summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
AgeCommit message (Expand)Author
2023-08-24perf scripts python: Add support for input args in gecko scriptAnup Sharma
2023-07-28perf scripts python: Add command execution for gecko scriptAnup Sharma
2022-12-14perf script: Introduce task analyzer python scriptHagen Paul Pfeifer
2021-09-10perf scripts python: Fix passing arguments to stackcollapse reportMichael Petlan
2021-05-25perf scripts python: intel-pt-events.py: Add branches to scriptAdrian Hunter
2020-05-05perf flamegraph: Use /bin/bash for report and record scriptsArnaldo Carvalho de Melo
2020-04-16perf script: Add flamegraph.py scriptAndreas Gerstmayr
2018-06-06perf script powerpc: Python script for hypervisor call statisticsRavi Bangoria
2018-01-12perf script python: Add script to profile and resolve physical mem typeKan Liang
2017-08-15perf script python: Add support for exporting to sqlite3Adrian Hunter
2017-06-30perf intel-pt: Add example script for power events and PTWRITEAdrian Hunter
2016-06-21perf script: Add stackcollapse.py scriptPaolo Bonzini
2015-08-28perf scripts python: Add new compaction-times scriptTony Jones
2014-11-03perf tools: Add call information to Python exportAdrian Hunter
2014-10-29perf script: Add Python script to export to postgresqlAdrian Hunter
2014-06-25perf scripts: Fallback to syscalls:* when raw_syscalls:* is not availableDaniel Bristot de Oliveira
2012-09-17perf scripts: Add event_analyzing_sample-record/reportFeng Tang
2011-09-29perf script: Add drop monitor scriptNeil Horman
2010-12-25perf script: Finish the rename from trace to scriptArnaldo Carvalho de Melo
2010-11-10perf trace scripting: remove system-wide param from shell scriptsTom Zanussi
2010-10-26perf python scripting: Add futex-contention scriptArnaldo Carvalho de Melo
2010-10-23perf trace: Use $PERF_EXEC_PATH in canned report scriptsBen Hutchings
2010-09-07perf: Add a script to show packets processingKoki Sanagi
2010-08-02perf: New migration tool overviewFrederic Weisbecker
2010-05-10perf/trace/scripting: syscall-counts script cleanupTom Zanussi
2010-05-10perf/trace/scripting: syscall-counts-by-pid script cleanupTom Zanussi
2010-05-10perf/trace/scripting: failed-syscalls-by-pid script cleanupTom Zanussi
2010-04-30perf: Remove leftover useless options to record trace events from scriptsFrederic Weisbecker
2010-04-14perf trace/scripting: Enable scripting shell scripts for live modeTom Zanussi
2010-04-14perf trace/scripting: Add rwtop and sctop scriptsTom Zanussi
2010-02-25perf/scripts: Add syscall tracing scriptsTom Zanussi
ntation/ABI/removed/sysfs-class-rfkill?id2=ae9559594cb851aff774d5bea243b84c6acf761d'>Documentation/ABI/removed/sysfs-class-rfkill2
-rw-r--r--Documentation/ABI/removed/sysfs-firmware-efi-vars12
-rw-r--r--Documentation/ABI/removed/sysfs-selinux-checkreqprot (renamed from Documentation/ABI/obsolete/sysfs-selinux-checkreqprot)3
-rw-r--r--Documentation/ABI/removed/sysfs-selinux-disable (renamed from Documentation/ABI/obsolete/sysfs-selinux-disable)3
-rw-r--r--Documentation/ABI/stable/o2cb4
-rw-r--r--Documentation/ABI/stable/sysfs-acpi-pmprofile20
-rw-r--r--Documentation/ABI/stable/sysfs-block223
-rw-r--r--Documentation/ABI/stable/sysfs-bus-mhi17
-rw-r--r--Documentation/ABI/stable/sysfs-bus-nvmem30
-rw-r--r--Documentation/ABI/stable/sysfs-class-backlight14
-rw-r--r--Documentation/ABI/stable/sysfs-class-bluetooth9
-rw-r--r--Documentation/ABI/stable/sysfs-class-infiniband2
-rw-r--r--Documentation/ABI/stable/sysfs-class-rfkill12
-rw-r--r--Documentation/ABI/stable/sysfs-devices-node54
-rw-r--r--Documentation/ABI/stable/sysfs-devices-system-cpu10
-rw-r--r--Documentation/ABI/stable/sysfs-driver-dma-idxd110
-rw-r--r--Documentation/ABI/stable/sysfs-driver-misc-cp50025
-rw-r--r--Documentation/ABI/stable/sysfs-driver-mlxreg-io273
-rw-r--r--Documentation/ABI/stable/sysfs-driver-qaic19
-rw-r--r--Documentation/ABI/stable/sysfs-driver-speakup9
-rw-r--r--Documentation/ABI/stable/sysfs-firmware-efi-vars79
-rw-r--r--Documentation/ABI/stable/sysfs-hypervisor-xen13
-rw-r--r--Documentation/ABI/stable/sysfs-kernel-time-aux-clocks5
-rw-r--r--Documentation/ABI/stable/sysfs-platform-wmi-bmof7
-rw-r--r--Documentation/ABI/stable/vdso8
-rw-r--r--Documentation/ABI/testing/configfs-tsm-report145
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget13
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget-acm7
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget-ffs12
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget-midi254
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget-uac18
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget-uac213
-rw-r--r--Documentation/ABI/testing/configfs-usb-gadget-uvc129
-rw-r--r--Documentation/ABI/testing/debugfs-alienware-wmi64
-rw-r--r--Documentation/ABI/testing/debugfs-amd-iommu131
-rw-r--r--Documentation/ABI/testing/debugfs-cec-error-inj2
-rw-r--r--Documentation/ABI/testing/debugfs-cxl157
-rw-r--r--Documentation/ABI/testing/debugfs-dell-wmi-ddv34
-rw-r--r--Documentation/ABI/testing/debugfs-driver-dcc127
-rw-r--r--Documentation/ABI/testing/debugfs-driver-habanalabs93
-rw-r--r--Documentation/ABI/testing/debugfs-driver-qat109
-rw-r--r--Documentation/ABI/testing/debugfs-driver-qat_telemetry259
-rw-r--r--Documentation/ABI/testing/debugfs-dwc-pcie157
-rw-r--r--Documentation/ABI/testing/debugfs-hisi-hpre31
-rw-r--r--Documentation/ABI/testing/debugfs-hisi-migration25
-rw-r--r--Documentation/ABI/testing/debugfs-hisi-sec31
-rw-r--r--Documentation/ABI/testing/debugfs-hisi-zip31
-rw-r--r--Documentation/ABI/testing/debugfs-iio-ad946739
-rw-r--r--Documentation/ABI/testing/debugfs-iio-backend20
-rw-r--r--Documentation/ABI/testing/debugfs-intel-iommu276
-rw-r--r--Documentation/ABI/testing/debugfs-msi-wmi-platform14
-rw-r--r--Documentation/ABI/testing/debugfs-pcie-ptm70
-rw-r--r--Documentation/ABI/testing/debugfs-pktcdvd18
-rw-r--r--Documentation/ABI/testing/debugfs-scmi70
-rw-r--r--Documentation/ABI/testing/debugfs-scmi-raw208
-rw-r--r--Documentation/ABI/testing/debugfs-tpmi40
-rw-r--r--Documentation/ABI/testing/debugfs-turris-mox-rwtm14
-rw-r--r--Documentation/ABI/testing/debugfs-vfio31
-rw-r--r--Documentation/ABI/testing/gpio-cdev9
-rw-r--r--Documentation/ABI/testing/ima_policy11
-rw-r--r--Documentation/ABI/testing/procfs-diskstats2
-rw-r--r--Documentation/ABI/testing/sysfs-auxdisplay-linedisp90
-rw-r--r--Documentation/ABI/testing/sysfs-block-bcache7
-rw-r--r--Documentation/ABI/testing/sysfs-block-device22
-rw-r--r--Documentation/ABI/testing/sysfs-block-zram29
-rw-r--r--Documentation/ABI/testing/sysfs-bus-acpi18
-rw-r--r--Documentation/ABI/testing/sysfs-bus-auxiliary9
-rw-r--r--Documentation/ABI/testing/sysfs-bus-cdx121
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coreboot45
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-cti84
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source21
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-etb106
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x18
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x16
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel6
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-stm6
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc22
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm280
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe6
-rw-r--r--Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb31
-rw-r--r--Documentation/ABI/testing/sysfs-bus-counter132
-rw-r--r--Documentation/ABI/testing/sysfs-bus-css15
-rw-r--r--Documentation/ABI/testing/sysfs-bus-cxl308
-rw-r--r--Documentation/ABI/testing/sysfs-bus-dax153
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices24
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-caps6
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-events12
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt113
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci160
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu37
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-dtl25
-rw-r--r--Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-pmu25
-rw-r--r--Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo6
-rw-r--r--Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa94802
-rw-r--r--Documentation/ABI/testing/sysfs-bus-i2c-devices-m24lr100
-rw-r--r--Documentation/ABI/testing/sysfs-bus-i2c-devices-turris-omnia-mcu113
-rw-r--r--Documentation/ABI/testing/sysfs-bus-i3c19
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio590
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-ad9739a19
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta23
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-ad413020
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-ad719224
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-max1141013
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-max961117
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-mcp356453
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-adc-pac19349
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-bno05581
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-cdc-ad774611
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp4014
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-cros-ec10
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-dac61
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-dac-ltc268831
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-filter-admv88184
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-frequency-admv10134
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc9
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-inv_icm4260018
-rw-r--r--Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s121027
-rw-r--r--Documentation/ABI/testing/sysfs-bus-nfit2
-rw-r--r--Documentation/ABI/testing/sysfs-bus-nvdimm18
-rw-r--r--Documentation/ABI/testing/sysfs-bus-optee-devices9
-rw-r--r--Documentation/ABI/testing/sysfs-bus-papr-pmem4
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci245
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci-devices-aer163
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats119
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci-devices-avs8
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd62
-rw-r--r--Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro325
-rw-r--r--Documentation/ABI/testing/sysfs-bus-platform-drivers-amd_x3d_vcache12
-rw-r--r--Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-dev9
-rw-r--r--Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub8
-rw-r--r--Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor9
-rw-r--r--Documentation/ABI/testing/sysfs-bus-thunderbolt42
-rw-r--r--Documentation/ABI/testing/sysfs-bus-umc28
-rw-r--r--Documentation/ABI/testing/sysfs-bus-usb91
-rw-r--r--Documentation/ABI/testing/sysfs-bus-vdpa14
-rw-r--r--Documentation/ABI/testing/sysfs-bus-wmi81
-rw-r--r--Documentation/ABI/testing/sysfs-class2
-rw-r--r--Documentation/ABI/testing/sysfs-class-bdi68
-rw-r--r--Documentation/ABI/testing/sysfs-class-chromeos20
-rw-r--r--Documentation/ABI/testing/sysfs-class-devfreq12
-rw-r--r--Documentation/ABI/testing/sysfs-class-drm8
-rw-r--r--Documentation/ABI/testing/sysfs-class-firmware14
-rw-r--r--Documentation/ABI/testing/sysfs-class-firmware-attributes138
-rw-r--r--Documentation/ABI/testing/sysfs-class-hwmon146
-rw-r--r--Documentation/ABI/testing/sysfs-class-intel_pmt-features134
-rw-r--r--Documentation/ABI/testing/sysfs-class-led6
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-driver-aw200xx5
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia14
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-trigger-netdev140
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-trigger-pattern10
-rw-r--r--Documentation/ABI/testing/sysfs-class-led-trigger-tty58
-rw-r--r--Documentation/ABI/testing/sysfs-class-mtd2
-rw-r--r--Documentation/ABI/testing/sysfs-class-net2
-rw-r--r--Documentation/ABI/testing/sysfs-class-net-peak_usb19
-rw-r--r--Documentation/ABI/testing/sysfs-class-net-phydev10
-rw-r--r--Documentation/ABI/testing/sysfs-class-net-qmi2
-rw-r--r--Documentation/ABI/testing/sysfs-class-net-queues47
-rw-r--r--Documentation/ABI/testing/sysfs-class-net-statistics48
-rw-r--r--Documentation/ABI/testing/sysfs-class-pktcdvd97
-rw-r--r--Documentation/ABI/testing/sysfs-class-platform-profile50
-rw-r--r--Documentation/ABI/testing/sysfs-class-power172
-rw-r--r--Documentation/ABI/testing/sysfs-class-power-gaokun27
-rw-r--r--Documentation/ABI/testing/sysfs-class-power-max1720x32
-rw-r--r--Documentation/ABI/testing/sysfs-class-power-rt946719
-rw-r--r--Documentation/ABI/testing/sysfs-class-power-rt947132
-rw-r--r--Documentation/ABI/testing/sysfs-class-power-rt975630
-rw-r--r--Documentation/ABI/testing/sysfs-class-power-wilco2
-rw-r--r--Documentation/ABI/testing/sysfs-class-remoteproc2
-rw-r--r--Documentation/ABI/testing/sysfs-class-tee15
-rw-r--r--Documentation/ABI/testing/sysfs-class-thermal2
-rw-r--r--Documentation/ABI/testing/sysfs-class-tsm19
-rw-r--r--Documentation/ABI/testing/sysfs-class-typec27
-rw-r--r--Documentation/ABI/testing/sysfs-class-usb_power_delivery46
-rw-r--r--Documentation/ABI/testing/sysfs-class-usb_role6
-rw-r--r--Documentation/ABI/testing/sysfs-class-uwb_rc156
-rw-r--r--Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc57
-rw-r--r--Documentation/ABI/testing/sysfs-class-watchdog15
-rw-r--r--Documentation/ABI/testing/sysfs-devices-mapping30
-rw-r--r--Documentation/ABI/testing/sysfs-devices-memory8
-rw-r--r--Documentation/ABI/testing/sysfs-devices-online2
-rw-r--r--Documentation/ABI/testing/sysfs-devices-pci-host-bridge45
-rw-r--r--Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs126
-rw-r--r--Documentation/ABI/testing/sysfs-devices-power44
-rw-r--r--Documentation/ABI/testing/sysfs-devices-state_synced5
-rw-r--r--Documentation/ABI/testing/sysfs-devices-system-cpu140
-rw-r--r--Documentation/ABI/testing/sysfs-devices-vfio-dev8
-rw-r--r--Documentation/ABI/testing/sysfs-devices-virtual-misc-tdx_guest63
-rw-r--r--Documentation/ABI/testing/sysfs-driver-amd-sfh13
-rw-r--r--Documentation/ABI/testing/sysfs-driver-ccp18
-rw-r--r--Documentation/ABI/testing/sysfs-driver-chromeos-acpi17
-rw-r--r--Documentation/ABI/testing/sysfs-driver-eud2
-rw-r--r--Documentation/ABI/testing/sysfs-driver-framer-pef22568
-rw-r--r--Documentation/ABI/testing/sysfs-driver-ge-achc2
-rw-r--r--Documentation/ABI/testing/sysfs-driver-habanalabs100
-rw-r--r--Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd13
-rw-r--r--Documentation/ABI/testing/sysfs-driver-hid-corsair-void38
-rw-r--r--Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon93
-rw-r--r--Documentation/ABI/testing/sysfs-driver-intel-m10-bmc12
-rw-r--r--Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update14
-rw-r--r--Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon198
-rw-r--r--Documentation/ABI/testing/sysfs-driver-intel-xe-sriov159
-rw-r--r--Documentation/ABI/testing/sysfs-driver-intel_sdsi47
-rw-r--r--Documentation/ABI/testing/sysfs-driver-panfrost-profiling10
-rw-r--r--Documentation/ABI/testing/sysfs-driver-panthor-profiling10
-rw-r--r--Documentation/ABI/testing/sysfs-driver-qaic18
-rw-r--r--Documentation/ABI/testing/sysfs-driver-qat134
-rw-r--r--Documentation/ABI/testing/sysfs-driver-qat_ras41
-rw-r--r--Documentation/ABI/testing/sysfs-driver-qat_rl226
-rw-r--r--Documentation/ABI/testing/sysfs-driver-samsung-laptop11
-rw-r--r--Documentation/ABI/testing/sysfs-driver-spi-intel20
-rw-r--r--Documentation/ABI/testing/sysfs-driver-tegra-fuse2
-rw-r--r--Documentation/ABI/testing/sysfs-driver-typec-displayport25
-rw-r--r--Documentation/ABI/testing/sysfs-driver-uacce18
-rw-r--r--Documentation/ABI/testing/sysfs-driver-ufs598
-rw-r--r--Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid29
-rw-r--r--Documentation/ABI/testing/sysfs-driver-uniwill-laptop53
-rw-r--r--Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager16
-rw-r--r--Documentation/ABI/testing/sysfs-driver-zynqmp-fpga73
-rw-r--r--Documentation/ABI/testing/sysfs-edac-ecs74
-rw-r--r--Documentation/ABI/testing/sysfs-edac-memory-repair206
-rw-r--r--Documentation/ABI/testing/sysfs-edac-scrub85
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-acpi29
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-dmi-entries2
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-efi7
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-initrd8
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-opal-powercap4
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-opal-psr4
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups4
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info10
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-sgi_uv4
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm9
-rw-r--r--Documentation/ABI/testing/sysfs-fs-erofs30
-rw-r--r--Documentation/ABI/testing/sysfs-fs-f2fs399
-rw-r--r--Documentation/ABI/testing/sysfs-fs-virtiofs11
-rw-r--r--Documentation/ABI/testing/sysfs-fs-xfs26
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-address_bits10
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-cpu_byteorder12
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-fadump19
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-hardlockup_count7
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-iommu_groups1
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-kexec-kdump61
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-livepatch25
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-cma19
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-damon280
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-ksm8
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers25
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-mempolicy4
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave54
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-numa16
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage18
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-oops_count6
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-rcu_stall_count6
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-reboot18
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-slab101
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-softlockup_count7
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-warn_count6
-rw-r--r--Documentation/ABI/testing/sysfs-memory-page-offline4
-rw-r--r--Documentation/ABI/testing/sysfs-module13
-rw-r--r--Documentation/ABI/testing/sysfs-nvmem-cells21
-rw-r--r--Documentation/ABI/testing/sysfs-ocfs212
-rw-r--r--Documentation/ABI/testing/sysfs-platform-alienware-wmi14
-rw-r--r--Documentation/ABI/testing/sysfs-platform-asus-wmi131
-rw-r--r--Documentation/ABI/testing/sysfs-platform-ayaneo-ec19
-rw-r--r--Documentation/ABI/testing/sysfs-platform-dell-laptop2
-rw-r--r--Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi8
-rw-r--r--Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv9
-rw-r--r--Documentation/ABI/testing/sysfs-platform-dfl-fme2
-rw-r--r--Documentation/ABI/testing/sysfs-platform-hidma2
-rw-r--r--Documentation/ABI/testing/sysfs-platform-hidma-mgmt20
-rw-r--r--Documentation/ABI/testing/sysfs-platform-ideapad-laptop9
-rw-r--r--Documentation/ABI/testing/sysfs-platform-intel-ifs47
-rw-r--r--Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update2
-rw-r--r--Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt2
-rw-r--r--Documentation/ABI/testing/sysfs-platform-kim2
-rw-r--r--Documentation/ABI/testing/sysfs-platform-mellanox-bootctl92
-rw-r--r--Documentation/ABI/testing/sysfs-platform-mellanox-pmc64
-rw-r--r--Documentation/ABI/testing/sysfs-platform-oxp25
-rw-r--r--Documentation/ABI/testing/sysfs-platform-power-on-reason12
-rw-r--r--Documentation/ABI/testing/sysfs-platform-silicom30
-rw-r--r--Documentation/ABI/testing/sysfs-platform-sst-atom2
-rw-r--r--Documentation/ABI/testing/sysfs-platform_profile5
-rw-r--r--Documentation/ABI/testing/sysfs-power73
-rw-r--r--Documentation/ABI/testing/sysfs-pps-gen43
-rw-r--r--Documentation/ABI/testing/sysfs-pps-gen-tio6
-rw-r--r--Documentation/ABI/testing/sysfs-secvar86
-rw-r--r--Documentation/ABI/testing/sysfs-timecard31
-rw-r--r--Documentation/ABI/testing/sysfs-tty15
-rw-r--r--Documentation/ABI/testing/sysfs-wusb_cbaf101
-rw-r--r--Documentation/Kconfig12
-rw-r--r--Documentation/Makefile140
-rw-r--r--Documentation/PCI/boot-interrupts.rst2
-rw-r--r--Documentation/PCI/controller/index.rst10
-rw-r--r--Documentation/PCI/controller/rcar-pcie-firmware.rst32
-rw-r--r--Documentation/PCI/endpoint/index.rst1
-rw-r--r--Documentation/PCI/endpoint/pci-endpoint-cfs.rst4
-rw-r--r--Documentation/PCI/endpoint/pci-endpoint.rst46
-rw-r--r--Documentation/PCI/endpoint/pci-ntb-howto.rst11
-rw-r--r--Documentation/PCI/endpoint/pci-nvme-function.rst13
-rw-r--r--Documentation/PCI/endpoint/pci-test-howto.rst189
-rw-r--r--Documentation/PCI/endpoint/pci-vntb-howto.rst22
-rw-r--r--Documentation/PCI/index.rst8
-rw-r--r--Documentation/PCI/msi-howto.rst14
-rw-r--r--Documentation/PCI/pci-error-recovery.rst82
-rw-r--r--Documentation/PCI/pci.rst4
-rw-r--r--Documentation/PCI/pcieaer-howto.rst263
-rw-r--r--Documentation/PCI/pciebus-howto.rst20
-rw-r--r--Documentation/PCI/tph.rst132
-rw-r--r--Documentation/RCU/Design/Data-Structures/Data-Structures.rst61
-rw-r--r--Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst8
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst12
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg9
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg8
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg12
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg21
-rw-r--r--Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg8
-rw-r--r--Documentation/RCU/Design/Requirements/Requirements.rst218
-rw-r--r--Documentation/RCU/NMI-RCU.rst4
-rw-r--r--Documentation/RCU/RTFP.txt16
-rw-r--r--Documentation/RCU/UP.rst17
-rw-r--r--Documentation/RCU/arrayRCU.rst165
-rw-r--r--Documentation/RCU/checklist.rst317
-rw-r--r--Documentation/RCU/index.rst7
-rw-r--r--Documentation/RCU/listRCU.rst193
-rw-r--r--Documentation/RCU/lockdep-splat.rst2
-rw-r--r--Documentation/RCU/lockdep.rst21
-rw-r--r--Documentation/RCU/rcu.rst6
-rw-r--r--Documentation/RCU/rcu_dereference.rst53
-rw-r--r--Documentation/RCU/rcubarrier.rst354
-rw-r--r--Documentation/RCU/rculist_nulls.rst137
-rw-r--r--Documentation/RCU/stallwarn.rst144
-rw-r--r--Documentation/RCU/torture.rst93
-rw-r--r--Documentation/RCU/whatisRCU.rst389
-rw-r--r--Documentation/accel/amdxdna/amdnpu.rst281
-rw-r--r--Documentation/accel/amdxdna/index.rst11
-rw-r--r--Documentation/accel/index.rst20
-rw-r--r--Documentation/accel/introduction.rst110
-rw-r--r--Documentation/accel/qaic/aic080.rst14
-rw-r--r--Documentation/accel/qaic/aic100.rst538
-rw-r--r--Documentation/accel/qaic/index.rst14
-rw-r--r--Documentation/accel/qaic/qaic.rst209
-rw-r--r--Documentation/accel/rocket/index.rst19
-rw-r--r--Documentation/accounting/delay-accounting.rst126
-rw-r--r--Documentation/accounting/psi.rst6
-rw-r--r--Documentation/accounting/taskstats-struct.rst2
-rw-r--r--Documentation/accounting/taskstats.rst54
-rw-r--r--Documentation/admin-guide/LSM/SELinux.rst11
-rw-r--r--Documentation/admin-guide/LSM/SafeSetID.rst2
-rw-r--r--Documentation/admin-guide/LSM/Smack.rst16
-rw-r--r--Documentation/admin-guide/LSM/apparmor.rst7
-rw-r--r--Documentation/admin-guide/LSM/index.rst2
-rw-r--r--Documentation/admin-guide/LSM/ipe.rst835
-rw-r--r--Documentation/admin-guide/LSM/landlock.rst158
-rw-r--r--Documentation/admin-guide/LSM/tomoyo.rst35
-rw-r--r--Documentation/admin-guide/RAS/address-translation.rst24
-rw-r--r--Documentation/admin-guide/RAS/error-decoding.rst21
-rw-r--r--Documentation/admin-guide/RAS/index.rst7
-rw-r--r--Documentation/admin-guide/RAS/main.rst1087
-rw-r--r--Documentation/admin-guide/README.rst79
-rw-r--r--Documentation/admin-guide/abi-obsolete-files.rst7
-rw-r--r--Documentation/admin-guide/abi-obsolete.rst6
-rw-r--r--Documentation/admin-guide/abi-removed-files.rst7
-rw-r--r--Documentation/admin-guide/abi-removed.rst6
-rw-r--r--Documentation/admin-guide/abi-stable-files.rst7
-rw-r--r--Documentation/admin-guide/abi-stable.rst6
-rw-r--r--Documentation/admin-guide/abi-testing-files.rst7
-rw-r--r--Documentation/admin-guide/abi-testing.rst6
-rw-r--r--Documentation/admin-guide/abi.rst18
-rw-r--r--Documentation/admin-guide/acpi/cppc_sysfs.rst2
-rw-r--r--Documentation/admin-guide/acpi/index.rst1
-rw-r--r--Documentation/admin-guide/acpi/ssdt-overlays.rst2
-rw-r--r--Documentation/admin-guide/aoe/udev.txt6
-rw-r--r--Documentation/admin-guide/bcache.rst18
-rw-r--r--Documentation/admin-guide/blockdev/index.rst1
-rw-r--r--Documentation/admin-guide/blockdev/nbd.rst2
-rw-r--r--Documentation/admin-guide/blockdev/paride.rst388
-rw-r--r--Documentation/admin-guide/blockdev/zoned_loop.rst182
-rw-r--r--Documentation/admin-guide/blockdev/zram.rst229
-rw-r--r--Documentation/admin-guide/bootconfig.rst10
-rw-r--r--Documentation/admin-guide/braille-console.rst4
-rw-r--r--Documentation/admin-guide/bug-bisect.rst219
-rw-r--r--Documentation/admin-guide/bug-hunting.rst30
-rw-r--r--Documentation/admin-guide/cgroup-v1/blkio-controller.rst2
-rw-r--r--Documentation/admin-guide/cgroup-v1/cgroups.rst6
-rw-r--r--Documentation/admin-guide/cgroup-v1/cpusets.rst13
-rw-r--r--Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst4
-rw-r--r--Documentation/admin-guide/cgroup-v1/hugetlb.rst20
-rw-r--r--Documentation/admin-guide/cgroup-v1/memcg_test.rst4
-rw-r--r--Documentation/admin-guide/cgroup-v1/memory.rst395
-rw-r--r--Documentation/admin-guide/cgroup-v1/pids.rst3
-rw-r--r--Documentation/admin-guide/cgroup-v2.rst848
-rw-r--r--Documentation/admin-guide/cifs/changes.rst4
-rw-r--r--Documentation/admin-guide/cifs/introduction.rst2
-rw-r--r--Documentation/admin-guide/cifs/todo.rst44
-rw-r--r--Documentation/admin-guide/cifs/usage.rst60
-rw-r--r--Documentation/admin-guide/device-mapper/cache-policies.rst2
-rw-r--r--Documentation/admin-guide/device-mapper/delay.rst41
-rw-r--r--Documentation/admin-guide/device-mapper/dm-crypt.rst31
-rw-r--r--Documentation/admin-guide/device-mapper/dm-ebs.rst2
-rw-r--r--Documentation/admin-guide/device-mapper/dm-flakey.rst14
-rw-r--r--Documentation/admin-guide/device-mapper/dm-init.rst8
-rw-r--r--Documentation/admin-guide/device-mapper/dm-integrity.rst48
-rw-r--r--Documentation/admin-guide/device-mapper/dm-pcache.rst202
-rw-r--r--Documentation/admin-guide/device-mapper/dm-zoned.rst2
-rw-r--r--Documentation/admin-guide/device-mapper/index.rst3
-rw-r--r--Documentation/admin-guide/device-mapper/thin-provisioning.rst16
-rw-r--r--Documentation/admin-guide/device-mapper/unstriped.rst10
-rw-r--r--Documentation/admin-guide/device-mapper/vdo-design.rst633
-rw-r--r--Documentation/admin-guide/device-mapper/vdo.rst413
-rw-r--r--Documentation/admin-guide/device-mapper/verity.rst20
-rw-r--r--Documentation/admin-guide/devices.txt24
-rw-r--r--Documentation/admin-guide/dynamic-debug-howto.rst259
-rw-r--r--Documentation/admin-guide/edid.rst35
-rw-r--r--Documentation/admin-guide/efi-stub.rst5
-rw-r--r--Documentation/admin-guide/ext4.rst22
-rw-r--r--Documentation/admin-guide/features.rst2
-rw-r--r--Documentation/admin-guide/gpio/gpio-aggregator.rst107
-rw-r--r--Documentation/admin-guide/gpio/gpio-mockup.rst8
-rw-r--r--Documentation/admin-guide/gpio/gpio-sim.rst11
-rw-r--r--Documentation/admin-guide/gpio/gpio-virtuser.rst177
-rw-r--r--Documentation/admin-guide/gpio/index.rst7
-rw-r--r--Documentation/admin-guide/gpio/obsolete.rst13
-rw-r--r--Documentation/admin-guide/highuid.rst80
-rw-r--r--Documentation/admin-guide/hw-vuln/attack_vector_controls.rst236
-rw-r--r--Documentation/admin-guide/hw-vuln/core-scheduling.rst4
-rw-r--r--Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst91
-rw-r--r--Documentation/admin-guide/hw-vuln/gather_data_sampling.rst109
-rw-r--r--Documentation/admin-guide/hw-vuln/index.rst19
-rw-r--r--Documentation/admin-guide/hw-vuln/indirect-target-selection.rst168
-rw-r--r--Documentation/admin-guide/hw-vuln/l1d_flush.rst2
-rw-r--r--Documentation/admin-guide/hw-vuln/mds.rst42
-rw-r--r--Documentation/admin-guide/hw-vuln/old_microcode.rst21
-rw-r--r--Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst17
-rw-r--r--Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst96
-rw-r--r--Documentation/admin-guide/hw-vuln/rsb.rst268
-rw-r--r--Documentation/admin-guide/hw-vuln/spectre.rst140
-rw-r--r--Documentation/admin-guide/hw-vuln/srso.rst242
-rw-r--r--Documentation/admin-guide/hw-vuln/tsx_async_abort.rst35
-rw-r--r--Documentation/admin-guide/hw-vuln/vmscape.rst110
-rw-r--r--Documentation/admin-guide/hw_random.rst11
-rw-r--r--Documentation/admin-guide/index.rst165
-rw-r--r--Documentation/admin-guide/iostats.rst89
-rw-r--r--Documentation/admin-guide/kdump/gdbmacros.txt2
-rw-r--r--Documentation/admin-guide/kdump/kdump.rst111
-rw-r--r--Documentation/admin-guide/kdump/vmcoreinfo.rst99
-rw-r--r--Documentation/admin-guide/kernel-parameters.rst155
-rw-r--r--Documentation/admin-guide/kernel-parameters.txt3468
-rw-r--r--Documentation/admin-guide/kernel-per-CPU-kthreads.rst23
-rw-r--r--Documentation/admin-guide/laptops/alienware-wmi.rst127
-rw-r--r--Documentation/admin-guide/laptops/index.rst3
-rw-r--r--Documentation/admin-guide/laptops/laptop-mode.rst8
-rw-r--r--Documentation/admin-guide/laptops/lg-laptop.rst4
-rw-r--r--Documentation/admin-guide/laptops/samsung-galaxybook.rst174
-rw-r--r--Documentation/admin-guide/laptops/sonypi.rst2
-rw-r--r--Documentation/admin-guide/laptops/thinkpad-acpi.rst33
-rw-r--r--Documentation/admin-guide/laptops/uniwill-laptop.rst60
-rw-r--r--Documentation/admin-guide/md.rst100
-rw-r--r--Documentation/admin-guide/media/bttv.rst2
-rw-r--r--Documentation/admin-guide/media/building.rst4
-rw-r--r--Documentation/admin-guide/media/c3-isp.dot26
-rw-r--r--Documentation/admin-guide/media/c3-isp.rst101
-rw-r--r--Documentation/admin-guide/media/cec-drivers.rst10
-rw-r--r--Documentation/admin-guide/media/cec.rst467
-rw-r--r--Documentation/admin-guide/media/cpia2.rst145
-rw-r--r--Documentation/admin-guide/media/davinci-vpbe.rst65
-rw-r--r--Documentation/admin-guide/media/dvb-drivers.rst1
-rw-r--r--Documentation/admin-guide/media/em28xx-cardlist.rst8
-rw-r--r--Documentation/admin-guide/media/i2c-cardlist.rst9
-rw-r--r--Documentation/admin-guide/media/imx.rst2
-rw-r--r--Documentation/admin-guide/media/index.rst14
-rw-r--r--Documentation/admin-guide/media/ipu3.rst6
-rw-r--r--Documentation/admin-guide/media/ipu6-isys.rst161
-rw-r--r--Documentation/admin-guide/media/ipu6_isys_graph.svg548
-rw-r--r--Documentation/admin-guide/media/ivtv.rst2
-rw-r--r--Documentation/admin-guide/media/mali-c55-graph.dot19
-rw-r--r--Documentation/admin-guide/media/mali-c55.rst413
-rw-r--r--Documentation/admin-guide/media/meye.rst93
-rw-r--r--Documentation/admin-guide/media/mgb4.rst385
-rw-r--r--Documentation/admin-guide/media/omap4_camera.rst62
-rw-r--r--Documentation/admin-guide/media/other-usb-cardlist.rst14
-rw-r--r--Documentation/admin-guide/media/pci-cardlist.rst3
-rw-r--r--Documentation/admin-guide/media/platform-cardlist.rst4
-rw-r--r--Documentation/admin-guide/media/pulse8-cec.rst13
-rw-r--r--Documentation/admin-guide/media/qcom_camss.rst6
-rw-r--r--Documentation/admin-guide/media/radio-cardlist.rst1
-rw-r--r--Documentation/admin-guide/media/raspberrypi-pisp-be.dot20
-rw-r--r--Documentation/admin-guide/media/raspberrypi-pisp-be.rst109
-rw-r--r--Documentation/admin-guide/media/raspberrypi-rp1-cfe.dot27
-rw-r--r--Documentation/admin-guide/media/raspberrypi-rp1-cfe.rst78
-rw-r--r--Documentation/admin-guide/media/rkcif-rk3568-vicap.dot8
-rw-r--r--Documentation/admin-guide/media/rkcif.rst79
-rw-r--r--Documentation/admin-guide/media/rkisp1.rst15
-rw-r--r--Documentation/admin-guide/media/saa7134.rst2
-rw-r--r--Documentation/admin-guide/media/si4713.rst6
-rw-r--r--Documentation/admin-guide/media/si476x.rst2
-rw-r--r--Documentation/admin-guide/media/starfive_camss.rst72
-rw-r--r--Documentation/admin-guide/media/starfive_camss_graph.dot12
-rw-r--r--Documentation/admin-guide/media/tm6000-cardlist.rst83
-rw-r--r--Documentation/admin-guide/media/tuner-cardlist.rst2
-rw-r--r--Documentation/admin-guide/media/usb-cardlist.rst7
-rw-r--r--Documentation/admin-guide/media/v4l-drivers.rst13
-rw-r--r--Documentation/admin-guide/media/vimc.rst8
-rw-r--r--Documentation/admin-guide/media/visl.rst185
-rw-r--r--Documentation/admin-guide/media/vivid.rst197
-rw-r--r--Documentation/admin-guide/media/zr364xx.rst102
-rw-r--r--Documentation/admin-guide/mm/cma_debugfs.rst20
-rw-r--r--Documentation/admin-guide/mm/concepts.rst13
-rw-r--r--Documentation/admin-guide/mm/damon/index.rst12
-rw-r--r--Documentation/admin-guide/mm/damon/lru_sort.rst26
-rw-r--r--Documentation/admin-guide/mm/damon/reclaim.rst62
-rw-r--r--Documentation/admin-guide/mm/damon/start.rst82
-rw-r--r--Documentation/admin-guide/mm/damon/stat.rst86
-rw-r--r--Documentation/admin-guide/mm/damon/usage.rst863
-rw-r--r--Documentation/admin-guide/mm/hugetlbpage.rst29
-rw-r--r--Documentation/admin-guide/mm/idle_page_tracking.rst9
-rw-r--r--Documentation/admin-guide/mm/index.rst9
-rw-r--r--Documentation/admin-guide/mm/kho.rst115
-rw-r--r--Documentation/admin-guide/mm/ksm.rst122
-rw-r--r--Documentation/admin-guide/mm/memory-hotplug.rst41
-rw-r--r--Documentation/admin-guide/mm/multigen_lru.rst163
-rw-r--r--Documentation/admin-guide/mm/numa_memory_policy.rst17
-rw-r--r--Documentation/admin-guide/mm/numaperf.rst8
-rw-r--r--Documentation/admin-guide/mm/pagemap.rst161
-rw-r--r--Documentation/admin-guide/mm/shrinker_debugfs.rst2
-rw-r--r--Documentation/admin-guide/mm/slab.rst469
-rw-r--r--Documentation/admin-guide/mm/soft-dirty.rst2
-rw-r--r--Documentation/admin-guide/mm/swap_numa.rst80
-rw-r--r--Documentation/admin-guide/mm/transhuge.rst442
-rw-r--r--Documentation/admin-guide/mm/userfaultfd.rst121
-rw-r--r--Documentation/admin-guide/mm/zswap.rst110
-rw-r--r--Documentation/admin-guide/module-signing.rst19
-rw-r--r--Documentation/admin-guide/namespaces/resource-control.rst24
-rw-r--r--Documentation/admin-guide/nfs/nfsroot.rst2
-rw-r--r--Documentation/admin-guide/nvme-multipath.rst72
-rw-r--r--Documentation/admin-guide/perf/alibaba_pmu.rst5
-rw-r--r--Documentation/admin-guide/perf/ampere_cspmu.rst29
-rw-r--r--Documentation/admin-guide/perf/arm-ni.rst17
-rw-r--r--Documentation/admin-guide/perf/cxl.rst68
-rw-r--r--Documentation/admin-guide/perf/dwc_pcie_pmu.rst94
-rw-r--r--Documentation/admin-guide/perf/fujitsu_uncore_pmu.rst115
-rw-r--r--Documentation/admin-guide/perf/hisi-pcie-pmu.rst132
-rw-r--r--Documentation/admin-guide/perf/hisi-pmu.rst99
-rw-r--r--Documentation/admin-guide/perf/hns3-pmu.rst10
-rw-r--r--Documentation/admin-guide/perf/imx-ddr.rst45
-rw-r--r--Documentation/admin-guide/perf/index.rst11
-rw-r--r--Documentation/admin-guide/perf/meson-ddr-pmu.rst70
-rw-r--r--Documentation/admin-guide/perf/mrvl-odyssey-ddr-pmu.rst80
-rw-r--r--Documentation/admin-guide/perf/mrvl-odyssey-tad-pmu.rst37
-rw-r--r--Documentation/admin-guide/perf/mrvl-pem-pmu.rst56
-rw-r--r--Documentation/admin-guide/perf/nvidia-pmu.rst333
-rw-r--r--Documentation/admin-guide/perf/qcom_l2_pmu.rst2
-rw-r--r--Documentation/admin-guide/perf/qcom_l3_pmu.rst2
-rw-r--r--Documentation/admin-guide/perf/starfive_starlink_pmu.rst46
-rw-r--r--Documentation/admin-guide/perf/thunderx2-pmu.rst2
-rw-r--r--Documentation/admin-guide/perf/xgene-pmu.rst2
-rw-r--r--Documentation/admin-guide/pm/amd-pstate.rst397
-rw-r--r--Documentation/admin-guide/pm/cpufreq.rst51
-rw-r--r--Documentation/admin-guide/pm/cpuidle.rst92
-rw-r--r--Documentation/admin-guide/pm/intel_idle.rst56
-rw-r--r--Documentation/admin-guide/pm/intel_pstate.rst232
-rw-r--r--Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst126
-rw-r--r--Documentation/admin-guide/pnp.rst3
-rw-r--r--Documentation/admin-guide/pstore-blk.rst8
-rw-r--r--Documentation/admin-guide/quickly-build-trimmed-linux.rst1097
-rw-r--r--Documentation/admin-guide/ramoops.rst13
-rw-r--r--Documentation/admin-guide/ras.rst1219
-rw-r--r--Documentation/admin-guide/reporting-issues.rst14
-rw-r--r--Documentation/admin-guide/reporting-regressions.rst12
-rw-r--r--Documentation/admin-guide/security-bugs.rst96
-rw-r--r--Documentation/admin-guide/serial-console.rst40
-rw-r--r--Documentation/admin-guide/spkguide.txt15
-rw-r--r--Documentation/admin-guide/syscall-user-dispatch.rst27
-rw-r--r--Documentation/admin-guide/sysctl/fs.rst296
-rw-r--r--Documentation/admin-guide/sysctl/index.rst18
-rw-r--r--Documentation/admin-guide/sysctl/kernel.rst302
-rw-r--r--Documentation/admin-guide/sysctl/net.rst55
-rw-r--r--Documentation/admin-guide/sysctl/vm.rst120
-rw-r--r--Documentation/admin-guide/sysrq.rst42
-rw-r--r--Documentation/admin-guide/tainted-kernels.rst11
-rw-r--r--Documentation/admin-guide/thermal/index.rst9
-rw-r--r--Documentation/admin-guide/thermal/intel_powerclamp.rst (renamed from Documentation/driver-api/thermal/intel_powerclamp.rst)37
-rw-r--r--Documentation/admin-guide/thermal/intel_thermal_throttle.rst91
-rw-r--r--Documentation/admin-guide/thunderbolt.rst94
-rw-r--r--Documentation/admin-guide/unicode.rst9
-rw-r--r--Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst2222
-rw-r--r--Documentation/admin-guide/workload-tracing.rst606
-rw-r--r--Documentation/admin-guide/xfs.rst128
-rw-r--r--Documentation/arc/features.rst3
-rw-r--r--Documentation/arch.rst28
-rw-r--r--Documentation/arch/arc/arc.rst (renamed from Documentation/arc/arc.rst)0
-rw-r--r--Documentation/arch/arc/features.rst3
-rw-r--r--Documentation/arch/arc/index.rst (renamed from Documentation/arc/index.rst)0
-rw-r--r--Documentation/arch/arm/arm.rst (renamed from Documentation/arm/arm.rst)2
-rw-r--r--Documentation/arch/arm/booting.rst (renamed from Documentation/arm/booting.rst)0
-rw-r--r--Documentation/arch/arm/cluster-pm-race-avoidance.rst (renamed from Documentation/arm/cluster-pm-race-avoidance.rst)0
-rw-r--r--Documentation/arch/arm/features.rst3
-rw-r--r--Documentation/arch/arm/firmware.rst (renamed from Documentation/arm/firmware.rst)0
-rw-r--r--Documentation/arch/arm/google/chromebook-boot-flow.rst (renamed from Documentation/arm/google/chromebook-boot-flow.rst)0
-rw-r--r--Documentation/arch/arm/index.rst85
-rw-r--r--Documentation/arch/arm/interrupts.rst (renamed from Documentation/arm/interrupts.rst)0
-rw-r--r--Documentation/arch/arm/ixp4xx.rst (renamed from Documentation/arm/ixp4xx.rst)4
-rw-r--r--Documentation/arch/arm/kernel_mode_neon.rst (renamed from Documentation/arm/kernel_mode_neon.rst)0
-rw-r--r--Documentation/arch/arm/kernel_user_helpers.rst (renamed from Documentation/arm/kernel_user_helpers.rst)0
-rw-r--r--Documentation/arch/arm/keystone/knav-qmss.rst (renamed from Documentation/arm/keystone/knav-qmss.rst)0
-rw-r--r--Documentation/arch/arm/keystone/overview.rst (renamed from Documentation/arm/keystone/overview.rst)0
-rw-r--r--Documentation/arch/arm/marvell.rst (renamed from Documentation/arm/marvell.rst)12
-rw-r--r--Documentation/arch/arm/mem_alignment.rst (renamed from Documentation/arm/mem_alignment.rst)2
-rw-r--r--Documentation/arch/arm/memory.rst (renamed from Documentation/arm/memory.rst)0
-rw-r--r--Documentation/arch/arm/microchip.rst (renamed from Documentation/arm/microchip.rst)0
-rw-r--r--Documentation/arch/arm/netwinder.rst (renamed from Documentation/arm/netwinder.rst)0
-rw-r--r--Documentation/arch/arm/nwfpe/index.rst (renamed from Documentation/arm/nwfpe/index.rst)0
-rw-r--r--Documentation/arch/arm/nwfpe/netwinder-fpe.rst (renamed from Documentation/arm/nwfpe/netwinder-fpe.rst)0
-rw-r--r--Documentation/arch/arm/nwfpe/notes.rst (renamed from Documentation/arm/nwfpe/notes.rst)0
-rw-r--r--Documentation/arch/arm/nwfpe/nwfpe.rst (renamed from Documentation/arm/nwfpe/nwfpe.rst)0
-rw-r--r--Documentation/arch/arm/nwfpe/todo.rst (renamed from Documentation/arm/nwfpe/todo.rst)0
-rw-r--r--Documentation/arch/arm/omap/dss.rst (renamed from Documentation/arm/omap/dss.rst)0
-rw-r--r--Documentation/arch/arm/omap/index.rst (renamed from Documentation/arm/omap/index.rst)0
-rw-r--r--Documentation/arch/arm/omap/omap.rst (renamed from Documentation/arm/omap/omap.rst)0
-rw-r--r--Documentation/arch/arm/omap/omap_pm.rst (renamed from Documentation/arm/omap/omap_pm.rst)0
-rw-r--r--Documentation/arch/arm/porting.rst (renamed from Documentation/arm/porting.rst)0
-rw-r--r--Documentation/arch/arm/pxa/mfp.rst (renamed from Documentation/arm/pxa/mfp.rst)0
-rw-r--r--Documentation/arch/arm/sa1100/assabet.rst (renamed from Documentation/arm/sa1100/assabet.rst)0
-rw-r--r--Documentation/arch/arm/sa1100/cerf.rst (renamed from Documentation/arm/sa1100/cerf.rst)0
-rw-r--r--Documentation/arch/arm/sa1100/index.rst (renamed from Documentation/arm/sa1100/index.rst)0
-rw-r--r--Documentation/arch/arm/sa1100/lart.rst (renamed from Documentation/arm/sa1100/lart.rst)0
-rw-r--r--Documentation/arch/arm/sa1100/serial_uart.rst (renamed from Documentation/arm/sa1100/serial_uart.rst)0
-rw-r--r--Documentation/arch/arm/samsung/bootloader-interface.rst (renamed from Documentation/arm/samsung/bootloader-interface.rst)0
-rwxr-xr-xDocumentation/arch/arm/samsung/clksrc-change-registers.awk (renamed from Documentation/arm/samsung/clksrc-change-registers.awk)0
-rw-r--r--Documentation/arch/arm/samsung/gpio.rst32
-rw-r--r--Documentation/arch/arm/samsung/index.rst (renamed from Documentation/arm/samsung/index.rst)0
-rw-r--r--Documentation/arch/arm/samsung/overview.rst76
-rw-r--r--Documentation/arch/arm/setup.rst (renamed from Documentation/arm/setup.rst)0
-rw-r--r--Documentation/arch/arm/spear/overview.rst (renamed from Documentation/arm/spear/overview.rst)0
-rw-r--r--Documentation/arch/arm/sti/overview.rst32
-rw-r--r--Documentation/arch/arm/sti/stih407-overview.rst (renamed from Documentation/arm/sti/stih407-overview.rst)0
-rw-r--r--Documentation/arch/arm/sti/stih418-overview.rst (renamed from Documentation/arm/sti/stih418-overview.rst)0
-rw-r--r--Documentation/arch/arm/stm32/overview.rst (renamed from Documentation/arm/stm32/overview.rst)0
-rw-r--r--Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst415
-rw-r--r--Documentation/arch/arm/stm32/stm32f429-overview.rst (renamed from Documentation/arm/stm32/stm32f429-overview.rst)0
-rw-r--r--Documentation/arch/arm/stm32/stm32f746-overview.rst (renamed from Documentation/arm/stm32/stm32f746-overview.rst)2
-rw-r--r--Documentation/arch/arm/stm32/stm32f769-overview.rst (renamed from Documentation/arm/stm32/stm32f769-overview.rst)2
-rw-r--r--Documentation/arch/arm/stm32/stm32h743-overview.rst (renamed from Documentation/arm/stm32/stm32h743-overview.rst)2
-rw-r--r--Documentation/arch/arm/stm32/stm32h750-overview.rst (renamed from Documentation/arm/stm32/stm32h750-overview.rst)2
-rw-r--r--Documentation/arch/arm/stm32/stm32mp13-overview.rst (renamed from Documentation/arm/stm32/stm32mp13-overview.rst)2
-rw-r--r--Documentation/arch/arm/stm32/stm32mp151-overview.rst36
-rw-r--r--Documentation/arch/arm/stm32/stm32mp157-overview.rst (renamed from Documentation/arm/stm32/stm32mp157-overview.rst)0
-rw-r--r--Documentation/arch/arm/sunxi.rst (renamed from Documentation/arm/sunxi.rst)0
-rw-r--r--Documentation/arch/arm/sunxi/clocks.rst (renamed from Documentation/arm/sunxi/clocks.rst)2
-rw-r--r--Documentation/arch/arm/swp_emulation.rst (renamed from Documentation/arm/swp_emulation.rst)2
-rw-r--r--Documentation/arch/arm/tcm.rst (renamed from Documentation/arm/tcm.rst)2
-rw-r--r--Documentation/arch/arm/uefi.rst72
-rw-r--r--Documentation/arch/arm/vfp/release-notes.rst (renamed from Documentation/arm/vfp/release-notes.rst)0
-rw-r--r--Documentation/arch/arm/vlocks.rst (renamed from Documentation/arm/vlocks.rst)2
-rw-r--r--Documentation/arch/arm64/acpi_object_usage.rst (renamed from Documentation/arm64/acpi_object_usage.rst)83
-rw-r--r--Documentation/arch/arm64/amu.rst119
-rw-r--r--Documentation/arch/arm64/arm-acpi.rst (renamed from Documentation/arm64/arm-acpi.rst)175
-rw-r--r--Documentation/arch/arm64/arm-cca.rst69
-rw-r--r--Documentation/arch/arm64/asymmetric-32bit.rst (renamed from Documentation/arm64/asymmetric-32bit.rst)10
-rw-r--r--Documentation/arch/arm64/booting.rst608
-rw-r--r--Documentation/arch/arm64/cpu-feature-registers.rst (renamed from Documentation/arm64/cpu-feature-registers.rst)69
-rw-r--r--Documentation/arch/arm64/cpu-hotplug.rst79
-rw-r--r--Documentation/arch/arm64/elf_hwcaps.rst452
-rw-r--r--Documentation/arch/arm64/features.rst3
-rw-r--r--Documentation/arch/arm64/gcs.rst227
-rw-r--r--Documentation/arch/arm64/hugetlbpage.rst (renamed from Documentation/arm64/hugetlbpage.rst)0
-rw-r--r--Documentation/arch/arm64/index.rst42
-rw-r--r--Documentation/arch/arm64/kasan-offsets.sh (renamed from Documentation/arm64/kasan-offsets.sh)0
-rw-r--r--Documentation/arch/arm64/kdump.rst92
-rw-r--r--Documentation/arch/arm64/legacy_instructions.rst (renamed from Documentation/arm64/legacy_instructions.rst)0
-rw-r--r--Documentation/arch/arm64/memory-tagging-extension.rst (renamed from Documentation/arm64/memory-tagging-extension.rst)2
-rw-r--r--Documentation/arch/arm64/memory.rst100
-rw-r--r--Documentation/arch/arm64/mops.rst44
-rw-r--r--Documentation/arch/arm64/perf.rst238
-rw-r--r--Documentation/arch/arm64/pointer-authentication.rst (renamed from Documentation/arm64/pointer-authentication.rst)0
-rw-r--r--Documentation/arch/arm64/ptdump.rst94
-rw-r--r--Documentation/arch/arm64/silicon-errata.rst307
-rw-r--r--Documentation/arch/arm64/sme.rst (renamed from Documentation/arm64/sme.rst)96
-rw-r--r--Documentation/arch/arm64/sve.rst (renamed from Documentation/arm64/sve.rst)26
-rw-r--r--Documentation/arch/arm64/tagged-address-abi.rst (renamed from Documentation/arm64/tagged-address-abi.rst)2
-rw-r--r--Documentation/arch/arm64/tagged-pointers.rst (renamed from Documentation/arm64/tagged-pointers.rst)13
-rw-r--r--Documentation/arch/index.rst27
-rw-r--r--Documentation/arch/loongarch/booting.rst42
-rw-r--r--Documentation/arch/loongarch/features.rst3
-rw-r--r--Documentation/arch/loongarch/index.rst22
-rw-r--r--Documentation/arch/loongarch/introduction.rst390
-rw-r--r--Documentation/arch/loongarch/irq-chip-model.rst256
-rw-r--r--Documentation/arch/m68k/buddha-driver.rst (renamed from Documentation/m68k/buddha-driver.rst)2
-rw-r--r--Documentation/arch/m68k/features.rst3
-rw-r--r--Documentation/arch/m68k/index.rst (renamed from Documentation/m68k/index.rst)0
-rw-r--r--Documentation/arch/m68k/kernel-options.rst (renamed from Documentation/m68k/kernel-options.rst)0
-rw-r--r--Documentation/arch/mips/booting.rst (renamed from Documentation/mips/booting.rst)0
-rw-r--r--Documentation/arch/mips/features.rst3
-rw-r--r--Documentation/arch/mips/index.rst (renamed from Documentation/mips/index.rst)0
-rw-r--r--Documentation/arch/mips/ingenic-tcu.rst (renamed from Documentation/mips/ingenic-tcu.rst)0
-rw-r--r--Documentation/arch/nios2/features.rst3
-rw-r--r--Documentation/arch/nios2/index.rst (renamed from Documentation/nios2/index.rst)0
-rw-r--r--Documentation/arch/nios2/nios2.rst (renamed from Documentation/nios2/nios2.rst)0
-rw-r--r--Documentation/arch/openrisc/features.rst3
-rw-r--r--Documentation/arch/openrisc/index.rst (renamed from Documentation/openrisc/index.rst)0
-rw-r--r--Documentation/arch/openrisc/openrisc_port.rst127
-rw-r--r--Documentation/arch/openrisc/todo.rst (renamed from Documentation/openrisc/todo.rst)0
-rw-r--r--Documentation/arch/parisc/debugging.rst (renamed from Documentation/parisc/debugging.rst)0
-rw-r--r--Documentation/arch/parisc/features.rst3
-rw-r--r--Documentation/arch/parisc/index.rst (renamed from Documentation/parisc/index.rst)0
-rw-r--r--Documentation/arch/parisc/registers.rst (renamed from Documentation/parisc/registers.rst)0
-rw-r--r--Documentation/arch/powerpc/associativity.rst (renamed from Documentation/powerpc/associativity.rst)0
-rw-r--r--Documentation/arch/powerpc/booting.rst110
-rw-r--r--Documentation/arch/powerpc/bootwrapper.rst (renamed from Documentation/powerpc/bootwrapper.rst)0
-rw-r--r--Documentation/arch/powerpc/cpu_families.rst (renamed from Documentation/powerpc/cpu_families.rst)31
-rw-r--r--Documentation/arch/powerpc/cpu_features.rst (renamed from Documentation/powerpc/cpu_features.rst)0
-rw-r--r--Documentation/arch/powerpc/dawr-power9.rst (renamed from Documentation/powerpc/dawr-power9.rst)0
-rw-r--r--Documentation/arch/powerpc/dexcr.rst195
-rw-r--r--Documentation/arch/powerpc/dscr.rst (renamed from Documentation/powerpc/dscr.rst)2
-rw-r--r--Documentation/arch/powerpc/eeh-pci-error-recovery.rst (renamed from Documentation/powerpc/eeh-pci-error-recovery.rst)1
-rw-r--r--Documentation/arch/powerpc/elf_hwcaps.rst232
-rw-r--r--Documentation/arch/powerpc/elfnote.rst (renamed from Documentation/powerpc/elfnote.rst)0
-rw-r--r--Documentation/arch/powerpc/features.rst3
-rw-r--r--Documentation/arch/powerpc/firmware-assisted-dump.rst (renamed from Documentation/powerpc/firmware-assisted-dump.rst)113
-rw-r--r--Documentation/arch/powerpc/htm.rst104
-rw-r--r--Documentation/arch/powerpc/hvcs.rst (renamed from Documentation/powerpc/hvcs.rst)0
-rw-r--r--Documentation/arch/powerpc/imc.rst (renamed from Documentation/powerpc/imc.rst)0
-rw-r--r--Documentation/arch/powerpc/index.rst49
-rw-r--r--Documentation/arch/powerpc/isa-versions.rst101
-rw-r--r--Documentation/arch/powerpc/kasan.txt (renamed from Documentation/powerpc/kasan.txt)2
-rw-r--r--Documentation/arch/powerpc/kaslr-booke32.rst (renamed from Documentation/powerpc/kaslr-booke32.rst)0
-rw-r--r--Documentation/arch/powerpc/kvm-nested.rst656
-rw-r--r--Documentation/arch/powerpc/mpc52xx.rst (renamed from Documentation/powerpc/mpc52xx.rst)0
-rw-r--r--Documentation/arch/powerpc/papr_hcalls.rst (renamed from Documentation/powerpc/papr_hcalls.rst)13
-rw-r--r--Documentation/arch/powerpc/pci_iov_resource_on_powernv.rst (renamed from Documentation/powerpc/pci_iov_resource_on_powernv.rst)0
-rw-r--r--Documentation/arch/powerpc/pmu-ebb.rst (renamed from Documentation/powerpc/pmu-ebb.rst)0
-rw-r--r--Documentation/arch/powerpc/ptrace.rst (renamed from Documentation/powerpc/ptrace.rst)8
-rw-r--r--Documentation/arch/powerpc/qe_firmware.rst (renamed from Documentation/powerpc/qe_firmware.rst)4
-rw-r--r--Documentation/arch/powerpc/syscall64-abi.rst (renamed from Documentation/powerpc/syscall64-abi.rst)0
-rw-r--r--Documentation/arch/powerpc/transactional_memory.rst (renamed from Documentation/powerpc/transactional_memory.rst)0
-rw-r--r--Documentation/arch/powerpc/ultravisor.rst (renamed from Documentation/powerpc/ultravisor.rst)2
-rw-r--r--Documentation/arch/powerpc/vas-api.rst (renamed from Documentation/powerpc/vas-api.rst)4
-rw-r--r--Documentation/arch/powerpc/vcpudispatch_stats.rst (renamed from Documentation/powerpc/vcpudispatch_stats.rst)0
-rw-r--r--Documentation/arch/powerpc/vmemmap_dedup.rst101
-rw-r--r--Documentation/arch/powerpc/vpa-dtl.rst156
-rw-r--r--Documentation/arch/riscv/acpi.rst10
-rw-r--r--Documentation/arch/riscv/boot-image-header.rst59
-rw-r--r--Documentation/arch/riscv/boot.rst169
-rw-r--r--Documentation/arch/riscv/cmodx.rst130
-rw-r--r--Documentation/arch/riscv/features.rst3
-rw-r--r--Documentation/arch/riscv/hwprobe.rst381
-rw-r--r--Documentation/arch/riscv/index.rst25
-rw-r--r--Documentation/arch/riscv/patch-acceptance.rst59
-rw-r--r--Documentation/arch/riscv/uabi.rst86
-rw-r--r--Documentation/arch/riscv/vector.rst140
-rw-r--r--Documentation/arch/riscv/vm-layout.rst136
-rw-r--r--Documentation/arch/s390/3270.ChangeLog (renamed from Documentation/s390/3270.ChangeLog)0
-rw-r--r--Documentation/arch/s390/3270.rst (renamed from Documentation/s390/3270.rst)4
-rw-r--r--Documentation/arch/s390/cds.rst (renamed from Documentation/s390/cds.rst)2
-rw-r--r--Documentation/arch/s390/common_io.rst (renamed from Documentation/s390/common_io.rst)2
-rw-r--r--Documentation/arch/s390/config3270.sh (renamed from Documentation/s390/config3270.sh)0
-rw-r--r--Documentation/arch/s390/driver-model.rst (renamed from Documentation/s390/driver-model.rst)23
-rw-r--r--Documentation/arch/s390/features.rst3
-rw-r--r--Documentation/arch/s390/index.rst31
-rw-r--r--Documentation/arch/s390/mm.rst111
-rw-r--r--Documentation/arch/s390/monreader.rst (renamed from Documentation/s390/monreader.rst)0
-rw-r--r--Documentation/arch/s390/pci.rst (renamed from Documentation/s390/pci.rst)6
-rw-r--r--Documentation/arch/s390/qeth.rst (renamed from Documentation/s390/qeth.rst)0
-rw-r--r--Documentation/arch/s390/s390dbf.rst (renamed from Documentation/s390/s390dbf.rst)5
-rw-r--r--Documentation/arch/s390/text_files.rst (renamed from Documentation/s390/text_files.rst)0
-rw-r--r--Documentation/arch/s390/vfio-ap-locking.rst (renamed from Documentation/s390/vfio-ap-locking.rst)0
-rw-r--r--Documentation/arch/s390/vfio-ap.rst (renamed from Documentation/s390/vfio-ap.rst)68
-rw-r--r--Documentation/arch/s390/vfio-ccw.rst (renamed from Documentation/s390/vfio-ccw.rst)10
-rw-r--r--Documentation/arch/s390/zfcpdump.rst (renamed from Documentation/s390/zfcpdump.rst)0
-rw-r--r--Documentation/arch/sh/booting.rst (renamed from Documentation/sh/booting.rst)0
-rw-r--r--Documentation/arch/sh/features.rst3
-rw-r--r--Documentation/arch/sh/index.rst50
-rw-r--r--Documentation/arch/sh/new-machine.rst (renamed from Documentation/sh/new-machine.rst)0
-rw-r--r--Documentation/arch/sh/register-banks.rst (renamed from Documentation/sh/register-banks.rst)0
-rw-r--r--Documentation/arch/sparc/adi.rst (renamed from Documentation/sparc/adi.rst)4
-rw-r--r--Documentation/arch/sparc/console.rst (renamed from Documentation/sparc/console.rst)0
-rw-r--r--Documentation/arch/sparc/features.rst3
-rw-r--r--Documentation/arch/sparc/index.rst (renamed from Documentation/sparc/index.rst)0
-rw-r--r--Documentation/arch/sparc/oradax/dax-hv-api.txt (renamed from Documentation/sparc/oradax/dax-hv-api.txt)46
-rw-r--r--Documentation/arch/sparc/oradax/oracle-dax.rst (renamed from Documentation/sparc/oradax/oracle-dax.rst)0
-rw-r--r--Documentation/arch/x86/amd-debugging.rst368
-rw-r--r--Documentation/arch/x86/amd-hfi.rst133
-rw-r--r--Documentation/arch/x86/amd-memory-encryption.rst278
-rw-r--r--Documentation/arch/x86/amd_hsmp.rst192
-rw-r--r--Documentation/arch/x86/boot.rst1464
-rw-r--r--Documentation/arch/x86/booting-dt.rst (renamed from Documentation/x86/booting-dt.rst)2
-rw-r--r--Documentation/arch/x86/buslock.rst (renamed from Documentation/x86/buslock.rst)15
-rw-r--r--Documentation/arch/x86/cpuinfo.rst202
-rw-r--r--Documentation/arch/x86/earlyprintk.rst (renamed from Documentation/x86/earlyprintk.rst)0
-rw-r--r--Documentation/arch/x86/elf_auxvec.rst (renamed from Documentation/x86/elf_auxvec.rst)0
-rw-r--r--Documentation/arch/x86/entry_64.rst (renamed from Documentation/x86/entry_64.rst)0
-rw-r--r--Documentation/arch/x86/exception-tables.rst (renamed from Documentation/x86/exception-tables.rst)2
-rw-r--r--Documentation/arch/x86/features.rst3
-rw-r--r--Documentation/arch/x86/i386/IO-APIC.rst (renamed from Documentation/x86/i386/IO-APIC.rst)0
-rw-r--r--Documentation/arch/x86/i386/index.rst (renamed from Documentation/x86/i386/index.rst)0
-rw-r--r--Documentation/arch/x86/ifs.rst (renamed from Documentation/x86/ifs.rst)0
-rw-r--r--Documentation/arch/x86/index.rst46
-rw-r--r--Documentation/arch/x86/intel-hfi.rst (renamed from Documentation/x86/intel-hfi.rst)0
-rw-r--r--Documentation/arch/x86/intel_txt.rst (renamed from Documentation/x86/intel_txt.rst)0
-rw-r--r--Documentation/arch/x86/iommu.rst151
-rw-r--r--Documentation/arch/x86/kernel-stacks.rst (renamed from Documentation/x86/kernel-stacks.rst)2
-rw-r--r--Documentation/arch/x86/mds.rst (renamed from Documentation/x86/mds.rst)48
-rw-r--r--Documentation/arch/x86/microcode.rst (renamed from Documentation/x86/microcode.rst)0
-rw-r--r--Documentation/arch/x86/mtrr.rst (renamed from Documentation/x86/mtrr.rst)2
-rw-r--r--Documentation/arch/x86/orc-unwinder.rst (renamed from Documentation/x86/orc-unwinder.rst)0
-rw-r--r--Documentation/arch/x86/pat.rst (renamed from Documentation/x86/pat.rst)0
-rw-r--r--Documentation/arch/x86/pti.rst (renamed from Documentation/x86/pti.rst)16
-rw-r--r--Documentation/arch/x86/resume.svg4
-rw-r--r--Documentation/arch/x86/sgx.rst (renamed from Documentation/x86/sgx.rst)2
-rw-r--r--Documentation/arch/x86/shstk.rst179
-rw-r--r--Documentation/arch/x86/suspend.svg4
-rw-r--r--Documentation/arch/x86/sva.rst (renamed from Documentation/x86/sva.rst)6
-rw-r--r--Documentation/arch/x86/tdx.rst446
-rw-r--r--Documentation/arch/x86/tlb.rst (renamed from Documentation/x86/tlb.rst)0
-rw-r--r--Documentation/arch/x86/topology.rst421
-rw-r--r--Documentation/arch/x86/tsx_async_abort.rst (renamed from Documentation/x86/tsx_async_abort.rst)0
-rw-r--r--Documentation/arch/x86/usb-legacy-support.rst (renamed from Documentation/x86/usb-legacy-support.rst)11
-rw-r--r--Documentation/arch/x86/x86_64/5level-paging.rst (renamed from Documentation/x86/x86_64/5level-paging.rst)11
-rw-r--r--Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst (renamed from Documentation/x86/x86_64/cpu-hotplug-spec.rst)0
-rw-r--r--Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst (renamed from Documentation/x86/x86_64/fake-numa-for-cpusets.rst)2
-rw-r--r--Documentation/arch/x86/x86_64/fred.rst96
-rw-r--r--Documentation/arch/x86/x86_64/fsgs.rst (renamed from Documentation/x86/x86_64/fsgs.rst)6
-rw-r--r--Documentation/arch/x86/x86_64/index.rst17
-rw-r--r--Documentation/arch/x86/x86_64/machinecheck.rst (renamed from Documentation/x86/x86_64/machinecheck.rst)0
-rw-r--r--Documentation/arch/x86/x86_64/mm.rst180
-rw-r--r--Documentation/arch/x86/x86_64/uefi.rst75
-rw-r--r--Documentation/arch/x86/xstate.rst174
-rw-r--r--Documentation/arch/x86/zero-page.rst (renamed from Documentation/x86/zero-page.rst)0
-rw-r--r--Documentation/arch/xtensa/atomctl.rst (renamed from Documentation/xtensa/atomctl.rst)2
-rw-r--r--Documentation/arch/xtensa/booting.rst (renamed from Documentation/xtensa/booting.rst)0
-rw-r--r--Documentation/arch/xtensa/features.rst3
-rw-r--r--Documentation/arch/xtensa/index.rst (renamed from Documentation/xtensa/index.rst)0
-rw-r--r--Documentation/arch/xtensa/mmu.rst (renamed from Documentation/xtensa/mmu.rst)0
-rw-r--r--Documentation/arm/features.rst3
-rw-r--r--Documentation/arm/index.rst86
-rw-r--r--Documentation/arm/samsung-s3c24xx/cpufreq.rst77
-rw-r--r--Documentation/arm/samsung-s3c24xx/eb2410itx.rst59
-rw-r--r--Documentation/arm/samsung-s3c24xx/gpio.rst172
-rw-r--r--Documentation/arm/samsung-s3c24xx/h1940.rst41
-rw-r--r--Documentation/arm/samsung-s3c24xx/index.rst20
-rw-r--r--Documentation/arm/samsung-s3c24xx/nand.rst30
-rw-r--r--Documentation/arm/samsung-s3c24xx/overview.rst311
-rw-r--r--Documentation/arm/samsung-s3c24xx/s3c2412.rst121
-rw-r--r--Documentation/arm/samsung-s3c24xx/s3c2413.rst22
-rw-r--r--Documentation/arm/samsung-s3c24xx/smdk2440.rst57
-rw-r--r--Documentation/arm/samsung-s3c24xx/suspend.rst137
-rw-r--r--Documentation/arm/samsung-s3c24xx/usb-host.rst91
-rw-r--r--Documentation/arm/samsung/gpio.rst40
-rw-r--r--Documentation/arm/samsung/overview.rst89
-rw-r--r--Documentation/arm/sti/overview.rst36
-rw-r--r--Documentation/arm/sti/stih415-overview.rst14
-rw-r--r--Documentation/arm/sti/stih416-overview.rst13
-rw-r--r--Documentation/arm/uefi.rst74
-rw-r--r--Documentation/arm64/amu.rst119
-rw-r--r--Documentation/arm64/booting.rst412
-rw-r--r--Documentation/arm64/elf_hwcaps.rst282
-rw-r--r--Documentation/arm64/features.rst3
-rw-r--r--Documentation/arm64/index.rst36
-rw-r--r--Documentation/arm64/memory.rst167
-rw-r--r--Documentation/arm64/perf.rst166
-rw-r--r--Documentation/arm64/silicon-errata.rst207
-rw-r--r--Documentation/atomic_t.txt6
-rw-r--r--Documentation/block/bfq-iosched.rst22
-rw-r--r--Documentation/block/biovecs.rst1
-rw-r--r--Documentation/block/blk-mq.rst2
-rw-r--r--Documentation/block/capability.rst10
-rw-r--r--Documentation/block/cmdline-partition.rst5
-rw-r--r--Documentation/block/data-integrity.rst51
-rw-r--r--Documentation/block/index.rst2
-rw-r--r--Documentation/block/inline-encryption.rst270
-rw-r--r--Documentation/block/ioprio.rst16
-rw-r--r--Documentation/block/request.rst99
-rw-r--r--Documentation/block/ublk.rst244
-rw-r--r--Documentation/block/writeback_cache_control.rst67
-rw-r--r--Documentation/bpf/bpf_design_QA.rst69
-rw-r--r--Documentation/bpf/bpf_devel_QA.rst86
-rw-r--r--Documentation/bpf/bpf_iterators.rst589
-rw-r--r--Documentation/bpf/btf.rst189
-rw-r--r--Documentation/bpf/clang-notes.rst6
-rw-r--r--Documentation/bpf/cpumasks.rst384
-rw-r--r--Documentation/bpf/fs_kfuncs.rst21
-rw-r--r--Documentation/bpf/graph_ds_impl.rst267
-rw-r--r--Documentation/bpf/index.rst6
-rw-r--r--Documentation/bpf/instruction-set.rst328
-rw-r--r--Documentation/bpf/kfuncs.rst597
-rw-r--r--Documentation/bpf/libbpf/index.rst28
-rw-r--r--Documentation/bpf/libbpf/libbpf_naming_convention.rst6
-rw-r--r--Documentation/bpf/libbpf/libbpf_overview.rst236
-rw-r--r--Documentation/bpf/libbpf/program_types.rst253
-rw-r--r--Documentation/bpf/linux-notes.rst33
-rw-r--r--Documentation/bpf/llvm_reloc.rst328
-rw-r--r--Documentation/bpf/map_array.rst263
-rw-r--r--Documentation/bpf/map_bloom_filter.rst174
-rw-r--r--Documentation/bpf/map_cgrp_storage.rst109
-rw-r--r--Documentation/bpf/map_cpumap.rst177
-rw-r--r--Documentation/bpf/map_devmap.rst238
-rw-r--r--Documentation/bpf/map_hash.rst92
-rw-r--r--Documentation/bpf/map_lpm_trie.rst197
-rw-r--r--Documentation/bpf/map_lru_hash_update.dot172
-rw-r--r--Documentation/bpf/map_of_maps.rst130
-rw-r--r--Documentation/bpf/map_queue_stack.rst146
-rw-r--r--Documentation/bpf/map_sk_storage.rst159
-rw-r--r--Documentation/bpf/map_sockmap.rst498
-rw-r--r--Documentation/bpf/map_xskmap.rst192
-rw-r--r--Documentation/bpf/maps.rst102
-rw-r--r--Documentation/bpf/other.rst3
-rw-r--r--Documentation/bpf/prog_cgroup_sockopt.rst57
-rw-r--r--Documentation/bpf/prog_flow_dissector.rst2
-rw-r--r--Documentation/bpf/prog_lsm.rst2
-rw-r--r--Documentation/bpf/programs.rst3
-rw-r--r--Documentation/bpf/redirect.rst81
-rw-r--r--Documentation/bpf/ringbuf.rst4
-rw-r--r--Documentation/bpf/standardization/abi.rst28
-rw-r--r--Documentation/bpf/standardization/index.rst18
-rw-r--r--Documentation/bpf/standardization/instruction-set.rst790
-rw-r--r--Documentation/bpf/verifier.rst33
-rw-r--r--Documentation/cdrom/cdrom-standard.rst5
-rw-r--r--Documentation/cdrom/index.rst7
-rw-r--r--Documentation/cdrom/packet-writing.rst139
-rw-r--r--Documentation/conf.py813
-rw-r--r--Documentation/core-api/asm-annotations.rst2
-rw-r--r--Documentation/core-api/assoc_array.rst196
-rw-r--r--Documentation/core-api/cachetlb.rst55
-rw-r--r--Documentation/core-api/cgroup.rst9
-rw-r--r--Documentation/core-api/cleanup.rst8
-rw-r--r--Documentation/core-api/cpu_hotplug.rst51
-rw-r--r--Documentation/core-api/debugging-via-ohci1394.rst6
-rw-r--r--Documentation/core-api/dma-api-howto.rst64
-rw-r--r--Documentation/core-api/dma-api.rst274
-rw-r--r--Documentation/core-api/dma-attributes.rst18
-rw-r--r--Documentation/core-api/entry.rst8
-rw-r--r--Documentation/core-api/floating-point.rst78
-rw-r--r--Documentation/core-api/folio_queue.rst209
-rw-r--r--Documentation/core-api/genericirq.rst4
-rw-r--r--Documentation/core-api/gfp_mask-from-fs-io.rst20
-rw-r--r--Documentation/core-api/index.rst14
-rw-r--r--Documentation/core-api/irq/concepts.rst27
-rw-r--r--Documentation/core-api/irq/irq-affinity.rst6
-rw-r--r--Documentation/core-api/irq/irq-domain.rst235
-rw-r--r--Documentation/core-api/kernel-api.rst84
-rw-r--r--Documentation/core-api/kho/bindings/kho.yaml43
-rw-r--r--Documentation/core-api/kho/bindings/memblock/memblock.yaml39
-rw-r--r--Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml40
-rw-r--r--Documentation/core-api/kho/bindings/sub-fdt.yaml27
-rw-r--r--Documentation/core-api/kho/concepts.rst74
-rw-r--r--Documentation/core-api/kho/fdt.rst80
-rw-r--r--Documentation/core-api/kho/index.rst13
-rw-r--r--Documentation/core-api/kref.rst7
-rw-r--r--Documentation/core-api/list.rst776
-rw-r--r--Documentation/core-api/liveupdate.rst61
-rw-r--r--Documentation/core-api/local_ops.rst2
-rw-r--r--Documentation/core-api/maple_tree.rst221
-rw-r--r--Documentation/core-api/memory-allocation.rst28
-rw-r--r--Documentation/core-api/memory-hotplug.rst91
-rw-r--r--Documentation/core-api/min_heap.rst302
-rw-r--r--Documentation/core-api/mm-api.rst34
-rw-r--r--Documentation/core-api/netlink.rst102
-rw-r--r--Documentation/core-api/packing.rst189
-rw-r--r--Documentation/core-api/padata.rst2
-rw-r--r--Documentation/core-api/parser.rst17
-rw-r--r--Documentation/core-api/pin_user_pages.rst57
-rw-r--r--Documentation/core-api/printk-formats.rst95
-rw-r--r--Documentation/core-api/printk-index.rst4
-rw-r--r--Documentation/core-api/protection-keys.rst38
-rw-r--r--Documentation/core-api/real-time/architecture-porting.rst109
-rw-r--r--Documentation/core-api/real-time/differences.rst242
-rw-r--r--Documentation/core-api/real-time/index.rst16
-rw-r--r--Documentation/core-api/real-time/theory.rst116
-rw-r--r--Documentation/core-api/refcount-vs-atomic.rst37
-rw-r--r--Documentation/core-api/swiotlb.rst321
-rw-r--r--Documentation/core-api/symbol-namespaces.rst83
-rw-r--r--Documentation/core-api/this_cpu_ops.rst24
-rw-r--r--Documentation/core-api/unaligned-memory-access.rst2
-rw-r--r--Documentation/core-api/union_find.rst106
-rw-r--r--Documentation/core-api/workqueue.rst438
-rw-r--r--Documentation/core-api/xarray.rst38
-rw-r--r--Documentation/cpu-freq/cpu-drivers.rst3
-rw-r--r--Documentation/cpu-freq/index.rst15
-rw-r--r--Documentation/crypto/api-aead.rst3
-rw-r--r--Documentation/crypto/api-akcipher.rst7
-rw-r--r--Documentation/crypto/api-digest.rst3
-rw-r--r--Documentation/crypto/api-kpp.rst3
-rw-r--r--Documentation/crypto/api-rng.rst3
-rw-r--r--Documentation/crypto/api-sig.rst18
-rw-r--r--Documentation/crypto/api-skcipher.rst3
-rw-r--r--Documentation/crypto/api.rst6
-rw-r--r--Documentation/crypto/architecture.rst4
-rw-r--r--Documentation/crypto/async-tx-api.rst32
-rw-r--r--Documentation/crypto/crypto_engine.rst6
-rw-r--r--Documentation/crypto/devel-algos.rst6
-rw-r--r--Documentation/crypto/device_drivers/index.rst9
-rw-r--r--Documentation/crypto/device_drivers/octeontx2.rst25
-rw-r--r--Documentation/crypto/index.rst14
-rw-r--r--Documentation/crypto/krb5.rst262
-rw-r--r--Documentation/crypto/sha3.rst130
-rw-r--r--Documentation/crypto/userspace-if.rst22
-rw-r--r--Documentation/dev-tools/autofdo.rst168
-rw-r--r--Documentation/dev-tools/checkpatch.rst77
-rw-r--r--Documentation/dev-tools/checkuapi.rst477
-rw-r--r--Documentation/dev-tools/clang-format.rst (renamed from Documentation/process/clang-format.rst)0
-rw-r--r--Documentation/dev-tools/coccinelle.rst26
-rw-r--r--Documentation/dev-tools/gcov.rst13
-rw-r--r--Documentation/dev-tools/gdb-kernel-debugging.rst175
-rw-r--r--Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst93
-rw-r--r--Documentation/dev-tools/index.rst15
-rw-r--r--Documentation/dev-tools/kasan.rst117
-rw-r--r--Documentation/dev-tools/kcov.rst176
-rw-r--r--Documentation/dev-tools/kcsan.rst19
-rw-r--r--Documentation/dev-tools/kfence.rst7
-rw-r--r--Documentation/dev-tools/kmemleak.rst3
-rw-r--r--Documentation/dev-tools/kmsan.rst435
-rw-r--r--Documentation/dev-tools/kselftest.rst63
-rw-r--r--Documentation/dev-tools/ktap.rst9
-rw-r--r--Documentation/dev-tools/kunit/api/clk.rst10
-rw-r--r--Documentation/dev-tools/kunit/api/functionredirection.rst162
-rw-r--r--Documentation/dev-tools/kunit/api/index.rst34
-rw-r--r--Documentation/dev-tools/kunit/api/of.rst13
-rw-r--r--Documentation/dev-tools/kunit/api/platformdevice.rst10
-rw-r--r--Documentation/dev-tools/kunit/api/resource.rst9
-rw-r--r--Documentation/dev-tools/kunit/architecture.rst117
-rw-r--r--Documentation/dev-tools/kunit/index.rst20
-rw-r--r--Documentation/dev-tools/kunit/run_manual.rst57
-rw-r--r--Documentation/dev-tools/kunit/run_wrapper.rst29
-rw-r--r--Documentation/dev-tools/kunit/running_tips.rst184
-rw-r--r--Documentation/dev-tools/kunit/start.rst25
-rw-r--r--Documentation/dev-tools/kunit/style.rst29
-rw-r--r--Documentation/dev-tools/kunit/tips.rst190
-rw-r--r--Documentation/dev-tools/kunit/usage.rst595
-rw-r--r--Documentation/dev-tools/lkmm/docs/access-marking.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/cheatsheet.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/control-dependencies.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/explanation.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/glossary.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/herd-representation.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/index.rst21
-rw-r--r--Documentation/dev-tools/lkmm/docs/litmus-tests.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/locking.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/ordering.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/readme.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/recipes.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/references.rst11
-rw-r--r--Documentation/dev-tools/lkmm/docs/simple.rst11
-rw-r--r--Documentation/dev-tools/lkmm/index.rst15
-rw-r--r--Documentation/dev-tools/lkmm/readme.rst11
-rw-r--r--Documentation/dev-tools/propeller.rst162
-rw-r--r--Documentation/dev-tools/testing-devices.rst47
-rw-r--r--Documentation/dev-tools/testing-overview.rst2
-rw-r--r--Documentation/dev-tools/ubsan.rst34
-rw-r--r--Documentation/devicetree/bindings/.gitignore5
-rw-r--r--Documentation/devicetree/bindings/.yamllint9
-rw-r--r--Documentation/devicetree/bindings/Makefile49
-rw-r--r--Documentation/devicetree/bindings/access-controllers/access-controllers.yaml84
-rw-r--r--Documentation/devicetree/bindings/arc/archs-pct.txt17
-rw-r--r--Documentation/devicetree/bindings/arc/snps,archs-pct.yaml33
-rw-r--r--Documentation/devicetree/bindings/arm/actions.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/airoha,en7581-chip-scu.yaml42
-rw-r--r--Documentation/devicetree/bindings/arm/airoha.yaml6
-rw-r--r--Documentation/devicetree/bindings/arm/altera.yaml26
-rw-r--r--Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml102
-rw-r--r--Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt12
-rw-r--r--Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt15
-rw-r--r--Documentation/devicetree/bindings/arm/altera/socfpga-system.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/amazon,al.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/amd,pensando.yaml26
-rw-r--r--Documentation/devicetree/bindings/arm/amd,seattle.yaml24
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic.yaml100
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml23
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/analog-top.txt20
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/assist.txt17
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/bootrom.txt17
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/pmu.txt18
-rw-r--r--Documentation/devicetree/bindings/arm/apm.yaml28
-rw-r--r--Documentation/devicetree/bindings/arm/apm/scu.txt17
-rw-r--r--Documentation/devicetree/bindings/arm/apple.yaml271
-rw-r--r--Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml27
-rw-r--r--Documentation/devicetree/bindings/arm/arm,cci-400.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml3
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml61
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml77
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml81
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml39
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml3
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml36
-rw-r--r--Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/arm,corstone1000.yaml6
-rw-r--r--Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml15
-rw-r--r--Documentation/devicetree/bindings/arm/arm,integrator.yaml41
-rw-r--r--Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml61
-rw-r--r--Documentation/devicetree/bindings/arm/arm,morello.yaml35
-rw-r--r--Documentation/devicetree/bindings/arm/arm,realview.yaml45
-rw-r--r--Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml19
-rw-r--r--Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml35
-rw-r--r--Documentation/devicetree/bindings/arm/arm,versatile.yaml42
-rw-r--r--Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml22
-rw-r--r--Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml30
-rw-r--r--Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml49
-rw-r--r--Documentation/devicetree/bindings/arm/atmel-at91.yaml67
-rw-r--r--Documentation/devicetree/bindings/arm/atmel-sysregs.txt167
-rw-r--r--Documentation/devicetree/bindings/arm/axiado.yaml23
-rw-r--r--Documentation/devicetree/bindings/arm/axis.txt29
-rw-r--r--Documentation/devicetree/bindings/arm/axis.yaml36
-rw-r--r--Documentation/devicetree/bindings/arm/axxia.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml9
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml22
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml39
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml59
-rw-r--r--Documentation/devicetree/bindings/arm/bitmain.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/blaize.yaml40
-rw-r--r--Documentation/devicetree/bindings/arm/bst.yaml31
-rw-r--r--Documentation/devicetree/bindings/arm/calxeda.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/cavium,thunder-88xx.yaml19
-rw-r--r--Documentation/devicetree/bindings/arm/cavium-thunder.txt10
-rw-r--r--Documentation/devicetree/bindings/arm/cavium-thunder2.txt8
-rw-r--r--Documentation/devicetree/bindings/arm/cci-control-port.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml38
-rw-r--r--Documentation/devicetree/bindings/arm/cix.yaml26
-rw-r--r--Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp10
-rw-r--r--Documentation/devicetree/bindings/arm/cpus.yaml336
-rw-r--r--Documentation/devicetree/bindings/arm/digicolor.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml5
-rw-r--r--Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml41
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml8
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt14
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt30
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/m4if.txt12
-rw-r--r--Documentation/devicetree/bindings/arm/freescale/tigerp.txt12
-rw-r--r--Documentation/devicetree/bindings/arm/fsl.yaml625
-rw-r--r--Documentation/devicetree/bindings/arm/google.yaml54
-rw-r--r--Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml20
-rw-r--r--Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.yaml17
-rw-r--r--Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/intel,keembay.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/intel,socfpga.yaml15
-rw-r--r--Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml20
-rw-r--r--Documentation/devicetree/bindings/arm/keystone/keystone.txt42
-rw-r--r--Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml19
-rw-r--r--Documentation/devicetree/bindings/arm/lge.yaml28
-rw-r--r--Documentation/devicetree/bindings/arm/marvell,berlin.yaml45
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/98dx3236.txt23
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt185
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt24
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-375.txt9
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt32
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-38x.txt27
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml70
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-39x.txt31
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml67
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt15
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt234
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/kirkwood.txt27
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,armada-370-xp.yaml78
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,armada375.yaml21
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,armada390.yaml32
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt22
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,dove.yaml35
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt105
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.yaml266
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.yaml37
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek.yaml316
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt39
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml167
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt24
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt24
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt28
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt26
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt30
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt22
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt43
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt22
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt23
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt28
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml57
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml58
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt25
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt27
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt29
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt22
-rw-r--r--Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt26
-rw-r--r--Documentation/devicetree/bindings/arm/microchip,sparx5.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/moxart.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/mrvl/feroceon.txt16
-rw-r--r--Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/mrvl/tauros2.txt17
-rw-r--r--Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt84
-rw-r--r--Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt49
-rw-r--r--Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt44
-rw-r--r--Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml64
-rw-r--r--Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt58
-rw-r--r--Documentation/devicetree/bindings/arm/msm/ssbi.txt18
-rw-r--r--Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/mstar/mstar.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/npcm/npcm.yaml36
-rw-r--r--Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml50
-rw-r--r--Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml30
-rw-r--r--Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml36
-rw-r--r--Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml8
-rw-r--r--Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/omap/ctrl.txt2
-rw-r--r--Documentation/devicetree/bindings/arm/omap/omap.txt99
-rw-r--r--Documentation/devicetree/bindings/arm/oxnas.txt14
-rw-r--r--Documentation/devicetree/bindings/arm/pmu.yaml22
-rw-r--r--Documentation/devicetree/bindings/arm/psci.yaml45
-rw-r--r--Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml88
-rw-r--r--Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml55
-rw-r--r--Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml113
-rw-r--r--Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml128
-rw-r--r--Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml167
-rw-r--r--Documentation/devicetree/bindings/arm/qcom-soc.yaml70
-rw-r--r--Documentation/devicetree/bindings/arm/qcom.yaml695
-rw-r--r--Documentation/devicetree/bindings/arm/rda.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/realtek.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/renesas.yaml471
-rw-r--r--Documentation/devicetree/bindings/arm/rockchip.yaml619
-rw-r--r--Documentation/devicetree/bindings/arm/rockchip/pmu.yaml16
-rw-r--r--Documentation/devicetree/bindings/arm/rtsm-dcscb.txt19
-rw-r--r--Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml58
-rw-r--r--Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/socionext/synquacer.yaml28
-rw-r--r--Documentation/devicetree/bindings/arm/socionext/uniphier.yaml8
-rw-r--r--Documentation/devicetree/bindings/arm/sp810.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/spear-misc.txt9
-rw-r--r--Documentation/devicetree/bindings/arm/spear.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/sprd/sprd.yaml7
-rw-r--r--Documentation/devicetree/bindings/arm/sti.yaml21
-rw-r--r--Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml29
-rw-r--r--Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml46
-rw-r--r--Documentation/devicetree/bindings/arm/stm32/stm32.yaml94
-rw-r--r--Documentation/devicetree/bindings/arm/sunxi.yaml192
-rw-r--r--Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/swir.txt12
-rw-r--r--Documentation/devicetree/bindings/arm/syna.txt101
-rw-r--r--Documentation/devicetree/bindings/arm/tegra.yaml123
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt21
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml9
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml59
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml4
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml10
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt17
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt18
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml389
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml6
-rw-r--r--Documentation/devicetree/bindings/arm/tesla.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/ti/k3.yaml156
-rw-r--r--Documentation/devicetree/bindings/arm/ti/omap.yaml193
-rw-r--r--Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/ti/ti,keystone.yaml42
-rw-r--r--Documentation/devicetree/bindings/arm/toshiba.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/ux500.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/versatile-sysreg.txt10
-rw-r--r--Documentation/devicetree/bindings/arm/vexpress-config.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/vt8500.yaml12
-rw-r--r--Documentation/devicetree/bindings/arm/xen.txt2
-rw-r--r--Documentation/devicetree/bindings/arm/xilinx.yaml137
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-common.yaml8
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-da850.txt18
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-dm816.txt21
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt21
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-mtk.txt51
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-platform.yaml83
-rw-r--r--Documentation/devicetree/bindings/ata/ahci-st.txt35
-rw-r--r--Documentation/devicetree/bindings/ata/allwinner,sun4i-a10-ahci.yaml2
-rw-r--r--Documentation/devicetree/bindings/ata/allwinner,sun8i-r40-ahci.yaml2
-rw-r--r--Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml65
-rw-r--r--Documentation/devicetree/bindings/ata/apm-xgene.txt77
-rw-r--r--Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml70
-rw-r--r--Documentation/devicetree/bindings/ata/ata-generic.yaml58
-rw-r--r--Documentation/devicetree/bindings/ata/atmel-at91_cf.txt19
-rw-r--r--Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml1
-rw-r--r--Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml59
-rw-r--r--Documentation/devicetree/bindings/ata/cavium-compact-flash.txt30
-rw-r--r--Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml8
-rw-r--r--Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml42
-rw-r--r--Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml2
-rw-r--r--Documentation/devicetree/bindings/ata/eswin,eic7700-ahci.yaml79
-rw-r--r--Documentation/devicetree/bindings/ata/fsl,ahci.yaml64
-rw-r--r--Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml42
-rw-r--r--Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml60
-rw-r--r--Documentation/devicetree/bindings/ata/fsl-sata.txt28
-rw-r--r--Documentation/devicetree/bindings/ata/imx-pata.txt16
-rw-r--r--Documentation/devicetree/bindings/ata/imx-sata.yaml50
-rw-r--r--Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml1
-rw-r--r--Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml83
-rw-r--r--Documentation/devicetree/bindings/ata/marvell.txt22
-rw-r--r--Documentation/devicetree/bindings/ata/mediatek,mtk-ahci.yaml98
-rw-r--r--Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml2
-rw-r--r--Documentation/devicetree/bindings/ata/pata-arasan.txt37
-rw-r--r--Documentation/devicetree/bindings/ata/pata-common.yaml3
-rw-r--r--Documentation/devicetree/bindings/ata/qcom-sata.txt48
-rw-r--r--Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml4
-rw-r--r--Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml130
-rw-r--r--Documentation/devicetree/bindings/ata/sata_highbank.yaml3
-rw-r--r--Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml8
-rw-r--r--Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml17
-rw-r--r--Documentation/devicetree/bindings/ata/st,ahci.yaml72
-rw-r--r--Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml39
-rw-r--r--Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml43
-rw-r--r--Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml4
-rw-r--r--Documentation/devicetree/bindings/auxdisplay/gpio-7-segment.yaml55
-rw-r--r--Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml68
-rw-r--r--Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml59
-rw-r--r--Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml4
-rw-r--r--Documentation/devicetree/bindings/auxdisplay/maxim,max6959.yaml44
-rw-r--r--Documentation/devicetree/bindings/board/fsl,bcsr.yaml32
-rw-r--r--Documentation/devicetree/bindings/board/fsl,fpga-qixis-i2c.yaml128
-rw-r--r--Documentation/devicetree/bindings/board/fsl,fpga-qixis.yaml91
-rw-r--r--Documentation/devicetree/bindings/board/fsl-board.txt81
-rw-r--r--Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml5
-rw-r--r--Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml5
-rw-r--r--Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml37
-rw-r--r--Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml3
-rw-r--r--Documentation/devicetree/bindings/bus/cznic,moxtet.yaml94
-rw-r--r--Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml104
-rw-r--r--Documentation/devicetree/bindings/bus/fsl,imx8qxp-pixel-link-msi-bus.yaml232
-rw-r--r--Documentation/devicetree/bindings/bus/imx-weim.txt117
-rw-r--r--Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml168
-rw-r--r--Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml66
-rw-r--r--Documentation/devicetree/bindings/bus/moxtet.txt46
-rw-r--r--Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml9
-rw-r--r--Documentation/devicetree/bindings/bus/palmbus.yaml3
-rw-r--r--Documentation/devicetree/bindings/bus/qcom,ebi2.txt138
-rw-r--r--Documentation/devicetree/bindings/bus/qcom,ssbi.yaml63
-rw-r--r--Documentation/devicetree/bindings/bus/renesas,bsc.yaml12
-rw-r--r--Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml96
-rw-r--r--Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml109
-rw-r--r--Documentation/devicetree/bindings/bus/ti-sysc.yaml4
-rw-r--r--Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml82
-rw-r--r--Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml103
-rw-r--r--Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml (renamed from Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml)2
-rw-r--r--Documentation/devicetree/bindings/cache/freescale-l2cache.txt (renamed from Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt)0
-rw-r--r--Documentation/devicetree/bindings/cache/l2c2x0.yaml (renamed from Documentation/devicetree/bindings/arm/l2c2x0.yaml)7
-rw-r--r--Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml45
-rw-r--r--Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml39
-rw-r--r--Documentation/devicetree/bindings/cache/qcom,llcc.yaml319
-rw-r--r--Documentation/devicetree/bindings/cache/sifive,ccache0.yaml217
-rw-r--r--Documentation/devicetree/bindings/cache/socionext,uniphier-system-cache.yaml (renamed from Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml)3
-rw-r--r--Documentation/devicetree/bindings/cache/starfive,jh8100-starlink-cache.yaml66
-rw-r--r--Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml9
-rw-r--r--Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml35
-rw-r--r--Documentation/devicetree/bindings/clock/actions,owl-cmu.txt52
-rw-r--r--Documentation/devicetree/bindings/clock/actions,owl-cmu.yaml60
-rw-r--r--Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml28
-rw-r--r--Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml48
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ahb-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb0-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb1-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-axi-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-cpu-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-display-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml3
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mbus-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mmc-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod0-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod1-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll3-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll5-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll6-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-usb-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ve-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml136
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun5i-a13-ahb-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun6i-a31-pll6-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-gmac-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-out-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml3
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun8i-h3-bus-gates-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-ahb-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-apb0-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-cpus-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-de-clks.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-gt-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-mmc-config-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-pll4-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clks.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-mod-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-phy-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/alphascale,acc.txt114
-rw-r--r--Documentation/devicetree/bindings/clock/alphascale,asm9260-clock-controller.yaml49
-rw-r--r--Documentation/devicetree/bindings/clock/altr_socfpga.txt30
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml78
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt59
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.yaml201
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,c3-peripherals-clkc.yaml120
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,c3-pll-clkc.yaml62
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt64
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml85
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt53
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml37
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,meson8-clkc.yaml45
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt51
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,s4-peripherals-clkc.yaml96
-rw-r--r--Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml49
-rw-r--r--Documentation/devicetree/bindings/clock/apm,xgene-device-clock.yaml80
-rw-r--r--Documentation/devicetree/bindings/clock/apm,xgene-socpll-clock.yaml50
-rw-r--r--Documentation/devicetree/bindings/clock/apple,nco.yaml16
-rw-r--r--Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml4
-rw-r--r--Documentation/devicetree/bindings/clock/armada3700-periph-clock.txt71
-rw-r--r--Documentation/devicetree/bindings/clock/armada3700-tbg-clock.txt27
-rw-r--r--Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt29
-rw-r--r--Documentation/devicetree/bindings/clock/artpec6.txt41
-rw-r--r--Documentation/devicetree/bindings/clock/at91-clock.txt58
-rw-r--r--Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml162
-rw-r--r--Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml73
-rw-r--r--Documentation/devicetree/bindings/clock/axis,artpec6-clkctrl.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/axis,artpec8-clock.yaml213
-rw-r--r--Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml8
-rw-r--r--Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt31
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt60
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.yaml59
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.txt36
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.yaml46
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml40
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt24
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.yaml44
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,kona-ccu.txt138
-rw-r--r--Documentation/devicetree/bindings/clock/brcm,kona-ccu.yaml181
-rw-r--r--Documentation/devicetree/bindings/clock/calxeda.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml4
-rw-r--r--Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml3
-rw-r--r--Documentation/devicetree/bindings/clock/cirrus,ep7209-clk.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml6
-rw-r--r--Documentation/devicetree/bindings/clock/clps711x-clock.txt19
-rw-r--r--Documentation/devicetree/bindings/clock/dove-divider-clock.txt28
-rw-r--r--Documentation/devicetree/bindings/clock/fixed-clock.yaml11
-rw-r--r--Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml11
-rw-r--r--Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml282
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml51
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,imx8ulp-sim-lpav.yaml72
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,imx93-anatop.yaml42
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,plldig.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,qoriq-clock-legacy.yaml84
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,qoriq-clock.yaml207
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/fsl,vf610-ccm.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt26
-rw-r--r--Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml49
-rw-r--r--Documentation/devicetree/bindings/clock/google,gs101-clock.yaml184
-rw-r--r--Documentation/devicetree/bindings/clock/gpio-gate-clock.txt21
-rw-r--r--Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml42
-rw-r--r--Documentation/devicetree/bindings/clock/hi3620-clock.txt20
-rw-r--r--Documentation/devicetree/bindings/clock/hix5hd2-clock.txt30
-rw-r--r--Documentation/devicetree/bindings/clock/idt,versaclock5.yaml11
-rw-r--r--Documentation/devicetree/bindings/clock/img,pistachio-clk.yaml136
-rw-r--r--Documentation/devicetree/bindings/clock/imx1-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx21-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx23-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx25-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx27-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx28-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx31-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx35-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx5-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx6q-clock.yaml5
-rw-r--r--Documentation/devicetree/bindings/clock/imx6sl-clock.yaml5
-rw-r--r--Documentation/devicetree/bindings/clock/imx6sll-clock.yaml5
-rw-r--r--Documentation/devicetree/bindings/clock/imx6sx-clock.yaml5
-rw-r--r--Documentation/devicetree/bindings/clock/imx6ul-clock.yaml5
-rw-r--r--Documentation/devicetree/bindings/clock/imx7d-clock.yaml3
-rw-r--r--Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx8m-clock.yaml18
-rw-r--r--Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml84
-rw-r--r--Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/imx93-clock.yaml3
-rw-r--r--Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/ingenic,cgu.yaml8
-rw-r--r--Documentation/devicetree/bindings/clock/intel,agilex.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml40
-rw-r--r--Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/intel,easic-n5x.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/intel,stratix10.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/keystone-gate.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/keystone-pll.txt4
-rw-r--r--Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml45
-rw-r--r--Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml77
-rw-r--r--Documentation/devicetree/bindings/clock/lpc1850-ccu.txt77
-rw-r--r--Documentation/devicetree/bindings/clock/lpc1850-cgu.txt131
-rw-r--r--Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt52
-rw-r--r--Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt29
-rw-r--r--Documentation/devicetree/bindings/clock/lsi,axm5516-clks.yaml43
-rw-r--r--Documentation/devicetree/bindings/clock/lsi,nspire-cx-clock.yaml33
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,ap80x-clock.yaml54
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,armada-370-corediv-clock.yaml52
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,armada-3700-periph-clock.yaml96
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,armada-3700-tbg-clock.yaml54
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,armada-xp-cpu-clock.yaml44
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,berlin.txt31
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,berlin2-clk.yaml51
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,cp110-clock.yaml70
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,dove-divider-clock.yaml50
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,mvebu-core-clock.yaml94
-rw-r--r--Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/marvell-armada-370-gating-clock.yaml227
-rw-r--r--Documentation/devicetree/bindings/clock/maxim,max77686.txt114
-rw-r--r--Documentation/devicetree/bindings/clock/maxim,max9485.txt59
-rw-r--r--Documentation/devicetree/bindings/clock/maxim,max9485.yaml82
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml13
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,infracfg.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml)16
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt2701-hifsys.yaml50
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt6795-clock.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt7622-pciesys.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt7622-ssusbsys.yaml45
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml52
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml48
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml)4
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml)4
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml93
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml)4
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml)4
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml)20
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml)4
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml112
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml107
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8365-clock.yaml42
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mt8365-sys-clock.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml77
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,pericfg.yaml (renamed from Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml)7
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,syscon.yaml112
-rw-r--r--Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml12
-rw-r--r--Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml13
-rw-r--r--Documentation/devicetree/bindings/clock/microchip,mpfs-ccc.yaml80
-rw-r--r--Documentation/devicetree/bindings/clock/microchip,mpfs-clkcfg.yaml88
-rw-r--r--Documentation/devicetree/bindings/clock/microchip,mpfs.yaml67
-rw-r--r--Documentation/devicetree/bindings/clock/microchip,pic32.txt39
-rw-r--r--Documentation/devicetree/bindings/clock/microchip,pic32mzda-clk.yaml45
-rw-r--r--Documentation/devicetree/bindings/clock/milbeaut-clock.yaml31
-rw-r--r--Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt48
-rw-r--r--Documentation/devicetree/bindings/clock/moxa,moxart-clock.yaml38
-rw-r--r--Documentation/devicetree/bindings/clock/mvebu-core-clock.txt87
-rw-r--r--Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt23
-rw-r--r--Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt23
-rw-r--r--Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt205
-rw-r--r--Documentation/devicetree/bindings/clock/nspire-clock.txt24
-rw-r--r--Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml63
-rw-r--r--Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt100
-rw-r--r--Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml12
-rw-r--r--Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml6
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml60
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,lpc1850-ccu.yaml104
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,lpc1850-cgu.yaml99
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.txt30
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.yaml51
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.txt22
-rw-r--r--Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.yaml35
-rw-r--r--Documentation/devicetree/bindings/clock/oxnas,stdclk.txt28
-rw-r--r--Documentation/devicetree/bindings/clock/pistachio-clock.txt123
-rw-r--r--Documentation/devicetree/bindings/clock/pwm-clock.txt26
-rw-r--r--Documentation/devicetree/bindings/clock/pwm-clock.yaml45
-rw-r--r--Documentation/devicetree/bindings/clock/qca,ath79-pll.txt33
-rw-r--r--Documentation/devicetree/bindings/clock/qca,ath79-pll.yaml70
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,a53pll.yaml16
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,a7pll.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml11
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml7
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml42
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,dispcc-sc8280xp.yaml85
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml33
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml30
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml32
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml54
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml30
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml45
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml43
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml50
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml63
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml67
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml79
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml62
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml31
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml31
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml33
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml41
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml69
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml33
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml50
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml40
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml36
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml38
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml36
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml62
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml94
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml36
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml37
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml33
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml35
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml35
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml35
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml40
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml31
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml35
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gcc.yaml9
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml98
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,glymur-gcc.yaml121
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gpucc-sdm660.yaml24
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml72
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,gpucc.yaml59
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,hfpll.txt60
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,hfpll.yaml69
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml83
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,ipq5424-apss-clk.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml79
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml145
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml72
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml88
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,krait-cc.txt34
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,krait-cc.yaml43
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,lcc.txt22
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,lcc.yaml120
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,lpasscc.txt26
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml51
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,milos-dispcc.yaml63
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml62
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml53
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,mmcc.yaml345
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml17
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml30
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml4
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml86
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml28
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml77
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcs404-turingcc.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcs615-dispcc.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml59
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcs615-gpucc.yaml49
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcs615-videocc.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qcs8300-gcc.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qdu1000-ecpricc.yaml68
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml53
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml14
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml18
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml81
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sa8775p-dispcc.yaml79
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml85
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml63
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sar2130p-gcc.yaml65
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml29
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml30
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml11
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml62
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml26
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml30
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml18
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml46
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc8180x-camcc.yaml67
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml67
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml32
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml30
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sdm845-lpasscc.yaml47
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm4450-camcc.yaml51
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm4450-dispcc.yaml59
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm4450-gcc.yaml56
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6115-dispcc.yaml57
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml46
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml54
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6375-dispcc.yaml54
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6375-gcc.yaml52
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml75
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm7150-camcc.yaml60
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm7150-dispcc.yaml75
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml53
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm7150-videocc.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8150-camcc.yaml65
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml70
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml67
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml86
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml75
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml91
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml101
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml63
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml68
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml66
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt59
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml71
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,turingcc.txt19
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,videocc.yaml154
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml75
-rw-r--r--Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml131
-rw-r--r--Documentation/devicetree/bindings/clock/qoriq-clock.txt212
-rw-r--r--Documentation/devicetree/bindings/clock/raspberrypi,rp1-clocks.yaml58
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,5p35023.yaml90
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,9series.yaml18
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml8
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml56
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml4
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.yaml84
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml6
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml9
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml84
-rw-r--r--Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/riscv,rpmi-clock.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/riscv,rpmi-mpxy-clock.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.txt58
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.yaml76
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt58
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.yaml74
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3506-cru.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3576-cru.yaml56
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rk3588-cru.yaml67
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rv1126-cru.yaml62
-rw-r--r--Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml52
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml1
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml247
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml227
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml63
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynos8895-clock.yaml239
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml164
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml21
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml298
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt49
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt49
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt55
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,s3c6400-clock.yaml57
-rw-r--r--Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt76
-rw-r--r--Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml1
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si514.txt24
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si5341.txt175
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si5341.yaml223
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si5351.txt126
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si5351.yaml265
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si544.txt25
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si544.yaml54
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si570.txt41
-rw-r--r--Documentation/devicetree/bindings/clock/silabs,si570.yaml80
-rw-r--r--Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml59
-rw-r--r--Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml39
-rw-r--r--Documentation/devicetree/bindings/clock/sophgo,cv1800-clk.yaml55
-rw-r--r--Documentation/devicetree/bindings/clock/sophgo,sg2042-clkgen.yaml61
-rw-r--r--Documentation/devicetree/bindings/clock/sophgo,sg2042-pll.yaml53
-rw-r--r--Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml49
-rw-r--r--Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml99
-rw-r--r--Documentation/devicetree/bindings/clock/spacemit,k1-pll.yaml50
-rw-r--r--Documentation/devicetree/bindings/clock/sprd,sc9860-clk.txt63
-rw-r--r--Documentation/devicetree/bindings/clock/sprd,sc9860-clk.yaml159
-rw-r--r--Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml8
-rw-r--r--Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml4
-rw-r--r--Documentation/devicetree/bindings/clock/st,stm32-rcc.txt138
-rw-r--r--Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml144
-rw-r--r--Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt71
-rw-r--r--Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml18
-rw-r--r--Documentation/devicetree/bindings/clock/st,stm32mp21-rcc.yaml199
-rw-r--r--Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml219
-rw-r--r--Documentation/devicetree/bindings/clock/st/st,flexgen.txt3
-rw-r--r--Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml107
-rw-r--r--Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml87
-rw-r--r--Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml46
-rw-r--r--Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml82
-rw-r--r--Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml118
-rw-r--r--Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml90
-rw-r--r--Documentation/devicetree/bindings/clock/stericsson,abx500.txt20
-rw-r--r--Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml64
-rw-r--r--Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml43
-rw-r--r--Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml5
-rw-r--r--Documentation/devicetree/bindings/clock/ti,cdce925.txt53
-rw-r--r--Documentation/devicetree/bindings/clock/ti,cdce925.yaml103
-rw-r--r--Documentation/devicetree/bindings/clock/ti,clkctrl.yaml65
-rw-r--r--Documentation/devicetree/bindings/clock/ti,lmk04832.yaml4
-rw-r--r--Documentation/devicetree/bindings/clock/ti,sci-clk.yaml6
-rw-r--r--Documentation/devicetree/bindings/clock/ti-clkctrl.txt63
-rw-r--r--Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt20
-rw-r--r--Documentation/devicetree/bindings/clock/ti/adpll.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/ti/apll.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/ti/autoidle.txt39
-rw-r--r--Documentation/devicetree/bindings/clock/ti/clockdomain.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/ti/composite.txt57
-rw-r--r--Documentation/devicetree/bindings/clock/ti/divider.txt117
-rw-r--r--Documentation/devicetree/bindings/clock/ti/dpll.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/ti/fapll.txt2
-rw-r--r--Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt44
-rw-r--r--Documentation/devicetree/bindings/clock/ti/gate.txt107
-rw-r--r--Documentation/devicetree/bindings/clock/ti/interface.txt57
-rw-r--r--Documentation/devicetree/bindings/clock/ti/mux.txt80
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,autoidle.yaml34
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml82
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml179
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,fixed-factor-clock.yaml76
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml125
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,interface-clock.yaml71
-rw-r--r--Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml125
-rw-r--r--Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml2
-rw-r--r--Documentation/devicetree/bindings/clock/vf610-clock.txt41
-rw-r--r--Documentation/devicetree/bindings/clock/xgene.txt131
-rw-r--r--Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml83
-rw-r--r--Documentation/devicetree/bindings/clock/xlnx,vcu.yaml59
-rw-r--r--Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml114
-rw-r--r--Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt63
-rw-r--r--Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml88
-rw-r--r--Documentation/devicetree/bindings/connector/usb-connector.yaml206
-rw-r--r--Documentation/devicetree/bindings/counter/fsl,ftm-quaddec.yaml36
-rw-r--r--Documentation/devicetree/bindings/counter/ftm-quaddec.txt18
-rw-r--r--Documentation/devicetree/bindings/counter/ti,am62-ecap-capture.yaml61
-rw-r--r--Documentation/devicetree/bindings/counter/ti-eqep.yaml27
-rw-r--r--Documentation/devicetree/bindings/cpu/cpu-capacity.txt (renamed from Documentation/devicetree/bindings/arm/cpu-capacity.txt)4
-rw-r--r--Documentation/devicetree/bindings/cpu/cpu-topology.txt553
-rw-r--r--Documentation/devicetree/bindings/cpu/idle-states.yaml87
-rw-r--r--Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml55
-rw-r--r--Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml128
-rw-r--r--Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt61
-rw-r--r--Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml2
-rw-r--r--Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt250
-rw-r--r--Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml210
-rw-r--r--Documentation/devicetree/bindings/cpufreq/mediatek,mt8196-cpufreq-hw.yaml82
-rw-r--r--Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml90
-rw-r--r--Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml48
-rw-r--r--Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt132
-rw-r--r--Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml2
-rw-r--r--Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml35
-rw-r--r--Documentation/devicetree/bindings/crypto/amd,ccp-seattle-v1a.yaml41
-rw-r--r--Documentation/devicetree/bindings/crypto/amd-ccp.txt17
-rw-r--r--Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml4
-rw-r--r--Documentation/devicetree/bindings/crypto/artpec6-crypto.txt16
-rw-r--r--Documentation/devicetree/bindings/crypto/aspeed,ast2500-hace.yaml53
-rw-r--r--Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml49
-rw-r--r--Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml10
-rw-r--r--Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml10
-rw-r--r--Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml10
-rw-r--r--Documentation/devicetree/bindings/crypto/axis,artpec6-crypto.yaml39
-rw-r--r--Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt22
-rw-r--r--Documentation/devicetree/bindings/crypto/brcm,spum-crypto.yaml44
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml167
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml318
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml144
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-dcp.yaml12
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-imx-sahara.yaml43
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-sec2.txt65
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-sec4.txt553
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-sec6.txt157
-rw-r--r--Documentation/devicetree/bindings/crypto/hisilicon,hip06-sec.yaml134
-rw-r--r--Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt67
-rw-r--r--Documentation/devicetree/bindings/crypto/img,hash-accelerator.yaml69
-rw-r--r--Documentation/devicetree/bindings/crypto/img-hash.txt27
-rw-r--r--Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml67
-rw-r--r--Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml88
-rw-r--r--Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt40
-rw-r--r--Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml6
-rw-r--r--Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml2
-rw-r--r--Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml2
-rw-r--r--Documentation/devicetree/bindings/crypto/intel,keembay-ocs-hcu.yaml2
-rw-r--r--Documentation/devicetree/bindings/crypto/marvell,orion-crypto.yaml133
-rw-r--r--Documentation/devicetree/bindings/crypto/marvell-cesa.txt44
-rw-r--r--Documentation/devicetree/bindings/crypto/mediatek-crypto.txt25
-rw-r--r--Documentation/devicetree/bindings/crypto/mv_cesa.txt32
-rw-r--r--Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml52
-rw-r--r--Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml52
-rw-r--r--Documentation/devicetree/bindings/crypto/omap-aes.txt31
-rw-r--r--Documentation/devicetree/bindings/crypto/omap-des.txt30
-rw-r--r--Documentation/devicetree/bindings/crypto/omap-sham.txt28
-rw-r--r--Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml50
-rw-r--r--Documentation/devicetree/bindings/crypto/qcom,prng.yaml37
-rw-r--r--Documentation/devicetree/bindings/crypto/qcom-qce.txt25
-rw-r--r--Documentation/devicetree/bindings/crypto/qcom-qce.yaml178
-rw-r--r--Documentation/devicetree/bindings/crypto/rockchip,rk3288-crypto.yaml127
-rw-r--r--Documentation/devicetree/bindings/crypto/rockchip-crypto.txt28
-rw-r--r--Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml1
-rw-r--r--Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml2
-rw-r--r--Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml25
-rw-r--r--Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml30
-rw-r--r--Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml96
-rw-r--r--Documentation/devicetree/bindings/crypto/ti,am62l-dthev2.yaml50
-rw-r--r--Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml56
-rw-r--r--Documentation/devicetree/bindings/crypto/ti,omap2-aes.yaml58
-rw-r--r--Documentation/devicetree/bindings/crypto/ti,omap4-des.yaml65
-rw-r--r--Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml31
-rw-r--r--Documentation/devicetree/bindings/crypto/xlnx,versal-trng.yaml35
-rw-r--r--Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml6
-rw-r--r--Documentation/devicetree/bindings/devfreq/event/rockchip,dfi.yaml74
-rw-r--r--Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt18
-rw-r--r--Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml2
-rw-r--r--Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml13
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml32
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml36
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml19
-rw-r--r--Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml118
-rw-r--r--Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml10
-rw-r--r--Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml83
-rw-r--r--Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml88
-rw-r--r--Documentation/devicetree/bindings/display/arm,hdlcd.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/arm,komeda.yaml1
-rw-r--r--Documentation/devicetree/bindings/display/arm,malidp.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/arm,pl11x.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml103
-rw-r--r--Documentation/devicetree/bindings/display/atmel,lcdc.txt87
-rw-r--r--Documentation/devicetree/bindings/display/atmel,lcdc.yaml70
-rw-r--r--Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt75
-rw-r--r--Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml80
-rw-r--r--Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml85
-rw-r--r--Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml1
-rw-r--r--Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml15
-rw-r--r--Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml22
-rw-r--r--Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml9
-rw-r--r--Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml1
-rw-r--r--Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml64
-rw-r--r--Documentation/devicetree/bindings/display/bridge/analogix_dp.txt51
-rw-r--r--Documentation/devicetree/bindings/display/bridge/anx6345.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt112
-rw-r--r--Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml180
-rw-r--r--Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml114
-rw-r--r--Documentation/devicetree/bindings/display/bridge/fsl,imx93-mipi-dsi.yaml115
-rw-r--r--Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml20
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml251
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml78
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml12
-rw-r--r--Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml23
-rw-r--r--Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/bridge/megachips,stdp2690-ge-b850v3-fw.yaml111
-rw-r--r--Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt91
-rw-r--r--Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml55
-rw-r--r--Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml18
-rw-r--r--Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml116
-rw-r--r--Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml115
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ps8622.txt31
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ps8640.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml58
-rw-r--r--Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml248
-rw-r--r--Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml309
-rw-r--r--Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml108
-rw-r--r--Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml20
-rw-r--r--Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt33
-rw-r--r--Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml18
-rw-r--r--Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml141
-rw-r--r--Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml14
-rw-r--r--Documentation/devicetree/bindings/display/bridge/tda998x.txt54
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml33
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml8
-rw-r--r--Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml58
-rw-r--r--Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt35
-rw-r--r--Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml89
-rw-r--r--Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml43
-rw-r--r--Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml6
-rw-r--r--Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml41
-rw-r--r--Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml103
-rw-r--r--Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt2
-rw-r--r--Documentation/devicetree/bindings/display/connector/dp-connector.yaml52
-rw-r--r--Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/dp-aux-bus.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/dsi-controller.yaml20
-rw-r--r--Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml54
-rw-r--r--Documentation/devicetree/bindings/display/exynos/exynos_dp.txt112
-rw-r--r--Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt90
-rw-r--r--Documentation/devicetree/bindings/display/fsl,dcu.txt34
-rw-r--r--Documentation/devicetree/bindings/display/fsl,lcdif.yaml110
-rw-r--r--Documentation/devicetree/bindings/display/fsl,ls1021a-dcu.yaml71
-rw-r--r--Documentation/devicetree/bindings/display/fsl,tcon.txt17
-rw-r--r--Documentation/devicetree/bindings/display/fsl,vf610-tcon.yaml43
-rw-r--r--Documentation/devicetree/bindings/display/himax,hx8357.yaml78
-rw-r--r--Documentation/devicetree/bindings/display/himax,hx8357d.txt26
-rw-r--r--Documentation/devicetree/bindings/display/ilitek,ili9486.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx-display-subsystem.yaml36
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt57
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml146
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml74
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml10
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx6q-ipu.yaml97
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx6q-ldb.yaml193
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx6qp-pre.yaml55
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx6qp-prg.yaml54
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml69
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml84
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-axi-performance-counter.yaml57
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blit-engine.yaml204
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml41
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-clut.yaml44
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml67
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-constframe.yaml44
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-display-engine.yaml152
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-dither.yaml45
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-extdst.yaml72
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-fetchunit.yaml141
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-filter.yaml43
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-framegen.yaml64
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-gammacor.yaml32
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-layerblend.yaml39
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-matrix.yaml44
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-pixel-engine.yaml250
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-rop.yaml43
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-safety.yaml34
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml83
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-signature.yaml53
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml96
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-tcon.yaml45
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc.yaml236
-rw-r--r--Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt162
-rw-r--r--Documentation/devicetree/bindings/display/imx/ldb.txt147
-rw-r--r--Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/ingenic,ipu.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/ingenic,lcd.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/intel,keembay-display.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/lvds-data-mapping.yaml115
-rw-r--r--Documentation/devicetree/bindings/display/lvds-dual-ports.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/lvds.yaml77
-rw-r--r--Documentation/devicetree/bindings/display/mayqueen,pixpaper.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml62
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml33
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml38
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml28
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml24
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml78
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml27
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml55
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml208
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml33
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml88
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml33
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml41
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.yaml151
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml42
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml29
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml48
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml87
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml26
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml40
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml49
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml39
-rw-r--r--Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/msm/dp-controller.yaml230
-rw-r--r--Documentation/devicetree/bindings/display/msm/dpu-common.yaml56
-rw-r--r--Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml223
-rw-r--r--Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml222
-rw-r--r--Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml235
-rw-r--r--Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml239
-rw-r--r--Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml217
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml473
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml55
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml50
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml38
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml45
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml45
-rw-r--r--Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml11
-rw-r--r--Documentation/devicetree/bindings/display/msm/gmu.yaml203
-rw-r--r--Documentation/devicetree/bindings/display/msm/gpu.yaml311
-rw-r--r--Documentation/devicetree/bindings/display/msm/hdmi.yaml47
-rw-r--r--Documentation/devicetree/bindings/display/msm/mdp4.yaml13
-rw-r--r--Documentation/devicetree/bindings/display/msm/mdp5.txt160
-rw-r--r--Documentation/devicetree/bindings/display/msm/mdss-common.yaml106
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml264
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml157
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml226
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml101
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml278
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml90
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml215
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml286
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml464
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sar2130p-mdss.yaml443
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml125
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml322
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml114
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml444
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc8180x-dpu.yaml103
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc8180x-mdss.yaml359
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml155
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml292
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml98
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml288
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml93
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml203
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml223
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml108
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml255
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml225
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml218
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml143
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml464
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml94
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml347
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml350
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml244
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml364
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml353
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml137
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml341
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml474
-rw-r--r--Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml255
-rw-r--r--Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml17
-rw-r--r--Documentation/devicetree/bindings/display/panel/anbernic,rg35xx-plus-panel.yaml67
-rw-r--r--Documentation/devicetree/bindings/display/panel/apple,summit.yaml58
-rw-r--r--Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml60
-rw-r--r--Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/boe,td4320.yaml65
-rw-r--r--Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml75
-rw-r--r--Documentation/devicetree/bindings/display/panel/boe,tv101wum-ll2.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/panel/display-timings.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml14
-rw-r--r--Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml59
-rw-r--r--Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml8
-rw-r--r--Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml56
-rw-r--r--Documentation/devicetree/bindings/display/panel/himax,hx8279.yaml75
-rw-r--r--Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml83
-rw-r--r--Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml76
-rw-r--r--Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml73
-rw-r--r--Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml94
-rw-r--r--Documentation/devicetree/bindings/display/panel/hydis,hv101hd1.yaml60
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml68
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml13
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml64
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml64
-rw-r--r--Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml12
-rw-r--r--Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml43
-rw-r--r--Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml75
-rw-r--r--Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml96
-rw-r--r--Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml9
-rw-r--r--Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml10
-rw-r--r--Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml60
-rw-r--r--Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml64
-rw-r--r--Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml8
-rw-r--r--Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml9
-rw-r--r--Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml64
-rw-r--r--Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml10
-rw-r--r--Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml108
-rw-r--r--Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml10
-rw-r--r--Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml66
-rw-r--r--Documentation/devicetree/bindings/display/panel/novatek,nt37801.yaml69
-rw-r--r--Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml8
-rw-r--r--Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml47
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-common.yaml10
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml117
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-lvds.yaml24
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml47
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml16
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml106
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-simple.yaml173
-rw-r--r--Documentation/devicetree/bindings/display/panel/panel-timing.yaml49
-rw-r--r--Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml29
-rw-r--r--Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml29
-rw-r--r--Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml71
-rw-r--r--Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml75
-rw-r--r--Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml90
-rw-r--r--Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml94
-rw-r--r--Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml73
-rw-r--r--Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml11
-rw-r--r--Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml16
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml60
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,ams581vf01.yaml79
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml80
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml116
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml8
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml6
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml71
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml81
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml75
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams427ap24.yaml65
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml13
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml16
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml55
-rw-r--r--Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml79
-rw-r--r--Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.yaml30
-rw-r--r--Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml99
-rw-r--r--Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml8
-rw-r--r--Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml81
-rw-r--r--Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml21
-rw-r--r--Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml85
-rw-r--r--Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml69
-rw-r--r--Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml89
-rw-r--r--Documentation/devicetree/bindings/display/panel/tpo,td.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml5
-rw-r--r--Documentation/devicetree/bindings/display/panel/truly,nt35597-2K-display.yaml97
-rw-r--r--Documentation/devicetree/bindings/display/panel/visionox,g2647fb105.yaml79
-rw-r--r--Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml59
-rw-r--r--Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml37
-rw-r--r--Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml77
-rw-r--r--Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml13
-rw-r--r--Documentation/devicetree/bindings/display/renesas,cmm.yaml12
-rw-r--r--Documentation/devicetree/bindings/display/renesas,du.yaml107
-rw-r--r--Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml176
-rw-r--r--Documentation/devicetree/bindings/display/renesas,shmobile-lcdc.yaml130
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt98
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt74
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt94
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt49
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml124
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml149
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml46
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml168
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml146
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml170
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml170
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml200
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml121
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt92
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml11
-rw-r--r--Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml215
-rw-r--r--Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml6
-rw-r--r--Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml163
-rw-r--r--Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml1
-rw-r--r--Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml27
-rw-r--r--Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/sharp,ls010b7dh04.yaml92
-rw-r--r--Documentation/devicetree/bindings/display/simple-framebuffer.yaml19
-rw-r--r--Documentation/devicetree/bindings/display/sitronix,st7567.yaml68
-rw-r--r--Documentation/devicetree/bindings/display/sitronix,st7571.yaml78
-rw-r--r--Documentation/devicetree/bindings/display/sitronix,st7586.txt22
-rw-r--r--Documentation/devicetree/bindings/display/sitronix,st7586.yaml61
-rw-r--r--Documentation/devicetree/bindings/display/sitronix,st7735r.yaml7
-rw-r--r--Documentation/devicetree/bindings/display/solomon,ssd-common.yaml42
-rw-r--r--Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml76
-rw-r--r--Documentation/devicetree/bindings/display/solomon,ssd132x.yaml89
-rw-r--r--Documentation/devicetree/bindings/display/solomon,ssd133x.yaml45
-rw-r--r--Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/st,stm32-dsi.yaml19
-rw-r--r--Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml55
-rw-r--r--Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml130
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-tsec.yaml68
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml1
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml14
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml6
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml2
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-csi.yaml138
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml15
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml17
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml9
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml14
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml15
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml23
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml63
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml41
-rw-r--r--Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml3
-rw-r--r--Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml79
-rw-r--r--Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml257
-rw-r--r--Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml4
-rw-r--r--Documentation/devicetree/bindings/display/ti/ti,opa362.txt38
-rw-r--r--Documentation/devicetree/bindings/display/truly,nt35597.txt59
-rw-r--r--Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml77
-rw-r--r--Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml22
-rw-r--r--Documentation/devicetree/bindings/dma/adi,axi-dmac.txt61
-rw-r--r--Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml129
-rw-r--r--Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml8
-rw-r--r--Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml19
-rw-r--r--Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml4
-rw-r--r--Documentation/devicetree/bindings/dma/altr,msgdma.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/apm,xgene-storm-dma.yaml59
-rw-r--r--Documentation/devicetree/bindings/dma/apm-xgene-dma.txt47
-rw-r--r--Documentation/devicetree/bindings/dma/apple,admac.yaml28
-rw-r--r--Documentation/devicetree/bindings/dma/arm,dma-350.yaml44
-rw-r--r--Documentation/devicetree/bindings/dma/arm,pl330.yaml6
-rw-r--r--Documentation/devicetree/bindings/dma/arm-pl08x.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml68
-rw-r--r--Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml82
-rw-r--r--Documentation/devicetree/bindings/dma/atmel-dma.txt42
-rw-r--r--Documentation/devicetree/bindings/dma/atmel-xdma.txt53
-rw-r--r--Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt83
-rw-r--r--Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml102
-rw-r--r--Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt29
-rw-r--r--Documentation/devicetree/bindings/dma/brcm,iproc-sba.yaml41
-rw-r--r--Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml84
-rw-r--r--Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml144
-rw-r--r--Documentation/devicetree/bindings/dma/dma-common.yaml9
-rw-r--r--Documentation/devicetree/bindings/dma/dma-controller.yaml19
-rw-r--r--Documentation/devicetree/bindings/dma/dma-router.yaml15
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,edma.yaml211
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml137
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml125
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml132
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,imx-dma.yaml70
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml151
-rw-r--r--Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml134
-rw-r--r--Documentation/devicetree/bindings/dma/fsl-imx-dma.txt50
-rw-r--r--Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt118
-rw-r--r--Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt60
-rw-r--r--Documentation/devicetree/bindings/dma/fsl-qdma.txt58
-rw-r--r--Documentation/devicetree/bindings/dma/fsl-qdma.yaml135
-rw-r--r--Documentation/devicetree/bindings/dma/ingenic,dma.yaml7
-rw-r--r--Documentation/devicetree/bindings/dma/intel,ldma.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/loongson,ls1b-apbdma.yaml65
-rw-r--r--Documentation/devicetree/bindings/dma/loongson,ls2x-apbdma.yaml62
-rw-r--r--Documentation/devicetree/bindings/dma/lpc1850-dmamux.txt54
-rw-r--r--Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml72
-rw-r--r--Documentation/devicetree/bindings/dma/marvell,orion-xor.yaml84
-rw-r--r--Documentation/devicetree/bindings/dma/marvell,xor-v2.yaml61
-rw-r--r--Documentation/devicetree/bindings/dma/mediatek,mt7622-hsdma.yaml63
-rw-r--r--Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml3
-rw-r--r--Documentation/devicetree/bindings/dma/mmp-dma.txt81
-rw-r--r--Documentation/devicetree/bindings/dma/mtk-hsdma.txt33
-rw-r--r--Documentation/devicetree/bindings/dma/mv-xor-v2.txt28
-rw-r--r--Documentation/devicetree/bindings/dma/mv-xor.txt40
-rw-r--r--Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml12
-rw-r--r--Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt44
-rw-r--r--Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml100
-rw-r--r--Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml65
-rw-r--r--Documentation/devicetree/bindings/dma/nxp,lpc3220-dmamux.yaml49
-rw-r--r--Documentation/devicetree/bindings/dma/owl-dma.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/qcom,adm.yaml99
-rw-r--r--Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml47
-rw-r--r--Documentation/devicetree/bindings/dma/qcom,gpi.yaml43
-rw-r--r--Documentation/devicetree/bindings/dma/qcom_adm.txt61
-rw-r--r--Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt95
-rw-r--r--Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml4
-rw-r--r--Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml136
-rw-r--r--Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml16
-rw-r--r--Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml45
-rw-r--r--Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml68
-rw-r--r--Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml2
-rw-r--r--Documentation/devicetree/bindings/dma/sophgo,cv1800b-dmamux.yaml51
-rw-r--r--Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml68
-rw-r--r--Documentation/devicetree/bindings/dma/sprd,sc9860-dma.yaml92
-rw-r--r--Documentation/devicetree/bindings/dma/sprd-dma.txt44
-rw-r--r--Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml53
-rw-r--r--Documentation/devicetree/bindings/dma/stericsson,dma40.yaml51
-rw-r--r--Documentation/devicetree/bindings/dma/stm32/st,stm32-dma.yaml (renamed from Documentation/devicetree/bindings/dma/st,stm32-dma.yaml)11
-rw-r--r--Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml141
-rw-r--r--Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml67
-rw-r--r--Documentation/devicetree/bindings/dma/stm32/st,stm32-mdma.yaml (renamed from Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml)6
-rw-r--r--Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt4
-rw-r--r--Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml141
-rw-r--r--Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml28
-rw-r--r--Documentation/devicetree/bindings/dma/ti/k3-udma.yaml33
-rw-r--r--Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt29
-rw-r--r--Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml15
-rw-r--r--Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml10
-rw-r--r--Documentation/devicetree/bindings/dpll/dpll-device.yaml76
-rw-r--r--Documentation/devicetree/bindings/dpll/dpll-pin.yaml45
-rw-r--r--Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml115
-rw-r--r--Documentation/devicetree/bindings/dsp/fsl,dsp.yaml58
-rw-r--r--Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml4
-rw-r--r--Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml42
-rw-r--r--Documentation/devicetree/bindings/dts-coding-style.rst213
-rw-r--r--Documentation/devicetree/bindings/dvfs/performance-domain.yaml2
-rw-r--r--Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml324
-rw-r--r--Documentation/devicetree/bindings/edac/apm,xgene-edac.yaml202
-rw-r--r--Documentation/devicetree/bindings/edac/apm-xgene-edac.txt112
-rw-r--r--Documentation/devicetree/bindings/edac/aspeed,ast2400-sdram-edac.yaml48
-rw-r--r--Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt28
-rw-r--r--Documentation/devicetree/bindings/edac/dmc-520.yaml2
-rw-r--r--Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt383
-rw-r--r--Documentation/devicetree/bindings/eeprom/at24.yaml40
-rw-r--r--Documentation/devicetree/bindings/eeprom/at25.yaml18
-rw-r--r--Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml3
-rw-r--r--Documentation/devicetree/bindings/eeprom/st,m24lr.yaml52
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/acer,aspire1-ec.yaml60
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/google,cros-ec.yaml326
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/gw,gsc.yaml193
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/huawei,gaokun3-ec.yaml124
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml (renamed from Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml)19
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/lenovo,thinkpad-t14s-ec.yaml50
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/lenovo,yoga-c630-ec.yaml83
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/microsoft,surface-sam.yaml47
-rw-r--r--Documentation/devicetree/bindings/embedded-controller/traverse,ten64-controller.yaml40
-rw-r--r--Documentation/devicetree/bindings/example-schema.yaml26
-rw-r--r--Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml11
-rw-r--r--Documentation/devicetree/bindings/extcon/extcon-rt8973a.txt23
-rw-r--r--Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt21
-rw-r--r--Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml3
-rw-r--r--Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml2
-rw-r--r--Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml43
-rw-r--r--Documentation/devicetree/bindings/extcon/maxim,max14526.yaml80
-rw-r--r--Documentation/devicetree/bindings/extcon/maxim,max77843.yaml1
-rw-r--r--Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml16
-rw-r--r--Documentation/devicetree/bindings/extcon/richtek,rt8973a-muic.yaml49
-rw-r--r--Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml4
-rw-r--r--Documentation/devicetree/bindings/extcon/wlf,arizona.yaml14
-rw-r--r--Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml39
-rw-r--r--Documentation/devicetree/bindings/firmware/arm,scmi.yaml215
-rw-r--r--Documentation/devicetree/bindings/firmware/arm,scpi.yaml2
-rw-r--r--Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml39
-rw-r--r--Documentation/devicetree/bindings/firmware/cznic,turris-omnia-mcu.yaml86
-rw-r--r--Documentation/devicetree/bindings/firmware/fsl,scu.yaml17
-rw-r--r--Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml96
-rw-r--r--Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml56
-rw-r--r--Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt57
-rw-r--r--Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml108
-rw-r--r--Documentation/devicetree/bindings/firmware/meson/meson_sm.txt15
-rw-r--r--Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml40
-rw-r--r--Documentation/devicetree/bindings/firmware/nxp,imx95-scmi-pinctrl.yaml53
-rw-r--r--Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml72
-rw-r--r--Documentation/devicetree/bindings/firmware/qcom,scm.yaml111
-rw-r--r--Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml3
-rw-r--r--Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml60
-rw-r--r--Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml116
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt13
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt20
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt36
-rw-r--r--Documentation/devicetree/bindings/fpga/altera-passive-serial.txt29
-rw-r--r--Documentation/devicetree/bindings/fpga/altr,fpga-passive-serial.yaml74
-rw-r--r--Documentation/devicetree/bindings/fpga/altr,freeze-bridge-controller.yaml41
-rw-r--r--Documentation/devicetree/bindings/fpga/altr,socfpga-fpga2sdram-bridge.yaml33
-rw-r--r--Documentation/devicetree/bindings/fpga/altr,socfpga-hps2fpga-bridge.yaml49
-rw-r--r--Documentation/devicetree/bindings/fpga/fpga-bridge.txt13
-rw-r--r--Documentation/devicetree/bindings/fpga/fpga-bridge.yaml30
-rw-r--r--Documentation/devicetree/bindings/fpga/fpga-region.txt479
-rw-r--r--Documentation/devicetree/bindings/fpga/fpga-region.yaml354
-rw-r--r--Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml36
-rw-r--r--Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt18
-rw-r--r--Documentation/devicetree/bindings/fpga/lattice,ice40-fpga-mgr.yaml59
-rw-r--r--Documentation/devicetree/bindings/fpga/lattice,sysconfig.yaml81
-rw-r--r--Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt21
-rw-r--r--Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml9
-rw-r--r--Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt54
-rw-r--r--Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt51
-rw-r--r--Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml4
-rw-r--r--Documentation/devicetree/bindings/fpga/xlnx,fpga-selectmap.yaml86
-rw-r--r--Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml80
-rw-r--r--Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml67
-rw-r--r--Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml6
-rw-r--r--Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml4
-rw-r--r--Documentation/devicetree/bindings/fsi/aspeed,ast2400-cf-fsi-master.yaml81
-rw-r--r--Documentation/devicetree/bindings/fsi/aspeed,ast2600-fsi-master.yaml121
-rw-r--r--Documentation/devicetree/bindings/fsi/fsi-controller.yaml66
-rw-r--r--Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt36
-rw-r--r--Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt36
-rw-r--r--Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt28
-rw-r--r--Documentation/devicetree/bindings/fsi/fsi-master-gpio.yaml63
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml36
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml44
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,p9-fsi-controller.yaml45
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt16
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml40
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.yaml46
-rw-r--r--Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml38
-rw-r--r--Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml3
-rw-r--r--Documentation/devicetree/bindings/gnss/brcm,bcm4751.yaml3
-rw-r--r--Documentation/devicetree/bindings/gnss/gnss-common.yaml8
-rw-r--r--Documentation/devicetree/bindings/gnss/mediatek.yaml3
-rw-r--r--Documentation/devicetree/bindings/gnss/sirfstar.yaml3
-rw-r--r--Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml27
-rw-r--r--Documentation/devicetree/bindings/goldfish/pipe.txt2
-rw-r--r--Documentation/devicetree/bindings/gpio/8xxx_gpio.txt72
-rw-r--r--Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt35
-rw-r--r--Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.yaml63
-rw-r--r--Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml51
-rw-r--r--Documentation/devicetree/bindings/gpio/altr-pio-1.0.yaml75
-rw-r--r--Documentation/devicetree/bindings/gpio/apm,xgene-gpio-sb.yaml94
-rw-r--r--Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml29
-rw-r--r--Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml169
-rw-r--r--Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml10
-rw-r--r--Documentation/devicetree/bindings/gpio/atmel,at91rm9200-gpio.yaml81
-rw-r--r--Documentation/devicetree/bindings/gpio/blaize,blzp1600-gpio.yaml77
-rw-r--r--Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml86
-rw-r--r--Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml72
-rw-r--r--Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml9
-rw-r--r--Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt52
-rw-r--r--Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml100
-rw-r--r--Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml1
-rw-r--r--Documentation/devicetree/bindings/gpio/cavium,octeon-3860-gpio.yaml62
-rw-r--r--Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt49
-rw-r--r--Documentation/devicetree/bindings/gpio/cdns,gpio.txt43
-rw-r--r--Documentation/devicetree/bindings/gpio/cdns,gpio.yaml84
-rw-r--r--Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt17
-rw-r--r--Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.yaml49
-rw-r--r--Documentation/devicetree/bindings/gpio/exar,xra1403.yaml75
-rw-r--r--Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml56
-rw-r--r--Documentation/devicetree/bindings/gpio/fsl,imx8qxp-sc-gpio.yaml39
-rw-r--r--Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml95
-rw-r--r--Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml25
-rw-r--r--Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt20
-rw-r--r--Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml50
-rw-r--r--Documentation/devicetree/bindings/gpio/gateworks,pld-gpio.txt20
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-74xx-mmio.txt30
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-altera.txt44
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-aspeed.txt39
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-ath79.txt37
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-clps711x.txt28
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-davinci.yaml4
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-delay.yaml79
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt39
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt97
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml157
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-latch.yaml94
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-lp3943.txt37
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-max3191x.txt59
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-max77620.txt25
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt38
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-mmio.yaml162
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-moxtet.txt18
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt53
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml12
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-mxs.yaml160
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-nmk.txt31
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-palmas.txt27
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml48
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml125
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-pisosr.txt34
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-sprd.txt28
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-stmpe.txt18
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml51
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-ts4800.txt20
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-ts4900.txt30
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-twl4030.txt29
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-vf610.yaml59
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt64
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-xgene.txt22
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-xilinx.txt48
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-xra1403.txt46
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-zevio.txt16
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-zynq.yaml4
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio.txt51
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio_atmel.txt31
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt43
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio_oxnas.txt47
-rw-r--r--Documentation/devicetree/bindings/gpio/hisilicon,ascend910-gpio.yaml56
-rw-r--r--Documentation/devicetree/bindings/gpio/ibm,ppc4xx-gpio.txt24
-rw-r--r--Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt38
-rw-r--r--Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.yaml73
-rw-r--r--Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml2
-rw-r--r--Documentation/devicetree/bindings/gpio/lacie,netxbig-gpio-ext.yaml60
-rw-r--r--Documentation/devicetree/bindings/gpio/lantiq,gpio-mm-lantiq.yaml54
-rw-r--r--Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml168
-rw-r--r--Documentation/devicetree/bindings/gpio/lsi,zevio-gpio.yaml43
-rw-r--r--Documentation/devicetree/bindings/gpio/maxim,max31910.yaml104
-rw-r--r--Documentation/devicetree/bindings/gpio/maxim,max7360-gpio.yaml83
-rw-r--r--Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml44
-rw-r--r--Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml30
-rw-r--r--Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt49
-rw-r--r--Documentation/devicetree/bindings/gpio/microchip,pic32mzda-gpio.yaml71
-rw-r--r--Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml2
-rw-r--r--Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt22
-rw-r--r--Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt38
-rw-r--r--Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt26
-rw-r--r--Documentation/devicetree/bindings/gpio/nuvoton,sgpio.yaml87
-rw-r--r--Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml5
-rw-r--r--Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt59
-rw-r--r--Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.yaml78
-rw-r--r--Documentation/devicetree/bindings/gpio/nxp,lpc3220-gpio.yaml50
-rw-r--r--Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml67
-rw-r--r--Documentation/devicetree/bindings/gpio/pisosr-gpio.yaml67
-rw-r--r--Documentation/devicetree/bindings/gpio/pl061-gpio.yaml3
-rw-r--r--Documentation/devicetree/bindings/gpio/qca,ar7100-gpio.yaml60
-rw-r--r--Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt30
-rw-r--r--Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml8
-rw-r--r--Documentation/devicetree/bindings/gpio/realtek,rtd-gpio.yaml69
-rw-r--r--Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml20
-rw-r--r--Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml26
-rw-r--r--Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml10
-rw-r--r--Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml50
-rw-r--r--Documentation/devicetree/bindings/gpio/sifive,gpio.yaml6
-rw-r--r--Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt21
-rw-r--r--Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml12
-rw-r--r--Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml11
-rw-r--r--Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml96
-rw-r--r--Documentation/devicetree/bindings/gpio/spear_spics.txt49
-rw-r--r--Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml124
-rw-r--r--Documentation/devicetree/bindings/gpio/sprd,gpio.yaml75
-rw-r--r--Documentation/devicetree/bindings/gpio/st,nomadik-gpio.yaml96
-rw-r--r--Documentation/devicetree/bindings/gpio/st,spear-spics-gpio.yaml82
-rw-r--r--Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml57
-rw-r--r--Documentation/devicetree/bindings/gpio/ti,keystone-dsp-gpio.yaml65
-rw-r--r--Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml6
-rw-r--r--Documentation/devicetree/bindings/gpio/ti,twl4030-gpio.yaml61
-rw-r--r--Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml24
-rw-r--r--Documentation/devicetree/bindings/gpio/trivial-gpio.yaml112
-rw-r--r--Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt38
-rw-r--r--Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml8
-rw-r--r--Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml155
-rw-r--r--Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml9
-rw-r--r--Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml4
-rw-r--r--Documentation/devicetree/bindings/gpu/apple,agx.yaml100
-rw-r--r--Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml106
-rw-r--r--Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml21
-rw-r--r--Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml8
-rw-r--r--Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml185
-rw-r--r--Documentation/devicetree/bindings/gpu/aspeed,ast2400-gfx.yaml63
-rw-r--r--Documentation/devicetree/bindings/gpu/aspeed-gfx.txt41
-rw-r--r--Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml93
-rw-r--r--Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml6
-rw-r--r--Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml6
-rw-r--r--Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml6
-rw-r--r--Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml156
-rw-r--r--Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml185
-rw-r--r--Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml138
-rw-r--r--Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt115
-rw-r--r--Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml171
-rw-r--r--Documentation/devicetree/bindings/gpu/samsung-g2d.yaml71
-rw-r--r--Documentation/devicetree/bindings/gpu/samsung-rotator.yaml9
-rw-r--r--Documentation/devicetree/bindings/gpu/samsung-scaler.yaml81
-rw-r--r--Documentation/devicetree/bindings/gpu/vivante,gc.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml38
-rw-r--r--Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml25
-rw-r--r--Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml37
-rw-r--r--Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml7
-rw-r--r--Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml29
-rw-r--r--Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml50
-rw-r--r--Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt23
-rw-r--r--Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/adc128d818.txt38
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml1
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml19
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml8
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml23
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml24
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml52
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml21
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml127
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml33
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml159
-rw-r--r--Documentation/devicetree/bindings/hwmon/adi,max31827.yaml119
-rw-r--r--Documentation/devicetree/bindings/hwmon/adt7475.yaml44
-rw-r--r--Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml6
-rw-r--r--Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml6
-rw-r--r--Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml77
-rw-r--r--Documentation/devicetree/bindings/hwmon/apm,xgene-slimpro-hwmon.yaml30
-rw-r--r--Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt14
-rw-r--r--Documentation/devicetree/bindings/hwmon/as370.txt11
-rw-r--r--Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml74
-rw-r--r--Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt2
-rw-r--r--Documentation/devicetree/bindings/hwmon/fan-common.yaml79
-rw-r--r--Documentation/devicetree/bindings/hwmon/g762.txt47
-rw-r--r--Documentation/devicetree/bindings/hwmon/gmt,g762.yaml95
-rw-r--r--Documentation/devicetree/bindings/hwmon/gpio-fan.txt41
-rw-r--r--Documentation/devicetree/bindings/hwmon/gpio-fan.yaml63
-rw-r--r--Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml45
-rw-r--r--Documentation/devicetree/bindings/hwmon/hwmon-common.yaml19
-rw-r--r--Documentation/devicetree/bindings/hwmon/ibm,occ-hwmon.yaml39
-rw-r--r--Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml37
-rw-r--r--Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt25
-rw-r--r--Documentation/devicetree/bindings/hwmon/ibmpowernv.txt23
-rw-r--r--Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml16
-rw-r--r--Documentation/devicetree/bindings/hwmon/ina3221.txt54
-rw-r--r--Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml3
-rw-r--r--Documentation/devicetree/bindings/hwmon/lantiq,cputemp.yaml30
-rw-r--r--Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml103
-rw-r--r--Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml7
-rw-r--r--Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml49
-rw-r--r--Documentation/devicetree/bindings/hwmon/lm75.yaml41
-rw-r--r--Documentation/devicetree/bindings/hwmon/lm87.txt30
-rw-r--r--Documentation/devicetree/bindings/hwmon/ltc2978.txt62
-rw-r--r--Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt10
-rw-r--r--Documentation/devicetree/bindings/hwmon/max31785.txt22
-rw-r--r--Documentation/devicetree/bindings/hwmon/max6650.txt28
-rw-r--r--Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml84
-rw-r--r--Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml91
-rw-r--r--Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml69
-rw-r--r--Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml111
-rw-r--r--Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml10
-rw-r--r--Documentation/devicetree/bindings/hwmon/national,lm90.yaml61
-rw-r--r--Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt8
-rw-r--r--Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml6
-rw-r--r--Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml65
-rw-r--r--Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml17
-rw-r--r--Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml36
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml60
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml50
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/adi,max17616.yaml52
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml77
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml151
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/mps,mp2975.yaml75
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml74
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml17
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml83
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml15
-rw-r--r--Documentation/devicetree/bindings/hwmon/pmbus/vicor,pli1209bc.yaml62
-rw-r--r--Documentation/devicetree/bindings/hwmon/pwm-fan.txt67
-rw-r--r--Documentation/devicetree/bindings/hwmon/pwm-fan.yaml116
-rw-r--r--Documentation/devicetree/bindings/hwmon/renesas,isl28022.yaml64
-rw-r--r--Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml47
-rw-r--r--Documentation/devicetree/bindings/hwmon/st,stts751.yaml41
-rw-r--r--Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml63
-rw-r--r--Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml70
-rw-r--r--Documentation/devicetree/bindings/hwmon/stts751.txt15
-rw-r--r--Documentation/devicetree/bindings/hwmon/syna,as370.yaml32
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml62
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml1
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml108
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml99
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,ina3221.yaml121
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,lm87.yaml70
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml11
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml20
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml2
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml31
-rw-r--r--Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml25
-rw-r--r--Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml1
-rw-r--r--Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml2
-rw-r--r--Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml7
-rw-r--r--Documentation/devicetree/bindings/i2c/apm,xgene-slimpro-i2c.yaml36
-rw-r--r--Documentation/devicetree/bindings/i2c/apple,i2c.yaml25
-rw-r--r--Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml9
-rw-r--r--Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml16
-rw-r--r--Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml28
-rw-r--r--Documentation/devicetree/bindings/i2c/brcm,kona-i2c.txt35
-rw-r--r--Documentation/devicetree/bindings/i2c/brcm,kona-i2c.yaml59
-rw-r--r--Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml23
-rw-r--r--Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml5
-rw-r--r--Documentation/devicetree/bindings/i2c/hisilicon,ascend910-i2c.yaml73
-rw-r--r--Documentation/devicetree/bindings/i2c/hisilicon,hix5hd2-i2c.yaml51
-rw-r--r--Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml59
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt82
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml135
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-arb.txt35
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-atr.yaml34
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt135
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml173
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml20
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-fsi.txt40
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-gpio.yaml28
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-hix5hd2.txt24
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml6
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-imx.yaml4
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt33
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mpc.yaml3
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml17
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mt7621.txt25
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml7
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml1
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml76
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-mxs.yaml5
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-pnx.txt34
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-pxa.yaml4
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml7
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-sprd.txt31
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-st.txt41
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-synquacer.txt29
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-wmt.txt24
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt15
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c.txt151
-rw-r--r--Documentation/devicetree/bindings/i2c/ibm,i2c-fsi.yaml76
-rw-r--r--Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml2
-rw-r--r--Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml51
-rw-r--r--Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml4
-rw-r--r--Documentation/devicetree/bindings/i2c/mediatek,mt7621-i2c.yaml61
-rw-r--r--Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml6
-rw-r--r--Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml2
-rw-r--r--Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml3
-rw-r--r--Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml70
-rw-r--r--Documentation/devicetree/bindings/i2c/nxp,lpc1788-i2c.yaml54
-rw-r--r--Documentation/devicetree/bindings/i2c/nxp,pca9541.txt29
-rw-r--r--Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml56
-rw-r--r--Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml49
-rw-r--r--Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml1
-rw-r--r--Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml154
-rw-r--r--Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml71
-rw-r--r--Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml16
-rw-r--r--Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml104
-rw-r--r--Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml14
-rw-r--r--Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml21
-rw-r--r--Documentation/devicetree/bindings/i2c/renesas,riic.yaml160
-rw-r--r--Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml24
-rw-r--r--Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml6
-rw-r--r--Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml31
-rw-r--r--Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml29
-rw-r--r--Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml58
-rw-r--r--Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml3
-rw-r--r--Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml3
-rw-r--r--Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml64
-rw-r--r--Documentation/devicetree/bindings/i2c/sprd,sc9860-i2c.yaml65
-rw-r--r--Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml56
-rw-r--r--Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml71
-rw-r--r--Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml100
-rw-r--r--Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml68
-rw-r--r--Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml67
-rw-r--r--Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml47
-rw-r--r--Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml17
-rw-r--r--Documentation/devicetree/bindings/i3c/adi,i3c-master.yaml72
-rw-r--r--Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml72
-rw-r--r--Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml9
-rw-r--r--Documentation/devicetree/bindings/i3c/i3c.yaml38
-rw-r--r--Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml8
-rw-r--r--Documentation/devicetree/bindings/i3c/renesas,i3c.yaml185
-rw-r--r--Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml47
-rw-r--r--Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml22
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml13
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml21
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml31
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml65
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml56
-rw-r--r--Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml95
-rw-r--r--Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml16
-rw-r--r--Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml1
-rw-r--r--Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml11
-rw-r--r--Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml72
-rw-r--r--Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml3
-rw-r--r--Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/accel/lis302.txt2
-rw-r--r--Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml52
-rw-r--r--Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml31
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adc.yaml37
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml246
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml110
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml101
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml262
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4170-4.yaml554
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml268
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml155
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml91
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml46
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml483
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml149
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml192
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml11
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml316
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7405.yaml60
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml171
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml401
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7625.yaml176
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml75
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7779.yaml152
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml19
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml38
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml213
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml18
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml15
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml94
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml93
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,max11410.yaml177
-rw-r--r--Documentation/devicetree/bindings/iio/adc/adi,max14001.yaml89
-rw-r--r--Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml96
-rw-r--r--Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml47
-rw-r--r--Documentation/devicetree/bindings/iio/adc/cosmic,10001-adc.yaml1
-rw-r--r--Documentation/devicetree/bindings/iio/adc/gehc,pmc-adc.yaml86
-rw-r--r--Documentation/devicetree/bindings/iio/adc/holt,hi8435.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml20
-rw-r--r--Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml24
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max11100.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max1118.yaml26
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max11205.yaml69
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml13
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/adc/maxim,max34408.yaml139
-rw-r--r--Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml35
-rw-r--r--Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml205
-rw-r--r--Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml27
-rw-r--r--Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml71
-rw-r--r--Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml120
-rw-r--r--Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/adc/nuvoton,nct7201.yaml70
-rw-r--r--Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml86
-rw-r--r--Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/adc/nxp,lpc3220-adc.yaml3
-rw-r--r--Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml18
-rw-r--r--Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml18
-rw-r--r--Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml118
-rw-r--r--Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml135
-rw-r--r--Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml62
-rw-r--r--Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml39
-rw-r--r--Documentation/devicetree/bindings/iio/adc/renesas,rzn1-adc.yaml111
-rw-r--r--Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml63
-rw-r--r--Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml13
-rw-r--r--Documentation/devicetree/bindings/iio/adc/rohm,bd79104.yaml76
-rw-r--r--Documentation/devicetree/bindings/iio/adc/rohm,bd79112.yaml104
-rw-r--r--Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml114
-rw-r--r--Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml60
-rw-r--r--Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml27
-rw-r--r--Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml83
-rw-r--r--Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml19
-rw-r--r--Documentation/devicetree/bindings/iio/adc/st,spear600-adc.yaml69
-rw-r--r--Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml187
-rw-r--r--Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml132
-rw-r--r--Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml11
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml55
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc0832.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc12138.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc128s052.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,adc161s626.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml28
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml46
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml155
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads1298.yaml79
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml11
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml63
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml110
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads8344.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml11
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml70
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml17
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,tlc4541.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml42
-rw-r--r--Documentation/devicetree/bindings/iio/adc/ti,twl6030-gpadc.yaml43
-rw-r--r--Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml15
-rw-r--r--Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml371
-rw-r--r--Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml26
-rw-r--r--Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml14
-rw-r--r--Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml63
-rw-r--r--Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/chemical/aosong,ags02ma.yaml47
-rw-r--r--Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml62
-rw-r--r--Documentation/devicetree/bindings/iio/chemical/sciosense,ens160.yaml70
-rw-r--r--Documentation/devicetree/bindings/iio/chemical/winsen,mhz19b.yaml33
-rw-r--r--Documentation/devicetree/bindings/iio/common.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml100
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml93
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml28
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5446.yaml138
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml61
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml3
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml10
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml24
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml102
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad8460.yaml164
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ad9739a.yaml95
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml125
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml181
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml160
-rw-r--r--Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml53
-rw-r--r--Documentation/devicetree/bindings/iio/dac/dac.yaml50
-rw-r--r--Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml20
-rw-r--r--Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml49
-rw-r--r--Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml49
-rw-r--r--Documentation/devicetree/bindings/iio/dac/microchip,mcp4821.yaml86
-rw-r--r--Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml81
-rw-r--r--Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml10
-rw-r--r--Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml3
-rw-r--r--Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml20
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adf4371.yaml27
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml13
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml102
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml127
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml67
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml17
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml19
-rw-r--r--Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/gyroscope/invensense,itg3200.yaml59
-rw-r--r--Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml35
-rw-r--r--Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml14
-rw-r--r--Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml14
-rw-r--r--Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/humidity/dht11.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml55
-rw-r--r--Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml21
-rw-r--r--Documentation/devicetree/bindings/iio/humidity/ti,hdc3020.yaml63
-rw-r--r--Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml12
-rw-r--r--Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml62
-rw-r--r--Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml48
-rw-r--r--Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml74
-rw-r--r--Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml46
-rw-r--r--Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml80
-rw-r--r--Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml78
-rw-r--r--Documentation/devicetree/bindings/iio/imu/bosch,bno055.yaml59
-rw-r--r--Documentation/devicetree/bindings/iio/imu/bosch,smi240.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/imu/bosch,smi330.yaml90
-rw-r--r--Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml60
-rw-r--r--Documentation/devicetree/bindings/iio/imu/invensense,icm45600.yaml90
-rw-r--r--Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml39
-rw-r--r--Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml35
-rw-r--r--Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml31
-rw-r--r--Documentation/devicetree/bindings/iio/light/ams,as73211.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml20
-rw-r--r--Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml44
-rw-r--r--Documentation/devicetree/bindings/iio/light/bh1750.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml78
-rw-r--r--Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml8
-rw-r--r--Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/light/liteon,ltr390.yaml56
-rw-r--r--Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml53
-rw-r--r--Documentation/devicetree/bindings/iio/light/rohm,bu27034anuc.yaml45
-rw-r--r--Documentation/devicetree/bindings/iio/light/st,vl6180.yaml1
-rw-r--r--Documentation/devicetree/bindings/iio/light/stk33xx.yaml13
-rw-r--r--Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml68
-rw-r--r--Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/light/veml6030.yaml64
-rw-r--r--Documentation/devicetree/bindings/iio/light/vishay,veml6030.yaml107
-rw-r--r--Documentation/devicetree/bindings/iio/light/vishay,veml6046x00.yaml51
-rw-r--r--Documentation/devicetree/bindings/iio/light/vishay,veml6075.yaml64
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/allegromicro,als31300.yaml46
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml3
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/infineon,tlv493d-a1b6.yaml45
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml48
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml75
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/voltafield,af8133j.yaml59
-rw-r--r--Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml18
-rw-r--r--Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml78
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/aosong,adp810.yaml45
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/bmp085.yaml80
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/fsl,mpl3115.yaml71
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/honeywell,hsc030pa.yaml145
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml158
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/infineon,dps310.yaml54
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/invensense,icp10100.yaml52
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/rohm,bm1390.yaml52
-rw-r--r--Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml46
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml61
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml1
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml60
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/nicera,d3323aa.yaml62
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml5
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml2
-rw-r--r--Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml93
-rw-r--r--Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml177
-rw-r--r--Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml7
-rw-r--r--Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml9
-rw-r--r--Documentation/devicetree/bindings/iio/st,st-sensors.yaml15
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml547
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml4
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml26
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml6
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml23
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/microchip,mcp9600.yaml120
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml48
-rw-r--r--Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml26
-rw-r--r--Documentation/devicetree/bindings/incomplete-devices.yaml285
-rw-r--r--Documentation/devicetree/bindings/index.rst1
-rw-r--r--Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml63
-rw-r--r--Documentation/devicetree/bindings/input/adc-joystick.yaml9
-rw-r--r--Documentation/devicetree/bindings/input/adi,adp5588.yaml139
-rw-r--r--Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml11
-rw-r--r--Documentation/devicetree/bindings/input/atmel,captouch.txt36
-rw-r--r--Documentation/devicetree/bindings/input/atmel,captouch.yaml59
-rw-r--r--Documentation/devicetree/bindings/input/atmel,maxtouch.yaml10
-rw-r--r--Documentation/devicetree/bindings/input/awinic,aw86927.yaml48
-rw-r--r--Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml275
-rw-r--r--Documentation/devicetree/bindings/input/cirrus,cs40l50.yaml68
-rw-r--r--Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml87
-rw-r--r--Documentation/devicetree/bindings/input/cypress,cyapa.txt42
-rw-r--r--Documentation/devicetree/bindings/input/cypress,cyapa.yaml49
-rw-r--r--Documentation/devicetree/bindings/input/da9062-onkey.txt47
-rw-r--r--Documentation/devicetree/bindings/input/dlg,da7280.txt108
-rw-r--r--Documentation/devicetree/bindings/input/dlg,da7280.yaml248
-rw-r--r--Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml38
-rw-r--r--Documentation/devicetree/bindings/input/elan,ekth3000.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/elan,ekth6915.yaml39
-rw-r--r--Documentation/devicetree/bindings/input/fsl,scu-key.yaml4
-rw-r--r--Documentation/devicetree/bindings/input/goodix,gt7375p.yaml26
-rw-r--r--Documentation/devicetree/bindings/input/goodix,gt7986u-spifw.yaml69
-rw-r--r--Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml4
-rw-r--r--Documentation/devicetree/bindings/input/gpio-beeper.txt13
-rw-r--r--Documentation/devicetree/bindings/input/gpio-beeper.yaml33
-rw-r--r--Documentation/devicetree/bindings/input/gpio-keys.yaml43
-rw-r--r--Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt49
-rw-r--r--Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml103
-rw-r--r--Documentation/devicetree/bindings/input/gpio-mouse.txt32
-rw-r--r--Documentation/devicetree/bindings/input/gpio-mouse.yaml68
-rw-r--r--Documentation/devicetree/bindings/input/hid-over-i2c.txt46
-rw-r--r--Documentation/devicetree/bindings/input/hid-over-i2c.yaml85
-rw-r--r--Documentation/devicetree/bindings/input/ibm,op-panel.yaml50
-rw-r--r--Documentation/devicetree/bindings/input/ilitek,ili2901.yaml66
-rw-r--r--Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml67
-rw-r--r--Documentation/devicetree/bindings/input/imx-keypad.yaml4
-rw-r--r--Documentation/devicetree/bindings/input/input.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/iqs269a.yaml98
-rw-r--r--Documentation/devicetree/bindings/input/iqs626a.yaml94
-rw-r--r--Documentation/devicetree/bindings/input/lpc32xx-key.txt34
-rw-r--r--Documentation/devicetree/bindings/input/matrix-keymap.yaml4
-rw-r--r--Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml17
-rw-r--r--Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml95
-rw-r--r--Documentation/devicetree/bindings/input/microchip,cap11xx.yaml89
-rw-r--r--Documentation/devicetree/bindings/input/mtk-pmic-keys.txt46
-rw-r--r--Documentation/devicetree/bindings/input/nxp,lpc3220-key.yaml61
-rw-r--r--Documentation/devicetree/bindings/input/pine64,pinephone-keyboard.yaml66
-rw-r--r--Documentation/devicetree/bindings/input/pwm-beeper.txt24
-rw-r--r--Documentation/devicetree/bindings/input/pwm-beeper.yaml41
-rw-r--r--Documentation/devicetree/bindings/input/pwm-vibrator.yaml6
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml89
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml75
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml42
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt90
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt46
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt23
-rw-r--r--Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml47
-rw-r--r--Documentation/devicetree/bindings/input/regulator-haptic.yaml6
-rw-r--r--Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt56
-rw-r--r--Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt39
-rw-r--r--Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt61
-rw-r--r--Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt56
-rw-r--r--Documentation/devicetree/bindings/input/rotary-encoder.txt50
-rw-r--r--Documentation/devicetree/bindings/input/rotary-encoder.yaml90
-rw-r--r--Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml121
-rw-r--r--Documentation/devicetree/bindings/input/samsung-keypad.txt77
-rw-r--r--Documentation/devicetree/bindings/input/snvs-pwrkey.txt1
-rw-r--r--Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml21
-rw-r--r--Documentation/devicetree/bindings/input/stmpe-keypad.txt41
-rw-r--r--Documentation/devicetree/bindings/input/syna,rmi4.yaml293
-rw-r--r--Documentation/devicetree/bindings/input/tca8418_keypad.txt10
-rw-r--r--Documentation/devicetree/bindings/input/ti,drv260x.txt50
-rw-r--r--Documentation/devicetree/bindings/input/ti,drv260x.yaml109
-rw-r--r--Documentation/devicetree/bindings/input/ti,drv2665.txt17
-rw-r--r--Documentation/devicetree/bindings/input/ti,drv2667.txt17
-rw-r--r--Documentation/devicetree/bindings/input/ti,drv266x.yaml49
-rw-r--r--Documentation/devicetree/bindings/input/ti,nspire-keypad.txt60
-rw-r--r--Documentation/devicetree/bindings/input/ti,nspire-keypad.yaml74
-rw-r--r--Documentation/devicetree/bindings/input/ti,tca8418.yaml61
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/ad7879.txt71
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml150
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/ads7846.txt106
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml70
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt6
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml769
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/bu21013.txt43
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt34
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml111
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml24
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml56
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/eeti.txt30
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt18
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt25
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml58
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml14
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml111
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml96
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/goodix.yaml10
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml64
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/himax,hx852es.yaml81
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816x.yaml65
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml65
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml43
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt38
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt16
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt17
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml46
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml13
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/mstar,msg2638.yaml10
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml72
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml62
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/nxp,lpc3220-tsc.yaml43
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt26
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/rohm,bu21013.yaml95
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt32
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.yaml54
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml52
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml4
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml29
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt41
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml72
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/stmpe.txt109
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/sx8654.txt23
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml183
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml2
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/ti,tsc2007.yaml77
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml77
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt1
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml132
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt39
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/zeitec,zet6223.yaml62
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/zet6223.txt30
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt34
-rw-r--r--Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml12
-rw-r--r--Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt21
-rw-r--r--Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt22
-rw-r--r--Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.yaml36
-rw-r--r--Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml5
-rw-r--r--Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml14
-rw-r--r--Documentation/devicetree/bindings/interconnect/mediatek,mt8183-emi.yaml51
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,glymur-rpmh.yaml172
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,kaanapali-rpmh.yaml124
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,milos-rpmh.yaml136
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml77
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml100
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml20
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml126
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml78
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml39
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml60
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,qcs615-rpmh.yaml73
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml72
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml70
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml28
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml225
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml99
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml98
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sar2130p-rpmh.yaml117
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml124
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml49
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml108
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sdx75-rpmh.yaml92
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm6115.yaml152
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml65
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm7150-rpmh.yaml84
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml124
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml139
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm8650-rpmh.yaml136
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml136
-rw-r--r--Documentation/devicetree/bindings/interconnect/qcom,x1e80100-rpmh.yaml83
-rw-r--r--Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt37
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml4
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt25
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.yaml49
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/allwinner,sun6i-a31-r-intc.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml11
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/altr,msi-controller.yaml65
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.yaml46
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt38
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml94
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/andestech,plicsw.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/apm,xgene1-msi.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml15
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml40
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5-iwb.yaml78
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5.yaml267
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml13
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt36
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,nvic.yaml62
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt36
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.yaml61
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt25
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.yaml46
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.txt23
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml62
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2500-scu-ic.yaml52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc.yaml90
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2xxx-scu-ic.txt23
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt43
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml90
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml60
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt131
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.yaml162
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt37
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.yaml49
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt55
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.yaml81
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml35
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-mx.txt18
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.txt25
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.yaml50
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/chrp,open-pic.yaml78
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt41
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/cirrus,ep7209-intc.yaml71
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/cnxt,cx92755-ic.yaml47
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt62
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.yaml43
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/digicolor-ic.txt21
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/econet,en751221-intc.yaml78
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.txt17
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.yaml34
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.txt25
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.yaml51
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,icoll.yaml45
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,imx8qxp-dc-intc.yaml318
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,intmux.yaml6
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml32
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,ls-msi.yaml79
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt30
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml161
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,mu-msi.yaml95
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,tzic.yaml48
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/fsl,vf610-mscm-ir.yaml62
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt30
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.yaml47
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt84
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.yaml76
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/idt,32434-pic.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt105
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.yaml79
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt26
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml60
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml71
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml4
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt26
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/jcore,aic.yaml43
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml34
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml59
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml4
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml4
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt24
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml51
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml10
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml6
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt18
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.yaml43
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-gicp.yaml50
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-sei.yaml58
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt38
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.txt25
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.yaml52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,cp110-icu.yaml101
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,gicp.txt27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt112
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,mpic.yaml63
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt42
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,orion-bridge-intc.yaml52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt48
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt36
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt33
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml86
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mediatek,mtk-cirq.yaml67
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt43
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml73
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/microchip,pic32-evic.txt67
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mzda-evic.yaml60
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml73
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml6
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml5
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/mti,cpu-interrupt-controller.yaml46
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt41
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml82
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt58
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml68
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/open-pic.txt97
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt23
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml38
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt22
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml45
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-cpu-intc.yaml61
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-misc-intc.yaml52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qca,ath79-cpu-intc.txt44
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt45
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml56
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt78
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml106
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml54
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml82
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml5
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml272
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml280
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml180
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.yaml73
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml172
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-mpxy-system-msi.yaml67
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-system-msi.yaml74
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt53
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml26
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt24
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.yaml42
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt46
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.yaml48
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt22
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.yaml48
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt43
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml64
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt31
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml53
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml63
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/st,spear300-shirq.yaml67
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt44
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt35
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml65
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml19
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml61
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800-irqc.yaml49
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt14
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml49
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-sswi.yaml108
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.yaml50
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt36
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.yaml63
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.txt28
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.yaml52
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt27
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu31
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu.yaml55
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml2
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml7
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml3
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt16
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml76
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml82
-rw-r--r--Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml9
-rw-r--r--Documentation/devicetree/bindings/iommu/apple,dart.yaml10
-rw-r--r--Documentation/devicetree/bindings/iommu/apple,sart.yaml13
-rw-r--r--Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml15
-rw-r--r--Documentation/devicetree/bindings/iommu/arm,smmu.yaml438
-rw-r--r--Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml32
-rw-r--r--Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt64
-rw-r--r--Documentation/devicetree/bindings/iommu/qcom,apq8064-iommu.yaml78
-rw-r--r--Documentation/devicetree/bindings/iommu/qcom,iommu.txt121
-rw-r--r--Documentation/devicetree/bindings/iommu/qcom,iommu.yaml132
-rw-r--r--Documentation/devicetree/bindings/iommu/qcom,tbu.yaml69
-rw-r--r--Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml40
-rw-r--r--Documentation/devicetree/bindings/iommu/riscv,iommu.yaml147
-rw-r--r--Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml12
-rw-r--r--Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml2
-rw-r--r--Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt28
-rw-r--r--Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml44
-rw-r--r--Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml11
-rw-r--r--Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml56
-rw-r--r--Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml4
-rw-r--r--Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml4
-rw-r--r--Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt39
-rw-r--r--Documentation/devicetree/bindings/ipmi/nuvoton,npcm750-kcs-bmc.yaml55
-rw-r--r--Documentation/devicetree/bindings/ipmi/ssif-bmc.yaml38
-rw-r--r--Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml137
-rw-r--r--Documentation/devicetree/bindings/leds/ams,as3645a.txt85
-rw-r--r--Documentation/devicetree/bindings/leds/ams,as3645a.yaml130
-rw-r--r--Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml173
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml57
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/arc,arc2c0608.yaml108
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt33
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/awinic,aw99706.yaml101
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/common.yaml17
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml2
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/kinetic,ktd2801.yaml46
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml86
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml27
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml149
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/lp855x.txt72
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt10
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml2
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml71
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml23
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml16
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml136
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml80
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt23
-rw-r--r--Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.yaml36
-rw-r--r--Documentation/devicetree/bindings/leds/common.yaml125
-rw-r--r--Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml10
-rw-r--r--Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt14
-rw-r--r--Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.yaml36
-rw-r--r--Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml61
-rw-r--r--Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt13
-rw-r--r--Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml37
-rw-r--r--Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt29
-rw-r--r--Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml6
-rw-r--r--Documentation/devicetree/bindings/leds/kinetic,ktd202x.yaml171
-rw-r--r--Documentation/devicetree/bindings/leds/leds-an30259a.txt55
-rw-r--r--Documentation/devicetree/bindings/leds/leds-aw2013.yaml16
-rw-r--r--Documentation/devicetree/bindings/leds/leds-bcm63138.yaml15
-rw-r--r--Documentation/devicetree/bindings/leds/leds-bcm6328.yaml4
-rw-r--r--Documentation/devicetree/bindings/leds/leds-bcm6358.txt2
-rw-r--r--Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml4
-rw-r--r--Documentation/devicetree/bindings/leds/leds-consumer.yaml67
-rw-r--r--Documentation/devicetree/bindings/leds/leds-gpio.yaml2
-rw-r--r--Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml61
-rw-r--r--Documentation/devicetree/bindings/leds/leds-lgm.yaml10
-rw-r--r--Documentation/devicetree/bindings/leds/leds-lm3692x.txt65
-rw-r--r--Documentation/devicetree/bindings/leds/leds-lp50xx.yaml25
-rw-r--r--Documentation/devicetree/bindings/leds/leds-lp55xx.yaml70
-rw-r--r--Documentation/devicetree/bindings/leds/leds-lp8860.txt50
-rw-r--r--Documentation/devicetree/bindings/leds/leds-max77650.yaml9
-rw-r--r--Documentation/devicetree/bindings/leds/leds-mt6323.txt60
-rw-r--r--Documentation/devicetree/bindings/leds/leds-mt6360.yaml240
-rw-r--r--Documentation/devicetree/bindings/leds/leds-pca9532.txt49
-rw-r--r--Documentation/devicetree/bindings/leds/leds-pca955x.txt89
-rw-r--r--Documentation/devicetree/bindings/leds/leds-pm8058.txt67
-rw-r--r--Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml4
-rw-r--r--Documentation/devicetree/bindings/leds/leds-pwm.yaml16
-rw-r--r--Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml160
-rw-r--r--Documentation/devicetree/bindings/leds/leds-rt4505.yaml3
-rw-r--r--Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt43
-rw-r--r--Documentation/devicetree/bindings/leds/leds-sgm3140.yaml6
-rw-r--r--Documentation/devicetree/bindings/leds/leds-tlc591xx.txt40
-rw-r--r--Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml41
-rw-r--r--Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml80
-rw-r--r--Documentation/devicetree/bindings/leds/nxp,pca953x.yaml94
-rw-r--r--Documentation/devicetree/bindings/leds/nxp,pca955x.yaml158
-rw-r--r--Documentation/devicetree/bindings/leds/nxp,pca963x.yaml140
-rw-r--r--Documentation/devicetree/bindings/leds/nxp,pca995x.yaml83
-rw-r--r--Documentation/devicetree/bindings/leds/onnn,ncp5623.yaml98
-rw-r--r--Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml84
-rw-r--r--Documentation/devicetree/bindings/leds/pca963x.txt52
-rw-r--r--Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml57
-rw-r--r--Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml123
-rw-r--r--Documentation/devicetree/bindings/leds/register-bit-led.yaml4
-rw-r--r--Documentation/devicetree/bindings/leds/regulator-led.yaml2
-rw-r--r--Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml81
-rw-r--r--Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml22
-rw-r--r--Documentation/devicetree/bindings/leds/silergy,sy7802.yaml100
-rw-r--r--Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml53
-rw-r--r--Documentation/devicetree/bindings/leds/st,led1202.yaml132
-rw-r--r--Documentation/devicetree/bindings/leds/ti,lp8860.yaml90
-rw-r--r--Documentation/devicetree/bindings/leds/ti,tca6507.yaml4
-rw-r--r--Documentation/devicetree/bindings/leds/ti,tlc59116.yaml90
-rw-r--r--Documentation/devicetree/bindings/leds/ti,tps61310.yaml120
-rw-r--r--Documentation/devicetree/bindings/leds/ti.lm36922.yaml110
-rw-r--r--Documentation/devicetree/bindings/loongarch/cpus.yaml61
-rw-r--r--Documentation/devicetree/bindings/loongarch/loongson.yaml34
-rw-r--r--Documentation/devicetree/bindings/mailbox/allwinner,sun6i-a31-msgbox.yaml14
-rw-r--r--Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml14
-rw-r--r--Documentation/devicetree/bindings/mailbox/apm,xgene-slimpro-mbox.yaml62
-rw-r--r--Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml26
-rw-r--r--Documentation/devicetree/bindings/mailbox/arm,mhu.yaml1
-rw-r--r--Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml3
-rw-r--r--Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml224
-rw-r--r--Documentation/devicetree/bindings/mailbox/aspeed,ast2700-mailbox.yaml68
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt26
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml40
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml64
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt59
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.yaml63
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt25
-rw-r--r--Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.yaml66
-rw-r--r--Documentation/devicetree/bindings/mailbox/cix,sky1-mbox.yaml77
-rw-r--r--Documentation/devicetree/bindings/mailbox/fsl,mu.yaml68
-rw-r--r--Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml69
-rw-r--r--Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt16
-rw-r--r--Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.yaml42
-rw-r--r--Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml83
-rw-r--r--Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml52
-rw-r--r--Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml64
-rw-r--r--Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml28
-rw-r--r--Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml123
-rw-r--r--Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml11
-rw-r--r--Documentation/devicetree/bindings/mailbox/mtk-gce.txt82
-rw-r--r--Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml36
-rw-r--r--Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml253
-rw-r--r--Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml54
-rw-r--r--Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml14
-rw-r--r--Documentation/devicetree/bindings/mailbox/riscv,rpmi-shmem-mbox.yaml124
-rw-r--r--Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml51
-rw-r--r--Documentation/devicetree/bindings/mailbox/rockchip,rk3368-mailbox.yaml56
-rw-r--r--Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt32
-rw-r--r--Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml60
-rw-r--r--Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml6
-rw-r--r--Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml53
-rw-r--r--Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml6
-rw-r--r--Documentation/devicetree/bindings/mailbox/sti-mailbox.txt51
-rw-r--r--Documentation/devicetree/bindings/mailbox/thead,th1520-mbox.yaml89
-rw-r--r--Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml14
-rw-r--r--Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml18
-rw-r--r--Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt35
-rw-r--r--Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml145
-rw-r--r--Documentation/devicetree/bindings/media/allegro,al5e.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml5
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml10
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml8
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml101
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml4
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/allwinner,sun8i-h3-deinterlace.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml4
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,c3-isp.yaml88
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,c3-mipi-adapter.yaml111
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,c3-mipi-csi2.yaml127
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml7
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml5
-rw-r--r--Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml48
-rw-r--r--Documentation/devicetree/bindings/media/amphion,vpu.yaml12
-rw-r--r--Documentation/devicetree/bindings/media/arm,mali-c55.yaml86
-rw-r--r--Documentation/devicetree/bindings/media/aspeed,video-engine.yaml70
-rw-r--r--Documentation/devicetree/bindings/media/aspeed-video.txt33
-rw-r--r--Documentation/devicetree/bindings/media/atmel,isc.yaml4
-rw-r--r--Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml127
-rw-r--r--Documentation/devicetree/bindings/media/cdns,csi2rx.txt100
-rw-r--r--Documentation/devicetree/bindings/media/cdns,csi2rx.yaml210
-rw-r--r--Documentation/devicetree/bindings/media/cec-gpio.txt42
-rw-r--r--Documentation/devicetree/bindings/media/cec.txt8
-rw-r--r--Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml (renamed from Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml)11
-rw-r--r--Documentation/devicetree/bindings/media/cec/cec-common.yaml28
-rw-r--r--Documentation/devicetree/bindings/media/cec/cec-gpio.yaml74
-rw-r--r--Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml63
-rw-r--r--Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml66
-rw-r--r--Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml66
-rw-r--r--Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml (renamed from Documentation/devicetree/bindings/media/st,stm32-cec.yaml)8
-rw-r--r--Documentation/devicetree/bindings/media/cnm,wave521c.yaml61
-rw-r--r--Documentation/devicetree/bindings/media/exynos-fimc-lite.txt16
-rw-r--r--Documentation/devicetree/bindings/media/exynos4-fimc-is.txt50
-rw-r--r--Documentation/devicetree/bindings/media/fsl,imx-capture-subsystem.yaml37
-rw-r--r--Documentation/devicetree/bindings/media/fsl,imx6-mipi-csi2.yaml143
-rw-r--r--Documentation/devicetree/bindings/media/fsl,imx6q-vdoa.yaml42
-rw-r--r--Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml87
-rw-r--r--Documentation/devicetree/bindings/media/fsl,imx8qm-isi.yaml117
-rw-r--r--Documentation/devicetree/bindings/media/fsl,imx8qxp-isi.yaml106
-rw-r--r--Documentation/devicetree/bindings/media/fsl-pxp.txt26
-rw-r--r--Documentation/devicetree/bindings/media/fsl-vdoa.txt21
-rw-r--r--Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml3
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ad5820.txt28
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adi,ad5820.yaml56
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adi,adp1653.txt (renamed from Documentation/devicetree/bindings/media/i2c/adp1653.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adi,adv7180.yaml189
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adi,adv7343.txt (renamed from Documentation/devicetree/bindings/media/i2c/adv7343.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adi,adv748x.yaml212
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adi,adv7604.yaml158
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adv7180.yaml179
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adv748x.yaml212
-rw-r--r--Documentation/devicetree/bindings/media/i2c/adv7604.yaml160
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ak7375.txt8
-rw-r--r--Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml81
-rw-r--r--Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/i2c/aptina,mt9v032.txt (renamed from Documentation/devicetree/bindings/media/i2c/mt9v032.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml54
-rw-r--r--Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml15
-rw-r--r--Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt9
-rw-r--r--Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml47
-rw-r--r--Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml89
-rw-r--r--Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml8
-rw-r--r--Documentation/devicetree/bindings/media/i2c/galaxycore,gc0308.yaml108
-rw-r--r--Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml112
-rw-r--r--Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml112
-rw-r--r--Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml113
-rw-r--r--Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml17
-rw-r--r--Documentation/devicetree/bindings/media/i2c/imx219.yaml109
-rw-r--r--Documentation/devicetree/bindings/media/i2c/imx258.yaml134
-rw-r--r--Documentation/devicetree/bindings/media/i2c/imx290.txt57
-rw-r--r--Documentation/devicetree/bindings/media/i2c/maxim,max2175.txt (renamed from Documentation/devicetree/bindings/media/i2c/max2175.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml60
-rw-r--r--Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml12
-rw-r--r--Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml174
-rw-r--r--Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml157
-rw-r--r--Documentation/devicetree/bindings/media/i2c/micron,mt9m111.txt (renamed from Documentation/devicetree/bindings/media/i2c/mt9m111.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml25
-rw-r--r--Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml162
-rw-r--r--Documentation/devicetree/bindings/media/i2c/onnn,mt9m001.txt (renamed from Documentation/devicetree/bindings/media/i2c/mt9m001.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml123
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ov2685.txt41
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ov5645.txt54
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ov5695.txt41
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ov7251.txt52
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ov8856.yaml134
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml107
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,og0ve1b.yaml97
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml15
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov02e10.yaml152
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml120
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov2640.txt (renamed from Documentation/devicetree/bindings/media/i2c/ov2640.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov2659.txt (renamed from Documentation/devicetree/bindings/media/i2c/ov2659.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml35
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml102
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov2735.yaml108
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml130
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml9
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5642.yaml141
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5645.yaml108
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml15
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml93
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml122
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml33
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov6211.yaml96
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml103
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml113
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov7670.txt (renamed from Documentation/devicetree/bindings/media/i2c/ov7670.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml5
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov7740.txt (renamed from Documentation/devicetree/bindings/media/i2c/ov7740.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml131
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml108
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml14
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml24
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ovti,ov9650.txt (renamed from Documentation/devicetree/bindings/media/i2c/ov9650.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml105
-rw-r--r--Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml102
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml105
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml35
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx219.yaml112
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml135
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml6
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml107
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml146
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml106
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml12
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml25
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml14
-rw-r--r--Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml115
-rw-r--r--Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt82
-rw-r--r--Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml175
-rw-r--r--Documentation/devicetree/bindings/media/i2c/st,st-vgxy61.yaml113
-rw-r--r--Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml137
-rw-r--r--Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml139
-rw-r--r--Documentation/devicetree/bindings/media/i2c/tda1997x.txt178
-rw-r--r--Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml136
-rw-r--r--Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml223
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml133
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml147
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml441
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,ths8200.txt (renamed from Documentation/devicetree/bindings/media/i2c/ths8200.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,tvp514x.txt (renamed from Documentation/devicetree/bindings/media/i2c/tvp514x.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml133
-rw-r--r--Documentation/devicetree/bindings/media/i2c/ti,tvp7002.txt (renamed from Documentation/devicetree/bindings/media/i2c/tvp7002.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt8
-rw-r--r--Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt (renamed from Documentation/devicetree/bindings/media/i2c/tc358743.txt)0
-rw-r--r--Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml180
-rw-r--r--Documentation/devicetree/bindings/media/i2c/tvp5150.txt157
-rw-r--r--Documentation/devicetree/bindings/media/img,e5010-jpeg-enc.yaml75
-rw-r--r--Documentation/devicetree/bindings/media/imx.txt53
-rw-r--r--Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml5
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml65
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml65
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml107
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml7
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml65
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml66
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml65
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml30
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mt7622-cir.yaml55
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml169
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml74
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml161
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml140
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml73
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml49
-rw-r--r--Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml218
-rw-r--r--Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml6
-rw-r--r--Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml11
-rw-r--r--Documentation/devicetree/bindings/media/mediatek-mdp.txt95
-rw-r--r--Documentation/devicetree/bindings/media/mediatek-vpu.txt31
-rw-r--r--Documentation/devicetree/bindings/media/meson-ir.txt20
-rw-r--r--Documentation/devicetree/bindings/media/microchip,csi2dc.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml23
-rw-r--r--Documentation/devicetree/bindings/media/microchip,xisc.yaml3
-rw-r--r--Documentation/devicetree/bindings/media/mtk-cir.txt28
-rw-r--r--Documentation/devicetree/bindings/media/nokia,n900-ir20
-rw-r--r--Documentation/devicetree/bindings/media/nuvoton,npcm-ece.yaml43
-rw-r--r--Documentation/devicetree/bindings/media/nuvoton,npcm-vcd.yaml72
-rw-r--r--Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml18
-rw-r--r--Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml14
-rw-r--r--Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml190
-rw-r--r--Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml40
-rw-r--r--Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml38
-rw-r--r--Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml45
-rw-r--r--Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml15
-rw-r--r--Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml87
-rw-r--r--Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml254
-rw-r--r--Documentation/devicetree/bindings/media/qcom,msm8953-camss.yaml337
-rw-r--r--Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml27
-rw-r--r--Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml149
-rw-r--r--Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml243
-rw-r--r--Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml130
-rw-r--r--Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml336
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sa8775p-camss.yaml361
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml101
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml425
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml128
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml531
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml27
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml143
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml318
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml47
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml113
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml103
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml63
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml119
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml597
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml199
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml375
-rw-r--r--Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml186
-rw-r--r--Documentation/devicetree/bindings/media/qcom,venus-common.yaml73
-rw-r--r--Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml367
-rw-r--r--Documentation/devicetree/bindings/media/raspberrypi,pispbe.yaml63
-rw-r--r--Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml93
-rw-r--r--Documentation/devicetree/bindings/media/rc.yaml7
-rw-r--r--Documentation/devicetree/bindings/media/renesas,ceu.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/renesas,csi2.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/renesas,fcp.yaml49
-rw-r--r--Documentation/devicetree/bindings/media/renesas,isp.yaml68
-rw-r--r--Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml103
-rw-r--r--Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml227
-rw-r--r--Documentation/devicetree/bindings/media/renesas,rzg2l-csi2.yaml182
-rw-r--r--Documentation/devicetree/bindings/media/renesas,vin.yaml17
-rw-r--r--Documentation/devicetree/bindings/media/renesas,vsp1.yaml40
-rw-r--r--Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml124
-rw-r--r--Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml6
-rw-r--r--Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml172
-rw-r--r--Documentation/devicetree/bindings/media/rockchip,vdec.yaml83
-rw-r--r--Documentation/devicetree/bindings/media/rockchip-isp1.yaml91
-rw-r--r--Documentation/devicetree/bindings/media/rockchip-rga.yaml5
-rw-r--r--Documentation/devicetree/bindings/media/rockchip-vpu.yaml50
-rw-r--r--Documentation/devicetree/bindings/media/s5p-cec.txt36
-rw-r--r--Documentation/devicetree/bindings/media/s5p-mfc.txt76
-rw-r--r--Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml170
-rw-r--r--Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml152
-rw-r--r--Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml225
-rw-r--r--Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml63
-rw-r--r--Documentation/devicetree/bindings/media/samsung,fimc.yaml278
-rw-r--r--Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml165
-rw-r--r--Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml195
-rw-r--r--Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml1
-rw-r--r--Documentation/devicetree/bindings/media/samsung-fimc.txt209
-rw-r--r--Documentation/devicetree/bindings/media/samsung-mipi-csis.txt81
-rw-r--r--Documentation/devicetree/bindings/media/samsung-s5c73m3.txt97
-rw-r--r--Documentation/devicetree/bindings/media/samsung-s5k5baf.txt58
-rw-r--r--Documentation/devicetree/bindings/media/samsung-s5k6a3.txt33
-rw-r--r--Documentation/devicetree/bindings/media/si470x.txt26
-rw-r--r--Documentation/devicetree/bindings/media/silabs,si470x.yaml48
-rw-r--r--Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml132
-rw-r--r--Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml10
-rw-r--r--Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml130
-rw-r--r--Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml3
-rw-r--r--Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml124
-rw-r--r--Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml53
-rw-r--r--Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml180
-rw-r--r--Documentation/devicetree/bindings/media/stih-cec.txt27
-rw-r--r--Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt88
-rw-r--r--Documentation/devicetree/bindings/media/tegra-cec.txt27
-rw-r--r--Documentation/devicetree/bindings/media/ti,cal.yaml8
-rw-r--r--Documentation/devicetree/bindings/media/ti,j721e-csi2rx-shim.yaml100
-rw-r--r--Documentation/devicetree/bindings/media/ti,vpe.yaml2
-rw-r--r--Documentation/devicetree/bindings/media/video-interface-devices.yaml14
-rw-r--r--Documentation/devicetree/bindings/media/video-interfaces.yaml31
-rw-r--r--Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml2
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt127
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/arm,pl172.yaml222
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml130
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml156
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/brcm,brcmstb-memc-ddr.yaml58
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml2
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml146
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml74
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml48
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml44
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml35
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml46
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml38
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml31
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml34
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml31
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim.yaml201
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml3
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml4
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-peripherals.yaml2
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml4
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml107
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml80
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml44
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml3
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml7
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml50
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml1
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml84
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml4
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml11
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml7
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml90
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/qcom,ebi2.yaml156
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml4
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml14
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml142
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml6
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml35
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml6
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml33
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml3
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml144
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml152
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml226
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/starfive,jh7110-dmc.yaml74
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml9
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml8
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml57
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/xlnx,versal-net-ddrmc5.yaml41
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml5
-rw-r--r--Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml45
-rw-r--r--Documentation/devicetree/bindings/mfd/act8945a.txt82
-rw-r--r--Documentation/devicetree/bindings/mfd/actions,atc260x.yaml10
-rw-r--r--Documentation/devicetree/bindings/mfd/adi,adp5585.yaml313
-rw-r--r--Documentation/devicetree/bindings/mfd/adi,max77541.yaml68
-rw-r--r--Documentation/devicetree/bindings/mfd/airoha,en7581-gpio-sysctl.yaml90
-rw-r--r--Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml59
-rw-r--r--Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml44
-rw-r--r--Documentation/devicetree/bindings/mfd/ampere,smpro.yaml42
-rw-r--r--Documentation/devicetree/bindings/mfd/ams,as3711.yaml223
-rw-r--r--Documentation/devicetree/bindings/mfd/apple,smc.yaml84
-rw-r--r--Documentation/devicetree/bindings/mfd/arm,dev-platforms-syscon.yaml67
-rw-r--r--Documentation/devicetree/bindings/mfd/as3711.txt73
-rw-r--r--Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml70
-rw-r--r--Documentation/devicetree/bindings/mfd/aspeed-gfx.txt17
-rw-r--r--Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml23
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml45
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml52
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml99
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml98
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel-flexcom.txt63
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel-gpbr.txt17
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt55
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel-matrix.txt25
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel-smc.txt1
-rw-r--r--Documentation/devicetree/bindings/mfd/atmel-usart.txt98
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt39
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml76
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml8
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml26
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml8
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml8
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml10
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml10
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,cru.yaml8
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt16
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt18
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,misc.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/brcm,twd.yaml8
-rw-r--r--Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml10
-rw-r--r--Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/da9052-i2c.txt67
-rw-r--r--Documentation/devicetree/bindings/mfd/da9062.txt123
-rw-r--r--Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml4
-rw-r--r--Documentation/devicetree/bindings/mfd/dlg,da9052.yaml89
-rw-r--r--Documentation/devicetree/bindings/mfd/dlg,da9063.yaml270
-rw-r--r--Documentation/devicetree/bindings/mfd/ene-kb3930.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/ene-kb930.yaml8
-rw-r--r--Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml192
-rw-r--r--Documentation/devicetree/bindings/mfd/fsl,mc13xxx.yaml300
-rw-r--r--Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml53
-rw-r--r--Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml203
-rw-r--r--Documentation/devicetree/bindings/mfd/google,cros-ec.yaml225
-rw-r--r--Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml142
-rw-r--r--Documentation/devicetree/bindings/mfd/iqs62x.yaml183
-rw-r--r--Documentation/devicetree/bindings/mfd/khadas,mcu.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/lp3943.txt2
-rw-r--r--Documentation/devicetree/bindings/mfd/lp873x.txt67
-rw-r--r--Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml80
-rw-r--r--Documentation/devicetree/bindings/mfd/max77650.yaml10
-rw-r--r--Documentation/devicetree/bindings/mfd/max8925.txt64
-rw-r--r--Documentation/devicetree/bindings/mfd/max8998.txt125
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max5970.yaml156
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max7360.yaml191
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max77686.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max77693.yaml50
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max77705.yaml172
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max77759.yaml99
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max8925.yaml145
-rw-r--r--Documentation/devicetree/bindings/mfd/maxim,max8998.yaml324
-rw-r--r--Documentation/devicetree/bindings/mfd/mc13xxx.txt156
-rw-r--r--Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml135
-rw-r--r--Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml9
-rw-r--r--Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml600
-rw-r--r--Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml3
-rw-r--r--Documentation/devicetree/bindings/mfd/mfd.txt15
-rw-r--r--Documentation/devicetree/bindings/mfd/motorola-cpcap.txt8
-rw-r--r--Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml19
-rw-r--r--Documentation/devicetree/bindings/mfd/mt6397.txt107
-rw-r--r--Documentation/devicetree/bindings/mfd/mxs-lradc.txt45
-rw-r--r--Documentation/devicetree/bindings/mfd/mxs-lradc.yaml134
-rw-r--r--Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml39
-rw-r--r--Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml101
-rw-r--r--Documentation/devicetree/bindings/mfd/nxp,lpc1850-creg.yaml148
-rw-r--r--Documentation/devicetree/bindings/mfd/nxp,pf1550.yaml161
-rw-r--r--Documentation/devicetree/bindings/mfd/omap-usb-host.txt8
-rw-r--r--Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml152
-rw-r--r--Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml93
-rw-r--r--Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml23
-rw-r--r--Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml64
-rw-r--r--Documentation/devicetree/bindings/mfd/qcom-rpm.txt283
-rw-r--r--Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml46
-rw-r--r--Documentation/devicetree/bindings/mfd/renesas,r2a11302ft.yaml58
-rw-r--r--Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml4
-rw-r--r--Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml138
-rw-r--r--Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml429
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml284
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml274
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml75
-rw-r--r--Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml28
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml32
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml5
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml52
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml10
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml177
-rw-r--r--Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml101
-rw-r--r--Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/samsung,s2dos05.yaml99
-rw-r--r--Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml56
-rw-r--r--Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml29
-rw-r--r--Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml11
-rw-r--r--Documentation/devicetree/bindings/mfd/spacemit,p1.yaml86
-rw-r--r--Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml244
-rw-r--r--Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt40
-rw-r--r--Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml4
-rw-r--r--Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml46
-rw-r--r--Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml24
-rw-r--r--Documentation/devicetree/bindings/mfd/st,stmfx.yaml4
-rw-r--r--Documentation/devicetree/bindings/mfd/st,stmpe.yaml297
-rw-r--r--Documentation/devicetree/bindings/mfd/st,stpmic1.yaml20
-rw-r--r--Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml65
-rw-r--r--Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml64
-rw-r--r--Documentation/devicetree/bindings/mfd/stmpe.txt42
-rw-r--r--Documentation/devicetree/bindings/mfd/syscon-common.yaml68
-rw-r--r--Documentation/devicetree/bindings/mfd/syscon.yaml237
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml5
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml117
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml95
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,lp8732.yaml112
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,lp87524-q1.yaml3
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,lp87561-q1.yaml3
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml3
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml51
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,tps65086.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,tps65910.yaml315
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,tps6594.yaml196
-rw-r--r--Documentation/devicetree/bindings/mfd/ti,twl.yaml585
-rw-r--r--Documentation/devicetree/bindings/mfd/tps65910.txt205
-rw-r--r--Documentation/devicetree/bindings/mfd/twl-family.txt46
-rw-r--r--Documentation/devicetree/bindings/mfd/twl4030-audio.txt46
-rw-r--r--Documentation/devicetree/bindings/mfd/twl4030-power.txt48
-rw-r--r--Documentation/devicetree/bindings/mfd/twl6040.txt2
-rw-r--r--Documentation/devicetree/bindings/mfd/wlf,arizona.yaml2
-rw-r--r--Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml6
-rw-r--r--Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml247
-rw-r--r--Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml4
-rw-r--r--Documentation/devicetree/bindings/mfd/zii,rave-sp.txt39
-rw-r--r--Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml63
-rw-r--r--Documentation/devicetree/bindings/mips/brcm/brcm,bmips.txt8
-rw-r--r--Documentation/devicetree/bindings/mips/brcm/soc.yaml120
-rw-r--r--Documentation/devicetree/bindings/mips/cpu_irq.txt47
-rw-r--r--Documentation/devicetree/bindings/mips/cpus.yaml118
-rw-r--r--Documentation/devicetree/bindings/mips/econet.yaml26
-rw-r--r--Documentation/devicetree/bindings/mips/ingenic/devices.yaml2
-rw-r--r--Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml69
-rw-r--r--Documentation/devicetree/bindings/mips/lantiq/lantiq,dma-xway.yaml2
-rw-r--r--Documentation/devicetree/bindings/mips/loongson/devices.yaml16
-rw-r--r--Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml4
-rw-r--r--Documentation/devicetree/bindings/mips/mobileye.yaml37
-rw-r--r--Documentation/devicetree/bindings/mips/mscc.txt17
-rw-r--r--Documentation/devicetree/bindings/mips/mti,mips-cm.yaml57
-rw-r--r--Documentation/devicetree/bindings/mips/ralink.yaml3
-rw-r--r--Documentation/devicetree/bindings/mips/realtek-rtl.yaml6
-rw-r--r--Documentation/devicetree/bindings/misc/aspeed,ast2400-cvic.yaml60
-rw-r--r--Documentation/devicetree/bindings/misc/aspeed,cvic.txt35
-rw-r--r--Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt46
-rw-r--r--Documentation/devicetree/bindings/misc/atmel-ssc.txt50
-rw-r--r--Documentation/devicetree/bindings/misc/brcm,kona-smc.txt15
-rw-r--r--Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml2
-rw-r--r--Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt196
-rw-r--r--Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml187
-rw-r--r--Documentation/devicetree/bindings/misc/idt,89hpesx.yaml72
-rw-r--r--Documentation/devicetree/bindings/misc/idt_89hpesx.txt44
-rw-r--r--Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml10
-rw-r--r--Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml54
-rw-r--r--Documentation/devicetree/bindings/misc/lwn-bk4.txt26
-rw-r--r--Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml1
-rw-r--r--Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml2
-rw-r--r--Documentation/devicetree/bindings/misc/pci1de4,1.yaml137
-rw-r--r--Documentation/devicetree/bindings/misc/qcom,fastrpc.txt88
-rw-r--r--Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml149
-rw-r--r--Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml6
-rw-r--r--Documentation/devicetree/bindings/misc/ti,fpc202.yaml94
-rw-r--r--Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml53
-rw-r--r--Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt58
-rw-r--r--Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml140
-rw-r--r--Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml47
-rw-r--r--Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml47
-rw-r--r--Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml42
-rw-r--r--Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml79
-rw-r--r--Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt39
-rw-r--r--Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml4
-rw-r--r--Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt54
-rw-r--r--Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml97
-rw-r--r--Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml74
-rw-r--r--Documentation/devicetree/bindings/mmc/arm,pl18x.yaml17
-rw-r--r--Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml1
-rw-r--r--Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml106
-rw-r--r--Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml93
-rw-r--r--Documentation/devicetree/bindings/mmc/atmel-hsmci.txt73
-rw-r--r--Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt23
-rw-r--r--Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml54
-rw-r--r--Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt21
-rw-r--r--Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml48
-rw-r--r--Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml11
-rw-r--r--Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml54
-rw-r--r--Documentation/devicetree/bindings/mmc/davinci_mmc.txt32
-rw-r--r--Documentation/devicetree/bindings/mmc/fsl,esdhc.yaml107
-rw-r--r--Documentation/devicetree/bindings/mmc/fsl-esdhc.txt52
-rw-r--r--Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml44
-rw-r--r--Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml14
-rw-r--r--Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml66
-rw-r--r--Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt40
-rw-r--r--Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml97
-rw-r--r--Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml2
-rw-r--r--Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml112
-rw-r--r--Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml77
-rw-r--r--Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml6
-rw-r--r--Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt29
-rw-r--r--Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.yaml66
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-card.yaml54
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml365
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-controller.yaml347
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml4
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml4
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml4
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-slot.yaml48
-rw-r--r--Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml18
-rw-r--r--Documentation/devicetree/bindings/mmc/mtk-sd.yaml227
-rw-r--r--Documentation/devicetree/bindings/mmc/mxs-mmc.yaml7
-rw-r--r--Documentation/devicetree/bindings/mmc/npcm,sdhci.yaml45
-rw-r--r--Documentation/devicetree/bindings/mmc/nuvoton,ma35d1-sdhci.yaml87
-rw-r--r--Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml37
-rw-r--r--Documentation/devicetree/bindings/mmc/owl-mmc.yaml2
-rw-r--r--Documentation/devicetree/bindings/mmc/pxa-mmc.txt2
-rw-r--r--Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml2
-rw-r--r--Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml227
-rw-r--r--Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml13
-rw-r--r--Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml31
-rw-r--r--Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt42
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-am654.yaml72
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-atmel.txt33
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-common.yaml32
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt32
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt30
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-msm.yaml63
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-omap.txt43
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml52
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-sprd.txt67
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci.txt13
-rw-r--r--Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml150
-rw-r--r--Documentation/devicetree/bindings/mmc/socionext,milbeaut-m10v-sdhci-3.0.yaml79
-rw-r--r--Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml10
-rw-r--r--Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml53
-rw-r--r--Documentation/devicetree/bindings/mmc/sprd,sdhci-r11.yaml112
-rw-r--r--Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml75
-rw-r--r--Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml61
-rw-r--r--Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml2
-rw-r--r--Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml38
-rw-r--r--Documentation/devicetree/bindings/mmc/ti,da830-mmc.yaml61
-rw-r--r--Documentation/devicetree/bindings/mmc/ti,omap2430-sdhci.yaml169
-rw-r--r--Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt2
-rw-r--r--Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt23
-rw-r--r--Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml66
-rw-r--r--Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml82
-rw-r--r--Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt60
-rw-r--r--Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml124
-rw-r--r--Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml11
-rw-r--r--Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml37
-rw-r--r--Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml55
-rw-r--r--Documentation/devicetree/bindings/mtd/atmel-dataflash.txt17
-rw-r--r--Documentation/devicetree/bindings/mtd/atmel-nand.txt16
-rw-r--r--Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml143
-rw-r--r--Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt53
-rw-r--r--Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml84
-rw-r--r--Documentation/devicetree/bindings/mtd/davinci-nand.txt94
-rw-r--r--Documentation/devicetree/bindings/mtd/denali,nand.yaml11
-rw-r--r--Documentation/devicetree/bindings/mtd/flctl-nand.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml89
-rw-r--r--Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/gpio-control-nand.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/gpmi-nand.yaml35
-rw-r--r--Documentation/devicetree/bindings/mtd/hisi504-nand.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/ingenic,nand.yaml152
-rw-r--r--Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml90
-rw-r--r--Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml99
-rw-r--r--Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml53
-rw-r--r--Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml122
-rw-r--r--Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml226
-rw-r--r--Documentation/devicetree/bindings/mtd/marvell-nand.txt126
-rw-r--r--Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml154
-rw-r--r--Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml63
-rw-r--r--Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml27
-rw-r--r--Documentation/devicetree/bindings/mtd/mtd-physmap.yaml25
-rw-r--r--Documentation/devicetree/bindings/mtd/mtd.yaml34
-rw-r--r--Documentation/devicetree/bindings/mtd/mtk-nand.txt176
-rw-r--r--Documentation/devicetree/bindings/mtd/mxc-nand.yaml12
-rw-r--r--Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml2
-rw-r--r--Documentation/devicetree/bindings/mtd/nand-chip.yaml6
-rw-r--r--Documentation/devicetree/bindings/mtd/nand-controller.yaml89
-rw-r--r--Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml95
-rw-r--r--Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/nxp,lpc1773-spifi.yaml74
-rw-r--r--Documentation/devicetree/bindings/mtd/nxp-spifi.txt58
-rw-r--r--Documentation/devicetree/bindings/mtd/orion-nand.txt2
-rw-r--r--Documentation/devicetree/bindings/mtd/oxnas-nand.txt41
-rw-r--r--Documentation/devicetree/bindings/mtd/partition.txt33
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml2
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/binman.yaml53
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml4
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml2
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml49
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml4
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/linux,ubi.yaml75
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml5
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/partition.yaml78
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/partitions.yaml42
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml40
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml6
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/seama.yaml44
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/tplink,safeloader-partitions.yaml57
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml56
-rw-r--r--Documentation/devicetree/bindings/mtd/partitions/ubi-volume.yaml40
-rw-r--r--Documentation/devicetree/bindings/mtd/qcom,nandc.yaml230
-rw-r--r--Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml111
-rw-r--r--Documentation/devicetree/bindings/mtd/realtek,rtl9301-ecc.yaml41
-rw-r--r--Documentation/devicetree/bindings/mtd/renesas-nandc.yaml4
-rw-r--r--Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml9
-rw-r--r--Documentation/devicetree/bindings/mtd/samsung,s5pv210-onenand.yaml65
-rw-r--r--Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt56
-rw-r--r--Documentation/devicetree/bindings/mtd/spi-nand.yaml4
-rw-r--r--Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml79
-rw-r--r--Documentation/devicetree/bindings/mtd/technologic,nand.yaml45
-rw-r--r--Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml38
-rw-r--r--Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml124
-rw-r--r--Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml7
-rw-r--r--Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml7
-rw-r--r--Documentation/devicetree/bindings/mtd/vf610-nfc.txt59
-rw-r--r--Documentation/devicetree/bindings/mux/gpio-mux.yaml6
-rw-r--r--Documentation/devicetree/bindings/mux/mux-consumer.yaml2
-rw-r--r--Documentation/devicetree/bindings/mux/mux-controller.yaml5
-rw-r--r--Documentation/devicetree/bindings/mux/reg-mux.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/actions,owl-emac.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/adi,adin.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/adi,adin1110.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/aeonsemi,as21xxx.yaml122
-rw-r--r--Documentation/devicetree/bindings/net/airoha,an7583-mdio.yaml59
-rw-r--r--Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml199
-rw-r--r--Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml99
-rw-r--r--Documentation/devicetree/bindings/net/airoha,en8811h.yaml56
-rw-r--r--Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml13
-rw-r--r--Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml106
-rw-r--r--Documentation/devicetree/bindings/net/altr,gmii-to-sgmii-2.0.yaml49
-rw-r--r--Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml178
-rw-r--r--Documentation/devicetree/bindings/net/altr,tse.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/amd,xgbe-seattle-v1a.yaml147
-rw-r--r--Documentation/devicetree/bindings/net/amd-xgbe.txt76
-rw-r--r--Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml80
-rw-r--r--Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml64
-rw-r--r--Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml50
-rw-r--r--Documentation/devicetree/bindings/net/apm,xgene-enet.yaml115
-rw-r--r--Documentation/devicetree/bindings/net/apm,xgene-mdio-rgmii.yaml54
-rw-r--r--Documentation/devicetree/bindings/net/apm-xgene-enet.txt91
-rw-r--r--Documentation/devicetree/bindings/net/apm-xgene-mdio.txt37
-rw-r--r--Documentation/devicetree/bindings/net/arc_emac.txt46
-rw-r--r--Documentation/devicetree/bindings/net/asix,ax88178.yaml10
-rw-r--r--Documentation/devicetree/bindings/net/asix,ax88796c.yaml5
-rw-r--r--Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml9
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth.txt5
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/amlogic,w155s2-bt.yaml63
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/bluetooth-controller.yaml29
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml82
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/brcm,bluetooth.yaml163
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/marvell,88w8897.yaml49
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/marvell,sd8897-bt.yaml79
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/mediatek,bluetooth.txt80
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml51
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml55
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/nokia,h4p-bluetooth.txt (renamed from Documentation/devicetree/bindings/net/nokia-bluetooth.txt)0
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml109
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml259
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/realtek,bluetooth.yaml68
-rw-r--r--Documentation/devicetree/bindings/net/bluetooth/ti,bluetooth.yaml (renamed from Documentation/devicetree/bindings/net/ti,bluetooth.yaml)5
-rw-r--r--Documentation/devicetree/bindings/net/brcm,amac.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml158
-rw-r--r--Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt50
-rw-r--r--Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml39
-rw-r--r--Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml51
-rw-r--r--Documentation/devicetree/bindings/net/brcm,systemport.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml156
-rw-r--r--Documentation/devicetree/bindings/net/btusb.txt2
-rw-r--r--Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml8
-rw-r--r--Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml58
-rw-r--r--Documentation/devicetree/bindings/net/can/atmel-can.txt15
-rw-r--r--Documentation/devicetree/bindings/net/can/bosch,c_can.yaml12
-rw-r--r--Documentation/devicetree/bindings/net/can/bosch,m_can.yaml56
-rw-r--r--Documentation/devicetree/bindings/net/can/can-controller.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/can/can-transceiver.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/can/cc770.txt2
-rw-r--r--Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml66
-rw-r--r--Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml70
-rw-r--r--Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt30
-rw-r--r--Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml13
-rw-r--r--Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml15
-rw-r--r--Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml252
-rw-r--r--Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml74
-rw-r--r--Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml96
-rw-r--r--Documentation/devicetree/bindings/net/can/tcan4x5x.txt40
-rw-r--r--Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml199
-rw-r--r--Documentation/devicetree/bindings/net/can/xilinx,can.yaml16
-rw-r--r--Documentation/devicetree/bindings/net/cdns,macb.yaml59
-rw-r--r--Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml59
-rw-r--r--Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml7
-rw-r--r--Documentation/devicetree/bindings/net/davicom,dm9000.yaml59
-rw-r--r--Documentation/devicetree/bindings/net/davicom-dm9000.txt27
-rw-r--r--Documentation/devicetree/bindings/net/dsa/ar9331.txt147
-rw-r--r--Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml14
-rw-r--r--Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml30
-rw-r--r--Documentation/devicetree/bindings/net/dsa/dsa-port.yaml33
-rw-r--r--Documentation/devicetree/bindings/net/dsa/dsa.yaml38
-rw-r--r--Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml350
-rw-r--r--Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt146
-rw-r--r--Documentation/devicetree/bindings/net/dsa/marvell,mv88e6060.yaml88
-rw-r--r--Documentation/devicetree/bindings/net/dsa/marvell,mv88e6xxx.yaml337
-rw-r--r--Documentation/devicetree/bindings/net/dsa/marvell.txt109
-rw-r--r--Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml133
-rw-r--r--Documentation/devicetree/bindings/net/dsa/micrel,ks8995.yaml135
-rw-r--r--Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml117
-rw-r--r--Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml7
-rw-r--r--Documentation/devicetree/bindings/net/dsa/motorcomm,yt921x.yaml167
-rw-r--r--Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml50
-rw-r--r--Documentation/devicetree/bindings/net/dsa/qca,ar9331.yaml161
-rw-r--r--Documentation/devicetree/bindings/net/dsa/qca8k.yaml37
-rw-r--r--Documentation/devicetree/bindings/net/dsa/realtek.yaml54
-rw-r--r--Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml14
-rw-r--r--Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt129
-rw-r--r--Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml194
-rw-r--r--Documentation/devicetree/bindings/net/engleder,tsnep.yaml7
-rw-r--r--Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml129
-rw-r--r--Documentation/devicetree/bindings/net/ethernet-controller.yaml187
-rw-r--r--Documentation/devicetree/bindings/net/ethernet-phy-package.yaml52
-rw-r--r--Documentation/devicetree/bindings/net/ethernet-phy.yaml110
-rw-r--r--Documentation/devicetree/bindings/net/ethernet-switch-port.yaml26
-rw-r--r--Documentation/devicetree/bindings/net/ethernet-switch.yaml85
-rw-r--r--Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml120
-rw-r--r--Documentation/devicetree/bindings/net/fsl,cpm-enet.yaml59
-rw-r--r--Documentation/devicetree/bindings/net/fsl,cpm-mdio.yaml55
-rw-r--r--Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml38
-rw-r--r--Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml60
-rw-r--r--Documentation/devicetree/bindings/net/fsl,enetc.yaml89
-rw-r--r--Documentation/devicetree/bindings/net/fsl,fec.yaml19
-rw-r--r--Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml56
-rw-r--r--Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml123
-rw-r--r--Documentation/devicetree/bindings/net/fsl,fman-muram.yaml40
-rw-r--r--Documentation/devicetree/bindings/net/fsl,fman-port.yaml75
-rw-r--r--Documentation/devicetree/bindings/net/fsl,fman.yaml210
-rw-r--r--Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml112
-rw-r--r--Documentation/devicetree/bindings/net/fsl,gianfar.yaml246
-rw-r--r--Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml18
-rw-r--r--Documentation/devicetree/bindings/net/fsl-enetc.txt119
-rw-r--r--Documentation/devicetree/bindings/net/fsl-fman.txt547
-rw-r--r--Documentation/devicetree/bindings/net/fsl-tsec-phy.txt82
-rw-r--r--Documentation/devicetree/bindings/net/ftgmac100.txt67
-rw-r--r--Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt10
-rw-r--r--Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt27
-rw-r--r--Documentation/devicetree/bindings/net/ieee802154/atmel,at86rf233.yaml66
-rw-r--r--Documentation/devicetree/bindings/net/ieee802154/ca8210.txt2
-rw-r--r--Documentation/devicetree/bindings/net/ingenic,mac.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml10
-rw-r--r--Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml14
-rw-r--r--Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml18
-rw-r--r--Documentation/devicetree/bindings/net/lantiq,pef2256.yaml213
-rw-r--r--Documentation/devicetree/bindings/net/litex,liteeth.yaml12
-rw-r--r--Documentation/devicetree/bindings/net/loongson,ls1b-gmac.yaml114
-rw-r--r--Documentation/devicetree/bindings/net/loongson,ls1c-emac.yaml113
-rw-r--r--Documentation/devicetree/bindings/net/lpc-eth.txt28
-rw-r--r--Documentation/devicetree/bindings/net/marvell,aquantia.yaml122
-rw-r--r--Documentation/devicetree/bindings/net/marvell,armada-370-neta.yaml79
-rw-r--r--Documentation/devicetree/bindings/net/marvell,armada-380-neta-bm.yaml60
-rw-r--r--Documentation/devicetree/bindings/net/marvell,dfx-server.yaml62
-rw-r--r--Documentation/devicetree/bindings/net/marvell,mvusb.yaml9
-rw-r--r--Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml8
-rw-r--r--Documentation/devicetree/bindings/net/marvell,pp2.yaml305
-rw-r--r--Documentation/devicetree/bindings/net/marvell,prestera.txt81
-rw-r--r--Documentation/devicetree/bindings/net/marvell,prestera.yaml91
-rw-r--r--Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt50
-rw-r--r--Documentation/devicetree/bindings/net/marvell-bluetooth.yaml31
-rw-r--r--Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt83
-rw-r--r--Documentation/devicetree/bindings/net/marvell-neta-bm.txt47
-rw-r--r--Documentation/devicetree/bindings/net/marvell-pp2.txt141
-rw-r--r--Documentation/devicetree/bindings/net/maxim,ds26522.txt13
-rw-r--r--Documentation/devicetree/bindings/net/maxim,ds26522.yaml40
-rw-r--r--Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml48
-rw-r--r--Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/mdio-gpio.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml32
-rw-r--r--Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt48
-rw-r--r--Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml1
-rw-r--r--Documentation/devicetree/bindings/net/mdio.yaml4
-rw-r--r--Documentation/devicetree/bindings/net/mediatek,net.yaml267
-rw-r--r--Documentation/devicetree/bindings/net/mediatek,star-emac.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/mediatek-bluetooth.txt116
-rw-r--r--Documentation/devicetree/bindings/net/mediatek-dwmac.yaml12
-rw-r--r--Documentation/devicetree/bindings/net/micrel,ks8851.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/micrel-ks8995.txt20
-rw-r--r--Documentation/devicetree/bindings/net/micrel-ksz90x1.txt5
-rw-r--r--Documentation/devicetree/bindings/net/micrel.txt2
-rw-r--r--Documentation/devicetree/bindings/net/microchip,lan8650.yaml74
-rw-r--r--Documentation/devicetree/bindings/net/microchip,lan95xx.yaml10
-rw-r--r--Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml65
-rw-r--r--Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml151
-rw-r--r--Documentation/devicetree/bindings/net/mscc,miim.yaml12
-rw-r--r--Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml130
-rw-r--r--Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt73
-rw-r--r--Documentation/devicetree/bindings/net/mscc-phy-vsc8531.yaml131
-rw-r--r--Documentation/devicetree/bindings/net/network-class.yaml46
-rw-r--r--Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml5
-rw-r--r--Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml3
-rw-r--r--Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml9
-rw-r--r--Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml23
-rw-r--r--Documentation/devicetree/bindings/net/nxp,lpc-eth.yaml48
-rw-r--r--Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt20
-rw-r--r--Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.yaml85
-rw-r--r--Documentation/devicetree/bindings/net/nxp,netc-blk-ctrl.yaml105
-rw-r--r--Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml105
-rw-r--r--Documentation/devicetree/bindings/net/nxp,tja11xx.yaml79
-rw-r--r--Documentation/devicetree/bindings/net/oxnas-dwmac.txt41
-rw-r--r--Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml40
-rw-r--r--Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml102
-rw-r--r--Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml177
-rw-r--r--Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml136
-rw-r--r--Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml192
-rw-r--r--Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml103
-rw-r--r--Documentation/devicetree/bindings/net/pse-pd/skyworks,si3474.yaml144
-rw-r--r--Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml127
-rw-r--r--Documentation/devicetree/bindings/net/qca,ar71xx.yaml1
-rw-r--r--Documentation/devicetree/bindings/net/qca,ar803x.yaml45
-rw-r--r--Documentation/devicetree/bindings/net/qca,qca7000.txt87
-rw-r--r--Documentation/devicetree/bindings/net/qca,qca7000.yaml109
-rw-r--r--Documentation/devicetree/bindings/net/qca,qca808x.yaml54
-rw-r--r--Documentation/devicetree/bindings/net/qcom,ethqos.txt66
-rw-r--r--Documentation/devicetree/bindings/net/qcom,ethqos.yaml144
-rw-r--r--Documentation/devicetree/bindings/net/qcom,ipa.yaml216
-rw-r--r--Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml65
-rw-r--r--Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml533
-rw-r--r--Documentation/devicetree/bindings/net/qcom,qca807x.yaml184
-rw-r--r--Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml183
-rw-r--r--Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml46
-rw-r--r--Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml86
-rw-r--r--Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml175
-rw-r--r--Documentation/devicetree/bindings/net/realtek-bluetooth.yaml58
-rw-r--r--Documentation/devicetree/bindings/net/renesas,ether.yaml7
-rw-r--r--Documentation/devicetree/bindings/net/renesas,etheravb.yaml48
-rw-r--r--Documentation/devicetree/bindings/net/renesas,ethertsn.yaml130
-rw-r--r--Documentation/devicetree/bindings/net/renesas,r8a779f0-ether-switch.yaml262
-rw-r--r--Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml75
-rw-r--r--Documentation/devicetree/bindings/net/renesas,rzv2h-gbeth.yaml303
-rw-r--r--Documentation/devicetree/bindings/net/rfkill-gpio.yaml56
-rw-r--r--Documentation/devicetree/bindings/net/rockchip,emac.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/rockchip-dwmac.yaml73
-rw-r--r--Documentation/devicetree/bindings/net/samsung-sxgbe.txt4
-rw-r--r--Documentation/devicetree/bindings/net/sff,sfp.yaml23
-rw-r--r--Documentation/devicetree/bindings/net/smsc,lan9115.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt2
-rw-r--r--Documentation/devicetree/bindings/net/snps,dwmac.yaml559
-rw-r--r--Documentation/devicetree/bindings/net/socfpga-dwmac.txt57
-rw-r--r--Documentation/devicetree/bindings/net/socionext,synquacer-netsec.yaml73
-rw-r--r--Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml8
-rw-r--r--Documentation/devicetree/bindings/net/socionext-netsec.txt56
-rw-r--r--Documentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml114
-rw-r--r--Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml151
-rw-r--r--Documentation/devicetree/bindings/net/spacemit,k1-emac.yaml81
-rw-r--r--Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml190
-rw-r--r--Documentation/devicetree/bindings/net/sti-dwmac.txt5
-rw-r--r--Documentation/devicetree/bindings/net/stm32-dwmac.yaml170
-rw-r--r--Documentation/devicetree/bindings/net/sunplus,sp7021-emac.yaml2
-rw-r--r--Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml118
-rw-r--r--Documentation/devicetree/bindings/net/thead,th1520-gmac.yaml112
-rw-r--r--Documentation/devicetree/bindings/net/ti,cc1352p7.yaml58
-rw-r--r--Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml19
-rw-r--r--Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml12
-rw-r--r--Documentation/devicetree/bindings/net/ti,dp83822.yaml71
-rw-r--r--Documentation/devicetree/bindings/net/ti,dp83867.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/ti,dp83869.yaml6
-rw-r--r--Documentation/devicetree/bindings/net/ti,icss-iep.yaml58
-rw-r--r--Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml233
-rw-r--r--Documentation/devicetree/bindings/net/ti,icssm-prueth.yaml233
-rw-r--r--Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml88
-rw-r--r--Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml52
-rw-r--r--Documentation/devicetree/bindings/net/ti,pruss-ecap.yaml32
-rw-r--r--Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml12
-rw-r--r--Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml10
-rw-r--r--Documentation/devicetree/bindings/net/via,vt8500-rhine.yaml41
-rw-r--r--Documentation/devicetree/bindings/net/via-rhine.txt17
-rw-r--r--Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml17
-rw-r--r--Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml22
-rw-r--r--Documentation/devicetree/bindings/net/wireless/ieee80211.yaml3
-rw-r--r--Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml92
-rw-r--r--Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt68
-rw-r--r--Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml120
-rw-r--r--Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml8
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml20
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt215
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml394
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml146
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml29
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml210
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml104
-rw-r--r--Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml315
-rw-r--r--Documentation/devicetree/bindings/net/wireless/ralink,rt2880.yaml49
-rw-r--r--Documentation/devicetree/bindings/net/wireless/realtek,rtl8188e.yaml50
-rw-r--r--Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml8
-rw-r--r--Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml81
-rw-r--r--Documentation/devicetree/bindings/net/wireless/wireless-controller.yaml23
-rw-r--r--Documentation/devicetree/bindings/net/xilinx_axienet.txt99
-rw-r--r--Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt35
-rw-r--r--Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml200
-rw-r--r--Documentation/devicetree/bindings/net/xlnx,emaclite.yaml5
-rw-r--r--Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml60
-rw-r--r--Documentation/devicetree/bindings/nios2/nios2.txt2
-rw-r--r--Documentation/devicetree/bindings/npu/arm,ethos.yaml79
-rw-r--r--Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml112
-rw-r--r--Documentation/devicetree/bindings/numa.txt319
-rw-r--r--Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml29
-rw-r--r--Documentation/devicetree/bindings/nvmem/airoha,an8855-efuse.yaml123
-rw-r--r--Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml10
-rw-r--r--Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml61
-rw-r--r--Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml58
-rw-r--r--Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt48
-rw-r--r--Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt22
-rw-r--r--Documentation/devicetree/bindings/nvmem/apple,efuses.yaml3
-rw-r--r--Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml54
-rw-r--r--Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml17
-rw-r--r--Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt17
-rw-r--r--Documentation/devicetree/bindings/nvmem/brcm,ocotp.yaml39
-rw-r--r--Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml3
-rw-r--r--Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml2
-rw-r--r--Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml37
-rw-r--r--Documentation/devicetree/bindings/nvmem/fsl,vf610-ocotp.yaml47
-rw-r--r--Documentation/devicetree/bindings/nvmem/imx-iim.yaml8
-rw-r--r--Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml36
-rw-r--r--Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml4
-rw-r--r--Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml55
-rw-r--r--Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml62
-rw-r--r--Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml69
-rw-r--r--Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml32
-rw-r--r--Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml147
-rw-r--r--Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml139
-rw-r--r--Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt28
-rw-r--r--Documentation/devicetree/bindings/nvmem/maxim,max77759-nvmem.yaml32
-rw-r--r--Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml25
-rw-r--r--Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml45
-rw-r--r--Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml3
-rw-r--r--Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml25
-rw-r--r--Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml4
-rw-r--r--Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml2
-rw-r--r--Documentation/devicetree/bindings/nvmem/nvmem-deprecated-cells.yaml28
-rw-r--r--Documentation/devicetree/bindings/nvmem/nvmem-provider.yaml18
-rw-r--r--Documentation/devicetree/bindings/nvmem/nvmem.yaml71
-rw-r--r--Documentation/devicetree/bindings/nvmem/nxp,lpc1857-eeprom.yaml61
-rw-r--r--Documentation/devicetree/bindings/nvmem/nxp,s32g-ocotp-nvmem.yaml45
-rw-r--r--Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml42
-rw-r--r--Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml56
-rw-r--r--Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml44
-rw-r--r--Documentation/devicetree/bindings/nvmem/renesas,rcar-efuse.yaml68
-rw-r--r--Documentation/devicetree/bindings/nvmem/renesas,rcar-otp.yaml43
-rw-r--r--Documentation/devicetree/bindings/nvmem/rmem.yaml4
-rw-r--r--Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml148
-rw-r--r--Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml5
-rw-r--r--Documentation/devicetree/bindings/nvmem/rockchip-otp.txt25
-rw-r--r--Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt52
-rw-r--r--Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml20
-rw-r--r--Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml109
-rw-r--r--Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml39
-rw-r--r--Documentation/devicetree/bindings/nvmem/sprd,ums312-efuse.yaml61
-rw-r--r--Documentation/devicetree/bindings/nvmem/sprd-efuse.txt39
-rw-r--r--Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml11
-rw-r--r--Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml9
-rw-r--r--Documentation/devicetree/bindings/nvmem/u-boot,env.yaml62
-rw-r--r--Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt19
-rw-r--r--Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt46
-rw-r--r--Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.yaml42
-rw-r--r--Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt40
-rw-r--r--Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.yaml54
-rw-r--r--Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml94
-rw-r--r--Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml110
-rw-r--r--Documentation/devicetree/bindings/opp/opp-v1.yaml20
-rw-r--r--Documentation/devicetree/bindings/opp/opp-v2-base.yaml12
-rw-r--r--Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml48
-rw-r--r--Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml96
-rw-r--r--Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml6
-rw-r--r--Documentation/devicetree/bindings/opp/opp-v2.yaml4
-rw-r--r--Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml101
-rw-r--r--Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt63
-rw-r--r--Documentation/devicetree/bindings/pci/83xx-512x-pci.txt39
-rw-r--r--Documentation/devicetree/bindings/pci/aardvark-pci.txt59
-rw-r--r--Documentation/devicetree/bindings/pci/altera-pcie-msi.txt27
-rw-r--r--Documentation/devicetree/bindings/pci/altera-pcie.txt50
-rw-r--r--Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml123
-rw-r--r--Documentation/devicetree/bindings/pci/amazon,al-alpine-v3-pcie.yaml71
-rw-r--r--Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml143
-rw-r--r--Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml135
-rw-r--r--Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt70
-rw-r--r--Documentation/devicetree/bindings/pci/apm,xgene-pcie.yaml84
-rw-r--r--Documentation/devicetree/bindings/pci/apple,pcie.yaml34
-rw-r--r--Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt50
-rw-r--r--Documentation/devicetree/bindings/pci/axis,artpec6-pcie.yaml118
-rw-r--r--Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml168
-rw-r--r--Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml166
-rw-r--r--Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml160
-rw-r--r--Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml18
-rw-r--r--Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml5
-rw-r--r--Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml8
-rw-r--r--Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml8
-rw-r--r--Documentation/devicetree/bindings/pci/cdns-pcie.yaml4
-rw-r--r--Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml83
-rw-r--r--Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml2
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml255
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml195
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml262
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml99
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml182
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml113
-rw-r--r--Documentation/devicetree/bindings/pci/fsl,pci.txt27
-rw-r--r--Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml3
-rw-r--r--Documentation/devicetree/bindings/pci/host-generic-pci.yaml10
-rw-r--r--Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml2
-rw-r--r--Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml30
-rw-r--r--Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml44
-rw-r--r--Documentation/devicetree/bindings/pci/layerscape-pci.txt79
-rw-r--r--Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt52
-rw-r--r--Documentation/devicetree/bindings/pci/loongson.yaml3
-rw-r--r--Documentation/devicetree/bindings/pci/marvell,armada-3700-pcie.yaml103
-rw-r--r--Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml100
-rw-r--r--Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml280
-rw-r--r--Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml173
-rw-r--r--Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml38
-rw-r--r--Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml197
-rw-r--r--Documentation/devicetree/bindings/pci/mediatek-pcie-mt7623.yaml164
-rw-r--r--Documentation/devicetree/bindings/pci/mediatek-pcie.txt289
-rw-r--r--Documentation/devicetree/bindings/pci/mediatek-pcie.yaml438
-rw-r--r--Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml134
-rw-r--r--Documentation/devicetree/bindings/pci/mobiveil-pcie.txt72
-rw-r--r--Documentation/devicetree/bindings/pci/mvebu-pci.txt310
-rw-r--r--Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml2
-rw-r--r--Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml34
-rw-r--r--Documentation/devicetree/bindings/pci/nxp,s32g-pcie.yaml130
-rw-r--r--Documentation/devicetree/bindings/pci/pci-armada8k.txt48
-rw-r--r--Documentation/devicetree/bindings/pci/pci-ep-bus.yaml58
-rw-r--r--Documentation/devicetree/bindings/pci/pci-ep.yaml86
-rw-r--r--Documentation/devicetree/bindings/pci/pci-iommu.txt171
-rw-r--r--Documentation/devicetree/bindings/pci/pci-msi.txt220
-rw-r--r--Documentation/devicetree/bindings/pci/pci.txt84
-rw-r--r--Documentation/devicetree/bindings/pci/pcie-al.txt46
-rw-r--r--Documentation/devicetree/bindings/pci/plda,xpressrich3-axi-common.yaml81
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml135
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml228
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sa8255p.yaml122
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml183
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml195
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml168
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml180
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml165
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml181
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml170
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml185
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml183
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml173
-rw-r--r--Documentation/devicetree/bindings/pci/qcom,pcie.yaml375
-rw-r--r--Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml118
-rw-r--r--Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml130
-rw-r--r--Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml34
-rw-r--r--Documentation/devicetree/bindings/pci/rcar-pci-host.yaml58
-rw-r--r--Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml12
-rw-r--r--Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml249
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml69
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml70
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml133
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml132
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip-dw-pcie-ep.yaml95
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml151
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt62
-rw-r--r--Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt135
-rw-r--r--Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml2
-rw-r--r--Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml10
-rw-r--r--Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml267
-rw-r--r--Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml221
-rw-r--r--Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml281
-rw-r--r--Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml76
-rw-r--r--Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml4
-rw-r--r--Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml64
-rw-r--r--Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml122
-rw-r--r--Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml157
-rw-r--r--Documentation/devicetree/bindings/pci/spear13xx-pcie.txt14
-rw-r--r--Documentation/devicetree/bindings/pci/st,spear1340-pcie.yaml45
-rw-r--r--Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml33
-rw-r--r--Documentation/devicetree/bindings/pci/st,stm32-pcie-ep.yaml73
-rw-r--r--Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml112
-rw-r--r--Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml126
-rw-r--r--Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml50
-rw-r--r--Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml84
-rw-r--r--Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml93
-rw-r--r--Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml179
-rw-r--r--Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml11
-rw-r--r--Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml100
-rw-r--r--Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt76
-rw-r--r--Documentation/devicetree/bindings/pci/versatile.yaml3
-rw-r--r--Documentation/devicetree/bindings/pci/xgene-pci-msi.txt68
-rw-r--r--Documentation/devicetree/bindings/pci/xgene-pci.txt50
-rw-r--r--Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt73
-rw-r--r--Documentation/devicetree/bindings/pci/xilinx-pcie.txt88
-rw-r--r--Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml129
-rw-r--r--Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml88
-rw-r--r--Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml156
-rw-r--r--Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml146
-rw-r--r--Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml56
-rw-r--r--Documentation/devicetree/bindings/peci/peci-aspeed.yaml2
-rw-r--r--Documentation/devicetree/bindings/peci/peci-controller.yaml2
-rw-r--r--Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml54
-rw-r--r--Documentation/devicetree/bindings/perf/apm,xgene-pmu.yaml142
-rw-r--r--Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt112
-rw-r--r--Documentation/devicetree/bindings/perf/arm,cmn.yaml1
-rw-r--r--Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml39
-rw-r--r--Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml3
-rw-r--r--Documentation/devicetree/bindings/perf/arm,ni.yaml30
-rw-r--r--Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml39
-rw-r--r--Documentation/devicetree/bindings/perf/riscv,pmu.yaml160
-rw-r--r--Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml46
-rw-r--r--Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml69
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun4i-a10-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml14
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun5i-a13-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml15
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun8i-a23-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun8i-a83t-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml28
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun8i-r40-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun8i-v3s-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,sun9i-a80-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml83
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml16
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml81
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml64
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml21
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml78
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml59
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml56
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/apm,xgene-phy.yaml169
-rw-r--r--Documentation/devicetree/bindings/phy/apm-xgene-phy.txt76
-rw-r--r--Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml19
-rw-r--r--Documentation/devicetree/bindings/phy/berlin-sata-phy.txt36
-rw-r--r--Documentation/devicetree/bindings/phy/berlin-usb-phy.txt16
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml9
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml1
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt15
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml36
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt30
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.yaml62
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml12
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt41
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.yaml46
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,sr-usb-combo-phy.yaml65
-rw-r--r--Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt32
-rw-r--r--Documentation/devicetree/bindings/phy/calxeda-combophy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/cdns,dphy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml10
-rw-r--r--Documentation/devicetree/bindings/phy/dm816x-phy.txt24
-rw-r--r--Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml18
-rw-r--r--Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml62
-rw-r--r--Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml126
-rw-r--r--Documentation/devicetree/bindings/phy/fsl,imx8qm-hsio.yaml164
-rw-r--r--Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml146
-rw-r--r--Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml29
-rw-r--r--Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml35
-rw-r--r--Documentation/devicetree/bindings/phy/hisilicon,hi3798cv200-combphy.yaml56
-rw-r--r--Documentation/devicetree/bindings/phy/hisilicon,hi6220-usb-phy.yaml35
-rw-r--r--Documentation/devicetree/bindings/phy/hisilicon,hix5hd2-sata-phy.yaml48
-rw-r--r--Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml93
-rw-r--r--Documentation/devicetree/bindings/phy/hix5hd2-phy.txt22
-rw-r--r--Documentation/devicetree/bindings/phy/img,pistachio-usb-phy.yaml62
-rw-r--r--Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/intel,combo-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml46
-rw-r--r--Documentation/devicetree/bindings/phy/keystone-usb-phy.txt19
-rw-r--r--Documentation/devicetree/bindings/phy/lantiq,ase-usb2-phy.yaml71
-rw-r--r--Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,armada-375-usb-cluster.yaml40
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,armada-380-comphy.yaml83
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml12
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,berlin2-sata-phy.yaml76
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,berlin2-usb-phy.yaml42
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,comphy-cp110.yaml167
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,mmp2-usb-phy.yaml37
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,mmp3-usb-phy.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,mvebu-sata-phy.yaml47
-rw-r--r--Documentation/devicetree/bindings/phy/marvell,pxa1928-usb-phy.yaml47
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml11
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml3
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml8
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,mt7628-usbphy.yaml74
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,mt7988-xfi-tphy.yaml80
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml79
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,tphy.yaml37
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml5
-rw-r--r--Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml18
-rw-r--r--Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt21
-rw-r--r--Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml17
-rw-r--r--Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml14
-rw-r--r--Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml107
-rw-r--r--Documentation/devicetree/bindings/phy/motorola,mapphone-mdm6600.yaml81
-rw-r--r--Documentation/devicetree/bindings/phy/mscc,vsc7514-serdes.yaml56
-rw-r--r--Documentation/devicetree/bindings/phy/mxs-usb-phy.txt33
-rw-r--r--Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml45
-rw-r--r--Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt779
-rw-r--r--Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml654
-rw-r--r--Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml544
-rw-r--r--Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml632
-rw-r--r--Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml786
-rw-r--r--Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml55
-rw-r--r--Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt48
-rw-r--r--Documentation/devicetree/bindings/phy/phy-ath79-usb.txt18
-rw-r--r--Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml16
-rw-r--r--Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml26
-rw-r--r--Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt40
-rw-r--r--Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt40
-rw-r--r--Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt59
-rw-r--r--Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt16
-rw-r--r--Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt71
-rw-r--r--Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt40
-rw-r--r--Documentation/devicetree/bindings/phy/phy-lpc18xx-usb-otg.txt26
-rw-r--r--Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt29
-rw-r--r--Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt94
-rw-r--r--Documentation/devicetree/bindings/phy/phy-mvebu.txt42
-rw-r--r--Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt43
-rw-r--r--Documentation/devicetree/bindings/phy/phy-pxa-usb.txt18
-rw-r--r--Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt43
-rw-r--r--Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml187
-rw-r--r--Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml48
-rw-r--r--Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt84
-rw-r--r--Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml152
-rw-r--r--Documentation/devicetree/bindings/phy/phy-stih407-usb.txt24
-rw-r--r--Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml10
-rw-r--r--Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml6
-rw-r--r--Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt29
-rw-r--r--Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt18
-rw-r--r--Documentation/devicetree/bindings/phy/qca,ar7100-usb-phy.yaml49
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml22
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml27
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml1
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml109
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml61
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml102
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,m31-eusb2-phy.yaml79
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml189
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml97
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml186
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml86
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml502
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml213
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml170
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml60
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,sata-phy.yaml55
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml314
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml187
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml197
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml270
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml88
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml84
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt76
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml5
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml9
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt65
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml67
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml125
-rw-r--r--Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt24
-rw-r--r--Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt23
-rw-r--r--Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt42
-rw-r--r--Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml4
-rw-r--r--Documentation/devicetree/bindings/phy/ralink-usb-phy.txt23
-rw-r--r--Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt112
-rw-r--r--Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml175
-rw-r--r--Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml107
-rw-r--r--Documentation/devicetree/bindings/phy/renesas,r8a779f0-ether-serdes.yaml54
-rw-r--r--Documentation/devicetree/bindings/phy/renesas,rcar-gen2-usb-phy.yaml123
-rw-r--r--Documentation/devicetree/bindings/phy/renesas,rzg3e-usb3-phy.yaml63
-rw-r--r--Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml34
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml248
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml116
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml3
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3228-hdmi-phy.yaml97
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml41
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3399-emmc-phy.yaml64
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3399-pcie-phy.yaml45
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3399-typec-phy.yaml116
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml120
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml87
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt26
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt43
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml70
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt36
-rw-r--r--Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml5
-rw-r--r--Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml6
-rw-r--r--Documentation/devicetree/bindings/phy/samsung,exynos2200-eusb2-phy.yaml80
-rw-r--r--Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml38
-rw-r--r--Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml53
-rw-r--r--Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml143
-rw-r--r--Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml32
-rw-r--r--Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml8
-rw-r--r--Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml41
-rw-r--r--Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml36
-rw-r--r--Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml33
-rw-r--r--Documentation/devicetree/bindings/phy/sophgo,cv1800b-usb2-phy.yaml54
-rw-r--r--Documentation/devicetree/bindings/phy/st,spear1310-miphy.yaml53
-rw-r--r--Documentation/devicetree/bindings/phy/st,stih407-usb2-phy.yaml63
-rw-r--r--Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml119
-rw-r--r--Documentation/devicetree/bindings/phy/st-spear-miphy.txt15
-rw-r--r--Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml71
-rw-r--r--Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-tx.yaml68
-rw-r--r--Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml58
-rw-r--r--Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml50
-rw-r--r--Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml73
-rw-r--r--Documentation/devicetree/bindings/phy/ti,da830-usb-phy.yaml53
-rw-r--r--Documentation/devicetree/bindings/phy/ti,dm8168-usb-phy.yaml58
-rw-r--r--Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml37
-rw-r--r--Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml7
-rw-r--r--Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml73
-rw-r--r--Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml56
-rw-r--r--Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml86
-rw-r--r--Documentation/devicetree/bindings/phy/ti-phy.txt2
-rw-r--r--Documentation/devicetree/bindings/phy/transmit-amplitude.yaml2
-rw-r--r--Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.txt170
-rw-r--r--Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.yaml204
-rw-r--r--Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt204
-rw-r--r--Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.yaml219
-rw-r--r--Documentation/devicetree/bindings/pinctrl/airoha,an7583-pinctrl.yaml402
-rw-r--r--Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml403
-rw-r--r--Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml19
-rw-r--r--Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml175
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml73
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml64
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml71
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml75
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml80
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml82
-rw-r--r--Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml139
-rw-r--r--Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml23
-rw-r--r--Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml197
-rw-r--r--Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml216
-rw-r--r--Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml548
-rw-r--r--Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt176
-rw-r--r--Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt4
-rw-r--r--Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml184
-rw-r--r--Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml139
-rw-r--r--Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt47
-rw-r--r--Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt126
-rw-r--r--Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.yaml132
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt461
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml259
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml151
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm2712c0-pinctrl.yaml137
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt99
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.yaml120
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml1
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml7
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml27
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml7
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml7
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml9
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml9
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt123
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.yaml111
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt102
-rw-r--r--Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.yaml111
-rw-r--r--Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml8
-rw-r--r--Documentation/devicetree/bindings/pinctrl/canaan,k230-pinctrl.yaml127
-rw-r--r--Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml7
-rw-r--r--Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml91
-rw-r--r--Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml158
-rw-r--r--Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml156
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt33
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml184
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx50-pinctrl.txt32
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt32
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt32
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt38
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt38
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt39
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt40
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt36
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt37
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-iomuxc1.yaml99
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt53
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml90
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml84
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml84
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml84
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml84
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx9-pinctrl.yaml86
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml85
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt127
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,vf610-iomuxc.yaml83
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt41
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml10
-rw-r--r--Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml4
-rw-r--r--Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml3
-rw-r--r--Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml119
-rw-r--r--Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt35
-rw-r--r--Documentation/devicetree/bindings/pinctrl/loongson,ls2k-pinctrl.yaml123
-rw-r--r--Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml5
-rw-r--r--Documentation/devicetree/bindings/pinctrl/marvell,ap806-pinctrl.yaml61
-rw-r--r--Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt195
-rw-r--r--Documentation/devicetree/bindings/pinctrl/marvell,armada-7k-pinctrl.yaml72
-rw-r--r--Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml124
-rw-r--r--Documentation/devicetree/bindings/pinctrl/marvell,berlin2-soc-pinctrl.yaml86
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml138
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml137
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml228
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml176
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt6878-pinctrl.yaml211
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt6893-pinctrl.yaml193
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml298
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml261
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml213
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt76x8-pinctrl.yaml450
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml480
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml216
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml580
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml118
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8186-pinctrl.yaml275
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml232
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8189-pinctrl.yaml213
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8192-pinctrl.yaml184
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8195-pinctrl.yaml286
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8196-pinctrl.yaml236
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml230
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml224
-rw-r--r--Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt94
-rw-r--r--Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml161
-rw-r--r--Documentation/devicetree/bindings/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml89
-rw-r--r--Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml74
-rw-r--r--Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml12
-rw-r--r--Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml33
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml178
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml215
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml4
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml178
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt131
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml153
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt153
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml174
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra186-pinmux.yaml285
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt107
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml282
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt143
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml110
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt166
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml140
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml81
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml52
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml142
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt144
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml174
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt71
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.yaml79
-rw-r--r--Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml123
-rw-r--r--Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt56
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml24
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt148
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml276
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml183
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml287
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt2
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt262
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml220
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt72
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml4
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt95
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.yaml110
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt188
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml129
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml133
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt85
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.yaml103
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml123
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml118
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml114
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml119
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt101
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.yaml108
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt181
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml121
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml114
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,kaanapali-tlmm.yaml127
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml75
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml134
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml119
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.txt161
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml106
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml133
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml112
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt96
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml110
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml104
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt195
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml152
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml160
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml104
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt190
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml150
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt121
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml165
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.txt183
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml122
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt186
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml148
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt208
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml168
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt202
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml157
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml116
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml127
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml167
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml122
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.txt199
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml161
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qcs615-tlmm.yaml124
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qcs8300-tlmm.yaml118
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml119
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml131
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sar2130p-tlmm.yaml138
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt187
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml144
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml110
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml110
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml153
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml138
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml114
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml151
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml137
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml173
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdm660-lpass-lpi-pinctrl.yaml109
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt191
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml112
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt176
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml155
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml103
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml191
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml153
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml131
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm4250-lpass-lpi-pinctrl.yaml118
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml135
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml100
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml181
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml138
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml133
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml136
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml149
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml148
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml108
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml146
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.txt190
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml159
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml99
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml191
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml102
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml146
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml135
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml123
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml143
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml134
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml113
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml148
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml111
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8650-tlmm.yaml141
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,sm8750-tlmm.yaml138
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml31
-rw-r--r--Documentation/devicetree/bindings/pinctrl/qcom,x1e80100-tlmm.yaml137
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml97
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml71
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml93
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml183
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml243
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml212
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml206
-rw-r--r--Documentation/devicetree/bindings/pinctrl/raspberrypi,rp1-gpio.yaml231
-rw-r--r--Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml188
-rw-r--r--Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml187
-rw-r--r--Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml186
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml10
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml172
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml12
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml61
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml70
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml86
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml12
-rw-r--r--Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml11
-rw-r--r--Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml23
-rw-r--r--Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml1
-rw-r--r--Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml71
-rw-r--r--Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml108
-rw-r--r--Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml251
-rw-r--r--Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml21
-rw-r--r--Documentation/devicetree/bindings/pinctrl/sophgo,cv1800-pinctrl.yaml122
-rw-r--r--Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml129
-rw-r--r--Documentation/devicetree/bindings/pinctrl/spacemit,k1-pinctrl.yaml142
-rw-r--r--Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt83
-rw-r--r--Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.txt70
-rw-r--r--Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.yaml199
-rw-r--r--Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml187
-rw-r--r--Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml167
-rw-r--r--Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml13
-rw-r--r--Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml124
-rw-r--r--Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml142
-rw-r--r--Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml8
-rw-r--r--Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml176
-rw-r--r--Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt13
-rw-r--r--Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml32
-rw-r--r--Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml210
-rw-r--r--Documentation/devicetree/bindings/pinctrl/xlnx,versal-pinctrl.yaml279
-rw-r--r--Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml217
-rw-r--r--Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml354
-rw-r--r--Documentation/devicetree/bindings/pmem/pmem-region.txt65
-rw-r--r--Documentation/devicetree/bindings/pmem/pmem-region.yaml48
-rw-r--r--Documentation/devicetree/bindings/power/actions,owl-sps.txt21
-rw-r--r--Documentation/devicetree/bindings/power/actions,s500-sps.yaml39
-rw-r--r--Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml57
-rw-r--r--Documentation/devicetree/bindings/power/allwinner,sun50i-h6-prcm-ppu.yaml42
-rw-r--r--Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt4
-rw-r--r--Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml9
-rw-r--r--Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml21
-rw-r--r--Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/domain-idle-state.yaml17
-rw-r--r--Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml34
-rw-r--r--Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml19
-rw-r--r--Documentation/devicetree/bindings/power/fsl,scu-pd.yaml3
-rw-r--r--Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml117
-rw-r--r--Documentation/devicetree/bindings/power/mediatek,power-controller.yaml56
-rw-r--r--Documentation/devicetree/bindings/power/power-domain.yaml22
-rw-r--r--Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml44
-rw-r--r--Documentation/devicetree/bindings/power/qcom,rpmpd.yaml86
-rw-r--r--Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml42
-rw-r--r--Documentation/devicetree/bindings/power/renesas,apmu.yaml6
-rw-r--r--Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml6
-rw-r--r--Documentation/devicetree/bindings/power/reset/apple,smc-reboot.yaml40
-rw-r--r--Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml82
-rw-r--r--Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml122
-rw-r--r--Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt14
-rw-r--r--Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml31
-rw-r--r--Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml8
-rw-r--r--Documentation/devicetree/bindings/power/reset/gpio-restart.yaml15
-rw-r--r--Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt20
-rw-r--r--Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt26
-rw-r--r--Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml54
-rw-r--r--Documentation/devicetree/bindings/power/reset/qcom,pon.yaml144
-rw-r--r--Documentation/devicetree/bindings/power/reset/reboot-mode.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/reset/restart-handler.yaml30
-rw-r--r--Documentation/devicetree/bindings/power/reset/syscon-poweroff.yaml10
-rw-r--r--Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml10
-rw-r--r--Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml45
-rw-r--r--Documentation/devicetree/bindings/power/reset/toradex,smarc-ec.yaml52
-rw-r--r--Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml9
-rw-r--r--Documentation/devicetree/bindings/power/rockchip,power-controller.yaml8
-rw-r--r--Documentation/devicetree/bindings/power/rockchip-io-domain.yaml24
-rw-r--r--Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml45
-rw-r--r--Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml76
-rw-r--r--Documentation/devicetree/bindings/power/supply/adc-battery.yaml70
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq2415x.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq24190.yaml14
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq24257.yaml6
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq24735.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq2515x.yaml9
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq256xx.yaml25
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq25890.yaml20
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq25980.yaml42
-rw-r--r--Documentation/devicetree/bindings/power/supply/bq27xxx.yaml54
-rw-r--r--Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml5
-rw-r--r--Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/gpio-charger.yaml6
-rw-r--r--Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml20
-rw-r--r--Documentation/devicetree/bindings/power/supply/isp1704.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml26
-rw-r--r--Documentation/devicetree/bindings/power/supply/max8925_battery.txt18
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml35
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml5
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max17201.yaml58
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml50
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml68
-rw-r--r--Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml96
-rw-r--r--Documentation/devicetree/bindings/power/supply/mitsumi,mm8013.yaml38
-rw-r--r--Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml3
-rw-r--r--Documentation/devicetree/bindings/power/supply/pegatron,chagall-ec.yaml49
-rw-r--r--Documentation/devicetree/bindings/power/supply/power-supply.yaml6
-rw-r--r--Documentation/devicetree/bindings/power/supply/qcom,pm8916-bms-vm.yaml83
-rw-r--r--Documentation/devicetree/bindings/power/supply/qcom,pm8916-lbc.yaml128
-rw-r--r--Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml20
-rw-r--r--Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml82
-rw-r--r--Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml2
-rw-r--r--Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml67
-rw-r--r--Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml12
-rw-r--r--Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml82
-rw-r--r--Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml73
-rw-r--r--Documentation/devicetree/bindings/power/supply/richtek,rt9756.yaml72
-rw-r--r--Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml3
-rw-r--r--Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml8
-rw-r--r--Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml24
-rw-r--r--Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml47
-rw-r--r--Documentation/devicetree/bindings/power/supply/st,stc3117.yaml74
-rw-r--r--Documentation/devicetree/bindings/power/supply/stericsson,ab8500-battery.txt34
-rw-r--r--Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml5
-rw-r--r--Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml4
-rw-r--r--Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml5
-rw-r--r--Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml5
-rw-r--r--Documentation/devicetree/bindings/power/supply/ti,twl6030-charger.yaml48
-rw-r--r--Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml23
-rw-r--r--Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml73
-rw-r--r--Documentation/devicetree/bindings/power/wakeup-source.txt33
-rw-r--r--Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt34
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/cpus.txt2
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt4
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/dma.txt204
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt17
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/mpic.txt231
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt111
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/pmc.txt63
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/pmc.yaml152
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/raideng.txt2
-rw-r--r--Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt2
-rw-r--r--Documentation/devicetree/bindings/powerpc/nintendo/wii.txt16
-rw-r--r--Documentation/devicetree/bindings/pps/pps-gpio.txt30
-rw-r--r--Documentation/devicetree/bindings/pps/pps-gpio.yaml49
-rw-r--r--Documentation/devicetree/bindings/ptp/fsl,ptp.yaml156
-rw-r--r--Documentation/devicetree/bindings/ptp/nxp,ptp-netc.yaml63
-rw-r--r--Documentation/devicetree/bindings/ptp/ptp-idt82p33.yaml2
-rw-r--r--Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml2
-rw-r--r--Documentation/devicetree/bindings/ptp/ptp-qoriq.txt87
-rw-r--r--Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml57
-rw-r--r--Documentation/devicetree/bindings/pwm/airoha,en7581-pwm.yaml34
-rw-r--r--Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml16
-rw-r--r--Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml52
-rw-r--r--Documentation/devicetree/bindings/pwm/argon40,fan-hat.yaml48
-rw-r--r--Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml9
-rw-r--r--Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml35
-rw-r--r--Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt29
-rw-r--r--Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml8
-rw-r--r--Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt21
-rw-r--r--Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml51
-rw-r--r--Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml53
-rw-r--r--Documentation/devicetree/bindings/pwm/fsl,vf610-ftm-pwm.yaml97
-rw-r--r--Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml4
-rw-r--r--Documentation/devicetree/bindings/pwm/imx-pwm.yaml15
-rw-r--r--Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml15
-rw-r--r--Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml2
-rw-r--r--Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml2
-rw-r--r--Documentation/devicetree/bindings/pwm/loongson,ls7a-pwm.yaml67
-rw-r--r--Documentation/devicetree/bindings/pwm/lpc1850-sct-pwm.txt20
-rw-r--r--Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt17
-rw-r--r--Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml44
-rw-r--r--Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml71
-rw-r--r--Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml100
-rw-r--r--Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml14
-rw-r--r--Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml6
-rw-r--r--Documentation/devicetree/bindings/pwm/mxs-pwm.yaml16
-rw-r--r--Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt77
-rw-r--r--Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml95
-rw-r--r--Documentation/devicetree/bindings/pwm/nxp,lpc1850-sct-pwm.yaml54
-rw-r--r--Documentation/devicetree/bindings/pwm/nxp,lpc3220-pwm.yaml44
-rw-r--r--Documentation/devicetree/bindings/pwm/nxp,mc33xs2410.yaml118
-rw-r--r--Documentation/devicetree/bindings/pwm/opencores,pwm.yaml56
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml181
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt30
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml42
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-berlin.txt17
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt55
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-gpio.yaml46
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-mediatek.txt52
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-meson.txt29
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml65
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt22
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml5
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-samsung.yaml22
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-sifive.yaml1
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm-sprd.txt40
-rw-r--r--Documentation/devicetree/bindings/pwm/pwm.yaml8
-rw-r--r--Documentation/devicetree/bindings/pwm/pxa-pwm.txt30
-rw-r--r--Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml3
-rw-r--r--Documentation/devicetree/bindings/pwm/renesas,rzg2l-gpt.yaml378
-rw-r--r--Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml11
-rw-r--r--Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml67
-rw-r--r--Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml60
-rw-r--r--Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml66
-rw-r--r--Documentation/devicetree/bindings/pwm/thead,th1520-pwm.yaml48
-rw-r--r--Documentation/devicetree/bindings/pwm/ti,omap-dmtimer-pwm.yaml59
-rw-r--r--Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt17
-rw-r--r--Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt17
-rw-r--r--Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml43
-rw-r--r--Documentation/devicetree/bindings/pwm/vt8500-pwm.txt18
-rw-r--r--Documentation/devicetree/bindings/regulator/act8865-regulator.txt117
-rw-r--r--Documentation/devicetree/bindings/regulator/act8945a-regulator.txt113
-rw-r--r--Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml139
-rw-r--r--Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml167
-rw-r--r--Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml158
-rw-r--r--Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml271
-rw-r--r--Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml157
-rw-r--r--Documentation/devicetree/bindings/regulator/adi,max77503-regulator.yaml50
-rw-r--r--Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml38
-rw-r--r--Documentation/devicetree/bindings/regulator/adi,max77857.yaml86
-rw-r--r--Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml37
-rw-r--r--Documentation/devicetree/bindings/regulator/anatop-regulator.yaml22
-rw-r--r--Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml78
-rw-r--r--Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml56
-rw-r--r--Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml51
-rw-r--r--Documentation/devicetree/bindings/regulator/da9210.txt29
-rw-r--r--Documentation/devicetree/bindings/regulator/da9211.txt205
-rw-r--r--Documentation/devicetree/bindings/regulator/dlg,da9121.yaml24
-rw-r--r--Documentation/devicetree/bindings/regulator/dlg,da9210.yaml52
-rw-r--r--Documentation/devicetree/bindings/regulator/dlg,da9211.yaml103
-rw-r--r--Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml132
-rw-r--r--Documentation/devicetree/bindings/regulator/fan53555.txt24
-rw-r--r--Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml73
-rw-r--r--Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml110
-rw-r--r--Documentation/devicetree/bindings/regulator/fixed-regulator.yaml23
-rw-r--r--Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml5
-rw-r--r--Documentation/devicetree/bindings/regulator/gpio-regulator.yaml6
-rw-r--r--Documentation/devicetree/bindings/regulator/infineon,ir38060.yaml45
-rw-r--r--Documentation/devicetree/bindings/regulator/lltc,ltc3676.yaml167
-rw-r--r--Documentation/devicetree/bindings/regulator/ltc3676.txt94
-rw-r--r--Documentation/devicetree/bindings/regulator/max77650-regulator.yaml3
-rw-r--r--Documentation/devicetree/bindings/regulator/max8660.yaml10
-rw-r--r--Documentation/devicetree/bindings/regulator/max8893.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/maxim,max20086.yaml1
-rw-r--r--Documentation/devicetree/bindings/regulator/maxim,max20411.yaml58
-rw-r--r--Documentation/devicetree/bindings/regulator/maxim,max77802.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/maxim,max77826.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/maxim,max77838.yaml68
-rw-r--r--Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt144
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6316b-regulator.yaml76
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6316c-regulator.yaml76
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6316d-regulator.yaml75
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml31
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml11
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml284
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml250
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6363-regulator.yaml146
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6397-regulator.yaml238
-rw-r--r--Documentation/devicetree/bindings/regulator/mediatek,mt6873-dvfsrc-regulator.yaml45
-rw-r--r--Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml200
-rw-r--r--Documentation/devicetree/bindings/regulator/mps,mp5416.yaml10
-rw-r--r--Documentation/devicetree/bindings/regulator/mps,mp886x.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/mps,mpq2286.yaml59
-rw-r--r--Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml13
-rw-r--r--Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml68
-rw-r--r--Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml14
-rw-r--r--Documentation/devicetree/bindings/regulator/mt6358-regulator.txt370
-rw-r--r--Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml16
-rw-r--r--Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml16
-rw-r--r--Documentation/devicetree/bindings/regulator/mt6397-regulator.txt220
-rw-r--r--Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml119
-rw-r--r--Documentation/devicetree/bindings/regulator/nxp,pf0900.yaml163
-rw-r--r--Documentation/devicetree/bindings/regulator/nxp,pf5300.yaml54
-rw-r--r--Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml23
-rw-r--r--Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/pfuze100.yaml15
-rw-r--r--Documentation/devicetree/bindings/regulator/pwm-regulator.yaml3
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml244
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml128
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml213
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml60
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml10
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml87
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml27
-rw-r--r--Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml13
-rw-r--r--Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator-v2.yaml61
-rw-r--r--Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/regulator-max77620.txt2
-rw-r--r--Documentation/devicetree/bindings/regulator/regulator-output.yaml39
-rw-r--r--Documentation/devicetree/bindings/regulator/regulator.yaml48
-rw-r--r--Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml85
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml68
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml1
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt5133.yaml178
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml73
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt6190.yaml79
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml9
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml3
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml207
-rw-r--r--Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml1
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml10
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml30
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml14
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml14
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml6
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml63
-rw-r--r--Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml44
-rw-r--r--Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml21
-rw-r--r--Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml47
-rw-r--r--Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/slg51000.txt88
-rw-r--r--Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml23
-rw-r--r--Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt43
-rw-r--r--Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml46
-rw-r--r--Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml6
-rw-r--r--Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml8
-rw-r--r--Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml11
-rw-r--r--Documentation/devicetree/bindings/regulator/ti,tps62360.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/ti,tps62864.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/ti,tps62870.yaml52
-rw-r--r--Documentation/devicetree/bindings/regulator/ti,tps65132.yaml87
-rw-r--r--Documentation/devicetree/bindings/regulator/ti,tps65219.yaml41
-rw-r--r--Documentation/devicetree/bindings/regulator/tps65132-regulator.txt46
-rw-r--r--Documentation/devicetree/bindings/regulator/twl-regulator.txt80
-rw-r--r--Documentation/devicetree/bindings/regulator/vctrl-regulator.yaml80
-rw-r--r--Documentation/devicetree/bindings/regulator/vctrl.txt49
-rw-r--r--Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml2
-rw-r--r--Documentation/devicetree/bindings/regulator/wlf,arizona.yaml8
-rw-r--r--Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml8
-rw-r--r--Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml65
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml6
-rw-r--r--Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml182
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml456
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml39
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml98
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml198
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml345
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml392
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml88
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml4
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt172
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml6
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml95
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml171
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml176
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml4
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml186
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml195
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml4
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml9
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml152
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml6
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml110
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml157
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml168
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sm6375-pas.yaml145
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml196
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml192
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml289
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml39
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt177
-rw-r--r--Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml321
-rw-r--r--Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml8
-rw-r--r--Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml68
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt3
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml92
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml125
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml80
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml2
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml60
-rw-r--r--Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml25
-rw-r--r--Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml371
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml4
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/memory-region.yaml40
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml4
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml48
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/phram.yaml4
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml6
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml23
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/ramoops.yaml6
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt2
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml100
-rw-r--r--Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml97
-rw-r--r--Documentation/devicetree/bindings/reset/allwinner,sun6i-a31-clock-reset.yaml2
-rw-r--r--Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml12
-rw-r--r--Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml24
-rw-r--r--Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml7
-rw-r--r--Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml8
-rw-r--r--Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/canaan,k230-rst.yaml39
-rw-r--r--Documentation/devicetree/bindings/reset/eswin,eic7700-reset.yaml42
-rw-r--r--Documentation/devicetree/bindings/reset/fsl,imx-src.yaml31
-rw-r--r--Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml25
-rw-r--r--Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/microchip,rst.yaml17
-rw-r--r--Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml46
-rw-r--r--Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml18
-rw-r--r--Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.txt83
-rw-r--r--Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.yaml101
-rw-r--r--Documentation/devicetree/bindings/reset/oxnas,reset.txt32
-rw-r--r--Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml10
-rw-r--r--Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml8
-rw-r--r--Documentation/devicetree/bindings/reset/renesas,rst.yaml6
-rw-r--r--Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml51
-rw-r--r--Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml61
-rw-r--r--Documentation/devicetree/bindings/reset/snps,dw-reset.txt30
-rw-r--r--Documentation/devicetree/bindings/reset/snps,dw-reset.yaml39
-rw-r--r--Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml31
-rw-r--r--Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml52
-rw-r--r--Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml42
-rw-r--r--Documentation/devicetree/bindings/reset/st,stm32-rcc.txt2
-rw-r--r--Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml2
-rw-r--r--Documentation/devicetree/bindings/reset/sunplus,reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml50
-rw-r--r--Documentation/devicetree/bindings/reset/ti,sci-reset.yaml7
-rw-r--r--Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml4
-rw-r--r--Documentation/devicetree/bindings/reset/ti-syscon-reset.txt2
-rw-r--r--Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt55
-rw-r--r--Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml53
-rw-r--r--Documentation/devicetree/bindings/riscv/andes.yaml25
-rw-r--r--Documentation/devicetree/bindings/riscv/anlogic.yaml27
-rw-r--r--Documentation/devicetree/bindings/riscv/canaan.yaml2
-rw-r--r--Documentation/devicetree/bindings/riscv/cpus.yaml130
-rw-r--r--Documentation/devicetree/bindings/riscv/eswin.yaml29
-rw-r--r--Documentation/devicetree/bindings/riscv/extensions.yaml904
-rw-r--r--Documentation/devicetree/bindings/riscv/microchip.yaml41
-rw-r--r--Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml146
-rw-r--r--Documentation/devicetree/bindings/riscv/spacemit.yaml32
-rw-r--r--Documentation/devicetree/bindings/riscv/starfive.yaml22
-rw-r--r--Documentation/devicetree/bindings/riscv/sunxi.yaml74
-rw-r--r--Documentation/devicetree/bindings/riscv/tenstorrent.yaml28
-rw-r--r--Documentation/devicetree/bindings/riscv/thead.yaml33
-rw-r--r--Documentation/devicetree/bindings/rng/SUNW,n2-rng.yaml50
-rw-r--r--Documentation/devicetree/bindings/rng/airoha,en7581-trng.yaml38
-rw-r--r--Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml8
-rw-r--r--Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml5
-rw-r--r--Documentation/devicetree/bindings/rng/brcm,bcm74110-rng.yaml35
-rw-r--r--Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml10
-rw-r--r--Documentation/devicetree/bindings/rng/hisi-rng.txt12
-rw-r--r--Documentation/devicetree/bindings/rng/hisi-rng.yaml32
-rw-r--r--Documentation/devicetree/bindings/rng/imx-rng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rng/ingenic,rng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rng/ingenic,trng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rng/inside-secure,safexcel-eip76.yaml84
-rw-r--r--Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rng/microchip,pic32-rng.txt17
-rw-r--r--Documentation/devicetree/bindings/rng/microchip,pic32-rng.yaml40
-rw-r--r--Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml49
-rw-r--r--Documentation/devicetree/bindings/rng/mtk-rng.yaml4
-rw-r--r--Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml4
-rw-r--r--Documentation/devicetree/bindings/rng/omap_rng.yaml92
-rw-r--r--Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml61
-rw-r--r--Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml60
-rw-r--r--Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml40
-rw-r--r--Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rng/sparc_sun_oracle_rng.txt30
-rw-r--r--Documentation/devicetree/bindings/rng/st,stm32-rng.yaml54
-rw-r--r--Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml59
-rw-r--r--Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml2
-rw-r--r--Documentation/devicetree/bindings/rtc/abracon,abx80x.txt31
-rw-r--r--Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml98
-rw-r--r--Documentation/devicetree/bindings/rtc/adi,max31335.yaml72
-rw-r--r--Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml4
-rw-r--r--Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml8
-rw-r--r--Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt19
-rw-r--r--Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml50
-rw-r--r--Documentation/devicetree/bindings/rtc/amlogic,a4-rtc.yaml68
-rw-r--r--Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml44
-rw-r--r--Documentation/devicetree/bindings/rtc/amlogic,meson6-rtc.yaml63
-rw-r--r--Documentation/devicetree/bindings/rtc/apm,xgene-rtc.yaml45
-rw-r--r--Documentation/devicetree/bindings/rtc/armada-380-rtc.txt24
-rw-r--r--Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml24
-rw-r--r--Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml9
-rw-r--r--Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml23
-rw-r--r--Documentation/devicetree/bindings/rtc/cirrus,ep9301-rtc.yaml42
-rw-r--r--Documentation/devicetree/bindings/rtc/digicolor-rtc.txt17
-rw-r--r--Documentation/devicetree/bindings/rtc/epson,rtc7301.txt16
-rw-r--r--Documentation/devicetree/bindings/rtc/epson,rtc7301.yaml51
-rw-r--r--Documentation/devicetree/bindings/rtc/epson,rx8900.yaml4
-rw-r--r--Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml4
-rw-r--r--Documentation/devicetree/bindings/rtc/fsl,ls-ftm-alarm.yaml73
-rw-r--r--Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml2
-rw-r--r--Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml51
-rw-r--r--Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt17
-rw-r--r--Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt30
-rw-r--r--Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml56
-rw-r--r--Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml31
-rw-r--r--Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml64
-rw-r--r--Documentation/devicetree/bindings/rtc/isil,isl12057.txt74
-rw-r--r--Documentation/devicetree/bindings/rtc/isil,isl1208.txt38
-rw-r--r--Documentation/devicetree/bindings/rtc/isil,isl1208.yaml100
-rw-r--r--Documentation/devicetree/bindings/rtc/loongson,rtc.yaml57
-rw-r--r--Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt15
-rw-r--r--Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml51
-rw-r--r--Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml40
-rw-r--r--Documentation/devicetree/bindings/rtc/maxim,ds1742.txt12
-rw-r--r--Documentation/devicetree/bindings/rtc/maxim,ds3231.txt38
-rw-r--r--Documentation/devicetree/bindings/rtc/maxim,mcp795.txt11
-rw-r--r--Documentation/devicetree/bindings/rtc/mediatek,mt2712-rtc.yaml39
-rw-r--r--Documentation/devicetree/bindings/rtc/mediatek,mt7622-rtc.yaml52
-rw-r--r--Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml67
-rw-r--r--Documentation/devicetree/bindings/rtc/microchip,mpfs-rtc.yaml69
-rw-r--r--Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml57
-rw-r--r--Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml6
-rw-r--r--Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt12
-rw-r--r--Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml4
-rw-r--r--Documentation/devicetree/bindings/rtc/mstar,ssd202d-rtc.yaml35
-rw-r--r--Documentation/devicetree/bindings/rtc/nuvoton,ma35d1-rtc.yaml48
-rw-r--r--Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml2
-rw-r--r--Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml1
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt21
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml63
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,lpc3220-rtc.yaml49
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf2123.yaml47
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml11
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml33
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf8523.txt18
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml45
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml60
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml2
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt17
-rw-r--r--Documentation/devicetree/bindings/rtc/nxp,s32g-rtc.yaml72
-rw-r--r--Documentation/devicetree/bindings/rtc/orion-rtc.txt18
-rw-r--r--Documentation/devicetree/bindings/rtc/pxa-rtc.txt14
-rw-r--r--Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml73
-rw-r--r--Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml84
-rw-r--r--Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml32
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-aspeed.txt22
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-cmos.txt2
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt36
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-m41t80.txt39
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt22
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-meson.txt35
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-mt2712.txt14
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-mt6397.txt31
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-mt7622.txt21
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-mxc.yaml12
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml2
-rw-r--r--Documentation/devicetree/bindings/rtc/rtc.yaml4
-rw-r--r--Documentation/devicetree/bindings/rtc/s3c-rtc.yaml45
-rw-r--r--Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml8
-rw-r--r--Documentation/devicetree/bindings/rtc/snvs-rtc.txt1
-rw-r--r--Documentation/devicetree/bindings/rtc/sophgo,cv1800b-rtc.yaml86
-rw-r--r--Documentation/devicetree/bindings/rtc/spear-rtc.txt15
-rw-r--r--Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml33
-rw-r--r--Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt26
-rw-r--r--Documentation/devicetree/bindings/rtc/st,m41t80.yaml73
-rw-r--r--Documentation/devicetree/bindings/rtc/st,m48t86.yaml38
-rw-r--r--Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml37
-rw-r--r--Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt21
-rw-r--r--Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml2
-rw-r--r--Documentation/devicetree/bindings/rtc/trivial-rtc.yaml44
-rw-r--r--Documentation/devicetree/bindings/rtc/twl-rtc.txt11
-rw-r--r--Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt15
-rw-r--r--Documentation/devicetree/bindings/rtc/xgene-rtc.txt28
-rw-r--r--Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml13
-rw-r--r--Documentation/devicetree/bindings/security/tpm/google,cr50.txt19
-rw-r--r--Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt41
-rw-r--r--Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt34
-rw-r--r--Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt32
-rw-r--r--Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt26
-rw-r--r--Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt25
-rw-r--r--Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt23
-rw-r--r--Documentation/devicetree/bindings/serial/8250.yaml106
-rw-r--r--Documentation/devicetree/bindings/serial/8250_omap.yaml48
-rw-r--r--Documentation/devicetree/bindings/serial/actions,owl-uart.txt16
-rw-r--r--Documentation/devicetree/bindings/serial/actions,owl-uart.yaml48
-rw-r--r--Documentation/devicetree/bindings/serial/altera_jtaguart.txt5
-rw-r--r--Documentation/devicetree/bindings/serial/altera_uart.txt8
-rw-r--r--Documentation/devicetree/bindings/serial/altr,juart-1.0.yaml19
-rw-r--r--Documentation/devicetree/bindings/serial/altr,uart-1.0.yaml25
-rw-r--r--Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml39
-rw-r--r--Documentation/devicetree/bindings/serial/arc-uart.txt25
-rw-r--r--Documentation/devicetree/bindings/serial/arm,dcc.yaml30
-rw-r--r--Documentation/devicetree/bindings/serial/arm,mps2-uart.txt19
-rw-r--r--Documentation/devicetree/bindings/serial/arm,mps2-uart.yaml46
-rw-r--r--Documentation/devicetree/bindings/serial/arm,sbsa-uart.yaml38
-rw-r--r--Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt10
-rw-r--r--Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml200
-rw-r--r--Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.txt18
-rw-r--r--Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.yaml46
-rw-r--r--Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml4
-rw-r--r--Documentation/devicetree/bindings/serial/cavium-uart.txt19
-rw-r--r--Documentation/devicetree/bindings/serial/cdns,uart.yaml42
-rw-r--r--Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt31
-rw-r--r--Documentation/devicetree/bindings/serial/cirrus,ep7209-uart.yaml56
-rw-r--r--Documentation/devicetree/bindings/serial/cnxt,cx92755-usart.yaml48
-rw-r--r--Documentation/devicetree/bindings/serial/digicolor-usart.txt27
-rw-r--r--Documentation/devicetree/bindings/serial/esp,esp32-acm.yaml42
-rw-r--r--Documentation/devicetree/bindings/serial/esp,esp32-uart.yaml51
-rw-r--r--Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml8
-rw-r--r--Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml65
-rw-r--r--Documentation/devicetree/bindings/serial/fsl-lpuart.yaml18
-rw-r--r--Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml15
-rw-r--r--Documentation/devicetree/bindings/serial/ingenic,uart.yaml6
-rw-r--r--Documentation/devicetree/bindings/serial/lantiq,asc.yaml56
-rw-r--r--Documentation/devicetree/bindings/serial/lantiq_asc.txt31
-rw-r--r--Documentation/devicetree/bindings/serial/marvell,armada-3700-uart.yaml102
-rw-r--r--Documentation/devicetree/bindings/serial/maxim,max310x.txt48
-rw-r--r--Documentation/devicetree/bindings/serial/maxim,max310x.yaml74
-rw-r--r--Documentation/devicetree/bindings/serial/mediatek,uart.yaml6
-rw-r--r--Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt29
-rw-r--r--Documentation/devicetree/bindings/serial/microchip,pic32mzda-uart.yaml53
-rw-r--r--Documentation/devicetree/bindings/serial/milbeaut-uart.txt21
-rw-r--r--Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt64
-rw-r--r--Documentation/devicetree/bindings/serial/mvebu-uart.txt56
-rw-r--r--Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml48
-rw-r--r--Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt73
-rw-r--r--Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml125
-rw-r--r--Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml73
-rw-r--r--Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt28
-rw-r--r--Documentation/devicetree/bindings/serial/nxp,lpc3220-hsuart.yaml39
-rw-r--r--Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt72
-rw-r--r--Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml133
-rw-r--r--Documentation/devicetree/bindings/serial/nxp-lpc32xx-hsuart.txt14
-rw-r--r--Documentation/devicetree/bindings/serial/pl011.yaml10
-rw-r--r--Documentation/devicetree/bindings/serial/qcom,msm-uart.txt25
-rw-r--r--Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml56
-rw-r--r--Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml19
-rw-r--r--Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml69
-rw-r--r--Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml5
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,em-uart.yaml28
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,hscif.yaml42
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,rsci.yaml83
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,sci.yaml30
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,scif.yaml184
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,scifa.yaml30
-rw-r--r--Documentation/devicetree/bindings/serial/renesas,scifb.yaml20
-rw-r--r--Documentation/devicetree/bindings/serial/rs485.yaml31
-rw-r--r--Documentation/devicetree/bindings/serial/samsung_uart.yaml132
-rw-r--r--Documentation/devicetree/bindings/serial/serial-peripheral-props.yaml41
-rw-r--r--Documentation/devicetree/bindings/serial/serial.yaml66
-rw-r--r--Documentation/devicetree/bindings/serial/sifive-serial.yaml6
-rw-r--r--Documentation/devicetree/bindings/serial/snps,arc-uart.yaml51
-rw-r--r--Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml68
-rw-r--r--Documentation/devicetree/bindings/serial/socionext,milbeaut-usio-uart.yaml56
-rw-r--r--Documentation/devicetree/bindings/serial/sprd-uart.yaml13
-rw-r--r--Documentation/devicetree/bindings/serial/st,asc.yaml55
-rw-r--r--Documentation/devicetree/bindings/serial/st,stm32-uart.yaml14
-rw-r--r--Documentation/devicetree/bindings/serial/st-asc.txt18
-rw-r--r--Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml6
-rw-r--r--Documentation/devicetree/bindings/serial/via,vt8500-uart.yaml46
-rw-r--r--Documentation/devicetree/bindings/serial/vt8500-uart.txt27
-rw-r--r--Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml9
-rw-r--r--Documentation/devicetree/bindings/serio/allwinner,sun4i-a10-ps2.yaml2
-rw-r--r--Documentation/devicetree/bindings/serio/ps2-gpio.yaml2
-rw-r--r--Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.txt19
-rw-r--r--Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.yaml48
-rw-r--r--Documentation/devicetree/bindings/slimbus/bus.txt60
-rw-r--r--Documentation/devicetree/bindings/slimbus/qcom,slim-ngd.yaml120
-rw-r--r--Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt84
-rw-r--r--Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt39
-rw-r--r--Documentation/devicetree/bindings/slimbus/slimbus.yaml96
-rw-r--r--Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml51
-rw-r--r--Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml4
-rw-r--r--Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml42
-rw-r--r--Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml207
-rw-r--r--Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt21
-rw-r--r--Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml4
-rw-r--r--Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml35
-rw-r--r--Documentation/devicetree/bindings/soc/bcm/brcm,bcm2711-avs-monitor.yaml44
-rw-r--r--Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml38
-rw-r--r--Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt47
-rw-r--r--Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml94
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/bman-portals.txt56
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/bman.txt137
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml193
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml205
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-firmware.yaml48
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ic.yaml47
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-muram.yaml70
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-si.yaml40
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-siram.yaml39
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-tsa.yaml210
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ucc-qmc.yaml197
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml148
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,ucc-hdlc.yaml140
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt130
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt178
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,bman-portal.yaml52
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,bman.yaml83
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,imx23-digctl.yaml53
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml3
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml6
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,ls1028a-reset.yaml56
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,qman-fqd.yaml69
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,qman-portal.yaml112
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,qman.yaml93
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,rcpm.yaml87
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/fsl,vf610-src.yaml47
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/qman-portals.txt134
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/qman.txt187
-rw-r--r--Documentation/devicetree/bindings/soc/fsl/rcpm.txt69
-rw-r--r--Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml35
-rw-r--r--Documentation/devicetree/bindings/soc/hisilicon/hisilicon,hi3660-usb3-otg-bc.yaml46
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml5
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx-anatop.yaml146
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml90
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml22
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml6
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml53
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml2
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml61
-rw-r--r--Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml3
-rw-r--r--Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml4
-rw-r--r--Documentation/devicetree/bindings/soc/intel/intel,lgm-syscon.yaml57
-rw-r--r--Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml4
-rw-r--r--Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml83
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/devapc.yaml4
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml52
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml84
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml23
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml168
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml5
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/pwrap.txt72
-rw-r--r--Documentation/devicetree/bindings/soc/mediatek/scpsys.txt1
-rw-r--r--Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml30
-rw-r--r--Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml58
-rw-r--r--Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml12
-rw-r--r--Documentation/devicetree/bindings/soc/microchip/microchip,sparx5-cpu-syscon.yaml49
-rw-r--r--Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml352
-rw-r--r--Documentation/devicetree/bindings/soc/nuvoton/nuvoton,gfxi.yaml39
-rw-r--r--Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml50
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml20
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml53
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml186
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml45
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml44
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml55
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt94
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml2
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml36
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml46
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml126
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml71
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml116
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml34
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml107
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml120
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,se-common-props.yaml26
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml92
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml40
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml6
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml10
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml32
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml82
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml19
-rw-r--r--Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml18
-rw-r--r--Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml43
-rw-r--r--Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml55
-rw-r--r--Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml5
-rw-r--r--Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml56
-rw-r--r--Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml73
-rw-r--r--Documentation/devicetree/bindings/soc/renesas/renesas.yaml630
-rw-r--r--Documentation/devicetree/bindings/soc/rockchip/grf.yaml141
-rw-r--r--Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml130
-rw-r--r--Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml130
-rw-r--r--Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml133
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml50
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml77
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml106
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml65
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml64
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml61
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml68
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml114
-rw-r--r--Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml104
-rw-r--r--Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-top-syscon.yaml80
-rw-r--r--Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2044-top-syscon.yaml49
-rw-r--r--Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml52
-rw-r--r--Documentation/devicetree/bindings/soc/spacemit/spacemit,k1-syscon.yaml95
-rw-r--r--Documentation/devicetree/bindings/soc/sprd/sprd,sc9863a-glbregs.yaml55
-rw-r--r--Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml93
-rw-r--r--Documentation/devicetree/bindings/soc/sti/st,sti-syscon.yaml55
-rw-r--r--Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml84
-rw-r--r--Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml40
-rw-r--r--Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml41
-rw-r--r--Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml416
-rw-r--r--Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml26
-rw-r--r--Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml6
-rw-r--r--Documentation/devicetree/bindings/soc/ti/ti,am654-serdes-ctrl.yaml43
-rw-r--r--Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml137
-rw-r--r--Documentation/devicetree/bindings/soc/ti/ti,j784s4-bist.yaml63
-rw-r--r--Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml45
-rw-r--r--Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml32
-rw-r--r--Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml280
-rw-r--r--Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt26
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau1372.yaml10
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau1373.yaml111
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau17x1.txt32
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau17x1.yaml52
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau1977.yaml1
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau7002.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau7002.yaml40
-rw-r--r--Documentation/devicetree/bindings/sound/adi,adau7118.yaml6
-rw-r--r--Documentation/devicetree/bindings/sound/adi,max98388.yaml79
-rw-r--r--Documentation/devicetree/bindings/sound/adi,max98396.yaml10
-rw-r--r--Documentation/devicetree/bindings/sound/adi,ssm2518.yaml49
-rw-r--r--Documentation/devicetree/bindings/sound/adi,ssm2602.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/ak4104.txt25
-rw-r--r--Documentation/devicetree/bindings/sound/ak4375.yaml57
-rw-r--r--Documentation/devicetree/bindings/sound/ak4458.txt28
-rw-r--r--Documentation/devicetree/bindings/sound/ak4554.txt11
-rw-r--r--Documentation/devicetree/bindings/sound/ak4613.yaml49
-rw-r--r--Documentation/devicetree/bindings/sound/ak4642.yaml56
-rw-r--r--Documentation/devicetree/bindings/sound/ak5558.txt24
-rw-r--r--Documentation/devicetree/bindings/sound/alc5623.txt25
-rw-r--r--Documentation/devicetree/bindings/sound/alc5632.txt43
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml95
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml9
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml54
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml12
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,aiu.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt34
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml112
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt29
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml82
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt124
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml181
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt27
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml86
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt25
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml79
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt36
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml88
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt22
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml55
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt58
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.yaml54
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml25
-rw-r--r--Documentation/devicetree/bindings/sound/amlogic,t9015.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/apple,mca.yaml21
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4104.yaml49
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4375.yaml60
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml77
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4554.yaml27
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4613.yaml59
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4619.yaml62
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak4642.yaml59
-rw-r--r--Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml48
-rw-r--r--Documentation/devicetree/bindings/sound/atmel,asoc-wm8904.yaml84
-rw-r--r--Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml109
-rw-r--r--Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml72
-rw-r--r--Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml76
-rw-r--r--Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt26
-rw-r--r--Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt35
-rw-r--r--Documentation/devicetree/bindings/sound/atmel-wm8904.txt55
-rw-r--r--Documentation/devicetree/bindings/sound/audio-graph-card.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/audio-graph-card2.yaml37
-rw-r--r--Documentation/devicetree/bindings/sound/audio-graph-port.yaml88
-rw-r--r--Documentation/devicetree/bindings/sound/audio-graph.yaml25
-rw-r--r--Documentation/devicetree/bindings/sound/audio-iio-aux.yaml64
-rw-r--r--Documentation/devicetree/bindings/sound/awinic,aw8738.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/awinic,aw87390.yaml58
-rw-r--r--Documentation/devicetree/bindings/sound/awinic,aw88395.yaml85
-rw-r--r--Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt24
-rw-r--r--Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.yaml51
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml62
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml88
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs4270.yaml59
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs4271.yaml111
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml12
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml314
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml18
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs42l84.yaml56
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs42xx8.yaml85
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml195
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,cs530x.yaml93
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml82
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/cirrus,madera.yaml3
-rw-r--r--Documentation/devicetree/bindings/sound/component-common.yaml21
-rw-r--r--Documentation/devicetree/bindings/sound/cs35l35.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/cs35l36.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/cs4265.txt29
-rw-r--r--Documentation/devicetree/bindings/sound/cs4270.txt21
-rw-r--r--Documentation/devicetree/bindings/sound/cs4271.txt57
-rw-r--r--Documentation/devicetree/bindings/sound/cs42xx8.txt34
-rw-r--r--Documentation/devicetree/bindings/sound/cs4341.txt22
-rw-r--r--Documentation/devicetree/bindings/sound/cs4349.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/cs53l30.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/da7213.txt45
-rw-r--r--Documentation/devicetree/bindings/sound/da7219.txt112
-rw-r--r--Documentation/devicetree/bindings/sound/da9055.txt22
-rw-r--r--Documentation/devicetree/bindings/sound/dai-common.yaml18
-rw-r--r--Documentation/devicetree/bindings/sound/dai-params.yaml11
-rw-r--r--Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml21
-rw-r--r--Documentation/devicetree/bindings/sound/davinci-mcbsp.txt50
-rw-r--r--Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml113
-rw-r--r--Documentation/devicetree/bindings/sound/dialog,da7219.yaml238
-rw-r--r--Documentation/devicetree/bindings/sound/dlg,da7213.yaml103
-rw-r--r--Documentation/devicetree/bindings/sound/dmic-codec.yaml58
-rw-r--r--Documentation/devicetree/bindings/sound/dmic.txt22
-rw-r--r--Documentation/devicetree/bindings/sound/es8328.txt38
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es7134.txt15
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es71x4.yaml62
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es7241.txt28
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es7241.yaml68
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es8316.yaml36
-rw-r--r--[-rwxr-xr-x]Documentation/devicetree/bindings/sound/everest,es8326.yaml14
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es8328.yaml86
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es8375.yaml71
-rw-r--r--Documentation/devicetree/bindings/sound/everest,es8389.yaml50
-rw-r--r--Documentation/devicetree/bindings/sound/foursemi,fs2105s.yaml101
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,asrc.txt80
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,audmix.txt50
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,audmix.yaml142
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,easrc.yaml49
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,esai.txt68
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,esai.yaml136
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml189
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,imx-audio-es8328.yaml111
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml64
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,micfil.yaml17
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,mqs.txt36
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,mqs.yaml117
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,mxs-audio-sgtl5000.yaml81
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml147
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml55
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,sai.yaml194
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,saif.yaml83
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml113
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml27
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,spdif.yaml62
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,ssi.txt87
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,ssi.yaml194
-rw-r--r--Documentation/devicetree/bindings/sound/fsl,xcvr.yaml92
-rw-r--r--Documentation/devicetree/bindings/sound/fsl-asoc-card.txt115
-rw-r--r--Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml243
-rw-r--r--Documentation/devicetree/bindings/sound/google,chv3-codec.yaml31
-rw-r--r--Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml44
-rw-r--r--Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml10
-rw-r--r--Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml22
-rw-r--r--Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml30
-rw-r--r--Documentation/devicetree/bindings/sound/gtm601.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/ics43432.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/imx-audio-card.yaml32
-rw-r--r--Documentation/devicetree/bindings/sound/imx-audio-es8328.txt60
-rw-r--r--Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt56
-rw-r--r--Documentation/devicetree/bindings/sound/imx-audio-spdif.txt36
-rw-r--r--Documentation/devicetree/bindings/sound/infineon,peb2466.yaml91
-rw-r--r--Documentation/devicetree/bindings/sound/ingenic,aic.yaml18
-rw-r--r--Documentation/devicetree/bindings/sound/ingenic,codec.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/inno-rk3036.txt20
-rw-r--r--Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml42
-rw-r--r--Documentation/devicetree/bindings/sound/invensense,ics43432.yaml51
-rw-r--r--Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml48
-rw-r--r--Documentation/devicetree/bindings/sound/irondevice,sma1307.yaml53
-rw-r--r--Documentation/devicetree/bindings/sound/linux,bt-sco.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml37
-rw-r--r--Documentation/devicetree/bindings/sound/linux,spdif.yaml42
-rw-r--r--Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml70
-rw-r--r--Documentation/devicetree/bindings/sound/loongson,ls1b-ac97.yaml68
-rw-r--r--Documentation/devicetree/bindings/sound/loongson,ls2k1000-i2s.yaml68
-rw-r--r--Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/max98090.txt59
-rw-r--r--Documentation/devicetree/bindings/sound/max98095.txt22
-rw-r--r--Documentation/devicetree/bindings/sound/max98357a.txt28
-rw-r--r--Documentation/devicetree/bindings/sound/max98371.txt17
-rw-r--r--Documentation/devicetree/bindings/sound/max98504.txt44
-rw-r--r--Documentation/devicetree/bindings/sound/max9867.txt17
-rw-r--r--Documentation/devicetree/bindings/sound/max9892x.txt44
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max9759.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max9759.yaml45
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98088.txt23
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98088.yaml47
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98090.yaml84
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98095.yaml54
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98357a.yaml52
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98371.yaml42
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98390.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98504.yaml86
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max9867.yaml60
-rw-r--r--Documentation/devicetree/bindings/sound/maxim,max98925.yaml98
-rw-r--r--Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml108
-rw-r--r--Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml73
-rw-r--r--Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml75
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml116
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml54
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml160
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml67
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8173-afe-pcm.yaml98
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8183-audio.yaml228
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8183_da7219.yaml49
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8183_mt6358_ts3a227.yaml59
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml241
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml136
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8189-afe-pcm.yaml178
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8189-nau8825.yaml101
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml130
-rw-r--r--Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml107
-rw-r--r--Documentation/devicetree/bindings/sound/microchip,pdmc.yaml100
-rw-r--r--Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml115
-rw-r--r--Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml105
-rw-r--r--Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml76
-rw-r--r--Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml78
-rw-r--r--Documentation/devicetree/bindings/sound/mscc,zl38060.yaml72
-rw-r--r--Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt146
-rw-r--r--Documentation/devicetree/bindings/sound/mt2701-wm8960.txt24
-rw-r--r--Documentation/devicetree/bindings/sound/mt6359.yaml12
-rw-r--r--Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt42
-rw-r--r--Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt21
-rw-r--r--Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt25
-rw-r--r--Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml11
-rw-r--r--Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml132
-rw-r--r--Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml138
-rw-r--r--Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml11
-rw-r--r--Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml146
-rw-r--r--Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml6
-rw-r--r--Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml146
-rw-r--r--Documentation/devicetree/bindings/sound/mtk-afe-pcm.txt45
-rw-r--r--Documentation/devicetree/bindings/sound/mvebu-audio.txt14
-rw-r--r--Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt42
-rw-r--r--Documentation/devicetree/bindings/sound/mxs-saif.txt41
-rw-r--r--Documentation/devicetree/bindings/sound/name-prefix.yaml21
-rw-r--r--Documentation/devicetree/bindings/sound/nau8315.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/nau8540.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/nau8810.txt17
-rw-r--r--Documentation/devicetree/bindings/sound/nau8821.txt55
-rw-r--r--Documentation/devicetree/bindings/sound/nau8822.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/nau8824.txt88
-rw-r--r--Documentation/devicetree/bindings/sound/nau8825.txt108
-rw-r--r--Documentation/devicetree/bindings/sound/neofidelity,ntp8835.yaml73
-rw-r--r--Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml72
-rw-r--r--Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml44
-rw-r--r--Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml80
-rw-r--r--Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml148
-rw-r--r--Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml58
-rw-r--r--Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml190
-rw-r--r--Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml253
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml1
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml90
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml85
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml6
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml26
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml6
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml6
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt36
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml82
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt12
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml36
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml119
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml10
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml8
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml1
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml1
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml109
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt27
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml67
-rw-r--r--Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml73
-rw-r--r--Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/omap-mcpdm.txt30
-rw-r--r--Documentation/devicetree/bindings/sound/omap-twl4030.txt62
-rw-r--r--Documentation/devicetree/bindings/sound/option,gtm601.yaml42
-rw-r--r--Documentation/devicetree/bindings/sound/pcm1789.txt22
-rw-r--r--Documentation/devicetree/bindings/sound/pcm179x.txt27
-rw-r--r--Documentation/devicetree/bindings/sound/pcm186x.txt42
-rw-r--r--Documentation/devicetree/bindings/sound/pcm5102a.txt13
-rw-r--r--Documentation/devicetree/bindings/sound/pcm512x.txt52
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml205
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,apq8096.txt128
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml143
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml118
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml118
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml143
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml81
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt101
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital-codec.yaml55
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt20
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,pm4125-codec.yaml134
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,pm4125-sdw.yaml79
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml153
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6adm-routing.yaml29
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6adm.yaml51
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6afe.yaml81
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml28
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml35
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6apm.yaml68
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml52
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6asm.yaml68
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6core.yaml39
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml46
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml65
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6prm.yaml50
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,q6usb.yaml55
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,sm8250.yaml173
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd9335.txt123
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml156
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml75
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml127
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml82
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml6
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml97
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml69
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml99
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml95
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml38
-rw-r--r--Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml83
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,alc203.yaml36
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,alc5623.yaml54
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,alc5632.yaml63
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt1015.yaml41
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml4
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt1016.yaml40
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt1019.yaml35
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5514.yaml70
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5616.yaml61
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5631.yaml67
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5640.yaml146
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5645.yaml131
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5659.yaml129
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5677.yaml135
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5682.yaml156
-rw-r--r--Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml33
-rw-r--r--Documentation/devicetree/bindings/sound/renesas,fsi.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/renesas,idt821034.yaml75
-rw-r--r--Documentation/devicetree/bindings/sound/renesas,rsnd.txt4
-rw-r--r--Documentation/devicetree/bindings/sound/renesas,rsnd.yaml214
-rw-r--r--Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml51
-rw-r--r--Documentation/devicetree/bindings/sound/richtek,rt9120.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/richtek,rt9123.yaml63
-rw-r--r--Documentation/devicetree/bindings/sound/richtek,rt9123p.yaml48
-rw-r--r--Documentation/devicetree/bindings/sound/richtek,rtq9128.yaml61
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml15
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,pdm.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,rk3036-codec.yaml58
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml102
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip,rk3576-sai.yaml144
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip-i2s.yaml10
-rw-r--r--Documentation/devicetree/bindings/sound/rockchip-spdif.yaml28
-rw-r--r--Documentation/devicetree/bindings/sound/rohm,bd28623.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/rt1015.txt23
-rw-r--r--Documentation/devicetree/bindings/sound/rt1016.txt17
-rw-r--r--Documentation/devicetree/bindings/sound/rt1019.yaml35
-rw-r--r--Documentation/devicetree/bindings/sound/rt5514.txt37
-rw-r--r--Documentation/devicetree/bindings/sound/rt5616.txt32
-rw-r--r--Documentation/devicetree/bindings/sound/rt5631.txt48
-rw-r--r--Documentation/devicetree/bindings/sound/rt5640.txt94
-rw-r--r--Documentation/devicetree/bindings/sound/rt5645.txt76
-rw-r--r--Documentation/devicetree/bindings/sound/rt5659.txt89
-rw-r--r--Documentation/devicetree/bindings/sound/rt5663.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/rt5677.txt78
-rw-r--r--Documentation/devicetree/bindings/sound/rt5682.txt78
-rw-r--r--Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml16
-rw-r--r--Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml49
-rw-r--r--Documentation/devicetree/bindings/sound/samsung,odroid.yaml24
-rw-r--r--Documentation/devicetree/bindings/sound/samsung,tm2.yaml22
-rw-r--r--Documentation/devicetree/bindings/sound/samsung-i2s.yaml33
-rw-r--r--Documentation/devicetree/bindings/sound/serial-midi.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/sgtl5000.yaml110
-rw-r--r--Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml4
-rw-r--r--Documentation/devicetree/bindings/sound/simple-audio-mux.yaml13
-rw-r--r--Documentation/devicetree/bindings/sound/simple-card.yaml111
-rw-r--r--Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml141
-rw-r--r--Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/sound-card-common.yaml34
-rw-r--r--Documentation/devicetree/bindings/sound/sound-dai.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/spacemit,k1-i2s.yaml87
-rw-r--r--Documentation/devicetree/bindings/sound/spdif-receiver.txt10
-rw-r--r--Documentation/devicetree/bindings/sound/sprd,pcm-platform.yaml56
-rw-r--r--Documentation/devicetree/bindings/sound/sprd,sc9860-mcdt.yaml47
-rw-r--r--Documentation/devicetree/bindings/sound/sprd-mcdt.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/sprd-pcm.txt23
-rw-r--r--Documentation/devicetree/bindings/sound/ssm2518.txt20
-rw-r--r--Documentation/devicetree/bindings/sound/st,sta350.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml50
-rw-r--r--Documentation/devicetree/bindings/sound/st,stm32-sai.yaml34
-rw-r--r--Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml13
-rw-r--r--Documentation/devicetree/bindings/sound/starfive,jh7110-pwmdac.yaml76
-rw-r--r--Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml98
-rw-r--r--Documentation/devicetree/bindings/sound/tas2562.yaml78
-rw-r--r--Documentation/devicetree/bindings/sound/tas2770.yaml82
-rw-r--r--Documentation/devicetree/bindings/sound/tas27xx.yaml77
-rw-r--r--Documentation/devicetree/bindings/sound/tas571x.txt48
-rw-r--r--Documentation/devicetree/bindings/sound/tas5720.txt2
-rw-r--r--Documentation/devicetree/bindings/sound/tas5805m.yaml56
-rw-r--r--Documentation/devicetree/bindings/sound/test-component.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/tfa9879.txt23
-rw-r--r--Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml2
-rw-r--r--Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml98
-rw-r--r--Documentation/devicetree/bindings/sound/ti,omap4-mcpdm.yaml73
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm1681.txt15
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm1681.yaml43
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm1754.yaml55
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm1862.yaml76
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm3168a.txt56
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml108
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm512x.yaml101
-rw-r--r--Documentation/devicetree/bindings/sound/ti,pcm6240.yaml179
-rw-r--r--Documentation/devicetree/bindings/sound/ti,src4xxx.yaml4
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas2562.yaml83
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas2770.yaml90
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas2781.yaml299
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas27xx.yaml85
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas57xx.yaml137
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas5805m.yaml57
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml37
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tlv320adcx140.yaml209
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml101
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml166
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tlv320dac3100.yaml126
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tpa6130a2.yaml55
-rw-r--r--Documentation/devicetree/bindings/sound/ti,twl4030-audio.yaml90
-rw-r--r--Documentation/devicetree/bindings/sound/tlv320adcx140.yaml209
-rw-r--r--Documentation/devicetree/bindings/sound/tlv320aic31xx.txt77
-rw-r--r--Documentation/devicetree/bindings/sound/tlv320aic32x4.txt42
-rw-r--r--Documentation/devicetree/bindings/sound/tlv320aic3x.txt97
-rw-r--r--Documentation/devicetree/bindings/sound/tpa6130a2.txt27
-rw-r--r--Documentation/devicetree/bindings/sound/trivial-codec.yaml79
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,arizona.yaml3
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8524.yaml40
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8731.yaml1
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8782.yaml47
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8804.yaml58
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8903.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8904.yaml203
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8940.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8960.yaml134
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8962.yaml5
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8974.txt15
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8978.yaml7
-rw-r--r--Documentation/devicetree/bindings/sound/wlf,wm8994.yaml194
-rw-r--r--Documentation/devicetree/bindings/sound/wm8510.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/wm8523.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/wm8524.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/wm8580.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/wm8711.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/wm8728.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/wm8737.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/wm8750.yaml42
-rw-r--r--Documentation/devicetree/bindings/sound/wm8753.txt40
-rw-r--r--Documentation/devicetree/bindings/sound/wm8770.txt16
-rw-r--r--Documentation/devicetree/bindings/sound/wm8776.txt18
-rw-r--r--Documentation/devicetree/bindings/sound/wm8782.txt17
-rw-r--r--Documentation/devicetree/bindings/sound/wm8804.txt25
-rw-r--r--Documentation/devicetree/bindings/sound/wm8904.txt33
-rw-r--r--Documentation/devicetree/bindings/sound/wm8960.txt42
-rw-r--r--Documentation/devicetree/bindings/sound/wm8994.txt112
-rw-r--r--Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt29
-rw-r--r--Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml72
-rw-r--r--Documentation/devicetree/bindings/sound/xlnx,i2s.txt28
-rw-r--r--Documentation/devicetree/bindings/sound/xlnx,i2s.yaml65
-rw-r--r--Documentation/devicetree/bindings/sound/xlnx,spdif.txt28
-rw-r--r--Documentation/devicetree/bindings/sound/xlnx,spdif.yaml77
-rw-r--r--Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml63
-rw-r--r--Documentation/devicetree/bindings/sound/zl38060.yaml69
-rw-r--r--Documentation/devicetree/bindings/soundwire/qcom,sdw.txt214
-rw-r--r--Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml285
-rw-r--r--Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml2
-rw-r--r--Documentation/devicetree/bindings/spi/adi,axi-spi-engine.txt31
-rw-r--r--Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml90
-rw-r--r--Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml70
-rw-r--r--Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml13
-rw-r--r--Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml23
-rw-r--r--Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml44
-rw-r--r--Documentation/devicetree/bindings/spi/amlogic,a4-spifc.yaml82
-rw-r--r--Documentation/devicetree/bindings/spi/amlogic,a4-spisg.yaml59
-rw-r--r--Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml105
-rw-r--r--Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml28
-rw-r--r--Documentation/devicetree/bindings/spi/apple,spi.yaml66
-rw-r--r--Documentation/devicetree/bindings/spi/arm,pl022-peripheral-props.yaml61
-rw-r--r--Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml32
-rw-r--r--Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml18
-rw-r--r--Documentation/devicetree/bindings/spi/atmel,quadspi.yaml5
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt38
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.yaml53
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt23
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.yaml50
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml134
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml71
-rw-r--r--Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml160
-rw-r--r--Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml135
-rw-r--r--Documentation/devicetree/bindings/spi/cdns,xspi.yaml36
-rw-r--r--Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml70
-rw-r--r--Documentation/devicetree/bindings/spi/fsl,dspi-peripheral-props.yaml30
-rw-r--r--Documentation/devicetree/bindings/spi/fsl,dspi.yaml134
-rw-r--r--Documentation/devicetree/bindings/spi/fsl,espi.yaml65
-rw-r--r--Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml21
-rw-r--r--Documentation/devicetree/bindings/spi/fsl,spi.yaml74
-rw-r--r--Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml13
-rw-r--r--Documentation/devicetree/bindings/spi/fsl-spi.txt62
-rw-r--r--Documentation/devicetree/bindings/spi/ibm,spi-fsi.yaml55
-rw-r--r--Documentation/devicetree/bindings/spi/ingenic,spi.yaml2
-rw-r--r--Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml46
-rw-r--r--Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml55
-rw-r--r--Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml37
-rw-r--r--Documentation/devicetree/bindings/spi/marvell,orion-spi.yaml102
-rw-r--r--Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml10
-rw-r--r--Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml54
-rw-r--r--Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml2
-rw-r--r--Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml106
-rw-r--r--Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml2
-rw-r--r--Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml4
-rw-r--r--Documentation/devicetree/bindings/spi/mxs-spi.yaml5
-rw-r--r--Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt2
-rw-r--r--Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt36
-rw-r--r--Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.yaml72
-rw-r--r--Documentation/devicetree/bindings/spi/nuvoton,wpcm450-fiu.yaml61
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt61
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml100
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt37
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml81
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt37
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml90
-rw-r--r--Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml63
-rw-r--r--Documentation/devicetree/bindings/spi/nxp,lpc3220-spi.yaml44
-rw-r--r--Documentation/devicetree/bindings/spi/nxp,sc18is.yaml51
-rw-r--r--Documentation/devicetree/bindings/spi/omap-spi.yaml4
-rw-r--r--Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml3
-rw-r--r--Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml14
-rw-r--r--Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml89
-rw-r--r--Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml15
-rw-r--r--Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml2
-rw-r--r--Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml62
-rw-r--r--Documentation/devicetree/bindings/spi/renesas,rspi.yaml24
-rw-r--r--Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml141
-rw-r--r--Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml79
-rw-r--r--Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml47
-rw-r--r--Documentation/devicetree/bindings/spi/rockchip-sfc.yaml2
-rw-r--r--Documentation/devicetree/bindings/spi/samsung,spi.yaml12
-rw-r--r--Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml48
-rw-r--r--Documentation/devicetree/bindings/spi/socionext,f-ospi.yaml57
-rw-r--r--Documentation/devicetree/bindings/spi/socionext,synquacer-spi.yaml73
-rw-r--r--Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml3
-rw-r--r--Documentation/devicetree/bindings/spi/spi-armada-3700.txt25
-rw-r--r--Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt33
-rw-r--r--Documentation/devicetree/bindings/spi/spi-bcm63xx.txt33
-rw-r--r--Documentation/devicetree/bindings/spi/spi-cadence.yaml31
-rw-r--r--Documentation/devicetree/bindings/spi/spi-controller.yaml59
-rw-r--r--Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt65
-rw-r--r--Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml24
-rw-r--r--Documentation/devicetree/bindings/spi/spi-gpio.yaml6
-rw-r--r--Documentation/devicetree/bindings/spi/spi-mux.yaml5
-rw-r--r--Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml24
-rw-r--r--Documentation/devicetree/bindings/spi/spi-orion.txt79
-rw-r--r--Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml36
-rw-r--r--Documentation/devicetree/bindings/spi/spi-pl022.yaml56
-rw-r--r--Documentation/devicetree/bindings/spi/spi-rockchip.yaml6
-rw-r--r--Documentation/devicetree/bindings/spi/spi-sc18is602.txt23
-rw-r--r--Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml54
-rw-r--r--Documentation/devicetree/bindings/spi/spi-sifive.yaml6
-rw-r--r--Documentation/devicetree/bindings/spi/spi-sprd.txt33
-rw-r--r--Documentation/devicetree/bindings/spi/spi-st-ssc.txt40
-rw-r--r--Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml6
-rw-r--r--Documentation/devicetree/bindings/spi/spi-synquacer.txt27
-rw-r--r--Documentation/devicetree/bindings/spi/spi-xilinx.yaml6
-rw-r--r--Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml39
-rw-r--r--Documentation/devicetree/bindings/spi/sprd,sc9860-spi.yaml72
-rw-r--r--Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml5
-rw-r--r--Documentation/devicetree/bindings/spi/st,ssc-spi.yaml61
-rw-r--r--Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml8
-rw-r--r--Documentation/devicetree/bindings/spi/st,stm32-spi.yaml81
-rw-r--r--Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml106
-rw-r--r--Documentation/devicetree/bindings/spi/ti,qspi.yaml96
-rw-r--r--Documentation/devicetree/bindings/spi/ti_qspi.txt53
-rw-r--r--Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml4
-rw-r--r--Documentation/devicetree/bindings/spmi/apple,spmi.yaml57
-rw-r--r--Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml17
-rw-r--r--Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml16
-rw-r--r--Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml11
-rw-r--r--Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml140
-rw-r--r--Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml45
-rw-r--r--Documentation/devicetree/bindings/sram/qcom,imem.yaml24
-rw-r--r--Documentation/devicetree/bindings/sram/qcom,ocmem.yaml27
-rw-r--r--Documentation/devicetree/bindings/sram/sram.yaml7
-rw-r--r--Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt24
-rw-r--r--Documentation/devicetree/bindings/submitting-patches.rst44
-rw-r--r--Documentation/devicetree/bindings/thermal/airoha,en7581-thermal.yaml48
-rw-r--r--Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml95
-rw-r--r--Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt33
-rw-r--r--Documentation/devicetree/bindings/thermal/amazon,al-thermal.yaml50
-rw-r--r--Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml39
-rw-r--r--Documentation/devicetree/bindings/thermal/armada-thermal.txt41
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml24
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml18
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt41
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml47
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt105
-rw-r--r--Documentation/devicetree/bindings/thermal/brcm,sr-thermal.yaml121
-rw-r--r--Documentation/devicetree/bindings/thermal/da9062-thermal.txt36
-rw-r--r--Documentation/devicetree/bindings/thermal/db8500-thermal.txt44
-rw-r--r--Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml35
-rw-r--r--Documentation/devicetree/bindings/thermal/fsl,imx91-tmu.yaml87
-rw-r--r--Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml7
-rw-r--r--Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml85
-rw-r--r--Documentation/devicetree/bindings/thermal/hisilicon,tsensor.yaml57
-rw-r--r--Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt32
-rw-r--r--Documentation/devicetree/bindings/thermal/imx-thermal.yaml66
-rw-r--r--Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml26
-rw-r--r--Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml71
-rw-r--r--Documentation/devicetree/bindings/thermal/marvell,armada-ap806-thermal.yaml46
-rw-r--r--Documentation/devicetree/bindings/thermal/marvell,armada370-thermal.yaml37
-rw-r--r--Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml148
-rw-r--r--Documentation/devicetree/bindings/thermal/mediatek,thermal.yaml106
-rw-r--r--Documentation/devicetree/bindings/thermal/mediatek-thermal.txt49
-rw-r--r--Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt238
-rw-r--r--Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml388
-rw-r--r--Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml12
-rw-r--r--Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml9
-rw-r--r--Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml1
-rw-r--r--Documentation/devicetree/bindings/thermal/qcom-lmh.yaml16
-rw-r--r--Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml20
-rw-r--r--Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml38
-rw-r--r--Documentation/devicetree/bindings/thermal/qcom-tsens.yaml354
-rw-r--r--Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml16
-rw-r--r--Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml76
-rw-r--r--Documentation/devicetree/bindings/thermal/rcar-thermal.yaml64
-rw-r--r--Documentation/devicetree/bindings/thermal/renesas,r9a08g045-tsu.yaml93
-rw-r--r--Documentation/devicetree/bindings/thermal/renesas,r9a09g047-tsu.yaml91
-rw-r--r--Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml83
-rw-r--r--Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml45
-rw-r--r--Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml3
-rw-r--r--Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml20
-rw-r--r--Documentation/devicetree/bindings/thermal/sprd-thermal.yaml51
-rw-r--r--Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml58
-rw-r--r--Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml7
-rw-r--r--Documentation/devicetree/bindings/thermal/st-thermal.txt32
-rw-r--r--Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml6
-rw-r--r--Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt95
-rw-r--r--Documentation/devicetree/bindings/thermal/thermal-idle.yaml156
-rw-r--r--Documentation/devicetree/bindings/thermal/thermal-sensor.yaml2
-rw-r--r--Documentation/devicetree/bindings/thermal/thermal-zones.yaml28
-rw-r--r--Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml17
-rw-r--r--Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml42
-rw-r--r--Documentation/devicetree/bindings/timer/actions,owl-timer.txt21
-rw-r--r--Documentation/devicetree/bindings/timer/actions,owl-timer.yaml107
-rw-r--r--Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml2
-rw-r--r--Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml2
-rw-r--r--Documentation/devicetree/bindings/timer/altr,timer-1.0.txt18
-rw-r--r--Documentation/devicetree/bindings/timer/altr,timer-1.0.yaml39
-rw-r--r--Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt22
-rw-r--r--Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml54
-rw-r--r--Documentation/devicetree/bindings/timer/andestech,plmt0.yaml53
-rw-r--r--Documentation/devicetree/bindings/timer/arm,arch_timer.yaml11
-rw-r--r--Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml5
-rw-r--r--Documentation/devicetree/bindings/timer/arm,mps2-timer.txt28
-rw-r--r--Documentation/devicetree/bindings/timer/arm,mps2-timer.yaml49
-rw-r--r--Documentation/devicetree/bindings/timer/arm,twd-timer.yaml6
-rw-r--r--Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt22
-rw-r--r--Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.yaml50
-rw-r--r--Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml40
-rw-r--r--Documentation/devicetree/bindings/timer/brcm,kona-timer.txt25
-rw-r--r--Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml52
-rw-r--r--Documentation/devicetree/bindings/timer/cdns,ttc.yaml26
-rw-r--r--Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt29
-rw-r--r--Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.yaml45
-rw-r--r--Documentation/devicetree/bindings/timer/cirrus,ep9301-timer.yaml49
-rw-r--r--Documentation/devicetree/bindings/timer/cnxt,cx92755-timer.yaml49
-rw-r--r--Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt42
-rw-r--r--Documentation/devicetree/bindings/timer/csky,gx6605s-timer.yaml40
-rw-r--r--Documentation/devicetree/bindings/timer/csky,mptimer.txt42
-rw-r--r--Documentation/devicetree/bindings/timer/csky,mptimer.yaml46
-rw-r--r--Documentation/devicetree/bindings/timer/digicolor-timer.txt18
-rw-r--r--Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml80
-rw-r--r--Documentation/devicetree/bindings/timer/ezchip,nps400-timer.yaml45
-rw-r--r--Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt17
-rw-r--r--Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt15
-rw-r--r--Documentation/devicetree/bindings/timer/faraday,fttmr010.txt38
-rw-r--r--Documentation/devicetree/bindings/timer/faraday,fttmr010.yaml89
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt31
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,ftm-timer.yaml62
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,gtm.txt30
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,gtm.yaml83
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml36
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,timrot.yaml48
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml59
-rw-r--r--Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt28
-rw-r--r--Documentation/devicetree/bindings/timer/img,pistachio-gptimer.yaml69
-rw-r--r--Documentation/devicetree/bindings/timer/ingenic,sysost.yaml2
-rw-r--r--Documentation/devicetree/bindings/timer/ingenic,tcu.yaml8
-rw-r--r--Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml4
-rw-r--r--Documentation/devicetree/bindings/timer/jcore,pit.txt24
-rw-r--r--Documentation/devicetree/bindings/timer/jcore,pit.yaml43
-rw-r--r--Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml48
-rw-r--r--Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt33
-rw-r--r--Documentation/devicetree/bindings/timer/lsi,zevio-timer.yaml56
-rw-r--r--Documentation/devicetree/bindings/timer/marvell,armada-370-timer.yaml88
-rw-r--r--Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt44
-rw-r--r--Documentation/devicetree/bindings/timer/marvell,orion-timer.txt16
-rw-r--r--Documentation/devicetree/bindings/timer/marvell,orion-timer.yaml43
-rw-r--r--Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt46
-rw-r--r--Documentation/devicetree/bindings/timer/mediatek,timer.yaml87
-rw-r--r--Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml4
-rw-r--r--Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml2
-rw-r--r--Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml8
-rw-r--r--Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml5
-rw-r--r--Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml5
-rw-r--r--Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt26
-rw-r--r--Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.yaml55
-rw-r--r--Documentation/devicetree/bindings/timer/nxp,s32g2-stm.yaml64
-rw-r--r--Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml13
-rw-r--r--Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt17
-rw-r--r--Documentation/devicetree/bindings/timer/qcom,msm-timer.txt47
-rw-r--r--Documentation/devicetree/bindings/timer/ralink,cevt-systick.yaml38
-rw-r--r--Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml44
-rw-r--r--Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml63
-rw-r--r--Documentation/devicetree/bindings/timer/realtek,rtd1625-systimer.yaml47
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,cmt.yaml48
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,em-sti.yaml10
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,mtu2.yaml14
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,ostm.yaml24
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml306
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,tmu.yaml50
-rw-r--r--Documentation/devicetree/bindings/timer/renesas,tpu.yaml56
-rw-r--r--Documentation/devicetree/bindings/timer/riscv,timer.yaml52
-rw-r--r--Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml7
-rw-r--r--Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml36
-rw-r--r--Documentation/devicetree/bindings/timer/sifive,clint.yaml70
-rw-r--r--Documentation/devicetree/bindings/timer/snps,arc-timer.txt27
-rw-r--r--Documentation/devicetree/bindings/timer/snps,arc-timer.yaml45
-rw-r--r--Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt14
-rw-r--r--Documentation/devicetree/bindings/timer/snps,archs-gfrc.yaml30
-rw-r--r--Documentation/devicetree/bindings/timer/snps,archs-rtc.txt14
-rw-r--r--Documentation/devicetree/bindings/timer/snps,archs-rtc.yaml30
-rw-r--r--Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt17
-rw-r--r--Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.yaml40
-rw-r--r--Documentation/devicetree/bindings/timer/sprd,sc9860-timer.yaml68
-rw-r--r--Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt20
-rw-r--r--Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml4
-rw-r--r--Documentation/devicetree/bindings/timer/st,spear-timer.txt16
-rw-r--r--Documentation/devicetree/bindings/timer/st,spear-timer.yaml36
-rw-r--r--Documentation/devicetree/bindings/timer/st,stm32-timer.yaml2
-rw-r--r--Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer.yaml56
-rw-r--r--Documentation/devicetree/bindings/timer/ti,da830-timer.yaml68
-rw-r--r--Documentation/devicetree/bindings/timer/ti,davinci-timer.txt37
-rw-r--r--Documentation/devicetree/bindings/timer/ti,keystone-timer.txt29
-rw-r--r--Documentation/devicetree/bindings/timer/ti,keystone-timer.yaml63
-rw-r--r--Documentation/devicetree/bindings/timer/ti,timer-dm.yaml17
-rw-r--r--Documentation/devicetree/bindings/timer/via,vt8500-timer.txt15
-rw-r--r--Documentation/devicetree/bindings/timer/via,vt8500-timer.yaml51
-rw-r--r--Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml2
-rw-r--r--Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml2
-rw-r--r--Documentation/devicetree/bindings/timestamp/hte-consumer.yaml2
-rw-r--r--Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml66
-rw-r--r--Documentation/devicetree/bindings/tpm/google,cr50.yaml65
-rw-r--r--Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml104
-rw-r--r--Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml47
-rw-r--r--Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml91
-rw-r--r--Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml49
-rw-r--r--Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml76
-rw-r--r--Documentation/devicetree/bindings/tpm/tpm-common.yaml87
-rw-r--r--Documentation/devicetree/bindings/trigger-source/adi,util-sigma-delta-spi.yaml49
-rw-r--r--Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml40
-rw-r--r--Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml37
-rw-r--r--Documentation/devicetree/bindings/trivial-devices.yaml283
-rw-r--r--Documentation/devicetree/bindings/ufs/amd,versal2-ufs.yaml61
-rw-r--r--Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml2
-rw-r--r--Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml49
-rw-r--r--Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml167
-rw-r--r--Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml180
-rw-r--r--Documentation/devicetree/bindings/ufs/qcom,ufs-common.yaml67
-rw-r--r--Documentation/devicetree/bindings/ufs/qcom,ufs.yaml186
-rw-r--r--Documentation/devicetree/bindings/ufs/renesas,ufs.yaml28
-rw-r--r--Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml105
-rw-r--r--Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml82
-rw-r--r--Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml79
-rw-r--r--Documentation/devicetree/bindings/ufs/ufs-common.yaml55
-rw-r--r--Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml14
-rw-r--r--Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml5
-rw-r--r--Documentation/devicetree/bindings/usb/analogix,anx7411.yaml13
-rw-r--r--Documentation/devicetree/bindings/usb/apple,dwc3.yaml80
-rw-r--r--Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml46
-rw-r--r--Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt11
-rw-r--r--Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml4
-rw-r--r--Documentation/devicetree/bindings/usb/brcm,bdc.yaml14
-rw-r--r--Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml2
-rw-r--r--Documentation/devicetree/bindings/usb/cdns,usb3.yaml19
-rw-r--r--Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml203
-rw-r--r--Documentation/devicetree/bindings/usb/chipidea,usb2-imx.yaml309
-rw-r--r--Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt158
-rw-r--r--Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml121
-rw-r--r--Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml93
-rw-r--r--Documentation/devicetree/bindings/usb/cypress,hx3.yaml89
-rw-r--r--Documentation/devicetree/bindings/usb/dwc2.yaml23
-rw-r--r--Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml29
-rw-r--r--Documentation/devicetree/bindings/usb/ehci-omap.txt31
-rw-r--r--Documentation/devicetree/bindings/usb/ehci-orion.txt22
-rw-r--r--Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml94
-rw-r--r--Documentation/devicetree/bindings/usb/faraday,fotg210.txt35
-rw-r--r--Documentation/devicetree/bindings/usb/faraday,fotg210.yaml78
-rw-r--r--Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml82
-rw-r--r--Documentation/devicetree/bindings/usb/fcs,fusb302.txt34
-rw-r--r--Documentation/devicetree/bindings/usb/fcs,fusb302.yaml67
-rw-r--r--Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml24
-rw-r--r--Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml48
-rw-r--r--Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml103
-rw-r--r--Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml55
-rw-r--r--Documentation/devicetree/bindings/usb/fsl,usb2.yaml95
-rw-r--r--Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml93
-rw-r--r--Documentation/devicetree/bindings/usb/fsl-usb.txt81
-rw-r--r--Documentation/devicetree/bindings/usb/generic-ehci.yaml18
-rw-r--r--Documentation/devicetree/bindings/usb/generic-ohci.yaml57
-rw-r--r--Documentation/devicetree/bindings/usb/generic-xhci.yaml44
-rw-r--r--Documentation/devicetree/bindings/usb/genesys,gl850g.yaml113
-rw-r--r--Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml116
-rw-r--r--Documentation/devicetree/bindings/usb/hisilicon,hi3798mv200-dwc3.yaml99
-rw-r--r--Documentation/devicetree/bindings/usb/ingenic,musb.yaml2
-rw-r--r--Documentation/devicetree/bindings/usb/intel,ixp4xx-udc.yaml39
-rw-r--r--Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml32
-rw-r--r--Documentation/devicetree/bindings/usb/isp1301.txt24
-rw-r--r--Documentation/devicetree/bindings/usb/ite,it5205.yaml72
-rw-r--r--Documentation/devicetree/bindings/usb/lpc32xx-udc.txt28
-rw-r--r--Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml2
-rw-r--r--Documentation/devicetree/bindings/usb/maxim,max33359.yaml18
-rw-r--r--Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml28
-rw-r--r--Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml8
-rw-r--r--Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml36
-rw-r--r--Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml36
-rw-r--r--Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml35
-rw-r--r--Documentation/devicetree/bindings/usb/mediatek,musb.yaml6
-rw-r--r--Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml16
-rw-r--r--Documentation/devicetree/bindings/usb/microchip,usb2514.yaml90
-rw-r--r--Documentation/devicetree/bindings/usb/microchip,usb5744.yaml110
-rw-r--r--Documentation/devicetree/bindings/usb/msm-hsusb.txt110
-rw-r--r--Documentation/devicetree/bindings/usb/npcm7xx-usb.txt18
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml28
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt132
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml200
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml171
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml175
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt23
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml195
-rw-r--r--Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml186
-rw-r--r--Documentation/devicetree/bindings/usb/nxp,isp1760.yaml2
-rw-r--r--Documentation/devicetree/bindings/usb/nxp,lpc3220-udc.yaml50
-rw-r--r--Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml93
-rw-r--r--Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml74
-rw-r--r--Documentation/devicetree/bindings/usb/ohci-nxp.txt24
-rw-r--r--Documentation/devicetree/bindings/usb/ohci-omap3.txt15
-rw-r--r--Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml139
-rw-r--r--Documentation/devicetree/bindings/usb/parade,ps5511.yaml108
-rw-r--r--Documentation/devicetree/bindings/usb/parade,ps8830.yaml144
-rw-r--r--Documentation/devicetree/bindings/usb/pxa-usb.txt2
-rw-r--r--Documentation/devicetree/bindings/usb/qcom,dwc3.yaml275
-rw-r--r--Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml248
-rw-r--r--Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml660
-rw-r--r--Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml101
-rw-r--r--Documentation/devicetree/bindings/usb/realtek,rtd-dwc3.yaml80
-rw-r--r--Documentation/devicetree/bindings/usb/realtek,rtd-type-c.yaml82
-rw-r--r--Documentation/devicetree/bindings/usb/realtek,rts5411.yaml52
-rw-r--r--Documentation/devicetree/bindings/usb/renesas,rzg3e-xhci.yaml95
-rw-r--r--Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml68
-rw-r--r--Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml129
-rw-r--r--Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml41
-rw-r--r--Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml87
-rw-r--r--Documentation/devicetree/bindings/usb/renesas,usbhs.yaml48
-rw-r--r--Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml103
-rw-r--r--Documentation/devicetree/bindings/usb/richtek,rt1719.yaml10
-rw-r--r--Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml97
-rw-r--r--Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml115
-rw-r--r--Documentation/devicetree/bindings/usb/s3c2410-usb.txt22
-rw-r--r--Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml122
-rw-r--r--Documentation/devicetree/bindings/usb/samsung-hsotg.txt38
-rw-r--r--Documentation/devicetree/bindings/usb/smsc,usb3503.yaml112
-rw-r--r--Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml432
-rw-r--r--Documentation/devicetree/bindings/usb/snps,dwc3.yaml295
-rw-r--r--Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml121
-rw-r--r--Documentation/devicetree/bindings/usb/spear-usb.txt35
-rw-r--r--Documentation/devicetree/bindings/usb/st,stusb160x.yaml20
-rw-r--r--Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml115
-rw-r--r--Documentation/devicetree/bindings/usb/ti,am62-usb.yaml10
-rw-r--r--Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml51
-rw-r--r--Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml15
-rw-r--r--Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml8
-rw-r--r--Documentation/devicetree/bindings/usb/ti,tps6598x.yaml103
-rw-r--r--Documentation/devicetree/bindings/usb/ti,tusb1046.yaml50
-rw-r--r--Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml55
-rw-r--r--Documentation/devicetree/bindings/usb/ti,twl4030-usb.yaml74
-rw-r--r--Documentation/devicetree/bindings/usb/ti,twl6030-usb.yaml48
-rw-r--r--Documentation/devicetree/bindings/usb/ti,usb8020b.yaml69
-rw-r--r--Documentation/devicetree/bindings/usb/ti,usb8041.yaml22
-rw-r--r--Documentation/devicetree/bindings/usb/twlxxxx-usb.txt43
-rw-r--r--Documentation/devicetree/bindings/usb/typec-tcpci.txt49
-rw-r--r--Documentation/devicetree/bindings/usb/usb-device.yaml12
-rw-r--r--Documentation/devicetree/bindings/usb/usb-drd.yaml3
-rw-r--r--Documentation/devicetree/bindings/usb/usb-hcd.yaml4
-rw-r--r--Documentation/devicetree/bindings/usb/usb-hub.yaml84
-rw-r--r--Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml19
-rw-r--r--Documentation/devicetree/bindings/usb/usb-switch-ports.yaml68
-rw-r--r--Documentation/devicetree/bindings/usb/usb-switch.yaml28
-rw-r--r--Documentation/devicetree/bindings/usb/usb-uhci.txt18
-rw-r--r--Documentation/devicetree/bindings/usb/usb-uhci.yaml88
-rw-r--r--Documentation/devicetree/bindings/usb/usb-xhci.yaml10
-rw-r--r--Documentation/devicetree/bindings/usb/usb.yaml4
-rw-r--r--Documentation/devicetree/bindings/usb/usb251xb.txt89
-rw-r--r--Documentation/devicetree/bindings/usb/usb251xb.yaml278
-rw-r--r--Documentation/devicetree/bindings/usb/usbmisc-imx.txt18
-rw-r--r--Documentation/devicetree/bindings/usb/vialab,vl817.yaml70
-rw-r--r--Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml3
-rw-r--r--Documentation/devicetree/bindings/usb/xlnx,usb2.yaml2
-rw-r--r--Documentation/devicetree/bindings/vendor-prefixes.yaml467
-rw-r--r--Documentation/devicetree/bindings/virtio/iommu.txt66
-rw-r--r--Documentation/devicetree/bindings/virtio/pci-iommu.yaml99
-rw-r--r--Documentation/devicetree/bindings/virtio/virtio-device.yaml2
-rw-r--r--Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml44
-rw-r--r--Documentation/devicetree/bindings/w1/fsl-imx-owire.yaml4
-rw-r--r--Documentation/devicetree/bindings/w1/maxim,ds2482.yaml46
-rw-r--r--Documentation/devicetree/bindings/w1/w1-gpio.yaml2
-rw-r--r--Documentation/devicetree/bindings/w1/w1-uart.yaml59
-rw-r--r--Documentation/devicetree/bindings/watchdog/airoha,en7581-wdt.yaml51
-rw-r--r--Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml10
-rw-r--r--Documentation/devicetree/bindings/watchdog/alphascale,asm9260-wdt.yaml70
-rw-r--r--Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt35
-rw-r--r--Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml22
-rw-r--r--Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml50
-rw-r--r--Documentation/devicetree/bindings/watchdog/apple,wdt.yaml27
-rw-r--r--Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml1
-rw-r--r--Documentation/devicetree/bindings/watchdog/arm,sp805.yaml6
-rw-r--r--Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml6
-rw-r--r--Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml13
-rw-r--r--Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt23
-rw-r--r--Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml146
-rw-r--r--Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt57
-rw-r--r--Documentation/devicetree/bindings/watchdog/atmel,at91rm9200-wdt.yaml33
-rw-r--r--Documentation/devicetree/bindings/watchdog/atmel,at91sam9-wdt.yaml127
-rw-r--r--Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml28
-rw-r--r--Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt9
-rw-r--r--Documentation/devicetree/bindings/watchdog/atmel-wdt.txt51
-rw-r--r--Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt18
-rw-r--r--Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml16
-rw-r--r--Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt15
-rw-r--r--Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml41
-rw-r--r--Documentation/devicetree/bindings/watchdog/cadence-wdt.txt23
-rw-r--r--Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml62
-rw-r--r--Documentation/devicetree/bindings/watchdog/cirrus,ep9301-wdt.yaml42
-rw-r--r--Documentation/devicetree/bindings/watchdog/cnxt,cx92755-wdt.yaml45
-rw-r--r--Documentation/devicetree/bindings/watchdog/da9062-wdt.txt34
-rw-r--r--Documentation/devicetree/bindings/watchdog/davinci-wdt.txt24
-rw-r--r--Documentation/devicetree/bindings/watchdog/digicolor-wdt.txt25
-rw-r--r--Documentation/devicetree/bindings/watchdog/dlg,da9062-watchdog.yaml54
-rw-r--r--Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml18
-rw-r--r--Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml7
-rw-r--r--Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml59
-rw-r--r--Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml17
-rw-r--r--Documentation/devicetree/bindings/watchdog/gpio-wdt.txt28
-rw-r--r--Documentation/devicetree/bindings/watchdog/img,pdc-wdt.yaml55
-rw-r--r--Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt19
-rw-r--r--Documentation/devicetree/bindings/watchdog/intel,keembay-wdt.yaml5
-rw-r--r--Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml9
-rw-r--r--Documentation/devicetree/bindings/watchdog/lantiq,wdt.yaml57
-rw-r--r--Documentation/devicetree/bindings/watchdog/lantiq-wdt.txt24
-rw-r--r--Documentation/devicetree/bindings/watchdog/linux,wdt-gpio.yaml68
-rw-r--r--Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml43
-rw-r--r--Documentation/devicetree/bindings/watchdog/lpc18xx-wdt.txt19
-rw-r--r--Documentation/devicetree/bindings/watchdog/marvel.txt45
-rw-r--r--Documentation/devicetree/bindings/watchdog/marvell,armada-3700-wdt.yaml41
-rw-r--r--Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml83
-rw-r--r--Documentation/devicetree/bindings/watchdog/marvell,orion-wdt.yaml100
-rw-r--r--Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml7
-rw-r--r--Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml40
-rw-r--r--Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml92
-rw-r--r--Documentation/devicetree/bindings/watchdog/meson-wdt.txt21
-rw-r--r--Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt15
-rw-r--r--Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml2
-rw-r--r--Documentation/devicetree/bindings/watchdog/mt7621-wdt.txt12
-rw-r--r--Documentation/devicetree/bindings/watchdog/mtk-wdt.txt42
-rw-r--r--Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt30
-rw-r--r--Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml60
-rw-r--r--Documentation/devicetree/bindings/watchdog/nxp,lpc1850-wwdt.yaml52
-rw-r--r--Documentation/devicetree/bindings/watchdog/nxp,pnx4008-wdt.yaml37
-rw-r--r--Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml54
-rw-r--r--Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt26
-rw-r--r--Documentation/devicetree/bindings/watchdog/omap-wdt.txt15
-rw-r--r--Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt17
-rw-r--r--Documentation/devicetree/bindings/watchdog/qca,ar7130-wdt.yaml33
-rw-r--r--Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt13
-rw-r--r--Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml35
-rw-r--r--Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml114
-rw-r--r--Documentation/devicetree/bindings/watchdog/ralink,rt2880-wdt.yaml46
-rw-r--r--Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml4
-rw-r--r--Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt17
-rw-r--r--Documentation/devicetree/bindings/watchdog/realtek,rtd1295-watchdog.yaml38
-rw-r--r--Documentation/devicetree/bindings/watchdog/renesas,r9a09g057-wdt.yaml99
-rw-r--r--Documentation/devicetree/bindings/watchdog/renesas,rcar-gen3-wwdt.yaml114
-rw-r--r--Documentation/devicetree/bindings/watchdog/renesas,rza-wdt.yaml51
-rw-r--r--Documentation/devicetree/bindings/watchdog/renesas,rzg2l-wdt.yaml111
-rw-r--r--Documentation/devicetree/bindings/watchdog/renesas,rzn1-wdt.yaml50
-rw-r--r--Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml85
-rw-r--r--Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt18
-rw-r--r--Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml38
-rw-r--r--Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml48
-rw-r--r--Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml12
-rw-r--r--Documentation/devicetree/bindings/watchdog/sprd,sp9860-wdt.yaml64
-rw-r--r--Documentation/devicetree/bindings/watchdog/sprd-wdt.txt19
-rw-r--r--Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml20
-rw-r--r--Documentation/devicetree/bindings/watchdog/starfive,jh7100-wdt.yaml93
-rw-r--r--Documentation/devicetree/bindings/watchdog/technologic,ts7200-wdt.yaml45
-rw-r--r--Documentation/devicetree/bindings/watchdog/ti,davinci-wdt.yaml55
-rw-r--r--Documentation/devicetree/bindings/watchdog/ti,omap2-wdt.yaml51
-rw-r--r--Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml30
-rw-r--r--Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml20
-rw-r--r--Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt10
-rw-r--r--Documentation/devicetree/bindings/watchdog/watchdog.yaml10
-rw-r--r--Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml50
-rw-r--r--Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml68
-rw-r--r--Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt39
-rw-r--r--Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.yaml47
-rw-r--r--Documentation/devicetree/bindings/watchdog/zii,rave-wdt.yaml49
-rw-r--r--Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt19
-rw-r--r--Documentation/devicetree/bindings/writing-bindings.rst51
-rw-r--r--Documentation/devicetree/bindings/writing-schema.rst81
-rw-r--r--Documentation/devicetree/bindings/xilinx.txt26
-rw-r--r--Documentation/devicetree/of_unittest.rst14
-rw-r--r--Documentation/devicetree/overlay-notes.rst18
-rw-r--r--Documentation/devicetree/usage-model.rst8
-rw-r--r--Documentation/doc-guide/checktransupdate.rst54
-rw-r--r--Documentation/doc-guide/contributing.rst6
-rw-r--r--Documentation/doc-guide/index.rst1
-rw-r--r--Documentation/doc-guide/kernel-doc.rst93
-rw-r--r--Documentation/doc-guide/maintainer-profile.rst7
-rw-r--r--Documentation/doc-guide/parse-headers.rst189
-rw-r--r--Documentation/doc-guide/sphinx.rst93
-rw-r--r--Documentation/dontdiff271
-rw-r--r--Documentation/driver-api/80211/mac80211.rst2
-rw-r--r--Documentation/driver-api/auxiliary_bus.rst1
-rw-r--r--Documentation/driver-api/basics.rst41
-rw-r--r--Documentation/driver-api/clk.rst5
-rw-r--r--Documentation/driver-api/coco/index.rst12
-rw-r--r--Documentation/driver-api/coco/measurement-registers.rst12
-rw-r--r--Documentation/driver-api/crypto/iaa/iaa-crypto.rst849
-rw-r--r--Documentation/driver-api/crypto/iaa/index.rst20
-rw-r--r--Documentation/driver-api/crypto/index.rst20
-rw-r--r--Documentation/driver-api/cxl/allocation/dax.rst60
-rw-r--r--Documentation/driver-api/cxl/allocation/hugepages.rst32
-rw-r--r--Documentation/driver-api/cxl/allocation/page-allocator.rst54
-rw-r--r--Documentation/driver-api/cxl/allocation/reclaim.rst51
-rw-r--r--Documentation/driver-api/cxl/conventions.rst182
-rw-r--r--Documentation/driver-api/cxl/devices/device-types.rst165
-rw-r--r--Documentation/driver-api/cxl/index.rst46
-rw-r--r--Documentation/driver-api/cxl/linux/access-coordinates.rst178
-rw-r--r--Documentation/driver-api/cxl/linux/cxl-driver.rst630
-rw-r--r--Documentation/driver-api/cxl/linux/dax-driver.rst43
-rw-r--r--Documentation/driver-api/cxl/linux/early-boot.rst137
-rw-r--r--Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst314
-rw-r--r--Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst291
-rw-r--r--Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst401
-rw-r--r--Documentation/driver-api/cxl/linux/example-configurations/single-device.rst246
-rw-r--r--Documentation/driver-api/cxl/linux/memory-hotplug.rst78
-rw-r--r--Documentation/driver-api/cxl/linux/overview.rst103
-rw-r--r--Documentation/driver-api/cxl/maturity-map.rst202
-rw-r--r--Documentation/driver-api/cxl/memory-devices.rst383
-rw-r--r--Documentation/driver-api/cxl/platform/acpi.rst76
-rw-r--r--Documentation/driver-api/cxl/platform/acpi/cedt.rst62
-rw-r--r--Documentation/driver-api/cxl/platform/acpi/dsdt.rst28
-rw-r--r--Documentation/driver-api/cxl/platform/acpi/hmat.rst32
-rw-r--r--Documentation/driver-api/cxl/platform/acpi/slit.rst21
-rw-r--r--Documentation/driver-api/cxl/platform/acpi/srat.rst71
-rw-r--r--Documentation/driver-api/cxl/platform/bios-and-efi.rst262
-rw-r--r--Documentation/driver-api/cxl/platform/cdat.rst118
-rw-r--r--Documentation/driver-api/cxl/platform/example-configs.rst13
-rw-r--r--Documentation/driver-api/cxl/platform/example-configurations/flexible.rst296
-rw-r--r--Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst107
-rw-r--r--Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst90
-rw-r--r--Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst136
-rw-r--r--Documentation/driver-api/cxl/theory-of-operation.rst415
-rw-r--r--Documentation/driver-api/device-io.rst16
-rw-r--r--Documentation/driver-api/dma-buf.rst60
-rw-r--r--Documentation/driver-api/dmaengine/client.rst11
-rw-r--r--Documentation/driver-api/dmaengine/dmatest.rst2
-rw-r--r--Documentation/driver-api/dmaengine/provider.rst22
-rw-r--r--Documentation/driver-api/dpll.rst635
-rw-r--r--Documentation/driver-api/driver-model/bus.rst4
-rw-r--r--Documentation/driver-api/driver-model/devres.rst43
-rw-r--r--Documentation/driver-api/driver-model/overview.rst2
-rw-r--r--Documentation/driver-api/driver-model/platform.rst9
-rw-r--r--Documentation/driver-api/early-userspace/buffer-format.rst39
-rw-r--r--Documentation/driver-api/edac.rst120
-rw-r--r--Documentation/driver-api/eisa.rst12
-rw-r--r--Documentation/driver-api/extcon.rst255
-rw-r--r--Documentation/driver-api/firewire.rst2
-rw-r--r--Documentation/driver-api/firmware/efi/index.rst11
-rw-r--r--Documentation/driver-api/firmware/firmware-usage-guidelines.rst5
-rw-r--r--Documentation/driver-api/firmware/fw_search_path.rst9
-rw-r--r--Documentation/driver-api/firmware/fw_upload.rst3
-rw-r--r--Documentation/driver-api/fpga/fpga-bridge.rst7
-rw-r--r--Documentation/driver-api/fpga/fpga-mgr.rst34
-rw-r--r--Documentation/driver-api/fpga/fpga-region.rst13
-rw-r--r--Documentation/driver-api/generic-counter.rst4
-rw-r--r--Documentation/driver-api/generic_pt.rst137
-rw-r--r--Documentation/driver-api/gpio/board.rst71
-rw-r--r--Documentation/driver-api/gpio/consumer.rst18
-rw-r--r--Documentation/driver-api/gpio/driver.rst43
-rw-r--r--Documentation/driver-api/gpio/drivers-on-gpio.rst7
-rw-r--r--Documentation/driver-api/gpio/index.rst5
-rw-r--r--Documentation/driver-api/gpio/intro.rst12
-rw-r--r--Documentation/driver-api/gpio/legacy-boards.rst298
-rw-r--r--Documentation/driver-api/gpio/legacy.rst769
-rw-r--r--Documentation/driver-api/gpio/pca953x.rst552
-rw-r--r--Documentation/driver-api/hsi.rst4
-rw-r--r--Documentation/driver-api/hte/index.rst2
-rw-r--r--Documentation/driver-api/hte/tegra-hte.rst47
-rw-r--r--Documentation/driver-api/hte/tegra194-hte.rst48
-rw-r--r--Documentation/driver-api/hw-recoverable-errors.rst60
-rw-r--r--Documentation/driver-api/i3c/protocol.rst8
-rw-r--r--Documentation/driver-api/iio/buffers.rst8
-rw-r--r--Documentation/driver-api/iio/core.rst16
-rw-r--r--Documentation/driver-api/index.rst177
-rw-r--r--Documentation/driver-api/infiniband.rst16
-rw-r--r--Documentation/driver-api/infrastructure.rst24
-rw-r--r--Documentation/driver-api/input.rst7
-rw-r--r--Documentation/driver-api/interconnect.rst25
-rw-r--r--Documentation/driver-api/io-mapping.rst4
-rw-r--r--Documentation/driver-api/ipmi.rst35
-rw-r--r--Documentation/driver-api/isapnp.rst15
-rw-r--r--Documentation/driver-api/libata.rst63
-rw-r--r--Documentation/driver-api/md/md-cluster.rst2
-rw-r--r--Documentation/driver-api/md/raid5-cache.rst2
-rw-r--r--Documentation/driver-api/media/camera-sensor.rst205
-rw-r--r--Documentation/driver-api/media/cec-core.rst44
-rw-r--r--Documentation/driver-api/media/drivers/ccs/ccs.rst83
-rwxr-xr-xDocumentation/driver-api/media/drivers/ccs/mk-ccs-regs104
-rw-r--r--Documentation/driver-api/media/drivers/cpia2_devel.rst56
-rw-r--r--Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst39
-rw-r--r--Documentation/driver-api/media/drivers/index.rst3
-rw-r--r--Documentation/driver-api/media/drivers/ipu6.rst190
-rw-r--r--Documentation/driver-api/media/drivers/vidtv.rst2
-rw-r--r--Documentation/driver-api/media/drivers/zoran.rst2
-rw-r--r--Documentation/driver-api/media/dtv-common.rst9
-rw-r--r--Documentation/driver-api/media/dtv-demux.rst2
-rw-r--r--Documentation/driver-api/media/index.rst7
-rw-r--r--Documentation/driver-api/media/maintainer-entry-profile.rst6
-rw-r--r--Documentation/driver-api/media/mc-core.rst92
-rw-r--r--Documentation/driver-api/media/tx-rx.rst73
-rw-r--r--Documentation/driver-api/media/v4l2-cci.rst5
-rw-r--r--Documentation/driver-api/media/v4l2-controls.rst9
-rw-r--r--Documentation/driver-api/media/v4l2-core.rst4
-rw-r--r--Documentation/driver-api/media/v4l2-dev.rst8
-rw-r--r--Documentation/driver-api/media/v4l2-fh.rst59
-rw-r--r--Documentation/driver-api/media/v4l2-isp.rst49
-rw-r--r--Documentation/driver-api/media/v4l2-jpeg.rst10
-rw-r--r--Documentation/driver-api/media/v4l2-subdev.rst133
-rw-r--r--Documentation/driver-api/media/v4l2-videobuf.rst403
-rw-r--r--Documentation/driver-api/mei/index.rst7
-rw-r--r--Documentation/driver-api/mei/nfc.rst2
-rw-r--r--Documentation/driver-api/miscellaneous.rst5
-rw-r--r--Documentation/driver-api/mmc/index.rst1
-rw-r--r--Documentation/driver-api/mmc/mmc-test.rst299
-rw-r--r--Documentation/driver-api/mtd/nand_ecc.rst2
-rw-r--r--Documentation/driver-api/mtd/spi-nor.rst265
-rw-r--r--Documentation/driver-api/nfc/nfc-hci.rst2
-rw-r--r--Documentation/driver-api/ntb.rst6
-rw-r--r--Documentation/driver-api/nvdimm/btt.rst2
-rw-r--r--Documentation/driver-api/nvdimm/nvdimm.rst10
-rw-r--r--Documentation/driver-api/nvdimm/security.rst2
-rw-r--r--Documentation/driver-api/nvmem.rst37
-rw-r--r--Documentation/driver-api/parport-lowlevel.rst5
-rw-r--r--Documentation/driver-api/pci/index.rst6
-rw-r--r--Documentation/driver-api/pci/p2pdma.rst113
-rw-r--r--Documentation/driver-api/pci/pci.rst12
-rw-r--r--Documentation/driver-api/pci/tsm.rst21
-rw-r--r--Documentation/driver-api/phy/phy.rst52
-rw-r--r--Documentation/driver-api/pin-control.rst581
-rw-r--r--Documentation/driver-api/pldmfw/index.rst3
-rw-r--r--Documentation/driver-api/pm/devices.rst6
-rw-r--r--Documentation/driver-api/pps.rst79
-rw-r--r--Documentation/driver-api/ptp.rst29
-rw-r--r--Documentation/driver-api/pwm.rst58
-rw-r--r--Documentation/driver-api/pwrseq.rst95
-rw-r--r--Documentation/driver-api/reset.rst1
-rw-r--r--Documentation/driver-api/s390-drivers.rst4
-rw-r--r--Documentation/driver-api/scsi.rst26
-rw-r--r--Documentation/driver-api/serial/driver.rst14
-rw-r--r--Documentation/driver-api/serial/serial-rs485.rst56
-rw-r--r--Documentation/driver-api/soundwire/bra.rst336
-rw-r--r--Documentation/driver-api/soundwire/bra_cadence.rst66
-rw-r--r--Documentation/driver-api/soundwire/index.rst2
-rw-r--r--Documentation/driver-api/soundwire/stream.rst6
-rw-r--r--Documentation/driver-api/soundwire/summary.rst8
-rw-r--r--Documentation/driver-api/spi.rst6
-rw-r--r--Documentation/driver-api/surface_aggregator/client.rst12
-rw-r--r--Documentation/driver-api/surface_aggregator/ssh.rst40
-rw-r--r--Documentation/driver-api/tee.rst66
-rw-r--r--Documentation/driver-api/thermal/exynos_thermal_emulation.rst14
-rw-r--r--Documentation/driver-api/thermal/index.rst1
-rw-r--r--Documentation/driver-api/thermal/intel_dptf.rst166
-rw-r--r--Documentation/driver-api/thermal/sysfs-api.rst198
-rw-r--r--Documentation/driver-api/tty/console.rst45
-rw-r--r--Documentation/driver-api/tty/index.rst2
-rw-r--r--Documentation/driver-api/tty/n_gsm.rst39
-rw-r--r--Documentation/driver-api/tty/tty_buffer.rst7
-rw-r--r--Documentation/driver-api/tty/tty_driver.rst4
-rw-r--r--Documentation/driver-api/tty/tty_ioctl.rst10
-rw-r--r--Documentation/driver-api/tty/tty_port.rst5
-rw-r--r--Documentation/driver-api/tty/tty_struct.rst2
-rw-r--r--Documentation/driver-api/usb/anchors.rst11
-rw-r--r--Documentation/driver-api/usb/callbacks.rst6
-rw-r--r--Documentation/driver-api/usb/dma.rst48
-rw-r--r--Documentation/driver-api/usb/dwc3.rst2
-rw-r--r--Documentation/driver-api/usb/hotplug.rst2
-rw-r--r--Documentation/driver-api/usb/index.rst1
-rw-r--r--Documentation/driver-api/usb/usb.rst14
-rw-r--r--Documentation/driver-api/usb/usb3-debug-port.rst2
-rw-r--r--Documentation/driver-api/usb/writing_musb_glue_layer.rst6
-rw-r--r--Documentation/driver-api/vfio-mediated-device.rst132
-rw-r--r--Documentation/driver-api/vfio.rst225
-rw-r--r--Documentation/driver-api/virtio/index.rst11
-rw-r--r--Documentation/driver-api/virtio/virtio.rst145
-rw-r--r--Documentation/driver-api/virtio/writing_virtio_drivers.rst196
-rw-r--r--Documentation/driver-api/wbrf.rst78
-rw-r--r--Documentation/driver-api/wmi.rst20
-rw-r--r--Documentation/edac/features.rst103
-rw-r--r--Documentation/edac/index.rst12
-rw-r--r--Documentation/edac/memory_repair.rst152
-rw-r--r--Documentation/edac/scrub.rst342
-rw-r--r--Documentation/fault-injection/fault-injection.rst145
-rw-r--r--Documentation/fault-injection/index.rst2
-rw-r--r--Documentation/fault-injection/notifier-error-inject.rst4
-rw-r--r--Documentation/fault-injection/provoke-crashes.rst2
-rw-r--r--Documentation/fb/aty128fb.rst8
-rw-r--r--Documentation/fb/deferred_io.rst2
-rw-r--r--Documentation/fb/efifb.rst6
-rw-r--r--Documentation/fb/ep93xx-fb.rst4
-rw-r--r--Documentation/fb/fbcon.rst42
-rw-r--r--Documentation/fb/gxfb.rst8
-rw-r--r--Documentation/fb/index.rst81
-rw-r--r--Documentation/fb/intelfb.rst155
-rw-r--r--Documentation/fb/lxfb.rst9
-rw-r--r--Documentation/fb/matroxfb.rst9
-rw-r--r--Documentation/fb/modedb.rst10
-rw-r--r--Documentation/fb/pvr2fb.rst6
-rw-r--r--Documentation/fb/sa1100fb.rst9
-rw-r--r--Documentation/fb/sisfb.rst6
-rw-r--r--Documentation/fb/sm712fb.rst8
-rw-r--r--Documentation/fb/sstfb.rst4
-rw-r--r--Documentation/fb/tgafb.rst6
-rw-r--r--Documentation/fb/udlfb.rst6
-rw-r--r--Documentation/fb/vesafb.rst6
-rw-r--r--Documentation/features/core/cBPF-JIT/arch-support.txt3
-rw-r--r--Documentation/features/core/eBPF-JIT/arch-support.txt7
-rw-r--r--Documentation/features/core/generic-idle-thread/arch-support.txt5
-rw-r--r--Documentation/features/core/jump-labels/arch-support.txt7
-rw-r--r--Documentation/features/core/mseal_sys_mappings/arch-support.txt30
-rw-r--r--Documentation/features/core/thread-info-in-task/arch-support.txt7
-rw-r--r--Documentation/features/core/tracehook/arch-support.txt5
-rw-r--r--Documentation/features/debug/KASAN/arch-support.txt5
-rw-r--r--Documentation/features/debug/debug-vm-pgtable/arch-support.txt3
-rw-r--r--Documentation/features/debug/gcov-profile-all/arch-support.txt3
-rw-r--r--Documentation/features/debug/kcov/arch-support.txt3
-rw-r--r--Documentation/features/debug/kgdb/arch-support.txt3
-rw-r--r--Documentation/features/debug/kmemleak/arch-support.txt3
-rw-r--r--Documentation/features/debug/kprobes-on-ftrace/arch-support.txt5
-rw-r--r--Documentation/features/debug/kprobes/arch-support.txt3
-rw-r--r--Documentation/features/debug/kretprobes/arch-support.txt3
-rw-r--r--Documentation/features/debug/optprobes/arch-support.txt3
-rw-r--r--Documentation/features/debug/stackprotector/arch-support.txt3
-rw-r--r--Documentation/features/debug/uprobes/arch-support.txt3
-rw-r--r--Documentation/features/debug/user-ret-profiler/arch-support.txt3
-rw-r--r--Documentation/features/io/dma-contiguous/arch-support.txt3
-rwxr-xr-xDocumentation/features/list-arch.sh11
-rw-r--r--Documentation/features/locking/cmpxchg-local/arch-support.txt3
-rw-r--r--Documentation/features/locking/lockdep/arch-support.txt5
-rw-r--r--Documentation/features/locking/queued-rwlocks/arch-support.txt3
-rw-r--r--Documentation/features/locking/queued-spinlocks/arch-support.txt7
-rw-r--r--Documentation/features/perf/kprobes-event/arch-support.txt5
-rw-r--r--Documentation/features/perf/perf-regs/arch-support.txt3
-rw-r--r--Documentation/features/perf/perf-stackdump/arch-support.txt3
-rw-r--r--Documentation/features/sched/membarrier-sync-core/arch-support.txt25
-rw-r--r--Documentation/features/sched/numa-balancing/arch-support.txt3
-rwxr-xr-xDocumentation/features/scripts/features-refresh.sh98
-rw-r--r--Documentation/features/seccomp/seccomp-filter/arch-support.txt5
-rw-r--r--Documentation/features/time/arch-tick-broadcast/arch-support.txt3
-rw-r--r--Documentation/features/time/clockevents/arch-support.txt5
-rw-r--r--Documentation/features/time/context-tracking/arch-support.txt3
-rw-r--r--Documentation/features/time/irq-time-acct/arch-support.txt3
-rw-r--r--Documentation/features/time/virt-cpuacct/arch-support.txt3
-rw-r--r--Documentation/features/vm/ELF-ASLR/arch-support.txt6
-rw-r--r--Documentation/features/vm/PG_uncached/arch-support.txt31
-rw-r--r--Documentation/features/vm/THP/arch-support.txt3
-rw-r--r--Documentation/features/vm/TLB/arch-support.txt7
-rw-r--r--Documentation/features/vm/huge-vmap/arch-support.txt5
-rw-r--r--Documentation/features/vm/ioremap_prot/arch-support.txt3
-rw-r--r--Documentation/features/vm/pte_special/arch-support.txt3
-rw-r--r--Documentation/filesystems/9p.rst114
-rw-r--r--Documentation/filesystems/afs.rst2
-rw-r--r--Documentation/filesystems/api-summary.rst3
-rw-r--r--Documentation/filesystems/autofs-mount-control.rst2
-rw-r--r--Documentation/filesystems/autofs.rst8
-rw-r--r--Documentation/filesystems/befs.rst4
-rw-r--r--Documentation/filesystems/btrfs.rst1
-rw-r--r--Documentation/filesystems/buffer.rst12
-rw-r--r--Documentation/filesystems/caching/cachefiles.rst4
-rw-r--r--Documentation/filesystems/caching/fscache.rst8
-rw-r--r--Documentation/filesystems/caching/netfs-api.rst6
-rw-r--r--Documentation/filesystems/ceph.rst26
-rw-r--r--Documentation/filesystems/cifs/index.rst10
-rw-r--r--Documentation/filesystems/coda.rst2
-rw-r--r--Documentation/filesystems/configfs.rst50
-rw-r--r--Documentation/filesystems/dax.rst4
-rw-r--r--Documentation/filesystems/debugfs.rst39
-rw-r--r--Documentation/filesystems/devpts.rst4
-rw-r--r--Documentation/filesystems/directory-locking.rst343
-rw-r--r--Documentation/filesystems/dlmfs.rst4
-rw-r--r--Documentation/filesystems/efivarfs.rst2
-rw-r--r--Documentation/filesystems/erofs.rst87
-rw-r--r--Documentation/filesystems/ext4/atomic_writes.rst225
-rw-r--r--Documentation/filesystems/ext4/bitmaps.rst7
-rw-r--r--Documentation/filesystems/ext4/blockgroup.rst17
-rw-r--r--Documentation/filesystems/ext4/directory.rst63
-rw-r--r--Documentation/filesystems/ext4/dynamic.rst10
-rw-r--r--Documentation/filesystems/ext4/globals.rst15
-rw-r--r--Documentation/filesystems/ext4/index.rst2
-rw-r--r--Documentation/filesystems/ext4/inode_table.rst9
-rw-r--r--Documentation/filesystems/ext4/inodes.rst2
-rw-r--r--Documentation/filesystems/ext4/journal.rst7
-rw-r--r--Documentation/filesystems/ext4/overview.rst21
-rw-r--r--Documentation/filesystems/ext4/super.rst26
-rw-r--r--Documentation/filesystems/f2fs.rst260
-rw-r--r--Documentation/filesystems/fiemap.rst49
-rw-r--r--Documentation/filesystems/files.rst53
-rw-r--r--Documentation/filesystems/fscrypt.rst524
-rw-r--r--Documentation/filesystems/fsverity.rst336
-rw-r--r--Documentation/filesystems/fuse/fuse-io-uring.rst99
-rw-r--r--Documentation/filesystems/fuse/fuse-io.rst (renamed from Documentation/filesystems/fuse-io.rst)5
-rw-r--r--Documentation/filesystems/fuse/fuse-passthrough.rst133
-rw-r--r--Documentation/filesystems/fuse/fuse.rst (renamed from Documentation/filesystems/fuse.rst)20
-rw-r--r--Documentation/filesystems/fuse/index.rst14
-rw-r--r--Documentation/filesystems/gfs2-glocks.rst253
-rw-r--r--Documentation/filesystems/gfs2.rst52
-rw-r--r--Documentation/filesystems/gfs2/glocks.rst249
-rw-r--r--Documentation/filesystems/gfs2/index.rst64
-rw-r--r--Documentation/filesystems/gfs2/uevents.rst (renamed from Documentation/filesystems/gfs2-uevents.rst)0
-rw-r--r--Documentation/filesystems/hpfs.rst2
-rw-r--r--Documentation/filesystems/idmappings.rst214
-rw-r--r--Documentation/filesystems/index.rst18
-rw-r--r--Documentation/filesystems/iomap/design.rst459
-rw-r--r--Documentation/filesystems/iomap/index.rst13
-rw-r--r--Documentation/filesystems/iomap/operations.rst785
-rw-r--r--Documentation/filesystems/iomap/porting.rst120
-rw-r--r--Documentation/filesystems/journalling.rst10
-rw-r--r--Documentation/filesystems/locking.rst186
-rw-r--r--Documentation/filesystems/mount_api.rst51
-rw-r--r--Documentation/filesystems/multigrain-ts.rst125
-rw-r--r--Documentation/filesystems/netfs_library.rst1031
-rw-r--r--Documentation/filesystems/nfs/client-identifier.rst6
-rw-r--r--Documentation/filesystems/nfs/exporting.rst35
-rw-r--r--Documentation/filesystems/nfs/index.rst2
-rw-r--r--Documentation/filesystems/nfs/localio.rst357
-rw-r--r--Documentation/filesystems/nfs/nfsd-io-modes.rst153
-rw-r--r--Documentation/filesystems/nfs/nfsd-maintainer-entry-profile.rst547
-rw-r--r--Documentation/filesystems/nfs/reexport.rst10
-rw-r--r--Documentation/filesystems/nfs/rpc-cache.rst2
-rw-r--r--Documentation/filesystems/nfs/rpc-server-gss.rst2
-rw-r--r--Documentation/filesystems/nilfs2.rst2
-rw-r--r--Documentation/filesystems/ntfs.rst466
-rw-r--r--Documentation/filesystems/ntfs3.rst32
-rw-r--r--Documentation/filesystems/ocfs2-online-filecheck.rst20
-rw-r--r--Documentation/filesystems/ocfs2.rst2
-rw-r--r--Documentation/filesystems/orangefs.rst2
-rw-r--r--Documentation/filesystems/overlayfs.rst343
-rw-r--r--Documentation/filesystems/path-lookup.rst2
-rw-r--r--Documentation/filesystems/path-lookup.txt2
-rw-r--r--Documentation/filesystems/porting.rst451
-rw-r--r--Documentation/filesystems/proc.rst379
-rw-r--r--Documentation/filesystems/propagate_umount.txt484
-rw-r--r--Documentation/filesystems/qnx6.rst2
-rw-r--r--Documentation/filesystems/ramfs-rootfs-initramfs.rst17
-rw-r--r--Documentation/filesystems/relay.rst36
-rw-r--r--Documentation/filesystems/resctrl.rst1932
-rw-r--r--Documentation/filesystems/seq_file.rst4
-rw-r--r--Documentation/filesystems/sharedsubtree.rst1351
-rw-r--r--Documentation/filesystems/smb/cifsroot.rst (renamed from Documentation/filesystems/cifs/cifsroot.rst)2
-rw-r--r--Documentation/filesystems/smb/index.rst11
-rw-r--r--Documentation/filesystems/smb/ksmbd.rst (renamed from Documentation/filesystems/cifs/ksmbd.rst)35
-rw-r--r--Documentation/filesystems/smb/smbdirect.rst103
-rw-r--r--Documentation/filesystems/squashfs.rst72
-rw-r--r--Documentation/filesystems/sysfs.rst70
-rw-r--r--Documentation/filesystems/sysv-fs.rst264
-rw-r--r--Documentation/filesystems/tmpfs.rst117
-rw-r--r--Documentation/filesystems/ubifs-authentication.rst4
-rw-r--r--Documentation/filesystems/ubifs.rst2
-rw-r--r--Documentation/filesystems/vfat.rst2
-rw-r--r--Documentation/filesystems/vfs.rst353
-rw-r--r--Documentation/filesystems/xfs/index.rst14
-rw-r--r--Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (renamed from Documentation/filesystems/xfs-delayed-logging-design.rst)2
-rw-r--r--Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst194
-rw-r--r--Documentation/filesystems/xfs/xfs-online-fsck-design.rst5279
-rw-r--r--Documentation/filesystems/xfs/xfs-self-describing-metadata.rst (renamed from Documentation/filesystems/xfs-self-describing-metadata.rst)1
-rw-r--r--Documentation/filesystems/zonefs.rst2
-rw-r--r--Documentation/firmware-guide/acpi/acpi-lid.rst2
-rw-r--r--Documentation/firmware-guide/acpi/apei/einj.rst67
-rw-r--r--Documentation/firmware-guide/acpi/chromeos-acpi-device.rst5
-rw-r--r--Documentation/firmware-guide/acpi/dsd/data-node-references.rst26
-rw-r--r--Documentation/firmware-guide/acpi/dsd/graph.rst11
-rw-r--r--Documentation/firmware-guide/acpi/dsd/leds.rst7
-rw-r--r--Documentation/firmware-guide/acpi/enumeration.rst57
-rw-r--r--Documentation/firmware-guide/acpi/gpio-properties.rst71
-rw-r--r--Documentation/firmware-guide/acpi/i2c-muxes.rst12
-rw-r--r--Documentation/firmware-guide/acpi/index.rst1
-rw-r--r--Documentation/firmware-guide/acpi/method-customizing.rst89
-rw-r--r--Documentation/firmware-guide/acpi/namespace.rst6
-rw-r--r--Documentation/firmware-guide/acpi/osi.rst2
-rw-r--r--Documentation/fpga/dfl.rst119
-rw-r--r--Documentation/fpga/index.rst2
-rw-r--r--Documentation/gpu/amdgpu/amd-hardware-list-info.rst23
-rw-r--r--Documentation/gpu/amdgpu/amdgpu-glossary.rst143
-rw-r--r--Documentation/gpu/amdgpu/apu-asic-info-table.csv26
-rw-r--r--Documentation/gpu/amdgpu/debugfs.rst210
-rw-r--r--Documentation/gpu/amdgpu/debugging.rst105
-rw-r--r--Documentation/gpu/amdgpu/dgpu-asic-info-table.csv54
-rw-r--r--Documentation/gpu/amdgpu/display/dc-arch-overview.svg731
-rw-r--r--Documentation/gpu/amdgpu/display/dc-components.svg732
-rw-r--r--Documentation/gpu/amdgpu/display/dc-debug.rst228
-rw-r--r--Documentation/gpu/amdgpu/display/dc-glossary.rst8
-rw-r--r--Documentation/gpu/amdgpu/display/dcn-blocks.rst57
-rw-r--r--Documentation/gpu/amdgpu/display/dcn-overview.rst2
-rw-r--r--Documentation/gpu/amdgpu/display/display-contributing.rst168
-rw-r--r--Documentation/gpu/amdgpu/display/display-manager.rst9
-rw-r--r--Documentation/gpu/amdgpu/display/index.rst79
-rw-r--r--Documentation/gpu/amdgpu/display/mpo-overview.rst2
-rw-r--r--Documentation/gpu/amdgpu/display/programming-model-dcn.rst162
-rw-r--r--Documentation/gpu/amdgpu/display/trace-groups-table.csv29
-rw-r--r--Documentation/gpu/amdgpu/driver-core.rst89
-rw-r--r--Documentation/gpu/amdgpu/driver-misc.rst39
-rw-r--r--Documentation/gpu/amdgpu/flashing.rst33
-rw-r--r--Documentation/gpu/amdgpu/gc/index.rst52
-rw-r--r--Documentation/gpu/amdgpu/gc/mes.rst38
-rw-r--r--Documentation/gpu/amdgpu/index.rst11
-rw-r--r--Documentation/gpu/amdgpu/pipe_and_queue_abstraction.svg1279
-rw-r--r--Documentation/gpu/amdgpu/process-isolation.rst59
-rw-r--r--Documentation/gpu/amdgpu/thermal.rst48
-rw-r--r--Documentation/gpu/amdgpu/userq.rst203
-rw-r--r--Documentation/gpu/automated_testing.rst171
-rw-r--r--Documentation/gpu/driver-uapi.rst26
-rw-r--r--Documentation/gpu/drivers.rst8
-rw-r--r--Documentation/gpu/drm-client.rst3
-rw-r--r--Documentation/gpu/drm-compute.rst54
-rw-r--r--Documentation/gpu/drm-internals.rst41
-rw-r--r--Documentation/gpu/drm-kms-helpers.rst49
-rw-r--r--Documentation/gpu/drm-kms.rst59
-rw-r--r--Documentation/gpu/drm-mm.rst62
-rw-r--r--Documentation/gpu/drm-uapi.rst296
-rw-r--r--Documentation/gpu/drm-usage-stats.rst146
-rw-r--r--Documentation/gpu/drm-vm-bind-async.rst309
-rw-r--r--Documentation/gpu/drm-vm-bind-locking.rst582
-rw-r--r--Documentation/gpu/i915.rst64
-rw-r--r--Documentation/gpu/imagination/index.rst13
-rw-r--r--Documentation/gpu/imagination/uapi.rst171
-rw-r--r--Documentation/gpu/implementation_guidelines.rst10
-rw-r--r--Documentation/gpu/index.rst9
-rw-r--r--Documentation/gpu/introduction.rst12
-rw-r--r--Documentation/gpu/kms-properties.csv2
-rw-r--r--Documentation/gpu/komeda-kms.rst6
-rw-r--r--Documentation/gpu/msm-crash-dump.rst2
-rw-r--r--Documentation/gpu/msm-preemption.rst99
-rw-r--r--Documentation/gpu/nouveau.rst32
-rw-r--r--Documentation/gpu/nova/core/devinit.rst61
-rw-r--r--Documentation/gpu/nova/core/falcon.rst158
-rw-r--r--Documentation/gpu/nova/core/fwsec.rst181
-rw-r--r--Documentation/gpu/nova/core/guidelines.rst24
-rw-r--r--Documentation/gpu/nova/core/todo.rst399
-rw-r--r--Documentation/gpu/nova/core/vbios.rst181
-rw-r--r--Documentation/gpu/nova/guidelines.rst69
-rw-r--r--Documentation/gpu/nova/index.rst34
-rw-r--r--Documentation/gpu/panfrost.rst49
-rw-r--r--Documentation/gpu/panthor.rst56
-rw-r--r--Documentation/gpu/rfc/color_pipeline.rst378
-rw-r--r--Documentation/gpu/rfc/gpusvm.rst118
-rw-r--r--Documentation/gpu/rfc/i915_scheduler.rst8
-rw-r--r--Documentation/gpu/rfc/i915_vm_bind.h11
-rw-r--r--Documentation/gpu/rfc/i915_vm_bind.rst2
-rw-r--r--Documentation/gpu/rfc/index.rst7
-rw-r--r--Documentation/gpu/todo.rst349
-rw-r--r--Documentation/gpu/vc4.rst19
-rw-r--r--Documentation/gpu/vgaarbiter.rst6
-rw-r--r--Documentation/gpu/vkms.rst141
-rw-r--r--Documentation/gpu/xe/index.rst31
-rw-r--r--Documentation/gpu/xe/xe-drm-usage-stats.rst10
-rw-r--r--Documentation/gpu/xe/xe_configfs.rst16
-rw-r--r--Documentation/gpu/xe/xe_cs.rst8
-rw-r--r--Documentation/gpu/xe/xe_debugging.rst7
-rw-r--r--Documentation/gpu/xe/xe_devcoredump.rst14
-rw-r--r--Documentation/gpu/xe/xe_device.rst10
-rw-r--r--Documentation/gpu/xe/xe_exec_queue.rst20
-rw-r--r--Documentation/gpu/xe/xe_firmware.rst43
-rw-r--r--Documentation/gpu/xe/xe_gt_freq.rst17
-rw-r--r--Documentation/gpu/xe/xe_gt_mcr.rst13
-rw-r--r--Documentation/gpu/xe/xe_map.rst8
-rw-r--r--Documentation/gpu/xe/xe_migrate.rst8
-rw-r--r--Documentation/gpu/xe/xe_mm.rst29
-rw-r--r--Documentation/gpu/xe/xe_pcode.rst23
-rw-r--r--Documentation/gpu/xe/xe_pm.rst14
-rw-r--r--Documentation/gpu/xe/xe_rtp.rst20
-rw-r--r--Documentation/gpu/xe/xe_tile.rst14
-rw-r--r--Documentation/gpu/xe/xe_wa.rst14
-rw-r--r--Documentation/gpu/zynqmp.rst147
-rw-r--r--Documentation/hid/hid-alps.rst10
-rw-r--r--Documentation/hid/hid-bpf.rst527
-rw-r--r--Documentation/hid/hiddev.rst2
-rw-r--r--Documentation/hid/hidintro.rst524
-rw-r--r--Documentation/hid/hidraw.rst2
-rw-r--r--Documentation/hid/hidreport-parsing.rst49
-rw-r--r--Documentation/hid/index.rst3
-rw-r--r--Documentation/hid/intel-ish-hid.rst172
-rw-r--r--Documentation/hid/intel-thc-hid.rst596
-rw-r--r--Documentation/hwmon/abituguru-datasheet.rst8
-rw-r--r--Documentation/hwmon/abituguru.rst2
-rw-r--r--Documentation/hwmon/acbel-fsg032.rst80
-rw-r--r--Documentation/hwmon/acpi_power_meter.rst29
-rw-r--r--Documentation/hwmon/adm1021.rst153
-rw-r--r--Documentation/hwmon/adm1275.rst44
-rw-r--r--Documentation/hwmon/adp1050.rst123
-rw-r--r--Documentation/hwmon/adt7475.rst3
-rw-r--r--Documentation/hwmon/aht10.rst30
-rw-r--r--Documentation/hwmon/amc6821.rst7
-rw-r--r--Documentation/hwmon/aquacomputer_d5next.rst48
-rw-r--r--Documentation/hwmon/aspeed-g6-pwm-tach.rst26
-rw-r--r--Documentation/hwmon/aspeed-pwm-tacho.rst2
-rw-r--r--Documentation/hwmon/asus_ec_sensors.rst28
-rw-r--r--Documentation/hwmon/asus_rog_ryujin.rst47
-rw-r--r--Documentation/hwmon/cgbc-hwmon.rst63
-rw-r--r--Documentation/hwmon/chipcap2.rst73
-rw-r--r--Documentation/hwmon/corsair-cpro.rst8
-rw-r--r--Documentation/hwmon/corsair-psu.rst19
-rw-r--r--Documentation/hwmon/cros_ec_hwmon.rst31
-rw-r--r--Documentation/hwmon/crps.rst97
-rw-r--r--Documentation/hwmon/dell-smm-hwmon.rst104
-rw-r--r--Documentation/hwmon/ds1621.rst10
-rw-r--r--Documentation/hwmon/emc1403.rst17
-rw-r--r--Documentation/hwmon/emc2305.rst1
-rw-r--r--Documentation/hwmon/f71882fg.rst9
-rw-r--r--Documentation/hwmon/ftsteutates.rst15
-rw-r--r--Documentation/hwmon/g762.rst2
-rw-r--r--Documentation/hwmon/gigabyte_waterforce.rst47
-rw-r--r--Documentation/hwmon/gpd-fan.rst78
-rw-r--r--Documentation/hwmon/gsc-hwmon.rst6
-rw-r--r--Documentation/hwmon/gxp-fan-ctrl.rst28
-rw-r--r--Documentation/hwmon/hp-wmi-sensors.rst140
-rw-r--r--Documentation/hwmon/hs3001.rst37
-rw-r--r--Documentation/hwmon/htu31.rst37
-rw-r--r--Documentation/hwmon/hwmon-kernel-api.rst87
-rw-r--r--Documentation/hwmon/ina233.rst75
-rw-r--r--Documentation/hwmon/ina238.rst61
-rw-r--r--Documentation/hwmon/ina2xx.rst50
-rw-r--r--Documentation/hwmon/index.rst66
-rw-r--r--Documentation/hwmon/isl28022.rst64
-rw-r--r--Documentation/hwmon/isl68137.rst30
-rw-r--r--Documentation/hwmon/it87.rst47
-rw-r--r--Documentation/hwmon/jc42.rst2
-rw-r--r--Documentation/hwmon/kbatt.rst60
-rw-r--r--Documentation/hwmon/kfan.rst39
-rw-r--r--Documentation/hwmon/lm70.rst2
-rw-r--r--Documentation/hwmon/lm75.rst33
-rw-r--r--Documentation/hwmon/lm90.rst166
-rw-r--r--Documentation/hwmon/lm92.rst26
-rw-r--r--Documentation/hwmon/lt3074.rst72
-rw-r--r--Documentation/hwmon/ltc2978.rst50
-rw-r--r--Documentation/hwmon/ltc2991.rst43
-rw-r--r--Documentation/hwmon/ltc4282.rst133
-rw-r--r--Documentation/hwmon/ltc4286.rst95
-rw-r--r--Documentation/hwmon/macsmc-hwmon.rst71
-rw-r--r--Documentation/hwmon/max127.rst2
-rw-r--r--Documentation/hwmon/max15301.rst10
-rw-r--r--Documentation/hwmon/max16064.rst2
-rw-r--r--Documentation/hwmon/max16065.rst8
-rw-r--r--Documentation/hwmon/max1619.rst8
-rw-r--r--Documentation/hwmon/max16601.rst13
-rw-r--r--Documentation/hwmon/max1668.rst2
-rw-r--r--Documentation/hwmon/max17616.rst62
-rw-r--r--Documentation/hwmon/max197.rst4
-rw-r--r--Documentation/hwmon/max20730.rst8
-rw-r--r--Documentation/hwmon/max31722.rst4
-rw-r--r--Documentation/hwmon/max31730.rst2
-rw-r--r--Documentation/hwmon/max31785.rst2
-rw-r--r--Documentation/hwmon/max31790.rst2
-rw-r--r--Documentation/hwmon/max31827.rst144
-rw-r--r--Documentation/hwmon/max34440.rst53
-rw-r--r--Documentation/hwmon/max6620.rst2
-rw-r--r--Documentation/hwmon/max6639.rst2
-rw-r--r--Documentation/hwmon/max6642.rst27
-rw-r--r--Documentation/hwmon/max6650.rst4
-rw-r--r--Documentation/hwmon/max6697.rst22
-rw-r--r--Documentation/hwmon/max77705.rst41
-rw-r--r--Documentation/hwmon/max8688.rst2
-rw-r--r--Documentation/hwmon/mc33xs2410_hwmon.rst34
-rw-r--r--Documentation/hwmon/mc34vr500.rst32
-rw-r--r--Documentation/hwmon/menf21bmc.rst2
-rw-r--r--Documentation/hwmon/mp2856.rst98
-rw-r--r--Documentation/hwmon/mp2869.rst175
-rw-r--r--Documentation/hwmon/mp2891.rst179
-rw-r--r--Documentation/hwmon/mp2925.rst151
-rw-r--r--Documentation/hwmon/mp29502.rst93
-rw-r--r--Documentation/hwmon/mp2993.rst150
-rw-r--r--Documentation/hwmon/mp5920.rst91
-rw-r--r--Documentation/hwmon/mp5990.rst106
-rw-r--r--Documentation/hwmon/mp9941.rst92
-rw-r--r--Documentation/hwmon/mp9945.rst117
-rw-r--r--Documentation/hwmon/mpq8785.rst109
-rw-r--r--Documentation/hwmon/nct6683.rst25
-rw-r--r--Documentation/hwmon/nct6775.rst11
-rw-r--r--Documentation/hwmon/nct7363.rst35
-rw-r--r--Documentation/hwmon/nzxt-kraken3.rst77
-rw-r--r--Documentation/hwmon/pmbus-core.rst54
-rw-r--r--Documentation/hwmon/pmbus.rst6
-rw-r--r--Documentation/hwmon/powerz.rst30
-rw-r--r--Documentation/hwmon/pt5161l.rst42
-rw-r--r--Documentation/hwmon/qnap-mcu-hwmon.rst27
-rw-r--r--Documentation/hwmon/sa67.rst41
-rw-r--r--Documentation/hwmon/sch5627.rst10
-rw-r--r--Documentation/hwmon/sfctemp.rst33
-rw-r--r--Documentation/hwmon/sg2042-mcu.rst78
-rw-r--r--Documentation/hwmon/sht21.rst26
-rw-r--r--Documentation/hwmon/sht3x.rst56
-rw-r--r--Documentation/hwmon/sht4x.rst16
-rw-r--r--Documentation/hwmon/smm665.rst187
-rw-r--r--Documentation/hwmon/smpro-hwmon.rst102
-rw-r--r--Documentation/hwmon/spd5118.rst63
-rw-r--r--Documentation/hwmon/stpddc60.rst2
-rw-r--r--Documentation/hwmon/submitting-patches.rst2
-rw-r--r--Documentation/hwmon/surface_fan.rst25
-rw-r--r--Documentation/hwmon/sy7636a-hwmon.rst4
-rw-r--r--Documentation/hwmon/sysfs-interface.rst2
-rw-r--r--Documentation/hwmon/tmp108.rst8
-rw-r--r--Documentation/hwmon/tps25990.rst147
-rw-r--r--Documentation/hwmon/tps53679.rst8
-rw-r--r--Documentation/hwmon/tsc1641.rst87
-rw-r--r--Documentation/hwmon/vexpress.rst2
-rw-r--r--Documentation/hwmon/via686a.rst2
-rw-r--r--Documentation/hwmon/xdp710.rst83
-rw-r--r--Documentation/hwmon/zl6100.rst16
-rw-r--r--Documentation/i2c/busses/i2c-i801.rst7
-rw-r--r--Documentation/i2c/busses/i2c-parport.rst2
-rw-r--r--Documentation/i2c/busses/i2c-piix4.rst63
-rw-r--r--Documentation/i2c/fault-codes.rst4
-rw-r--r--Documentation/i2c/gpio-fault-injection.rst2
-rw-r--r--Documentation/i2c/i2c-address-translators.rst96
-rw-r--r--Documentation/i2c/i2c_bus.svg15
-rw-r--r--Documentation/i2c/index.rst1
-rw-r--r--Documentation/i2c/slave-testunit-backend.rst237
-rw-r--r--Documentation/i2c/smbus-protocol.rst2
-rw-r--r--Documentation/i2c/summary.rst79
-rw-r--r--Documentation/i2c/writing-clients.rst37
-rw-r--r--Documentation/ia64/aliasing.rst246
-rw-r--r--Documentation/ia64/efirtc.rst144
-rw-r--r--Documentation/ia64/err_inject.rst1067
-rw-r--r--Documentation/ia64/features.rst3
-rw-r--r--Documentation/ia64/fsys.rst303
-rw-r--r--Documentation/ia64/ia64.rst49
-rw-r--r--Documentation/ia64/index.rst19
-rw-r--r--Documentation/ia64/irq-redir.rst80
-rw-r--r--Documentation/ia64/mca.rst198
-rw-r--r--Documentation/ia64/serial.rst165
-rw-r--r--Documentation/iio/ad3552r.rst73
-rw-r--r--Documentation/iio/ad4000.rst220
-rw-r--r--Documentation/iio/ad4030.rst180
-rw-r--r--Documentation/iio/ad4695.rst269
-rw-r--r--Documentation/iio/ad7191.rst119
-rw-r--r--Documentation/iio/ad7380.rst212
-rw-r--r--Documentation/iio/ad7606.rst189
-rw-r--r--Documentation/iio/ad7625.rst91
-rw-r--r--Documentation/iio/ad7944.rst178
-rw-r--r--Documentation/iio/ade9000.rst268
-rw-r--r--Documentation/iio/adis16475.rst384
-rw-r--r--Documentation/iio/adis16480.rst446
-rw-r--r--Documentation/iio/adis16550.rst376
-rw-r--r--Documentation/iio/adxl313.rst293
-rw-r--r--Documentation/iio/adxl345.rst443
-rw-r--r--Documentation/iio/adxl380.rst233
-rw-r--r--Documentation/iio/bno055.rst51
-rw-r--r--Documentation/iio/iio_adc.rst305
-rw-r--r--Documentation/iio/iio_devbuf.rst152
-rw-r--r--Documentation/iio/iio_dmabuf_api.rst54
-rw-r--r--Documentation/iio/iio_tools.rst27
-rw-r--r--Documentation/iio/index.rst28
-rw-r--r--Documentation/iio/opt4060.rst61
-rw-r--r--Documentation/index.rst73
-rw-r--r--Documentation/infiniband/index.rst1
-rw-r--r--Documentation/infiniband/ucaps.rst71
-rw-r--r--Documentation/input/devices/amijoy.rst125
-rw-r--r--Documentation/input/devices/edt-ft5x06.rst21
-rw-r--r--Documentation/input/devices/elantech.rst2
-rw-r--r--Documentation/input/devices/iforce-protocol.rst2
-rw-r--r--Documentation/input/devices/pxrc.rst7
-rw-r--r--Documentation/input/devices/xpad.rst10
-rw-r--r--Documentation/input/event-codes.rst31
-rw-r--r--Documentation/input/gamepad.rst21
-rw-r--r--Documentation/input/index.rst6
-rw-r--r--Documentation/input/input-programming.rst19
-rw-r--r--Documentation/input/input.rst2
-rw-r--r--Documentation/input/input_kapi.rst5
-rw-r--r--Documentation/input/input_uapi.rst5
-rw-r--r--Documentation/input/joydev/index.rst5
-rw-r--r--Documentation/input/multi-touch-protocol.rst2
-rw-r--r--Documentation/isdn/interface_capi.rst2
-rw-r--r--Documentation/isdn/m_isdn.rst2
-rw-r--r--Documentation/kbuild/Kconfig.recursion-issue-016
-rw-r--r--Documentation/kbuild/bash-completion.rst65
-rw-r--r--Documentation/kbuild/gendwarfksyms.rst395
-rw-r--r--Documentation/kbuild/index.rst3
-rw-r--r--Documentation/kbuild/kbuild.rst58
-rw-r--r--Documentation/kbuild/kconfig-language.rst125
-rw-r--r--Documentation/kbuild/kconfig.rst350
-rw-r--r--Documentation/kbuild/llvm.rst144
-rw-r--r--Documentation/kbuild/makefiles.rst2277
-rw-r--r--Documentation/kbuild/modules.rst265
-rw-r--r--Documentation/kbuild/reproducible-builds.rst13
-rw-r--r--Documentation/kernel-hacking/false-sharing.rst206
-rw-r--r--Documentation/kernel-hacking/hacking.rst4
-rw-r--r--Documentation/kernel-hacking/index.rst1
-rw-r--r--Documentation/kernel-hacking/locking.rst21
-rw-r--r--Documentation/leds/index.rst4
-rw-r--r--Documentation/leds/leds-blinkm.rst31
-rw-r--r--Documentation/leds/leds-cht-wcove.rst38
-rw-r--r--Documentation/leds/leds-class-multicolor.rst82
-rw-r--r--Documentation/leds/leds-class.rst81
-rw-r--r--Documentation/leds/leds-lp5521.rst2
-rw-r--r--Documentation/leds/leds-lp5523.rst2
-rw-r--r--Documentation/leds/leds-mlxcpld.rst2
-rw-r--r--Documentation/leds/leds-mt6370-rgb.rst64
-rw-r--r--Documentation/leds/leds-qcom-lpg.rst4
-rw-r--r--Documentation/leds/leds-st1202.rst34
-rw-r--r--Documentation/leds/ledtrig-oneshot.rst2
-rw-r--r--Documentation/leds/well-known-leds.txt41
-rw-r--r--Documentation/litmus-tests/README47
-rw-r--r--Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus35
-rw-r--r--Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus30
-rw-r--r--Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus34
-rw-r--r--Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus30
-rw-r--r--Documentation/litmus-tests/locking/DCL-broken.litmus54
-rw-r--r--Documentation/litmus-tests/locking/DCL-fixed.litmus55
-rw-r--r--Documentation/litmus-tests/locking/RM-broken.litmus41
-rw-r--r--Documentation/litmus-tests/locking/RM-fixed.litmus41
-rw-r--r--Documentation/livepatch/callbacks.rst4
-rw-r--r--Documentation/livepatch/livepatch.rst2
-rw-r--r--Documentation/livepatch/module-elf-format.rst44
-rw-r--r--Documentation/livepatch/reliable-stacktrace.rst4
-rw-r--r--Documentation/locking/hwspinlock.rst68
-rw-r--r--Documentation/locking/index.rst2
-rw-r--r--Documentation/locking/lockdep-design.rst4
-rw-r--r--Documentation/locking/locktorture.rst6
-rw-r--r--Documentation/locking/locktypes.rst23
-rw-r--r--Documentation/locking/mutex-design.rst18
-rw-r--r--Documentation/locking/percpu-rw-semaphore.rst4
-rw-r--r--Documentation/locking/seqlock.rst13
-rw-r--r--Documentation/loongarch/features.rst3
-rw-r--r--Documentation/loongarch/index.rst21
-rw-r--r--Documentation/loongarch/introduction.rst390
-rw-r--r--Documentation/loongarch/irq-chip-model.rst160
-rw-r--r--Documentation/m68k/features.rst3
-rw-r--r--Documentation/maintainer/configure-git.rst58
-rw-r--r--Documentation/maintainer/feature-and-driver-maintainers.rst166
-rw-r--r--Documentation/maintainer/index.rst1
-rw-r--r--Documentation/maintainer/maintainer-entry-profile.rst11
-rw-r--r--Documentation/maintainer/pull-requests.rst6
-rw-r--r--Documentation/maintainer/rebasing-and-merging.rst6
-rw-r--r--Documentation/memory-barriers.txt39
-rw-r--r--Documentation/mips/features.rst3
-rw-r--r--Documentation/misc-devices/amd-sbi.rst101
-rw-r--r--Documentation/misc-devices/eeprom.rst107
-rw-r--r--Documentation/misc-devices/index.rst9
-rw-r--r--Documentation/misc-devices/lis3lv02d.rst6
-rw-r--r--Documentation/misc-devices/mrvl_cn10k_dpi.rst52
-rw-r--r--Documentation/misc-devices/tps6594-pfsm.rst87
-rw-r--r--Documentation/misc-devices/uacce.rst7
-rw-r--r--Documentation/misc-devices/xilinx_sdfec.rst2
-rw-r--r--Documentation/mm/active_mm.rst10
-rw-r--r--Documentation/mm/allocation-profiling.rst104
-rw-r--r--Documentation/mm/arch_pgtable_helpers.rst50
-rw-r--r--Documentation/mm/balance.rst6
-rw-r--r--Documentation/mm/damon/design.rst735
-rw-r--r--Documentation/mm/damon/faq.rst23
-rw-r--r--Documentation/mm/damon/index.rst38
-rw-r--r--Documentation/mm/damon/maintainer-profile.rst103
-rw-r--r--Documentation/mm/damon/monitoring_intervals_tuning_example.rst247
-rw-r--r--Documentation/mm/free_page_reporting.rst2
-rw-r--r--Documentation/mm/frontswap.rst266
-rw-r--r--Documentation/mm/highmem.rst67
-rw-r--r--Documentation/mm/hmm.rst29
-rw-r--r--Documentation/mm/hugetlbfs_reserv.rst45
-rw-r--r--Documentation/mm/hwpoison.rst4
-rw-r--r--Documentation/mm/index.rst30
-rw-r--r--Documentation/mm/ksm.rst6
-rw-r--r--Documentation/mm/memfd_preservation.rst23
-rw-r--r--Documentation/mm/memory-model.rst4
-rw-r--r--Documentation/mm/mmu_notifier.rst2
-rw-r--r--Documentation/mm/multigen_lru.rst269
-rw-r--r--Documentation/mm/numa.rst6
-rw-r--r--Documentation/mm/overcommit-accounting.rst3
-rw-r--r--Documentation/mm/page_cache.rst10
-rw-r--r--Documentation/mm/page_frags.rst4
-rw-r--r--Documentation/mm/page_migration.rst72
-rw-r--r--Documentation/mm/page_owner.rst111
-rw-r--r--Documentation/mm/page_table_check.rst30
-rw-r--r--Documentation/mm/page_tables.rst276
-rw-r--r--Documentation/mm/physical_memory.rst630
-rw-r--r--Documentation/mm/process_addrs.rst911
-rw-r--r--Documentation/mm/remap_file_pages.rst2
-rw-r--r--Documentation/mm/slab.rst7
-rw-r--r--Documentation/mm/slub.rst452
-rw-r--r--Documentation/mm/split_page_table_lock.rst37
-rw-r--r--Documentation/mm/swap-table.rst69
-rw-r--r--Documentation/mm/transhuge.rst65
-rw-r--r--Documentation/mm/unevictable-lru.rst175
-rw-r--r--Documentation/mm/vmalloced-kernel-stacks.rst18
-rw-r--r--Documentation/mm/vmemmap_dedup.rst28
-rw-r--r--Documentation/mm/z3fold.rst30
-rw-r--r--Documentation/mm/zsmalloc.rst231
-rw-r--r--Documentation/netlink/genetlink-c.yaml406
-rw-r--r--Documentation/netlink/genetlink-legacy.yaml473
-rw-r--r--Documentation/netlink/genetlink.yaml353
-rw-r--r--Documentation/netlink/netlink-raw.yaml517
-rw-r--r--Documentation/netlink/specs/binder.yaml93
-rw-r--r--Documentation/netlink/specs/conntrack.yaml642
-rw-r--r--Documentation/netlink/specs/devlink.yaml2338
-rw-r--r--Documentation/netlink/specs/dpll.yaml681
-rw-r--r--Documentation/netlink/specs/em.yaml113
-rw-r--r--Documentation/netlink/specs/ethtool.yaml2850
-rw-r--r--Documentation/netlink/specs/fou.yaml132
-rw-r--r--Documentation/netlink/specs/handshake.yaml132
-rw-r--r--Documentation/netlink/specs/index.rst13
-rw-r--r--Documentation/netlink/specs/lockd.yaml45
-rw-r--r--Documentation/netlink/specs/mptcp_pm.yaml395
-rw-r--r--Documentation/netlink/specs/net_shaper.yaml363
-rw-r--r--Documentation/netlink/specs/netdev.yaml808
-rw-r--r--Documentation/netlink/specs/nfsd.yaml224
-rw-r--r--Documentation/netlink/specs/nftables.yaml1532
-rw-r--r--Documentation/netlink/specs/nl80211.yaml1933
-rw-r--r--Documentation/netlink/specs/nlctrl.yaml208
-rw-r--r--Documentation/netlink/specs/ovpn.yaml508
-rw-r--r--Documentation/netlink/specs/ovs_datapath.yaml160
-rw-r--r--Documentation/netlink/specs/ovs_flow.yaml1002
-rw-r--r--Documentation/netlink/specs/ovs_vport.yaml172
-rw-r--r--Documentation/netlink/specs/psp.yaml282
-rw-r--r--Documentation/netlink/specs/rt-addr.yaml195
-rw-r--r--Documentation/netlink/specs/rt-link.yaml2555
-rw-r--r--Documentation/netlink/specs/rt-neigh.yaml453
-rw-r--r--Documentation/netlink/specs/rt-route.yaml324
-rw-r--r--Documentation/netlink/specs/rt-rule.yaml275
-rw-r--r--Documentation/netlink/specs/tc.yaml4210
-rw-r--r--Documentation/netlink/specs/tcp_metrics.yaml169
-rw-r--r--Documentation/netlink/specs/team.yaml206
-rw-r--r--Documentation/netlink/specs/wireguard.yaml298
-rw-r--r--Documentation/networking/6pack.rst2
-rw-r--r--Documentation/networking/af_xdp.rst272
-rw-r--r--Documentation/networking/arcnet-hardware.rst26
-rw-r--r--Documentation/networking/arcnet.rst48
-rw-r--r--Documentation/networking/ax25.rst11
-rw-r--r--Documentation/networking/bareudp.rst11
-rw-r--r--Documentation/networking/batman-adv.rst6
-rw-r--r--Documentation/networking/bonding.rst157
-rw-r--r--Documentation/networking/bridge.rst334
-rw-r--r--Documentation/networking/can.rst159
-rw-r--r--Documentation/networking/can_ucan_protocol.rst2
-rw-r--r--Documentation/networking/cdc_mbim.rst4
-rw-r--r--Documentation/networking/dccp.rst219
-rw-r--r--Documentation/networking/device_drivers/appletalk/cops.rst80
-rw-r--r--Documentation/networking/device_drivers/appletalk/index.rst18
-rw-r--r--Documentation/networking/device_drivers/atm/iphase.rst2
-rw-r--r--Documentation/networking/device_drivers/cable/index.rst18
-rw-r--r--Documentation/networking/device_drivers/cable/sb1000.rst222
-rw-r--r--Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst7
-rw-r--r--Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg4
-rw-r--r--Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst29
-rw-r--r--Documentation/networking/device_drivers/ethernet/3com/vortex.rst2
-rw-r--r--Documentation/networking/device_drivers/ethernet/amazon/ena.rst154
-rw-r--r--Documentation/networking/device_drivers/ethernet/amd/pds_core.rst139
-rw-r--r--Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst85
-rw-r--r--Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst79
-rw-r--r--Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst6
-rw-r--r--Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst11
-rw-r--r--Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst2
-rw-r--r--Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst2
-rw-r--r--Documentation/networking/device_drivers/ethernet/google/gve.rst9
-rw-r--r--Documentation/networking/device_drivers/ethernet/huawei/hinic3.rst137
-rw-r--r--Documentation/networking/device_drivers/ethernet/index.rst17
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/e100.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/e1000.rst9
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/e1000e.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/fm10k.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/i40e.rst23
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/iavf.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/ice.rst249
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/idpf.rst160
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/igb.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/igbvf.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/ixgb.rst468
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst7
-rw-r--r--Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst6
-rw-r--r--Documentation/networking/device_drivers/ethernet/marvell/octeon_ep_vf.rst24
-rw-r--r--Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst148
-rw-r--r--Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst762
-rw-r--r--Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst1380
-rw-r--r--Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst25
-rw-r--r--Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst171
-rw-r--r--Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst281
-rw-r--r--Documentation/networking/device_drivers/ethernet/mellanox/mlx5/tracepoints.rst229
-rw-r--r--Documentation/networking/device_drivers/ethernet/meta/fbnic.rst192
-rw-r--r--Documentation/networking/device_drivers/ethernet/mucse/rnpgbe.rst17
-rw-r--r--Documentation/networking/device_drivers/ethernet/neterion/s2io.rst4
-rw-r--r--Documentation/networking/device_drivers/ethernet/netronome/nfp.rst165
-rw-r--r--Documentation/networking/device_drivers/ethernet/pensando/ionic.rst34
-rw-r--r--Documentation/networking/device_drivers/ethernet/pensando/ionic_rdma.rst52
-rw-r--r--Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst194
-rw-r--r--Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst4
-rw-r--r--Documentation/networking/device_drivers/ethernet/ti/cpsw.rst6
-rw-r--r--Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst4
-rw-r--r--Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst56
-rw-r--r--Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst202
-rw-r--r--Documentation/networking/device_drivers/ethernet/wangxun/ngbevf.rst16
-rw-r--r--Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst2
-rw-r--r--Documentation/networking/device_drivers/ethernet/wangxun/txgbevf.rst16
-rw-r--r--Documentation/networking/device_drivers/index.rst3
-rw-r--r--Documentation/networking/device_drivers/qlogic/index.rst18
-rw-r--r--Documentation/networking/device_drivers/qlogic/qlge.rst118
-rw-r--r--Documentation/networking/device_drivers/wifi/index.rst1
-rw-r--r--Documentation/networking/device_drivers/wifi/ray_cs.rst165
-rw-r--r--Documentation/networking/device_drivers/wwan/iosm.rst2
-rw-r--r--Documentation/networking/device_drivers/wwan/t7xx.rst106
-rw-r--r--Documentation/networking/devlink/bnxt.rst2
-rw-r--r--Documentation/networking/devlink/devlink-eswitch-attr.rst89
-rw-r--r--Documentation/networking/devlink/devlink-health.rst25
-rw-r--r--Documentation/networking/devlink/devlink-info.rst14
-rw-r--r--Documentation/networking/devlink/devlink-params.rst28
-rw-r--r--Documentation/networking/devlink/devlink-port.rst264
-rw-r--r--Documentation/networking/devlink/devlink-region.rst15
-rw-r--r--Documentation/networking/devlink/devlink-reload.rst13
-rw-r--r--Documentation/networking/devlink/devlink-trap.rst15
-rw-r--r--Documentation/networking/devlink/etas_es58x.rst36
-rw-r--r--Documentation/networking/devlink/hns3.rst5
-rw-r--r--Documentation/networking/devlink/i40e.rst93
-rw-r--r--Documentation/networking/devlink/ice.rst235
-rw-r--r--Documentation/networking/devlink/index.rst53
-rw-r--r--Documentation/networking/devlink/ixgbe.rst171
-rw-r--r--Documentation/networking/devlink/kvaser_pciefd.rst24
-rw-r--r--Documentation/networking/devlink/kvaser_usb.rst33
-rw-r--r--Documentation/networking/devlink/mlx5.rst347
-rw-r--r--Documentation/networking/devlink/netdevsim.rst4
-rw-r--r--Documentation/networking/devlink/nfp.rst5
-rw-r--r--Documentation/networking/devlink/octeontx2.rst37
-rw-r--r--Documentation/networking/devlink/prestera.rst2
-rw-r--r--Documentation/networking/devlink/sfc.rst71
-rw-r--r--Documentation/networking/devlink/stmmac.rst40
-rw-r--r--Documentation/networking/devlink/zl3073x.rst65
-rw-r--r--Documentation/networking/devmem.rst419
-rw-r--r--Documentation/networking/diagnostic/index.rst17
-rw-r--r--Documentation/networking/diagnostic/twisted_pair_layer1_diagnostics.rst784
-rw-r--r--Documentation/networking/dns_resolver.rst56
-rw-r--r--Documentation/networking/driver.rst156
-rw-r--r--Documentation/networking/dsa/b53.rst14
-rw-r--r--Documentation/networking/dsa/bcm_sf2.rst2
-rw-r--r--Documentation/networking/dsa/configuration.rst104
-rw-r--r--Documentation/networking/dsa/dsa.rst179
-rw-r--r--Documentation/networking/dsa/lan9303.rst2
-rw-r--r--Documentation/networking/dsa/sja1105.rst6
-rw-r--r--Documentation/networking/ethtool-netlink.rst937
-rw-r--r--Documentation/networking/filter.rst8
-rw-r--r--Documentation/networking/generic_netlink.rst2
-rw-r--r--Documentation/networking/gtp.rst2
-rw-r--r--Documentation/networking/ieee802154.rst18
-rw-r--r--Documentation/networking/index.rst29
-rw-r--r--Documentation/networking/iou-zcrx.rst202
-rw-r--r--Documentation/networking/ip-sysctl.rst1178
-rw-r--r--Documentation/networking/ipddp.rst78
-rw-r--r--Documentation/networking/ipvlan.rst2
-rw-r--r--Documentation/networking/ipvs-sysctl.rst24
-rw-r--r--Documentation/networking/iso15765-2.rst386
-rw-r--r--Documentation/networking/j1939.rst679
-rw-r--r--Documentation/networking/kapi.rst3
-rw-r--r--Documentation/networking/kcm.rst2
-rw-r--r--Documentation/networking/l2tp.rst189
-rw-r--r--Documentation/networking/mptcp-sysctl.rst115
-rw-r--r--Documentation/networking/mptcp.rst156
-rw-r--r--Documentation/networking/msg_zerocopy.rst19
-rw-r--r--Documentation/networking/multi-pf-netdev.rst174
-rw-r--r--Documentation/networking/napi.rst505
-rw-r--r--Documentation/networking/net_cachelines/index.rst16
-rw-r--r--Documentation/networking/net_cachelines/inet_connection_sock.rst51
-rw-r--r--Documentation/networking/net_cachelines/inet_sock.rst47
-rw-r--r--Documentation/networking/net_cachelines/net_device.rst193
-rw-r--r--Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst163
-rw-r--r--Documentation/networking/net_cachelines/snmp.rst141
-rw-r--r--Documentation/networking/net_cachelines/tcp_sock.rst170
-rw-r--r--Documentation/networking/net_dim.rst44
-rw-r--r--Documentation/networking/net_failover.rst8
-rw-r--r--Documentation/networking/netconsole.rst245
-rw-r--r--Documentation/networking/netdev-features.rst20
-rw-r--r--Documentation/networking/netdevices.rst153
-rw-r--r--Documentation/networking/netmem.rst98
-rw-r--r--Documentation/networking/nf_conntrack-sysctl.rst34
-rw-r--r--Documentation/networking/nfc.rst6
-rw-r--r--Documentation/networking/oa-tc6-framework.rst497
-rw-r--r--Documentation/networking/packet_mmap.rst21
-rw-r--r--Documentation/networking/page_pool.rst160
-rw-r--r--Documentation/networking/phonet.rst2
-rw-r--r--Documentation/networking/phy-link-topology.rst121
-rw-r--r--Documentation/networking/phy.rst23
-rw-r--r--Documentation/networking/pktgen.rst12
-rw-r--r--Documentation/networking/pse-pd/index.rst10
-rw-r--r--Documentation/networking/pse-pd/introduction.rst73
-rw-r--r--Documentation/networking/pse-pd/pse-pi.rst301
-rw-r--r--Documentation/networking/psp.rst183
-rw-r--r--Documentation/networking/rds.rst10
-rw-r--r--Documentation/networking/regulatory.rst4
-rw-r--r--Documentation/networking/representors.rst9
-rw-r--r--Documentation/networking/rxrpc.rst69
-rw-r--r--Documentation/networking/scaling.rst74
-rw-r--r--Documentation/networking/seg6-sysctl.rst3
-rw-r--r--Documentation/networking/segmentation-offloads.rst22
-rw-r--r--Documentation/networking/sfp-phylink.rst157
-rw-r--r--Documentation/networking/smc-sysctl.rst60
-rw-r--r--Documentation/networking/snmp_counter.rst20
-rw-r--r--Documentation/networking/sriov.rst25
-rw-r--r--Documentation/networking/statistics.rst22
-rw-r--r--Documentation/networking/strparser.rst11
-rw-r--r--Documentation/networking/switchdev.rst4
-rw-r--r--Documentation/networking/sysfs-tagging.rst2
-rw-r--r--Documentation/networking/tc-queue-filters.rst37
-rw-r--r--Documentation/networking/tcp_ao.rst453
-rw-r--r--Documentation/networking/timestamping.rst123
-rw-r--r--Documentation/networking/tipc.rst2
-rw-r--r--Documentation/networking/tls-handshake.rst222
-rw-r--r--Documentation/networking/tls-offload.rst29
-rw-r--r--Documentation/networking/tls.rst60
-rw-r--r--Documentation/networking/tproxy.rst6
-rw-r--r--Documentation/networking/x25-iface.rst3
-rw-r--r--Documentation/networking/xdp-rx-metadata.rst161
-rw-r--r--Documentation/networking/xfrm/index.rst13
-rw-r--r--Documentation/networking/xfrm/xfrm_device.rst206
-rw-r--r--Documentation/networking/xfrm/xfrm_proc.rst119
-rw-r--r--Documentation/networking/xfrm/xfrm_sync.rst192
-rw-r--r--Documentation/networking/xfrm/xfrm_sysctl.rst11
-rw-r--r--Documentation/networking/xfrm_device.rst151
-rw-r--r--Documentation/networking/xfrm_proc.rst113
-rw-r--r--Documentation/networking/xfrm_sync.rst189
-rw-r--r--Documentation/networking/xfrm_sysctl.rst11
-rw-r--r--Documentation/networking/xsk-tx-metadata.rst147
-rw-r--r--Documentation/nios2/features.rst3
-rw-r--r--Documentation/nvme/feature-and-quirk-policy.rst77
-rw-r--r--Documentation/nvme/index.rst12
-rw-r--r--Documentation/nvme/nvme-pci-endpoint-target.rst368
-rw-r--r--Documentation/openrisc/features.rst3
-rw-r--r--Documentation/openrisc/openrisc_port.rst121
-rw-r--r--Documentation/parisc/features.rst3
-rw-r--r--Documentation/pcmcia/index.rst2
-rw-r--r--Documentation/peci/index.rst6
-rw-r--r--Documentation/power/energy-model.rst187
-rw-r--r--Documentation/power/freezing-of-tasks.rst85
-rw-r--r--Documentation/power/index.rst1
-rw-r--r--Documentation/power/opp.rst2
-rw-r--r--Documentation/power/pci.rst19
-rw-r--r--Documentation/power/pm_qos_interface.rst16
-rw-r--r--Documentation/power/power_supply_class.rst88
-rw-r--r--Documentation/power/regulator/consumer.rst38
-rw-r--r--Documentation/power/runtime_pm.rst73
-rw-r--r--Documentation/power/shutdown-debugging.rst53
-rw-r--r--Documentation/power/suspend-and-cpuhotplug.rst2
-rw-r--r--Documentation/power/suspend-and-interrupts.rst4
-rw-r--r--Documentation/power/video.rst2
-rw-r--r--Documentation/powerpc/booting.rst110
-rw-r--r--Documentation/powerpc/cxl.rst469
-rw-r--r--Documentation/powerpc/cxlflash.rst433
-rw-r--r--Documentation/powerpc/elf_hwcaps.rst231
-rw-r--r--Documentation/powerpc/features.rst3
-rw-r--r--Documentation/powerpc/index.rst46
-rw-r--r--Documentation/powerpc/isa-versions.rst79
-rw-r--r--Documentation/process/1.Intro.rst12
-rw-r--r--Documentation/process/2.Process.rst77
-rw-r--r--Documentation/process/4.Coding.rst6
-rw-r--r--Documentation/process/5.Posting.rst50
-rw-r--r--Documentation/process/6.Followthrough.rst7
-rw-r--r--Documentation/process/7.AdvancedTopics.rst18
-rw-r--r--Documentation/process/adding-syscalls.rst84
-rw-r--r--Documentation/process/backporting.rst604
-rw-r--r--Documentation/process/botching-up-ioctls.rst4
-rw-r--r--Documentation/process/changes.rst111
-rw-r--r--Documentation/process/code-of-conduct-interpretation.rst100
-rw-r--r--Documentation/process/coding-style.rst65
-rw-r--r--Documentation/process/contribution-maturity-model.rst109
-rw-r--r--Documentation/process/cve.rst121
-rw-r--r--Documentation/process/debugging/driver_development_debugging_guide.rst235
-rw-r--r--Documentation/process/debugging/gdb-kernel-debugging.rst175
-rw-r--r--Documentation/process/debugging/index.rst80
-rw-r--r--Documentation/process/debugging/kgdb.rst (renamed from Documentation/dev-tools/kgdb.rst)70
-rw-r--r--Documentation/process/debugging/media_specific_debugging_guide.rst180
-rw-r--r--Documentation/process/debugging/userspace_debugging_guide.rst280
-rw-r--r--Documentation/process/deprecated.rst28
-rw-r--r--Documentation/process/development-process.rst19
-rw-r--r--Documentation/process/email-clients.rst19
-rw-r--r--Documentation/process/embargoed-hardware-issues.rst179
-rw-r--r--Documentation/process/handling-regressions.rst252
-rw-r--r--Documentation/process/howto.rst21
-rw-r--r--Documentation/process/index.rst93
-rw-r--r--Documentation/process/kernel-docs.rst699
-rw-r--r--Documentation/process/license-rules.rst18
-rw-r--r--Documentation/process/magic-number.rst154
-rw-r--r--Documentation/process/maintainer-handbooks.rst5
-rw-r--r--Documentation/process/maintainer-kvm-x86.rst390
-rw-r--r--Documentation/process/maintainer-netdev.rst585
-rw-r--r--Documentation/process/maintainer-pgp-guide.rst246
-rw-r--r--Documentation/process/maintainer-soc-clean-dts.rst26
-rw-r--r--Documentation/process/maintainer-soc.rst209
-rw-r--r--Documentation/process/maintainer-tip.rst97
-rw-r--r--Documentation/process/programming-language.rst24
-rw-r--r--Documentation/process/researcher-guidelines.rst31
-rw-r--r--Documentation/process/security-bugs.rst116
-rw-r--r--Documentation/process/stable-kernel-rules.rst286
-rw-r--r--Documentation/process/submit-checklist.rst173
-rw-r--r--Documentation/process/submitting-patches.rst263
-rw-r--r--Documentation/riscv/boot-image-header.rst62
-rw-r--r--Documentation/riscv/features.rst3
-rw-r--r--Documentation/riscv/index.rst19
-rw-r--r--Documentation/riscv/patch-acceptance.rst35
-rw-r--r--Documentation/riscv/vm-layout.rst99
-rw-r--r--Documentation/rust/arch-support.rst16
-rw-r--r--Documentation/rust/coding-guidelines.rst309
-rw-r--r--Documentation/rust/general-information.rst90
-rw-r--r--Documentation/rust/index.rst45
-rw-r--r--Documentation/rust/quick-start.rst228
-rw-r--r--Documentation/rust/testing.rst236
-rw-r--r--Documentation/s390/features.rst3
-rw-r--r--Documentation/s390/index.rst30
-rw-r--r--Documentation/scheduler/completion.rst4
-rw-r--r--Documentation/scheduler/index.rst10
-rw-r--r--Documentation/scheduler/membarrier.rst39
-rw-r--r--Documentation/scheduler/sched-arch.rst6
-rw-r--r--Documentation/scheduler/sched-bwc.rst4
-rw-r--r--Documentation/scheduler/sched-capacity.rst17
-rw-r--r--Documentation/scheduler/sched-deadline.rst119
-rw-r--r--Documentation/scheduler/sched-debug.rst2
-rw-r--r--Documentation/scheduler/sched-design-CFS.rst27
-rw-r--r--Documentation/scheduler/sched-domains.rst17
-rw-r--r--Documentation/scheduler/sched-eevdf.rst43
-rw-r--r--Documentation/scheduler/sched-energy.rst33
-rw-r--r--Documentation/scheduler/sched-ext.rst367
-rw-r--r--Documentation/scheduler/sched-rt-group.rst43
-rw-r--r--Documentation/scheduler/sched-stats.rst140
-rw-r--r--Documentation/scheduler/sched-util-clamp.rst741
-rw-r--r--Documentation/scheduler/schedutil.rst7
-rw-r--r--Documentation/scsi/ChangeLog.lpfc40
-rw-r--r--Documentation/scsi/ChangeLog.megaraid8
-rw-r--r--Documentation/scsi/ChangeLog.megaraid_sas4
-rw-r--r--Documentation/scsi/ChangeLog.ncr53c8xx16
-rw-r--r--Documentation/scsi/ChangeLog.sym53c8xx14
-rw-r--r--Documentation/scsi/ChangeLog.sym53c8xx_210
-rw-r--r--Documentation/scsi/arcmsr_spec.rst1
-rw-r--r--Documentation/scsi/dc395x.rst17
-rw-r--r--Documentation/scsi/g_NCR5380.rst6
-rw-r--r--Documentation/scsi/index.rst43
-rw-r--r--Documentation/scsi/megaraid.rst6
-rw-r--r--Documentation/scsi/ncr53c8xx.rst10
-rw-r--r--Documentation/scsi/scsi-changer.rst6
-rw-r--r--Documentation/scsi/scsi-generic.rst53
-rw-r--r--Documentation/scsi/scsi.rst23
-rw-r--r--Documentation/scsi/scsi_eh.rst53
-rw-r--r--Documentation/scsi/scsi_fc_transport.rst43
-rw-r--r--Documentation/scsi/scsi_mid_low_api.rst258
-rw-r--r--Documentation/scsi/st.rst5
-rw-r--r--Documentation/scsi/sym53c8xx_2.rst8
-rw-r--r--Documentation/scsi/tcm_qla2xxx.rst2
-rw-r--r--Documentation/scsi/ufs.rst2
-rw-r--r--Documentation/security/SCTP.rst2
-rw-r--r--Documentation/security/credentials.rst7
-rw-r--r--Documentation/security/digsig.rst2
-rw-r--r--Documentation/security/index.rst2
-rw-r--r--Documentation/security/ipe.rst446
-rw-r--r--Documentation/security/keys/core.rst2
-rw-r--r--Documentation/security/keys/trusted-encrypted.rst146
-rw-r--r--Documentation/security/landlock.rst62
-rw-r--r--Documentation/security/lsm-development.rst6
-rw-r--r--Documentation/security/lsm.rst2
-rw-r--r--Documentation/security/secrets/coco.rst2
-rw-r--r--Documentation/security/self-protection.rst2
-rw-r--r--Documentation/security/snp-tdx-threat-model.rst253
-rw-r--r--Documentation/security/tpm/index.rst3
-rw-r--r--Documentation/security/tpm/tpm-security.rst216
-rw-r--r--Documentation/security/tpm/tpm_ffa_crb.rst65
-rw-r--r--Documentation/security/tpm/tpm_tis.rst46
-rw-r--r--Documentation/sh/features.rst3
-rw-r--r--Documentation/sh/index.rst56
-rw-r--r--Documentation/sound/alsa-configuration.rst147
-rw-r--r--Documentation/sound/cards/audigy-mixer.rst260
-rw-r--r--Documentation/sound/cards/emu-mixer.rst226
-rw-r--r--Documentation/sound/cards/index.rst2
-rw-r--r--Documentation/sound/cards/maya44.rst2
-rw-r--r--Documentation/sound/cards/pcmtest.rst120
-rw-r--r--Documentation/sound/cards/sb-live-mixer.rst45
-rw-r--r--Documentation/sound/codecs/cs35l56.rst305
-rw-r--r--Documentation/sound/codecs/index.rst9
-rw-r--r--Documentation/sound/designs/compress-accel.rst134
-rw-r--r--Documentation/sound/designs/compress-offload.rst11
-rw-r--r--Documentation/sound/designs/index.rst2
-rw-r--r--Documentation/sound/designs/jack-controls.rst2
-rw-r--r--Documentation/sound/designs/midi-2.0.rst584
-rw-r--r--Documentation/sound/designs/powersave.rst6
-rw-r--r--Documentation/sound/designs/seq-oss.rst2
-rw-r--r--Documentation/sound/hd-audio/index.rst1
-rw-r--r--Documentation/sound/hd-audio/intel-multi-link.rst312
-rw-r--r--Documentation/sound/hd-audio/models.rst2
-rw-r--r--Documentation/sound/hd-audio/notes.rst32
-rw-r--r--Documentation/sound/index.rst10
-rw-r--r--Documentation/sound/kernel-api/writing-an-alsa-driver.rst1171
-rw-r--r--Documentation/sound/soc/clocking.rst12
-rw-r--r--Documentation/sound/soc/codec-to-codec.rst12
-rw-r--r--Documentation/sound/soc/codec.rst4
-rw-r--r--Documentation/sound/soc/dapm-graph.svg375
-rw-r--r--Documentation/sound/soc/dapm.rst172
-rw-r--r--Documentation/sound/soc/dpcm.rst35
-rw-r--r--Documentation/sound/soc/index.rst1
-rw-r--r--Documentation/sound/soc/machine.rst26
-rw-r--r--Documentation/sound/soc/platform.rst4
-rw-r--r--Documentation/sound/soc/usb.rst482
-rw-r--r--Documentation/sound/utimers.rst126
-rw-r--r--Documentation/sparc/features.rst3
-rw-r--r--Documentation/sphinx-static/custom.css153
-rw-r--r--Documentation/sphinx-static/theme_overrides.css5
-rw-r--r--Documentation/sphinx/automarkup.py188
-rw-r--r--Documentation/sphinx/cdomain.py253
-rw-r--r--Documentation/sphinx/kernel_abi.py198
-rw-r--r--Documentation/sphinx/kernel_feat.py73
-rwxr-xr-xDocumentation/sphinx/kernel_include.py614
-rw-r--r--Documentation/sphinx/kerneldoc-preamble.sty20
-rw-r--r--Documentation/sphinx/kerneldoc.py229
-rw-r--r--Documentation/sphinx/kernellog.py22
-rw-r--r--Documentation/sphinx/kfigure.py102
-rw-r--r--Documentation/sphinx/load_config.py57
-rwxr-xr-xDocumentation/sphinx/maintainers_include.py16
-rw-r--r--Documentation/sphinx/min_requirements.txt11
-rw-r--r--Documentation/sphinx/parallel-wrapper.sh33
-rwxr-xr-xDocumentation/sphinx/parse-headers.pl401
-rwxr-xr-xDocumentation/sphinx/parser_yaml.py123
-rw-r--r--Documentation/sphinx/requirements.txt8
-rwxr-xr-xDocumentation/sphinx/rstFlatTable.py11
-rw-r--r--Documentation/sphinx/templates/kernel-toc.html19
-rw-r--r--Documentation/sphinx/templates/translations.html15
-rw-r--r--Documentation/sphinx/translations.py99
-rw-r--r--Documentation/spi/index.rst1
-rw-r--r--Documentation/spi/pxa2xx.rst214
-rw-r--r--Documentation/spi/spi-lm70llp.rst8
-rw-r--r--Documentation/spi/spi-summary.rst221
-rw-r--r--Documentation/spi/spidev.rst2
-rw-r--r--Documentation/staging/crc32.rst6
-rw-r--r--Documentation/staging/index.rst2
-rw-r--r--Documentation/staging/magic-number.rst84
-rw-r--r--Documentation/staging/remoteproc.rst2
-rw-r--r--Documentation/staging/rpmsg.rst84
-rw-r--r--Documentation/staging/speculation.rst1
-rw-r--r--Documentation/staging/tee.rst311
-rw-r--r--Documentation/staging/xz.rst157
-rw-r--r--Documentation/subsystem-apis.rst77
-rw-r--r--Documentation/sunrpc/xdr/nfs4_1.x186
-rw-r--r--Documentation/target/scripts.rst6
-rwxr-xr-xDocumentation/target/tcm_mod_builder.py656
-rw-r--r--Documentation/target/tcmu-design.rst2
-rw-r--r--Documentation/tee/amd-tee.rst90
-rw-r--r--Documentation/tee/index.rst21
-rw-r--r--Documentation/tee/op-tee.rst166
-rw-r--r--Documentation/tee/qtee.rst96
-rw-r--r--Documentation/tee/tee.rst22
-rw-r--r--Documentation/tee/ts-tee.rst71
-rw-r--r--Documentation/timers/delay_sleep_functions.rst121
-rw-r--r--Documentation/timers/hrtimers.rst21
-rw-r--r--Documentation/timers/index.rst4
-rw-r--r--Documentation/timers/no_hz.rst7
-rw-r--r--Documentation/timers/timers-howto.rst115
-rw-r--r--Documentation/tools/index.rst1
-rw-r--r--Documentation/tools/rtla/common_appendix.rst13
-rw-r--r--Documentation/tools/rtla/common_appendix.txt24
-rw-r--r--Documentation/tools/rtla/common_hist_options.txt (renamed from Documentation/tools/rtla/common_hist_options.rst)0
-rw-r--r--Documentation/tools/rtla/common_options.rst47
-rw-r--r--Documentation/tools/rtla/common_options.txt129
-rw-r--r--Documentation/tools/rtla/common_osnoise_description.txt (renamed from Documentation/tools/rtla/common_osnoise_description.rst)0
-rw-r--r--Documentation/tools/rtla/common_osnoise_options.rst27
-rw-r--r--Documentation/tools/rtla/common_osnoise_options.txt39
-rw-r--r--Documentation/tools/rtla/common_timerlat_aa.txt7
-rw-r--r--Documentation/tools/rtla/common_timerlat_description.rst10
-rw-r--r--Documentation/tools/rtla/common_timerlat_description.txt18
-rw-r--r--Documentation/tools/rtla/common_timerlat_options.rst28
-rw-r--r--Documentation/tools/rtla/common_timerlat_options.txt67
-rw-r--r--Documentation/tools/rtla/common_top_options.txt (renamed from Documentation/tools/rtla/common_top_options.rst)0
-rw-r--r--Documentation/tools/rtla/index.rst1
-rw-r--r--Documentation/tools/rtla/rtla-hwnoise.rst109
-rw-r--r--Documentation/tools/rtla/rtla-osnoise-hist.rst12
-rw-r--r--Documentation/tools/rtla/rtla-osnoise-top.rst12
-rw-r--r--Documentation/tools/rtla/rtla-osnoise.rst4
-rw-r--r--Documentation/tools/rtla/rtla-timerlat-hist.rst21
-rw-r--r--Documentation/tools/rtla/rtla-timerlat-top.rst187
-rw-r--r--Documentation/tools/rtla/rtla-timerlat.rst13
-rw-r--r--Documentation/tools/rtla/rtla.rst2
-rw-r--r--Documentation/tools/rv/Makefile52
-rw-r--r--Documentation/tools/rv/common_appendix.rst16
-rw-r--r--Documentation/tools/rv/common_ikm.rst21
-rw-r--r--Documentation/tools/rv/index.rst25
-rw-r--r--Documentation/tools/rv/rv-list.rst43
-rw-r--r--Documentation/tools/rv/rv-mon-sched.rst69
-rw-r--r--Documentation/tools/rv/rv-mon-wip.rst44
-rw-r--r--Documentation/tools/rv/rv-mon-wwnr.rst43
-rw-r--r--Documentation/tools/rv/rv-mon.rst55
-rw-r--r--Documentation/tools/rv/rv.rst63
-rw-r--r--Documentation/trace/boottime-trace.rst6
-rw-r--r--Documentation/trace/coresight/coresight-cpu-debug.rst3
-rw-r--r--Documentation/trace/coresight/coresight-dummy.rst32
-rw-r--r--Documentation/trace/coresight/coresight-etm4x-reference.rst16
-rw-r--r--Documentation/trace/coresight/coresight-perf.rst189
-rw-r--r--Documentation/trace/coresight/coresight-tpda.rst52
-rw-r--r--Documentation/trace/coresight/coresight-tpdm.rst45
-rw-r--r--Documentation/trace/coresight/coresight.rst47
-rw-r--r--Documentation/trace/coresight/panic.rst362
-rw-r--r--Documentation/trace/coresight/ultrasoc-smb.rst83
-rw-r--r--Documentation/trace/debugging.rst161
-rw-r--r--Documentation/trace/eprobetrace.rst269
-rw-r--r--Documentation/trace/events-msr.rst4
-rw-r--r--Documentation/trace/events-nmi.rst6
-rw-r--r--Documentation/trace/events.rst142
-rw-r--r--Documentation/trace/fprobe.rst56
-rw-r--r--Documentation/trace/fprobetrace.rst251
-rw-r--r--Documentation/trace/ftrace-design.rst24
-rw-r--r--Documentation/trace/ftrace-uses.rst6
-rw-r--r--Documentation/trace/ftrace.rst273
-rw-r--r--Documentation/trace/hisi-ptt.rst304
-rw-r--r--Documentation/trace/histogram-design.rst187
-rw-r--r--Documentation/trace/histogram.rst532
-rw-r--r--Documentation/trace/hwlat_detector.rst2
-rw-r--r--Documentation/trace/index.rst99
-rw-r--r--Documentation/trace/kprobes.rst8
-rw-r--r--Documentation/trace/kprobetrace.rst84
-rw-r--r--Documentation/trace/mmiotrace.rst20
-rw-r--r--Documentation/trace/osnoise-tracer.rst34
-rw-r--r--Documentation/trace/postprocess/decode_msr.py2
-rw-r--r--Documentation/trace/postprocess/trace-pagealloc-postprocess.pl4
-rw-r--r--Documentation/trace/postprocess/trace-vmscan-postprocess.pl46
-rw-r--r--Documentation/trace/ring-buffer-map.rst106
-rw-r--r--Documentation/trace/rv/da_monitor_synthesis.rst147
-rw-r--r--Documentation/trace/rv/index.rst5
-rw-r--r--Documentation/trace/rv/linear_temporal_logic.rst134
-rw-r--r--Documentation/trace/rv/monitor_rtapp.rst133
-rw-r--r--Documentation/trace/rv/monitor_sched.rst402
-rw-r--r--Documentation/trace/rv/monitor_synthesis.rst271
-rw-r--r--Documentation/trace/rv/monitor_wwnr.rst2
-rw-r--r--Documentation/trace/rv/runtime-verification.rst6
-rw-r--r--Documentation/trace/timerlat-tracer.rst90
-rw-r--r--Documentation/trace/tracepoint-analysis.rst8
-rw-r--r--Documentation/trace/tracepoints.rst19
-rw-r--r--Documentation/trace/uprobetracer.rst24
-rw-r--r--Documentation/trace/user_events.rst210
-rw-r--r--Documentation/translations/index.rst1
-rw-r--r--Documentation/translations/it_IT/RCU/index.rst19
-rw-r--r--Documentation/translations/it_IT/RCU/torture.rst369
-rw-r--r--Documentation/translations/it_IT/admin-guide/README.rst2
-rw-r--r--Documentation/translations/it_IT/admin-guide/security-bugs.rst12
-rw-r--r--Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst60
-rw-r--r--Documentation/translations/it_IT/core-api/index.rst12
-rw-r--r--Documentation/translations/it_IT/core-api/symbol-namespaces.rst43
-rw-r--r--Documentation/translations/it_IT/dev-tools/clang-format.rst (renamed from Documentation/translations/it_IT/process/clang-format.rst)4
-rw-r--r--Documentation/translations/it_IT/dev-tools/index.rst17
-rw-r--r--Documentation/translations/it_IT/doc-guide/kernel-doc.rst56
-rw-r--r--Documentation/translations/it_IT/doc-guide/parse-headers.rst15
-rw-r--r--Documentation/translations/it_IT/doc-guide/sphinx.rst18
-rw-r--r--Documentation/translations/it_IT/i2c/i2c-protocol.rst99
-rw-r--r--Documentation/translations/it_IT/i2c/index.rst46
-rw-r--r--Documentation/translations/it_IT/i2c/summary.rst84
-rw-r--r--Documentation/translations/it_IT/index.rst130
-rw-r--r--Documentation/translations/it_IT/kernel-hacking/hacking.rst2
-rw-r--r--Documentation/translations/it_IT/kernel-hacking/locking.rst23
-rw-r--r--Documentation/translations/it_IT/locking/index.rst20
-rw-r--r--Documentation/translations/it_IT/locking/lockdep-design.rst678
-rw-r--r--Documentation/translations/it_IT/locking/lockstat.rst230
-rw-r--r--Documentation/translations/it_IT/locking/locktorture.rst181
-rw-r--r--Documentation/translations/it_IT/locking/locktypes.rst547
-rw-r--r--Documentation/translations/it_IT/networking/netdev-FAQ.rst13
-rw-r--r--Documentation/translations/it_IT/process/2.Process.rst30
-rw-r--r--Documentation/translations/it_IT/process/4.Coding.rst6
-rw-r--r--Documentation/translations/it_IT/process/5.Posting.rst43
-rw-r--r--Documentation/translations/it_IT/process/6.Followthrough.rst7
-rw-r--r--Documentation/translations/it_IT/process/7.AdvancedTopics.rst27
-rw-r--r--Documentation/translations/it_IT/process/botching-up-ioctls.rst249
-rw-r--r--Documentation/translations/it_IT/process/changes.rst100
-rw-r--r--Documentation/translations/it_IT/process/coding-style.rst61
-rw-r--r--Documentation/translations/it_IT/process/deprecated.rst31
-rw-r--r--Documentation/translations/it_IT/process/development-process.rst19
-rw-r--r--Documentation/translations/it_IT/process/email-clients.rst89
-rw-r--r--Documentation/translations/it_IT/process/howto.rst18
-rw-r--r--Documentation/translations/it_IT/process/index.rst72
-rw-r--r--Documentation/translations/it_IT/process/kernel-docs.rst4
-rw-r--r--Documentation/translations/it_IT/process/magic-number.rst161
-rw-r--r--Documentation/translations/it_IT/process/maintainer-pgp-guide.rst352
-rw-r--r--Documentation/translations/it_IT/process/programming-language.rst25
-rw-r--r--Documentation/translations/it_IT/process/security-bugs.rst12
-rw-r--r--Documentation/translations/it_IT/process/stable-kernel-rules.rst314
-rw-r--r--Documentation/translations/it_IT/process/submit-checklist.rst168
-rw-r--r--Documentation/translations/it_IT/process/submitting-patches.rst199
-rw-r--r--Documentation/translations/it_IT/process/volatile-considered-harmful.rst4
-rw-r--r--Documentation/translations/it_IT/riscv/patch-acceptance.rst40
-rw-r--r--Documentation/translations/it_IT/staging/index.rst13
-rw-r--r--Documentation/translations/it_IT/staging/magic-number.rst90
-rw-r--r--Documentation/translations/it_IT/subsystem-apis.rst47
-rw-r--r--Documentation/translations/ja_JP/SubmitChecklist105
-rw-r--r--Documentation/translations/ja_JP/SubmittingPatches30
-rw-r--r--Documentation/translations/ja_JP/disclaimer-ja_JP.rst24
-rw-r--r--Documentation/translations/ja_JP/howto.rst650
-rw-r--r--Documentation/translations/ja_JP/index.rst4
-rw-r--r--Documentation/translations/ja_JP/process/howto.rst629
-rw-r--r--Documentation/translations/ja_JP/process/submit-checklist.rst163
-rw-r--r--Documentation/translations/ko_KR/core-api/wrappers/memory-barriers.rst18
-rw-r--r--Documentation/translations/ko_KR/howto.rst619
-rw-r--r--Documentation/translations/ko_KR/index.rst16
-rw-r--r--Documentation/translations/ko_KR/memory-barriers.txt149
-rw-r--r--Documentation/translations/ko_KR/process/howto.rst619
-rw-r--r--Documentation/translations/sp_SP/disclaimer-sp.rst9
-rw-r--r--Documentation/translations/sp_SP/index.rst81
-rw-r--r--Documentation/translations/sp_SP/memory-barriers.txt3134
-rw-r--r--Documentation/translations/sp_SP/process/1.Intro.rst302
-rw-r--r--Documentation/translations/sp_SP/process/2.Process.rst543
-rw-r--r--Documentation/translations/sp_SP/process/3.Early-stage.rst241
-rw-r--r--Documentation/translations/sp_SP/process/4.Coding.rst470
-rw-r--r--Documentation/translations/sp_SP/process/5.Posting.rst391
-rw-r--r--Documentation/translations/sp_SP/process/6.Followthrough.rst230
-rw-r--r--Documentation/translations/sp_SP/process/7.AdvancedTopics.rst214
-rw-r--r--Documentation/translations/sp_SP/process/8.Conclusion.rst82
-rw-r--r--Documentation/translations/sp_SP/process/adding-syscalls.rst632
-rw-r--r--Documentation/translations/sp_SP/process/code-of-conduct.rst97
-rw-r--r--Documentation/translations/sp_SP/process/coding-style.rst1315
-rw-r--r--Documentation/translations/sp_SP/process/contribution-maturity-model.rst120
-rw-r--r--Documentation/translations/sp_SP/process/deprecated.rst381
-rw-r--r--Documentation/translations/sp_SP/process/development-process.rst32
-rw-r--r--Documentation/translations/sp_SP/process/email-clients.rst374
-rw-r--r--Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst341
-rw-r--r--Documentation/translations/sp_SP/process/handling-regressions.rst797
-rw-r--r--Documentation/translations/sp_SP/process/howto.rst617
-rw-r--r--Documentation/translations/sp_SP/process/index.rst32
-rw-r--r--Documentation/translations/sp_SP/process/kernel-docs.rst186
-rw-r--r--Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst174
-rw-r--r--Documentation/translations/sp_SP/process/magic-number.rst89
-rw-r--r--Documentation/translations/sp_SP/process/maintainer-kvm-x86.rst465
-rw-r--r--Documentation/translations/sp_SP/process/management-style.rst299
-rw-r--r--Documentation/translations/sp_SP/process/programming-language.rst53
-rw-r--r--Documentation/translations/sp_SP/process/researcher-guidelines.rst150
-rw-r--r--Documentation/translations/sp_SP/process/security-bugs.rst103
-rw-r--r--Documentation/translations/sp_SP/process/submit-checklist.rst134
-rw-r--r--Documentation/translations/sp_SP/process/submitting-patches.rst919
-rw-r--r--Documentation/translations/sp_SP/scheduler/index.rst10
-rw-r--r--Documentation/translations/sp_SP/scheduler/sched-bwc.rst287
-rw-r--r--Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst277
-rw-r--r--Documentation/translations/sp_SP/scheduler/sched-eevdf.rst58
-rw-r--r--Documentation/translations/sp_SP/wrappers/memory-barriers.rst19
-rw-r--r--Documentation/translations/zh_CN/PCI/msi-howto.rst13
-rw-r--r--Documentation/translations/zh_CN/PCI/pci.rst2
-rw-r--r--Documentation/translations/zh_CN/PCI/pciebus-howto.rst2
-rw-r--r--Documentation/translations/zh_CN/accounting/delay-accounting.rst17
-rw-r--r--Documentation/translations/zh_CN/admin-guide/README.rst6
-rw-r--r--Documentation/translations/zh_CN/admin-guide/bug-hunting.rst13
-rw-r--r--Documentation/translations/zh_CN/admin-guide/index.rst3
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst1
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst263
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst8
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst16
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst310
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/index.rst2
-rw-r--r--Documentation/translations/zh_CN/admin-guide/mm/ksm.rst50
-rw-r--r--Documentation/translations/zh_CN/admin-guide/numastat.rst48
-rw-r--r--Documentation/translations/zh_CN/admin-guide/reporting-issues.rst4
-rw-r--r--Documentation/translations/zh_CN/admin-guide/security-bugs.rst74
-rw-r--r--Documentation/translations/zh_CN/admin-guide/sysrq.rst22
-rw-r--r--Documentation/translations/zh_CN/arch/arm/Booting175
-rw-r--r--Documentation/translations/zh_CN/arch/arm/kernel_user_helpers.txt284
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/amu.rst100
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/booting.txt246
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/elf_hwcaps.rst240
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/hugetlbpage.rst45
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/index.rst19
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/legacy_instructions.txt72
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/memory.txt114
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/perf.rst86
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/silicon-errata.txt74
-rw-r--r--Documentation/translations/zh_CN/arch/arm64/tagged-pointers.txt52
-rw-r--r--Documentation/translations/zh_CN/arch/index.rst28
-rw-r--r--Documentation/translations/zh_CN/arch/loongarch/booting.rst48
-rw-r--r--Documentation/translations/zh_CN/arch/loongarch/features.rst8
-rw-r--r--Documentation/translations/zh_CN/arch/loongarch/index.rst27
-rw-r--r--Documentation/translations/zh_CN/arch/loongarch/introduction.rst353
-rw-r--r--Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst244
-rw-r--r--Documentation/translations/zh_CN/arch/mips/booting.rst34
-rw-r--r--Documentation/translations/zh_CN/arch/mips/features.rst13
-rw-r--r--Documentation/translations/zh_CN/arch/mips/index.rst29
-rw-r--r--Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst72
-rw-r--r--Documentation/translations/zh_CN/arch/openrisc/index.rst32
-rw-r--r--Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst127
-rw-r--r--Documentation/translations/zh_CN/arch/openrisc/todo.rst23
-rw-r--r--Documentation/translations/zh_CN/arch/parisc/debugging.rst45
-rw-r--r--Documentation/translations/zh_CN/arch/parisc/index.rst31
-rw-r--r--Documentation/translations/zh_CN/arch/parisc/registers.rst156
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/boot-image-header.rst69
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/boot.rst155
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/index.rst31
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/patch-acceptance.rst33
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/vm-layout.rst104
-rw-r--r--Documentation/translations/zh_CN/arm/Booting175
-rw-r--r--Documentation/translations/zh_CN/arm/kernel_user_helpers.txt284
-rw-r--r--Documentation/translations/zh_CN/arm64/amu.rst100
-rw-r--r--Documentation/translations/zh_CN/arm64/booting.txt246
-rw-r--r--Documentation/translations/zh_CN/arm64/elf_hwcaps.rst240
-rw-r--r--Documentation/translations/zh_CN/arm64/hugetlbpage.rst45
-rw-r--r--Documentation/translations/zh_CN/arm64/index.rst19
-rw-r--r--Documentation/translations/zh_CN/arm64/legacy_instructions.txt72
-rw-r--r--Documentation/translations/zh_CN/arm64/memory.txt114
-rw-r--r--Documentation/translations/zh_CN/arm64/perf.rst86
-rw-r--r--Documentation/translations/zh_CN/arm64/silicon-errata.txt74
-rw-r--r--Documentation/translations/zh_CN/arm64/tagged-pointers.txt52
-rw-r--r--Documentation/translations/zh_CN/block/blk-mq.rst130
-rw-r--r--Documentation/translations/zh_CN/block/data-integrity.rst192
-rw-r--r--Documentation/translations/zh_CN/block/index.rst35
-rw-r--r--Documentation/translations/zh_CN/core-api/cachetlb.rst2
-rw-r--r--Documentation/translations/zh_CN/core-api/cpu_hotplug.rst6
-rw-r--r--Documentation/translations/zh_CN/core-api/errseq.rst145
-rw-r--r--Documentation/translations/zh_CN/core-api/index.rst7
-rw-r--r--Documentation/translations/zh_CN/core-api/irq/irq-domain.rst8
-rw-r--r--Documentation/translations/zh_CN/core-api/kernel-api.rst12
-rw-r--r--Documentation/translations/zh_CN/core-api/local_ops.rst2
-rw-r--r--Documentation/translations/zh_CN/core-api/memory-hotplug.rst3
-rw-r--r--Documentation/translations/zh_CN/core-api/mm-api.rst2
-rw-r--r--Documentation/translations/zh_CN/core-api/printk-basics.rst2
-rw-r--r--Documentation/translations/zh_CN/core-api/printk-formats.rst3
-rw-r--r--Documentation/translations/zh_CN/core-api/symbol-namespaces.rst49
-rw-r--r--Documentation/translations/zh_CN/core-api/this_cpu_ops.rst285
-rw-r--r--Documentation/translations/zh_CN/core-api/unaligned-memory-access.rst2
-rw-r--r--Documentation/translations/zh_CN/core-api/union_find.rst92
-rw-r--r--Documentation/translations/zh_CN/core-api/workqueue.rst402
-rw-r--r--Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst3
-rw-r--r--Documentation/translations/zh_CN/dev-tools/gcov.rst8
-rw-r--r--Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst40
-rw-r--r--Documentation/translations/zh_CN/dev-tools/index.rst17
-rw-r--r--Documentation/translations/zh_CN/dev-tools/kasan.rst124
-rw-r--r--Documentation/translations/zh_CN/dev-tools/kcov.rst359
-rw-r--r--Documentation/translations/zh_CN/dev-tools/kcsan.rst320
-rw-r--r--Documentation/translations/zh_CN/dev-tools/kmemleak.rst229
-rw-r--r--Documentation/translations/zh_CN/dev-tools/kmsan.rst392
-rw-r--r--Documentation/translations/zh_CN/dev-tools/testing-overview.rst31
-rw-r--r--Documentation/translations/zh_CN/dev-tools/ubsan.rst88
-rw-r--r--Documentation/translations/zh_CN/devicetree/changesets.rst2
-rw-r--r--Documentation/translations/zh_CN/devicetree/dynamic-resolution-notes.rst2
-rw-r--r--Documentation/translations/zh_CN/devicetree/kernel-api.rst2
-rw-r--r--Documentation/translations/zh_CN/devicetree/of_unittest.rst2
-rw-r--r--Documentation/translations/zh_CN/devicetree/overlay-notes.rst14
-rw-r--r--Documentation/translations/zh_CN/devicetree/usage-model.rst2
-rw-r--r--Documentation/translations/zh_CN/disclaimer-zh_CN.rst8
-rw-r--r--Documentation/translations/zh_CN/doc-guide/checktransupdate.rst55
-rw-r--r--Documentation/translations/zh_CN/doc-guide/contributing.rst2
-rw-r--r--Documentation/translations/zh_CN/doc-guide/index.rst3
-rw-r--r--Documentation/translations/zh_CN/doc-guide/parse-headers.rst8
-rw-r--r--Documentation/translations/zh_CN/doc-guide/sphinx.rst4
-rw-r--r--Documentation/translations/zh_CN/driver-api/gpio/index.rst7
-rw-r--r--Documentation/translations/zh_CN/driver-api/gpio/legacy.rst694
-rw-r--r--Documentation/translations/zh_CN/driver-api/index.rst7
-rw-r--r--Documentation/translations/zh_CN/driver-api/phy/index.rst20
-rw-r--r--Documentation/translations/zh_CN/driver-api/phy/phy.rst212
-rw-r--r--Documentation/translations/zh_CN/filesystems/dnotify.rst67
-rw-r--r--Documentation/translations/zh_CN/filesystems/gfs2-glocks.rst211
-rw-r--r--Documentation/translations/zh_CN/filesystems/gfs2-uevents.rst97
-rw-r--r--Documentation/translations/zh_CN/filesystems/gfs2.rst57
-rw-r--r--Documentation/translations/zh_CN/filesystems/index.rst17
-rw-r--r--Documentation/translations/zh_CN/filesystems/inotify.rst80
-rw-r--r--Documentation/translations/zh_CN/filesystems/sysfs.txt6
-rw-r--r--Documentation/translations/zh_CN/filesystems/ubifs-authentication.rst354
-rw-r--r--Documentation/translations/zh_CN/filesystems/ubifs.rst114
-rw-r--r--Documentation/translations/zh_CN/glossary.rst37
-rw-r--r--Documentation/translations/zh_CN/how-to.rst473
-rw-r--r--Documentation/translations/zh_CN/index.rst196
-rw-r--r--Documentation/translations/zh_CN/kbuild/gcc-plugins.rst126
-rw-r--r--Documentation/translations/zh_CN/kbuild/headers_install.rst39
-rw-r--r--Documentation/translations/zh_CN/kbuild/index.rst36
-rw-r--r--Documentation/translations/zh_CN/kbuild/kbuild.rst325
-rw-r--r--Documentation/translations/zh_CN/kbuild/kconfig.rst259
-rw-r--r--Documentation/translations/zh_CN/kbuild/llvm.rst203
-rw-r--r--Documentation/translations/zh_CN/kbuild/reproducible-builds.rst114
-rw-r--r--Documentation/translations/zh_CN/loongarch/features.rst8
-rw-r--r--Documentation/translations/zh_CN/loongarch/index.rst26
-rw-r--r--Documentation/translations/zh_CN/loongarch/introduction.rst353
-rw-r--r--Documentation/translations/zh_CN/loongarch/irq-chip-model.rst157
-rw-r--r--Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst2
-rw-r--r--Documentation/translations/zh_CN/mips/booting.rst34
-rw-r--r--Documentation/translations/zh_CN/mips/features.rst13
-rw-r--r--Documentation/translations/zh_CN/mips/index.rst29
-rw-r--r--Documentation/translations/zh_CN/mips/ingenic-tcu.rst72
-rw-r--r--Documentation/translations/zh_CN/mm/active_mm.rst7
-rw-r--r--Documentation/translations/zh_CN/mm/balance.rst2
-rw-r--r--Documentation/translations/zh_CN/mm/damon/faq.rst17
-rw-r--r--Documentation/translations/zh_CN/mm/frontswap.rst196
-rw-r--r--Documentation/translations/zh_CN/mm/highmem.rst20
-rw-r--r--Documentation/translations/zh_CN/mm/hmm.rst12
-rw-r--r--Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst25
-rw-r--r--Documentation/translations/zh_CN/mm/index.rst4
-rw-r--r--Documentation/translations/zh_CN/mm/ksm.rst2
-rw-r--r--Documentation/translations/zh_CN/mm/numa.rst2
-rw-r--r--Documentation/translations/zh_CN/mm/overcommit-accounting.rst3
-rw-r--r--Documentation/translations/zh_CN/mm/page_frags.rst2
-rw-r--r--Documentation/translations/zh_CN/mm/page_migration.rst8
-rw-r--r--Documentation/translations/zh_CN/mm/page_owner.rst75
-rw-r--r--Documentation/translations/zh_CN/mm/page_table_check.rst13
-rw-r--r--Documentation/translations/zh_CN/mm/page_tables.rst221
-rw-r--r--Documentation/translations/zh_CN/mm/physical_memory.rst356
-rw-r--r--Documentation/translations/zh_CN/mm/split_page_table_lock.rst14
-rw-r--r--Documentation/translations/zh_CN/mm/z3fold.rst31
-rw-r--r--Documentation/translations/zh_CN/networking/alias.rst56
-rw-r--r--Documentation/translations/zh_CN/networking/generic-hdlc.rst176
-rw-r--r--Documentation/translations/zh_CN/networking/index.rst159
-rw-r--r--Documentation/translations/zh_CN/networking/mptcp-sysctl.rst139
-rw-r--r--Documentation/translations/zh_CN/networking/msg_zerocopy.rst223
-rw-r--r--Documentation/translations/zh_CN/networking/napi.rst362
-rw-r--r--Documentation/translations/zh_CN/networking/netif-msg.rst92
-rw-r--r--Documentation/translations/zh_CN/networking/netmem.rst92
-rw-r--r--Documentation/translations/zh_CN/networking/timestamping.rst674
-rw-r--r--Documentation/translations/zh_CN/networking/vxlan.rst85
-rw-r--r--Documentation/translations/zh_CN/networking/xfrm_proc.rst126
-rw-r--r--Documentation/translations/zh_CN/openrisc/index.rst32
-rw-r--r--Documentation/translations/zh_CN/openrisc/openrisc_port.rst127
-rw-r--r--Documentation/translations/zh_CN/openrisc/todo.rst23
-rw-r--r--Documentation/translations/zh_CN/parisc/debugging.rst45
-rw-r--r--Documentation/translations/zh_CN/parisc/index.rst31
-rw-r--r--Documentation/translations/zh_CN/parisc/registers.rst156
-rw-r--r--Documentation/translations/zh_CN/power/energy-model.rst36
-rw-r--r--Documentation/translations/zh_CN/power/opp.rst2
-rw-r--r--Documentation/translations/zh_CN/process/1.Intro.rst10
-rw-r--r--Documentation/translations/zh_CN/process/2.Process.rst9
-rw-r--r--Documentation/translations/zh_CN/process/3.Early-stage.rst2
-rw-r--r--Documentation/translations/zh_CN/process/4.Coding.rst4
-rw-r--r--Documentation/translations/zh_CN/process/5.Posting.rst15
-rw-r--r--Documentation/translations/zh_CN/process/6.Followthrough.rst5
-rw-r--r--Documentation/translations/zh_CN/process/7.AdvancedTopics.rst16
-rw-r--r--Documentation/translations/zh_CN/process/coding-style.rst17
-rw-r--r--Documentation/translations/zh_CN/process/cve.rst89
-rw-r--r--Documentation/translations/zh_CN/process/development-process.rst5
-rw-r--r--Documentation/translations/zh_CN/process/email-clients.rst17
-rw-r--r--Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst2
-rw-r--r--Documentation/translations/zh_CN/process/howto.rst8
-rw-r--r--Documentation/translations/zh_CN/process/index.rst56
-rw-r--r--Documentation/translations/zh_CN/process/magic-number.rst140
-rw-r--r--Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst789
-rw-r--r--Documentation/translations/zh_CN/process/programming-language.rst78
-rw-r--r--Documentation/translations/zh_CN/process/researcher-guidelines.rst129
-rw-r--r--Documentation/translations/zh_CN/process/security-bugs.rst84
-rw-r--r--Documentation/translations/zh_CN/process/submit-checklist.rst7
-rw-r--r--Documentation/translations/zh_CN/process/submitting-patches.rst29
-rw-r--r--Documentation/translations/zh_CN/riscv/boot-image-header.rst69
-rw-r--r--Documentation/translations/zh_CN/riscv/index.rst30
-rw-r--r--Documentation/translations/zh_CN/riscv/patch-acceptance.rst33
-rw-r--r--Documentation/translations/zh_CN/riscv/vm-layout.rst104
-rw-r--r--Documentation/translations/zh_CN/rust/arch-support.rst27
-rw-r--r--Documentation/translations/zh_CN/rust/coding-guidelines.rst204
-rw-r--r--Documentation/translations/zh_CN/rust/general-information.rst76
-rw-r--r--Documentation/translations/zh_CN/rust/index.rst59
-rw-r--r--Documentation/translations/zh_CN/rust/quick-start.rst229
-rw-r--r--Documentation/translations/zh_CN/rust/testing.rst215
-rw-r--r--Documentation/translations/zh_CN/scheduler/sched-arch.rst7
-rw-r--r--Documentation/translations/zh_CN/scheduler/sched-capacity.rst4
-rw-r--r--Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst8
-rw-r--r--Documentation/translations/zh_CN/scheduler/sched-domains.rst10
-rw-r--r--Documentation/translations/zh_CN/scheduler/sched-stats.rst30
-rw-r--r--Documentation/translations/zh_CN/scheduler/schedutil.rst7
-rw-r--r--Documentation/translations/zh_CN/scsi/index.rst92
-rw-r--r--Documentation/translations/zh_CN/scsi/libsas.rst425
-rw-r--r--Documentation/translations/zh_CN/scsi/link_power_management_policy.rst32
-rw-r--r--Documentation/translations/zh_CN/scsi/scsi-parameters.rst118
-rw-r--r--Documentation/translations/zh_CN/scsi/scsi.rst48
-rw-r--r--Documentation/translations/zh_CN/scsi/scsi_eh.rst482
-rw-r--r--Documentation/translations/zh_CN/scsi/scsi_mid_low_api.rst1174
-rw-r--r--Documentation/translations/zh_CN/scsi/sd-parameters.rst38
-rw-r--r--Documentation/translations/zh_CN/scsi/wd719x.rst35
-rw-r--r--Documentation/translations/zh_CN/security/IMA-templates.rst97
-rw-r--r--Documentation/translations/zh_CN/security/SCTP.rst317
-rw-r--r--Documentation/translations/zh_CN/security/credentials.rst479
-rw-r--r--Documentation/translations/zh_CN/security/digsig.rst103
-rw-r--r--Documentation/translations/zh_CN/security/index.rst34
-rw-r--r--Documentation/translations/zh_CN/security/ipe.rst398
-rw-r--r--Documentation/translations/zh_CN/security/keys/index.rst22
-rw-r--r--Documentation/translations/zh_CN/security/landlock.rst123
-rw-r--r--Documentation/translations/zh_CN/security/lsm-development.rst19
-rw-r--r--Documentation/translations/zh_CN/security/lsm.rst95
-rw-r--r--Documentation/translations/zh_CN/security/sak.rst86
-rw-r--r--Documentation/translations/zh_CN/security/secrets/coco.rst96
-rw-r--r--Documentation/translations/zh_CN/security/secrets/index.rst14
-rw-r--r--Documentation/translations/zh_CN/security/self-protection.rst271
-rw-r--r--Documentation/translations/zh_CN/security/siphash.rst195
-rw-r--r--Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst209
-rw-r--r--Documentation/translations/zh_CN/security/tpm/index.rst20
-rw-r--r--Documentation/translations/zh_CN/security/tpm/tpm-security.rst151
-rw-r--r--Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst49
-rw-r--r--Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst31
-rw-r--r--Documentation/translations/zh_CN/security/tpm/tpm_tis.rst43
-rw-r--r--Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst51
-rw-r--r--Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst114
-rw-r--r--Documentation/translations/zh_CN/staging/index.rst26
-rw-r--r--Documentation/translations/zh_CN/staging/speculation.rst85
-rw-r--r--Documentation/translations/zh_CN/staging/xz.rst100
-rw-r--r--Documentation/translations/zh_CN/subsystem-apis.rst109
-rw-r--r--Documentation/translations/zh_CN/userspace-api/accelerators/ocxl.rst168
-rw-r--r--Documentation/translations/zh_CN/userspace-api/ebpf/index.rst22
-rw-r--r--Documentation/translations/zh_CN/userspace-api/ebpf/syscall.rst29
-rw-r--r--Documentation/translations/zh_CN/userspace-api/futex2.rst80
-rw-r--r--Documentation/translations/zh_CN/userspace-api/index.rst47
-rw-r--r--Documentation/translations/zh_CN/userspace-api/no_new_privs.rst57
-rw-r--r--Documentation/translations/zh_CN/userspace-api/seccomp_filter.rst293
-rw-r--r--Documentation/translations/zh_CN/userspace-api/sysfs-platform_profile.rst40
-rw-r--r--Documentation/translations/zh_CN/video4linux/v4l2-framework.txt28
-rw-r--r--Documentation/translations/zh_CN/virt/guest-halt-polling.rst2
-rw-r--r--Documentation/translations/zh_TW/IRQ.txt8
-rw-r--r--Documentation/translations/zh_TW/admin-guide/README.rst168
-rw-r--r--Documentation/translations/zh_TW/admin-guide/bootconfig.rst294
-rw-r--r--Documentation/translations/zh_TW/admin-guide/bug-bisect.rst12
-rw-r--r--Documentation/translations/zh_TW/admin-guide/bug-hunting.rst54
-rw-r--r--Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst6
-rw-r--r--Documentation/translations/zh_TW/admin-guide/cpu-load.rst10
-rw-r--r--Documentation/translations/zh_TW/admin-guide/cputopology.rst97
-rw-r--r--Documentation/translations/zh_TW/admin-guide/index.rst137
-rw-r--r--Documentation/translations/zh_TW/admin-guide/init.rst38
-rw-r--r--Documentation/translations/zh_TW/admin-guide/lockup-watchdogs.rst67
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/damon/index.rst30
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/damon/lru_sort.rst264
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/damon/reclaim.rst229
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/damon/start.rst125
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst346
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/index.rst50
-rw-r--r--Documentation/translations/zh_TW/admin-guide/mm/ksm.rst199
-rw-r--r--Documentation/translations/zh_TW/admin-guide/reporting-issues.rst729
-rw-r--r--Documentation/translations/zh_TW/admin-guide/reporting-regressions.rst371
-rw-r--r--Documentation/translations/zh_TW/admin-guide/security-bugs.rst30
-rw-r--r--Documentation/translations/zh_TW/admin-guide/sysrq.rst281
-rw-r--r--Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst86
-rw-r--r--Documentation/translations/zh_TW/admin-guide/unicode.rst12
-rw-r--r--Documentation/translations/zh_TW/arch/arm/Booting176
-rw-r--r--Documentation/translations/zh_TW/arch/arm/kernel_user_helpers.txt285
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/amu.rst104
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/booting.txt251
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst244
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst49
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/index.rst23
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt77
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/memory.txt119
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/perf.rst88
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt79
-rw-r--r--Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt57
-rw-r--r--Documentation/translations/zh_TW/arch/index.rst29
-rw-r--r--Documentation/translations/zh_TW/arch/loongarch/booting.rst49
-rw-r--r--Documentation/translations/zh_TW/arch/loongarch/features.rst9
-rw-r--r--Documentation/translations/zh_TW/arch/loongarch/index.rst28
-rw-r--r--Documentation/translations/zh_TW/arch/loongarch/introduction.rst354
-rw-r--r--Documentation/translations/zh_TW/arch/loongarch/irq-chip-model.rst158
-rw-r--r--Documentation/translations/zh_TW/arch/mips/booting.rst35
-rw-r--r--Documentation/translations/zh_TW/arch/mips/features.rst14
-rw-r--r--Documentation/translations/zh_TW/arch/mips/index.rst30
-rw-r--r--Documentation/translations/zh_TW/arch/mips/ingenic-tcu.rst73
-rw-r--r--Documentation/translations/zh_TW/arch/openrisc/index.rst33
-rw-r--r--Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst128
-rw-r--r--Documentation/translations/zh_TW/arch/openrisc/todo.rst24
-rw-r--r--Documentation/translations/zh_TW/arch/parisc/debugging.rst46
-rw-r--r--Documentation/translations/zh_TW/arch/parisc/index.rst32
-rw-r--r--Documentation/translations/zh_TW/arch/parisc/registers.rst157
-rw-r--r--Documentation/translations/zh_TW/arm64/amu.rst104
-rw-r--r--Documentation/translations/zh_TW/arm64/booting.txt251
-rw-r--r--Documentation/translations/zh_TW/arm64/elf_hwcaps.rst244
-rw-r--r--Documentation/translations/zh_TW/arm64/hugetlbpage.rst49
-rw-r--r--Documentation/translations/zh_TW/arm64/index.rst23
-rw-r--r--Documentation/translations/zh_TW/arm64/legacy_instructions.txt77
-rw-r--r--Documentation/translations/zh_TW/arm64/memory.txt119
-rw-r--r--Documentation/translations/zh_TW/arm64/perf.rst88
-rw-r--r--Documentation/translations/zh_TW/arm64/silicon-errata.txt79
-rw-r--r--Documentation/translations/zh_TW/arm64/tagged-pointers.txt57
-rw-r--r--Documentation/translations/zh_TW/cpu-freq/core.rst38
-rw-r--r--Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst157
-rw-r--r--Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst52
-rw-r--r--Documentation/translations/zh_TW/cpu-freq/index.rst13
-rw-r--r--Documentation/translations/zh_TW/dev-tools/gcov.rst265
-rw-r--r--Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst164
-rw-r--r--Documentation/translations/zh_TW/dev-tools/index.rst43
-rw-r--r--Documentation/translations/zh_TW/dev-tools/kasan.rst460
-rw-r--r--Documentation/translations/zh_TW/dev-tools/sparse.rst91
-rw-r--r--Documentation/translations/zh_TW/dev-tools/testing-overview.rst162
-rw-r--r--Documentation/translations/zh_TW/disclaimer-zh_TW.rst2
-rw-r--r--Documentation/translations/zh_TW/filesystems/debugfs.rst49
-rw-r--r--Documentation/translations/zh_TW/filesystems/index.rst4
-rw-r--r--Documentation/translations/zh_TW/filesystems/sysfs.txt22
-rw-r--r--Documentation/translations/zh_TW/filesystems/tmpfs.rst35
-rw-r--r--Documentation/translations/zh_TW/filesystems/virtiofs.rst11
-rw-r--r--Documentation/translations/zh_TW/gpio.txt651
-rw-r--r--Documentation/translations/zh_TW/index.rst161
-rw-r--r--Documentation/translations/zh_TW/io_ordering.txt8
-rw-r--r--Documentation/translations/zh_TW/process/1.Intro.rst80
-rw-r--r--Documentation/translations/zh_TW/process/2.Process.rst134
-rw-r--r--Documentation/translations/zh_TW/process/3.Early-stage.rst48
-rw-r--r--Documentation/translations/zh_TW/process/4.Coding.rst110
-rw-r--r--Documentation/translations/zh_TW/process/5.Posting.rst84
-rw-r--r--Documentation/translations/zh_TW/process/6.Followthrough.rst48
-rw-r--r--Documentation/translations/zh_TW/process/7.AdvancedTopics.rst60
-rw-r--r--Documentation/translations/zh_TW/process/8.Conclusion.rst16
-rw-r--r--Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst54
-rw-r--r--Documentation/translations/zh_TW/process/code-of-conduct.rst20
-rw-r--r--Documentation/translations/zh_TW/process/coding-style.rst409
-rw-r--r--Documentation/translations/zh_TW/process/development-process.rst8
-rw-r--r--Documentation/translations/zh_TW/process/email-clients.rst279
-rw-r--r--Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst80
-rw-r--r--Documentation/translations/zh_TW/process/howto.rst8
-rw-r--r--Documentation/translations/zh_TW/process/index.rst7
-rw-r--r--Documentation/translations/zh_TW/process/kernel-driver-statement.rst4
-rw-r--r--Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst2
-rw-r--r--Documentation/translations/zh_TW/process/license-rules.rst56
-rw-r--r--Documentation/translations/zh_TW/process/magic-number.rst78
-rw-r--r--Documentation/translations/zh_TW/process/management-style.rst62
-rw-r--r--Documentation/translations/zh_TW/process/programming-language.rst2
-rw-r--r--Documentation/translations/zh_TW/process/stable-api-nonsense.rst88
-rw-r--r--Documentation/translations/zh_TW/process/stable-kernel-rules.rst38
-rw-r--r--Documentation/translations/zh_TW/process/submit-checklist.rst99
-rw-r--r--Documentation/translations/zh_TW/process/submitting-patches.rst749
-rw-r--r--Documentation/translations/zh_TW/process/volatile-considered-harmful.rst34
-rw-r--r--Documentation/translations/zh_TW/sparse.txt91
-rw-r--r--Documentation/usb/CREDITS8
-rw-r--r--Documentation/usb/authorization.rst9
-rw-r--r--Documentation/usb/chipidea.rst19
-rw-r--r--Documentation/usb/functionfs-desc.rst39
-rw-r--r--Documentation/usb/functionfs.rst40
-rw-r--r--Documentation/usb/gadget-testing.rst207
-rw-r--r--Documentation/usb/gadget_configfs.rst53
-rw-r--r--Documentation/usb/gadget_multi.rst2
-rw-r--r--Documentation/usb/gadget_uvc.rst380
-rw-r--r--Documentation/usb/index.rst2
-rw-r--r--Documentation/usb/mass-storage.rst2
-rw-r--r--Documentation/usb/raw-gadget.rst3
-rw-r--r--Documentation/usb/usbip_protocol.rst25
-rw-r--r--Documentation/userspace-api/ELF.rst34
-rw-r--r--Documentation/userspace-api/accelerators/ocxl.rst7
-rw-r--r--Documentation/userspace-api/check_exec.rst144
-rw-r--r--Documentation/userspace-api/dcdbas.rst (renamed from Documentation/driver-api/dcdbas.rst)0
-rw-r--r--Documentation/userspace-api/dma-buf-alloc-exchange.rst389
-rw-r--r--Documentation/userspace-api/dma-buf-heaps.rst67
-rw-r--r--Documentation/userspace-api/fwctl/fwctl-cxl.rst142
-rw-r--r--Documentation/userspace-api/fwctl/fwctl.rst286
-rw-r--r--Documentation/userspace-api/fwctl/index.rst14
-rw-r--r--Documentation/userspace-api/fwctl/pds_fwctl.rst46
-rw-r--r--Documentation/userspace-api/gpio/chardev.rst116
-rw-r--r--Documentation/userspace-api/gpio/chardev_v1.rst131
-rw-r--r--Documentation/userspace-api/gpio/error-codes.rst79
-rw-r--r--Documentation/userspace-api/gpio/gpio-get-chipinfo-ioctl.rst41
-rw-r--r--Documentation/userspace-api/gpio/gpio-get-lineevent-ioctl.rst84
-rw-r--r--Documentation/userspace-api/gpio/gpio-get-linehandle-ioctl.rst125
-rw-r--r--Documentation/userspace-api/gpio/gpio-get-lineinfo-ioctl.rst54
-rw-r--r--Documentation/userspace-api/gpio/gpio-get-lineinfo-unwatch-ioctl.rst49
-rw-r--r--Documentation/userspace-api/gpio/gpio-get-lineinfo-watch-ioctl.rst74
-rw-r--r--Documentation/userspace-api/gpio/gpio-handle-get-line-values-ioctl.rst63
-rw-r--r--Documentation/userspace-api/gpio/gpio-handle-set-config-ioctl.rst66
-rw-r--r--Documentation/userspace-api/gpio/gpio-handle-set-line-values-ioctl.rst55
-rw-r--r--Documentation/userspace-api/gpio/gpio-lineevent-data-read.rst89
-rw-r--r--Documentation/userspace-api/gpio/gpio-lineinfo-changed-read.rst87
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-get-line-ioctl.rst152
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-ioctl.rst50
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-get-lineinfo-watch-ioctl.rst67
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-line-event-read.rst88
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-line-get-values-ioctl.rst58
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-line-set-config-ioctl.rst61
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-line-set-values-ioctl.rst54
-rw-r--r--Documentation/userspace-api/gpio/gpio-v2-lineinfo-changed-read.rst81
-rw-r--r--Documentation/userspace-api/gpio/index.rst18
-rw-r--r--Documentation/userspace-api/gpio/obsolete.rst11
-rw-r--r--Documentation/userspace-api/gpio/sysfs.rst (renamed from Documentation/admin-guide/gpio/sysfs.rst)40
-rw-r--r--Documentation/userspace-api/index.rst52
-rw-r--r--Documentation/userspace-api/ioctl/ioctl-number.rst555
-rw-r--r--Documentation/userspace-api/iommu.rst209
-rw-r--r--Documentation/userspace-api/iommufd.rst384
-rw-r--r--Documentation/userspace-api/isapnp.rst15
-rw-r--r--Documentation/userspace-api/landlock.rst401
-rw-r--r--Documentation/userspace-api/liveupdate.rst20
-rw-r--r--Documentation/userspace-api/lsm.rst73
-rw-r--r--Documentation/userspace-api/media/Makefile63
-rw-r--r--Documentation/userspace-api/media/cec/cec-api.rst9
-rw-r--r--Documentation/userspace-api/media/cec/cec-func-open.rst4
-rw-r--r--Documentation/userspace-api/media/cec/cec-header.rst15
-rw-r--r--Documentation/userspace-api/media/cec/cec-ioc-adap-g-caps.rst6
-rw-r--r--Documentation/userspace-api/media/cec/cec-ioc-receive.rst15
-rw-r--r--Documentation/userspace-api/media/cec/cec-pin-error-inj.rst44
-rw-r--r--Documentation/userspace-api/media/cec/cec.h.rst.exceptions (renamed from Documentation/userspace-api/media/cec.h.rst.exceptions)5
-rw-r--r--Documentation/userspace-api/media/dmx.h.rst.exceptions66
-rw-r--r--Documentation/userspace-api/media/drivers/aspeed-video.rst65
-rw-r--r--Documentation/userspace-api/media/drivers/camera-sensor.rst106
-rw-r--r--Documentation/userspace-api/media/drivers/ccs.rst6
-rw-r--r--Documentation/userspace-api/media/drivers/cx2341x-uapi.rst2
-rw-r--r--Documentation/userspace-api/media/drivers/index.rst14
-rw-r--r--Documentation/userspace-api/media/drivers/mali-c55.rst55
-rw-r--r--Documentation/userspace-api/media/drivers/meye-uapi.rst53
-rw-r--r--Documentation/userspace-api/media/drivers/npcm-video.rst66
-rw-r--r--Documentation/userspace-api/media/drivers/thp7312.rst39
-rw-r--r--Documentation/userspace-api/media/drivers/uvcvideo.rst64
-rw-r--r--Documentation/userspace-api/media/drivers/vgxy61.rst25
-rw-r--r--Documentation/userspace-api/media/dvb/ca.h.rst.exceptions (renamed from Documentation/userspace-api/media/ca.h.rst.exceptions)0
-rw-r--r--Documentation/userspace-api/media/dvb/dmx.h.rst.exceptions62
-rw-r--r--Documentation/userspace-api/media/dvb/dmx_types.rst1
-rw-r--r--Documentation/userspace-api/media/dvb/dvbapi.rst7
-rw-r--r--Documentation/userspace-api/media/dvb/fe-diseqc-send-burst.rst2
-rw-r--r--Documentation/userspace-api/media/dvb/fe-set-tone.rst2
-rw-r--r--Documentation/userspace-api/media/dvb/fe-set-voltage.rst2
-rw-r--r--Documentation/userspace-api/media/dvb/fe_property_parameters.rst48
-rw-r--r--Documentation/userspace-api/media/dvb/frontend-property-terrestrial-systems.rst2
-rw-r--r--Documentation/userspace-api/media/dvb/frontend.h.rst.exceptions (renamed from Documentation/userspace-api/media/frontend.h.rst.exceptions)37
-rw-r--r--Documentation/userspace-api/media/dvb/frontend_f_open.rst2
-rw-r--r--Documentation/userspace-api/media/dvb/headers.rst48
-rw-r--r--Documentation/userspace-api/media/dvb/intro.rst4
-rw-r--r--Documentation/userspace-api/media/dvb/legacy_dvb_apis.rst1
-rw-r--r--Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst1642
-rw-r--r--Documentation/userspace-api/media/dvb/legacy_dvb_decoder_api.rst61
-rw-r--r--Documentation/userspace-api/media/dvb/legacy_dvb_osd.rst883
-rw-r--r--Documentation/userspace-api/media/dvb/legacy_dvb_video.rst2430
-rw-r--r--Documentation/userspace-api/media/dvb/net.h.rst.exceptions (renamed from Documentation/userspace-api/media/net.h.rst.exceptions)0
-rw-r--r--Documentation/userspace-api/media/gen-errors.rst4
-rw-r--r--Documentation/userspace-api/media/glossary.rst12
-rw-r--r--Documentation/userspace-api/media/index.rst7
-rw-r--r--Documentation/userspace-api/media/mediactl/media-controller.rst7
-rw-r--r--Documentation/userspace-api/media/mediactl/media-header.rst15
-rw-r--r--Documentation/userspace-api/media/mediactl/media-types.rst11
-rw-r--r--Documentation/userspace-api/media/mediactl/media.h.rst.exceptions (renamed from Documentation/userspace-api/media/media.h.rst.exceptions)3
-rw-r--r--Documentation/userspace-api/media/rc/lirc-header.rst18
-rw-r--r--Documentation/userspace-api/media/rc/lirc-set-send-duty-cycle.rst2
-rw-r--r--Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst2
-rw-r--r--Documentation/userspace-api/media/rc/lirc.h.rst.exceptions (renamed from Documentation/userspace-api/media/lirc.h.rst.exceptions)0
-rw-r--r--Documentation/userspace-api/media/rc/rc-protos.rst6
-rw-r--r--Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst2
-rw-r--r--Documentation/userspace-api/media/rc/rc-tables.rst2
-rw-r--r--Documentation/userspace-api/media/rc/remote_controllers.rst7
-rw-r--r--Documentation/userspace-api/media/v4l/app-pri.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/audio.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/biblio.rst23
-rw-r--r--Documentation/userspace-api/media/v4l/buffer.rst52
-rw-r--r--Documentation/userspace-api/media/v4l/capture-example.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/capture.c.rst7
-rw-r--r--Documentation/userspace-api/media/v4l/colorspaces-defs.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/colorspaces-details.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/colorspaces.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/common-defs.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/common.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/compat.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/control.rst11
-rw-r--r--Documentation/userspace-api/media/v4l/crop.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/depth-formats.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dev-decoder.rst17
-rw-r--r--Documentation/userspace-api/media/v4l/dev-encoder.rst25
-rw-r--r--Documentation/userspace-api/media/v4l/dev-event.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dev-mem2mem.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dev-meta.rst22
-rw-r--r--Documentation/userspace-api/media/v4l/dev-osd.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dev-overlay.rst11
-rw-r--r--Documentation/userspace-api/media/v4l/dev-radio.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dev-sdr.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dev-sliced-vbi.rst6
-rw-r--r--Documentation/userspace-api/media/v4l/dev-stateless-decoder.rst5
-rw-r--r--Documentation/userspace-api/media/v4l/dev-subdev.rst191
-rw-r--r--Documentation/userspace-api/media/v4l/dev-touch.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/devices.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/dv-timings.rst22
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-camera.rst12
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst1227
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst15
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-colorimetry.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-detect.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-dv.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-flash.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-fm-rx.rst12
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-fm-tx.rst22
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst3
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-jpeg.rst3
-rw-r--r--Documentation/userspace-api/media/v4l/ext-ctrls-rf-tuner.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/extended-controls.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/field-order.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/fourcc.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/func-open.rst4
-rw-r--r--Documentation/userspace-api/media/v4l/hist-v4l2.rst4
-rw-r--r--Documentation/userspace-api/media/v4l/hsv-formats.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/libv4l-introduction.rst4
-rw-r--r--Documentation/userspace-api/media/v4l/libv4l.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/meta-formats.rst22
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-arm-mali-c55.rst84
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-c3-isp.rst87
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-d4xx.rst253
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-generic.rst341
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-intel-ipu3.rst82
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-pisp-be.rst57
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-pisp-fe.rst40
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst90
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-uvc-msxu-1-5.rst23
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-uvc.rst54
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-vivid.rst37
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-vsp1-hgo.rst169
-rw-r--r--Documentation/userspace-api/media/v4l/metafmt-vsp1-hgt.rst130
-rw-r--r--Documentation/userspace-api/media/v4l/mmap.rst2
-rw-r--r--Documentation/userspace-api/media/v4l/mt2110t.svg315
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-bayer.rst3
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-cnf4.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-compressed.rst42
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-indexed.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-intro.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-inzi.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-m420.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-d4xx.rst213
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.rst81
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst50
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-uvc.rst51
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-vivid.rst36
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgo.rst168
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-meta-vsp1-hgt.rst129
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-packed-hsv.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst78
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-rawnn-cru.rst143
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-reserved.rst25
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-rgb.rst288
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-cs08.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-cs14le.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-cu08.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-cu16le.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-pcu16be.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-pcu18be.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-pcu20be.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-sdr-ru12le.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb10-ipu3.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb10.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb10alaw8.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb10dpcm8.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb10p.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb12.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb12p.rst9
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb14.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb14p.rst3
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb16.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb8-pisp-comp.rst75
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-srggb8.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-tch-td08.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-tch-td16.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-tch-tu08.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-tch-tu16.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-uv8.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-v4l2-mplane.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-y12i.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-y16i.rst74
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-y8i.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst74
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst408
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt-z16.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/pixfmt.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/planar-apis.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/querycap.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/sdr-formats.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selection-api-configuration.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selection-api-examples.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selection-api-intro.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selection-api-targets.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selection-api-vs-crop-api.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selection-api.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/selections-common.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/standard.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/subdev-formats.rst1066
-rw-r--r--Documentation/userspace-api/media/v4l/tch-formats.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/tuner.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/user-func.rst4
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2-isp.rst67
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2-selection-flags.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2-selection-targets.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2.rst10
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2grab-example.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/v4l2grab.c.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/video.rst1
-rw-r--r--Documentation/userspace-api/media/v4l/videodev.rst13
-rw-r--r--Documentation/userspace-api/media/v4l/videodev2.h.rst.exceptions614
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst8
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-cropcap.rst2
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst25
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst60
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst52
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-querycap.rst11
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst46
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-remove-bufs.rst86
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst42
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-interval.rst14
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst56
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst51
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst103
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-g-crop.rst18
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-g-fmt.rst10
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-g-frame-interval.rst23
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-g-routing.rst164
-rw-r--r--Documentation/userspace-api/media/v4l/vidioc-subdev-g-selection.rst12
-rw-r--r--Documentation/userspace-api/media/v4l/yuv-formats.rst2
-rw-r--r--Documentation/userspace-api/media/videodev2.h.rst.exceptions599
-rw-r--r--Documentation/userspace-api/mfd_noexec.rst86
-rw-r--r--Documentation/userspace-api/mseal.rst209
-rw-r--r--Documentation/userspace-api/netlink/c-code-gen.rst109
-rw-r--r--Documentation/userspace-api/netlink/genetlink-legacy.rst292
-rw-r--r--Documentation/userspace-api/netlink/index.rst9
-rw-r--r--Documentation/userspace-api/netlink/intro-specs.rst159
-rw-r--r--Documentation/userspace-api/netlink/intro.rst8
-rw-r--r--Documentation/userspace-api/netlink/netlink-raw.rst194
-rw-r--r--Documentation/userspace-api/netlink/specs.rst467
-rw-r--r--Documentation/userspace-api/ntsync.rst385
-rw-r--r--Documentation/userspace-api/perf_ring_buffer.rst830
-rw-r--r--Documentation/userspace-api/seccomp_filter.rst2
-rw-r--r--Documentation/userspace-api/spec_ctrl.rst6
-rw-r--r--Documentation/userspace-api/sysfs-platform_profile.rst44
-rw-r--r--Documentation/userspace-api/tee.rst39
-rw-r--r--Documentation/virt/coco/sev-guest.rst102
-rw-r--r--Documentation/virt/coco/tdx-guest.rst52
-rw-r--r--Documentation/virt/guest-halt-polling.rst2
-rw-r--r--Documentation/virt/hyperv/clocks.rst23
-rw-r--r--Documentation/virt/hyperv/coco.rst397
-rw-r--r--Documentation/virt/hyperv/hibernation.rst336
-rw-r--r--Documentation/virt/hyperv/index.rst3
-rw-r--r--Documentation/virt/hyperv/overview.rst22
-rw-r--r--Documentation/virt/hyperv/vmbus.rst171
-rw-r--r--Documentation/virt/hyperv/vpci.rst316
-rw-r--r--Documentation/virt/index.rst7
-rw-r--r--Documentation/virt/kvm/api.rst2409
-rw-r--r--Documentation/virt/kvm/arm/fw-pseudo-registers.rst151
-rw-r--r--Documentation/virt/kvm/arm/hypercalls.rst337
-rw-r--r--Documentation/virt/kvm/arm/index.rst2
-rw-r--r--Documentation/virt/kvm/arm/ptp_kvm.rst38
-rw-r--r--Documentation/virt/kvm/arm/pvtime.rst14
-rw-r--r--Documentation/virt/kvm/arm/vcpu-features.rst48
-rw-r--r--Documentation/virt/kvm/devices/arm-vgic-its.rst10
-rw-r--r--Documentation/virt/kvm/devices/arm-vgic-v3.rst99
-rw-r--r--Documentation/virt/kvm/devices/arm-vgic.rst2
-rw-r--r--Documentation/virt/kvm/devices/s390_flic.rst4
-rw-r--r--Documentation/virt/kvm/devices/vcpu.rst40
-rw-r--r--Documentation/virt/kvm/devices/vfio.rst48
-rw-r--r--Documentation/virt/kvm/devices/vm.rst88
-rw-r--r--Documentation/virt/kvm/devices/xive.rst2
-rw-r--r--Documentation/virt/kvm/halt-polling.rst (renamed from Documentation/virt/kvm/x86/halt-polling.rst)37
-rw-r--r--Documentation/virt/kvm/index.rst2
-rw-r--r--Documentation/virt/kvm/locking.rst164
-rw-r--r--Documentation/virt/kvm/loongarch/hypercalls.rst89
-rw-r--r--Documentation/virt/kvm/loongarch/index.rst10
-rw-r--r--Documentation/virt/kvm/ppc-pv.rst8
-rw-r--r--Documentation/virt/kvm/review-checklist.rst95
-rw-r--r--Documentation/virt/kvm/s390/s390-diag.rst35
-rw-r--r--Documentation/virt/kvm/vcpu-requests.rst34
-rw-r--r--Documentation/virt/kvm/x86/amd-memory-encryption.rst214
-rw-r--r--Documentation/virt/kvm/x86/errata.rst50
-rw-r--r--Documentation/virt/kvm/x86/hypercalls.rst6
-rw-r--r--Documentation/virt/kvm/x86/index.rst2
-rw-r--r--Documentation/virt/kvm/x86/intel-tdx.rst268
-rw-r--r--Documentation/virt/kvm/x86/mmu.rst47
-rw-r--r--Documentation/virt/kvm/x86/msr.rst19
-rw-r--r--Documentation/virt/kvm/x86/running-nested-guests.rst4
-rw-r--r--Documentation/virt/paravirt_ops.rst16
-rw-r--r--Documentation/virt/uml/user_mode_linux_howto_v2.rst82
-rw-r--r--Documentation/w1/masters/ds2482.rst2
-rw-r--r--Documentation/w1/masters/index.rst3
-rw-r--r--Documentation/w1/masters/w1-uart.rst54
-rw-r--r--Documentation/w1/slaves/index.rst2
-rw-r--r--Documentation/w1/slaves/w1_therm.rst2
-rw-r--r--Documentation/w1/w1-generic.rst2
-rw-r--r--Documentation/w1/w1-netlink.rst4
-rw-r--r--Documentation/watchdog/convert_drivers_to_kernel_api.rst1
-rw-r--r--Documentation/watchdog/hpwdt.rst8
-rw-r--r--Documentation/watchdog/index.rst6
-rw-r--r--Documentation/watchdog/watchdog-api.rst2
-rw-r--r--Documentation/watchdog/watchdog-kernel-api.rst2
-rw-r--r--Documentation/watchdog/watchdog-parameters.rst10
-rw-r--r--Documentation/wmi/acpi-interface.rst106
-rw-r--r--Documentation/wmi/devices/alienware-wmi.rst322
-rw-r--r--Documentation/wmi/devices/dell-wmi-ddv.rst319
-rw-r--r--Documentation/wmi/devices/index.rst22
-rw-r--r--Documentation/wmi/devices/lenovo-wmi-gamezone.rst202
-rw-r--r--Documentation/wmi/devices/lenovo-wmi-other.rst108
-rw-r--r--Documentation/wmi/devices/msi-wmi-platform.rst198
-rw-r--r--Documentation/wmi/devices/uniwill-laptop.rst198
-rw-r--r--Documentation/wmi/devices/wmi-bmof.rst25
-rw-r--r--Documentation/wmi/driver-development-guide.rst192
-rw-r--r--Documentation/wmi/index.rst20
-rw-r--r--Documentation/x86/amd-memory-encryption.rst97
-rw-r--r--Documentation/x86/amd_hsmp.rst86
-rw-r--r--Documentation/x86/boot.rst1442
-rw-r--r--Documentation/x86/cpuinfo.rst154
-rw-r--r--Documentation/x86/features.rst3
-rw-r--r--Documentation/x86/index.rst44
-rw-r--r--Documentation/x86/iommu.rst151
-rw-r--r--Documentation/x86/resctrl.rst1304
-rw-r--r--Documentation/x86/tdx.rst218
-rw-r--r--Documentation/x86/topology.rst234
-rw-r--r--Documentation/x86/x86_64/boot-options.rst319
-rw-r--r--Documentation/x86/x86_64/index.rst17
-rw-r--r--Documentation/x86/x86_64/mm.rst157
-rw-r--r--Documentation/x86/x86_64/uefi.rst58
-rw-r--r--Documentation/x86/xstate.rst74
-rw-r--r--Documentation/xtensa/features.rst3
9412 files changed, 568744 insertions, 160882 deletions
diff --git a/Documentation/.renames.txt b/Documentation/.renames.txt
new file mode 100644
index 000000000000..c0bd5d3dc8b9
--- /dev/null
+++ b/Documentation/.renames.txt
@@ -0,0 +1,1191 @@
+80211/cfg80211 driver-api/80211/cfg80211
+80211/index driver-api/80211/index
+80211/introduction driver-api/80211/introduction
+80211/mac80211 driver-api/80211/mac80211
+80211/mac80211-advanced driver-api/80211/mac80211-advanced
+EDID/howto admin-guide/edid
+PCI/picebus-howto PCI/pciebus-howto
+RAS/address-translation admin-guide/RAS/address-translation
+RAS/error-decoding admin-guide/RAS/error-decoding
+RAS/ras admin-guide/RAS/error-decoding
+accelerators/ocxl userspace-api/accelerators/ocxl
+admin-guide/gpio/sysfs userspace-api/gpio/sysfs
+admin-guide/l1tf admin-guide/hw-vuln/l1tf
+admin-guide/media/v4l-with-ir admin-guide/media/remote-controller
+admin-guide/ras admin-guide/RAS/main
+admin-guide/security-bugs process/security-bugs
+aoe/aoe admin-guide/aoe/aoe
+aoe/examples admin-guide/aoe/examples
+aoe/index admin-guide/aoe/index
+aoe/todo admin-guide/aoe/todo
+arc/arc arch/arc/arc
+arc/features arch/arc/features
+arc/index arch/arc/index
+arch/x86/resctrl filesystems/resctrl
+arm/arm arch/arm/arm
+arm/booting arch/arm/booting
+arm/cluster-pm-race-avoidance arch/arm/cluster-pm-race-avoidance
+arm/features arch/arm/features
+arm/firmware arch/arm/firmware
+arm/google/chromebook-boot-flow arch/arm/google/chromebook-boot-flow
+arm/index arch/arm/index
+arm/interrupts arch/arm/interrupts
+arm/ixp4xx arch/arm/ixp4xx
+arm/kernel_mode_neon arch/arm/kernel_mode_neon
+arm/kernel_user_helpers arch/arm/kernel_user_helpers
+arm/keystone/knav-qmss arch/arm/keystone/knav-qmss
+arm/keystone/overview arch/arm/keystone/overview
+arm/marvel arch/arm/marvell
+arm/marvell arch/arm/marvell
+arm/mem_alignment arch/arm/mem_alignment
+arm/memory arch/arm/memory
+arm/microchip arch/arm/microchip
+arm/netwinder arch/arm/netwinder
+arm/nwfpe/index arch/arm/nwfpe/index
+arm/nwfpe/netwinder-fpe arch/arm/nwfpe/netwinder-fpe
+arm/nwfpe/notes arch/arm/nwfpe/notes
+arm/nwfpe/nwfpe arch/arm/nwfpe/nwfpe
+arm/nwfpe/todo arch/arm/nwfpe/todo
+arm/omap/dss arch/arm/omap/dss
+arm/omap/index arch/arm/omap/index
+arm/omap/omap arch/arm/omap/omap
+arm/omap/omap_pm arch/arm/omap/omap_pm
+arm/porting arch/arm/porting
+arm/pxa/mfp arch/arm/pxa/mfp
+arm/sa1100/assabet arch/arm/sa1100/assabet
+arm/sa1100/cerf arch/arm/sa1100/cerf
+arm/sa1100/index arch/arm/sa1100/index
+arm/sa1100/lart arch/arm/sa1100/lart
+arm/sa1100/serial_uart arch/arm/sa1100/serial_uart
+arm/samsung/bootloader-interface arch/arm/samsung/bootloader-interface
+arm/samsung/gpio arch/arm/samsung/gpio
+arm/samsung/index arch/arm/samsung/index
+arm/samsung/overview arch/arm/samsung/overview
+arm/setup arch/arm/setup
+arm/spear/overview arch/arm/spear/overview
+arm/sti/overview arch/arm/sti/overview
+arm/sti/stih407-overview arch/arm/sti/stih407-overview
+arm/sti/stih418-overview arch/arm/sti/stih418-overview
+arm/stm32/overview arch/arm/stm32/overview
+arm/stm32/stm32-dma-mdma-chaining arch/arm/stm32/stm32-dma-mdma-chaining
+arm/stm32/stm32f429-overview arch/arm/stm32/stm32f429-overview
+arm/stm32/stm32f746-overview arch/arm/stm32/stm32f746-overview
+arm/stm32/stm32f769-overview arch/arm/stm32/stm32f769-overview
+arm/stm32/stm32h743-overview arch/arm/stm32/stm32h743-overview
+arm/stm32/stm32h750-overview arch/arm/stm32/stm32h750-overview
+arm/stm32/stm32mp13-overview arch/arm/stm32/stm32mp13-overview
+arm/stm32/stm32mp151-overview arch/arm/stm32/stm32mp151-overview
+arm/stm32/stm32mp157-overview arch/arm/stm32/stm32mp157-overview
+arm/sunxi arch/arm/sunxi
+arm/sunxi/clocks arch/arm/sunxi/clocks
+arm/swp_emulation arch/arm/swp_emulation
+arm/tcm arch/arm/tcm
+arm/uefi arch/arm/uefi
+arm/vfp/release-notes arch/arm/vfp/release-notes
+arm/vlocks arch/arm/vlocks
+arm64/acpi_object_usage arch/arm64/acpi_object_usage
+arm64/amu arch/arm64/amu
+arm64/arm-acpi arch/arm64/arm-acpi
+arm64/asymmetric-32bit arch/arm64/asymmetric-32bit
+arm64/booting arch/arm64/booting
+arm64/cpu-feature-registers arch/arm64/cpu-feature-registers
+arm64/elf_hwcaps arch/arm64/elf_hwcaps
+arm64/features arch/arm64/features
+arm64/hugetlbpage arch/arm64/hugetlbpage
+arm64/index arch/arm64/index
+arm64/legacy_instructions arch/arm64/legacy_instructions
+arm64/memory arch/arm64/memory
+arm64/memory-tagging-extension arch/arm64/memory-tagging-extension
+arm64/perf arch/arm64/perf
+arm64/pointer-authentication arch/arm64/pointer-authentication
+arm64/silicon-errata arch/arm64/silicon-errata
+arm64/sme arch/arm64/sme
+arm64/sve arch/arm64/sve
+arm64/tagged-address-abi arch/arm64/tagged-address-abi
+arm64/tagged-pointers arch/arm64/tagged-pointers
+asm-annotations core-api/asm-annotations
+auxdisplay/lcd-panel-cgram admin-guide/lcd-panel-cgram
+backlight/lp855x-driver driver-api/backlight/lp855x-driver
+blockdev/drbd/data-structure-v9 admin-guide/blockdev/drbd/data-structure-v9
+blockdev/drbd/figures admin-guide/blockdev/drbd/figures
+blockdev/drbd/index admin-guide/blockdev/drbd/index
+blockdev/floppy admin-guide/blockdev/floppy
+blockdev/index admin-guide/blockdev/index
+blockdev/nbd admin-guide/blockdev/nbd
+blockdev/paride admin-guide/blockdev/paride
+blockdev/ramdisk admin-guide/blockdev/ramdisk
+blockdev/zram admin-guide/blockdev/zram
+bpf/README bpf/index
+bpf/bpf_lsm bpf/prog_lsm
+bpf/instruction-set bpf/standardization/instruction-set
+bpf/libbpf/libbpf bpf/libbpf/index
+bpf/standardization/linux-notes bpf/linux-notes
+bus-devices/ti-gpmc driver-api/memory-devices/ti-gpmc
+cgroup-v1/blkio-controller admin-guide/cgroup-v1/blkio-controller
+cgroup-v1/cgroups admin-guide/cgroup-v1/cgroups
+cgroup-v1/cpuacct admin-guide/cgroup-v1/cpuacct
+cgroup-v1/cpusets admin-guide/cgroup-v1/cpusets
+cgroup-v1/devices admin-guide/cgroup-v1/devices
+cgroup-v1/freezer-subsystem admin-guide/cgroup-v1/freezer-subsystem
+cgroup-v1/hugetlb admin-guide/cgroup-v1/hugetlb
+cgroup-v1/index admin-guide/cgroup-v1/index
+cgroup-v1/memcg_test admin-guide/cgroup-v1/memcg_test
+cgroup-v1/memory admin-guide/cgroup-v1/memory
+cgroup-v1/net_cls admin-guide/cgroup-v1/net_cls
+cgroup-v1/net_prio admin-guide/cgroup-v1/net_prio
+cgroup-v1/pids admin-guide/cgroup-v1/pids
+cgroup-v1/rdma admin-guide/cgroup-v1/rdma
+cma/debugfs admin-guide/mm/cma_debugfs
+connector/connector driver-api/connector
+console/console driver-api/console
+core-api/gcc-plugins kbuild/gcc-plugins
+core-api/ioctl driver-api/ioctl
+core-api/memory-hotplug-notifier core-api/memory-hotplug
+dev-tools/gdb-kernel-debugging process/debugging/gdb-kernel-debugging
+dev-tools/kgdb process/debugging/kgdb
+dev-tools/tools dev-tools/index
+development-process/1.Intro process/1.Intro
+development-process/2.Process process/2.Process
+development-process/3.Early-stage process/3.Early-stage
+development-process/4.Coding process/4.Coding
+development-process/5.Posting process/5.Posting
+development-process/6.Followthrough process/6.Followthrough
+development-process/7.AdvancedTopics process/7.AdvancedTopics
+development-process/8.Conclusion process/8.Conclusion
+development-process/development-process process/development-process
+development-process/index process/index
+device-mapper/cache admin-guide/device-mapper/cache
+device-mapper/cache-policies admin-guide/device-mapper/cache-policies
+device-mapper/delay admin-guide/device-mapper/delay
+device-mapper/dm-crypt admin-guide/device-mapper/dm-crypt
+device-mapper/dm-flakey admin-guide/device-mapper/dm-flakey
+device-mapper/dm-init admin-guide/device-mapper/dm-init
+device-mapper/dm-integrity admin-guide/device-mapper/dm-integrity
+device-mapper/dm-io admin-guide/device-mapper/dm-io
+device-mapper/dm-log admin-guide/device-mapper/dm-log
+device-mapper/dm-queue-length admin-guide/device-mapper/dm-queue-length
+device-mapper/dm-raid admin-guide/device-mapper/dm-raid
+device-mapper/dm-service-time admin-guide/device-mapper/dm-service-time
+device-mapper/dm-uevent admin-guide/device-mapper/dm-uevent
+device-mapper/dm-zoned admin-guide/device-mapper/dm-zoned
+device-mapper/era admin-guide/device-mapper/era
+device-mapper/index admin-guide/device-mapper/index
+device-mapper/kcopyd admin-guide/device-mapper/kcopyd
+device-mapper/linear admin-guide/device-mapper/linear
+device-mapper/log-writes admin-guide/device-mapper/log-writes
+device-mapper/persistent-data admin-guide/device-mapper/persistent-data
+device-mapper/snapshot admin-guide/device-mapper/snapshot
+device-mapper/statistics admin-guide/device-mapper/statistics
+device-mapper/striped admin-guide/device-mapper/striped
+device-mapper/switch admin-guide/device-mapper/switch
+device-mapper/thin-provisioning admin-guide/device-mapper/thin-provisioning
+device-mapper/unstriped admin-guide/device-mapper/unstriped
+device-mapper/verity admin-guide/device-mapper/verity
+device-mapper/writecache admin-guide/device-mapper/writecache
+device-mapper/zero admin-guide/device-mapper/zero
+devicetree/writing-schema devicetree/bindings/writing-schema
+driver-api/bt8xxgpio driver-api/gpio/bt8xxgpio
+driver-api/cxl/access-coordinates driver-api/cxl/linux/access-coordinates
+driver-api/cxl/memory-devices driver-api/cxl/theory-of-operation
+driver-api/dcdbas userspace-api/dcdbas
+driver-api/dell_rbu admin-guide/dell_rbu
+driver-api/edid admin-guide/edid
+driver-api/gpio driver-api/gpio/index
+driver-api/hte/tegra194-hte driver-api/hte/tegra-hte
+driver-api/isapnp userspace-api/isapnp
+driver-api/media/drivers/v4l-drivers/zoran driver-api/media/drivers/zoran
+driver-api/mtd/intel-spi driver-api/mtd/spi-intel
+driver-api/pci driver-api/pci/pci
+driver-api/pinctl driver-api/pin-control
+driver-api/rapidio admin-guide/rapidio
+driver-api/serial/moxa-smartio driver-api/tty/moxa-smartio
+driver-api/serial/n_gsm driver-api/tty/n_gsm
+driver-api/serial/tty driver-api/tty/tty_ldisc
+driver-api/thermal/intel_powerclamp admin-guide/thermal/intel_powerclamp
+driver-api/usb driver-api/usb/usb
+driver-model/binding driver-api/driver-model/binding
+driver-model/bus driver-api/driver-model/bus
+driver-model/design-patterns driver-api/driver-model/design-patterns
+driver-model/device driver-api/driver-model/device
+driver-model/devres driver-api/driver-model/devres
+driver-model/driver driver-api/driver-model/driver
+driver-model/index driver-api/driver-model/index
+driver-model/overview driver-api/driver-model/overview
+driver-model/platform driver-api/driver-model/platform
+driver-model/porting driver-api/driver-model/porting
+early-userspace/buffer-format driver-api/early-userspace/buffer-format
+early-userspace/early_userspace_support driver-api/early-userspace/early_userspace_support
+early-userspace/index driver-api/early-userspace/index
+errseq core-api/errseq
+filesystems/binderfs admin-guide/binderfs
+filesystems/cifs/cifsd filesystems/smb/ksmbd
+filesystems/cifs/cifsroot filesystems/smb/cifsroot
+filesystems/cifs/index filesystems/smb/index
+filesystems/cifs/ksmbd filesystems/smb/ksmbd
+filesystems/ext4/ext4 admin-guide/ext4
+filesystems/ext4/ondisk/about filesystems/ext4/about
+filesystems/ext4/ondisk/allocators filesystems/ext4/allocators
+filesystems/ext4/ondisk/attributes filesystems/ext4/attributes
+filesystems/ext4/ondisk/bigalloc filesystems/ext4/bigalloc
+filesystems/ext4/ondisk/bitmaps filesystems/ext4/bitmaps
+filesystems/ext4/ondisk/blockgroup filesystems/ext4/blockgroup
+filesystems/ext4/ondisk/blockmap filesystems/ext4/blockmap
+filesystems/ext4/ondisk/blocks filesystems/ext4/blocks
+filesystems/ext4/ondisk/checksums filesystems/ext4/checksums
+filesystems/ext4/ondisk/directory filesystems/ext4/directory
+filesystems/ext4/ondisk/dynamic filesystems/ext4/dynamic
+filesystems/ext4/ondisk/eainode filesystems/ext4/eainode
+filesystems/ext4/ondisk/globals filesystems/ext4/globals
+filesystems/ext4/ondisk/group_descr filesystems/ext4/group_descr
+filesystems/ext4/ondisk/ifork filesystems/ext4/ifork
+filesystems/ext4/ondisk/inlinedata filesystems/ext4/inlinedata
+filesystems/ext4/ondisk/inodes filesystems/ext4/inodes
+filesystems/ext4/ondisk/journal filesystems/ext4/journal
+filesystems/ext4/ondisk/mmp filesystems/ext4/mmp
+filesystems/ext4/ondisk/overview filesystems/ext4/overview
+filesystems/ext4/ondisk/special_inodes filesystems/ext4/special_inodes
+filesystems/ext4/ondisk/super filesystems/ext4/super
+filesystems/sysfs-pci PCI/sysfs-pci
+filesystems/sysfs-tagging networking/sysfs-tagging
+filesystems/xfs-delayed-logging-design filesystems/xfs/xfs-delayed-logging-design
+filesystems/xfs-maintainer-entry-profile filesystems/xfs/xfs-maintainer-entry-profile
+filesystems/xfs-online-fsck-design filesystems/xfs/xfs-online-fsck-design
+filesystems/xfs-self-describing-metadata filesystems/xfs/xfs-self-describing-metadata
+gpio/index admin-guide/gpio/index
+gpio/sysfs userspace-api/gpio/sysfs
+gpu/amdgpu gpu/amdgpu/index
+hte/hte driver-api/hte/hte
+hte/index driver-api/hte/index
+hte/tegra194-hte driver-api/hte/tegra-hte
+input/alps input/devices/alps
+input/amijoy input/devices/amijoy
+input/appletouch input/devices/appletouch
+input/atarikbd input/devices/atarikbd
+input/bcm5974 input/devices/bcm5974
+input/cma3000_d0x input/devices/cma3000_d0x
+input/cs461x input/devices/cs461x
+input/edt-ft5x06 input/devices/edt-ft5x06
+input/elantech input/devices/elantech
+input/iforce-protocol input/devices/iforce-protocol
+input/joystick input/joydev/joystick
+input/joystick-api input/joydev/joystick-api
+input/joystick-parport input/devices/joystick-parport
+input/ntrig input/devices/ntrig
+input/rotary-encoder input/devices/rotary-encoder
+input/sentelic input/devices/sentelic
+input/walkera0701 input/devices/walkera0701
+input/xpad input/devices/xpad
+input/yealink input/devices/yealink
+interconnect/interconnect driver-api/interconnect
+ioctl/botching-up-ioctls process/botching-up-ioctls
+ioctl/cdrom userspace-api/ioctl/cdrom
+ioctl/hdio userspace-api/ioctl/hdio
+ioctl/index userspace-api/ioctl/index
+ioctl/ioctl-decoding userspace-api/ioctl/ioctl-decoding
+ioctl/ioctl-number userspace-api/ioctl/ioctl-number
+kbuild/namespaces core-api/symbol-namespaces
+kdump/index admin-guide/kdump/index
+kdump/kdump admin-guide/kdump/kdump
+kdump/vmcoreinfo admin-guide/kdump/vmcoreinfo
+kernel-documentation doc-guide/kernel-doc
+laptops/asus-laptop admin-guide/laptops/asus-laptop
+laptops/disk-shock-protection admin-guide/laptops/disk-shock-protection
+laptops/index admin-guide/laptops/index
+laptops/laptop-mode admin-guide/laptops/laptop-mode
+laptops/lg-laptop admin-guide/laptops/lg-laptop
+laptops/sony-laptop admin-guide/laptops/sony-laptop
+laptops/sonypi admin-guide/laptops/sonypi
+laptops/thinkpad-acpi admin-guide/laptops/thinkpad-acpi
+laptops/toshiba_haps admin-guide/laptops/toshiba_haps
+loongarch/booting arch/loongarch/booting
+loongarch/features arch/loongarch/features
+loongarch/index arch/loongarch/index
+loongarch/introduction arch/loongarch/introduction
+loongarch/irq-chip-model arch/loongarch/irq-chip-model
+m68k/buddha-driver arch/m68k/buddha-driver
+m68k/features arch/m68k/features
+m68k/index arch/m68k/index
+m68k/kernel-options arch/m68k/kernel-options
+md/index driver-api/md/index
+md/md-cluster driver-api/md/md-cluster
+md/raid5-cache driver-api/md/raid5-cache
+md/raid5-ppl driver-api/md/raid5-ppl
+media/dvb-drivers/avermedia admin-guide/media/avermedia
+media/dvb-drivers/bt8xx admin-guide/media/bt8xx
+media/dvb-drivers/ci admin-guide/media/ci
+media/dvb-drivers/contributors driver-api/media/drivers/contributors
+media/dvb-drivers/dvb-usb driver-api/media/drivers/dvb-usb
+media/dvb-drivers/faq admin-guide/media/faq
+media/dvb-drivers/frontends driver-api/media/drivers/frontends
+media/dvb-drivers/index driver-api/media/drivers/index
+media/dvb-drivers/lmedm04 admin-guide/media/lmedm04
+media/dvb-drivers/opera-firmware admin-guide/media/opera-firmware
+media/dvb-drivers/technisat admin-guide/media/technisat
+media/dvb-drivers/ttusb-dec admin-guide/media/ttusb-dec
+media/intro userspace-api/media/intro
+media/kapi/cec-core driver-api/media/cec-core
+media/kapi/dtv-ca driver-api/media/dtv-ca
+media/kapi/dtv-common driver-api/media/dtv-common
+media/kapi/dtv-core driver-api/media/dtv-core
+media/kapi/dtv-demux driver-api/media/dtv-demux
+media/kapi/dtv-frontend driver-api/media/dtv-frontend
+media/kapi/dtv-net driver-api/media/dtv-net
+media/kapi/mc-core driver-api/media/mc-core
+media/kapi/rc-core driver-api/media/rc-core
+media/kapi/v4l2-async driver-api/media/v4l2-async
+media/kapi/v4l2-common driver-api/media/v4l2-common
+media/kapi/v4l2-controls driver-api/media/v4l2-controls
+media/kapi/v4l2-core driver-api/media/v4l2-core
+media/kapi/v4l2-dev driver-api/media/v4l2-dev
+media/kapi/v4l2-device driver-api/media/v4l2-device
+media/kapi/v4l2-dv-timings driver-api/media/v4l2-dv-timings
+media/kapi/v4l2-event driver-api/media/v4l2-event
+media/kapi/v4l2-fh driver-api/media/v4l2-fh
+media/kapi/v4l2-flash-led-class driver-api/media/v4l2-flash-led-class
+media/kapi/v4l2-fwnode driver-api/media/v4l2-fwnode
+media/kapi/v4l2-intro driver-api/media/v4l2-intro
+media/kapi/v4l2-mc driver-api/media/v4l2-mc
+media/kapi/v4l2-mediabus driver-api/media/v4l2-mediabus
+media/kapi/v4l2-mem2mem driver-api/media/v4l2-mem2mem
+media/kapi/v4l2-rect driver-api/media/v4l2-rect
+media/kapi/v4l2-subdev driver-api/media/v4l2-subdev
+media/kapi/v4l2-tuner driver-api/media/v4l2-tuner
+media/kapi/v4l2-tveeprom driver-api/media/v4l2-tveeprom
+media/kapi/v4l2-videobuf2 driver-api/media/v4l2-videobuf2
+media/media_kapi driver-api/media/index
+media/media_uapi userspace-api/media/index
+media/uapi/cec/cec-api userspace-api/media/cec/cec-api
+media/uapi/cec/cec-func-close userspace-api/media/cec/cec-func-close
+media/uapi/cec/cec-func-ioctl userspace-api/media/cec/cec-func-ioctl
+media/uapi/cec/cec-func-open userspace-api/media/cec/cec-func-open
+media/uapi/cec/cec-func-poll userspace-api/media/cec/cec-func-poll
+media/uapi/cec/cec-funcs userspace-api/media/cec/cec-funcs
+media/uapi/cec/cec-header userspace-api/media/cec/cec-header
+media/uapi/cec/cec-intro userspace-api/media/cec/cec-intro
+media/uapi/cec/cec-ioc-adap-g-caps userspace-api/media/cec/cec-ioc-adap-g-caps
+media/uapi/cec/cec-ioc-adap-g-conn-info userspace-api/media/cec/cec-ioc-adap-g-conn-info
+media/uapi/cec/cec-ioc-adap-g-log-addrs userspace-api/media/cec/cec-ioc-adap-g-log-addrs
+media/uapi/cec/cec-ioc-adap-g-phys-addr userspace-api/media/cec/cec-ioc-adap-g-phys-addr
+media/uapi/cec/cec-ioc-dqevent userspace-api/media/cec/cec-ioc-dqevent
+media/uapi/cec/cec-ioc-g-mode userspace-api/media/cec/cec-ioc-g-mode
+media/uapi/cec/cec-ioc-receive userspace-api/media/cec/cec-ioc-receive
+media/uapi/cec/cec-pin-error-inj userspace-api/media/cec/cec-pin-error-inj
+media/uapi/dvb/ca userspace-api/media/dvb/ca
+media/uapi/dvb/ca-fclose userspace-api/media/dvb/ca-fclose
+media/uapi/dvb/ca-fopen userspace-api/media/dvb/ca-fopen
+media/uapi/dvb/ca-get-cap userspace-api/media/dvb/ca-get-cap
+media/uapi/dvb/ca-get-descr-info userspace-api/media/dvb/ca-get-descr-info
+media/uapi/dvb/ca-get-msg userspace-api/media/dvb/ca-get-msg
+media/uapi/dvb/ca-get-slot-info userspace-api/media/dvb/ca-get-slot-info
+media/uapi/dvb/ca-reset userspace-api/media/dvb/ca-reset
+media/uapi/dvb/ca-send-msg userspace-api/media/dvb/ca-send-msg
+media/uapi/dvb/ca-set-descr userspace-api/media/dvb/ca-set-descr
+media/uapi/dvb/ca_data_types userspace-api/media/dvb/ca_data_types
+media/uapi/dvb/ca_function_calls userspace-api/media/dvb/ca_function_calls
+media/uapi/dvb/ca_high_level userspace-api/media/dvb/ca_high_level
+media/uapi/dvb/demux userspace-api/media/dvb/demux
+media/uapi/dvb/dmx-add-pid userspace-api/media/dvb/dmx-add-pid
+media/uapi/dvb/dmx-expbuf userspace-api/media/dvb/dmx-expbuf
+media/uapi/dvb/dmx-fclose userspace-api/media/dvb/dmx-fclose
+media/uapi/dvb/dmx-fopen userspace-api/media/dvb/dmx-fopen
+media/uapi/dvb/dmx-fread userspace-api/media/dvb/dmx-fread
+media/uapi/dvb/dmx-fwrite userspace-api/media/dvb/dmx-fwrite
+media/uapi/dvb/dmx-get-pes-pids userspace-api/media/dvb/dmx-get-pes-pids
+media/uapi/dvb/dmx-get-stc userspace-api/media/dvb/dmx-get-stc
+media/uapi/dvb/dmx-mmap userspace-api/media/dvb/dmx-mmap
+media/uapi/dvb/dmx-munmap userspace-api/media/dvb/dmx-munmap
+media/uapi/dvb/dmx-qbuf userspace-api/media/dvb/dmx-qbuf
+media/uapi/dvb/dmx-querybuf userspace-api/media/dvb/dmx-querybuf
+media/uapi/dvb/dmx-remove-pid userspace-api/media/dvb/dmx-remove-pid
+media/uapi/dvb/dmx-reqbufs userspace-api/media/dvb/dmx-reqbufs
+media/uapi/dvb/dmx-set-buffer-size userspace-api/media/dvb/dmx-set-buffer-size
+media/uapi/dvb/dmx-set-filter userspace-api/media/dvb/dmx-set-filter
+media/uapi/dvb/dmx-set-pes-filter userspace-api/media/dvb/dmx-set-pes-filter
+media/uapi/dvb/dmx-start userspace-api/media/dvb/dmx-start
+media/uapi/dvb/dmx-stop userspace-api/media/dvb/dmx-stop
+media/uapi/dvb/dmx_fcalls userspace-api/media/dvb/dmx_fcalls
+media/uapi/dvb/dmx_types userspace-api/media/dvb/dmx_types
+media/uapi/dvb/dvb-fe-read-status userspace-api/media/dvb/dvb-fe-read-status
+media/uapi/dvb/dvb-frontend-event userspace-api/media/dvb/dvb-frontend-event
+media/uapi/dvb/dvb-frontend-parameters userspace-api/media/dvb/dvb-frontend-parameters
+media/uapi/dvb/dvbapi userspace-api/media/dvb/dvbapi
+media/uapi/dvb/dvbproperty userspace-api/media/dvb/dvbproperty
+media/uapi/dvb/examples userspace-api/media/dvb/examples
+media/uapi/dvb/fe-bandwidth-t userspace-api/media/dvb/fe-bandwidth-t
+media/uapi/dvb/fe-diseqc-recv-slave-reply userspace-api/media/dvb/fe-diseqc-recv-slave-reply
+media/uapi/dvb/fe-diseqc-reset-overload userspace-api/media/dvb/fe-diseqc-reset-overload
+media/uapi/dvb/fe-diseqc-send-burst userspace-api/media/dvb/fe-diseqc-send-burst
+media/uapi/dvb/fe-diseqc-send-master-cmd userspace-api/media/dvb/fe-diseqc-send-master-cmd
+media/uapi/dvb/fe-dishnetwork-send-legacy-cmd userspace-api/media/dvb/fe-dishnetwork-send-legacy-cmd
+media/uapi/dvb/fe-enable-high-lnb-voltage userspace-api/media/dvb/fe-enable-high-lnb-voltage
+media/uapi/dvb/fe-get-event userspace-api/media/dvb/fe-get-event
+media/uapi/dvb/fe-get-frontend userspace-api/media/dvb/fe-get-frontend
+media/uapi/dvb/fe-get-info userspace-api/media/dvb/fe-get-info
+media/uapi/dvb/fe-get-property userspace-api/media/dvb/fe-get-property
+media/uapi/dvb/fe-read-ber userspace-api/media/dvb/fe-read-ber
+media/uapi/dvb/fe-read-signal-strength userspace-api/media/dvb/fe-read-signal-strength
+media/uapi/dvb/fe-read-snr userspace-api/media/dvb/fe-read-snr
+media/uapi/dvb/fe-read-status userspace-api/media/dvb/fe-read-status
+media/uapi/dvb/fe-read-uncorrected-blocks userspace-api/media/dvb/fe-read-uncorrected-blocks
+media/uapi/dvb/fe-set-frontend userspace-api/media/dvb/fe-set-frontend
+media/uapi/dvb/fe-set-frontend-tune-mode userspace-api/media/dvb/fe-set-frontend-tune-mode
+media/uapi/dvb/fe-set-tone userspace-api/media/dvb/fe-set-tone
+media/uapi/dvb/fe-set-voltage userspace-api/media/dvb/fe-set-voltage
+media/uapi/dvb/fe-type-t userspace-api/media/dvb/fe-type-t
+media/uapi/dvb/fe_property_parameters userspace-api/media/dvb/fe_property_parameters
+media/uapi/dvb/frontend userspace-api/media/dvb/frontend
+media/uapi/dvb/frontend-header userspace-api/media/dvb/frontend-header
+media/uapi/dvb/frontend-property-cable-systems userspace-api/media/dvb/frontend-property-cable-systems
+media/uapi/dvb/frontend-property-satellite-systems userspace-api/media/dvb/frontend-property-satellite-systems
+media/uapi/dvb/frontend-property-terrestrial-systems userspace-api/media/dvb/frontend-property-terrestrial-systems
+media/uapi/dvb/frontend-stat-properties userspace-api/media/dvb/frontend-stat-properties
+media/uapi/dvb/frontend_f_close userspace-api/media/dvb/frontend_f_close
+media/uapi/dvb/frontend_f_open userspace-api/media/dvb/frontend_f_open
+media/uapi/dvb/frontend_fcalls userspace-api/media/dvb/frontend_fcalls
+media/uapi/dvb/frontend_legacy_api userspace-api/media/dvb/frontend_legacy_api
+media/uapi/dvb/frontend_legacy_dvbv3_api userspace-api/media/dvb/frontend_legacy_dvbv3_api
+media/uapi/dvb/headers userspace-api/media/dvb/headers
+media/uapi/dvb/intro userspace-api/media/dvb/intro
+media/uapi/dvb/legacy_dvb_apis userspace-api/media/dvb/legacy_dvb_apis
+media/uapi/dvb/net userspace-api/media/dvb/net
+media/uapi/dvb/net-add-if userspace-api/media/dvb/net-add-if
+media/uapi/dvb/net-get-if userspace-api/media/dvb/net-get-if
+media/uapi/dvb/net-remove-if userspace-api/media/dvb/net-remove-if
+media/uapi/dvb/net-types userspace-api/media/dvb/net-types
+media/uapi/dvb/query-dvb-frontend-info userspace-api/media/dvb/query-dvb-frontend-info
+media/uapi/fdl-appendix userspace-api/media/fdl-appendix
+media/uapi/gen-errors userspace-api/media/gen-errors
+media/uapi/mediactl/media-controller userspace-api/media/mediactl/media-controller
+media/uapi/mediactl/media-controller-intro userspace-api/media/mediactl/media-controller-intro
+media/uapi/mediactl/media-controller-model userspace-api/media/mediactl/media-controller-model
+media/uapi/mediactl/media-func-close userspace-api/media/mediactl/media-func-close
+media/uapi/mediactl/media-func-ioctl userspace-api/media/mediactl/media-func-ioctl
+media/uapi/mediactl/media-func-open userspace-api/media/mediactl/media-func-open
+media/uapi/mediactl/media-funcs userspace-api/media/mediactl/media-funcs
+media/uapi/mediactl/media-header userspace-api/media/mediactl/media-header
+media/uapi/mediactl/media-ioc-device-info userspace-api/media/mediactl/media-ioc-device-info
+media/uapi/mediactl/media-ioc-enum-entities userspace-api/media/mediactl/media-ioc-enum-entities
+media/uapi/mediactl/media-ioc-enum-links userspace-api/media/mediactl/media-ioc-enum-links
+media/uapi/mediactl/media-ioc-g-topology userspace-api/media/mediactl/media-ioc-g-topology
+media/uapi/mediactl/media-ioc-request-alloc userspace-api/media/mediactl/media-ioc-request-alloc
+media/uapi/mediactl/media-ioc-setup-link userspace-api/media/mediactl/media-ioc-setup-link
+media/uapi/mediactl/media-request-ioc-queue userspace-api/media/mediactl/media-request-ioc-queue
+media/uapi/mediactl/media-request-ioc-reinit userspace-api/media/mediactl/media-request-ioc-reinit
+media/uapi/mediactl/media-types userspace-api/media/mediactl/media-types
+media/uapi/mediactl/request-api userspace-api/media/mediactl/request-api
+media/uapi/mediactl/request-func-close userspace-api/media/mediactl/request-func-close
+media/uapi/mediactl/request-func-ioctl userspace-api/media/mediactl/request-func-ioctl
+media/uapi/mediactl/request-func-poll userspace-api/media/mediactl/request-func-poll
+media/uapi/rc/keytable.c userspace-api/media/rc/keytable.c
+media/uapi/rc/lirc-dev userspace-api/media/rc/lirc-dev
+media/uapi/rc/lirc-dev-intro userspace-api/media/rc/lirc-dev-intro
+media/uapi/rc/lirc-func userspace-api/media/rc/lirc-func
+media/uapi/rc/lirc-get-features userspace-api/media/rc/lirc-get-features
+media/uapi/rc/lirc-get-rec-mode userspace-api/media/rc/lirc-get-rec-mode
+media/uapi/rc/lirc-get-rec-resolution userspace-api/media/rc/lirc-get-rec-resolution
+media/uapi/rc/lirc-get-send-mode userspace-api/media/rc/lirc-get-send-mode
+media/uapi/rc/lirc-get-timeout userspace-api/media/rc/lirc-get-timeout
+media/uapi/rc/lirc-header userspace-api/media/rc/lirc-header
+media/uapi/rc/lirc-read userspace-api/media/rc/lirc-read
+media/uapi/rc/lirc-set-measure-carrier-mode userspace-api/media/rc/lirc-set-measure-carrier-mode
+media/uapi/rc/lirc-set-rec-carrier userspace-api/media/rc/lirc-set-rec-carrier
+media/uapi/rc/lirc-set-rec-carrier-range userspace-api/media/rc/lirc-set-rec-carrier-range
+media/uapi/rc/lirc-set-rec-timeout userspace-api/media/rc/lirc-set-rec-timeout
+media/uapi/rc/lirc-set-send-carrier userspace-api/media/rc/lirc-set-send-carrier
+media/uapi/rc/lirc-set-send-duty-cycle userspace-api/media/rc/lirc-set-send-duty-cycle
+media/uapi/rc/lirc-set-transmitter-mask userspace-api/media/rc/lirc-set-transmitter-mask
+media/uapi/rc/lirc-set-wideband-receiver userspace-api/media/rc/lirc-set-wideband-receiver
+media/uapi/rc/lirc-write userspace-api/media/rc/lirc-write
+media/uapi/rc/rc-intro userspace-api/media/rc/rc-intro
+media/uapi/rc/rc-protos userspace-api/media/rc/rc-protos
+media/uapi/rc/rc-sysfs-nodes userspace-api/media/rc/rc-sysfs-nodes
+media/uapi/rc/rc-table-change userspace-api/media/rc/rc-table-change
+media/uapi/rc/rc-tables userspace-api/media/rc/rc-tables
+media/uapi/rc/remote_controllers userspace-api/media/rc/remote_controllers
+media/uapi/v4l/app-pri userspace-api/media/v4l/app-pri
+media/uapi/v4l/audio userspace-api/media/v4l/audio
+media/uapi/v4l/biblio userspace-api/media/v4l/biblio
+media/uapi/v4l/buffer userspace-api/media/v4l/buffer
+media/uapi/v4l/capture-example userspace-api/media/v4l/capture-example
+media/uapi/v4l/capture.c userspace-api/media/v4l/capture.c
+media/uapi/v4l/colorspaces userspace-api/media/v4l/colorspaces
+media/uapi/v4l/colorspaces-defs userspace-api/media/v4l/colorspaces-defs
+media/uapi/v4l/colorspaces-details userspace-api/media/v4l/colorspaces-details
+media/uapi/v4l/common userspace-api/media/v4l/common
+media/uapi/v4l/common-defs userspace-api/media/v4l/common-defs
+media/uapi/v4l/compat userspace-api/media/v4l/compat
+media/uapi/v4l/control userspace-api/media/v4l/control
+media/uapi/v4l/crop userspace-api/media/v4l/crop
+media/uapi/v4l/depth-formats userspace-api/media/v4l/depth-formats
+media/uapi/v4l/dev-capture userspace-api/media/v4l/dev-capture
+media/uapi/v4l/dev-codec userspace-api/media/v4l/dev-mem2mem
+media/uapi/v4l/dev-decoder userspace-api/media/v4l/dev-decoder
+media/uapi/v4l/dev-event userspace-api/media/v4l/dev-event
+media/uapi/v4l/dev-mem2mem userspace-api/media/v4l/dev-mem2mem
+media/uapi/v4l/dev-meta userspace-api/media/v4l/dev-meta
+media/uapi/v4l/dev-osd userspace-api/media/v4l/dev-osd
+media/uapi/v4l/dev-output userspace-api/media/v4l/dev-output
+media/uapi/v4l/dev-overlay userspace-api/media/v4l/dev-overlay
+media/uapi/v4l/dev-radio userspace-api/media/v4l/dev-radio
+media/uapi/v4l/dev-raw-vbi userspace-api/media/v4l/dev-raw-vbi
+media/uapi/v4l/dev-rds userspace-api/media/v4l/dev-rds
+media/uapi/v4l/dev-sdr userspace-api/media/v4l/dev-sdr
+media/uapi/v4l/dev-sliced-vbi userspace-api/media/v4l/dev-sliced-vbi
+media/uapi/v4l/dev-stateless-decoder userspace-api/media/v4l/dev-stateless-decoder
+media/uapi/v4l/dev-subdev userspace-api/media/v4l/dev-subdev
+media/uapi/v4l/dev-touch userspace-api/media/v4l/dev-touch
+media/uapi/v4l/devices userspace-api/media/v4l/devices
+media/uapi/v4l/diff-v4l userspace-api/media/v4l/diff-v4l
+media/uapi/v4l/dmabuf userspace-api/media/v4l/dmabuf
+media/uapi/v4l/dv-timings userspace-api/media/v4l/dv-timings
+media/uapi/v4l/ext-ctrls-camera userspace-api/media/v4l/ext-ctrls-camera
+media/uapi/v4l/ext-ctrls-codec userspace-api/media/v4l/ext-ctrls-codec
+media/uapi/v4l/ext-ctrls-detect userspace-api/media/v4l/ext-ctrls-detect
+media/uapi/v4l/ext-ctrls-dv userspace-api/media/v4l/ext-ctrls-dv
+media/uapi/v4l/ext-ctrls-flash userspace-api/media/v4l/ext-ctrls-flash
+media/uapi/v4l/ext-ctrls-fm-rx userspace-api/media/v4l/ext-ctrls-fm-rx
+media/uapi/v4l/ext-ctrls-fm-tx userspace-api/media/v4l/ext-ctrls-fm-tx
+media/uapi/v4l/ext-ctrls-image-process userspace-api/media/v4l/ext-ctrls-image-process
+media/uapi/v4l/ext-ctrls-image-source userspace-api/media/v4l/ext-ctrls-image-source
+media/uapi/v4l/ext-ctrls-jpeg userspace-api/media/v4l/ext-ctrls-jpeg
+media/uapi/v4l/ext-ctrls-rf-tuner userspace-api/media/v4l/ext-ctrls-rf-tuner
+media/uapi/v4l/extended-controls userspace-api/media/v4l/extended-controls
+media/uapi/v4l/field-order userspace-api/media/v4l/field-order
+media/uapi/v4l/format userspace-api/media/v4l/format
+media/uapi/v4l/func-close userspace-api/media/v4l/func-close
+media/uapi/v4l/func-ioctl userspace-api/media/v4l/func-ioctl
+media/uapi/v4l/func-mmap userspace-api/media/v4l/func-mmap
+media/uapi/v4l/func-munmap userspace-api/media/v4l/func-munmap
+media/uapi/v4l/func-open userspace-api/media/v4l/func-open
+media/uapi/v4l/func-poll userspace-api/media/v4l/func-poll
+media/uapi/v4l/func-read userspace-api/media/v4l/func-read
+media/uapi/v4l/func-select userspace-api/media/v4l/func-select
+media/uapi/v4l/func-write userspace-api/media/v4l/func-write
+media/uapi/v4l/hist-v4l2 userspace-api/media/v4l/hist-v4l2
+media/uapi/v4l/hsv-formats userspace-api/media/v4l/hsv-formats
+media/uapi/v4l/io userspace-api/media/v4l/io
+media/uapi/v4l/libv4l userspace-api/media/v4l/libv4l
+media/uapi/v4l/libv4l-introduction userspace-api/media/v4l/libv4l-introduction
+media/uapi/v4l/meta-formats userspace-api/media/v4l/meta-formats
+media/uapi/v4l/mmap userspace-api/media/v4l/mmap
+media/uapi/v4l/open userspace-api/media/v4l/open
+media/uapi/v4l/pixfmt userspace-api/media/v4l/pixfmt
+media/uapi/v4l/pixfmt-002 userspace-api/media/v4l/pixfmt-v4l2
+media/uapi/v4l/pixfmt-003 userspace-api/media/v4l/pixfmt-v4l2-mplane
+media/uapi/v4l/pixfmt-004 userspace-api/media/v4l/pixfmt-intro
+media/uapi/v4l/pixfmt-006 userspace-api/media/v4l/colorspaces-defs
+media/uapi/v4l/pixfmt-007 userspace-api/media/v4l/colorspaces-details
+media/uapi/v4l/pixfmt-013 userspace-api/media/v4l/pixfmt-compressed
+media/uapi/v4l/pixfmt-bayer userspace-api/media/v4l/pixfmt-bayer
+media/uapi/v4l/pixfmt-cnf4 userspace-api/media/v4l/pixfmt-cnf4
+media/uapi/v4l/pixfmt-compressed userspace-api/media/v4l/pixfmt-compressed
+media/uapi/v4l/pixfmt-indexed userspace-api/media/v4l/pixfmt-indexed
+media/uapi/v4l/pixfmt-intro userspace-api/media/v4l/pixfmt-intro
+media/uapi/v4l/pixfmt-inzi userspace-api/media/v4l/pixfmt-inzi
+media/uapi/v4l/pixfmt-m420 userspace-api/media/v4l/pixfmt-m420
+media/uapi/v4l/pixfmt-meta-d4xx userspace-api/media/v4l/metafmt-d4xx
+media/uapi/v4l/pixfmt-meta-intel-ipu3 userspace-api/media/v4l/metafmt-intel-ipu3
+media/uapi/v4l/pixfmt-meta-uvc userspace-api/media/v4l/metafmt-uvc
+media/uapi/v4l/pixfmt-meta-vivid userspace-api/media/v4l/metafmt-vivid
+media/uapi/v4l/pixfmt-meta-vsp1-hgo userspace-api/media/v4l/metafmt-vsp1-hgo
+media/uapi/v4l/pixfmt-meta-vsp1-hgt userspace-api/media/v4l/metafmt-vsp1-hgt
+media/uapi/v4l/pixfmt-packed-hsv userspace-api/media/v4l/pixfmt-packed-hsv
+media/uapi/v4l/pixfmt-packed-yuv userspace-api/media/v4l/pixfmt-packed-yuv
+media/uapi/v4l/pixfmt-reserved userspace-api/media/v4l/pixfmt-reserved
+media/uapi/v4l/pixfmt-rgb userspace-api/media/v4l/pixfmt-rgb
+media/uapi/v4l/pixfmt-sbggr16 userspace-api/media/v4l/pixfmt-srggb16
+media/uapi/v4l/pixfmt-sdr-cs08 userspace-api/media/v4l/pixfmt-sdr-cs08
+media/uapi/v4l/pixfmt-sdr-cs14le userspace-api/media/v4l/pixfmt-sdr-cs14le
+media/uapi/v4l/pixfmt-sdr-cu08 userspace-api/media/v4l/pixfmt-sdr-cu08
+media/uapi/v4l/pixfmt-sdr-cu16le userspace-api/media/v4l/pixfmt-sdr-cu16le
+media/uapi/v4l/pixfmt-sdr-pcu16be userspace-api/media/v4l/pixfmt-sdr-pcu16be
+media/uapi/v4l/pixfmt-sdr-pcu18be userspace-api/media/v4l/pixfmt-sdr-pcu18be
+media/uapi/v4l/pixfmt-sdr-pcu20be userspace-api/media/v4l/pixfmt-sdr-pcu20be
+media/uapi/v4l/pixfmt-sdr-ru12le userspace-api/media/v4l/pixfmt-sdr-ru12le
+media/uapi/v4l/pixfmt-srggb10 userspace-api/media/v4l/pixfmt-srggb10
+media/uapi/v4l/pixfmt-srggb10-ipu3 userspace-api/media/v4l/pixfmt-srggb10-ipu3
+media/uapi/v4l/pixfmt-srggb10alaw8 userspace-api/media/v4l/pixfmt-srggb10alaw8
+media/uapi/v4l/pixfmt-srggb10dpcm8 userspace-api/media/v4l/pixfmt-srggb10dpcm8
+media/uapi/v4l/pixfmt-srggb10p userspace-api/media/v4l/pixfmt-srggb10p
+media/uapi/v4l/pixfmt-srggb12 userspace-api/media/v4l/pixfmt-srggb12
+media/uapi/v4l/pixfmt-srggb12p userspace-api/media/v4l/pixfmt-srggb12p
+media/uapi/v4l/pixfmt-srggb14 userspace-api/media/v4l/pixfmt-srggb14
+media/uapi/v4l/pixfmt-srggb14p userspace-api/media/v4l/pixfmt-srggb14p
+media/uapi/v4l/pixfmt-srggb16 userspace-api/media/v4l/pixfmt-srggb16
+media/uapi/v4l/pixfmt-srggb8 userspace-api/media/v4l/pixfmt-srggb8
+media/uapi/v4l/pixfmt-tch-td08 userspace-api/media/v4l/pixfmt-tch-td08
+media/uapi/v4l/pixfmt-tch-td16 userspace-api/media/v4l/pixfmt-tch-td16
+media/uapi/v4l/pixfmt-tch-tu08 userspace-api/media/v4l/pixfmt-tch-tu08
+media/uapi/v4l/pixfmt-tch-tu16 userspace-api/media/v4l/pixfmt-tch-tu16
+media/uapi/v4l/pixfmt-uv8 userspace-api/media/v4l/pixfmt-uv8
+media/uapi/v4l/pixfmt-v4l2 userspace-api/media/v4l/pixfmt-v4l2
+media/uapi/v4l/pixfmt-v4l2-mplane userspace-api/media/v4l/pixfmt-v4l2-mplane
+media/uapi/v4l/pixfmt-y12i userspace-api/media/v4l/pixfmt-y12i
+media/uapi/v4l/pixfmt-y8i userspace-api/media/v4l/pixfmt-y8i
+media/uapi/v4l/pixfmt-z16 userspace-api/media/v4l/pixfmt-z16
+media/uapi/v4l/planar-apis userspace-api/media/v4l/planar-apis
+media/uapi/v4l/querycap userspace-api/media/v4l/querycap
+media/uapi/v4l/rw userspace-api/media/v4l/rw
+media/uapi/v4l/sdr-formats userspace-api/media/v4l/sdr-formats
+media/uapi/v4l/selection-api userspace-api/media/v4l/selection-api
+media/uapi/v4l/selection-api-002 userspace-api/media/v4l/selection-api-intro
+media/uapi/v4l/selection-api-003 userspace-api/media/v4l/selection-api-targets
+media/uapi/v4l/selection-api-004 userspace-api/media/v4l/selection-api-configuration
+media/uapi/v4l/selection-api-005 userspace-api/media/v4l/selection-api-vs-crop-api
+media/uapi/v4l/selection-api-006 userspace-api/media/v4l/selection-api-examples
+media/uapi/v4l/selection-api-configuration userspace-api/media/v4l/selection-api-configuration
+media/uapi/v4l/selection-api-examples userspace-api/media/v4l/selection-api-examples
+media/uapi/v4l/selection-api-intro userspace-api/media/v4l/selection-api-intro
+media/uapi/v4l/selection-api-targets userspace-api/media/v4l/selection-api-targets
+media/uapi/v4l/selection-api-vs-crop-api userspace-api/media/v4l/selection-api-vs-crop-api
+media/uapi/v4l/selections-common userspace-api/media/v4l/selections-common
+media/uapi/v4l/standard userspace-api/media/v4l/standard
+media/uapi/v4l/streaming-par userspace-api/media/v4l/streaming-par
+media/uapi/v4l/subdev-formats userspace-api/media/v4l/subdev-formats
+media/uapi/v4l/tch-formats userspace-api/media/v4l/tch-formats
+media/uapi/v4l/tuner userspace-api/media/v4l/tuner
+media/uapi/v4l/user-func userspace-api/media/v4l/user-func
+media/uapi/v4l/userp userspace-api/media/v4l/userp
+media/uapi/v4l/v4l2 userspace-api/media/v4l/v4l2
+media/uapi/v4l/v4l2-selection-flags userspace-api/media/v4l/v4l2-selection-flags
+media/uapi/v4l/v4l2-selection-targets userspace-api/media/v4l/v4l2-selection-targets
+media/uapi/v4l/v4l2grab-example userspace-api/media/v4l/v4l2grab-example
+media/uapi/v4l/v4l2grab.c userspace-api/media/v4l/v4l2grab.c
+media/uapi/v4l/video userspace-api/media/v4l/video
+media/uapi/v4l/videodev userspace-api/media/v4l/videodev
+media/uapi/v4l/vidioc-create-bufs userspace-api/media/v4l/vidioc-create-bufs
+media/uapi/v4l/vidioc-cropcap userspace-api/media/v4l/vidioc-cropcap
+media/uapi/v4l/vidioc-dbg-g-chip-info userspace-api/media/v4l/vidioc-dbg-g-chip-info
+media/uapi/v4l/vidioc-dbg-g-register userspace-api/media/v4l/vidioc-dbg-g-register
+media/uapi/v4l/vidioc-decoder-cmd userspace-api/media/v4l/vidioc-decoder-cmd
+media/uapi/v4l/vidioc-dqevent userspace-api/media/v4l/vidioc-dqevent
+media/uapi/v4l/vidioc-dv-timings-cap userspace-api/media/v4l/vidioc-dv-timings-cap
+media/uapi/v4l/vidioc-encoder-cmd userspace-api/media/v4l/vidioc-encoder-cmd
+media/uapi/v4l/vidioc-enum-dv-timings userspace-api/media/v4l/vidioc-enum-dv-timings
+media/uapi/v4l/vidioc-enum-fmt userspace-api/media/v4l/vidioc-enum-fmt
+media/uapi/v4l/vidioc-enum-frameintervals userspace-api/media/v4l/vidioc-enum-frameintervals
+media/uapi/v4l/vidioc-enum-framesizes userspace-api/media/v4l/vidioc-enum-framesizes
+media/uapi/v4l/vidioc-enum-freq-bands userspace-api/media/v4l/vidioc-enum-freq-bands
+media/uapi/v4l/vidioc-enumaudio userspace-api/media/v4l/vidioc-enumaudio
+media/uapi/v4l/vidioc-enumaudioout userspace-api/media/v4l/vidioc-enumaudioout
+media/uapi/v4l/vidioc-enuminput userspace-api/media/v4l/vidioc-enuminput
+media/uapi/v4l/vidioc-enumoutput userspace-api/media/v4l/vidioc-enumoutput
+media/uapi/v4l/vidioc-enumstd userspace-api/media/v4l/vidioc-enumstd
+media/uapi/v4l/vidioc-expbuf userspace-api/media/v4l/vidioc-expbuf
+media/uapi/v4l/vidioc-g-audio userspace-api/media/v4l/vidioc-g-audio
+media/uapi/v4l/vidioc-g-audioout userspace-api/media/v4l/vidioc-g-audioout
+media/uapi/v4l/vidioc-g-crop userspace-api/media/v4l/vidioc-g-crop
+media/uapi/v4l/vidioc-g-ctrl userspace-api/media/v4l/vidioc-g-ctrl
+media/uapi/v4l/vidioc-g-dv-timings userspace-api/media/v4l/vidioc-g-dv-timings
+media/uapi/v4l/vidioc-g-edid userspace-api/media/v4l/vidioc-g-edid
+media/uapi/v4l/vidioc-g-enc-index userspace-api/media/v4l/vidioc-g-enc-index
+media/uapi/v4l/vidioc-g-ext-ctrls userspace-api/media/v4l/vidioc-g-ext-ctrls
+media/uapi/v4l/vidioc-g-fbuf userspace-api/media/v4l/vidioc-g-fbuf
+media/uapi/v4l/vidioc-g-fmt userspace-api/media/v4l/vidioc-g-fmt
+media/uapi/v4l/vidioc-g-frequency userspace-api/media/v4l/vidioc-g-frequency
+media/uapi/v4l/vidioc-g-input userspace-api/media/v4l/vidioc-g-input
+media/uapi/v4l/vidioc-g-jpegcomp userspace-api/media/v4l/vidioc-g-jpegcomp
+media/uapi/v4l/vidioc-g-modulator userspace-api/media/v4l/vidioc-g-modulator
+media/uapi/v4l/vidioc-g-output userspace-api/media/v4l/vidioc-g-output
+media/uapi/v4l/vidioc-g-parm userspace-api/media/v4l/vidioc-g-parm
+media/uapi/v4l/vidioc-g-priority userspace-api/media/v4l/vidioc-g-priority
+media/uapi/v4l/vidioc-g-selection userspace-api/media/v4l/vidioc-g-selection
+media/uapi/v4l/vidioc-g-sliced-vbi-cap userspace-api/media/v4l/vidioc-g-sliced-vbi-cap
+media/uapi/v4l/vidioc-g-std userspace-api/media/v4l/vidioc-g-std
+media/uapi/v4l/vidioc-g-tuner userspace-api/media/v4l/vidioc-g-tuner
+media/uapi/v4l/vidioc-log-status userspace-api/media/v4l/vidioc-log-status
+media/uapi/v4l/vidioc-overlay userspace-api/media/v4l/vidioc-overlay
+media/uapi/v4l/vidioc-prepare-buf userspace-api/media/v4l/vidioc-prepare-buf
+media/uapi/v4l/vidioc-qbuf userspace-api/media/v4l/vidioc-qbuf
+media/uapi/v4l/vidioc-query-dv-timings userspace-api/media/v4l/vidioc-query-dv-timings
+media/uapi/v4l/vidioc-querybuf userspace-api/media/v4l/vidioc-querybuf
+media/uapi/v4l/vidioc-querycap userspace-api/media/v4l/vidioc-querycap
+media/uapi/v4l/vidioc-queryctrl userspace-api/media/v4l/vidioc-queryctrl
+media/uapi/v4l/vidioc-querystd userspace-api/media/v4l/vidioc-querystd
+media/uapi/v4l/vidioc-reqbufs userspace-api/media/v4l/vidioc-reqbufs
+media/uapi/v4l/vidioc-s-hw-freq-seek userspace-api/media/v4l/vidioc-s-hw-freq-seek
+media/uapi/v4l/vidioc-streamon userspace-api/media/v4l/vidioc-streamon
+media/uapi/v4l/vidioc-subdev-enum-frame-interval userspace-api/media/v4l/vidioc-subdev-enum-frame-interval
+media/uapi/v4l/vidioc-subdev-enum-frame-size userspace-api/media/v4l/vidioc-subdev-enum-frame-size
+media/uapi/v4l/vidioc-subdev-enum-mbus-code userspace-api/media/v4l/vidioc-subdev-enum-mbus-code
+media/uapi/v4l/vidioc-subdev-g-crop userspace-api/media/v4l/vidioc-subdev-g-crop
+media/uapi/v4l/vidioc-subdev-g-fmt userspace-api/media/v4l/vidioc-subdev-g-fmt
+media/uapi/v4l/vidioc-subdev-g-frame-interval userspace-api/media/v4l/vidioc-subdev-g-frame-interval
+media/uapi/v4l/vidioc-subdev-g-selection userspace-api/media/v4l/vidioc-subdev-g-selection
+media/uapi/v4l/vidioc-subscribe-event userspace-api/media/v4l/vidioc-subscribe-event
+media/uapi/v4l/yuv-formats userspace-api/media/v4l/yuv-formats
+media/v4l-drivers/au0828-cardlist admin-guide/media/au0828-cardlist
+media/v4l-drivers/bttv admin-guide/media/bttv
+media/v4l-drivers/bttv-cardlist admin-guide/media/bttv-cardlist
+media/v4l-drivers/bttv-devel driver-api/media/drivers/bttv-devel
+media/v4l-drivers/cafe_ccic admin-guide/media/cafe_ccic
+media/v4l-drivers/cardlist admin-guide/media/cardlist
+media/v4l-drivers/cx2341x driver-api/media/drivers/cx2341x-devel
+media/v4l-drivers/cx2341x-devel driver-api/media/drivers/cx2341x-devel
+media/v4l-drivers/cx2341x-uapi userspace-api/media/drivers/cx2341x-uapi
+media/v4l-drivers/cx23885-cardlist admin-guide/media/cx23885-cardlist
+media/v4l-drivers/cx88 admin-guide/media/cx88
+media/v4l-drivers/cx88-cardlist admin-guide/media/cx88-cardlist
+media/v4l-drivers/cx88-devel driver-api/media/drivers/cx88-devel
+media/v4l-drivers/em28xx-cardlist admin-guide/media/em28xx-cardlist
+media/v4l-drivers/fimc admin-guide/media/fimc
+media/v4l-drivers/fimc-devel driver-api/media/drivers/fimc-devel
+media/v4l-drivers/fourcc userspace-api/media/v4l/fourcc
+media/v4l-drivers/gspca-cardlist admin-guide/media/gspca-cardlist
+media/v4l-drivers/imx admin-guide/media/imx
+media/v4l-drivers/imx-uapi userspace-api/media/drivers/imx-uapi
+media/v4l-drivers/imx7 admin-guide/media/imx7
+media/v4l-drivers/index userspace-api/media/drivers/index
+media/v4l-drivers/ipu3 admin-guide/media/ipu3
+media/v4l-drivers/ivtv admin-guide/media/ivtv
+media/v4l-drivers/ivtv-cardlist admin-guide/media/ivtv-cardlist
+media/v4l-drivers/max2175 userspace-api/media/drivers/max2175
+media/v4l-drivers/omap3isp admin-guide/media/omap3isp
+media/v4l-drivers/omap3isp-uapi userspace-api/media/drivers/omap3isp-uapi
+media/v4l-drivers/philips admin-guide/media/philips
+media/v4l-drivers/pvrusb2 driver-api/media/drivers/pvrusb2
+media/v4l-drivers/pxa_camera driver-api/media/drivers/pxa_camera
+media/v4l-drivers/qcom_camss admin-guide/media/qcom_camss
+media/v4l-drivers/radiotrack driver-api/media/drivers/radiotrack
+media/v4l-drivers/rcar-fdp1 admin-guide/media/rcar-fdp1
+media/v4l-drivers/saa7134 admin-guide/media/saa7134
+media/v4l-drivers/saa7134-cardlist admin-guide/media/saa7134-cardlist
+media/v4l-drivers/saa7134-devel driver-api/media/drivers/saa7134-devel
+media/v4l-drivers/saa7164-cardlist admin-guide/media/saa7164-cardlist
+media/v4l-drivers/sh_mobile_ceu_camera driver-api/media/drivers/sh_mobile_ceu_camera
+media/v4l-drivers/si470x admin-guide/media/si470x
+media/v4l-drivers/si4713 admin-guide/media/si4713
+media/v4l-drivers/si476x admin-guide/media/si476x
+media/v4l-drivers/tuner-cardlist admin-guide/media/tuner-cardlist
+media/v4l-drivers/tuners driver-api/media/drivers/tuners
+media/v4l-drivers/uvcvideo userspace-api/media/drivers/uvcvideo
+media/v4l-drivers/v4l-with-ir admin-guide/media/remote-controller
+media/v4l-drivers/vimc admin-guide/media/vimc
+media/v4l-drivers/vimc-devel driver-api/media/drivers/vimc-devel
+media/v4l-drivers/vivid admin-guide/media/vivid
+media/v4l-drivers/zoran driver-api/media/drivers/zoran
+memory-devices/ti-emif driver-api/memory-devices/ti-emif
+mips/booting arch/mips/booting
+mips/features arch/mips/features
+mips/index arch/mips/index
+mips/ingenic-tcu arch/mips/ingenic-tcu
+mm/slub admin-guide/mm/slab
+mmc/index driver-api/mmc/index
+mmc/mmc-async-req driver-api/mmc/mmc-async-req
+mmc/mmc-dev-attrs driver-api/mmc/mmc-dev-attrs
+mmc/mmc-dev-parts driver-api/mmc/mmc-dev-parts
+mmc/mmc-tools driver-api/mmc/mmc-tools
+mtd/index driver-api/mtd/index
+mtd/intel-spi driver-api/mtd/spi-intel
+mtd/nand_ecc driver-api/mtd/nand_ecc
+mtd/spi-nor driver-api/mtd/spi-nor
+namespaces/compatibility-list admin-guide/namespaces/compatibility-list
+namespaces/index admin-guide/namespaces/index
+namespaces/resource-control admin-guide/namespaces/resource-control
+networking/altera_tse networking/device_drivers/ethernet/altera/altera_tse
+networking/baycom networking/device_drivers/hamradio/baycom
+networking/bpf_flow_dissector bpf/prog_flow_dissector
+networking/cxacru networking/device_drivers/atm/cxacru
+networking/defza networking/device_drivers/fddi/defza
+networking/device_drivers/3com/3c509 networking/device_drivers/ethernet/3com/3c509
+networking/device_drivers/3com/vortex networking/device_drivers/ethernet/3com/vortex
+networking/device_drivers/amazon/ena networking/device_drivers/ethernet/amazon/ena
+networking/device_drivers/aquantia/atlantic networking/device_drivers/ethernet/aquantia/atlantic
+networking/device_drivers/chelsio/cxgb networking/device_drivers/ethernet/chelsio/cxgb
+networking/device_drivers/cirrus/cs89x0 networking/device_drivers/ethernet/cirrus/cs89x0
+networking/device_drivers/davicom/dm9000 networking/device_drivers/ethernet/davicom/dm9000
+networking/device_drivers/dec/dmfe networking/device_drivers/ethernet/dec/dmfe
+networking/device_drivers/dlink/dl2k networking/device_drivers/ethernet/dlink/dl2k
+networking/device_drivers/freescale/dpaa networking/device_drivers/ethernet/freescale/dpaa
+networking/device_drivers/freescale/dpaa2/dpio-driver networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver
+networking/device_drivers/freescale/dpaa2/ethernet-driver networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver
+networking/device_drivers/freescale/dpaa2/index networking/device_drivers/ethernet/freescale/dpaa2/index
+networking/device_drivers/freescale/dpaa2/mac-phy-support networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support
+networking/device_drivers/freescale/dpaa2/overview networking/device_drivers/ethernet/freescale/dpaa2/overview
+networking/device_drivers/freescale/gianfar networking/device_drivers/ethernet/freescale/gianfar
+networking/device_drivers/google/gve networking/device_drivers/ethernet/google/gve
+networking/device_drivers/intel/e100 networking/device_drivers/ethernet/intel/e100
+networking/device_drivers/intel/e1000 networking/device_drivers/ethernet/intel/e1000
+networking/device_drivers/intel/e1000e networking/device_drivers/ethernet/intel/e1000e
+networking/device_drivers/intel/fm10k networking/device_drivers/ethernet/intel/fm10k
+networking/device_drivers/intel/i40e networking/device_drivers/ethernet/intel/i40e
+networking/device_drivers/intel/iavf networking/device_drivers/ethernet/intel/iavf
+networking/device_drivers/intel/ice networking/device_drivers/ethernet/intel/ice
+networking/device_drivers/intel/igb networking/device_drivers/ethernet/intel/igb
+networking/device_drivers/intel/igbvf networking/device_drivers/ethernet/intel/igbvf
+networking/device_drivers/intel/ipw2100 networking/device_drivers/wifi/intel/ipw2100
+networking/device_drivers/intel/ipw2200 networking/device_drivers/wifi/intel/ipw2200
+networking/device_drivers/intel/ixgbe networking/device_drivers/ethernet/intel/ixgbe
+networking/device_drivers/intel/ixgbevf networking/device_drivers/ethernet/intel/ixgbevf
+networking/device_drivers/marvell/octeontx2 networking/device_drivers/ethernet/marvell/octeontx2
+networking/device_drivers/microsoft/netvsc networking/device_drivers/ethernet/microsoft/netvsc
+networking/device_drivers/neterion/s2io networking/device_drivers/ethernet/neterion/s2io
+networking/device_drivers/netronome/nfp networking/device_drivers/ethernet/netronome/nfp
+networking/device_drivers/pensando/ionic networking/device_drivers/ethernet/pensando/ionic
+networking/device_drivers/qualcomm/rmnet networking/device_drivers/cellular/qualcomm/rmnet
+networking/device_drivers/smsc/smc9 networking/device_drivers/ethernet/smsc/smc9
+networking/device_drivers/stmicro/stmmac networking/device_drivers/ethernet/stmicro/stmmac
+networking/device_drivers/ti/cpsw networking/device_drivers/ethernet/ti/cpsw
+networking/device_drivers/ti/cpsw_switchdev networking/device_drivers/ethernet/ti/cpsw_switchdev
+networking/device_drivers/ti/tlan networking/device_drivers/ethernet/ti/tlan
+networking/devlink-trap networking/devlink/devlink-trap
+networking/dpaa2/dpio-driver networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver
+networking/dpaa2/ethernet-driver networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver
+networking/dpaa2/index networking/device_drivers/ethernet/freescale/dpaa2/index
+networking/dpaa2/overview networking/device_drivers/ethernet/freescale/dpaa2/overview
+networking/e100 networking/device_drivers/ethernet/intel/e100
+networking/e1000 networking/device_drivers/ethernet/intel/e1000
+networking/e1000e networking/device_drivers/ethernet/intel/e1000e
+networking/fm10k networking/device_drivers/ethernet/intel/fm10k
+networking/fore200e networking/device_drivers/atm/fore200e
+networking/hinic networking/device_drivers/ethernet/huawei/hinic
+networking/i40e networking/device_drivers/ethernet/intel/i40e
+networking/iavf networking/device_drivers/ethernet/intel/iavf
+networking/ice networking/device_drivers/ethernet/intel/ice
+networking/igb networking/device_drivers/ethernet/intel/igb
+networking/igbvf networking/device_drivers/ethernet/intel/igbvf
+networking/iphase networking/device_drivers/atm/iphase
+networking/ixgbe networking/device_drivers/ethernet/intel/ixgbe
+networking/ixgbevf networking/device_drivers/ethernet/intel/ixgbevf
+networking/netdev-FAQ process/maintainer-netdev
+networking/skfp networking/device_drivers/fddi/skfp
+networking/z8530drv networking/device_drivers/hamradio/z8530drv
+nfc/index driver-api/nfc/index
+nfc/nfc-hci driver-api/nfc/nfc-hci
+nfc/nfc-pn544 driver-api/nfc/nfc-pn544
+nios2/features arch/nios2/features
+nios2/index arch/nios2/index
+nios2/nios2 arch/nios2/nios2
+nvdimm/btt driver-api/nvdimm/btt
+nvdimm/index driver-api/nvdimm/index
+nvdimm/nvdimm driver-api/nvdimm/nvdimm
+nvdimm/security driver-api/nvdimm/security
+nvmem/nvmem driver-api/nvmem
+openrisc/features arch/openrisc/features
+openrisc/index arch/openrisc/index
+openrisc/openrisc_port arch/openrisc/openrisc_port
+openrisc/todo arch/openrisc/todo
+parisc/debugging arch/parisc/debugging
+parisc/features arch/parisc/features
+parisc/index arch/parisc/index
+parisc/registers arch/parisc/registers
+perf/arm-ccn admin-guide/perf/arm-ccn
+perf/arm_dsu_pmu admin-guide/perf/arm_dsu_pmu
+perf/hisi-pmu admin-guide/perf/hisi-pmu
+perf/index admin-guide/perf/index
+perf/qcom_l2_pmu admin-guide/perf/qcom_l2_pmu
+perf/qcom_l3_pmu admin-guide/perf/qcom_l3_pmu
+perf/thunderx2-pmu admin-guide/perf/thunderx2-pmu
+perf/xgene-pmu admin-guide/perf/xgene-pmu
+phy/samsung-usb2 driver-api/phy/samsung-usb2
+powerpc/associativity arch/powerpc/associativity
+powerpc/booting arch/powerpc/booting
+powerpc/bootwrapper arch/powerpc/bootwrapper
+powerpc/cpu_families arch/powerpc/cpu_families
+powerpc/cpu_features arch/powerpc/cpu_features
+powerpc/dawr-power9 arch/powerpc/dawr-power9
+powerpc/dexcr arch/powerpc/dexcr
+powerpc/dscr arch/powerpc/dscr
+powerpc/eeh-pci-error-recovery arch/powerpc/eeh-pci-error-recovery
+powerpc/elf_hwcaps arch/powerpc/elf_hwcaps
+powerpc/elfnote arch/powerpc/elfnote
+powerpc/features arch/powerpc/features
+powerpc/firmware-assisted-dump arch/powerpc/firmware-assisted-dump
+powerpc/hvcs arch/powerpc/hvcs
+powerpc/imc arch/powerpc/imc
+powerpc/index arch/powerpc/index
+powerpc/isa-versions arch/powerpc/isa-versions
+powerpc/kaslr-booke32 arch/powerpc/kaslr-booke32
+powerpc/mpc52xx arch/powerpc/mpc52xx
+powerpc/papr_hcalls arch/powerpc/papr_hcalls
+powerpc/pci_iov_resource_on_powernv arch/powerpc/pci_iov_resource_on_powernv
+powerpc/pmu-ebb arch/powerpc/pmu-ebb
+powerpc/ptrace arch/powerpc/ptrace
+powerpc/qe_firmware arch/powerpc/qe_firmware
+powerpc/syscall64-abi arch/powerpc/syscall64-abi
+powerpc/transactional_memory arch/powerpc/transactional_memory
+powerpc/ultravisor arch/powerpc/ultravisor
+powerpc/vas-api arch/powerpc/vas-api
+powerpc/vcpudispatch_stats arch/powerpc/vcpudispatch_stats
+powerpc/vmemmap_dedup arch/powerpc/vmemmap_dedup
+process/clang-format dev-tools/clang-format
+process/magic-number staging/magic-number
+process/unaligned-memory-access core-api/unaligned-memory-access
+rapidio/index driver-api/rapidio/index
+rapidio/mport_cdev driver-api/rapidio/mport_cdev
+rapidio/rapidio driver-api/rapidio/rapidio
+rapidio/rio_cm driver-api/rapidio/rio_cm
+rapidio/sysfs driver-api/rapidio/sysfs
+rapidio/tsi721 driver-api/rapidio/tsi721
+riscv/acpi arch/riscv/acpi
+riscv/boot arch/riscv/boot
+riscv/boot-image-header arch/riscv/boot-image-header
+riscv/features arch/riscv/features
+riscv/hwprobe arch/riscv/hwprobe
+riscv/index arch/riscv/index
+riscv/patch-acceptance arch/riscv/patch-acceptance
+riscv/uabi arch/riscv/uabi
+riscv/vector arch/riscv/vector
+riscv/vm-layout arch/riscv/vm-layout
+s390/3270 arch/s390/3270
+s390/cds arch/s390/cds
+s390/common_io arch/s390/common_io
+s390/driver-model arch/s390/driver-model
+s390/features arch/s390/features
+s390/index arch/s390/index
+s390/monreader arch/s390/monreader
+s390/pci arch/s390/pci
+s390/qeth arch/s390/qeth
+s390/s390dbf arch/s390/s390dbf
+s390/text_files arch/s390/text_files
+s390/vfio-ap arch/s390/vfio-ap
+s390/vfio-ap-locking arch/s390/vfio-ap-locking
+s390/vfio-ccw arch/s390/vfio-ccw
+s390/zfcpdump arch/s390/zfcpdump
+security/LSM security/lsm-development
+security/LSM-sctp security/SCTP
+serial/driver driver-api/serial/driver
+serial/index driver-api/serial/index
+serial/moxa-smartio driver-api/tty/moxa-smartio
+serial/n_gsm driver-api/tty/n_gsm
+serial/serial-iso7816 driver-api/serial/serial-iso7816
+serial/serial-rs485 driver-api/serial/serial-rs485
+serial/tty driver-api/tty/tty_ldisc
+sh/booting arch/sh/booting
+sh/features arch/sh/features
+sh/index arch/sh/index
+sh/new-machine arch/sh/new-machine
+sh/register-banks arch/sh/register-banks
+sparc/adi arch/sparc/adi
+sparc/console arch/sparc/console
+sparc/features arch/sparc/features
+sparc/index arch/sparc/index
+sparc/oradax/oracle-dax arch/sparc/oradax/oracle-dax
+staging/kprobes trace/kprobes
+sysctl/abi admin-guide/sysctl/abi
+sysctl/fs admin-guide/sysctl/fs
+sysctl/index admin-guide/sysctl/index
+sysctl/kernel admin-guide/sysctl/kernel
+sysctl/net admin-guide/sysctl/net
+sysctl/sunrpc admin-guide/sysctl/sunrpc
+sysctl/user admin-guide/sysctl/user
+sysctl/vm admin-guide/sysctl/vm
+thermal/cpu-cooling-api driver-api/thermal/cpu-cooling-api
+thermal/exynos_thermal driver-api/thermal/exynos_thermal
+thermal/exynos_thermal_emulation driver-api/thermal/exynos_thermal_emulation
+thermal/index driver-api/thermal/index
+thermal/intel_powerclamp admin-guide/thermal/intel_powerclamp
+thermal/nouveau_thermal driver-api/thermal/nouveau_thermal
+thermal/power_allocator driver-api/thermal/power_allocator
+thermal/sysfs-api driver-api/thermal/sysfs-api
+thermal/x86_pkg_temperature_thermal driver-api/thermal/x86_pkg_temperature_thermal
+tpm/index security/tpm/index
+tpm/tpm_vtpm_proxy security/tpm/tpm_vtpm_proxy
+trace/coresight trace/coresight/coresight
+trace/coresight-cpu-debug trace/coresight/coresight-cpu-debug
+trace/rv/da_monitor_synthesis trace/rv/monitor_synthesis
+translations/it_IT/admin-guide/security-bugs translations/it_IT/process/security-bugs
+translations/it_IT/process/clang-format translations/it_IT/dev-tools/clang-format
+translations/it_IT/process/magic-number translations/it_IT/staging/magic-number
+translations/it_IT/riscv/patch-acceptance translations/it_IT/arch/riscv/patch-acceptance
+translations/ja_JP/howto translations/ja_JP/process/howto
+translations/ko_KR/howto translations/ko_KR/process/howto
+translations/sp_SP/howto translations/sp_SP/process/howto
+translations/sp_SP/submitting-patches translations/sp_SP/process/submitting-patches
+translations/zh_CN/admin-guide/security-bugs translations/zh_CN/process/security-bugs
+translations/zh_CN/arch translations/zh_CN/arch/index
+translations/zh_CN/arm64/amu translations/zh_CN/arch/arm64/amu
+translations/zh_CN/arm64/elf_hwcaps translations/zh_CN/arch/arm64/elf_hwcaps
+translations/zh_CN/arm64/hugetlbpage translations/zh_CN/arch/arm64/hugetlbpage
+translations/zh_CN/arm64/index translations/zh_CN/arch/arm64/index
+translations/zh_CN/arm64/perf translations/zh_CN/arch/arm64/perf
+translations/zh_CN/coding-style translations/zh_CN/process/coding-style
+translations/zh_CN/loongarch/booting translations/zh_CN/arch/loongarch/booting
+translations/zh_CN/loongarch/features translations/zh_CN/arch/loongarch/features
+translations/zh_CN/loongarch/index translations/zh_CN/arch/loongarch/index
+translations/zh_CN/loongarch/introduction translations/zh_CN/arch/loongarch/introduction
+translations/zh_CN/loongarch/irq-chip-model translations/zh_CN/arch/loongarch/irq-chip-model
+translations/zh_CN/mips/booting translations/zh_CN/arch/mips/booting
+translations/zh_CN/mips/features translations/zh_CN/arch/mips/features
+translations/zh_CN/mips/index translations/zh_CN/arch/mips/index
+translations/zh_CN/mips/ingenic-tcu translations/zh_CN/arch/mips/ingenic-tcu
+translations/zh_CN/openrisc/index translations/zh_CN/arch/openrisc/index
+translations/zh_CN/openrisc/openrisc_port translations/zh_CN/arch/openrisc/openrisc_port
+translations/zh_CN/openrisc/todo translations/zh_CN/arch/openrisc/todo
+translations/zh_CN/parisc/debugging translations/zh_CN/arch/parisc/debugging
+translations/zh_CN/parisc/index translations/zh_CN/arch/parisc/index
+translations/zh_CN/parisc/registers translations/zh_CN/arch/parisc/registers
+translations/zh_CN/riscv/boot-image-header translations/zh_CN/arch/riscv/boot-image-header
+translations/zh_CN/riscv/index translations/zh_CN/arch/riscv/index
+translations/zh_CN/riscv/patch-acceptance translations/zh_CN/arch/riscv/patch-acceptance
+translations/zh_CN/riscv/vm-layout translations/zh_CN/arch/riscv/vm-layout
+translations/zh_CN/vm/active_mm translations/zh_CN/mm/active_mm
+translations/zh_CN/vm/balance translations/zh_CN/mm/balance
+translations/zh_CN/vm/damon/api translations/zh_CN/mm/damon/api
+translations/zh_CN/vm/damon/design translations/zh_CN/mm/damon/design
+translations/zh_CN/vm/damon/faq translations/zh_CN/mm/damon/faq
+translations/zh_CN/vm/damon/index translations/zh_CN/mm/damon/index
+translations/zh_CN/vm/free_page_reporting translations/zh_CN/mm/free_page_reporting
+translations/zh_CN/vm/highmem translations/zh_CN/mm/highmem
+translations/zh_CN/vm/hmm translations/zh_CN/mm/hmm
+translations/zh_CN/vm/hugetlbfs_reserv translations/zh_CN/mm/hugetlbfs_reserv
+translations/zh_CN/vm/hwpoison translations/zh_CN/mm/hwpoison
+translations/zh_CN/vm/index translations/zh_CN/mm/index
+translations/zh_CN/vm/ksm translations/zh_CN/mm/ksm
+translations/zh_CN/vm/memory-model translations/zh_CN/mm/memory-model
+translations/zh_CN/vm/mmu_notifier translations/zh_CN/mm/mmu_notifier
+translations/zh_CN/vm/numa translations/zh_CN/mm/numa
+translations/zh_CN/vm/overcommit-accounting translations/zh_CN/mm/overcommit-accounting
+translations/zh_CN/vm/page_frags translations/zh_CN/mm/page_frags
+translations/zh_CN/vm/page_owner translations/zh_CN/mm/page_owner
+translations/zh_CN/vm/page_table_check translations/zh_CN/mm/page_table_check
+translations/zh_CN/vm/remap_file_pages translations/zh_CN/mm/remap_file_pages
+translations/zh_CN/vm/split_page_table_lock translations/zh_CN/mm/split_page_table_lock
+translations/zh_CN/vm/zsmalloc translations/zh_CN/mm/zsmalloc
+translations/zh_TW/arm64/amu translations/zh_TW/arch/arm64/amu
+translations/zh_TW/arm64/elf_hwcaps translations/zh_TW/arch/arm64/elf_hwcaps
+translations/zh_TW/arm64/hugetlbpage translations/zh_TW/arch/arm64/hugetlbpage
+translations/zh_TW/arm64/index translations/zh_TW/arch/arm64/index
+translations/zh_TW/arm64/perf translations/zh_TW/arch/arm64/perf
+tty/device_drivers/oxsemi-tornado misc-devices/oxsemi-tornado
+tty/index driver-api/tty/index
+tty/n_tty driver-api/tty/n_tty
+tty/tty_buffer driver-api/tty/tty_buffer
+tty/tty_driver driver-api/tty/tty_driver
+tty/tty_internals driver-api/tty/tty_internals
+tty/tty_ldisc driver-api/tty/tty_ldisc
+tty/tty_port driver-api/tty/tty_port
+tty/tty_struct driver-api/tty/tty_struct
+usb/typec driver-api/usb/typec
+usb/usb3-debug-port driver-api/usb/usb3-debug-port
+userspace-api/media/drivers/st-vgxy61 userspace-api/media/drivers/vgxy61
+userspace-api/media/v4l/pixfmt-meta-d4xx userspace-api/media/v4l/metafmt-d4xx
+userspace-api/media/v4l/pixfmt-meta-intel-ipu3 userspace-api/media/v4l/metafmt-intel-ipu3
+userspace-api/media/v4l/pixfmt-meta-rkisp1 userspace-api/media/v4l/metafmt-rkisp1
+userspace-api/media/v4l/pixfmt-meta-uvc userspace-api/media/v4l/metafmt-uvc
+userspace-api/media/v4l/pixfmt-meta-vivid userspace-api/media/v4l/metafmt-vivid
+userspace-api/media/v4l/pixfmt-meta-vsp1-hgo userspace-api/media/v4l/metafmt-vsp1-hgo
+userspace-api/media/v4l/pixfmt-meta-vsp1-hgt userspace-api/media/v4l/metafmt-vsp1-hgt
+virt/coco/sevguest virt/coco/sev-guest
+virt/kvm/amd-memory-encryption virt/kvm/x86/amd-memory-encryption
+virt/kvm/arm/psci virt/kvm/arm/fw-pseudo-registers
+virt/kvm/cpuid virt/kvm/x86/cpuid
+virt/kvm/hypercalls virt/kvm/x86/hypercalls
+virt/kvm/mmu virt/kvm/x86/mmu
+virt/kvm/msr virt/kvm/x86/msr
+virt/kvm/nested-vmx virt/kvm/x86/nested-vmx
+virt/kvm/running-nested-guests virt/kvm/x86/running-nested-guests
+virt/kvm/s390-diag virt/kvm/s390/s390-diag
+virt/kvm/s390-pv virt/kvm/s390/s390-pv
+virt/kvm/s390-pv-boot virt/kvm/s390/s390-pv-boot
+virt/kvm/timekeeping virt/kvm/x86/timekeeping
+virt/kvm/x86/halt-polling virt/kvm/halt-polling
+virtual/index virt/index
+virtual/kvm/amd-memory-encryption virt/kvm/x86/amd-memory-encryption
+virtual/kvm/cpuid virt/kvm/x86/cpuid
+virtual/kvm/index virt/kvm/index
+virtual/kvm/vcpu-requests virt/kvm/vcpu-requests
+virtual/paravirt_ops virt/paravirt_ops
+vm/active_mm mm/active_mm
+vm/arch_pgtable_helpers mm/arch_pgtable_helpers
+vm/balance mm/balance
+vm/bootmem mm/bootmem
+vm/damon/api mm/damon/api
+vm/damon/design mm/damon/design
+vm/damon/faq mm/damon/faq
+vm/damon/index mm/damon/index
+vm/free_page_reporting mm/free_page_reporting
+vm/highmem mm/highmem
+vm/hmm mm/hmm
+vm/hugetlbfs_reserv mm/hugetlbfs_reserv
+vm/hugetlbpage admin-guide/mm/hugetlbpage
+vm/hwpoison mm/hwpoison
+vm/idle_page_tracking admin-guide/mm/idle_page_tracking
+vm/index mm/index
+vm/ksm mm/ksm
+vm/memory-model mm/memory-model
+vm/mmu_notifier mm/mmu_notifier
+vm/numa mm/numa
+vm/numa_memory_policy admin-guide/mm/numa_memory_policy
+vm/oom mm/oom
+vm/overcommit-accounting mm/overcommit-accounting
+vm/page_allocation mm/page_allocation
+vm/page_cache mm/page_cache
+vm/page_frags mm/page_frags
+vm/page_migration mm/page_migration
+vm/page_owner mm/page_owner
+vm/page_reclaim mm/page_reclaim
+vm/page_table_check mm/page_table_check
+vm/page_tables mm/page_tables
+vm/pagemap admin-guide/mm/pagemap
+vm/physical_memory mm/physical_memory
+vm/process_addrs mm/process_addrs
+vm/remap_file_pages mm/remap_file_pages
+vm/shmfs mm/shmfs
+vm/slab mm/slab
+vm/slub admin-guide/mm/slab
+vm/soft-dirty admin-guide/mm/soft-dirty
+vm/split_page_table_lock mm/split_page_table_lock
+vm/swap mm/swap
+vm/swap_numa admin-guide/mm/swap_numa
+vm/transhuge mm/transhuge
+vm/unevictable-lru mm/unevictable-lru
+vm/userfaultfd admin-guide/mm/userfaultfd
+vm/vmalloc mm/vmalloc
+vm/vmalloced-kernel-stacks mm/vmalloced-kernel-stacks
+vm/vmemmap_dedup mm/vmemmap_dedup
+vm/zsmalloc mm/zsmalloc
+vm/zswap admin-guide/mm/zswap
+watch_queue core-api/watch_queue
+x86/amd-memory-encryption arch/x86/amd-memory-encryption
+x86/amd_hsmp arch/x86/amd_hsmp
+x86/boot arch/x86/boot
+x86/booting-dt arch/x86/booting-dt
+x86/buslock arch/x86/buslock
+x86/cpuinfo arch/x86/cpuinfo
+x86/earlyprintk arch/x86/earlyprintk
+x86/elf_auxvec arch/x86/elf_auxvec
+x86/entry_64 arch/x86/entry_64
+x86/exception-tables arch/x86/exception-tables
+x86/features arch/x86/features
+x86/i386/IO-APIC arch/x86/i386/IO-APIC
+x86/i386/index arch/x86/i386/index
+x86/ifs arch/x86/ifs
+x86/index arch/x86/index
+x86/intel-hfi arch/x86/intel-hfi
+x86/intel_txt arch/x86/intel_txt
+x86/iommu arch/x86/iommu
+x86/kernel-stacks arch/x86/kernel-stacks
+x86/mds arch/x86/mds
+x86/microcode arch/x86/microcode
+x86/mtrr arch/x86/mtrr
+x86/orc-unwinder arch/x86/orc-unwinder
+x86/pat arch/x86/pat
+x86/protection-keys core-api/protection-keys
+x86/pti arch/x86/pti
+x86/resctrl filesystems/resctrl
+x86/resctrl_ui filesystems/resctrl
+x86/sgx arch/x86/sgx
+x86/sva arch/x86/sva
+x86/tdx arch/x86/tdx
+x86/tlb arch/x86/tlb
+x86/topology arch/x86/topology
+x86/tsx_async_abort arch/x86/tsx_async_abort
+x86/usb-legacy-support arch/x86/usb-legacy-support
+x86/x86_64/5level-paging arch/x86/x86_64/5level-paging
+x86/x86_64/cpu-hotplug-spec arch/x86/x86_64/cpu-hotplug-spec
+x86/x86_64/fake-numa-for-cpusets arch/x86/x86_64/fake-numa-for-cpusets
+x86/x86_64/fsgs arch/x86/x86_64/fsgs
+x86/x86_64/index arch/x86/x86_64/index
+x86/x86_64/machinecheck arch/x86/x86_64/machinecheck
+x86/x86_64/mm arch/x86/x86_64/mm
+x86/x86_64/uefi arch/x86/x86_64/uefi
+x86/xstate arch/x86/xstate
+x86/zero-page arch/x86/zero-page
+xilinx/eemi driver-api/xilinx/eemi
+xilinx/index driver-api/xilinx/index
+xtensa/atomctl arch/xtensa/atomctl
+xtensa/booting arch/xtensa/booting
+xtensa/features arch/xtensa/features
+xtensa/index arch/xtensa/index
+xtensa/mmu arch/xtensa/mmu
diff --git a/Documentation/ABI/README b/Documentation/ABI/README
index 8bac9cb09a6d..315fffe1f831 100644
--- a/Documentation/ABI/README
+++ b/Documentation/ABI/README
@@ -1,4 +1,5 @@
-This directory attempts to document the ABI between the Linux kernel and
+This part of the documentation inside Documentation/ABI directory
+attempts to document the ABI between the Linux kernel and
userspace, and the relative stability of these interfaces. Due to the
everchanging nature of Linux, and the differing maturity levels, these
interfaces should be used by userspace programs in different ways.
@@ -45,7 +46,9 @@ Every file in these directories will contain the following information:
What: Short description of the interface
Date: Date created
-KernelVersion: Kernel version this feature first showed up in.
+KernelVersion: (Optional) Kernel version this feature first showed up in.
+ Note: git history often provides more accurate version
+ info, so this field may be omitted.
Contact: Primary contact for this interface (may be a mailing list)
Description: Long description of the interface and how to use it.
Users: All users of this interface who wish to be notified when
diff --git a/Documentation/ABI/obsolete/automount-tracefs-debugfs b/Documentation/ABI/obsolete/automount-tracefs-debugfs
new file mode 100644
index 000000000000..a5196ec78cb5
--- /dev/null
+++ b/Documentation/ABI/obsolete/automount-tracefs-debugfs
@@ -0,0 +1,20 @@
+What: /sys/kernel/debug/tracing
+Date: May 2008
+KernelVersion: 2.6.27
+Contact: linux-trace-kernel@vger.kernel.org
+Description:
+
+ The ftrace was first added to the kernel, its interface was placed
+ into the debugfs file system under the "tracing" directory. Access
+ to the files were in /sys/kernel/debug/tracing. As systems wanted
+ access to the tracing interface without having to enable debugfs, a
+ new interface was created called "tracefs". This was a stand alone
+ file system and was usually mounted in /sys/kernel/tracing.
+
+ To allow older tooling to continue to operate, when mounting
+ debugfs, the tracefs file system would automatically get mounted in
+ the "tracing" directory of debugfs. The tracefs interface was added
+ in January 2015 in the v4.1 kernel.
+
+ All tooling should now be using tracefs directly and the "tracing"
+ directory in debugfs should be removed by January 2030.
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb
index fe7e45e17bc7..8f39b596731d 100644
--- a/Documentation/ABI/obsolete/o2cb
+++ b/Documentation/ABI/obsolete/o2cb
@@ -1,11 +1,11 @@
What: /sys/o2cb
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Was renamed to /sys/fs/u2cb/
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/obsolete/sysfs-bus-iio b/Documentation/ABI/obsolete/sysfs-bus-iio
index b64394b0b374..a13523561958 100644
--- a/Documentation/ABI/obsolete/sysfs-bus-iio
+++ b/Documentation/ABI/obsolete/sysfs-bus-iio
@@ -48,10 +48,6 @@ What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
-What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
-What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
-What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en
-What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
@@ -73,10 +69,6 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
-What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
-What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
-What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type
-What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
@@ -110,10 +102,6 @@ Description:
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
-What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
-What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
-What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index
-What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
diff --git a/Documentation/ABI/obsolete/sysfs-driver-samsung-laptop b/Documentation/ABI/obsolete/sysfs-driver-samsung-laptop
new file mode 100644
index 000000000000..204c3f3a1d78
--- /dev/null
+++ b/Documentation/ABI/obsolete/sysfs-driver-samsung-laptop
@@ -0,0 +1,10 @@
+What: /sys/devices/platform/samsung/battery_life_extender
+Date: December 1, 2011
+KernelVersion: 3.3
+Contact: Corentin Chary <corentin.chary@gmail.com>
+Description: Max battery charge level can be modified, battery cycle
+ life can be extended by reducing the max battery charge
+ level.
+
+ - 0 means normal battery mode (100% charge)
+ - 1 means battery life extender mode (80% charge)
diff --git a/Documentation/ABI/obsolete/sysfs-gpio b/Documentation/ABI/obsolete/sysfs-gpio
index b8b0fd341c17..0d3f12c4dcbd 100644
--- a/Documentation/ABI/obsolete/sysfs-gpio
+++ b/Documentation/ABI/obsolete/sysfs-gpio
@@ -19,14 +19,22 @@ Description:
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N OR
- /<LINE-NAME> ... for a properly named GPIO line
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write: high, low
/edge ... r/w as: none, falling, rising, both
+ /active_low ... r/w as: 0, 1
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
- /label ... (r/o) descriptive, not necessarily unique
+ /label ... (r/o) descriptive chip name
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
+ /gpio<OFFSET>
+ /value ... always readable, writes fail for input GPIOs
+ /direction ... r/w as: in, out (default low); write: high, low
+ /chipX ... for each gpiochip; #X is the gpio device ID
+ /export ... asks the kernel to export a GPIO at HW offset X to userspace
+ /unexport ... to return a GPIO at HW offset X to the kernel
+ /label ... (r/o) descriptive chip name
+ /ngpio ... (r/o) number of GPIOs exposed by the chip
- This ABI is deprecated and will be removed after 2020. It is
- replaced with the GPIO character device.
+ This ABI is obsoleted by Documentation/ABI/testing/gpio-cdev and will be
+ removed after 2020.
diff --git a/Documentation/ABI/obsolete/sysfs-kernel-kexec-kdump b/Documentation/ABI/obsolete/sysfs-kernel-kexec-kdump
new file mode 100644
index 000000000000..ba26a6a1d2be
--- /dev/null
+++ b/Documentation/ABI/obsolete/sysfs-kernel-kexec-kdump
@@ -0,0 +1,71 @@
+NOTE: all the ABIs listed in this file are deprecated and will be removed after 2028.
+
+Here are the alternative ABIs:
++------------------------------------+-----------------------------------------+
+| Deprecated | Alternative |
++------------------------------------+-----------------------------------------+
+| /sys/kernel/kexec_loaded | /sys/kernel/kexec/loaded |
++------------------------------------+-----------------------------------------+
+| /sys/kernel/kexec_crash_loaded | /sys/kernel/kexec/crash_loaded |
++------------------------------------+-----------------------------------------+
+| /sys/kernel/kexec_crash_size | /sys/kernel/kexec/crash_size |
++------------------------------------+-----------------------------------------+
+| /sys/kernel/crash_elfcorehdr_size | /sys/kernel/kexec/crash_elfcorehdr_size |
++------------------------------------+-----------------------------------------+
+| /sys/kernel/kexec_crash_cma_ranges | /sys/kernel/kexec/crash_cma_ranges |
++------------------------------------+-----------------------------------------+
+
+
+What: /sys/kernel/kexec_loaded
+Date: Jun 2006
+Contact: kexec@lists.infradead.org
+Description: read only
+ Indicates whether a new kernel image has been loaded
+ into memory using the kexec system call. It shows 1 if
+ a kexec image is present and ready to boot, or 0 if none
+ is loaded.
+User: kexec tools, kdump service
+
+What: /sys/kernel/kexec_crash_loaded
+Date: Jun 2006
+Contact: kexec@lists.infradead.org
+Description: read only
+ Indicates whether a crash (kdump) kernel is currently
+ loaded into memory. It shows 1 if a crash kernel has been
+ successfully loaded for panic handling, or 0 if no crash
+ kernel is present.
+User: Kexec tools, Kdump service
+
+What: /sys/kernel/kexec_crash_size
+Date: Dec 2009
+Contact: kexec@lists.infradead.org
+Description: read/write
+ Shows the amount of memory reserved for loading the crash
+ (kdump) kernel. It reports the size, in bytes, of the
+ crash kernel area defined by the crashkernel= parameter.
+ This interface also allows reducing the crashkernel
+ reservation by writing a smaller value, and the reclaimed
+ space is added back to the system RAM.
+User: Kdump service
+
+What: /sys/kernel/crash_elfcorehdr_size
+Date: Aug 2023
+Contact: kexec@lists.infradead.org
+Description: read only
+ Indicates the preferred size of the memory buffer for the
+ ELF core header used by the crash (kdump) kernel. It defines
+ how much space is needed to hold metadata about the crashed
+ system, including CPU and memory information. This information
+ is used by the user space utility kexec to support updating the
+ in-kernel kdump image during hotplug operations.
+User: Kexec tools
+
+What: /sys/kernel/kexec_crash_cma_ranges
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description: read only
+ Provides information about the memory ranges reserved from
+ the Contiguous Memory Allocator (CMA) area that are allocated
+ to the crash (kdump) kernel. It lists the start and end physical
+ addresses of CMA regions assigned for crashkernel use.
+User: kdump service
diff --git a/Documentation/ABI/obsolete/sysfs-platform-ideapad-laptop b/Documentation/ABI/obsolete/sysfs-platform-ideapad-laptop
new file mode 100644
index 000000000000..c1dbd19c679c
--- /dev/null
+++ b/Documentation/ABI/obsolete/sysfs-platform-ideapad-laptop
@@ -0,0 +1,8 @@
+What: /sys/bus/platform/devices/VPC2004:*/conservation_mode
+Date: Aug 2017
+KernelVersion: 4.14
+Contact: platform-driver-x86@vger.kernel.org
+Description:
+ Controls whether the conservation mode is enabled or not.
+ This feature limits the maximum battery charge percentage to
+ around 50-60% in order to prolong the lifetime of the battery.
diff --git a/Documentation/ABI/obsolete/sysfs-selinux-user b/Documentation/ABI/obsolete/sysfs-selinux-user
new file mode 100644
index 000000000000..8ab7557f283f
--- /dev/null
+++ b/Documentation/ABI/obsolete/sysfs-selinux-user
@@ -0,0 +1,12 @@
+What: /sys/fs/selinux/user
+Date: April 2005 (predates git)
+KernelVersion: 2.6.12-rc2 (predates git)
+Contact: selinux@vger.kernel.org
+Description:
+
+ The selinuxfs "user" node allows userspace to request a list
+ of security contexts that can be reached for a given SELinux
+ user from a given starting context. This was used by libselinux
+ when various login-style programs requested contexts for
+ users, but libselinux stopped using it in 2020.
+ Kernel support will be removed no sooner than Dec 2025.
diff --git a/Documentation/ABI/removed/o2cb b/Documentation/ABI/removed/o2cb
index 20c91adca6d4..61cff238fbe8 100644
--- a/Documentation/ABI/removed/o2cb
+++ b/Documentation/ABI/removed/o2cb
@@ -1,10 +1,10 @@
What: /sys/o2cb symlink
Date: May 2011
KernelVersion: 3.0
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is
removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/removed/sysfs-class-cxl
index 594fda254130..266c413b96e8 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/removed/sysfs-class-cxl
@@ -1,3 +1,5 @@
+The cxl driver was removed in 6.15.
+
Please note that attributes that are shared between devices are stored in
the directory pointed to by the symlink device/.
For example, the real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
@@ -7,7 +9,7 @@ For example, the real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
Slave contexts (eg. /sys/class/cxl/afu0.0s):
What: /sys/class/cxl/<afu>/afu_err_buf
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
AFU Error Buffer contents. The contents of this file are
@@ -18,7 +20,7 @@ Description: read only
What: /sys/class/cxl/<afu>/irqs_max
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Decimal value of maximum number of interrupts that can be
@@ -29,7 +31,7 @@ Description: read/write
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/irqs_min
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the minimum number of interrupts that
@@ -39,15 +41,15 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/mmio_size
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
- Decimal value of the size of the MMIO space that may be mmaped
+ Decimal value of the size of the MMIO space that may be mmapped
by userspace.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/modes_supported
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
List of the modes this AFU supports. One per line.
@@ -55,7 +57,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/mode
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
The current mode the AFU is using. Will be one of the modes
@@ -65,7 +67,7 @@ Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/prefault_mode
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Set the mode for prefaulting in segments into the segment table
@@ -85,7 +87,7 @@ Description: read/write
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/reset
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 here will reset the AFU provided there are not
@@ -93,14 +95,14 @@ Description: write only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/api_version
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the current version of the kernel/user API.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/api_version_compatible
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the lowest version of the userspace API
@@ -114,7 +116,7 @@ An AFU may optionally export one or more PCIe like configuration records, known
as AFU configuration records, which will show up here (if present).
What: /sys/class/cxl/<afu>/cr<config num>/vendor
-Date: February 2015
+Date: February 2015, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the vendor ID found in this AFU
@@ -122,7 +124,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/cr<config num>/device
-Date: February 2015
+Date: February 2015, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the device ID found in this AFU
@@ -130,7 +132,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/cr<config num>/class
-Date: February 2015
+Date: February 2015, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the class code found in this AFU
@@ -138,7 +140,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/cr<config num>/config
-Date: February 2015
+Date: February 2015, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
This binary file provides raw access to the AFU configuration
@@ -152,22 +154,22 @@ Users: https://github.com/ibm-capi/libcxl
Master contexts (eg. /sys/class/cxl/afu0.0m)
What: /sys/class/cxl/<afu>m/mmio_size
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
- Decimal value of the size of the MMIO space that may be mmaped
+ Decimal value of the size of the MMIO space that may be mmapped
by userspace. This includes all slave contexts space also.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_len
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space length.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_off
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
(not in a guest)
@@ -178,21 +180,21 @@ Users: https://github.com/ibm-capi/libcxl
Card info (eg. /sys/class/cxl/card0)
What: /sys/class/cxl/<card>/caia_version
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the CAIA Version the card implements.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/psl_revision
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the revision level of the PSL.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/base_image
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
(not in a guest)
@@ -203,7 +205,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/image_loaded
-Date: September 2014
+Date: September 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
(not in a guest)
@@ -212,7 +214,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/load_image_on_perst
-Date: December 2014
+Date: December 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
(not in a guest)
@@ -229,7 +231,7 @@ Description: read/write
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/reset
-Date: October 2014
+Date: October 2014, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 will issue a PERST to card provided there are no
@@ -240,7 +242,7 @@ Description: write only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/perst_reloads_same_image
-Date: July 2015
+Date: July 2015, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
(not in a guest)
@@ -254,7 +256,7 @@ Description: read/write
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/psl_timebase_synced
-Date: March 2016
+Date: March 2016, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Returns 1 if the psl timebase register is synchronized
@@ -262,7 +264,7 @@ Description: read only
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/tunneled_ops_supported
-Date: May 2018
+Date: May 2018, removed February 2025
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Returns 1 if tunneled operations are supported in capi mode,
diff --git a/Documentation/ABI/removed/sysfs-class-rfkill b/Documentation/ABI/removed/sysfs-class-rfkill
index f25174eafd55..20cb688af173 100644
--- a/Documentation/ABI/removed/sysfs-class-rfkill
+++ b/Documentation/ABI/removed/sysfs-class-rfkill
@@ -4,7 +4,7 @@ For details to this subsystem look at Documentation/driver-api/rfkill.rst.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
-KernelVersion v2.6.22
+KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file was deprecated because there no longer was a way to
claim just control over a single rfkill instance.
diff --git a/Documentation/ABI/removed/sysfs-firmware-efi-vars b/Documentation/ABI/removed/sysfs-firmware-efi-vars
new file mode 100644
index 000000000000..8d97368b149b
--- /dev/null
+++ b/Documentation/ABI/removed/sysfs-firmware-efi-vars
@@ -0,0 +1,12 @@
+What: /sys/firmware/efi/vars
+Date: April 2004, removed March 2023
+Description:
+ This directory exposed interfaces for interacting with
+ EFI variables. For more information on EFI variables,
+ see 'Variable Services' in the UEFI specification
+ (section 7.2 in specification version 2.3 Errata D).
+
+ The 'efivars' sysfs interface was removed in March of 2023,
+ after being considered deprecated no later than September
+ of 2020. Its functionality has been replaced by the
+ 'efivarfs' filesystem.
diff --git a/Documentation/ABI/obsolete/sysfs-selinux-checkreqprot b/Documentation/ABI/removed/sysfs-selinux-checkreqprot
index ed6b52ca210f..f599a0a87e8b 100644
--- a/Documentation/ABI/obsolete/sysfs-selinux-checkreqprot
+++ b/Documentation/ABI/removed/sysfs-selinux-checkreqprot
@@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git)
Contact: selinux@vger.kernel.org
Description:
+ REMOVAL UPDATE: The SELinux checkreqprot functionality was removed in
+ March 2023, the original deprecation notice is shown below.
+
The selinuxfs "checkreqprot" node allows SELinux to be configured
to check the protection requested by userspace for mmap/mprotect
calls instead of the actual protection applied by the kernel.
diff --git a/Documentation/ABI/obsolete/sysfs-selinux-disable b/Documentation/ABI/removed/sysfs-selinux-disable
index c340278e3cf8..cb783c64cab3 100644
--- a/Documentation/ABI/obsolete/sysfs-selinux-disable
+++ b/Documentation/ABI/removed/sysfs-selinux-disable
@@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git)
Contact: selinux@vger.kernel.org
Description:
+ REMOVAL UPDATE: The SELinux runtime disable functionality was removed
+ in March 2023, the original deprecation notice is shown below.
+
The selinuxfs "disable" node allows SELinux to be disabled at runtime
prior to a policy being loaded into the kernel. If disabled via this
mechanism, SELinux will remain disabled until the system is rebooted.
diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb
index b62a967f01a0..3a83b5c54e93 100644
--- a/Documentation/ABI/stable/o2cb
+++ b/Documentation/ABI/stable/o2cb
@@ -1,10 +1,10 @@
What: /sys/fs/o2cb/
Date: Dec 2005
KernelVersion: 2.6.16
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
- ocfs2-devel@oss.oracle.com.
+ ocfs2-devel@lists.linux.dev.
diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile
index 2d6314f0e4e4..cd55e421d921 100644
--- a/Documentation/ABI/stable/sysfs-acpi-pmprofile
+++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile
@@ -2,16 +2,17 @@ What: /sys/firmware/acpi/pm_profile
Date: 03-Nov-2011
KernelVersion: v3.2
Contact: linux-acpi@vger.kernel.org
-Description: The ACPI pm_profile sysfs interface exports the platform
- power management (and performance) requirement expectations
- as provided by BIOS. The integer value is directly passed as
- retrieved from the FADT ACPI table.
+Description: The ACPI pm_profile sysfs interface exposes the preferred
+ power management (and performance) profile of the platform
+ as provided in the ACPI FADT Preferred_PM_Profile field.
-Values: For possible values see ACPI specification:
- 5.2.9 Fixed ACPI Description Table (FADT)
- Field: Preferred_PM_Profile
+ The integer value is directly passed as retrieved from the FADT.
- Currently these values are defined by spec:
+Values: For the possible values refer to the Preferred_PM_Profile field
+ definition in Table 5.9 "FADT Format", Section 5.2.9 "Fixed ACPI
+ Description Table (FADT)" of the ACPI specification.
+
+ As of ACPI 6.5, the following values are defined:
== =================
0 Unspecified
@@ -22,5 +23,6 @@ Values: For possible values see ACPI specification:
5 SOHO Server
6 Appliance PC
7 Performance Server
- >7 Reserved
+ 8 Tablet
+ >8 Reserved
== =================
diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block
index cd14ecb3c9a5..0ed10aeff86b 100644
--- a/Documentation/ABI/stable/sysfs-block
+++ b/Documentation/ABI/stable/sysfs-block
@@ -21,10 +21,63 @@ Description:
device is offset from the internal allocation unit's
natural alignment.
+What: /sys/block/<disk>/atomic_write_max_bytes
+Date: February 2024
+Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
+Description:
+ [RO] This parameter specifies the maximum atomic write
+ size reported by the device. This parameter is relevant
+ for merging of writes, where a merged atomic write
+ operation must not exceed this number of bytes.
+ This parameter may be greater than the value in
+ atomic_write_unit_max_bytes as
+ atomic_write_unit_max_bytes will be rounded down to a
+ power-of-two and atomic_write_unit_max_bytes may also be
+ limited by some other queue limits, such as max_segments.
+ This parameter - along with atomic_write_unit_min_bytes
+ and atomic_write_unit_max_bytes - will not be larger than
+ max_hw_sectors_kb, but may be larger than max_sectors_kb.
+
+
+What: /sys/block/<disk>/atomic_write_unit_min_bytes
+Date: February 2024
+Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
+Description:
+ [RO] This parameter specifies the smallest block which can
+ be written atomically with an atomic write operation. All
+ atomic write operations must begin at a
+ atomic_write_unit_min boundary and must be multiples of
+ atomic_write_unit_min. This value must be a power-of-two.
+
+
+What: /sys/block/<disk>/atomic_write_unit_max_bytes
+Date: February 2024
+Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
+Description:
+ [RO] This parameter defines the largest block which can be
+ written atomically with an atomic write operation. This
+ value must be a multiple of atomic_write_unit_min and must
+ be a power-of-two. This value will not be larger than
+ atomic_write_max_bytes.
+
+
+What: /sys/block/<disk>/atomic_write_boundary_bytes
+Date: February 2024
+Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
+Description:
+ [RO] A device may need to internally split an atomic write I/O
+ which straddles a given logical block address boundary. This
+ parameter specifies the size in bytes of the atomic boundary if
+ one is reported by the device. This value must be a
+ power-of-two and at least the size as in
+ atomic_write_unit_max_bytes.
+ Any attempt to merge atomic write I/Os must not result in a
+ merged I/O which crosses this boundary (if any).
+
What: /sys/block/<disk>/diskseq
Date: February 2021
-Contact: Matteo Croce <mcroce@microsoft.com>
+Contact: Matteo Croce <teknoraver@meta.com>
Description:
The /sys/block/<disk>/diskseq files reports the disk
sequence number, which is a monotonically increasing
@@ -56,6 +109,10 @@ Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether a storage device is capable of storing
integrity metadata. Set if the device is T10 PI-capable.
+ This flag is set to 1 if the storage media is formatted
+ with T10 Protection Information. If the storage media is
+ not formatted with T10 Protection Information, this flag
+ is set to 0.
What: /sys/block/<disk>/integrity/format
@@ -64,6 +121,13 @@ Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Metadata format for integrity capable block device.
E.g. T10-DIF-TYPE1-CRC.
+ This field describes the type of T10 Protection Information
+ that the block device can send and receive.
+ If the device can store application integrity metadata but
+ no T10 Protection Information profile is used, this field
+ contains "nop".
+ If the device does not support integrity metadata, this
+ field contains "none".
What: /sys/block/<disk>/integrity/protection_interval_bytes
@@ -89,7 +153,17 @@ Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Number of bytes of integrity tag space available per
- 512 bytes of data.
+ protection_interval_bytes, which is typically
+ the device's logical block size.
+ This field describes the size of the application tag
+ if the storage device is formatted with T10 Protection
+ Information and permits use of the application tag.
+ The tag_size is reported in bytes and indicates the
+ space available for adding an opaque tag to each block
+ (protection_interval_bytes).
+ If the device does not support T10 Protection Information
+ (even if the device provides application integrity
+ metadata space), this field is set to 0.
What: /sys/block/<disk>/integrity/write_generate
@@ -101,6 +175,16 @@ Description:
devices that support receiving integrity metadata.
+What: /sys/block/<disk>/partscan
+Date: May 2024
+Contact: Christoph Hellwig <hch@lst.de>
+Description:
+ The /sys/block/<disk>/partscan files reports if partition
+ scanning is enabled for the disk. It returns "1" if partition
+ scanning is enabled, or "0" if not. The value type is a 32-bit
+ unsigned integer, but only "0" and "1" are valid values.
+
+
What: /sys/block/<disk>/<partition>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
@@ -166,6 +250,17 @@ Description:
encryption, refer to Documentation/block/inline-encryption.rst.
+What: /sys/block/<disk>/queue/crypto/hw_wrapped_keys
+Date: February 2025
+Contact: linux-block@vger.kernel.org
+Description:
+ [RO] The presence of this file indicates that the device
+ supports hardware-wrapped inline encryption keys, i.e. key blobs
+ that can only be unwrapped and used by dedicated hardware. For
+ more information about hardware-wrapped inline encryption keys,
+ see Documentation/block/inline-encryption.rst.
+
+
What: /sys/block/<disk>/queue/crypto/max_dun_bits
Date: February 2022
Contact: linux-block@vger.kernel.org
@@ -204,6 +299,15 @@ Description:
use with inline encryption.
+What: /sys/block/<disk>/queue/crypto/raw_keys
+Date: February 2025
+Contact: linux-block@vger.kernel.org
+Description:
+ [RO] The presence of this file indicates that the device
+ supports raw inline encryption keys, i.e. keys that are managed
+ in raw, plaintext form in software.
+
+
What: /sys/block/<disk>/queue/dax
Date: June 2016
Contact: linux-block@vger.kernel.org
@@ -295,7 +399,7 @@ Description:
capable of executing requests targeting different sector ranges
in parallel. For instance, single LUN multi-actuator hard-disks
will have an independent_access_ranges directory if the device
- correctly advertizes the sector ranges of its actuators.
+ correctly advertises the sector ranges of its actuators.
The independent_access_ranges directory contains one directory
per access range, with each range described using the sector
@@ -336,18 +440,11 @@ What: /sys/block/<disk>/queue/io_poll_delay
Date: November 2016
Contact: linux-block@vger.kernel.org
Description:
- [RW] If polling is enabled, this controls what kind of polling
- will be performed. It defaults to -1, which is classic polling.
+ [RW] This was used to control what kind of polling will be
+ performed. It is now fixed to -1, which is classic polling.
In this mode, the CPU will repeatedly ask for completions
- without giving up any time. If set to 0, a hybrid polling mode
- is used, where the kernel will attempt to make an educated guess
- at when the IO will complete. Based on this guess, the kernel
- will put the process issuing IO to sleep for an amount of time,
- before entering a classic poll loop. This mode might be a little
- slower than pure classic polling, but it will be more efficient.
- If set to a value larger than 0, the kernel will put the process
- issuing IO to sleep for this amount of microseconds before
- entering classic polling.
+ without giving up any time.
+ <deprecated>
What: /sys/block/<disk>/queue/io_timeout
@@ -368,6 +465,13 @@ Description:
[RW] This file is used to control (on/off) the iostats
accounting of the disk.
+What: /sys/block/<disk>/queue/iostats_passthrough
+Date: October 2024
+Contact: linux-block@vger.kernel.org
+Description:
+ [RW] This file is used to control (on/off) the iostats
+ accounting of the disk for passthrough commands.
+
What: /sys/block/<disk>/queue/logical_block_size
Date: May 2009
@@ -432,7 +536,8 @@ Contact: linux-block@vger.kernel.org
Description:
[RW] This is the maximum number of kilobytes that the block
layer will allow for a filesystem request. Must be smaller than
- or equal to the maximum size allowed by the hardware.
+ or equal to the maximum size allowed by the hardware. Write 0
+ to use default kernel settings.
What: /sys/block/<disk>/queue/max_segment_size
@@ -442,6 +547,21 @@ Description:
[RO] Maximum size in bytes of a single element in a DMA
scatter/gather list.
+What: /sys/block/<disk>/queue/max_write_streams
+Date: November 2024
+Contact: linux-block@vger.kernel.org
+Description:
+ [RO] Maximum number of write streams supported, 0 if not
+ supported. If supported, valid values are 1 through
+ max_write_streams, inclusive.
+
+What: /sys/block/<disk>/queue/write_stream_granularity
+Date: November 2024
+Contact: linux-block@vger.kernel.org
+Description:
+ [RO] Granularity of a write stream in bytes. The granularity
+ of a write stream is the size that should be discarded or
+ overwritten together to avoid write amplification in the device.
What: /sys/block/<disk>/queue/max_segments
Date: March 2010
@@ -483,16 +603,10 @@ Date: July 2003
Contact: linux-block@vger.kernel.org
Description:
[RW] This controls how many requests may be allocated in the
- block layer for read or write requests. Note that the total
- allocated number may be twice this amount, since it applies only
- to reads or writes (not the accumulated sum).
-
- To avoid priority inversion through request starvation, a
- request queue maintains a separate request pool per each cgroup
- when CONFIG_BLK_CGROUP is enabled, and this parameter applies to
- each such per-block-cgroup request pool. IOW, if there are N
- block cgroups, each request queue may have up to N request
- pools, each independently regulated by nr_requests.
+ block layer. Noted this value only represents the quantity for a
+ single blk_mq_tags instance. The actual number for the entire
+ device depends on the hardware queue count, whether elevator is
+ enabled, and whether tags are shared.
What: /sys/block/<disk>/queue/nr_zones
@@ -537,6 +651,9 @@ Description:
[RW] Maximum number of kilobytes to read-ahead for filesystems
on this block device.
+ For MADV_HUGEPAGE, the readahead size may exceed this setting
+ since its granularity is based on the hugepage size.
+
What: /sys/block/<disk>/queue/rotational
Date: January 2009
@@ -590,18 +707,6 @@ Description:
the data. If no such restriction exists, this file will contain
'0'. This file is writable for testing purposes.
-
-What: /sys/block/<disk>/queue/throttle_sample_time
-Date: March 2017
-Contact: linux-block@vger.kernel.org
-Description:
- [RW] This is the time window that blk-throttle samples data, in
- millisecond. blk-throttle makes decision based on the
- samplings. Lower time means cgroups have more smooth throughput,
- but higher CPU overhead. This exists only when
- CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
-
-
What: /sys/block/<disk>/queue/virt_boundary_mask
Date: April 2021
Contact: linux-block@vger.kernel.org
@@ -620,7 +725,7 @@ Contact: linux-block@vger.kernel.org
Description:
[RW] If the device is registered for writeback throttling, then
this file shows the target minimum read latency. If this latency
- is exceeded in a given window of time (see wb_window_usec), then
+ is exceeded in a given window of time (see curr_win_nsec), then
the writeback throttling will start scaling back writes. Writing
a value of '0' to this file disables the feature. Writing a
value of '-1' to this file resets the value to the default
@@ -667,6 +772,39 @@ Description:
0, write zeroes is not supported by the device.
+What: /sys/block/<disk>/queue/write_zeroes_unmap_max_hw_bytes
+Date: January 2025
+Contact: Zhang Yi <yi.zhang@huawei.com>
+Description:
+ [RO] This file indicates whether a device supports zeroing data
+ in a specified block range without incurring the cost of
+ physically writing zeroes to the media for each individual
+ block. If this parameter is set to write_zeroes_max_bytes, the
+ device implements a zeroing operation which opportunistically
+ avoids writing zeroes to media while still guaranteeing that
+ subsequent reads from the specified block range will return
+ zeroed data. This operation is a best-effort optimization, a
+ device may fall back to physically writing zeroes to the media
+ due to other factors such as misalignment or being asked to
+ clear a block range smaller than the device's internal
+ allocation unit. If this parameter is set to 0, the device may
+ have to write each logical block media during a zeroing
+ operation.
+
+
+What: /sys/block/<disk>/queue/write_zeroes_unmap_max_bytes
+Date: January 2025
+Contact: Zhang Yi <yi.zhang@huawei.com>
+Description:
+ [RW] While write_zeroes_unmap_max_hw_bytes is the hardware limit
+ for the device, this setting is the software limit. Since the
+ unmap write zeroes operation is a best-effort optimization, some
+ devices may still physically writing zeroes to media. So the
+ speed of this operation is not guaranteed. Writing a value of
+ '0' to this file disables this operation. Otherwise, this
+ parameter should be equal to write_zeroes_unmap_max_hw_bytes.
+
+
What: /sys/block/<disk>/queue/zone_append_max_bytes
Date: May 2020
Contact: linux-block@vger.kernel.org
@@ -704,6 +842,15 @@ Description:
zoned will report "none".
+What: /sys/block/<disk>/hidden
+Date: March 2023
+Contact: linux-block@vger.kernel.org
+Description:
+ [RO] the block device is hidden. it doesn’t produce events, and
+ can’t be opened from userspace or using blkdev_get*.
+ Used for the underlying components of multipath devices.
+
+
What: /sys/block/<disk>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
diff --git a/Documentation/ABI/stable/sysfs-bus-mhi b/Documentation/ABI/stable/sysfs-bus-mhi
index 96ccc3385a2b..8b9698fa0beb 100644
--- a/Documentation/ABI/stable/sysfs-bus-mhi
+++ b/Documentation/ABI/stable/sysfs-bus-mhi
@@ -1,7 +1,7 @@
What: /sys/bus/mhi/devices/.../serialnumber
Date: Sept 2020
KernelVersion: 5.10
-Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Contact: mhi@lists.linux.dev
Description: The file holds the serial number of the client device obtained
using a BHI (Boot Host Interface) register read after at least
one attempt to power up the device has been done. If read
@@ -12,7 +12,7 @@ Users: Any userspace application or clients interested in device info.
What: /sys/bus/mhi/devices/.../oem_pk_hash
Date: Sept 2020
KernelVersion: 5.10
-Contact: Bhaumik Bhatt <bbhatt@codeaurora.org>
+Contact: mhi@lists.linux.dev
Description: The file holds the OEM PK Hash value of the endpoint device
obtained using a BHI (Boot Host Interface) register read after
at least one attempt to power up the device has been done. If
@@ -29,3 +29,16 @@ Description: Initiates a SoC reset on the MHI controller. A SoC reset is
This can be useful as a method of recovery if the device is
non-responsive, or as a means of loading new firmware as a
system administration task.
+
+What: /sys/bus/mhi/devices/.../trigger_edl
+Date: April 2024
+KernelVersion: 6.10
+Contact: mhi@lists.linux.dev
+Description: Writing a non-zero value to this file will force devices to
+ enter EDL (Emergency Download) mode. This entry only exists for
+ devices capable of entering the EDL mode using the standard EDL
+ triggering mechanism defined in the MHI spec v1.2. Once in EDL
+ mode, the flash programmer image can be downloaded to the
+ device to enter the flash programmer execution environment.
+ This can be useful if user wants to use QDL (Qualcomm Download,
+ which is used to download firmware over EDL) to update firmware.
diff --git a/Documentation/ABI/stable/sysfs-bus-nvmem b/Documentation/ABI/stable/sysfs-bus-nvmem
index c399323f37de..0ae8cb074acf 100644
--- a/Documentation/ABI/stable/sysfs-bus-nvmem
+++ b/Documentation/ABI/stable/sysfs-bus-nvmem
@@ -1,6 +1,23 @@
+What: /sys/bus/nvmem/devices/.../force_ro
+Date: June 2024
+KernelVersion: 6.11
+Contact: Marek Vasut <marex@denx.de>
+Description:
+ This read/write attribute allows users to set read-write
+ devices as read-only and back to read-write from userspace.
+ This can be used to unlock and relock write-protection of
+ devices which are generally locked, except during sporadic
+ programming operation.
+ Read returns '0' or '1' for read-write or read-only modes
+ respectively.
+ Write parses one of 'YyTt1NnFf0', or [oO][NnFf] for "on"
+ and "off", i.e. what kstrtobool() supports.
+ Note: This file is only present if CONFIG_NVMEM_SYSFS
+ is enabled.
+
What: /sys/bus/nvmem/devices/.../nvmem
Date: July 2015
-KernelVersion: 4.2
+KernelVersion: 4.2
Contact: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Description:
This file allows user to read/write the raw NVMEM contents.
@@ -20,3 +37,14 @@ Description:
...
*
0001000
+
+What: /sys/bus/nvmem/devices/.../type
+Date: November 2018
+KernelVersion: 5.0
+Contact: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Description:
+ This read-only attribute allows user to read the NVMEM
+ device type. Supported types are "Unknown", "EEPROM",
+ "OTP", "Battery backed", "FRAM".
+ Note: This file is only present if CONFIG_NVMEM_SYSFS
+ is enabled.
diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight
index 023fb52645f8..40b8c46b95b2 100644
--- a/Documentation/ABI/stable/sysfs-class-backlight
+++ b/Documentation/ABI/stable/sysfs-class-backlight
@@ -3,10 +3,11 @@ Date: April 2005
KernelVersion: 2.6.12
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
- Control BACKLIGHT power, values are FB_BLANK_* from fb.h
+ Control BACKLIGHT power, values are compatible with
+ FB_BLANK_* from fb.h
- - FB_BLANK_UNBLANK (0) : power on.
- - FB_BLANK_POWERDOWN (4) : power off
+ - 0 (FB_BLANK_UNBLANK) : power on.
+ - 4 (FB_BLANK_POWERDOWN) : power off
Users: HAL
What: /sys/class/backlight/<backlight>/brightness
@@ -25,7 +26,12 @@ Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
- Show the actual brightness by querying the hardware.
+ Show the actual brightness by querying the hardware. Due
+ to implementation differences in hardware this may not
+ match the value in 'brightness'. For example some hardware
+ may treat blanking differently or have custom power saving
+ features. Userspace should generally use the values in
+ 'brightness' to make decisions.
Users: HAL
What: /sys/class/backlight/<backlight>/max_brightness
diff --git a/Documentation/ABI/stable/sysfs-class-bluetooth b/Documentation/ABI/stable/sysfs-class-bluetooth
new file mode 100644
index 000000000000..36be02471174
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-class-bluetooth
@@ -0,0 +1,9 @@
+What: /sys/class/bluetooth/hci<index>/reset
+Date: 14-Jan-2025
+KernelVersion: 6.13
+Contact: linux-bluetooth@vger.kernel.org
+Description: This write-only attribute allows users to trigger the vendor reset
+ method on the Bluetooth device when arbitrary data is written.
+ The reset may or may not be done through the device transport
+ (e.g., UART/USB), and can also be done through an out-of-band
+ approach such as GPIO.
diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband
index ebf08c604336..694f23a03a28 100644
--- a/Documentation/ABI/stable/sysfs-class-infiniband
+++ b/Documentation/ABI/stable/sysfs-class-infiniband
@@ -356,7 +356,7 @@ Description:
pkeys/<n>: (RO) Displays the contents of the physical
key table n = 0..126
- mcgs/: (RO) Muticast group table
+ mcgs/: (RO) Multicast group table
<m>/gid_idx/0: (RO) Display the GID mapping m = 1..2
diff --git a/Documentation/ABI/stable/sysfs-class-rfkill b/Documentation/ABI/stable/sysfs-class-rfkill
index 037979f7dc4b..67b605e3dd16 100644
--- a/Documentation/ABI/stable/sysfs-class-rfkill
+++ b/Documentation/ABI/stable/sysfs-class-rfkill
@@ -16,7 +16,7 @@ Description: The rfkill class subsystem folder.
What: /sys/class/rfkill/rfkill[0-9]+/name
Date: 09-Jul-2007
-KernelVersion v2.6.22
+KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Name assigned by driver to this key (interface or driver name).
Values: arbitrary string.
@@ -24,7 +24,7 @@ Values: arbitrary string.
What: /sys/class/rfkill/rfkill[0-9]+/type
Date: 09-Jul-2007
-KernelVersion v2.6.22
+KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Driver type string ("wlan", "bluetooth", etc).
Values: See include/linux/rfkill.h.
@@ -32,7 +32,7 @@ Values: See include/linux/rfkill.h.
What: /sys/class/rfkill/rfkill[0-9]+/persistent
Date: 09-Jul-2007
-KernelVersion v2.6.22
+KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Whether the soft blocked state is initialised from non-volatile
storage at startup.
@@ -44,7 +44,7 @@ Values: A numeric value:
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
-KernelVersion v2.6.22
+KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file was scheduled to be removed in 2014, but due to its
@@ -67,7 +67,7 @@ Values: A numeric value.
What: /sys/class/rfkill/rfkill[0-9]+/hard
Date: 12-March-2010
-KernelVersion v2.6.34
+KernelVersion: v2.6.34
Contact: linux-wireless@vger.kernel.org
Description: Current hardblock state. This file is read only.
Values: A numeric value.
@@ -81,7 +81,7 @@ Values: A numeric value.
What: /sys/class/rfkill/rfkill[0-9]+/soft
Date: 12-March-2010
-KernelVersion v2.6.34
+KernelVersion: v2.6.34
Contact: linux-wireless@vger.kernel.org
Description: Current softblock state. This file is read and write.
Values: A numeric value.
diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node
index 8db67aa472f1..2d0e023f22a7 100644
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -177,8 +177,62 @@ Description:
The cache write policy: 0 for write-back, 1 for write-through,
other or unknown.
+What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/address_mode
+Date: March 2025
+Contact: Dave Jiang <dave.jiang@intel.com>
+Description:
+ The address mode: 0 for reserved, 1 for extended-linear.
+
What: /sys/devices/system/node/nodeX/x86/sgx_total_bytes
Date: November 2021
Contact: Jarkko Sakkinen <jarkko@kernel.org>
Description:
The total amount of SGX physical memory in bytes.
+
+What: /sys/devices/system/node/nodeX/memory_failure/total
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ The total number of raw poisoned pages (pages containing
+ corrupted data due to memory errors) on a NUMA node.
+
+What: /sys/devices/system/node/nodeX/memory_failure/ignored
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ ignored by memory error recovery attempt, usually because
+ support for this type of pages is unavailable, and kernel
+ gives up the recovery.
+
+What: /sys/devices/system/node/nodeX/memory_failure/failed
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ failed by memory error recovery attempt. This usually means
+ a key recovery operation failed.
+
+What: /sys/devices/system/node/nodeX/memory_failure/delayed
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ delayed by memory error recovery attempt. Delayed poisoned
+ pages usually will be retried by kernel.
+
+What: /sys/devices/system/node/nodeX/memory_failure/recovered
+Date: January 2023
+Contact: Jiaqi Yan <jiaqiyan@google.com>
+Description:
+ Of the raw poisoned pages on a NUMA node, how many pages are
+ recovered by memory error recovery attempt.
+
+What: /sys/devices/system/node/nodeX/reclaim
+Date: June 2025
+Contact: Linux Memory Management list <linux-mm@kvack.org>
+Description:
+ Perform user-triggered proactive reclaim on a NUMA node.
+ This interface is equivalent to the memcg variant.
+
+ See Documentation/admin-guide/cgroup-v2.rst
diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu
index 902392d7eddf..cf78bd99f6c8 100644
--- a/Documentation/ABI/stable/sysfs-devices-system-cpu
+++ b/Documentation/ABI/stable/sysfs-devices-system-cpu
@@ -24,12 +24,6 @@ Description: Default value for the Data Stream Control Register (DSCR) on
If set by a process it will be inherited by child processes.
Values: 64 bit unsigned integer (bit field)
-What: /sys/devices/system/cpu/cpuX/topology/physical_package_id
-Description: physical package id of cpuX. Typically corresponds to a physical
- socket number, but the actual value is architecture and platform
- dependent.
-Values: integer
-
What: /sys/devices/system/cpu/cpuX/topology/die_id
Description: the CPU die ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
@@ -86,10 +80,6 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus
Description: internal kernel map of CPUs within the same die.
Values: hexadecimal bitmask.
-What: /sys/devices/system/cpu/cpuX/topology/ppin
-Description: per-socket protected processor inventory number
-Values: hexadecimal.
-
What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list
Description: human-readable list of CPUs within the same die.
The format is like 0-3, 8-11, 14,17.
diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd
index 0c2b613f2373..4a355e6747ae 100644
--- a/Documentation/ABI/stable/sysfs-driver-dma-idxd
+++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd
@@ -22,6 +22,7 @@ Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The largest number of work descriptors in a batch.
+ It's not visible when the device does not support batch.
What: /sys/bus/dsa/devices/dsa<m>/max_work_queues_size
Date: Oct 25, 2019
@@ -49,6 +50,8 @@ Description: The total number of read buffers supported by this device.
The read buffers represent resources within the DSA
implementation, and these resources are allocated by engines to
support operations. See DSA spec v1.2 9.2.4 Total Read Buffers.
+ It's not visible when the device does not support Read Buffer
+ allocation control.
What: /sys/bus/dsa/devices/dsa<m>/max_transfer_size
Date: Oct 25, 2019
@@ -81,7 +84,7 @@ What: /sys/bus/dsa/devices/dsa<m>/pasid_enabled
Date: Oct 27, 2020
KernelVersion: 5.11.0
Contact: dmaengine@vger.kernel.org
-Description: To indicate if PASID (process address space identifier) is
+Description: To indicate if user PASID (process address space identifier) is
enabled or not for this device.
What: /sys/bus/dsa/devices/dsa<m>/state
@@ -122,6 +125,8 @@ Contact: dmaengine@vger.kernel.org
Description: The maximum number of read buffers that may be in use at
one time by operations that access low bandwidth memory in the
device. See DSA spec v1.2 9.2.8 GENCFG on Global Read Buffer Limit.
+ It's not visible when the device does not support Read Buffer
+ allocation control.
What: /sys/bus/dsa/devices/dsa<m>/cmd_status
Date: Aug 28, 2020
@@ -131,6 +136,22 @@ Description: The last executed device administrative command's status/error.
Also last configuration error overloaded.
Writing to it will clear the status.
+What: /sys/bus/dsa/devices/dsa<m>/iaa_cap
+Date: Sept 14, 2022
+KernelVersion: 6.0.0
+Contact: dmaengine@vger.kernel.org
+Description: IAA (IAX) capability mask. Exported to user space for application
+ consumption. This attribute should only be visible on IAA devices
+ that are version 2 or later.
+
+What: /sys/bus/dsa/devices/dsa<m>/event_log_size
+Date: Sept 14, 2022
+KernelVersion: 6.4.0
+Contact: dmaengine@vger.kernel.org
+Description: The event log size to be configured. Default is 64 entries and
+ occupies 4k size if the evl entry is 64 bytes. It's visible
+ only on platforms that support the capability.
+
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
Date: Oct 27, 2020
KernelVersion: 5.11.0
@@ -205,6 +226,7 @@ KernelVersion: 5.10.0
Contact: dmaengine@vger.kernel.org
Description: The max batch size for this workqueue. Cannot exceed device
max batch size. Configurable parameter.
+ It's not visible when the device does not support batch.
What: /sys/bus/dsa/devices/wq<m>.<n>/ats_disable
Date: Nov 13, 2020
@@ -213,20 +235,47 @@ Contact: dmaengine@vger.kernel.org
Description: Indicate whether ATS disable is turned on for the workqueue.
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
+What: /sys/bus/dsa/devices/wq<m>.<n>/prs_disable
+Date: Sept 14, 2022
+KernelVersion: 6.4.0
+Contact: dmaengine@vger.kernel.org
+Description: Controls whether PRS disable is turned on for the workqueue.
+ 0 indicates PRS is on, and 1 indicates PRS is off for the
+ workqueue. This option overrides block_on_fault attribute
+ if set. It's visible only on platforms that support the
+ capability.
+
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
-Date May 25, 2021
+Date: May 25, 2021
KernelVersion: 5.14.0
Contact: dmaengine@vger.kernel.org
Description: Show the current number of entries in this WQ if WQ Occupancy
Support bit WQ capabilities is 1.
What: /sys/bus/dsa/devices/wq<m>.<n>/enqcmds_retries
-Date Oct 29, 2021
+Date: Oct 29, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Indicate the number of retires for an enqcmds submission on a sharedwq.
A max value to set attribute is capped at 64.
+What: /sys/bus/dsa/devices/wq<m>.<n>/op_config
+Date: Sept 14, 2022
+KernelVersion: 6.0.0
+Contact: dmaengine@vger.kernel.org
+Description: Shows the operation capability bits displayed in bitmap format
+ presented by %*pb printk() output format specifier.
+ The attribute can be configured when the WQ is disabled in
+ order to configure the WQ to accept specific bits that
+ correlates to the operations allowed. It's visible only
+ on platforms that support the capability.
+
+What: /sys/bus/dsa/devices/wq<m>.<n>/driver_name
+Date: Sept 8, 2023
+KernelVersion: 6.7.0
+Contact: dmaengine@vger.kernel.org
+Description: Name of driver to be bounded to the wq.
+
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
@@ -239,6 +288,8 @@ KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Enable the use of global read buffer limit for the group. See DSA
spec v1.2 9.2.18 GRPCFG Use Global Read Buffer Limit.
+ It's not visible when the device does not support Read Buffer
+ allocation control.
What: /sys/bus/dsa/devices/group<m>.<n>/read_buffers_allowed
Date: Dec 10, 2021
@@ -247,6 +298,8 @@ Contact: dmaengine@vger.kernel.org
Description: Indicates max number of read buffers that may be in use at one time
by all engines in the group. See DSA spec v1.2 9.2.18 GRPCFG Read
Buffers Allowed.
+ It's not visible when the device does not support Read Buffer
+ allocation control.
What: /sys/bus/dsa/devices/group<m>.<n>/read_buffers_reserved
Date: Dec 10, 2021
@@ -255,3 +308,54 @@ Contact: dmaengine@vger.kernel.org
Description: Indicates the number of Read Buffers reserved for the use of
engines in the group. See DSA spec v1.2 9.2.18 GRPCFG Read Buffers
Reserved.
+ It's not visible when the device does not support Read Buffer
+ allocation control.
+
+What: /sys/bus/dsa/devices/group<m>.<n>/desc_progress_limit
+Date: Sept 14, 2022
+KernelVersion: 6.0.0
+Contact: dmaengine@vger.kernel.org
+Description: Allows control of the number of work descriptors that can be
+ concurrently processed by an engine in the group as a fraction
+ of the Maximum Work Descriptors in Progress value specified in
+ the ENGCAP register. The acceptable values are 0 (default),
+ 1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
+ the max value). It's visible only on platforms that support
+ the capability.
+
+What: /sys/bus/dsa/devices/group<m>.<n>/batch_progress_limit
+Date: Sept 14, 2022
+KernelVersion: 6.0.0
+Contact: dmaengine@vger.kernel.org
+Description: Allows control of the number of batch descriptors that can be
+ concurrently processed by an engine in the group as a fraction
+ of the Maximum Batch Descriptors in Progress value specified in
+ the ENGCAP register. The acceptable values are 0 (default),
+ 1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
+ the max value). It's visible only on platforms that support
+ the capability.
+
+What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_faults
+Date: Sept 14, 2022
+KernelVersion: 6.4.0
+Contact: dmaengine@vger.kernel.org
+Description: Show the number of Completion Record (CR) faults this application
+ has caused.
+
+What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_fault_failures
+Date: Sept 14, 2022
+KernelVersion: 6.4.0
+Contact: dmaengine@vger.kernel.org
+Description: Show the number of Completion Record (CR) faults failures that this
+ application has caused. The failure counter is incremented when the
+ driver cannot fault in the address for the CR. Typically this is caused
+ by a bad address programmed in the submitted descriptor or a malicious
+ submitter is using bad CR address on purpose.
+
+What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/pid
+Date: Sept 14, 2022
+KernelVersion: 6.4.0
+Contact: dmaengine@vger.kernel.org
+Description: Show the process id of the application that opened the file. This is
+ helpful information for a monitor daemon that wants to kill the
+ application that opened the file.
diff --git a/Documentation/ABI/stable/sysfs-driver-misc-cp500 b/Documentation/ABI/stable/sysfs-driver-misc-cp500
new file mode 100644
index 000000000000..525bd18a2db4
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-misc-cp500
@@ -0,0 +1,25 @@
+What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/0000:XX:XX.X/version
+Date: June 2024
+KernelVersion: 6.11
+Contact: Gerhard Engleder <eg@keba.com>
+Description: Version of the FPGA configuration bitstream as printable string.
+ This file is read only.
+Users: KEBA
+
+What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/0000:XX:XX.X/keep_cfg
+Date: June 2024
+KernelVersion: 6.11
+Contact: Gerhard Engleder <eg@keba.com>
+Description: Flag which signals if FPGA shall keep or reload configuration
+ bitstream on reset. Normal FPGA behavior and default is to keep
+ configuration bitstream and to only reset the configured logic.
+
+ Reloading configuration on reset enables an update of the
+ configuration bitstream with a simple reboot. Otherwise it is
+ necessary to power cycle the device to reload the new
+ configuration bitstream.
+
+ This file is read/write. The values are as follows:
+ 1 = keep configuration bitstream on reset, default
+ 0 = reload configuration bitstream on reset
+Users: KEBA
diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
index af0cbf143c48..f59461111221 100644
--- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io
+++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
@@ -522,7 +522,6 @@ Description: These files allow to each of ASICs by writing 1.
The files are write only.
-
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/comm_chnl_ready
Date: July 2022
KernelVersion: 5.20
@@ -542,3 +541,275 @@ Description: The file indicates COME module hardware configuration.
The purpose is to expose some minor BOM changes for the same system SKU.
The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_pwr_converter_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows the system reset cause due to power converter
+ devices failure.
+ Value 1 in file means this is reset cause, 0 - otherwise.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_ap_reset
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_ap_reset
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files aim to monitor the status of the External Root of Trust (EROT)
+ processor's RESET output to the Application Processor (AP).
+ By reading this file, could be determined if the EROT has invalidated or
+ revoked AP Firmware, at which point it will hold the AP in RESET until a
+ valid firmware is loaded. This protects the AP from running an
+ unauthorized firmware. In the normal flow, the AP reset should be released
+ after the EROT validates the integrity of the FW, and it should be done so
+ as quickly as possible so that the AP boots before the CPU starts to
+ communicate to each ASIC.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_recovery
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_recovery
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_reset
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_reset
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files aim to perform External Root of Trust (EROT) recovery
+ sequence after EROT device failure.
+ These EROT devices protect ASICs from unauthorized access and in normal
+ flow their reset should be released with system power – earliest power
+ up stage, so that EROTs can begin boot and authentication process before
+ CPU starts to communicate to ASICs.
+ Issuing a reset to the EROT while asserting the recovery signal will cause
+ the EROT Application Processor to enter recovery mode so that the EROT FW
+ can be updated/recovered.
+ For reset/recovery the related file should be toggled by 1/0.
+
+ The files are read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot1_wp
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/erot2_wp
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files allow access to External Root of Trust (EROT) for reset
+ and recovery sequence after EROT device failure.
+ Default is 0 (programming disabled).
+ If the system is in locked-down mode writing this file will not be allowed.
+
+ The files are read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/spi_chnl_select
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file allows SPI chip selection for External Root of Trust (EROT)
+ device Out-of-Band recovery.
+ File can be written with 0 or with 1. It selects which EROT can be accessed
+ through SPI device.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_pg_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak vadimp@nvidia.com
+Description: This file shows ASIC Power Good status.
+ Value 1 in file means ASIC Power Good failed, 0 - otherwise.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd1_boot_fail
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd2_boot_fail
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak vadimp@nvidia.com
+Description: These files are related to clock boards status in system.
+ - clk_brd1_boot_fail: warning about 1-st clock board failed to boot from CI.
+ - clk_brd2_boot_fail: warning about 2-nd clock board failed to boot from CI.
+ - clk_brd_fail: error about common clock board boot failure.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/clk_brd_prog_en
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file enables programming of clock boards.
+ Default is 0 (programming disabled).
+ If the system is in locked-down mode writing this file will not be allowed.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_converter_prog_en
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file enables programming of power converters.
+ Default is 0 (programming disabled).
+ If the system is in locked-down mode writing this file will not be allowed.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_ac_ok_fail
+Date: February 2023
+KernelVersion: 6.3
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows the system reset cause due to AC power failure.
+ Value 1 in file means this is reset cause, 0 - otherwise.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_pn
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld5_version_min
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files show with which CPLD part numbers, version and minor
+ versions have been burned the 5-th CPLD device equipped on a
+ system.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_cap
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file indicates the available method of CPLD/FPGA devices
+ field update through the JTAG chain:
+
+ b00 - field update through LPC bus register memory space.
+ b01 - Reserved.
+ b10 - Reserved.
+ b11 - field update through CPU GPIOs bit-banging.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/lid_open
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: 1 - indicates that system lid is opened, otherwise 0.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_long_pwr_pb
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file if set 1 indicates that system has been reset by
+ long press of power button.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_dc_dc_pwr_fail
+Date: August 2023
+KernelVersion: 6.6
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows 1 in case the system reset happened due to the
+ failure of any DC-DC power converter devices equipped on the
+ switch board.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/global_wp_request
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file when written 1 activates request to allow access to
+ the write protected flashes. Such request can be performed only
+ for system equipped with BMC (Board Management Controller),
+ which can grant access to protected flashes. In case BMC allows
+ access - it will respond with "global_wp_response". BMC decides
+ regarding time window of granted access. After granted window is
+ expired, BMC will change value back to 0.
+ Default value is 0.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/global_wp_response
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file, when set 1, indicates that access to protected
+ flashes have been granted to host CPU by BMC.
+ Default value is 0.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/shutdown_unlock
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: When ASICs are getting overheated, system protection
+ hardware mechanism enforces system reboot. After system
+ reboot ASICs come up in locked state. To unlock ASICs,
+ this file should be written 1
+ Default value is 0.
+
+ The file is read/write.
+
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/boot_progress
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files show the Data Process Unit board boot progress
+ state. Valid states are:
+ - 4 : OS starting.
+ - 5 : OS running.
+ - 6 : Low-Power Standby.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/dpu_id
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: This file shows hardware Id of Data Process Unit board.
+
+ The file is read only.
+
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/reset_aux_pwr_or_reload
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/reset_dpu_thermal
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/reset_from_main_board
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files expose the cause of the most recent reset of the Data
+ Processing Unit (DPU) board. The possible causes are:
+ - Power auxiliary outage or power reload.
+ - Thermal shutdown.
+ - Reset request from the main board.
+ Value 1 in file means this is reset cause, 0 - otherwise. Only one of
+ the above causes could be 1 at the same time, representing only last
+ reset cause.
+
+ The files are read only.
+
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/perst_rst
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/phy_rst
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/tpm_rst
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/usbphy_rst
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files allow to reset hardware components of Data Process
+ Unit board. Respectively PCI, Ethernet PHY, TPM and USB PHY
+ resets.
+ Default values for all the attributes is 1. Writing 0 will
+ cause reset of the related component.
+
+ The files are read/write.
+
+What: /sys/devices/platform/mlxplat/i2c_mlxcpld.*/i2c-*/i2c-*/*-00**/mlxreg-io.*/hwmon/hwmon*/ufm_upgrade
+Date: May 2025
+KernelVersion: 6.16
+Contact: Vadim Pasternak <vadimp@nvidia.com>
+Description: These files show status of Unified Fabric Manager upgrade.
+ state. 0 - means upgrade is done, 1 - otherwise.
+
+ The file is read only.
diff --git a/Documentation/ABI/stable/sysfs-driver-qaic b/Documentation/ABI/stable/sysfs-driver-qaic
new file mode 100644
index 000000000000..c767a93342b3
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-qaic
@@ -0,0 +1,19 @@
+What: /sys/bus/pci/drivers/qaic/XXXX:XX:XX.X/accel/accel<minor_nr>/dbc<N>_state
+Date: October 2025
+KernelVersion: 6.19
+Contact: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
+Description: Represents the current state of DMA Bridge channel (DBC). Below are the possible
+ states:
+
+ =================== ==========================================================
+ IDLE (0) DBC is free and can be activated
+ ASSIGNED (1) DBC is activated and a workload is running on device
+ BEFORE_SHUTDOWN (2) Sub-system associated with this workload has crashed and
+ it will shutdown soon
+ AFTER_SHUTDOWN (3) Sub-system associated with this workload has crashed and
+ it has shutdown
+ BEFORE_POWER_UP (4) Sub-system associated with this workload is shutdown and
+ it will be powered up soon
+ AFTER_POWER_UP (5) Sub-system associated with this workload is now powered up
+ =================== ==========================================================
+Users: Any userspace application or clients interested in DBC state.
diff --git a/Documentation/ABI/stable/sysfs-driver-speakup b/Documentation/ABI/stable/sysfs-driver-speakup
index dc2a6ba1674b..bcb6831aa114 100644
--- a/Documentation/ABI/stable/sysfs-driver-speakup
+++ b/Documentation/ABI/stable/sysfs-driver-speakup
@@ -35,6 +35,15 @@ Description: This controls cursor delay when using arrow keys. When a
characters. Set this to a higher value to adjust for the delay
and better synchronisation between cursor position and speech.
+What: /sys/accessibility/speakup/cur_phonetic
+KernelVersion: 6.2
+Contact: speakup@linux-speakup.org
+Description: This allows speakup to speak letters phoneticaly when arrowing through
+ a word letter by letter. This doesn't affect the spelling when typing
+ the characters. When cur_phonetic=1, speakup will speak characters
+ phoneticaly when arrowing over a letter. When cur_phonetic=0, speakup
+ will speak letters as normally.
+
What: /sys/accessibility/speakup/delimiters
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
diff --git a/Documentation/ABI/stable/sysfs-firmware-efi-vars b/Documentation/ABI/stable/sysfs-firmware-efi-vars
deleted file mode 100644
index 46ccd233e359..000000000000
--- a/Documentation/ABI/stable/sysfs-firmware-efi-vars
+++ /dev/null
@@ -1,79 +0,0 @@
-What: /sys/firmware/efi/vars
-Date: April 2004
-Contact: Matt Domsch <Matt_Domsch@dell.com>
-Description:
- This directory exposes interfaces for interactive with
- EFI variables. For more information on EFI variables,
- see 'Variable Services' in the UEFI specification
- (section 7.2 in specification version 2.3 Errata D).
-
- In summary, EFI variables are named, and are classified
- into separate namespaces through the use of a vendor
- GUID. They also have an arbitrary binary value
- associated with them.
-
- The efivars module enumerates these variables and
- creates a separate directory for each one found. Each
- directory has a name of the form "<key>-<vendor guid>"
- and contains the following files:
-
- =============== ========================================
- attributes: A read-only text file enumerating the
- EFI variable flags. Potential values
- include:
-
- EFI_VARIABLE_NON_VOLATILE
- EFI_VARIABLE_BOOTSERVICE_ACCESS
- EFI_VARIABLE_RUNTIME_ACCESS
- EFI_VARIABLE_HARDWARE_ERROR_RECORD
- EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
-
- See the EFI documentation for an
- explanation of each of these variables.
-
- data: A read-only binary file that can be read
- to attain the value of the EFI variable
-
- guid: The vendor GUID of the variable. This
- should always match the GUID in the
- variable's name.
-
- raw_var: A binary file that can be read to obtain
- a structure that contains everything
- there is to know about the variable.
- For structure definition see "struct
- efi_variable" in the kernel sources.
-
- This file can also be written to in
- order to update the value of a variable.
- For this to work however, all fields of
- the "struct efi_variable" passed must
- match byte for byte with the structure
- read out of the file, save for the value
- portion.
-
- **Note** the efi_variable structure
- read/written with this file contains a
- 'long' type that may change widths
- depending on your underlying
- architecture.
-
- size: As ASCII representation of the size of
- the variable's value.
- =============== ========================================
-
-
- In addition, two other magic binary files are provided
- in the top-level directory and are used for adding and
- removing variables:
-
- =============== ========================================
- new_var: Takes a "struct efi_variable" and
- instructs the EFI firmware to create a
- new variable.
-
- del_var: Takes a "struct efi_variable" and
- instructs the EFI firmware to remove any
- variable that has a matching vendor GUID
- and variable key name.
- =============== ========================================
diff --git a/Documentation/ABI/stable/sysfs-hypervisor-xen b/Documentation/ABI/stable/sysfs-hypervisor-xen
index 748593c64568..be9ca9981bb1 100644
--- a/Documentation/ABI/stable/sysfs-hypervisor-xen
+++ b/Documentation/ABI/stable/sysfs-hypervisor-xen
@@ -120,3 +120,16 @@ Contact: xen-devel@lists.xenproject.org
Description: If running under Xen:
The Xen version is in the format <major>.<minor><extra>
This is the <minor> part of it.
+
+What: /sys/hypervisor/start_flags/*
+Date: March 2023
+KernelVersion: 6.3.0
+Contact: xen-devel@lists.xenproject.org
+Description: If running under Xen:
+ All bits in Xen's start-flags are represented as
+ boolean files, returning '1' if set, '0' otherwise.
+ This takes the place of the defunct /proc/xen/capabilities,
+ which would contain "control_d" on dom0, and be empty
+ otherwise. This flag is now exposed as "initdomain" in
+ addition to the "privileged" flag; all other possible flags
+ are accessible as "unknownXX".
diff --git a/Documentation/ABI/stable/sysfs-kernel-time-aux-clocks b/Documentation/ABI/stable/sysfs-kernel-time-aux-clocks
new file mode 100644
index 000000000000..825508f42af6
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-kernel-time-aux-clocks
@@ -0,0 +1,5 @@
+What: /sys/kernel/time/aux_clocks/<ID>/enable
+Date: May 2025
+Contact: Thomas Gleixner <tglx@linutronix.de>
+Description:
+ Controls the enablement of auxiliary clock timekeepers.
diff --git a/Documentation/ABI/stable/sysfs-platform-wmi-bmof b/Documentation/ABI/stable/sysfs-platform-wmi-bmof
new file mode 100644
index 000000000000..2881244e3f09
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-platform-wmi-bmof
@@ -0,0 +1,7 @@
+What: /sys/bus/wmi/devices/05901221-D566-11D1-B2F0-00A0C9062910[-X]/bmof
+Date: Jun 2017
+KernelVersion: 4.13
+Description:
+ Binary MOF metadata used to describe the details of available ACPI WMI interfaces.
+
+ See Documentation/wmi/devices/wmi-bmof.rst for details.
diff --git a/Documentation/ABI/stable/vdso b/Documentation/ABI/stable/vdso
index 951838d42781..85dbb6a160df 100644
--- a/Documentation/ABI/stable/vdso
+++ b/Documentation/ABI/stable/vdso
@@ -9,9 +9,11 @@ maps an ELF DSO into that program's address space. This DSO is called
the vDSO and it often contains useful and highly-optimized alternatives
to real syscalls.
-These functions are called just like ordinary C function according to
-your platform's ABI. Call them from a sensible context. (For example,
-if you set CS on x86 to something strange, the vDSO functions are
+These functions are called according to your platform's ABI. On many
+platforms they are called just like ordinary C function. On other platforms
+(ex: powerpc) they are called with the same convention as system calls which
+is different from ordinary C functions. Call them from a sensible context.
+(For example, if you set CS on x86 to something strange, the vDSO functions are
within their rights to crash.) In addition, if you pass a bad
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.
diff --git a/Documentation/ABI/testing/configfs-tsm-report b/Documentation/ABI/testing/configfs-tsm-report
new file mode 100644
index 000000000000..534408bc1408
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-tsm-report
@@ -0,0 +1,145 @@
+What: /sys/kernel/config/tsm/report/$name/inblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Up to 64 bytes of user specified binary data. For replay
+ protection this should include a nonce, but the kernel does not
+ place any restrictions on the content.
+
+What: /sys/kernel/config/tsm/report/$name/outblob
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Binary attestation report generated from @inblob and other
+ options The format of the report is implementation specific
+ where the implementation is conveyed via the @provider
+ attribute.
+
+What: /sys/kernel/config/tsm/report/$name/auxblob
+Date: October, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ auxiliary data is available.
+
+ When @provider is "sev_guest" this file contains the
+ "cert_table" from SEV-ES Guest-Hypervisor Communication Block
+ Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+
+What: /sys/kernel/config/tsm/report/$name/manifestblob
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Optional supplemental data that a TSM may emit, visibility
+ of this attribute depends on TSM, and may be empty if no
+ manifest data is available.
+
+ See 'service_provider' for information on the format of the
+ manifest blob.
+
+What: /sys/kernel/config/tsm/report/$name/provider
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) A name for the format-specification of @outblob like
+ "sev_guest" [1] or "tdx_guest" [2] in the near term, or a
+ common standard format in the future.
+
+ [1]: SEV Secure Nested Paging Firmware ABI Specification
+ Revision 1.55 Table 22
+ https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
+
+ [2]: Intel® Trust Domain Extensions Data Center Attestation
+ Primitives : Quote Generation Library and Quote Verification
+ Library Revision 0.8 Appendix 4,5
+ https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
+
+What: /sys/kernel/config/tsm/report/$name/generation
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) The value in this attribute increments each time @inblob or
+ any option is written. Userspace can detect conflicts by
+ checking generation before writing to any attribute and making
+ sure the number of writes matches expectations after reading
+ @outblob, or it can prevent conflicts by creating a report
+ instance per requesting context.
+
+What: /sys/kernel/config/tsm/report/$name/privlevel
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports for TVMs running at
+ different privilege levels, like SEV-SNP "VMPL", specify the
+ privilege level via this attribute. The minimum acceptable
+ value is conveyed via @privlevel_floor and the maximum
+ acceptable value is TSM_PRIVLEVEL_MAX (3).
+
+What: /sys/kernel/config/tsm/report/$name/privlevel_floor
+Date: September, 2023
+KernelVersion: v6.7
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) Indicates the minimum permissible value that can be written
+ to @privlevel.
+
+What: /sys/kernel/config/tsm/report/$name/service_provider
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Specifying the service provider via this attribute will create
+ an attestation report as specified by the service provider.
+ The only currently supported service provider is "svsm".
+
+ For the "svsm" service provider, see the Secure VM Service Module
+ for SEV-SNP Guests v1.00 Section 7. For the doc, search for
+ "site:amd.com "Secure VM Service Module for SEV-SNP
+ Guests", docID: 58019"
+
+What: /sys/kernel/config/tsm/report/$name/service_guid
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
+ requests all active services within the service provider be
+ part of the attestation report. Specifying a GUID request
+ an attestation report of just the specified service using the
+ manifest form specified by the service_manifest_version
+ attribute.
+
+ See 'service_provider' for information on the format of the
+ service guid.
+
+What: /sys/kernel/config/tsm/report/$name/service_manifest_version
+Date: January, 2024
+KernelVersion: v6.10
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Attribute is visible if a TSM implementation provider
+ supports the concept of attestation reports from a service
+ provider for TVMs, like SEV-SNP running under an SVSM.
+ Indicates the service manifest version requested for the
+ attestation report (default 0). If this field is not set by
+ the user, the default manifest version of the service (the
+ service's initial/first manifest version) is returned.
+
+ See 'service_provider' for information on the format of the
+ service manifest version.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget
index b7943aa7e997..a8bb896def54 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -143,3 +143,16 @@ Description:
qw_sign an identifier to be reported as "OS String"
proper
============= ===============================================
+
+What: /config/usb-gadget/gadget/webusb
+Date: Dec 2022
+KernelVersion: 6.3
+Description:
+ This group contains "WebUSB" extension handling attributes.
+
+ ============= ===============================================
+ use flag turning "WebUSB" support on/off
+ bcdVersion bcd WebUSB specification version number
+ bVendorCode one-byte value used for custom per-device
+ landingPage UTF-8 encoded URL of the device's landing page
+ ============= ===============================================
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm
index d21092d75a05..25e68be9eb66 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-acm
+++ b/Documentation/ABI/testing/configfs-usb-gadget-acm
@@ -6,3 +6,10 @@ Description:
This item contains just one readonly attribute: port_num.
It contains the port number of the /dev/ttyGS<n> device
associated with acm function's instance "name".
+
+What: /config/usb-gadget/gadget/functions/acm.name/protocol
+Date: Aug 2024
+KernelVersion: 6.13
+Description:
+ Reported bInterfaceProtocol for the ACM device. For legacy
+ reasons, this defaults to 1 (USB_CDC_ACM_PROTO_AT_V25TER).
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ffs b/Documentation/ABI/testing/configfs-usb-gadget-ffs
index e39b27653c65..bf8936ff6d38 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-ffs
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ffs
@@ -4,6 +4,14 @@ KernelVersion: 3.13
Description: The purpose of this directory is to create and remove it.
A corresponding USB function instance is created/removed.
- There are no attributes here.
- All parameters are set through FunctionFS.
+ All attributes are read only:
+
+ ============= ============================================
+ ready 1 if the function is ready to be used, E.G.
+ if userspace has written descriptors and
+ strings to ep0, so the gadget can be
+ enabled - 0 otherwise.
+ ============= ============================================
+
+ All other parameters are set through FunctionFS.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-midi2 b/Documentation/ABI/testing/configfs-usb-gadget-midi2
new file mode 100644
index 000000000000..d76a52e2ca7f
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-midi2
@@ -0,0 +1,54 @@
+What: /config/usb-gadget/gadget/functions/midi2.name
+Date: Jul 2023
+KernelVersion: 6.6
+Description:
+ The attributes:
+
+ ============ ===============================================
+ process_ump Flag to process UMP Stream messages (0 or 1)
+ static_block Flag for static blocks (0 or 1)
+ iface_name MIDI interface name string
+ ============ ===============================================
+
+What: /config/usb-gadget/gadget/functions/midi2.name/ep.number
+Date: Jul 2023
+KernelVersion: 6.6
+Description:
+ This group contains a UMP Endpoint configuration.
+ A new Endpoint starts from 0, and can be up to 3.
+
+ The attributes:
+
+ ============= ===============================================
+ protocol_caps MIDI protocol capabilities (1, 2 or 3 for both)
+ protocol Default MIDI protocol (1 or 2)
+ ep_name UMP Endpoint name string
+ product_id Product ID string
+ manufacturer Manufacture ID (24 bit)
+ family Device family ID (16 bit)
+ model Device model ID (16 bit)
+ sw_revision Software Revision (32 bit)
+ ============= ===============================================
+
+What: /config/usb-gadget/gadget/functions/midi2.name/ep.number/block.number
+Date: Jul 2023
+KernelVersion: 6.6
+Description:
+ This group contains a UMP Function Block configuration.
+ A new block starts from 0, and can be up to 31.
+
+ The attributes:
+
+ ================= ==============================================
+ name Function Block name string
+ direction 1: input, 2: output, 3: bidirectional
+ first_group The first UMP Group number (0-15)
+ num_groups The number of groups in this FB (1-16)
+ midi1_first_group The first UMP Group number for MIDI 1.0 (0-15)
+ midi1_num_groups The number of groups for MIDI 1.0 (0-16)
+ ui_hint 0: unknown, 1: receiver, 2: sender, 3: both
+ midi_ci_version Supported MIDI-CI version number (8 bit)
+ is_midi1 Legacy MIDI 1.0 device (0, 1 or 2)
+ sysex8_streams Max number of SysEx8 streams (8 bit)
+ active Active FB flag (0 or 1)
+ ================= ==============================================
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1
index c4ba92f004c3..64188a85592b 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uac1
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1
@@ -30,4 +30,12 @@ Description:
req_number the number of pre-allocated requests
for both capture and playback
function_name name of the interface
+ p_it_name playback input terminal name
+ p_it_ch_name playback channels name
+ p_ot_name playback output terminal name
+ p_fu_vol_name playback mute/volume functional unit name
+ c_it_name capture input terminal name
+ c_it_ch_name capture channels name
+ c_ot_name capture output terminal name
+ c_fu_vol_name capture mute/volume functional unit name
===================== =======================================
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2
index 3371c39f651d..133e995c3e92 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uac2
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2
@@ -35,4 +35,17 @@ Description:
req_number the number of pre-allocated requests
for both capture and playback
function_name name of the interface
+ if_ctrl_name topology control name
+ clksrc_in_name input clock name
+ clksrc_out_name output clock name
+ p_it_name playback input terminal name
+ p_it_ch_name playback input first channel name
+ p_ot_name playback output terminal name
+ p_fu_vol_name playback mute/volume function unit name
+ c_it_name capture input terminal name
+ c_it_ch_name capture input first channel name
+ c_ot_name capture output terminal name
+ c_fu_vol_name capture mute/volume functional unit name
+ c_terminal_type code of the capture terminal type
+ p_terminal_type code of the playback terminal type
===================== =======================================
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index 611b23e6488d..b6720768d63d 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -15,12 +15,14 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Control descriptors
- All attributes read only:
+ All attributes read only except enable_interrupt_ep:
- ================ =============================
+ =================== =============================
bInterfaceNumber USB interface number for this
streaming interface
- ================ =============================
+ enable_interrupt_ep flag to enable the interrupt
+ endpoint for the VC interface
+ =================== =============================
What: /config/usb-gadget/gadget/functions/uvc.name/control/class
Date: Dec 2014
@@ -52,7 +54,7 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Default output terminal descriptors
- All attributes read only:
+ All attributes read only except bSourceID:
============== =============================================
iTerminal index of string descriptor
@@ -74,7 +76,7 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Default camera terminal descriptors
- All attributes read only:
+ All attributes read only except bmControls, which is read/write:
======================== ====================================
bmControls bitmap specifying which controls are
@@ -99,7 +101,7 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Default processing unit descriptors
- All attributes read only:
+ All attributes read only except bmControls, which is read/write:
=============== ========================================
iProcessing index of string descriptor
@@ -111,6 +113,34 @@ Description: Default processing unit descriptors
bUnitID a non-zero id of this unit
=============== ========================================
+What: /config/usb-gadget/gadget/functions/uvc.name/control/extensions
+Date: Nov 2022
+KernelVersion: 6.1
+Description: Extension unit descriptors
+
+What: /config/usb-gadget/gadget/functions/uvc.name/control/extensions/name
+Date: Nov 2022
+KernelVersion: 6.1
+Description: Extension Unit (XU) Descriptor
+
+ bLength, bUnitID and iExtension are read-only. All others are
+ read-write.
+
+ ================= ========================================
+ bLength size of the descriptor in bytes
+ bUnitID non-zero ID of this unit
+ guidExtensionCode Vendor-specific code identifying the XU
+ bNumControls number of controls in this XU
+ bNrInPins number of input pins for this unit
+ baSourceID list of the IDs of the units or terminals
+ to which this XU is connected
+ bControlSize size of the bmControls field in bytes
+ bmControls list of bitmaps detailing which vendor
+ specific controls are supported
+ iExtension index of a string descriptor that describes
+ this extension unit
+ ================= ========================================
+
What: /config/usb-gadget/gadget/functions/uvc.name/control/header
Date: Dec 2014
KernelVersion: 4.0
@@ -165,7 +195,24 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Default color matching descriptors
- All attributes read only:
+ All attributes read/write:
+
+ ======================== ======================================
+ bMatrixCoefficients matrix used to compute luma and
+ chroma values from the color primaries
+ bTransferCharacteristics optoelectronic transfer
+ characteristic of the source picture,
+ also called the gamma function
+ bColorPrimaries color primaries and the reference
+ white
+ ======================== ======================================
+
+What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching/name
+Date: Dec 2022
+KernelVersion: 6.3
+Description: Additional color matching descriptors
+
+ All attributes read/write:
======================== ======================================
bMatrixCoefficients matrix used to compute luma and
@@ -197,7 +244,7 @@ Description: Specific MJPEG format descriptors
read-only
bmaControls this format's data for bmaControls in
the streaming header
- bmInterfaceFlags specifies interlace information,
+ bmInterlaceFlags specifies interlace information,
read-only
bAspectRatioY the X dimension of the picture aspect
ratio, read-only
@@ -253,7 +300,7 @@ Description: Specific uncompressed format descriptors
read-only
bmaControls this format's data for bmaControls in
the streaming header
- bmInterfaceFlags specifies interlace information,
+ bmInterlaceFlags specifies interlace information,
read-only
bAspectRatioY the X dimension of the picture aspect
ratio, read-only
@@ -295,6 +342,70 @@ Description: Specific uncompressed frame descriptors
support
========================= =====================================
+What: /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased
+Date: Sept 2024
+KernelVersion: 5.15
+Description: Framebased format descriptors
+
+What: /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased/name
+Date: Sept 2024
+KernelVersion: 5.15
+Description: Specific framebased format descriptors
+
+ ================== =======================================
+ bFormatIndex unique id for this format descriptor;
+ only defined after parent header is
+ linked into the streaming class;
+ read-only
+ bmaControls this format's data for bmaControls in
+ the streaming header
+ bmInterlaceFlags specifies interlace information,
+ read-only
+ bAspectRatioY the X dimension of the picture aspect
+ ratio, read-only
+ bAspectRatioX the Y dimension of the picture aspect
+ ratio, read-only
+ bDefaultFrameIndex optimum frame index for this stream
+ bBitsPerPixel number of bits per pixel used to
+ specify color in the decoded video
+ frame
+ guidFormat globally unique id used to identify
+ stream-encoding format
+ ================== =======================================
+
+What: /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased/name/name
+Date: Sept 2024
+KernelVersion: 5.15
+Description: Specific framebased frame descriptors
+
+ ========================= =====================================
+ bFrameIndex unique id for this framedescriptor;
+ only defined after parent format is
+ linked into the streaming header;
+ read-only
+ dwFrameInterval indicates how frame interval can be
+ programmed; a number of values
+ separated by newline can be specified
+ dwDefaultFrameInterval the frame interval the device would
+ like to use as default
+ dwBytesPerLine Specifies the number of bytes per line
+ of video for packed fixed frame size
+ formats, allowing the receiver to
+ perform stride alignment of the video.
+ If the bVariableSize value (above) is
+ TRUE (1), or if the format does not
+ permit such alignment, this value shall
+ be set to zero (0).
+ dwMaxBitRate the maximum bit rate at the shortest
+ frame interval in bps
+ dwMinBitRate the minimum bit rate at the longest
+ frame interval in bps
+ wHeight height of decoded bitmap frame in px
+ wWidth width of decoded bitmam frame in px
+ bmCapabilities still image support, fixed frame-rate
+ support
+ ========================= =====================================
+
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
Date: Dec 2014
KernelVersion: 4.0
diff --git a/Documentation/ABI/testing/debugfs-alienware-wmi b/Documentation/ABI/testing/debugfs-alienware-wmi
new file mode 100644
index 000000000000..c7f525d6baac
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-alienware-wmi
@@ -0,0 +1,64 @@
+What: /sys/kernel/debug/alienware-wmi-<wmi_device_name>/system_description
+Date: March 2025
+KernelVersion: 6.15
+Contact: Kurt Borja <kuurtb@gmail.com>
+Description:
+ This file exposes the raw ``system_description`` number reported
+ by the WMAX device.
+
+ Only present on devices with the AWCC interface.
+
+ See Documentation/admin-guide/laptops/alienware-wmi.rst for
+ details.
+
+ RO
+
+What: /sys/kernel/debug/alienware-wmi-<wmi_device_name>/hwmon_data
+Date: March 2025
+KernelVersion: 6.15
+Contact: Kurt Borja <kuurtb@gmail.com>
+Description:
+ This file exposes HWMON private data.
+
+ Includes fan sensor count, temperature sensor count, internal
+ fan IDs and internal temp IDs.
+
+ See Documentation/admin-guide/laptops/alienware-wmi.rst for
+ details.
+
+ RO
+
+What: /sys/kernel/debug/alienware-wmi-<wmi_device_name>/pprof_data
+Date: March 2025
+KernelVersion: 6.15
+Contact: Kurt Borja <kuurtb@gmail.com>
+Description:
+ This file exposes Platform Profile private data.
+
+ Includes internal mapping to platform profiles and thermal
+ profile IDs.
+
+ See Documentation/admin-guide/laptops/alienware-wmi.rst for
+ details.
+
+ RO
+
+What: /sys/kernel/debug/alienware-wmi-<wmi_device_name>/gpio_ctl/total_gpios
+Date: May 2025
+KernelVersion: 6.16
+Contact: Kurt Borja <kuurtb@gmail.com>
+Description:
+ Total number of GPIO pins reported by the device.
+
+ RO
+
+What: /sys/kernel/debug/alienware-wmi-<wmi_device_name>/gpio_ctl/pinX
+Date: May 2025
+KernelVersion: 6.16
+Contact: Kurt Borja <kuurtb@gmail.com>
+Description:
+ This file controls GPIO pin X status.
+
+ See Documentation/wmi/devices/alienware-wmi.rst for details.
+
+ RW
diff --git a/Documentation/ABI/testing/debugfs-amd-iommu b/Documentation/ABI/testing/debugfs-amd-iommu
new file mode 100644
index 000000000000..5621a66aa693
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-amd-iommu
@@ -0,0 +1,131 @@
+What: /sys/kernel/debug/iommu/amd/iommu<x>/mmio
+Date: January 2025
+Contact: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
+Description:
+ This file provides read/write access for user input. Users specify the
+ MMIO register offset for iommu<x>, and the file outputs the corresponding
+ MMIO register value of iommu<x>
+
+ Example::
+
+ $ echo "0x18" > /sys/kernel/debug/iommu/amd/iommu00/mmio
+ $ cat /sys/kernel/debug/iommu/amd/iommu00/mmio
+
+ Output::
+
+ Offset:0x18 Value:0x000c22000003f48d
+
+What: /sys/kernel/debug/iommu/amd/iommu<x>/capability
+Date: January 2025
+Contact: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
+Description:
+ This file provides read/write access for user input. Users specify the
+ capability register offset for iommu<x>, and the file outputs the
+ corresponding capability register value of iommu<x>.
+
+ Example::
+
+ $ echo "0x10" > /sys/kernel/debug/iommu/amd/iommu00/capability
+ $ cat /sys/kernel/debug/iommu/amd/iommu00/capability
+
+ Output::
+
+ Offset:0x10 Value:0x00203040
+
+What: /sys/kernel/debug/iommu/amd/iommu<x>/cmdbuf
+Date: January 2025
+Contact: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
+Description:
+ This file is a read-only output file containing iommu<x> command
+ buffer entries.
+
+ Examples::
+
+ $ cat /sys/kernel/debug/iommu/amd/iommu<x>/cmdbuf
+
+ Output::
+
+ CMD Buffer Head Offset:339 Tail Offset:339
+ 0: 00835001 10000001 00003c00 00000000
+ 1: 00000000 30000005 fffff003 7fffffff
+ 2: 00835001 10000001 00003c01 00000000
+ 3: 00000000 30000005 fffff003 7fffffff
+ 4: 00835001 10000001 00003c02 00000000
+ 5: 00000000 30000005 fffff003 7fffffff
+ 6: 00835001 10000001 00003c03 00000000
+ 7: 00000000 30000005 fffff003 7fffffff
+ 8: 00835001 10000001 00003c04 00000000
+ 9: 00000000 30000005 fffff003 7fffffff
+ 10: 00835001 10000001 00003c05 00000000
+ 11: 00000000 30000005 fffff003 7fffffff
+ [...]
+
+What: /sys/kernel/debug/iommu/amd/devid
+Date: January 2025
+Contact: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
+Description:
+ This file provides read/write access for user input. Users specify the
+ device ID, which can be used to dump IOMMU data structures such as the
+ interrupt remapping table and device table.
+
+ Example:
+
+ 1.
+ ::
+
+ $ echo 0000:01:00.0 > /sys/kernel/debug/iommu/amd/devid
+ $ cat /sys/kernel/debug/iommu/amd/devid
+
+ Output::
+
+ 0000:01:00.0
+
+ 2.
+ ::
+
+ $ echo 01:00.0 > /sys/kernel/debug/iommu/amd/devid
+ $ cat /sys/kernel/debug/iommu/amd/devid
+
+ Output::
+
+ 0000:01:00.0
+
+What: /sys/kernel/debug/iommu/amd/devtbl
+Date: January 2025
+Contact: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
+Description:
+ This file is a read-only output file containing the device table entry
+ for the device ID provided in /sys/kernel/debug/iommu/amd/devid.
+
+ Example::
+
+ $ cat /sys/kernel/debug/iommu/amd/devtbl
+
+ Output::
+
+ DeviceId QWORD[3] QWORD[2] QWORD[1] QWORD[0] iommu
+ 0000:01:00.0 0000000000000000 20000001373b8013 0000000000000038 6000000114d7b603 iommu3
+
+What: /sys/kernel/debug/iommu/amd/irqtbl
+Date: January 2025
+Contact: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
+Description:
+ This file is a read-only output file containing valid IRT table entries
+ for the device ID provided in /sys/kernel/debug/iommu/amd/devid.
+
+ Example::
+
+ $ cat /sys/kernel/debug/iommu/amd/irqtbl
+
+ Output::
+
+ DeviceId 0000:01:00.0
+ IRT[0000] 0000000000000020 0000000000000241
+ IRT[0001] 0000000000000020 0000000000000841
+ IRT[0002] 0000000000000020 0000000000002041
+ IRT[0003] 0000000000000020 0000000000008041
+ IRT[0004] 0000000000000020 0000000000020041
+ IRT[0005] 0000000000000020 0000000000080041
+ IRT[0006] 0000000000000020 0000000000200041
+ IRT[0007] 0000000000000020 0000000000800041
+ [...]
diff --git a/Documentation/ABI/testing/debugfs-cec-error-inj b/Documentation/ABI/testing/debugfs-cec-error-inj
index 8debcb08a3b5..c512f71bba8e 100644
--- a/Documentation/ABI/testing/debugfs-cec-error-inj
+++ b/Documentation/ABI/testing/debugfs-cec-error-inj
@@ -1,6 +1,6 @@
What: /sys/kernel/debug/cec/*/error-inj
Date: March 2018
-Contact: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Contact: Hans Verkuil <hverkuil@kernel.org>
Description:
The CEC Framework allows for CEC error injection commands through
diff --git a/Documentation/ABI/testing/debugfs-cxl b/Documentation/ABI/testing/debugfs-cxl
new file mode 100644
index 000000000000..2989d4da96c1
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-cxl
@@ -0,0 +1,157 @@
+What: /sys/kernel/debug/cxl/memX/inject_poison
+Date: April, 2023
+KernelVersion: v6.4
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) When a Device Physical Address (DPA) is written to this
+ attribute, the memdev driver sends an inject poison command to
+ the device for the specified address. The DPA must be 64-byte
+ aligned and the length of the injected poison is 64-bytes. If
+ successful, the device returns poison when the address is
+ accessed through the CXL.mem bus. Injecting poison adds the
+ address to the device's Poison List and the error source is set
+ to Injected. In addition, the device adds a poison creation
+ event to its internal Informational Event log, updates the
+ Event Status register, and if configured, interrupts the host.
+ It is not an error to inject poison into an address that
+ already has poison present and no error is returned. If the
+ device returns 'Inject Poison Limit Reached' an -EBUSY error
+ is returned to the user. The inject_poison attribute is only
+ visible for devices supporting the capability.
+
+ TEST-ONLY INTERFACE: This interface is intended for testing
+ and validation purposes only. It is not a data repair mechanism
+ and should never be used on production systems or live data.
+
+ DATA LOSS RISK: For CXL persistent memory (PMEM) devices,
+ poison injection can result in permanent data loss. Injected
+ poison may render data permanently inaccessible even after
+ clearing, as the clear operation writes zeros and does not
+ recover original data.
+
+ SYSTEM STABILITY RISK: For volatile memory, poison injection
+ can cause kernel crashes, system instability, or unpredictable
+ behavior if the poisoned addresses are accessed by running code
+ or critical kernel structures.
+
+What: /sys/kernel/debug/cxl/memX/clear_poison
+Date: April, 2023
+KernelVersion: v6.4
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) When a Device Physical Address (DPA) is written to this
+ attribute, the memdev driver sends a clear poison command to
+ the device for the specified address. Clearing poison removes
+ the address from the device's Poison List and writes 0 (zero)
+ for 64 bytes starting at address. It is not an error to clear
+ poison from an address that does not have poison set. If the
+ device cannot clear poison from the address, -ENXIO is returned.
+ The clear_poison attribute is only visible for devices
+ supporting the capability.
+
+ TEST-ONLY INTERFACE: This interface is intended for testing
+ and validation purposes only. It is not a data repair mechanism
+ and should never be used on production systems or live data.
+
+ CLEAR IS NOT DATA RECOVERY: This operation writes zeros to the
+ specified address range and removes the address from the poison
+ list. It does NOT recover or restore original data that may have
+ been present before poison injection. Any original data at the
+ cleared address is permanently lost and replaced with zeros.
+
+ CLEAR IS NOT A REPAIR MECHANISM: This interface is for testing
+ purposes only and should not be used as a data repair tool.
+ Clearing poison is fundamentally different from data recovery
+ or error correction.
+
+What: /sys/kernel/debug/cxl/regionX/inject_poison
+Date: August, 2025
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) When a Host Physical Address (HPA) is written to this
+ attribute, the region driver translates it to a Device
+ Physical Address (DPA) and identifies the corresponding
+ memdev. It then sends an inject poison command to that memdev
+ at the translated DPA. Refer to the memdev ABI entry at:
+ /sys/kernel/debug/cxl/memX/inject_poison for the detailed
+ behavior. This attribute is only visible if all memdevs
+ participating in the region support both inject and clear
+ poison commands.
+
+ TEST-ONLY INTERFACE: This interface is intended for testing
+ and validation purposes only. It is not a data repair mechanism
+ and should never be used on production systems or live data.
+
+ DATA LOSS RISK: For CXL persistent memory (PMEM) devices,
+ poison injection can result in permanent data loss. Injected
+ poison may render data permanently inaccessible even after
+ clearing, as the clear operation writes zeros and does not
+ recover original data.
+
+ SYSTEM STABILITY RISK: For volatile memory, poison injection
+ can cause kernel crashes, system instability, or unpredictable
+ behavior if the poisoned addresses are accessed by running code
+ or critical kernel structures.
+
+What: /sys/kernel/debug/cxl/regionX/clear_poison
+Date: August, 2025
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) When a Host Physical Address (HPA) is written to this
+ attribute, the region driver translates it to a Device
+ Physical Address (DPA) and identifies the corresponding
+ memdev. It then sends a clear poison command to that memdev
+ at the translated DPA. Refer to the memdev ABI entry at:
+ /sys/kernel/debug/cxl/memX/clear_poison for the detailed
+ behavior. This attribute is only visible if all memdevs
+ participating in the region support both inject and clear
+ poison commands.
+
+ TEST-ONLY INTERFACE: This interface is intended for testing
+ and validation purposes only. It is not a data repair mechanism
+ and should never be used on production systems or live data.
+
+ CLEAR IS NOT DATA RECOVERY: This operation writes zeros to the
+ specified address range and removes the address from the poison
+ list. It does NOT recover or restore original data that may have
+ been present before poison injection. Any original data at the
+ cleared address is permanently lost and replaced with zeros.
+
+ CLEAR IS NOT A REPAIR MECHANISM: This interface is for testing
+ purposes only and should not be used as a data repair tool.
+ Clearing poison is fundamentally different from data recovery
+ or error correction.
+
+What: /sys/kernel/debug/cxl/einj_types
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) Prints the CXL protocol error types made available by
+ the platform in the format:
+
+ 0x<error number> <error type>
+
+ The possible error types are (as of ACPI v6.5):
+
+ 0x1000 CXL.cache Protocol Correctable
+ 0x2000 CXL.cache Protocol Uncorrectable non-fatal
+ 0x4000 CXL.cache Protocol Uncorrectable fatal
+ 0x8000 CXL.mem Protocol Correctable
+ 0x10000 CXL.mem Protocol Uncorrectable non-fatal
+ 0x20000 CXL.mem Protocol Uncorrectable fatal
+
+ The <error number> can be written to einj_inject to inject
+ <error type> into a chosen dport.
+
+What: /sys/kernel/debug/cxl/$dport_dev/einj_inject
+Date: January, 2024
+KernelVersion: v6.9
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) Writing an integer to this file injects the corresponding
+ CXL protocol error into $dport_dev ($dport_dev will be a device
+ name from /sys/bus/pci/devices). The integer to type mapping for
+ injection can be found by reading from einj_types. If the dport
+ was enumerated in RCH mode, a CXL 1.1 error is injected, otherwise
+ a CXL 2.0 error is injected.
diff --git a/Documentation/ABI/testing/debugfs-dell-wmi-ddv b/Documentation/ABI/testing/debugfs-dell-wmi-ddv
new file mode 100644
index 000000000000..81cfc788be15
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-dell-wmi-ddv
@@ -0,0 +1,34 @@
+What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/fan_sensor_information
+Date: September 2022
+KernelVersion: 6.1
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ This file contains the contents of the fan sensor information
+ buffer, which contains fan sensor entries and a terminating
+ character (0xFF).
+
+ Each fan sensor entry contains:
+
+ - fan type (single byte)
+ - fan speed in RPM (two bytes, little endian)
+
+ See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
+
+What: /sys/kernel/debug/dell-wmi-ddv-<wmi_device_name>/thermal_sensor_information
+Date: September 2022
+KernelVersion: 6.1
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ This file contains the contents of the thermal sensor information
+ buffer, which contains thermal sensor entries and a terminating
+ character (0xFF).
+
+ Each thermal sensor entry contains:
+
+ - thermal type (single byte)
+ - current temperature (single byte)
+ - min. temperature (single byte)
+ - max. temperature (single byte)
+ - unknown field (single byte)
+
+ See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
diff --git a/Documentation/ABI/testing/debugfs-driver-dcc b/Documentation/ABI/testing/debugfs-driver-dcc
new file mode 100644
index 000000000000..27ed5919d21b
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-driver-dcc
@@ -0,0 +1,127 @@
+What: /sys/kernel/debug/dcc/.../ready
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This file is used to check the status of the dcc
+ hardware if it's ready to receive user configurations.
+ A 'Y' here indicates dcc is ready.
+
+What: /sys/kernel/debug/dcc/.../trigger
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This is the debugfs interface for manual software
+ triggers. The trigger can be invoked by writing '1'
+ to the file.
+
+What: /sys/kernel/debug/dcc/.../config_reset
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This file is used to reset the configuration of
+ a dcc driver to the default configuration. When '1'
+ is written to the file, all the previous addresses
+ stored in the driver gets removed and users need to
+ reconfigure addresses again.
+
+What: /sys/kernel/debug/dcc/.../[list-number]/config
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This stores the addresses of the registers which
+ can be read in case of a hardware crash or manual
+ software triggers. The input addresses type
+ can be one of following dcc instructions: read,
+ write, read-write, and loop type. The lists need to
+ be configured sequentially and not in a overlapping
+ manner; e.g. users can jump to list x only after
+ list y is configured and enabled. The input format for
+ each type is as follows:
+
+ i) Read instruction
+
+ ::
+
+ echo R <addr> <n> <bus> >/sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <addr>
+ The address to be read.
+
+ <n>
+ The addresses word count, starting from address <1>.
+ Each word is 32 bits (4 bytes). If omitted, defaulted
+ to 1.
+
+ <bus type>
+ The bus type, which can be either 'apb' or 'ahb'.
+ The default is 'ahb' if leaved out.
+
+ ii) Write instruction
+
+ ::
+
+ echo W <addr> <n> <bus type> > /sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <addr>
+ The address to be written.
+
+ <n>
+ The value to be written at <addr>.
+
+ <bus type>
+ The bus type, which can be either 'apb' or 'ahb'.
+
+ iii) Read-write instruction
+
+ ::
+
+ echo RW <addr> <n> <mask> > /sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <addr>
+ The address to be read and written.
+
+ <n>
+ The value to be written at <addr>.
+
+ <mask>
+ The value mask.
+
+ iv) Loop instruction
+
+ ::
+
+ echo L <loop count> <address count> <address>... > /sys/kernel/debug/dcc/../[list-number]/config
+
+ where:
+
+ <loop count>
+ Number of iterations
+
+ <address count>
+ total number of addresses to be written
+
+ <address>
+ Space-separated list of addresses.
+
+What: /sys/kernel/debug/dcc/.../[list-number]/enable
+Date: December 2022
+Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+Description:
+ This debugfs interface is used for enabling the
+ the dcc hardware. A file named "enable" is in the
+ directory list number where users can enable/disable
+ the specific list by writing boolean (1 or 0) to the
+ file.
+
+ On enabling the dcc, all the addresses specified
+ by the user for the corresponding list is written
+ into dcc sram which is read by the dcc hardware
+ on manual or crash induced triggers. Lists must
+ be configured and enabled sequentially, e.g. list
+ 2 can only be enabled when list 1 have so.
diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs
index c915bf17b293..3318a14f35b9 100644
--- a/Documentation/ABI/testing/debugfs-driver-habanalabs
+++ b/Documentation/ABI/testing/debugfs-driver-habanalabs
@@ -1,4 +1,4 @@
-What: /sys/kernel/debug/habanalabs/hl<n>/addr
+What: /sys/kernel/debug/accel/<parent_device>/addr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -8,34 +8,34 @@ Description: Sets the device address to be used for read or write through
only when the IOMMU is disabled.
The acceptable value is a string that starts with "0x"
-What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate
+What: /sys/kernel/debug/accel/<parent_device>/clk_gate
Date: May 2020
KernelVersion: 5.8
Contact: ogabbay@kernel.org
Description: This setting is now deprecated as clock gating is handled solely by the f/w
-What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
+What: /sys/kernel/debug/accel/<parent_device>/command_buffers
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently allocated
command buffers
-What: /sys/kernel/debug/habanalabs/hl<n>/command_submission
+What: /sys/kernel/debug/accel/<parent_device>/command_submission
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently active
command submissions
-What: /sys/kernel/debug/habanalabs/hl<n>/command_submission_jobs
+What: /sys/kernel/debug/accel/<parent_device>/command_submission_jobs
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with detailed information about each JOB (CB) of
each active command submission
-What: /sys/kernel/debug/habanalabs/hl<n>/data32
+What: /sys/kernel/debug/accel/<parent_device>/data32
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -50,7 +50,7 @@ Description: Allows the root user to read or write directly through the
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
-What: /sys/kernel/debug/habanalabs/hl<n>/data64
+What: /sys/kernel/debug/accel/<parent_device>/data64
Date: Jan 2020
KernelVersion: 5.6
Contact: ogabbay@kernel.org
@@ -65,7 +65,7 @@ Description: Allows the root user to read or write 64 bit data directly
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
-What: /sys/kernel/debug/habanalabs/hl<n>/data_dma
+What: /sys/kernel/debug/accel/<parent_device>/data_dma
Date: Apr 2021
KernelVersion: 5.13
Contact: ogabbay@kernel.org
@@ -79,11 +79,11 @@ Description: Allows the root user to read from the device's internal
a very long time.
This interface doesn't support concurrency in the same device.
In GAUDI and GOYA, this action can cause undefined behavior
- in case the it is done while the device is executing user
+ in case it is done while the device is executing user
workloads.
Only supported on GAUDI at this stage.
-What: /sys/kernel/debug/habanalabs/hl<n>/device
+What: /sys/kernel/debug/accel/<parent_device>/device
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -91,7 +91,14 @@ Description: Enables the root user to set the device to specific state.
Valid values are "disable", "enable", "suspend", "resume".
User can read this property to see the valid values
-What: /sys/kernel/debug/habanalabs/hl<n>/dma_size
+What: /sys/kernel/debug/accel/<parent_device>/device_release_watchdog_timeout
+Date: Oct 2022
+KernelVersion: 6.2
+Contact: ttayar@habana.ai
+Description: The watchdog timeout value in seconds for a device release upon
+ certain error cases, after which the device is reset.
+
+What: /sys/kernel/debug/accel/<parent_device>/dma_size
Date: Apr 2021
KernelVersion: 5.13
Contact: ogabbay@kernel.org
@@ -101,7 +108,7 @@ Description: Specify the size of the DMA transaction when using DMA to read
When the write is finished, the user can read the "data_dma"
blob
-What: /sys/kernel/debug/habanalabs/hl<n>/dump_razwi_events
+What: /sys/kernel/debug/accel/<parent_device>/dump_razwi_events
Date: Aug 2022
KernelVersion: 5.20
Contact: fkassabri@habana.ai
@@ -110,7 +117,7 @@ Description: Dumps all razwi events to dmesg if exist.
the routine will clear the status register.
Usage: cat dump_razwi_events
-What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations
+What: /sys/kernel/debug/accel/<parent_device>/dump_security_violations
Date: Jan 2021
KernelVersion: 5.12
Contact: ogabbay@kernel.org
@@ -118,14 +125,14 @@ Description: Dumps all security violations to dmesg. This will also ack
all security violations meanings those violations will not be
dumped next time user calls this API
-What: /sys/kernel/debug/habanalabs/hl<n>/engines
+What: /sys/kernel/debug/accel/<parent_device>/engines
Date: Jul 2019
KernelVersion: 5.3
Contact: ogabbay@kernel.org
Description: Displays the status registers values of the device engines and
their derived idle status
-What: /sys/kernel/debug/habanalabs/hl<n>/i2c_addr
+What: /sys/kernel/debug/accel/<parent_device>/i2c_addr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -133,7 +140,7 @@ Description: Sets I2C device address for I2C transaction that is generated
by the device's CPU, Not available when device is loaded with secured
firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
+What: /sys/kernel/debug/accel/<parent_device>/i2c_bus
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -141,7 +148,7 @@ Description: Sets I2C bus address for I2C transaction that is generated by
the device's CPU, Not available when device is loaded with secured
firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
+What: /sys/kernel/debug/accel/<parent_device>/i2c_data
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -150,7 +157,7 @@ Description: Triggers an I2C transaction that is generated by the device's
reading from the file generates a read transaction, Not available
when device is loaded with secured firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len
+What: /sys/kernel/debug/accel/<parent_device>/i2c_len
Date: Dec 2021
KernelVersion: 5.17
Contact: obitton@habana.ai
@@ -158,7 +165,7 @@ Description: Sets I2C length in bytes for I2C transaction that is generated b
the device's CPU, Not available when device is loaded with secured
firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
+What: /sys/kernel/debug/accel/<parent_device>/i2c_reg
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -166,35 +173,35 @@ Description: Sets I2C register id for I2C transaction that is generated by
the device's CPU, Not available when device is loaded with secured
firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/led0
+What: /sys/kernel/debug/accel/<parent_device>/led0
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the first S/W led on the device, Not available
when device is loaded with secured firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/led1
+What: /sys/kernel/debug/accel/<parent_device>/led1
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the second S/W led on the device, Not available
when device is loaded with secured firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/led2
+What: /sys/kernel/debug/accel/<parent_device>/led2
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the third S/W led on the device, Not available
when device is loaded with secured firmware
-What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub
+What: /sys/kernel/debug/accel/<parent_device>/memory_scrub
Date: May 2022
KernelVersion: 5.19
Contact: dhirschfeld@habana.ai
Description: Allows the root user to scrub the dram memory. The scrubbing
value can be set using the debugfs file memory_scrub_val.
-What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub_val
+What: /sys/kernel/debug/accel/<parent_device>/memory_scrub_val
Date: May 2022
KernelVersion: 5.19
Contact: dhirschfeld@habana.ai
@@ -202,7 +209,7 @@ Description: The value to which the dram will be set to when the user
scrubs the dram using 'memory_scrub' debugfs file and
the scrubbing value when using module param 'memory_scrub'
-What: /sys/kernel/debug/habanalabs/hl<n>/mmu
+What: /sys/kernel/debug/accel/<parent_device>/mmu
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -210,19 +217,19 @@ Description: Displays the hop values and physical address for a given ASID
and virtual address. The user should write the ASID and VA into
the file and then read the file to get the result.
e.g. to display info about VA 0x1000 for ASID 1 you need to do:
- echo "1 0x1000" > /sys/kernel/debug/habanalabs/hl0/mmu
+ echo "1 0x1000" > /sys/kernel/debug/accel/<parent_device>/mmu
-What: /sys/kernel/debug/habanalabs/hl<n>/mmu_error
+What: /sys/kernel/debug/accel/<parent_device>/mmu_error
Date: Mar 2021
KernelVersion: 5.12
Contact: fkassabri@habana.ai
Description: Check and display page fault or access violation mmu errors for
all MMUs specified in mmu_cap_mask.
e.g. to display error info for MMU hw cap bit 9, you need to do:
- echo "0x200" > /sys/kernel/debug/habanalabs/hl0/mmu_error
- cat /sys/kernel/debug/habanalabs/hl0/mmu_error
+ echo "0x200" > /sys/kernel/debug/accel/<parent_device>/mmu_error
+ cat /sys/kernel/debug/accel/<parent_device>/mmu_error
-What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump
+What: /sys/kernel/debug/accel/<parent_device>/monitor_dump
Date: Mar 2022
KernelVersion: 5.19
Contact: osharabi@habana.ai
@@ -236,7 +243,7 @@ Description: Allows the root user to dump monitors status from the device's
This interface doesn't support concurrency in the same device.
Only supported on GAUDI.
-What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump_trig
+What: /sys/kernel/debug/accel/<parent_device>/monitor_dump_trig
Date: Mar 2022
KernelVersion: 5.19
Contact: osharabi@habana.ai
@@ -246,14 +253,20 @@ Description: Triggers dump of monitor data. The value to trigger the operatio
When the write is finished, the user can read the "monitor_dump"
blob
-What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
+What: /sys/kernel/debug/accel/<parent_device>/server_type
+Date: Feb 2024
+KernelVersion: 6.11
+Contact: trisin@habana.ai
+Description: Exposes the device's server type, maps to enum hl_server_type.
+
+What: /sys/kernel/debug/accel/<parent_device>/set_power_state
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
for D3Hot
-What: /sys/kernel/debug/habanalabs/hl<n>/skip_reset_on_timeout
+What: /sys/kernel/debug/accel/<parent_device>/skip_reset_on_timeout
Date: Jun 2021
KernelVersion: 5.13
Contact: ynudelman@habana.ai
@@ -261,7 +274,7 @@ Description: Sets the skip reset on timeout option for the device. Value of
"0" means device will be reset in case some CS has timed out,
otherwise it will not be reset.
-What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
+What: /sys/kernel/debug/accel/<parent_device>/state_dump
Date: Oct 2021
KernelVersion: 5.15
Contact: ynudelman@habana.ai
@@ -272,7 +285,7 @@ Description: Gets the state dump occurring on a CS timeout or failure.
Writing an integer X discards X state dumps, so that the
next read would return X+1-st newest state dump.
-What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
+What: /sys/kernel/debug/accel/<parent_device>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
Contact: ogabbay@kernel.org
@@ -280,21 +293,21 @@ Description: Sets the stop-on_error option for the device engines. Value of
"0" is for disable, otherwise enable.
Relevant only for GOYA and GAUDI.
-What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked
+What: /sys/kernel/debug/accel/<parent_device>/timeout_locked
Date: Sep 2021
KernelVersion: 5.16
Contact: obitton@habana.ai
Description: Sets the command submission timeout value in seconds.
-What: /sys/kernel/debug/habanalabs/hl<n>/userptr
+What: /sys/kernel/debug/accel/<parent_device>/userptr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
-Description: Displays a list with information about the currently user
+Description: Displays a list with information about the current user
pointers (user virtual addresses) that are pinned and mapped
to DMA addresses
-What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
+What: /sys/kernel/debug/accel/<parent_device>/userptr_lookup
Date: Oct 2021
KernelVersion: 5.15
Contact: ogabbay@kernel.org
@@ -302,7 +315,7 @@ Description: Allows to search for specific user pointers (user virtual
addresses) that are pinned and mapped to DMA addresses, and see
their resolution to the specific dma address.
-What: /sys/kernel/debug/habanalabs/hl<n>/vm
+What: /sys/kernel/debug/accel/<parent_device>/vm
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
diff --git a/Documentation/ABI/testing/debugfs-driver-qat b/Documentation/ABI/testing/debugfs-driver-qat
new file mode 100644
index 000000000000..3f1efbbad6ca
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-driver-qat
@@ -0,0 +1,109 @@
+What: /sys/kernel/debug/qat_<device>_<BDF>/fw_counters
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the number of requests sent to the FW and the number of responses
+ received from the FW for each Acceleration Engine
+ Reported firmware counters::
+
+ <N>: Number of requests sent from Acceleration Engine N to FW and responses
+ Acceleration Engine N received from FW
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/config
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RW) Read returns value of the Heartbeat update period.
+ Write to the file changes this period value.
+
+ This period should reflect planned polling interval of device
+ health status. High frequency Heartbeat monitoring wastes CPU cycles
+ but minimizes the customer’s system downtime. Also, if there are
+ large service requests that take some time to complete, high frequency
+ Heartbeat monitoring could result in false reports of unresponsiveness
+ and in those cases, period needs to be increased.
+
+ This parameter is effective only for c3xxx, c62x, dh895xcc devices.
+ 4xxx has this value internally fixed to 200ms.
+
+ Default value is set to 500. Minimal allowed value is 200.
+ All values are expressed in milliseconds.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_failed
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the number of times the device became unresponsive.
+
+ Attribute returns value of the counter which is incremented when
+ status query results negative.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/queries_sent
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the number of times the control process checked
+ if the device is responsive.
+
+ Attribute returns value of the counter which is incremented on
+ every status query.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/status
+Date: November 2023
+KernelVersion: 6.6
+Contact: qat-linux@intel.com
+Description: (RO) Read returns the device health status.
+
+ Returns 0 when device is healthy or -1 when is unresponsive
+ or the query failed to send.
+
+ The driver does not monitor for Heartbeat. It is left for a user
+ to poll the status periodically.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/pm_status
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description: (RO) Read returns power management information specific to the
+ QAT device.
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/cnv_errors
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description: (RO) Read returns, for each Acceleration Engine (AE), the number
+ of errors and the type of the last error detected by the device
+ when performing verified compression.
+ Reported counters::
+
+ <N>: Number of Compress and Verify (CnV) errors and type
+ of the last CnV error detected by Acceleration
+ Engine N.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/heartbeat/inject_error
+Date: March 2024
+KernelVersion: 6.8
+Contact: qat-linux@intel.com
+Description: (WO) Write to inject an error that simulates an heartbeat
+ failure. This is to be used for testing purposes.
+
+ After writing this file, the driver stops arbitration on a
+ random engine and disables the fetching of heartbeat counters.
+ If a workload is running on the device, a job submitted to the
+ accelerator might not get a response and a read of the
+ `heartbeat/status` attribute might report -1, i.e. device
+ unresponsive.
+ The error is unrecoverable thus the device must be restarted to
+ restore its functionality.
+
+ This attribute is available only when the kernel is built with
+ CONFIG_CRYPTO_DEV_QAT_ERROR_INJECTION=y.
+
+ A write of 1 enables error injection.
+
+ The following example shows how to enable error injection::
+
+ # cd /sys/kernel/debug/qat_<device>_<BDF>
+ # echo 1 > heartbeat/inject_error
diff --git a/Documentation/ABI/testing/debugfs-driver-qat_telemetry b/Documentation/ABI/testing/debugfs-driver-qat_telemetry
new file mode 100644
index 000000000000..06097ee0f154
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-driver-qat_telemetry
@@ -0,0 +1,259 @@
+What: /sys/kernel/debug/qat_<device>_<BDF>/telemetry/control
+Date: March 2024
+KernelVersion: 6.8
+Contact: qat-linux@intel.com
+Description: (RW) Enables/disables the reporting of telemetry metrics.
+
+ Allowed values to write:
+ ========================
+ * 0: disable telemetry
+ * 1: enable telemetry
+ * 2, 3, 4: enable telemetry and calculate minimum, maximum
+ and average for each counter over 2, 3 or 4 samples
+
+ Returned values:
+ ================
+ * 1-4: telemetry is enabled and running
+ * 0: telemetry is disabled
+
+ Example.
+
+ Writing '3' to this file starts the collection of
+ telemetry metrics. Samples are collected every second and
+ stored in a circular buffer of size 3. These values are then
+ used to calculate the minimum, maximum and average for each
+ counter. After enabling, counters can be retrieved through
+ the ``device_data`` file::
+
+ echo 3 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/telemetry/control
+
+ Writing '0' to this file stops the collection of telemetry
+ metrics::
+
+ echo 0 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/telemetry/control
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/telemetry/device_data
+Date: March 2024
+KernelVersion: 6.8
+Contact: qat-linux@intel.com
+Description: (RO) Reports device telemetry counters.
+ Reads report metrics about performance and utilization of
+ a QAT device:
+
+ ======================= ========================================
+ Field Description
+ ======================= ========================================
+ sample_cnt number of acquisitions of telemetry data
+ from the device. Reads are performed
+ every 1000 ms.
+ pci_trans_cnt number of PCIe partial transactions
+ max_rd_lat maximum logged read latency [ns] (could
+ be any read operation)
+ rd_lat_acc_avg average read latency [ns]
+ max_gp_lat max get to put latency [ns] (only takes
+ samples for AE0)
+ gp_lat_acc_avg average get to put latency [ns]
+ bw_in PCIe, write bandwidth [Mbps]
+ bw_out PCIe, read bandwidth [Mbps]
+ re_acc_avg average ring empty time [ns]
+ at_page_req_lat_avg Address Translator(AT), average page
+ request latency [ns]
+ at_trans_lat_avg AT, average page translation latency [ns]
+ at_max_tlb_used AT, maximum uTLB used
+ util_cpr<N> utilization of Compression slice N [%]
+ exec_cpr<N> execution count of Compression slice N
+ util_xlt<N> utilization of Translator slice N [%]
+ exec_xlt<N> execution count of Translator slice N
+ util_dcpr<N> utilization of Decompression slice N [%]
+ exec_dcpr<N> execution count of Decompression slice N
+ util_cnv<N> utilization of Compression and verify slice N [%]
+ exec_cnv<N> execution count of Compression and verify slice N
+ util_dcprz<N> utilization of Decompression slice N [%]
+ exec_dcprz<N> execution count of Decompression slice N
+ util_pke<N> utilization of PKE N [%]
+ exec_pke<N> execution count of PKE N
+ util_ucs<N> utilization of UCS slice N [%]
+ exec_ucs<N> execution count of UCS slice N
+ util_wat<N> utilization of Wireless Authentication
+ slice N [%]
+ exec_wat<N> execution count of Wireless Authentication
+ slice N
+ util_wcp<N> utilization of Wireless Cipher slice N [%]
+ exec_wcp<N> execution count of Wireless Cipher slice N
+ util_cph<N> utilization of Cipher slice N [%]
+ exec_cph<N> execution count of Cipher slice N
+ util_ath<N> utilization of Authentication slice N [%]
+ exec_ath<N> execution count of Authentication slice N
+ cmdq_wait_cnv<N> wait time for cmdq N to get Compression and verify
+ slice ownership
+ cmdq_exec_cnv<N> Compression and verify slice execution time while
+ owned by cmdq N
+ cmdq_drain_cnv<N> time taken for cmdq N to release Compression and
+ verify slice ownership
+ cmdq_wait_dcprz<N> wait time for cmdq N to get Decompression
+ slice N ownership
+ cmdq_exec_dcprz<N> Decompression slice execution time while
+ owned by cmdq N
+ cmdq_drain_dcprz<N> time taken for cmdq N to release Decompression
+ slice ownership
+ cmdq_wait_pke<N> wait time for cmdq N to get PKE slice ownership
+ cmdq_exec_pke<N> PKE slice execution time while owned by cmdq N
+ cmdq_drain_pke<N> time taken for cmdq N to release PKE slice
+ ownership
+ cmdq_wait_ucs<N> wait time for cmdq N to get UCS slice ownership
+ cmdq_exec_ucs<N> UCS slice execution time while owned by cmdq N
+ cmdq_drain_ucs<N> time taken for cmdq N to release UCS slice
+ ownership
+ cmdq_wait_ath<N> wait time for cmdq N to get Authentication slice
+ ownership
+ cmdq_exec_ath<N> Authentication slice execution time while owned
+ by cmdq N
+ cmdq_drain_ath<N> time taken for cmdq N to release Authentication
+ slice ownership
+ ======================= ========================================
+
+ The telemetry report file can be read with the following command::
+
+ cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/telemetry/device_data
+
+ If ``control`` is set to 1, only the current values of the
+ counters are displayed::
+
+ <counter_name> <current>
+
+ If ``control`` is 2, 3 or 4, counters are displayed in the
+ following format::
+
+ <counter_name> <current> <min> <max> <avg>
+
+ If a device lacks of a specific accelerator, the corresponding
+ attribute is not reported.
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/kernel/debug/qat_<device>_<BDF>/telemetry/rp_<A/B/C/D>_data
+Date: March 2024
+KernelVersion: 6.8
+Contact: qat-linux@intel.com
+Description: (RW) Selects up to 4 Ring Pairs (RP) to monitor, one per file,
+ and report telemetry counters related to each.
+
+ Allowed values to write:
+ ========================
+ * 0 to ``<num_rps - 1>``:
+ Ring pair to be monitored. The value of ``num_rps`` can be
+ retrieved through ``/sys/bus/pci/devices/<BDF>/qat/num_rps``.
+ See Documentation/ABI/testing/sysfs-driver-qat.
+
+ Reads report metrics about performance and utilization of
+ the selected RP:
+
+ ======================= ========================================
+ Field Description
+ ======================= ========================================
+ sample_cnt number of acquisitions of telemetry data
+ from the device. Reads are performed
+ every 1000 ms
+ rp_num RP number associated with slot <A/B/C/D>
+ service_type service associated to the RP
+ pci_trans_cnt number of PCIe partial transactions
+ gp_lat_acc_avg average get to put latency [ns]
+ bw_in PCIe, write bandwidth [Mbps]
+ bw_out PCIe, read bandwidth [Mbps]
+ at_glob_devtlb_hit Message descriptor DevTLB hit rate
+ at_glob_devtlb_miss Message descriptor DevTLB miss rate
+ tl_at_payld_devtlb_hit Payload DevTLB hit rate
+ tl_at_payld_devtlb_miss Payload DevTLB miss rate
+ ======================= ========================================
+
+ Example.
+
+ Writing the value '32' to the file ``rp_C_data`` starts the
+ collection of telemetry metrics for ring pair 32::
+
+ echo 32 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/telemetry/rp_C_data
+
+ Once a ring pair is selected, statistics can be read accessing
+ the file::
+
+ cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/telemetry/rp_C_data
+
+ If ``control`` is set to 1, only the current values of the
+ counters are displayed::
+
+ <counter_name> <current>
+
+ If ``control`` is 2, 3 or 4, counters are displayed in the
+ following format::
+
+ <counter_name> <current> <min> <max> <avg>
+
+
+ On QAT GEN4 devices there are 64 RPs on a PF, so the allowed
+ values are 0..63. This number is absolute to the device.
+ If Virtual Functions (VF) are used, the ring pair number can
+ be derived from the Bus, Device, Function of the VF:
+
+ ============ ====== ====== ====== ======
+ PCI BDF/VF RP0 RP1 RP2 RP3
+ ============ ====== ====== ====== ======
+ 0000:6b:0.1 RP 0 RP 1 RP 2 RP 3
+ 0000:6b:0.2 RP 4 RP 5 RP 6 RP 7
+ 0000:6b:0.3 RP 8 RP 9 RP 10 RP 11
+ 0000:6b:0.4 RP 12 RP 13 RP 14 RP 15
+ 0000:6b:0.5 RP 16 RP 17 RP 18 RP 19
+ 0000:6b:0.6 RP 20 RP 21 RP 22 RP 23
+ 0000:6b:0.7 RP 24 RP 25 RP 26 RP 27
+ 0000:6b:1.0 RP 28 RP 29 RP 30 RP 31
+ 0000:6b:1.1 RP 32 RP 33 RP 34 RP 35
+ 0000:6b:1.2 RP 36 RP 37 RP 38 RP 39
+ 0000:6b:1.3 RP 40 RP 41 RP 42 RP 43
+ 0000:6b:1.4 RP 44 RP 45 RP 46 RP 47
+ 0000:6b:1.5 RP 48 RP 49 RP 50 RP 51
+ 0000:6b:1.6 RP 52 RP 53 RP 54 RP 55
+ 0000:6b:1.7 RP 56 RP 57 RP 58 RP 59
+ 0000:6b:2.0 RP 60 RP 61 RP 62 RP 63
+ ============ ====== ====== ====== ======
+
+ The mapping is only valid for the BDFs of VFs on the host.
+
+
+ The service provided on a ring-pair varies depending on the
+ configuration. The configuration for a given device can be
+ queried and set using ``cfg_services``.
+ See Documentation/ABI/testing/sysfs-driver-qat for details.
+
+ The following table reports how ring pairs are mapped to VFs
+ on the PF 0000:6b:0.0 configured for `sym;asym` or `asym;sym`:
+
+ =========== ============ =========== ============ ===========
+ PCI BDF/VF RP0/service RP1/service RP2/service RP3/service
+ =========== ============ =========== ============ ===========
+ 0000:6b:0.1 RP 0 asym RP 1 sym RP 2 asym RP 3 sym
+ 0000:6b:0.2 RP 4 asym RP 5 sym RP 6 asym RP 7 sym
+ 0000:6b:0.3 RP 8 asym RP 9 sym RP10 asym RP11 sym
+ ... ... ... ... ...
+ =========== ============ =========== ============ ===========
+
+ All VFs follow the same pattern.
+
+
+ The following table reports how ring pairs are mapped to VFs on
+ the PF 0000:6b:0.0 configured for `dc`:
+
+ =========== ============ =========== ============ ===========
+ PCI BDF/VF RP0/service RP1/service RP2/service RP3/service
+ =========== ============ =========== ============ ===========
+ 0000:6b:0.1 RP 0 dc RP 1 dc RP 2 dc RP 3 dc
+ 0000:6b:0.2 RP 4 dc RP 5 dc RP 6 dc RP 7 dc
+ 0000:6b:0.3 RP 8 dc RP 9 dc RP10 dc RP11 dc
+ ... ... ... ... ...
+ =========== ============ =========== ============ ===========
+
+ The mapping of a RP to a service can be retrieved using
+ ``rp2srv`` from sysfs.
+ See Documentation/ABI/testing/sysfs-driver-qat for details.
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
diff --git a/Documentation/ABI/testing/debugfs-dwc-pcie b/Documentation/ABI/testing/debugfs-dwc-pcie
new file mode 100644
index 000000000000..92b76f52a408
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-dwc-pcie
@@ -0,0 +1,157 @@
+What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_debug/lane_detect
+Date: February 2025
+Contact: Shradha Todi <shradha.t@samsung.com>
+Description: (RW) Write the lane number to be checked for detection. Read
+ will return whether PHY indicates receiver detection on the
+ selected lane. The default selected lane is Lane0.
+
+What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_debug/rx_valid
+Date: February 2025
+Contact: Shradha Todi <shradha.t@samsung.com>
+Description: (RW) Write the lane number to be checked as valid or invalid.
+ Read will return the status of PIPE RXVALID signal of the
+ selected lane. The default selected lane is Lane0.
+
+What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error>
+Date: February 2025
+Contact: Shradha Todi <shradha.t@samsung.com>
+Description: The "rasdes_err_inj" is a directory which can be used to inject
+ errors into the system. The possible errors that can be injected
+ are:
+
+ 1) tx_lcrc - TLP LCRC error injection TX Path
+ 2) b16_crc_dllp - 16b CRC error injection of ACK/NAK DLLP
+ 3) b16_crc_upd_fc - 16b CRC error injection of Update-FC DLLP
+ 4) tx_ecrc - TLP ECRC error injection TX Path
+ 5) fcrc_tlp - TLP's FCRC error injection TX Path
+ 6) parity_tsos - Parity error of TSOS
+ 7) parity_skpos - Parity error on SKPOS
+ 8) rx_lcrc - LCRC error injection RX Path
+ 9) rx_ecrc - ECRC error injection RX Path
+ 10) tlp_err_seq - TLPs SEQ# error
+ 11) ack_nak_dllp_seq - DLLPS ACK/NAK SEQ# error
+ 12) ack_nak_dllp - ACK/NAK DLLPs transmission block
+ 13) upd_fc_dllp - UpdateFC DLLPs transmission block
+ 14) nak_dllp - Always transmission for NAK DLLP
+ 15) inv_sync_hdr_sym - Invert SYNC header
+ 16) com_pad_ts1 - COM/PAD TS1 order set
+ 17) com_pad_ts2 - COM/PAD TS2 order set
+ 18) com_fts - COM/FTS FTS order set
+ 19) com_idl - COM/IDL E-idle order set
+ 20) end_edb - END/EDB symbol
+ 21) stp_sdp - STP/SDP symbol
+ 22) com_skp - COM/SKP SKP order set
+ 23) posted_tlp_hdr - Posted TLP Header credit value control
+ 24) non_post_tlp_hdr - Non-Posted TLP Header credit value control
+ 25) cmpl_tlp_hdr - Completion TLP Header credit value control
+ 26) posted_tlp_data - Posted TLP Data credit value control
+ 27) non_post_tlp_data - Non-Posted TLP Data credit value control
+ 28) cmpl_tlp_data - Completion TLP Data credit value control
+ 29) duplicate_tlp - Generates duplicate TLPs
+ 30) nullified_tlp - Generates Nullified TLPs
+
+ (WO) Write to the attribute will prepare controller to inject
+ the respective error in the next transmission of data.
+
+ Parameter required to write will change in the following ways:
+
+ - Errors 9 and 10 are sequence errors. The write command:
+
+ echo <count> <diff> > /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error>
+
+ <count>
+ Number of errors to be injected
+ <diff>
+ The difference to add or subtract from natural
+ sequence number to generate sequence error.
+ Allowed range from -4095 to 4095
+
+ - Errors 23 to 28 are credit value error insertions. The write
+ command:
+
+ echo <count> <diff> <vc> > /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error>
+
+ <count>
+ Number of errors to be injected
+ <diff>
+ The difference to add or subtract from UpdateFC
+ credit value. Allowed range from -4095 to 4095
+ <vc>
+ Target VC number
+
+ - All other errors. The write command:
+
+ echo <count> > /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error>
+
+ <count>
+ Number of errors to be injected
+
+What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_event_counters/<event>/counter_enable
+Date: February 2025
+Contact: Shradha Todi <shradha.t@samsung.com>
+Description: The "rasdes_event_counters" is the directory which can be used
+ to collect statistical data about the number of times a certain
+ event has occurred in the controller. The list of possible
+ events are:
+
+ 1) EBUF Overflow
+ 2) EBUF Underrun
+ 3) Decode Error
+ 4) Running Disparity Error
+ 5) SKP OS Parity Error
+ 6) SYNC Header Error
+ 7) Rx Valid De-assertion
+ 8) CTL SKP OS Parity Error
+ 9) 1st Retimer Parity Error
+ 10) 2nd Retimer Parity Error
+ 11) Margin CRC and Parity Error
+ 12) Detect EI Infer
+ 13) Receiver Error
+ 14) RX Recovery Req
+ 15) N_FTS Timeout
+ 16) Framing Error
+ 17) Deskew Error
+ 18) Framing Error In L0
+ 19) Deskew Uncompleted Error
+ 20) Bad TLP
+ 21) LCRC Error
+ 22) Bad DLLP
+ 23) Replay Number Rollover
+ 24) Replay Timeout
+ 25) Rx Nak DLLP
+ 26) Tx Nak DLLP
+ 27) Retry TLP
+ 28) FC Timeout
+ 29) Poisoned TLP
+ 30) ECRC Error
+ 31) Unsupported Request
+ 32) Completer Abort
+ 33) Completion Timeout
+ 34) EBUF SKP Add
+ 35) EBUF SKP Del
+
+ (RW) Write 1 to enable the event counter and write 0 to disable
+ the event counter. Read will return whether the counter is
+ currently enabled or disabled. Counter is disabled by default.
+
+What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_event_counters/<event>/counter_value
+Date: February 2025
+Contact: Shradha Todi <shradha.t@samsung.com>
+Description: (RO) Read will return the current value of the event counter.
+ To reset the counter, counter should be disabled first and then
+ enabled back using the "counter_enable" attribute.
+
+What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_event_counters/<event>/lane_select
+Date: February 2025
+Contact: Shradha Todi <shradha.t@samsung.com>
+Description: (RW) Some lanes in the event list are lane specific events.
+ These include events from 1 to 11, as well as, 34 and 35. Write
+ the lane number for which you wish the counter to be enabled,
+ disabled, or value dumped. Read will return the current
+ selected lane number. Lane0 is selected by default.
+
+What: /sys/kernel/debug/dwc_pcie_<dev>/ltssm_status
+Date: February 2025
+Contact: Hans Zhang <18255117159@163.com>
+Description: (RO) Read will return the current PCIe LTSSM state in both
+ string and raw value.
diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre
index 82abf92df429..29fb7d5ffc69 100644
--- a/Documentation/ABI/testing/debugfs-hisi-hpre
+++ b/Documentation/ABI/testing/debugfs-hisi-hpre
@@ -101,7 +101,7 @@ What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
- Four states: initiated, started, stopped and closed.
+ Two states: work, stop.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/diff_regs
@@ -111,6 +111,28 @@ Description: QM debug registers(regs) read hardware register value. This
node is used to show the change of the qm register values. This
node can be help users to check the change of register values.
+What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/qm_state
+Date: Jan 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the state of the device.
+ 0: busy, 1: idle.
+ Only available for PF, and take no other effect on HPRE.
+
+What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/dev_timeout
+Date: Feb 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Set the wait time when stop queue fails. Available for both PF
+ and VF, and take no other effect on HPRE.
+ 0: not wait(default), others value: wait dev_timeout * 20 microsecond.
+
+What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/dev_state
+Date: Feb 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the stop queue status of the QM. The default value is 0,
+ if dev_timeout is set, when stop queue fails, the dev_state
+ will return non-zero value. Available for both PF and VF,
+ and take no other effect on HPRE.
+
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
@@ -162,3 +184,10 @@ Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of time out requests.
Available for both PF and VF, and take no other effect on HPRE.
+
+What: /sys/kernel/debug/hisi_hpre/<bdf>/cap_regs
+Date: Oct 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the values of the qm and hpre capability bit registers and
+ support the query of device specifications to facilitate fault locating.
+ Available for both PF and VF, and take no other effect on HPRE.
diff --git a/Documentation/ABI/testing/debugfs-hisi-migration b/Documentation/ABI/testing/debugfs-hisi-migration
new file mode 100644
index 000000000000..2c01b2d387dd
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-hisi-migration
@@ -0,0 +1,25 @@
+What: /sys/kernel/debug/vfio/<device>/migration/hisi_acc/dev_data
+Date: Jan 2025
+KernelVersion: 6.13
+Contact: Longfang Liu <liulongfang@huawei.com>
+Description: Read the configuration data and some status data
+ required for device live migration. These data include device
+ status data, queue configuration data, some task configuration
+ data and device attribute data. The output format of the data
+ is defined by the live migration driver.
+
+What: /sys/kernel/debug/vfio/<device>/migration/hisi_acc/migf_data
+Date: Jan 2025
+KernelVersion: 6.13
+Contact: Longfang Liu <liulongfang@huawei.com>
+Description: Read the data from the last completed live migration.
+ This data includes the same device status data as in "dev_data".
+ The migf_data is the dev_data that is migrated.
+
+What: /sys/kernel/debug/vfio/<device>/migration/hisi_acc/cmd_state
+Date: Jan 2025
+KernelVersion: 6.13
+Contact: Longfang Liu <liulongfang@huawei.com>
+Description: Used to obtain the device command sending and receiving
+ channel status. Returns failure or success logs based on the
+ results.
diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec
index 93c530d1bf0f..82bf4a0dc7f7 100644
--- a/Documentation/ABI/testing/debugfs-hisi-sec
+++ b/Documentation/ABI/testing/debugfs-hisi-sec
@@ -81,7 +81,7 @@ What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
- Four states: initiated, started, stopped and closed.
+ Two states: work, stop.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/diff_regs
@@ -91,6 +91,28 @@ Description: QM debug registers(regs) read hardware register value. This
node is used to show the change of the qm register values. This
node can be help users to check the change of register values.
+What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_state
+Date: Jan 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the state of the device.
+ 0: busy, 1: idle.
+ Only available for PF, and take no other effect on SEC.
+
+What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/dev_timeout
+Date: Feb 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Set the wait time when stop queue fails. Available for both PF
+ and VF, and take no other effect on SEC.
+ 0: not wait(default), others value: wait dev_timeout * 20 microsecond.
+
+What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/dev_state
+Date: Feb 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the stop queue status of the QM. The default value is 0,
+ if dev_timeout is set, when stop queue fails, the dev_state
+ will return non-zero value. Available for both PF and VF,
+ and take no other effect on SEC.
+
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
@@ -135,3 +157,10 @@ Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but marked error requests
to be received.
Available for both PF and VF, and take no other effect on SEC.
+
+What: /sys/kernel/debug/hisi_sec2/<bdf>/cap_regs
+Date: Oct 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the values of the qm and sec capability bit registers and
+ support the query of device specifications to facilitate fault locating.
+ Available for both PF and VF, and take no other effect on SEC.
diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip
index fd3f314cf8d1..0abd65d27e9b 100644
--- a/Documentation/ABI/testing/debugfs-hisi-zip
+++ b/Documentation/ABI/testing/debugfs-hisi-zip
@@ -94,7 +94,7 @@ What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
- Four states: initiated, started, stopped and closed.
+ Two states: work, stop.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/diff_regs
@@ -104,6 +104,28 @@ Description: QM debug registers(regs) read hardware register value. This
node is used to show the change of the qm registers value. This
node can be help users to check the change of register values.
+What: /sys/kernel/debug/hisi_zip/<bdf>/qm/qm_state
+Date: Jan 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the state of the device.
+ 0: busy, 1: idle.
+ Only available for PF, and take no other effect on ZIP.
+
+What: /sys/kernel/debug/hisi_zip/<bdf>/qm/dev_timeout
+Date: Feb 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Set the wait time when stop queue fails. Available for both PF
+ and VF, and take no other effect on ZIP.
+ 0: not wait(default), others value: wait dev_timeout * 20 microsecond.
+
+What: /sys/kernel/debug/hisi_zip/<bdf>/qm/dev_state
+Date: Feb 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the stop queue status of the QM. The default value is 0,
+ if dev_timeout is set, when stop queue fails, the dev_state
+ will return non-zero value. Available for both PF and VF,
+ and take no other effect on ZIP.
+
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/diff_regs
Date: Mar 2022
Contact: linux-crypto@vger.kernel.org
@@ -136,3 +158,10 @@ Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
to be received.
Available for both PF and VF, and take no other effect on ZIP.
+
+What: /sys/kernel/debug/hisi_zip/<bdf>/cap_regs
+Date: Oct 2024
+Contact: linux-crypto@vger.kernel.org
+Description: Dump the values of the qm and zip capability bit registers and
+ support the query of device specifications to facilitate fault locating.
+ Available for both PF and VF, and take no other effect on ZIP.
diff --git a/Documentation/ABI/testing/debugfs-iio-ad9467 b/Documentation/ABI/testing/debugfs-iio-ad9467
new file mode 100644
index 000000000000..0352fca1f7f2
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-iio-ad9467
@@ -0,0 +1,39 @@
+What: /sys/kernel/debug/iio/iio:deviceX/calibration_table_dump
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ This dumps the calibration table that was filled during the
+ digital interface tuning process.
+
+What: /sys/kernel/debug/iio/iio:deviceX/in_voltage_test_mode_available
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ List all the available test tones:
+ - off
+ - midscale_short
+ - pos_fullscale
+ - neg_fullscale
+ - checkerboard
+ - prbs23
+ - prbs9
+ - one_zero_toggle
+ - user
+ - bit_toggle
+ - sync
+ - one_bit_high
+ - mixed_bit_frequency
+ - ramp
+
+ Note that depending on the actual device being used, some of the
+ above might not be available (and they won't be listed when
+ reading the file).
+
+What: /sys/kernel/debug/iio/iio:deviceX/in_voltageY_test_mode
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ Writing to this file will initiate one of available test tone on
+ channel Y. Reading it, shows which test is running. In cases
+ where an IIO backend is available and supports the test tone,
+ additional information about the data correctness is given.
diff --git a/Documentation/ABI/testing/debugfs-iio-backend b/Documentation/ABI/testing/debugfs-iio-backend
new file mode 100644
index 000000000000..01ab94469432
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-iio-backend
@@ -0,0 +1,20 @@
+What: /sys/kernel/debug/iio/iio:deviceX/backendY/name
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ Name of Backend Y connected to device X.
+
+What: /sys/kernel/debug/iio/iio:deviceX/backendY/direct_reg_access
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ Directly access the registers of backend Y. Typical usage is:
+
+ Reading address 0x50
+ echo 0x50 > direct_reg_access
+ cat direct_reg_access
+
+ Writing address 0x50
+ echo 0x50 0x3 > direct_reg_access
+ //readback address 0x50
+ cat direct_reg_access
diff --git a/Documentation/ABI/testing/debugfs-intel-iommu b/Documentation/ABI/testing/debugfs-intel-iommu
new file mode 100644
index 000000000000..2ab8464504a9
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-intel-iommu
@@ -0,0 +1,276 @@
+What: /sys/kernel/debug/iommu/intel/iommu_regset
+Date: December 2023
+Contact: Jingqi Liu <Jingqi.liu@intel.com>
+Description:
+ This file dumps all the register contents for each IOMMU device.
+
+ Example in Kabylake:
+
+ ::
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/iommu_regset
+
+ IOMMU: dmar0 Register Base Address: 26be37000
+
+ Name Offset Contents
+ VER 0x00 0x0000000000000010
+ GCMD 0x18 0x0000000000000000
+ GSTS 0x1c 0x00000000c7000000
+ FSTS 0x34 0x0000000000000000
+ FECTL 0x38 0x0000000000000000
+
+ [...]
+
+ IOMMU: dmar1 Register Base Address: fed90000
+
+ Name Offset Contents
+ VER 0x00 0x0000000000000010
+ GCMD 0x18 0x0000000000000000
+ GSTS 0x1c 0x00000000c7000000
+ FSTS 0x34 0x0000000000000000
+ FECTL 0x38 0x0000000000000000
+
+ [...]
+
+ IOMMU: dmar2 Register Base Address: fed91000
+
+ Name Offset Contents
+ VER 0x00 0x0000000000000010
+ GCMD 0x18 0x0000000000000000
+ GSTS 0x1c 0x00000000c7000000
+ FSTS 0x34 0x0000000000000000
+ FECTL 0x38 0x0000000000000000
+
+ [...]
+
+What: /sys/kernel/debug/iommu/intel/ir_translation_struct
+Date: December 2023
+Contact: Jingqi Liu <Jingqi.liu@intel.com>
+Description:
+ This file dumps the table entries for Interrupt
+ remapping and Interrupt posting.
+
+ Example in Kabylake:
+
+ ::
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/ir_translation_struct
+
+ Remapped Interrupt supported on IOMMU: dmar0
+ IR table address:100900000
+
+ Entry SrcID DstID Vct IRTE_high IRTE_low
+ 0 00:0a.0 00000080 24 0000000000040050 000000800024000d
+ 1 00:0a.0 00000001 ef 0000000000040050 0000000100ef000d
+
+ Remapped Interrupt supported on IOMMU: dmar1
+ IR table address:100300000
+ Entry SrcID DstID Vct IRTE_high IRTE_low
+ 0 00:02.0 00000002 26 0000000000040010 000000020026000d
+
+ [...]
+
+ ****
+
+ Posted Interrupt supported on IOMMU: dmar0
+ IR table address:100900000
+ Entry SrcID PDA_high PDA_low Vct IRTE_high IRTE_low
+
+What: /sys/kernel/debug/iommu/intel/dmar_translation_struct
+Date: December 2023
+Contact: Jingqi Liu <Jingqi.liu@intel.com>
+Description:
+ This file dumps Intel IOMMU DMA remapping tables, such
+ as root table, context table, PASID directory and PASID
+ table entries in debugfs. For legacy mode, it doesn't
+ support PASID, and hence PASID field is defaulted to
+ '-1' and other PASID related fields are invalid.
+
+ Example in Kabylake:
+
+ ::
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/dmar_translation_struct
+
+ IOMMU dmar1: Root Table Address: 0x103027000
+ B.D.F Root_entry
+ 00:02.0 0x0000000000000000:0x000000010303e001
+
+ Context_entry
+ 0x0000000000000102:0x000000010303f005
+
+ PASID PASID_table_entry
+ -1 0x0000000000000000:0x0000000000000000:0x0000000000000000
+
+ IOMMU dmar0: Root Table Address: 0x103028000
+ B.D.F Root_entry
+ 00:0a.0 0x0000000000000000:0x00000001038a7001
+
+ Context_entry
+ 0x0000000000000000:0x0000000103220e7d
+
+ PASID PASID_table_entry
+ 0 0x0000000000000000:0x0000000000800002:0x00000001038a5089
+
+ [...]
+
+What: /sys/kernel/debug/iommu/intel/invalidation_queue
+Date: December 2023
+Contact: Jingqi Liu <Jingqi.liu@intel.com>
+Description:
+ This file exports invalidation queue internals of each
+ IOMMU device.
+
+ Example in Kabylake:
+
+ ::
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/invalidation_queue
+
+ Invalidation queue on IOMMU: dmar0
+ Base: 0x10022e000 Head: 20 Tail: 20
+ Index qw0 qw1 qw2
+ 0 0000000000000014 0000000000000000 0000000000000000
+ 1 0000000200000025 0000000100059c04 0000000000000000
+ 2 0000000000000014 0000000000000000 0000000000000000
+
+ qw3 status
+ 0000000000000000 0000000000000000
+ 0000000000000000 0000000000000000
+ 0000000000000000 0000000000000000
+
+ [...]
+
+ Invalidation queue on IOMMU: dmar1
+ Base: 0x10026e000 Head: 32 Tail: 32
+ Index qw0 qw1 status
+ 0 0000000000000004 0000000000000000 0000000000000000
+ 1 0000000200000025 0000000100059804 0000000000000000
+ 2 0000000000000011 0000000000000000 0000000000000000
+
+ [...]
+
+What: /sys/kernel/debug/iommu/intel/dmar_perf_latency
+Date: December 2023
+Contact: Jingqi Liu <Jingqi.liu@intel.com>
+Description:
+ This file is used to control and show counts of
+ execution time ranges for various types per DMAR.
+
+ Firstly, write a value to
+ /sys/kernel/debug/iommu/intel/dmar_perf_latency
+ to enable sampling.
+
+ The possible values are as follows:
+
+ * 0 - disable sampling all latency data
+
+ * 1 - enable sampling IOTLB invalidation latency data
+
+ * 2 - enable sampling devTLB invalidation latency data
+
+ * 3 - enable sampling intr entry cache invalidation latency data
+
+ Next, read /sys/kernel/debug/iommu/intel/dmar_perf_latency gives
+ a snapshot of sampling result of all enabled monitors.
+
+ Examples in Kabylake:
+
+ ::
+
+ 1) Disable sampling all latency data:
+
+ $ sudo echo 0 > /sys/kernel/debug/iommu/intel/dmar_perf_latency
+
+ 2) Enable sampling IOTLB invalidation latency data
+
+ $ sudo echo 1 > /sys/kernel/debug/iommu/intel/dmar_perf_latency
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/dmar_perf_latency
+
+ IOMMU: dmar0 Register Base Address: 26be37000
+ <0.1us 0.1us-1us 1us-10us 10us-100us 100us-1ms
+ inv_iotlb 0 0 0 0 0
+
+ 1ms-10ms >=10ms min(us) max(us) average(us)
+ inv_iotlb 0 0 0 0 0
+
+ [...]
+
+ IOMMU: dmar2 Register Base Address: fed91000
+ <0.1us 0.1us-1us 1us-10us 10us-100us 100us-1ms
+ inv_iotlb 0 0 18 0 0
+
+ 1ms-10ms >=10ms min(us) max(us) average(us)
+ inv_iotlb 0 0 2 2 2
+
+ 3) Enable sampling devTLB invalidation latency data
+
+ $ sudo echo 2 > /sys/kernel/debug/iommu/intel/dmar_perf_latency
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/dmar_perf_latency
+
+ IOMMU: dmar0 Register Base Address: 26be37000
+ <0.1us 0.1us-1us 1us-10us 10us-100us 100us-1ms
+ inv_devtlb 0 0 0 0 0
+
+ >=10ms min(us) max(us) average(us)
+ inv_devtlb 0 0 0 0
+
+ [...]
+
+What: /sys/kernel/debug/iommu/intel/<bdf>/domain_translation_struct
+Date: December 2023
+Contact: Jingqi Liu <Jingqi.liu@intel.com>
+Description:
+ This file dumps a specified page table of Intel IOMMU
+ in legacy mode or scalable mode.
+
+ For a device that only supports legacy mode, dump its
+ page table by the debugfs file in the debugfs device
+ directory. e.g.
+ /sys/kernel/debug/iommu/intel/0000:00:02.0/domain_translation_struct.
+
+ For a device that supports scalable mode, dump the
+ page table of specified pasid by the debugfs file in
+ the debugfs pasid directory. e.g.
+ /sys/kernel/debug/iommu/intel/0000:00:02.0/1/domain_translation_struct.
+
+ Examples in Kabylake:
+
+ ::
+
+ 1) Dump the page table of device "0000:00:02.0" that only supports legacy mode.
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/0000:00:02.0/domain_translation_struct
+
+ Device 0000:00:02.0 @0x1017f8000
+ IOVA_PFN PML5E PML4E
+ 0x000000008d800 | 0x0000000000000000 0x00000001017f9003
+ 0x000000008d801 | 0x0000000000000000 0x00000001017f9003
+ 0x000000008d802 | 0x0000000000000000 0x00000001017f9003
+
+ PDPE PDE PTE
+ 0x00000001017fa003 0x00000001017fb003 0x000000008d800003
+ 0x00000001017fa003 0x00000001017fb003 0x000000008d801003
+ 0x00000001017fa003 0x00000001017fb003 0x000000008d802003
+
+ [...]
+
+ 2) Dump the page table of device "0000:00:0a.0" with PASID "1" that
+ supports scalable mode.
+
+ $ sudo cat /sys/kernel/debug/iommu/intel/0000:00:0a.0/1/domain_translation_struct
+
+ Device 0000:00:0a.0 with pasid 1 @0x10c112000
+ IOVA_PFN PML5E PML4E
+ 0x0000000000000 | 0x0000000000000000 0x000000010df93003
+ 0x0000000000001 | 0x0000000000000000 0x000000010df93003
+ 0x0000000000002 | 0x0000000000000000 0x000000010df93003
+
+ PDPE PDE PTE
+ 0x0000000106ae6003 0x0000000104b38003 0x0000000147c00803
+ 0x0000000106ae6003 0x0000000104b38003 0x0000000147c01803
+ 0x0000000106ae6003 0x0000000104b38003 0x0000000147c02803
+
+ [...]
diff --git a/Documentation/ABI/testing/debugfs-msi-wmi-platform b/Documentation/ABI/testing/debugfs-msi-wmi-platform
new file mode 100644
index 000000000000..71f9992168d8
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-msi-wmi-platform
@@ -0,0 +1,14 @@
+What: /sys/kernel/debug/msi-wmi-platform-<wmi_device_name>/*
+Date: April 2024
+KernelVersion: 6.10
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ This file allows to execute the associated WMI method with the same name.
+
+ To start the execution, write a buffer containing the method arguments
+ at file offset 0. Partial writes or writes at a different offset are not
+ supported.
+
+ The buffer returned by the WMI method can then be read from the file.
+
+ See Documentation/wmi/devices/msi-wmi-platform.rst for details.
diff --git a/Documentation/ABI/testing/debugfs-pcie-ptm b/Documentation/ABI/testing/debugfs-pcie-ptm
new file mode 100644
index 000000000000..602d41363571
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-pcie-ptm
@@ -0,0 +1,70 @@
+What: /sys/kernel/debug/pcie_ptm_*/local_clock
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RO) PTM local clock in nanoseconds. Applicable for both Root
+ Complex and Endpoint controllers.
+
+What: /sys/kernel/debug/pcie_ptm_*/master_clock
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RO) PTM master clock in nanoseconds. Applicable only for
+ Endpoint controllers.
+
+What: /sys/kernel/debug/pcie_ptm_*/t1
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RO) PTM T1 timestamp in nanoseconds. Applicable only for
+ Endpoint controllers.
+
+What: /sys/kernel/debug/pcie_ptm_*/t2
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RO) PTM T2 timestamp in nanoseconds. Applicable only for
+ Root Complex controllers.
+
+What: /sys/kernel/debug/pcie_ptm_*/t3
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RO) PTM T3 timestamp in nanoseconds. Applicable only for
+ Root Complex controllers.
+
+What: /sys/kernel/debug/pcie_ptm_*/t4
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RO) PTM T4 timestamp in nanoseconds. Applicable only for
+ Endpoint controllers.
+
+What: /sys/kernel/debug/pcie_ptm_*/context_update
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RW) Control the PTM context update mode. Applicable only for
+ Endpoint controllers.
+
+ Following values are supported:
+
+ * auto = PTM context auto update trigger for every 10ms
+
+ * manual = PTM context manual update. Writing 'manual' to this
+ file triggers PTM context update (default)
+
+What: /sys/kernel/debug/pcie_ptm_*/context_valid
+Date: May 2025
+Contact: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Description:
+ (RW) Control the PTM context validity (local clock timing).
+ Applicable only for Root Complex controllers. PTM context is
+ invalidated by hardware if the Root Complex enters low power
+ mode or changes link frequency.
+
+ Following values are supported:
+
+ * 0 = PTM context invalid (default)
+
+ * 1 = PTM context valid
diff --git a/Documentation/ABI/testing/debugfs-pktcdvd b/Documentation/ABI/testing/debugfs-pktcdvd
deleted file mode 100644
index f6f65a4faea0..000000000000
--- a/Documentation/ABI/testing/debugfs-pktcdvd
+++ /dev/null
@@ -1,18 +0,0 @@
-What: /sys/kernel/debug/pktcdvd/pktcdvd[0-7]
-Date: Oct. 2006
-KernelVersion: 2.6.20
-Contact: Thomas Maier <balagi@justmail.de>
-Description:
-
-The pktcdvd module (packet writing driver) creates
-these files in debugfs:
-
-/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/
-
- ==== ====== ====================================
- info 0444 Lots of driver statistics and infos.
- ==== ====== ====================================
-
-Example::
-
- cat /sys/kernel/debug/pktcdvd/pktcdvd0/info
diff --git a/Documentation/ABI/testing/debugfs-scmi b/Documentation/ABI/testing/debugfs-scmi
new file mode 100644
index 000000000000..ee7179ab2edf
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-scmi
@@ -0,0 +1,70 @@
+What: /sys/kernel/debug/scmi/<n>/instance_name
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: The name of the underlying SCMI instance <n> described by
+ all the debugfs accessors rooted at /sys/kernel/debug/scmi/<n>,
+ expressed as the full name of the top DT SCMI node under which
+ this SCMI instance is rooted.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/atomic_threshold_us
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: An optional time value, expressed in microseconds, representing,
+ on this SCMI instance <n>, the threshold above which any SCMI
+ command, advertised to have an higher-than-threshold execution
+ latency, should not be considered for atomic mode of operation,
+ even if requested.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/type
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: A string representing the type of transport configured for this
+ SCMI instance <n>.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/is_atomic
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: A boolean stating if the transport configured on the underlying
+ SCMI instance <n> is capable of atomic mode of operation.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/max_rx_timeout_ms
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Timeout in milliseconds allowed for SCMI synchronous replies
+ for the currently configured SCMI transport for instance <n>.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/max_msg_size
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Max message size of allowed SCMI messages for the currently
+ configured SCMI transport for instance <n>.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/tx_max_msg
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Max number of concurrently allowed in-flight SCMI messages for
+ the currently configured SCMI transport for instance <n> on the
+ TX channels.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/transport/rx_max_msg
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: Max number of concurrently allowed in-flight SCMI messages for
+ the currently configured SCMI transport for instance <n> on the
+ RX channels.
+Users: Debugging, any userspace test suite
diff --git a/Documentation/ABI/testing/debugfs-scmi-raw b/Documentation/ABI/testing/debugfs-scmi-raw
new file mode 100644
index 000000000000..5847b96b3896
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-scmi-raw
@@ -0,0 +1,208 @@
+What: /sys/kernel/debug/scmi/<n>/raw/message
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw synchronous message injection/snooping facility; write
+ a complete SCMI synchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n>.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/message_async
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility; write
+ a complete SCMI asynchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n>.
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/message_poll
+Date: June 2025
+KernelVersion: 6.16
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw message injection/snooping facility using polling mode;
+ write a complete SCMI command message (header included) in
+ little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n>, using polling mode on
+ the reception path. (if transport is polling capable)
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/message_poll_async
+Date: June 2025
+KernelVersion: 6.16
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility using
+ polling-mode; write a complete SCMI asynchronous command message
+ (header included) in little-endian binary format to have it sent
+ to the configured backend SCMI server for instance <n>, using
+ polling-mode on the reception path of the immediate part of the
+ asynchronous command. (if transport is polling capable)
+ Any subsequently received response can be read from this same
+ entry if it arrived within the configured timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/errors
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw message errors facility; any kind of timed-out or
+ generally unexpectedly received SCMI message, for instance <n>,
+ can be read from this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/notification
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw notification snooping facility; any notification
+ emitted by the backend SCMI server, for instance <n>, can be
+ read from this entry.
+ Each read gives back one message at time (receiving an EOF at
+ each message boundary).
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/reset
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw stack reset facility; writing a value to this entry
+ causes the internal queues of any kind of received message,
+ still pending to be read out for instance <n>, to be immediately
+ flushed.
+ Can be used to reset and clean the SCMI Raw stack between to
+ different test-run.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw synchronous message injection/snooping facility; write
+ a complete SCMI synchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n> through the <m> transport
+ channel.
+ Any subsequently received response can be read from this same
+ entry if it arrived on channel <m> within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+ Channel identifier <m> matches the SCMI protocol number which
+ has been associated with this transport channel in the DT
+ description, with base protocol number 0x10 being the default
+ channel for this instance.
+ Note that these per-channel entries rooted at <..>/channels
+ exist only if the transport is configured to have more than
+ one default channel.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_async
+Date: March 2023
+KernelVersion: 6.3
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility; write
+ a complete SCMI asynchronous command message (header included)
+ in little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n> through the <m> transport
+ channel.
+ Any subsequently received response can be read from this same
+ entry if it arrived on channel <m> within the configured
+ timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+ Channel identifier <m> matches the SCMI protocol number which
+ has been associated with this transport channel in the DT
+ description, with base protocol number 0x10 being the default
+ channel for this instance.
+ Note that these per-channel entries rooted at <..>/channels
+ exist only if the transport is configured to have more than
+ one default channel.
+Users: Debugging, any userspace test suite
+
+
+What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_poll
+Date: June 2025
+KernelVersion: 6.16
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw message injection/snooping facility using polling mode;
+ write a complete SCMI command message (header included) in
+ little-endian binary format to have it sent to the configured
+ backend SCMI server for instance <n> through the <m> transport
+ channel, using polling mode on the reception path.
+ (if transport is polling capable)
+ Any subsequently received response can be read from this same
+ entry if it arrived on channel <m> within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+ Channel identifier <m> matches the SCMI protocol number which
+ has been associated with this transport channel in the DT
+ description, with base protocol number 0x10 being the default
+ channel for this instance.
+ Note that these per-channel entries rooted at <..>/channels
+ exist only if the transport is configured to have more than
+ one default channel.
+Users: Debugging, any userspace test suite
+
+What: /sys/kernel/debug/scmi/<n>/raw/channels/<m>/message_poll_async
+Date: June 2025
+KernelVersion: 6.16
+Contact: cristian.marussi@arm.com
+Description: SCMI Raw asynchronous message injection/snooping facility using
+ polling-mode; write a complete SCMI asynchronous command message
+ (header included) in little-endian binary format to have it sent
+ to the configured backend SCMI server for instance <n> through
+ the <m> transport channel, using polling mode on the reception
+ path of the immediate part of the asynchronous command.
+ (if transport is polling capable)
+ Any subsequently received response can be read from this same
+ entry if it arrived on channel <m> within the configured
+ timeout.
+ Any additional delayed response received afterwards can be read
+ from this same entry too if it arrived within the configured
+ timeout.
+ Each write to the entry causes one command request to be built
+ and sent while the replies are read back one message at time
+ (receiving an EOF at each message boundary).
+ Channel identifier <m> matches the SCMI protocol number which
+ has been associated with this transport channel in the DT
+ description, with base protocol number 0x10 being the default
+ channel for this instance.
+ Note that these per-channel entries rooted at <..>/channels
+ exist only if the transport is configured to have more than
+ one default channel.
+Users: Debugging, any userspace test suite
diff --git a/Documentation/ABI/testing/debugfs-tpmi b/Documentation/ABI/testing/debugfs-tpmi
new file mode 100644
index 000000000000..c493a1403d2f
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-tpmi
@@ -0,0 +1,40 @@
+What: /sys/kernel/debug/tpmi-<n>/pfs_dump
+Date: November 2023
+KernelVersion: 6.6
+Contact: srinivas.pandruvada@linux.intel.com
+Description:
+The PFS (PM Feature Structure) table, shows details of each power
+management feature. This includes:
+tpmi_id, number of entries, entry size, offset, vsec offset, lock status
+and disabled status.
+Users: Debugging, any user space test suite
+
+What: /sys/kernel/debug/tpmi-<n>/tpmi-id-<n>/mem_dump
+Date: November 2023
+KernelVersion: 6.6
+Contact: srinivas.pandruvada@linux.intel.com
+Description:
+Shows the memory dump of the MMIO region for a TPMI ID.
+Users: Debugging, any user space test suite
+
+What: /sys/kernel/debug/tpmi-<n>/tpmi-id-<n>/mem_write
+Date: November 2023
+KernelVersion: 6.6
+Contact: srinivas.pandruvada@linux.intel.com
+Description:
+Allows to write at any offset. It doesn't check for Read/Write access
+as hardware will not allow to write at read-only memory. This write is
+at offset multiples of 4. The format is instance,offset,contents.
+Example:
+echo 0,0x20,0xff > mem_write
+echo 1,64,64 > mem_write
+Users: Debugging, any user space test suite
+
+What: /sys/kernel/debug/tpmi-<n>/plr/domain<n>/status
+Date: Aug 2024
+KernelVersion: 6.11
+Contact: Tero Kristo <tero.kristo@linux.intel.com>
+Description:
+Shows the currently active Performance Limit Reasons for die level and the
+individual CPUs under the die. The contents of this file are sticky, and
+clearing all the statuses can be done by writing "0\n" to this file.
diff --git a/Documentation/ABI/testing/debugfs-turris-mox-rwtm b/Documentation/ABI/testing/debugfs-turris-mox-rwtm
deleted file mode 100644
index 813987d5de4e..000000000000
--- a/Documentation/ABI/testing/debugfs-turris-mox-rwtm
+++ /dev/null
@@ -1,14 +0,0 @@
-What: /sys/kernel/debug/turris-mox-rwtm/do_sign
-Date: Jun 2020
-KernelVersion: 5.8
-Contact: Marek Behún <kabel@kernel.org>
-Description:
-
- ======= ===========================================================
- (Write) Message to sign with the ECDSA private key stored in
- device's OTP. The message must be exactly 64 bytes
- (since this is intended for SHA-512 hashes).
- (Read) The resulting signature, 136 bytes. This contains the
- R and S values of the ECDSA signature, both in
- big-endian format.
- ======= ===========================================================
diff --git a/Documentation/ABI/testing/debugfs-vfio b/Documentation/ABI/testing/debugfs-vfio
new file mode 100644
index 000000000000..70ec2d454686
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-vfio
@@ -0,0 +1,31 @@
+What: /sys/kernel/debug/vfio
+Date: December 2023
+KernelVersion: 6.8
+Contact: Longfang Liu <liulongfang@huawei.com>
+Description: This debugfs file directory is used for debugging
+ of vfio devices, it's a common directory for all vfio devices.
+ Vfio core will create a device subdirectory under this
+ directory.
+
+What: /sys/kernel/debug/vfio/<device>/migration
+Date: December 2023
+KernelVersion: 6.8
+Contact: Longfang Liu <liulongfang@huawei.com>
+Description: This debugfs file directory is used for debugging
+ of vfio devices that support live migration.
+ The debugfs of each vfio device that supports live migration
+ could be created under this directory.
+
+What: /sys/kernel/debug/vfio/<device>/migration/state
+Date: December 2023
+KernelVersion: 6.8
+Contact: Longfang Liu <liulongfang@huawei.com>
+Description: Read the live migration status of the vfio device.
+ The contents of the state file reflects the migration state
+ relative to those defined in the vfio_device_mig_state enum
+
+What: /sys/kernel/debug/vfio/<device>/migration/features
+Date: Oct 2025
+KernelVersion: 6.18
+Contact: Cédric Le Goater <clg@redhat.com>
+Description: Read the migration features of the vfio device.
diff --git a/Documentation/ABI/testing/gpio-cdev b/Documentation/ABI/testing/gpio-cdev
index 66bdcd188b6c..c9689b2a6fed 100644
--- a/Documentation/ABI/testing/gpio-cdev
+++ b/Documentation/ABI/testing/gpio-cdev
@@ -6,8 +6,9 @@ Description:
The character device files /dev/gpiochip* are the interface
between GPIO chips and userspace.
- The ioctl(2)-based ABI is defined and documented in
- [include/uapi]<linux/gpio.h>.
+ The ioctl(2)-based ABI is defined in
+ [include/uapi]<linux/gpio.h> and documented in
+ Documentation/userspace-api/gpio/chardev.rst.
The following file operations are supported:
@@ -17,8 +18,8 @@ Description:
ioctl(2)
Initiate various actions.
- See the inline documentation in [include/uapi]<linux/gpio.h>
- for descriptions of all ioctls.
+ See Documentation/userspace-api/gpio/chardev.rst
+ for a description of all ioctls.
close(2)
Stops and free up the I/O contexts that was associated
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index db17fc8a0c9f..d4b3696a9efb 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -20,9 +20,10 @@ Description:
rule format: action [condition ...]
action: measure | dont_measure | appraise | dont_appraise |
- audit | hash | dont_hash
+ audit | dont_audit | hash | dont_hash
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [fsname=]
+ [fs_subtype=]
[uid=] [euid=] [gid=] [egid=]
[fowner=] [fgroup=]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
@@ -35,7 +36,7 @@ Description:
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
- [SETXATTR_CHECK]
+ [SETXATTR_CHECK][MMAP_CHECK_REQPROT]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
[[^]MAY_EXEC]
fsmagic:= hex value
@@ -57,9 +58,9 @@ Description:
stored in security.ima xattr. Requires
specifying "digest_type=verity" first.)
- appraise_flag:= [check_blacklist]
- Currently, blacklist check is only for files signed with appended
- signature.
+ appraise_flag:= [check_blacklist] (deprecated)
+ Setting the check_blacklist flag is no longer necessary.
+ All appraisal functions set it by default.
digest_type:= verity
Require fs-verity's file digest instead of the
regular IMA file hash.
diff --git a/Documentation/ABI/testing/procfs-diskstats b/Documentation/ABI/testing/procfs-diskstats
index e58d641443d3..6a719cf2075c 100644
--- a/Documentation/ABI/testing/procfs-diskstats
+++ b/Documentation/ABI/testing/procfs-diskstats
@@ -8,7 +8,7 @@ Description:
== ===================================
1 major number
- 2 minor mumber
+ 2 minor number
3 device name
4 reads completed successfully
5 reads merged
diff --git a/Documentation/ABI/testing/sysfs-auxdisplay-linedisp b/Documentation/ABI/testing/sysfs-auxdisplay-linedisp
new file mode 100644
index 000000000000..55f1b559e84e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-auxdisplay-linedisp
@@ -0,0 +1,90 @@
+What: /sys/.../message
+Date: October 2021
+KernelVersion: 5.16
+Description:
+ Controls the text message displayed on character line displays.
+
+ Reading returns the current message with a trailing newline.
+ Writing updates the displayed message. Messages longer than the
+ display width will automatically scroll. Trailing newlines in
+ input are automatically trimmed.
+
+ Writing an empty string clears the display.
+
+ Example:
+ echo "Hello World" > message
+ cat message # Returns "Hello World\n"
+
+What: /sys/.../num_chars
+Date: November 2025
+KernelVersion: 6.18
+Contact: Jean-François Lessard <jefflessard3@gmail.com>
+Description:
+ Read-only attribute showing the character width capacity of
+ the line display device. Messages longer than this will scroll.
+
+ Example:
+ cat num_chars # Returns "16\n" for 16-char display
+
+What: /sys/.../scroll_step_ms
+Date: October 2021
+KernelVersion: 5.16
+Description:
+ Controls the scrolling speed for messages longer than the display
+ width, specified in milliseconds per scroll step.
+
+ Setting to 0 disables scrolling. Default is 500ms.
+
+ Example:
+ echo "250" > scroll_step_ms # 4Hz scrolling
+ cat scroll_step_ms # Returns "250\n"
+
+What: /sys/.../map_seg7
+Date: January 2024
+KernelVersion: 6.9
+Description:
+ Read/write binary blob representing the ASCII-to-7-segment
+ display conversion table used by the linedisp driver, as defined
+ by struct seg7_conversion_map in <linux/map_to_7segment.h>.
+
+ Only visible on displays with 7-segment capability.
+
+ This attribute is not human-readable. Writes must match the
+ struct size exactly, else -EINVAL is returned; reads return the
+ entire mapping as a binary blob.
+
+ This interface and its implementation match existing conventions
+ used in segment-mapped display drivers since 2005.
+
+ ABI note: This style of binary sysfs attribute *is an exception*
+ to current "one value per file, text only" sysfs rules, for
+ historical compatibility and driver uniformity. New drivers are
+ discouraged from introducing additional binary sysfs ABIs.
+
+ Reference interface guidance:
+ - include/uapi/linux/map_to_7segment.h
+
+What: /sys/.../map_seg14
+Date: January 2024
+KernelVersion: 6.9
+Description:
+ Read/write binary blob representing the ASCII-to-14-segment
+ display conversion table used by the linedisp driver, as defined
+ by struct seg14_conversion_map in <linux/map_to_14segment.h>.
+
+ Only visible on displays with 14-segment capability.
+
+ This attribute is not human-readable. Writes must match the
+ struct size exactly, else -EINVAL is returned; reads return the
+ entire mapping as a binary blob.
+
+ This interface and its implementation match existing conventions
+ used by segment-mapped display drivers since 2005.
+
+ ABI note: This style of binary sysfs attribute *is an exception*
+ to current "one value per file, text only" sysfs rules, for
+ historical compatibility and driver uniformity. New drivers are
+ discouraged from introducing additional binary sysfs ABIs.
+
+ Reference interface guidance:
+ - include/uapi/linux/map_to_14segment.h
diff --git a/Documentation/ABI/testing/sysfs-block-bcache b/Documentation/ABI/testing/sysfs-block-bcache
index 9e4bbc5d51fd..9344a657ca70 100644
--- a/Documentation/ABI/testing/sysfs-block-bcache
+++ b/Documentation/ABI/testing/sysfs-block-bcache
@@ -106,13 +106,6 @@ Description:
will be discarded from the cache. Should not be turned off with
writeback caching enabled.
-What: /sys/block/<disk>/bcache/discard
-Date: November 2010
-Contact: Kent Overstreet <kent.overstreet@gmail.com>
-Description:
- For a cache, a boolean allowing discard/TRIM to be turned off
- or back on if the device supports it.
-
What: /sys/block/<disk>/bcache/bucket_size
Date: November 2010
Contact: Kent Overstreet <kent.overstreet@gmail.com>
diff --git a/Documentation/ABI/testing/sysfs-block-device b/Documentation/ABI/testing/sysfs-block-device
index 7ac7b19b2f72..2d543cfa4079 100644
--- a/Documentation/ABI/testing/sysfs-block-device
+++ b/Documentation/ABI/testing/sysfs-block-device
@@ -95,3 +95,25 @@ Description:
This file does not exist if the HBA driver does not implement
support for the SATA NCQ priority feature, regardless of the
device support for this feature.
+
+
+What: /sys/block/*/device/cdl_supported
+Date: May, 2023
+KernelVersion: v6.5
+Contact: linux-scsi@vger.kernel.org
+Description:
+ (RO) Indicates if the device supports the command duration
+ limits feature found in some ATA and SCSI devices.
+
+
+What: /sys/block/*/device/cdl_enable
+Date: May, 2023
+KernelVersion: v6.5
+Contact: linux-scsi@vger.kernel.org
+Description:
+ (RW) For a device supporting the command duration limits
+ feature, write to the file to turn on or off the feature.
+ By default this feature is turned off.
+ Writing "1" to this file enables the use of command duration
+ limits for read and write commands in the kernel and turns on
+ the feature on the device. Writing "0" disables the feature.
diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram
index 14b2bf2e5105..36c57de0a10a 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -22,14 +22,6 @@ Description:
device. The reset operation frees all the memory associated
with this device.
-What: /sys/block/zram<id>/max_comp_streams
-Date: February 2014
-Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Description:
- The max_comp_streams file is read-write and specifies the
- number of backend's zcomp_strm compression streams (number of
- concurrent compress operations).
-
What: /sys/block/zram<id>/comp_algorithm
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
@@ -137,3 +129,24 @@ Description:
The writeback_limit file is read-write and specifies the maximum
amount of writeback ZRAM can do. The limit could be changed
in run time.
+
+What: /sys/block/zram<id>/recomp_algorithm
+Date: November 2022
+Contact: Sergey Senozhatsky <senozhatsky@chromium.org>
+Description:
+ The recomp_algorithm file is read-write and allows to set
+ or show secondary compression algorithms.
+
+What: /sys/block/zram<id>/recompress
+Date: November 2022
+Contact: Sergey Senozhatsky <senozhatsky@chromium.org>
+Description:
+ The recompress file is write-only and triggers re-compression
+ with secondary compression algorithms.
+
+What: /sys/block/zram<id>/algorithm_params
+Date: August 2024
+Contact: Sergey Senozhatsky <senozhatsky@chromium.org>
+Description:
+ The algorithm_params file is write-only and is used to setup
+ compression algorithm parameters.
diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi
index 58abacf59b2a..6f2b907a8013 100644
--- a/Documentation/ABI/testing/sysfs-bus-acpi
+++ b/Documentation/ABI/testing/sysfs-bus-acpi
@@ -1,6 +1,6 @@
What: /sys/bus/acpi/devices/.../path
Date: December 2006
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
This attribute indicates the full path of ACPI namespace
object associated with the device object. For example,
@@ -12,7 +12,7 @@ Description:
What: /sys/bus/acpi/devices/.../modalias
Date: July 2007
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
This attribute indicates the PNP IDs of the device object.
That is acpi:HHHHHHHH:[CCCCCCC:]. Where each HHHHHHHH or
@@ -20,7 +20,7 @@ Description:
What: /sys/bus/acpi/devices/.../hid
Date: April 2005
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
This attribute indicates the hardware ID (_HID) of the
device object. For example, PNP0103.
@@ -29,14 +29,14 @@ Description:
What: /sys/bus/acpi/devices/.../description
Date: October 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
This attribute contains the output of the device object's
_STR control method, if present.
What: /sys/bus/acpi/devices/.../adr
Date: October 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
This attribute contains the output of the device object's
_ADR control method, which is present for ACPI device
@@ -45,14 +45,14 @@ Description:
What: /sys/bus/acpi/devices/.../uid
Date: October 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
This attribute contains the output of the device object's
_UID control method, if present.
What: /sys/bus/acpi/devices/.../eject
Date: December 2006
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
Writing 1 to this attribute will trigger hot removal of
this device object. This file exists for every device
@@ -60,7 +60,7 @@ Description:
What: /sys/bus/acpi/devices/.../status
Date: Jan, 2014
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
(RO) Returns the ACPI device status: enabled, disabled or
functioning or present, if the method _STA is present.
@@ -90,7 +90,7 @@ Description:
What: /sys/bus/acpi/devices/.../hrv
Date: Apr, 2016
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
(RO) Allows users to read the hardware version of non-PCI
hardware, if the _HRV control method is present. It is mostly
diff --git a/Documentation/ABI/testing/sysfs-bus-auxiliary b/Documentation/ABI/testing/sysfs-bus-auxiliary
new file mode 100644
index 000000000000..cc856079690f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-auxiliary
@@ -0,0 +1,9 @@
+What: /sys/bus/auxiliary/devices/.../irqs/
+Date: April, 2024
+Contact: Shay Drory <shayd@nvidia.com>
+Description:
+ The /sys/devices/.../irqs directory contains a variable set of
+ files, with each file is named as irq number similar to PCI PF
+ or VF's irq number located in msi_irqs directory.
+ These irq files are added and removed dynamically when an IRQ
+ is requested and freed respectively for the PCI SF.
diff --git a/Documentation/ABI/testing/sysfs-bus-cdx b/Documentation/ABI/testing/sysfs-bus-cdx
new file mode 100644
index 000000000000..e84277531414
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-cdx
@@ -0,0 +1,121 @@
+What: /sys/bus/cdx/rescan
+Date: March 2023
+Contact: nipun.gupta@amd.com
+Description:
+ Writing y/1/on to this file will cause rescan of the bus
+ and devices on the CDX bus. Any new devices are scanned and
+ added to the list of Linux devices and any devices removed are
+ also deleted from Linux.
+
+ For example::
+
+ # echo 1 > /sys/bus/cdx/rescan
+
+What: /sys/bus/cdx/devices/.../vendor
+Date: March 2023
+Contact: nipun.gupta@amd.com
+Description:
+ Vendor ID for this CDX device, in hexadecimal. Vendor ID is
+ 16 bit identifier which is specific to the device manufacturer.
+ Combination of Vendor ID and Device ID identifies a device.
+
+What: /sys/bus/cdx/devices/.../device
+Date: March 2023
+Contact: nipun.gupta@amd.com
+Description:
+ Device ID for this CDX device, in hexadecimal. Device ID is
+ 16 bit identifier to identify a device type within the range
+ of a device manufacturer.
+ Combination of Vendor ID and Device ID identifies a device.
+
+What: /sys/bus/cdx/devices/.../subsystem_vendor
+Date: July 2023
+Contact: puneet.gupta@amd.com
+Description:
+ Subsystem Vendor ID for this CDX device, in hexadecimal.
+ Subsystem Vendor ID is 16 bit identifier specific to the
+ card manufacturer.
+
+What: /sys/bus/cdx/devices/.../subsystem_device
+Date: July 2023
+Contact: puneet.gupta@amd.com
+Description:
+ Subsystem Device ID for this CDX device, in hexadecimal
+ Subsystem Device ID is 16 bit identifier specific to the
+ card manufacturer.
+
+What: /sys/bus/cdx/devices/.../class
+Date: July 2023
+Contact: puneet.gupta@amd.com
+Description:
+ This file contains the class of the CDX device, in hexadecimal.
+ Class is 24 bit identifier specifies the functionality of the device.
+
+What: /sys/bus/cdx/devices/.../revision
+Date: July 2023
+Contact: puneet.gupta@amd.com
+Description:
+ This file contains the revision field of the CDX device, in hexadecimal.
+ Revision is 8 bit revision identifier of the device.
+
+What: /sys/bus/cdx/devices/.../enable
+Date: October 2023
+Contact: abhijit.gangurde@amd.com
+Description:
+ CDX bus should be disabled before updating the devices in FPGA.
+ Writing n/0/off will attempt to disable the CDX bus and.
+ writing y/1/on will attempt to enable the CDX bus. Reading this file
+ gives the current state of the bus, 1 for enabled and 0 for disabled.
+
+ For example::
+
+ # echo 1 > /sys/bus/cdx/.../enable
+
+What: /sys/bus/cdx/devices/.../reset
+Date: March 2023
+Contact: nipun.gupta@amd.com
+Description:
+ Writing y/1/on to this file resets the CDX device or all devices
+ on the bus. On resetting the device, the corresponding driver is
+ notified twice, once before the device is being reset, and again
+ after the reset has been complete.
+
+ For example::
+
+ # echo 1 > /sys/bus/cdx/.../reset
+
+What: /sys/bus/cdx/devices/.../remove
+Date: March 2023
+Contact: tarak.reddy@amd.com
+Description:
+ Writing y/1/on to this file removes the corresponding
+ device from the CDX bus. If the device is to be reconfigured
+ reconfigured in the Hardware, the device can be removed, so
+ that the device driver does not access the device while it is
+ being reconfigured.
+
+ For example::
+
+ # echo 1 > /sys/bus/cdx/devices/.../remove
+
+What: /sys/bus/cdx/devices/.../resource<N>
+Date: July 2023
+Contact: puneet.gupta@amd.com
+Description:
+ The resource binary file contains the content of the memory
+ regions. These files can be m'maped from userspace.
+
+What: /sys/bus/cdx/devices/.../modalias
+Date: July 2023
+Contact: nipun.gupta@amd.com
+Description:
+ This attribute indicates the CDX ID of the device.
+ That is in the format:
+ cdx:vXXXXdXXXXsvXXXXsdXXXXcXXXXXX,
+ where:
+
+ - vXXXX contains the vendor ID;
+ - dXXXX contains the device ID;
+ - svXXXX contains the subsystem vendor ID;
+ - sdXXXX contains the subsystem device ID;
+ - cXXXXXX contains the device class.
diff --git a/Documentation/ABI/testing/sysfs-bus-coreboot b/Documentation/ABI/testing/sysfs-bus-coreboot
new file mode 100644
index 000000000000..8e8d6af24a4c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coreboot
@@ -0,0 +1,45 @@
+What: /sys/bus/coreboot
+Date: August 2022
+Contact: Jack Rosenthal <jrosenth@chromium.org>
+Description:
+ The coreboot bus provides a variety of virtual devices used to
+ access data structures created by the Coreboot BIOS.
+
+What: /sys/bus/coreboot/devices/cbmem-<id>
+Date: August 2022
+Contact: Jack Rosenthal <jrosenth@chromium.org>
+Description:
+ CBMEM is a downwards-growing memory region created by Coreboot,
+ and contains tagged data structures to be shared with payloads
+ in the boot process and the OS. Each CBMEM entry is given a
+ directory in /sys/bus/coreboot/devices based on its id.
+ A list of ids known to Coreboot can be found in the coreboot
+ source tree at
+ ``src/commonlib/bsd/include/commonlib/bsd/cbmem_id.h``.
+
+What: /sys/bus/coreboot/devices/cbmem-<id>/address
+Date: August 2022
+Contact: Jack Rosenthal <jrosenth@chromium.org>
+Description:
+ This is the physical memory address that the CBMEM entry's data
+ begins at, in hexadecimal (e.g., ``0x76ffe000``).
+
+What: /sys/bus/coreboot/devices/cbmem-<id>/size
+Date: August 2022
+Contact: Jack Rosenthal <jrosenth@chromium.org>
+Description:
+ This is the size of the CBMEM entry's data, in hexadecimal
+ (e.g., ``0x1234``).
+
+What: /sys/bus/coreboot/devices/cbmem-<id>/mem
+Date: August 2022
+Contact: Jack Rosenthal <jrosenth@chromium.org>
+Description:
+ A file exposing read/write access to the entry's data. Note
+ that this file does not support mmap(), as coreboot
+ does not guarantee that the data will be page-aligned.
+
+ The mode of this file is 0600. While there shouldn't be
+ anything security-sensitive contained in CBMEM, read access
+ requires root privileges given this is exposing a small subset
+ of physical memory.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti
index bf2869c413e7..a2aef7f5a6d7 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti
@@ -1,241 +1,247 @@
What: /sys/bus/coresight/devices/<cti-name>/enable
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable/Disable the CTI hardware.
What: /sys/bus/coresight/devices/<cti-name>/powered
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Indicate if the CTI hardware is powered.
What: /sys/bus/coresight/devices/<cti-name>/ctmid
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Display the associated CTM ID
What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Number of devices connected to triggers on this CTI
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Name of connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Input trigger signals from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Functional types for the input trigger signals
from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Output trigger signals to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Functional types for the output trigger signals
to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Select the index for inen and outen registers.
What: /sys/bus/coresight/devices/<cti-name>/regs/inen
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIINEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/outen
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIOUTEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/gate
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write CTIGATE register.
What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write ASICCTL register.
What: /sys/bus/coresight/devices/<cti-name>/regs/intack
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Write the INTACK register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appset
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Set CTIAPPSET register to activate channel. Read back to
determine current value of register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appclear
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Write APPCLEAR register to deactivate channel.
What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Write APPPULSE to pulse a channel active for one clock
cycle.
What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Read current status of channel inputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) read current status of channel outputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) read current status of input trigger signals
What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) read current status of output trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Attach a CTI input trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Detach a CTI input trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Attach a CTI output trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Detach a CTI output trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable CTIGATE for single channel (Write) or list enabled
channels through the gate (R).
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Disable CTIGATE for single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Activate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Deactivate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Pulse a single channel - activate for a single clock cycle.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) List of output triggers filtered across all connections.
What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable or disable trigger output signal filtering.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) show channels with at least one attached trigger signal.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) show channels with no attached trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Write channel number to select a channel to view, read to
see selected channel number.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Read to see input triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Read to see output triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset
Date: March 2020
-KernelVersion 5.7
+KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Clear all channel / trigger programming.
+
+What: /sys/bus/coresight/devices/<cti-name>/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source b/Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source
new file mode 100644
index 000000000000..321e3ee1fc9d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source
@@ -0,0 +1,21 @@
+What: /sys/bus/coresight/devices/dummy_source<N>/enable_source
+Date: Dec 2024
+KernelVersion: 6.14
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (RW) Enable/disable tracing of dummy source. A sink should be activated
+ before enabling the source. The path of coresight components linking
+ the source to the sink is configured and managed automatically by the
+ coresight framework.
+
+What: /sys/bus/coresight/devices/dummy_source<N>/traceid
+Date: Dec 2024
+KernelVersion: 6.14
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (R) Show the trace ID that will appear in the trace stream
+ coming from this trace entity.
+
+What: /sys/bus/coresight/devices/dummy_source<N>/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10 b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10
index 9a383f6a74eb..f30526949687 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10
@@ -19,6 +19,12 @@ Description: (RW) Disables write access to the Trace RAM by stopping the
into the Trace RAM following the trigger event is equal to the
value stored in this register+1 (from ARM ETB-TRM).
+What: /sys/bus/coresight/devices/<memory_map>.etb/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
+
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/rdp
Date: March 2016
KernelVersion: 4.7
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
index 651602a61eac..245c322c91f1 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
@@ -22,7 +22,7 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies
characteristics about the address comparator being configure,
for example the access type, the kind of instruction to trace,
- processor contect ID to trigger on, etc. Individual fields in
+ processor context ID to trigger on, etc. Individual fields in
the access type register may vary on the version of the trace
entity.
@@ -31,7 +31,7 @@ Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the range of
- addresses to trigger on. Inclusion or exclusion is specificed
+ addresses to trigger on. Inclusion or exclusion is specified
in the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single
@@ -236,7 +236,7 @@ What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/traceid
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RW) Holds the trace ID that will appear in the trace stream
+Description: (RO) Holds the trace ID that will appear in the trace stream
coming from this trace entity.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/trigger_event
@@ -251,6 +251,12 @@ KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Holds the cpu number this tracer is affined to.
+What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
+
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccr
Date: September 2015
KernelVersion: 4.4
@@ -304,19 +310,19 @@ What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtsscr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RO) Print the content of the ETM Trace Start/Stop Conrol
+Description: (RO) Print the content of the ETM Trace Start/Stop Control
register (0x018). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RO) Print the content of the ETM Enable Conrol #1
+Description: (RO) Print the content of the ETM Enable Control #1
register (0x024). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
-Description: (RO) Print the content of the ETM Enable Conrol #2
+Description: (RO) Print the content of the ETM Enable Control #2
register (0x01c). The value is read directly from the HW.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
index 8e53a32f8150..6f19a6a5f2e1 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
@@ -329,6 +329,12 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Access the selected single show PE comparator control
register.
+What: /sys/bus/coresight/devices/etm<N>/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
+
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcoslsr
Date: April 2015
KernelVersion: 4.01
@@ -446,7 +452,7 @@ Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (Read) Returns the maximum size of the data value, data address,
- VMID, context ID and instuction address in the trace unit
+ VMID, context ID and instruction address in the trace unit
(0x1E8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3
@@ -516,3 +522,11 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (Read) Returns the number of special conditional P1 right-hand keys
that the trace unit can use (0x194). The value is taken
directly from the HW.
+
+What: /sys/bus/coresight/devices/etm<N>/ts_source
+Date: October 2022
+KernelVersion: 6.1
+Contact: Mathieu Poirier <mathieu.poirier@linaro.org> or Suzuki K Poulose <suzuki.poulose@arm.com>
+Description: (Read) When FEAT_TRF is implemented, value of TRFCR_ELx.TS used for
+ trace session. Otherwise -1 indicates an unknown time source. Check
+ trcidr0.tssize to see if a global timestamp is available.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel b/Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel
index d75acda5e1b3..86938e9bbcde 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel
@@ -10,3 +10,9 @@ Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines input port priority order.
+
+What: /sys/bus/coresight/devices/<memory_map>.funnel/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
index 53e1f4815d64..848e2ffc1480 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
@@ -51,3 +51,9 @@ KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Holds the trace ID that will appear in the trace stream
coming from this trace entity.
+
+What: /sys/bus/coresight/devices/<memory_map>.stm/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
index 6aa527296c71..55e298b9c4a4 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
@@ -91,3 +91,25 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Size of the trace buffer for TMC-ETR when used in SYSFS
mode. Writable only for TMC-ETR configurations. The value
should be aligned to the kernel pagesize.
+
+What: /sys/bus/coresight/devices/<memory_map>.tmc/buf_modes_available
+Date: August 2023
+KernelVersion: 6.7
+Contact: Anshuman Khandual <anshuman.khandual@arm.com>
+Description: (Read) Shows all supported Coresight TMC-ETR buffer modes available
+ for the users to configure explicitly. This file is available only
+ for TMC ETR devices.
+
+What: /sys/bus/coresight/devices/<memory_map>.tmc/buf_mode_preferred
+Date: August 2023
+KernelVersion: 6.7
+Contact: Anshuman Khandual <anshuman.khandual@arm.com>
+Description: (RW) Current Coresight TMC-ETR buffer mode selected. But user could
+ only provide a mode which is supported for a given ETR device. This
+ file is available only for TMC ETR devices.
+
+What: /sys/bus/coresight/devices/<memory_map>.tmc/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
new file mode 100644
index 000000000000..98f1c6545027
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
@@ -0,0 +1,280 @@
+What: /sys/bus/coresight/devices/<tpdm-name>/integration_test
+Date: January 2023
+KernelVersion: 6.2
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (Write) Run integration test for tpdm. Integration test
+ will generate test data for tpdm. It can help to make
+ sure that the trace path is enabled and the link configurations
+ are fine.
+
+ Accepts only one of the 2 values - 1 or 2.
+ 1 : Generate 64 bits data
+ 2 : Generate 32 bits data
+
+What: /sys/bus/coresight/devices/<tpdm-name>/reset_dataset
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (Write) Reset the dataset of the tpdm.
+
+ Accepts only one value - 1.
+ 1 : Reset the dataset of the tpdm
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_type
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the trigger type of the DSB for tpdm.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Set the DSB trigger type to false
+ 1 : Set the DSB trigger type to true
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_ts
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the trigger timestamp of the DSB for tpdm.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Set the DSB trigger type to false
+ 1 : Set the DSB trigger type to true
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_mode
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the programming mode of the DSB for tpdm.
+
+ Accepts the value needs to be greater than 0. What data
+ bits do is listed below.
+ Bit[0:1] : Test mode control bit for choosing the inputs.
+ Bit[3] : Set to 0 for low performance mode. Set to 1 for high
+ performance mode.
+ Bit[4:8] : Select byte lane for high performance mode.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_idx
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the index number of the edge detection for the DSB
+ subunit TPDM. Since there are at most 256 edge detections, this
+ value ranges from 0 to 255.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_val
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ Write a data to control the edge detection corresponding to
+ the index number. Before writing data to this sysfs file,
+ "ctrl_idx" should be written first to configure the index
+ number of the edge detection which needs to be controlled.
+
+ Accepts only one of the following values.
+ 0 - Rising edge detection
+ 1 - Falling edge detection
+ 2 - Rising and falling edge detection (toggle detection)
+
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_mask
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ Write a data to mask the edge detection corresponding to the index
+ number. Before writing data to this sysfs file, "ctrl_idx" should
+ be written first to configure the index number of the edge detection
+ which needs to be masked.
+
+ Accepts only one of the 2 values - 0 or 1.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcr[0:15]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ Read a set of the edge control value of the DSB in TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcmr[0:7]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ Read a set of the edge control mask of the DSB in TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpr[0:7]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the value of the trigger pattern for the DSB
+ subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpmr[0:7]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the mask of the trigger pattern for the DSB
+ subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:7]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the value of the pattern for the DSB subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:7]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the mask of the pattern for the DSB subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/enable_ts
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (Write) Set the pattern timestamp of DSB tpdm. Read
+ the pattern timestamp of DSB tpdm.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Disable DSB pattern timestamp.
+ 1 : Enable DSB pattern timestamp.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/set_type
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (Write) Set the pattern type of DSB tpdm. Read
+ the pattern type of DSB tpdm.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Set the DSB pattern type to value.
+ 1 : Set the DSB pattern type to toggle.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_msr/msr[0:31]
+Date: March 2023
+KernelVersion: 6.7
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the MSR(mux select register) for the DSB subunit
+ TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_mode
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description: (Write) Set the data collection mode of CMB tpdm. Continuous
+ change creates CMB data set elements on every CMBCLK edge.
+ Trace-on-change creates CMB data set elements only when a new
+ data set element differs in value from the previous element
+ in a CMB data set.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Continuous CMB collection mode.
+ 1 : Trace-on-change CMB collection mode.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpr[0:1]
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the value of the trigger pattern for the CMB
+ subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpmr[0:1]
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the mask of the trigger pattern for the CMB
+ subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:1]
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the value of the pattern for the CMB subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:1]
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the mask of the pattern for the CMB subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (Write) Set the pattern timestamp of CMB tpdm. Read
+ the pattern timestamp of CMB tpdm.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Disable CMB pattern timestamp.
+ 1 : Enable CMB pattern timestamp.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the trigger timestamp of the CMB for tpdm.
+
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Set the CMB trigger type to false
+ 1 : Set the CMB trigger type to true
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Read or write the status of timestamp upon all interface.
+ Only value 0 and 1 can be written to this node. Set this node to 1 to request
+ timestamp to all trace packet.
+ Accepts only one of the 2 values - 0 or 1.
+ 0 : Disable the timestamp of all trace packets.
+ 1 : Enable the timestamp of all trace packets.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
+Date: January 2024
+KernelVersion: 6.9
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the MSR(mux select register) for the CMB subunit
+ TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/mcmb_trig_lane
+Date: Feb 2025
+KernelVersion 6.15
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get which lane participates in the output pattern
+ match cross trigger mechanism for the MCMB subunit TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/mcmb_lanes_select
+Date: Feb 2025
+KernelVersion 6.15
+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
+Description:
+ (RW) Set/Get the enablement of the individual lane.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe b/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
index ad3bbc6fa751..8a4b749ed26e 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
@@ -12,3 +12,9 @@ Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows if TRBE updates in the memory are with access
and dirty flag updates as well. This value is fetched from
the TRBIDR register.
+
+What: /sys/bus/coresight/devices/trbe<cpu>/label
+Date: Aug 2025
+KernelVersion 6.18
+Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
+Description: (Read) Show hardware context information of device.
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb
new file mode 100644
index 000000000000..f560918ae738
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb
@@ -0,0 +1,31 @@
+What: /sys/bus/coresight/devices/ultra_smb<N>/enable_sink
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RW) Add/remove a SMB device from a trace path. There can be
+ multiple sources for a single SMB device.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/buf_size
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the buffer size of each UltraSoc SMB device.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/buf_status
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the value of UltraSoc SMB status register.
+ BIT(0) is zero means buffer is empty.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/read_pos
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the value of UltraSoc SMB Read Pointer register.
+
+What: /sys/bus/coresight/devices/ultra_smb<N>/mgmt/write_pos
+Date: January 2023
+KernelVersion: 6.3
+Contact: Junhao He <hejunhao3@huawei.com>
+Description: (RO) Shows the value of UltraSoc SMB Write Pointer register.
diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
index 06c2b3e27e0b..3e7eddd8aff3 100644
--- a/Documentation/ABI/testing/sysfs-bus-counter
+++ b/Documentation/ABI/testing/sysfs-bus-counter
@@ -1,9 +1,53 @@
+What: /sys/bus/counter/devices/counterX/cascade_counts_enable
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ Indicates the cascading of Counts on Counter X.
+
+ Valid attribute values are boolean.
+
+What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ Selects the external clock pin for phase counting mode of
+ Counter X.
+
+ MTCLKA-MTCLKB:
+ MTCLKA and MTCLKB pins are selected for the external
+ phase clock.
+
+ MTCLKC-MTCLKD:
+ MTCLKC and MTCLKD pins are selected for the external
+ phase clock.
+
+What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ Discrete set of available values for the respective device
+ configuration are listed in this file.
+
What: /sys/bus/counter/devices/counterX/countY/count
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Count data of Count Y represented as a string.
+What: /sys/bus/counter/devices/counterX/countY/compare
+KernelVersion: 6.15
+Contact: linux-iio@vger.kernel.org
+Description:
+ If the counter device supports compare registers -- registers
+ used to compare counter channels against a particular count --
+ the compare count for channel Y is provided by this attribute.
+
+What: /sys/bus/counter/devices/counterX/countY/capture
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Historical capture of the Count Y count data.
+
What: /sys/bus/counter/devices/counterX/countY/ceiling
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
@@ -54,6 +98,60 @@ Description:
counter does not freeze at the boundary points, but
counts continuously throughout.
+ interrupt on terminal count:
+ The output signal is initially low, and will remain low
+ until the counter reaches zero. The output signal then
+ goes high and remains high until a new preset value is
+ set.
+
+ hardware retriggerable one-shot:
+ The output signal is initially high. The output signal
+ will go low by a trigger input signal, and will remain
+ low until the counter reaches zero. The output will then
+ go high and remain high until the next trigger. A
+ trigger results in loading the counter to the preset
+ value and setting the output signal low, thus starting
+ the one-shot pulse.
+
+ rate generator:
+ The output signal is initially high. When the counter
+ has decremented to 1, the output signal goes low for one
+ clock pulse. The output signal then goes high again, the
+ counter is reloaded to the preset value, and the process
+ repeats in a periodic manner as such.
+
+ square wave mode:
+ The output signal is initially high.
+
+ If the initial count is even, the counter is decremented
+ by two on succeeding clock pulses. When the count
+ expires, the output signal changes value and the
+ counter is reloaded to the preset value. The process
+ repeats in periodic manner as such.
+
+ If the initial count is odd, the initial count minus one
+ (an even number) is loaded and then is decremented by
+ two on succeeding clock pulses. One clock pulse after
+ the count expires, the output signal goes low and the
+ counter is reloaded to the preset value minus one.
+ Succeeding clock pulses decrement the count by two. When
+ the count expires, the output goes high again and the
+ counter is reloaded to the preset value minus one. The
+ process repeats in a periodic manner as such.
+
+ software triggered strobe:
+ The output signal is initially high. When the count
+ expires, the output will go low for one clock pulse and
+ then go high again. The counting sequence is "triggered"
+ by setting the preset value.
+
+ hardware triggered strobe:
+ The output signal is initially high. Counting is started
+ by a trigger input signal. When the count expires, the
+ output signal will go low for one clock pulse and then
+ go high again. A trigger results in loading the counter
+ to the preset value.
+
What: /sys/bus/counter/devices/counterX/countY/count_mode_available
What: /sys/bus/counter/devices/counterX/countY/error_noise_available
What: /sys/bus/counter/devices/counterX/countY/function_available
@@ -203,12 +301,23 @@ Description:
both edges:
Any state transition.
+What: /sys/bus/counter/devices/counterX/countY/num_overflows
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute indicates the number of overflows of count Y.
+
+What: /sys/bus/counter/devices/counterX/cascade_counts_enable_component_id
+What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_component_id
+What: /sys/bus/counter/devices/counterX/countY/capture_component_id
What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id
-What: /sys/bus/counter/devices/counterX/countY/floor_component_id
+What: /sys/bus/counter/devices/counterX/countY/compare_component_id
What: /sys/bus/counter/devices/counterX/countY/count_mode_component_id
What: /sys/bus/counter/devices/counterX/countY/direction_component_id
What: /sys/bus/counter/devices/counterX/countY/enable_component_id
What: /sys/bus/counter/devices/counterX/countY/error_noise_component_id
+What: /sys/bus/counter/devices/counterX/countY/floor_component_id
+What: /sys/bus/counter/devices/counterX/countY/num_overflows_component_id
What: /sys/bus/counter/devices/counterX/countY/prescaler_component_id
What: /sys/bus/counter/devices/counterX/countY/preset_component_id
What: /sys/bus/counter/devices/counterX/countY/preset_enable_component_id
@@ -216,7 +325,9 @@ What: /sys/bus/counter/devices/counterX/countY/signalZ_action_component_id
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_component_id
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable_component_id
What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler_component_id
+What: /sys/bus/counter/devices/counterX/signalY/frequency_component_id
What: /sys/bus/counter/devices/counterX/signalY/index_polarity_component_id
+What: /sys/bus/counter/devices/counterX/signalY/polarity_component_id
What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_component_id
KernelVersion: 5.16
Contact: linux-iio@vger.kernel.org
@@ -303,6 +414,19 @@ Description:
Discrete set of available values for the respective Signal Y
configuration are listed in this file.
+What: /sys/bus/counter/devices/counterX/signalY/polarity
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Active level of Signal Y. The following polarity values are
+ available:
+
+ positive:
+ Signal high state considered active level (rising edge).
+
+ negative:
+ Signal low state considered active level (falling edge).
+
What: /sys/bus/counter/devices/counterX/signalY/name
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
@@ -345,3 +469,9 @@ Description:
via index_polarity. The index function (as enabled via
preset_enable) is performed synchronously with the
quadrature clock on the active level of the index input.
+
+What: /sys/bus/counter/devices/counterX/signalY/frequency
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Read-only attribute that indicates the signal Y frequency, in Hz.
diff --git a/Documentation/ABI/testing/sysfs-bus-css b/Documentation/ABI/testing/sysfs-bus-css
index 12a733fe357f..d4d5cfb63b90 100644
--- a/Documentation/ABI/testing/sysfs-bus-css
+++ b/Documentation/ABI/testing/sysfs-bus-css
@@ -1,22 +1,19 @@
What: /sys/bus/css/devices/.../type
Date: March 2008
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the subchannel type, as reported by the hardware.
This attribute is present for all subchannel types.
What: /sys/bus/css/devices/.../modalias
Date: March 2008
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the module alias as reported with uevents.
It is of the format css:t<type> and present for all
subchannel types.
What: /sys/bus/css/drivers/io_subchannel/.../chpids
Date: December 2002
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the ids of the channel paths used by this
subchannel, as reported by the channel subsystem
during subchannel recognition.
@@ -26,8 +23,7 @@ Users: s390-tools, HAL
What: /sys/bus/css/drivers/io_subchannel/.../pimpampom
Date: December 2002
-Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: Contains the PIM/PAM/POM values, as reported by the
channel subsystem when last queried by the common I/O
layer (this implies that this attribute is not necessarily
@@ -38,8 +34,7 @@ Users: s390-tools, HAL
What: /sys/bus/css/devices/.../driver_override
Date: June 2019
-Contact: Cornelia Huck <cohuck@redhat.com>
- linux-s390@vger.kernel.org
+Contact: linux-s390@vger.kernel.org
Description: This file allows the driver for a device to be specified. When
specified, only a driver with a name matching the value written
to driver_override will have an opportunity to bind to the
diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl
index 8494ef27e8d2..c80a1b5a03db 100644
--- a/Documentation/ABI/testing/sysfs-bus-cxl
+++ b/Documentation/ABI/testing/sysfs-bus-cxl
@@ -1,5 +1,5 @@
What: /sys/bus/cxl/flush
-Date: Januarry, 2022
+Date: January, 2022
KernelVersion: v5.18
Contact: linux-cxl@vger.kernel.org
Description:
@@ -18,6 +18,24 @@ Description:
specification.
+What: /sys/bus/cxl/devices/memX/payload_max
+Date: December, 2020
+KernelVersion: v5.12
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) Maximum size (in bytes) of the mailbox command payload
+ registers. Linux caps this at 1MB if the device reports a
+ larger size.
+
+
+What: /sys/bus/cxl/devices/memX/label_storage_size
+Date: May, 2021
+KernelVersion: v5.13
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) Size (in bytes) of the Label Storage Area (LSA).
+
+
What: /sys/bus/cxl/devices/memX/ram/size
Date: December, 2020
KernelVersion: v5.12
@@ -28,6 +46,23 @@ Description:
Payload in the CXL-2.0 specification.
+What: /sys/bus/cxl/devices/memX/ram/qos_class
+Date: May, 2023
+KernelVersion: v6.8
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) For CXL host platforms that support "QoS Telemetry"
+ this attribute conveys a comma delimited list of platform
+ specific cookies that identifies a QoS performance class
+ for the volatile partition of the CXL mem device. These
+ class-ids can be compared against a similar "qos_class"
+ published for a root decoder. While it is not required
+ that the endpoints map their local memory-class to a
+ matching platform class, mismatches are not recommended
+ and there are platform specific performance related
+ side-effects that may result. First class-id is displayed.
+
+
What: /sys/bus/cxl/devices/memX/pmem/size
Date: December, 2020
KernelVersion: v5.12
@@ -38,6 +73,23 @@ Description:
Payload in the CXL-2.0 specification.
+What: /sys/bus/cxl/devices/memX/pmem/qos_class
+Date: May, 2023
+KernelVersion: v6.8
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) For CXL host platforms that support "QoS Telemetry"
+ this attribute conveys a comma delimited list of platform
+ specific cookies that identifies a QoS performance class
+ for the persistent partition of the CXL mem device. These
+ class-ids can be compared against a similar "qos_class"
+ published for a root decoder. While it is not required
+ that the endpoints map their local memory-class to a
+ matching platform class, mismatches are not recommended
+ and there are platform specific performance related
+ side-effects that may result. First class-id is displayed.
+
+
What: /sys/bus/cxl/devices/memX/serial
Date: January, 2022
KernelVersion: v5.18
@@ -58,6 +110,65 @@ Description:
affinity for this device.
+What: /sys/bus/cxl/devices/memX/security/state
+Date: June, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) Reading this file will display the CXL security state for
+ that device. Such states can be: 'disabled', 'sanitize', when
+ a sanitization is currently underway; or those available only
+ for persistent memory: 'locked', 'unlocked' or 'frozen'. This
+ sysfs entry is select/poll capable from userspace to notify
+ upon completion of a sanitize operation.
+
+
+What: /sys/bus/cxl/devices/memX/security/sanitize
+Date: June, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) Write a boolean 'true' string value to this attribute to
+ sanitize the device to securely re-purpose or decommission it.
+ This is done by ensuring that all user data and meta-data,
+ whether it resides in persistent capacity, volatile capacity,
+ or the LSA, is made permanently unavailable by whatever means
+ is appropriate for the media type. This functionality requires
+ the device to be disabled, that is, not actively decoding any
+ HPA ranges. This permits avoiding explicit global CPU cache
+ management, relying instead for it to be done when a region
+ transitions between software programmed and hardware committed
+ states. If this file is not present, then there is no hardware
+ support for the operation.
+
+
+What /sys/bus/cxl/devices/memX/security/erase
+Date: June, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) Write a boolean 'true' string value to this attribute to
+ secure erase user data by changing the media encryption keys for
+ all user data areas of the device. This functionality requires
+ the device to be disabled, that is, not actively decoding any
+ HPA ranges. This permits avoiding explicit global CPU cache
+ management, relying instead for it to be done when a region
+ transitions between software programmed and hardware committed
+ states. If this file is not present, then there is no hardware
+ support for the operation.
+
+
+What: /sys/bus/cxl/devices/memX/firmware/
+Date: April, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RW) Firmware uploader mechanism. The different files under
+ this directory can be used to upload and activate new
+ firmware for CXL devices. The interfaces under this are
+ documented in sysfs-class-firmware.
+
+
What: /sys/bus/cxl/devices/*/devtype
Date: June, 2021
KernelVersion: v5.14
@@ -90,6 +201,21 @@ Description:
capability.
+What: /sys/bus/cxl/devices/{port,endpoint}X/parent_dport
+Date: January, 2023
+KernelVersion: v6.3
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) CXL port objects are instantiated for each upstream port in
+ a CXL/PCIe switch, and for each endpoint to map the
+ corresponding memory device into the CXL port hierarchy. When a
+ descendant CXL port (switch or endpoint) is enumerated it is
+ useful to know which 'dport' object in the parent CXL port
+ routes to this descendant. The 'parent_dport' symlink points to
+ the device representing the downstream port of a CXL switch that
+ routes to {port,endpoint}X.
+
+
What: /sys/bus/cxl/devices/portX/dportY
Date: June, 2021
KernelVersion: v5.14
@@ -104,6 +230,21 @@ Description:
hardware decoder target list.
+What: /sys/bus/cxl/devices/portX/decoders_committed
+Date: October, 2023
+KernelVersion: v6.7
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) A memory device is considered active when any of its
+ decoders are in the "committed" state (See CXL 3.0 8.2.4.19.7
+ CXL HDM Decoder n Control Register). Hotplug and destructive
+ operations like "sanitize" are blocked while device is actively
+ decoding a Host Physical Address range. Note that this number
+ may be elevated without any regionX objects active or even
+ enumerated, as this may be due to decoders established by
+ platform firmware or a previous kernel (kexec).
+
+
What: /sys/bus/cxl/devices/decoderX.Y
Date: June, 2021
KernelVersion: v5.14
@@ -183,7 +324,7 @@ Description:
What: /sys/bus/cxl/devices/endpointX/CDAT
Date: July, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) If this sysfs entry is not present no DOE mailbox was
@@ -194,18 +335,17 @@ Description:
What: /sys/bus/cxl/devices/decoderX.Y/mode
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
- translates from a host physical address range, to a device local
- address range. Device-local address ranges are further split
- into a 'ram' (volatile memory) range and 'pmem' (persistent
- memory) range. The 'mode' attribute emits one of 'ram', 'pmem',
- 'mixed', or 'none'. The 'mixed' indication is for error cases
- when a decoder straddles the volatile/persistent partition
- boundary, and 'none' indicates the decoder is not actively
- decoding, or no DPA allocation policy has been set.
+ translates from a host physical address range, to a device
+ local address range. Device-local address ranges are further
+ split into a 'ram' (volatile memory) range and 'pmem'
+ (persistent memory) range. The 'mode' attribute emits one of
+ 'ram', 'pmem', or 'none'. The 'none' indicates the decoder is
+ not actively decoding, or no DPA allocation policy has been
+ set.
'mode' can be written, when the decoder is in the 'disabled'
state, with either 'ram' or 'pmem' to set the boundaries for the
@@ -214,7 +354,7 @@ Description:
What: /sys/bus/cxl/devices/decoderX.Y/dpa_resource
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) When a CXL decoder is of devtype "cxl_decoder_endpoint",
@@ -225,7 +365,7 @@ Description:
What: /sys/bus/cxl/devices/decoderX.Y/dpa_size
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
@@ -245,7 +385,7 @@ Description:
What: /sys/bus/cxl/devices/decoderX.Y/interleave_ways
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The number of targets across which this decoder's host
@@ -260,7 +400,7 @@ Description:
What: /sys/bus/cxl/devices/decoderX.Y/interleave_granularity
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The number of consecutive bytes of host physical address
@@ -270,44 +410,60 @@ Description:
interleave_granularity).
-What: /sys/bus/cxl/devices/decoderX.Y/create_pmem_region
-Date: May, 2022
-KernelVersion: v5.20
+What: /sys/bus/cxl/devices/decoderX.Y/create_{pmem,ram}_region
+Date: May, 2022, January, 2023
+KernelVersion: v6.0 (pmem), v6.3 (ram)
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a string in the form 'regionZ' to start the process
- of defining a new persistent memory region (interleave-set)
- within the decode range bounded by root decoder 'decoderX.Y'.
- The value written must match the current value returned from
- reading this attribute. An atomic compare exchange operation is
- done on write to assign the requested id to a region and
- allocate the region-id for the next creation attempt. EBUSY is
- returned if the region name written does not match the current
- cached value.
+ of defining a new persistent, or volatile memory region
+ (interleave-set) within the decode range bounded by root decoder
+ 'decoderX.Y'. The value written must match the current value
+ returned from reading this attribute. An atomic compare exchange
+ operation is done on write to assign the requested id to a
+ region and allocate the region-id for the next creation attempt.
+ EBUSY is returned if the region name written does not match the
+ current cached value.
What: /sys/bus/cxl/devices/decoderX.Y/delete_region
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(WO) Write a string in the form 'regionZ' to delete that region,
provided it is currently idle / not bound to a driver.
+What: /sys/bus/cxl/devices/decoderX.Y/qos_class
+Date: May, 2023
+KernelVersion: v6.5
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) For CXL host platforms that support "QoS Telemetry" this
+ root-decoder-only attribute conveys a platform specific cookie
+ that identifies a QoS performance class for the CXL Window.
+ This class-id can be compared against a similar "qos_class"
+ published for each memory-type that an endpoint supports. While
+ it is not required that endpoints map their local memory-class
+ to a matching platform class, mismatches are not recommended and
+ there are platform specific side-effects that may result.
+
+
What: /sys/bus/cxl/devices/regionZ/uuid
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a unique identifier for the region. This field must
be set for persistent regions and it must not conflict with the
- UUID of another region.
+ UUID of another region. For volatile ram regions this
+ attribute is a read-only empty string.
What: /sys/bus/cxl/devices/regionZ/interleave_granularity
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Set the number of consecutive bytes each device in the
@@ -318,7 +474,7 @@ Description:
What: /sys/bus/cxl/devices/regionZ/interleave_ways
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Configures the number of devices participating in the
@@ -328,7 +484,7 @@ Description:
What: /sys/bus/cxl/devices/regionZ/size
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) System physical address space to be consumed by the region.
@@ -340,12 +496,32 @@ Description:
changed, only freed by writing 0. The kernel makes no guarantees
that data is maintained over an address space freeing event, and
there is no guarantee that a free followed by an allocate
- results in the same address being allocated.
+ results in the same address being allocated. If extended linear
+ cache is present, the size indicates extended linear cache size
+ plus the CXL region size.
+
+What: /sys/bus/cxl/devices/regionZ/extended_linear_cache_size
+Date: October, 2025
+KernelVersion: v6.19
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) The size of extended linear cache, if there is an extended
+ linear cache. Otherwise the attribute will not be visible.
+
+What: /sys/bus/cxl/devices/regionZ/mode
+Date: January, 2023
+KernelVersion: v6.3
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) The mode of a region is established at region creation time
+ and dictates the mode of the endpoint decoder that comprise the
+ region. For more details on the possible modes see
+ /sys/bus/cxl/devices/decoderX.Y/mode
What: /sys/bus/cxl/devices/regionZ/resource
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RO) A region is a contiguous partition of a CXL root decoder
@@ -357,7 +533,7 @@ Description:
What: /sys/bus/cxl/devices/regionZ/target[0..N]
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write an endpoint decoder object name to 'targetX' where X
@@ -376,7 +552,7 @@ Description:
What: /sys/bus/cxl/devices/regionZ/commit
Date: May, 2022
-KernelVersion: v5.20
+KernelVersion: v6.0
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a boolean 'true' string value to this attribute to
@@ -388,3 +564,63 @@ Description:
1), and checks that the hardware accepts the commit request.
Reading this value indicates whether the region is committed or
not.
+
+
+What: /sys/bus/cxl/devices/memX/trigger_poison_list
+Date: April, 2023
+KernelVersion: v6.4
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (WO) When a boolean 'true' is written to this attribute the
+ memdev driver retrieves the poison list from the device. The
+ list consists of addresses that are poisoned, or would result
+ in poison if accessed, and the source of the poison. This
+ attribute is only visible for devices supporting the
+ capability. The retrieved errors are logged as kernel
+ events when cxl_poison event tracing is enabled.
+
+
+What: /sys/bus/cxl/devices/regionZ/accessY/read_bandwidth
+ /sys/bus/cxl/devices/regionZ/accessY/write_bandwidth
+Date: Jan, 2024
+KernelVersion: v6.9
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) The aggregated read or write bandwidth of the region. The
+ number is the accumulated read or write bandwidth of all CXL memory
+ devices that contributes to the region in MB/s. It is
+ identical data that should appear in
+ /sys/devices/system/node/nodeX/accessY/initiators/read_bandwidth or
+ /sys/devices/system/node/nodeX/accessY/initiators/write_bandwidth.
+ See Documentation/ABI/stable/sysfs-devices-node. access0 provides
+ the number to the closest initiator and access1 provides the
+ number to the closest CPU.
+
+
+What: /sys/bus/cxl/devices/regionZ/accessY/read_latency
+ /sys/bus/cxl/devices/regionZ/accessY/write_latency
+Date: Jan, 2024
+KernelVersion: v6.9
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) The read or write latency of the region. The number is
+ the worst read or write latency of all CXL memory devices that
+ contributes to the region in nanoseconds. It is identical data
+ that should appear in
+ /sys/devices/system/node/nodeX/accessY/initiators/read_latency or
+ /sys/devices/system/node/nodeX/accessY/initiators/write_latency.
+ See Documentation/ABI/stable/sysfs-devices-node. access0 provides
+ the number to the closest initiator and access1 provides the
+ number to the closest CPU.
+
+
+What: /sys/bus/cxl/devices/nvdimm-bridge0/ndbusX/nmemY/cxl/dirty_shutdown
+Date: Feb, 2025
+KernelVersion: v6.15
+Contact: linux-cxl@vger.kernel.org
+Description:
+ (RO) The device dirty shutdown count value, which is the number
+ of times the device could have incurred in potential data loss.
+ The count is persistent across power loss and wraps back to 0
+ upon overflow. If this file is not present, the device does not
+ have the necessary support for dirty tracking.
diff --git a/Documentation/ABI/testing/sysfs-bus-dax b/Documentation/ABI/testing/sysfs-bus-dax
new file mode 100644
index 000000000000..b34266bfae49
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-dax
@@ -0,0 +1,153 @@
+What: /sys/bus/dax/devices/daxX.Y/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Provides a way to specify an alignment for a dax device.
+ Values allowed are constrained by the physical address ranges
+ that back the dax device, and also by arch requirements.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) Provides a way to allocate a mapping range under a dax
+ device. Specified in the format <start>-<end>.
+
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/start
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/end
+What: /sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) A dax device may have multiple constituent discontiguous
+ address ranges. These are represented by the different
+ 'mappingX' subdirectories. The 'start' attribute indicates the
+ start physical address for the given range. The 'end' attribute
+ indicates the end physical address for the given range. The
+ 'page_offset' attribute indicates the offset of the current
+ range in the dax device.
+
+What: /sys/bus/dax/devices/daxX.Y/resource
+Date: June, 2019
+KernelVersion: v5.3
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The resource attribute indicates the starting physical
+ address of a dax device. In case of a device with multiple
+ constituent ranges, it indicates the starting address of the
+ first range.
+
+What: /sys/bus/dax/devices/daxX.Y/size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The size attribute indicates the total size of a dax
+ device. For creating subdivided dax devices, or for resizing
+ an existing device, the new size can be written to this as
+ part of the reconfiguration process.
+
+What: /sys/bus/dax/devices/daxX.Y/numa_node
+Date: November, 2019
+KernelVersion: v5.5
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) If NUMA is enabled and the platform has affinitized the
+ backing device for this dax device, emit the CPU node
+ affinity for this device.
+
+What: /sys/bus/dax/devices/daxX.Y/target_node
+Date: February, 2019
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The target-node attribute is the Linux numa-node that a
+ device-dax instance may create when it is online. Prior to
+ being online the device's 'numa_node' property reflects the
+ closest online cpu node which is the typical expectation of a
+ device 'numa_node'. Once it is online it becomes its own
+ distinct numa node.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/available_size
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The available_size attribute tracks available dax region
+ capacity. This only applies to volatile hmem devices, not pmem
+ devices, since pmem devices are defined by nvdimm namespace
+ boundaries.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/size
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The size attribute indicates the size of a given dax region
+ in bytes.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/align
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The align attribute indicates alignment of the dax region.
+ Changes on align may not always be valid, when say certain
+ mappings were created with 2M and then we switch to 1G. This
+ validates all ranges against the new value being attempted, post
+ resizing.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/seed
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The seed device is a concept for dynamic dax regions to be
+ able to split the region amongst multiple sub-instances. The
+ seed device, similar to libnvdimm seed devices, is a device
+ that starts with zero capacity allocated and unbound to a
+ driver.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/create
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) The create interface to the dax region provides a way to
+ create a new unconfigured dax device under the given region, which
+ can then be configured (with a size etc.) and then probed.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/delete
+Date: October, 2020
+KernelVersion: v5.10
+Contact: nvdimm@lists.linux.dev
+Description:
+ (WO) The delete interface for a dax region provides for deletion
+ of any 0-sized and idle dax devices.
+
+What: $(readlink -f /sys/bus/dax/devices/daxX.Y)/../dax_region/id
+Date: July, 2017
+KernelVersion: v5.1
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RO) The id attribute indicates the region id of a dax region.
+
+What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory
+Date: January, 2024
+KernelVersion: v6.8
+Contact: nvdimm@lists.linux.dev
+Description:
+ (RW) Control the memmap_on_memory setting if the dax device
+ were to be hotplugged as system memory. This determines whether
+ the 'altmap' for the hotplugged memory will be placed on the
+ device being hotplugged (memmap_on_memory=1) or if it will be
+ placed on regular memory (memmap_on_memory=0). This attribute
+ must be set before the device is handed over to the 'kmem'
+ driver (i.e. hotplugged into system-ram). Additionally, this
+ depends on CONFIG_MHP_MEMMAP_ON_MEMORY, and a globally enabled
+ memmap_on_memory parameter for memory_hotplug. This is
+ typically set on the kernel command line -
+ memory_hotplug.memmap_on_memory set to 'true' or 'force'."
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices b/Documentation/ABI/testing/sysfs-bus-event_source-devices
new file mode 100644
index 000000000000..79b268319df1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices
@@ -0,0 +1,24 @@
+What: /sys/bus/event_source/devices/<pmu>
+Date: 2014/02/24
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description: Performance Monitoring Unit (<pmu>)
+
+ Each <pmu> directory, for a PMU device, is a name
+ optionally followed by an underscore and then either a
+ decimal or hexadecimal number. For example, cpu is a
+ PMU name without a suffix as is intel_bts,
+ uncore_imc_0 is a PMU name with a 0 numeric suffix,
+ ddr_pmu_87e1b0000000 is a PMU name with a hex
+ suffix. The hex suffix must be more than two
+ characters long to avoid ambiguity with PMUs like the
+ S390 cpum_cf.
+
+ Tools can treat PMUs with the same name that differ by
+ suffix as instances of the same PMU for the sake of,
+ for example, opening an event. For example, the PMUs
+ uncore_imc_free_running_0 and
+ uncore_imc_free_running_1 have an event data_read;
+ opening the data_read event on a PMU specified as
+ uncore_imc_free_running should be treated as opening
+ the data_read event on PMU uncore_imc_free_running_0
+ and PMU uncore_imc_free_running_1.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps b/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps
index 8757dcf41c08..a5f506f7d481 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-caps
@@ -16,3 +16,9 @@ Description:
Example output in powerpc:
grep . /sys/bus/event_source/devices/cpu/caps/*
/sys/bus/event_source/devices/cpu/caps/pmu_name:POWER9
+
+ The "branch_counter_nr" in the supported platform exposes the
+ maximum number of counters which can be shown in the u64 counters
+ of PERF_SAMPLE_BRANCH_COUNTERS, while the "branch_counter_width"
+ exposes the width of each counter. Both of them can be used by
+ the perf tool to parse the logged counters in each branch.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 505f080d20a1..0fe1b9487202 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -37,6 +37,14 @@ Description: Per-pmu performance monitoring events specific to the running syste
performance monitoring event supported by the <pmu>. The name
of the file is the name of the event.
+ As performance monitoring event names are case insensitive
+ in the perf tool, the perf tool only looks for all lower
+ case or all upper case event names in sysfs to avoid
+ scanning the directory. It is therefore required the
+ name of the event here is either completely lower or upper
+ case, with no mixed-case characters. Numbers, '.', '_', and
+ '-' are also allowed.
+
File contents:
<term>[=<value>][,<term>[=<value>]]...
@@ -47,7 +55,7 @@ Description: Per-pmu performance monitoring events specific to the running syste
If a <term> is specified alone (without an assigned value), it
is implied that 0x1 is assigned to that <term>.
- Examples (each of these lines would be in a seperate file):
+ Examples (each of these lines would be in a separate file):
event=0x2abc
event=0x423,inv,cmask=0x3
@@ -83,7 +91,7 @@ Description: Perf event scaling factors
A string representing a floating point value expressed in
scientific notation to be multiplied by the event count
- recieved from the kernel to match the unit specified in the
+ received from the kernel to match the unit specified in the
<event>.unit file.
Example:
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
new file mode 100644
index 000000000000..1119766564d7
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
@@ -0,0 +1,113 @@
+What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune
+Date: October 2022
+KernelVersion: 6.1
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: This directory contains files for tuning the PCIe link
+ parameters(events). Each file is named after the event
+ of the PCIe link.
+
+ See Documentation/trace/hisi-ptt.rst for more information.
+
+What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
+Date: October 2022
+KernelVersion: 6.1
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (RW) Controls the weight of Tx completion TLPs, which influence
+ the proportion of outbound completion TLPs on the PCIe link.
+ The available tune data is [0, 1, 2]. Writing a negative value
+ will return an error, and out of range values will be converted
+ to 2. The value indicates a probable level of the event.
+
+What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
+Date: October 2022
+KernelVersion: 6.1
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (RW) Controls the weight of Tx non-posted TLPs, which influence
+ the proportion of outbound non-posted TLPs on the PCIe link.
+ The available tune data is [0, 1, 2]. Writing a negative value
+ will return an error, and out of range values will be converted
+ to 2. The value indicates a probable level of the event.
+
+What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
+Date: October 2022
+KernelVersion: 6.1
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (RW) Controls the weight of Tx posted TLPs, which influence the
+ proportion of outbound posted TLPs on the PCIe link.
+ The available tune data is [0, 1, 2]. Writing a negative value
+ will return an error, and out of range values will be converted
+ to 2. The value indicates a probable level of the event.
+
+What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
+Date: October 2022
+KernelVersion: 6.1
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (RW) Control the allocated buffer watermark for inbound packets.
+ The packets will be stored in the buffer first and then transmitted
+ either when the watermark reached or when timed out.
+ The available tune data is [0, 1, 2]. Writing a negative value
+ will return an error, and out of range values will be converted
+ to 2. The value indicates a probable level of the event.
+
+What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
+Date: October 2022
+KernelVersion: 6.1
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (RW) Control the allocated buffer watermark of outbound packets.
+ The packets will be stored in the buffer first and then transmitted
+ either when the watermark reached or when timed out.
+ The available tune data is [0, 1, 2]. Writing a negative value
+ will return an error, and out of range values will be converted
+ to 2. The value indicates a probable level of the event.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: This directory contains the files providing the PCIe Root Port filters
+ information used for PTT trace. Each file is named after the supported
+ Root Port device name <domain>:<bus>:<device>.<function>.
+
+ See the description of the "filter" in Documentation/trace/hisi-ptt.rst
+ for more information.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters/multiselect
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates if this kind of filter can be selected at the same
+ time as others filters, or must be used on it's own. 1 indicates
+ the former case and 0 indicates the latter.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/root_port_filters/<bdf>
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates the filter value of this Root Port filter, which
+ can be used to control the TLP headers to trace by the PTT trace.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: This directory contains the files providing the PCIe Requester filters
+ information used for PTT trace. Each file is named after the supported
+ Endpoint device name <domain>:<bus>:<device>.<function>.
+
+ See the description of the "filter" in Documentation/trace/hisi-ptt.rst
+ for more information.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters/multiselect
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates if this kind of filter can be selected at the same
+ time as others filters, or must be used on it's own. 1 indicates
+ the former case and 0 indicates the latter.
+
+What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/requester_filters/<bdf>
+Date: May 2023
+KernelVersion: 6.5
+Contact: Yicong Yang <yangyicong@hisilicon.com>
+Description: (Read) Indicates the filter value of this Requester filter, which
+ can be used to control the TLP headers to trace by the PTT trace.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
index 12e2bf92783f..40f7cd240591 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -80,3 +80,163 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description: read only
This sysfs file exposes the cpumask which is designated to make
HCALLs to retrieve hv-gpci pmu event counter data.
+
+What: /sys/devices/hv_gpci/interface/processor_bus_topology
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ PROCESSOR_BUS_TOPOLOGY(0xD0).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/processor_config
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ PROCESSOR_CONFIG(0x90).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/affinity_domain_via_virtual_processor
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ AFFINITY_DOMAIN_INFORMATION_BY_VIRTUAL_PROCESSOR(0xA0).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/affinity_domain_via_domain
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ AFFINITY_DOMAIN_INFORMATION_BY_DOMAIN(0xB0).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
+
+What: /sys/devices/hv_gpci/interface/affinity_domain_via_partition
+Date: July 2023
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: admin read only
+ This sysfs file exposes the system topology information by making HCALL
+ H_GET_PERF_COUNTER_INFO. The HCALL is made with counter request value
+ AFFINITY_DOMAIN_INFORMATION_BY_PARTITION(0xB1).
+
+ * This sysfs file will be created only for power10 and above platforms.
+
+ * User needs root privileges to read data from this sysfs file.
+
+ * This sysfs file will be created, only when the HCALL returns "H_SUCCESS",
+ "H_AUTHORITY" or "H_PARAMETER" as the return type.
+
+ HCALL with return error type "H_AUTHORITY" can be resolved during
+ runtime by setting "Enable Performance Information Collection" option.
+
+ * The end user reading this sysfs file must decode the content as per
+ underlying platform/firmware.
+
+ Possible error codes while reading this sysfs file:
+
+ * "-EPERM" : Partition is not permitted to retrieve performance information,
+ required to set "Enable Performance Information Collection" option.
+
+ * "-EIO" : Can't retrieve system information because of invalid buffer length/invalid address
+ or because of some hardware error. Refer to getPerfCountInfo documentation for
+ more information.
+
+ * "-EFBIG" : System information exceeds PAGE_SIZE.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu b/Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu
new file mode 100644
index 000000000000..d7af4919302e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-iommu
@@ -0,0 +1,37 @@
+What: /sys/bus/event_source/devices/dmar*/format
+Date: Jan 2023
+KernelVersion: 6.3
+Contact: Kan Liang <kan.liang@linux.intel.com>
+Description: Read-only. Attribute group to describe the magic bits
+ that go into perf_event_attr.config,
+ perf_event_attr.config1 or perf_event_attr.config2 for
+ the IOMMU pmu. (See also
+ ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute in this group defines a bit range in
+ perf_event_attr.config, perf_event_attr.config1,
+ or perf_event_attr.config2. All supported attributes
+ are listed below (See the VT-d Spec 4.0 for possible
+ attribute values)::
+
+ event = "config:0-27" - event ID
+ event_group = "config:28-31" - event group ID
+
+ filter_requester_en = "config1:0" - Enable Requester ID filter
+ filter_domain_en = "config1:1" - Enable Domain ID filter
+ filter_pasid_en = "config1:2" - Enable PASID filter
+ filter_ats_en = "config1:3" - Enable Address Type filter
+ filter_page_table_en= "config1:4" - Enable Page Table Level filter
+ filter_requester_id = "config1:16-31" - Requester ID filter
+ filter_domain = "config1:32-47" - Domain ID filter
+ filter_pasid = "config2:0-21" - PASID filter
+ filter_ats = "config2:24-28" - Address Type filter
+ filter_page_table = "config2:32-36" - Page Table Level filter
+
+What: /sys/bus/event_source/devices/dmar*/cpumask
+Date: Jan 2023
+KernelVersion: 6.3
+Contact: Kan Liang <kan.liang@linux.intel.com>
+Description: Read-only. This file always returns the CPU to which the
+ IOMMU pmu is bound for access to all IOMMU pmu performance
+ monitoring events.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-dtl b/Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-dtl
new file mode 100644
index 000000000000..7b7c789a5cf5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-dtl
@@ -0,0 +1,25 @@
+What: /sys/bus/event_source/devices/vpa_dtl/format
+Date: February 2025
+Contact: Linux on PowerPC Developer List <linuxppc-dev at lists.ozlabs.org>
+Description: Read-only. Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute are listed
+ below::
+
+ event = "config:0-7" - event ID
+
+ For example::
+
+ dtl_cede = "event=0x1"
+
+What: /sys/bus/event_source/devices/vpa_dtl/events
+Date: February 2025
+Contact: Linux on PowerPC Developer List <linuxppc-dev at lists.ozlabs.org>
+Description: (RO) Attribute group to describe performance monitoring events
+ for the Virtual Processor Dispatch Trace Log. Each attribute in
+ this group describes a single performance monitoring event
+ supported by vpa_dtl pmu. The name of the file is the name of
+ the event (See ABI/testing/sysfs-bus-event_source-devices-events).
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-pmu b/Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-pmu
new file mode 100644
index 000000000000..a116aee9709a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-vpa-pmu
@@ -0,0 +1,25 @@
+What: /sys/bus/event_source/devices/vpa_pmu/format
+Date: November 2024
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: Read-only. Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. Supported attribute are listed
+ below::
+
+ event = "config:0-31" - event ID
+
+ For example::
+
+ l1_to_l2_lat = "event=0x1"
+
+What: /sys/bus/event_source/devices/vpa_pmu/events
+Date: November 2024
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: Read-only. Attribute group to describe performance monitoring
+ events for the Virtual Processor Area events. Each attribute
+ in this group describes a single performance monitoring event
+ supported by vpa_pmu. The name of the file is the name of
+ the event (See ABI/testing/sysfs-bus-event_source-devices-events).
diff --git a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo
index 531fe9d6b40a..c7393b4dd2d8 100644
--- a/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo
+++ b/Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo
@@ -5,6 +5,6 @@ Description:
Indicates whether or not this SBE device has experienced a
timeout; i.e. the SBE did not respond within the time allotted
by the driver. A value of 1 indicates that a timeout has
- ocurred and no transfers have completed since the timeout. A
- value of 0 indicates that no timeout has ocurred, or if one
- has, more recent transfers have completed successful.
+ occurred and no transfers have completed since the timeout. A
+ value of 0 indicates that no timeout has occurred, or if one
+ has, more recent transfers have completed successfully.
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480
index 42dfc9399d2d..288bc2fa9547 100644
--- a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480
@@ -8,7 +8,7 @@ Description:
NONE no device
USB USB device is attached
UART UART is attached
- CHARGER Charger is attaced
+ CHARGER Charger is attached
JIG JIG is attached
======= ======================
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-m24lr b/Documentation/ABI/testing/sysfs-bus-i2c-devices-m24lr
new file mode 100644
index 000000000000..7c51ce8d38ba
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-m24lr
@@ -0,0 +1,100 @@
+What: /sys/bus/i2c/devices/<busnum>-<primary-addr>/unlock
+Date: 2025-07-04
+KernelVersion: 6.17
+Contact: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+Description:
+ Write-only attribute used to present a password and unlock
+ access to protected areas of the M24LR chip, including
+ configuration registers such as the Sector Security Status
+ (SSS) bytes. A valid password must be written to enable write
+ access to these regions via the I2C interface.
+
+ Format:
+ - Hexadecimal string representing a 32-bit (4-byte) password
+ - Accepts 1 to 8 hex digits (e.g., "c", "1F", "a1b2c3d4")
+ - No "0x" prefix, whitespace, or trailing newline
+ - Case-insensitive
+
+ Behavior:
+ - If the password matches the internal stored value,
+ access to protected memory/configuration is granted
+ - If the password does not match the internally stored value,
+ it will fail silently
+
+What: /sys/bus/i2c/devices/<busnum>-<primary-addr>/new_pass
+Date: 2025-07-04
+KernelVersion: 6.17
+Contact: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+Description:
+ Write-only attribute used to update the password required to
+ unlock the M24LR chip.
+
+ Format:
+ - Hexadecimal string representing a new 32-bit password
+ - Accepts 1 to 8 hex digits (e.g., "1A", "ffff", "c0ffee00")
+ - No "0x" prefix, whitespace, or trailing newline
+ - Case-insensitive
+
+ Behavior:
+ - Overwrites the current password stored in the I2C password
+ register
+ - Requires the device to be unlocked before changing the
+ password
+ - If the device is locked, the write silently fails
+
+What: /sys/bus/i2c/devices/<busnum>-<primary-addr>/uid
+Date: 2025-07-04
+KernelVersion: 6.17
+Contact: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+Description:
+ Read-only attribute that exposes the 8-byte unique identifier
+ programmed into the M24LR chip at the factory.
+
+ Format:
+ - Lowercase hexadecimal string representing a 64-bit value
+ - 1 to 16 hex digits (e.g., "e00204f12345678")
+ - No "0x" prefix
+ - Includes a trailing newline
+
+What: /sys/bus/i2c/devices/<busnum>-<primary-addr>/total_sectors
+Date: 2025-07-04
+KernelVersion: 6.17
+Contact: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+Description:
+ Read-only attribute that exposes the total number of EEPROM
+ sectors available in the M24LR chip.
+
+ Format:
+ - 1 to 2 hex digits (e.g. "F")
+ - No "0x" prefix
+ - Includes a trailing newline
+
+ Notes:
+ - Value is encoded by the chip and corresponds to the EEPROM
+ size (e.g., 3 = 4 kbit for M24LR04E-R)
+
+What: /sys/bus/i2c/devices/<busnum>-<primary-addr>/sss
+Date: 2025-07-04
+KernelVersion: 6.17
+Contact: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+Description:
+ Read/write binary attribute representing the Sector Security
+ Status (SSS) bytes for all EEPROM sectors in STMicroelectronics
+ M24LR chips.
+
+ Each EEPROM sector has one SSS byte, which controls I2C and
+ RF access through protection bits and optional password
+ authentication.
+
+ Format:
+ - The file contains one byte per EEPROM sector
+ - Byte at offset N corresponds to sector N
+ - Binary access only; use tools like dd, Python, or C that
+ support byte-level I/O and offset control.
+
+ Notes:
+ - The number of valid bytes in this file is equal to the
+ value exposed by 'total_sectors' file
+ - Write access requires prior password authentication in
+ I2C mode
+ - Refer to the M24LR datasheet for full SSS bit layout
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-turris-omnia-mcu b/Documentation/ABI/testing/sysfs-bus-i2c-devices-turris-omnia-mcu
new file mode 100644
index 000000000000..35a8f6dae5bf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-turris-omnia-mcu
@@ -0,0 +1,113 @@
+What: /sys/bus/i2c/devices/<mcu_device>/board_revision
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains board revision number.
+
+ Only available if board information is burned in the MCU (older
+ revisions have board information burned in the ATSHA204-A chip).
+
+ Format: %u.
+
+What: /sys/bus/i2c/devices/<mcu_device>/first_mac_address
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains device first MAC address. Each Turris Omnia is
+ allocated 3 MAC addresses. The two additional addresses are
+ computed from the first one by incrementing it.
+
+ Only available if board information is burned in the MCU (older
+ revisions have board information burned in the ATSHA204-A chip).
+
+ Format: %pM.
+
+What: /sys/bus/i2c/devices/<mcu_device>/front_button_mode
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RW) The front button on the Turris Omnia router can be
+ configured either to change the intensity of all the LEDs on the
+ front panel, or to send the press event to the CPU as an
+ interrupt.
+
+ This file switches between these two modes:
+ - ``mcu`` makes the button press event be handled by the MCU to
+ change the LEDs panel intensity.
+ - ``cpu`` makes the button press event be handled by the CPU.
+
+ Format: %s.
+
+What: /sys/bus/i2c/devices/<mcu_device>/front_button_poweron
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RW) Newer versions of the microcontroller firmware of the
+ Turris Omnia router support powering off the router into true
+ low power mode. The router can be powered on by pressing the
+ front button.
+
+ This file configures whether front button power on is enabled.
+
+ This file is present only if the power off feature is supported
+ by the firmware.
+
+ Format: %i.
+
+What: /sys/bus/i2c/devices/<mcu_device>/fw_features
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Newer versions of the microcontroller firmware report the
+ features they support. These can be read from this file. If the
+ MCU firmware is too old, this file reads 0x0.
+
+ Format: 0x%x.
+
+What: /sys/bus/i2c/devices/<mcu_device>/fw_version_hash_application
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains the version hash (commit hash) of the application
+ part of the microcontroller firmware.
+
+ Format: %s.
+
+What: /sys/bus/i2c/devices/<mcu_device>/fw_version_hash_bootloader
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains the version hash (commit hash) of the bootloader
+ part of the microcontroller firmware.
+
+ Format: %s.
+
+What: /sys/bus/i2c/devices/<mcu_device>/mcu_type
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains the microcontroller type (STM32, GD32, MKL).
+
+ Format: %s.
+
+What: /sys/bus/i2c/devices/<mcu_device>/reset_selector
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains the selected factory reset level, determined by
+ how long the rear reset button was held by the user during board
+ reset.
+
+ Format: %i.
+
+What: /sys/bus/i2c/devices/<mcu_device>/serial_number
+Date: September 2024
+KernelVersion: 6.11
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RO) Contains the 64-bit board serial number in hexadecimal
+ format.
+
+ Only available if board information is burned in the MCU (older
+ revisions have board information burned in the ATSHA204-A chip).
+
+ Format: %016X.
diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c
index 1f4a2662335b..c812ab180ff4 100644
--- a/Documentation/ABI/testing/sysfs-bus-i3c
+++ b/Documentation/ABI/testing/sysfs-bus-i3c
@@ -67,7 +67,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/pid
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
Description:
- PID stands for Provisional ID and is used to uniquely identify
+ PID stands for Provisioned ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
@@ -88,6 +88,21 @@ Description:
This entry describes the HDRCAP of the master controller
driving the bus.
+What: /sys/bus/i3c/devices/i3c-<bus-id>/hotjoin
+KernelVersion: 6.8
+Contact: linux-i3c@vger.kernel.org
+Description:
+ I3C’s Hot-Join mechanism allows an I3C Device to inform the
+ Active Controller that a newly-joined Target is present on the
+ I3C Bus and is ready to receive a Dynamic Address, in order to
+ become fully functional on the Bus. Hot-Join is used when the
+ Target is mounted on the same I3C bus and remains depowered
+ until needed or until the Target is physically inserted into the
+ I3C bus
+
+ This entry allows to enable or disable Hot-join of the Current
+ Controller driving the bus.
+
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
@@ -123,7 +138,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
Description:
- PID stands for Provisional ID and is used to uniquely identify
+ PID stands for Provisioned ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index e81ba6f5e1c8..5f87dcee78f7 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -94,6 +94,7 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency
What: /sys/bus/iio/devices/iio:deviceX/buffer/sampling_frequency
+What: /sys/bus/iio/devices/iio:deviceX/events/sampling_frequency
What: /sys/bus/iio/devices/triggerX/sampling_frequency
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
@@ -140,8 +141,6 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -168,19 +167,18 @@ Description:
is required is a consistent labeling. Units after application
of scale and offset are millivolts.
-What: /sys/bus/iio/devices/iio:deviceX/in_currentY_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_raw
-KernelVersion: 3.17
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_rms_raw
+KernelVersion: 6.18
Contact: linux-iio@vger.kernel.org
Description:
- Raw (unscaled no bias removal etc.) current measurement from
- channel Y. In special cases where the channel does not
- correspond to externally available input one of the named
- versions may be used. The number must always be specified and
- unique to allow association with event codes. Units after
- application of scale and offset are milliamps.
+ Raw (unscaled) Root Mean Square (RMS) voltage measurement from
+ channel Y. Units after application of scale and offset are
+ millivolts.
What: /sys/bus/iio/devices/iio:deviceX/in_powerY_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_powerY_active_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_powerY_reactive_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_powerY_apparent_raw
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
@@ -189,6 +187,13 @@ Description:
unique to allow association with event codes. Units after
application of scale and offset are milliwatts.
+What: /sys/bus/iio/devices/iio:deviceX/in_powerY_powerfactor
+KernelVersion: 6.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ Power factor measurement from channel Y. Power factor is the
+ ratio of active power to apparent power. The value is unitless.
+
What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
KernelVersion: 3.2
Contact: linux-iio@vger.kernel.org
@@ -196,7 +201,7 @@ Description:
Raw capacitance measurement from channel Y. Units after
application of scale and offset are nanofarads.
-What: /sys/.../iio:deviceX/in_capacitanceY-in_capacitanceZ_raw
+What: /sys/.../iio:deviceX/in_capacitanceY-capacitanceZ_raw
KernelVersion: 3.2
Contact: linux-iio@vger.kernel.org
Description:
@@ -207,8 +212,27 @@ Description:
is required is a consistent labeling. Units after application
of scale and offset are nanofarads.
+What: /sys/.../iio:deviceX/in_capacitanceY-capacitanceZ_zeropoint
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ For differential channels, this an offset that is applied
+ equally to both inputs. As the reading is of the difference
+ between the two inputs, this should not be applied to the _raw
+ reading by userspace (unlike _offset) and unlike calibbias
+ it does not affect the differential value measured because
+ the effect of _zeropoint cancels out across the two inputs
+ that make up the differential pair. It's purpose is to bring
+ the individual signals, before the differential is measured,
+ within the measurement range of the device. The naming is
+ chosen because if the separate inputs that make the
+ differential pair are drawn on a graph in their
+ _raw units, this is the value that the zero point on the
+ measurement axis represents. It is expressed with the
+ same scaling as _raw.
+
What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_tempY_raw
What: /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_temp_ambient_raw
@@ -224,7 +248,8 @@ Description:
less measurements. Units after application of scale and offset
are milli degrees Celsius.
-What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input
+What: /sys/bus/iio/devices/iio:deviceX/in_tempY_input
+What: /sys/bus/iio/devices/iio:deviceX/in_temp_input
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
@@ -241,6 +266,15 @@ Description:
Has all of the equivalent parameters as per voltageY. Units
after application of scale and offset are m/s^2.
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_linear_x_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_linear_y_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_linear_z_raw
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ As per in_accel_X_raw attributes, but minus the
+ acceleration due to gravity.
+
What: /sys/bus/iio/devices/iio:deviceX/in_gravity_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_gravity_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_gravity_z_raw
@@ -251,6 +285,35 @@ Description:
but should match other such assignments on device).
Units after application of scale and offset are m/s^2.
+What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_x_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_y_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_z_raw
+KernelVersion: 6.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ Angular displacement between two consecutive samples on x, y or
+ z (may be arbitrarily assigned but should match other such
+ assignments on device).
+ In order to compute the total angular displacement during a
+ desired period of time, the application should sum-up the delta
+ angle samples acquired during that time.
+ Units after application of scale and offset are radians.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_x_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_y_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_z_raw
+KernelVersion: 6.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ The linear velocity change between two consecutive samples on x,
+ y or z (may be arbitrarily assigned but should match other such
+ assignments on device).
+ In order to compute the total linear velocity change during a
+ desired period of time, the application should sum-up the delta
+ velocity samples acquired during that time.
+ Units after application of scale and offset are meters per
+ second.
+
What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
KernelVersion: 4.17
@@ -305,10 +368,21 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_peak_raw
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_peak_raw
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_peak_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_peak_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_temp_peak_raw
KernelVersion: 2.6.36
Contact: linux-iio@vger.kernel.org
Description:
- Highest value since some reset condition. These
+ Highest value since some reset condition. These
+ attributes allow access to this and are otherwise
+ the direct equivalent of the <type>Y[_name]_raw attributes.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_trough_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_temp_trough_raw
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Lowest value since some reset condition. These
attributes allow access to this and are otherwise
the direct equivalent of the <type>Y[_name]_raw attributes.
@@ -347,11 +421,11 @@ Contact: linux-iio@vger.kernel.org
Description:
Scaled humidity measurement in milli percent.
-What: /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_Y_mean_raw
KernelVersion: 3.5
Contact: linux-iio@vger.kernel.org
Description:
- Averaged raw measurement from channel X. The number of values
+ Averaged raw measurement from channel Y. The number of values
used for averaging is device specific. The converting rules for
normal raw values also applies to the averaged raw values.
@@ -359,18 +433,14 @@ What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_q_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_current_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_currentY_i_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_currentY_q_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_current_q_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_current_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
@@ -379,7 +449,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
What: /sys/bus/iio/devices/iio:deviceX/in_magn_offset
What: /sys/bus/iio/devices/iio:deviceX/in_rot_offset
What: /sys/bus/iio/devices/iio:deviceX/in_angl_offset
-What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceX_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_offset
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -398,21 +468,15 @@ Description:
to the _raw output.
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_scale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_current_scale
-What: /sys/bus/iio/devices/iio:deviceX/in_currentY_i_scale
-What: /sys/bus/iio/devices/iio:deviceX/in_currentY_q_scale
-What: /sys/bus/iio/devices/iio:deviceX/in_current_i_scale
What: /sys/bus/iio/devices/iio:deviceX/in_current_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
@@ -433,10 +497,15 @@ What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
What: /sys/bus/iio/devices/iio:deviceX/in_countY_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_scale
What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_z_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
@@ -452,13 +521,27 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_i_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_q_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_capacitance_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias
-What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
-What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_intensityY_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_proximity_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_resistance_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/out_currentY_calibbias
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_calibbias
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -470,6 +553,10 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available
+What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibbias_available
+What: /sys/bus/iio/devices/iio:deviceX/in_proximity_calibbias_available
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibbias_available
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_calibbias_available
KernelVersion: 5.8
Contact: linux-iio@vger.kernel.org
Description:
@@ -478,25 +565,54 @@ Description:
- a small discrete set of values like "0 2 4 6 8"
- a range specified as "[min step max]"
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_convdelay
+KernelVersion: 6.17
+Contact: linux-iio@vger.kernel.org
+Description:
+ Delay of start of conversion from common reference point shared
+ by all channels. Can be writable when used to compensate for
+ delay variation introduced by external filters feeding a
+ simultaneous sampling ADC.
+
+ E.g., for the ad7606 ADC series, this value is intended as a
+ configurable time delay in seconds, to correct delay introduced
+ by an optional external filtering circuit.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_convdelay_available
+KernelVersion: 6.16
+Contact: linux-iio@vger.kernel.org
+Description:
+ Available values of convdelay. Maybe expressed as:
+
+ - a range specified as "[min step max]"
+
+ If shared across all channels, <type>_convdelay_available
+ is used.
+
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_capacitance_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_intensity_both_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_intensity_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ir_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale
-What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/out_currentY_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_calibscale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -504,6 +620,20 @@ Description:
production inaccuracies). If shared across all channels,
<type>_calibscale is used.
+What: /sys/bus/iio/devices/iio:deviceX/in_illuminanceY_calibscale_available
+What: /sys/bus/iio/devices/iio:deviceX/in_intensityY_calibscale_available
+What: /sys/bus/iio/devices/iio:deviceX/in_proximityY_calibscale_available
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale_available
+KernelVersion: 4.8
+Contact: linux-iio@vger.kernel.org
+Description:
+ Available values of calibscale. Maybe expressed as either of:
+
+ - a small discrete set of values like "1 8 16"
+ - a range specified as "[min step max]"
+
+ If shared across all channels, <type>_calibscale_available is used.
+
What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
@@ -548,10 +678,10 @@ What: /sys/.../iio:deviceX/in_magn_scale_available
What: /sys/.../iio:deviceX/in_illuminance_scale_available
What: /sys/.../iio:deviceX/in_intensity_scale_available
What: /sys/.../iio:deviceX/in_proximity_scale_available
-What: /sys/.../iio:deviceX/in_voltageX_scale_available
+What: /sys/.../iio:deviceX/in_voltageY_scale_available
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
-What: /sys/.../iio:deviceX/out_voltageX_scale_available
-What: /sys/.../iio:deviceX/out_altvoltageX_scale_available
+What: /sys/.../iio:deviceX/out_voltageY_scale_available
+What: /sys/.../iio:deviceX/out_altvoltageY_scale_available
What: /sys/.../iio:deviceX/in_capacitance_scale_available
What: /sys/.../iio:deviceX/in_pressure_scale_available
What: /sys/.../iio:deviceX/in_pressureY_scale_available
@@ -559,7 +689,9 @@ KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
If a discrete set of scale values is available, they
- are listed in this attribute.
+ are listed in this attribute. Unlike illumination,
+ multiplying intensity by intensity_scale does not
+ yield value with any standardized unit.
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_hardwaregain
@@ -567,6 +699,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_hardwaregain
+What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_hardwaregain
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -634,7 +767,10 @@ Description:
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
2.5kohm_to_gnd: connected to ground via a 2.5kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
+ 7.7kohm_to_gnd: connected to ground via a 7.7kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
+ 32kohm_to_gnd: connected to ground via a 32kOhm resistor,
+ 42kohm_to_gnd: connected to ground via a 42kOhm resistor,
90kohm_to_gnd: connected to ground via a 90kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
125kohm_to_gnd: connected to ground via an 125kOhm resistor,
@@ -695,7 +831,11 @@ Description:
all the other channels, since it involves changing the VCO
fundamental output frequency.
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_i_phase
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_q_phase
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_i_phase
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_q_phase
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
@@ -758,6 +898,7 @@ What: /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_capacitanceY_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_capacitanceY_thresh_falling_en
+What: /sys/.../iio:deviceX/events/in_pressure_thresh_rising_en
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -786,6 +927,7 @@ What: /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en
What: /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en
What: /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en
What: /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en
+What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en
What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_rising_en
What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_falling_en
What: /sys/.../iio:deviceX/events/in_anglvel_y_roc_rising_en
@@ -861,6 +1003,7 @@ Description:
to the raw signal, allowing slow tracking to resume and the
adaptive threshold event detection to function as expected.
+What: /sys/.../events/in_accel_mag_adaptive_rising_value
What: /sys/.../events/in_accel_thresh_rising_value
What: /sys/.../events/in_accel_thresh_falling_value
What: /sys/.../events/in_accel_x_raw_thresh_rising_value
@@ -905,6 +1048,7 @@ What: /sys/.../events/in_capacitanceY_thresh_rising_value
What: /sys/.../events/in_capacitanceY_thresh_falling_value
What: /sys/.../events/in_capacitanceY_thresh_adaptive_rising_value
What: /sys/.../events/in_capacitanceY_thresh_falling_rising_value
+What: /sys/.../events/in_pressure_thresh_rising_value
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -1007,6 +1151,7 @@ Description:
will get activated once in_voltage0_raw goes above 1200 and will become
deactivated again once the value falls below 1150.
+What: /sys/.../events/in_accel_roc_rising_value
What: /sys/.../events/in_accel_x_raw_roc_rising_value
What: /sys/.../events/in_accel_x_raw_roc_falling_value
What: /sys/.../events/in_accel_y_raw_roc_rising_value
@@ -1053,6 +1198,8 @@ Description:
value is in raw device units or in processed units (as _raw
and _input do on sysfs direct channel read attributes).
+What: /sys/.../events/in_accel_mag_adaptive_rising_period
+What: /sys/.../events/in_accel_roc_rising_period
What: /sys/.../events/in_accel_x_thresh_rising_period
What: /sys/.../events/in_accel_x_thresh_falling_period
What: /sys/.../events/in_accel_x_roc_rising_period
@@ -1222,6 +1369,15 @@ Description:
number or direction is not specified, applies to all channels of
this type.
+What: /sys/.../iio:deviceX/events/in_accel_x_mag_adaptive_rising_en
+What: /sys/.../iio:deviceX/events/in_accel_y_mag_adaptive_rising_en
+What: /sys/.../iio:deviceX/events/in_accel_z_mag_adaptive_rising_en
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Similar to in_accel_x_thresh[_rising|_falling]_en, but here the
+ magnitude of the channel is compared to the adaptive threshold.
+
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_en
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_en
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_en
@@ -1304,6 +1460,12 @@ Description:
What: /sys/.../iio:deviceX/bufferY/in_accel_x_en
What: /sys/.../iio:deviceX/bufferY/in_accel_y_en
What: /sys/.../iio:deviceX/bufferY/in_accel_z_en
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_en
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_en
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_en
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_en
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_en
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_en
@@ -1318,10 +1480,6 @@ What: /sys/.../iio:deviceX/bufferY/in_timestamp_en
What: /sys/.../iio:deviceX/bufferY/in_voltageY_supply_en
What: /sys/.../iio:deviceX/bufferY/in_voltageY_en
What: /sys/.../iio:deviceX/bufferY/in_voltageY-voltageZ_en
-What: /sys/.../iio:deviceX/bufferY/in_voltageY_i_en
-What: /sys/.../iio:deviceX/bufferY/in_voltageY_q_en
-What: /sys/.../iio:deviceX/bufferY/in_voltage_i_en
-What: /sys/.../iio:deviceX/bufferY/in_voltage_q_en
What: /sys/.../iio:deviceX/bufferY/in_incli_x_en
What: /sys/.../iio:deviceX/bufferY/in_incli_y_en
What: /sys/.../iio:deviceX/bufferY/in_pressureY_en
@@ -1334,16 +1492,14 @@ Description:
Scan element control for triggered data capture.
What: /sys/.../iio:deviceX/bufferY/in_accel_type
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_type
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_type
What: /sys/.../iio:deviceX/bufferY/in_anglvel_type
What: /sys/.../iio:deviceX/bufferY/in_magn_type
What: /sys/.../iio:deviceX/bufferY/in_incli_type
What: /sys/.../iio:deviceX/bufferY/in_voltageY_type
What: /sys/.../iio:deviceX/bufferY/in_voltage_type
What: /sys/.../iio:deviceX/bufferY/in_voltageY_supply_type
-What: /sys/.../iio:deviceX/bufferY/in_voltageY_i_type
-What: /sys/.../iio:deviceX/bufferY/in_voltageY_q_type
-What: /sys/.../iio:deviceX/bufferY/in_voltage_i_type
-What: /sys/.../iio:deviceX/bufferY/in_voltage_q_type
What: /sys/.../iio:deviceX/bufferY/in_timestamp_type
What: /sys/.../iio:deviceX/bufferY/in_pressureY_type
What: /sys/.../iio:deviceX/bufferY/in_pressure_type
@@ -1381,13 +1537,15 @@ Description:
What: /sys/.../iio:deviceX/bufferY/in_voltageY_index
What: /sys/.../iio:deviceX/bufferY/in_voltageY_supply_index
-What: /sys/.../iio:deviceX/bufferY/in_voltageY_i_index
-What: /sys/.../iio:deviceX/bufferY/in_voltageY_q_index
-What: /sys/.../iio:deviceX/bufferY/in_voltage_i_index
-What: /sys/.../iio:deviceX/bufferY/in_voltage_q_index
What: /sys/.../iio:deviceX/bufferY/in_accel_x_index
What: /sys/.../iio:deviceX/bufferY/in_accel_y_index
What: /sys/.../iio:deviceX/bufferY/in_accel_z_index
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_index
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_index
+What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_index
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_index
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_index
+What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_index
@@ -1433,7 +1591,7 @@ Description:
This attribute is used to read the amount of quadrature error
present in the device at a given time.
-What: /sys/.../iio:deviceX/in_accelX_power_mode
+What: /sys/.../iio:deviceX/in_accelY_power_mode
KernelVersion: 3.11
Contact: linux-iio@vger.kernel.org
Description:
@@ -1445,6 +1603,9 @@ Description:
What: /sys/.../iio:deviceX/in_energy_input
What: /sys/.../iio:deviceX/in_energy_raw
+What: /sys/.../iio:deviceX/in_energyY_active_raw
+What: /sys/.../iio:deviceX/in_energyY_reactive_raw
+What: /sys/.../iio:deviceX/in_energyY_apparent_raw
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
@@ -1501,7 +1662,13 @@ What: /sys/.../iio:deviceX/in_intensityY_raw
What: /sys/.../iio:deviceX/in_intensityY_ir_raw
What: /sys/.../iio:deviceX/in_intensityY_both_raw
What: /sys/.../iio:deviceX/in_intensityY_uv_raw
+What: /sys/.../iio:deviceX/in_intensityY_uva_raw
+What: /sys/.../iio:deviceX/in_intensityY_uvb_raw
What: /sys/.../iio:deviceX/in_intensityY_duv_raw
+What: /sys/.../iio:deviceX/in_intensity_red_raw
+What: /sys/.../iio:deviceX/in_intensity_green_raw
+What: /sys/.../iio:deviceX/in_intensity_blue_raw
+What: /sys/.../iio:deviceX/in_intensity_clear_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
@@ -1509,8 +1676,9 @@ Description:
that measurements contain visible and infrared light
components or just infrared light, respectively. Modifier
uv indicates that measurements contain ultraviolet light
- components. Modifier duv indicates that measurements
- contain deep ultraviolet light components.
+ components. Modifiers uva, uvb and duv indicate that
+ measurements contain A, B or deep (C) ultraviolet light
+ components respectively.
What: /sys/.../iio:deviceX/in_uvindex_input
KernelVersion: 4.6
@@ -1559,22 +1727,31 @@ Description:
Raw value of rotation from true/magnetic north measured with
or without compensation from tilt sensors.
-What: /sys/bus/iio/devices/iio:deviceX/in_currentX_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_currentX_i_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_currentX_q_raw
-KernelVersion: 3.18
+What: /sys/bus/iio/devices/iio:deviceX/in_currentY_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_raw
+KernelVersion: 3.17
Contact: linux-iio@vger.kernel.org
Description:
- Raw current measurement from channel X. Units are in milliamps
+ Raw current measurement from channel Y. Units are in milliamps
after application of scale and offset. If no offset or scale is
present, output should be considered as processed with the
- unit in milliamps.
+ unit in milliamps. In special cases where the channel does not
+ correspond to externally available input one of the named
+ versions may be used.
Channels with 'i' and 'q' modifiers always exist in pairs and both
channels refer to the same signal. The 'i' channel contains the in-phase
component of the signal while the 'q' channel contains the quadrature
component.
+What: /sys/bus/iio/devices/iio:deviceX/in_altcurrentY_rms_raw
+KernelVersion: 6.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled no bias removal etc.) Root Mean Square (RMS) current
+ measurement from channel Y. Units after application of scale and
+ offset are milliamps.
+
What: /sys/.../iio:deviceX/in_energy_en
What: /sys/.../iio:deviceX/in_distance_en
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_en
@@ -1732,9 +1909,9 @@ Description:
hardware fifo watermark level.
What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibemissivity
-What: /sys/bus/iio/devices/iio:deviceX/in_tempX_calibemissivity
+What: /sys/bus/iio/devices/iio:deviceX/in_tempY_calibemissivity
What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_calibemissivity
-What: /sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibemissivity
+What: /sys/bus/iio/devices/iio:deviceX/in_tempY_object_calibemissivity
KernelVersion: 4.1
Contact: linux-iio@vger.kernel.org
Description:
@@ -1755,17 +1932,17 @@ Description:
is considered as one sample for <type>[_name]_sampling_frequency.
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_co2_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_ethanol_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_ethanol_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_ethanol_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_h2_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_h2_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_h2_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_o2_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_o2_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_o2_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationY_voc_raw
KernelVersion: 4.3
Contact: linux-iio@vger.kernel.org
Description:
@@ -1773,14 +1950,14 @@ Description:
after application of scale and offset are percents.
What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
-What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_resistanceY_raw
What: /sys/bus/iio/devices/iio:deviceX/out_resistance_raw
-What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
+What: /sys/bus/iio/devices/iio:deviceX/out_resistanceY_raw
KernelVersion: 4.3
Contact: linux-iio@vger.kernel.org
Description:
- Raw (unscaled no offset etc.) resistance reading that can be processed
- into an ohm value.
+ Raw (unscaled no offset etc.) resistance reading.
+ Units after application of scale and offset are ohms.
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
KernelVersion: 4.1.0
@@ -1866,8 +2043,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_electricalconductivity_raw
KernelVersion: 4.8
Contact: linux-iio@vger.kernel.org
Description:
- Raw (unscaled no offset etc.) electric conductivity reading that
- can be processed to siemens per meter.
+ Raw (unscaled no offset etc.) electric conductivity reading.
+ Units after application of scale and offset are siemens per
+ meter.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_raw
KernelVersion: 4.10
@@ -1923,8 +2101,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
- Raw (unscaled) phase difference reading from channel Y
- that can be processed to radians.
+ Raw (unscaled) phase difference reading from channel Y.
+ Units after application of scale and offset are radians.
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input
@@ -1963,7 +2141,7 @@ Description:
One of the following thermocouple types: B, E, J, K, N, R, S, T.
What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_calibambient
-What: /sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibambient
+What: /sys/bus/iio/devices/iio:deviceX/in_tempY_object_calibambient
KernelVersion: 5.10
Contact: linux-iio@vger.kernel.org
Description:
@@ -2038,3 +2216,245 @@ Description:
Available range for the forced calibration value, expressed as:
- a range specified as "[min step max]"
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sampling_frequency
+What: /sys/bus/iio/devices/iio:deviceX/in_powerY_sampling_frequency
+What: /sys/bus/iio/devices/iio:deviceX/in_currentY_sampling_frequency
+KernelVersion: 5.20
+Contact: linux-iio@vger.kernel.org
+Description:
+ Some devices have separate controls of sampling frequency for
+ individual channels. If multiple channels are enabled in a scan,
+ then the sampling_frequency of the scan may be computed from the
+ per channel sampling frequencies.
+
+What: /sys/.../events/in_accel_gesture_singletap_en
+What: /sys/.../events/in_accel_gesture_doubletap_en
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Device generates an event on a single or double tap.
+
+What: /sys/.../events/in_accel_gesture_singletap_value
+What: /sys/.../events/in_accel_gesture_doubletap_value
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Specifies the threshold value that the device is comparing
+ against to generate the tap gesture event. The lower
+ threshold value increases the sensitivity of tap detection.
+ Units and the exact meaning of value are device-specific.
+
+What: /sys/.../events/in_accel_gesture_tap_value_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Lists all available threshold values which can be used to
+ modify the sensitivity of the tap detection.
+
+What: /sys/.../events/in_accel_gesture_singletap_reset_timeout
+What: /sys/.../events/in_accel_gesture_doubletap_reset_timeout
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Specifies the timeout value in seconds for the tap detector
+ to not to look for another tap event after the event as
+ occurred. Basically the minimum quiet time between the two
+ single-tap's or two double-tap's.
+
+What: /sys/.../events/in_accel_gesture_tap_reset_timeout_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Lists all available tap reset timeout values. Units in seconds.
+
+What: /sys/.../events/in_accel_gesture_doubletap_tap2_min_delay
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Specifies the minimum quiet time in seconds between the two
+ taps of a double tap.
+
+What: /sys/.../events/in_accel_gesture_doubletap_tap2_min_delay_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Lists all available delay values between two taps in the double
+ tap. Units in seconds.
+
+What: /sys/.../events/in_accel_gesture_tap_maxtomin_time
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Specifies the maximum time difference allowed between upper
+ and lower peak of tap to consider it as the valid tap event.
+ Units in seconds.
+
+What: /sys/.../events/in_accel_gesture_tap_maxtomin_time_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Lists all available time values between upper peak to lower
+ peak. Units in seconds.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_rot_yaw_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_rot_pitch_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_rot_roll_raw
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled) euler angles readings. Units after
+ application of scale are deg.
+
+What: /sys/bus/iio/devices/iio:deviceX/serialnumber
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ An example format is 16-bytes, 2-digits-per-byte, HEX-string
+ representing the sensor unique ID number.
+
+What: /sys/bus/iio/devices/iio:deviceX/filter_type_available
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_filter_type_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns a list with the possible filter modes. Options
+ for the attribute:
+
+ * "none" - Filter is disabled/bypassed.
+ * "sinc1" - The digital sinc1 filter. Fast 1st
+ conversion time. Poor noise performance.
+ * "sinc3" - The digital sinc3 filter. Moderate 1st
+ conversion time. Good noise performance.
+ * "sinc3+pf1" - Sinc3 + device specific Post Filter 1.
+ * "sinc3+pf2" - Sinc3 + device specific Post Filter 2.
+ * "sinc3+pf3" - Sinc3 + device specific Post Filter 3.
+ * "sinc3+pf4" - Sinc3 + device specific Post Filter 4.
+ * "sinc3+rej60" - Sinc3 + 60Hz rejection.
+ * "sinc3+sinc1" - Sinc3 + averaging by 8. Low 1st conversion
+ time.
+ * "sinc4" - Sinc 4. Excellent noise performance. Long
+ 1st conversion time.
+ * "sinc4+lp" - Sinc4 + Low Pass Filter.
+ * "sinc4+sinc1" - Sinc4 + averaging by 8. Low 1st conversion
+ time.
+ * "sinc4+rej60" - Sinc4 + 60Hz rejection.
+ * "sinc5" - The digital sinc5 filter. Excellent noise
+ performance
+ * "sinc5+avg" - Sinc5 + averaging by 4.
+ * "sinc5+pf1" - Sinc5 + device specific Post Filter 1.
+ * "sinc5+sinc1" - Sinc5 + Sinc1.
+ * "sinc5+sinc1+pf1" - Sinc5 + Sinc1 + device specific Post Filter 1.
+ * "sinc5+sinc1+pf2" - Sinc5 + Sinc1 + device specific Post Filter 2.
+ * "sinc5+sinc1+pf3" - Sinc5 + Sinc1 + device specific Post Filter 3.
+ * "sinc5+sinc1+pf4" - Sinc5 + Sinc1 + device specific Post Filter 4.
+ * "wideband" - filter with wideband low ripple passband
+ and sharp transition band.
+
+What: /sys/bus/iio/devices/iio:deviceX/filter_type
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_filter_type
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Specifies which filter type apply to the channel. The possible
+ values are given by the filter_type_available attribute.
+
+What: /sys/.../events/in_proximity_thresh_either_runningperiod
+KernelVersion: 6.6
+Contact: linux-iio@vger.kernel.org
+Description:
+ A running period of time (in seconds) for which
+ in_proximity_thresh_either_runningcount amount of conditions
+ must occur before an event is generated. If direction is not
+ specified then this period applies to both directions.
+
+What: /sys/.../events/in_proximity_thresh_either_runningcount
+KernelVersion: 6.6
+Contact: linux-iio@vger.kernel.org
+Description:
+ Number of conditions that must occur, during a running
+ period, before an event is generated.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_colortemp_raw
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Represents light color temperature, which measures light color
+ temperature in Kelvin.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_x_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_y_raw
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ The x and y light color coordinate on the CIE 1931 chromaticity
+ diagram.
+
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_either_label
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_rising_label
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_falling_label
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_rising_label
+What: /sys/bus/iio/devices/iio:deviceX/events/in_anglvelY_mag_rising_label
+What: /sys/bus/iio/devices/iio:deviceX/events/in_anglY_thresh_rising_label
+What: /sys/bus/iio/devices/iio:deviceX/events/in_phaseY_mag_rising_label
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Optional symbolic label to a device channel event.
+ If a label is defined for this event add that to the event
+ specific attributes. This is useful for userspace to be able to
+ better identify an individual event.
+
+What: /sys/.../events/in_accel_gesture_tap_wait_timeout
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Enable tap gesture confirmation with timeout.
+
+What: /sys/.../events/in_accel_gesture_tap_wait_dur
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Timeout value in seconds for tap gesture confirmation.
+
+What: /sys/.../events/in_accel_gesture_tap_wait_dur_available
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of available timeout value for tap gesture confirmation.
+
+What: /sys/.../iio:deviceX/in_shunt_resistor
+What: /sys/.../iio:deviceX/in_current_shunt_resistor
+What: /sys/.../iio:deviceX/in_power_shunt_resistor
+KernelVersion: 6.10
+Contact: linux-iio@vger.kernel.org
+Description:
+ The value of current sense resistor in Ohms.
+
+What: /sys/.../iio:deviceX/in_attention_input
+KernelVersion: 6.13
+Contact: linux-iio@vger.kernel.org
+Description:
+ Value representing the user's attention to the system expressed
+ in units as percentage. This usually means if the user is
+ looking at the screen or not.
+
+What: /sys/.../events/in_accel_value_available
+KernelVersion: 6.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of available threshold values for acceleration event
+ generation. Applies to all event types on in_accel channels.
+ Units after application of scale and offset are m/s^2.
+ Expressed as:
+
+ - a range specified as "[min step max]"
+
+What: /sys/.../events/in_accel_period_available
+KernelVersion: 6.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of available periods for accelerometer event detection in
+ seconds, expressed as:
+
+ - a range specified as "[min step max]"
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-ad9739a b/Documentation/ABI/testing/sysfs-bus-iio-ad9739a
new file mode 100644
index 000000000000..ed59299e6f8d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-ad9739a
@@ -0,0 +1,19 @@
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_operating_mode
+KernelVersion: 6.9
+Contact: linux-iio@vger.kernel.org
+Description:
+ DAC operating mode. One of the following modes can be selected:
+
+ * normal: This is DAC normal mode.
+ * mixed-mode: In this mode the output is effectively chopped at
+ the DAC sample rate. This has the effect of
+ reducing the power of the fundamental signal while
+ increasing the power of the images centered around
+ the DAC sample rate, thus improving the output
+ power of these images.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_operating_mode_available
+KernelVersion: 6.9
+Contact: linux-iio@vger.kernel.org
+Description:
+ Available operating modes.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta
new file mode 100644
index 000000000000..a5a8a579f4f3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad-sigma-delta
@@ -0,0 +1,23 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sys_calibration
+KernelVersion: 5.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute, if available, initiates the system calibration procedure. This is done on a
+ single channel at a time. Write '1' to start the calibration.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sys_calibration_mode_available
+KernelVersion: 5.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute, if available, returns a list with the possible calibration modes.
+ There are two available options:
+ "zero_scale" - calibrate to zero scale
+ "full_scale" - calibrate to full scale
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sys_calibration_mode
+KernelVersion: 5.5
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute, if available, sets up the calibration mode used in the system calibration
+ procedure. Reading returns the current calibration mode.
+ Writing sets the system calibration mode.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4130 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4130
new file mode 100644
index 000000000000..d3fad27421d6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4130
@@ -0,0 +1,20 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_filter_mode_available
+KernelVersion: 6.2
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns a list with the possible filter modes.
+
+ This ABI is only kept for backwards compatibility and the values
+ returned are identical to filter_type_available attribute
+ documented in Documentation/ABI/testing/sysfs-bus-iio. Please,
+ use filter_type_available like ABI to provide filter options for
+ new drivers.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_filter_mode
+KernelVersion: 6.2
+Contact: linux-iio@vger.kernel.org
+Description:
+ This ABI is only kept for backwards compatibility and the values
+ returned are identical to in_voltageY-voltageZ_filter_type
+ attribute documented in Documentation/ABI/testing/sysfs-bus-iio.
+ Please, use in_voltageY-voltageZ_filter_type for new drivers.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
index f8315202c8f0..28be1cabf112 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
@@ -19,33 +19,9 @@ Description:
the bridge can be disconnected (when it is not being used
using the bridge_switch_en attribute.
-What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration
-KernelVersion:
-Contact: linux-iio@vger.kernel.org
-Description:
- Initiates the system calibration procedure. This is done on a
- single channel at a time. Write '1' to start the calibration.
-
What: /sys/bus/iio/devices/iio:deviceX/in_voltage2-voltage2_shorted_raw
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Measure voltage from AIN2 pin connected to AIN(+)
and AIN(-) shorted.
-
-What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode_available
-KernelVersion:
-Contact: linux-iio@vger.kernel.org
-Description:
- Reading returns a list with the possible calibration modes.
- There are two available options:
- "zero_scale" - calibrate to zero scale
- "full_scale" - calibrate to full scale
-
-What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode
-KernelVersion:
-Contact: linux-iio@vger.kernel.org
-Description:
- Sets up the calibration mode used in the system calibration
- procedure. Reading returns the current calibration mode.
- Writing sets the system calibration mode.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max11410 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max11410
new file mode 100644
index 000000000000..2a53c6b37360
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-max11410
@@ -0,0 +1,13 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage_filterY_notch_en
+Date: September 2022
+KernelVersion: 6.0
+Contact: linux-iio@vger.kernel.org
+Description:
+ Enable or disable a notch filter.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_voltage_filterY_notch_center
+Date: September 2022
+KernelVersion: 6.0
+Contact: linux-iio@vger.kernel.org
+Description:
+ Center frequency of the notch filter in Hz.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
deleted file mode 100644
index 6d2d2b094941..000000000000
--- a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
+++ /dev/null
@@ -1,17 +0,0 @@
-What: /sys/bus/iio/devices/iio:deviceX/in_power_shunt_resistor
-Date: March 2017
-KernelVersion: 4.12
-Contact: linux-iio@vger.kernel.org
-Description: The value of the shunt resistor used to compute power drain on
- common input voltage pin (RS+). In Ohms.
-
-What: /sys/bus/iio/devices/iio:deviceX/in_current_shunt_resistor
-Date: March 2017
-KernelVersion: 4.12
-Contact: linux-iio@vger.kernel.org
-Description: The value of the shunt resistor used to compute current flowing
- between RS+ and RS- voltage sense inputs. In Ohms.
-
-These attributes describe a single physical component, exposed as two distinct
-attributes as it is used to calculate two different values: power load and
-current flowing between RS+ and RS- inputs.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564 b/Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564
new file mode 100644
index 000000000000..b168aa44b233
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564
@@ -0,0 +1,53 @@
+What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute is used to set the gain of the biasing current
+ circuit of the Delta-Sigma modulator. The different BOOST
+ settings are applied to the entire modulator circuit, including
+ the voltage reference buffers.
+
+What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain_available
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns a list with the possible gain values for
+ the current biasing circuit of the Delta-Sigma modulator.
+
+What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_mux_enable
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute is used to enable the analog input multiplexer
+ auto-zeroing algorithm (the input multiplexer and the ADC
+ include an offset cancellation algorithm that cancels the offset
+ contribution of the ADC). When the offset cancellation algorithm
+ is enabled, ADC takes two conversions, one with the differential
+ input as VIN+/VIN-, one with VIN+/VIN- inverted. In this case the
+ conversion time is multiplied by two compared to the default
+ case where the algorithm is disabled. This technique allows the
+ cancellation of the ADC offset error and the achievement of
+ ultra-low offset without any digital calibration. The resulting
+ offset is the residue of the difference between the two
+ conversions, which is on the order of magnitude of the noise
+ floor. This offset is effectively canceled at every conversion,
+ so the residual offset error temperature drift is extremely low.
+ Write '1' to enable it, write '0' to disable it.
+
+What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_ref_enable
+KernelVersion: 6.4
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute is used to enable the chopping algorithm for the
+ internal voltage reference buffer. This setting has no effect
+ when external voltage reference is selected.
+ Internal voltage reference buffer injects a certain quantity of
+ 1/f noise into the system that can be modulated with the
+ incoming input signals and can limit the SNR performance at
+ higher Oversampling Ratio values (over 256). To overcome this
+ limitation, the buffer includes an auto-zeroing algorithm that
+ greatly reduces (cancels out) the 1/f noise and cancels the
+ offset value of the reference buffer. As a result, the SNR of
+ the system is not affected by this 1/f noise component of the
+ reference buffer, even at maximum oversampling ratio values.
+ Write '1' to enable it, write '0' to disable it.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934 b/Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934
new file mode 100644
index 000000000000..625b7f867847
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-pac1934
@@ -0,0 +1,9 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistorY
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ The value of the shunt resistor may be known only at runtime
+ and set by a client application. This attribute allows to
+ set its value in micro-ohms. X is the IIO index of the device.
+ Y is the channel number. The value is used to calculate
+ current, power and accumulated energy.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-bno055 b/Documentation/ABI/testing/sysfs-bus-iio-bno055
new file mode 100644
index 000000000000..f32b1644e986
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-bno055
@@ -0,0 +1,81 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_raw_range
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled) range for acceleration readings. Unit after
+ application of scale is m/s^2. Note that this doesn't affects
+ the scale (which should be used when changing the maximum and
+ minimum readable value affects also the reading scaling factor).
+
+What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_raw_range
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Range for angular velocity readings in radians per second. Note
+ that this does not affects the scale (which should be used when
+ changing the maximum and minimum readable value affects also the
+ reading scaling factor).
+
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_raw_range_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of allowed values for in_accel_raw_range attribute
+
+What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_raw_range_available
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of allowed values for in_anglvel_raw_range attribute
+
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_calibration_fast_enable
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Can be 1 or 0. Enables/disables the "Fast Magnetometer
+ Calibration" HW function.
+
+What: /sys/bus/iio/devices/iio:deviceX/fusion_enable
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Can be 1 or 0. Enables/disables the "sensor fusion" (a.k.a.
+ NDOF) HW function.
+
+What: /sys/bus/iio/devices/iio:deviceX/calibration_data
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reports the binary calibration data blob for the IMU sensors.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibration_auto_status
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reports the autocalibration status for the accelerometer sensor.
+ Can be 0 (calibration non even enabled) or 1 to 5 where the greater
+ the number, the better the calibration status.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_gyro_calibration_auto_status
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reports the autocalibration status for the gyroscope sensor.
+ Can be 0 (calibration non even enabled) or 1 to 5 where the greater
+ the number, the better the calibration status.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_magn_calibration_auto_status
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reports the autocalibration status for the magnetometer sensor.
+ Can be 0 (calibration non even enabled) or 1 to 5 where the greater
+ the number, the better the calibration status.
+
+What: /sys/bus/iio/devices/iio:deviceX/sys_calibration_auto_status
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reports the status for the IMU overall autocalibration.
+ Can be 0 (calibration non even enabled) or 1 to 5 where the greater
+ the number, the better the calibration status.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-cdc-ad7746 b/Documentation/ABI/testing/sysfs-bus-iio-cdc-ad7746
new file mode 100644
index 000000000000..02ca8941dce1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-cdc-ad7746
@@ -0,0 +1,11 @@
+What: /sys/.../iio:deviceX/in_capacitableY_calibbias_calibration
+What: /sys/.../iio:deviceX/in_capacitableY_calibscale_calibration
+KernelVersion: 6.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Write 1 to trigger a calibration of the calibbias or
+ calibscale. For calibscale, a full scale capacitance should
+ be connected to the capacitance input and a
+ calibscale_calibration then started. For calibbias see
+ the device datasheet section on "capacitive system offset
+ calibration".
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
index 469a7c00fad4..a95547e874f1 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
+++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
@@ -15,17 +15,3 @@ Description:
Set the relative humidity. This value is sent to the sensor for
humidity compensation.
Default value: 50000 (50 % relative humidity)
-
-What: /sys/bus/iio/devices/iio:deviceX/in_resistance_calibbias
-Date: August 2021
-KernelVersion: 5.15
-Contact: Andreas Klinger <ak@it-klinger.de>
-Description:
- Set the bias value for the resistance which is used for
- calculation of in_concentration_input as follows:
-
- x = (in_resistance_raw - in_resistance_calibbias) * 0.65
-
- in_concentration_input = 500 / (1 + e^x)
-
- Default value: 30000
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
index adf24c40126f..9e3926243797 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
+++ b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
@@ -7,16 +7,6 @@ Description:
corresponding calibration offsets can be read from `*_calibbias`
entries.
-What: /sys/bus/iio/devices/iio:deviceX/location
-Date: July 2015
-KernelVersion: 4.7
-Contact: linux-iio@vger.kernel.org
-Description:
- This attribute returns a string with the physical location where
- the motion sensor is placed. For example, in a laptop a motion
- sensor can be located on the base or on the lid. Current valid
- values are 'base' and 'lid'.
-
What: /sys/bus/iio/devices/iio:deviceX/id
Date: September 2017
KernelVersion: 4.14
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac b/Documentation/ABI/testing/sysfs-bus-iio-dac
new file mode 100644
index 000000000000..810eaac5533c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-dac
@@ -0,0 +1,61 @@
+What: /sys/bus/iio/devices/iio:deviceX/out_currentY_toggle_en
+KernelVersion: 5.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ Toggle enable. Write 1 to enable toggle or 0 to disable it. This
+ is useful when one wants to change the DAC output codes. For
+ autonomous toggling, the way it should be done is:
+
+ - disable toggle operation;
+ - change out_currentY_rawN, where N is the integer value of the symbol;
+ - enable toggle operation.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_currentY_rawN
+KernelVersion: 5.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute has the same meaning as out_currentY_raw. It is
+ specific to toggle enabled channels and refers to the DAC output
+ code in INPUT_N (_rawN), where N is the integer value of the symbol.
+ The same scale and offset as in out_currentY_raw applies.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_currentY_symbol
+KernelVersion: 5.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ Performs a SW switch to a predefined output symbol. This attribute
+ is specific to toggle enabled channels and allows switching between
+ multiple predefined symbols. Each symbol corresponds to a different
+ output, denoted as out_currentY_rawN, where N is the integer value
+ of the symbol. Writing an integer value N will select out_currentY_rawN.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_toggle_en
+KernelVersion: 5.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ Toggle enable. Write 1 to enable toggle or 0 to disable it. This
+ is useful when one wants to change the DAC output codes. For
+ autonomous toggling, the way it should be done is:
+
+ - disable toggle operation;
+ - change out_voltageY_rawN, where N is the integer value of the symbol;
+ - enable toggle operation.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_rawN
+KernelVersion: 5.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ This attribute has the same meaning as out_currentY_raw. It is
+ specific to toggle enabled channels and refers to the DAC output
+ code in INPUT_N (_rawN), where N is the integer value of the symbol.
+ The same scale and offset as in out_currentY_raw applies.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_symbol
+KernelVersion: 5.18
+Contact: linux-iio@vger.kernel.org
+Description:
+ Performs a SW switch to a predefined output symbol. This attribute
+ is specific to toggle enabled channels and allows switching between
+ multiple predefined symbols. Each symbol corresponds to a different
+ output, denoted as out_voltageY_rawN, where N is the integer value
+ of the symbol. Writing an integer value N will select out_voltageY_rawN.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688
index 1c35971277ba..ae95a5477382 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688
+++ b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688
@@ -53,34 +53,3 @@ KernelVersion: 5.18
Contact: linux-iio@vger.kernel.org
Description:
Returns the available values for the dither phase.
-
-What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_toggle_en
-KernelVersion: 5.18
-Contact: linux-iio@vger.kernel.org
-Description:
- Toggle enable. Write 1 to enable toggle or 0 to disable it. This is
- useful when one wants to change the DAC output codes. The way it should
- be done is:
-
- - disable toggle operation;
- - change out_voltageY_raw0 and out_voltageY_raw1;
- - enable toggle operation.
-
-What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw0
-What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw1
-KernelVersion: 5.18
-Contact: linux-iio@vger.kernel.org
-Description:
- It has the same meaning as out_voltageY_raw. This attribute is
- specific to toggle enabled channels and refers to the DAC output
- code in INPUT_A (_raw0) and INPUT_B (_raw1). The same scale and offset
- as in out_voltageY_raw applies.
-
-What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_symbol
-KernelVersion: 5.18
-Contact: linux-iio@vger.kernel.org
-Description:
- Performs a SW toggle. This attribute is specific to toggle
- enabled channels and allows to toggle between out_voltageY_raw0
- and out_voltageY_raw1 through software. Writing 0 will select
- out_voltageY_raw0 while 1 selects out_voltageY_raw1.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
index f6c035752639..c431f0a13cf5 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
+++ b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818
@@ -3,10 +3,12 @@ KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Reading this returns the valid values that can be written to the
- on_altvoltage0_mode attribute:
+ filter_mode attribute:
- auto -> Adjust bandpass filter to track changes in input clock rate.
- manual -> disable/unregister the clock rate notifier / input clock tracking.
+ - bypass -> bypass low pass filter, high pass filter and disable/unregister
+ the clock rate notifier
What: /sys/bus/iio/devices/iio:deviceX/filter_mode
KernelVersion:
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013
index de1e323e5d47..9cf8cd0dd2df 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013
+++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013
@@ -1,10 +1,10 @@
-What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0-1_i_calibphase
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0-altvoltage1_i_calibphase
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write unscaled value for the Local Oscillatior path quadrature I phase shift.
-What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0-1_q_calibphase
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0-altvoltage1_q_calibphase
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc b/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc
index 8916f7ec6507..8dbca113112d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc
+++ b/Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc
@@ -13,12 +13,3 @@ Description:
available for reading data. However, samples can be occasionally skipped
or repeated, depending on the beat between the capture and conversion
rates.
-
-What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor
-Date: December 2015
-KernelVersion: 4.4
-Contact: linux-iio@vger.kernel.org
-Description:
- The value of the shunt resistor may be known only at runtime fom an
- eeprom content read by a client application. This attribute allows to
- set its value in ohms.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-inv_icm42600 b/Documentation/ABI/testing/sysfs-bus-iio-inv_icm42600
new file mode 100644
index 000000000000..7eeacfb7650d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-inv_icm42600
@@ -0,0 +1,18 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_power_mode
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ Accelerometer power mode. Setting this attribute will set the
+ requested power mode to use if the ODR support it. If ODR
+ support only 1 mode, power mode will be enforced.
+ Reading this attribute will return the current accelerometer
+ power mode if the sensor is on, or the requested value if the
+ sensor is off. The value between real and requested value can
+ be different for ODR supporting only 1 mode.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_accel_power_mode_available
+KernelVersion: 6.11
+Contact: linux-iio@vger.kernel.org
+Description:
+ List of available accelerometer power modes that can be set in
+ in_accel_power_mode attribute.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210 b/Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210
new file mode 100644
index 000000000000..f92c79342b93
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210
@@ -0,0 +1,27 @@
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns the current Degradation of Signal Reset Maximum
+ Threshold value in millivolts. Writing sets the value.
+
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max_available
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns the allowable voltage range for
+ in_altvoltage0_mag_rising_reset_max.
+
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns the current Degradation of Signal Reset Minimum
+ Threshold value in millivolts. Writing sets the value.
+
+What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min_available
+KernelVersion: 6.7
+Contact: linux-iio@vger.kernel.org
+Description:
+ Reading returns the allowable voltage range for
+ in_altvoltage0_mag_rising_reset_min.
diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit
index e7282d184a74..ed483a11c58c 100644
--- a/Documentation/ABI/testing/sysfs-bus-nfit
+++ b/Documentation/ABI/testing/sysfs-bus-nfit
@@ -121,7 +121,7 @@ KernelVersion: v4.7
Contact: nvdimm@lists.linux.dev
Description:
(RO) ACPI specification 6.2 section 5.2.25.9, defines an
- identifier for an NVDIMM, which refelects the id attribute.
+ identifier for an NVDIMM, which reflects the id attribute.
What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor
diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm
index 1c1f5acbf53d..64eb8f4c6a41 100644
--- a/Documentation/ABI/testing/sysfs-bus-nvdimm
+++ b/Documentation/ABI/testing/sysfs-bus-nvdimm
@@ -18,10 +18,12 @@ Description: (RO) Attribute group to describe the magic bits
Each attribute under this group defines a bit range of the
perf_event_attr.config. Supported attribute is listed
below::
+
event = "config:0-4" - event ID
For example::
- ctl_res_cnt = "event=0x1"
+
+ ctl_res_cnt = "event=0x1"
What: /sys/bus/event_source/devices/nmemX/events
Date: February 2022
@@ -41,3 +43,17 @@ KernelVersion: 5.18
Contact: Kajol Jain <kjain@linux.ibm.com>
Description: (RO) This sysfs file exposes the cpumask which is designated to
to retrieve nvdimm pmu event counter data.
+
+What: /sys/bus/nd/devices/nmemX/cxl/id
+Date: November 2022
+KernelVersion: 6.2
+Contact: Dave Jiang <dave.jiang@intel.com>
+Description: (RO) Show the id (serial) of the device. This is CXL specific.
+
+What: /sys/bus/nd/devices/nmemX/cxl/provider
+Date: November 2022
+KernelVersion: 6.2
+Contact: Dave Jiang <dave.jiang@intel.com>
+Description: (RO) Shows the CXL bridge device that ties to a CXL memory device
+ to this NVDIMM device. I.e. the parent of the device returned is
+ a /sys/bus/cxl/devices/memX instance.
diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices b/Documentation/ABI/testing/sysfs-bus-optee-devices
index 0f58701367b6..af31e5a22d89 100644
--- a/Documentation/ABI/testing/sysfs-bus-optee-devices
+++ b/Documentation/ABI/testing/sysfs-bus-optee-devices
@@ -6,3 +6,12 @@ Description:
OP-TEE bus provides reference to registered drivers under this directory. The <uuid>
matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers
are free to create needed API under optee-ta-<uuid> directory.
+
+What: /sys/bus/tee/devices/optee-ta-<uuid>/need_supplicant
+Date: November 2023
+KernelVersion: 6.7
+Contact: op-tee@lists.trustedfirmware.org
+Description:
+ Allows to distinguish whether an OP-TEE based TA/device requires user-space
+ tee-supplicant to function properly or not. This attribute will be present for
+ devices which depend on tee-supplicant to be running.
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 4ac0673901e7..34ee8c59ab25 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -8,7 +8,7 @@ Description:
more bits set in the dimm-health-bitmap retrieved in
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
- at 'Documentation/powerpc/papr_hcalls.rst' . Below are
+ at 'Documentation/arch/powerpc/papr_hcalls.rst' . Below are
the flags reported in this sysfs file:
* "not_armed"
@@ -30,7 +30,7 @@ Description:
Indicating that contents of the
NVDIMM have been scrubbed.
* "locked"
- Indicating that NVDIMM contents cant
+ Indicating that NVDIMM contents can't
be modified until next power cycle.
What: /sys/bus/nd/devices/nmemX/papr/perf_stats
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 6fc2c2efe8ab..b767db2c52cb 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -163,6 +163,17 @@ Description:
will be present in sysfs. Writing 1 to this file
will perform reset.
+What: /sys/bus/pci/devices/.../reset_subordinate
+Date: October 2024
+Contact: linux-pci@vger.kernel.org
+Description:
+ This is visible only for bridge devices. If you want to reset
+ all devices attached through the subordinate bus of a specific
+ bridge device, writing 1 to this will try to do it. This will
+ affect all devices attached to the system through this bridge
+ similiar to writing 1 to their individual "reset" file, so use
+ with caution.
+
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings <bwh@kernel.org>
@@ -407,6 +418,16 @@ Description:
file contains a '1' if the memory has been published for
use outside the driver that owns the device.
+What: /sys/bus/pci/devices/.../p2pmem/allocate
+Date: August 2022
+Contact: Logan Gunthorpe <logang@deltatee.com>
+Description:
+ This file allows mapping p2pmem into userspace. For each
+ mmap() call on this file, the kernel will allocate a chunk
+ of Peer-to-Peer memory for use in Peer-to-Peer transactions.
+ This memory can be used in O_DIRECT calls to NVMe backed
+ files for Peer-to-Peer copies.
+
What: /sys/bus/pci/devices/.../link/clkpm
/sys/bus/pci/devices/.../link/l0s_aspm
/sys/bus/pci/devices/.../link/l1_aspm
@@ -457,3 +478,227 @@ Description:
The file is writable if the PF is bound to a driver that
implements ->sriov_set_msix_vec_count().
+
+What: /sys/bus/pci/devices/.../resourceN_resize
+Date: September 2022
+Contact: Alex Williamson <alex.williamson@redhat.com>
+Description:
+ These files provide an interface to PCIe Resizable BAR support.
+ A file is created for each BAR resource (N) supported by the
+ PCIe Resizable BAR extended capability of the device. Reading
+ each file exposes the bitmap of available resource sizes:
+
+ # cat resource1_resize
+ 00000000000001c0
+
+ The bitmap represents supported resource sizes for the BAR,
+ where bit0 = 1MB, bit1 = 2MB, bit2 = 4MB, etc. In the above
+ example the device supports 64MB, 128MB, and 256MB BAR sizes.
+
+ When writing the file, the user provides the bit position of
+ the desired resource size, for example:
+
+ # echo 7 > resource1_resize
+
+ This indicates to set the size value corresponding to bit 7,
+ 128MB. The resulting size is 2 ^ (bit# + 20). This definition
+ matches the PCIe specification of this capability.
+
+ In order to make use of resource resizing, all PCI drivers must
+ be unbound from the device and peer devices under the same
+ parent bridge may need to be soft removed. In the case of
+ VGA devices, writing a resize value will remove low level
+ console drivers from the device. Raw users of pci-sysfs
+ resourceN attributes must be terminated prior to resizing.
+ Success of the resizing operation is not guaranteed.
+
+What: /sys/bus/pci/devices/.../leds/*:enclosure:*/brightness
+What: /sys/class/leds/*:enclosure:*/brightness
+Date: August 2024
+KernelVersion: 6.12
+Description:
+ LED indications on PCIe storage enclosures which are controlled
+ through the NPEM interface (Native PCIe Enclosure Management,
+ PCIe r6.1 sec 6.28) are accessible as led class devices, both
+ below /sys/class/leds and below NPEM-capable PCI devices.
+
+ Although these led class devices could be manipulated manually,
+ in practice they are typically manipulated automatically by an
+ application such as ledmon(8).
+
+ The name of a led class device is as follows:
+ <bdf>:enclosure:<indication>
+ where:
+
+ - <bdf> is the domain, bus, device and function number
+ (e.g. 10000:02:05.0)
+ - <indication> is a short description of the LED indication
+
+ Valid indications per PCIe r6.1 table 6-27 are:
+
+ - ok (drive is functioning normally)
+ - locate (drive is being identified by an admin)
+ - fail (drive is not functioning properly)
+ - rebuild (drive is part of an array that is rebuilding)
+ - pfa (drive is predicted to fail soon)
+ - hotspare (drive is marked to be used as a replacement)
+ - ica (drive is part of an array that is degraded)
+ - ifa (drive is part of an array that is failed)
+ - idt (drive is not the right type for the connector)
+ - disabled (drive is disabled, removal is safe)
+ - specific0 to specific7 (enclosure-specific indications)
+
+ Broadly, the indications fall into one of these categories:
+
+ - to signify drive state (ok, locate, fail, idt, disabled)
+ - to signify drive role or state in a software RAID array
+ (rebuild, pfa, hotspare, ica, ifa)
+ - to signify any other role or state (specific0 to specific7)
+
+ Mandatory indications per PCIe r6.1 sec 7.9.19.2 comprise:
+ ok, locate, fail, rebuild. All others are optional.
+ A led class device is only visible if the corresponding
+ indication is supported by the device.
+
+ To manipulate the indications, write 0 (LED_OFF) or 1 (LED_ON)
+ to the "brightness" file. Note that manipulating an indication
+ may implicitly manipulate other indications at the vendor's
+ discretion. E.g. when the user lights up the "ok" indication,
+ the vendor may choose to automatically turn off the "fail"
+ indication. The current state of an indication can be
+ retrieved by reading its "brightness" file.
+
+ The PCIe Base Specification allows vendors leeway to choose
+ different colors or blinking patterns for the indications,
+ but they typically follow the IBPI standard. E.g. the "locate"
+ indication is usually presented as one or two LEDs blinking at
+ 4 Hz frequency:
+ https://en.wikipedia.org/wiki/International_Blinking_Pattern_Interpretation
+
+ PCI Firmware Specification r3.3 sec 4.7 defines a DSM interface
+ to facilitate shared access by operating system and platform
+ firmware to a device's NPEM registers. The kernel will use
+ this DSM interface where available, instead of accessing NPEM
+ registers directly. The DSM interface does not support the
+ enclosure-specific indications "specific0" to "specific7",
+ hence the corresponding led class devices are unavailable if
+ the DSM interface is used.
+
+What: /sys/bus/pci/devices/.../doe_features
+Date: March 2025
+Contact: Linux PCI developers <linux-pci@vger.kernel.org>
+Description:
+ This directory contains a list of the supported Data Object
+ Exchange (DOE) features. The features are the file name.
+ The contents of each file is the raw Vendor ID and data
+ object feature values.
+
+ The value comes from the device and specifies the vendor and
+ data object type supported. The lower (RHS of the colon) is
+ the data object type in hex. The upper (LHS of the colon)
+ is the vendor ID.
+
+ As all DOE devices must support the DOE discovery feature,
+ if DOE is supported you will at least see the doe_discovery
+ file, with this contents:
+
+ # cat doe_features/doe_discovery
+ 0001:00
+
+ If the device supports other features you will see other
+ files as well. For example if CMA/SPDM and secure CMA/SPDM
+ are supported the doe_features directory will look like
+ this:
+
+ # ls doe_features
+ 0001:01 0001:02 doe_discovery
+
+What: /sys/bus/pci/devices/.../serial_number
+Date: December 2025
+Contact: Matthew Wood <thepacketgeek@gmail.com>
+Description:
+ This is visible only for PCI devices that support the serial
+ number extended capability. The file is read only and due to
+ the possible sensitivity of accessible serial numbers, admin
+ only.
+
+What: /sys/bus/pci/devices/.../tsm/
+Contact: linux-coco@lists.linux.dev
+Description:
+ This directory only appears if a physical device function
+ supports authentication (PCIe CMA-SPDM), interface security
+ (PCIe TDISP), and is accepted for secure operation by the
+ platform TSM driver. This attribute directory appears
+ dynamically after the platform TSM driver loads. So, only after
+ the /sys/class/tsm/tsm0 device arrives can tools assume that
+ devices without a tsm/ attribute directory will never have one;
+ before that, the security capabilities of the device relative to
+ the platform TSM are unknown. See
+ Documentation/ABI/testing/sysfs-class-tsm.
+
+What: /sys/bus/pci/devices/.../tsm/connect
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RW) Write the name of a TSM (TEE Security Manager) device from
+ /sys/class/tsm to this file to establish a connection with the
+ device. This typically includes an SPDM (DMTF Security
+ Protocols and Data Models) session over PCIe DOE (Data Object
+ Exchange) and may also include PCIe IDE (Integrity and Data
+ Encryption) establishment. Reads from this attribute return the
+ name of the connected TSM or the empty string if not
+ connected. A TSM device signals its readiness to accept PCI
+ connection via a KOBJ_CHANGE event.
+
+What: /sys/bus/pci/devices/.../tsm/disconnect
+Contact: linux-coco@lists.linux.dev
+Description:
+ (WO) Write the name of the TSM device that was specified
+ to 'connect' to teardown the connection.
+
+What: /sys/bus/pci/devices/.../tsm/dsm
+Contact: linux-coco@lists.linux.dev
+Description: (RO) Return PCI device name of this device's DSM (Device
+ Security Manager). When a device is in the connected state it
+ indicates that the platform TSM (TEE Security Manager) has made
+ a secure-session connection with a device's DSM. A DSM is always
+ physical function 0 and when the device supports TDISP (TEE
+ Device Interface Security Protocol) its managed functions also
+ populate this tsm/dsm attribute. The managed functions of a DSM
+ are SR-IOV (Single Root I/O Virtualization) virtual functions,
+ non-zero functions of a multi-function device, or downstream
+ endpoints depending on whether the DSM is an SR-IOV physical
+ function, function0 of a multi-function device, or an upstream
+ PCIe switch port. This is a "link" TSM attribute, see
+ Documentation/ABI/testing/sysfs-class-tsm.
+
+What: /sys/bus/pci/devices/.../tsm/bound
+Contact: linux-coco@lists.linux.dev
+Description: (RO) Return the device name of the TSM when the device is in a
+ TDISP (TEE Device Interface Security Protocol) operational state
+ (LOCKED, RUN, or ERROR, not UNLOCKED). Bound devices consume
+ platform TSM resources and depend on the device's configuration
+ (e.g. BME (Bus Master Enable) and MSE (Memory Space Enable)
+ among other settings) to remain stable for the duration of the
+ bound state. This attribute is only visible for devices that
+ support TDISP operation, and it is only populated after
+ successful connect and TSM bind. The TSM bind operation is
+ initiated by VFIO/IOMMUFD. This is a "link" TSM attribute, see
+ Documentation/ABI/testing/sysfs-class-tsm.
+
+What: /sys/bus/pci/devices/.../authenticated
+Contact: linux-pci@vger.kernel.org
+Description:
+ When the device's tsm/ directory is present device
+ authentication (PCIe CMA-SPDM) and link encryption (PCIe IDE)
+ are handled by the platform TSM (TEE Security Manager). When the
+ tsm/ directory is not present this attribute reflects only the
+ native CMA-SPDM authentication state with the kernel's
+ certificate store.
+
+ If the attribute is not present, it indicates that
+ authentication is unsupported by the device, or the TSM has no
+ available authentication methods for the device.
+
+ When present and the tsm/ attribute directory is present, the
+ authenticated attribute is an alias for the device 'connect'
+ state. See the 'tsm/connect' attribute for more details.
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer
new file mode 100644
index 000000000000..5ed284523956
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer
@@ -0,0 +1,163 @@
+PCIe Device AER statistics
+--------------------------
+
+These attributes show up under all the devices that are AER capable. These
+statistical counters indicate the errors "as seen/reported by the device".
+Note that this may mean that if an endpoint is causing problems, the AER
+counters may increment at its link partner (e.g. root port) because the
+errors may be "seen" / reported by the link partner and not the
+problematic endpoint itself (which may report all counters as 0 as it never
+saw any problems).
+
+What: /sys/bus/pci/devices/<dev>/aer_dev_correctable
+Date: July 2018
+KernelVersion: 4.19.0
+Contact: linux-pci@vger.kernel.org, rajatja@google.com
+Description: List of correctable errors seen and reported by this
+ PCI device using ERR_COR. Note that since multiple errors may
+ be reported using a single ERR_COR message, thus
+ TOTAL_ERR_COR at the end of the file may not match the actual
+ total of all the errors in the file. Sample output::
+
+ localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_correctable
+ Receiver Error 2
+ Bad TLP 0
+ Bad DLLP 0
+ RELAY_NUM Rollover 0
+ Replay Timer Timeout 0
+ Advisory Non-Fatal 0
+ Corrected Internal Error 0
+ Header Log Overflow 0
+ TOTAL_ERR_COR 2
+
+What: /sys/bus/pci/devices/<dev>/aer_dev_fatal
+Date: July 2018
+KernelVersion: 4.19.0
+Contact: linux-pci@vger.kernel.org, rajatja@google.com
+Description: List of uncorrectable fatal errors seen and reported by this
+ PCI device using ERR_FATAL. Note that since multiple errors may
+ be reported using a single ERR_FATAL message, thus
+ TOTAL_ERR_FATAL at the end of the file may not match the actual
+ total of all the errors in the file. Sample output::
+
+ localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_fatal
+ Undefined 0
+ Data Link Protocol 0
+ Surprise Down Error 0
+ Poisoned TLP 0
+ Flow Control Protocol 0
+ Completion Timeout 0
+ Completer Abort 0
+ Unexpected Completion 0
+ Receiver Overflow 0
+ Malformed TLP 0
+ ECRC 0
+ Unsupported Request 0
+ ACS Violation 0
+ Uncorrectable Internal Error 0
+ MC Blocked TLP 0
+ AtomicOp Egress Blocked 0
+ TLP Prefix Blocked Error 0
+ TOTAL_ERR_FATAL 0
+
+What: /sys/bus/pci/devices/<dev>/aer_dev_nonfatal
+Date: July 2018
+KernelVersion: 4.19.0
+Contact: linux-pci@vger.kernel.org, rajatja@google.com
+Description: List of uncorrectable nonfatal errors seen and reported by this
+ PCI device using ERR_NONFATAL. Note that since multiple errors
+ may be reported using a single ERR_FATAL message, thus
+ TOTAL_ERR_NONFATAL at the end of the file may not match the
+ actual total of all the errors in the file. Sample output::
+
+ localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_nonfatal
+ Undefined 0
+ Data Link Protocol 0
+ Surprise Down Error 0
+ Poisoned TLP 0
+ Flow Control Protocol 0
+ Completion Timeout 0
+ Completer Abort 0
+ Unexpected Completion 0
+ Receiver Overflow 0
+ Malformed TLP 0
+ ECRC 0
+ Unsupported Request 0
+ ACS Violation 0
+ Uncorrectable Internal Error 0
+ MC Blocked TLP 0
+ AtomicOp Egress Blocked 0
+ TLP Prefix Blocked Error 0
+ TOTAL_ERR_NONFATAL 0
+
+PCIe Rootport AER statistics
+----------------------------
+
+These attributes show up under only the rootports (or root complex event
+collectors) that are AER capable. These indicate the number of error messages as
+"reported to" the rootport. Please note that the rootports also transmit
+(internally) the ERR_* messages for errors seen by the internal rootport PCI
+device, so these counters include them and are thus cumulative of all the error
+messages on the PCI hierarchy originating at that root port.
+
+What: /sys/bus/pci/devices/<dev>/aer_rootport_total_err_cor
+Date: July 2018
+KernelVersion: 4.19.0
+Contact: linux-pci@vger.kernel.org, rajatja@google.com
+Description: Total number of ERR_COR messages reported to rootport.
+
+What: /sys/bus/pci/devices/<dev>/aer_rootport_total_err_fatal
+Date: July 2018
+KernelVersion: 4.19.0
+Contact: linux-pci@vger.kernel.org, rajatja@google.com
+Description: Total number of ERR_FATAL messages reported to rootport.
+
+What: /sys/bus/pci/devices/<dev>/aer_rootport_total_err_nonfatal
+Date: July 2018
+KernelVersion: 4.19.0
+Contact: linux-pci@vger.kernel.org, rajatja@google.com
+Description: Total number of ERR_NONFATAL messages reported to rootport.
+
+PCIe AER ratelimits
+-------------------
+
+These attributes show up under all the devices that are AER capable.
+They represent configurable ratelimits of logs per error type.
+
+See Documentation/PCI/pcieaer-howto.rst for more info on ratelimits.
+
+What: /sys/bus/pci/devices/<dev>/aer/correctable_ratelimit_interval_ms
+Date: May 2025
+KernelVersion: 6.16.0
+Contact: linux-pci@vger.kernel.org
+Description: Writing 0 disables AER correctable error log ratelimiting.
+ Writing a positive value sets the ratelimit interval in ms.
+ Default is DEFAULT_RATELIMIT_INTERVAL (5000 ms).
+
+What: /sys/bus/pci/devices/<dev>/aer/correctable_ratelimit_burst
+Date: May 2025
+KernelVersion: 6.16.0
+Contact: linux-pci@vger.kernel.org
+Description: Ratelimit burst for correctable error logs. Writing a value
+ changes the number of errors (burst) allowed per interval
+ before ratelimiting. Reading gets the current ratelimit
+ burst. Default is DEFAULT_RATELIMIT_BURST (10).
+
+What: /sys/bus/pci/devices/<dev>/aer/nonfatal_ratelimit_interval_ms
+Date: May 2025
+KernelVersion: 6.16.0
+Contact: linux-pci@vger.kernel.org
+Description: Writing 0 disables AER non-fatal uncorrectable error log
+ ratelimiting. Writing a positive value sets the ratelimit
+ interval in ms. Default is DEFAULT_RATELIMIT_INTERVAL
+ (5000 ms).
+
+What: /sys/bus/pci/devices/<dev>/aer/nonfatal_ratelimit_burst
+Date: May 2025
+KernelVersion: 6.16.0
+Contact: linux-pci@vger.kernel.org
+Description: Ratelimit burst for non-fatal uncorrectable error logs.
+ Writing a value changes the number of errors (burst)
+ allowed per interval before ratelimiting. Reading gets the
+ current ratelimit burst. Default is DEFAULT_RATELIMIT_BURST
+ (10).
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
deleted file mode 100644
index 860db53037a5..000000000000
--- a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
+++ /dev/null
@@ -1,119 +0,0 @@
-PCIe Device AER statistics
---------------------------
-
-These attributes show up under all the devices that are AER capable. These
-statistical counters indicate the errors "as seen/reported by the device".
-Note that this may mean that if an endpoint is causing problems, the AER
-counters may increment at its link partner (e.g. root port) because the
-errors may be "seen" / reported by the link partner and not the
-problematic endpoint itself (which may report all counters as 0 as it never
-saw any problems).
-
-What: /sys/bus/pci/devices/<dev>/aer_dev_correctable
-Date: July 2018
-KernelVersion: 4.19.0
-Contact: linux-pci@vger.kernel.org, rajatja@google.com
-Description: List of correctable errors seen and reported by this
- PCI device using ERR_COR. Note that since multiple errors may
- be reported using a single ERR_COR message, thus
- TOTAL_ERR_COR at the end of the file may not match the actual
- total of all the errors in the file. Sample output::
-
- localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_correctable
- Receiver Error 2
- Bad TLP 0
- Bad DLLP 0
- RELAY_NUM Rollover 0
- Replay Timer Timeout 0
- Advisory Non-Fatal 0
- Corrected Internal Error 0
- Header Log Overflow 0
- TOTAL_ERR_COR 2
-
-What: /sys/bus/pci/devices/<dev>/aer_dev_fatal
-Date: July 2018
-KernelVersion: 4.19.0
-Contact: linux-pci@vger.kernel.org, rajatja@google.com
-Description: List of uncorrectable fatal errors seen and reported by this
- PCI device using ERR_FATAL. Note that since multiple errors may
- be reported using a single ERR_FATAL message, thus
- TOTAL_ERR_FATAL at the end of the file may not match the actual
- total of all the errors in the file. Sample output::
-
- localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_fatal
- Undefined 0
- Data Link Protocol 0
- Surprise Down Error 0
- Poisoned TLP 0
- Flow Control Protocol 0
- Completion Timeout 0
- Completer Abort 0
- Unexpected Completion 0
- Receiver Overflow 0
- Malformed TLP 0
- ECRC 0
- Unsupported Request 0
- ACS Violation 0
- Uncorrectable Internal Error 0
- MC Blocked TLP 0
- AtomicOp Egress Blocked 0
- TLP Prefix Blocked Error 0
- TOTAL_ERR_FATAL 0
-
-What: /sys/bus/pci/devices/<dev>/aer_dev_nonfatal
-Date: July 2018
-KernelVersion: 4.19.0
-Contact: linux-pci@vger.kernel.org, rajatja@google.com
-Description: List of uncorrectable nonfatal errors seen and reported by this
- PCI device using ERR_NONFATAL. Note that since multiple errors
- may be reported using a single ERR_FATAL message, thus
- TOTAL_ERR_NONFATAL at the end of the file may not match the
- actual total of all the errors in the file. Sample output::
-
- localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_nonfatal
- Undefined 0
- Data Link Protocol 0
- Surprise Down Error 0
- Poisoned TLP 0
- Flow Control Protocol 0
- Completion Timeout 0
- Completer Abort 0
- Unexpected Completion 0
- Receiver Overflow 0
- Malformed TLP 0
- ECRC 0
- Unsupported Request 0
- ACS Violation 0
- Uncorrectable Internal Error 0
- MC Blocked TLP 0
- AtomicOp Egress Blocked 0
- TLP Prefix Blocked Error 0
- TOTAL_ERR_NONFATAL 0
-
-PCIe Rootport AER statistics
-----------------------------
-
-These attributes show up under only the rootports (or root complex event
-collectors) that are AER capable. These indicate the number of error messages as
-"reported to" the rootport. Please note that the rootports also transmit
-(internally) the ERR_* messages for errors seen by the internal rootport PCI
-device, so these counters include them and are thus cumulative of all the error
-messages on the PCI hierarchy originating at that root port.
-
-What: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_cor
-Date: July 2018
-KernelVersion: 4.19.0
-Contact: linux-pci@vger.kernel.org, rajatja@google.com
-Description: Total number of ERR_COR messages reported to rootport.
-
-What: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_fatal
-Date: July 2018
-KernelVersion: 4.19.0
-Contact: linux-pci@vger.kernel.org, rajatja@google.com
-Description: Total number of ERR_FATAL messages reported to rootport.
-
-What: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_nonfatal
-Date: July 2018
-KernelVersion: 4.19.0
-Contact: linux-pci@vger.kernel.org, rajatja@google.com
-Description: Total number of ERR_NONFATAL messages reported to rootport.
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-avs b/Documentation/ABI/testing/sysfs-bus-pci-devices-avs
new file mode 100644
index 000000000000..ebff3fa12055
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-avs
@@ -0,0 +1,8 @@
+What: /sys/devices/pci0000:00/<dev>/avs/fw_version
+Date: February 2024
+Contact: Cezary Rojewski <cezary.rojewski@intel.com>
+Description:
+ Version of AudioDSP firmware ASoC avs driver is communicating
+ with.
+
+ Format: %d.%d.%d.%d, type:major:minor:build.
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
index 0088aba4caa8..fc82aa4e54b0 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -23,3 +23,65 @@ Description:
Reading this attribute gives the state of the DbC. It
can be one of the following states: disabled, enabled,
initialized, connected, configured and stalled.
+
+What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor
+Date: March 2023
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ This dbc_idVendor attribute lets us change the idVendor field
+ presented in the USB device descriptor by this xhci debug
+ device.
+ Value can only be changed while debug capability (DbC) is in
+ disabled state to prevent USB device descriptor change while
+ connected to a USB host.
+ The default value is 0x1d6b (Linux Foundation).
+ It can be any 16-bit integer.
+
+What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idProduct
+Date: March 2023
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ This dbc_idProduct attribute lets us change the idProduct field
+ presented in the USB device descriptor by this xhci debug
+ device.
+ Value can only be changed while debug capability (DbC) is in
+ disabled state to prevent USB device descriptor change while
+ connected to a USB host.
+ The default value is 0x0010. It can be any 16-bit integer.
+
+What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bcdDevice
+Date: March 2023
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ This dbc_bcdDevice attribute lets us change the bcdDevice field
+ presented in the USB device descriptor by this xhci debug
+ device.
+ Value can only be changed while debug capability (DbC) is in
+ disabled state to prevent USB device descriptor change while
+ connected to a USB host.
+ The default value is 0x0010. (device rev 0.10)
+ It can be any 16-bit integer.
+
+What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bInterfaceProtocol
+Date: March 2023
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ This attribute lets us change the bInterfaceProtocol field
+ presented in the USB Interface descriptor by the xhci debug
+ device.
+ Value can only be changed while debug capability (DbC) is in
+ disabled state to prevent USB descriptor change while
+ connected to a USB host.
+ The default value is 1 (GNU Remote Debug command).
+ Other permissible value is 0 which is for vendor defined debug
+ target.
+
+What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_poll_interval_ms
+Date: February 2024
+Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+ This attribute adjust the polling interval used to check for
+ DbC events. Unit is milliseconds. Accepted values range from 0
+ up to 5000. The default value is 64 ms.
+ This polling interval is used while DbC is enabled but has no
+ active data transfers.
diff --git a/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro b/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro
new file mode 100644
index 000000000000..fead760dcf77
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro
@@ -0,0 +1,325 @@
+What: /sys/bus/platform/devices/smpro-errmon.*/error_[core|mem|pcie|other]_[ce|ue]
+KernelVersion: 6.1
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RO) Contains the 48-byte Ampere (Vendor-Specific) Error Record printed
+ in hex format according to the table below:
+
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | Offset | Field | Size (byte) | Description |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 00 | Error Type | 1 | See :ref:`the table below <smpro-error-types>` for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 01 | Subtype | 1 | See :ref:`the table below <smpro-error-types>` for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 02 | Instance | 2 | See :ref:`the table below <smpro-error-types>` for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 04 | Error status | 4 | See ARM RAS specification for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 08 | Error Address | 8 | See ARM RAS specification for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 16 | Error Misc 0 | 8 | See ARM RAS specification for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 24 | Error Misc 1 | 8 | See ARM RAS specification for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 32 | Error Misc 2 | 8 | See ARM RAS specification for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+ | 40 | Error Misc 3 | 8 | See ARM RAS specification for details |
+ +--------+---------------+-------------+------------------------------------------------------------+
+
+ The table below defines the value of error types, their subtype, subcomponent and instance:
+
+ .. _smpro-error-types:
+
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | Error Group | Error Type | Sub type | Sub component | Instance |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | CPM (core) | 0 | 0 | Snoop-Logic | CPM # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | CPM (core) | 0 | 2 | Armv8 Core 1 | CPM # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 1 | ERR1 | MCU # \| SLOT << 11 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 2 | ERR2 | MCU # \| SLOT << 11 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 3 | ERR3 | MCU # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 4 | ERR4 | MCU # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 5 | ERR5 | MCU # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 6 | ERR6 | MCU # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | MCU (mem) | 1 | 7 | Link Error | MCU # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | Mesh (other) | 2 | 0 | Cross Point | X \| (Y << 5) \| NS <<11 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | Mesh (other) | 2 | 1 | Home Node(IO) | X \| (Y << 5) \| NS <<11 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | Mesh (other) | 2 | 2 | Home Node(Mem) | X \| (Y << 5) \| NS <<11 \| device<<12 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | Mesh (other) | 2 | 4 | CCIX Node | X \| (Y << 5) \| NS <<11 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | 2P Link (other) | 3 | 0 | N/A | Altra 2P Link # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 0 | ERR0 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 1 | ERR1 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 2 | ERR2 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 3 | ERR3 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 4 | ERR4 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 5 | ERR5 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 6 | ERR6 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 7 | ERR7 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 8 | ERR8 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 9 | ERR9 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 10 | ERR10 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 11 | ERR11 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 12 | ERR12 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | GIC (other) | 5 | 13-21 | ERR13 | RC # + 1 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TCU | 100 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU0 | 0 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU1 | 1 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU2 | 2 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU3 | 3 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU4 | 4 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU5 | 5 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU6 | 6 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU7 | 7 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU8 | 8 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMMU (other) | 6 | TBU9 | 9 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PCIe AER (pcie) | 7 | Root | 0 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PCIe AER (pcie) | 7 | Device | 1 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PCIe RC (pcie) | 8 | RCA HB | 0 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PCIe RC (pcie) | 8 | RCB HB | 1 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PCIe RC (pcie) | 8 | RASDP | 8 | RC # |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | OCM (other) | 9 | ERR0 | 0 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | OCM (other) | 9 | ERR1 | 1 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | OCM (other) | 9 | ERR2 | 2 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMpro (other) | 10 | ERR0 | 0 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMpro (other) | 10 | ERR1 | 1 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | SMpro (other) | 10 | MPA_ERR | 2 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PMpro (other) | 11 | ERR0 | 0 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PMpro (other) | 11 | ERR1 | 1 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+ | PMpro (other) | 11 | MPA_ERR | 2 | 0 |
+ +-----------------+------------+----------+----------------+----------------------------------------+
+
+ Example::
+
+ # cat error_other_ue
+ 880807001e004010401040101500000001004010401040100c0000000000000000000000000000000000000000000000
+
+ The detail of each sysfs entries is as below:
+
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Error | Sysfs entry | Description (when triggered) |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Core's CE | /sys/bus/platform/devices/smpro-errmon.*/error_core_ce | Core has CE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Core's UE | /sys/bus/platform/devices/smpro-errmon.*/error_core_ue | Core has UE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Memory's CE | /sys/bus/platform/devices/smpro-errmon.*/error_mem_ce | Memory has CE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Memory's UE | /sys/bus/platform/devices/smpro-errmon.*/error_mem_ue | Memory has UE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | PCIe's CE | /sys/bus/platform/devices/smpro-errmon.*/error_pcie_ce | any PCIe controller has CE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | PCIe's UE | /sys/bus/platform/devices/smpro-errmon.*/error_pcie_ue | any PCIe controller has UE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Other's CE | /sys/bus/platform/devices/smpro-errmon.*/error_other_ce | any other CE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+ | Other's UE | /sys/bus/platform/devices/smpro-errmon.*/error_other_ue | any other UE error |
+ +-------------+---------------------------------------------------------+----------------------------------+
+
+ UE: Uncorrect-able Error
+ CE: Correct-able Error
+
+ For details, see section `3.3 Ampere (Vendor-Specific) Error Record Formats,
+ Altra Family RAS Supplement`.
+
+
+What: /sys/bus/platform/devices/smpro-errmon.*/overflow_[core|mem|pcie|other]_[ce|ue]
+KernelVersion: 6.1
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RO) Return the overflow status of each type HW error reported:
+
+ - 0 : No overflow
+ - 1 : There is an overflow and the oldest HW errors are dropped
+
+ The detail of each sysfs entries is as below:
+
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Overflow | Sysfs entry | Description |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Core's CE | /sys/bus/platform/devices/smpro-errmon.*/overflow_core_ce | Core CE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Core's UE | /sys/bus/platform/devices/smpro-errmon.*/overflow_core_ue | Core UE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Memory's CE | /sys/bus/platform/devices/smpro-errmon.*/overflow_mem_ce | Memory CE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Memory's UE | /sys/bus/platform/devices/smpro-errmon.*/overflow_mem_ue | Memory UE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | PCIe's CE | /sys/bus/platform/devices/smpro-errmon.*/overflow_pcie_ce | any PCIe controller CE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | PCIe's UE | /sys/bus/platform/devices/smpro-errmon.*/overflow_pcie_ue | any PCIe controller UE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Other's CE | /sys/bus/platform/devices/smpro-errmon.*/overflow_other_ce| any other CE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+ | Other's UE | /sys/bus/platform/devices/smpro-errmon.*/overflow_other_ue| other UE error overflow |
+ +-------------+-----------------------------------------------------------+---------------------------------------+
+
+ where:
+
+ - UE: Uncorrect-able Error
+ - CE: Correct-able Error
+
+What: /sys/bus/platform/devices/smpro-errmon.*/[error|warn]_[smpro|pmpro]
+KernelVersion: 6.1
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RO) Contains the internal firmware error/warning printed as hex format.
+
+ The detail of each sysfs entries is as below:
+
+ +---------------+------------------------------------------------------+--------------------------+
+ | Error | Sysfs entry | Description |
+ +---------------+------------------------------------------------------+--------------------------+
+ | SMpro error | /sys/bus/platform/devices/smpro-errmon.*/error_smpro | system has SMpro error |
+ +---------------+------------------------------------------------------+--------------------------+
+ | SMpro warning | /sys/bus/platform/devices/smpro-errmon.*/warn_smpro | system has SMpro warning |
+ +---------------+------------------------------------------------------+--------------------------+
+ | PMpro error | /sys/bus/platform/devices/smpro-errmon.*/error_pmpro | system has PMpro error |
+ +---------------+------------------------------------------------------+--------------------------+
+ | PMpro warning | /sys/bus/platform/devices/smpro-errmon.*/warn_pmpro | system has PMpro warning |
+ +---------------+------------------------------------------------------+--------------------------+
+
+ For details, see section `5.10 RAS Internal Error Register Definitions,
+ Altra Family Soc BMC Interface Specification`.
+
+What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot|dimm_2x_refresh]
+KernelVersion: 6.1 (event_[vrd_warn_fault|vrd_hot|dimm_hot]), 6.4 (event_dimm_2x_refresh)
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RO) Contains the detail information in case of VRD/DIMM warning/hot events
+ in hex format as below::
+
+ AAAA
+
+ where:
+
+ - ``AAAA``: The event detail information data
+
+ The detail of each sysfs entries is as below:
+
+ +---------------+---------------------------------------------------------------+---------------------+
+ | Event | Sysfs entry | Description |
+ +---------------+---------------------------------------------------------------+---------------------+
+ | VRD HOT | /sys/bus/platform/devices/smpro-errmon.*/event_vrd_hot | VRD Hot |
+ +---------------+---------------------------------------------------------------+---------------------+
+ | VR Warn/Fault | /sys/bus/platform/devices/smpro-errmon.*/event_vrd_warn_fault | VR Warning or Fault |
+ +---------------+---------------------------------------------------------------+---------------------+
+ | DIMM HOT | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_hot | DIMM Hot |
+ +---------------+---------------------------------------------------------------+---------------------+
+ | DIMM 2X | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_2x_refresh| DIMM 2x refresh rate|
+ | REFRESH RATE | | event in high temp |
+ +---------------+---------------------------------------------------------------+---------------------+
+
+ For more details, see section `5.7 GPI Status Registers and 5.9 Memory Error Register Definitions,
+ Altra Family Soc BMC Interface Specification`.
+
+What: /sys/bus/platform/devices/smpro-errmon.*/event_dimm[0-15]_syndrome
+KernelVersion: 6.4
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RO) The sysfs returns the 2-byte DIMM failure syndrome data for slot
+ 0-15 if it failed to initialize.
+
+ For more details, see section `5.11 Boot Stage Register Definitions,
+ Altra Family Soc BMC Interface Specification`.
+
+What: /sys/bus/platform/devices/smpro-misc.*/boot_progress
+KernelVersion: 6.1
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RO) Contains the boot stages information in hex as format below::
+
+ AABBCCCCCCCC
+
+ where:
+
+ - ``AA`` : The boot stages
+
+ - 00: SMpro firmware booting
+ - 01: PMpro firmware booting
+ - 02: ATF BL1 firmware booting
+ - 03: DDR initialization
+ - 04: DDR training report status
+ - 05: ATF BL2 firmware booting
+ - 06: ATF BL31 firmware booting
+ - 07: ATF BL32 firmware booting
+ - 08: UEFI firmware booting
+ - 09: OS booting
+
+ - ``BB`` : Boot status
+
+ - 00: Not started
+ - 01: Started
+ - 02: Completed without error
+ - 03: Failed.
+
+ - ``CCCCCCCC``: Boot status information defined for each boot stages
+
+ For details, see section `5.11 Boot Stage Register Definitions`
+ and section `6. Processor Boot Progress Codes, Altra Family Soc BMC
+ Interface Specification`.
+
+
+What: /sys/bus/platform/devices/smpro-misc*/soc_power_limit
+KernelVersion: 6.1
+Contact: Quan Nguyen <quan@os.amperecomputing.com>
+Description:
+ (RW) Contains the desired SoC power limit in Watt.
+ Writes to this sysfs set the desired SoC power limit (W).
+ Reads from this register return the current SoC power limit (W).
+ The value ranges:
+
+ - Minimum: 120 W
+ - Maximum: Socket TDP power
diff --git a/Documentation/ABI/testing/sysfs-bus-platform-drivers-amd_x3d_vcache b/Documentation/ABI/testing/sysfs-bus-platform-drivers-amd_x3d_vcache
new file mode 100644
index 000000000000..ac3431736f5c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform-drivers-amd_x3d_vcache
@@ -0,0 +1,12 @@
+What: /sys/bus/platform/drivers/amd_x3d_vcache/AMDI0101:00/amd_x3d_mode
+Date: November 2024
+KernelVersion: 6.13
+Contact: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
+Description: (RW) AMD 3D V-Cache optimizer allows users to switch CPU core
+ rankings dynamically.
+
+ This file switches between these two modes:
+ - "frequency" cores within the faster CCD are prioritized before
+ those in the slower CCD.
+ - "cache" cores within the larger L3 CCD are prioritized before
+ those in the smaller L3 CCD.
diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-dev b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-dev
new file mode 100644
index 000000000000..b06a48c3c85a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-dev
@@ -0,0 +1,9 @@
+What: /sys/bus/platform/devices/<dev>/always_powered_in_suspend
+Date: June 2022
+KernelVersion: 5.20
+Contact: Matthias Kaehlcke <matthias@kaehlcke.net>
+ linux-usb@vger.kernel.org
+Description:
+ (RW) Controls whether the USB hub remains always powered
+ during system suspend or not. This attribute is not
+ available for non-hub devices.
diff --git a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub b/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
deleted file mode 100644
index 42deb0552065..000000000000
--- a/Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
+++ /dev/null
@@ -1,8 +0,0 @@
-What: /sys/bus/platform/devices/<dev>/always_powered_in_suspend
-Date: June 2022
-KernelVersion: 5.20
-Contact: Matthias Kaehlcke <matthias@kaehlcke.net>
- linux-usb@vger.kernel.org
-Description:
- (RW) Controls whether the USB hub remains always powered
- during system suspend or not. \ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor
index d76cd3946434..9ed5582ddea2 100644
--- a/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor
+++ b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor
@@ -5,6 +5,9 @@ Contact: linux-mtd@lists.infradead.org
Description: (RO) The JEDEC ID of the SPI NOR flash as reported by the
flash device.
+ The attribute is not present if the flash doesn't support
+ the "Read JEDEC ID" command (9Fh). This is the case for
+ non-JEDEC compliant flashes.
What: /sys/bus/spi/devices/.../spi-nor/manufacturer
Date: April 2021
@@ -12,6 +15,9 @@ KernelVersion: 5.14
Contact: linux-mtd@lists.infradead.org
Description: (RO) Manufacturer of the SPI NOR flash.
+ The attribute is not present if the flash device isn't
+ known to the kernel and is only probed by its SFDP
+ tables.
What: /sys/bus/spi/devices/.../spi-nor/partname
Date: April 2021
@@ -19,6 +25,9 @@ KernelVersion: 5.14
Contact: linux-mtd@lists.infradead.org
Description: (RO) Part name of the SPI NOR flash.
+ The attribute is optional. User space should not rely on
+ it to be present or even correct. Instead, user space
+ should read the jedec_id attribute.
What: /sys/bus/spi/devices/.../spi-nor/sfdp
Date: April 2021
diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index f7570c240ce8..221b6c75ed93 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -1,7 +1,7 @@
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
Date: Jun 2018
KernelVersion: 4.17
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Holds a comma separated list of device unique_ids that
are allowed to be connected automatically during system
startup (e.g boot devices). The list always contains
@@ -33,7 +33,7 @@ Description: This attribute tells whether the system supports
What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
Date: Mar 2019
KernelVersion: 4.21
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute tells whether the system uses IOMMU
for DMA protection. Value of 1 means IOMMU is used 0 means
it is not (DMA protection is solely based on Thunderbolt
@@ -42,7 +42,7 @@ Description: This attribute tells whether the system uses IOMMU
What: /sys/bus/thunderbolt/devices/.../domainX/security
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute holds current Thunderbolt security level
set by the system BIOS. Possible values are:
@@ -64,7 +64,7 @@ Description: This attribute holds current Thunderbolt security level
What: /sys/bus/thunderbolt/devices/.../authorized
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute is used to authorize Thunderbolt devices
after they have been connected. If the device is not
authorized, no PCIe devices are available to the system.
@@ -98,7 +98,7 @@ Description: This attribute is used to authorize Thunderbolt devices
What: /sys/bus/thunderbolt/devices/.../boot
Date: Jun 2018
KernelVersion: 4.17
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains 1 if Thunderbolt device was already
authorized on boot and 0 otherwise.
@@ -113,7 +113,7 @@ Description: This attribute contains the generation of the Thunderbolt
What: /sys/bus/thunderbolt/devices/.../key
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: When a devices supports Thunderbolt secure connect it will
have this attribute. Writing 32 byte hex string changes
authorization to use the secure connection method instead.
@@ -123,14 +123,14 @@ Description: When a devices supports Thunderbolt secure connect it will
What: /sys/bus/thunderbolt/devices/.../device
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains id of this device extracted from
the device DROM.
What: /sys/bus/thunderbolt/devices/.../device_name
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains name of this device extracted from
the device DROM.
@@ -153,7 +153,7 @@ Date: Jan 2020
KernelVersion: 5.5
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute reports number of RX lanes the device is
- using simultaneusly through its upstream port.
+ using simultaneously through its upstream port.
What: /sys/bus/thunderbolt/devices/.../tx_speed
Date: Jan 2020
@@ -167,26 +167,26 @@ Date: Jan 2020
KernelVersion: 5.5
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute reports number of TX lanes the device is
- using simultaneusly through its upstream port.
+ using simultaneously through its upstream port.
What: /sys/bus/thunderbolt/devices/.../vendor
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains vendor id of this device extracted
from the device DROM.
What: /sys/bus/thunderbolt/devices/.../vendor_name
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains vendor name of this device extracted
from the device DROM.
What: /sys/bus/thunderbolt/devices/.../unique_id
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains unique_id string of this device.
This is either read from hardware registers (UUID on
newer hardware) or based on UID from the device DROM.
@@ -195,7 +195,7 @@ Description: This attribute contains unique_id string of this device.
What: /sys/bus/thunderbolt/devices/.../nvm_version
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: If the device has upgradeable firmware the version
number is available here. Format: %x.%x, major.minor.
If the device is in safe mode reading the file returns
@@ -204,7 +204,7 @@ Description: If the device has upgradeable firmware the version
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate
Date: Sep 2017
KernelVersion: 4.13
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: When new NVM image is written to the non-active NVM
area (through non_activeX NVMem device), the
authentication procedure is started by writing to
@@ -246,7 +246,7 @@ Description: For supported devices, automatically authenticate the new Thunderbo
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/key
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains name of the property directory the XDomain
service exposes. This entry describes the protocol in
question. Following directories are already reserved by
@@ -261,35 +261,35 @@ Description: This contains name of the property directory the XDomain
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/modalias
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Stores the same MODALIAS value emitted by uevent for
the XDomain service. Format: tbtsvc:kSpNvNrN
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcid
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain protocol identifier the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcvers
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain protocol version the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcrevs
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain software version the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcstns
Date: Jan 2018
KernelVersion: 4.15
-Contact: thunderbolt-software@lists.01.org
+Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain service specific settings as
bitmask. Format: %x
diff --git a/Documentation/ABI/testing/sysfs-bus-umc b/Documentation/ABI/testing/sysfs-bus-umc
deleted file mode 100644
index 948fec412446..000000000000
--- a/Documentation/ABI/testing/sysfs-bus-umc
+++ /dev/null
@@ -1,28 +0,0 @@
-What: /sys/bus/umc/
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The Wireless Host Controller Interface (WHCI)
- specification describes a PCI-based device with
- multiple capabilities; the UWB Multi-interface
- Controller (UMC).
-
- The umc bus presents each of the individual
- capabilties as a device.
-
-What: /sys/bus/umc/devices/.../capability_id
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The ID of this capability, with 0 being the radio
- controller capability.
-
-What: /sys/bus/umc/devices/.../version
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The specification version this capability's hardware
- interface complies with.
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 568103d3376e..af9b653422f1 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -28,40 +28,6 @@ Description:
drivers, non-authorized one are not. By default, wired
USB devices are authorized.
- Certified Wireless USB devices are not authorized
- initially and should be (by writing 1) after the
- device has been authenticated.
-
-What: /sys/bus/usb/device/.../wusb_cdid
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- For Certified Wireless USB devices only.
-
- A devices's CDID, as 16 space-separated hex octets.
-
-What: /sys/bus/usb/device/.../wusb_ck
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- For Certified Wireless USB devices only.
-
- Write the device's connection key (CK) to start the
- authentication of the device. The CK is 16
- space-separated hex octets.
-
-What: /sys/bus/usb/device/.../wusb_disconnect
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- For Certified Wireless USB devices only.
-
- Write a 1 to force the device to disconnect
- (equivalent to unplugging a wired USB device).
-
What: /sys/bus/usb/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
@@ -166,6 +132,23 @@ Description:
The file will be present for all speeds of USB devices, and will
always read "no" for USB 1.1 and USB 2.0 devices.
+What: /sys/bus/usb/devices/<INTERFACE>/wireless_status
+Date: February 2023
+Contact: Bastien Nocera <hadess@hadess.net>
+Description:
+ Some USB devices use a USB receiver dongle to communicate
+ wirelessly with their device using proprietary protocols. This
+ attribute allows user-space to know whether the device is
+ connected to its receiver dongle, and, for example, consider
+ the device to be absent when choosing whether to show the
+ device's battery, show a headset in a list of outputs, or show
+ an on-screen keyboard if the only wireless keyboard is
+ turned off.
+ This attribute is not to be used to replace protocol specific
+ statuses available in WWAN, WLAN/Wi-Fi, Bluetooth, etc.
+ If the device does not use a receiver dongle with a wireless
+ device, then this attribute will not exist.
+
What: /sys/bus/usb/devices/.../<hub_interface>/port<X>
Date: August 2012
Contact: Lan Tianyu <tianyu.lan@intel.com>
@@ -264,6 +247,27 @@ Description:
attached to the port will not be detected, initialized,
or enumerated.
+What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/early_stop
+Date: Sep 2022
+Contact: Ray Chi <raychi@google.com>
+Description:
+ Some USB hosts have some watchdog mechanisms so that the device
+ may enter ramdump if it takes a long time during port initialization.
+ This attribute allows each port just has two attempts so that the
+ port initialization will be failed quickly. In addition, if a port
+ which is marked with early_stop has failed to initialize, it will ignore
+ all future connections until this attribute is clear.
+
+What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/state
+Date: June 2023
+Contact: Roy Luo <royluo@google.com>
+Description:
+ Indicates current state of the USB device attached to the port.
+ Valid states are: 'not-attached', 'attached', 'powered',
+ 'reconnecting', 'unauthenticated', 'default', 'addressed',
+ 'configured', and 'suspended'. This file supports poll() to
+ monitor the state change from user space.
+
What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
Date: May 2013
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
@@ -309,6 +313,15 @@ Description:
Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
direction. Devices before USB 3.2 are single lane (tx_lanes = 1)
+What: /sys/bus/usb/devices/.../typec
+Date: November 2023
+Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description:
+ Symlink to the USB Type-C partner device. USB Type-C partner
+ represents the component that communicates over the
+ Configuration Channel (CC signal on USB Type-C connectors and
+ cables) with the local port.
+
What: /sys/bus/usb/devices/usbX/bAlternateSetting
Description:
The current interface alternate setting number, in decimal.
@@ -429,6 +442,16 @@ What: /sys/bus/usb/devices/usbX/descriptors
Description:
Contains the interface descriptors, in binary.
+What: /sys/bus/usb/devices/usbX/bos_descriptors
+Date: March 2024
+Contact: Elbert Mai <code@elbertmai.com>
+Description:
+ Binary file containing the cached binary device object store (BOS)
+ of the device. This consists of the BOS descriptor followed by the
+ set of device capability descriptors. All descriptors read from
+ this file are in bus-endian format. Note that the kernel will not
+ request the BOS from a device if its bcdUSB is less than 0x0201.
+
What: /sys/bus/usb/devices/usbX/idProduct
Description:
Product ID, in hexadecimal.
diff --git a/Documentation/ABI/testing/sysfs-bus-vdpa b/Documentation/ABI/testing/sysfs-bus-vdpa
index 28a6111202ba..2c833b5163f2 100644
--- a/Documentation/ABI/testing/sysfs-bus-vdpa
+++ b/Documentation/ABI/testing/sysfs-bus-vdpa
@@ -1,6 +1,6 @@
-What: /sys/bus/vdpa/driver_autoprobe
+What: /sys/bus/vdpa/drivers_autoprobe
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
This file determines whether new devices are immediately bound
to a driver after the creation. It initially contains 1, which
@@ -12,17 +12,17 @@ Description:
What: /sys/bus/vdpa/driver_probe
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
Writing a device name to this file will cause the kernel binds
devices to a compatible driver.
- This can be useful when /sys/bus/vdpa/driver_autoprobe is
+ This can be useful when /sys/bus/vdpa/drivers_autoprobe is
disabled.
What: /sys/bus/vdpa/drivers/.../bind
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
Writing a device name to this file will cause the driver to
attempt to bind to the device. This is useful for overriding
@@ -30,7 +30,7 @@ Description:
What: /sys/bus/vdpa/drivers/.../unbind
Date: March 2020
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
Writing a device name to this file will cause the driver to
attempt to unbind from the device. This may be useful when
@@ -38,7 +38,7 @@ Description:
What: /sys/bus/vdpa/devices/.../driver_override
Date: November 2021
-Contact: virtualization@lists.linux-foundation.org
+Contact: virtualization@lists.linux.dev
Description:
This file allows the driver for a device to be specified.
When specified, only a driver with a name matching the value
diff --git a/Documentation/ABI/testing/sysfs-bus-wmi b/Documentation/ABI/testing/sysfs-bus-wmi
new file mode 100644
index 000000000000..d71a219c610e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-wmi
@@ -0,0 +1,81 @@
+What: /sys/bus/wmi/devices/.../driver_override
+Date: February 2024
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ This file allows the driver for a device to be specified which
+ will override standard ID table matching.
+ When specified, only a driver with a name matching the value
+ written to driver_override will have an opportunity to bind
+ to the device.
+ The override is specified by writing a string to the
+ driver_override file (echo wmi-event-dummy > driver_override).
+ The override may be cleared with an empty string (echo > \
+ driver_override) which returns the device to standard matching
+ rules binding.
+ Writing to driver_override does not automatically unbind the
+ device from its current driver or make any attempt to automatically
+ load the specified driver. If no driver with a matching name is
+ currently loaded in the kernel, the device will not bind to any
+ driver.
+ This also allows devices to opt-out of driver binding using a
+ driver_override name such as "none". Only a single driver may be
+ specified in the override, there is no support for parsing delimiters.
+
+What: /sys/bus/wmi/devices/.../modalias
+Date: November 20:15
+Contact: Andy Lutomirski <luto@kernel.org>
+Description:
+ This file contains the MODALIAS value emitted by uevent for a
+ given WMI device.
+
+ Format: wmi:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
+
+What: /sys/bus/wmi/devices/.../guid
+Date: November 2015
+Contact: Andy Lutomirski <luto@kernel.org>
+Description:
+ This file contains the GUID used to match WMI devices to
+ compatible WMI drivers. This GUID is not necessarily unique
+ inside a given machine, it is solely used to identify the
+ interface exposed by a given WMI device.
+
+What: /sys/bus/wmi/devices/.../object_id
+Date: November 2015
+Contact: Andy Lutomirski <luto@kernel.org>
+Description:
+ This file contains the WMI object ID used internally to construct
+ the ACPI method names used by non-event WMI devices. It contains
+ two ASCII letters.
+
+What: /sys/bus/wmi/devices/.../notify_id
+Date: November 2015
+Contact: Andy Lutomirski <luto@kernel.org>
+Description:
+ This file contains the WMI notify ID used internally to map ACPI
+ events to WMI event devices. It contains two ASCII letters.
+
+What: /sys/bus/wmi/devices/.../instance_count
+Date: November 2015
+Contact: Andy Lutomirski <luto@kernel.org>
+Description:
+ This file contains the number of WMI object instances being
+ present on a given WMI device. It contains a non-negative
+ number.
+
+What: /sys/bus/wmi/devices/.../expensive
+Date: November 2015
+Contact: Andy Lutomirski <luto@kernel.org>
+Description:
+ This file contains a boolean flag signaling if interacting with
+ the given WMI device will consume significant CPU resources.
+ The WMI driver core will take care of enabling/disabling such
+ WMI devices.
+
+What: /sys/bus/wmi/devices/.../setable
+Date: May 2017
+Contact: Darren Hart (VMware) <dvhart@infradead.org>
+Description:
+ This file contains a boolean flags signaling the data block
+ associated with the given WMI device is writable. If the
+ given WMI device is not associated with a data block, then
+ this file will not exist.
diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class
index 676530fcf747..906735faa1b8 100644
--- a/Documentation/ABI/testing/sysfs-class
+++ b/Documentation/ABI/testing/sysfs-class
@@ -1,5 +1,5 @@
What: /sys/class/
-Date: Febuary 2006
+Date: February 2006
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
The /sys/class directory will consist of a group of
diff --git a/Documentation/ABI/testing/sysfs-class-bdi b/Documentation/ABI/testing/sysfs-class-bdi
index 6d2a2fc189dd..0d2abd88a18c 100644
--- a/Documentation/ABI/testing/sysfs-class-bdi
+++ b/Documentation/ABI/testing/sysfs-class-bdi
@@ -44,6 +44,21 @@ Description:
(read-write)
+What: /sys/class/bdi/<bdi>/min_ratio_fine
+Date: November 2022
+Contact: Stefan Roesch <shr@devkernel.io>
+Description:
+ Under normal circumstances each device is given a part of the
+ total write-back cache that relates to its current average
+ writeout speed in relation to the other devices.
+
+ The 'min_ratio_fine' parameter allows assigning a minimum reserve
+ of the write-back cache to a particular device. The value is
+ expressed as part of 1 million. For example, this is useful for
+ providing a minimum QoS.
+
+ (read-write)
+
What: /sys/class/bdi/<bdi>/max_ratio
Date: January 2008
Contact: Peter Zijlstra <a.p.zijlstra@chello.nl>
@@ -56,6 +71,59 @@ Description:
be trusted to play fair.
(read-write)
+
+What: /sys/class/bdi/<bdi>/max_ratio_fine
+Date: November 2022
+Contact: Stefan Roesch <shr@devkernel.io>
+Description:
+ Allows limiting a particular device to use not more than the
+ given value of the write-back cache. The value is given as part
+ of 1 million. This is useful in situations where we want to avoid
+ one device taking all or most of the write-back cache. For example
+ in case of an NFS mount that is prone to get stuck, or a FUSE mount
+ which cannot be trusted to play fair.
+
+ (read-write)
+
+What: /sys/class/bdi/<bdi>/min_bytes
+Date: October 2022
+Contact: Stefan Roesch <shr@devkernel.io>
+Description:
+ Under normal circumstances each device is given a part of the
+ total write-back cache that relates to its current average
+ writeout speed in relation to the other devices.
+
+ The 'min_bytes' parameter allows assigning a minimum
+ percentage of the write-back cache to a particular device
+ expressed in bytes.
+ For example, this is useful for providing a minimum QoS.
+
+ (read-write)
+
+What: /sys/class/bdi/<bdi>/max_bytes
+Date: October 2022
+Contact: Stefan Roesch <shr@devkernel.io>
+Description:
+ Allows limiting a particular device to use not more than the
+ given 'max_bytes' of the write-back cache. This is useful in
+ situations where we want to avoid one device taking all or
+ most of the write-back cache. For example in case of an NFS
+ mount that is prone to get stuck, a FUSE mount which cannot be
+ trusted to play fair, or a nbd device.
+
+ (read-write)
+
+What: /sys/class/bdi/<bdi>/strict_limit
+Date: October 2022
+Contact: Stefan Roesch <shr@devkernel.io>
+Description:
+ Forces per-BDI checks for the share of given device in the write-back
+ cache even before the global background dirty limit is reached. This
+ is useful in situations where the global limit is much higher than
+ affordable for given relatively slow (or untrusted) device. Turning
+ strictlimit on has no visible effect if max_ratio is equal to 100%.
+
+ (read-write)
What: /sys/class/bdi/<bdi>/stable_pages_required
Date: January 2008
Contact: Peter Zijlstra <a.p.zijlstra@chello.nl>
diff --git a/Documentation/ABI/testing/sysfs-class-chromeos b/Documentation/ABI/testing/sysfs-class-chromeos
index 74ece942722e..7fa5be6cc774 100644
--- a/Documentation/ABI/testing/sysfs-class-chromeos
+++ b/Documentation/ABI/testing/sysfs-class-chromeos
@@ -31,3 +31,23 @@ Date: August 2015
KernelVersion: 4.2
Description:
Show the information about the EC software and hardware.
+
+What: /sys/class/chromeos/cros_ec/usbpdmuxinfo
+Date: February 2025
+Description:
+ Show PD mux status for each typec port with following flags:
+ - "USB": USB connected
+ - "DP": DP connected
+ - "POLARITY": CC line Polarity inverted
+ - "HPD_IRQ": Hot Plug Detect interrupt is asserted
+ - "HPD_LVL": Hot Plug Detect level is asserted
+ - "SAFE": DP is in safe mode
+ - "TBT": TBT enabled
+ - "USB4": USB4 enabled
+
+What: /sys/class/chromeos/cros_ec/ap_mode_entry
+Date: February 2025
+Description:
+ Show if the AP mode entry EC feature is supported.
+ It indicates whether the EC waits for direction from the AP
+ to enter Type-C altmodes or USB4 mode.
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq
index 5e6b74f30406..df8ba88b9f6a 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -52,6 +52,9 @@ Description:
echo 0 > /sys/class/devfreq/.../trans_stat
+ If the transition table is bigger than PAGE_SIZE, reading
+ this will return an -EFBIG error.
+
What: /sys/class/devfreq/.../available_frequencies
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
@@ -129,3 +132,12 @@ Description:
A list of governors that support the node:
- simple_ondemand
+
+What: /sys/class/devfreq/.../related_cpus
+Date: June 2025
+Contact: Linux power management list <linux-pm@vger.kernel.org>
+Description: The list of CPUs whose performance is closely related to the
+ frequency of this devfreq domain.
+
+ This file is only present if a specific devfreq device is
+ closely associated with a subset of CPUs.
diff --git a/Documentation/ABI/testing/sysfs-class-drm b/Documentation/ABI/testing/sysfs-class-drm
new file mode 100644
index 000000000000..d23fed5e29a7
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-drm
@@ -0,0 +1,8 @@
+What: /sys/class/drm/.../boot_display
+Date: January 2026
+Contact: Linux DRI developers <dri-devel@vger.kernel.org>
+Description:
+ This file indicates that displays connected to the device were
+ used to display the boot sequence. If a display connected to
+ the device was used to display the boot sequence the file will
+ be present and contain "1".
diff --git a/Documentation/ABI/testing/sysfs-class-firmware b/Documentation/ABI/testing/sysfs-class-firmware
index 978d3d500400..fba87a55f3ca 100644
--- a/Documentation/ABI/testing/sysfs-class-firmware
+++ b/Documentation/ABI/testing/sysfs-class-firmware
@@ -1,7 +1,7 @@
What: /sys/class/firmware/.../data
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: The data sysfs file is used for firmware-fallback and for
firmware uploads. Cat a firmware image to this sysfs file
after you echo 1 to the loading sysfs file. When the firmware
@@ -13,7 +13,7 @@ Description: The data sysfs file is used for firmware-fallback and for
What: /sys/class/firmware/.../cancel
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: Write-only. For firmware uploads, write a "1" to this file to
request that the transfer of firmware data to the lower-level
device be canceled. This request will be rejected (EBUSY) if
@@ -23,7 +23,7 @@ Description: Write-only. For firmware uploads, write a "1" to this file to
What: /sys/class/firmware/.../error
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: Read-only. Returns a string describing a failed firmware
upload. This string will be in the form of <STATUS>:<ERROR>,
where <STATUS> will be one of the status strings described
@@ -37,7 +37,7 @@ Description: Read-only. Returns a string describing a failed firmware
What: /sys/class/firmware/.../loading
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: The loading sysfs file is used for both firmware-fallback and
for firmware uploads. Echo 1 onto the loading file to indicate
you are writing a firmware file to the data sysfs node. Echo
@@ -49,7 +49,7 @@ Description: The loading sysfs file is used for both firmware-fallback and
What: /sys/class/firmware/.../remaining_size
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: Read-only. For firmware upload, this file contains the size
of the firmware data that remains to be transferred to the
lower-level device driver. The size value is initialized to
@@ -62,7 +62,7 @@ Description: Read-only. For firmware upload, this file contains the size
What: /sys/class/firmware/.../status
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: Read-only. Returns a string describing the current status of
a firmware upload. The string will be one of the following:
idle, "receiving", "preparing", "transferring", "programming".
@@ -70,7 +70,7 @@ Description: Read-only. Returns a string describing the current status of
What: /sys/class/firmware/.../timeout
Date: July 2022
KernelVersion: 5.19
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Russ Weight <russ.weight@linux.dev>
Description: This file supports the timeout mechanism for firmware
fallback. This file has no affect on firmware uploads. For
more information on timeouts please see the documentation
diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes
index 4cdba3477176..2713efa509b4 100644
--- a/Documentation/ABI/testing/sysfs-class-firmware-attributes
+++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes
@@ -22,6 +22,11 @@ Description:
- integer: a range of numerical values
- string
+ HP specific types
+ -----------------
+ - ordered-list - a set of ordered list valid values
+
+
All attribute types support the following values:
current_value:
@@ -126,6 +131,21 @@ Description:
value will not be effective through sysfs until this rule is
met.
+ HP specific class extensions
+ ------------------------------
+
+ On HP systems the following additional attributes are available:
+
+ "ordered-list"-type specific properties:
+
+ elements:
+ A file that can be read to obtain the possible
+ list of values of the <attr>. Values are separated using
+ semi-colon (``;``) and listed according to their priority.
+ An element listed first has the highest priority. Writing
+ the list in a different order to current_value alters
+ the priority order for the particular attribute.
+
What: /sys/class/firmware-attributes/*/authentication/
Date: February 2021
KernelVersion: 5.11
@@ -173,7 +193,7 @@ Description:
mechanism:
The means of authentication. This attribute is mandatory.
- Only supported type currently is "password".
+ Supported types are "password" or "certificate".
max_password_length:
A file that can be read to obtain the
@@ -206,7 +226,7 @@ Description:
Drivers may emit a CHANGE uevent when a password is set or unset
userspace may check it again.
- On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes
+ On Dell, Lenovo and HP systems, if Admin password is set, then all BIOS attributes
require password validation.
On Lenovo systems if you change the Admin password the new password is not active until
the next boot.
@@ -243,8 +263,8 @@ Description:
index:
Used with HDD and NVME authentication to set the drive index
- that is being referenced (e.g hdd0, hdd1 etc)
- This attribute defaults to device 0.
+ that is being referenced (e.g hdd1, hdd2 etc)
+ This attribute defaults to device 1.
certificate, signature, save_signature:
These attributes are used for certificate based authentication. This is
@@ -283,6 +303,7 @@ Description:
being configured allowing anyone to make changes.
After any of these operations the system must reboot for the changes to
take effect.
+ Admin and System certificates are supported from 2025 systems onward.
certificate_thumbprint:
Read only attribute used to display the MD5, SHA1 and SHA256 thumbprints
@@ -296,6 +317,15 @@ Description:
echo "signature" > authentication/Admin/signature
echo "password" > authentication/Admin/certificate_to_password
+ HP specific class extensions
+ --------------------------------
+
+ On HP systems the following additional settings are available:
+
+ role: enhanced-bios-auth:
+ This role is specific to Secure Platform Management (SPM) attribute.
+ It requires configuring an endorsement (kek) and signing certificate (sk).
+
What: /sys/class/firmware-attributes/*/attributes/pending_reboot
Date: February 2021
@@ -311,7 +341,7 @@ Description:
== =========================================
0 All BIOS attributes setting are current
1 A reboot is necessary to get pending BIOS
- attribute changes applied
+ attribute changes applied
== =========================================
Note, userspace applications need to follow below steps for efficient
@@ -354,6 +384,36 @@ Description:
Note that any changes to this attribute requires a reboot
for changes to take effect.
+What: /sys/class/firmware-attributes/*/attributes/save_settings
+Date: August 2023
+KernelVersion: 6.6
+Contact: Mark Pearson <mpearson-lenovo@squebb.ca>
+Description:
+ On Lenovo platforms there is a limitation in the number of times an attribute can be
+ saved. This is an architectural limitation and it limits the number of attributes
+ that can be modified to 48.
+ A solution for this is instead of the attribute being saved after every modification,
+ to allow a user to bulk set the attributes, and then trigger a final save. This allows
+ unlimited attributes.
+
+ Read the attribute to check what save mode is enabled (single or bulk).
+ E.g:
+ # cat /sys/class/firmware-attributes/thinklmi/attributes/save_settings
+ single
+
+ Write the attribute with 'bulk' to enable bulk save mode.
+ Write the attribute with 'single' to enable saving, after every attribute set.
+ The default setting is single mode.
+ E.g:
+ # echo bulk > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
+
+ When in bulk mode write 'save' to trigger a save of all currently modified attributes.
+ Note, once a save has been triggered, in bulk mode, attributes can no longer be set and
+ will return a permissions error. This is to prevent users hitting the 48+ save limitation
+ (which requires entering the BIOS to clear the error condition)
+ E.g:
+ # echo save > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
+
What: /sys/class/firmware-attributes/*/attributes/debug_cmd
Date: July 2021
KernelVersion: 5.14
@@ -364,3 +424,71 @@ Description:
use it to enable extra debug attributes or BIOS features for testing purposes.
Note that any changes to this attribute requires a reboot for changes to take effect.
+
+
+ HP specific class extensions - Secure Platform Manager (SPM)
+ --------------------------------
+
+What: /sys/class/firmware-attributes/*/authentication/SPM/kek
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'kek' Key-Encryption-Key is a write-only file that can be used to configure the
+ RSA public key that will be used by the BIOS to verify
+ signatures when setting the signing key. When written,
+ the bytes should correspond to the KEK certificate
+ (x509 .DER format containing an OU). The size of the
+ certificate must be less than or equal to 4095 bytes.
+
+What: /sys/class/firmware-attributes/*/authentication/SPM/sk
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'sk' Signature Key is a write-only file that can be used to configure the RSA
+ public key that will be used by the BIOS to verify signatures
+ when configuring BIOS settings and security features. When
+ written, the bytes should correspond to the modulus of the
+ public key. The exponent is assumed to be 0x10001.
+
+What: /sys/class/firmware-attributes/*/authentication/SPM/status
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'status' is a read-only file that returns ASCII text in JSON format reporting
+ the status information.
+
+ "State": "not provisioned | provisioned | provisioning in progress",
+ "Version": "Major.Minor",
+ "Nonce": <16-bit unsigned number display in base 10>,
+ "FeaturesInUse": <16-bit unsigned number display in base 10>,
+ "EndorsementKeyMod": "<256 bytes in base64>",
+ "SigningKeyMod": "<256 bytes in base64>"
+
+What: /sys/class/firmware-attributes/*/attributes/Sure_Start/audit_log_entries
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'audit_log_entries' is a read-only file that returns the events in the log.
+
+ Audit log entry format
+
+ Byte 0-15: Requested Audit Log entry (Each Audit log is 16 bytes)
+ Byte 16-127: Unused
+
+What: /sys/class/firmware-attributes/*/attributes/Sure_Start/audit_log_entry_count
+Date: March 2023
+KernelVersion: 5.18
+Contact: "Jorge Lopez" <jorge.lopez2@hp.com>
+Description:
+ 'audit_log_entry_count' is a read-only file that returns the number of existing
+ audit log events available to be read. Values are separated using comma. (``,``)
+
+ [No of entries],[log entry size],[Max number of entries supported]
+
+ log entry size identifies audit log size for the current BIOS version.
+ The current size is 16 bytes but it can be up to 128 bytes long in future BIOS
+ versions.
diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon
index 7271781a23b2..cfd0d0bab483 100644
--- a/Documentation/ABI/testing/sysfs-class-hwmon
+++ b/Documentation/ABI/testing/sysfs-class-hwmon
@@ -149,6 +149,15 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/inY_fault
+Description:
+ Reports a voltage hard failure (eg: shorted component)
+
+ - 1: Failed
+ - 0: Ok
+
+ RO
+
What: /sys/class/hwmon/hwmonX/cpuY_vid
Description:
CPU core reference voltage.
@@ -276,6 +285,15 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/fanY_fault
+Description:
+ Reports if a fan has reported failure.
+
+ - 1: Failed
+ - 0: Ok
+
+ RO
+
What: /sys/class/hwmon/hwmonX/pwmY
Description:
Pulse width modulation fan control.
@@ -372,6 +390,15 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/tempY_max_alarm
+Description:
+ Maximum temperature alarm flag.
+
+ - 0: OK
+ - 1: temperature has reached tempY_max
+
+ RO
+
What: /sys/class/hwmon/hwmonX/tempY_min
Description:
Temperature min value.
@@ -380,6 +407,15 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/tempY_min_alarm
+Description:
+ Minimum temperature alarm flag.
+
+ - 0: OK
+ - 1: temperature has reached tempY_min
+
+ RO
+
What: /sys/class/hwmon/hwmonX/tempY_max_hyst
Description:
Temperature hysteresis value for max limit.
@@ -425,12 +461,7 @@ Description:
- 0: OK
- 1: temperature has reached tempY_crit
- RW
-
- Contrary to regular alarm flags which clear themselves
- automatically when read, this one sticks until cleared by
- the user. This is done by writing 0 to the file. Writing
- other values is unsupported.
+ RO
What: /sys/class/hwmon/hwmonX/tempY_crit_hyst
Description:
@@ -453,6 +484,15 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/tempY_emergency_alarm
+Description:
+ Emergency high temperature alarm flag.
+
+ - 0: OK
+ - 1: temperature has reached tempY_emergency
+
+ RO
+
What: /sys/class/hwmon/hwmonX/tempY_emergency_hyst
Description:
Temperature hysteresis value for emergency limit.
@@ -878,15 +918,15 @@ Description:
RW
-What: /sys/class/hwmon/hwmonX/humidityY_input
+What: /sys/class/hwmon/hwmonX/humidityY_alarm
Description:
- Humidity
+ Humidity limit detection
- Unit: milli-percent (per cent mille, pcm)
+ - 0: OK
+ - 1: Humidity limit has been reached
RO
-
What: /sys/class/hwmon/hwmonX/humidityY_enable
Description:
Enable or disable the sensors
@@ -899,6 +939,92 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/humidityY_fault
+Description:
+ Reports a humidity sensor failure.
+
+ - 1: Failed
+ - 0: Ok
+
+ RO
+
+What: /sys/class/hwmon/hwmonX/humidityY_input
+Description:
+ Humidity
+
+ Unit: milli-percent (per cent mille, pcm)
+
+ RO
+
+What: /sys/class/hwmon/hwmonX/humidityY_label
+Description:
+ Suggested humidity channel label.
+
+ Text string
+
+ Should only be created if the driver has hints about what
+ this humidity channel is being used for, and user-space
+ doesn't. In all other cases, the label is provided by
+ user-space.
+
+ RO
+
+What: /sys/class/hwmon/hwmonX/humidityY_max
+Description:
+ Humidity max value.
+
+ Unit: milli-percent (per cent mille, pcm)
+
+ RW
+
+What: /sys/class/hwmon/hwmonX/humidityY_max_alarm
+Description:
+ Maximum humidity detection
+
+ - 0: OK
+ - 1: Maximum humidity detected
+
+ RO
+
+What: /sys/class/hwmon/hwmonX/humidityY_max_hyst
+Description:
+ Humidity hysteresis value for max limit.
+
+ Unit: milli-percent (per cent mille, pcm)
+
+ Must be reported as an absolute humidity, NOT a delta
+ from the max value.
+
+ RW
+
+What: /sys/class/hwmon/hwmonX/humidityY_min
+Description:
+ Humidity min value.
+
+ Unit: milli-percent (per cent mille, pcm)
+
+ RW
+
+What: /sys/class/hwmon/hwmonX/humidityY_min_alarm
+Description:
+ Minimum humidity detection
+
+ - 0: OK
+ - 1: Minimum humidity detected
+
+ RO
+
+What: /sys/class/hwmon/hwmonX/humidityY_min_hyst
+Description:
+ Humidity hysteresis value for min limit.
+
+ Unit: milli-percent (per cent mille, pcm)
+
+ Must be reported as an absolute humidity, NOT a delta
+ from the min value.
+
+ RW
+
What: /sys/class/hwmon/hwmonX/humidityY_rated_min
Description:
Minimum rated humidity.
diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt-features b/Documentation/ABI/testing/sysfs-class-intel_pmt-features
new file mode 100644
index 000000000000..cddb30e5bdf6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-intel_pmt-features
@@ -0,0 +1,134 @@
+What: /sys/class/intel_pmt/features-<PCI BDF>/
+Date: 2025-04-24
+KernelVersion: 6.16
+Contact: david.e.box@linux.intel.com
+Description:
+ The `features-<PCI BDF>/` directory represents the "features"
+ capability exposed by Intel PMT (Platform Monitoring Technology)
+ for the given PCI device.
+
+ Each directory corresponds to a PMT feature and contains
+ attributes describing the available telemetry, monitoring, or
+ control functionalities.
+
+Directory Structure:
+
+ /sys/class/intel_pmt/features-<PCI BDF>/
+ ├── accelerator_telemetry/ # Per-accelerator telemetry data
+ ├── crash_log/ # Contains system crash telemetry logs
+ ├── per_core_environment_telemetry/ # Environmental telemetry per core
+ ├── per_core_performance_telemetry/ # Performance telemetry per core
+ ├── per_rmid_energy_telemetry/ # Energy telemetry for RMIDs
+ ├── per_rmid_perf_telemetry/ # Performance telemetry for RMIDs
+ ├── tpmi_control/ # TPMI-related controls and telemetry
+ ├── tracing/ # PMT tracing features
+ └── uncore_telemetry/ # Uncore telemetry data
+
+Common Files (Present in all feature directories):
+
+ caps
+ - Read-only
+ - Lists available capabilities for this feature.
+
+ guids
+ - Read-only
+ - Lists GUIDs associated with this feature.
+
+Additional Attributes (Conditional Presence):
+
+ max_command_size
+ - Read-only
+ - Present if the feature supports out-of-band MCTP access.
+ - Maximum supported MCTP command size for out-of-band PMT access (bytes).
+
+ max_stream_size
+ - Read-only
+ - Present if the feature supports out-of-band MCTP access.
+ - Maximum supported MCTP stream size (bytes).
+
+ min_watcher_period_ms
+ - Read-only
+ - Present if the feature supports the watcher API.
+ The watcher API provides a writable control interface that allows user
+ configuration of monitoring behavior, such as setting the sampling or
+ reporting interval.
+ - Minimum supported time period for the watcher interface (milliseconds).
+
+ num_rmids
+ - Read-only
+ - Present if the feature supports RMID (Resource Monitoring ID) telemetry.
+ RMIDs are identifiers used by hardware to track and report resource usage,
+ such as memory bandwidth or energy consumption, on a per-logical-entity
+ basis (e.g., per core, thread, or process group).
+ - Maximum number of RMIDs tracked simultaneously.
+
+Example:
+For a device with PCI BDF `0000:00:03.1`, the directory tree could look like:
+
+ /sys/class/intel_pmt/features-0000:00:03.1/
+ ├── accelerator_telemetry/
+ │ ├── caps
+ │ ├── guids
+ │ ├── max_command_size
+ │ ├── max_stream_size
+ │ ├── min_watcher_period_ms
+ ├── crash_log/
+ │ ├── caps
+ │ ├── guids
+ │ ├── max_command_size
+ │ ├── max_stream_size
+ ├── per_core_environment_telemetry/
+ │ ├── caps
+ │ ├── guids
+ │ ├── max_command_size
+ │ ├── max_stream_size
+ │ ├── min_watcher_period_ms
+ ├── per_rmid_energy_telemetry/
+ │ ├── caps
+ │ ├── guids
+ │ ├── max_command_size
+ │ ├── max_stream_size
+ │ ├── min_watcher_period_ms
+ │ ├── num_rmids
+ ├── tpmi_control/
+ │ ├── caps
+ │ ├── guids
+ ├── tracing/
+ │ ├── caps
+ │ ├── guids
+ ├── uncore_telemetry/
+ │ ├── caps
+ │ ├── guids
+ │ ├── max_command_size
+ │ ├── max_stream_size
+ │ ├── min_watcher_period_ms
+
+Notes:
+ - Some attributes are only present if the corresponding feature supports
+ the capability (e.g., `max_command_size` for MCTP-capable features).
+ - Features supporting RMIDs include `num_rmids`.
+ - Features supporting the watcher API include `min_watcher_period_ms`.
+ - The `caps` file provides additional information about the functionality
+ of the feature.
+
+Example 'caps' content for the 'tracing' feature:
+
+ /sys/class/intel_pmt/features-0000:00:03.1/
+ ├── tracing/
+ │ ├── caps
+
+ telemetry Available: No
+ watcher Available: Yes
+ crashlog Available: No
+ streaming Available: No
+ threashold Available: No
+ window Available: No
+ config Available: Yes
+ tracing Available: No
+ inband Available: Yes
+ oob Available: Yes
+ secure_chan Available: No
+ pmt_sp Available: Yes
+ pmt_sp_policy Available: Yes
+ mailbox Available: Yes
+ bios_lock Available: Yes
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
index 2e24ac3bd7ef..0313b82644f2 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -72,6 +72,12 @@ Description:
/sys/class/leds/<led> once a given trigger is selected. For
their documentation see `sysfs-class-led-trigger-*`.
+ Writing "none" removes the trigger for this LED.
+
+ Writing "default" sets the trigger to the LED's default trigger
+ (which would often be configured in the device tree for the
+ hardware).
+
What: /sys/class/leds/<led>/inverted
Date: January 2011
KernelVersion: 2.6.38
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx b/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx
new file mode 100644
index 000000000000..6d4449cf9d71
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-aw200xx
@@ -0,0 +1,5 @@
+What: /sys/class/leds/<led>/dim
+Date: May 2023
+Description: 64-level DIM current. If you write a negative value or
+ "auto", the dim will be calculated according to the
+ brightness.
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia
index c4d46970c1cf..369b4ae8be5f 100644
--- a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia
@@ -12,3 +12,17 @@ Description: (RW) On the front panel of the Turris Omnia router there is also
able to change this setting from software.
Format: %i
+
+What: /sys/class/leds/<led>/device/gamma_correction
+Date: August 2023
+KernelVersion: 6.6
+Contact: Marek Behún <kabel@kernel.org>
+Description: (RW) Newer versions of the microcontroller firmware of the
+ Turris Omnia router support gamma correction for the RGB LEDs.
+ This feature can be enabled/disabled by writing to this file.
+
+ If the feature is not supported because the MCU firmware is too
+ old, the file always reads as 0, and writing to the file results
+ in the EOPNOTSUPP error.
+
+ Format: %i
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
index 646540950e38..ed46b37ab8a2 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
@@ -13,6 +13,11 @@ Description:
Specifies the duration of the LED blink in milliseconds.
Defaults to 50 ms.
+ When offloaded is true, the interval value MUST be set to the
+ default value and cannot be changed.
+ Trying to set any value in this specific mode will return
+ an EINVAL error.
+
What: /sys/class/leds/<led>/link
Date: Dec 2017
KernelVersion: 4.16
@@ -39,6 +44,9 @@ Description:
If set to 1, the LED will blink for the milliseconds specified
in interval to signal transmission.
+ When offloaded is true, the blink interval is controlled by
+ hardware and won't reflect the value set in interval.
+
What: /sys/class/leds/<led>/rx
Date: Dec 2017
KernelVersion: 4.16
@@ -50,3 +58,135 @@ Description:
If set to 1, the LED will blink for the milliseconds specified
in interval to signal reception.
+
+ When offloaded is true, the blink interval is controlled by
+ hardware and won't reflect the value set in interval.
+
+What: /sys/class/leds/<led>/offloaded
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Communicate whether the LED trigger modes are offloaded to
+ hardware or whether software fallback is used.
+
+ If 0, the LED is using software fallback to blink.
+
+ If 1, the LED blinking in requested mode is offloaded to
+ hardware.
+
+What: /sys/class/leds/<led>/link_10
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 10Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 10MBps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+ Present only if the named network device supports 10Mbps link speed.
+
+What: /sys/class/leds/<led>/link_100
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 100Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 100Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+ Present only if the named network device supports 100Mbps link speed.
+
+What: /sys/class/leds/<led>/link_1000
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 1000Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 1000Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+ Present only if the named network device supports 1000Mbps link speed.
+
+What: /sys/class/leds/<led>/link_2500
+Date: Nov 2023
+KernelVersion: 6.8
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 2500Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 2500Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+ Present only if the named network device supports 2500Mbps link speed.
+
+What: /sys/class/leds/<led>/link_5000
+Date: Nov 2023
+KernelVersion: 6.8
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 5000Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 5000Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+ Present only if the named network device supports 5000Mbps link speed.
+
+What: /sys/class/leds/<led>/link_10000
+Date: Nov 2023
+KernelVersion: 6.8
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link speed state of 10000Mbps of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link state
+ speed of 10000Mbps of the named network device.
+ Setting this value also immediately changes the LED state.
+
+ Present only if the named network device supports 10000Mbps link speed.
+
+What: /sys/class/leds/<led>/half_duplex
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link half duplex state of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link half
+ duplex state of the named network device.
+ Setting this value also immediately changes the LED state.
+
+What: /sys/class/leds/<led>/full_duplex
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: linux-leds@vger.kernel.org
+Description:
+ Signal the link full duplex state of the named network device.
+
+ If set to 0 (default), the LED's normal state is off.
+
+ If set to 1, the LED's normal state reflects the link full
+ duplex state of the named network device.
+ Setting this value also immediately changes the LED state.
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
index 8c57d2780554..22f28f2e9ac4 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
@@ -12,6 +12,16 @@ Description:
The exact format is described in:
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
+What: /sys/class/leds/<led>/hr_pattern
+Date: April 2024
+Description:
+ Specify a software pattern for the LED, that supports altering
+ the brightness for the specified duration with one software
+ timer. It can do gradual dimming and step change of brightness.
+
+ Unlike the /sys/class/leds/<led>/pattern, this attribute runs
+ a pattern on high-resolution timer (hrtimer).
+
What: /sys/class/leds/<led>/hw_pattern
Date: September 2018
KernelVersion: 4.20
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-tty b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
index 2bf6b24e781b..308fbc3627cd 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-tty
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-tty
@@ -1,6 +1,62 @@
-What: /sys/class/leds/<led>/ttyname
+What: /sys/class/leds/<tty_led>/ttyname
Date: Dec 2020
KernelVersion: 5.10
Contact: linux-leds@vger.kernel.org
Description:
Specifies the tty device name of the triggering tty
+
+What: /sys/class/leds/<tty_led>/rx
+Date: February 2024
+KernelVersion: 6.8
+Description:
+ Signal reception (rx) of data on the named tty device.
+ If set to 0, the LED will not blink on reception.
+ If set to 1 (default), the LED will blink on reception.
+
+What: /sys/class/leds/<tty_led>/tx
+Date: February 2024
+KernelVersion: 6.8
+Description:
+ Signal transmission (tx) of data on the named tty device.
+ If set to 0, the LED will not blink on transmission.
+ If set to 1 (default), the LED will blink on transmission.
+
+What: /sys/class/leds/<tty_led>/cts
+Date: February 2024
+KernelVersion: 6.8
+Description:
+ CTS = Clear To Send
+ DCE is ready to accept data from the DTE.
+ If the line state is detected, the LED is switched on.
+ If set to 0 (default), the LED will not evaluate CTS.
+ If set to 1, the LED will evaluate CTS.
+
+What: /sys/class/leds/<tty_led>/dsr
+Date: February 2024
+KernelVersion: 6.8
+Description:
+ DSR = Data Set Ready
+ DCE is ready to receive and send data.
+ If the line state is detected, the LED is switched on.
+ If set to 0 (default), the LED will not evaluate DSR.
+ If set to 1, the LED will evaluate DSR.
+
+What: /sys/class/leds/<tty_led>/dcd
+Date: February 2024
+KernelVersion: 6.8
+Description:
+ DCD = Data Carrier Detect
+ DTE is receiving a carrier from the DCE.
+ If the line state is detected, the LED is switched on.
+ If set to 0 (default), the LED will not evaluate CAR (DCD).
+ If set to 1, the LED will evaluate CAR (DCD).
+
+What: /sys/class/leds/<tty_led>/rng
+Date: February 2024
+KernelVersion: 6.8
+Description:
+ RNG = Ring Indicator
+ DCE has detected an incoming ring signal on the telephone
+ line. If the line state is detected, the LED is switched on.
+ If set to 0 (default), the LED will not evaluate RNG.
+ If set to 1, the LED will evaluate RNG.
diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
index 3bc7c0a95c92..f77fa4f6d465 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -39,7 +39,7 @@ KernelVersion: 2.6.29
Contact: linux-mtd@lists.infradead.org
Description:
Major and minor numbers of the character device corresponding
- to the read-only variant of thie MTD device (in
+ to the read-only variant of the MTD device (in
<major>:<minor> format). In this case <minor> will be odd.
What: /sys/class/mtd/mtdX/erasesize
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net
index 1419103d11f9..ebf21beba846 100644
--- a/Documentation/ABI/testing/sysfs-class-net
+++ b/Documentation/ABI/testing/sysfs-class-net
@@ -82,7 +82,7 @@ KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the current physical link state of the interface.
- Posssible values are:
+ Possible values are:
== =====================
0 physical link is down
diff --git a/Documentation/ABI/testing/sysfs-class-net-peak_usb b/Documentation/ABI/testing/sysfs-class-net-peak_usb
new file mode 100644
index 000000000000..9e3d0bf4d4b2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-peak_usb
@@ -0,0 +1,19 @@
+
+What: /sys/class/net/<iface>/peak_usb/can_channel_id
+Date: November 2022
+KernelVersion: 6.2
+Contact: Stephane Grosjean <s.grosjean@peak-system.com>
+Description:
+ PEAK PCAN-USB devices support user-configurable CAN channel
+ identifiers. Contrary to a USB serial number, these identifiers
+ are writable and can be set per CAN interface. This means that
+ if a USB device exports multiple CAN interfaces, each of them
+ can be assigned a unique channel ID.
+ This attribute provides read-only access to the currently
+ configured value of the channel identifier. Depending on the
+ device type, the identifier has a length of 8 or 32 bit. The
+ value read from this attribute is always an 8 digit 32 bit
+ hexadecimal value in big endian format. If the device only
+ supports an 8 bit identifier, the upper 24 bit of the value are
+ set to zero.
+
diff --git a/Documentation/ABI/testing/sysfs-class-net-phydev b/Documentation/ABI/testing/sysfs-class-net-phydev
index ac722dd5e694..31615c59bff9 100644
--- a/Documentation/ABI/testing/sysfs-class-net-phydev
+++ b/Documentation/ABI/testing/sysfs-class-net-phydev
@@ -26,6 +26,16 @@ Description:
This ID is used to match the device with the appropriate
driver.
+What: /sys/class/mdio_bus/<bus>/<device>/c45_phy_ids/mmd<n>_device_id
+Date: June 2025
+KernelVersion: 6.17
+Contact: netdev@vger.kernel.org
+Description:
+ This attribute contains the 32-bit PHY Identifier as reported
+ by the device during bus enumeration, encoded in hexadecimal.
+ These C45 IDs are used to match the device with the appropriate
+ driver. These files are invisible to the C22 device.
+
What: /sys/class/mdio_bus/<bus>/<device>/phy_interface
Date: February 2014
KernelVersion: 3.15
diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi b/Documentation/ABI/testing/sysfs-class-net-qmi
index 47e6b9732337..b028f5bc86db 100644
--- a/Documentation/ABI/testing/sysfs-class-net-qmi
+++ b/Documentation/ABI/testing/sysfs-class-net-qmi
@@ -62,7 +62,7 @@ Description:
What: /sys/class/net/<iface>/qmi/pass_through
Date: January 2021
KernelVersion: 5.12
-Contact: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
+Contact: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
Description:
Boolean. Default: 'N'
diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues
index 978b76358661..84aa25e0d14d 100644
--- a/Documentation/ABI/testing/sysfs-class-net-queues
+++ b/Documentation/ABI/testing/sysfs-class-net-queues
@@ -1,4 +1,4 @@
-What: /sys/class/<iface>/queues/rx-<queue>/rps_cpus
+What: /sys/class/net/<iface>/queues/rx-<queue>/rps_cpus
Date: March 2010
KernelVersion: 2.6.35
Contact: netdev@vger.kernel.org
@@ -8,7 +8,7 @@ Description:
network device queue. Possible values depend on the number
of available CPU(s) in the system.
-What: /sys/class/<iface>/queues/rx-<queue>/rps_flow_cnt
+What: /sys/class/net/<iface>/queues/rx-<queue>/rps_flow_cnt
Date: April 2010
KernelVersion: 2.6.35
Contact: netdev@vger.kernel.org
@@ -16,7 +16,7 @@ Description:
Number of Receive Packet Steering flows being currently
processed by this particular network device receive queue.
-What: /sys/class/<iface>/queues/tx-<queue>/tx_timeout
+What: /sys/class/net/<iface>/queues/tx-<queue>/tx_timeout
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
@@ -24,7 +24,7 @@ Description:
Indicates the number of transmit timeout events seen by this
network interface transmit queue.
-What: /sys/class/<iface>/queues/tx-<queue>/tx_maxrate
+What: /sys/class/net/<iface>/queues/tx-<queue>/tx_maxrate
Date: March 2015
KernelVersion: 4.1
Contact: netdev@vger.kernel.org
@@ -32,17 +32,17 @@ Description:
A Mbps max-rate set for the queue, a value of zero means disabled,
default is disabled.
-What: /sys/class/<iface>/queues/tx-<queue>/xps_cpus
+What: /sys/class/net/<iface>/queues/tx-<queue>/xps_cpus
Date: November 2010
KernelVersion: 2.6.38
Contact: netdev@vger.kernel.org
Description:
Mask of the CPU(s) currently enabled to participate into the
Transmit Packet Steering packet processing flow for this
- network device transmit queue. Possible vaules depend on the
+ network device transmit queue. Possible values depend on the
number of available CPU(s) in the system.
-What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
+What: /sys/class/net/<iface>/queues/tx-<queue>/xps_rxqs
Date: June 2018
KernelVersion: 4.18.0
Contact: netdev@vger.kernel.org
@@ -53,7 +53,7 @@ Description:
number of available receive queue(s) in the network device.
Default is disabled.
-What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
@@ -62,7 +62,7 @@ Description:
of this particular network device transmit queue.
Default value is 1000.
-What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
@@ -70,7 +70,7 @@ Description:
Indicates the number of bytes (objects) in flight on this
network device transmit queue.
-What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
@@ -79,7 +79,7 @@ Description:
on this network device transmit queue. This value is clamped
to be within the bounds defined by limit_max and limit_min.
-What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
@@ -88,7 +88,7 @@ Description:
queued on this network device transmit queue. See
include/linux/dynamic_queue_limits.h for the default value.
-What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
@@ -96,3 +96,26 @@ Description:
Indicates the absolute minimum limit of bytes allowed to be
queued on this network device transmit queue. Default value is
0.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_thrs
+Date: Jan 2024
+KernelVersion: 6.9
+Contact: netdev@vger.kernel.org
+Description:
+ Tx completion stall detection threshold in ms. Kernel will
+ guarantee to detect all stalls longer than this threshold but
+ may also detect stalls longer than half of the threshold.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_cnt
+Date: Jan 2024
+KernelVersion: 6.9
+Contact: netdev@vger.kernel.org
+Description:
+ Number of detected Tx completion stalls.
+
+What: /sys/class/net/<iface>/queues/tx-<queue>/byte_queue_limits/stall_max
+Date: Jan 2024
+KernelVersion: 6.9
+Contact: netdev@vger.kernel.org
+Description:
+ Longest detected Tx completion stall. Write 0 to clear.
diff --git a/Documentation/ABI/testing/sysfs-class-net-statistics b/Documentation/ABI/testing/sysfs-class-net-statistics
index 55db27815361..53e508c6936a 100644
--- a/Documentation/ABI/testing/sysfs-class-net-statistics
+++ b/Documentation/ABI/testing/sysfs-class-net-statistics
@@ -1,4 +1,4 @@
-What: /sys/class/<iface>/statistics/collisions
+What: /sys/class/net/<iface>/statistics/collisions
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -6,7 +6,7 @@ Description:
Indicates the number of collisions seen by this network device.
This value might not be relevant with all MAC layers.
-What: /sys/class/<iface>/statistics/multicast
+What: /sys/class/net/<iface>/statistics/multicast
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -14,7 +14,7 @@ Description:
Indicates the number of multicast packets received by this
network device.
-What: /sys/class/<iface>/statistics/rx_bytes
+What: /sys/class/net/<iface>/statistics/rx_bytes
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -23,7 +23,7 @@ Description:
See the network driver for the exact meaning of when this
value is incremented.
-What: /sys/class/<iface>/statistics/rx_compressed
+What: /sys/class/net/<iface>/statistics/rx_compressed
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -32,7 +32,7 @@ Description:
network device. This value might only be relevant for interfaces
that support packet compression (e.g: PPP).
-What: /sys/class/<iface>/statistics/rx_crc_errors
+What: /sys/class/net/<iface>/statistics/rx_crc_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -41,7 +41,7 @@ Description:
by this network device. Note that the specific meaning might
depend on the MAC layer used by the interface.
-What: /sys/class/<iface>/statistics/rx_dropped
+What: /sys/class/net/<iface>/statistics/rx_dropped
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -51,7 +51,7 @@ Description:
packet processing. See the network driver for the exact
meaning of this value.
-What: /sys/class/<iface>/statistics/rx_errors
+What: /sys/class/net/<iface>/statistics/rx_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -59,7 +59,7 @@ Description:
Indicates the number of receive errors on this network device.
See the network driver for the exact meaning of this value.
-What: /sys/class/<iface>/statistics/rx_fifo_errors
+What: /sys/class/net/<iface>/statistics/rx_fifo_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -68,7 +68,7 @@ Description:
network device. See the network driver for the exact
meaning of this value.
-What: /sys/class/<iface>/statistics/rx_frame_errors
+What: /sys/class/net/<iface>/statistics/rx_frame_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -78,7 +78,7 @@ Description:
on the MAC layer protocol used. See the network driver for
the exact meaning of this value.
-What: /sys/class/<iface>/statistics/rx_length_errors
+What: /sys/class/net/<iface>/statistics/rx_length_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -87,7 +87,7 @@ Description:
error, oversized or undersized. See the network driver for the
exact meaning of this value.
-What: /sys/class/<iface>/statistics/rx_missed_errors
+What: /sys/class/net/<iface>/statistics/rx_missed_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -96,7 +96,7 @@ Description:
due to lack of capacity in the receive side. See the network
driver for the exact meaning of this value.
-What: /sys/class/<iface>/statistics/rx_nohandler
+What: /sys/class/net/<iface>/statistics/rx_nohandler
Date: February 2016
KernelVersion: 4.6
Contact: netdev@vger.kernel.org
@@ -104,7 +104,7 @@ Description:
Indicates the number of received packets that were dropped on
an inactive device by the network core.
-What: /sys/class/<iface>/statistics/rx_over_errors
+What: /sys/class/net/<iface>/statistics/rx_over_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -114,7 +114,7 @@ Description:
(e.g: larger than MTU). See the network driver for the exact
meaning of this value.
-What: /sys/class/<iface>/statistics/rx_packets
+What: /sys/class/net/<iface>/statistics/rx_packets
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -122,7 +122,7 @@ Description:
Indicates the total number of good packets received by this
network device.
-What: /sys/class/<iface>/statistics/tx_aborted_errors
+What: /sys/class/net/<iface>/statistics/tx_aborted_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -132,7 +132,7 @@ Description:
a medium collision). See the network driver for the exact
meaning of this value.
-What: /sys/class/<iface>/statistics/tx_bytes
+What: /sys/class/net/<iface>/statistics/tx_bytes
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -143,7 +143,7 @@ Description:
transmitted packets or all packets that have been queued for
transmission.
-What: /sys/class/<iface>/statistics/tx_carrier_errors
+What: /sys/class/net/<iface>/statistics/tx_carrier_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -152,7 +152,7 @@ Description:
because of carrier errors (e.g: physical link down). See the
network driver for the exact meaning of this value.
-What: /sys/class/<iface>/statistics/tx_compressed
+What: /sys/class/net/<iface>/statistics/tx_compressed
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -161,7 +161,7 @@ Description:
this might only be relevant for devices that support
compression (e.g: PPP).
-What: /sys/class/<iface>/statistics/tx_dropped
+What: /sys/class/net/<iface>/statistics/tx_dropped
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -170,7 +170,7 @@ Description:
See the driver for the exact reasons as to why the packets were
dropped.
-What: /sys/class/<iface>/statistics/tx_errors
+What: /sys/class/net/<iface>/statistics/tx_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -179,7 +179,7 @@ Description:
a network device. See the driver for the exact reasons as to
why the packets were dropped.
-What: /sys/class/<iface>/statistics/tx_fifo_errors
+What: /sys/class/net/<iface>/statistics/tx_fifo_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -188,7 +188,7 @@ Description:
FIFO error. See the driver for the exact reasons as to why the
packets were dropped.
-What: /sys/class/<iface>/statistics/tx_heartbeat_errors
+What: /sys/class/net/<iface>/statistics/tx_heartbeat_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -197,7 +197,7 @@ Description:
reported as heartbeat errors. See the driver for the exact
reasons as to why the packets were dropped.
-What: /sys/class/<iface>/statistics/tx_packets
+What: /sys/class/net/<iface>/statistics/tx_packets
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
@@ -206,7 +206,7 @@ Description:
device. See the driver for whether this reports the number of all
attempted or successful transmissions.
-What: /sys/class/<iface>/statistics/tx_window_errors
+What: /sys/class/net/<iface>/statistics/tx_window_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
diff --git a/Documentation/ABI/testing/sysfs-class-pktcdvd b/Documentation/ABI/testing/sysfs-class-pktcdvd
deleted file mode 100644
index ba1ce626591d..000000000000
--- a/Documentation/ABI/testing/sysfs-class-pktcdvd
+++ /dev/null
@@ -1,97 +0,0 @@
-sysfs interface
----------------
-The pktcdvd module (packet writing driver) creates the following files in the
-sysfs: (<devid> is in the format major:minor)
-
-What: /sys/class/pktcdvd/add
-What: /sys/class/pktcdvd/remove
-What: /sys/class/pktcdvd/device_map
-Date: Oct. 2006
-KernelVersion: 2.6.20
-Contact: Thomas Maier <balagi@justmail.de>
-Description:
-
- ========== ==============================================
- add (WO) Write a block device id (major:minor) to
- create a new pktcdvd device and map it to the
- block device.
-
- remove (WO) Write the pktcdvd device id (major:minor)
- to remove the pktcdvd device.
-
- device_map (RO) Shows the device mapping in format:
- pktcdvd[0-7] <pktdevid> <blkdevid>
- ========== ==============================================
-
-
-What: /sys/class/pktcdvd/pktcdvd[0-7]/dev
-What: /sys/class/pktcdvd/pktcdvd[0-7]/uevent
-Date: Oct. 2006
-KernelVersion: 2.6.20
-Contact: Thomas Maier <balagi@justmail.de>
-Description:
- dev: (RO) Device id
-
- uevent: (WO) To send a uevent
-
-
-What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_started
-What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/packets_finished
-What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_written
-What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read
-What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/kb_read_gather
-What: /sys/class/pktcdvd/pktcdvd[0-7]/stat/reset
-Date: Oct. 2006
-KernelVersion: 2.6.20
-Contact: Thomas Maier <balagi@justmail.de>
-Description:
- packets_started: (RO) Number of started packets.
-
- packets_finished: (RO) Number of finished packets.
-
- kb_written: (RO) kBytes written.
-
- kb_read: (RO) kBytes read.
-
- kb_read_gather: (RO) kBytes read to fill write packets.
-
- reset: (WO) Write any value to it to reset
- pktcdvd device statistic values, like
- bytes read/written.
-
-
-What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/size
-What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_off
-What: /sys/class/pktcdvd/pktcdvd[0-7]/write_queue/congestion_on
-Date: Oct. 2006
-KernelVersion: 2.6.20
-Contact: Thomas Maier <balagi@justmail.de>
-Description:
- ============== ================================================
- size (RO) Contains the size of the bio write queue.
-
- congestion_off (RW) If bio write queue size is below this mark,
- accept new bio requests from the block layer.
-
- congestion_on (RW) If bio write queue size is higher as this
- mark, do no longer accept bio write requests
- from the block layer and wait till the pktcdvd
- device has processed enough bio's so that bio
- write queue size is below congestion off mark.
- A value of <= 0 disables congestion control.
- ============== ================================================
-
-
-Example:
---------
-To use the pktcdvd sysfs interface directly, you can do::
-
- # create a new pktcdvd device mapped to /dev/hdc
- echo "22:0" >/sys/class/pktcdvd/add
- cat /sys/class/pktcdvd/device_map
- # assuming device pktcdvd0 was created, look at stat's
- cat /sys/class/pktcdvd/pktcdvd0/stat/kb_written
- # print the device id of the mapped block device
- fgrep pktcdvd0 /sys/class/pktcdvd/device_map
- # remove device, using pktcdvd0 device id 253:0
- echo "253:0" >/sys/class/pktcdvd/remove
diff --git a/Documentation/ABI/testing/sysfs-class-platform-profile b/Documentation/ABI/testing/sysfs-class-platform-profile
new file mode 100644
index 000000000000..fcab26894ec3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-platform-profile
@@ -0,0 +1,50 @@
+What: /sys/class/platform-profile/platform-profile-X/name
+Date: March 2025
+KernelVersion: 6.14
+Description: Name of the class device given by the driver.
+
+ RO
+
+What: /sys/class/platform-profile/platform-profile-X/choices
+Date: March 2025
+KernelVersion: 6.14
+Description: This file contains a space-separated list of profiles supported
+ for this device.
+
+ Drivers must use the following standard profile-names:
+
+ ==================== ========================================
+ low-power Low power consumption
+ cool Cooler operation
+ quiet Quieter operation
+ balanced Balance between low power consumption
+ and performance
+ balanced-performance Balance between performance and low
+ power consumption with a slight bias
+ towards performance
+ performance High performance operation
+ max-power Higher performance operation that may exceed
+ internal battery draw limits when on AC power
+ custom Driver defined custom profile
+ ==================== ========================================
+
+ RO
+
+What: /sys/class/platform-profile/platform-profile-X/profile
+Date: March 2025
+KernelVersion: 6.14
+Description: Reading this file gives the current selected profile for this
+ device. Writing this file with one of the strings from
+ platform_profile_choices changes the profile to the new value.
+
+ This file can be monitored for changes by polling for POLLPRI,
+ POLLPRI will be signaled on any changes, independent of those
+ changes coming from a userspace write; or coming from another
+ source such as e.g. a hotkey triggered profile change handled
+ either directly by the embedded-controller or fully handled
+ inside the kernel.
+
+ This file may also emit the string 'custom' to indicate
+ that the driver is using a driver defined custom profile.
+
+ RW
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
index e434fc523291..4b21d5d23251 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -377,24 +377,60 @@ What: /sys/class/power_supply/<supply_name>/charge_type
Date: July 2009
Contact: linux-pm@vger.kernel.org
Description:
- Represents the type of charging currently being applied to the
- battery. "Trickle", "Fast", and "Standard" all mean different
- charging speeds. "Adaptive" means that the charger uses some
- algorithm to adjust the charge rate dynamically, without
- any user configuration required. "Custom" means that the charger
- uses the charge_control_* properties as configuration for some
- different algorithm. "Long Life" means the charger reduces its
- charging rate in order to prolong the battery health. "Bypass"
- means the charger bypasses the charging path around the
- integrated converter allowing for a "smart" wall adaptor to
- perform the power conversion externally.
+ Select the charging algorithm to use for a battery.
+
+ Standard:
+ Fully charge the battery at a moderate rate.
+ Fast:
+ Quickly charge the battery using fast-charge
+ technology. This is typically harder on the battery
+ than standard charging and may lower its lifespan.
+ Trickle:
+ Users who primarily operate the system while
+ plugged into an external power source can extend
+ battery life with this mode. Vendor tooling may
+ call this "Primarily AC Use".
+ Adaptive:
+ Automatically optimize battery charge rate based
+ on typical usage pattern.
+ Custom:
+ Use the charge_control_* properties to determine
+ when to start and stop charging. Advanced users
+ can use this to drastically extend battery life.
+ Long Life:
+ The charger reduces its charging rate in order to
+ prolong the battery health.
+ Bypass:
+ The charger bypasses the charging path around the
+ integrated converter allowing for a "smart" wall
+ adaptor to perform the power conversion externally.
Access: Read, Write
+ Reading this returns the current active value, e.g. 'Standard'.
+ Check charge_types to get the values supported by the battery.
+
Valid values:
"Unknown", "N/A", "Trickle", "Fast", "Standard",
"Adaptive", "Custom", "Long Life", "Bypass"
+What: /sys/class/power_supply/<supply_name>/charge_types
+Date: December 2024
+Contact: linux-pm@vger.kernel.org
+Description:
+ Identical to charge_type but reading returns a list of supported
+ charge-types with the currently active type surrounded by square
+ brackets, e.g.: "Fast [Standard] Long_Life".
+
+ power_supply class devices may support both charge_type and
+ charge_types for backward compatibility. In this case both will
+ always have the same active value and the active value can be
+ changed by writing either property.
+
+ Note charge-types which contain a space such as "Long Life" will
+ have the space replaced by a '_' resulting in e.g. "Long_Life".
+ When writing charge-types both variants are accepted.
+
What: /sys/class/power_supply/<supply_name>/charge_term_current
Date: July 2014
Contact: linux-pm@vger.kernel.org
@@ -417,10 +453,10 @@ Description:
Valid values:
"Unknown", "Good", "Overheat", "Dead",
- "Over voltage", "Unspecified failure", "Cold",
+ "Over voltage", "Under voltage", "Unspecified failure", "Cold",
"Watchdog timer expire", "Safety timer expire",
"Over current", "Calibration required", "Warm",
- "Cool", "Hot", "No battery"
+ "Cool", "Hot", "No battery", "Blown fuse", "Cell imbalance"
What: /sys/class/power_supply/<supply_name>/precharge_current
Date: June 2017
@@ -437,7 +473,8 @@ What: /sys/class/power_supply/<supply_name>/present
Date: May 2007
Contact: linux-pm@vger.kernel.org
Description:
- Reports whether a battery is present or not in the system.
+ Reports whether a battery is present or not in the system. If the
+ property does not exist, the battery is considered to be present.
Access: Read
@@ -471,11 +508,12 @@ Description:
Access: Read, Write
Valid values:
- ================ ====================================
- auto: Charge normally, respect thresholds
- inhibit-charge: Do not charge while AC is attached
- force-discharge: Force discharge while AC is attached
- ================ ====================================
+ ===================== ========================================
+ auto: Charge normally, respect thresholds
+ inhibit-charge: Do not charge while AC is attached
+ inhibit-charge-awake: inhibit-charge only when device is awake
+ force-discharge: Force discharge while AC is attached
+ ===================== ========================================
What: /sys/class/power_supply/<supply_name>/technology
Date: May 2007
@@ -515,6 +553,43 @@ Description:
Integer > 0: representing full cycles
Integer = 0: cycle_count info is not available
+What: /sys/class/power_supply/<supply_name>/internal_resistance
+Date: August 2025
+Contact: linux-arm-msm@vger.kernel.org
+Description:
+ Represent the battery's internal resistance, often referred
+ to as Equivalent Series Resistance (ESR). It is a dynamic
+ parameter that reflects the opposition to current flow within
+ the cell. It is not a fixed value but varies significantly
+ based on several operational conditions, including battery
+ state of charge (SoC), temperature, and whether the battery
+ is in a charging or discharging state.
+
+ Access: Read
+
+ Valid values: Represented in microohms
+
+What: /sys/class/power_supply/<supply_name>/state_of_health
+Date: August 2025
+Contact: linux-arm-msm@vger.kernel.org
+Description:
+ The state_of_health parameter quantifies the overall condition
+ of a battery as a percentage, reflecting its ability to deliver
+ rated performance relative to its original specifications. It is
+ dynamically computed using a combination of learned capacity
+ and impedance-based degradation indicators, both of which evolve
+ over the battery's lifecycle.
+ Note that the exact algorithms are kept secret by most battery
+ vendors and the value from different battery vendors cannot be
+ compared with each other as there is no vendor-agnostic definition
+ of "performance". Also this usually cannot be used for any
+ calculations (i.e. this is not the factor between charge_full and
+ charge_full_design).
+
+ Access: Read
+
+ Valid values: 0 - 100 (percent)
+
**USB Properties**
What: /sys/class/power_supply/<supply_name>/input_current_limit
@@ -591,7 +666,12 @@ Description:
the supply, for example it can show if USB-PD capable source
is attached.
- Access: Read-Only
+ Access: For power-supplies which consume USB power such
+ as battery charger chips, this indicates the type of
+ the connected USB power source and is Read-Only.
+
+ For power-supplies which act as a USB power-source such as
+ e.g. the UCS1002 USB Port Power Controller this is writable.
Valid values:
"Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
@@ -771,3 +851,55 @@ Description:
Access: Read
Valid values: 1-31
+
+What: /sys/class/power_supply/<supply_name>/extensions/<extension_name>
+Date: March 2025
+Contact: linux-pm@vger.kernel.org
+Description:
+ Reports the extensions registered to the power supply.
+ Each entry is a link to the device which registered the extension.
+
+ Access: Read
+
+What: /sys/class/power_supply/max8971-charger/fast_charge_timer
+Date: May 2025
+KernelVersion: 6.15.0
+Contact: Svyatoslav Ryhel <clamor95@gmail.com>
+Description:
+ This entry shows and sets the maximum time the max8971
+ charger operates in fast-charge mode. When the timer expires
+ the device will terminate fast-charge mode (charging current
+ will drop to 0 A) and will trigger interrupt.
+
+ Valid values:
+
+ - 4 - 10 (hours), step by 1
+ - 0: disabled.
+
+What: /sys/class/power_supply/max8971-charger/top_off_threshold_current
+Date: May 2025
+KernelVersion: 6.15.0
+Contact: Svyatoslav Ryhel <clamor95@gmail.com>
+Description:
+ This entry shows and sets the charging current threshold for
+ entering top-off charging mode. When charging current in fast
+ charge mode drops below this value, the charger will trigger
+ interrupt and start top-off charging mode.
+
+ Valid values:
+
+ - 50000 - 200000 (microamps), step by 50000 (rounded down)
+
+What: /sys/class/power_supply/max8971-charger/top_off_timer
+Date: May 2025
+KernelVersion: 6.15.0
+Contact: Svyatoslav Ryhel <clamor95@gmail.com>
+Description:
+ This entry shows and sets the maximum time the max8971
+ charger operates in top-off charge mode. When the timer expires
+ the device will terminate top-off charge mode (charging current
+ will drop to 0 A) and will trigger interrupt.
+
+ Valid values:
+
+ - 0 - 70 (minutes), step by 10 (rounded down)
diff --git a/Documentation/ABI/testing/sysfs-class-power-gaokun b/Documentation/ABI/testing/sysfs-class-power-gaokun
new file mode 100644
index 000000000000..0633aed7b355
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-gaokun
@@ -0,0 +1,27 @@
+What: /sys/class/power_supply/gaokun-ec-battery/smart_charge_delay
+Date: March 2025
+KernelVersion: 6.15
+Contact: Pengyu Luo <mitltlatltl@gmail.com>
+Description:
+ This entry allows configuration of smart charging delay.
+
+ Smart charging behavior: when the power adapter is connected
+ for delay hours, battery charging will follow the rules of
+ charge_control_start_threshold and charge_control_end_threshold.
+ For more information about charge control, please refer to
+ sysfs-class-power.
+
+ Access: Read, Write
+
+ Valid values: In hours (non-negative)
+
+What: /sys/class/power_supply/gaokun-ec-battery/battery_adaptive_charge
+Date: March 2025
+KernelVersion: 6.15
+Contact: Pengyu Luo <mitltlatltl@gmail.com>
+Description:
+ This entry allows enabling battery adaptive charging.
+
+ Access: Read, Write
+
+ Valid values: 0 (disabled) or 1 (enabled)
diff --git a/Documentation/ABI/testing/sysfs-class-power-max1720x b/Documentation/ABI/testing/sysfs-class-power-max1720x
new file mode 100644
index 000000000000..7d895bfda9ce
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-max1720x
@@ -0,0 +1,32 @@
+What: /sys/class/power_supply/max1720x/temp_ain1
+Date: January 2025
+KernelVersion: 6.14
+Contact: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+Description:
+ Reports the current temperature reading from AIN1 thermistor.
+
+ Access: Read
+
+ Valid values: Represented in 1/10 Degrees Celsius
+
+What: /sys/class/power_supply/max1720x/temp_ain2
+Date: January 2025
+KernelVersion: 6.14
+Contact: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+Description:
+ Reports the current temperature reading from AIN2 thermistor.
+
+ Access: Read
+
+ Valid values: Represented in 1/10 Degrees Celsius
+
+What: /sys/class/power_supply/max1720x/temp_int
+Date: January 2025
+KernelVersion: 6.14
+Contact: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+Description:
+ Reports the current temperature reading from internal die.
+
+ Access: Read
+
+ Valid values: Represented in 1/10 Degrees Celsius
diff --git a/Documentation/ABI/testing/sysfs-class-power-rt9467 b/Documentation/ABI/testing/sysfs-class-power-rt9467
new file mode 100644
index 000000000000..619b7c45d145
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-rt9467
@@ -0,0 +1,19 @@
+What: /sys/class/power_supply/rt9467-*/sysoff_enable
+Date: Feb 2023
+KernelVersion: 6.3
+Contact: ChiaEn Wu <chiaen_wu@richtek.com>
+Description:
+ This entry allows enabling the sysoff mode of rt9467 charger
+ devices.
+ If enabled and the input is removed, the internal battery FET
+ is turned off to reduce the leakage from the BAT pin. See
+ device datasheet for details. It's commonly used when the
+ product enter shipping stage. After entering shipping mode,
+ only 'VBUS' or 'Power key" pressed can make it leave this mode.
+ 'Disable' also can help to leave it, but it's more like to
+ abort the action before the device really enter shipping mode.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
diff --git a/Documentation/ABI/testing/sysfs-class-power-rt9471 b/Documentation/ABI/testing/sysfs-class-power-rt9471
new file mode 100644
index 000000000000..0a390ee5ac21
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-rt9471
@@ -0,0 +1,32 @@
+What: /sys/class/power_supply/rt9471-*/sysoff_enable
+Date: Feb 2023
+KernelVersion: 6.3
+Contact: ChiYuan Huang <cy_huang@richtek.com>
+Description:
+ This entry allows enabling the sysoff mode of rt9471 charger devices.
+ If enabled and the input is removed, the internal battery FET is turned
+ off to reduce the leakage from the BAT pin. See device datasheet for details.
+ It's commonly used when the product enter shipping stage. After entering
+ shipping mode, only 'VBUS' or 'Power key" pressed can make it leave this
+ mode. 'Disable' also can help to leave it, but it's more like to abort
+ the action before the device really enter shipping mode.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
+
+What: /sys/class/power_supply/rt9471-*/port_detect_enable
+Date: Feb 2023
+KernelVersion: 6.3
+Contact: ChiYuan Huang <cy_huang@richtek.com>
+Description:
+ This entry allows enabling the USB BC12 port detect function of rt9471 charger
+ devices. If enabled and VBUS is inserted, device will start to do the BC12
+ port detect and report the usb port type when port detect is done. See
+ datasheet for details. Normally controlled when TypeC/USBPD port integrated.
+
+ Access: Read, Write
+ Valid values:
+ - 1: enabled
+ - 0: disabled
diff --git a/Documentation/ABI/testing/sysfs-class-power-rt9756 b/Documentation/ABI/testing/sysfs-class-power-rt9756
new file mode 100644
index 000000000000..c4d6c2b4715d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-rt9756
@@ -0,0 +1,30 @@
+What: /sys/class/power_supply/rt9756-*/watchdog_timer
+Date: Dec 2025
+KernelVersion: 6.19
+Contact: ChiYuan Huang <cy_huang@richtek.com>
+Description:
+ This entry shows and sets the watchdog timer when rt9756 charger
+ operates in charging mode. When the timer expires, the device
+ will disable the charging. To prevent the timer expires, any
+ host communication can make the timer restarted.
+
+ Access: Read, Write
+
+ Valid values:
+ - 500, 1000, 5000, 30000, 40000, 80000, 128000 or 255000 (milliseconds),
+ - 0: disabled
+
+What: /sys/class/power_supply/rt9756-*/operation_mode
+Date: Dec 2025
+KernelVersion: 6.19
+Contact: ChiYuan Huang <cy_huang@richtek.com>
+Description:
+ This entry shows and set the operation mode when rt9756 charger
+ operates in charging phase. If 'bypass' mode is used, internal
+ path will connect vbus directly to vbat. Else, default 'div2'
+ mode for the switch-cap charging.
+
+ Access: Read, Write
+
+ Valid values:
+ - 'bypass' or 'div2'
diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco b/Documentation/ABI/testing/sysfs-class-power-wilco
index 82af180fcaab..083c4641b4c4 100644
--- a/Documentation/ABI/testing/sysfs-class-power-wilco
+++ b/Documentation/ABI/testing/sysfs-class-power-wilco
@@ -22,7 +22,7 @@ Description:
Long Life:
Customized charge rate for last longer battery life.
On Wilco device this mode is pre-configured in the factory
- through EC's private PID. Swiching to a different mode will
+ through EC's private PID. Switching to a different mode will
be denied by Wilco EC when Long Life mode is enabled.
What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold
diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc b/Documentation/ABI/testing/sysfs-class-remoteproc
index 0c9ee55098b8..b2b8e2db2503 100644
--- a/Documentation/ABI/testing/sysfs-class-remoteproc
+++ b/Documentation/ABI/testing/sysfs-class-remoteproc
@@ -81,7 +81,7 @@ Description: Remote processor coredump configuration
collected userspace will directly read from the remote
processor's device memory. Extra buffer will not be used to
copy the dump. Also recovery process will not proceed until
- all data is read by usersapce.
+ all data is read by userspace.
What: /sys/class/remoteproc/.../recovery
Date: July 2020
diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
new file mode 100644
index 000000000000..c9144d16003e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-tee
@@ -0,0 +1,15 @@
+What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
+Date: May 2024
+KernelVersion: 6.10
+Contact: op-tee@lists.trustedfirmware.org
+Description:
+ RPMB frames can be routed to the RPMB device via the
+ user-space daemon tee-supplicant or the RPMB subsystem
+ in the kernel. The value "user" means that the driver
+ will route the RPMB frames via user space. Conversely,
+ "kernel" means that the frames are routed via the RPMB
+ subsystem without assistance from tee-supplicant. It
+ should be assumed that RPMB frames are routed via user
+ space if the variable is absent. The primary purpose
+ of this variable is to let systemd know whether
+ tee-supplicant is needed in the early boot with initramfs.
diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal
index 8eee37982b2a..968d89e15e8e 100644
--- a/Documentation/ABI/testing/sysfs-class-thermal
+++ b/Documentation/ABI/testing/sysfs-class-thermal
@@ -4,7 +4,7 @@ Description:
This is given by thermal zone driver as part of registration.
E.g: "acpitz" indicates it's an ACPI thermal device.
In order to keep it consistent with hwmon sys attribute; this
- shouldbe a short, lowercase string, not containing spaces nor
+ should be a short, lowercase string, not containing spaces nor
dashes.
RO, Required
diff --git a/Documentation/ABI/testing/sysfs-class-tsm b/Documentation/ABI/testing/sysfs-class-tsm
new file mode 100644
index 000000000000..6fc1a5ac6da1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-tsm
@@ -0,0 +1,19 @@
+What: /sys/class/tsm/tsmN
+Contact: linux-coco@lists.linux.dev
+Description:
+ "tsmN" is a device that represents the generic attributes of a
+ platform TEE Security Manager. It is typically a child of a
+ platform enumerated TSM device. /sys/class/tsm/tsmN/uevent
+ signals when the PCI layer is able to support establishment of
+ link encryption and other device-security features coordinated
+ through a platform tsm.
+
+What: /sys/class/tsm/tsmN/streamH.R.E
+Contact: linux-pci@vger.kernel.org
+Description:
+ (RO) When a host bridge has established a secure connection via
+ the platform TSM, symlink appears. The primary function of this
+ is have a system global review of TSM resource consumption
+ across host bridges. The link points to the endpoint PCI device
+ and matches the same link published by the host bridge. See
+ Documentation/ABI/testing/sysfs-devices-pci-host-bridge.
diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec
index 281b995beb05..38e101c17a00 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -149,6 +149,19 @@ Description:
advertise to the partner. The currently used capabilities are in
brackets. Selection happens by writing to the file.
+What: /sys/class/typec/<port>/usb_capability
+Date: November 2024
+Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description: Lists the supported USB Modes. The default USB mode that is used
+ next time with the Enter_USB Message is in brackets. The default
+ mode can be changed by writing to the file when supported by the
+ driver.
+
+ Valid values:
+ - usb2 (USB 2.0)
+ - usb3 (USB 3.2)
+ - usb4 (USB4)
+
USB Type-C partner devices (eg. /sys/class/typec/port0-partner/)
What: /sys/class/typec/<port>-partner/accessory_mode
@@ -220,6 +233,20 @@ Description:
directory exists, it will have an attribute file for every VDO
in Discover Identity command result.
+What: /sys/class/typec/<port>-partner/usb_mode
+Date: November 2024
+Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description: The USB Modes that the partner device supports. The active mode
+ is displayed in brackets. The active USB mode can be changed by
+ writing to this file when the port driver is able to send Data
+ Reset Message to the partner. That requires USB Power Delivery
+ contract between the partner and the port.
+
+ Valid values:
+ - usb2 (USB 2.0)
+ - usb3 (USB 3.2)
+ - usb4 (USB4)
+
USB Type-C cable devices (eg. /sys/class/typec/port0-cable/)
Note: Electronically Marked Cables will have a device also for one cable plug
diff --git a/Documentation/ABI/testing/sysfs-class-usb_power_delivery b/Documentation/ABI/testing/sysfs-class-usb_power_delivery
index ce2b1b563cb3..c754458a527e 100644
--- a/Documentation/ABI/testing/sysfs-class-usb_power_delivery
+++ b/Documentation/ABI/testing/sysfs-class-usb_power_delivery
@@ -69,7 +69,7 @@ Description:
This file contains boolean value that tells does the device
support both source and sink power roles.
-What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_suspend_supported
+What: /sys/class/usb_power_delivery/.../source-capabilities/1:fixed_supply/usb_suspend_supported
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
@@ -78,6 +78,15 @@ Description:
will follow the USB 2.0 and USB 3.2 rules for suspend and
resume.
+What: /sys/class/usb_power_delivery/.../sink-capabilities/1:fixed_supply/higher_capability
+Date: February 2023
+Contact: Saranya Gopal <saranya.gopal@linux.intel.com>
+Description:
+ This file shows the value of the Higher capability bit in
+ vsafe5V Fixed Supply Object. If the bit is set, then the sink
+ needs more than vsafe5V(eg. 12 V) to provide full functionality.
+ Valid values: 0, 1
+
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unconstrained_power
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
@@ -115,6 +124,13 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The voltage the supply supports in millivolts.
+What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/peak_current
+Date: October 2023
+Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description:
+ This file shows the value of the Fixed Power Source Peak Current
+ Capability field.
+
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
@@ -238,3 +254,31 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The PPS Power Limited bit indicates whether or not the source
supply will exceed the rated output power if requested.
+
+Standard Power Range (SPR) Adjustable Voltage Supplies
+
+What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply
+Date: Oct 2025
+Contact: Badhri Jagan Sridharan <badhri@google.com>
+Description:
+ Adjustable Voltage Supply (AVS) Augmented PDO (APDO).
+
+What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply/maximum_current_9V_to_15V
+Date: Oct 2025
+Contact: Badhri Jagan Sridharan <badhri@google.com>
+Description:
+ Maximum Current for 9V to 15V range in milliamperes.
+
+What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply/maximum_current_15V_to_20V
+Date: Oct 2025
+Contact: Badhri Jagan Sridharan <badhri@google.com>
+Description:
+ Maximum Current for greater than 15V till 20V range in
+ milliamperes.
+
+What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply/peak_current
+Date: Oct 2025
+Contact: Badhri Jagan Sridharan <badhri@google.com>
+Description:
+ This file shows the value of the Adjustable Voltage Supply Peak Current
+ Capability field.
diff --git a/Documentation/ABI/testing/sysfs-class-usb_role b/Documentation/ABI/testing/sysfs-class-usb_role
index 3b810a425a52..9fab3f06679e 100644
--- a/Documentation/ABI/testing/sysfs-class-usb_role
+++ b/Documentation/ABI/testing/sysfs-class-usb_role
@@ -19,3 +19,9 @@ Description:
- none
- host
- device
+
+What: /sys/class/usb_role/<switch>/connector
+Date: Feb 2024
+Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Description:
+ Optional symlink to the USB Type-C connector.
diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc b/Documentation/ABI/testing/sysfs-class-uwb_rc
deleted file mode 100644
index a7ea169dc4eb..000000000000
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc
+++ /dev/null
@@ -1,156 +0,0 @@
-What: /sys/class/uwb_rc
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Interfaces for WiMedia Ultra Wideband Common Radio
- Platform (UWB) radio controllers.
-
- Familiarity with the ECMA-368 'High Rate Ultra
- Wideband MAC and PHY Specification' is assumed.
-
-What: /sys/class/uwb_rc/beacon_timeout_ms
-Date: July 2008
-KernelVersion: 2.6.27
-Description:
- If no beacons are received from a device for at least
- this time, the device will be considered to have gone
- and it will be removed. The default is 3 superframes
- (~197 ms) as required by the specification.
-
-What: /sys/class/uwb_rc/uwb<N>/
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- An individual UWB radio controller.
-
-What: /sys/class/uwb_rc/uwb<N>/beacon
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Write:
-
- <channel>
-
- to force a specific channel to be used when beaconing,
- or, if <channel> is -1, to prohibit beaconing. If
- <channel> is 0, then the default channel selection
- algorithm will be used. Valid channels depends on the
- radio controller's supported band groups.
-
- Reading returns the currently active channel, or -1 if
- the radio controller is not beaconing.
-
-What: /sys/class/uwb_rc/uwb<N>/ASIE
-Date: August 2014
-KernelVersion: 3.18
-Contact: linux-usb@vger.kernel.org
-Description:
-
- The application-specific information element (ASIE)
- included in this device's beacon, in space separated
- hex octets.
-
- Reading returns the current ASIE. Writing replaces
- the current ASIE with the one written.
-
-What: /sys/class/uwb_rc/uwb<N>/scan
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Write:
-
- <channel> <type> [<bpst offset>]
-
- to start (or stop) scanning on a channel. <type> is one of:
-
- == =======================================
- 0 scan
- 1 scan outside BP
- 2 scan while inactive
- 3 scanning disabled
- 4 scan (with start time of <bpst offset>)
- == =======================================
-
-What: /sys/class/uwb_rc/uwb<N>/mac_address
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The EUI-48, in colon-separated hex octets, for this
- radio controller. A write will change the radio
- controller's EUI-48 but only do so while the device is
- not beaconing or scanning.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- A symlink to the device (if any) of the WUSB Host
- Controller PAL using this radio controller.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- A neighbour UWB device that has either been detected
- as part of a scan or is a member of the radio
- controllers beacon group.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/BPST
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The time (using the radio controllers internal 1 ms
- interval superframe timer) of the last beacon from
- this device was received.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/DevAddr
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The current DevAddr of this device in colon separated
- hex octets.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/EUI_48
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
-
- The EUI-48 of this device in colon separated hex
- octets.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/IEs
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- The latest IEs included in this device's beacon, in
- space separated hex octets with one IE per line.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/LQE
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Link Quality Estimate - the Signal to Noise Ratio
- (SNR) of all packets received from this device in dB.
- This gives an estimate on a suitable PHY rate. Refer
- to [ECMA-368] section 13.3 for more details.
-
-What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/RSSI
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: linux-usb@vger.kernel.org
-Description:
- Received Signal Strength Indication - the strength of
- the received signal in dB. LQE is a more useful
- measure of the radio link quality.
diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
deleted file mode 100644
index 55eb55cac92e..000000000000
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
+++ /dev/null
@@ -1,57 +0,0 @@
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_chid
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Write the CHID (16 space-separated hex octets) for this host controller.
- This starts the host controller, allowing it to accept connection from
- WUSB devices.
-
- Set an all zero CHID to stop the host controller.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_trust_timeout
-Date: July 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Devices that haven't sent a WUSB packet to the host
- within 'wusb_trust_timeout' ms are considered to have
- disconnected and are removed. The default value of
- 4000 ms is the value required by the WUSB
- specification.
-
- Since this relates to security (specifically, the
- lifetime of PTKs and GTKs) it should not be changed
- from the default.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_phy_rate
-Date: August 2009
-KernelVersion: 2.6.32
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The maximum PHY rate to use for all connected devices.
- This is only of limited use for testing and
- development as the hardware's automatic rate
- adaptation is better then this simple control.
-
- Refer to [ECMA-368] section 10.3.1.1 for the value to
- use.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_dnts
-Date: June 2013
-KernelVersion: 3.11
-Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
-Description:
- The device notification time slot (DNTS) count and inverval in
- milliseconds that the WUSB host should use. This controls how
- often the devices will have the opportunity to send
- notifications to the host.
-
-What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_retry_count
-Date: June 2013
-KernelVersion: 3.11
-Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
-Description:
- The number of retries that the WUSB host should attempt
- before reporting an error for a bus transaction. The range of
- valid values is [0..15], where 0 indicates infinite retries.
diff --git a/Documentation/ABI/testing/sysfs-class-watchdog b/Documentation/ABI/testing/sysfs-class-watchdog
index 585caecda3a5..70eabccf0557 100644
--- a/Documentation/ABI/testing/sysfs-class-watchdog
+++ b/Documentation/ABI/testing/sysfs-class-watchdog
@@ -6,6 +6,19 @@ Description:
device at boot. It is equivalent to WDIOC_GETBOOTSTATUS of
ioctl interface.
+What: /sys/class/watchdog/watchdogn/options
+Date: April 2023
+Contact: Thomas Weißschuh
+Description:
+ It is a read only file. It contains options of watchdog device.
+
+What: /sys/class/watchdog/watchdogn/fw_version
+Date: April 2023
+Contact: Thomas Weißschuh
+Description:
+ It is a read only file. It contains firmware version of
+ watchdog device.
+
What: /sys/class/watchdog/watchdogn/identity
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
@@ -63,7 +76,7 @@ Description:
timeout when the pretimeout interrupt is delivered. Pretimeout
is an optional feature.
-What: /sys/class/watchdog/watchdogn/pretimeout_avaialable_governors
+What: /sys/class/watchdog/watchdogn/pretimeout_available_governors
Date: February 2017
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
diff --git a/Documentation/ABI/testing/sysfs-devices-mapping b/Documentation/ABI/testing/sysfs-devices-mapping
index 8d202bac9394..2eee1446ad4c 100644
--- a/Documentation/ABI/testing/sysfs-devices-mapping
+++ b/Documentation/ABI/testing/sysfs-devices-mapping
@@ -1,6 +1,6 @@
What: /sys/devices/uncore_iio_x/dieX
Date: February 2020
-Contact: Roman Sudarikov <roman.sudarikov@linux.intel.com>
+Contact: Alexander Antonov <alexander.antonov@linux.intel.com>
Description:
Each IIO stack (PCIe root port) has its own IIO PMON block, so
each dieX file (where X is die number) holds "Segment:Root Bus"
@@ -32,3 +32,31 @@ Description:
IIO PMU 0 on die 1 belongs to PCI RP on bus 0x40, domain 0x0000
IIO PMU 0 on die 2 belongs to PCI RP on bus 0x80, domain 0x0000
IIO PMU 0 on die 3 belongs to PCI RP on bus 0xc0, domain 0x0000
+
+What: /sys/devices/uncore_upi_x/dieX
+Date: March 2022
+Contact: Alexander Antonov <alexander.antonov@linux.intel.com>
+Description:
+ Each /sys/devices/uncore_upi_X/dieY file holds "upi_Z,die_W"
+ value that means UPI link number X on die Y is connected to UPI
+ link Z on die W and this link between sockets can be monitored
+ by UPI PMON block.
+ For example, 4-die Sapphire Rapids platform has the following
+ UPI 0 topology::
+
+ # tail /sys/devices/uncore_upi_0/die*
+ ==> /sys/devices/uncore_upi_0/die0 <==
+ upi_1,die_1
+ ==> /sys/devices/uncore_upi_0/die1 <==
+ upi_0,die_3
+ ==> /sys/devices/uncore_upi_0/die2 <==
+ upi_1,die_3
+ ==> /sys/devices/uncore_upi_0/die3 <==
+ upi_0,die_1
+
+ Which means::
+
+ UPI link 0 on die 0 is connected to UPI link 1 on die 1
+ UPI link 0 on die 1 is connected to UPI link 0 on die 3
+ UPI link 0 on die 2 is connected to UPI link 1 on die 3
+ UPI link 0 on die 3 is connected to UPI link 0 on die 1 \ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory
index d8b0f80b9e33..cec65827e602 100644
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -110,3 +110,11 @@ Description:
link is created for memory section 9 on node0.
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
+
+What: /sys/devices/system/memory/crash_hotplug
+Date: Aug 2023
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ (RO) indicates whether or not the kernel updates relevant kexec
+ segments on memory hot un/plug and/or on/offline events, avoiding the
+ need to reload kdump kernel.
diff --git a/Documentation/ABI/testing/sysfs-devices-online b/Documentation/ABI/testing/sysfs-devices-online
index f990026c0740..c3359fec2980 100644
--- a/Documentation/ABI/testing/sysfs-devices-online
+++ b/Documentation/ABI/testing/sysfs-devices-online
@@ -17,4 +17,4 @@ Description:
After a successful execution of the bus type's .offline()
callback the device cannot be used for any purpose until either
it is removed (i.e. device_del() is called for it), or its bus
- type's .online() is exeucted successfully.
+ type's .online() is executed successfully.
diff --git a/Documentation/ABI/testing/sysfs-devices-pci-host-bridge b/Documentation/ABI/testing/sysfs-devices-pci-host-bridge
new file mode 100644
index 000000000000..b91ec3450811
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-pci-host-bridge
@@ -0,0 +1,45 @@
+What: /sys/devices/pciDDDD:BB
+ /sys/devices/.../pciDDDD:BB
+Contact: linux-pci@vger.kernel.org
+Description:
+ A PCI host bridge device parents a PCI bus device topology. PCI
+ controllers may also parent host bridges. The DDDD:BB format
+ conveys the PCI domain (ACPI segment) number and root bus number
+ (in hexadecimal) of the host bridge. Note that the domain number
+ may be larger than the 16-bits that the "DDDD" format implies
+ for emulated host-bridges.
+
+What: pciDDDD:BB/firmware_node
+Contact: linux-pci@vger.kernel.org
+Description:
+ (RO) Symlink to the platform firmware device object "companion"
+ of the host bridge. For example, an ACPI device with an _HID of
+ PNP0A08 (/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00). See
+ /sys/devices/pciDDDD:BB entry for details about the DDDD:BB
+ format.
+
+What: pciDDDD:BB/streamH.R.E
+Contact: linux-pci@vger.kernel.org
+Description:
+ (RO) When a platform has established a secure connection, PCIe
+ IDE, between two Partner Ports, this symlink appears. A stream
+ consumes a Stream ID slot in each of the Host bridge (H), Root
+ Port (R) and Endpoint (E). The link points to the Endpoint PCI
+ device in the Selective IDE Stream pairing. Specifically, "R"
+ and "E" represent the assigned Selective IDE Stream Register
+ Block in the Root Port and Endpoint, and "H" represents a
+ platform specific pool of stream resources shared by the Root
+ Ports in a host bridge. See /sys/devices/pciDDDD:BB entry for
+ details about the DDDD:BB format.
+
+What: pciDDDD:BB/available_secure_streams
+Contact: linux-pci@vger.kernel.org
+Description:
+ (RO) When a host bridge has Root Ports that support PCIe IDE
+ (link encryption and integrity protection) there may be a
+ limited number of Selective IDE Streams that can be used for
+ establishing new end-to-end secure links. This attribute
+ decrements upon secure link setup, and increments upon secure
+ link teardown. The in-use stream count is determined by counting
+ stream symlinks. See /sys/devices/pciDDDD:BB entry for details
+ about the DDDD:BB format.
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs b/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
new file mode 100644
index 000000000000..d1b3a95a5518
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
@@ -0,0 +1,126 @@
+What: /sys/devices/platform/HISI04Bx:00/chipX/all_linked
+What: /sys/devices/platform/HISI04Bx:00/chipX/linked_full_lane
+What: /sys/devices/platform/HISI04Bx:00/chipX/crc_err_cnt
+Date: November 2023
+KernelVersion: 6.6
+Contact: Huisong Li <lihuisong@huawei.com>
+Description:
+ The /sys/devices/platform/HISI04Bx:00/chipX/ directory
+ contains read-only attributes exposing some summarization
+ information of all HCCS ports under a specified chip.
+ The X in 'chipX' indicates the Xth chip on platform.
+
+ There are following attributes in this directory:
+
+ ================= ==== =========================================
+ all_linked: (RO) if all enabled ports on this chip are
+ linked (bool).
+ linked_full_lane: (RO) if all linked ports on this chip are full
+ lane (bool).
+ crc_err_cnt: (RO) total CRC err count for all ports on this
+ chip.
+ ================= ==== =========================================
+
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/all_linked
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/linked_full_lane
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/crc_err_cnt
+Date: November 2023
+KernelVersion: 6.6
+Contact: Huisong Li <lihuisong@huawei.com>
+Description:
+ The /sys/devices/platform/HISI04Bx:00/chipX/dieY/ directory
+ contains read-only attributes exposing some summarization
+ information of all HCCS ports under a specified die.
+ The Y in 'dieY' indicates the hardware id of the die on chip who
+ has chip id X.
+
+ There are following attributes in this directory:
+
+ ================= ==== =========================================
+ all_linked: (RO) if all enabled ports on this die are
+ linked (bool).
+ linked_full_lane: (RO) if all linked ports on this die are full
+ lane (bool).
+ crc_err_cnt: (RO) total CRC err count for all ports on this
+ die.
+ ================= ==== =========================================
+
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/type
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/lane_mode
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/enable
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/cur_lane_num
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/link_fsm
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/lane_mask
+What: /sys/devices/platform/HISI04Bx:00/chipX/dieY/hccsN/crc_err_cnt
+Date: November 2023
+KernelVersion: 6.6
+Contact: Huisong Li <lihuisong@huawei.com>
+Description:
+ The /sys/devices/platform/HISI04Bx/chipX/dieX/hccsN/ directory
+ contains read-only attributes exposing information about
+ a HCCS port. The N value in 'hccsN' indicates this port id.
+ The X in 'chipX' indicates the ID of the chip to which the
+ HCCS port belongs. For example, X ranges from to 'n - 1' if the
+ chip number on platform is n.
+ The Y in 'dieY' indicates the hardware id of the die to which
+ the hccs port belongs.
+ Note: type, lane_mode and enable are fixed attributes on running
+ platform.
+
+ The HCCS port have the following attributes:
+
+ ============= ==== =============================================
+ type: (RO) port type (string), e.g. HCCS-v1 -> H32
+ lane_mode: (RO) the lane mode of this port (string), e.g. x8
+ enable: (RO) indicate if this port is enabled (bool).
+ cur_lane_num: (RO) current lane number of this port.
+ link_fsm: (RO) link finite state machine of this port.
+ lane_mask: (RO) current lane mask of this port, every bit
+ indicates a lane.
+ crc_err_cnt: (RO) CRC err count on this port.
+ ============= ==== =============================================
+
+What: /sys/devices/platform/HISI04Bx:00/used_types
+Date: August 2024
+KernelVersion: 6.12
+Contact: Huisong Li <lihuisong@huawei.com>
+Description:
+ This interface is used to show all HCCS types used on the
+ platform, like, HCCS-v1, HCCS-v2 and so on.
+
+What: /sys/devices/platform/HISI04Bx:00/available_inc_dec_lane_types
+What: /sys/devices/platform/HISI04Bx:00/dec_lane_of_type
+What: /sys/devices/platform/HISI04Bx:00/inc_lane_of_type
+Date: August 2024
+KernelVersion: 6.12
+Contact: Huisong Li <lihuisong@huawei.com>
+Description:
+ These interfaces under /sys/devices/platform/HISI04Bx/ are
+ used to support the low power consumption feature of some
+ HCCS types by changing the number of lanes used. The interfaces
+ changing the number of lanes used are 'dec_lane_of_type' and
+ 'inc_lane_of_type' which require root privileges. These
+ interfaces aren't exposed if no HCCS type on platform support
+ this feature. Please note that decreasing lane number is only
+ allowed if all the specified HCCS ports are not busy.
+
+ The low power consumption interfaces are as follows:
+
+ ============================= ==== ================================
+ available_inc_dec_lane_types: (RO) available HCCS types (string) to
+ increase and decrease the number
+ of lane used, e.g. HCCS-v2.
+ dec_lane_of_type: (WO) input HCCS type supported
+ decreasing lane to decrease the
+ used lane number of all specified
+ HCCS type ports on platform to
+ the minimum.
+ You can query the 'cur_lane_num'
+ to get the minimum lane number
+ after executing successfully.
+ inc_lane_of_type: (WO) input HCCS type supported
+ increasing lane to increase the
+ used lane number of all specified
+ HCCS type ports on platform to
+ the full lane state.
+ ============================= ==== ================================
diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power
index 54195530e97a..9bf7c8a267c5 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -1,6 +1,6 @@
What: /sys/devices/.../power/
Date: January 2009
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power directory contains attributes
allowing the user space to check and modify some power
@@ -8,7 +8,7 @@ Description:
What: /sys/devices/.../power/wakeup
Date: January 2009
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power/wakeup attribute allows the user
space to check if the device is enabled to wake up the system
@@ -34,7 +34,7 @@ Description:
What: /sys/devices/.../power/control
Date: January 2009
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power/control attribute allows the user
space to control the run-time power management of the device.
@@ -53,10 +53,10 @@ Description:
What: /sys/devices/.../power/async
Date: January 2009
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../async attribute allows the user space to
- enable or diasble the device's suspend and resume callbacks to
+ enable or disable the device's suspend and resume callbacks to
be executed asynchronously (ie. in separate threads, in parallel
with the main suspend/resume thread) during system-wide power
transitions (eg. suspend to RAM, hibernation).
@@ -79,7 +79,7 @@ Description:
What: /sys/devices/.../power/wakeup_count
Date: September 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
@@ -90,7 +90,7 @@ Description:
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_active_count attribute contains the
number of times the processing of wakeup events associated with
@@ -102,7 +102,7 @@ Description:
What: /sys/devices/.../power/wakeup_abort_count
Date: February 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_abort_count attribute contains the
number of times the processing of a wakeup event associated with
@@ -114,7 +114,7 @@ Description:
What: /sys/devices/.../power/wakeup_expire_count
Date: February 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_expire_count attribute contains the
number of times a wakeup event associated with the device has
@@ -126,7 +126,7 @@ Description:
What: /sys/devices/.../power/wakeup_active
Date: September 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_active attribute contains either 1,
or 0, depending on whether or not a wakeup event associated with
@@ -138,7 +138,7 @@ Description:
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_total_time_ms attribute contains
the total time of processing wakeup events associated with the
@@ -149,7 +149,7 @@ Description:
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_max_time_ms attribute contains
the maximum time of processing a single wakeup event associated
@@ -161,7 +161,7 @@ Description:
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_last_time_ms attribute contains
the value of the monotonic clock corresponding to the time of
@@ -173,7 +173,7 @@ Description:
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
Date: February 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
contains the total time the device has been preventing
@@ -203,7 +203,7 @@ Description:
What: /sys/devices/.../power/pm_qos_resume_latency_us
Date: March 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
contains the PM QoS resume latency limit for the given device,
@@ -223,7 +223,7 @@ Description:
What: /sys/devices/.../power/pm_qos_latency_tolerance_us
Date: January 2014
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power/pm_qos_latency_tolerance_us attribute
contains the PM QoS active state latency tolerance limit for the
@@ -248,7 +248,7 @@ Description:
What: /sys/devices/.../power/pm_qos_no_power_off
Date: September 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power/pm_qos_no_power_off attribute
is used for manipulating the PM QoS "no power off" flag. If
@@ -263,7 +263,7 @@ Description:
What: /sys/devices/.../power/runtime_status
Date: April 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/devices/.../power/runtime_status attribute contains
the current runtime PM status of the device, which may be
@@ -274,15 +274,15 @@ What: /sys/devices/.../power/runtime_active_time
Date: Jul 2010
Contact: Arjan van de Ven <arjan@linux.intel.com>
Description:
- Reports the total time that the device has been active.
- Used for runtime PM statistics.
+ Reports the total time that the device has been active, in
+ milliseconds. Used for runtime PM statistics.
What: /sys/devices/.../power/runtime_suspended_time
Date: Jul 2010
Contact: Arjan van de Ven <arjan@linux.intel.com>
Description:
- Reports total time that the device has been suspended.
- Used for runtime PM statistics.
+ Reports total time that the device has been suspended, in
+ milliseconds. Used for runtime PM statistics.
What: /sys/devices/.../power/runtime_usage
Date: Apr 2010
diff --git a/Documentation/ABI/testing/sysfs-devices-state_synced b/Documentation/ABI/testing/sysfs-devices-state_synced
index 0c922d7d02fc..c64636ddac41 100644
--- a/Documentation/ABI/testing/sysfs-devices-state_synced
+++ b/Documentation/ABI/testing/sysfs-devices-state_synced
@@ -21,4 +21,9 @@ Description:
at the time the kernel starts are not affected or limited in
any way by sync_state() callbacks.
+ Writing "1" to this file will force a call to the device's
+ sync_state() function if it hasn't been called already. The
+ sync_state() call happens independent of the state of the
+ consumer devices.
+
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index f54867cadb0f..3a05604c21bf 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -111,6 +111,7 @@ What: /sys/devices/system/cpu/cpuidle/available_governors
/sys/devices/system/cpu/cpuidle/current_driver
/sys/devices/system/cpu/cpuidle/current_governor
/sys/devices/system/cpu/cpuidle/current_governer_ro
+ /sys/devices/system/cpu/cpuidle/intel_c1_demotion
Date: September 2007
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Discover cpuidle policy and mechanism
@@ -132,7 +133,11 @@ Description: Discover cpuidle policy and mechanism
current_governor_ro: (RO) displays current idle policy.
- See Documentation/admin-guide/pm/cpuidle.rst and
+ intel_c1_demotion: (RW) enables/disables the C1 demotion
+ feature on Intel CPUs.
+
+ See Documentation/admin-guide/pm/cpuidle.rst,
+ Documentation/admin-guide/pm/intel_idle.rst, and
Documentation/driver-api/pm/cpuidle.rst for more information.
@@ -268,6 +273,60 @@ Description: Discover CPUs in the same CPU frequency coordination domain
This file is only present if the acpi-cpufreq or the cppc-cpufreq
drivers are in use.
+What: /sys/devices/system/cpu/cpuX/cpufreq/auto_select
+Date: May 2025
+Contact: linux-pm@vger.kernel.org
+Description: Autonomous selection enable
+
+ Read/write interface to control autonomous selection enable
+ Read returns autonomous selection status:
+ 0: autonomous selection is disabled
+ 1: autonomous selection is enabled
+
+ Write 'y' or '1' or 'on' to enable autonomous selection.
+ Write 'n' or '0' or 'off' to disable autonomous selection.
+
+ This file is only present if the cppc-cpufreq driver is in use.
+
+What: /sys/devices/system/cpu/cpuX/cpufreq/auto_act_window
+Date: May 2025
+Contact: linux-pm@vger.kernel.org
+Description: Autonomous activity window
+
+ This file indicates a moving utilization sensitivity window to
+ the platform's autonomous selection policy.
+
+ Read/write an integer represents autonomous activity window (in
+ microseconds) from/to this file. The max value to write is
+ 1270000000 but the max significand is 127. This means that if 128
+ is written to this file, 127 will be stored. If the value is
+ greater than 130, only the first two digits will be saved as
+ significand.
+
+ Writing a zero value to this file enable the platform to
+ determine an appropriate Activity Window depending on the workload.
+
+ Writing to this file only has meaning when Autonomous Selection is
+ enabled.
+
+ This file is only present if the cppc-cpufreq driver is in use.
+
+What: /sys/devices/system/cpu/cpuX/cpufreq/energy_performance_preference_val
+Date: May 2025
+Contact: linux-pm@vger.kernel.org
+Description: Energy performance preference
+
+ Read/write an 8-bit integer from/to this file. This file
+ represents a range of values from 0 (performance preference) to
+ 0xFF (energy efficiency preference) that influences the rate of
+ performance increase/decrease and the result of the hardware's
+ energy efficiency and performance optimization policies.
+
+ Writing to this file only has meaning when Autonomous Selection is
+ enabled.
+
+ This file is only present if the cppc-cpufreq driver is in use.
+
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
@@ -354,9 +413,6 @@ Description: Parameters for the CPU cache attributes
- ReadWriteAllocate:
both writeallocate and readallocate
- attributes:
- LEGACY used only on IA64 and is same as write_policy
-
coherency_line_size:
the minimum amount of data in bytes that gets
transferred from memory to cache
@@ -426,7 +482,7 @@ What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
- Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+ Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
@@ -476,7 +532,7 @@ What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
- Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+ Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
@@ -488,6 +544,7 @@ What: /sys/devices/system/cpu/cpuX/regs/
/sys/devices/system/cpu/cpuX/regs/identification/
/sys/devices/system/cpu/cpuX/regs/identification/midr_el1
/sys/devices/system/cpu/cpuX/regs/identification/revidr_el1
+ /sys/devices/system/cpu/cpuX/regs/identification/aidr_el1
/sys/devices/system/cpu/cpuX/regs/identification/smidr_el1
Date: June 2016
Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
@@ -513,17 +570,23 @@ Description: information about CPUs heterogeneity.
cpu_capacity: capacity of cpuX.
What: /sys/devices/system/cpu/vulnerabilities
+ /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
+ /sys/devices/system/cpu/vulnerabilities/indirect_target_selection
+ /sys/devices/system/cpu/vulnerabilities/itlb_multihit
+ /sys/devices/system/cpu/vulnerabilities/l1tf
+ /sys/devices/system/cpu/vulnerabilities/mds
/sys/devices/system/cpu/vulnerabilities/meltdown
+ /sys/devices/system/cpu/vulnerabilities/mmio_stale_data
+ /sys/devices/system/cpu/vulnerabilities/old_microcode
+ /sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling
+ /sys/devices/system/cpu/vulnerabilities/retbleed
+ /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
/sys/devices/system/cpu/vulnerabilities/spectre_v1
/sys/devices/system/cpu/vulnerabilities/spectre_v2
- /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
- /sys/devices/system/cpu/vulnerabilities/l1tf
- /sys/devices/system/cpu/vulnerabilities/mds
/sys/devices/system/cpu/vulnerabilities/srbds
+ /sys/devices/system/cpu/vulnerabilities/tsa
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
- /sys/devices/system/cpu/vulnerabilities/itlb_multihit
- /sys/devices/system/cpu/vulnerabilities/mmio_stale_data
- /sys/devices/system/cpu/vulnerabilities/retbleed
+ /sys/devices/system/cpu/vulnerabilities/vmscape
Date: January 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Information about CPU vulnerabilities
@@ -555,6 +618,7 @@ Description: Control Symmetric Multi Threading (SMT)
================ =========================================
"on" SMT is enabled
"off" SMT is disabled
+ "<N>" SMT is enabled with N threads per core.
"forceoff" SMT is force disabled. Cannot be changed.
"notsupported" SMT is not supported by the CPU
"notimplemented" SMT runtime toggling is not
@@ -562,7 +626,8 @@ Description: Control Symmetric Multi Threading (SMT)
================ =========================================
If control status is "forceoff" or "notsupported" writes
- are rejected.
+ are rejected. Note that enabling SMT on PowerPC skips
+ offline cores.
What: /sys/devices/system/cpu/cpuX/power/energy_perf_bias
Date: March 2019
@@ -605,10 +670,22 @@ Description: Umwait control
Note that a value of zero means there is no limit.
Low order two bits must be zero.
+What: /sys/devices/system/cpu/sev
+ /sys/devices/system/cpu/sev/vmpl
+Date: May 2024
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description: Secure Encrypted Virtualization (SEV) information
+
+ This directory is only present when running as an SEV-SNP guest.
+
+ vmpl: Reports the Virtual Machine Privilege Level (VMPL) at which
+ the SEV-SNP guest is running.
+
+
What: /sys/devices/system/cpu/svm
Date: August 2019
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
- Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+ Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Secure Virtual Machine
If 1, it means the system is using the Protected Execution
@@ -617,7 +694,7 @@ Description: Secure Virtual Machine
What: /sys/devices/system/cpu/cpuX/purr
Date: Apr 2005
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: PURR ticks for this CPU since the system boot.
The Processor Utilization Resources Register (PURR) is
@@ -628,7 +705,7 @@ Description: PURR ticks for this CPU since the system boot.
What: /sys/devices/system/cpu/cpuX/spurr
Date: Dec 2006
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: SPURR ticks for this CPU since the system boot.
The Scaled Processor Utilization Resources Register
@@ -640,7 +717,7 @@ Description: SPURR ticks for this CPU since the system boot.
What: /sys/devices/system/cpu/cpuX/idle_purr
Date: Apr 2020
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: PURR ticks for cpuX when it was idle.
This sysfs interface exposes the number of PURR ticks
@@ -648,7 +725,7 @@ Description: PURR ticks for cpuX when it was idle.
What: /sys/devices/system/cpu/cpuX/idle_spurr
Date: Apr 2020
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: SPURR ticks for cpuX when it was idle.
This sysfs interface exposes the number of SPURR ticks
@@ -670,7 +747,7 @@ Description: Preferred MTE tag checking mode
"async" Prefer asynchronous mode
================ ==============================================
- See also: Documentation/arm64/memory-tagging-extension.rst
+ See also: Documentation/arch/arm64/memory-tagging-extension.rst
What: /sys/devices/system/cpu/nohz_full
Date: Apr 2015
@@ -686,3 +763,28 @@ Description:
(RO) the list of CPUs that are isolated and don't
participate in load balancing. These CPUs are set by
boot parameter "isolcpus=".
+
+What: /sys/devices/system/cpu/housekeeping
+Date: Oct 2025
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ (RO) the list of logical CPUs that are designated by the kernel as
+ "housekeeping". Each CPU are responsible for handling essential
+ system-wide background tasks, including RCU callbacks, delayed
+ timer callbacks, and unbound workqueues, minimizing scheduling
+ jitter on low-latency, isolated CPUs. These CPUs are set when boot
+ parameter "isolcpus=nohz" or "nohz_full=" is specified.
+
+What: /sys/devices/system/cpu/crash_hotplug
+Date: Aug 2023
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ (RO) indicates whether or not the kernel updates relevant kexec
+ segments on memory hot un/plug and/or on/offline events, avoiding the
+ need to reload kdump kernel.
+
+What: /sys/devices/system/cpu/enabled
+Date: Nov 2022
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ (RO) the list of CPUs that can be brought online.
diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev b/Documentation/ABI/testing/sysfs-devices-vfio-dev
new file mode 100644
index 000000000000..e21424fd9666
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev
@@ -0,0 +1,8 @@
+What: /sys/.../<device>/vfio-dev/vfioX/
+Date: September 2022
+Contact: Yi Liu <yi.l.liu@intel.com>
+Description:
+ This directory is created when the device is bound to a
+ vfio driver. The layout under this directory matches what
+ exists for a standard 'struct device'. 'X' is a unique
+ index marking this device in vfio.
diff --git a/Documentation/ABI/testing/sysfs-devices-virtual-misc-tdx_guest b/Documentation/ABI/testing/sysfs-devices-virtual-misc-tdx_guest
new file mode 100644
index 000000000000..8fca56c8c9df
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-virtual-misc-tdx_guest
@@ -0,0 +1,63 @@
+What: /sys/devices/virtual/misc/tdx_guest/measurements/MRNAME[:HASH]
+Date: April, 2025
+KernelVersion: v6.16
+Contact: linux-coco@lists.linux.dev
+Description:
+ Value of a TDX measurement register (MR). MRNAME and HASH above
+ are placeholders. The optional suffix :HASH is used for MRs
+ that have associated hash algorithms. See below for a complete
+ list of TDX MRs exposed via sysfs. Refer to Intel TDX Module
+ ABI Specification for the definition of TDREPORT and the full
+ list of TDX measurements.
+
+ Intel TDX Module ABI Specification can be found at:
+ https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/documentation.html#architecture
+
+ See also:
+ https://docs.kernel.org/driver-api/coco/measurement-registers.html
+
+What: /sys/devices/virtual/misc/tdx_guest/measurements/mrconfigid
+Date: April, 2025
+KernelVersion: v6.16
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) MRCONFIGID - 48-byte immutable storage typically used for
+ software-defined ID for non-owner-defined configuration of the
+ guest TD – e.g., run-time or OS configuration.
+
+What: /sys/devices/virtual/misc/tdx_guest/measurements/mrowner
+Date: April, 2025
+KernelVersion: v6.16
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) MROWNER - 48-byte immutable storage typically used for
+ software-defined ID for the guest TD’s owner.
+
+What: /sys/devices/virtual/misc/tdx_guest/measurements/mrownerconfig
+Date: April, 2025
+KernelVersion: v6.16
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) MROWNERCONFIG - 48-byte immutable storage typically used
+ for software-defined ID for owner-defined configuration of the
+ guest TD – e.g., specific to the workload rather than the
+ run-time or OS.
+
+What: /sys/devices/virtual/misc/tdx_guest/measurements/mrtd:sha384
+Date: April, 2025
+KernelVersion: v6.16
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RO) MRTD - Measurement of the initial contents of the TD.
+
+What: /sys/devices/virtual/misc/tdx_guest/measurements/rtmr[0123]:sha384
+Date: April, 2025
+KernelVersion: v6.16
+Contact: linux-coco@lists.linux.dev
+Description:
+ (RW) RTMR[0123] - 4 Run-Time extendable Measurement Registers.
+ Read from any of these returns the current value of the
+ corresponding RTMR. Write extends the written buffer to the
+ RTMR. All writes must start at offset 0 and be 48 bytes in
+ size. Partial writes will result in EINVAL returned by the
+ write() syscall.
diff --git a/Documentation/ABI/testing/sysfs-driver-amd-sfh b/Documentation/ABI/testing/sysfs-driver-amd-sfh
new file mode 100644
index 000000000000..c053126a83bb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-amd-sfh
@@ -0,0 +1,13 @@
+What: /sys/bus/pci/drivers/pcie_mp2_amd/*/hpd
+Date: April 2025
+Contact: mario.limonciello@amd.com
+Description:
+ Human presence detection (HPD) enable/disable.
+ When HPD is enabled, the device will be able to detect the
+ presence of a human and will send an interrupt that can be
+ used to wake the system from a low power state.
+ When HPD is disabled, the device will not be able to detect
+ the presence of a human.
+
+ Access: Read/Write
+ Valid values: enabled/disabled
diff --git a/Documentation/ABI/testing/sysfs-driver-ccp b/Documentation/ABI/testing/sysfs-driver-ccp
index 7aded9b75553..ee6b787eee7a 100644
--- a/Documentation/ABI/testing/sysfs-driver-ccp
+++ b/Documentation/ABI/testing/sysfs-driver-ccp
@@ -85,3 +85,21 @@ Description:
Possible values:
0: Not enforced
1: Enforced
+
+What: /sys/bus/pci/devices/<BDF>/bootloader_version
+Date: June 2023
+KernelVersion: 6.4
+Contact: mario.limonciello@amd.com
+Description:
+ The /sys/bus/pci/devices/<BDF>/bootloader_version
+ file reports the firmware version of the AMD AGESA
+ bootloader.
+
+What: /sys/bus/pci/devices/<BDF>/tee_version
+Date: June 2023
+KernelVersion: 6.4
+Contact: mario.limonciello@amd.com
+Description:
+ The /sys/bus/pci/devices/<BDF>/tee_version
+ file reports the firmware version of the AMD Trusted
+ Execution Environment (TEE).
diff --git a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi
index c308926e1568..d46b1c85840d 100644
--- a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi
+++ b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi
@@ -1,4 +1,5 @@
What: /sys/bus/platform/devices/GGL0001:*/BINF.2
+ /sys/bus/platform/devices/GOOG0016:*/BINF.2
Date: May 2022
KernelVersion: 5.19
Description:
@@ -10,6 +11,7 @@ Description:
== ===============================
What: /sys/bus/platform/devices/GGL0001:*/BINF.3
+ /sys/bus/platform/devices/GOOG0016:*/BINF.3
Date: May 2022
KernelVersion: 5.19
Description:
@@ -23,6 +25,7 @@ Description:
== =====================================
What: /sys/bus/platform/devices/GGL0001:*/CHSW
+ /sys/bus/platform/devices/GOOG0016:*/CHSW
Date: May 2022
KernelVersion: 5.19
Description:
@@ -38,6 +41,7 @@ Description:
==== ===========================================
What: /sys/bus/platform/devices/GGL0001:*/FMAP
+ /sys/bus/platform/devices/GOOG0016:*/FMAP
Date: May 2022
KernelVersion: 5.19
Description:
@@ -45,6 +49,7 @@ Description:
processor firmware flashmap.
What: /sys/bus/platform/devices/GGL0001:*/FRID
+ /sys/bus/platform/devices/GOOG0016:*/FRID
Date: May 2022
KernelVersion: 5.19
Description:
@@ -52,6 +57,7 @@ Description:
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/FWID
+ /sys/bus/platform/devices/GOOG0016:*/FWID
Date: May 2022
KernelVersion: 5.19
Description:
@@ -59,6 +65,7 @@ Description:
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.0
Date: May 2022
KernelVersion: 5.19
Description:
@@ -73,6 +80,7 @@ Description:
=========== ==================================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.1
Date: May 2022
KernelVersion: 5.19
Description:
@@ -84,6 +92,7 @@ Description:
== =======================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.2
Date: May 2022
KernelVersion: 5.19
Description:
@@ -91,18 +100,21 @@ Description:
controller.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3
+ /sys/bus/platform/devices/GOOG0016:*/GPIO.X/GPIO.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns name of the GPIO controller.
What: /sys/bus/platform/devices/GGL0001:*/HWID
+ /sys/bus/platform/devices/GOOG0016:*/HWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns hardware ID for the Chromebook.
What: /sys/bus/platform/devices/GGL0001:*/MECK
+ /sys/bus/platform/devices/GOOG0016:*/MECK
Date: May 2022
KernelVersion: 5.19
Description:
@@ -113,6 +125,7 @@ Description:
present, or if the firmware was unable to read the extended registers, this buffer size can be zero.
What: /sys/bus/platform/devices/GGL0001:*/VBNV.0
+ /sys/bus/platform/devices/GOOG0016:*/VBNV.0
Date: May 2022
KernelVersion: 5.19
Description:
@@ -122,6 +135,7 @@ Description:
clock data).
What: /sys/bus/platform/devices/GGL0001:*/VBNV.1
+ /sys/bus/platform/devices/GOOG0016:*/VBNV.1
Date: May 2022
KernelVersion: 5.19
Description:
@@ -129,9 +143,10 @@ Description:
storage block.
What: /sys/bus/platform/devices/GGL0001:*/VDAT
+ /sys/bus/platform/devices/GOOG0016:*/VDAT
Date: May 2022
KernelVersion: 5.19
Description:
Returns the verified boot data block shared between the
firmware verification step and the kernel verification step
- (binary).
+ (hex dump).
diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud
index 83f3872182a4..2bab0db2d2f0 100644
--- a/Documentation/ABI/testing/sysfs-driver-eud
+++ b/Documentation/ABI/testing/sysfs-driver-eud
@@ -1,4 +1,4 @@
-What: /sys/bus/platform/drivers/eud/.../enable
+What: /sys/bus/platform/drivers/qcom_eud/.../enable
Date: February 2022
Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
Description:
diff --git a/Documentation/ABI/testing/sysfs-driver-framer-pef2256 b/Documentation/ABI/testing/sysfs-driver-framer-pef2256
new file mode 100644
index 000000000000..29f97783bf07
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-framer-pef2256
@@ -0,0 +1,8 @@
+What: /sys/bus/platform/devices/xxx/version
+Date: Sep 2025
+Contact: netdev@vger.kernel.org
+Description: Reports the version of the PEF2256 framer
+
+ Access: Read
+
+ Valid values: Represented as string
diff --git a/Documentation/ABI/testing/sysfs-driver-ge-achc b/Documentation/ABI/testing/sysfs-driver-ge-achc
index a9e7a079190c..c3e77def4b20 100644
--- a/Documentation/ABI/testing/sysfs-driver-ge-achc
+++ b/Documentation/ABI/testing/sysfs-driver-ge-achc
@@ -5,7 +5,7 @@ Description: Write 1 to this file to update the ACHC microcontroller
firmware via the EzPort interface. For this the kernel
will load "achc.bin" via the firmware API (so usually
from /lib/firmware). The write will block until the FW
- has either been flashed successfully or an error occured.
+ has either been flashed successfully or an error occurred.
What: /sys/bus/spi/<dev>/reset
Date: Jul 2021
diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs
index 96646fb2e7a1..4244f5af4b54 100644
--- a/Documentation/ABI/testing/sysfs-driver-habanalabs
+++ b/Documentation/ABI/testing/sysfs-driver-habanalabs
@@ -1,4 +1,4 @@
-What: /sys/class/habanalabs/hl<n>/armcp_kernel_ver
+What: /sys/class/accel/accel<n>/device/armcp_kernel_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -6,7 +6,7 @@ Description: Version of the Linux kernel running on the device's CPU.
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_kernel_ver
-What: /sys/class/habanalabs/hl<n>/armcp_ver
+What: /sys/class/accel/accel<n>/device/armcp_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -14,9 +14,9 @@ Description: Version of the application running on the device's CPU
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_ver
-What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz
+What: /sys/class/accel/accel<n>/device/clk_max_freq_mhz
Date: Jun 2019
-KernelVersion: not yet upstreamed
+KernelVersion: 5.7
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum clock frequency, in MHz.
The device clock might be set to lower value than the maximum.
@@ -24,58 +24,58 @@ Description: Allows the user to set the maximum clock frequency, in MHz.
frequency value of the device clock. This property is valid
only for the Gaudi ASIC family
-What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz
+What: /sys/class/accel/accel<n>/device/clk_cur_freq_mhz
Date: Jun 2019
-KernelVersion: not yet upstreamed
+KernelVersion: 5.7
Contact: ogabbay@kernel.org
Description: Displays the current frequency, in MHz, of the device clock.
This property is valid only for the Gaudi ASIC family
-What: /sys/class/habanalabs/hl<n>/cpld_ver
+What: /sys/class/accel/accel<n>/device/cpld_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the Device's CPLD F/W
-What: /sys/class/habanalabs/hl<n>/cpucp_kernel_ver
+What: /sys/class/accel/accel<n>/device/cpucp_kernel_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: ogabbay@kernel.org
Description: Version of the Linux kernel running on the device's CPU
-What: /sys/class/habanalabs/hl<n>/cpucp_ver
+What: /sys/class/accel/accel<n>/device/cpucp_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: ogabbay@kernel.org
Description: Version of the application running on the device's CPU
-What: /sys/class/habanalabs/hl<n>/device_type
+What: /sys/class/accel/accel<n>/device/device_type
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the code name of the device according to its type.
The supported values are: "GOYA"
-What: /sys/class/habanalabs/hl<n>/eeprom
+What: /sys/class/accel/accel<n>/device/eeprom
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: A binary file attribute that contains the contents of the
on-board EEPROM
-What: /sys/class/habanalabs/hl<n>/fuse_ver
+What: /sys/class/accel/accel<n>/device/fuse_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the device's version from the eFuse
-What: /sys/class/habanalabs/hl<n>/fw_os_ver
+What: /sys/class/accel/accel<n>/device/fw_os_ver
Date: Dec 2021
KernelVersion: 5.18
Contact: ogabbay@kernel.org
Description: Version of the firmware OS running on the device's CPU
-What: /sys/class/habanalabs/hl<n>/hard_reset
+What: /sys/class/accel/accel<n>/device/hard_reset
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -83,14 +83,14 @@ Description: Interface to trigger a hard-reset operation for the device.
Hard-reset will reset ALL internal components of the device
except for the PCI interface and the internal PLLs
-What: /sys/class/habanalabs/hl<n>/hard_reset_cnt
+What: /sys/class/accel/accel<n>/device/hard_reset_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays how many times the device have undergone a hard-reset
operation since the driver was loaded
-What: /sys/class/habanalabs/hl<n>/high_pll
+What: /sys/class/accel/accel<n>/device/high_pll
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -98,7 +98,7 @@ Description: Allows the user to set the maximum clock frequency for MME, TPC
and IC when the power management profile is set to "automatic".
This property is valid only for the Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/ic_clk
+What: /sys/class/accel/accel<n>/device/ic_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -110,27 +110,27 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
frequency value of the IC. This property is valid only for the
Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/ic_clk_curr
+What: /sys/class/accel/accel<n>/device/ic_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the Interconnect
fabric. This property is valid only for the Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/infineon_ver
+What: /sys/class/accel/accel<n>/device/infineon_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the Device's power supply F/W code. Relevant only to GOYA and GAUDI
-What: /sys/class/habanalabs/hl<n>/max_power
+What: /sys/class/accel/accel<n>/device/max_power
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum power consumption of the
device in milliwatts.
-What: /sys/class/habanalabs/hl<n>/mme_clk
+What: /sys/class/accel/accel<n>/device/mme_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -142,21 +142,33 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
frequency value of the MME. This property is valid only for the
Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/mme_clk_curr
+What: /sys/class/accel/accel<n>/device/mme_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the MME compute
engine. This property is valid only for the Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/pci_addr
+What: /sys/class/accel/accel<n>/device/module_id
+Date: Nov 2023
+KernelVersion: not yet upstreamed
+Contact: ogabbay@kernel.org
+Description: Displays the device's module id
+
+What: /sys/class/accel/accel<n>/device/parent_device
+Date: Nov 2023
+KernelVersion: 6.8
+Contact: ttayar@habana.ai
+Description: Displays the name of the parent device of the accel device
+
+What: /sys/class/accel/accel<n>/device/pci_addr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the PCI address of the device. This is needed so the
user would be able to open a device based on its PCI address
-What: /sys/class/habanalabs/hl<n>/pm_mng_profile
+What: /sys/class/accel/accel<n>/device/pm_mng_profile
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -170,13 +182,19 @@ Description: Power management profile. Values are "auto", "manual". In "auto"
ic_clk, mme_clk and tpc_clk. This property is valid only for
the Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/preboot_btl_ver
+What: /sys/class/accel/accel<n>/device/preboot_btl_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the device's preboot F/W code
-What: /sys/class/habanalabs/hl<n>/soft_reset
+What: /sys/class/accel/accel<n>/device/security_enabled
+Date: Oct 2022
+KernelVersion: 6.1
+Contact: obitton@habana.ai
+Description: Displays the device's security status
+
+What: /sys/class/accel/accel<n>/device/soft_reset
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -184,26 +202,38 @@ Description: Interface to trigger a soft-reset operation for the device.
Soft-reset will reset only the compute and DMA engines of the
device
-What: /sys/class/habanalabs/hl<n>/soft_reset_cnt
+What: /sys/class/accel/accel<n>/device/soft_reset_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays how many times the device have undergone a soft-reset
operation since the driver was loaded
-What: /sys/class/habanalabs/hl<n>/status
+What: /sys/class/accel/accel<n>/device/status
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
-Description: Status of the card: "Operational", "Malfunction", "In reset".
+Description: Status of the card:
-What: /sys/class/habanalabs/hl<n>/thermal_ver
+ * "operational" - Device is available for work.
+ * "in reset" - Device is going through reset, will be
+ available shortly.
+ * "disabled" - Device is not usable.
+ * "needs reset" - Device is not usable until a hard reset
+ is initiated.
+ * "in device creation" - Device is not available yet, as it
+ is still initializing.
+ * "in reset after device release" - Device is going through
+ a compute-reset which is executed after a device release
+ (relevant for Gaudi2 only).
+
+What: /sys/class/accel/accel<n>/device/thermal_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the Device's thermal daemon
-What: /sys/class/habanalabs/hl<n>/tpc_clk
+What: /sys/class/accel/accel<n>/device/tpc_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -215,21 +245,21 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
frequency value of the TPC. This property is valid only for
Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/tpc_clk_curr
+What: /sys/class/accel/accel<n>/device/tpc_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the TPC compute
engines. This property is valid only for the Goya ASIC family
-What: /sys/class/habanalabs/hl<n>/uboot_ver
+What: /sys/class/accel/accel<n>/device/uboot_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the u-boot running on the device's CPU
-What: /sys/class/habanalabs/hl<n>/vrm_ver
+What: /sys/class/accel/accel<n>/device/vrm_ver
Date: Jan 2022
-KernelVersion: not yet upstreamed
+KernelVersion: 5.17
Contact: ogabbay@kernel.org
Description: Version of the Device's Voltage Regulator Monitor F/W code. N/A to GOYA and GAUDI
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd b/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd
new file mode 100644
index 000000000000..8c9718d83e9d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd
@@ -0,0 +1,13 @@
+What: /sys/bus/hid/drivers/hid-appletb-kbd/<dev>/mode
+Date: March, 2025
+KernelVersion: 6.15
+Contact: linux-input@vger.kernel.org
+Description:
+ The set of keys displayed on the Touch Bar.
+ Valid values are:
+ == =================
+ 0 Escape key only
+ 1 Function keys
+ 2 Media/brightness keys
+ 3 None
+ == =================
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-corsair-void b/Documentation/ABI/testing/sysfs-driver-hid-corsair-void
new file mode 100644
index 000000000000..83fa625c0025
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-corsair-void
@@ -0,0 +1,38 @@
+What: /sys/bus/hid/drivers/hid-corsair-void/<dev>/fw_version_headset
+Date: January 2024
+KernelVersion: 6.13
+Contact: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
+Description: (R) The firmware version of the headset
+ * Returns -ENODATA if no version was reported
+
+What: /sys/bus/hid/drivers/hid-corsair-void/<dev>/fw_version_receiver
+Date: January 2024
+KernelVersion: 6.13
+Contact: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
+Description: (R) The firmware version of the receiver
+
+What: /sys/bus/hid/drivers/hid-corsair-void/<dev>/microphone_up
+Date: July 2023
+KernelVersion: 6.13
+Contact: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
+Description: (R) Get the physical position of the microphone
+ * 1 -> Microphone up
+ * 0 -> Microphone down
+
+What: /sys/bus/hid/drivers/hid-corsair-void/<dev>/send_alert
+Date: July 2023
+KernelVersion: 6.13
+Contact: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
+Description: (W) Play a built-in notification from the headset (0 / 1)
+
+What: /sys/bus/hid/drivers/hid-corsair-void/<dev>/set_sidetone
+Date: December 2023
+KernelVersion: 6.13
+Contact: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
+Description: (W) Set the sidetone volume (0 - sidetone_max)
+
+What: /sys/bus/hid/drivers/hid-corsair-void/<dev>/sidetone_max
+Date: July 2024
+KernelVersion: 6.13
+Contact: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
+Description: (R) Report the maximum sidetone volume
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index 000000000000..a885e5316d02
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,93 @@
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/in0_input
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/power1_max
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit. A read value of 0 means that the PL1
+ power limit is disabled, writing 0 disables the
+ limit. Writing values > 0 will enable the power limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/power1_rated_max
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/power1_max_interval
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/power1_crit
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/curr1_crit
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/energy1_input
+Date: February 2023
+KernelVersion: 6.2
+Contact: intel-gfx@lists.freedesktop.org
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/bus/pci/drivers/i915/.../hwmon/hwmon<i>/fan1_input
+Date: November 2024
+KernelVersion: 6.12
+Contact: intel-gfx@lists.freedesktop.org
+Description: RO. Fan speed of device in RPM.
+
+ 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.
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
index 9773925138af..faeae8fedb14 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
@@ -1,4 +1,4 @@
-What: /sys/bus/spi/devices/.../bmc_version
+What: /sys/bus/.../drivers/intel-m10-bmc/.../bmc_version
Date: June 2020
KernelVersion: 5.10
Contact: Xu Yilun <yilun.xu@intel.com>
@@ -6,7 +6,7 @@ Description: Read only. Returns the hardware build version of Intel
MAX10 BMC chip.
Format: "0x%x".
-What: /sys/bus/spi/devices/.../bmcfw_version
+What: /sys/bus/.../drivers/intel-m10-bmc/.../bmcfw_version
Date: June 2020
KernelVersion: 5.10
Contact: Xu Yilun <yilun.xu@intel.com>
@@ -14,10 +14,10 @@ Description: Read only. Returns the firmware version of Intel MAX10
BMC chip.
Format: "0x%x".
-What: /sys/bus/spi/devices/.../mac_address
+What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_address
Date: January 2021
KernelVersion: 5.12
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns the first MAC address in a block
of sequential MAC addresses assigned to the board
that is managed by the Intel MAX10 BMC. It is stored in
@@ -25,10 +25,10 @@ Description: Read only. Returns the first MAC address in a block
space.
Format: "%02x:%02x:%02x:%02x:%02x:%02x".
-What: /sys/bus/spi/devices/.../mac_count
+What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_count
Date: January 2021
KernelVersion: 5.12
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns the number of sequential MAC
addresses assigned to the board managed by the Intel
MAX10 BMC. This value is stored in FLASH and is mirrored
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
index 0a41afe0ab4c..3a6ca780c75c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
@@ -1,7 +1,7 @@
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns the root entry hash for the static
region if one is programmed, else it returns the
string: "hash not programmed". This file is only
@@ -11,7 +11,7 @@ Description: Read only. Returns the root entry hash for the static
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns the root entry hash for the partial
reconfiguration region if one is programmed, else it
returns the string: "hash not programmed". This file
@@ -21,7 +21,7 @@ Description: Read only. Returns the root entry hash for the partial
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns the root entry hash for the BMC image
if one is programmed, else it returns the string:
"hash not programmed". This file is only visible if the
@@ -31,7 +31,7 @@ Description: Read only. Returns the root entry hash for the BMC image
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the static region. The standard bitmap
list format is used (e.g. "1,2-6,9").
@@ -39,7 +39,7 @@ Description: Read only. Returns a list of indices for canceled code
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the partial reconfiguration region. The
standard bitmap list format is used (e.g. "1,2-6,9").
@@ -47,7 +47,7 @@ Description: Read only. Returns a list of indices for canceled code
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the BMC. The standard bitmap list format
is used (e.g. "1,2-6,9").
@@ -55,7 +55,7 @@ Description: Read only. Returns a list of indices for canceled code
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count
Date: Sep 2022
KernelVersion: 5.20
-Contact: Russ Weight <russell.h.weight@intel.com>
+Contact: Matthew Gerlach <matthew.gerlach@altera.com>
Description: Read only. Returns number of times the secure update
staging area has been flashed.
Format: "%u".
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
new file mode 100644
index 000000000000..d9e2b17c6872
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
@@ -0,0 +1,198 @@
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_max
+Date: September 2023
+KernelVersion: 6.5
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1) power limit in microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit. A read value of 0 means that the PL1
+ power limit is disabled, writing 0 disables the
+ limit. Writing values > 0 and <= TDP will enable the power limit.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_rated_max
+Date: September 2023
+KernelVersion: 6.5
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel Xe graphics platforms.
+
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy1_input
+Date: September 2023
+KernelVersion: 6.5
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Card energy input of device in microjoules.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_max_interval
+Date: October 2023
+KernelVersion: 6.6
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Card sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_max
+Date: February 2024
+KernelVersion: 6.8
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Package reactive sustained (PL1) power limit in microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit. A read value of 0 means that the PL1
+ power limit is disabled, writing 0 disables the
+ limit. Writing values > 0 and <= TDP will enable the power limit.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_rated_max
+Date: February 2024
+KernelVersion: 6.8
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Package default power limit (default TDP setting).
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_crit
+Date: May 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/curr1_crit
+Date: May 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy2_input
+Date: February 2024
+KernelVersion: 6.8
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Package energy input of device in microjoules.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_max_interval
+Date: February 2024
+KernelVersion: 6.8
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Package sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/in1_input
+Date: February 2024
+KernelVersion: 6.8
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Package current voltage in millivolt.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp2_input
+Date: March 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Package temperature in millidegree Celsius.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp3_input
+Date: March 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. VRAM temperature in millidegree Celsius.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/fan1_input
+Date: March 2025
+KernelVersion: 6.16
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Fan 1 speed in RPM.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/fan2_input
+Date: March 2025
+KernelVersion: 6.16
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Fan 2 speed in RPM.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/fan3_input
+Date: March 2025
+KernelVersion: 6.16
+Contact: intel-xe@lists.freedesktop.org
+Description: RO. Fan 3 speed in RPM.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_cap
+Date: May 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Card burst (PL2) power limit in microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically milli seconds)
+ exceeds this limit. A read value of 0 means that the PL2
+ power limit is disabled, writing 0 disables the limit.
+ PL2 is greater than PL1 and its time window is lesser
+ compared to PL1.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_cap
+Date: May 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Package burst (PL2) power limit in microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically milli seconds)
+ exceeds this limit. A read value of 0 means that the PL2
+ power limit is disabled, writing 0 disables the limit.
+ PL2 is greater than PL1 and its time window is lesser
+ compared to PL1.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_cap_interval
+Date: May 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Card burst power limit interval (Tau in PL2/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel Xe graphics platforms.
+
+What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_cap_interval
+Date: May 2025
+KernelVersion: 6.15
+Contact: intel-xe@lists.freedesktop.org
+Description: RW. Package burst power limit interval (Tau in PL2/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel Xe graphics platforms.
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov b/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov
new file mode 100644
index 000000000000..2fd7e9b7bacc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov
@@ -0,0 +1,159 @@
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ This directory appears for the particular Intel Xe device when:
+
+ - device supports SR-IOV, and
+ - device is a Physical Function (PF), and
+ - driver support for the SR-IOV PF is enabled on given device.
+
+ This directory is used as a root for all attributes required to
+ manage both Physical Function (PF) and Virtual Functions (VFs).
+
+
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ This directory holds attributes related to the SR-IOV Physical
+ Function (PF).
+
+
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf1/
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf2/
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<N>/
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ These directories hold attributes related to the SR-IOV Virtual
+ Functions (VFs).
+
+ Note that the VF number <N> is 1-based as described in PCI SR-IOV
+ specification as the Xe driver follows that naming schema.
+
+ There could be "vf1", "vf2" and so on, up to "vf<N>", where <N>
+ matches the value of the "sriov_totalvfs" attribute.
+
+
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/profile/exec_quantum_ms
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/profile/preempt_timeout_us
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/profile/sched_priority
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/exec_quantum_ms
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/preempt_timeout_us
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/sched_priority
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ These files expose scheduling parameters for the PF and its VFs, and
+ are visible only on Intel Xe platforms that use time-sliced GPU sharing.
+ They can be changed even if VFs are enabled and running and reflect the
+ settings of all tiles/GTs assigned to the given function.
+
+ exec_quantum_ms: (RW) unsigned integer
+ The GT execution quantum (EQ) in [ms] for the given function.
+ Actual quantum value might be aligned per HW/FW requirements.
+
+ Default is 0 (unlimited).
+
+ preempt_timeout_us: (RW) unsigned integer
+ The GT preemption timeout in [us] of the given function.
+ Actual timeout value might be aligned per HW/FW requirements.
+
+ Default is 0 (unlimited).
+
+ sched_priority: (RW/RO) string
+ The GT scheduling priority of the given function.
+
+ "low" - function will be scheduled on the GPU for its EQ/PT
+ only if function has any work already submitted.
+
+ "normal" - functions will be scheduled on the GPU for its EQ/PT
+ irrespective of whether it has submitted a work or not.
+
+ "high" - function will be scheduled on the GPU for its EQ/PT
+ in the next time-slice after the current one completes
+ and function has a work submitted.
+
+ Default is "low".
+
+ When read, this file will display the current and available
+ scheduling priorities. The currently active priority level will
+ be enclosed in square brackets, like:
+
+ [low] normal high
+
+ This file can be read-only if changing the priority is not
+ supported.
+
+ Writes to these attributes may fail with errors like:
+ -EINVAL if provided input is malformed or not recognized,
+ -EPERM if change is not applicable on given HW/FW,
+ -EIO if FW refuses to change the provisioning.
+
+ Reads from these attributes may fail with:
+ -EUCLEAN if value is not consistent across all tiles/GTs.
+
+
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/exec_quantum_ms
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/preempt_timeout_us
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/sched_priority
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ These files allows bulk reconfiguration of the scheduling parameters
+ of the PF or VFs and are available only for Intel Xe platforms with
+ GPU sharing based on the time-slice basis. These scheduling parameters
+ can be changed even if VFs are enabled and running.
+
+ exec_quantum_ms: (WO) unsigned integer
+ The GT execution quantum (EQ) in [ms] to be applied to all functions.
+ See sriov_admin/{pf,vf<N>}/profile/exec_quantum_ms for more details.
+
+ preempt_timeout_us: (WO) unsigned integer
+ The GT preemption timeout (PT) in [us] to be applied to all functions.
+ See sriov_admin/{pf,vf<N>}/profile/preempt_timeout_us for more details.
+
+ sched_priority: (RW/RO) string
+ The GT scheduling priority to be applied for all functions.
+ See sriov_admin/{pf,vf<N>}/profile/sched_priority for more details.
+
+ Writes to these attributes may fail with errors like:
+ -EINVAL if provided input is malformed or not recognized,
+ -EPERM if change is not applicable on given HW/FW,
+ -EIO if FW refuses to change the provisioning.
+
+
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/stop
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ This file allows to control scheduling of the VF on the Intel Xe GPU
+ platforms. It allows to implement custom policy mechanism in case VFs
+ are misbehaving or triggering adverse events above defined thresholds.
+
+ stop: (WO) bool
+ All GT executions of given function shall be immediately stopped.
+ To allow scheduling this VF again, the VF FLR must be triggered.
+
+ Writes to this attribute may fail with errors like:
+ -EINVAL if provided input is malformed or not recognized,
+ -EPERM if change is not applicable on given HW/FW,
+ -EIO if FW refuses to change the scheduling.
+
+
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/device
+What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/device
+Date: October 2025
+KernelVersion: 6.19
+Contact: intel-xe@lists.freedesktop.org
+Description:
+ These are symlinks to the underlying PCI device entry representing
+ given Xe SR-IOV function. For the PF, this link is always present.
+ For VFs, this link is present only for currently enabled VFs.
diff --git a/Documentation/ABI/testing/sysfs-driver-intel_sdsi b/Documentation/ABI/testing/sysfs-driver-intel_sdsi
index 96b92c105ec4..f8afed127107 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel_sdsi
+++ b/Documentation/ABI/testing/sysfs-driver-intel_sdsi
@@ -4,21 +4,21 @@ KernelVersion: 5.18
Contact: "David E. Box" <david.e.box@linux.intel.com>
Description:
This directory contains interface files for accessing Intel
- Software Defined Silicon (SDSi) features on a CPU. X
- represents the socket instance (though not the socket ID).
- The socket ID is determined by reading the registers file
- and decoding it per the specification.
+ On Demand (formerly Software Defined Silicon or SDSi) features
+ on a CPU. X represents the socket instance (though not the
+ socket ID). The socket ID is determined by reading the
+ registers file and decoding it per the specification.
- Some files communicate with SDSi hardware through a mailbox.
- Should the operation fail, one of the following error codes
- may be returned:
+ Some files communicate with On Demand hardware through a
+ mailbox. Should the operation fail, one of the following error
+ codes may be returned:
========== =====
Error Code Cause
========== =====
EIO General mailbox failure. Log may indicate cause.
EBUSY Mailbox is owned by another agent.
- EPERM SDSI capability is not enabled in hardware.
+ EPERM On Demand capability is not enabled in hardware.
EPROTO Failure in mailbox protocol detected by driver.
See log for details.
EOVERFLOW For provision commands, the size of the data
@@ -54,8 +54,8 @@ KernelVersion: 5.18
Contact: "David E. Box" <david.e.box@linux.intel.com>
Description:
(WO) Used to write an Authentication Key Certificate (AKC) to
- the SDSi NVRAM for the CPU. The AKC is used to authenticate a
- Capability Activation Payload. Mailbox command.
+ the On Demand NVRAM for the CPU. The AKC is used to authenticate
+ a Capability Activation Payload. Mailbox command.
What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/provision_cap
Date: Feb 2022
@@ -63,17 +63,28 @@ KernelVersion: 5.18
Contact: "David E. Box" <david.e.box@linux.intel.com>
Description:
(WO) Used to write a Capability Activation Payload (CAP) to the
- SDSi NVRAM for the CPU. CAPs are used to activate a given CPU
- feature. A CAP is validated by SDSi hardware using a previously
- provisioned AKC file. Upon successful authentication, the CPU
- configuration is updated. A cold reboot is required to fully
- activate the feature. Mailbox command.
+ On Demand NVRAM for the CPU. CAPs are used to activate a given
+ CPU feature. A CAP is validated by On Demand hardware using a
+ previously provisioned AKC file. Upon successful authentication,
+ the CPU configuration is updated. A cold reboot is required to
+ fully activate the feature. Mailbox command.
+
+What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/meter_certificate
+Date: Nov 2022
+KernelVersion: 6.2
+Contact: "David E. Box" <david.e.box@linux.intel.com>
+Description:
+ (RO) Used to read back the current meter certificate for the CPU
+ from Intel On Demand hardware. The meter certificate contains
+ utilization metrics of On Demand enabled features. Mailbox
+ command.
What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/state_certificate
Date: Feb 2022
KernelVersion: 5.18
Contact: "David E. Box" <david.e.box@linux.intel.com>
Description:
- (RO) Used to read back the current State Certificate for the CPU
- from SDSi hardware. The State Certificate contains information
- about the current licenses on the CPU. Mailbox command.
+ (RO) Used to read back the current state certificate for the CPU
+ from On Demand hardware. The state certificate contains
+ information about the current licenses on the CPU. Mailbox
+ command.
diff --git a/Documentation/ABI/testing/sysfs-driver-panfrost-profiling b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling
new file mode 100644
index 000000000000..7597c420e54b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-panfrost-profiling
@@ -0,0 +1,10 @@
+What: /sys/bus/platform/drivers/panfrost/.../profiling
+Date: February 2024
+KernelVersion: 6.8.0
+Contact: Adrian Larumbe <adrian.larumbe@collabora.com>
+Description:
+ Get/set drm fdinfo's engine and cycles profiling status.
+ Valid values are:
+ 0: Don't enable fdinfo job profiling sources.
+ 1: Enable fdinfo job profiling sources, this enables both the GPU's
+ timestamp and cycle counter registers.
diff --git a/Documentation/ABI/testing/sysfs-driver-panthor-profiling b/Documentation/ABI/testing/sysfs-driver-panthor-profiling
new file mode 100644
index 000000000000..af05fccedc15
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-panthor-profiling
@@ -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.
diff --git a/Documentation/ABI/testing/sysfs-driver-qaic b/Documentation/ABI/testing/sysfs-driver-qaic
new file mode 100644
index 000000000000..f794fd734163
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-qaic
@@ -0,0 +1,18 @@
+What: /sys/bus/pci/drivers/qaic/XXXX:XX:XX.X/ce_count
+Date: May 2025
+KernelVersion: 6.17
+Contact: dri-devel@lists.freedesktop.org
+Description: Number of correctable errors received from device since driver is loaded.
+
+What: /sys/bus/pci/drivers/qaic/XXXX:XX:XX.X/ue_count
+Date: May 2025
+KernelVersion: 6.17
+Contact: dri-devel@lists.freedesktop.org
+Description: Number of uncorrectable errors received from device since driver is loaded.
+
+What: /sys/bus/pci/drivers/qaic/XXXX:XX:XX.X/ue_nonfatal_count
+Date: May 2025
+KernelVersion: 6.17
+Contact: dri-devel@lists.freedesktop.org
+Description: Number of uncorrectable non-fatal errors received from device since driver
+ is loaded.
diff --git a/Documentation/ABI/testing/sysfs-driver-qat b/Documentation/ABI/testing/sysfs-driver-qat
index 185f81a2aab3..b0561b9fc4eb 100644
--- a/Documentation/ABI/testing/sysfs-driver-qat
+++ b/Documentation/ABI/testing/sysfs-driver-qat
@@ -1,6 +1,6 @@
What: /sys/bus/pci/devices/<BDF>/qat/state
Date: June 2022
-KernelVersion: 5.20
+KernelVersion: 6.0
Contact: qat-linux@intel.com
Description: (RW) Reports the current state of the QAT device. Write to
the file to start or stop the device.
@@ -14,20 +14,37 @@ Description: (RW) Reports the current state of the QAT device. Write to
It is possible to transition the device from up to down only
if the device is up and vice versa.
- This attribute is only available for qat_4xxx devices.
+ This attribute is available for qat_4xxx and qat_6xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/cfg_services
Date: June 2022
-KernelVersion: 5.20
+KernelVersion: 6.0
Contact: qat-linux@intel.com
Description: (RW) Reports the current configuration of the QAT device.
Write to the file to change the configured services.
- The values are:
+ One or more services can be enabled per device.
+ Certain configurations are restricted to specific device types;
+ where applicable this is explicitly indicated, for example
+ (qat_6xxx) denotes applicability exclusively to that device series.
- * sym;asym: the device is configured for running crypto
- services
- * dc: the device is configured for running compression services
+ The available services include:
+
+ * sym: Configures the device for symmetric cryptographic operations.
+ * asym: Configures the device for asymmetric cryptographic operations.
+ * dc: Configures the device for compression and decompression
+ operations.
+ * dcc: Similar to dc, but with the additional dc chaining feature
+ enabled, cipher then compress (qat_6xxx), hash then compression.
+ If this is not required choose dc.
+ * decomp: Configures the device for decompression operations (qat_6xxx).
+
+ Service combinations are permitted for all services except dcc.
+ On QAT GEN4 devices (qat_4xxx driver) a maximum of two services can be
+ combined and on QAT GEN6 devices (qat_6xxx driver ) a maximum of three
+ services can be combined.
+ The order of services is not significant. For instance, sym;asym is
+ functionally equivalent to asym;sym.
It is possible to set the configuration only if the device
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
@@ -46,4 +63,105 @@ Description: (RW) Reports the current configuration of the QAT device.
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
dc
- This attribute is only available for qat_4xxx devices.
+ This attribute is available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+Date: June 2023
+KernelVersion: 6.5
+Contact: qat-linux@intel.com
+Description: (RW) This configuration option provides a way to force the device into remaining in
+ the MAX power state.
+ If idle support is enabled the device will transition to the `MIN` power state when
+ idle, otherwise will stay in the MAX power state.
+ Write to the file to enable or disable idle support.
+
+ The values are:
+
+ * 0: idle support is disabled
+ * 1: idle support is enabled
+
+ Default value is 1.
+
+ It is possible to set the pm_idle_enabled value only if the device
+ is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
+
+ The following example shows how to change the pm_idle_enabled of
+ a device::
+
+ # cat /sys/bus/pci/devices/<BDF>/qat/state
+ up
+ # cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+ 1
+ # echo down > /sys/bus/pci/devices/<BDF>/qat/state
+ # echo 0 > /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+ # echo up > /sys/bus/pci/devices/<BDF>/qat/state
+ # cat /sys/bus/pci/devices/<BDF>/qat/pm_idle_enabled
+ 0
+
+ This attribute is available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat/rp2srv
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) This attribute provides a way for a user to query a
+ specific ring pair for the type of service that it is currently
+ configured for.
+
+ When written to, the value is cached and used to perform the
+ read operation. Allowed values are in the range 0 to N-1, where
+ N is the max number of ring pairs supported by a device. This
+ can be queried using the attribute qat/num_rps.
+
+ A read returns the service associated to the ring pair queried.
+
+ The values are:
+
+ * dc: the ring pair is configured for running compression services
+ * sym: the ring pair is configured for running symmetric crypto
+ services
+ * asym: the ring pair is configured for running asymmetric crypto
+ services
+
+ Example usage::
+
+ # echo 1 > /sys/bus/pci/devices/<BDF>/qat/rp2srv
+ # cat /sys/bus/pci/devices/<BDF>/qat/rp2srv
+ sym
+
+ This attribute is available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat/num_rps
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RO) Returns the number of ring pairs that a single device has.
+
+ Example usage::
+
+ # cat /sys/bus/pci/devices/<BDF>/qat/num_rps
+ 64
+
+ This attribute is available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat/auto_reset
+Date: May 2024
+KernelVersion: 6.9
+Contact: qat-linux@intel.com
+Description: (RW) Reports the current state of the autoreset feature
+ for a QAT device
+
+ Write to the attribute to enable or disable device auto reset.
+
+ Device auto reset is disabled by default.
+
+ The values are:
+
+ * 1/Yy/on: auto reset enabled. If the device encounters an
+ unrecoverable error, it will be reset automatically.
+ * 0/Nn/off: auto reset disabled. If the device encounters an
+ unrecoverable error, it will not be reset.
+
+ This attribute is available for qat_4xxx and qat_6xxx devices.
diff --git a/Documentation/ABI/testing/sysfs-driver-qat_ras b/Documentation/ABI/testing/sysfs-driver-qat_ras
new file mode 100644
index 000000000000..82ceb04445ec
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-qat_ras
@@ -0,0 +1,41 @@
+What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description: (RO) Reports the number of correctable errors detected by the device.
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description: (RO) Reports the number of non fatal errors detected by the device.
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description: (RO) Reports the number of fatal errors detected by the device.
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description: (WO) Write to resets all error counters of a device.
+
+ The following example reports how to reset the counters::
+
+ # echo 1 > /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
+ # cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
+ 0
+ # cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
+ 0
+ # cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
+ 0
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
diff --git a/Documentation/ABI/testing/sysfs-driver-qat_rl b/Documentation/ABI/testing/sysfs-driver-qat_rl
new file mode 100644
index 000000000000..d534f89b4971
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-qat_rl
@@ -0,0 +1,226 @@
+What: /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (WO) This attribute is used to perform an operation on an SLA.
+ The supported operations are: add, update, rm, rm_all, and get.
+
+ Input values must be filled through the associated attribute in
+ this group before a write to this file.
+ If the operation completes successfully, the associated
+ attributes will be updated.
+ The associated attributes are: cir, pir, srv, rp, and id.
+
+ Supported operations:
+
+ * add: Creates a new SLA with the provided inputs from user.
+ * Inputs: cir, pir, srv, and rp
+ * Output: id
+
+ * get: Returns the configuration of the specified SLA in id attribute
+ * Inputs: id
+ * Outputs: cir, pir, srv, and rp
+
+ * update: Updates the SLA with new values set in the following attributes
+ * Inputs: id, cir, and pir
+
+ * rm: Removes the specified SLA in the id attribute.
+ * Inputs: id
+
+ * rm_all: Removes all the configured SLAs.
+ * Inputs: None
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_rl/rp
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) When read, reports the current assigned ring pairs for the
+ queried SLA.
+ When wrote to, configures the ring pairs associated to a new SLA.
+
+ The value is a 64-bit bit mask and is written/displayed in hex.
+ Each bit of this mask represents a single ring pair i.e.,
+ bit 1 == ring pair id 0; bit 3 == ring pair id 2.
+
+ Selected ring pairs must to be assigned to a single service,
+ i.e. the one provided with the srv attribute. The service
+ assigned to a certain ring pair can be checked by querying
+ the attribute qat/rp2srv.
+
+ The maximum number of ring pairs is 4 per SLA.
+
+ Applicability in sla_op:
+
+ * WRITE: add operation
+ * READ: get operation
+
+ Example usage::
+
+ ## Read
+ # echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
+ 0x5
+
+ ## Write
+ # echo 0x5 > /sys/bus/pci/devices/<BDF>/qat_rl/rp
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_rl/id
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) If written to, the value is used to retrieve a particular
+ SLA and operate on it.
+ This is valid only for the following operations: update, rm,
+ and get.
+ A read of this attribute is only guaranteed to have correct data
+ after creation of an SLA.
+
+ Applicability in sla_op:
+
+ * WRITE: rm and update operations
+ * READ: add and get operations
+
+ Example usage::
+
+ ## Read
+ ## Set attributes e.g. cir, pir, srv, etc
+ # echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/id
+ 4
+
+ ## Write
+ # echo 7 > /sys/bus/pci/devices/<BDF>/qat_rl/id
+ # echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
+ 0x5 ## ring pair ID 0 and ring pair ID 2
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_rl/cir
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) Committed information rate (CIR). Rate guaranteed to be
+ achieved by a particular SLA. The value is expressed in
+ permille scale, i.e. 1000 refers to the maximum device
+ throughput for a selected service.
+
+ After sending a "get" to sla_op, this will be populated with the
+ CIR for that queried SLA.
+ Write to this file before sending an "add/update" sla_op, to set
+ the SLA to the specified value.
+
+ Applicability in sla_op:
+
+ * WRITE: add and update operations
+ * READ: get operation
+
+ Example usage::
+
+ ## Write
+ # echo 500 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
+ # echo "add" /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+
+ ## Read
+ # echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
+ # echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/cir
+ 500
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_rl/pir
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) Peak information rate (PIR). The maximum rate that can be
+ achieved by that particular SLA. An SLA can reach a value
+ between CIR and PIR when the device is not fully utilized by
+ requests from other users (assigned to different SLAs).
+
+ After sending a "get" to sla_op, this will be populated with the
+ PIR for that queried SLA.
+ Write to this file before sending an "add/update" sla_op, to set
+ the SLA to the specified value.
+
+ Applicability in sla_op:
+
+ * WRITE: add and update operations
+ * READ: get operation
+
+ Example usage::
+
+ ## Write
+ # echo 750 > /sys/bus/pci/devices/<BDF>/qat_rl/pir
+ # echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+
+ ## Read
+ # echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
+ # echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/pir
+ 750
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_rl/srv
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) Service (SRV). Represents the service (sym, asym, dc)
+ associated to an SLA.
+ Can be written to or queried to set/show the SRV type for an SLA.
+ The SRV attribute is used to specify the SRV type before adding
+ an SLA. After an SLA is configured, reports the service
+ associated to that SLA.
+
+ Applicability in sla_op:
+
+ * WRITE: add and update operations
+ * READ: get operation
+
+ Example usage::
+
+ ## Write
+ # echo "dc" > /sys/bus/pci/devices/<BDF>/qat_rl/srv
+ # echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/id
+ 4
+
+ ## Read
+ # echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
+ # echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/srv
+ dc
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
+
+What: /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
+Date: January 2024
+KernelVersion: 6.7
+Contact: qat-linux@intel.com
+Description:
+ (RW) This file will return the remaining capability for a
+ particular service/sla. This is the remaining value that a new
+ SLA can be set to or a current SLA can be increased with.
+
+ Example usage::
+
+ # echo "asym" > /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
+ 250
+ # echo 250 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
+ # echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
+ # cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
+ 0
+
+ This attribute is only available for qat_4xxx and qat_6xxx devices.
diff --git a/Documentation/ABI/testing/sysfs-driver-samsung-laptop b/Documentation/ABI/testing/sysfs-driver-samsung-laptop
index 28c9c040de5d..408cb0ddf4aa 100644
--- a/Documentation/ABI/testing/sysfs-driver-samsung-laptop
+++ b/Documentation/ABI/testing/sysfs-driver-samsung-laptop
@@ -20,17 +20,6 @@ Description: Some Samsung laptops have different "performance levels"
and it's still unknown if this value even changes
anything, other than making the user feel a bit better.
-What: /sys/devices/platform/samsung/battery_life_extender
-Date: December 1, 2011
-KernelVersion: 3.3
-Contact: Corentin Chary <corentin.chary@gmail.com>
-Description: Max battery charge level can be modified, battery cycle
- life can be extended by reducing the max battery charge
- level.
-
- - 0 means normal battery mode (100% charge)
- - 1 means battery life extender mode (80% charge)
-
What: /sys/devices/platform/samsung/usb_charge
Date: December 1, 2011
KernelVersion: 3.3
diff --git a/Documentation/ABI/testing/sysfs-driver-spi-intel b/Documentation/ABI/testing/sysfs-driver-spi-intel
new file mode 100644
index 000000000000..d7c9139ddbf3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-spi-intel
@@ -0,0 +1,20 @@
+What: /sys/devices/.../intel_spi_protected
+Date: Feb 2025
+KernelVersion: 6.13
+Contact: Alexander Usyskin <alexander.usyskin@intel.com>
+Description: This attribute allows the userspace to check if the
+ Intel SPI flash controller is write protected from the host.
+
+What: /sys/devices/.../intel_spi_locked
+Date: Feb 2025
+KernelVersion: 6.13
+Contact: Alexander Usyskin <alexander.usyskin@intel.com>
+Description: This attribute allows the user space to check if the
+ Intel SPI flash controller locks supported opcodes.
+
+What: /sys/devices/.../intel_spi_bios_locked
+Date: Feb 2025
+KernelVersion: 6.13
+Contact: Alexander Usyskin <alexander.usyskin@intel.com>
+Description: This attribute allows the user space to check if the
+ Intel SPI flash controller BIOS region is locked for writes.
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
index 69f5af632657..b8936fad2ccf 100644
--- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
@@ -3,7 +3,7 @@ Date: February 2014
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
- data programmed at the factory. The data is layed out in 32bit
+ data programmed at the factory. The data is laid out in 32bit
words in LSB first format. Each bit represents a single value
as decoded from the fuse registers. Bits order/assignment
exactly matches the HW registers, including any unused bits.
diff --git a/Documentation/ABI/testing/sysfs-driver-typec-displayport b/Documentation/ABI/testing/sysfs-driver-typec-displayport
index 231471ad0d4b..314acd54e13e 100644
--- a/Documentation/ABI/testing/sysfs-driver-typec-displayport
+++ b/Documentation/ABI/testing/sysfs-driver-typec-displayport
@@ -47,3 +47,28 @@ Description:
USB SuperSpeed protocol. From user perspective pin assignments C
and E are equal, where all channels on the connector are used
for carrying DisplayPort protocol (allowing higher resolutions).
+
+What: /sys/bus/typec/devices/.../displayport/hpd
+Date: Dec 2022
+Contact: Badhri Jagan Sridharan <badhri@google.com>
+Description:
+ VESA DisplayPort Alt Mode on USB Type-C Standard defines how
+ HotPlugDetect(HPD) shall be supported on the USB-C connector when
+ operating in DisplayPort Alt Mode. This is a read only node which
+ reflects the current state of HPD.
+
+ Valid values:
+ - 1: when HPD’s logical state is high (HPD_High) as defined
+ by VESA DisplayPort Alt Mode on USB Type-C Standard.
+ - 0 when HPD’s logical state is low (HPD_Low) as defined by
+ VESA DisplayPort Alt Mode on USB Type-C Standard.
+
+What: /sys/bus/typec/devices/.../displayport/irq_hpd
+Date: June 2025
+Contact: RD Babiera <rdbabiera@google.com>
+Description:
+ IRQ_HPD events are sent over the USB PD protocol in Status Update and
+ Attention messages. IRQ_HPD can only be asserted when HPD is high,
+ and is asserted when an IRQ_HPD has been issued since the last Status
+ Update. This is a read only node that returns the number of IRQ events
+ raised in the driver's lifetime.
diff --git a/Documentation/ABI/testing/sysfs-driver-uacce b/Documentation/ABI/testing/sysfs-driver-uacce
index 08f2591138af..d3f0b8f3c589 100644
--- a/Documentation/ABI/testing/sysfs-driver-uacce
+++ b/Documentation/ABI/testing/sysfs-driver-uacce
@@ -19,6 +19,24 @@ Contact: linux-accelerators@lists.ozlabs.org
Description: Available instances left of the device
Return -ENODEV if uacce_ops get_available_instances is not provided
+What: /sys/class/uacce/<dev_name>/isolate_strategy
+Date: Nov 2022
+KernelVersion: 6.1
+Contact: linux-accelerators@lists.ozlabs.org
+Description: (RW) A sysfs node that configure the error threshold for the hardware
+ isolation strategy. This size is a configured integer value, which is the
+ number of threshold for hardware errors occurred in one hour. The default is 0.
+ 0 means never isolate the device. The maximum value is 65535. You can write
+ a number of threshold based on your hardware.
+
+What: /sys/class/uacce/<dev_name>/isolate
+Date: Nov 2022
+KernelVersion: 6.1
+Contact: linux-accelerators@lists.ozlabs.org
+Description: (R) A sysfs node that read the device isolated state. The value 1
+ means the device is unavailable. The 0 means the device is
+ available.
+
What: /sys/class/uacce/<dev_name>/algorithms
Date: Feb 2020
KernelVersion: 5.7
diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs
index 6b248abb1bd7..a90612ab5780 100644
--- a/Documentation/ABI/testing/sysfs-driver-ufs
+++ b/Documentation/ABI/testing/sysfs-driver-ufs
@@ -711,7 +711,7 @@ Description: This file shows the thin provisioning type. This is one of
The file is read only.
-What: /sys/class/scsi_device/*/device/unit_descriptor/physical_memory_resourse_count
+What: /sys/class/scsi_device/*/device/unit_descriptor/physical_memory_resource_count
Date: February 2018
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
Description: This file shows the total physical memory resources. This is
@@ -920,14 +920,16 @@ Description: This file shows whether the configuration descriptor is locked.
What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_number_of_rtt
What: /sys/bus/platform/devices/*.ufs/attributes/max_number_of_rtt
-Date: February 2018
-Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
+Date: May 2024
+Contact: Avri Altman <avri.altman@wdc.com>
Description: This file provides the maximum current number of
- outstanding RTTs in device that is allowed. The full
- information about the attribute could be found at
- UFS specifications 2.1.
+ outstanding RTTs in device that is allowed. bMaxNumOfRTT is a
+ read-write persistent attribute and is equal to two after device
+ manufacturing. It shall not be set to a value greater than
+ bDeviceRTTCap value, and it may be set only when the hw queues are
+ empty.
- The file is read only.
+ The file is read write.
What: /sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_control
What: /sys/bus/platform/devices/*.ufs/attributes/exception_event_control
@@ -994,7 +996,7 @@ Description: This file shows the amount of physical memory needed
What: /sys/bus/platform/drivers/ufshcd/*/rpm_lvl
What: /sys/bus/platform/devices/*.ufs/rpm_lvl
Date: September 2014
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry could be used to set or show the UFS device
runtime power management level. The current driver
implementation supports 7 levels with next target states:
@@ -1021,7 +1023,7 @@ Description: This entry could be used to set or show the UFS device
What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state
What: /sys/bus/platform/devices/*.ufs/rpm_target_dev_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target power mode of an UFS device
for the chosen runtime power management level.
@@ -1030,7 +1032,7 @@ Description: This entry shows the target power mode of an UFS device
What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_link_state
What: /sys/bus/platform/devices/*.ufs/rpm_target_link_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target state of an UFS UIC link
for the chosen runtime power management level.
@@ -1039,7 +1041,7 @@ Description: This entry shows the target state of an UFS UIC link
What: /sys/bus/platform/drivers/ufshcd/*/spm_lvl
What: /sys/bus/platform/devices/*.ufs/spm_lvl
Date: September 2014
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry could be used to set or show the UFS device
system power management level. The current driver
implementation supports 7 levels with next target states:
@@ -1066,7 +1068,7 @@ Description: This entry could be used to set or show the UFS device
What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state
What: /sys/bus/platform/devices/*.ufs/spm_target_dev_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target power mode of an UFS device
for the chosen system power management level.
@@ -1075,7 +1077,7 @@ Description: This entry shows the target power mode of an UFS device
What: /sys/bus/platform/drivers/ufshcd/*/spm_target_link_state
What: /sys/bus/platform/devices/*.ufs/spm_target_link_state
Date: February 2018
-Contact: Subhash Jadavani <subhashj@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This entry shows the target state of an UFS UIC link
for the chosen system power management level.
@@ -1084,7 +1086,7 @@ Description: This entry shows the target state of an UFS UIC link
What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable
What: /sys/bus/platform/devices/*.ufs/monitor/monitor_enable
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the status of performance monitor enablement
and it can be used to start/stop the monitor. When the monitor
is stopped, the performance data collected is also cleared.
@@ -1092,7 +1094,7 @@ Description: This file shows the status of performance monitor enablement
What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size
What: /sys/bus/platform/devices/*.ufs/monitor/monitor_chunk_size
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file tells the monitor to focus on requests transferring
data of specific chunk size (in Bytes). 0 means any chunk size.
It can only be changed when monitor is disabled.
@@ -1100,7 +1102,7 @@ Description: This file tells the monitor to focus on requests transferring
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors
What: /sys/bus/platform/devices/*.ufs/monitor/read_total_sectors
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many sectors (in 512 Bytes) have been
sent from device to host after monitor gets started.
@@ -1109,7 +1111,7 @@ Description: This file shows how many sectors (in 512 Bytes) have been
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy
What: /sys/bus/platform/devices/*.ufs/monitor/read_total_busy
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how long (in micro seconds) has been spent
sending data from device to host after monitor gets started.
@@ -1118,7 +1120,7 @@ Description: This file shows how long (in micro seconds) has been spent
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests
What: /sys/bus/platform/devices/*.ufs/monitor/read_nr_requests
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many read requests have been sent after
monitor gets started.
@@ -1127,7 +1129,7 @@ Description: This file shows how many read requests have been sent after
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_max
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the maximum latency (in micro seconds) of
read requests after monitor gets started.
@@ -1136,7 +1138,7 @@ Description: This file shows the maximum latency (in micro seconds) of
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_min
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the minimum latency (in micro seconds) of
read requests after monitor gets started.
@@ -1145,7 +1147,7 @@ Description: This file shows the minimum latency (in micro seconds) of
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_avg
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the average latency (in micro seconds) of
read requests after monitor gets started.
@@ -1154,7 +1156,7 @@ Description: This file shows the average latency (in micro seconds) of
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum
What: /sys/bus/platform/devices/*.ufs/monitor/read_req_latency_sum
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the total latency (in micro seconds) of
read requests sent after monitor gets started.
@@ -1163,7 +1165,7 @@ Description: This file shows the total latency (in micro seconds) of
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors
What: /sys/bus/platform/devices/*.ufs/monitor/write_total_sectors
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many sectors (in 512 Bytes) have been sent
from host to device after monitor gets started.
@@ -1172,7 +1174,7 @@ Description: This file shows how many sectors (in 512 Bytes) have been sent
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy
What: /sys/bus/platform/devices/*.ufs/monitor/write_total_busy
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how long (in micro seconds) has been spent
sending data from host to device after monitor gets started.
@@ -1181,7 +1183,7 @@ Description: This file shows how long (in micro seconds) has been spent
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests
What: /sys/bus/platform/devices/*.ufs/monitor/write_nr_requests
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows how many write requests have been sent after
monitor gets started.
@@ -1190,7 +1192,7 @@ Description: This file shows how many write requests have been sent after
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_max
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the maximum latency (in micro seconds) of write
requests after monitor gets started.
@@ -1199,7 +1201,7 @@ Description: This file shows the maximum latency (in micro seconds) of write
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_min
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the minimum latency (in micro seconds) of write
requests after monitor gets started.
@@ -1208,7 +1210,7 @@ Description: This file shows the minimum latency (in micro seconds) of write
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_avg
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the average latency (in micro seconds) of write
requests after monitor gets started.
@@ -1217,16 +1219,65 @@ Description: This file shows the average latency (in micro seconds) of write
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum
What: /sys/bus/platform/devices/*.ufs/monitor/write_req_latency_sum
Date: January 2021
-Contact: Can Guo <cang@codeaurora.org>
+Contact: Can Guo <quic_cang@quicinc.com>
Description: This file shows the total latency (in micro seconds) of write
requests after monitor gets started.
The file is read only.
+What: /sys/bus/platform/drivers/ufshcd/*/power_info/lane
+What: /sys/bus/platform/devices/*.ufs/power_info/lane
+Date: September 2023
+Contact: Can Guo <quic_cang@quicinc.com>
+Description: This file shows how many lanes are enabled on the UFS link,
+ i.e., an output 2 means UFS link is operating with 2 lanes.
+
+ The file is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/power_info/mode
+What: /sys/bus/platform/devices/*.ufs/power_info/mode
+Date: September 2023
+Contact: Can Guo <quic_cang@quicinc.com>
+Description: This file shows the PA power mode of UFS.
+
+ The file is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/power_info/rate
+What: /sys/bus/platform/devices/*.ufs/power_info/rate
+Date: September 2023
+Contact: Can Guo <quic_cang@quicinc.com>
+Description: This file shows the speed rate of UFS link.
+
+ The file is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/power_info/gear
+What: /sys/bus/platform/devices/*.ufs/power_info/gear
+Date: September 2023
+Contact: Can Guo <quic_cang@quicinc.com>
+Description: This file shows the gear of UFS link.
+
+ The file is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/power_info/dev_pm
+What: /sys/bus/platform/devices/*.ufs/power_info/dev_pm
+Date: September 2023
+Contact: Can Guo <quic_cang@quicinc.com>
+Description: This file shows the UFS device power mode.
+
+ The file is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/power_info/link_state
+What: /sys/bus/platform/devices/*.ufs/power_info/link_state
+Date: September 2023
+Contact: Can Guo <quic_cang@quicinc.com>
+Description: This file shows the state of UFS link.
+
+ The file is read only.
+
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en
What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_presv_us_en
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows if preserve user-space was configured
The file is read only.
@@ -1234,7 +1285,7 @@ Description: This entry shows if preserve user-space was configured
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units
What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_shared_alloc_units
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the shared allocated units of WB buffer
The file is read only.
@@ -1242,7 +1293,7 @@ Description: This entry shows the shared allocated units of WB buffer
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type
What: /sys/bus/platform/devices/*.ufs/device_descriptor/wb_type
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the configured WB type.
0x1 for shared buffer mode. 0x0 for dedicated buffer mode.
@@ -1251,7 +1302,7 @@ Description: This entry shows the configured WB type.
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_buff_cap_adj
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the total user-space decrease in shared
buffer mode.
The value of this parameter is 3 for TLC NAND when SLC mode
@@ -1262,7 +1313,7 @@ Description: This entry shows the total user-space decrease in shared
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_alloc_units
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the Maximum total WriteBooster Buffer size
which is supported by the entire device.
@@ -1271,7 +1322,7 @@ Description: This entry shows the Maximum total WriteBooster Buffer size
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_max_wb_luns
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the maximum number of luns that can support
WriteBooster.
@@ -1280,7 +1331,7 @@ Description: This entry shows the maximum number of luns that can support
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_red_type
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: The supportability of user space reduction mode
and preserve user space mode.
00h: WriteBooster Buffer can be configured only in
@@ -1295,7 +1346,7 @@ Description: The supportability of user space reduction mode
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type
What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/wb_sup_wb_type
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: The supportability of WriteBooster Buffer type.
=== ==========================================================
@@ -1310,7 +1361,7 @@ Description: The supportability of WriteBooster Buffer type.
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable
What: /sys/bus/platform/devices/*.ufs/flags/wb_enable
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the status of WriteBooster.
== ============================
@@ -1323,7 +1374,7 @@ Description: This entry shows the status of WriteBooster.
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en
What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_en
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows if flush is enabled.
== =================================
@@ -1336,7 +1387,7 @@ Description: This entry shows if flush is enabled.
What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8
What: /sys/bus/platform/devices/*.ufs/flags/wb_flush_during_h8
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: Flush WriteBooster Buffer during hibernate state.
== =================================================
@@ -1351,7 +1402,7 @@ Description: Flush WriteBooster Buffer during hibernate state.
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf
What: /sys/bus/platform/devices/*.ufs/attributes/wb_avail_buf
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the amount of unused WriteBooster buffer
available.
@@ -1360,7 +1411,7 @@ Description: This entry shows the amount of unused WriteBooster buffer
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf
What: /sys/bus/platform/devices/*.ufs/attributes/wb_cur_buf
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the amount of unused current buffer.
The file is read only.
@@ -1368,7 +1419,7 @@ Description: This entry shows the amount of unused current buffer.
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status
What: /sys/bus/platform/devices/*.ufs/attributes/wb_flush_status
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the flush operation status.
@@ -1385,7 +1436,7 @@ Description: This entry shows the flush operation status.
What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est
What: /sys/bus/platform/devices/*.ufs/attributes/wb_life_time_est
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows an indication of the WriteBooster Buffer
lifetime based on the amount of performed program/erase cycles
@@ -1399,7 +1450,7 @@ Description: This entry shows an indication of the WriteBooster Buffer
What: /sys/class/scsi_device/*/device/unit_descriptor/wb_buf_alloc_units
Date: June 2020
-Contact: Asutosh Das <asutoshd@codeaurora.org>
+Contact: Asutosh Das <quic_asutoshd@quicinc.com>
Description: This entry shows the configured size of WriteBooster buffer.
0400h corresponds to 4GB.
@@ -1417,250 +1468,303 @@ Description: This node is used to set or display whether UFS WriteBooster is
platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can
disable/enable WriteBooster through this sysfs node.
-What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
-What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_version
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the HPB specification version.
- The full information about the descriptor can be found in the UFS
- HPB (Host Performance Booster) Extension specifications.
- Example: version 1.2.3 = 0123h
-
- The file is read only.
+What: /sys/bus/platform/drivers/ufshcd/*/enable_wb_buf_flush
+What: /sys/bus/platform/devices/*.ufs/enable_wb_buf_flush
+Date: July 2022
+Contact: Jinyoung Choi <j-young.choi@samsung.com>
+Description: This entry shows the status of WriteBooster buffer flushing
+ and it can be used to enable or disable the flushing.
+ If flushing is enabled, the device executes the flush
+ operation when the command queue is empty.
+
+What: /sys/bus/platform/drivers/ufshcd/*/wb_flush_threshold
+What: /sys/bus/platform/devices/*.ufs/wb_flush_threshold
+Date: June 2023
+Contact: Lu Hongfei <luhongfei@vivo.com>
+Description:
+ wb_flush_threshold represents the threshold for flushing WriteBooster buffer,
+ whose value expressed in unit of 10% granularity, such as '1' representing 10%,
+ '2' representing 20%, and so on.
+ If avail_wb_buff < wb_flush_threshold, it indicates that WriteBooster buffer needs to
+ be flushed, otherwise it is not necessary.
+
+Contact: Daniil Lunev <dlunev@chromium.org>
+What: /sys/bus/platform/drivers/ufshcd/*/capabilities/
+What: /sys/bus/platform/devices/*.ufs/capabilities/
+Date: August 2022
+Description: The group represents the effective capabilities of the
+ host-device pair. i.e. the capabilities which are enabled in the
+ driver for the specific host controller, supported by the host
+ controller and are supported and/or have compatible
+ configuration on the device side.
+
+Contact: Daniil Lunev <dlunev@chromium.org>
+What: /sys/bus/platform/drivers/ufshcd/*/capabilities/clock_scaling
+What: /sys/bus/platform/devices/*.ufs/capabilities/clock_scaling
+Date: August 2022
+Contact: Daniil Lunev <dlunev@chromium.org>
+Description: Indicates status of clock scaling.
-What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control
-What: /sys/bus/platform/devices/*.ufs/device_descriptor/hpb_control
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows an indication of the HPB control mode.
- 00h: Host control mode
- 01h: Device control mode
+ == ============================
+ 0 Clock scaling is not supported.
+ 1 Clock scaling is supported.
+ == ============================
The file is read only.
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_region_size
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the bHPBRegionSize which can be calculated
- as in the following (in bytes):
- HPB Region size = 512B * 2^bHPBRegionSize
-
- The file is read only.
+What: /sys/bus/platform/drivers/ufshcd/*/capabilities/write_booster
+What: /sys/bus/platform/devices/*.ufs/capabilities/write_booster
+Date: August 2022
+Contact: Daniil Lunev <dlunev@chromium.org>
+Description: Indicates status of Write Booster.
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_number_lu
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum number of HPB LU supported by
- the device.
- 00h: HPB is not supported by the device.
- 01h ~ 20h: Maximum number of HPB LU supported by the device
+ == ============================
+ 0 Write Booster can not be enabled.
+ 1 Write Booster can be enabled.
+ == ============================
The file is read only.
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_subregion_size
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the bHPBSubRegionSize, which can be
- calculated as in the following (in bytes) and shall be a multiple of
- logical block size:
- HPB Sub-Region size = 512B x 2^bHPBSubRegionSize
- bHPBSubRegionSize shall not exceed bHPBRegionSize.
+What: /sys/bus/platform/drivers/ufshcd/*/rtc_update_ms
+What: /sys/bus/platform/devices/*.ufs/rtc_update_ms
+Date: November 2023
+Contact: Bean Huo <beanhuo@micron.com>
+Description:
+ rtc_update_ms indicates how often the host should synchronize or update the
+ UFS RTC. If set to 0, this will disable UFS RTC periodic update.
+What: /sys/devices/platform/.../ufshci_capabilities/version
+Date: August 2024
+Contact: Avri Altman <avri.altman@wdc.com>
+Description:
+ Host Capabilities register group: UFS version register.
+ Symbol - VER. This file shows the UFSHCD version.
+ Example: Version 3.12 would be represented as 0000_0312h.
The file is read only.
-What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions
-What: /sys/bus/platform/devices/*.ufs/geometry_descriptor/hpb_max_active_regions
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum number of active HPB regions that
- is supported by the device.
+What: /sys/devices/platform/.../ufshci_capabilities/product_id
+Date: August 2024
+Contact: Avri Altman <avri.altman@wdc.com>
+Description:
+ Host Capabilities register group: product ID register.
+ Symbol - HCPID. This file shows the UFSHCD product id.
+ The content of this register is vendor specific.
+ The file is read only.
+What: /sys/devices/platform/.../ufshci_capabilities/man_id
+Date: August 2024
+Contact: Avri Altman <avri.altman@wdc.com>
+Description:
+ Host Capabilities register group: manufacturer ID register.
+ Symbol - HCMID. This file shows the UFSHCD manufacturer id.
+ The Manufacturer ID is defined by JEDEC in JEDEC-JEP106.
The file is read only.
-What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum number of HPB regions assigned to
- the HPB logical unit.
+What: /sys/bus/platform/drivers/ufshcd/*/critical_health
+What: /sys/bus/platform/devices/*.ufs/critical_health
+Date: February 2025
+Contact: Avri Altman <avri.altman@wdc.com>
+Description: Report the number of times a critical health event has been
+ reported by a UFS device. Further insight into the specific
+ issue can be gained by reading one of: bPreEOLInfo,
+ bDeviceLifeTimeEstA, bDeviceLifeTimeEstB,
+ bWriteBoosterBufferLifeTimeEst, and bRPMBLifeTimeEst.
The file is read only.
-What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the start offset of HPB pinned region.
+What: /sys/bus/platform/drivers/ufshcd/*/clkscale_enable
+What: /sys/bus/platform/devices/*.ufs/clkscale_enable
+Date: January 2025
+Contact: Ziqi Chen <quic_ziqichen@quicinc.com>
+Description:
+ This attribute shows whether the UFS clock scaling is enabled or not.
+ And it can be used to enable/disable the clock scaling by writing
+ 1 or 0 to this attribute.
- The file is read only.
+ The attribute is read/write.
-What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of HPB pinned regions assigned to
- the HPB logical unit.
+What: /sys/bus/platform/drivers/ufshcd/*/clkgate_enable
+What: /sys/bus/platform/devices/*.ufs/clkgate_enable
+Date: January 2025
+Contact: Ziqi Chen <quic_ziqichen@quicinc.com>
+Description:
+ This attribute shows whether the UFS clock gating is enabled or not.
+ And it can be used to enable/disable the clock gating by writing
+ 1 or 0 to this attribute.
- The file is read only.
+ The attribute is read/write.
-What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of reads that changed to HPB read.
+What: /sys/bus/platform/drivers/ufshcd/*/clkgate_delay_ms
+What: /sys/bus/platform/devices/*.ufs/clkgate_delay_ms
+Date: January 2025
+Contact: Ziqi Chen <quic_ziqichen@quicinc.com>
+Description:
+ This attribute shows and sets the number of milliseconds of idle time
+ before the UFS driver starts to perform clock gating. This can
+ prevent the UFS from frequently performing clock gating/ungating.
- The file is read only.
+ The attribute is read/write.
-What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of reads that cannot be changed to
- HPB read.
+What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_count
+What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_count
+Date: March 2025
+Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
+Description:
+ This attribute is applicable to ufs devices compliant to the
+ JEDEC specifications version 4.1 or later. The
+ device_lvl_exception_count is a counter indicating the number of
+ times the device level exceptions have occurred since the last
+ time this variable is reset. Writing a 0 value to this
+ attribute will reset the device_lvl_exception_count. If the
+ device_lvl_exception_count reads a positive value, the user
+ application should read the device_lvl_exception_id attribute to
+ know more information about the exception.
+
+ The attribute is read/write.
+
+What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_id
+What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_id
+Date: March 2025
+Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
+Description:
+ Reading the device_lvl_exception_id returns the
+ qDeviceLevelExceptionID attribute of the ufs device JEDEC
+ specification version 4.1. The definition of the
+ qDeviceLevelExceptionID is the ufs device vendor specific
+ implementation. Refer to the device manufacturer datasheet for
+ more information on the meaning of the qDeviceLevelExceptionID
+ attribute value.
+
+ The attribute is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/wb_resize_enable
+What: /sys/bus/platform/devices/*.ufs/wb_resize_enable
+Date: April 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The host can enable the WriteBooster buffer resize by setting this
+ attribute.
- The file is read only.
+ ======== ======================================
+ idle There is no resize operation
+ decrease Decrease WriteBooster buffer size
+ increase Increase WriteBooster buffer size
+ ======== ======================================
-What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_noti_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of response UPIUs that has
- recommendations for activating sub-regions and/or inactivating region.
+ The file is write only.
- The file is read only.
+What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_resize_hint
+What: /sys/bus/platform/devices/*.ufs/attributes/wb_resize_hint
+Date: April 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ wb_resize_hint indicates hint information about which type of resize
+ for WriteBooster buffer is recommended by the device.
-What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_active_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: For the HPB device control mode, this entry shows the number of
- active sub-regions recommended by response UPIUs. For the HPB host control
- mode, this entry shows the number of active sub-regions recommended by the
- HPB host control mode heuristic algorithm.
+ ========= ======================================
+ keep Recommend keep the buffer size
+ decrease Recommend to decrease the buffer size
+ increase Recommend to increase the buffer size
+ ========= ======================================
The file is read only.
-What: /sys/class/scsi_device/*/device/hpb_stats/rcmd_inactive_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: For the HPB device control mode, this entry shows the number of
- inactive regions recommended by response UPIUs. For the HPB host control
- mode, this entry shows the number of inactive regions recommended by the
- HPB host control mode heuristic algorithm.
+What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_resize_status
+What: /sys/bus/platform/devices/*.ufs/attributes/wb_resize_status
+Date: April 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The host can check the resize operation status of the WriteBooster
+ buffer by reading this attribute.
+
+ ================ ========================================
+ idle Resize operation is not issued
+ in_progress Resize operation in progress
+ complete_success Resize operation completed successfully
+ general_failure Resize operation general failure
+ ================ ========================================
The file is read only.
-What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the number of read buffer commands for
- activating sub-regions recommended by response UPIUs.
+What: /sys/bus/platform/drivers/ufshcd/*/hid/analysis_trigger
+What: /sys/bus/platform/devices/*.ufs/hid/analysis_trigger
+Date: May 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The host can enable or disable HID analysis operation.
- The file is read only.
+ ======= =========================================
+ disable disable HID analysis operation
+ enable enable HID analysis operation
+ ======= =========================================
-What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the requeue timeout threshold for write buffer
- command in ms. The value can be changed by writing an integer to
- this entry.
+ The file is write only.
-What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd
-What: /sys/bus/platform/devices/*.ufs/attributes/max_data_size_hpb_single_cmd
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the maximum HPB data size for using a single HPB
- command.
+What: /sys/bus/platform/drivers/ufshcd/*/hid/defrag_trigger
+What: /sys/bus/platform/devices/*.ufs/hid/defrag_trigger
+Date: May 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The host can enable or disable HID defragmentation operation.
- === ========
- 00h 4KB
- 01h 8KB
- 02h 12KB
- ...
- FFh 1024KB
- === ========
+ ======= =========================================
+ disable disable HID defragmentation operation
+ enable enable HID defragmentation operation
+ ======= =========================================
- The file is read only.
+ The attribute is write only.
-What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable
-What: /sys/bus/platform/devices/*.ufs/flags/hpb_enable
-Date: June 2021
-Contact: Daejun Park <daejun7.park@samsung.com>
-Description: This entry shows the status of HPB.
+What: /sys/bus/platform/drivers/ufshcd/*/hid/fragmented_size
+What: /sys/bus/platform/devices/*.ufs/hid/fragmented_size
+Date: May 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The total fragmented size in the device is reported through
+ this attribute.
- == ============================
- 0 HPB is not enabled.
- 1 HPB is enabled
- == ============================
+ The attribute is read only.
- The file is read only.
+What: /sys/bus/platform/drivers/ufshcd/*/hid/defrag_size
+What: /sys/bus/platform/devices/*.ufs/hid/defrag_size
+Date: May 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The host sets the size to be defragmented by an HID
+ defragmentation operation.
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In host control mode, reads are the major source of activation
- trials. Once this threshold hs met, the region is added to the
- "to-be-activated" list. Since we reset the read counter upon
- write, this include sending a rb command updating the region
- ppn as well.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In host control mode, we think of the regions as "buckets".
- Those buckets are being filled with reads, and emptied on write.
- We use entries_per_srgn - the amount of blocks in a subregion as
- our bucket size. This applies because HPB1.0 only handles
- single-block reads. Once the bucket size is crossed, we trigger
- a normalization work - not only to avoid overflow, but mainly
- because we want to keep those counters normalized, as we are
- using those reads as a comparative score, to make various decisions.
- The normalization is dividing (shift right) the read counter by
- the normalization_factor. If during consecutive normalizations
- an active region has exhausted its reads - inactivate it.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: Region deactivation is often due to the fact that eviction took
- place: A region becomes active at the expense of another. This is
- happening when the max-active-regions limit has been crossed.
- In host mode, eviction is considered an extreme measure. We
- want to verify that the entering region has enough reads, and
- the exiting region has much fewer reads. eviction_thld_enter is
- the min reads that a region must have in order to be considered
- a candidate for evicting another region.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: Same as above for the exiting region. A region is considered to
- be a candidate for eviction only if it has fewer reads than
- eviction_thld_exit.
+ The attribute is read/write.
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In order not to hang on to "cold" regions, we inactivate
- a region that has no READ access for a predefined amount of
- time - read_timeout_ms. If read_timeout_ms has expired, and the
- region is dirty, it is less likely that we can make any use of
- HPB reading it so we inactivate it. Still, deactivation has
- its overhead, and we may still benefit from HPB reading this
- region if it is clean - see read_timeout_expiries.
-
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: If the region read timeout has expired, but the region is clean,
- just re-wind its timer for another spin. Do that as long as it
- is clean and did not exhaust its read_timeout_expiries threshold.
+What: /sys/bus/platform/drivers/ufshcd/*/hid/progress_ratio
+What: /sys/bus/platform/devices/*.ufs/hid/progress_ratio
+Date: May 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ Defragmentation progress is reported by this attribute,
+ indicates the ratio of the completed defragmentation size
+ over the requested defragmentation size.
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: The frequency with which the delayed worker that checks the
- read_timeouts is awakened.
+ ==== ============================================
+ 1 1%
+ ...
+ 100 100%
+ ==== ============================================
-What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req
-Date: February 2021
-Contact: Avri Altman <avri.altman@wdc.com>
-Description: In host control mode the host is the originator of map requests.
- To avoid flooding the device with map requests, use a simple throttling
- mechanism that limits the number of inflight map requests.
+ The attribute is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/hid/state
+What: /sys/bus/platform/devices/*.ufs/hid/state
+Date: May 2025
+Contact: Huan Tang <tanghuan@vivo.com>
+Description:
+ The HID state is reported by this attribute.
+
+ ==================== ===========================
+ idle Idle (analysis required)
+ analysis_in_progress Analysis in progress
+ defrag_required Defrag required
+ defrag_in_progress Defrag in progress
+ defrag_completed Defrag completed
+ defrag_not_required Defrag is not required
+ ==================== ===========================
+
+ The attribute is read only.
diff --git a/Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid b/Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid
new file mode 100644
index 000000000000..6892fe46cea8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid
@@ -0,0 +1,29 @@
+What: /sys/bus/pci/drivers/uio_pci_sva/<pci_dev>/pasid
+Date: September 2025
+Contact: Yaxing Guo <guoyaxing@bosc.ac.cn>
+Description:
+ Process Address Space ID (PASID) assigned by IOMMU driver to
+ the device for use with Shared Virtual Addressing (SVA).
+
+ This read-only attribute exposes the PASID (A 20-bit identifier
+ used in PCIe Address Translation Services and iommu table walks)
+ allocated by the IOMMU driver during sva device binding.
+
+ User-space UIO applications must read this attribute to obtain
+ the PASID and program it into the device's configuration registers.
+ This enables the device to perform DMA using user-space virtual
+ address, with address translation handled by IOMMU.
+
+ UIO User-space applications must:
+ - Opening device and Mapping the device's register space via /dev/uioX
+ (This triggers the IOMMU driver to allocate the PASID)
+ - Reading the PASID from sysfs
+ - Writing the PASID to a device-specific register (with example offset)
+ The code may be like:
+
+ map = mmap(..., "/dev/uio0", ...);
+
+ f = fopen("/sys/.../pasid", "r");
+ fscanf(f, "%d", &pasid);
+
+ map[REG_PASID_OFFSET] = pasid;
diff --git a/Documentation/ABI/testing/sysfs-driver-uniwill-laptop b/Documentation/ABI/testing/sysfs-driver-uniwill-laptop
new file mode 100644
index 000000000000..eaeb659793d2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-uniwill-laptop
@@ -0,0 +1,53 @@
+What: /sys/bus/platform/devices/INOU0000:XX/fn_lock_toggle_enable
+Date: November 2025
+KernelVersion: 6.19
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ Allows userspace applications to enable/disable the FN lock feature
+ of the integrated keyboard by writing "1"/"0" into this file.
+
+ Reading this file returns the current enable status of the FN lock functionality.
+
+What: /sys/bus/platform/devices/INOU0000:XX/super_key_toggle_enable
+Date: November 2025
+KernelVersion: 6.19
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ Allows userspace applications to enable/disable the super key functionality
+ of the integrated keyboard by writing "1"/"0" into this file.
+
+ Reading this file returns the current enable status of the super key functionality.
+
+What: /sys/bus/platform/devices/INOU0000:XX/touchpad_toggle_enable
+Date: November 2025
+KernelVersion: 6.19
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ Allows userspace applications to enable/disable the touchpad toggle functionality
+ of the integrated touchpad by writing "1"/"0" into this file.
+
+ Reading this file returns the current enable status of the touchpad toggle
+ functionality.
+
+What: /sys/bus/platform/devices/INOU0000:XX/rainbow_animation
+Date: November 2025
+KernelVersion: 6.19
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ Forces the integrated lightbar to display a rainbow animation when the machine
+ is not suspended. Writing "1"/"0" into this file enables/disables this
+ functionality.
+
+ Reading this file returns the current status of the rainbow animation functionality.
+
+What: /sys/bus/platform/devices/INOU0000:XX/breathing_in_suspend
+Date: November 2025
+KernelVersion: 6.19
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ Causes the integrated lightbar to display a breathing animation when the machine
+ has been suspended and is running on AC power. Writing "1"/"0" into this file
+ enables/disables this functionality.
+
+ Reading this file returns the current status of the breathing animation
+ functionality.
diff --git a/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager b/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
new file mode 100644
index 000000000000..57b9b68a73ee
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-xilinx-tmr-manager
@@ -0,0 +1,16 @@
+What: /sys/devices/platform/amba_pl/<dev>/errcnt
+Date: Nov 2022
+Contact: appana.durga.kedareswara.rao@amd.com
+Description: This control file provides the fault detection count.
+ This file cannot be written.
+ Example:
+ # cat /sys/devices/platform/amba_pl/44a10000.tmr_manager/errcnt
+ 1
+
+What: /sys/devices/platform/amba_pl/<dev>/dis_block_break
+Date: Nov 2022
+Contact: appana.durga.kedareswara.rao@amd.com
+Description: Write any value to it, This control file enables the break signal.
+ This file is write only.
+ Example:
+ # echo <any value> > /sys/devices/platform/amba_pl/44a10000.tmr_manager/dis_block_break
diff --git a/Documentation/ABI/testing/sysfs-driver-zynqmp-fpga b/Documentation/ABI/testing/sysfs-driver-zynqmp-fpga
new file mode 100644
index 000000000000..8f93d27b6d91
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-zynqmp-fpga
@@ -0,0 +1,73 @@
+What: /sys/bus/platform/drivers/zynqmp_fpga_manager/firmware:zynqmp-firmware:pcap/status
+Date: February 2023
+KernelVersion: 6.4
+Contact: Nava kishore Manne <nava.kishore.manne@amd.com>
+Description: (RO) Read fpga status.
+ Read returns a hexadecimal value that tells the current status
+ of the FPGA device. Each bit position in the status value is
+ described Below(see ug570 chapter 9).
+ https://docs.xilinx.com/v/u/en-US/ug570-ultrascale-configuration
+
+ ====================== ==============================================
+ BIT(0) 0: No CRC error
+ 1: CRC error
+
+ BIT(1) 0: Decryptor security not set
+ 1: Decryptor security set
+
+ BIT(2) 0: MMCMs/PLLs are not locked
+ 1: MMCMs/PLLs are locked
+
+ BIT(3) 0: DCI not matched
+ 1: DCI matched
+
+ BIT(4) 0: Start-up sequence has not finished
+ 1: Start-up sequence has finished
+
+ BIT(5) 0: All I/Os are placed in High-Z state
+ 1: All I/Os behave as configured
+
+ BIT(6) 0: Flip-flops and block RAM are write disabled
+ 1: Flip-flops and block RAM are write enabled
+
+ BIT(7) 0: GHIGH_B_STATUS asserted
+ 1: GHIGH_B_STATUS deasserted
+
+ BIT(8) to BIT(10) Status of the mode pins
+
+ BIT(11) 0: Initialization has not finished
+ 1: Initialization finished
+
+ BIT(12) Value on INIT_B_PIN pin
+
+ BIT(13) 0: Signal not released
+ 1: Signal released
+
+ BIT(14) Value on DONE_PIN pin.
+
+ BIT(15) 0: No IDCODE_ERROR
+ 1: IDCODE_ERROR
+
+ BIT(16) 0: No SECURITY_ERROR
+ 1: SECURITY_ERROR
+
+ BIT(17) System Monitor over-temperature if set
+
+ BIT(18) to BIT(20) Start-up state machine (0 to 7)
+ Phase 0 = 000
+ Phase 1 = 001
+ Phase 2 = 011
+ Phase 3 = 010
+ Phase 4 = 110
+ Phase 5 = 111
+ Phase 6 = 101
+ Phase 7 = 100
+
+ BIT(25) to BIT(26) Indicates the detected bus width
+ 00 = x1
+ 01 = x8
+ 10 = x16
+ 11 = x32
+ ====================== ==============================================
+
+ The other bits are reserved.
diff --git a/Documentation/ABI/testing/sysfs-edac-ecs b/Documentation/ABI/testing/sysfs-edac-ecs
new file mode 100644
index 000000000000..87c885c4eb1a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-edac-ecs
@@ -0,0 +1,74 @@
+What: /sys/bus/edac/devices/<dev-name>/ecs_fruX
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ The sysfs EDAC bus devices /<dev-name>/ecs_fruX subdirectory
+ pertains to the memory media ECS (Error Check Scrub) control
+ feature, where <dev-name> directory corresponds to a device
+ registered with the EDAC device driver for the ECS feature.
+ /ecs_fruX belongs to the media FRUs (Field Replaceable Unit)
+ under the memory device.
+
+ The sysfs ECS attr nodes are only present if the parent
+ driver has implemented the corresponding attr callback
+ function and provided the necessary operations to the EDAC
+ device driver during registration.
+
+What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/log_entry_type
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The log entry type of how the DDR5 ECS log is reported.
+
+ - 0 - per DRAM.
+
+ - 1 - per memory media FRU.
+
+ - All other values are reserved.
+
+What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/mode
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The mode of how the DDR5 ECS counts the errors.
+ Error count is tracked based on two different modes
+ selected by DDR5 ECS Control Feature - Codeword mode and
+ Row Count mode. If the ECS is under Codeword mode, then
+ the error count increments each time a codeword with check
+ bit errors is detected. If the ECS is under Row Count mode,
+ then the error counter increments each time a row with
+ check bit errors is detected.
+
+ - 0 - ECS counts rows in the memory media that have ECC errors.
+
+ - 1 - ECS counts codewords with errors, specifically, it counts
+ the number of ECC-detected errors in the memory media.
+
+ - All other values are reserved.
+
+What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/reset
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (WO) ECS reset ECC counter.
+
+ - 1 - reset ECC counter to the default value.
+
+ - All other values are reserved.
+
+What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/threshold
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) DDR5 ECS threshold count per gigabits of memory cells.
+ The ECS error count is subject to the ECS Threshold count
+ per Gbit, which masks error counts less than the Threshold.
+
+ Supported values are 256, 1024 and 4096.
+
+ All other values are reserved.
diff --git a/Documentation/ABI/testing/sysfs-edac-memory-repair b/Documentation/ABI/testing/sysfs-edac-memory-repair
new file mode 100644
index 000000000000..0434a3b23ff3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-edac-memory-repair
@@ -0,0 +1,206 @@
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ The sysfs EDAC bus devices /<dev-name>/mem_repairX subdirectory
+ pertains to the memory media repair features control, such as
+ PPR (Post Package Repair), memory sparing etc, where <dev-name>
+ directory corresponds to a device registered with the EDAC
+ device driver for the memory repair features.
+
+ Post Package Repair is a maintenance operation requests the memory
+ device to perform a repair operation on its media. It is a memory
+ self-healing feature that fixes a failing memory location by
+ replacing it with a spare row in a DRAM device. For example, a
+ CXL memory device with DRAM components that support PPR features may
+ implement PPR maintenance operations. DRAM components may support
+ two types of PPR functions: hard PPR, for a permanent row repair, and
+ soft PPR, for a temporary row repair. Soft PPR may be much faster
+ than hard PPR, but the repair is lost with a power cycle.
+
+ The sysfs attributes nodes for a repair feature are only
+ present if the parent driver has implemented the corresponding
+ attr callback function and provided the necessary operations
+ to the EDAC device driver during registration.
+
+ In some states of system configuration (e.g. before address
+ decoders have been configured), memory devices (e.g. CXL)
+ may not have an active mapping in the main host address
+ physical address map. As such, the memory to repair must be
+ identified by a device specific physical addressing scheme
+ using a device physical address(DPA). The DPA and other control
+ attributes to use will be presented in related error records.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair_type
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RO) Memory repair type. For eg. post package repair,
+ memory sparing etc. Valid values are:
+
+ - ppr - Post package repair.
+
+ - cacheline-sparing
+
+ - row-sparing
+
+ - bank-sparing
+
+ - rank-sparing
+
+ - All other values are reserved.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/persist_mode
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) Get/Set the current persist repair mode set for a
+ repair function. Persist repair modes supported in the
+ device, based on a memory repair function, either is temporary,
+ which is lost with a power cycle or permanent. Valid values are:
+
+ - 0 - Soft memory repair (temporary repair).
+
+ - 1 - Hard memory repair (permanent repair).
+
+ - All other values are reserved.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair_safe_when_in_use
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RO) True if memory media is accessible and data is retained
+ during the memory repair operation.
+ The data may not be retained and memory requests may not be
+ correctly processed during a repair operation. In such case
+ repair operation can not be executed at runtime. The memory
+ must be taken offline.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/hpa
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) Host Physical Address (HPA) of the memory to repair.
+ The HPA to use will be provided in related error records.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/dpa
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) Device Physical Address (DPA) of the memory to repair.
+ The specific DPA to use will be provided in related error
+ records.
+
+ In some states of system configuration (e.g. before address
+ decoders have been configured), memory devices (e.g. CXL)
+ may not have an active mapping in the main host address
+ physical address map. As such, the memory to repair must be
+ identified by a device specific physical addressing scheme
+ using a DPA. The device physical address(DPA) to use will be
+ presented in related error records.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/nibble_mask
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) Read/Write Nibble mask of the memory to repair.
+ Nibble mask identifies one or more nibbles in error on the
+ memory bus that produced the error event. Nibble Mask bit 0
+ shall be set if nibble 0 on the memory bus produced the
+ event, etc. For example, CXL PPR and sparing, a nibble mask
+ bit set to 1 indicates the request to perform repair
+ operation in the specific device. All nibble mask bits set
+ to 1 indicates the request to perform the operation in all
+ devices. Eg. for CXL memory repair, the specific value of
+ nibble mask to use will be provided in related error records.
+ For more details, See nibble mask field in CXL spec ver 3.1,
+ section 8.2.9.7.1.2 Table 8-103 soft PPR and section
+ 8.2.9.7.1.3 Table 8-104 hard PPR, section 8.2.9.7.1.4
+ Table 8-105 memory sparing.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/min_hpa
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/max_hpa
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/min_dpa
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/max_dpa
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The supported range of memory address that is to be
+ repaired. The memory device may give the supported range of
+ attributes to use and it will depend on the memory device
+ and the portion of memory to repair.
+ The userspace may receive the specific value of attributes
+ to use for a repair operation from the memory device via
+ related error records and trace events, for eg. CXL DRAM
+ and CXL general media error records in CXL memory devices.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/bank_group
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/bank
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/rank
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/row
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/column
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/channel
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/sub_channel
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The control attributes for the memory to be repaired.
+ The specific value of attributes to use depends on the
+ portion of memory to repair and will be reported to the host
+ in related error records and be available to userspace
+ in trace events, such as CXL DRAM and CXL general media
+ error records of CXL memory devices.
+
+ When readng back these attributes, it returns the current
+ value of memory requested to be repaired.
+
+ bank_group - The bank group of the memory to repair.
+
+ bank - The bank number of the memory to repair.
+
+ rank - The rank of the memory to repair. Rank is defined as a
+ set of memory devices on a channel that together execute a
+ transaction.
+
+ row - The row number of the memory to repair.
+
+ column - The column number of the memory to repair.
+
+ channel - The channel of the memory to repair. Channel is
+ defined as an interface that can be independently accessed
+ for a transaction.
+
+ sub_channel - The subchannel of the memory to repair.
+
+ The requirement to set these attributes varies based on the
+ repair function. The attributes in sysfs are not present
+ unless required for a repair function.
+
+ For example, CXL spec ver 3.1, Section 8.2.9.7.1.2 Table 8-103
+ soft PPR and Section 8.2.9.7.1.3 Table 8-104 hard PPR operations,
+ these attributes are not required to set. CXL spec ver 3.1,
+ Section 8.2.9.7.1.4 Table 8-105 memory sparing, these attributes
+ are required to set based on memory sparing granularity.
+
+What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (WO) Issue the memory repair operation for the specified
+ memory repair attributes. The operation may fail if resources
+ are insufficient based on the requirements of the memory
+ device and repair function.
+
+ - 1 - Issue the repair operation.
+
+ - All other values are reserved.
diff --git a/Documentation/ABI/testing/sysfs-edac-scrub b/Documentation/ABI/testing/sysfs-edac-scrub
new file mode 100644
index 000000000000..ab6014743da5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-edac-scrub
@@ -0,0 +1,85 @@
+What: /sys/bus/edac/devices/<dev-name>/scrubX
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ The sysfs EDAC bus devices /<dev-name>/scrubX subdirectory
+ belongs to an instance of memory scrub control feature,
+ where <dev-name> directory corresponds to a device/memory
+ region registered with the EDAC device driver for the
+ scrub control feature.
+
+ The sysfs scrub attr nodes are only present if the parent
+ driver has implemented the corresponding attr callback
+ function and provided the necessary operations to the EDAC
+ device driver during registration.
+
+What: /sys/bus/edac/devices/<dev-name>/scrubX/addr
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The base address of the memory region to be scrubbed
+ for on-demand scrubbing. Setting address starts scrubbing.
+ The size must be set before that.
+
+ The readback addr value is non-zero if the requested
+ on-demand scrubbing is in progress, zero otherwise.
+
+What: /sys/bus/edac/devices/<dev-name>/scrubX/size
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The size of the memory region to be scrubbed
+ (on-demand scrubbing).
+
+What: /sys/bus/edac/devices/<dev-name>/scrubX/enable_background
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) Start/Stop background (patrol) scrubbing if supported.
+
+What: /sys/bus/edac/devices/<dev-name>/scrubX/min_cycle_duration
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RO) Supported minimum scrub cycle duration in seconds
+ by the memory scrubber.
+
+ Device-based scrub: returns the minimum scrub cycle
+ supported by the memory device.
+
+ Region-based scrub: returns the max of minimum scrub cycles
+ supported by individual memory devices that back the region.
+
+What: /sys/bus/edac/devices/<dev-name>/scrubX/max_cycle_duration
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RO) Supported maximum scrub cycle duration in seconds
+ by the memory scrubber.
+
+ Device-based scrub: returns the maximum scrub cycle supported
+ by the memory device.
+
+ Region-based scrub: returns the min of maximum scrub cycles
+ supported by individual memory devices that back the region.
+
+ If the memory device does not provide maximum scrub cycle
+ information, return the maximum supported value of the scrub
+ cycle field.
+
+What: /sys/bus/edac/devices/<dev-name>/scrubX/current_cycle_duration
+Date: March 2025
+KernelVersion: 6.15
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) The current scrub cycle duration in seconds and must be
+ within the supported range by the memory scrubber.
+
+ Scrub has an overhead when running and that may want to be
+ reduced by taking longer to do it.
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index 819939d858c9..72e7c9161ce7 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -84,7 +84,7 @@ Description:
hotplug events associated with the given class of
devices and will allow those devices to be ejected with
the help of the _EJ0 control method. Unsetting it
- effectively disables hotplug for the correspoinding
+ effectively disables hotplug for the corresponding
class of devices.
======== =======================================================
@@ -108,15 +108,15 @@ Description:
number of a "General Purpose Events" (GPE).
A GPE vectors to a specified handler in AML, which
- can do a anything the BIOS writer wants from
+ can do anything the BIOS writer wants from
OS context. GPE 0x12, for example, would vector
to a level or edge handler called _L12 or _E12.
The handler may do its business and return.
- Or the handler may send send a Notify event
+ Or the handler may send a Notify event
to a Linux device driver registered on an ACPI device,
such as a battery, or a processor.
- To figure out where all the SCI's are coming from,
+ To figure out where all the SCIs are coming from,
/sys/firmware/acpi/interrupts contains a file listing
every possible source, and the count of how many
times it has triggered::
@@ -248,3 +248,24 @@ Description:
# cat ff_pwr_btn
7 enabled
+What: /sys/firmware/acpi/memory_ranges/rangeX
+Date: February 2025
+Contact: Tony Luck <tony.luck@intel.com>
+Description:
+ On systems with the ACPI MRRM table reports the parameters for
+ each range.
+
+ base: Starting system physical address.
+
+ length: Length of this range in bytes.
+
+ node: NUMA node that this range belongs to. Negative numbers
+ indicate that the node number could not be determined (e.g
+ for an address range that is reserved for future hot add of
+ memory).
+
+ local_region_id: ID associated with access by agents
+ local to this range of addresses.
+
+ remote_region_id: ID associated with access by agents
+ non-local to this range of addresses.
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-entries b/Documentation/ABI/testing/sysfs-firmware-dmi-entries
index fe0289c87768..b6c23807b804 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi-entries
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi-entries
@@ -2,7 +2,7 @@ What: /sys/firmware/dmi/entries/
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
- Many machines' firmware (x86 and ia64) export DMI /
+ Many machines' firmware (x86 and arm64) export DMI /
SMBIOS tables to the operating system. Getting at this
information is often valuable to userland, especially in
cases where there are OEM extensions used.
diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi
index 5e4d0b27cdfe..927e362d4974 100644
--- a/Documentation/ABI/testing/sysfs-firmware-efi
+++ b/Documentation/ABI/testing/sysfs-firmware-efi
@@ -36,3 +36,10 @@ Description: Displays the content of the Runtime Configuration Interface
Table version 2 on Dell EMC PowerEdge systems in binary format
Users: It is used by Dell EMC OpenManage Server Administrator tool to
populate BIOS setup page.
+
+What: /sys/firmware/efi/ovmf_debug_log
+Date: July 2025
+Contact: Gerd Hoffmann <kraxel@redhat.com>, linux-efi@vger.kernel.org
+Description: Displays the content of the OVMF debug log buffer. The file is
+ only present in case the firmware supports logging to a memory
+ buffer.
diff --git a/Documentation/ABI/testing/sysfs-firmware-initrd b/Documentation/ABI/testing/sysfs-firmware-initrd
new file mode 100644
index 000000000000..20bf7cf77a19
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-initrd
@@ -0,0 +1,8 @@
+What: /sys/firmware/initrd
+Date: December 2023
+Contact: Alexander Graf <graf@amazon.com>
+Description:
+ When the kernel was booted with an initrd and the
+ "retain_initrd" option is set on the kernel command
+ line, /sys/firmware/initrd contains the contents of the
+ initrd that the kernel was booted with.
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-powercap b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
index c9b66ec4f165..d2d12ee89288 100644
--- a/Documentation/ABI/testing/sysfs-firmware-opal-powercap
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
@@ -1,6 +1,6 @@
What: /sys/firmware/opal/powercap
Date: August 2017
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Powercap directory for Powernv (P8, P9) servers
Each folder in this directory contains a
@@ -11,7 +11,7 @@ What: /sys/firmware/opal/powercap/system-powercap
/sys/firmware/opal/powercap/system-powercap/powercap-max
/sys/firmware/opal/powercap/system-powercap/powercap-current
Date: August 2017
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: System powercap directory and attributes applicable for
Powernv (P8, P9) servers
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-psr b/Documentation/ABI/testing/sysfs-firmware-opal-psr
index cc2ece70e365..1e55b56a0f89 100644
--- a/Documentation/ABI/testing/sysfs-firmware-opal-psr
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-psr
@@ -1,6 +1,6 @@
What: /sys/firmware/opal/psr
Date: August 2017
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Power-Shift-Ratio directory for Powernv P9 servers
Power-Shift-Ratio allows to provide hints the firmware
@@ -10,7 +10,7 @@ Description: Power-Shift-Ratio directory for Powernv P9 servers
What: /sys/firmware/opal/psr/cpu_to_gpu_X
Date: August 2017
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: PSR sysfs attributes for Powernv P9 servers
Power-Shift-Ratio between CPU and GPU for a given chip
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
index 3a2dfe542e8c..fcb1fb4795b6 100644
--- a/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
@@ -1,6 +1,6 @@
What: /sys/firmware/opal/sensor_groups
Date: August 2017
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Sensor groups directory for POWER9 powernv servers
Each folder in this directory contains a sensor group
@@ -11,7 +11,7 @@ Description: Sensor groups directory for POWER9 powernv servers
What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
Date: August 2017
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Sysfs file to clear the min-max of all the sensors
belonging to the group.
diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
index 141a6b371469..f5cefb81ac9d 100644
--- a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
+++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
@@ -1,6 +1,6 @@
What: /sys/firmware/papr/energy_scale_info
Date: February 2022
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Directory hosting a set of platform attributes like
energy/frequency on Linux running as a PAPR guest.
@@ -10,20 +10,20 @@ Description: Directory hosting a set of platform attributes like
What: /sys/firmware/papr/energy_scale_info/<id>
Date: February 2022
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Energy, frequency attributes directory for POWERVM servers
What: /sys/firmware/papr/energy_scale_info/<id>/desc
Date: February 2022
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: String description of the energy attribute of <id>
What: /sys/firmware/papr/energy_scale_info/<id>/value
Date: February 2022
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Numeric value of the energy attribute of <id>
What: /sys/firmware/papr/energy_scale_info/<id>/value_desc
Date: February 2022
-Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: String value of the energy attribute of <id>
diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
index 12ed843e1d3e..7fe9244b87bb 100644
--- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
+++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
@@ -102,12 +102,12 @@ Description:
conn_port
The conn_hub entry contains a value representing the unique
- oridinal value of the hub on the other end of the fabric
+ ordinal value of the hub on the other end of the fabric
cable plugged into the port. If the port is disconnected,
the value returned will be -1.
The conn_port entry contains a value representing the unique
- oridinal value of the port on the other end of the fabric cable
+ ordinal value of the port on the other end of the fabric cable
plugged into the port. If the port is disconnected, the value
returned will be -1.
diff --git a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm
index ea5e5b489bc7..26741cb84504 100644
--- a/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm
+++ b/Documentation/ABI/testing/sysfs-firmware-turris-mox-rwtm
@@ -12,15 +12,6 @@ Contact: Marek Behún <kabel@kernel.org>
Description: (Read) MAC addresses burned into eFuses of this Turris Mox board.
Format: %pM
-What: /sys/firmware/turris-mox-rwtm/pubkey
-Date: August 2019
-KernelVersion: 5.4
-Contact: Marek Behún <kabel@kernel.org>
-Description: (Read) ECDSA public key (in pubkey hex compressed form) computed
- as pair to the ECDSA private key burned into eFuses of this
- Turris Mox Board.
- Format: string
-
What: /sys/firmware/turris-mox-rwtm/ram_size
Date: August 2019
KernelVersion: 5.4
diff --git a/Documentation/ABI/testing/sysfs-fs-erofs b/Documentation/ABI/testing/sysfs-fs-erofs
index bb4681a01811..76d9808ed581 100644
--- a/Documentation/ABI/testing/sysfs-fs-erofs
+++ b/Documentation/ABI/testing/sysfs-fs-erofs
@@ -4,7 +4,8 @@ Contact: "Huang Jianan" <huangjianan@oppo.com>
Description: Shows all enabled kernel features.
Supported features:
zero_padding, compr_cfgs, big_pcluster, chunked_file,
- device_table, compr_head2, sb_chksum.
+ device_table, compr_head2, sb_chksum, ztailpacking,
+ dedupe, fragments, 48bit, metabox.
What: /sys/fs/erofs/<disk>/sync_decompress
Date: November 2021
@@ -15,3 +16,30 @@ Description: Control strategy of sync decompression:
readahead on atomic contexts only.
- 1 (force on): enable for readpage and readahead.
- 2 (force off): disable for all situations.
+
+What: /sys/fs/erofs/<disk>/drop_caches
+Date: November 2024
+Contact: "Guo Chunhai" <guochunhai@vivo.com>
+Description: Writing to this will drop compression-related caches,
+ currently used to drop in-memory pclusters and cached
+ compressed folios:
+
+ - 1 : invalidate cached compressed folios
+ - 2 : drop in-memory pclusters
+ - 3 : drop in-memory pclusters and cached compressed folios
+
+What: /sys/fs/erofs/accel
+Date: May 2025
+Contact: "Bo Liu" <liubo03@inspur.com>
+Description: Used to set or show hardware accelerators in effect
+ and multiple accelerators are separated by '\n'.
+ Supported accelerator(s): qat_deflate.
+ Disable all accelerators with an empty string (echo > accel).
+
+What: /sys/fs/erofs/<disk>/dir_ra_bytes
+Date: July 2025
+Contact: "Chao Yu" <chao@kernel.org>
+Description: Used to set or show readahead bytes during readdir(), by
+ default the value is 16384.
+
+ - 0: disable readahead.
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 083ac2d63eef..770470e0598b 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -49,16 +49,23 @@ Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description: Controls the in-place-update policy.
updates in f2fs. User can set:
- ==== =================
- 0x01 F2FS_IPU_FORCE
- 0x02 F2FS_IPU_SSR
- 0x04 F2FS_IPU_UTIL
- 0x08 F2FS_IPU_SSR_UTIL
- 0x10 F2FS_IPU_FSYNC
- 0x20 F2FS_IPU_ASYNC
- 0x40 F2FS_IPU_NOCACHE
- 0x80 F2FS_IPU_HONOR_OPU_WRITE
- ==== =================
+ ===== =============== ===================================================
+ value policy description
+ 0x00 DISABLE disable IPU(=default option in LFS mode)
+ 0x01 FORCE all the time
+ 0x02 SSR if SSR mode is activated
+ 0x04 UTIL if FS utilization is over threshold
+ 0x08 SSR_UTIL if SSR mode is activated and FS utilization is over
+ threshold
+ 0x10 FSYNC activated in fsync path only for high performance
+ flash storages. IPU will be triggered only if the
+ # of dirty pages over min_fsync_blocks.
+ (=default option)
+ 0x20 ASYNC do IPU given by asynchronous write requests
+ 0x40 NOCACHE disable IPU bio cache
+ 0x80 HONOR_OPU_WRITE use OPU write prior to IPU write if inode has
+ FI_OPU_WRITE flag
+ ===== =============== ===================================================
Refer segment.h for details.
@@ -95,16 +102,22 @@ What: /sys/fs/f2fs/<disk>/max_small_discards
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description: Controls the issue rate of discard commands that consist of small
- blocks less than 2MB. The candidates to be discarded are cached until
- checkpoint is triggered, and issued during the checkpoint.
- By default, it is disabled with 0.
+ blocks less than 2MB. The candidates to be discarded are cached during
+ checkpoint, and issued by issue_discard thread after checkpoint.
+ It is enabled by default.
+
+What: /sys/fs/f2fs/<disk>/max_ordered_discard
+Date: October 2022
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: Controls the maximum ordered discard, the unit size is one block(4KB).
+ Set it to 16 by default.
What: /sys/fs/f2fs/<disk>/max_discard_request
Date: December 2021
Contact: "Konstantin Vyshetsky" <vkon@google.com>
Description: Controls the number of discards a thread will issue at a time.
Higher number will allow the discard thread to finish its work
- faster, at the cost of higher latency for incomming I/O.
+ faster, at the cost of higher latency for incoming I/O.
What: /sys/fs/f2fs/<disk>/min_discard_issue_time
Date: December 2021
@@ -132,7 +145,8 @@ Contact: "Chao Yu" <yuchao0@huawei.com>
Description: Controls discard granularity of inner discard thread. Inner thread
will not issue discards with size that is smaller than granularity.
The unit size is one block(4KB), now only support configuring
- in range of [1, 512]. Default value is 4(=16KB).
+ in range of [1, 512]. Default value is 16.
+ For small devices, default value is 1.
What: /sys/fs/f2fs/<disk>/umount_discard_timeout
Date: January 2019
@@ -176,12 +190,6 @@ Description: Controls the memory footprint used by free nids and cached
nat entries. By default, 1 is set, which indicates
10 MB / 1 GB RAM.
-What: /sys/fs/f2fs/<disk>/batched_trim_sections
-Date: February 2015
-Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
-Description: Controls the trimming rate in batch mode.
- <deprecated>
-
What: /sys/fs/f2fs/<disk>/cp_interval
Date: October 2015
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
@@ -197,7 +205,7 @@ Description: Controls the idle timing of system, if there is no FS operation
What: /sys/fs/f2fs/<disk>/discard_idle_interval
Date: September 2018
Contact: "Chao Yu" <yuchao0@huawei.com>
-Contact: "Sahitya Tummala" <stummala@codeaurora.org>
+Contact: "Sahitya Tummala" <quic_stummala@quicinc.com>
Description: Controls the idle timing of discard thread given
this time interval.
Default is 5 secs.
@@ -205,7 +213,7 @@ Description: Controls the idle timing of discard thread given
What: /sys/fs/f2fs/<disk>/gc_idle_interval
Date: September 2018
Contact: "Chao Yu" <yuchao0@huawei.com>
-Contact: "Sahitya Tummala" <stummala@codeaurora.org>
+Contact: "Sahitya Tummala" <quic_stummala@quicinc.com>
Description: Controls the idle timing for gc path. Set to 5 seconds by default.
What: /sys/fs/f2fs/<disk>/iostat_enable
@@ -235,7 +243,7 @@ Description: Shows total written kbytes issued to disk.
What: /sys/fs/f2fs/<disk>/features
Date: July 2017
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
-Description: <deprecated: should use /sys/fs/f2fs/<disk>/feature_list/
+Description: <deprecated: should use /sys/fs/f2fs/<disk>/feature_list/>
Shows all enabled features in current device.
Supported features:
encryption, blkzoned, extra_attr, projquota, inode_checksum,
@@ -262,7 +270,7 @@ Description: Shows all enabled kernel features.
inode_checksum, flexible_inline_xattr, quota_ino,
inode_crtime, lost_found, verity, sb_checksum,
casefold, readonly, compression, test_dummy_encryption_v2,
- atomic_write, pin_file, encrypted_casefold.
+ atomic_write, pin_file, encrypted_casefold, linear_lookup.
What: /sys/fs/f2fs/<disk>/inject_rate
Date: May 2016
@@ -303,10 +311,13 @@ Description: Do background GC aggressively when set. Set to 0 by default.
GC approach and turns SSR mode on.
gc urgent low(2): lowers the bar of checking I/O idling in
order to process outstanding discard commands and GC a
- little bit aggressively. uses cost benefit GC approach.
+ little bit aggressively. always uses cost benefit GC approach,
+ and will override age-threshold GC approach if ATGC is enabled
+ at the same time.
gc urgent mid(3): does GC forcibly in a period of given
gc_urgent_sleep_time and executes a mid level of I/O idling check.
- uses cost benefit GC approach.
+ always uses cost benefit GC approach, and will override
+ age-threshold GC approach if ATGC is enabled at the same time.
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
Date: August 2017
@@ -323,10 +334,10 @@ Date: January 2018
Contact: Jaegeuk Kim <jaegeuk@kernel.org>
Description: This indicates how many GC can be failed for the pinned
file. If it exceeds this, F2FS doesn't guarantee its pinning
- state. 2048 trials is set by default.
+ state. 2048 trials is set by default, and 65535 as maximum.
What: /sys/fs/f2fs/<disk>/extension_list
-Date: Feburary 2018
+Date: February 2018
Contact: "Chao Yu" <yuchao0@huawei.com>
Description: Used to control configure extension list:
- Query: cat /sys/fs/f2fs/<disk>/extension_list
@@ -336,7 +347,7 @@ Description: Used to control configure extension list:
- [c] means add/del cold file extension
What: /sys/fs/f2fs/<disk>/unusable
-Date April 2019
+Date: April 2019
Contact: "Daniel Rosenberg" <drosen@google.com>
Description: If checkpoint=disable, it displays the number of blocks that
are unusable.
@@ -344,7 +355,7 @@ Description: If checkpoint=disable, it displays the number of blocks that
would be unusable if checkpoint=disable were to be set.
What: /sys/fs/f2fs/<disk>/encoding
-Date July 2019
+Date: July 2019
Contact: "Daniel Rosenberg" <drosen@google.com>
Description: Displays name and version of the encoding set for the filesystem.
If no encoding is set, displays (none)
@@ -466,6 +477,45 @@ Description: Show status of f2fs superblock in real time.
0x4000 SBI_IS_FREEZING freefs is in process
====== ===================== =================================
+What: /sys/fs/f2fs/<disk>/stat/cp_status
+Date: September 2022
+Contact: "Chao Yu" <chao.yu@oppo.com>
+Description: Show status of f2fs checkpoint in real time.
+
+ =============================== ==============================
+ cp flag value
+ CP_UMOUNT_FLAG 0x00000001
+ CP_ORPHAN_PRESENT_FLAG 0x00000002
+ CP_COMPACT_SUM_FLAG 0x00000004
+ CP_ERROR_FLAG 0x00000008
+ CP_FSCK_FLAG 0x00000010
+ CP_FASTBOOT_FLAG 0x00000020
+ CP_CRC_RECOVERY_FLAG 0x00000040
+ CP_NAT_BITS_FLAG 0x00000080
+ CP_TRIMMED_FLAG 0x00000100
+ CP_NOCRC_RECOVERY_FLAG 0x00000200
+ CP_LARGE_NAT_BITMAP_FLAG 0x00000400
+ CP_QUOTA_NEED_FSCK_FLAG 0x00000800
+ CP_DISABLED_FLAG 0x00001000
+ CP_DISABLED_QUICK_FLAG 0x00002000
+ CP_RESIZEFS_FLAG 0x00004000
+ =============================== ==============================
+
+What: /sys/fs/f2fs/<disk>/stat/issued_discard
+Date: December 2023
+Contact: "Zhiguo Niu" <zhiguo.niu@unisoc.com>
+Description: Shows the number of issued discard.
+
+What: /sys/fs/f2fs/<disk>/stat/queued_discard
+Date: December 2023
+Contact: "Zhiguo Niu" <zhiguo.niu@unisoc.com>
+Description: Shows the number of queued discard.
+
+What: /sys/fs/f2fs/<disk>/stat/undiscard_blks
+Date: December 2023
+Contact: "Zhiguo Niu" <zhiguo.niu@unisoc.com>
+Description: Shows the total number of undiscard blocks.
+
What: /sys/fs/f2fs/<disk>/ckpt_thread_ioprio
Date: January 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
@@ -532,6 +582,12 @@ Description: When ATGC is on, it controls age threshold to bypass GCing young
candidates whose age is not beyond the threshold, by default it was
initialized as 604800 seconds (equals to 7 days).
+What: /sys/fs/f2fs/<disk>/atgc_enabled
+Date: Feb 2024
+Contact: "Jinbao Liu" <liujinbao1@xiaomi.com>
+Description: It represents whether ATGC is on or off. The value is 1 which
+ indicates that ATGC is on, and 0 indicates that it is off.
+
What: /sys/fs/f2fs/<disk>/gc_reclaimed_segments
Date: July 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
@@ -568,10 +624,10 @@ Description: With "mode=fragment:block" mount options, we can scatter block allo
in the length of 1..<max_fragment_hole> by turns. This value can be set
between 1..512 and the default value is 4.
-What: /sys/fs/f2fs/<disk>/gc_urgent_high_remaining
-Date: December 2021
-Contact: "Daeho Jeong" <daehojeong@google.com>
-Description: You can set the trial count limit for GC urgent high mode with this value.
+What: /sys/fs/f2fs/<disk>/gc_remaining_trials
+Date: October 2022
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: You can set the trial count limit for GC urgent and idle mode with this value.
If GC thread gets to the limit, the mode will turn back to GC normal mode.
By default, the value is zero, which means there is no limit like before.
@@ -587,6 +643,12 @@ Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Shows the number of unusable blocks in a section which was defined by
the zone capacity reported by underlying zoned device.
+What: /sys/fs/f2fs/<disk>/max_open_zones
+Date: November 2025
+Contact: "Yongpeng Yang" <yangyongpeng@xiaomi.com>
+Description: Shows the max number of zones that F2FS can write concurrently when a zoned
+ device is mounted.
+
What: /sys/fs/f2fs/<disk>/current_atomic_write
Date: July 2022
Contact: "Daeho Jeong" <daehojeong@google.com>
@@ -610,3 +672,270 @@ Date: July 2022
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the accumulated total revoked atomic write block count after boot.
If you write "0" here, you can initialize to "0".
+
+What: /sys/fs/f2fs/<disk>/gc_mode
+Date: October 2022
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: Show the current gc_mode as a string.
+ This is a read-only entry.
+
+What: /sys/fs/f2fs/<disk>/discard_urgent_util
+Date: November 2022
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: When space utilization exceeds this, do background DISCARD aggressively.
+ Does DISCARD forcibly in a period of given min_discard_issue_time when the number
+ of discards is not 0 and set discard granularity to 1.
+ Default: 80
+
+What: /sys/fs/f2fs/<disk>/hot_data_age_threshold
+Date: November 2022
+Contact: "Ping Xiong" <xiongping1@xiaomi.com>
+Description: When DATA SEPARATION is on, it controls the age threshold to indicate
+ the data blocks as hot. By default it was initialized as 262144 blocks
+ (equals to 1GB).
+
+What: /sys/fs/f2fs/<disk>/warm_data_age_threshold
+Date: November 2022
+Contact: "Ping Xiong" <xiongping1@xiaomi.com>
+Description: When DATA SEPARATION is on, it controls the age threshold to indicate
+ the data blocks as warm. By default it was initialized as 2621440 blocks
+ (equals to 10GB).
+
+What: /sys/fs/f2fs/<disk>/fault_rate
+Date: May 2016
+Contact: "Sheng Yong" <shengyong@oppo.com>
+Contact: "Chao Yu" <chao@kernel.org>
+Description: Enable fault injection in all supported types with
+ specified injection rate.
+
+What: /sys/fs/f2fs/<disk>/fault_type
+Date: May 2016
+Contact: "Sheng Yong" <shengyong@oppo.com>
+Contact: "Chao Yu" <chao@kernel.org>
+Description: Support configuring fault injection type, should be
+ enabled with fault_injection option, fault type value
+ is shown below, it supports single or combined type.
+
+ =========================== ==========
+ Type_Name Type_Value
+ =========================== ==========
+ FAULT_KMALLOC 0x00000001
+ FAULT_KVMALLOC 0x00000002
+ FAULT_PAGE_ALLOC 0x00000004
+ FAULT_PAGE_GET 0x00000008
+ FAULT_ALLOC_BIO 0x00000010 (obsolete)
+ FAULT_ALLOC_NID 0x00000020
+ FAULT_ORPHAN 0x00000040
+ FAULT_BLOCK 0x00000080
+ FAULT_DIR_DEPTH 0x00000100
+ FAULT_EVICT_INODE 0x00000200
+ FAULT_TRUNCATE 0x00000400
+ FAULT_READ_IO 0x00000800
+ FAULT_CHECKPOINT 0x00001000
+ FAULT_DISCARD 0x00002000
+ FAULT_WRITE_IO 0x00004000
+ FAULT_SLAB_ALLOC 0x00008000
+ FAULT_DQUOT_INIT 0x00010000
+ FAULT_LOCK_OP 0x00020000
+ FAULT_BLKADDR_VALIDITY 0x00040000
+ FAULT_BLKADDR_CONSISTENCE 0x00080000
+ FAULT_NO_SEGMENT 0x00100000
+ FAULT_INCONSISTENT_FOOTER 0x00200000
+ FAULT_TIMEOUT 0x00400000 (1000ms)
+ FAULT_VMALLOC 0x00800000
+ =========================== ==========
+
+What: /sys/fs/f2fs/<disk>/discard_io_aware_gran
+Date: January 2023
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: Controls background discard granularity of inner discard thread
+ when is not in idle. Inner thread will not issue discards with size that
+ is smaller than granularity. The unit size is one block(4KB), now only
+ support configuring in range of [0, 512].
+ Default: 512
+
+What: /sys/fs/f2fs/<disk>/last_age_weight
+Date: January 2023
+Contact: "Ping Xiong" <xiongping1@xiaomi.com>
+Description: When DATA SEPARATION is on, it controls the weight of last data block age.
+
+What: /sys/fs/f2fs/<disk>/compress_watermark
+Date: February 2023
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: When compress cache is on, it controls free memory watermark
+ in order to limit caching compress page. If free memory is lower
+ than watermark, then deny caching compress page. The value should be in
+ range of (0, 100], by default it was initialized as 20(%).
+
+What: /sys/fs/f2fs/<disk>/compress_percent
+Date: February 2023
+Contact: "Yangtao Li" <frank.li@vivo.com>
+Description: When compress cache is on, it controls cached page
+ percent(compress pages / free_ram) in order to limit caching compress page.
+ If cached page percent exceed threshold, then deny caching compress page.
+ The value should be in range of (0, 100], by default it was initialized
+ as 20(%).
+
+What: /sys/fs/f2fs/<disk>/discard_io_aware
+Date: November 2023
+Contact: "Chao Yu" <chao@kernel.org>
+Description: It controls to enable/disable IO aware feature for background discard.
+ By default, the value is 1 which indicates IO aware is on.
+
+What: /sys/fs/f2fs/<disk>/blkzone_alloc_policy
+Date: July 2024
+Contact: "Yuanhong Liao" <liaoyuanhong@vivo.com>
+Description: The zone UFS we are currently using consists of two parts:
+ conventional zones and sequential zones. It can be used to control which part
+ to prioritize for writes, with a default value of 0.
+
+ ======================== =========================================
+ value description
+ blkzone_alloc_policy = 0 Prioritize writing to sequential zones
+ blkzone_alloc_policy = 1 Only allow writing to sequential zones
+ blkzone_alloc_policy = 2 Prioritize writing to conventional zones
+ ======================== =========================================
+
+What: /sys/fs/f2fs/<disk>/migration_window_granularity
+Date: September 2024
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: Controls migration window granularity of garbage collection on large
+ section. it can control the scanning window granularity for GC migration
+ in a unit of segment, while migration_granularity controls the number
+ of segments which can be migrated at the same turn.
+
+What: /sys/fs/f2fs/<disk>/reserved_segments
+Date: September 2024
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: In order to fine tune GC behavior, we can control the number of
+ reserved segments.
+
+What: /sys/fs/f2fs/<disk>/gc_no_zoned_gc_percent
+Date: September 2024
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: If the percentage of free sections over total sections is above this
+ number, F2FS do not garbage collection for zoned devices through the
+ background GC thread. the default number is "60".
+
+What: /sys/fs/f2fs/<disk>/gc_boost_zoned_gc_percent
+Date: September 2024
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: If the percentage of free sections over total sections is under this
+ number, F2FS boosts garbage collection for zoned devices through the
+ background GC thread. the default number is "25".
+
+What: /sys/fs/f2fs/<disk>/gc_valid_thresh_ratio
+Date: September 2024
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: It controls the valid block ratio threshold not to trigger excessive GC
+ for zoned devices. The initial value of it is 95(%). F2FS will stop the
+ background GC thread from initiating GC for sections having valid blocks
+ exceeding the ratio.
+
+What: /sys/fs/f2fs/<disk>/max_read_extent_count
+Date: November 2024
+Contact: "Chao Yu" <chao@kernel.org>
+Description: It controls max read extent count for per-inode, the value of threshold
+ is 10240 by default.
+
+What: /sys/fs/f2fs/tuning/reclaim_caches_kb
+Date: February 2025
+Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
+Description: It reclaims the given KBs of file-backed pages registered by
+ ioctl(F2FS_IOC_DONATE_RANGE).
+ For example, writing N tries to drop N KBs spaces in LRU.
+
+What: /sys/fs/f2fs/<disk>/carve_out
+Date: March 2025
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: For several zoned storage devices, vendors will provide extra space which
+ was used for device level GC than specs and F2FS can use this space for
+ filesystem level GC. To do that, we can reserve the space using
+ reserved_blocks. However, it is not enough, since this extra space should
+ not be shown to users. So, with this new sysfs node, we can hide the space
+ by subtracting reserved_blocks from total bytes.
+
+What: /sys/fs/f2fs/<disk>/encoding_flags
+Date: April 2025
+Contact: "Chao Yu" <chao@kernel.org>
+Description: This is a read-only entry to show the value of sb.s_encoding_flags, the
+ value is hexadecimal.
+
+ ============================ ==========
+ Flag_Name Flag_Value
+ ============================ ==========
+ SB_ENC_STRICT_MODE_FL 0x00000001
+ SB_ENC_NO_COMPAT_FALLBACK_FL 0x00000002
+ ============================ ==========
+
+What: /sys/fs/f2fs/<disk>/reserved_pin_section
+Date: June 2025
+Contact: "Chao Yu" <chao@kernel.org>
+Description: This threshold is used to control triggering garbage collection while
+ fallocating on pinned file, so, it can guarantee there is enough free
+ reserved section before preallocating on pinned file.
+ By default, the value is ovp_sections, especially, for zoned ufs, the
+ value is 1.
+
+What: /sys/fs/f2fs/<disk>/gc_boost_gc_multiple
+Date: June 2025
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: Set a multiplier for the background GC migration window when F2FS GC is
+ boosted. The range should be from 1 to the segment count in a section.
+ Default: 5
+
+What: /sys/fs/f2fs/<disk>/gc_boost_gc_greedy
+Date: June 2025
+Contact: "Daeho Jeong" <daehojeong@google.com>
+Description: Control GC algorithm for boost GC. 0: cost benefit, 1: greedy
+ Default: 1
+
+What: /sys/fs/f2fs/<disk>/effective_lookup_mode
+Date: August 2025
+Contact: "Daniel Lee" <chullee@google.com>
+Description:
+ This is a read-only entry to show the effective directory lookup mode
+ F2FS is currently using for casefolded directories.
+ This considers both the "lookup_mode" mount option and the on-disk
+ encoding flag, SB_ENC_NO_COMPAT_FALLBACK_FL.
+
+ Possible values are:
+ - "perf": Hash-only lookup.
+ - "compat": Hash-based lookup with a linear search fallback enabled
+ - "auto:perf": lookup_mode is auto and fallback is disabled on-disk
+ - "auto:compat": lookup_mode is auto and fallback is enabled on-disk
+
+What: /sys/fs/f2fs/<disk>/bggc_io_aware
+Date: August 2025
+Contact: "Liao Yuanhong" <liaoyuanhong@vivo.com>
+Description: Used to adjust the BG_GC priority when pending IO, with a default value
+ of 0. Specifically, for ZUFS, the default value is 1.
+
+ ================== ======================================================
+ value description
+ bggc_io_aware = 0 skip background GC if there is any kind of pending IO
+ bggc_io_aware = 1 skip background GC if there is pending read IO
+ bggc_io_aware = 2 don't aware IO for background GC
+ ================== ======================================================
+
+What: /sys/fs/f2fs/<disk>/allocate_section_hint
+Date: August 2025
+Contact: "Liao Yuanhong" <liaoyuanhong@vivo.com>
+Description: Indicates the hint section between the first device and others in multi-devices
+ setup. It defaults to the end of the first device in sections. For a single storage
+ device, it defaults to the total number of sections. It can be manually set to match
+ scenarios where multi-devices are mapped to the same dm device.
+
+What: /sys/fs/f2fs/<disk>/allocate_section_policy
+Date: August 2025
+Contact: "Liao Yuanhong" <liaoyuanhong@vivo.com>
+Description: Controls write priority in multi-devices setups. A value of 0 means normal writing.
+ A value of 1 prioritizes writing to devices before the allocate_section_hint. A value of 2
+ prioritizes writing to devices after the allocate_section_hint. The default is 0.
+
+ =========================== ==========================================================
+ value description
+ allocate_section_policy = 0 Normal writing
+ allocate_section_policy = 1 Prioritize writing to section before allocate_section_hint
+ allocate_section_policy = 2 Prioritize writing to section after allocate_section_hint
+ =========================== ==========================================================
diff --git a/Documentation/ABI/testing/sysfs-fs-virtiofs b/Documentation/ABI/testing/sysfs-fs-virtiofs
new file mode 100644
index 000000000000..4839dbce997e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-fs-virtiofs
@@ -0,0 +1,11 @@
+What: /sys/fs/virtiofs/<n>/tag
+Date: Feb 2024
+Contact: virtio-fs@lists.linux.dev
+Description:
+ [RO] The mount "tag" that can be used to mount this filesystem.
+
+What: /sys/fs/virtiofs/<n>/device
+Date: Feb 2024
+Contact: virtio-fs@lists.linux.dev
+Description:
+ Symlink to the virtio device that exports this filesystem.
diff --git a/Documentation/ABI/testing/sysfs-fs-xfs b/Documentation/ABI/testing/sysfs-fs-xfs
index f704925f6fe9..7da4de948b46 100644
--- a/Documentation/ABI/testing/sysfs-fs-xfs
+++ b/Documentation/ABI/testing/sysfs-fs-xfs
@@ -1,7 +1,7 @@
What: /sys/fs/xfs/<disk>/log/log_head_lsn
Date: July 2014
KernelVersion: 3.17
-Contact: xfs@oss.sgi.com
+Contact: linux-xfs@vger.kernel.org
Description:
The log sequence number (LSN) of the current head of the
log. The LSN is exported in "cycle:basic block" format.
@@ -10,30 +10,28 @@ Users: xfstests
What: /sys/fs/xfs/<disk>/log/log_tail_lsn
Date: July 2014
KernelVersion: 3.17
-Contact: xfs@oss.sgi.com
+Contact: linux-xfs@vger.kernel.org
Description:
The log sequence number (LSN) of the current tail of the
log. The LSN is exported in "cycle:basic block" format.
-What: /sys/fs/xfs/<disk>/log/reserve_grant_head
-Date: July 2014
-KernelVersion: 3.17
-Contact: xfs@oss.sgi.com
+What: /sys/fs/xfs/<disk>/log/reserve_grant_head_bytes
+Date: June 2024
+KernelVersion: 6.11
+Contact: linux-xfs@vger.kernel.org
Description:
The current state of the log reserve grant head. It
represents the total log reservation of all currently
- outstanding transactions. The grant head is exported in
- "cycle:bytes" format.
+ outstanding transactions in bytes.
Users: xfstests
-What: /sys/fs/xfs/<disk>/log/write_grant_head
-Date: July 2014
-KernelVersion: 3.17
-Contact: xfs@oss.sgi.com
+What: /sys/fs/xfs/<disk>/log/write_grant_head_bytes
+Date: June 2024
+KernelVersion: 6.11
+Contact: linux-xfs@vger.kernel.org
Description:
The current state of the log write grant head. It
represents the total log reservation of all currently
outstanding transactions, including regrants due to
- rolling transactions. The grant head is exported in
- "cycle:bytes" format.
+ rolling transactions in bytes.
Users: xfstests
diff --git a/Documentation/ABI/testing/sysfs-kernel-address_bits b/Documentation/ABI/testing/sysfs-kernel-address_bits
new file mode 100644
index 000000000000..3b72e48086aa
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-address_bits
@@ -0,0 +1,10 @@
+What: /sys/kernel/address_bits
+Date: May 2023
+KernelVersion: 6.3
+Contact: Thomas Weißschuh <linux@weissschuh.net>
+Description:
+ The address size of the running kernel in bits.
+
+ Access: Read
+
+Users: util-linux
diff --git a/Documentation/ABI/testing/sysfs-kernel-cpu_byteorder b/Documentation/ABI/testing/sysfs-kernel-cpu_byteorder
new file mode 100644
index 000000000000..f0e6ac1b5356
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-cpu_byteorder
@@ -0,0 +1,12 @@
+What: /sys/kernel/cpu_byteorder
+Date: February 2023
+KernelVersion: 6.2
+Contact: Thomas Weißschuh <linux@weissschuh.net>
+Description:
+ The endianness of the running kernel.
+
+ Access: Read
+
+ Valid values:
+ "little", "big"
+Users: util-linux
diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump b/Documentation/ABI/testing/sysfs-kernel-fadump
index 8f7a64a81783..b64b7622e6fc 100644
--- a/Documentation/ABI/testing/sysfs-kernel-fadump
+++ b/Documentation/ABI/testing/sysfs-kernel-fadump
@@ -38,3 +38,22 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Provide information about the amount of memory reserved by
FADump to save the crash dump in bytes.
+
+What: /sys/kernel/fadump/hotplug_ready
+Date: Apr 2024
+Contact: linuxppc-dev@lists.ozlabs.org
+Description: read only
+ Kdump udev rule re-registers fadump on memory add/remove events,
+ primarily to update the elfcorehdr. This sysfs indicates the
+ kdump udev rule that fadump re-registration is not required on
+ memory add/remove events because elfcorehdr is now prepared in
+ the second/fadump kernel.
+User: kexec-tools
+
+What: /sys/kernel/fadump/bootargs_append
+Date: May 2024
+Contact: linuxppc-dev@lists.ozlabs.org
+Description: read/write
+ This is a special sysfs file available to setup additional
+ parameters to be passed to capture kernel. For HASH MMU it
+ is exported only if RMA size higher than 768MB.
diff --git a/Documentation/ABI/testing/sysfs-kernel-hardlockup_count b/Documentation/ABI/testing/sysfs-kernel-hardlockup_count
new file mode 100644
index 000000000000..dfdd4078b077
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-hardlockup_count
@@ -0,0 +1,7 @@
+What: /sys/kernel/hardlockup_count
+Date: May 2025
+KernelVersion: 6.16
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ Shows how many times the system has detected a hard lockup since last boot.
+ Available only if CONFIG_HARDLOCKUP_DETECTOR is enabled.
diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups
index b15af6a5bc08..a42d4383d999 100644
--- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups
+++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups
@@ -53,7 +53,6 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
The default domain type of a group may be modified only when
- - The group has only one device.
- The device in the group is not bound to any device driver.
So, the users must unbind the appropriate driver before
changing the default domain type.
diff --git a/Documentation/ABI/testing/sysfs-kernel-kexec-kdump b/Documentation/ABI/testing/sysfs-kernel-kexec-kdump
new file mode 100644
index 000000000000..f59051b5d96d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-kexec-kdump
@@ -0,0 +1,61 @@
+What: /sys/kernel/kexec/*
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description:
+ The /sys/kernel/kexec/* directory contains sysfs files
+ that provide information about the configuration status
+ of kexec and kdump.
+
+What: /sys/kernel/kexec/loaded
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description: read only
+ Indicates whether a new kernel image has been loaded
+ into memory using the kexec system call. It shows 1 if
+ a kexec image is present and ready to boot, or 0 if none
+ is loaded.
+User: kexec tools, kdump service
+
+What: /sys/kernel/kexec/crash_loaded
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description: read only
+ Indicates whether a crash (kdump) kernel is currently
+ loaded into memory. It shows 1 if a crash kernel has been
+ successfully loaded for panic handling, or 0 if no crash
+ kernel is present.
+User: Kexec tools, Kdump service
+
+What: /sys/kernel/kexec/crash_size
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description: read/write
+ Shows the amount of memory reserved for loading the crash
+ (kdump) kernel. It reports the size, in bytes, of the
+ crash kernel area defined by the crashkernel= parameter.
+ This interface also allows reducing the crashkernel
+ reservation by writing a smaller value, and the reclaimed
+ space is added back to the system RAM.
+User: Kdump service
+
+What: /sys/kernel/kexec/crash_elfcorehdr_size
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description: read only
+ Indicates the preferred size of the memory buffer for the
+ ELF core header used by the crash (kdump) kernel. It defines
+ how much space is needed to hold metadata about the crashed
+ system, including CPU and memory information. This information
+ is used by the user space utility kexec to support updating the
+ in-kernel kdump image during hotplug operations.
+User: Kexec tools
+
+What: /sys/kernel/kexec/crash_cma_ranges
+Date: Nov 2025
+Contact: kexec@lists.infradead.org
+Description: read only
+ Provides information about the memory ranges reserved from
+ the Contiguous Memory Allocator (CMA) area that are allocated
+ to the crash (kdump) kernel. It lists the start and end physical
+ addresses of CMA regions assigned for crashkernel use.
+User: kdump service
diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch b/Documentation/ABI/testing/sysfs-kernel-livepatch
index bea7bd5a1d5f..3c3f36b32b57 100644
--- a/Documentation/ABI/testing/sysfs-kernel-livepatch
+++ b/Documentation/ABI/testing/sysfs-kernel-livepatch
@@ -47,6 +47,23 @@ Description:
disabled when the feature is used. See
Documentation/livepatch/livepatch.rst for more information.
+What: /sys/kernel/livepatch/<patch>/replace
+Date: Jun 2024
+KernelVersion: 6.11.0
+Contact: live-patching@vger.kernel.org
+Description:
+ An attribute which indicates whether the patch supports
+ atomic-replace.
+
+What: /sys/kernel/livepatch/<patch>/stack_order
+Date: Jan 2025
+KernelVersion: 6.14.0
+Description:
+ This attribute specifies the sequence in which live patch modules
+ are applied to the system. If multiple live patches modify the same
+ function, the implementation with the biggest 'stack_order' number
+ is used, unless a transition is currently in progress.
+
What: /sys/kernel/livepatch/<patch>/<object>
Date: Nov 2014
KernelVersion: 3.19.0
@@ -55,6 +72,14 @@ Description:
The object directory contains subdirectories for each function
that is patched within the object.
+What: /sys/kernel/livepatch/<patch>/<object>/patched
+Date: August 2022
+KernelVersion: 6.1.0
+Contact: live-patching@vger.kernel.org
+Description:
+ An attribute which indicates whether the object is currently
+ patched.
+
What: /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
Date: Nov 2014
KernelVersion: 3.19.0
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cma b/Documentation/ABI/testing/sysfs-kernel-mm-cma
index 02b2bb60c296..aaf2a5d8b13b 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-cma
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-cma
@@ -23,3 +23,22 @@ Date: Feb 2021
Contact: Minchan Kim <minchan@kernel.org>
Description:
the number of pages CMA API failed to allocate
+
+What: /sys/kernel/mm/cma/<cma-heap-name>/release_pages_success
+Date: Feb 2024
+Contact: Anshuman Khandual <anshuman.khandual@arm.com>
+Description:
+ the number of pages CMA API succeeded to release
+
+What: /sys/kernel/mm/cma/<cma-heap-name>/total_pages
+Date: Jun 2024
+Contact: Frank van der Linden <fvdl@google.com>
+Description:
+ The size of the CMA area in pages.
+
+What: /sys/kernel/mm/cma/<cma-heap-name>/available_pages
+Date: Jun 2024
+Contact: Frank van der Linden <fvdl@google.com>
+Description:
+ The number of pages in the CMA area that are still
+ available for CMA allocation.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon
index 08b9df323560..4fb8b7a6d625 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-damon
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon
@@ -25,8 +25,18 @@ Description: Writing 'on' or 'off' to this file makes the kdamond starts or
stops, respectively. Reading the file returns the keywords
based on the current status. Writing 'commit' to this file
makes the kdamond reads the user inputs in the sysfs files
- except 'state' again. Writing 'update_schemes_stats' to the
- file updates contents of schemes stats files of the kdamond.
+ except 'state' again. Writing 'commit_schemes_quota_goals' to
+ this file makes the kdamond reads the quota goal files again.
+ Writing 'update_schemes_stats' to the file updates contents of
+ schemes stats files of the kdamond. Writing
+ 'update_schemes_tried_regions' to the file updates contents of
+ 'tried_regions' directory of every scheme directory of this
+ kdamond. Writing 'update_schemes_tried_bytes' to the file
+ updates only '.../tried_regions/total_bytes' files of this
+ kdamond. Writing 'clear_schemes_tried_regions' to the file
+ removes contents of the 'tried_regions' directory. Writing
+ 'update_schemes_effective_quotas' to the file updates
+ '.../quotas/effective_bytes' files of this kdamond.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid
Date: Mar 2022
@@ -34,6 +44,13 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Reading this file returns the pid of the kdamond if it is
running.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/refresh_ms
+Date: Jul 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a value to this file sets the time interval for
+ automatic DAMON status file contents update. Writing '0'
+ disables the update. Reading this file returns the value.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/nr_contexts
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -60,6 +77,13 @@ Description: Writing a keyword for a monitoring operations set ('vaddr' for
Note that only the operations sets that listed in
'avail_operations' file are valid inputs.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/addr_unit
+Date: Aug 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing an integer to this file sets the 'address unit'
+ parameter of the given operations set of the context. Reading
+ the file returns the last-written 'address unit' value.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -81,6 +105,36 @@ Description: Writing a value to this file sets the update interval of the
DAMON context in microseconds as the value. Reading this file
returns the value.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/access_bp
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a value to this file sets the monitoring intervals
+ auto-tuning target DAMON-observed access events ratio within
+ the given time interval (aggrs in same directory), in bp
+ (1/10,000). Reading this file returns the value.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/aggrs
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a value to this file sets the time interval to achieve
+ the monitoring intervals auto-tuning target DAMON-observed
+ access events ratio (access_bp in same directory) within.
+ Reading this file returns the value.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/min_sample_us
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a value to this file sets the minimum value of
+ auto-tuned sampling interval in microseconds. Reading this
+ file returns the value.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/max_sample_us
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a value to this file sets the maximum value of
+ auto-tuned sampling interval in microseconds. Reading this
+ file returns the value.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/nr_regions/min
WDate: Mar 2022
@@ -110,6 +164,13 @@ Description: Writing to and reading from this file sets and gets the pid of
the target process if the context is for virtual address spaces
monitoring, respectively.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/obsolete_target
+Date: Oct 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the
+ obsoleteness of the matching parameters commit destination
+ target.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/nr_regions
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -145,10 +206,23 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the action
of the scheme.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/target_nid
+Date: Jun 2024
+Contact: SeongJae Park <sj@kernel.org>
+Description: Action's target NUMA node id. Supported by only relevant
+ actions.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/apply_interval_us
+Date: Sep 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a value to this file sets the action apply interval of
+ the scheme in microseconds. Reading this file returns the
+ value.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
-Description: Writing to and reading from this file sets and gets the mimimum
+Description: Writing to and reading from this file sets and gets the minimum
size of the scheme's target regions in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/max
@@ -193,12 +267,55 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the size
quota of the scheme in bytes.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/effective_bytes
+Date: Feb 2024
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading from this file gets the effective size quota of the
+ scheme in bytes, which adjusted for the time quota and goals.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/reset_interval_ms
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the quotas
charge reset interval of the scheme in milliseconds.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/nr_goals
+Date: Nov 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a number 'N' to this file creates the number of
+ directories for setting automatic tuning of the scheme's
+ aggressiveness named '0' to 'N-1' under the goals/ directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/target_metric
+Date: Feb 2024
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the quota
+ auto-tuning goal metric.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/target_value
+Date: Nov 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the target
+ value of the goal metric.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/current_value
+Date: Nov 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the current
+ value of the goal metric.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/nid
+Date: Apr 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the nid
+ parameter of the goal.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/path
+Date: Oct 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the path
+ parameter of the goal.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/sz_permil
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -254,6 +371,115 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the low
watermark of the scheme in permil.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/nr_filters
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a number 'N' to this file creates the number of
+ directories for setting filters of the scheme named '0' to
+ 'N-1' under the filters/ directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/type
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the type of
+ the memory of the interest. 'anon' for anonymous pages,
+ 'memcg' for specific memory cgroup, 'young' for young pages,
+ 'addr' for address range (an open-ended interval), or 'target'
+ for DAMON monitoring target can be written and read.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/memcg_path
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'memcg' is written to the 'type' file, writing to and
+ reading from this file sets and gets the path to the memory
+ cgroup of the interest.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_start
+Date: Jul 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'addr' is written to the 'type' file, writing to or reading
+ from this file sets or gets the start address of the address
+ range for the filter.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_end
+Date: Jul 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'addr' is written to the 'type' file, writing to or reading
+ from this file sets or gets the end address of the address
+ range for the filter.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/min
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'hugepage_size' is written to the 'type' file, writing to
+ or reading from this file sets or gets the minimum size of the
+ hugepage for the filter.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/max
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'hugepage_size' is written to the 'type' file, writing to
+ or reading from this file sets or gets the maximum size of the
+ hugepage for the filter.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/target_idx
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: If 'target' is written to the 'type' file, writing to or
+ reading from this file sets or gets the index of the DAMON
+ monitoring target of the interest.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/matching
+Date: Dec 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing 'Y' or 'N' to this file sets whether the filter is for
+ the memory of the 'type', or all except the 'type'.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/allow
+Date: Jan 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing 'Y' or 'N' to this file sets whether to allow or reject
+ applying the scheme's action to the memory that satisfies the
+ 'type' and the 'matching' of the directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Directory for DAMON core layer-handled DAMOS filters. Files
+ under this directory works same to those of
+ /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters
+ directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/ops_filters
+Date: Feb 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Directory for DAMON operations set layer-handled DAMOS filters.
+ Files under this directory works same to those of
+ /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters
+ directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/nr_dests
+Date: Jul 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing a number 'N' to this file creates the number of
+ directories for setting action destinations of the scheme named
+ '0' to 'N-1' under the dests/ directory.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/<D>/id
+Date: Jul 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the id of
+ the DAMOS action destination. For DAMOS_MIGRATE_{HOT,COLD}
+ actions, the destination node's node id can be written and
+ read.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/<D>/weight
+Date: Jul 2025
+Contact: SeongJae Park <sj@kernel.org>
+Description: Writing to and reading from this file sets and gets the weight
+ of the DAMOS action destination to select as the destination of
+ each action among the destinations.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_tried
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -278,8 +504,56 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Reading this file returns the total size of regions that the
action of the scheme has successfully applied in bytes.
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_ops_filter_passed
+Date: Dec 2024
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the total size of memory that passed
+ DAMON operations layer-handled filters of the scheme in bytes.
+
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/qt_exceeds
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Reading this file returns the number of the exceed events of
the scheme's quotas.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/total_bytes
+Date: Jul 2023
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the total amount of memory that
+ corresponding DAMON-based Operation Scheme's action has tried
+ to be applied.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/start
+Date: Oct 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the start address of a memory region
+ that corresponding DAMON-based Operation Scheme's action has
+ tried to be applied.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/end
+Date: Oct 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the end address of a memory region
+ that corresponding DAMON-based Operation Scheme's action has
+ tried to be applied.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/nr_accesses
+Date: Oct 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the 'nr_accesses' of a memory region
+ that corresponding DAMON-based Operation Scheme's action has
+ tried to be applied.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/age
+Date: Oct 2022
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the 'age' of a memory region that
+ corresponding DAMON-based Operation Scheme's action has tried
+ to be applied.
+
+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/sz_filter_passed
+Date: Dec 2024
+Contact: SeongJae Park <sj@kernel.org>
+Description: Reading this file returns the size of the memory in the region
+ that passed DAMON operations layer-handled filters of the
+ scheme in bytes.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm
index d244674a9480..6041a025b65a 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-ksm
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-ksm
@@ -51,3 +51,11 @@ Description: Control merging pages across different NUMA nodes.
When it is set to 0 only pages from the same node are merged,
otherwise pages from all nodes can be merged together (default).
+
+What: /sys/kernel/mm/ksm/general_profit
+Date: April 2023
+KernelVersion: 6.4
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Measure how effective KSM is.
+ general_profit: how effective is KSM. The formula for the
+ calculation is in Documentation/admin-guide/mm/ksm.rst.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers b/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers
new file mode 100644
index 000000000000..721a05b90109
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-memory-tiers
@@ -0,0 +1,25 @@
+What: /sys/devices/virtual/memory_tiering/
+Date: August 2022
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: A collection of all the memory tiers allocated.
+
+ Individual memory tier details are contained in subdirectories
+ named by the abstract distance of the memory tier.
+
+ /sys/devices/virtual/memory_tiering/memory_tierN/
+
+
+What: /sys/devices/virtual/memory_tiering/memory_tierN/
+ /sys/devices/virtual/memory_tiering/memory_tierN/nodelist
+Date: August 2022
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Directory with details of a specific memory tier
+
+ This is the directory containing information about a particular
+ memory tier, memtierN, where N is derived based on abstract distance.
+
+ A smaller value of N implies a higher (faster) memory tier in the
+ hierarchy.
+
+ nodelist: NUMA nodes that are part of this memory tier.
+
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy
new file mode 100644
index 000000000000..8ac327fd7fb6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy
@@ -0,0 +1,4 @@
+What: /sys/kernel/mm/mempolicy/
+Date: January 2024
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Interface for Mempolicy
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave
new file mode 100644
index 000000000000..649c0e9b895c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave
@@ -0,0 +1,54 @@
+What: /sys/kernel/mm/mempolicy/weighted_interleave/
+Date: January 2024
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Configuration Interface for the Weighted Interleave policy
+
+What: /sys/kernel/mm/mempolicy/weighted_interleave/nodeN
+Date: January 2024
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Weight configuration interface for nodeN
+
+ The interleave weight for a memory node (N). These weights are
+ utilized by tasks which have set their mempolicy to
+ MPOL_WEIGHTED_INTERLEAVE.
+
+ These weights only affect new allocations, and changes at runtime
+ will not cause migrations on already allocated pages.
+
+ The minimum weight for a node is always 1.
+
+ Minimum weight: 1
+ Maximum weight: 255
+
+ Writing invalid values (i.e. any values not in [1,255],
+ empty string, ...) will return -EINVAL.
+
+ Changing the weight to a valid value will automatically
+ switch the system to manual mode as well.
+
+What: /sys/kernel/mm/mempolicy/weighted_interleave/auto
+Date: May 2025
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description: Auto-weighting configuration interface
+
+ Configuration mode for weighted interleave. 'true' indicates
+ that the system is in auto mode, and a 'false' indicates that
+ the system is in manual mode.
+
+ In auto mode, all node weights are re-calculated and overwritten
+ (visible via the nodeN interfaces) whenever new bandwidth data
+ is made available during either boot or hotplug events.
+
+ In manual mode, node weights can only be updated by the user.
+ Note that nodes that are onlined with previously set weights
+ will reuse those weights. If they were not previously set or
+ are onlined with missing bandwidth data, the weights will use
+ a default weight of 1.
+
+ Writing any true value string (e.g. Y or 1) will enable auto
+ mode, while writing any false value string (e.g. N or 0) will
+ enable manual mode. All other strings are ignored and will
+ return -EINVAL.
+
+ Writing a new weight to a node directly via the nodeN interface
+ will also automatically switch the system to manual mode.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-numa b/Documentation/ABI/testing/sysfs-kernel-mm-numa
index 77e559d4ed80..90e375ff54cb 100644
--- a/Documentation/ABI/testing/sysfs-kernel-mm-numa
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-numa
@@ -16,9 +16,13 @@ Description: Enable/disable demoting pages during reclaim
Allowing page migration during reclaim enables these
systems to migrate pages from fast tiers to slow tiers
when the fast tier is under pressure. This migration
- is performed before swap. It may move data to a NUMA
- node that does not fall into the cpuset of the
- allocating process which might be construed to violate
- the guarantees of cpusets. This should not be enabled
- on systems which need strict cpuset location
- guarantees.
+ is performed before swap if an eligible numa node is
+ present in cpuset.mems for the cgroup (or if cpuset v1
+ is being used). If cpusets.mems changes at runtime, it
+ may move data to a NUMA node that does not fall into the
+ cpuset of the new cpusets.mems, which might be construed
+ to violate the guarantees of cpusets. Shared memory,
+ such as libraries, owned by another cgroup may still be
+ demoted and result in memory use on a node not present
+ in cpusets.mem. This should not be enabled on systems
+ which need strict cpuset location guarantees.
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage b/Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage
new file mode 100644
index 000000000000..7bfbb9cc2c11
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage
@@ -0,0 +1,18 @@
+What: /sys/kernel/mm/transparent_hugepage/
+Date: April 2024
+Contact: Linux memory management mailing list <linux-mm@kvack.org>
+Description:
+ /sys/kernel/mm/transparent_hugepage/ contains a number of files and
+ subdirectories,
+
+ - defrag
+ - enabled
+ - hpage_pmd_size
+ - khugepaged
+ - shmem_enabled
+ - use_zero_page
+ - subdirectories of the form hugepages-<size>kB, where <size>
+ is the page size of the hugepages supported by the kernel/CPU
+ combination.
+
+ See Documentation/admin-guide/mm/transhuge.rst for details.
diff --git a/Documentation/ABI/testing/sysfs-kernel-oops_count b/Documentation/ABI/testing/sysfs-kernel-oops_count
new file mode 100644
index 000000000000..156cca9dbc96
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-oops_count
@@ -0,0 +1,6 @@
+What: /sys/kernel/oops_count
+Date: November 2022
+KernelVersion: 6.2.0
+Contact: Linux Kernel Hardening List <linux-hardening@vger.kernel.org>
+Description:
+ Shows how many times the system has Oopsed since last boot.
diff --git a/Documentation/ABI/testing/sysfs-kernel-rcu_stall_count b/Documentation/ABI/testing/sysfs-kernel-rcu_stall_count
new file mode 100644
index 000000000000..a4a97a7f4a4d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-rcu_stall_count
@@ -0,0 +1,6 @@
+What: /sys/kernel/rcu_stall_count
+Date: May 2025
+KernelVersion: 6.16
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ Shows how many times the system has detected an RCU stall since last boot.
diff --git a/Documentation/ABI/testing/sysfs-kernel-reboot b/Documentation/ABI/testing/sysfs-kernel-reboot
index 837330fb2511..52571fd5ddba 100644
--- a/Documentation/ABI/testing/sysfs-kernel-reboot
+++ b/Documentation/ABI/testing/sysfs-kernel-reboot
@@ -1,7 +1,7 @@
What: /sys/kernel/reboot
Date: November 2020
KernelVersion: 5.11
-Contact: Matteo Croce <mcroce@microsoft.com>
+Contact: Matteo Croce <teknoraver@meta.com>
Description: Interface to set the kernel reboot behavior, similarly to
what can be done via the reboot= cmdline option.
(see Documentation/admin-guide/kernel-parameters.txt)
@@ -9,24 +9,32 @@ Description: Interface to set the kernel reboot behavior, similarly to
What: /sys/kernel/reboot/mode
Date: November 2020
KernelVersion: 5.11
-Contact: Matteo Croce <mcroce@microsoft.com>
+Contact: Matteo Croce <teknoraver@meta.com>
Description: Reboot mode. Valid values are: cold warm hard soft gpio
What: /sys/kernel/reboot/type
Date: November 2020
KernelVersion: 5.11
-Contact: Matteo Croce <mcroce@microsoft.com>
+Contact: Matteo Croce <teknoraver@meta.com>
Description: Reboot type. Valid values are: bios acpi kbd triple efi pci
What: /sys/kernel/reboot/cpu
Date: November 2020
KernelVersion: 5.11
-Contact: Matteo Croce <mcroce@microsoft.com>
+Contact: Matteo Croce <teknoraver@meta.com>
Description: CPU number to use to reboot.
What: /sys/kernel/reboot/force
Date: November 2020
KernelVersion: 5.11
-Contact: Matteo Croce <mcroce@microsoft.com>
+Contact: Matteo Croce <teknoraver@meta.com>
Description: Don't wait for any other CPUs on reboot and
avoid anything that could hang.
+
+What: /sys/kernel/reboot/hw_protection
+Date: April 2025
+KernelVersion: 6.15
+Contact: Ahmad Fatoum <a.fatoum@pengutronix.de>
+Description: Hardware protection action taken on critical events like
+ overtemperature or imminent voltage loss.
+ Valid values are: reboot shutdown
diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab
index cd5fb8fa3ddf..b26e4299f822 100644
--- a/Documentation/ABI/testing/sysfs-kernel-slab
+++ b/Documentation/ABI/testing/sysfs-kernel-slab
@@ -2,7 +2,7 @@ What: /sys/kernel/slab
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The /sys/kernel/slab directory contains a snapshot of the
internal state of the SLUB allocator for each cache. Certain
@@ -14,7 +14,7 @@ What: /sys/kernel/slab/<cache>/aliases
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The aliases file is read-only and specifies how many caches
have merged into this cache.
@@ -23,7 +23,7 @@ What: /sys/kernel/slab/<cache>/align
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The align file is read-only and specifies the cache's object
alignment in bytes.
@@ -32,18 +32,19 @@ What: /sys/kernel/slab/<cache>/alloc_calls
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The alloc_calls file is read-only and lists the kernel code
locations from which allocations for this cache were performed.
The alloc_calls file only contains information if debugging is
- enabled for that cache (see Documentation/mm/slub.rst).
+ enabled for that cache (see
+ Documentation/admin-guide/mm/slab.rst).
What: /sys/kernel/slab/<cache>/alloc_fastpath
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The alloc_fastpath file shows how many objects have been
allocated using the fast path. It can be written to clear the
@@ -54,7 +55,7 @@ What: /sys/kernel/slab/<cache>/alloc_from_partial
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The alloc_from_partial file shows how many times a cpu slab has
been full and it has been refilled by using a slab from the list
@@ -66,7 +67,7 @@ What: /sys/kernel/slab/<cache>/alloc_refill
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The alloc_refill file shows how many times the per-cpu freelist
was empty but there were objects available as the result of
@@ -77,7 +78,7 @@ What: /sys/kernel/slab/<cache>/alloc_slab
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The alloc_slab file is shows how many times a new slab had to
be allocated from the page allocator. It can be written to
@@ -88,7 +89,7 @@ What: /sys/kernel/slab/<cache>/alloc_slowpath
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The alloc_slowpath file shows how many objects have been
allocated using the slow path because of a refill or
@@ -100,7 +101,7 @@ What: /sys/kernel/slab/<cache>/cache_dma
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The cache_dma file is read-only and specifies whether objects
are from ZONE_DMA.
@@ -110,7 +111,7 @@ What: /sys/kernel/slab/<cache>/cpu_slabs
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The cpu_slabs file is read-only and displays how many cpu slabs
are active and their NUMA locality.
@@ -119,7 +120,7 @@ What: /sys/kernel/slab/<cache>/cpuslab_flush
Date: April 2009
KernelVersion: 2.6.31
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The file cpuslab_flush shows how many times a cache's cpu slabs
have been flushed as the result of destroying or shrinking a
@@ -132,7 +133,7 @@ What: /sys/kernel/slab/<cache>/ctor
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The ctor file is read-only and specifies the cache's object
constructor function, which is invoked for each object when a
@@ -142,7 +143,7 @@ What: /sys/kernel/slab/<cache>/deactivate_empty
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The deactivate_empty file shows how many times an empty cpu slab
was deactivated. It can be written to clear the current count.
@@ -152,7 +153,7 @@ What: /sys/kernel/slab/<cache>/deactivate_full
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The deactivate_full file shows how many times a full cpu slab
was deactivated. It can be written to clear the current count.
@@ -162,7 +163,7 @@ What: /sys/kernel/slab/<cache>/deactivate_remote_frees
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The deactivate_remote_frees file shows how many times a cpu slab
has been deactivated and contained free objects that were freed
@@ -173,7 +174,7 @@ What: /sys/kernel/slab/<cache>/deactivate_to_head
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The deactivate_to_head file shows how many times a partial cpu
slab was deactivated and added to the head of its node's partial
@@ -184,7 +185,7 @@ What: /sys/kernel/slab/<cache>/deactivate_to_tail
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The deactivate_to_tail file shows how many times a partial cpu
slab was deactivated and added to the tail of its node's partial
@@ -195,7 +196,7 @@ What: /sys/kernel/slab/<cache>/destroy_by_rcu
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The destroy_by_rcu file is read-only and specifies whether
slabs (not objects) are freed by rcu.
@@ -204,7 +205,7 @@ What: /sys/kernel/slab/<cache>/free_add_partial
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_add_partial file shows how many times an object has
been freed in a full slab so that it had to added to its node's
@@ -215,17 +216,17 @@ What: /sys/kernel/slab/<cache>/free_calls
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_calls file is read-only and lists the locations of
object frees if slab debugging is enabled (see
- Documentation/mm/slub.rst).
+ Documentation/admin-guide/mm/slab.rst).
What: /sys/kernel/slab/<cache>/free_fastpath
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_fastpath file shows how many objects have been freed
using the fast path because it was an object from the cpu slab.
@@ -236,7 +237,7 @@ What: /sys/kernel/slab/<cache>/free_frozen
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_frozen file shows how many objects have been freed to
a frozen slab (i.e. a remote cpu slab). It can be written to
@@ -247,7 +248,7 @@ What: /sys/kernel/slab/<cache>/free_remove_partial
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_remove_partial file shows how many times an object has
been freed to a now-empty slab so that it had to be removed from
@@ -259,7 +260,7 @@ What: /sys/kernel/slab/<cache>/free_slab
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_slab file shows how many times an empty slab has been
freed back to the page allocator. It can be written to clear
@@ -270,7 +271,7 @@ What: /sys/kernel/slab/<cache>/free_slowpath
Date: February 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The free_slowpath file shows how many objects have been freed
using the slow path (i.e. to a full or partial slab). It can
@@ -281,7 +282,7 @@ What: /sys/kernel/slab/<cache>/hwcache_align
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The hwcache_align file is read-only and specifies whether
objects are aligned on cachelines.
@@ -301,7 +302,7 @@ What: /sys/kernel/slab/<cache>/object_size
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The object_size file is read-only and specifies the cache's
object size.
@@ -310,7 +311,7 @@ What: /sys/kernel/slab/<cache>/objects
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The objects file is read-only and displays how many objects are
active and from which nodes they are from.
@@ -319,7 +320,7 @@ What: /sys/kernel/slab/<cache>/objects_partial
Date: April 2008
KernelVersion: 2.6.26
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The objects_partial file is read-only and displays how many
objects are on partial slabs and from which nodes they are
@@ -329,7 +330,7 @@ What: /sys/kernel/slab/<cache>/objs_per_slab
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The file objs_per_slab is read-only and specifies how many
objects may be allocated from a single slab of the order
@@ -339,7 +340,7 @@ What: /sys/kernel/slab/<cache>/order
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The order file specifies the page order at which new slabs are
allocated. It is writable and can be changed to increase the
@@ -356,7 +357,7 @@ What: /sys/kernel/slab/<cache>/order_fallback
Date: April 2008
KernelVersion: 2.6.26
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The order_fallback file shows how many times an allocation of a
new slab has not been possible at the cache's order and instead
@@ -369,7 +370,7 @@ What: /sys/kernel/slab/<cache>/partial
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The partial file is read-only and displays how long many
partial slabs there are and how long each node's list is.
@@ -378,7 +379,7 @@ What: /sys/kernel/slab/<cache>/poison
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The poison file specifies whether objects should be poisoned
when a new slab is allocated.
@@ -387,7 +388,7 @@ What: /sys/kernel/slab/<cache>/reclaim_account
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The reclaim_account file specifies whether the cache's objects
are reclaimable (and grouped by their mobility).
@@ -396,7 +397,7 @@ What: /sys/kernel/slab/<cache>/red_zone
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The red_zone file specifies whether the cache's objects are red
zoned.
@@ -405,7 +406,7 @@ What: /sys/kernel/slab/<cache>/remote_node_defrag_ratio
Date: January 2008
KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The file remote_node_defrag_ratio specifies the percentage of
times SLUB will attempt to refill the cpu slab with a partial
@@ -419,7 +420,7 @@ What: /sys/kernel/slab/<cache>/sanity_checks
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The sanity_checks file specifies whether expensive checks
should be performed on free and, at minimum, enables double free
@@ -430,7 +431,7 @@ What: /sys/kernel/slab/<cache>/shrink
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The shrink file is used to reclaim unused slab cache
memory from a cache. Empty per-cpu or partial slabs
@@ -446,7 +447,7 @@ What: /sys/kernel/slab/<cache>/slab_size
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The slab_size file is read-only and specifies the object size
with metadata (debugging information and alignment) in bytes.
@@ -455,7 +456,7 @@ What: /sys/kernel/slab/<cache>/slabs
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The slabs file is read-only and displays how long many slabs
there are (both cpu and partial) and from which nodes they are
@@ -465,7 +466,7 @@ What: /sys/kernel/slab/<cache>/store_user
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The store_user file specifies whether the location of
allocation or free should be tracked for a cache.
@@ -474,7 +475,7 @@ What: /sys/kernel/slab/<cache>/total_objects
Date: April 2008
KernelVersion: 2.6.26
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The total_objects file is read-only and displays how many total
objects a cache has and from which nodes they are from.
@@ -483,7 +484,7 @@ What: /sys/kernel/slab/<cache>/trace
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
The trace file specifies whether object allocations and frees
should be traced.
@@ -492,7 +493,7 @@ What: /sys/kernel/slab/<cache>/validate
Date: May 2007
KernelVersion: 2.6.22
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
- Christoph Lameter <cl@linux-foundation.org>
+ Christoph Lameter <cl@gentwo.org>
Description:
Writing to the validate file causes SLUB to traverse all of its
cache's objects and check the validity of metadata.
@@ -506,14 +507,14 @@ Description:
What: /sys/kernel/slab/<cache>/slabs_cpu_partial
Date: Aug 2011
-Contact: Christoph Lameter <cl@linux.com>
+Contact: Christoph Lameter <cl@gentwo.org>
Description:
This read-only file shows the number of partialli allocated
frozen slabs.
What: /sys/kernel/slab/<cache>/cpu_partial
Date: Aug 2011
-Contact: Christoph Lameter <cl@linux.com>
+Contact: Christoph Lameter <cl@gentwo.org>
Description:
This read-only file shows the number of per cpu partial
pages to keep around.
diff --git a/Documentation/ABI/testing/sysfs-kernel-softlockup_count b/Documentation/ABI/testing/sysfs-kernel-softlockup_count
new file mode 100644
index 000000000000..337ff5531b5f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-softlockup_count
@@ -0,0 +1,7 @@
+What: /sys/kernel/softlockup_count
+Date: May 2025
+KernelVersion: 6.16
+Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:
+ Shows how many times the system has detected a soft lockup since last boot.
+ Available only if CONFIG_SOFTLOCKUP_DETECTOR is enabled.
diff --git a/Documentation/ABI/testing/sysfs-kernel-warn_count b/Documentation/ABI/testing/sysfs-kernel-warn_count
new file mode 100644
index 000000000000..90a029813717
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-warn_count
@@ -0,0 +1,6 @@
+What: /sys/kernel/warn_count
+Date: November 2022
+KernelVersion: 6.2.0
+Contact: Linux Kernel Hardening List <linux-hardening@vger.kernel.org>
+Description:
+ Shows how many times the system has Warned since last boot.
diff --git a/Documentation/ABI/testing/sysfs-memory-page-offline b/Documentation/ABI/testing/sysfs-memory-page-offline
index e14703f12fdf..00f4e35f916f 100644
--- a/Documentation/ABI/testing/sysfs-memory-page-offline
+++ b/Documentation/ABI/testing/sysfs-memory-page-offline
@@ -10,7 +10,7 @@ Description:
dropping it if possible. The kernel will then be placed
on the bad page list and never be reused.
- The offlining is done in kernel specific granuality.
+ The offlining is done in kernel specific granularity.
Normally it's the base page size of the kernel, but
this might change.
@@ -35,7 +35,7 @@ Description:
to access this page assuming it's poisoned by the
hardware.
- The offlining is done in kernel specific granuality.
+ The offlining is done in kernel specific granularity.
Normally it's the base page size of the kernel, but
this might change.
diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module
index 08886367d047..6bc9af6229f0 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -59,4 +59,17 @@ Description: Module taint flags:
F force-loaded module
C staging driver module
E unsigned module
+ K livepatch module
+ N in-kernel test module
== =====================
+
+What: /sys/module/grant_table/parameters/free_per_iteration
+Date: July 2023
+KernelVersion: 6.5 but backported to all supported stable branches
+Contact: Xen developer discussion <xen-devel@lists.xenproject.org>
+Description: Read and write number of grant entries to attempt to free per iteration.
+
+ Note: Future versions of Xen and Linux may provide a better
+ interface for controlling the rate of deferred grant reclaim
+ or may not need it at all.
+Users: Qubes OS (https://www.qubes-os.org)
diff --git a/Documentation/ABI/testing/sysfs-nvmem-cells b/Documentation/ABI/testing/sysfs-nvmem-cells
new file mode 100644
index 000000000000..c7c9444f92a8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-nvmem-cells
@@ -0,0 +1,21 @@
+What: /sys/bus/nvmem/devices/.../cells/<cell-name>
+Date: May 2023
+KernelVersion: 6.5
+Contact: Miquel Raynal <miquel.raynal@bootlin.com>
+Description:
+ The "cells" folder contains one file per cell exposed by the
+ NVMEM device. The name of the file is: "<name>@<byte>,<bit>",
+ with <name> being the cell name and <where> its location in
+ the NVMEM device, in hexadecimal bytes and bits (without the
+ '0x' prefix, to mimic device tree node names). The length of
+ the file is the size of the cell (when known). The content of
+ the file is the binary content of the cell (may sometimes be
+ ASCII, likely without trailing character).
+ Note: This file is only present if CONFIG_NVMEM_SYSFS
+ is enabled.
+
+ Example::
+
+ hexdump -C /sys/bus/nvmem/devices/1-00563/cells/product-name@d,0
+ 00000000 54 4e 34 38 4d 2d 50 2d 44 4e |TN48M-P-DN|
+ 0000000a
diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2
index b7cc516a8a8a..494d7c1ac710 100644
--- a/Documentation/ABI/testing/sysfs-ocfs2
+++ b/Documentation/ABI/testing/sysfs-ocfs2
@@ -1,13 +1,13 @@
What: /sys/fs/ocfs2/
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
@@ -28,7 +28,7 @@ Description:
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
@@ -48,7 +48,7 @@ Description:
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
@@ -65,7 +65,7 @@ Description:
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
-Contact: ocfs2-devel@oss.oracle.com
+Contact: ocfs2-devel@lists.linux.dev
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
@@ -86,4 +86,4 @@ Description:
stack return an error.
Users:
- ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
+ ocfs2-tools <ocfs2-tools-devel@lists.linux.dev>
diff --git a/Documentation/ABI/testing/sysfs-platform-alienware-wmi b/Documentation/ABI/testing/sysfs-platform-alienware-wmi
new file mode 100644
index 000000000000..4877b3745f4e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-alienware-wmi
@@ -0,0 +1,14 @@
+What: /sys/class/hwmon/hwmonX/fanY_boost
+Date: March 2025
+KernelVersion: 6.15
+Contact: Kurt Borja <kuurtb@gmail.com>
+Description:
+ This file exposes fan boost control for Dell gaming laptops with
+ the AWCC WMI interface.
+
+ See Documentation/admin-guide/laptops/alienware-wmi.rst for
+ details.
+
+ Integer value in the range 0 to 255
+
+ RW
diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Documentation/ABI/testing/sysfs-platform-asus-wmi
index a77a004a1baa..89acb6638df8 100644
--- a/Documentation/ABI/testing/sysfs-platform-asus-wmi
+++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi
@@ -63,6 +63,7 @@ Date: Aug 2022
KernelVersion: 6.1
Contact: "Luke Jones" <luke@ljones.dev>
Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
Switch the GPU hardware MUX mode. Laptops with this feature can
can be toggled to boot with only the dGPU (discrete mode) or in
standard Optimus/Hybrid mode. On switch a reboot is required:
@@ -75,6 +76,7 @@ Date: Aug 2022
KernelVersion: 5.17
Contact: "Luke Jones" <luke@ljones.dev>
Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
Disable discrete GPU:
* 0 - Enable dGPU,
* 1 - Disable dGPU
@@ -84,6 +86,7 @@ Date: Aug 2022
KernelVersion: 5.17
Contact: "Luke Jones" <luke@ljones.dev>
Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
Enable the external GPU paired with ROG X-Flow laptops.
Toggling this setting will also trigger ACPI to disable the dGPU:
@@ -95,6 +98,134 @@ Date: Aug 2022
KernelVersion: 5.17
Contact: "Luke Jones" <luke@ljones.dev>
Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
Enable an LCD response-time boost to reduce or remove ghosting:
* 0 - Disable,
* 1 - Enable
+
+What: /sys/devices/platform/<platform>/charge_mode
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Get the current charging mode being used:
+ * 1 - Barrel connected charger,
+ * 2 - USB-C charging
+ * 3 - Both connected, barrel used for charging
+
+What: /sys/devices/platform/<platform>/egpu_connected
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Show if the egpu (XG Mobile) is correctly connected:
+ * 0 - False,
+ * 1 - True
+
+What: /sys/devices/platform/<platform>/mini_led_mode
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Change the mini-LED mode:
+ * 0 - Single-zone,
+ * 1 - Multi-zone
+ * 2 - Multi-zone strong (available on newer generation mini-led)
+
+What: /sys/devices/platform/<platform>/available_mini_led_mode
+Date: Apr 2024
+KernelVersion: 6.10
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ List the available mini-led modes.
+
+What: /sys/devices/platform/<platform>/ppt_pl1_spl
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the Package Power Target total of CPU: PL1 on Intel, SPL on AMD.
+ Shown on Intel+Nvidia or AMD+Nvidia based systems:
+
+ * min=5, max=250
+
+What: /sys/devices/platform/<platform>/ppt_pl2_sppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the Slow Package Power Tracking Limit of CPU: PL2 on Intel, SPPT,
+ on AMD. Shown on Intel+Nvidia or AMD+Nvidia based systems:
+
+ * min=5, max=250
+
+What: /sys/devices/platform/<platform>/ppt_fppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the Fast Package Power Tracking Limit of CPU. AMD+Nvidia only:
+ * min=5, max=250
+
+What: /sys/devices/platform/<platform>/ppt_apu_sppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the APU SPPT limit. Shown on full AMD systems only:
+ * min=5, max=130
+
+What: /sys/devices/platform/<platform>/ppt_platform_sppt
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the platform SPPT limit. Shown on full AMD systems only:
+ * min=5, max=130
+
+What: /sys/devices/platform/<platform>/nv_dynamic_boost
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the dynamic boost limit of the Nvidia dGPU:
+ * min=5, max=25
+
+What: /sys/devices/platform/<platform>/nv_temp_target
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set the target temperature limit of the Nvidia dGPU:
+ * min=75, max=87
+
+What: /sys/devices/platform/<platform>/boot_sound
+Date: Apr 2024
+KernelVersion: 6.10
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set if the BIOS POST sound is played on boot.
+ * 0 - False,
+ * 1 - True
+
+What: /sys/devices/platform/<platform>/mcu_powersave
+Date: Apr 2024
+KernelVersion: 6.10
+Contact: "Luke Jones" <luke@ljones.dev>
+Description:
+ DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
+ Set if the MCU can go in to low-power mode on system sleep
+ * 0 - False,
+ * 1 - True
diff --git a/Documentation/ABI/testing/sysfs-platform-ayaneo-ec b/Documentation/ABI/testing/sysfs-platform-ayaneo-ec
new file mode 100644
index 000000000000..4cffbf5fc7ca
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-ayaneo-ec
@@ -0,0 +1,19 @@
+What: /sys/devices/platform/ayaneo-ec/controller_power
+Date: Nov 2025
+KernelVersion: 6.19
+Contact: "Antheas Kapenekakis" <lkml@antheas.dev>
+Description:
+ Current controller power state. Allows turning on and off
+ the controller power (e.g. for power savings). Write 1 to
+ turn on, 0 to turn off. File is readable and writable.
+
+What: /sys/devices/platform/ayaneo-ec/controller_modules
+Date: Nov 2025
+KernelVersion: 6.19
+Contact: "Antheas Kapenekakis" <lkml@antheas.dev>
+Description:
+ Shows which controller modules are currently connected to
+ the device. Possible values are "left", "right" and "both".
+ File is read-only. The Windows software for this device
+ will only set controller power to 1 if both module sides
+ are connected (i.e. this file returns "both").
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop b/Documentation/ABI/testing/sysfs-platform-dell-laptop
index 82bcfe9df66e..701529653283 100644
--- a/Documentation/ABI/testing/sysfs-platform-dell-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop
@@ -15,7 +15,7 @@ KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali@kernel.org>
Description:
- This file allows to specifiy the on/off threshold value,
+ This file allows to specify the on/off threshold value,
as reported by the ambient light sensor.
What: /sys/class/leds/dell::kbd_backlight/start_triggers
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
index 1f1f274a6979..b4da7b2ea0ca 100644
--- a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
+++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi
@@ -1,4 +1,4 @@
-What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
+What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919[-X]/dell_privacy_supported_type
Date: Apr 2021
KernelVersion: 5.13
Contact: "<perry.yuan@dell.com>"
@@ -29,12 +29,12 @@ Description:
For example to check which privacy devices are supported::
- # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type
+ # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919*/dell_privacy_supported_type
[Microphone Mute] [supported]
[Camera Shutter] [supported]
[ePrivacy Screen] [unsupported]
-What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state
+What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919[-X]/dell_privacy_current_state
Date: Apr 2021
KernelVersion: 5.13
Contact: "<perry.yuan@dell.com>"
@@ -66,6 +66,6 @@ Description:
For example to check all supported current privacy device states::
- # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state
+ # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919*/dell_privacy_current_state
[Microphone] [unmuted]
[Camera Shutter] [unmuted]
diff --git a/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
new file mode 100644
index 000000000000..a9d39d9e8865
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-dell-wmi-ddv
@@ -0,0 +1,9 @@
+What: /sys/class/power_supply/<battery_name>/eppid
+Date: September 2022
+KernelVersion: 6.1
+Contact: Armin Wolf <W_Armin@gmx.de>
+Description:
+ Reports the Dell ePPID (electronic Piece Part Identification)
+ of the ACPI battery.
+
+ See Documentation/wmi/devices/dell-wmi-ddv.rst for details.
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
index d6ab34e81b9b..2d5b78d2cf51 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
@@ -90,7 +90,7 @@ KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to get errors detected on FME.
Write this file to clear errors logged in fme_errors. Write
- fials with -EINVAL if input parsing fails or input error code
+ fails with -EINVAL if input parsing fails or input error code
doesn't match.
What: /sys/bus/platform/devices/dfl-fme.0/errors/first_error
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma b/Documentation/ABI/testing/sysfs-platform-hidma
index fca40a54df59..a80aeda85ef6 100644
--- a/Documentation/ABI/testing/sysfs-platform-hidma
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-*/chid
/sys/devices/platform/QCOM8061:*/chid
Date: Dec 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the ID of the channel within the HIDMA instance.
It is used to associate a given HIDMA channel with the
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
index 3b6c5c9eabdc..0373745b4e18 100644
--- a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains either 0 or 1 and indicates if the DMA channel is a
low priority (0) or high priority (1) channel.
@@ -11,7 +11,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains 0..15 and indicates the weight of the channel among
equal priority channels during round robin scheduling.
@@ -20,7 +20,7 @@ What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the platform specific cycle value to wait after a
reset command is issued. If the value is chosen too short,
@@ -32,7 +32,7 @@ What: /sys/devices/platform/hidma-mgmt*/dma_channels
/sys/devices/platform/QCOM8060:*/dma_channels
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains the number of dma channels supported by one instance
of HIDMA hardware. The value may change from chip to chip.
@@ -41,7 +41,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_major
/sys/devices/platform/QCOM8060:*/hw_version_major
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Version number major for the hardware.
@@ -49,7 +49,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_minor
/sys/devices/platform/QCOM8060:*/hw_version_minor
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Version number minor for the hardware.
@@ -57,7 +57,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions
/sys/devices/platform/QCOM8060:*/max_rd_xactions
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains a value between 0 and 31. Maximum number of
read transactions that can be issued back to back.
@@ -69,7 +69,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_read_request
/sys/devices/platform/QCOM8060:*/max_read_request
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Size of each read request. The value needs to be a power
of two and can be between 128 and 1024.
@@ -78,7 +78,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions
/sys/devices/platform/QCOM8060:*/max_wr_xactions
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Contains a value between 0 and 31. Maximum number of
write transactions that can be issued back to back.
@@ -91,7 +91,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_write_request
/sys/devices/platform/QCOM8060:*/max_write_request
Date: Nov 2015
KernelVersion: 4.4
-Contact: "Sinan Kaya <okaya@codeaurora.org>"
+Contact: "Sinan Kaya <okaya@kernel.org>"
Description:
Size of each write request. The value needs to be a power
of two and can be between 128 and 1024.
diff --git a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
index 4989ab266682..5ec0dee9e707 100644
--- a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop
@@ -27,15 +27,6 @@ Description:
* 1 -> Switched On
* 0 -> Switched Off
-What: /sys/bus/platform/devices/VPC2004:*/conservation_mode
-Date: Aug 2017
-KernelVersion: 4.14
-Contact: platform-driver-x86@vger.kernel.org
-Description:
- Controls whether the conservation mode is enabled or not.
- This feature limits the maximum battery charge percentage to
- around 50-60% in order to prolong the lifetime of the battery.
-
What: /sys/bus/platform/devices/VPC2004:*/fn_lock
Date: May 2018
KernelVersion: 4.18
diff --git a/Documentation/ABI/testing/sysfs-platform-intel-ifs b/Documentation/ABI/testing/sysfs-platform-intel-ifs
index 486d6d2ff8a0..41b4d5b1e21c 100644
--- a/Documentation/ABI/testing/sysfs-platform-intel-ifs
+++ b/Documentation/ABI/testing/sysfs-platform-intel-ifs
@@ -1,39 +1,52 @@
+Device instance to test mapping
+intel_ifs_0 -> Scan Test
+intel_ifs_1 -> Array BIST test
+
What: /sys/devices/virtual/misc/intel_ifs_<N>/run_test
-Date: April 21 2022
-KernelVersion: 5.19
+Date: Nov 16 2022
+KernelVersion: 6.2
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: Write <cpu#> to trigger IFS test for one online core.
Note that the test is per core. The cpu# can be
for any thread on the core. Running on one thread
completes the test for the core containing that thread.
Example: to test the core containing cpu5: echo 5 >
- /sys/devices/platform/intel_ifs.<N>/run_test
+ /sys/devices/virtual/misc/intel_ifs_<N>/run_test
+Devices: all
What: /sys/devices/virtual/misc/intel_ifs_<N>/status
-Date: April 21 2022
-KernelVersion: 5.19
+Date: Nov 16 2022
+KernelVersion: 6.2
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: The status of the last test. It can be one of "pass", "fail"
or "untested".
+Devices: all
What: /sys/devices/virtual/misc/intel_ifs_<N>/details
-Date: April 21 2022
-KernelVersion: 5.19
+Date: Nov 16 2022
+KernelVersion: 6.2
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: Additional information regarding the last test. The details file reports
- the hex value of the SCAN_STATUS MSR. Note that the error_code field
+ the hex value of the STATUS MSR for this test. Note that the error_code field
may contain driver defined software code not defined in the Intel SDM.
+Devices: all
What: /sys/devices/virtual/misc/intel_ifs_<N>/image_version
-Date: April 21 2022
-KernelVersion: 5.19
+Date: Nov 16 2022
+KernelVersion: 6.2
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
-Description: Version (hexadecimal) of loaded IFS binary image. If no scan image
- is loaded reports "none".
+Description: Version (hexadecimal) of loaded IFS test image. If no test image
+ is loaded reports "none". Only present for device instances where a test image
+ is applicable.
+Devices: intel_ifs_0
-What: /sys/devices/virtual/misc/intel_ifs_<N>/reload
-Date: April 21 2022
-KernelVersion: 5.19
+What: /sys/devices/virtual/misc/intel_ifs_<N>/current_batch
+Date: Nov 16 2022
+KernelVersion: 6.2
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
-Description: Write "1" (or "y" or "Y") to reload the IFS image from
- /lib/firmware/intel/ifs/ff-mm-ss.scan.
+Description: Write a number less than or equal to 0xff to load an IFS test image.
+ The number written treated as the 2 digit suffix in the following file name:
+ /lib/firmware/intel/ifs_<N>/ff-mm-ss-02x.scan
+ Reading the file will provide the suffix of the currently loaded IFS test image.
+ This file is present only for device instances where a test image is applicable.
+Devices: intel_ifs_0
diff --git a/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update b/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update
index 02ae1e9bbfc8..7ffd1579b8f7 100644
--- a/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update
+++ b/Documentation/ABI/testing/sysfs-platform-intel-wmi-sbl-fw-update
@@ -1,4 +1,4 @@
-What: /sys/bus/wmi/devices/44FADEB1-B204-40F2-8581-394BBDC1B651/firmware_update_request
+What: /sys/bus/wmi/devices/44FADEB1-B204-40F2-8581-394BBDC1B651[-X]/firmware_update_request
Date: April 2020
KernelVersion: 5.7
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
diff --git a/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt b/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt
index fd3a7ec79760..10ef1282c9d2 100644
--- a/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt
@@ -1,4 +1,4 @@
-What: /sys/devices/platform/<platform>/force_power
+What: /sys/bus/wmi/devices/86CCFD48-205E-4A77-9C48-2021CBEDE341[-X]/force_power
Date: September 2017
KernelVersion: 4.15
Contact: "Mario Limonciello" <mario.limonciello@outlook.com>
diff --git a/Documentation/ABI/testing/sysfs-platform-kim b/Documentation/ABI/testing/sysfs-platform-kim
index 6a52d6d2b601..0a38caa62a32 100644
--- a/Documentation/ABI/testing/sysfs-platform-kim
+++ b/Documentation/ABI/testing/sysfs-platform-kim
@@ -9,7 +9,7 @@ Description:
The device name flows down to architecture specific board
initialization file from the ATAGS bootloader
firmware. The name exposed is read from the user-space
- dameon and opens the device when install is requested.
+ daemon and opens the device when install is requested.
What: /sys/devices/platform/kim/baud_rate
Date: January 2010
diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
index e79ca22e2f45..09f783fa0a53 100644
--- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
+++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
@@ -68,3 +68,95 @@ Description:
Wasted burnt and invalid
Invalid not burnt but marked as valid (error state).
======= ===============================================
+
+What: /sys/bus/platform/devices/MLNXBF04:00/bootfifo
+Date: Apr 2023
+KernelVersion: 6.4
+Contact: "Liming Sun <limings@nvidia.com>"
+Description:
+ The file used to access the BlueField boot fifo.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/rsh_log
+Date: May 2023
+KernelVersion: 6.4
+Contact: "Liming Sun <limings@nvidia.com>"
+Description:
+ The file used to write BlueField boot log with the format
+ "[INFO|WARN|ERR|ASSERT ]<msg>". Log level 'INFO' is used by
+ default if not specified.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/oob_mac
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "oob_mac" sysfs attribute holds the MAC address for
+ the out-of-band 1Gbps Ethernet port. This MAC address is
+ provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/opn
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "opn" sysfs attribute holds the board's part number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/sku
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "sku" sysfs attribute holds the board's SKU number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/modl
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "modl" sysfs attribute holds the board's model number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/sn
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "sn" sysfs attribute holds the board's serial number.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/uuid
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "uuid" sysfs attribute holds the board's UUID.
+ This value is provided by the manufacturing team.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/rev
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "rev" sysfs attribute holds the board's revision.
+ This value is provided on a board-level label.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/mfg_lock
+Date: August 2023
+KernelVersion: 6.5
+Contact: "David Thompson <davthompson@nvidia.com>"
+Description:
+ The "mfg_lock" sysfs attribute is write-only.
+ A successful write to this attribute will latch the
+ board-level attributes into EEPROM, making them read-only.
+
+What: /sys/bus/platform/devices/MLNXBF04:00/rtc_battery
+Date: June 2025
+KernelVersion: 6.15
+Contact: "Xiangrong Li <xiangrongl@nvidia.com>"
+Description:
+ The "rtc_battery" sysfs attribute is read-only.
+ A successful read from this attribute returns the status of
+ the board's RTC battery. The RTC battery status register is
+ also cleared upon successful read operation.
diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-pmc b/Documentation/ABI/testing/sysfs-platform-mellanox-pmc
new file mode 100644
index 000000000000..29b3f9c58e00
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-mellanox-pmc
@@ -0,0 +1,64 @@
+HID Driver Description
+MLNXBFD0 mlxbf-pmc Performance counters (BlueField-1)
+MLNXBFD1 mlxbf-pmc Performance counters (BlueField-2)
+MLNXBFD2 mlxbf-pmc Performance counters (BlueField-3)
+
+What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/event_list
+Date: Dec 2020
+KernelVersion: 5.10
+Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>"
+Description:
+ List of events supported by the counters in the specific block.
+ It is used to extract the event number or ID associated with
+ each event.
+
+What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/event<N>
+Date: Dec 2020
+KernelVersion: 5.10
+Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>"
+Description:
+ Event monitored by corresponding counter. This is used to
+ program or read back the event that should be or is currently
+ being monitored by counter<N>.
+
+What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/counter<N>
+Date: Dec 2020
+KernelVersion: 5.10
+Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>"
+Description:
+ Counter value of the event being monitored. This is used to
+ read the counter value of the event which was programmed using
+ event<N>. This is also used to clear or reset the counter value
+ by writing 0 to the counter sysfs.
+
+What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/enable
+Date: Dec 2020
+KernelVersion: 5.10
+Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>"
+Description:
+ Start or stop counters. This is used to start the counters
+ for monitoring the programmed events and also to stop the
+ counters after the desired duration. Writing value 1 will
+ start all the counters in the block, and writing 0 will
+ stop all the counters together.
+
+What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/<reg>
+Date: Dec 2020
+KernelVersion: 5.10
+Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>"
+Description:
+ Value of register. This is used to read or reset the registers
+ where various performance statistics are counted for each block.
+ Writing 0 to the sysfs will clear the counter, writing any other
+ value is not allowed.
+
+What: /sys/bus/platform/devices/<HID>/hwmon/hwmonX/<block>/count_clock
+Date: Mar 2025
+KernelVersion: 6.14
+Contact: "Shravan Kumar Ramani <shravankr@nvidia.com>"
+Description:
+ Use a counter for counting cycles. This is used to repurpose/dedicate
+ any of the counters in the block to counting cycles. Each counter is
+ represented by a bit (bit 0 for counter0, bit1 for counter1 and so on)
+ and setting the corresponding bit will reserve that specific counter
+ for counting cycles and override the event<N> setting.
diff --git a/Documentation/ABI/testing/sysfs-platform-oxp b/Documentation/ABI/testing/sysfs-platform-oxp
new file mode 100644
index 000000000000..b3f39fc21dfa
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-oxp
@@ -0,0 +1,25 @@
+What: /sys/devices/platform/<platform>/tt_toggle
+Date: Jun 2023
+KernelVersion: 6.5
+Contact: "Antheas Kapenekakis" <lkml@antheas.dev>
+Description:
+ Takeover TDP controls from the device. OneXPlayer devices have a
+ turbo button that can be used to switch between two TDP modes
+ (usually 15W and 25W). By setting this attribute to 1, this
+ functionality is disabled, handing TDP control over to (Windows)
+ userspace software and the Turbo button turns into a keyboard
+ shortcut over the AT keyboard of the device. In addition,
+ using this setting is a prerequisite for PWM control for most
+ newer models (otherwise it NOOPs).
+
+What: /sys/devices/platform/<platform>/tt_led
+Date: April 2025
+KernelVersion: 6.16
+Contact: "Antheas Kapenekakis" <lkml@antheas.dev>
+Description:
+ Some OneXPlayer devices (e.g., X1 series) feature a little LED
+ nested in the Turbo button. This LED is illuminated when the
+ device is in the higher TDP mode (e.g., 25W). Once tt_toggle
+ is engaged, this LED is left dangling to its last state. This
+ attribute allows userspace to control the LED state manually
+ (either with 1 or 0). Only a subset of devices contain this LED.
diff --git a/Documentation/ABI/testing/sysfs-platform-power-on-reason b/Documentation/ABI/testing/sysfs-platform-power-on-reason
new file mode 100644
index 000000000000..c3b29dbc64bf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-power-on-reason
@@ -0,0 +1,12 @@
+What: /sys/devices/platform/.../power_on_reason
+Date: June 2023
+KernelVersion: 6.5
+Contact: Kamel Bouhara <kamel.bouhara@bootlin.com>
+Description: Shows system power on reason. The following strings/reasons can
+ be read (the list can be extended):
+ "regular power-up", "RTC wakeup", "watchdog timeout",
+ "software reset", "reset button action", "CPU clock failure",
+ "crystal oscillator failure", "brown-out reset",
+ "unknown reason".
+
+ The file is read only.
diff --git a/Documentation/ABI/testing/sysfs-platform-silicom b/Documentation/ABI/testing/sysfs-platform-silicom
new file mode 100644
index 000000000000..4d1cc5bdbcc5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-silicom
@@ -0,0 +1,30 @@
+What: /sys/devices/platform/silicom-platform/uc_version
+Date: November 2023
+KernelVersion: 6.7
+Contact: Henry Shi <henrys@silicom-usa.com>
+Description:
+ This file allows to read microcontroller firmware
+ version of current platform.
+
+What: /sys/devices/platform/silicom-platform/power_cycle
+Date: November 2023
+KernelVersion: 6.7
+Contact: Henry Shi <henrys@silicom-usa.com>
+Description:
+ This file allow user to power cycle the platform.
+ Default value is 0; when set to 1, it powers down
+ the platform, waits 5 seconds, then powers on the
+ device. It returns to default value after power cycle.
+
+ 0 - default value.
+
+What: /sys/devices/platform/silicom-platform/efuse_status
+Date: November 2023
+KernelVersion: 6.7
+Contact: Henry Shi <henrys@silicom-usa.com>
+Description:
+ This file is read only. It returns the current
+ OTP status:
+
+ 0 - not programmed.
+ 1 - programmed.
diff --git a/Documentation/ABI/testing/sysfs-platform-sst-atom b/Documentation/ABI/testing/sysfs-platform-sst-atom
index 0154b0fba759..4bb2e6135c2e 100644
--- a/Documentation/ABI/testing/sysfs-platform-sst-atom
+++ b/Documentation/ABI/testing/sysfs-platform-sst-atom
@@ -4,7 +4,7 @@ KernelVersion: 4.10
Contact: "Sebastien Guiriec" <sebastien.guiriec@intel.com>
Description:
LPE Firmware version for SST driver on all atom
- plaforms (BYT/CHT/Merrifield/BSW).
+ platforms (BYT/CHT/Merrifield/BSW).
If the FW has never been loaded it will display::
"FW not yet loaded"
diff --git a/Documentation/ABI/testing/sysfs-platform_profile b/Documentation/ABI/testing/sysfs-platform_profile
index baf1d125f9f8..125324ab53a9 100644
--- a/Documentation/ABI/testing/sysfs-platform_profile
+++ b/Documentation/ABI/testing/sysfs-platform_profile
@@ -33,3 +33,8 @@ Description: Reading this file gives the current selected profile for this
source such as e.g. a hotkey triggered profile change handled
either directly by the embedded-controller or fully handled
inside the kernel.
+
+ This file may also emit the string 'custom' to indicate
+ that multiple platform profiles drivers are in use but
+ have different values. This string can not be written to
+ this interface and is solely for informational purposes.
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index f99d433ff311..d38da077905a 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -1,6 +1,6 @@
What: /sys/power/
Date: August 2006
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power directory will contain files that will
provide a unified interface to the power management
@@ -8,7 +8,7 @@ Description:
What: /sys/power/state
Date: November 2016
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/state file controls system sleep states.
Reading from this file returns the available sleep state
@@ -23,7 +23,7 @@ Description:
What: /sys/power/mem_sleep
Date: November 2016
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/mem_sleep file controls the operating mode of
system suspend. Reading from it returns the available modes
@@ -41,7 +41,7 @@ Description:
What: /sys/power/disk
Date: September 2006
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/disk file controls the operating mode of the
suspend-to-disk mechanism. Reading from this file returns
@@ -90,7 +90,7 @@ Description:
What: /sys/power/image_size
Date: August 2006
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/image_size file controls the size of the image
created by the suspend-to-disk mechanism. It can be written a
@@ -107,7 +107,7 @@ Description:
What: /sys/power/pm_trace
Date: August 2006
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/pm_trace file controls the code which saves the
last PM event point in the RTC across reboots, so that you can
@@ -131,7 +131,7 @@ Description:
CAUTION: Using it will cause your machine's real-time (CMOS)
clock to be set to a random invalid time after a resume.
-What; /sys/power/pm_trace_dev_match
+What: /sys/power/pm_trace_dev_match
Date: October 2010
Contact: James Hogan <jhogan@kernel.org>
Description:
@@ -156,7 +156,7 @@ Description:
What: /sys/power/pm_async
Date: January 2009
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/pm_async file controls the switch allowing the
user space to enable or disable asynchronous suspend and resume
@@ -169,7 +169,7 @@ Description:
What: /sys/power/wakeup_count
Date: July 2010
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/wakeup_count file allows user space to put the
system into a sleep state while taking into account the
@@ -184,7 +184,7 @@ Description:
What: /sys/power/reserved_size
Date: May 2011
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/reserved_size file allows user space to control
the amount of memory reserved for allocations made by device
@@ -198,7 +198,7 @@ Description:
What: /sys/power/autosleep
Date: April 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/autosleep file can be written one of the strings
returned by reads from /sys/power/state. If that happens, a
@@ -215,7 +215,7 @@ Description:
What: /sys/power/wake_lock
Date: February 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/wake_lock file allows user space to create
wakeup source objects and activate them on demand (if one of
@@ -242,7 +242,7 @@ Description:
What: /sys/power/wake_unlock
Date: February 2012
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/wake_unlock file allows user space to deactivate
wakeup sources created with the help of /sys/power/wake_lock.
@@ -283,7 +283,7 @@ Description:
What: /sys/power/pm_debug_messages
Date: July 2017
-Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
+Contact: Rafael J. Wysocki <rafael@kernel.org>
Description:
The /sys/power/pm_debug_messages file controls the printing
of debug messages from the system suspend/hiberbation
@@ -413,6 +413,35 @@ Description:
The /sys/power/suspend_stats/last_failed_step file contains
the last failed step in the suspend/resume path.
+What: /sys/power/suspend_stats/last_hw_sleep
+Date: June 2023
+Contact: Mario Limonciello <mario.limonciello@amd.com>
+Description:
+ The /sys/power/suspend_stats/last_hw_sleep file
+ contains the duration of time spent in a hardware sleep
+ state in the most recent system suspend-resume cycle.
+ This number is measured in microseconds.
+
+What: /sys/power/suspend_stats/total_hw_sleep
+Date: June 2023
+Contact: Mario Limonciello <mario.limonciello@amd.com>
+Description:
+ The /sys/power/suspend_stats/total_hw_sleep file
+ contains the aggregate of time spent in a hardware sleep
+ state since the kernel was booted. This number
+ is measured in microseconds.
+
+What: /sys/power/suspend_stats/max_hw_sleep
+Date: June 2023
+Contact: Mario Limonciello <mario.limonciello@amd.com>
+Description:
+ The /sys/power/suspend_stats/max_hw_sleep file
+ contains the maximum amount of time that the hardware can
+ report for time spent in a hardware sleep state. When sleep
+ cycles are longer than this time, the values for
+ 'total_hw_sleep' and 'last_hw_sleep' may not be accurate.
+ This number is measured in microseconds.
+
What: /sys/power/sync_on_suspend
Date: October 2019
Contact: Jonas Meurer <jonas@freesources.org>
@@ -425,3 +454,19 @@ Description:
disables it. Reads from the file return the current value.
The default is "1" if the build-time "SUSPEND_SKIP_SYNC" config
flag is unset, or "0" otherwise.
+
+What: /sys/power/hibernate_compression_threads
+Date: October 2025
+Contact: <luoxueqin@kylinos.cn>
+Description:
+ Controls the number of threads used for compression
+ and decompression of hibernation images.
+
+ The value can be adjusted at runtime to balance
+ performance and CPU utilization.
+
+ The change takes effect on the next hibernation or
+ resume operation.
+
+ Minimum value: 1
+ Default value: 3
diff --git a/Documentation/ABI/testing/sysfs-pps-gen b/Documentation/ABI/testing/sysfs-pps-gen
new file mode 100644
index 000000000000..2519207b88fd
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-pps-gen
@@ -0,0 +1,43 @@
+What: /sys/class/pps-gen/
+Date: February 2025
+KernelVersion: 6.13
+Contact: Rodolfo Giometti <giometti@enneenne.com>
+Description:
+ The /sys/class/pps-gen/ directory contains files and
+ directories that provide a unified interface to the PPS
+ generators.
+
+What: /sys/class/pps-gen/pps-genX/
+Date: February 2025
+KernelVersion: 6.13
+Contact: Rodolfo Giometti <giometti@enneenne.com>
+Description:
+ The /sys/class/pps-gen/pps-genX/ directory is related to X-th
+ PPS generator in the system. Each directory contain files to
+ manage and control its PPS generator.
+
+What: /sys/class/pps-gen/pps-genX/enable
+Date: February 2025
+KernelVersion: 6.13
+Contact: Rodolfo Giometti <giometti@enneenne.com>
+Description:
+ This write-only file enables or disables generation of the
+ PPS signal.
+
+What: /sys/class/pps-gen/pps-genX/system
+Date: February 2025
+KernelVersion: 6.13
+Contact: Rodolfo Giometti <giometti@enneenne.com>
+Description:
+ This read-only file returns "1" if the generator takes the
+ timing from the system clock, while it returns "0" if not
+ (i.e. from a peripheral device clock).
+
+What: /sys/class/pps-gen/pps-genX/time
+Date: February 2025
+KernelVersion: 6.13
+Contact: Rodolfo Giometti <giometti@enneenne.com>
+Description:
+ This read-only file contains the current time stored into the
+ generator clock as two integers representing the current time
+ seconds and nanoseconds.
diff --git a/Documentation/ABI/testing/sysfs-pps-gen-tio b/Documentation/ABI/testing/sysfs-pps-gen-tio
new file mode 100644
index 000000000000..3c34ff17a335
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-pps-gen-tio
@@ -0,0 +1,6 @@
+What: /sys/class/pps-gen/pps-genx/enable
+Date: April 2025
+KernelVersion: 6.15
+Contact: Subramanian Mohan<subramanian.mohan@intel.com>
+Description:
+ Enable or disable PPS TIO generator output.
diff --git a/Documentation/ABI/testing/sysfs-secvar b/Documentation/ABI/testing/sysfs-secvar
index feebb8c57294..1016967a730f 100644
--- a/Documentation/ABI/testing/sysfs-secvar
+++ b/Documentation/ABI/testing/sysfs-secvar
@@ -18,6 +18,18 @@ Description: A string indicating which backend is in use by the firmware.
This determines the format of the variable and the accepted
format of variable updates.
+ On powernv/OPAL, this value is provided by the OPAL firmware
+ and is expected to be "ibm,edk2-compat-v1".
+
+ On pseries/PLPKS, this is generated by the kernel based on the
+ version number in the SB_VERSION variable in the keystore. The
+ version numbering in the SB_VERSION variable starts from 1. The
+ format string takes the form "ibm,plpks-sb-v<version>" in the
+ case of dynamic key management mode. If the SB_VERSION variable
+ does not exist (or there is an error while reading it), it takes
+ the form "ibm,plpks-sb-v0", indicating that the key management
+ mode is static.
+
What: /sys/firmware/secvar/vars/<variable name>
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
@@ -26,6 +38,13 @@ Description: Each secure variable is represented as a directory named as
representation. The data and size can be determined by reading
their respective attribute files.
+ Only secvars relevant to the key management mode are exposed.
+ Only in the dynamic key management mode should the user have
+ access (read and write) to the secure boot secvars db, dbx,
+ grubdb, grubdbx, and sbat. These secvars are not consumed in the
+ static key management mode. PK, trustedcadb and moduledb are the
+ secvars common to both static and dynamic key management modes.
+
What: /sys/firmware/secvar/vars/<variable_name>/size
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
@@ -34,7 +53,7 @@ Description: An integer representation of the size of the content of the
What: /sys/firmware/secvar/vars/<variable_name>/data
Date: August 2019
-Contact: Nayna Jain h<nayna@linux.ibm.com>
+Contact: Nayna Jain <nayna@linux.ibm.com>
Description: A read-only file containing the value of the variable. The size
of the file represents the maximum size of the variable data.
@@ -44,3 +63,68 @@ Contact: Nayna Jain <nayna@linux.ibm.com>
Description: A write-only file that is used to submit the new value for the
variable. The size of the file represents the maximum size of
the variable data that can be written.
+
+What: /sys/firmware/secvar/config
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: This optional directory contains read-only config attributes as
+ defined by the secure variable implementation. All data is in
+ ASCII format. The directory is only created if the backing
+ implementation provides variables to populate it, which at
+ present is only PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/version
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Config version as reported by the hypervisor in ASCII decimal
+ format.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/max_object_size
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Maximum allowed size of objects in the keystore in bytes,
+ represented in ASCII decimal format.
+
+ This is not necessarily the same as the max size that can be
+ written to an update file as writes can contain more than
+ object data, you should use the size of the update file for
+ that purpose.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/total_size
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Total size of the PLPKS in bytes, represented in ASCII decimal
+ format.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/used_space
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Current space consumed by the key store, in bytes, represented
+ in ASCII decimal format.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/supported_policies
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Bitmask of supported policy flags by the hypervisor,
+ represented as an 8 byte hexadecimal ASCII string. Consult the
+ hypervisor documentation for what these flags are.
+
+ Currently only provided by PLPKS on the pseries platform.
+
+What: /sys/firmware/secvar/config/signed_update_algorithms
+Date: February 2023
+Contact: Nayna Jain <nayna@linux.ibm.com>
+Description: Bitmask of flags indicating which algorithms the hypervisor
+ supports for signed update of objects, represented as a 16 byte
+ hexadecimal ASCII string. Consult the hypervisor documentation
+ for what these flags mean.
+
+ Currently only provided by PLPKS on the pseries platform.
diff --git a/Documentation/ABI/testing/sysfs-timecard b/Documentation/ABI/testing/sysfs-timecard
index 220478156297..3ae41b7634ac 100644
--- a/Documentation/ABI/testing/sysfs-timecard
+++ b/Documentation/ABI/testing/sysfs-timecard
@@ -258,24 +258,29 @@ Description: (RW) When retrieving the PHC with the PTP SYS_OFFSET_EXTENDED
the estimated point where the FPGA latches the PHC time. This
value may be changed by writing an unsigned integer.
-What: /sys/class/timecard/ocpN/ttyGNSS
-What: /sys/class/timecard/ocpN/ttyGNSS2
-Date: September 2021
+What: /sys/class/timecard/ocpN/tty
+Date: August 2024
+Contact: Vadim Fedorenko <vadim.fedorenko@linux.dev>
+Description: (RO) Directory containing the sysfs nodes for TTY attributes
+
+What: /sys/class/timecard/ocpN/tty/ttyGNSS
+What: /sys/class/timecard/ocpN/tty/ttyGNSS2
+Date: August 2024
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
-Description: These optional attributes link to the TTY serial ports
- associated with the GNSS devices.
+Description: (RO) These optional attributes contain names of the TTY serial
+ ports associated with the GNSS devices.
-What: /sys/class/timecard/ocpN/ttyMAC
-Date: September 2021
+What: /sys/class/timecard/ocpN/tty/ttyMAC
+Date: August 2024
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
-Description: This optional attribute links to the TTY serial port
- associated with the Miniature Atomic Clock.
+Description: (RO) This optional attribute contains name of the TTY serial
+ port associated with the Miniature Atomic Clock.
-What: /sys/class/timecard/ocpN/ttyNMEA
-Date: September 2021
+What: /sys/class/timecard/ocpN/tty/ttyNMEA
+Date: August 2024
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
-Description: This optional attribute links to the TTY serial port
- which outputs the PHC time in NMEA ZDA format.
+Description: (RO) This optional attribute contains name of the TTY serial
+ port which outputs the PHC time in NMEA ZDA format.
What: /sys/class/timecard/ocpN/utc_tai_offset
Date: September 2021
diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty
index 820e412d38a8..895c47f05f6f 100644
--- a/Documentation/ABI/testing/sysfs-tty
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -87,19 +87,22 @@ What: /sys/class/tty/ttyS<x>/close_delay
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
- Show the closing delay time for this port in ms.
+ Show the closing delay time for this port in centiseconds.
- These sysfs values expose the TIOCGSERIAL interface via
- sysfs rather than via ioctls.
+ These sysfs values expose the TIOCGSERIAL interface via
+ sysfs rather than via ioctls.
What: /sys/class/tty/ttyS<x>/closing_wait
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
- Show the close wait time for this port in ms.
+ Show the close wait time for this port in centiseconds.
- These sysfs values expose the TIOCGSERIAL interface via
- sysfs rather than via ioctls.
+ Waiting forever is represented as 0. If waiting on close is
+ disabled then the value is 65535.
+
+ These sysfs values expose the TIOCGSERIAL interface via
+ sysfs rather than via ioctls.
What: /sys/class/tty/ttyS<x>/custom_divisor
Date: October 2012
diff --git a/Documentation/ABI/testing/sysfs-wusb_cbaf b/Documentation/ABI/testing/sysfs-wusb_cbaf
deleted file mode 100644
index 2969d3694ec0..000000000000
--- a/Documentation/ABI/testing/sysfs-wusb_cbaf
+++ /dev/null
@@ -1,101 +0,0 @@
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_*
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Various files for managing Cable Based Association of
- (wireless) USB devices.
-
- The sequence of operations should be:
-
- 1. Device is plugged in.
-
- 2. The connection manager (CM) sees a device with CBA capability.
- (the wusb_chid etc. files in /sys/devices/blah/OURDEVICE).
-
- 3. The CM writes the host name, supported band groups,
- and the CHID (host ID) into the wusb_host_name,
- wusb_host_band_groups and wusb_chid files. These
- get sent to the device and the CDID (if any) for
- this host is requested.
-
- 4. The CM can verify that the device's supported band
- groups (wusb_device_band_groups) are compatible
- with the host.
-
- 5. The CM reads the wusb_cdid file.
-
- 6. The CM looks it up its database.
-
- - If it has a matching CHID,CDID entry, the device
- has been authorized before and nothing further
- needs to be done.
-
- - If the CDID is zero (or the CM doesn't find a
- matching CDID in its database), the device is
- assumed to be not known. The CM may associate
- the host with device by: writing a randomly
- generated CDID to wusb_cdid and then a random CK
- to wusb_ck (this uploads the new CC to the
- device).
-
- CMD may choose to prompt the user before
- associating with a new device.
-
- 7. Device is unplugged.
-
- References:
- [WUSB-AM]
- Association Models Supplement to the
- Certified Wireless Universal Serial Bus
- Specification, version 1.0.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_chid
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The CHID of the host formatted as 16 space-separated
- hex octets.
-
- Writes fetches device's supported band groups and the
- the CDID for any existing association with this host.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_name
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- A friendly name for the host as a UTF-8 encoded string.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_band_groups
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The band groups supported by the host, in the format
- defined in [WUSB-AM].
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_device_band_groups
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The band groups supported by the device, in the format
- defined in [WUSB-AM].
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_cdid
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- The device's CDID formatted as 16 space-separated hex
- octets.
-
-What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_ck
-Date: August 2008
-KernelVersion: 2.6.27
-Contact: David Vrabel <david.vrabel@csr.com>
-Description:
- Write 16 space-separated random, hex octets to
- associate with the device.
diff --git a/Documentation/Kconfig b/Documentation/Kconfig
index 252bfc164dbd..8b6c4b84b218 100644
--- a/Documentation/Kconfig
+++ b/Documentation/Kconfig
@@ -1,6 +1,9 @@
+if COMPILE_TEST
+
+menu "Documentation"
+
config WARN_MISSING_DOCUMENTS
bool "Warn if there's a missing documentation file"
- depends on COMPILE_TEST
help
It is not uncommon that a document gets renamed.
This option makes the Kernel to check for missing dependencies,
@@ -11,12 +14,15 @@ config WARN_MISSING_DOCUMENTS
config WARN_ABI_ERRORS
bool "Warn if there are errors at ABI files"
- depends on COMPILE_TEST
help
The files under Documentation/ABI should follow what's
described at Documentation/ABI/README. Yet, as they're manually
written, it would be possible that some of those files would
have errors that would break them for being parsed by
- scripts/get_abi.pl. Add a check to verify them.
+ tools/docs/get_abi.py. Add a check to verify them.
If unsure, select 'N'.
+
+endmenu
+
+endif
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 64d44c1ecad3..e96ac6dcac4f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -5,14 +5,16 @@
# for cleaning
subdir- := devicetree/bindings
+ifneq ($(MAKECMDGOALS),cleandocs)
# Check for broken documentation file references
ifeq ($(CONFIG_WARN_MISSING_DOCUMENTS),y)
-$(shell $(srctree)/scripts/documentation-file-ref-check --warn)
+$(shell $(srctree)/tools/docs/documentation-file-ref-check --warn)
endif
# Check for broken ABI files
ifeq ($(CONFIG_WARN_ABI_ERRORS),y)
-$(shell $(srctree)/scripts/get_abi.pl validate --dir $(srctree)/Documentation/ABI)
+$(shell $(srctree)/tools/docs/get_abi.py --dir $(srctree)/Documentation/ABI validate)
+endif
endif
# You can set these variables from the command line.
@@ -21,16 +23,21 @@ SPHINXOPTS =
SPHINXDIRS = .
DOCS_THEME =
DOCS_CSS =
-_SPHINXDIRS = $(sort $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst)))
-SPHINX_CONF = conf.py
+RUSTDOC =
PAPER =
BUILDDIR = $(obj)/output
PDFLATEX = xelatex
LATEXOPTS = -interaction=batchmode -no-shell-escape
-ifeq ($(KBUILD_VERBOSE),0)
-SPHINXOPTS += "-q"
-endif
+PYTHONPYCACHEPREFIX ?= $(abspath $(BUILDDIR)/__pycache__)
+
+# Wrapper for sphinx-build
+
+BUILD_WRAPPER = $(srctree)/tools/docs/sphinx-build-wrapper
+
+# For denylisting "variable font" files
+# Can be overridden by setting as an env variable
+FONTS_CONF_DENY_VF ?= $(HOME)/deny-vf
# User-friendly check for sphinx-build
HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi)
@@ -40,109 +47,46 @@ ifeq ($(HAVE_SPHINX),0)
.DEFAULT:
$(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
@echo
- @$(srctree)/scripts/sphinx-pre-install
+ @$(srctree)/tools/docs/sphinx-pre-install
@echo " SKIP Sphinx $@ target."
else # HAVE_SPHINX
-# User-friendly check for pdflatex and latexmk
-HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; else echo 0; fi)
-HAVE_LATEXMK := $(shell if which latexmk >/dev/null 2>&1; then echo 1; else echo 0; fi)
-
-ifeq ($(HAVE_LATEXMK),1)
- PDFLATEX := latexmk -$(PDFLATEX)
-endif #HAVE_LATEXMK
-
-# Internal variables.
-PAPEROPT_a4 = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-KERNELDOC = $(srctree)/scripts/kernel-doc
-KERNELDOC_CONF = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC)
-ALLSPHINXOPTS = $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) $(SPHINXOPTS)
-# the i18n builder cannot share the environment and doctrees with the others
-I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-# commands; the 'cmd' from scripts/Kbuild.include is not *loopable*
-loop_cmd = $(echo-cmd) $(cmd_$(1)) || exit;
-
-# $2 sphinx builder e.g. "html"
-# $3 name of the build subfolder / e.g. "userspace-api/media", used as:
-# * dest folder relative to $(BUILDDIR) and
-# * cache folder relative to $(BUILDDIR)/.doctrees
-# $4 dest subfolder e.g. "man" for man pages at userspace-api/media/man
-# $5 reST source folder relative to $(srctree)/$(src),
-# e.g. "userspace-api/media" for the linux-tv book-set at ./Documentation/userspace-api/media
-
-quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
- cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/userspace-api/media $2 && \
- PYTHONDONTWRITEBYTECODE=1 \
- BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
- $(PYTHON3) $(srctree)/scripts/jobserver-exec \
- $(CONFIG_SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \
- $(SPHINXBUILD) \
- -b $2 \
- -c $(abspath $(srctree)/$(src)) \
- -d $(abspath $(BUILDDIR)/.doctrees/$3) \
- -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \
- $(ALLSPHINXOPTS) \
- $(abspath $(srctree)/$(src)/$5) \
- $(abspath $(BUILDDIR)/$3/$4) && \
- if [ "x$(DOCS_CSS)" != "x" ]; then \
- cp $(if $(patsubst /%,,$(DOCS_CSS)),$(abspath $(srctree)/$(DOCS_CSS)),$(DOCS_CSS)) $(BUILDDIR)/$3/_static/; \
- fi
-
-htmldocs:
- @$(srctree)/scripts/sphinx-pre-install --version-check
- @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var)))
-
-linkcheckdocs:
- @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,linkcheck,$(var),,$(var)))
-
-latexdocs:
- @$(srctree)/scripts/sphinx-pre-install --version-check
- @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,latex,$(var),latex,$(var)))
-
-ifeq ($(HAVE_PDFLATEX),0)
-
-pdfdocs:
- $(warning The '$(PDFLATEX)' command was not found. Make sure you have it installed and in PATH to produce PDF output.)
- @echo " SKIP Sphinx $@ target."
-
-else # HAVE_PDFLATEX
-
-pdfdocs: latexdocs
- @$(srctree)/scripts/sphinx-pre-install --version-check
- $(foreach var,$(SPHINXDIRS), \
- $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \
- mkdir -p $(BUILDDIR)/$(var)/pdf; \
- mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \
- )
+# Common documentation targets
+htmldocs mandocs infodocs texinfodocs latexdocs epubdocs xmldocs pdfdocs linkcheckdocs:
+ $(Q)PYTHONPYCACHEPREFIX="$(PYTHONPYCACHEPREFIX)" \
+ $(srctree)/tools/docs/sphinx-pre-install --version-check
+ +$(Q)PYTHONPYCACHEPREFIX="$(PYTHONPYCACHEPREFIX)" \
+ $(PYTHON3) $(BUILD_WRAPPER) $@ \
+ --sphinxdirs="$(SPHINXDIRS)" $(RUSTDOC) \
+ --builddir="$(BUILDDIR)" --deny-vf=$(FONTS_CONF_DENY_VF) \
+ --theme=$(DOCS_THEME) --css=$(DOCS_CSS) --paper=$(PAPER)
-endif # HAVE_PDFLATEX
-epubdocs:
- @$(srctree)/scripts/sphinx-pre-install --version-check
- @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,epub,$(var),epub,$(var)))
-
-xmldocs:
- @$(srctree)/scripts/sphinx-pre-install --version-check
- @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,xml,$(var),xml,$(var)))
-
-endif # HAVE_SPHINX
+endif
# The following targets are independent of HAVE_SPHINX, and the rules should
# work or silently pass without Sphinx.
+htmldocs-redirects: $(srctree)/Documentation/.renames.txt
+ @tools/docs/gen-redirects.py --output $(BUILDDIR) < $<
+
refcheckdocs:
- $(Q)cd $(srctree);scripts/documentation-file-ref-check
+ $(Q)cd $(srctree); tools/docs/documentation-file-ref-check
cleandocs:
$(Q)rm -rf $(BUILDDIR)
- $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/userspace-api/media clean
+
+# Used only on help
+_SPHINXDIRS = $(shell printf "%s\n" $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst)) | sort -f)
dochelp:
@echo ' Linux kernel internal documentation in different formats from ReST:'
@echo ' htmldocs - HTML'
+ @echo ' htmldocs-redirects - generate HTML redirects for moved pages'
+ @echo ' texinfodocs - Texinfo'
+ @echo ' infodocs - Info'
+ @echo ' mandocs - Man pages'
@echo ' latexdocs - LaTeX'
@echo ' pdfdocs - PDF'
@echo ' epubdocs - EPUB'
@@ -154,13 +98,17 @@ dochelp:
@echo ' cleandocs - clean all generated files'
@echo
@echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2'
- @echo ' valid values for SPHINXDIRS are: $(_SPHINXDIRS)'
- @echo
- @echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build'
- @echo ' configuration. This is e.g. useful to build with nit-picking config.'
+ @echo ' top level values for SPHINXDIRS are: $(_SPHINXDIRS)'
+ @echo ' you may also use a subdirectory like SPHINXDIRS=userspace-api/media,'
+ @echo ' provided that there is an index.rst file at the subdirectory.'
@echo
@echo ' make DOCS_THEME={sphinx-theme} selects a different Sphinx theme.'
@echo
@echo ' make DOCS_CSS={a .css file} adds a DOCS_CSS override file for html/epub output.'
@echo
+ @echo ' make PAPER={a4|letter} Specifies the paper size used for LaTeX/PDF output.'
+ @echo
+ @echo ' make FONTS_CONF_DENY_VF={path} sets a deny list to block variable Noto CJK fonts'
+ @echo ' for PDF build. See tools/lib/python/kdoc/latex_fonts.py for more details'
+ @echo
@echo ' Default location for the generated documents is Documentation/output'
diff --git a/Documentation/PCI/boot-interrupts.rst b/Documentation/PCI/boot-interrupts.rst
index 2ec70121bfca..931077bb0953 100644
--- a/Documentation/PCI/boot-interrupts.rst
+++ b/Documentation/PCI/boot-interrupts.rst
@@ -61,7 +61,7 @@ Conditions
==========
The use of threaded interrupts is the most likely condition to trigger
-this problem today. Threaded interrupts may not be reenabled after the IRQ
+this problem today. Threaded interrupts may not be re-enabled after the IRQ
handler wakes. These "one shot" conditions mean that the threaded interrupt
needs to keep the interrupt line masked until the threaded handler has run.
Especially when dealing with high data rate interrupts, the thread needs to
diff --git a/Documentation/PCI/controller/index.rst b/Documentation/PCI/controller/index.rst
new file mode 100644
index 000000000000..c2ce9ccdcfa0
--- /dev/null
+++ b/Documentation/PCI/controller/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================================
+PCI Native Host Bridge and Endpoint Drivers
+===========================================
+
+.. toctree::
+ :maxdepth: 2
+
+ rcar-pcie-firmware
diff --git a/Documentation/PCI/controller/rcar-pcie-firmware.rst b/Documentation/PCI/controller/rcar-pcie-firmware.rst
new file mode 100644
index 000000000000..67d3bf66e315
--- /dev/null
+++ b/Documentation/PCI/controller/rcar-pcie-firmware.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================================
+Firmware of PCIe controller for Renesas R-Car V4H
+=================================================
+
+Renesas R-Car V4H (r8a779g0) has a PCIe controller, requiring a specific
+firmware download during startup.
+
+However, Renesas currently cannot distribute the firmware free of charge.
+
+The firmware file "104_PCIe_fw_addr_data_ver1.05.txt" (note that the file name
+might be different between different datasheet revisions) can be found in the
+datasheet encoded as text, and as such, the file's content must be converted
+back to binary form. This can be achieved using the following example script:
+
+.. code-block:: sh
+
+ $ awk '/^\s*0x[0-9A-Fa-f]{4}\s+0x[0-9A-Fa-f]{4}/ { print substr($2,5,2) substr($2,3,2) }' \
+ 104_PCIe_fw_addr_data_ver1.05.txt | \
+ xxd -p -r > rcar_gen4_pcie.bin
+
+Once the text content has been converted into a binary firmware file, verify
+its checksum as follows:
+
+.. code-block:: sh
+
+ $ sha1sum rcar_gen4_pcie.bin
+ 1d0bd4b189b4eb009f5d564b1f93a79112994945 rcar_gen4_pcie.bin
+
+The resulting binary file called "rcar_gen4_pcie.bin" should be placed in the
+"/lib/firmware" directory before the driver runs.
diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst
index 4d2333e7ae06..dd1f62e731c9 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -15,6 +15,7 @@ PCI Endpoint Framework
pci-ntb-howto
pci-vntb-function
pci-vntb-howto
+ pci-nvme-function
function/binding/pci-test
function/binding/pci-ntb
diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
index fb73345cfb8a..e69c2872ce3b 100644
--- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
@@ -86,7 +86,7 @@ The <EPF Device> directory can have a list of symbolic links
be created by the user to represent the virtual functions that are bound to
the physical function. In the above directory structure <EPF Device 11> is a
physical function and <EPF Device 31> is a virtual function. An EPF device once
-it's linked to another EPF device, cannot be linked to a EPC device.
+it's linked to another EPF device, cannot be linked to an EPC device.
EPC Device
==========
@@ -108,7 +108,7 @@ entries corresponding to EPC device will be created by the EPC core.
The <EPC Device> directory will have a list of symbolic links to
<EPF Device>. These symbolic links should be created by the user to
represent the functions present in the endpoint device. Only <EPF Device>
-that represents a physical function can be linked to a EPC device.
+that represents a physical function can be linked to an EPC device.
The <EPC Device> directory will also have a *start* field. Once
"1" is written to this field, the endpoint device will be ready to
diff --git a/Documentation/PCI/endpoint/pci-endpoint.rst b/Documentation/PCI/endpoint/pci-endpoint.rst
index 4f5622a65555..0741c8cbd74e 100644
--- a/Documentation/PCI/endpoint/pci-endpoint.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint.rst
@@ -57,11 +57,10 @@ by the PCI controller driver.
The PCI controller driver can then create a new EPC device by invoking
devm_pci_epc_create()/pci_epc_create().
-* devm_pci_epc_destroy()/pci_epc_destroy()
+* pci_epc_destroy()
- The PCI controller driver can destroy the EPC device created by either
- devm_pci_epc_create() or pci_epc_create() using devm_pci_epc_destroy() or
- pci_epc_destroy().
+ The PCI controller driver can destroy the EPC device created by
+ pci_epc_create() using pci_epc_destroy().
* pci_epc_linkup()
@@ -117,6 +116,35 @@ by the PCI endpoint function driver.
The PCI endpoint function driver should use pci_epc_mem_free_addr() to
free the memory space allocated using pci_epc_mem_alloc_addr().
+* pci_epc_map_addr()
+
+ A PCI endpoint function driver should use pci_epc_map_addr() to map to a RC
+ PCI address the CPU address of local memory obtained with
+ pci_epc_mem_alloc_addr().
+
+* pci_epc_unmap_addr()
+
+ A PCI endpoint function driver should use pci_epc_unmap_addr() to unmap the
+ CPU address of local memory mapped to a RC address with pci_epc_map_addr().
+
+* pci_epc_mem_map()
+
+ A PCI endpoint controller may impose constraints on the RC PCI addresses that
+ can be mapped. The function pci_epc_mem_map() allows endpoint function
+ drivers to allocate and map controller memory while handling such
+ constraints. This function will determine the size of the memory that must be
+ allocated with pci_epc_mem_alloc_addr() for successfully mapping a RC PCI
+ address range. This function will also indicate the size of the PCI address
+ range that was actually mapped, which can be less than the requested size, as
+ well as the offset into the allocated memory to use for accessing the mapped
+ RC PCI address range.
+
+* pci_epc_mem_unmap()
+
+ A PCI endpoint function driver can use pci_epc_mem_unmap() to unmap and free
+ controller memory that was allocated and mapped using pci_epc_mem_map().
+
+
Other EPC APIs
~~~~~~~~~~~~~~
@@ -169,11 +197,11 @@ by the PCI endpoint function driver.
* pci_epf_register_driver()
The PCI Endpoint Function driver should implement the following ops:
- * bind: ops to perform when a EPC device has been bound to EPF device
- * unbind: ops to perform when a binding has been lost between a EPC
+ * bind: ops to perform when an EPC device has been bound to EPF device
+ * unbind: ops to perform when a binding has been lost between an EPC
device and EPF device
- * linkup: ops to perform when the EPC device has established a
- connection with a host system
+ * add_cfs: optional ops to create function specific configfs
+ attributes
The PCI Function driver can then register the PCI EPF driver by using
pci_epf_register_driver().
@@ -223,7 +251,7 @@ pci-ep-cfs.c can be used as reference for using these APIs.
* pci_epf_bind()
pci_epf_bind() should be invoked when the EPF device has been bound to
- a EPC device.
+ an EPC device.
* pci_epf_unbind()
diff --git a/Documentation/PCI/endpoint/pci-ntb-howto.rst b/Documentation/PCI/endpoint/pci-ntb-howto.rst
index 1884bf29caba..4261e7157ef1 100644
--- a/Documentation/PCI/endpoint/pci-ntb-howto.rst
+++ b/Documentation/PCI/endpoint/pci-ntb-howto.rst
@@ -88,13 +88,10 @@ commands can be used::
# echo 0x104c > functions/pci_epf_ntb/func1/vendorid
# echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
-In order to configure NTB specific attributes, a new sub-directory to func1
-should be created::
-
- # mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
-
-The NTB function driver will populate this directory with various attributes
-that can be configured by the user::
+The PCI endpoint framework also automatically creates a sub-directory in the
+function attribute directory. This sub-directory has the same name as the name
+of the function device and is populated with the following NTB specific
+attributes that can be configured by the user::
# ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
db_count mw1 mw2 mw3 mw4 num_mws
diff --git a/Documentation/PCI/endpoint/pci-nvme-function.rst b/Documentation/PCI/endpoint/pci-nvme-function.rst
new file mode 100644
index 000000000000..a68015317f7f
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-nvme-function.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+PCI NVMe Function
+=================
+
+:Author: Damien Le Moal <dlemoal@kernel.org>
+
+The PCI NVMe endpoint function implements a PCI NVMe controller using the NVMe
+subsystem target core code. The driver for this function resides with the NVMe
+subsystem as drivers/nvme/target/pci-epf.c.
+
+See Documentation/nvme/nvme-pci-endpoint-target.rst for more details.
diff --git a/Documentation/PCI/endpoint/pci-test-howto.rst b/Documentation/PCI/endpoint/pci-test-howto.rst
index 909f770a07d6..dd66858cde46 100644
--- a/Documentation/PCI/endpoint/pci-test-howto.rst
+++ b/Documentation/PCI/endpoint/pci-test-howto.rst
@@ -81,8 +81,8 @@ device, the following commands can be used::
# echo 0x104c > functions/pci_epf_test/func1/vendorid
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
- # echo 16 > functions/pci_epf_test/func1/msi_interrupts
- # echo 8 > functions/pci_epf_test/func1/msix_interrupts
+ # echo 32 > functions/pci_epf_test/func1/msi_interrupts
+ # echo 2048 > functions/pci_epf_test/func1/msix_interrupts
Binding pci-epf-test Device to EP Controller
@@ -123,113 +123,98 @@ above::
Using Endpoint Test function Device
-----------------------------------
-pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
-tests. To compile this tool the following commands should be used::
+Kselftest added in tools/testing/selftests/pci_endpoint can be used to run all
+the default PCI endpoint tests. To build the Kselftest for PCI endpoint
+subsystem, the following commands should be used::
# cd <kernel-dir>
- # make -C tools/pci
+ # make -C tools/testing/selftests/pci_endpoint
or if you desire to compile and install in your system::
# cd <kernel-dir>
- # make -C tools/pci install
+ # make -C tools/testing/selftests/pci_endpoint INSTALL_PATH=/usr/bin install
-The tool and script will be located in <rootfs>/usr/bin/
+The test will be located in <rootfs>/usr/bin/
-
-pcitest.sh Output
-~~~~~~~~~~~~~~~~~
+Kselftest Output
+~~~~~~~~~~~~~~~~
::
- # pcitest.sh
- BAR tests
-
- BAR0: OKAY
- BAR1: OKAY
- BAR2: OKAY
- BAR3: OKAY
- BAR4: NOT OKAY
- BAR5: NOT OKAY
-
- Interrupt tests
-
- SET IRQ TYPE TO LEGACY: OKAY
- LEGACY IRQ: NOT OKAY
- SET IRQ TYPE TO MSI: OKAY
- MSI1: OKAY
- MSI2: OKAY
- MSI3: OKAY
- MSI4: OKAY
- MSI5: OKAY
- MSI6: OKAY
- MSI7: OKAY
- MSI8: OKAY
- MSI9: OKAY
- MSI10: OKAY
- MSI11: OKAY
- MSI12: OKAY
- MSI13: OKAY
- MSI14: OKAY
- MSI15: OKAY
- MSI16: OKAY
- MSI17: NOT OKAY
- MSI18: NOT OKAY
- MSI19: NOT OKAY
- MSI20: NOT OKAY
- MSI21: NOT OKAY
- MSI22: NOT OKAY
- MSI23: NOT OKAY
- MSI24: NOT OKAY
- MSI25: NOT OKAY
- MSI26: NOT OKAY
- MSI27: NOT OKAY
- MSI28: NOT OKAY
- MSI29: NOT OKAY
- MSI30: NOT OKAY
- MSI31: NOT OKAY
- MSI32: NOT OKAY
- SET IRQ TYPE TO MSI-X: OKAY
- MSI-X1: OKAY
- MSI-X2: OKAY
- MSI-X3: OKAY
- MSI-X4: OKAY
- MSI-X5: OKAY
- MSI-X6: OKAY
- MSI-X7: OKAY
- MSI-X8: OKAY
- MSI-X9: NOT OKAY
- MSI-X10: NOT OKAY
- MSI-X11: NOT OKAY
- MSI-X12: NOT OKAY
- MSI-X13: NOT OKAY
- MSI-X14: NOT OKAY
- MSI-X15: NOT OKAY
- MSI-X16: NOT OKAY
- [...]
- MSI-X2047: NOT OKAY
- MSI-X2048: NOT OKAY
-
- Read Tests
-
- SET IRQ TYPE TO MSI: OKAY
- READ ( 1 bytes): OKAY
- READ ( 1024 bytes): OKAY
- READ ( 1025 bytes): OKAY
- READ (1024000 bytes): OKAY
- READ (1024001 bytes): OKAY
-
- Write Tests
-
- WRITE ( 1 bytes): OKAY
- WRITE ( 1024 bytes): OKAY
- WRITE ( 1025 bytes): OKAY
- WRITE (1024000 bytes): OKAY
- WRITE (1024001 bytes): OKAY
-
- Copy Tests
-
- COPY ( 1 bytes): OKAY
- COPY ( 1024 bytes): OKAY
- COPY ( 1025 bytes): OKAY
- COPY (1024000 bytes): OKAY
- COPY (1024001 bytes): OKAY
+ # pci_endpoint_test
+ TAP version 13
+ 1..16
+ # Starting 16 tests from 9 test cases.
+ # RUN pci_ep_bar.BAR0.BAR_TEST ...
+ # OK pci_ep_bar.BAR0.BAR_TEST
+ ok 1 pci_ep_bar.BAR0.BAR_TEST
+ # RUN pci_ep_bar.BAR1.BAR_TEST ...
+ # OK pci_ep_bar.BAR1.BAR_TEST
+ ok 2 pci_ep_bar.BAR1.BAR_TEST
+ # RUN pci_ep_bar.BAR2.BAR_TEST ...
+ # OK pci_ep_bar.BAR2.BAR_TEST
+ ok 3 pci_ep_bar.BAR2.BAR_TEST
+ # RUN pci_ep_bar.BAR3.BAR_TEST ...
+ # OK pci_ep_bar.BAR3.BAR_TEST
+ ok 4 pci_ep_bar.BAR3.BAR_TEST
+ # RUN pci_ep_bar.BAR4.BAR_TEST ...
+ # OK pci_ep_bar.BAR4.BAR_TEST
+ ok 5 pci_ep_bar.BAR4.BAR_TEST
+ # RUN pci_ep_bar.BAR5.BAR_TEST ...
+ # OK pci_ep_bar.BAR5.BAR_TEST
+ ok 6 pci_ep_bar.BAR5.BAR_TEST
+ # RUN pci_ep_basic.CONSECUTIVE_BAR_TEST ...
+ # OK pci_ep_basic.CONSECUTIVE_BAR_TEST
+ ok 7 pci_ep_basic.CONSECUTIVE_BAR_TEST
+ # RUN pci_ep_basic.LEGACY_IRQ_TEST ...
+ # OK pci_ep_basic.LEGACY_IRQ_TEST
+ ok 8 pci_ep_basic.LEGACY_IRQ_TEST
+ # RUN pci_ep_basic.MSI_TEST ...
+ # OK pci_ep_basic.MSI_TEST
+ ok 9 pci_ep_basic.MSI_TEST
+ # RUN pci_ep_basic.MSIX_TEST ...
+ # OK pci_ep_basic.MSIX_TEST
+ ok 10 pci_ep_basic.MSIX_TEST
+ # RUN pci_ep_data_transfer.memcpy.READ_TEST ...
+ # OK pci_ep_data_transfer.memcpy.READ_TEST
+ ok 11 pci_ep_data_transfer.memcpy.READ_TEST
+ # RUN pci_ep_data_transfer.memcpy.WRITE_TEST ...
+ # OK pci_ep_data_transfer.memcpy.WRITE_TEST
+ ok 12 pci_ep_data_transfer.memcpy.WRITE_TEST
+ # RUN pci_ep_data_transfer.memcpy.COPY_TEST ...
+ # OK pci_ep_data_transfer.memcpy.COPY_TEST
+ ok 13 pci_ep_data_transfer.memcpy.COPY_TEST
+ # RUN pci_ep_data_transfer.dma.READ_TEST ...
+ # OK pci_ep_data_transfer.dma.READ_TEST
+ ok 14 pci_ep_data_transfer.dma.READ_TEST
+ # RUN pci_ep_data_transfer.dma.WRITE_TEST ...
+ # OK pci_ep_data_transfer.dma.WRITE_TEST
+ ok 15 pci_ep_data_transfer.dma.WRITE_TEST
+ # RUN pci_ep_data_transfer.dma.COPY_TEST ...
+ # OK pci_ep_data_transfer.dma.COPY_TEST
+ ok 16 pci_ep_data_transfer.dma.COPY_TEST
+ # PASSED: 16 / 16 tests passed.
+ # Totals: pass:16 fail:0 xfail:0 xpass:0 skip:0 error:0
+
+
+Testcase 16 (pci_ep_data_transfer.dma.COPY_TEST) will fail for most of the DMA
+capable endpoint controllers due to the absence of the MEMCPY over DMA. For such
+controllers, it is advisable to skip this testcase using this
+command::
+
+ # pci_endpoint_test -f pci_ep_bar -f pci_ep_basic -v memcpy -T COPY_TEST -v dma
+
+Kselftest EP Doorbell
+~~~~~~~~~~~~~~~~~~~~~
+
+If the Endpoint MSI controller is used for the doorbell usecase, run below
+command for testing it:
+
+ # pci_endpoint_test -f pcie_ep_doorbell
+
+ # Starting 1 tests from 1 test cases.
+ # RUN pcie_ep_doorbell.DOORBELL_TEST ...
+ # OK pcie_ep_doorbell.DOORBELL_TEST
+ ok 1 pcie_ep_doorbell.DOORBELL_TEST
+ # PASSED: 1 / 1 tests passed.
+ # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
diff --git a/Documentation/PCI/endpoint/pci-vntb-howto.rst b/Documentation/PCI/endpoint/pci-vntb-howto.rst
index 4ab8e4a26d4b..9a7a2f0a6849 100644
--- a/Documentation/PCI/endpoint/pci-vntb-howto.rst
+++ b/Documentation/PCI/endpoint/pci-vntb-howto.rst
@@ -84,17 +84,15 @@ commands can be used::
# echo 0x1957 > functions/pci_epf_vntb/func1/vendorid
# echo 0x0809 > functions/pci_epf_vntb/func1/deviceid
-In order to configure NTB specific attributes, a new sub-directory to func1
-should be created::
-
- # mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/
-
-The NTB function driver will populate this directory with various attributes
-that can be configured by the user::
+The PCI endpoint framework also automatically creates a sub-directory in the
+function attribute directory. This sub-directory has the same name as the name
+of the function device and is populated with the following NTB specific
+attributes that can be configured by the user::
# ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/
- db_count mw1 mw2 mw3 mw4 num_mws
- spad_count
+ ctrl_bar db_count mw1_bar mw2_bar mw3_bar mw4_bar spad_count
+ db_bar mw1 mw2 mw3 mw4 num_mws vbus_number
+ vntb_vid vntb_pid
A sample configuration for NTB function is given below::
@@ -103,7 +101,11 @@ A sample configuration for NTB function is given below::
# echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws
# echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1
-A sample configuration for virtual NTB driver for virutal PCI bus::
+By default, each construct is assigned a BAR, as needed and in order.
+Should a specific BAR setup be required by the platform, BAR may be assigned
+to each construct using the related ``XYZ_bar`` entry.
+
+A sample configuration for virtual NTB driver for virtual PCI bus::
# echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid
# echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid
diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
index c17c87af1968..5d720d2a415e 100644
--- a/Documentation/PCI/index.rst
+++ b/Documentation/PCI/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-=======================
-Linux PCI Bus Subsystem
-=======================
+=================
+PCI Bus Subsystem
+=================
.. toctree::
:maxdepth: 2
@@ -17,4 +17,6 @@ Linux PCI Bus Subsystem
pci-error-recovery
pcieaer-howto
endpoint/index
+ controller/index
boot-interrupts
+ tph
diff --git a/Documentation/PCI/msi-howto.rst b/Documentation/PCI/msi-howto.rst
index aa2046af69f7..0692c9aec66f 100644
--- a/Documentation/PCI/msi-howto.rst
+++ b/Documentation/PCI/msi-howto.rst
@@ -103,7 +103,7 @@ min_vecs argument set to this limit, and the PCI core will return -ENOSPC
if it can't meet the minimum number of vectors.
The flags argument is used to specify which type of interrupt can be used
-by the device and the driver (PCI_IRQ_LEGACY, PCI_IRQ_MSI, PCI_IRQ_MSIX).
+by the device and the driver (PCI_IRQ_INTX, PCI_IRQ_MSI, PCI_IRQ_MSIX).
A convenient short-hand (PCI_IRQ_ALL_TYPES) is also available to ask for
any possible kind of interrupt. If the PCI_IRQ_AFFINITY flag is set,
pci_alloc_irq_vectors() will spread the interrupts around the available CPUs.
@@ -236,7 +236,7 @@ including a full 'lspci -v' so we can add the quirks to the kernel.
Disabling MSIs below a bridge
-----------------------------
-Some PCI bridges are not able to route MSIs between busses properly.
+Some PCI bridges are not able to route MSIs between buses properly.
In this case, MSIs must be disabled on all devices behind the bridge.
Some bridges allow you to enable MSIs by changing some bits in their
@@ -285,3 +285,13 @@ to bridges between the PCI root and the device, MSIs are disabled.
It is also worth checking the device driver to see whether it supports MSIs.
For example, it may contain calls to pci_alloc_irq_vectors() with the
PCI_IRQ_MSI or PCI_IRQ_MSIX flags.
+
+
+List of device drivers MSI(-X) APIs
+===================================
+
+The PCI/MSI subsystem has a dedicated C file for its exported device driver
+APIs — `drivers/pci/msi/api.c`. The following functions are exported:
+
+.. kernel-doc:: drivers/pci/msi/api.c
+ :export:
diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
index 187f43a03200..43bc4e3665b4 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -13,11 +13,11 @@ PCI Error Recovery
Many PCI bus controllers are able to detect a variety of hardware
PCI errors on the bus, such as parity errors on the data and address
buses, as well as SERR and PERR errors. Some of the more advanced
-chipsets are able to deal with these errors; these include PCI-E chipsets,
+chipsets are able to deal with these errors; these include PCIe chipsets,
and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
pSeries boxes. A typical action taken is to disconnect the affected device,
halting all I/O to it. The goal of a disconnection is to avoid system
-corruption; for example, to halt system memory corruption due to DMA's
+corruption; for example, to halt system memory corruption due to DMAs
to "wild" addresses. Typically, a reconnection mechanism is also
offered, so that the affected PCI device(s) are reset and put back
into working condition. The reset phase requires coordination
@@ -83,6 +83,7 @@ This structure has the form::
int (*mmio_enabled)(struct pci_dev *dev);
int (*slot_reset)(struct pci_dev *dev);
void (*resume)(struct pci_dev *dev);
+ void (*cor_error_detected)(struct pci_dev *dev);
};
The possible channel states are::
@@ -107,8 +108,8 @@ A driver does not have to implement all of these callbacks; however,
if it implements any, it must implement error_detected(). If a callback
is not implemented, the corresponding feature is considered unsupported.
For example, if mmio_enabled() and resume() aren't there, then it
-is assumed that the driver is not doing any direct recovery and requires
-a slot reset. Typically a driver will want to know about
+is assumed that the driver does not need these callbacks
+for recovery. Typically a driver will want to know about
a slot_reset().
The actual steps taken by a platform to recover from a PCI error
@@ -121,6 +122,10 @@ A PCI bus error is detected by the PCI hardware. On powerpc, the slot
is isolated, in that all I/O is blocked: all reads return 0xffffffff,
all writes are ignored.
+Similarly, on platforms supporting Downstream Port Containment
+(PCIe r7.0 sec 6.2.11), the link to the sub-hierarchy with the
+faulting device is disabled. Any device in the sub-hierarchy
+becomes inaccessible.
STEP 1: Notification
--------------------
@@ -140,6 +145,9 @@ shouldn't do any new IOs. Called in task context. This is sort of a
All drivers participating in this system must implement this call.
The driver must return one of the following result codes:
+ - PCI_ERS_RESULT_RECOVERED
+ Driver returns this if it thinks the device is usable despite
+ the error and does not need further intervention.
- PCI_ERS_RESULT_CAN_RECOVER
Driver returns this if it thinks it might be able to recover
the HW by just banging IOs or if it wants to be given
@@ -177,9 +185,9 @@ is STEP 6 (Permanent Failure).
complex and not worth implementing.
The current powerpc implementation doesn't much care if the device
- attempts I/O at this point, or not. I/O's will fail, returning
+ attempts I/O at this point, or not. I/Os will fail, returning
a value of 0xff on read, and writes will be dropped. If more than
- EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH
+ EEH_MAX_FAILS I/Os are attempted to a frozen adapter, EEH
assumes that the device driver has gone into an infinite loop
and prints an error to syslog. A reboot is then required to
get the device working again.
@@ -198,12 +206,30 @@ reset or some such, but not restart operations. This callback is made if
all drivers on a segment agree that they can try to recover and if no automatic
link reset was performed by the HW. If the platform can't just re-enable IOs
without a slot reset or a link reset, it will not call this callback, and
-instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset).
+
+.. note::
+
+ On platforms supporting Advanced Error Reporting (PCIe r7.0 sec 6.2),
+ the faulting device may already be accessible in STEP 1 (Notification).
+ Drivers should nevertheless defer accesses to STEP 2 (MMIO Enabled)
+ to be compatible with EEH on powerpc and with s390 (where devices are
+ inaccessible until STEP 2).
+
+ On platforms supporting Downstream Port Containment, the link to the
+ sub-hierarchy with the faulting device is re-enabled in STEP 3 (Link
+ Reset). Hence devices in the sub-hierarchy are inaccessible until
+ STEP 4 (Slot Reset).
+
+ For errors such as Surprise Down (PCIe r7.0 sec 6.2.7), the device
+ may not even be accessible in STEP 4 (Slot Reset). Drivers can detect
+ accessibility by checking whether reads from the device return all 1's
+ (PCI_POSSIBLE_ERROR()).
.. note::
The following is proposed; no platform implements this yet:
- Proposal: All I/O's should be done _synchronously_ from within
+ Proposal: All I/Os should be done _synchronously_ from within
this callback, errors triggered by them will be returned via
the normal pci_check_whatever() API, no new error_detected()
callback will be issued due to an error happening here. However,
@@ -233,14 +259,14 @@ The driver should return one of the following result codes:
The next step taken depends on the results returned by the drivers.
If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
-proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
+proceeds to either STEP 3 (Link Reset) or to STEP 5 (Resume Operations).
If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
proceeds to STEP 4 (Slot Reset)
STEP 3: Link Reset
------------------
-The platform resets the link. This is a PCI-Express specific step
+The platform resets the link. This is a PCIe specific step
and is done whenever a fatal error has been detected that can be
"solved" by resetting the link.
@@ -257,18 +283,18 @@ Powerpc platforms implement two levels of slot reset:
soft reset(default) and fundamental(optional) reset.
Powerpc soft reset consists of asserting the adapter #RST line and then
-restoring the PCI BAR's and PCI configuration header to a state
+restoring the PCI BARs and PCI configuration header to a state
that is equivalent to what it would be after a fresh system
power-on followed by power-on BIOS/system firmware initialization.
Soft reset is also known as hot-reset.
-Powerpc fundamental reset is supported by PCI Express cards only
+Powerpc fundamental reset is supported by PCIe cards only
and results in device's state machines, hardware logic, port states and
configuration registers to initialize to their default conditions.
For most PCI devices, a soft reset will be sufficient for recovery.
Optional fundamental reset is provided to support a limited number
-of PCI Express devices for which a soft reset is not sufficient
+of PCIe devices for which a soft reset is not sufficient
for recovery.
If the platform supports PCI hotplug, then the reset might be
@@ -300,6 +326,21 @@ be recovered, there is nothing more that can be done; the platform
will typically report a "permanent failure" in such a case. The
device will be considered "dead" in this case.
+Drivers typically need to call pci_restore_state() after reset to
+re-initialize the device's config space registers and thereby
+bring it from D0\ :sub:`uninitialized` into D0\ :sub:`active` state
+(PCIe r7.0 sec 5.3.1.1). The PCI core invokes pci_save_state()
+on enumeration after initializing config space to ensure that a
+saved state is available for subsequent error recovery.
+Drivers which modify config space on probe may need to invoke
+pci_save_state() afterwards to record those changes for later
+error recovery. When going into system suspend, pci_save_state()
+is called for every PCI device and that state will be restored
+not only on resume, but also on any subsequent error recovery.
+In the unlikely event that the saved state recorded on suspend
+is unsuitable for error recovery, drivers should call
+pci_save_state() on resume.
+
Drivers for multi-function cards will need to coordinate among
themselves as to which driver instance will perform any "one-shot"
or global device initialization. For example, the Symbios sym53cxx2
@@ -312,7 +353,7 @@ Result codes:
- PCI_ERS_RESULT_DISCONNECT
Same as above.
-Drivers for PCI Express cards that require a fundamental reset must
+Drivers for PCIe cards that require a fundamental reset must
set the needs_freset bit in the pci_dev structure in their probe function.
For example, the QLogic qla2xxx driver sets the needs_freset bit for certain
PCI card types::
@@ -361,9 +402,9 @@ permanent failure in some way. If the device is hotplug-capable,
the operator will probably want to remove and replace the device.
Note, however, not all failures are truly "permanent". Some are
caused by over-heating, some by a poorly seated card. Many
-PCI error events are caused by software bugs, e.g. DMA's to
+PCI error events are caused by software bugs, e.g. DMAs to
wild addresses or bogus split transactions due to programming
-errors. See the discussion in powerpc/eeh-pci-error-recovery.txt
+errors. See the discussion in Documentation/arch/powerpc/eeh-pci-error-recovery.rst
for additional detail on real-life experience of the causes of
software errors.
@@ -403,7 +444,7 @@ That is, the recovery API only requires that:
.. note::
Implementation details for the powerpc platform are discussed in
- the file Documentation/powerpc/eeh-pci-error-recovery.rst
+ the file Documentation/arch/powerpc/eeh-pci-error-recovery.rst
As of this writing, there is a growing list of device drivers with
patches implementing error recovery. Not all of these patches are in
@@ -417,10 +458,15 @@ That is, the recovery API only requires that:
- drivers/next/e100.c
- drivers/net/e1000
- drivers/net/e1000e
- - drivers/net/ixgb
- drivers/net/ixgbe
- drivers/net/cxgb3
- drivers/net/s2io.c
+ The cor_error_detected() callback is invoked in handle_error_source() when
+ the error severity is "correctable". The callback is optional and allows
+ additional logging to be done if desired. See example:
+
+ - drivers/cxl/pci.c
+
The End
-------
diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst
index cced568d78e9..f4d2662871ab 100644
--- a/Documentation/PCI/pci.rst
+++ b/Documentation/PCI/pci.rst
@@ -52,7 +52,7 @@ driver generally needs to perform the following initialization:
- Enable DMA/processing engines
When done using the device, and perhaps the module needs to be unloaded,
-the driver needs to take the follow steps:
+the driver needs to take the following steps:
- Disable the device from generating IRQs
- Release the IRQ (free_irq())
@@ -335,7 +335,7 @@ causes the PCI support to program CPU vector data into the PCI device
capability registers. Many architectures, chip-sets, or BIOSes do NOT
support MSI or MSI-X and a call to pci_alloc_irq_vectors with just
the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always
-specify PCI_IRQ_LEGACY as well.
+specify PCI_IRQ_INTX as well.
Drivers that have different interrupt handlers for MSI/MSI-X and
legacy INTx should chose the right one based on the msi_enabled
diff --git a/Documentation/PCI/pcieaer-howto.rst b/Documentation/PCI/pcieaer-howto.rst
index 0b36b9ebfa4b..3210c4792978 100644
--- a/Documentation/PCI/pcieaer-howto.rst
+++ b/Documentation/PCI/pcieaer-howto.rst
@@ -16,264 +16,221 @@ Overview
About this guide
----------------
-This guide describes the basics of the PCI Express Advanced Error
+This guide describes the basics of the PCI Express (PCIe) Advanced Error
Reporting (AER) driver and provides information on how to use it, as
-well as how to enable the drivers of endpoint devices to conform with
-PCI Express AER driver.
+well as how to enable the drivers of Endpoint devices to conform with
+the PCIe AER driver.
-What is the PCI Express AER Driver?
------------------------------------
+What is the PCIe AER Driver?
+----------------------------
-PCI Express error signaling can occur on the PCI Express link itself
-or on behalf of transactions initiated on the link. PCI Express
+PCIe error signaling can occur on the PCIe link itself
+or on behalf of transactions initiated on the link. PCIe
defines two error reporting paradigms: the baseline capability and
the Advanced Error Reporting capability. The baseline capability is
-required of all PCI Express components providing a minimum defined
+required of all PCIe components providing a minimum defined
set of error reporting requirements. Advanced Error Reporting
-capability is implemented with a PCI Express advanced error reporting
+capability is implemented with a PCIe Advanced Error Reporting
extended capability structure providing more robust error reporting.
-The PCI Express AER driver provides the infrastructure to support PCI
-Express Advanced Error Reporting capability. The PCI Express AER
-driver provides three basic functions:
+The PCIe AER driver provides the infrastructure to support PCIe Advanced
+Error Reporting capability. The PCIe AER driver provides three basic
+functions:
- Gathers the comprehensive error information if errors occurred.
- Reports error to the users.
- Performs error recovery actions.
-AER driver only attaches root ports which support PCI-Express AER
-capability.
+The AER driver only attaches to Root Ports and RCECs that support the PCIe
+AER capability.
User Guide
==========
-Include the PCI Express AER Root Driver into the Linux Kernel
--------------------------------------------------------------
+Include the PCIe AER Root Driver into the Linux Kernel
+------------------------------------------------------
-The PCI Express AER Root driver is a Root Port service driver attached
-to the PCI Express Port Bus driver. If a user wants to use it, the driver
-has to be compiled. Option CONFIG_PCIEAER supports this capability. It
-depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
-CONFIG_PCIEAER = y.
+The PCIe AER driver is a Root Port service driver attached
+via the PCIe Port Bus driver. If a user wants to use it, the driver
+must be compiled. It is enabled with CONFIG_PCIEAER, which
+depends on CONFIG_PCIEPORTBUS.
-Load PCI Express AER Root Driver
---------------------------------
+Load PCIe AER Root Driver
+-------------------------
Some systems have AER support in firmware. Enabling Linux AER support at
-the same time the firmware handles AER may result in unpredictable
+the same time the firmware handles AER would result in unpredictable
behavior. Therefore, Linux does not handle AER events unless the firmware
-grants AER control to the OS via the ACPI _OSC method. See the PCI FW 3.0
+grants AER control to the OS via the ACPI _OSC method. See the PCI Firmware
Specification for details regarding _OSC usage.
AER error output
----------------
When a PCIe AER error is captured, an error message will be output to
-console. If it's a correctable error, it is output as a warning.
+console. If it's a correctable error, it is output as a warning message.
Otherwise, it is printed as an error. So users could choose different
log level to filter out correctable error messages.
Below shows an example::
- 0000:50:00.0: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, id=0500(Requester ID)
+ 0000:50:00.0: PCIe Bus Error: severity=Uncorrectable (Fatal), type=Transaction Layer, (Requester ID)
0000:50:00.0: device [8086:0329] error status/mask=00100000/00000000
- 0000:50:00.0: [20] Unsupported Request (First)
- 0000:50:00.0: TLP Header: 04000001 00200a03 05010000 00050100
+ 0000:50:00.0: [20] UnsupReq (First)
+ 0000:50:00.0: TLP Header: 0x04000001 0x00200a03 0x05010000 0x00050100
+
+In the example, 'Requester ID' means the ID of the device that sent
+the error message to the Root Port. Please refer to PCIe specs for other
+fields.
+
+AER Ratelimits
+--------------
+
+Since error messages can be generated for each transaction, we may see
+large volumes of errors reported. To prevent spammy devices from flooding
+the console/stalling execution, messages are throttled by device and error
+type (correctable vs. non-fatal uncorrectable). Fatal errors, including
+DPC errors, are not ratelimited.
+
+AER uses the default ratelimit of DEFAULT_RATELIMIT_BURST (10 events) over
+DEFAULT_RATELIMIT_INTERVAL (5 seconds).
-In the example, 'Requester ID' means the ID of the device who sends
-the error message to root port. Pls. refer to pci express specs for
-other fields.
+Ratelimits are exposed in the form of sysfs attributes and configurable.
+See Documentation/ABI/testing/sysfs-bus-pci-devices-aer.
AER Statistics / Counters
-------------------------
When PCIe AER errors are captured, the counters / statistics are also exposed
in the form of sysfs attributes which are documented at
-Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
+Documentation/ABI/testing/sysfs-bus-pci-devices-aer.
Developer Guide
===============
-To enable AER aware support requires a software driver to configure
-the AER capability structure within its device and to provide callbacks.
+To enable error recovery, a software driver must provide callbacks.
-To support AER better, developers need understand how AER does work
-firstly.
+To support AER better, developers need to understand how AER works.
-PCI Express errors are classified into two types: correctable errors
-and uncorrectable errors. This classification is based on the impacts
+PCIe errors are classified into two types: correctable errors
+and uncorrectable errors. This classification is based on the impact
of those errors, which may result in degraded performance or function
failure.
Correctable errors pose no impacts on the functionality of the
-interface. The PCI Express protocol can recover without any software
+interface. The PCIe protocol can recover without any software
intervention or any loss of data. These errors are detected and
-corrected by hardware. Unlike correctable errors, uncorrectable
+corrected by hardware.
+
+Unlike correctable errors, uncorrectable
errors impact functionality of the interface. Uncorrectable errors
-can cause a particular transaction or a particular PCI Express link
+can cause a particular transaction or a particular PCIe link
to be unreliable. Depending on those error conditions, uncorrectable
errors are further classified into non-fatal errors and fatal errors.
Non-fatal errors cause the particular transaction to be unreliable,
-but the PCI Express link itself is fully functional. Fatal errors, on
+but the PCIe link itself is fully functional. Fatal errors, on
the other hand, cause the link to be unreliable.
-When AER is enabled, a PCI Express device will automatically send an
-error message to the PCIe root port above it when the device captures
+When PCIe error reporting is enabled, a device will automatically send an
+error message to the Root Port above it when it captures
an error. The Root Port, upon receiving an error reporting message,
-internally processes and logs the error message in its PCI Express
-capability structure. Error information being logged includes storing
-the error reporting agent's requestor ID into the Error Source
+internally processes and logs the error message in its AER
+Capability structure. Error information being logged includes storing
+the error reporting agent's Requester ID into the Error Source
Identification Registers and setting the error bits of the Root Error
-Status Register accordingly. If AER error reporting is enabled in Root
-Error Command Register, the Root Port generates an interrupt if an
+Status Register accordingly. If AER error reporting is enabled in the Root
+Error Command Register, the Root Port generates an interrupt when an
error is detected.
-Note that the errors as described above are related to the PCI Express
+Note that the errors as described above are related to the PCIe
hierarchy and links. These errors do not include any device specific
errors because device specific errors will still get sent directly to
the device driver.
-Configure the AER capability structure
---------------------------------------
-
-AER aware drivers of PCI Express component need change the device
-control registers to enable AER. They also could change AER registers,
-including mask and severity registers. Helper function
-pci_enable_pcie_error_reporting could be used to enable AER. See
-section 3.3.
-
Provide callbacks
-----------------
-callback reset_link to reset pci express link
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This callback is used to reset the pci express physical link when a
-fatal error happens. The root port aer service driver provides a
-default reset_link function, but different upstream ports might
-have different specifications to reset pci express link, so all
-upstream ports should provide their own reset_link functions.
-
-Section 3.2.2.2 provides more detailed info on when to call
-reset_link.
-
PCI error-recovery callbacks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The PCI Express AER Root driver uses error callbacks to coordinate
+The PCIe AER Root driver uses error callbacks to coordinate
with downstream device drivers associated with a hierarchy in question
when performing error recovery actions.
Data struct pci_driver has a pointer, err_handler, to point to
pci_error_handlers who consists of a couple of callback function
-pointers. AER driver follows the rules defined in
-pci-error-recovery.txt except pci express specific parts (e.g.
-reset_link). Pls. refer to pci-error-recovery.txt for detailed
+pointers. The AER driver follows the rules defined in
+pci-error-recovery.rst except PCIe-specific parts (see
+below). Please refer to pci-error-recovery.rst for detailed
definitions of the callbacks.
-Below sections specify when to call the error callback functions.
+The sections below specify when to call the error callback functions.
Correctable errors
~~~~~~~~~~~~~~~~~~
Correctable errors pose no impacts on the functionality of
-the interface. The PCI Express protocol can recover without any
+the interface. The PCIe protocol can recover without any
software intervention or any loss of data. These errors do not
require any recovery actions. The AER driver clears the device's
correctable error status register accordingly and logs these errors.
-Non-correctable (non-fatal and fatal) errors
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Uncorrectable (non-fatal and fatal) errors
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The AER driver performs a Secondary Bus Reset to recover from
+uncorrectable errors. The reset is applied at the port above
+the originating device: If the originating device is an Endpoint,
+only the Endpoint is reset. If on the other hand the originating
+device has subordinate devices, those are all affected by the
+reset as well.
+
+If the originating device is a Root Complex Integrated Endpoint,
+there's no port above where a Secondary Bus Reset could be applied.
+In this case, the AER driver instead applies a Function Level Reset.
-If an error message indicates a non-fatal error, performing link reset
+If an error message indicates a non-fatal error, performing a reset
at upstream is not required. The AER driver calls error_detected(dev,
pci_channel_io_normal) to all drivers associated within a hierarchy in
-question. for example::
+question. For example::
- EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort
+ Endpoint <==> Downstream Port B <==> Upstream Port A <==> Root Port
-If Upstream port A captures an AER error, the hierarchy consists of
-Downstream port B and EndPoint.
+If Upstream Port A captures an AER error, the hierarchy consists of
+Downstream Port B and Endpoint.
A driver may return PCI_ERS_RESULT_CAN_RECOVER,
PCI_ERS_RESULT_DISCONNECT, or PCI_ERS_RESULT_NEED_RESET, depending on
-whether it can recover or the AER driver calls mmio_enabled as next.
+whether it can recover without a reset, considers the device unrecoverable
+or needs a reset for recovery. If all affected drivers agree that they can
+recover without a reset, it is skipped. Should one driver request a reset,
+it overrides all other drivers.
If an error message indicates a fatal error, kernel will broadcast
error_detected(dev, pci_channel_io_frozen) to all drivers within
-a hierarchy in question. Then, performing link reset at upstream is
-necessary. As different kinds of devices might use different approaches
-to reset link, AER port service driver is required to provide the
-function to reset link via callback parameter of pcie_do_recovery()
-function. If reset_link is not NULL, recovery function will use it
-to reset the link. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER
-and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
-to mmio_enabled.
-
-helper functions
-----------------
-::
-
- int pci_enable_pcie_error_reporting(struct pci_dev *dev);
-
-pci_enable_pcie_error_reporting enables the device to send error
-messages to root port when an error is detected. Note that devices
-don't enable the error reporting by default, so device drivers need
-call this function to enable it.
-
-::
+a hierarchy in question. Then, performing a reset at upstream is
+necessary. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER
+to indicate that recovery without a reset is possible, the error
+handling goes to mmio_enabled, but afterwards a reset is still
+performed.
- int pci_disable_pcie_error_reporting(struct pci_dev *dev);
+In other words, for non-fatal errors, drivers may opt in to a reset.
+But for fatal errors, they cannot opt out of a reset, based on the
+assumption that the link is unreliable.
-pci_disable_pcie_error_reporting disables the device to send error
-messages to root port when an error is detected.
-
-::
-
- int pci_aer_clear_nonfatal_status(struct pci_dev *dev);`
-
-pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable
-error status register.
-
-Frequent Asked Questions
-------------------------
+Frequently Asked Questions
+--------------------------
Q:
- What happens if a PCI Express device driver does not provide an
+ What happens if a PCIe device driver does not provide an
error recovery handler (pci_driver->err_handler is equal to NULL)?
A:
- The devices attached with the driver won't be recovered. If the
- error is fatal, kernel will print out warning messages. Please refer
- to section 3 for more information.
-
-Q:
- What happens if an upstream port service driver does not provide
- callback reset_link?
-
-A:
- Fatal error recovery will fail if the errors are reported by the
- upstream ports who are attached by the service driver.
-
-Q:
- How does this infrastructure deal with driver that is not PCI
- Express aware?
-
-A:
- This infrastructure calls the error callback functions of the
- driver when an error happens. But if the driver is not aware of
- PCI Express, the device might not report its own errors to root
- port.
-
-Q:
- What modifications will that driver need to make it compatible
- with the PCI Express AER Root driver?
-
-A:
- It could call the helper functions to enable AER in devices and
- cleanup uncorrectable status register. Pls. refer to section 3.3.
+ The devices attached with the driver won't be recovered.
+ The kernel will print out informational messages to identify
+ unrecoverable devices.
Software error injection
@@ -294,7 +251,7 @@ After reboot with new kernel or insert the module, a device file named
Then, you need a user space tool named aer-inject, which can be gotten
from:
- https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
+ https://github.com/intel/aer-inject.git
-More information about aer-inject can be found in the document comes
-with its source code.
+More information about aer-inject can be found in the document in
+its source code.
diff --git a/Documentation/PCI/pciebus-howto.rst b/Documentation/PCI/pciebus-howto.rst
index f882ff62c51f..375d9ce171f6 100644
--- a/Documentation/PCI/pciebus-howto.rst
+++ b/Documentation/PCI/pciebus-howto.rst
@@ -139,7 +139,7 @@ driver data structure.
static struct pcie_port_service_driver root_aerdrv = {
.name = (char *)device_name,
- .id_table = &service_id[0],
+ .id_table = service_id,
.probe = aerdrv_load,
.remove = aerdrv_unload,
@@ -213,8 +213,16 @@ PCI Config Registers
--------------------
Each service driver runs its PCI config operations on its own
-capability structure except the PCI Express capability structure, in
-which Root Control register and Device Control register are shared
-between PME and AER. This patch assumes that all service drivers
-will be well behaved and not overwrite other service driver's
-configuration settings.
+capability structure except the PCI Express capability structure,
+that is shared between many drivers including the service drivers.
+RMW Capability accessors (pcie_capability_clear_and_set_word(),
+pcie_capability_set_word(), and pcie_capability_clear_word()) protect
+a selected set of PCI Express Capability Registers:
+
+* Link Control Register
+* Root Control Register
+* Link Control 2 Register
+
+Any change to those registers should be performed using RMW accessors to
+avoid problems due to concurrent updates. For the up-to-date list of
+protected registers, see pcie_capability_clear_and_set_word().
diff --git a/Documentation/PCI/tph.rst b/Documentation/PCI/tph.rst
new file mode 100644
index 000000000000..e8993be64fd6
--- /dev/null
+++ b/Documentation/PCI/tph.rst
@@ -0,0 +1,132 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+===========
+TPH Support
+===========
+
+:Copyright: 2024 Advanced Micro Devices, Inc.
+:Authors: - Eric van Tassell <eric.vantassell@amd.com>
+ - Wei Huang <wei.huang2@amd.com>
+
+
+Overview
+========
+
+TPH (TLP Processing Hints) is a PCIe feature that allows endpoint devices
+to provide optimization hints for requests that target memory space.
+These hints, in a format called Steering Tags (STs), are embedded in the
+requester's TLP headers, enabling the system hardware, such as the Root
+Complex, to better manage platform resources for these requests.
+
+For example, on platforms with TPH-based direct data cache injection
+support, an endpoint device can include appropriate STs in its DMA
+traffic to specify which cache the data should be written to. This allows
+the CPU core to have a higher probability of getting data from cache,
+potentially improving performance and reducing latency in data
+processing.
+
+
+How to Use TPH
+==============
+
+TPH is presented as an optional extended capability in PCIe. The Linux
+kernel handles TPH discovery during boot, but it is up to the device
+driver to request TPH enablement if it is to be utilized. Once enabled,
+the driver uses the provided API to obtain the Steering Tag for the
+target memory and to program the ST into the device's ST table.
+
+Enable TPH support in Linux
+---------------------------
+
+To support TPH, the kernel must be built with the CONFIG_PCIE_TPH option
+enabled.
+
+Manage TPH
+----------
+
+To enable TPH for a device, use the following function::
+
+ int pcie_enable_tph(struct pci_dev *pdev, int mode);
+
+This function enables TPH support for device with a specific ST mode.
+Current supported modes include:
+
+ * PCI_TPH_ST_NS_MODE - NO ST Mode
+ * PCI_TPH_ST_IV_MODE - Interrupt Vector Mode
+ * PCI_TPH_ST_DS_MODE - Device Specific Mode
+
+`pcie_enable_tph()` checks whether the requested mode is actually
+supported by the device before enabling. The device driver can figure out
+which TPH mode is supported and can be properly enabled based on the
+return value of `pcie_enable_tph()`.
+
+To disable TPH, use the following function::
+
+ void pcie_disable_tph(struct pci_dev *pdev);
+
+Manage ST
+---------
+
+Steering Tags are platform specific. PCIe spec does not specify where STs
+are from. Instead PCI Firmware Specification defines an ACPI _DSM method
+(see the `Revised _DSM for Cache Locality TPH Features ECN
+<https://members.pcisig.com/wg/PCI-SIG/document/15470>`_) for retrieving
+STs for a target memory of various properties. This method is what is
+supported in this implementation.
+
+To retrieve a Steering Tag for a target memory associated with a specific
+CPU, use the following function::
+
+ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type type,
+ unsigned int cpu_uid, u16 *tag);
+
+The `type` argument is used to specify the memory type, either volatile
+or persistent, of the target memory. The `cpu_uid` argument specifies the
+CPU where the memory is associated to.
+
+After the ST value is retrieved, the device driver can use the following
+function to write the ST into the device::
+
+ int pcie_tph_set_st_entry(struct pci_dev *pdev, unsigned int index,
+ u16 tag);
+
+The `index` argument is the ST table entry index the ST tag will be
+written into. `pcie_tph_set_st_entry()` will figure out the proper
+location of ST table, either in the MSI-X table or in the TPH Extended
+Capability space, and write the Steering Tag into the ST entry pointed by
+the `index` argument.
+
+It is completely up to the driver to decide how to use these TPH
+functions. For example a network device driver can use the TPH APIs above
+to update the Steering Tag when interrupt affinity of a RX/TX queue has
+been changed. Here is a sample code for IRQ affinity notifier:
+
+.. code-block:: c
+
+ static void irq_affinity_notified(struct irq_affinity_notify *notify,
+ const cpumask_t *mask)
+ {
+ struct drv_irq *irq;
+ unsigned int cpu_id;
+ u16 tag;
+
+ irq = container_of(notify, struct drv_irq, affinity_notify);
+ cpumask_copy(irq->cpu_mask, mask);
+
+ /* Pick a right CPU as the target - here is just an example */
+ cpu_id = cpumask_first(irq->cpu_mask);
+
+ if (pcie_tph_get_cpu_st(irq->pdev, TPH_MEM_TYPE_VM, cpu_id,
+ &tag))
+ return;
+
+ if (pcie_tph_set_st_entry(irq->pdev, irq->msix_nr, tag))
+ return;
+ }
+
+Disable TPH system-wide
+-----------------------
+
+There is a kernel command line option available to control TPH feature:
+ * "notph": TPH will be disabled for all endpoint devices.
diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
index b34990c7c377..1b0aad184dd7 100644
--- a/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
+++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.rst
@@ -286,6 +286,39 @@ in order to detect the beginnings and ends of grace periods in a
distributed fashion. The values flow from ``rcu_state`` to ``rcu_node``
(down the tree from the root to the leaves) to ``rcu_data``.
++-----------------------------------------------------------------------+
+| **Quick Quiz**: |
++-----------------------------------------------------------------------+
+| Given that the root rcu_node structure has a gp_seq field, |
+| why does RCU maintain a separate gp_seq in the rcu_state structure? |
+| Why not just use the root rcu_node's gp_seq as the official record |
+| and update it directly when starting a new grace period? |
++-----------------------------------------------------------------------+
+| **Answer**: |
++-----------------------------------------------------------------------+
+| On single-node RCU trees (where the root node is also a leaf), |
+| updating the root node's gp_seq immediately would create unnecessary |
+| lock contention. Here's why: |
+| |
+| If we did rcu_seq_start() directly on the root node's gp_seq: |
+| |
+| 1. All CPUs would immediately see their node's gp_seq from their rdp's|
+| gp_seq, in rcu_pending(). They would all then invoke the RCU-core. |
+| 2. Which calls note_gp_changes() and try to acquire the node lock. |
+| 3. But rnp->qsmask isn't initialized yet (happens later in |
+| rcu_gp_init()) |
+| 4. So each CPU would acquire the lock, find it can't determine if it |
+| needs to report quiescent state (no qsmask), update rdp->gp_seq, |
+| and release the lock. |
+| 5. Result: Lots of lock acquisitions with no grace period progress |
+| |
+| By having a separate rcu_state.gp_seq, we can increment the official |
+| grace period counter without immediately affecting what CPUs see in |
+| their nodes. The hierarchical propagation in rcu_gp_init() then |
+| updates the root node's gp_seq and qsmask together under the same lock|
+| acquisition, avoiding this useless contention. |
++-----------------------------------------------------------------------+
+
Miscellaneous
'''''''''''''
@@ -921,10 +954,10 @@ This portion of the ``rcu_data`` structure is declared as follows:
::
- 1 int dynticks_snap;
+ 1 int watching_snap;
2 unsigned long dynticks_fqs;
-The ``->dynticks_snap`` field is used to take a snapshot of the
+The ``->watching_snap`` field is used to take a snapshot of the
corresponding CPU's dyntick-idle state when forcing quiescent states,
and is therefore accessed from other CPUs. Finally, the
``->dynticks_fqs`` field is used to count the number of times this CPU
@@ -935,8 +968,8 @@ This portion of the rcu_data structure is declared as follows:
::
- 1 long dynticks_nesting;
- 2 long dynticks_nmi_nesting;
+ 1 long nesting;
+ 2 long nmi_nesting;
3 atomic_t dynticks;
4 bool rcu_need_heavy_qs;
5 bool rcu_urgent_qs;
@@ -945,14 +978,14 @@ These fields in the rcu_data structure maintain the per-CPU dyntick-idle
state for the corresponding CPU. The fields may be accessed only from
the corresponding CPU (and from tracing) unless otherwise stated.
-The ``->dynticks_nesting`` field counts the nesting depth of process
+The ``->nesting`` field counts the nesting depth of process
execution, so that in normal circumstances this counter has value zero
or one. NMIs, irqs, and tracers are counted by the
-``->dynticks_nmi_nesting`` field. Because NMIs cannot be masked, changes
+``->nmi_nesting`` field. Because NMIs cannot be masked, changes
to this variable have to be undertaken carefully using an algorithm
provided by Andy Lutomirski. The initial transition from idle adds one,
and nested transitions add two, so that a nesting level of five is
-represented by a ``->dynticks_nmi_nesting`` value of nine. This counter
+represented by a ``->nmi_nesting`` value of nine. This counter
can therefore be thought of as counting the number of reasons why this
CPU cannot be permitted to enter dyntick-idle mode, aside from
process-level transitions.
@@ -960,12 +993,12 @@ process-level transitions.
However, it turns out that when running in non-idle kernel context, the
Linux kernel is fully capable of entering interrupt handlers that never
exit and perhaps also vice versa. Therefore, whenever the
-``->dynticks_nesting`` field is incremented up from zero, the
-``->dynticks_nmi_nesting`` field is set to a large positive number, and
-whenever the ``->dynticks_nesting`` field is decremented down to zero,
-the ``->dynticks_nmi_nesting`` field is set to zero. Assuming that
+``->nesting`` field is incremented up from zero, the
+``->nmi_nesting`` field is set to a large positive number, and
+whenever the ``->nesting`` field is decremented down to zero,
+the ``->nmi_nesting`` field is set to zero. Assuming that
the number of misnested interrupts is not sufficient to overflow the
-counter, this approach corrects the ``->dynticks_nmi_nesting`` field
+counter, this approach corrects the ``->nmi_nesting`` field
every time the corresponding CPU enters the idle loop from process
context.
@@ -992,8 +1025,8 @@ code.
+-----------------------------------------------------------------------+
| **Quick Quiz**: |
+-----------------------------------------------------------------------+
-| Why not simply combine the ``->dynticks_nesting`` and |
-| ``->dynticks_nmi_nesting`` counters into a single counter that just |
+| Why not simply combine the ``->nesting`` and |
+| ``->nmi_nesting`` counters into a single counter that just |
| counts the number of reasons that the corresponding CPU is non-idle? |
+-----------------------------------------------------------------------+
| **Answer**: |
diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
index c9c957c85bac..414f8a2012d6 100644
--- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
+++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
@@ -181,7 +181,7 @@ operations is carried out at several levels:
of this wait (or series of waits, as the case may be) is to permit a
concurrent CPU-hotplug operation to complete.
#. In the case of RCU-sched, one of the last acts of an outgoing CPU is
- to invoke ``rcu_report_dead()``, which reports a quiescent state for
+ to invoke ``rcutree_report_cpu_dead()``, which reports a quiescent state for
that CPU. However, this is likely paranoia-induced redundancy.
+-----------------------------------------------------------------------+
@@ -277,7 +277,7 @@ the following access functions:
Again, only one request in a given batch need actually carry out a
grace-period operation, which means there must be an efficient way to
-identify which of many concurrent reqeusts will initiate the grace
+identify which of many concurrent requests will initiate the grace
period, and that there be an efficient way for the remaining requests to
wait for that grace period to complete. However, that is the topic of
the next section.
@@ -405,7 +405,7 @@ Use of Workqueues
In earlier implementations, the task requesting the expedited grace
period also drove it to completion. This straightforward approach had
the disadvantage of needing to account for POSIX signals sent to user
-tasks, so more recent implemementations use the Linux kernel's
+tasks, so more recent implementations use the Linux kernel's
workqueues (see Documentation/core-api/workqueue.rst).
The requesting task still does counter snapshotting and funnel-lock
@@ -465,7 +465,7 @@ corresponding disadvantage that workqueues cannot be used until they are
initialized, which does not happen until some time after the scheduler
spawns the first task. Given that there are parts of the kernel that
really do want to execute grace periods during this mid-boot “dead
-zone”, expedited grace periods must do something else during thie time.
+zone”, expedited grace periods must do something else during this time.
What they do is to fall back to the old practice of requiring that the
requesting task drive the expedited grace period, as was the case before
diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
index 7fdf151a8680..1a5ff1a9f02e 100644
--- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
@@ -147,11 +147,11 @@ RCU read-side critical sections preceding and following the current
idle sojourn.
This case is handled by calls to the strongly ordered
``atomic_add_return()`` read-modify-write atomic operation that
-is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry
-time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.
-The grace-period kthread invokes ``rcu_dynticks_snap()`` and
-``rcu_dynticks_in_eqs_since()`` (both of which invoke
-an ``atomic_add_return()`` of zero) to detect idle CPUs.
+is invoked within ``ct_kernel_exit_state()`` at idle-entry
+time and within ``ct_kernel_enter_state()`` at idle-exit time.
+The grace-period kthread invokes first ``ct_rcu_watching_cpu_acquire()``
+(preceded by a full memory barrier) and ``rcu_watching_snap_stopped_since()``
+(both of which rely on acquire semantics) to detect idle CPUs.
+-----------------------------------------------------------------------+
| **Quick Quiz**: |
@@ -168,7 +168,7 @@ an ``atomic_add_return()`` of zero) to detect idle CPUs.
+-----------------------------------------------------------------------+
The approach must be extended to handle one final case, that of waking a
-task blocked in ``synchronize_rcu()``. This task might be affinitied to
+task blocked in ``synchronize_rcu()``. This task might be affined to
a CPU that is not yet aware that the grace period has ended, and thus
might not yet be subject to the grace period's memory ordering.
Therefore, there is an ``smp_mb()`` after the return from
diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg
index 7ac6f9269806..63eff867175a 100644
--- a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg
+++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg
@@ -566,15 +566,6 @@
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_migrate_callbacks()</text>
<text
xml:space="preserve"
- x="8335.4873"
- y="5357.1006"
- font-style="normal"
- font-weight="bold"
- font-size="192"
- id="text202-7-9-6-0"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_migrate_callbacks()</text>
- <text
- xml:space="preserve"
x="8768.4678"
y="6224.9038"
font-style="normal"
diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg
index 423df00c4df9..3fbc19c48a58 100644
--- a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg
+++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-dyntick.svg
@@ -528,7 +528,7 @@
font-style="normal"
y="-8652.5312"
x="2466.7822"
- xml:space="preserve">dyntick_save_progress_counter()</text>
+ xml:space="preserve">rcu_watching_snap_save()</text>
<text
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
id="text202-7-2-7-2-0"
@@ -537,7 +537,7 @@
font-style="normal"
y="-8368.1475"
x="2463.3262"
- xml:space="preserve">rcu_implicit_dynticks_qs()</text>
+ xml:space="preserve">rcu_watching_snap_recheck()</text>
</g>
<g
id="g4504"
@@ -607,7 +607,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_enter()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_exit_state()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -638,7 +638,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-1"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_exit()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_enter_state()</text>
<text
xml:space="preserve"
x="3745.7725"
diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg
index 7ddc094d7f28..25c7acc8a4c2 100644
--- a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg
+++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg
@@ -844,7 +844,7 @@
font-style="normal"
y="1547.8876"
x="4417.6396"
- xml:space="preserve">dyntick_save_progress_counter()</text>
+ xml:space="preserve">rcu_watching_snap_save()</text>
<g
style="fill:none;stroke-width:0.025in"
transform="translate(6501.9719,-10685.904)"
@@ -899,7 +899,7 @@
font-style="normal"
y="1858.8729"
x="4414.1836"
- xml:space="preserve">rcu_implicit_dynticks_qs()</text>
+ xml:space="preserve">rcu_watching_snap_recheck()</text>
<text
xml:space="preserve"
x="14659.87"
@@ -977,7 +977,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_enter()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_exit_state()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -1008,7 +1008,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-1"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_exit()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_enter_state()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -1135,7 +1135,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-5"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_report_dead()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_report_cpu_dead()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -1256,7 +1256,7 @@
font-style="normal"
y="3679.27"
x="-3804.9949"
- xml:space="preserve">rcu_cpu_starting()</text>
+ xml:space="preserve">rcutree_report_cpu_starting()</text>
<g
style="fill:none;stroke-width:0.025in"
id="g3107-7-5-0"
diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg
index 069f6f8371c2..d05bc7b27edb 100644
--- a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg
+++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg
@@ -1448,15 +1448,6 @@
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_migrate_callbacks()</text>
<text
xml:space="preserve"
- x="8335.4873"
- y="5357.1006"
- font-style="normal"
- font-weight="bold"
- font-size="192"
- id="text202-7-9-6-0"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_migrate_callbacks()</text>
- <text
- xml:space="preserve"
x="8768.4678"
y="6224.9038"
font-style="normal"
@@ -2983,7 +2974,7 @@
font-style="normal"
y="38114.047"
x="-334.33856"
- xml:space="preserve">dyntick_save_progress_counter()</text>
+ xml:space="preserve">rcu_watching_snap_save()</text>
<g
style="fill:none;stroke-width:0.025in"
transform="translate(1749.9916,25880.249)"
@@ -3038,7 +3029,7 @@
font-style="normal"
y="38425.035"
x="-337.79462"
- xml:space="preserve">rcu_implicit_dynticks_qs()</text>
+ xml:space="preserve">rcu_watching_snap_recheck()</text>
<text
xml:space="preserve"
x="9907.8887"
@@ -3116,7 +3107,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_enter()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_exit_state()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -3147,7 +3138,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-1"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_exit()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_enter_state()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -3274,7 +3265,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-5"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_report_dead()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_report_cpu_dead()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -3395,7 +3386,7 @@
font-style="normal"
y="3679.27"
x="-3804.9949"
- xml:space="preserve">rcu_cpu_starting()</text>
+ xml:space="preserve">rcutree_report_cpu_starting()</text>
<g
style="fill:none;stroke-width:0.025in"
id="g3107-7-5-0"
diff --git a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg
index 2c9310ba29ba..a92356ce4011 100644
--- a/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg
+++ b/Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg
@@ -516,7 +516,7 @@
font-style="normal"
y="-8652.5312"
x="2466.7822"
- xml:space="preserve">dyntick_save_progress_counter()</text>
+ xml:space="preserve">rcu_watching_snap_save()</text>
<text
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
id="text202-7-2-7-2-0"
@@ -525,7 +525,7 @@
font-style="normal"
y="-8368.1475"
x="2463.3262"
- xml:space="preserve">rcu_implicit_dynticks_qs()</text>
+ xml:space="preserve">rcu_watching_snap_recheck()</text>
<text
sodipodi:linespacing="125%"
style="font-size:192px;font-style:normal;font-weight:bold;line-height:125%;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
@@ -607,7 +607,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6"
- style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_report_dead()</text>
+ style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_report_cpu_dead()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -728,7 +728,7 @@
font-style="normal"
y="3679.27"
x="-3804.9949"
- xml:space="preserve">rcu_cpu_starting()</text>
+ xml:space="preserve">rcutree_report_cpu_starting()</text>
<g
style="fill:none;stroke-width:0.025in"
id="g3107-7-5-0"
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index a0f8164c8513..ba417a08b93d 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -1858,7 +1858,7 @@ unloaded. After a given module has been unloaded, any attempt to call
one of its functions results in a segmentation fault. The module-unload
functions must therefore cancel any delayed calls to loadable-module
functions, for example, any outstanding mod_timer() must be dealt
-with via del_timer_sync() or similar.
+with via timer_shutdown_sync() or similar.
Unfortunately, there is no way to cancel an RCU callback; once you
invoke call_rcu(), the callback function is eventually going to be
@@ -1955,12 +1955,12 @@ if offline CPUs block an RCU grace period for too long.
An offline CPU's quiescent state will be reported either:
-1. As the CPU goes offline using RCU's hotplug notifier (rcu_report_dead()).
+1. As the CPU goes offline using RCU's hotplug notifier (rcutree_report_cpu_dead()).
2. When grace period initialization (rcu_gp_init()) detects a
race either with CPU offlining or with a task unblocking on a leaf
``rcu_node`` structure whose CPUs are all offline.
-The CPU-online path (rcu_cpu_starting()) should never need to report
+The CPU-online path (rcutree_report_cpu_starting()) should never need to report
a quiescent state for an offline CPU. However, as a debugging measure,
it does emit a warning if a quiescent state was not already reported
for that CPU.
@@ -1970,6 +1970,130 @@ corresponding CPU's leaf node lock is held. This avoids race conditions
between RCU's hotplug notifier hooks, the grace period initialization
code, and the FQS loop, all of which refer to or modify this bookkeeping.
+Note that grace period initialization (rcu_gp_init()) must carefully sequence
+CPU hotplug scanning with grace period state changes. For example, the
+following race could occur in rcu_gp_init() if rcu_seq_start() were to happen
+after the CPU hotplug scanning::
+
+ CPU0 (rcu_gp_init) CPU1 CPU2
+ --------------------- ---- ----
+ // Hotplug scan first (WRONG ORDER)
+ rcu_for_each_leaf_node(rnp) {
+ rnp->qsmaskinit = rnp->qsmaskinitnext;
+ }
+ rcutree_report_cpu_starting()
+ rnp->qsmaskinitnext |= mask;
+ rcu_read_lock()
+ r0 = *X;
+ r1 = *X;
+ X = NULL;
+ cookie = get_state_synchronize_rcu();
+ // cookie = 8 (future GP)
+ rcu_seq_start(&rcu_state.gp_seq);
+ // gp_seq = 5
+
+ // CPU1 now invisible to this GP!
+ rcu_for_each_node_breadth_first() {
+ rnp->qsmask = rnp->qsmaskinit;
+ // CPU1 not included!
+ }
+
+ // GP completes without CPU1
+ rcu_seq_end(&rcu_state.gp_seq);
+ // gp_seq = 8
+ poll_state_synchronize_rcu(cookie);
+ // Returns true!
+ kfree(r1);
+ r2 = *r0; // USE-AFTER-FREE!
+
+By incrementing ``gp_seq`` first, CPU1's RCU read-side critical section
+is guaranteed to not be missed by CPU2.
+
+Concurrent Quiescent State Reporting for Offline CPUs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+RCU must ensure that CPUs going offline report quiescent states to avoid
+blocking grace periods. This requires careful synchronization to handle
+race conditions
+
+Race condition causing Offline CPU to hang GP
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A race between CPU offlining and new GP initialization (gp_init()) may occur
+because rcu_report_qs_rnp() in rcutree_report_cpu_dead() must temporarily
+release the ``rcu_node`` lock to wake the RCU grace-period kthread::
+
+ CPU1 (going offline) CPU0 (GP kthread)
+ -------------------- -----------------
+ rcutree_report_cpu_dead()
+ rcu_report_qs_rnp()
+ // Must release rnp->lock to wake GP kthread
+ raw_spin_unlock_irqrestore_rcu_node()
+ // Wakes up and starts new GP
+ rcu_gp_init()
+ // First loop:
+ copies qsmaskinitnext->qsmaskinit
+ // CPU1 still in qsmaskinitnext!
+
+ // Second loop:
+ rnp->qsmask = rnp->qsmaskinit
+ mask = rnp->qsmask & ~rnp->qsmaskinitnext
+ // mask is 0! CPU1 still in both masks
+ // Reacquire lock (but too late)
+ rnp->qsmaskinitnext &= ~mask // Finally clears bit
+
+Without ``ofl_lock``, the new grace period includes the offline CPU and waits
+forever for its quiescent state causing a GP hang.
+
+A solution with ofl_lock
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``ofl_lock`` (offline lock) prevents rcu_gp_init() from running during
+the vulnerable window when rcu_report_qs_rnp() has released ``rnp->lock``::
+
+ CPU0 (rcu_gp_init) CPU1 (rcutree_report_cpu_dead)
+ ------------------ ------------------------------
+ rcu_for_each_leaf_node(rnp) {
+ arch_spin_lock(&ofl_lock) -----> arch_spin_lock(&ofl_lock) [BLOCKED]
+
+ // Safe: CPU1 can't interfere
+ rnp->qsmaskinit = rnp->qsmaskinitnext
+
+ arch_spin_unlock(&ofl_lock) ---> // Now CPU1 can proceed
+ } // But snapshot already taken
+
+Another race causing GP hangs in rcu_gpu_init(): Reporting QS for Now-offline CPUs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+After the first loop takes an atomic snapshot of online CPUs, as shown above,
+the second loop in rcu_gp_init() detects CPUs that went offline between
+releasing ``ofl_lock`` and acquiring the per-node ``rnp->lock``.
+This detection is crucial because:
+
+1. The CPU might have gone offline after the snapshot but before the second loop
+2. The offline CPU cannot report its own QS if it's already dead
+3. Without this detection, the grace period would wait forever for CPUs that
+ are now offline.
+
+The second loop performs this detection safely::
+
+ rcu_for_each_node_breadth_first(rnp) {
+ raw_spin_lock_irqsave_rcu_node(rnp, flags);
+ rnp->qsmask = rnp->qsmaskinit; // Apply the snapshot
+
+ // Detect CPUs offline after snapshot
+ mask = rnp->qsmask & ~rnp->qsmaskinitnext;
+
+ if (mask && rcu_is_leaf_node(rnp))
+ rcu_report_qs_rnp(mask, ...) // Report QS for offline CPUs
+ }
+
+This approach ensures atomicity: quiescent state reporting for offline CPUs
+happens either in rcu_gp_init() (second loop) or in rcutree_report_cpu_dead(),
+never both and never neither. The ``rnp->lock`` held throughout the sequence
+prevents races - rcutree_report_cpu_dead() also acquires this lock when
+clearing ``qsmaskinitnext``, ensuring mutual exclusion.
+
Scheduler and RCU
~~~~~~~~~~~~~~~~~
@@ -2071,41 +2195,7 @@ call.
Because RCU avoids interrupting idle CPUs, it is illegal to execute an
RCU read-side critical section on an idle CPU. (Kernels built with
-``CONFIG_PROVE_RCU=y`` will splat if you try it.) The RCU_NONIDLE()
-macro and ``_rcuidle`` event tracing is provided to work around this
-restriction. In addition, rcu_is_watching() may be used to test
-whether or not it is currently legal to run RCU read-side critical
-sections on this CPU. I learned of the need for diagnostics on the one
-hand and RCU_NONIDLE() on the other while inspecting idle-loop code.
-Steven Rostedt supplied ``_rcuidle`` event tracing, which is used quite
-heavily in the idle loop. However, there are some restrictions on the
-code placed within RCU_NONIDLE():
-
-#. Blocking is prohibited. In practice, this is not a serious
- restriction given that idle tasks are prohibited from blocking to
- begin with.
-#. Although nesting RCU_NONIDLE() is permitted, they cannot nest
- indefinitely deeply. However, given that they can be nested on the
- order of a million deep, even on 32-bit systems, this should not be a
- serious restriction. This nesting limit would probably be reached
- long after the compiler OOMed or the stack overflowed.
-#. Any code path that enters RCU_NONIDLE() must sequence out of that
- same RCU_NONIDLE(). For example, the following is grossly
- illegal:
-
- ::
-
- 1 RCU_NONIDLE({
- 2 do_something();
- 3 goto bad_idea; /* BUG!!! */
- 4 do_something_else();});
- 5 bad_idea:
-
-
- It is just as illegal to transfer control into the middle of
- RCU_NONIDLE()'s argument. Yes, in theory, you could transfer in
- as long as you also transferred out, but in practice you could also
- expect to get sharply worded review comments.
+``CONFIG_PROVE_RCU=y`` will splat if you try it.)
It is similarly socially unacceptable to interrupt an ``nohz_full`` CPU
running in userspace. RCU must therefore track ``nohz_full`` userspace
@@ -2391,6 +2481,7 @@ section.
#. `Sched Flavor (Historical)`_
#. `Sleepable RCU`_
#. `Tasks RCU`_
+#. `Tasks Trace RCU`_
Bottom-Half Flavor (Historical)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2546,15 +2637,16 @@ synchronize_srcu() for some other domain ``ss1``, and if an
that was held across as ``ss``-domain synchronize_srcu(), deadlock
would again be possible. Such a deadlock cycle could extend across an
arbitrarily large number of different SRCU domains. Again, with great
-power comes great responsibility.
+power comes great responsibility, though lockdep is now able to detect
+this sort of deadlock.
-Unlike the other RCU flavors, SRCU read-side critical sections can run
-on idle and even offline CPUs. This ability requires that
-srcu_read_lock() and srcu_read_unlock() contain memory barriers,
-which means that SRCU readers will run a bit slower than would RCU
-readers. It also motivates the smp_mb__after_srcu_read_unlock() API,
-which, in combination with srcu_read_unlock(), guarantees a full
-memory barrier.
+Unlike the other RCU flavors, SRCU read-side critical sections can run on
+idle and even offline CPUs, with the exception of srcu_read_lock_fast()
+and friends. This ability requires that srcu_read_lock() and
+srcu_read_unlock() contain memory barriers, which means that SRCU
+readers will run a bit slower than would RCU readers. It also motivates
+the smp_mb__after_srcu_read_unlock() API, which, in combination with
+srcu_read_unlock(), guarantees a full memory barrier.
Also unlike other RCU flavors, synchronize_srcu() may **not** be
invoked from CPU-hotplug notifiers, due to the fact that SRCU grace
@@ -2590,15 +2682,15 @@ run some tests first. SRCU just might need a few adjustment to deal with
that sort of load. Of course, your mileage may vary based on the speed
of your CPUs and the size of your memory.
-The `SRCU
-API <https://lwn.net/Articles/609973/#RCU%20Per-Flavor%20API%20Table>`__
+The `SRCU API
+<https://lwn.net/Articles/609973/#RCU%20Per-Flavor%20API%20Table>`__
includes srcu_read_lock(), srcu_read_unlock(),
-srcu_dereference(), srcu_dereference_check(),
-synchronize_srcu(), synchronize_srcu_expedited(),
-call_srcu(), srcu_barrier(), and srcu_read_lock_held(). It
-also includes DEFINE_SRCU(), DEFINE_STATIC_SRCU(), and
-init_srcu_struct() APIs for defining and initializing
-``srcu_struct`` structures.
+srcu_dereference(), srcu_dereference_check(), synchronize_srcu(),
+synchronize_srcu_expedited(), call_srcu(), srcu_barrier(),
+and srcu_read_lock_held(). It also includes DEFINE_SRCU(),
+DEFINE_STATIC_SRCU(), DEFINE_SRCU_FAST(), DEFINE_STATIC_SRCU_FAST(),
+init_srcu_struct(), and init_srcu_struct_fast() APIs for defining and
+initializing ``srcu_struct`` structures.
More recently, the SRCU API has added polling interfaces:
@@ -2644,6 +2736,16 @@ critical sections that are delimited by voluntary context switches, that
is, calls to schedule(), cond_resched(), and
synchronize_rcu_tasks(). In addition, transitions to and from
userspace execution also delimit tasks-RCU read-side critical sections.
+Idle tasks are ignored by Tasks RCU, and Tasks Rude RCU may be used to
+interact with them.
+
+Note well that involuntary context switches are *not* Tasks-RCU quiescent
+states. After all, in preemptible kernels, a task executing code in a
+trampoline might be preempted. In this case, the Tasks-RCU grace period
+clearly cannot end until that task resumes and its execution leaves that
+trampoline. This means, among other things, that cond_resched() does
+not provide a Tasks RCU quiescent state. (Instead, use rcu_softirq_qs()
+from softirq or rcu_tasks_classic_qs() otherwise.)
The tasks-RCU API is quite compact, consisting only of
call_rcu_tasks(), synchronize_rcu_tasks(), and
@@ -2666,9 +2768,13 @@ moniker. And this operation is considered to be quite rude by real-time
workloads that don't want their ``nohz_full`` CPUs receiving IPIs and
by battery-powered systems that don't want their idle CPUs to be awakened.
+Once kernel entry/exit and deep-idle functions have been properly tagged
+``noinstr``, Tasks RCU can start paying attention to idle tasks (except
+those that are idle from RCU's perspective) and then Tasks Rude RCU can
+be removed from the kernel.
+
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
-consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
-and rcu_barrier_tasks_rude().
+consisting solely of synchronize_rcu_tasks_rude().
Tasks Trace RCU
~~~~~~~~~~~~~~~
diff --git a/Documentation/RCU/NMI-RCU.rst b/Documentation/RCU/NMI-RCU.rst
index 2a92bc685ef1..dff60a80b386 100644
--- a/Documentation/RCU/NMI-RCU.rst
+++ b/Documentation/RCU/NMI-RCU.rst
@@ -8,7 +8,7 @@ Although RCU is usually used to protect read-mostly data structures,
it is possible to use RCU to provide dynamic non-maskable interrupt
handlers, as well as dynamic irq handlers. This document describes
how to do this, drawing loosely from Zwane Mwaikambo's NMI-timer
-work in "arch/x86/kernel/traps.c".
+work in an old version of "arch/x86/kernel/traps.c".
The relevant pieces of code are listed below, each followed by a
brief explanation::
@@ -116,7 +116,7 @@ Answer to Quick Quiz:
This same sad story can happen on other CPUs when using
a compiler with aggressive pointer-value speculation
- optimizations.
+ optimizations. (But please don't!)
More important, the rcu_dereference_sched() makes it
clear to someone reading the code that the pointer is
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt
index 588d97366a46..8d4e8de4c460 100644
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
@@ -201,7 +201,7 @@ work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425].
In 2012, Josh Triplett received his Ph.D. with his dissertation
covering RCU-protected resizable hash tables and the relationship
between memory barriers and read-side traversal order: If the updater
-is making changes in the opposite direction from the read-side traveral
+is making changes in the opposite direction from the read-side traversal
order, the updater need only execute a memory-barrier instruction,
but if in the same direction, the updater needs to wait for a grace
period between the individual updates [JoshTriplettPhD]. Also in 2012,
@@ -641,7 +641,7 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni"
,Month="July"
,Year="2001"
,note="Available:
-\url{http://www.linuxsymposium.org/2001/abstracts/readcopy.php}
+\url{https://kernel.org/doc/ols/2001/read-copy.pdf}
\url{http://www.rdrop.com/users/paulmck/RCU/rclock_OLS.2001.05.01c.pdf}
[Viewed June 23, 2004]"
,annotation={
@@ -1245,7 +1245,7 @@ Oregon Health and Sciences University"
[Viewed September 5, 2005]"
,annotation={
First posting showing how RCU can be safely adapted for
- preemptable RCU read side critical sections.
+ preemptible RCU read side critical sections.
}
}
@@ -1480,7 +1480,7 @@ Suparna Bhattacharya"
,Year="2006"
,pages="v2 123-138"
,note="Available:
-\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
+\url{https://kernel.org/doc/ols/2006/ols2006v2-pages-131-146.pdf}
\url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf}
[Viewed January 1, 2007]"
,annotation={
@@ -1511,7 +1511,7 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen"
,Year="2006"
,pages="v2 249-254"
,note="Available:
-\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
+\url{https://kernel.org/doc/ols/2006/ols2006v2-pages-249-262.pdf}
[Viewed January 11, 2009]"
,annotation={
Uses RCU-protected radix tree for a lockless page cache.
@@ -1888,7 +1888,7 @@ Revised:
\url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com}
[Viewed October 25, 2007]"
,annotation={
- Final patch for preemptable RCU to -rt. (Later patches were
+ Final patch for preemptible RCU to -rt. (Later patches were
to mainline, eventually incorporated.)
}
}
@@ -2275,7 +2275,7 @@ lot of {Linux} into your technology!!!"
\url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com}
[Viewed August 15, 2009]"
,annotation={
- First posting of simple and fast preemptable RCU.
+ First posting of simple and fast preemptible RCU.
}
}
@@ -2639,7 +2639,7 @@ lot of {Linux} into your technology!!!"
RCU-protected hash tables, barriers vs. read-side traversal order.
.
If the updater is making changes in the opposite direction from
- the read-side traveral order, the updater need only execute a
+ the read-side traversal order, the updater need only execute a
memory-barrier instruction, but if in the same direction, the
updater needs to wait for a grace period between the individual
updates.
diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst
index e26dda27430c..4060d7a2f62a 100644
--- a/Documentation/RCU/UP.rst
+++ b/Documentation/RCU/UP.rst
@@ -38,7 +38,7 @@ by having call_rcu() directly invoke its arguments only if it was called
from process context. However, this can fail in a similar manner.
Suppose that an RCU-based algorithm again scans a linked list containing
-elements A, B, and C in process contexts, but that it invokes a function
+elements A, B, and C in process context, but that it invokes a function
on each element as it is scanned. Suppose further that this function
deletes element B from the list, then passes it to call_rcu() for deferred
freeing. This may be a bit unconventional, but it is perfectly legal
@@ -59,7 +59,8 @@ Example 3: Death by Deadlock
Suppose that call_rcu() is invoked while holding a lock, and that the
callback function must acquire this same lock. In this case, if
call_rcu() were to directly invoke the callback, the result would
-be self-deadlock.
+be self-deadlock *even if* this invocation occurred from a later
+call_rcu() invocation a full grace period later.
In some cases, it would possible to restructure to code so that
the call_rcu() is delayed until after the lock is released. However,
@@ -85,6 +86,14 @@ Quick Quiz #2:
:ref:`Answers to Quick Quiz <answer_quick_quiz_up>`
+It is important to note that userspace RCU implementations *do*
+permit call_rcu() to directly invoke callbacks, but only if a full
+grace period has elapsed since those callbacks were queued. This is
+the case because some userspace environments are extremely constrained.
+Nevertheless, people writing userspace RCU implementations are strongly
+encouraged to avoid invoking callbacks from call_rcu(), thus obtaining
+the deadlock-avoidance benefits called out above.
+
Summary
-------
@@ -98,7 +107,7 @@ UP systems, including PREEMPT SMP builds running on UP systems.
Quick Quiz #3:
Why can't synchronize_rcu() return immediately on UP systems running
- preemptable RCU?
+ preemptible RCU?
.. _answer_quick_quiz_up:
@@ -134,7 +143,7 @@ Answer to Quick Quiz #2:
Answer to Quick Quiz #3:
Why can't synchronize_rcu() return immediately on UP systems
- running preemptable RCU?
+ running preemptible RCU?
Because some other task might have been preempted in the middle
of an RCU read-side critical section. If synchronize_rcu()
diff --git a/Documentation/RCU/arrayRCU.rst b/Documentation/RCU/arrayRCU.rst
deleted file mode 100644
index a5f2ff8fc54c..000000000000
--- a/Documentation/RCU/arrayRCU.rst
+++ /dev/null
@@ -1,165 +0,0 @@
-.. _array_rcu_doc:
-
-Using RCU to Protect Read-Mostly Arrays
-=======================================
-
-Although RCU is more commonly used to protect linked lists, it can
-also be used to protect arrays. Three situations are as follows:
-
-1. :ref:`Hash Tables <hash_tables>`
-
-2. :ref:`Static Arrays <static_arrays>`
-
-3. :ref:`Resizable Arrays <resizable_arrays>`
-
-Each of these three situations involves an RCU-protected pointer to an
-array that is separately indexed. It might be tempting to consider use
-of RCU to instead protect the index into an array, however, this use
-case is **not** supported. The problem with RCU-protected indexes into
-arrays is that compilers can play way too many optimization games with
-integers, which means that the rules governing handling of these indexes
-are far more trouble than they are worth. If RCU-protected indexes into
-arrays prove to be particularly valuable (which they have not thus far),
-explicit cooperation from the compiler will be required to permit them
-to be safely used.
-
-That aside, each of the three RCU-protected pointer situations are
-described in the following sections.
-
-.. _hash_tables:
-
-Situation 1: Hash Tables
-------------------------
-
-Hash tables are often implemented as an array, where each array entry
-has a linked-list hash chain. Each hash chain can be protected by RCU
-as described in listRCU.rst. This approach also applies to other
-array-of-list situations, such as radix trees.
-
-.. _static_arrays:
-
-Situation 2: Static Arrays
---------------------------
-
-Static arrays, where the data (rather than a pointer to the data) is
-located in each array element, and where the array is never resized,
-have not been used with RCU. Rik van Riel recommends using seqlock in
-this situation, which would also have minimal read-side overhead as long
-as updates are rare.
-
-Quick Quiz:
- Why is it so important that updates be rare when using seqlock?
-
-:ref:`Answer to Quick Quiz <answer_quick_quiz_seqlock>`
-
-.. _resizable_arrays:
-
-Situation 3: Resizable Arrays
-------------------------------
-
-Use of RCU for resizable arrays is demonstrated by the grow_ary()
-function formerly used by the System V IPC code. The array is used
-to map from semaphore, message-queue, and shared-memory IDs to the data
-structure that represents the corresponding IPC construct. The grow_ary()
-function does not acquire any locks; instead its caller must hold the
-ids->sem semaphore.
-
-The grow_ary() function, shown below, does some limit checks, allocates a
-new ipc_id_ary, copies the old to the new portion of the new, initializes
-the remainder of the new, updates the ids->entries pointer to point to
-the new array, and invokes ipc_rcu_putref() to free up the old array.
-Note that rcu_assign_pointer() is used to update the ids->entries pointer,
-which includes any memory barriers required on whatever architecture
-you are running on::
-
- static int grow_ary(struct ipc_ids* ids, int newsize)
- {
- struct ipc_id_ary* new;
- struct ipc_id_ary* old;
- int i;
- int size = ids->entries->size;
-
- if(newsize > IPCMNI)
- newsize = IPCMNI;
- if(newsize <= size)
- return newsize;
-
- new = ipc_rcu_alloc(sizeof(struct kern_ipc_perm *)*newsize +
- sizeof(struct ipc_id_ary));
- if(new == NULL)
- return size;
- new->size = newsize;
- memcpy(new->p, ids->entries->p,
- sizeof(struct kern_ipc_perm *)*size +
- sizeof(struct ipc_id_ary));
- for(i=size;i<newsize;i++) {
- new->p[i] = NULL;
- }
- old = ids->entries;
-
- /*
- * Use rcu_assign_pointer() to make sure the memcpyed
- * contents of the new array are visible before the new
- * array becomes visible.
- */
- rcu_assign_pointer(ids->entries, new);
-
- ipc_rcu_putref(old);
- return newsize;
- }
-
-The ipc_rcu_putref() function decrements the array's reference count
-and then, if the reference count has dropped to zero, uses call_rcu()
-to free the array after a grace period has elapsed.
-
-The array is traversed by the ipc_lock() function. This function
-indexes into the array under the protection of rcu_read_lock(),
-using rcu_dereference() to pick up the pointer to the array so
-that it may later safely be dereferenced -- memory barriers are
-required on the Alpha CPU. Since the size of the array is stored
-with the array itself, there can be no array-size mismatches, so
-a simple check suffices. The pointer to the structure corresponding
-to the desired IPC object is placed in "out", with NULL indicating
-a non-existent entry. After acquiring "out->lock", the "out->deleted"
-flag indicates whether the IPC object is in the process of being
-deleted, and, if not, the pointer is returned::
-
- struct kern_ipc_perm* ipc_lock(struct ipc_ids* ids, int id)
- {
- struct kern_ipc_perm* out;
- int lid = id % SEQ_MULTIPLIER;
- struct ipc_id_ary* entries;
-
- rcu_read_lock();
- entries = rcu_dereference(ids->entries);
- if(lid >= entries->size) {
- rcu_read_unlock();
- return NULL;
- }
- out = entries->p[lid];
- if(out == NULL) {
- rcu_read_unlock();
- return NULL;
- }
- spin_lock(&out->lock);
-
- /* ipc_rmid() may have already freed the ID while ipc_lock
- * was spinning: here verify that the structure is still valid
- */
- if (out->deleted) {
- spin_unlock(&out->lock);
- rcu_read_unlock();
- return NULL;
- }
- return out;
- }
-
-.. _answer_quick_quiz_seqlock:
-
-Answer to Quick Quiz:
- Why is it so important that updates be rare when using seqlock?
-
- The reason that it is important that updates be rare when
- using seqlock is that frequent updates can livelock readers.
- One way to avoid this problem is to assign a seqlock for
- each array entry rather than to the entire array.
diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst
index 048c5bc1f813..4b30f701225f 100644
--- a/Documentation/RCU/checklist.rst
+++ b/Documentation/RCU/checklist.rst
@@ -32,8 +32,8 @@ over a rather long period of time, but improvements are always welcome!
for lockless updates. This does result in the mildly
counter-intuitive situation where rcu_read_lock() and
rcu_read_unlock() are used to protect updates, however, this
- approach provides the same potential simplifications that garbage
- collectors do.
+ approach can provide the same simplifications to certain types
+ of lockless algorithms that garbage collectors do.
1. Does the update code have proper mutual exclusion?
@@ -49,12 +49,12 @@ over a rather long period of time, but improvements are always welcome!
them -- even x86 allows later loads to be reordered to precede
earlier stores), and be prepared to explain why this added
complexity is worthwhile. If you choose #c, be prepared to
- explain how this single task does not become a major bottleneck on
- big multiprocessor machines (for example, if the task is updating
- information relating to itself that other tasks can read, there
- by definition can be no bottleneck). Note that the definition
- of "large" has changed significantly: Eight CPUs was "large"
- in the year 2000, but a hundred CPUs was unremarkable in 2017.
+ explain how this single task does not become a major bottleneck
+ on large systems (for example, if the task is updating information
+ relating to itself that other tasks can read, there by definition
+ can be no bottleneck). Note that the definition of "large" has
+ changed significantly: Eight CPUs was "large" in the year 2000,
+ but a hundred CPUs was unremarkable in 2017.
2. Do the RCU read-side critical sections make proper use of
rcu_read_lock() and friends? These primitives are needed
@@ -68,9 +68,16 @@ over a rather long period of time, but improvements are always welcome!
rcu_read_lock_sched(), or by the appropriate update-side lock.
Explicit disabling of preemption (preempt_disable(), for example)
can serve as rcu_read_lock_sched(), but is less readable and
- prevents lockdep from detecting locking issues.
+ prevents lockdep from detecting locking issues. Acquiring a
+ raw spinlock also enters an RCU read-side critical section.
- Please not that you *cannot* rely on code known to be built
+ The guard(rcu)() and scoped_guard(rcu) primitives designate
+ the remainder of the current scope or the next statement,
+ respectively, as the RCU read-side critical section. Use of
+ these guards can be less error-prone than rcu_read_lock(),
+ rcu_read_unlock(), and friends.
+
+ Please note that you *cannot* rely on code known to be built
only in non-preemptible kernels. Such code can and will break,
especially in kernels built with CONFIG_PREEMPT_COUNT=y.
@@ -97,33 +104,38 @@ over a rather long period of time, but improvements are always welcome!
b. Proceed as in (a) above, but also maintain per-element
locks (that are acquired by both readers and writers)
- that guard per-element state. Of course, fields that
- the readers refrain from accessing can be guarded by
- some other lock acquired only by updaters, if desired.
+ that guard per-element state. Fields that the readers
+ refrain from accessing can be guarded by some other lock
+ acquired only by updaters, if desired.
- This works quite well, also.
+ This also works quite well.
c. Make updates appear atomic to readers. For example,
pointer updates to properly aligned fields will
appear atomic, as will individual atomic primitives.
Sequences of operations performed under a lock will *not*
appear to be atomic to RCU readers, nor will sequences
- of multiple atomic primitives.
+ of multiple atomic primitives. One alternative is to
+ move multiple individual fields to a separate structure,
+ thus solving the multiple-field problem by imposing an
+ additional level of indirection.
This can work, but is starting to get a bit tricky.
- d. Carefully order the updates and the reads so that
- readers see valid data at all phases of the update.
- This is often more difficult than it sounds, especially
- given modern CPUs' tendency to reorder memory references.
- One must usually liberally sprinkle memory barriers
- (smp_wmb(), smp_rmb(), smp_mb()) through the code,
- making it difficult to understand and to test.
-
- It is usually better to group the changing data into
- a separate structure, so that the change may be made
- to appear atomic by updating a pointer to reference
- a new structure containing updated values.
+ d. Carefully order the updates and the reads so that readers
+ see valid data at all phases of the update. This is often
+ more difficult than it sounds, especially given modern
+ CPUs' tendency to reorder memory references. One must
+ usually liberally sprinkle memory-ordering operations
+ through the code, making it difficult to understand and
+ to test. Where it works, it is better to use things
+ like smp_store_release() and smp_load_acquire(), but in
+ some cases the smp_mb() full memory barrier is required.
+
+ As noted earlier, it is usually better to group the
+ changing data into a separate structure, so that the
+ change may be made to appear atomic by updating a pointer
+ to reference a new structure containing updated values.
4. Weakly ordered CPUs pose special challenges. Almost all CPUs
are weakly ordered -- even x86 CPUs allow later loads to be
@@ -188,26 +200,28 @@ over a rather long period of time, but improvements are always welcome!
when publicizing a pointer to a structure that can
be traversed by an RCU read-side critical section.
-5. If call_rcu() or call_srcu() is used, the callback function will
- be called from softirq context. In particular, it cannot block.
+5. If any of call_rcu(), call_srcu(), call_rcu_tasks(), or
+ call_rcu_tasks_trace() is used, the callback function may be
+ invoked from softirq context, and in any case with bottom halves
+ disabled. In particular, this callback function cannot block.
If you need the callback to block, run that code in a workqueue
handler scheduled from the callback. The queue_rcu_work()
function does this for you in the case of call_rcu().
6. Since synchronize_rcu() can block, it cannot be called
from any sort of irq context. The same rule applies
- for synchronize_srcu(), synchronize_rcu_expedited(), and
- synchronize_srcu_expedited().
+ for synchronize_srcu(), synchronize_rcu_expedited(),
+ synchronize_srcu_expedited(), synchronize_rcu_tasks(),
+ synchronize_rcu_tasks_rude(), and synchronize_rcu_tasks_trace().
The expedited forms of these primitives have the same semantics
- as the non-expedited forms, but expediting is both expensive and
- (with the exception of synchronize_srcu_expedited()) unfriendly
- to real-time workloads. Use of the expedited primitives should
- be restricted to rare configuration-change operations that would
- not normally be undertaken while a real-time workload is running.
- However, real-time workloads can use rcupdate.rcu_normal kernel
- boot parameter to completely disable expedited grace periods,
- though this might have performance implications.
+ as the non-expedited forms, but expediting is more CPU intensive.
+ Use of the expedited primitives should be restricted to rare
+ configuration-change operations that would not normally be
+ undertaken while a real-time workload is running. Note that
+ IPI-sensitive real-time workloads can use the rcupdate.rcu_normal
+ kernel boot parameter to completely disable expedited grace
+ periods, though this might have performance implications.
In particular, if you find yourself invoking one of the expedited
primitives repeatedly in a loop, please do everyone a favor:
@@ -215,8 +229,9 @@ over a rather long period of time, but improvements are always welcome!
a single non-expedited primitive to cover the entire batch.
This will very likely be faster than the loop containing the
expedited primitive, and will be much much easier on the rest
- of the system, especially to real-time workloads running on
- the rest of the system.
+ of the system, especially to real-time workloads running on the
+ rest of the system. Alternatively, instead use asynchronous
+ primitives such as call_rcu().
7. As of v4.20, a given kernel implements only one RCU flavor, which
is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y.
@@ -232,14 +247,22 @@ over a rather long period of time, but improvements are always welcome!
srcu_struct. The rules for the expedited RCU grace-period-wait
primitives are the same as for their non-expedited counterparts.
- If the updater uses call_rcu_tasks() or synchronize_rcu_tasks(),
- then the readers must refrain from executing voluntary
- context switches, that is, from blocking. If the updater uses
- call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then
- the corresponding readers must use rcu_read_lock_trace() and
- rcu_read_unlock_trace(). If an updater uses call_rcu_tasks_rude()
- or synchronize_rcu_tasks_rude(), then the corresponding readers
- must use anything that disables interrupts.
+ Similarly, it is necessary to correctly use the RCU Tasks flavors:
+
+ a. If the updater uses synchronize_rcu_tasks() or
+ call_rcu_tasks(), then the readers must refrain from
+ executing voluntary context switches, that is, from
+ blocking.
+
+ b. If the updater uses call_rcu_tasks_trace()
+ or synchronize_rcu_tasks_trace(), then the
+ corresponding readers must use rcu_read_lock_trace()
+ and rcu_read_unlock_trace().
+
+ c. If an updater uses synchronize_rcu_tasks_rude(),
+ then the corresponding readers must use anything that
+ disables preemption, for example, preempt_disable()
+ and preempt_enable().
Mixing things up will result in confusion and broken kernels, and
has even resulted in an exploitable security issue. Therefore,
@@ -253,15 +276,16 @@ over a rather long period of time, but improvements are always welcome!
that this usage is safe is that readers can use anything that
disables BH when updaters use call_rcu() or synchronize_rcu().
-8. Although synchronize_rcu() is slower than is call_rcu(), it
- usually results in simpler code. So, unless update performance is
- critically important, the updaters cannot block, or the latency of
- synchronize_rcu() is visible from userspace, synchronize_rcu()
- should be used in preference to call_rcu(). Furthermore,
- kfree_rcu() usually results in even simpler code than does
- synchronize_rcu() without synchronize_rcu()'s multi-millisecond
- latency. So please take advantage of kfree_rcu()'s "fire and
- forget" memory-freeing capabilities where it applies.
+8. Although synchronize_rcu() is slower than is call_rcu(),
+ it usually results in simpler code. So, unless update
+ performance is critically important, the updaters cannot block,
+ or the latency of synchronize_rcu() is visible from userspace,
+ synchronize_rcu() should be used in preference to call_rcu().
+ Furthermore, kfree_rcu() and kvfree_rcu() usually result
+ in even simpler code than does synchronize_rcu() without
+ synchronize_rcu()'s multi-millisecond latency. So please take
+ advantage of kfree_rcu()'s and kvfree_rcu()'s "fire and forget"
+ memory-freeing capabilities where it applies.
An especially important property of the synchronize_rcu()
primitive is that it automatically self-limits: if grace periods
@@ -271,8 +295,8 @@ over a rather long period of time, but improvements are always welcome!
cases where grace periods are delayed, as failing to do so can
result in excessive realtime latencies or even OOM conditions.
- Ways of gaining this self-limiting property when using call_rcu()
- include:
+ Ways of gaining this self-limiting property when using call_rcu(),
+ kfree_rcu(), or kvfree_rcu() include:
a. Keeping a count of the number of data-structure elements
used by the RCU-protected data structure, including
@@ -304,18 +328,19 @@ over a rather long period of time, but improvements are always welcome!
here is that superuser already has lots of ways to crash
the machine.
- d. Periodically invoke synchronize_rcu(), permitting a limited
- number of updates per grace period. Better yet, periodically
- invoke rcu_barrier() to wait for all outstanding callbacks.
+ d. Periodically invoke rcu_barrier(), permitting a limited
+ number of updates per grace period.
- The same cautions apply to call_srcu() and kfree_rcu().
+ The same cautions apply to call_srcu(), call_rcu_tasks(), and
+ call_rcu_tasks_trace(). This is why there is an srcu_barrier(),
+ rcu_barrier_tasks(), and rcu_barrier_tasks_trace(), respectively.
- Note that although these primitives do take action to avoid memory
- exhaustion when any given CPU has too many callbacks, a determined
- user could still exhaust memory. This is especially the case
- if a system with a large number of CPUs has been configured to
- offload all of its RCU callbacks onto a single CPU, or if the
- system has relatively little free memory.
+ Note that although these primitives do take action to avoid
+ memory exhaustion when any given CPU has too many callbacks,
+ a determined user or administrator can still exhaust memory.
+ This is especially the case if a system with a large number of
+ CPUs has been configured to offload all of its RCU callbacks onto
+ a single CPU, or if the system has relatively little free memory.
9. All RCU list-traversal primitives, which include
rcu_dereference(), list_for_each_entry_rcu(), and
@@ -344,14 +369,14 @@ over a rather long period of time, but improvements are always welcome!
and you don't hold the appropriate update-side lock, you *must*
use the "_rcu()" variants of the list macros. Failing to do so
will break Alpha, cause aggressive compilers to generate bad code,
- and confuse people trying to read your code.
+ and confuse people trying to understand your code.
11. Any lock acquired by an RCU callback must be acquired elsewhere
- with softirq disabled, e.g., via spin_lock_irqsave(),
- spin_lock_bh(), etc. Failing to disable softirq on a given
- acquisition of that lock will result in deadlock as soon as
- the RCU softirq handler happens to run your RCU callback while
- interrupting that acquisition's critical section.
+ with softirq disabled, e.g., via spin_lock_bh(). Failing to
+ disable softirq on a given acquisition of that lock will result
+ in deadlock as soon as the RCU softirq handler happens to run
+ your RCU callback while interrupting that acquisition's critical
+ section.
12. RCU callbacks can be and are executed in parallel. In many cases,
the callback code simply wrappers around kfree(), so that this
@@ -362,28 +387,43 @@ over a rather long period of time, but improvements are always welcome!
to safely access and/or modify that data structure.
Do not assume that RCU callbacks will be executed on the same
- CPU that executed the corresponding call_rcu() or call_srcu().
- For example, if a given CPU goes offline while having an RCU
- callback pending, then that RCU callback will execute on some
- surviving CPU. (If this was not the case, a self-spawning RCU
- callback would prevent the victim CPU from ever going offline.)
- Furthermore, CPUs designated by rcu_nocbs= might well *always*
- have their RCU callbacks executed on some other CPUs, in fact,
- for some real-time workloads, this is the whole point of using
- the rcu_nocbs= kernel boot parameter.
-
-13. Unlike other forms of RCU, it *is* permissible to block in an
+ CPU that executed the corresponding call_rcu(), call_srcu(),
+ call_rcu_tasks(), or call_rcu_tasks_trace(). For example, if
+ a given CPU goes offline while having an RCU callback pending,
+ then that RCU callback will execute on some surviving CPU.
+ (If this was not the case, a self-spawning RCU callback would
+ prevent the victim CPU from ever going offline.) Furthermore,
+ CPUs designated by rcu_nocbs= might well *always* have their
+ RCU callbacks executed on some other CPUs, in fact, for some
+ real-time workloads, this is the whole point of using the
+ rcu_nocbs= kernel boot parameter.
+
+ In addition, do not assume that callbacks queued in a given order
+ will be invoked in that order, even if they all are queued on the
+ same CPU. Furthermore, do not assume that same-CPU callbacks will
+ be invoked serially. For example, in recent kernels, CPUs can be
+ switched between offloaded and de-offloaded callback invocation,
+ and while a given CPU is undergoing such a switch, its callbacks
+ might be concurrently invoked by that CPU's softirq handler and
+ that CPU's rcuo kthread. At such times, that CPU's callbacks
+ might be executed both concurrently and out of order.
+
+13. Unlike most flavors of RCU, it *is* permissible to block in an
SRCU read-side critical section (demarked by srcu_read_lock()
and srcu_read_unlock()), hence the "SRCU": "sleepable RCU".
- Please note that if you don't need to sleep in read-side critical
- sections, you should be using RCU rather than SRCU, because RCU
- is almost always faster and easier to use than is SRCU.
-
- Also unlike other forms of RCU, explicit initialization and
- cleanup is required either at build time via DEFINE_SRCU()
- or DEFINE_STATIC_SRCU() or at runtime via init_srcu_struct()
- and cleanup_srcu_struct(). These last two are passed a
- "struct srcu_struct" that defines the scope of a given
+ As with RCU, guard(srcu)() and scoped_guard(srcu) forms are
+ available, and often provide greater ease of use. Please note
+ that if you don't need to sleep in read-side critical sections,
+ you should be using RCU rather than SRCU, because RCU is almost
+ always faster and easier to use than is SRCU.
+
+ Also unlike other forms of RCU, explicit initialization
+ and cleanup is required either at build time via
+ DEFINE_SRCU(), DEFINE_STATIC_SRCU(), DEFINE_SRCU_FAST(),
+ or DEFINE_STATIC_SRCU_FAST() or at runtime via either
+ init_srcu_struct() or init_srcu_struct_fast() and
+ cleanup_srcu_struct(). These last three are passed a
+ `struct srcu_struct` that defines the scope of a given
SRCU domain. Once initialized, the srcu_struct is passed
to srcu_read_lock(), srcu_read_unlock() synchronize_srcu(),
synchronize_srcu_expedited(), and call_srcu(). A given
@@ -412,6 +452,15 @@ over a rather long period of time, but improvements are always welcome!
never sends IPIs to other CPUs, so it is easier on
real-time workloads than is synchronize_rcu_expedited().
+ It is also permissible to sleep in RCU Tasks Trace read-side
+ critical section, which are delimited by rcu_read_lock_trace()
+ and rcu_read_unlock_trace(). However, this is a specialized
+ flavor of RCU, and you should not use it without first checking
+ with its current users. In most cases, you should instead
+ use SRCU. As with RCU and SRCU, guard(rcu_tasks_trace)() and
+ scoped_guard(rcu_tasks_trace) are available, and often provide
+ greater ease of use.
+
Note that rcu_assign_pointer() relates to SRCU just as it does to
other forms of RCU, but instead of rcu_dereference() you should
use srcu_dereference() in order to avoid lockdep splats.
@@ -442,50 +491,66 @@ over a rather long period of time, but improvements are always welcome!
find problems as follows:
CONFIG_PROVE_LOCKING:
- check that accesses to RCU-protected data
- structures are carried out under the proper RCU
- read-side critical section, while holding the right
- combination of locks, or whatever other conditions
- are appropriate.
+ check that accesses to RCU-protected data structures
+ are carried out under the proper RCU read-side critical
+ section, while holding the right combination of locks,
+ or whatever other conditions are appropriate.
CONFIG_DEBUG_OBJECTS_RCU_HEAD:
- check that you don't pass the
- same object to call_rcu() (or friends) before an RCU
- grace period has elapsed since the last time that you
- passed that same object to call_rcu() (or friends).
+ check that you don't pass the same object to call_rcu()
+ (or friends) before an RCU grace period has elapsed
+ since the last time that you passed that same object to
+ call_rcu() (or friends).
+
+ CONFIG_RCU_STRICT_GRACE_PERIOD:
+ combine with KASAN to check for pointers leaked out
+ of RCU read-side critical sections. This Kconfig
+ option is tough on both performance and scalability,
+ and so is limited to four-CPU systems.
__rcu sparse checks:
- tag the pointer to the RCU-protected data
- structure with __rcu, and sparse will warn you if you
- access that pointer without the services of one of the
- variants of rcu_dereference().
+ tag the pointer to the RCU-protected data structure
+ with __rcu, and sparse will warn you if you access that
+ pointer without the services of one of the variants
+ of rcu_dereference().
These debugging aids can help you find problems that are
otherwise extremely difficult to spot.
-17. If you register a callback using call_rcu() or call_srcu(), and
- pass in a function defined within a loadable module, then it in
- necessary to wait for all pending callbacks to be invoked after
- the last invocation and before unloading that module. Note that
- it is absolutely *not* sufficient to wait for a grace period!
- The current (say) synchronize_rcu() implementation is *not*
- guaranteed to wait for callbacks registered on other CPUs.
- Or even on the current CPU if that CPU recently went offline
- and came back online.
+17. If you pass a callback function defined within a module
+ to one of call_rcu(), call_srcu(), call_rcu_tasks(), or
+ call_rcu_tasks_trace(), then it is necessary to wait for all
+ pending callbacks to be invoked before unloading that module.
+ Note that it is absolutely *not* sufficient to wait for a grace
+ period! For example, synchronize_rcu() implementation is *not*
+ guaranteed to wait for callbacks registered on other CPUs via
+ call_rcu(). Or even on the current CPU if that CPU recently
+ went offline and came back online.
You instead need to use one of the barrier functions:
- call_rcu() -> rcu_barrier()
- call_srcu() -> srcu_barrier()
+ - call_rcu_tasks() -> rcu_barrier_tasks()
+ - call_rcu_tasks_trace() -> rcu_barrier_tasks_trace()
However, these barrier functions are absolutely *not* guaranteed
- to wait for a grace period. In fact, if there are no call_rcu()
- callbacks waiting anywhere in the system, rcu_barrier() is within
- its rights to return immediately.
-
- So if you need to wait for both an RCU grace period and for
- all pre-existing call_rcu() callbacks, you will need to execute
- both rcu_barrier() and synchronize_rcu(), if necessary, using
- something like workqueues to execute them concurrently.
+ to wait for a grace period. For example, if there are no
+ call_rcu() callbacks queued anywhere in the system, rcu_barrier()
+ can and will return immediately.
+
+ So if you need to wait for both a grace period and for all
+ pre-existing callbacks, you will need to invoke both functions,
+ with the pair depending on the flavor of RCU:
+
+ - Either synchronize_rcu() or synchronize_rcu_expedited(),
+ together with rcu_barrier()
+ - Either synchronize_srcu() or synchronize_srcu_expedited(),
+ together with and srcu_barrier()
+ - synchronize_rcu_tasks() and rcu_barrier_tasks()
+ - synchronize_tasks_trace() and rcu_barrier_tasks_trace()
+
+ If necessary, you can use something like workqueues to execute
+ the requisite pair of functions concurrently.
See rcubarrier.rst for more information.
diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst
index e703d3dbe60c..ef26c78507d3 100644
--- a/Documentation/RCU/index.rst
+++ b/Documentation/RCU/index.rst
@@ -1,15 +1,14 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _rcu_concepts:
+.. _rcu_handbook:
============
-RCU concepts
+RCU Handbook
============
.. toctree::
- :maxdepth: 3
+ :maxdepth: 2
- arrayRCU
checklist
lockdep
lockdep-splat
diff --git a/Documentation/RCU/listRCU.rst b/Documentation/RCU/listRCU.rst
index 2a643e293fb4..d8bb98623c12 100644
--- a/Documentation/RCU/listRCU.rst
+++ b/Documentation/RCU/listRCU.rst
@@ -3,11 +3,19 @@
Using RCU to Protect Read-Mostly Linked Lists
=============================================
-One of the best applications of RCU is to protect read-mostly linked lists
-(``struct list_head`` in list.h). One big advantage of this approach
-is that all of the required memory barriers are included for you in
-the list macros. This document describes several applications of RCU,
-with the best fits first.
+One of the most common uses of RCU is protecting read-mostly linked lists
+(``struct list_head`` in list.h). One big advantage of this approach is
+that all of the required memory ordering is provided by the list macros.
+This document describes several list-based RCU use cases.
+
+When iterating a list while holding the rcu_read_lock(), writers may
+modify the list. The reader is guaranteed to see all of the elements
+which were added to the list before they acquired the rcu_read_lock()
+and are still on the list when they drop the rcu_read_unlock().
+Elements which are added to, or removed from the list may or may not
+be seen. If the writer calls list_replace_rcu(), the reader may see
+either the old element or the new element; they will not see both,
+nor will they see neither.
Example 1: Read-mostly list: Deferred Destruction
@@ -35,7 +43,8 @@ The code traversing the list of all processes typically looks like::
}
rcu_read_unlock();
-The simplified code for removing a process from a task list is::
+The simplified and heavily inlined code for removing a process from a
+task list is::
void release_task(struct task_struct *p)
{
@@ -45,39 +54,48 @@ The simplified code for removing a process from a task list is::
call_rcu(&p->rcu, delayed_put_task_struct);
}
-When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` under
-``tasklist_lock`` writer lock protection, to remove the task from the list of
-all tasks. The ``tasklist_lock`` prevents concurrent list additions/removals
-from corrupting the list. Readers using ``for_each_process()`` are not protected
-with the ``tasklist_lock``. To prevent readers from noticing changes in the list
-pointers, the ``task_struct`` object is freed only after one or more grace
-periods elapse (with the help of call_rcu()). This deferring of destruction
-ensures that any readers traversing the list will see valid ``p->tasks.next``
-pointers and deletion/freeing can happen in parallel with traversal of the list.
-This pattern is also called an **existence lock**, since RCU pins the object in
-memory until all existing readers finish.
+When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)``
+via __exit_signal() and __unhash_process() under ``tasklist_lock``
+writer lock protection. The list_del_rcu() invocation removes
+the task from the list of all tasks. The ``tasklist_lock``
+prevents concurrent list additions/removals from corrupting the
+list. Readers using ``for_each_process()`` are not protected with the
+``tasklist_lock``. To prevent readers from noticing changes in the list
+pointers, the ``task_struct`` object is freed only after one or more
+grace periods elapse, with the help of call_rcu(), which is invoked via
+put_task_struct_rcu_user(). This deferring of destruction ensures that
+any readers traversing the list will see valid ``p->tasks.next`` pointers
+and deletion/freeing can happen in parallel with traversal of the list.
+This pattern is also called an **existence lock**, since RCU refrains
+from invoking the delayed_put_task_struct() callback function until
+all existing readers finish, which guarantees that the ``task_struct``
+object in question will remain in existence until after the completion
+of all RCU readers that might possibly have a reference to that object.
Example 2: Read-Side Action Taken Outside of Lock: No In-Place Updates
----------------------------------------------------------------------
-The best applications are cases where, if reader-writer locking were
-used, the read-side lock would be dropped before taking any action
-based on the results of the search. The most celebrated example is
-the routing table. Because the routing table is tracking the state of
-equipment outside of the computer, it will at times contain stale data.
-Therefore, once the route has been computed, there is no need to hold
-the routing table static during transmission of the packet. After all,
-you can hold the routing table static all you want, but that won't keep
-the external Internet from changing, and it is the state of the external
-Internet that really matters. In addition, routing entries are typically
-added or deleted, rather than being modified in place.
-
-A straightforward example of this use of RCU may be found in the
-system-call auditing support. For example, a reader-writer locked
+Some reader-writer locking use cases compute a value while holding
+the read-side lock, but continue to use that value after that lock is
+released. These use cases are often good candidates for conversion
+to RCU. One prominent example involves network packet routing.
+Because the packet-routing data tracks the state of equipment outside
+of the computer, it will at times contain stale data. Therefore, once
+the route has been computed, there is no need to hold the routing table
+static during transmission of the packet. After all, you can hold the
+routing table static all you want, but that won't keep the external
+Internet from changing, and it is the state of the external Internet
+that really matters. In addition, routing entries are typically added
+or deleted, rather than being modified in place. This is a rare example
+of the finite speed of light and the non-zero size of atoms actually
+helping make synchronization be lighter weight.
+
+A straightforward example of this type of RCU use case may be found in
+the system-call auditing support. For example, a reader-writer locked
implementation of ``audit_filter_task()`` might be as follows::
- static enum audit_state audit_filter_task(struct task_struct *tsk)
+ static enum audit_state audit_filter_task(struct task_struct *tsk, char **key)
{
struct audit_entry *e;
enum audit_state state;
@@ -86,6 +104,8 @@ implementation of ``audit_filter_task()`` might be as follows::
/* Note: audit_filter_mutex held by caller. */
list_for_each_entry(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
+ if (state == AUDIT_STATE_RECORD)
+ *key = kstrdup(e->rule.filterkey, GFP_ATOMIC);
read_unlock(&auditsc_lock);
return state;
}
@@ -101,7 +121,7 @@ you are turning auditing off, it is OK to audit a few extra system calls.
This means that RCU can be easily applied to the read side, as follows::
- static enum audit_state audit_filter_task(struct task_struct *tsk)
+ static enum audit_state audit_filter_task(struct task_struct *tsk, char **key)
{
struct audit_entry *e;
enum audit_state state;
@@ -110,6 +130,8 @@ This means that RCU can be easily applied to the read side, as follows::
/* Note: audit_filter_mutex held by caller. */
list_for_each_entry_rcu(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
+ if (state == AUDIT_STATE_RECORD)
+ *key = kstrdup(e->rule.filterkey, GFP_ATOMIC);
rcu_read_unlock();
return state;
}
@@ -118,13 +140,15 @@ This means that RCU can be easily applied to the read side, as follows::
return AUDIT_BUILD_CONTEXT;
}
-The ``read_lock()`` and ``read_unlock()`` calls have become rcu_read_lock()
-and rcu_read_unlock(), respectively, and the list_for_each_entry() has
-become list_for_each_entry_rcu(). The **_rcu()** list-traversal primitives
-insert the read-side memory barriers that are required on DEC Alpha CPUs.
+The read_lock() and read_unlock() calls have become rcu_read_lock()
+and rcu_read_unlock(), respectively, and the list_for_each_entry()
+has become list_for_each_entry_rcu(). The **_rcu()** list-traversal
+primitives add READ_ONCE() and diagnostic checks for incorrect use
+outside of an RCU read-side critical section.
The changes to the update side are also straightforward. A reader-writer lock
-might be used as follows for deletion and insertion::
+might be used as follows for deletion and insertion in these simplified
+versions of audit_del_rule() and audit_add_rule()::
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
@@ -188,16 +212,16 @@ Following are the RCU equivalents for these two functions::
return 0;
}
-Normally, the ``write_lock()`` and ``write_unlock()`` would be replaced by a
+Normally, the write_lock() and write_unlock() would be replaced by a
spin_lock() and a spin_unlock(). But in this case, all callers hold
``audit_filter_mutex``, so no additional locking is required. The
-``auditsc_lock`` can therefore be eliminated, since use of RCU eliminates the
+auditsc_lock can therefore be eliminated, since use of RCU eliminates the
need for writers to exclude readers.
The list_del(), list_add(), and list_add_tail() primitives have been
replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu().
-The **_rcu()** list-manipulation primitives add memory barriers that are needed on
-weakly ordered CPUs (most of them!). The list_del_rcu() primitive omits the
+The **_rcu()** list-manipulation primitives add memory barriers that are
+needed on weakly ordered CPUs. The list_del_rcu() primitive omits the
pointer poisoning debug-assist code that would otherwise cause concurrent
readers to fail spectacularly.
@@ -238,7 +262,9 @@ need to be filled in)::
The RCU version creates a copy, updates the copy, then replaces the old
entry with the newly updated entry. This sequence of actions, allowing
concurrent reads while making a copy to perform an update, is what gives
-RCU (*read-copy update*) its name. The RCU code is as follows::
+RCU (*read-copy update*) its name.
+
+The RCU version of audit_upd_rule() is as follows::
static inline int audit_upd_rule(struct audit_rule *rule,
struct list_head *list,
@@ -267,6 +293,9 @@ RCU (*read-copy update*) its name. The RCU code is as follows::
Again, this assumes that the caller holds ``audit_filter_mutex``. Normally, the
writer lock would become a spinlock in this sort of code.
+The update_lsm_rule() does something very similar, for those who would
+prefer to look at real Linux-kernel code.
+
Another use of this pattern can be found in the openswitch driver's *connection
tracking table* code in ``ct_limit_set()``. The table holds connection tracking
entries and has a limit on the maximum entries. There is one such table
@@ -281,9 +310,10 @@ Example 4: Eliminating Stale Data
---------------------------------
The auditing example above tolerates stale data, as do most algorithms
-that are tracking external state. Because there is a delay from the
-time the external state changes before Linux becomes aware of the change,
-additional RCU-induced staleness is generally not a problem.
+that are tracking external state. After all, given there is a delay
+from the time the external state changes before Linux becomes aware
+of the change, and so as noted earlier, a small quantity of additional
+RCU-induced staleness is generally not a problem.
However, there are many examples where stale data cannot be tolerated.
One example in the Linux kernel is the System V IPC (see the shm_lock()
@@ -302,9 +332,9 @@ Quick Quiz:
If the system-call audit module were to ever need to reject stale data, one way
to accomplish this would be to add a ``deleted`` flag and a ``lock`` spinlock to the
-audit_entry structure, and modify ``audit_filter_task()`` as follows::
+``audit_entry`` structure, and modify audit_filter_task() as follows::
- static enum audit_state audit_filter_task(struct task_struct *tsk)
+ static struct audit_entry *audit_filter_task(struct task_struct *tsk, char **key)
{
struct audit_entry *e;
enum audit_state state;
@@ -316,22 +346,20 @@ audit_entry structure, and modify ``audit_filter_task()`` as follows::
if (e->deleted) {
spin_unlock(&e->lock);
rcu_read_unlock();
- return AUDIT_BUILD_CONTEXT;
+ return NULL;
}
rcu_read_unlock();
- return state;
+ if (state == AUDIT_STATE_RECORD)
+ *key = kstrdup(e->rule.filterkey, GFP_ATOMIC);
+ /* As long as e->lock is held, e is valid and
+ * its value is not stale */
+ return e;
}
}
rcu_read_unlock();
- return AUDIT_BUILD_CONTEXT;
+ return NULL;
}
-Note that this example assumes that entries are only added and deleted.
-Additional mechanism is required to deal correctly with the update-in-place
-performed by ``audit_upd_rule()``. For one thing, ``audit_upd_rule()`` would
-need additional memory barriers to ensure that the list_add_rcu() was really
-executed before the list_del_rcu().
-
The ``audit_del_rule()`` function would need to set the ``deleted`` flag under the
spinlock as follows::
@@ -357,24 +385,32 @@ spinlock as follows::
This too assumes that the caller holds ``audit_filter_mutex``.
+Note that this example assumes that entries are only added and deleted.
+Additional mechanism is required to deal correctly with the update-in-place
+performed by audit_upd_rule(). For one thing, audit_upd_rule() would
+need to hold the locks of both the old ``audit_entry`` and its replacement
+while executing the list_replace_rcu().
+
Example 5: Skipping Stale Objects
---------------------------------
-For some usecases, reader performance can be improved by skipping stale objects
-during read-side list traversal if the object in concern is pending destruction
-after one or more grace periods. One such example can be found in the timerfd
-subsystem. When a ``CLOCK_REALTIME`` clock is reprogrammed - for example due to
-setting of the system time, then all programmed timerfds that depend on this
-clock get triggered and processes waiting on them to expire are woken up in
-advance of their scheduled expiry. To facilitate this, all such timers are added
-to an RCU-managed ``cancel_list`` when they are setup in
+For some use cases, reader performance can be improved by skipping
+stale objects during read-side list traversal, where stale objects
+are those that will be removed and destroyed after one or more grace
+periods. One such example can be found in the timerfd subsystem. When a
+``CLOCK_REALTIME`` clock is reprogrammed (for example due to setting
+of the system time) then all programmed ``timerfds`` that depend on
+this clock get triggered and processes waiting on them are awakened in
+advance of their scheduled expiry. To facilitate this, all such timers
+are added to an RCU-managed ``cancel_list`` when they are setup in
``timerfd_setup_cancel()``::
static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags)
{
spin_lock(&ctx->cancel_lock);
- if ((ctx->clockid == CLOCK_REALTIME &&
+ if ((ctx->clockid == CLOCK_REALTIME ||
+ ctx->clockid == CLOCK_REALTIME_ALARM) &&
(flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
if (!ctx->might_cancel) {
ctx->might_cancel = true;
@@ -382,13 +418,16 @@ to an RCU-managed ``cancel_list`` when they are setup in
list_add_rcu(&ctx->clist, &cancel_list);
spin_unlock(&cancel_lock);
}
+ } else {
+ __timerfd_remove_cancel(ctx);
}
spin_unlock(&ctx->cancel_lock);
}
-When a timerfd is freed (fd is closed), then the ``might_cancel`` flag of the
-timerfd object is cleared, the object removed from the ``cancel_list`` and
-destroyed::
+When a timerfd is freed (fd is closed), then the ``might_cancel``
+flag of the timerfd object is cleared, the object removed from the
+``cancel_list`` and destroyed, as shown in this simplified and inlined
+version of timerfd_release()::
int timerfd_release(struct inode *inode, struct file *file)
{
@@ -403,7 +442,10 @@ destroyed::
}
spin_unlock(&ctx->cancel_lock);
- hrtimer_cancel(&ctx->t.tmr);
+ if (isalarm(ctx))
+ alarm_cancel(&ctx->t.alarm);
+ else
+ hrtimer_cancel(&ctx->t.tmr);
kfree_rcu(ctx, rcu);
return 0;
}
@@ -416,6 +458,7 @@ objects::
void timerfd_clock_was_set(void)
{
+ ktime_t moffs = ktime_mono_to_real(0);
struct timerfd_ctx *ctx;
unsigned long flags;
@@ -424,7 +467,7 @@ objects::
if (!ctx->might_cancel)
continue;
spin_lock_irqsave(&ctx->wqh.lock, flags);
- if (ctx->moffs != ktime_mono_to_real(0)) {
+ if (ctx->moffs != moffs) {
ctx->moffs = KTIME_MAX;
ctx->ticks++;
wake_up_locked_poll(&ctx->wqh, EPOLLIN);
@@ -434,10 +477,10 @@ objects::
rcu_read_unlock();
}
-The key point here is, because RCU-traversal of the ``cancel_list`` happens
-while objects are being added and removed to the list, sometimes the traversal
-can step on an object that has been removed from the list. In this example, it
-is seen that it is better to skip such objects using a flag.
+The key point is that because RCU-protected traversal of the
+``cancel_list`` happens concurrently with object addition and removal,
+sometimes the traversal can access an object that has been removed from
+the list. In this example, a flag is used to skip such objects.
Summary
diff --git a/Documentation/RCU/lockdep-splat.rst b/Documentation/RCU/lockdep-splat.rst
index 2a5c79db57dc..bcbc4b3c88d7 100644
--- a/Documentation/RCU/lockdep-splat.rst
+++ b/Documentation/RCU/lockdep-splat.rst
@@ -10,7 +10,7 @@ misuses of the RCU API, most notably using one of the rcu_dereference()
family to access an RCU-protected pointer without the proper protection.
When such misuse is detected, an lockdep-RCU splat is emitted.
-The usual cause of a lockdep-RCU slat is someone accessing an
+The usual cause of a lockdep-RCU splat is someone accessing an
RCU-protected data structure without either (1) being in the right kind of
RCU read-side critical section or (2) holding the right update-side lock.
This problem can therefore be serious: it might result in random memory
diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst
index a94f55991a71..741b157bbacb 100644
--- a/Documentation/RCU/lockdep.rst
+++ b/Documentation/RCU/lockdep.rst
@@ -17,7 +17,9 @@ state::
rcu_read_lock_held() for normal RCU.
rcu_read_lock_bh_held() for RCU-bh.
rcu_read_lock_sched_held() for RCU-sched.
+ rcu_read_lock_any_held() for any of normal RCU, RCU-bh, and RCU-sched.
srcu_read_lock_held() for SRCU.
+ rcu_read_lock_trace_held() for RCU Tasks Trace.
These functions are conservative, and will therefore return 1 if they
aren't certain (for example, if CONFIG_DEBUG_LOCK_ALLOC is not set).
@@ -53,6 +55,8 @@ checking of rcu_dereference() primitives:
is invoked by both SRCU readers and updaters.
rcu_dereference_raw(p):
Don't check. (Use sparingly, if at all.)
+ rcu_dereference_raw_check(p):
+ Don't do lockdep at all. (Use sparingly, if at all.)
rcu_dereference_protected(p, c):
Use explicit check expression "c", and omit all barriers
and compiler constraints. This is useful when the data
@@ -61,13 +65,12 @@ checking of rcu_dereference() primitives:
rcu_access_pointer(p):
Return the value of the pointer and omit all barriers,
but retain the compiler constraints that prevent duplicating
- or coalescsing. This is useful when testing the
+ or coalescing. This is useful when testing the
value of the pointer itself, for example, against NULL.
The rcu_dereference_check() check expression can be any boolean
-expression, but would normally include a lockdep expression. However,
-any boolean expression can be used. For a moderately ornate example,
-consider the following::
+expression, but would normally include a lockdep expression. For a
+moderately ornate example, consider the following::
file = rcu_dereference_check(fdt->fd[fd],
lockdep_is_held(&files->file_lock) ||
@@ -93,17 +96,17 @@ code, it could instead be written as follows::
atomic_read(&files->count) == 1);
This would verify cases #2 and #3 above, and furthermore lockdep would
-complain if this was used in an RCU read-side critical section unless one
-of these two cases held. Because rcu_dereference_protected() omits all
-barriers and compiler constraints, it generates better code than do the
-other flavors of rcu_dereference(). On the other hand, it is illegal
+complain even if this was used in an RCU read-side critical section unless
+one of these two cases held. Because rcu_dereference_protected() omits
+all barriers and compiler constraints, it generates better code than do
+the other flavors of rcu_dereference(). On the other hand, it is illegal
to use rcu_dereference_protected() if either the RCU-protected pointer
or the RCU-protected data that it points to can change concurrently.
Like rcu_dereference(), when lockdep is enabled, RCU list and hlist
traversal primitives check for being called from within an RCU read-side
critical section. However, a lockdep expression can be passed to them
-as a additional optional argument. With this lockdep expression, these
+as an additional optional argument. With this lockdep expression, these
traversal primitives will complain only if the lockdep expression is
false and they are called from outside any RCU read-side critical section.
diff --git a/Documentation/RCU/rcu.rst b/Documentation/RCU/rcu.rst
index 3cfe01ba9a49..bf6617b330a7 100644
--- a/Documentation/RCU/rcu.rst
+++ b/Documentation/RCU/rcu.rst
@@ -77,15 +77,17 @@ Frequently Asked Questions
search for the string "Patent" in Documentation/RCU/RTFP.txt to find them.
Of these, one was allowed to lapse by the assignee, and the
others have been contributed to the Linux kernel under GPL.
+ Many (but not all) have long since expired.
There are now also LGPL implementations of user-level RCU
available (https://liburcu.org/).
- I hear that RCU needs work in order to support realtime kernels?
- Realtime-friendly RCU can be enabled via the CONFIG_PREEMPT_RCU
+ Realtime-friendly RCU are enabled via the CONFIG_PREEMPTION
kernel configuration parameter.
- Where can I find more information on RCU?
See the Documentation/RCU/RTFP.txt file.
- Or point your browser at (http://www.rdrop.com/users/paulmck/RCU/).
+ Or point your browser at (https://docs.google.com/document/d/1X0lThx8OK0ZgLMqVoXiR4ZrGURHrXK6NyLRbeXe3Xac/edit)
+ or (https://docs.google.com/document/d/1GCdQC8SDbb54W1shjEXqGZ0Rq8a6kIeYutdSIajfpLA/edit?usp=sharing).
diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst
index 81e828c8313b..2524dcdadde2 100644
--- a/Documentation/RCU/rcu_dereference.rst
+++ b/Documentation/RCU/rcu_dereference.rst
@@ -3,13 +3,26 @@
PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference()
===============================================================
-Most of the time, you can use values from rcu_dereference() or one of
-the similar primitives without worries. Dereferencing (prefix "*"),
-field selection ("->"), assignment ("="), address-of ("&"), addition and
-subtraction of constants, and casts all work quite naturally and safely.
-
-It is nevertheless possible to get into trouble with other operations.
-Follow these rules to keep your RCU code working properly:
+Proper care and feeding of address and data dependencies is critically
+important to correct use of things like RCU. To this end, the pointers
+returned from the rcu_dereference() family of primitives carry address and
+data dependencies. These dependencies extend from the rcu_dereference()
+macro's load of the pointer to the later use of that pointer to compute
+either the address of a later memory access (representing an address
+dependency) or the value written by a later memory access (representing
+a data dependency).
+
+Most of the time, these dependencies are preserved, permitting you to
+freely use values from rcu_dereference(). For example, dereferencing
+(prefix "*"), field selection ("->"), assignment ("="), address-of
+("&"), casts, and addition or subtraction of constants all work quite
+naturally and safely. However, because current compilers do not take
+either address or data dependencies into account it is still possible
+to get into trouble.
+
+Follow these rules to preserve the address and data dependencies emanating
+from your calls to rcu_dereference() and friends, thus keeping your RCU
+readers working properly:
- You must use one of the rcu_dereference() family of primitives
to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU
@@ -19,8 +32,9 @@ Follow these rules to keep your RCU code working properly:
can reload the value, and won't your code have fun with two
different values for a single pointer! Without rcu_dereference(),
DEC Alpha can load a pointer, dereference that pointer, and
- return data preceding initialization that preceded the store of
- the pointer.
+ return data preceding initialization that preceded the store
+ of the pointer. (As noted later, in recent kernels READ_ONCE()
+ also prevents DEC Alpha from playing these tricks.)
In addition, the volatile cast in rcu_dereference() prevents the
compiler from deducing the resulting pointer value. Please see
@@ -34,7 +48,7 @@ Follow these rules to keep your RCU code working properly:
takes on the role of the lockless_dereference() primitive that
was removed in v4.15.
-- You are only permitted to use rcu_dereference on pointer values.
+- You are only permitted to use rcu_dereference() on pointer values.
The compiler simply knows too much about integral values to
trust it to carry dependencies through integer operations.
There are a very few exceptions, namely that you can temporarily
@@ -240,6 +254,7 @@ precautions. To see this, consider the following code fragment::
struct foo *q;
int r1, r2;
+ rcu_read_lock();
p = rcu_dereference(gp2);
if (p == NULL)
return;
@@ -248,7 +263,10 @@ precautions. To see this, consider the following code fragment::
if (p == q) {
/* The compiler decides that q->c is same as p->c. */
r2 = p->c; /* Could get 44 on weakly order system. */
+ } else {
+ r2 = p->c - r1; /* Unconditional access to p->c. */
}
+ rcu_read_unlock();
do_something_with(r1, r2);
}
@@ -297,6 +315,7 @@ Then one approach is to use locking, for example, as follows::
struct foo *q;
int r1, r2;
+ rcu_read_lock();
p = rcu_dereference(gp2);
if (p == NULL)
return;
@@ -306,7 +325,12 @@ Then one approach is to use locking, for example, as follows::
if (p == q) {
/* The compiler decides that q->c is same as p->c. */
r2 = p->c; /* Locking guarantees r2 == 144. */
+ } else {
+ spin_lock(&q->lock);
+ r2 = q->c - r1;
+ spin_unlock(&q->lock);
}
+ rcu_read_unlock();
spin_unlock(&p->lock);
do_something_with(r1, r2);
}
@@ -364,7 +388,7 @@ the exact value of "p" even in the not-equals case. This allows the
compiler to make the return values independent of the load from "gp",
in turn destroying the ordering between this load and the loads of the
return values. This can result in "p->b" returning pre-initialization
-garbage values.
+garbage values on weakly ordered systems.
In short, rcu_dereference() is *not* optional when you are going to
dereference the resulting pointer.
@@ -384,7 +408,10 @@ member of the rcu_dereference() to use in various situations:
RCU flavors, an RCU read-side critical section is entered
using rcu_read_lock(), anything that disables bottom halves,
anything that disables interrupts, or anything that disables
- preemption.
+ preemption. Please note that spinlock critical sections
+ are also implied RCU read-side critical sections, even when
+ they are preemptible, as they are in kernels built with
+ CONFIG_PREEMPT_RT=y.
2. If the access might be within an RCU read-side critical section
on the one hand, or protected by (say) my_lock on the other,
@@ -430,7 +457,7 @@ member of the rcu_dereference() to use in various situations:
SPARSE CHECKING OF RCU-PROTECTED POINTERS
-----------------------------------------
-The sparse static-analysis tool checks for direct access to RCU-protected
+The sparse static-analysis tool checks for non-RCU access to RCU-protected
pointers, which can result in "interesting" bugs due to compiler
optimizations involving invented loads and perhaps also load tearing.
For example, suppose someone mistakenly does something like this::
diff --git a/Documentation/RCU/rcubarrier.rst b/Documentation/RCU/rcubarrier.rst
index 3b4a24877496..12a7b059654f 100644
--- a/Documentation/RCU/rcubarrier.rst
+++ b/Documentation/RCU/rcubarrier.rst
@@ -5,37 +5,12 @@ RCU and Unloadable Modules
[Originally published in LWN Jan. 14, 2007: http://lwn.net/Articles/217484/]
-RCU (read-copy update) is a synchronization mechanism that can be thought
-of as a replacement for read-writer locking (among other things), but with
-very low-overhead readers that are immune to deadlock, priority inversion,
-and unbounded latency. RCU read-side critical sections are delimited
-by rcu_read_lock() and rcu_read_unlock(), which, in non-CONFIG_PREEMPTION
-kernels, generate no code whatsoever.
-
-This means that RCU writers are unaware of the presence of concurrent
-readers, so that RCU updates to shared data must be undertaken quite
-carefully, leaving an old version of the data structure in place until all
-pre-existing readers have finished. These old versions are needed because
-such readers might hold a reference to them. RCU updates can therefore be
-rather expensive, and RCU is thus best suited for read-mostly situations.
-
-How can an RCU writer possibly determine when all readers are finished,
-given that readers might well leave absolutely no trace of their
-presence? There is a synchronize_rcu() primitive that blocks until all
-pre-existing readers have completed. An updater wishing to delete an
-element p from a linked list might do the following, while holding an
-appropriate lock, of course::
-
- list_del_rcu(p);
- synchronize_rcu();
- kfree(p);
-
-But the above code cannot be used in IRQ context -- the call_rcu()
-primitive must be used instead. This primitive takes a pointer to an
-rcu_head struct placed within the RCU-protected data structure and
-another pointer to a function that may be invoked later to free that
-structure. Code to delete an element p from the linked list from IRQ
-context might then be as follows::
+RCU updaters sometimes use call_rcu() to initiate an asynchronous wait for
+a grace period to elapse. This primitive takes a pointer to an rcu_head
+struct placed within the RCU-protected data structure and another pointer
+to a function that may be invoked later to free that structure. Code to
+delete an element p from the linked list from IRQ context might then be
+as follows::
list_del_rcu(p);
call_rcu(&p->rcu, p_callback);
@@ -54,7 +29,7 @@ IRQ context. The function p_callback() might be defined as follows::
Unloading Modules That Use call_rcu()
-------------------------------------
-But what if p_callback is defined in an unloadable module?
+But what if the p_callback() function is defined in an unloadable module?
If we unload the module while some RCU callbacks are pending,
the CPUs executing these callbacks are going to be severely
@@ -67,20 +42,21 @@ grace period to elapse, it does not wait for the callbacks to complete.
One might be tempted to try several back-to-back synchronize_rcu()
calls, but this is still not guaranteed to work. If there is a very
-heavy RCU-callback load, then some of the callbacks might be deferred
-in order to allow other processing to proceed. Such deferral is required
-in realtime kernels in order to avoid excessive scheduling latencies.
+heavy RCU-callback load, then some of the callbacks might be deferred in
+order to allow other processing to proceed. For but one example, such
+deferral is required in realtime kernels in order to avoid excessive
+scheduling latencies.
rcu_barrier()
-------------
-We instead need the rcu_barrier() primitive. Rather than waiting for
-a grace period to elapse, rcu_barrier() waits for all outstanding RCU
-callbacks to complete. Please note that rcu_barrier() does **not** imply
-synchronize_rcu(), in particular, if there are no RCU callbacks queued
-anywhere, rcu_barrier() is within its rights to return immediately,
-without waiting for a grace period to elapse.
+This situation can be handled by the rcu_barrier() primitive. Rather
+than waiting for a grace period to elapse, rcu_barrier() waits for all
+outstanding RCU callbacks to complete. Please note that rcu_barrier()
+does **not** imply synchronize_rcu(), in particular, if there are no RCU
+callbacks queued anywhere, rcu_barrier() is within its rights to return
+immediately, without waiting for anything, let alone a grace period.
Pseudo-code using rcu_barrier() is as follows:
@@ -89,83 +65,86 @@ Pseudo-code using rcu_barrier() is as follows:
3. Allow the module to be unloaded.
There is also an srcu_barrier() function for SRCU, and you of course
-must match the flavor of rcu_barrier() with that of call_rcu(). If your
-module uses multiple flavors of call_rcu(), then it must also use multiple
-flavors of rcu_barrier() when unloading that module. For example, if
-it uses call_rcu(), call_srcu() on srcu_struct_1, and call_srcu() on
-srcu_struct_2, then the following three lines of code will be required
-when unloading::
-
- 1 rcu_barrier();
- 2 srcu_barrier(&srcu_struct_1);
- 3 srcu_barrier(&srcu_struct_2);
-
-The rcutorture module makes use of rcu_barrier() in its exit function
-as follows::
-
- 1 static void
- 2 rcu_torture_cleanup(void)
- 3 {
- 4 int i;
- 5
- 6 fullstop = 1;
- 7 if (shuffler_task != NULL) {
- 8 VERBOSE_PRINTK_STRING("Stopping rcu_torture_shuffle task");
- 9 kthread_stop(shuffler_task);
- 10 }
- 11 shuffler_task = NULL;
+must match the flavor of srcu_barrier() with that of call_srcu().
+If your module uses multiple srcu_struct structures, then it must also
+use multiple invocations of srcu_barrier() when unloading that module.
+For example, if it uses call_rcu(), call_srcu() on srcu_struct_1, and
+call_srcu() on srcu_struct_2, then the following three lines of code
+will be required when unloading::
+
+ 1 rcu_barrier();
+ 2 srcu_barrier(&srcu_struct_1);
+ 3 srcu_barrier(&srcu_struct_2);
+
+If latency is of the essence, workqueues could be used to run these
+three functions concurrently.
+
+An ancient version of the rcutorture module makes use of rcu_barrier()
+in its exit function as follows::
+
+ 1 static void
+ 2 rcu_torture_cleanup(void)
+ 3 {
+ 4 int i;
+ 5
+ 6 fullstop = 1;
+ 7 if (shuffler_task != NULL) {
+ 8 VERBOSE_PRINTK_STRING("Stopping rcu_torture_shuffle task");
+ 9 kthread_stop(shuffler_task);
+ 10 }
+ 11 shuffler_task = NULL;
12
- 13 if (writer_task != NULL) {
- 14 VERBOSE_PRINTK_STRING("Stopping rcu_torture_writer task");
- 15 kthread_stop(writer_task);
- 16 }
- 17 writer_task = NULL;
+ 13 if (writer_task != NULL) {
+ 14 VERBOSE_PRINTK_STRING("Stopping rcu_torture_writer task");
+ 15 kthread_stop(writer_task);
+ 16 }
+ 17 writer_task = NULL;
18
- 19 if (reader_tasks != NULL) {
- 20 for (i = 0; i < nrealreaders; i++) {
- 21 if (reader_tasks[i] != NULL) {
- 22 VERBOSE_PRINTK_STRING(
- 23 "Stopping rcu_torture_reader task");
- 24 kthread_stop(reader_tasks[i]);
- 25 }
- 26 reader_tasks[i] = NULL;
- 27 }
- 28 kfree(reader_tasks);
- 29 reader_tasks = NULL;
- 30 }
- 31 rcu_torture_current = NULL;
+ 19 if (reader_tasks != NULL) {
+ 20 for (i = 0; i < nrealreaders; i++) {
+ 21 if (reader_tasks[i] != NULL) {
+ 22 VERBOSE_PRINTK_STRING(
+ 23 "Stopping rcu_torture_reader task");
+ 24 kthread_stop(reader_tasks[i]);
+ 25 }
+ 26 reader_tasks[i] = NULL;
+ 27 }
+ 28 kfree(reader_tasks);
+ 29 reader_tasks = NULL;
+ 30 }
+ 31 rcu_torture_current = NULL;
32
- 33 if (fakewriter_tasks != NULL) {
- 34 for (i = 0; i < nfakewriters; i++) {
- 35 if (fakewriter_tasks[i] != NULL) {
- 36 VERBOSE_PRINTK_STRING(
- 37 "Stopping rcu_torture_fakewriter task");
- 38 kthread_stop(fakewriter_tasks[i]);
- 39 }
- 40 fakewriter_tasks[i] = NULL;
- 41 }
- 42 kfree(fakewriter_tasks);
- 43 fakewriter_tasks = NULL;
- 44 }
+ 33 if (fakewriter_tasks != NULL) {
+ 34 for (i = 0; i < nfakewriters; i++) {
+ 35 if (fakewriter_tasks[i] != NULL) {
+ 36 VERBOSE_PRINTK_STRING(
+ 37 "Stopping rcu_torture_fakewriter task");
+ 38 kthread_stop(fakewriter_tasks[i]);
+ 39 }
+ 40 fakewriter_tasks[i] = NULL;
+ 41 }
+ 42 kfree(fakewriter_tasks);
+ 43 fakewriter_tasks = NULL;
+ 44 }
45
- 46 if (stats_task != NULL) {
- 47 VERBOSE_PRINTK_STRING("Stopping rcu_torture_stats task");
- 48 kthread_stop(stats_task);
- 49 }
- 50 stats_task = NULL;
+ 46 if (stats_task != NULL) {
+ 47 VERBOSE_PRINTK_STRING("Stopping rcu_torture_stats task");
+ 48 kthread_stop(stats_task);
+ 49 }
+ 50 stats_task = NULL;
51
- 52 /* Wait for all RCU callbacks to fire. */
- 53 rcu_barrier();
+ 52 /* Wait for all RCU callbacks to fire. */
+ 53 rcu_barrier();
54
- 55 rcu_torture_stats_print(); /* -After- the stats thread is stopped! */
+ 55 rcu_torture_stats_print(); /* -After- the stats thread is stopped! */
56
- 57 if (cur_ops->cleanup != NULL)
- 58 cur_ops->cleanup();
- 59 if (atomic_read(&n_rcu_torture_error))
- 60 rcu_torture_print_module_parms("End of test: FAILURE");
- 61 else
- 62 rcu_torture_print_module_parms("End of test: SUCCESS");
- 63 }
+ 57 if (cur_ops->cleanup != NULL)
+ 58 cur_ops->cleanup();
+ 59 if (atomic_read(&n_rcu_torture_error))
+ 60 rcu_torture_print_module_parms("End of test: FAILURE");
+ 61 else
+ 62 rcu_torture_print_module_parms("End of test: SUCCESS");
+ 63 }
Line 6 sets a global variable that prevents any RCU callbacks from
re-posting themselves. This will not be necessary in most cases, since
@@ -190,16 +169,17 @@ Quick Quiz #1:
:ref:`Answer to Quick Quiz #1 <answer_rcubarrier_quiz_1>`
Your module might have additional complications. For example, if your
-module invokes call_rcu() from timers, you will need to first cancel all
-the timers, and only then invoke rcu_barrier() to wait for any remaining
+module invokes call_rcu() from timers, you will need to first refrain
+from posting new timers, cancel (or wait for) all the already-posted
+timers, and only then invoke rcu_barrier() to wait for any remaining
RCU callbacks to complete.
-Of course, if you module uses call_rcu(), you will need to invoke
+Of course, if your module uses call_rcu(), you will need to invoke
rcu_barrier() before unloading. Similarly, if your module uses
call_srcu(), you will need to invoke srcu_barrier() before unloading,
and on the same srcu_struct structure. If your module uses call_rcu()
-**and** call_srcu(), then you will need to invoke rcu_barrier() **and**
-srcu_barrier().
+**and** call_srcu(), then (as noted above) you will need to invoke
+rcu_barrier() **and** srcu_barrier().
Implementing rcu_barrier()
@@ -211,27 +191,40 @@ queues. His implementation queues an RCU callback on each of the per-CPU
callback queues, and then waits until they have all started executing, at
which point, all earlier RCU callbacks are guaranteed to have completed.
-The original code for rcu_barrier() was as follows::
-
- 1 void rcu_barrier(void)
- 2 {
- 3 BUG_ON(in_interrupt());
- 4 /* Take cpucontrol mutex to protect against CPU hotplug */
- 5 mutex_lock(&rcu_barrier_mutex);
- 6 init_completion(&rcu_barrier_completion);
- 7 atomic_set(&rcu_barrier_cpu_count, 0);
- 8 on_each_cpu(rcu_barrier_func, NULL, 0, 1);
- 9 wait_for_completion(&rcu_barrier_completion);
- 10 mutex_unlock(&rcu_barrier_mutex);
- 11 }
-
-Line 3 verifies that the caller is in process context, and lines 5 and 10
+The original code for rcu_barrier() was roughly as follows::
+
+ 1 void rcu_barrier(void)
+ 2 {
+ 3 BUG_ON(in_interrupt());
+ 4 /* Take cpucontrol mutex to protect against CPU hotplug */
+ 5 mutex_lock(&rcu_barrier_mutex);
+ 6 init_completion(&rcu_barrier_completion);
+ 7 atomic_set(&rcu_barrier_cpu_count, 1);
+ 8 on_each_cpu(rcu_barrier_func, NULL, 0, 1);
+ 9 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
+ 10 complete(&rcu_barrier_completion);
+ 11 wait_for_completion(&rcu_barrier_completion);
+ 12 mutex_unlock(&rcu_barrier_mutex);
+ 13 }
+
+Line 3 verifies that the caller is in process context, and lines 5 and 12
use rcu_barrier_mutex to ensure that only one rcu_barrier() is using the
global completion and counters at a time, which are initialized on lines
6 and 7. Line 8 causes each CPU to invoke rcu_barrier_func(), which is
shown below. Note that the final "1" in on_each_cpu()'s argument list
ensures that all the calls to rcu_barrier_func() will have completed
-before on_each_cpu() returns. Line 9 then waits for the completion.
+before on_each_cpu() returns. Line 9 removes the initial count from
+rcu_barrier_cpu_count, and if this count is now zero, line 10 finalizes
+the completion, which prevents line 11 from blocking. Either way,
+line 11 then waits (if needed) for the completion.
+
+.. _rcubarrier_quiz_2:
+
+Quick Quiz #2:
+ Why doesn't line 8 initialize rcu_barrier_cpu_count to zero,
+ thereby avoiding the need for lines 9 and 10?
+
+:ref:`Answer to Quick Quiz #2 <answer_rcubarrier_quiz_2>`
This code was rewritten in 2008 and several times thereafter, but this
still gives the general idea.
@@ -239,21 +232,21 @@ still gives the general idea.
The rcu_barrier_func() runs on each CPU, where it invokes call_rcu()
to post an RCU callback, as follows::
- 1 static void rcu_barrier_func(void *notused)
- 2 {
- 3 int cpu = smp_processor_id();
- 4 struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
- 5 struct rcu_head *head;
- 6
- 7 head = &rdp->barrier;
- 8 atomic_inc(&rcu_barrier_cpu_count);
- 9 call_rcu(head, rcu_barrier_callback);
- 10 }
+ 1 static void rcu_barrier_func(void *notused)
+ 2 {
+ 3 int cpu = smp_processor_id();
+ 4 struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
+ 5 struct rcu_head *head;
+ 6
+ 7 head = &rdp->barrier;
+ 8 atomic_inc(&rcu_barrier_cpu_count);
+ 9 call_rcu(head, rcu_barrier_callback);
+ 10 }
Lines 3 and 4 locate RCU's internal per-CPU rcu_data structure,
which contains the struct rcu_head that needed for the later call to
call_rcu(). Line 7 picks up a pointer to this struct rcu_head, and line
-8 increments a global counter. This counter will later be decremented
+8 increments the global counter. This counter will later be decremented
by the callback. Line 9 then registers the rcu_barrier_callback() on
the current CPU's queue.
@@ -261,33 +254,34 @@ The rcu_barrier_callback() function simply atomically decrements the
rcu_barrier_cpu_count variable and finalizes the completion when it
reaches zero, as follows::
- 1 static void rcu_barrier_callback(struct rcu_head *notused)
- 2 {
- 3 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
- 4 complete(&rcu_barrier_completion);
- 5 }
+ 1 static void rcu_barrier_callback(struct rcu_head *notused)
+ 2 {
+ 3 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
+ 4 complete(&rcu_barrier_completion);
+ 5 }
-.. _rcubarrier_quiz_2:
+.. _rcubarrier_quiz_3:
-Quick Quiz #2:
+Quick Quiz #3:
What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in
rcu_barrier() returning prematurely?
-:ref:`Answer to Quick Quiz #2 <answer_rcubarrier_quiz_2>`
+:ref:`Answer to Quick Quiz #3 <answer_rcubarrier_quiz_3>`
The current rcu_barrier() implementation is more complex, due to the need
to avoid disturbing idle CPUs (especially on battery-powered systems)
and the need to minimally disturb non-idle CPUs in real-time systems.
-However, the code above illustrates the concepts.
+In addition, a great many optimizations have been applied. However,
+the code above illustrates the concepts.
rcu_barrier() Summary
---------------------
-The rcu_barrier() primitive has seen relatively little use, since most
+The rcu_barrier() primitive is used relatively infrequently, since most
code using RCU is in the core kernel rather than in modules. However, if
you are using RCU from an unloadable module, you need to use rcu_barrier()
so that your module may be safely unloaded.
@@ -302,7 +296,8 @@ Quick Quiz #1:
Is there any other situation where rcu_barrier() might
be required?
-Answer: Interestingly enough, rcu_barrier() was not originally
+Answer:
+ Interestingly enough, rcu_barrier() was not originally
implemented for module unloading. Nikita Danilov was using
RCU in a filesystem, which resulted in a similar situation at
filesystem-unmount time. Dipankar Sarma coded up rcu_barrier()
@@ -318,13 +313,45 @@ Answer: Interestingly enough, rcu_barrier() was not originally
.. _answer_rcubarrier_quiz_2:
Quick Quiz #2:
+ Why doesn't line 8 initialize rcu_barrier_cpu_count to zero,
+ thereby avoiding the need for lines 9 and 10?
+
+Answer:
+ Suppose that the on_each_cpu() function shown on line 8 was
+ delayed, so that CPU 0's rcu_barrier_func() executed and
+ the corresponding grace period elapsed, all before CPU 1's
+ rcu_barrier_func() started executing. This would result in
+ rcu_barrier_cpu_count being decremented to zero, so that line
+ 11's wait_for_completion() would return immediately, failing to
+ wait for CPU 1's callbacks to be invoked.
+
+ Note that this was not a problem when the rcu_barrier() code
+ was first added back in 2005. This is because on_each_cpu()
+ disables preemption, which acted as an RCU read-side critical
+ section, thus preventing CPU 0's grace period from completing
+ until on_each_cpu() had dealt with all of the CPUs.
+
+ However, with the RCU flavor consolidation around v4.20, this
+ possibility was once again ruled out, because the consolidated
+ RCU once again waits on nonpreemptible regions of code.
+
+ Nevertheless, that extra count might still be a good idea.
+ Relying on these sort of accidents of implementation can result
+ in later surprise bugs when the implementation changes.
+
+:ref:`Back to Quick Quiz #2 <rcubarrier_quiz_2>`
+
+.. _answer_rcubarrier_quiz_3:
+
+Quick Quiz #3:
What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in
rcu_barrier() returning prematurely?
-Answer: This cannot happen. The reason is that on_each_cpu() has its last
+Answer:
+ This cannot happen. The reason is that on_each_cpu() has its last
argument, the wait flag, set to "1". This flag is passed through
to smp_call_function() and further to smp_call_function_on_cpu(),
causing this latter to spin until the cross-CPU invocation of
@@ -336,18 +363,15 @@ Answer: This cannot happen. The reason is that on_each_cpu() has its last
Therefore, on_each_cpu() disables preemption across its call
to smp_call_function() and also across the local call to
- rcu_barrier_func(). This prevents the local CPU from context
- switching, again preventing grace periods from completing. This
+ rcu_barrier_func(). Because recent RCU implementations treat
+ preemption-disabled regions of code as RCU read-side critical
+ sections, this prevents grace periods from completing. This
means that all CPUs have executed rcu_barrier_func() before
the first rcu_barrier_callback() can possibly execute, in turn
preventing rcu_barrier_cpu_count from prematurely reaching zero.
- Currently, -rt implementations of RCU keep but a single global
- queue for RCU callbacks, and thus do not suffer from this
- problem. However, when the -rt RCU eventually does have per-CPU
- callback queues, things will have to change. One simple change
- is to add an rcu_read_lock() before line 8 of rcu_barrier()
- and an rcu_read_unlock() after line 8 of this same function. If
- you can think of a better change, please let me know!
+ But if on_each_cpu() ever decides to forgo disabling preemption,
+ as might well happen due to real-time latency considerations,
+ initializing rcu_barrier_cpu_count to one will save the day.
-:ref:`Back to Quick Quiz #2 <rcubarrier_quiz_2>`
+:ref:`Back to Quick Quiz #3 <rcubarrier_quiz_3>`
diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst
index ca4692775ad4..21e40fcc08de 100644
--- a/Documentation/RCU/rculist_nulls.rst
+++ b/Documentation/RCU/rculist_nulls.rst
@@ -14,23 +14,34 @@ Using 'nulls'
=============
Using special makers (called 'nulls') is a convenient way
-to solve following problem :
+to solve following problem.
-A typical RCU linked list managing objects which are
-allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can
-use following algos :
+Without 'nulls', a typical RCU linked list managing objects which are
+allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following
+algorithms. Following examples assume 'obj' is a pointer to such
+objects, which is having below type.
-1) Lookup algo
---------------
+::
+
+ struct object {
+ struct hlist_node obj_node;
+ atomic_t refcnt;
+ unsigned int key;
+ };
+
+1) Lookup algorithm
+-------------------
::
- rcu_read_lock()
begin:
+ rcu_read_lock();
obj = lockless_lookup(key);
if (obj) {
- if (!try_get_ref(obj)) // might fail for free objects
+ if (!try_get_ref(obj)) { // might fail for free objects
+ rcu_read_unlock();
goto begin;
+ }
/*
* Because a writer could delete object, and a writer could
* reuse these object before the RCU grace period, we
@@ -38,6 +49,7 @@ use following algos :
*/
if (obj->key != key) { // not the object we expected
put_ref(obj);
+ rcu_read_unlock();
goto begin;
}
}
@@ -52,9 +64,9 @@ but a version with an additional memory barrier (smp_rmb())
{
struct hlist_node *node, *next;
for (pos = rcu_dereference((head)->first);
- pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
- ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
- pos = rcu_dereference(next))
+ pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
+ ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
+ pos = rcu_dereference(next))
if (obj->key == key)
return obj;
return NULL;
@@ -64,11 +76,11 @@ And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb()::
struct hlist_node *node;
for (pos = rcu_dereference((head)->first);
- pos && ({ prefetch(pos->next); 1; }) &&
- ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
- pos = rcu_dereference(pos->next))
- if (obj->key == key)
- return obj;
+ pos && ({ prefetch(pos->next); 1; }) &&
+ ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
+ pos = rcu_dereference(pos->next))
+ if (obj->key == key)
+ return obj;
return NULL;
Quoting Corey Minyard::
@@ -82,36 +94,32 @@ Quoting Corey Minyard::
solved by pre-fetching the "next" field (with proper barriers) before
checking the key."
-2) Insert algo
---------------
+2) Insertion algorithm
+----------------------
-We need to make sure a reader cannot read the new 'obj->obj_next' value
-and previous value of 'obj->key'. Or else, an item could be deleted
+We need to make sure a reader cannot read the new 'obj->obj_node.next' value
+and previous value of 'obj->key'. Otherwise, an item could be deleted
from a chain, and inserted into another chain. If new chain was empty
-before the move, 'next' pointer is NULL, and lockless reader can
-not detect it missed following items in original chain.
+before the move, 'next' pointer is NULL, and lockless reader can not
+detect the fact that it missed following items in original chain.
::
/*
- * Please note that new inserts are done at the head of list,
- * not in the middle or end.
- */
+ * Please note that new inserts are done at the head of list,
+ * not in the middle or end.
+ */
obj = kmem_cache_alloc(...);
lock_chain(); // typically a spin_lock()
obj->key = key;
- /*
- * we need to make sure obj->key is updated before obj->next
- * or obj->refcnt
- */
- smp_wmb();
- atomic_set(&obj->refcnt, 1);
+ atomic_set_release(&obj->refcnt, 1); // key before refcnt
hlist_add_head_rcu(&obj->obj_node, list);
unlock_chain(); // typically a spin_unlock()
-3) Remove algo
---------------
+3) Removal algorithm
+--------------------
+
Nothing special here, we can use a standard RCU hlist deletion.
But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
very very fast (before the end of RCU grace period)
@@ -132,8 +140,7 @@ very very fast (before the end of RCU grace period)
Avoiding extra smp_rmb()
========================
-With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
-and extra smp_wmb() in insert function.
+With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup().
For example, if we choose to store the slot number as the 'nulls'
end-of-list marker for each slot of the hash table, we can detect
@@ -142,59 +149,67 @@ to another chain) checking the final 'nulls' value if
the lookup met the end of chain. If final 'nulls' value
is not the slot number, then we must restart the lookup at
the beginning. If the object was moved to the same chain,
-then the reader doesn't care : It might eventually
+then the reader doesn't care: It might occasionally
scan the list again without harm.
+Note that using hlist_nulls means the type of 'obj_node' field of
+'struct object' becomes 'struct hlist_nulls_node'.
-1) lookup algo
---------------
+
+1) lookup algorithm
+-------------------
::
head = &table[slot];
- rcu_read_lock();
begin:
- hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
+ rcu_read_lock();
+ hlist_nulls_for_each_entry_rcu(obj, node, head, obj_node) {
if (obj->key == key) {
- if (!try_get_ref(obj)) // might fail for free objects
+ if (!try_get_ref(obj)) { // might fail for free objects
+ rcu_read_unlock();
goto begin;
+ }
if (obj->key != key) { // not the object we expected
put_ref(obj);
+ rcu_read_unlock();
goto begin;
}
- goto out;
+ goto out;
+ }
+ }
+
+ // If the nulls value we got at the end of this lookup is
+ // not the expected one, we must restart lookup.
+ // We probably met an item that was moved to another chain.
+ if (get_nulls_value(node) != slot) {
+ put_ref(obj);
+ rcu_read_unlock();
+ goto begin;
}
- /*
- * if the nulls value we got at the end of this lookup is
- * not the expected one, we must restart lookup.
- * We probably met an item that was moved to another chain.
- */
- if (get_nulls_value(node) != slot)
- goto begin;
obj = NULL;
out:
rcu_read_unlock();
-2) Insert function
-------------------
+2) Insert algorithm
+-------------------
+
+Same to the above one, but uses hlist_nulls_add_head_rcu() instead of
+hlist_add_head_rcu().
::
/*
- * Please note that new inserts are done at the head of list,
- * not in the middle or end.
- */
+ * Please note that new inserts are done at the head of list,
+ * not in the middle or end.
+ */
obj = kmem_cache_alloc(cachep);
lock_chain(); // typically a spin_lock()
obj->key = key;
+ atomic_set_release(&obj->refcnt, 1); // key before refcnt
/*
- * changes to obj->key must be visible before refcnt one
- */
- smp_wmb();
- atomic_set(&obj->refcnt, 1);
- /*
- * insert obj in RCU way (readers might be traversing chain)
- */
+ * insert obj in RCU way (readers might be traversing chain)
+ */
hlist_nulls_add_head_rcu(&obj->obj_node, list);
unlock_chain(); // typically a spin_unlock()
diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst
index e38c587067fc..d7c8eff63317 100644
--- a/Documentation/RCU/stallwarn.rst
+++ b/Documentation/RCU/stallwarn.rst
@@ -25,10 +25,10 @@ warnings:
- A CPU looping with bottom halves disabled.
-- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the kernel
- without invoking schedule(). If the looping in the kernel is
- really expected and desirable behavior, you might need to add
- some calls to cond_resched().
+- For !CONFIG_PREEMPTION kernels, a CPU looping anywhere in the
+ kernel without potentially invoking schedule(). If the looping
+ in the kernel is really expected and desirable behavior, you
+ might need to add some calls to cond_resched().
- Booting Linux using a console connection that is too slow to
keep up with the boot-time console-message rate. For example,
@@ -96,6 +96,13 @@ warnings:
the ``rcu_.*timer wakeup didn't happen for`` console-log message,
which will include additional debugging information.
+- A timer issue causes time to appear to jump forward, so that RCU
+ believes that the RCU CPU stall-warning timeout has been exceeded
+ when in fact much less time has passed. This could be due to
+ timer hardware bugs, timer driver bugs, or even corruption of
+ the "jiffies" global variable. These sorts of timer hardware
+ and driver bugs are not uncommon when testing new hardware.
+
- A low-level kernel issue that either fails to invoke one of the
variants of rcu_eqs_enter(true), rcu_eqs_exit(true), ct_idle_enter(),
ct_idle_exit(), ct_irq_enter(), or ct_irq_exit() on the one
@@ -108,16 +115,17 @@ warnings:
- A bug in the RCU implementation.
-- A hardware failure. This is quite unlikely, but has occurred
- at least once in real life. A CPU failed in a running system,
- becoming unresponsive, but not causing an immediate crash.
- This resulted in a series of RCU CPU stall warnings, eventually
- leading the realization that the CPU had failed.
+- A hardware failure. This is quite unlikely, but is not at all
+ uncommon in large datacenter. In one memorable case some decades
+ back, a CPU failed in a running system, becoming unresponsive,
+ but not causing an immediate crash. This resulted in a series
+ of RCU CPU stall warnings, eventually leading to the realization
+ that the CPU had failed.
-The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning.
-Note that SRCU does *not* have CPU stall warnings. Please note that
-RCU only detects CPU stalls when there is a grace period in progress.
-No grace period, no CPU stall warnings.
+The RCU, RCU-sched, RCU-tasks, and RCU-tasks-trace implementations have
+CPU stall warning. Note that SRCU does *not* have CPU stall warnings.
+Please note that RCU only detects CPU stalls when there is a grace period
+in progress. No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.
@@ -205,16 +213,21 @@ RCU_STALL_RAT_DELAY
rcupdate.rcu_task_stall_timeout
-------------------------------
- This boot/sysfs parameter controls the RCU-tasks stall warning
- interval. A value of zero or less suppresses RCU-tasks stall
- warnings. A positive value sets the stall-warning interval
- in seconds. An RCU-tasks stall warning starts with the line:
+ This boot/sysfs parameter controls the RCU-tasks and
+ RCU-tasks-trace stall warning intervals. A value of zero or less
+ suppresses RCU-tasks stall warnings. A positive value sets the
+ stall-warning interval in seconds. An RCU-tasks stall warning
+ starts with the line:
INFO: rcu_tasks detected stalls on tasks:
And continues with the output of sched_show_task() for each
task stalling the current RCU-tasks grace period.
+ An RCU-tasks-trace stall warning starts (and continues) similarly:
+
+ INFO: rcu_tasks_trace detected stalls on tasks
+
Interpreting RCU's CPU Stall-Detector "Splats"
==============================================
@@ -243,12 +256,13 @@ ticks this GP)" indicates that this CPU has not taken any scheduling-clock
interrupts during the current stalled grace period.
The "idle=" portion of the message prints the dyntick-idle state.
-The hex number before the first "/" is the low-order 12 bits of the
+The hex number before the first "/" is the low-order 16 bits of the
dynticks counter, which will have an even-numbered value if the CPU
is in dyntick-idle mode and an odd-numbered value otherwise. The hex
number between the two "/"s is the value of the nesting, which will be
a small non-negative number if in the idle loop (as shown above) and a
-very large positive number otherwise.
+very large positive number otherwise. The number following the final
+"/" is the NMI nesting, which will be a small non-negative number.
The "softirq=" portion of the message tracks the number of RCU softirq
handlers that the stalled CPU has executed. The number before the "/"
@@ -383,3 +397,95 @@ for example, "P3421".
It is entirely possible to see stall warnings from normal and from
expedited grace periods at about the same time during the same run.
+
+RCU_CPU_STALL_CPUTIME
+=====================
+
+In kernels built with CONFIG_RCU_CPU_STALL_CPUTIME=y or booted with
+rcupdate.rcu_cpu_stall_cputime=1, the following additional information
+is supplied with each RCU CPU stall warning::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 624 45 0
+ rcu: cputime: 69 1 2425 ==> 2500(ms)
+
+These statistics are collected during the sampling period. The values
+in row "number:" are the number of hard interrupts, number of soft
+interrupts, and number of context switches on the stalled CPU. The
+first three values in row "cputime:" indicate the CPU time in
+milliseconds consumed by hard interrupts, soft interrupts, and tasks
+on the stalled CPU. The last number is the measurement interval, again
+in milliseconds. Because user-mode tasks normally do not cause RCU CPU
+stalls, these tasks are typically kernel tasks, which is why only the
+system CPU time are considered.
+
+The sampling period is shown as follows::
+
+ |<------------first timeout---------->|<-----second timeout----->|
+ |<--half timeout-->|<--half timeout-->| |
+ | |<--first period-->| |
+ | |<-----------second sampling period---------->|
+ | | | |
+ snapshot time point 1st-stall 2nd-stall
+
+The following describes four typical scenarios:
+
+1. A CPU looping with interrupts disabled.
+
+ ::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 0 0 0
+ rcu: cputime: 0 0 0 ==> 2500(ms)
+
+ Because interrupts have been disabled throughout the measurement
+ interval, there are no interrupts and no context switches.
+ Furthermore, because CPU time consumption was measured using interrupt
+ handlers, the system CPU consumption is misleadingly measured as zero.
+ This scenario will normally also have "(0 ticks this GP)" printed on
+ this CPU's summary line.
+
+2. A CPU looping with bottom halves disabled.
+
+ This is similar to the previous example, but with non-zero number of
+ and CPU time consumed by hard interrupts, along with non-zero CPU
+ time consumed by in-kernel execution::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 624 0 0
+ rcu: cputime: 49 0 2446 ==> 2500(ms)
+
+ The fact that there are zero softirqs gives a hint that these were
+ disabled, perhaps via local_bh_disable(). It is of course possible
+ that there were no softirqs, perhaps because all events that would
+ result in softirq execution are confined to other CPUs. In this case,
+ the diagnosis should continue as shown in the next example.
+
+3. A CPU looping with preemption disabled.
+
+ Here, only the number of context switches is zero::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: 624 45 0
+ rcu: cputime: 69 1 2425 ==> 2500(ms)
+
+ This situation hints that the stalled CPU was looping with preemption
+ disabled.
+
+4. No looping, but massive hard and soft interrupts.
+
+ ::
+
+ rcu: hardirqs softirqs csw/system
+ rcu: number: xx xx 0
+ rcu: cputime: xx xx 0 ==> 2500(ms)
+
+ Here, the number and CPU time of hard interrupts are all non-zero,
+ but the number of context switches and the in-kernel CPU time consumed
+ are zero. The number and cputime of soft interrupts will usually be
+ non-zero, but could be zero, for example, if the CPU was spinning
+ within a single hard interrupt handler.
+
+ If this type of RCU CPU stall warning can be reproduced, you can
+ narrow it down by looking at /proc/interrupts or by writing code to
+ trace each interrupt, for example, by referring to show_interrupts().
diff --git a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst
index a90147713062..1ad5cc793811 100644
--- a/Documentation/RCU/torture.rst
+++ b/Documentation/RCU/torture.rst
@@ -185,7 +185,7 @@ argument.
Not all changes require that all scenarios be run. For example, a change
to Tree SRCU might run only the SRCU-N and SRCU-P scenarios using the
--configs argument to kvm.sh as follows: "--configs 'SRCU-N SRCU-P'".
-Large systems can run multiple copies of of the full set of scenarios,
+Large systems can run multiple copies of the full set of scenarios,
for example, a system with 448 hardware threads can run five instances
of the full set concurrently. To make this happen::
@@ -206,23 +206,34 @@ values for memory may require disabling the callback-flooding tests
using the --bootargs parameter discussed below.
Sometimes additional debugging is useful, and in such cases the --kconfig
-parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_KASAN=y'``.
+parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_RCU_EQS_DEBUG=y'``.
+In addition, there are the --gdb, --kasan, and --kcsan parameters.
+Note that --gdb limits you to one scenario per kvm.sh run and requires
+that you have another window open from which to run ``gdb`` as instructed
+by the script.
Kernel boot arguments can also be supplied, for example, to control
rcutorture's module parameters. For example, to test a change to RCU's
CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'".
This will of course result in the scripting reporting a failure, namely
-the resuling RCU CPU stall warning. As noted above, reducing memory may
+the resulting RCU CPU stall warning. As noted above, reducing memory may
require disabling rcutorture's callback-flooding tests::
kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \
--bootargs 'rcutorture.fwd_progress=0'
Sometimes all that is needed is a full set of kernel builds. This is
-what the --buildonly argument does.
+what the --buildonly parameter does.
-Finally, the --trust-make argument allows each kernel build to reuse what
-it can from the previous kernel build.
+The --duration parameter can override the default run time of 30 minutes.
+For example, ``--duration 2d`` would run for two days, ``--duration 3h``
+would run for three hours, ``--duration 5m`` would run for five minutes,
+and ``--duration 45s`` would run for 45 seconds. This last can be useful
+for tracking down rare boot-time failures.
+
+Finally, the --trust-make parameter allows each kernel build to reuse what
+it can from the previous kernel build. Please note that without the
+--trust-make parameter, your tags files may be demolished.
There are additional more arcane arguments that are documented in the
source code of the kvm.sh script.
@@ -291,3 +302,73 @@ the following summary at the end of the run on a 12-CPU system::
TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
CPU count limited from 16 to 12
TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011
+
+
+Repeated Runs
+=============
+
+Suppose that you are chasing down a rare boot-time failure. Although you
+could use kvm.sh, doing so will rebuild the kernel on each run. If you
+need (say) 1,000 runs to have confidence that you have fixed the bug,
+these pointless rebuilds can become extremely annoying.
+
+This is why kvm-again.sh exists.
+
+Suppose that a previous kvm.sh run left its output in this directory::
+
+ tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
+
+Then this run can be re-run without rebuilding as follow::
+
+ kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
+
+A few of the original run's kvm.sh parameters may be overridden, perhaps
+most notably --duration and --bootargs. For example::
+
+ kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 \
+ --duration 45s
+
+would re-run the previous test, but for only 45 seconds, thus facilitating
+tracking down the aforementioned rare boot-time failure.
+
+
+Distributed Runs
+================
+
+Although kvm.sh is quite useful, its testing is confined to a single
+system. It is not all that hard to use your favorite framework to cause
+(say) 5 instances of kvm.sh to run on your 5 systems, but this will very
+likely unnecessarily rebuild kernels. In addition, manually distributing
+the desired rcutorture scenarios across the available systems can be
+painstaking and error-prone.
+
+And this is why the kvm-remote.sh script exists.
+
+If the following command works::
+
+ ssh system0 date
+
+and if it also works for system1, system2, system3, system4, and system5,
+and all of these systems have 64 CPUs, you can type::
+
+ kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
+ --cpus 64 --duration 8h --configs "5*CFLIST"
+
+This will build each default scenario's kernel on the local system, then
+spread each of five instances of each scenario over the systems listed,
+running each scenario for eight hours. At the end of the runs, the
+results will be gathered, recorded, and printed. Most of the parameters
+that kvm.sh will accept can be passed to kvm-remote.sh, but the list of
+systems must come first.
+
+The kvm.sh ``--dryrun scenarios`` argument is useful for working out
+how many scenarios may be run in one batch across a group of systems.
+
+You can also re-run a previous remote run in a manner similar to kvm.sh::
+
+ kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
+ tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \
+ --duration 24h
+
+In this case, most of the kvm-again.sh parameters may be supplied following
+the pathname of the old run-results directory.
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index 1c747ac3f2c8..a1582bd653d1 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -15,19 +15,27 @@ to start learning about RCU:
| 2014 Big API Table https://lwn.net/Articles/609973/
| 6. The RCU API, 2019 Edition https://lwn.net/Articles/777036/
| 2019 Big API Table https://lwn.net/Articles/777165/
+| 7. The RCU API, 2024 Edition https://lwn.net/Articles/988638/
+| 2024 Background Information https://lwn.net/Articles/988641/
+| 2024 Big API Table https://lwn.net/Articles/988666/
+
+For those preferring video:
+
+| 1. Unraveling RCU Mysteries: Fundamentals https://www.linuxfoundation.org/webinars/unraveling-rcu-usage-mysteries
+| 2. Unraveling RCU Mysteries: Additional Use Cases https://www.linuxfoundation.org/webinars/unraveling-rcu-usage-mysteries-additional-use-cases
What is RCU?
RCU is a synchronization mechanism that was added to the Linux kernel
during the 2.5 development effort that is optimized for read-mostly
-situations. Although RCU is actually quite simple once you understand it,
-getting there can sometimes be a challenge. Part of the problem is that
-most of the past descriptions of RCU have been written with the mistaken
-assumption that there is "one true way" to describe RCU. Instead,
-the experience has been that different people must take different paths
-to arrive at an understanding of RCU. This document provides several
-different paths, as follows:
+situations. Although RCU is actually quite simple, making effective use
+of it requires you to think differently about your code. Another part
+of the problem is the mistaken assumption that there is "one true way" to
+describe and to use RCU. Instead, the experience has been that different
+people must take different paths to arrive at an understanding of RCU,
+depending on their experiences and use cases. This document provides
+several different paths, as follows:
:ref:`1. RCU OVERVIEW <1_whatisRCU>`
@@ -54,8 +62,8 @@ experiment with should focus on Section 2. People who prefer to start
with example uses should focus on Sections 3 and 4. People who need to
understand the RCU implementation should focus on Section 5, then dive
into the kernel source code. People who reason best by analogy should
-focus on Section 6. Section 7 serves as an index to the docbook API
-documentation, and Section 8 is the traditional answer key.
+focus on Section 6 and 7. Section 8 serves as an index to the docbook
+API documentation, and Section 9 is the traditional answer key.
So, start with the section that makes the most sense to you and your
preferred method of learning. If you need to know everything about
@@ -157,34 +165,47 @@ rcu_read_lock()
^^^^^^^^^^^^^^^
void rcu_read_lock(void);
- Used by a reader to inform the reclaimer that the reader is
- entering an RCU read-side critical section. It is illegal
- to block while in an RCU read-side critical section, though
- kernels built with CONFIG_PREEMPT_RCU can preempt RCU
- read-side critical sections. Any RCU-protected data structure
- accessed during an RCU read-side critical section is guaranteed to
- remain unreclaimed for the full duration of that critical section.
- Reference counts may be used in conjunction with RCU to maintain
- longer-term references to data structures.
+ This temporal primitive is used by a reader to inform the
+ reclaimer that the reader is entering an RCU read-side critical
+ section. It is illegal to block while in an RCU read-side
+ critical section, though kernels built with CONFIG_PREEMPT_RCU
+ can preempt RCU read-side critical sections. Any RCU-protected
+ data structure accessed during an RCU read-side critical section
+ is guaranteed to remain unreclaimed for the full duration of that
+ critical section. Reference counts may be used in conjunction
+ with RCU to maintain longer-term references to data structures.
+
+ Note that anything that disables bottom halves, preemption,
+ or interrupts also enters an RCU read-side critical section.
+ Acquiring a spinlock also enters an RCU read-side critical
+ sections, even for spinlocks that do not disable preemption,
+ as is the case in kernels built with CONFIG_PREEMPT_RT=y.
+ Sleeplocks do *not* enter RCU read-side critical sections.
rcu_read_unlock()
^^^^^^^^^^^^^^^^^
void rcu_read_unlock(void);
- Used by a reader to inform the reclaimer that the reader is
- exiting an RCU read-side critical section. Note that RCU
- read-side critical sections may be nested and/or overlapping.
+ This temporal primitives is used by a reader to inform the
+ reclaimer that the reader is exiting an RCU read-side critical
+ section. Anything that enables bottom halves, preemption,
+ or interrupts also exits an RCU read-side critical section.
+ Releasing a spinlock also exits an RCU read-side critical section.
+
+ Note that RCU read-side critical sections may be nested and/or
+ overlapping.
synchronize_rcu()
^^^^^^^^^^^^^^^^^
void synchronize_rcu(void);
- Marks the end of updater code and the beginning of reclaimer
- code. It does this by blocking until all pre-existing RCU
- read-side critical sections on all CPUs have completed.
- Note that synchronize_rcu() will **not** necessarily wait for
- any subsequent RCU read-side critical sections to complete.
- For example, consider the following sequence of events::
+ This temporal primitive marks the end of updater code and the
+ beginning of reclaimer code. It does this by blocking until
+ all pre-existing RCU read-side critical sections on all CPUs
+ have completed. Note that synchronize_rcu() will **not**
+ necessarily wait for any subsequent RCU read-side critical
+ sections to complete. For example, consider the following
+ sequence of events::
CPU 0 CPU 1 CPU 2
----------------- ------------------------- ---------------
@@ -211,13 +232,13 @@ synchronize_rcu()
to be useful in all but the most read-intensive situations,
synchronize_rcu()'s overhead must also be quite small.
- The call_rcu() API is a callback form of synchronize_rcu(),
- and is described in more detail in a later section. Instead of
- blocking, it registers a function and argument which are invoked
- after all ongoing RCU read-side critical sections have completed.
- This callback variant is particularly useful in situations where
- it is illegal to block or where update-side performance is
- critically important.
+ The call_rcu() API is an asynchronous callback form of
+ synchronize_rcu(), and is described in more detail in a later
+ section. Instead of blocking, it registers a function and
+ argument which are invoked after all ongoing RCU read-side
+ critical sections have completed. This callback variant is
+ particularly useful in situations where it is illegal to block
+ or where update-side performance is critically important.
However, the call_rcu() API should not be used lightly, as use
of the synchronize_rcu() API generally results in simpler code.
@@ -232,19 +253,25 @@ rcu_assign_pointer()
^^^^^^^^^^^^^^^^^^^^
void rcu_assign_pointer(p, typeof(p) v);
- Yes, rcu_assign_pointer() **is** implemented as a macro, though it
- would be cool to be able to declare a function in this manner.
- (Compiler experts will no doubt disagree.)
+ Yes, rcu_assign_pointer() **is** implemented as a macro, though
+ it would be cool to be able to declare a function in this manner.
+ (And there has been some discussion of adding overloaded functions
+ to the C language, so who knows?)
- The updater uses this function to assign a new value to an
+ The updater uses this spatial macro to assign a new value to an
RCU-protected pointer, in order to safely communicate the change
- in value from the updater to the reader. This macro does not
- evaluate to an rvalue, but it does execute any memory-barrier
- instructions required for a given CPU architecture.
-
- Perhaps just as important, it serves to document (1) which
- pointers are protected by RCU and (2) the point at which a
- given structure becomes accessible to other CPUs. That said,
+ in value from the updater to the reader. This is a spatial (as
+ opposed to temporal) macro. It does not evaluate to an rvalue,
+ but it does provide any compiler directives and memory-barrier
+ instructions required for a given compile or CPU architecture.
+ Its ordering properties are that of a store-release operation,
+ that is, any prior loads and stores required to initialize the
+ structure are ordered before the store that publishes the pointer
+ to that structure.
+
+ Perhaps just as important, rcu_assign_pointer() serves to document
+ (1) which pointers are protected by RCU and (2) the point at which
+ a given structure becomes accessible to other CPUs. That said,
rcu_assign_pointer() is most frequently used indirectly, via
the _rcu list-manipulation primitives such as list_add_rcu().
@@ -255,14 +282,19 @@ rcu_dereference()
Like rcu_assign_pointer(), rcu_dereference() must be implemented
as a macro.
- The reader uses rcu_dereference() to fetch an RCU-protected
- pointer, which returns a value that may then be safely
- dereferenced. Note that rcu_dereference() does not actually
- dereference the pointer, instead, it protects the pointer for
- later dereferencing. It also executes any needed memory-barrier
- instructions for a given CPU architecture. Currently, only Alpha
- needs memory barriers within rcu_dereference() -- on other CPUs,
- it compiles to nothing, not even a compiler directive.
+ The reader uses the spatial rcu_dereference() macro to fetch
+ an RCU-protected pointer, which returns a value that may
+ then be safely dereferenced. Note that rcu_dereference()
+ does not actually dereference the pointer, instead, it
+ protects the pointer for later dereferencing. It also
+ executes any needed memory-barrier instructions for a given
+ CPU architecture. Currently, only Alpha needs memory barriers
+ within rcu_dereference() -- on other CPUs, it compiles to a
+ volatile load. However, no mainstream C compilers respect
+ address dependencies, so rcu_dereference() uses volatile casts,
+ which, in combination with the coding guidelines listed in
+ rcu_dereference.rst, prevent current compilers from breaking
+ these dependencies.
Common coding practice uses rcu_dereference() to copy an
RCU-protected pointer to a local variable, then dereferences
@@ -355,12 +387,15 @@ reader, updater, and reclaimer.
synchronize_rcu() & call_rcu()
-The RCU infrastructure observes the time sequence of rcu_read_lock(),
+The RCU infrastructure observes the temporal sequence of rcu_read_lock(),
rcu_read_unlock(), synchronize_rcu(), and call_rcu() invocations in
order to determine when (1) synchronize_rcu() invocations may return
to their callers and (2) call_rcu() callbacks may be invoked. Efficient
implementations of the RCU infrastructure make heavy use of batching in
order to amortize their overhead over many uses of the corresponding APIs.
+The rcu_assign_pointer() and rcu_dereference() invocations communicate
+spatial changes via stores to and loads from the RCU-protected pointer in
+question.
There are at least three flavors of RCU usage in the Linux kernel. The diagram
above shows the most common one. On the updater side, the rcu_assign_pointer(),
@@ -392,7 +427,9 @@ b. RCU applied to networking data structures that may be subjected
c. RCU applied to scheduler and interrupt/NMI-handler tasks.
Again, most uses will be of (a). The (b) and (c) cases are important
-for specialized uses, but are relatively uncommon.
+for specialized uses, but are relatively uncommon. The SRCU, RCU-Tasks,
+RCU-Tasks-Rude, and RCU-Tasks-Trace have similar relationships among
+their assorted primitives.
.. _3_whatisRCU:
@@ -401,7 +438,7 @@ for specialized uses, but are relatively uncommon.
This section shows a simple use of the core RCU API to protect a
global pointer to a dynamically allocated structure. More-typical
-uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst.
+uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
::
struct foo {
@@ -468,7 +505,7 @@ So, to sum up:
- Within an RCU read-side critical section, use rcu_dereference()
to dereference RCU-protected pointers.
-- Use some solid scheme (such as locks or semaphores) to
+- Use some solid design (such as locks or semaphores) to
keep concurrent updates from interfering with each other.
- Use rcu_assign_pointer() to update an RCU-protected pointer.
@@ -484,8 +521,8 @@ So, to sum up:
data item.
See checklist.rst for additional rules to follow when using RCU.
-And again, more-typical uses of RCU may be found in listRCU.rst,
-arrayRCU.rst, and NMI-RCU.rst.
+And again, more-typical uses of RCU may be found in listRCU.rst
+and NMI-RCU.rst.
.. _4_whatisRCU:
@@ -579,6 +616,14 @@ to avoid having to write your own callback::
kfree_rcu(old_fp, rcu);
+If the occasional sleep is permitted, the single-argument form may
+be used, omitting the rcu_head structure from struct foo.
+
+ kfree_rcu_mightsleep(old_fp);
+
+This variant almost never blocks, but might do so by invoking
+synchronize_rcu() in response to memory-allocation failure.
+
Again, see checklist.rst for additional rules governing the use of RCU.
.. _5_whatisRCU:
@@ -596,7 +641,7 @@ lacking both functionality and performance. However, they are useful
in getting a feel for how RCU works. See kernel/rcu/update.c for a
production-quality implementation, and see:
- http://www.rdrop.com/users/paulmck/RCU
+ https://docs.google.com/document/d/1X0lThx8OK0ZgLMqVoXiR4ZrGURHrXK6NyLRbeXe3Xac/edit
for papers describing the Linux kernel RCU implementation. The OLS'01
and OLS'02 papers are a good introduction, and the dissertation provides
@@ -929,6 +974,18 @@ unfortunately any spinlock in a ``SLAB_TYPESAFE_BY_RCU`` object must be
initialized after each and every call to kmem_cache_alloc(), which renders
reference-free spinlock acquisition completely unsafe. Therefore, when
using ``SLAB_TYPESAFE_BY_RCU``, make proper use of a reference counter.
+If using refcount_t, the specialized refcount_{add|inc}_not_zero_acquire()
+and refcount_set_release() APIs should be used to ensure correct operation
+ordering when verifying object identity and when initializing newly
+allocated objects. Acquire fence in refcount_{add|inc}_not_zero_acquire()
+ensures that identity checks happen *after* reference count is taken.
+refcount_set_release() should be called after a newly allocated object is
+fully initialized and release fence ensures that new values are visible
+*before* refcount can be successfully taken by other users. Once
+refcount_set_release() is called, the object should be considered visible
+by other tasks.
+(Those willing to initialize their locks in a kmem_cache constructor
+may also use locking, including cache-friendly sequence locking.)
With traditional reference counting -- such as that implemented by the
kref library in Linux -- there is typically code that runs when the last
@@ -964,32 +1021,41 @@ RCU list traversal::
list_entry_rcu
list_entry_lockless
list_first_entry_rcu
+ list_first_or_null_rcu
+ list_tail_rcu
list_next_rcu
+ list_next_or_null_rcu
list_for_each_entry_rcu
list_for_each_entry_continue_rcu
list_for_each_entry_from_rcu
- list_first_or_null_rcu
- list_next_or_null_rcu
+ list_for_each_entry_lockless
hlist_first_rcu
hlist_next_rcu
hlist_pprev_rcu
hlist_for_each_entry_rcu
+ hlist_for_each_entry_rcu_notrace
hlist_for_each_entry_rcu_bh
hlist_for_each_entry_from_rcu
hlist_for_each_entry_continue_rcu
hlist_for_each_entry_continue_rcu_bh
hlist_nulls_first_rcu
+ hlist_nulls_next_rcu
hlist_nulls_for_each_entry_rcu
+ hlist_nulls_for_each_entry_safe
hlist_bl_first_rcu
hlist_bl_for_each_entry_rcu
RCU pointer/list update::
rcu_assign_pointer
+ rcu_replace_pointer
+ INIT_LIST_HEAD_RCU
list_add_rcu
list_add_tail_rcu
list_del_rcu
list_replace_rcu
+ list_splice_init_rcu
+ list_splice_tail_init_rcu
hlist_add_behind_rcu
hlist_add_before_rcu
hlist_add_head_rcu
@@ -997,34 +1063,53 @@ RCU pointer/list update::
hlist_del_rcu
hlist_del_init_rcu
hlist_replace_rcu
- list_splice_init_rcu
- list_splice_tail_init_rcu
hlist_nulls_del_init_rcu
hlist_nulls_del_rcu
hlist_nulls_add_head_rcu
+ hlist_nulls_add_tail_rcu
+ hlist_nulls_add_fake
+ hlists_swap_heads_rcu
hlist_bl_add_head_rcu
- hlist_bl_del_init_rcu
hlist_bl_del_rcu
hlist_bl_set_first_rcu
RCU::
- Critical sections Grace period Barrier
-
- rcu_read_lock synchronize_net rcu_barrier
- rcu_read_unlock synchronize_rcu
- rcu_dereference synchronize_rcu_expedited
- rcu_read_lock_held call_rcu
- rcu_dereference_check kfree_rcu
- rcu_dereference_protected
+ Critical sections Grace period Barrier
+
+ rcu_read_lock synchronize_net rcu_barrier
+ rcu_read_unlock synchronize_rcu
+ guard(rcu)() synchronize_rcu_expedited
+ scoped_guard(rcu) synchronize_rcu_mult
+ rcu_dereference call_rcu
+ rcu_dereference_check call_rcu_hurry
+ rcu_dereference_protected kfree_rcu
+ rcu_read_lock_held kvfree_rcu
+ rcu_read_lock_any_held kfree_rcu_mightsleep
+ rcu_pointer_handoff cond_synchronize_rcu
+ unrcu_pointer cond_synchronize_rcu_full
+ cond_synchronize_rcu_expedited
+ cond_synchronize_rcu_expedited_full
+ get_completed_synchronize_rcu
+ get_completed_synchronize_rcu_full
+ get_state_synchronize_rcu
+ get_state_synchronize_rcu_full
+ poll_state_synchronize_rcu
+ poll_state_synchronize_rcu_full
+ same_state_synchronize_rcu
+ same_state_synchronize_rcu_full
+ start_poll_synchronize_rcu
+ start_poll_synchronize_rcu_full
+ start_poll_synchronize_rcu_expedited
+ start_poll_synchronize_rcu_expedited_full
bh::
Critical sections Grace period Barrier
- rcu_read_lock_bh call_rcu rcu_barrier
- rcu_read_unlock_bh synchronize_rcu
- [local_bh_disable] synchronize_rcu_expedited
+ rcu_read_lock_bh [Same as RCU] [Same as RCU]
+ rcu_read_unlock_bh
+ [local_bh_disable]
[and friends]
rcu_dereference_bh
rcu_dereference_bh_check
@@ -1035,9 +1120,9 @@ sched::
Critical sections Grace period Barrier
- rcu_read_lock_sched call_rcu rcu_barrier
- rcu_read_unlock_sched synchronize_rcu
- [preempt_disable] synchronize_rcu_expedited
+ rcu_read_lock_sched [Same as RCU] [Same as RCU]
+ rcu_read_unlock_sched
+ [preempt_disable]
[and friends]
rcu_read_lock_sched_notrace
rcu_read_unlock_sched_notrace
@@ -1047,28 +1132,112 @@ sched::
rcu_read_lock_sched_held
-SRCU::
+RCU: Initialization/cleanup/ordering::
- Critical sections Grace period Barrier
+ RCU_INIT_POINTER
+ RCU_INITIALIZER
+ RCU_POINTER_INITIALIZER
+ init_rcu_head
+ destroy_rcu_head
+ init_rcu_head_on_stack
+ destroy_rcu_head_on_stack
+ SLAB_TYPESAFE_BY_RCU
+
+
+RCU: Quiescents states and control::
+
+ cond_resched_tasks_rcu_qs
+ rcu_all_qs
+ rcu_softirq_qs_periodic
+ rcu_end_inkernel_boot
+ rcu_expedite_gp
+ rcu_gp_is_expedited
+ rcu_unexpedite_gp
+ rcu_cpu_stall_reset
+ rcu_head_after_call_rcu
+ rcu_is_watching
+
+
+RCU-sync primitive::
- srcu_read_lock call_srcu srcu_barrier
- srcu_read_unlock synchronize_srcu
- srcu_dereference synchronize_srcu_expedited
+ rcu_sync_is_idle
+ rcu_sync_init
+ rcu_sync_enter
+ rcu_sync_exit
+ rcu_sync_dtor
+
+
+RCU-Tasks::
+
+ Critical sections Grace period Barrier
+
+ N/A call_rcu_tasks rcu_barrier_tasks
+ synchronize_rcu_tasks
+
+
+RCU-Tasks-Rude::
+
+ Critical sections Grace period Barrier
+
+ N/A synchronize_rcu_tasks_rude rcu_barrier_tasks_rude
+ call_rcu_tasks_rude
+
+
+RCU-Tasks-Trace::
+
+ Critical sections Grace period Barrier
+
+ rcu_read_lock_trace call_rcu_tasks_trace rcu_barrier_tasks_trace
+ rcu_read_unlock_trace synchronize_rcu_tasks_trace
+ guard(rcu_tasks_trace)()
+ scoped_guard(rcu_tasks_trace)
+
+
+SRCU list traversal::
+ list_for_each_entry_srcu
+ hlist_for_each_entry_srcu
+
+
+SRCU::
+
+ Critical sections Grace period Barrier
+
+ srcu_read_lock call_srcu srcu_barrier
+ srcu_read_unlock synchronize_srcu
+ srcu_read_lock_fast synchronize_srcu_expedited
+ srcu_read_unlock_fast get_state_synchronize_srcu
+ srcu_read_lock_nmisafe start_poll_synchronize_srcu
+ srcu_read_unlock_nmisafe start_poll_synchronize_srcu_expedited
+ srcu_read_lock_notrace poll_state_synchronize_srcu
+ srcu_read_unlock_notrace
+ srcu_down_read
+ srcu_up_read
+ srcu_down_read_fast
+ srcu_up_read_fast
+ guard(srcu)()
+ scoped_guard(srcu)
+ srcu_read_lock_held
+ srcu_dereference
srcu_dereference_check
+ srcu_dereference_notrace
srcu_read_lock_held
-SRCU: Initialization/cleanup::
+
+SRCU: Initialization/cleanup/ordering::
DEFINE_SRCU
DEFINE_STATIC_SRCU
+ DEFINE_SRCU_FAST // for srcu_read_lock_fast() and friends
+ DEFINE_STATIC_SRCU_FAST // for srcu_read_lock_fast() and friends
init_srcu_struct
+ init_srcu_struct_fast
cleanup_srcu_struct
+ smp_mb__after_srcu_read_unlock
All: lockdep-checked RCU utility APIs::
RCU_LOCKDEP_WARN
rcu_sleep_check
- RCU_NONIDLE
All: Unchecked RCU-protected pointer access::
@@ -1087,35 +1256,43 @@ list can be helpful:
a. Will readers need to block? If so, you need SRCU.
-b. What about the -rt patchset? If readers would need to block
- in an non-rt kernel, you need SRCU. If readers would block
- in a -rt kernel, but not in a non-rt kernel, SRCU is not
- necessary. (The -rt patchset turns spinlocks into sleeplocks,
- hence this distinction.)
+b. Will readers need to block and are you doing tracing, for
+ example, ftrace or BPF? If so, you need RCU-tasks,
+ RCU-tasks-rude, and/or RCU-tasks-trace.
+
+c. What about the -rt patchset? If readers would need to block in
+ an non-rt kernel, you need SRCU. If readers would block when
+ acquiring spinlocks in a -rt kernel, but not in a non-rt kernel,
+ SRCU is not necessary. (The -rt patchset turns spinlocks into
+ sleeplocks, hence this distinction.)
-c. Do you need to treat NMI handlers, hardirq handlers,
+d. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
- If so, RCU-sched is the only choice that will work for you.
-
-d. Do you need RCU grace periods to complete even in the face
- of softirq monopolization of one or more of the CPUs? For
- example, is your code subject to network-based denial-of-service
- attacks? If so, you should disable softirq across your readers,
- for example, by using rcu_read_lock_bh().
-
-e. Is your workload too update-intensive for normal use of
+ If so, RCU-sched readers are the only choice that will work
+ for you, but since about v4.20 you use can use the vanilla RCU
+ update primitives.
+
+e. Do you need RCU grace periods to complete even in the face of
+ softirq monopolization of one or more of the CPUs? For example,
+ is your code subject to network-based denial-of-service attacks?
+ If so, you should disable softirq across your readers, for
+ example, by using rcu_read_lock_bh(). Since about v4.20 you
+ use can use the vanilla RCU update primitives.
+
+f. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_TYPESAFE_BY_RCU (which was originally
named SLAB_DESTROY_BY_RCU). But please be careful!
-f. Do you need read-side critical sections that are respected
- even though they are in the middle of the idle loop, during
- user-mode execution, or on an offlined CPU? If so, SRCU is the
- only choice that will work for you.
+g. Do you need read-side critical sections that are respected even
+ on CPUs that are deep in the idle loop, during entry to or exit
+ from user-mode execution, or on an offlined CPU? If so, SRCU
+ and RCU Tasks Trace are the only choices that will work for you,
+ with SRCU being strongly preferred in almost all cases.
-g. Otherwise, use RCU.
+h. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.
diff --git a/Documentation/accel/amdxdna/amdnpu.rst b/Documentation/accel/amdxdna/amdnpu.rst
new file mode 100644
index 000000000000..42e54904f9a8
--- /dev/null
+++ b/Documentation/accel/amdxdna/amdnpu.rst
@@ -0,0 +1,281 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+.. include:: <isonum.txt>
+
+=========
+ AMD NPU
+=========
+
+:Copyright: |copy| 2024 Advanced Micro Devices, Inc.
+:Author: Sonal Santan <sonal.santan@amd.com>
+
+Overview
+========
+
+AMD NPU (Neural Processing Unit) is a multi-user AI inference accelerator
+integrated into AMD client APU. NPU enables efficient execution of Machine
+Learning applications like CNN, LLM, etc. NPU is based on
+`AMD XDNA Architecture`_. NPU is managed by **amdxdna** driver.
+
+
+Hardware Description
+====================
+
+AMD NPU consists of the following hardware components:
+
+AMD XDNA Array
+--------------
+
+AMD XDNA Array comprises of 2D array of compute and memory tiles built with
+`AMD AI Engine Technology`_. Each column has 4 rows of compute tiles and 1
+row of memory tile. Each compute tile contains a VLIW processor with its own
+dedicated program and data memory. The memory tile acts as L2 memory. The 2D
+array can be partitioned at a column boundary creating a spatially isolated
+partition which can be bound to a workload context.
+
+Each column also has dedicated DMA engines to move data between host DDR and
+memory tile.
+
+AMD Phoenix and AMD Hawk Point client NPU have a 4x5 topology, i.e., 4 rows of
+compute tiles arranged into 5 columns. AMD Strix Point client APU have 4x8
+topology, i.e., 4 rows of compute tiles arranged into 8 columns.
+
+Shared L2 Memory
+----------------
+
+The single row of memory tiles create a pool of software managed on chip L2
+memory. DMA engines are used to move data between host DDR and memory tiles.
+AMD Phoenix and AMD Hawk Point NPUs have a total of 2560 KB of L2 memory.
+AMD Strix Point NPU has a total of 4096 KB of L2 memory.
+
+Microcontroller
+---------------
+
+A microcontroller runs NPU Firmware which is responsible for command processing,
+XDNA Array partition setup, XDNA Array configuration, workload context
+management and workload orchestration.
+
+NPU Firmware uses a dedicated instance of an isolated non-privileged context
+called ERT to service each workload context. ERT is also used to execute user
+provided ``ctrlcode`` associated with the workload context.
+
+NPU Firmware uses a single isolated privileged context called MERT to service
+management commands from the amdxdna driver.
+
+Mailboxes
+---------
+
+The microcontroller and amdxdna driver use a privileged channel for management
+tasks like setting up of contexts, telemetry, query, error handling, setting up
+user channel, etc. As mentioned before, privileged channel requests are
+serviced by MERT. The privileged channel is bound to a single mailbox.
+
+The microcontroller and amdxdna driver use a dedicated user channel per
+workload context. The user channel is primarily used for submitting work to
+the NPU. As mentioned before, a user channel requests are serviced by an
+instance of ERT. Each user channel is bound to its own dedicated mailbox.
+
+PCIe EP
+-------
+
+NPU is visible to the x86 host CPU as a PCIe device with multiple BARs and some
+MSI-X interrupt vectors. NPU uses a dedicated high bandwidth SoC level fabric
+for reading or writing into host memory. Each instance of ERT gets its own
+dedicated MSI-X interrupt. MERT gets a single instance of MSI-X interrupt.
+
+The number of PCIe BARs varies depending on the specific device. Based on their
+functions, PCIe BARs can generally be categorized into the following types.
+
+* PSP BAR: Expose the AMD PSP (Platform Security Processor) function
+* SMU BAR: Expose the AMD SMU (System Management Unit) function
+* SRAM BAR: Expose ring buffers for the mailbox
+* Mailbox BAR: Expose the mailbox control registers (head, tail and ISR
+ registers etc.)
+* Public Register BAR: Expose public registers
+
+On specific devices, the above-mentioned BAR type might be combined into a
+single physical PCIe BAR. Or a module might require two physical PCIe BARs to
+be fully functional. For example,
+
+* On AMD Phoenix device, PSP, SMU, Public Register BARs are on PCIe BAR index 0.
+* On AMD Strix Point device, Mailbox and Public Register BARs are on PCIe BAR
+ index 0. The PSP has some registers in PCIe BAR index 0 (Public Register BAR)
+ and PCIe BAR index 4 (PSP BAR).
+
+Process Isolation Hardware
+--------------------------
+
+As explained before, XDNA Array can be dynamically divided into isolated
+spatial partitions, each of which may have one or more columns. The spatial
+partition is setup by programming the column isolation registers by the
+microcontroller. Each spatial partition is associated with a PASID which is
+also programmed by the microcontroller. Hence multiple spatial partitions in
+the NPU can make concurrent host access protected by PASID.
+
+The NPU FW itself uses microcontroller MMU enforced isolated contexts for
+servicing user and privileged channel requests.
+
+
+Mixed Spatial and Temporal Scheduling
+=====================================
+
+AMD XDNA architecture supports mixed spatial and temporal (time sharing)
+scheduling of 2D array. This means that spatial partitions may be setup and
+torn down dynamically to accommodate various workloads. A *spatial* partition
+may be *exclusively* bound to one workload context while another partition may
+be *temporarily* bound to more than one workload contexts. The microcontroller
+updates the PASID for a temporarily shared partition to match the context that
+has been bound to the partition at any moment.
+
+Resource Solver
+---------------
+
+The Resource Solver component of the amdxdna driver manages the allocation
+of 2D array among various workloads. Every workload describes the number
+of columns required to run the NPU binary in its metadata. The Resource Solver
+component uses hints passed by the workload and its own heuristics to
+decide 2D array (re)partition strategy and mapping of workloads for spatial and
+temporal sharing of columns. The FW enforces the context-to-column(s) resource
+binding decisions made by the Resource Solver.
+
+AMD Phoenix and AMD Hawk Point client NPU can support 6 concurrent workload
+contexts. AMD Strix Point can support 16 concurrent workload contexts.
+
+
+Application Binaries
+====================
+
+A NPU application workload is comprised of two separate binaries which are
+generated by the NPU compiler.
+
+1. AMD XDNA Array overlay, which is used to configure a NPU spatial partition.
+ The overlay contains instructions for setting up the stream switch
+ configuration and ELF for the compute tiles. The overlay is loaded on the
+ spatial partition bound to the workload by the associated ERT instance.
+ Refer to the
+ `Versal Adaptive SoC AIE-ML Architecture Manual (AM020)`_ for more details.
+
+2. ``ctrlcode``, used for orchestrating the overlay loaded on the spatial
+ partition. ``ctrlcode`` is executed by the ERT running in protected mode on
+ the microcontroller in the context of the workload. ``ctrlcode`` is made up
+ of a sequence of opcodes named ``XAie_TxnOpcode``. Refer to the
+ `AI Engine Run Time`_ for more details.
+
+
+Special Host Buffers
+====================
+
+Per-context Instruction Buffer
+------------------------------
+
+Every workload context uses a host resident 64 MB buffer which is memory
+mapped into the ERT instance created to service the workload. The ``ctrlcode``
+used by the workload is copied into this special memory. This buffer is
+protected by PASID like all other input/output buffers used by that workload.
+Instruction buffer is also mapped into the user space of the workload.
+
+Global Privileged Buffer
+------------------------
+
+In addition, the driver also allocates a single buffer for maintenance tasks
+like recording errors from MERT. This global buffer uses the global IOMMU
+domain and is only accessible by MERT.
+
+
+High-level Use Flow
+===================
+
+Here are the steps to run a workload on AMD NPU:
+
+1. Compile the workload into an overlay and a ``ctrlcode`` binary.
+2. Userspace opens a context in the driver and provides the overlay.
+3. The driver checks with the Resource Solver for provisioning a set of columns
+ for the workload.
+4. The driver then asks MERT to create a context on the device with the desired
+ columns.
+5. MERT then creates an instance of ERT. MERT also maps the Instruction Buffer
+ into ERT memory.
+6. The userspace then copies the ``ctrlcode`` to the Instruction Buffer.
+7. Userspace then creates a command buffer with pointers to input, output, and
+ instruction buffer; it then submits command buffer with the driver and goes
+ to sleep waiting for completion.
+8. The driver sends the command over the Mailbox to ERT.
+9. ERT *executes* the ``ctrlcode`` in the instruction buffer.
+10. Execution of the ``ctrlcode`` kicks off DMAs to and from the host DDR while
+ AMD XDNA Array is running.
+11. When ERT reaches end of ``ctrlcode``, it raises an MSI-X to send completion
+ signal to the driver which then wakes up the waiting workload.
+
+
+Boot Flow
+=========
+
+amdxdna driver uses PSP to securely load signed NPU FW and kick off the boot
+of the NPU microcontroller. amdxdna driver then waits for the alive signal in
+a special location on BAR 0. The NPU is switched off during SoC suspend and
+turned on after resume where the NPU FW is reloaded, and the handshake is
+performed again.
+
+
+Userspace components
+====================
+
+Compiler
+--------
+
+Peano is an LLVM based open-source single core compiler for AMD XDNA Array
+compute tile. Peano is available at:
+https://github.com/Xilinx/llvm-aie
+
+IRON is an open-source array compiler for AMD XDNA Array based NPU which uses
+Peano underneath. IRON is available at:
+https://github.com/Xilinx/mlir-aie
+
+Usermode Driver (UMD)
+---------------------
+
+The open-source XRT runtime stack interfaces with amdxdna kernel driver. XRT
+can be found at:
+https://github.com/Xilinx/XRT
+
+The open-source XRT shim for NPU is can be found at:
+https://github.com/amd/xdna-driver
+
+
+DMA Operation
+=============
+
+DMA operation instructions are encoded in the ``ctrlcode`` as
+``XAIE_IO_BLOCKWRITE`` opcode. When ERT executes ``XAIE_IO_BLOCKWRITE``, DMA
+operations between host DDR and L2 memory are effected.
+
+
+Error Handling
+==============
+
+When MERT detects an error in AMD XDNA Array, it pauses execution for that
+workload context and sends an asynchronous message to the driver over the
+privileged channel. The driver then sends a buffer pointer to MERT to capture
+the register states for the partition bound to faulting workload context. The
+driver then decodes the error by reading the contents of the buffer pointer.
+
+
+Telemetry
+=========
+
+MERT can report various kinds of telemetry information like the following:
+
+* L1 interrupt counter
+* DMA counter
+* Deep Sleep counter
+* etc.
+
+
+References
+==========
+
+- `AMD XDNA Architecture <https://www.amd.com/en/technologies/xdna.html>`_
+- `AMD AI Engine Technology <https://www.xilinx.com/products/technology/ai-engine.html>`_
+- `Peano <https://github.com/Xilinx/llvm-aie>`_
+- `Versal Adaptive SoC AIE-ML Architecture Manual (AM020) <https://docs.amd.com/r/en-US/am020-versal-aie-ml>`_
+- `AI Engine Run Time <https://github.com/Xilinx/aie-rt/tree/release/main_aig>`_
diff --git a/Documentation/accel/amdxdna/index.rst b/Documentation/accel/amdxdna/index.rst
new file mode 100644
index 000000000000..38c16939f1fc
--- /dev/null
+++ b/Documentation/accel/amdxdna/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=====================================
+ accel/amdxdna NPU driver
+=====================================
+
+The accel/amdxdna driver supports the AMD NPU (Neural Processing Unit).
+
+.. toctree::
+
+ amdnpu
diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
new file mode 100644
index 000000000000..d8fa332d60a8
--- /dev/null
+++ b/Documentation/accel/index.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Compute Accelerators
+====================
+
+.. toctree::
+ :maxdepth: 1
+
+ introduction
+ amdxdna/index
+ qaic/index
+ rocket/index
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/accel/introduction.rst b/Documentation/accel/introduction.rst
new file mode 100644
index 000000000000..ae3030136637
--- /dev/null
+++ b/Documentation/accel/introduction.rst
@@ -0,0 +1,110 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+Introduction
+============
+
+The Linux compute accelerators subsystem is designed to expose compute
+accelerators in a common way to user-space and provide a common set of
+functionality.
+
+These devices can be either stand-alone ASICs or IP blocks inside an SoC/GPU.
+Although these devices are typically designed to accelerate
+Machine-Learning (ML) and/or Deep-Learning (DL) computations, the accel layer
+is not limited to handling these types of accelerators.
+
+Typically, a compute accelerator will belong to one of the following
+categories:
+
+- Edge AI - doing inference at an edge device. It can be an embedded ASIC/FPGA,
+ or an IP inside a SoC (e.g. laptop web camera). These devices
+ are typically configured using registers and can work with or without DMA.
+
+- Inference data-center - single/multi user devices in a large server. This
+ type of device can be stand-alone or an IP inside a SoC or a GPU. It will
+ have on-board DRAM (to hold the DL topology), DMA engines and
+ command submission queues (either kernel or user-space queues).
+ It might also have an MMU to manage multiple users and might also enable
+ virtualization (SR-IOV) to support multiple VMs on the same device. In
+ addition, these devices will usually have some tools, such as profiler and
+ debugger.
+
+- Training data-center - Similar to Inference data-center cards, but typically
+ have more computational power and memory b/w (e.g. HBM) and will likely have
+ a method of scaling-up/out, i.e. connecting to other training cards inside
+ the server or in other servers, respectively.
+
+All these devices typically have different runtime user-space software stacks,
+that are tailored-made to their h/w. In addition, they will also probably
+include a compiler to generate programs to their custom-made computational
+engines. Typically, the common layer in user-space will be the DL frameworks,
+such as PyTorch and TensorFlow.
+
+Sharing code with DRM
+=====================
+
+Because this type of devices can be an IP inside GPUs or have similar
+characteristics as those of GPUs, the accel subsystem will use the
+DRM subsystem's code and functionality. i.e. the accel core code will
+be part of the DRM subsystem and an accel device will be a new type of DRM
+device.
+
+This will allow us to leverage the extensive DRM code-base and
+collaborate with DRM developers that have experience with this type of
+devices. In addition, new features that will be added for the accelerator
+drivers can be of use to GPU drivers as well.
+
+Differentiation from GPUs
+=========================
+
+Because we want to prevent the extensive user-space graphic software stack
+from trying to use an accelerator as a GPU, the compute accelerators will be
+differentiated from GPUs by using a new major number and new device char files.
+
+Furthermore, the drivers will be located in a separate place in the kernel
+tree - drivers/accel/.
+
+The accelerator devices will be exposed to the user space with the dedicated
+261 major number and will have the following convention:
+
+- device char files - /dev/accel/accel\*
+- sysfs - /sys/class/accel/accel\*/
+- debugfs - /sys/kernel/debug/accel/\*/
+
+Getting Started
+===============
+
+First, read the DRM documentation at Documentation/gpu/index.rst.
+Not only it will explain how to write a new DRM driver but it will also
+contain all the information on how to contribute, the Code Of Conduct and
+what is the coding style/documentation. All of that is the same for the
+accel subsystem.
+
+Second, make sure the kernel is configured with CONFIG_DRM_ACCEL.
+
+To expose your device as an accelerator, two changes are needed to
+be done in your driver (as opposed to a standard DRM driver):
+
+- Add the DRIVER_COMPUTE_ACCEL feature flag in your drm_driver's
+ driver_features field. It is important to note that this driver feature is
+ mutually exclusive with DRIVER_RENDER and DRIVER_MODESET. Devices that want
+ to expose both graphics and compute device char files should be handled by
+ two drivers that are connected using the auxiliary bus framework.
+
+- Change the open callback in your driver fops structure to accel_open().
+ Alternatively, your driver can use DEFINE_DRM_ACCEL_FOPS macro to easily
+ set the correct function operations pointers structure.
+
+External References
+===================
+
+email threads
+-------------
+
+* `Initial discussion on the New subsystem for acceleration devices <https://lore.kernel.org/lkml/CAFCwf11=9qpNAepL7NL+YAV_QO=Wv6pnWPhKHKAepK3fNn+2Dg@mail.gmail.com/>`_ - Oded Gabbay (2022)
+* `patch-set to add the new subsystem <https://lore.kernel.org/lkml/20221022214622.18042-1-ogabbay@kernel.org/>`_ - Oded Gabbay (2022)
+
+Conference talks
+----------------
+
+* `LPC 2022 Accelerators BOF outcomes summary <https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summary.html>`_ - Dave Airlie (2022)
diff --git a/Documentation/accel/qaic/aic080.rst b/Documentation/accel/qaic/aic080.rst
new file mode 100644
index 000000000000..d563771ea6ce
--- /dev/null
+++ b/Documentation/accel/qaic/aic080.rst
@@ -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.
diff --git a/Documentation/accel/qaic/aic100.rst b/Documentation/accel/qaic/aic100.rst
new file mode 100644
index 000000000000..41331cf580b1
--- /dev/null
+++ b/Documentation/accel/qaic/aic100.rst
@@ -0,0 +1,538 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+===============================
+ Qualcomm Cloud AI 100 (AIC100)
+===============================
+
+Overview
+========
+
+The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P - part of
+Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for
+the purpose of efficiently running Artificial Intelligence (AI) Deep Learning
+inference workloads. They are AI accelerators.
+
+The PCIe interface of AIC100 is capable of PCIe Gen4 speeds over eight lanes
+(x8). An individual SoC on a card can have up to 16 NSPs for running workloads.
+Each SoC has an A53 management CPU. On card, there can be up to 32 GB of DDR.
+
+Multiple AIC100 cards can be hosted in a single system to scale overall
+performance. AIC100 cards are multi-user capable and able to execute workloads
+from multiple users in a concurrent manner.
+
+Hardware Description
+====================
+
+An AIC100 card consists of an AIC100 SoC, on-card DDR, and a set of misc
+peripherals (PMICs, etc).
+
+An AIC100 card can either be a PCIe HHHL form factor (a traditional PCIe card),
+or a Dual M.2 card. Both use PCIe to connect to the host system.
+
+As a PCIe endpoint/adapter, AIC100 uses the standard VendorID(VID)/
+DeviceID(DID) combination to uniquely identify itself to the host. AIC100
+uses the standard Qualcomm VID (0x17cb). All AIC100 SKUs use the same
+AIC100 DID (0xa100).
+
+AIC100 does not implement FLR (function level reset).
+
+AIC100 implements MSI but does not implement MSI-X. AIC100 prefers 17 MSIs to
+operate (1 for MHI, 16 for the DMA Bridge). Falling back to 1 MSI is possible in
+scenarios where reserving 32 MSIs isn't feasible.
+
+As a PCIe device, AIC100 utilizes BARs to provide host interfaces to the device
+hardware. AIC100 provides 3, 64-bit BARs.
+
+* The first BAR is 4K in size, and exposes the MHI interface to the host.
+
+* The second BAR is 2M in size, and exposes the DMA Bridge interface to the
+ host.
+
+* The third BAR is variable in size based on an individual AIC100's
+ configuration, but defaults to 64K. This BAR currently has no purpose.
+
+From the host perspective, AIC100 has several key hardware components -
+
+* MHI (Modem Host Interface)
+* QSM (QAIC Service Manager)
+* NSPs (Neural Signal Processor)
+* DMA Bridge
+* DDR
+
+MHI
+---
+
+AIC100 has one MHI interface over PCIe. MHI itself is documented at
+Documentation/mhi/index.rst MHI is the mechanism the host uses to communicate
+with the QSM. Except for workload data via the DMA Bridge, all interaction with
+the device occurs via MHI.
+
+QSM
+---
+
+QAIC Service Manager. This is an ARM A53 CPU that runs the primary
+firmware of the card and performs on-card management tasks. It also
+communicates with the host via MHI. Each AIC100 has one of
+these.
+
+NSP
+---
+
+Neural Signal Processor. Each AIC100 has up to 16 of these. These are
+the processors that run the workloads on AIC100. Each NSP is a Qualcomm Hexagon
+(Q6) DSP with HVX and HMX. Each NSP can only run one workload at a time, but
+multiple NSPs may be assigned to a single workload. Since each NSP can only run
+one workload, AIC100 is limited to 16 concurrent workloads. Workload
+"scheduling" is under the purview of the host. AIC100 does not automatically
+timeslice.
+
+DMA Bridge
+----------
+
+The DMA Bridge is custom DMA engine that manages the flow of data
+in and out of workloads. AIC100 has one of these. The DMA Bridge has 16
+channels, each consisting of a set of request/response FIFOs. Each active
+workload is assigned a single DMA Bridge channel. The DMA Bridge exposes
+hardware registers to manage the FIFOs (head/tail pointers), but requires host
+memory to store the FIFOs.
+
+DDR
+---
+
+AIC100 has on-card DDR. In total, an AIC100 can have up to 32 GB of DDR.
+This DDR is used to store workloads, data for the workloads, and is used by the
+QSM for managing the device. NSPs are granted access to sections of the DDR by
+the QSM. The host does not have direct access to the DDR, and must make
+requests to the QSM to transfer data to the DDR.
+
+High-level Use Flow
+===================
+
+AIC100 is a multi-user, programmable accelerator typically used for running
+neural networks in inferencing mode to efficiently perform AI operations.
+AIC100 is not intended for training neural networks. AIC100 can be utilized
+for generic compute workloads.
+
+Assuming a user wants to utilize AIC100, they would follow these steps:
+
+1. Compile the workload into an ELF targeting the NSP(s)
+2. Make requests to the QSM to load the workload and related artifacts into the
+ device DDR
+3. Make a request to the QSM to activate the workload onto a set of idle NSPs
+4. Make requests to the DMA Bridge to send input data to the workload to be
+ processed, and other requests to receive processed output data from the
+ workload.
+5. Once the workload is no longer required, make a request to the QSM to
+ deactivate the workload, thus putting the NSPs back into an idle state.
+6. Once the workload and related artifacts are no longer needed for future
+ sessions, make requests to the QSM to unload the data from DDR. This frees
+ the DDR to be used by other users.
+
+
+Boot Flow
+=========
+
+AIC100 uses a flashless boot flow, derived from Qualcomm MSMs.
+
+When AIC100 is first powered on, it begins executing PBL (Primary Bootloader)
+from ROM. PBL enumerates the PCIe link, and initializes the BHI (Boot Host
+Interface) component of MHI.
+
+Using BHI, the host points PBL to the location of the SBL (Secondary Bootloader)
+image. The PBL pulls the image from the host, validates it, and begins
+execution of SBL.
+
+SBL initializes MHI, and uses MHI to notify the host that the device has entered
+the SBL stage. SBL performs a number of operations:
+
+* SBL initializes the majority of hardware (anything PBL left uninitialized),
+ including DDR.
+* SBL offloads the bootlog to the host.
+* SBL synchronizes timestamps with the host for future logging.
+* SBL uses the Sahara protocol to obtain the runtime firmware images from the
+ host.
+
+Once SBL has obtained and validated the runtime firmware, it brings the NSPs out
+of reset, and jumps into the QSM.
+
+The QSM uses MHI to notify the host that the device has entered the QSM stage
+(AMSS in MHI terms). At this point, the AIC100 device is fully functional, and
+ready to process workloads.
+
+Userspace components
+====================
+
+Compiler
+--------
+
+An open compiler for AIC100 based on upstream LLVM can be found at:
+https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100-cc
+
+Usermode Driver (UMD)
+---------------------
+
+An open UMD that interfaces with the qaic kernel driver can be found at:
+https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100
+
+Sahara loader
+-------------
+
+An open implementation of the Sahara protocol called kickstart can be found at:
+https://github.com/andersson/qdl
+
+MHI Channels
+============
+
+AIC100 defines a number of MHI channels for different purposes. This is a list
+of the defined channels, and their uses.
+
++----------------+---------+----------+----------------------------------------+
+| Channel name | IDs | EEs | Purpose |
++================+=========+==========+========================================+
+| QAIC_LOOPBACK | 0 & 1 | AMSS | Any data sent to the device on this |
+| | | | channel is sent back to the host. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_SAHARA | 2 & 3 | SBL | Used by SBL to obtain the runtime |
+| | | | firmware from the host. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_DIAG | 4 & 5 | AMSS | Used to communicate with QSM via the |
+| | | | DIAG protocol. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_SSR | 6 & 7 | AMSS | Used to notify the host of subsystem |
+| | | | restart events, and to offload SSR |
+| | | | crashdumps. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_QDSS | 8 & 9 | AMSS | Used for the Qualcomm Debug Subsystem. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_CONTROL | 10 & 11 | AMSS | Used for the Neural Network Control |
+| | | | (NNC) protocol. This is the primary |
+| | | | channel between host and QSM for |
+| | | | managing workloads. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_LOGGING | 12 & 13 | SBL | Used by the SBL to send the bootlog to |
+| | | | the host. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_STATUS | 14 & 15 | AMSS | Used to notify the host of Reliability,|
+| | | | Accessibility, Serviceability (RAS) |
+| | | | events. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_TELEMETRY | 16 & 17 | AMSS | Used to get/set power/thermal/etc |
+| | | | attributes. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_DEBUG | 18 & 19 | AMSS | Not used. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_TIMESYNC | 20 & 21 | SBL | Used to synchronize timestamps in the |
+| | | | device side logs with the host time |
+| | | | source. |
++----------------+---------+----------+----------------------------------------+
+| QAIC_TIMESYNC | 22 & 23 | AMSS | Used to periodically synchronize |
+| _PERIODIC | | | timestamps in the device side logs with|
+| | | | the host time source. |
++----------------+---------+----------+----------------------------------------+
+| IPCR | 24 & 25 | AMSS | AF_QIPCRTR clients and servers. |
++----------------+---------+----------+----------------------------------------+
+
+DMA Bridge
+==========
+
+Overview
+--------
+
+The DMA Bridge is one of the main interfaces to the host from the device
+(the other being MHI). As part of activating a workload to run on NSPs, the QSM
+assigns that network a DMA Bridge channel. A workload's DMA Bridge channel
+(DBC for short) is solely for the use of that workload and is not shared with
+other workloads.
+
+Each DBC is a pair of FIFOs that manage data in and out of the workload. One
+FIFO is the request FIFO. The other FIFO is the response FIFO.
+
+Each DBC contains 4 registers in hardware:
+
+* Request FIFO head pointer (offset 0x0). Read only by the host. Indicates the
+ latest item in the FIFO the device has consumed.
+* Request FIFO tail pointer (offset 0x4). Read/write by the host. Host
+ increments this register to add new items to the FIFO.
+* Response FIFO head pointer (offset 0x8). Read/write by the host. Indicates
+ the latest item in the FIFO the host has consumed.
+* Response FIFO tail pointer (offset 0xc). Read only by the host. Device
+ increments this register to add new items to the FIFO.
+
+The values in each register are indexes in the FIFO. To get the location of the
+FIFO element pointed to by the register: FIFO base address + register * element
+size.
+
+DBC registers are exposed to the host via the second BAR. Each DBC consumes
+4KB of space in the BAR.
+
+The actual FIFOs are backed by host memory. When sending a request to the QSM
+to activate a network, the host must donate memory to be used for the FIFOs.
+Due to internal mapping limitations of the device, a single contiguous chunk of
+memory must be provided per DBC, which hosts both FIFOs. The request FIFO will
+consume the beginning of the memory chunk, and the response FIFO will consume
+the end of the memory chunk.
+
+Request FIFO
+------------
+
+A request FIFO element has the following structure:
+
+.. code-block:: c
+
+ struct request_elem {
+ u16 req_id;
+ u8 seq_id;
+ u8 pcie_dma_cmd;
+ u32 reserved;
+ u64 pcie_dma_source_addr;
+ u64 pcie_dma_dest_addr;
+ u32 pcie_dma_len;
+ u32 reserved;
+ u64 doorbell_addr;
+ u8 doorbell_attr;
+ u8 reserved;
+ u16 reserved;
+ u32 doorbell_data;
+ u32 sem_cmd0;
+ u32 sem_cmd1;
+ u32 sem_cmd2;
+ u32 sem_cmd3;
+ };
+
+Request field descriptions:
+
+req_id
+ request ID. A request FIFO element and a response FIFO element with
+ the same request ID refer to the same command.
+
+seq_id
+ sequence ID within a request. Ignored by the DMA Bridge.
+
+pcie_dma_cmd
+ describes the DMA element of this request.
+
+ * Bit(7) is the force msi flag, which overrides the DMA Bridge MSI logic
+ and generates a MSI when this request is complete, and QSM
+ configures the DMA Bridge to look at this bit.
+ * Bits(6:5) are reserved.
+ * Bit(4) is the completion code flag, and indicates that the DMA Bridge
+ shall generate a response FIFO element when this request is
+ complete.
+ * Bit(3) indicates if this request is a linked list transfer(0) or a bulk
+ transfer(1).
+ * Bit(2) is reserved.
+ * Bits(1:0) indicate the type of transfer. No transfer(0), to device(1),
+ from device(2). Value 3 is illegal.
+
+pcie_dma_source_addr
+ source address for a bulk transfer, or the address of the linked list.
+
+pcie_dma_dest_addr
+ destination address for a bulk transfer.
+
+pcie_dma_len
+ length of the bulk transfer. Note that the size of this field
+ limits transfers to 4G in size.
+
+doorbell_addr
+ address of the doorbell to ring when this request is complete.
+
+doorbell_attr
+ doorbell attributes.
+
+ * Bit(7) indicates if a write to a doorbell is to occur.
+ * Bits(6:2) are reserved.
+ * Bits(1:0) contain the encoding of the doorbell length. 0 is 32-bit,
+ 1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell address
+ must be naturally aligned to the specified length.
+
+doorbell_data
+ data to write to the doorbell. Only the bits corresponding to
+ the doorbell length are valid.
+
+sem_cmdN
+ semaphore command.
+
+ * Bit(31) indicates this semaphore command is enabled.
+ * Bit(30) is the to-device DMA fence. Block this request until all
+ to-device DMA transfers are complete.
+ * Bit(29) is the from-device DMA fence. Block this request until all
+ from-device DMA transfers are complete.
+ * Bits(28:27) are reserved.
+ * Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with the
+ specified value. 2 is increment. 3 is decrement. 4 is wait
+ until the semaphore is equal to the specified value. 5 is wait
+ until the semaphore is greater or equal to the specified value.
+ 6 is "P", wait until semaphore is greater than 0, then
+ decrement by 1. 7 is reserved.
+ * Bit(23) is reserved.
+ * Bit(22) is the semaphore sync. 0 is post sync, which means that the
+ semaphore operation is done after the DMA transfer. 1 is
+ presync, which gates the DMA transfer. Only one presync is
+ allowed per request.
+ * Bit(21) is reserved.
+ * Bits(20:16) is the index of the semaphore to operate on.
+ * Bits(15:12) are reserved.
+ * Bits(11:0) are the semaphore value to use in operations.
+
+Overall, a request is processed in 4 steps:
+
+1. If specified, the presync semaphore condition must be true
+2. If enabled, the DMA transfer occurs
+3. If specified, the postsync semaphore conditions must be true
+4. If enabled, the doorbell is written
+
+By using the semaphores in conjunction with the workload running on the NSPs,
+the data pipeline can be synchronized such that the host can queue multiple
+requests of data for the workload to process, but the DMA Bridge will only copy
+the data into the memory of the workload when the workload is ready to process
+the next input.
+
+Response FIFO
+-------------
+
+Once a request is fully processed, a response FIFO element is generated if
+specified in pcie_dma_cmd. The structure of a response FIFO element:
+
+.. code-block:: c
+
+ struct response_elem {
+ u16 req_id;
+ u16 completion_code;
+ };
+
+req_id
+ matches the req_id of the request that generated this element.
+
+completion_code
+ status of this request. 0 is success. Non-zero is an error.
+
+The DMA Bridge will generate a MSI to the host as a reaction to activity in the
+response FIFO of a DBC. The DMA Bridge hardware has an IRQ storm mitigation
+algorithm, where it will only generate a MSI when the response FIFO transitions
+from empty to non-empty (unless force MSI is enabled and triggered). In
+response to this MSI, the host is expected to drain the response FIFO, and must
+take care to handle any race conditions between draining the FIFO, and the
+device inserting elements into the FIFO.
+
+Neural Network Control (NNC) Protocol
+=====================================
+
+The NNC protocol is how the host makes requests to the QSM to manage workloads.
+It uses the QAIC_CONTROL MHI channel.
+
+Each NNC request is packaged into a message. Each message is a series of
+transactions. A passthrough type transaction can contain elements known as
+commands.
+
+QSM requires NNC messages be little endian encoded and the fields be naturally
+aligned. Since there are 64-bit elements in some NNC messages, 64-bit alignment
+must be maintained.
+
+A message contains a header and then a series of transactions. A message may be
+at most 4K in size from QSM to the host. From the host to the QSM, a message
+can be at most 64K (maximum size of a single MHI packet), but there is a
+continuation feature where message N+1 can be marked as a continuation of
+message N. This is used for exceedingly large DMA xfer transactions.
+
+Transaction descriptions
+------------------------
+
+passthrough
+ Allows userspace to send an opaque payload directly to the QSM.
+ This is used for NNC commands. Userspace is responsible for managing
+ the QSM message requirements in the payload.
+
+dma_xfer
+ DMA transfer. Describes an object that the QSM should DMA into the
+ device via address and size tuples.
+
+activate
+ Activate a workload onto NSPs. The host must provide memory to be
+ used by the DBC.
+
+deactivate
+ Deactivate an active workload and return the NSPs to idle.
+
+status
+ Query the QSM about it's NNC implementation. Returns the NNC version,
+ and if CRC is used.
+
+terminate
+ Release a user's resources.
+
+dma_xfer_cont
+ Continuation of a previous DMA transfer. If a DMA transfer
+ cannot be specified in a single message (highly fragmented), this
+ transaction can be used to specify more ranges.
+
+validate_partition
+ Query to QSM to determine if a partition identifier is valid.
+
+Each message is tagged with a user id, and a partition id. The user id allows
+QSM to track resources, and release them when the user goes away (eg the process
+crashes). A partition id identifies the resource partition that QSM manages,
+which this message applies to.
+
+Messages may have CRCs. Messages should have CRCs applied until the QSM
+reports via the status transaction that CRCs are not needed. The QSM on the
+SA9000P requires CRCs for black channel safing.
+
+Subsystem Restart (SSR)
+=======================
+
+SSR is the concept of limiting the impact of an error. An AIC100 device may
+have multiple users, each with their own workload running. If the workload of
+one user crashes, the fallout of that should be limited to that workload and not
+impact other workloads. SSR accomplishes this.
+
+If a particular workload crashes, QSM notifies the host via the QAIC_SSR MHI
+channel. This notification identifies the workload by its assigned DBC. A
+multi-stage recovery process is then used to cleanup both sides, and gets the
+DBC/NSPs into a working state.
+
+When SSR occurs, any state in the workload is lost. Any inputs that were in
+process, or queued by not yet serviced, are lost. The loaded artifacts will
+remain in on-card DDR, but the host will need to re-activate the workload if
+it desires to recover the workload.
+
+When SSR occurs for a specific NSP, the assigned DBC goes through the
+following state transactions in order:
+
+DBC_STATE_BEFORE_SHUTDOWN
+ Indicates that the affected NSP was found in an unrecoverable error
+ condition.
+DBC_STATE_AFTER_SHUTDOWN
+ Indicates that the NSP is under reset.
+DBC_STATE_BEFORE_POWER_UP
+ Indicates that the NSP's debug information has been collected, and is
+ ready to be collected by the host (if desired). At that stage the NSP
+ is restarted by QSM.
+DBC_STATE_AFTER_POWER_UP
+ Indicates that the NSP has been restarted, fully operational and is
+ in idle state.
+
+SSR also has an optional crashdump collection feature. If enabled, the host can
+collect the memory dump for the crashed NSP and dump it to the user space via
+the dev_coredump subsystem. The host can also decline the crashdump collection
+request from the device.
+
+Reliability, Accessibility, Serviceability (RAS)
+================================================
+
+AIC100 is expected to be deployed in server systems where RAS ideology is
+applied. Simply put, RAS is the concept of detecting, classifying, and
+reporting errors. While PCIe has AER (Advanced Error Reporting) which factors
+into RAS, AER does not allow for a device to report details about internal
+errors. Therefore, AIC100 implements a custom RAS mechanism. When a RAS event
+occurs, QSM will report the event with appropriate details via the QAIC_STATUS
+MHI channel. A sysadmin may determine that a particular device needs
+additional service based on RAS reports.
+
+Telemetry
+=========
+
+QSM has the ability to report various physical attributes of the device, and in
+some cases, to allow the host to control them. Examples include thermal limits,
+thermal readings, and power readings. These items are communicated via the
+QAIC_TELEMETRY MHI channel.
diff --git a/Documentation/accel/qaic/index.rst b/Documentation/accel/qaic/index.rst
new file mode 100644
index 000000000000..967b9dd8bace
--- /dev/null
+++ b/Documentation/accel/qaic/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=====================================
+ accel/qaic Qualcomm Cloud AI driver
+=====================================
+
+The accel/qaic driver supports the Qualcomm Cloud AI machine learning
+accelerator cards.
+
+.. toctree::
+
+ qaic
+ aic080
+ aic100
diff --git a/Documentation/accel/qaic/qaic.rst b/Documentation/accel/qaic/qaic.rst
new file mode 100644
index 000000000000..ef27e262cb91
--- /dev/null
+++ b/Documentation/accel/qaic/qaic.rst
@@ -0,0 +1,209 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+ QAIC driver
+=============
+
+The QAIC driver is the Kernel Mode Driver (KMD) for the AIC100 family of AI
+accelerator products.
+
+Interrupts
+==========
+
+IRQ Storm Mitigation
+--------------------
+
+While the AIC100 DMA Bridge hardware implements an IRQ storm mitigation
+mechanism, it is still possible for an IRQ storm to occur. A storm can happen
+if the workload is particularly quick, and the host is responsive. If the host
+can drain the response FIFO as quickly as the device can insert elements into
+it, then the device will frequently transition the response FIFO from empty to
+non-empty and generate MSIs at a rate equivalent to the speed of the
+workload's ability to process inputs. The lprnet (license plate reader network)
+workload is known to trigger this condition, and can generate in excess of 100k
+MSIs per second. It has been observed that most systems cannot tolerate this
+for long, and will crash due to some form of watchdog due to the overhead of
+the interrupt controller interrupting the host CPU.
+
+To mitigate this issue, the QAIC driver implements specific IRQ handling. When
+QAIC receives an IRQ, it disables that line. This prevents the interrupt
+controller from interrupting the CPU. Then AIC drains the FIFO. Once the FIFO
+is drained, QAIC implements a "last chance" polling algorithm where QAIC will
+sleep for a time to see if the workload will generate more activity. The IRQ
+line remains disabled during this time. If no activity is detected, QAIC exits
+polling mode and reenables the IRQ line.
+
+This mitigation in QAIC is very effective. The same lprnet usecase that
+generates 100k IRQs per second (per /proc/interrupts) is reduced to roughly 64
+IRQs over 5 minutes while keeping the host system stable, and having the same
+workload throughput performance (within run-to-run noise variation).
+
+Single MSI Mode
+---------------
+
+MultiMSI is not well supported on all systems; virtualized ones even less so
+(circa 2023). Between hypervisors masking the PCIe MSI capability structure to
+large memory requirements for vIOMMUs (required for supporting MultiMSI), it is
+useful to be able to fall back to a single MSI when needed.
+
+To support this fallback, we allow the case where only one MSI is able to be
+allocated, and share that one MSI between MHI and the DBCs. The device detects
+when only one MSI has been configured and directs the interrupts for the DBCs
+to the interrupt normally used for MHI. Unfortunately, this means that the
+interrupt handlers for every DBC and MHI wake up for every interrupt that
+arrives; however, the DBC threaded irq handlers only are started when work to be
+done is detected (MHI will always start its threaded handler).
+
+If the DBC is configured to force MSI interrupts, this can circumvent the
+software IRQ storm mitigation mentioned above. Since the MSI is shared it is
+never disabled, allowing each new entry to the FIFO to trigger a new interrupt.
+
+
+Neural Network Control (NNC) Protocol
+=====================================
+
+The implementation of NNC is split between the KMD (QAIC) and UMD. In general,
+QAIC understands how to encode/decode NNC wire protocol, and elements of the
+protocol which requires kernel space knowledge to process (for example, mapping
+host memory to device IOVAs). QAIC understands the structure of a message, and
+all of the transactions. QAIC does not understand commands (the payload of a
+passthrough transaction).
+
+QAIC handles and enforces the required little endianness and 64-bit alignment,
+to the degree that it can. Since QAIC does not know the contents of a
+passthrough transaction, it relies on the UMD to satisfy the requirements.
+
+The terminate transaction is of particular use to QAIC. QAIC is not aware of
+the resources that are loaded onto a device since the majority of that activity
+occurs within NNC commands. As a result, QAIC does not have the means to
+roll back userspace activity. To ensure that a userspace client's resources
+are fully released in the case of a process crash, or a bug, QAIC uses the
+terminate command to let QSM know when a user has gone away, and the resources
+can be released.
+
+QSM can report a version number of the NNC protocol it supports. This is in the
+form of a Major number and a Minor number.
+
+Major number updates indicate changes to the NNC protocol which impact the
+message format, or transactions (impacts QAIC).
+
+Minor number updates indicate changes to the NNC protocol which impact the
+commands (does not impact QAIC).
+
+uAPI
+====
+
+QAIC creates an accel device per physical PCIe device. This accel device exists
+for as long as the PCIe device is known to Linux.
+
+The PCIe device may not be in the state to accept requests from userspace at
+all times. QAIC will trigger KOBJ_ONLINE/OFFLINE uevents to advertise when the
+device can accept requests (ONLINE) and when the device is no longer accepting
+requests (OFFLINE) because of a reset or other state transition.
+
+QAIC defines a number of driver specific IOCTLs as part of the userspace API.
+
+DRM_IOCTL_QAIC_MANAGE
+ This IOCTL allows userspace to send a NNC request to the QSM. The call will
+ block until a response is received, or the request has timed out.
+
+DRM_IOCTL_QAIC_CREATE_BO
+ This IOCTL allows userspace to allocate a buffer object (BO) which can send
+ or receive data from a workload. The call will return a GEM handle that
+ represents the allocated buffer. The BO is not usable until it has been
+ sliced (see DRM_IOCTL_QAIC_ATTACH_SLICE_BO).
+
+DRM_IOCTL_QAIC_MMAP_BO
+ This IOCTL allows userspace to prepare an allocated BO to be mmap'd into the
+ userspace process.
+
+DRM_IOCTL_QAIC_ATTACH_SLICE_BO
+ This IOCTL allows userspace to slice a BO in preparation for sending the BO
+ to the device. Slicing is the operation of describing what portions of a BO
+ get sent where to a workload. This requires a set of DMA transfers for the
+ DMA Bridge, and as such, locks the BO to a specific DBC.
+
+DRM_IOCTL_QAIC_EXECUTE_BO
+ This IOCTL allows userspace to submit a set of sliced BOs to the device. The
+ call is non-blocking. Success only indicates that the BOs have been queued
+ to the device, but does not guarantee they have been executed.
+
+DRM_IOCTL_QAIC_PARTIAL_EXECUTE_BO
+ This IOCTL operates like DRM_IOCTL_QAIC_EXECUTE_BO, but it allows userspace
+ to shrink the BOs sent to the device for this specific call. If a BO
+ typically has N inputs, but only a subset of those is available, this IOCTL
+ allows userspace to indicate that only the first M bytes of the BO should be
+ sent to the device to minimize data transfer overhead. This IOCTL dynamically
+ recomputes the slicing, and therefore has some processing overhead before the
+ BOs can be queued to the device.
+
+DRM_IOCTL_QAIC_WAIT_BO
+ This IOCTL allows userspace to determine when a particular BO has been
+ processed by the device. The call will block until either the BO has been
+ processed and can be re-queued to the device, or a timeout occurs.
+
+DRM_IOCTL_QAIC_PERF_STATS_BO
+ This IOCTL allows userspace to collect performance statistics on the most
+ recent execution of a BO. This allows userspace to construct an end to end
+ timeline of the BO processing for a performance analysis.
+
+DRM_IOCTL_QAIC_DETACH_SLICE_BO
+ This IOCTL allows userspace to remove the slicing information from a BO that
+ was originally provided by a call to DRM_IOCTL_QAIC_ATTACH_SLICE_BO. This
+ is the inverse of DRM_IOCTL_QAIC_ATTACH_SLICE_BO. The BO must be idle for
+ DRM_IOCTL_QAIC_DETACH_SLICE_BO to be called. After a successful detach slice
+ operation the BO may have new slicing information attached with a new call
+ to DRM_IOCTL_QAIC_ATTACH_SLICE_BO. After detach slice, the BO cannot be
+ executed until after a new attach slice operation. Combining attach slice
+ and detach slice calls allows userspace to use a BO with multiple workloads.
+
+Userspace Client Isolation
+==========================
+
+AIC100 supports multiple clients. Multiple DBCs can be consumed by a single
+client, and multiple clients can each consume one or more DBCs. Workloads
+may contain sensitive information therefore only the client that owns the
+workload should be allowed to interface with the DBC.
+
+Clients are identified by the instance associated with their open(). A client
+may only use memory they allocate, and DBCs that are assigned to their
+workloads. Attempts to access resources assigned to other clients will be
+rejected.
+
+Module parameters
+=================
+
+QAIC supports the following module parameters:
+
+**datapath_polling (bool)**
+
+Configures QAIC to use a polling thread for datapath events instead of relying
+on the device interrupts. Useful for platforms with broken multiMSI. Must be
+set at QAIC driver initialization. Default is 0 (off).
+
+**mhi_timeout_ms (unsigned int)**
+
+Sets the timeout value for MHI operations in milliseconds (ms). Must be set
+at the time the driver detects a device. Default is 2000 (2 seconds).
+
+**control_resp_timeout_s (unsigned int)**
+
+Sets the timeout value for QSM responses to NNC messages in seconds (s). Must
+be set at the time the driver is sending a request to QSM. Default is 60 (one
+minute).
+
+**wait_exec_default_timeout_ms (unsigned int)**
+
+Sets the default timeout for the wait_exec ioctl in milliseconds (ms). Must be
+set prior to the waic_exec ioctl call. A value specified in the ioctl call
+overrides this for that call. Default is 5000 (5 seconds).
+
+**datapath_poll_interval_us (unsigned int)**
+
+Sets the polling interval in microseconds (us) when datapath polling is active.
+Takes effect at the next polling interval. Default is 100 (100 us).
+
+**timesync_delay_ms (unsigned int)**
+
+Sets the time interval in milliseconds (ms) between two consecutive timesync
+operations. Default is 1000 (1000 ms).
diff --git a/Documentation/accel/rocket/index.rst b/Documentation/accel/rocket/index.rst
new file mode 100644
index 000000000000..70f97bccf100
--- /dev/null
+++ b/Documentation/accel/rocket/index.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=====================================
+ accel/rocket Rockchip NPU driver
+=====================================
+
+The accel/rocket driver supports the Neural Processing Units (NPUs) inside some
+Rockchip SoCs such as the RK3588. Rockchip calls it RKNN and sometimes RKNPU.
+
+The hardware is described in chapter 36 in the RK3588 TRM.
+
+This driver just powers the hardware on and off, allocates and maps buffers to
+the device and submits jobs to the frontend unit. Everything else is done in
+userspace, as a Gallium driver (also called rocket) that is part of the Mesa3D
+project.
+
+Hardware currently supported:
+
+* RK3588
diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst
index 241d1a87f2cd..86d7902a657f 100644
--- a/Documentation/accounting/delay-accounting.rst
+++ b/Documentation/accounting/delay-accounting.rst
@@ -13,9 +13,10 @@ a) waiting for a CPU (while being runnable)
b) completion of synchronous block I/O initiated by the task
c) swapping in pages
d) memory reclaim
-e) thrashing page cache
+e) thrashing
f) direct compact
g) write-protect copy
+h) IRQ/SOFTIRQ
and makes these statistics available to userspace through
the taskstats interface.
@@ -49,7 +50,7 @@ this structure. See
for a description of the fields pertaining to delay accounting.
It will generally be in the form of counters returning the cumulative
delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page
-cache, direct compact, write-protect copy etc.
+cache, direct compact, write-protect copy, IRQ/SOFTIRQ etc.
Taking the difference of two successive readings of a given
counter (say cpu_delay_total) for a task will give the delay
@@ -99,27 +100,29 @@ Get delays, since system boot, for pid 10::
# ./getdelays -d -p 10
(output similar to next case)
-Get sum of delays, since system boot, for all pids with tgid 5::
+Get sum and peak of delays, since system boot, for all pids with tgid 242::
- # ./getdelays -d -t 5
+ bash-4.4# ./getdelays -d -t 242
print delayacct stats ON
- TGID 5
-
-
- CPU count real total virtual total delay total delay average
- 8 7000000 6872122 3382277 0.423ms
- IO count delay total delay average
- 0 0 0ms
- SWAP count delay total delay average
- 0 0 0ms
- RECLAIM count delay total delay average
- 0 0 0ms
- THRASHING count delay total delay average
- 0 0 0ms
- COMPACT count delay total delay average
- 0 0 0ms
- WPCOPY count delay total delay average
- 0 0 0ms
+ TGID 242
+
+
+ CPU count real total virtual total delay total delay average delay max delay min
+ 39 156000000 156576579 2111069 0.054ms 0.212296ms 0.031307ms
+ IO count delay total delay average delay max delay min
+ 0 0 0.000ms 0.000000ms 0.000000ms
+ SWAP count delay total delay average delay max delay min
+ 0 0 0.000ms 0.000000ms 0.000000ms
+ RECLAIM count delay total delay average delay max delay min
+ 0 0 0.000ms 0.000000ms 0.000000ms
+ THRASHING count delay total delay average delay max delay min
+ 0 0 0.000ms 0.000000ms 0.000000ms
+ COMPACT count delay total delay average delay max delay min
+ 0 0 0.000ms 0.000000ms 0.000000ms
+ WPCOPY count delay total delay average delay max delay min
+ 156 11215873 0.072ms 0.207403ms 0.033913ms
+ IRQ count delay total delay average delay max delay min
+ 0 0 0.000ms 0.000000ms 0.000000ms
Get IO accounting for pid 1, it works only with -p::
@@ -128,3 +131,84 @@ Get IO accounting for pid 1, it works only with -p::
linuxrc: read=65536, write=0, cancelled_write=0
The above command can be used with -v to get more debug information.
+
+After the system starts, use `delaytop` to get the system-wide delay information,
+which includes system-wide PSI information and Top-N high-latency tasks.
+Note: PSI support requires `CONFIG_PSI=y` and `psi=1` for full functionality.
+
+`delaytop` is an interactive tool for monitoring system pressure and task delays.
+It supports multiple sorting options, display modes, and real-time keyboard controls.
+
+Basic usage with default settings (sorts by CPU delay, shows top 20 tasks, refreshes every 2 seconds)::
+
+ bash# ./delaytop
+ System Pressure Information: (avg10/avg60vg300/total)
+ CPU some: 0.0%/ 0.0%/ 0.0%/ 106137(ms)
+ CPU full: 0.0%/ 0.0%/ 0.0%/ 0(ms)
+ Memory full: 0.0%/ 0.0%/ 0.0%/ 0(ms)
+ Memory some: 0.0%/ 0.0%/ 0.0%/ 0(ms)
+ IO full: 0.0%/ 0.0%/ 0.0%/ 2240(ms)
+ IO some: 0.0%/ 0.0%/ 0.0%/ 2783(ms)
+ IRQ full: 0.0%/ 0.0%/ 0.0%/ 0(ms)
+ [o]sort [M]memverbose [q]quit
+ Top 20 processes (sorted by cpu delay):
+ PID TGID COMMAND CPU(ms) IO(ms) IRQ(ms) MEM(ms)
+ ------------------------------------------------------------------------
+ 110 110 kworker/15:0H-s 27.91 0.00 0.00 0.00
+ 57 57 cpuhp/7 3.18 0.00 0.00 0.00
+ 99 99 cpuhp/14 2.97 0.00 0.00 0.00
+ 51 51 cpuhp/6 0.90 0.00 0.00 0.00
+ 44 44 kworker/4:0H-sy 0.80 0.00 0.00 0.00
+ 60 60 ksoftirqd/7 0.74 0.00 0.00 0.00
+ 76 76 idle_inject/10 0.31 0.00 0.00 0.00
+ 100 100 idle_inject/14 0.30 0.00 0.00 0.00
+ 1309 1309 systemsettings 0.29 0.00 0.00 0.00
+ 45 45 cpuhp/5 0.22 0.00 0.00 0.00
+ 63 63 cpuhp/8 0.20 0.00 0.00 0.00
+ 87 87 cpuhp/12 0.18 0.00 0.00 0.00
+ 93 93 cpuhp/13 0.17 0.00 0.00 0.00
+ 1265 1265 acpid 0.17 0.00 0.00 0.00
+ 1552 1552 sshd 0.17 0.00 0.00 0.00
+ 2584 2584 sddm-helper 0.16 0.00 0.00 0.00
+ 1284 1284 rtkit-daemon 0.15 0.00 0.00 0.00
+ 1326 1326 nde-netfilter 0.14 0.00 0.00 0.00
+ 27 27 cpuhp/2 0.13 0.00 0.00 0.00
+ 631 631 kworker/11:2-rc 0.11 0.00 0.00 0.00
+
+Interactive keyboard controls during runtime::
+
+ o - Select sort field (CPU, IO, IRQ, Memory, etc.)
+ M - Toggle display mode (Default/Memory Verbose)
+ q - Quit
+
+Available sort fields(use -s/--sort or interactive command)::
+
+ cpu(c) - CPU delay
+ blkio(i) - I/O delay
+ irq(q) - IRQ delay
+ mem(m) - Total memory delay
+ swapin(s) - Swapin delay (memory verbose mode only)
+ freepages(r) - Freepages reclaim delay (memory verbose mode only)
+ thrashing(t) - Thrashing delay (memory verbose mode only)
+ compact(p) - Compaction delay (memory verbose mode only)
+ wpcopy(w) - Write page copy delay (memory verbose mode only)
+
+Advanced usage examples::
+
+ # ./delaytop -s blkio
+ Sorted by IO delay
+
+ # ./delaytop -s mem -M
+ Sorted by memory delay in memory verbose mode
+
+ # ./delaytop -p pid
+ Print delayacct stats
+
+ # ./delaytop -P num
+ Display the top N tasks
+
+ # ./delaytop -n num
+ Set delaytop refresh frequency (num times)
+
+ # ./delaytop -d secs
+ Specify refresh interval as secs
diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst
index 5e40b3f437f9..d455db3e5808 100644
--- a/Documentation/accounting/psi.rst
+++ b/Documentation/accounting/psi.rst
@@ -105,6 +105,10 @@ prevent overly frequent polling. Max limit is chosen as a high enough number
after which monitors are most likely not needed and psi averages can be used
instead.
+Unprivileged users can also create monitors, with the only limitation that the
+window size must be a multiple of 2s, in order to prevent excessive resource
+usage.
+
When activated, psi monitor stays active for at least the duration of one
tracking window to avoid repeated activations/deactivations when system is
bouncing in and out of the stall state.
@@ -174,7 +178,7 @@ Userspace monitor usage example
Cgroup2 interface
=================
-In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem
+In a system with a CONFIG_CGROUPS=y kernel and the cgroup2 filesystem
mounted, pressure stall information is also tracked for tasks grouped
into cgroups. Each subdirectory in the cgroupfs mountpoint contains
cpu.pressure, memory.pressure, and io.pressure files; the format is
diff --git a/Documentation/accounting/taskstats-struct.rst b/Documentation/accounting/taskstats-struct.rst
index ca90fd489c9a..acca51c34157 100644
--- a/Documentation/accounting/taskstats-struct.rst
+++ b/Documentation/accounting/taskstats-struct.rst
@@ -47,7 +47,7 @@ should not change the relative position of each field within the struct.
1) Common and basic accounting fields::
/* The version number of this struct. This field is always set to
- * TAKSTATS_VERSION, which is defined in <linux/taskstats.h>.
+ * TASKSTATS_VERSION, which is defined in <linux/taskstats.h>.
* Each time the struct is changed, the value should be incremented.
*/
__u16 version;
diff --git a/Documentation/accounting/taskstats.rst b/Documentation/accounting/taskstats.rst
index 2a28b7f55c10..173c1e7bf5ef 100644
--- a/Documentation/accounting/taskstats.rst
+++ b/Documentation/accounting/taskstats.rst
@@ -76,41 +76,43 @@ The messages are in the format::
The taskstats payload is one of the following three kinds:
1. Commands: Sent from user to kernel. Commands to get data on
-a pid/tgid consist of one attribute, of type TASKSTATS_CMD_ATTR_PID/TGID,
-containing a u32 pid or tgid in the attribute payload. The pid/tgid denotes
-the task/process for which userspace wants statistics.
-
-Commands to register/deregister interest in exit data from a set of cpus
-consist of one attribute, of type
-TASKSTATS_CMD_ATTR_REGISTER/DEREGISTER_CPUMASK and contain a cpumask in the
-attribute payload. The cpumask is specified as an ascii string of
-comma-separated cpu ranges e.g. to listen to exit data from cpus 1,2,3,5,7,8
-the cpumask would be "1-3,5,7-8". If userspace forgets to deregister interest
-in cpus before closing the listening socket, the kernel cleans up its interest
-set over time. However, for the sake of efficiency, an explicit deregistration
-is advisable.
+ a pid/tgid consist of one attribute, of type TASKSTATS_CMD_ATTR_PID/TGID,
+ containing a u32 pid or tgid in the attribute payload. The pid/tgid denotes
+ the task/process for which userspace wants statistics.
+
+ Commands to register/deregister interest in exit data from a set of cpus
+ consist of one attribute, of type
+ TASKSTATS_CMD_ATTR_REGISTER/DEREGISTER_CPUMASK and contain a cpumask in the
+ attribute payload. The cpumask is specified as an ascii string of
+ comma-separated cpu ranges e.g. to listen to exit data from cpus 1,2,3,5,7,8
+ the cpumask would be "1-3,5,7-8". If userspace forgets to deregister
+ interest in cpus before closing the listening socket, the kernel cleans up
+ its interest set over time. However, for the sake of efficiency, an explicit
+ deregistration is advisable.
2. Response for a command: sent from the kernel in response to a userspace
-command. The payload is a series of three attributes of type:
+ command. The payload is a series of three attributes of type:
-a) TASKSTATS_TYPE_AGGR_PID/TGID : attribute containing no payload but indicates
-a pid/tgid will be followed by some stats.
+ a) TASKSTATS_TYPE_AGGR_PID/TGID: attribute containing no payload but
+ indicates a pid/tgid will be followed by some stats.
-b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats
-are being returned.
+ b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose
+ stats are being returned.
-c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The
-same structure is used for both per-pid and per-tgid stats.
+ c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The
+ same structure is used for both per-pid and per-tgid stats.
3. New message sent by kernel whenever a task exits. The payload consists of a
series of attributes of the following type:
-a) TASKSTATS_TYPE_AGGR_PID: indicates next two attributes will be pid+stats
-b) TASKSTATS_TYPE_PID: contains exiting task's pid
-c) TASKSTATS_TYPE_STATS: contains the exiting task's per-pid stats
-d) TASKSTATS_TYPE_AGGR_TGID: indicates next two attributes will be tgid+stats
-e) TASKSTATS_TYPE_TGID: contains tgid of process to which task belongs
-f) TASKSTATS_TYPE_STATS: contains the per-tgid stats for exiting task's process
+ a) TASKSTATS_TYPE_AGGR_PID: indicates next two attributes will be pid+stats
+ b) TASKSTATS_TYPE_PID: contains exiting task's pid
+ c) TASKSTATS_TYPE_STATS: contains the exiting task's per-pid stats
+ d) TASKSTATS_TYPE_AGGR_TGID: indicates next two attributes will be
+ tgid+stats
+ e) TASKSTATS_TYPE_TGID: contains tgid of process to which task belongs
+ f) TASKSTATS_TYPE_STATS: contains the per-tgid stats for exiting task's
+ process
per-tgid stats
diff --git a/Documentation/admin-guide/LSM/SELinux.rst b/Documentation/admin-guide/LSM/SELinux.rst
index 520a1c2c6fd2..cdd65164ca96 100644
--- a/Documentation/admin-guide/LSM/SELinux.rst
+++ b/Documentation/admin-guide/LSM/SELinux.rst
@@ -2,6 +2,17 @@
SELinux
=======
+Information about the SELinux kernel subsystem can be found at the
+following links:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git/tree/README.md
+
+ https://github.com/selinuxproject/selinux-kernel/wiki
+
+Information about the SELinux userspace can be found at:
+
+ https://github.com/SELinuxProject/selinux/wiki
+
If you want to use SELinux, chances are you will want
to use the distro-provided policies, or install the
latest reference policy release from
diff --git a/Documentation/admin-guide/LSM/SafeSetID.rst b/Documentation/admin-guide/LSM/SafeSetID.rst
index 0ec34863c674..6d439c987563 100644
--- a/Documentation/admin-guide/LSM/SafeSetID.rst
+++ b/Documentation/admin-guide/LSM/SafeSetID.rst
@@ -41,7 +41,7 @@ namespace). The higher level goal is to allow for uid-based sandboxing of system
services without having to give out CAP_SETUID all over the place just so that
non-root programs can drop to even-lesser-privileged uids. This is especially
relevant when one non-root daemon on the system should be allowed to spawn other
-processes as different uids, but its undesirable to give the daemon a
+processes as different uids, but it's undesirable to give the daemon a
basically-root-equivalent CAP_SETUID.
diff --git a/Documentation/admin-guide/LSM/Smack.rst b/Documentation/admin-guide/LSM/Smack.rst
index 6d44f4fdbf59..c5ed775f2d10 100644
--- a/Documentation/admin-guide/LSM/Smack.rst
+++ b/Documentation/admin-guide/LSM/Smack.rst
@@ -601,10 +601,15 @@ specification.
Task Attribute
~~~~~~~~~~~~~~
-The Smack label of a process can be read from /proc/<pid>/attr/current. A
-process can read its own Smack label from /proc/self/attr/current. A
+The Smack label of a process can be read from ``/proc/<pid>/attr/current``. A
+process can read its own Smack label from ``/proc/self/attr/current``. A
privileged process can change its own Smack label by writing to
-/proc/self/attr/current but not the label of another process.
+``/proc/self/attr/current`` but not the label of another process.
+
+Format of writing is : only the label or the label followed by one of the
+3 trailers: ``\n`` (by common agreement for ``/proc/...`` interfaces),
+``\0`` (because some applications incorrectly include it),
+``\n\0`` (because we think some applications may incorrectly include it).
File Attribute
~~~~~~~~~~~~~~
@@ -696,6 +701,11 @@ sockets.
A privileged program may set this to match the label of another
task with which it hopes to communicate.
+UNIX domain socket (UDS) with a BSD address functions both as a file in a
+filesystem and as a socket. As a file, it carries the SMACK64 attribute. This
+attribute is not involved in Smack security enforcement and is immutably
+assigned the label "*".
+
Smack Netlabel Exceptions
~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/admin-guide/LSM/apparmor.rst b/Documentation/admin-guide/LSM/apparmor.rst
index 6cf81bbd7ce8..47939ee89d74 100644
--- a/Documentation/admin-guide/LSM/apparmor.rst
+++ b/Documentation/admin-guide/LSM/apparmor.rst
@@ -18,8 +18,11 @@ set ``CONFIG_SECURITY_APPARMOR=y``
If AppArmor should be selected as the default security module then set::
- CONFIG_DEFAULT_SECURITY="apparmor"
- CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
+ CONFIG_DEFAULT_SECURITY_APPARMOR=y
+
+The CONFIG_LSM parameter manages the order and selection of LSMs.
+Specify apparmor as the first "major" module (e.g. AppArmor, SELinux, Smack)
+in the list.
Build the kernel
diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst
index a6ba95fbaa9f..b44ef68f6e4d 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -47,3 +47,5 @@ subdirectories.
tomoyo
Yama
SafeSetID
+ ipe
+ landlock
diff --git a/Documentation/admin-guide/LSM/ipe.rst b/Documentation/admin-guide/LSM/ipe.rst
new file mode 100644
index 000000000000..a756d8158531
--- /dev/null
+++ b/Documentation/admin-guide/LSM/ipe.rst
@@ -0,0 +1,835 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Integrity Policy Enforcement (IPE)
+==================================
+
+.. NOTE::
+
+ This is the documentation for admins, system builders, or individuals
+ attempting to use IPE. If you're looking for more developer-focused
+ documentation about IPE please see :doc:`the design docs </security/ipe>`.
+
+Overview
+--------
+
+Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a
+complementary approach to access control. Unlike traditional access control
+mechanisms that rely on labels and paths for decision-making, IPE focuses
+on the immutable security properties inherent to system components. These
+properties are fundamental attributes or features of a system component
+that cannot be altered, ensuring a consistent and reliable basis for
+security decisions.
+
+To elaborate, in the context of IPE, system components primarily refer to
+files or the devices these files reside on. However, this is just a
+starting point. The concept of system components is flexible and can be
+extended to include new elements as the system evolves. The immutable
+properties include the origin of a file, which remains constant and
+unchangeable over time. For example, IPE policies can be crafted to trust
+files originating from the initramfs. Since initramfs is typically verified
+by the bootloader, its files are deemed trustworthy; "file is from
+initramfs" becomes an immutable property under IPE's consideration.
+
+The immutable property concept extends to the security features enabled on
+a file's origin, such as dm-verity or fs-verity, which provide a layer of
+integrity and trust. For example, IPE allows the definition of policies
+that trust files from a dm-verity protected device. dm-verity ensures the
+integrity of an entire device by providing a verifiable and immutable state
+of its contents. Similarly, fs-verity offers filesystem-level integrity
+checks, allowing IPE to enforce policies that trust files protected by
+fs-verity. These two features cannot be turned off once established, so
+they are considered immutable properties. These examples demonstrate how
+IPE leverages immutable properties, such as a file's origin and its
+integrity protection mechanisms, to make access control decisions.
+
+For the IPE policy, specifically, it grants the ability to enforce
+stringent access controls by assessing security properties against
+reference values defined within the policy. This assessment can be based on
+the existence of a security property (e.g., verifying if a file originates
+from initramfs) or evaluating the internal state of an immutable security
+property. The latter includes checking the roothash of a dm-verity
+protected device, determining whether dm-verity possesses a valid
+signature, assessing the digest of a fs-verity protected file, or
+determining whether fs-verity possesses a valid built-in signature. This
+nuanced approach to policy enforcement enables a highly secure and
+customizable system defense mechanism, tailored to specific security
+requirements and trust models.
+
+To enable IPE, ensure that ``CONFIG_SECURITY_IPE`` (under
+:menuselection:`Security -> Integrity Policy Enforcement (IPE)`) config
+option is enabled.
+
+Use Cases
+---------
+
+IPE works best in fixed-function devices: devices in which their purpose
+is clearly defined and not supposed to be changed (e.g. network firewall
+device in a data center, an IoT device, etcetera), where all software and
+configuration is built and provisioned by the system owner.
+
+IPE is a long-way off for use in general-purpose computing: the Linux
+community as a whole tends to follow a decentralized trust model (known as
+the web of trust), which IPE has no support for it yet. Instead, IPE
+supports PKI (public key infrastructure), which generally designates a
+set of trusted entities that provide a measure of absolute trust.
+
+Additionally, while most packages are signed today, the files inside
+the packages (for instance, the executables), tend to be unsigned. This
+makes it difficult to utilize IPE in systems where a package manager is
+expected to be functional, without major changes to the package manager
+and ecosystem behind it.
+
+The digest_cache LSM [#digest_cache_lsm]_ is a system that when combined with IPE,
+could be used to enable and support general-purpose computing use cases.
+
+Known Limitations
+-----------------
+
+IPE cannot verify the integrity of anonymous executable memory, such as
+the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd code.
+Unfortunately, as this is dynamically generated code, there is no way
+for IPE to ensure the integrity of this code to form a trust basis.
+
+IPE cannot verify the integrity of programs written in interpreted
+languages when these scripts are invoked by passing these program files
+to the interpreter. This is because the way interpreters execute these
+files; the scripts themselves are not evaluated as executable code
+through one of IPE's hooks, but they are merely text files that are read
+(as opposed to compiled executables). However, with the introduction of the
+``AT_EXECVE_CHECK`` flag (:doc:`AT_EXECVE_CHECK </userspace-api/check_exec>`),
+interpreters can use it to signal the kernel that a script file will be executed,
+and request the kernel to perform LSM security checks on it.
+
+IPE's EXECUTE operation enforcement differs between compiled executables and
+interpreted scripts: For compiled executables, enforcement is triggered
+automatically by the kernel during ``execve()``, ``execveat()``, ``mmap()``
+and ``mprotect()`` syscalls when loading executable content. For interpreted
+scripts, enforcement requires explicit interpreter integration using
+``execveat()`` with ``AT_EXECVE_CHECK`` flag. Unlike exec syscalls that IPE
+intercepts during the execution process, this mechanism needs the interpreter
+to take the initiative, and existing interpreters won't be automatically
+supported unless the signal call is added.
+
+Threat Model
+------------
+
+IPE specifically targets the risk of tampering with user-space executable
+code after the kernel has initially booted, including the kernel modules
+loaded from userspace via ``modprobe`` or ``insmod``.
+
+To illustrate, consider a scenario where an untrusted binary, possibly
+malicious, is downloaded along with all necessary dependencies, including a
+loader and libc. The primary function of IPE in this context is to prevent
+the execution of such binaries and their dependencies.
+
+IPE achieves this by verifying the integrity and authenticity of all
+executable code before allowing them to run. It conducts a thorough
+check to ensure that the code's integrity is intact and that they match an
+authorized reference value (digest, signature, etc) as per the defined
+policy. If a binary does not pass this verification process, either
+because its integrity has been compromised or it does not meet the
+authorization criteria, IPE will deny its execution. Additionally, IPE
+generates audit logs which may be utilized to detect and analyze failures
+resulting from policy violation.
+
+Tampering threat scenarios include modification or replacement of
+executable code by a range of actors including:
+
+- Actors with physical access to the hardware
+- Actors with local network access to the system
+- Actors with access to the deployment system
+- Compromised internal systems under external control
+- Malicious end users of the system
+- Compromised end users of the system
+- Remote (external) compromise of the system
+
+IPE does not mitigate threats arising from malicious but authorized
+developers (with access to a signing certificate), or compromised
+developer tools used by them (i.e. return-oriented programming attacks).
+Additionally, IPE draws hard security boundary between userspace and
+kernelspace. As a result, kernel-level exploits are considered outside
+the scope of IPE and mitigation is left to other mechanisms.
+
+Policy
+------
+
+IPE policy is a plain-text [#devdoc]_ policy composed of multiple statements
+over several lines. There is one required line, at the top of the
+policy, indicating the policy name, and the policy version, for
+instance::
+
+ policy_name=Ex_Policy policy_version=0.0.0
+
+The policy name is a unique key identifying this policy in a human
+readable name. This is used to create nodes under securityfs as well as
+uniquely identify policies to deploy new policies vs update existing
+policies.
+
+The policy version indicates the current version of the policy (NOT the
+policy syntax version). This is used to prevent rollback of policy to
+potentially insecure previous versions of the policy.
+
+The next portion of IPE policy are rules. Rules are formed by key=value
+pairs, known as properties. IPE rules require two properties: ``action``,
+which determines what IPE does when it encounters a match against the
+rule, and ``op``, which determines when the rule should be evaluated.
+The ordering is significant, a rule must start with ``op``, and end with
+``action``. Thus, a minimal rule is::
+
+ op=EXECUTE action=ALLOW
+
+This example will allow any execution. Additional properties are used to
+assess immutable security properties about the files being evaluated.
+These properties are intended to be descriptions of systems within the
+kernel that can provide a measure of integrity verification, such that IPE
+can determine the trust of the resource based on the value of the property.
+
+Rules are evaluated top-to-bottom. As a result, any revocation rules,
+or denies should be placed early in the file to ensure that these rules
+are evaluated before a rule with ``action=ALLOW``.
+
+IPE policy supports comments. The character '#' will function as a
+comment, ignoring all characters to the right of '#' until the newline.
+
+The default behavior of IPE evaluations can also be expressed in policy,
+through the ``DEFAULT`` statement. This can be done at a global level,
+or a per-operation level::
+
+ # Global
+ DEFAULT action=ALLOW
+
+ # Operation Specific
+ DEFAULT op=EXECUTE action=ALLOW
+
+A default must be set for all known operations in IPE. If you want to
+preserve older policies being compatible with newer kernels that can introduce
+new operations, set a global default of ``ALLOW``, then override the
+defaults on a per-operation basis (as above).
+
+With configurable policy-based LSMs, there's several issues with
+enforcing the configurable policies at startup, around reading and
+parsing the policy:
+
+1. The kernel *should* not read files from userspace, so directly reading
+ the policy file is prohibited.
+2. The kernel command line has a character limit, and one kernel module
+ should not reserve the entire character limit for its own
+ configuration.
+3. There are various boot loaders in the kernel ecosystem, so handing
+ off a memory block would be costly to maintain.
+
+As a result, IPE has addressed this problem through a concept of a "boot
+policy". A boot policy is a minimal policy which is compiled into the
+kernel. This policy is intended to get the system to a state where
+userspace is set up and ready to receive commands, at which point a more
+complex policy can be deployed via securityfs. The boot policy can be
+specified via ``SECURITY_IPE_BOOT_POLICY`` config option, which accepts
+a path to a plain-text version of the IPE policy to apply. This policy
+will be compiled into the kernel. If not specified, IPE will be disabled
+until a policy is deployed and activated through securityfs.
+
+Deploying Policies
+~~~~~~~~~~~~~~~~~~
+
+Policies can be deployed from userspace through securityfs. These policies
+are signed through the PKCS#7 message format to enforce some level of
+authorization of the policies (prohibiting an attacker from gaining
+unconstrained root, and deploying an "allow all" policy). These
+policies must be signed by a certificate that chains to the
+``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 \
+ -in "$MY_POLICY" \
+ -signer "$MY_CERTIFICATE" \
+ -inkey "$MY_PRIVATE_KEY" \
+ -noattr \
+ -nodetach \
+ -nosmimecap \
+ -outform der \
+ -out "$MY_POLICY.p7b"
+
+Deploying the policies is done through securityfs, through the
+``new_policy`` node. To deploy a policy, simply cat the file into the
+securityfs node::
+
+ cat "$MY_POLICY.p7b" > /sys/kernel/security/ipe/new_policy
+
+Upon success, this will create one subdirectory under
+``/sys/kernel/security/ipe/policies/``. The subdirectory will be the
+``policy_name`` field of the policy deployed, so for the example above,
+the directory will be ``/sys/kernel/security/ipe/policies/Ex_Policy``.
+Within this directory, there will be seven files: ``pkcs7``, ``policy``,
+``name``, ``version``, ``active``, ``update``, and ``delete``.
+
+The ``pkcs7`` file is read-only. Reading it returns the raw PKCS#7 data
+that was provided to the kernel, representing the policy. If the policy being
+read is the boot policy, this will return ``ENOENT``, as it is not signed.
+
+The ``policy`` file is read only. Reading it returns the PKCS#7 inner
+content of the policy, which will be the plain text policy.
+
+The ``active`` file is used to set a policy as the currently active policy.
+This file is rw, and accepts a value of ``"1"`` to set the policy as active.
+Since only a single policy can be active at one time, all other policies
+will be marked inactive. The policy being marked active must have a policy
+version greater or equal to the currently-running version.
+
+The ``update`` file is used to update a policy that is already present
+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_names`` must match with the updated version and the existing
+version. Second the updated policy must have a policy version greater than
+the currently-running version. This is to prevent rollback attacks.
+
+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.
+On deletion, the securityfs node representing the policy will be removed.
+However, delete the current active policy is not allowed and will return
+an operation not permitted error.
+
+Similarly, writing to both ``update`` and ``new_policy`` could result in
+bad message(policy syntax error) or file exists error. The latter error happens
+when trying to deploy a policy with a ``policy_name`` while the kernel already
+has a deployed policy with the same ``policy_name``.
+
+Deploying a policy will *not* cause IPE to start enforcing the policy. IPE will
+only enforce the policy marked active. Note that only one policy can be active
+at a time.
+
+Once deployment is successful, the policy can be activated, by writing file
+``/sys/kernel/security/ipe/policies/$policy_name/active``.
+For example, the ``Ex_Policy`` can be activated by::
+
+ echo 1 > "/sys/kernel/security/ipe/policies/Ex_Policy/active"
+
+From above point on, ``Ex_Policy`` is now the enforced policy on the
+system.
+
+IPE also provides a way to delete policies. This can be done via the
+``delete`` securityfs node,
+``/sys/kernel/security/ipe/policies/$policy_name/delete``.
+Writing ``1`` to that file deletes the policy::
+
+ echo 1 > "/sys/kernel/security/ipe/policies/$policy_name/delete"
+
+There is only one requirement to delete a policy: the policy being deleted
+must be inactive.
+
+.. NOTE::
+
+ If a traditional MAC system is enabled (SELinux, apparmor, smack), all
+ writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
+
+Modes
+~~~~~
+
+IPE supports two modes of operation: permissive (similar to SELinux's
+permissive mode) and enforced. In permissive mode, all events are
+checked and policy violations are logged, but the policy is not really
+enforced. This allows users to test policies before enforcing them.
+
+The default mode is enforce, and can be changed via the kernel command
+line parameter ``ipe.enforce=(0|1)``, or the securityfs node
+``/sys/kernel/security/ipe/enforce``.
+
+.. NOTE::
+
+ If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera),
+ all writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
+
+Audit Events
+~~~~~~~~~~~~
+
+1420 AUDIT_IPE_ACCESS
+^^^^^^^^^^^^^^^^^^^^^
+Event Examples::
+
+ type=1420 audit(1653364370.067:61): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2241 comm="ld-linux.so" path="/deny/lib/libc.so.6" dev="sda2" ino=14549020 rule="DEFAULT action=DENY"
+ type=1300 audit(1653364370.067:61): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=7f1105a28000 a1=195000 a2=5 a3=812 items=0 ppid=2219 pid=2241 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ld-linux.so" exe="/tmp/ipe-test/lib/ld-linux.so" subj=unconfined key=(null)
+ type=1327 audit(1653364370.067:61): 707974686F6E3300746573742F6D61696E2E7079002D6E00
+
+ type=1420 audit(1653364735.161:64): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2472 comm="mmap_test" path=? dev=? ino=? rule="DEFAULT action=DENY"
+ type=1300 audit(1653364735.161:64): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=4 a3=21 items=0 ppid=2219 pid=2472 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mmap_test" exe="/root/overlake_test/upstream_test/vol_fsverity/bin/mmap_test" subj=unconfined key=(null)
+ type=1327 audit(1653364735.161:64): 707974686F6E3300746573742F6D61696E2E7079002D6E00
+
+This event indicates that IPE made an access control decision; the IPE
+specific record (1420) is always emitted in conjunction with a
+``AUDITSYSCALL`` record.
+
+Determining whether IPE is in permissive or enforced mode can be derived
+from ``success`` property and exit code of the ``AUDITSYSCALL`` record.
+
+
+Field descriptions:
+
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| Field | Value Type | Optional? | Description of Value |
++===========+============+===========+=================================================================================+
+| ipe_op | string | No | The IPE operation name associated with the log |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| ipe_hook | string | No | The name of the LSM hook that triggered the IPE event |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| enforcing | integer | No | The current IPE enforcing state 1 is in enforcing mode, 0 is in permissive mode |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| pid | integer | No | The pid of the process that triggered the IPE event. |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| comm | string | No | The command line program name of the process that triggered the IPE event |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| path | string | Yes | The absolute path to the evaluated file |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| ino | integer | Yes | The inode number of the evaluated file |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| dev | string | Yes | The device name of the evaluated file, e.g. vda |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+| rule | string | No | The matched policy rule |
++-----------+------------+-----------+---------------------------------------------------------------------------------+
+
+1421 AUDIT_IPE_CONFIG_CHANGE
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Event Example::
+
+ type=1421 audit(1653425583.136:54): old_active_pol_name="Allow_All" old_active_pol_version=0.0.0 old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 new_active_pol_name="boot_verified" new_active_pol_version=0.0.0 new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1
+ type=1300 audit(1653425583.136:54): SYSCALL arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=5596fcae1fb0 a2=2 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
+ type=1327 audit(1653425583.136:54): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2
+
+This event indicates that IPE switched the active poliy from one to another
+along with the version and the hash digest of the two policies.
+Note IPE can only have one policy active at a time, all access decision
+evaluation is based on the current active policy.
+The normal procedure to deploy a new policy is loading the policy to deploy
+into the kernel first, then switch the active policy to it.
+
+This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
+
+Field descriptions:
+
++------------------------+------------+-----------+---------------------------------------------------+
+| Field | Value Type | Optional? | Description of Value |
++========================+============+===========+===================================================+
+| old_active_pol_name | string | Yes | The name of previous active policy |
++------------------------+------------+-----------+---------------------------------------------------+
+| old_active_pol_version | string | Yes | The version of previous active policy |
++------------------------+------------+-----------+---------------------------------------------------+
+| old_policy_digest | string | Yes | The hash of previous active policy |
++------------------------+------------+-----------+---------------------------------------------------+
+| new_active_pol_name | string | No | The name of current active policy |
++------------------------+------------+-----------+---------------------------------------------------+
+| new_active_pol_version | string | No | The version of current active policy |
++------------------------+------------+-----------+---------------------------------------------------+
+| new_policy_digest | string | No | The hash of current active policy |
++------------------------+------------+-----------+---------------------------------------------------+
+| auid | integer | No | The login user ID |
++------------------------+------------+-----------+---------------------------------------------------+
+| ses | integer | No | The login session ID |
++------------------------+------------+-----------+---------------------------------------------------+
+| lsm | string | No | The lsm name associated with the event |
++------------------------+------------+-----------+---------------------------------------------------+
+| res | integer | No | The result of the audited operation(success/fail) |
++------------------------+------------+-----------+---------------------------------------------------+
+
+1422 AUDIT_IPE_POLICY_LOAD
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Event Example::
+
+ type=1422 audit(1653425529.927:53): policy_name="boot_verified" policy_version=0.0.0 policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1 errno=0
+ type=1300 audit(1653425529.927:53): arch=c000003e syscall=1 success=yes exit=2567 a0=3 a1=5596fcae1fb0 a2=a07 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
+ type=1327 audit(1653425529.927:53): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2E
+
+This record indicates a new policy has been loaded into the kernel with the policy name, policy version and policy hash.
+
+This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
+
+Field descriptions:
+
++----------------+------------+-----------+-------------------------------------------------------------+
+| Field | Value Type | Optional? | Description of Value |
++================+============+===========+=============================================================+
+| policy_name | string | Yes | The policy_name |
++----------------+------------+-----------+-------------------------------------------------------------+
+| policy_version | string | Yes | The policy_version |
++----------------+------------+-----------+-------------------------------------------------------------+
+| policy_digest | string | Yes | The policy hash |
++----------------+------------+-----------+-------------------------------------------------------------+
+| auid | integer | No | The login user ID |
++----------------+------------+-----------+-------------------------------------------------------------+
+| ses | integer | No | The login session ID |
++----------------+------------+-----------+-------------------------------------------------------------+
+| lsm | string | No | The lsm name associated with the event |
++----------------+------------+-----------+-------------------------------------------------------------+
+| res | integer | No | The result of the audited operation(success/fail) |
++----------------+------------+-----------+-------------------------------------------------------------+
+| errno | integer | No | Error code from policy loading operations (see table below) |
++----------------+------------+-----------+-------------------------------------------------------------+
+
+Policy error codes (errno):
+
+The following table lists the error codes that may appear in the errno field while loading or updating the policy:
+
++----------------+--------------------------------------------------------+
+| Error Code | Description |
++================+========================================================+
+| 0 | Success |
++----------------+--------------------------------------------------------+
+| -EPERM | Insufficient permission |
++----------------+--------------------------------------------------------+
+| -EEXIST | Same name policy already deployed |
++----------------+--------------------------------------------------------+
+| -EBADMSG | Policy is invalid |
++----------------+--------------------------------------------------------+
+| -ENOMEM | Out of memory (OOM) |
++----------------+--------------------------------------------------------+
+| -ERANGE | Policy version number overflow |
++----------------+--------------------------------------------------------+
+| -EINVAL | Policy version parsing error |
++----------------+--------------------------------------------------------+
+| -ENOKEY | Key used to sign the IPE policy not found in keyring |
++----------------+--------------------------------------------------------+
+| -EKEYREJECTED | Policy signature verification failed |
++----------------+--------------------------------------------------------+
+| -ESTALE | Attempting to update an IPE policy with older version |
++----------------+--------------------------------------------------------+
+| -ENOENT | Policy was deleted while updating |
++----------------+--------------------------------------------------------+
+
+1404 AUDIT_MAC_STATUS
+^^^^^^^^^^^^^^^^^^^^^
+
+Event Examples::
+
+ type=1404 audit(1653425689.008:55): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
+ type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
+ type=1327 audit(1653425689.008:55): proctitle="-bash"
+
+ type=1404 audit(1653425689.008:55): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
+ type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
+ type=1327 audit(1653425689.008:55): proctitle="-bash"
+
+This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
+
+Field descriptions:
+
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| Field | Value Type | Optional? | Description of Value |
++===============+============+===========+=================================================================================================+
+| enforcing | integer | No | The enforcing state IPE is being switched to, 1 is in enforcing mode, 0 is in permissive mode |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| old_enforcing | integer | No | The enforcing state IPE is being switched from, 1 is in enforcing mode, 0 is in permissive mode |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| auid | integer | No | The login user ID |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| ses | integer | No | The login session ID |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| enabled | integer | No | The new TTY audit enabled setting |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| old-enabled | integer | No | The old TTY audit enabled setting |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| lsm | string | No | The lsm name associated with the event |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+| res | integer | No | The result of the audited operation(success/fail) |
++---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
+
+
+Success Auditing
+^^^^^^^^^^^^^^^^
+
+IPE supports success auditing. When enabled, all events that pass IPE
+policy and are not blocked will emit an audit event. This is disabled by
+default, and can be enabled via the kernel command line
+``ipe.success_audit=(0|1)`` or
+``/sys/kernel/security/ipe/success_audit`` securityfs file.
+
+This is *very* noisy, as IPE will check every userspace binary on the
+system, but is useful for debugging policies.
+
+.. NOTE::
+
+ If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera),
+ all writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
+
+Properties
+----------
+
+As explained above, IPE properties are ``key=value`` pairs expressed in IPE
+policy. Two properties are built-into the policy parser: 'op' and 'action'.
+The other properties are used to restrict immutable security properties
+about the files being evaluated. Currently those properties are:
+'``boot_verified``', '``dmverity_signature``', '``dmverity_roothash``',
+'``fsverity_signature``', '``fsverity_digest``'. A description of all
+properties supported by IPE are listed below:
+
+op
+~~
+
+Indicates the operation for a rule to apply to. Must be in every rule,
+as the first token. IPE supports the following operations:
+
+ ``EXECUTE``
+
+ Pertains to any file attempting to be executed, or loaded as an
+ executable.
+
+ ``FIRMWARE``:
+
+ Pertains to firmware being loaded via the firmware_class interface.
+ This covers both the preallocated buffer and the firmware file
+ itself.
+
+ ``KMODULE``:
+
+ Pertains to loading kernel modules via ``modprobe`` or ``insmod``.
+
+ ``KEXEC_IMAGE``:
+
+ Pertains to kernel images loading via ``kexec``.
+
+ ``KEXEC_INITRAMFS``
+
+ Pertains to initrd images loading via ``kexec --initrd``.
+
+ ``POLICY``:
+
+ Controls loading policies via reading a kernel-space initiated read.
+
+ An example of such is loading IMA policies by writing the path
+ to the policy file to ``$securityfs/ima/policy``
+
+ ``X509_CERT``:
+
+ Controls loading IMA certificates through the Kconfigs,
+ ``CONFIG_IMA_X509_PATH`` and ``CONFIG_EVM_X509_PATH``.
+
+action
+~~~~~~
+
+ Determines what IPE should do when a rule matches. Must be in every
+ rule, as the final clause. Can be one of:
+
+ ``ALLOW``:
+
+ If the rule matches, explicitly allow access to the resource to proceed
+ without executing any more rules.
+
+ ``DENY``:
+
+ If the rule matches, explicitly prohibit access to the resource to
+ proceed without executing any more rules.
+
+boot_verified
+~~~~~~~~~~~~~
+
+ This property can be utilized for authorization of files from initramfs.
+ The format of this property is::
+
+ boot_verified=(TRUE|FALSE)
+
+
+ .. WARNING::
+
+ This property will trust files from initramfs(rootfs). It should
+ only be used during early booting stage. Before mounting the real
+ rootfs on top of the initramfs, initramfs script will recursively
+ remove all files and directories on the initramfs. This is typically
+ implemented by using switch_root(8) [#switch_root]_. Therefore the
+ initramfs will be empty and not accessible after the real
+ rootfs takes over. It is advised to switch to a different policy
+ that doesn't rely on the property after this point.
+ This ensures that the trust policies remain relevant and effective
+ throughout the system's operation.
+
+dmverity_roothash
+~~~~~~~~~~~~~~~~~
+
+ This property can be utilized for authorization or revocation of
+ specific dm-verity volumes, identified via their root hashes. It has a
+ dependency on the DM_VERITY module. This property is controlled by
+ the ``IPE_PROP_DM_VERITY`` config option, it will be automatically
+ selected when ``SECURITY_IPE`` and ``DM_VERITY`` are all enabled.
+ The format of this property is::
+
+ dmverity_roothash=DigestName:HexadecimalString
+
+ The supported DigestNames for dmverity_roothash are [#dmveritydigests]_
+
+ + blake2b-512
+ + blake2s-256
+ + sha256
+ + sha384
+ + sha512
+ + sha3-224
+ + sha3-256
+ + sha3-384
+ + sha3-512
+ + sm3
+ + rmd160
+
+dmverity_signature
+~~~~~~~~~~~~~~~~~~
+
+ This property can be utilized for authorization of all dm-verity
+ volumes that have a signed roothash that validated by a keyring
+ specified by dm-verity's configuration, either the system trusted
+ keyring, or the secondary keyring. It depends on
+ ``DM_VERITY_VERIFY_ROOTHASH_SIG`` config option and is controlled by
+ the ``IPE_PROP_DM_VERITY_SIGNATURE`` config option, it will be automatically
+ selected when ``SECURITY_IPE``, ``DM_VERITY`` and
+ ``DM_VERITY_VERIFY_ROOTHASH_SIG`` are all enabled.
+ The format of this property is::
+
+ dmverity_signature=(TRUE|FALSE)
+
+fsverity_digest
+~~~~~~~~~~~~~~~
+
+ This property can be utilized for authorization of specific fsverity
+ enabled files, identified via their fsverity digests.
+ It depends on ``FS_VERITY`` config option and is controlled by
+ the ``IPE_PROP_FS_VERITY`` config option, it will be automatically
+ selected when ``SECURITY_IPE`` and ``FS_VERITY`` are all enabled.
+ The format of this property is::
+
+ fsverity_digest=DigestName:HexadecimalString
+
+ The supported DigestNames for fsverity_digest are [#fsveritydigest]_
+
+ + sha256
+ + sha512
+
+fsverity_signature
+~~~~~~~~~~~~~~~~~~
+
+ This property is used to authorize all fs-verity enabled files that have
+ been verified by fs-verity's built-in signature mechanism. The signature
+ verification relies on a key stored within the ".fs-verity" keyring. It
+ depends on ``FS_VERITY_BUILTIN_SIGNATURES`` config option and
+ it is controlled by the ``IPE_PROP_FS_VERITY`` config option,
+ it will be automatically selected when ``SECURITY_IPE``, ``FS_VERITY``
+ and ``FS_VERITY_BUILTIN_SIGNATURES`` are all enabled.
+ The format of this property is::
+
+ fsverity_signature=(TRUE|FALSE)
+
+Policy Examples
+---------------
+
+Allow all
+~~~~~~~~~
+
+::
+
+ policy_name=Allow_All policy_version=0.0.0
+ DEFAULT action=ALLOW
+
+Allow only initramfs
+~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ policy_name=Allow_Initramfs policy_version=0.0.0
+ DEFAULT action=DENY
+
+ op=EXECUTE boot_verified=TRUE action=ALLOW
+
+Allow any signed and validated dm-verity volume and the initramfs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ policy_name=Allow_Signed_DMV_And_Initramfs policy_version=0.0.0
+ DEFAULT action=DENY
+
+ op=EXECUTE boot_verified=TRUE action=ALLOW
+ op=EXECUTE dmverity_signature=TRUE action=ALLOW
+
+Prohibit execution from a specific dm-verity volume
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ policy_name=Deny_DMV_By_Roothash policy_version=0.0.0
+ DEFAULT action=DENY
+
+ op=EXECUTE dmverity_roothash=sha256:cd2c5bae7c6c579edaae4353049d58eb5f2e8be0244bf05345bc8e5ed257baff action=DENY
+
+ op=EXECUTE boot_verified=TRUE action=ALLOW
+ op=EXECUTE dmverity_signature=TRUE action=ALLOW
+
+Allow only a specific dm-verity volume
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ policy_name=Allow_DMV_By_Roothash policy_version=0.0.0
+ DEFAULT action=DENY
+
+ op=EXECUTE dmverity_roothash=sha256:401fcec5944823ae12f62726e8184407a5fa9599783f030dec146938 action=ALLOW
+
+Allow any fs-verity file with a valid built-in signature
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ policy_name=Allow_Signed_And_Validated_FSVerity policy_version=0.0.0
+ DEFAULT action=DENY
+
+ op=EXECUTE fsverity_signature=TRUE action=ALLOW
+
+Allow execution of a specific fs-verity file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ policy_name=ALLOW_FSV_By_Digest policy_version=0.0.0
+ DEFAULT action=DENY
+
+ op=EXECUTE fsverity_digest=sha256:fd88f2b8824e197f850bf4c5109bea5cf0ee38104f710843bb72da796ba5af9e action=ALLOW
+
+Additional Information
+----------------------
+
+- `Github Repository <https://github.com/microsoft/ipe>`_
+- :doc:`Developer and design docs for IPE </security/ipe>`
+
+FAQ
+---
+
+Q:
+ What's the difference between other LSMs which provide a measure of
+ trust-based access control?
+
+A:
+
+ In general, there's two other LSMs that can provide similar functionality:
+ IMA, and Loadpin.
+
+ IMA and IPE are functionally very similar. The significant difference between
+ the two is the policy. [#devdoc]_
+
+ Loadpin and IPE differ fairly dramatically, as Loadpin only covers the IPE's
+ kernel read operations, whereas IPE is capable of controlling execution
+ on top of kernel read. The trust model is also different; Loadpin roots its
+ trust in the initial super-block, whereas trust in IPE is stemmed from kernel
+ itself (via ``SYSTEM_TRUSTED_KEYS``).
+
+-----------
+
+.. [#digest_cache_lsm] https://lore.kernel.org/lkml/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
+
+.. [#devdoc] Please see :doc:`the design docs </security/ipe>` for more on
+ this topic.
+
+.. [#switch_root] https://man7.org/linux/man-pages/man8/switch_root.8.html
+
+.. [#dmveritydigests] These hash algorithms are based on values accepted by
+ the Linux crypto API; IPE does not impose any
+ restrictions on the digest algorithm itself;
+ thus, this list may be out of date.
+
+.. [#fsveritydigest] These hash algorithms are based on values accepted by the
+ kernel's fsverity support; IPE does not impose any
+ restrictions on the digest algorithm itself;
+ thus, this list may be out of date.
diff --git a/Documentation/admin-guide/LSM/landlock.rst b/Documentation/admin-guide/LSM/landlock.rst
new file mode 100644
index 000000000000..9e61607def08
--- /dev/null
+++ b/Documentation/admin-guide/LSM/landlock.rst
@@ -0,0 +1,158 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. Copyright © 2025 Microsoft Corporation
+
+================================
+Landlock: system-wide management
+================================
+
+:Author: Mickaël Salaün
+:Date: March 2025
+
+Landlock can leverage the audit framework to log events.
+
+User space documentation can be found here:
+Documentation/userspace-api/landlock.rst.
+
+Audit
+=====
+
+Denied access requests are logged by default for a sandboxed program if `audit`
+is enabled. This default behavior can be changed with the
+sys_landlock_restrict_self() flags (cf.
+Documentation/userspace-api/landlock.rst). Landlock logs can also be masked
+thanks to audit rules. Landlock can generate 2 audit record types.
+
+Record types
+------------
+
+AUDIT_LANDLOCK_ACCESS
+ This record type identifies a denied access request to a kernel resource.
+ The ``domain`` field indicates the ID of the domain that blocked the
+ request. The ``blockers`` field indicates the cause(s) of this denial
+ (separated by a comma), and the following fields identify the kernel object
+ (similar to SELinux). There may be more than one of this record type per
+ audit event.
+
+ Example with a file link request generating two records in the same event::
+
+ domain=195ba459b blockers=fs.refer path="/usr/bin" dev="vda2" ino=351
+ domain=195ba459b blockers=fs.make_reg,fs.refer path="/usr/local" dev="vda2" ino=365
+
+AUDIT_LANDLOCK_DOMAIN
+ This record type describes the status of a Landlock domain. The ``status``
+ field can be either ``allocated`` or ``deallocated``.
+
+ The ``allocated`` status is part of the same audit event and follows
+ the first logged ``AUDIT_LANDLOCK_ACCESS`` record of a domain. It identifies
+ Landlock domain information at the time of the sys_landlock_restrict_self()
+ call with the following fields:
+
+ - the ``domain`` ID
+ - the enforcement ``mode``
+ - the domain creator's ``pid``
+ - the domain creator's ``uid``
+ - the domain creator's executable path (``exe``)
+ - the domain creator's command line (``comm``)
+
+ Example::
+
+ domain=195ba459b status=allocated mode=enforcing pid=300 uid=0 exe="/root/sandboxer" comm="sandboxer"
+
+ The ``deallocated`` status is an event on its own and it identifies a
+ Landlock domain release. After such event, it is guarantee that the
+ related domain ID will never be reused during the lifetime of the system.
+ The ``domain`` field indicates the ID of the domain which is released, and
+ the ``denials`` field indicates the total number of denied access request,
+ which might not have been logged according to the audit rules and
+ sys_landlock_restrict_self()'s flags.
+
+ Example::
+
+ domain=195ba459b status=deallocated denials=3
+
+
+Event samples
+--------------
+
+Here are two examples of log events (see serial numbers).
+
+In this example a sandboxed program (``kill``) tries to send a signal to the
+init process, which is denied because of the signal scoping restriction
+(``LL_SCOPED=s``)::
+
+ $ LL_FS_RO=/ LL_FS_RW=/ LL_SCOPED=s LL_FORCE_LOG=1 ./sandboxer kill 1
+
+This command generates two events, each identified with a unique serial
+number following a timestamp (``msg=audit(1729738800.268:30)``). The first
+event (serial ``30``) contains 4 records. The first record
+(``type=LANDLOCK_ACCESS``) shows an access denied by the domain `1a6fdc66f`.
+The cause of this denial is signal scopping restriction
+(``blockers=scope.signal``). The process that would have receive this signal
+is the init process (``opid=1 ocomm="systemd"``).
+
+The second record (``type=LANDLOCK_DOMAIN``) describes (``status=allocated``)
+domain `1a6fdc66f`. This domain was created by process ``286`` executing the
+``/root/sandboxer`` program launched by the root user.
+
+The third record (``type=SYSCALL``) describes the syscall, its provided
+arguments, its result (``success=no exit=-1``), and the process that called it.
+
+The fourth record (``type=PROCTITLE``) shows the command's name as an
+hexadecimal value. This can be translated with ``python -c
+'print(bytes.fromhex("6B696C6C0031"))'``.
+
+Finally, the last record (``type=LANDLOCK_DOMAIN``) is also the only one from
+the second event (serial ``31``). It is not tied to a direct user space action
+but an asynchronous one to free resources tied to a Landlock domain
+(``status=deallocated``). This can be useful to know that the following logs
+will not concern the domain ``1a6fdc66f`` anymore. This record also summarize
+the number of requests this domain denied (``denials=1``), whether they were
+logged or not.
+
+.. code-block::
+
+ type=LANDLOCK_ACCESS msg=audit(1729738800.268:30): domain=1a6fdc66f blockers=scope.signal opid=1 ocomm="systemd"
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.268:30): domain=1a6fdc66f status=allocated mode=enforcing pid=286 uid=0 exe="/root/sandboxer" comm="sandboxer"
+ type=SYSCALL msg=audit(1729738800.268:30): arch=c000003e syscall=62 success=no exit=-1 [..] ppid=272 pid=286 auid=0 uid=0 gid=0 [...] comm="kill" [...]
+ type=PROCTITLE msg=audit(1729738800.268:30): proctitle=6B696C6C0031
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.324:31): domain=1a6fdc66f status=deallocated denials=1
+
+Here is another example showcasing filesystem access control::
+
+ $ LL_FS_RO=/ LL_FS_RW=/tmp LL_FORCE_LOG=1 ./sandboxer sh -c "echo > /etc/passwd"
+
+The related audit logs contains 8 records from 3 different events (serials 33,
+34 and 35) created by the same domain `1a6fdc679`::
+
+ type=LANDLOCK_ACCESS msg=audit(1729738800.221:33): domain=1a6fdc679 blockers=fs.write_file path="/dev/tty" dev="devtmpfs" ino=9
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.221:33): domain=1a6fdc679 status=allocated mode=enforcing pid=289 uid=0 exe="/root/sandboxer" comm="sandboxer"
+ type=SYSCALL msg=audit(1729738800.221:33): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]
+ type=PROCTITLE msg=audit(1729738800.221:33): proctitle=7368002D63006563686F203E202F6574632F706173737764
+ type=LANDLOCK_ACCESS msg=audit(1729738800.221:34): domain=1a6fdc679 blockers=fs.write_file path="/etc/passwd" dev="vda2" ino=143821
+ type=SYSCALL msg=audit(1729738800.221:34): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]
+ type=PROCTITLE msg=audit(1729738800.221:34): proctitle=7368002D63006563686F203E202F6574632F706173737764
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.261:35): domain=1a6fdc679 status=deallocated denials=2
+
+
+Event filtering
+---------------
+
+If you get spammed with audit logs related to Landlock, this is either an
+attack attempt or a bug in the security policy. We can put in place some
+filters to limit noise with two complementary ways:
+
+- with sys_landlock_restrict_self()'s flags if we can fix the sandboxed
+ programs,
+- or with audit rules (see :manpage:`auditctl(8)`).
+
+Additional documentation
+========================
+
+* `Linux Audit Documentation`_
+* Documentation/userspace-api/landlock.rst
+* Documentation/security/landlock.rst
+* https://landlock.io
+
+.. Links
+.. _Linux Audit Documentation:
+ https://github.com/linux-audit/audit-documentation/wiki
diff --git a/Documentation/admin-guide/LSM/tomoyo.rst b/Documentation/admin-guide/LSM/tomoyo.rst
index 4bc9c2b4da6f..bdb2c2e2a1b2 100644
--- a/Documentation/admin-guide/LSM/tomoyo.rst
+++ b/Documentation/admin-guide/LSM/tomoyo.rst
@@ -9,8 +9,8 @@ TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel.
LiveCD-based tutorials are available at
-http://tomoyo.sourceforge.jp/1.8/ubuntu12.04-live.html
-http://tomoyo.sourceforge.jp/1.8/centos6-live.html
+https://tomoyo.sourceforge.net/1.8/ubuntu12.04-live.html
+https://tomoyo.sourceforge.net/1.8/centos6-live.html
Though these tutorials use non-LSM version of TOMOYO, they are useful for you
to know what TOMOYO is.
@@ -21,45 +21,32 @@ How to enable TOMOYO?
Build the kernel with ``CONFIG_SECURITY_TOMOYO=y`` and pass ``security=tomoyo`` on
kernel's command line.
-Please see http://tomoyo.osdn.jp/2.5/ for details.
+Please see https://tomoyo.sourceforge.net/2.6/ for details.
Where is documentation?
=======================
User <-> Kernel interface documentation is available at
-https://tomoyo.osdn.jp/2.5/policy-specification/index.html .
+https://tomoyo.sourceforge.net/2.6/policy-specification/index.html .
Materials we prepared for seminars and symposiums are available at
-https://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 .
+https://sourceforge.net/projects/tomoyo/files/docs/ .
Below lists are chosen from three aspects.
What is TOMOYO?
TOMOYO Linux Overview
- https://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf
+ https://sourceforge.net/projects/tomoyo/files/docs/lca2009-takeda.pdf
TOMOYO Linux: pragmatic and manageable security for Linux
- https://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf
+ https://sourceforge.net/projects/tomoyo/files/docs/freedomhectaipei-tomoyo.pdf
TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box
- https://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf
+ https://sourceforge.net/projects/tomoyo/files/docs/PacSec2007-en-no-demo.pdf
What can TOMOYO do?
Deep inside TOMOYO Linux
- https://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf
+ https://sourceforge.net/projects/tomoyo/files/docs/lca2009-kumaneko.pdf
The role of "pathname based access control" in security.
- https://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf
+ https://sourceforge.net/projects/tomoyo/files/docs/lfj2008-bof.pdf
History of TOMOYO?
Realities of Mainlining
- https://osdn.jp/projects/tomoyo/docs/lfj2008.pdf
-
-What is future plan?
-====================
-
-We believe that inode based security and name based security are complementary
-and both should be used together. But unfortunately, so far, we cannot enable
-multiple LSM modules at the same time. We feel sorry that you have to give up
-SELinux/SMACK/AppArmor etc. when you want to use TOMOYO.
-
-We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM
-version of TOMOYO, available at http://tomoyo.osdn.jp/1.8/ .
-LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning
-to port non-LSM version's functionalities to LSM versions.
+ https://sourceforge.net/projects/tomoyo/files/docs/lfj2008.pdf
diff --git a/Documentation/admin-guide/RAS/address-translation.rst b/Documentation/admin-guide/RAS/address-translation.rst
new file mode 100644
index 000000000000..f0ca17b43cd3
--- /dev/null
+++ b/Documentation/admin-guide/RAS/address-translation.rst
@@ -0,0 +1,24 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Address translation
+===================
+
+x86 AMD
+-------
+
+Zen-based AMD systems include a Data Fabric that manages the layout of
+physical memory. Devices attached to the Fabric, like memory controllers,
+I/O, etc., may not have a complete view of the system physical memory map.
+These devices may provide a "normalized", i.e. device physical, address
+when reporting memory errors. Normalized addresses must be translated to
+a system physical address for the kernel to action on the memory.
+
+AMD Address Translation Library (CONFIG_AMD_ATL) provides translation for
+this case.
+
+Glossary of acronyms used in address translation for Zen-based systems
+
+* CCM = Cache Coherent Moderator
+* COD = Cluster-on-Die
+* COH_ST = Coherent Station
+* DF = Data Fabric
diff --git a/Documentation/admin-guide/RAS/error-decoding.rst b/Documentation/admin-guide/RAS/error-decoding.rst
new file mode 100644
index 000000000000..26a72f3fe5de
--- /dev/null
+++ b/Documentation/admin-guide/RAS/error-decoding.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Error decoding
+==============
+
+x86
+---
+
+Error decoding on AMD systems should be done using the rasdaemon tool:
+https://github.com/mchehab/rasdaemon/
+
+While the daemon is running, it would automatically log and decode
+errors. If not, one can still decode such errors by supplying the
+hardware information from the error::
+
+ $ rasdaemon -p --status <STATUS> --ipid <IPID> --smca
+
+Also, the user can pass particular family and model to decode the error
+string::
+
+ $ rasdaemon -p --status <STATUS> --ipid <IPID> --smca --family <CPU Family> --model <CPU Model> --bank <BANK_NUM>
diff --git a/Documentation/admin-guide/RAS/index.rst b/Documentation/admin-guide/RAS/index.rst
new file mode 100644
index 000000000000..f4087040a7c0
--- /dev/null
+++ b/Documentation/admin-guide/RAS/index.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. toctree::
+ :maxdepth: 2
+
+ main
+ error-decoding
+ address-translation
diff --git a/Documentation/admin-guide/RAS/main.rst b/Documentation/admin-guide/RAS/main.rst
new file mode 100644
index 000000000000..5a45db32c49b
--- /dev/null
+++ b/Documentation/admin-guide/RAS/main.rst
@@ -0,0 +1,1087 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+==================================================
+Reliability, Availability and Serviceability (RAS)
+==================================================
+
+This documents different aspects of the RAS functionality present in the
+kernel.
+
+RAS concepts
+************
+
+Reliability, Availability and Serviceability (RAS) is a concept used on
+servers meant to measure their robustness.
+
+Reliability
+ is the probability that a system will produce correct outputs.
+
+ * Generally measured as Mean Time Between Failures (MTBF)
+ * Enhanced by features that help to avoid, detect and repair hardware faults
+
+Availability
+ is the probability that a system is operational at a given time
+
+ * Generally measured as a percentage of downtime per a period of time
+ * Often uses mechanisms to detect and correct hardware faults in
+ runtime;
+
+Serviceability (or maintainability)
+ is the simplicity and speed with which a system can be repaired or
+ maintained
+
+ * Generally measured on Mean Time Between Repair (MTBR)
+
+Improving RAS
+-------------
+
+In order to reduce systems downtime, a system should be capable of detecting
+hardware errors, and, when possible correcting them in runtime. It should
+also provide mechanisms to detect hardware degradation, in order to warn
+the system administrator to take the action of replacing a component before
+it causes data loss or system downtime.
+
+Among the monitoring measures, the most usual ones include:
+
+* CPU – detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory – add error correction logic (ECC) to detect and correct errors;
+* I/O – add CRC checksums for transferred data;
+* Storage – RAID, journal file systems, checksums,
+ Self-Monitoring, Analysis and Reporting Technology (SMART).
+
+By monitoring the number of occurrences of error detections, it is possible
+to identify if the probability of hardware errors is increasing, and, on such
+case, do a preventive maintenance to replace a degraded component while
+those errors are correctable.
+
+Types of errors
+---------------
+
+Most mechanisms used on modern systems use technologies like Hamming
+Codes that allow error correction when the number of errors on a bit packet
+is below a threshold. If the number of errors is above, those mechanisms
+can indicate with a high degree of confidence that an error happened, but
+they can't correct.
+
+Also, sometimes an error occur on a component that it is not used. For
+example, a part of the memory that it is not currently allocated.
+
+That defines some categories of errors:
+
+* **Correctable Error (CE)** - the error detection mechanism detected and
+ corrected the error. Such errors are usually not fatal, although some
+ Kernel mechanisms allow the system administrator to consider them as fatal.
+
+* **Uncorrected Error (UE)** - the amount of errors happened above the error
+ correction threshold, and the system was unable to auto-correct.
+
+* **Fatal Error** - when an UE error happens on a critical component of the
+ system (for example, a piece of the Kernel got corrupted by an UE), the
+ only reliable way to avoid data corruption is to hang or reboot the machine.
+
+* **Non-fatal Error** - when an UE error happens on an unused component,
+ like a CPU in power down state or an unused memory bank, the system may
+ still run, eventually replacing the affected hardware by a hot spare,
+ if available.
+
+ Also, when an error happens on a userspace process, it is also possible to
+ kill such process and let userspace restart it.
+
+The mechanism for handling non-fatal errors is usually complex and may
+require the help of some userspace application, in order to apply the
+policy desired by the system administrator.
+
+Identifying a bad hardware component
+------------------------------------
+
+Just detecting a hardware flaw is usually not enough, as the system needs
+to pinpoint to the minimal replaceable unit (MRU) that should be exchanged
+to make the hardware reliable again.
+
+So, it requires not only error logging facilities, but also mechanisms that
+will translate the error message to the silkscreen or component label for
+the MRU.
+
+Typically, it is very complex for memory, as modern CPUs interlace memory
+from different memory modules, in order to provide a better performance. The
+DMI BIOS usually have a list of memory module labels, with can be obtained
+using the ``dmidecode`` tool. For example, on a desktop machine, it shows::
+
+ Memory Device
+ Total Width: 64 bits
+ Data Width: 64 bits
+ Size: 16384 MB
+ Form Factor: SODIMM
+ Set: None
+ Locator: ChannelA-DIMM0
+ Bank Locator: BANK 0
+ Type: DDR4
+ Type Detail: Synchronous
+ Speed: 2133 MHz
+ Rank: 2
+ Configured Clock Speed: 2133 MHz
+
+On the above example, a DDR4 SO-DIMM memory module is located at the
+system's memory labeled as "BANK 0", as given by the *bank locator* field.
+Please notice that, on such system, the *total width* is equal to the
+*data width*. It means that such memory module doesn't have error
+detection/correction mechanisms.
+
+Unfortunately, not all systems use the same field to specify the memory
+bank. On this example, from an older server, ``dmidecode`` shows::
+
+ Memory Device
+ Array Handle: 0x1000
+ Error Information Handle: Not Provided
+ Total Width: 72 bits
+ Data Width: 64 bits
+ Size: 8192 MB
+ Form Factor: DIMM
+ Set: 1
+ Locator: DIMM_A1
+ Bank Locator: Not Specified
+ Type: DDR3
+ Type Detail: Synchronous Registered (Buffered)
+ Speed: 1600 MHz
+ Rank: 2
+ Configured Clock Speed: 1600 MHz
+
+There, the DDR3 RDIMM memory module is located at the system's memory labeled
+as "DIMM_A1", as given by the *locator* field. Please notice that this
+memory module has 64 bits of *data width* and 72 bits of *total width*. So,
+it has 8 extra bits to be used by error detection and correction mechanisms.
+Such kind of memory is called Error-correcting code memory (ECC memory).
+
+To make things even worse, it is not uncommon that systems with different
+labels on their system's board to use exactly the same BIOS, meaning that
+the labels provided by the BIOS won't match the real ones.
+
+ECC memory
+----------
+
+As mentioned in the previous section, ECC memory has extra bits to be
+used for error correction. In the above example, a memory module has
+64 bits of *data width*, and 72 bits of *total width*. The extra 8
+bits which are used for the error detection and correction mechanisms
+are referred to as the *syndrome*\ [#f1]_\ [#f2]_.
+
+So, when the cpu requests the memory controller to write a word with
+*data width*, the memory controller calculates the *syndrome* in real time,
+using Hamming code, or some other error correction code, like SECDED+,
+producing a code with *total width* size. Such code is then written
+on the memory modules.
+
+At read, the *total width* bits code is converted back, using the same
+ECC code used on write, producing a word with *data width* and a *syndrome*.
+The word with *data width* is sent to the CPU, even when errors happen.
+
+The memory controller also looks at the *syndrome* in order to check if
+there was an error, and if the ECC code was able to fix such error.
+If the error was corrected, a Corrected Error (CE) happened. If not, an
+Uncorrected Error (UE) happened.
+
+The information about the CE/UE errors is stored on some special registers
+at the memory controller and can be accessed by reading such registers,
+either by BIOS, by some special CPUs or by Linux EDAC driver. On x86 64
+bit CPUs, such errors can also be retrieved via the Machine Check
+Architecture (MCA)\ [#f3]_.
+
+.. [#f1] Please notice that several memory controllers allow operation on a
+ mode called "Lock-Step", where it groups two memory modules together,
+ doing 128-bit reads/writes. That gives 16 bits for error correction, with
+ significantly improves the error correction mechanism, at the expense
+ that, when an error happens, there's no way to know what memory module is
+ to blame. So, it has to blame both memory modules.
+
+.. [#f2] Some memory controllers also allow using memory in mirror mode.
+ On such mode, the same data is written to two memory modules. At read,
+ the system checks both memory modules, in order to check if both provide
+ identical data. On such configuration, when an error happens, there's no
+ way to know what memory module is to blame. So, it has to blame both
+ memory modules (or 4 memory modules, if the system is also on Lock-step
+ mode).
+
+.. [#f3] For more details about the Machine Check Architecture (MCA),
+ please read Documentation/arch/x86/x86_64/machinecheck.rst at the Kernel tree.
+
+EDAC - Error Detection And Correction
+*************************************
+
+.. note::
+
+ "bluesmoke" was the name for this device driver subsystem when it
+ was "out-of-tree" and maintained at http://bluesmoke.sourceforge.net.
+ That site is mostly archaic now and can be used only for historical
+ purposes.
+
+ When the subsystem was pushed upstream for the first time, on
+ Kernel 2.6.16, it was renamed to ``EDAC``.
+
+Purpose
+-------
+
+The ``edac`` kernel module's goal is to detect and report hardware errors
+that occur within the computer system running under linux.
+
+Memory
+------
+
+Memory Correctable Errors (CE) and Uncorrectable Errors (UE) are the
+primary errors being harvested. These types of errors are harvested by
+the ``edac_mc`` device.
+
+Detecting CE events, then harvesting those events and reporting them,
+**can** but must not necessarily be a predictor of future UE events. With
+CE events only, the system can and will continue to operate as no data
+has been damaged yet.
+
+However, preventive maintenance and proactive part replacement of memory
+modules exhibiting CEs can reduce the likelihood of the dreaded UE events
+and system panics.
+
+Other hardware elements
+-----------------------
+
+A new feature for EDAC, the ``edac_device`` class of device, was added in
+the 2.6.23 version of the kernel.
+
+This new device type allows for non-memory type of ECC hardware detectors
+to have their states harvested and presented to userspace via the sysfs
+interface.
+
+Some architectures have ECC detectors for L1, L2 and L3 caches,
+along with DMA engines, fabric switches, main data path switches,
+interconnections, and various other hardware data paths. If the hardware
+reports it, then an edac_device device probably can be constructed to
+harvest and present that to userspace.
+
+
+PCI bus scanning
+----------------
+
+In addition, PCI devices are scanned for PCI Bus Parity and SERR Errors
+in order to determine if errors are occurring during data transfers.
+
+The presence of PCI Parity errors must be examined with a grain of salt.
+There are several add-in adapters that do **not** follow the PCI specification
+with regards to Parity generation and reporting. The specification says
+the vendor should tie the parity status bits to 0 if they do not intend
+to generate parity. Some vendors do not do this, and thus the parity bit
+can "float" giving false positives.
+
+There is a PCI device attribute located in sysfs that is checked by
+the EDAC PCI scanning code. If that attribute is set, PCI parity/error
+scanning is skipped for that device. The attribute is::
+
+ broken_parity_status
+
+and is located in ``/sys/devices/pci<XXX>/0000:XX:YY.Z`` directories for
+PCI devices.
+
+
+Versioning
+----------
+
+EDAC is composed of a "core" module (``edac_core.ko``) and several Memory
+Controller (MC) driver modules. On a given system, the CORE is loaded
+and one MC driver will be loaded. Both the CORE and the MC driver (or
+``edac_device`` driver) have individual versions that reflect current
+release level of their respective modules.
+
+Thus, to "report" on what version a system is running, one must report
+both the CORE's and the MC driver's versions.
+
+
+Loading
+-------
+
+If ``edac`` was statically linked with the kernel then no loading
+is necessary. If ``edac`` was built as modules then simply modprobe
+the ``edac`` pieces that you need. You should be able to modprobe
+hardware-specific modules and have the dependencies load the necessary
+core modules.
+
+Example::
+
+ $ modprobe amd76x_edac
+
+loads both the ``amd76x_edac.ko`` memory controller module and the
+``edac_mc.ko`` core module.
+
+
+Sysfs interface
+---------------
+
+EDAC presents a ``sysfs`` interface for control and reporting purposes. It
+lives in the /sys/devices/system/edac directory.
+
+Within this directory there currently reside 2 components:
+
+ ======= ==============================
+ mc memory controller(s) system
+ pci PCI control and status system
+ ======= ==============================
+
+
+
+Memory Controller (mc) Model
+----------------------------
+
+Each ``mc`` device controls a set of memory modules [#f4]_. These modules
+are laid out in a Chip-Select Row (``csrowX``) and Channel table (``chX``).
+There can be multiple csrows and multiple channels.
+
+.. [#f4] Nowadays, the term DIMM (Dual In-line Memory Module) is widely
+ used to refer to a memory module, although there are other memory
+ packaging alternatives, like SO-DIMM, SIMM, etc. The UEFI
+ specification (Version 2.7) defines a memory module in the Common
+ Platform Error Record (CPER) section to be an SMBIOS Memory Device
+ (Type 17). Along this document, and inside the EDAC subsystem, the term
+ "dimm" is used for all memory modules, even when they use a
+ different kind of packaging.
+
+Memory controllers allow for several csrows, with 8 csrows being a
+typical value. Yet, the actual number of csrows depends on the layout of
+a given motherboard, memory controller and memory module characteristics.
+
+Dual channels allow for dual data length (e. g. 128 bits, on 64 bit systems)
+data transfers to/from the CPU from/to memory. Some newer chipsets allow
+for more than 2 channels, like Fully Buffered DIMMs (FB-DIMMs) memory
+controllers. The following example will assume 2 channels:
+
+ +------------+-----------------------+
+ | CS Rows | Channels |
+ +------------+-----------+-----------+
+ | | ``ch0`` | ``ch1`` |
+ +============+===========+===========+
+ | |**DIMM_A0**|**DIMM_B0**|
+ +------------+-----------+-----------+
+ | ``csrow0`` | rank0 | rank0 |
+ +------------+-----------+-----------+
+ | ``csrow1`` | rank1 | rank1 |
+ +------------+-----------+-----------+
+ | |**DIMM_A1**|**DIMM_B1**|
+ +------------+-----------+-----------+
+ | ``csrow2`` | rank0 | rank0 |
+ +------------+-----------+-----------+
+ | ``csrow3`` | rank1 | rank1 |
+ +------------+-----------+-----------+
+
+In the above example, there are 4 physical slots on the motherboard
+for memory DIMMs:
+
+ +---------+---------+
+ | DIMM_A0 | DIMM_B0 |
+ +---------+---------+
+ | DIMM_A1 | DIMM_B1 |
+ +---------+---------+
+
+Labels for these slots are usually silk-screened on the motherboard.
+Slots labeled ``A`` are channel 0 in this example. Slots labeled ``B`` are
+channel 1. Notice that there are two csrows possible on a physical DIMM.
+These csrows are allocated their csrow assignment based on the slot into
+which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
+Channel, the csrows cross both DIMMs.
+
+Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
+In the example above 2 dual ranked DIMMs are similarly placed. Thus,
+both csrow0 and csrow1 are populated. On the other hand, when 2 single
+ranked DIMMs are placed in slots DIMM_A0 and DIMM_B0, then they will
+have just one csrow (csrow0) and csrow1 will be empty. The pattern
+repeats itself for csrow2 and csrow3. Also note that some memory
+controllers don't have any logic to identify the memory module, see
+``rankX`` directories below.
+
+The representation of the above is reflected in the directory
+tree in EDAC's sysfs interface. Starting in directory
+``/sys/devices/system/edac/mc``, each memory controller will be
+represented by its own ``mcX`` directory, where ``X`` is the
+index of the MC::
+
+ ..../edac/mc/
+ |
+ |->mc0
+ |->mc1
+ |->mc2
+ ....
+
+Within each of the ``mcX`` directory are several EDAC control and
+attribute files.
+
+``mcX`` directories
+-------------------
+
+In ``mcX`` directories are EDAC control and attribute files for
+this ``X`` instance of the memory controllers.
+
+For a description of the sysfs API, please see:
+
+ Documentation/ABI/testing/sysfs-devices-edac
+
+
+``dimmX`` or ``rankX`` directories
+----------------------------------
+
+The recommended way to use the EDAC subsystem is to look at the information
+provided by the ``dimmX`` or ``rankX`` directories [#f5]_.
+
+A typical EDAC system has the following structure under
+``/sys/devices/system/edac/``\ [#f6]_::
+
+ /sys/devices/system/edac/
+ ├── mc
+ │   ├── mc0
+ │   │   ├── ce_count
+ │   │   ├── ce_noinfo_count
+ │   │   ├── dimm0
+ │   │   │   ├── dimm_ce_count
+ │   │   │   ├── dimm_dev_type
+ │   │   │   ├── dimm_edac_mode
+ │   │   │   ├── dimm_label
+ │   │   │   ├── dimm_location
+ │   │   │   ├── dimm_mem_type
+ │   │   │   ├── dimm_ue_count
+ │   │   │   ├── size
+ │   │   │   └── uevent
+ │   │   ├── max_location
+ │   │   ├── mc_name
+ │   │   ├── reset_counters
+ │   │   ├── seconds_since_reset
+ │   │   ├── size_mb
+ │   │   ├── ue_count
+ │   │   ├── ue_noinfo_count
+ │   │   └── uevent
+ │   ├── mc1
+ │   │   ├── ce_count
+ │   │   ├── ce_noinfo_count
+ │   │   ├── dimm0
+ │   │   │   ├── dimm_ce_count
+ │   │   │   ├── dimm_dev_type
+ │   │   │   ├── dimm_edac_mode
+ │   │   │   ├── dimm_label
+ │   │   │   ├── dimm_location
+ │   │   │   ├── dimm_mem_type
+ │   │   │   ├── dimm_ue_count
+ │   │   │   ├── size
+ │   │   │   └── uevent
+ │   │   ├── max_location
+ │   │   ├── mc_name
+ │   │   ├── reset_counters
+ │   │   ├── seconds_since_reset
+ │   │   ├── size_mb
+ │   │   ├── ue_count
+ │   │   ├── ue_noinfo_count
+ │   │   └── uevent
+ │   └── uevent
+ └── uevent
+
+In the ``dimmX`` directories are EDAC control and attribute files for
+this ``X`` memory module:
+
+- ``size`` - Total memory managed by this csrow attribute file
+
+ This attribute file displays, in count of megabytes, the memory
+ that this csrow contains.
+
+- ``dimm_ue_count`` - Uncorrectable Errors count attribute file
+
+ This attribute file displays the total count of uncorrectable
+ errors that have occurred on this DIMM. If panic_on_ue is set
+ this counter will not have a chance to increment, since EDAC
+ will panic the system.
+
+- ``dimm_ce_count`` - Correctable Errors count attribute file
+
+ This attribute file displays the total count of correctable
+ errors that have occurred on this DIMM. This count is very
+ important to examine. CEs provide early indications that a
+ DIMM is beginning to fail. This count field should be
+ monitored for non-zero values and report such information
+ to the system administrator.
+
+- ``dimm_dev_type`` - Device type attribute file
+
+ This attribute file will display what type of DRAM device is
+ being utilized on this DIMM.
+ Examples:
+
+ - x1
+ - x2
+ - x4
+ - x8
+
+- ``dimm_edac_mode`` - EDAC Mode of operation attribute file
+
+ This attribute file will display what type of Error detection
+ and correction is being utilized.
+
+- ``dimm_label`` - memory module label control file
+
+ This control file allows this DIMM to have a label assigned
+ to it. With this label in the module, when errors occur
+ the output can provide the DIMM label in the system log.
+ This becomes vital for panic events to isolate the
+ cause of the UE event.
+
+ DIMM Labels must be assigned after booting, with information
+ that correctly identifies the physical slot with its
+ silk screen label. This information is currently very
+ motherboard specific and determination of this information
+ must occur in userland at this time.
+
+- ``dimm_location`` - location of the memory module
+
+ The location can have up to 3 levels, and describe how the
+ memory controller identifies the location of a memory module.
+ Depending on the type of memory and memory controller, it
+ can be:
+
+ - *csrow* and *channel* - used when the memory controller
+ doesn't identify a single DIMM - e. g. in ``rankX`` dir;
+ - *branch*, *channel*, *slot* - typically used on FB-DIMM memory
+ controllers;
+ - *channel*, *slot* - used on Nehalem and newer Intel drivers.
+
+- ``dimm_mem_type`` - Memory Type attribute file
+
+ This attribute file will display what type of memory is currently
+ on this csrow. Normally, either buffered or unbuffered memory.
+ Examples:
+
+ - Registered-DDR
+ - Unbuffered-DDR
+
+.. [#f5] On some systems, the memory controller doesn't have any logic
+ to identify the memory module. On such systems, the directory is called ``rankX``.
+ On modern Intel memory controllers, the memory controller identifies the
+ memory modules directly. On such systems, the directory is called ``dimmX``.
+
+.. [#f6] There are also some ``power`` directories and ``subsystem``
+ symlinks inside the sysfs mapping that are automatically created by
+ the sysfs subsystem. Currently, they serve no purpose.
+
+
+System Logging
+--------------
+
+If logging for UEs and CEs is enabled, then system logs will contain
+information indicating that errors have been detected::
+
+ EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0, channel 1 "DIMM_B1": amd76x_edac
+ EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0, channel 1 "DIMM_B1": amd76x_edac
+
+
+The structure of the message is:
+
+ +---------------------------------------+-------------+
+ | Content | Example |
+ +=======================================+=============+
+ | The memory controller | MC0 |
+ +---------------------------------------+-------------+
+ | Error type | CE |
+ +---------------------------------------+-------------+
+ | Memory page | 0x283 |
+ +---------------------------------------+-------------+
+ | Offset in the page | 0xce0 |
+ +---------------------------------------+-------------+
+ | The byte granularity | grain 8 |
+ | or resolution of the error | |
+ +---------------------------------------+-------------+
+ | The error syndrome | 0xb741 |
+ +---------------------------------------+-------------+
+ | Memory row | row 0 |
+ +---------------------------------------+-------------+
+ | Memory channel | channel 1 |
+ +---------------------------------------+-------------+
+ | DIMM label, if set prior | DIMM B1 |
+ +---------------------------------------+-------------+
+ | And then an optional, driver-specific | |
+ | message that may have additional | |
+ | information. | |
+ +---------------------------------------+-------------+
+
+Both UEs and CEs with no info will lack all but memory controller, error
+type, a notice of "no info" and then an optional, driver-specific error
+message.
+
+
+PCI Bus Parity Detection
+------------------------
+
+On Header Type 00 devices, the primary status is looked at for any
+parity error regardless of whether parity is enabled on the device or
+not. (The spec indicates parity is generated in some cases). On Header
+Type 01 bridges, the secondary status register is also looked at to see
+if parity occurred on the bus on the other side of the bridge.
+
+
+Sysfs configuration
+-------------------
+
+Under ``/sys/devices/system/edac/pci`` are control and attribute files as
+follows:
+
+
+- ``check_pci_parity`` - Enable/Disable PCI Parity checking control file
+
+ This control file enables or disables the PCI Bus Parity scanning
+ operation. Writing a 1 to this file enables the scanning. Writing
+ a 0 to this file disables the scanning.
+
+ Enable::
+
+ echo "1" >/sys/devices/system/edac/pci/check_pci_parity
+
+ Disable::
+
+ echo "0" >/sys/devices/system/edac/pci/check_pci_parity
+
+
+- ``pci_parity_count`` - Parity Count
+
+ This attribute file will display the number of parity errors that
+ have been detected.
+
+
+Module parameters
+-----------------
+
+- ``edac_mc_panic_on_ue`` - Panic on UE control file
+
+ An uncorrectable error will cause a machine panic. This is usually
+ desirable. It is a bad idea to continue when an uncorrectable error
+ occurs - it is indeterminate what was uncorrected and the operating
+ system context might be so mangled that continuing will lead to further
+ corruption. If the kernel has MCE configured, then EDAC will never
+ notice the UE.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_panic_on_ue=[0|1]
+
+ RUN TIME::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
+
+
+- ``edac_mc_log_ue`` - Log UE control file
+
+
+ Generate kernel messages describing uncorrectable errors. These errors
+ are reported through the system message log system. UE statistics
+ will be accumulated even when UE logging is disabled.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_log_ue=[0|1]
+
+ RUN TIME::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
+
+
+- ``edac_mc_log_ce`` - Log CE control file
+
+
+ Generate kernel messages describing correctable errors. These
+ errors are reported through the system message log system.
+ CE statistics will be accumulated even when CE logging is disabled.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_log_ce=[0|1]
+
+ RUN TIME::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
+
+
+- ``edac_mc_poll_msec`` - Polling period control file
+
+
+ The time period, in milliseconds, for polling for error information.
+ Too small a value wastes resources. Too large a value might delay
+ necessary handling of errors and might loose valuable information for
+ locating the error. 1000 milliseconds (once each second) is the current
+ default. Systems which require all the bandwidth they can get, may
+ increase this.
+
+ LOAD TIME::
+
+ module/kernel parameter: edac_mc_poll_msec=[0|1]
+
+ RUN TIME::
+
+ echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
+
+
+- ``panic_on_pci_parity`` - Panic on PCI PARITY Error
+
+
+ This control file enables or disables panicking when a parity
+ error has been detected.
+
+
+ module/kernel parameter::
+
+ edac_panic_on_pci_pe=[0|1]
+
+ Enable::
+
+ echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
+
+ Disable::
+
+ echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
+
+
+
+EDAC device type
+----------------
+
+In the header file, edac_pci.h, there is a series of edac_device structures
+and APIs for the EDAC_DEVICE.
+
+User space access to an edac_device is through the sysfs interface.
+
+At the location ``/sys/devices/system/edac`` (sysfs) new edac_device devices
+will appear.
+
+There is a three level tree beneath the above ``edac`` directory. For example,
+the ``test_device_edac`` device (found at the http://bluesmoke.sourceforget.net
+website) installs itself as::
+
+ /sys/devices/system/edac/test-instance
+
+in this directory are various controls, a symlink and one or more ``instance``
+directories.
+
+The standard default controls are:
+
+ ============== =======================================================
+ log_ce boolean to log CE events
+ log_ue boolean to log UE events
+ panic_on_ue boolean to ``panic`` the system if an UE is encountered
+ (default off, can be set true via startup script)
+ poll_msec time period between POLL cycles for events
+ ============== =======================================================
+
+The test_device_edac device adds at least one of its own custom control:
+
+ ============== ==================================================
+ test_bits which in the current test driver does nothing but
+ show how it is installed. A ported driver can
+ add one or more such controls and/or attributes
+ for specific uses.
+ One out-of-tree driver uses controls here to allow
+ for ERROR INJECTION operations to hardware
+ injection registers
+ ============== ==================================================
+
+The symlink points to the 'struct dev' that is registered for this edac_device.
+
+Instances
+---------
+
+One or more instance directories are present. For the ``test_device_edac``
+case:
+
+ +----------------+
+ | test-instance0 |
+ +----------------+
+
+
+In this directory there are two default counter attributes, which are totals of
+counter in deeper subdirectories.
+
+ ============== ====================================
+ ce_count total of CE events of subdirectories
+ ue_count total of UE events of subdirectories
+ ============== ====================================
+
+Blocks
+------
+
+At the lowest directory level is the ``block`` directory. There can be 0, 1
+or more blocks specified in each instance:
+
+ +-------------+
+ | test-block0 |
+ +-------------+
+
+In this directory the default attributes are:
+
+ ============== ================================================
+ ce_count which is counter of CE events for this ``block``
+ of hardware being monitored
+ ue_count which is counter of UE events for this ``block``
+ of hardware being monitored
+ ============== ================================================
+
+
+The ``test_device_edac`` device adds 4 attributes and 1 control:
+
+ ================== ====================================================
+ test-block-bits-0 for every POLL cycle this counter
+ is incremented
+ test-block-bits-1 every 10 cycles, this counter is bumped once,
+ and test-block-bits-0 is set to 0
+ test-block-bits-2 every 100 cycles, this counter is bumped once,
+ and test-block-bits-1 is set to 0
+ test-block-bits-3 every 1000 cycles, this counter is bumped once,
+ and test-block-bits-2 is set to 0
+ ================== ====================================================
+
+
+ ================== ====================================================
+ reset-counters writing ANY thing to this control will
+ reset all the above counters.
+ ================== ====================================================
+
+
+Use of the ``test_device_edac`` driver should enable any others to create their own
+unique drivers for their hardware systems.
+
+The ``test_device_edac`` sample driver is located at the
+http://bluesmoke.sourceforge.net project site for EDAC.
+
+
+Usage of EDAC APIs on Nehalem and newer Intel CPUs
+--------------------------------------------------
+
+On older Intel architectures, the memory controller was part of the North
+Bridge chipset. Nehalem, Sandy Bridge, Ivy Bridge, Haswell, Sky Lake and
+newer Intel architectures integrated an enhanced version of the memory
+controller (MC) inside the CPUs.
+
+This chapter will cover the differences of the enhanced memory controllers
+found on newer Intel CPUs, such as ``i7core_edac``, ``sb_edac`` and
+``sbx_edac`` drivers.
+
+.. note::
+
+ The Xeon E7 processor families use a separate chip for the memory
+ controller, called Intel Scalable Memory Buffer. This section doesn't
+ apply for such families.
+
+1) There is one Memory Controller per Quick Patch Interconnect
+ (QPI). At the driver, the term "socket" means one QPI. This is
+ associated with a physical CPU socket.
+
+ Each MC have 3 physical read channels, 3 physical write channels and
+ 3 logic channels. The driver currently sees it as just 3 channels.
+ Each channel can have up to 3 DIMMs.
+
+ The minimum known unity is DIMMs. There are no information about csrows.
+ As EDAC API maps the minimum unity is csrows, the driver sequentially
+ maps channel/DIMM into different csrows.
+
+ For example, supposing the following layout::
+
+ Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
+ dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+ dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
+ Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
+ dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+ Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
+ dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+
+ The driver will map it as::
+
+ csrow0: channel 0, dimm0
+ csrow1: channel 0, dimm1
+ csrow2: channel 1, dimm0
+ csrow3: channel 2, dimm0
+
+ exports one DIMM per csrow.
+
+ Each QPI is exported as a different memory controller.
+
+2) The MC has the ability to inject errors to test drivers. The drivers
+ implement this functionality via some error injection nodes:
+
+ For injecting a memory error, there are some sysfs nodes, under
+ ``/sys/devices/system/edac/mc/mc?/``:
+
+ - ``inject_addrmatch/*``:
+ Controls the error injection mask register. It is possible to specify
+ several characteristics of the address to match an error code::
+
+ dimm = the affected dimm. Numbers are relative to a channel;
+ rank = the memory rank;
+ channel = the channel that will generate an error;
+ bank = the affected bank;
+ page = the page address;
+ column (or col) = the address column.
+
+ each of the above values can be set to "any" to match any valid value.
+
+ At driver init, all values are set to any.
+
+ For example, to generate an error at rank 1 of dimm 2, for any channel,
+ any bank, any page, any column::
+
+ echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
+ echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
+
+ To return to the default behaviour of matching any, you can do::
+
+ echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
+ echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
+
+ - ``inject_eccmask``:
+ specifies what bits will have troubles,
+
+ - ``inject_section``:
+ specifies what ECC cache section will get the error::
+
+ 3 for both
+ 2 for the highest
+ 1 for the lowest
+
+ - ``inject_type``:
+ specifies the type of error, being a combination of the following bits::
+
+ bit 0 - repeat
+ bit 1 - ecc
+ bit 2 - parity
+
+ - ``inject_enable``:
+ starts the error generation when something different than 0 is written.
+
+ All inject vars can be read. root permission is needed for write.
+
+ Datasheet states that the error will only be generated after a write on an
+ address that matches inject_addrmatch. It seems, however, that reading will
+ also produce an error.
+
+ For example, the following code will generate an error for any write access
+ at socket 0, on any DIMM/address on channel 2::
+
+ echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
+ echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
+ echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
+ echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
+ echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
+ dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
+
+ For socket 1, it is needed to replace "mc0" by "mc1" at the above
+ commands.
+
+ The generated error message will look like::
+
+ EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
+
+3) Corrected Error memory register counters
+
+ Those newer MCs have some registers to count memory errors. The driver
+ uses those registers to report Corrected Errors on devices with Registered
+ DIMMs.
+
+ However, those counters don't work with Unregistered DIMM. As the chipset
+ offers some counters that also work with UDIMMs (but with a worse level of
+ granularity than the default ones), the driver exposes those registers for
+ UDIMM memories.
+
+ They can be read by looking at the contents of ``all_channel_counts/``::
+
+ $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
+ /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
+ 0
+ /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
+ 0
+ /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
+ 0
+
+ What happens here is that errors on different csrows, but at the same
+ dimm number will increment the same counter.
+ So, in this memory mapping::
+
+ csrow0: channel 0, dimm0
+ csrow1: channel 0, dimm1
+ csrow2: channel 1, dimm0
+ csrow3: channel 2, dimm0
+
+ The hardware will increment udimm0 for an error at the first dimm at either
+ csrow0, csrow2 or csrow3;
+
+ The hardware will increment udimm1 for an error at the second dimm at either
+ csrow0, csrow2 or csrow3;
+
+ The hardware will increment udimm2 for an error at the third dimm at either
+ csrow0, csrow2 or csrow3;
+
+4) Standard error counters
+
+ The standard error counters are generated when an mcelog error is received
+ by the driver. Since, with UDIMM, this is counted by software, it is
+ possible that some errors could be lost. With RDIMM's, they display the
+ contents of the registers
+
+Reference documents used on ``amd64_edac``
+------------------------------------------
+
+``amd64_edac`` module is based on the following documents
+(available from http://support.amd.com/en-us/search/tech-docs):
+
+1. :Title: BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD
+ Opteron Processors
+ :AMD publication #: 26094
+ :Revision: 3.26
+ :Link: http://support.amd.com/TechDocs/26094.PDF
+
+2. :Title: BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh
+ Processors
+ :AMD publication #: 32559
+ :Revision: 3.00
+ :Issue Date: May 2006
+ :Link: http://support.amd.com/TechDocs/32559.pdf
+
+3. :Title: BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h
+ Processors
+ :AMD publication #: 31116
+ :Revision: 3.00
+ :Issue Date: September 07, 2007
+ :Link: http://support.amd.com/TechDocs/31116.pdf
+
+4. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
+ Models 30h-3Fh Processors
+ :AMD publication #: 49125
+ :Revision: 3.06
+ :Issue Date: 2/12/2015 (latest release)
+ :Link: http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf
+
+5. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
+ Models 60h-6Fh Processors
+ :AMD publication #: 50742
+ :Revision: 3.01
+ :Issue Date: 7/23/2015 (latest release)
+ :Link: http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
+
+6. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h
+ Models 00h-0Fh Processors
+ :AMD publication #: 48751
+ :Revision: 3.03
+ :Issue Date: 2/23/2015 (latest release)
+ :Link: http://support.amd.com/TechDocs/48751_16h_bkdg.pdf
+
+Credits
+=======
+
+* Written by Doug Thompson <dougthompson@xmission.com>
+
+ - 7 Dec 2005
+ - 17 Jul 2007 Updated
+
+* |copy| Mauro Carvalho Chehab
+
+ - 05 Aug 2009 Nehalem interface
+ - 26 Oct 2016 Converted to ReST and cleanups at the Nehalem section
+
+* EDAC authors/maintainers:
+
+ - Doug Thompson, Dave Jiang, Dave Peterson et al,
+ - Mauro Carvalho Chehab
+ - Borislav Petkov
+ - original author: Thayne Harbaugh
diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst
index 9a969c0157f1..05301f03b717 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -165,7 +165,7 @@ Configuring the kernel
"make xconfig" Qt based configuration tool.
- "make gconfig" GTK+ based configuration tool.
+ "make gconfig" GTK based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
@@ -176,7 +176,7 @@ Configuring the kernel
values without prompting.
"make defconfig" Create a ./.config file by using the default
- symbol values from either arch/$ARCH/defconfig
+ symbol values from either arch/$ARCH/configs/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
@@ -259,12 +259,14 @@ Configuring the kernel
Compiling the kernel
--------------------
- - Make sure you have at least gcc 5.1 available.
+ - Make sure you have at least gcc 8.1 available.
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.
- - Do a ``make`` to create a compressed kernel image. It is also
- possible to do ``make install`` if you have lilo installed to suit the
- kernel makefiles, but you may want to check your particular lilo setup first.
+ - Do a ``make`` to create a compressed kernel image. It is also possible to do
+ ``make install`` if you have lilo installed or if your distribution has an
+ install script recognised by the kernel's installer. Most popular
+ distributions will have a recognized install script. You may want to
+ check your distribution's setup first.
To do the actual install, you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
@@ -301,32 +303,51 @@ Compiling the kernel
image (e.g. .../linux/arch/x86/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- - Booting a kernel directly from a floppy without the assistance of a
- bootloader such as LILO, is no longer supported.
-
- If you boot Linux from the hard drive, chances are you use LILO, which
- uses the kernel image as specified in the file /etc/lilo.conf. The
- kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
- /boot/bzImage. To use the new kernel, save a copy of the old image
- and copy the new image over the old one. Then, you MUST RERUN LILO
- to update the loading map! If you don't, you won't be able to boot
- the new kernel image.
-
- Reinstalling LILO is usually a matter of running /sbin/lilo.
- You may wish to edit /etc/lilo.conf to specify an entry for your
- old kernel image (say, /vmlinux.old) in case the new one does not
- work. See the LILO docs for more information.
-
- After reinstalling LILO, you should be all set. Shutdown the system,
+ - Booting a kernel directly from a storage device without the assistance
+ of a bootloader such as LILO or GRUB, is no longer supported in BIOS
+ (non-EFI systems). On UEFI/EFI systems, however, you can use EFISTUB
+ which allows the motherboard to boot directly to the kernel.
+ On modern workstations and desktops, it's generally recommended to use a
+ bootloader as difficulties can arise with multiple kernels and secure boot.
+ For more details on EFISTUB,
+ see "Documentation/admin-guide/efi-stub.rst".
+
+ - It's important to note that as of 2016 LILO (LInux LOader) is no longer in
+ active development, though as it was extremely popular, it often comes up
+ in documentation. Popular alternatives include GRUB2, rEFInd, Syslinux,
+ systemd-boot, or EFISTUB. For various reasons, it's not recommended to use
+ software that's no longer in active development.
+
+ - Chances are your distribution includes an install script and running
+ ``make install`` will be all that's needed. Should that not be the case
+ you'll have to identify your bootloader and reference its documentation or
+ configure your EFI.
+
+Legacy LILO Instructions
+------------------------
+
+
+ - If you use LILO the kernel images are specified in the file /etc/lilo.conf.
+ The kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
+ /boot/bzImage. To use the new kernel, save a copy of the old image and copy
+ the new image over the old one. Then, you MUST RERUN LILO to update the
+ loading map! If you don't, you won't be able to boot the new kernel image.
+
+ - Reinstalling LILO is usually a matter of running /sbin/lilo. You may wish
+ to edit /etc/lilo.conf to specify an entry for your old kernel image
+ (say, /vmlinux.old) in case the new one does not work. See the LILO docs
+ for more information.
+
+ - After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
- If you ever need to change the default root device, video mode,
- etc. in the kernel image, use your bootloader's boot options
- where appropriate. No need to recompile the kernel to change
- these parameters.
+ - If you ever need to change the default root device, video mode, etc. in the
+ kernel image, use your bootloader's boot options where appropriate. No need
+ to recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
+
If something goes wrong
-----------------------
@@ -335,5 +356,5 @@ instructions at 'Documentation/admin-guide/reporting-issues.rst'.
Hints on understanding kernel bug reports are in
'Documentation/admin-guide/bug-hunting.rst'. More on debugging the kernel
-with gdb is in 'Documentation/dev-tools/gdb-kernel-debugging.rst' and
-'Documentation/dev-tools/kgdb.rst'.
+with gdb is in 'Documentation/process/debugging/gdb-kernel-debugging.rst' and
+'Documentation/process/debugging/kgdb.rst'.
diff --git a/Documentation/admin-guide/abi-obsolete-files.rst b/Documentation/admin-guide/abi-obsolete-files.rst
new file mode 100644
index 000000000000..3061a916b4b5
--- /dev/null
+++ b/Documentation/admin-guide/abi-obsolete-files.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Obsolete ABI Files
+==================
+
+.. kernel-abi:: obsolete
+ :no-symbols:
diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst
index d095867899c5..640f3903e847 100644
--- a/Documentation/admin-guide/abi-obsolete.rst
+++ b/Documentation/admin-guide/abi-obsolete.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
ABI obsolete symbols
====================
@@ -7,5 +9,5 @@ marked to be removed at some later point in time.
The description of the interface will document the reason why it is
obsolete and when it can be expected to be removed.
-.. kernel-abi:: $srctree/Documentation/ABI/obsolete
- :rst:
+.. kernel-abi:: obsolete
+ :no-files:
diff --git a/Documentation/admin-guide/abi-removed-files.rst b/Documentation/admin-guide/abi-removed-files.rst
new file mode 100644
index 000000000000..f1bdfadd2ec4
--- /dev/null
+++ b/Documentation/admin-guide/abi-removed-files.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Removed ABI Files
+=================
+
+.. kernel-abi:: removed
+ :no-symbols:
diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst
index f7e9e43023c1..88832d3eacd6 100644
--- a/Documentation/admin-guide/abi-removed.rst
+++ b/Documentation/admin-guide/abi-removed.rst
@@ -1,5 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
ABI removed symbols
===================
-.. kernel-abi:: $srctree/Documentation/ABI/removed
- :rst:
+.. kernel-abi:: removed
+ :no-files:
diff --git a/Documentation/admin-guide/abi-stable-files.rst b/Documentation/admin-guide/abi-stable-files.rst
new file mode 100644
index 000000000000..f867738fc178
--- /dev/null
+++ b/Documentation/admin-guide/abi-stable-files.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Stable ABI Files
+================
+
+.. kernel-abi:: stable
+ :no-symbols:
diff --git a/Documentation/admin-guide/abi-stable.rst b/Documentation/admin-guide/abi-stable.rst
index 70490736e0d3..528c68401f4b 100644
--- a/Documentation/admin-guide/abi-stable.rst
+++ b/Documentation/admin-guide/abi-stable.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
ABI stable symbols
==================
@@ -10,5 +12,5 @@ for at least 2 years.
Most interfaces (like syscalls) are expected to never change and always
be available.
-.. kernel-abi:: $srctree/Documentation/ABI/stable
- :rst:
+.. kernel-abi:: stable
+ :no-files:
diff --git a/Documentation/admin-guide/abi-testing-files.rst b/Documentation/admin-guide/abi-testing-files.rst
new file mode 100644
index 000000000000..1da868e42fdb
--- /dev/null
+++ b/Documentation/admin-guide/abi-testing-files.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Testing ABI Files
+=================
+
+.. kernel-abi:: testing
+ :no-symbols:
diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst
index b205b16a72d0..6153ebd38e2d 100644
--- a/Documentation/admin-guide/abi-testing.rst
+++ b/Documentation/admin-guide/abi-testing.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
ABI testing symbols
===================
@@ -16,5 +18,5 @@ Programs that use these interfaces are strongly encouraged to add their
name to the description of these interfaces, so that the kernel
developers can easily notify them if any changes occur.
-.. kernel-abi:: $srctree/Documentation/ABI/testing
- :rst:
+.. kernel-abi:: testing
+ :no-files:
diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst
index bcab3ef2597c..c6039359e585 100644
--- a/Documentation/admin-guide/abi.rst
+++ b/Documentation/admin-guide/abi.rst
@@ -1,7 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
=====================
Linux ABI description
=====================
+.. kernel-abi:: README
+
+ABI symbols
+-----------
+
.. toctree::
:maxdepth: 2
@@ -9,3 +16,14 @@ Linux ABI description
abi-testing
abi-obsolete
abi-removed
+
+ABI files
+---------
+
+.. toctree::
+ :maxdepth: 2
+
+ abi-stable-files
+ abi-testing-files
+ abi-obsolete-files
+ abi-removed-files
diff --git a/Documentation/admin-guide/acpi/cppc_sysfs.rst b/Documentation/admin-guide/acpi/cppc_sysfs.rst
index e53d76365aa7..36981c667823 100644
--- a/Documentation/admin-guide/acpi/cppc_sysfs.rst
+++ b/Documentation/admin-guide/acpi/cppc_sysfs.rst
@@ -75,4 +75,4 @@ taking two different snapshots of feedback counters at time T1 and T2.
delivered_counter_delta = fbc_t2[del] - fbc_t1[del]
reference_counter_delta = fbc_t2[ref] - fbc_t1[ref]
- delivered_perf = (refernce_perf x delivered_counter_delta) / reference_counter_delta
+ delivered_perf = (reference_perf x delivered_counter_delta) / reference_counter_delta
diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst
index 71277689ad97..b078fdb8f4c9 100644
--- a/Documentation/admin-guide/acpi/index.rst
+++ b/Documentation/admin-guide/acpi/index.rst
@@ -9,7 +9,6 @@ the Linux ACPI support.
:maxdepth: 1
initrd_table_override
- dsdt-override
ssdt-overlays
cppc_sysfs
fan_performance_states
diff --git a/Documentation/admin-guide/acpi/ssdt-overlays.rst b/Documentation/admin-guide/acpi/ssdt-overlays.rst
index b5fbf54dca19..5ea9f4a3b76e 100644
--- a/Documentation/admin-guide/acpi/ssdt-overlays.rst
+++ b/Documentation/admin-guide/acpi/ssdt-overlays.rst
@@ -103,7 +103,7 @@ allows a persistent, OS independent way of storing the user defined SSDTs. There
is also work underway to implement EFI support for loading user defined SSDTs
and using this method will make it easier to convert to the EFI loading
mechanism when that will arrive. To enable it, the
-CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y.
+CONFIG_EFI_CUSTOM_SSDT_OVERLAYS should be chosen to y.
In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel
command line parameter can be used (the name has a limitation of 16 characters).
diff --git a/Documentation/admin-guide/aoe/udev.txt b/Documentation/admin-guide/aoe/udev.txt
index 5fb756466bc7..d55ecb411c21 100644
--- a/Documentation/admin-guide/aoe/udev.txt
+++ b/Documentation/admin-guide/aoe/udev.txt
@@ -2,7 +2,7 @@
# They may be installed along the following lines. Check the section
# 8 udev manpage to see whether your udev supports SUBSYSTEM, and
# whether it uses one or two equal signs for SUBSYSTEM and KERNEL.
-#
+#
# ecashin@makki ~$ su
# Password:
# bash# find /etc -type f -name udev.conf
@@ -13,7 +13,7 @@
# 10-wacom.rules 50-udev.rules
# bash# cp /path/to/linux/Documentation/admin-guide/aoe/udev.txt \
# /etc/udev/rules.d/60-aoe.rules
-#
+#
# aoe char devices
SUBSYSTEM=="aoe", KERNEL=="discover", NAME="etherd/%k", GROUP="disk", MODE="0220"
@@ -22,5 +22,5 @@ SUBSYSTEM=="aoe", KERNEL=="interfaces", NAME="etherd/%k", GROUP="disk", MODE="02
SUBSYSTEM=="aoe", KERNEL=="revalidate", NAME="etherd/%k", GROUP="disk", MODE="0220"
SUBSYSTEM=="aoe", KERNEL=="flush", NAME="etherd/%k", GROUP="disk", MODE="0220"
-# aoe block devices
+# aoe block devices
KERNEL=="etherd*", GROUP="disk"
diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
index 8d3a2d045c0a..f71f349553e4 100644
--- a/Documentation/admin-guide/bcache.rst
+++ b/Documentation/admin-guide/bcache.rst
@@ -17,8 +17,7 @@ The latest bcache kernel code can be found from mainline Linux kernel:
It's designed around the performance characteristics of SSDs - it only allocates
in erase block sized buckets, and it uses a hybrid btree/log to track cached
extents (which can be anywhere from a single sector to the bucket size). It's
-designed to avoid random writes at all costs; it fills up an erase block
-sequentially, then issues a discard before reusing it.
+designed to avoid random writes at all costs.
Both writethrough and writeback caching are supported. Writeback defaults to
off, but can be switched on and off arbitrarily at runtime. Bcache goes to
@@ -204,7 +203,7 @@ For example::
This should present your unmodified backing device data in /dev/loop0
If your cache is in writethrough mode, then you can safely discard the
-cache device without loosing data.
+cache device without losing data.
E) Wiping a cache device
@@ -508,9 +507,6 @@ cache_miss_collisions
cache miss, but raced with a write and data was already present (usually 0
since the synchronization for cache misses was rewritten)
-cache_readaheads
- Count of times readahead occurred.
-
Sysfs - cache set
~~~~~~~~~~~~~~~~~
@@ -621,19 +617,11 @@ bucket_size
cache_replacement_policy
One of either lru, fifo or random.
-discard
- Boolean; if on a discard/TRIM will be issued to each bucket before it is
- reused. Defaults to off, since SATA TRIM is an unqueued command (and thus
- slow).
-
freelist_percent
Size of the freelist as a percentage of nbuckets. Can be written to to
increase the number of buckets kept on the freelist, which lets you
artificially reduce the size of the cache at runtime. Mostly for testing
- purposes (i.e. testing how different size caches affect your hit rate), but
- since buckets are discarded when they move on to the freelist will also make
- the SSD's garbage collection easier by effectively giving it more reserved
- space.
+ purposes (i.e. testing how different size caches affect your hit rate).
io_errors
Number of errors that have occurred, decayed by io_error_halflife.
diff --git a/Documentation/admin-guide/blockdev/index.rst b/Documentation/admin-guide/blockdev/index.rst
index 957ccf617797..3262397ebe8f 100644
--- a/Documentation/admin-guide/blockdev/index.rst
+++ b/Documentation/admin-guide/blockdev/index.rst
@@ -11,6 +11,7 @@ Block Devices
nbd
paride
ramdisk
+ zoned_loop
zram
drbd/index
diff --git a/Documentation/admin-guide/blockdev/nbd.rst b/Documentation/admin-guide/blockdev/nbd.rst
index d78dfe559dcf..faf2ac4b1509 100644
--- a/Documentation/admin-guide/blockdev/nbd.rst
+++ b/Documentation/admin-guide/blockdev/nbd.rst
@@ -14,7 +14,7 @@ to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc.
For more information, or to download the nbd-client and nbd-server
-tools, go to http://nbd.sf.net/.
+tools, go to https://github.com/NetworkBlockDevice/nbd.
The nbd kernel module need only be installed on the client
system, as the nbd-server is completely in userspace. In fact,
diff --git a/Documentation/admin-guide/blockdev/paride.rst b/Documentation/admin-guide/blockdev/paride.rst
index e1ce90af602a..b2f627d4c2f8 100644
--- a/Documentation/admin-guide/blockdev/paride.rst
+++ b/Documentation/admin-guide/blockdev/paride.rst
@@ -3,6 +3,7 @@ Linux and parallel port IDE devices
===================================
PARIDE v1.03 (c) 1997-8 Grant Guenther <grant@torque.net>
+PATA_PARPORT (c) 2023 Ondrej Zary
1. Introduction
===============
@@ -51,27 +52,15 @@ parallel port IDE subsystem, including:
as well as most of the clone and no-name products on the market.
-To support such a wide range of devices, PARIDE, the parallel port IDE
-subsystem, is actually structured in three parts. There is a base
-paride module which provides a registry and some common methods for
-accessing the parallel ports. The second component is a set of
-high-level drivers for each of the different types of supported devices:
+To support such a wide range of devices, pata_parport is actually structured
+in two parts. There is a base pata_parport module which provides an interface
+to kernel libata subsystem, registry and some common methods for accessing
+the parallel ports.
- === =============
- pd IDE disk
- pcd ATAPI CD-ROM
- pf ATAPI disk
- pt ATAPI tape
- pg ATAPI generic
- === =============
-
-(Currently, the pg driver is only used with CD-R drives).
-
-The high-level drivers function according to the relevant standards.
-The third component of PARIDE is a set of low-level protocol drivers
-for each of the parallel port IDE adapter chips. Thanks to the interest
-and encouragement of Linux users from many parts of the world,
-support is available for almost all known adapter protocols:
+The second component is a set of low-level protocol drivers for each of the
+parallel port IDE adapter chips. Thanks to the interest and encouragement of
+Linux users from many parts of the world, support is available for almost all
+known adapter protocols:
==== ====================================== ====
aten ATEN EH-100 (HK)
@@ -91,251 +80,87 @@ support is available for almost all known adapter protocols:
==== ====================================== ====
-2. Using the PARIDE subsystem
-=============================
+2. Using pata_parport subsystem
+===============================
While configuring the Linux kernel, you may choose either to build
-the PARIDE drivers into your kernel, or to build them as modules.
+the pata_parport drivers into your kernel, or to build them as modules.
In either case, you will need to select "Parallel port IDE device support"
-as well as at least one of the high-level drivers and at least one
-of the parallel port communication protocols. If you do not know
-what kind of parallel port adapter is used in your drive, you could
-begin by checking the file names and any text files on your DOS
+and at least one of the parallel port communication protocols.
+If you do not know what kind of parallel port adapter is used in your drive,
+you could begin by checking the file names and any text files on your DOS
installation floppy. Alternatively, you can look at the markings on
the adapter chip itself. That's usually sufficient to identify the
correct device.
-You can actually select all the protocol modules, and allow the PARIDE
+You can actually select all the protocol modules, and allow the pata_parport
subsystem to try them all for you.
For the "brand-name" products listed above, here are the protocol
and high-level drivers that you would use:
- ================ ============ ====== ========
- Manufacturer Model Driver Protocol
- ================ ============ ====== ========
- MicroSolutions CD-ROM pcd bpck
- MicroSolutions PD drive pf bpck
- MicroSolutions hard-drive pd bpck
- MicroSolutions 8000t tape pt bpck
- SyQuest EZ, SparQ pd epat
- Imation Superdisk pf epat
- Maxell Superdisk pf friq
- Avatar Shark pd epat
- FreeCom CD-ROM pcd frpw
- Hewlett-Packard 5GB Tape pt epat
- Hewlett-Packard 7200e (CD) pcd epat
- Hewlett-Packard 7200e (CD-R) pg epat
- ================ ============ ====== ========
-
-2.1 Configuring built-in drivers
----------------------------------
-
-We recommend that you get to know how the drivers work and how to
-configure them as loadable modules, before attempting to compile a
-kernel with the drivers built-in.
-
-If you built all of your PARIDE support directly into your kernel,
-and you have just a single parallel port IDE device, your kernel should
-locate it automatically for you. If you have more than one device,
-you may need to give some command line options to your bootloader
-(eg: LILO), how to do that is beyond the scope of this document.
-
-The high-level drivers accept a number of command line parameters, all
-of which are documented in the source files in linux/drivers/block/paride.
-By default, each driver will automatically try all parallel ports it
-can find, and all protocol types that have been installed, until it finds
-a parallel port IDE adapter. Once it finds one, the probe stops. So,
-if you have more than one device, you will need to tell the drivers
-how to identify them. This requires specifying the port address, the
-protocol identification number and, for some devices, the drive's
-chain ID. While your system is booting, a number of messages are
-displayed on the console. Like all such messages, they can be
-reviewed with the 'dmesg' command. Among those messages will be
-some lines like::
-
- paride: bpck registered as protocol 0
- paride: epat registered as protocol 1
-
-The numbers will always be the same until you build a new kernel with
-different protocol selections. You should note these numbers as you
-will need them to identify the devices.
+ ================ ============ ========
+ Manufacturer Model Protocol
+ ================ ============ ========
+ MicroSolutions CD-ROM bpck
+ MicroSolutions PD drive bpck
+ MicroSolutions hard-drive bpck
+ MicroSolutions 8000t tape bpck
+ SyQuest EZ, SparQ epat
+ Imation Superdisk epat
+ Maxell Superdisk friq
+ Avatar Shark epat
+ FreeCom CD-ROM frpw
+ Hewlett-Packard 5GB Tape epat
+ Hewlett-Packard 7200e (CD) epat
+ Hewlett-Packard 7200e (CD-R) epat
+ ================ ============ ========
+
+All parports and all protocol drivers are probed automatically unless probe=0
+parameter is used. So just "modprobe epat" is enough for an Imation SuperDisk
+drive to work.
+
+Manual device creation::
+
+ # echo "port protocol mode unit delay" >/sys/bus/pata_parport/new_device
+
+where:
+
+ ======== ================================================
+ port parport name (or "auto" for all parports)
+ protocol protocol name (or "auto" for all protocols)
+ mode mode number (protocol-specific) or -1 for probe
+ unit unit number (for backpack only, see below)
+ delay I/O delay (see troubleshooting section below)
+ ======== ================================================
If you happen to be using a MicroSolutions backpack device, you will
also need to know the unit ID number for each drive. This is usually
the last two digits of the drive's serial number (but read MicroSolutions'
documentation about this).
-As an example, let's assume that you have a MicroSolutions PD/CD drive
-with unit ID number 36 connected to the parallel port at 0x378, a SyQuest
-EZ-135 connected to the chained port on the PD/CD drive and also an
-Imation Superdisk connected to port 0x278. You could give the following
-options on your boot command::
-
- pd.drive0=0x378,1 pf.drive0=0x278,1 pf.drive1=0x378,0,36
-
-In the last option, pf.drive1 configures device /dev/pf1, the 0x378
-is the parallel port base address, the 0 is the protocol registration
-number and 36 is the chain ID.
-
-Please note: while PARIDE will work both with and without the
-PARPORT parallel port sharing system that is included by the
-"Parallel port support" option, PARPORT must be included and enabled
-if you want to use chains of devices on the same parallel port.
-
-2.2 Loading and configuring PARIDE as modules
-----------------------------------------------
-
-It is much faster and simpler to get to understand the PARIDE drivers
-if you use them as loadable kernel modules.
-
-Note 1:
- using these drivers with the "kerneld" automatic module loading
- system is not recommended for beginners, and is not documented here.
-
-Note 2:
- if you build PARPORT support as a loadable module, PARIDE must
- also be built as loadable modules, and PARPORT must be loaded before
- the PARIDE modules.
-
-To use PARIDE, you must begin by::
-
- insmod paride
-
-this loads a base module which provides a registry for the protocols,
-among other tasks.
-
-Then, load as many of the protocol modules as you think you might need.
-As you load each module, it will register the protocols that it supports,
-and print a log message to your kernel log file and your console. For
-example::
-
- # insmod epat
- paride: epat registered as protocol 0
- # insmod kbic
- paride: k951 registered as protocol 1
- paride: k971 registered as protocol 2
-
-Finally, you can load high-level drivers for each kind of device that
-you have connected. By default, each driver will autoprobe for a single
-device, but you can support up to four similar devices by giving their
-individual coordinates when you load the driver.
-
-For example, if you had two no-name CD-ROM drives both using the
-KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc
-you could give the following command::
-
- # insmod pcd drive0=0x378,1 drive1=0x3bc,1
-
-For most adapters, giving a port address and protocol number is sufficient,
-but check the source files in linux/drivers/block/paride for more
-information. (Hopefully someone will write some man pages one day !).
-
-As another example, here's what happens when PARPORT is installed, and
-a SyQuest EZ-135 is attached to port 0x378::
-
- # insmod paride
- paride: version 1.0 installed
- # insmod epat
- paride: epat registered as protocol 0
- # insmod pd
- pd: pd version 1.0, major 45, cluster 64, nice 0
- pda: Sharing parport1 at 0x378
- pda: epat 1.0, Shuttle EPAT chip c3 at 0x378, mode 5 (EPP-32), delay 1
- pda: SyQuest EZ135A, 262144 blocks [128M], (512/16/32), removable media
- pda: pda1
-
-Note that the last line is the output from the generic partition table
-scanner - in this case it reports that it has found a disk with one partition.
-
-2.3 Using a PARIDE device
---------------------------
-
-Once the drivers have been loaded, you can access PARIDE devices in the
-same way as their traditional counterparts. You will probably need to
-create the device "special files". Here is a simple script that you can
-cut to a file and execute::
-
- #!/bin/bash
- #
- # mkd -- a script to create the device special files for the PARIDE subsystem
- #
- function mkdev {
- mknod $1 $2 $3 $4 ; chmod 0660 $1 ; chown root:disk $1
- }
- #
- function pd {
- D=$( printf \\$( printf "x%03x" $[ $1 + 97 ] ) )
- mkdev pd$D b 45 $[ $1 * 16 ]
- for P in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
- do mkdev pd$D$P b 45 $[ $1 * 16 + $P ]
- done
- }
- #
- cd /dev
- #
- for u in 0 1 2 3 ; do pd $u ; done
- for u in 0 1 2 3 ; do mkdev pcd$u b 46 $u ; done
- for u in 0 1 2 3 ; do mkdev pf$u b 47 $u ; done
- for u in 0 1 2 3 ; do mkdev pt$u c 96 $u ; done
- for u in 0 1 2 3 ; do mkdev npt$u c 96 $[ $u + 128 ] ; done
- for u in 0 1 2 3 ; do mkdev pg$u c 97 $u ; done
- #
- # end of mkd
-
-With the device files and drivers in place, you can access PARIDE devices
-like any other Linux device. For example, to mount a CD-ROM in pcd0, use::
-
- mount /dev/pcd0 /cdrom
-
-If you have a fresh Avatar Shark cartridge, and the drive is pda, you
-might do something like::
-
- fdisk /dev/pda -- make a new partition table with
- partition 1 of type 83
-
- mke2fs /dev/pda1 -- to build the file system
-
- mkdir /shark -- make a place to mount the disk
-
- mount /dev/pda1 /shark
-
-Devices like the Imation superdisk work in the same way, except that
-they do not have a partition table. For example to make a 120MB
-floppy that you could share with a DOS system::
-
- mkdosfs /dev/pf0
- mount /dev/pf0 /mnt
-
-
-2.4 The pf driver
-------------------
-
-The pf driver is intended for use with parallel port ATAPI disk
-devices. The most common devices in this category are PD drives
-and LS-120 drives. Traditionally, media for these devices are not
-partitioned. Consequently, the pf driver does not support partitioned
-media. This may be changed in a future version of the driver.
-
-2.5 Using the pt driver
-------------------------
-
-The pt driver for parallel port ATAPI tape drives is a minimal driver.
-It does not yet support many of the standard tape ioctl operations.
-For best performance, a block size of 32KB should be used. You will
-probably want to set the parallel port delay to 0, if you can.
-
-2.6 Using the pg driver
-------------------------
-
-The pg driver can be used in conjunction with the cdrecord program
-to create CD-ROMs. Please get cdrecord version 1.6.1 or later
-from ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/ . To record CD-R media
-your parallel port should ideally be set to EPP mode, and the "port delay"
-should be set to 0. With those settings it is possible to record at 2x
-speed without any buffer underruns. If you cannot get the driver to work
-in EPP mode, try to use "bidirectional" or "PS/2" mode and 1x speeds only.
+If you omit the parameters from the end, defaults will be used, e.g.:
+
+Probe all parports with all protocols::
+
+ # echo auto >/sys/bus/pata_parport/new_device
+
+Probe parport0 using protocol epat and mode 4 (EPP-16)::
+
+ # echo "parport0 epat 4" >/sys/bus/pata_parport/new_device
+
+Probe parport0 using all protocols::
+
+ # echo "parport0 auto" >/sys/bus/pata_parport/new_device
+
+Probe all parports using protoocol epat::
+
+ # echo "auto epat" >/sys/bus/pata_parport/new_device
+
+Deleting devices::
+
+ # echo pata_parport.0 >/sys/bus/pata_parport/delete_device
3. Troubleshooting
@@ -344,9 +169,9 @@ in EPP mode, try to use "bidirectional" or "PS/2" mode and 1x speeds only.
3.1 Use EPP mode if you can
----------------------------
-The most common problems that people report with the PARIDE drivers
+The most common problems that people report with the pata_parport drivers
concern the parallel port CMOS settings. At this time, none of the
-PARIDE protocol modules support ECP mode, or any ECP combination modes.
+protocol modules support ECP mode, or any ECP combination modes.
If you are able to do so, please set your parallel port into EPP mode
using your CMOS setup procedure.
@@ -354,17 +179,14 @@ using your CMOS setup procedure.
-------------------------
Some parallel ports cannot reliably transfer data at full speed. To
-offset the errors, the PARIDE protocol modules introduce a "port
+offset the errors, the protocol modules introduce a "port
delay" between each access to the i/o ports. Each protocol sets
a default value for this delay. In most cases, the user can override
the default and set it to 0 - resulting in somewhat higher transfer
rates. In some rare cases (especially with older 486 systems) the
default delays are not long enough. if you experience corrupt data
transfers, or unexpected failures, you may wish to increase the
-port delay. The delay can be programmed using the "driveN" parameters
-to each of the high-level drivers. Please see the notes above, or
-read the comments at the beginning of the driver source files in
-linux/drivers/block/paride.
+port delay.
3.3 Some drives need a printer reset
-------------------------------------
@@ -374,66 +196,12 @@ that do not always power up correctly. We have noticed this with some
drives based on OnSpec and older Freecom adapters. In these rare cases,
the adapter can often be reinitialised by issuing a "printer reset" on
the parallel port. As the reset operation is potentially disruptive in
-multiple device environments, the PARIDE drivers will not do it
+multiple device environments, the pata_parport drivers will not do it
automatically. You can however, force a printer reset by doing::
insmod lp reset=1
rmmod lp
If you have one of these marginal cases, you should probably build
-your paride drivers as modules, and arrange to do the printer reset
-before loading the PARIDE drivers.
-
-3.4 Use the verbose option and dmesg if you need help
-------------------------------------------------------
-
-While a lot of testing has gone into these drivers to make them work
-as smoothly as possible, problems will arise. If you do have problems,
-please check all the obvious things first: does the drive work in
-DOS with the manufacturer's drivers ? If that doesn't yield any useful
-clues, then please make sure that only one drive is hooked to your system,
-and that either (a) PARPORT is enabled or (b) no other device driver
-is using your parallel port (check in /proc/ioports). Then, load the
-appropriate drivers (you can load several protocol modules if you want)
-as in::
-
- # insmod paride
- # insmod epat
- # insmod bpck
- # insmod kbic
- ...
- # insmod pd verbose=1
-
-(using the correct driver for the type of device you have, of course).
-The verbose=1 parameter will cause the drivers to log a trace of their
-activity as they attempt to locate your drive.
-
-Use 'dmesg' to capture a log of all the PARIDE messages (any messages
-beginning with paride:, a protocol module's name or a driver's name) and
-include that with your bug report. You can submit a bug report in one
-of two ways. Either send it directly to the author of the PARIDE suite,
-by e-mail to grant@torque.net, or join the linux-parport mailing list
-and post your report there.
-
-3.5 For more information or help
----------------------------------
-
-You can join the linux-parport mailing list by sending a mail message
-to:
-
- linux-parport-request@torque.net
-
-with the single word::
-
- subscribe
-
-in the body of the mail message (not in the subject line). Please be
-sure that your mail program is correctly set up when you do this, as
-the list manager is a robot that will subscribe you using the reply
-address in your mail headers. REMOVE any anti-spam gimmicks you may
-have in your mail headers, when sending mail to the list server.
-
-You might also find some useful information on the linux-parport
-web pages (although they are not always up to date) at
-
- http://web.archive.org/web/%2E/http://www.torque.net/parport/
+your pata_parport drivers as modules, and arrange to do the printer reset
+before loading the pata_parport drivers.
diff --git a/Documentation/admin-guide/blockdev/zoned_loop.rst b/Documentation/admin-guide/blockdev/zoned_loop.rst
new file mode 100644
index 000000000000..806adde664db
--- /dev/null
+++ b/Documentation/admin-guide/blockdev/zoned_loop.rst
@@ -0,0 +1,182 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+Zoned Loop Block Device
+=======================
+
+.. Contents:
+
+ 1) Overview
+ 2) Creating a Zoned Device
+ 3) Deleting a Zoned Device
+ 4) Example
+
+
+1) Overview
+-----------
+
+The zoned loop block device driver (zloop) allows a user to create a zoned block
+device using one regular file per zone as backing storage. This driver does not
+directly control any hardware and uses read, write and truncate operations to
+regular files of a file system to emulate a zoned block device.
+
+Using zloop, zoned block devices with a configurable capacity, zone size and
+number of conventional zones can be created. The storage for each zone of the
+device is implemented using a regular file with a maximum size equal to the zone
+size. The size of a file backing a conventional zone is always equal to the zone
+size. The size of a file backing a sequential zone indicates the amount of data
+sequentially written to the file, that is, the size of the file directly
+indicates the position of the write pointer of the zone.
+
+When resetting a sequential zone, its backing file size is truncated to zero.
+Conversely, for a zone finish operation, the backing file is truncated to the
+zone size. With this, the maximum capacity of a zloop zoned block device created
+can be larger configured to be larger than the storage space available on the
+backing file system. Of course, for such configuration, writing more data than
+the storage space available on the backing file system will result in write
+errors.
+
+The zoned loop block device driver implements a complete zone transition state
+machine. That is, zones can be empty, implicitly opened, explicitly opened,
+closed or full. The current implementation does not support any limits on the
+maximum number of open and active zones.
+
+No user tools are necessary to create and delete zloop devices.
+
+2) Creating a Zoned Device
+--------------------------
+
+Once the zloop module is loaded (or if zloop is compiled in the kernel), the
+character device file /dev/zloop-control can be used to add a zloop device.
+This is done by writing an "add" command directly to the /dev/zloop-control
+device::
+
+ $ modprobe zloop
+ $ ls -l /dev/zloop*
+ crw-------. 1 root root 10, 123 Jan 6 19:18 /dev/zloop-control
+
+ $ mkdir -p <base directory/<device ID>
+ $ echo "add [options]" > /dev/zloop-control
+
+The options available for the add command can be listed by reading the
+/dev/zloop-control device::
+
+ $ cat /dev/zloop-control
+ add id=%d,capacity_mb=%u,zone_size_mb=%u,zone_capacity_mb=%u,conv_zones=%u,base_dir=%s,nr_queues=%u,queue_depth=%u,buffered_io
+ remove id=%d
+
+In more details, the options that can be used with the "add" command are as
+follows.
+
+=================== =========================================================
+id Device number (the X in /dev/zloopX).
+ Default: automatically assigned.
+capacity_mb Device total capacity in MiB. This is always rounded up
+ to the nearest higher multiple of the zone size.
+ Default: 16384 MiB (16 GiB).
+zone_size_mb Device zone size in MiB. Default: 256 MiB.
+zone_capacity_mb Device zone capacity (must always be equal to or lower
+ than the zone size. Default: zone size.
+conv_zones Total number of conventioanl zones starting from
+ sector 0
+ Default: 8
+base_dir Path to the base directory where to create the directory
+ containing the zone files of the device.
+ Default=/var/local/zloop.
+ The device directory containing the zone files is always
+ named with the device ID. E.g. the default zone file
+ directory for /dev/zloop0 is /var/local/zloop/0.
+nr_queues Number of I/O queues of the zoned block device. This
+ value is always capped by the number of online CPUs
+ Default: 1
+queue_depth Maximum I/O queue depth per I/O queue.
+ Default: 64
+buffered_io Do buffered IOs instead of direct IOs (default: false)
+zone_append Enable or disable a zloop device native zone append
+ support.
+ Default: 1 (enabled).
+ If native zone append support is disabled, the block layer
+ will emulate this operation using regular write
+ operations.
+ordered_zone_append Enable zloop mitigation of zone append reordering.
+ Default: disabled.
+ This is useful for testing file systems file data mapping
+ (extents), as when enabled, this can significantly reduce
+ the number of data extents needed to for a file data
+ mapping.
+=================== =========================================================
+
+3) Deleting a Zoned Device
+--------------------------
+
+Deleting an unused zoned loop block device is done by issuing the "remove"
+command to /dev/zloop-control, specifying the ID of the device to remove::
+
+ $ echo "remove id=X" > /dev/zloop-control
+
+The remove command does not have any option.
+
+A zoned device that was removed can be re-added again without any change to the
+state of the device zones: the device zones are restored to their last state
+before the device was removed. Adding again a zoned device after it was removed
+must always be done using the same configuration as when the device was first
+added. If a zone configuration change is detected, an error will be returned and
+the zoned device will not be created.
+
+To fully delete a zoned device, after executing the remove operation, the device
+base directory containing the backing files of the device zones must be deleted.
+
+4) Example
+----------
+
+The following sequence of commands creates a 2GB zoned device with zones of 64
+MB and a zone capacity of 63 MB::
+
+ $ modprobe zloop
+ $ mkdir -p /var/local/zloop/0
+ $ echo "add capacity_mb=2048,zone_size_mb=64,zone_capacity=63MB" > /dev/zloop-control
+
+For the device created (/dev/zloop0), the zone backing files are all created
+under the default base directory (/var/local/zloop)::
+
+ $ ls -l /var/local/zloop/0
+ total 0
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000000
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000001
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000002
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000003
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000004
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000005
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000006
+ -rw-------. 1 root root 67108864 Jan 6 22:23 cnv-000007
+ -rw-------. 1 root root 0 Jan 6 22:23 seq-000008
+ -rw-------. 1 root root 0 Jan 6 22:23 seq-000009
+ ...
+
+The zoned device created (/dev/zloop0) can then be used normally::
+
+ $ lsblk -z
+ NAME ZONED ZONE-SZ ZONE-NR ZONE-AMAX ZONE-OMAX ZONE-APP ZONE-WGRAN
+ zloop0 host-managed 64M 32 0 0 1M 4K
+ $ blkzone report /dev/zloop0
+ start: 0x000000000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x000020000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x000040000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x000060000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x000080000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x0000a0000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x0000c0000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x0000e0000, len 0x020000, cap 0x020000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
+ start: 0x000100000, len 0x020000, cap 0x01f800, wptr 0x000000 reset:0 non-seq:0, zcond: 1(em) [type: 2(SEQ_WRITE_REQUIRED)]
+ start: 0x000120000, len 0x020000, cap 0x01f800, wptr 0x000000 reset:0 non-seq:0, zcond: 1(em) [type: 2(SEQ_WRITE_REQUIRED)]
+ ...
+
+Deleting this device is done using the command::
+
+ $ echo "remove id=0" > /dev/zloop-control
+
+The removed device can be re-added again using the same "add" command as when
+the device was first created. To fully delete a zoned device, its backing files
+should also be deleted after executing the remove command::
+
+ $ rm -r /var/local/zloop/0
diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst
index c73b16930449..3e273c1bb749 100644
--- a/Documentation/admin-guide/blockdev/zram.rst
+++ b/Documentation/admin-guide/blockdev/zram.rst
@@ -47,12 +47,14 @@ The list of possible return codes:
-ENOMEM zram was not able to allocate enough memory to fulfil your
needs.
-EINVAL invalid input has been provided.
+-EAGAIN re-try operation later (e.g. when attempting to run recompress
+ and writeback simultaneously).
======== =============================================================
If you use 'echo', the returned value is set by the 'echo' utility,
and, in general case, something like::
- echo 3 > /sys/block/zram0/max_comp_streams
+ echo foo > /sys/block/zram0/comp_algorithm
if [ $? -ne 0 ]; then
handle_error
fi
@@ -71,21 +73,7 @@ This creates 4 devices: /dev/zram{0,1,2,3}
num_devices parameter is optional and tells zram how many devices should be
pre-created. Default: 1.
-2) Set max number of compression streams
-========================================
-
-Regardless of the value passed to this attribute, ZRAM will always
-allocate multiple compression streams - one per online CPU - thus
-allowing several concurrent compression operations. The number of
-allocated compression streams goes down when some of the CPUs
-become offline. There is no single-compression-stream mode anymore,
-unless you are running a UP system or have only 1 CPU online.
-
-To find out how many streams are currently available::
-
- cat /sys/block/zram0/max_comp_streams
-
-3) Select compression algorithm
+2) Select compression algorithm
===============================
Using comp_algorithm device attribute one can see available and
@@ -102,15 +90,39 @@ Examples::
#select lzo compression algorithm
echo lzo > /sys/block/zram0/comp_algorithm
-For the time being, the `comp_algorithm` content does not necessarily
-show every compression algorithm supported by the kernel. We keep this
-list primarily to simplify device configuration and one can configure
-a new device with a compression algorithm that is not listed in
-`comp_algorithm`. The thing is that, internally, ZRAM uses Crypto API
-and, if some of the algorithms were built as modules, it's impossible
-to list all of them using, for instance, /proc/crypto or any other
-method. This, however, has an advantage of permitting the usage of
-custom crypto compression modules (implementing S/W or H/W compression).
+For the time being, the `comp_algorithm` content shows only compression
+algorithms that are supported by zram.
+
+3) Set compression algorithm parameters: Optional
+=================================================
+
+Compression algorithms may support specific parameters which can be
+tweaked for particular dataset. ZRAM has an `algorithm_params` device
+attribute which provides a per-algorithm params configuration.
+
+For example, several compression algorithms support `level` parameter.
+In addition, certain compression algorithms support pre-trained dictionaries,
+which significantly change algorithms' characteristics. In order to configure
+compression algorithm to use external pre-trained dictionary, pass full
+path to the `dict` along with other parameters::
+
+ #pass path to pre-trained zstd dictionary
+ echo "algo=zstd dict=/etc/dictionary" > /sys/block/zram0/algorithm_params
+
+ #same, but using algorithm priority
+ echo "priority=1 dict=/etc/dictionary" > \
+ /sys/block/zram0/algorithm_params
+
+ #pass path to pre-trained zstd dictionary and compression level
+ echo "algo=zstd level=8 dict=/etc/dictionary" > \
+ /sys/block/zram0/algorithm_params
+
+Parameters are algorithm specific: not all algorithms support pre-trained
+dictionaries, not all algorithms support `level`. Furthermore, for certain
+algorithms `level` controls the compression level (the higher the value the
+better the compression ratio, it even can take negatives values for some
+algorithms), for other algorithms `level` is acceleration level (the higher
+the value the lower the compression ratio).
4) Set Disksize
===============
@@ -202,9 +214,8 @@ mem_limit WO specifies the maximum amount of memory ZRAM can
writeback_limit WO specifies the maximum amount of write IO zram
can write out to backing device as 4KB unit
writeback_limit_enable RW show and set writeback_limit feature
-max_comp_streams RW the number of possible concurrent compress
- operations
comp_algorithm RW show and change the compression algorithm
+algorithm_params WO setup compression algorithm parameters
compact WO trigger memory compaction
debug_stat RO this file is used for zram debugging purposes
backing_dev RW set up backend storage for zram to write out
@@ -284,7 +295,7 @@ a single line of text and contains the following stats separated by whitespace:
============== =============================================================
9) Deactivate
-=============
+==============
::
@@ -306,6 +317,26 @@ a single line of text and contains the following stats separated by whitespace:
Optional Feature
================
+IDLE pages tracking
+-------------------
+
+zram has built-in support for idle pages tracking (that is, allocated but
+not used pages). This feature is useful for e.g. zram writeback and
+recompression. In order to mark pages as idle, execute the following command::
+
+ echo all > /sys/block/zramX/idle
+
+This will mark all allocated zram pages as idle. The idle mark will be
+removed only when the page (block) is accessed (e.g. overwritten or freed).
+Additionally, when CONFIG_ZRAM_TRACK_ENTRY_ACTIME is enabled, pages can be
+marked as idle based on how many seconds have passed since the last access to
+a particular zram page::
+
+ echo 86400 > /sys/block/zramX/idle
+
+In this example, all pages which haven't been accessed in more than 86400
+seconds (one day) will be marked idle.
+
writeback
---------
@@ -320,24 +351,7 @@ If admin wants to use incompressible page writeback, they could do it via::
echo huge > /sys/block/zramX/writeback
-To use idle page writeback, first, user need to declare zram pages
-as idle::
-
- echo all > /sys/block/zramX/idle
-
-From now on, any pages on zram are idle pages. The idle mark
-will be removed until someone requests access of the block.
-IOW, unless there is access request, those pages are still idle pages.
-Additionally, when CONFIG_ZRAM_MEMORY_TRACKING is enabled pages can be
-marked as idle based on how long (in seconds) it's been since they were
-last accessed::
-
- echo 86400 > /sys/block/zramX/idle
-
-In this example all pages which haven't been accessed in more than 86400
-seconds (one day) will be marked idle.
-
-Admin can request writeback of those idle pages at right timing via::
+Admin can request writeback of idle pages at right timing via::
echo idle > /sys/block/zramX/writeback
@@ -348,11 +362,33 @@ this can be accomplished with::
echo huge_idle > /sys/block/zramX/writeback
+If a user chooses to writeback only incompressible pages (pages that none of
+algorithms can compress) this can be accomplished with::
+
+ echo incompressible > /sys/block/zramX/writeback
+
If an admin wants to write a specific page in zram device to the backing device,
-they could write a page index into the interface.
+they could write a page index into the interface::
echo "page_index=1251" > /sys/block/zramX/writeback
+In Linux 6.16 this interface underwent some rework. First, the interface
+now supports `key=value` format for all of its parameters (`type=huge_idle`,
+etc.) Second, the support for `page_indexes` was introduced, which specify
+`LOW-HIGH` range (or ranges) of pages to be written-back. This reduces the
+number of syscalls, but more importantly this enables optimal post-processing
+target selection strategy. Usage example::
+
+ echo "type=idle" > /sys/block/zramX/writeback
+ echo "page_indexes=1-100 page_indexes=200-300" > \
+ /sys/block/zramX/writeback
+
+We also now permit multiple page_index params per call and a mix of
+single pages and page ranges::
+
+ echo page_index=42 page_index=99 page_indexes=100-200 \
+ page_indexes=500-700 > /sys/block/zramX/writeback
+
If there are lots of write IO with flash device, potentially, it has
flash wearout problem so that admin needs to design write limitation
to guarantee storage health for entire product life.
@@ -401,6 +437,93 @@ budget in next setting is user's job.
If admin wants to measure writeback count in a certain period, they could
know it via /sys/block/zram0/bd_stat's 3rd column.
+recompression
+-------------
+
+With CONFIG_ZRAM_MULTI_COMP, zram can recompress pages using alternative
+(secondary) compression algorithms. The basic idea is that alternative
+compression algorithm can provide better compression ratio at a price of
+(potentially) slower compression/decompression speeds. Alternative compression
+algorithm can, for example, be more successful compressing huge pages (those
+that default algorithm failed to compress). Another application is idle pages
+recompression - pages that are cold and sit in the memory can be recompressed
+using more effective algorithm and, hence, reduce zsmalloc memory usage.
+
+With CONFIG_ZRAM_MULTI_COMP, zram supports up to 4 compression algorithms:
+one primary and up to 3 secondary ones. Primary zram compressor is explained
+in "3) Select compression algorithm", secondary algorithms are configured
+using recomp_algorithm device attribute.
+
+Example:::
+
+ #show supported recompression algorithms
+ cat /sys/block/zramX/recomp_algorithm
+ #1: lzo lzo-rle lz4 lz4hc [zstd]
+ #2: lzo lzo-rle lz4 [lz4hc] zstd
+
+Alternative compression algorithms are sorted by priority. In the example
+above, zstd is used as the first alternative algorithm, which has priority
+of 1, while lz4hc is configured as a compression algorithm with priority 2.
+Alternative compression algorithm's priority is provided during algorithms
+configuration:::
+
+ #select zstd recompression algorithm, priority 1
+ echo "algo=zstd priority=1" > /sys/block/zramX/recomp_algorithm
+
+ #select deflate recompression algorithm, priority 2
+ echo "algo=deflate priority=2" > /sys/block/zramX/recomp_algorithm
+
+Another device attribute that CONFIG_ZRAM_MULTI_COMP enables is recompress,
+which controls recompression.
+
+Examples:::
+
+ #IDLE pages recompression is activated by `idle` mode
+ echo "type=idle" > /sys/block/zramX/recompress
+
+ #HUGE pages recompression is activated by `huge` mode
+ echo "type=huge" > /sys/block/zram0/recompress
+
+ #HUGE_IDLE pages recompression is activated by `huge_idle` mode
+ echo "type=huge_idle" > /sys/block/zramX/recompress
+
+The number of idle pages can be significant, so user-space can pass a size
+threshold (in bytes) to the recompress knob: zram will recompress only pages
+of equal or greater size:::
+
+ #recompress all pages larger than 3000 bytes
+ echo "threshold=3000" > /sys/block/zramX/recompress
+
+ #recompress idle pages larger than 2000 bytes
+ echo "type=idle threshold=2000" > /sys/block/zramX/recompress
+
+It is also possible to limit the number of pages zram re-compression will
+attempt to recompress:::
+
+ echo "type=huge_idle max_pages=42" > /sys/block/zramX/recompress
+
+During re-compression for every page, that matches re-compression criteria,
+ZRAM iterates the list of registered alternative compression algorithms in
+order of their priorities. ZRAM stops either when re-compression was
+successful (re-compressed object is smaller in size than the original one)
+and matches re-compression criteria (e.g. size threshold) or when there are
+no secondary algorithms left to try. If none of the secondary algorithms can
+successfully re-compressed the page such a page is marked as incompressible,
+so ZRAM will not attempt to re-compress it in the future.
+
+This re-compression behaviour, when it iterates through the list of
+registered compression algorithms, increases our chances of finding the
+algorithm that successfully compresses a particular page. Sometimes, however,
+it is convenient (and sometimes even necessary) to limit recompression to
+only one particular algorithm so that it will not try any other algorithms.
+This can be achieved by providing a `algo` or `priority` parameter:::
+
+ #use zstd algorithm only (if registered)
+ echo "type=huge algo=zstd" > /sys/block/zramX/recompress
+
+ #use zstd algorithm only (if zstd was registered under priority 1)
+ echo "type=huge priority=1" > /sys/block/zramX/recompress
+
memory tracking
===============
@@ -411,9 +534,11 @@ pages of the process with*pagemap.
If you enable the feature, you could see block state via
/sys/kernel/debug/zram/zram0/block_state". The output is as follows::
- 300 75.033841 .wh.
- 301 63.806904 s...
- 302 63.806919 ..hi
+ 300 75.033841 .wh...
+ 301 63.806904 s.....
+ 302 63.806919 ..hi..
+ 303 62.801919 ....r.
+ 304 146.781902 ..hi.n
First column
zram's block index.
@@ -430,6 +555,10 @@ Third column
huge page
i:
idle page
+ r:
+ recompressed page (secondary compression algorithm)
+ n:
+ none (including secondary) of algorithms could compress it
First line of above example says 300th block is accessed at 75.033841sec
and the block's state is huge so it is written back to the backing
diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst
index d99994345d41..7a86042c9b6d 100644
--- a/Documentation/admin-guide/bootconfig.rst
+++ b/Documentation/admin-guide/bootconfig.rst
@@ -201,6 +201,8 @@ To remove the config from the image, you can use -d option as below::
Then add "bootconfig" on the normal kernel command line to tell the
kernel to look for the bootconfig at the end of the initrd file.
+Alternatively, build your kernel with the ``CONFIG_BOOT_CONFIG_FORCE``
+Kconfig option selected.
Embedding a Boot Config into Kernel
-----------------------------------
@@ -217,7 +219,9 @@ path to the bootconfig file from source tree or object tree.
The kernel will embed it as the default bootconfig.
Just as when attaching the bootconfig to the initrd, you need ``bootconfig``
-option on the kernel command line to enable the embedded bootconfig.
+option on the kernel command line to enable the embedded bootconfig, or,
+alternatively, build your kernel with the ``CONFIG_BOOT_CONFIG_FORCE``
+Kconfig option selected.
Note that even if you set this option, you can override the embedded
bootconfig by another bootconfig which attached to the initrd.
@@ -229,7 +233,7 @@ In addition to the kernel command line, the boot config can be used for
passing the kernel parameters. All the key-value pairs under ``kernel``
key will be passed to kernel cmdline directly. Moreover, the key-value
pairs under ``init`` will be passed to init process via the cmdline.
-The parameters are concatinated with user-given kernel cmdline string
+The parameters are concatenated with user-given kernel cmdline string
as the following order, so that the command line parameter can override
bootconfig parameters (this depends on how the subsystem handles parameters
but in general, earlier parameter will be overwritten by later one.)::
@@ -261,7 +265,7 @@ The final kernel cmdline will be the following::
Config File Limitation
======================
-Currently the maximum config size size is 32KB and the total key-words (not
+Currently the maximum config size is 32KB and the total key-words (not
key-value entries) must be under 1024 nodes.
Note: this is not the number of entries but nodes, an entry must consume
more than 2 nodes (a key-word and a value). So theoretically, it will be
diff --git a/Documentation/admin-guide/braille-console.rst b/Documentation/admin-guide/braille-console.rst
index 18e79337dcfd..153472e93cae 100644
--- a/Documentation/admin-guide/braille-console.rst
+++ b/Documentation/admin-guide/braille-console.rst
@@ -21,8 +21,8 @@ override the baud rate to 115200, etc.
By default, the braille device will just show the last kernel message (console
mode). To review previous messages, press the Insert key to switch to the VT
review mode. In review mode, the arrow keys permit to browse in the VT content,
-:kbd:`PAGE-UP`/:kbd:`PAGE-DOWN` keys go at the top/bottom of the screen, and
-the :kbd:`HOME` key goes back
+`PAGE-UP`/`PAGE-DOWN` keys go at the top/bottom of the screen, and
+the `HOME` key goes back
to the cursor, hence providing very basic screen reviewing facility.
Sound feedback can be obtained by adding the ``braille_console.sound=1`` kernel
diff --git a/Documentation/admin-guide/bug-bisect.rst b/Documentation/admin-guide/bug-bisect.rst
index 325c5d0ed34a..f4f867cabb17 100644
--- a/Documentation/admin-guide/bug-bisect.rst
+++ b/Documentation/admin-guide/bug-bisect.rst
@@ -1,76 +1,165 @@
-Bisecting a bug
-+++++++++++++++
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. [see the bottom of this file for redistribution information]
-Last updated: 28 October 2016
+======================
+Bisecting a regression
+======================
-Introduction
-============
+This document describes how to use a ``git bisect`` to find the source code
+change that broke something -- for example when some functionality stopped
+working after upgrading from Linux 6.0 to 6.1.
-Always try the latest kernel from kernel.org and build from source. If you are
-not confident in doing that please report the bug to your distribution vendor
-instead of to a kernel developer.
+The text focuses on the gist of the process. If you are new to bisecting the
+kernel, better follow Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
+instead: it depicts everything from start to finish while covering multiple
+aspects even kernel developers occasionally forget. This includes detecting
+situations early where a bisection would be a waste of time, as nobody would
+care about the result -- for example, because the problem happens after the
+kernel marked itself as 'tainted', occurs in an abandoned version, was already
+fixed, or is caused by a .config change you or your Linux distributor performed.
-Finding bugs is not always easy. Have a go though. If you can't find it don't
-give up. Report as much as you have found to the relevant maintainer. See
-MAINTAINERS for who that is for the subsystem you have worked on.
+Finding the change causing a kernel issue using a bisection
+===========================================================
-Before you submit a bug report read
-'Documentation/admin-guide/reporting-issues.rst'.
+*Note: the following process assumes you prepared everything for a bisection.
+This includes having a Git clone with the appropriate sources, installing the
+software required to build and install kernels, as well as a .config file stored
+in a safe place (the following example assumes '~/prepared_kernel_.config') to
+use as pristine base at each bisection step; ideally, you have also worked out
+a fully reliable and straight-forward way to reproduce the regression, too.*
-Devices not appearing
-=====================
+* Preparation: start the bisection and tell Git about the points in the history
+ you consider to be working and broken, which Git calls 'good' and 'bad'::
-Often this is caused by udev/systemd. Check that first before blaming it
-on the kernel.
+ git bisect start
+ git bisect good v6.0
+ git bisect bad v6.1
-Finding patch that caused a bug
-===============================
+ Instead of Git tags like 'v6.0' and 'v6.1' you can specify commit-ids, too.
-Using the provided tools with ``git`` makes finding bugs easy provided the bug
-is reproducible.
+1. Copy your prepared .config into the build directory and adjust it to the
+ needs of the codebase Git checked out for testing::
-Steps to do it:
+ cp ~/prepared_kernel_.config .config
+ make olddefconfig
-- build the Kernel from its git source
-- start bisect with [#f1]_::
-
- $ git bisect start
-
-- mark the broken changeset with::
-
- $ git bisect bad [commit]
-
-- mark a changeset where the code is known to work with::
-
- $ git bisect good [commit]
-
-- rebuild the Kernel and test
-- interact with git bisect by using either::
-
- $ git bisect good
-
- or::
-
- $ git bisect bad
-
- depending if the bug happened on the changeset you're testing
-- After some interactions, git bisect will give you the changeset that
- likely caused the bug.
-
-- For example, if you know that the current version is bad, and version
- 4.8 is good, you could do::
-
- $ git bisect start
- $ git bisect bad # Current version is bad
- $ git bisect good v4.8
-
-
-.. [#f1] You can, optionally, provide both good and bad arguments at git
- start with ``git bisect start [BAD] [GOOD]``
-
-For further references, please read:
-
-- The man page for ``git-bisect``
-- `Fighting regressions with git bisect <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_
-- `Fully automated bisecting with "git bisect run" <https://lwn.net/Articles/317154>`_
-- `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_
+2. Now build, install, and boot a kernel. This might fail for unrelated reasons,
+ for example, when a compile error happens at the current stage of the
+ bisection a later change resolves. In such cases run ``git bisect skip`` and
+ go back to step 1.
+
+3. Check if the functionality that regressed works in the kernel you just built.
+
+ If it works, execute::
+
+ git bisect good
+
+ If it is broken, run::
+
+ git bisect bad
+
+ Note, getting this wrong just once will send the rest of the bisection
+ totally off course. To prevent having to start anew later you thus want to
+ ensure what you tell Git is correct; it is thus often wise to spend a few
+ minutes more on testing in case your reproducer is unreliable.
+
+ After issuing one of these two commands, Git will usually check out another
+ bisection point and print something like 'Bisecting: 675 revisions left to
+ test after this (roughly 10 steps)'. In that case go back to step 1.
+
+ If Git instead prints something like 'cafecaca0c0dacafecaca0c0dacafecaca0c0da
+ is the first bad commit', then you have finished the bisection. In that case
+ move to the next point below. Note, right after displaying that line Git will
+ show some details about the culprit including its patch description; this can
+ easily fill your terminal, so you might need to scroll up to see the message
+ mentioning the culprit's commit-id.
+
+ In case you missed Git's output, you can always run ``git bisect log`` to
+ print the status: it will show how many steps remain or mention the result of
+ the bisection.
+
+* Recommended complementary task: put the bisection log and the current .config
+ file aside for the bug report; furthermore tell Git to reset the sources to
+ the state before the bisection::
+
+ git bisect log > ~/bisection-log
+ cp .config ~/bisection-config-culprit
+ git bisect reset
+
+* Recommended optional task: try reverting the culprit on top of the latest
+ codebase and check if that fixes your bug; if that is the case, it validates
+ the bisection and enables developers to resolve the regression through a
+ revert.
+
+ To try this, update your clone and check out latest mainline. Then tell Git
+ to revert the change by specifying its commit-id::
+
+ git revert --no-edit cafec0cacaca0
+
+ Git might reject this, for example when the bisection landed on a merge
+ commit. In that case, abandon the attempt. Do the same, if Git fails to revert
+ the culprit on its own because later changes depend on it -- at least unless
+ you bisected a stable or longterm kernel series, in which case you want to
+ check out its latest codebase and try a revert there.
+
+ If a revert succeeds, build and test another kernel to check if reverting
+ resolved your regression.
+
+With that the process is complete. Now report the regression as described by
+Documentation/admin-guide/reporting-issues.rst.
+
+Bisecting linux-next
+--------------------
+
+If you face a problem only happening in linux-next, bisect between the
+linux-next branches 'stable' and 'master'. The following commands will start
+the process for a linux-next tree you added as a remote called 'next'::
+
+ git bisect start
+ git bisect good next/stable
+ git bisect bad next/master
+
+The 'stable' branch refers to the state of linux-mainline that the current
+linux-next release (found in the 'master' branch) is based on -- the former
+thus should be free of any problems that show up in -next, but not in Linus'
+tree.
+
+This will bisect across a wide range of changes, some of which you might have
+used in earlier linux-next releases without problems. Sadly there is no simple
+way to avoid checking them: bisecting from one linux-next release to a later
+one (say between 'next-20241020' and 'next-20241021') is impossible, as they
+share no common history.
+
+Additional reading material
+---------------------------
+
+* The `man page for 'git bisect' <https://git-scm.com/docs/git-bisect>`_ and
+ `fighting regressions with 'git bisect' <https://git-scm.com/docs/git-bisect-lk2009.html>`_
+ in the Git documentation.
+* `Working with git bisect <https://nathanchance.dev/posts/working-with-git-bisect/>`_
+ from kernel developer Nathan Chancellor.
+* `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_.
+* `Fully automated bisecting with 'git bisect run' <https://lwn.net/Articles/317154>`_.
+
+..
+ end-of-content
+..
+ This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If
+ you spot a typo or small mistake, feel free to let him know directly and
+ he'll fix it. You are free to do the same in a mostly informal way if you
+ want to contribute changes to the text -- but for copyright reasons please CC
+ linux-doc@vger.kernel.org and 'sign-off' your contribution as
+ Documentation/process/submitting-patches.rst explains in the section 'Sign
+ your work - the Developer's Certificate of Origin'.
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use 'The Linux kernel development community' for author attribution
+ and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/bug-bisect.rst
+
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst
index 95299b08c405..7da0504388ec 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -196,7 +196,7 @@ will see the assembler code for the routine shown, but if your kernel has
debug symbols the C code will also be available. (Debug symbols can be enabled
in the kernel hacking menu of the menu configuration.) For example::
- $ objdump -r -S -l --disassemble net/dccp/ipv4.o
+ $ objdump -r -S -l --disassemble net/ipv4/tcp.o
.. note::
@@ -244,15 +244,15 @@ Reporting the bug
Once you find where the bug happened, by inspecting its location,
you could either try to fix it yourself or report it upstream.
-In order to report it upstream, you should identify the mailing list
-used for the development of the affected code. This can be done by using
-the ``get_maintainer.pl`` script.
+In order to report it upstream, you should identify the bug tracker, if any, or
+mailing list used for the development of the affected code. This can be done by
+using the ``get_maintainer.pl`` script.
For example, if you find a bug at the gspca's sonixj.c file, you can get
its maintainers with::
- $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
- Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
+ $ ./scripts/get_maintainer.pl --bug -f drivers/media/usb/gspca/sonixj.c
+ Hans Verkuil <hverkuil@kernel.org> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%)
Tejun Heo <tj@kernel.org> (commit_signer:1/1=100%)
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:4/4=100%,removed_lines:9/9=100%)
@@ -267,11 +267,12 @@ Please notice that it will point to:
- The driver maintainer (Hans Verkuil);
- The subsystem maintainer (Mauro Carvalho Chehab);
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
-- the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
+- The Linux Kernel mailing list (linux-kernel@vger.kernel.org);
+- The bug reporting URIs for the driver/subsystem (none in the above example).
-Usually, the fastest way to have your bug fixed is to report it to mailing
-list used for the development of the code (linux-media ML) copying the
-driver maintainer (Hans).
+If the listing contains bug reporting URIs at the end, please prefer them over
+email. Otherwise, please report bugs to the mailing list used for the
+development of the code (linux-media ML) copying the driver maintainer (Hans).
If you are totally stumped as to whom to send the report, and
``get_maintainer.pl`` didn't provide you anything useful, send it to
@@ -367,12 +368,3 @@ processed by ``klogd``::
Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128]
Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3
----------------------------------------------------------------------------
-
-::
-
- Dr. G.W. Wettstein Oncology Research Div. Computing Facility
- Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
- 820 4th St. N.
- Fargo, ND 58122
- Phone: 701-234-7556
diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
index 16253eda192e..dabb80cdd25a 100644
--- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
+++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst
@@ -106,7 +106,7 @@ Proportional weight policy files
see Documentation/block/bfq-iosched.rst.
blkio.bfq.weight_device
- Specifes per cgroup per device weights, overriding the default group
+ Specifies per cgroup per device weights, overriding the default group
weight. For more details, see Documentation/block/bfq-iosched.rst.
Following is the format::
diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
index b0688011ed06..463f98453323 100644
--- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
+++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
@@ -13,7 +13,7 @@ Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
-Modified by Christoph Lameter <cl@linux.com>
+Modified by Christoph Lameter <cl@gentwo.org>
.. CONTENTS:
@@ -80,6 +80,8 @@ access. For example, cpusets (see Documentation/admin-guide/cgroup-v1/cpusets.rs
you to associate a set of CPUs and a set of memory nodes with the
tasks in each cgroup.
+.. _cgroups-why-needed:
+
1.2 Why are cgroups needed ?
----------------------------
@@ -568,7 +570,7 @@ visible to cgroup_for_each_child/descendant_*() iterators. The
subsystem may choose to fail creation by returning -errno. This
callback can be used to implement reliable state sharing and
propagation along the hierarchy. See the comment on
-cgroup_for_each_descendant_pre() for details.
+cgroup_for_each_live_descendant_pre() for details.
``void css_offline(struct cgroup *cgrp);``
(cgroup_mutex held by caller)
diff --git a/Documentation/admin-guide/cgroup-v1/cpusets.rst b/Documentation/admin-guide/cgroup-v1/cpusets.rst
index 5d844ed4df69..c7909e5ac136 100644
--- a/Documentation/admin-guide/cgroup-v1/cpusets.rst
+++ b/Documentation/admin-guide/cgroup-v1/cpusets.rst
@@ -10,7 +10,7 @@ Written by Simon.Derr@bull.net
- Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
- Modified by Paul Jackson <pj@sgi.com>
-- Modified by Christoph Lameter <cl@linux.com>
+- Modified by Christoph Lameter <cl@gentwo.org>
- Modified by Paul Menage <menage@google.com>
- Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
@@ -179,7 +179,7 @@ files describing that cpuset:
- cpuset.mem_hardwall flag: is memory allocation hardwalled
- cpuset.memory_pressure: measure of how much paging pressure in cpuset
- cpuset.memory_spread_page flag: if set, spread page cache evenly on allowed nodes
- - cpuset.memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
+ - cpuset.memory_spread_slab flag: OBSOLETE. Doesn't have any function.
- cpuset.sched_load_balance flag: if set, load balance within CPUs on that cpuset
- cpuset.sched_relax_domain_level: the searching range when migrating tasks
@@ -568,7 +568,7 @@ on the next tick. For some applications in special situation, waiting
The 'cpuset.sched_relax_domain_level' file allows you to request changing
this searching range as you like. This file takes int value which
-indicates size of searching range in levels ideally as follows,
+indicates size of searching range in levels approximately as follows,
otherwise initial value -1 that indicates the cpuset has no request.
====== ===========================================================
@@ -581,6 +581,11 @@ otherwise initial value -1 that indicates the cpuset has no request.
5 search system wide [on NUMA system]
====== ===========================================================
+Not all levels can be present and values can change depending on the
+system architecture and kernel configuration. Check
+/sys/kernel/debug/sched/domains/cpu*/domain*/ for system-specific
+details.
+
The system default is architecture dependent. The system default
can be changed using the relax_domain_level= boot parameter.
@@ -719,7 +724,7 @@ There are ways to query or modify cpusets:
cat, rmdir commands from the shell, or their equivalent from C.
- via the C library libcpuset.
- via the C library libcgroup.
- (http://sourceforge.net/projects/libcg/)
+ (https://github.com/libcgroup/libcgroup/)
- via the python application cset.
(http://code.google.com/p/cpuset/)
diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
index 582d3427de3f..a964aff373b1 100644
--- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
+++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
@@ -125,3 +125,7 @@ to unfreeze all tasks in the container::
This is the basic mechanism which should do the right thing for user space task
in a simple scenario.
+
+This freezer implementation is affected by shortcomings (see commit
+76f969e8948d8 ("cgroup: cgroup v2 freezer")) and cgroup v2 freezer is
+recommended.
diff --git a/Documentation/admin-guide/cgroup-v1/hugetlb.rst b/Documentation/admin-guide/cgroup-v1/hugetlb.rst
index 0fa724d82abb..493a8e386700 100644
--- a/Documentation/admin-guide/cgroup-v1/hugetlb.rst
+++ b/Documentation/admin-guide/cgroup-v1/hugetlb.rst
@@ -65,10 +65,12 @@ files include::
1. Page fault accounting
-hugetlb.<hugepagesize>.limit_in_bytes
-hugetlb.<hugepagesize>.max_usage_in_bytes
-hugetlb.<hugepagesize>.usage_in_bytes
-hugetlb.<hugepagesize>.failcnt
+::
+
+ hugetlb.<hugepagesize>.limit_in_bytes
+ hugetlb.<hugepagesize>.max_usage_in_bytes
+ hugetlb.<hugepagesize>.usage_in_bytes
+ hugetlb.<hugepagesize>.failcnt
The HugeTLB controller allows users to limit the HugeTLB usage (page fault) per
control group and enforces the limit during page fault. Since HugeTLB
@@ -82,10 +84,12 @@ getting SIGBUS.
2. Reservation accounting
-hugetlb.<hugepagesize>.rsvd.limit_in_bytes
-hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes
-hugetlb.<hugepagesize>.rsvd.usage_in_bytes
-hugetlb.<hugepagesize>.rsvd.failcnt
+::
+
+ hugetlb.<hugepagesize>.rsvd.limit_in_bytes
+ hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes
+ hugetlb.<hugepagesize>.rsvd.usage_in_bytes
+ hugetlb.<hugepagesize>.rsvd.failcnt
The HugeTLB controller allows to limit the HugeTLB reservations per control
group and enforces the controller limit at reservation time and at the fault of
diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index a402359abb99..9f8e27355cba 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -62,7 +62,7 @@ Please note that implementation details can be changed.
At cancel(), simply usage -= PAGE_SIZE.
-Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
+Under below explanation, we assume CONFIG_SWAP=y.
4. Anonymous
============
@@ -102,7 +102,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
The logic is very clear. (About migration, see below)
Note:
- __remove_from_page_cache() is called by remove_from_page_cache()
+ __filemap_remove_folio() is called by filemap_remove_folio()
and __remove_mapping().
6. Shmem(tmpfs) Page Cache
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
index 2cc502a75ef6..d6b1db8cc7eb 100644
--- a/Documentation/admin-guide/cgroup-v1/memory.rst
+++ b/Documentation/admin-guide/cgroup-v1/memory.rst
@@ -2,18 +2,18 @@
Memory Resource Controller
==========================
-NOTE:
+.. caution::
This document is hopelessly outdated and it asks for a complete
rewrite. It still contains a useful information so we are keeping it
here but make sure to check the current code if you need a deeper
understanding.
-NOTE:
+.. note::
The Memory Resource Controller has generically been referred to as the
memory controller in this document. Do not confuse memory controller
used here with the memory controller that is used in hardware.
-(For editors) In this document:
+.. hint::
When we mention a cgroup (cgroupfs's directory) with memory controller,
we call it "memory cgroup". When you see git-log and source code, you'll
see patch's title and function names tend to use "memcg".
@@ -23,7 +23,7 @@ Benefits and Purpose of the memory controller
=============================================
The memory controller isolates the memory behaviour of a group of tasks
-from the rest of the system. The article on LWN [12] mentions some probable
+from the rest of the system. The article on LWN [12]_ mentions some probable
uses of the memory controller. The memory controller can be used to
a. Isolate an application or a group of applications
@@ -55,7 +55,8 @@ Features:
- Root cgroup has no limit controls.
Kernel memory support is a work in progress, and the current version provides
- basically functionality. (See Section 2.7)
+ basically functionality. (See :ref:`section 2.7
+ <cgroup-v1-memory-kernel-extension>`)
Brief summary of control files.
@@ -77,46 +78,66 @@ Brief summary of control files.
memory.memsw.max_usage_in_bytes show max memory+Swap usage recorded
memory.soft_limit_in_bytes set/show soft limit of memory usage
This knob is not available on CONFIG_PREEMPT_RT systems.
+ This knob is deprecated and shouldn't be
+ used.
memory.stat show various statistics
memory.use_hierarchy set/show hierarchical account enabled
This knob is deprecated and shouldn't be
used.
memory.force_empty trigger forced page reclaim
memory.pressure_level set memory pressure notifications
+ This knob is deprecated and shouldn't be
+ used.
memory.swappiness set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
- memory.move_charge_at_immigrate set/show controls of moving charges
+ Per memcg knob does not exist in cgroup v2.
+ memory.move_charge_at_immigrate This knob is deprecated.
memory.oom_control set/show oom controls.
+ This knob is deprecated and shouldn't be
+ used.
memory.numa_stat show the number of memory usage per numa
node
- memory.kmem.limit_in_bytes This knob is deprecated and writing to
- it will return -ENOTSUPP.
+ memory.kmem.limit_in_bytes Deprecated knob to set and read the kernel
+ memory hard limit. Kernel hard limit is not
+ supported since 5.16. Writing any value to
+ do file will not have any effect same as if
+ nokmem kernel parameter was specified.
+ Kernel memory is still charged and reported
+ by memory.kmem.usage_in_bytes.
memory.kmem.usage_in_bytes show current kernel memory allocation
memory.kmem.failcnt show the number of kernel memory usage
hits limits
memory.kmem.max_usage_in_bytes show max kernel memory usage recorded
memory.kmem.tcp.limit_in_bytes set/show hard limit for tcp buf memory
+ This knob is deprecated and shouldn't be
+ used.
memory.kmem.tcp.usage_in_bytes show current tcp buf memory allocation
+ This knob is deprecated and shouldn't be
+ used.
memory.kmem.tcp.failcnt show the number of tcp buf memory usage
hits limits
+ This knob is deprecated and shouldn't be
+ used.
memory.kmem.tcp.max_usage_in_bytes show max tcp buf memory usage recorded
+ This knob is deprecated and shouldn't be
+ used.
==================================== ==========================================
1. History
==========
The memory controller has a long history. A request for comments for the memory
-controller was posted by Balbir Singh [1]. At the time the RFC was posted
+controller was posted by Balbir Singh [1]_. At the time the RFC was posted
there were several implementations for memory control. The goal of the
RFC was to build consensus and agreement for the minimal features required
-for memory control. The first RSS controller was posted by Balbir Singh[2]
-in Feb 2007. Pavel Emelianov [3][4][5] has since posted three versions of the
-RSS controller. At OLS, at the resource management BoF, everyone suggested
-that we handle both page cache and RSS together. Another request was raised
-to allow user space handling of OOM. The current memory controller is
+for memory control. The first RSS controller was posted by Balbir Singh [2]_
+in Feb 2007. Pavel Emelianov [3]_ [4]_ [5]_ has since posted three versions
+of the RSS controller. At OLS, at the resource management BoF, everyone
+suggested that we handle both page cache and RSS together. Another request was
+raised to allow user space handling of OOM. The current memory controller is
at version 6; it combines both mapped (RSS) and unmapped Page
-Cache Control [11].
+Cache Control [11]_.
2. Memory Control
=================
@@ -147,7 +168,8 @@ specific data structure (mem_cgroup) associated with it.
2.2. Accounting
---------------
-::
+.. code-block::
+ :caption: Figure 1: Hierarchy of Accounting
+--------------------+
| mem_cgroup |
@@ -167,7 +189,6 @@ specific data structure (mem_cgroup) associated with it.
| | | |
+---------------+ +---------------+
- (Figure 1: Hierarchy of Accounting)
Figure 1 shows the important aspects of the controller
@@ -194,11 +215,11 @@ are not accounted. We just account pages under usual VM management.
RSS pages are accounted at page_fault unless they've already been accounted
for earlier. A file page will be accounted for as Page Cache when it's
-inserted into inode (radix-tree). While it's mapped into the page tables of
+inserted into inode (xarray). While it's mapped into the page tables of
processes, duplicate accounting is carefully avoided.
An RSS page is unaccounted when it's fully unmapped. A PageCache page is
-unaccounted when it's removed from radix-tree. Even if RSS pages are fully
+unaccounted when it's removed from xarray. Even if RSS pages are fully
unmapped (by kswapd), they may exist as SwapCache in the system until they
are really freed. Such SwapCaches are also accounted.
A swapped-in page is accounted after adding into swapcache.
@@ -221,9 +242,6 @@ behind this approach is that a cgroup that aggressively uses a shared
page will eventually get charged for it (once it is uncharged from
the cgroup that brought it in -- this will happen on memory pressure).
-But see section 8.2: when moving a task to another cgroup, its pages may
-be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
-
2.4 Swap Extension
--------------------------------------
@@ -244,7 +262,8 @@ In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
By using the memsw limit, you can avoid system OOM which can be caused by swap
shortage.
-**why 'memory+swap' rather than swap**
+2.4.1 why 'memory+swap' rather than swap
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
to move account from memory to swap...there is no change in usage of
@@ -252,7 +271,8 @@ memory+swap. In other words, when we want to limit the usage of swap without
affecting global LRU, memory+swap limit is better than just limiting swap from
an OS point of view.
-**What happens when a cgroup hits memory.memsw.limit_in_bytes**
+2.4.2. What happens when a cgroup hits memory.memsw.limit_in_bytes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
in this cgroup. Then, swap-out will not be done by cgroup routine and file
@@ -268,38 +288,40 @@ global VM. When a cgroup goes over its limit, we first try
to reclaim memory from the cgroup so as to make space for the new
pages that the cgroup has touched. If the reclaim is unsuccessful,
an OOM routine is invoked to select and kill the bulkiest task in the
-cgroup. (See 10. OOM Control below.)
+cgroup. (See :ref:`10. OOM Control <cgroup-v1-memory-oom-control>` below.)
The reclaim algorithm has not been modified for cgroups, except that
pages that are selected for reclaiming come from the per-cgroup LRU
list.
-NOTE:
- Reclaim does not work for the root cgroup, since we cannot set any
- limits on the root cgroup.
+.. note::
+ Reclaim does not work for the root cgroup, since we cannot set any
+ limits on the root cgroup.
-Note2:
- When panic_on_oom is set to "2", the whole system will panic.
+.. note::
+ When panic_on_oom is set to "2", the whole system will panic.
When oom event notifier is registered, event will be delivered.
-(See oom_control section)
+(See :ref:`oom_control <cgroup-v1-memory-oom-control>` section)
2.6 Locking
-----------
-Lock order is as follows:
+Lock order is as follows::
- Page lock (PG_locked bit of page->flags)
+ folio_lock
mm->page_table_lock or split pte_lock
- lock_page_memcg (memcg->move_lock)
+ folio_memcg_lock (memcg->move_lock)
mapping->i_pages lock
lruvec->lru_lock.
Per-node-per-memcgroup LRU (cgroup's private LRU) is guarded by
-lruvec->lru_lock; PG_lru bit of page->flags is cleared before
+lruvec->lru_lock; the folio LRU flag is cleared before
isolating a page from its LRU under lruvec->lru_lock.
-2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
+.. _cgroup-v1-memory-kernel-extension:
+
+2.7 Kernel Memory Extension
-----------------------------------------------
With the Kernel memory extension, the Memory Controller is able to limit
@@ -367,10 +389,10 @@ U != 0, K < U:
never greater than the total memory, and freely set U at the cost of his
QoS.
-WARNING:
- In the current implementation, memory reclaim will NOT be
- triggered for a cgroup when it hits K while staying below U, which makes
- this setup impractical.
+ .. warning::
+ In the current implementation, memory reclaim will NOT be triggered for
+ a cgroup when it hits K while staying below U, which makes this setup
+ impractical.
U != 0, K >= U:
Since kmem charges will also be fed to the user counter and reclaim will be
@@ -381,47 +403,41 @@ U != 0, K >= U:
3. User Interface
=================
-3.0. Configuration
-------------------
-
-a. Enable CONFIG_CGROUPS
-b. Enable CONFIG_MEMCG
-c. Enable CONFIG_MEMCG_SWAP (to use swap extension)
-d. Enable CONFIG_MEMCG_KMEM (to use kmem extension)
+To use the user interface:
-3.1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
--------------------------------------------------------------------
-
-::
+1. Enable CONFIG_CGROUPS and CONFIG_MEMCG options
+2. Prepare the cgroups (see :ref:`Why are cgroups needed?
+ <cgroups-why-needed>` for the background information)::
# mount -t tmpfs none /sys/fs/cgroup
# mkdir /sys/fs/cgroup/memory
# mount -t cgroup none /sys/fs/cgroup/memory -o memory
-3.2. Make the new group and move bash into it::
+3. Make the new group and move bash into it::
# mkdir /sys/fs/cgroup/memory/0
# echo $$ > /sys/fs/cgroup/memory/0/tasks
-Since now we're in the 0 cgroup, we can alter the memory limit::
+4. Since now we're in the 0 cgroup, we can alter the memory limit::
# echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes
-NOTE:
- We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
- mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes,
- Gibibytes.)
+ The limit can now be queried::
+
+ # cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
+ 4194304
-NOTE:
- We can write "-1" to reset the ``*.limit_in_bytes(unlimited)``.
+.. note::
+ We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
+ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes,
+ Gibibytes.)
-NOTE:
- We cannot set limits on the root cgroup any more.
+.. note::
+ We can write "-1" to reset the ``*.limit_in_bytes(unlimited)``.
-::
+.. note::
+ We cannot set limits on the root cgroup any more.
- # cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
- 4194304
We can check the usage::
@@ -460,6 +476,8 @@ test because it has noise of shared objects/status.
But the above two are testing extreme situations.
Trying usual test under memory controller is always helpful.
+.. _cgroup-v1-memory-test-troubleshoot:
+
4.1 Troubleshooting
-------------------
@@ -472,8 +490,11 @@ terminated by the OOM killer. There are several causes for this:
A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
some of the pages cached in the cgroup (page cache pages).
-To know what happens, disabling OOM_Kill as per "10. OOM Control" (below) and
-seeing what happens will be helpful.
+To know what happens, disabling OOM_Kill as per :ref:`"10. OOM Control"
+<cgroup-v1-memory-oom-control>` (below) and seeing what happens will be
+helpful.
+
+.. _cgroup-v1-memory-test-task-migration:
4.2 Task migration
------------------
@@ -484,15 +505,16 @@ remain charged to it, the charge is dropped when the page is freed or
reclaimed.
You can move charges of a task along with task migration.
-See 8. "Move charges at task migration"
+See :ref:`8. "Move charges at task migration" <cgroup-v1-memory-move-charges>`
4.3 Removing a cgroup
---------------------
-A cgroup can be removed by rmdir, but as discussed in sections 4.1 and 4.2, a
-cgroup might have some charge associated with it, even though all
-tasks have migrated away from it. (because we charge against pages, not
-against tasks.)
+A cgroup can be removed by rmdir, but as discussed in :ref:`sections 4.1
+<cgroup-v1-memory-test-troubleshoot>` and :ref:`4.2
+<cgroup-v1-memory-test-task-migration>`, a cgroup might have some charge
+associated with it, even though all tasks have migrated away from it. (because
+we charge against pages, not against tasks.)
We move the stats to parent, and no change on the charge except uncharging
from the child.
@@ -521,72 +543,77 @@ will be charged as a new owner of it.
5.2 stat file
-------------
-memory.stat file includes following statistics
-
-per-memory cgroup local status
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-=============== ===============================================================
-cache # of bytes of page cache memory.
-rss # of bytes of anonymous and swap cache memory (includes
- transparent hugepages).
-rss_huge # of bytes of anonymous transparent hugepages.
-mapped_file # of bytes of mapped file (includes tmpfs/shmem)
-pgpgin # of charging events to the memory cgroup. The charging
- event happens each time a page is accounted as either mapped
- anon page(RSS) or cache page(Page Cache) to the cgroup.
-pgpgout # of uncharging events to the memory cgroup. The uncharging
- event happens each time a page is unaccounted from the cgroup.
-swap # of bytes of swap usage
-dirty # of bytes that are waiting to get written back to the disk.
-writeback # of bytes of file/anon cache that are queued for syncing to
- disk.
-inactive_anon # of bytes of anonymous and swap cache memory on inactive
- LRU list.
-active_anon # of bytes of anonymous and swap cache memory on active
- LRU list.
-inactive_file # of bytes of file-backed memory on inactive LRU list.
-active_file # of bytes of file-backed memory on active LRU list.
-unevictable # of bytes of memory that cannot be reclaimed (mlocked etc).
-=============== ===============================================================
-
-status considering hierarchy (see memory.use_hierarchy settings)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-========================= ===================================================
-hierarchical_memory_limit # of bytes of memory limit with regard to hierarchy
- under which the memory cgroup is
-hierarchical_memsw_limit # of bytes of memory+swap limit with regard to
- hierarchy under which memory cgroup is.
-
-total_<counter> # hierarchical version of <counter>, which in
- addition to the cgroup's own value includes the
- sum of all hierarchical children's values of
- <counter>, i.e. total_cache
-========================= ===================================================
-
-The following additional stats are dependent on CONFIG_DEBUG_VM
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-========================= ========================================
-recent_rotated_anon VM internal parameter. (see mm/vmscan.c)
-recent_rotated_file VM internal parameter. (see mm/vmscan.c)
-recent_scanned_anon VM internal parameter. (see mm/vmscan.c)
-recent_scanned_file VM internal parameter. (see mm/vmscan.c)
-========================= ========================================
-
-Memo:
+memory.stat file includes following statistics:
+
+ * per-memory cgroup local status
+
+ =============== ===============================================================
+ cache # of bytes of page cache memory.
+ rss # of bytes of anonymous and swap cache memory (includes
+ transparent hugepages).
+ rss_huge # of bytes of anonymous transparent hugepages.
+ mapped_file # of bytes of mapped file (includes tmpfs/shmem)
+ pgpgin # of charging events to the memory cgroup. The charging
+ event happens each time a page is accounted as either mapped
+ anon page(RSS) or cache page(Page Cache) to the cgroup.
+ pgpgout # of uncharging events to the memory cgroup. The uncharging
+ event happens each time a page is unaccounted from the
+ cgroup.
+ swap # of bytes of swap usage
+ swapcached # of bytes of swap cached in memory
+ dirty # of bytes that are waiting to get written back to the disk.
+ writeback # of bytes of file/anon cache that are queued for syncing to
+ disk.
+ inactive_anon # of bytes of anonymous and swap cache memory on inactive
+ LRU list.
+ active_anon # of bytes of anonymous and swap cache memory on active
+ LRU list.
+ inactive_file # of bytes of file-backed memory and MADV_FREE anonymous
+ memory (LazyFree pages) on inactive LRU list.
+ active_file # of bytes of file-backed memory on active LRU list.
+ unevictable # of bytes of memory that cannot be reclaimed (mlocked etc).
+ =============== ===============================================================
+
+ * status considering hierarchy (see memory.use_hierarchy settings):
+
+ ========================= ===================================================
+ hierarchical_memory_limit # of bytes of memory limit with regard to
+ hierarchy
+ under which the memory cgroup is
+ hierarchical_memsw_limit # of bytes of memory+swap limit with regard to
+ hierarchy under which memory cgroup is.
+
+ total_<counter> # hierarchical version of <counter>, which in
+ addition to the cgroup's own value includes the
+ sum of all hierarchical children's values of
+ <counter>, i.e. total_cache
+ ========================= ===================================================
+
+ * additional vm parameters (depends on CONFIG_DEBUG_VM):
+
+ ========================= ========================================
+ recent_rotated_anon VM internal parameter. (see mm/vmscan.c)
+ recent_rotated_file VM internal parameter. (see mm/vmscan.c)
+ recent_scanned_anon VM internal parameter. (see mm/vmscan.c)
+ recent_scanned_file VM internal parameter. (see mm/vmscan.c)
+ ========================= ========================================
+
+.. hint::
recent_rotated means recent frequency of LRU rotation.
recent_scanned means recent # of scans to LRU.
showing for better debug please see the code for meanings.
-Note:
+.. note::
Only anonymous and swap cache memory is listed as part of 'rss' stat.
This should not be confused with the true 'resident set size' or the
amount of physical memory used by the cgroup.
'rss + mapped_file" will give you resident set size of cgroup.
+ Note that some kernel configurations might account complete larger
+ allocations (e.g., THP) towards 'rss' and 'mapped_file', even if
+ only some, but not all that memory is mapped.
+
(Note: file and shmem may be shared among other cgroups. In that case,
mapped_file is accounted only when the memory cgroup is owner of page
cache.)
@@ -679,8 +706,10 @@ For compatibility reasons writing 1 to memory.use_hierarchy will always pass::
# echo 1 > memory.use_hierarchy
-7. Soft limits
-==============
+7. Soft limits (DEPRECATED)
+===========================
+
+THIS IS DEPRECATED!
Soft limits allow for greater sharing of memory. The idea behind soft limits
is to allow control groups to use as much of the memory as needed, provided
@@ -711,77 +740,23 @@ If we want to change this to 1G, we can at any time use::
# echo 1G > memory.soft_limit_in_bytes
-NOTE1:
+.. note::
Soft limits take effect over a long period of time, since they involve
reclaiming memory for balancing between memory cgroups
-NOTE2:
+
+.. note::
It is recommended to set the soft limit always below the hard limit,
otherwise the hard limit will take precedence.
-8. Move charges at task migration
-=================================
-
-Users can move charges associated with a task along with task migration, that
-is, uncharge task's pages from the old cgroup and charge them to the new cgroup.
-This feature is not supported in !CONFIG_MMU environments because of lack of
-page tables.
-
-8.1 Interface
--------------
-
-This feature is disabled by default. It can be enabled (and disabled again) by
-writing to memory.move_charge_at_immigrate of the destination cgroup.
-
-If you want to enable it::
+.. _cgroup-v1-memory-move-charges:
- # echo (some positive value) > memory.move_charge_at_immigrate
+8. Move charges at task migration (DEPRECATED!)
+===============================================
-Note:
- Each bits of move_charge_at_immigrate has its own meaning about what type
- of charges should be moved. See 8.2 for details.
-Note:
- Charges are moved only when you move mm->owner, in other words,
- a leader of a thread group.
-Note:
- If we cannot find enough space for the task in the destination cgroup, we
- try to make space by reclaiming memory. Task migration may fail if we
- cannot make enough space.
-Note:
- It can take several seconds if you move charges much.
+THIS IS DEPRECATED!
-And if you want disable it again::
-
- # echo 0 > memory.move_charge_at_immigrate
-
-8.2 Type of charges which can be moved
---------------------------------------
-
-Each bit in move_charge_at_immigrate has its own meaning about what type of
-charges should be moved. But in any case, it must be noted that an account of
-a page or a swap can be moved only when it is charged to the task's current
-(old) memory cgroup.
-
-+---+--------------------------------------------------------------------------+
-|bit| what type of charges would be moved ? |
-+===+==========================================================================+
-| 0 | A charge of an anonymous page (or swap of it) used by the target task. |
-| | You must enable Swap Extension (see 2.4) to enable move of swap charges. |
-+---+--------------------------------------------------------------------------+
-| 1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory) |
-| | and swaps of tmpfs file) mmapped by the target task. Unlike the case of |
-| | anonymous pages, file pages (and swaps) in the range mmapped by the task |
-| | will be moved even if the task hasn't done page fault, i.e. they might |
-| | not be the task's "RSS", but other task's "RSS" that maps the same file. |
-| | And mapcount of the page is ignored (the page can be moved even if |
-| | page_mapcount(page) > 1). You must enable Swap Extension (see 2.4) to |
-| | enable move of swap charges. |
-+---+--------------------------------------------------------------------------+
-
-8.3 TODO
---------
-
-- All of moving charge operations are done under cgroup_mutex. It's not good
- behavior to hold the mutex too long, so we may need some trick.
+Reading memory.move_charge_at_immigrate will always return 0 and writing
+to it will always return -EINVAL.
9. Memory thresholds
====================
@@ -802,8 +777,12 @@ threshold in any direction.
It's applicable for root and non-root cgroup.
-10. OOM Control
-===============
+.. _cgroup-v1-memory-oom-control:
+
+10. OOM Control (DEPRECATED)
+============================
+
+THIS IS DEPRECATED!
memory.oom_control file is for OOM notification and other controls.
@@ -850,8 +829,10 @@ At reading, current status of OOM is shown.
The number of processes belonging to this cgroup killed by any
kind of OOM killer.
-11. Memory Pressure
-===================
+11. Memory Pressure (DEPRECATED)
+================================
+
+THIS IS DEPRECATED!
The pressure level notifications can be used to monitor the memory
allocation cost; based on the pressure, applications can implement
@@ -883,7 +864,7 @@ experiences some pressure. In this situation, only group C will receive the
notification, i.e. groups A and B will not receive it. This is done to avoid
excessive "broadcasting" of messages, which disturbs the system and which is
especially bad if we are low on memory or thrashing. Group B, will receive
-notification only if there are no event listers for group C.
+notification only if there are no event listeners for group C.
There are three optional modes that specify different propagation behavior:
@@ -957,15 +938,16 @@ commented and discussed quite extensively in the community.
References
==========
-1. Singh, Balbir. RFC: Memory Controller, http://lwn.net/Articles/206697/
-2. Singh, Balbir. Memory Controller (RSS Control),
+.. [1] Singh, Balbir. RFC: Memory Controller, http://lwn.net/Articles/206697/
+.. [2] Singh, Balbir. Memory Controller (RSS Control),
http://lwn.net/Articles/222762/
-3. Emelianov, Pavel. Resource controllers based on process cgroups
+.. [3] Emelianov, Pavel. Resource controllers based on process cgroups
https://lore.kernel.org/r/45ED7DEC.7010403@sw.ru
-4. Emelianov, Pavel. RSS controller based on process cgroups (v2)
+.. [4] Emelianov, Pavel. RSS controller based on process cgroups (v2)
https://lore.kernel.org/r/461A3010.90403@sw.ru
-5. Emelianov, Pavel. RSS controller based on process cgroups (v3)
+.. [5] Emelianov, Pavel. RSS controller based on process cgroups (v3)
https://lore.kernel.org/r/465D9739.8070209@openvz.org
+
6. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/
7. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control
subsystem (v3), http://lwn.net/Articles/235534/
@@ -975,7 +957,8 @@ References
https://lore.kernel.org/r/464D267A.50107@linux.vnet.ibm.com
10. Singh, Balbir. Memory controller v6 test results,
https://lore.kernel.org/r/20070819094658.654.84837.sendpatchset@balbir-laptop
-11. Singh, Balbir. Memory controller introduction (v6),
- https://lore.kernel.org/r/20070817084228.26003.12568.sendpatchset@balbir-laptop
-12. Corbet, Jonathan, Controlling memory use in cgroups,
- http://lwn.net/Articles/243795/
+
+.. [11] Singh, Balbir. Memory controller introduction (v6),
+ https://lore.kernel.org/r/20070817084228.26003.12568.sendpatchset@balbir-laptop
+.. [12] Corbet, Jonathan, Controlling memory use in cgroups,
+ http://lwn.net/Articles/243795/
diff --git a/Documentation/admin-guide/cgroup-v1/pids.rst b/Documentation/admin-guide/cgroup-v1/pids.rst
index 6acebd9e72c8..0f9f9a7b1f6c 100644
--- a/Documentation/admin-guide/cgroup-v1/pids.rst
+++ b/Documentation/admin-guide/cgroup-v1/pids.rst
@@ -36,7 +36,8 @@ superset of parent/child/pids.current.
The pids.events file contains event counters:
- - max: Number of times fork failed because limit was hit.
+ - max: Number of times fork failed in the cgroup because limit was hit in
+ self or ancestors.
Example
-------
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index be4a77baf784..7f5b59d95fce 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -15,6 +15,9 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou
.. CONTENTS
+ [Whenever any new section is added to this document, please also add
+ an entry here.]
+
1. Introduction
1-1. Terminology
1-2. What is cgroup?
@@ -25,9 +28,10 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou
2-2-2. Threads
2-3. [Un]populated Notification
2-4. Controlling Controllers
- 2-4-1. Enabling and Disabling
- 2-4-2. Top-down Constraint
- 2-4-3. No Internal Process Constraint
+ 2-4-1. Availability
+ 2-4-2. Enabling and Disabling
+ 2-4-3. Top-down Constraint
+ 2-4-4. No Internal Process Constraint
2-5. Delegation
2-5-1. Model of Delegation
2-5-2. Delegation Containment
@@ -49,7 +53,8 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou
5-2. Memory
5-2-1. Memory Interface Files
5-2-2. Usage Guidelines
- 5-2-3. Memory Ownership
+ 5-2-3. Reclaim Protection
+ 5-2-4. Memory Ownership
5-3. IO
5-3-1. IO Interface Files
5-3-2. Writeback
@@ -61,16 +66,18 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou
5-4-1. PID Interface Files
5-5. Cpuset
5.5-1. Cpuset Interface Files
- 5-6. Device
+ 5-6. Device controller
5-7. RDMA
5-7-1. RDMA Interface Files
- 5-8. HugeTLB
- 5.8-1. HugeTLB Interface Files
- 5-9. Misc
- 5.9-1 Miscellaneous cgroup Interface Files
- 5.9-2 Migration and Ownership
- 5-10. Others
- 5-10-1. perf_event
+ 5-8. DMEM
+ 5-8-1. DMEM Interface Files
+ 5-9. HugeTLB
+ 5.9-1. HugeTLB Interface Files
+ 5-10. Misc
+ 5.10-1 Misc Interface Files
+ 5.10-2 Migration and Ownership
+ 5-11. Others
+ 5-11-1. perf_event
5-N. Non-normative information
5-N-1. CPU controller root cgroup process behaviour
5-N-2. IO controller root cgroup process behaviour
@@ -210,6 +217,42 @@ cgroup v2 currently supports the following mount options.
relying on the original semantics (e.g. specifying bogusly
high 'bypass' protection values at higher tree levels).
+ memory_hugetlb_accounting
+ Count HugeTLB memory usage towards the cgroup's overall
+ memory usage for the memory controller (for the purpose of
+ statistics reporting and memory protetion). This is a new
+ behavior that could regress existing setups, so it must be
+ explicitly opted in with this mount option.
+
+ A few caveats to keep in mind:
+
+ * There is no HugeTLB pool management involved in the memory
+ controller. The pre-allocated pool does not belong to anyone.
+ Specifically, when a new HugeTLB folio is allocated to
+ the pool, it is not accounted for from the perspective of the
+ memory controller. It is only charged to a cgroup when it is
+ actually used (for e.g at page fault time). Host memory
+ overcommit management has to consider this when configuring
+ hard limits. In general, HugeTLB pool management should be
+ done via other mechanisms (such as the HugeTLB controller).
+ * Failure to charge a HugeTLB folio to the memory controller
+ results in SIGBUS. This could happen even if the HugeTLB pool
+ still has pages available (but the cgroup limit is hit and
+ reclaim attempt fails).
+ * Charging HugeTLB memory towards the memory controller affects
+ memory protection and reclaim dynamics. Any userspace tuning
+ (of low, min limits for e.g) needs to take this into account.
+ * HugeTLB pages utilized while this option is not selected
+ will not be tracked by the memory controller (even if cgroup
+ v2 is remounted later on).
+
+ pids_localevents
+ The option restores v1-like behavior of pids.events:max, that is only
+ local (inside cgroup proper) fork failures are counted. Without this
+ option pids.events.max represents any pids.max enforcemnt across
+ cgroup's subtree.
+
+
Organizing Processes and Threads
--------------------------------
@@ -364,6 +407,13 @@ constraint, a threaded controller must be able to handle competition
between threads in a non-leaf cgroup and its child cgroups. Each
threaded controller defines how such competitions are handled.
+Currently, the following controllers are threaded and can be enabled
+in a threaded cgroup::
+
+- cpu
+- cpuset
+- perf_event
+- pids
[Un]populated Notification
--------------------------
@@ -391,6 +441,15 @@ both cgroups.
Controlling Controllers
-----------------------
+Availability
+~~~~~~~~~~~~
+
+A controller is available in a cgroup when it is supported by the kernel (i.e.,
+compiled in, not disabled and not attached to a v1 hierarchy) and listed in the
+"cgroup.controllers" file. Availability means the controller's interface files
+are exposed in the cgroup’s directory, allowing the distribution of the target
+resource to be observed or controlled within that cgroup.
+
Enabling and Disabling
~~~~~~~~~~~~~~~~~~~~~~
@@ -490,10 +549,12 @@ cgroup namespace on namespace creation.
Because the resource control interface files in a given directory
control the distribution of the parent's resources, the delegatee
shouldn't be allowed to write to them. For the first method, this is
-achieved by not granting access to these files. For the second, the
-kernel rejects writes to all files other than "cgroup.procs" and
-"cgroup.subtree_control" on a namespace root from inside the
-namespace.
+achieved by not granting access to these files. For the second, files
+outside the namespace should be hidden from the delegatee by the means
+of at least mount namespacing, and the kernel rejects writes to all
+files on a namespace root from inside the cgroup namespace, except for
+those files listed in "/sys/kernel/cgroup/delegate" (including
+"cgroup.procs", "cgroup.threads", "cgroup.subtree_control", etc.).
The end results are equivalent for both delegation types. Once
delegated, the user can build sub-hierarchy under the directory,
@@ -619,10 +680,12 @@ process migrations.
and is an example of this type.
+.. _cgroupv2-limits-distributor:
+
Limits
------
-A child can only consume upto the configured amount of the resource.
+A child can only consume up to the configured amount of the resource.
Limits can be over-committed - the sum of the limits of children can
exceed the amount of resource available to the parent.
@@ -635,15 +698,16 @@ process migrations.
"io.max" limits the maximum BPS and/or IOPS that a cgroup can consume
on an IO device and is an example of this type.
+.. _cgroupv2-protections-distributor:
Protections
-----------
-A cgroup is protected upto the configured amount of the resource
+A cgroup is protected up to the configured amount of the resource
as long as the usages of all its ancestors are under their
protected levels. Protections can be hard guarantees or best effort
soft boundaries. Protections can also be over-committed in which case
-only upto the amount available to the parent is protected among
+only up to the amount available to the parent is protected among
children.
Protections are in the range [0, max] and defaults to 0, which is
@@ -935,6 +999,32 @@ All cgroup core files are prefixed with "cgroup."
A dying cgroup can consume system resources not exceeding
limits, which were active at the moment of cgroup deletion.
+ nr_subsys_<cgroup_subsys>
+ Total number of live cgroup subsystems (e.g memory
+ cgroup) at and beneath the current cgroup.
+
+ nr_dying_subsys_<cgroup_subsys>
+ Total number of dying cgroup subsystems (e.g. memory
+ cgroup) at and beneath the current cgroup.
+
+ cgroup.stat.local
+ A read-only flat-keyed file which exists in non-root cgroups.
+ The following entry is defined:
+
+ frozen_usec
+ Cumulative time that this cgroup has spent between freezing and
+ thawing, regardless of whether by self or ancestor groups.
+ NB: (not) reaching "frozen" state is not accounted here.
+
+ Using the following ASCII representation of a cgroup's freezer
+ state, ::
+
+ 1 _____
+ frozen 0 __/ \__
+ ab cd
+
+ the duration being measured is the span between a and c.
+
cgroup.freeze
A read-write single value file which exists on non-root cgroups.
Allowed values are "0" and "1". The default is "0".
@@ -976,6 +1066,29 @@ All cgroup core files are prefixed with "cgroup."
killing cgroups is a process directed operation, i.e. it affects
the whole thread-group.
+ cgroup.pressure
+ A read-write single value file that allowed values are "0" and "1".
+ The default is "1".
+
+ Writing "0" to the file will disable the cgroup PSI accounting.
+ Writing "1" to the file will re-enable the cgroup PSI accounting.
+
+ This control attribute is not hierarchical, so disable or enable PSI
+ accounting in a cgroup does not affect PSI accounting in descendants
+ and doesn't need pass enablement via ancestors from root.
+
+ The reason this control attribute exists is that PSI accounts stalls for
+ each cgroup separately and aggregates it at each level of the hierarchy.
+ This may cause non-negligible overhead for some workloads when under
+ deep level of the hierarchy, in which case this control attribute can
+ be used to disable PSI accounting in the non-leaf cgroups.
+
+ irq.pressure
+ A read-write nested-keyed file.
+
+ Shows pressure stall information for IRQ/SOFTIRQ. See
+ :ref:`Documentation/accounting/psi.rst <psi>` for details.
+
Controllers
===========
@@ -996,30 +1109,53 @@ cpufreq governor about the minimum desired frequency which should always be
provided by a CPU, as well as the maximum desired frequency, which should not
be exceeded by a CPU.
-WARNING: cgroup2 doesn't yet support control of realtime processes and
-the cpu controller can only be enabled when all RT processes are in
-the root cgroup. Be aware that system management software may already
-have placed RT processes into nonroot cgroups during the system boot
-process, and these processes may need to be moved to the root cgroup
-before the cpu controller can be enabled.
+WARNING: cgroup2 cpu controller doesn't yet support the (bandwidth) control of
+realtime processes. For a kernel built with the CONFIG_RT_GROUP_SCHED option
+enabled for group scheduling of realtime processes, the cpu controller can only
+be enabled when all RT processes are in the root cgroup. Be aware that system
+management software may already have placed RT processes into non-root cgroups
+during the system boot process, and these processes may need to be moved to the
+root cgroup before the cpu controller can be enabled with a
+CONFIG_RT_GROUP_SCHED enabled kernel.
+
+With CONFIG_RT_GROUP_SCHED disabled, this limitation does not apply and some of
+the interface files either affect realtime processes or account for them. See
+the following section for details. Only the cpu controller is affected by
+CONFIG_RT_GROUP_SCHED. Other controllers can be used for the resource control of
+realtime processes irrespective of CONFIG_RT_GROUP_SCHED.
CPU Interface Files
~~~~~~~~~~~~~~~~~~~
-All time durations are in microseconds.
+The interaction of a process with the cpu controller depends on its scheduling
+policy and the underlying scheduler. From the point of view of the cpu controller,
+processes can be categorized as follows:
+
+* Processes under the fair-class scheduler
+* Processes under a BPF scheduler with the ``cgroup_set_weight`` callback
+* Everything else: ``SCHED_{FIFO,RR,DEADLINE}`` and processes under a BPF scheduler
+ without the ``cgroup_set_weight`` callback
+
+For details on when a process is under the fair-class scheduler or a BPF scheduler,
+check out :ref:`Documentation/scheduler/sched-ext.rst <sched-ext>`.
+
+For each of the following interface files, the above categories
+will be referred to. All time durations are in microseconds.
cpu.stat
A read-only flat-keyed file.
This file exists whether the controller is enabled or not.
- It always reports the following three stats:
+ It always reports the following three stats, which account for all the
+ processes in the cgroup:
- usage_usec
- user_usec
- system_usec
- and the following three when the controller is enabled:
+ and the following five when the controller is enabled, which account for
+ only the processes under the fair-class scheduler:
- nr_periods
- nr_throttled
@@ -1031,7 +1167,15 @@ All time durations are in microseconds.
A read-write single value file which exists on non-root
cgroups. The default is "100".
- The weight in the range [1, 10000].
+ For non idle groups (cpu.idle = 0), the weight is in the
+ range [1, 10000].
+
+ If the cgroup has been configured to be SCHED_IDLE (cpu.idle = 1),
+ then the weight will show as a 0.
+
+ This file affects only processes under the fair-class scheduler and a BPF
+ scheduler with the ``cgroup_set_weight`` callback depending on what the
+ callback actually does.
cpu.weight.nice
A read-write single value file which exists on non-root
@@ -1045,6 +1189,10 @@ All time durations are in microseconds.
granularity is coarser for the nice values, the read value is
the closest approximation of the current weight.
+ This file affects only processes under the fair-class scheduler and a BPF
+ scheduler with the ``cgroup_set_weight`` callback depending on what the
+ callback actually does.
+
cpu.max
A read-write two value file which exists on non-root cgroups.
The default is "max 100000".
@@ -1053,49 +1201,71 @@ All time durations are in microseconds.
$MAX $PERIOD
- which indicates that the group may consume upto $MAX in each
+ which indicates that the group may consume up to $MAX in each
$PERIOD duration. "max" for $MAX indicates no limit. If only
one number is written, $MAX is updated.
+ This file affects only processes under the fair-class scheduler.
+
cpu.max.burst
A read-write single value file which exists on non-root
cgroups. The default is "0".
The burst in the range [0, $MAX].
+ This file affects only processes under the fair-class scheduler.
+
cpu.pressure
A read-write nested-keyed file.
Shows pressure stall information for CPU. See
:ref:`Documentation/accounting/psi.rst <psi>` for details.
+ This file accounts for all the processes in the cgroup.
+
cpu.uclamp.min
- A read-write single value file which exists on non-root cgroups.
- The default is "0", i.e. no utilization boosting.
+ A read-write single value file which exists on non-root cgroups.
+ The default is "0", i.e. no utilization boosting.
+
+ The requested minimum utilization (protection) as a percentage
+ rational number, e.g. 12.34 for 12.34%.
- The requested minimum utilization (protection) as a percentage
- rational number, e.g. 12.34 for 12.34%.
+ This interface allows reading and setting minimum utilization clamp
+ values similar to the sched_setattr(2). This minimum utilization
+ value is used to clamp the task specific minimum utilization clamp,
+ including those of realtime processes.
- This interface allows reading and setting minimum utilization clamp
- values similar to the sched_setattr(2). This minimum utilization
- value is used to clamp the task specific minimum utilization clamp.
+ The requested minimum utilization (protection) is always capped by
+ the current value for the maximum utilization (limit), i.e.
+ `cpu.uclamp.max`.
- The requested minimum utilization (protection) is always capped by
- the current value for the maximum utilization (limit), i.e.
- `cpu.uclamp.max`.
+ This file affects all the processes in the cgroup.
cpu.uclamp.max
- A read-write single value file which exists on non-root cgroups.
- The default is "max". i.e. no utilization capping
+ A read-write single value file which exists on non-root cgroups.
+ The default is "max". i.e. no utilization capping
+
+ The requested maximum utilization (limit) as a percentage rational
+ number, e.g. 98.76 for 98.76%.
- The requested maximum utilization (limit) as a percentage rational
- number, e.g. 98.76 for 98.76%.
+ This interface allows reading and setting maximum utilization clamp
+ values similar to the sched_setattr(2). This maximum utilization
+ value is used to clamp the task specific maximum utilization clamp,
+ including those of realtime processes.
- This interface allows reading and setting maximum utilization clamp
- values similar to the sched_setattr(2). This maximum utilization
- value is used to clamp the task specific maximum utilization clamp.
+ This file affects all the processes in the cgroup.
+ cpu.idle
+ A read-write single value file which exists on non-root cgroups.
+ The default is 0.
+
+ This is the cgroup analog of the per-task SCHED_IDLE sched policy.
+ Setting this value to a 1 will make the scheduling policy of the
+ cgroup SCHED_IDLE. The threads inside the cgroup will retain their
+ own relative priorities, but the cgroup itself will be treated as
+ very low priority relative to its peers.
+ This file affects only processes under the fair-class scheduler.
Memory
------
@@ -1148,7 +1318,7 @@ PAGE_SIZE multiple when read back.
smaller overages.
Effective min boundary is limited by memory.min values of
- all ancestor cgroups. If there is memory.min overcommitment
+ ancestor cgroups. If there is memory.min overcommitment
(child cgroup or cgroups are requiring more protected memory
than parent will allow), then each child cgroup will get
the part of parent's protection proportional to its
@@ -1157,9 +1327,6 @@ PAGE_SIZE multiple when read back.
Putting more memory than generally available under this
protection is discouraged and may lead to constant OOMs.
- If a memory cgroup is not populated with processes,
- its memory.min is ignored.
-
memory.low
A read-write single value file which exists on non-root
cgroups. The default is "0".
@@ -1174,7 +1341,7 @@ PAGE_SIZE multiple when read back.
smaller overages.
Effective low boundary is limited by memory.low values of
- all ancestor cgroups. If there is memory.low overcommitment
+ ancestor cgroups. If there is memory.low overcommitment
(child cgroup or cgroups are requiring more protected memory
than parent will allow), then each child cgroup will get
the part of parent's protection proportional to its
@@ -1187,23 +1354,37 @@ PAGE_SIZE multiple when read back.
A read-write single value file which exists on non-root
cgroups. The default is "max".
- Memory usage throttle limit. This is the main mechanism to
- control memory usage of a cgroup. If a cgroup's usage goes
+ Memory usage throttle limit. If a cgroup's usage goes
over the high boundary, the processes of the cgroup are
throttled and put under heavy reclaim pressure.
Going over the high limit never invokes the OOM killer and
- under extreme conditions the limit may be breached.
+ under extreme conditions the limit may be breached. The high
+ limit should be used in scenarios where an external process
+ monitors the limited cgroup to alleviate heavy reclaim
+ pressure.
+
+ If memory.high is opened with O_NONBLOCK then the synchronous
+ reclaim is bypassed. This is useful for admin processes that
+ need to dynamically adjust the job's memory limits without
+ expending their own CPU resources on memory reclamation. The
+ job will trigger the reclaim and/or get throttled on its
+ next charge request.
+
+ Please note that with O_NONBLOCK, there is a chance that the
+ target memory cgroup may take indefinite amount of time to
+ reduce usage below the limit due to delayed charge request or
+ busy-hitting its memory to slow down reclaim.
memory.max
A read-write single value file which exists on non-root
cgroups. The default is "max".
- Memory usage hard limit. This is the final protection
- mechanism. If a cgroup's memory usage reaches this limit and
- can't be reduced, the OOM killer is invoked in the cgroup.
- Under certain circumstances, the usage may go over the limit
- temporarily.
+ Memory usage hard limit. This is the main mechanism to limit
+ memory usage of a cgroup. If a cgroup's memory usage reaches
+ this limit and can't be reduced, the OOM killer is invoked in
+ the cgroup. Under certain circumstances, the usage may go
+ over the limit temporarily.
In default configuration regular 0-order allocations always
succeed unless OOM killer chooses current task as a victim.
@@ -1212,9 +1393,17 @@ PAGE_SIZE multiple when read back.
Caller could retry them differently, return into userspace
as -ENOMEM or silently ignore in cases like disk readahead.
- This is the ultimate protection mechanism. As long as the
- high limit is used and monitored properly, this limit's
- utility is limited to providing the final safety net.
+ If memory.max is opened with O_NONBLOCK, then the synchronous
+ reclaim and oom-kill are bypassed. This is useful for admin
+ processes that need to dynamically adjust the job's memory limits
+ without expending their own CPU resources on memory reclamation.
+ The job will trigger the reclaim and/or oom-kill on its next
+ charge request.
+
+ Please note that with O_NONBLOCK, there is a chance that the
+ target memory cgroup may take indefinite amount of time to
+ reduce usage below the limit due to delayed charge request or
+ busy-hitting its memory to slow down reclaim.
memory.reclaim
A write-only nested-keyed file which exists for all cgroups.
@@ -1222,17 +1411,10 @@ PAGE_SIZE multiple when read back.
This is a simple interface to trigger memory reclaim in the
target cgroup.
- This file accepts a single key, the number of bytes to reclaim.
- No nested keys are currently supported.
-
Example::
echo "1G" > memory.reclaim
- The interface can be later extended with nested keys to
- configure the reclaim behavior. For example, specify the
- type of memory to reclaim from (anon, file, ..).
-
Please note that the kernel can over or under reclaim from
the target cgroup. If less bytes are reclaimed than the
specified amount, -EAGAIN is returned.
@@ -1244,12 +1426,29 @@ PAGE_SIZE multiple when read back.
This means that the networking layer will not adapt based on
reclaim induced by memory.reclaim.
+The following nested keys are defined.
+
+ ========== ================================
+ swappiness Swappiness value to reclaim with
+ ========== ================================
+
+ Specifying a swappiness value instructs the kernel to perform
+ the reclaim with that swappiness value. Note that this has the
+ same semantics as vm.swappiness applied to memcg reclaim with
+ all the existing limitations and potential future extensions.
+
+ The valid range for swappiness is [0-200, max], setting
+ swappiness=max exclusively reclaims anonymous memory.
+
memory.peak
- A read-only single value file which exists on non-root
- cgroups.
+ A read-write single value file which exists on non-root cgroups.
+
+ The max memory usage recorded for the cgroup and its descendants since
+ either the creation of the cgroup or the most recent reset for that FD.
- The max memory usage recorded for the cgroup and its
- descendants since the creation of the cgroup.
+ A write of any non-empty string to this file resets it to the
+ current memory usage for subsequent reads through the same
+ file descriptor.
memory.oom.group
A read-write single value file which exists on non-root
@@ -1314,6 +1513,10 @@ PAGE_SIZE multiple when read back.
oom_group_kill
The number of times a group OOM has occurred.
+ sock_throttled
+ The number of times network sockets associated with
+ this cgroup are throttled.
+
memory.events.local
Similar to memory.events but the fields in the file are local
to the cgroup i.e. not hierarchical. The file modified event
@@ -1338,7 +1541,10 @@ PAGE_SIZE multiple when read back.
anon
Amount of memory used in anonymous mappings such as
- brk(), sbrk(), and mmap(MAP_ANONYMOUS)
+ brk(), sbrk(), and mmap(MAP_ANONYMOUS). Note that
+ some kernel configurations might account complete larger
+ allocations (e.g., THP) if only some, but not all the
+ memory of such an allocation is mapped anymore.
file
Amount of memory used to cache filesystem data,
@@ -1355,6 +1561,11 @@ PAGE_SIZE multiple when read back.
pagetables
Amount of memory allocated for page tables.
+ sec_pagetables
+ Amount of memory allocated for secondary page tables,
+ this currently includes KVM mmu allocations on x86
+ and arm64 and IOMMU page tables.
+
percpu (npn)
Amount of memory used for storing per-cpu kernel
data structures.
@@ -1376,7 +1587,10 @@ PAGE_SIZE multiple when read back.
Amount of application memory swapped out to zswap.
file_mapped
- Amount of cached filesystem data mapped with mmap()
+ Amount of cached filesystem data mapped with mmap(). Note
+ that some kernel configurations might account complete
+ larger allocations (e.g., THP) if only some, but not
+ not all the memory of such an allocation is mapped.
file_dirty
Amount of cached filesystem data that was modified but
@@ -1448,6 +1662,12 @@ PAGE_SIZE multiple when read back.
workingset_nodereclaim
Number of times a shadow node has been reclaimed
+ pswpin (npn)
+ Number of pages swapped into memory
+
+ pswpout (npn)
+ Number of pages swapped out of memory
+
pgscan (npn)
Amount of scanned pages (in an inactive LRU list)
@@ -1460,12 +1680,24 @@ PAGE_SIZE multiple when read back.
pgscan_direct (npn)
Amount of scanned pages directly (in an inactive LRU list)
+ pgscan_khugepaged (npn)
+ Amount of scanned pages by khugepaged (in an inactive LRU list)
+
+ pgscan_proactive (npn)
+ Amount of scanned pages proactively (in an inactive LRU list)
+
pgsteal_kswapd (npn)
Amount of reclaimed pages by kswapd
pgsteal_direct (npn)
Amount of reclaimed pages directly
+ pgsteal_khugepaged (npn)
+ Amount of reclaimed pages by khugepaged
+
+ pgsteal_proactive (npn)
+ Amount of reclaimed pages proactively
+
pgfault (npn)
Total number of page faults incurred
@@ -1487,6 +1719,24 @@ PAGE_SIZE multiple when read back.
pglazyfreed (npn)
Amount of reclaimed lazyfree pages
+ swpin_zero
+ Number of pages swapped into memory and filled with zero, where I/O
+ was optimized out because the page content was detected to be zero
+ during swapout.
+
+ swpout_zero
+ Number of zero-filled pages swapped out with I/O skipped due to the
+ content being detected as zero.
+
+ zswpin
+ Number of pages moved in to memory from zswap.
+
+ zswpout
+ Number of pages moved out of memory to zswap.
+
+ zswpwb
+ Number of pages written from zswap to swap.
+
thp_fault_alloc (npn)
Number of transparent hugepages which were allocated to satisfy
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
@@ -1497,6 +1747,42 @@ PAGE_SIZE multiple when read back.
collapsing an existing range of pages. This counter is not
present when CONFIG_TRANSPARENT_HUGEPAGE is not set.
+ thp_swpout (npn)
+ Number of transparent hugepages which are swapout in one piece
+ without splitting.
+
+ thp_swpout_fallback (npn)
+ Number of transparent hugepages which were split before swapout.
+ Usually because failed to allocate some continuous swap space
+ for the huge page.
+
+ numa_pages_migrated (npn)
+ Number of pages migrated by NUMA balancing.
+
+ numa_pte_updates (npn)
+ Number of pages whose page table entries are modified by
+ NUMA balancing to produce NUMA hinting faults on access.
+
+ numa_hint_faults (npn)
+ Number of NUMA hinting faults.
+
+ pgdemote_kswapd
+ Number of pages demoted by kswapd.
+
+ pgdemote_direct
+ Number of pages demoted directly.
+
+ pgdemote_khugepaged
+ Number of pages demoted by khugepaged.
+
+ pgdemote_proactive
+ Number of pages demoted by proactively.
+
+ hugetlb
+ Amount of memory used by hugetlb pages. This metric only shows
+ up if hugetlb usage is accounted for in memory.current (i.e.
+ cgroup is mounted with the memory_hugetlb_accounting option).
+
memory.numa_stat
A read-only nested-keyed file which exists on non-root cgroups.
@@ -1545,6 +1831,16 @@ PAGE_SIZE multiple when read back.
Healthy workloads are not expected to reach this limit.
+ memory.swap.peak
+ A read-write single value file which exists on non-root cgroups.
+
+ The max swap usage recorded for the cgroup and its descendants since
+ the creation of the cgroup or the most recent reset for that FD.
+
+ A write of any non-empty string to this file resets it to the
+ current memory usage for subsequent reads through the same
+ file descriptor.
+
memory.swap.max
A read-write single value file which exists on non-root
cgroups. The default is "max".
@@ -1592,6 +1888,24 @@ PAGE_SIZE multiple when read back.
limit, it will refuse to take any more stores before existing
entries fault back in or are written out to disk.
+ memory.zswap.writeback
+ A read-write single value file. The default value is "1".
+ Note that this setting is hierarchical, i.e. the writeback would be
+ implicitly disabled for child cgroups if the upper hierarchy
+ does so.
+
+ When this is set to 0, all swapping attempts to swapping devices
+ are disabled. This included both zswap writebacks, and swapping due
+ to zswap store failures. If the zswap store failures are recurring
+ (for e.g if the pages are incompressible), users can observe
+ reclaim inefficiency after disabling writeback (because the same
+ pages might be rejected again and again).
+
+ Note that this is subtly different from setting memory.swap.max to
+ 0, as it still allows for pages to be written to the zswap pool.
+ This setting has no effect if zswap is disabled, and swapping
+ is allowed unless memory.swap.max is set to 0.
+
memory.pressure
A read-only nested-keyed file.
@@ -1622,6 +1936,27 @@ memory - is necessary to determine whether a workload needs more
memory; unfortunately, memory pressure monitoring mechanism isn't
implemented yet.
+Reclaim Protection
+~~~~~~~~~~~~~~~~~~
+
+The protection configured with "memory.low" or "memory.min" applies relatively
+to the target of the reclaim (i.e. any of memory cgroup limits, proactive
+memory.reclaim or global reclaim apparently located in the root cgroup).
+The protection value configured for B applies unchanged to the reclaim
+targeting A (i.e. caused by competition with the sibling E)::
+
+ root - ... - A - B - C
+ \ ` D
+ ` E
+
+When the reclaim targets ancestors of A, the effective protection of B is
+capped by the protection value configured for A (and any other intermediate
+ancestors between A and the target).
+
+To express indifference about relative sibling protection, it is suggested to
+use memory_recursiveprot. Configuring all descendants of a parent with finite
+protection to "max" works but it may unnecessarily skew memory.events:low
+field.
Memory Ownership
~~~~~~~~~~~~~~~~
@@ -1981,37 +2316,41 @@ IO Priority
~~~~~~~~~~~
A single attribute controls the behavior of the I/O priority cgroup policy,
-namely the blkio.prio.class attribute. The following values are accepted for
+namely the io.prio.class attribute. The following values are accepted for
that attribute:
no-change
Do not modify the I/O priority class.
- none-to-rt
- For requests that do not have an I/O priority class (NONE),
- change the I/O priority class into RT. Do not modify
- the I/O priority class of other requests.
+ promote-to-rt
+ For requests that have a non-RT I/O priority class, change it into RT.
+ Also change the priority level of these requests to 4. Do not modify
+ the I/O priority of requests that have priority class RT.
restrict-to-be
For requests that do not have an I/O priority class or that have I/O
- priority class RT, change it into BE. Do not modify the I/O priority
- class of requests that have priority class IDLE.
+ priority class RT, change it into BE. Also change the priority level
+ of these requests to 0. Do not modify the I/O priority class of
+ requests that have priority class IDLE.
idle
Change the I/O priority class of all requests into IDLE, the lowest
I/O priority class.
+ none-to-rt
+ Deprecated. Just an alias for promote-to-rt.
+
The following numerical values are associated with the I/O priority policies:
-+-------------+---+
-| no-change | 0 |
-+-------------+---+
-| none-to-rt | 1 |
-+-------------+---+
-| rt-to-be | 2 |
-+-------------+---+
-| all-to-idle | 3 |
-+-------------+---+
++----------------+---+
+| no-change | 0 |
++----------------+---+
+| promote-to-rt | 1 |
++----------------+---+
+| restrict-to-be | 2 |
++----------------+---+
+| idle | 3 |
++----------------+---+
The numerical value that corresponds to each I/O priority class is as follows:
@@ -2027,9 +2366,13 @@ The numerical value that corresponds to each I/O priority class is as follows:
The algorithm to set the I/O priority class for a request is as follows:
-- Translate the I/O priority class policy into a number.
-- Change the request I/O priority class into the maximum of the I/O priority
- class policy number and the numerical I/O priority class.
+- If I/O priority class policy is promote-to-rt, change the request I/O
+ priority class to IOPRIO_CLASS_RT and change the request I/O priority
+ level to 4.
+- If I/O priority class policy is not promote-to-rt, translate the I/O priority
+ class policy into a number, then change the request I/O priority class
+ into the maximum of the I/O priority class policy number and the numerical
+ I/O priority class.
PID
---
@@ -2057,11 +2400,31 @@ PID Interface Files
Hard limit of number of processes.
pids.current
- A read-only single value file which exists on all cgroups.
+ A read-only single value file which exists on non-root cgroups.
The number of processes currently in the cgroup and its
descendants.
+ pids.peak
+ A read-only single value file which exists on non-root cgroups.
+
+ The maximum value that the number of processes in the cgroup and its
+ descendants has ever reached.
+
+ pids.events
+ A read-only flat-keyed file which exists on non-root cgroups. Unless
+ specified otherwise, a value change in this file generates a file
+ modified event. The following entries are defined.
+
+ max
+ The number of times the cgroup's total number of processes hit the pids.max
+ limit (see also pids_localevents).
+
+ pids.events.local
+ Similar to pids.events but the fields in the file are local
+ to the cgroup i.e. not hierarchical. The file modified event
+ generated on this file reflects only the local events.
+
Organisational operations are not blocked by cgroup policies, so it is
possible to have pids.current > pids.max. This can be done by either
setting the limit to be smaller than pids.current, or attaching enough
@@ -2178,6 +2541,60 @@ Cpuset Interface Files
Its value will be affected by memory nodes hotplug events.
+ cpuset.cpus.exclusive
+ A read-write multiple values file which exists on non-root
+ cpuset-enabled cgroups.
+
+ It lists all the exclusive CPUs that are allowed to be used
+ to create a new cpuset partition. Its value is not used
+ unless the cgroup becomes a valid partition root. See the
+ "cpuset.cpus.partition" section below for a description of what
+ a cpuset partition is.
+
+ When the cgroup becomes a partition root, the actual exclusive
+ CPUs that are allocated to that partition are listed in
+ "cpuset.cpus.exclusive.effective" which may be different
+ from "cpuset.cpus.exclusive". If "cpuset.cpus.exclusive"
+ has previously been set, "cpuset.cpus.exclusive.effective"
+ is always a subset of it.
+
+ Users can manually set it to a value that is different from
+ "cpuset.cpus". One constraint in setting it is that the list of
+ CPUs must be exclusive with respect to "cpuset.cpus.exclusive"
+ of its sibling. If "cpuset.cpus.exclusive" of a sibling cgroup
+ isn't set, its "cpuset.cpus" value, if set, cannot be a subset
+ of it to leave at least one CPU available when the exclusive
+ CPUs are taken away.
+
+ For a parent cgroup, any one of its exclusive CPUs can only
+ be distributed to at most one of its child cgroups. Having an
+ exclusive CPU appearing in two or more of its child cgroups is
+ not allowed (the exclusivity rule). A value that violates the
+ exclusivity rule will be rejected with a write error.
+
+ The root cgroup is a partition root and all its available CPUs
+ are in its exclusive CPU set.
+
+ cpuset.cpus.exclusive.effective
+ A read-only multiple values file which exists on all non-root
+ cpuset-enabled cgroups.
+
+ This file shows the effective set of exclusive CPUs that
+ can be used to create a partition root. The content
+ of this file will always be a subset of its parent's
+ "cpuset.cpus.exclusive.effective" if its parent is not the root
+ cgroup. It will also be a subset of "cpuset.cpus.exclusive"
+ if it is set. If "cpuset.cpus.exclusive" is not set, it is
+ treated to have an implicit value of "cpuset.cpus" in the
+ formation of local partition.
+
+ cpuset.cpus.isolated
+ A read-only and root cgroup only multiple values file.
+
+ This file shows the set of all isolated CPUs used in existing
+ isolated partitions. It will be empty if no isolated partition
+ is created.
+
cpuset.cpus.partition
A read-write single value file which exists on non-root
cpuset-enabled cgroups. This flag is owned by the parent cgroup
@@ -2185,75 +2602,109 @@ Cpuset Interface Files
It accepts only the following input values when written to.
- ======== ================================
- "root" a partition root
- "member" a non-root member of a partition
- ======== ================================
-
- When set to be a partition root, the current cgroup is the
- root of a new partition or scheduling domain that comprises
- itself and all its descendants except those that are separate
- partition roots themselves and their descendants. The root
- cgroup is always a partition root.
-
- There are constraints on where a partition root can be set.
- It can only be set in a cgroup if all the following conditions
- are true.
-
- 1) The "cpuset.cpus" is not empty and the list of CPUs are
- exclusive, i.e. they are not shared by any of its siblings.
- 2) The parent cgroup is a partition root.
- 3) The "cpuset.cpus" is also a proper subset of the parent's
- "cpuset.cpus.effective".
- 4) There is no child cgroups with cpuset enabled. This is for
- eliminating corner cases that have to be handled if such a
- condition is allowed.
-
- Setting it to partition root will take the CPUs away from the
- effective CPUs of the parent cgroup. Once it is set, this
- file cannot be reverted back to "member" if there are any child
- cgroups with cpuset enabled.
-
- A parent partition cannot distribute all its CPUs to its
- child partitions. There must be at least one cpu left in the
- parent partition.
-
- Once becoming a partition root, changes to "cpuset.cpus" is
- generally allowed as long as the first condition above is true,
- the change will not take away all the CPUs from the parent
- partition and the new "cpuset.cpus" value is a superset of its
- children's "cpuset.cpus" values.
-
- Sometimes, external factors like changes to ancestors'
- "cpuset.cpus" or cpu hotplug can cause the state of the partition
- root to change. On read, the "cpuset.sched.partition" file
- can show the following values.
-
- ============== ==============================
- "member" Non-root member of a partition
- "root" Partition root
- "root invalid" Invalid partition root
- ============== ==============================
-
- It is a partition root if the first 2 partition root conditions
- above are true and at least one CPU from "cpuset.cpus" is
- granted by the parent cgroup.
-
- A partition root can become invalid if none of CPUs requested
- in "cpuset.cpus" can be granted by the parent cgroup or the
- parent cgroup is no longer a partition root itself. In this
- case, it is not a real partition even though the restriction
- of the first partition root condition above will still apply.
- The cpu affinity of all the tasks in the cgroup will then be
- associated with CPUs in the nearest ancestor partition.
-
- An invalid partition root can be transitioned back to a
- real partition root if at least one of the requested CPUs
- can now be granted by its parent. In this case, the cpu
- affinity of all the tasks in the formerly invalid partition
- will be associated to the CPUs of the newly formed partition.
- Changing the partition state of an invalid partition root to
- "member" is always allowed even if child cpusets are present.
+ ========== =====================================
+ "member" Non-root member of a partition
+ "root" Partition root
+ "isolated" Partition root without load balancing
+ ========== =====================================
+
+ A cpuset partition is a collection of cpuset-enabled cgroups with
+ a partition root at the top of the hierarchy and its descendants
+ except those that are separate partition roots themselves and
+ their descendants. A partition has exclusive access to the
+ set of exclusive CPUs allocated to it. Other cgroups outside
+ of that partition cannot use any CPUs in that set.
+
+ There are two types of partitions - local and remote. A local
+ partition is one whose parent cgroup is also a valid partition
+ root. A remote partition is one whose parent cgroup is not a
+ valid partition root itself. Writing to "cpuset.cpus.exclusive"
+ is optional for the creation of a local partition as its
+ "cpuset.cpus.exclusive" file will assume an implicit value that
+ is the same as "cpuset.cpus" if it is not set. Writing the
+ proper "cpuset.cpus.exclusive" values down the cgroup hierarchy
+ before the target partition root is mandatory for the creation
+ of a remote partition.
+
+ Currently, a remote partition cannot be created under a local
+ partition. All the ancestors of a remote partition root except
+ the root cgroup cannot be a partition root.
+
+ The root cgroup is always a partition root and its state cannot
+ be changed. All other non-root cgroups start out as "member".
+
+ When set to "root", the current cgroup is the root of a new
+ partition or scheduling domain. The set of exclusive CPUs is
+ determined by the value of its "cpuset.cpus.exclusive.effective".
+
+ When set to "isolated", the CPUs in that partition will be in
+ an isolated state without any load balancing from the scheduler
+ and excluded from the unbound workqueues. Tasks placed in such
+ a partition with multiple CPUs should be carefully distributed
+ and bound to each of the individual CPUs for optimal performance.
+
+ A partition root ("root" or "isolated") can be in one of the
+ two possible states - valid or invalid. An invalid partition
+ root is in a degraded state where some state information may
+ be retained, but behaves more like a "member".
+
+ All possible state transitions among "member", "root" and
+ "isolated" are allowed.
+
+ On read, the "cpuset.cpus.partition" file can show the following
+ values.
+
+ ============================= =====================================
+ "member" Non-root member of a partition
+ "root" Partition root
+ "isolated" Partition root without load balancing
+ "root invalid (<reason>)" Invalid partition root
+ "isolated invalid (<reason>)" Invalid isolated partition root
+ ============================= =====================================
+
+ In the case of an invalid partition root, a descriptive string on
+ why the partition is invalid is included within parentheses.
+
+ For a local partition root to be valid, the following conditions
+ must be met.
+
+ 1) The parent cgroup is a valid partition root.
+ 2) The "cpuset.cpus.exclusive.effective" file cannot be empty,
+ though it may contain offline CPUs.
+ 3) The "cpuset.cpus.effective" cannot be empty unless there is
+ no task associated with this partition.
+
+ For a remote partition root to be valid, all the above conditions
+ except the first one must be met.
+
+ External events like hotplug or changes to "cpuset.cpus" or
+ "cpuset.cpus.exclusive" can cause a valid partition root to
+ become invalid and vice versa. Note that a task cannot be
+ moved to a cgroup with empty "cpuset.cpus.effective".
+
+ A valid non-root parent partition may distribute out all its CPUs
+ to its child local partitions when there is no task associated
+ with it.
+
+ Care must be taken to change a valid partition root to "member"
+ as all its child local partitions, if present, will become
+ invalid causing disruption to tasks running in those child
+ partitions. These inactivated partitions could be recovered if
+ their parent is switched back to a partition root with a proper
+ value in "cpuset.cpus" or "cpuset.cpus.exclusive".
+
+ Poll and inotify events are triggered whenever the state of
+ "cpuset.cpus.partition" changes. That includes changes caused
+ by write to "cpuset.cpus.partition", cpu hotplug or other
+ changes that modify the validity status of the partition.
+ This will allow user space agents to monitor unexpected changes
+ to "cpuset.cpus.partition" without the need to do continuous
+ polling.
+
+ A user can pre-configure certain CPUs to an isolated state
+ with load balancing disabled at boot time with the "isolcpus"
+ kernel boot command line option. If those CPUs are to be put
+ into a partition, they have to be used in an isolated partition.
Device controller
@@ -2319,6 +2770,49 @@ RDMA Interface Files
mlx4_0 hca_handle=1 hca_object=20
ocrdma1 hca_handle=1 hca_object=23
+DMEM
+----
+
+The "dmem" controller regulates the distribution and accounting of
+device memory regions. Because each memory region may have its own page size,
+which does not have to be equal to the system page size, the units are always bytes.
+
+DMEM Interface Files
+~~~~~~~~~~~~~~~~~~~~
+
+ dmem.max, dmem.min, dmem.low
+ A readwrite nested-keyed file that exists for all the cgroups
+ except root that describes current configured resource limit
+ for a region.
+
+ An example for xe follows::
+
+ drm/0000:03:00.0/vram0 1073741824
+ drm/0000:03:00.0/stolen max
+
+ The semantics are the same as for the memory cgroup controller, and are
+ calculated in the same way.
+
+ dmem.capacity
+ A read-only file that describes maximum region capacity.
+ It only exists on the root cgroup. Not all memory can be
+ allocated by cgroups, as the kernel reserves some for
+ internal use.
+
+ An example for xe follows::
+
+ drm/0000:03:00.0/vram0 8514437120
+ drm/0000:03:00.0/stolen 67108864
+
+ dmem.current
+ A read-only file that describes current resource usage.
+ It exists for all the cgroup except root.
+
+ An example for xe follows::
+
+ drm/0000:03:00.0/vram0 12550144
+ drm/0000:03:00.0/stolen 8650752
+
HugeTLB
-------
@@ -2384,13 +2878,22 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_
res_b 10
misc.current
- A read-only flat-keyed file shown in the non-root cgroups. It shows
+ A read-only flat-keyed file shown in the all cgroups. It shows
the current usage of the resources in the cgroup and its children.::
$ cat misc.current
res_a 3
res_b 0
+ misc.peak
+ A read-only flat-keyed file shown in all cgroups. It shows the
+ historical maximum usage of the resources in the cgroup and its
+ children.::
+
+ $ cat misc.peak
+ res_a 10
+ res_b 8
+
misc.max
A read-write flat-keyed file shown in the non root cgroups. Allowed
maximum usage of the resources in the cgroup and its children.::
@@ -2420,6 +2923,11 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_
The number of times the cgroup's resource usage was
about to go over the max boundary.
+ misc.events.local
+ Similar to misc.events but the fields in the file are local to the
+ cgroup i.e. not hierarchical. The file modified event generated on
+ this file reflects only the local events.
+
Migration and Ownership
~~~~~~~~~~~~~~~~~~~~~~~
@@ -2628,7 +3136,7 @@ Filesystem Support for Writeback
--------------------------------
A filesystem can support cgroup writeback by updating
-address_space_operations->writepage[s]() to annotate bio's using the
+address_space_operations->writepages() to annotate bio's using the
following two functions.
wbc_init_bio(@wbc, @bio)
@@ -2638,7 +3146,7 @@ following two functions.
a queue (device) has been associated with the bio and
before submission.
- wbc_account_cgroup_owner(@wbc, @page, @bytes)
+ wbc_account_cgroup_owner(@wbc, @folio, @bytes)
Should be called for each data segment being written out.
While this function doesn't care exactly when it's called
during the writeback session, it's the easiest and most
@@ -2670,8 +3178,8 @@ Deprecated v1 Core Features
- "cgroup.clone_children" is removed.
-- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" file
- at the root instead.
+- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" or
+ "cgroup.stat" files at the root instead.
Issues with v1 and Rationales for v2
diff --git a/Documentation/admin-guide/cifs/changes.rst b/Documentation/admin-guide/cifs/changes.rst
index 3147bbae9c43..8c42c4de510b 100644
--- a/Documentation/admin-guide/cifs/changes.rst
+++ b/Documentation/admin-guide/cifs/changes.rst
@@ -5,5 +5,5 @@ Changes
See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary
information about fixes/improvements to CIFS/SMB2/SMB3 support (changes
to cifs.ko module) by kernel version (and cifs internal module version).
-This may be easier to read than parsing the output of "git log fs/cifs"
-by release.
+This may be easier to read than parsing the output of
+"git log fs/smb/client" by release.
diff --git a/Documentation/admin-guide/cifs/introduction.rst b/Documentation/admin-guide/cifs/introduction.rst
index 53ea62906aa5..ffc6e2564dd5 100644
--- a/Documentation/admin-guide/cifs/introduction.rst
+++ b/Documentation/admin-guide/cifs/introduction.rst
@@ -28,7 +28,7 @@ Introduction
high performance safe distributed caching (leases/oplocks), optional packet
signing, large files, Unicode support and other internationalization
improvements. Since both Samba server and this filesystem client support the
- CIFS Unix extensions, and the Linux client also suppors SMB3 POSIX extensions,
+ CIFS Unix extensions, and the Linux client also supports SMB3 POSIX extensions,
the combination can provide a reasonable alternative to other network and
cluster file systems for fileserving in some Linux to Linux environments,
not just in Linux to Windows (or Linux to Mac) environments.
diff --git a/Documentation/admin-guide/cifs/todo.rst b/Documentation/admin-guide/cifs/todo.rst
index 2646ed2e2d3e..9a65c670774e 100644
--- a/Documentation/admin-guide/cifs/todo.rst
+++ b/Documentation/admin-guide/cifs/todo.rst
@@ -2,7 +2,8 @@
TODO
====
-Version 2.14 December 21, 2018
+As of 6.7 kernel. See https://wiki.samba.org/index.php/LinuxCIFSKernel
+for list of features added by release
A Partial List of Missing Features
==================================
@@ -12,22 +13,22 @@ for visible, important contributions to this module. Here
is a partial list of the known problems and missing features:
a) SMB3 (and SMB3.1.1) missing optional features:
+ multichannel performance optimizations, algorithmic channel selection,
+ directory leases optimizations,
+ support for faster packet signing (GMAC),
+ support for compression over the network,
+ T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
+ are currently the only two server side copy mechanisms supported)
- - multichannel (partially integrated), integration of multichannel with RDMA
- - directory leases (improved metadata caching). Currently only implemented for root dir
- - T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
- currently the only two server side copy mechanisms supported)
+b) Better optimized compounding and error handling for sparse file support,
+ perhaps addition of new optional SMB3.1.1 fsctls to make collapse range
+ and insert range more atomic
-b) improved sparse file support (fiemap and SEEK_HOLE are implemented
- but additional features would be supportable by the protocol such
- as FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE)
-
-c) Directory entry caching relies on a 1 second timer, rather than
- using Directory Leases, currently only the root file handle is cached longer
- by leveraging Directory Leases
+c) Support for SMB3.1.1 over QUIC (and perhaps other socket based protocols
+ like SCTP)
d) quota support (needs minor kernel change since quota calls otherwise
- won't make it to network filesystems or deviceless filesystems).
+ won't make it to network filesystems or deviceless filesystems).
e) Additional use cases can be optimized to use "compounding" (e.g.
open/query/close and open/setinfo/close) to reduce the number of
@@ -92,23 +93,20 @@ t) split cifs and smb3 support into separate modules so legacy (and less
v) Additional testing of POSIX Extensions for SMB3.1.1
-w) Add support for additional strong encryption types, and additional spnego
- authentication mechanisms (see MS-SMB2). GCM-256 is now partially implemented.
+w) Support for the Mac SMB3.1.1 extensions to improve interop with Apple servers
+
+x) Support for additional authentication options (e.g. IAKERB, peer-to-peer
+ Kerberos, SCRAM and others supported by existing servers)
-x) Finish support for SMB3.1.1 compression
+y) Improved tracing, more eBPF trace points, better scripts for performance
+ analysis
Known Bugs
==========
See https://bugzilla.samba.org - search on product "CifsVFS" for
current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS)
-
-1) existing symbolic links (Windows reparse points) are recognized but
- can not be created remotely. They are implemented for Samba and those that
- support the CIFS Unix extensions, although earlier versions of Samba
- overly restrict the pathnames.
-2) follow_link and readdir code does not follow dfs junctions
- but recognizes them
+and xfstest results e.g. https://wiki.samba.org/index.php/Xfstest-results-smb3
Misc testing to do
==================
diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst
index 3766bf8a1c20..d989ae5778ba 100644
--- a/Documentation/admin-guide/cifs/usage.rst
+++ b/Documentation/admin-guide/cifs/usage.rst
@@ -45,7 +45,7 @@ Installation instructions
If you have built the CIFS vfs as module (successfully) simply
type ``make modules_install`` (or if you prefer, manually copy the file to
-the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko).
+the modules directory e.g. /lib/modules/6.3.0-060300-generic/kernel/fs/smb/client/cifs.ko).
If you have built the CIFS vfs into the kernel itself, follow the instructions
for your distribution on how to install a new kernel (usually you
@@ -66,22 +66,22 @@ If cifs is built as a module, then the size and number of network buffers
and maximum number of simultaneous requests to one server can be configured.
Changing these from their defaults is not recommended. By executing modinfo::
- modinfo kernel/fs/cifs/cifs.ko
+ modinfo <path to cifs.ko>
-on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made
+on kernel/fs/smb/client/cifs.ko the list of configuration changes that can be made
at module initialization time (by running insmod cifs.ko) can be seen.
Recommendations
===============
-To improve security the SMB2.1 dialect or later (usually will get SMB3) is now
+To improve security the SMB2.1 dialect or later (usually will get SMB3.1.1) is now
the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0"
on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is
much older and less secure than the default dialect SMB3 which includes
many advanced security features such as downgrade attack detection
and encrypted shares and stronger signing and authentication algorithms.
There are additional mount options that may be helpful for SMB3 to get
-improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
+improved POSIX behavior (NB: can use vers=3 to force SMB3 or later, never 2.1):
``mfsymlinks`` and either ``cifsacl`` or ``modefromsid`` (usually with ``idsfromsid``)
@@ -270,6 +270,8 @@ configured for Unix Extensions (and the client has not disabled
illegal Windows/NTFS/SMB characters to a remap range (this mount parameter
is the default for SMB3). This remap (``mapposix``) range is also
compatible with Mac (and "Services for Mac" on some older Windows).
+When POSIX Extensions for SMB 3.1.1 are negotiated, remapping is automatically
+disabled.
CIFS VFS Mount Options
======================
@@ -399,7 +401,7 @@ A partial list of the supported mount options follows:
sep
if first mount option (after the -o), overrides
the comma as the separator between the mount
- parms. e.g.::
+ parameters. e.g.::
-o user=myname,password=mypassword,domain=mydom
@@ -715,6 +717,7 @@ DebugData Displays information about active CIFS sessions and
Stats Lists summary resource usage information as well as per
share statistics.
open_files List all the open file handles on all active SMB sessions.
+mount_params List of all mount parameters available for the module
======================= =======================================================
Configuration pseudo-files:
@@ -722,40 +725,26 @@ Configuration pseudo-files:
======================= =======================================================
SecurityFlags Flags which control security negotiation and
also packet signing. Authentication (may/must)
- flags (e.g. for NTLM and/or NTLMv2) may be combined with
+ flags (e.g. for NTLMv2) may be combined with
the signing flags. Specifying two different password
hashing mechanisms (as "must use") on the other hand
does not make much sense. Default flags are::
- 0x07007
-
- (NTLM, NTLMv2 and packet signing allowed). The maximum
- allowable flags if you want to allow mounts to servers
- using weaker password hashes is 0x37037 (lanman,
- plaintext, ntlm, ntlmv2, signing allowed). Some
- SecurityFlags require the corresponding menuconfig
- options to be enabled. Enabling plaintext
- authentication currently requires also enabling
- lanman authentication in the security flags
- because the cifs module only supports sending
- laintext passwords using the older lanman dialect
- form of the session setup SMB. (e.g. for authentication
- using plain text passwords, set the SecurityFlags
- to 0x30030)::
+ 0x00C5
+
+ (NTLMv2 and packet signing allowed). Some SecurityFlags
+ may require enabling a corresponding menuconfig option.
may use packet signing 0x00001
must use packet signing 0x01001
- may use NTLM (most common password hash) 0x00002
- must use NTLM 0x02002
may use NTLMv2 0x00004
must use NTLMv2 0x04004
- may use Kerberos security 0x00008
- must use Kerberos 0x08008
- may use lanman (weak) password hash 0x00010
- must use lanman password hash 0x10010
- may use plaintext passwords 0x00020
- must use plaintext passwords 0x20020
- (reserved for future packet encryption) 0x00040
+ may use Kerberos security (krb5) 0x00008
+ must use Kerberos 0x08008
+ may use NTLMSSP 0x00080
+ must use NTLMSSP 0x80080
+ seal (packet encryption) 0x00040
+ must seal 0x40040
cifsFYI If set to non-zero value, additional debug information
will be logged to the system error log. This field
@@ -765,7 +754,7 @@ cifsFYI If set to non-zero value, additional debug information
Some debugging statements are not compiled into the
cifs kernel unless CONFIG_CIFS_DEBUG2 is enabled in the
kernel configuration. cifsFYI may be set to one or
- nore of the following flags (7 sets them all)::
+ more of the following flags (7 sets them all)::
+-----------------------------------------------+------+
| log cifs informational messages | 0x01 |
@@ -858,12 +847,17 @@ CIFS kernel module parameters
These module parameters can be specified or modified either during the time of
module loading or during the runtime by using the interface::
- /proc/module/cifs/parameters/<param>
+ /sys/module/cifs/parameters/<param>
i.e.::
echo "value" > /sys/module/cifs/parameters/<param>
+More detailed descriptions of the available module parameters and their values
+can be seen by doing:
+
+ modinfo cifs (or modinfo smb3)
+
================= ==========================================================
1. enable_oplocks Enable or disable oplocks. Oplocks are enabled by default.
[Y/y/1]. To disable use any of [N/n/0].
diff --git a/Documentation/admin-guide/device-mapper/cache-policies.rst b/Documentation/admin-guide/device-mapper/cache-policies.rst
index b17fe352fc41..13da4d831d46 100644
--- a/Documentation/admin-guide/device-mapper/cache-policies.rst
+++ b/Documentation/admin-guide/device-mapper/cache-policies.rst
@@ -70,7 +70,7 @@ the entries (each hotspot block covers a larger area than a single
cache block).
All this means smq uses ~25bytes per cache block. Still a lot of
-memory, but a substantial improvement nontheless.
+memory, but a substantial improvement nonetheless.
Level balancing
^^^^^^^^^^^^^^^
diff --git a/Documentation/admin-guide/device-mapper/delay.rst b/Documentation/admin-guide/device-mapper/delay.rst
index 917ba8c33359..a1e673c0e782 100644
--- a/Documentation/admin-guide/device-mapper/delay.rst
+++ b/Documentation/admin-guide/device-mapper/delay.rst
@@ -3,29 +3,52 @@ dm-delay
========
Device-Mapper's "delay" target delays reads and/or writes
-and maps them to different devices.
+and/or flushes and optionally maps them to different devices.
-Parameters::
+Arguments::
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>
[<flush_device> <flush_offset> <flush_delay>]]
-With separate write parameters, the first set is only used for reads.
+Table line has to either have 3, 6 or 9 arguments:
+
+3: apply offset and delay to read, write and flush operations on device
+
+6: apply offset and delay to device, also apply write_offset and write_delay
+ to write and flush operations on optionally different write_device with
+ optionally different sector offset
+
+9: same as 6 arguments plus define flush_offset and flush_delay explicitly
+ on/with optionally different flush_device/flush_offset.
+
Offsets are specified in sectors.
+
Delays are specified in milliseconds.
+
Example scripts
===============
::
-
#!/bin/sh
- # Create device delaying rw operation for 500ms
- echo "0 `blockdev --getsz $1` delay $1 0 500" | dmsetup create delayed
+ #
+ # Create mapped device named "delayed" delaying read, write and flush operations for 500ms.
+ #
+ dmsetup create delayed --table "0 `blockdev --getsz $1` delay $1 0 500"
::
+ #!/bin/sh
+ #
+ # Create mapped device delaying write and flush operations for 400ms and
+ # splitting reads to device $1 but writes and flushes to different device $2
+ # to different offsets of 2048 and 4096 sectors respectively.
+ #
+ dmsetup create delayed --table "0 `blockdev --getsz $1` delay $1 2048 0 $2 4096 400"
+::
#!/bin/sh
- # Create device delaying only write operation for 500ms and
- # splitting reads and writes to different devices $1 $2
- echo "0 `blockdev --getsz $1` delay $1 0 0 $2 0 500" | dmsetup create delayed
+ #
+ # Create mapped device delaying reads for 50ms, writes for 100ms and flushes for 333ms
+ # onto the same backing device at offset 0 sectors.
+ #
+ dmsetup create delayed --table "0 `blockdev --getsz $1` delay $1 0 50 $2 0 100 $1 0 333"
diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst
index aa2d04d95df6..4467f6d4b632 100644
--- a/Documentation/admin-guide/device-mapper/dm-crypt.rst
+++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst
@@ -113,6 +113,11 @@ same_cpu_crypt
The default is to use an unbound workqueue so that encryption work
is automatically balanced between available CPUs.
+high_priority
+ Set dm-crypt workqueues and the writer thread to high priority. This
+ improves throughput and latency of dm-crypt while degrading general
+ responsiveness of the system.
+
submit_from_crypt_cpus
Disable offloading writes to a separate thread after encryption.
There are some situations where offloading write bios from the
@@ -141,6 +146,11 @@ integrity:<bytes>:<type>
integrity for the encrypted device. The additional space is then
used for storing authentication tag (and persistent IV if needed).
+integrity_key_size:<bytes>
+ Optionally set the integrity key size if it differs from the digest size.
+ It allows the use of wrapped key algorithms where the key size is
+ independent of the cryptographic key size.
+
sector_size:<bytes>
Use <bytes> as the encryption unit instead of 512 bytes sectors.
This option can be in range 512 - 4096 bytes and must be power of two.
@@ -155,6 +165,27 @@ iv_large_sectors
The <iv_offset> must be multiple of <sector_size> (in 512 bytes units)
if this flag is specified.
+integrity_key_size:<bytes>
+ Use an integrity key of <bytes> size instead of using an integrity key size
+ of the digest size of the used HMAC algorithm.
+
+
+Module parameters::
+ max_read_size
+ Maximum size of read requests. When a request larger than this size
+ is received, dm-crypt will split the request. The splitting improves
+ concurrency (the split requests could be encrypted in parallel by multiple
+ cores), but it also causes overhead. The user should tune this parameters to
+ fit the actual workload.
+
+ max_write_size
+ Maximum size of write requests. When a request larger than this size
+ is received, dm-crypt will split the request. The splitting improves
+ concurrency (the split requests could be encrypted in parallel by multiple
+ cores), but it also causes overhead. The user should tune this parameters to
+ fit the actual workload.
+
+
Example scripts
===============
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
diff --git a/Documentation/admin-guide/device-mapper/dm-ebs.rst b/Documentation/admin-guide/device-mapper/dm-ebs.rst
index 534fa38e8862..c09f66db5621 100644
--- a/Documentation/admin-guide/device-mapper/dm-ebs.rst
+++ b/Documentation/admin-guide/device-mapper/dm-ebs.rst
@@ -31,7 +31,7 @@ Mandatory parameters:
Optional parameter:
- <underyling sectors>:
+ <underlying sectors>:
Number of sectors defining the logical block size of <dev path>.
2^N supported, e.g. 8 = emulate 8 sectors of 512 bytes = 4KiB.
If not provided, the logical block size of <dev path> will be used.
diff --git a/Documentation/admin-guide/device-mapper/dm-flakey.rst b/Documentation/admin-guide/device-mapper/dm-flakey.rst
index 86138735879d..f967c5fea219 100644
--- a/Documentation/admin-guide/device-mapper/dm-flakey.rst
+++ b/Documentation/admin-guide/device-mapper/dm-flakey.rst
@@ -39,6 +39,10 @@ Optional feature parameters:
If no feature parameters are present, during the periods of
unreliability, all I/O returns errors.
+ error_reads:
+ All read I/O is failed with an error signalled.
+ Write I/O is handled correctly.
+
drop_writes:
All write I/O is silently ignored.
Read I/O is handled correctly.
@@ -63,6 +67,16 @@ Optional feature parameters:
Perform the replacement only if bio->bi_opf has all the
selected flags set.
+ random_read_corrupt <probability>
+ During <down interval>, replace random byte in a read bio
+ with a random value. probability is an integer between
+ 0 and 1000000000 meaning 0% to 100% probability of corruption.
+
+ random_write_corrupt <probability>
+ During <down interval>, replace random byte in a write bio
+ with a random value. probability is an integer between
+ 0 and 1000000000 meaning 0% to 100% probability of corruption.
+
Examples:
Replaces the 32nd byte of READ bios with the value 1::
diff --git a/Documentation/admin-guide/device-mapper/dm-init.rst b/Documentation/admin-guide/device-mapper/dm-init.rst
index e5242ff17e9b..981d6a907699 100644
--- a/Documentation/admin-guide/device-mapper/dm-init.rst
+++ b/Documentation/admin-guide/device-mapper/dm-init.rst
@@ -123,3 +123,11 @@ Other examples (per target):
0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256
fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd
51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584
+
+For setups using device-mapper on top of asynchronously probed block
+devices (MMC, USB, ..), it may be necessary to tell dm-init to
+explicitly wait for them to become available before setting up the
+device-mapper tables. This can be done with the "dm-mod.waitfor="
+module parameter, which takes a list of devices to wait for::
+
+ dm-mod.waitfor=<device1>[,..,<deviceN>]
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 8db172efa272..c2e18ecc065c 100644
--- a/Documentation/admin-guide/device-mapper/dm-integrity.rst
+++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst
@@ -25,7 +25,7 @@ mode it calculates and verifies the integrity tag internally. In this
mode, the dm-integrity target can be used to detect silent data
corruption on the disk or in the I/O path.
-There's an alternate mode of operation where dm-integrity uses bitmap
+There's an alternate mode of operation where dm-integrity uses a bitmap
instead of a journal. If a bit in the bitmap is 1, the corresponding
region's data and integrity tags are not synchronized - if the machine
crashes, the unsynchronized regions will be recalculated. The bitmap mode
@@ -38,6 +38,15 @@ the device. But it will only format the device if the superblock contains
zeroes. If the superblock is neither valid nor zeroed, the dm-integrity
target can't be loaded.
+Accesses to the on-disk metadata area containing checksums (aka tags) are
+buffered using dm-bufio. When an access to any given metadata area
+occurs, each unique metadata area gets its own buffer(s). The buffer size
+is capped at the size of the metadata area, but may be smaller, thereby
+requiring multiple buffers to represent the full metadata area. A smaller
+buffer size will produce a smaller resulting read/write operation to the
+metadata area for small reads/writes. The metadata is still read even in
+a full write to the data covered by a single buffer.
+
To use the target for the first time:
1. overwrite the superblock with zeroes
@@ -83,6 +92,11 @@ Target arguments:
allowed. This mode is useful for data recovery if the
device cannot be activated in any of the other standard
modes.
+ I - inline mode - in this mode, dm-integrity will store integrity
+ data directly in the underlying device sectors.
+ The underlying device must have an integrity profile that
+ allows storing user integrity data and provides enough
+ space for the selected integrity tag.
5. the number of additional arguments
@@ -93,7 +107,7 @@ journal_sectors:number
device. If the device is already formatted, the value from the
superblock is used.
-interleave_sectors:number
+interleave_sectors:number (default 32768)
The number of interleaved sectors. This values is rounded down to
a power of two. If the device is already formatted, the value from
the superblock is used.
@@ -102,20 +116,16 @@ meta_device:device
Don't interleave the data and metadata on the device. Use a
separate device for metadata.
-buffer_sectors:number
- The number of sectors in one buffer. The value is rounded down to
- a power of two.
-
- The tag area is accessed using buffers, the buffer size is
- configurable. The large buffer size means that the I/O size will
- be larger, but there could be less I/Os issued.
+buffer_sectors:number (default 128)
+ The number of sectors in one metadata buffer. The value is rounded
+ down to a power of two.
-journal_watermark:number
+journal_watermark:number (default 50)
The journal watermark in percents. When the size of the journal
exceeds this watermark, the thread that flushes the journal will
be started.
-commit_time:number
+commit_time:number (default 10000)
Commit time in milliseconds. When this time passes, the journal is
written. The journal is also written immediately if the FLUSH
request is received.
@@ -163,11 +173,10 @@ journal_mac:algorithm(:key) (the key is optional)
the journal. Thus, modified sector number would be detected at
this stage.
-block_size:number
- The size of a data block in bytes. The larger the block size the
+block_size:number (default 512)
+ The size of a data block in bytes. The larger the block size the
less overhead there is for per-block integrity metadata.
- Supported values are 512, 1024, 2048 and 4096 bytes. If not
- specified the default block size is 512 bytes.
+ Supported values are 512, 1024, 2048 and 4096 bytes.
sectors_per_bit:number
In the bitmap mode, this parameter specifies the number of
@@ -209,6 +218,12 @@ table and swap the tables with suspend and resume). The other arguments
should not be changed when reloading the target because the layout of disk
data depend on them and the reloaded target would be non-functional.
+For example, on a device using the default interleave_sectors of 32768, a
+block_size of 512, and an internal_hash of crc32c with a tag size of 4
+bytes, it will take 128 KiB of tags to track a full data area, requiring
+256 sectors of metadata per data area. With the default buffer_sectors of
+128, that means there will be 2 buffers per metadata area, or 2 buffers
+per 16 MiB of data.
Status line:
@@ -286,7 +301,8 @@ The layout of the formatted block device:
Each run contains:
* tag area - it contains integrity tags. There is one tag for each
- sector in the data area
+ sector in the data area. The size of this area is always 4KiB or
+ greater.
* data area - it contains data sectors. The number of data sectors
in one run must be a power of two. log2 of this value is stored
in the superblock.
diff --git a/Documentation/admin-guide/device-mapper/dm-pcache.rst b/Documentation/admin-guide/device-mapper/dm-pcache.rst
new file mode 100644
index 000000000000..09d327ef4b14
--- /dev/null
+++ b/Documentation/admin-guide/device-mapper/dm-pcache.rst
@@ -0,0 +1,202 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================
+dm-pcache — Persistent Cache
+=================================
+
+*Author: Dongsheng Yang <dongsheng.yang@linux.dev>*
+
+This document describes *dm-pcache*, a Device-Mapper target that lets a
+byte-addressable *DAX* (persistent-memory, “pmem”) region act as a
+high-performance, crash-persistent cache in front of a slower block
+device. The code lives in `drivers/md/dm-pcache/`.
+
+Quick feature summary
+=====================
+
+* *Write-back* caching (only mode currently supported).
+* *16 MiB segments* allocated on the pmem device.
+* *Data CRC32* verification (optional, per cache).
+* Crash-safe: every metadata structure is duplicated (`PCACHE_META_INDEX_MAX
+ == 2`) and protected with CRC+sequence numbers.
+* *Multi-tree indexing* (indexing trees sharded by logical address) for high PMem parallelism
+* Pure *DAX path* I/O – no extra BIO round-trips
+* *Log-structured write-back* that preserves backend crash-consistency
+
+
+Constructor
+===========
+
+::
+
+ pcache <cache_dev> <backing_dev> [<number_of_optional_arguments> <cache_mode writeback> <data_crc true|false>]
+
+========================= ====================================================
+``cache_dev`` Any DAX-capable block device (``/dev/pmem0``…).
+ All metadata *and* cached blocks are stored here.
+
+``backing_dev`` The slow block device to be cached.
+
+``cache_mode`` Optional, Only ``writeback`` is accepted at the
+ moment.
+
+``data_crc`` Optional, default to ``false``
+
+ * ``true`` – store CRC32 for every cached entry
+ and verify on reads
+ * ``false`` – skip CRC (faster)
+========================= ====================================================
+
+Example
+-------
+
+.. code-block:: shell
+
+ dmsetup create pcache_sdb --table \
+ "0 $(blockdev --getsz /dev/sdb) pcache /dev/pmem0 /dev/sdb 4 cache_mode writeback data_crc true"
+
+The first time a pmem device is used, dm-pcache formats it automatically
+(super-block, cache_info, etc.).
+
+
+Status line
+===========
+
+``dmsetup status <device>`` (``STATUSTYPE_INFO``) prints:
+
+::
+
+ <sb_flags> <seg_total> <cache_segs> <segs_used> \
+ <gc_percent> <cache_flags> \
+ <key_head_seg>:<key_head_off> \
+ <dirty_tail_seg>:<dirty_tail_off> \
+ <key_tail_seg>:<key_tail_off>
+
+Field meanings
+--------------
+
+=============================== =============================================
+``sb_flags`` Super-block flags (e.g. endian marker).
+
+``seg_total`` Number of physical *pmem* segments.
+
+``cache_segs`` Number of segments used for cache.
+
+``segs_used`` Segments currently allocated (bitmap weight).
+
+``gc_percent`` Current GC high-water mark (0-90).
+
+``cache_flags`` Bit 0 – DATA_CRC enabled
+ Bit 1 – INIT_DONE (cache initialised)
+ Bits 2-5 – cache mode (0 == WB).
+
+``key_head`` Where new key-sets are being written.
+
+``dirty_tail`` First dirty key-set that still needs
+ write-back to the backing device.
+
+``key_tail`` First key-set that may be reclaimed by GC.
+=============================== =============================================
+
+
+Messages
+========
+
+*Change GC trigger*
+
+::
+
+ dmsetup message <dev> 0 gc_percent <0-90>
+
+
+Theory of operation
+===================
+
+Sub-devices
+-----------
+
+==================== =========================================================
+backing_dev Any block device (SSD/HDD/loop/LVM, etc.).
+cache_dev DAX device; must expose direct-access memory.
+==================== =========================================================
+
+Segments and key-sets
+---------------------
+
+* The pmem space is divided into *16 MiB segments*.
+* Each write allocates space from a per-CPU *data_head* inside a segment.
+* A *cache-key* records a logical range on the origin and where it lives
+ inside pmem (segment + offset + generation).
+* 128 keys form a *key-set* (kset); ksets are written sequentially in pmem
+ and are themselves crash-safe (CRC).
+* The pair *(key_tail, dirty_tail)* delimit clean/dirty and live/dead ksets.
+
+Write-back
+----------
+
+Dirty keys are queued into a tree; a background worker copies data
+back to the backing_dev and advances *dirty_tail*. A FLUSH/FUA bio from the
+upper layers forces an immediate metadata commit.
+
+Garbage collection
+------------------
+
+GC starts when ``segs_used >= seg_total * gc_percent / 100``. It walks
+from *key_tail*, frees segments whose every key has been invalidated, and
+advances *key_tail*.
+
+CRC verification
+----------------
+
+If ``data_crc is enabled`` dm-pcache computes a CRC32 over every cached data
+range when it is inserted and stores it in the on-media key. Reads
+validate the CRC before copying to the caller.
+
+
+Failure handling
+================
+
+* *pmem media errors* – all metadata copies are read with
+ ``copy_mc_to_kernel``; an uncorrectable error logs and aborts initialisation.
+* *Cache full* – if no free segment can be found, writes return ``-EBUSY``;
+ dm-pcache retries internally (request deferral).
+* *System crash* – on attach, the driver replays ksets from *key_tail* to
+ rebuild the in-core trees; every segment’s generation guards against
+ use-after-free keys.
+
+
+Limitations & TODO
+==================
+
+* Only *write-back* mode; other modes planned.
+* Only FIFO cache invalidate; other (LRU, ARC...) planned.
+* Table reload is not supported currently.
+* Discard planned.
+
+
+Example workflow
+================
+
+.. code-block:: shell
+
+ # 1. Create devices
+ dmsetup create pcache_sdb --table \
+ "0 $(blockdev --getsz /dev/sdb) pcache /dev/pmem0 /dev/sdb 4 cache_mode writeback data_crc true"
+
+ # 2. Put a filesystem on top
+ mkfs.ext4 /dev/mapper/pcache_sdb
+ mount /dev/mapper/pcache_sdb /mnt
+
+ # 3. Tune GC threshold to 80 %
+ dmsetup message pcache_sdb 0 gc_percent 80
+
+ # 4. Observe status
+ watch -n1 'dmsetup status pcache_sdb'
+
+ # 5. Shutdown
+ umount /mnt
+ dmsetup remove pcache_sdb
+
+
+``dm-pcache`` is under active development; feedback, bug reports and patches
+are very welcome!
diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst b/Documentation/admin-guide/device-mapper/dm-zoned.rst
index 0fac051caeac..932383fe6e88 100644
--- a/Documentation/admin-guide/device-mapper/dm-zoned.rst
+++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst
@@ -46,7 +46,7 @@ just like conventional zones.
The zones of the device(s) are separated into 2 types:
1) Metadata zones: these are conventional zones used to store metadata.
-Metadata zones are not reported as useable capacity to the user.
+Metadata zones are not reported as usable capacity to the user.
2) Data zones: all remaining zones, the vast majority of which will be
sequential zones used exclusively to store user data. The conventional
diff --git a/Documentation/admin-guide/device-mapper/index.rst b/Documentation/admin-guide/device-mapper/index.rst
index cde52cc09645..f1c1f4b824ba 100644
--- a/Documentation/admin-guide/device-mapper/index.rst
+++ b/Documentation/admin-guide/device-mapper/index.rst
@@ -18,6 +18,7 @@ Device Mapper
dm-integrity
dm-io
dm-log
+ dm-pcache
dm-queue-length
dm-raid
dm-service-time
@@ -34,6 +35,8 @@ Device Mapper
switch
thin-provisioning
unstriped
+ vdo-design
+ vdo
verity
writecache
zero
diff --git a/Documentation/admin-guide/device-mapper/thin-provisioning.rst b/Documentation/admin-guide/device-mapper/thin-provisioning.rst
index bafebf79da4b..b2fa49a5608a 100644
--- a/Documentation/admin-guide/device-mapper/thin-provisioning.rst
+++ b/Documentation/admin-guide/device-mapper/thin-provisioning.rst
@@ -80,11 +80,11 @@ less sharing than average you'll need a larger-than-average metadata device.
As a guide, we suggest you calculate the number of bytes to use in the
metadata device as 48 * $data_dev_size / $data_block_size but round it up
-to 2MB if the answer is smaller. If you're creating large numbers of
+to 2MiB if the answer is smaller. If you're creating large numbers of
snapshots which are recording large amounts of change, you may find you
need to increase this.
-The largest size supported is 16GB: If the device is larger,
+The largest size supported is 16GiB: If the device is larger,
a warning will be issued and the excess space will not be used.
Reloading a pool table
@@ -107,13 +107,13 @@ Using an existing pool device
$data_block_size gives the smallest unit of disk space that can be
allocated at a time expressed in units of 512-byte sectors.
-$data_block_size must be between 128 (64KB) and 2097152 (1GB) and a
-multiple of 128 (64KB). $data_block_size cannot be changed after the
+$data_block_size must be between 128 (64KiB) and 2097152 (1GiB) and a
+multiple of 128 (64KiB). $data_block_size cannot be changed after the
thin-pool is created. People primarily interested in thin provisioning
-may want to use a value such as 1024 (512KB). People doing lots of
-snapshotting may want a smaller value such as 128 (64KB). If you are
+may want to use a value such as 1024 (512KiB). People doing lots of
+snapshotting may want a smaller value such as 128 (64KiB). If you are
not zeroing newly-allocated data, a larger $data_block_size in the
-region of 256000 (128MB) is suggested.
+region of 262144 (128MiB) is suggested.
$low_water_mark is expressed in blocks of size $data_block_size. If
free space on the data device drops below this level then a dm event
@@ -291,7 +291,7 @@ i) Constructor
error_if_no_space:
Error IOs, instead of queueing, if no space.
- Data block size must be between 64KB (128 sectors) and 1GB
+ Data block size must be between 64KiB (128 sectors) and 1GiB
(2097152 sectors) inclusive.
diff --git a/Documentation/admin-guide/device-mapper/unstriped.rst b/Documentation/admin-guide/device-mapper/unstriped.rst
index 0a8d3eb3f072..5772ccdd1f5f 100644
--- a/Documentation/admin-guide/device-mapper/unstriped.rst
+++ b/Documentation/admin-guide/device-mapper/unstriped.rst
@@ -35,7 +35,7 @@ An example of undoing an existing dm-stripe
This small bash script will setup 4 loop devices and use the existing
striped target to combine the 4 devices into one. It then will use
-the unstriped target ontop of the striped device to access the
+the unstriped target on top of the striped device to access the
individual backing loop devices. We write data to the newly exposed
unstriped devices and verify the data written matches the correct
underlying device on the striped array::
@@ -110,8 +110,8 @@ to get a 92% reduction in read latency using this device mapper target.
Example dmsetup usage
=====================
-unstriped ontop of Intel NVMe device that has 2 cores
------------------------------------------------------
+unstriped on top of Intel NVMe device that has 2 cores
+------------------------------------------------------
::
@@ -124,8 +124,8 @@ respectively::
/dev/mapper/nvmset0
/dev/mapper/nvmset1
-unstriped ontop of striped with 4 drives using 128K chunk size
---------------------------------------------------------------
+unstriped on top of striped with 4 drives using 128K chunk size
+---------------------------------------------------------------
::
diff --git a/Documentation/admin-guide/device-mapper/vdo-design.rst b/Documentation/admin-guide/device-mapper/vdo-design.rst
new file mode 100644
index 000000000000..faa0ecd4a5ae
--- /dev/null
+++ b/Documentation/admin-guide/device-mapper/vdo-design.rst
@@ -0,0 +1,633 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+================
+Design of dm-vdo
+================
+
+The dm-vdo (virtual data optimizer) target provides inline deduplication,
+compression, zero-block elimination, and thin provisioning. A dm-vdo target
+can be backed by up to 256TB of storage, and can present a logical size of
+up to 4PB. This target was originally developed at Permabit Technology
+Corp. starting in 2009. It was first released in 2013 and has been used in
+production environments ever since. It was made open-source in 2017 after
+Permabit was acquired by Red Hat. This document describes the design of
+dm-vdo. For usage, see vdo.rst in the same directory as this file.
+
+Because deduplication rates fall drastically as the block size increases, a
+vdo target has a maximum block size of 4K. However, it can achieve
+deduplication rates of 254:1, i.e. up to 254 copies of a given 4K block can
+reference a single 4K of actual storage. It can achieve compression rates
+of 14:1. All zero blocks consume no storage at all.
+
+Theory of Operation
+===================
+
+The design of dm-vdo is based on the idea that deduplication is a two-part
+problem. The first is to recognize duplicate data. The second is to avoid
+storing multiple copies of those duplicates. Therefore, dm-vdo has two main
+parts: a deduplication index (called UDS) that is used to discover
+duplicate data, and a data store with a reference counted block map that
+maps from logical block addresses to the actual storage location of the
+data.
+
+Zones and Threading
+-------------------
+
+Due to the complexity of data optimization, the number of metadata
+structures involved in a single write operation to a vdo target is larger
+than most other targets. Furthermore, because vdo must operate on small
+block sizes in order to achieve good deduplication rates, acceptable
+performance can only be achieved through parallelism. Therefore, vdo's
+design attempts to be lock-free.
+
+Most of a vdo's main data structures are designed to be easily divided into
+"zones" such that any given bio must only access a single zone of any zoned
+structure. Safety with minimal locking is achieved by ensuring that during
+normal operation, each zone is assigned to a specific thread, and only that
+thread will access the portion of the data structure in that zone.
+Associated with each thread is a work queue. Each bio is associated with a
+request object (the "data_vio") which will be added to a work queue when
+the next phase of its operation requires access to the structures in the
+zone associated with that queue.
+
+Another way of thinking about this arrangement is that the work queue for
+each zone has an implicit lock on the structures it manages for all its
+operations, because vdo guarantees that no other thread will alter those
+structures.
+
+Although each structure is divided into zones, this division is not
+reflected in the on-disk representation of each data structure. Therefore,
+the number of zones for each structure, and hence the number of threads,
+can be reconfigured each time a vdo target is started.
+
+The Deduplication Index
+-----------------------
+
+In order to identify duplicate data efficiently, vdo was designed to
+leverage some common characteristics of duplicate data. From empirical
+observations, we gathered two key insights. The first is that in most data
+sets with significant amounts of duplicate data, the duplicates tend to
+have temporal locality. When a duplicate appears, it is more likely that
+other duplicates will be detected, and that those duplicates will have been
+written at about the same time. This is why the index keeps records in
+temporal order. The second insight is that new data is more likely to
+duplicate recent data than it is to duplicate older data and in general,
+there are diminishing returns to looking further back in time. Therefore,
+when the index is full, it should cull its oldest records to make space for
+new ones. Another important idea behind the design of the index is that the
+ultimate goal of deduplication is to reduce storage costs. Since there is a
+trade-off between the storage saved and the resources expended to achieve
+those savings, vdo does not attempt to find every last duplicate block. It
+is sufficient to find and eliminate most of the redundancy.
+
+Each block of data is hashed to produce a 16-byte block name. An index
+record consists of this block name paired with the presumed location of
+that data on the underlying storage. However, it is not possible to
+guarantee that the index is accurate. In the most common case, this occurs
+because it is too costly to update the index when a block is over-written
+or discarded. Doing so would require either storing the block name along
+with the blocks, which is difficult to do efficiently in block-based
+storage, or reading and rehashing each block before overwriting it.
+Inaccuracy can also result from a hash collision where two different blocks
+have the same name. In practice, this is extremely unlikely, but because
+vdo does not use a cryptographic hash, a malicious workload could be
+constructed. Because of these inaccuracies, vdo treats the locations in the
+index as hints, and reads each indicated block to verify that it is indeed
+a duplicate before sharing the existing block with a new one.
+
+Records are collected into groups called chapters. New records are added to
+the newest chapter, called the open chapter. This chapter is stored in a
+format optimized for adding and modifying records, and the content of the
+open chapter is not finalized until it runs out of space for new records.
+When the open chapter fills up, it is closed and a new open chapter is
+created to collect new records.
+
+Closing a chapter converts it to a different format which is optimized for
+reading. The records are written to a series of record pages based on the
+order in which they were received. This means that records with temporal
+locality should be on a small number of pages, reducing the I/O required to
+retrieve them. The chapter also compiles an index that indicates which
+record page contains any given name. This index means that a request for a
+name can determine exactly which record page may contain that record,
+without having to load the entire chapter from storage. This index uses
+only a subset of the block name as its key, so it cannot guarantee that an
+index entry refers to the desired block name. It can only guarantee that if
+there is a record for this name, it will be on the indicated page. Closed
+chapters are read-only structures and their contents are never altered in
+any way.
+
+Once enough records have been written to fill up all the available index
+space, the oldest chapter is removed to make space for new chapters. Any
+time a request finds a matching record in the index, that record is copied
+into the open chapter. This ensures that useful block names remain available
+in the index, while unreferenced block names are forgotten over time.
+
+In order to find records in older chapters, the index also maintains a
+higher level structure called the volume index, which contains entries
+mapping each block name to the chapter containing its newest record. This
+mapping is updated as records for the block name are copied or updated,
+ensuring that only the newest record for a given block name can be found.
+An older record for a block name will no longer be found even though it has
+not been deleted from its chapter. Like the chapter index, the volume index
+uses only a subset of the block name as its key and can not definitively
+say that a record exists for a name. It can only say which chapter would
+contain the record if a record exists. The volume index is stored entirely
+in memory and is saved to storage only when the vdo target is shut down.
+
+From the viewpoint of a request for a particular block name, it will first
+look up the name in the volume index. This search will either indicate that
+the name is new, or which chapter to search. If it returns a chapter, the
+request looks up its name in the chapter index. This will indicate either
+that the name is new, or which record page to search. Finally, if it is not
+new, the request will look for its name in the indicated record page.
+This process may require up to two page reads per request (one for the
+chapter index page and one for the request page). However, recently
+accessed pages are cached so that these page reads can be amortized across
+many block name requests.
+
+The volume index and the chapter indexes are implemented using a
+memory-efficient structure called a delta index. Instead of storing the
+entire block name (the key) for each entry, the entries are sorted by name
+and only the difference between adjacent keys (the delta) is stored.
+Because we expect the hashes to be randomly distributed, the size of the
+deltas follows an exponential distribution. Because of this distribution,
+the deltas are expressed using a Huffman code to take up even less space.
+The entire sorted list of keys is called a delta list. This structure
+allows the index to use many fewer bytes per entry than a traditional hash
+table, but it is slightly more expensive to look up entries, because a
+request must read every entry in a delta list to add up the deltas in order
+to find the record it needs. The delta index reduces this lookup cost by
+splitting its key space into many sub-lists, each starting at a fixed key
+value, so that each individual list is short.
+
+The default index size can hold 64 million records, corresponding to about
+256GB of data. This means that the index can identify duplicate data if the
+original data was written within the last 256GB of writes. This range is
+called the deduplication window. If new writes duplicate data that is older
+than that, the index will not be able to find it because the records of the
+older data have been removed. This means that if an application writes a
+200 GB file to a vdo target and then immediately writes it again, the two
+copies will deduplicate perfectly. Doing the same with a 500 GB file will
+result in no deduplication, because the beginning of the file will no
+longer be in the index by the time the second write begins (assuming there
+is no duplication within the file itself).
+
+If an application anticipates a data workload that will see useful
+deduplication beyond the 256GB threshold, vdo can be configured to use a
+larger index with a correspondingly larger deduplication window. (This
+configuration can only be set when the target is created, not altered
+later. It is important to consider the expected workload for a vdo target
+before configuring it.) There are two ways to do this.
+
+One way is to increase the memory size of the index, which also increases
+the amount of backing storage required. Doubling the size of the index will
+double the length of the deduplication window at the expense of doubling
+the storage size and the memory requirements.
+
+The other option is to enable sparse indexing. Sparse indexing increases
+the deduplication window by a factor of 10, at the expense of also
+increasing the storage size by a factor of 10. However with sparse
+indexing, the memory requirements do not increase. The trade-off is
+slightly more computation per request and a slight decrease in the amount
+of deduplication detected. For most workloads with significant amounts of
+duplicate data, sparse indexing will detect 97-99% of the deduplication
+that a standard index will detect.
+
+The vio and data_vio Structures
+-------------------------------
+
+A vio (short for Vdo I/O) is conceptually similar to a bio, with additional
+fields and data to track vdo-specific information. A struct vio maintains a
+pointer to a bio but also tracks other fields specific to the operation of
+vdo. The vio is kept separate from its related bio because there are many
+circumstances where vdo completes the bio but must continue to do work
+related to deduplication or compression.
+
+Metadata reads and writes, and other writes that originate within vdo, use
+a struct vio directly. Application reads and writes use a larger structure
+called a data_vio to track information about their progress. A struct
+data_vio contain a struct vio and also includes several other fields
+related to deduplication and other vdo features. The data_vio is the
+primary unit of application work in vdo. Each data_vio proceeds through a
+set of steps to handle the application data, after which it is reset and
+returned to a pool of data_vios for reuse.
+
+There is a fixed pool of 2048 data_vios. This number was chosen to bound
+the amount of work that is required to recover from a crash. In addition,
+benchmarks have indicated that increasing the size of the pool does not
+significantly improve performance.
+
+The Data Store
+--------------
+
+The data store is implemented by three main data structures, all of which
+work in concert to reduce or amortize metadata updates across as many data
+writes as possible.
+
+*The Slab Depot*
+
+Most of the vdo volume belongs to the slab depot. The depot contains a
+collection of slabs. The slabs can be up to 32GB, and are divided into
+three sections. Most of a slab consists of a linear sequence of 4K blocks.
+These blocks are used either to store data, or to hold portions of the
+block map (see below). In addition to the data blocks, each slab has a set
+of reference counters, using 1 byte for each data block. Finally each slab
+has a journal.
+
+Reference updates are written to the slab journal. Slab journal blocks are
+written out either when they are full, or when the recovery journal
+requests they do so in order to allow the main recovery journal (see below)
+to free up space. The slab journal is used both to ensure that the main
+recovery journal can regularly free up space, and also to amortize the cost
+of updating individual reference blocks. The reference counters are kept in
+memory and are written out, a block at a time in oldest-dirtied-order, only
+when there is a need to reclaim slab journal space. The write operations
+are performed in the background as needed so they do not add latency to
+particular I/O operations.
+
+Each slab is independent of every other. They are assigned to "physical
+zones" in round-robin fashion. If there are P physical zones, then slab n
+is assigned to zone n mod P.
+
+The slab depot maintains an additional small data structure, the "slab
+summary," which is used to reduce the amount of work needed to come back
+online after a crash. The slab summary maintains an entry for each slab
+indicating whether or not the slab has ever been used, whether all of its
+reference count updates have been persisted to storage, and approximately
+how full it is. During recovery, each physical zone will attempt to recover
+at least one slab, stopping whenever it has recovered a slab which has some
+free blocks. Once each zone has some space, or has determined that none is
+available, the target can resume normal operation in a degraded mode. Read
+and write requests can be serviced, perhaps with degraded performance,
+while the remainder of the dirty slabs are recovered.
+
+*The Block Map*
+
+The block map contains the logical to physical mapping. It can be thought
+of as an array with one entry per logical address. Each entry is 5 bytes,
+36 bits of which contain the physical block number which holds the data for
+the given logical address. The other 4 bits are used to indicate the nature
+of the mapping. Of the 16 possible states, one represents a logical address
+which is unmapped (i.e. it has never been written, or has been discarded),
+one represents an uncompressed block, and the other 14 states are used to
+indicate that the mapped data is compressed, and which of the compression
+slots in the compressed block contains the data for this logical address.
+
+In practice, the array of mapping entries is divided into "block map
+pages," each of which fits in a single 4K block. Each block map page
+consists of a header and 812 mapping entries. Each mapping page is actually
+a leaf of a radix tree which consists of block map pages at each level.
+There are 60 radix trees which are assigned to "logical zones" in round
+robin fashion. (If there are L logical zones, tree n will belong to zone n
+mod L.) At each level, the trees are interleaved, so logical addresses
+0-811 belong to tree 0, logical addresses 812-1623 belong to tree 1, and so
+on. The interleaving is maintained all the way up to the 60 root nodes.
+Choosing 60 trees results in an evenly distributed number of trees per zone
+for a large number of possible logical zone counts. The storage for the 60
+tree roots is allocated at format time. All other block map pages are
+allocated out of the slabs as needed. This flexible allocation avoids the
+need to pre-allocate space for the entire set of logical mappings and also
+makes growing the logical size of a vdo relatively easy.
+
+In operation, the block map maintains two caches. It is prohibitive to keep
+the entire leaf level of the trees in memory, so each logical zone
+maintains its own cache of leaf pages. The size of this cache is
+configurable at target start time. The second cache is allocated at start
+time, and is large enough to hold all the non-leaf pages of the entire
+block map. This cache is populated as pages are needed.
+
+*The Recovery Journal*
+
+The recovery journal is used to amortize updates across the block map and
+slab depot. Each write request causes an entry to be made in the journal.
+Entries are either "data remappings" or "block map remappings." For a data
+remapping, the journal records the logical address affected and its old and
+new physical mappings. For a block map remapping, the journal records the
+block map page number and the physical block allocated for it. Block map
+pages are never reclaimed or repurposed, so the old mapping is always 0.
+
+Each journal entry is an intent record summarizing the metadata updates
+that are required for a data_vio. The recovery journal issues a flush
+before each journal block write to ensure that the physical data for the
+new block mappings in that block are stable on storage, and journal block
+writes are all issued with the FUA bit set to ensure the recovery journal
+entries themselves are stable. The journal entry and the data write it
+represents must be stable on disk before the other metadata structures may
+be updated to reflect the operation. These entries allow the vdo device to
+reconstruct the logical to physical mappings after an unexpected
+interruption such as a loss of power.
+
+*Write Path*
+
+All write I/O to vdo is asynchronous. Each bio will be acknowledged as soon
+as vdo has done enough work to guarantee that it can complete the write
+eventually. Generally, the data for acknowledged but unflushed write I/O
+can be treated as though it is cached in memory. If an application
+requires data to be stable on storage, it must issue a flush or write the
+data with the FUA bit set like any other asynchronous I/O. Shutting down
+the vdo target will also flush any remaining I/O.
+
+Application write bios follow the steps outlined below.
+
+1. A data_vio is obtained from the data_vio pool and associated with the
+ application bio. If there are no data_vios available, the incoming bio
+ will block until a data_vio is available. This provides back pressure
+ to the application. The data_vio pool is protected by a spin lock.
+
+ The newly acquired data_vio is reset and the bio's data is copied into
+ the data_vio if it is a write and the data is not all zeroes. The data
+ must be copied because the application bio can be acknowledged before
+ the data_vio processing is complete, which means later processing steps
+ will no longer have access to the application bio. The application bio
+ may also be smaller than 4K, in which case the data_vio will have
+ already read the underlying block and the data is instead copied over
+ the relevant portion of the larger block.
+
+2. The data_vio places a claim (the "logical lock") on the logical address
+ of the bio. It is vital to prevent simultaneous modifications of the
+ same logical address, because deduplication involves sharing blocks.
+ This claim is implemented as an entry in a hashtable where the key is
+ the logical address and the value is a pointer to the data_vio
+ currently handling that address.
+
+ If a data_vio looks in the hashtable and finds that another data_vio is
+ already operating on that logical address, it waits until the previous
+ operation finishes. It also sends a message to inform the current
+ lock holder that it is waiting. Most notably, a new data_vio waiting
+ for a logical lock will flush the previous lock holder out of the
+ compression packer (step 8d) rather than allowing it to continue
+ waiting to be packed.
+
+ This stage requires the data_vio to get an implicit lock on the
+ appropriate logical zone to prevent concurrent modifications of the
+ hashtable. This implicit locking is handled by the zone divisions
+ described above.
+
+3. The data_vio traverses the block map tree to ensure that all the
+ necessary internal tree nodes have been allocated, by trying to find
+ the leaf page for its logical address. If any interior tree page is
+ missing, it is allocated at this time out of the same physical storage
+ pool used to store application data.
+
+ a. If any page-node in the tree has not yet been allocated, it must be
+ allocated before the write can continue. This step requires the
+ data_vio to lock the page-node that needs to be allocated. This
+ lock, like the logical block lock in step 2, is a hashtable entry
+ that causes other data_vios to wait for the allocation process to
+ complete.
+
+ The implicit logical zone lock is released while the allocation is
+ happening, in order to allow other operations in the same logical
+ zone to proceed. The details of allocation are the same as in
+ step 4. Once a new node has been allocated, that node is added to
+ the tree using a similar process to adding a new data block mapping.
+ The data_vio journals the intent to add the new node to the block
+ map tree (step 10), updates the reference count of the new block
+ (step 11), and reacquires the implicit logical zone lock to add the
+ new mapping to the parent tree node (step 12). Once the tree is
+ updated, the data_vio proceeds down the tree. Any other data_vios
+ waiting on this allocation also proceed.
+
+ b. In the steady-state case, the block map tree nodes will already be
+ allocated, so the data_vio just traverses the tree until it finds
+ the required leaf node. The location of the mapping (the "block map
+ slot") is recorded in the data_vio so that later steps do not need
+ to traverse the tree again. The data_vio then releases the implicit
+ logical zone lock.
+
+4. If the block is a zero block, skip to step 9. Otherwise, an attempt is
+ made to allocate a free data block. This allocation ensures that the
+ data_vio can write its data somewhere even if deduplication and
+ compression are not possible. This stage gets an implicit lock on a
+ physical zone to search for free space within that zone.
+
+ The data_vio will search each slab in a zone until it finds a free
+ block or decides there are none. If the first zone has no free space,
+ it will proceed to search the next physical zone by taking the implicit
+ lock for that zone and releasing the previous one until it finds a
+ free block or runs out of zones to search. The data_vio will acquire a
+ struct pbn_lock (the "physical block lock") on the free block. The
+ struct pbn_lock also has several fields to record the various kinds of
+ claims that data_vios can have on physical blocks. The pbn_lock is
+ added to a hashtable like the logical block locks in step 2. This
+ hashtable is also covered by the implicit physical zone lock. The
+ reference count of the free block is updated to prevent any other
+ data_vio from considering it free. The reference counters are a
+ sub-component of the slab and are thus also covered by the implicit
+ physical zone lock.
+
+5. If an allocation was obtained, the data_vio has all the resources it
+ needs to complete the write. The application bio can safely be
+ acknowledged at this point. The acknowledgment happens on a separate
+ thread to prevent the application callback from blocking other data_vio
+ operations.
+
+ If an allocation could not be obtained, the data_vio continues to
+ attempt to deduplicate or compress the data, but the bio is not
+ acknowledged because the vdo device may be out of space.
+
+6. At this point vdo must determine where to store the application data.
+ The data_vio's data is hashed and the hash (the "record name") is
+ recorded in the data_vio.
+
+7. The data_vio reserves or joins a struct hash_lock, which manages all of
+ the data_vios currently writing the same data. Active hash locks are
+ tracked in a hashtable similar to the way logical block locks are
+ tracked in step 2. This hashtable is covered by the implicit lock on
+ the hash zone.
+
+ If there is no existing hash lock for this data_vio's record_name, the
+ data_vio obtains a hash lock from the pool, adds it to the hashtable,
+ and sets itself as the new hash lock's "agent." The hash_lock pool is
+ also covered by the implicit hash zone lock. The hash lock agent will
+ do all the work to decide where the application data will be
+ written. If a hash lock for the data_vio's record_name already exists,
+ and the data_vio's data is the same as the agent's data, the new
+ data_vio will wait for the agent to complete its work and then share
+ its result.
+
+ In the rare case that a hash lock exists for the data_vio's hash but
+ the data does not match the hash lock's agent, the data_vio skips to
+ step 8h and attempts to write its data directly. This can happen if two
+ different data blocks produce the same hash, for example.
+
+8. The hash lock agent attempts to deduplicate or compress its data with
+ the following steps.
+
+ a. The agent initializes and sends its embedded deduplication request
+ (struct uds_request) to the deduplication index. This does not
+ require the data_vio to get any locks because the index components
+ manage their own locking. The data_vio waits until it either gets a
+ response from the index or times out.
+
+ b. If the deduplication index returns advice, the data_vio attempts to
+ obtain a physical block lock on the indicated physical address, in
+ order to read the data and verify that it is the same as the
+ data_vio's data, and that it can accept more references. If the
+ physical address is already locked by another data_vio, the data at
+ that address may soon be overwritten so it is not safe to use the
+ address for deduplication.
+
+ c. If the data matches and the physical block can add references, the
+ agent and any other data_vios waiting on it will record this
+ physical block as their new physical address and proceed to step 9
+ to record their new mapping. If there are more data_vios in the hash
+ lock than there are references available, one of the remaining
+ data_vios becomes the new agent and continues to step 8d as if no
+ valid advice was returned.
+
+ d. If no usable duplicate block was found, the agent first checks that
+ it has an allocated physical block (from step 3) that it can write
+ to. If the agent does not have an allocation, some other data_vio in
+ the hash lock that does have an allocation takes over as agent. If
+ none of the data_vios have an allocated physical block, these writes
+ are out of space, so they proceed to step 13 for cleanup.
+
+ e. The agent attempts to compress its data. If the data does not
+ compress, the data_vio will continue to step 8h to write its data
+ directly.
+
+ If the compressed size is small enough, the agent will release the
+ implicit hash zone lock and go to the packer (struct packer) where
+ it will be placed in a bin (struct packer_bin) along with other
+ data_vios. All compression operations require the implicit lock on
+ the packer zone.
+
+ The packer can combine up to 14 compressed blocks in a single 4k
+ data block. Compression is only helpful if vdo can pack at least 2
+ data_vios into a single data block. This means that a data_vio may
+ wait in the packer for an arbitrarily long time for other data_vios
+ to fill out the compressed block. There is a mechanism for vdo to
+ evict waiting data_vios when continuing to wait would cause
+ problems. Circumstances causing an eviction include an application
+ flush, device shutdown, or a subsequent data_vio trying to overwrite
+ the same logical block address. A data_vio may also be evicted from
+ the packer if it cannot be paired with any other compressed block
+ before more compressible blocks need to use its bin. An evicted
+ data_vio will proceed to step 8h to write its data directly.
+
+ f. If the agent fills a packer bin, either because all 14 of its slots
+ are used or because it has no remaining space, it is written out
+ using the allocated physical block from one of its data_vios. Step
+ 8d has already ensured that an allocation is available.
+
+ g. Each data_vio sets the compressed block as its new physical address.
+ The data_vio obtains an implicit lock on the physical zone and
+ acquires the struct pbn_lock for the compressed block, which is
+ modified to be a shared lock. Then it releases the implicit physical
+ zone lock and proceeds to step 8i.
+
+ h. Any data_vio evicted from the packer will have an allocation from
+ step 3. It will write its data to that allocated physical block.
+
+ i. After the data is written, if the data_vio is the agent of a hash
+ lock, it will reacquire the implicit hash zone lock and share its
+ physical address with as many other data_vios in the hash lock as
+ possible. Each data_vio will then proceed to step 9 to record its
+ new mapping.
+
+ j. If the agent actually wrote new data (whether compressed or not),
+ the deduplication index is updated to reflect the location of the
+ new data. The agent then releases the implicit hash zone lock.
+
+9. The data_vio determines the previous mapping of the logical address.
+ There is a cache for block map leaf pages (the "block map cache"),
+ because there are usually too many block map leaf nodes to store
+ entirely in memory. If the desired leaf page is not in the cache, the
+ data_vio will reserve a slot in the cache and load the desired page
+ into it, possibly evicting an older cached page. The data_vio then
+ finds the current physical address for this logical address (the "old
+ physical mapping"), if any, and records it. This step requires a lock
+ on the block map cache structures, covered by the implicit logical zone
+ lock.
+
+10. The data_vio makes an entry in the recovery journal containing the
+ logical block address, the old physical mapping, and the new physical
+ mapping. Making this journal entry requires holding the implicit
+ recovery journal lock. The data_vio will wait in the journal until all
+ recovery blocks up to the one containing its entry have been written
+ and flushed to ensure the transaction is stable on storage.
+
+11. Once the recovery journal entry is stable, the data_vio makes two slab
+ journal entries: an increment entry for the new mapping, and a
+ decrement entry for the old mapping. These two operations each require
+ holding a lock on the affected physical slab, covered by its implicit
+ physical zone lock. For correctness during recovery, the slab journal
+ entries in any given slab journal must be in the same order as the
+ corresponding recovery journal entries. Therefore, if the two entries
+ are in different zones, they are made concurrently, and if they are in
+ the same zone, the increment is always made before the decrement in
+ order to avoid underflow. After each slab journal entry is made in
+ memory, the associated reference count is also updated in memory.
+
+12. Once both of the reference count updates are done, the data_vio
+ acquires the implicit logical zone lock and updates the
+ logical-to-physical mapping in the block map to point to the new
+ physical block. At this point the write operation is complete.
+
+13. If the data_vio has a hash lock, it acquires the implicit hash zone
+ lock and releases its hash lock to the pool.
+
+ The data_vio then acquires the implicit physical zone lock and releases
+ the struct pbn_lock it holds for its allocated block. If it had an
+ allocation that it did not use, it also sets the reference count for
+ that block back to zero to free it for use by subsequent data_vios.
+
+ The data_vio then acquires the implicit logical zone lock and releases
+ the logical block lock acquired in step 2.
+
+ The application bio is then acknowledged if it has not previously been
+ acknowledged, and the data_vio is returned to the pool.
+
+*Read Path*
+
+An application read bio follows a much simpler set of steps. It does steps
+1 and 2 in the write path to obtain a data_vio and lock its logical
+address. If there is already a write data_vio in progress for that logical
+address that is guaranteed to complete, the read data_vio will copy the
+data from the write data_vio and return it. Otherwise, it will look up the
+logical-to-physical mapping by traversing the block map tree as in step 3,
+and then read and possibly decompress the indicated data at the indicated
+physical block address. A read data_vio will not allocate block map tree
+nodes if they are missing. If the interior block map nodes do not exist
+yet, the logical block map address must still be unmapped and the read
+data_vio will return all zeroes. A read data_vio handles cleanup and
+acknowledgment as in step 13, although it only needs to release the logical
+lock and return itself to the pool.
+
+*Small Writes*
+
+All storage within vdo is managed as 4KB blocks, but it can accept writes
+as small as 512 bytes. Processing a write that is smaller than 4K requires
+a read-modify-write operation that reads the relevant 4K block, copies the
+new data over the appropriate sectors of the block, and then launches a
+write operation for the modified data block. The read and write stages of
+this operation are nearly identical to the normal read and write
+operations, and a single data_vio is used throughout this operation.
+
+*Recovery*
+
+When a vdo is restarted after a crash, it will attempt to recover from the
+recovery journal. During the pre-resume phase of the next start, the
+recovery journal is read. The increment portion of valid entries are played
+into the block map. Next, valid entries are played, in order as required,
+into the slab journals. Finally, each physical zone attempts to replay at
+least one slab journal to reconstruct the reference counts of one slab.
+Once each zone has some free space (or has determined that it has none),
+the vdo comes back online, while the remainder of the slab journals are
+used to reconstruct the rest of the reference counts in the background.
+
+*Read-only Rebuild*
+
+If a vdo encounters an unrecoverable error, it will enter read-only mode.
+This mode indicates that some previously acknowledged data may have been
+lost. The vdo may be instructed to rebuild as best it can in order to
+return to a writable state. However, this is never done automatically due
+to the possibility that data has been lost. During a read-only rebuild, the
+block map is recovered from the recovery journal as before. However, the
+reference counts are not rebuilt from the slab journals. Instead, the
+reference counts are zeroed, the entire block map is traversed, and the
+reference counts are updated from the block mappings. While this may lose
+some data, it ensures that the block map and reference counts are
+consistent with each other. This allows vdo to resume normal operation and
+accept further writes.
diff --git a/Documentation/admin-guide/device-mapper/vdo.rst b/Documentation/admin-guide/device-mapper/vdo.rst
new file mode 100644
index 000000000000..8a67b320a97b
--- /dev/null
+++ b/Documentation/admin-guide/device-mapper/vdo.rst
@@ -0,0 +1,413 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+======
+dm-vdo
+======
+
+The dm-vdo (virtual data optimizer) device mapper target provides
+block-level deduplication, compression, and thin provisioning. As a device
+mapper target, it can add these features to the storage stack, compatible
+with any file system. The vdo target does not protect against data
+corruption, relying instead on integrity protection of the storage below
+it. It is strongly recommended that lvm be used to manage vdo volumes. See
+lvmvdo(7).
+
+Userspace component
+===================
+
+Formatting a vdo volume requires the use of the 'vdoformat' tool, available
+at:
+
+https://github.com/dm-vdo/vdo/
+
+In most cases, a vdo target will recover from a crash automatically the
+next time it is started. In cases where it encountered an unrecoverable
+error (either during normal operation or crash recovery) the target will
+enter or come up in read-only mode. Because read-only mode is indicative of
+data-loss, a positive action must be taken to bring vdo out of read-only
+mode. The 'vdoforcerebuild' tool, available from the same repo, is used to
+prepare a read-only vdo to exit read-only mode. After running this tool,
+the vdo target will rebuild its metadata the next time it is
+started. Although some data may be lost, the rebuilt vdo's metadata will be
+internally consistent and the target will be writable again.
+
+The repo also contains additional userspace tools which can be used to
+inspect a vdo target's on-disk metadata. Fortunately, these tools are
+rarely needed except by dm-vdo developers.
+
+Metadata requirements
+=====================
+
+Each vdo volume reserves 3GB of space for metadata, or more depending on
+its configuration. It is helpful to check that the space saved by
+deduplication and compression is not cancelled out by the metadata
+requirements. An estimation of the space saved for a specific dataset can
+be computed with the vdo estimator tool, which is available at:
+
+https://github.com/dm-vdo/vdoestimator/
+
+Target interface
+================
+
+Table line
+----------
+
+::
+
+ <offset> <logical device size> vdo V4 <storage device>
+ <storage device size> <minimum I/O size> <block map cache size>
+ <block map era length> [optional arguments]
+
+
+Required parameters:
+
+ offset:
+ The offset, in sectors, at which the vdo volume's logical
+ space begins.
+
+ logical device size:
+ The size of the device which the vdo volume will service,
+ in sectors. Must match the current logical size of the vdo
+ volume.
+
+ storage device:
+ The device holding the vdo volume's data and metadata.
+
+ storage device size:
+ The size of the device holding the vdo volume, as a number
+ of 4096-byte blocks. Must match the current size of the vdo
+ volume.
+
+ minimum I/O size:
+ The minimum I/O size for this vdo volume to accept, in
+ bytes. Valid values are 512 or 4096. The recommended value
+ is 4096.
+
+ block map cache size:
+ The size of the block map cache, as a number of 4096-byte
+ blocks. The minimum and recommended value is 32768 blocks.
+ If the logical thread count is non-zero, the cache size
+ must be at least 4096 blocks per logical thread.
+
+ block map era length:
+ The speed with which the block map cache writes out
+ modified block map pages. A smaller era length is likely to
+ reduce the amount of time spent rebuilding, at the cost of
+ increased block map writes during normal operation. The
+ maximum and recommended value is 16380; the minimum value
+ is 1.
+
+Optional parameters:
+--------------------
+Some or all of these parameters may be specified as <key> <value> pairs.
+
+Thread related parameters:
+
+Different categories of work are assigned to separate thread groups, and
+the number of threads in each group can be configured separately.
+
+If <hash>, <logical>, and <physical> are all set to 0, the work handled by
+all three thread types will be handled by a single thread. If any of these
+values are non-zero, all of them must be non-zero.
+
+ ack:
+ The number of threads used to complete bios. Since
+ completing a bio calls an arbitrary completion function
+ outside the vdo volume, threads of this type allow the vdo
+ volume to continue processing requests even when bio
+ completion is slow. The default is 1.
+
+ bio:
+ The number of threads used to issue bios to the underlying
+ storage. Threads of this type allow the vdo volume to
+ continue processing requests even when bio submission is
+ slow. The default is 4.
+
+ bioRotationInterval:
+ The number of bios to enqueue on each bio thread before
+ switching to the next thread. The value must be greater
+ than 0 and not more than 1024; the default is 64.
+
+ cpu:
+ The number of threads used to do CPU-intensive work, such
+ as hashing and compression. The default is 1.
+
+ hash:
+ The number of threads used to manage data comparisons for
+ deduplication based on the hash value of data blocks. The
+ default is 0.
+
+ logical:
+ The number of threads used to manage caching and locking
+ based on the logical address of incoming bios. The default
+ is 0; the maximum is 60.
+
+ physical:
+ The number of threads used to manage administration of the
+ underlying storage device. At format time, a slab size for
+ the vdo is chosen; the vdo storage device must be large
+ enough to have at least 1 slab per physical thread. The
+ default is 0; the maximum is 16.
+
+Miscellaneous parameters:
+
+ maxDiscard:
+ The maximum size of discard bio accepted, in 4096-byte
+ blocks. I/O requests to a vdo volume are normally split
+ into 4096-byte blocks, and processed up to 2048 at a time.
+ However, discard requests to a vdo volume can be
+ automatically split to a larger size, up to <maxDiscard>
+ 4096-byte blocks in a single bio, and are limited to 1500
+ at a time. Increasing this value may provide better overall
+ performance, at the cost of increased latency for the
+ individual discard requests. The default and minimum is 1;
+ the maximum is UINT_MAX / 4096.
+
+ deduplication:
+ Whether deduplication is enabled. The default is 'on'; the
+ acceptable values are 'on' and 'off'.
+
+ compression:
+ Whether compression is enabled. The default is 'off'; the
+ acceptable values are 'on' and 'off'.
+
+Device modification
+-------------------
+
+A modified table may be loaded into a running, non-suspended vdo volume.
+The modifications will take effect when the device is next resumed. The
+modifiable parameters are <logical device size>, <physical device size>,
+<maxDiscard>, <compression>, and <deduplication>.
+
+If the logical device size or physical device size are changed, upon
+successful resume vdo will store the new values and require them on future
+startups. These two parameters may not be decreased. The logical device
+size may not exceed 4 PB. The physical device size must increase by at
+least 32832 4096-byte blocks if at all, and must not exceed the size of the
+underlying storage device. Additionally, when formatting the vdo device, a
+slab size is chosen: the physical device size may never increase above the
+size which provides 8192 slabs, and each increase must be large enough to
+add at least one new slab.
+
+Examples:
+
+Start a previously-formatted vdo volume with 1 GB logical space and 1 GB
+physical space, storing to /dev/dm-1 which has more than 1 GB of space.
+
+::
+
+ dmsetup create vdo0 --table \
+ "0 2097152 vdo V4 /dev/dm-1 262144 4096 32768 16380"
+
+Grow the logical size to 4 GB.
+
+::
+
+ dmsetup reload vdo0 --table \
+ "0 8388608 vdo V4 /dev/dm-1 262144 4096 32768 16380"
+ dmsetup resume vdo0
+
+Grow the physical size to 2 GB.
+
+::
+
+ dmsetup reload vdo0 --table \
+ "0 8388608 vdo V4 /dev/dm-1 524288 4096 32768 16380"
+ dmsetup resume vdo0
+
+Grow the physical size by 1 GB more and increase max discard sectors.
+
+::
+
+ dmsetup reload vdo0 --table \
+ "0 10485760 vdo V4 /dev/dm-1 786432 4096 32768 16380 maxDiscard 8"
+ dmsetup resume vdo0
+
+Stop the vdo volume.
+
+::
+
+ dmsetup remove vdo0
+
+Start the vdo volume again. Note that the logical and physical device sizes
+must still match, but other parameters can change.
+
+::
+
+ dmsetup create vdo1 --table \
+ "0 10485760 vdo V4 /dev/dm-1 786432 512 65550 5000 hash 1 logical 3 physical 2"
+
+Messages
+--------
+All vdo devices accept messages in the form:
+
+::
+
+ dmsetup message <target-name> 0 <message-name> <message-parameters>
+
+The messages are:
+
+ stats:
+ Outputs the current view of the vdo statistics. Mostly used
+ by the vdostats userspace program to interpret the output
+ buffer.
+
+ config:
+ Outputs useful vdo configuration information. Mostly used
+ by users who want to recreate a similar VDO volume and
+ want to know the creation configuration used.
+
+ dump:
+ Dumps many internal structures to the system log. This is
+ not always safe to run, so it should only be used to debug
+ a hung vdo. Optional parameters to specify structures to
+ dump are:
+
+ viopool: The pool of I/O requests incoming bios
+ pools: A synonym of 'viopool'
+ vdo: Most of the structures managing on-disk data
+ queues: Basic information about each vdo thread
+ threads: A synonym of 'queues'
+ default: Equivalent to 'queues vdo'
+ all: All of the above.
+
+ dump-on-shutdown:
+ Perform a default dump next time vdo shuts down.
+
+
+Status
+------
+
+::
+
+ <device> <operating mode> <in recovery> <index state>
+ <compression state> <physical blocks used> <total physical blocks>
+
+ device:
+ The name of the vdo volume.
+
+ operating mode:
+ The current operating mode of the vdo volume; values may be
+ 'normal', 'recovering' (the volume has detected an issue
+ with its metadata and is attempting to repair itself), and
+ 'read-only' (an error has occurred that forces the vdo
+ volume to only support read operations and not writes).
+
+ in recovery:
+ Whether the vdo volume is currently in recovery mode;
+ values may be 'recovering' or '-' which indicates not
+ recovering.
+
+ index state:
+ The current state of the deduplication index in the vdo
+ volume; values may be 'closed', 'closing', 'error',
+ 'offline', 'online', 'opening', and 'unknown'.
+
+ compression state:
+ The current state of compression in the vdo volume; values
+ may be 'offline' and 'online'.
+
+ used physical blocks:
+ The number of physical blocks in use by the vdo volume.
+
+ total physical blocks:
+ The total number of physical blocks the vdo volume may use;
+ the difference between this value and the
+ <used physical blocks> is the number of blocks the vdo
+ volume has left before being full.
+
+Memory Requirements
+===================
+
+A vdo target requires a fixed 38 MB of RAM along with the following amounts
+that scale with the target:
+
+- 1.15 MB of RAM for each 1 MB of configured block map cache size. The
+ block map cache requires a minimum of 150 MB.
+- 1.6 MB of RAM for each 1 TB of logical space.
+- 268 MB of RAM for each 1 TB of physical storage managed by the volume.
+
+The deduplication index requires additional memory which scales with the
+size of the deduplication window. For dense indexes, the index requires 1
+GB of RAM per 1 TB of window. For sparse indexes, the index requires 1 GB
+of RAM per 10 TB of window. The index configuration is set when the target
+is formatted and may not be modified.
+
+Module Parameters
+=================
+
+The vdo driver has a numeric parameter 'log_level' which controls the
+verbosity of logging from the driver. The default setting is 6
+(LOGLEVEL_INFO and more severe messages).
+
+Run-time Usage
+==============
+
+When using dm-vdo, it is important to be aware of the ways in which its
+behavior differs from other storage targets.
+
+- There is no guarantee that over-writes of existing blocks will succeed.
+ Because the underlying storage may be multiply referenced, over-writing
+ an existing block generally requires a vdo to have a free block
+ available.
+
+- When blocks are no longer in use, sending a discard request for those
+ blocks lets the vdo release references for those blocks. If the vdo is
+ thinly provisioned, discarding unused blocks is essential to prevent the
+ target from running out of space. However, due to the sharing of
+ duplicate blocks, no discard request for any given logical block is
+ guaranteed to reclaim space.
+
+- Assuming the underlying storage properly implements flush requests, vdo
+ is resilient against crashes, however, unflushed writes may or may not
+ persist after a crash.
+
+- Each write to a vdo target entails a significant amount of processing.
+ However, much of the work is paralellizable. Therefore, vdo targets
+ achieve better throughput at higher I/O depths, and can support up 2048
+ requests in parallel.
+
+Tuning
+======
+
+The vdo device has many options, and it can be difficult to make optimal
+choices without perfect knowledge of the workload. Additionally, most
+configuration options must be set when a vdo target is started, and cannot
+be changed without shutting it down completely; the configuration cannot be
+changed while the target is active. Ideally, tuning with simulated
+workloads should be performed before deploying vdo in production
+environments.
+
+The most important value to adjust is the block map cache size. In order to
+service a request for any logical address, a vdo must load the portion of
+the block map which holds the relevant mapping. These mappings are cached.
+Performance will suffer when the working set does not fit in the cache. By
+default, a vdo allocates 128 MB of metadata cache in RAM to support
+efficient access to 100 GB of logical space at a time. It should be scaled
+up proportionally for larger working sets.
+
+The logical and physical thread counts should also be adjusted. A logical
+thread controls a disjoint section of the block map, so additional logical
+threads increase parallelism and can increase throughput. Physical threads
+control a disjoint section of the data blocks, so additional physical
+threads can also increase throughput. However, excess threads can waste
+resources and increase contention.
+
+Bio submission threads control the parallelism involved in sending I/O to
+the underlying storage; fewer threads mean there is more opportunity to
+reorder I/O requests for performance benefit, but also that each I/O
+request has to wait longer before being submitted.
+
+Bio acknowledgment threads are used for finishing I/O requests. This is
+done on dedicated threads since the amount of work required to execute a
+bio's callback can not be controlled by the vdo itself. Usually one thread
+is sufficient but additional threads may be beneficial, particularly when
+bios have CPU-heavy callbacks.
+
+CPU threads are used for hashing and for compression; in workloads with
+compression enabled, more threads may result in higher throughput.
+
+Hash threads are used to sort active requests by hash and determine whether
+they should deduplicate; the most CPU intensive actions done by these
+threads are comparison of 4096-byte data blocks. In most cases, a single
+hash thread is sufficient.
diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst
index 1a6b91368e59..8c3f1f967a3c 100644
--- a/Documentation/admin-guide/device-mapper/verity.rst
+++ b/Documentation/admin-guide/device-mapper/verity.rst
@@ -87,6 +87,15 @@ panic_on_corruption
Panic the device when a corrupted block is discovered. This option is
not compatible with ignore_corruption and restart_on_corruption.
+restart_on_error
+ Restart the system when an I/O error is detected.
+ This option can be combined with the restart_on_corruption option.
+
+panic_on_error
+ Panic the device when an I/O error is detected. This option is
+ not compatible with the restart_on_error option but can be combined
+ with the panic_on_corruption option.
+
ignore_zero_blocks
Do not verify blocks that are expected to contain zeroes and always return
zeroes instead. This may be useful if the partition contains unused blocks
@@ -141,6 +150,17 @@ root_hash_sig_key_desc <key_description>
also gain new certificates at run time if they are signed by a certificate
already in the secondary trusted keyring.
+try_verify_in_tasklet
+ If verity hashes are in cache and the IO size does not exceed the limit,
+ verify data blocks in bottom half instead of workqueue. This option can
+ reduce IO latency. The size limits can be configured via
+ /sys/module/dm_verity/parameters/use_bh_bytes. The four parameters
+ correspond to limits for IOPRIO_CLASS_NONE, IOPRIO_CLASS_RT,
+ IOPRIO_CLASS_BE and IOPRIO_CLASS_IDLE in turn.
+ For example:
+ <none>,<rt>,<be>,<idle>
+ 4096,4096,4096,4096
+
Theory of operation
===================
diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt
index 9764d6edb189..94c98be1329a 100644
--- a/Documentation/admin-guide/devices.txt
+++ b/Documentation/admin-guide/devices.txt
@@ -2691,18 +2691,9 @@
45 = /dev/ttyMM1 Marvell MPSC - port 1 (obsolete unused)
46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
- 50 = /dev/ttyIOC0 Altix serial card
- ...
- 81 = /dev/ttyIOC31 Altix serial card
+ 51 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
82 = /dev/ttyVR0 NEC VR4100 series SIU
83 = /dev/ttyVR1 NEC VR4100 series DSIU
- 84 = /dev/ttyIOC84 Altix ioc4 serial card
- ...
- 115 = /dev/ttyIOC115 Altix ioc4 serial card
- 116 = /dev/ttySIOC0 Altix ioc3 serial card
- ...
- 147 = /dev/ttySIOC31 Altix ioc3 serial card
148 = /dev/ttyPSC0 PPC PSC - port 0
...
153 = /dev/ttyPSC5 PPC PSC - port 5
@@ -2713,6 +2704,9 @@
...
185 = /dev/ttyNX15 Hilscher netX serial port 15
186 = /dev/ttyJ0 JTAG1 DCC protocol based serial port emulation
+
+ If maximum number of uartlite serial ports is more than 4, then the driver
+ uses dynamic allocation instead of static allocation for major number.
187 = /dev/ttyUL0 Xilinx uartlite - port 0
...
190 = /dev/ttyUL3 Xilinx uartlite - port 3
@@ -2761,10 +2755,7 @@
43 = /dev/ttycusmx2 Callout device for ttySMX2
46 = /dev/cucpm0 Callout device for ttyCPM0
...
- 49 = /dev/cucpm5 Callout device for ttyCPM5
- 50 = /dev/cuioc40 Callout device for ttyIOC40
- ...
- 81 = /dev/cuioc431 Callout device for ttyIOC431
+ 51 = /dev/cucpm5 Callout device for ttyCPM5
82 = /dev/cuvr0 Callout device for ttyVR0
83 = /dev/cuvr1 Callout device for ttyVR1
@@ -3080,6 +3071,11 @@
...
255 = /dev/osd255 256th OSD Device
+ 261 char Compute Acceleration Devices
+ 0 = /dev/accel/accel0 First acceleration device
+ 1 = /dev/accel/accel1 Second acceleration device
+ ...
+
384-511 char RESERVED FOR DYNAMIC ASSIGNMENT
Character devices that request a dynamic allocation of major
number will take numbers starting from 511 and downward,
diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst
index a89cfa083155..095a63892257 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -5,143 +5,120 @@ Dynamic debug
Introduction
============
-This document describes how to use the dynamic debug (dyndbg) feature.
+Dynamic debug allows you to dynamically enable/disable kernel
+debug-print code to obtain additional kernel information.
-Dynamic debug is designed to allow you to dynamically enable/disable
-kernel code to obtain additional kernel information. Currently, if
-``CONFIG_DYNAMIC_DEBUG`` is set, then all ``pr_debug()``/``dev_dbg()`` and
-``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically
-enabled per-callsite.
+If ``/proc/dynamic_debug/control`` exists, your kernel has dynamic
+debug. You'll need root access (sudo su) to use this.
-If you do not want to enable dynamic debug globally (i.e. in some embedded
-system), you may set ``CONFIG_DYNAMIC_DEBUG_CORE`` as basic support of dynamic
-debug and add ``ccflags := -DDYNAMIC_DEBUG_MODULE`` into the Makefile of any
-modules which you'd like to dynamically debug later.
-
-If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``print_hex_dump_debug()`` is just
-shortcut for ``print_hex_dump(KERN_DEBUG)``.
-
-For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is
-its ``prefix_str`` argument, if it is constant string; or ``hexdump``
-in case ``prefix_str`` is built dynamically.
+Dynamic debug provides:
-Dynamic debug has even more useful features:
+ * a Catalog of all *prdbgs* in your kernel.
+ ``cat /proc/dynamic_debug/control`` to see them.
- * Simple query language allows turning on and off debugging
- statements by matching any combination of 0 or 1 of:
+ * a Simple query/command language to alter *prdbgs* by selecting on
+ any combination of 0 or 1 of:
- source filename
- function name
- line number (including ranges of line numbers)
- module name
- format string
+ - class name (as known/declared by each module)
- * Provides a debugfs control file: ``<debugfs>/dynamic_debug/control``
- which can be read to display the complete list of known debug
- statements, to help guide you
-
-Controlling dynamic debug Behaviour
-===================================
-
-The behaviour of ``pr_debug()``/``dev_dbg()`` are controlled via writing to a
-control file in the 'debugfs' filesystem. Thus, you must first mount
-the debugfs filesystem, in order to make use of this feature.
-Subsequently, we refer to the control file as:
-``<debugfs>/dynamic_debug/control``. For example, if you want to enable
-printing from source file ``svcsock.c``, line 1603 you simply do::
-
- nullarbor:~ # echo 'file svcsock.c line 1603 +p' >
- <debugfs>/dynamic_debug/control
-
-If you make a mistake with the syntax, the write will fail thus::
-
- nullarbor:~ # echo 'file svcsock.c wtf 1 +p' >
- <debugfs>/dynamic_debug/control
- -bash: echo: write error: Invalid argument
-
-Note, for systems without 'debugfs' enabled, the control file can be
-found in ``/proc/dynamic_debug/control``.
+NOTE: To actually get the debug-print output on the console, you may
+need to adjust the kernel ``loglevel=``, or use ``ignore_loglevel``.
+Read about these kernel parameters in
+Documentation/admin-guide/kernel-parameters.rst.
Viewing Dynamic Debug Behaviour
===============================
-You can view the currently configured behaviour of all the debug
-statements via::
+You can view the currently configured behaviour in the *prdbg* catalog::
- nullarbor:~ # cat <debugfs>/dynamic_debug/control
+ :#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
- net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
- net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012"
- net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012"
- net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012"
- ...
+ init/main.c:1179 [main]initcall_blacklist =_ "blacklisting initcall %s\012
+ init/main.c:1218 [main]initcall_blacklisted =_ "initcall %s blacklisted\012"
+ init/main.c:1424 [main]run_init_process =_ " with arguments:\012"
+ init/main.c:1426 [main]run_init_process =_ " %s\012"
+ init/main.c:1427 [main]run_init_process =_ " with environment:\012"
+ init/main.c:1429 [main]run_init_process =_ " %s\012"
+The 3rd space-delimited column shows the current flags, preceded by
+a ``=`` for easy use with grep/cut. ``=p`` shows enabled callsites.
-You can also apply standard Unix text manipulation filters to this
-data, e.g.::
+Controlling dynamic debug Behaviour
+===================================
- nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control | wc -l
- 62
+The behaviour of *prdbg* sites are controlled by writing
+query/commands to the control file. Example::
- nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l
- 42
+ # grease the interface
+ :#> alias ddcmd='echo $* > /proc/dynamic_debug/control'
-The third column shows the currently enabled flags for each debug
-statement callsite (see below for definitions of the flags). The
-default value, with no flags enabled, is ``=_``. So you can view all
-the debug statement callsites with any non-default flags::
+ :#> ddcmd '-p; module main func run* +p'
+ :#> grep =p /proc/dynamic_debug/control
+ init/main.c:1424 [main]run_init_process =p " with arguments:\012"
+ init/main.c:1426 [main]run_init_process =p " %s\012"
+ init/main.c:1427 [main]run_init_process =p " with environment:\012"
+ init/main.c:1429 [main]run_init_process =p " %s\012"
- nullarbor:~ # awk '$3 != "=_"' <debugfs>/dynamic_debug/control
- # filename:lineno [module]function flags format
- net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012"
+Error messages go to console/syslog::
+
+ :#> ddcmd mode foo +p
+ dyndbg: unknown keyword "mode"
+ dyndbg: query parse failed
+ bash: echo: write error: Invalid argument
+
+If debugfs is also enabled and mounted, ``dynamic_debug/control`` is
+also under the mount-dir, typically ``/sys/kernel/debug/``.
Command Language Reference
==========================
-At the lexical level, a command comprises a sequence of words separated
+At the basic lexical level, a command is a sequence of words separated
by spaces or tabs. So these are all equivalent::
- nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
- <debugfs>/dynamic_debug/control
- nullarbor:~ # echo -n ' file svcsock.c line 1603 +p ' >
- <debugfs>/dynamic_debug/control
- nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd file svcsock.c line 1603 +p
+ :#> ddcmd "file svcsock.c line 1603 +p"
+ :#> ddcmd ' file svcsock.c line 1603 +p '
Command submissions are bounded by a write() system call.
Multiple commands can be written together, separated by ``;`` or ``\n``::
- ~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \
- > <debugfs>/dynamic_debug/control
-
-If your query set is big, you can batch them too::
+ :#> ddcmd "func pnpacpi_get_resources +p; func pnp_assign_mem +p"
+ :#> ddcmd <<"EOC"
+ func pnpacpi_get_resources +p
+ func pnp_assign_mem +p
+ EOC
+ :#> cat query-batch-file > /proc/dynamic_debug/control
- ~# cat query-batch-file > <debugfs>/dynamic_debug/control
+You can also use wildcards in each query term. The match rule supports
+``*`` (matches zero or more characters) and ``?`` (matches exactly one
+character). For example, you can match all usb drivers::
-Another way is to use wildcards. The match rule supports ``*`` (matches
-zero or more characters) and ``?`` (matches exactly one character). For
-example, you can match all usb drivers::
+ :#> ddcmd file "drivers/usb/*" +p # "" to suppress shell expansion
- ~# echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control
-
-At the syntactical level, a command comprises a sequence of match
-specifications, followed by a flags change specification::
+Syntactically, a command is pairs of keyword values, followed by a
+flags change or setting::
command ::= match-spec* flags-spec
-The match-spec's are used to choose a subset of the known pr_debug()
-callsites to which to apply the flags-spec. Think of them as a query
-with implicit ANDs between each pair. Note that an empty list of
-match-specs will select all debug statement callsites.
+The match-spec's select *prdbgs* from the catalog, upon which to apply
+the flags-spec, all constraints are ANDed together. An absent keyword
+is the same as keyword "*".
+
-A match specification comprises a keyword, which controls the
-attribute of the callsite to be compared, and a value to compare
-against. Possible keywords are:::
+A match specification is a keyword, which selects the attribute of
+the callsite to be compared, and a value to compare against. Possible
+keywords are:::
match-spec ::= 'func' string |
'file' string |
'module' string |
'format' string |
+ 'class' string |
'line' line-range
line-range ::= lineno |
@@ -203,6 +180,16 @@ format
format "nfsd: SETATTR" // a neater way to match a format with whitespace
format 'nfsd: SETATTR' // yet another way to match a format with whitespace
+class
+ The given class_name is validated against each module, which may
+ have declared a list of known class_names. If the class_name is
+ found for a module, callsite & class matching and adjustment
+ proceeds. Examples::
+
+ class DRM_UT_KMS # a DRM.debug category
+ class JUNK # silent non-match
+ // class TLD_* # NOTICE: no wildcard in class names
+
line
The given line number or range of line numbers is compared
against the line number of each ``pr_debug()`` callsite. A single
@@ -228,20 +215,21 @@ of the characters::
The flags are::
p enables the pr_debug() callsite.
- f Include the function name in the printed message
- l Include line number in the printed message
- m Include module name in the printed message
- t Include thread ID in messages not generated from interrupt context
- _ No flags are set. (Or'd with others on input)
+ _ enables no flags.
-For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only ``p`` flag
-have meaning, other flags ignored.
+ Decorator flags add to the message-prefix, in order:
+ t Include thread ID, or <intr>
+ m Include module name
+ f Include the function name
+ s Include the source file name
+ l Include line number
+ d Include call trace
-For display, the flags are preceded by ``=``
-(mnemonic: what the flags are currently equal to).
+For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only
+the ``p`` flag has meaning, other flags are ignored.
-Note the regexp ``^[-+=][flmpt_]+$`` matches a flags specification.
-To clear all flags at once, use ``=_`` or ``-flmpt``.
+Note the regexp ``^[-+=][fslmptd_]+$`` matches a flags specification.
+To clear all flags at once, use ``=_`` or ``-fslmptd``.
Debug messages during Boot Process
@@ -277,7 +265,7 @@ Debug Messages at Module Initialization Time
When ``modprobe foo`` is called, modprobe scans ``/proc/cmdline`` for
``foo.params``, strips ``foo.``, and passes them to the kernel along with
-params given in modprobe args or ``/etc/modprob.d/*.conf`` files,
+params given in modprobe args or ``/etc/modprobe.d/*.conf`` files,
in the following order:
1. parameters given via ``/etc/modprobe.d/*.conf``::
@@ -313,7 +301,7 @@ For ``CONFIG_DYNAMIC_DEBUG`` kernels, any settings given at boot-time (or
enabled by ``-DDEBUG`` flag during compilation) can be disabled later via
the debugfs interface if the debug messages are no longer needed::
- echo "module module_name -p" > <debugfs>/dynamic_debug/control
+ echo "module module_name -p" > /proc/dynamic_debug/control
Examples
========
@@ -321,41 +309,35 @@ Examples
::
// enable the message at line 1603 of file svcsock.c
- nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd 'file svcsock.c line 1603 +p'
// enable all the messages in file svcsock.c
- nullarbor:~ # echo -n 'file svcsock.c +p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd 'file svcsock.c +p'
// enable all the messages in the NFS server module
- nullarbor:~ # echo -n 'module nfsd +p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd 'module nfsd +p'
// enable all 12 messages in the function svc_process()
- nullarbor:~ # echo -n 'func svc_process +p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd 'func svc_process +p'
// disable all 12 messages in the function svc_process()
- nullarbor:~ # echo -n 'func svc_process -p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd 'func svc_process -p'
// enable messages for NFS calls READ, READLINK, READDIR and READDIR+.
- nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
- <debugfs>/dynamic_debug/control
+ :#> ddcmd 'format "nfsd: READ" +p'
// enable messages in files of which the paths include string "usb"
- nullarbor:~ # echo -n 'file *usb* +p' > <debugfs>/dynamic_debug/control
+ :#> ddcmd 'file *usb* +p'
// enable all messages
- nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control
+ :#> ddcmd '+p'
// add module, function to all enabled messages
- nullarbor:~ # echo -n '+mf' > <debugfs>/dynamic_debug/control
+ :#> ddcmd '+mf'
// boot-args example, with newlines and comments for readability
Kernel command line: ...
- // see whats going on in dyndbg=value processing
+ // see what's going on in dyndbg=value processing
dynamic_debug.verbose=3
// enable pr_debugs in the btrfs module (can be builtin or loadable)
btrfs.dyndbg="+p"
@@ -364,3 +346,38 @@ Examples
dyndbg="file init/* +p #cmt ; func parse_one +p"
// enable pr_debugs in 2 functions in a module loaded later
pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p"
+
+Kernel Configuration
+====================
+
+Dynamic Debug is enabled via kernel config items::
+
+ CONFIG_DYNAMIC_DEBUG=y # build catalog, enables CORE
+ CONFIG_DYNAMIC_DEBUG_CORE=y # enable mechanics only, skip catalog
+
+If you do not want to enable dynamic debug globally (i.e. in some embedded
+system), you may set ``CONFIG_DYNAMIC_DEBUG_CORE`` as basic support of dynamic
+debug and add ``ccflags := -DDYNAMIC_DEBUG_MODULE`` into the Makefile of any
+modules which you'd like to dynamically debug later.
+
+
+Kernel *prdbg* API
+==================
+
+The following functions are cataloged and controllable when dynamic
+debug is enabled::
+
+ pr_debug()
+ dev_dbg()
+ print_hex_dump_debug()
+ print_hex_dump_bytes()
+
+Otherwise, they are off by default; ``ccflags += -DDEBUG`` or
+``#define DEBUG`` in a source file will enable them appropriately.
+
+If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``print_hex_dump_debug()`` is
+just a shortcut for ``print_hex_dump(KERN_DEBUG)``.
+
+For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is
+its ``prefix_str`` argument, if it is constant string; or ``hexdump``
+in case ``prefix_str`` is built dynamically.
diff --git a/Documentation/admin-guide/edid.rst b/Documentation/admin-guide/edid.rst
index 80deeb21a265..1a9b965aa486 100644
--- a/Documentation/admin-guide/edid.rst
+++ b/Documentation/admin-guide/edid.rst
@@ -24,37 +24,4 @@ restrictions later on.
As a remedy for such situations, the kernel configuration item
CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
individually prepared or corrected EDID data set in the /lib/firmware
-directory from where it is loaded via the firmware interface. The code
-(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
-commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
-1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
-not contain code to create these data. In order to elucidate the origin
-of the built-in binary EDID blobs and to facilitate the creation of
-individual data for a specific misbehaving monitor, commented sources
-and a Makefile environment are given here.
-
-To create binary EDID and C source code files from the existing data
-material, simply type "make" in tools/edid/.
-
-If you want to create your own EDID file, copy the file 1024x768.S,
-replace the settings with your own data and add a new target to the
-Makefile. Please note that the EDID data structure expects the timing
-values in a different way as compared to the standard X11 format.
-
-X11:
- HTimings:
- hdisp hsyncstart hsyncend htotal
- VTimings:
- vdisp vsyncstart vsyncend vtotal
-
-EDID::
-
- #define XPIX hdisp
- #define XBLANK htotal-hdisp
- #define XOFFSET hsyncstart-hdisp
- #define XPULSE hsyncend-hsyncstart
-
- #define YPIX vdisp
- #define YBLANK vtotal-vdisp
- #define YOFFSET vsyncstart-vdisp
- #define YPULSE vsyncend-vsyncstart
+directory from where it is loaded via the firmware interface.
diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst
index b24e7c40d832..f8e7407698bd 100644
--- a/Documentation/admin-guide/efi-stub.rst
+++ b/Documentation/admin-guide/efi-stub.rst
@@ -15,7 +15,7 @@ between architectures is in drivers/firmware/efi/libstub.
For arm64, there is no compressed kernel support, so the Image itself
masquerades as a PE/COFF image and the EFI stub is linked into the
-kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
+kernel. The arm64 EFI stub lives in drivers/firmware/efi/libstub/arm64.c
and drivers/firmware/efi/libstub/arm64-stub.c.
By using the EFI boot stub it's possible to boot a Linux kernel
@@ -79,6 +79,9 @@ because the image we're executing is interpreted by the EFI shell,
which understands relative paths, whereas the rest of the command line
is passed to bzImage.efi.
+.. hint::
+ It is also possible to provide an initrd using a Linux-specific UEFI
+ protocol at boot time. See :ref:`pe-coff-entry-point` for details.
The "dtb=" option
-----------------
diff --git a/Documentation/admin-guide/ext4.rst b/Documentation/admin-guide/ext4.rst
index 4c559e08d11e..ac0c709ea9e7 100644
--- a/Documentation/admin-guide/ext4.rst
+++ b/Documentation/admin-guide/ext4.rst
@@ -212,16 +212,6 @@ When mounting an ext4 filesystem, the following option are accepted:
that ext4's inode table readahead algorithm will pre-read into the
buffer cache. The default value is 32 blocks.
- nouser_xattr
- Disables Extended User Attributes. See the attr(5) manual page for
- more information about extended attributes.
-
- noacl
- This option disables POSIX Access Control List support. If ACL support
- is enabled in the kernel configuration (CONFIG_EXT4_FS_POSIX_ACL), ACL
- is enabled by default on mount. See the acl(5) manual page for more
- information about acl.
-
bsddf (*)
Make 'df' act like BSD.
@@ -248,11 +238,10 @@ When mounting an ext4 filesystem, the following option are accepted:
configured using tune2fs)
data_err=ignore(*)
- Just print an error message if an error occurs in a file data buffer in
- ordered mode.
+ Just print an error message if an error occurs in a file data buffer.
+
data_err=abort
- Abort the journal if an error occurs in a file data buffer in ordered
- mode.
+ Abort the journal if an error occurs in a file data buffer.
grpid | bsdgroups
New objects have the group ID of their parent.
@@ -409,7 +398,7 @@ There are 3 different data modes:
* writeback mode
In data=writeback mode, ext4 does not journal data at all. This mode provides
- a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
+ a similar level of journaling as that of XFS and JFS in its default
mode - metadata journaling. A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash. This mode will
typically provide the best ext4 performance.
@@ -489,9 +478,6 @@ Files in /sys/fs/ext4/<devname>:
multiple of this tuning parameter if the stripe size is not set in the
ext4 superblock
- mb_max_inode_prealloc
- The maximum length of per-inode ext4_prealloc_space list.
-
mb_max_to_scan
The maximum number of extents the multiblock allocator will search to
find the best extent.
diff --git a/Documentation/admin-guide/features.rst b/Documentation/admin-guide/features.rst
index 8c167082a84f..7651eca38227 100644
--- a/Documentation/admin-guide/features.rst
+++ b/Documentation/admin-guide/features.rst
@@ -1,3 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
-.. kernel-feat:: $srctree/Documentation/features
+.. kernel-feat:: features
diff --git a/Documentation/admin-guide/gpio/gpio-aggregator.rst b/Documentation/admin-guide/gpio/gpio-aggregator.rst
index 5cd1e7221756..8374a9df9105 100644
--- a/Documentation/admin-guide/gpio/gpio-aggregator.rst
+++ b/Documentation/admin-guide/gpio/gpio-aggregator.rst
@@ -69,6 +69,113 @@ write-only attribute files in sysfs.
$ echo gpio-aggregator.0 > delete_device
+Aggregating GPIOs using Configfs
+--------------------------------
+
+**Group:** ``/config/gpio-aggregator``
+
+ This is the root directory of the gpio-aggregator configfs tree.
+
+**Group:** ``/config/gpio-aggregator/<example-name>``
+
+ This directory represents a GPIO aggregator device. You can assign any
+ name to ``<example-name>`` (e.g. ``agg0``), except names starting with
+ ``_sysfs`` prefix, which are reserved for auto-generated configfs
+ entries corresponding to devices created via Sysfs.
+
+**Attribute:** ``/config/gpio-aggregator/<example-name>/live``
+
+ The ``live`` attribute allows to trigger the actual creation of the device
+ once it's fully configured. Accepted values are:
+
+ * ``1``, ``yes``, ``true`` : enable the virtual device
+ * ``0``, ``no``, ``false`` : disable the virtual device
+
+**Attribute:** ``/config/gpio-aggregator/<example-name>/dev_name``
+
+ The read-only ``dev_name`` attribute exposes the name of the device as it
+ will appear in the system on the platform bus (e.g. ``gpio-aggregator.0``).
+ This is useful for identifying a character device for the newly created
+ aggregator. If it's ``gpio-aggregator.0``,
+ ``/sys/devices/platform/gpio-aggregator.0/gpiochipX`` path tells you that the
+ GPIO device id is ``X``.
+
+You must create subdirectories for each virtual line you want to
+instantiate, named exactly as ``line0``, ``line1``, ..., ``lineY``, when
+you want to instantiate ``Y+1`` (Y >= 0) lines. Configure all lines before
+activating the device by setting ``live`` to 1.
+
+**Group:** ``/config/gpio-aggregator/<example-name>/<lineY>/``
+
+ This directory represents a GPIO line to include in the aggregator.
+
+**Attribute:** ``/config/gpio-aggregator/<example-name>/<lineY>/key``
+
+**Attribute:** ``/config/gpio-aggregator/<example-name>/<lineY>/offset``
+
+ The default values after creating the ``<lineY>`` directory are:
+
+ * ``key`` : <empty>
+ * ``offset`` : -1
+
+ ``key`` must always be explicitly configured, while ``offset`` depends.
+ Two configuration patterns exist for each ``<lineY>``:
+
+ (a). For lookup by GPIO line name:
+
+ * Set ``key`` to the line name.
+ * Ensure ``offset`` remains -1 (the default).
+
+ (b). For lookup by GPIO chip name and the line offset within the chip:
+
+ * Set ``key`` to the chip name.
+ * Set ``offset`` to the line offset (0 <= ``offset`` < 65535).
+
+**Attribute:** ``/config/gpio-aggregator/<example-name>/<lineY>/name``
+
+ The ``name`` attribute sets a custom name for lineY. If left unset, the
+ line will remain unnamed.
+
+Once the configuration is done, the ``'live'`` attribute must be set to 1
+in order to instantiate the aggregator device. It can be set back to 0 to
+destroy the virtual device. The module will synchronously wait for the new
+aggregator device to be successfully probed and if this doesn't happen, writing
+to ``'live'`` will result in an error. This is a different behaviour from the
+case when you create it using sysfs ``new_device`` interface.
+
+.. note::
+
+ For aggregators created via Sysfs, the configfs entries are
+ auto-generated and appear as ``/config/gpio-aggregator/_sysfs.<N>/``. You
+ cannot add or remove line directories with mkdir(2)/rmdir(2). To modify
+ lines, you must use the "delete_device" interface to tear down the
+ existing device and reconfigure it from scratch. However, you can still
+ toggle the aggregator with the ``live`` attribute and adjust the
+ ``key``, ``offset``, and ``name`` attributes for each line when ``live``
+ is set to 0 by hand (i.e. it's not waiting for deferred probe).
+
+Sample configuration commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: sh
+
+ # Create a directory for an aggregator device
+ $ mkdir /sys/kernel/config/gpio-aggregator/agg0
+
+ # Configure each line
+ $ mkdir /sys/kernel/config/gpio-aggregator/agg0/line0
+ $ echo gpiochip0 > /sys/kernel/config/gpio-aggregator/agg0/line0/key
+ $ echo 6 > /sys/kernel/config/gpio-aggregator/agg0/line0/offset
+ $ echo test0 > /sys/kernel/config/gpio-aggregator/agg0/line0/name
+ $ mkdir /sys/kernel/config/gpio-aggregator/agg0/line1
+ $ echo gpiochip0 > /sys/kernel/config/gpio-aggregator/agg0/line1/key
+ $ echo 7 > /sys/kernel/config/gpio-aggregator/agg0/line1/offset
+ $ echo test1 > /sys/kernel/config/gpio-aggregator/agg0/line1/name
+
+ # Activate the aggregator device
+ $ echo 1 > /sys/kernel/config/gpio-aggregator/agg0/live
+
+
Generic GPIO Driver
-------------------
diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst
index 493071da1738..d6e7438a7550 100644
--- a/Documentation/admin-guide/gpio/gpio-mockup.rst
+++ b/Documentation/admin-guide/gpio/gpio-mockup.rst
@@ -3,6 +3,14 @@
GPIO Testing Driver
===================
+.. note::
+
+ This module has been obsoleted by the more flexible gpio-sim.rst.
+ New developments should use that API and existing developments are
+ encouraged to migrate as soon as possible.
+ This module will continue to be maintained but no new features will be
+ added.
+
The GPIO Testing Driver (gpio-mockup) provides a way to create simulated GPIO
chips for testing purposes. The lines exposed by these chips can be accessed
using the standard GPIO character device interface as well as manipulated
diff --git a/Documentation/admin-guide/gpio/gpio-sim.rst b/Documentation/admin-guide/gpio/gpio-sim.rst
index d8a90c81b9ee..f5135a14ef2e 100644
--- a/Documentation/admin-guide/gpio/gpio-sim.rst
+++ b/Documentation/admin-guide/gpio/gpio-sim.rst
@@ -50,8 +50,11 @@ the number of lines exposed by this bank.
**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/name``
-This group represents a single line at the offset Y. The 'name' attribute
-allows to set the line name as represented by the 'gpio-line-names' property.
+**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/valid``
+
+This group represents a single line at the offset Y. The ``valid`` attribute
+indicates whether the line can be used as GPIO. The ``name`` attribute allows
+to set the line name as represented by the 'gpio-line-names' property.
**Item:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/hog``
@@ -71,7 +74,7 @@ specific lines. The name of those subdirectories must take the form of:
``'line<offset>'`` (e.g. ``'line0'``, ``'line20'``, etc.) as the name will be
used by the module to assign the config to the specific line at given offset.
-Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in
+Once the configuration is complete, the ``'live'`` attribute must be set to 1 in
order to instantiate the chip. It can be set back to 0 to destroy the simulated
chip. The module will synchronously wait for the new simulated device to be
successfully probed and if this doesn't happen, writing to ``'live'`` will
@@ -123,7 +126,7 @@ Each simulated GPIO chip creates a separate sysfs group under its device
directory for each exposed line
(e.g. ``/sys/devices/platform/gpio-sim.X/gpiochipY/``). The name of each group
is of the form: ``'sim_gpioX'`` where X is the offset of the line. Inside each
-group there are two attibutes:
+group there are two attributes:
``pull`` - allows to read and set the current simulated pull setting for
every line, when writing the value must be one of: ``'pull-up'``,
diff --git a/Documentation/admin-guide/gpio/gpio-virtuser.rst b/Documentation/admin-guide/gpio/gpio-virtuser.rst
new file mode 100644
index 000000000000..7e7c0df51640
--- /dev/null
+++ b/Documentation/admin-guide/gpio/gpio-virtuser.rst
@@ -0,0 +1,177 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Virtual GPIO Consumer
+=====================
+
+The virtual GPIO Consumer module allows users to instantiate virtual devices
+that request GPIOs and then control their behavior over debugfs. Virtual
+consumer devices can be instantiated from device-tree or over configfs.
+
+A virtual consumer uses the driver-facing GPIO APIs and allows to cover it with
+automated tests driven by user-space. The GPIOs are requested using
+``gpiod_get_array()`` and so we support multiple GPIOs per connector ID.
+
+Creating GPIO consumers
+-----------------------
+
+The gpio-consumer module registers a configfs subsystem called
+``'gpio-virtuser'``. For details of the configfs filesystem, please refer to
+the configfs documentation.
+
+The user can create a hierarchy of configfs groups and items as well as modify
+values of exposed attributes. Once the consumer is instantiated, this hierarchy
+will be translated to appropriate device properties. The general structure is:
+
+**Group:** ``/config/gpio-virtuser``
+
+This is the top directory of the gpio-consumer configfs tree.
+
+**Group:** ``/config/gpio-consumer/example-name``
+
+**Attribute:** ``/config/gpio-consumer/example-name/live``
+
+**Attribute:** ``/config/gpio-consumer/example-name/dev_name``
+
+This is a directory representing a GPIO consumer device.
+
+The read-only ``dev_name`` attribute exposes the name of the device as it will
+appear in the system on the platform bus. This is useful for locating the
+associated debugfs directory under
+``/sys/kernel/debug/gpio-virtuser/$dev_name``.
+
+The ``'live'`` attribute allows to trigger the actual creation of the device
+once it's fully configured. The accepted values are: ``'1'`` to enable the
+virtual device and ``'0'`` to disable and tear it down.
+
+Creating GPIO lookup tables
+---------------------------
+
+Users can create a number of configfs groups under the device group:
+
+**Group:** ``/config/gpio-consumer/example-name/con_id``
+
+The ``'con_id'`` directory represents a single GPIO lookup and its value maps
+to the ``'con_id'`` argument of the ``gpiod_get()`` function. For example:
+``con_id`` == ``'reset'`` maps to the ``reset-gpios`` device property.
+
+Users can assign a number of GPIOs to each lookup. Each GPIO is a sub-directory
+with a user-defined name under the ``'con_id'`` group.
+
+**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/key``
+
+**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/offset``
+
+**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/drive``
+
+**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/pull``
+
+**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/active_low``
+
+**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/transitory``
+
+This is a group describing a single GPIO in the ``con_id-gpios`` property.
+
+For virtual consumers created using configfs we use machine lookup tables so
+this group can be considered as a mapping between the filesystem and the fields
+of a single entry in ``'struct gpiod_lookup'``.
+
+The ``'key'`` attribute represents either the name of the chip this GPIO
+belongs to or the GPIO line name. This depends on the value of the ``'offset'``
+attribute: if its value is >= 0, then ``'key'`` represents the label of the
+chip to lookup while ``'offset'`` represents the offset of the line in that
+chip. If ``'offset'`` is < 0, then ``'key'`` represents the name of the line.
+
+The remaining attributes map to the ``'flags'`` field of the GPIO lookup
+struct. The first two take string values as arguments:
+
+**``'drive'``:** ``'push-pull'``, ``'open-drain'``, ``'open-source'``
+**``'pull'``:** ``'pull-up'``, ``'pull-down'``, ``'pull-disabled'``, ``'as-is'``
+
+``'active_low'`` and ``'transitory'`` are boolean attributes.
+
+Activating GPIO consumers
+-------------------------
+
+Once the configuration is complete, the ``'live'`` attribute must be set to 1 in
+order to instantiate the consumer. It can be set back to 0 to destroy the
+virtual device. The module will synchronously wait for the new simulated device
+to be successfully probed and if this doesn't happen, writing to ``'live'`` will
+result in an error.
+
+Device-tree
+-----------
+
+Virtual GPIO consumers can also be defined in device-tree. The compatible string
+must be: ``"gpio-virtuser"`` with at least one property following the
+standardized GPIO pattern.
+
+An example device-tree code defining a virtual GPIO consumer:
+
+.. code-block :: none
+
+ gpio-virt-consumer {
+ compatible = "gpio-virtuser";
+
+ foo-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>, <&gpio1 2 0>;
+ bar-gpios = <&gpio0 6 0>;
+ };
+
+Controlling virtual GPIO consumers
+----------------------------------
+
+Once active, the device will export debugfs attributes for controlling GPIO
+arrays as well as each requested GPIO line separately. Let's consider the
+following device property: ``foo-gpios = <&gpio0 0 0>, <&gpio0 4 0>;``.
+
+The following debugfs attribute groups will be created:
+
+**Group:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo/``
+
+This is the group that will contain the attributes for the entire GPIO array.
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo/values``
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo/values_atomic``
+
+Both attributes allow to read and set arrays of GPIO values. User must pass
+exactly the number of values that the array contains in the form of a string
+containing zeroes and ones representing inactive and active GPIO states
+respectively. In this example: ``echo 11 > values``.
+
+The ``values_atomic`` attribute works the same as ``values`` but the kernel
+will execute the GPIO driver callbacks in interrupt context.
+
+**Group:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/``
+
+This is a group that represents a single GPIO with ``$index`` being its offset
+in the array.
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/consumer``
+
+Allows to set and read the consumer label of the GPIO line.
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/debounce``
+
+Allows to set and read the debounce period of the GPIO line.
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/direction``
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/direction_atomic``
+
+These two attributes allow to set the direction of the GPIO line. They accept
+"input" and "output" as values. The atomic variant executes the driver callback
+in interrupt context.
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/interrupts``
+
+If the line is requested in input mode, writing ``1`` to this attribute will
+make the module listen for edge interrupts on the GPIO. Writing ``0`` disables
+the monitoring. Reading this attribute returns the current number of registered
+interrupts (both edges).
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/value``
+
+**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/value_atomic``
+
+Both attributes allow to read and set values of individual requested GPIO lines.
+They accept the following values: ``1`` and ``0``.
diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst
index f6861ca16ffe..712f379731cb 100644
--- a/Documentation/admin-guide/gpio/index.rst
+++ b/Documentation/admin-guide/gpio/index.rst
@@ -1,16 +1,17 @@
.. SPDX-License-Identifier: GPL-2.0
====
-gpio
+GPIO
====
.. toctree::
:maxdepth: 1
+ Character Device Userspace API <../../userspace-api/gpio/chardev>
gpio-aggregator
- sysfs
- gpio-mockup
gpio-sim
+ gpio-virtuser
+ Obsolete APIs <obsolete>
.. only:: subproject and html
diff --git a/Documentation/admin-guide/gpio/obsolete.rst b/Documentation/admin-guide/gpio/obsolete.rst
new file mode 100644
index 000000000000..5adbff02d61f
--- /dev/null
+++ b/Documentation/admin-guide/gpio/obsolete.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================
+Obsolete GPIO APIs
+==================
+
+.. toctree::
+ :maxdepth: 1
+
+ Character Device Userspace API (v1) <../../userspace-api/gpio/chardev_v1>
+ Sysfs Interface <../../userspace-api/gpio/sysfs>
+ Mockup Testing Module <gpio-mockup>
+
diff --git a/Documentation/admin-guide/highuid.rst b/Documentation/admin-guide/highuid.rst
deleted file mode 100644
index 6ee70465c0ea..000000000000
--- a/Documentation/admin-guide/highuid.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-===================================================
-Notes on the change from 16-bit UIDs to 32-bit UIDs
-===================================================
-
-:Author: Chris Wing <wingc@umich.edu>
-:Last updated: January 11, 2000
-
-- kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t
- when communicating between user and kernel space in an ioctl or data
- structure.
-
-- kernel code should use uid_t and gid_t in kernel-private structures and
- code.
-
-What's left to be done for 32-bit UIDs on all Linux architectures:
-
-- Disk quotas have an interesting limitation that is not related to the
- maximum UID/GID. They are limited by the maximum file size on the
- underlying filesystem, because quota records are written at offsets
- corresponding to the UID in question.
- Further investigation is needed to see if the quota system can cope
- properly with huge UIDs. If it can deal with 64-bit file offsets on all
- architectures, this should not be a problem.
-
-- Decide whether or not to keep backwards compatibility with the system
- accounting file, or if we should break it as the comments suggest
- (currently, the old 16-bit UID and GID are still written to disk, and
- part of the former pad space is used to store separate 32-bit UID and
- GID)
-
-- Need to validate that OS emulation calls the 16-bit UID
- compatibility syscalls, if the OS being emulated used 16-bit UIDs, or
- uses the 32-bit UID system calls properly otherwise.
-
- This affects at least:
-
- - iBCS on Intel
-
- - sparc32 emulation on sparc64
- (need to support whatever new 32-bit UID system calls are added to
- sparc32)
-
-- Validate that all filesystems behave properly.
-
- At present, 32-bit UIDs _should_ work for:
-
- - ext2
- - ufs
- - isofs
- - nfs
- - coda
- - udf
-
- Ioctl() fixups have been made for:
-
- - ncpfs
- - smbfs
-
- Filesystems with simple fixups to prevent 16-bit UID wraparound:
-
- - minix
- - sysv
- - qnx4
-
- Other filesystems have not been checked yet.
-
-- The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in
- all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but
- more are needed. (as well as new user<->kernel data structures)
-
-- The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k,
- sh, and sparc32. Fixing this is probably not that important, but would
- require adding a new ELF section.
-
-- The ioctl()s used to control the in-kernel NFS server only support
- 16-bit UIDs on arm, i386, m68k, sh, and sparc32.
-
-- make sure that the UID mapping feature of AX25 networking works properly
- (it should be safe because it's always used a 32-bit integer to
- communicate between user and kernel)
diff --git a/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst b/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
new file mode 100644
index 000000000000..d0bdbd81dcf9
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
@@ -0,0 +1,236 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Attack Vector Controls
+======================
+
+Attack vector controls provide a simple method to configure only the mitigations
+for CPU vulnerabilities which are relevant given the intended use of a system.
+Administrators are encouraged to consider which attack vectors are relevant and
+disable all others in order to recoup system performance.
+
+When new relevant CPU vulnerabilities are found, they will be added to these
+attack vector controls so administrators will likely not need to reconfigure
+their command line parameters as mitigations will continue to be correctly
+applied based on the chosen attack vector controls.
+
+Attack Vectors
+--------------
+
+There are 5 sets of attack-vector mitigations currently supported by the kernel:
+
+#. :ref:`user_kernel`
+#. :ref:`user_user`
+#. :ref:`guest_host`
+#. :ref:`guest_guest`
+#. :ref:`smt`
+
+To control the enabled attack vectors, see :ref:`cmdline`.
+
+.. _user_kernel:
+
+User-to-Kernel
+^^^^^^^^^^^^^^
+
+The user-to-kernel attack vector involves a malicious userspace program
+attempting to leak kernel data into userspace by exploiting a CPU vulnerability.
+The kernel data involved might be limited to certain kernel memory, or include
+all memory in the system, depending on the vulnerability exploited.
+
+If no untrusted userspace applications are being run, such as with single-user
+systems, consider disabling user-to-kernel mitigations.
+
+Note that the CPU vulnerabilities mitigated by Linux have generally not been
+shown to be exploitable from browser-based sandboxes. User-to-kernel
+mitigations are therefore mostly relevant if unknown userspace applications may
+be run by untrusted users.
+
+*user-to-kernel mitigations are enabled by default*
+
+.. _user_user:
+
+User-to-User
+^^^^^^^^^^^^
+
+The user-to-user attack vector involves a malicious userspace program attempting
+to influence the behavior of another unsuspecting userspace program in order to
+exfiltrate data. The vulnerability of a userspace program is based on the
+program itself and the interfaces it provides.
+
+If no untrusted userspace applications are being run, consider disabling
+user-to-user mitigations.
+
+Note that because the Linux kernel contains a mapping of all physical memory,
+preventing a malicious userspace program from leaking data from another
+userspace program requires mitigating user-to-kernel attacks as well for
+complete protection.
+
+*user-to-user mitigations are enabled by default*
+
+.. _guest_host:
+
+Guest-to-Host
+^^^^^^^^^^^^^
+
+The guest-to-host attack vector involves a malicious VM attempting to leak
+hypervisor data into the VM. The data involved may be limited, or may
+potentially include all memory in the system, depending on the vulnerability
+exploited.
+
+If no untrusted VMs are being run, consider disabling guest-to-host mitigations.
+
+*guest-to-host mitigations are enabled by default if KVM support is present*
+
+.. _guest_guest:
+
+Guest-to-Guest
+^^^^^^^^^^^^^^
+
+The guest-to-guest attack vector involves a malicious VM attempting to influence
+the behavior of another unsuspecting VM in order to exfiltrate data. The
+vulnerability of a VM is based on the code inside the VM itself and the
+interfaces it provides.
+
+If no untrusted VMs, or only a single VM is being run, consider disabling
+guest-to-guest mitigations.
+
+Similar to the user-to-user attack vector, preventing a malicious VM from
+leaking data from another VM requires mitigating guest-to-host attacks as well
+due to the Linux kernel phys map.
+
+*guest-to-guest mitigations are enabled by default if KVM support is present*
+
+.. _smt:
+
+Cross-Thread
+^^^^^^^^^^^^
+
+The cross-thread attack vector involves a malicious userspace program or
+malicious VM either observing or attempting to influence the behavior of code
+running on the SMT sibling thread in order to exfiltrate data.
+
+Many cross-thread attacks can only be mitigated if SMT is disabled, which will
+result in reduced CPU core count and reduced performance.
+
+If cross-thread mitigations are fully enabled ('auto,nosmt'), all mitigations
+for cross-thread attacks will be enabled. SMT may be disabled depending on
+which vulnerabilities are present in the CPU.
+
+If cross-thread mitigations are partially enabled ('auto'), mitigations for
+cross-thread attacks will be enabled but SMT will not be disabled.
+
+If cross-thread mitigations are disabled, no mitigations for cross-thread
+attacks will be enabled.
+
+Cross-thread mitigation may not be required if core-scheduling or similar
+techniques are used to prevent untrusted workloads from running on SMT siblings.
+
+*cross-thread mitigations default to partially enabled*
+
+.. _cmdline:
+
+Command Line Controls
+---------------------
+
+Attack vectors are controlled through the mitigations= command line option. The
+value provided begins with a global option and then may optionally include one
+or more options to disable various attack vectors.
+
+Format:
+ | ``mitigations=[global]``
+ | ``mitigations=[global],[attack vectors]``
+
+Global options:
+
+============ =============================================================
+Option Description
+============ =============================================================
+'off' All attack vectors disabled.
+'auto' All attack vectors enabled, partial cross-thread mitigations.
+'auto,nosmt' All attack vectors enabled, full cross-thread mitigations.
+============ =============================================================
+
+Attack vector options:
+
+================= =======================================
+Option Description
+================= =======================================
+'no_user_kernel' Disables user-to-kernel mitigations.
+'no_user_user' Disables user-to-user mitigations.
+'no_guest_host' Disables guest-to-host mitigations.
+'no_guest_guest' Disables guest-to-guest mitigations
+'no_cross_thread' Disables all cross-thread mitigations.
+================= =======================================
+
+Multiple attack vector options may be specified in a comma-separated list. If
+the global option is not specified, it defaults to 'auto'. The global option
+'off' is equivalent to disabling all attack vectors.
+
+Examples:
+ | ``mitigations=auto,no_user_kernel``
+
+ Enable all attack vectors except user-to-kernel. Partial cross-thread
+ mitigations.
+
+ | ``mitigations=auto,nosmt,no_guest_host,no_guest_guest``
+
+ Enable all attack vectors and cross-thread mitigations except for
+ guest-to-host and guest-to-guest mitigations.
+
+ | ``mitigations=,no_cross_thread``
+
+ Enable all attack vectors but not cross-thread mitigations.
+
+Interactions with command-line options
+--------------------------------------
+
+Vulnerability-specific controls (e.g. "retbleed=off") take precedence over all
+attack vector controls. Mitigations for individual vulnerabilities may be
+turned on or off via their command-line options regardless of the attack vector
+controls.
+
+Summary of attack-vector mitigations
+------------------------------------
+
+When a vulnerability is mitigated due to an attack-vector control, the default
+mitigation option for that particular vulnerability is used. To use a different
+mitigation, please use the vulnerability-specific command line option.
+
+The table below summarizes which vulnerabilities are mitigated when different
+attack vectors are enabled and assuming the CPU is vulnerable.
+
+=============== ============== ============ ============= ============== ============ ========
+Vulnerability User-to-Kernel User-to-User Guest-to-Host Guest-to-Guest Cross-Thread Notes
+=============== ============== ============ ============= ============== ============ ========
+BHI X X
+ITS X X
+GDS X X X X * (Note 1)
+L1TF X X * (Note 2)
+MDS X X X X * (Note 2)
+MMIO X X X X * (Note 2)
+Meltdown X
+Retbleed X X * (Note 3)
+RFDS X X X X
+Spectre_v1 X
+Spectre_v2 X X
+Spectre_v2_user X X * (Note 1)
+SRBDS X X X X
+SRSO X X X X
+SSB X
+TAA X X X X * (Note 2)
+TSA X X X X
+VMSCAPE X
+=============== ============== ============ ============= ============== ============ ========
+
+Notes:
+ 1 -- Can be mitigated without disabling SMT.
+
+ 2 -- Disables SMT if cross-thread mitigations are fully enabled and the CPU
+ is vulnerable
+
+ 3 -- Disables SMT if cross-thread mitigations are fully enabled, the CPU is
+ vulnerable, and STIBP is not supported
+
+When an attack-vector is disabled, all mitigations for the vulnerabilities
+listed in the above table are disabled, unless mitigation is required for a
+different enabled attack-vector or a mitigation is explicitly selected via a
+vulnerability-specific command line option.
diff --git a/Documentation/admin-guide/hw-vuln/core-scheduling.rst b/Documentation/admin-guide/hw-vuln/core-scheduling.rst
index cf1eeefdfc32..a92e10ec402e 100644
--- a/Documentation/admin-guide/hw-vuln/core-scheduling.rst
+++ b/Documentation/admin-guide/hw-vuln/core-scheduling.rst
@@ -67,8 +67,8 @@ arg4:
will be performed for all tasks in the task group of ``pid``.
arg5:
- userspace pointer to an unsigned long for storing the cookie returned by
- ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
+ userspace pointer to an unsigned long long for storing the cookie returned
+ by ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
In order for a process to push a cookie to, or pull a cookie from a process, it
is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the
diff --git a/Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst b/Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst
new file mode 100644
index 000000000000..875616d675fe
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst
@@ -0,0 +1,91 @@
+
+.. SPDX-License-Identifier: GPL-2.0
+
+Cross-Thread Return Address Predictions
+=======================================
+
+Certain AMD and Hygon processors are subject to a cross-thread return address
+predictions vulnerability. When running in SMT mode and one sibling thread
+transitions out of C0 state, the other sibling thread could use return target
+predictions from the sibling thread that transitioned out of C0.
+
+The Spectre v2 mitigations protect the Linux kernel, as it fills the return
+address prediction entries with safe targets when context switching to the idle
+thread. However, KVM does allow a VMM to prevent exiting guest mode when
+transitioning out of C0. This could result in a guest-controlled return target
+being consumed by the sibling thread.
+
+Affected processors
+-------------------
+
+The following CPUs are vulnerable:
+
+ - AMD Family 17h processors
+ - Hygon Family 18h processors
+
+Related CVEs
+------------
+
+The following CVE entry is related to this issue:
+
+ ============== =======================================
+ CVE-2022-27672 Cross-Thread Return Address Predictions
+ ============== =======================================
+
+Problem
+-------
+
+Affected SMT-capable processors support 1T and 2T modes of execution when SMT
+is enabled. In 2T mode, both threads in a core are executing code. For the
+processor core to enter 1T mode, it is required that one of the threads
+requests to transition out of the C0 state. This can be communicated with the
+HLT instruction or with an MWAIT instruction that requests non-C0.
+When the thread re-enters the C0 state, the processor transitions back
+to 2T mode, assuming the other thread is also still in C0 state.
+
+In affected processors, the return address predictor (RAP) is partitioned
+depending on the SMT mode. For instance, in 2T mode each thread uses a private
+16-entry RAP, but in 1T mode, the active thread uses a 32-entry RAP. Upon
+transition between 1T/2T mode, the RAP contents are not modified but the RAP
+pointers (which control the next return target to use for predictions) may
+change. This behavior may result in return targets from one SMT thread being
+used by RET predictions in the sibling thread following a 1T/2T switch. In
+particular, a RET instruction executed immediately after a transition to 1T may
+use a return target from the thread that just became idle. In theory, this
+could lead to information disclosure if the return targets used do not come
+from trustworthy code.
+
+Attack scenarios
+----------------
+
+An attack can be mounted on affected processors by performing a series of CALL
+instructions with targeted return locations and then transitioning out of C0
+state.
+
+Mitigation mechanism
+--------------------
+
+Before entering idle state, the kernel context switches to the idle thread. The
+context switch fills the RAP entries (referred to as the RSB in Linux) with safe
+targets by performing a sequence of CALL instructions.
+
+Prevent a guest VM from directly putting the processor into an idle state by
+intercepting HLT and MWAIT instructions.
+
+Both mitigations are required to fully address this issue.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+
+Use existing Spectre v2 mitigations that will fill the RSB on context switch.
+
+Mitigation control for KVM - module parameter
+---------------------------------------------
+
+By default, the KVM hypervisor mitigates this issue by intercepting guest
+attempts to transition out of C0. A VMM can use the KVM_CAP_X86_DISABLE_EXITS
+capability to override those interceptions, but since this is not common, the
+mitigation that covers this path is not enabled by default.
+
+The mitigation for the KVM_CAP_X86_DISABLE_EXITS capability can be turned on
+using the boolean module parameter mitigate_smt_rsb, e.g. ``kvm.mitigate_smt_rsb=1``.
diff --git a/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
new file mode 100644
index 000000000000..264bfa937f7d
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+GDS - Gather Data Sampling
+==========================
+
+Gather Data Sampling is a hardware vulnerability which allows unprivileged
+speculative access to data which was previously stored in vector registers.
+
+Problem
+-------
+When a gather instruction performs loads from memory, different data elements
+are merged into the destination vector register. However, when a gather
+instruction that is transiently executed encounters a fault, stale data from
+architectural or internal vector registers may get transiently forwarded to the
+destination vector register instead. This will allow a malicious attacker to
+infer stale data using typical side channel techniques like cache timing
+attacks. GDS is a purely sampling-based attack.
+
+The attacker uses gather instructions to infer the stale vector register data.
+The victim does not need to do anything special other than use the vector
+registers. The victim does not need to use gather instructions to be
+vulnerable.
+
+Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks
+are possible.
+
+Attack scenarios
+----------------
+Without mitigation, GDS can infer stale data across virtually all
+permission boundaries:
+
+ Non-enclaves can infer SGX enclave data
+ Userspace can infer kernel data
+ Guests can infer data from hosts
+ Guest can infer guest from other guests
+ Users can infer data from other users
+
+Because of this, it is important to ensure that the mitigation stays enabled in
+lower-privilege contexts like guests and when running outside SGX enclaves.
+
+The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure
+that guests are not allowed to disable the GDS mitigation. If a host erred and
+allowed this, a guest could theoretically disable GDS mitigation, mount an
+attack, and re-enable it.
+
+Mitigation mechanism
+--------------------
+This issue is mitigated in microcode. The microcode defines the following new
+bits:
+
+ ================================ === ============================
+ IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability
+ and mitigation support.
+ IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable.
+ IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation
+ 0 by default.
+ IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes
+ to GDS_MITG_DIS are ignored
+ Can't be cleared once set.
+ ================================ === ============================
+
+GDS can also be mitigated on systems that don't have updated microcode by
+disabling AVX. This can be done by setting gather_data_sampling="force" or
+"clearcpuid=avx" on the kernel command-line.
+
+If used, these options will disable AVX use by turning off XSAVE YMM support.
+However, the processor will still enumerate AVX support. Userspace that
+does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
+support will break.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+The mitigation can be disabled by setting "gather_data_sampling=off" or
+"mitigations=off" on the kernel command line. Not specifying either will default
+to the mitigation being enabled. Specifying "gather_data_sampling=force" will
+use the microcode mitigation when available or disable AVX on affected systems
+where the microcode hasn't been updated to include the mitigation.
+
+GDS System Information
+------------------------
+The kernel provides vulnerability status information through sysfs. For
+GDS this can be accessed by the following sysfs file:
+
+/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
+
+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected Processor not vulnerable.
+ Vulnerable Processor vulnerable and mitigation disabled.
+ Vulnerable: No microcode Processor vulnerable and microcode is missing
+ mitigation.
+ Mitigation: AVX disabled,
+ no microcode Processor is vulnerable and microcode is missing
+ mitigation. AVX disabled as mitigation.
+ Mitigation: Microcode Processor is vulnerable and mitigation is in
+ effect.
+ Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
+ effect and cannot be disabled.
+ Unknown: Dependent on
+ hypervisor status Running on a virtual guest processor that is
+ affected but with no way to know if host
+ processor is mitigated or vulnerable.
+ ============================== =============================================
+
+GDS Default mitigation
+----------------------
+The updated microcode will enable the mitigation by default. The kernel's
+default action is to leave the mitigation enabled.
diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst
index 4df436e7c417..55d747511f83 100644
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -9,12 +9,21 @@ are configurable at compile, boot or run time.
.. toctree::
:maxdepth: 1
+ attack_vector_controls
spectre
l1tf
mds
tsx_async_abort
- multihit.rst
- special-register-buffer-data-sampling.rst
- core-scheduling.rst
- l1d_flush.rst
- processor_mmio_stale_data.rst
+ multihit
+ special-register-buffer-data-sampling
+ core-scheduling
+ l1d_flush
+ processor_mmio_stale_data
+ cross-thread-rsb
+ srso
+ gather_data_sampling
+ reg-file-data-sampling
+ rsb
+ old_microcode
+ indirect-target-selection
+ vmscape
diff --git a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
new file mode 100644
index 000000000000..d9ca64108d23
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
@@ -0,0 +1,168 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Indirect Target Selection (ITS)
+===============================
+
+ITS is a vulnerability in some Intel CPUs that support Enhanced IBRS and were
+released before Alder Lake. ITS may allow an attacker to control the prediction
+of indirect branches and RETs located in the lower half of a cacheline.
+
+ITS is assigned CVE-2024-28956 with a CVSS score of 4.7 (Medium).
+
+Scope of Impact
+---------------
+- **eIBRS Guest/Host Isolation**: Indirect branches in KVM/kernel may still be
+ predicted with unintended target corresponding to a branch in the guest.
+
+- **Intra-Mode BTI**: In-kernel training such as through cBPF or other native
+ gadgets.
+
+- **Indirect Branch Prediction Barrier (IBPB)**: After an IBPB, indirect
+ branches may still be predicted with targets corresponding to direct branches
+ executed prior to the IBPB. This is fixed by the IPU 2025.1 microcode, which
+ should be available via distro updates. Alternatively microcode can be
+ obtained from Intel's github repository [#f1]_.
+
+Affected CPUs
+-------------
+Below is the list of ITS affected CPUs [#f2]_ [#f3]_:
+
+ ======================== ============ ==================== ===============
+ Common name Family_Model eIBRS Intra-mode BTI
+ Guest/Host Isolation
+ ======================== ============ ==================== ===============
+ SKYLAKE_X (step >= 6) 06_55H Affected Affected
+ ICELAKE_X 06_6AH Not affected Affected
+ ICELAKE_D 06_6CH Not affected Affected
+ ICELAKE_L 06_7EH Not affected Affected
+ TIGERLAKE_L 06_8CH Not affected Affected
+ TIGERLAKE 06_8DH Not affected Affected
+ KABYLAKE_L (step >= 12) 06_8EH Affected Affected
+ KABYLAKE (step >= 13) 06_9EH Affected Affected
+ COMETLAKE 06_A5H Affected Affected
+ COMETLAKE_L 06_A6H Affected Affected
+ ROCKETLAKE 06_A7H Not affected Affected
+ ======================== ============ ==================== ===============
+
+- All affected CPUs enumerate Enhanced IBRS feature.
+- IBPB isolation is affected on all ITS affected CPUs, and need a microcode
+ update for mitigation.
+- None of the affected CPUs enumerate BHI_CTRL which was introduced in Golden
+ Cove (Alder Lake and Sapphire Rapids). This can help guests to determine the
+ host's affected status.
+- Intel Atom CPUs are not affected by ITS.
+
+Mitigation
+----------
+As only the indirect branches and RETs that have their last byte of instruction
+in the lower half of the cacheline are vulnerable to ITS, the basic idea behind
+the mitigation is to not allow indirect branches in the lower half.
+
+This is achieved by relying on existing retpoline support in the kernel, and in
+compilers. ITS-vulnerable retpoline sites are runtime patched to point to newly
+added ITS-safe thunks. These safe thunks consists of indirect branch in the
+second half of the cacheline. Not all retpoline sites are patched to thunks, if
+a retpoline site is evaluated to be ITS-safe, it is replaced with an inline
+indirect branch.
+
+Dynamic thunks
+~~~~~~~~~~~~~~
+From a dynamically allocated pool of safe-thunks, each vulnerable site is
+replaced with a new thunk, such that they get a unique address. This could
+improve the branch prediction accuracy. Also, it is a defense-in-depth measure
+against aliasing.
+
+Note, for simplicity, indirect branches in eBPF programs are always replaced
+with a jump to a static thunk in __x86_indirect_its_thunk_array. If required,
+in future this can be changed to use dynamic thunks.
+
+All vulnerable RETs are replaced with a static thunk, they do not use dynamic
+thunks. This is because RETs get their prediction from RSB mostly that does not
+depend on source address. RETs that underflow RSB may benefit from dynamic
+thunks. But, RETs significantly outnumber indirect branches, and any benefit
+from a unique source address could be outweighed by the increased icache
+footprint and iTLB pressure.
+
+Retpoline
+~~~~~~~~~
+Retpoline sequence also mitigates ITS-unsafe indirect branches. For this
+reason, when retpoline is enabled, ITS mitigation only relocates the RETs to
+safe thunks. Unless user requested the RSB-stuffing mitigation.
+
+RSB Stuffing
+~~~~~~~~~~~~
+RSB-stuffing via Call Depth Tracking is a mitigation for Retbleed RSB-underflow
+attacks. And it also mitigates RETs that are vulnerable to ITS.
+
+Mitigation in guests
+^^^^^^^^^^^^^^^^^^^^
+All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
+and Family/Model of the guest. This is because eIBRS feature could be hidden
+from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
+indicates that the guest is running on an unaffected host.
+
+To prevent guests from unnecessarily deploying the mitigation on unaffected
+platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
+a guest sees this bit set, it should not enumerate the ITS bug. Note, this bit
+is not set by any hardware, but is **intended for VMMs to synthesize** it for
+guests as per the host's affected status.
+
+Mitigation options
+^^^^^^^^^^^^^^^^^^
+The ITS mitigation can be controlled using the "indirect_target_selection"
+kernel parameter. The available options are:
+
+ ======== ===================================================================
+ on (default) Deploy the "Aligned branch/return thunks" mitigation.
+ If spectre_v2 mitigation enables retpoline, aligned-thunks are only
+ deployed for the affected RET instructions. Retpoline mitigates
+ indirect branches.
+
+ off Disable ITS mitigation.
+
+ vmexit Equivalent to "=on" if the CPU is affected by guest/host isolation
+ part of ITS. Otherwise, mitigation is not deployed. This option is
+ useful when host userspace is not in the threat model, and only
+ attacks from guest to host are considered.
+
+ stuff Deploy RSB-fill mitigation when retpoline is also deployed.
+ Otherwise, deploy the default mitigation. When retpoline mitigation
+ is enabled, RSB-stuffing via Call-Depth-Tracking also mitigates
+ ITS.
+
+ force Force the ITS bug and deploy the default mitigation.
+ ======== ===================================================================
+
+Sysfs reporting
+---------------
+
+The sysfs file showing ITS mitigation status is:
+
+ /sys/devices/system/cpu/vulnerabilities/indirect_target_selection
+
+Note, microcode mitigation status is not reported in this file.
+
+The possible values in this file are:
+
+.. list-table::
+
+ * - Not affected
+ - The processor is not vulnerable.
+ * - Vulnerable
+ - System is vulnerable and no mitigation has been applied.
+ * - Vulnerable, KVM: Not affected
+ - System is vulnerable to intra-mode BTI, but not affected by eIBRS
+ guest/host isolation.
+ * - Mitigation: Aligned branch/return thunks
+ - The mitigation is enabled, affected indirect branches and RETs are
+ relocated to safe thunks.
+ * - Mitigation: Retpolines, Stuffing RSB
+ - The mitigation is enabled using retpoline and RSB stuffing.
+
+References
+----------
+.. [#f1] Microcode repository - https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
+
+.. [#f2] Affected Processors list - https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
+
+.. [#f3] Affected Processors list (machine readable) - https://github.com/intel/Intel-affected-processor-list
diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
index 210020bc3f56..35dc25159b28 100644
--- a/Documentation/admin-guide/hw-vuln/l1d_flush.rst
+++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst
@@ -31,7 +31,7 @@ specifically opt into the feature to enable it.
Mitigation
----------
-When PR_SET_L1D_FLUSH is enabled for a task a flush of the L1D cache is
+When PR_SPEC_L1D_FLUSH is enabled for a task a flush of the L1D cache is
performed when the task is scheduled out and the incoming task belongs to a
different process and therefore to a different address space.
diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst
index 2d19c9f4c1fe..754679db0ce8 100644
--- a/Documentation/admin-guide/hw-vuln/mds.rst
+++ b/Documentation/admin-guide/hw-vuln/mds.rst
@@ -58,14 +58,14 @@ Because the buffers are potentially shared between Hyper-Threads cross
Hyper-Thread attacks are possible.
Deeper technical information is available in the MDS specific x86
-architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
+architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`.
Attack scenarios
----------------
-Attacks against the MDS vulnerabilities can be mounted from malicious non
-priviledged user space applications running on hosts or guest. Malicious
+Attacks against the MDS vulnerabilities can be mounted from malicious non-
+privileged user space applications running on hosts or guest. Malicious
guest OSes can obviously mount attacks as well.
Contrary to other speculation based vulnerabilities the MDS vulnerability
@@ -102,9 +102,19 @@ The possible values in this file are:
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- - The processor is vulnerable but microcode is not updated.
-
- The mitigation is enabled on a best effort basis. See :ref:`vmwerv`
+ - The processor is vulnerable but microcode is not updated. The
+ mitigation is enabled on a best effort basis.
+
+ If the processor is vulnerable but the availability of the microcode
+ based mitigation mechanism is not advertised via CPUID, the kernel
+ selects a best effort mitigation mode. This mode invokes the mitigation
+ instructions without a guarantee that they clear the CPU buffers.
+
+ This is done to address virtualization scenarios where the host has the
+ microcode update applied, but the hypervisor is not yet updated to
+ expose the CPUID to the guest. If the host has updated microcode the
+ protection takes effect; otherwise a few CPU cycles are wasted
+ pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
@@ -119,24 +129,6 @@ to the above information:
'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
======================== ============================================
-.. _vmwerv:
-
-Best effort mitigation mode
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- If the processor is vulnerable, but the availability of the microcode based
- mitigation mechanism is not advertised via CPUID the kernel selects a best
- effort mitigation mode. This mode invokes the mitigation instructions
- without a guarantee that they clear the CPU buffers.
-
- This is done to address virtualization scenarios where the host has the
- microcode update applied, but the hypervisor is not yet updated to expose
- the CPUID to the guest. If the host has updated microcode the protection
- takes effect otherwise a few cpu cycles are wasted pointlessly.
-
- The state in the mds sysfs file reflects this situation accordingly.
-
-
Mitigation mechanism
-------------------------
@@ -222,7 +214,7 @@ XEON PHI specific considerations
command line with the 'ring3mwait=disable' command line option.
XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
- before the CPU enters a idle state. As XEON PHI is not affected by L1TF
+ before the CPU enters an idle state. As XEON PHI is not affected by L1TF
either disabling SMT is not required for full protection.
.. _mds_smt_control:
diff --git a/Documentation/admin-guide/hw-vuln/old_microcode.rst b/Documentation/admin-guide/hw-vuln/old_microcode.rst
new file mode 100644
index 000000000000..6ded8f86b8d0
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/old_microcode.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+Old Microcode
+=============
+
+The kernel keeps a table of released microcode. Systems that had
+microcode older than this at boot will say "Vulnerable". This means
+that the system was vulnerable to some known CPU issue. It could be
+security or functional, the kernel does not know or care.
+
+You should update the CPU microcode to mitigate any exposure. This is
+usually accomplished by updating the files in
+/lib/firmware/intel-ucode/ via normal distribution updates. Intel also
+distributes these files in a github repo:
+
+ https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
+
+Just like all the other hardware vulnerabilities, exposure is
+determined at boot. Runtime microcode updates do not change the status
+of this vulnerability.
diff --git a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
index c98fd11907cc..6dba18dbb9ab 100644
--- a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
+++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
@@ -157,9 +157,7 @@ This is achieved by using the otherwise unused and obsolete VERW instruction in
combination with a microcode update. The microcode clears the affected CPU
buffers when the VERW instruction is executed.
-Kernel reuses the MDS function to invoke the buffer clearing:
-
- mds_clear_cpu_buffers()
+Kernel does the buffer clearing with x86_clear_cpu_buffers().
On MDS affected CPUs, the kernel already invokes CPU buffer clear on
kernel/userspace, hypervisor/guest and C-state (idle) transitions. No
@@ -225,8 +223,19 @@ The possible values in this file are:
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- - The processor is vulnerable, but microcode is not updated. The
+ - The processor is vulnerable but microcode is not updated. The
mitigation is enabled on a best effort basis.
+
+ If the processor is vulnerable but the availability of the microcode
+ based mitigation mechanism is not advertised via CPUID, the kernel
+ selects a best effort mitigation mode. This mode invokes the mitigation
+ instructions without a guarantee that they clear the CPU buffers.
+
+ This is done to address virtualization scenarios where the host has the
+ microcode update applied, but the hypervisor is not yet updated to
+ expose the CPUID to the guest. If the host has updated microcode the
+ protection takes effect; otherwise a few CPU cycles are wasted
+ pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
new file mode 100644
index 000000000000..ad15417d39f9
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
@@ -0,0 +1,96 @@
+==================================
+Register File Data Sampling (RFDS)
+==================================
+
+Register File Data Sampling (RFDS) is a microarchitectural vulnerability that
+only affects Intel Atom parts(also branded as E-cores). RFDS may allow
+a malicious actor to infer data values previously used in floating point
+registers, vector registers, or integer registers. RFDS does not provide the
+ability to choose which data is inferred. CVE-2023-28746 is assigned to RFDS.
+
+Affected Processors
+===================
+Below is the list of affected Intel processors [#f1]_:
+
+ =================== ============
+ Common name Family_Model
+ =================== ============
+ ATOM_GOLDMONT 06_5CH
+ ATOM_GOLDMONT_D 06_5FH
+ ATOM_GOLDMONT_PLUS 06_7AH
+ ATOM_TREMONT_D 06_86H
+ ATOM_TREMONT 06_96H
+ ALDERLAKE 06_97H
+ ALDERLAKE_L 06_9AH
+ ATOM_TREMONT_L 06_9CH
+ RAPTORLAKE 06_B7H
+ RAPTORLAKE_P 06_BAH
+ ATOM_GRACEMONT 06_BEH
+ RAPTORLAKE_S 06_BFH
+ =================== ============
+
+Mitigation
+==========
+Intel released a microcode update that enables software to clear sensitive
+information using the VERW instruction. Like MDS, RFDS deploys the same
+mitigation strategy to force the CPU to clear the affected buffers before an
+attacker can extract the secrets. This is achieved by using the otherwise
+unused and obsolete VERW instruction in combination with a microcode update.
+The microcode clears the affected CPU buffers when the VERW instruction is
+executed.
+
+Mitigation points
+-----------------
+VERW is executed by the kernel before returning to user space, and by KVM
+before VMentry. None of the affected cores support SMT, so VERW is not required
+at C-state transitions.
+
+New bits in IA32_ARCH_CAPABILITIES
+----------------------------------
+Newer processors and microcode update on existing affected processors added new
+bits to IA32_ARCH_CAPABILITIES MSR. These bits can be used to enumerate
+vulnerability and mitigation capability:
+
+- Bit 27 - RFDS_NO - When set, processor is not affected by RFDS.
+- Bit 28 - RFDS_CLEAR - When set, processor is affected by RFDS, and has the
+ microcode that clears the affected buffers on VERW execution.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+The kernel command line allows to control RFDS mitigation at boot time with the
+parameter "reg_file_data_sampling=". The valid arguments are:
+
+ ========== =================================================================
+ on If the CPU is vulnerable, enable mitigation; CPU buffer clearing
+ on exit to userspace and before entering a VM.
+ off Disables mitigation.
+ ========== =================================================================
+
+Mitigation default is selected by CONFIG_MITIGATION_RFDS.
+
+Mitigation status information
+-----------------------------
+The Linux kernel provides a sysfs interface to enumerate the current
+vulnerability status of the system: whether the system is vulnerable, and
+which mitigations are active. The relevant sysfs file is:
+
+ /sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling
+
+The possible values in this file are:
+
+ .. list-table::
+
+ * - 'Not affected'
+ - The processor is not vulnerable
+ * - 'Vulnerable'
+ - The processor is vulnerable, but no mitigation enabled
+ * - 'Vulnerable: No microcode'
+ - The processor is vulnerable but microcode is not updated.
+ * - 'Mitigation: Clear Register File'
+ - The processor is vulnerable and the CPU buffer clearing mitigation is
+ enabled.
+
+References
+----------
+.. [#f1] Affected Processors
+ https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
diff --git a/Documentation/admin-guide/hw-vuln/rsb.rst b/Documentation/admin-guide/hw-vuln/rsb.rst
new file mode 100644
index 000000000000..21dbf9cf25f8
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/rsb.rst
@@ -0,0 +1,268 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+RSB-related mitigations
+=======================
+
+.. warning::
+ Please keep this document up-to-date, otherwise you will be
+ volunteered to update it and convert it to a very long comment in
+ bugs.c!
+
+Since 2018 there have been many Spectre CVEs related to the Return Stack
+Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or
+Return Address Predictor (RAP) on AMD).
+
+Information about these CVEs and how to mitigate them is scattered
+amongst a myriad of microarchitecture-specific documents.
+
+This document attempts to consolidate all the relevant information in
+once place and clarify the reasoning behind the current RSB-related
+mitigations. It's meant to be as concise as possible, focused only on
+the current kernel mitigations: what are the RSB-related attack vectors
+and how are they currently being mitigated?
+
+It's *not* meant to describe how the RSB mechanism operates or how the
+exploits work. More details about those can be found in the references
+below.
+
+Rather, this is basically a glorified comment, but too long to actually
+be one. So when the next CVE comes along, a kernel developer can
+quickly refer to this as a refresher to see what we're actually doing
+and why.
+
+At a high level, there are two classes of RSB attacks: RSB poisoning
+(Intel and AMD) and RSB underflow (Intel only). They must each be
+considered individually for each attack vector (and microarchitecture
+where applicable).
+
+----
+
+RSB poisoning (Intel and AMD)
+=============================
+
+SpectreRSB
+~~~~~~~~~~
+
+RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where
+an attacker poisons an RSB entry to cause a victim's return instruction
+to speculate to an attacker-controlled address. This can happen when
+there are unbalanced CALLs/RETs after a context switch or VMEXIT.
+
+* All attack vectors can potentially be mitigated by flushing out any
+ poisoned RSB entries using an RSB filling sequence
+ [#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between
+ untrusted and trusted domains. But this has a performance impact and
+ should be avoided whenever possible.
+
+ .. DANGER::
+ **FIXME**: Currently we're flushing 32 entries. However, some CPU
+ models have more than 32 entries. The loop count needs to be
+ increased for those. More detailed information is needed about RSB
+ sizes.
+
+* On context switch, the user->user mitigation requires ensuring the
+ RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_
+ during a context switch:
+
+ * AMD:
+ On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.
+ This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.
+
+ On Zen < 4, the RSB filling sequence [#amd-rsb-filling]_ must be
+ always be done in addition to IBPB [#amd-ibpb-no-rsb]_. This is
+ indicated by X86_BUG_IBPB_NO_RET.
+
+ * Intel:
+ IBPB always clears the RSB:
+
+ "Software that executed before the IBPB command cannot control
+ the predicted targets of indirect branches executed after the
+ command on the same logical processor. The term indirect branch
+ in this context includes near return instructions, so these
+ predicted targets may come from the RSB." [#intel-ibpb-rsb]_
+
+* On context switch, user->kernel attacks are prevented by SMEP. User
+ space can only insert user space addresses into the RSB. Even
+ non-canonical addresses can't be inserted due to the page gap at the
+ end of the user canonical address space reserved by TASK_SIZE_MAX.
+ A SMEP #PF at instruction fetch prevents the kernel from speculatively
+ executing user space.
+
+ * AMD:
+ "Finally, branches that are predicted as 'ret' instructions get
+ their predicted targets from the Return Address Predictor (RAP).
+ AMD recommends software use a RAP stuffing sequence (mitigation
+ V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP)
+ to ensure that the addresses in the RAP are safe for
+ speculation. Collectively, we refer to these mitigations as "RAP
+ Protection"." [#amd-smep-rsb]_
+
+ * Intel:
+ "On processors with enhanced IBRS, an RSB overwrite sequence may
+ not suffice to prevent the predicted target of a near return
+ from using an RSB entry created in a less privileged predictor
+ mode. Software can prevent this by enabling SMEP (for
+ transitions from user mode to supervisor mode) and by having
+ IA32_SPEC_CTRL.IBRS set during VM exits." [#intel-smep-rsb]_
+
+* On VMEXIT, guest->host attacks are mitigated by eIBRS (and PBRSB
+ mitigation if needed):
+
+ * AMD:
+ "When Automatic IBRS is enabled, the internal return address
+ stack used for return address predictions is cleared on VMEXIT."
+ [#amd-eibrs-vmexit]_
+
+ * Intel:
+ "On processors with enhanced IBRS, an RSB overwrite sequence may
+ not suffice to prevent the predicted target of a near return
+ from using an RSB entry created in a less privileged predictor
+ mode. Software can prevent this by enabling SMEP (for
+ transitions from user mode to supervisor mode) and by having
+ IA32_SPEC_CTRL.IBRS set during VM exits. Processors with
+ enhanced IBRS still support the usage model where IBRS is set
+ only in the OS/VMM for OSes that enable SMEP. To do this, such
+ processors will ensure that guest behavior cannot control the
+ RSB after a VM exit once IBRS is set, even if IBRS was not set
+ at the time of the VM exit." [#intel-eibrs-vmexit]_
+
+ Note that some Intel CPUs are susceptible to Post-barrier Return
+ Stack Buffer Predictions (PBRSB) [#intel-pbrsb]_, where the last
+ CALL from the guest can be used to predict the first unbalanced RET.
+ In this case the PBRSB mitigation is needed in addition to eIBRS.
+
+AMD RETBleed / SRSO / Branch Type Confusion
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On AMD, poisoned RSB entries can also be created by the AMD RETBleed
+variant [#retbleed-paper]_ [#amd-btc]_ or by Speculative Return Stack
+Overflow [#amd-srso]_ (Inception [#inception-paper]_). The kernel
+protects itself by replacing every RET in the kernel with a branch to a
+single safe RET.
+
+----
+
+RSB underflow (Intel only)
+==========================
+
+RSB Alternate (RSBA) ("Intel Retbleed")
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some Intel Skylake-generation CPUs are susceptible to the Intel variant
+of RETBleed [#retbleed-paper]_ (Return Stack Buffer Underflow
+[#intel-rsbu]_). If a RET is executed when the RSB buffer is empty due
+to mismatched CALLs/RETs or returning from a deep call stack, the branch
+predictor can fall back to using the Branch Target Buffer (BTB). If a
+user forces a BTB collision then the RET can speculatively branch to a
+user-controlled address.
+
+* Note that RSB filling doesn't fully mitigate this issue. If there
+ are enough unbalanced RETs, the RSB may still underflow and fall back
+ to using a poisoned BTB entry.
+
+* On context switch, user->user underflow attacks are mitigated by the
+ conditional IBPB [#cond-ibpb]_ on context switch which effectively
+ clears the BTB:
+
+ * "The indirect branch predictor barrier (IBPB) is an indirect branch
+ control mechanism that establishes a barrier, preventing software
+ that executed before the barrier from controlling the predicted
+ targets of indirect branches executed after the barrier on the same
+ logical processor." [#intel-ibpb-btb]_
+
+* On context switch and VMEXIT, user->kernel and guest->host RSB
+ underflows are mitigated by IBRS or eIBRS:
+
+ * "Enabling IBRS (including enhanced IBRS) will mitigate the "RSBU"
+ attack demonstrated by the researchers. As previously documented,
+ Intel recommends the use of enhanced IBRS, where supported. This
+ includes any processor that enumerates RRSBA but not RRSBA_DIS_S."
+ [#intel-rsbu]_
+
+ However, note that eIBRS and IBRS do not mitigate intra-mode attacks.
+ Like RRSBA below, this is mitigated by clearing the BHB on kernel
+ entry.
+
+ As an alternative to classic IBRS, call depth tracking (combined with
+ retpolines) can be used to track kernel returns and fill the RSB when
+ it gets close to being empty.
+
+Restricted RSB Alternate (RRSBA)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some newer Intel CPUs have Restricted RSB Alternate (RRSBA) behavior,
+which, similar to RSBA described above, also falls back to using the BTB
+on RSB underflow. The only difference is that the predicted targets are
+restricted to the current domain when eIBRS is enabled:
+
+* "Restricted RSB Alternate (RRSBA) behavior allows alternate branch
+ predictors to be used by near RET instructions when the RSB is
+ empty. When eIBRS is enabled, the predicted targets of these
+ alternate predictors are restricted to those belonging to the
+ indirect branch predictor entries of the current prediction domain.
+ [#intel-eibrs-rrsba]_
+
+When a CPU with RRSBA is vulnerable to Branch History Injection
+[#bhi-paper]_ [#intel-bhi]_, an RSB underflow could be used for an
+intra-mode BTI attack. This is mitigated by clearing the BHB on
+kernel entry.
+
+However if the kernel uses retpolines instead of eIBRS, it needs to
+disable RRSBA:
+
+* "Where software is using retpoline as a mitigation for BHI or
+ intra-mode BTI, and the processor both enumerates RRSBA and
+ enumerates RRSBA_DIS controls, it should disable this behavior."
+ [#intel-retpoline-rrsba]_
+
+----
+
+References
+==========
+
+.. [#spectre-rsb] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://arxiv.org/pdf/1807.07940.pdf>`_
+
+.. [#intel-rsb-filling] "Empty RSB Mitigation on Skylake-generation" in `Retpoline: A Branch Target Injection Mitigation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html#inpage-nav-5-1>`_
+
+.. [#amd-rsb-filling] "Mitigation V2-3" in `Software Techniques for Managing Speculation <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf>`_
+
+.. [#cond-ibpb] Whether IBPB is written depends on whether the prev and/or next task is protected from Spectre attacks. It typically requires opting in per task or system-wide. For more details see the documentation for the ``spectre_v2_user`` cmdline option in Documentation/admin-guide/kernel-parameters.txt.
+
+.. [#amd-sbpb] IBPB without flushing of branch type predictions. Only exists for AMD.
+
+.. [#amd-ibpb-rsb] "Function 8000_0008h -- Processor Capacity Parameters and Extended Feature Identification" in `AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf>`_. SBPB behaves the same way according to `this email <https://lore.kernel.org/5175b163a3736ca5fd01cedf406735636c99a>`_.
+
+.. [#amd-ibpb-no-rsb] `Spectre Attacks: Exploiting Speculative Execution <https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf>`_
+
+.. [#intel-ibpb-rsb] "Introduction" in `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
+
+.. [#amd-smep-rsb] "Existing Mitigations" in `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
+
+.. [#intel-smep-rsb] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
+
+.. [#amd-eibrs-vmexit] "Extended Feature Enable Register (EFER)" in `AMD64 Architecture Programmer's Manual Volume 2: System Programming <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf>`_
+
+.. [#intel-eibrs-vmexit] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
+
+.. [#intel-pbrsb] `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
+
+.. [#retbleed-paper] `RETBleed: Arbitrary Speculative Code Execution with Return Instruction <https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf>`_
+
+.. [#amd-btc] `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
+
+.. [#amd-srso] `Technical Update Regarding Speculative Return Stack Overflow <https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf>`_
+
+.. [#inception-paper] `Inception: Exposing New Attack Surfaces with Training in Transient Execution <https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf>`_
+
+.. [#intel-rsbu] `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
+
+.. [#intel-ibpb-btb] `Indirect Branch Predictor Barrier' <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-predictor-barrier.html>`_
+
+.. [#intel-eibrs-rrsba] "Guidance for RSBU" in `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
+
+.. [#bhi-paper] `Branch History Injection: On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks <http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf>`_
+
+.. [#intel-bhi] `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
+
+.. [#intel-retpoline-rrsba] "Retpoline" in `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
index c4dcdb3d0d45..4bb8549bee82 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -138,11 +138,10 @@ associated with the source address of the indirect branch. Specifically,
the BHB might be shared across privilege levels even in the presence of
Enhanced IBRS.
-Currently the only known real-world BHB attack vector is via
-unprivileged eBPF. Therefore, it's highly recommended to not enable
-unprivileged eBPF, especially when eIBRS is used (without retpolines).
-For a full mitigation against BHB attacks, it's recommended to use
-retpolines (or eIBRS combined with retpolines).
+Previously the only known real-world BHB attack vector was via unprivileged
+eBPF. Further research has found attacks that don't require unprivileged eBPF.
+For a full mitigation against BHB attacks it is recommended to set BHI_DIS_S or
+use the BHB clearing sequence.
Attack scenarios
----------------
@@ -407,7 +406,7 @@ The possible values in this file are:
- Single threaded indirect branch prediction (STIBP) status for protection
between different hyper threads. This feature can be controlled through
- prctl per process, or through kernel command line options. This is x86
+ prctl per process, or through kernel command line options. This is an x86
only feature. For more details see below.
==================== ========================================================
@@ -430,6 +429,23 @@ The possible values in this file are:
'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB
=========================== =======================================================
+ - Branch History Injection (BHI) protection status:
+
+.. list-table::
+
+ * - BHI: Not affected
+ - System is not affected
+ * - BHI: Retpoline
+ - System is protected by retpoline
+ * - BHI: BHI_DIS_S
+ - System is protected by BHI_DIS_S
+ * - BHI: SW loop, KVM SW loop
+ - System is protected by software clearing sequence
+ * - BHI: Vulnerable
+ - System is vulnerable to BHI
+ * - BHI: Vulnerable, KVM: SW loop
+ - System is vulnerable; KVM is protected by software clearing sequence
+
Full mitigation might require a microcode update from the CPU
vendor. When the necessary microcode is not available, the kernel will
report vulnerability.
@@ -473,14 +489,29 @@ Spectre variant 2
-mindirect-branch=thunk-extern -mindirect-branch-register options.
If the kernel is compiled with a Clang compiler, the compiler needs
to support -mretpoline-external-thunk option. The kernel config
- CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
- the latest updated microcode.
+ CONFIG_MITIGATION_RETPOLINE needs to be turned on, and the CPU needs
+ to run with the latest updated microcode.
On Intel Skylake-era systems the mitigation covers most, but not all,
cases. See :ref:`[3] <spec_ref3>` for more details.
- On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
- IBRS on x86), retpoline is automatically disabled at run time.
+ On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS
+ or enhanced IBRS on x86), retpoline is automatically disabled at run time.
+
+ Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at
+ boot, by setting the IBRS bit, and they're automatically protected against
+ some Spectre v2 variant attacks. The BHB can still influence the choice of
+ indirect branch predictor entry, and although branch predictor entries are
+ isolated between modes when eIBRS is enabled, the BHB itself is not isolated
+ between modes. Systems which support BHI_DIS_S will set it to protect against
+ BHI attacks.
+
+ On Intel's enhanced IBRS systems, this includes cross-thread branch target
+ injections on SMT systems (STIBP). In other words, Intel eIBRS enables
+ STIBP, too.
+
+ AMD Automatic IBRS does not protect userspace, and Legacy IBRS systems clear
+ the IBRS bit on exit to userspace, therefore both explicitly enable STIBP.
The retpoline mitigation is turned on by default on vulnerable
CPUs. It can be forced on or off by the administrator
@@ -504,9 +535,12 @@ Spectre variant 2
For Spectre variant 2 mitigation, individual user programs
can be compiled with return trampolines for indirect branches.
This protects them from consuming poisoned entries in the branch
- target buffer left by malicious software. Alternatively, the
- programs can disable their indirect branch speculation via prctl()
- (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
+ target buffer left by malicious software.
+
+ On legacy IBRS systems, at return to userspace, implicit STIBP is disabled
+ because the kernel clears the IBRS bit. In this case, the userspace programs
+ can disable indirect branch speculation via prctl() (See
+ :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
On x86, this will turn on STIBP to guard against attacks from the
sibling thread when the user program is running, and use IBPB to
flush the branch target buffer when switching to/from the program.
@@ -558,73 +592,19 @@ Spectre variant 2
Mitigation control on the kernel command line
---------------------------------------------
-Spectre variant 2 mitigation can be disabled or force enabled at the
-kernel command line.
-
- nospectre_v1
-
- [X86,PPC] Disable mitigations for Spectre Variant 1
- (bounds check bypass). With this option data leaks are
- possible in the system.
-
- nospectre_v2
-
- [X86] Disable all mitigations for the Spectre variant 2
- (indirect branch prediction) vulnerability. System may
- allow data leaks with this option, which is equivalent
- to spectre_v2=off.
-
-
- spectre_v2=
-
- [X86] Control mitigation of Spectre variant 2
- (indirect branch speculation) vulnerability.
- The default operation protects the kernel from
- user space attacks.
-
- on
- unconditionally enable, implies
- spectre_v2_user=on
- off
- unconditionally disable, implies
- spectre_v2_user=off
- auto
- kernel detects whether your CPU model is
- vulnerable
-
- Selecting 'on' will, and 'auto' may, choose a
- mitigation method at run time according to the
- CPU, the available microcode, the setting of the
- CONFIG_RETPOLINE configuration option, and the
- compiler with which the kernel was built.
-
- Selecting 'on' will also enable the mitigation
- against user space to user space task attacks.
-
- Selecting 'off' will disable both the kernel and
- the user space protections.
-
- Specific mitigations can also be selected manually:
-
- retpoline auto pick between generic,lfence
- retpoline,generic Retpolines
- retpoline,lfence LFENCE; indirect branch
- retpoline,amd alias for retpoline,lfence
- eibrs enhanced IBRS
- eibrs,retpoline enhanced IBRS + Retpolines
- eibrs,lfence enhanced IBRS + LFENCE
- ibrs use IBRS to protect kernel
+In general the kernel selects reasonable default mitigations for the
+current CPU.
- Not specifying this option is equivalent to
- spectre_v2=auto.
+Spectre default mitigations can be disabled or changed at the kernel
+command line with the following options:
- In general the kernel by default selects
- reasonable mitigations for the current CPU. To
- disable Spectre variant 2 mitigations, boot with
- spectre_v2=off. Spectre variant 1 mitigations
- cannot be disabled.
+ - nospectre_v1
+ - nospectre_v2
+ - spectre_v2={option}
+ - spectre_v2_user={option}
+ - spectre_bhi={option}
-For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt
+For more details on the available options, refer to Documentation/admin-guide/kernel-parameters.txt
Mitigation selection guide
--------------------------
@@ -684,7 +664,7 @@ Intel white papers:
.. _spec_ref1:
-[1] `Intel analysis of speculative execution side channels <https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf>`_.
+[1] `Intel analysis of speculative execution side channels <https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/analysis-of-speculative-execution-side-channels-white-paper.pdf>`_.
.. _spec_ref2:
@@ -702,7 +682,7 @@ AMD white papers:
.. _spec_ref5:
-[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.
+[5] `AMD64 technology indirect branch control extension <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/111006-architecture-guidelines-update-amd64-technology-indirect-branch-control-extension.pdf>`_.
.. _spec_ref6:
@@ -728,7 +708,7 @@ MIPS white paper:
.. _spec_ref10:
-[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
+[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://web.archive.org/web/20220512003005if_/https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
Academic papers:
diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst
new file mode 100644
index 000000000000..66af95251a3d
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/srso.rst
@@ -0,0 +1,242 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Speculative Return Stack Overflow (SRSO)
+========================================
+
+This is a mitigation for the speculative return stack overflow (SRSO)
+vulnerability found on AMD processors. The mechanism is by now the well
+known scenario of poisoning CPU functional units - the Branch Target
+Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
+tricking the elevated privilege domain (the kernel) into leaking
+sensitive data.
+
+AMD CPUs predict RET instructions using a Return Address Predictor (aka
+Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
+CALL instruction (i.e., an instruction predicted to be a CALL but is
+not actually a CALL) can create an entry in the RAP which may be used
+to predict the target of a subsequent RET instruction.
+
+The specific circumstances that lead to this varies by microarchitecture
+but the concern is that an attacker can mis-train the CPU BTB to predict
+non-architectural CALL instructions in kernel space and use this to
+control the speculative target of a subsequent kernel RET, potentially
+leading to information disclosure via a speculative side-channel.
+
+The issue is tracked under CVE-2023-20569.
+
+Affected processors
+-------------------
+
+AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
+processors have not been investigated.
+
+System information and options
+------------------------------
+
+First of all, it is required that the latest microcode be loaded for
+mitigations to be effective.
+
+The sysfs file showing SRSO mitigation status is:
+
+ /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
+
+The possible values in this file are:
+
+ * 'Not affected':
+
+ The processor is not vulnerable
+
+* 'Vulnerable':
+
+ The processor is vulnerable and no mitigations have been applied.
+
+ * 'Vulnerable: No microcode':
+
+ The processor is vulnerable, no microcode extending IBPB
+ functionality to address the vulnerability has been applied.
+
+ * 'Vulnerable: Safe RET, no microcode':
+
+ The "Safe RET" mitigation (see below) has been applied to protect the
+ kernel, but the IBPB-extending microcode has not been applied. User
+ space tasks may still be vulnerable.
+
+ * 'Vulnerable: Microcode, no safe RET':
+
+ Extended IBPB functionality microcode patch has been applied. It does
+ not address User->Kernel and Guest->Host transitions protection but it
+ does address User->User and VM->VM attack vectors.
+
+ Note that User->User mitigation is controlled by how the IBPB aspect in
+ the Spectre v2 mitigation is selected:
+
+ * conditional IBPB:
+
+ where each process can select whether it needs an IBPB issued
+ around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`
+
+ * strict:
+
+ i.e., always on - by supplying spectre_v2_user=on on the kernel
+ command line
+
+ (spec_rstack_overflow=microcode)
+
+ * 'Mitigation: Safe RET':
+
+ Combined microcode/software mitigation. It complements the
+ extended IBPB microcode patch functionality by addressing
+ User->Kernel and Guest->Host transitions protection.
+
+ Selected by default or by spec_rstack_overflow=safe-ret
+
+ * 'Mitigation: IBPB':
+
+ Similar protection as "safe RET" above but employs an IBPB barrier on
+ privilege domain crossings (User->Kernel, Guest->Host).
+
+ (spec_rstack_overflow=ibpb)
+
+ * 'Mitigation: IBPB on VMEXIT':
+
+ Mitigation addressing the cloud provider scenario - the Guest->Host
+ transitions only.
+
+ (spec_rstack_overflow=ibpb-vmexit)
+
+ * 'Mitigation: Reduced Speculation':
+
+ This mitigation gets automatically enabled when the above one "IBPB on
+ VMEXIT" has been selected and the CPU supports the BpSpecReduce bit.
+
+ It gets automatically enabled on machines which have the
+ SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch
+ to the above =ibpb-vmexit mitigation because the user/kernel boundary is
+ not affected anymore and thus "safe RET" is not needed.
+
+ After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit
+ is detected (functionality present on all such machines) and that
+ practically overrides IBPB on VMEXIT as it has a lot less performance
+ impact and takes care of the guest->host attack vector too.
+
+In order to exploit vulnerability, an attacker needs to:
+
+ - gain local access on the machine
+
+ - break kASLR
+
+ - find gadgets in the running kernel in order to use them in the exploit
+
+ - potentially create and pin an additional workload on the sibling
+ thread, depending on the microarchitecture (not necessary on fam 0x19)
+
+ - run the exploit
+
+Considering the performance implications of each mitigation type, the
+default one is 'Mitigation: safe RET' which should take care of most
+attack vectors, including the local User->Kernel one.
+
+As always, the user is advised to keep her/his system up-to-date by
+applying software updates regularly.
+
+The default setting will be reevaluated when needed and especially when
+new attack vectors appear.
+
+As one can surmise, 'Mitigation: safe RET' does come at the cost of some
+performance depending on the workload. If one trusts her/his userspace
+and does not want to suffer the performance impact, one can always
+disable the mitigation with spec_rstack_overflow=off.
+
+Similarly, 'Mitigation: IBPB' is another full mitigation type employing
+an indirect branch prediction barrier after having applied the required
+microcode patch for one's system. This mitigation comes also at
+a performance cost.
+
+Mitigation: Safe RET
+--------------------
+
+The mitigation works by ensuring all RET instructions speculate to
+a controlled location, similar to how speculation is controlled in the
+retpoline sequence. To accomplish this, the __x86_return_thunk forces
+the CPU to mispredict every function return using a 'safe return'
+sequence.
+
+To ensure the safety of this mitigation, the kernel must ensure that the
+safe return sequence is itself free from attacker interference. In Zen3
+and Zen4, this is accomplished by creating a BTB alias between the
+untraining function srso_alias_untrain_ret() and the safe return
+function srso_alias_safe_ret() which results in evicting a potentially
+poisoned BTB entry and using that safe one for all function returns.
+
+In older Zen1 and Zen2, this is accomplished using a reinterpretation
+technique similar to Retbleed one: srso_untrain_ret() and
+srso_safe_ret().
+
+Checking the safe RET mitigation actually works
+-----------------------------------------------
+
+In case one wants to validate whether the SRSO safe RET mitigation works
+on a kernel, one could use two performance counters
+
+* PMC_0xc8 - Count of RET/RET lw retired
+* PMC_0xc9 - Count of RET/RET lw retired mispredicted
+
+and compare the number of RETs retired properly vs those retired
+mispredicted, in kernel mode. Another way of specifying those events
+is::
+
+ # perf list ex_ret_near_ret
+
+ List of pre-defined events (to be used in -e or -M):
+
+ core:
+ ex_ret_near_ret
+ [Retired Near Returns]
+ ex_ret_near_ret_mispred
+ [Retired Near Returns Mispredicted]
+
+Either the command using the event mnemonics::
+
+ # perf stat -e ex_ret_near_ret:k -e ex_ret_near_ret_mispred:k sleep 10s
+
+or using the raw PMC numbers::
+
+ # perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s
+
+should give the same amount. I.e., every RET retired should be
+mispredicted::
+
+ [root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s
+
+ Performance counter stats for 'sleep 10s':
+
+ 137,167 cpu/event=0xc8,umask=0/k
+ 137,173 cpu/event=0xc9,umask=0/k
+
+ 10.004110303 seconds time elapsed
+
+ 0.000000000 seconds user
+ 0.004462000 seconds sys
+
+vs the case when the mitigation is disabled (spec_rstack_overflow=off)
+or not functioning properly, showing usually a lot smaller number of
+mispredicted retired RETs vs the overall count of retired RETs during
+a workload::
+
+ [root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s
+
+ Performance counter stats for 'sleep 10s':
+
+ 201,627 cpu/event=0xc8,umask=0/k
+ 4,074 cpu/event=0xc9,umask=0/k
+
+ 10.003267252 seconds time elapsed
+
+ 0.002729000 seconds user
+ 0.000000000 seconds sys
+
+Also, there is a selftest which performs the above, go to
+tools/testing/selftests/x86/ and do::
+
+ make srso
+ ./srso
diff --git a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
index 76673affd917..444f84e22a91 100644
--- a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
+++ b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
@@ -63,7 +63,7 @@ attacker needs to begin a TSX transaction and raise an asynchronous abort
which in turn potentially leaks data stored in the buffers.
More detailed technical information is available in the TAA specific x86
-architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
+architecture section: :ref:`Documentation/arch/x86/tsx_async_abort.rst <tsx_async_abort>`.
Attack scenarios
@@ -98,7 +98,19 @@ The possible values in this file are:
* - 'Vulnerable'
- The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied.
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- - The system tries to clear the buffers but the microcode might not support the operation.
+ - The processor is vulnerable but microcode is not updated. The
+ mitigation is enabled on a best effort basis.
+
+ If the processor is vulnerable but the availability of the microcode
+ based mitigation mechanism is not advertised via CPUID, the kernel
+ selects a best effort mitigation mode. This mode invokes the mitigation
+ instructions without a guarantee that they clear the CPU buffers.
+
+ This is done to address virtualization scenarios where the host has the
+ microcode update applied, but the hypervisor is not yet updated to
+ expose the CPUID to the guest. If the host has updated microcode the
+ protection takes effect; otherwise a few CPU cycles are wasted
+ pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The microcode has been updated to clear the buffers. TSX is still enabled.
* - 'Mitigation: TSX disabled'
@@ -106,25 +118,6 @@ The possible values in this file are:
* - 'Not affected'
- The CPU is not affected by this issue.
-.. _ucode_needed:
-
-Best effort mitigation mode
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If the processor is vulnerable, but the availability of the microcode-based
-mitigation mechanism is not advertised via CPUID the kernel selects a best
-effort mitigation mode. This mode invokes the mitigation instructions
-without a guarantee that they clear the CPU buffers.
-
-This is done to address virtualization scenarios where the host has the
-microcode update applied, but the hypervisor is not yet updated to expose the
-CPUID to the guest. If the host has updated microcode the protection takes
-effect; otherwise a few CPU cycles are wasted pointlessly.
-
-The state in the tsx_async_abort sysfs file reflects this situation
-accordingly.
-
-
Mitigation mechanism
--------------------
diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst b/Documentation/admin-guide/hw-vuln/vmscape.rst
new file mode 100644
index 000000000000..d9b9a2b6c114
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/vmscape.rst
@@ -0,0 +1,110 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+VMSCAPE
+=======
+
+VMSCAPE is a vulnerability that may allow a guest to influence the branch
+prediction in host userspace. It particularly affects hypervisors like QEMU.
+
+Even if a hypervisor may not have any sensitive data like disk encryption keys,
+guest-userspace may be able to attack the guest-kernel using the hypervisor as
+a confused deputy.
+
+Affected processors
+-------------------
+
+The following CPU families are affected by VMSCAPE:
+
+**Intel processors:**
+ - Skylake generation (Parts without Enhanced-IBRS)
+ - Cascade Lake generation - (Parts affected by ITS guest/host separation)
+ - Alder Lake and newer (Parts affected by BHI)
+
+Note that, BHI affected parts that use BHB clearing software mitigation e.g.
+Icelake are not vulnerable to VMSCAPE.
+
+**AMD processors:**
+ - Zen series (families 0x17, 0x19, 0x1a)
+
+** Hygon processors:**
+ - Family 0x18
+
+Mitigation
+----------
+
+Conditional IBPB
+----------------
+
+Kernel tracks when a CPU has run a potentially malicious guest and issues an
+IBPB before the first exit to userspace after VM-exit. If userspace did not run
+between VM-exit and the next VM-entry, no IBPB is issued.
+
+Note that the existing userspace mitigation against Spectre-v2 is effective in
+protecting the userspace. They are insufficient to protect the userspace VMMs
+from a malicious guest. This is because Spectre-v2 mitigations are applied at
+context switch time, while the userspace VMM can run after a VM-exit without a
+context switch.
+
+Vulnerability enumeration and mitigation is not applied inside a guest. This is
+because nested hypervisors should already be deploying IBPB to isolate
+themselves from nested guests.
+
+SMT considerations
+------------------
+
+When Simultaneous Multi-Threading (SMT) is enabled, hypervisors can be
+vulnerable to cross-thread attacks. For complete protection against VMSCAPE
+attacks in SMT environments, STIBP should be enabled.
+
+The kernel will issue a warning if SMT is enabled without adequate STIBP
+protection. Warning is not issued when:
+
+- SMT is disabled
+- STIBP is enabled system-wide
+- Intel eIBRS is enabled (which implies STIBP protection)
+
+System information and options
+------------------------------
+
+The sysfs file showing VMSCAPE mitigation status is:
+
+ /sys/devices/system/cpu/vulnerabilities/vmscape
+
+The possible values in this file are:
+
+ * 'Not affected':
+
+ The processor is not vulnerable to VMSCAPE attacks.
+
+ * 'Vulnerable':
+
+ The processor is vulnerable and no mitigation has been applied.
+
+ * 'Mitigation: IBPB before exit to userspace':
+
+ Conditional IBPB mitigation is enabled. The kernel tracks when a CPU has
+ run a potentially malicious guest and issues an IBPB before the first
+ exit to userspace after VM-exit.
+
+ * 'Mitigation: IBPB on VMEXIT':
+
+ IBPB is issued on every VM-exit. This occurs when other mitigations like
+ RETBLEED or SRSO are already issuing IBPB on VM-exit.
+
+Mitigation control on the kernel command line
+----------------------------------------------
+
+The mitigation can be controlled via the ``vmscape=`` command line parameter:
+
+ * ``vmscape=off``:
+
+ Disable the VMSCAPE mitigation.
+
+ * ``vmscape=ibpb``:
+
+ Enable conditional IBPB mitigation (default when CONFIG_MITIGATION_VMSCAPE=y).
+
+ * ``vmscape=force``:
+
+ Force vulnerability detection and mitigation even on processors that are
+ not known to be affected.
diff --git a/Documentation/admin-guide/hw_random.rst b/Documentation/admin-guide/hw_random.rst
index 121de96e395e..bfc39f1cf470 100644
--- a/Documentation/admin-guide/hw_random.rst
+++ b/Documentation/admin-guide/hw_random.rst
@@ -1,6 +1,6 @@
-==========================================================
-Linux support for random number generator in i8xx chipsets
-==========================================================
+=================================
+Hardware random number generators
+=================================
Introduction
============
@@ -14,10 +14,9 @@ into that core.
To make the most effective use of these mechanisms, you
should download the support software as well. Download the
-latest version of the "rng-tools" package from the
-hw_random driver's official Web site:
+latest version of the "rng-tools" package from:
- http://sourceforge.net/projects/gkernel/
+ https://github.com/nhorman/rng-tools
Those tools use /dev/hwrng to fill the kernel entropy pool,
which is used internally and exported by the /dev/urandom and
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 5bfafcbb9562..259d79fbeb94 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -1,3 +1,4 @@
+=================================================
The Linux kernel user's and administrator's guide
=================================================
@@ -6,6 +7,9 @@ added to the kernel over time. There is, as yet, little overall order or
organization here — this material was not written to be a single, coherent
document! With luck things will improve quickly over time.
+General guides to kernel administration
+---------------------------------------
+
This initial section contains overall information, including the README
file describing the kernel as a whole, documentation on kernel parameters,
etc.
@@ -14,19 +18,44 @@ etc.
:maxdepth: 1
README
- kernel-parameters
devices
- sysctl/index
- abi
features
-This section describes CPU vulnerabilities and their mitigations.
+A big part of the kernel's administrative interface is the /proc and sysfs
+virtual filesystems; these documents describe how to interact with tem
+
+.. toctree::
+ :maxdepth: 1
+
+ sysfs-rules
+ sysctl/index
+ cputopology
+ abi
+
+Security-related documentation:
.. toctree::
:maxdepth: 1
hw-vuln/index
+ LSM/index
+ perf-security
+
+Booting the kernel
+------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ bootconfig
+ kernel-parameters
+ efi-stub
+ initrd
+
+
+Tracking down and identifying problems
+--------------------------------------
Here is a set of documents aimed at users who are trying to track down
problems and bugs in particular.
@@ -36,7 +65,8 @@ problems and bugs in particular.
reporting-issues
reporting-regressions
- security-bugs
+ quickly-build-trimmed-linux
+ verify-bugs-and-bisect-regressions
bug-hunting
bug-bisect
tainted-kernels
@@ -46,82 +76,119 @@ problems and bugs in particular.
kdump/index
perf/index
pstore-blk
+ clearing-warn-once
+ kernel-per-CPU-kthreads
+ lockup-watchdogs
+ RAS/index
+ sysrq
-This is the beginning of a section with information of interest to
-application developers. Documents covering various aspects of the kernel
-ABI will be found here.
+
+Core-kernel subsystems
+----------------------
+
+These documents describe core-kernel administration interfaces that are
+likely to be of interest on almost any system.
.. toctree::
:maxdepth: 1
- sysfs-rules
+ cgroup-v2
+ cgroup-v1/index
+ cpu-load
+ mm/index
+ module-signing
+ namespaces/index
+ numastat
+ pm/index
+ syscall-user-dispatch
-The rest of this manual consists of various unordered guides on how to
-configure specific aspects of kernel behavior to your liking.
+Support for non-native binary formats. Note that some of these
+documents are ... old ...
+
+.. toctree::
+ :maxdepth: 1
+
+ binfmt-misc
+ java
+ mono
+
+
+Block-layer and filesystem administration
+-----------------------------------------
.. toctree::
:maxdepth: 1
- acpi/index
- aoe/index
- auxdisplay/index
bcache
binderfs
- binfmt-misc
blockdev/index
- bootconfig
- braille-console
- btmrvl
- cgroup-v1/index
- cgroup-v2
cifs/index
- clearing-warn-once
- cpu-load
- cputopology
- dell_rbu
device-mapper/index
- edid
- efi-stub
ext4
filesystem-monitoring
nfs/index
- gpio/index
- highuid
- hw_random
- initrd
iostats
- java
jfs
- kernel-per-CPU-kthreads
+ md
+ ufs
+ xfs
+
+Device-specific guides
+----------------------
+
+How to configure your hardware within your Linux system.
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi/index
+ aoe/index
+ auxdisplay/index
+ braille-console
+ btmrvl
+ dell_rbu
+ edid
+ gpio/index
+ hw_random
laptops/index
lcd-panel-cgram
- ldm
- lockup-watchdogs
- LSM/index
- md
media/index
- mm/index
- module-signing
- mono
- namespaces/index
- numastat
+ nvme-multipath
parport
- perf-security
- pm/index
pnp
rapidio
- ras
rtc
serial-console
svga
- syscall-user-dispatch
- sysrq
+ thermal/index
thunderbolt
- ufs
- unicode
vga-softcursor
video-output
- xfs
+
+Workload analysis
+-----------------
+
+This is the beginning of a section with information of interest to
+application developers and system integrators doing analysis of the
+Linux kernel for safety critical applications. Documents supporting
+analysis of kernel interactions with applications, and key kernel
+subsystems expectations will be found here.
+
+.. toctree::
+ :maxdepth: 1
+
+ workload-tracing
+
+Everything else
+---------------
+
+A few hard-to-categorize and generally obsolete documents.
+
+.. toctree::
+ :maxdepth: 1
+
+ ldm
+ unicode
.. only:: subproject and html
diff --git a/Documentation/admin-guide/iostats.rst b/Documentation/admin-guide/iostats.rst
index 609a3201fd4e..9453196ade51 100644
--- a/Documentation/admin-guide/iostats.rst
+++ b/Documentation/admin-guide/iostats.rst
@@ -2,62 +2,39 @@
I/O statistics fields
=====================
-Since 2.4.20 (and some versions before, with patches), and 2.5.45,
-more extensive disk statistics have been introduced to help measure disk
-activity. Tools such as ``sar`` and ``iostat`` typically interpret these and do
-the work for you, but in case you are interested in creating your own
-tools, the fields are explained here.
-
-In 2.4 now, the information is found as additional fields in
-``/proc/partitions``. In 2.6 and upper, the same information is found in two
-places: one is in the file ``/proc/diskstats``, and the other is within
-the sysfs file system, which must be mounted in order to obtain
-the information. Throughout this document we'll assume that sysfs
-is mounted on ``/sys``, although of course it may be mounted anywhere.
-Both ``/proc/diskstats`` and sysfs use the same source for the information
-and so should not differ.
-
-Here are examples of these different formats::
-
- 2.4:
- 3 0 39082680 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160
- 3 1 9221278 hda1 35486 0 35496 38030 0 0 0 0 0 38030 38030
-
- 2.6+ sysfs:
- 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160
- 35486 38030 38030 38030
-
- 2.6+ diskstats:
- 3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160
- 3 1 hda1 35486 38030 38030 38030
-
- 4.18+ diskstats:
- 3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 0 0 0 0
-
-On 2.4 you might execute ``grep 'hda ' /proc/partitions``. On 2.6+, you have
-a choice of ``cat /sys/block/hda/stat`` or ``grep 'hda ' /proc/diskstats``.
-
-The advantage of one over the other is that the sysfs choice works well
-if you are watching a known, small set of disks. ``/proc/diskstats`` may
-be a better choice if you are watching a large number of disks because
-you'll avoid the overhead of 50, 100, or 500 or more opens/closes with
-each snapshot of your disk statistics.
-
-In 2.4, the statistics fields are those after the device name. In
-the above example, the first field of statistics would be 446216.
-By contrast, in 2.6+ if you look at ``/sys/block/hda/stat``, you'll
-find just the 15 fields, beginning with 446216. If you look at
-``/proc/diskstats``, the 15 fields will be preceded by the major and
-minor device numbers, and device name. Each of these formats provides
-15 fields of statistics, each meaning exactly the same things.
-All fields except field 9 are cumulative since boot. Field 9 should
-go to zero as I/Os complete; all others only increase (unless they
-overflow and wrap). Wrapping might eventually occur on a very busy
-or long-lived system; so applications should be prepared to deal with
-it. Regarding wrapping, the types of the fields are either unsigned
-int (32 bit) or unsigned long (32-bit or 64-bit, depending on your
-machine) as noted per-field below. Unless your observations are very
-spread in time, these fields should not wrap twice before you notice it.
+The kernel exposes disk statistics via ``/proc/diskstats`` and
+``/sys/block/<device>/stat``. These stats are usually accessed via tools
+such as ``sar`` and ``iostat``.
+
+Here are examples using a disk with two partitions::
+
+ /proc/diskstats:
+ 259 0 nvme0n1 255999 814 12369153 47919 996852 81 36123024 425995 0 301795 580470 0 0 0 0 60602 106555
+ 259 1 nvme0n1p1 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0
+ 259 2 nvme0n1p2 255401 1 12343477 47799 996004 0 36014736 425784 0 344336 473584 0 0 0 0 0 0
+
+ /sys/block/nvme0n1/stat:
+ 255999 814 12369153 47919 996858 81 36123056 426009 0 301809 580491 0 0 0 0 60605 106562
+
+ /sys/block/nvme0n1/nvme0n1p1/stat:
+ 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0
+
+Both files contain the same 17 statistics. ``/sys/block/<device>/stat``
+contains the fields for ``<device>``. In ``/proc/diskstats`` the fields
+are prefixed with the major and minor device numbers and the device
+name. In the example above, the first stat value for ``nvme0n1`` is
+255999 in both files.
+
+The sysfs ``stat`` file is efficient for monitoring a small, known set
+of disks. If you're tracking a large number of devices,
+``/proc/diskstats`` is often the better choice since it avoids the
+overhead of opening and closing multiple files for each snapshot.
+
+All fields are cumulative, monotonic counters, except for field 9, which
+resets to zero as I/Os complete. The remaining fields reset at boot, on
+device reattachment or reinitialization, or when the underlying counter
+overflows. Applications reading these counters should detect and handle
+resets when comparing stat snapshots.
Each set of stats only applies to the indicated device; if you want
system-wide stats you'll have to find all the devices and sum them all up.
diff --git a/Documentation/admin-guide/kdump/gdbmacros.txt b/Documentation/admin-guide/kdump/gdbmacros.txt
index 82aecdcae8a6..030de95e3e6b 100644
--- a/Documentation/admin-guide/kdump/gdbmacros.txt
+++ b/Documentation/admin-guide/kdump/gdbmacros.txt
@@ -312,10 +312,10 @@ define dmesg
set var $prev_flags = $info->flags
end
- set var $id = ($id + 1) & $id_mask
if ($id == $end_id)
loop_break
end
+ set var $id = ($id + 1) & $id_mask
end
end
document dmesg
diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
index a748e7eb4429..7b011eb116a7 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -17,7 +17,7 @@ You can use common commands, such as cp, scp or makedumpfile to copy
the memory image to a dump file on the local disk, or across the network
to a remote system.
-Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
+Kdump and kexec are currently supported on the x86, x86_64, ppc64,
s390x, arm and arm64 architectures.
When the system kernel boots, it reserves a small section of memory for
@@ -113,7 +113,7 @@ There are two possible methods of using Kdump.
2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
- of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
+ of today, i386, x86_64, ppc64, arm and arm64 architectures support
relocatable kernel.
Building a relocatable kernel is advantageous from the point of view that
@@ -136,10 +136,6 @@ System kernel config options
CONFIG_KEXEC_CORE=y
- Subsequently, CRASH_CORE is selected by KEXEC_CORE::
-
- CONFIG_CRASH_CORE=y
-
2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo
filesystems." This is usually enabled by default::
@@ -168,6 +164,10 @@ Dump-capture kernel config options (Arch Independent)
CONFIG_CRASH_DUMP=y
+ And this will select VMCORE_INFO and CRASH_RESERVE::
+ CONFIG_VMCORE_INFO=y
+ CONFIG_CRASH_RESERVE=y
+
2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems"::
CONFIG_PROC_VMCORE=y
@@ -180,10 +180,6 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
1) On i386, enable high memory support under "Processor type and
features"::
- CONFIG_HIGHMEM64G=y
-
- or::
-
CONFIG_HIGHMEM4G
2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel
@@ -191,9 +187,7 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
CPU is enough for kdump kernel to dump vmcore on most of systems.
However, you can also specify nr_cpus=X to enable multiple processors
- in kdump kernel. In this case, "disable_cpu_apicid=" is needed to
- tell kdump kernel which cpu is 1st kernel's BSP. Please refer to
- admin-guide/kernel-parameters.txt for more details.
+ in kdump kernel.
With CONFIG_SMP=n, the above things are not related.
@@ -236,24 +230,6 @@ Dump-capture kernel config options (Arch Dependent, ppc64)
Make and install the kernel and its modules.
-Dump-capture kernel config options (Arch Dependent, ia64)
-----------------------------------------------------------
-
-- No specific options are required to create a dump-capture kernel
- for ia64, other than those specified in the arch independent section
- above. This means that it is possible to use the system kernel
- as a dump-capture kernel if desired.
-
- The crashkernel region can be automatically placed by the system
- kernel at runtime. This is done by specifying the base address as 0,
- or omitting it all together::
-
- crashkernel=256M@0
-
- or::
-
- crashkernel=256M
-
Dump-capture kernel config options (Arch Dependent, arm)
----------------------------------------------------------
@@ -335,6 +311,27 @@ crashkernel syntax
crashkernel=0,low
+4) crashkernel=size,cma
+
+ Reserve additional crash kernel memory from CMA. This reservation is
+ usable by the first system's userspace memory and kernel movable
+ allocations (memory balloon, zswap). Pages allocated from this memory
+ range will not be included in the vmcore so this should not be used if
+ dumping of userspace memory is intended and it has to be expected that
+ some movable kernel pages may be missing from the dump.
+
+ A standard crashkernel reservation, as described above, is still needed
+ to hold the crash kernel and initrd.
+
+ This option increases the risk of a kdump failure: DMA transfers
+ configured by the first kernel may end up corrupting the second
+ kernel's memory.
+
+ This reservation method is intended for systems that can't afford to
+ sacrifice enough memory for standard crashkernel reservation and where
+ less reliable and possibly incomplete kdump is preferable to no kdump at
+ all.
+
Boot into System Kernel
-----------------------
1) Update the boot loader (such as grub, yaboot, or lilo) configuration
@@ -348,11 +345,6 @@ Boot into System Kernel
On ppc64, use "crashkernel=128M@32M".
- On ia64, 256M@256M is a generous value that typically works.
- The region may be automatically placed on ia64, see the
- dump-capture kernel config option notes above.
- If use sparse memory, the size should be rounded to GRANULE boundaries.
-
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
dependent on the memory size of the production system.
@@ -383,10 +375,6 @@ For ppc64:
- Use vmlinux
-For ia64:
-
- - Use vmlinux or vmlinuz.gz
-
For s390x:
- Use image or bzImage
@@ -428,14 +416,10 @@ to load dump-capture kernel::
--initrd=<initrd-for-dump-capture-kernel> \
--append="root=<root-dev> <arch-specific-options>"
-Please note, that --args-linux does not need to be specified for ia64.
-It is planned to make this a no-op on that architecture, but for now
-it should be omitted
-
Following are the arch specific command line options to be used while
loading dump-capture kernel.
-For i386, x86_64 and ia64:
+For i386 and x86_64:
"1 irqpoll nr_cpus=1 reset_devices"
@@ -485,10 +469,9 @@ Notes on loading the dump-capture kernel:
to use multi-thread programs with it, such as parallel dump feature of
makedumpfile. Otherwise, the multi-thread program may have a great
performance degradation. To enable multi-cpu support, you should bring up an
- SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
- options while loading it.
+ SMP dump-capture kernel and specify maxcpus/nr_cpus options while loading it.
-* For s390x there are two kdump modes: If a ELF header is specified with
+* For s390x there are two kdump modes: If an ELF header is specified with
the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
is done on all other architectures. If no elfcorehdr= kernel parameter is
specified, the s390x kdump kernel dynamically creates the header. The
@@ -585,6 +568,38 @@ from within add_taint() whenever the value set in this bitmask matches with the
bit flag being set by add_taint().
This will cause a kdump to occur at the add_taint()->panic() call.
+Write the dump file to encrypted disk volume
+============================================
+
+CONFIG_CRASH_DM_CRYPT can be enabled to support saving the dump file to an
+encrypted disk volume (only x86_64 supported for now). User space can interact
+with /sys/kernel/config/crash_dm_crypt_keys for setup,
+
+1. Tell the first kernel what logon keys are needed to unlock the disk volumes,
+ # Add key #1
+ mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
+ # Add key #1's description
+ echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description
+
+ # how many keys do we have now?
+ cat /sys/kernel/config/crash_dm_crypt_keys/count
+ 1
+
+ # Add key #2 in the same way
+
+ # how many keys do we have now?
+ cat /sys/kernel/config/crash_dm_crypt_keys/count
+ 2
+
+ # To support CPU/memory hot-plugging, re-use keys already saved to reserved
+ # memory
+ echo true > /sys/kernel/config/crash_dm_crypt_key/reuse
+
+2. Load the dump-capture kernel
+
+3. After the dump-capture kerne get booted, restore the keys to user keyring
+ echo yes > /sys/kernel/crash_dm_crypt_keys/restore
+
Contact
=======
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6726f439958c..404a15f6782c 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -65,11 +65,11 @@ Defines the beginning of the text section. In general, _stext indicates
the kernel start address. Used to convert a virtual address from the
direct kernel map to a physical address.
-vmap_area_list
---------------
+VMALLOC_START
+-------------
-Stores the virtual area list. makedumpfile gets the vmalloc start value
-from this variable and its value is necessary for vmalloc translation.
+Stores the base address of vmalloc area. makedumpfile gets this value
+since is necessary for vmalloc translation.
mem_map
-------
@@ -141,8 +141,8 @@ nodemask_t
The size of a nodemask_t type. Used to compute the number of online
nodes.
-(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|compound_order|compound_head)
--------------------------------------------------------------------------------------------------
+(page, flags|_refcount|mapping|lru|_mapcount|private|compound_order|compound_head)
+----------------------------------------------------------------------------------
User-space tools compute their values based on the offset of these
variables. The variables are used when excluding unnecessary pages.
@@ -172,7 +172,7 @@ variables.
Offset of the free_list's member. This value is used to compute the number
of free pages.
-Each zone has a free_area structure array called free_area[MAX_ORDER].
+Each zone has a free_area structure array called free_area[NR_PAGE_ORDERS].
The free_list represents a linked list of free page blocks.
(list_head, next|prev)
@@ -189,11 +189,11 @@ Offsets of the vmap_area's members. They carry vmalloc-specific
information. Makedumpfile gets the start address of the vmalloc region
from this.
-(zone.free_area, MAX_ORDER)
----------------------------
+(zone.free_area, NR_PAGE_ORDERS)
+--------------------------------
Free areas descriptor. User-space tools use this value to iterate the
-free_area ranges. MAX_ORDER is used by the zone buddy allocator.
+free_area ranges. NR_PAGE_ORDERS is used by the zone buddy allocator.
prb
---
@@ -325,25 +325,19 @@ NR_FREE_PAGES
On linux-2.6.21 or later, the number of free pages is in
vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
-PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask
-------------------------------------------------------------------------------
+PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_hwpoison|PG_head_mask
+--------------------------------------------------------------------------
Page attributes. These flags are used to filter various unnecessary for
dumping pages.
-PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
------------------------------------------------------------------------------
+PAGE_SLAB_MAPCOUNT_VALUE|PAGE_BUDDY_MAPCOUNT_VALUE|PAGE_OFFLINE_MAPCOUNT_VALUE|PAGE_HUGETLB_MAPCOUNT_VALUE|PAGE_UNACCEPTED_MAPCOUNT_VALUE
+------------------------------------------------------------------------------------------------------------------------------------------
More page attributes. These flags are used to filter various unnecessary for
dumping pages.
-HUGETLB_PAGE_DTOR
------------------
-
-The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile
-excludes these pages.
-
x86_64
======
@@ -419,36 +413,6 @@ of a higher page table lookup overhead, and also consumes more page
table space per process. Used to check whether PAE was enabled in the
crash kernel when converting virtual addresses to physical addresses.
-ia64
-====
-
-pgdat_list|(pgdat_list, MAX_NUMNODES)
--------------------------------------
-
-pg_data_t array storing all NUMA nodes information. MAX_NUMNODES
-indicates the number of the nodes.
-
-node_memblk|(node_memblk, NR_NODE_MEMBLKS)
-------------------------------------------
-
-List of node memory chunks. Filled when parsing the SRAT table to obtain
-information about memory nodes. NR_NODE_MEMBLKS indicates the number of
-node memory chunks.
-
-These values are used to compute the number of nodes the crashed kernel used.
-
-node_memblk_s|(node_memblk_s, start_paddr)|(node_memblk_s, size)
-----------------------------------------------------------------
-
-The size of a struct node_memblk_s and the offsets of the
-node_memblk_s's members. Used to compute the number of nodes.
-
-PGTABLE_3|PGTABLE_4
--------------------
-
-User-space tools need to know whether the crash kernel was in 3-level or
-4-level paging mode. Used to distinguish the page table.
-
ARM64
=====
@@ -595,3 +559,38 @@ X2TLB
-----
Indicates whether the crashed kernel enabled SH extended mode.
+
+RISCV64
+=======
+
+VA_BITS
+-------
+
+The maximum number of bits for virtual addresses. Used to compute the
+virtual memory ranges.
+
+PAGE_OFFSET
+-----------
+
+Indicates the virtual kernel start address of the direct-mapped RAM region.
+
+phys_ram_base
+-------------
+
+Indicates the start physical RAM address.
+
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KERNEL_LINK_ADDR
+----------------------------------------------------------------------------------------------
+
+Used to get the correct ranges:
+
+ * MODULES_VADDR ~ MODULES_END : Kernel module space.
+ * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
+ * VMEMMAP_START ~ VMEMMAP_END : vmemmap space, used for struct page array.
+ * KERNEL_LINK_ADDR : start address of Kernel link and BPF
+
+va_kernel_pa_offset
+-------------------
+
+Indicates the offset between the kernel virtual and physical mappings.
+Used to translate virtual to physical addresses.
diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst
index 959f73a32712..02a725536cc5 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
.. _kernelparameters:
The kernel's command-line parameters
@@ -27,6 +29,16 @@ kernel command line (/proc/cmdline) and collects module parameters
when it loads a module, so the kernel command line can be used for
loadable modules too.
+This document may not be entirely up to date and comprehensive. The command
+"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
+module. Loadable modules, after being loaded into the running kernel, also
+reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
+parameters may be changed at runtime by the command
+``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``.
+
+Special handling
+----------------
+
Hyphens (dashes) and underscores are equivalent in parameter names, so::
log_buf_len=1M print-fatal-signals=1
@@ -39,8 +51,8 @@ Double-quotes can be used to protect spaces in values, e.g.::
param="spaces in here"
-cpu lists:
-----------
+cpu lists
+~~~~~~~~~
Some kernel parameters take a list of CPUs as a value, e.g. isolcpus,
nohz_full, irqaffinity, rcu_nocbs. The format of this list is:
@@ -80,126 +92,35 @@ The special case-tolerant group name "all" has a meaning of selecting all CPUs,
so that "nohz_full=all" is the equivalent of "nohz_full=0-N".
The semantics of "N" and "all" is supported on a level of bitmaps and holds for
-all users of bitmap_parse().
+all users of bitmap_parselist().
-This document may not be entirely up to date and comprehensive. The command
-"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
-module. Loadable modules, after being loaded into the running kernel, also
-reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
-parameters may be changed at runtime by the command
-``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``.
+Metric suffixes
+~~~~~~~~~~~~~~~
-The parameters listed below are only valid if certain kernel build options were
-enabled and if respective hardware is present. The text in square brackets at
-the beginning of each description states the restrictions within which a
-parameter is applicable::
-
- ACPI ACPI support is enabled.
- AGP AGP (Accelerated Graphics Port) is enabled.
- ALSA ALSA sound support is enabled.
- APIC APIC support is enabled.
- APM Advanced Power Management support is enabled.
- APPARMOR AppArmor support is enabled.
- ARM ARM architecture is enabled.
- ARM64 ARM64 architecture is enabled.
- AX25 Appropriate AX.25 support is enabled.
- CLK Common clock infrastructure is enabled.
- CMA Contiguous Memory Area support is enabled.
- DRM Direct Rendering Management support is enabled.
- DYNAMIC_DEBUG Build in debug messages and enable them at runtime
- EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
- EFI EFI Partitioning (GPT) is enabled
- EVM Extended Verification Module
- FB The frame buffer device is enabled.
- FTRACE Function tracing enabled.
- GCOV GCOV profiling is enabled.
- HIBERNATION HIBERNATION is enabled.
- HW Appropriate hardware is enabled.
- HYPER_V HYPERV support is enabled.
- IA-64 IA-64 architecture is enabled.
- IMA Integrity measurement architecture is enabled.
- IP_PNP IP DHCP, BOOTP, or RARP is enabled.
- IPV6 IPv6 support is enabled.
- ISAPNP ISA PnP code is enabled.
- ISDN Appropriate ISDN support is enabled.
- ISOL CPU Isolation is enabled.
- JOY Appropriate joystick support is enabled.
- KGDB Kernel debugger support is enabled.
- KVM Kernel Virtual Machine support is enabled.
- LIBATA Libata driver is enabled
- LP Printer support is enabled.
- LOOP Loopback device support is enabled.
- M68k M68k architecture is enabled.
- These options have more detailed description inside of
- Documentation/m68k/kernel-options.rst.
- MDA MDA console support is enabled.
- MIPS MIPS architecture is enabled.
- MOUSE Appropriate mouse support is enabled.
- MSI Message Signaled Interrupts (PCI).
- MTD MTD (Memory Technology Device) support is enabled.
- NET Appropriate network support is enabled.
- NUMA NUMA support is enabled.
- NFS Appropriate NFS support is enabled.
- OF Devicetree is enabled.
- PV_OPS A paravirtualized kernel is enabled.
- PARIDE The ParIDE (parallel port IDE) subsystem is enabled.
- PARISC The PA-RISC architecture is enabled.
- PCI PCI bus support is enabled.
- PCIE PCI Express support is enabled.
- PCMCIA The PCMCIA subsystem is enabled.
- PNP Plug & Play support is enabled.
- PPC PowerPC architecture is enabled.
- PPT Parallel port support is enabled.
- PS2 Appropriate PS/2 support is enabled.
- RAM RAM disk support is enabled.
- RISCV RISCV architecture is enabled.
- RDT Intel Resource Director Technology.
- S390 S390 architecture is enabled.
- SCSI Appropriate SCSI support is enabled.
- A lot of drivers have their options described inside
- the Documentation/scsi/ sub-directory.
- SECURITY Different security models are enabled.
- SELINUX SELinux support is enabled.
- SERIAL Serial support is enabled.
- SH SuperH architecture is enabled.
- SMP The kernel is an SMP kernel.
- SPARC Sparc architecture is enabled.
- SWSUSP Software suspend (hibernation) is enabled.
- SUSPEND System suspend states are enabled.
- TPM TPM drivers are enabled.
- UMS USB Mass Storage support is enabled.
- USB USB support is enabled.
- USBHID USB Human Interface Device support is enabled.
- V4L Video For Linux support is enabled.
- VMMIO Driver for memory mapped virtio devices is enabled.
- VGA The VGA console has been enabled.
- VT Virtual terminal support is enabled.
- WDT Watchdog support is enabled.
- X86-32 X86-32, aka i386 architecture is enabled.
- X86-64 X86-64 architecture is enabled.
- More X86-64 boot options can be found in
- Documentation/x86/x86_64/boot-options.rst.
- X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
- X86_UV SGI UV support is enabled.
- XEN Xen support is enabled
- XTENSA xtensa architecture is enabled.
-
-In addition, the following text indicates that the option::
-
- BUGS= Relates to possible processor bugs on the said processor.
- KNL Is a kernel start-up parameter.
- BOOT Is a boot loader parameter.
+The [KMG] suffix is commonly described after a number of kernel
+parameter values. 'K', 'M', 'G', 'T', 'P', and 'E' suffixes are allowed.
+These letters represent the _binary_ multipliers 'Kilo', 'Mega', 'Giga',
+'Tera', 'Peta', and 'Exa', equaling 2^10, 2^20, 2^30, 2^40, 2^50, and
+2^60 bytes respectively. Such letter suffixes can also be entirely omitted.
+
+Kernel Build Options
+--------------------
+
+The parameters listed below are only valid if certain kernel build options
+were enabled and if respective hardware is present. This list should be kept
+in alphabetical order. The text in square brackets at the beginning
+of each description states the restrictions within which a parameter
+is applicable.
Parameters denoted with BOOT are actually interpreted by the boot
loader, and have no meaning to the kernel directly.
Do not modify the syntax of boot loader parameters without extreme
-need or coordination with <Documentation/x86/boot.rst>.
+need or coordination with <Documentation/arch/x86/boot.rst>.
There are also arch-specific kernel-parameters not documented here.
-See for example <Documentation/x86/x86_64/boot-options.rst>.
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
-a trailing = on the name of any parameter states that that parameter will
+a trailing = on the name of any parameter states that the parameter will
be entered as an environment variable, whereas its absence indicates that
it will appear as a kernel argument readable via /proc/cmdline by programs
running once the system is up.
@@ -210,15 +131,5 @@ a fixed number of characters. This limit depends on the architecture
and is between 256 and 4096 characters. It is defined in the file
./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.
-Finally, the [KMG] suffix is commonly described after a number of kernel
-parameter values. These 'K', 'M', and 'G' letters represent the _binary_
-multipliers 'Kilo', 'Mega', and 'Giga', equaling 2^10, 2^20, and 2^30
-bytes respectively. Such letter suffixes can also be entirely omitted:
-
.. include:: kernel-parameters.txt
:literal:
-
-Todo
-----
-
- Add more DRM drivers.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 02ee2e2405e7..a8d0afde7f85 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1,21 +1,138 @@
- acpi= [HW,ACPI,X86,ARM64]
+ ACPI ACPI support is enabled.
+ AGP AGP (Accelerated Graphics Port) is enabled.
+ ALSA ALSA sound support is enabled.
+ APIC APIC support is enabled.
+ APM Advanced Power Management support is enabled.
+ APPARMOR AppArmor support is enabled.
+ ARM ARM architecture is enabled.
+ ARM64 ARM64 architecture is enabled.
+ AX25 Appropriate AX.25 support is enabled.
+ CLK Common clock infrastructure is enabled.
+ CMA Contiguous Memory Area support is enabled.
+ DRM Direct Rendering Management support is enabled.
+ DYNAMIC_DEBUG Build in debug messages and enable them at runtime
+ EARLY Parameter processed too early to be embedded in initrd.
+ EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
+ EFI EFI Partitioning (GPT) is enabled
+ EVM Extended Verification Module
+ FB The frame buffer device is enabled.
+ FTRACE Function tracing enabled.
+ GCOV GCOV profiling is enabled.
+ HIBERNATION HIBERNATION is enabled.
+ HW Appropriate hardware is enabled.
+ HYPER_V HYPERV support is enabled.
+ IMA Integrity measurement architecture is enabled.
+ IP_PNP IP DHCP, BOOTP, or RARP is enabled.
+ IPV6 IPv6 support is enabled.
+ ISAPNP ISA PnP code is enabled.
+ ISDN Appropriate ISDN support is enabled.
+ ISOL CPU Isolation is enabled.
+ JOY Appropriate joystick support is enabled.
+ KGDB Kernel debugger support is enabled.
+ KVM Kernel Virtual Machine support is enabled.
+ LIBATA Libata driver is enabled
+ LOONGARCH LoongArch architecture is enabled.
+ LOOP Loopback device support is enabled.
+ LP Printer support is enabled.
+ M68k M68k architecture is enabled.
+ These options have more detailed description inside of
+ Documentation/arch/m68k/kernel-options.rst.
+ MDA MDA console support is enabled.
+ MIPS MIPS architecture is enabled.
+ MOUSE Appropriate mouse support is enabled.
+ MSI Message Signaled Interrupts (PCI).
+ MTD MTD (Memory Technology Device) support is enabled.
+ NET Appropriate network support is enabled.
+ NFS Appropriate NFS support is enabled.
+ NUMA NUMA support is enabled.
+ OF Devicetree is enabled.
+ PARISC The PA-RISC architecture is enabled.
+ PCI PCI bus support is enabled.
+ PCIE PCI Express support is enabled.
+ PCMCIA The PCMCIA subsystem is enabled.
+ PNP Plug & Play support is enabled.
+ PPC PowerPC architecture is enabled.
+ PPT Parallel port support is enabled.
+ PS2 Appropriate PS/2 support is enabled.
+ PV_OPS A paravirtualized kernel is enabled.
+ RAM RAM disk support is enabled.
+ RDT Intel Resource Director Technology.
+ RISCV RISCV architecture is enabled.
+ S390 S390 architecture is enabled.
+ SCSI Appropriate SCSI support is enabled.
+ A lot of drivers have their options described inside
+ the Documentation/scsi/ sub-directory.
+ SDW SoundWire support is enabled.
+ SECURITY Different security models are enabled.
+ SELINUX SELinux support is enabled.
+ SERIAL Serial support is enabled.
+ SH SuperH architecture is enabled.
+ SMP The kernel is an SMP kernel.
+ SPARC Sparc architecture is enabled.
+ SUSPEND System suspend states are enabled.
+ SWSUSP Software suspend (hibernation) is enabled.
+ TPM TPM drivers are enabled.
+ UMS USB Mass Storage support is enabled.
+ USB USB support is enabled.
+ USBHID USB Human Interface Device support is enabled.
+ V4L Video For Linux support is enabled.
+ VGA The VGA console has been enabled.
+ VMMIO Driver for memory mapped virtio devices is enabled.
+ VT Virtual terminal support is enabled.
+ WDT Watchdog support is enabled.
+ X86-32 X86-32, aka i386 architecture is enabled.
+ X86-64 X86-64 architecture is enabled.
+ X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
+ X86_UV SGI UV support is enabled.
+ XEN Xen support is enabled
+ XTENSA xtensa architecture is enabled.
+
+In addition, the following text indicates that the option
+
+ BOOT Is a boot loader parameter.
+ BUGS= Relates to possible processor bugs on the said processor.
+ KNL Is a kernel start-up parameter.
+
+
+Kernel parameters
+
+ accept_memory= [MM]
+ Format: { eager | lazy }
+ default: lazy
+ By default, unaccepted memory is accepted lazily to
+ avoid prolonged boot times. The lazy option will add
+ some runtime overhead until all memory is eventually
+ accepted. In most cases the overhead is negligible.
+ For some workloads or for debugging purposes
+ accept_memory=eager can be used to accept all memory
+ at once during boot.
+
+ acpi= [HW,ACPI,X86,ARM64,RISCV64,EARLY]
Advanced Configuration and Power Interface
Format: { force | on | off | strict | noirq | rsdt |
- copy_dsdt }
+ copy_dsdt | nospcr }
force -- enable ACPI if default was off
- on -- enable ACPI but allow fallback to DT [arm64]
+ on -- enable ACPI but allow fallback to DT [arm64,riscv64]
off -- disable ACPI if default was on
noirq -- do not use ACPI for IRQ routing
strict -- Be less tolerant of platforms that are not
strictly ACPI specification compliant.
rsdt -- prefer RSDT over (default) XSDT
copy_dsdt -- copy DSDT to memory
- For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force"
+ nocmcff -- Disable firmware first mode for corrected
+ errors. This disables parsing the HEST CMC error
+ source to check if firmware has set the FF flag. This
+ may result in duplicate corrected error reports.
+ nospcr -- disable console in ACPI SPCR table as
+ default _serial_ console on ARM64
+ For ARM64, ONLY "acpi=off", "acpi=on", "acpi=force" or
+ "acpi=nospcr" are available
+ For RISCV64, ONLY "acpi=off", "acpi=on" or "acpi=force"
are available
See also Documentation/power/runtime_pm.rst, pci=noacpi
- acpi_apic_instance= [ACPI, IOAPIC]
+ acpi_apic_instance= [ACPI,IOAPIC,EARLY]
Format: <int>
2: use 2nd APIC table, if available
1,0: use 1st APIC table
@@ -30,7 +147,7 @@
If set to native, use the device's native backlight mode.
If set to none, disable the ACPI backlight interface.
- acpi_force_32bit_fadt_addr
+ acpi_force_32bit_fadt_addr [ACPI,EARLY]
force FADT to use 32 bit addresses rather than the
64 bit X_* addresses. Some firmware have broken 64
bit addresses for force ACPI ignore these and use
@@ -86,7 +203,7 @@
no: ACPI OperationRegions are not marked as reserved,
no further checks are performed.
- acpi_force_table_verification [HW,ACPI]
+ acpi_force_table_verification [HW,ACPI,EARLY]
Enable table checksum verification during early stage.
By default, this is disabled due to x86 early mapping
size limitation.
@@ -126,7 +243,7 @@
acpi_no_memhotplug [ACPI] Disable memory hotplug. Useful for kdump
kernels.
- acpi_no_static_ssdt [HW,ACPI]
+ acpi_no_static_ssdt [HW,ACPI,EARLY]
Disable installation of static SSDTs at early boot time
By default, SSDTs contained in the RSDT/XSDT will be
installed automatically and they will appear under
@@ -140,7 +257,7 @@
Ignore the ACPI-based watchdog interface (WDAT) and let
a native driver control the watchdog device instead.
- acpi_rsdp= [ACPI,EFI,KEXEC]
+ acpi_rsdp= [ACPI,EFI,KEXEC,EARLY]
Pass the RSDP address to the kernel, mostly used
on machines running EFI runtime service to boot the
second kernel for kdump.
@@ -217,10 +334,10 @@
to assume that this machine's pmtimer latches its value
and always returns good values.
- acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
+ acpi_sci= [HW,ACPI,EARLY] ACPI System Control Interrupt trigger mode
Format: { level | edge | high | low }
- acpi_skip_timer_override [HW,ACPI]
+ acpi_skip_timer_override [HW,ACPI,EARLY]
Recognize and ignore IRQ0/pin2 Interrupt Override.
For broken nForce2 BIOS resulting in XT-PIC timer.
@@ -255,11 +372,11 @@
behave incorrectly in some ways with respect to system
suspend and resume to be ignored (use wisely).
- acpi_use_timer_override [HW,ACPI]
+ acpi_use_timer_override [HW,ACPI,EARLY]
Use timer override. For some broken Nvidia NF5 boards
that require a timer override, but don't have HPET
- add_efi_memmap [EFI; X86] Include EFI memory map in
+ add_efi_memmap [EFI,X86,EARLY] Include EFI memory map in
kernel's map of available physical RAM.
agp= [AGP]
@@ -296,7 +413,7 @@
do not want to use tracing_snapshot_alloc() as it needs
to be done where GFP_KERNEL allocations are allowed.
- allow_mismatched_32bit_el0 [ARM64]
+ allow_mismatched_32bit_el0 [ARM64,EARLY]
Allow execve() of 32-bit applications and setting of the
PER_LINUX32 personality on systems where only a strict
subset of the CPUs support 32-bit EL0. When this
@@ -304,7 +421,7 @@
EL0 is indicated by /sys/devices/system/cpu/aarch32_el0
and hot-unplug operations may be restricted.
- See Documentation/arm64/asymmetric-32bit.rst for more
+ See Documentation/arch/arm64/asymmetric-32bit.rst for more
information.
amd_iommu= [HW,X86-64]
@@ -318,9 +435,17 @@
allowed anymore to lift isolation
requirements as needed. This option
does not override iommu=pt
- force_enable - Force enable the IOMMU on platforms known
- to be buggy with IOMMU enabled. Use this
- option with care.
+ force_enable - Force enable the IOMMU on platforms known
+ to be buggy with IOMMU enabled. Use this
+ option with care.
+ pgtbl_v1 - Use v1 page table for DMA-API (Default).
+ pgtbl_v2 - Use v2 page table for DMA-API.
+ irtcachedis - Disable Interrupt Remapping Table (IRT) caching.
+ nohugepages - Limit page-sizes used for v1 page-tables
+ to 4 KiB.
+ v2_pgsizes_only - Limit page-sizes used for v1 page-tables
+ to 4KiB/2Mib/1GiB.
+
amd_iommu_dump= [HW,X86-64]
Enable AMD IOMMU driver option to dump the ACPI table
@@ -337,6 +462,34 @@
This mode requires kvm-amd.avic=1.
(Default when IOMMU HW support is present.)
+ amd_pstate= [X86,EARLY]
+ disable
+ Do not enable amd_pstate as the default
+ scaling driver for the supported processors
+ passive
+ Use amd_pstate with passive mode as a scaling driver.
+ In this mode autonomous selection is disabled.
+ Driver requests a desired performance level and platform
+ tries to match the same performance level if it is
+ satisfied by guaranteed performance level.
+ active
+ Use amd_pstate_epp driver instance as the scaling driver,
+ driver provides a hint to the hardware if software wants
+ to bias toward performance (0x0) or energy efficiency (0xff)
+ to the CPPC firmware. then CPPC power algorithm will
+ calculate the runtime workload and adjust the realtime cores
+ frequency.
+ guided
+ Activate guided autonomous mode. Driver requests minimum and
+ maximum performance level and the platform autonomously
+ selects a performance level in this range and appropriate
+ to the current workload.
+
+ amd_prefcore=
+ [X86]
+ disable
+ Disable amd-pstate preferred core.
+
amijoy.map= [HW,JOY] Amiga joystick support
Map of devices attached to JOY0DAT and JOY1DAT
Format: <a>,<b>
@@ -354,17 +507,15 @@
not play well with APC CPU idle - disable it if you have
APC and your system crashes randomly.
- apic= [APIC,X86] Advanced Programmable Interrupt Controller
+ apic [APIC,X86-64] Use IO-APIC. Default.
+
+ apic= [APIC,X86,EARLY] Advanced Programmable Interrupt Controller
Change the output verbosity while booting
Format: { quiet (default) | verbose | debug }
Change the amount of debugging information output
when initialising the APIC and IO-APIC components.
- For X86-32, this can also be used to specify an APIC
- driver name.
- Format: apic=driver_name
- Examples: apic=bigsmp
- apic_extnmi= [APIC,X86] External NMI delivery setting
+ apic_extnmi= [APIC,X86,EARLY] External NMI delivery setting
Format: { bsp (default) | all | none }
bsp: External NMI is delivered only to CPU 0
all: External NMIs are broadcast to all CPUs as a
@@ -373,39 +524,53 @@
useful so that a dump capture kernel won't be
shot down by NMI
+ apicpmtimer Do APIC timer calibration using the pmtimer. Implies
+ apicmaintimer. Useful when your PIT timer is totally
+ broken.
+
autoconf= [IPV6]
See Documentation/networking/ipv6.rst.
- show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
- Limit apic dumping. The parameter defines the maximal
- number of local apics being dumped. Also it is possible
- to set it to "all" by meaning -- no limit here.
- Format: { 1 (default) | 2 | ... | all }.
- The parameter valid if only apic=debug or
- apic=verbose is specified.
- Example: apic=debug show_lapic=all
-
apm= [APM] Advanced Power Management
See header of arch/x86/kernel/apm_32.c.
+ apparmor= [APPARMOR] Disable or enable AppArmor at boot time
+ Format: { "0" | "1" }
+ See security/apparmor/Kconfig help text
+ 0 -- disable.
+ 1 -- enable.
+ Default value is set via kernel config option.
+
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
Format: <io>,<irq>,<nodeID>
+ arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
+ 32 bit applications.
+
arm64.nobti [ARM64] Unconditionally disable Branch Target
Identification support
- arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication
+ arm64.nogcs [ARM64] Unconditionally disable Guarded Control Stack
support
+ arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
+ Set instructions support
+
+ arm64.nompam [ARM64] Unconditionally disable Memory Partitioning And
+ Monitoring support
+
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
support
- arm64.nosve [ARM64] Unconditionally disable Scalable Vector
- Extension support
+ arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication
+ support
arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
Extension support
+ arm64.nosve [ARM64] Unconditionally disable Scalable Vector
+ Extension support
+
ataflop= [HW,M68k]
atarimouse= [HW,MOUSE] Atari Mouse
@@ -467,22 +632,37 @@
Format: <io>,<irq>,<mode>
See header of drivers/net/hamradio/baycom_ser_hdx.c.
+ bdev_allow_write_mounted=
+ Format: <bool>
+ Control the ability to open a mounted block device
+ for writing, i.e., allow / disallow writes that bypass
+ the FS. This was implemented as a means to prevent
+ fuzzers from crashing the kernel by overwriting the
+ metadata underneath a mounted FS without its awareness.
+ This also prevents destructive formatting of mounted
+ filesystems by naive storage tooling that don't use
+ O_EXCL. Default is Y and can be changed through the
+ Kconfig option CONFIG_BLK_DEV_WRITE_MOUNTED.
+
bert_disable [ACPI]
Disable BERT OS support on buggy BIOSes.
- bgrt_disable [ACPI][X86]
+ bgrt_disable [ACPI,X86,EARLY]
Disable BGRT to avoid flickering OEM logo.
blkdevparts= Manual partition parsing of block device(s) for
embedded devices based on command line input.
See Documentation/block/cmdline-partition.rst
- boot_delay= Milliseconds to delay each printk during boot.
- Values larger than 10 seconds (10000) are changed to
- no delay (0).
+ boot_delay= [KNL,EARLY]
+ Milliseconds to delay each printk during boot.
+ Only works if CONFIG_BOOT_PRINTK_DELAY is enabled,
+ and you may also have to specify "lpj=". Boot_delay
+ values larger than 10 seconds (10000) are assumed
+ erroneous and ignored.
Format: integer
- bootconfig [KNL]
+ bootconfig [KNL,EARLY]
Extended command line options can be added to an initrd
and this will cause the kernel to look for it.
@@ -517,14 +697,32 @@
trust validation.
format: { id:<keyid> | builtin }
- cca= [MIPS] Override the kernel pages' cache coherency
+ cca= [MIPS,EARLY] Override the kernel pages' cache coherency
algorithm. Accepted values range from 0 to 7
inclusive. See arch/mips/include/asm/pgtable-bits.h
for platform specific values (SB1, Loongson3 and
others).
ccw_timeout_log [S390]
- See Documentation/s390/common_io.rst for details.
+ See Documentation/arch/s390/common_io.rst for details.
+
+ cfi= [X86-64] Set Control Flow Integrity checking features
+ when CONFIG_FINEIBT is enabled.
+ Format: feature[,feature...]
+ Default: auto
+
+ auto: Use FineIBT if IBT available, otherwise kCFI.
+ Under FineIBT, enable "paranoid" mode when
+ FRED is not available.
+ off: Turn off CFI checking.
+ kcfi: Use kCFI (disable FineIBT).
+ fineibt: Use FineIBT (even if IBT not available).
+ norand: Do not re-randomize CFI hashes.
+ paranoid: Add caller hash checking under FineIBT.
+ bhi: Enable register poisoning to stop speculation
+ across FineIBT. (Disabled by default.)
+ warn: Do not enforce CFI checking: warn only.
+ debug: Report CFI initialization details.
cgroup_disable= [KNL] Disable a particular controller or optional feature
Format: {name of the controller(s) or feature(s) to disable}
@@ -551,10 +749,31 @@
named mounts. Specifying both "all" and "named" disables
all v1 hierarchies.
+ cgroup_v1_proc= [KNL] Show also missing controllers in /proc/cgroups
+ Format: { "true" | "false" }
+ /proc/cgroups lists only v1 controllers by default.
+ This compatibility option enables listing also v2
+ controllers (whose v1 code is not compiled!), so that
+ semi-legacy software can check this file to decide
+ about usage of v2 (sic) controllers.
+
+ cgroup_favordynmods= [KNL] Enable or Disable favordynmods.
+ Format: { "true" | "false" }
+ Defaults to the value of CONFIG_CGROUP_FAVOR_DYNMODS.
+
cgroup.memory= [KNL] Pass options to the cgroup memory controller.
Format: <string>
nosocket -- Disable socket memory accounting.
nokmem -- Disable kernel memory accounting.
+ nobpf -- Disable BPF memory accounting.
+
+ check_pages= [MM,EARLY] Enable sanity checking of pages after
+ allocations / before freeing. This adds checks to catch
+ double-frees, use-after-frees, and other sources of
+ page corruption by inspecting page internals (flags,
+ mapcount/refcount, memcg_data, etc.).
+ Format: { "0" | "1" }
+ Default: 0 (1 if CONFIG_DEBUG_VM is set)
checkreqprot= [SELINUX] Set initial checkreqprot flag value.
Format: { "0" | "1" }
@@ -568,7 +787,7 @@
Setting checkreqprot to 1 is deprecated.
cio_ignore= [S390]
- See Documentation/s390/common_io.rst for details.
+ See Documentation/arch/s390/common_io.rst for details.
clearcpuid=X[,X...] [X86]
Disable CPUID feature X for the kernel. See
@@ -627,19 +846,13 @@
[X86-64] hpet,tsc
clocksource.arm_arch_timer.evtstrm=
- [ARM,ARM64]
+ [ARM,ARM64,EARLY]
Format: <bool>
Enable/disable the eventstream feature of the ARM
architected timer so that code using WFE-based polling
loops can be debugged more effectively on production
systems.
- clocksource.max_cswd_read_retries= [KNL]
- Number of clocksource_watchdog() retries due to
- external delays before the clock will be marked
- unstable. Defaults to two retries, that is,
- three attempts to read the clock under test.
-
clocksource.verify_n_cpus= [KNL]
Limit the number of CPUs checked for clocksources
marked with CLOCK_SOURCE_VERIFY_PERCPU that
@@ -657,7 +870,7 @@
10 seconds when built into the kernel.
cma=nn[MG]@[start[MG][-end[MG]]]
- [KNL,CMA]
+ [KNL,CMA,EARLY]
Sets the size of kernel global memory area for
contiguous memory allocations and optionally the
placement constraint by the physical address range of
@@ -666,16 +879,27 @@
kernel/dma/contiguous.c
cma_pernuma=nn[MG]
- [ARM64,KNL,CMA]
+ [KNL,CMA,EARLY]
Sets the size of kernel per-numa memory area for
contiguous memory allocations. A value of 0 disables
per-numa CMA altogether. And If this option is not
- specificed, the default value is 0.
+ specified, the default value is 0.
With per-numa CMA enabled, DMA users on node nid will
first try to allocate buffer from the pernuma area
which is located in node nid, if the allocation fails,
they will fallback to the global default memory area.
+ numa_cma=<node>:nn[MG][,<node>:nn[MG]]
+ [KNL,CMA,EARLY]
+ Sets the size of kernel numa memory area for
+ contiguous memory allocations. It will reserve CMA
+ area for the specified node.
+
+ With numa CMA enabled, DMA users on node nid will
+ first try to allocate buffer from the numa area
+ which is located in node nid, if the allocation fails,
+ they will fallback to the global default memory area.
+
cmo_free_hint= [PPC] Format: { yes | no }
Specify whether pages are marked as being inactive
when they are freed. This is used in CMO environments
@@ -683,7 +907,7 @@
a hypervisor.
Default: yes
- coherent_pool=nn[KMG] [ARM,KNL]
+ coherent_pool=nn[KMG] [ARM,KNL,EARLY]
Sets the size of memory pool for coherent, atomic dma
allocations, by default set to 256K.
@@ -701,6 +925,17 @@
condev= [HW,S390] console device
conmode=
+ con3215_drop= [S390,EARLY] 3215 console drop mode.
+ Format: y|n|Y|N|1|0
+ When set to true, drop data on the 3215 console when
+ the console buffer is full. In this case the
+ operator using a 3270 terminal emulator (for example
+ x3270) does not have to enter the clear key for the
+ console output to advance and the kernel to continue.
+ This leads to a much faster boot time when a 3270
+ terminal emulator is active. If no 3270 terminal
+ emulator is used, this parameter has no effect.
+
console= [KNL] Output console device and options.
tty<n> Use the virtual console device <n>.
@@ -718,6 +953,25 @@
Documentation/networking/netconsole.rst for an
alternative.
+ <DEVNAME>:<n>.<n>[,options]
+ Use the specified serial port on the serial core bus.
+ The addressing uses DEVNAME of the physical serial port
+ device, followed by the serial core controller instance,
+ and the serial port instance. The options are the same
+ as documented for the ttyS addressing above.
+
+ The mapping of the serial ports to the tty instances
+ can be viewed with:
+
+ $ ls -d /sys/bus/serial-base/devices/*:*.*/tty/*
+ /sys/bus/serial-base/devices/00:04:0.0/tty/ttyS0
+
+ In the above example, the console can be addressed with
+ console=00:04:0.0. Note that a console addressed this
+ way will only get added when the related device driver
+ is ready. The use of an earlycon parameter in addition to
+ the console may be desired for console output early on.
+
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
uart[8250],mmio16,<addr>[,options]
@@ -781,20 +1035,6 @@
Format:
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
- cpu0_hotplug [X86] Turn on CPU0 hotplug feature when
- CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off.
- Some features depend on CPU0. Known dependencies are:
- 1. Resume from suspend/hibernate depends on CPU0.
- Suspend/hibernate will fail if CPU0 is offline and you
- need to online CPU0 before suspend/hibernate.
- 2. PIC interrupts also depend on CPU0. CPU0 can't be
- removed if a PIC interrupt is detected.
- It's said poweroff/reboot may depend on CPU0 on some
- machines although I haven't seen such issues so far
- after CPU0 is offline on a few tested machines.
- If the dependencies are under your control, you can
- turn on cpu0_hotplug.
-
cpuidle.off=1 [CPU_IDLE]
disable the cpuidle sub-system
@@ -810,28 +1050,38 @@
kernel before the cpufreq driver probes.
cpu_init_udelay=N
- [X86] Delay for N microsec between assert and de-assert
+ [X86,EARLY] Delay for N microsec between assert and de-assert
of APIC INIT to start processors. This delay occurs
on every CPU online, such as boot, and resume from suspend.
Default: 10000
+ cpuhp.parallel=
+ [SMP] Enable/disable parallel bringup of secondary CPUs
+ Format: <bool>
+ Default is enabled if CONFIG_HOTPLUG_PARALLEL=y. Otherwise
+ the parameter has no effect.
+
crash_kexec_post_notifiers
- Run kdump after running panic-notifiers and dumping
- kmsg. This only for the users who doubt kdump always
- succeeds in any situation.
- Note that this also increases risks of kdump failure,
- because some panic notifiers can make the crashed
- kernel more unstable.
+ Only jump to kdump kernel after running the panic
+ notifiers and dumping kmsg. This option increases
+ the risks of a kdump failure, since some panic
+ notifiers can make the crashed kernel more unstable.
+ In configurations where kdump may not be reliable,
+ running the panic notifiers could allow collecting
+ more data on dmesg, like stack traces from other CPUS
+ or extra data dumped by panic_print. Note that some
+ configurations enable this option unconditionally,
+ like Hyper-V, PowerPC (fadump) and AMD SEV-SNP.
crashkernel=size[KMG][@offset[KMG]]
- [KNL] Using kexec, Linux can switch to a 'crash kernel'
+ [KNL,EARLY] Using kexec, Linux can switch to a 'crash kernel'
upon panic. This parameter reserves the physical
memory region [offset, offset + size] for that kernel
image. If '@offset' is omitted, then a suitable offset
is selected automatically.
- [KNL, X86-64] Select a region under 4G first, and
- fall back to reserve region above 4G when '@offset'
- hasn't been specified.
+ [KNL, X86-64, ARM64, RISCV, LoongArch] Select a region
+ under 4G first, and fall back to reserve region above
+ 4G when '@offset' hasn't been specified.
See Documentation/admin-guide/kdump/kdump.rst for further details.
crashkernel=range1:size1[,range2:size2,...][@offset]
@@ -842,32 +1092,54 @@
Documentation/admin-guide/kdump/kdump.rst for an example.
crashkernel=size[KMG],high
- [KNL, X86-64, ARM64] range could be above 4G. Allow kernel
- to allocate physical memory region from top, so could
- be above 4G if system have more than 4G ram installed.
- Otherwise memory region will be allocated below 4G, if
- available.
+ [KNL, X86-64, ARM64, RISCV, LoongArch] range could be
+ above 4G.
+ Allow kernel to allocate physical memory region from top,
+ so could be above 4G if system have more than 4G ram
+ installed. Otherwise memory region will be allocated
+ below 4G, if available.
It will be ignored if crashkernel=X is specified.
crashkernel=size[KMG],low
- [KNL, X86-64] range under 4G. When crashkernel=X,high
- is passed, kernel could allocate physical memory region
- above 4G, that cause second kernel crash on system
- that require some amount of low memory, e.g. swiotlb
- requires at least 64M+32K low memory, also enough extra
- low memory is needed to make sure DMA buffers for 32-bit
- devices won't run out. Kernel would try to allocate
- at least 256M below 4G automatically.
+ [KNL, X86-64, ARM64, RISCV, LoongArch] range under 4G.
+ When crashkernel=X,high is passed, kernel could allocate
+ physical memory region above 4G, that cause second kernel
+ crash on system that require some amount of low memory,
+ e.g. swiotlb requires at least 64M+32K low memory, also
+ enough extra low memory is needed to make sure DMA buffers
+ for 32-bit devices won't run out. Kernel would try to allocate
+ default size of memory below 4G automatically. The default
+ size is platform dependent.
+ --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB)
+ --> arm64: 128MiB
+ --> riscv: 128MiB
+ --> loongarch: 128MiB
This one lets the user specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
-
- [KNL, ARM64] range in low memory.
- This one lets the user specify a low range in the
- DMA zone for the crash dump kernel.
- It will be ignored when crashkernel=X,high is not used
- or memory reserved is located in the DMA zones.
+ crashkernel=size[KMG],cma
+ [KNL, X86, ppc] Reserve additional crash kernel memory from
+ CMA. This reservation is usable by the first system's
+ userspace memory and kernel movable allocations (memory
+ balloon, zswap). Pages allocated from this memory range
+ will not be included in the vmcore so this should not
+ be used if dumping of userspace memory is intended and
+ it has to be expected that some movable kernel pages
+ may be missing from the dump.
+
+ A standard crashkernel reservation, as described above,
+ is still needed to hold the crash kernel and initrd.
+
+ This option increases the risk of a kdump failure: DMA
+ transfers configured by the first kernel may end up
+ corrupting the second kernel's memory.
+
+ This reservation method is intended for systems that
+ can't afford to sacrifice enough memory for standard
+ crashkernel reservation and where less reliable and
+ possibly incomplete kdump is preferable to no kdump at
+ all.
cryptomgr.notests
[KNL] Disable crypto self-tests
@@ -878,15 +1150,14 @@
cs89x0_media= [HW,NET]
Format: { rj45 | aui | bnc }
- csdlock_debug= [KNL] Enable debug add-ons of cross-CPU function call
- handling. When switched on, additional debug data is
- printed to the console in case a hanging CPU is
- detected, and that CPU is pinged again in order to try
- to resolve the hang situation.
- 0: disable csdlock debugging (default)
- 1: enable basic csdlock debugging (minor impact)
- ext: enable extended csdlock debugging (more impact,
- but more data)
+ csdlock_debug= [KNL] Enable or disable debug add-ons of cross-CPU
+ function call handling. When switched on,
+ additional debug data is printed to the console
+ in case a hanging CPU is detected, and that
+ CPU is pinged again in order to try to resolve
+ the hang situation. The default value of this
+ option depends on the CSD_LOCK_WAIT_DEBUG_DEFAULT
+ Kconfig option.
dasd= [HW,NET]
See header of drivers/s390/block/dasd_devmap.c.
@@ -896,10 +1167,10 @@
Format: <port#>,<type>
See also Documentation/input/devices/joystick-parport.rst
- debug [KNL] Enable kernel debugging (events log level).
+ debug [KNL,EARLY] Enable kernel debugging (events log level).
debug_boot_weak_hash
- [KNL] Enable printing [hashed] pointers early in the
+ [KNL,EARLY] Enable printing [hashed] pointers early in the
boot sequence. If enabled, we use a weak hash instead
of siphash to hash pointers. Use this option if you are
seeing instances of '(___ptrval___)') and need to see a
@@ -916,32 +1187,29 @@
will print _a_lot_ more information - normally only
useful to lockdep developers.
- debug_objects [KNL] Enable object debugging
-
- no_debug_objects
- [KNL] Disable object debugging
+ debug_objects [KNL,EARLY] Enable object debugging
debug_guardpage_minorder=
- [KNL] When CONFIG_DEBUG_PAGEALLOC is set, this
+ [KNL,EARLY] When CONFIG_DEBUG_PAGEALLOC is set, this
parameter allows control of the order of pages that will
be intentionally kept free (and hence protected) by the
buddy allocator. Bigger value increase the probability
of catching random memory corruption, but reduce the
amount of memory for normal system use. The maximum
- possible value is MAX_ORDER/2. Setting this parameter
- to 1 or 2 should be enough to identify most random
- memory corruption problems caused by bugs in kernel or
- driver code when a CPU writes to (or reads from) a
- random memory location. Note that there exists a class
- of memory corruptions problems caused by buggy H/W or
- F/W or by drivers badly programing DMA (basically when
- memory is written at bus level and the CPU MMU is
- bypassed) which are not detectable by
- CONFIG_DEBUG_PAGEALLOC, hence this option will not help
- tracking down these problems.
+ possible value is MAX_PAGE_ORDER/2. Setting this
+ parameter to 1 or 2 should be enough to identify most
+ random memory corruption problems caused by bugs in
+ kernel or driver code when a CPU writes to (or reads
+ from) a random memory location. Note that there exists
+ a class of memory corruptions problems caused by buggy
+ H/W or F/W or by drivers badly programming DMA
+ (basically when memory is written at bus level and the
+ CPU MMU is bypassed) which are not detectable by
+ CONFIG_DEBUG_PAGEALLOC, hence this option will not
+ help tracking down these problems.
debug_pagealloc=
- [KNL] When CONFIG_DEBUG_PAGEALLOC is set, this parameter
+ [KNL,EARLY] When CONFIG_DEBUG_PAGEALLOC is set, this parameter
enables the feature at boot time. By default, it is
disabled and the system will work mostly the same as a
kernel built without CONFIG_DEBUG_PAGEALLOC.
@@ -949,14 +1217,10 @@
useful to also enable the page_owner functionality.
on: enable the feature
- debugfs= [KNL] This parameter enables what is exposed to userspace
- and debugfs internal clients.
- Format: { on, no-mount, off }
+ debugfs= [KNL,EARLY] This parameter enables what is exposed to
+ userspace and debugfs internal clients.
+ Format: { on, off }
on: All functions are enabled.
- no-mount:
- Filesystem is not registered but kernel clients can
- access APIs and a crashkernel can be used to read
- its content. There is nothing to mount.
off: Filesystem is not registered and clients
get a -EPERM as result when trying to register files
or directories within debugfs.
@@ -1029,59 +1293,41 @@
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
- disable_1tb_segments [PPC]
+ disable_1tb_segments [PPC,EARLY]
Disables the use of 1TB hash page table segments. This
causes the kernel to fall back to 256MB segments which
can be useful when debugging issues that require an SLB
miss to occur.
- stress_slb [PPC]
- Limits the number of kernel SLB entries, and flushes
- them frequently to increase the rate of SLB faults
- on kernel addresses.
-
disable= [IPV6]
See Documentation/networking/ipv6.rst.
- disable_radix [PPC]
+ disable_radix [PPC,EARLY]
Disable RADIX MMU mode on POWER9
- radix_hcall_invalidate=on [PPC/PSERIES]
- Disable RADIX GTSE feature and use hcall for TLB
- invalidate.
-
disable_tlbie [PPC]
Disable TLBIE instruction. Currently does not work
with KVM, with HASH MMU, or with coherent accelerators.
- disable_cpu_apicid= [X86,APIC,SMP]
- Format: <int>
- The number of initial APIC ID for the
- corresponding CPU to be disabled at boot,
- mostly used for the kdump 2nd kernel to
- disable BSP to wake up multiple CPUs without
- causing system reset or hang due to sending
- INIT from AP to BSP.
-
- disable_ddw [PPC/PSERIES]
+ disable_ddw [PPC/PSERIES,EARLY]
Disable Dynamic DMA Window support. Use this
to workaround buggy firmware.
disable_ipv6= [IPV6]
See Documentation/networking/ipv6.rst.
- disable_mtrr_cleanup [X86]
+ disable_mtrr_cleanup [X86,EARLY]
The kernel tries to adjust MTRR layout from continuous
to discrete, to make X server driver able to add WB
entry later. This parameter disables that.
- disable_mtrr_trim [X86, Intel and AMD only]
+ disable_mtrr_trim [X86, Intel and AMD only,EARLY]
By default the kernel will trim any uncacheable
memory out of your available memory pool based on
MTRR settings. This parameter disables that behavior,
possibly causing your machine to run very slowly.
- disable_timer_pin_1 [X86]
+ disable_timer_pin_1 [X86,EARLY]
Disable PIN 1 of APIC timer
Can be useful to work around chipset bugs.
@@ -1104,6 +1350,26 @@
The filter can be disabled or changed to another
driver later using sysfs.
+ reg_file_data_sampling=
+ [X86] Controls mitigation for Register File Data
+ Sampling (RFDS) vulnerability. RFDS is a CPU
+ vulnerability which may allow userspace to infer
+ kernel data values previously stored in floating point
+ registers, vector registers, or integer registers.
+ RFDS only affects Intel Atom processors.
+
+ on: Turns ON the mitigation.
+ off: Turns OFF the mitigation.
+
+ This parameter overrides the compile time default set
+ by CONFIG_MITIGATION_RFDS. Mitigation cannot be
+ disabled when other VERW based mitigations (like MDS)
+ are enabled. In order to disable RFDS mitigation all
+ VERW based mitigations need to be disabled.
+
+ For details see:
+ Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
+
driver_async_probe= [KNL]
List of driver names to be probed asynchronously. *
matches with all driver names. If * is specified, the
@@ -1116,22 +1382,16 @@
panels may send no or incorrect EDID data sets.
This parameter allows to specify an EDID data sets
in the /lib/firmware directory that are used instead.
- Generic built-in EDID data sets are used, if one of
- edid/1024x768.bin, edid/1280x1024.bin,
- edid/1680x1050.bin, or edid/1920x1080.bin is given
- and no file with the same name exists. Details and
- instructions how to build your own EDID data are
- available in Documentation/admin-guide/edid.rst. An EDID
- data set will only be used for a particular connector,
- if its name and a colon are prepended to the EDID
- name. Each connector may use a unique EDID data
- set by separating the files with a comma. An EDID
+ An EDID data set will only be used for a particular
+ connector, if its name and a colon are prepended to
+ the EDID name. Each connector may use a unique EDID
+ data set by separating the files with a comma. An EDID
data set with no connector name will be used for
any connectors not explicitly specified.
dscc4.setup= [NET]
- dt_cpu_ftrs= [PPC]
+ dt_cpu_ftrs= [PPC,EARLY]
Format: {"off" | "known"}
Control how the dt_cpu_ftrs device-tree binding is
used for CPU feature discovery and setup (if it
@@ -1151,22 +1411,12 @@
Documentation/admin-guide/dynamic-debug-howto.rst
for details.
- nopku [X86] Disable Memory Protection Keys CPU feature found
- in some Intel CPUs.
-
- <module>.async_probe[=<bool>] [KNL]
- If no <bool> value is specified or if the value
- specified is not a valid <bool>, enable asynchronous
- probe on this module. Otherwise, enable/disable
- asynchronous probe on this module as indicated by the
- <bool> value. See also: module.async_probe
-
- early_ioremap_debug [KNL]
+ early_ioremap_debug [KNL,EARLY]
Enable debug messages in early_ioremap support. This
is useful for tracking down temporary early mappings
which are not unmapped.
- earlycon= [KNL] Output early console device and options.
+ earlycon= [KNL,EARLY] Output early console device and options.
When used with no options, the early console is
determined by stdout-path property in device tree's
@@ -1180,10 +1430,10 @@
specified, the serial port must already be setup and
configured.
- uart[8250],io,<addr>[,options]
- uart[8250],mmio,<addr>[,options]
- uart[8250],mmio32,<addr>[,options]
- uart[8250],mmio32be,<addr>[,options]
+ uart[8250],io,<addr>[,options[,uartclk]]
+ uart[8250],mmio,<addr>[,options[,uartclk]]
+ uart[8250],mmio32,<addr>[,options[,uartclk]]
+ uart[8250],mmio32be,<addr>[,options[,uartclk]]
uart[8250],0x<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
@@ -1192,7 +1442,9 @@
If none of [io|mmio|mmio32|mmio32be], <addr> is assumed
to be equivalent to 'mmio'. 'options' are specified
in the same format described for "console=ttyS<n>"; if
- unspecified, the h/w is not initialized.
+ unspecified, the h/w is not initialized. 'uartclk' is
+ the uart clock frequency; if unspecified, it is set
+ to 'BASE_BAUD' * 16.
pl011,<addr>
pl011,mmio32,<addr>
@@ -1300,7 +1552,7 @@
address must be provided, and the serial port must
already be setup and configured.
- earlyprintk= [X86,SH,ARM,M68k,S390]
+ earlyprintk= [X86,SH,ARM,M68k,S390,UM,EARLY]
earlyprintk=vga
earlyprintk=sclp
earlyprintk=xen
@@ -1308,13 +1560,18 @@
earlyprintk=serial[,0x...[,baudrate]]
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
- earlyprintk=pciserial[,force],bus:device.function[,baudrate]
+ earlyprintk=mmio32,membase[,{nocfg|baudrate}]
+ earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}]
earlyprintk=xdbc[xhciController#]
+ earlyprintk=bios
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
default because it has some cosmetic problems.
+ Use "nocfg" to skip UART configuration, assume
+ BIOS/firmware has configured UART correctly.
+
Append ",keep" to not disable it when the real console
takes over.
@@ -1340,6 +1597,8 @@
The sclp output can only be used on s390.
+ The bios output can only be used on SuperH.
+
The optional "force" to "pciserial" enables use of a
PCI device even when its classcode is not of the
UART class.
@@ -1355,7 +1614,7 @@
edd= [EDD]
Format: {"off" | "on" | "skip[mbr]"}
- efi= [EFI]
+ efi= [EFI,EARLY]
Format: { "debug", "disable_early_pci_dma",
"nochunk", "noruntime", "nosoftreserve",
"novamap", "no_disable_early_pci_dma" }
@@ -1376,33 +1635,12 @@
no_disable_early_pci_dma: Leave the busmaster bit set
on all PCI bridges while in the EFI boot stub
- efi_no_storage_paranoia [EFI; X86]
+ efi_no_storage_paranoia [EFI,X86,EARLY]
Using this parameter you can use more than 50% of
your efi variable storage. Use this parameter only if
you are really sure that your UEFI does sane gc and
fulfills the spec otherwise your board may brick.
- efi_fake_mem= nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI; X86]
- Add arbitrary attribute to specific memory range by
- updating original EFI memory map.
- Region of memory which aa attribute is added to is
- from ss to ss+nn.
-
- If efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000
- is specified, EFI_MEMORY_MORE_RELIABLE(0x10000)
- attribute is added to range 0x100000000-0x180000000 and
- 0x10a0000000-0x1120000000.
-
- If efi_fake_mem=8G@9G:0x40000 is specified, the
- EFI_MEMORY_SP(0x40000) attribute is added to
- range 0x240000000-0x43fffffff.
-
- Using this parameter you can do debugging of EFI memmap
- related features. For example, you can do debugging of
- Address Range Mirroring feature even if your box
- doesn't support it, or mark specific memory as
- "soft reserved".
-
efivar_ssdt= [EFI; X86] Name of an EFI variable that contains an SSDT
that is to be dynamically loaded by Linux. If there are
multiple variables with the same name but with different
@@ -1413,7 +1651,7 @@
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
- ekgdboc= [X86,KGDB] Allow early kernel console debugging
+ ekgdboc= [X86,KGDB,EARLY] Allow early kernel console debugging
Format: ekgdboc=kbd
This is designed to be used in conjunction with
@@ -1428,13 +1666,13 @@
See comment before function elanfreq_setup() in
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
- elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
+ elfcorehdr=[size[KMG]@]offset[KMG] [PPC,SH,X86,S390,EARLY]
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
kexec loader will pass this option to capture kernel.
See Documentation/admin-guide/kdump/kdump.rst for details.
- enable_mtrr_cleanup [X86]
+ enable_mtrr_cleanup [X86,EARLY]
The kernel tries to adjust MTRR layout from continuous
to discrete, to make X server driver able to add WB
entry later. This parameter enables that.
@@ -1467,9 +1705,18 @@
Permit 'security.evm' to be updated regardless of
current integrity status.
+ early_page_ext [KNL,EARLY] Enforces page_ext initialization to earlier
+ stages so cover more early boot allocations.
+ Please note that as side effect some optimizations
+ might be disabled to achieve that (e.g. parallelized
+ memory initialization is disabled) so the boot process
+ might take longer, especially on systems with a lot of
+ memory. Available with CONFIG_PAGE_EXTENSION=y.
+
failslab=
fail_usercopy=
fail_page_alloc=
+ fail_skb_realloc=
fail_make_request=[KNL]
General fault injection mechanism.
Format: <interval>,<probability>,<space>,<times>
@@ -1483,12 +1730,6 @@
floppy= [HW]
See Documentation/admin-guide/blockdev/floppy.rst.
- force_pal_cache_flush
- [IA-64] Avoid check_sal_cache_flush which may hang on
- buggy SAL_CACHE_FLUSH implementations. Using this
- parameter will force ia64_sal_cache_flush to call
- ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
-
forcepae [X86-32]
Forcefully enable Physical Address Extension (PAE).
Many Pentium M systems disable PAE but may have a
@@ -1496,6 +1737,12 @@
Warning: use of this parameter will taint the kernel
and may cause unknown problems.
+ fred= [X86-64]
+ Enable/disable Flexible Return and Event Delivery.
+ Format: { on | off }
+ on: enable FRED when it's present.
+ off: disable FRED, the default setting.
+
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
as early as possible in order to facilitate early
@@ -1509,12 +1756,37 @@
boot up that is likely to be overridden by user space
start up functionality.
- ftrace_dump_on_oops[=orig_cpu]
+ Optionally, the snapshot can also be defined for a tracing
+ instance that was created by the trace_instance= command
+ line parameter.
+
+ trace_instance=foo,sched_switch ftrace_boot_snapshot=foo
+
+ The above will cause the "foo" tracing instance to trigger
+ a snapshot at the end of boot up.
+
+ ftrace_dump_on_oops[=2(orig_cpu) | =<instance>][,<instance> |
+ ,<instance>=2(orig_cpu)]
[FTRACE] will dump the trace buffers on oops.
- If no parameter is passed, ftrace will dump
- buffers of all CPUs, but if you pass orig_cpu, it will
- dump only the buffer of the CPU that triggered the
- oops.
+ If no parameter is passed, ftrace will dump global
+ buffers of all CPUs, if you pass 2 or orig_cpu, it
+ will dump only the buffer of the CPU that triggered
+ the oops, or the specific instance will be dumped if
+ its name is passed. Multiple instance dump is also
+ supported, and instances are separated by commas. Each
+ instance supports only dump on CPU that triggered the
+ oops by passing 2 or orig_cpu to it.
+
+ ftrace_dump_on_oops=foo=orig_cpu
+
+ The above will dump only the buffer of "foo" instance
+ on CPU that triggered the oops.
+
+ ftrace_dump_on_oops,foo,bar=orig_cpu
+
+ The above will dump global buffer on all CPUs, the
+ buffer of "foo" instance on all CPUs and the buffer
+ of "bar" instance on CPU that triggered the oops.
ftrace_filter=[function-list]
[FTRACE] Limit the functions traced by the function
@@ -1548,7 +1820,7 @@
can be changed at run time by the max_graph_depth file
in the tracefs tracing directory. default: 0 (no limit)
- fw_devlink= [KNL] Create device links between consumer and supplier
+ fw_devlink= [KNL,EARLY] Create device links between consumer and supplier
devices by scanning the firmware to infer the
consumer/supplier relationships. This feature is
especially useful when drivers are loaded as modules as
@@ -1567,10 +1839,24 @@
rpm -- Like "on", but also use to order runtime PM.
fw_devlink.strict=<bool>
- [KNL] Treat all inferred dependencies as mandatory
+ [KNL,EARLY] Treat all inferred dependencies as mandatory
dependencies. This only applies for fw_devlink=on|rpm.
Format: <bool>
+ fw_devlink.sync_state =
+ [KNL,EARLY] When all devices that could probe have finished
+ probing, this parameter controls what to do with
+ devices that haven't yet received their sync_state()
+ calls.
+ Format: { strict | timeout }
+ strict -- Default. Continue waiting on consumers to
+ probe successfully.
+ timeout -- Give up waiting on consumers and call
+ sync_state() on any devices that haven't yet
+ received their sync_state() calls after
+ deferred_probe_timeout has expired or by
+ late_initcall() if !CONFIG_MODULES.
+
gamecon.map[2|3]=
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
support via parallel port (up to 5 devices per port)
@@ -1579,10 +1865,32 @@
gamma= [HW,DRM]
- gart_fix_e820= [X86-64] disable the fix e820 for K8 GART
+ gart_fix_e820= [X86-64,EARLY] disable the fix e820 for K8 GART
Format: off | on
default: on
+ gather_data_sampling=
+ [X86,INTEL,EARLY] Control the Gather Data Sampling (GDS)
+ mitigation.
+
+ Gather Data Sampling is a hardware vulnerability which
+ allows unprivileged speculative access to data which was
+ previously stored in vector registers.
+
+ This issue is mitigated by default in updated microcode.
+ The mitigation may have a performance impact but can be
+ disabled. On systems without the microcode mitigation
+ disabling AVX serves as a mitigation.
+
+ force: Disable AVX to mitigate systems without
+ microcode mitigation. No effect if the microcode
+ mitigation is present. Known to cause crashes in
+ userspace with buggy AVX enumeration.
+
+ off: Disable GDS mitigation.
+
+ gbpages [X86] Use GB pages for kernel direct mappings.
+
gcov_persist= [GCOV] When non-zero (default), profiling data for
kernel modules is saved and remains accessible via
debugfs, even when the module is unloaded/reloaded.
@@ -1630,7 +1938,9 @@
allocation boundaries as a proactive defense
against bounds-checking flaws in the kernel's
copy_to_user()/copy_from_user() interface.
- on Perform hardened usercopy checks (default).
+ The default is determined by
+ CONFIG_HARDENED_USERCOPY_DEFAULT_ON.
+ on Perform hardened usercopy checks.
off Disable hardened usercopy checks.
hardlockup_all_cpu_backtrace=
@@ -1638,13 +1948,32 @@
backtraces on all cpus.
Format: 0 | 1
+ hash_pointers=
+ [KNL,EARLY]
+ By default, when pointers are printed to the console
+ or buffers via the %p format string, that pointer is
+ "hashed", i.e. obscured by hashing the pointer value.
+ This is a security feature that hides actual kernel
+ addresses from unprivileged users, but it also makes
+ debugging the kernel more difficult since unequal
+ pointers can no longer be compared. The choices are:
+ Format: { auto | always | never }
+ Default: auto
+
+ auto - Hash pointers unless slab_debug is enabled.
+ always - Always hash pointers (even if slab_debug is
+ enabled).
+ never - Never hash pointers. This option should only
+ be specified when debugging the kernel. Do
+ not use on production kernels. The boot
+ param "no_hash_pointers" is an alias for
+ this mode.
+
hashdist= [KNL,NUMA] Large hashes allocated during boot
are distributed across NUMA nodes. Defaults on
for 64-bit NUMA, off otherwise.
Format: 0 | 1 (for off | on)
- hcl= [IA-64] SGI's Hardware Graph compatibility layer
-
hd= [EIDE] (E)IDE hard drive subsystem geometry
Format: <cyl>,<head>,<sect>
@@ -1662,7 +1991,35 @@
(that will set all pages holding image data
during restoration read-only).
- highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact
+ hibernate.compressor= [HIBERNATION] Compression algorithm to be
+ used with hibernation.
+ Format: { lzo | lz4 }
+ Default: lzo
+
+ lzo: Select LZO compression algorithm to
+ compress/decompress hibernation image.
+
+ lz4: Select LZ4 compression algorithm to
+ compress/decompress hibernation image.
+
+ hibernate.pm_test_delay=
+ [HIBERNATION]
+ Sets the number of seconds to remain in a hibernation test
+ mode before resuming the system (see
+ /sys/power/pm_test). Only available when CONFIG_PM_DEBUG
+ is set. Default value is 5.
+
+ hibernate_compression_threads=
+ [HIBERNATION]
+ Set the number of threads used for compressing or decompressing
+ hibernation images.
+
+ Format: <integer>
+ Default: 3
+ Minimum: 1
+ Example: hibernate_compression_threads=4
+
+ highmem=nn[KMG] [KNL,BOOT,EARLY] forces the highmem zone to have an exact
size of <nn>. This works even on boxes that have no
highmem otherwise. This also works to reduce highmem
size on bigger boxes.
@@ -1673,7 +2030,7 @@
hlt [BUGS=ARM,SH]
- hostname= [KNL] Set the hostname (aka UTS nodename).
+ hostname= [KNL,EARLY] Set the hostname (aka UTS nodename).
Format: <string>
This allows setting the system's hostname during early
startup. This sets the name returned by gethostname.
@@ -1697,7 +2054,7 @@
hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
- hugepages= [HW] Number of HugeTLB pages to allocate at boot.
+ hugepages= [HW,EARLY] Number of HugeTLB pages to allocate at boot.
If this follows hugepagesz (below), it specifies
the number of pages of hugepagesz to be allocated.
If this is the first HugeTLB parameter on the command
@@ -1709,16 +2066,25 @@
<node>:<integer>[,<node>:<integer>]
hugepagesz=
- [HW] The size of the HugeTLB pages. This is used in
- conjunction with hugepages (above) to allocate huge
- pages of a specific size at boot. The pair
- hugepagesz=X hugepages=Y can be specified once for
- each supported huge page size. Huge page sizes are
- architecture dependent. See also
+ [HW,EARLY] The size of the HugeTLB pages. This is
+ used in conjunction with hugepages (above) to
+ allocate huge pages of a specific size at boot. The
+ pair hugepagesz=X hugepages=Y can be specified once
+ for each supported huge page size. Huge page sizes
+ are architecture dependent. See also
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: size[KMG]
- hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
+ hugepage_alloc_threads=
+ [HW] The number of threads that should be used to
+ allocate hugepages during boot. This option can be
+ used to improve system bootup time when allocating
+ a large amount of huge pages.
+ The default value is 25% of the available hardware threads.
+
+ Note that this parameter only applies to non-gigantic huge pages.
+
+ hugetlb_cma= [HW,CMA,EARLY] The size of a CMA area used for allocation
of gigantic hugepages. Or using node format, the size
of a CMA area per node can be specified.
Format: nn[KMGTPE] or (node format)
@@ -1728,8 +2094,15 @@
hugepages using the CMA allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
+ hugetlb_cma_only=
+ [HW,CMA,EARLY] When allocating new HugeTLB pages, only
+ try to allocate from the CMA areas.
+
+ This option does nothing if hugetlb_cma= is not also
+ specified.
+
hugetlb_free_vmemmap=
- [KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
+ [KNL] Requires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
enabled.
Control if HugeTLB Vmemmap Optimization (HVO) is enabled.
Allows heavy hugetlb users to free up some more
@@ -1749,14 +2122,20 @@
the added memory block itself do not be affected.
hung_task_panic=
- [KNL] Should the hung task detector generate panics.
- Format: 0 | 1
+ [KNL] Number of hung tasks to trigger kernel panic.
+ Format: <int>
- A value of 1 instructs the kernel to panic when a
- hung task is detected. The default value is controlled
- by the CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time
- option. The value selected by this boot parameter can
- be changed later by the kernel.hung_task_panic sysctl.
+ When set to a non-zero value, a kernel panic will be triggered if
+ the number of detected hung tasks reaches this value.
+
+ 0: don't panic
+ 1: panic immediately on first hung task
+ N: panic after N hung tasks are detected in a single scan
+
+ The default value is controlled by the
+ CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time option. The value
+ selected by this boot parameter can be changed later by the
+ kernel.hung_task_panic sysctl.
hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
terminal devices. Valid values: 0..8
@@ -1764,15 +2143,16 @@
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
- hv_nopvspin [X86,HYPER_V] Disables the paravirt spinlock optimizations
- which allow the hypervisor to 'idle' the
- guest on lock contention.
+ hv_nopvspin [X86,HYPER_V,EARLY]
+ Disables the paravirt spinlock optimizations
+ which allow the hypervisor to 'idle' the guest
+ on lock contention.
- keep_bootcon [KNL]
- Do not unregister boot console at start. This is only
- useful for debugging when something happens in the window
- between unregistering the boot console and initializing
- the real console.
+ hw_protection= [HW]
+ Format: reboot | shutdown
+
+ Hardware protection action taken on critical events like
+ overtemperature or imminent voltage loss.
i2c_bus= [HW] Override the default board specific I2C bus speed
or register an additional I2C bus that is not
@@ -1780,6 +2160,28 @@
Format:
<bus_id>,<clkrate>
+ i2c_touchscreen_props= [HW,ACPI,X86]
+ Set device-properties for ACPI-enumerated I2C-attached
+ touchscreen, to e.g. fix coordinates of upside-down
+ mounted touchscreens. If you need this option please
+ submit a drivers/platform/x86/touchscreen_dmi.c patch
+ adding a DMI quirk for this.
+
+ Format:
+ <ACPI_HW_ID>:<prop_name>=<val>[:prop_name=val][:...]
+ Where <val> is one of:
+ Omit "=<val>" entirely Set a boolean device-property
+ Unsigned number Set a u32 device-property
+ Anything else Set a string device-property
+
+ Examples (split over multiple lines):
+ i2c_touchscreen_props=GDIX1001:touchscreen-inverted-x:
+ touchscreen-inverted-y
+
+ i2c_touchscreen_props=MSSL1680:touchscreen-size-x=1920:
+ touchscreen-size-y=1080:touchscreen-inverted-y:
+ firmware-name=gsl1680-vendor-model.fw:silead,home-button
+
i8042.debug [HW] Toggle i8042 debug mode
i8042.unmask_kbd_data
[HW] Enable printing of interrupt data from the KBD port
@@ -1827,18 +2229,33 @@
0 -- machine default
1 -- force brightness inversion
+ ia32_emulation= [X86-64]
+ Format: <bool>
+ When true, allows loading 32-bit programs and executing 32-bit
+ syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
+ boot time. When false, unconditionally disables IA32 emulation.
+
icn= [HW,ISDN]
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
- idle= [X86]
+ idle= [X86,EARLY]
Format: idle=poll, idle=halt, idle=nomwait
- Poll forces a polling idle loop that can slightly
- improve the performance of waking up a idle CPU, but
- will use a lot of power and make the system run hot.
- Not recommended.
+
+ idle=poll: Don't do power saving in the idle loop
+ using HLT, but poll for rescheduling event. This will
+ make the CPUs eat a lot more power, but may be useful
+ to get slightly better performance in multiprocessor
+ benchmarks. It also makes some profiling using
+ performance counters more accurate. Please note that
+ on systems with MONITOR/MWAIT support (like Intel
+ EM64T CPUs) this option has no performance advantage
+ over the normal idle loop. It may also interact badly
+ with hyperthreading.
+
idle=halt: Halt is forced to be used for CPU idle.
In such case C2/C3 won't be used again.
+
idle=nomwait: Disable mwait for CPU C-states
idxd.sva= [HW]
@@ -1853,7 +2270,7 @@
for the device. By default it is set to false (0).
ieee754= [MIPS] Select IEEE Std 754 conformance mode
- Format: { strict | legacy | 2008 | relaxed }
+ Format: { strict | legacy | 2008 | relaxed | emulated }
Default: strict
Choose which programs will be accepted for execution
@@ -1873,6 +2290,8 @@
by the FPU
relaxed accept any binaries regardless of whether
supported by the FPU
+ emulated accept any binaries but enable FPU emulator
+ if binary mode is unsupported by the FPU.
The FPU emulator is always able to support both NaN
encodings, so if no FPU hardware is present or it has
@@ -1887,7 +2306,7 @@
mode generally follows that for the NaN encoding,
except where unsupported by hardware.
- ignore_loglevel [KNL]
+ ignore_loglevel [KNL,EARLY]
Ignore loglevel setting - this will print /all/
kernel messages to the console. Useful for debugging.
We also add it as printk module parameter, so users
@@ -1980,6 +2399,28 @@
different crypto accelerators. This option can be used
to achieve best performance for particular HW.
+ ima= [IMA] Enable or disable IMA
+ Format: { "off" | "on" }
+ Default: "on"
+ Note that disabling IMA is limited to kdump kernel.
+
+ indirect_target_selection= [X86,Intel] Mitigation control for Indirect
+ Target Selection(ITS) bug in Intel CPUs. Updated
+ microcode is also required for a fix in IBPB.
+
+ on: Enable mitigation (default).
+ off: Disable mitigation.
+ force: Force the ITS bug and deploy default
+ mitigation.
+ vmexit: Only deploy mitigation if CPU is affected by
+ guest/host isolation part of ITS.
+ stuff: Deploy RSB-fill mitigation when retpoline is
+ also deployed. Otherwise, deploy the default
+ mitigation.
+
+ For details see:
+ Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
+
init= [KNL]
Format: <full_path>
Run specified binary instead of /sbin/init as init
@@ -2005,21 +2446,21 @@
unpacking being completed before device_ and
late_ initcalls.
- initrd= [BOOT] Specify the location of the initial ramdisk
+ initrd= [BOOT,EARLY] Specify the location of the initial ramdisk
- initrdmem= [KNL] Specify a physical address and size from which to
+ initrdmem= [KNL,EARLY] Specify a physical address and size from which to
load the initrd. If an initrd is compiled in or
specified in the bootparams, it takes priority over this
setting.
Format: ss[KMG],nn[KMG]
Default is 0, 0
- init_on_alloc= [MM] Fill newly allocated pages and heap objects with
+ init_on_alloc= [MM,EARLY] Fill newly allocated pages and heap objects with
zeroes.
Format: 0 | 1
Default set by CONFIG_INIT_ON_ALLOC_DEFAULT_ON.
- init_on_free= [MM] Fill freed pages and heap objects with zeroes.
+ init_on_free= [MM,EARLY] Fill freed pages and heap objects with zeroes.
Format: 0 | 1
Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON.
@@ -2075,10 +2516,20 @@
0 disables intel_idle and fall back on acpi_idle.
1 to 9 specify maximum depth of C-state.
- intel_pstate= [X86]
+ intel_pstate= [X86,EARLY]
disable
Do not enable intel_pstate as the default
scaling driver for the supported processors
+ active
+ Use intel_pstate driver to bypass the scaling
+ governors layer of cpufreq and provides it own
+ algorithms for p-state selection. There are two
+ P-state selection algorithms provided by
+ intel_pstate in the active mode: powersave and
+ performance. The way they both operate depends
+ on whether or not the hardware managed P-states
+ (HWP) feature has been enabled in the processor
+ and possibly on the processor model.
passive
Use intel_pstate as a scaling driver, but configure it
to work with generic cpufreq governors (instead of
@@ -2108,35 +2559,93 @@
per_cpu_perf_limits
Allow per-logical-CPU P-State performance control limits using
cpufreq sysfs interface
+ no_cas
+ Do not enable capacity-aware scheduling (CAS) on
+ hybrid systems
- intremap= [X86-64, Intel-IOMMU]
+ intremap= [X86-64,Intel-IOMMU,EARLY]
on enable Interrupt Remapping (default)
off disable Interrupt Remapping
nosid disable Source ID checking
no_x2apic_optout
BIOS x2APIC opt-out request will be ignored
nopost disable Interrupt Posting
+ posted_msi
+ enable MSIs delivered as posted interrupts
iomem= Disable strict checking of access to MMIO memory
strict regions from userspace.
relaxed
- iommu= [X86]
+ iommu= [X86,EARLY]
+
off
+ Don't initialize and use any kind of IOMMU.
+
force
+ Force the use of the hardware IOMMU even when
+ it is not actually needed (e.g. because < 3 GB
+ memory).
+
noforce
+ Don't force hardware IOMMU usage when it is not
+ needed. (default).
+
biomerge
panic
nopanic
merge
nomerge
+
soft
- pt [X86]
- nopt [X86]
- nobypass [PPC/POWERNV]
+ Use software bounce buffering (SWIOTLB) (default for
+ Intel machines). This can be used to prevent the usage
+ of an available hardware IOMMU.
+
+ [X86]
+ pt
+ [X86]
+ nopt
+ [PPC/POWERNV]
+ nobypass
Disable IOMMU bypass, using IOMMU for PCI devices.
- iommu.forcedac= [ARM64, X86] Control IOVA allocation for PCI devices.
+ [X86]
+ AMD Gart HW IOMMU-specific options:
+
+ <size>
+ Set the size of the remapping area in bytes.
+
+ allowed
+ Overwrite iommu off workarounds for specific chipsets
+
+ fullflush
+ Flush IOMMU on each allocation (default).
+
+ nofullflush
+ Don't use IOMMU fullflush.
+
+ memaper[=<order>]
+ Allocate an own aperture over RAM with size
+ 32MB<<order. (default: order=1, i.e. 64MB)
+
+ merge
+ Do scatter-gather (SG) merging. Implies "force"
+ (experimental).
+
+ nomerge
+ Don't do scatter-gather (SG) merging.
+
+ noaperture
+ Ask the IOMMU not to touch the aperture for AGP.
+
+ noagp
+ Don't initialize the AGP driver and use full aperture.
+
+ panic
+ Always panic when IOMMU overflows.
+
+ iommu.forcedac= [ARM64,X86,EARLY] Control IOVA allocation for PCI devices.
Format: { "0" | "1" }
0 - Try to allocate a 32-bit DMA address first, before
falling back to the full range if needed.
@@ -2144,7 +2653,7 @@
forcing Dual Address Cycle for PCI cards supporting
greater than 32-bit addressing.
- iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour
+ iommu.strict= [ARM64,X86,S390,EARLY] Configure TLB invalidation behaviour
Format: { "0" | "1" }
0 - Lazy mode.
Request that DMA unmap operations use deferred
@@ -2160,7 +2669,7 @@
legacy driver-specific options takes precedence.
iommu.passthrough=
- [ARM64, X86] Configure DMA to bypass the IOMMU by default.
+ [ARM64,X86,EARLY] Configure DMA to bypass the IOMMU by default.
Format: { "0" | "1" }
0 - Use IOMMU translation for DMA.
1 - Bypass the IOMMU for DMA.
@@ -2170,7 +2679,7 @@
See comment before marvel_specify_io7 in
arch/alpha/kernel/core_marvel.c.
- io_delay= [X86] I/O delay method
+ io_delay= [X86,EARLY] I/O delay method
0x80
Standard port 0x80 based delay
0xed
@@ -2183,37 +2692,61 @@
ip= [IP_PNP]
See Documentation/admin-guide/nfs/nfsroot.rst.
- ipcmni_extend [KNL] Extend the maximum number of unique System V
+ ipcmni_extend [KNL,EARLY] Extend the maximum number of unique System V
IPC identifiers from 32,768 to 16,777,216.
+ ipe.enforce= [IPE]
+ Format: <bool>
+ Determine whether IPE starts in permissive (0) or
+ enforce (1) mode. The default is enforce.
+
+ ipe.success_audit=
+ [IPE]
+ Format: <bool>
+ Start IPE with success auditing enabled, emitting
+ an audit event when a binary is allowed. The default
+ is 0.
+
irqaffinity= [SMP] Set the default irq affinity mask
The argument is a cpu list, as described above.
irqchip.gicv2_force_probe=
- [ARM, ARM64]
+ [ARM,ARM64,EARLY]
Format: <bool>
Force the kernel to look for the second 4kB page
of a GICv2 controller even if the memory range
exposed by the device tree is too small.
irqchip.gicv3_nolpi=
- [ARM, ARM64]
+ [ARM,ARM64,EARLY]
Force the kernel to ignore the availability of
LPIs (and by consequence ITSs). Intended for system
that use the kernel as a bootloader, and thus want
to let secondary kernels in charge of setting up
LPIs.
- irqchip.gicv3_pseudo_nmi= [ARM64]
+ irqchip.gicv3_pseudo_nmi= [ARM64,EARLY]
Enables support for pseudo-NMIs in the kernel. This
requires the kernel to be built with
CONFIG_ARM64_PSEUDO_NMI.
+ irqchip.riscv_imsic_noipi
+ [RISC-V,EARLY]
+ Force the kernel to not use IMSIC software injected MSIs
+ as IPIs. Intended for system where IMSIC is trap-n-emulated,
+ and thus want to reduce MMIO traps when triggering IPIs
+ to multiple harts.
+
irqfixup [HW]
When an interrupt is not handled search all handlers
for it. Intended to get systems with badly broken
firmware running.
+ irqhandler.duration_warn_us= [KNL]
+ Warn if an IRQ handler exceeds the specified duration
+ threshold in microseconds. Useful for identifying
+ long-running IRQs in the system.
+
irqpoll [HW]
When an interrupt is not handled search all handlers
for it. Also check all handlers each timer
@@ -2231,7 +2764,9 @@
specified in the flag list (default: domain):
nohz
- Disable the tick when a single task runs.
+ Disable the tick when a single task runs as well as
+ disabling other kernel noises like having RCU callbacks
+ offloaded. This is equivalent to the nohz_full parameter.
A residual 1Hz tick is offloaded to workqueues, which you
need to affine to housekeeping through the global
@@ -2290,7 +2825,13 @@
Provide an override to the IOAPIC-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table.
By default, PCI segment is 0, and can be omitted.
- For example:
+
+ For example, to map IOAPIC-ID decimal 10 to
+ PCI segment 0x1 and PCI device 00:14.0,
+ write the parameter as:
+ ivrs_ioapic=10@0001:00:14.0
+
+ Deprecated formats:
* To map IOAPIC-ID decimal 10 to PCI device 00:14.0
write the parameter as:
ivrs_ioapic[10]=00:14.0
@@ -2302,7 +2843,13 @@
Provide an override to the HPET-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table.
By default, PCI segment is 0, and can be omitted.
- For example:
+
+ For example, to map HPET-ID decimal 10 to
+ PCI segment 0x1 and PCI device 00:14.0,
+ write the parameter as:
+ ivrs_hpet=10@0001:00:14.0
+
+ Deprecated formats:
* To map HPET-ID decimal 0 to PCI device 00:14.0
write the parameter as:
ivrs_hpet[0]=00:14.0
@@ -2313,33 +2860,39 @@
ivrs_acpihid [HW,X86-64]
Provide an override to the ACPI-HID:UID<->DEVICE-ID
mapping provided in the IVRS ACPI table.
+ By default, PCI segment is 0, and can be omitted.
For example, to map UART-HID:UID AMD0020:0 to
PCI segment 0x1 and PCI device ID 00:14.5,
write the parameter as:
- ivrs_acpihid[0001:00:14.5]=AMD0020:0
+ ivrs_acpihid=AMD0020:0@0001:00:14.5
- By default, PCI segment is 0, and can be omitted.
- For example, PCI device 00:14.5 write the parameter as:
+ Deprecated formats:
+ * To map UART-HID:UID AMD0020:0 to PCI segment is 0,
+ PCI device ID 00:14.5, write the parameter as:
ivrs_acpihid[00:14.5]=AMD0020:0
+ * To map UART-HID:UID AMD0020:0 to PCI segment 0x1 and
+ PCI device ID 00:14.5, write the parameter as:
+ ivrs_acpihid[0001:00:14.5]=AMD0020:0
js= [HW,JOY] Analog joystick
See Documentation/input/joydev/joystick.rst.
- nokaslr [KNL]
- When CONFIG_RANDOMIZE_BASE is set, this disables
- kernel and module base offset ASLR (Address Space
- Layout Randomization).
-
kasan_multi_shot
[KNL] Enforce KASAN (Kernel Address Sanitizer) to print
report on every invalid memory access. Without this
parameter KASAN will print report only for the first
invalid access.
- keepinitrd [HW,ARM]
+ keep_bootcon [KNL,EARLY]
+ Do not unregister boot console at start. This is only
+ useful for debugging when something happens in the window
+ between unregistering the boot console and initializing
+ the real console.
+
+ keepinitrd [HW,ARM] See retain_initrd.
- kernelcore= [KNL,X86,IA-64,PPC]
+ kernelcore= [KNL,X86,PPC,EARLY]
Format: nn[KMGTPE] | nn% | "mirror"
This parameter specifies the amount of memory usable by
the kernel for non-movable allocations. The requested
@@ -2364,7 +2917,7 @@
for Movable pages. "nn[KMGTPE]", "nn%", and "mirror"
are exclusive, so you cannot specify multiple forms.
- kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port.
+ kgdbdbgp= [KGDB,HW,EARLY] kgdb over EHCI usb debug port.
Format: <Controller#>[,poll interval]
The controller # is the number of the ehci usb debug
port as it is probed via PCI. The poll interval is
@@ -2385,7 +2938,7 @@
kms, kbd format: kms,kbd
kms, kbd and serial format: kms,kbd,<ser_dev>[,baud]
- kgdboc_earlycon= [KGDB,HW]
+ kgdboc_earlycon= [KGDB,HW,EARLY]
If the boot console provides the ability to read
characters and can work in polling mode, you can use
this parameter to tell kgdb to use it as a backend
@@ -2400,14 +2953,39 @@
blank and the first boot console that implements
read() will be picked.
- kgdbwait [KGDB] Stop kernel execution and enter the
+ kgdbwait [KGDB,EARLY] Stop kernel execution and enter the
kernel debugger at the earliest opportunity.
+ kho= [KEXEC,EARLY]
+ Format: { "0" | "1" | "off" | "on" | "y" | "n" }
+ Enables or disables Kexec HandOver.
+ "0" | "off" | "n" - kexec handover is disabled
+ "1" | "on" | "y" - kexec handover is enabled
+
+ kho_scratch= [KEXEC,EARLY]
+ Format: ll[KMG],mm[KMG],nn[KMG] | nn%
+ Defines the size of the KHO scratch region. The KHO
+ scratch regions are physically contiguous memory
+ ranges that can only be used for non-kernel
+ allocations. That way, even when memory is heavily
+ fragmented with handed over memory, the kexeced
+ kernel will always have enough contiguous ranges to
+ bootstrap itself.
+
+ It is possible to specify the exact amount of
+ memory in the form of "ll[KMG],mm[KMG],nn[KMG]"
+ where the first parameter defines the size of a low
+ memory scratch area, the second parameter defines
+ the size of a global scratch area and the third
+ parameter defines the size of additional per-node
+ scratch areas. The form "nn%" defines scale factor
+ (in percents) of memory that was used during boot.
+
kmac= [MIPS] Korina ethernet MAC address.
Configure the RouterBoard 532 series on-chip
Ethernet adapter MAC address.
- kmemleak= [KNL] Boot-time kmemleak enable/disable
+ kmemleak= [KNL,EARLY] Boot-time kmemleak enable/disable
Valid arguments: on, off
Default: on
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
@@ -2426,8 +3004,8 @@
See also Documentation/trace/kprobetrace.rst "Kernel
Boot Parameter" section.
- kpti= [ARM64] Control page table isolation of user
- and kernel address spaces.
+ kpti= [ARM64,EARLY] Control page table isolation of
+ user and kernel address spaces.
Default: enabled on cores which need mitigation.
0: force disabled
1: force enabled
@@ -2466,6 +3044,23 @@
Default is Y (on).
+ kvm.enable_virt_at_load=[KVM,ARM64,LOONGARCH,MIPS,RISCV,X86]
+ If enabled, KVM will enable virtualization in hardware
+ when KVM is loaded, and disable virtualization when KVM
+ is unloaded (if KVM is built as a module).
+
+ If disabled, KVM will dynamically enable and disable
+ virtualization on-demand when creating and destroying
+ VMs, i.e. on the 0=>1 and 1=>0 transitions of the
+ number of VMs.
+
+ Enabling virtualization at module load avoids potential
+ latency for creation of the 0=>1 VM, as KVM serializes
+ virtualization enabling across all online CPUs. The
+ "cost" of enabling virtualization when KVM is loaded,
+ is that doing so may interfere with using out-of-tree
+ hypervisors that want to "own" virtualization hardware.
+
kvm.enable_vmware_backdoor=[KVM] Support VMware backdoor PV interface.
Default is false (don't support).
@@ -2495,45 +3090,95 @@
If the value is 0 (the default), KVM will pick a period based
on the ratio, such that a page is zapped after 1 hour on average.
- kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM.
- Default is 1 (enabled)
-
- kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU)
- for all guests.
- Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
+ kvm-amd.nested= [KVM,AMD] Control nested virtualization feature in
+ KVM/SVM. Default is 1 (enabled).
+
+ kvm-amd.npt= [KVM,AMD] Control KVM's use of Nested Page Tables,
+ a.k.a. Two-Dimensional Page Tables. Default is 1
+ (enabled). Disable by KVM if hardware lacks support
+ for NPT.
+
+ kvm-amd.ciphertext_hiding_asids=
+ [KVM,AMD] Ciphertext hiding prevents disallowed accesses
+ to SNP private memory from reading ciphertext. Instead,
+ reads will see constant default values (0xff).
+
+ If ciphertext hiding is enabled, the joint SEV-ES and
+ SEV-SNP ASID space is partitioned into separate SEV-ES
+ and SEV-SNP ASID ranges, with the SEV-SNP range being
+ [1..max_snp_asid] and the SEV-ES range being
+ (max_snp_asid..min_sev_asid), where min_sev_asid is
+ enumerated by CPUID.0x.8000_001F[EDX].
+
+ A non-zero value enables SEV-SNP ciphertext hiding and
+ adjusts the ASID ranges for SEV-ES and SEV-SNP guests.
+ KVM caps the number of SEV-SNP ASIDs at the maximum
+ possible value, e.g. specifying -1u will assign all
+ joint SEV-ES and SEV-SNP ASIDs to SEV-SNP. Note,
+ assigning all joint ASIDs to SEV-SNP, i.e. configuring
+ max_snp_asid == min_sev_asid-1, will effectively make
+ SEV-ES unusable.
kvm-arm.mode=
- [KVM,ARM] Select one of KVM/arm64's modes of operation.
+ [KVM,ARM,EARLY] Select one of KVM/arm64's modes of
+ operation.
none: Forcefully disable KVM.
nvhe: Standard nVHE-based mode, without support for
protected guests.
- protected: nVHE-based mode with support for guests whose
- state is kept private from the host.
+ protected: Mode with support for guests whose state is
+ kept private from the host, using VHE or
+ nVHE depending on HW support.
+
+ nested: VHE-based mode with support for nested
+ virtualization. Requires at least ARMv8.4
+ hardware (with FEAT_NV2).
Defaults to VHE/nVHE based on hardware support. Setting
mode to "protected" will disable kexec and hibernation
- for the host.
+ for the host. To force nVHE on VHE hardware, add
+ "arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" to the
+ command-line.
+ "nested" is experimental and should be used with
+ extreme caution.
kvm-arm.vgic_v3_group0_trap=
- [KVM,ARM] Trap guest accesses to GICv3 group-0
+ [KVM,ARM,EARLY] Trap guest accesses to GICv3 group-0
system registers
kvm-arm.vgic_v3_group1_trap=
- [KVM,ARM] Trap guest accesses to GICv3 group-1
+ [KVM,ARM,EARLY] Trap guest accesses to GICv3 group-1
system registers
kvm-arm.vgic_v3_common_trap=
- [KVM,ARM] Trap guest accesses to GICv3 common
+ [KVM,ARM,EARLY] Trap guest accesses to GICv3 common
system registers
kvm-arm.vgic_v4_enable=
- [KVM,ARM] Allow use of GICv4 for direct injection of
- LPIs.
+ [KVM,ARM,EARLY] Allow use of GICv4 for direct
+ injection of LPIs.
+
+ kvm-arm.wfe_trap_policy=
+ [KVM,ARM] Control when to set WFE instruction trap for
+ KVM VMs. Traps are allowed but not guaranteed by the
+ CPU architecture.
+
+ trap: set WFE instruction trap
- kvm_cma_resv_ratio=n [PPC]
+ notrap: clear WFE instruction trap
+
+ kvm-arm.wfi_trap_policy=
+ [KVM,ARM] Control when to set WFI instruction trap for
+ KVM VMs. Traps are allowed but not guaranteed by the
+ CPU architecture.
+
+ trap: set WFI instruction trap
+
+ notrap: clear WFI instruction trap
+
+ kvm_cma_resv_ratio=n [PPC,EARLY]
Reserves given percentage from system memory area for
contiguous memory allocation for KVM hash pagetable
allocation.
@@ -2541,30 +3186,33 @@
Format: <integer>
Default: 5
- kvm-intel.ept= [KVM,Intel] Disable extended page tables
- (virtualized MMU) support on capable Intel chips.
- Default is 1 (enabled)
+ kvm-intel.ept= [KVM,Intel] Control KVM's use of Extended Page Tables,
+ a.k.a. Two-Dimensional Page Tables. Default is 1
+ (enabled). Disable by KVM if hardware lacks support
+ for EPT.
kvm-intel.emulate_invalid_guest_state=
- [KVM,Intel] Disable emulation of invalid guest state.
- Ignored if kvm-intel.enable_unrestricted_guest=1, as
- guest state is never invalid for unrestricted guests.
- This param doesn't apply to nested guests (L2), as KVM
- never emulates invalid L2 guest state.
- Default is 1 (enabled)
+ [KVM,Intel] Control whether to emulate invalid guest
+ state. Ignored if kvm-intel.enable_unrestricted_guest=1,
+ as guest state is never invalid for unrestricted
+ guests. This param doesn't apply to nested guests (L2),
+ as KVM never emulates invalid L2 guest state.
+ Default is 1 (enabled).
kvm-intel.flexpriority=
- [KVM,Intel] Disable FlexPriority feature (TPR shadow).
- Default is 1 (enabled)
+ [KVM,Intel] Control KVM's use of FlexPriority feature
+ (TPR shadow). Default is 1 (enabled). Disable by KVM if
+ hardware lacks support for it.
kvm-intel.nested=
- [KVM,Intel] Enable VMX nesting (nVMX).
- Default is 0 (disabled)
+ [KVM,Intel] Control nested virtualization feature in
+ KVM/VMX. Default is 1 (enabled).
kvm-intel.unrestricted_guest=
- [KVM,Intel] Disable unrestricted guest feature
- (virtualized real and unpaged mode) on capable
- Intel chips. Default is 1 (enabled)
+ [KVM,Intel] Control KVM's use of unrestricted guest
+ feature (virtualized real and unpaged mode). Default
+ is 1 (enabled). Disable by KVM if EPT is disabled or
+ hardware lacks support for it.
kvm-intel.vmentry_l1d_flush=[KVM,Intel] Mitigation for L1 Terminal Fault
CVE-2018-3620.
@@ -2578,11 +3226,12 @@
Default is cond (do L1 cache flush in specific instances)
- kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification
- feature (tagged TLBs) on capable Intel chips.
- Default is 1 (enabled)
+ kvm-intel.vpid= [KVM,Intel] Control KVM's use of Virtual Processor
+ Identification feature (tagged TLBs). Default is 1
+ (enabled). Disable by KVM if hardware lacks support
+ for it.
- l1d_flush= [X86,INTEL]
+ l1d_flush= [X86,INTEL,EARLY]
Control mitigation for L1D based snooping vulnerability.
Certain CPUs are vulnerable to an exploit against CPU
@@ -2599,7 +3248,7 @@
on - enable the interface for the mitigation
- l1tf= [X86] Control mitigation of the L1TF vulnerability on
+ l1tf= [X86,EARLY] Control mitigation of the L1TF vulnerability on
affected CPUs
The kernel PTE inversion protection is unconditionally
@@ -2668,7 +3317,7 @@
l3cr= [PPC]
- lapic [X86-32,APIC] Enable the local APIC even if BIOS
+ lapic [X86-32,APIC,EARLY] Enable the local APIC even if BIOS
disabled it.
lapic= [X86,APIC] Do not use TSC deadline
@@ -2676,7 +3325,7 @@
back to the programmable timer unit in the LAPIC.
Format: notscdeadline
- lapic_timer_c2_ok [X86,APIC] trust the local apic timer
+ lapic_timer_c2_ok [X86,APIC,EARLY] trust the local apic timer
in C2 power state.
libata.dma= [LIBATA] DMA control
@@ -2771,11 +3420,16 @@
* max_sec_lba48: Set or clear transfer size limit to
65535 sectors.
+ * external: Mark port as external (hotplug-capable).
+
* [no]lpm: Enable or disable link power management.
* [no]setxfer: Indicate if transfer speed mode setting
should be skipped.
+ * [no]fua: Disable or enable FUA (Force Unit Access)
+ support for devices supporting this feature.
+
* dump_id: Dump IDENTIFY data.
* disable: Disable this device.
@@ -2797,7 +3451,7 @@
lockd.nlm_udpport=M [NFS] Assign UDP port.
Format: <integer>
- lockdown= [SECURITY]
+ lockdown= [SECURITY,EARLY]
{ integrity | confidentiality }
Enable the kernel lockdown feature. If set to
integrity, kernel features that allow userland to
@@ -2806,6 +3460,38 @@
to extract confidential information from the kernel
are also disabled.
+ locktorture.acq_writer_lim= [KNL]
+ Set the time limit in jiffies for a lock
+ acquisition. Acquisitions exceeding this limit
+ will result in a splat once they do complete.
+
+ locktorture.bind_readers= [KNL]
+ Specify the list of CPUs to which the readers are
+ to be bound.
+
+ locktorture.bind_writers= [KNL]
+ Specify the list of CPUs to which the writers are
+ to be bound.
+
+ locktorture.call_rcu_chains= [KNL]
+ Specify the number of self-propagating call_rcu()
+ chains to set up. These are used to ensure that
+ there is a high probability of an RCU grace period
+ in progress at any given time. Defaults to 0,
+ which disables these call_rcu() chains.
+
+ locktorture.long_hold= [KNL]
+ Specify the duration in milliseconds for the
+ occasional long-duration lock hold time. Defaults
+ to 100 milliseconds. Select 0 to disable.
+
+ locktorture.nested_locks= [KNL]
+ Specify the maximum lock nesting depth that
+ locktorture is to exercise, up to a limit of 8
+ (MAX_NESTED_LOCKS). Specify zero to disable.
+ Note that this parameter is ineffective on types
+ of locks that do not support nested acquisition.
+
locktorture.nreaders_stress= [KNL]
Set the number of locking read-acquisition kthreads.
Defaults to being automatically set based on the
@@ -2821,6 +3507,25 @@
Set time (s) between CPU-hotplug operations, or
zero to disable CPU-hotplug testing.
+ locktorture.rt_boost= [KNL]
+ Do periodic testing of real-time lock priority
+ boosting. Select 0 to disable, 1 to boost
+ only rt_mutex, and 2 to boost unconditionally.
+ Defaults to 2, which might seem to be an
+ odd choice, but which should be harmless for
+ non-real-time spinlocks, due to their disabling
+ of preemption. Note that non-realtime mutexes
+ disable boosting.
+
+ locktorture.rt_boost_factor= [KNL]
+ Number that determines how often and for how
+ long priority boosting is exercised. This is
+ scaled down by the number of writers, so that the
+ number of boosts per unit time remains roughly
+ constant as the number of writers increases.
+ On the other hand, the duration of each boost
+ increases with the number of writers.
+
locktorture.shuffle_interval= [KNL]
Set task-shuffle interval (jiffies). Shuffling
tasks allows some CPUs to go into dyntick-idle
@@ -2846,10 +3551,15 @@
locktorture.verbose= [KNL]
Enable additional printk() statements.
+ locktorture.writer_fifo= [KNL]
+ Run the write-side locktorture kthreads at
+ sched_set_fifo() real-time priority.
+
logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver
Format: <irq>
- loglevel= All Kernel Messages with a loglevel smaller than the
+ loglevel= [KNL,EARLY]
+ All Kernel Messages with a loglevel smaller than the
console loglevel will be printed to the console. It can
also be changed with klogd or other programs. The
loglevels are defined as follows:
@@ -2863,13 +3573,15 @@
6 (KERN_INFO) informational
7 (KERN_DEBUG) debug-level messages
- log_buf_len=n[KMG] Sets the size of the printk ring buffer,
- in bytes. n must be a power of two and greater
- than the minimal size. The minimal size is defined
- by LOG_BUF_SHIFT kernel config parameter. There is
- also CONFIG_LOG_CPU_MAX_BUF_SHIFT config parameter
- that allows to increase the default size depending on
- the number of CPUs. See init/Kconfig for more details.
+ log_buf_len=n[KMG] [KNL,EARLY]
+ Sets the size of the printk ring buffer, in bytes.
+ n must be a power of two and greater than the
+ minimal size. The minimal size is defined by
+ LOG_BUF_SHIFT kernel config parameter. There
+ is also CONFIG_LOG_CPU_MAX_BUF_SHIFT config
+ parameter that allows to increase the default size
+ depending on the number of CPUs. See init/Kconfig
+ for more details.
logo.nologo [FB] Disables display of the built-in Linux logo.
This may be used to provide more screen space for
@@ -2907,27 +3619,17 @@
unlikely, in the extreme case this might damage your
hardware.
- ltpc= [NET]
- Format: <io>,<irq>,<dma>
-
lsm.debug [SECURITY] Enable LSM initialization debugging output.
lsm=lsm1,...,lsmN
[SECURITY] Choose order of LSM initialization. This
overrides CONFIG_LSM, and the "security=" parameter.
- machvec= [IA-64] Force the use of a particular machine-vector
- (machvec) in a generic kernel.
- Example: machvec=hpzx1
-
machtype= [Loongson] Share the same kernel image file between
different yeeloong laptops.
Example: machtype=lemote-yeeloong-2f-7inch
- max_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory greater
- than or equal to this physical address is ignored.
-
- maxcpus= [SMP] Maximum number of processors that an SMP kernel
+ maxcpus= [SMP,EARLY] Maximum number of processors that an SMP kernel
will bring up during bootup. maxcpus=n : n >= 0 limits
the kernel to bring up 'n' processors. Surely after
bootup you can bring up the other plugged cpu by executing
@@ -2943,9 +3645,77 @@
devices can be requested on-demand with the
/dev/loop-control interface.
- mce [X86-32] Machine Check Exception
+ mce= [X86-{32,64}]
+
+ Please see Documentation/arch/x86/x86_64/machinecheck.rst for sysfs runtime tunables.
+
+ off
+ disable machine check
+
+ no_cmci
+ disable CMCI(Corrected Machine Check Interrupt) that
+ Intel processor supports. Usually this disablement is
+ not recommended, but it might be handy if your
+ hardware is misbehaving.
+
+ Note that you'll get more problems without CMCI than
+ with due to the shared banks, i.e. you might get
+ duplicated error logs.
+
+ dont_log_ce
+ don't make logs for corrected errors. All events
+ reported as corrected are silently cleared by OS. This
+ option will be useful if you have no interest in any
+ of corrected errors.
+
+ ignore_ce
+ disable features for corrected errors, e.g.
+ polling timer and CMCI. All events reported as
+ corrected are not cleared by OS and remained in its
+ error banks.
+
+ Usually this disablement is not recommended, however
+ if there is an agent checking/clearing corrected
+ errors (e.g. BIOS or hardware monitoring
+ applications), conflicting with OS's error handling,
+ and you cannot deactivate the agent, then this option
+ will be a help.
+
+ no_lmce
+ do not opt-in to Local MCE delivery. Use legacy method
+ to broadcast MCEs.
+
+ bootlog
+ enable logging of machine checks left over from
+ booting. Disabled by default on AMD Fam10h and older
+ because some BIOS leave bogus ones.
+
+ If your BIOS doesn't do that it's a good idea to
+ enable though to make sure you log even machine check
+ events that result in a reboot. On Intel systems it is
+ enabled by default.
+
+ nobootlog
+ disable boot machine check logging.
+
+ monarchtimeout (number)
+ sets the time in us to wait for other CPUs on machine
+ checks. 0 to disable.
+
+ bios_cmci_threshold
+ don't overwrite the bios-set CMCI threshold. This boot
+ option prevents Linux from overwriting the CMCI
+ threshold set by the bios. Without this option, Linux
+ always sets the CMCI threshold to 1. Enabling this may
+ make memory predictive failure analysis less effective
+ if the bios sets thresholds for memory errors since we
+ will not see details for all errors.
+
+ recovery
+ force-enable recoverable machine check code paths
+
+ Everything else is in sysfs now.
- mce=option [X86-64] See Documentation/x86/x86_64/boot-options.rst
md= [HW] RAID subsystems devices and level
See Documentation/admin-guide/md.rst.
@@ -2954,7 +3724,7 @@
Format: <first>,<last>
Specifies range of consoles to be captured by the MDA.
- mds= [X86,INTEL]
+ mds= [X86,INTEL,EARLY]
Control mitigation for the Micro-architectural Data
Sampling (MDS) vulnerability.
@@ -2986,11 +3756,12 @@
For details see: Documentation/admin-guide/hw-vuln/mds.rst
- mem=nn[KMG] [HEXAGON] Set the memory size.
+ mem=nn[KMG] [HEXAGON,EARLY] Set the memory size.
Must be specified, otherwise memory size will be 0.
- mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
- Amount of memory to be used in cases as follows:
+ mem=nn[KMG] [KNL,BOOT,EARLY] Force usage of a specific amount
+ of memory Amount of memory to be used in cases
+ as follows:
1 for test;
2 when the kernel is not able to see the whole system memory;
@@ -3014,8 +3785,8 @@
if system memory of hypervisor is not sufficient.
mem=nn[KMG]@ss[KMG]
- [ARM,MIPS] - override the memory layout reported by
- firmware.
+ [ARM,MIPS,EARLY] - override the memory layout
+ reported by firmware.
Define a memory region of size nn[KMG] starting at
ss[KMG].
Multiple different regions can be specified with
@@ -3024,28 +3795,28 @@
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
- memblock=debug [KNL] Enable memblock debug messages.
+ memblock=debug [KNL,EARLY] Enable memblock debug messages.
memchunk=nn[KMG]
[KNL,SH] Allow user to override the default size for
per-device physically contiguous DMA buffers.
- memhp_default_state=online/offline
+ memhp_default_state=online/offline/online_kernel/online_movable
[KNL] Set the initial state for the memory hotplug
onlining policy. If not specified, the default value is
set according to the
- CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel config
- option.
+ CONFIG_MHP_DEFAULT_ONLINE_TYPE kernel config
+ options.
See Documentation/admin-guide/mm/memory-hotplug.rst.
- memmap=exactmap [KNL,X86] Enable setting of an exact
+ memmap=exactmap [KNL,X86,EARLY] Enable setting of an exact
E820 memory map, as specified by the user.
Such memmap=exactmap lines can be constructed based on
BIOS output or other requirements. See the memmap=nn@ss
option description.
memmap=nn[KMG]@ss[KMG]
- [KNL, X86, MIPS, XTENSA] Force usage of a specific region of memory.
+ [KNL, X86,MIPS,XTENSA,EARLY] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
If @ss[KMG] is omitted, it is equivalent to mem=nn[KMG],
which limits max address to nn[KMG].
@@ -3055,11 +3826,11 @@
memmap=100M@2G,100M#3G,1G!1024G
memmap=nn[KMG]#ss[KMG]
- [KNL,ACPI] Mark specific memory as ACPI data.
+ [KNL,ACPI,EARLY] Mark specific memory as ACPI data.
Region of memory to be marked is from ss to ss+nn.
memmap=nn[KMG]$ss[KMG]
- [KNL,ACPI] Mark specific memory as reserved.
+ [KNL,ACPI,EARLY] Mark specific memory as reserved.
Region of memory to be reserved is from ss to ss+nn.
Example: Exclude memory from 0x18690000-0x1869ffff
memmap=64K$0x18690000
@@ -3069,14 +3840,14 @@
like Grub2, otherwise '$' and the following number
will be eaten.
- memmap=nn[KMG]!ss[KMG]
+ memmap=nn[KMG]!ss[KMG,EARLY]
[KNL,X86] Mark specific memory as protected.
Region of memory to be used, from ss to ss+nn.
The memory region may be marked as e820 type 12 (0xc)
and is NVDIMM or ADR memory.
memmap=<size>%<offset>-<oldtype>+<newtype>
- [KNL,ACPI] Convert memory within the specified region
+ [KNL,ACPI,EARLY] Convert memory within the specified region
from <oldtype> to <newtype>. If "-<oldtype>" is left
out, the whole region will be marked as <newtype>,
even if previously unavailable. If "+<newtype>" is left
@@ -3084,25 +3855,25 @@
specified as e820 types, e.g., 1 = RAM, 2 = reserved,
3 = ACPI, 12 = PRAM.
- memory_corruption_check=0/1 [X86]
+ memory_corruption_check=0/1 [X86,EARLY]
Some BIOSes seem to corrupt the first 64k of
memory when doing things like suspend/resume.
Setting this option will scan the memory
looking for corruption. Enabling this will
both detect corruption and prevent the kernel
from using the memory being corrupted.
- However, its intended as a diagnostic tool; if
+ However, it's intended as a diagnostic tool; if
repeatable BIOS-originated corruption always
affects the same memory, you can use memmap=
to prevent the kernel from using that memory.
- memory_corruption_check_size=size [X86]
+ memory_corruption_check_size=size [X86,EARLY]
By default it checks for corruption in the low
64k, making this memory unavailable for normal
use. Use this parameter to scan for
corruption in more or less memory.
- memory_corruption_check_period=seconds [X86]
+ memory_corruption_check_period=seconds [X86,EARLY]
By default it checks for corruption every 60
seconds. Use this parameter to check at some
other rate. 0 disables periodic checking.
@@ -3126,7 +3897,7 @@
Note that even when enabled, there are a few cases where
the feature is not effective.
- memtest= [KNL,X86,ARM,M68K,PPC,RISCV] Enable memtest
+ memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable memtest
Format: <integer>
default : 0 <disable>
Specifies the number of memtest passes to be
@@ -3138,9 +3909,7 @@
mem_encrypt= [X86-64] AMD Secure Memory Encryption (SME) control
Valid arguments: on, off
- Default (depends on kernel configuration option):
- on (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y)
- off (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n)
+ Default: off
mem_encrypt=on: Activate SME
mem_encrypt=off: Do not activate SME
@@ -3153,13 +3922,6 @@
deep - Suspend-To-RAM or equivalent (if supported)
See Documentation/admin-guide/pm/sleep-states.rst.
- meye.*= [HW] Set MotionEye Camera parameters
- See Documentation/admin-guide/media/meye.rst.
-
- mfgpt_irq= [IA-32] Specify the IRQ to use for the
- Multi-Function General Purpose Timers on AMD Geode
- platforms.
-
mfgptfix [X86-32] Fix MFGPT timers on AMD Geode platforms when
the BIOS has incorrectly applied a workaround. TinyBIOS
version 0.98 is known to be affected, 0.99 fixes the
@@ -3167,8 +3929,18 @@
mga= [HW,DRM]
- min_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory below this
- physical address is ignored.
+ microcode= [X86] Control the behavior of the microcode loader.
+ Available options, comma separated:
+
+ base_rev=X - with <X> with format: <u32>
+ Set the base microcode revision of each thread when in
+ debug mode.
+
+ dis_ucode_ldr: disable the microcode loader
+
+ force_minrev:
+ Enable or disable the microcode minimal revision
+ enforcement for the runtime microcode loader.
mini2440= [ARM,HW,KNL]
Format:[0..2][b][c][t]
@@ -3192,33 +3964,42 @@
https://repo.or.cz/w/linux-2.6/mini2440.git
mitigations=
- [X86,PPC,S390,ARM64] Control optional mitigations for
+ [X86,PPC,S390,ARM64,EARLY] Control optional mitigations for
CPU vulnerabilities. This is a set of curated,
arch-independent options, each of which is an
aggregation of existing arch-specific options.
+ Note, "mitigations" is supported if and only if the
+ kernel was built with CPU_MITIGATIONS=y.
+
off
Disable all optional CPU mitigations. This
improves system performance, but it may also
expose users to several CPU vulnerabilities.
- Equivalent to: nopti [X86,PPC]
- if nokaslr then kpti=0 [ARM64]
- nospectre_v1 [X86,PPC]
- nobp=0 [S390]
- nospectre_v2 [X86,PPC,S390,ARM64]
- spectre_v2_user=off [X86]
- spec_store_bypass_disable=off [X86,PPC]
- ssbd=force-off [ARM64]
- nospectre_bhb [ARM64]
+ Equivalent to: if nokaslr then kpti=0 [ARM64]
+ gather_data_sampling=off [X86]
+ indirect_target_selection=off [X86]
+ kvm.nx_huge_pages=off [X86]
l1tf=off [X86]
mds=off [X86]
- tsx_async_abort=off [X86]
- kvm.nx_huge_pages=off [X86]
- srbds=off [X86,INTEL]
+ mmio_stale_data=off [X86]
no_entry_flush [PPC]
no_uaccess_flush [PPC]
- mmio_stale_data=off [X86]
+ nobp=0 [S390]
+ nopti [X86,PPC]
+ nospectre_bhb [ARM64]
+ nospectre_v1 [X86,PPC]
+ nospectre_v2 [X86,PPC,S390,ARM64]
+ reg_file_data_sampling=off [X86]
retbleed=off [X86]
+ spec_rstack_overflow=off [X86]
+ spec_store_bypass_disable=off [X86,PPC]
+ spectre_bhi=off [X86]
+ spectre_v2_user=off [X86]
+ srbds=off [X86,INTEL]
+ ssbd=force-off [ARM64]
+ tsx_async_abort=off [X86]
+ vmscape=off [X86]
Exceptions:
This does not have any effect on
@@ -3243,8 +4024,12 @@
mmio_stale_data=full,nosmt [X86]
retbleed=auto,nosmt [X86]
+ [X86] After one of the above options, additionally
+ supports attack-vector based controls as documented in
+ Documentation/admin-guide/hw-vuln/attack_vector_controls.rst
+
mminit_loglevel=
- [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
+ [KNL,EARLY] When CONFIG_DEBUG_MEMORY_INIT is set, this
parameter allows control of the logging verbosity for
the additional memory initialisation checks. A value
of 0 disables mminit logging and a level of 4 will
@@ -3252,7 +4037,7 @@
so loglevel=8 may also need to be specified.
mmio_stale_data=
- [X86,INTEL] Control mitigation for the Processor
+ [X86,INTEL,EARLY] Control mitigation for the Processor
MMIO Stale Data vulnerabilities.
Processor MMIO Stale Data is a class of
@@ -3285,6 +4070,13 @@
For details see:
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
+ <module>.async_probe[=<bool>] [KNL]
+ If no <bool> value is specified or if the value
+ specified is not a valid <bool>, enable asynchronous
+ probe on this module. Otherwise, enable/disable
+ asynchronous probe on this module as indicated by the
+ <bool> value. See also: module.async_probe
+
module.async_probe=<bool>
[KNL] When set to true, modules will use async probing
by default. To enable/disable async probing for a
@@ -3294,6 +4086,12 @@
specified, <module>.async_probe takes precedence for
the specific module.
+ module.enable_dups_trace
+ [KNL] When CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS is set,
+ this means that duplicate request_module() calls will
+ trigger a WARN_ON() instead of a pr_warn(). Note that
+ if MODULE_DEBUG_AUTOLOAD_DUPS_TRACE is set, WARN_ON()s
+ will always be issued and this option does nothing.
module.sig_enforce
[KNL] When CONFIG_MODULE_SIG is set, this means that
modules without (valid) signatures will fail to load.
@@ -3314,7 +4112,7 @@
mousedev.yres= [MOUSE] Vertical screen resolution, used for devices
reporting absolute coordinates, such as tablets
- movablecore= [KNL,X86,IA-64,PPC]
+ movablecore= [KNL,X86,PPC,EARLY]
Format: nn[KMGTPE] | nn%
This parameter is the complement to kernelcore=, it
specifies the amount of memory used for migratable
@@ -3325,7 +4123,7 @@
that the amount of memory usable for all allocations
is not too small.
- movable_node [KNL] Boot-time switch to make hotplugable memory
+ movable_node [KNL,EARLY] Boot-time switch to make hotplugable memory
NUMA nodes to be movable. This means that the memory
of such nodes will be usable only for movable
allocations which rules out almost all kernel
@@ -3340,26 +4138,25 @@
mtdparts= [MTD]
See drivers/mtd/parsers/cmdlinepart.c
- mtdset= [ARM]
- ARM/S3C2412 JIVE boot control
-
- See arch/arm/mach-s3c/mach-jive.c
-
mtouchusb.raw_coordinates=
[HW] Make the MicroTouch USB driver use raw coordinates
('y', default) or cooked coordinates ('n')
- mtrr_chunk_size=nn[KMG] [X86]
+ mtrr=debug [X86,EARLY]
+ Enable printing debug information related to MTRR
+ registers at boot time.
+
+ mtrr_chunk_size=nn[KMG,X86,EARLY]
used for mtrr cleanup. It is largest continuous chunk
that could hold holes aka. UC entries.
- mtrr_gran_size=nn[KMG] [X86]
+ mtrr_gran_size=nn[KMG,X86,EARLY]
Used for mtrr cleanup. It is granularity of mtrr block.
Default is 1.
Large value could prevent small alignment from
using up MTRRs.
- mtrr_spare_reg_nr=n [X86]
+ mtrr_spare_reg_nr=n [X86,EARLY]
Format: <integer>
Range: 0,7 : spare reg number
Default : 1
@@ -3390,14 +4187,13 @@
1 to enable accounting
Default value is 0.
- nfsaddrs= [NFS] Deprecated. Use ip= instead.
- See Documentation/admin-guide/nfs/nfsroot.rst.
-
- nfsroot= [NFS] nfs root filesystem for disk-less boxes.
- See Documentation/admin-guide/nfs/nfsroot.rst.
+ nfs.cache_getent=
+ [NFS] sets the pathname to the program which is used
+ to update the NFS client cache entries.
- nfsrootdebug [NFS] enable nfsroot debugging messages.
- See Documentation/admin-guide/nfs/nfsroot.rst.
+ nfs.cache_getent_timeout=
+ [NFS] sets the timeout after which an attempt to
+ update a cache entry is deemed to have failed.
nfs.callback_nr_threads=
[NFSv4] set the total number of threads that the
@@ -3408,17 +4204,12 @@
[NFS] set the TCP port on which the NFSv4 callback
channel should listen.
- nfs.cache_getent=
- [NFS] sets the pathname to the program which is used
- to update the NFS client cache entries.
-
- nfs.cache_getent_timeout=
- [NFS] sets the timeout after which an attempt to
- update a cache entry is deemed to have failed.
-
- nfs.idmap_cache_timeout=
- [NFS] set the maximum lifetime for idmapper cache
- entries.
+ nfs.delay_retrans=
+ [NFS] specifies the number of times the NFSv4 client
+ retries the request before returning an EAGAIN error,
+ after a reply of NFS4ERR_DELAY from the server.
+ Only applies if the softerr mount option is enabled,
+ and the specified value is >= 0.
nfs.enable_ino64=
[NFS] enable 64-bit inode numbers.
@@ -3427,6 +4218,10 @@
of returning the full 64-bit number.
The default is to return 64-bit inode numbers.
+ nfs.idmap_cache_timeout=
+ [NFS] set the maximum lifetime for idmapper cache
+ entries.
+
nfs.max_session_cb_slots=
[NFSv4.1] Sets the maximum number of session
slots the client will assign to the callback
@@ -3454,21 +4249,14 @@
will be autodetected by the client, and it will fall
back to using the idmapper.
To turn off this behaviour, set the value to '0'.
+
nfs.nfs4_unique_id=
[NFS4] Specify an additional fixed unique ident-
ification string that NFSv4 clients can insert into
their nfs_client_id4 string. This is typically a
UUID that is generated at system install time.
- nfs.send_implementation_id =
- [NFSv4.1] Send client implementation identification
- information in exchange_id requests.
- If zero, no implementation identification information
- will be sent.
- The default is to send the implementation identification
- information.
-
- nfs.recover_lost_locks =
+ nfs.recover_lost_locks=
[NFSv4] Attempt to recover locks that were lost due
to a lease timeout on the server. Please note that
doing this risks data corruption, since there are
@@ -3480,7 +4268,15 @@
The default parameter value of '0' causes the kernel
not to attempt recovery of lost locks.
- nfs4.layoutstats_timer =
+ nfs.send_implementation_id=
+ [NFSv4.1] Send client implementation identification
+ information in exchange_id requests.
+ If zero, no implementation identification information
+ will be sent.
+ The default is to send the implementation identification
+ information.
+
+ nfs4.layoutstats_timer=
[NFSv4.2] Change the rate at which the kernel sends
layoutstats to the pNFS metadata server.
@@ -3489,12 +4285,19 @@
driver. A non-zero value sets the minimum interval
in seconds between layoutstats transmissions.
- nfsd.inter_copy_offload_enable =
+ nfsd.inter_copy_offload_enable=
[NFSv4.2] When set to 1, the server will support
server-to-server copies for which this server is
the destination of the copy.
- nfsd.nfsd4_ssc_umount_timeout =
+ nfsd.nfs4_disable_idmapping=
+ [NFSv4] When set to the default of '1', the NFSv4
+ server will return only numeric uids and gids to
+ clients using auth_sys, and will accept numeric uids
+ and gids from such clients. This is intended to ease
+ migration from NFSv2/v3.
+
+ nfsd.nfsd4_ssc_umount_timeout=
[NFSv4.2] When used as the destination of a
server-to-server copy, knfsd temporarily mounts
the source server. It caches the mount in case
@@ -3502,13 +4305,14 @@
used for the number of milliseconds specified by
this parameter.
- nfsd.nfs4_disable_idmapping=
- [NFSv4] When set to the default of '1', the NFSv4
- server will return only numeric uids and gids to
- clients using auth_sys, and will accept numeric uids
- and gids from such clients. This is intended to ease
- migration from NFSv2/v3.
+ nfsaddrs= [NFS] Deprecated. Use ip= instead.
+ See Documentation/admin-guide/nfs/nfsroot.rst.
+
+ nfsroot= [NFS] nfs root filesystem for disk-less boxes.
+ See Documentation/admin-guide/nfs/nfsroot.rst.
+ nfsrootdebug [NFS] enable nfsroot debugging messages.
+ See Documentation/admin-guide/nfs/nfsroot.rst.
nmi_backtrace.backtrace_idle [KNL]
Dump stacks even of idle CPUs in response to an
@@ -3519,10 +4323,12 @@
Format: [state][,regs][,debounce][,die]
nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels
- Format: [panic,][nopanic,][num]
+ Format: [panic,][nopanic,][rNNN,][num]
Valid num: 0 or 1
0 - turn hardlockup detector in nmi_watchdog off
1 - turn hardlockup detector in nmi_watchdog on
+ rNNN - configure the watchdog with raw perf event 0xNNN
+
When panic is specified, panic when an NMI watchdog
timeout occurs (or 'nopanic' to not panic on an NMI
watchdog, if CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is set)
@@ -3538,10 +4344,22 @@
emulation library even if a 387 maths coprocessor
is present.
- no5lvl [X86-64] Disable 5-level paging mode. Forces
+ no4lvl [RISCV,EARLY] Disable 4-level and 5-level paging modes.
+ Forces kernel to use 3-level paging instead.
+
+ no5lvl [X86-64,RISCV,EARLY] Disable 5-level paging mode. Forces
kernel to use 4-level paging instead.
- nofsgsbase [X86] Disables FSGSBASE instructions.
+ noalign [KNL,ARM]
+
+ noapic [SMP,APIC,EARLY] Tells the kernel to not make use of any
+ IOAPICs that may be present in the system.
+
+ noapictimer [APIC,X86] Don't set up the APIC timer
+
+ noautogroup Disable scheduler automatic task group creation.
+
+ nocache [ARM,EARLY]
no_console_suspend
[HW] Never suspend the console
@@ -3558,48 +4376,14 @@
/sys/module/printk/parameters/console_suspend) to
turn on/off it dynamically.
- novmcoredd [KNL,KDUMP]
- Disable device dump. Device dump allows drivers to
- append dump data to vmcore so you can collect driver
- specified debug info. Drivers can append the data
- without any limit and this data is stored in memory,
- so this may cause significant memory stress. Disabling
- device dump can help save memory but the driver debug
- data will be no longer available. This parameter
- is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP
- is set.
-
- noaliencache [MM, NUMA, SLAB] Disables the allocation of alien
- caches in the slab allocator. Saves per-node memory,
- but will impact performance.
-
- noalign [KNL,ARM]
-
- noaltinstr [S390] Disables alternative instructions patching
- (CPU alternatives feature).
-
- noapic [SMP,APIC] Tells the kernel to not make use of any
- IOAPICs that may be present in the system.
-
- noautogroup Disable scheduler automatic task group creation.
-
- nocache [ARM]
+ no_debug_objects
+ [KNL,EARLY] Disable object debugging
nodsp [SH] Disable hardware DSP at boot time.
- noefi Disable EFI runtime services support.
-
- no_entry_flush [PPC] Don't flush the L1-D cache when entering the kernel.
-
- noexec [IA-64]
+ noefi [EFI,EARLY] Disable EFI runtime services support.
- nosmap [PPC]
- Disable SMAP (Supervisor Mode Access Prevention)
- even if it is supported by processor.
-
- nosmep [PPC64s]
- Disable SMEP (Supervisor Mode Execution Prevention)
- even if it is supported by processor.
+ no_entry_flush [PPC,EARLY] Don't flush the L1-D cache when entering the kernel.
noexec32 [X86-64]
This affects only 32-bit executables.
@@ -3608,96 +4392,40 @@
noexec32=off: disable non-executable mappings
read implies executable mappings
+ no_file_caps Tells the kernel not to honor file capabilities. The
+ only way then for a file to be executed with privilege
+ is to be setuid root or executed by root.
+
nofpu [MIPS,SH] Disable hardware FPU at boot time.
+ nofsgsbase [X86] Disables FSGSBASE instructions.
+
nofxsr [BUGS=X86-32] Disables x86 floating point extended
register save and restore. The kernel will only save
legacy floating-point registers on task switch.
- nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
-
- nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings.
-
- nosmt [KNL,S390] Disable symmetric multithreading (SMT).
- Equivalent to smt=1.
-
- [KNL,X86] Disable symmetric multithreading (SMT).
- nosmt=force: Force disable SMT, cannot be undone
- via the sysfs control file.
-
- nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1
- (bounds check bypass). With this option data leaks are
- possible in the system.
-
- nospectre_v2 [X86,PPC_FSL_BOOK3E,ARM64] Disable all mitigations for
- the Spectre variant 2 (indirect branch prediction)
- vulnerability. System may allow data leaks with this
- option.
-
- nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch
- history injection) vulnerability. System may allow data leaks
- with this option.
-
- nospec_store_bypass_disable
- [HW] Disable all mitigations for the Speculative Store Bypass vulnerability
-
- no_uaccess_flush
- [PPC] Don't flush the L1-D cache after accessing user data.
+ nogbpages [X86] Do not use GB pages for kernel direct mappings.
- noxsave [BUGS=X86] Disables x86 extended register state save
- and restore using xsave. The kernel will fallback to
- enabling legacy floating-point and sse state.
-
- noxsaveopt [X86] Disables xsaveopt used in saving x86 extended
- register states. The kernel will fall back to use
- xsave to save the states. By using this parameter,
- performance of saving the states is degraded because
- xsave doesn't support modified optimization while
- xsaveopt supports it on xsaveopt enabled systems.
+ no_hash_pointers
+ [KNL,EARLY]
+ Alias for "hash_pointers=never".
- noxsaves [X86] Disables xsaves and xrstors used in saving and
- restoring x86 extended register state in compacted
- form of xsave area. The kernel will fall back to use
- xsaveopt and xrstor to save and restore the states
- in standard form of xsave area. By using this
- parameter, xsave area per process might occupy more
- memory on xsaves enabled systems.
+ nohibernate [HIBERNATION] Disable hibernation and resume.
- nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait
- in do_idle() and not use the arch_cpu_idle()
+ nohlt [ARM,ARM64,MICROBLAZE,MIPS,PPC,RISCV,SH] Forces the kernel to
+ busy wait in do_idle() and not use the arch_cpu_idle()
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
to be effective. This is useful on platforms where the
sleep(SH) or wfi(ARM,ARM64) instructions do not work
- correctly or when doing power measurements to evalute
+ correctly or when doing power measurements to evaluate
the impact of the sleep instructions. This is also
useful when using JTAG debugger.
- no_file_caps Tells the kernel not to honor file capabilities. The
- only way then for a file to be executed with privilege
- is to be setuid root or executed by root.
-
- nohalt [IA-64] Tells the kernel not to use the power saving
- function PAL_HALT_LIGHT when idle. This increases
- power-consumption. On the positive side, it reduces
- interrupt wake-up latency, which may improve performance
- in certain environments such as networked servers or
- real-time systems.
+ nohpet [X86] Don't use the HPET timer.
- no_hash_pointers
- Force pointers printed to the console or buffers to be
- unhashed. By default, when a pointer is printed via %p
- format string, that pointer is "hashed", i.e. obscured
- by hashing the pointer value. This is a security feature
- that hides actual kernel addresses from unprivileged
- users, but it also makes debugging the kernel more
- difficult since unequal pointers can no longer be
- compared. However, if this command-line option is
- specified, then all normal pointers will have their true
- value printed. This option should only be specified when
- debugging the kernel. Please do not use on production
- kernels.
+ nohugeiomap [KNL,X86,PPC,ARM64,EARLY] Disable kernel huge I/O mappings.
- nohibernate [HIBERNATION] Disable hibernation and resume.
+ nohugevmalloc [KNL,X86,PPC,ARM64,EARLY] Disable kernel huge vmalloc mappings.
nohz= [KNL] Boottime enable/disable dynamic ticks
Valid arguments: on, off
@@ -3716,70 +4444,77 @@
Note that this argument takes precedence over
the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option.
- noiotrap [SH] Disables trapped I/O port accesses.
-
- noirqdebug [X86-32] Disables the code which attempts to detect and
- disable unhandled interrupt sources.
-
- no_timer_check [X86,APIC] Disables the code which tests for
- broken timer IRQ sources.
-
- noisapnp [ISAPNP] Disables ISA PnP code.
-
noinitrd [RAM] Tells the kernel not to load any configured
initial RAM disk.
- nointremap [X86-64, Intel-IOMMU] Do not enable interrupt
+ nointremap [X86-64,Intel-IOMMU,EARLY] Do not enable interrupt
remapping.
[Deprecated - use intremap=off]
- nointroute [IA-64]
-
- noinvpcid [X86] Disable the INVPCID cpu feature.
+ noinvpcid [X86,EARLY] Disable the INVPCID cpu feature.
- nojitter [IA-64] Disables jitter checking for ITC timers.
+ noiotrap [SH] Disables trapped I/O port accesses.
- no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
+ noirqdebug [X86-32] Disables the code which attempts to detect and
+ disable unhandled interrupt sources.
- no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page
- fault handling.
+ noisapnp [ISAPNP] Disables ISA PnP code.
- no-vmw-sched-clock
- [X86,PV_OPS] Disable paravirtualized VMware scheduler
- clock and use the default one.
+ nokaslr [KNL,EARLY]
+ When CONFIG_RANDOMIZE_BASE is set, this disables
+ kernel and module base offset ASLR (Address Space
+ Layout Randomization).
- no-steal-acc [X86,PV_OPS,ARM64] Disable paravirtualized steal time
- accounting. steal time is computed, but won't
- influence scheduler behaviour
+ no-kvmapf [X86,KVM,EARLY] Disable paravirtualized asynchronous page
+ fault handling.
- nolapic [X86-32,APIC] Do not enable or use the local APIC.
+ no-kvmclock [X86,KVM,EARLY] Disable paravirtualized KVM clock driver
- nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
+ nolapic [X86-32,APIC,EARLY] Do not enable or use the local APIC.
- nomca [IA-64] Disable machine check abort handling
+ nolapic_timer [X86-32,APIC,EARLY] Do not use the local APIC timer.
nomce [X86-32] Disable Machine Check Exception
nomfgpt [X86-32] Disable Multi-Function General Purpose
Timer usage (for AMD Geode machines).
+ nomodeset Disable kernel modesetting. Most systems' firmware
+ sets up a display mode and provides framebuffer memory
+ for output. With nomodeset, DRM and fbdev drivers will
+ not load if they could possibly displace the pre-
+ initialized output. Only the system framebuffer will
+ be available for use. The respective drivers will not
+ perform display-mode changes or accelerated rendering.
+
+ Useful as error fallback, or for testing and debugging.
+
+ nomodule Disable module load
+
nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to
shutdown the other cpus. Instead use the REBOOT_VECTOR
irq.
- nomodeset Disable kernel modesetting. DRM drivers will not perform
- display-mode changes or accelerated rendering. Only the
- system framebuffer will be available for use if this was
- set-up by the firmware or boot loader.
+ nopat [X86,EARLY] Disable PAT (page attribute table extension of
+ pagetables) support.
- Useful as fallback, or for testing and debugging.
+ nopcid [X86-64,EARLY] Disable the PCID cpu feature.
- nomodule Disable module load
+ nopku [X86] Disable Memory Protection Keys CPU feature found
+ in some Intel CPUs.
- nopat [X86] Disable PAT (page attribute table extension of
- pagetables) support.
+ nopti [X86-64,EARLY]
+ Equivalent to pti=off
- nopcid [X86-64] Disable the PCID cpu feature.
+ nopv= [X86,XEN,KVM,HYPER_V,VMWARE,EARLY]
+ Disables the PV optimizations forcing the guest to run
+ as generic guest with no PV drivers. Currently support
+ XEN HVM, KVM, HYPER_V and VMWARE guest.
+
+ nopvspin [X86,XEN,KVM,EARLY]
+ Disables the qspinlock slow path using PV optimizations
+ which allow the hypervisor to 'idle' the guest on lock
+ contention.
norandmaps Don't use address space randomization. Equivalent to
echo 0 > /proc/sys/kernel/randomize_va_space
@@ -3794,42 +4529,105 @@
This is required for the Braillex ib80-piezo Braille
reader made by F.H. Papenmeier (Germany).
- nosbagart [IA-64]
+ nosgx [X86-64,SGX,EARLY] Disables Intel SGX kernel support.
+
+ nosmap [PPC,EARLY]
+ Disable SMAP (Supervisor Mode Access Prevention)
+ even if it is supported by processor.
- nosgx [X86-64,SGX] Disables Intel SGX kernel support.
+ nosmep [PPC64s,EARLY]
+ Disable SMEP (Supervisor Mode Execution Prevention)
+ even if it is supported by processor.
- nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
+ nosmp [SMP,EARLY] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC. legacy for "maxcpus=0".
+ nosmt [KNL,MIPS,PPC,EARLY] Disable symmetric multithreading (SMT).
+ Equivalent to smt=1.
+
+ [KNL,X86,PPC,S390] Disable symmetric multithreading (SMT).
+ nosmt=force: Force disable SMT, cannot be undone
+ via the sysfs control file.
+
nosoftlockup [KNL] Disable the soft-lockup detector.
+ nospec_store_bypass_disable
+ [HW,EARLY] Disable all mitigations for the Speculative
+ Store Bypass vulnerability
+
+ nospectre_bhb [ARM64,EARLY] Disable all mitigations for Spectre-BHB (branch
+ history injection) vulnerability. System may allow data leaks
+ with this option.
+
+ nospectre_v1 [X86,PPC,EARLY] Disable mitigations for Spectre Variant 1
+ (bounds check bypass). With this option data leaks are
+ possible in the system.
+
+ nospectre_v2 [X86,PPC_E500,ARM64,EARLY] Disable all mitigations
+ for the Spectre variant 2 (indirect branch
+ prediction) vulnerability. System may allow data
+ leaks with this option.
+
+ no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES,RISCV,LOONGARCH,EARLY]
+ Disable paravirtualized steal time accounting. steal time
+ is computed, but won't influence scheduler behaviour
+
nosync [HW,M68K] Disables sync negotiation for all devices.
+ no_timer_check [X86,APIC] Disables the code which tests for broken
+ timer IRQ sources, i.e., the IO-APIC timer. This can
+ work around problems with incorrect timer
+ initialization on some boards.
+
+ no_uaccess_flush
+ [PPC,EARLY] Don't flush the L1-D cache after accessing user data.
+
+ novmcoredd [KNL,KDUMP]
+ Disable device dump. Device dump allows drivers to
+ append dump data to vmcore so you can collect driver
+ specified debug info. Drivers can append the data
+ without any limit and this data is stored in memory,
+ so this may cause significant memory stress. Disabling
+ device dump can help save memory but the driver debug
+ data will be no longer available. This parameter
+ is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP
+ is set.
+
+ no-vmw-sched-clock
+ [X86,PV_OPS,EARLY] Disable paravirtualized VMware
+ scheduler clock and use the default one.
+
nowatchdog [KNL] Disable both lockup detectors, i.e.
soft-lockup and NMI watchdog (hard-lockup).
- nowb [ARM]
+ nowb [ARM,EARLY]
- nox2apic [X86-64,APIC] Do not enable x2APIC mode.
+ nox2apic [X86-64,APIC,EARLY] Do not enable x2APIC mode.
NOTE: this parameter will be ignored on systems with the
LEGACY_XAPIC_DISABLED bit set in the
IA32_XAPIC_DISABLE_STATUS MSR.
- nps_mtm_hs_ctr= [KNL,ARC]
- This parameter sets the maximum duration, in
- cycles, each HW thread of the CTOP can run
- without interruptions, before HW switches it.
- The actual maximum duration is 16 times this
- parameter's value.
- Format: integer between 1 and 255
- Default: 255
+ noxsave [BUGS=X86] Disables x86 extended register state save
+ and restore using xsave. The kernel will fallback to
+ enabling legacy floating-point and sse state.
+
+ noxsaveopt [X86] Disables xsaveopt used in saving x86 extended
+ register states. The kernel will fall back to use
+ xsave to save the states. By using this parameter,
+ performance of saving the states is degraded because
+ xsave doesn't support modified optimization while
+ xsaveopt supports it on xsaveopt enabled systems.
- nptcg= [IA-64] Override max number of concurrent global TLB
- purges which is reported from either PAL_VM_SUMMARY or
- SAL PALO.
+ noxsaves [X86] Disables xsaves and xrstors used in saving and
+ restoring x86 extended register state in compacted
+ form of xsave area. The kernel will fall back to use
+ xsaveopt and xrstor to save and restore the states
+ in standard form of xsave area. By using this
+ parameter, xsave area per process might occupy more
+ memory on xsaves enabled systems.
- nr_cpus= [SMP] Maximum number of processors that an SMP kernel
+ nr_cpus= [SMP,EARLY] Maximum number of processors that an SMP kernel
could support. nr_cpus=n : n >= 1 limits the kernel to
support 'n' processors. It could be larger than the
number of already plugged CPU during bootup, later in
@@ -3840,8 +4638,29 @@
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
- numa=off [KNL, ARM64, PPC, RISCV, SPARC, X86] Disable NUMA, Only
- set up a single NUMA node spanning all memory.
+ numa=off [KNL, ARM64, PPC, RISCV, SPARC, X86, EARLY]
+ Disable NUMA, Only set up a single NUMA node
+ spanning all memory.
+
+ numa=fake=<size>[MG]
+ [KNL, ARM64, RISCV, X86, EARLY]
+ If given as a memory unit, fills all system RAM with
+ nodes of size interleaved over physical nodes.
+
+ numa=fake=<N>
+ [KNL, ARM64, RISCV, X86, EARLY]
+ If given as an integer, fills all system RAM with N
+ fake nodes interleaved over physical nodes.
+
+ numa=fake=<N>U
+ [KNL, ARM64, RISCV, X86, EARLY]
+ If given as an integer followed by 'U', it will
+ divide each physical node into N emulated nodes.
+
+ numa=noacpi [X86] Don't parse the SRAT table for NUMA setup
+
+ numa=nohmat [X86] Don't parse the HMAT table for NUMA setup, or
+ soft-reserved memory partitioning.
numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic
NUMA balancing.
@@ -3852,7 +4671,7 @@
This can be set from sysctl after boot.
See Documentation/admin-guide/sysctl/vm.rst for details.
- ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
+ ohci1394_dma=early [HW,EARLY] enable debugging via the ohci1394 driver.
See Documentation/core-api/debugging-via-ohci1394.rst for more
info.
@@ -3878,7 +4697,8 @@
Once locked, the boundary cannot be changed.
1 indicates lock status, 0 indicates unlock status.
- oops=panic Always panic on oopses. Default is to just kill the
+ oops=panic [KNL,EARLY]
+ Always panic on oopses. Default is to just kill the
process, but there is a small probability of
deadlocking the machine.
This will also cause panics on machine check exceptions.
@@ -3886,21 +4706,19 @@
page_alloc.shuffle=
[KNL] Boolean flag to control whether the page allocator
- should randomize its free lists. The randomization may
- be automatically enabled if the kernel detects it is
- running on a platform with a direct-mapped memory-side
- cache, and this parameter can be used to
- override/disable that behavior. The state of the flag
- can be read from sysfs at:
+ should randomize its free lists. This parameter can be
+ used to enable/disable page randomization. The state of
+ the flag can be read from sysfs at:
/sys/module/page_alloc/parameters/shuffle.
+ This parameter is only available if CONFIG_SHUFFLE_PAGE_ALLOCATOR=y.
- page_owner= [KNL] Boot-time page_owner enabling option.
+ page_owner= [KNL,EARLY] Boot-time page_owner enabling option.
Storage of the information about who allocated
each page is disabled in default. With this switch,
we can turn it on.
on: enable the feature
- page_poison= [KNL] Boot-time parameter changing the state of
+ page_poison= [KNL,EARLY] Boot-time parameter changing the state of
poisoning on the buddy allocator, available with
CONFIG_PAGE_POISONING=y.
off: turn off poisoning (default)
@@ -3910,7 +4728,7 @@
[KNL] Minimal page reporting order
Format: <integer>
Adjust the minimal page reporting order. The page
- reporting is disabled when it exceeds (MAX_ORDER-1).
+ reporting is disabled when it exceeds MAX_PAGE_ORDER.
panic= [KNL] Kernel behaviour on panic: delay <timeout>
timeout > 0: seconds before rebooting
@@ -3918,6 +4736,23 @@
timeout < 0: reboot immediately
Format: <timeout>
+ panic_on_taint= [KNL,EARLY]
+ Bitmask for conditionally calling panic() in add_taint()
+ Format: <hex>[,nousertaint]
+ Hexadecimal bitmask representing the set of TAINT flags
+ that will cause the kernel to panic when add_taint() is
+ called with any of the flags in this set.
+ The optional switch "nousertaint" can be utilized to
+ prevent userspace forced crashes by writing to sysctl
+ /proc/sys/kernel/tainted any flagset matching with the
+ bitmask set on panic_on_taint.
+ See Documentation/admin-guide/tainted-kernels.rst for
+ extra details on the taint flags that users can pick
+ to compose the bitmask to assign to panic_on_taint.
+
+ panic_on_warn=1 panic() instead of WARN(). Useful to cause kdump
+ on a WARN().
+
panic_print= Bitmask for printing system info when panic happens.
User can chose combination of the following bits:
bit 0: print all tasks info
@@ -3925,28 +4760,32 @@
bit 2: print timer info
bit 3: print locks info if CONFIG_LOCKDEP is on
bit 4: print ftrace buffer
- bit 5: print all printk messages in buffer
+ bit 5: replay all kernel messages on consoles at the end of panic
bit 6: print all CPUs backtrace (if available in the arch)
+ bit 7: print only tasks in uninterruptible (blocked) state
*Be aware* that this option may print a _lot_ of lines,
so there are risks of losing older messages in the log.
Use this option carefully, maybe worth to setup a
bigger log buffer with "log_buf_len" along with this.
- panic_on_taint= Bitmask for conditionally calling panic() in add_taint()
- Format: <hex>[,nousertaint]
- Hexadecimal bitmask representing the set of TAINT flags
- that will cause the kernel to panic when add_taint() is
- called with any of the flags in this set.
- The optional switch "nousertaint" can be utilized to
- prevent userspace forced crashes by writing to sysctl
- /proc/sys/kernel/tainted any flagset matching with the
- bitmask set on panic_on_taint.
- See Documentation/admin-guide/tainted-kernels.rst for
- extra details on the taint flags that users can pick
- to compose the bitmask to assign to panic_on_taint.
+ panic_sys_info= A comma separated list of extra information to be dumped
+ on panic.
+ Format: val[,val...]
+ Where @val can be any of the following:
- panic_on_warn panic() instead of WARN(). Useful to cause kdump
- on a WARN().
+ tasks: print all tasks info
+ mem: print system memory info
+ timers: print timers info
+ locks: print locks info if CONFIG_LOCKDEP is on
+ ftrace: print ftrace buffer
+ all_bt: print all CPUs backtrace (if available in the arch)
+ blocked_tasks: print only tasks in uninterruptible (blocked) state
+
+ This is a human readable alternative to the 'panic_print' option.
+
+ panic_console_replay
+ When panic happens, replay all kernel messages on
+ consoles at the end of panic.
parkbd.port= [HW] Parallel port number the keyboard adapter is
connected to, default is 0.
@@ -4067,18 +4906,14 @@
mode 0, bit 1 is for mode 1, and so on. Mode 0 only
allowed by default.
- pause_on_oops=
+ pause_on_oops=<int>
Halt all CPUs after the first oops has been printed for
the specified number of seconds. This is to be used if
your oopses keep scrolling off the screen.
pcbit= [HW,ISDN]
- pcd. [PARIDE]
- See header of drivers/block/paride/pcd.c.
- See also Documentation/admin-guide/blockdev/paride.rst.
-
- pci=option[,option...] [PCI] various PCI subsystem options.
+ pci=option[,option...] [PCI,EARLY] various PCI subsystem options.
Some options herein operate on a specific device
or a set of devices (<pci_dev>). These are
@@ -4253,7 +5088,9 @@
specified, e.g., 12@pci:8086:9c22:103c:198f
for 4096-byte alignment.
ecrc= Enable/disable PCIe ECRC (transaction layer
- end-to-end CRC checking).
+ end-to-end CRC checking). Only effective if
+ OS has native AER control (either granted by
+ ACPI _OSC or forced via "pcie_ports=native")
bios: Use BIOS/firmware settings. This is the
the default.
off: Turn ECRC off
@@ -4302,14 +5139,51 @@
bridges without forcing it upstream. Note:
this removes isolation between devices and
may put more devices in an IOMMU group.
+ config_acs=
+ Format:
+ <ACS flags>@<pci_dev>[; ...]
+ Specify one or more PCI devices (in the format
+ specified above) optionally prepended with flags
+ and separated by semicolons. The respective
+ capabilities will be enabled, disabled or
+ unchanged based on what is specified in
+ flags.
+
+ ACS Flags is defined as follows:
+ bit-0 : ACS Source Validation
+ bit-1 : ACS Translation Blocking
+ bit-2 : ACS P2P Request Redirect
+ bit-3 : ACS P2P Completion Redirect
+ bit-4 : ACS Upstream Forwarding
+ bit-5 : ACS P2P Egress Control
+ bit-6 : ACS Direct Translated P2P
+ Each bit can be marked as:
+ '0' – force disabled
+ '1' – force enabled
+ 'x' – unchanged
+ For example,
+ pci=config_acs=10x@pci:0:0
+ would configure all devices that support
+ ACS to enable P2P Request Redirect, disable
+ Translation Blocking, and leave Source
+ Validation unchanged from whatever power-up
+ or firmware set it to.
+
+ Note: this may remove isolation between devices
+ and may put more devices in an IOMMU group.
force_floating [S390] Force usage of floating interrupts.
nomio [S390] Do not use MIO instructions.
norid [S390] ignore the RID field and force use of
one PCI domain per PCI function
+ notph [PCIE] If the PCIE_TPH kernel config parameter
+ is enabled, this kernel boot option can be used
+ to disable PCIe TLP Processing Hints support
+ system-wide.
- pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
+ pcie_aspm= [PCIE] Forcibly enable or ignore PCIe Active State Power
Management.
- off Disable ASPM.
+ off Don't touch ASPM configuration at all. Leave any
+ configuration done by firmware unchanged.
force Enable ASPM even on devices that claim not to support it.
WARNING: Forcing ASPM on may cause system lockups.
@@ -4340,29 +5214,21 @@
for debug and development, but should not be
needed on a platform with proper driver support.
- pd. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
pdcchassis= [PARISC,HW] Disable/Enable PDC Chassis Status codes at
boot time.
Format: { 0 | 1 }
See arch/parisc/kernel/pdc_chassis.c
- percpu_alloc= Select which percpu first chunk allocator to use.
+ percpu_alloc= [MM,EARLY]
+ Select which percpu first chunk allocator to use.
Currently supported values are "embed" and "page".
Archs may support subset or none of the selections.
See comments in mm/percpu.c for details on each
allocator. This parameter is primarily for debugging
and performance comparison.
- pf. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
- pg. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
pirq= [SMP,APIC] Manual mp-table setup
- See Documentation/x86/i386/IO-APIC.rst.
+ See Documentation/arch/x86/i386/IO-APIC.rst.
plip= [PPT,NET] Parallel port network link
Format: { parport<nr> | timid | 0 }
@@ -4380,6 +5246,18 @@
that number, otherwise (e.g., 'pmu_override=on'), MMCR1
remains 0.
+ pm_async= [PM]
+ Format: off
+ This parameter sets the initial value of the
+ /sys/power/pm_async sysfs knob at boot time.
+ If set to "off", disables asynchronous suspend and
+ resume of devices during system-wide power transitions.
+ This can be useful on platforms where device
+ dependencies are not well-defined, or for debugging
+ power management issues. Asynchronous operations are
+ enabled by default.
+
+
pm_debug_messages [SUSPEND,KNL]
Enable suspend/resume debug messages during boot up.
@@ -4416,6 +5294,11 @@
may be specified.
Format: <port>,<port>....
+ possible_cpus= [SMP,S390,X86]
+ Format: <unsigned int>
+ Set the number of possible CPUs, overriding the
+ regular discovery mechanisms (such as ACPI/FW, etc).
+
powersave=off [PPC] This option disables power saving features.
It specifically disables cpuidle and sets the
platform machine description specific power_save
@@ -4423,12 +5306,12 @@
execution priority.
ppc_strict_facility_enable
- [PPC] This option catches any kernel floating point,
+ [PPC,ENABLE] This option catches any kernel floating point,
Altivec, VSX and SPE outside of regions specifically
allowed (eg kernel_enable_fpu()/kernel_disable_fpu()).
There is some performance impact when enabling this.
- ppc_tm= [PPC]
+ ppc_tm= [PPC,EARLY]
Format: {"off"}
Disable Hardware Transactional Memory
@@ -4437,7 +5320,14 @@
none - Limited to cond_resched() calls
voluntary - Limited to cond_resched() and might_sleep() calls
full - Any section that isn't explicitly preempt disabled
- can be preempted anytime.
+ can be preempted anytime. Tasks will also yield
+ contended spinlocks (if the critical section isn't
+ explicitly preempt disabled beyond the lock itself).
+ lazy - Scheduler controlled. Similar to full but instead
+ of preempting the task immediately, the task gets
+ one HZ tick time to yield itself before the
+ preemption will be forced. One preemption is when the
+ task returns to user space.
print-fatal-signals=
[KNL] debug: print fatal signals
@@ -4467,6 +5357,14 @@
Format: <bool>
default: 0 (auto_verbose is enabled)
+ printk.debug_non_panic_cpus=
+ Allows storing messages from non-panic CPUs into
+ the printk log buffer during panic(). They are
+ flushed to consoles by the panic-CPU on
+ a best-effort basis.
+ Format: <bool> (1/Y/y=enable, 0/N/n=disable)
+ Default: disabled
+
printk.devkmsg={on,off,ratelimit}
Control writing to /dev/kmsg.
on - unlimited logging to /dev/kmsg from userspace
@@ -4477,6 +5375,16 @@
printk.time= Show timing data prefixed to each printk message line
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
+ proc_mem.force_override= [KNL]
+ Format: {always | ptrace | never}
+ Traditionally /proc/pid/mem allows memory permissions to be
+ overridden without restrictions. This option may be set to
+ restrict that. Can be one of:
+ - 'always': traditional behavior always allows mem overrides.
+ - 'ptrace': only allow mem overrides for active ptracers.
+ - 'never': never allow mem overrides.
+ If not specified, default is the CONFIG_PROC_MEM_* choice.
+
processor.max_cstate= [HW,ACPI]
Limit processor to maximum C-state
max_cstate=9 overrides any DMI blacklist limit.
@@ -4487,11 +5395,9 @@
profile= [KNL] Enable kernel profiling via /proc/profile
Format: [<profiletype>,]<number>
- Param: <profiletype>: "schedule", "sleep", or "kvm"
+ Param: <profiletype>: "schedule" or "kvm"
[defaults to kernel profiling]
Param: "schedule" - profile schedule points.
- Param: "sleep" - profile D-state sleeping (millisecs).
- Requires CONFIG_SCHEDSTATS
Param: "kvm" - profile VM exits.
Param: <number> - step/bucket size as a power of 2 for
statistical time based profiling.
@@ -4500,7 +5406,9 @@
prot_virt= [S390] enable hosting protected virtual machines
isolated from the hypervisor (if hardware supports
- that).
+ that). If enabled, the default kernel base address
+ might be overridden even when Kernel Address Space
+ Layout Randomization is disabled.
Format: <bool>
psi= [KNL] Enable or disable pressure stall information
@@ -4522,9 +5430,6 @@
pstore.backend= Specify the name of the pstore backend to use
- pt. [PARIDE]
- See Documentation/admin-guide/blockdev/paride.rst.
-
pti= [X86-64] Control Page Table Isolation of user and
kernel address spaces. Disabling this feature
removes hardening, but improves performance of
@@ -4537,17 +5442,18 @@
Not specifying this option is equivalent to pti=auto.
- nopti [X86-64]
- Equivalent to pti=off
-
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
default number.
- quiet [KNL] Disable most log messages
+ quiet [KNL,EARLY] Disable most log messages
r128= [HW,DRM]
+ radix_hcall_invalidate=on [PPC/PSERIES]
+ Disable RADIX GTSE feature and use hcall for TLB
+ invalidate.
+
raid= [HW,RAID]
See Documentation/admin-guide/md.rst.
@@ -4556,20 +5462,18 @@
ramdisk_start= [RAM] RAM disk image start address
- random.trust_cpu={on,off}
- [KNL] Enable or disable trusting the use of the
- CPU's random number generator (if available) to
- fully seed the kernel's CRNG. Default is controlled
- by CONFIG_RANDOM_TRUST_CPU.
+ random.trust_cpu=off
+ [KNL,EARLY] Disable trusting the use of the CPU's
+ random number generator (if available) to
+ initialize the kernel's RNG.
- random.trust_bootloader={on,off}
- [KNL] Enable or disable trusting the use of a
- seed passed by the bootloader (if available) to
- fully seed the kernel's CRNG. Default is controlled
- by CONFIG_RANDOM_TRUST_BOOTLOADER.
+ random.trust_bootloader=off
+ [KNL,EARLY] Disable trusting the use of the a seed
+ passed by the bootloader (if available) to
+ initialize the kernel's RNG.
randomize_kstack_offset=
- [KNL] Enable or disable kernel stack offset
+ [KNL,EARLY] Enable or disable kernel stack offset
randomization, which provides roughly 5 bits of
entropy, frustrating memory corruption attacks
that depend on stack address determinism or
@@ -4628,6 +5532,17 @@
Set maximum number of finished RCU callbacks to
process in one batch.
+ rcutree.csd_lock_suppress_rcu_stall= [KNL]
+ Do only a one-line RCU CPU stall warning when
+ there is an ongoing too-long CSD-lock wait.
+
+ rcutree.do_rcu_barrier= [KNL]
+ Request a call to rcu_barrier(). This is
+ throttled so that userspace tests can safely
+ hammer on the sysfs variable if they so choose.
+ If triggered before the RCU grace-period machinery
+ is fully active, this will error out with EAGAIN.
+
rcutree.dump_tree= [KNL]
Dump the structure of the rcu_node combining tree
out at early boot. This is used for diagnostic
@@ -4647,43 +5562,6 @@
the propagation of recent CPU-hotplug changes up
the rcu_node combining tree.
- rcutree.use_softirq= [KNL]
- If set to zero, move all RCU_SOFTIRQ processing to
- per-CPU rcuc kthreads. Defaults to a non-zero
- value, meaning that RCU_SOFTIRQ is used by default.
- Specify rcutree.use_softirq=0 to use rcuc kthreads.
-
- But note that CONFIG_PREEMPT_RT=y kernels disable
- this kernel boot parameter, forcibly setting it
- to zero.
-
- rcutree.rcu_fanout_exact= [KNL]
- Disable autobalancing of the rcu_node combining
- tree. This is used by rcutorture, and might
- possibly be useful for architectures having high
- cache-to-cache transfer latencies.
-
- rcutree.rcu_fanout_leaf= [KNL]
- Change the number of CPUs assigned to each
- leaf rcu_node structure. Useful for very
- large systems, which will choose the value 64,
- and for NUMA systems with large remote-access
- latencies, which will choose a value aligned
- with the appropriate hardware boundaries.
-
- rcutree.rcu_min_cached_objs= [KNL]
- Minimum number of objects which are cached and
- maintained per one CPU. Object size is equal
- to PAGE_SIZE. The cache allows to reduce the
- pressure to page allocator, also it makes the
- whole algorithm to behave better in low memory
- condition.
-
- rcutree.rcu_delay_page_cache_fill_msec= [KNL]
- Set the page-cache refill delay (in milliseconds)
- in response to low-memory conditions. The range
- of permitted values is in the range 0:100000.
-
rcutree.jiffies_till_first_fqs= [KNL]
Set delay from grace-period initialization to
first attempt to force quiescent states.
@@ -4722,21 +5600,6 @@
When RCU_NOCB_CPU is set, also adjust the
priority of NOCB callback kthreads.
- rcutree.rcu_divisor= [KNL]
- Set the shift-right count to use to compute
- the callback-invocation batch limit bl from
- the number of callbacks queued on this CPU.
- The result will be bounded below by the value of
- the rcutree.blimit kernel parameter. Every bl
- callbacks, the softirq handler will exit in
- order to allow the CPU to do other work.
-
- Please note that this callback-invocation batch
- limit applies only to non-offloaded callback
- invocation. Offloaded callbacks are instead
- invoked in the context of an rcuoc kthread, which
- scheduler will preempt as it does any other task.
-
rcutree.nocb_nobypass_lim_per_jiffy= [KNL]
On callback-offloaded (rcu_nocbs) CPUs,
RCU reduces the lock contention that would
@@ -4750,13 +5613,13 @@
the ->nocb_bypass queue. The definition of "too
many" is supplied by this kernel boot parameter.
- rcutree.rcu_nocb_gp_stride= [KNL]
- Set the number of NOCB callback kthreads in
- each group, which defaults to the square root
- of the number of CPUs. Larger numbers reduce
- the wakeup overhead on the global grace-period
- kthread, but increases that same overhead on
- each group's NOCB grace-period kthread.
+ rcutree.nohz_full_patience_delay= [KNL]
+ On callback-offloaded (rcu_nocbs) CPUs, avoid
+ disturbing RCU unless the grace period has
+ reached the specified age in milliseconds.
+ Defaults to zero. Large values will be capped
+ at five seconds. All values will be rounded down
+ to the nearest value representable by jiffies.
rcutree.qhimark= [KNL]
Set threshold of queued RCU callbacks beyond which
@@ -4775,6 +5638,56 @@
on rcutree.qhimark at boot time and to zero to
disable more aggressive help enlistment.
+ rcutree.rcu_delay_page_cache_fill_msec= [KNL]
+ Set the page-cache refill delay (in milliseconds)
+ in response to low-memory conditions. The range
+ of permitted values is in the range 0:100000.
+
+ rcutree.rcu_divisor= [KNL]
+ Set the shift-right count to use to compute
+ the callback-invocation batch limit bl from
+ the number of callbacks queued on this CPU.
+ The result will be bounded below by the value of
+ the rcutree.blimit kernel parameter. Every bl
+ callbacks, the softirq handler will exit in
+ order to allow the CPU to do other work.
+
+ Please note that this callback-invocation batch
+ limit applies only to non-offloaded callback
+ invocation. Offloaded callbacks are instead
+ invoked in the context of an rcuoc kthread, which
+ scheduler will preempt as it does any other task.
+
+ rcutree.rcu_fanout_exact= [KNL]
+ Disable autobalancing of the rcu_node combining
+ tree. This is used by rcutorture, and might
+ possibly be useful for architectures having high
+ cache-to-cache transfer latencies.
+
+ rcutree.rcu_fanout_leaf= [KNL]
+ Change the number of CPUs assigned to each
+ leaf rcu_node structure. Useful for very
+ large systems, which will choose the value 64,
+ and for NUMA systems with large remote-access
+ latencies, which will choose a value aligned
+ with the appropriate hardware boundaries.
+
+ rcutree.rcu_min_cached_objs= [KNL]
+ Minimum number of objects which are cached and
+ maintained per one CPU. Object size is equal
+ to PAGE_SIZE. The cache allows to reduce the
+ pressure to page allocator, also it makes the
+ whole algorithm to behave better in low memory
+ condition.
+
+ rcutree.rcu_nocb_gp_stride= [KNL]
+ Set the number of NOCB callback kthreads in
+ each group, which defaults to the square root
+ of the number of CPUs. Larger numbers reduce
+ the wakeup overhead on the global grace-period
+ kthread, but increases that same overhead on
+ each group's NOCB grace-period kthread.
+
rcutree.rcu_kick_kthreads= [KNL]
Cause the grace-period kthread to get an extra
wake_up() if it sleeps three times longer than
@@ -4782,6 +5695,13 @@
This wake_up() will be accompanied by a
WARN_ONCE() splat and an ftrace_dump().
+ rcutree.rcu_resched_ns= [KNL]
+ Limit the time spend invoking a batch of RCU
+ callbacks to the specified number of nanoseconds.
+ By default, this limit is checked only once
+ every 32 callbacks in order to limit the pain
+ inflicted by local_clock() overhead.
+
rcutree.rcu_unlock_delay= [KNL]
In CONFIG_RCU_STRICT_GRACE_PERIOD=y kernels,
this specifies an rcu_read_unlock()-time delay
@@ -4796,6 +5716,36 @@
rcu_node tree with an eye towards determining
why a new grace period has not yet started.
+ rcutree.use_softirq= [KNL]
+ If set to zero, move all RCU_SOFTIRQ processing to
+ per-CPU rcuc kthreads. Defaults to a non-zero
+ value, meaning that RCU_SOFTIRQ is used by default.
+ Specify rcutree.use_softirq=0 to use rcuc kthreads.
+
+ But note that CONFIG_PREEMPT_RT=y kernels disable
+ this kernel boot parameter, forcibly setting it
+ to zero.
+
+ rcutree.enable_rcu_lazy= [KNL]
+ To save power, batch RCU callbacks and flush after
+ delay, memory pressure or callback list growing too
+ big.
+
+ rcutree.rcu_normal_wake_from_gp= [KNL]
+ Reduces a latency of synchronize_rcu() call. This approach
+ maintains its own track of synchronize_rcu() callers, so it
+ does not interact with regular callbacks because it does not
+ use a call_rcu[_hurry]() path. Please note, this is for a
+ normal grace period.
+
+ How to enable it:
+
+ echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp
+ or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1"
+
+ Default is 1 if num_possible_cpus() <= 16 and it is not explicitly
+ disabled by the boot parameter passing 0.
+
rcuscale.gp_async= [KNL]
Measure performance of asynchronous
grace-period primitives such as call_rcu().
@@ -4817,6 +5767,15 @@
test until boot completes in order to avoid
interference.
+ rcuscale.kfree_by_call_rcu= [KNL]
+ In kernels built with CONFIG_RCU_LAZY=y, test
+ call_rcu() instead of kfree_rcu().
+
+ rcuscale.kfree_mult= [KNL]
+ Instead of allocating an object of size kfree_obj,
+ allocate one of kfree_mult * sizeof(kfree_obj).
+ Defaults to 1.
+
rcuscale.kfree_rcu_test= [KNL]
Set to measure performance of kfree_rcu() flooding.
@@ -4842,6 +5801,12 @@
Number of loops doing rcuscale.kfree_alloc_num number
of allocations and frees.
+ rcuscale.minruntime= [KNL]
+ Set the minimum test run time in seconds. This
+ does not affect the data-collection interval,
+ but instead allows better measurement of things
+ like CPU consumption.
+
rcuscale.nreaders= [KNL]
Set number of RCU readers. The value -1 selects
N, where N is the number of CPUs. A value
@@ -4856,7 +5821,7 @@
the same as for rcuscale.nreaders.
N, where N is the number of CPUs
- rcuscale.perf_type= [KNL]
+ rcuscale.scale_type= [KNL]
Specify the RCU implementation to test.
rcuscale.shutdown= [KNL]
@@ -4872,6 +5837,11 @@
in microseconds. The default of zero says
no holdoff.
+ rcuscale.writer_holdoff_jiffies= [KNL]
+ Additional write-side holdoff between grace
+ periods, but in jiffies. The default of zero
+ says no holdoff.
+
rcutorture.fqs_duration= [KNL]
Set duration of force_quiescent_state bursts
in microseconds.
@@ -4907,7 +5877,42 @@
rcutorture.gp_cond= [KNL]
Use conditional/asynchronous update-side
- primitives, if available.
+ normal-grace-period primitives, if available.
+
+ rcutorture.gp_cond_exp= [KNL]
+ Use conditional/asynchronous update-side
+ expedited-grace-period primitives, if available.
+
+ rcutorture.gp_cond_full= [KNL]
+ Use conditional/asynchronous update-side
+ normal-grace-period primitives that also take
+ concurrent expedited grace periods into account,
+ if available.
+
+ rcutorture.gp_cond_exp_full= [KNL]
+ Use conditional/asynchronous update-side
+ expedited-grace-period primitives that also take
+ concurrent normal grace periods into account,
+ if available.
+
+ rcutorture.gp_cond_wi= [KNL]
+ Nominal wait interval for normal conditional
+ grace periods (specified by rcutorture's
+ gp_cond and gp_cond_full module parameters),
+ in microseconds. The actual wait interval will
+ be randomly selected to nanosecond granularity up
+ to this wait interval. Defaults to 16 jiffies,
+ for example, 16,000 microseconds on a system
+ with HZ=1000.
+
+ rcutorture.gp_cond_wi_exp= [KNL]
+ Nominal wait interval for expedited conditional
+ grace periods (specified by rcutorture's
+ gp_cond_exp and gp_cond_exp_full module
+ parameters), in microseconds. The actual wait
+ interval will be randomly selected to nanosecond
+ granularity up to this wait interval. Defaults to
+ 128 microseconds.
rcutorture.gp_exp= [KNL]
Use expedited update-side primitives, if available.
@@ -4916,6 +5921,43 @@
Use normal (non-expedited) asynchronous
update-side primitives, if available.
+ rcutorture.gp_poll= [KNL]
+ Use polled update-side normal-grace-period
+ primitives, if available.
+
+ rcutorture.gp_poll_exp= [KNL]
+ Use polled update-side expedited-grace-period
+ primitives, if available.
+
+ rcutorture.gp_poll_full= [KNL]
+ Use polled update-side normal-grace-period
+ primitives that also take concurrent expedited
+ grace periods into account, if available.
+
+ rcutorture.gp_poll_exp_full= [KNL]
+ Use polled update-side expedited-grace-period
+ primitives that also take concurrent normal
+ grace periods into account, if available.
+
+ rcutorture.gp_poll_wi= [KNL]
+ Nominal wait interval for normal conditional
+ grace periods (specified by rcutorture's
+ gp_poll and gp_poll_full module parameters),
+ in microseconds. The actual wait interval will
+ be randomly selected to nanosecond granularity up
+ to this wait interval. Defaults to 16 jiffies,
+ for example, 16,000 microseconds on a system
+ with HZ=1000.
+
+ rcutorture.gp_poll_wi_exp= [KNL]
+ Nominal wait interval for expedited conditional
+ grace periods (specified by rcutorture's
+ gp_poll_exp and gp_poll_exp_full module
+ parameters), in microseconds. The actual wait
+ interval will be randomly selected to nanosecond
+ granularity up to this wait interval. Defaults to
+ 128 microseconds.
+
rcutorture.gp_sync= [KNL]
Use normal (non-expedited) synchronous
update-side primitives, if available. If all
@@ -4924,6 +5966,31 @@
are zero, rcutorture acts as if is interpreted
they are all non-zero.
+ rcutorture.gpwrap_lag= [KNL]
+ Enable grace-period wrap lag testing. Setting
+ to false prevents the gpwrap lag test from
+ running. Default is true.
+
+ rcutorture.gpwrap_lag_gps= [KNL]
+ Set the value for grace-period wrap lag during
+ active lag testing periods. This controls how many
+ grace periods differences we tolerate between
+ rdp and rnp's gp_seq before setting overflow flag.
+ The default is always set to 8.
+
+ rcutorture.gpwrap_lag_cycle_mins= [KNL]
+ Set the total cycle duration for gpwrap lag
+ testing in minutes. This is the total time for
+ one complete cycle of active and inactive
+ testing periods. Default is 30 minutes.
+
+ rcutorture.gpwrap_lag_active_mins= [KNL]
+ Set the duration for which gpwrap lag is active
+ within each cycle, in minutes. During this time,
+ the grace-period wrap lag will be set to the
+ value specified by gpwrap_lag_gps. Default is
+ 5 minutes.
+
rcutorture.irqreader= [KNL]
Run RCU readers from irq handlers, or, more
accurately, from a timer handler. Not all RCU
@@ -4969,10 +6036,21 @@
Set time (jiffies) between CPU-hotplug operations,
or zero to disable CPU-hotplug testing.
- rcutorture.read_exit= [KNL]
- Set the number of read-then-exit kthreads used
- to test the interaction of RCU updaters and
- task-exit processing.
+ rcutorture.preempt_duration= [KNL]
+ Set duration (in milliseconds) of preemptions
+ by a high-priority FIFO real-time task. Set to
+ zero (the default) to disable. The CPUs to
+ preempt are selected randomly from the set that
+ are online at a given point in time. Races with
+ CPUs going offline are ignored, with that attempt
+ at preemption skipped.
+
+ rcutorture.preempt_interval= [KNL]
+ Set interval (in milliseconds, defaulting to one
+ second) between preemptions by a high-priority
+ FIFO real-time task. This delay is mediated
+ by an hrtimer and is further fuzzed to avoid
+ inadvertent synchronizations.
rcutorture.read_exit_burst= [KNL]
The number of times in a given read-then-exit
@@ -4983,6 +6061,14 @@
The delay, in seconds, between successive
read-then-exit testing episodes.
+ rcutorture.reader_flavor= [KNL]
+ A bit mask indicating which readers to use.
+ If there is more than one bit set, the readers
+ are entered from low-order bit up, and are
+ exited in the opposite order. For SRCU, the
+ 0x1 bit is normal readers, 0x2 NMI-safe readers,
+ and 0x4 light-weight readers.
+
rcutorture.shuffle_interval= [KNL]
Set task-shuffle interval (s). Shuffling tasks
allows some CPUs to go into dyntick-idle mode
@@ -4998,14 +6084,29 @@
rcutorture.stall_cpu_block= [KNL]
Sleep while stalling if set. This will result
- in warnings from preemptible RCU in addition
- to any other stall-related activity.
+ in warnings from preemptible RCU in addition to
+ any other stall-related activity. Note that
+ in kernels built with CONFIG_PREEMPTION=n and
+ CONFIG_PREEMPT_COUNT=y, this parameter will
+ cause the CPU to pass through a quiescent state.
+ Given CONFIG_PREEMPTION=n, this will suppress
+ RCU CPU stall warnings, but will instead result
+ in scheduling-while-atomic splats.
+
+ Use of this module parameter results in splats.
+
rcutorture.stall_cpu_holdoff= [KNL]
Time to wait (s) after boot before inducing stall.
rcutorture.stall_cpu_irqsoff= [KNL]
- Disable interrupts while stalling if set.
+ Disable interrupts while stalling if set, but only
+ on the first stall in the set.
+
+ rcutorture.stall_cpu_repeat= [KNL]
+ Number of times to repeat the stall sequence,
+ so that rcutorture.stall_cpu_repeat=3 will result
+ in four stall sequences.
rcutorture.stall_gp_kthread= [KNL]
Duration (s) of forced sleep within RCU
@@ -5031,6 +6132,11 @@
rcutorture.test_boost_duration= [KNL]
Duration (s) of each individual boost test.
+ rcutorture.test_boost_holdoff= [KNL]
+ Holdoff time (s) from start of test to the start
+ of RCU priority-boost testing. Defaults to zero,
+ that is, no holdoff.
+
rcutorture.test_boost_interval= [KNL]
Interval (s) between each boost test.
@@ -5048,6 +6154,12 @@
Dump ftrace buffer after reporting RCU CPU
stall warning.
+ rcupdate.rcu_cpu_stall_notifiers= [KNL]
+ Provide RCU CPU stall notifiers, but see the
+ warnings in the RCU_CPU_STALL_NOTIFIER Kconfig
+ option's help text. TL;DR: You almost certainly
+ do not want rcupdate.rcu_cpu_stall_notifiers.
+
rcupdate.rcu_cpu_stall_suppress= [KNL]
Suppress RCU CPU stall warning messages.
@@ -5072,6 +6184,17 @@
rcupdate.rcu_cpu_stall_timeout to be used (after
conversion from seconds to milliseconds).
+ rcupdate.rcu_cpu_stall_cputime= [KNL]
+ Provide statistics on the cputime and count of
+ interrupts and tasks during the sampling period. For
+ multiple continuous RCU stalls, all sampling periods
+ begin at half of the first RCU stall timeout.
+
+ rcupdate.rcu_exp_stall_task_details= [KNL]
+ Print stack dumps of any tasks blocking the
+ current expedited RCU grace period during an
+ expedited RCU CPU stall warning.
+
rcupdate.rcu_expedited= [KNL]
Use expedited grace-period primitives, for
example, synchronize_rcu_expedited() instead
@@ -5133,6 +6256,13 @@
number avoids disturbing real-time workloads,
but lengthens grace periods.
+ rcupdate.rcu_task_lazy_lim= [KNL]
+ Number of callbacks on a given CPU that will
+ cancel laziness on that CPU. Use -1 to disable
+ cancellation of laziness, but be advised that
+ doing so increases the danger of OOM due to
+ callback flooding.
+
rcupdate.rcu_task_stall_info= [KNL]
Set initial timeout in jiffies for RCU task stall
informational messages, which give some indication
@@ -5162,6 +6292,21 @@
A change in value does not take effect until
the beginning of the next grace period.
+ rcupdate.rcu_tasks_lazy_ms= [KNL]
+ Set timeout in milliseconds RCU Tasks asynchronous
+ callback batching for call_rcu_tasks().
+ A negative value will take the default. A value
+ of zero will disable batching. Batching is
+ always disabled for synchronize_rcu_tasks().
+
+ rcupdate.rcu_tasks_trace_lazy_ms= [KNL]
+ Set timeout in milliseconds RCU Tasks
+ Trace asynchronous callback batching for
+ call_rcu_tasks_trace(). A negative value
+ will take the default. A value of zero will
+ disable batching. Batching is always disabled
+ for synchronize_rcu_tasks_trace().
+
rcupdate.rcu_self_test= [KNL]
Run the RCU early boot self tests
@@ -5170,7 +6315,7 @@
Run specified binary instead of /init from the ramdisk,
used for early userspace startup. See initrd.
- rdrand= [X86]
+ rdrand= [X86,EARLY]
force - Override the decision by the kernel to hide the
advertisement of RDRAND support (this affects
certain AMD processors because of buggy BIOS
@@ -5180,7 +6325,7 @@
rdt= [HW,X86,RDT]
Turn on/off individual RDT features. List is:
cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
- mba.
+ mba, smba, bmec, abmc, sdciae.
E.g. to turn on cmt and turn off mba use:
rdt=cmt,!mba
@@ -5198,12 +6343,67 @@
reboot_cpu is s[mp]#### with #### being the processor
to be used for rebooting.
+ acpi
+ Use the ACPI RESET_REG in the FADT. If ACPI is not
+ configured or the ACPI reset does not work, the reboot
+ path attempts the reset using the keyboard controller.
+
+ bios
+ Use the CPU reboot vector for warm reset
+
+ cold
+ Set the cold reboot flag
+
+ default
+ There are some built-in platform specific "quirks"
+ - you may see: "reboot: <name> series board detected.
+ Selecting <type> for reboots." In the case where you
+ think the quirk is in error (e.g. you have newer BIOS,
+ or newer board) using this option will ignore the
+ built-in quirk table, and use the generic default
+ reboot actions.
+
+ efi
+ Use efi reset_system runtime service. If EFI is not
+ configured or the EFI reset does not work, the reboot
+ path attempts the reset using the keyboard controller.
+
+ force
+ Don't stop other CPUs on reboot. This can make reboot
+ more reliable in some cases.
+
+ kbd
+ Use the keyboard controller. cold reset (default)
+
+ pci
+ Use a write to the PCI config space register 0xcf9 to
+ trigger reboot.
+
+ triple
+ Force a triple fault (init)
+
+ warm
+ Don't set the cold reboot flag
+
+ Using warm reset will be much faster especially on big
+ memory systems because the BIOS will not go through
+ the memory check. Disadvantage is that not all
+ hardware will be completely reinitialized on reboot so
+ there may be boot problems on some systems.
+
+
refscale.holdoff= [KNL]
Set test-start holdoff period. The purpose of
this parameter is to delay the start of the
test until boot completes in order to avoid
interference.
+ refscale.lookup_instances= [KNL]
+ Number of data elements to use for the forms of
+ SLAB_TYPESAFE_BY_RCU testing. A negative number
+ is negated and multiplied by nr_cpu_ids, while
+ zero specifies nr_cpu_ids.
+
refscale.loops= [KNL]
Set the number of loops over the synchronization
primitive under test. Increasing this number
@@ -5243,6 +6443,13 @@
print every Nth verbose statement, where N is the value
specified.
+ regulator_ignore_unused
+ [REGULATOR]
+ Prevents regulator framework from disabling regulators
+ that are unused, due no driver claiming them. This may
+ be useful for debug and development, but should not be
+ needed on a platform with proper driver support.
+
relax_domain_level=
[KNL, SMP] Set scheduler's default relax_domain_level.
See Documentation/admin-guide/cgroup-v1/cpusets.rst.
@@ -5253,7 +6460,29 @@
them. If <base> is less than 0x10000, the region
is assumed to be I/O ports; otherwise it is memory.
- reservetop= [X86-32]
+ reserve_mem= [RAM]
+ Format: nn[KMG]:<align>:<label>
+ Reserve physical memory and label it with a name that
+ other subsystems can use to access it. This is typically
+ used for systems that do not wipe the RAM, and this command
+ line will try to reserve the same physical memory on
+ soft reboots. Note, it is not guaranteed to be the same
+ location. For example, if anything about the system changes
+ or if booting a different kernel. It can also fail if KASLR
+ places the kernel at the location of where the RAM reservation
+ was from a previous boot, the new reservation will be at a
+ different location.
+ Any subsystem using this feature must add a way to verify
+ that the contents of the physical memory is from a previous
+ boot, as there may be cases where the memory will not be
+ located at the same location.
+
+ The format is size:align:label for example, to request
+ 12 megabytes of 4096 alignment for ramoops:
+
+ reserve_mem=12M:4096:oops ramoops.mem_name=oops
+
+ reservetop= [X86-32,EARLY]
Format: nn[KMG]
Reserves a hole at the top of the kernel virtual
address space.
@@ -5279,7 +6508,8 @@
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
- retain_initrd [RAM] Keep initrd memory after extraction
+ retain_initrd [RAM] Keep initrd memory after extraction. After boot, it will
+ be accessible via /sys/firmware/initrd.
retbleed= [X86] Control mitigation of RETBleed (Arbitrary
Speculative Code Execution with Return Instructions)
@@ -5292,7 +6522,7 @@
that don't.
off - no mitigation
- auto - automatically select a migitation
+ auto - automatically select a mitigation
auto,nosmt - automatically select a mitigation,
disabling SMT if necessary for
the full mitigation (only on Zen1
@@ -5330,46 +6560,73 @@
2 The "airplane mode" button toggles between everything
blocked and everything unblocked.
- rhash_entries= [KNL,NET]
- Set number of hash buckets for route cache
-
ring3mwait=disable
[KNL] Disable ring 3 MONITOR/MWAIT feature on supported
CPUs.
+ riscv_isa_fallback [RISCV,EARLY]
+ When CONFIG_RISCV_ISA_FALLBACK is not enabled, permit
+ falling back to detecting extension support by parsing
+ "riscv,isa" property on devicetree systems when the
+ replacement properties are not found. See the Kconfig
+ entry for RISCV_ISA_FALLBACK.
+
ro [KNL] Mount root device read-only on boot
- rodata= [KNL]
+ rodata= [KNL,EARLY]
on Mark read-only kernel memory as read-only (default).
off Leave read-only kernel memory writable for debugging.
- full Mark read-only kernel memory and aliases as read-only
- [arm64]
+ noalias Mark read-only kernel memory as read-only but retain
+ writable aliases in the direct map for regions outside
+ of the kernel image. [arm64]
rockchip.usb_uart
+ [EARLY]
Enable the uart passthrough on the designated usb port
on Rockchip SoCs. When active, the signals of the
debug-uart get routed to the D+ and D- pins of the usb
port and the regular usb controller gets disabled.
root= [KNL] Root filesystem
- See name_to_dev_t comment in init/do_mounts.c.
+ Usually this is a block device specifier of some kind,
+ see the early_lookup_bdev comment in
+ block/early-lookup.c for details.
+ Alternatively this can be "ram" for the legacy initial
+ ramdisk, "nfs" and "cifs" for root on a network file
+ system, or "mtd" and "ubi" for mounting from raw flash.
rootdelay= [KNL] Delay (in seconds) to pause before attempting to
mount the root filesystem
rootflags= [KNL] Set root filesystem mount option string
+ initramfs_options= [KNL]
+ Specify mount options for for the initramfs mount.
+
rootfstype= [KNL] Set root filesystem type
rootwait [KNL] Wait (indefinitely) for root device to show up.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rootwait= [KNL] Maximum time (in seconds) to wait for root device
+ to show up before attempting to mount the root
+ filesystem.
+
rproc_mem=nn[KMG][@address]
[KNL,ARM,CMA] Remoteproc physical memory block.
Memory area to be used by remote processor image,
managed by CMA.
+ rseq_debug= [KNL] Enable or disable restartable sequence
+ debug mode. Defaults to CONFIG_RSEQ_DEBUG_DEFAULT_ENABLE.
+ Format: <bool>
+
+ rt_group_sched= [KNL] Enable or disable SCHED_RR/FIFO group scheduling
+ when CONFIG_RT_GROUP_SCHED=y. Defaults to
+ !CONFIG_RT_GROUP_SCHED_DEFAULT_DISABLED.
+ Format: <bool>
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
@@ -5377,9 +6634,10 @@
s390_iommu= [HW,S390]
Set s390 IOTLB flushing mode
strict
- With strict flushing every unmap operation will result in
- an IOTLB flush. Default is lazy flushing before reuse,
- which is faster.
+ With strict flushing every unmap operation will result
+ in an IOTLB flush. Default is lazy flushing before
+ reuse, which is faster. Deprecated, equivalent to
+ iommu.strict=1.
s390_iommu_aperture= [KNL,S390]
Specifies the size of the per device DMA address space
@@ -5396,7 +6654,12 @@
sa1100ir [NET]
See drivers/net/irda/sa1100_ir.c.
- sched_verbose [KNL] Enables verbose scheduler debug messages.
+ sched_proxy_exec= [KNL]
+ Enables or disables "proxy execution" style
+ solution to mutex-based priority inversion.
+ Format: <bool>
+
+ sched_verbose [KNL,EARLY] Enables verbose scheduler debug messages.
schedstats= [KNL,X86] Enable or disable scheduled statistics.
Allowed values are enable and disable. This feature
@@ -5404,6 +6667,7 @@
but is useful for debugging and performance tuning.
sched_thermal_decay_shift=
+ [Deprecated]
[KNL, SMP] Set a decay shift for scheduler thermal
pressure signal. Thermal pressure signal follows the
default decay period of other scheduler pelt
@@ -5511,7 +6775,11 @@
non-zero "wait" parameter. See weight_single
and weight_many.
- skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate
+ sdw_mclk_divider=[SDW]
+ Specify the MCLK divider for Intel SoundWire buses in
+ case the BIOS does not provide the clock rate properly.
+
+ skew_tick= [KNL,EARLY] Offset the periodic timer tick per cpu to mitigate
xtime_lock contention on larger systems, and/or RCU lock
contention on all systems with CONFIG_MAXSMP set.
Format: { "0" | "1" }
@@ -5531,82 +6799,99 @@
1 -- enable.
Default value is 1.
- apparmor= [APPARMOR] Disable or enable AppArmor at boot time
- Format: { "0" | "1" }
- See security/apparmor/Kconfig help text
- 0 -- disable.
- 1 -- enable.
- Default value is set via kernel config option.
-
serialnumber [BUGS=X86-32]
- sev=option[,option...] [X86-64] See Documentation/x86/x86_64/boot-options.rst
+ sev=option[,option...] [X86-64]
- shapers= [NET]
- Maximal number of shapers.
+ debug
+ Enable debug messages.
- simeth= [IA-64]
- simscsi=
-
- slram= [HW,MTD]
-
- slab_merge [MM]
- Enable merging of slabs with similar size when the
- kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
+ nosnp
+ Do not enable SEV-SNP (applies to host/hypervisor
+ only). Setting 'nosnp' avoids the RMP check overhead
+ in memory accesses when users do not want to run
+ SEV-SNP guests.
- slab_nomerge [MM]
- Disable merging of slabs with similar size. May be
- necessary if there is some reason to distinguish
- allocs to different slabs, especially in hardened
- environments where the risk of heap overflows and
- layout control by attackers can usually be
- frustrated by disabling merging. This will reduce
- most of the exposure of a heap attack to a single
- cache (risks via metadata attacks are mostly
- unchanged). Debug options disable merging on their
- own.
- For more information see Documentation/mm/slub.rst.
+ shapers= [NET]
+ Maximal number of shapers.
- slab_max_order= [MM, SLAB]
- Determines the maximum allowed order for slabs.
- A high setting may cause OOMs due to memory
- fragmentation. Defaults to 1 for systems with
- more than 32MB of RAM, 0 otherwise.
+ show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
+ Limit apic dumping. The parameter defines the maximal
+ number of local apics being dumped. Also it is possible
+ to set it to "all" by meaning -- no limit here.
+ Format: { 1 (default) | 2 | ... | all }.
+ The parameter valid if only apic=debug or
+ apic=verbose is specified.
+ Example: apic=debug show_lapic=all
- slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB]
- Enabling slub_debug allows one to determine the
+ slab_debug[=options[,slabs][;[options[,slabs]]...] [MM]
+ Enabling slab_debug allows one to determine the
culprit if slab objects become corrupted. Enabling
- slub_debug can create guard zones around objects and
+ slab_debug can create guard zones around objects and
may poison objects when not in use. Also tracks the
last alloc / free. For more information see
- Documentation/mm/slub.rst.
+ Documentation/admin-guide/mm/slab.rst.
+ (slub_debug legacy name also accepted for now)
+
+ Using this option implies the "no_hash_pointers"
+ option which can be undone by adding the
+ "hash_pointers=always" option.
- slub_max_order= [MM, SLUB]
+ slab_max_order= [MM]
Determines the maximum allowed order for slabs.
A high setting may cause OOMs due to memory
fragmentation. For more information see
- Documentation/mm/slub.rst.
+ Documentation/admin-guide/mm/slab.rst.
+ (slub_max_order legacy name also accepted for now)
- slub_min_objects= [MM, SLUB]
+ slab_merge [MM]
+ Enable merging of slabs with similar size when the
+ kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
+ (slub_merge legacy name also accepted for now)
+
+ slab_min_objects= [MM]
The minimum number of objects per slab. SLUB will
- increase the slab order up to slub_max_order to
+ increase the slab order up to slab_max_order to
generate a sufficiently large slab able to contain
the number of objects indicated. The higher the number
of objects the smaller the overhead of tracking slabs
and the less frequently locks need to be acquired.
- For more information see Documentation/mm/slub.rst.
+ For more information see
+ Documentation/admin-guide/mm/slab.rst.
+ (slub_min_objects legacy name also accepted for now)
- slub_min_order= [MM, SLUB]
+ slab_min_order= [MM]
Determines the minimum page order for slabs. Must be
- lower than slub_max_order.
- For more information see Documentation/mm/slub.rst.
+ lower or equal to slab_max_order. For more information see
+ Documentation/admin-guide/mm/slab.rst.
+ (slub_min_order legacy name also accepted for now)
- slub_merge [MM, SLUB]
- Same with slab_merge.
+ slab_nomerge [MM]
+ Disable merging of slabs with similar size. May be
+ necessary if there is some reason to distinguish
+ allocs to different slabs, especially in hardened
+ environments where the risk of heap overflows and
+ layout control by attackers can usually be
+ frustrated by disabling merging. This will reduce
+ most of the exposure of a heap attack to a single
+ cache (risks via metadata attacks are mostly
+ unchanged). Debug options disable merging on their
+ own.
+ For more information see
+ Documentation/admin-guide/mm/slab.rst.
+ (slub_nomerge legacy name also accepted for now)
+
+ slab_strict_numa [MM]
+ Support memory policies on a per object level
+ in the slab allocator. The default is for memory
+ policies to be applied at the folio level when
+ a new folio is needed or a partial folio is
+ retrieved from the lists. Increases overhead
+ in the slab fastpaths but gains more accurate
+ NUMA kernel object placement which helps with slow
+ interconnects in NUMA systems.
- slub_nomerge [MM, SLUB]
- Same with slab_nomerge. This is supported for legacy.
- See slab_nomerge for more information.
+ slram= [HW,MTD]
smart2= [HW]
Format: <io1>[,<io2>[,...,<io8>]]
@@ -5622,6 +6907,13 @@
This feature may be more efficiently disabled
using the csdlock_debug- kernel parameter.
+ smp.panic_on_ipistall= [KNL]
+ If a csd_lock_timeout extends for more than
+ the specified number of milliseconds, panic the
+ system. By default, let CSD-lock acquisition
+ take as long as they take. Specifying 300,000
+ for this value provides a 5-minute timeout.
+
smsc-ircc2.nopnp [HW] Don't use PNP to discover SMC devices
smsc-ircc2.ircc_cfg= [HW] Device configuration I/O port
smsc-ircc2.ircc_sir= [HW] SIR base I/O port
@@ -5633,10 +6925,10 @@
1: Fast pin select (default)
2: ATC IRMode
- smt= [KNL,S390] Set the maximum number of threads (logical
- CPUs) to use per physical CPU on systems capable of
- symmetric multithreading (SMT). Will be capped to the
- actual hardware limit.
+ smt= [KNL,MIPS,S390,EARLY] Set the maximum number of threads
+ (logical CPUs) to use per physical CPU on systems
+ capable of symmetric multithreading (SMT). Will
+ be capped to the actual hardware limit.
Format: <integer>
Default: -1 (no limit)
@@ -5658,7 +6950,22 @@
sonypi.*= [HW] Sony Programmable I/O Control Device driver
See Documentation/admin-guide/laptops/sonypi.rst
- spectre_v2= [X86] Control mitigation of Spectre variant 2
+ spectre_bhi= [X86] Control mitigation of Branch History Injection
+ (BHI) vulnerability. This setting affects the
+ deployment of the HW BHI control and the SW BHB
+ clearing sequence.
+
+ on - (default) Enable the HW or SW mitigation as
+ needed. This protects the kernel from
+ both syscalls and VMs.
+ vmexit - On systems which don't have the HW mitigation
+ available, enable the SW mitigation on vmexit
+ ONLY. On such systems, the host kernel is
+ protected from VM-originated BHI attacks, but
+ may still be vulnerable to syscall attacks.
+ off - Disable the mitigation.
+
+ spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2
(indirect branch speculation) vulnerability.
The default operation protects the kernel from
user space attacks.
@@ -5673,11 +6980,13 @@
Selecting 'on' will, and 'auto' may, choose a
mitigation method at run time according to the
CPU, the available microcode, the setting of the
- CONFIG_RETPOLINE configuration option, and the
- compiler with which the kernel was built.
+ CONFIG_MITIGATION_RETPOLINE configuration option,
+ and the compiler with which the kernel was built.
Selecting 'on' will also enable the mitigation
against user space to user space task attacks.
+ Selecting specific mitigation does not force enable
+ user mitigations.
Selecting 'off' will disable both the kernel and
the user space protections.
@@ -5688,9 +6997,9 @@
retpoline,generic - Retpolines
retpoline,lfence - LFENCE; indirect branch
retpoline,amd - alias for retpoline,lfence
- eibrs - enhanced IBRS
- eibrs,retpoline - enhanced IBRS + Retpolines
- eibrs,lfence - enhanced IBRS + LFENCE
+ eibrs - Enhanced/Auto IBRS
+ eibrs,retpoline - Enhanced/Auto IBRS + Retpolines
+ eibrs,lfence - Enhanced/Auto IBRS + LFENCE
ibrs - use IBRS to protect kernel
Not specifying this option is equivalent to
@@ -5737,8 +7046,19 @@
Not specifying this option is equivalent to
spectre_v2_user=auto.
+ spec_rstack_overflow=
+ [X86,EARLY] Control RAS overflow mitigation on AMD Zen CPUs
+
+ off - Disable mitigation
+ microcode - Enable microcode mitigation only
+ safe-ret - Enable sw-only safe RET mitigation (default)
+ ibpb - Enable mitigation by issuing IBPB on
+ kernel entry
+ ibpb-vmexit - Issue IBPB only on VMEXIT
+ (cloud-specific mitigation)
+
spec_store_bypass_disable=
- [HW] Control Speculative Store Bypass (SSB) Disable mitigation
+ [HW,EARLY] Control Speculative Store Bypass (SSB) Disable mitigation
(Speculative Store Bypass vulnerability)
Certain CPUs are vulnerable to an exploit against a
@@ -5789,11 +7109,6 @@
Not specifying this option is equivalent to
spec_store_bypass_disable=auto.
- spia_io_base= [HW,MTD]
- spia_fio_base=
- spia_pedr=
- spia_peddr=
-
split_lock_detect=
[X86] Enable split lock detection or bus lock detection
@@ -5834,7 +7149,7 @@
#DB exception for bus lock is triggered only when
CPL > 0.
- srbds= [X86,INTEL]
+ srbds= [X86,INTEL,EARLY]
Control the Special Register Buffer Data Sampling
(SRBDS) mitigation.
@@ -5921,7 +7236,7 @@
srcutree.convert_to_big must have the 0x10 bit
set for contention-based conversions to occur.
- ssbd= [ARM64,HW]
+ ssbd= [ARM64,HW,EARLY]
Speculative Store Bypass Disable control
On CPUs that are vulnerable to the Speculative
@@ -5945,14 +7260,19 @@
growing up) the main stack are reserved for no other
mapping. Default value is 256 pages.
- stack_depot_disable= [KNL]
+ stack_depot_disable= [KNL,EARLY]
Setting this to true through kernel command line will
disable the stack depot thereby saving the static memory
consumed by the stack hash table. By default this is set
to false.
+ stack_depot_max_pools= [KNL,EARLY]
+ Specify the maximum number of pools to use for storing
+ stack traces. Pools are allocated on-demand up to this
+ limit. Default value is 8191 pools.
+
stacktrace [FTRACE]
- Enabled the stack tracer on boot up.
+ Enable the stack tracer on boot up.
stacktrace_filter=[function-list]
[FTRACE] Limit the functions that the stack tracer
@@ -5984,6 +7304,19 @@
be used to filter out binaries which have
not yet been made aware of AT_MINSIGSTKSZ.
+ stress_hpt [PPC,EARLY]
+ Limits the number of kernel HPT entries in the hash
+ page table to increase the rate of hash page table
+ faults on kernel addresses.
+
+ stress_slb [PPC,EARLY]
+ Limits the number of kernel SLB entries, and flushes
+ them frequently to increase the rate of SLB faults
+ on kernel addresses.
+
+ no_slb_preload [PPC,EARLY]
+ Disables slb preloading for userspace.
+
sunrpc.min_resvport=
sunrpc.max_resvport=
[NFS,SUNRPC]
@@ -6039,13 +7372,7 @@
This parameter controls use of the Protected
Execution Facility on pSeries.
- swapaccount= [KNL]
- Format: [0|1]
- Enable accounting of swap in memory resource
- controller if no parameter or 1 is given or disable
- it if 0 is given (See Documentation/admin-guide/cgroup-v1/memory.rst)
-
- swiotlb= [ARM,IA-64,PPC,MIPS,X86]
+ swiotlb= [ARM,PPC,MIPS,X86,S390,EARLY]
Format: { <int> [,<int>] | force | noforce }
<int> -- Number of I/O TLB slabs
<int> -- Second integer after comma. Number of swiotlb
@@ -6055,7 +7382,7 @@
wouldn't be automatically used by the kernel
noforce -- Never use bounce buffers (for debugging)
- switches= [HW,M68k]
+ switches= [HW,M68k,EARLY]
sysctl.*= [KNL]
Set a sysctl parameter, right before loading the init
@@ -6066,15 +7393,6 @@
later by a loaded module cannot be set this way.
Example: sysctl.vm.swappiness=40
- sysfs.deprecated=0|1 [KNL]
- Enable/disable old style sysfs layout for old udev
- on older distributions. When this option is enabled
- very new udev will not work anymore. When this option
- is disabled (or CONFIG_SYSFS_DEPRECATED not compiled)
- in older udev will not work anymore.
- Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in
- the kernel configuration.
-
sysrq_always_enabled
[KNL]
Ignore sysrq setting - this boot parameter will
@@ -6110,10 +7428,6 @@
-1: disable all critical trip points in all thermal zones
<degrees C>: override all critical trip points
- thermal.nocrt= [HW,ACPI]
- Set to disable actions on ACPI thermal zone
- critical and hot trip points.
-
thermal.off= [HW,ACPI]
1: disable ACPI thermal control
@@ -6127,11 +7441,30 @@
<deci-seconds>: poll all this frequency
0: no polling (default)
- threadirqs [KNL]
+ thp_anon= [KNL]
+ Format: <size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>
+ state is one of "always", "madvise", "never" or "inherit".
+ Control the default behavior of the system with respect
+ to anonymous transparent hugepages.
+ Can be used multiple times for multiple anon THP sizes.
+ See Documentation/admin-guide/mm/transhuge.rst for more
+ details.
+
+ threadirqs [KNL,EARLY]
Force threading of all interrupt handlers except those
marked explicitly IRQF_NO_THREAD.
- topology= [S390]
+ thp_shmem= [KNL]
+ Format: <size>[KMG],<size>[KMG]:<policy>;<size>[KMG]-<size>[KMG]:<policy>
+ Control the default policy of each hugepage size for the
+ internal shmem mount. <policy> is one of policies available
+ for the shmem mount ("always", "inherit", "never", "within_size",
+ and "advise").
+ It can be used multiple times for multiple shmem THP sizes.
+ See Documentation/admin-guide/mm/transhuge.rst for more
+ details.
+
+ topology= [S390,EARLY]
Format: {off | on}
Specify if the kernel should make use of the cpu
topology information if the hardware supports this.
@@ -6139,12 +7472,6 @@
e.g. base its process migration decisions on it.
Default is on.
- topology_updates= [KNL, PPC, NUMA]
- Format: {off}
- Specify if the kernel should ignore (off)
- topology updates sent by the hypervisor to this
- LPAR.
-
torture.disable_onoff_at_boot= [KNL]
Prevent the CPU-hotplug component of torturing
until after init has spawned.
@@ -6164,7 +7491,22 @@
torture.verbose_sleep_duration= [KNL]
Duration of each verbose-printk() sleep in jiffies.
- tp720= [HW,PS2]
+ tpm.disable_pcr_integrity= [HW,TPM]
+ Do not protect PCR registers from unintended physical
+ access, or interposers in the bus by the means of
+ having an integrity protected session wrapped around
+ TPM2_PCR_Extend command. Consider this in a situation
+ where TPM is heavily utilized by IMA, thus protection
+ causing a major performance hit, and the space where
+ machines are deployed is by other means guarded.
+
+ tpm_crb_ffa.busy_timeout_ms= [ARM64,TPM]
+ Maximum time in milliseconds to retry sending a message
+ to the TPM service before giving up. This parameter controls
+ how long the system will continue retrying when the TPM
+ service is busy.
+ Format: <unsigned int>
+ Default: 2000 (2 seconds)
tpm_suspend_pcr=[HW,TPM]
Format: integer pcr id
@@ -6175,6 +7517,13 @@
This will guarantee that all the other pcrs
are saved.
+ tpm_tis.interrupts= [HW,TPM]
+ Enable interrupts for the MMIO based physical layer
+ for the FIFO interface. By default it is set to false
+ (0). For more information about TPM hardware interfaces
+ defined by Trusted Computing Group (TCG) see
+ https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
+
tp_printk [FTRACE]
Have the tracepoints sent to printk as well as the
tracing ring buffer. This is useful for early boot up
@@ -6185,7 +7534,7 @@
To turn off having tracepoints sent to printk,
echo 0 > /proc/sys/kernel/tracepoint_printk
Note, echoing 1 into this file without the
- tracepoint_printk kernel cmdline option has no effect.
+ tp_printk kernel cmdline option has no effect.
The tp_printk_stop_on_boot (see below) can also be used
to stop the printing of events to console at
@@ -6215,7 +7564,7 @@
(converted into nanoseconds). Fast, but
depending on the architecture, may not be
in sync between CPUs.
- global - Event time stamps are synchronize across
+ global - Event time stamps are synchronized across
CPUs. May be slower than the local clock,
but better for some race conditions.
counter - Simple counting of events (1, 2, ..)
@@ -6237,13 +7586,94 @@
comma-separated list of trace events to enable. See
also Documentation/trace/events.rst
+ To enable modules, use :mod: keyword:
+
+ trace_event=:mod:<module>
+
+ The value before :mod: will only enable specific events
+ that are part of the module. See the above mentioned
+ document for more information.
+
+ trace_instance=[instance-info]
+ [FTRACE] Create a ring buffer instance early in boot up.
+ This will be listed in:
+
+ /sys/kernel/tracing/instances
+
+ Events can be enabled at the time the instance is created
+ via:
+
+ trace_instance=<name>,<system1>:<event1>,<system2>:<event2>
+
+ Note, the "<system*>:" portion is optional if the event is
+ unique.
+
+ trace_instance=foo,sched:sched_switch,irq_handler_entry,initcall
+
+ will enable the "sched_switch" event (note, the "sched:" is optional, and
+ the same thing would happen if it was left off). The irq_handler_entry
+ event, and all events under the "initcall" system.
+
+ Flags can be added to the instance to modify its behavior when it is
+ created. The flags are separated by '^'.
+
+ The available flags are:
+
+ traceoff - Have the tracing instance tracing disabled after it is created.
+ traceprintk - Have trace_printk() write into this trace instance
+ (note, "printk" and "trace_printk" can also be used)
+
+ trace_instance=foo^traceoff^traceprintk,sched,irq
+
+ The flags must come before the defined events.
+
+ If memory has been reserved (see memmap for x86), the instance
+ can use that memory:
+
+ memmap=12M$0x284500000 trace_instance=boot_map@0x284500000:12M
+
+ The above will create a "boot_map" instance that uses the physical
+ memory at 0x284500000 that is 12Megs. The per CPU buffers of that
+ instance will be split up accordingly.
+
+ Alternatively, the memory can be reserved by the reserve_mem option:
+
+ reserve_mem=12M:4096:trace trace_instance=boot_map@trace
+
+ This will reserve 12 megabytes at boot up with a 4096 byte alignment
+ and place the ring buffer in this memory. Note that due to KASLR, the
+ memory may not be the same location each time, which will not preserve
+ the buffer content.
+
+ Also note that the layout of the ring buffer data may change between
+ kernel versions where the validator will fail and reset the ring buffer
+ if the layout is not the same as the previous kernel.
+
+ If the ring buffer is used for persistent bootups and has events enabled,
+ it is recommend to disable tracing so that events from a previous boot do not
+ mix with events of the current boot (unless you are debugging a random crash
+ at boot up).
+
+ reserve_mem=12M:4096:trace trace_instance=boot_map^traceoff^traceprintk@trace,sched,irq
+
+ Note, saving the trace buffer across reboots does require that the system
+ is set up to not wipe memory. For instance, CONFIG_RESET_ATTACK_MITIGATION
+ can force a memory reset on boot which will clear any trace that was stored.
+ This is just one of many ways that can clear memory. Make sure your system
+ keeps the content of memory across reboots before relying on this option.
+
+ NB: Both the mapped address and size must be page aligned for the architecture.
+
+ See also Documentation/trace/debugging.rst
+
+
trace_options=[option-list]
[FTRACE] Enable or disable tracer options at boot.
The option-list is a comma delimited list of options
that can be enabled or disabled just as if you were
to echo the option name into
- /sys/kernel/debug/tracing/trace_options
+ /sys/kernel/tracing/trace_options
For example, to enable stacktrace option (to dump the
stack trace of each event), add to the command line:
@@ -6253,11 +7683,39 @@
See also Documentation/trace/ftrace.rst "trace options"
section.
+ trace_trigger=[trigger-list]
+ [FTRACE] Add an event trigger on specific events.
+ Set a trigger on top of a specific event, with an optional
+ filter.
+
+ The format is "trace_trigger=<event>.<trigger>[ if <filter>],..."
+ Where more than one trigger may be specified that are comma delimited.
+
+ For example:
+
+ trace_trigger="sched_switch.stacktrace if prev_state == 2"
+
+ The above will enable the "stacktrace" trigger on the "sched_switch"
+ event but only trigger it if the "prev_state" of the "sched_switch"
+ event is "2" (TASK_UNINTERRUPTIBLE).
+
+ See also "Event triggers" in Documentation/trace/events.rst
+
+
+ traceoff_after_boot
+ [FTRACE] Sometimes tracing is used to debug issues
+ during the boot process. Since the trace buffer has a
+ limited amount of storage, it may be prudent to
+ disable tracing after the boot is finished, otherwise
+ the critical information may be overwritten. With this
+ option, the main tracing buffer will be turned off at
+ the end of the boot process.
+
traceoff_on_warning
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
be enabled again by echoing '1' into the "tracing_on"
- file located in /sys/kernel/debug/tracing/
+ file located in /sys/kernel/tracing/
This option is useful, as it disables the trace before
the WARNING dump is called, which prevents the trace to
@@ -6274,6 +7732,20 @@
See Documentation/admin-guide/mm/transhuge.rst
for more details.
+ transparent_hugepage_shmem= [KNL]
+ Format: [always|within_size|advise|never|deny|force]
+ Can be used to control the hugepage allocation policy for
+ the internal shmem mount.
+ See Documentation/admin-guide/mm/transhuge.rst
+ for more details.
+
+ transparent_hugepage_tmpfs= [KNL]
+ Format: [always|within_size|advise|never]
+ Can be used to control the default hugepage allocation policy
+ for the tmpfs mount.
+ See Documentation/admin-guide/mm/transhuge.rst
+ for more details.
+
trusted.source= [KEYS]
Format: <string>
This parameter identifies the trust source as a backend
@@ -6282,6 +7754,7 @@
- "tpm"
- "tee"
- "caam"
+ - "dcp"
If not specified then it defaults to iterating through
the trust source list starting with TPM and assigns the
first trust source as a backend which is initialized
@@ -6297,6 +7770,31 @@
If not specified, "default" is used. In this case,
the RNG's choice is left to each individual trust source.
+ trusted.dcp_use_otp_key
+ This is intended to be used in combination with
+ trusted.source=dcp and will select the DCP OTP key
+ instead of the DCP UNIQUE key blob encryption.
+
+ trusted.dcp_skip_zk_test
+ This is intended to be used in combination with
+ trusted.source=dcp and will disable the check if the
+ blob key is all zeros. This is helpful for situations where
+ having this key zero'ed is acceptable. E.g. in testing
+ scenarios.
+
+ tsa= [X86] Control mitigation for Transient Scheduler
+ Attacks on AMD CPUs. Search the following in your
+ favourite search engine for more details:
+
+ "Technical guidance for mitigating transient scheduler
+ attacks".
+
+ off - disable the mitigation
+ on - enable the mitigation (default)
+ user - mitigate only user/kernel transitions
+ vm - mitigate only guest/host transitions
+
+
tsc= Disable clocksource stability checks for TSC.
Format: <string>
[x86] reliable: mark tsc clocksource as reliable, this
@@ -6315,8 +7813,18 @@
in situations with strict latency requirements (where
interruptions from clocksource watchdog are not
acceptable).
-
- tsc_early_khz= [X86] Skip early TSC calibration and use the given
+ [x86] recalibrate: force recalibration against a HW timer
+ (HPET or PM timer) on systems whose TSC frequency was
+ obtained from HW or FW using either an MSR or CPUID(0x15).
+ Warn if the difference is more than 500 ppm.
+ [x86] watchdog: Use TSC as the watchdog clocksource with
+ which to check other HW timers (HPET or PM timer), but
+ only on systems where TSC has been deemed trustworthy.
+ This will be suppressed by an earlier tsc=nowatchdog and
+ can be overridden by a later tsc=nowatchdog. A console
+ message will flag any such suppression or overriding.
+
+ tsc_early_khz= [X86,EARLY] Skip early TSC calibration and use the given
value instead. Useful when the early TSC frequency discovery
procedure is not reliable, such as on overclocked systems
with CPUID.16h support and partial CPUID.15h support.
@@ -6351,7 +7859,7 @@
See Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
for more details.
- tsx_async_abort= [X86,INTEL] Control mitigation for the TSX Async
+ tsx_async_abort= [X86,INTEL,EARLY] Control mitigation for the TSX Async
Abort (TAA) vulnerability.
Similar to Micro-architectural Data Sampling (MDS)
@@ -6414,12 +7922,34 @@
Note that genuine overcurrent events won't be
reported either.
+ unaligned_scalar_speed=
+ [RISCV]
+ Format: {slow | fast | unsupported}
+ Allow skipping scalar unaligned access speed tests. This
+ is useful for testing alternative code paths and to skip
+ the tests in environments where they run too slowly. All
+ CPUs must have the same scalar unaligned access speed.
+
+ unaligned_vector_speed=
+ [RISCV]
+ Format: {slow | fast | unsupported}
+ Allow skipping vector unaligned access speed tests. This
+ is useful for testing alternative code paths and to skip
+ the tests in environments where they run too slowly. All
+ CPUs must have the same vector unaligned access speed.
+
unknown_nmi_panic
[X86] Cause panic on unknown NMI.
+ unwind_debug [X86-64,EARLY]
+ Enable unwinder debug output. This can be
+ useful for debugging certain unwinder error
+ conditions, including corrupt stacks and
+ bad/missing unwinder metadata.
+
usbcore.authorized_default=
[USB] Default USB device authorization:
- (default -1 = authorized except for wireless USB,
+ (default -1 = authorized (same as 1),
0 = not authorized, 1 = authorized, 2 = authorized
if device connected to internal port)
@@ -6517,6 +8047,9 @@
pause after every control message);
o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
delay after resetting its port);
+ p = USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT
+ (Reduce timeout of the SET_ADDRESS
+ request from 5000 ms to 500 ms);
Example: quirks=0781:5580:bk,0a5c:5834:gij
usbhid.mousepoll=
@@ -6531,6 +8064,9 @@
usb-storage.delay_use=
[UMS] The delay in seconds before a new device is
scanned for Logical Units (default 1).
+ Optionally the delay in milliseconds if the value has
+ suffix with "ms".
+ Example: delay_use=2567ms
usb-storage.quirks=
[UMS] A list of quirks entries to supplement or
@@ -6597,13 +8133,6 @@
16 - SIGBUS faults
Example: user_debug=31
- userpte=
- [X86] Flags controlling user PTE allocations.
-
- nohigh = do not allocate PTE pages in
- HIGHMEM regardless of setting
- of CONFIG_HIGHPTE.
-
vdso= [X86,SH,SPARC]
On X86_32, this is an alias for vdso32=. Otherwise:
@@ -6624,10 +8153,7 @@
Try vdso32=0 if you encounter an error that says:
dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
- vector= [IA-64,SMP]
- vector=percpu: enable percpu vector domain
-
- video= [FB] Frame buffer configuration
+ video= [FB,EARLY] Frame buffer configuration
See Documentation/fb/modedb.rst.
video.brightness_switch_enabled= [ACPI]
@@ -6657,7 +8183,7 @@
Can be used multiple times for multiple devices.
vga= [BOOT,X86-32] Select a particular video mode
- See Documentation/x86/boot.rst and
+ See Documentation/arch/x86/boot.rst and
Documentation/admin-guide/svga.rst.
Use vga=ask for menu.
This is actually a boot loader parameter; the value is
@@ -6675,13 +8201,16 @@
P Enable page structure init time poisoning
- Disable all of the above options
- vmalloc=nn[KMG] [KNL,BOOT] Forces the vmalloc area to have an exact
- size of <nn>. This can be used to increase the
- minimum size (128MB on x86). It can also be used to
- decrease the size and leave more room for directly
- mapped kernel RAM.
+ vmalloc=nn[KMG] [KNL,BOOT,EARLY] Forces the vmalloc area to have an
+ exact size of <nn>. This can be used to increase
+ the minimum size (128MB on x86, arm32 platforms).
+ It can also be used to decrease the size and leave more room
+ for directly mapped kernel RAM. Note that this parameter does
+ not exist on many other platforms (including arm64, alpha,
+ loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc,
+ parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc).
- vmcp_cma=nn[MG] [KNL,S390]
+ vmcp_cma=nn[MG] [KNL,S390,EARLY]
Sets the memory size reserved for contiguous memory
allocations for the vmcp device driver.
@@ -6694,7 +8223,17 @@
vmpoff= [KNL,S390] Perform z/VM CP command after power off.
Format: <command>
- vsyscall= [X86-64]
+ vmscape= [X86] Controls mitigation for VMscape attacks.
+ VMscape attacks can leak information from a userspace
+ hypervisor to a guest via speculative side-channels.
+
+ off - disable the mitigation
+ ibpb - use Indirect Branch Prediction Barrier
+ (IBPB) mitigation (default)
+ force - force vulnerability detection even on
+ unaffected processors
+
+ vsyscall= [X86-64,EARLY]
Controls the behavior of vsyscalls (i.e. calls to
fixed addresses of 0xffffffffff600x00 from legacy
code). Most statically-linked binaries and older
@@ -6702,11 +8241,11 @@
functions are at fixed addresses, they make nice
targets for exploits that can control RIP.
- emulate [default] Vsyscalls turn into traps and are
- emulated reasonably safely. The vsyscall
- page is readable.
+ emulate Vsyscalls turn into traps and are emulated
+ reasonably safely. The vsyscall page is
+ readable.
- xonly Vsyscalls turn into traps and are
+ xonly [default] Vsyscalls turn into traps and are
emulated reasonably safely. The vsyscall
page is not readable.
@@ -6721,7 +8260,7 @@
vt.cur_default= [VT] Default cursor shape.
Format: 0xCCBBAA, where AA, BB, and CC are the same as
the parameters of the <Esc>[?A;B;Cc escape sequence;
- see VGA-softcursor.txt. Default: 2 = underline.
+ see vga-softcursor.rst. Default: 2 = underline.
vt.default_blu= [VT]
Format: <blue0>,<blue1>,<blue2>,...,<blue15>
@@ -6776,6 +8315,13 @@
disables both lockup detectors. Default is 10
seconds.
+ workqueue.unbound_cpus=
+ [KNL,SMP] Specify to constrain one or some CPUs
+ to use in unbound workqueues.
+ Format: <cpu-list>
+ By default, all online CPUs are available for
+ unbound workqueues.
+
workqueue.watchdog_thresh=
If CONFIG_WQ_WATCHDOG is configured, workqueue can
warn stall conditions and dump internal state to
@@ -6785,14 +8331,33 @@
it can be updated at runtime by writing to the
corresponding sysfs file.
- workqueue.disable_numa
- By default, all work items queued to unbound
- workqueues are affine to the NUMA nodes they're
- issued on, which results in better behavior in
- general. If NUMA affinity needs to be disabled for
- whatever reason, this option can be used. Note
- that this also can be controlled per-workqueue for
- workqueues visible under /sys/bus/workqueue/.
+ workqueue.panic_on_stall=<uint>
+ Panic when workqueue stall is detected by
+ CONFIG_WQ_WATCHDOG. It sets the number times of the
+ stall to trigger panic.
+
+ The default is 0, which disables the panic on stall.
+
+ workqueue.cpu_intensive_thresh_us=
+ Per-cpu work items which run for longer than this
+ threshold are automatically considered CPU intensive
+ and excluded from concurrency management to prevent
+ them from noticeably delaying other per-cpu work
+ items. Default is 10000 (10ms).
+
+ If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel
+ will report the work functions which violate this
+ threshold repeatedly. They are likely good
+ candidates for using WQ_UNBOUND workqueues instead.
+
+ workqueue.cpu_intensive_warning_thresh=<uint>
+ If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel
+ will report the work functions which violate the
+ intensive_threshold_us repeatedly. In order to prevent
+ spurious warnings, start printing only after a work
+ function has violated this threshold number of times.
+
+ The default is 4 times. 0 disables the warning.
workqueue.power_efficient
Per-cpu workqueues are generally preferred because
@@ -6809,6 +8374,18 @@
The default value of this parameter is determined by
the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
+ workqueue.default_affinity_scope=
+ Select the default affinity scope to use for unbound
+ workqueues. Can be one of "cpu", "smt", "cache",
+ "numa" and "system". Default is "cache". For more
+ information, see the Affinity Scopes section in
+ Documentation/core-api/workqueue.rst.
+
+ This can be changed after boot by writing to the
+ matching /sys/module/workqueue/parameters file. All
+ workqueues with the "default" affinity scope will be
+ updated accordingly.
+
workqueue.debug_force_rr_cpu
Workqueue used to implicitly guarantee that work
items queued without explicit CPU specified are put
@@ -6820,7 +8397,13 @@
When enabled, memory and cache locality will be
impacted.
- x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
+ writecombine= [LOONGARCH,EARLY] Control the MAT (Memory Access
+ Type) of ioremap_wc().
+
+ on - Enable writecombine, use WUC for ioremap_wc()
+ off - Disable writecombine, use SUC for ioremap_wc()
+
+ x2apic_phys [X86-64,APIC,EARLY] Use x2apic physical mode instead of
default x2apic cluster mode on platforms
supporting x2apic.
@@ -6831,7 +8414,7 @@
save/restore/migration must be enabled to handle larger
domains.
- xen_emul_unplug= [HW,X86,XEN]
+ xen_emul_unplug= [HW,X86,XEN,EARLY]
Unplug Xen emulated devices
Format: [unplug0,][unplug1]
ide-disks -- unplug primary master IDE devices
@@ -6843,14 +8426,21 @@
the unplug protocol
never -- do not unplug even if version check succeeds
- xen_legacy_crash [X86,XEN]
+ xen_legacy_crash [X86,XEN,EARLY]
Crash from Xen panic notifier, without executing late
panic() code such as dumping handler.
- xen_nopvspin [X86,XEN]
- Disables the qspinlock slowpath using Xen PV optimizations.
- This parameter is obsoleted by "nopvspin" parameter, which
- has equivalent effect for XEN platform.
+ xen_mc_debug [X86,XEN,EARLY]
+ Enable multicall debugging when running as a Xen PV guest.
+ Enabling this feature will reduce performance a little
+ bit, so it should only be enabled for obtaining extended
+ debug data in case of multicall errors.
+
+ xen_msr_safe= [X86,XEN,EARLY]
+ Format: <bool>
+ Select whether to always use non-faulting (safe) MSR
+ access functions when running as Xen PV guest. The
+ default value is controlled by CONFIG_XEN_PV_MSR_SAFE.
xen_nopv [X86]
Disables the PV optimizations forcing the HVM guest to
@@ -6859,7 +8449,7 @@
has equivalent effect for XEN platform.
xen_no_vector_callback
- [KNL,X86,XEN] Disable the vector callback for Xen
+ [KNL,X86,XEN,EARLY] Disable the vector callback for Xen
event channel interrupts.
xen_scrub_pages= [XEN]
@@ -6868,7 +8458,7 @@
with /sys/devices/system/xen_memory/xen_memory0/scrub_pages.
Default value controlled with CONFIG_XEN_SCRUB_PAGES_DEFAULT.
- xen_timer_slop= [X86-64,XEN]
+ xen_timer_slop= [X86-64,XEN,EARLY]
Set the timer slop (in nanoseconds) for the virtual Xen
timers (default is 100000). This adjusts the minimum
delta of virtualized Xen timers, where lower values
@@ -6897,16 +8487,6 @@
fairer and the number of possible event channels is
much higher. Default is on (use fifo events).
- nopv= [X86,XEN,KVM,HYPER_V,VMWARE]
- Disables the PV optimizations forcing the guest to run
- as generic guest with no PV drivers. Currently support
- XEN HVM, KVM, HYPER_V and VMWARE guest.
-
- nopvspin [X86,XEN,KVM]
- Disables the qspinlock slow path using PV optimizations
- which allow the hypervisor to 'idle' the guest on lock
- contention.
-
xirc2ps_cs= [NET,PCMCIA]
Format:
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
@@ -6931,7 +8511,7 @@
host controller quirks. Meaning of each bit can be
consulted in header drivers/usb/host/xhci.h.
- xmon [PPC]
+ xmon [PPC,EARLY]
Format: { early | on | rw | ro | off }
Controls if xmon debugger is enabled. Default is off.
Passing only "xmon" is equivalent to "xmon=early".
diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
index e4a5fc26f1a9..ee9a6c94f383 100644
--- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
+++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst
@@ -25,7 +25,7 @@ References
- In order to locate kernel-generated OS jitter on CPU N:
- cd /sys/kernel/debug/tracing
+ cd /sys/kernel/tracing
echo 1 > max_graph_depth # Increase the "1" for more detail
echo function_graph > current_tracer
# run workload
@@ -243,13 +243,9 @@ To reduce its OS jitter, do any of the following:
3. Do any of the following needed to avoid jitter that your
application cannot tolerate:
- a. Build your kernel with CONFIG_SLUB=y rather than
- CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
- use of each CPU's workqueues to run its cache_reap()
- function.
- b. Avoid using oprofile, thus avoiding OS jitter from
+ a. Avoid using oprofile, thus avoiding OS jitter from
wq_sync_buffer().
- c. Limit your CPU frequency so that a CPU-frequency
+ b. Limit your CPU frequency so that a CPU-frequency
governor is not required, possibly enlisting the aid of
special heatsinks or other cooling technologies. If done
correctly, and if you CPU architecture permits, you should
@@ -259,7 +255,7 @@ To reduce its OS jitter, do any of the following:
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
- d. As of v3.18, Christoph Lameter's on-demand vmstat workers
+ c. As of v3.18, Christoph Lameter's on-demand vmstat workers
commit prevents OS jitter due to vmstat_update() on
CONFIG_SMP=y systems. Before v3.18, is not possible
to entirely get rid of the OS jitter, but you can
@@ -274,7 +270,7 @@ To reduce its OS jitter, do any of the following:
(based on an earlier one from Gilad Ben-Yossef) that
reduces or even eliminates vmstat overhead for some
workloads at https://lore.kernel.org/r/00000140e9dfd6bd-40db3d4f-c1be-434f-8132-7820f81bb586-000000@email.amazonses.com.
- e. If running on high-end powerpc servers, build with
+ d. If running on high-end powerpc servers, build with
CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
daemon from running on each CPU every second or so.
(This will require editing Kconfig files and will defeat
@@ -282,12 +278,7 @@ To reduce its OS jitter, do any of the following:
due to the rtas_event_scan() function.
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
- f. If running on Cell Processor, build your kernel with
- CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
- spu_gov_work().
- WARNING: Please check your CPU specifications to
- make sure that this is safe on your particular system.
- g. If running on PowerMAC, build your kernel with
+ e. If running on PowerMAC, build your kernel with
CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
avoiding OS jitter from rackmeter_do_timer().
@@ -319,7 +310,7 @@ To reduce its OS jitter, do at least one of the following:
to do.
Name:
- rcuop/%d and rcuos/%d
+ rcuop/%d, rcuos/%d, and rcuog/%d
Purpose:
Offload RCU callbacks from the corresponding CPU.
diff --git a/Documentation/admin-guide/laptops/alienware-wmi.rst b/Documentation/admin-guide/laptops/alienware-wmi.rst
new file mode 100644
index 000000000000..27a32a8057da
--- /dev/null
+++ b/Documentation/admin-guide/laptops/alienware-wmi.rst
@@ -0,0 +1,127 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+====================
+Alienware WMI Driver
+====================
+
+Kurt Borja <kuurtb@gmail.com>
+
+This is a driver for the "WMAX" WMI device, which is found in most Dell gaming
+laptops and controls various special features.
+
+Before the launch of M-Series laptops (~2018), the "WMAX" device controlled
+basic RGB lighting, deep sleep mode, HDMI mode and amplifier status.
+
+Later, this device was completely repurpused. Now it mostly deals with thermal
+profiles, sensor monitoring and overclocking. This interface is named "AWCC" and
+is known to be used by the AWCC OEM application to control these features.
+
+The alienware-wmi driver controls both interfaces.
+
+AWCC Interface
+==============
+
+WMI device documentation: Documentation/wmi/devices/alienware-wmi.rst
+
+Supported devices
+-----------------
+
+- Alienware M-Series laptops
+- Alienware X-Series laptops
+- Alienware Aurora Desktops
+- Dell G-Series laptops
+
+If you believe your device supports the AWCC interface and you don't have any of
+the features described in this document, try the following alienware-wmi module
+parameters:
+
+- ``force_platform_profile=1``: Forces probing for platform profile support
+- ``force_hwmon=1``: Forces probing for HWMON support
+
+If the module loads successfully with these parameters, consider submitting a
+patch adding your model to the ``awcc_dmi_table`` located in
+``drivers/platform/x86/dell/alienware-wmi-wmax.c`` or contacting the maintainer
+for further guidance.
+
+Status
+------
+
+The following features are currently supported:
+
+- :ref:`Platform Profile <platform-profile>`:
+
+ - Thermal profile control
+
+ - G-Mode toggling
+
+- :ref:`HWMON <hwmon>`:
+
+ - Sensor monitoring
+
+ - Manual fan control
+
+.. _platform-profile:
+
+Platform Profile
+----------------
+
+The AWCC interface exposes various firmware defined thermal profiles. These are
+exposed to user-space through the Platform Profile class interface. Refer to
+:ref:`sysfs-class-platform-profile <abi_file_testing_sysfs_class_platform_profile>`
+for more information.
+
+The name of the platform-profile class device exported by this driver is
+"alienware-wmi" and it's path can be found with:
+
+::
+
+ grep -l "alienware-wmi" /sys/class/platform-profile/platform-profile-*/name | sed 's|/[^/]*$||'
+
+If the device supports G-Mode, it is also toggled when selecting the
+``performance`` profile.
+
+.. note::
+ You may set the ``force_gmode`` module parameter to always try to toggle this
+ feature, without checking if your model supports it.
+
+.. _hwmon:
+
+HWMON
+-----
+
+The AWCC interface also supports sensor monitoring and manual fan control. Both
+of these features are exposed to user-space through the HWMON interface.
+
+The name of the hwmon class device exported by this driver is "alienware_wmi"
+and it's path can be found with:
+
+::
+
+ grep -l "alienware_wmi" /sys/class/hwmon/hwmon*/name | sed 's|/[^/]*$||'
+
+Sensor monitoring is done through the standard HWMON interface. Refer to
+:ref:`sysfs-class-hwmon <abi_file_testing_sysfs_class_hwmon>` for more
+information.
+
+Manual fan control on the other hand, is not exposed directly by the AWCC
+interface. Instead it let's us control a fan `boost` value. This `boost` value
+has the following aproximate behavior over the fan pwm:
+
+::
+
+ pwm = pwm_base + (fan_boost / 255) * (pwm_max - pwm_base)
+
+Due to the above behavior, the fan `boost` control is exposed to user-space
+through the following, custom hwmon sysfs attribute:
+
+=============================== ======= =======================================
+Name Perm Description
+=============================== ======= =======================================
+fan[1-4]_boost RW Fan boost value.
+
+ Integer value between 0 and 255
+=============================== ======= =======================================
+
+.. note::
+ In some devices, manual fan control only works reliably if the ``custom``
+ platform profile is selected.
diff --git a/Documentation/admin-guide/laptops/index.rst b/Documentation/admin-guide/laptops/index.rst
index cd9a1c2695fd..6432c251dc95 100644
--- a/Documentation/admin-guide/laptops/index.rst
+++ b/Documentation/admin-guide/laptops/index.rst
@@ -7,11 +7,14 @@ Laptop Drivers
.. toctree::
:maxdepth: 1
+ alienware-wmi
asus-laptop
disk-shock-protection
laptop-mode
lg-laptop
+ samsung-galaxybook
sony-laptop
sonypi
thinkpad-acpi
toshiba_haps
+ uniwill-laptop
diff --git a/Documentation/admin-guide/laptops/laptop-mode.rst b/Documentation/admin-guide/laptops/laptop-mode.rst
index b61cc601d298..66eb9cd918b5 100644
--- a/Documentation/admin-guide/laptops/laptop-mode.rst
+++ b/Documentation/admin-guide/laptops/laptop-mode.rst
@@ -61,7 +61,7 @@ Caveats
Check your drive's rating, and don't wear down your drive's lifetime if you
don't need to.
-* If you mount some of your ext3/reiserfs filesystems with the -n option, then
+* If you mount some of your ext3 filesystems with the -n option, then
the control script will not be able to remount them correctly. You must set
DO_REMOUNTS=0 in the control script, otherwise it will remount them with the
wrong options -- or it will fail because it cannot write to /etc/mtab.
@@ -96,7 +96,7 @@ control script increases dirty_expire_centisecs and dirty_writeback_centisecs in
dirtied are not forced to be written to disk as often. The control script also
changes the dirty background ratio, so that background writeback of dirty pages
is not done anymore. Combined with a higher commit value (also 10 minutes) for
-ext3 or ReiserFS filesystems (also done automatically by the control script),
+ext3 filesystem (also done automatically by the control script),
this results in concentration of disk activity in a small time interval which
occurs only once every 10 minutes, or whenever the disk is forced to spin up by
a cache miss. The disk can then be spun down in the periods of inactivity.
@@ -587,7 +587,7 @@ Control script::
FST=$(deduce_fstype $MP)
fi
case "$FST" in
- "ext3"|"reiserfs")
+ "ext3")
PARSEDOPTS="$(parse_mount_opts commit "$OPTS")"
mount $DEV -t $FST $MP -o remount,$PARSEDOPTS,commit=$MAX_AGE$NOATIME_OPT
;;
@@ -647,7 +647,7 @@ Control script::
FST=$(deduce_fstype $MP)
fi
case "$FST" in
- "ext3"|"reiserfs")
+ "ext3")
PARSEDOPTS="$(parse_mount_opts_wfstab $DEV commit $OPTS)"
PARSEDOPTS="$(parse_yesno_opts_wfstab $DEV atime atime $PARSEDOPTS)"
mount $DEV -t $FST $MP -o remount,$PARSEDOPTS
diff --git a/Documentation/admin-guide/laptops/lg-laptop.rst b/Documentation/admin-guide/laptops/lg-laptop.rst
index 67fd6932cef4..c4dd534f91ed 100644
--- a/Documentation/admin-guide/laptops/lg-laptop.rst
+++ b/Documentation/admin-guide/laptops/lg-laptop.rst
@@ -48,8 +48,8 @@ This value is reset to 100 when the kernel boots.
Fan mode
--------
-Writing 1/0 to /sys/devices/platform/lg-laptop/fan_mode disables/enables
-the fan silent mode.
+Writing 0/1/2 to /sys/devices/platform/lg-laptop/fan_mode sets fan mode to
+Optimal/Silent/Performance respectively.
USB charge
diff --git a/Documentation/admin-guide/laptops/samsung-galaxybook.rst b/Documentation/admin-guide/laptops/samsung-galaxybook.rst
new file mode 100644
index 000000000000..752b8f1a4a74
--- /dev/null
+++ b/Documentation/admin-guide/laptops/samsung-galaxybook.rst
@@ -0,0 +1,174 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================
+Samsung Galaxy Book Driver
+==========================
+
+Joshua Grisham <josh@joshuagrisham.com>
+
+This is a Linux x86 platform driver for Samsung Galaxy Book series notebook
+devices which utilizes Samsung's ``SCAI`` ACPI device in order to control
+extra features and receive various notifications.
+
+Supported devices
+=================
+
+Any device with one of the supported ACPI device IDs should be supported. This
+covers most of the "Samsung Galaxy Book" series notebooks that are currently
+available as of this writing, and could include other Samsung notebook devices
+as well.
+
+Status
+======
+
+The following features are currently supported:
+
+- :ref:`Keyboard backlight <keyboard-backlight>` control
+- :ref:`Performance mode <performance-mode>` control implemented using the
+ platform profile interface
+- :ref:`Battery charge control end threshold
+ <battery-charge-control-end-threshold>` (stop charging battery at given
+ percentage value) implemented as a battery hook
+- :ref:`Firmware Attributes <firmware-attributes>` to allow control of various
+ device settings
+- :ref:`Handling of Fn hotkeys <keyboard-hotkey-actions>` for various actions
+- :ref:`Handling of ACPI notifications and hotkeys
+ <acpi-notifications-and-hotkey-actions>`
+
+Because different models of these devices can vary in their features, there is
+logic built within the driver which attempts to test each implemented feature
+for a valid response before enabling its support (registering additional devices
+or extensions, adding sysfs attributes, etc). Therefore, it can be important to
+note that not all features may be supported for your particular device.
+
+The following features might be possible to implement but will require
+additional investigation and are therefore not supported at this time:
+
+- "Dolby Atmos" mode for the speakers
+- "Outdoor Mode" for increasing screen brightness on models with ``SAM0427``
+- "Silent Mode" on models with ``SAM0427``
+
+.. _keyboard-backlight:
+
+Keyboard backlight
+==================
+
+A new LED class named ``samsung-galaxybook::kbd_backlight`` is created which
+will then expose the device using the standard sysfs-based LED interface at
+``/sys/class/leds/samsung-galaxybook::kbd_backlight``. Brightness can be
+controlled by writing the desired value to the ``brightness`` sysfs attribute or
+with any other desired userspace utility.
+
+.. note::
+ Most of these devices have an ambient light sensor which also turns
+ off the keyboard backlight under well-lit conditions. This behavior does not
+ seem possible to control at this time, but can be good to be aware of.
+
+.. _performance-mode:
+
+Performance mode
+================
+
+This driver implements the
+Documentation/userspace-api/sysfs-platform_profile.rst interface for working
+with the "performance mode" function of the Samsung ACPI device.
+
+Mapping of each Samsung "performance mode" to its respective platform profile is
+performed dynamically by the driver, as not all models support all of the same
+performance modes. Your device might have one or more of the following mappings:
+
+- "Silent" maps to ``low-power``
+- "Quiet" maps to ``quiet``
+- "Optimized" maps to ``balanced``
+- "High performance" maps to ``performance``
+
+The result of the mapping can be printed in the kernel log when the module is
+loaded. Supported profiles can also be retrieved from
+``/sys/firmware/acpi/platform_profile_choices``, while
+``/sys/firmware/acpi/platform_profile`` can be used to read or write the
+currently selected profile.
+
+The ``balanced`` platform profile will be set during module load if no profile
+has been previously set.
+
+.. _battery-charge-control-end-threshold:
+
+Battery charge control end threshold
+====================================
+
+This platform driver will add the ability to set the battery's charge control
+end threshold, but does not have the ability to set a start threshold.
+
+This feature is typically called "Battery Saver" by the various Samsung
+applications in Windows, but in Linux we have implemented the standardized
+"charge control threshold" sysfs interface on the battery device to allow for
+controlling this functionality from the userspace.
+
+The sysfs attribute
+``/sys/class/power_supply/BAT1/charge_control_end_threshold`` can be used to
+read or set the desired charge end threshold.
+
+If you wish to maintain interoperability with the Samsung Settings application
+in Windows, then you should set the value to 100 to represent "off", or enable
+the feature using only one of the following values: 50, 60, 70, 80, or 90.
+Otherwise, the driver will accept any value between 1 and 100 as the percentage
+that you wish the battery to stop charging at.
+
+.. note::
+ Some devices have been observed as automatically "turning off" the charge
+ control end threshold if an input value of less than 30 is given.
+
+.. _firmware-attributes:
+
+Firmware Attributes
+===================
+
+The following enumeration-typed firmware attributes are set up by this driver
+and should be accessible under
+``/sys/class/firmware-attributes/samsung-galaxybook/attributes/`` if your device
+supports them:
+
+- ``power_on_lid_open`` (device should power on when the lid is opened)
+- ``usb_charging`` (USB ports can deliver power to connected devices even when
+ the device is powered off or in a low sleep state)
+- ``block_recording`` (blocks access to camera and microphone)
+
+All of these attributes are simple boolean-like enumeration values which use 0
+to represent "off" and 1 to represent "on". Use the ``current_value`` attribute
+to get or change the setting on the device.
+
+Note that when ``block_recording`` is updated, the input device "Samsung Galaxy
+Book Lens Cover" will receive a ``SW_CAMERA_LENS_COVER`` switch event which
+reflects the current state.
+
+.. _keyboard-hotkey-actions:
+
+Keyboard hotkey actions (i8042 filter)
+======================================
+
+The i8042 filter will swallow the keyboard events for the Fn+F9 hotkey (Multi-
+level keyboard backlight toggle) and Fn+F10 hotkey (Block recording toggle)
+and instead execute their actions within the driver itself.
+
+Fn+F9 will cycle through the brightness levels of the keyboard backlight. A
+notification will be sent using ``led_classdev_notify_brightness_hw_changed``
+so that the userspace can be aware of the change. This mimics the behavior of
+other existing devices where the brightness level is cycled internally by the
+embedded controller and then reported via a notification.
+
+Fn+F10 will toggle the value of the "block recording" setting, which blocks
+or allows usage of the built-in camera and microphone (and generates the same
+Lens Cover switch event mentioned above).
+
+.. _acpi-notifications-and-hotkey-actions:
+
+ACPI notifications and hotkey actions
+=====================================
+
+ACPI notifications will generate ACPI netlink events under the device class
+``samsung-galaxybook`` and bus ID matching the Samsung ACPI device ID found on
+your device. The events can be received using userspace tools such as
+``acpi_listen`` and ``acpid``.
+
+The Fn+F11 Performance mode hotkey will be handled by the driver; each keypress
+will cycle to the next available platform profile.
diff --git a/Documentation/admin-guide/laptops/sonypi.rst b/Documentation/admin-guide/laptops/sonypi.rst
index 190da1234314..7541f56e0007 100644
--- a/Documentation/admin-guide/laptops/sonypi.rst
+++ b/Documentation/admin-guide/laptops/sonypi.rst
@@ -25,7 +25,7 @@ generate, like:
(when available)
Those events (see linux/sonypi.h) can be polled using the character device node
-/dev/sonypi (major 10, minor auto allocated or specified as a option).
+/dev/sonypi (major 10, minor auto allocated or specified as an option).
A simple daemon which translates the jogdial movements into mouse wheel events
can be downloaded at: <http://popies.net/sonypi/>
diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
index 475eb0e81e4a..4ab0fef7d440 100644
--- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -53,6 +53,7 @@ detailed description):
- Lap mode sensor
- Setting keyboard language
- WWAN Antenna type
+ - Auxmac
A compatibility table by model and feature is maintained on the web
site, http://ibm-acpi.sf.net/. I appreciate any success or failure
@@ -443,7 +444,11 @@ event code Key Notes
0x1008 0x07 FN+F8 IBM: toggle screen expand
Lenovo: configure UltraNav,
- or toggle screen expand
+ or toggle screen expand.
+ On 2024 platforms replaced by
+ 0x131f (see below) and on newer
+ platforms (2025 +) keycode is
+ replaced by 0x1401 (see below).
0x1009 0x08 FN+F9 -
@@ -503,6 +508,11 @@ event code Key Notes
0x1019 0x18 unknown
+0x131f ... FN+F8 Platform Mode change (2024 systems).
+ Implemented in driver.
+
+0x1401 ... FN+F8 Platform Mode change (2025 + systems).
+ Implemented in driver.
... ... ...
0x1020 0x1F unknown
@@ -1488,7 +1498,7 @@ Example of command to set keyboard language is mentioned below::
Text corresponding to keyboard layout to be set in sysfs are: be(Belgian),
cz(Czech), da(Danish), de(German), en(English), es(Spain), et(Estonian),
fr(French), fr-ch(French(Switzerland)), hu(Hungarian), it(Italy), jp (Japan),
-nl(Dutch), nn(Norway), pl(Polish), pt(portugese), sl(Slovenian), sv(Sweden),
+nl(Dutch), nn(Norway), pl(Polish), pt(portuguese), sl(Slovenian), sv(Sweden),
tr(Turkey)
WWAN Antenna type
@@ -1511,6 +1521,25 @@ Currently 2 antenna types are supported as mentioned below:
The property is read-only. If the platform doesn't have support the sysfs
class is not created.
+Auxmac
+------
+
+sysfs: auxmac
+
+Some newer Thinkpads have a feature called MAC Address Pass-through. This
+feature is implemented by the system firmware to provide a system unique MAC,
+that can override a dock or USB ethernet dongle MAC, when connected to a
+network. This property enables user-space to easily determine the MAC address
+if the feature is enabled.
+
+The values of this auxiliary MAC are:
+
+ cat /sys/devices/platform/thinkpad_acpi/auxmac
+
+If the feature is disabled, the value will be 'disabled'.
+
+This property is read-only.
+
Adaptive keyboard
-----------------
diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst b/Documentation/admin-guide/laptops/uniwill-laptop.rst
new file mode 100644
index 000000000000..a16baf15516b
--- /dev/null
+++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Uniwill laptop extra features
+=============================
+
+On laptops manufactured by Uniwill (either directly or as ODM), the ``uniwill-laptop`` driver
+handles various platform-specific features.
+
+Module Loading
+--------------
+
+The ``uniwill-laptop`` driver relies on a DMI table to automatically load on supported devices.
+When using the ``force`` module parameter, this DMI check will be omitted, allowing the driver
+to be loaded on unsupported devices for testing purposes.
+
+Hotkeys
+-------
+
+Usually the FN keys work without a special driver. However as soon as the ``uniwill-laptop`` driver
+is loaded, the FN keys need to be handled manually. This is done automatically by the driver itself.
+
+Keyboard settings
+-----------------
+
+The ``uniwill-laptop`` driver allows the user to enable/disable:
+
+ - the FN and super key lock functionality of the integrated keyboard
+ - the touchpad toggle functionality of the integrated touchpad
+
+See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
+
+Hwmon interface
+---------------
+
+The ``uniwill-laptop`` driver supports reading of the CPU and GPU temperature and supports up to
+two fans. Userspace applications can access sensor readings over the hwmon sysfs interface.
+
+Platform profile
+----------------
+
+Support for changing the platform performance mode is currently not implemented.
+
+Battery Charging Control
+------------------------
+
+The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over
+the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values
+between 1 and 100 percent are supported.
+
+Additionally the driver signals the presence of battery charging issues through the standard
+``health`` power supply sysfs attribute.
+
+Lightbar
+--------
+
+The ``uniwill-laptop`` driver exposes the lightbar found on some models as a standard multicolor
+LED class device. The default name of this LED class device is ``uniwill:multicolor:status``.
+
+See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various
+animation modes of the lightbar.
diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst
index d8fc9a59c086..dc7eab191caa 100644
--- a/Documentation/admin-guide/md.rst
+++ b/Documentation/admin-guide/md.rst
@@ -238,6 +238,16 @@ All md devices contain:
the number of devices in a raid4/5/6, or to support external
metadata formats which mandate such clipping.
+ logical_block_size
+ Configure the array's logical block size in bytes. This attribute
+ is only supported for 1.x meta. Write the value before starting
+ array. The final array LBS uses the maximum between this
+ configuration and LBS of all combined devices. Note that
+ LBS cannot exceed PAGE_SIZE before RAID supports folio.
+ WARNING: Arrays created on new kernel cannot be assembled at old
+ kernel due to padding check, Set module parameter 'check_new_feature'
+ to false to bypass, but data loss may occur.
+
reshape_position
This is either ``none`` or a sector number within the devices of
the array where ``reshape`` is up to. If this is set, the three
@@ -317,7 +327,7 @@ All md devices contain:
suspended (not supported yet)
All IO requests will block. The array can be reconfigured.
- Writing this, if accepted, will block until array is quiessent
+ Writing this, if accepted, will block until array is quiescent
readonly
no resync can happen. no superblocks get written.
@@ -347,6 +357,54 @@ All md devices contain:
active-idle
like active, but no writes have been seen for a while (safe_mode_delay).
+ consistency_policy
+ This indicates how the array maintains consistency in case of unexpected
+ shutdown. It can be:
+
+ none
+ Array has no redundancy information, e.g. raid0, linear.
+
+ resync
+ Full resync is performed and all redundancy is regenerated when the
+ array is started after unclean shutdown.
+
+ bitmap
+ Resync assisted by a write-intent bitmap.
+
+ journal
+ For raid4/5/6, journal device is used to log transactions and replay
+ after unclean shutdown.
+
+ ppl
+ For raid5 only, Partial Parity Log is used to close the write hole and
+ eliminate resync.
+
+ The accepted values when writing to this file are ``ppl`` and ``resync``,
+ used to enable and disable PPL.
+
+ uuid
+ This indicates the UUID of the array in the following format:
+ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+
+ bitmap_type
+ [RW] When read, this file will display the current and available
+ bitmap for this array. The currently active bitmap will be enclosed
+ in [] brackets. Writing an bitmap name or ID to this file will switch
+ control of this array to that new bitmap. Note that writing a new
+ bitmap for created array is forbidden.
+
+ none
+ No bitmap
+ bitmap
+ The default internal bitmap
+ llbitmap
+ The lockless internal bitmap
+
+If bitmap_type is not none, then additional bitmap attributes bitmap/xxx or
+llbitmap/xxx will be created after md device KOBJ_CHANGE event.
+
+If bitmap_type is bitmap, then the md device will also contain:
+
bitmap/location
This indicates where the write-intent bitmap for the array is
stored.
@@ -401,35 +459,23 @@ All md devices contain:
once the array becomes non-degraded, and this fact has been
recorded in the metadata.
- consistency_policy
- This indicates how the array maintains consistency in case of unexpected
- shutdown. It can be:
-
- none
- Array has no redundancy information, e.g. raid0, linear.
-
- resync
- Full resync is performed and all redundancy is regenerated when the
- array is started after unclean shutdown.
-
- bitmap
- Resync assisted by a write-intent bitmap.
+If bitmap_type is llbitmap, then the md device will also contain:
- journal
- For raid4/5/6, journal device is used to log transactions and replay
- after unclean shutdown.
+ llbitmap/bits
+ This is read-only, show status of bitmap bits, the number of each
+ value.
- ppl
- For raid5 only, Partial Parity Log is used to close the write hole and
- eliminate resync.
-
- The accepted values when writing to this file are ``ppl`` and ``resync``,
- used to enable and disable PPL.
+ llbitmap/metadata
+ This is read-only, show bitmap metadata, include chunksize, chunkshift,
+ chunks, offset and daemon_sleep.
- uuid
- This indicates the UUID of the array in the following format:
- xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+ llbitmap/daemon_sleep
+ This is read-write, time in seconds that daemon function will be
+ triggered to clear dirty bits.
+ llbitmap/barrier_idle
+ This is read-write, time in seconds that page barrier will be idled,
+ means dirty bits in the page will be cleared.
As component devices are added to an md array, they appear in the ``md``
directory as new directories named::
@@ -758,7 +804,7 @@ These currently include:
journal_mode (currently raid5 only)
The cache mode for raid5. raid5 could include an extra disk for
- caching. The mode can be "write-throuth" and "write-back". The
+ caching. The mode can be "write-through" or "write-back". The
default is "write-through".
ppl_write_hint
diff --git a/Documentation/admin-guide/media/bttv.rst b/Documentation/admin-guide/media/bttv.rst
index 125f6f47123d..58cbaf6df694 100644
--- a/Documentation/admin-guide/media/bttv.rst
+++ b/Documentation/admin-guide/media/bttv.rst
@@ -909,7 +909,7 @@ DE hat diverse Treiber fuer diese Modelle (Stand 09/2002):
- TVPhone98 (Bt878)
- AVerTV und TVCapture98 w/VCR (Bt 878)
- AVerTVStudio und TVPhone98 w/VCR (Bt878)
- - AVerTV GO Serie (Kein SVideo Input)
+ - AVerTV GO Series (Kein SVideo Input)
- AVerTV98 (BT-878 chip)
- AVerTV98 mit Fernbedienung (BT-878 chip)
- AVerTV/FM98 (BT-878 chip)
diff --git a/Documentation/admin-guide/media/building.rst b/Documentation/admin-guide/media/building.rst
index 2d660b76caea..7a413ba07f93 100644
--- a/Documentation/admin-guide/media/building.rst
+++ b/Documentation/admin-guide/media/building.rst
@@ -15,7 +15,7 @@ Please notice, however, that, if:
you should use the main media development tree ``master`` branch:
- https://git.linuxtv.org/media_tree.git/
+ https://git.linuxtv.org/media.git/
In this case, you may find some useful information at the
`LinuxTv wiki pages <https://linuxtv.org/wiki>`_:
@@ -137,7 +137,7 @@ The ``LIRC user interface`` option adds enhanced functionality when using the
from remote controllers.
The ``Support for eBPF programs attached to lirc devices`` option allows
-the usage of special programs (called eBPF) that would allow aplications
+the usage of special programs (called eBPF) that would allow applications
to add extra remote controller decoding functionality to the Linux Kernel.
The ``Remote controller decoders`` option allows selecting the
diff --git a/Documentation/admin-guide/media/c3-isp.dot b/Documentation/admin-guide/media/c3-isp.dot
new file mode 100644
index 000000000000..42dc931ee84a
--- /dev/null
+++ b/Documentation/admin-guide/media/c3-isp.dot
@@ -0,0 +1,26 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{<port0> 0 | <port1> 1} | c3-isp-core\n/dev/v4l-subdev0 | {<port2> 2 | <port3> 3 | <port4> 4 | <port5> 5}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port3 -> n00000008:port0
+ n00000001:port4 -> n0000000b:port0
+ n00000001:port5 -> n0000000e:port0
+ n00000001:port2 -> n00000027
+ n00000008 [label="{{<port0> 0} | c3-isp-resizer0\n/dev/v4l-subdev1 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000008:port1 -> n00000016 [style=bold]
+ n0000000b [label="{{<port0> 0} | c3-isp-resizer1\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000000b:port1 -> n0000001a [style=bold]
+ n0000000e [label="{{<port0> 0} | c3-isp-resizer2\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000000e:port1 -> n00000023 [style=bold]
+ n00000011 [label="{{<port0> 0} | c3-mipi-adapter\n/dev/v4l-subdev4 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000011:port1 -> n00000001:port0 [style=bold]
+ n00000016 [label="c3-isp-cap0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n0000001a [label="c3-isp-cap1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n0000001e [label="{{<port0> 0} | c3-mipi-csi2\n/dev/v4l-subdev5 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000001e:port1 -> n00000011:port0 [style=bold]
+ n00000023 [label="c3-isp-cap2\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
+ n00000027 [label="c3-isp-stats\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
+ n0000002b [label="c3-isp-params\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
+ n0000002b -> n00000001:port1
+ n0000003f [label="{{} | imx290 2-001a\n/dev/v4l-subdev6 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000003f:port0 -> n0000001e:port0 [style=bold]
+}
diff --git a/Documentation/admin-guide/media/c3-isp.rst b/Documentation/admin-guide/media/c3-isp.rst
new file mode 100644
index 000000000000..ac508b8c6831
--- /dev/null
+++ b/Documentation/admin-guide/media/c3-isp.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: (GPL-2.0-only OR MIT)
+
+.. include:: <isonum.txt>
+
+=================================================
+Amlogic C3 Image Signal Processing (C3ISP) driver
+=================================================
+
+Introduction
+============
+
+This file documents the Amlogic C3ISP driver located under
+drivers/media/platform/amlogic/c3/isp.
+
+The current version of the driver supports the C3ISP found on
+Amlogic C308L processor.
+
+The driver implements V4L2, Media controller and V4L2 subdev interfaces.
+Camera sensor using V4L2 subdev interface in the kernel is supported.
+
+The driver has been tested on AW419-C308L-Socket platform.
+
+Amlogic C3 ISP
+==============
+
+The Camera hardware found on C308L processors and supported by
+the driver consists of:
+
+- 1 MIPI-CSI-2 module: handles the physical layer of the MIPI CSI-2 receiver and
+ receives data from the connected camera sensor.
+- 1 MIPI-ADAPTER module: organizes MIPI data to meet ISP input requirements and
+ send MIPI data to ISP.
+- 1 ISP (Image Signal Processing) module: contains a pipeline of image processing
+ hardware blocks. The ISP pipeline contains three resizers at the end each of
+ them connected to a DMA interface which writes the output data to memory.
+
+A high-level functional view of the C3 ISP is presented below.::
+
+ +----------+ +-------+
+ | Resizer |--->| WRMIF |
+ +---------+ +------------+ +--------------+ +-------+ |----------+ +-------+
+ | Sensor |--->| MIPI CSI-2 |--->| MIPI ADAPTER |--->| ISP |---|----------+ +-------+
+ +---------+ +------------+ +--------------+ +-------+ | Resizer |--->| WRMIF |
+ +----------+ +-------+
+ |----------+ +-------+
+ | Resizer |--->| WRMIF |
+ +----------+ +-------+
+
+Driver architecture and design
+==============================
+
+With the goal to model the hardware links between the modules and to expose a
+clean, logical and usable interface, the driver registers the following V4L2
+sub-devices:
+
+- 1 `c3-mipi-csi2` sub-device - the MIPI CSI-2 receiver
+- 1 `c3-mipi-adapter` sub-device - the MIPI adapter
+- 1 `c3-isp-core` sub-device - the ISP core
+- 3 `c3-isp-resizer` sub-devices - the ISP resizers
+
+The `c3-isp-core` sub-device is linked to 2 video device nodes for statistics
+capture and parameters programming:
+
+- the `c3-isp-stats` capture video device node for statistics capture
+- the `c3-isp-params` output video device for parameters programming
+
+Each `c3-isp-resizer` sub-device is linked to a capture video device node where
+frames are captured from:
+
+- `c3-isp-resizer0` is linked to the `c3-isp-cap0` capture video device
+- `c3-isp-resizer1` is linked to the `c3-isp-cap1` capture video device
+- `c3-isp-resizer2` is linked to the `c3-isp-cap2` capture video device
+
+The media controller pipeline graph is as follows (with connected a
+IMX290 camera sensor):
+
+.. _isp_topology_graph:
+
+.. kernel-figure:: c3-isp.dot
+ :alt: c3-isp.dot
+ :align: center
+
+ Media pipeline topology
+
+Implementation
+==============
+
+Runtime configuration of the ISP hardware is performed on the `c3-isp-params`
+video device node using the :ref:`V4L2_META_FMT_C3ISP_PARAMS
+<v4l2-meta-fmt-c3isp-params>` as data format. The buffer structure is defined by
+:c:type:`c3_isp_params_cfg`.
+
+Statistics are captured from the `c3-isp-stats` video device node using the
+:ref:`V4L2_META_FMT_C3ISP_STATS <v4l2-meta-fmt-c3isp-stats>` data format.
+
+The final picture size and format is configured using the V4L2 video
+capture interface on the `c3-isp-cap[0, 2]` video device nodes.
+
+The Amlogic C3 ISP is supported by `libcamera <https://libcamera.org>`_ with a
+dedicated pipeline handler and algorithms that perform run-time image correction
+and enhancement.
diff --git a/Documentation/admin-guide/media/cec-drivers.rst b/Documentation/admin-guide/media/cec-drivers.rst
deleted file mode 100644
index 8d9686c08df9..000000000000
--- a/Documentation/admin-guide/media/cec-drivers.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=================================
-CEC driver-specific documentation
-=================================
-
-.. toctree::
- :maxdepth: 2
-
- pulse8-cec
diff --git a/Documentation/admin-guide/media/cec.rst b/Documentation/admin-guide/media/cec.rst
new file mode 100644
index 000000000000..b2e7a300494a
--- /dev/null
+++ b/Documentation/admin-guide/media/cec.rst
@@ -0,0 +1,467 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========
+HDMI CEC
+========
+
+Supported hardware in mainline
+==============================
+
+HDMI Transmitters:
+
+- Exynos4
+- Exynos5
+- STIH4xx HDMI CEC
+- V4L2 adv7511 (same HW, but a different driver from the drm adv7511)
+- stm32
+- Allwinner A10 (sun4i)
+- Raspberry Pi
+- dw-hdmi (Synopsis IP)
+- amlogic (meson ao-cec and ao-cec-g12a)
+- drm adv7511/adv7533
+- omap4
+- tegra
+- rk3288, rk3399
+- tda998x
+- DisplayPort CEC-Tunneling-over-AUX on i915, nouveau and amdgpu
+- ChromeOS EC CEC
+- CEC for SECO boards (UDOO x86).
+- Chrontel CH7322
+
+
+HDMI Receivers:
+
+- adv7604/11/12
+- adv7842
+- tc358743
+
+USB Dongles (see below for additional information on how to use these
+dongles):
+
+- Pulse-Eight: the pulse8-cec driver implements the following module option:
+ ``persistent_config``: by default this is off, but when set to 1 the driver
+ will store the current settings to the device's internal eeprom and restore
+ it the next time the device is connected to the USB port.
+
+- RainShadow Tech. Note: this driver does not support the persistent_config
+ module option of the Pulse-Eight driver. The hardware supports it, but I
+ have no plans to add this feature. But I accept patches :-)
+
+- Extron DA HD 4K PLUS HDMI Distribution Amplifier. See
+ :ref:`extron_da_hd_4k_plus` for more information.
+
+Miscellaneous:
+
+- vivid: emulates a CEC receiver and CEC transmitter.
+ Can be used to test CEC applications without actual CEC hardware.
+
+- cec-gpio. If the CEC pin is hooked up to a GPIO pin then
+ you can control the CEC line through this driver. This supports error
+ injection as well.
+
+- cec-gpio and Allwinner A10 (or any other driver that uses the CEC pin
+ framework to drive the CEC pin directly): the CEC pin framework uses
+ high-resolution timers. These timers are affected by NTP daemons that
+ speed up or slow down the clock to sync with the official time. The
+ chronyd server will by default increase or decrease the clock by
+ 1/12th. This will cause the CEC timings to go out of spec. To fix this,
+ add a 'maxslewrate 40000' line to chronyd.conf. This limits the clock
+ frequency change to 1/25th, which keeps the CEC timings within spec.
+
+
+Utilities
+=========
+
+Utilities are available here: https://git.linuxtv.org/v4l-utils.git
+
+``utils/cec-ctl``: control a CEC device
+
+``utils/cec-compliance``: test compliance of a remote CEC device
+
+``utils/cec-follower``: emulate a CEC follower device
+
+Note that ``cec-ctl`` has support for the CEC Hospitality Profile as is
+used in some hotel displays. See http://www.htng.org.
+
+Note that the libcec library (https://github.com/Pulse-Eight/libcec) supports
+the linux CEC framework.
+
+If you want to get the CEC specification, then look at the References of
+the HDMI wikipedia page: https://en.wikipedia.org/wiki/HDMI. CEC is part
+of the HDMI specification. HDMI 1.3 is freely available (very similar to
+HDMI 1.4 w.r.t. CEC) and should be good enough for most things.
+
+
+DisplayPort to HDMI Adapters with working CEC
+=============================================
+
+Background: most adapters do not support the CEC Tunneling feature,
+and of those that do many did not actually connect the CEC pin.
+Unfortunately, this means that while a CEC device is created, it
+is actually all alone in the world and will never be able to see other
+CEC devices.
+
+This is a list of known working adapters that have CEC Tunneling AND
+that properly connected the CEC pin. If you find adapters that work
+but are not in this list, then drop me a note.
+
+To test: hook up your DP-to-HDMI adapter to a CEC capable device
+(typically a TV), then run::
+
+ cec-ctl --playback # Configure the PC as a CEC Playback device
+ cec-ctl -S # Show the CEC topology
+
+The ``cec-ctl -S`` command should show at least two CEC devices,
+ourselves and the CEC device you are connected to (i.e. typically the TV).
+
+General note: I have only seen this work with the Parade PS175, PS176 and
+PS186 chipsets and the MegaChips 2900. While MegaChips 28x0 claims CEC support,
+I have never seen it work.
+
+USB-C to HDMI
+-------------
+
+Samsung Multiport Adapter EE-PW700: https://www.samsung.com/ie/support/model/EE-PW700BBEGWW/
+
+Kramer ADC-U31C/HF: https://www.kramerav.com/product/ADC-U31C/HF
+
+Club3D CAC-2504: https://www.club-3d.com/en/detail/2449/usb_3.1_type_c_to_hdmi_2.0_uhd_4k_60hz_active_adapter/
+
+DisplayPort to HDMI
+-------------------
+
+Club3D CAC-1080: https://www.club-3d.com/en/detail/2442/displayport_1.4_to_hdmi_2.0b_hdr/
+
+CableCreation (SKU: CD0712): https://www.cablecreation.com/products/active-displayport-to-hdmi-adapter-4k-hdr
+
+HP DisplayPort to HDMI True 4k Adapter (P/N 2JA63AA): https://www.hp.com/us-en/shop/pdp/hp-displayport-to-hdmi-true-4k-adapter
+
+Mini-DisplayPort to HDMI
+------------------------
+
+Club3D CAC-1180: https://www.club-3d.com/en/detail/2443/mini_displayport_1.4_to_hdmi_2.0b_hdr/
+
+Note that passive adapters will never work, you need an active adapter.
+
+The Club3D adapters in this list are all MegaChips 2900 based. Other Club3D adapters
+are PS176 based and do NOT have the CEC pin hooked up, so only the three Club3D
+adapters above are known to work.
+
+I suspect that MegaChips 2900 based designs in general are likely to work
+whereas with the PS176 it is more hit-and-miss (mostly miss). The PS186 is
+likely to have the CEC pin hooked up, it looks like they changed the reference
+design for that chipset.
+
+
+USB CEC Dongles
+===============
+
+These dongles appear as ``/dev/ttyACMX`` devices and need the ``inputattach``
+utility to create the ``/dev/cecX`` devices. Support for the Pulse-Eight
+has been added to ``inputattach`` 1.6.0. Support for the Rainshadow Tech has
+been added to ``inputattach`` 1.6.1.
+
+You also need udev rules to automatically start systemd services::
+
+ SUBSYSTEM=="tty", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="2548", ATTRS{idProduct}=="1002", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}+="pulse8-cec-inputattach@%k.service"
+ SUBSYSTEM=="tty", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="2548", ATTRS{idProduct}=="1001", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}+="pulse8-cec-inputattach@%k.service"
+ SUBSYSTEM=="tty", KERNEL=="ttyACM[0-9]*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="ff59", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}+="rainshadow-cec-inputattach@%k.service"
+
+and these systemd services:
+
+For Pulse-Eight make /lib/systemd/system/pulse8-cec-inputattach@.service::
+
+ [Unit]
+ Description=inputattach for pulse8-cec device on %I
+
+ [Service]
+ Type=simple
+ ExecStart=/usr/bin/inputattach --pulse8-cec /dev/%I
+
+For the RainShadow Tech make /lib/systemd/system/rainshadow-cec-inputattach@.service::
+
+ [Unit]
+ Description=inputattach for rainshadow-cec device on %I
+
+ [Service]
+ Type=simple
+ ExecStart=/usr/bin/inputattach --rainshadow-cec /dev/%I
+
+
+For proper suspend/resume support create: /lib/systemd/system/restart-cec-inputattach.service::
+
+ [Unit]
+ Description=restart inputattach for cec devices
+ After=suspend.target
+
+ [Service]
+ Type=forking
+ ExecStart=/bin/bash -c 'for d in /dev/serial/by-id/usb-Pulse-Eight*; do /usr/bin/inputattach --daemon --pulse8-cec $d; done; for d in /dev/serial/by-id/usb-RainShadow_Tech*; do /usr/bin/inputattach --daemon --rainshadow-cec $d; done'
+
+ [Install]
+ WantedBy=suspend.target
+
+And run ``systemctl enable restart-cec-inputattach``.
+
+To automatically set the physical address of the CEC device whenever the
+EDID changes, you can use ``cec-ctl`` with the ``-E`` option::
+
+ cec-ctl -E /sys/class/drm/card0-DP-1/edid
+
+This assumes the dongle is connected to the card0-DP-1 output (``xrandr`` will tell
+you which output is used) and it will poll for changes to the EDID and update
+the Physical Address whenever they occur.
+
+To automatically run this command you can use cron. Edit crontab with
+``crontab -e`` and add this line::
+
+ @reboot /usr/local/bin/cec-ctl -E /sys/class/drm/card0-DP-1/edid
+
+This only works for display drivers that expose the EDID in ``/sys/class/drm``,
+such as the i915 driver.
+
+
+CEC Without HPD
+===============
+
+Some displays when in standby mode have no HDMI Hotplug Detect signal, but
+CEC is still enabled so connected devices can send an <Image View On> CEC
+message in order to wake up such displays. Unfortunately, not all CEC
+adapters can support this. An example is the Odroid-U3 SBC that has a
+level-shifter that is powered off when the HPD signal is low, thus
+blocking the CEC pin. Even though the SoC can use CEC without a HPD,
+the level-shifter will prevent this from functioning.
+
+There is a CEC capability flag to signal this: ``CEC_CAP_NEEDS_HPD``.
+If set, then the hardware cannot wake up displays with this behavior.
+
+Note for CEC application implementers: the <Image View On> message must
+be the first message you send, don't send any other messages before.
+Certain very bad but unfortunately not uncommon CEC implementations
+get very confused if they receive anything else but this message and
+they won't wake up.
+
+When writing a driver it can be tricky to test this. There are two
+ways to do this:
+
+1) Get a Pulse-Eight USB CEC dongle, connect an HDMI cable from your
+ device to the Pulse-Eight, but do not connect the Pulse-Eight to
+ the display.
+
+ Now configure the Pulse-Eight dongle::
+
+ cec-ctl -p0.0.0.0 --tv
+
+ and start monitoring::
+
+ sudo cec-ctl -M
+
+ On the device you are testing run::
+
+ cec-ctl --playback
+
+ It should report a physical address of f.f.f.f. Now run this
+ command::
+
+ cec-ctl -t0 --image-view-on
+
+ The Pulse-Eight should see the <Image View On> message. If not,
+ then something (hardware and/or software) is preventing the CEC
+ message from going out.
+
+ To make sure you have the wiring correct just connect the
+ Pulse-Eight to a CEC-enabled display and run the same command
+ on your device: now there is a HPD, so you should see the command
+ arriving at the Pulse-Eight.
+
+2) If you have another linux device supporting CEC without HPD, then
+ you can just connect your device to that device. Yes, you can connect
+ two HDMI outputs together. You won't have a HPD (which is what we
+ want for this test), but the second device can monitor the CEC pin.
+
+ Otherwise use the same commands as in 1.
+
+If CEC messages do not come through when there is no HPD, then you
+need to figure out why. Typically it is either a hardware restriction
+or the software powers off the CEC core when the HPD goes low. The
+first cannot be corrected of course, the second will likely required
+driver changes.
+
+
+Microcontrollers & CEC
+======================
+
+We have seen some CEC implementations in displays that use a microcontroller
+to sample the bus. This does not have to be a problem, but some implementations
+have timing issues. This is hard to discover unless you can hook up a low-level
+CEC debugger (see the next section).
+
+You will see cases where the CEC transmitter holds the CEC line high or low for
+a longer time than is allowed. For directed messages this is not a problem since
+if that happens the message will not be Acked and it will be retransmitted.
+For broadcast messages no such mechanism exists.
+
+It's not clear what to do about this. It is probably wise to transmit some
+broadcast messages twice to reduce the chance of them being lost. Specifically
+<Standby> and <Active Source> are candidates for that.
+
+
+Making a CEC debugger
+=====================
+
+By using a Raspberry Pi 4B and some cheap components you can make
+your own low-level CEC debugger.
+
+The critical component is one of these HDMI female-female passthrough connectors
+(full soldering type 1):
+
+https://elabbay.myshopify.com/collections/camera/products/hdmi-af-af-v1a-hdmi-type-a-female-to-hdmi-type-a-female-pass-through-adapter-breakout-board?variant=45533926147
+
+The video quality is variable and certainly not enough to pass-through 4kp60
+(594 MHz) video. You might be able to support 4kp30, but more likely you will
+be limited to 1080p60 (148.5 MHz). But for CEC testing that is fine.
+
+You need a breadboard and some breadboard wires:
+
+http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I
+
+If you want to monitor the HPD and/or 5V lines as well, then you need one of
+these 5V to 3.3V level shifters:
+
+https://www.adafruit.com/product/757
+
+(This is just where I got these components, there are many other places you
+can get similar things).
+
+The ground pin of the HDMI connector needs to be connected to a ground
+pin of the Raspberry Pi, of course.
+
+The CEC pin of the HDMI connector needs to be connected to these pins:
+GPIO 6 and GPIO 7. The optional HPD pin of the HDMI connector should
+be connected via the level shifter to these pins: GPIO 23 and GPIO 12.
+The optional 5V pin of the HDMI connector should be connected via the
+level shifter to these pins: GPIO 25 and GPIO 22. Monitoring the HPD and
+5V lines is not necessary, but it is helpful.
+
+This device tree addition in ``arch/arm/boot/dts/bcm2711-rpi-4-b.dts``
+will hook up the cec-gpio driver correctly::
+
+ cec@6 {
+ compatible = "cec-gpio";
+ cec-gpios = <&gpio 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ hpd-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>;
+ v5-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>;
+ };
+
+ cec@7 {
+ compatible = "cec-gpio";
+ cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ hpd-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;
+ v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ };
+
+If you haven't hooked up the HPD and/or 5V lines, then just delete those
+lines.
+
+This dts change will enable two cec GPIO devices: I typically use one to
+send/receive CEC commands and the other to monitor. If you monitor using
+an unconfigured CEC adapter then it will use GPIO interrupts which makes
+monitoring very accurate.
+
+If you just want to monitor traffic, then a single instance is sufficient.
+The minimum configuration is one HDMI female-female passthrough connector
+and two female-female breadboard wires: one for connecting the HDMI ground
+pin to a ground pin on the Raspberry Pi, and the other to connect the HDMI
+CEC pin to GPIO 6 on the Raspberry Pi.
+
+The documentation on how to use the error injection is here: :ref:`cec_pin_error_inj`.
+
+``cec-ctl --monitor-pin`` will do low-level CEC bus sniffing and analysis.
+You can also store the CEC traffic to file using ``--store-pin`` and analyze
+it later using ``--analyze-pin``.
+
+You can also use this as a full-fledged CEC device by configuring it
+using ``cec-ctl --tv -p0.0.0.0`` or ``cec-ctl --playback -p1.0.0.0``.
+
+.. _extron_da_hd_4k_plus:
+
+Extron DA HD 4K PLUS CEC Adapter driver
+=======================================
+
+This driver is for the Extron DA HD 4K PLUS series of HDMI Distribution
+Amplifiers: https://www.extron.com/product/dahd4kplusseries
+
+The 2, 4 and 6 port models are supported.
+
+Firmware version 1.02.0001 or higher is required.
+
+Note that older Extron hardware revisions have a problem with the CEC voltage,
+which may mean that CEC will not work. This is fixed in hardware revisions
+E34814 and up.
+
+The CEC support has two modes: the first is a manual mode where userspace has
+to manually control CEC for the HDMI Input and all HDMI Outputs. While this gives
+full control, it is also complicated.
+
+The second mode is an automatic mode, which is selected if the module option
+``vendor_id`` is set. In that case the driver controls CEC and CEC messages
+received in the input will be distributed to the outputs. It is still possible
+to use the /dev/cecX devices to talk to the connected devices directly, but it is
+the driver that configures everything and deals with things like Hotplug Detect
+changes.
+
+The driver also takes care of the EDIDs: /dev/videoX devices are created to
+read the EDIDs and (for the HDMI Input port) to set the EDID.
+
+By default userspace is responsible to set the EDID for the HDMI Input
+according to the EDIDs of the connected displays. But if the ``manufacturer_name``
+module option is set, then the driver will take care of setting the EDID
+of the HDMI Input based on the supported resolutions of the connected displays.
+Currently the driver only supports resolutions 1080p60 and 4kp60: if all connected
+displays support 4kp60, then it will advertise 4kp60 on the HDMI input, otherwise
+it will fall back to an EDID that just reports 1080p60.
+
+The status of the Extron is reported in ``/sys/kernel/debug/cec/cecX/status``.
+
+The extron-da-hd-4k-plus driver implements the following module options:
+
+``debug``
+---------
+
+If set to 1, then all serial port traffic is shown.
+
+``vendor_id``
+-------------
+
+The CEC Vendor ID to report to connected displays.
+
+If set, then the driver will take care of distributing CEC messages received
+on the input to the HDMI outputs. This is done for the following CEC messages:
+
+- <Standby>
+- <Image View On> and <Text View On>
+- <Give Device Power Status>
+- <Set System Audio Mode>
+- <Request Current Latency>
+
+If not set, then userspace is responsible for this, and it will have to
+configure the CEC devices for HDMI Input and the HDMI Outputs manually.
+
+``manufacturer_name``
+---------------------
+
+A three character manufacturer name that is used in the EDID for the HDMI
+Input. If not set, then userspace is responsible for configuring an EDID.
+If set, then the driver will update the EDID automatically based on the
+resolutions supported by the connected displays, and it will not be possible
+anymore to manually set the EDID for the HDMI Input.
+
+``hpd_never_low``
+-----------------
+
+If set, then the Hotplug Detect pin of the HDMI Input will always be high,
+even if nothing is connected to the HDMI Outputs. If not set (the default)
+then the Hotplug Detect pin of the HDMI input will go low if all the detected
+Hotplug Detect pins of the HDMI Outputs are also low.
+
+This option may be changed dynamically.
diff --git a/Documentation/admin-guide/media/cpia2.rst b/Documentation/admin-guide/media/cpia2.rst
deleted file mode 100644
index f6ffef686462..000000000000
--- a/Documentation/admin-guide/media/cpia2.rst
+++ /dev/null
@@ -1,145 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The cpia2 driver
-================
-
-Authors: Peter Pregler <Peter_Pregler@email.com>,
-Scott J. Bertin <scottbertin@yahoo.com>, and
-Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
-this one was modelled from.
-
-Introduction
-------------
-
-This is a driver for STMicroelectronics's CPiA2 (second generation
-Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
-stream at up to vga size. It implements the Video4Linux interface as much as
-possible. Since the V4L interface does not support compressed formats, only
-an mjpeg enabled application can be used with the camera. We have modified the
-gqcam application to view this stream.
-
-The driver is implemented as two kernel modules. The cpia2 module
-contains the camera functions and the V4L interface. The cpia2_usb module
-contains usb specific functions. The main reason for this was the size of the
-module was getting out of hand, so I separated them. It is not likely that
-there will be a parallel port version.
-
-Features
---------
-
-- Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
- sensors. I only have the vga sensor, so can't test the other.
-- Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
- VGA and QVGA are the native image sizes for the VGA camera. CIF is done
- in the coprocessor by scaling QVGA. All other sizes are done by clipping.
-- Palette: YCrCb, compressed with MJPEG.
-- Some compression parameters are settable.
-- Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
-- Adjust brightness, color, contrast while streaming.
-- Flicker control settable for 50 or 60 Hz mains frequency.
-
-Making and installing the stv672 driver modules
------------------------------------------------
-
-Requirements
-~~~~~~~~~~~~
-
-Video4Linux must be either compiled into the kernel or
-available as a module. Video4Linux2 is automatically detected and made
-available at compile time.
-
-Setup
-~~~~~
-
-Use ``modprobe cpia2`` to load and ``modprobe -r cpia2`` to unload. This
-may be done automatically by your distribution.
-
-Driver options
-~~~~~~~~~~~~~~
-
-.. tabularcolumns:: |p{13ex}|L|
-
-
-============== ========================================================
-Option Description
-============== ========================================================
-video_nr video device to register (0=/dev/video0, etc)
- range -1 to 64. default is -1 (first available)
- If you have more than 1 camera, this MUST be -1.
-buffer_size Size for each frame buffer in bytes (default 68k)
-num_buffers Number of frame buffers (1-32, default 3)
-alternate USB Alternate (2-7, default 7)
-flicker_freq Frequency for flicker reduction(50 or 60, default 60)
-flicker_mode 0 to disable, or 1 to enable flicker reduction.
- (default 0). This is only effective if the camera
- uses a stv0672 coprocessor.
-============== ========================================================
-
-Setting the options
-~~~~~~~~~~~~~~~~~~~
-
-If you are using modules, edit /etc/modules.conf and add an options
-line like this::
-
- options cpia2 num_buffers=3 buffer_size=65535
-
-If the driver is compiled into the kernel, at boot time specify them
-like this::
-
- cpia2.num_buffers=3 cpia2.buffer_size=65535
-
-What buffer size should I use?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The maximum image size depends on the alternate you choose, and the
-frame rate achieved by the camera. If the compression engine is able to
-keep up with the frame rate, the maximum image size is given by the table
-below.
-
-The compression engine starts out at maximum compression, and will
-increase image quality until it is close to the size in the table. As long
-as the compression engine can keep up with the frame rate, after a short time
-the images will all be about the size in the table, regardless of resolution.
-
-At low alternate settings, the compression engine may not be able to
-compress the image enough and will reduce the frame rate by producing larger
-images.
-
-The default of 68k should be good for most users. This will handle
-any alternate at frame rates down to 15fps. For lower frame rates, it may
-be necessary to increase the buffer size to avoid having frames dropped due
-to insufficient space.
-
-========== ========== ======== =====
-Alternate bytes/ms 15fps 30fps
-========== ========== ======== =====
- 2 128 8533 4267
- 3 384 25600 12800
- 4 640 42667 21333
- 5 768 51200 25600
- 6 896 59733 29867
- 7 1023 68200 34100
-========== ========== ======== =====
-
-Table: Image size(bytes)
-
-
-How many buffers should I use?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For normal streaming, 3 should give the best results. With only 2,
-it is possible for the camera to finish sending one image just after a
-program has started reading the other. If this happens, the driver must drop
-a frame. The exception to this is if you have a heavily loaded machine. In
-this case use 2 buffers. You are probably not reading at the full frame rate.
-If the camera can send multiple images before a read finishes, it could
-overwrite the third buffer before the read finishes, leading to a corrupt
-image. Single and double buffering have extra checks to avoid overwriting.
-
-Using the camera
-~~~~~~~~~~~~~~~~
-
-We are providing a modified gqcam application to view the output. In
-order to avoid confusion, here it is called mview. There is also the qx5view
-program which can also control the lights on the qx5 microscope. MJPEG Tools
-(http://mjpeg.sourceforge.net) can also be used to record from the camera.
diff --git a/Documentation/admin-guide/media/davinci-vpbe.rst b/Documentation/admin-guide/media/davinci-vpbe.rst
deleted file mode 100644
index 9e6360fd02db..000000000000
--- a/Documentation/admin-guide/media/davinci-vpbe.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The VPBE V4L2 driver design
-===========================
-
-Functional partitioning
------------------------
-
-Consists of the following:
-
- 1. V4L2 display driver
-
- Implements creation of video2 and video3 device nodes and
- provides v4l2 device interface to manage VID0 and VID1 layers.
-
- 2. Display controller
-
- Loads up VENC, OSD and external encoders such as ths8200. It provides
- a set of API calls to V4L2 drivers to set the output/standards
- in the VENC or external sub devices. It also provides
- a device object to access the services from OSD subdevice
- using sub device ops. The connection of external encoders to VENC LCD
- controller port is done at init time based on default output and standard
- selection or at run time when application change the output through
- V4L2 IOCTLs.
-
- When connected to an external encoder, vpbe controller is also responsible
- for setting up the interface between VENC and external encoders based on
- board specific settings (specified in board-xxx-evm.c). This allows
- interfacing external encoders such as ths8200. The setup_if_config()
- is implemented for this as well as configure_venc() (part of the next patch)
- API to set timings in VENC for a specific display resolution. As of this
- patch series, the interconnection and enabling and setting of the external
- encoders is not present, and would be a part of the next patch series.
-
- 3. VENC subdevice module
-
- Responsible for setting outputs provided through internal DACs and also
- setting timings at LCD controller port when external encoders are connected
- at the port or LCD panel timings required. When external encoder/LCD panel
- is connected, the timings for a specific standard/preset is retrieved from
- the board specific table and the values are used to set the timings in
- venc using non-standard timing mode.
-
- Support LCD Panel displays using the VENC. For example to support a Logic
- PD display, it requires setting up the LCD controller port with a set of
- timings for the resolution supported and setting the dot clock. So we could
- add the available outputs as a board specific entry (i.e add the "LogicPD"
- output name to board-xxx-evm.c). A table of timings for various LCDs
- supported can be maintained in the board specific setup file to support
- various LCD displays.As of this patch a basic driver is present, and this
- support for external encoders and displays forms a part of the next
- patch series.
-
- 4. OSD module
-
- OSD module implements all OSD layer management and hardware specific
- features. The VPBE module interacts with the OSD for enabling and
- disabling appropriate features of the OSD.
-
-Current status
---------------
-
-A fully functional working version of the V4L2 driver is available. This
-driver has been tested with NTSC and PAL standards and buffer streaming.
diff --git a/Documentation/admin-guide/media/dvb-drivers.rst b/Documentation/admin-guide/media/dvb-drivers.rst
index 8df637c375f9..66fa4edd0606 100644
--- a/Documentation/admin-guide/media/dvb-drivers.rst
+++ b/Documentation/admin-guide/media/dvb-drivers.rst
@@ -13,4 +13,3 @@ Digital TV driver-specific documentation
opera-firmware
technisat
ttusb-dec
- zr364xx
diff --git a/Documentation/admin-guide/media/em28xx-cardlist.rst b/Documentation/admin-guide/media/em28xx-cardlist.rst
index ace65718ea22..7dac07986d91 100644
--- a/Documentation/admin-guide/media/em28xx-cardlist.rst
+++ b/Documentation/admin-guide/media/em28xx-cardlist.rst
@@ -438,3 +438,11 @@ EM28xx cards list
- MyGica iGrabber
- em2860
- 1f4d:1abe
+ * - 106
+ - Hauppauge USB QuadHD ATSC
+ - em28274
+ - 2040:846d
+ * - 107
+ - MyGica UTV3 Analog USB2.0 TV Box
+ - em2860
+ - eb1a:2860
diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst
index ef3b5fff3b01..fff962558cd5 100644
--- a/Documentation/admin-guide/media/i2c-cardlist.rst
+++ b/Documentation/admin-guide/media/i2c-cardlist.rst
@@ -72,17 +72,13 @@ imx319 Sony IMX319 sensor
imx334 Sony IMX334 sensor
imx355 Sony IMX355 sensor
imx412 Sony IMX412 sensor
-m5mols Fujitsu M-5MOLS 8MP sensor
mt9m001 mt9m001
-mt9m032 MT9M032 camera sensor
mt9m111 mt9m111, mt9m112 and mt9m131
mt9p031 Aptina MT9P031
-mt9t001 Aptina MT9T001
mt9t112 Aptina MT9T111/MT9T112
mt9v011 Micron mt9v011 sensor
mt9v032 Micron MT9V032 sensor
mt9v111 Aptina MT9V111 sensor
-noon010pc30 Siliconfile NOON010PC30 sensor
ov13858 OmniVision OV13858 sensor
ov13b10 OmniVision OV13B10 sensor
ov2640 OmniVision OV2640 sensor
@@ -95,7 +91,6 @@ ov5647 OmniVision OV5647 sensor
ov5670 OmniVision OV5670 sensor
ov5675 OmniVision OV5675 sensor
ov5695 OmniVision OV5695 sensor
-ov6650 OmniVision OV6650 sensor
ov7251 OmniVision OV7251 sensor
ov7640 OmniVision OV7640 sensor
ov7670 OmniVision OV7670 sensor
@@ -109,9 +104,6 @@ s5c73m3 Samsung S5C73M3 sensor
s5k4ecgx Samsung S5K4ECGX sensor
s5k5baf Samsung S5K5BAF sensor
s5k6a3 Samsung S5K6A3 sensor
-s5k6aa Samsung S5K6AAFX sensor
-sr030pc30 Siliconfile SR030PC30 sensor
-vs6624 ST VS6624 sensor
============ ==========================================================
Flash devices
@@ -222,7 +214,6 @@ Video encoders
============ ==========================================================
Driver Name
============ ==========================================================
-ad9389b Analog Devices AD9389B encoder
adv7170 Analog Devices ADV7170 video encoder
adv7175 Analog Devices ADV7175 video encoder
adv7343 ADV7343 video encoder
diff --git a/Documentation/admin-guide/media/imx.rst b/Documentation/admin-guide/media/imx.rst
index b8fa70f854fd..bb68100d8acb 100644
--- a/Documentation/admin-guide/media/imx.rst
+++ b/Documentation/admin-guide/media/imx.rst
@@ -96,7 +96,7 @@ Some of the features of this driver include:
motion compensation modes: low, medium, and high motion. Pipelines are
defined that allow sending frames to the VDIC subdev directly from the
CSI. There is also support in the future for sending frames to the
- VDIC from memory buffers via a output/mem2mem devices.
+ VDIC from memory buffers via output/mem2mem devices.
- Includes a Frame Interval Monitor (FIM) that can correct vertical sync
problems with the ADV718x video decoders.
diff --git a/Documentation/admin-guide/media/index.rst b/Documentation/admin-guide/media/index.rst
index c676af665111..b11737ae6c04 100644
--- a/Documentation/admin-guide/media/index.rst
+++ b/Documentation/admin-guide/media/index.rst
@@ -20,16 +20,13 @@ Documentation/driver-api/media/index.rst
- for driver development information and Kernel APIs used by
media devices;
-The media subsystem
-===================
+Documentation/process/debugging/media_specific_debugging_guide.rst
-.. only:: html
-
- .. class:: toc-title
-
- Table of Contents
+ - for advice about essential tools and techniques to debug drivers on this
+ subsystem
.. toctree::
+ :caption: Table of Contents
:maxdepth: 2
:numbered:
@@ -38,13 +35,14 @@ The media subsystem
remote-controller
+ cec
+
dvb
cardlist
v4l-drivers
dvb-drivers
- cec-drivers
**Copyright** |copy| 1999-2020 : LinuxTV Developers
diff --git a/Documentation/admin-guide/media/ipu3.rst b/Documentation/admin-guide/media/ipu3.rst
index 83b3cd03b35c..9c190942932e 100644
--- a/Documentation/admin-guide/media/ipu3.rst
+++ b/Documentation/admin-guide/media/ipu3.rst
@@ -98,7 +98,7 @@ frames in packed raw Bayer format to IPU3 CSI2 receiver.
# and that ov5670 sensor is connected to i2c bus 10 with address 0x36
export SDEV=$(media-ctl -d $MDEV -e "ov5670 10-0036")
- # Establish the link for the media devices using media-ctl [#f3]_
+ # Establish the link for the media devices using media-ctl
media-ctl -d $MDEV -l "ov5670:0 -> ipu3-csi2 0:0[1]"
# Set the format for the media devices
@@ -589,12 +589,8 @@ preserved.
References
==========
-.. [#f5] drivers/staging/media/ipu3/include/uapi/intel-ipu3.h
-
.. [#f1] https://github.com/intel/nvt
.. [#f2] http://git.ideasonboard.org/yavta.git
-.. [#f3] http://git.ideasonboard.org/?p=media-ctl.git;a=summary
-
.. [#f4] ImgU limitation requires an additional 16x16 for all input resolutions
diff --git a/Documentation/admin-guide/media/ipu6-isys.rst b/Documentation/admin-guide/media/ipu6-isys.rst
new file mode 100644
index 000000000000..d05086824a74
--- /dev/null
+++ b/Documentation/admin-guide/media/ipu6-isys.rst
@@ -0,0 +1,161 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+========================================================
+Intel Image Processing Unit 6 (IPU6) Input System driver
+========================================================
+
+Copyright |copy| 2023--2024 Intel Corporation
+
+Introduction
+============
+
+This file documents the Intel IPU6 (6th generation Image Processing Unit)
+Input System (MIPI CSI2 receiver) drivers located under
+drivers/media/pci/intel/ipu6.
+
+The Intel IPU6 can be found in certain Intel SoCs but not in all SKUs:
+
+* Tiger Lake
+* Jasper Lake
+* Alder Lake
+* Raptor Lake
+* Meteor Lake
+
+Intel IPU6 is made up of two components - Input System (ISYS) and Processing
+System (PSYS).
+
+The Input System mainly works as MIPI CSI-2 receiver which receives and
+processes the image data from the sensors and outputs the frames to memory.
+
+There are 2 driver modules - intel-ipu6 and intel-ipu6-isys. intel-ipu6 is an
+IPU6 common driver which does PCI configuration, firmware loading and parsing,
+firmware authentication, DMA mapping and IPU-MMU (internal Memory mapping Unit)
+configuration. intel_ipu6_isys implements V4L2, Media Controller and V4L2
+sub-device interfaces. The IPU6 ISYS driver supports camera sensors connected
+to the IPU6 ISYS through V4L2 sub-device sensor drivers.
+
+.. Note:: See Documentation/driver-api/media/drivers/ipu6.rst for more
+ information about the IPU6 hardware.
+
+Input system driver
+===================
+
+The Input System driver mainly configures CSI-2 D-PHY, constructs the firmware
+stream configuration, sends commands to firmware, gets response from hardware
+and firmware and then returns buffers to user. The ISYS is represented as
+several V4L2 sub-devices as well as video nodes.
+
+.. kernel-figure:: ipu6_isys_graph.svg
+ :alt: ipu6 isys media graph with multiple streams support
+
+ IPU6 ISYS media graph with multiple streams support
+
+The graph has been produced using the following command:
+
+.. code-block:: none
+
+ fdp -Gsplines=true -Tsvg < dot > dot.svg
+
+Capturing frames with IPU6 ISYS
+-------------------------------
+
+IPU6 ISYS is used to capture frames from the camera sensors connected to the
+CSI2 ports. The supported input formats of ISYS are listed in table below:
+
+.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|
+
+.. flat-table::
+ :header-rows: 1
+
+ * - IPU6 ISYS supported input formats
+
+ * - RGB565, RGB888
+
+ * - UYVY8, YUYV8
+
+ * - RAW8, RAW10, RAW12
+
+.. _ipu6_isys_capture_examples:
+
+Examples
+~~~~~~~~
+
+Here is an example of IPU6 ISYS raw capture on Dell XPS 9315 laptop. On this
+machine, ov01a10 sensor is connected to IPU ISYS CSI-2 port 2, which can
+generate images at sBGGR10 with resolution 1280x800.
+
+Using the media controller APIs, we can configure ov01a10 sensor by
+media-ctl [#f1]_ and yavta [#f2]_ to transmit frames to IPU6 ISYS.
+
+.. code-block:: none
+
+ # Example 1 capture frame from ov01a10 camera sensor
+ # This example assumes /dev/media0 as the IPU ISYS media device
+ export MDEV=/dev/media0
+
+ # Establish the link for the media devices using media-ctl
+ media-ctl -d $MDEV -l "\"ov01a10 3-0036\":0 -> \"Intel IPU6 CSI2 2\":0[1]"
+
+ # Set the format for the media devices
+ media-ctl -d $MDEV -V "ov01a10:0 [fmt:SBGGR10/1280x800]"
+ media-ctl -d $MDEV -V "Intel IPU6 CSI2 2:0 [fmt:SBGGR10/1280x800]"
+ media-ctl -d $MDEV -V "Intel IPU6 CSI2 2:1 [fmt:SBGGR10/1280x800]"
+
+Once the media pipeline is configured, desired sensor specific settings
+(such as exposure and gain settings) can be set, using the yavta tool.
+
+e.g
+
+.. code-block:: none
+
+ # and that ov01a10 sensor is connected to i2c bus 3 with address 0x36
+ export SDEV=$(media-ctl -d $MDEV -e "ov01a10 3-0036")
+
+ yavta -w 0x009e0903 400 $SDEV
+ yavta -w 0x009e0913 1000 $SDEV
+ yavta -w 0x009e0911 2000 $SDEV
+
+Once the desired sensor settings are set, frame captures can be done as below.
+
+e.g
+
+.. code-block:: none
+
+ yavta --data-prefix -u -c10 -n5 -I -s 1280x800 --file=/tmp/frame-#.bin \
+ -f SBGGR10 $(media-ctl -d $MDEV -e "Intel IPU6 ISYS Capture 0")
+
+With the above command, 10 frames are captured at 1280x800 resolution with
+sBGGR10 format. The captured frames are available as /tmp/frame-#.bin files.
+
+Here is another example of IPU6 ISYS RAW and metadata capture from camera
+sensor ov2740 on Lenovo X1 Yoga laptop.
+
+.. code-block:: none
+
+ media-ctl -l "\"ov2740 14-0036\":0 -> \"Intel IPU6 CSI2 1\":0[1]"
+ media-ctl -l "\"Intel IPU6 CSI2 1\":1 -> \"Intel IPU6 ISYS Capture 0\":0[1]"
+ media-ctl -l "\"Intel IPU6 CSI2 1\":2 -> \"Intel IPU6 ISYS Capture 1\":0[1]"
+
+ # set routing
+ media-ctl -R "\"Intel IPU6 CSI2 1\" [0/0->1/0[1],0/1->2/1[1]]"
+
+ media-ctl -V "\"Intel IPU6 CSI2 1\":0/0 [fmt:SGRBG10/1932x1092]"
+ media-ctl -V "\"Intel IPU6 CSI2 1\":0/1 [fmt:GENERIC_8/97x1]"
+ media-ctl -V "\"Intel IPU6 CSI2 1\":1/0 [fmt:SGRBG10/1932x1092]"
+ media-ctl -V "\"Intel IPU6 CSI2 1\":2/1 [fmt:GENERIC_8/97x1]"
+
+ CAPTURE_DEV=$(media-ctl -e "Intel IPU6 ISYS Capture 0")
+ ./yavta --data-prefix -c100 -n5 -I -s1932x1092 --file=/tmp/frame-#.bin \
+ -f SGRBG10 ${CAPTURE_DEV}
+
+ CAPTURE_META=$(media-ctl -e "Intel IPU6 ISYS Capture 1")
+ ./yavta --data-prefix -c100 -n5 -I -s97x1 -B meta-capture \
+ --file=/tmp/meta-#.bin -f GENERIC_8 ${CAPTURE_META}
+
+References
+==========
+
+.. [#f1] https://git.ideasonboard.org/media-ctl.git
+.. [#f2] https://git.ideasonboard.org/yavta.git
diff --git a/Documentation/admin-guide/media/ipu6_isys_graph.svg b/Documentation/admin-guide/media/ipu6_isys_graph.svg
new file mode 100644
index 000000000000..c8539ef320d2
--- /dev/null
+++ b/Documentation/admin-guide/media/ipu6_isys_graph.svg
@@ -0,0 +1,548 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.43.0 (0)
+ -->
+<!-- Title: board Pages: 1 -->
+<svg width="1703pt" height="1473pt"
+ viewBox="0.00 0.00 1703.00 1473.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 1469)">
+<title>board</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-1469 1699,-1469 1699,4 -4,4"/>
+<!-- n00000001 -->
+<g id="node1" class="node">
+<title>n00000001</title>
+<polygon fill="yellow" stroke="black" points="832.99,-750.08 629.99,-750.08 629.99,-712.08 832.99,-712.08 832.99,-750.08"/>
+<text text-anchor="middle" x="731.49" y="-734.88" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 0</text>
+<text text-anchor="middle" x="731.49" y="-719.88" font-family="Times,serif" font-size="14.00">/dev/video0</text>
+</g>
+<!-- n00000005 -->
+<g id="node2" class="node">
+<title>n00000005</title>
+<polygon fill="yellow" stroke="black" points="1396.59,-771.88 1193.59,-771.88 1193.59,-733.88 1396.59,-733.88 1396.59,-771.88"/>
+<text text-anchor="middle" x="1295.09" y="-756.68" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 1</text>
+<text text-anchor="middle" x="1295.09" y="-741.68" font-family="Times,serif" font-size="14.00">/dev/video1</text>
+</g>
+<!-- n00000009 -->
+<g id="node3" class="node">
+<title>n00000009</title>
+<polygon fill="yellow" stroke="black" points="1118.52,-690.47 915.52,-690.47 915.52,-652.47 1118.52,-652.47 1118.52,-690.47"/>
+<text text-anchor="middle" x="1017.02" y="-675.27" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 2</text>
+<text text-anchor="middle" x="1017.02" y="-660.27" font-family="Times,serif" font-size="14.00">/dev/video2</text>
+</g>
+<!-- n0000000d -->
+<g id="node4" class="node">
+<title>n0000000d</title>
+<polygon fill="yellow" stroke="black" points="1105.89,-838.84 902.89,-838.84 902.89,-800.84 1105.89,-800.84 1105.89,-838.84"/>
+<text text-anchor="middle" x="1004.39" y="-823.64" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 3</text>
+<text text-anchor="middle" x="1004.39" y="-808.64" font-family="Times,serif" font-size="14.00">/dev/video3</text>
+</g>
+<!-- n00000011 -->
+<g id="node5" class="node">
+<title>n00000011</title>
+<polygon fill="yellow" stroke="black" points="1279.22,-992.95 1076.22,-992.95 1076.22,-954.95 1279.22,-954.95 1279.22,-992.95"/>
+<text text-anchor="middle" x="1177.72" y="-977.75" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 4</text>
+<text text-anchor="middle" x="1177.72" y="-962.75" font-family="Times,serif" font-size="14.00">/dev/video4</text>
+</g>
+<!-- n00000015 -->
+<g id="node6" class="node">
+<title>n00000015</title>
+<polygon fill="yellow" stroke="black" points="939.18,-984.91 736.18,-984.91 736.18,-946.91 939.18,-946.91 939.18,-984.91"/>
+<text text-anchor="middle" x="837.68" y="-969.71" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 5</text>
+<text text-anchor="middle" x="837.68" y="-954.71" font-family="Times,serif" font-size="14.00">/dev/video5</text>
+</g>
+<!-- n00000019 -->
+<g id="node7" class="node">
+<title>n00000019</title>
+<polygon fill="yellow" stroke="black" points="957.87,-527.99 754.87,-527.99 754.87,-489.99 957.87,-489.99 957.87,-527.99"/>
+<text text-anchor="middle" x="856.37" y="-512.79" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 6</text>
+<text text-anchor="middle" x="856.37" y="-497.79" font-family="Times,serif" font-size="14.00">/dev/video6</text>
+</g>
+<!-- n0000001d -->
+<g id="node8" class="node">
+<title>n0000001d</title>
+<polygon fill="yellow" stroke="black" points="1291.02,-542.15 1088.02,-542.15 1088.02,-504.15 1291.02,-504.15 1291.02,-542.15"/>
+<text text-anchor="middle" x="1189.52" y="-526.95" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 7</text>
+<text text-anchor="middle" x="1189.52" y="-511.95" font-family="Times,serif" font-size="14.00">/dev/video7</text>
+</g>
+<!-- n00000021 -->
+<g id="node9" class="node">
+<title>n00000021</title>
+<polygon fill="yellow" stroke="black" points="202.74,-611.46 -0.26,-611.46 -0.26,-573.46 202.74,-573.46 202.74,-611.46"/>
+<text text-anchor="middle" x="101.24" y="-596.26" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 8</text>
+<text text-anchor="middle" x="101.24" y="-581.26" font-family="Times,serif" font-size="14.00">/dev/video8</text>
+</g>
+<!-- n00000025 -->
+<g id="node10" class="node">
+<title>n00000025</title>
+<polygon fill="yellow" stroke="black" points="764.86,-637.89 561.86,-637.89 561.86,-599.89 764.86,-599.89 764.86,-637.89"/>
+<text text-anchor="middle" x="663.36" y="-622.69" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 9</text>
+<text text-anchor="middle" x="663.36" y="-607.69" font-family="Times,serif" font-size="14.00">/dev/video9</text>
+</g>
+<!-- n00000029 -->
+<g id="node11" class="node">
+<title>n00000029</title>
+<polygon fill="yellow" stroke="black" points="358.62,-519.5 146.62,-519.5 146.62,-481.5 358.62,-481.5 358.62,-519.5"/>
+<text text-anchor="middle" x="252.62" y="-504.3" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 10</text>
+<text text-anchor="middle" x="252.62" y="-489.3" font-family="Times,serif" font-size="14.00">/dev/video10</text>
+</g>
+<!-- n0000002d -->
+<g id="node12" class="node">
+<title>n0000002d</title>
+<polygon fill="yellow" stroke="black" points="481.4,-662.59 269.4,-662.59 269.4,-624.59 481.4,-624.59 481.4,-662.59"/>
+<text text-anchor="middle" x="375.4" y="-647.39" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 11</text>
+<text text-anchor="middle" x="375.4" y="-632.39" font-family="Times,serif" font-size="14.00">/dev/video11</text>
+</g>
+<!-- n00000031 -->
+<g id="node13" class="node">
+<title>n00000031</title>
+<polygon fill="yellow" stroke="black" points="637.17,-837.47 425.17,-837.47 425.17,-799.47 637.17,-799.47 637.17,-837.47"/>
+<text text-anchor="middle" x="531.17" y="-822.27" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 12</text>
+<text text-anchor="middle" x="531.17" y="-807.27" font-family="Times,serif" font-size="14.00">/dev/video12</text>
+</g>
+<!-- n00000035 -->
+<g id="node14" class="node">
+<title>n00000035</title>
+<polygon fill="yellow" stroke="black" points="337.75,-833.67 125.75,-833.67 125.75,-795.67 337.75,-795.67 337.75,-833.67"/>
+<text text-anchor="middle" x="231.75" y="-818.47" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 13</text>
+<text text-anchor="middle" x="231.75" y="-803.47" font-family="Times,serif" font-size="14.00">/dev/video13</text>
+</g>
+<!-- n00000039 -->
+<g id="node15" class="node">
+<title>n00000039</title>
+<polygon fill="yellow" stroke="black" points="393.07,-317.96 181.07,-317.96 181.07,-279.96 393.07,-279.96 393.07,-317.96"/>
+<text text-anchor="middle" x="287.07" y="-302.76" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 14</text>
+<text text-anchor="middle" x="287.07" y="-287.76" font-family="Times,serif" font-size="14.00">/dev/video14</text>
+</g>
+<!-- n0000003d -->
+<g id="node16" class="node">
+<title>n0000003d</title>
+<polygon fill="yellow" stroke="black" points="701.46,-391.04 489.46,-391.04 489.46,-353.04 701.46,-353.04 701.46,-391.04"/>
+<text text-anchor="middle" x="595.46" y="-375.84" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 15</text>
+<text text-anchor="middle" x="595.46" y="-360.84" font-family="Times,serif" font-size="14.00">/dev/video15</text>
+</g>
+<!-- n00000041 -->
+<g id="node17" class="node">
+<title>n00000041</title>
+<polygon fill="yellow" stroke="black" points="212.45,-1228.8 0.45,-1228.8 0.45,-1190.8 212.45,-1190.8 212.45,-1228.8"/>
+<text text-anchor="middle" x="106.45" y="-1213.6" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 16</text>
+<text text-anchor="middle" x="106.45" y="-1198.6" font-family="Times,serif" font-size="14.00">/dev/video16</text>
+</g>
+<!-- n00000045 -->
+<g id="node18" class="node">
+<title>n00000045</title>
+<polygon fill="yellow" stroke="black" points="784.86,-1252.38 572.86,-1252.38 572.86,-1214.38 784.86,-1214.38 784.86,-1252.38"/>
+<text text-anchor="middle" x="678.86" y="-1237.18" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 17</text>
+<text text-anchor="middle" x="678.86" y="-1222.18" font-family="Times,serif" font-size="14.00">/dev/video17</text>
+</g>
+<!-- n00000049 -->
+<g id="node19" class="node">
+<title>n00000049</title>
+<polygon fill="yellow" stroke="black" points="503.14,-1169.96 291.14,-1169.96 291.14,-1131.96 503.14,-1131.96 503.14,-1169.96"/>
+<text text-anchor="middle" x="397.14" y="-1154.76" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 18</text>
+<text text-anchor="middle" x="397.14" y="-1139.76" font-family="Times,serif" font-size="14.00">/dev/video18</text>
+</g>
+<!-- n0000004d -->
+<g id="node20" class="node">
+<title>n0000004d</title>
+<polygon fill="yellow" stroke="black" points="492.62,-1319.4 280.62,-1319.4 280.62,-1281.4 492.62,-1281.4 492.62,-1319.4"/>
+<text text-anchor="middle" x="386.62" y="-1304.2" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 19</text>
+<text text-anchor="middle" x="386.62" y="-1289.2" font-family="Times,serif" font-size="14.00">/dev/video19</text>
+</g>
+<!-- n00000051 -->
+<g id="node21" class="node">
+<title>n00000051</title>
+<polygon fill="yellow" stroke="black" points="680.74,-1464.66 468.74,-1464.66 468.74,-1426.66 680.74,-1426.66 680.74,-1464.66"/>
+<text text-anchor="middle" x="574.74" y="-1449.46" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 20</text>
+<text text-anchor="middle" x="574.74" y="-1434.46" font-family="Times,serif" font-size="14.00">/dev/video20</text>
+</g>
+<!-- n00000055 -->
+<g id="node22" class="node">
+<title>n00000055</title>
+<polygon fill="yellow" stroke="black" points="302.42,-1452.56 90.42,-1452.56 90.42,-1414.56 302.42,-1414.56 302.42,-1452.56"/>
+<text text-anchor="middle" x="196.42" y="-1437.36" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 21</text>
+<text text-anchor="middle" x="196.42" y="-1422.36" font-family="Times,serif" font-size="14.00">/dev/video21</text>
+</g>
+<!-- n00000059 -->
+<g id="node23" class="node">
+<title>n00000059</title>
+<polygon fill="yellow" stroke="black" points="319.89,-1018.32 107.89,-1018.32 107.89,-980.32 319.89,-980.32 319.89,-1018.32"/>
+<text text-anchor="middle" x="213.89" y="-1003.12" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 22</text>
+<text text-anchor="middle" x="213.89" y="-988.12" font-family="Times,serif" font-size="14.00">/dev/video22</text>
+</g>
+<!-- n0000005d -->
+<g id="node24" class="node">
+<title>n0000005d</title>
+<polygon fill="yellow" stroke="black" points="692.62,-1031.39 480.62,-1031.39 480.62,-993.39 692.62,-993.39 692.62,-1031.39"/>
+<text text-anchor="middle" x="586.62" y="-1016.19" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 23</text>
+<text text-anchor="middle" x="586.62" y="-1001.19" font-family="Times,serif" font-size="14.00">/dev/video23</text>
+</g>
+<!-- n00000061 -->
+<g id="node25" class="node">
+<title>n00000061</title>
+<polygon fill="yellow" stroke="black" points="1122.45,-248.8 910.45,-248.8 910.45,-210.8 1122.45,-210.8 1122.45,-248.8"/>
+<text text-anchor="middle" x="1016.45" y="-233.6" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 24</text>
+<text text-anchor="middle" x="1016.45" y="-218.6" font-family="Times,serif" font-size="14.00">/dev/video24</text>
+</g>
+<!-- n00000065 -->
+<g id="node26" class="node">
+<title>n00000065</title>
+<polygon fill="yellow" stroke="black" points="1694.86,-272.38 1482.86,-272.38 1482.86,-234.38 1694.86,-234.38 1694.86,-272.38"/>
+<text text-anchor="middle" x="1588.86" y="-257.18" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 25</text>
+<text text-anchor="middle" x="1588.86" y="-242.18" font-family="Times,serif" font-size="14.00">/dev/video25</text>
+</g>
+<!-- n00000069 -->
+<g id="node27" class="node">
+<title>n00000069</title>
+<polygon fill="yellow" stroke="black" points="1413.14,-189.96 1201.14,-189.96 1201.14,-151.96 1413.14,-151.96 1413.14,-189.96"/>
+<text text-anchor="middle" x="1307.14" y="-174.76" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 26</text>
+<text text-anchor="middle" x="1307.14" y="-159.76" font-family="Times,serif" font-size="14.00">/dev/video26</text>
+</g>
+<!-- n0000006d -->
+<g id="node28" class="node">
+<title>n0000006d</title>
+<polygon fill="yellow" stroke="black" points="1402.62,-339.4 1190.62,-339.4 1190.62,-301.4 1402.62,-301.4 1402.62,-339.4"/>
+<text text-anchor="middle" x="1296.62" y="-324.2" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 27</text>
+<text text-anchor="middle" x="1296.62" y="-309.2" font-family="Times,serif" font-size="14.00">/dev/video27</text>
+</g>
+<!-- n00000071 -->
+<g id="node29" class="node">
+<title>n00000071</title>
+<polygon fill="yellow" stroke="black" points="1590.74,-484.66 1378.74,-484.66 1378.74,-446.66 1590.74,-446.66 1590.74,-484.66"/>
+<text text-anchor="middle" x="1484.74" y="-469.46" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 28</text>
+<text text-anchor="middle" x="1484.74" y="-454.46" font-family="Times,serif" font-size="14.00">/dev/video28</text>
+</g>
+<!-- n00000075 -->
+<g id="node30" class="node">
+<title>n00000075</title>
+<polygon fill="yellow" stroke="black" points="1212.42,-472.56 1000.42,-472.56 1000.42,-434.56 1212.42,-434.56 1212.42,-472.56"/>
+<text text-anchor="middle" x="1106.42" y="-457.36" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 29</text>
+<text text-anchor="middle" x="1106.42" y="-442.36" font-family="Times,serif" font-size="14.00">/dev/video29</text>
+</g>
+<!-- n00000079 -->
+<g id="node31" class="node">
+<title>n00000079</title>
+<polygon fill="yellow" stroke="black" points="1229.89,-38.32 1017.89,-38.32 1017.89,-0.32 1229.89,-0.32 1229.89,-38.32"/>
+<text text-anchor="middle" x="1123.89" y="-23.12" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 30</text>
+<text text-anchor="middle" x="1123.89" y="-8.12" font-family="Times,serif" font-size="14.00">/dev/video30</text>
+</g>
+<!-- n0000007d -->
+<g id="node32" class="node">
+<title>n0000007d</title>
+<polygon fill="yellow" stroke="black" points="1602.62,-51.39 1390.62,-51.39 1390.62,-13.39 1602.62,-13.39 1602.62,-51.39"/>
+<text text-anchor="middle" x="1496.62" y="-36.19" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 31</text>
+<text text-anchor="middle" x="1496.62" y="-21.19" font-family="Times,serif" font-size="14.00">/dev/video31</text>
+</g>
+<!-- n00000081 -->
+<g id="node33" class="node">
+<title>n00000081</title>
+<path fill="green" stroke="black" d="M924.28,-700.28C924.28,-700.28 1108.28,-700.28 1108.28,-700.28 1114.28,-700.28 1120.28,-706.28 1120.28,-712.28 1120.28,-712.28 1120.28,-772.28 1120.28,-772.28 1120.28,-778.28 1114.28,-784.28 1108.28,-784.28 1108.28,-784.28 924.28,-784.28 924.28,-784.28 918.28,-784.28 912.28,-778.28 912.28,-772.28 912.28,-772.28 912.28,-712.28 912.28,-712.28 912.28,-706.28 918.28,-700.28 924.28,-700.28"/>
+<text text-anchor="middle" x="1016.28" y="-769.08" font-family="Times,serif" font-size="14.00">0</text>
+<polyline fill="none" stroke="black" points="912.28,-761.28 1120.28,-761.28 "/>
+<text text-anchor="middle" x="1016.28" y="-746.08" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 0</text>
+<text text-anchor="middle" x="1016.28" y="-731.08" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev0</text>
+<polyline fill="none" stroke="black" points="912.28,-723.28 1120.28,-723.28 "/>
+<text text-anchor="middle" x="925.28" y="-708.08" font-family="Times,serif" font-size="14.00">1</text>
+<polyline fill="none" stroke="black" points="938.28,-700.28 938.28,-723.28 "/>
+<text text-anchor="middle" x="951.28" y="-708.08" font-family="Times,serif" font-size="14.00">2</text>
+<polyline fill="none" stroke="black" points="964.28,-700.28 964.28,-723.28 "/>
+<text text-anchor="middle" x="977.28" y="-708.08" font-family="Times,serif" font-size="14.00">3</text>
+<polyline fill="none" stroke="black" points="990.28,-700.28 990.28,-723.28 "/>
+<text text-anchor="middle" x="1003.28" y="-708.08" font-family="Times,serif" font-size="14.00">4</text>
+<polyline fill="none" stroke="black" points="1016.28,-700.28 1016.28,-723.28 "/>
+<text text-anchor="middle" x="1029.28" y="-708.08" font-family="Times,serif" font-size="14.00">5</text>
+<polyline fill="none" stroke="black" points="1042.28,-700.28 1042.28,-723.28 "/>
+<text text-anchor="middle" x="1055.28" y="-708.08" font-family="Times,serif" font-size="14.00">6</text>
+<polyline fill="none" stroke="black" points="1068.28,-700.28 1068.28,-723.28 "/>
+<text text-anchor="middle" x="1081.28" y="-708.08" font-family="Times,serif" font-size="14.00">7</text>
+<polyline fill="none" stroke="black" points="1094.28,-700.28 1094.28,-723.28 "/>
+<text text-anchor="middle" x="1107.28" y="-708.08" font-family="Times,serif" font-size="14.00">8</text>
+</g>
+<!-- n00000081&#45;&gt;n00000001 -->
+<g id="edge1" class="edge">
+<title>n00000081:port1&#45;&gt;n00000001</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M912.28,-711.28C912.28,-711.28 880.33,-714.78 843.28,-718.84"/>
+<polygon fill="black" stroke="black" points="842.81,-715.37 833.25,-719.94 843.57,-722.33 842.81,-715.37"/>
+</g>
+<!-- n00000081&#45;&gt;n00000005 -->
+<g id="edge2" class="edge">
+<title>n00000081:port2&#45;&gt;n00000005</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M951.38,-700.28C951.38,-700.28 1086.18,-688.61 1123.48,-697.08 1155.93,-704.45 1158.99,-719.67 1190.39,-730.68 1190.49,-730.71 1190.59,-730.75 1190.69,-730.78"/>
+<polygon fill="black" stroke="black" points="1189.45,-734.06 1200.05,-733.86 1191.64,-727.41 1189.45,-734.06"/>
+</g>
+<!-- n00000081&#45;&gt;n00000009 -->
+<g id="edge3" class="edge">
+<title>n00000081:port3&#45;&gt;n00000009</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M977.28,-700.28C977.28,-700.28 979.31,-698.81 982.45,-696.54"/>
+<polygon fill="black" stroke="black" points="984.7,-699.23 990.74,-690.53 980.59,-693.56 984.7,-699.23"/>
+</g>
+<!-- n00000081&#45;&gt;n0000000d -->
+<g id="edge4" class="edge">
+<title>n00000081:port4&#45;&gt;n0000000d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1003.38,-700.26C1003.38,-700.26 916.62,-689.8 909.08,-697.08 880.2,-725.01 885.68,-754.82 909.08,-787.48 910.88,-789.99 918.96,-793.59 929.7,-797.47"/>
+<polygon fill="black" stroke="black" points="928.69,-800.82 939.28,-800.79 930.98,-794.21 928.69,-800.82"/>
+</g>
+<!-- n00000081&#45;&gt;n00000011 -->
+<g id="edge5" class="edge">
+<title>n00000081:port5&#45;&gt;n00000011</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1029.19,-700.26C1029.19,-700.26 1115.28,-690.56 1123.48,-697.08 1198.37,-756.64 1190.55,-886.51 1182.64,-944.71"/>
+<polygon fill="black" stroke="black" points="1179.16,-944.31 1181.18,-954.71 1186.09,-945.32 1179.16,-944.31"/>
+</g>
+<!-- n00000081&#45;&gt;n00000015 -->
+<g id="edge6" class="edge">
+<title>n00000081:port6&#45;&gt;n00000015</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1055.18,-700.28C1055.18,-700.28 915.57,-692.2 909.08,-697.08 834.02,-753.51 831.79,-879.34 835.06,-936.56"/>
+<polygon fill="black" stroke="black" points="831.58,-936.99 835.74,-946.73 838.56,-936.52 831.58,-936.99"/>
+</g>
+<!-- n00000081&#45;&gt;n00000019 -->
+<g id="edge7" class="edge">
+<title>n00000081:port7&#45;&gt;n00000019</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1081.28,-700.28C1081.28,-700.28 916.04,-696.54 912.32,-693.67 864.52,-656.73 856.3,-580.22 855.62,-538.2"/>
+<polygon fill="black" stroke="black" points="859.11,-538.05 855.59,-528.06 852.11,-538.07 859.11,-538.05"/>
+</g>
+<!-- n00000081&#45;&gt;n0000001d -->
+<g id="edge8" class="edge">
+<title>n00000081:port8&#45;&gt;n0000001d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1107.28,-700.28C1107.28,-700.28 1119.29,-696.23 1121.72,-693.67 1159.76,-653.62 1177.38,-589.6 1184.78,-552.46"/>
+<polygon fill="black" stroke="black" points="1188.29,-552.76 1186.69,-542.29 1181.41,-551.47 1188.29,-552.76"/>
+</g>
+<!-- n0000008b -->
+<g id="node34" class="node">
+<title>n0000008b</title>
+<path fill="green" stroke="black" d="M293.1,-532.08C293.1,-532.08 477.1,-532.08 477.1,-532.08 483.1,-532.08 489.1,-538.08 489.1,-544.08 489.1,-544.08 489.1,-604.08 489.1,-604.08 489.1,-610.08 483.1,-616.08 477.1,-616.08 477.1,-616.08 293.1,-616.08 293.1,-616.08 287.1,-616.08 281.1,-610.08 281.1,-604.08 281.1,-604.08 281.1,-544.08 281.1,-544.08 281.1,-538.08 287.1,-532.08 293.1,-532.08"/>
+<text text-anchor="middle" x="385.1" y="-600.88" font-family="Times,serif" font-size="14.00">0</text>
+<polyline fill="none" stroke="black" points="281.1,-593.08 489.1,-593.08 "/>
+<text text-anchor="middle" x="385.1" y="-577.88" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 1</text>
+<text text-anchor="middle" x="385.1" y="-562.88" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev1</text>
+<polyline fill="none" stroke="black" points="281.1,-555.08 489.1,-555.08 "/>
+<text text-anchor="middle" x="294.1" y="-539.88" font-family="Times,serif" font-size="14.00">1</text>
+<polyline fill="none" stroke="black" points="307.1,-532.08 307.1,-555.08 "/>
+<text text-anchor="middle" x="320.1" y="-539.88" font-family="Times,serif" font-size="14.00">2</text>
+<polyline fill="none" stroke="black" points="333.1,-532.08 333.1,-555.08 "/>
+<text text-anchor="middle" x="346.1" y="-539.88" font-family="Times,serif" font-size="14.00">3</text>
+<polyline fill="none" stroke="black" points="359.1,-532.08 359.1,-555.08 "/>
+<text text-anchor="middle" x="372.1" y="-539.88" font-family="Times,serif" font-size="14.00">4</text>
+<polyline fill="none" stroke="black" points="385.1,-532.08 385.1,-555.08 "/>
+<text text-anchor="middle" x="398.1" y="-539.88" font-family="Times,serif" font-size="14.00">5</text>
+<polyline fill="none" stroke="black" points="411.1,-532.08 411.1,-555.08 "/>
+<text text-anchor="middle" x="424.1" y="-539.88" font-family="Times,serif" font-size="14.00">6</text>
+<polyline fill="none" stroke="black" points="437.1,-532.08 437.1,-555.08 "/>
+<text text-anchor="middle" x="450.1" y="-539.88" font-family="Times,serif" font-size="14.00">7</text>
+<polyline fill="none" stroke="black" points="463.1,-532.08 463.1,-555.08 "/>
+<text text-anchor="middle" x="476.1" y="-539.88" font-family="Times,serif" font-size="14.00">8</text>
+</g>
+<!-- n0000008b&#45;&gt;n00000021 -->
+<g id="edge9" class="edge">
+<title>n0000008b:port1&#45;&gt;n00000021</title>
+<path fill="none" stroke="black" d="M281.1,-543.08C281.1,-543.08 240.1,-560.51 205.94,-570.26 205.35,-570.43 204.77,-570.59 204.18,-570.76"/>
+<polygon fill="black" stroke="black" points="203.2,-567.39 194.47,-573.39 205.03,-574.15 203.2,-567.39"/>
+</g>
+<!-- n0000008b&#45;&gt;n00000025 -->
+<g id="edge10" class="edge">
+<title>n0000008b:port2&#45;&gt;n00000025</title>
+<path fill="none" stroke="black" d="M320.2,-532.07C320.2,-532.07 456.9,-514.37 492.3,-528.88 528.42,-543.68 522.86,-571.78 556.11,-594.53"/>
+<polygon fill="black" stroke="black" points="554.54,-597.67 564.9,-599.88 558.18,-591.69 554.54,-597.67"/>
+</g>
+<!-- n0000008b&#45;&gt;n00000029 -->
+<g id="edge11" class="edge">
+<title>n0000008b:port3&#45;&gt;n00000029</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M346.1,-532.08C346.1,-532.08 333.93,-527.96 318.37,-522.71"/>
+<polygon fill="black" stroke="black" points="319.48,-519.39 308.88,-519.5 317.24,-526.02 319.48,-519.39"/>
+</g>
+<!-- n0000008b&#45;&gt;n0000002d -->
+<g id="edge12" class="edge">
+<title>n0000008b:port4&#45;&gt;n0000002d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M372.19,-532.05C372.19,-532.05 292.97,-514.3 277.9,-528.88 249.01,-556.8 253.16,-587.62 277.9,-619.28 278.34,-619.85 280.33,-620.69 283.45,-621.71"/>
+<polygon fill="black" stroke="black" points="282.71,-625.14 293.29,-624.58 284.67,-618.42 282.71,-625.14"/>
+</g>
+<!-- n0000008b&#45;&gt;n00000031 -->
+<g id="edge13" class="edge">
+<title>n0000008b:port5&#45;&gt;n00000031</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M398,-532.05C398,-532.05 476.28,-515.34 492.3,-528.88 568.49,-593.29 550.55,-729.67 538.14,-789.41"/>
+<polygon fill="black" stroke="black" points="534.69,-788.79 535.99,-799.31 541.53,-790.28 534.69,-788.79"/>
+</g>
+<!-- n0000008b&#45;&gt;n00000035 -->
+<g id="edge14" class="edge">
+<title>n0000008b:port6&#45;&gt;n00000035</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M424,-532.07C424,-532.07 290.37,-518.48 277.9,-528.88 202.27,-591.86 215.34,-725.69 225.66,-785.15"/>
+<polygon fill="black" stroke="black" points="222.29,-786.14 227.54,-795.35 229.17,-784.88 222.29,-786.14"/>
+</g>
+<!-- n0000008b&#45;&gt;n00000039 -->
+<g id="edge15" class="edge">
+<title>n0000008b:port7&#45;&gt;n00000039</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M450.1,-532.08C450.1,-532.08 395.22,-528.13 383.45,-518.65 375.46,-512.21 322.64,-385.46 298.76,-327.47"/>
+<polygon fill="black" stroke="black" points="301.96,-326.05 294.92,-318.14 295.49,-328.72 301.96,-326.05"/>
+</g>
+<!-- n0000008b&#45;&gt;n0000003d -->
+<g id="edge16" class="edge">
+<title>n0000008b:port8&#45;&gt;n0000003d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M476.1,-532.08C476.1,-532.08 522.37,-522.39 526.85,-518.65 563.15,-488.33 581.38,-434.52 589.6,-401.2"/>
+<polygon fill="black" stroke="black" points="593.08,-401.69 591.93,-391.16 586.26,-400.11 593.08,-401.69"/>
+</g>
+<!-- n00000095 -->
+<g id="node35" class="node">
+<title>n00000095</title>
+<path fill="green" stroke="black" d="M301.38,-1180.11C301.38,-1180.11 485.38,-1180.11 485.38,-1180.11 491.38,-1180.11 497.38,-1186.11 497.38,-1192.11 497.38,-1192.11 497.38,-1252.11 497.38,-1252.11 497.38,-1258.11 491.38,-1264.11 485.38,-1264.11 485.38,-1264.11 301.38,-1264.11 301.38,-1264.11 295.38,-1264.11 289.38,-1258.11 289.38,-1252.11 289.38,-1252.11 289.38,-1192.11 289.38,-1192.11 289.38,-1186.11 295.38,-1180.11 301.38,-1180.11"/>
+<text text-anchor="middle" x="393.38" y="-1248.91" font-family="Times,serif" font-size="14.00">0</text>
+<polyline fill="none" stroke="black" points="289.38,-1241.11 497.38,-1241.11 "/>
+<text text-anchor="middle" x="393.38" y="-1225.91" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 2</text>
+<text text-anchor="middle" x="393.38" y="-1210.91" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev2</text>
+<polyline fill="none" stroke="black" points="289.38,-1203.11 497.38,-1203.11 "/>
+<text text-anchor="middle" x="302.38" y="-1187.91" font-family="Times,serif" font-size="14.00">1</text>
+<polyline fill="none" stroke="black" points="315.38,-1180.11 315.38,-1203.11 "/>
+<text text-anchor="middle" x="328.38" y="-1187.91" font-family="Times,serif" font-size="14.00">2</text>
+<polyline fill="none" stroke="black" points="341.38,-1180.11 341.38,-1203.11 "/>
+<text text-anchor="middle" x="354.38" y="-1187.91" font-family="Times,serif" font-size="14.00">3</text>
+<polyline fill="none" stroke="black" points="367.38,-1180.11 367.38,-1203.11 "/>
+<text text-anchor="middle" x="380.38" y="-1187.91" font-family="Times,serif" font-size="14.00">4</text>
+<polyline fill="none" stroke="black" points="393.38,-1180.11 393.38,-1203.11 "/>
+<text text-anchor="middle" x="406.38" y="-1187.91" font-family="Times,serif" font-size="14.00">5</text>
+<polyline fill="none" stroke="black" points="419.38,-1180.11 419.38,-1203.11 "/>
+<text text-anchor="middle" x="432.38" y="-1187.91" font-family="Times,serif" font-size="14.00">6</text>
+<polyline fill="none" stroke="black" points="445.38,-1180.11 445.38,-1203.11 "/>
+<text text-anchor="middle" x="458.38" y="-1187.91" font-family="Times,serif" font-size="14.00">7</text>
+<polyline fill="none" stroke="black" points="471.38,-1180.11 471.38,-1203.11 "/>
+<text text-anchor="middle" x="484.38" y="-1187.91" font-family="Times,serif" font-size="14.00">8</text>
+</g>
+<!-- n00000095&#45;&gt;n00000041 -->
+<g id="edge17" class="edge">
+<title>n00000095:port1&#45;&gt;n00000041</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M289.38,-1191.11C289.38,-1191.11 258.94,-1194.22 222.89,-1197.91"/>
+<polygon fill="black" stroke="black" points="222.19,-1194.46 212.6,-1198.96 222.9,-1201.42 222.19,-1194.46"/>
+</g>
+<!-- n00000095&#45;&gt;n00000045 -->
+<g id="edge18" class="edge">
+<title>n00000095:port2&#45;&gt;n00000045</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M328.48,-1180.11C328.48,-1180.11 463.26,-1168.53 500.58,-1176.91 534.02,-1184.43 537.24,-1200.06 569.66,-1211.18 569.76,-1211.22 569.86,-1211.25 569.96,-1211.29"/>
+<polygon fill="black" stroke="black" points="568.86,-1214.61 579.45,-1214.34 571,-1207.95 568.86,-1214.61"/>
+</g>
+<!-- n00000095&#45;&gt;n00000049 -->
+<g id="edge19" class="edge">
+<title>n00000095:port3&#45;&gt;n00000049</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M354.38,-1180.11C354.38,-1180.11 356.8,-1178.46 360.49,-1175.94"/>
+<polygon fill="black" stroke="black" points="362.56,-1178.77 368.86,-1170.24 358.62,-1172.98 362.56,-1178.77"/>
+</g>
+<!-- n00000095&#45;&gt;n0000004d -->
+<g id="edge20" class="edge">
+<title>n00000095:port4&#45;&gt;n0000004d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M380.47,-1180.09C380.47,-1180.09 293.71,-1169.63 286.18,-1176.91 257.29,-1204.84 262.63,-1234.76 286.18,-1267.31 288.16,-1270.05 297.33,-1273.96 309.38,-1278.13"/>
+<polygon fill="black" stroke="black" points="308.49,-1281.53 319.09,-1281.36 310.7,-1274.88 308.49,-1281.53"/>
+</g>
+<!-- n00000095&#45;&gt;n00000051 -->
+<g id="edge21" class="edge">
+<title>n00000095:port5&#45;&gt;n00000051</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M406.28,-1180.09C406.28,-1180.09 492.13,-1170.7 500.58,-1176.91 576.41,-1232.66 579.83,-1358.79 577.09,-1416.2"/>
+<polygon fill="black" stroke="black" points="573.59,-1416.23 576.51,-1426.41 580.58,-1416.63 573.59,-1416.23"/>
+</g>
+<!-- n00000095&#45;&gt;n00000055 -->
+<g id="edge22" class="edge">
+<title>n00000095:port6&#45;&gt;n00000055</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M432.28,-1180.11C432.28,-1180.11 292.85,-1172.29 286.18,-1176.91 211.26,-1228.86 198.3,-1348.49 196.45,-1404.12"/>
+<polygon fill="black" stroke="black" points="192.94,-1404.28 196.21,-1414.36 199.94,-1404.44 192.94,-1404.28"/>
+</g>
+<!-- n00000095&#45;&gt;n00000059 -->
+<g id="edge23" class="edge">
+<title>n00000095:port7&#45;&gt;n00000059</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M458.38,-1180.11C458.38,-1180.11 291.84,-1175.85 287.94,-1173.16 239.87,-1139.96 222.85,-1068.83 216.94,-1028.6"/>
+<polygon fill="black" stroke="black" points="220.39,-1028.06 215.6,-1018.61 213.46,-1028.98 220.39,-1028.06"/>
+</g>
+<!-- n00000095&#45;&gt;n0000005d -->
+<g id="edge24" class="edge">
+<title>n00000095:port8&#45;&gt;n0000005d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M484.38,-1180.11C484.38,-1180.11 502.45,-1176.49 506.34,-1173.16 547.25,-1138.2 569.47,-1077.38 579.62,-1041.41"/>
+<polygon fill="black" stroke="black" points="583.06,-1042.09 582.28,-1031.53 576.3,-1040.27 583.06,-1042.09"/>
+</g>
+<!-- n0000009f -->
+<g id="node36" class="node">
+<title>n0000009f</title>
+<path fill="green" stroke="black" d="M1211.38,-200.11C1211.38,-200.11 1395.38,-200.11 1395.38,-200.11 1401.38,-200.11 1407.38,-206.11 1407.38,-212.11 1407.38,-212.11 1407.38,-272.11 1407.38,-272.11 1407.38,-278.11 1401.38,-284.11 1395.38,-284.11 1395.38,-284.11 1211.38,-284.11 1211.38,-284.11 1205.38,-284.11 1199.38,-278.11 1199.38,-272.11 1199.38,-272.11 1199.38,-212.11 1199.38,-212.11 1199.38,-206.11 1205.38,-200.11 1211.38,-200.11"/>
+<text text-anchor="middle" x="1303.38" y="-268.91" font-family="Times,serif" font-size="14.00">0</text>
+<polyline fill="none" stroke="black" points="1199.38,-261.11 1407.38,-261.11 "/>
+<text text-anchor="middle" x="1303.38" y="-245.91" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 3</text>
+<text text-anchor="middle" x="1303.38" y="-230.91" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev3</text>
+<polyline fill="none" stroke="black" points="1199.38,-223.11 1407.38,-223.11 "/>
+<text text-anchor="middle" x="1212.38" y="-207.91" font-family="Times,serif" font-size="14.00">1</text>
+<polyline fill="none" stroke="black" points="1225.38,-200.11 1225.38,-223.11 "/>
+<text text-anchor="middle" x="1238.38" y="-207.91" font-family="Times,serif" font-size="14.00">2</text>
+<polyline fill="none" stroke="black" points="1251.38,-200.11 1251.38,-223.11 "/>
+<text text-anchor="middle" x="1264.38" y="-207.91" font-family="Times,serif" font-size="14.00">3</text>
+<polyline fill="none" stroke="black" points="1277.38,-200.11 1277.38,-223.11 "/>
+<text text-anchor="middle" x="1290.38" y="-207.91" font-family="Times,serif" font-size="14.00">4</text>
+<polyline fill="none" stroke="black" points="1303.38,-200.11 1303.38,-223.11 "/>
+<text text-anchor="middle" x="1316.38" y="-207.91" font-family="Times,serif" font-size="14.00">5</text>
+<polyline fill="none" stroke="black" points="1329.38,-200.11 1329.38,-223.11 "/>
+<text text-anchor="middle" x="1342.38" y="-207.91" font-family="Times,serif" font-size="14.00">6</text>
+<polyline fill="none" stroke="black" points="1355.38,-200.11 1355.38,-223.11 "/>
+<text text-anchor="middle" x="1368.38" y="-207.91" font-family="Times,serif" font-size="14.00">7</text>
+<polyline fill="none" stroke="black" points="1381.38,-200.11 1381.38,-223.11 "/>
+<text text-anchor="middle" x="1394.38" y="-207.91" font-family="Times,serif" font-size="14.00">8</text>
+</g>
+<!-- n0000009f&#45;&gt;n00000061 -->
+<g id="edge25" class="edge">
+<title>n0000009f:port1&#45;&gt;n00000061</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1199.38,-211.11C1199.38,-211.11 1168.94,-214.22 1132.89,-217.91"/>
+<polygon fill="black" stroke="black" points="1132.19,-214.46 1122.6,-218.96 1132.9,-221.42 1132.19,-214.46"/>
+</g>
+<!-- n0000009f&#45;&gt;n00000065 -->
+<g id="edge26" class="edge">
+<title>n0000009f:port2&#45;&gt;n00000065</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1238.48,-200.11C1238.48,-200.11 1373.26,-188.53 1410.58,-196.91 1444.02,-204.43 1447.24,-220.06 1479.66,-231.18 1479.76,-231.22 1479.86,-231.25 1479.96,-231.29"/>
+<polygon fill="black" stroke="black" points="1478.86,-234.61 1489.45,-234.34 1481,-227.95 1478.86,-234.61"/>
+</g>
+<!-- n0000009f&#45;&gt;n00000069 -->
+<g id="edge27" class="edge">
+<title>n0000009f:port3&#45;&gt;n00000069</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1264.38,-200.11C1264.38,-200.11 1266.8,-198.46 1270.49,-195.94"/>
+<polygon fill="black" stroke="black" points="1272.56,-198.77 1278.86,-190.24 1268.62,-192.98 1272.56,-198.77"/>
+</g>
+<!-- n0000009f&#45;&gt;n0000006d -->
+<g id="edge28" class="edge">
+<title>n0000009f:port4&#45;&gt;n0000006d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1290.47,-200.09C1290.47,-200.09 1203.71,-189.63 1196.18,-196.91 1167.29,-224.84 1172.63,-254.76 1196.18,-287.31 1198.16,-290.05 1207.33,-293.96 1219.38,-298.13"/>
+<polygon fill="black" stroke="black" points="1218.49,-301.53 1229.09,-301.36 1220.7,-294.88 1218.49,-301.53"/>
+</g>
+<!-- n0000009f&#45;&gt;n00000071 -->
+<g id="edge29" class="edge">
+<title>n0000009f:port5&#45;&gt;n00000071</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1316.28,-200.09C1316.28,-200.09 1402.13,-190.7 1410.58,-196.91 1486.41,-252.66 1489.83,-378.79 1487.09,-436.2"/>
+<polygon fill="black" stroke="black" points="1483.59,-436.23 1486.51,-446.41 1490.58,-436.63 1483.59,-436.23"/>
+</g>
+<!-- n0000009f&#45;&gt;n00000075 -->
+<g id="edge30" class="edge">
+<title>n0000009f:port6&#45;&gt;n00000075</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1342.28,-200.11C1342.28,-200.11 1202.85,-192.29 1196.18,-196.91 1121.26,-248.86 1108.3,-368.49 1106.45,-424.12"/>
+<polygon fill="black" stroke="black" points="1102.94,-424.28 1106.21,-434.36 1109.94,-424.44 1102.94,-424.28"/>
+</g>
+<!-- n0000009f&#45;&gt;n00000079 -->
+<g id="edge31" class="edge">
+<title>n0000009f:port7&#45;&gt;n00000079</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1368.38,-200.11C1368.38,-200.11 1201.84,-195.85 1197.94,-193.16 1149.87,-159.96 1132.85,-88.83 1126.94,-48.6"/>
+<polygon fill="black" stroke="black" points="1130.39,-48.06 1125.6,-38.61 1123.46,-48.98 1130.39,-48.06"/>
+</g>
+<!-- n0000009f&#45;&gt;n0000007d -->
+<g id="edge32" class="edge">
+<title>n0000009f:port8&#45;&gt;n0000007d</title>
+<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1394.38,-200.11C1394.38,-200.11 1412.45,-196.49 1416.34,-193.16 1457.25,-158.2 1479.47,-97.38 1489.62,-61.41"/>
+<polygon fill="black" stroke="black" points="1493.06,-62.09 1492.28,-51.53 1486.3,-60.27 1493.06,-62.09"/>
+</g>
+<!-- n000000e9 -->
+<g id="node37" class="node">
+<title>n000000e9</title>
+<path fill="green" stroke="black" d="M398.65,-431.45C398.65,-431.45 511.65,-431.45 511.65,-431.45 517.65,-431.45 523.65,-437.45 523.65,-443.45 523.65,-443.45 523.65,-503.45 523.65,-503.45 523.65,-509.45 517.65,-515.45 511.65,-515.45 511.65,-515.45 398.65,-515.45 398.65,-515.45 392.65,-515.45 386.65,-509.45 386.65,-503.45 386.65,-503.45 386.65,-443.45 386.65,-443.45 386.65,-437.45 392.65,-431.45 398.65,-431.45"/>
+<text text-anchor="middle" x="420.65" y="-500.25" font-family="Times,serif" font-size="14.00">1</text>
+<polyline fill="none" stroke="black" points="454.65,-492.45 454.65,-515.45 "/>
+<text text-anchor="middle" x="489.15" y="-500.25" font-family="Times,serif" font-size="14.00">2</text>
+<polyline fill="none" stroke="black" points="386.65,-492.45 523.65,-492.45 "/>
+<text text-anchor="middle" x="455.15" y="-477.25" font-family="Times,serif" font-size="14.00">ov2740 4&#45;0036</text>
+<text text-anchor="middle" x="455.15" y="-462.25" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev4</text>
+<polyline fill="none" stroke="black" points="386.65,-454.45 523.65,-454.45 "/>
+<text text-anchor="middle" x="455.15" y="-439.25" font-family="Times,serif" font-size="14.00">0</text>
+</g>
+<!-- n000000e9&#45;&gt;n0000008b -->
+<g id="edge33" class="edge">
+<title>n000000e9:port0&#45;&gt;n0000008b:port0</title>
+<path fill="none" stroke="black" stroke-width="2" d="M386.14,-442.55C386.14,-442.55 361.11,-493.23 383.45,-518.65 391.47,-527.78 484.31,-519.72 492.3,-528.88 508.64,-547.6 499.26,-579.87 493.12,-595.68"/>
+<polygon fill="black" stroke="black" stroke-width="2" points="489.86,-594.41 489.11,-604.98 496.29,-597.19 489.86,-594.41"/>
+</g>
+</g>
+</svg>
diff --git a/Documentation/admin-guide/media/ivtv.rst b/Documentation/admin-guide/media/ivtv.rst
index 101f16d0263e..8b65ac3f5321 100644
--- a/Documentation/admin-guide/media/ivtv.rst
+++ b/Documentation/admin-guide/media/ivtv.rst
@@ -3,7 +3,7 @@
The ivtv driver
===============
-Author: Hans Verkuil <hverkuil@xs4all.nl>
+Author: Hans Verkuil <hverkuil@kernel.org>
This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder.
The cx23415 can do both encoding and decoding, the cx23416 can only do MPEG
diff --git a/Documentation/admin-guide/media/mali-c55-graph.dot b/Documentation/admin-guide/media/mali-c55-graph.dot
new file mode 100644
index 000000000000..0775ba42bf4c
--- /dev/null
+++ b/Documentation/admin-guide/media/mali-c55-graph.dot
@@ -0,0 +1,19 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{} | mali-c55 tpg\n/dev/v4l-subdev0 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port0 -> n00000003:port0 [style=dashed]
+ n00000003 [label="{{<port0> 0} | mali-c55 isp\n/dev/v4l-subdev1 | {<port1> 1 | <port2> 2}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000003:port1 -> n00000007:port0 [style=bold]
+ n00000003:port2 -> n00000007:port2 [style=bold]
+ n00000003:port1 -> n0000000b:port0 [style=bold]
+ n00000007 [label="{{<port0> 0 | <port2> 2} | mali-c55 resizer fr\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000007:port1 -> n0000000e [style=bold]
+ n0000000b [label="{{<port0> 0} | mali-c55 resizer ds\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000000b:port1 -> n00000012 [style=bold]
+ n0000000e [label="mali-c55 fr\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n00000012 [label="mali-c55 ds\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n00000022 [label="{{<port0> 0} | csi2-rx\n/dev/v4l-subdev4 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000022:port1 -> n00000003:port0
+ n00000027 [label="{{} | imx415 1-001a\n/dev/v4l-subdev5 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000027:port0 -> n00000022:port0 [style=bold]
+} \ No newline at end of file
diff --git a/Documentation/admin-guide/media/mali-c55.rst b/Documentation/admin-guide/media/mali-c55.rst
new file mode 100644
index 000000000000..315f982000c4
--- /dev/null
+++ b/Documentation/admin-guide/media/mali-c55.rst
@@ -0,0 +1,413 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+ARM Mali-C55 Image Signal Processor driver
+==========================================
+
+Introduction
+============
+
+This file documents the driver for ARM's Mali-C55 Image Signal Processor. The
+driver is located under drivers/media/platform/arm/mali-c55.
+
+The Mali-C55 ISP receives data in either raw Bayer format or RGB/YUV format from
+sensors through either a parallel interface or a memory bus before processing it
+and outputting it through an internal DMA engine. Two output pipelines are
+possible (though one may not be fitted, depending on the implementation). These
+are referred to as "Full resolution" and "Downscale", but the naming is historic
+and both pipes are capable of cropping/scaling operations. The full resolution
+pipe is also capable of outputting RAW data, bypassing much of the ISP's
+processing. The downscale pipe cannot output RAW data. An integrated test
+pattern generator can be used to drive the ISP and produce image data in the
+absence of a connected camera sensor. The driver module is named mali_c55, and
+is enabled through the CONFIG_VIDEO_MALI_C55 config option.
+
+The driver implements V4L2, Media Controller and V4L2 Subdevice interfaces and
+expects camera sensors connected to the ISP to have V4L2 subdevice interfaces.
+
+Mali-C55 ISP hardware
+=====================
+
+A high level functional view of the Mali-C55 ISP is presented below. The ISP
+takes input from either a live source or through a DMA engine for memory input,
+depending on the SoC integration.::
+
+ +---------+ +----------+ +--------+
+ | Sensor |--->| CSI-2 Rx | "Full Resolution" | DMA |
+ +---------+ +----------+ |\ Output +--->| Writer |
+ | | \ | +--------+
+ | | \ +----------+ +------+---> Streaming I/O
+ +------------+ +------->| | | | |
+ | | | |-->| Mali-C55 |--+
+ | DMA Reader |--------------->| | | ISP | |
+ | | | / | | | +---> Streaming I/O
+ +------------+ | / +----------+ | |
+ |/ +------+
+ | +--------+
+ +--->| DMA |
+ "Downscaled" | Writer |
+ Output +--------+
+
+Media Controller Topology
+=========================
+
+An example of the ISP's topology (as implemented in a system with an IMX415
+camera sensor and generic CSI-2 receiver) is below:
+
+
+.. kernel-figure:: mali-c55-graph.dot
+ :alt: mali-c55-graph.dot
+ :align: center
+
+The driver has 4 V4L2 subdevices:
+
+- `mali_c55 isp`: Responsible for configuring input crop and color space
+ conversion
+- `mali_c55 tpg`: The test pattern generator, emulating a camera sensor.
+- `mali_c55 resizer fr`: The Full-Resolution pipe resizer
+- `mali_c55 resizer ds`: The Downscale pipe resizer
+
+The driver has 3 V4L2 video devices:
+
+- `mali-c55 fr`: The full-resolution pipe's capture device
+- `mali-c55 ds`: The downscale pipe's capture device
+- `mali-c55 3a stats`: The 3A statistics capture device
+
+Frame sequences are synchronised across to two capture devices, meaning if one
+pipe is started later than the other the sequence numbers returned in its
+buffers will match those of the other pipe rather than starting from zero.
+
+Idiosyncrasies
+--------------
+
+**mali-c55 isp**
+The `mali-c55 isp` subdevice has a single sink pad to which all sources of data
+should be connected. The active source is selected by enabling the appropriate
+media link and disabling all others. The ISP has two source pads, reflecting the
+different paths through which it can internally route data. Tap points within
+the ISP allow users to divert data to avoid processing by some or all of the
+hardware's processing steps. The diagram below is intended only to highlight how
+the bypassing works and is not a true reflection of those processing steps; for
+a high-level functional block diagram see ARM's developer page for the
+ISP [3]_::
+
+ +--------------------------------------------------------------+
+ | Possible Internal ISP Data Routes |
+ | +------------+ +----------+ +------------+ |
+ +---+ | | | | | Colour | +---+
+ | 0 |--+-->| Processing |->| Demosaic |->| Space |--->| 1 |
+ +---+ | | | | | | Conversion | +---+
+ | | +------------+ +----------+ +------------+ |
+ | | +---+
+ | +---------------------------------------------------| 2 |
+ | +---+
+ | |
+ +--------------------------------------------------------------+
+
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Pad
+ - Direction
+ - Purpose
+
+ * - 0
+ - sink
+ - Data input, connected to the TPG and camera sensors
+
+ * - 1
+ - source
+ - RGB/YUV data, connected to the FR and DS V4L2 subdevices
+
+ * - 2
+ - source
+ - RAW bayer data, connected to the FR V4L2 subdevices
+
+The ISP is limited to both input and output resolutions between 640x480 and
+8192x8192, and this is reflected in the ISP and resizer subdevice's .set_fmt()
+operations.
+
+**mali-c55 resizer fr**
+The `mali-c55 resizer fr` subdevice has two _sink_ pads to reflect the different
+insertion points in the hardware (either RAW or demosaiced data):
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Pad
+ - Direction
+ - Purpose
+
+ * - 0
+ - sink
+ - Data input connected to the ISP's demosaiced stream.
+
+ * - 1
+ - source
+ - Data output connected to the capture video device
+
+ * - 2
+ - sink
+ - Data input connected to the ISP's raw data stream
+
+The data source in use is selected through the routing API; two routes each of a
+single stream are available:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Sink Pad
+ - Source Pad
+ - Purpose
+
+ * - 0
+ - 1
+ - Demosaiced data route
+
+ * - 2
+ - 1
+ - Raw data route
+
+
+If the demosaiced route is active then the FR pipe is only capable of output
+in RGB/YUV formats. If the raw route is active then the output reflects the
+input (which may be either Bayer or RGB/YUV data).
+
+Using the driver to capture video
+=================================
+
+Using the media controller APIs we can configure the input source and ISP to
+capture images in a variety of formats. In the examples below, configuring the
+media graph is done with the v4l-utils [1]_ package's media-ctl utility.
+Capturing the images is done with yavta [2]_.
+
+Configuring the input source
+----------------------------
+
+The first step is to set the input source that we wish by enabling the correct
+media link. Using the example topology above, we can select the TPG as follows:
+
+.. code-block:: none
+
+ media-ctl -l "'lte-csi2-rx':1->'mali-c55 isp':0[0]"
+ media-ctl -l "'mali-c55 tpg':0->'mali-c55 isp':0[1]"
+
+Configuring which video devices will stream data
+------------------------------------------------
+
+The driver will wait for all video devices to have their VIDIOC_STREAMON ioctl
+called before it tells the sensor to start streaming. To facilitate this we need
+to enable links to the video devices that we want to use. In the example below
+we enable the links to both of the image capture video devices
+
+.. code-block:: none
+
+ media-ctl -l "'mali-c55 resizer fr':1->'mali-c55 fr':0[1]"
+ media-ctl -l "'mali-c55 resizer ds':1->'mali-c55 ds':0[1]"
+
+Capturing bayer data from the source and processing to RGB/YUV
+--------------------------------------------------------------
+
+To capture 1920x1080 bayer data from the source and push it through the ISP's
+full processing pipeline, we configure the data formats appropriately on the
+source, ISP and resizer subdevices and set the FR resizer's routing to select
+processed data. The media bus format on the resizer's source pad will be either
+RGB121212_1X36 or YUV10_1X30, depending on whether you want to capture RGB or
+YUV. The ISP's debayering block outputs RGB data natively, setting the source
+pad format to YUV10_1X30 enables the colour space conversion block.
+
+In this example we target RGB565 output, so select RGB121212_1X36 as the resizer
+source pad's format:
+
+.. code-block:: none
+
+ # Set formats on the TPG and ISP
+ media-ctl -V "'mali-c55 tpg':0[fmt:SRGGB20_1X20/1920x1080]"
+ media-ctl -V "'mali-c55 isp':0[fmt:SRGGB20_1X20/1920x1080]"
+ media-ctl -V "'mali-c55 isp':1[fmt:SRGGB20_1X20/1920x1080]"
+
+ # Set routing on the FR resizer
+ media-ctl -R "'mali-c55 resizer fr'[0/0->1/0[1],2/0->1/0[0]]"
+
+ # Set format on the resizer, must be done AFTER the routing.
+ media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB121212_1X36/1920x1080]"
+
+The downscale output can also be used to stream data at the same time. In this
+case since only processed data can be captured through the downscale output no
+routing need be set:
+
+.. code-block:: none
+
+ # Set format on the resizer
+ media-ctl -V "'mali-c55 resizer ds':1[fmt:RGB121212_1X36/1920x1080]"
+
+Following which images can be captured from both the FR and DS output's video
+devices (simultaneously, if desired):
+
+.. code-block:: none
+
+ yavta -f RGB565 -s 1920x1080 -c10 /dev/video0
+ yavta -f RGB565 -s 1920x1080 -c10 /dev/video1
+
+Cropping the image
+~~~~~~~~~~~~~~~~~~
+
+Both the full resolution and downscale pipes can crop to a minimum resolution of
+640x480. To crop the image simply configure the resizer's sink pad's crop and
+compose rectangles and set the format on the video device:
+
+.. code-block:: none
+
+ media-ctl -V "'mali-c55 resizer fr':0[fmt:RGB121212_1X36/1920x1080 crop:(480,270)/640x480 compose:(0,0)/640x480]"
+ media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB121212_1X36/640x480]"
+ yavta -f RGB565 -s 640x480 -c10 /dev/video0
+
+Downscaling the image
+~~~~~~~~~~~~~~~~~~~~~
+
+Both the full resolution and downscale pipes can downscale the image by up to 8x
+provided the minimum 640x480 output resolution is adhered to. For the best image
+result the scaling ratio for each direction should be the same. To configure
+scaling we use the compose rectangle on the resizer's sink pad:
+
+.. code-block:: none
+
+ media-ctl -V "'mali-c55 resizer fr':0[fmt:RGB121212_1X36/1920x1080 crop:(0,0)/1920x1080 compose:(0,0)/640x480]"
+ media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB121212_1X36/640x480]"
+ yavta -f RGB565 -s 640x480 -c10 /dev/video0
+
+Capturing images in YUV formats
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If we need to output YUV data rather than RGB the color space conversion block
+needs to be active, which is achieved by setting MEDIA_BUS_FMT_YUV10_1X30 on the
+resizer's source pad. We can then configure a capture format like NV12 (here in
+its multi-planar variant)
+
+.. code-block:: none
+
+ media-ctl -V "'mali-c55 resizer fr':1[fmt:YUV10_1X30/1920x1080]"
+ yavta -f NV12M -s 1920x1080 -c10 /dev/video0
+
+Capturing RGB data from the source and processing it with the resizers
+----------------------------------------------------------------------
+
+The Mali-C55 ISP can work with sensors capable of outputting RGB data. In this
+case although none of the image quality blocks would be used it can still
+crop/scale the data in the usual way. For this reason RGB data input to the ISP
+still goes through the ISP subdevice's pad 1 to the resizer.
+
+To achieve this, the ISP's sink pad's format is set to
+MEDIA_BUS_FMT_RGB202020_1X60 - this reflects the format that data must be in to
+work with the ISP. Converting the camera sensor's output to that format is the
+responsibility of external hardware.
+
+In this example we ask the test pattern generator to give us RGB data instead of
+bayer.
+
+.. code-block:: none
+
+ media-ctl -V "'mali-c55 tpg':0[fmt:RGB202020_1X60/1920x1080]"
+ media-ctl -V "'mali-c55 isp':0[fmt:RGB202020_1X60/1920x1080]"
+
+Cropping or scaling the data can be done in exactly the same way as outlined
+earlier.
+
+Capturing raw data from the source and outputting it unmodified
+-----------------------------------------------------------------
+
+The ISP can additionally capture raw data from the source and output it on the
+full resolution pipe only, completely unmodified. In this case the downscale
+pipe can still process the data normally and be used at the same time.
+
+To configure raw bypass the FR resizer's subdevice's routing table needs to be
+configured, followed by formats in the appropriate places:
+
+.. code-block:: none
+
+ media-ctl -R "'mali-c55 resizer fr'[0/0->1/0[0],2/0->1/0[1]]"
+ media-ctl -V "'mali-c55 isp':0[fmt:RGB202020_1X60/1920x1080]"
+ media-ctl -V "'mali-c55 resizer fr':2[fmt:RGB202020_1X60/1920x1080]"
+ media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB202020_1X60/1920x1080]"
+
+ # Set format on the video device and stream
+ yavta -f RGB565 -s 1920x1080 -c10 /dev/video0
+
+.. _mali-c55-3a-stats:
+
+Capturing ISP Statistics
+========================
+
+The ISP is capable of producing statistics for consumption by image processing
+algorithms running in userspace. These statistics can be captured by queueing
+buffers to the `mali-c55 3a stats` V4L2 Device whilst the ISP is streaming. Only
+the :ref:`V4L2_META_FMT_MALI_C55_STATS <v4l2-meta-fmt-mali-c55-stats>`
+format is supported, so no format-setting need be done:
+
+.. code-block:: none
+
+ # We assume the media graph has been configured to support RGB565 capture
+ # from the mali-c55 fr V4L2 Device, which is at /dev/video0. The statistics
+ # V4L2 device is at /dev/video3
+
+ yavta -f RGB565 -s 1920x1080 -c32 /dev/video0 && \
+ yavta -c10 -F /dev/video3
+
+The layout of the buffer is described by :c:type:`mali_c55_stats_buffer`,
+but broadly statistics are generated to support three image processing
+algorithms; AEXP (Auto-Exposure), AWB (Auto-White Balance) and AF (Auto-Focus).
+These stats can be drawn from various places in the Mali C55 ISP pipeline, known
+as "tap points". This high-level block diagram is intended to explain where in
+the processing flow the statistics can be drawn from::
+
+ +--> AEXP-2 +----> AEXP-1 +--> AF-0
+ | +----> AF-1 |
+ | | |
+ +---------+ | +--------------+ | +--------------+ |
+ | Input +-+-->+ Digital Gain +---+-->+ Black Level +---+---+
+ +---------+ +--------------+ +--------------+ |
+ +-----------------------------------------------------------------+
+ |
+ | +--------------+ +---------+ +----------------+
+ +-->| Sinter Noise +-+ White +--+--->| Lens Shading +--+---------------+
+ | Reduction | | Balance | | | | | |
+ +--------------+ +---------+ | +----------------+ | |
+ +---> AEXP-0 (A) +--> AEXP-0 (B) |
+ +--------------------------------------------------------------------------+
+ |
+ | +----------------+ +--------------+ +----------------+
+ +-->| Tone mapping +-+--->| Demosaicing +->+ Purple Fringe +-+-----------+
+ | | | +--------------+ | Correction | | |
+ +----------------+ +-> AEXP-IRIDIX +----------------+ +---> AWB-0 |
+ +----------------------------------------------------------------------------+
+ | +-------------+ +-------------+
+ +------------------->| Colour +---+--->| Output |
+ | Correction | | | Pipelines |
+ +-------------+ | +-------------+
+ +--> AWB-1
+
+By default all statistics are drawn from the 0th tap point for each algorithm;
+I.E. AEXP statistics from AEXP-0 (A), AWB statistics from AWB-0 and AF
+statistics from AF-0. This is configurable for AEXP and AWB statsistics through
+programming the ISP's parameters.
+
+.. _mali-c55-3a-params:
+
+Programming ISP Parameters
+==========================
+
+The ISP can be programmed with various parameters from userspace to apply to the
+hardware before and during video stream. This allows userspace to dynamically
+change values such as black level, white balance and lens shading gains and so
+on.
+
+The buffer format and how to populate it are described by the
+:ref:`V4L2_META_FMT_MALI_C55_PARAMS <v4l2-meta-fmt-mali-c55-params>` format,
+which should be set as the data format for the `mali-c55 3a params` video node.
+
+References
+==========
+.. [1] https://git.linuxtv.org/v4l-utils.git/
+.. [2] https://git.ideasonboard.org/yavta.git
+.. [3] https://developer.arm.com/Processors/Mali-C55
diff --git a/Documentation/admin-guide/media/meye.rst b/Documentation/admin-guide/media/meye.rst
deleted file mode 100644
index 9098a1e65f8b..000000000000
--- a/Documentation/admin-guide/media/meye.rst
+++ /dev/null
@@ -1,93 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. include:: <isonum.txt>
-
-Vaio Picturebook Motion Eye Camera Driver
-=========================================
-
-Copyright |copy| 2001-2004 Stelian Pop <stelian@popies.net>
-
-Copyright |copy| 2001-2002 Alcôve <www.alcove.com>
-
-Copyright |copy| 2000 Andrew Tridgell <tridge@samba.org>
-
-This driver enable the use of video4linux compatible applications with the
-Motion Eye camera. This driver requires the "Sony Laptop Extras" driver (which
-can be found in the "Misc devices" section of the kernel configuration utility)
-to be compiled and installed (using its "camera=1" parameter).
-
-It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
-
-Grabbing is supported in packed YUV colorspace only.
-
-MJPEG hardware grabbing is supported via a private API (see below).
-
-Hardware supported
-------------------
-
-This driver supports the 'second' version of the MotionEye camera :)
-
-The first version was connected directly on the video bus of the Neomagic
-video card and is unsupported.
-
-The second one, made by Kawasaki Steel is fully supported by this
-driver (PCI vendor/device is 0x136b/0xff01)
-
-The third one, present in recent (more or less last year) Picturebooks
-(C1M* models), is not supported. The manufacturer has given the specs
-to the developers under a NDA (which allows the development of a GPL
-driver however), but things are not moving very fast (see
-http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
-
-There is a forth model connected on the USB bus in TR1* Vaio laptops.
-This camera is not supported at all by the current driver, in fact
-little information if any is available for this camera
-(USB vendor/device is 0x054c/0x0107).
-
-Driver options
---------------
-
-Several options can be passed to the meye driver using the standard
-module argument syntax (<param>=<value> when passing the option to the
-module or meye.<param>=<value> on the kernel boot line when meye is
-statically linked into the kernel). Those options are:
-
-.. code-block:: none
-
- gbuffers: number of capture buffers, default is 2 (32 max)
-
- gbufsize: size of each capture buffer, default is 614400
-
- video_nr: video device to register (0 = /dev/video0, etc)
-
-Module use
-----------
-
-In order to automatically load the meye module on use, you can put those lines
-in your /etc/modprobe.d/meye.conf file:
-
-.. code-block:: none
-
- alias char-major-81 videodev
- alias char-major-81-0 meye
- options meye gbuffers=32
-
-Usage:
-------
-
-.. code-block:: none
-
- xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
- for display and uncompressed video capture:
-
- xawtv -c /dev/video0 -geometry 640x480
- or
- xawtv -c /dev/video0 -geometry 320x240
-
- motioneye (<http://popies.net/meye/>)
- for getting ppm or jpg snapshots, mjpeg video
-
-Bugs / Todo
------------
-
-- 'motioneye' still uses the meye private v4l1 API extensions.
diff --git a/Documentation/admin-guide/media/mgb4.rst b/Documentation/admin-guide/media/mgb4.rst
new file mode 100644
index 000000000000..5ac69b833a7a
--- /dev/null
+++ b/Documentation/admin-guide/media/mgb4.rst
@@ -0,0 +1,385 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+The mgb4 driver
+===============
+
+Copyright |copy| 2023 - 2025 Digiteq Automotive
+ author: Martin Tůma <martin.tuma@digiteqautomotive.com>
+
+This is a v4l2 device driver for the Digiteq Automotive FrameGrabber 4, a PCIe
+card capable of capturing and generating FPD-Link III and GMSL2/3 video streams
+as used in the automotive industry.
+
+sysfs interface
+---------------
+
+The mgb4 driver provides a sysfs interface, that is used to configure video
+stream related parameters (some of them must be set properly before the v4l2
+device can be opened) and obtain the video device/stream status.
+
+There are two types of parameters - global / PCI card related, found under
+``/sys/class/video4linux/videoX/device`` and module specific found under
+``/sys/class/video4linux/videoX``.
+
+Global (PCI card) parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**module_type** (R):
+ Module type.
+
+ | 0 - No module present
+ | 1 - FPDL3
+ | 2 - GMSL (one serializer, two daisy chained deserializers)
+ | 3 - GMSL (one serializer, two deserializers)
+ | 4 - GMSL (two deserializers with two daisy chain outputs)
+
+**module_version** (R):
+ Module version number. Zero in case of a missing module.
+
+**fw_type** (R):
+ Firmware type.
+
+ | 1 - FPDL3
+ | 2 - GMSL
+
+**fw_version** (R):
+ Firmware version number.
+
+**serial_number** (R):
+ Card serial number. The format is::
+
+ PRODUCT-REVISION-SERIES-SERIAL
+
+ where each component is a 8b number.
+
+Common FPDL3/GMSL input parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**input_id** (R):
+ Input number ID, zero based.
+
+**oldi_lane_width** (RW):
+ Number of deserializer output lanes.
+
+ | 0 - single
+ | 1 - dual (default)
+
+**color_mapping** (RW):
+ Mapping of the incoming bits in the signal to the colour bits of the pixels.
+
+ | 0 - OLDI/JEIDA
+ | 1 - SPWG/VESA (default)
+
+**link_status** (R):
+ Video link status. If the link is locked, chips are properly connected and
+ communicating at the same speed and protocol. The link can be locked without
+ an active video stream.
+
+ A value of 0 is equivalent to the V4L2_IN_ST_NO_SYNC flag of the V4L2
+ VIDIOC_ENUMINPUT status bits.
+
+ | 0 - unlocked
+ | 1 - locked
+
+**stream_status** (R):
+ Video stream status. A stream is detected if the link is locked, the input
+ pixel clock is running and the DE signal is moving.
+
+ A value of 0 is equivalent to the V4L2_IN_ST_NO_SIGNAL flag of the V4L2
+ VIDIOC_ENUMINPUT status bits.
+
+ | 0 - not detected
+ | 1 - detected
+
+**video_width** (R):
+ Video stream width. This is the actual width as detected by the HW.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the width
+ field of the v4l2_bt_timings struct.
+
+**video_height** (R):
+ Video stream height. This is the actual height as detected by the HW.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the height
+ field of the v4l2_bt_timings struct.
+
+**vsync_status** (R):
+ The type of VSYNC pulses as detected by the video format detector.
+
+ The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
+ the polarities field of the v4l2_bt_timings struct.
+
+ | 0 - active low
+ | 1 - active high
+ | 2 - not available
+
+**hsync_status** (R):
+ The type of HSYNC pulses as detected by the video format detector.
+
+ The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
+ the polarities field of the v4l2_bt_timings struct.
+
+ | 0 - active low
+ | 1 - active high
+ | 2 - not available
+
+**vsync_gap_length** (RW):
+ If the incoming video signal does not contain synchronization VSYNC and
+ HSYNC pulses, these must be generated internally in the FPGA to achieve
+ the correct frame ordering. This value indicates, how many "empty" pixels
+ (pixels with deasserted Data Enable signal) are necessary to generate the
+ internal VSYNC pulse.
+
+**hsync_gap_length** (RW):
+ If the incoming video signal does not contain synchronization VSYNC and
+ HSYNC pulses, these must be generated internally in the FPGA to achieve
+ the correct frame ordering. This value indicates, how many "empty" pixels
+ (pixels with deasserted Data Enable signal) are necessary to generate the
+ internal HSYNC pulse. The value must be greater than 1 and smaller than
+ vsync_gap_length.
+
+**pclk_frequency** (R):
+ Input pixel clock frequency in kHz.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the pixelclock field of the v4l2_bt_timings struct.
+
+ *Note: The frequency_range parameter must be set properly first to get
+ a valid frequency here.*
+
+**hsync_width** (R):
+ Width of the HSYNC signal in PCLK clock ticks.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the hsync field of the v4l2_bt_timings struct.
+
+**vsync_width** (R):
+ Width of the VSYNC signal in PCLK clock ticks.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the vsync field of the v4l2_bt_timings struct.
+
+**hback_porch** (R):
+ Number of PCLK pulses between deassertion of the HSYNC signal and the first
+ valid pixel in the video line (marked by DE=1).
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the hbackporch field of the v4l2_bt_timings struct.
+
+**hfront_porch** (R):
+ Number of PCLK pulses between the end of the last valid pixel in the video
+ line (marked by DE=1) and assertion of the HSYNC signal.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the hfrontporch field of the v4l2_bt_timings struct.
+
+**vback_porch** (R):
+ Number of video lines between deassertion of the VSYNC signal and the video
+ line with the first valid pixel (marked by DE=1).
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the vbackporch field of the v4l2_bt_timings struct.
+
+**vfront_porch** (R):
+ Number of video lines between the end of the last valid pixel line (marked
+ by DE=1) and assertion of the VSYNC signal.
+
+ The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
+ the vfrontporch field of the v4l2_bt_timings struct.
+
+**frequency_range** (RW)
+ PLL frequency range of the OLDI input clock generator. The PLL frequency is
+ derived from the Pixel Clock Frequency (PCLK) and is equal to PCLK if
+ oldi_lane_width is set to "single" and PCLK/2 if oldi_lane_width is set to
+ "dual".
+
+ | 0 - PLL < 50MHz (default)
+ | 1 - PLL >= 50MHz
+
+ *Note: This parameter can not be changed while the input v4l2 device is
+ open.*
+
+Common FPDL3/GMSL output parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**output_id** (R):
+ Output number ID, zero based.
+
+**video_source** (RW):
+ Output video source. If set to 0 or 1, the source is the corresponding card
+ input and the v4l2 output devices are disabled. If set to 2 or 3, the source
+ is the corresponding v4l2 video output device. The default is
+ the corresponding v4l2 output, i.e. 2 for OUT1 and 3 for OUT2.
+
+ | 0 - input 0
+ | 1 - input 1
+ | 2 - v4l2 output 0
+ | 3 - v4l2 output 1
+
+ *Note: This parameter can not be changed while ANY of the input/output v4l2
+ devices is open.*
+
+**display_width** (RW):
+ Display width. There is no autodetection of the connected display, so the
+ proper value must be set before the start of streaming. The default width
+ is 1280.
+
+ *Note: This parameter can not be changed while the output v4l2 device is
+ open.*
+
+**display_height** (RW):
+ Display height. There is no autodetection of the connected display, so the
+ proper value must be set before the start of streaming. The default height
+ is 640.
+
+ *Note: This parameter can not be changed while the output v4l2 device is
+ open.*
+
+**frame_rate** (RW):
+ Output video signal frame rate limit in frames per second. Due to
+ the limited output pixel clock steps, the card can not always generate
+ a frame rate perfectly matching the value required by the connected display.
+ Using this parameter one can limit the frame rate by "crippling" the signal
+ so that the lines are not equal (the porches of the last line differ) but
+ the signal appears like having the exact frame rate to the connected display.
+ The default frame rate limit is 60Hz.
+
+**hsync_polarity** (RW):
+ HSYNC signal polarity.
+
+ | 0 - active low (default)
+ | 1 - active high
+
+**vsync_polarity** (RW):
+ VSYNC signal polarity.
+
+ | 0 - active low (default)
+ | 1 - active high
+
+**de_polarity** (RW):
+ DE signal polarity.
+
+ | 0 - active low
+ | 1 - active high (default)
+
+**pclk_frequency** (RW):
+ Output pixel clock frequency. Allowed values are between 25000-190000(kHz)
+ and there is a non-linear stepping between two consecutive allowed
+ frequencies. The driver finds the nearest allowed frequency to the given
+ value and sets it. When reading this property, you get the exact
+ frequency set by the driver. The default frequency is 61150kHz.
+
+ *Note: This parameter can not be changed while the output v4l2 device is
+ open.*
+
+**hsync_width** (RW):
+ Width of the HSYNC signal in pixels. The default value is 40.
+
+**vsync_width** (RW):
+ Width of the VSYNC signal in video lines. The default value is 20.
+
+**hback_porch** (RW):
+ Number of PCLK pulses between deassertion of the HSYNC signal and the first
+ valid pixel in the video line (marked by DE=1). The default value is 50.
+
+**hfront_porch** (RW):
+ Number of PCLK pulses between the end of the last valid pixel in the video
+ line (marked by DE=1) and assertion of the HSYNC signal. The default value
+ is 50.
+
+**vback_porch** (RW):
+ Number of video lines between deassertion of the VSYNC signal and the video
+ line with the first valid pixel (marked by DE=1). The default value is 31.
+
+**vfront_porch** (RW):
+ Number of video lines between the end of the last valid pixel line (marked
+ by DE=1) and assertion of the VSYNC signal. The default value is 30.
+
+FPDL3 specific input parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**fpdl3_input_width** (RW):
+ Number of deserializer input lines.
+
+ | 0 - auto (default)
+ | 1 - single
+ | 2 - dual
+
+FPDL3 specific output parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**fpdl3_output_width** (RW):
+ Number of serializer output lines.
+
+ | 0 - auto (default)
+ | 1 - single
+ | 2 - dual
+
+GMSL specific input parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**gmsl_mode** (RW):
+ GMSL speed mode.
+
+ | 0 - 12Gb/s (default)
+ | 1 - 6Gb/s
+ | 2 - 3Gb/s
+ | 3 - 1.5Gb/s
+
+**gmsl_stream_id** (RW):
+ The GMSL multi-stream contains up to four video streams. This parameter
+ selects which stream is captured by the video input. The value is the
+ zero-based index of the stream. The default stream id is 0.
+
+ *Note: This parameter can not be changed while the input v4l2 device is
+ open.*
+
+**gmsl_fec** (RW):
+ GMSL Forward Error Correction (FEC).
+
+ | 0 - disabled
+ | 1 - enabled (default)
+
+MTD partitions
+--------------
+
+The mgb4 driver creates a MTD device with two partitions:
+ - mgb4-fw.X - FPGA firmware.
+ - mgb4-data.X - Factory settings, e.g. card serial number.
+
+The *mgb4-fw* partition is writable and is used for FW updates, *mgb4-data* is
+read-only. The *X* attached to the partition name represents the card number.
+Depending on the CONFIG_MTD_PARTITIONED_MASTER kernel configuration, you may
+also have a third partition named *mgb4-flash* available in the system. This
+partition represents the whole, unpartitioned, card's FLASH memory and one should
+not fiddle with it...
+
+IIO (triggers)
+--------------
+
+The mgb4 driver creates an Industrial I/O (IIO) device that provides trigger and
+signal level status capability. The following scan elements are available:
+
+**activity**:
+ The trigger levels and pending status.
+
+ | bit 1 - trigger 1 pending
+ | bit 2 - trigger 2 pending
+ | bit 5 - trigger 1 level
+ | bit 6 - trigger 2 level
+
+**timestamp**:
+ The trigger event timestamp.
+
+The iio device can operate either in "raw" mode where you can fetch the signal
+levels (activity bits 5 and 6) using sysfs access or in triggered buffer mode.
+In the triggered buffer mode you can follow the signal level changes (activity
+bits 1 and 2) using the iio device in /dev. If you enable the timestamps, you
+will also get the exact trigger event time that can be matched to a video frame
+(every mgb4 video frame has a timestamp with the same clock source).
+
+*Note: although the activity sample always contains all the status bits, it makes
+no sense to get the pending bits in raw mode or the level bits in the triggered
+buffer mode - the values do not represent valid data in such case.*
diff --git a/Documentation/admin-guide/media/omap4_camera.rst b/Documentation/admin-guide/media/omap4_camera.rst
deleted file mode 100644
index 2ada9b1e6897..000000000000
--- a/Documentation/admin-guide/media/omap4_camera.rst
+++ /dev/null
@@ -1,62 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-OMAP4 ISS Driver
-================
-
-Author: Sergio Aguirre <sergio.a.aguirre@gmail.com>
-
-Copyright (C) 2012, Texas Instruments
-
-Introduction
-------------
-
-The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS),
-Which contains several components that can be categorized in 3 big groups:
-
-- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2)
-- ISP (Image Signal Processor)
-- SIMCOP (Still Image Coprocessor)
-
-For more information, please look in [#f1]_ for latest version of:
-"OMAP4430 Multimedia Device Silicon Revision 2.x"
-
-As of Revision AB, the ISS is described in detail in section 8.
-
-This driver is supporting **only** the CSI2-A/B interfaces for now.
-
-It makes use of the Media Controller framework [#f2]_, and inherited most of the
-code from OMAP3 ISP driver (found under drivers/media/platform/ti/omap3isp/\*),
-except that it doesn't need an IOMMU now for ISS buffers memory mapping.
-
-Supports usage of MMAP buffers only (for now).
-
-Tested platforms
-----------------
-
-- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in
- which only the last one is supported, outputting YUV422 frames).
-
-- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in
- which only the OV5650 are supported, outputting RAW10 frames).
-
-- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with
- following sensors:
- * OV5640
- * OV5650
-
-- Tested on mainline kernel:
-
- http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
-
- Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7)
-
-File list
----------
-drivers/staging/media/omap4iss/
-include/linux/platform_data/media/omap4iss.h
-
-References
-----------
-
-.. [#f1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62
-.. [#f2] http://lwn.net/Articles/420485/
diff --git a/Documentation/admin-guide/media/other-usb-cardlist.rst b/Documentation/admin-guide/media/other-usb-cardlist.rst
index bbfdb1389c18..fb88db50e861 100644
--- a/Documentation/admin-guide/media/other-usb-cardlist.rst
+++ b/Documentation/admin-guide/media/other-usb-cardlist.rst
@@ -14,8 +14,6 @@ dvb-as102 nBox DVB-T Dongle 0b89:0007
dvb-as102 Sky IT Digital Key (green led) 2137:0001
b2c2-flexcop-usb Technisat/B2C2 FlexCop II/IIb/III 0af7:0101
Digital TV
-cpia2 Vision's CPiA2 cameras 0553:0100, 0553:0140,
- such as the Digital Blue QX5 0553:0151
go7007 WIS GO7007 MPEG encoder 1943:a250, 093b:a002,
093b:a004, 0eb1:6666,
0eb1:6668
@@ -66,7 +64,6 @@ pwc Visionite VCS-UC300 0d81:1900
pwc Visionite VCS-UM100 0d81:1910
s2255drv Sensoray 2255 1943:2255, 1943:2257
stk1160 STK1160 USB video capture dongle 05e1:0408
-stkwebcam Syntek DC1125 174f:a311, 05e1:0501
dvb-ttusb-budget Technotrend/Hauppauge Nova-USB devices 0b48:1003, 0b48:1004,
0b48:1005
dvb-ttusb_dec Technotrend/Hauppauge MPEG decoder 0b48:1006
@@ -78,15 +75,4 @@ dvb-ttusb_dec Technotrend/Hauppauge MPEG decoder
DEC2540-t 0b48:1009
usbtv Fushicai USBTV007 Audio-Video Grabber 1b71:3002, 1f71:3301,
1f71:3306
-zr364xx USB ZR364XX Camera 08ca:0109, 041e:4024,
- 0d64:0108, 0546:3187,
- 0d64:3108, 0595:4343,
- 0bb0:500d, 0feb:2004,
- 055f:b500, 08ca:2062,
- 052b:1a18, 04c8:0729,
- 04f2:a208, 0784:0040,
- 06d6:0034, 0a17:0062,
- 06d6:003b, 0a17:004e,
- 041e:405d, 08ca:2102,
- 06d6:003d
================ ====================================== =====================
diff --git a/Documentation/admin-guide/media/pci-cardlist.rst b/Documentation/admin-guide/media/pci-cardlist.rst
index f4d670e632f8..239879634ea5 100644
--- a/Documentation/admin-guide/media/pci-cardlist.rst
+++ b/Documentation/admin-guide/media/pci-cardlist.rst
@@ -77,7 +77,7 @@ ipu3-cio2 Intel ipu3-cio2 driver
ivtv Conexant cx23416/cx23415 MPEG encoder/decoder
ivtvfb Conexant cx23415 framebuffer
mantis MANTIS based cards
-meye Sony Vaio Picturebook Motion Eye
+mgb4 Digiteq Automotive MGB4 frame grabber
mxb Siemens-Nixdorf 'Multimedia eXtension Board'
netup-unidvb NetUP Universal DVB card
ngene Micronas nGene
@@ -86,7 +86,6 @@ saa7134 Philips SAA7134
saa7164 NXP SAA7164
smipcie SMI PCIe DVBSky cards
solo6x10 Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)
-sta2x11_vip STA2X11 VIP Video For Linux
tw5864 Techwell TW5864 video/audio grabber and encoder
tw686x Intersil/Techwell TW686x
tw68 Techwell tw68x Video For Linux
diff --git a/Documentation/admin-guide/media/platform-cardlist.rst b/Documentation/admin-guide/media/platform-cardlist.rst
index ac73c4166d1e..63f4b19c3628 100644
--- a/Documentation/admin-guide/media/platform-cardlist.rst
+++ b/Documentation/admin-guide/media/platform-cardlist.rst
@@ -18,8 +18,6 @@ am437x-vpfe TI AM437x VPFE
aspeed-video Aspeed AST2400 and AST2500
atmel-isc ATMEL Image Sensor Controller (ISC)
atmel-isi ATMEL Image Sensor Interface (ISI)
-c8sectpfe SDR platform devices
-c8sectpfe SDR platform devices
cafe_ccic Marvell 88ALP01 (Cafe) CMOS Camera Controller
cdns-csi2rx Cadence MIPI-CSI2 RX Controller
cdns-csi2tx Cadence MIPI-CSI2 TX Controller
@@ -30,7 +28,6 @@ exynos-fimc-is EXYNOS4x12 FIMC-IS (Imaging Subsystem)
exynos-fimc-lite EXYNOS FIMC-LITE camera interface
exynos-gsc Samsung Exynos G-Scaler
exy Samsung S5P/EXYNOS4 SoC series Camera Subsystem
-fsl-viu Freescale VIU
imx-pxp i.MX Pixel Pipeline (PXP)
isdf TI DM365 ISIF video capture
mmp_camera Marvell Armada 610 integrated camera controller
@@ -73,7 +70,6 @@ via-camera VIAFB camera controller
video-mux Video Multiplexer
vpif_display TI DaVinci VPIF V4L2-Display
vpif_capture TI DaVinci VPIF video capture
-vpss TI DaVinci VPBE V4L2-Display
vsp1 Renesas VSP1 Video Processing Engine
xilinx-tpg Xilinx Video Test Pattern Generator
xilinx-video Xilinx Video IP (EXPERIMENTAL)
diff --git a/Documentation/admin-guide/media/pulse8-cec.rst b/Documentation/admin-guide/media/pulse8-cec.rst
deleted file mode 100644
index 356d08b519f3..000000000000
--- a/Documentation/admin-guide/media/pulse8-cec.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-Pulse-Eight CEC Adapter driver
-==============================
-
-The pulse8-cec driver implements the following module option:
-
-``persistent_config``
----------------------
-
-By default this is off, but when set to 1 the driver will store the current
-settings to the device's internal eeprom and restore it the next time the
-device is connected to the USB port.
diff --git a/Documentation/admin-guide/media/qcom_camss.rst b/Documentation/admin-guide/media/qcom_camss.rst
index a72e17d09cb7..8a8f3ff40105 100644
--- a/Documentation/admin-guide/media/qcom_camss.rst
+++ b/Documentation/admin-guide/media/qcom_camss.rst
@@ -18,7 +18,7 @@ The driver implements V4L2, Media controller and V4L2 subdev interfaces.
Camera sensor using V4L2 subdev interface in the kernel is supported.
The driver is implemented using as a reference the Qualcomm Camera Subsystem
-driver for Android as found in Code Aurora [#f1]_ [#f2]_.
+driver for Android as found in Code Linaro [#f1]_ [#f2]_.
Qualcomm Camera Subsystem hardware
@@ -181,5 +181,5 @@ Referenced 2018-06-22.
References
----------
-.. [#f1] https://source.codeaurora.org/quic/la/kernel/msm-3.10/
-.. [#f2] https://source.codeaurora.org/quic/la/kernel/msm-3.18/
+.. [#f1] https://git.codelinaro.org/clo/la/kernel/msm-3.10/
+.. [#f2] https://git.codelinaro.org/clo/la/kernel/msm-3.18/
diff --git a/Documentation/admin-guide/media/radio-cardlist.rst b/Documentation/admin-guide/media/radio-cardlist.rst
index a82a146bf912..cec724256812 100644
--- a/Documentation/admin-guide/media/radio-cardlist.rst
+++ b/Documentation/admin-guide/media/radio-cardlist.rst
@@ -30,7 +30,6 @@ radio-terratec TerraTec ActiveRadio ISA Standalone
radio-timb Enable the Timberdale radio driver
radio-trust Trust FM radio card
radio-typhoon Typhoon Radio (a.k.a. EcoRadio)
-radio-wl1273 Texas Instruments WL1273 I2C FM Radio
fm_drv ISA radio devices
fm_drv ISA radio devices
radio-zoltrix Zoltrix Radio
diff --git a/Documentation/admin-guide/media/raspberrypi-pisp-be.dot b/Documentation/admin-guide/media/raspberrypi-pisp-be.dot
new file mode 100644
index 000000000000..55671dc1d443
--- /dev/null
+++ b/Documentation/admin-guide/media/raspberrypi-pisp-be.dot
@@ -0,0 +1,20 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{<port0> 0 | <port1> 1 | <port2> 2 | <port7> 7} | pispbe\n | {<port3> 3 | <port4> 4 | <port5> 5 | <port6> 6}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port3 -> n0000001c [style=bold]
+ n00000001:port4 -> n00000022 [style=bold]
+ n00000001:port5 -> n00000028 [style=bold]
+ n00000001:port6 -> n0000002e [style=bold]
+ n0000000a [label="pispbe-input\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n0000000a -> n00000001:port0 [style=bold]
+ n00000010 [label="pispbe-tdn_input\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n00000010 -> n00000001:port1 [style=bold]
+ n00000016 [label="pispbe-stitch_input\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
+ n00000016 -> n00000001:port2 [style=bold]
+ n0000001c [label="pispbe-output0\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
+ n00000022 [label="pispbe-output1\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
+ n00000028 [label="pispbe-tdn_output\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
+ n0000002e [label="pispbe-stitch_output\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
+ n00000034 [label="pispbe-config\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
+ n00000034 -> n00000001:port7 [style=bold]
+}
diff --git a/Documentation/admin-guide/media/raspberrypi-pisp-be.rst b/Documentation/admin-guide/media/raspberrypi-pisp-be.rst
new file mode 100644
index 000000000000..0fcf46f26276
--- /dev/null
+++ b/Documentation/admin-guide/media/raspberrypi-pisp-be.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================================
+Raspberry Pi PiSP Back End Memory-to-Memory ISP (pisp-be)
+=========================================================
+
+The PiSP Back End
+=================
+
+The PiSP Back End is a memory-to-memory Image Signal Processor (ISP) which reads
+image data from DRAM memory and performs image processing as specified by the
+application through the parameters in a configuration buffer, before writing
+pixel data back to memory through two distinct output channels.
+
+The ISP registers and programming model are documented in the `Raspberry Pi
+Image Signal Processor (PiSP) Specification document`_
+
+The PiSP Back End ISP processes images in tiles. The handling of image
+tessellation and the computation of low-level configuration parameters is
+realized by a free software library called `libpisp
+<https://github.com/raspberrypi/libpisp>`_.
+
+The full image processing pipeline, which involves capturing RAW Bayer data from
+an image sensor through a MIPI CSI-2 compatible capture interface, storing them
+in DRAM memory and processing them in the PiSP Back End to obtain images usable
+by an application is implemented in `libcamera <https://libcamera.org>`_ as
+part of the Raspberry Pi platform support.
+
+The pisp-be driver
+==================
+
+The Raspberry Pi PiSP Back End (pisp-be) driver is located under
+drivers/media/platform/raspberrypi/pisp-be. It uses the `V4L2 API` to register
+a number of video capture and output devices, the `V4L2 subdev API` to register
+a subdevice for the ISP that connects the video devices in a single media graph
+realized using the `Media Controller (MC) API`.
+
+The media topology registered by the `pisp-be` driver is represented below:
+
+.. _pips-be-topology:
+
+.. kernel-figure:: raspberrypi-pisp-be.dot
+ :alt: Diagram of the default media pipeline topology
+ :align: center
+
+
+The media graph registers the following video device nodes:
+
+- pispbe-input: output device for images to be submitted to the ISP for
+ processing.
+- pispbe-tdn_input: output device for temporal denoise.
+- pispbe-stitch_input: output device for image stitching (HDR).
+- pispbe-output0: first capture device for processed images.
+- pispbe-output1: second capture device for processed images.
+- pispbe-tdn_output: capture device for temporal denoise.
+- pispbe-stitch_output: capture device for image stitching (HDR).
+- pispbe-config: output device for ISP configuration parameters.
+
+pispbe-input
+------------
+
+Images to be processed by the ISP are queued to the `pispbe-input` output device
+node. For a list of image formats supported as input to the ISP refer to the
+`Raspberry Pi Image Signal Processor (PiSP) Specification document`_.
+
+pispbe-tdn_input, pispbe-tdn_output
+-----------------------------------
+
+The `pispbe-tdn_input` output video device receives images to be processed by
+the temporal denoise block which are captured from the `pispbe-tdn_output`
+capture video device. Userspace is responsible for maintaining queues on both
+devices, and ensuring that buffers completed on the output are queued to the
+input.
+
+pispbe-stitch_input, pispbe-stitch_output
+-----------------------------------------
+
+To realize HDR (high dynamic range) image processing the image stitching and
+tonemapping blocks are used. The `pispbe-stitch_output` writes images to memory
+and the `pispbe-stitch_input` receives the previously written frame to process
+it along with the current input image. Userspace is responsible for maintaining
+queues on both devices, and ensuring that buffers completed on the output are
+queued to the input.
+
+pispbe-output0, pispbe-output1
+------------------------------
+
+The two capture devices write to memory the pixel data as processed by the ISP.
+
+pispbe-config
+-------------
+
+The `pispbe-config` output video devices receives a buffer of configuration
+parameters that define the desired image processing to be performed by the ISP.
+
+The format of the ISP configuration parameter is defined by
+:c:type:`pisp_be_tiles_config` C structure and the meaning of each parameter is
+described in the `Raspberry Pi Image Signal Processor (PiSP) Specification
+document`_.
+
+ISP configuration
+=================
+
+The ISP configuration is described solely by the content of the parameters
+buffer. The only parameter that userspace needs to configure using the V4L2 API
+is the image format on the output and capture video devices for validation of
+the content of the parameters buffer.
+
+.. _Raspberry Pi Image Signal Processor (PiSP) Specification document: https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
diff --git a/Documentation/admin-guide/media/raspberrypi-rp1-cfe.dot b/Documentation/admin-guide/media/raspberrypi-rp1-cfe.dot
new file mode 100644
index 000000000000..7717f2291049
--- /dev/null
+++ b/Documentation/admin-guide/media/raspberrypi-rp1-cfe.dot
@@ -0,0 +1,27 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{<port0> 0} | csi2\n/dev/v4l-subdev0 | {<port1> 1 | <port2> 2 | <port3> 3 | <port4> 4}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port1 -> n00000011 [style=dashed]
+ n00000001:port1 -> n00000007:port0
+ n00000001:port2 -> n00000015
+ n00000001:port2 -> n00000007:port0 [style=dashed]
+ n00000001:port3 -> n00000019 [style=dashed]
+ n00000001:port3 -> n00000007:port0 [style=dashed]
+ n00000001:port4 -> n0000001d [style=dashed]
+ n00000001:port4 -> n00000007:port0 [style=dashed]
+ n00000007 [label="{{<port0> 0 | <port1> 1} | pisp-fe\n/dev/v4l-subdev1 | {<port2> 2 | <port3> 3 | <port4> 4}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000007:port2 -> n00000021
+ n00000007:port3 -> n00000025 [style=dashed]
+ n00000007:port4 -> n00000029
+ n0000000d [label="{imx219 6-0010\n/dev/v4l-subdev2 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000000d:port0 -> n00000001:port0 [style=bold]
+ n00000011 [label="rp1-cfe-csi2-ch0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n00000015 [label="rp1-cfe-csi2-ch1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n00000019 [label="rp1-cfe-csi2-ch2\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
+ n0000001d [label="rp1-cfe-csi2-ch3\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
+ n00000021 [label="rp1-cfe-fe-image0\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
+ n00000025 [label="rp1-cfe-fe-image1\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
+ n00000029 [label="rp1-cfe-fe-stats\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
+ n0000002d [label="rp1-cfe-fe-config\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
+ n0000002d -> n00000007:port1
+}
diff --git a/Documentation/admin-guide/media/raspberrypi-rp1-cfe.rst b/Documentation/admin-guide/media/raspberrypi-rp1-cfe.rst
new file mode 100644
index 000000000000..668d978a9875
--- /dev/null
+++ b/Documentation/admin-guide/media/raspberrypi-rp1-cfe.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================================
+Raspberry Pi PiSP Camera Front End (rp1-cfe)
+============================================
+
+The PiSP Camera Front End
+=========================
+
+The PiSP Camera Front End (CFE) is a module which combines a CSI-2 receiver with
+a simple ISP, called the Front End (FE).
+
+The CFE has four DMA engines and can write frames from four separate streams
+received from the CSI-2 to the memory. One of those streams can also be routed
+directly to the FE, which can do minimal image processing, write two versions
+(e.g. non-scaled and downscaled versions) of the received frames to memory and
+provide statistics of the received frames.
+
+The FE registers are documented in the `Raspberry Pi Image Signal Processor
+(ISP) Specification document
+<https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf>`_,
+and example code for FE can be found in `libpisp
+<https://github.com/raspberrypi/libpisp>`_.
+
+The rp1-cfe driver
+==================
+
+The Raspberry Pi PiSP Camera Front End (rp1-cfe) driver is located under
+drivers/media/platform/raspberrypi/rp1-cfe. It uses the `V4L2 API` to register
+a number of video capture and output devices, the `V4L2 subdev API` to register
+subdevices for the CSI-2 received and the FE that connects the video devices in
+a single media graph realized using the `Media Controller (MC) API`.
+
+The media topology registered by the `rp1-cfe` driver, in this particular
+example connected to an imx219 sensor, is the following one:
+
+.. _rp1-cfe-topology:
+
+.. kernel-figure:: raspberrypi-rp1-cfe.dot
+ :alt: Diagram of an example media pipeline topology
+ :align: center
+
+The media graph contains the following video device nodes:
+
+- rp1-cfe-csi2-ch0: capture device for the first CSI-2 stream
+- rp1-cfe-csi2-ch1: capture device for the second CSI-2 stream
+- rp1-cfe-csi2-ch2: capture device for the third CSI-2 stream
+- rp1-cfe-csi2-ch3: capture device for the fourth CSI-2 stream
+- rp1-cfe-fe-image0: capture device for the first FE output
+- rp1-cfe-fe-image1: capture device for the second FE output
+- rp1-cfe-fe-stats: capture device for the FE statistics
+- rp1-cfe-fe-config: output device for FE configuration
+
+rp1-cfe-csi2-chX
+----------------
+
+The rp1-cfe-csi2-chX capture devices are normal V4L2 capture devices which
+can be used to capture video frames or metadata received from the CSI-2.
+
+rp1-cfe-fe-image0, rp1-cfe-fe-image1
+------------------------------------
+
+The rp1-cfe-fe-image0 and rp1-cfe-fe-image1 capture devices are used to write
+the processed frames to memory.
+
+rp1-cfe-fe-stats
+----------------
+
+The format of the FE statistics buffer is defined by
+:c:type:`pisp_statistics` C structure and the meaning of each parameter is
+described in the `PiSP specification` document.
+
+rp1-cfe-fe-config
+-----------------
+
+The format of the FE configuration buffer is defined by
+:c:type:`pisp_fe_config` C structure and the meaning of each parameter is
+described in the `PiSP specification` document.
diff --git a/Documentation/admin-guide/media/rkcif-rk3568-vicap.dot b/Documentation/admin-guide/media/rkcif-rk3568-vicap.dot
new file mode 100644
index 000000000000..3fac59335459
--- /dev/null
+++ b/Documentation/admin-guide/media/rkcif-rk3568-vicap.dot
@@ -0,0 +1,8 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{<port0> 0} | rkcif-dvp0\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port1 -> n00000004
+ n00000004 [label="rkcif-dvp0-id0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n00000025 [label="{{} | it6801 2-0048\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000025:port0 -> n00000001:port0
+}
diff --git a/Documentation/admin-guide/media/rkcif.rst b/Documentation/admin-guide/media/rkcif.rst
new file mode 100644
index 000000000000..2558c121abc4
--- /dev/null
+++ b/Documentation/admin-guide/media/rkcif.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Rockchip Camera Interface (CIF)
+=========================================
+
+Introduction
+============
+
+The Rockchip Camera Interface (CIF) is featured in many Rockchip SoCs in
+different variants.
+The different variants are combinations of common building blocks, such as
+
+* INTERFACE blocks of different types, namely
+
+ * the Digital Video Port (DVP, a parallel data interface)
+ * the interface block for the MIPI CSI-2 receiver
+
+* CROP units
+
+* MIPI CSI-2 receiver (not available on all variants): This unit is referred
+ to as MIPI CSI HOST in the Rockchip documentation.
+ Technically, it is a separate hardware block, but it is strongly coupled to
+ the CIF and therefore included here.
+
+* MUX units (not available on all variants) that pass the video data to an
+ image signal processor (ISP)
+
+* SCALE units (not available on all variants)
+
+* DMA engines that transfer video data into system memory using a
+ double-buffering mechanism called ping-pong mode
+
+* Support for four streams per INTERFACE block (not available on all
+ variants), e.g., for MIPI CSI-2 Virtual Channels (VCs)
+
+This document describes the different variants of the CIF, their hardware
+layout, as well as their representation in the media controller centric rkcif
+device driver, which is located under drivers/media/platform/rockchip/rkcif.
+
+Variants
+========
+
+Rockchip PX30 Video Input Processor (VIP)
+-----------------------------------------
+
+The PX30 Video Input Processor (VIP) features a digital video port that accepts
+parallel video data or BT.656.
+Since these protocols do not feature multiple streams, the VIP has one DMA
+engine that transfers the input video data into system memory.
+
+The rkcif driver represents this hardware variant by exposing one V4L2 subdevice
+(the DVP INTERFACE/CROP block) and one V4L2 device (the DVP DMA engine).
+
+Rockchip RK3568 Video Capture (VICAP)
+-------------------------------------
+
+The RK3568 Video Capture (VICAP) unit features a digital video port and a MIPI
+CSI-2 receiver that can receive video data independently.
+The DVP accepts parallel video data, BT.656 and BT.1120.
+Since the BT.1120 protocol may feature more than one stream, the RK3568 VICAP
+DVP features four DMA engines that can capture different streams.
+Similarly, the RK3568 VICAP MIPI CSI-2 receiver features four DMA engines to
+handle different Virtual Channels (VCs).
+
+The rkcif driver represents this hardware variant by exposing up the following
+V4L2 subdevices:
+
+* rkcif-dvp0: INTERFACE/CROP block for the DVP
+
+and the following video devices:
+
+* rkcif-dvp0-id0: The support for multiple streams on the DVP is not yet
+ implemented, as it is hard to find test hardware. Thus, this video device
+ represents the first DMA engine of the RK3568 DVP.
+
+.. kernel-figure:: rkcif-rk3568-vicap.dot
+ :alt: Topology of the RK3568 Video Capture (VICAP) unit
+ :align: center
diff --git a/Documentation/admin-guide/media/rkisp1.rst b/Documentation/admin-guide/media/rkisp1.rst
index ccf418713623..6c878c71442f 100644
--- a/Documentation/admin-guide/media/rkisp1.rst
+++ b/Documentation/admin-guide/media/rkisp1.rst
@@ -10,8 +10,8 @@ Introduction
============
This file documents the driver for the Rockchip ISP1 that is part of RK3288
-and RK3399 SoCs. The driver is located under drivers/staging/media/rkisp1
-and uses the Media-Controller API.
+and RK3399 SoCs. The driver is located under drivers/media/platform/rockchip/
+rkisp1 and uses the Media-Controller API.
Revisions
=========
@@ -114,11 +114,18 @@ to be applied to the hardware during a video stream, allowing userspace
to dynamically modify values such as black level, cross talk corrections
and others.
-The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
-userspace should set
+The ISP driver supports two different parameters configuration methods, the
+`fixed parameters format` or the `extensible parameters format`.
+
+When using the `fixed parameters` method the buffer format is defined by struct
+:c:type:`rkisp1_params_cfg`, and userspace should set
:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-rk-isp1-params>` as the
dataformat.
+When using the `extensible parameters` method the buffer format is defined by
+struct :c:type:`rkisp1_ext_params_cfg`, and userspace should set
+:ref:`V4L2_META_FMT_RK_ISP1_EXT_PARAMS <v4l2-meta-fmt-rk-isp1-ext-params>` as
+the dataformat.
Capturing Video Frames Example
==============================
diff --git a/Documentation/admin-guide/media/saa7134.rst b/Documentation/admin-guide/media/saa7134.rst
index 51eae7eb5ab7..18d7cbc897db 100644
--- a/Documentation/admin-guide/media/saa7134.rst
+++ b/Documentation/admin-guide/media/saa7134.rst
@@ -67,7 +67,7 @@ Changes / Fixes
Please mail to linux-media AT vger.kernel.org unified diffs against
the linux media git tree:
- https://git.linuxtv.org/media_tree.git/
+ https://git.linuxtv.org/media.git/
This is done by committing a patch at a clone of the git tree and
submitting the patch using ``git send-email``. Don't forget to
diff --git a/Documentation/admin-guide/media/si4713.rst b/Documentation/admin-guide/media/si4713.rst
index be8e6b49b7b4..85dcf1cd2df8 100644
--- a/Documentation/admin-guide/media/si4713.rst
+++ b/Documentation/admin-guide/media/si4713.rst
@@ -13,7 +13,7 @@ Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
Information about the Device
----------------------------
-This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address.
+This chip is a Silicon Labs product. It is an I2C device, currently on 0x63 address.
Basically, it has transmission and signal noise level measurement features.
The Si4713 integrates transmit functions for FM broadcast stereo transmission.
@@ -28,7 +28,7 @@ Users must comply with local regulations on radio frequency (RF) transmission.
Device driver description
-------------------------
-There are two modules to handle this device. One is a I2C device driver
+There are two modules to handle this device. One is an I2C device driver
and the other is a platform driver.
The I2C device driver exports a v4l2-subdev interface to the kernel.
@@ -113,7 +113,7 @@ Here is a summary of them:
- acomp_attack_time - Sets the attack time for audio dynamic range control.
- acomp_release_time - Sets the release time for audio dynamic range control.
-* Limiter setups audio deviation limiter feature. Once a over deviation occurs,
+* Limiter sets up the audio deviation limiter feature. Once an over deviation occurs,
it is possible to adjust the front-end gain of the audio input and always
prevent over deviation.
diff --git a/Documentation/admin-guide/media/si476x.rst b/Documentation/admin-guide/media/si476x.rst
index 87062301d6a1..c8882ee9f208 100644
--- a/Documentation/admin-guide/media/si476x.rst
+++ b/Documentation/admin-guide/media/si476x.rst
@@ -142,7 +142,7 @@ The drivers exposes following files:
indicator
0x18 lassi Signed Low side adjacent Channel
Strength indicator
- 0x19 hassi ditto fpr High side
+ 0x19 hassi ditto for High side
0x20 mult Multipath indicator
0x21 dev Frequency deviation
0x24 assi Adjacent channel SSI
diff --git a/Documentation/admin-guide/media/starfive_camss.rst b/Documentation/admin-guide/media/starfive_camss.rst
new file mode 100644
index 000000000000..ca42e9447c47
--- /dev/null
+++ b/Documentation/admin-guide/media/starfive_camss.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+================================
+Starfive Camera Subsystem driver
+================================
+
+Introduction
+------------
+
+This file documents the driver for the Starfive Camera Subsystem found on
+Starfive JH7110 SoC. The driver is located under drivers/staging/media/starfive/
+camss.
+
+The driver implements V4L2, Media controller and v4l2_subdev interfaces. Camera
+sensor using V4L2 subdev interface in the kernel is supported.
+
+The driver has been successfully used on the Gstreamer 1.18.5 with v4l2src
+plugin.
+
+
+Starfive Camera Subsystem hardware
+----------------------------------
+
+The Starfive Camera Subsystem hardware consists of::
+
+ |\ +---------------+ +-----------+
+ +----------+ | \ | | | |
+ | | | | | | | |
+ | MIPI |----->| |----->| ISP |----->| |
+ | | | | | | | |
+ +----------+ | | | | | Memory |
+ |MUX| +---------------+ | Interface |
+ +----------+ | | | |
+ | | | |---------------------------->| |
+ | Parallel |----->| | | |
+ | | | | | |
+ +----------+ | / | |
+ |/ +-----------+
+
+- MIPI: The MIPI interface, receiving data from a MIPI CSI-2 camera sensor.
+
+- Parallel: The parallel interface, receiving data from a parallel sensor.
+
+- ISP: The ISP, processing raw Bayer data from an image sensor and producing
+ YUV frames.
+
+
+Topology
+--------
+
+The media controller pipeline graph is as follows:
+
+.. _starfive_camss_graph:
+
+.. kernel-figure:: starfive_camss_graph.dot
+ :alt: starfive_camss_graph.dot
+ :align: center
+
+The driver has 2 video devices:
+
+- capture_raw: The capture device, capturing image data directly from a sensor.
+- capture_yuv: The capture device, capturing YUV frame data processed by the
+ ISP module
+
+The driver has 3 subdevices:
+
+- stf_isp: is responsible for all the isp operations, outputs YUV frames.
+- cdns_csi2rx: a CSI-2 bridge supporting up to 4 CSI lanes in input, and 4
+ different pixel streams in output.
+- imx219: an image sensor, image data is sent through MIPI CSI-2.
diff --git a/Documentation/admin-guide/media/starfive_camss_graph.dot b/Documentation/admin-guide/media/starfive_camss_graph.dot
new file mode 100644
index 000000000000..8eff1f161ac7
--- /dev/null
+++ b/Documentation/admin-guide/media/starfive_camss_graph.dot
@@ -0,0 +1,12 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{<port0> 0} | stf_isp\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port1 -> n00000008 [style=dashed]
+ n00000004 [label="capture_raw\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n00000008 [label="capture_yuv\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n0000000e [label="{{<port0> 0} | cdns_csi2rx.19800000.csi-bridge\n | {<port1> 1 | <port2> 2 | <port3> 3 | <port4> 4}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000000e:port1 -> n00000001:port0 [style=dashed]
+ n0000000e:port1 -> n00000004 [style=dashed]
+ n00000018 [label="{{} | imx219 6-0010\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000018:port0 -> n0000000e:port0 [style=bold]
+}
diff --git a/Documentation/admin-guide/media/tm6000-cardlist.rst b/Documentation/admin-guide/media/tm6000-cardlist.rst
deleted file mode 100644
index 6d2769c0f4d8..000000000000
--- a/Documentation/admin-guide/media/tm6000-cardlist.rst
+++ /dev/null
@@ -1,83 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-TM6000 cards list
-=================
-
-.. tabularcolumns:: |p{1.4cm}|p{11.1cm}|p{4.2cm}|
-
-.. flat-table::
- :header-rows: 1
- :widths: 2 19 18
- :stub-columns: 0
-
- * - Card number
- - Card name
- - USB IDs
-
- * - 0
- - Unknown tm6000 video grabber
- -
-
- * - 1
- - Generic tm5600 board
- - 6000:0001
-
- * - 2
- - Generic tm6000 board
- -
-
- * - 3
- - Generic tm6010 board
- - 6000:0002
-
- * - 4
- - 10Moons UT 821
- -
-
- * - 5
- - 10Moons UT 330
- -
-
- * - 6
- - ADSTECH Dual TV USB
- - 06e1:f332
-
- * - 7
- - Freecom Hybrid Stick / Moka DVB-T Receiver Dual
- - 14aa:0620
-
- * - 8
- - ADSTECH Mini Dual TV USB
- - 06e1:b339
-
- * - 9
- - Hauppauge WinTV HVR-900H / WinTV USB2-Stick
- - 2040:6600, 2040:6601, 2040:6610, 2040:6611
-
- * - 10
- - Beholder Wander DVB-T/TV/FM USB2.0
- - 6000:dec0
-
- * - 11
- - Beholder Voyager TV/FM USB2.0
- - 6000:dec1
-
- * - 12
- - Terratec Cinergy Hybrid XE / Cinergy Hybrid-Stick
- - 0ccd:0086, 0ccd:00A5
-
- * - 13
- - Twinhan TU501(704D1)
- - 13d3:3240, 13d3:3241, 13d3:3243, 13d3:3264
-
- * - 14
- - Beholder Wander Lite DVB-T/TV/FM USB2.0
- - 6000:dec2
-
- * - 15
- - Beholder Voyager Lite TV/FM USB2.0
- - 6000:dec3
-
- * - 16
- - Terratec Grabster AV 150/250 MX
- - 0ccd:0079
diff --git a/Documentation/admin-guide/media/tuner-cardlist.rst b/Documentation/admin-guide/media/tuner-cardlist.rst
index 362617c59c5d..65ecf48ddf24 100644
--- a/Documentation/admin-guide/media/tuner-cardlist.rst
+++ b/Documentation/admin-guide/media/tuner-cardlist.rst
@@ -97,4 +97,6 @@ Tuner number Card name
89 Sony BTF-PG472Z PAL/SECAM
90 Sony BTF-PK467Z NTSC-M-JP
91 Sony BTF-PB463Z NTSC-M
+92 Silicon Labs Si2157 tuner
+93 Tena TNF931D-DFDR1
============ =====================================================
diff --git a/Documentation/admin-guide/media/usb-cardlist.rst b/Documentation/admin-guide/media/usb-cardlist.rst
index 1e96f928e0af..5f5ab0723e48 100644
--- a/Documentation/admin-guide/media/usb-cardlist.rst
+++ b/Documentation/admin-guide/media/usb-cardlist.rst
@@ -43,7 +43,6 @@ Driver Name
airspy AirSpy
au0828 Auvitek AU0828
b2c2-flexcop-usb Technisat/B2C2 Air/Sky/Cable2PC USB
-cpia2 CPiA2 Video For Linux
cx231xx Conexant cx231xx USB video capture
dvb-as102 Abilis AS102 DVB receiver
dvb-ttusb-budget Technotrend/Hauppauge Nova - USB devices
@@ -93,15 +92,10 @@ pwc USB Philips Cameras
s2250 Sensoray 2250/2251
s2255drv USB Sensoray 2255 video capture device
smsusb Siano SMS1xxx based MDTV receiver
-stkwebcam USB Syntek DC1125 Camera
-tm6000-alsa TV Master TM5600/6000/6010 audio
-tm6000-dvb DVB Support for tm6000 based TV cards
-tm6000 TV Master TM5600/6000/6010 driver
ttusb_dec Technotrend/Hauppauge USB DEC devices
usbtv USBTV007 video capture
uvcvideo USB Video Class (UVC)
zd1301 ZyDAS ZD1301
-zr364xx USB ZR364XX Camera
====================== =========================================================
.. toctree::
@@ -110,7 +104,6 @@ zr364xx USB ZR364XX Camera
au0828-cardlist
cx231xx-cardlist
em28xx-cardlist
- tm6000-cardlist
siano-cardlist
gspca-cardlist
diff --git a/Documentation/admin-guide/media/v4l-drivers.rst b/Documentation/admin-guide/media/v4l-drivers.rst
index 9c7ebe2ca3bd..393f83e8dc4d 100644
--- a/Documentation/admin-guide/media/v4l-drivers.rst
+++ b/Documentation/admin-guide/media/v4l-drivers.rst
@@ -10,25 +10,30 @@ Video4Linux (V4L) driver-specific documentation
:maxdepth: 2
bttv
+ c3-isp
cafe_ccic
- cpia2
cx88
- davinci-vpbe
fimc
imx
imx7
ipu3
+ ipu6-isys
ivtv
- meye
+ mali-c55
+ mgb4
omap3isp
- omap4_camera
philips
qcom_camss
+ raspberrypi-pisp-be
rcar-fdp1
+ rkcif
rkisp1
+ raspberrypi-rp1-cfe
saa7134
si470x
si4713
si476x
+ starfive_camss
vimc
+ visl
vivid
diff --git a/Documentation/admin-guide/media/vimc.rst b/Documentation/admin-guide/media/vimc.rst
index 3b4d2b36b4f3..29d843a8ddb1 100644
--- a/Documentation/admin-guide/media/vimc.rst
+++ b/Documentation/admin-guide/media/vimc.rst
@@ -35,11 +35,11 @@ of commands fits for the default topology:
media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
- media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
- media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'
- v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
+ media-ctl -d platform:vimc -V '"Scaler":0[fmt:RGB888_1X24/640x480]'
+ media-ctl -d platform:vimc -V '"Scaler":0[crop:(100,50)/400x150]'
+ media-ctl -d platform:vimc -V '"Scaler":1[fmt:RGB888_1X24/300x700]'
+ v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=300,height=700
v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
- v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81
Subdevices
----------
diff --git a/Documentation/admin-guide/media/visl.rst b/Documentation/admin-guide/media/visl.rst
new file mode 100644
index 000000000000..cd45145cde68
--- /dev/null
+++ b/Documentation/admin-guide/media/visl.rst
@@ -0,0 +1,185 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+The Virtual Stateless Decoder Driver (visl)
+===========================================
+
+A virtual stateless decoder device for stateless uAPI development
+purposes.
+
+This tool's objective is to help the development and testing of
+userspace applications that use the V4L2 stateless API to decode media.
+
+A userspace implementation can use visl to run a decoding loop even when
+no hardware is available or when the kernel uAPI for the codec has not
+been upstreamed yet. This can reveal bugs at an early stage.
+
+This driver can also trace the contents of the V4L2 controls submitted
+to it. It can also dump the contents of the vb2 buffers through a
+debugfs interface. This is in many ways similar to the tracing
+infrastructure available for other popular encode/decode APIs out there
+and can help develop a userspace application by using another (working)
+one as a reference.
+
+.. note::
+
+ No actual decoding of video frames is performed by visl. The
+ V4L2 test pattern generator is used to write various debug information
+ to the capture buffers instead.
+
+Module parameters
+-----------------
+
+- visl_debug: Activates debug info, printing various debug messages through
+ dprintk. Also controls whether per-frame debug info is shown. Defaults to off.
+ Note that enabling this feature can result in slow performance through serial.
+
+- visl_transtime_ms: Simulated process time in milliseconds. Slowing down the
+ decoding speed can be useful for debugging.
+
+- visl_dprintk_frame_start, visl_dprintk_frame_nframes: Dictates a range of
+ frames where dprintk is activated. This only controls the dprintk tracing on a
+ per-frame basis. Note that printing a lot of data can be slow through serial.
+
+- keep_bitstream_buffers: Controls whether bitstream (i.e. OUTPUT) buffers are
+ kept after a decoding session. Defaults to false so as to reduce the amount of
+ clutter. keep_bitstream_buffers == false works well when live debugging the
+ client program with GDB.
+
+- bitstream_trace_frame_start, bitstream_trace_nframes: Similar to
+ visl_dprintk_frame_start, visl_dprintk_nframes, but controls the dumping of
+ buffer data through debugfs instead.
+
+- tpg_verbose: Write extra information on each output frame to ease debugging
+ the API. When set to true, the output frames are not stable for a given input
+ as some information like pointers or queue status will be added to them.
+
+What is the default use case for this driver?
+---------------------------------------------
+
+This driver can be used as a way to compare different userspace implementations.
+This assumes that a working client is run against visl and that the ftrace and
+OUTPUT buffer data is subsequently used to debug a work-in-progress
+implementation.
+
+Even though no video decoding is actually done, the output frames can be used
+against a reference for a given input, except if tpg_verbose is set to true.
+
+Depending on the tpg_verbose parameter value, information on reference frames,
+their timestamps, the status of the OUTPUT and CAPTURE queues and more can be
+read directly from the CAPTURE buffers.
+
+Supported codecs
+----------------
+
+The following codecs are supported:
+
+- FWHT
+- MPEG2
+- VP8
+- VP9
+- H.264
+- HEVC
+- AV1
+
+visl trace events
+-----------------
+The trace events are defined on a per-codec basis, e.g.:
+
+.. code-block:: bash
+
+ $ ls /sys/kernel/tracing/events/ | grep visl
+ visl_av1_controls
+ visl_fwht_controls
+ visl_h264_controls
+ visl_hevc_controls
+ visl_mpeg2_controls
+ visl_vp8_controls
+ visl_vp9_controls
+
+For example, in order to dump HEVC SPS data:
+
+.. code-block:: bash
+
+ $ echo 1 > /sys/kernel/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
+
+The SPS data will be dumped to the trace buffer, i.e.:
+
+.. code-block:: bash
+
+ $ cat /sys/kernel/tracing/trace
+ video_parameter_set_id 0
+ seq_parameter_set_id 0
+ pic_width_in_luma_samples 1920
+ pic_height_in_luma_samples 1080
+ bit_depth_luma_minus8 0
+ bit_depth_chroma_minus8 0
+ log2_max_pic_order_cnt_lsb_minus4 4
+ sps_max_dec_pic_buffering_minus1 6
+ sps_max_num_reorder_pics 2
+ sps_max_latency_increase_plus1 0
+ log2_min_luma_coding_block_size_minus3 0
+ log2_diff_max_min_luma_coding_block_size 3
+ log2_min_luma_transform_block_size_minus2 0
+ log2_diff_max_min_luma_transform_block_size 3
+ max_transform_hierarchy_depth_inter 2
+ max_transform_hierarchy_depth_intra 2
+ pcm_sample_bit_depth_luma_minus1 0
+ pcm_sample_bit_depth_chroma_minus1 0
+ log2_min_pcm_luma_coding_block_size_minus3 0
+ log2_diff_max_min_pcm_luma_coding_block_size 0
+ num_short_term_ref_pic_sets 0
+ num_long_term_ref_pics_sps 0
+ chroma_format_idc 1
+ sps_max_sub_layers_minus1 0
+ flags AMP_ENABLED|SAMPLE_ADAPTIVE_OFFSET|TEMPORAL_MVP_ENABLED|STRONG_INTRA_SMOOTHING_ENABLED
+
+
+Dumping OUTPUT buffer data through debugfs
+------------------------------------------
+
+If the **VISL_DEBUGFS** Kconfig is enabled, visl will populate
+**/sys/kernel/debug/visl/bitstream** with OUTPUT buffer data according to the
+values of bitstream_trace_frame_start and bitstream_trace_nframes. This can
+highlight errors as broken clients may fail to fill the buffers properly.
+
+A single file is created for each processed OUTPUT buffer. Its name contains an
+integer that denotes the buffer sequence, i.e.:
+
+.. code-block:: c
+
+ snprintf(name, 32, "bitstream%d", run->src->sequence);
+
+Dumping the values is simply a matter of reading from the file, i.e.:
+
+For the buffer with sequence == 0:
+
+.. code-block:: bash
+
+ $ xxd /sys/kernel/debug/visl/bitstream/bitstream0
+ 00000000: 2601 af04 d088 bc25 a173 0e41 a4f2 3274 &......%.s.A..2t
+ 00000010: c668 cb28 e775 b4ac f53a ba60 f8fd 3aa1 .h.(.u...:.`..:.
+ 00000020: 46b4 bcfc 506c e227 2372 e5f5 d7ea 579f F...Pl.'#r....W.
+ 00000030: 6371 5eb5 0eb8 23b5 ca6a 5de5 983a 19e4 cq^...#..j]..:..
+ 00000040: e8c3 4320 b4ba a226 cbc1 4138 3a12 32d6 ..C ...&..A8:.2.
+ 00000050: fef3 247b 3523 4e90 9682 ac8e eb0c a389 ..${5#N.........
+ 00000060: ddd0 6cfc 0187 0e20 7aae b15b 1812 3d33 ..l.... z..[..=3
+ 00000070: e1c5 f425 a83a 00b7 4f18 8127 3c4c aefb ...%.:..O..'<L..
+
+For the buffer with sequence == 1:
+
+.. code-block:: bash
+
+ $ xxd /sys/kernel/debug/visl/bitstream/bitstream1
+ 00000000: 0201 d021 49e1 0c40 aa11 1449 14a6 01dc ...!I..@...I....
+ 00000010: 7023 889a c8cd 2cd0 13b4 dab0 e8ca 21fe p#....,.......!.
+ 00000020: c4c8 ab4c 486e 4e2f b0df 96cc c74e 8dde ...LHnN/.....N..
+ 00000030: 8ce7 ee36 d880 4095 4d64 30a0 ff4f 0c5e ...6..@.Md0..O.^
+ 00000040: f16b a6a1 d806 ca2a 0ece a673 7bea 1f37 .k.....*...s{..7
+ 00000050: 370f 5bb9 1dc4 ba21 6434 bc53 0173 cba0 7.[....!d4.S.s..
+ 00000060: dfe6 bc99 01ea b6e0 346b 92b5 c8de 9f5d ........4k.....]
+ 00000070: e7cc 3484 1769 fef2 a693 a945 2c8b 31da ..4..i.....E,.1.
+
+And so on.
+
+By default, the files are removed during STREAMOFF. This is to reduce the amount
+of clutter.
diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst
index 4f680dc9661c..034ca7c77fb9 100644
--- a/Documentation/admin-guide/media/vivid.rst
+++ b/Documentation/admin-guide/media/vivid.rst
@@ -60,7 +60,7 @@ all configurable using the following module options:
- node_types:
which devices should each driver instance create. An array of
- hexadecimal values, one for each instance. The default is 0x1d3d.
+ hexadecimal values, one for each instance. The default is 0xe1d3d.
Each value is a bitmask with the following meaning:
- bit 0: Video Capture node
@@ -302,6 +302,15 @@ all configurable using the following module options:
- 0: forbid hints
- 1: allow hints
+- supports_requests:
+
+ specifies if the device should support the Request API. There are
+ three possible values, default is 1:
+
+ - 0: no request
+ - 1: supports requests
+ - 2: requires requests
+
Taken together, all these module options allow you to precisely customize
the driver behavior and test your application with all sorts of permutations.
It is also very suitable to emulate hardware that is not yet available, e.g.
@@ -313,13 +322,13 @@ Video Capture
This is probably the most frequently used feature. The video capture device
can be configured by using the module options num_inputs, input_types and
-ccs_cap_mode (see section 1 for more detailed information), but by default
-four inputs are configured: a webcam, a TV tuner, an S-Video and an HDMI
-input, one input for each input type. Those are described in more detail
-below.
+ccs_cap_mode (see "Configuring the driver" for more detailed information),
+but by default four inputs are configured: a webcam, a TV tuner, an S-Video
+and an HDMI input, one input for each input type. Those are described in more
+detail below.
Special attention has been given to the rate at which new frames become
-available. The jitter will be around 1 jiffie (that depends on the HZ
+available. The jitter will be around 1 jiffy (that depends on the HZ
configuration of your kernel, so usually 1/100, 1/250 or 1/1000 of a second),
but the long-term behavior is exactly following the framerate. So a
framerate of 59.94 Hz is really different from 60 Hz. If the framerate
@@ -392,7 +401,7 @@ Which one is returned depends on the chosen channel, each next valid channel
will cycle through the possible audio subchannel combinations. This allows
you to test the various combinations by just switching channels..
-Finally, for these inputs the v4l2_timecode struct is filled in in the
+Finally, for these inputs the v4l2_timecode struct is filled in the
dequeued v4l2_buffer struct.
@@ -434,10 +443,10 @@ Video Output
------------
The video output device can be configured by using the module options
-num_outputs, output_types and ccs_out_mode (see section 1 for more detailed
-information), but by default two outputs are configured: an S-Video and an
-HDMI input, one output for each output type. Those are described in more detail
-below.
+num_outputs, output_types and ccs_out_mode (see "Configuring the driver"
+for more detailed information), but by default two outputs are configured:
+an S-Video and an HDMI input, one output for each output type. Those are
+described in more detail below.
Like with video capture the framerate is also exact in the long term.
@@ -580,7 +589,7 @@ Metadata Capture
----------------
The Metadata capture generates UVC format metadata. The PTS and SCR are
-transmitted based on the values set in vivid contols.
+transmitted based on the values set in vivid controls.
The Metadata device will only work for the Webcam input, it will give
back an error for all other inputs.
@@ -1011,11 +1020,6 @@ Digital Video Controls
affects the reported colorspace since DVI_D outputs will always use
sRGB.
-- Display Present:
-
- sets the presence of a "display" on the HDMI output. This affects
- the tx_edid_present, tx_hotplug and tx_rxsense controls.
-
FM Radio Receiver Controls
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1130,35 +1134,34 @@ Metadata Capture Controls
if set, then the generated metadata stream contains Source Clock information.
-Video, VBI and RDS Looping
---------------------------
-The vivid driver supports looping of video output to video input, VBI output
-to VBI input and RDS output to RDS input. For video/VBI looping this emulates
-as if a cable was hooked up between the output and input connector. So video
-and VBI looping is only supported between S-Video and HDMI inputs and outputs.
-VBI is only valid for S-Video as it makes no sense for HDMI.
+Video, Sliced VBI and HDMI CEC Looping
+--------------------------------------
-Since radio is wireless this looping always happens if the radio receiver
-frequency is close to the radio transmitter frequency. In that case the radio
-transmitter will 'override' the emulated radio stations.
-
-Looping is currently supported only between devices created by the same
-vivid driver instance.
+Video Looping functionality is supported for devices created by the same
+vivid driver instance, as well as across multiple instances of the vivid driver.
+The vivid driver supports looping of video and Sliced VBI data between an S-Video output
+and an S-Video input. It also supports looping of video and HDMI CEC data between an
+HDMI output and an HDMI input.
+To enable looping, set the 'HDMI/S-Video XXX-N Is Connected To' control(s) to select
+whether an input uses the Test Pattern Generator, or is disconnected, or is connected
+to an output. An input can be connected to an output from any vivid instance.
+The inputs and outputs are numbered XXX-N where XXX is the vivid instance number
+(see module option n_devs). If there is only one vivid instance (the default), then
+XXX will be 000. And N is the Nth S-Video/HDMI input or output of that instance.
+If vivid is loaded without module options, then you can connect the S-Video 000-0 input
+to the S-Video 000-0 output, or the HDMI 000-0 input to the HDMI 000-0 output.
+This is the equivalent of connecting or disconnecting a cable between an input and an
+output in a physical device.
-Video and Sliced VBI looping
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If an 'HDMI/S-Video XXX-N Is Connected To' control selected an output, then the video
+output will be looped to the video input provided that:
-The way to enable video/VBI looping is currently fairly crude. A 'Loop Video'
-control is available in the "Vivid" control class of the video
-capture and VBI capture devices. When checked the video looping will be enabled.
-Once enabled any video S-Video or HDMI input will show a static test pattern
-until the video output has started. At that time the video output will be
-looped to the video input provided that:
+- the currently selected input matches the input indicated by the control name.
-- the input type matches the output type. So the HDMI input cannot receive
- video from the S-Video output.
+- in the vivid instance of the output connector, the currently selected output matches
+ the output indicated by the control's value.
- the video resolution of the video input must match that of the video output.
So it is not possible to loop a 50 Hz (720x576) S-Video output to a 60 Hz
@@ -1185,6 +1188,8 @@ looped to the video input provided that:
"DV Timings Signal Mode" for the HDMI input should be configured so that a
valid signal is passed to the video input.
+If any condition is not valid, then the 'Noise' test pattern is shown.
+
The framerates do not have to match, although this might change in the future.
By default you will see the OSD text superimposed on top of the looped video.
@@ -1198,17 +1203,26 @@ and WSS (50 Hz formats) VBI data is looped. Teletext VBI data is not looped.
Radio & RDS Looping
-~~~~~~~~~~~~~~~~~~~
-
-As mentioned in section 6 the radio receiver emulates stations are regular
-frequency intervals. Depending on the frequency of the radio receiver a
-signal strength value is calculated (this is returned by VIDIOC_G_TUNER).
-However, it will also look at the frequency set by the radio transmitter and
-if that results in a higher signal strength than the settings of the radio
-transmitter will be used as if it was a valid station. This also includes
-the RDS data (if any) that the transmitter 'transmits'. This is received
-faithfully on the receiver side. Note that when the driver is loaded the
-frequencies of the radio receiver and transmitter are not identical, so
+-------------------
+
+The vivid driver supports looping of RDS output to RDS input.
+
+Since radio is wireless this looping always happens if the radio receiver
+frequency is close to the radio transmitter frequency. In that case the radio
+transmitter will 'override' the emulated radio stations.
+
+RDS looping is currently supported only between devices created by the same
+vivid driver instance.
+
+As mentioned in the "Radio Receiver" section, the radio receiver emulates
+stations at regular frequency intervals. Depending on the frequency of the
+radio receiver a signal strength value is calculated (this is returned by
+VIDIOC_G_TUNER). However, it will also look at the frequency set by the radio
+transmitter and if that results in a higher signal strength than the settings
+of the radio transmitter will be used as if it was a valid station. This also
+includes the RDS data (if any) that the transmitter 'transmits'. This is
+received faithfully on the receiver side. Note that when the driver is loaded
+the frequencies of the radio receiver and transmitter are not identical, so
initially no looping takes place.
@@ -1218,8 +1232,8 @@ Cropping, Composing, Scaling
This driver supports cropping, composing and scaling in any combination. Normally
which features are supported can be selected through the Vivid controls,
but it is also possible to hardcode it when the module is loaded through the
-ccs_cap_mode and ccs_out_mode module options. See section 1 on the details of
-these module options.
+ccs_cap_mode and ccs_out_mode module options. See "Configuring the driver" on
+the details of these module options.
This allows you to test your application for all these variations.
@@ -1260,7 +1274,8 @@ is set, then the alpha component is only used for the color red and set to
The driver has to be configured to support the multiplanar formats. By default
the driver instances are single-planar. This can be changed by setting the
-multiplanar module option, see section 1 for more details on that option.
+multiplanar module option, see "Configuring the driver" for more details on that
+option.
If the driver instance is using the multiplanar formats/API, then the first
single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
@@ -1270,74 +1285,6 @@ data_offset to be non-zero, so this is a useful feature for testing applications
Video output will also honor any data_offset that the application set.
-Capture Overlay
----------------
-
-Note: capture overlay support is implemented primarily to test the existing
-V4L2 capture overlay API. In practice few if any GPUs support such overlays
-anymore, and neither are they generally needed anymore since modern hardware
-is so much more capable. By setting flag 0x10000 in the node_types module
-option the vivid driver will create a simple framebuffer device that can be
-used for testing this API. Whether this API should be used for new drivers is
-questionable.
-
-This driver has support for a destructive capture overlay with bitmap clipping
-and list clipping (up to 16 rectangles) capabilities. Overlays are not
-supported for multiplanar formats. It also honors the struct v4l2_window field
-setting: if it is set to FIELD_TOP or FIELD_BOTTOM and the capture setting is
-FIELD_ALTERNATE, then only the top or bottom fields will be copied to the overlay.
-
-The overlay only works if you are also capturing at that same time. This is a
-vivid limitation since it copies from a buffer to the overlay instead of
-filling the overlay directly. And if you are not capturing, then no buffers
-are available to fill.
-
-In addition, the pixelformat of the capture format and that of the framebuffer
-must be the same for the overlay to work. Otherwise VIDIOC_OVERLAY will return
-an error.
-
-In order to really see what it going on you will need to create two vivid
-instances: the first with a framebuffer enabled. You configure the capture
-overlay of the second instance to use the framebuffer of the first, then
-you start capturing in the second instance. For the first instance you setup
-the output overlay for the video output, turn on video looping and capture
-to see the blended framebuffer overlay that's being written to by the second
-instance. This setup would require the following commands:
-
-.. code-block:: none
-
- $ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
- $ v4l2-ctl -d1 --find-fb
- /dev/fb1 is the framebuffer associated with base address 0x12800000
- $ sudo v4l2-ctl -d2 --set-fbuf fb=1
- $ v4l2-ctl -d1 --set-fbuf fb=1
- $ v4l2-ctl -d0 --set-fmt-video=pixelformat='AR15'
- $ v4l2-ctl -d1 --set-fmt-video-out=pixelformat='AR15'
- $ v4l2-ctl -d2 --set-fmt-video=pixelformat='AR15'
- $ v4l2-ctl -d0 -i2
- $ v4l2-ctl -d2 -i2
- $ v4l2-ctl -d2 -c horizontal_movement=4
- $ v4l2-ctl -d1 --overlay=1
- $ v4l2-ctl -d1 -c loop_video=1
- $ v4l2-ctl -d2 --stream-mmap --overlay=1
-
-And from another console:
-
-.. code-block:: none
-
- $ v4l2-ctl -d1 --stream-out-mmap
-
-And yet another console:
-
-.. code-block:: none
-
- $ qv4l2
-
-and start streaming.
-
-As you can see, this is not for the faint of heart...
-
-
Output Overlay
--------------
@@ -1396,7 +1343,7 @@ Some Future Improvements
Just as a reminder and in no particular order:
- Add a virtual alsa driver to test audio
-- Add virtual sub-devices and media controller support
+- Add virtual sub-devices
- Some support for testing compressed video
- Add support to loop raw VBI output to raw VBI input
- Add support to loop teletext sliced VBI output to VBI input
@@ -1405,12 +1352,10 @@ Just as a reminder and in no particular order:
- Add ARGB888 overlay support: better testing of the alpha channel
- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
- Use per-queue locks and/or per-device locks to improve throughput
-- Add support to loop from a specific output to a specific input across
- vivid instances
- The SDR radio should use the same 'frequencies' for stations as the normal
radio receiver, and give back noise if the frequency doesn't match up with
a station frequency
- Make a thread for the RDS generation, that would help in particular for the
"Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated
in real-time.
-- Changing the EDID should cause hotplug detect emulation to happen.
+- Changing the EDID doesn't wait 100 ms before setting the HPD signal.
diff --git a/Documentation/admin-guide/media/zr364xx.rst b/Documentation/admin-guide/media/zr364xx.rst
deleted file mode 100644
index 7291e54b8be3..000000000000
--- a/Documentation/admin-guide/media/zr364xx.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-Zoran 364xx based USB webcam module
-===================================
-
-site: http://royale.zerezo.com/zr364xx/
-
-mail: royale@zerezo.com
-
-
-Introduction
-------------
-
-
-This brings support under Linux for the Aiptek PocketDV 3300 and similar
-devices in webcam mode. If you just want to get on your PC the pictures
-and movies on the camera, you should use the usb-storage module instead.
-
-The driver works with several other cameras in webcam mode (see the list
-below).
-
-Possible chipsets are : ZR36430 (ZR36430BGC) and
-maybe ZR36431, ZR36440, ZR36442...
-
-You can try the experience changing the vendor/product ID values (look
-at the source code).
-
-You can get these values by looking at /var/log/messages when you plug
-your camera, or by typing : cat /sys/kernel/debug/usb/devices.
-
-
-Install
--------
-
-In order to use this driver, you must compile it with your kernel,
-with the following config options::
-
- ./scripts/config -e USB
- ./scripts/config -m MEDIA_SUPPORT
- ./scripts/config -e MEDIA_USB_SUPPORT
- ./scripts/config -e MEDIA_CAMERA_SUPPORT
- ./scripts/config -m USB_ZR364XX
-
-Usage
------
-
-modprobe zr364xx debug=X mode=Y
-
-- debug : set to 1 to enable verbose debug messages
-- mode : 0 = 320x240, 1 = 160x120, 2 = 640x480
-
-You can then use the camera with V4L2 compatible applications, for
-example Ekiga.
-
-To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M
-count=1
-
-links
------
-
-http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV)
-http://www.harmwal.nl/pccam880/ (this project also supports cameras based on this chipset)
-
-Supported devices
------------------
-
-====== ======= ============== ====================
-Vendor Product Distributor Model
-====== ======= ============== ====================
-0x08ca 0x0109 Aiptek PocketDV 3300
-0x08ca 0x0109 Maxell Maxcam PRO DV3
-0x041e 0x4024 Creative PC-CAM 880
-0x0d64 0x0108 Aiptek Fidelity 3200
-0x0d64 0x0108 Praktica DCZ 1.3 S
-0x0d64 0x0108 Genius Digital Camera (?)
-0x0d64 0x0108 DXG Technology Fashion Cam
-0x0546 0x3187 Polaroid iON 230
-0x0d64 0x3108 Praktica Exakta DC 2200
-0x0d64 0x3108 Genius G-Shot D211
-0x0595 0x4343 Concord Eye-Q Duo 1300
-0x0595 0x4343 Concord Eye-Q Duo 2000
-0x0595 0x4343 Fujifilm EX-10
-0x0595 0x4343 Ricoh RDC-6000
-0x0595 0x4343 Digitrex DSC 1300
-0x0595 0x4343 Firstline FDC 2000
-0x0bb0 0x500d Concord EyeQ Go Wireless
-0x0feb 0x2004 CRS Electronic 3.3 Digital Camera
-0x0feb 0x2004 Packard Bell DSC-300
-0x055f 0xb500 Mustek MDC 3000
-0x08ca 0x2062 Aiptek PocketDV 5700
-0x052b 0x1a18 Chiphead Megapix V12
-0x04c8 0x0729 Konica Revio 2
-0x04f2 0xa208 Creative PC-CAM 850
-0x0784 0x0040 Traveler Slimline X5
-0x06d6 0x0034 Trust Powerc@m 750
-0x0a17 0x0062 Pentax Optio 50L
-0x06d6 0x003b Trust Powerc@m 970Z
-0x0a17 0x004e Pentax Optio 50
-0x041e 0x405d Creative DiVi CAM 516
-0x08ca 0x2102 Aiptek DV T300
-0x06d6 0x003d Trust Powerc@m 910Z
-====== ======= ============== ====================
diff --git a/Documentation/admin-guide/mm/cma_debugfs.rst b/Documentation/admin-guide/mm/cma_debugfs.rst
index 4e06ffabd78a..4120e9cb0cd5 100644
--- a/Documentation/admin-guide/mm/cma_debugfs.rst
+++ b/Documentation/admin-guide/mm/cma_debugfs.rst
@@ -5,21 +5,27 @@ CMA Debugfs Interface
The CMA debugfs interface is useful to retrieve basic information out of the
different CMA areas and to test allocation/release in each of the areas.
-Each CMA zone represents a directory under <debugfs>/cma/, indexed by the
-kernel's CMA index. So the first CMA zone would be:
+Each CMA area represents a directory under <debugfs>/cma/, represented by
+its CMA name like below:
- <debugfs>/cma/cma-0
+ <debugfs>/cma/<cma_name>
The structure of the files created under that directory is as follows:
- - [RO] base_pfn: The base PFN (Page Frame Number) of the zone.
+ - [RO] base_pfn: The base PFN (Page Frame Number) of the CMA area.
+ This is the same as ranges/0/base_pfn.
- [RO] count: Amount of memory in the CMA area.
- [RO] order_per_bit: Order of pages represented by one bit.
- - [RO] bitmap: The bitmap of page states in the zone.
+ - [RO] bitmap: The bitmap of allocated pages in the area.
+ This is the same as ranges/0/base_pfn.
+ - [RO] ranges/N/base_pfn: The base PFN of contiguous range N
+ in the CMA area.
+ - [RO] ranges/N/bitmap: The bit map of allocated pages in
+ range N in the CMA area.
- [WO] alloc: Allocate N pages from that CMA area. For example::
- echo 5 > <debugfs>/cma/cma-2/alloc
+ echo 5 > <debugfs>/cma/<cma_name>/alloc
-would try to allocate 5 pages from the cma-2 area.
+would try to allocate 5 pages from the 'cma_name' area.
- [WO] free: Free N pages from that CMA area, similar to the above.
diff --git a/Documentation/admin-guide/mm/concepts.rst b/Documentation/admin-guide/mm/concepts.rst
index c79f1e336222..e796b0a7e4a5 100644
--- a/Documentation/admin-guide/mm/concepts.rst
+++ b/Documentation/admin-guide/mm/concepts.rst
@@ -1,5 +1,3 @@
-.. _mm_concepts:
-
=================
Concepts overview
=================
@@ -86,16 +84,15 @@ memory with the huge pages. The first one is `HugeTLB filesystem`, or
hugetlbfs. It is a pseudo filesystem that uses RAM as its backing
store. For the files created in this filesystem the data resides in
the memory and mapped using huge pages. The hugetlbfs is described at
-:ref:`Documentation/admin-guide/mm/hugetlbpage.rst <hugetlbpage>`.
+Documentation/admin-guide/mm/hugetlbpage.rst.
Another, more recent, mechanism that enables use of the huge pages is
called `Transparent HugePages`, or THP. Unlike the hugetlbfs that
requires users and/or system administrators to configure what parts of
the system memory should and can be mapped by the huge pages, THP
manages such mappings transparently to the user and hence the
-name. See
-:ref:`Documentation/admin-guide/mm/transhuge.rst <admin_guide_transhuge>`
-for more details about THP.
+name. See Documentation/admin-guide/mm/transhuge.rst for more details
+about THP.
Zones
=====
@@ -125,8 +122,8 @@ processor. Each bank is referred to as a `node` and for each node Linux
constructs an independent memory management subsystem. A node has its
own set of zones, lists of free and used pages and various statistics
counters. You can find more details about NUMA in
-:ref:`Documentation/mm/numa.rst <numa>` and in
-:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`.
+Documentation/mm/numa.rst` and in
+Documentation/admin-guide/mm/numa_memory_policy.rst.
Page cache
==========
diff --git a/Documentation/admin-guide/mm/damon/index.rst b/Documentation/admin-guide/mm/damon/index.rst
index 05500042f777..3ce3164480c7 100644
--- a/Documentation/admin-guide/mm/damon/index.rst
+++ b/Documentation/admin-guide/mm/damon/index.rst
@@ -1,12 +1,11 @@
.. SPDX-License-Identifier: GPL-2.0
-========================
-Monitoring Data Accesses
-========================
+================================================================
+DAMON: Data Access MONitoring and Access-aware System Operations
+================================================================
-:doc:`DAMON </mm/damon/index>` allows light-weight data access monitoring.
-Using DAMON, users can analyze the memory access patterns of their systems and
-optimize those.
+:doc:`DAMON </mm/damon/index>` is a Linux kernel subsystem for efficient data
+access monitoring and access-aware system operations.
.. toctree::
:maxdepth: 2
@@ -15,3 +14,4 @@ optimize those.
usage
reclaim
lru_sort
+ stat
diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
index c09cace80651..72a943202676 100644
--- a/Documentation/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
@@ -54,7 +54,7 @@ that is built with ``CONFIG_DAMON_LRU_SORT=y``.
To let sysadmins enable or disable it and tune for the given system,
DAMON_LRU_SORT utilizes module parameters. That is, you can put
``damon_lru_sort.<parameter>=<value>`` on the kernel boot command line or write
-proper values to ``/sys/modules/damon_lru_sort/parameters/<parameter>`` files.
+proper values to ``/sys/module/damon_lru_sort/parameters/<parameter>`` files.
Below are the description of each parameter.
@@ -211,6 +211,28 @@ End of target memory region in physical address.
The end physical address of memory region that DAMON_LRU_SORT will do work
against. By default, biggest System RAM is used as the region.
+addr_unit
+---------
+
+A scale factor for memory addresses and bytes.
+
+This parameter is for setting and getting the :ref:`address unit
+<damon_design_addr_unit>` parameter of the DAMON instance for DAMON_RECLAIM.
+
+``monitor_region_start`` and ``monitor_region_end`` should be provided in this
+unit. For example, let's suppose ``addr_unit``, ``monitor_region_start`` and
+``monitor_region_end`` are set as ``1024``, ``0`` and ``10``, respectively.
+Then DAMON_LRU_SORT will work for 10 KiB length of physical address range that
+starts from address zero (``[0 * 1024, 10 * 1024)`` in bytes).
+
+Stat parameters having ``bytes_`` prefix are also in this unit. For example,
+let's suppose values of ``addr_unit``, ``bytes_lru_sort_tried_hot_regions`` and
+``bytes_lru_sorted_hot_regions`` are ``1024``, ``42``, and ``32``,
+respectively. Then it means DAMON_LRU_SORT tried to LRU-sort 42 KiB of hot
+memory and successfully LRU-sorted 32 KiB of the memory in total.
+
+If unsure, use only the default value (``1``) and forget about this.
+
kdamond_pid
-----------
@@ -283,7 +305,7 @@ doesn't make progress and therefore the free memory rate becomes lower than
20%, it asks DAMON_LRU_SORT to do nothing again, so that we can fall back to
the LRU-list based page granularity reclamation. ::
- # cd /sys/modules/damon_lru_sort/parameters
+ # cd /sys/module/damon_lru_sort/parameters
# echo 500 > hot_thres_access_freq
# echo 120000000 > cold_min_age
# echo 10 > quota_ms
diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
index 4f1479a11e63..8eba3da8dcee 100644
--- a/Documentation/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/admin-guide/mm/damon/reclaim.rst
@@ -46,7 +46,7 @@ that is built with ``CONFIG_DAMON_RECLAIM=y``.
To let sysadmins enable or disable it and tune for the given system,
DAMON_RECLAIM utilizes module parameters. That is, you can put
``damon_reclaim.<parameter>=<value>`` on the kernel boot command line or write
-proper values to ``/sys/modules/damon_reclaim/parameters/<parameter>`` files.
+proper values to ``/sys/module/damon_reclaim/parameters/<parameter>`` files.
Below are the description of each parameter.
@@ -117,6 +117,33 @@ milliseconds.
1 second by default.
+quota_mem_pressure_us
+---------------------
+
+Desired level of memory pressure-stall time in microseconds.
+
+While keeping the caps that set by other quotas, DAMON_RECLAIM automatically
+increases and decreases the effective level of the quota aiming this level of
+memory pressure is incurred. System-wide ``some`` memory PSI in microseconds
+per quota reset interval (``quota_reset_interval_ms``) is collected and
+compared to this value to see if the aim is satisfied. Value zero means
+disabling this auto-tuning feature.
+
+Disabled by default.
+
+quota_autotune_feedback
+-----------------------
+
+User-specifiable feedback for auto-tuning of the effective quota.
+
+While keeping the caps that set by other quotas, DAMON_RECLAIM automatically
+increases and decreases the effective level of the quota aiming receiving this
+feedback of value ``10,000`` from the user. DAMON_RECLAIM assumes the feedback
+value and the quota are positively proportional. Value zero means disabling
+this auto-tuning feature.
+
+Disabled by default.
+
wmarks_interval
---------------
@@ -205,6 +232,37 @@ The end physical address of memory region that DAMON_RECLAIM will do work
against. That is, DAMON_RECLAIM will find cold memory regions in this region
and reclaims. By default, biggest System RAM is used as the region.
+addr_unit
+---------
+
+A scale factor for memory addresses and bytes.
+
+This parameter is for setting and getting the :ref:`address unit
+<damon_design_addr_unit>` parameter of the DAMON instance for DAMON_RECLAIM.
+
+``monitor_region_start`` and ``monitor_region_end`` should be provided in this
+unit. For example, let's suppose ``addr_unit``, ``monitor_region_start`` and
+``monitor_region_end`` are set as ``1024``, ``0`` and ``10``, respectively.
+Then DAMON_RECLAIM will work for 10 KiB length of physical address range that
+starts from address zero (``[0 * 1024, 10 * 1024)`` in bytes).
+
+``bytes_reclaim_tried_regions`` and ``bytes_reclaimed_regions`` are also in
+this unit. For example, let's suppose values of ``addr_unit``,
+``bytes_reclaim_tried_regions`` and ``bytes_reclaimed_regions`` are ``1024``,
+``42``, and ``32``, respectively. Then it means DAMON_RECLAIM tried to reclaim
+42 KiB memory and successfully reclaimed 32 KiB memory in total.
+
+If unsure, use only the default value (``1``) and forget about this.
+
+skip_anon
+---------
+
+Skip anonymous pages reclamation.
+
+If this parameter is set as ``Y``, DAMON_RECLAIM does not reclaim anonymous
+pages. By default, ``N``.
+
+
kdamond_pid
-----------
@@ -251,7 +309,7 @@ therefore the free memory rate becomes lower than 20%, it asks DAMON_RECLAIM to
do nothing again, so that we can fall back to the LRU-list based page
granularity reclamation. ::
- # cd /sys/modules/damon_reclaim/parameters
+ # cd /sys/module/damon_reclaim/parameters
# echo 30000000 > min_age
# echo $((1 * 1024 * 1024 * 1024)) > quota_sz
# echo 1000 > quota_reset_interval_ms
diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst
index 4d5ca2c46288..ec8c34b2d32f 100644
--- a/Documentation/admin-guide/mm/damon/start.rst
+++ b/Documentation/admin-guide/mm/damon/start.rst
@@ -7,7 +7,7 @@ Getting Started
This document briefly describes how you can use DAMON by demonstrating its
default user space tool. Please note that this document describes only a part
of its features for brevity. Please refer to the usage `doc
-<https://github.com/awslabs/damo/blob/next/USAGE.md>`_ of the tool for more
+<https://github.com/damonitor/damo/blob/next/USAGE.md>`_ of the tool for more
details.
@@ -26,19 +26,64 @@ User Space Tool
For the demonstration, we will use the default user space tool for DAMON,
called DAMON Operator (DAMO). It is available at
-https://github.com/awslabs/damo. The examples below assume that ``damo`` is on
+https://github.com/damonitor/damo. The examples below assume that ``damo`` is on
your ``$PATH``. It's not mandatory, though.
-Because DAMO is using the debugfs interface (refer to :doc:`usage` for the
-detail) of DAMON, you should ensure debugfs is mounted. Mount it manually as
-below::
+Because DAMO is using the sysfs interface (refer to :doc:`usage` for the
+detail) of DAMON, you should ensure :doc:`sysfs </filesystems/sysfs>` is
+mounted.
- # mount -t debugfs none /sys/kernel/debug/
-or append the following line to your ``/etc/fstab`` file so that your system
-can automatically mount debugfs upon booting::
+Snapshot Data Access Patterns
+=============================
- debugfs /sys/kernel/debug debugfs defaults 0 0
+The commands below show the memory access pattern of a program at the moment of
+the execution. ::
+
+ $ git clone https://github.com/sjp38/masim; cd masim; make
+ $ sudo damo start "./masim ./configs/stairs.cfg --quiet"
+ $ sudo damo report access
+ heatmap: 641111111000000000000000000000000000000000000000000000[...]33333333333333335557984444[...]7
+ # min/max temperatures: -1,840,000,000, 370,010,000, column size: 3.925 MiB
+ 0 addr 86.182 TiB size 8.000 KiB access 0 % age 14.900 s
+ 1 addr 86.182 TiB size 8.000 KiB access 60 % age 0 ns
+ 2 addr 86.182 TiB size 3.422 MiB access 0 % age 4.100 s
+ 3 addr 86.182 TiB size 2.004 MiB access 95 % age 2.200 s
+ 4 addr 86.182 TiB size 29.688 MiB access 0 % age 14.100 s
+ 5 addr 86.182 TiB size 29.516 MiB access 0 % age 16.700 s
+ 6 addr 86.182 TiB size 29.633 MiB access 0 % age 17.900 s
+ 7 addr 86.182 TiB size 117.652 MiB access 0 % age 18.400 s
+ 8 addr 126.990 TiB size 62.332 MiB access 0 % age 9.500 s
+ 9 addr 126.990 TiB size 13.980 MiB access 0 % age 5.200 s
+ 10 addr 126.990 TiB size 9.539 MiB access 100 % age 3.700 s
+ 11 addr 126.990 TiB size 16.098 MiB access 0 % age 6.400 s
+ 12 addr 127.987 TiB size 132.000 KiB access 0 % age 2.900 s
+ total size: 314.008 MiB
+ $ sudo damo stop
+
+The first command of the above example downloads and builds an artificial
+memory access generator program called ``masim``. The second command asks DAMO
+to start the program via the given command and make DAMON monitors the newly
+started process. The third command retrieves the current snapshot of the
+monitored access pattern of the process from DAMON and shows the pattern in a
+human readable format.
+
+The first line of the output shows the relative access temperature (hotness) of
+the regions in a single row hetmap format. Each column on the heatmap
+represents regions of same size on the monitored virtual address space. The
+position of the colun on the row and the number on the column represents the
+relative location and access temperature of the region. ``[...]`` means
+unmapped huge regions on the virtual address spaces. The second line shows
+additional information for better understanding the heatmap.
+
+Each line of the output from the third line shows which virtual address range
+(``addr XX size XX``) of the process is how frequently (``access XX %``)
+accessed for how long time (``age XX``). For example, the evelenth region of
+~9.5 MiB size is being most frequently accessed for last 3.7 seconds. Finally,
+the fourth command stops DAMON.
+
+Note that DAMON can monitor not only virtual address spaces but multiple types
+of address spaces including the physical address space.
Recording Data Access Patterns
@@ -47,12 +92,11 @@ Recording Data Access Patterns
The commands below record the memory access patterns of a program and save the
monitoring results to a file. ::
- $ git clone https://github.com/sjp38/masim
- $ cd masim; make; ./masim ./configs/zigzag.cfg &
+ $ ./masim ./configs/zigzag.cfg &
$ sudo damo record -o damon.data $(pidof masim)
-The first two lines of the commands download an artificial memory access
-generator program and run it in the background. The generator will repeatedly
+The line of the commands run the artificial memory access
+generator program again. The generator will repeatedly
access two 100 MiB sized memory regions one by one. You can substitute this
with your real workload. The last line asks ``damo`` to record the access
pattern in the ``damon.data`` file.
@@ -64,7 +108,7 @@ Visualizing Recorded Patterns
You can visualize the pattern in a heatmap, showing which memory region
(x-axis) got accessed when (y-axis) and how frequently (number).::
- $ sudo damo report heats --heatmap stdout
+ $ sudo damo report heatmap
22222222222222222222222222222222222222211111111111111111111111111111111111111100
44444444444444444444444444444444444444434444444444444444444444444444444444443200
44444444444444444444444444444444444444433444444444444444444444444444444444444200
@@ -126,9 +170,9 @@ set size has chronologically changed.::
Data Access Pattern Aware Memory Management
===========================================
-Below three commands make every memory region of size >=4K that doesn't
-accessed for >=60 seconds in your workload to be swapped out. ::
+Below command makes every memory region of size >=4K that has not accessed for
+>=60 seconds in your workload to be swapped out. ::
- $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme
- $ echo "4K max 0 0 60s max pageout" >> test_scheme
- $ damo schemes -c test_scheme <pid of your workload>
+ $ sudo damo start --damos_access_rate 0 0 --damos_sz_region 4K max \
+ --damos_age 60s max --damos_action pageout \
+ --target_pid <pid of your workload>
diff --git a/Documentation/admin-guide/mm/damon/stat.rst b/Documentation/admin-guide/mm/damon/stat.rst
new file mode 100644
index 000000000000..e5a5a2c4f803
--- /dev/null
+++ b/Documentation/admin-guide/mm/damon/stat.rst
@@ -0,0 +1,86 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===================================
+Data Access Monitoring Results Stat
+===================================
+
+Data Access Monitoring Results Stat (DAMON_STAT) is a static kernel module that
+is aimed to be used for simple access pattern monitoring. It monitors accesses
+on the system's entire physical memory using DAMON, and provides simplified
+access monitoring results statistics, namely idle time percentiles and
+estimated memory bandwidth.
+
+.. _damon_stat_monitoring_accuracy_overhead:
+
+Monitoring Accuracy and Overhead
+================================
+
+DAMON_STAT uses monitoring intervals :ref:`auto-tuning
+<damon_design_monitoring_intervals_autotuning>` to make its accuracy high and
+overhead minimum. It auto-tunes the intervals aiming 4 % of observable access
+events to be captured in each snapshot, while limiting the resulting sampling
+interval to be 5 milliseconds in minimum and 10 seconds in maximum. On a few
+production server systems, it resulted in consuming only 0.x % single CPU time,
+while capturing reasonable quality of access patterns. The tuning-resulting
+intervals can be retrieved via ``aggr_interval_us`` :ref:`parameter
+<damon_stat_aggr_interval_us>`.
+
+Interface: Module Parameters
+============================
+
+To use this feature, you should first ensure your system is running on a kernel
+that is built with ``CONFIG_DAMON_STAT=y``. The feature can be enabled by
+default at build time, by setting ``CONFIG_DAMON_STAT_ENABLED_DEFAULT`` true.
+
+To let sysadmins enable or disable it at boot and/or runtime, and read the
+monitoring results, DAMON_STAT provides module parameters. Following
+sections are descriptions of the parameters.
+
+enabled
+-------
+
+Enable or disable DAMON_STAT.
+
+You can enable DAMON_STAT by setting the value of this parameter as ``Y``.
+Setting it as ``N`` disables DAMON_STAT. The default value is set by
+``CONFIG_DAMON_STAT_ENABLED_DEFAULT`` build config option.
+
+.. _damon_stat_aggr_interval_us:
+
+aggr_interval_us
+----------------
+
+Auto-tuned aggregation time interval in microseconds.
+
+Users can read the aggregation interval of DAMON that is being used by the
+DAMON instance for DAMON_STAT. It is :ref:`auto-tuned
+<damon_stat_monitoring_accuracy_overhead>` and therefore the value is
+dynamically changed.
+
+estimated_memory_bandwidth
+--------------------------
+
+Estimated memory bandwidth consumption (bytes per second) of the system.
+
+DAMON_STAT reads observed access events on the current DAMON results snapshot
+and converts it to memory bandwidth consumption estimation in bytes per second.
+The resulting metric is exposed to user via this read-only parameter. Because
+DAMON uses sampling, this is only an estimation of the access intensity rather
+than accurate memory bandwidth.
+
+memory_idle_ms_percentiles
+--------------------------
+
+Per-byte idle time (milliseconds) percentiles of the system.
+
+DAMON_STAT calculates how long each byte of the memory was not accessed until
+now (idle time), based on the current DAMON results snapshot. For regions
+having access frequency (nr_accesses) larger than zero, how long the current
+access frequency level was kept multiplied by ``-1`` becomes the idlee time of
+every byte of the region. If a region has zero access frequency (nr_accesses),
+how long the region was keeping the zero access frequency (age) becomes the
+idle time of every byte of the region. Then, DAMON_STAT exposes the
+percentiles of the idle time values via this read-only parameter. Reading the
+parameter returns 101 idle time values in milliseconds, separated by comma.
+Each value represents 0-th, 1st, 2nd, 3rd, ..., 99th and 100th percentile idle
+times.
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index ca91ecc29078..9991dad60fcf 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -7,28 +7,19 @@ Detailed Usages
DAMON provides below interfaces for different users.
- *DAMON user space tool.*
- `This <https://github.com/awslabs/damo>`_ is for privileged people such as
+ `This <https://github.com/damonitor/damo>`_ is for privileged people such as
system administrators who want a just-working human-friendly interface.
Using this, users can use the DAMON’s major features in a human-friendly way.
- It may not be highly tuned for special cases, though. It supports both
- virtual and physical address spaces monitoring. For more detail, please
- refer to its `usage document
- <https://github.com/awslabs/damo/blob/next/USAGE.md>`_.
+ It may not be highly tuned for special cases, though. For more detail,
+ please refer to its `usage document
+ <https://github.com/damonitor/damo/blob/next/USAGE.md>`_.
- *sysfs interface.*
:ref:`This <sysfs_interface>` is for privileged user space programmers who
want more optimized use of DAMON. Using this, users can use DAMON’s major
features by reading from and writing to special sysfs files. Therefore,
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
- <https://github.com/awslabs/damo>`_ is one example of such programs. It
- supports both virtual and physical address spaces monitoring. Note that this
- interface provides only simple :ref:`statistics <damos_stats>` for the
- monitoring results. For detailed monitoring results, DAMON provides a
- :ref:`tracepoint <tracepoint>`.
-- *debugfs interface.*
- :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
- <sysfs_interface>`. This will be removed after next LTS kernel is released,
- so users should move to the :ref:`sysfs interface <sysfs_interface>`.
+ <https://github.com/damonitor/damo>`_ is one example of such programs.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
@@ -62,110 +53,164 @@ Files Hierarchy
The files hierarchy of DAMON sysfs interface is shown below. In the below
figure, parents-children relations are represented with indentations, each
directory is having ``/`` suffix, and files in each directory are separated by
-comma (","). ::
-
- /sys/kernel/mm/damon/admin
- │ kdamonds/nr_kdamonds
- │ │ 0/state,pid
- │ │ │ contexts/nr_contexts
- │ │ │ │ 0/avail_operations,operations
- │ │ │ │ │ monitoring_attrs/
+comma (",").
+
+.. parsed-literal::
+
+ :ref:`/sys/kernel/mm/damon <sysfs_root>`/admin
+ │ :ref:`kdamonds <sysfs_kdamonds>`/nr_kdamonds
+ │ │ :ref:`0 <sysfs_kdamond>`/state,pid,refresh_ms
+ │ │ │ :ref:`contexts <sysfs_contexts>`/nr_contexts
+ │ │ │ │ :ref:`0 <sysfs_context>`/avail_operations,operations,addr_unit
+ │ │ │ │ │ :ref:`monitoring_attrs <sysfs_monitoring_attrs>`/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
+ │ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
│ │ │ │ │ │ nr_regions/min,max
- │ │ │ │ │ targets/nr_targets
- │ │ │ │ │ │ 0/pid_target
- │ │ │ │ │ │ │ regions/nr_regions
- │ │ │ │ │ │ │ │ 0/start,end
+ │ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
+ │ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target,obsolete_target
+ │ │ │ │ │ │ │ :ref:`regions <sysfs_regions>`/nr_regions
+ │ │ │ │ │ │ │ │ :ref:`0 <sysfs_region>`/start,end
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
- │ │ │ │ │ schemes/nr_schemes
- │ │ │ │ │ │ 0/action
- │ │ │ │ │ │ │ access_pattern/
+ │ │ │ │ │ :ref:`schemes <sysfs_schemes>`/nr_schemes
+ │ │ │ │ │ │ :ref:`0 <sysfs_scheme>`/action,target_nid,apply_interval_us
+ │ │ │ │ │ │ │ :ref:`access_pattern <sysfs_access_pattern>`/
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
- │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms
+ │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
- │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
- │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
+ │ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals
+ │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
+ │ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low
+ │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters
+ │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max
+ │ │ │ │ │ │ │ :ref:`dests <damon_sysfs_dests>`/nr_dests
+ │ │ │ │ │ │ │ │ 0/id,weight
+ │ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds
+ │ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions>`/total_bytes
+ │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed
+ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ ...
│ │ ...
+.. _sysfs_root:
+
Root
----
The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it
has one directory named ``admin``. The directory contains the files for
-privileged user space programs' control of DAMON. User space tools or deamons
+privileged user space programs' control of DAMON. User space tools or daemons
having the root permission could use this directory.
+.. _sysfs_kdamonds:
+
kdamonds/
---------
-The monitoring-related information including request specifications and results
-are called DAMON context. DAMON executes each context with a kernel thread
-called kdamond, and multiple kdamonds could run in parallel.
-
Under the ``admin`` directory, one directory, ``kdamonds``, which has files for
-controlling the kdamonds exist. In the beginning, this directory has only one
-file, ``nr_kdamonds``. Writing a number (``N``) to the file creates the number
-of child directories named ``0`` to ``N-1``. Each directory represents each
+controlling the kdamonds (refer to
+:ref:`design <damon_design_execution_model_and_data_structures>` for more
+details) exists. In the beginning, this directory has only one file,
+``nr_kdamonds``. Writing a number (``N``) to the file creates the number of
+child directories named ``0`` to ``N-1``. Each directory represents each
kdamond.
+.. _sysfs_kdamond:
+
kdamonds/<N>/
-------------
-In each kdamond directory, two files (``state`` and ``pid``) and one directory
-(``contexts``) exist.
+In each kdamond directory, three files (``state``, ``pid`` and ``refresh_ms``)
+and one directory (``contexts``) exist.
Reading ``state`` returns ``on`` if the kdamond is currently running, or
-``off`` if it is not running. Writing ``on`` or ``off`` makes the kdamond be
-in the state. Writing ``commit`` to the ``state`` file makes kdamond reads the
-user inputs in the sysfs files except ``state`` file again. Writing
-``update_schemes_stats`` to ``state`` file updates the contents of stats files
-for each DAMON-based operation scheme of the kdamond. For details of the
-stats, please refer to :ref:`stats section <sysfs_schemes_stats>`.
+``off`` if it is not running.
+
+Users can write below commands for the kdamond to the ``state`` file.
+
+- ``on``: Start running.
+- ``off``: Stop running.
+- ``commit``: Read the user inputs in the sysfs files except ``state`` file
+ again. Monitoring :ref:`target region <sysfs_regions>` inputs are also be
+ ignored if no target region is specified.
+- ``update_tuned_intervals``: Update the contents of ``sample_us`` and
+ ``aggr_us`` files of the kdamond with the auto-tuning applied ``sampling
+ interval`` and ``aggregation interval`` for the files. Please refer to
+ :ref:`intervals_goal section <damon_usage_sysfs_monitoring_intervals_goal>`
+ for more details.
+- ``commit_schemes_quota_goals``: Read the DAMON-based operation schemes'
+ :ref:`quota goals <sysfs_schemes_quota_goals>`.
+- ``update_schemes_stats``: Update the contents of stats files for each
+ DAMON-based operation scheme of the kdamond. For details of the stats,
+ please refer to :ref:`stats section <sysfs_schemes_stats>`.
+- ``update_schemes_tried_regions``: Update the DAMON-based operation scheme
+ action tried regions directory for each DAMON-based operation scheme of the
+ kdamond. For details of the DAMON-based operation scheme action tried
+ regions directory, please refer to
+ :ref:`tried_regions section <sysfs_schemes_tried_regions>`.
+- ``update_schemes_tried_bytes``: Update only ``.../tried_regions/total_bytes``
+ files.
+- ``clear_schemes_tried_regions``: Clear the DAMON-based operating scheme
+ action tried regions directory for each DAMON-based operation scheme of the
+ kdamond.
+- ``update_schemes_effective_quotas``: Update the contents of
+ ``effective_bytes`` files for each DAMON-based operation scheme of the
+ kdamond. For more details, refer to :ref:`quotas directory <sysfs_quotas>`.
If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread.
+Users can ask the kernel to periodically update files showing auto-tuned
+parameters and DAMOS stats instead of manually writing
+``update_tuned_intervals`` like keywords to ``state`` file. For this, users
+should write the desired update time interval in milliseconds to ``refresh_ms``
+file. If the interval is zero, the periodic update is disabled. Reading the
+file shows currently set time interval.
+
``contexts`` directory contains files for controlling the monitoring contexts
that this kdamond will execute.
+.. _sysfs_contexts:
+
kdamonds/<N>/contexts/
----------------------
In the beginning, this directory has only one file, ``nr_contexts``. Writing a
number (``N``) to the file creates the number of child directories named as
-``0`` to ``N-1``. Each directory represents each monitoring context. At the
-moment, only one context per kdamond is supported, so only ``0`` or ``1`` can
-be written to the file.
+``0`` to ``N-1``. Each directory represents each monitoring context (refer to
+:ref:`design <damon_design_execution_model_and_data_structures>` for more
+details). At the moment, only one context per kdamond is supported, so only
+``0`` or ``1`` can be written to the file.
+
+.. _sysfs_context:
contexts/<N>/
-------------
-In each context directory, two files (``avail_operations`` and ``operations``)
-and three directories (``monitoring_attrs``, ``targets``, and ``schemes``)
-exist.
+In each context directory, three files (``avail_operations``, ``operations``
+and ``addr_unit``) and three directories (``monitoring_attrs``, ``targets``,
+and ``schemes``) exist.
-DAMON supports multiple types of monitoring operations, including those for
-virtual address space and the physical address space. You can get the list of
-available monitoring operations set on the currently running kernel by reading
+DAMON supports multiple types of :ref:`monitoring operations
+<damon_design_configurable_operations_set>`, including those for virtual address
+space and the physical address space. You can get the list of available
+monitoring operations set on the currently running kernel by reading
``avail_operations`` file. Based on the kernel configuration, the file will
-list some or all of below keywords.
-
- - vaddr: Monitor virtual address spaces of specific processes
- - fvaddr: Monitor fixed virtual address ranges
- - paddr: Monitor the physical address space of the system
-
-Please refer to :ref:`regions sysfs directory <sysfs_regions>` for detailed
-differences between the operations sets in terms of the monitoring target
-regions.
+list different available operation sets. Please refer to the :ref:`design
+<damon_operations_set>` for the list of all available operation sets and their
+brief explanations.
You can set and get what type of monitoring operations DAMON will use for the
context by writing one of the keywords listed in ``avail_operations`` file and
reading from the ``operations`` file.
+``addr_unit`` file is for setting and getting the :ref:`address unit
+<damon_design_addr_unit>` parameter of the operations set.
+
+.. _sysfs_monitoring_attrs:
+
contexts/<N>/monitoring_attrs/
------------------------------
@@ -187,6 +232,27 @@ writing to and rading from the files.
For more details about the intervals and monitoring regions range, please refer
to the Design document (:doc:`/mm/damon/design`).
+.. _damon_usage_sysfs_monitoring_intervals_goal:
+
+contexts/<N>/monitoring_attrs/intervals/intervals_goal/
+-------------------------------------------------------
+
+Under the ``intervals`` directory, one directory for automated tuning of
+``sample_us`` and ``aggr_us``, namely ``intervals_goal`` directory also exists.
+Under the directory, four files for the auto-tuning control, namely
+``access_bp``, ``aggrs``, ``min_sample_us`` and ``max_sample_us`` exist.
+Please refer to the :ref:`design document of the feature
+<damon_design_monitoring_intervals_autotuning>` for the internal of the tuning
+mechanism. Reading and writing the four files under ``intervals_goal``
+directory shows and updates the tuning parameters that described in the
+:ref:design doc <damon_design_monitoring_intervals_autotuning>` with the same
+names. The tuning starts with the user-set ``sample_us`` and ``aggr_us``. The
+tuning-applied current values of the two intervals can be read from the
+``sample_us`` and ``aggr_us`` files after writing ``update_tuned_intervals`` to
+the ``state`` file.
+
+.. _sysfs_targets:
+
contexts/<N>/targets/
---------------------
@@ -194,32 +260,35 @@ In the beginning, this directory has only one file, ``nr_targets``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
to ``N-1``. Each directory represents each monitoring target.
+.. _sysfs_target:
+
targets/<N>/
------------
-In each target directory, one file (``pid_target``) and one directory
-(``regions``) exist.
+In each target directory, two files (``pid_target`` and ``obsolete_target``)
+and one directory (``regions``) exist.
If you wrote ``vaddr`` to the ``contexts/<N>/operations``, each target should
be a process. You can specify the process to DAMON by writing the pid of the
process to the ``pid_target`` file.
+Users can selectively remove targets in the middle of the targets array by
+writing non-zero value to ``obsolete_target`` file and committing it (writing
+``commit`` to ``state`` file). DAMON will remove the matching targets from its
+internal targets array. Users are responsible to construct target directories
+again, so that those correctly represent the changed internal targets array.
+
+
.. _sysfs_regions:
targets/<N>/regions
-------------------
-When ``vaddr`` monitoring operations set is being used (``vaddr`` is written to
-the ``contexts/<N>/operations`` file), DAMON automatically sets and updates the
-monitoring target regions so that entire memory mappings of target processes
-can be covered. However, users could want to set the initial monitoring region
-to specific address ranges.
-
-In contrast, DAMON do not automatically sets and updates the monitoring target
-regions when ``fvaddr`` or ``paddr`` monitoring operations sets are being used
-(``fvaddr`` or ``paddr`` have written to the ``contexts/<N>/operations``).
-Therefore, users should set the monitoring target regions by themselves in the
-cases.
+In case of ``fvaddr`` or ``paddr`` monitoring operations sets, users are
+required to set the monitoring target address ranges. In case of ``vaddr``
+operations set, it is not mandatory, but users can optionally set the initial
+monitoring region to specific address ranges. Please refer to the :ref:`design
+<damon_design_vaddr_target_regions_construction>` for more details.
For such cases, users can explicitly set the initial monitoring target regions
as they want, by writing proper values to the files under this directory.
@@ -228,6 +297,13 @@ In the beginning, this directory has only one file, ``nr_regions``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
to ``N-1``. Each directory represents each initial monitoring target region.
+If ``nr_regions`` is zero when committing new DAMON parameters online (writing
+``commit`` to ``state`` file of :ref:`kdamond <sysfs_kdamond>`), the commit
+logic ignores the target regions. In other words, the current monitoring
+results for the target are preserved.
+
+.. _sysfs_region:
+
regions/<N>/
------------
@@ -235,92 +311,129 @@ In each region directory, you will find two files (``start`` and ``end``). You
can set and get the start and end addresses of the initial monitoring target
region by writing to and reading from the files, respectively.
+Each region should not overlap with others. ``end`` of directory ``N`` should
+be equal or smaller than ``start`` of directory ``N+1``.
+
+.. _sysfs_schemes:
+
contexts/<N>/schemes/
---------------------
-For usual DAMON-based data access aware memory management optimizations, users
-would normally want the system to apply a memory management action to a memory
-region of a specific access pattern. DAMON receives such formalized operation
-schemes from the user and applies those to the target memory regions. Users
-can get and set the schemes by reading from and writing to files under this
-directory.
+The directory for DAMON-based Operation Schemes (:ref:`DAMOS
+<damon_design_damos>`). Users can get and set the schemes by reading from and
+writing to files under this directory.
In the beginning, this directory has only one file, ``nr_schemes``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
to ``N-1``. Each directory represents each DAMON-based operation scheme.
+.. _sysfs_scheme:
+
schemes/<N>/
------------
-In each scheme directory, four directories (``access_pattern``, ``quotas``,
-``watermarks``, and ``stats``) and one file (``action``) exist.
+In each scheme directory, eight directories (``access_pattern``, ``quotas``,
+``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``dests``,
+``stats``, and ``tried_regions``) and three files (``action``, ``target_nid``
+and ``apply_interval``) exist.
+
+The ``action`` file is for setting and getting the scheme's :ref:`action
+<damon_design_damos_action>`. The keywords that can be written to and read
+from the file and their meaning are same to those of the list on
+:ref:`design doc <damon_design_damos_action>`.
-The ``action`` file is for setting and getting what action you want to apply to
-memory regions having specific access pattern of the interest. The keywords
-that can be written to and read from the file and their meaning are as below.
+The ``target_nid`` file is for setting the migration target node, which is
+only meaningful when the ``action`` is either ``migrate_hot`` or
+``migrate_cold``.
- - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``
- - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``
- - ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
- - ``lru_prio``: Prioritize the region on its LRU lists.
- - ``lru_deprio``: Deprioritize the region on its LRU lists.
- - ``stat``: Do nothing but count the statistics
+The ``apply_interval_us`` file is for setting and getting the scheme's
+:ref:`apply_interval <damon_design_damos>` in microseconds.
+
+.. _sysfs_access_pattern:
schemes/<N>/access_pattern/
---------------------------
-The target access pattern of each DAMON-based operation scheme is constructed
-with three ranges including the size of the region in bytes, number of
-monitored accesses per aggregate interval, and number of aggregated intervals
-for the age of the region.
+The directory for the target access :ref:`pattern
+<damon_design_damos_access_pattern>` of the given DAMON-based operation scheme.
Under the ``access_pattern`` directory, three directories (``sz``,
``nr_accesses``, and ``age``) each having two files (``min`` and ``max``)
exist. You can set and get the access pattern for the given scheme by writing
to and reading from the ``min`` and ``max`` files under ``sz``,
-``nr_accesses``, and ``age`` directories, respectively.
+``nr_accesses``, and ``age`` directories, respectively. Note that the ``min``
+and the ``max`` form a closed interval.
+
+.. _sysfs_quotas:
schemes/<N>/quotas/
-------------------
-Optimal ``target access pattern`` for each ``action`` is workload dependent, so
-not easy to find. Worse yet, setting a scheme of some action too aggressive
-can cause severe overhead. To avoid such overhead, users can limit time and
-size quota for each scheme. In detail, users can ask DAMON to try to use only
-up to specific time (``time quota``) for applying the action, and to apply the
-action to only up to specific amount (``size quota``) of memory regions having
-the target access pattern within a given time interval (``reset interval``).
+The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given
+DAMON-based operation scheme.
-When the quota limit is expected to be exceeded, DAMON prioritizes found memory
-regions of the ``target access pattern`` based on their size, access frequency,
-and age. For personalized prioritization, users can set the weights for the
-three properties.
-
-Under ``quotas`` directory, three files (``ms``, ``bytes``,
-``reset_interval_ms``) and one directory (``weights``) having three files
-(``sz_permil``, ``nr_accesses_permil``, and ``age_permil``) in it exist.
+Under ``quotas`` directory, four files (``ms``, ``bytes``,
+``reset_interval_ms``, ``effective_bytes``) and two directories (``weights`` and
+``goals``) exist.
You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and
``reset interval`` in milliseconds by writing the values to the three files,
-respectively. You can also set the prioritization weights for size, access
-frequency, and age in per-thousand unit by writing the values to the three
-files under the ``weights`` directory.
+respectively. Then, DAMON tries to use only up to ``time quota`` milliseconds
+for applying the ``action`` to memory regions of the ``access_pattern``, and to
+apply the action to only up to ``bytes`` bytes of memory regions within the
+``reset_interval_ms``. Setting both ``ms`` and ``bytes`` zero disables the
+quota limits unless at least one :ref:`goal <sysfs_schemes_quota_goals>` is
+set.
+
+The time quota is internally transformed to a size quota. Between the
+transformed size quota and user-specified size quota, smaller one is applied.
+Based on the user-specified :ref:`goal <sysfs_schemes_quota_goals>`, the
+effective size quota is further adjusted. Reading ``effective_bytes`` returns
+the current effective size quota. The file is not updated in real time, so
+users should ask DAMON sysfs interface to update the content of the file for
+the stats by writing a special keyword, ``update_schemes_effective_quotas`` to
+the relevant ``kdamonds/<N>/state`` file.
+
+Under ``weights`` directory, three files (``sz_permil``,
+``nr_accesses_permil``, and ``age_permil``) exist.
+You can set the :ref:`prioritization weights
+<damon_design_damos_quotas_prioritization>` for size, access frequency, and age
+in per-thousand unit by writing the values to the three files under the
+``weights`` directory.
+
+.. _sysfs_schemes_quota_goals:
+
+schemes/<N>/quotas/goals/
+-------------------------
+
+The directory for the :ref:`automatic quota tuning goals
+<damon_design_damos_quotas_auto_tuning>` of the given DAMON-based operation
+scheme.
+
+In the beginning, this directory has only one file, ``nr_goals``. Writing a
+number (``N``) to the file creates the number of child directories named ``0``
+to ``N-1``. Each directory represents each goal and current achievement.
+Among the multiple feedback, the best one is used.
+
+Each goal directory contains five files, namely ``target_metric``,
+``target_value``, ``current_value`` ``nid`` and ``path``. Users can set and
+get the five parameters for the quota auto-tuning goals that specified on the
+:ref:`design doc <damon_design_damos_quotas_auto_tuning>` by writing to and
+reading from each of the files. Note that users should further write
+``commit_schemes_quota_goals`` to the ``state`` file of the :ref:`kdamond
+directory <sysfs_kdamond>` to pass the feedback to DAMON.
+
+.. _sysfs_watermarks:
schemes/<N>/watermarks/
-----------------------
-To allow easy activation and deactivation of each scheme based on system
-status, DAMON provides a feature called watermarks. The feature receives five
-values called ``metric``, ``interval``, ``high``, ``mid``, and ``low``. The
-``metric`` is the system metric such as free memory ratio that can be measured.
-If the metric value of the system is higher than the value in ``high`` or lower
-than ``low`` at the memoent, the scheme is deactivated. If the value is lower
-than ``mid``, the scheme is activated.
+The directory for the :ref:`watermarks <damon_design_damos_watermarks>` of the
+given DAMON-based operation scheme.
Under the watermarks directory, five files (``metric``, ``interval_us``,
-``high``, ``mid``, and ``low``) for setting each value exist. You can set and
+``high``, ``mid``, and ``low``) for setting the metric, the time interval
+between check of the metric, and the three watermarks exist. You can set and
get the five values by writing to the files, respectively.
Keywords and meanings of those that can be written to the ``metric`` file are
@@ -331,23 +444,150 @@ as below.
The ``interval`` should written in microseconds unit.
+.. _sysfs_filters:
+
+schemes/<N>/{core\_,ops\_,}filters/
+-----------------------------------
+
+Directories for :ref:`filters <damon_design_damos_filters>` of the given
+DAMON-based operation scheme.
+
+``core_filters`` and ``ops_filters`` directories are for the filters handled by
+the DAMON core layer and operations set layer, respectively. ``filters``
+directory can be used for installing filters regardless of their handled
+layers. Filters that requested by ``core_filters`` and ``ops_filters`` will be
+installed before those of ``filters``. All three directories have same files.
+
+Use of ``filters`` directory can make expecting evaluation orders of given
+filters with the files under directory bit confusing. Users are hence
+recommended to use ``core_filters`` and ``ops_filters`` directories. The
+``filters`` directory could be deprecated in future.
+
+In the beginning, the directory has only one file, ``nr_filters``. Writing a
+number (``N``) to the file creates the number of child directories named ``0``
+to ``N-1``. Each directory represents each filter. The filters are evaluated
+in the numeric order.
+
+Each filter directory contains nine files, namely ``type``, ``matching``,
+``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, ``min``, ``max``
+and ``target_idx``. To ``type`` file, you can write the type of the filter.
+Refer to :ref:`the design doc <damon_design_damos_filters>` for available type
+names, their meaning and on what layer those are handled.
+
+For ``memcg`` type, you can specify the memory cgroup of the interest by
+writing the path of the memory cgroup from the cgroups mount point to
+``memcg_path`` file. For ``addr`` type, you can specify the start and end
+address of the range (open-ended interval) to ``addr_start`` and ``addr_end``
+files, respectively. For ``hugepage_size`` type, you can specify the minimum
+and maximum size of the range (closed interval) to ``min`` and ``max`` files,
+respectively. For ``target`` type, you can specify the index of the target
+between the list of the DAMON context's monitoring targets list to
+``target_idx`` file.
+
+You can write ``Y`` or ``N`` to ``matching`` file to specify whether the filter
+is for memory that matches the ``type``. You can write ``Y`` or ``N`` to
+``allow`` file to specify if applying the action to the memory that satisfies
+the ``type`` and ``matching`` should be allowed or not.
+
+For example, below restricts a DAMOS action to be applied to only non-anonymous
+pages of all memory cgroups except ``/having_care_already``.::
+
+ # cd ops_filters/0/
+ # echo 2 > nr_filters
+ # # disallow anonymous pages
+ echo anon > 0/type
+ echo Y > 0/matching
+ echo N > 0/allow
+ # # further filter out all cgroups except one at '/having_care_already'
+ echo memcg > 1/type
+ echo /having_care_already > 1/memcg_path
+ echo Y > 1/matching
+ echo N > 1/allow
+
+Refer to the :ref:`DAMOS filters design documentation
+<damon_design_damos_filters>` for more details including how multiple filters
+of different ``allow`` works, when each of the filters are supported, and
+differences on stats.
+
+.. _damon_sysfs_dests:
+
+schemes/<N>/dests/
+------------------
+
+Directory for specifying the destinations of given DAMON-based operation
+scheme's action. This directory is ignored if the action of the given scheme
+is not supporting multiple destinations. Only ``DAMOS_MIGRATE_{HOT,COLD}``
+actions are supporting multiple destinations.
+
+In the beginning, the directory has only one file, ``nr_dests``. Writing a
+number (``N``) to the file creates the number of child directories named ``0``
+to ``N-1``. Each directory represents each action destination.
+
+Each destination directory contains two files, namely ``id`` and ``weight``.
+Users can write and read the identifier of the destination to ``id`` file.
+For ``DAMOS_MIGRATE_{HOT,COLD}`` actions, the migrate destination node's node
+id should be written to ``id`` file. Users can write and read the weight of
+the destination among the given destinations to the ``weight`` file. The
+weight can be an arbitrary integer. When DAMOS apply the action to each entity
+of the memory region, it will select the destination of the action based on the
+relative weights of the destinations.
+
.. _sysfs_schemes_stats:
schemes/<N>/stats/
------------------
-DAMON counts the total number and bytes of regions that each scheme is tried to
-be applied, the two numbers for the regions that each scheme is successfully
-applied, and the total number of the quota limit exceeds. This statistics can
-be used for online analysis or tuning of the schemes.
+DAMON counts statistics for each scheme. This statistics can be used for
+online analysis or tuning of the schemes. Refer to :ref:`design doc
+<damon_design_damos_stat>` for more details about the stats.
The statistics can be retrieved by reading the files under ``stats`` directory
-(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and
-``qt_exceeds``), respectively. The files are not updated in real time, so you
-should ask DAMON sysfs interface to updte the content of the files for the
-stats by writing a special keyword, ``update_schemes_stats`` to the relevant
+(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``,
+``sz_ops_filter_passed``, and ``qt_exceeds``), respectively. The files are not
+updated in real time, so you should ask DAMON sysfs interface to update the
+content of the files for the stats by writing a special keyword,
+``update_schemes_stats`` to the relevant ``kdamonds/<N>/state`` file.
+
+.. _sysfs_schemes_tried_regions:
+
+schemes/<N>/tried_regions/
+--------------------------
+
+This directory initially has one file, ``total_bytes``.
+
+When a special keyword, ``update_schemes_tried_regions``, is written to the
+relevant ``kdamonds/<N>/state`` file, DAMON updates the ``total_bytes`` file so
+that reading it returns the total size of the scheme tried regions, and creates
+directories named integer starting from ``0`` under this directory. Each
+directory contains files exposing detailed information about each of the memory
+region that the corresponding scheme's ``action`` has tried to be applied under
+this directory, during next :ref:`apply interval <damon_design_damos>` of the
+corresponding scheme. The information includes address range, ``nr_accesses``,
+and ``age`` of the region.
+
+Writing ``update_schemes_tried_bytes`` to the relevant ``kdamonds/<N>/state``
+file will only update the ``total_bytes`` file, and will not create the
+subdirectories.
+
+The directories will be removed when another special keyword,
+``clear_schemes_tried_regions``, is written to the relevant
``kdamonds/<N>/state`` file.
+The expected usage of this directory is investigations of schemes' behaviors,
+and query-like efficient data access monitoring results retrievals. For the
+latter use case, in particular, users can set the ``action`` as ``stat`` and
+set the ``access pattern`` as their interested pattern that they want to query.
+
+.. _sysfs_schemes_tried_region:
+
+tried_regions/<N>/
+------------------
+
+In each region directory, you will find five files (``start``, ``end``,
+``nr_accesses``, ``age``, and ``sz_filter_passed``). Reading the files will
+show the properties of the region that corresponding DAMON-based operation
+scheme ``action`` has tried to be applied.
+
Example
~~~~~~~
@@ -385,313 +625,60 @@ memory rate becomes larger than 60%, or lower than 30%". ::
# echo 300 > watermarks/low
Please note that it's highly recommended to use user space tools like `damo
-<https://github.com/awslabs/damo>`_ rather than manually reading and writing
+<https://github.com/damonitor/damo>`_ rather than manually reading and writing
the files as above. Above is only for an example.
-.. _debugfs_interface:
-
-debugfs Interface
-=================
-
-DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
-``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
-``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
-
-
-Attributes
-----------
-
-Users can get and set the ``sampling interval``, ``aggregation interval``,
-``update interval``, and min/max number of monitoring target regions by
-reading from and writing to the ``attrs`` file. To know about the monitoring
-attributes in detail, please refer to the :doc:`/mm/damon/design`. For
-example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and
-1000, and then check it again::
-
- # cd <debugfs>/damon
- # echo 5000 100000 1000000 10 1000 > attrs
- # cat attrs
- 5000 100000 1000000 10 1000
-
-
-Target IDs
-----------
-
-Some types of address spaces supports multiple monitoring target. For example,
-the virtual memory address spaces monitoring can have multiple processes as the
-monitoring targets. Users can set the targets by writing relevant id values of
-the targets to, and get the ids of the current targets by reading from the
-``target_ids`` file. In case of the virtual address spaces monitoring, the
-values should be pids of the monitoring target processes. For example, below
-commands set processes having pids 42 and 4242 as the monitoring targets and
-check it again::
-
- # cd <debugfs>/damon
- # echo 42 4242 > target_ids
- # cat target_ids
- 42 4242
-
-Users can also monitor the physical memory address space of the system by
-writing a special keyword, "``paddr\n``" to the file. Because physical address
-space monitoring doesn't support multiple targets, reading the file will show a
-fake value, ``42``, as below::
-
- # cd <debugfs>/damon
- # echo paddr > target_ids
- # cat target_ids
- 42
-
-Note that setting the target ids doesn't start the monitoring.
-
-
-Initial Monitoring Target Regions
----------------------------------
-
-In case of the virtual address space monitoring, DAMON automatically sets and
-updates the monitoring target regions so that entire memory mappings of target
-processes can be covered. However, users can want to limit the monitoring
-region to specific address ranges, such as the heap, the stack, or specific
-file-mapped area. Or, some users can know the initial access pattern of their
-workloads and therefore want to set optimal initial regions for the 'adaptive
-regions adjustment'.
-
-In contrast, DAMON do not automatically sets and updates the monitoring target
-regions in case of physical memory monitoring. Therefore, users should set the
-monitoring target regions by themselves.
-
-In such cases, users can explicitly set the initial monitoring target regions
-as they want, by writing proper values to the ``init_regions`` file. Each line
-of the input should represent one region in below form.::
-
- <target idx> <start address> <end address>
-
-The ``target idx`` should be the index of the target in ``target_ids`` file,
-starting from ``0``, and the regions should be passed in address order. For
-example, below commands will set a couple of address ranges, ``1-100`` and
-``100-200`` as the initial monitoring target region of pid 42, which is the
-first one (index ``0``) in ``target_ids``, and another couple of address
-ranges, ``20-40`` and ``50-100`` as that of pid 4242, which is the second one
-(index ``1``) in ``target_ids``.::
-
- # cd <debugfs>/damon
- # cat target_ids
- 42 4242
- # echo "0 1 100
- 0 100 200
- 1 20 40
- 1 50 100" > init_regions
-
-Note that this sets the initial monitoring target regions only. In case of
-virtual memory monitoring, DAMON will automatically updates the boundary of the
-regions after one ``update interval``. Therefore, users should set the
-``update interval`` large enough in this case, if they don't want the
-update.
-
-
-Schemes
--------
-
-For usual DAMON-based data access aware memory management optimizations, users
-would simply want the system to apply a memory management action to a memory
-region of a specific access pattern. DAMON receives such formalized operation
-schemes from the user and applies those to the target processes.
-
-Users can get and set the schemes by reading from and writing to ``schemes``
-debugfs file. Reading the file also shows the statistics of each scheme. To
-the file, each of the schemes should be represented in each line in below
-form::
-
- <target access pattern> <action> <quota> <watermarks>
-
-You can disable schemes by simply writing an empty string to the file.
-
-Target Access Pattern
-~~~~~~~~~~~~~~~~~~~~~
-
-The ``<target access pattern>`` is constructed with three ranges in below
-form::
-
- min-size max-size min-acc max-acc min-age max-age
-
-Specifically, bytes for the size of regions (``min-size`` and ``max-size``),
-number of monitored accesses per aggregate interval for access frequency
-(``min-acc`` and ``max-acc``), number of aggregate intervals for the age of
-regions (``min-age`` and ``max-age``) are specified. Note that the ranges are
-closed interval.
-
-Action
-~~~~~~
-
-The ``<action>`` is a predefined integer for memory management actions, which
-DAMON will apply to the regions having the target access pattern. The
-supported numbers and their meanings are as below.
-
- - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``
- - 1: Call ``madvise()`` for the region with ``MADV_COLD``
- - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
- - 5: Do nothing but count the statistics
-
-Quota
-~~~~~
-
-Optimal ``target access pattern`` for each ``action`` is workload dependent, so
-not easy to find. Worse yet, setting a scheme of some action too aggressive
-can cause severe overhead. To avoid such overhead, users can limit time and
-size quota for the scheme via the ``<quota>`` in below form::
-
- <ms> <sz> <reset interval> <priority weights>
-
-This makes DAMON to try to use only up to ``<ms>`` milliseconds for applying
-the action to memory regions of the ``target access pattern`` within the
-``<reset interval>`` milliseconds, and to apply the action to only up to
-``<sz>`` bytes of memory regions within the ``<reset interval>``. Setting both
-``<ms>`` and ``<sz>`` zero disables the quota limits.
-
-When the quota limit is expected to be exceeded, DAMON prioritizes found memory
-regions of the ``target access pattern`` based on their size, access frequency,
-and age. For personalized prioritization, users can set the weights for the
-three properties in ``<priority weights>`` in below form::
-
- <size weight> <access frequency weight> <age weight>
-
-Watermarks
-~~~~~~~~~~
-
-Some schemes would need to run based on current value of the system's specific
-metrics like free memory ratio. For such cases, users can specify watermarks
-for the condition.::
-
- <metric> <check interval> <high mark> <middle mark> <low mark>
-
-``<metric>`` is a predefined integer for the metric to be checked. The
-supported numbers and their meanings are as below.
-
- - 0: Ignore the watermarks
- - 1: System's free memory rate (per thousand)
-
-The value of the metric is checked every ``<check interval>`` microseconds.
-
-If the value is higher than ``<high mark>`` or lower than ``<low mark>``, the
-scheme is deactivated. If the value is lower than ``<mid mark>``, the scheme
-is activated.
-
-.. _damos_stats:
-
-Statistics
-~~~~~~~~~~
-
-It also counts the total number and bytes of regions that each scheme is tried
-to be applied, the two numbers for the regions that each scheme is successfully
-applied, and the total number of the quota limit exceeds. This statistics can
-be used for online analysis or tuning of the schemes.
-
-The statistics can be shown by reading the ``schemes`` file. Reading the file
-will show each scheme you entered in each line, and the five numbers for the
-statistics will be added at the end of each line.
-
-Example
-~~~~~~~
-
-Below commands applies a scheme saying "If a memory region of size in [4KiB,
-8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate
-interval in [10, 20], page out the region. For the paging out, use only up to
-10ms per second, and also don't page out more than 1GiB per second. Under the
-limitation, page out memory regions having longer age first. Also, check the
-free memory rate of the system every 5 seconds, start the monitoring and paging
-out when the free memory rate becomes lower than 50%, but stop it if the free
-memory rate becomes larger than 60%, or lower than 30%".::
-
- # cd <debugfs>/damon
- # scheme="4096 8192 0 5 10 20 2" # target access pattern and action
- # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas
- # scheme+=" 0 0 100" # prioritization weights
- # scheme+=" 1 5000000 600 500 300" # watermarks
- # echo "$scheme" > schemes
-
-
-Turning On/Off
---------------
-
-Setting the files as described above doesn't incur effect unless you explicitly
-start the monitoring. You can start, stop, and check the current status of the
-monitoring by writing to and reading from the ``monitor_on`` file. Writing
-``on`` to the file starts the monitoring of the targets with the attributes.
-Writing ``off`` to the file stops those. DAMON also stops if every target
-process is terminated. Below example commands turn on, off, and check the
-status of DAMON::
-
- # cd <debugfs>/damon
- # echo on > monitor_on
- # echo off > monitor_on
- # cat monitor_on
- off
-
-Please note that you cannot write to the above-mentioned debugfs files while
-the monitoring is turned on. If you write to the files while DAMON is running,
-an error code such as ``-EBUSY`` will be returned.
-
-
-Monitoring Thread PID
----------------------
-
-DAMON does requested monitoring with a kernel thread called ``kdamond``. You
-can get the pid of the thread by reading the ``kdamond_pid`` file. When the
-monitoring is turned off, reading the file returns ``none``. ::
-
- # cd <debugfs>/damon
- # cat monitor_on
- off
- # cat kdamond_pid
- none
- # echo on > monitor_on
- # cat kdamond_pid
- 18594
-
-
-Using Multiple Monitoring Threads
----------------------------------
-
-One ``kdamond`` thread is created for each monitoring context. You can create
-and remove monitoring contexts for multiple ``kdamond`` required use case using
-the ``mk_contexts`` and ``rm_contexts`` files.
-
-Writing the name of the new context to the ``mk_contexts`` file creates a
-directory of the name on the DAMON debugfs directory. The directory will have
-DAMON debugfs files for the context. ::
-
- # cd <debugfs>/damon
- # ls foo
- # ls: cannot access 'foo': No such file or directory
- # echo foo > mk_contexts
- # ls foo
- # attrs init_regions kdamond_pid schemes target_ids
-
-If the context is not needed anymore, you can remove it and the corresponding
-directory by putting the name of the context to the ``rm_contexts`` file. ::
-
- # echo foo > rm_contexts
- # ls foo
- # ls: cannot access 'foo': No such file or directory
-
-Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on`` files are in the
-root directory only.
-
-
.. _tracepoint:
-Tracepoint for Monitoring Results
-=================================
+Tracepoints for Monitoring Results
+==================================
+
+Users can get the monitoring results via the :ref:`tried_regions
+<sysfs_schemes_tried_regions>`. The interface is useful for getting a
+snapshot, but it could be inefficient for fully recording all the monitoring
+results. For the purpose, two trace points, namely ``damon:damon_aggregated``
+and ``damon:damos_before_apply``, are provided. ``damon:damon_aggregated``
+provides the whole monitoring results, while ``damon:damos_before_apply``
+provides the monitoring results for regions that each DAMON-based Operation
+Scheme (:ref:`DAMOS <damon_design_damos>`) is gonna be applied. Hence,
+``damon:damos_before_apply`` is more useful for recording internal behavior of
+DAMOS, or DAMOS target access
+:ref:`pattern <damon_design_damos_access_pattern>` based query-like efficient
+monitoring results recording.
+
+While the monitoring is turned on, you could record the tracepoint events and
+show results using tracepoint supporting tools like ``perf``. For example::
-DAMON provides the monitoring results via a tracepoint,
-``damon:damon_aggregated``. While the monitoring is turned on, you could
-record the tracepoint events and show results using tracepoint supporting tools
-like ``perf``. For example::
-
- # echo on > monitor_on
+ # echo on > kdamonds/0/state
# perf record -e damon:damon_aggregated &
# sleep 5
# kill 9 $(pidof perf)
- # echo off > monitor_on
+ # echo off > kdamonds/0/state
# perf script
+ kdamond.0 46568 [027] 79357.842179: damon:damon_aggregated: target_id=0 nr_regions=11 122509119488-135708762112: 0 864
+ [...]
+
+Each line of the perf script output represents each monitoring region. The
+first five fields are as usual other tracepoint outputs. The sixth field
+(``target_id=X``) shows the ide of the monitoring target of the region. The
+seventh field (``nr_regions=X``) shows the total number of monitoring regions
+for the target. The eighth field (``X-Y:``) shows the start (``X``) and end
+(``Y``) addresses of the region in bytes. The ninth field (``X``) shows the
+``nr_accesses`` of the region (refer to
+:ref:`design <damon_design_region_based_sampling>` for more details of the
+counter). Finally the tenth field (``X``) shows the ``age`` of the region
+(refer to :ref:`design <damon_design_age_tracking>` for more details of the
+counter).
+
+If the event was ``damon:damos_beofre_apply``, the ``perf script`` output would
+be somewhat like below::
+
+ kdamond.0 47293 [000] 80801.060214: damon:damos_before_apply: ctx_idx=0 scheme_idx=0 target_idx=0 nr_regions=11 121932607488-135128711168: 0 136
+ [...]
+
+Each line of the output represents each monitoring region that each DAMON-based
+Operation Scheme was about to be applied at the traced time. The first five
+fields are as usual. It shows the index of the DAMON context (``ctx_idx=X``)
+of the scheme in the list of the contexts of the context's kdamond, the index
+of the scheme (``scheme_idx=X``) in the list of the schemes of the context, in
+addition to the output of ``damon_aggregated`` tracepoint.
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst
index 19f27c0d92e0..67a941903fd2 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -1,5 +1,3 @@
-.. _hugetlbpage:
-
=============
HugeTLB Pages
=============
@@ -86,7 +84,7 @@ by increasing or decreasing the value of ``nr_hugepages``.
Note: When the feature of freeing unused vmemmap pages associated with each
hugetlb page is enabled, we can fail to free the huge pages triggered by
-the user when ths system is under memory pressure. Please try again later.
+the user when the system is under memory pressure. Please try again later.
Pages that are used as huge pages are reserved inside the kernel and cannot
be used for other purposes. Huge pages cannot be swapped out under
@@ -147,7 +145,17 @@ hugepages
It will allocate 1 2M hugepage on node0 and 2 2M hugepages on node1.
If the node number is invalid, the parameter will be ignored.
+hugepage_alloc_threads
+ Specify the number of threads that should be used to allocate hugepages
+ during boot. This parameter can be used to improve system bootup time
+ when allocating a large amount of huge pages.
+
+ The default value is 25% of the available hardware threads.
+ Example to use 8 allocation threads::
+ hugepage_alloc_threads=8
+
+ Note that this parameter only applies to non-gigantic huge pages.
default_hugepagesz
Specify the default huge page size. This parameter can
only be specified once on the command line. default_hugepagesz can
@@ -313,7 +321,7 @@ memory policy mode--bind, preferred, local or interleave--may be used. The
resulting effect on persistent huge page allocation is as follows:
#. Regardless of mempolicy mode [see
- :ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`],
+ Documentation/admin-guide/mm/numa_memory_policy.rst],
persistent huge pages will be distributed across the node or nodes
specified in the mempolicy as if "interleave" had been specified.
However, if a node in the policy does not contain sufficient contiguous
@@ -378,6 +386,13 @@ Note that the number of overcommit and reserve pages remain global quantities,
as we don't know until fault time, when the faulting task's mempolicy is
applied, from which node the huge page allocation will be attempted.
+The hugetlb may be migrated between the per-node hugepages pool in the following
+scenarios: memory offline, memory failure, longterm pinning, syscalls(mbind,
+migrate_pages and move_pages), alloc_contig_range() and alloc_contig_pages().
+Now only memory offline, memory failure and syscalls allow fallbacking to allocate
+a new hugetlb on a different node if the current node is unable to allocate during
+hugetlb migration, that means these 3 cases can break the per-node hugepages pool.
+
.. _using_huge_pages:
Using Huge Pages
@@ -461,13 +476,13 @@ Examples
.. _map_hugetlb:
``map_hugetlb``
- see tools/testing/selftests/vm/map_hugetlb.c
+ see tools/testing/selftests/mm/map_hugetlb.c
``hugepage-shm``
- see tools/testing/selftests/vm/hugepage-shm.c
+ see tools/testing/selftests/mm/hugepage-shm.c
``hugepage-mmap``
- see tools/testing/selftests/vm/hugepage-mmap.c
+ see tools/testing/selftests/mm/hugepage-mmap.c
The `libhugetlbfs`_ library provides a wide range of userspace tools
to help with huge page usability, environment setup, and control.
diff --git a/Documentation/admin-guide/mm/idle_page_tracking.rst b/Documentation/admin-guide/mm/idle_page_tracking.rst
index df9394fb39c2..16fcf38dac56 100644
--- a/Documentation/admin-guide/mm/idle_page_tracking.rst
+++ b/Documentation/admin-guide/mm/idle_page_tracking.rst
@@ -1,5 +1,3 @@
-.. _idle_page_tracking:
-
==================
Idle Page Tracking
==================
@@ -65,14 +63,13 @@ workload one should:
are not reclaimable, he or she can filter them out using
``/proc/kpageflags``.
-The page-types tool in the tools/vm directory can be used to assist in this.
+The page-types tool in the tools/mm directory can be used to assist in this.
If the tool is run initially with the appropriate option, it will mark all the
queried pages as idle. Subsequent runs of the tool can then show which pages have
their idle flag cleared in the interim.
-See :ref:`Documentation/admin-guide/mm/pagemap.rst <pagemap>` for more
-information about ``/proc/pid/pagemap``, ``/proc/kpageflags``, and
-``/proc/kpagecgroup``.
+See Documentation/admin-guide/mm/pagemap.rst for more information about
+``/proc/pid/pagemap``, ``/proc/kpageflags``, and ``/proc/kpagecgroup``.
.. _impl_details:
diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst
index 1bd11118dfb1..bbb563cba5d2 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -10,14 +10,13 @@ processes address space and many other cool things.
Linux memory management is a complex system with many configurable
settings. Most of these settings are available via ``/proc``
-filesystem and can be quired and adjusted using ``sysctl``. These APIs
+filesystem and can be queried and adjusted using ``sysctl``. These APIs
are described in Documentation/admin-guide/sysctl/vm.rst and in `man 5 proc`_.
.. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html
Linux memory management has its own jargon and if you are not yet
-familiar with it, consider reading
-:ref:`Documentation/admin-guide/mm/concepts.rst <mm_concepts>`.
+familiar with it, consider reading Documentation/admin-guide/mm/concepts.rst.
Here we document in detail how to interact with various mechanisms in
the Linux memory management.
@@ -32,13 +31,15 @@ the Linux memory management.
idle_page_tracking
ksm
memory-hotplug
+ multigen_lru
nommu-mmap
numa_memory_policy
numaperf
pagemap
shrinker_debugfs
+ slab
soft-dirty
- swap_numa
transhuge
userfaultfd
zswap
+ kho
diff --git a/Documentation/admin-guide/mm/kho.rst b/Documentation/admin-guide/mm/kho.rst
new file mode 100644
index 000000000000..6dc18ed4b886
--- /dev/null
+++ b/Documentation/admin-guide/mm/kho.rst
@@ -0,0 +1,115 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+====================
+Kexec Handover Usage
+====================
+
+Kexec HandOver (KHO) is a mechanism that allows Linux to preserve memory
+regions, which could contain serialized system states, across kexec.
+
+This document expects that you are familiar with the base KHO
+:ref:`concepts <kho-concepts>`. If you have not read
+them yet, please do so now.
+
+Prerequisites
+=============
+
+KHO is available when the kernel is compiled with ``CONFIG_KEXEC_HANDOVER``
+set to y. Every KHO producer may have its own config option that you
+need to enable if you would like to preserve their respective state across
+kexec.
+
+To use KHO, please boot the kernel with the ``kho=on`` command line
+parameter. You may use ``kho_scratch`` parameter to define size of the
+scratch regions. For example ``kho_scratch=16M,512M,256M`` will reserve a
+16 MiB low memory scratch area, a 512 MiB global scratch region, and 256 MiB
+per NUMA node scratch regions on boot.
+
+Perform a KHO kexec
+===================
+
+First, before you perform a KHO kexec, you need to move the system into
+the :ref:`KHO finalization phase <kho-finalization-phase>` ::
+
+ $ echo 1 > /sys/kernel/debug/kho/out/finalize
+
+After this command, the KHO FDT is available in
+``/sys/kernel/debug/kho/out/fdt``. Other subsystems may also register
+their own preserved sub FDTs under
+``/sys/kernel/debug/kho/out/sub_fdts/``.
+
+Next, load the target payload and kexec into it. It is important that you
+use the ``-s`` parameter to use the in-kernel kexec file loader, as user
+space kexec tooling currently has no support for KHO with the user space
+based file loader ::
+
+ # kexec -l /path/to/bzImage --initrd /path/to/initrd -s
+ # kexec -e
+
+The new kernel will boot up and contain some of the previous kernel's state.
+
+For example, if you used ``reserve_mem`` command line parameter to create
+an early memory reservation, the new kernel will have that memory at the
+same physical address as the old kernel.
+
+Abort a KHO exec
+================
+
+You can move the system out of KHO finalization phase again by calling ::
+
+ $ echo 0 > /sys/kernel/debug/kho/out/active
+
+After this command, the KHO FDT is no longer available in
+``/sys/kernel/debug/kho/out/fdt``.
+
+debugfs Interfaces
+==================
+
+Currently KHO creates the following debugfs interfaces. Notice that these
+interfaces may change in the future. They will be moved to sysfs once KHO is
+stabilized.
+
+``/sys/kernel/debug/kho/out/finalize``
+ Kexec HandOver (KHO) allows Linux to transition the state of
+ compatible drivers into the next kexec'ed kernel. To do so,
+ device drivers will instruct KHO to preserve memory regions,
+ which could contain serialized kernel state.
+ While the state is serialized, they are unable to perform
+ any modifications to state that was serialized, such as
+ handed over memory allocations.
+
+ When this file contains "1", the system is in the transition
+ state. When contains "0", it is not. To switch between the
+ two states, echo the respective number into this file.
+
+``/sys/kernel/debug/kho/out/fdt``
+ When KHO state tree is finalized, the kernel exposes the
+ flattened device tree blob that carries its current KHO
+ state in this file. Kexec user space tooling can use this
+ as input file for the KHO payload image.
+
+``/sys/kernel/debug/kho/out/scratch_len``
+ Lengths of KHO scratch regions, which are physically contiguous
+ memory regions that will always stay available for future kexec
+ allocations. Kexec user space tools can use this file to determine
+ where it should place its payload images.
+
+``/sys/kernel/debug/kho/out/scratch_phys``
+ Physical locations of KHO scratch regions. Kexec user space tools
+ can use this file in conjunction to scratch_phys to determine where
+ it should place its payload images.
+
+``/sys/kernel/debug/kho/out/sub_fdts/``
+ In the KHO finalization phase, KHO producers register their own
+ FDT blob under this directory.
+
+``/sys/kernel/debug/kho/in/fdt``
+ When the kernel was booted with Kexec HandOver (KHO),
+ the state tree that carries metadata about the previous
+ kernel's state is in this file in the format of flattened
+ device tree. This file may disappear when all consumers of
+ it finished to interpret their metadata.
+
+``/sys/kernel/debug/kho/in/sub_fdts/``
+ Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs
+ of KHO producers passed from the old kernel.
diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
index b244f0202a03..ad8e7a41f3b5 100644
--- a/Documentation/admin-guide/mm/ksm.rst
+++ b/Documentation/admin-guide/mm/ksm.rst
@@ -1,5 +1,3 @@
-.. _admin_guide_ksm:
-
=======================
Kernel Samepage Merging
=======================
@@ -22,7 +20,7 @@ content which can be replaced by a single write-protected page (which
is automatically copied if a process later wants to update its
content). The amount of pages that KSM daemon scans in a single pass
and the time between the passes are configured using :ref:`sysfs
-intraface <ksm_sysfs>`
+interface <ksm_sysfs>`
KSM only merges anonymous (private) pages, never pagecache (file) pages.
KSM's merged pages were originally locked into kernel memory, but can now
@@ -82,6 +80,9 @@ pages_to_scan
how many pages to scan before ksmd goes to sleep
e.g. ``echo 100 > /sys/kernel/mm/ksm/pages_to_scan``.
+ The pages_to_scan value cannot be changed if ``advisor_mode`` has
+ been set to scan-time.
+
Default: 100 (chosen for demonstration purposes)
sleep_millisecs
@@ -157,8 +158,44 @@ stable_node_chains_prune_millisecs
scan. It's a noop if not a single KSM page hit the
``max_page_sharing`` yet.
+smart_scan
+ Historically KSM checked every candidate page for each scan. It did
+ not take into account historic information. When smart scan is
+ enabled, pages that have previously not been de-duplicated get
+ skipped. How often these pages are skipped depends on how often
+ de-duplication has already been tried and failed. By default this
+ optimization is enabled. The ``pages_skipped`` metric shows how
+ effective the setting is.
+
+advisor_mode
+ The ``advisor_mode`` selects the current advisor. Two modes are
+ supported: none and scan-time. The default is none. By setting
+ ``advisor_mode`` to scan-time, the scan time advisor is enabled.
+ The section about ``advisor`` explains in detail how the scan time
+ advisor works.
+
+adivsor_max_cpu
+ specifies the upper limit of the cpu percent usage of the ksmd
+ background thread. The default is 70.
+
+advisor_target_scan_time
+ specifies the target scan time in seconds to scan all the candidate
+ pages. The default value is 200 seconds.
+
+advisor_min_pages_to_scan
+ specifies the lower limit of the ``pages_to_scan`` parameter of the
+ scan time advisor. The default is 500.
+
+adivsor_max_pages_to_scan
+ specifies the upper limit of the ``pages_to_scan`` parameter of the
+ scan time advisor. The default is 30000.
+
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
+general_profit
+ how effective is KSM. The calculation is explained below.
+pages_scanned
+ how many pages are being scanned for ksm
pages_shared
how many shared pages are being used
pages_sharing
@@ -167,12 +204,21 @@ pages_unshared
how many pages unique but repeatedly checked for merging
pages_volatile
how many pages changing too fast to be placed in a tree
+pages_skipped
+ how many pages did the "smart" page scanning algorithm skip
full_scans
how many times all mergeable areas have been scanned
stable_node_chains
the number of KSM pages that hit the ``max_page_sharing`` limit
stable_node_dups
number of duplicated KSM pages
+ksm_zero_pages
+ how many zero pages that are still mapped into processes were mapped by
+ KSM when deduplicating.
+
+When ``use_zero_pages`` is/was enabled, the sum of ``pages_sharing`` +
+``ksm_zero_pages`` represents the actual number of pages saved by KSM.
+if ``use_zero_pages`` has never been enabled, ``ksm_zero_pages`` is 0.
A high ratio of ``pages_sharing`` to ``pages_shared`` indicates good
sharing, but a high ratio of ``pages_unshared`` to ``pages_sharing``
@@ -184,6 +230,47 @@ The maximum possible ``pages_sharing/pages_shared`` ratio is limited by the
``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` must
be increased accordingly.
+Monitoring KSM profit
+=====================
+
+KSM can save memory by merging identical pages, but also can consume
+additional memory, because it needs to generate a number of rmap_items to
+save each scanned page's brief rmap information. Some of these pages may
+be merged, but some may not be abled to be merged after being checked
+several times, which are unprofitable memory consumed.
+
+1) How to determine whether KSM save memory or consume memory in system-wide
+ range? Here is a simple approximate calculation for reference::
+
+ general_profit =~ ksm_saved_pages * sizeof(page) - (all_rmap_items) *
+ sizeof(rmap_item);
+
+ where ksm_saved_pages equals to the sum of ``pages_sharing`` +
+ ``ksm_zero_pages`` of the system, and all_rmap_items can be easily
+ obtained by summing ``pages_sharing``, ``pages_shared``, ``pages_unshared``
+ and ``pages_volatile``.
+
+2) The KSM profit inner a single process can be similarly obtained by the
+ following approximate calculation::
+
+ process_profit =~ ksm_saved_pages * sizeof(page) -
+ ksm_rmap_items * sizeof(rmap_item).
+
+ where ksm_saved_pages equals to the sum of ``ksm_merging_pages`` and
+ ``ksm_zero_pages``, both of which are shown under the directory
+ ``/proc/<pid>/ksm_stat``, and ksm_rmap_items is also shown in
+ ``/proc/<pid>/ksm_stat``. The process profit is also shown in
+ ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
+
+From the perspective of application, a high ratio of ``ksm_rmap_items`` to
+``ksm_merging_pages`` means a bad madvise-applied policy, so developers or
+administrators have to rethink how to change madvise policy. Giving an example
+for reference, a page's size is usually 4K, and the rmap_item's size is
+separately 32B on 32-bit CPU architecture and 64B on 64-bit CPU architecture.
+so if the ``ksm_rmap_items/ksm_merging_pages`` ratio exceeds 64 on 64-bit CPU
+or exceeds 128 on 32-bit CPU, then the app's madvise policy should be dropped,
+because the ksm profit is approximately zero or negative.
+
Monitoring KSM events
=====================
@@ -202,6 +289,35 @@ ksm_swpin_copy
note that KSM page might be copied when swapping in because do_swap_page()
cannot do all the locking needed to reconstitute a cross-anon_vma KSM page.
+Advisor
+=======
+
+The number of candidate pages for KSM is dynamic. It can be often observed
+that during the startup of an application more candidate pages need to be
+processed. Without an advisor the ``pages_to_scan`` parameter needs to be
+sized for the maximum number of candidate pages. The scan time advisor can
+changes the ``pages_to_scan`` parameter based on demand.
+
+The advisor can be enabled, so KSM can automatically adapt to changes in the
+number of candidate pages to scan. Two advisors are implemented: none and
+scan-time. With none, no advisor is enabled. The default is none.
+
+The scan time advisor changes the ``pages_to_scan`` parameter based on the
+observed scan times. The possible values for the ``pages_to_scan`` parameter is
+limited by the ``advisor_max_cpu`` parameter. In addition there is also the
+``advisor_target_scan_time`` parameter. This parameter sets the target time to
+scan all the KSM candidate pages. The parameter ``advisor_target_scan_time``
+decides how aggressive the scan time advisor scans candidate pages. Lower
+values make the scan time advisor to scan more aggressively. This is the most
+important parameter for the configuration of the scan time advisor.
+
+The initial value and the maximum value can be changed with
+``advisor_min_pages_to_scan`` and ``advisor_max_pages_to_scan``. The default
+values are sufficient for most workloads and use cases.
+
+The ``pages_to_scan`` parameter is re-calculated after a scan has been completed.
+
+
--
Izik Eidus,
Hugh Dickins, 17 Nov 2009
diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst
index a3c9e8ad8fa0..33c886f3d198 100644
--- a/Documentation/admin-guide/mm/memory-hotplug.rst
+++ b/Documentation/admin-guide/mm/memory-hotplug.rst
@@ -1,5 +1,3 @@
-.. _admin_guide_memory_hotplug:
-
==================
Memory Hot(Un)Plug
==================
@@ -35,7 +33,7 @@ used to expose persistent memory, other performance-differentiated memory and
reserved memory regions as ordinary system RAM to Linux.
Linux only supports memory hot(un)plug on selected 64 bit architectures, such as
-x86_64, arm64, ppc64, s390x and ia64.
+x86_64, arm64, ppc64 and s390x.
Memory Hot(Un)Plug Granularity
------------------------------
@@ -77,7 +75,7 @@ Memory hotunplug consists of two phases:
(1) Offlining memory blocks
(2) Removing the memory from Linux
-In the fist phase, memory is "hidden" from the page allocator again, for
+In the first phase, memory is "hidden" from the page allocator again, for
example, by migrating busy memory to other memory locations and removing all
relevant free pages from the page allocator After this phase, the memory is no
longer visible in memory statistics of the system.
@@ -252,15 +250,15 @@ Observing the State of Memory Blocks
The state (online/offline/going-offline) of a memory block can be observed
either via::
- % cat /sys/device/system/memory/memoryXXX/state
+ % cat /sys/devices/system/memory/memoryXXX/state
Or alternatively (1/0) via::
- % cat /sys/device/system/memory/memoryXXX/online
+ % cat /sys/devices/system/memory/memoryXXX/online
For an online memory block, the managing zone can be observed via::
- % cat /sys/device/system/memory/memoryXXX/valid_zones
+ % cat /sys/devices/system/memory/memoryXXX/valid_zones
Configuring Memory Hot(Un)Plug
==============================
@@ -282,8 +280,8 @@ The following files are currently defined:
blocks; configure auto-onlining.
The default value depends on the
- CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel configuration
- option.
+ CONFIG_MHP_DEFAULT_ONLINE_TYPE kernel configuration
+ options.
See the ``state`` property of memory blocks for details.
``block_size_bytes`` read-only: the size in bytes of a memory block.
@@ -293,6 +291,15 @@ The following files are currently defined:
Availability depends on the CONFIG_ARCH_MEMORY_PROBE
kernel configuration option.
``uevent`` read-write: generic udev file for device subsystems.
+``crash_hotplug`` read-only: when changes to the system memory map
+ occur due to hot un/plug of memory, this file contains
+ '1' if the kernel updates the kdump capture kernel memory
+ map itself (via elfcorehdr and other relevant kexec
+ segments), or '0' if userspace must update the kdump
+ capture kernel memory map.
+
+ Availability depends on the CONFIG_MEMORY_HOTPLUG kernel
+ configuration option.
====================== =========================================================
.. note::
@@ -320,7 +327,7 @@ however, a memory block might span memory holes. A memory block spanning memory
holes cannot be offlined.
For example, assume 1 GiB memory block size. A device for a memory starting at
-0x100000000 is ``/sys/device/system/memory/memory4``::
+0x100000000 is ``/sys/devices/system/memory/memory4``::
(0x100000000 / 1Gib = 4)
@@ -435,6 +442,18 @@ The following module parameters are currently defined:
memory in a way that huge pages in bigger
granularity cannot be formed on hotplugged
memory.
+
+ With value "force" it could result in memory
+ wastage due to memmap size limitations. For
+ example, if the memmap for a memory block
+ requires 1 MiB, but the pageblock size is 2
+ MiB, 1 MiB of hotplugged memory will be wasted.
+ Note that there are still cases where the
+ feature cannot be enforced: for example, if the
+ memmap is smaller than a single page, or if the
+ architecture does not support the forced mode
+ in all configurations.
+
``online_policy`` read-write: Set the basic policy used for
automatic zone selection when onlining memory
blocks without specifying a target zone.
@@ -671,7 +690,7 @@ when still encountering permanently unmovable pages within ZONE_MOVABLE
(-> BUG), memory offlining will keep retrying until it eventually succeeds.
When offlining is triggered from user space, the offlining context can be
-terminated by sending a fatal signal. A timeout based offlining can easily be
+terminated by sending a signal. A timeout based offlining can easily be
implemented via::
% timeout $TIMEOUT offline_block | failure_handling
diff --git a/Documentation/admin-guide/mm/multigen_lru.rst b/Documentation/admin-guide/mm/multigen_lru.rst
new file mode 100644
index 000000000000..9cb54b4ff5d9
--- /dev/null
+++ b/Documentation/admin-guide/mm/multigen_lru.rst
@@ -0,0 +1,163 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+Multi-Gen LRU
+=============
+The multi-gen LRU is an alternative LRU implementation that optimizes
+page reclaim and improves performance under memory pressure. Page
+reclaim decides the kernel's caching policy and ability to overcommit
+memory. It directly impacts the kswapd CPU usage and RAM efficiency.
+
+Quick start
+===========
+Build the kernel with the following configurations.
+
+* ``CONFIG_LRU_GEN=y``
+* ``CONFIG_LRU_GEN_ENABLED=y``
+
+All set!
+
+Runtime options
+===============
+``/sys/kernel/mm/lru_gen/`` contains stable ABIs described in the
+following subsections.
+
+Kill switch
+-----------
+``enabled`` accepts different values to enable or disable the
+following components. Its default value depends on
+``CONFIG_LRU_GEN_ENABLED``. All the components should be enabled
+unless some of them have unforeseen side effects. Writing to
+``enabled`` has no effect when a component is not supported by the
+hardware, and valid values will be accepted even when the main switch
+is off.
+
+====== ===============================================================
+Values Components
+====== ===============================================================
+0x0001 The main switch for the multi-gen LRU.
+0x0002 Clearing the accessed bit in leaf page table entries in large
+ batches, when MMU sets it (e.g., on x86). This behavior can
+ theoretically worsen lock contention (mmap_lock). If it is
+ disabled, the multi-gen LRU will suffer a minor performance
+ degradation for workloads that contiguously map hot pages,
+ whose accessed bits can be otherwise cleared by fewer larger
+ batches.
+0x0004 Clearing the accessed bit in non-leaf page table entries as
+ well, when MMU sets it (e.g., on x86). This behavior was not
+ verified on x86 varieties other than Intel and AMD. If it is
+ disabled, the multi-gen LRU will suffer a negligible
+ performance degradation.
+[yYnN] Apply to all the components above.
+====== ===============================================================
+
+E.g.,
+::
+
+ echo y >/sys/kernel/mm/lru_gen/enabled
+ cat /sys/kernel/mm/lru_gen/enabled
+ 0x0007
+ echo 5 >/sys/kernel/mm/lru_gen/enabled
+ cat /sys/kernel/mm/lru_gen/enabled
+ 0x0005
+
+Thrashing prevention
+--------------------
+Personal computers are more sensitive to thrashing because it can
+cause janks (lags when rendering UI) and negatively impact user
+experience. The multi-gen LRU offers thrashing prevention to the
+majority of laptop and desktop users who do not have ``oomd``.
+
+Users can write ``N`` to ``min_ttl_ms`` to prevent the working set of
+``N`` milliseconds from getting evicted. The OOM killer is triggered
+if this working set cannot be kept in memory. In other words, this
+option works as an adjustable pressure relief valve, and when open, it
+terminates applications that are hopefully not being used.
+
+Based on the average human detectable lag (~100ms), ``N=1000`` usually
+eliminates intolerable janks due to thrashing. Larger values like
+``N=3000`` make janks less noticeable at the risk of premature OOM
+kills.
+
+The default value ``0`` means disabled.
+
+Experimental features
+=====================
+``/sys/kernel/debug/lru_gen`` accepts commands described in the
+following subsections. Multiple command lines are supported, so does
+concatenation with delimiters ``,`` and ``;``.
+
+``/sys/kernel/debug/lru_gen_full`` provides additional stats for
+debugging. ``CONFIG_LRU_GEN_STATS=y`` keeps historical stats from
+evicted generations in this file.
+
+Working set estimation
+----------------------
+Working set estimation measures how much memory an application needs
+in a given time interval, and it is usually done with little impact on
+the performance of the application. E.g., data centers want to
+optimize job scheduling (bin packing) to improve memory utilizations.
+When a new job comes in, the job scheduler needs to find out whether
+each server it manages can allocate a certain amount of memory for
+this new job before it can pick a candidate. To do so, the job
+scheduler needs to estimate the working sets of the existing jobs.
+
+When it is read, ``lru_gen`` returns a histogram of numbers of pages
+accessed over different time intervals for each memcg and node.
+``MAX_NR_GENS`` decides the number of bins for each histogram. The
+histograms are noncumulative.
+::
+
+ memcg memcg_id memcg_path
+ node node_id
+ min_gen_nr age_in_ms nr_anon_pages nr_file_pages
+ ...
+ max_gen_nr age_in_ms nr_anon_pages nr_file_pages
+
+Each bin contains an estimated number of pages that have been accessed
+within ``age_in_ms``. E.g., ``min_gen_nr`` contains the coldest pages
+and ``max_gen_nr`` contains the hottest pages, since ``age_in_ms`` of
+the former is the largest and that of the latter is the smallest.
+
+Users can write the following command to ``lru_gen`` to create a new
+generation ``max_gen_nr+1``:
+
+ ``+ memcg_id node_id max_gen_nr [can_swap [force_scan]]``
+
+``can_swap`` defaults to the swap setting and, if it is set to ``1``,
+it forces the scan of anon pages when swap is off, and vice versa.
+``force_scan`` defaults to ``1`` and, if it is set to ``0``, it
+employs heuristics to reduce the overhead, which is likely to reduce
+the coverage as well.
+
+A typical use case is that a job scheduler runs this command at a
+certain time interval to create new generations, and it ranks the
+servers it manages based on the sizes of their cold pages defined by
+this time interval.
+
+Proactive reclaim
+-----------------
+Proactive reclaim induces page reclaim when there is no memory
+pressure. It usually targets cold pages only. E.g., when a new job
+comes in, the job scheduler wants to proactively reclaim cold pages on
+the server it selected, to improve the chance of successfully landing
+this new job.
+
+Users can write the following command to ``lru_gen`` to evict
+generations less than or equal to ``min_gen_nr``.
+
+ ``- memcg_id node_id min_gen_nr [swappiness [nr_to_reclaim]]``
+
+``min_gen_nr`` should be less than ``max_gen_nr-1``, since
+``max_gen_nr`` and ``max_gen_nr-1`` are not fully aged (equivalent to
+the active list) and therefore cannot be evicted. ``swappiness``
+overrides the default value in ``/proc/sys/vm/swappiness`` and the valid
+range is [0-200, max], with max being exclusively used for the reclamation
+of anonymous memory. ``nr_to_reclaim`` limits the number of pages to evict.
+
+A typical use case is that a job scheduler runs this command before it
+tries to land a new job on a server. If it fails to materialize enough
+cold pages because of the overestimation, it retries on the next
+server according to the ranking result obtained from the working set
+estimation step. This less forceful approach limits the impacts on the
+existing jobs.
diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst
index 5a6afecbb0d0..a70f20ce1ffb 100644
--- a/Documentation/admin-guide/mm/numa_memory_policy.rst
+++ b/Documentation/admin-guide/mm/numa_memory_policy.rst
@@ -1,5 +1,3 @@
-.. _numa_memory_policy:
-
==================
NUMA Memory Policy
==================
@@ -111,7 +109,7 @@ VMA Policy
* A task may install a new VMA policy on a sub-range of a
previously mmap()ed region. When this happens, Linux splits
the existing virtual memory area into 2 or 3 VMAs, each with
- it's own policy.
+ its own policy.
* By default, VMA policy applies only to pages allocated after
the policy is installed. Any pages already faulted into the
@@ -246,12 +244,21 @@ MPOL_INTERLEAVED
interleaved system default policy works in this mode.
MPOL_PREFERRED_MANY
- This mode specifices that the allocation should be preferrably
+ This mode specifies that the allocation should be preferably
satisfied from the nodemask specified in the policy. If there is
a memory pressure on all nodes in the nodemask, the allocation
can fall back to all existing numa nodes. This is effectively
MPOL_PREFERRED allowed for a mask rather than a single node.
+MPOL_WEIGHTED_INTERLEAVE
+ This mode operates the same as MPOL_INTERLEAVE, except that
+ interleaving behavior is executed based on weights set in
+ /sys/kernel/mm/mempolicy/weighted_interleave/
+
+ Weighted interleave allocates pages on nodes according to a
+ weight. For example if nodes [0,1] are weighted [5,2], 5 pages
+ will be allocated on node0 for every 2 pages allocated on node1.
+
NUMA memory policy supports the following optional mode flags:
MPOL_F_STATIC_NODES
@@ -360,7 +367,7 @@ and NUMA nodes. "Usage" here means one of the following:
2) examination of the policy to determine the policy mode and associated node
or node lists, if any, for page allocation. This is considered a "hot
path". Note that for MPOL_BIND, the "usage" extends across the entire
- allocation process, which may sleep during page reclaimation, because the
+ allocation process, which may sleep during page reclamation, because the
BIND policy nodemask is used, by reference, to filter ineligible nodes.
We can avoid taking an extra reference during the usages listed above as
diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst
index 166697325947..90a12b6a8bfc 100644
--- a/Documentation/admin-guide/mm/numaperf.rst
+++ b/Documentation/admin-guide/mm/numaperf.rst
@@ -1,6 +1,7 @@
-.. _numaperf:
+=======================
+NUMA Memory Performance
+=======================
-=============
NUMA Locality
=============
@@ -61,7 +62,6 @@ that are CPUs and hence suitable for generic task scheduling, and
IO initiators such as GPUs and NICs. Unlike access class 0, only
nodes containing CPUs are considered.
-================
NUMA Performance
================
@@ -96,7 +96,6 @@ for the platform.
Access class 1 takes the same form but only includes values for CPU to
memory activity.
-==========
NUMA Cache
==========
@@ -170,7 +169,6 @@ The "size" is the number of bytes provided by this cache level.
The "write_policy" will be 0 for write-back, and non-zero for
write-through caching.
-========
See Also
========
diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
index 6e2e416af783..c57e61b5d8aa 100644
--- a/Documentation/admin-guide/mm/pagemap.rst
+++ b/Documentation/admin-guide/mm/pagemap.rst
@@ -1,5 +1,3 @@
-.. _pagemap:
-
=============================
Examining Process Page Tables
=============================
@@ -19,11 +17,12 @@ There are four components to pagemap:
* Bits 0-4 swap type if swapped
* Bits 5-54 swap offset if swapped
* Bit 55 pte is soft-dirty (see
- :ref:`Documentation/admin-guide/mm/soft-dirty.rst <soft_dirty>`)
+ Documentation/admin-guide/mm/soft-dirty.rst)
* Bit 56 page exclusively mapped (since 4.2)
* Bit 57 pte is uffd-wp write-protected (since 5.13) (see
- :ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`)
- * Bits 58-60 zero
+ Documentation/admin-guide/mm/userfaultfd.rst)
+ * Bit 58 pte is a guard region (since 6.15) (see madvise (2) man page)
+ * Bits 59-60 zero
* Bit 61 page is file-page or shared-anon (since 3.5)
* Bit 62 page swapped
* Bit 63 page present
@@ -39,14 +38,30 @@ There are four components to pagemap:
precisely which pages are mapped (or in swap) and comparing mapped
pages between processes.
+ Traditionally, bit 56 indicates that a page is mapped exactly once and bit
+ 56 is clear when a page is mapped multiple times, even when mapped in the
+ same process multiple times. In some kernel configurations, the semantics
+ for pages part of a larger allocation (e.g., THP) can differ: bit 56 is set
+ if all pages part of the corresponding large allocation are *certainly*
+ mapped in the same process, even if the page is mapped multiple times in that
+ process. Bit 56 is clear when any page page of the larger allocation
+ is *maybe* mapped in a different process. In some cases, a large allocation
+ might be treated as "maybe mapped by multiple processes" even though this
+ is no longer the case.
+
Efficient users of this interface will use ``/proc/pid/maps`` to
determine which areas of memory are actually mapped and llseek to
skip over unmapped regions.
* ``/proc/kpagecount``. This file contains a 64-bit count of the number of
- times each page is mapped, indexed by PFN.
-
-The page-types tool in the tools/vm directory can be used to query the
+ times each page is mapped, indexed by PFN. Some kernel configurations do
+ not track the precise number of times a page part of a larger allocation
+ (e.g., THP) is mapped. In these configurations, the average number of
+ mappings per page in this larger allocation is returned instead. However,
+ if any page of the large allocation is mapped, the returned value will
+ be at least 1.
+
+The page-types tool in the tools/mm directory can be used to query the
number of times a page is mapped.
* ``/proc/kpageflags``. This file contains a 64-bit set of flags for each
@@ -93,20 +108,20 @@ Short descriptions to the page flags
The page is being locked for exclusive access, e.g. by undergoing read/write
IO.
7 - SLAB
- The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator.
- When compound page is used, SLUB/SLQB will only set this flag on the head
- page; SLOB will not flag it at all.
+ The page is managed by the SLAB/SLUB kernel memory allocator.
+ When compound page is used, either will only set this flag on the head
+ page.
10 - BUDDY
A free memory block managed by the buddy system allocator.
The buddy system organizes free memory in blocks of various orders.
An order N block has 2^N physically contiguous pages, with the BUDDY flag
- set for and _only_ for the first page.
+ set for all pages.
+ Before 4.6 only the first page of the block had the flag set.
15 - COMPOUND_HEAD
A compound page with order N consists of 2^N physically contiguous pages.
A compound page with order 2 takes the form of "HTTT", where H donates its
head page and T donates its tail page(s). The major consumers of compound
- pages are hugeTLB pages
- (:ref:`Documentation/admin-guide/mm/hugetlbpage.rst <hugetlbpage>`),
+ pages are hugeTLB pages (Documentation/admin-guide/mm/hugetlbpage.rst),
the SLUB etc. memory allocators and various device drivers.
However in this interface, only huge/giga pages are made visible
to end users.
@@ -121,14 +136,14 @@ Short descriptions to the page flags
21 - KSM
Identical memory pages dynamically shared between one or more processes.
22 - THP
- Contiguous pages which construct transparent hugepages.
+ Contiguous pages which construct THP of any size and mapped by any granularity.
23 - OFFLINE
The page is logically offline.
24 - ZERO_PAGE
Zero page for pfn_zero or huge_zero page.
25 - IDLE
The page has not been accessed since it was marked idle (see
- :ref:`Documentation/admin-guide/mm/idle_page_tracking.rst <idle_page_tracking>`).
+ Documentation/admin-guide/mm/idle_page_tracking.rst).
Note that this flag may be stale in case the page was accessed via
a PTE. To make sure the flag is up-to-date one has to read
``/sys/kernel/mm/page_idle/bitmap`` first.
@@ -173,30 +188,9 @@ LRU related page flags
14 - SWAPBACKED
The page is backed by swap/RAM.
-The page-types tool in the tools/vm directory can be used to query the
+The page-types tool in the tools/mm directory can be used to query the
above flags.
-Using pagemap to do something useful
-====================================
-
-The general procedure for using pagemap to find out about a process' memory
-usage goes like this:
-
- 1. Read ``/proc/pid/maps`` to determine which parts of the memory space are
- mapped to what.
- 2. Select the maps you are interested in -- all of them, or a particular
- library, or the stack or the heap, etc.
- 3. Open ``/proc/pid/pagemap`` and seek to the pages you would like to examine.
- 4. Read a u64 for each page from pagemap.
- 5. Open ``/proc/kpagecount`` and/or ``/proc/kpageflags``. For each PFN you
- just read, seek to that entry in the file, and read the data you want.
-
-For example, to find the "unique set size" (USS), which is the amount of
-memory that a process is using that is not shared with any other process,
-you can go through every map in the process, find the PFNs, look those up
-in kpagecount, and tally up the number of pages that are only referenced
-once.
-
Exceptions for Shared Memory
============================
@@ -230,3 +224,94 @@ Before Linux 3.11 pagemap bits 55-60 were used for "page-shift" (which is
always 12 at most architectures). Since Linux 3.11 their meaning changes
after first clear of soft-dirty bits. Since Linux 4.2 they are used for
flags unconditionally.
+
+Pagemap Scan IOCTL
+==================
+
+The ``PAGEMAP_SCAN`` IOCTL on the pagemap file can be used to get or optionally
+clear the info about page table entries. The following operations are supported
+in this IOCTL:
+
+- Scan the address range and get the memory ranges matching the provided criteria.
+ This is performed when the output buffer is specified.
+- Write-protect the pages. The ``PM_SCAN_WP_MATCHING`` is used to write-protect
+ the pages of interest. The ``PM_SCAN_CHECK_WPASYNC`` aborts the operation if
+ non-Async Write Protected pages are found. The ``PM_SCAN_WP_MATCHING`` can be
+ used with or without ``PM_SCAN_CHECK_WPASYNC``.
+- Both of those operations can be combined into one atomic operation where we can
+ get and write protect the pages as well.
+
+Following flags about pages are currently supported:
+
+- ``PAGE_IS_WPALLOWED`` - Page has async-write-protection enabled
+- ``PAGE_IS_WRITTEN`` - Page has been written to from the time it was write protected
+- ``PAGE_IS_FILE`` - Page is file backed
+- ``PAGE_IS_PRESENT`` - Page is present in the memory
+- ``PAGE_IS_SWAPPED`` - Page is in swapped
+- ``PAGE_IS_PFNZERO`` - Page has zero PFN
+- ``PAGE_IS_HUGE`` - Page is PMD-mapped THP or Hugetlb backed
+- ``PAGE_IS_SOFT_DIRTY`` - Page is soft-dirty
+- ``PAGE_IS_GUARD`` - Page is a part of a guard region
+
+The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
+
+ 1. The size of the ``struct pm_scan_arg`` must be specified in the ``size``
+ field. This field will be helpful in recognizing the structure if extensions
+ are done later.
+ 2. The flags can be specified in the ``flags`` field. The ``PM_SCAN_WP_MATCHING``
+ and ``PM_SCAN_CHECK_WPASYNC`` are the only added flags at this time. The get
+ operation is optionally performed depending upon if the output buffer is
+ provided or not.
+ 3. The range is specified through ``start`` and ``end``.
+ 4. The walk can abort before visiting the complete range such as the user buffer
+ can get full etc. The walk ending address is specified in``end_walk``.
+ 5. The output buffer of ``struct page_region`` array and size is specified in
+ ``vec`` and ``vec_len``.
+ 6. The optional maximum requested pages are specified in the ``max_pages``.
+ 7. The masks are specified in ``category_mask``, ``category_anyof_mask``,
+ ``category_inverted`` and ``return_mask``.
+
+Find pages which have been written and WP them as well::
+
+ struct pm_scan_arg arg = {
+ .size = sizeof(arg),
+ .flags = PM_SCAN_CHECK_WPASYNC | PM_SCAN_CHECK_WPASYNC,
+ ..
+ .category_mask = PAGE_IS_WRITTEN,
+ .return_mask = PAGE_IS_WRITTEN,
+ };
+
+Find pages which have been written, are file backed, not swapped and either
+present or huge::
+
+ struct pm_scan_arg arg = {
+ .size = sizeof(arg),
+ .flags = 0,
+ ..
+ .category_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED,
+ .category_inverted = PAGE_IS_SWAPPED,
+ .category_anyof_mask = PAGE_IS_PRESENT | PAGE_IS_HUGE,
+ .return_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED |
+ PAGE_IS_PRESENT | PAGE_IS_HUGE,
+ };
+
+The ``PAGE_IS_WRITTEN`` flag can be considered as a better-performing alternative
+of soft-dirty flag. It doesn't get affected by VMA merging of the kernel and hence
+the user can find the true soft-dirty pages in case of normal pages. (There may
+still be extra dirty pages reported for THP or Hugetlb pages.)
+
+"PAGE_IS_WRITTEN" category is used with uffd write protect-enabled ranges to
+implement memory dirty tracking in userspace:
+
+ 1. The userfaultfd file descriptor is created with ``userfaultfd`` syscall.
+ 2. The ``UFFD_FEATURE_WP_UNPOPULATED`` and ``UFFD_FEATURE_WP_ASYNC`` features
+ are set by ``UFFDIO_API`` IOCTL.
+ 3. The memory range is registered with ``UFFDIO_REGISTER_MODE_WP`` mode
+ through ``UFFDIO_REGISTER`` IOCTL.
+ 4. Then any part of the registered memory or the whole memory region must
+ be write protected using ``PAGEMAP_SCAN`` IOCTL with flag ``PM_SCAN_WP_MATCHING``
+ or the ``UFFDIO_WRITEPROTECT`` IOCTL can be used. Both of these perform the
+ same operation. The former is better in terms of performance.
+ 5. Now the ``PAGEMAP_SCAN`` IOCTL can be used to either just find pages which
+ have been written to since they were last marked and/or optionally write protect
+ the pages as well.
diff --git a/Documentation/admin-guide/mm/shrinker_debugfs.rst b/Documentation/admin-guide/mm/shrinker_debugfs.rst
index 3887f0b294fe..c582033bd113 100644
--- a/Documentation/admin-guide/mm/shrinker_debugfs.rst
+++ b/Documentation/admin-guide/mm/shrinker_debugfs.rst
@@ -1,5 +1,3 @@
-.. _shrinker_debugfs:
-
==========================
Shrinker Debugfs Interface
==========================
diff --git a/Documentation/admin-guide/mm/slab.rst b/Documentation/admin-guide/mm/slab.rst
new file mode 100644
index 000000000000..14429ab90611
--- /dev/null
+++ b/Documentation/admin-guide/mm/slab.rst
@@ -0,0 +1,469 @@
+========================================
+Short users guide for the slab allocator
+========================================
+
+The slab allocator includes full debugging support (when built with
+CONFIG_SLUB_DEBUG=y) but it is off by default (unless built with
+CONFIG_SLUB_DEBUG_ON=y). You can enable debugging only for selected
+slabs in order to avoid an impact on overall system performance which
+may make a bug more difficult to find.
+
+In order to switch debugging on one can add an option ``slab_debug``
+to the kernel command line. That will enable full debugging for
+all slabs.
+
+Typically one would then use the ``slabinfo`` command to get statistical
+data and perform operation on the slabs. By default ``slabinfo`` only lists
+slabs that have data in them. See "slabinfo -h" for more options when
+running the command. ``slabinfo`` can be compiled with
+::
+
+ gcc -o slabinfo tools/mm/slabinfo.c
+
+Some of the modes of operation of ``slabinfo`` require that slub debugging
+be enabled on the command line. F.e. no tracking information will be
+available without debugging on and validation can only partially
+be performed if debugging was not switched on.
+
+Some more sophisticated uses of slab_debug:
+-------------------------------------------
+
+Parameters may be given to ``slab_debug``. If none is specified then full
+debugging is enabled. Format:
+
+slab_debug=<Debug-Options>
+ Enable options for all slabs
+
+slab_debug=<Debug-Options>,<slab name1>,<slab name2>,...
+ Enable options only for select slabs (no spaces
+ after a comma)
+
+Multiple blocks of options for all slabs or selected slabs can be given, with
+blocks of options delimited by ';'. The last of "all slabs" blocks is applied
+to all slabs except those that match one of the "select slabs" block. Options
+of the first "select slabs" blocks that matches the slab's name are applied.
+
+Possible debug options are::
+
+ F Sanity checks on (enables SLAB_DEBUG_CONSISTENCY_CHECKS
+ Sorry SLAB legacy issues)
+ Z Red zoning
+ P Poisoning (object and padding)
+ U User tracking (free and alloc)
+ T Trace (please only use on single slabs)
+ A Enable failslab filter mark for the cache
+ O Switch debugging off for caches that would have
+ caused higher minimum slab orders
+ - Switch all debugging off (useful if the kernel is
+ configured with CONFIG_SLUB_DEBUG_ON)
+
+F.e. in order to boot just with sanity checks and red zoning one would specify::
+
+ slab_debug=FZ
+
+Trying to find an issue in the dentry cache? Try::
+
+ slab_debug=,dentry
+
+to only enable debugging on the dentry cache. You may use an asterisk at the
+end of the slab name, in order to cover all slabs with the same prefix. For
+example, here's how you can poison the dentry cache as well as all kmalloc
+slabs::
+
+ slab_debug=P,kmalloc-*,dentry
+
+Red zoning and tracking may realign the slab. We can just apply sanity checks
+to the dentry cache with::
+
+ slab_debug=F,dentry
+
+Debugging options may require the minimum possible slab order to increase as
+a result of storing the metadata (for example, caches with PAGE_SIZE object
+sizes). This has a higher likelihood of resulting in slab allocation errors
+in low memory situations or if there's high fragmentation of memory. To
+switch off debugging for such caches by default, use::
+
+ slab_debug=O
+
+You can apply different options to different list of slab names, using blocks
+of options. This will enable red zoning for dentry and user tracking for
+kmalloc. All other slabs will not get any debugging enabled::
+
+ slab_debug=Z,dentry;U,kmalloc-*
+
+You can also enable options (e.g. sanity checks and poisoning) for all caches
+except some that are deemed too performance critical and don't need to be
+debugged by specifying global debug options followed by a list of slab names
+with "-" as options::
+
+ slab_debug=FZ;-,zs_handle,zspage
+
+The state of each debug option for a slab can be found in the respective files
+under::
+
+ /sys/kernel/slab/<slab name>/
+
+If the file contains 1, the option is enabled, 0 means disabled. The debug
+options from the ``slab_debug`` parameter translate to the following files::
+
+ F sanity_checks
+ Z red_zone
+ P poison
+ U store_user
+ T trace
+ A failslab
+
+failslab file is writable, so writing 1 or 0 will enable or disable
+the option at runtime. Write returns -EINVAL if cache is an alias.
+Careful with tracing: It may spew out lots of information and never stop if
+used on the wrong slab.
+
+Slab merging
+============
+
+If no debug options are specified then SLUB may merge similar slabs together
+in order to reduce overhead and increase cache hotness of objects.
+``slabinfo -a`` displays which slabs were merged together.
+
+Slab validation
+===============
+
+SLUB can validate all object if the kernel was booted with slab_debug. In
+order to do so you must have the ``slabinfo`` tool. Then you can do
+::
+
+ slabinfo -v
+
+which will test all objects. Output will be generated to the syslog.
+
+This also works in a more limited way if boot was without slab debug.
+In that case ``slabinfo -v`` simply tests all reachable objects. Usually
+these are in the cpu slabs and the partial slabs. Full slabs are not
+tracked by SLUB in a non debug situation.
+
+Getting more performance
+========================
+
+To some degree SLUB's performance is limited by the need to take the
+list_lock once in a while to deal with partial slabs. That overhead is
+governed by the order of the allocation for each slab. The allocations
+can be influenced by kernel parameters:
+
+.. slab_min_objects=x (default: automatically scaled by number of cpus)
+.. slab_min_order=x (default 0)
+.. slab_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER))
+
+``slab_min_objects``
+ allows to specify how many objects must at least fit into one
+ slab in order for the allocation order to be acceptable. In
+ general slub will be able to perform this number of
+ allocations on a slab without consulting centralized resources
+ (list_lock) where contention may occur.
+
+``slab_min_order``
+ specifies a minimum order of slabs. A similar effect like
+ ``slab_min_objects``.
+
+``slab_max_order``
+ specified the order at which ``slab_min_objects`` should no
+ longer be checked. This is useful to avoid SLUB trying to
+ generate super large order pages to fit ``slab_min_objects``
+ of a slab cache with large object sizes into one high order
+ page. Setting command line parameter
+ ``debug_guardpage_minorder=N`` (N > 0), forces setting
+ ``slab_max_order`` to 0, what cause minimum possible order of
+ slabs allocation.
+
+``slab_strict_numa``
+ Enables the application of memory policies on each
+ allocation. This results in more accurate placement of
+ objects which may result in the reduction of accesses
+ to remote nodes. The default is to only apply memory
+ policies at the folio level when a new folio is acquired
+ or a folio is retrieved from the lists. Enabling this
+ option reduces the fastpath performance of the slab allocator.
+
+SLUB Debug output
+=================
+
+Here is a sample of slub debug output::
+
+ ====================================================================
+ BUG kmalloc-8: Right Redzone overwritten
+ --------------------------------------------------------------------
+
+ INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc
+ INFO: Slab 0xc528c530 flags=0x400000c3 inuse=61 fp=0xc90f6d58
+ INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58
+ INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554
+
+ Bytes b4 (0xc90f6d10): 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
+ Object (0xc90f6d20): 31 30 31 39 2e 30 30 35 1019.005
+ Redzone (0xc90f6d28): 00 cc cc cc .
+ Padding (0xc90f6d50): 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
+
+ [<c010523d>] dump_trace+0x63/0x1eb
+ [<c01053df>] show_trace_log_lvl+0x1a/0x2f
+ [<c010601d>] show_trace+0x12/0x14
+ [<c0106035>] dump_stack+0x16/0x18
+ [<c017e0fa>] object_err+0x143/0x14b
+ [<c017e2cc>] check_object+0x66/0x234
+ [<c017eb43>] __slab_free+0x239/0x384
+ [<c017f446>] kfree+0xa6/0xc6
+ [<c02e2335>] get_modalias+0xb9/0xf5
+ [<c02e23b7>] dmi_dev_uevent+0x27/0x3c
+ [<c027866a>] dev_uevent+0x1ad/0x1da
+ [<c0205024>] kobject_uevent_env+0x20a/0x45b
+ [<c020527f>] kobject_uevent+0xa/0xf
+ [<c02779f1>] store_uevent+0x4f/0x58
+ [<c027758e>] dev_attr_store+0x29/0x2f
+ [<c01bec4f>] sysfs_write_file+0x16e/0x19c
+ [<c0183ba7>] vfs_write+0xd1/0x15a
+ [<c01841d7>] sys_write+0x3d/0x72
+ [<c0104112>] sysenter_past_esp+0x5f/0x99
+ [<b7f7b410>] 0xb7f7b410
+ =======================
+
+ FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc
+
+If SLUB encounters a corrupted object (full detection requires the kernel
+to be booted with slab_debug) then the following output will be dumped
+into the syslog:
+
+1. Description of the problem encountered
+
+ This will be a message in the system log starting with::
+
+ ===============================================
+ BUG <slab cache affected>: <What went wrong>
+ -----------------------------------------------
+
+ INFO: <corruption start>-<corruption_end> <more info>
+ INFO: Slab <address> <slab information>
+ INFO: Object <address> <object information>
+ INFO: Allocated in <kernel function> age=<jiffies since alloc> cpu=<allocated by
+ cpu> pid=<pid of the process>
+ INFO: Freed in <kernel function> age=<jiffies since free> cpu=<freed by cpu>
+ pid=<pid of the process>
+
+ (Object allocation / free information is only available if SLAB_STORE_USER is
+ set for the slab. slab_debug sets that option)
+
+2. The object contents if an object was involved.
+
+ Various types of lines can follow the BUG SLUB line:
+
+ Bytes b4 <address> : <bytes>
+ Shows a few bytes before the object where the problem was detected.
+ Can be useful if the corruption does not stop with the start of the
+ object.
+
+ Object <address> : <bytes>
+ The bytes of the object. If the object is inactive then the bytes
+ typically contain poison values. Any non-poison value shows a
+ corruption by a write after free.
+
+ Redzone <address> : <bytes>
+ The Redzone following the object. The Redzone is used to detect
+ writes after the object. All bytes should always have the same
+ value. If there is any deviation then it is due to a write after
+ the object boundary.
+
+ (Redzone information is only available if SLAB_RED_ZONE is set.
+ slab_debug sets that option)
+
+ Padding <address> : <bytes>
+ Unused data to fill up the space in order to get the next object
+ properly aligned. In the debug case we make sure that there are
+ at least 4 bytes of padding. This allows the detection of writes
+ before the object.
+
+3. A stackdump
+
+ The stackdump describes the location where the error was detected. The cause
+ of the corruption is may be more likely found by looking at the function that
+ allocated or freed the object.
+
+4. Report on how the problem was dealt with in order to ensure the continued
+ operation of the system.
+
+ These are messages in the system log beginning with::
+
+ FIX <slab cache affected>: <corrective action taken>
+
+ In the above sample SLUB found that the Redzone of an active object has
+ been overwritten. Here a string of 8 characters was written into a slab that
+ has the length of 8 characters. However, a 8 character string needs a
+ terminating 0. That zero has overwritten the first byte of the Redzone field.
+ After reporting the details of the issue encountered the FIX SLUB message
+ tells us that SLUB has restored the Redzone to its proper value and then
+ system operations continue.
+
+Emergency operations
+====================
+
+Minimal debugging (sanity checks alone) can be enabled by booting with::
+
+ slab_debug=F
+
+This will be generally be enough to enable the resiliency features of slub
+which will keep the system running even if a bad kernel component will
+keep corrupting objects. This may be important for production systems.
+Performance will be impacted by the sanity checks and there will be a
+continual stream of error messages to the syslog but no additional memory
+will be used (unlike full debugging).
+
+No guarantees. The kernel component still needs to be fixed. Performance
+may be optimized further by locating the slab that experiences corruption
+and enabling debugging only for that cache
+
+I.e.::
+
+ slab_debug=F,dentry
+
+If the corruption occurs by writing after the end of the object then it
+may be advisable to enable a Redzone to avoid corrupting the beginning
+of other objects::
+
+ slab_debug=FZ,dentry
+
+Extended slabinfo mode and plotting
+===================================
+
+The ``slabinfo`` tool has a special 'extended' ('-X') mode that includes:
+ - Slabcache Totals
+ - Slabs sorted by size (up to -N <num> slabs, default 1)
+ - Slabs sorted by loss (up to -N <num> slabs, default 1)
+
+Additionally, in this mode ``slabinfo`` does not dynamically scale
+sizes (G/M/K) and reports everything in bytes (this functionality is
+also available to other slabinfo modes via '-B' option) which makes
+reporting more precise and accurate. Moreover, in some sense the `-X'
+mode also simplifies the analysis of slabs' behaviour, because its
+output can be plotted using the ``slabinfo-gnuplot.sh`` script. So it
+pushes the analysis from looking through the numbers (tons of numbers)
+to something easier -- visual analysis.
+
+To generate plots:
+
+a) collect slabinfo extended records, for example::
+
+ while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done
+
+b) pass stats file(-s) to ``slabinfo-gnuplot.sh`` script::
+
+ slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN]
+
+ The ``slabinfo-gnuplot.sh`` script will pre-processes the collected records
+ and generates 3 png files (and 3 pre-processing cache files) per STATS
+ file:
+ - Slabcache Totals: FOO_STATS-totals.png
+ - Slabs sorted by size: FOO_STATS-slabs-by-size.png
+ - Slabs sorted by loss: FOO_STATS-slabs-by-loss.png
+
+Another use case, when ``slabinfo-gnuplot.sh`` can be useful, is when you
+need to compare slabs' behaviour "prior to" and "after" some code
+modification. To help you out there, ``slabinfo-gnuplot.sh`` script
+can 'merge' the `Slabcache Totals` sections from different
+measurements. To visually compare N plots:
+
+a) Collect as many STATS1, STATS2, .. STATSN files as you need::
+
+ while [ 1 ]; do slabinfo -X >> STATS<X>; sleep 1; done
+
+b) Pre-process those STATS files::
+
+ slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN
+
+c) Execute ``slabinfo-gnuplot.sh`` in '-t' mode, passing all of the
+ generated pre-processed \*-totals::
+
+ slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals
+
+ This will produce a single plot (png file).
+
+ Plots, expectedly, can be large so some fluctuations or small spikes
+ can go unnoticed. To deal with that, ``slabinfo-gnuplot.sh`` has two
+ options to 'zoom-in'/'zoom-out':
+
+ a) ``-s %d,%d`` -- overwrites the default image width and height
+ b) ``-r %d,%d`` -- specifies a range of samples to use (for example,
+ in ``slabinfo -X >> FOO_STATS; sleep 1;`` case, using a ``-r
+ 40,60`` range will plot only samples collected between 40th and
+ 60th seconds).
+
+
+DebugFS files for SLUB
+======================
+
+For more information about current state of SLUB caches with the user tracking
+debug option enabled, debugfs files are available, typically under
+/sys/kernel/debug/slab/<cache>/ (created only for caches with enabled user
+tracking). There are 2 types of these files with the following debug
+information:
+
+1. alloc_traces::
+
+ Prints information about unique allocation traces of the currently
+ allocated objects. The output is sorted by frequency of each trace.
+
+ Information in the output:
+ Number of objects, allocating function, possible memory wastage of
+ kmalloc objects(total/per-object), minimal/average/maximal jiffies
+ since alloc, pid range of the allocating processes, cpu mask of
+ allocating cpus, numa node mask of origins of memory, and stack trace.
+
+ Example:::
+
+ 338 pci_alloc_dev+0x2c/0xa0 waste=521872/1544 age=290837/291891/293509 pid=1 cpus=106 nodes=0-1
+ __kmem_cache_alloc_node+0x11f/0x4e0
+ kmalloc_trace+0x26/0xa0
+ pci_alloc_dev+0x2c/0xa0
+ pci_scan_single_device+0xd2/0x150
+ pci_scan_slot+0xf7/0x2d0
+ pci_scan_child_bus_extend+0x4e/0x360
+ acpi_pci_root_create+0x32e/0x3b0
+ pci_acpi_scan_root+0x2b9/0x2d0
+ acpi_pci_root_add.cold.11+0x110/0xb0a
+ acpi_bus_attach+0x262/0x3f0
+ device_for_each_child+0xb7/0x110
+ acpi_dev_for_each_child+0x77/0xa0
+ acpi_bus_attach+0x108/0x3f0
+ device_for_each_child+0xb7/0x110
+ acpi_dev_for_each_child+0x77/0xa0
+ acpi_bus_attach+0x108/0x3f0
+
+2. free_traces::
+
+ Prints information about unique freeing traces of the currently allocated
+ objects. The freeing traces thus come from the previous life-cycle of the
+ objects and are reported as not available for objects allocated for the first
+ time. The output is sorted by frequency of each trace.
+
+ Information in the output:
+ Number of objects, freeing function, minimal/average/maximal jiffies since free,
+ pid range of the freeing processes, cpu mask of freeing cpus, and stack trace.
+
+ Example:::
+
+ 1980 <not-available> age=4294912290 pid=0 cpus=0
+ 51 acpi_ut_update_ref_count+0x6a6/0x782 age=236886/237027/237772 pid=1 cpus=1
+ kfree+0x2db/0x420
+ acpi_ut_update_ref_count+0x6a6/0x782
+ acpi_ut_update_object_reference+0x1ad/0x234
+ acpi_ut_remove_reference+0x7d/0x84
+ acpi_rs_get_prt_method_data+0x97/0xd6
+ acpi_get_irq_routing_table+0x82/0xc4
+ acpi_pci_irq_find_prt_entry+0x8e/0x2e0
+ acpi_pci_irq_lookup+0x3a/0x1e0
+ acpi_pci_irq_enable+0x77/0x240
+ pcibios_enable_device+0x39/0x40
+ do_pci_enable_device.part.0+0x5d/0xe0
+ pci_enable_device_flags+0xfc/0x120
+ pci_enable_device+0x13/0x20
+ virtio_pci_probe+0x9e/0x170
+ local_pci_probe+0x48/0x80
+ pci_device_probe+0x105/0x1c0
+
+Christoph Lameter, May 30, 2007
+Sergey Senozhatsky, October 23, 2015
diff --git a/Documentation/admin-guide/mm/soft-dirty.rst b/Documentation/admin-guide/mm/soft-dirty.rst
index cb0cfd6672fa..aeea936caa44 100644
--- a/Documentation/admin-guide/mm/soft-dirty.rst
+++ b/Documentation/admin-guide/mm/soft-dirty.rst
@@ -1,5 +1,3 @@
-.. _soft_dirty:
-
===============
Soft-Dirty PTEs
===============
diff --git a/Documentation/admin-guide/mm/swap_numa.rst b/Documentation/admin-guide/mm/swap_numa.rst
deleted file mode 100644
index e0466f2db8fa..000000000000
--- a/Documentation/admin-guide/mm/swap_numa.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-.. _swap_numa:
-
-===========================================
-Automatically bind swap device to numa node
-===========================================
-
-If the system has more than one swap device and swap device has the node
-information, we can make use of this information to decide which swap
-device to use in get_swap_pages() to get better performance.
-
-
-How to use this feature
-=======================
-
-Swap device has priority and that decides the order of it to be used. To make
-use of automatically binding, there is no need to manipulate priority settings
-for swap devices. e.g. on a 2 node machine, assume 2 swap devices swapA and
-swapB, with swapA attached to node 0 and swapB attached to node 1, are going
-to be swapped on. Simply swapping them on by doing::
-
- # swapon /dev/swapA
- # swapon /dev/swapB
-
-Then node 0 will use the two swap devices in the order of swapA then swapB and
-node 1 will use the two swap devices in the order of swapB then swapA. Note
-that the order of them being swapped on doesn't matter.
-
-A more complex example on a 4 node machine. Assume 6 swap devices are going to
-be swapped on: swapA and swapB are attached to node 0, swapC is attached to
-node 1, swapD and swapE are attached to node 2 and swapF is attached to node3.
-The way to swap them on is the same as above::
-
- # swapon /dev/swapA
- # swapon /dev/swapB
- # swapon /dev/swapC
- # swapon /dev/swapD
- # swapon /dev/swapE
- # swapon /dev/swapF
-
-Then node 0 will use them in the order of::
-
- swapA/swapB -> swapC -> swapD -> swapE -> swapF
-
-swapA and swapB will be used in a round robin mode before any other swap device.
-
-node 1 will use them in the order of::
-
- swapC -> swapA -> swapB -> swapD -> swapE -> swapF
-
-node 2 will use them in the order of::
-
- swapD/swapE -> swapA -> swapB -> swapC -> swapF
-
-Similaly, swapD and swapE will be used in a round robin mode before any
-other swap devices.
-
-node 3 will use them in the order of::
-
- swapF -> swapA -> swapB -> swapC -> swapD -> swapE
-
-
-Implementation details
-======================
-
-The current code uses a priority based list, swap_avail_list, to decide
-which swap device to use and if multiple swap devices share the same
-priority, they are used round robin. This change here replaces the single
-global swap_avail_list with a per-numa-node list, i.e. for each numa node,
-it sees its own priority based list of available swap devices. Swap
-device's priority can be promoted on its matching node's swap_avail_list.
-
-The current swap device's priority is set as: user can set a >=0 value,
-or the system will pick one starting from -1 then downwards. The priority
-value in the swap_avail_list is the negated value of the swap device's
-due to plist being sorted from low to high. The new policy doesn't change
-the semantics for priority >=0 cases, the previous starting from -1 then
-downwards now becomes starting from -2 then downwards and -1 is reserved
-as the promoted value. So if multiple swap devices are attached to the same
-node, they will all be promoted to priority -1 on that node's plist and will
-be used round robin before any other swap devices.
diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
index c9c37f16eef8..5fbc3d89bb07 100644
--- a/Documentation/admin-guide/mm/transhuge.rst
+++ b/Documentation/admin-guide/mm/transhuge.rst
@@ -1,5 +1,3 @@
-.. _admin_guide_transhuge:
-
============================
Transparent Hugepage Support
============================
@@ -47,10 +45,25 @@ components:
the two is using hugepages just because of the fact the TLB miss is
going to run faster.
+Modern kernels support "multi-size THP" (mTHP), which introduces the
+ability to allocate memory in blocks that are bigger than a base page
+but smaller than traditional PMD-size (as described above), in
+increments of a power-of-2 number of pages. mTHP can back anonymous
+memory (for example 16K, 32K, 64K, etc). These THPs continue to be
+PTE-mapped, but in many cases can still provide similar benefits to
+those outlined above: Page faults are significantly reduced (by a
+factor of e.g. 4, 8, 16, etc), but latency spikes are much less
+prominent because the size of each page isn't as huge as the PMD-sized
+variant and there is less memory to clear in each page fault. Some
+architectures also employ TLB compression mechanisms to squeeze more
+entries in when a set of PTEs are virtually and physically contiguous
+and approporiately aligned. In this case, TLB misses will occur less
+often.
+
THP can be enabled system wide or restricted to certain tasks or even
memory ranges inside task's address space. Unless THP is completely
disabled, there is ``khugepaged`` daemon that scans memory and
-collapses sequences of basic pages into huge pages.
+collapses sequences of basic pages into PMD-sized huge pages.
The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
interface and using madvise(2) and prctl(2) system calls.
@@ -94,15 +107,48 @@ sysfs
Global THP controls
-------------------
-Transparent Hugepage Support for anonymous memory can be entirely disabled
+Transparent Hugepage Support for anonymous memory can be disabled
(mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
regions (to avoid the risk of consuming more memory resources) or enabled
-system wide. This can be achieved with one of::
+system wide. This can be achieved per-supported-THP-size with one of::
+
+ echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+ echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+ echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+
+where <size> is the hugepage size being addressed, the available sizes
+for which vary by system.
+
+.. note:: Setting "never" in all sysfs THP controls does **not** disable
+ Transparent Huge Pages globally. This is because ``madvise(...,
+ MADV_COLLAPSE)`` ignores these settings and collapses ranges to
+ PMD-sized huge pages unconditionally.
+
+For example::
+
+ echo always >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
+
+Alternatively it is possible to specify that a given hugepage size
+will inherit the top-level "enabled" value::
+
+ echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
+
+For example::
+
+ echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
+
+The top-level setting (for use with "inherit") can be set by issuing
+one of the following commands::
echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled
+By default, PMD-sized hugepages have enabled="inherit" and all other
+hugepage sizes have enabled="never". If enabling multiple hugepage
+sizes, the kernel will select the most appropriate enabled size for a
+given allocation.
+
It's also possible to limit defrag efforts in the VM to generate
anonymous hugepages in case they're not immediately free to madvise
regions or to never try to defrag memory and simply fallback to regular
@@ -146,27 +192,83 @@ madvise
behaviour.
never
- should be self-explanatory.
+ should be self-explanatory. Note that ``madvise(...,
+ MADV_COLLAPSE)`` can still cause transparent huge pages to be
+ obtained even if this mode is specified everywhere.
-By default kernel tries to use huge zero page on read page fault to
-anonymous mapping. It's possible to disable huge zero page by writing 0
-or enable it back by writing 1::
+By default kernel tries to use huge, PMD-mappable zero page on read
+page fault to anonymous mapping. It's possible to disable huge zero
+page by writing 0 or enable it back by writing 1::
echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
-Some userspace (such as a test program, or an optimized memory allocation
-library) may want to know the size (in bytes) of a transparent hugepage::
+Some userspace (such as a test program, or an optimized memory
+allocation library) may want to know the size (in bytes) of a
+PMD-mappable transparent hugepage::
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
-khugepaged will be automatically started when
-transparent_hugepage/enabled is set to "always" or "madvise, and it'll
-be automatically shutdown if it's set to "never".
+All THPs at fault and collapse time will be added to _deferred_list,
+and will therefore be split under memory presure if they are considered
+"underused". A THP is underused if the number of zero-filled pages in
+the THP is above max_ptes_none (see below). It is possible to disable
+this behaviour by writing 0 to shrink_underused, and enable it by writing
+1 to it::
+
+ echo 0 > /sys/kernel/mm/transparent_hugepage/shrink_underused
+ echo 1 > /sys/kernel/mm/transparent_hugepage/shrink_underused
+
+khugepaged will be automatically started when PMD-sized THP is enabled
+(either of the per-size anon control or the top-level control are set
+to "always" or "madvise"), and it'll be automatically shutdown when
+PMD-sized THP is disabled (when both the per-size anon control and the
+top-level control are "never")
+
+process THP controls
+--------------------
+
+A process can control its own THP behaviour using the ``PR_SET_THP_DISABLE``
+and ``PR_GET_THP_DISABLE`` pair of prctl(2) calls. The THP behaviour set using
+``PR_SET_THP_DISABLE`` is inherited across fork(2) and execve(2). These calls
+support the following arguments::
+
+ prctl(PR_SET_THP_DISABLE, 1, 0, 0, 0):
+ This will disable THPs completely for the process, irrespective
+ of global THP controls or madvise(..., MADV_COLLAPSE) being used.
+
+ prctl(PR_SET_THP_DISABLE, 1, PR_THP_DISABLE_EXCEPT_ADVISED, 0, 0):
+ This will disable THPs for the process except when the usage of THPs is
+ advised. Consequently, THPs will only be used when:
+ - Global THP controls are set to "always" or "madvise" and
+ madvise(..., MADV_HUGEPAGE) or madvise(..., MADV_COLLAPSE) is used.
+ - Global THP controls are set to "never" and madvise(..., MADV_COLLAPSE)
+ is used. This is the same behavior as if THPs would not be disabled on
+ a process level.
+ Note that MADV_COLLAPSE is currently always rejected if
+ madvise(..., MADV_NOHUGEPAGE) is set on an area.
+
+ prctl(PR_SET_THP_DISABLE, 0, 0, 0, 0):
+ This will re-enable THPs for the process, as if they were never disabled.
+ Whether THPs will actually be used depends on global THP controls and
+ madvise() calls.
+
+ prctl(PR_GET_THP_DISABLE, 0, 0, 0, 0):
+ This returns a value whose bits indicate how THP-disable is configured:
+ Bits
+ 1 0 Value Description
+ |0|0| 0 No THP-disable behaviour specified.
+ |0|1| 1 THP is entirely disabled for this process.
+ |1|1| 3 THP-except-advised mode is set for this process.
Khugepaged controls
-------------------
+.. note::
+ khugepaged currently only searches for opportunities to collapse to
+ PMD-sized THP and no attempt is made to collapse to other THP
+ sizes.
+
khugepaged runs usually at low frequency so while one may not want to
invoke defrag algorithms synchronously during the page faults, it
should be worth invoking defrag at least in khugepaged. However it's
@@ -191,7 +293,14 @@ allocation failure to throttle the next allocation attempt::
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs
-The khugepaged progress can be seen in the number of pages collapsed::
+The khugepaged progress can be seen in the number of pages collapsed (note
+that this counter may not be an exact count of the number of pages
+collapsed, since "collapsed" could mean multiple things: (1) A PTE mapping
+being replaced by a PMD mapping, or (2) All 4K physical pages replaced by
+one 2M hugepage. Each may happen independently, or together, depending on
+the type of memory and the failures that occur. As such, this value should
+be interpreted roughly as a sign of progress, and counters in /proc/vmstat
+consulted for more accurate accounting)::
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed
@@ -221,52 +330,130 @@ collapsed, resulting fewer pages being collapsed into
THPs, and lower memory access performance.
``max_ptes_shared`` specifies how many pages can be shared across multiple
-processes. Exceeding the number would block the collapse::
+processes. khugepaged might treat pages of THPs as shared if any page of
+that THP is shared. Exceeding the number would block the collapse::
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared
A higher value may increase memory footprint for some workloads.
-Boot parameter
-==============
-
-You can change the sysfs boot time defaults of Transparent Hugepage
-Support by passing the parameter ``transparent_hugepage=always`` or
-``transparent_hugepage=madvise`` or ``transparent_hugepage=never``
-to the kernel command line.
+Boot parameters
+===============
+
+You can change the sysfs boot time default for the top-level "enabled"
+control by passing the parameter ``transparent_hugepage=always`` or
+``transparent_hugepage=madvise`` or ``transparent_hugepage=never`` to the
+kernel command line.
+
+Alternatively, each supported anonymous THP size can be controlled by
+passing ``thp_anon=<size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>``,
+where ``<size>`` is the THP size (must be a power of 2 of PAGE_SIZE and
+supported anonymous THP) and ``<state>`` is one of ``always``, ``madvise``,
+``never`` or ``inherit``.
+
+For example, the following will set 16K, 32K, 64K THP to ``always``,
+set 128K, 512K to ``inherit``, set 256K to ``madvise`` and 1M, 2M
+to ``never``::
+
+ thp_anon=16K-64K:always;128K,512K:inherit;256K:madvise;1M-2M:never
+
+``thp_anon=`` may be specified multiple times to configure all THP sizes as
+required. If ``thp_anon=`` is specified at least once, any anon THP sizes
+not explicitly configured on the command line are implicitly set to
+``never``.
+
+``transparent_hugepage`` setting only affects the global toggle. If
+``thp_anon`` is not specified, PMD_ORDER THP will default to ``inherit``.
+However, if a valid ``thp_anon`` setting is provided by the user, the
+PMD_ORDER THP policy will be overridden. If the policy for PMD_ORDER
+is not defined within a valid ``thp_anon``, its policy will default to
+``never``.
+
+Similarly to ``transparent_hugepage``, you can control the hugepage
+allocation policy for the internal shmem mount by using the kernel parameter
+``transparent_hugepage_shmem=<policy>``, where ``<policy>`` is one of the
+seven valid policies for shmem (``always``, ``within_size``, ``advise``,
+``never``, ``deny``, and ``force``).
+
+Similarly to ``transparent_hugepage_shmem``, you can control the default
+hugepage allocation policy for the tmpfs mount by using the kernel parameter
+``transparent_hugepage_tmpfs=<policy>``, where ``<policy>`` is one of the
+four valid policies for tmpfs (``always``, ``within_size``, ``advise``,
+``never``). The tmpfs mount default policy is ``never``.
+
+Additionally, Kconfig options are available to set the default hugepage
+policies for shmem (``CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_*``) and tmpfs
+(``CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_*``) at build time. Refer to the
+Kconfig help for more details.
+
+In the same manner as ``thp_anon`` controls each supported anonymous THP
+size, ``thp_shmem`` controls each supported shmem THP size. ``thp_shmem``
+has the same format as ``thp_anon``, but also supports the policy
+``within_size``.
+
+``thp_shmem=`` may be specified multiple times to configure all THP sizes
+as required. If ``thp_shmem=`` is specified at least once, any shmem THP
+sizes not explicitly configured on the command line are implicitly set to
+``never``.
+
+``transparent_hugepage_shmem`` setting only affects the global toggle. If
+``thp_shmem`` is not specified, PMD_ORDER hugepage will default to
+``inherit``. However, if a valid ``thp_shmem`` setting is provided by the
+user, the PMD_ORDER hugepage policy will be overridden. If the policy for
+PMD_ORDER is not defined within a valid ``thp_shmem``, its policy will
+default to ``never``.
Hugepages in tmpfs/shmem
========================
-You can control hugepage allocation policy in tmpfs with mount option
-``huge=``. It can have following values:
+Traditionally, tmpfs only supported a single huge page size ("PMD"). Today,
+it also supports smaller sizes just like anonymous memory, often referred
+to as "multi-size THP" (mTHP). Huge pages of any size are commonly
+represented in the kernel as "large folios".
+
+While there is fine control over the huge page sizes to use for the internal
+shmem mount (see below), ordinary tmpfs mounts will make use of all available
+huge page sizes without any control over the exact sizes, behaving more like
+other file systems.
+
+tmpfs mounts
+------------
+
+The THP allocation policy for tmpfs mounts can be adjusted using the mount
+option: ``huge=``. It can have following values:
always
Attempt to allocate huge pages every time we need a new page;
+ Always try PMD-sized huge pages first, and fall back to smaller-sized
+ huge pages if the PMD-sized huge page allocation fails;
never
- Do not allocate huge pages;
+ Do not allocate huge pages. Note that ``madvise(..., MADV_COLLAPSE)``
+ can still cause transparent huge pages to be obtained even if this mode
+ is specified everywhere;
within_size
- Only allocate huge page if it will be fully within i_size.
- Also respect fadvise()/madvise() hints;
+ Only allocate huge page if it will be fully within i_size;
+ Always try PMD-sized huge pages first, and fall back to smaller-sized
+ huge pages if the PMD-sized huge page allocation fails;
+ Also respect madvise() hints;
advise
- Only allocate huge pages if requested with fadvise()/madvise();
+ Only allocate huge pages if requested with madvise();
+
+Remember, that the kernel may use huge pages of all available sizes, and
+that no fine control as for the internal tmpfs mount is available.
-The default policy is ``never``.
+The default policy in the past was ``never``, but it can now be adjusted
+using the kernel parameter ``transparent_hugepage_tmpfs=<policy>``.
``mount -o remount,huge= /mountpoint`` works fine after mount: remounting
``huge=never`` will not attempt to break up huge pages at all, just stop more
from being allocated.
-There's also sysfs knob to control hugepage allocation policy for internal
-shmem mount: /sys/kernel/mm/transparent_hugepage/shmem_enabled. The mount
-is used for SysV SHM, memfds, shared anonymous mmaps (of /dev/zero or
-MAP_ANONYMOUS), GPU drivers' DRM objects, Ashmem.
-
-In addition to policies listed above, shmem_enabled allows two further
-values:
+In addition to policies listed above, the sysfs knob
+/sys/kernel/mm/transparent_hugepage/shmem_enabled will affect the
+allocation policy of tmpfs mounts, when set to the following values:
deny
For use in emergencies, to force the huge option off from
@@ -274,27 +461,68 @@ deny
force
Force the huge option on for all - very useful for testing;
+shmem / internal tmpfs
+----------------------
+The mount internal tmpfs mount is used for SysV SHM, memfds, shared anonymous
+mmaps (of /dev/zero or MAP_ANONYMOUS), GPU drivers' DRM objects, Ashmem.
+
+To control the THP allocation policy for this internal tmpfs mount, the
+sysfs knob /sys/kernel/mm/transparent_hugepage/shmem_enabled and the knobs
+per THP size in
+'/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/shmem_enabled'
+can be used.
+
+The global knob has the same semantics as the ``huge=`` mount options
+for tmpfs mounts, except that the different huge page sizes can be controlled
+individually, and will only use the setting of the global knob when the
+per-size knob is set to 'inherit'.
+
+The options 'force' and 'deny' are dropped for the individual sizes, which
+are rather testing artifacts from the old ages.
+
+always
+ Attempt to allocate <size> huge pages every time we need a new page;
+
+inherit
+ Inherit the top-level "shmem_enabled" value. By default, PMD-sized hugepages
+ have enabled="inherit" and all other hugepage sizes have enabled="never";
+
+never
+ Do not allocate <size> huge pages. Note that ``madvise(...,
+ MADV_COLLAPSE)`` can still cause transparent huge pages to be obtained
+ even if this mode is specified everywhere;
+
+within_size
+ Only allocate <size> huge page if it will be fully within i_size.
+ Also respect madvise() hints;
+
+advise
+ Only allocate <size> huge pages if requested with madvise();
+
Need of application restart
===========================
-The transparent_hugepage/enabled values and tmpfs mount option only affect
-future behavior. So to make them effective you need to restart any
-application that could have been using hugepages. This also applies to the
-regions registered in khugepaged.
+The transparent_hugepage/enabled and
+transparent_hugepage/hugepages-<size>kB/enabled values and tmpfs mount
+option only affect future behavior. So to make them effective you need
+to restart any application that could have been using hugepages. This
+also applies to the regions registered in khugepaged.
Monitoring usage
================
-The number of anonymous transparent huge pages currently used by the
+The number of PMD-sized anonymous transparent huge pages currently used by the
system is available by reading the AnonHugePages field in ``/proc/meminfo``.
-To identify what applications are using anonymous transparent huge pages,
-it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
-for each mapping.
+To identify what applications are using PMD-sized anonymous transparent huge
+pages, it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages
+fields for each mapping. (Note that AnonHugePages only applies to traditional
+PMD-sized THP for historical reasons and should have been called
+AnonHugePmdMapped).
The number of file transparent huge pages mapped to userspace is available
by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
To identify what applications are mapping file transparent huge pages, it
-is necessary to read ``/proc/PID/smaps`` and count the FileHugeMapped fields
+is necessary to read ``/proc/PID/smaps`` and count the FilePmdMapped fields
for each mapping.
Note that reading the smaps file is expensive and reading it
@@ -305,7 +533,7 @@ monitor how successfully the system is providing huge pages for use.
thp_fault_alloc
is incremented every time a huge page is successfully
- allocated to handle a page fault.
+ allocated and charged to handle a page fault.
thp_collapse_alloc
is incremented by khugepaged when it has found
@@ -313,7 +541,7 @@ thp_collapse_alloc
successfully allocated a new huge page to store the data.
thp_fault_fallback
- is incremented if a page fault fails to allocate
+ is incremented if a page fault fails to allocate or charge
a huge page and instead falls back to using small pages.
thp_fault_fallback_charge
@@ -327,20 +555,23 @@ thp_collapse_alloc_failed
the allocation.
thp_file_alloc
- is incremented every time a file huge page is successfully
- allocated.
+ is incremented every time a shmem huge page is successfully
+ allocated (Note that despite being named after "file", the counter
+ measures only shmem).
thp_file_fallback
- is incremented if a file huge page is attempted to be allocated
- but fails and instead falls back to using small pages.
+ is incremented if a shmem huge page is attempted to be allocated
+ but fails and instead falls back to using small pages. (Note that
+ despite being named after "file", the counter measures only shmem).
thp_file_fallback_charge
- is incremented if a file huge page cannot be charged and instead
+ is incremented if a shmem huge page cannot be charged and instead
falls back to using small pages even though the allocation was
- successful.
+ successful. (Note that despite being named after "file", the
+ counter measures only shmem).
thp_file_mapped
- is incremented every time a file huge page is mapped into
+ is incremented every time a file or shmem huge page is mapped into
user address space.
thp_split_page
@@ -359,6 +590,12 @@ thp_deferred_split_page
splitting it would free up some memory. Pages on split queue are
going to be split under memory pressure.
+thp_underused_split_page
+ is incremented when a huge page on the split queue was split
+ because it was underused. A THP is underused if the number of
+ zero pages in the THP is above a certain threshold
+ (/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none).
+
thp_split_pmd
is incremented every time a PMD split into table of PTEs.
This can happen, for instance, when application calls mprotect() or
@@ -366,10 +603,9 @@ thp_split_pmd
page table entry.
thp_zero_page_alloc
- is incremented every time a huge zero page is
- successfully allocated. It includes allocations which where
- dropped due race with other allocation. Note, it doesn't count
- every map of the huge zero page, only its allocation.
+ is incremented every time a huge zero page used for thp is
+ successfully allocated. Note, it doesn't count every map of
+ the huge zero page, only its allocation.
thp_zero_page_alloc_failed
is incremented if kernel fails to allocate
@@ -384,6 +620,92 @@ thp_swpout_fallback
Usually because failed to allocate some continuous swap space
for the huge page.
+In /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats, There are
+also individual counters for each huge page size, which can be utilized to
+monitor the system's effectiveness in providing huge pages for usage. Each
+counter has its own corresponding file.
+
+anon_fault_alloc
+ is incremented every time a huge page is successfully
+ allocated and charged to handle a page fault.
+
+anon_fault_fallback
+ is incremented if a page fault fails to allocate or charge
+ a huge page and instead falls back to using huge pages with
+ lower orders or small pages.
+
+anon_fault_fallback_charge
+ is incremented if a page fault fails to charge a huge page and
+ instead falls back to using huge pages with lower orders or
+ small pages even though the allocation was successful.
+
+zswpout
+ is incremented every time a huge page is swapped out to zswap in one
+ piece without splitting.
+
+swpin
+ is incremented every time a huge page is swapped in from a non-zswap
+ swap device in one piece.
+
+swpin_fallback
+ is incremented if swapin fails to allocate or charge a huge page
+ and instead falls back to using huge pages with lower orders or
+ small pages.
+
+swpin_fallback_charge
+ is incremented if swapin fails to charge a huge page and instead
+ falls back to using huge pages with lower orders or small pages
+ even though the allocation was successful.
+
+swpout
+ is incremented every time a huge page is swapped out to a non-zswap
+ swap device in one piece without splitting.
+
+swpout_fallback
+ is incremented if a huge page has to be split before swapout.
+ Usually because failed to allocate some continuous swap space
+ for the huge page.
+
+shmem_alloc
+ is incremented every time a shmem huge page is successfully
+ allocated.
+
+shmem_fallback
+ is incremented if a shmem huge page is attempted to be allocated
+ but fails and instead falls back to using small pages.
+
+shmem_fallback_charge
+ is incremented if a shmem huge page cannot be charged and instead
+ falls back to using small pages even though the allocation was
+ successful.
+
+split
+ is incremented every time a huge page is successfully split into
+ smaller orders. This can happen for a variety of reasons but a
+ common reason is that a huge page is old and is being reclaimed.
+
+split_failed
+ is incremented if kernel fails to split huge
+ page. This can happen if the page was pinned by somebody.
+
+split_deferred
+ is incremented when a huge page is put onto split queue.
+ This happens when a huge page is partially unmapped and splitting
+ it would free up some memory. Pages on split queue are going to
+ be split under memory pressure, if splitting is possible.
+
+nr_anon
+ the number of anonymous THP we have in the whole system. These THPs
+ might be currently entirely mapped or have partially unmapped/unused
+ subpages.
+
+nr_anon_partially_mapped
+ the number of anonymous THP which are likely partially mapped, possibly
+ wasting memory, and have been queued for deferred memory reclamation.
+ Note that in corner some cases (e.g., failed migration), we might detect
+ an anonymous THP as "partially mapped" and count it here, even though it
+ is not actually partially mapped anymore.
+
As the system ages, allocating huge pages may be expensive as the
system uses memory compaction to copy data around memory to free a
huge page for use. There are some counters in ``/proc/vmstat`` to help
@@ -409,7 +731,7 @@ for huge pages.
Optimizing the applications
===========================
-To be guaranteed that the kernel will map a 2M page immediately in any
+To be guaranteed that the kernel will map a THP immediately in any
memory region, the mmap region has to be hugepage naturally
aligned. posix_memalign() can provide that guarantee.
diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
index 6528036093e1..e5cc8848dcb3 100644
--- a/Documentation/admin-guide/mm/userfaultfd.rst
+++ b/Documentation/admin-guide/mm/userfaultfd.rst
@@ -1,5 +1,3 @@
-.. _userfaultfd:
-
===========
Userfaultfd
===========
@@ -17,7 +15,10 @@ of the ``PROT_NONE+SIGSEGV`` trick.
Design
======
-Userfaults are delivered and resolved through the ``userfaultfd`` syscall.
+Userspace creates a new userfaultfd, initializes it, and registers one or more
+regions of virtual memory with it. Then, any page faults which occur within the
+region(s) result in a message being delivered to the userfaultfd, notifying
+userspace of the fault.
The ``userfaultfd`` (aside from registering and unregistering virtual
memory ranges) provides two primary functionalities:
@@ -34,12 +35,11 @@ The real advantage of userfaults if compared to regular virtual memory
management of mremap/mprotect is that the userfaults in all their
operations never involve heavyweight structures like vmas (in fact the
``userfaultfd`` runtime load never takes the mmap_lock for writing).
-
Vmas are not suitable for page- (or hugepage) granular fault tracking
when dealing with virtual address spaces that could span
Terabytes. Too many vmas would be needed for that.
-The ``userfaultfd`` once opened by invoking the syscall, can also be
+The ``userfaultfd``, once created, can also be
passed using unix domain sockets to a manager process, so the same
manager process could handle the userfaults of a multitude of
different processes without them being aware about what is going on
@@ -50,6 +50,39 @@ is a corner case that would currently return ``-EBUSY``).
API
===
+Creating a userfaultfd
+----------------------
+
+There are two ways to create a new userfaultfd, each of which provide ways to
+restrict access to this functionality (since historically userfaultfds which
+handle kernel page faults have been a useful tool for exploiting the kernel).
+
+The first way, supported since userfaultfd was introduced, is the
+userfaultfd(2) syscall. Access to this is controlled in several ways:
+
+- Any user can always create a userfaultfd which traps userspace page faults
+ only. Such a userfaultfd can be created using the userfaultfd(2) syscall
+ with the flag UFFD_USER_MODE_ONLY.
+
+- In order to also trap kernel page faults for the address space, either the
+ process needs the CAP_SYS_PTRACE capability, or the system must have
+ vm.unprivileged_userfaultfd set to 1. By default, vm.unprivileged_userfaultfd
+ is set to 0.
+
+The second way, added to the kernel more recently, is by opening
+/dev/userfaultfd and issuing a USERFAULTFD_IOC_NEW ioctl to it. This method
+yields equivalent userfaultfds to the userfaultfd(2) syscall.
+
+Unlike userfaultfd(2), access to /dev/userfaultfd is controlled via normal
+filesystem permissions (user/group/mode), which gives fine grained access to
+userfaultfd specifically, without also granting other unrelated privileges at
+the same time (as e.g. granting CAP_SYS_PTRACE would do). Users who have access
+to /dev/userfaultfd can always create userfaultfds that trap kernel page faults;
+vm.unprivileged_userfaultfd is not considered.
+
+Initializing a userfaultfd
+--------------------------
+
When first opened the ``userfaultfd`` must be enabled invoking the
``UFFDIO_API`` ioctl specifying a ``uffdio_api.api`` value set to ``UFFD_API`` (or
a later API version) which will specify the ``read/POLLIN`` protocol
@@ -80,6 +113,9 @@ events, except page fault notifications, may be generated:
areas. ``UFFD_FEATURE_MINOR_SHMEM`` is the analogous feature indicating
support for shmem virtual memory areas.
+- ``UFFD_FEATURE_MOVE`` indicates that the kernel supports moving an
+ existing page contents from userspace.
+
The userland application should set the feature flags it intends to use
when invoking the ``UFFDIO_API`` ioctl, to request that those features be
enabled if supported.
@@ -186,6 +222,81 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
used.
+Userfaultfd write-protect mode currently behave differently on none ptes
+(when e.g. page is missing) over different types of memories.
+
+For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
+(e.g. when pages are missing and not populated). For file-backed memories
+like shmem and hugetlbfs, none ptes will be write protected just like a
+present pte. In other words, there will be a userfaultfd write fault
+message generated when writing to a missing page on file typed memories,
+as long as the page range was write-protected before. Such a message will
+not be generated on anonymous memories by default.
+
+If the application wants to be able to write protect none ptes on anonymous
+memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ. On
+newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
+and set the feature bit in advance to make sure none ptes will also be
+write protected even upon anonymous memory.
+
+When using ``UFFDIO_REGISTER_MODE_WP`` in combination with either
+``UFFDIO_REGISTER_MODE_MISSING`` or ``UFFDIO_REGISTER_MODE_MINOR``, when
+resolving missing / minor faults with ``UFFDIO_COPY`` or ``UFFDIO_CONTINUE``
+respectively, it may be desirable for the new page / mapping to be
+write-protected (so future writes will also result in a WP fault). These ioctls
+support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
+respectively) to configure the mapping this way.
+
+If the userfaultfd context has ``UFFD_FEATURE_WP_ASYNC`` feature bit set,
+any vma registered with write-protection will work in async mode rather
+than the default sync mode.
+
+In async mode, there will be no message generated when a write operation
+happens, meanwhile the write-protection will be resolved automatically by
+the kernel. It can be seen as a more accurate version of soft-dirty
+tracking and it can be different in a few ways:
+
+ - The dirty result will not be affected by vma changes (e.g. vma
+ merging) because the dirty is only tracked by the pte.
+
+ - It supports range operations by default, so one can enable tracking on
+ any range of memory as long as page aligned.
+
+ - Dirty information will not get lost if the pte was zapped due to
+ various reasons (e.g. during split of a shmem transparent huge page).
+
+ - Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
+ set; dirty when uffd-wp bit cleared), it has different semantics on
+ some of the memory operations. For example: ``MADV_DONTNEED`` on
+ anonymous (or ``MADV_REMOVE`` on a file mapping) will be treated as
+ dirtying of memory by dropping uffd-wp bit during the procedure.
+
+The user app can collect the "written/dirty" status by looking up the
+uffd-wp bit for the pages being interested in /proc/pagemap.
+
+The page will not be under track of uffd-wp async mode until the page is
+explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
+flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault
+that was tracked by async mode userfaultfd-wp is invalid.
+
+When userfaultfd-wp async mode is used alone, it can be applied to all
+kinds of memory.
+
+Memory Poisioning Emulation
+---------------------------
+
+In response to a fault (either missing or minor), an action userspace can
+take to "resolve" it is to issue a ``UFFDIO_POISON``. This will cause any
+future faulters to either get a SIGBUS, or in KVM's case the guest will
+receive an MCE as if there were hardware memory poisoning.
+
+This is used to emulate hardware memory poisoning. Imagine a VM running on a
+machine which experiences a real hardware memory error. Later, we live migrate
+the VM to another physical machine. Since we want the migration to be
+transparent to the guest, we want that same address range to act as if it was
+still poisoned, even though it's on a new physical host which ostensibly
+doesn't have a memory error in the exact same spot.
+
QEMU/KVM
========
diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst
index 6e6f7b0d6562..2464425c783d 100644
--- a/Documentation/admin-guide/mm/zswap.rst
+++ b/Documentation/admin-guide/mm/zswap.rst
@@ -1,5 +1,3 @@
-.. _zswap:
-
=====
zswap
=====
@@ -14,13 +12,7 @@ for potentially reduced swap I/O. This trade-off can also result in a
significant performance improvement if reads from the compressed cache are
faster than reads from a swap device.
-.. note::
- Zswap is a new feature as of v3.11 and interacts heavily with memory
- reclaim. This interaction has not been fully explored on the large set of
- potential configurations and workloads that exist. For this reason, zswap
- is a work in progress and should be considered experimental.
-
- Some potential benefits:
+Some potential benefits:
* Desktop/laptop users with limited RAM capacities can mitigate the
performance impact of swapping.
@@ -57,42 +49,29 @@ compressed pool.
Design
======
-Zswap receives pages for compression through the Frontswap API and is able to
+Zswap receives pages for compression from the swap subsystem and is able to
evict pages from its own compressed pool on an LRU basis and write them back to
the backing swap device in the case that the compressed pool is full.
-Zswap makes use of zpool for the managing the compressed memory pool. Each
-allocation in zpool is not directly accessible by address. Rather, a handle is
+Zswap makes use of zsmalloc for the managing the compressed memory pool. Each
+allocation in zsmalloc is not directly accessible by address. Rather, a handle is
returned by the allocation routine and that handle must be mapped before being
accessed. The compressed memory pool grows on demand and shrinks as compressed
-pages are freed. The pool is not preallocated. By default, a zpool
-of type selected in ``CONFIG_ZSWAP_ZPOOL_DEFAULT`` Kconfig option is created,
-but it can be overridden at boot time by setting the ``zpool`` attribute,
-e.g. ``zswap.zpool=zbud``. It can also be changed at runtime using the sysfs
-``zpool`` attribute, e.g.::
-
- echo zbud > /sys/module/zswap/parameters/zpool
-
-The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which
-means the compression ratio will always be 2:1 or worse (because of half-full
-zbud pages). The zsmalloc type zpool has a more complex compressed page
-storage method, and it can achieve greater storage densities. However,
-zsmalloc does not implement compressed page eviction, so once zswap fills it
-cannot evict the oldest page, it can only reject new pages.
-
-When a swap page is passed from frontswap to zswap, zswap maintains a mapping
-of the swap entry, a combination of the swap type and swap offset, to the zpool
+pages are freed. The pool is not preallocated.
+
+When a swap page is passed from swapout to zswap, zswap maintains a mapping of
+the swap entry, a combination of the swap type and swap offset, to the zsmalloc
handle that references that compressed swap page. This mapping is achieved
-with a red-black tree per swap type. The swap offset is the search key for the
-tree nodes.
+with an xarray per swap type. The swap offset is the search key for the xarray
+nodes.
-During a page fault on a PTE that is a swap entry, frontswap calls the zswap
-load function to decompress the page into the page allocated by the page fault
-handler.
+During a page fault on a PTE that is a swap entry, the swapin code calls the
+zswap load function to decompress the page into the page allocated by the page
+fault handler.
Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
-in the swap_map goes to 0) the swap code calls the zswap invalidate function,
-via frontswap, to free the compressed entry.
+in the swap_map goes to 0) the swap code calls the zswap invalidate function
+to free the compressed entry.
Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
controlled policy:
@@ -108,11 +87,11 @@ attribute, e.g.::
echo lzo > /sys/module/zswap/parameters/compressor
-When the zpool and/or compressor parameter is changed at runtime, any existing
-compressed pages are not modified; they are left in their own zpool. When a
-request is made for a page in an old zpool, it is uncompressed using its
-original compressor. Once all pages are removed from an old zpool, the zpool
-and its compressor are freed.
+When the compressor parameter is changed at runtime, any existing compressed
+pages are not modified; they are left in their own pool. When a request is
+made for a page in an old pool, it is uncompressed using its original
+compressor. Once all pages are removed from an old pool, the pool and its
+compressor are freed.
Some of the pages in zswap are same-value filled pages (i.e. contents of the
page have same value or repetitive pattern). These pages include zero-filled
@@ -121,35 +100,6 @@ checked if it is a same-value filled page before compressing it. If true, the
compressed length of the page is set to zero and the pattern or same-filled
value is stored.
-Same-value filled pages identification feature is enabled by default and can be
-disabled at boot time by setting the ``same_filled_pages_enabled`` attribute
-to 0, e.g. ``zswap.same_filled_pages_enabled=0``. It can also be enabled and
-disabled at runtime using the sysfs ``same_filled_pages_enabled``
-attribute, e.g.::
-
- echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled
-
-When zswap same-filled page identification is disabled at runtime, it will stop
-checking for the same-value filled pages during store operation.
-In other words, every page will be then considered non-same-value filled.
-However, the existing pages which are marked as same-value filled pages remain
-stored unchanged in zswap until they are either loaded or invalidated.
-
-In some circumstances it might be advantageous to make use of just the zswap
-ability to efficiently store same-filled pages without enabling the whole
-compressed page storage.
-In this case the handling of non-same-value pages by zswap (enabled by default)
-can be disabled by setting the ``non_same_filled_pages_enabled`` attribute
-to 0, e.g. ``zswap.non_same_filled_pages_enabled=0``.
-It can also be enabled and disabled at runtime using the sysfs
-``non_same_filled_pages_enabled`` attribute, e.g.::
-
- echo 1 > /sys/module/zswap/parameters/non_same_filled_pages_enabled
-
-Disabling both ``zswap.same_filled_pages_enabled`` and
-``zswap.non_same_filled_pages_enabled`` effectively disables accepting any new
-pages by zswap.
-
To prevent zswap from shrinking pool when zswap is full and there's a high
pressure on swap (this will result in flipping pages in and out zswap pool
without any real benefit but with a performance drop for the system), a
@@ -163,6 +113,26 @@ attribute, e. g.::
Setting this parameter to 100 will disable the hysteresis.
+Some users cannot tolerate the swapping that comes with zswap store failures
+and zswap writebacks. Swapping can be disabled entirely (without disabling
+zswap itself) on a cgroup-basis as follows::
+
+ echo 0 > /sys/fs/cgroup/<cgroup-name>/memory.zswap.writeback
+
+Note that if the store failures are recurring (for e.g if the pages are
+incompressible), users can observe reclaim inefficiency after disabling
+writeback (because the same pages might be rejected again and again).
+
+When there is a sizable amount of cold memory residing in the zswap pool, it
+can be advantageous to proactively write these cold pages to swap and reclaim
+the memory for other use cases. By default, the zswap shrinker is disabled.
+User can enable it as follows::
+
+ echo Y > /sys/module/zswap/parameters/shrinker_enabled
+
+This can be enabled at the boot time if ``CONFIG_ZSWAP_SHRINKER_DEFAULT_ON`` is
+selected.
+
A debugfs interface is provided for various statistic about pool size, number
of pages stored, same-value filled pages and various counters for the reasons
pages are rejected.
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index 7d7c7c8a545c..a8667a777490 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -28,10 +28,10 @@ trusted userspace bits.
This facility uses X.509 ITU-T standard certificates to encode the public keys
involved. The signatures are not themselves encoded in any industrial standard
-type. The facility currently only supports the RSA public key encryption
-standard (though it is pluggable and permits others to be used). The possible
-hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384, and
-SHA-512 (the algorithm is selected by data in the signature).
+type. The built-in facility currently only supports the RSA & NIST P-384 ECDSA
+public key signing standard (though it is pluggable and permits others to be
+used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
+sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
==========================
@@ -81,11 +81,12 @@ This has a number of options available:
sign the modules with:
=============================== ==========================================
- ``CONFIG_MODULE_SIG_SHA1`` :menuselection:`Sign modules with SHA-1`
- ``CONFIG_MODULE_SIG_SHA224`` :menuselection:`Sign modules with SHA-224`
``CONFIG_MODULE_SIG_SHA256`` :menuselection:`Sign modules with SHA-256`
``CONFIG_MODULE_SIG_SHA384`` :menuselection:`Sign modules with SHA-384`
``CONFIG_MODULE_SIG_SHA512`` :menuselection:`Sign modules with SHA-512`
+ ``CONFIG_MODULE_SIG_SHA3_256`` :menuselection:`Sign modules with SHA3-256`
+ ``CONFIG_MODULE_SIG_SHA3_384`` :menuselection:`Sign modules with SHA3-384`
+ ``CONFIG_MODULE_SIG_SHA3_512`` :menuselection:`Sign modules with SHA3-512`
=============================== ==========================================
The algorithm selected here will also be built into the kernel (rather
@@ -145,6 +146,10 @@ into vmlinux) using parameters in the::
file (which is also generated if it does not already exist).
+One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
+(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
+P-384 keypair.
+
It is strongly recommended that you provide your own x509.genkey file.
Most notably, in the x509.genkey file, the req_distinguished_name section
@@ -266,7 +271,7 @@ for which it has a public key. Otherwise, it will also load modules that are
unsigned. Any module for which the kernel has a key, but which proves to have
a signature mismatch will not be permitted to load.
-Any module that has an unparseable signature will be rejected.
+Any module that has an unparsable signature will be rejected.
=========================================
diff --git a/Documentation/admin-guide/namespaces/resource-control.rst b/Documentation/admin-guide/namespaces/resource-control.rst
index 369556e00f0c..553a44803231 100644
--- a/Documentation/admin-guide/namespaces/resource-control.rst
+++ b/Documentation/admin-guide/namespaces/resource-control.rst
@@ -1,17 +1,17 @@
-===========================
-Namespaces research control
-===========================
+====================================
+User namespaces and resource control
+====================================
-There are a lot of kinds of objects in the kernel that don't have
-individual limits or that have limits that are ineffective when a set
-of processes is allowed to switch user ids. With user namespaces
-enabled in a kernel for people who don't trust their users or their
-users programs to play nice this problems becomes more acute.
+The kernel contains many kinds of objects that either don't have
+individual limits or that have limits which are ineffective when
+a set of processes is allowed to switch their UID. On a system
+where the admins don't trust their users or their users' programs,
+user namespaces expose the system to potential misuse of resources.
-Therefore it is recommended that memory control groups be enabled in
-kernels that enable user namespaces, and it is further recommended
-that userspace configure memory control groups to limit how much
-memory user's they don't trust to play nice can use.
+In order to mitigate this, we recommend that admins enable memory
+control groups on any system that enables user namespaces.
+Furthermore, we recommend that admins configure the memory control
+groups to limit the maximum memory usable by any untrusted user.
Memory control groups can be configured by installing the libcgroup
package present on most distros editing /etc/cgrules.conf,
diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst
index 135218f33394..06990309c6ff 100644
--- a/Documentation/admin-guide/nfs/nfsroot.rst
+++ b/Documentation/admin-guide/nfs/nfsroot.rst
@@ -342,7 +342,7 @@ They depend on various facilities being available:
When using pxelinux, the kernel image is specified using
"kernel <relative-path-below /tftpboot>". The nfsroot parameters
are passed to the kernel by adding them to the "append" line.
- It is common to use serial console in conjunction with pxeliunx,
+ It is common to use serial console in conjunction with pxelinux,
see Documentation/admin-guide/serial-console.rst for more information.
For more information on isolinux, including how to create bootdisks
diff --git a/Documentation/admin-guide/nvme-multipath.rst b/Documentation/admin-guide/nvme-multipath.rst
new file mode 100644
index 000000000000..97ca1ccef459
--- /dev/null
+++ b/Documentation/admin-guide/nvme-multipath.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Linux NVMe multipath
+====================
+
+This document describes NVMe multipath and its path selection policies supported
+by the Linux NVMe host driver.
+
+
+Introduction
+============
+
+The NVMe multipath feature in Linux integrates namespaces with the same
+identifier into a single block device. Using multipath enhances the reliability
+and stability of I/O access while improving bandwidth performance. When a user
+sends I/O to this merged block device, the multipath mechanism selects one of
+the underlying block devices (paths) according to the configured policy.
+Different policies result in different path selections.
+
+
+Policies
+========
+
+All policies follow the ANA (Asymmetric Namespace Access) mechanism, meaning
+that when an optimized path is available, it will be chosen over a non-optimized
+one. Current the NVMe multipath policies include numa(default), round-robin and
+queue-depth.
+
+To set the desired policy (e.g., round-robin), use one of the following methods:
+ 1. echo -n "round-robin" > /sys/module/nvme_core/parameters/iopolicy
+ 2. or add the "nvme_core.iopolicy=round-robin" to cmdline.
+
+
+NUMA
+----
+
+The NUMA policy selects the path closest to the NUMA node of the current CPU for
+I/O distribution. This policy maintains the nearest paths to each NUMA node
+based on network interface connections.
+
+When to use the NUMA policy:
+ 1. Multi-core Systems: Optimizes memory access in multi-core and
+ multi-processor systems, especially under NUMA architecture.
+ 2. High Affinity Workloads: Binds I/O processing to the CPU to reduce
+ communication and data transfer delays across nodes.
+
+
+Round-Robin
+-----------
+
+The round-robin policy distributes I/O requests evenly across all paths to
+enhance throughput and resource utilization. Each I/O operation is sent to the
+next path in sequence.
+
+When to use the round-robin policy:
+ 1. Balanced Workloads: Effective for balanced and predictable workloads with
+ similar I/O size and type.
+ 2. Homogeneous Path Performance: Utilizes all paths efficiently when
+ performance characteristics (e.g., latency, bandwidth) are similar.
+
+
+Queue-Depth
+-----------
+
+The queue-depth policy manages I/O requests based on the current queue depth
+of each path, selecting the path with the least number of in-flight I/Os.
+
+When to use the queue-depth policy:
+ 1. High load with small I/Os: Effectively balances load across paths when
+ the load is high, and I/O operations consist of small, relatively
+ fixed-sized requests.
diff --git a/Documentation/admin-guide/perf/alibaba_pmu.rst b/Documentation/admin-guide/perf/alibaba_pmu.rst
index 11de998bb480..7d840023903f 100644
--- a/Documentation/admin-guide/perf/alibaba_pmu.rst
+++ b/Documentation/admin-guide/perf/alibaba_pmu.rst
@@ -88,6 +88,11 @@ data bandwidth::
-e ali_drw_27080/hif_rmw/ \
-e ali_drw_27080/cycle/ -- sleep 10
+Example usage of counting all memory read/write bandwidth by metric::
+
+ perf stat -M ddr_read_bandwidth.all -- sleep 10
+ perf stat -M ddr_write_bandwidth.all -- sleep 10
+
The average DRAM bandwidth can be calculated as follows:
- Read Bandwidth = perf_hif_rd * DDRC_WIDTH * DDRC_Freq / DDRC_Cycle
diff --git a/Documentation/admin-guide/perf/ampere_cspmu.rst b/Documentation/admin-guide/perf/ampere_cspmu.rst
new file mode 100644
index 000000000000..94f93f5aee6c
--- /dev/null
+++ b/Documentation/admin-guide/perf/ampere_cspmu.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================================
+Ampere SoC Performance Monitoring Unit (PMU)
+============================================
+
+Ampere SoC PMU is a generic PMU IP that follows Arm CoreSight PMU architecture.
+Therefore, the driver is implemented as a submodule of arm_cspmu driver. At the
+first phase it's used for counting MCU events on AmpereOne.
+
+
+MCU PMU events
+--------------
+
+The PMU driver supports setting filters for "rank", "bank", and "threshold".
+Note, that the filters are per PMU instance rather than per event.
+
+
+Example for perf tool use::
+
+ / # perf list ampere
+
+ ampere_mcu_pmu_0/act_sent/ [Kernel PMU event]
+ <...>
+ ampere_mcu_pmu_1/rd_sent/ [Kernel PMU event]
+ <...>
+
+ / # perf stat -a -e ampere_mcu_pmu_0/act_sent,bank=5,rank=3,threshold=2/,ampere_mcu_pmu_1/rd_sent/ \
+ sleep 1
diff --git a/Documentation/admin-guide/perf/arm-ni.rst b/Documentation/admin-guide/perf/arm-ni.rst
new file mode 100644
index 000000000000..d26a8f697c36
--- /dev/null
+++ b/Documentation/admin-guide/perf/arm-ni.rst
@@ -0,0 +1,17 @@
+====================================
+Arm Network-on Chip Interconnect PMU
+====================================
+
+NI-700 and friends implement a distinct PMU for each clock domain within the
+interconnect. Correspondingly, the driver exposes multiple PMU devices named
+arm_ni_<x>_cd_<y>, where <x> is an (arbitrary) instance identifier and <y> is
+the clock domain ID within that particular instance. If multiple NI instances
+exist within a system, the PMU devices can be correlated with the underlying
+hardware instance via sysfs parentage.
+
+Each PMU exposes base event aliases for the interface types present in its clock
+domain. These require qualifying with the "eventid" and "nodeid" parameters
+to specify the event code to count and the interface at which to count it
+(per the configured hardware ID as reflected in the xxNI_NODE_INFO register).
+The exception is the "cycles" alias for the PMU cycle counter, which is encoded
+with the PMU node type and needs no further qualification.
diff --git a/Documentation/admin-guide/perf/cxl.rst b/Documentation/admin-guide/perf/cxl.rst
new file mode 100644
index 000000000000..9233ea0d0b10
--- /dev/null
+++ b/Documentation/admin-guide/perf/cxl.rst
@@ -0,0 +1,68 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+CXL Performance Monitoring Unit (CPMU)
+======================================
+
+The CXL rev 3.0 specification provides a definition of CXL Performance
+Monitoring Unit in section 13.2: Performance Monitoring.
+
+CXL components (e.g. Root Port, Switch Upstream Port, End Point) may have
+any number of CPMU instances. CPMU capabilities are fully discoverable from
+the devices. The specification provides event definitions for all CXL protocol
+message types and a set of additional events for things commonly counted on
+CXL devices (e.g. DRAM events).
+
+CPMU driver
+===========
+
+The CPMU driver registers a perf PMU with the name pmu_mem<X>.<Y> on the CXL bus
+representing the Yth CPMU for memX.
+
+ /sys/bus/cxl/device/pmu_mem<X>.<Y>
+
+The associated PMU is registered as
+
+ /sys/bus/event_sources/devices/cxl_pmu_mem<X>.<Y>
+
+In common with other CXL bus devices, the id has no specific meaning and the
+relationship to specific CXL device should be established via the device parent
+of the device on the CXL bus.
+
+PMU driver provides description of available events and filter options in sysfs.
+
+The "format" directory describes all formats of the config (event vendor id,
+group id and mask) config1 (threshold, filter enables) and config2 (filter
+parameters) fields of the perf_event_attr structure. The "events" directory
+describes all documented events show in perf list.
+
+The events shown in perf list are the most fine grained events with a single
+bit of the event mask set. More general events may be enable by setting
+multiple mask bits in config. For example, all Device to Host Read Requests
+may be captured on a single counter by setting the bits for all of
+
+* d2h_req_rdcurr
+* d2h_req_rdown
+* d2h_req_rdshared
+* d2h_req_rdany
+* d2h_req_rdownnodata
+
+Example of usage::
+
+ $#perf list
+ cxl_pmu_mem0.0/clock_ticks/ [Kernel PMU event]
+ cxl_pmu_mem0.0/d2h_req_rdshared/ [Kernel PMU event]
+ cxl_pmu_mem0.0/h2d_req_snpcur/ [Kernel PMU event]
+ cxl_pmu_mem0.0/h2d_req_snpdata/ [Kernel PMU event]
+ cxl_pmu_mem0.0/h2d_req_snpinv/ [Kernel PMU event]
+ -----------------------------------------------------------
+
+ $# perf stat -a -e cxl_pmu_mem0.0/clock_ticks/ -e cxl_pmu_mem0.0/d2h_req_rdshared/
+
+Vendor specific events may also be available and if so can be used via
+
+ $# perf stat -a -e cxl_pmu_mem0.0/vid=VID,gid=GID,mask=MASK/
+
+The driver does not support sampling so "perf record" is unsupported.
+It only supports system-wide counting so attaching to a task is
+unsupported.
diff --git a/Documentation/admin-guide/perf/dwc_pcie_pmu.rst b/Documentation/admin-guide/perf/dwc_pcie_pmu.rst
new file mode 100644
index 000000000000..167f9281fbf5
--- /dev/null
+++ b/Documentation/admin-guide/perf/dwc_pcie_pmu.rst
@@ -0,0 +1,94 @@
+======================================================================
+Synopsys DesignWare Cores (DWC) PCIe Performance Monitoring Unit (PMU)
+======================================================================
+
+DesignWare Cores (DWC) PCIe PMU
+===============================
+
+The PMU is a PCIe configuration space register block provided by each PCIe Root
+Port in a Vendor-Specific Extended Capability named RAS D.E.S (Debug, Error
+injection, and Statistics).
+
+As the name indicates, the RAS DES capability supports system level
+debugging, AER error injection, and collection of statistics. To facilitate
+collection of statistics, Synopsys DesignWare Cores PCIe controller
+provides the following two features:
+
+- one 64-bit counter for Time Based Analysis (RX/TX data throughput and
+ time spent in each low-power LTSSM state) and
+- one 32-bit counter per event for Event Counting (error and non-error
+ events for a specified lane)
+
+Note: There is no interrupt for counter overflow.
+
+Time Based Analysis
+-------------------
+
+Using this feature you can obtain information regarding RX/TX data
+throughput and time spent in each low-power LTSSM state by the controller.
+The PMU measures data in two categories:
+
+- Group#0: Percentage of time the controller stays in LTSSM states.
+- Group#1: Amount of data processed (Units of 16 bytes).
+
+Lane Event counters
+-------------------
+
+Using this feature you can obtain Error and Non-Error information in
+specific lane by the controller. The PMU event is selected by all of:
+
+- Group i
+- Event j within the Group i
+- Lane k
+
+Some of the events only exist for specific configurations.
+
+DesignWare Cores (DWC) PCIe PMU Driver
+=======================================
+
+This driver adds PMU devices for each PCIe Root Port named based on the SBDF of
+the Root Port. For example,
+
+ 0001:30:03.0 PCI bridge: Device 1ded:8000 (rev 01)
+
+the PMU device name for this Root Port is dwc_rootport_13018.
+
+The DWC PCIe PMU driver registers a perf PMU driver, which provides
+description of available events and configuration options in sysfs, see
+/sys/bus/event_source/devices/dwc_rootport_{sbdf}.
+
+The "format" directory describes format of the config fields of the
+perf_event_attr structure. The "events" directory provides configuration
+templates for all documented events. For example,
+"rx_pcie_tlp_data_payload" is an equivalent of "eventid=0x21,type=0x0".
+
+The "perf list" command shall list the available events from sysfs, e.g.::
+
+ $# perf list | grep dwc_rootport
+ <...>
+ dwc_rootport_13018/Rx_PCIe_TLP_Data_Payload/ [Kernel PMU event]
+ <...>
+ dwc_rootport_13018/rx_memory_read,lane=?/ [Kernel PMU event]
+
+Time Based Analysis Event Usage
+-------------------------------
+
+Example usage of counting PCIe RX TLP data payload (Units of bytes)::
+
+ $# perf stat -a -e dwc_rootport_13018/Rx_PCIe_TLP_Data_Payload/
+
+The average RX/TX bandwidth can be calculated using the following formula:
+
+ PCIe RX Bandwidth = rx_pcie_tlp_data_payload / Measure_Time_Window
+ PCIe TX Bandwidth = tx_pcie_tlp_data_payload / Measure_Time_Window
+
+Lane Event Usage
+-------------------------------
+
+Each lane has the same event set and to avoid generating a list of hundreds
+of events, the user need to specify the lane ID explicitly, e.g.::
+
+ $# perf stat -a -e dwc_rootport_13018/rx_memory_read,lane=4/
+
+The driver does not support sampling, therefore "perf record" will not
+work. Per-task (without "-a") perf sessions are not supported.
diff --git a/Documentation/admin-guide/perf/fujitsu_uncore_pmu.rst b/Documentation/admin-guide/perf/fujitsu_uncore_pmu.rst
new file mode 100644
index 000000000000..2ec0249e37b6
--- /dev/null
+++ b/Documentation/admin-guide/perf/fujitsu_uncore_pmu.rst
@@ -0,0 +1,115 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+================================================
+Fujitsu Uncore Performance Monitoring Unit (PMU)
+================================================
+
+This driver supports the Uncore MAC PMUs and the Uncore PCI PMUs found
+in Fujitsu chips.
+Each MAC PMU on these chips is exposed as a uncore perf PMU with device name
+mac_iod<iod>_mac<mac>_ch<ch>.
+And each PCI PMU on these chips is exposed as a uncore perf PMU with device name
+pci_iod<iod>_pci<pci>.
+
+The driver provides a description of its available events and configuration
+options in sysfs, see /sys/bus/event_sources/devices/mac_iod<iod>_mac<mac>_ch<ch>/
+and /sys/bus/event_sources/devices/pci_iod<iod>_pci<pci>/.
+This driver exports:
+
+- formats, used by perf user space and other tools to configure events
+- events, used by perf user space and other tools to create events
+ symbolically, e.g.::
+
+ perf stat -a -e mac_iod0_mac0_ch0/event=0x21/ ls
+ perf stat -a -e pci_iod0_pci0/event=0x24/ ls
+
+- cpumask, used by perf user space and other tools to know on which CPUs
+ to open the events
+
+This driver supports the following events for MAC:
+
+- cycles
+ This event counts MAC cycles at MAC frequency.
+- read-count
+ This event counts the number of read requests to MAC.
+- read-count-request
+ This event counts the number of read requests including retry to MAC.
+- read-count-return
+ This event counts the number of responses to read requests to MAC.
+- read-count-request-pftgt
+ This event counts the number of read requests including retry with PFTGT
+ flag.
+- read-count-request-normal
+ This event counts the number of read requests including retry without PFTGT
+ flag.
+- read-count-return-pftgt-hit
+ This event counts the number of responses to read requests which hit the
+ PFTGT buffer.
+- read-count-return-pftgt-miss
+ This event counts the number of responses to read requests which miss the
+ PFTGT buffer.
+- read-wait
+ This event counts outstanding read requests issued by DDR memory controller
+ per cycle.
+- write-count
+ This event counts the number of write requests to MAC (including zero write,
+ full write, partial write, write cancel).
+- write-count-write
+ This event counts the number of full write requests to MAC (not including
+ zero write).
+- write-count-pwrite
+ This event counts the number of partial write requests to MAC.
+- memory-read-count
+ This event counts the number of read requests from MAC to memory.
+- memory-write-count
+ This event counts the number of full write requests from MAC to memory.
+- memory-pwrite-count
+ This event counts the number of partial write requests from MAC to memory.
+- ea-mac
+ This event counts energy consumption of MAC.
+- ea-memory
+ This event counts energy consumption of memory.
+- ea-memory-mac-write
+ This event counts the number of write requests from MAC to memory.
+- ea-ha
+ This event counts energy consumption of HA.
+
+ 'ea' is the abbreviation for 'Energy Analyzer'.
+
+Examples for use with perf::
+
+ perf stat -e mac_iod0_mac0_ch0/ea-mac/ ls
+
+And, this driver supports the following events for PCI:
+
+- pci-port0-cycles
+ This event counts PCI cycles at PCI frequency in port0.
+- pci-port0-read-count
+ This event counts read transactions for data transfer in port0.
+- pci-port0-read-count-bus
+ This event counts read transactions for bus usage in port0.
+- pci-port0-write-count
+ This event counts write transactions for data transfer in port0.
+- pci-port0-write-count-bus
+ This event counts write transactions for bus usage in port0.
+- pci-port1-cycles
+ This event counts PCI cycles at PCI frequency in port1.
+- pci-port1-read-count
+ This event counts read transactions for data transfer in port1.
+- pci-port1-read-count-bus
+ This event counts read transactions for bus usage in port1.
+- pci-port1-write-count
+ This event counts write transactions for data transfer in port1.
+- pci-port1-write-count-bus
+ This event counts write transactions for bus usage in port1.
+- ea-pci
+ This event counts energy consumption of PCI.
+
+ 'ea' is the abbreviation for 'Energy Analyzer'.
+
+Examples for use with perf::
+
+ perf stat -e pci_iod0_pci0/ea-pci/ ls
+
+Given that these are uncore PMUs the driver does not support sampling, therefore
+"perf record" will not work. Per-task perf sessions are not supported.
diff --git a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
index 294ebbdb22af..083ca50de896 100644
--- a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
+++ b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
@@ -15,10 +15,10 @@ HiSilicon PCIe PMU driver
The PCIe PMU driver registers a perf PMU with the name of its sicl-id and PCIe
Core id.::
- /sys/bus/event_source/hisi_pcie<sicl>_<core>
+ /sys/bus/event_source/hisi_pcie<sicl>_core<core>
PMU driver provides description of available events and filter options in sysfs,
-see /sys/bus/event_source/devices/hisi_pcie<sicl>_<core>.
+see /sys/bus/event_source/devices/hisi_pcie<sicl>_core<core>.
The "format" directory describes all formats of the config (events) and config1
(filter options) fields of the perf_event_attr structure. The "events" directory
@@ -28,18 +28,32 @@ The "identifier" sysfs file allows users to identify the version of the
PMU hardware device.
The "bus" sysfs file allows users to get the bus number of Root Ports
-monitored by PMU.
+monitored by PMU. Furthermore users can get the Root Ports range in
+[bdf_min, bdf_max] from "bdf_min" and "bdf_max" sysfs attributes
+respectively.
Example usage of perf::
$# perf list
- hisi_pcie0_0/rx_mwr_latency/ [kernel PMU event]
- hisi_pcie0_0/rx_mwr_cnt/ [kernel PMU event]
+ hisi_pcie0_core0/rx_mwr_latency/ [kernel PMU event]
+ hisi_pcie0_core0/rx_mwr_cnt/ [kernel PMU event]
------------------------------------------
- $# perf stat -e hisi_pcie0_0/rx_mwr_latency/
- $# perf stat -e hisi_pcie0_0/rx_mwr_cnt/
- $# perf stat -g -e hisi_pcie0_0/rx_mwr_latency/ -e hisi_pcie0_0/rx_mwr_cnt/
+ $# perf stat -e hisi_pcie0_core0/rx_mwr_latency,port=0xffff/
+ $# perf stat -e hisi_pcie0_core0/rx_mwr_cnt,port=0xffff/
+
+The related events usually used to calculate the bandwidth, latency or others.
+They need to start and end counting at the same time, therefore related events
+are best used in the same event group to get the expected value. There are two
+ways to know if they are related events:
+
+a) By event name, such as the latency events "xxx_latency, xxx_cnt" or
+ bandwidth events "xxx_flux, xxx_time".
+b) By event type, such as "event=0xXXXX, event=0x1XXXX".
+
+Example usage of perf group::
+
+ $# perf stat -e "{hisi_pcie0_core0/rx_mwr_latency,port=0xffff/,hisi_pcie0_core0/rx_mwr_cnt,port=0xffff/}"
The current driver does not support sampling. So "perf record" is unsupported.
Also attach to a task is unsupported for PCIe PMU.
@@ -48,59 +62,87 @@ Filter options
--------------
1. Target filter
-PMU could only monitor the performance of traffic downstream target Root Ports
-or downstream target Endpoint. PCIe PMU driver support "port" and "bdf"
-interfaces for users, and these two interfaces aren't supported at the same
-time.
--port
-"port" filter can be used in all PCIe PMU events, target Root Port can be
-selected by configuring the 16-bits-bitmap "port". Multi ports can be selected
-for AP-layer-events, and only one port can be selected for TL/DL-layer-events.
+ PMU could only monitor the performance of traffic downstream target Root
+ Ports or downstream target Endpoint. PCIe PMU driver support "port" and
+ "bdf" interfaces for users.
+ Please notice that, one of these two interfaces must be set, and these two
+ interfaces aren't supported at the same time. If they are both set, only
+ "port" filter is valid.
+ If "port" filter not being set or is set explicitly to zero (default), the
+ "bdf" filter will be in effect, because "bdf=0" meaning 0000:000:00.0.
-For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of bitmap
-should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4 lanes),
-bit8 is set, port=0x100; if these two Root Ports are both monitored, port=0x101.
+ - port
-Example usage of perf::
+ "port" filter can be used in all PCIe PMU events, target Root Port can be
+ selected by configuring the 16-bits-bitmap "port". Multi ports can be
+ selected for AP-layer-events, and only one port can be selected for
+ TL/DL-layer-events.
- $# perf stat -e hisi_pcie0_0/rx_mwr_latency,port=0x1/ sleep 5
+ For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of
+ bitmap should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4
+ lanes), bit8 is set, port=0x100; if these two Root Ports are both
+ monitored, port=0x101.
--bdf
+ Example usage of perf::
-"bdf" filter can only be used in bandwidth events, target Endpoint is selected
-by configuring BDF to "bdf". Counter only counts the bandwidth of message
-requested by target Endpoint.
+ $# perf stat -e hisi_pcie0_core0/rx_mwr_latency,port=0x1/ sleep 5
-For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0.
+ - bdf
-Example usage of perf::
+ "bdf" filter can only be used in bandwidth events, target Endpoint is
+ selected by configuring BDF to "bdf". Counter only counts the bandwidth of
+ message requested by target Endpoint.
+
+ For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0.
- $# perf stat -e hisi_pcie0_0/rx_mrd_flux,bdf=0x3900/ sleep 5
+ Example usage of perf::
+
+ $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,bdf=0x3900/ sleep 5
2. Trigger filter
-Event statistics start when the first time TLP length is greater/smaller
-than trigger condition. You can set the trigger condition by writing "trig_len",
-and set the trigger mode by writing "trig_mode". This filter can only be used
-in bandwidth events.
-For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0"
-means statistics start when TLP length > trigger condition, "trig_mode=1"
-means start when TLP length < condition.
+ Event statistics start when the first time TLP length is greater/smaller
+ than trigger condition. You can set the trigger condition by writing
+ "trig_len", and set the trigger mode by writing "trig_mode". This filter can
+ only be used in bandwidth events.
-Example usage of perf::
+ For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0"
+ means statistics start when TLP length > trigger condition, "trig_mode=1"
+ means start when TLP length < condition.
- $# perf stat -e hisi_pcie0_0/rx_mrd_flux,trig_len=0x4,trig_mode=1/ sleep 5
+ Example usage of perf::
+
+ $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,port=0xffff,trig_len=0x4,trig_mode=1/ sleep 5
3. Threshold filter
-Counter counts when TLP length within the specified range. You can set the
-threshold by writing "thr_len", and set the threshold mode by writing
-"thr_mode". This filter can only be used in bandwidth events.
-For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means
-counter counts when TLP length >= threshold, and "thr_mode=1" means counts
-when TLP length < threshold.
+ Counter counts when TLP length within the specified range. You can set the
+ threshold by writing "thr_len", and set the threshold mode by writing
+ "thr_mode". This filter can only be used in bandwidth events.
-Example usage of perf::
+ For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means
+ counter counts when TLP length >= threshold, and "thr_mode=1" means counts
+ when TLP length < threshold.
+
+ Example usage of perf::
+
+ $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,port=0xffff,thr_len=0x4,thr_mode=1/ sleep 5
+
+4. TLP Length filter
+
+ When counting bandwidth, the data can be composed of certain parts of TLP
+ packets. You can specify it through "len_mode":
+
+ - 2'b00: Reserved (Do not use this since the behaviour is undefined)
+ - 2'b01: Bandwidth of TLP payloads
+ - 2'b10: Bandwidth of TLP headers
+ - 2'b11: Bandwidth of both TLP payloads and headers
+
+ For example, "len_mode=2" means only counting the bandwidth of TLP headers
+ and "len_mode=3" means the final bandwidth data is composed of both TLP
+ headers and payloads. Default value if not specified is 2'b11.
+
+ Example usage of perf::
- $# perf stat -e hisi_pcie0_0/rx_mrd_flux,thr_len=0x4,thr_mode=1/ sleep 5
+ $# perf stat -e hisi_pcie0_core0/rx_mrd_flux,port=0xffff,len_mode=0x1/ sleep 5
diff --git a/Documentation/admin-guide/perf/hisi-pmu.rst b/Documentation/admin-guide/perf/hisi-pmu.rst
index 546979360513..d56b2d690709 100644
--- a/Documentation/admin-guide/perf/hisi-pmu.rst
+++ b/Documentation/admin-guide/perf/hisi-pmu.rst
@@ -18,10 +18,10 @@ HiSilicon SoC uncore PMU driver
Each device PMU has separate registers for event counting, control and
interrupt, and the PMU driver shall register perf PMU drivers like L3C,
HHA and DDRC etc. The available events and configuration options shall
-be described in the sysfs, see:
+be described in the sysfs, see::
+
+/sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>
-/sys/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>/, or
-/sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>.
The "perf list" command shall list the available events from sysfs.
Each L3C, HHA and DDRC is registered as a separate PMU with perf. The PMU
@@ -36,7 +36,10 @@ e.g. hisi_sccl1_hha0/rx_operations is RX_OPERATIONS event of HHA index #0 in
SCCL ID #1.
The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
-ID used to count the uncore PMU event.
+ID used to count the uncore PMU event. An "associated_cpus" sysfs attribute is
+also provided to show the CPUs associated with this PMU. The "cpumask" indicates
+the CPUs to open the events, usually as a hint for userspaces tools like perf.
+It only contains one associated CPU from the "associated_cpus".
Example usage of perf::
@@ -56,14 +59,18 @@ Example usage of perf::
For HiSilicon uncore PMU v2 whose identifier is 0x30, the topology is the same
as PMU v1, but some new functions are added to the hardware.
-(a) L3C PMU supports filtering by core/thread within the cluster which can be
+1. L3C PMU supports filtering by core/thread within the cluster which can be
specified as a bitmap::
$# perf stat -a -e hisi_sccl3_l3c0/config=0x02,tt_core=0x3/ sleep 5
This will only count the operations from core/thread 0 and 1 in this cluster.
-(b) Tracetag allow the user to chose to count only read, write or atomic
+User should not use tt_core_deprecated to specify the core/thread filtering.
+This option is provided for backward compatiblility and only support 8bit
+which may not cover all the core/thread sharing L3C.
+
+2. Tracetag allow the user to chose to count only read, write or atomic
operations via the tt_req parameeter in perf. The default value counts all
operations. tt_req is 3bits, 3'b100 represents read operations, 3'b101
represents write operations, 3'b110 represents atomic store operations and
@@ -73,14 +80,16 @@ represents write operations, 3'b110 represents atomic store operations and
This will only count the read operations in this cluster.
-(c) Datasrc allows the user to check where the data comes from. It is 5 bits.
+3. Datasrc allows the user to check where the data comes from. It is 5 bits.
Some important codes are as follows:
-5'b00001: comes from L3C in this die;
-5'b01000: comes from L3C in the cross-die;
-5'b01001: comes from L3C which is in another socket;
-5'b01110: comes from the local DDR;
-5'b01111: comes from the cross-die DDR;
-5'b10000: comes from cross-socket DDR;
+
+- 5'b00001: comes from L3C in this die;
+- 5'b01000: comes from L3C in the cross-die;
+- 5'b01001: comes from L3C which is in another socket;
+- 5'b01110: comes from the local DDR;
+- 5'b01111: comes from the cross-die DDR;
+- 5'b10000: comes from cross-socket DDR;
+
etc, it is mainly helpful to find that the data source is nearest from the CPU
cores. If datasrc_cfg is used in the multi-chips, the datasrc_skt shall be
configured in perf command::
@@ -88,15 +97,69 @@ configured in perf command::
$# perf stat -a -e hisi_sccl3_l3c0/config=0xb9,datasrc_cfg=0xE/,
hisi_sccl3_l3c0/config=0xb9,datasrc_cfg=0xF/ sleep 5
-(d)Some HiSilicon SoCs encapsulate multiple CPU and IO dies. Each CPU die
+4. Some HiSilicon SoCs encapsulate multiple CPU and IO dies. Each CPU die
contains several Compute Clusters (CCLs). The I/O dies are called Super I/O
clusters (SICL) containing multiple I/O clusters (ICLs). Each CCL/ICL in the
SoC has a unique ID. Each ID is 11bits, include a 6-bit SCCL-ID and 5-bit
CCL/ICL-ID. For I/O die, the ICL-ID is followed by:
-5'b00000: I/O_MGMT_ICL;
-5'b00001: Network_ICL;
-5'b00011: HAC_ICL;
-5'b10000: PCIe_ICL;
+
+- 5'b00000: I/O_MGMT_ICL;
+- 5'b00001: Network_ICL;
+- 5'b00011: HAC_ICL;
+- 5'b10000: PCIe_ICL;
+
+5. uring_channel: UC PMU events 0x47~0x59 supports filtering by tx request
+uring channel. It is 2 bits. Some important codes are as follows:
+
+- 2'b11: count the events which sent to the uring_ext (MATA) channel;
+- 2'b01: is the same as 2'b11;
+- 2'b10: count the events which sent to the uring (non-MATA) channel;
+- 2'b00: default value, count the events which sent to both uring and
+ uring_ext channels;
+
+6. ch: NoC PMU supports filtering the event counts of certain transaction
+channel with this option. The current supported channels are as follows:
+
+- 3'b010: Request channel
+- 3'b100: Snoop channel
+- 3'b110: Response channel
+- 3'b111: Data channel
+
+7. tt_en: NoC PMU supports counting only transactions that have tracetag set
+if this option is set. See the 2nd list for more information about tracetag.
+
+For HiSilicon uncore PMU v3 whose identifier is 0x40, some uncore PMUs are
+further divided into parts for finer granularity of tracing, each part has its
+own dedicated PMU, and all such PMUs together cover the monitoring job of events
+on particular uncore device. Such PMUs are described in sysfs with name format
+slightly changed::
+
+/sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}_{Z}/ddrc{Y}_{Z}/noc{Y}_{Z}>
+
+Z is the sub-id, indicating different PMUs for part of hardware device.
+
+Usage of most PMUs with different sub-ids are identical. Specially, L3C PMU
+provides ``ext`` option to allow exploration of even finer granual statistics
+of L3C PMU. L3C PMU driver uses that as hint of termination when delivering
+perf command to hardware:
+
+- ext=0: Default, could be used with event names.
+- ext=1 and ext=2: Must be used with event codes, event names are not supported.
+
+An example of perf command could be::
+
+ $# perf stat -a -e hisi_sccl0_l3c1_0/rd_spipe/ sleep 5
+
+or::
+
+ $# perf stat -a -e hisi_sccl0_l3c1_0/event=0x1,ext=1/ sleep 5
+
+As above, ``hisi_sccl0_l3c1_0`` locates PMU of Super CPU CLuster 0, L3 cache 1
+pipe0.
+
+First command locates the first part of L3C since ``ext=0`` is implied by
+default. Second command issues the counting on another part of L3C with the
+event ``0x1``.
Users could configure IDs to count data come from specific CCL/ICL, by setting
srcid_cmd & srcid_msk, and data desitined for specific CCL/ICL by setting
diff --git a/Documentation/admin-guide/perf/hns3-pmu.rst b/Documentation/admin-guide/perf/hns3-pmu.rst
index 578407e487d6..1195e570f2d6 100644
--- a/Documentation/admin-guide/perf/hns3-pmu.rst
+++ b/Documentation/admin-guide/perf/hns3-pmu.rst
@@ -16,7 +16,7 @@ HNS3 PMU driver
The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
- /sys/devices/hns3_pmu_sicl_<sicl_id>
+ /sys/bus/event_source/devices/hns3_pmu_sicl_<sicl_id>
PMU driver provides description of available events, filter modes, format,
identifier and cpumask in sysfs.
@@ -40,9 +40,9 @@ device.
Example usage of checking event code and subevent code::
- $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
+ $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
config=0x00204
- $# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
+ $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
config=0x10204
Each performance statistic has a pair of events to get two values to
@@ -53,14 +53,14 @@ two events have same value of bits 0~15 of config, that means they are
event pair. And the bit 16 of config indicates getting counter 0 or
counter 1 of hardware event.
-After getting two values of event pair in usersapce, the formula of
+After getting two values of event pair in userspace, the formula of
computation to calculate real performance data is:::
counter 0 / counter 1
Example usage of checking supported filter mode::
- $# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
+ $# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
filter mode supported: global/port/port-tc/func/func-queue/
Example usage of perf::
diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
index 90926d0fb8ec..77418ae5a290 100644
--- a/Documentation/admin-guide/perf/imx-ddr.rst
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -13,8 +13,8 @@ is one register for each counter. Counter 0 is special in that it always counts
interrupt is raised. If any other counter overflows, it continues counting, and
no interrupt is raised.
-The "format" directory describes format of the config (event ID) and config1
-(AXI filtering) fields of the perf_event_attr structure, see /sys/bus/event_source/
+The "format" directory describes format of the config (event ID) and config1/2
+(AXI filter setting) fields of the perf_event_attr structure, see /sys/bus/event_source/
devices/imx8_ddr0/format/. The "events" directory describes the events types
hardware supported that can be used with perf tool, see /sys/bus/event_source/
devices/imx8_ddr0/events/. The "caps" directory describes filter features implemented
@@ -28,12 +28,11 @@ in DDR PMU, see /sys/bus/events_source/devices/imx8_ddr0/caps/.
AXI filtering is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write)
to count reading or writing matches filter setting. Filter setting is various
from different DRAM controller implementations, which is distinguished by quirks
-in the driver. You also can dump info from userspace, filter in "caps" directory
-indicates whether PMU supports AXI ID filter or not; enhanced_filter indicates
-whether PMU supports enhanced AXI ID filter or not. Value 0 for un-supported, and
-value 1 for supported.
+in the driver. You also can dump info from userspace, "caps" directory show the
+type of AXI filter (filter, enhanced_filter and super_filter). Value 0 for
+un-supported, and value 1 for supported.
-* With DDR_CAP_AXI_ID_FILTER quirk(filter: 1, enhanced_filter: 0).
+* With DDR_CAP_AXI_ID_FILTER quirk(filter: 1, enhanced_filter: 0, super_filter: 0).
Filter is defined with two configuration parts:
--AXI_ID defines AxID matching value.
--AXI_MASKING defines which bits of AxID are meaningful for the matching.
@@ -65,7 +64,37 @@ value 1 for supported.
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
-* With DDR_CAP_AXI_ID_FILTER_ENHANCED quirk(filter: 1, enhanced_filter: 1).
+* With DDR_CAP_AXI_ID_FILTER_ENHANCED quirk(filter: 1, enhanced_filter: 1, super_filter: 0).
This is an extension to the DDR_CAP_AXI_ID_FILTER quirk which permits
counting the number of bytes (as opposed to the number of bursts) from DDR
read and write transactions concurrently with another set of data counters.
+
+* With DDR_CAP_AXI_ID_PORT_CHANNEL_FILTER quirk(filter: 0, enhanced_filter: 0, super_filter: 1).
+ There is a limitation in previous AXI filter, it cannot filter different IDs
+ at the same time as the filter is shared between counters. This quirk is the
+ extension of AXI ID filter. One improvement is that counter 1-3 has their own
+ filter, means that it supports concurrently filter various IDs. Another
+ improvement is that counter 1-3 supports AXI PORT and CHANNEL selection. Support
+ selecting address channel or data channel.
+
+ Filter is defined with 2 configuration registers per counter 1-3.
+ --Counter N MASK COMP register - including AXI_ID and AXI_MASKING.
+ --Counter N MUX CNTL register - including AXI CHANNEL and AXI PORT.
+
+ - 0: address channel
+ - 1: data channel
+
+ PMU in DDR subsystem, only one single port0 exists, so axi_port is reserved
+ which should be 0.
+
+ .. code-block:: bash
+
+ perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD,axi_channel=0xH/ cmd
+ perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD,axi_channel=0xH/ cmd
+
+ .. note::
+
+ axi_channel is inverted in userspace, and it will be reverted in driver
+ automatically. So that users do not need specify axi_channel if want to
+ monitor data channel from DDR transactions, since data channel is more
+ meaningful.
diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst
index 793e1970bc05..47d9a3df6329 100644
--- a/Documentation/admin-guide/perf/index.rst
+++ b/Documentation/admin-guide/perf/index.rst
@@ -13,9 +13,20 @@ Performance monitor support
imx-ddr
qcom_l2_pmu
qcom_l3_pmu
+ starfive_starlink_pmu
+ mrvl-odyssey-ddr-pmu
+ mrvl-odyssey-tad-pmu
arm-ccn
arm-cmn
+ arm-ni
xgene-pmu
arm_dsu_pmu
thunderx2-pmu
alibaba_pmu
+ dwc_pcie_pmu
+ nvidia-pmu
+ meson-ddr-pmu
+ cxl
+ ampere_cspmu
+ mrvl-pem-pmu
+ fujitsu_uncore_pmu
diff --git a/Documentation/admin-guide/perf/meson-ddr-pmu.rst b/Documentation/admin-guide/perf/meson-ddr-pmu.rst
new file mode 100644
index 000000000000..8e71be1d6346
--- /dev/null
+++ b/Documentation/admin-guide/perf/meson-ddr-pmu.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================================================
+Amlogic SoC DDR Bandwidth Performance Monitoring Unit (PMU)
+===========================================================
+
+The Amlogic Meson G12 SoC contains a bandwidth monitor inside DRAM controller.
+The monitor includes 4 channels. Each channel can count the request accessing
+DRAM. The channel can count up to 3 AXI port simultaneously. It can be helpful
+to show if the performance bottleneck is on DDR bandwidth.
+
+Currently, this driver supports the following 5 perf events:
+
++ meson_ddr_bw/total_rw_bytes/
++ meson_ddr_bw/chan_1_rw_bytes/
++ meson_ddr_bw/chan_2_rw_bytes/
++ meson_ddr_bw/chan_3_rw_bytes/
++ meson_ddr_bw/chan_4_rw_bytes/
+
+meson_ddr_bw/chan_{1,2,3,4}_rw_bytes/ events are channel-specific events.
+Each channel support filtering, which can let the channel to monitor
+individual IP module in SoC.
+
+Below are DDR access request event filter keywords:
+
++ arm - from CPU
++ vpu_read1 - from OSD + VPP read
++ gpu - from 3D GPU
++ pcie - from PCIe controller
++ hdcp - from HDCP controller
++ hevc_front - from HEVC codec front end
++ usb3_0 - from USB3.0 controller
++ hevc_back - from HEVC codec back end
++ h265enc - from HEVC encoder
++ vpu_read2 - from DI read
++ vpu_write1 - from VDIN write
++ vpu_write2 - from di write
++ vdec - from legacy codec video decoder
++ hcodec - from H264 encoder
++ ge2d - from ge2d
++ spicc1 - from SPI controller 1
++ usb0 - from USB2.0 controller 0
++ dma - from system DMA controller 1
++ arb0 - from arb0
++ sd_emmc_b - from SD eMMC b controller
++ usb1 - from USB2.0 controller 1
++ audio - from Audio module
++ sd_emmc_c - from SD eMMC c controller
++ spicc2 - from SPI controller 2
++ ethernet - from Ethernet controller
+
+
+Examples:
+
+ + Show the total DDR bandwidth per seconds:
+
+ .. code-block:: bash
+
+ perf stat -a -e meson_ddr_bw/total_rw_bytes/ -I 1000 sleep 10
+
+
+ + Show individual DDR bandwidth from CPU and GPU respectively, as well as
+ sum of them:
+
+ .. code-block:: bash
+
+ perf stat -a -e meson_ddr_bw/chan_1_rw_bytes,arm=1/ -I 1000 sleep 10
+ perf stat -a -e meson_ddr_bw/chan_2_rw_bytes,gpu=1/ -I 1000 sleep 10
+ perf stat -a -e meson_ddr_bw/chan_3_rw_bytes,arm=1,gpu=1/ -I 1000 sleep 10
+
diff --git a/Documentation/admin-guide/perf/mrvl-odyssey-ddr-pmu.rst b/Documentation/admin-guide/perf/mrvl-odyssey-ddr-pmu.rst
new file mode 100644
index 000000000000..2e817593a4d9
--- /dev/null
+++ b/Documentation/admin-guide/perf/mrvl-odyssey-ddr-pmu.rst
@@ -0,0 +1,80 @@
+===================================================================
+Marvell Odyssey DDR PMU Performance Monitoring Unit (PMU UNCORE)
+===================================================================
+
+Odyssey DRAM Subsystem supports eight counters for monitoring performance
+and software can program those counters to monitor any of the defined
+performance events. Supported performance events include those counted
+at the interface between the DDR controller and the PHY, interface between
+the DDR Controller and the CHI interconnect, or within the DDR Controller.
+
+Additionally DSS also supports two fixed performance event counters, one
+for ddr reads and the other for ddr writes.
+
+The counter will be operating in either manual or auto mode.
+
+The PMU driver exposes the available events and format options under sysfs::
+
+ /sys/bus/event_source/devices/mrvl_ddr_pmu_<>/events/
+ /sys/bus/event_source/devices/mrvl_ddr_pmu_<>/format/
+
+Examples::
+
+ $ perf list | grep ddr
+ mrvl_ddr_pmu_<>/ddr_act_bypass_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_bsm_alloc/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_bsm_starvation/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_active_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_mwr/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_rd_active_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_rd_or_wr_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_read/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_wr_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_cam_write/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_capar_error/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_crit_ref/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_ddr_reads/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_ddr_writes/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dfi_cmd_is_retry/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dfi_cycles/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dfi_parity_poison/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dfi_rd_data_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dfi_wr_data_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dqsosc_mpc/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_dqsosc_mrr/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_enter_mpsm/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_enter_powerdown/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_enter_selfref/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_hif_pri_rdaccess/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_hif_rd_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_hif_rd_or_wr_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_hif_rmw_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_hif_wr_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_hpri_sched_rd_crit_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_load_mode/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_lpri_sched_rd_crit_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_precharge/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_precharge_for_other/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_precharge_for_rdwr/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_raw_hazard/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_rd_bypass_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_rd_crc_error/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_rd_uc_ecc_error/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_rdwr_transitions/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_refresh/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_retry_fifo_full/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_spec_ref/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_tcr_mrr/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_war_hazard/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_waw_hazard/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_win_limit_reached_rd/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_win_limit_reached_wr/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_wr_crc_error/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_wr_trxn_crit_access/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_write_combine/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_zqcl/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_zqlatch/ [Kernel PMU event]
+ mrvl_ddr_pmu_<>/ddr_zqstart/ [Kernel PMU event]
+
+ $ perf stat -e ddr_cam_read,ddr_cam_write,ddr_cam_active_access,ddr_cam
+ rd_or_wr_access,ddr_cam_rd_active_access,ddr_cam_mwr <workload>
diff --git a/Documentation/admin-guide/perf/mrvl-odyssey-tad-pmu.rst b/Documentation/admin-guide/perf/mrvl-odyssey-tad-pmu.rst
new file mode 100644
index 000000000000..ad1975b14087
--- /dev/null
+++ b/Documentation/admin-guide/perf/mrvl-odyssey-tad-pmu.rst
@@ -0,0 +1,37 @@
+====================================================================
+Marvell Odyssey LLC-TAD Performance Monitoring Unit (PMU UNCORE)
+====================================================================
+
+Each TAD provides eight 64-bit counters for monitoring
+cache behavior.The driver always configures the same counter for
+all the TADs. The user would end up effectively reserving one of
+eight counters in every TAD to look across all TADs.
+The occurrences of events are aggregated and presented to the user
+at the end of running the workload. The driver does not provide a
+way for the user to partition TADs so that different TADs are used for
+different applications.
+
+The performance events reflect various internal or interface activities.
+By combining the values from multiple performance counters, cache
+performance can be measured in terms such as: cache miss rate, cache
+allocations, interface retry rate, internal resource occupancy, etc.
+
+The PMU driver exposes the available events and format options under sysfs::
+
+ /sys/bus/event_source/devices/tad/events/
+ /sys/bus/event_source/devices/tad/format/
+
+Examples::
+
+ $ perf list | grep tad
+ tad/tad_alloc_any/ [Kernel PMU event]
+ tad/tad_alloc_dtg/ [Kernel PMU event]
+ tad/tad_alloc_ltg/ [Kernel PMU event]
+ tad/tad_hit_any/ [Kernel PMU event]
+ tad/tad_hit_dtg/ [Kernel PMU event]
+ tad/tad_hit_ltg/ [Kernel PMU event]
+ tad/tad_req_msh_in_exlmn/ [Kernel PMU event]
+ tad/tad_tag_rd/ [Kernel PMU event]
+ tad/tad_tot_cycle/ [Kernel PMU event]
+
+ $ perf stat -e tad_alloc_dtg,tad_alloc_ltg,tad_alloc_any,tad_hit_dtg,tad_hit_ltg,tad_hit_any,tad_tag_rd <workload>
diff --git a/Documentation/admin-guide/perf/mrvl-pem-pmu.rst b/Documentation/admin-guide/perf/mrvl-pem-pmu.rst
new file mode 100644
index 000000000000..c39007149b97
--- /dev/null
+++ b/Documentation/admin-guide/perf/mrvl-pem-pmu.rst
@@ -0,0 +1,56 @@
+=================================================================
+Marvell Odyssey PEM Performance Monitoring Unit (PMU UNCORE)
+=================================================================
+
+The PCI Express Interface Units(PEM) are associated with a corresponding
+monitoring unit. This includes performance counters to track various
+characteristics of the data that is transmitted over the PCIe link.
+
+The counters track inbound and outbound transactions which
+includes separate counters for posted/non-posted/completion TLPs.
+Also, inbound and outbound memory read requests along with their
+latencies can also be monitored. Address Translation Services(ATS)events
+such as ATS Translation, ATS Page Request, ATS Invalidation along with
+their corresponding latencies are also tracked.
+
+There are separate 64 bit counters to measure posted/non-posted/completion
+tlps in inbound and outbound transactions. ATS events are measured by
+different counters.
+
+The PMU driver exposes the available events and format options under sysfs,
+/sys/bus/event_source/devices/mrvl_pcie_rc_pmu_<>/events/
+/sys/bus/event_source/devices/mrvl_pcie_rc_pmu_<>/format/
+
+Examples::
+
+ # perf list | grep mrvl_pcie_rc_pmu
+ mrvl_pcie_rc_pmu_<>/ats_inv/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ats_inv_latency/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ats_pri/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ats_pri_latency/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ats_trans/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ats_trans_latency/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_inflight/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_reads/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_req_no_ro_ebus/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_req_no_ro_ncb/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_tlp_cpl_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_tlp_dwords_cpl_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_tlp_dwords_npr/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_tlp_dwords_pr/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_tlp_npr/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ib_tlp_pr/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_inflight_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_merges_cpl_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_merges_npr_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_merges_pr_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_reads_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_tlp_cpl_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_tlp_dwords_cpl_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_tlp_dwords_npr_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_tlp_dwords_pr_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_tlp_npr_partid/ [Kernel PMU event]
+ mrvl_pcie_rc_pmu_<>/ob_tlp_pr_partid/ [Kernel PMU event]
+
+
+ # perf stat -e ib_inflight,ib_reads,ib_req_no_ro_ebus,ib_req_no_ro_ncb <workload>
diff --git a/Documentation/admin-guide/perf/nvidia-pmu.rst b/Documentation/admin-guide/perf/nvidia-pmu.rst
new file mode 100644
index 000000000000..f538ef67e0e8
--- /dev/null
+++ b/Documentation/admin-guide/perf/nvidia-pmu.rst
@@ -0,0 +1,333 @@
+=========================================================
+NVIDIA Tegra SoC Uncore Performance Monitoring Unit (PMU)
+=========================================================
+
+The NVIDIA Tegra SoC includes various system PMUs to measure key performance
+metrics like memory bandwidth, latency, and utilization:
+
+* Scalable Coherency Fabric (SCF)
+* NVLink-C2C0
+* NVLink-C2C1
+* CNVLink
+* PCIE
+
+PMU Driver
+----------
+
+The PMUs in this document are based on ARM CoreSight PMU Architecture as
+described in document: ARM IHI 0091. Since this is a standard architecture, the
+PMUs are managed by a common driver "arm-cs-arch-pmu". This driver describes
+the available events and configuration of each PMU in sysfs. Please see the
+sections below to get the sysfs path of each PMU. Like other uncore PMU drivers,
+the driver provides "cpumask" sysfs attribute to show the CPU id used to handle
+the PMU event. There is also "associated_cpus" sysfs attribute, which contains a
+list of CPUs associated with the PMU instance.
+
+.. _SCF_PMU_Section:
+
+SCF PMU
+-------
+
+The SCF PMU monitors system level cache events, CPU traffic, and
+strongly-ordered (SO) PCIE write traffic to local/remote memory. Please see
+:ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` for more info about the PMU
+traffic coverage.
+
+The events and configuration options of this PMU device are described in sysfs,
+see /sys/bus/event_source/devices/nvidia_scf_pmu_<socket-id>.
+
+Example usage:
+
+* Count event id 0x0 in socket 0::
+
+ perf stat -a -e nvidia_scf_pmu_0/event=0x0/
+
+* Count event id 0x0 in socket 1::
+
+ perf stat -a -e nvidia_scf_pmu_1/event=0x0/
+
+NVLink-C2C0 PMU
+--------------------
+
+The NVLink-C2C0 PMU monitors incoming traffic from a GPU/CPU connected with
+NVLink-C2C (Chip-2-Chip) interconnect. The type of traffic captured by this PMU
+varies dependent on the chip configuration:
+
+* NVIDIA Grace Hopper Superchip: Hopper GPU is connected with Grace SoC.
+
+ In this config, the PMU captures GPU ATS translated or EGM traffic from the GPU.
+
+* NVIDIA Grace CPU Superchip: two Grace CPU SoCs are connected.
+
+ In this config, the PMU captures read and relaxed ordered (RO) writes from
+ PCIE device of the remote SoC.
+
+Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` for more info about
+the PMU traffic coverage.
+
+The events and configuration options of this PMU device are described in sysfs,
+see /sys/bus/event_source/devices/nvidia_nvlink_c2c0_pmu_<socket-id>.
+
+Example usage:
+
+* Count event id 0x0 from the GPU/CPU connected with socket 0::
+
+ perf stat -a -e nvidia_nvlink_c2c0_pmu_0/event=0x0/
+
+* Count event id 0x0 from the GPU/CPU connected with socket 1::
+
+ perf stat -a -e nvidia_nvlink_c2c0_pmu_1/event=0x0/
+
+* Count event id 0x0 from the GPU/CPU connected with socket 2::
+
+ perf stat -a -e nvidia_nvlink_c2c0_pmu_2/event=0x0/
+
+* Count event id 0x0 from the GPU/CPU connected with socket 3::
+
+ perf stat -a -e nvidia_nvlink_c2c0_pmu_3/event=0x0/
+
+The NVLink-C2C has two ports that can be connected to one GPU (occupying both
+ports) or to two GPUs (one GPU per port). The user can use "port" bitmap
+parameter to select the port(s) to monitor. Each bit represents the port number,
+e.g. "port=0x1" corresponds to port 0 and "port=0x3" is for port 0 and 1. The
+PMU will monitor both ports by default if not specified.
+
+Example for port filtering:
+
+* Count event id 0x0 from the GPU connected with socket 0 on port 0::
+
+ perf stat -a -e nvidia_nvlink_c2c0_pmu_0/event=0x0,port=0x1/
+
+* Count event id 0x0 from the GPUs connected with socket 0 on port 0 and port 1::
+
+ perf stat -a -e nvidia_nvlink_c2c0_pmu_0/event=0x0,port=0x3/
+
+NVLink-C2C1 PMU
+-------------------
+
+The NVLink-C2C1 PMU monitors incoming traffic from a GPU connected with
+NVLink-C2C (Chip-2-Chip) interconnect. This PMU captures untranslated GPU
+traffic, in contrast with NvLink-C2C0 PMU that captures ATS translated traffic.
+Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section` for more info about
+the PMU traffic coverage.
+
+The events and configuration options of this PMU device are described in sysfs,
+see /sys/bus/event_source/devices/nvidia_nvlink_c2c1_pmu_<socket-id>.
+
+Example usage:
+
+* Count event id 0x0 from the GPU connected with socket 0::
+
+ perf stat -a -e nvidia_nvlink_c2c1_pmu_0/event=0x0/
+
+* Count event id 0x0 from the GPU connected with socket 1::
+
+ perf stat -a -e nvidia_nvlink_c2c1_pmu_1/event=0x0/
+
+* Count event id 0x0 from the GPU connected with socket 2::
+
+ perf stat -a -e nvidia_nvlink_c2c1_pmu_2/event=0x0/
+
+* Count event id 0x0 from the GPU connected with socket 3::
+
+ perf stat -a -e nvidia_nvlink_c2c1_pmu_3/event=0x0/
+
+The NVLink-C2C has two ports that can be connected to one GPU (occupying both
+ports) or to two GPUs (one GPU per port). The user can use "port" bitmap
+parameter to select the port(s) to monitor. Each bit represents the port number,
+e.g. "port=0x1" corresponds to port 0 and "port=0x3" is for port 0 and 1. The
+PMU will monitor both ports by default if not specified.
+
+Example for port filtering:
+
+* Count event id 0x0 from the GPU connected with socket 0 on port 0::
+
+ perf stat -a -e nvidia_nvlink_c2c1_pmu_0/event=0x0,port=0x1/
+
+* Count event id 0x0 from the GPUs connected with socket 0 on port 0 and port 1::
+
+ perf stat -a -e nvidia_nvlink_c2c1_pmu_0/event=0x0,port=0x3/
+
+CNVLink PMU
+---------------
+
+The CNVLink PMU monitors traffic from GPU and PCIE device on remote sockets
+to local memory. For PCIE traffic, this PMU captures read and relaxed ordered
+(RO) write traffic. Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section`
+for more info about the PMU traffic coverage.
+
+The events and configuration options of this PMU device are described in sysfs,
+see /sys/bus/event_source/devices/nvidia_cnvlink_pmu_<socket-id>.
+
+Each SoC socket can be connected to one or more sockets via CNVLink. The user can
+use "rem_socket" bitmap parameter to select the remote socket(s) to monitor.
+Each bit represents the socket number, e.g. "rem_socket=0xE" corresponds to
+socket 1 to 3. The PMU will monitor all remote sockets by default if not
+specified.
+/sys/bus/event_source/devices/nvidia_cnvlink_pmu_<socket-id>/format/rem_socket
+shows the valid bits that can be set in the "rem_socket" parameter.
+
+The PMU can not distinguish the remote traffic initiator, therefore it does not
+provide filter to select the traffic source to monitor. It reports combined
+traffic from remote GPU and PCIE devices.
+
+Example usage:
+
+* Count event id 0x0 for the traffic from remote socket 1, 2, and 3 to socket 0::
+
+ perf stat -a -e nvidia_cnvlink_pmu_0/event=0x0,rem_socket=0xE/
+
+* Count event id 0x0 for the traffic from remote socket 0, 2, and 3 to socket 1::
+
+ perf stat -a -e nvidia_cnvlink_pmu_1/event=0x0,rem_socket=0xD/
+
+* Count event id 0x0 for the traffic from remote socket 0, 1, and 3 to socket 2::
+
+ perf stat -a -e nvidia_cnvlink_pmu_2/event=0x0,rem_socket=0xB/
+
+* Count event id 0x0 for the traffic from remote socket 0, 1, and 2 to socket 3::
+
+ perf stat -a -e nvidia_cnvlink_pmu_3/event=0x0,rem_socket=0x7/
+
+
+PCIE PMU
+------------
+
+The PCIE PMU monitors all read/write traffic from PCIE root ports to
+local/remote memory. Please see :ref:`NVIDIA_Uncore_PMU_Traffic_Coverage_Section`
+for more info about the PMU traffic coverage.
+
+The events and configuration options of this PMU device are described in sysfs,
+see /sys/bus/event_source/devices/nvidia_pcie_pmu_<socket-id>.
+
+Each SoC socket can support multiple root ports. The user can use
+"root_port" bitmap parameter to select the port(s) to monitor, i.e.
+"root_port=0xF" corresponds to root port 0 to 3. The PMU will monitor all root
+ports by default if not specified.
+/sys/bus/event_source/devices/nvidia_pcie_pmu_<socket-id>/format/root_port
+shows the valid bits that can be set in the "root_port" parameter.
+
+Example usage:
+
+* Count event id 0x0 from root port 0 and 1 of socket 0::
+
+ perf stat -a -e nvidia_pcie_pmu_0/event=0x0,root_port=0x3/
+
+* Count event id 0x0 from root port 0 and 1 of socket 1::
+
+ perf stat -a -e nvidia_pcie_pmu_1/event=0x0,root_port=0x3/
+
+.. _NVIDIA_Uncore_PMU_Traffic_Coverage_Section:
+
+Traffic Coverage
+----------------
+
+The PMU traffic coverage may vary dependent on the chip configuration:
+
+* **NVIDIA Grace Hopper Superchip**: Hopper GPU is connected with Grace SoC.
+
+ Example configuration with two Grace SoCs::
+
+ ********************************* *********************************
+ * SOCKET-A * * SOCKET-B *
+ * * * *
+ * :::::::: * * :::::::: *
+ * : PCIE : * * : PCIE : *
+ * :::::::: * * :::::::: *
+ * | * * | *
+ * | * * | *
+ * ::::::: ::::::::: * * ::::::::: ::::::: *
+ * : : : : * * : : : : *
+ * : GPU :<--NVLink-->: Grace :<---CNVLink--->: Grace :<--NVLink-->: GPU : *
+ * : : C2C : SoC : * * : SoC : C2C : : *
+ * ::::::: ::::::::: * * ::::::::: ::::::: *
+ * | | * * | | *
+ * | | * * | | *
+ * &&&&&&&& &&&&&&&& * * &&&&&&&& &&&&&&&& *
+ * & GMEM & & CMEM & * * & CMEM & & GMEM & *
+ * &&&&&&&& &&&&&&&& * * &&&&&&&& &&&&&&&& *
+ * * * *
+ ********************************* *********************************
+
+ GMEM = GPU Memory (e.g. HBM)
+ CMEM = CPU Memory (e.g. LPDDR5X)
+
+ |
+ | Following table contains traffic coverage of Grace SoC PMU in socket-A:
+
+ ::
+
+ +--------------+-------+-----------+-----------+-----+----------+----------+
+ | | Source |
+ + +-------+-----------+-----------+-----+----------+----------+
+ | Destination | |GPU ATS |GPU Not-ATS| | Socket-B | Socket-B |
+ | |PCI R/W|Translated,|Translated | CPU | CPU/PCIE1| GPU/PCIE2|
+ | | |EGM | | | | |
+ +==============+=======+===========+===========+=====+==========+==========+
+ | Local | PCIE |NVLink-C2C0|NVLink-C2C1| SCF | SCF PMU | CNVLink |
+ | SYSRAM/CMEM | PMU |PMU |PMU | PMU | | PMU |
+ +--------------+-------+-----------+-----------+-----+----------+----------+
+ | Local GMEM | PCIE | N/A |NVLink-C2C1| SCF | SCF PMU | CNVLink |
+ | | PMU | |PMU | PMU | | PMU |
+ +--------------+-------+-----------+-----------+-----+----------+----------+
+ | Remote | PCIE |NVLink-C2C0|NVLink-C2C1| SCF | | |
+ | SYSRAM/CMEM | PMU |PMU |PMU | PMU | N/A | N/A |
+ | over CNVLink | | | | | | |
+ +--------------+-------+-----------+-----------+-----+----------+----------+
+ | Remote GMEM | PCIE |NVLink-C2C0|NVLink-C2C1| SCF | | |
+ | over CNVLink | PMU |PMU |PMU | PMU | N/A | N/A |
+ +--------------+-------+-----------+-----------+-----+----------+----------+
+
+ PCIE1 traffic represents strongly ordered (SO) writes.
+ PCIE2 traffic represents reads and relaxed ordered (RO) writes.
+
+* **NVIDIA Grace CPU Superchip**: two Grace CPU SoCs are connected.
+
+ Example configuration with two Grace SoCs::
+
+ ******************* *******************
+ * SOCKET-A * * SOCKET-B *
+ * * * *
+ * :::::::: * * :::::::: *
+ * : PCIE : * * : PCIE : *
+ * :::::::: * * :::::::: *
+ * | * * | *
+ * | * * | *
+ * ::::::::: * * ::::::::: *
+ * : : * * : : *
+ * : Grace :<--------NVLink------->: Grace : *
+ * : SoC : * C2C * : SoC : *
+ * ::::::::: * * ::::::::: *
+ * | * * | *
+ * | * * | *
+ * &&&&&&&& * * &&&&&&&& *
+ * & CMEM & * * & CMEM & *
+ * &&&&&&&& * * &&&&&&&& *
+ * * * *
+ ******************* *******************
+
+ GMEM = GPU Memory (e.g. HBM)
+ CMEM = CPU Memory (e.g. LPDDR5X)
+
+ |
+ | Following table contains traffic coverage of Grace SoC PMU in socket-A:
+
+ ::
+
+ +-----------------+-----------+---------+----------+-------------+
+ | | Source |
+ + +-----------+---------+----------+-------------+
+ | Destination | | | Socket-B | Socket-B |
+ | | PCI R/W | CPU | CPU/PCIE1| PCIE2 |
+ | | | | | |
+ +=================+===========+=========+==========+=============+
+ | Local | PCIE PMU | SCF PMU | SCF PMU | NVLink-C2C0 |
+ | SYSRAM/CMEM | | | | PMU |
+ +-----------------+-----------+---------+----------+-------------+
+ | Remote | | | | |
+ | SYSRAM/CMEM | PCIE PMU | SCF PMU | N/A | N/A |
+ | over NVLink-C2C | | | | |
+ +-----------------+-----------+---------+----------+-------------+
+
+ PCIE1 traffic represents strongly ordered (SO) writes.
+ PCIE2 traffic represents reads and relaxed ordered (RO) writes.
diff --git a/Documentation/admin-guide/perf/qcom_l2_pmu.rst b/Documentation/admin-guide/perf/qcom_l2_pmu.rst
index c130178a4a55..c37c6be9b8d8 100644
--- a/Documentation/admin-guide/perf/qcom_l2_pmu.rst
+++ b/Documentation/admin-guide/perf/qcom_l2_pmu.rst
@@ -10,7 +10,7 @@ There is one logical L2 PMU exposed, which aggregates the results from
the physical PMUs.
The driver provides a description of its available events and configuration
-options in sysfs, see /sys/devices/l2cache_0.
+options in sysfs, see /sys/bus/event_source/devices/l2cache_0.
The "format" directory describes the format of the events.
diff --git a/Documentation/admin-guide/perf/qcom_l3_pmu.rst b/Documentation/admin-guide/perf/qcom_l3_pmu.rst
index a3d014a46bfd..a66556b7e985 100644
--- a/Documentation/admin-guide/perf/qcom_l3_pmu.rst
+++ b/Documentation/admin-guide/perf/qcom_l3_pmu.rst
@@ -9,7 +9,7 @@ PMU with device name l3cache_<socket>_<instance>. User space is responsible
for aggregating across slices.
The driver provides a description of its available events and configuration
-options in sysfs, see /sys/devices/l3cache*. Given that these are uncore PMUs
+options in sysfs, see /sys/bus/event_source/devices/l3cache*. Given that these are uncore PMUs
the driver also exposes a "cpumask" sysfs attribute which contains a mask
consisting of one CPU per socket which will be used to handle all the PMU
events on that socket.
diff --git a/Documentation/admin-guide/perf/starfive_starlink_pmu.rst b/Documentation/admin-guide/perf/starfive_starlink_pmu.rst
new file mode 100644
index 000000000000..2932ddb4eb76
--- /dev/null
+++ b/Documentation/admin-guide/perf/starfive_starlink_pmu.rst
@@ -0,0 +1,46 @@
+================================================
+StarFive StarLink Performance Monitor Unit (PMU)
+================================================
+
+StarFive StarLink Performance Monitor Unit (PMU) exists within the
+StarLink Coherent Network on Chip (CNoC) that connects multiple CPU
+clusters with an L3 memory system.
+
+The uncore PMU supports overflow interrupt, up to 16 programmable 64bit
+event counters, and an independent 64bit cycle counter.
+The PMU can only be accessed via Memory Mapped I/O and are common to the
+cores connected to the same PMU.
+
+Driver exposes supported PMU events in sysfs "events" directory under::
+
+ /sys/bus/event_source/devices/starfive_starlink_pmu/events/
+
+Driver exposes cpu used to handle PMU events in sysfs "cpumask" directory
+under::
+
+ /sys/bus/event_source/devices/starfive_starlink_pmu/cpumask/
+
+Driver describes the format of config (event ID) in sysfs "format" directory
+under::
+
+ /sys/bus/event_source/devices/starfive_starlink_pmu/format/
+
+Example of perf usage::
+
+ $ perf list
+
+ starfive_starlink_pmu/cycles/ [Kernel PMU event]
+ starfive_starlink_pmu/read_hit/ [Kernel PMU event]
+ starfive_starlink_pmu/read_miss/ [Kernel PMU event]
+ starfive_starlink_pmu/read_request/ [Kernel PMU event]
+ starfive_starlink_pmu/release_request/ [Kernel PMU event]
+ starfive_starlink_pmu/write_hit/ [Kernel PMU event]
+ starfive_starlink_pmu/write_miss/ [Kernel PMU event]
+ starfive_starlink_pmu/write_request/ [Kernel PMU event]
+ starfive_starlink_pmu/writeback/ [Kernel PMU event]
+
+
+ $ perf stat -a -e /starfive_starlink_pmu/cycles/ sleep 1
+
+Sampling is not supported. As a result, "perf record" is not supported.
+Attaching to a task is not supported, only system-wide counting is supported.
diff --git a/Documentation/admin-guide/perf/thunderx2-pmu.rst b/Documentation/admin-guide/perf/thunderx2-pmu.rst
index 01f158238ae1..9255f7bf9452 100644
--- a/Documentation/admin-guide/perf/thunderx2-pmu.rst
+++ b/Documentation/admin-guide/perf/thunderx2-pmu.rst
@@ -22,7 +22,7 @@ The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
(CCPI2) events simultaneously. The PMUs provide a description of their
available events and configuration options under sysfs, see
-/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
+/sys/bus/event_source/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
The driver does not support sampling, therefore "perf record" will not
work. Per-task perf sessions are also not supported.
diff --git a/Documentation/admin-guide/perf/xgene-pmu.rst b/Documentation/admin-guide/perf/xgene-pmu.rst
index 644f8ed89152..98ccb8e777c4 100644
--- a/Documentation/admin-guide/perf/xgene-pmu.rst
+++ b/Documentation/admin-guide/perf/xgene-pmu.rst
@@ -13,7 +13,7 @@ PMU (perf) driver
The xgene-pmu driver registers several perf PMU drivers. Each of the perf
driver provides description of its available events and configuration options
-in sysfs, see /sys/devices/<l3cX/iobX/mcbX/mcX>/.
+in sysfs, see /sys/bus/event_source/devices/<l3cX/iobX/mcbX/mcX>/.
The "format" directory describes format of the config (event ID),
config1 (agent ID) fields of the perf_event_attr structure. The "events"
diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst
index 8f3d30c5a0d8..e1771f2225d5 100644
--- a/Documentation/admin-guide/pm/amd-pstate.rst
+++ b/Documentation/admin-guide/pm/amd-pstate.rst
@@ -72,7 +72,7 @@ to manage each performance update behavior. ::
Lowest non- | | | |
linear perf ------>+-----------------------+ +-----------------------+
| | | |
- | | Lowest perf ---->| |
+ | | Min perf ---->| |
| | | |
Lowest perf ------>+-----------------------+ +-----------------------+
| | | |
@@ -230,8 +230,8 @@ with :c:macro:`MSR_AMD_CPPC_ENABLE` or ``cppc_set_enable``, it will respond
to the request from AMD P-States.
-User Space Interface in ``sysfs``
-==================================
+User Space Interface in ``sysfs`` - Per-policy control
+======================================================
``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to
control its functionality at the system level. They are located in the
@@ -262,6 +262,52 @@ lowest non-linear performance in `AMD CPPC Performance Capability
<perf_cap_>`_.)
This attribute is read-only.
+``amd_pstate_hw_prefcore``
+
+Whether the platform supports the preferred core feature and it has been
+enabled. This attribute is read-only.
+
+``amd_pstate_prefcore_ranking``
+
+The performance ranking of the core. This number doesn't have any unit, but
+larger numbers are preferred at the time of reading. This can change at
+runtime based on platform conditions. This attribute is read-only.
+
+``energy_performance_available_preferences``
+
+A list of all the supported EPP preferences that could be used for
+``energy_performance_preference`` on this system.
+These profiles represent different hints that are provided
+to the low-level firmware about the user's desired energy vs efficiency
+tradeoff. ``default`` represents the epp value is set by platform
+firmware. This attribute is read-only.
+
+``energy_performance_preference``
+
+The current energy performance preference can be read from this attribute.
+and user can change current preference according to energy or performance needs
+Please get all support profiles list from
+``energy_performance_available_preferences`` attribute, all the profiles are
+integer values defined between 0 to 255 when EPP feature is enabled by platform
+firmware, if EPP feature is disabled, driver will ignore the written value
+This attribute is read-write.
+
+``boost``
+The `boost` sysfs attribute provides control over the CPU core
+performance boost, allowing users to manage the maximum frequency limitation
+of the CPU. This attribute can be used to enable or disable the boost feature
+on individual CPUs.
+
+When the boost feature is enabled, the CPU can dynamically increase its frequency
+beyond the base frequency, providing enhanced performance for demanding workloads.
+On the other hand, disabling the boost feature restricts the CPU to operate at the
+base frequency, which may be desirable in certain scenarios to prioritize power
+efficiency or manage temperature.
+
+To manipulate the `boost` attribute, users can write a value of `0` to disable the
+boost or `1` to enable it, for the respective CPU using the sysfs path
+`/sys/devices/system/cpu/cpuX/cpufreq/boost`, where `X` represents the CPU number.
+
Other performance and frequency values can be read back from
``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`.
@@ -280,27 +326,146 @@ module which supports the new AMD P-States mechanism on most of the future AMD
platforms. The AMD P-States mechanism is the more performance and energy
efficiency frequency management method on AMD processors.
-Kernel Module Options for ``amd-pstate``
-=========================================
-.. _shared_mem:
+``amd-pstate`` Driver Operation Modes
+======================================
+
+``amd_pstate`` CPPC has 3 operation modes: autonomous (active) mode,
+non-autonomous (passive) mode and guided autonomous (guided) mode.
+Active/passive/guided mode can be chosen by different kernel parameters.
+
+- In autonomous mode, platform ignores the desired performance level request
+ and takes into account only the values set to the minimum, maximum and energy
+ performance preference registers.
+- In non-autonomous mode, platform gets desired performance level
+ from OS directly through Desired Performance Register.
+- In guided-autonomous mode, platform sets operating performance level
+ autonomously according to the current workload and within the limits set by
+ OS through min and max performance registers.
+
+Active Mode
+------------
+
+``amd_pstate=active``
+
+This is the low-level firmware control mode which is implemented by ``amd_pstate_epp``
+driver with ``amd_pstate=active`` passed to the kernel in the command line.
+In this mode, ``amd_pstate_epp`` driver provides a hint to the hardware if software
+wants to bias toward performance (0x0) or energy efficiency (0xff) to the CPPC firmware.
+then CPPC power algorithm will calculate the runtime workload and adjust the realtime
+cores frequency according to the power supply and thermal, core voltage and some other
+hardware conditions.
+
+Passive Mode
+------------
+
+``amd_pstate=passive``
+
+It will be enabled if the ``amd_pstate=passive`` is passed to the kernel in the command line.
+In this mode, ``amd_pstate`` driver software specifies a desired QoS target in the CPPC
+performance scale as a relative number. This can be expressed as percentage of nominal
+performance (infrastructure max). Below the nominal sustained performance level,
+desired performance expresses the average performance level of the processor subject
+to the Performance Reduction Tolerance register. Above the nominal performance level,
+processor must provide at least nominal performance requested and go higher if current
+operating conditions allow.
+
+Guided Mode
+-----------
+
+``amd_pstate=guided``
+
+If ``amd_pstate=guided`` is passed to kernel command line option then this mode
+is activated. In this mode, driver requests minimum and maximum performance
+level and the platform autonomously selects a performance level in this range
+and appropriate to the current workload.
+
+``amd-pstate`` Preferred Core
+=================================
+
+The core frequency is subjected to the process variation in semiconductors.
+Not all cores are able to reach the maximum frequency respecting the
+infrastructure limits. Consequently, AMD has redefined the concept of
+maximum frequency of a part. This means that a fraction of cores can reach
+maximum frequency. To find the best process scheduling policy for a given
+scenario, OS needs to know the core ordering informed by the platform through
+highest performance capability register of the CPPC interface.
+
+``amd-pstate`` preferred core enables the scheduler to prefer scheduling on
+cores that can achieve a higher frequency with lower voltage. The preferred
+core rankings can dynamically change based on the workload, platform conditions,
+thermals and ageing.
+
+The priority metric will be initialized by the ``amd-pstate`` driver. The ``amd-pstate``
+driver will also determine whether or not ``amd-pstate`` preferred core is
+supported by the platform.
+
+``amd-pstate`` driver will provide an initial core ordering when the system boots.
+The platform uses the CPPC interfaces to communicate the core ranking to the
+operating system and scheduler to make sure that OS is choosing the cores
+with highest performance firstly for scheduling the process. When ``amd-pstate``
+driver receives a message with the highest performance change, it will
+update the core ranking and set the cpu's priority.
+
+``amd-pstate`` Preferred Core Switch
+=====================================
+Kernel Parameters
+-----------------
+
+``amd-pstate`` peferred core`` has two states: enable and disable.
+Enable/disable states can be chosen by different kernel parameters.
+Default enable ``amd-pstate`` preferred core.
+
+``amd_prefcore=disable``
+
+For systems that support ``amd-pstate`` preferred core, the core rankings will
+always be advertised by the platform. But OS can choose to ignore that via the
+kernel parameter ``amd_prefcore=disable``.
+
+User Space Interface in ``sysfs`` - General
+===========================================
+
+Global Attributes
+-----------------
+
+``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to
+control its functionality at the system level. They are located in the
+``/sys/devices/system/cpu/amd_pstate/`` directory and affect all CPUs.
+
+``status``
+ Operation mode of the driver: "active", "passive", "guided" or "disable".
+
+ "active"
+ The driver is functional and in the ``active mode``
-``shared_mem``
-Use a module param (shared_mem) to enable related processors manually with
-**amd_pstate.shared_mem=1**.
-Due to the performance issue on the processors with `Shared Memory Support
-<perf_cap_>`_, we disable it presently and will re-enable this by default
-once we address performance issue with this solution.
+ "passive"
+ The driver is functional and in the ``passive mode``
-To check whether the current processor is using `Full MSR Support <perf_cap_>`_
-or `Shared Memory Support <perf_cap_>`_ : ::
+ "guided"
+ The driver is functional and in the ``guided mode``
- ray@hr-test1:~$ lscpu | grep cppc
- Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
+ "disable"
+ The driver is unregistered and not functional now.
-If the CPU flags have ``cppc``, then this processor supports `Full MSR Support
-<perf_cap_>`_. Otherwise, it supports `Shared Memory Support <perf_cap_>`_.
+ This attribute can be written to in order to change the driver's
+ operation mode or to unregister it. The string written to it must be
+ one of the possible values of it and, if successful, writing one of
+ these values to the sysfs file will cause the driver to switch over
+ to the operation mode represented by that string - or to be
+ unregistered in the "disable" case.
+``prefcore``
+ Preferred core state of the driver: "enabled" or "disabled".
+
+ "enabled"
+ Enable the ``amd-pstate`` preferred core.
+
+ "disabled"
+ Disable the ``amd-pstate`` preferred core
+
+
+ This attribute is read-only to check the state of preferred core set
+ by the kernel parameter.
``cpupower`` tool support for ``amd-pstate``
===============================================
@@ -407,39 +572,57 @@ Unit Tests for amd-pstate
* We can introduce more functional or performance tests to align the result together, it will benefit power and performance scale optimization.
-1. Test case decriptions
+1. Test case descriptions
+
+ 1). Basic tests
+
+ Test prerequisite and basic functions for the ``amd-pstate`` driver.
+---------+--------------------------------+------------------------------------------------------------------------------------+
| Index | Functions | Description |
+=========+================================+====================================================================================+
- | 0 | amd_pstate_ut_acpi_cpc_valid || Check whether the _CPC object is present in SBIOS. |
+ | 1 | amd_pstate_ut_acpi_cpc_valid || Check whether the _CPC object is present in SBIOS. |
| | || |
| | || The detail refer to `Processor Support <processor_support_>`_. |
+---------+--------------------------------+------------------------------------------------------------------------------------+
- | 1 | amd_pstate_ut_check_enabled || Check whether AMD P-State is enabled. |
+ | 2 | amd_pstate_ut_check_enabled || Check whether AMD P-State is enabled. |
| | || |
| | || AMD P-States and ACPI hardware P-States always can be supported in one processor. |
| | | But AMD P-States has the higher priority and if it is enabled with |
| | | :c:macro:`MSR_AMD_CPPC_ENABLE` or ``cppc_set_enable``, it will respond to the |
| | | request from AMD P-States. |
+---------+--------------------------------+------------------------------------------------------------------------------------+
- | 2 | amd_pstate_ut_check_perf || Check if the each performance values are reasonable. |
+ | 3 | amd_pstate_ut_check_perf || Check if the each performance values are reasonable. |
| | || highest_perf >= nominal_perf > lowest_nonlinear_perf > lowest_perf > 0. |
+---------+--------------------------------+------------------------------------------------------------------------------------+
- | 3 | amd_pstate_ut_check_freq || Check if the each frequency values and max freq when set support boost mode |
+ | 4 | amd_pstate_ut_check_freq || Check if the each frequency values and max freq when set support boost mode |
| | | are reasonable. |
| | || max_freq >= nominal_freq > lowest_nonlinear_freq > min_freq > 0 |
| | || If boost is not active but supported, this maximum frequency will be larger than |
| | | the one in ``cpuinfo``. |
+---------+--------------------------------+------------------------------------------------------------------------------------+
+ 2). Tbench test
+
+ Test and monitor the cpu changes when running tbench benchmark under the specified governor.
+ These changes include desire performance, frequency, load, performance, energy etc.
+ The specified governor is ondemand or schedutil.
+ Tbench can also be tested on the ``acpi-cpufreq`` kernel driver for comparison.
+
+ 3). Gitsource test
+
+ Test and monitor the cpu changes when running gitsource benchmark under the specified governor.
+ These changes include desire performance, frequency, load, time, energy etc.
+ The specified governor is ondemand or schedutil.
+ Gitsource can also be tested on the ``acpi-cpufreq`` kernel driver for comparison.
+
#. How to execute the tests
We use test module in the kselftest frameworks to implement it.
- We create amd-pstate-ut module and tie it into kselftest.(for
+ We create ``amd-pstate-ut`` module and tie it into kselftest.(for
details refer to Linux Kernel Selftests [4]_).
- 1. Build
+ 1). Build
+ open the :c:macro:`CONFIG_X86_AMD_PSTATE` configuration option.
+ set the :c:macro:`CONFIG_X86_AMD_PSTATE_UT` configuration option to M.
@@ -449,23 +632,159 @@ Unit Tests for amd-pstate
$ cd linux
$ make -C tools/testing/selftests
- #. Installation & Steps ::
+ + make perf ::
+
+ $ cd tools/perf/
+ $ make
+
+
+ 2). Installation & Steps ::
$ make -C tools/testing/selftests install INSTALL_PATH=~/kselftest
+ $ cp tools/perf/perf /usr/bin/perf
$ sudo ./kselftest/run_kselftest.sh -c amd-pstate
- TAP version 13
- 1..1
- # selftests: amd-pstate: amd-pstate-ut.sh
- # amd-pstate-ut: ok
- ok 1 selftests: amd-pstate: amd-pstate-ut.sh
-
- #. Results ::
-
- $ dmesg | grep "amd_pstate_ut" | tee log.txt
- [12977.570663] amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success!
- [12977.570673] amd_pstate_ut: 2 amd_pstate_ut_check_enabled success!
- [12977.571207] amd_pstate_ut: 3 amd_pstate_ut_check_perf success!
- [12977.571212] amd_pstate_ut: 4 amd_pstate_ut_check_freq success!
+
+ 3). Specified test case ::
+
+ $ cd ~/kselftest/amd-pstate
+ $ sudo ./run.sh -t basic
+ $ sudo ./run.sh -t tbench
+ $ sudo ./run.sh -t tbench -m acpi-cpufreq
+ $ sudo ./run.sh -t gitsource
+ $ sudo ./run.sh -t gitsource -m acpi-cpufreq
+ $ ./run.sh --help
+ ./run.sh: illegal option -- -
+ Usage: ./run.sh [OPTION...]
+ [-h <help>]
+ [-o <output-file-for-dump>]
+ [-c <all: All testing,
+ basic: Basic testing,
+ tbench: Tbench testing,
+ gitsource: Gitsource testing.>]
+ [-t <tbench time limit>]
+ [-p <tbench process number>]
+ [-l <loop times for tbench>]
+ [-i <amd tracer interval>]
+ [-m <comparative test: acpi-cpufreq>]
+
+
+ 4). Results
+
+ + basic
+
+ When you finish test, you will get the following log info ::
+
+ $ dmesg | grep "amd_pstate_ut" | tee log.txt
+ [12977.570663] amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success!
+ [12977.570673] amd_pstate_ut: 2 amd_pstate_ut_check_enabled success!
+ [12977.571207] amd_pstate_ut: 3 amd_pstate_ut_check_perf success!
+ [12977.571212] amd_pstate_ut: 4 amd_pstate_ut_check_freq success!
+
+ + tbench
+
+ When you finish test, you will get selftest.tbench.csv and png images.
+ The selftest.tbench.csv file contains the raw data and the drop of the comparative test.
+ The png images shows the performance, energy and performan per watt of each test.
+ Open selftest.tbench.csv :
+
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + Governor | Round | Des-perf | Freq | Load | Performance | Energy | Performance Per Watt |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + Unit | | | GHz | | MB/s | J | MB/J |
+ +=================================================+==============+==========+=========+==========+=============+=========+======================+
+ + amd-pstate-ondemand | 1 | | | | 2504.05 | 1563.67 | 158.5378 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand | 2 | | | | 2243.64 | 1430.32 | 155.2941 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand | 3 | | | | 2183.88 | 1401.32 | 154.2860 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand | Average | | | | 2310.52 | 1465.1 | 156.1268 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | 1 | 165.329 | 1.62257 | 99.798 | 2136.54 | 1395.26 | 151.5971 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | 2 | 166 | 1.49761 | 99.9993 | 2100.56 | 1380.5 | 150.6377 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | 3 | 166 | 1.47806 | 99.9993 | 2084.12 | 1375.76 | 149.9737 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | Average | 165.776 | 1.53275 | 99.9322 | 2107.07 | 1383.84 | 150.7399 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | 1 | | | | 2529.9 | 1564.4 | 160.0997 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | 2 | | | | 2249.76 | 1432.97 | 155.4297 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | 3 | | | | 2181.46 | 1406.88 | 153.5060 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | Average | | | | 2320.37 | 1468.08 | 156.4741 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | 1 | | | | 2137.64 | 1385.24 | 152.7723 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | 2 | | | | 2107.05 | 1372.23 | 152.0138 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | 3 | | | | 2085.86 | 1365.35 | 151.2433 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | Average | | | | 2110.18 | 1374.27 | 152.0136 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand VS acpi-cpufreq-schedutil | Comprison(%) | | | | -9.0584 | -6.3899 | -2.8506 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand VS amd-pstate-schedutil | Comprison(%) | | | | 8.8053 | -5.5463 | -3.4503 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand VS amd-pstate-ondemand | Comprison(%) | | | | -0.4245 | -0.2029 | -0.2219 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil VS amd-pstate-schedutil | Comprison(%) | | | | -0.1473 | 0.6963 | -0.8378 |
+ +-------------------------------------------------+--------------+----------+---------+----------+-------------+---------+----------------------+
+
+ + gitsource
+
+ When you finish test, you will get selftest.gitsource.csv and png images.
+ The selftest.gitsource.csv file contains the raw data and the drop of the comparative test.
+ The png images shows the performance, energy and performan per watt of each test.
+ Open selftest.gitsource.csv :
+
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + Governor | Round | Des-perf | Freq | Load | Time | Energy | Performance Per Watt |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + Unit | | | GHz | | s | J | 1/J |
+ +=================================================+==============+==========+==========+==========+=============+=========+======================+
+ + amd-pstate-ondemand | 1 | 50.119 | 2.10509 | 23.3076 | 475.69 | 865.78 | 0.001155027 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand | 2 | 94.8006 | 1.98771 | 56.6533 | 467.1 | 839.67 | 0.001190944 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand | 3 | 76.6091 | 2.53251 | 43.7791 | 467.69 | 855.85 | 0.001168429 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand | Average | 73.8429 | 2.20844 | 41.2467 | 470.16 | 853.767 | 0.001171279 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | 1 | 165.919 | 1.62319 | 98.3868 | 464.17 | 866.8 | 0.001153668 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | 2 | 165.97 | 1.31309 | 99.5712 | 480.15 | 880.4 | 0.001135847 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | 3 | 165.973 | 1.28448 | 99.9252 | 481.79 | 867.02 | 0.001153375 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-schedutil | Average | 165.954 | 1.40692 | 99.2944 | 475.37 | 871.407 | 0.001147569 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | 1 | | | | 2379.62 | 742.96 | 0.001345967 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | 2 | | | | 441.74 | 817.49 | 0.001223256 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | 3 | | | | 455.48 | 820.01 | 0.001219497 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand | Average | | | | 425.613 | 793.487 | 0.001260260 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | 1 | | | | 459.69 | 838.54 | 0.001192548 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | 2 | | | | 466.55 | 830.89 | 0.001203528 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | 3 | | | | 470.38 | 837.32 | 0.001194286 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil | Average | | | | 465.54 | 835.583 | 0.001196769 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand VS acpi-cpufreq-schedutil | Comprison(%) | | | | 9.3810 | 5.3051 | -5.0379 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + amd-pstate-ondemand VS amd-pstate-schedutil | Comprison(%) | 124.7392 | -36.2934 | 140.7329 | 1.1081 | 2.0661 | -2.0242 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-ondemand VS amd-pstate-ondemand | Comprison(%) | | | | 10.4665 | 7.5968 | -7.0605 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
+ + acpi-cpufreq-schedutil VS amd-pstate-schedutil | Comprison(%) | | | | 2.1115 | 4.2873 | -4.1110 |
+ +-------------------------------------------------+--------------+----------+----------+----------+-------------+---------+----------------------+
Reference
===========
diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index 6adb7988e0eb..738d7b4dc33a 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -231,7 +231,7 @@ are the following:
present).
The existence of the limit may be a result of some (often unintentional)
- BIOS settings, restrictions coming from a service processor or another
+ BIOS settings, restrictions coming from a service processor or other
BIOS/HW-based mechanisms.
This does not cover ACPI thermal limitations which can be discovered
@@ -248,6 +248,20 @@ are the following:
If that frequency cannot be determined, this attribute should not
be present.
+``cpuinfo_avg_freq``
+ An average frequency (in KHz) of all CPUs belonging to a given policy,
+ derived from a hardware provided feedback and reported on a time frame
+ spanning at most few milliseconds.
+
+ This is expected to be based on the frequency the hardware actually runs
+ at and, as such, might require specialised hardware support (such as AMU
+ extension on ARM). If one cannot be determined, this attribute should
+ not be present.
+
+ Note that failed attempt to retrieve current frequency for a given
+ CPU(s) will result in an appropriate error, i.e.: EAGAIN for CPU that
+ remains idle (raised on ARM).
+
``cpuinfo_max_freq``
Maximum possible operating frequency the CPUs belonging to this policy
can run at (in kHz).
@@ -260,13 +274,13 @@ are the following:
The time it takes to switch the CPUs belonging to this policy from one
P-state to another, in nanoseconds.
- If unknown or if known to be so high that the scaling driver does not
- work with the `ondemand`_ governor, -1 (:c:macro:`CPUFREQ_ETERNAL`)
- will be returned by reads from this attribute.
-
``related_cpus``
List of all (online and offline) CPUs belonging to this policy.
+``scaling_available_frequencies``
+ List of available frequencies of the CPUs belonging to this policy
+ (in kHz).
+
``scaling_available_governors``
List of ``CPUFreq`` scaling governors present in the kernel that can
be attached to this policy or (if the |intel_pstate| scaling driver is
@@ -289,7 +303,8 @@ are the following:
Some architectures (e.g. ``x86``) may attempt to provide information
more precisely reflecting the current CPU frequency through this
attribute, but that still may not be the exact current CPU frequency as
- seen by the hardware at the moment.
+ seen by the hardware at the moment. This behavior though, is only
+ available via c:macro:``CPUFREQ_ARCH_CUR_FREQ`` option.
``scaling_driver``
The scaling driver currently in use.
@@ -379,7 +394,9 @@ policy limits change after that.
This governor does not do anything by itself. Instead, it allows user space
to set the CPU frequency for the policy it is attached to by writing to the
-``scaling_setspeed`` attribute of that policy.
+``scaling_setspeed`` attribute of that policy. Though the intention may be to
+set an exact frequency for the policy, the actual frequency may vary depending
+on hardware coordination, thermal and power limits, and other factors.
``schedutil``
-------------
@@ -421,8 +438,8 @@ This governor exposes only one tunable:
``rate_limit_us``
Minimum time (in microseconds) that has to pass between two consecutive
- runs of governor computations (default: 1000 times the scaling driver's
- transition latency).
+ runs of governor computations (default: 1.5 times the scaling driver's
+ transition latency or the maximum 2ms).
The purpose of this tunable is to reduce the scheduler context overhead
of the governor which might be excessive without it.
@@ -470,17 +487,17 @@ This governor exposes the following tunables:
This is how often the governor's worker routine should run, in
microseconds.
- Typically, it is set to values of the order of 10000 (10 ms). Its
- default value is equal to the value of ``cpuinfo_transition_latency``
- for each policy this governor is attached to (but since the unit here
- is greater by 1000, this means that the time represented by
- ``sampling_rate`` is 1000 times greater than the transition latency by
- default).
+ Typically, it is set to values of the order of 2000 (2 ms). Its
+ default value is to add a 50% breathing room
+ to ``cpuinfo_transition_latency`` on each policy this governor is
+ attached to. The minimum is typically the length of two scheduler
+ ticks.
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``
If the estimated CPU load is above this value (in percent), the governor
diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst
index 19754beb5a4e..be4c1120e3f0 100644
--- a/Documentation/admin-guide/pm/cpuidle.rst
+++ b/Documentation/admin-guide/pm/cpuidle.rst
@@ -269,61 +269,56 @@ Namely, when invoked to select an idle state for a CPU (i.e. an idle state that
the CPU will ask the processor hardware to enter), it attempts to predict the
idle duration and uses the predicted value for idle state selection.
-It first obtains the time until the closest timer event with the assumption
-that the scheduler tick will be stopped. That time, referred to as the *sleep
-length* in what follows, is the upper bound on the time before the next CPU
-wakeup. It is used to determine the sleep length range, which in turn is needed
-to get the sleep length correction factor.
-
-The ``menu`` governor maintains two arrays of sleep length correction factors.
-One of them is used when tasks previously running on the given CPU are waiting
-for some I/O operations to complete and the other one is used when that is not
-the case. Each array contains several correction factor values that correspond
-to different sleep length ranges organized so that each range represented in the
-array is approximately 10 times wider than the previous one.
-
-The correction factor for the given sleep length range (determined before
-selecting the idle state for the CPU) is updated after the CPU has been woken
-up and the closer the sleep length is to the observed idle duration, the closer
-to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
-The sleep length is multiplied by the correction factor for the range that it
-falls into to obtain the first approximation of the predicted idle duration.
-
-Next, the governor uses a simple pattern recognition algorithm to refine its
+It first uses a simple pattern recognition algorithm to obtain a preliminary
idle duration prediction. Namely, it saves the last 8 observed idle duration
values and, when predicting the idle duration next time, it computes the average
and variance of them. If the variance is small (smaller than 400 square
milliseconds) or it is small relative to the average (the average is greater
that 6 times the standard deviation), the average is regarded as the "typical
-interval" value. Otherwise, the longest of the saved observed idle duration
+interval" value. Otherwise, either the longest or the shortest (depending on
+which one is farther from the average) of the saved observed idle duration
values is discarded and the computation is repeated for the remaining ones.
+
Again, if the variance of them is small (in the above sense), the average is
taken as the "typical interval" value and so on, until either the "typical
-interval" is determined or too many data points are disregarded, in which case
-the "typical interval" is assumed to equal "infinity" (the maximum unsigned
-integer value). The "typical interval" computed this way is compared with the
-sleep length multiplied by the correction factor and the minimum of the two is
-taken as the predicted idle duration.
-
-Then, the governor computes an extra latency limit to help "interactive"
-workloads. It uses the observation that if the exit latency of the selected
-idle state is comparable with the predicted idle duration, the total time spent
-in that state probably will be very short and the amount of energy to save by
-entering it will be relatively small, so likely it is better to avoid the
-overhead related to entering that state and exiting it. Thus selecting a
-shallower state is likely to be a better option then. The first approximation
-of the extra latency limit is the predicted idle duration itself which
-additionally is divided by a value depending on the number of tasks that
-previously ran on the given CPU and now they are waiting for I/O operations to
-complete. The result of that division is compared with the latency limit coming
-from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
-framework and the minimum of the two is taken as the limit for the idle states'
-exit latency.
+interval" is determined or too many data points are disregarded. In the latter
+case, if the size of the set of data points still under consideration is
+sufficiently large, the next idle duration is not likely to be above the largest
+idle duration value still in that set, so that value is taken as the predicted
+next idle duration. Finally, if the set of data points still under
+consideration is too small, no prediction is made.
+
+If the preliminary prediction of the next idle duration computed this way is
+long enough, the governor obtains the time until the closest timer event with
+the assumption that the scheduler tick will be stopped. That time, referred to
+as the *sleep length* in what follows, is the upper bound on the time before the
+next CPU wakeup. It is used to determine the sleep length range, which in turn
+is needed to get the sleep length correction factor.
+
+The ``menu`` governor maintains an array containing several correction factor
+values that correspond to different sleep length ranges organized so that each
+range represented in the array is approximately 10 times wider than the previous
+one.
+
+The correction factor for the given sleep length range (determined before
+selecting the idle state for the CPU) is updated after the CPU has been woken
+up and the closer the sleep length is to the observed idle duration, the closer
+to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
+The sleep length is multiplied by the correction factor for the range that it
+falls into to obtain an approximation of the predicted idle duration that is
+compared to the "typical interval" determined previously and the minimum of
+the two is taken as the final idle duration prediction.
+
+If the "typical interval" value is small, which means that the CPU is likely
+to be woken up soon enough, the sleep length computation is skipped as it may
+be costly and the idle duration is simply predicted to equal the "typical
+interval" value.
Now, the governor is ready to walk the list of idle states and choose one of
them. For this purpose, it compares the target residency of each state with
-the predicted idle duration and the exit latency of it with the computed latency
-limit. It selects the state with the target residency closest to the predicted
+the predicted idle duration and the exit latency of it with the with the latency
+limit coming from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
+framework. It selects the state with the target residency closest to the predicted
idle duration, but still below it, and exit latency that does not exceed the
limit.
@@ -585,6 +580,15 @@ the given CPU as the upper limit for the exit latency of the idle states that
they are allowed to select for that CPU. They should never select any idle
states with exit latency beyond that limit.
+While the above CPU QoS constraints apply to CPU idle time management, user
+space may also request a CPU system wakeup latency QoS limit, via the
+`cpu_wakeup_latency` file. This QoS constraint is respected when selecting a
+suitable idle state for the CPUs, while entering the system-wide suspend-to-idle
+sleep state, but also to the regular CPU idle time management.
+
+Note that, the management of the `cpu_wakeup_latency` file works according to
+the 'cpu_dma_latency' file from user space point of view. Moreover, the unit
+is also microseconds.
Idle States Control Via Kernel Command Line
===========================================
diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst
index b799a43da62e..ed6f055d4b14 100644
--- a/Documentation/admin-guide/pm/intel_idle.rst
+++ b/Documentation/admin-guide/pm/intel_idle.rst
@@ -38,6 +38,27 @@ instruction at all.
only way to pass early-configuration-time parameters to it is via the kernel
command line.
+Sysfs Interface
+===============
+
+The ``intel_idle`` driver exposes the following ``sysfs`` attributes in
+``/sys/devices/system/cpu/cpuidle/``:
+
+``intel_c1_demotion``
+ Enable or disable C1 demotion for all CPUs in the system. This file is
+ only exposed on platforms that support the C1 demotion feature and where
+ it was tested. Value 0 means that C1 demotion is disabled, value 1 means
+ that it is enabled. Write 0 or 1 to disable or enable C1 demotion for
+ all CPUs.
+
+ The C1 demotion feature involves the platform firmware demoting deep
+ C-state requests from the OS (e.g., C6 requests) to C1. The idea is that
+ firmware monitors CPU wake-up rate, and if it is higher than a
+ platform-specific threshold, the firmware demotes deep C-state requests
+ to C1. For example, Linux requests C6, but firmware noticed too many
+ wake-ups per second, and it keeps the CPU in C1. When the CPU stays in
+ C1 long enough, the platform promotes it back to C6. This may improve
+ some workloads' performance, but it may also increase power consumption.
.. _intel-idle-enumeration-of-states:
@@ -170,7 +191,7 @@ and ``idle=nomwait``. If any of them is present in the kernel command line, the
``MWAIT`` instruction is not allowed to be used, so the initialization of
``intel_idle`` will fail.
-Apart from that there are four module parameters recognized by ``intel_idle``
+Apart from that there are five module parameters recognized by ``intel_idle``
itself that can be set via the kernel command line (they cannot be updated via
sysfs, so that is the only way to change their values).
@@ -192,11 +213,19 @@ even if they have been enumerated (see :ref:`cpu-pm-qos` in
Documentation/admin-guide/pm/cpuidle.rst).
Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail.
-The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle``
-if the kernel has been configured with ACPI support) can be set to make the
-driver ignore the system's ACPI tables entirely or use them for all of the
-recognized processor models, respectively (they both are unset by default and
-``use_acpi`` has no effect if ``no_acpi`` is set).
+The ``no_acpi``, ``use_acpi`` and ``no_native`` module parameters are
+recognized by ``intel_idle`` if the kernel has been configured with ACPI
+support. In the case that ACPI is not configured these flags have no impact
+on functionality.
+
+``no_acpi`` - Do not use ACPI at all. Only native mode is available, no
+ACPI mode.
+
+``use_acpi`` - No-op in ACPI mode, the driver will consult ACPI tables for
+C-states on/off status in native mode.
+
+``no_native`` - Work only in ACPI mode, no native mode available (ignore
+all custom tables).
The value of the ``states_off`` module parameter (0 by default) represents a
list of idle states to be disabled by default in the form of a bitmask.
@@ -216,6 +245,21 @@ are ignored).
The idle states disabled this way can be enabled (on a per-CPU basis) from user
space via ``sysfs``.
+The ``ibrs_off`` module parameter is a boolean flag (defaults to
+false). If set, it is used to control if IBRS (Indirect Branch Restricted
+Speculation) should be turned off when the CPU enters an idle state.
+This flag does not affect CPUs that use Enhanced IBRS which can remain
+on with little performance impact.
+
+For some CPUs, IBRS will be selected as mitigation for Spectre v2 and Retbleed
+security vulnerabilities by default. Leaving the IBRS mode on while idling may
+have a performance impact on its sibling CPU. The IBRS mode will be turned off
+by default when the CPU enters into a deep idle state, but not in some
+shallower ones. Setting the ``ibrs_off`` module parameter will force the IBRS
+mode to off when the CPU is in any one of the available idle states. This may
+help performance of a sibling CPU at the expense of a slightly higher wakeup
+latency for the idle CPU.
+
.. _intel-idle-core-and-package-idle-states:
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst
index d5043cd8d2f5..fde967b0c2e0 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -48,8 +48,9 @@ only way to pass early-configuration-time parameters to it is via the kernel
command line. However, its configuration can be adjusted via ``sysfs`` to a
great extent. In some configurations it even is possible to unregister it via
``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and
-registered (see `below <status_attr_>`_).
+registered (see :ref:`below <status_attr>`).
+.. _operation_modes:
Operation Modes
===============
@@ -62,6 +63,8 @@ a certain performance scaling algorithm. Which of them will be in effect
depends on what kernel command line options are used and on the capabilities of
the processor.
+.. _active_mode:
+
Active Mode
-----------
@@ -94,6 +97,8 @@ Which of the P-state selection algorithms is used by default depends on the
Namely, if that option is set, the ``performance`` algorithm will be used by
default, and the other one will be used by default if it is not set.
+.. _active_mode_hwp:
+
Active Mode With HWP
~~~~~~~~~~~~~~~~~~~~
@@ -123,7 +128,7 @@ Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's
internal P-state selection logic is expected to focus entirely on performance.
This will override the EPP/EPB setting coming from the ``sysfs`` interface
-(see `Energy vs Performance Hints`_ below). Moreover, any attempts to change
+(see :ref:`energy_performance_hints` below). Moreover, any attempts to change
the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in this
configuration will be rejected.
@@ -192,6 +197,8 @@ This is the default P-state selection algorithm if the
:c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration option
is not set.
+.. _passive_mode:
+
Passive Mode
------------
@@ -289,12 +296,12 @@ Unlike ``_PSS`` objects in the ACPI tables, ``intel_pstate`` always exposes
the entire range of available P-states, including the whole turbo range, to the
``CPUFreq`` core and (in the passive mode) to generic scaling governors. This
generally causes turbo P-states to be set more often when ``intel_pstate`` is
-used relative to ACPI-based CPU performance scaling (see `below <acpi-cpufreq_>`_
-for more information).
+used relative to ACPI-based CPU performance scaling (see
+:ref:`below <acpi-cpufreq>` for more information).
Moreover, since ``intel_pstate`` always knows what the real turbo threshold is
(even if the Configurable TDP feature is enabled in the processor), its
-``no_turbo`` attribute in ``sysfs`` (described `below <no_turbo_attr_>`_) should
+``no_turbo`` attribute in ``sysfs`` (described :ref:`below <no_turbo_attr>`) should
work as expected in all cases (that is, if set to disable turbo P-states, it
always should prevent ``intel_pstate`` from using them).
@@ -307,12 +314,12 @@ pieces of information on it to be known, including:
* The minimum supported P-state.
- * The maximum supported `non-turbo P-state <turbo_>`_.
+ * The maximum supported :ref:`non-turbo P-state <turbo>`.
* Whether or not turbo P-states are supported at all.
- * The maximum supported `one-core turbo P-state <turbo_>`_ (if turbo P-states
- are supported).
+ * The maximum supported :ref:`one-core turbo P-state <turbo>` (if turbo
+ P-states are supported).
* The scaling formula to translate the driver's internal representation
of P-states into frequencies and the other way around.
@@ -329,9 +336,111 @@ information listed above is the same for all of the processors supporting the
HWP feature, which is why ``intel_pstate`` works with all of them.]
+Support for Hybrid Processors
+=============================
+
+Some processors supported by ``intel_pstate`` contain two or more types of CPU
+cores differing by the maximum turbo P-state, performance vs power characteristics,
+cache sizes, and possibly other properties. They are commonly referred to as
+hybrid processors. To support them, ``intel_pstate`` requires HWP to be enabled
+and it assumes the HWP performance units to be the same for all CPUs in the
+system, so a given HWP performance level always represents approximately the
+same physical performance regardless of the core (CPU) type.
+
+Hybrid Processors with SMT
+--------------------------
+
+On systems where SMT (Simultaneous Multithreading), also referred to as
+HyperThreading (HT) in the context of Intel processors, is enabled on at least
+one core, ``intel_pstate`` assigns performance-based priorities to CPUs. Namely,
+the priority of a given CPU reflects its highest HWP performance level which
+causes the CPU scheduler to generally prefer more performant CPUs, so the less
+performant CPUs are used when the other ones are fully loaded. However, SMT
+siblings (that is, logical CPUs sharing one physical core) are treated in a
+special way such that if one of them is in use, the effective priority of the
+other ones is lowered below the priorities of the CPUs located in the other
+physical cores.
+
+This approach maximizes performance in the majority of cases, but unfortunately
+it also leads to excessive energy usage in some important scenarios, like video
+playback, which is not generally desirable. While there is no other viable
+choice with SMT enabled because the effective capacity and utilization of SMT
+siblings are hard to determine, hybrid processors without SMT can be handled in
+more energy-efficient ways.
+
+.. _CAS:
+
+Capacity-Aware Scheduling Support
+---------------------------------
+
+The capacity-aware scheduling (CAS) support in the CPU scheduler is enabled by
+``intel_pstate`` by default on hybrid processors without SMT. CAS generally
+causes the scheduler to put tasks on a CPU so long as there is a sufficient
+amount of spare capacity on it, and if the utilization of a given task is too
+high for it, the task will need to go somewhere else.
+
+Since CAS takes CPU capacities into account, it does not require CPU
+prioritization and it allows tasks to be distributed more symmetrically among
+the more performant and less performant CPUs. Once placed on a CPU with enough
+capacity to accommodate it, a task may just continue to run there regardless of
+whether or not the other CPUs are fully loaded, so on average CAS reduces the
+utilization of the more performant CPUs which causes the energy usage to be more
+balanced because the more performant CPUs are generally less energy-efficient
+than the less performant ones.
+
+In order to use CAS, the scheduler needs to know the capacity of each CPU in
+the system and it needs to be able to compute scale-invariant utilization of
+CPUs, so ``intel_pstate`` provides it with the requisite information.
+
+First of all, the capacity of each CPU is represented by the ratio of its highest
+HWP performance level, multiplied by 1024, to the highest HWP performance level
+of the most performant CPU in the system, which works because the HWP performance
+units are the same for all CPUs. Second, the frequency-invariance computations,
+carried out by the scheduler to always express CPU utilization in the same units
+regardless of the frequency it is currently running at, are adjusted to take the
+CPU capacity into account. All of this happens when ``intel_pstate`` has
+registered itself with the ``CPUFreq`` core and it has figured out that it is
+running on a hybrid processor without SMT.
+
+Energy-Aware Scheduling Support
+-------------------------------
+
+If ``CONFIG_ENERGY_MODEL`` has been set during kernel configuration and
+``intel_pstate`` runs on a hybrid processor without SMT, in addition to enabling
+:ref:`CAS` it registers an Energy Model for the processor. This allows the
+Energy-Aware Scheduling (EAS) support to be enabled in the CPU scheduler if
+``schedutil`` is used as the ``CPUFreq`` governor which requires ``intel_pstate``
+to operate in the :ref:`passive mode <passive_mode>`.
+
+The Energy Model registered by ``intel_pstate`` is artificial (that is, it is
+based on abstract cost values and it does not include any real power numbers)
+and it is relatively simple to avoid unnecessary computations in the scheduler.
+There is a performance domain in it for every CPU in the system and the cost
+values for these performance domains have been chosen so that running a task on
+a less performant (small) CPU appears to be always cheaper than running that
+task on a more performant (big) CPU. However, for two CPUs of the same type,
+the cost difference depends on their current utilization, and the CPU whose
+current utilization is higher generally appears to be a more expensive
+destination for a given task. This helps to balance the load among CPUs of the
+same type.
+
+Since EAS works on top of CAS, high-utilization tasks are always migrated to
+CPUs with enough capacity to accommodate them, but thanks to EAS, low-utilization
+tasks tend to be placed on the CPUs that look less expensive to the scheduler.
+Effectively, this causes the less performant and less loaded CPUs to be
+preferred as long as they have enough spare capacity to run the given task
+which generally leads to reduced energy usage.
+
+The Energy Model created by ``intel_pstate`` can be inspected by looking at
+the ``energy_model`` directory in ``debugfs`` (typlically mounted on
+``/sys/kernel/debug/``).
+
+
User Space Interface in ``sysfs``
=================================
+.. _global_attributes:
+
Global Attributes
-----------------
@@ -344,8 +453,8 @@ argument is passed to the kernel in the command line.
``max_perf_pct``
Maximum P-state the driver is allowed to set in percent of the
- maximum supported performance level (the highest supported `turbo
- P-state <turbo_>`_).
+ maximum supported performance level (the highest supported :ref:`turbo
+ P-state <turbo>`).
This attribute will not be exposed if the
``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
@@ -353,8 +462,8 @@ argument is passed to the kernel in the command line.
``min_perf_pct``
Minimum P-state the driver is allowed to set in percent of the
- maximum supported performance level (the highest supported `turbo
- P-state <turbo_>`_).
+ maximum supported performance level (the highest supported :ref:`turbo
+ P-state <turbo>`).
This attribute will not be exposed if the
``intel_pstate=per_cpu_perf_limits`` argument is present in the kernel
@@ -363,18 +472,18 @@ argument is passed to the kernel in the command line.
``num_pstates``
Number of P-states supported by the processor (between 0 and 255
inclusive) including both turbo and non-turbo P-states (see
- `Turbo P-states Support`_).
+ :ref:`turbo`).
This attribute is present only if the value exposed by it is the same
for all of the CPUs in the system.
The value of this attribute is not affected by the ``no_turbo``
- setting described `below <no_turbo_attr_>`_.
+ setting described :ref:`below <no_turbo_attr>`.
This attribute is read-only.
``turbo_pct``
- Ratio of the `turbo range <turbo_>`_ size to the size of the entire
+ Ratio of the :ref:`turbo range <turbo>` size to the size of the entire
range of supported P-states, in percent.
This attribute is present only if the value exposed by it is the same
@@ -386,7 +495,7 @@ argument is passed to the kernel in the command line.
``no_turbo``
If set (equal to 1), the driver is not allowed to set any turbo P-states
- (see `Turbo P-states Support`_). If unset (equal to 0, which is the
+ (see :ref:`turbo`). If unset (equal to 0, which is the
default), turbo P-states can be set by the driver.
[Note that ``intel_pstate`` does not support the general ``boost``
attribute (supported by some other scaling drivers) which is replaced
@@ -395,11 +504,11 @@ argument is passed to the kernel in the command line.
This attribute does not affect the maximum supported frequency value
supplied to the ``CPUFreq`` core and exposed via the policy interface,
but it affects the maximum possible value of per-policy P-state limits
- (see `Interpretation of Policy Attributes`_ below for details).
+ (see :ref:`policy_attributes_interpretation` below for details).
``hwp_dynamic_boost``
This attribute is only present if ``intel_pstate`` works in the
- `active mode with the HWP feature enabled <Active Mode With HWP_>`_ in
+ :ref:`active mode with the HWP feature enabled <active_mode_hwp>` in
the processor. If set (equal to 1), it causes the minimum P-state limit
to be increased dynamically for a short time whenever a task previously
waiting on I/O is selected to run on a given logical CPU (the purpose
@@ -414,12 +523,12 @@ argument is passed to the kernel in the command line.
Operation mode of the driver: "active", "passive" or "off".
"active"
- The driver is functional and in the `active mode
- <Active Mode_>`_.
+ The driver is functional and in the :ref:`active mode
+ <active_mode>`.
"passive"
- The driver is functional and in the `passive mode
- <Passive Mode_>`_.
+ The driver is functional and in the :ref:`passive mode
+ <passive_mode>`.
"off"
The driver is not functional (it is not registered as a scaling
@@ -447,13 +556,15 @@ argument is passed to the kernel in the command line.
attribute to "1" enables the energy-efficiency optimizations and setting
to "0" disables them.
+.. _policy_attributes_interpretation:
+
Interpretation of Policy Attributes
-----------------------------------
The interpretation of some ``CPUFreq`` policy attributes described in
Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate``
as the current scaling driver and it generally depends on the driver's
-`operation mode <Operation Modes_>`_.
+:ref:`operation mode <operation_modes>`.
First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
``scaling_cur_freq`` attributes are produced by applying a processor-specific
@@ -462,9 +573,10 @@ Also, the values of the ``scaling_max_freq`` and ``scaling_min_freq``
attributes are capped by the frequency corresponding to the maximum P-state that
the driver is allowed to set.
-If the ``no_turbo`` `global attribute <no_turbo_attr_>`_ is set, the driver is
-not allowed to use turbo P-states, so the maximum value of ``scaling_max_freq``
-and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequency.
+If the ``no_turbo`` :ref:`global attribute <no_turbo_attr>` is set, the driver
+is not allowed to use turbo P-states, so the maximum value of
+``scaling_max_freq`` and ``scaling_min_freq`` is limited to the maximum
+non-turbo P-state frequency.
Accordingly, setting ``no_turbo`` causes ``scaling_max_freq`` and
``scaling_min_freq`` to go down to that value if they were above it before.
However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` will be
@@ -476,7 +588,7 @@ and ``scaling_min_freq`` corresponds to the maximum supported turbo P-state,
which also is the value of ``cpuinfo_max_freq`` in either case.
Next, the following policy attributes have special meaning if
-``intel_pstate`` works in the `active mode <Active Mode_>`_:
+``intel_pstate`` works in the :ref:`active mode <active_mode>`:
``scaling_available_governors``
List of P-state selection algorithms provided by ``intel_pstate``.
@@ -497,20 +609,22 @@ processor:
Shows the base frequency of the CPU. Any frequency above this will be
in the turbo frequency range.
-The meaning of these attributes in the `passive mode <Passive Mode_>`_ is the
+The meaning of these attributes in the :ref:`passive mode <passive_mode>` is the
same as for other scaling drivers.
Additionally, the value of the ``scaling_driver`` attribute for ``intel_pstate``
depends on the operation mode of the driver. Namely, it is either
-"intel_pstate" (in the `active mode <Active Mode_>`_) or "intel_cpufreq" (in the
-`passive mode <Passive Mode_>`_).
+"intel_pstate" (in the :ref:`active mode <active_mode>`) or "intel_cpufreq"
+(in the :ref:`passive mode <passive_mode>`).
+
+.. _pstate_limits_coordination:
Coordination of P-State Limits
------------------------------
``intel_pstate`` allows P-state limits to be set in two ways: with the help of
-the ``max_perf_pct`` and ``min_perf_pct`` `global attributes
-<Global Attributes_>`_ or via the ``scaling_max_freq`` and ``scaling_min_freq``
+the ``max_perf_pct`` and ``min_perf_pct`` :ref:`global attributes
+<global_attributes>` or via the ``scaling_max_freq`` and ``scaling_min_freq``
``CPUFreq`` policy attributes. The coordination between those limits is based
on the following rules, regardless of the current operation mode of the driver:
@@ -532,17 +646,18 @@ on the following rules, regardless of the current operation mode of the driver:
3. The global and per-policy limits can be set independently.
-In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the
+In the :ref:`active mode with the HWP feature enabled <active_mode_hwp>`, the
resulting effective values are written into hardware registers whenever the
limits change in order to request its internal P-state selection logic to always
set P-states within these limits. Otherwise, the limits are taken into account
-by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
-every time before setting a new P-state for a CPU.
+by scaling governors (in the :ref:`passive mode <passive_mode>`) and by the
+driver every time before setting a new P-state for a CPU.
Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exposed
at all and the only way to set the limits is by using the policy attributes.
+.. _energy_performance_hints:
Energy vs Performance Hints
---------------------------
@@ -602,9 +717,9 @@ output.
On those systems each ``_PSS`` object returns a list of P-states supported by
the corresponding CPU which basically is a subset of the P-states range that can
be used by ``intel_pstate`` on the same system, with one exception: the whole
-`turbo range <turbo_>`_ is represented by one item in it (the topmost one). By
-convention, the frequency returned by ``_PSS`` for that item is greater by 1 MHz
-than the frequency of the highest non-turbo P-state listed by it, but the
+:ref:`turbo range <turbo>` is represented by one item in it (the topmost one).
+By convention, the frequency returned by ``_PSS`` for that item is greater by
+1 MHz than the frequency of the highest non-turbo P-state listed by it, but the
corresponding P-state representation (following the hardware specification)
returned for it matches the maximum supported turbo P-state (or is the
special value 255 meaning essentially "go as high as you can get").
@@ -630,18 +745,18 @@ benefit from running at turbo frequencies will be given non-turbo P-states
instead.
One more issue related to that may appear on systems supporting the
-`Configurable TDP feature <turbo_>`_ allowing the platform firmware to set the
-turbo threshold. Namely, if that is not coordinated with the lists of P-states
-returned by ``_PSS`` properly, there may be more than one item corresponding to
-a turbo P-state in those lists and there may be a problem with avoiding the
-turbo range (if desirable or necessary). Usually, to avoid using turbo
-P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state listed
-by ``_PSS``, but that is not sufficient when there are other turbo P-states in
-the list returned by it.
+:ref:`Configurable TDP feature <turbo>` allowing the platform firmware to set
+the turbo threshold. Namely, if that is not coordinated with the lists of
+P-states returned by ``_PSS`` properly, there may be more than one item
+corresponding to a turbo P-state in those lists and there may be a problem with
+avoiding the turbo range (if desirable or necessary). Usually, to avoid using
+turbo P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state
+listed by ``_PSS``, but that is not sufficient when there are other turbo
+P-states in the list returned by it.
Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the
-`passive mode <Passive Mode_>`_, except that the number of P-states it can set
-is limited to the ones listed by the ACPI ``_PSS`` objects.
+:ref:`passive mode <passive_mode>`, except that the number of P-states it can
+set is limited to the ones listed by the ACPI ``_PSS`` objects.
Kernel Command Line Options for ``intel_pstate``
@@ -656,11 +771,11 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
processor is supported by it.
``active``
- Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start
- with.
+ Register ``intel_pstate`` in the :ref:`active mode <active_mode>` to
+ start with.
``passive``
- Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
+ Register ``intel_pstate`` in the :ref:`passive mode <passive_mode>` to
start with.
``force``
@@ -693,9 +808,12 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
and this option has no effect.
``per_cpu_perf_limits``
- Use per-logical-CPU P-State limits (see `Coordination of P-state
- Limits`_ for details).
+ Use per-logical-CPU P-State limits (see
+ :ref:`pstate_limits_coordination` for details).
+``no_cas``
+ Do not enable :ref:`capacity-aware scheduling <CAS>` which is enabled
+ by default on hybrid systems without SMT.
Diagnostics and Tuning
======================
@@ -707,19 +825,19 @@ There are two static trace events that can be used for ``intel_pstate``
diagnostics. One of them is the ``cpu_frequency`` trace event generally used
by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific
to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if
-it works in the `active mode <Active Mode_>`_.
+it works in the :ref:`active mode <active_mode>`.
The following sequence of shell commands can be used to enable them and see
their output (if the kernel is generally configured to support event tracing)::
- # cd /sys/kernel/debug/tracing/
+ # cd /sys/kernel/tracing/
# echo 1 > events/power/pstate_sample/enable
# echo 1 > events/power/cpu_frequency/enable
# cat trace
gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107 scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618 freq=2474476
cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
-If ``intel_pstate`` works in the `passive mode <Passive Mode_>`_, the
+If ``intel_pstate`` works in the :ref:`passive mode <passive_mode>`, the
``cpu_frequency`` trace event will be triggered either by the ``schedutil``
scaling governor (for the policies it is attached to), or by the ``CPUFreq``
core (for the policies with other scaling governors).
@@ -732,7 +850,7 @@ The ``ftrace`` interface can be used for low-level diagnostics of
P-state is called, the ``ftrace`` filter can be set to
:c:func:`intel_pstate_set_pstate`::
- # cd /sys/kernel/debug/tracing/
+ # cd /sys/kernel/tracing/
# cat available_filter_functions | grep -i pstate
intel_pstate_set_pstate
intel_pstate_cpu_init
diff --git a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
index 09169d935835..d367ba4d744a 100644
--- a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
+++ b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
@@ -5,7 +5,7 @@
Intel Uncore Frequency Scaling
==============================
-:Copyright: |copy| 2022 Intel Corporation
+:Copyright: |copy| 2022-2023 Intel Corporation
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
@@ -58,3 +58,127 @@ Each package_*_die_* contains the following attributes:
``current_freq_khz``
This attribute is used to get the current uncore frequency.
+
+SoCs with TPMI (Topology Aware Register and PM Capsule Interface)
+-----------------------------------------------------------------
+
+An SoC can contain multiple power domains with individual or collection
+of mesh partitions. This partition is called fabric cluster.
+
+Certain type of meshes will need to run at the same frequency, they will
+be placed in the same fabric cluster. Benefit of fabric cluster is that it
+offers a scalable mechanism to deal with partitioned fabrics in a SoC.
+
+The current sysfs interface supports controls at package and die level.
+This interface is not enough to support more granular control at
+fabric cluster level.
+
+SoCs with the support of TPMI (Topology Aware Register and PM Capsule
+Interface), can have multiple power domains. Each power domain can
+contain one or more fabric clusters.
+
+To represent controls at fabric cluster level in addition to the
+controls at package and die level (like systems without TPMI
+support), sysfs is enhanced. This granular interface is presented in the
+sysfs with directories names prefixed with "uncore". For example:
+uncore00, uncore01 etc.
+
+The scope of control is specified by attributes "package_id", "domain_id"
+and "fabric_cluster_id" in the directory.
+
+Attributes in each directory:
+
+``domain_id``
+ This attribute is used to get the power domain id of this instance.
+
+``die_id``
+ This attribute is used to get the Linux die id of this instance.
+ This attribute is only present for domains with core agents and
+ when the CPUID leaf 0x1f presents die ID.
+
+``fabric_cluster_id``
+ This attribute is used to get the fabric cluster id of this instance.
+
+``package_id``
+ This attribute is used to get the package id of this instance.
+
+``agent_types``
+ This attribute displays all the hardware agents present within the
+ domain. Each agent has the capability to control one or more hardware
+ subsystems, which include: core, cache, memory, and I/O.
+
+The other attributes are same as presented at package_*_die_* level.
+
+In most of current use cases, the "max_freq_khz" and "min_freq_khz"
+is updated at "package_*_die_*" level. This model will be still supported
+with the following approach:
+
+When user uses controls at "package_*_die_*" level, then every fabric
+cluster is affected in that package and die. For example: user changes
+"max_freq_khz" in the package_00_die_00, then "max_freq_khz" for uncore*
+directory with the same package id will be updated. In this case user can
+still update "max_freq_khz" at each uncore* level, which is more restrictive.
+Similarly, user can update "min_freq_khz" at "package_*_die_*" level
+to apply at each uncore* level.
+
+Support for "current_freq_khz" is available only at each fabric cluster
+level (i.e., in uncore* directory).
+
+Efficiency vs. Latency Tradeoff
+-------------------------------
+
+The Efficiency Latency Control (ELC) feature improves performance
+per watt. With this feature hardware power management algorithms
+optimize trade-off between latency and power consumption. For some
+latency sensitive workloads further tuning can be done by SW to
+get desired performance.
+
+The hardware monitors the average CPU utilization across all cores
+in a power domain at regular intervals and decides an uncore frequency.
+While this may result in the best performance per watt, workload may be
+expecting higher performance at the expense of power. Consider an
+application that intermittently wakes up to perform memory reads on an
+otherwise idle system. In such cases, if hardware lowers uncore
+frequency, then there may be delay in ramp up of frequency to meet
+target performance.
+
+The ELC control defines some parameters which can be changed from SW.
+If the average CPU utilization is below a user-defined threshold
+(elc_low_threshold_percent attribute below), the user-defined uncore
+floor frequency will be used (elc_floor_freq_khz attribute below)
+instead of hardware calculated minimum.
+
+Similarly in high load scenario where the CPU utilization goes above
+the high threshold value (elc_high_threshold_percent attribute below)
+instead of jumping to maximum uncore frequency, frequency is increased
+in 100MHz steps. This avoids consuming unnecessarily high power
+immediately with CPU utilization spikes.
+
+Attributes for efficiency latency control:
+
+``elc_floor_freq_khz``
+ This attribute is used to get/set the efficiency latency floor frequency.
+ If this variable is lower than the 'min_freq_khz', it is ignored by
+ the firmware.
+
+``elc_low_threshold_percent``
+ This attribute is used to get/set the efficiency latency control low
+ threshold. This attribute is in percentages of CPU utilization.
+
+``elc_high_threshold_percent``
+ This attribute is used to get/set the efficiency latency control high
+ threshold. This attribute is in percentages of CPU utilization.
+
+``elc_high_threshold_enable``
+ This attribute is used to enable/disable the efficiency latency control
+ high threshold. Write '1' to enable, '0' to disable.
+
+Example system configuration below, which does following:
+ * when CPU utilization is less than 10%: sets uncore frequency to 800MHz
+ * when CPU utilization is higher than 95%: increases uncore frequency in
+ 100MHz steps, until power limit is reached
+
+ elc_floor_freq_khz:800000
+ elc_high_threshold_percent:95
+ elc_high_threshold_enable:1
+ elc_low_threshold_percent:10
diff --git a/Documentation/admin-guide/pnp.rst b/Documentation/admin-guide/pnp.rst
index 3eda08191d13..24d80e3eb309 100644
--- a/Documentation/admin-guide/pnp.rst
+++ b/Documentation/admin-guide/pnp.rst
@@ -129,9 +129,6 @@ pnp_put_protocol
pnp_register_protocol
use this to register a new PnP protocol
-pnp_unregister_protocol
- use this function to remove a PnP protocol from the Plug and Play Layer
-
pnp_register_driver
adds a PnP driver to the Plug and Play Layer
diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst
index 2d22ead9520e..1bb2a1c292aa 100644
--- a/Documentation/admin-guide/pstore-blk.rst
+++ b/Documentation/admin-guide/pstore-blk.rst
@@ -76,7 +76,7 @@ kmsg_size
~~~~~~~~~
The chunk size in KB for oops/panic front-end. It **MUST** be a multiple of 4.
-It's optional if you do not care oops/panic log.
+It's optional if you do not care about the oops/panic log.
There are multiple chunks for oops/panic front-end depending on the remaining
space except other pstore front-ends.
@@ -88,7 +88,7 @@ pmsg_size
~~~~~~~~~
The chunk size in KB for pmsg front-end. It **MUST** be a multiple of 4.
-It's optional if you do not care pmsg log.
+It's optional if you do not care about the pmsg log.
Unlike oops/panic front-end, there is only one chunk for pmsg front-end.
@@ -100,7 +100,7 @@ console_size
~~~~~~~~~~~~
The chunk size in KB for console front-end. It **MUST** be a multiple of 4.
-It's optional if you do not care console log.
+It's optional if you do not care about the console log.
Similar to pmsg front-end, there is only one chunk for console front-end.
@@ -111,7 +111,7 @@ ftrace_size
~~~~~~~~~~~
The chunk size in KB for ftrace front-end. It **MUST** be a multiple of 4.
-It's optional if you do not care console log.
+It's optional if you do not care about the ftrace log.
Similar to oops front-end, there are multiple chunks for ftrace front-end
depending on the count of cpu processors. Each chunk size is equal to
diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
new file mode 100644
index 000000000000..cb4b78468a93
--- /dev/null
+++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
@@ -0,0 +1,1097 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. [see the bottom of this file for redistribution information]
+
+===========================================
+How to quickly build a trimmed Linux kernel
+===========================================
+
+This guide explains how to swiftly build Linux kernels that are ideal for
+testing purposes, but perfectly fine for day-to-day use, too.
+
+The essence of the process (aka 'TL;DR')
+========================================
+
+*[If you are new to compiling Linux, ignore this TLDR and head over to the next
+section below: it contains a step-by-step guide, which is more detailed, but
+still brief and easy to follow; that guide and its accompanying reference
+section also mention alternatives, pitfalls, and additional aspects, all of
+which might be relevant for you.]*
+
+If your system uses techniques like Secure Boot, prepare it to permit starting
+self-compiled Linux kernels; install compilers and everything else needed for
+building Linux; make sure to have 12 Gigabyte free space in your home directory.
+Now run the following commands to download fresh Linux mainline sources, which
+you then use to configure, build and install your own kernel::
+
+ git clone --depth 1 -b master \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/
+ cd ~/linux/
+ # Hint: if you want to apply patches, do it at this point. See below for details.
+ # Hint: it's recommended to tag your build at this point. See below for details.
+ yes "" | make localmodconfig
+ # Hint: at this point you might want to adjust the build configuration; you'll
+ # have to, if you are running Debian. See below for details.
+ make -j $(nproc --all)
+ # Note: on many commodity distributions the next command suffices, but on Arch
+ # Linux, its derivatives, and some others it does not. See below for details.
+ command -v installkernel && sudo make modules_install install
+ reboot
+
+If you later want to build a newer mainline snapshot, use these commands::
+
+ cd ~/linux/
+ git fetch --depth 1 origin
+ # Note: the next command will discard any changes you did to the code:
+ git checkout --force --detach origin/master
+ # Reminder: if you want to (re)apply patches, do it at this point.
+ # Reminder: you might want to add or modify a build tag at this point.
+ make olddefconfig
+ make -j $(nproc --all)
+ # Reminder: the next command on some distributions does not suffice.
+ command -v installkernel && sudo make modules_install install
+ reboot
+
+Step-by-step guide
+==================
+
+Compiling your own Linux kernel is easy in principle. There are various ways to
+do it. Which of them actually work and is the best depends on the circumstances.
+
+This guide describes a way perfectly suited for those who want to quickly
+install Linux from sources without being bothered by complicated details; the
+goal is to cover everything typically needed on mainstream Linux distributions
+running on commodity PC or server hardware.
+
+The described approach is great for testing purposes, for example to try a
+proposed fix or to check if a problem was already fixed in the latest codebase.
+Nonetheless, kernels built this way are also totally fine for day-to-day use
+while at the same time being easy to keep up to date.
+
+The following steps describe the important aspects of the process; a
+comprehensive reference section later explains each of them in more detail. It
+sometimes also describes alternative approaches, pitfalls, as well as errors
+that might occur at a particular point -- and how to then get things rolling
+again.
+
+..
+ Note: if you see this note, you are reading the text's source file. You
+ might want to switch to a rendered version, as it makes it a lot easier to
+ quickly look something up in the reference section and afterwards jump back
+ to where you left off. Find a the latest rendered version here:
+ https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html
+
+.. _backup_sbs:
+
+ * Create a fresh backup and put system repair and restore tools at hand, just
+ to be prepared for the unlikely case of something going sideways.
+
+ [:ref:`details<backup>`]
+
+.. _secureboot_sbs:
+
+ * On platforms with 'Secure Boot' or similar techniques, prepare everything to
+ ensure the system will permit your self-compiled kernel to boot later. The
+ quickest and easiest way to achieve this on commodity x86 systems is to
+ disable such techniques in the BIOS setup utility; alternatively, remove
+ their restrictions through a process initiated by
+ ``mokutil --disable-validation``.
+
+ [:ref:`details<secureboot>`]
+
+.. _buildrequires_sbs:
+
+ * Install all software required to build a Linux kernel. Often you will need:
+ 'bc', 'binutils' ('ld' et al.), 'bison', 'flex', 'gcc', 'git', 'openssl',
+ 'pahole', 'perl', and the development headers for 'libelf' and 'openssl'. The
+ reference section shows how to quickly install those on various popular Linux
+ distributions.
+
+ [:ref:`details<buildrequires>`]
+
+.. _diskspace_sbs:
+
+ * Ensure to have enough free space for building and installing Linux. For the
+ latter 150 Megabyte in /lib/ and 100 in /boot/ are a safe bet. For storing
+ sources and build artifacts 12 Gigabyte in your home directory should
+ typically suffice. If you have less available, be sure to check the reference
+ section for the step that explains adjusting your kernels build
+ configuration: it mentions a trick that reduce the amount of required space
+ in /home/ to around 4 Gigabyte.
+
+ [:ref:`details<diskspace>`]
+
+.. _sources_sbs:
+
+ * Retrieve the sources of the Linux version you intend to build; then change
+ into the directory holding them, as all further commands in this guide are
+ meant to be executed from there.
+
+ *[Note: the following paragraphs describe how to retrieve the sources by
+ partially cloning the Linux stable git repository. This is called a shallow
+ clone. The reference section explains two alternatives:* :ref:`packaged
+ archives<sources_archive>` *and* :ref:`a full git clone<sources_full>` *;
+ prefer the latter, if downloading a lot of data does not bother you, as that
+ will avoid some* :ref:`peculiar characteristics of shallow clones the
+ reference section explains<sources_shallow>` *.]*
+
+ First, execute the following command to retrieve a fresh mainline codebase::
+
+ git clone --no-checkout --depth 1 -b master \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/
+ cd ~/linux/
+
+ If you want to access recent mainline releases and pre-releases, deepen you
+ clone's history to the oldest mainline version you are interested in::
+
+ git fetch --shallow-exclude=v6.0 origin
+
+ In case you want to access a stable/longterm release (say v6.1.5), simply add
+ the branch holding that series; afterwards fetch the history at least up to
+ the mainline version that started the series (v6.1)::
+
+ git remote set-branches --add origin linux-6.1.y
+ git fetch --shallow-exclude=v6.0 origin
+
+ Now checkout the code you are interested in. If you just performed the
+ initial clone, you will be able to check out a fresh mainline codebase, which
+ is ideal for checking whether developers already fixed an issue::
+
+ git checkout --detach origin/master
+
+ If you deepened your clone, you instead of ``origin/master`` can specify the
+ version you deepened to (``v6.0`` above); later releases like ``v6.1`` and
+ pre-release like ``v6.2-rc1`` will work, too. Stable or longterm versions
+ like ``v6.1.5`` work just the same, if you added the appropriate
+ stable/longterm branch as described.
+
+ [:ref:`details<sources>`]
+
+.. _patching_sbs:
+
+ * In case you want to apply a kernel patch, do so now. Often a command like
+ this will do the trick::
+
+ patch -p1 < ../proposed-fix.patch
+
+ If the ``-p1`` is actually needed, depends on how the patch was created; in
+ case it does not apply thus try without it.
+
+ If you cloned the sources with git and anything goes sideways, run ``git
+ reset --hard`` to undo any changes to the sources.
+
+ [:ref:`details<patching>`]
+
+.. _tagging_sbs:
+
+ * If you patched your kernel or have one of the same version installed already,
+ better add a unique tag to the one you are about to build::
+
+ echo "-proposed_fix" > localversion
+
+ Running ``uname -r`` under your kernel later will then print something like
+ '6.1-rc4-proposed_fix'.
+
+ [:ref:`details<tagging>`]
+
+ .. _configuration_sbs:
+
+ * Create the build configuration for your kernel based on an existing
+ configuration.
+
+ If you already prepared such a '.config' file yourself, copy it to
+ ~/linux/ and run ``make olddefconfig``.
+
+ Use the same command, if your distribution or somebody else already tailored
+ your running kernel to your or your hardware's needs: the make target
+ 'olddefconfig' will then try to use that kernel's .config as base.
+
+ Using this make target is fine for everybody else, too -- but you often can
+ save a lot of time by using this command instead::
+
+ yes "" | make localmodconfig
+
+ This will try to pick your distribution's kernel as base, but then disable
+ modules for any features apparently superfluous for your setup. This will
+ reduce the compile time enormously, especially if you are running an
+ universal kernel from a commodity Linux distribution.
+
+ There is a catch: 'localmodconfig' is likely to disable kernel features you
+ did not use since you booted your Linux -- like drivers for currently
+ disconnected peripherals or a virtualization software not haven't used yet.
+ You can reduce or nearly eliminate that risk with tricks the reference
+ section outlines; but when building a kernel just for quick testing purposes
+ it is often negligible if such features are missing. But you should keep that
+ aspect in mind when using a kernel built with this make target, as it might
+ be the reason why something you only use occasionally stopped working.
+
+ [:ref:`details<configuration>`]
+
+.. _configmods_sbs:
+
+ * Check if you might want to or have to adjust some kernel configuration
+ options:
+
+ * Evaluate how you want to handle debug symbols. Enable them, if you later
+ might need to decode a stack trace found for example in a 'panic', 'Oops',
+ 'warning', or 'BUG'; on the other hand disable them, if you are short on
+ storage space or prefer a smaller kernel binary. See the reference section
+ for details on how to do either. If neither applies, it will likely be fine
+ to simply not bother with this. [:ref:`details<configmods_debugsymbols>`]
+
+ * Are you running Debian? Then to avoid known problems by performing
+ additional adjustments explained in the reference section.
+ [:ref:`details<configmods_distros>`].
+
+ * If you want to influence the other aspects of the configuration, do so now
+ by using make targets like 'menuconfig' or 'xconfig'.
+ [:ref:`details<configmods_individual>`].
+
+.. _build_sbs:
+
+ * Build the image and the modules of your kernel::
+
+ make -j $(nproc --all)
+
+ If you want your kernel packaged up as deb, rpm, or tar file, see the
+ reference section for alternatives.
+
+ [:ref:`details<build>`]
+
+.. _install_sbs:
+
+ * Now install your kernel::
+
+ command -v installkernel && sudo make modules_install install
+
+ Often all left for you to do afterwards is a ``reboot``, as many commodity
+ Linux distributions will then create an initramfs (also known as initrd) and
+ an entry for your kernel in your bootloader's configuration; but on some
+ distributions you have to take care of these two steps manually for reasons
+ the reference section explains.
+
+ On a few distributions like Arch Linux and its derivatives the above command
+ does nothing at all; in that case you have to manually install your kernel,
+ as outlined in the reference section.
+
+ If you are running an immutable Linux distribution, check its documentation
+ and the web to find out how to install your own kernel there.
+
+ [:ref:`details<install>`]
+
+.. _another_sbs:
+
+ * To later build another kernel you need similar steps, but sometimes slightly
+ different commands.
+
+ First, switch back into the sources tree::
+
+ cd ~/linux/
+
+ In case you want to build a version from a stable/longterm series you have
+ not used yet (say 6.2.y), tell git to track it::
+
+ git remote set-branches --add origin linux-6.2.y
+
+ Now fetch the latest upstream changes; you again need to specify the earliest
+ version you care about, as git otherwise might retrieve the entire commit
+ history::
+
+ git fetch --shallow-exclude=v6.0 origin
+
+ Now switch to the version you are interested in -- but be aware the command
+ used here will discard any modifications you performed, as they would
+ conflict with the sources you want to checkout::
+
+ git checkout --force --detach origin/master
+
+ At this point you might want to patch the sources again or set/modify a build
+ tag, as explained earlier. Afterwards adjust the build configuration to the
+ new codebase using olddefconfig, which will now adjust the configuration file
+ you prepared earlier using localmodconfig (~/linux/.config) for your next
+ kernel::
+
+ # reminder: if you want to apply patches, do it at this point
+ # reminder: you might want to update your build tag at this point
+ make olddefconfig
+
+ Now build your kernel::
+
+ make -j $(nproc --all)
+
+ Afterwards install the kernel as outlined above::
+
+ command -v installkernel && sudo make modules_install install
+
+ [:ref:`details<another>`]
+
+.. _uninstall_sbs:
+
+ * Your kernel is easy to remove later, as its parts are only stored in two
+ places and clearly identifiable by the kernel's release name. Just ensure to
+ not delete the kernel you are running, as that might render your system
+ unbootable.
+
+ Start by deleting the directory holding your kernel's modules, which is named
+ after its release name -- '6.0.1-foobar' in the following example::
+
+ sudo rm -rf /lib/modules/6.0.1-foobar
+
+ Now try the following command, which on some distributions will delete all
+ other kernel files installed while also removing the kernel's entry from the
+ bootloader configuration::
+
+ command -v kernel-install && sudo kernel-install -v remove 6.0.1-foobar
+
+ If that command does not output anything or fails, see the reference section;
+ do the same if any files named '*6.0.1-foobar*' remain in /boot/.
+
+ [:ref:`details<uninstall>`]
+
+.. _submit_improvements_qbtl:
+
+Did you run into trouble following any of the above steps that is not cleared up
+by the reference section below? Or do you have ideas how to improve the text?
+Then please take a moment of your time and let the maintainer of this document
+know by email (Thorsten Leemhuis <linux@leemhuis.info>), ideally while CCing the
+Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is vital to
+improve this document further, which is in everybody's interest, as it will
+enable more people to master the task described here.
+
+Reference section for the step-by-step guide
+============================================
+
+This section holds additional information for each of the steps in the above
+guide.
+
+.. _backup:
+
+Prepare for emergencies
+-----------------------
+
+ *Create a fresh backup and put system repair and restore tools at hand*
+ [:ref:`... <backup_sbs>`]
+
+Remember, you are dealing with computers, which sometimes do unexpected things
+-- especially if you fiddle with crucial parts like the kernel of an operating
+system. That's what you are about to do in this process. Hence, better prepare
+for something going sideways, even if that should not happen.
+
+[:ref:`back to step-by-step guide <backup_sbs>`]
+
+.. _secureboot:
+
+Dealing with techniques like Secure Boot
+----------------------------------------
+
+ *On platforms with 'Secure Boot' or similar techniques, prepare everything to
+ ensure the system will permit your self-compiled kernel to boot later.*
+ [:ref:`... <secureboot_sbs>`]
+
+Many modern systems allow only certain operating systems to start; they thus by
+default will reject booting self-compiled kernels.
+
+You ideally deal with this by making your platform trust your self-built kernels
+with the help of a certificate and signing. How to do that is not described
+here, as it requires various steps that would take the text too far away from
+its purpose; 'Documentation/admin-guide/module-signing.rst' and various web
+sides already explain this in more detail.
+
+Temporarily disabling solutions like Secure Boot is another way to make your own
+Linux boot. On commodity x86 systems it is possible to do this in the BIOS Setup
+utility; the steps to do so are not described here, as they greatly vary between
+machines.
+
+On mainstream x86 Linux distributions there is a third and universal option:
+disable all Secure Boot restrictions for your Linux environment. You can
+initiate this process by running ``mokutil --disable-validation``; this will
+tell you to create a one-time password, which is safe to write down. Now
+restart; right after your BIOS performed all self-tests the bootloader Shim will
+show a blue box with a message 'Press any key to perform MOK management'. Hit
+some key before the countdown exposes. This will open a menu and choose 'Change
+Secure Boot state' there. Shim's 'MokManager' will now ask you to enter three
+randomly chosen characters from the one-time password specified earlier. Once
+you provided them, confirm that you really want to disable the validation.
+Afterwards, permit MokManager to reboot the machine.
+
+[:ref:`back to step-by-step guide <secureboot_sbs>`]
+
+.. _buildrequires:
+
+Install build requirements
+--------------------------
+
+ *Install all software required to build a Linux kernel.*
+ [:ref:`...<buildrequires_sbs>`]
+
+The kernel is pretty stand-alone, but besides tools like the compiler you will
+sometimes need a few libraries to build one. How to install everything needed
+depends on your Linux distribution and the configuration of the kernel you are
+about to build.
+
+Here are a few examples what you typically need on some mainstream
+distributions:
+
+ * Debian, Ubuntu, and derivatives::
+
+ sudo apt install bc binutils bison dwarves flex gcc git make openssl \
+ pahole perl-base libssl-dev libelf-dev
+
+ * Fedora and derivatives::
+
+ sudo dnf install binutils /usr/include/{libelf.h,openssl/pkcs7.h} \
+ /usr/bin/{bc,bison,flex,gcc,git,openssl,make,perl,pahole}
+
+ * openSUSE and derivatives::
+
+ sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \
+ openssl openssl-devel libelf-dev
+
+In case you wonder why these lists include openssl and its development headers:
+they are needed for the Secure Boot support, which many distributions enable in
+their kernel configuration for x86 machines.
+
+Sometimes you will need tools for compression formats like bzip2, gzip, lz4,
+lzma, lzo, xz, or zstd as well.
+
+You might need additional libraries and their development headers in case you
+perform tasks not covered in this guide. For example, zlib will be needed when
+building kernel tools from the tools/ directory; adjusting the build
+configuration with make targets like 'menuconfig' or 'xconfig' will require
+development headers for ncurses or Qt5.
+
+[:ref:`back to step-by-step guide <buildrequires_sbs>`]
+
+.. _diskspace:
+
+Space requirements
+------------------
+
+ *Ensure to have enough free space for building and installing Linux.*
+ [:ref:`... <diskspace_sbs>`]
+
+The numbers mentioned are rough estimates with a big extra charge to be on the
+safe side, so often you will need less.
+
+If you have space constraints, remember to read the reference section when you
+reach the :ref:`section about configuration adjustments' <configmods>`, as
+ensuring debug symbols are disabled will reduce the consumed disk space by quite
+a few gigabytes.
+
+[:ref:`back to step-by-step guide <diskspace_sbs>`]
+
+
+.. _sources:
+
+Download the sources
+--------------------
+
+ *Retrieve the sources of the Linux version you intend to build.*
+ [:ref:`...<sources_sbs>`]
+
+The step-by-step guide outlines how to retrieve Linux' sources using a shallow
+git clone. There is :ref:`more to tell about this method<sources_shallow>` and
+two alternate ways worth describing: :ref:`packaged archives<sources_archive>`
+and :ref:`a full git clone<sources_full>`. And the aspects ':ref:`wouldn't it
+be wiser to use a proper pre-release than the latest mainline code
+<sources_snapshot>`' and ':ref:`how to get an even fresher mainline codebase
+<sources_fresher>`' need elaboration, too.
+
+Note, to keep things simple the commands used in this guide store the build
+artifacts in the source tree. If you prefer to separate them, simply add
+something like ``O=~/linux-builddir/`` to all make calls; also adjust the path
+in all commands that add files or modify any generated (like your '.config').
+
+[:ref:`back to step-by-step guide <sources_sbs>`]
+
+.. _sources_shallow:
+
+Noteworthy characteristics of shallow clones
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The step-by-step guide uses a shallow clone, as it is the best solution for most
+of this document's target audience. There are a few aspects of this approach
+worth mentioning:
+
+ * This document in most places uses ``git fetch`` with ``--shallow-exclude=``
+ to specify the earliest version you care about (or to be precise: its git
+ tag). You alternatively can use the parameter ``--shallow-since=`` to specify
+ an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
+ define the depth of the history you want to download. As a second
+ alternative, you can also specify a certain depth explicitly with a parameter
+ like ``--depth=1``, unless you add branches for stable/longterm kernels.
+
+ * When running ``git fetch``, remember to always specify the oldest version,
+ the time you care about, or an explicit depth as shown in the step-by-step
+ guide. Otherwise you will risk downloading nearly the entire git history,
+ which will consume quite a bit of time and bandwidth while also stressing the
+ servers.
+
+ Note, you do not have to use the same version or date all the time. But when
+ you change it over time, git will deepen or flatten the history to the
+ specified point. That allows you to retrieve versions you initially thought
+ you did not need -- or it will discard the sources of older versions, for
+ example in case you want to free up some disk space. The latter will happen
+ automatically when using ``--shallow-since=`` or
+ ``--depth=``.
+
+ * Be warned, when deepening your clone you might encounter an error like
+ 'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'.
+ In that case run ``git repack -d`` and try again``
+
+ * In case you want to revert changes from a certain version (say Linux 6.3) or
+ perform a bisection (v6.2..v6.3), better tell ``git fetch`` to retrieve
+ objects up to three versions earlier (e.g. 6.0): ``git describe`` will then
+ be able to describe most commits just like it would in a full git clone.
+
+[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
+
+.. _sources_archive:
+
+Downloading the sources using a packages archive
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+People new to compiling Linux often assume downloading an archive via the
+front-page of https://kernel.org is the best approach to retrieve Linux'
+sources. It actually can be, if you are certain to build just one particular
+kernel version without changing any code. Thing is: you might be sure this will
+be the case, but in practice it often will turn out to be a wrong assumption.
+
+That's because when reporting or debugging an issue developers will often ask to
+give another version a try. They also might suggest temporarily undoing a commit
+with ``git revert`` or might provide various patches to try. Sometimes reporters
+will also be asked to use ``git bisect`` to find the change causing a problem.
+These things rely on git or are a lot easier and quicker to handle with it.
+
+A shallow clone also does not add any significant overhead. For example, when
+you use ``git clone --depth=1`` to create a shallow clone of the latest mainline
+codebase git will only retrieve a little more data than downloading the latest
+mainline pre-release (aka 'rc') via the front-page of kernel.org would.
+
+A shallow clone therefore is often the better choice. If you nevertheless want
+to use a packaged source archive, download one via kernel.org; afterwards
+extract its content to some directory and change to the subdirectory created
+during extraction. The rest of the step-by-step guide will work just fine, apart
+from things that rely on git -- but this mainly concerns the section on
+successive builds of other versions.
+
+[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
+
+.. _sources_full:
+
+Downloading the sources using a full git clone
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If downloading and storing a lot of data (~4,4 Gigabyte as of early 2023) is
+nothing that bothers you, instead of a shallow clone perform a full git clone
+instead. You then will avoid the specialties mentioned above and will have all
+versions and individual commits at hand at any time::
+
+ curl -L \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \
+ -o linux-stable.git.bundle
+ git clone linux-stable.git.bundle ~/linux/
+ rm linux-stable.git.bundle
+ cd ~/linux/
+ git remote set-url origin \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+ git fetch origin
+ git checkout --detach origin/master
+
+[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
+
+.. _sources_snapshot:
+
+Proper pre-releases (RCs) vs. latest mainline
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When cloning the sources using git and checking out origin/master, you often
+will retrieve a codebase that is somewhere between the latest and the next
+release or pre-release. This almost always is the code you want when giving
+mainline a shot: pre-releases like v6.1-rc5 are in no way special, as they do
+not get any significant extra testing before being published.
+
+There is one exception: you might want to stick to the latest mainline release
+(say v6.1) before its successor's first pre-release (v6.2-rc1) is out. That is
+because compiler errors and other problems are more likely to occur during this
+time, as mainline then is in its 'merge window': a usually two week long phase,
+in which the bulk of the changes for the next release is merged.
+
+[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
+
+.. _sources_fresher:
+
+Avoiding the mainline lag
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The explanations for both the shallow clone and the full clone both retrieve the
+code from the Linux stable git repository. That makes things simpler for this
+document's audience, as it allows easy access to both mainline and
+stable/longterm releases. This approach has just one downside:
+
+Changes merged into the mainline repository are only synced to the master branch
+of the Linux stable repository every few hours. This lag most of the time is
+not something to worry about; but in case you really need the latest code, just
+add the mainline repo as additional remote and checkout the code from there::
+
+ git remote add mainline \
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+ git fetch mainline
+ git checkout --detach mainline/master
+
+When doing this with a shallow clone, remember to call ``git fetch`` with one
+of the parameters described earlier to limit the depth.
+
+[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`]
+
+.. _patching:
+
+Patch the sources (optional)
+----------------------------
+
+ *In case you want to apply a kernel patch, do so now.*
+ [:ref:`...<patching_sbs>`]
+
+This is the point where you might want to patch your kernel -- for example when
+a developer proposed a fix and asked you to check if it helps. The step-by-step
+guide already explains everything crucial here.
+
+[:ref:`back to step-by-step guide <patching_sbs>`]
+
+.. _tagging:
+
+Tagging this kernel build (optional, often wise)
+------------------------------------------------
+
+ *If you patched your kernel or already have that kernel version installed,
+ better tag your kernel by extending its release name:*
+ [:ref:`...<tagging_sbs>`]
+
+Tagging your kernel will help avoid confusion later, especially when you patched
+your kernel. Adding an individual tag will also ensure the kernel's image and
+its modules are installed in parallel to any existing kernels.
+
+There are various ways to add such a tag. The step-by-step guide realizes one by
+creating a 'localversion' file in your build directory from which the kernel
+build scripts will automatically pick up the tag. You can later change that file
+to use a different tag in subsequent builds or simply remove that file to dump
+the tag.
+
+[:ref:`back to step-by-step guide <tagging_sbs>`]
+
+.. _configuration:
+
+Define the build configuration for your kernel
+----------------------------------------------
+
+ *Create the build configuration for your kernel based on an existing
+ configuration.* [:ref:`... <configuration_sbs>`]
+
+There are various aspects for this steps that require a more careful
+explanation:
+
+Pitfalls when using another configuration file as base
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Make targets like localmodconfig and olddefconfig share a few common snares you
+want to be aware of:
+
+ * These targets will reuse a kernel build configuration in your build directory
+ (e.g. '~/linux/.config'), if one exists. In case you want to start from
+ scratch you thus need to delete it.
+
+ * The make targets try to find the configuration for your running kernel
+ automatically, but might choose poorly. A line like '# using defaults found
+ in /boot/config-6.0.7-250.fc36.x86_64' or 'using config:
+ '/boot/config-6.0.7-250.fc36.x86_64' tells you which file they picked. If
+ that is not the intended one, simply store it as '~/linux/.config'
+ before using these make targets.
+
+ * Unexpected things might happen if you try to use a config file prepared for
+ one kernel (say v6.0) on an older generation (say v5.15). In that case you
+ might want to use a configuration as base which your distribution utilized
+ when they used that or an slightly older kernel version.
+
+Influencing the configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The make target olddefconfig and the ``yes "" |`` used when utilizing
+localmodconfig will set any undefined build options to their default value. This
+among others will disable many kernel features that were introduced after your
+base kernel was released.
+
+If you want to set these configurations options manually, use ``oldconfig``
+instead of ``olddefconfig`` or omit the ``yes "" |`` when utilizing
+localmodconfig. Then for each undefined configuration option you will be asked
+how to proceed. In case you are unsure what to answer, simply hit 'enter' to
+apply the default value.
+
+Big pitfall when using localmodconfig
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As explained briefly in the step-by-step guide already: with localmodconfig it
+can easily happen that your self-built kernel will lack modules for tasks you
+did not perform before utilizing this make target. That's because those tasks
+require kernel modules that are normally autoloaded when you perform that task
+for the first time; if you didn't perform that task at least once before using
+localmodconfig, the latter will thus assume these modules are superfluous and
+disable them.
+
+You can try to avoid this by performing typical tasks that often will autoload
+additional kernel modules: start a VM, establish VPN connections, loop-mount a
+CD/DVD ISO, mount network shares (CIFS, NFS, ...), and connect all external
+devices (2FA keys, headsets, webcams, ...) as well as storage devices with file
+systems you otherwise do not utilize (btrfs, ext4, FAT, NTFS, XFS, ...). But it
+is hard to think of everything that might be needed -- even kernel developers
+often forget one thing or another at this point.
+
+Do not let that risk bother you, especially when compiling a kernel only for
+testing purposes: everything typically crucial will be there. And if you forget
+something important you can turn on a missing feature later and quickly run the
+commands to compile and install a better kernel.
+
+But if you plan to build and use self-built kernels regularly, you might want to
+reduce the risk by recording which modules your system loads over the course of
+a few weeks. You can automate this with `modprobed-db
+<https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to
+point localmodconfig to the list of modules modprobed-db noticed being used::
+
+ yes "" | make LSMOD="${HOME}"/.config/modprobed.db localmodconfig
+
+Remote building with localmodconfig
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you want to use localmodconfig to build a kernel for another machine, run
+``lsmod > lsmod_foo-machine`` on it and transfer that file to your build host.
+Now point the build scripts to the file like this: ``yes "" | make
+LSMOD=~/lsmod_foo-machine localmodconfig``. Note, in this case
+you likely want to copy a base kernel configuration from the other machine over
+as well and place it as .config in your build directory.
+
+[:ref:`back to step-by-step guide <configuration_sbs>`]
+
+.. _configmods:
+
+Adjust build configuration
+--------------------------
+
+ *Check if you might want to or have to adjust some kernel configuration
+ options:*
+
+Depending on your needs you at this point might want or have to adjust some
+kernel configuration options.
+
+.. _configmods_debugsymbols:
+
+Debug symbols
+~~~~~~~~~~~~~
+
+ *Evaluate how you want to handle debug symbols.*
+ [:ref:`...<configmods_sbs>`]
+
+Most users do not need to care about this, it's often fine to leave everything
+as it is; but you should take a closer look at this, if you might need to decode
+a stack trace or want to reduce space consumption.
+
+Having debug symbols available can be important when your kernel throws a
+'panic', 'Oops', 'warning', or 'BUG' later when running, as then you will be
+able to find the exact place where the problem occurred in the code. But
+collecting and embedding the needed debug information takes time and consumes
+quite a bit of space: in late 2022 the build artifacts for a typical x86 kernel
+configured with localmodconfig consumed around 5 Gigabyte of space with debug
+symbols, but less than 1 when they were disabled. The resulting kernel image and
+the modules are bigger as well, which increases load times.
+
+Hence, if you want a small kernel and are unlikely to decode a stack trace
+later, you might want to disable debug symbols to avoid above downsides::
+
+ ./scripts/config --file .config -d DEBUG_INFO \
+ -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -d DEBUG_INFO_DWARF4 \
+ -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
+ make olddefconfig
+
+You on the other hand definitely want to enable them, if there is a decent
+chance that you need to decode a stack trace later (as explained by 'Decode
+failure messages' in Documentation/admin-guide/tainted-kernels.rst in more
+detail)::
+
+ ./scripts/config --file .config -d DEBUG_INFO_NONE -e DEBUG_KERNEL
+ -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS -e KALLSYMS_ALL
+ make olddefconfig
+
+Note, many mainstream distributions enable debug symbols in their kernel
+configurations -- make targets like localmodconfig and olddefconfig thus will
+often pick that setting up.
+
+[:ref:`back to step-by-step guide <configmods_sbs>`]
+
+.. _configmods_distros:
+
+Distro specific adjustments
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Are you running* [:ref:`... <configmods_sbs>`]
+
+The following sections help you to avoid build problems that are known to occur
+when following this guide on a few commodity distributions.
+
+**Debian:**
+
+ * Remove a stale reference to a certificate file that would cause your build to
+ fail::
+
+ ./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS ''
+
+ Alternatively, download the needed certificate and make that configuration
+ option point to it, as `the Debian handbook explains in more detail
+ <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
+ -- or generate your own, as explained in
+ Documentation/admin-guide/module-signing.rst.
+
+[:ref:`back to step-by-step guide <configmods_sbs>`]
+
+.. _configmods_individual:
+
+Individual adjustments
+~~~~~~~~~~~~~~~~~~~~~~
+
+ *If you want to influence the other aspects of the configuration, do so
+ now* [:ref:`... <configmods_sbs>`]
+
+You at this point can use a command like ``make menuconfig`` to enable or
+disable certain features using a text-based user interface; to use a graphical
+configuration utilize, use the make target ``xconfig`` or ``gconfig`` instead.
+All of them require development libraries from toolkits they are based on
+(ncurses, Qt5, Gtk2); an error message will tell you if something required is
+missing.
+
+[:ref:`back to step-by-step guide <configmods_sbs>`]
+
+.. _build:
+
+Build your kernel
+-----------------
+
+ *Build the image and the modules of your kernel* [:ref:`... <build_sbs>`]
+
+A lot can go wrong at this stage, but the instructions below will help you help
+yourself. Another subsection explains how to directly package your kernel up as
+deb, rpm or tar file.
+
+Dealing with build errors
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When a build error occurs, it might be caused by some aspect of your machine's
+setup that often can be fixed quickly; other times though the problem lies in
+the code and can only be fixed by a developer. A close examination of the
+failure messages coupled with some research on the internet will often tell you
+which of the two it is. To perform such an investigation, restart the build
+process like this::
+
+ make V=1
+
+The ``V=1`` activates verbose output, which might be needed to see the actual
+error. To make it easier to spot, this command also omits the ``-j $(nproc
+--all)`` used earlier to utilize every CPU core in the system for the job -- but
+this parallelism also results in some clutter when failures occur.
+
+After a few seconds the build process should run into the error again. Now try
+to find the most crucial line describing the problem. Then search the internet
+for the most important and non-generic section of that line (say 4 to 8 words);
+avoid or remove anything that looks remotely system-specific, like your username
+or local path names like ``/home/username/linux/``. First try your regular
+internet search engine with that string, afterwards search Linux kernel mailing
+lists via `lore.kernel.org/all/ <https://lore.kernel.org/all/>`_.
+
+This most of the time will find something that will explain what is wrong; quite
+often one of the hits will provide a solution for your problem, too. If you
+do not find anything that matches your problem, try again from a different angle
+by modifying your search terms or using another line from the error messages.
+
+In the end, most trouble you are to run into has likely been encountered and
+reported by others already. That includes issues where the cause is not your
+system, but lies the code. If you run into one of those, you might thus find a
+solution (e.g. a patch) or workaround for your problem, too.
+
+Package your kernel up
+~~~~~~~~~~~~~~~~~~~~~~
+
+The step-by-step guide uses the default make targets (e.g. 'bzImage' and
+'modules' on x86) to build the image and the modules of your kernel, which later
+steps of the guide then install. You instead can also directly build everything
+and directly package it up by using one of the following targets:
+
+ * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
+
+ * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
+
+ * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
+
+This is just a selection of available make targets for this purpose, see
+``make help`` for others. You can also use these targets after running
+``make -j $(nproc --all)``, as they will pick up everything already built.
+
+If you employ the targets to generate deb or rpm packages, ignore the
+step-by-step guide's instructions on installing and removing your kernel;
+instead install and remove the packages using the package utility for the format
+(e.g. dpkg and rpm) or a package management utility build on top of them (apt,
+aptitude, dnf/yum, zypper, ...). Be aware that the packages generated using
+these two make targets are designed to work on various distributions utilizing
+those formats, they thus will sometimes behave differently than your
+distribution's kernel packages.
+
+[:ref:`back to step-by-step guide <build_sbs>`]
+
+.. _install:
+
+Install your kernel
+-------------------
+
+ *Now install your kernel* [:ref:`... <install_sbs>`]
+
+What you need to do after executing the command in the step-by-step guide
+depends on the existence and the implementation of an ``installkernel``
+executable. Many commodity Linux distributions ship such a kernel installer in
+``/sbin/`` that does everything needed, hence there is nothing left for you
+except rebooting. But some distributions contain an installkernel that does
+only part of the job -- and a few lack it completely and leave all the work to
+you.
+
+If ``installkernel`` is found, the kernel's build system will delegate the
+actual installation of your kernel's image and related files to this executable.
+On almost all Linux distributions it will store the image as '/boot/vmlinuz-
+<your kernel's release name>' and put a 'System.map-<your kernel's release
+name>' alongside it. Your kernel will thus be installed in parallel to any
+existing ones, unless you already have one with exactly the same release name.
+
+Installkernel on many distributions will afterwards generate an 'initramfs'
+(often also called 'initrd'), which commodity distributions rely on for booting;
+hence be sure to keep the order of the two make targets used in the step-by-step
+guide, as things will go sideways if you install your kernel's image before its
+modules. Often installkernel will then add your kernel to the bootloader
+configuration, too. You have to take care of one or both of these tasks
+yourself, if your distributions installkernel doesn't handle them.
+
+A few distributions like Arch Linux and its derivatives totally lack an
+installkernel executable. On those just install the modules using the kernel's
+build system and then install the image and the System.map file manually::
+
+ sudo make modules_install
+ sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
+ sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
+
+If your distribution boots with the help of an initramfs, now generate one for
+your kernel using the tools your distribution provides for this process.
+Afterwards add your kernel to your bootloader configuration and reboot.
+
+[:ref:`back to step-by-step guide <install_sbs>`]
+
+.. _another:
+
+Another round later
+-------------------
+
+ *To later build another kernel you need similar, but sometimes slightly
+ different commands* [:ref:`... <another_sbs>`]
+
+The process to build later kernels is similar, but at some points slightly
+different. You for example do not want to use 'localmodconfig' for succeeding
+kernel builds, as you already created a trimmed down configuration you want to
+use from now on. Hence instead just use ``oldconfig`` or ``olddefconfig`` to
+adjust your build configurations to the needs of the kernel version you are
+about to build.
+
+If you created a shallow-clone with git, remember what the :ref:`section that
+explained the setup described in more detail <sources>`: you need to use a
+slightly different ``git fetch`` command and when switching to another series
+need to add an additional remote branch.
+
+[:ref:`back to step-by-step guide <another_sbs>`]
+
+.. _uninstall:
+
+Uninstall the kernel later
+--------------------------
+
+ *All parts of your installed kernel are identifiable by its release name and
+ thus easy to remove later.* [:ref:`... <uninstall_sbs>`]
+
+Do not worry installing your kernel manually and thus bypassing your
+distribution's packaging system will totally mess up your machine: all parts of
+your kernel are easy to remove later, as files are stored in two places only and
+normally identifiable by the kernel's release name.
+
+One of the two places is a directory in /lib/modules/, which holds the modules
+for each installed kernel. This directory is named after the kernel's release
+name; hence, to remove all modules for one of your kernels, simply remove its
+modules directory in /lib/modules/.
+
+The other place is /boot/, where typically one to five files will be placed
+during installation of a kernel. All of them usually contain the release name in
+their file name, but how many files and their name depends somewhat on your
+distribution's installkernel executable (:ref:`see above <install>`) and its
+initramfs generator. On some distributions the ``kernel-install`` command
+mentioned in the step-by-step guide will remove all of these files for you --
+and the entry for your kernel in the bootloader configuration at the same time,
+too. On others you have to take care of these steps yourself. The following
+command should interactively remove the two main files of a kernel with the
+release name '6.0.1-foobar'::
+
+ rm -i /boot/{System.map,vmlinuz}-6.0.1-foobar
+
+Now remove the belonging initramfs, which often will be called something like
+``/boot/initramfs-6.0.1-foobar.img`` or ``/boot/initrd.img-6.0.1-foobar``.
+Afterwards check for other files in /boot/ that have '6.0.1-foobar' in their
+name and delete them as well. Now remove the kernel from your bootloader's
+configuration.
+
+Note, be very careful with wildcards like '*' when deleting files or directories
+for kernels manually: you might accidentally remove files of a 6.0.11 kernel
+when all you want is to remove 6.0 or 6.0.1.
+
+[:ref:`back to step-by-step guide <uninstall_sbs>`]
+
+.. _faq:
+
+FAQ
+===
+
+Why does this 'how-to' not work on my system?
+---------------------------------------------
+
+As initially stated, this guide is 'designed to cover everything typically
+needed [to build a kernel] on mainstream Linux distributions running on
+commodity PC or server hardware'. The outlined approach despite this should work
+on many other setups as well. But trying to cover every possible use-case in one
+guide would defeat its purpose, as without such a focus you would need dozens or
+hundreds of constructs along the lines of 'in case you are having <insert
+machine or distro>, you at this point have to do <this and that>
+<instead|additionally>'. Each of which would make the text longer, more
+complicated, and harder to follow.
+
+That being said: this of course is a balancing act. Hence, if you think an
+additional use-case is worth describing, suggest it to the maintainers of this
+document, as :ref:`described above <submit_improvements_qbtl>`.
+
+
+..
+ end-of-content
+..
+ This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If
+ you spot a typo or small mistake, feel free to let him know directly and
+ he'll fix it. You are free to do the same in a mostly informal way if you
+ want to contribute changes to the text -- but for copyright reasons please CC
+ linux-doc@vger.kernel.org and 'sign-off' your contribution as
+ Documentation/process/submitting-patches.rst explains in the section 'Sign
+ your work - the Developer's Certificate of Origin'.
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use 'The Linux kernel development community' for author attribution
+ and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/quickly-build-trimmed-linux.rst
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
+
diff --git a/Documentation/admin-guide/ramoops.rst b/Documentation/admin-guide/ramoops.rst
index e9f85142182d..2eabef31220d 100644
--- a/Documentation/admin-guide/ramoops.rst
+++ b/Documentation/admin-guide/ramoops.rst
@@ -23,6 +23,8 @@ and type of the memory area are set using three variables:
* ``mem_size`` for the size. The memory size will be rounded down to a
power of two.
* ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
+ * ``mem_name`` to specify a memory region defined by ``reserve_mem`` command
+ line parameter.
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use
@@ -118,6 +120,17 @@ Setting the ramoops parameters can be done in several different manners:
return ret;
}
+ D. Using a region of memory reserved via ``reserve_mem`` command line
+ parameter. The address and size will be defined by the ``reserve_mem``
+ parameter. Note, that ``reserve_mem`` may not always allocate memory
+ in the same location, and cannot be relied upon. Testing will need
+ to be done, and it may not work on every machine, nor every kernel.
+ Consider this a "best effort" approach. The ``reserve_mem`` option
+ takes a size, alignment and name as arguments. The name is used
+ to map the memory to a label that can be retrieved by ramoops.
+
+ reserve_mem=2M:4096:oops ramoops.mem_name=oops
+
You can specify either RAM memory or peripheral devices' memory. However, when
specifying RAM, be sure to reserve the memory by issuing memblock_reserve()
very early in the architecture code, e.g.::
diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst
deleted file mode 100644
index 7b481b2a368e..000000000000
--- a/Documentation/admin-guide/ras.rst
+++ /dev/null
@@ -1,1219 +0,0 @@
-.. include:: <isonum.txt>
-
-============================================
-Reliability, Availability and Serviceability
-============================================
-
-RAS concepts
-************
-
-Reliability, Availability and Serviceability (RAS) is a concept used on
-servers meant to measure their robustness.
-
-Reliability
- is the probability that a system will produce correct outputs.
-
- * Generally measured as Mean Time Between Failures (MTBF)
- * Enhanced by features that help to avoid, detect and repair hardware faults
-
-Availability
- is the probability that a system is operational at a given time
-
- * Generally measured as a percentage of downtime per a period of time
- * Often uses mechanisms to detect and correct hardware faults in
- runtime;
-
-Serviceability (or maintainability)
- is the simplicity and speed with which a system can be repaired or
- maintained
-
- * Generally measured on Mean Time Between Repair (MTBR)
-
-Improving RAS
--------------
-
-In order to reduce systems downtime, a system should be capable of detecting
-hardware errors, and, when possible correcting them in runtime. It should
-also provide mechanisms to detect hardware degradation, in order to warn
-the system administrator to take the action of replacing a component before
-it causes data loss or system downtime.
-
-Among the monitoring measures, the most usual ones include:
-
-* CPU – detect errors at instruction execution and at L1/L2/L3 caches;
-* Memory – add error correction logic (ECC) to detect and correct errors;
-* I/O – add CRC checksums for transferred data;
-* Storage – RAID, journal file systems, checksums,
- Self-Monitoring, Analysis and Reporting Technology (SMART).
-
-By monitoring the number of occurrences of error detections, it is possible
-to identify if the probability of hardware errors is increasing, and, on such
-case, do a preventive maintenance to replace a degraded component while
-those errors are correctable.
-
-Types of errors
----------------
-
-Most mechanisms used on modern systems use technologies like Hamming
-Codes that allow error correction when the number of errors on a bit packet
-is below a threshold. If the number of errors is above, those mechanisms
-can indicate with a high degree of confidence that an error happened, but
-they can't correct.
-
-Also, sometimes an error occur on a component that it is not used. For
-example, a part of the memory that it is not currently allocated.
-
-That defines some categories of errors:
-
-* **Correctable Error (CE)** - the error detection mechanism detected and
- corrected the error. Such errors are usually not fatal, although some
- Kernel mechanisms allow the system administrator to consider them as fatal.
-
-* **Uncorrected Error (UE)** - the amount of errors happened above the error
- correction threshold, and the system was unable to auto-correct.
-
-* **Fatal Error** - when an UE error happens on a critical component of the
- system (for example, a piece of the Kernel got corrupted by an UE), the
- only reliable way to avoid data corruption is to hang or reboot the machine.
-
-* **Non-fatal Error** - when an UE error happens on an unused component,
- like a CPU in power down state or an unused memory bank, the system may
- still run, eventually replacing the affected hardware by a hot spare,
- if available.
-
- Also, when an error happens on a userspace process, it is also possible to
- kill such process and let userspace restart it.
-
-The mechanism for handling non-fatal errors is usually complex and may
-require the help of some userspace application, in order to apply the
-policy desired by the system administrator.
-
-Identifying a bad hardware component
-------------------------------------
-
-Just detecting a hardware flaw is usually not enough, as the system needs
-to pinpoint to the minimal replaceable unit (MRU) that should be exchanged
-to make the hardware reliable again.
-
-So, it requires not only error logging facilities, but also mechanisms that
-will translate the error message to the silkscreen or component label for
-the MRU.
-
-Typically, it is very complex for memory, as modern CPUs interlace memory
-from different memory modules, in order to provide a better performance. The
-DMI BIOS usually have a list of memory module labels, with can be obtained
-using the ``dmidecode`` tool. For example, on a desktop machine, it shows::
-
- Memory Device
- Total Width: 64 bits
- Data Width: 64 bits
- Size: 16384 MB
- Form Factor: SODIMM
- Set: None
- Locator: ChannelA-DIMM0
- Bank Locator: BANK 0
- Type: DDR4
- Type Detail: Synchronous
- Speed: 2133 MHz
- Rank: 2
- Configured Clock Speed: 2133 MHz
-
-On the above example, a DDR4 SO-DIMM memory module is located at the
-system's memory labeled as "BANK 0", as given by the *bank locator* field.
-Please notice that, on such system, the *total width* is equal to the
-*data width*. It means that such memory module doesn't have error
-detection/correction mechanisms.
-
-Unfortunately, not all systems use the same field to specify the memory
-bank. On this example, from an older server, ``dmidecode`` shows::
-
- Memory Device
- Array Handle: 0x1000
- Error Information Handle: Not Provided
- Total Width: 72 bits
- Data Width: 64 bits
- Size: 8192 MB
- Form Factor: DIMM
- Set: 1
- Locator: DIMM_A1
- Bank Locator: Not Specified
- Type: DDR3
- Type Detail: Synchronous Registered (Buffered)
- Speed: 1600 MHz
- Rank: 2
- Configured Clock Speed: 1600 MHz
-
-There, the DDR3 RDIMM memory module is located at the system's memory labeled
-as "DIMM_A1", as given by the *locator* field. Please notice that this
-memory module has 64 bits of *data width* and 72 bits of *total width*. So,
-it has 8 extra bits to be used by error detection and correction mechanisms.
-Such kind of memory is called Error-correcting code memory (ECC memory).
-
-To make things even worse, it is not uncommon that systems with different
-labels on their system's board to use exactly the same BIOS, meaning that
-the labels provided by the BIOS won't match the real ones.
-
-ECC memory
-----------
-
-As mentioned in the previous section, ECC memory has extra bits to be
-used for error correction. In the above example, a memory module has
-64 bits of *data width*, and 72 bits of *total width*. The extra 8
-bits which are used for the error detection and correction mechanisms
-are referred to as the *syndrome*\ [#f1]_\ [#f2]_.
-
-So, when the cpu requests the memory controller to write a word with
-*data width*, the memory controller calculates the *syndrome* in real time,
-using Hamming code, or some other error correction code, like SECDED+,
-producing a code with *total width* size. Such code is then written
-on the memory modules.
-
-At read, the *total width* bits code is converted back, using the same
-ECC code used on write, producing a word with *data width* and a *syndrome*.
-The word with *data width* is sent to the CPU, even when errors happen.
-
-The memory controller also looks at the *syndrome* in order to check if
-there was an error, and if the ECC code was able to fix such error.
-If the error was corrected, a Corrected Error (CE) happened. If not, an
-Uncorrected Error (UE) happened.
-
-The information about the CE/UE errors is stored on some special registers
-at the memory controller and can be accessed by reading such registers,
-either by BIOS, by some special CPUs or by Linux EDAC driver. On x86 64
-bit CPUs, such errors can also be retrieved via the Machine Check
-Architecture (MCA)\ [#f3]_.
-
-.. [#f1] Please notice that several memory controllers allow operation on a
- mode called "Lock-Step", where it groups two memory modules together,
- doing 128-bit reads/writes. That gives 16 bits for error correction, with
- significantly improves the error correction mechanism, at the expense
- that, when an error happens, there's no way to know what memory module is
- to blame. So, it has to blame both memory modules.
-
-.. [#f2] Some memory controllers also allow using memory in mirror mode.
- On such mode, the same data is written to two memory modules. At read,
- the system checks both memory modules, in order to check if both provide
- identical data. On such configuration, when an error happens, there's no
- way to know what memory module is to blame. So, it has to blame both
- memory modules (or 4 memory modules, if the system is also on Lock-step
- mode).
-
-.. [#f3] For more details about the Machine Check Architecture (MCA),
- please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree.
-
-EDAC - Error Detection And Correction
-*************************************
-
-.. note::
-
- "bluesmoke" was the name for this device driver subsystem when it
- was "out-of-tree" and maintained at http://bluesmoke.sourceforge.net.
- That site is mostly archaic now and can be used only for historical
- purposes.
-
- When the subsystem was pushed upstream for the first time, on
- Kernel 2.6.16, it was renamed to ``EDAC``.
-
-Purpose
--------
-
-The ``edac`` kernel module's goal is to detect and report hardware errors
-that occur within the computer system running under linux.
-
-Memory
-------
-
-Memory Correctable Errors (CE) and Uncorrectable Errors (UE) are the
-primary errors being harvested. These types of errors are harvested by
-the ``edac_mc`` device.
-
-Detecting CE events, then harvesting those events and reporting them,
-**can** but must not necessarily be a predictor of future UE events. With
-CE events only, the system can and will continue to operate as no data
-has been damaged yet.
-
-However, preventive maintenance and proactive part replacement of memory
-modules exhibiting CEs can reduce the likelihood of the dreaded UE events
-and system panics.
-
-Other hardware elements
------------------------
-
-A new feature for EDAC, the ``edac_device`` class of device, was added in
-the 2.6.23 version of the kernel.
-
-This new device type allows for non-memory type of ECC hardware detectors
-to have their states harvested and presented to userspace via the sysfs
-interface.
-
-Some architectures have ECC detectors for L1, L2 and L3 caches,
-along with DMA engines, fabric switches, main data path switches,
-interconnections, and various other hardware data paths. If the hardware
-reports it, then a edac_device device probably can be constructed to
-harvest and present that to userspace.
-
-
-PCI bus scanning
-----------------
-
-In addition, PCI devices are scanned for PCI Bus Parity and SERR Errors
-in order to determine if errors are occurring during data transfers.
-
-The presence of PCI Parity errors must be examined with a grain of salt.
-There are several add-in adapters that do **not** follow the PCI specification
-with regards to Parity generation and reporting. The specification says
-the vendor should tie the parity status bits to 0 if they do not intend
-to generate parity. Some vendors do not do this, and thus the parity bit
-can "float" giving false positives.
-
-There is a PCI device attribute located in sysfs that is checked by
-the EDAC PCI scanning code. If that attribute is set, PCI parity/error
-scanning is skipped for that device. The attribute is::
-
- broken_parity_status
-
-and is located in ``/sys/devices/pci<XXX>/0000:XX:YY.Z`` directories for
-PCI devices.
-
-
-Versioning
-----------
-
-EDAC is composed of a "core" module (``edac_core.ko``) and several Memory
-Controller (MC) driver modules. On a given system, the CORE is loaded
-and one MC driver will be loaded. Both the CORE and the MC driver (or
-``edac_device`` driver) have individual versions that reflect current
-release level of their respective modules.
-
-Thus, to "report" on what version a system is running, one must report
-both the CORE's and the MC driver's versions.
-
-
-Loading
--------
-
-If ``edac`` was statically linked with the kernel then no loading
-is necessary. If ``edac`` was built as modules then simply modprobe
-the ``edac`` pieces that you need. You should be able to modprobe
-hardware-specific modules and have the dependencies load the necessary
-core modules.
-
-Example::
-
- $ modprobe amd76x_edac
-
-loads both the ``amd76x_edac.ko`` memory controller module and the
-``edac_mc.ko`` core module.
-
-
-Sysfs interface
----------------
-
-EDAC presents a ``sysfs`` interface for control and reporting purposes. It
-lives in the /sys/devices/system/edac directory.
-
-Within this directory there currently reside 2 components:
-
- ======= ==============================
- mc memory controller(s) system
- pci PCI control and status system
- ======= ==============================
-
-
-
-Memory Controller (mc) Model
-----------------------------
-
-Each ``mc`` device controls a set of memory modules [#f4]_. These modules
-are laid out in a Chip-Select Row (``csrowX``) and Channel table (``chX``).
-There can be multiple csrows and multiple channels.
-
-.. [#f4] Nowadays, the term DIMM (Dual In-line Memory Module) is widely
- used to refer to a memory module, although there are other memory
- packaging alternatives, like SO-DIMM, SIMM, etc. The UEFI
- specification (Version 2.7) defines a memory module in the Common
- Platform Error Record (CPER) section to be an SMBIOS Memory Device
- (Type 17). Along this document, and inside the EDAC subsystem, the term
- "dimm" is used for all memory modules, even when they use a
- different kind of packaging.
-
-Memory controllers allow for several csrows, with 8 csrows being a
-typical value. Yet, the actual number of csrows depends on the layout of
-a given motherboard, memory controller and memory module characteristics.
-
-Dual channels allow for dual data length (e. g. 128 bits, on 64 bit systems)
-data transfers to/from the CPU from/to memory. Some newer chipsets allow
-for more than 2 channels, like Fully Buffered DIMMs (FB-DIMMs) memory
-controllers. The following example will assume 2 channels:
-
- +------------+-----------------------+
- | CS Rows | Channels |
- +------------+-----------+-----------+
- | | ``ch0`` | ``ch1`` |
- +============+===========+===========+
- | |**DIMM_A0**|**DIMM_B0**|
- +------------+-----------+-----------+
- | ``csrow0`` | rank0 | rank0 |
- +------------+-----------+-----------+
- | ``csrow1`` | rank1 | rank1 |
- +------------+-----------+-----------+
- | |**DIMM_A1**|**DIMM_B1**|
- +------------+-----------+-----------+
- | ``csrow2`` | rank0 | rank0 |
- +------------+-----------+-----------+
- | ``csrow3`` | rank1 | rank1 |
- +------------+-----------+-----------+
-
-In the above example, there are 4 physical slots on the motherboard
-for memory DIMMs:
-
- +---------+---------+
- | DIMM_A0 | DIMM_B0 |
- +---------+---------+
- | DIMM_A1 | DIMM_B1 |
- +---------+---------+
-
-Labels for these slots are usually silk-screened on the motherboard.
-Slots labeled ``A`` are channel 0 in this example. Slots labeled ``B`` are
-channel 1. Notice that there are two csrows possible on a physical DIMM.
-These csrows are allocated their csrow assignment based on the slot into
-which the memory DIMM is placed. Thus, when 1 DIMM is placed in each
-Channel, the csrows cross both DIMMs.
-
-Memory DIMMs come single or dual "ranked". A rank is a populated csrow.
-In the example above 2 dual ranked DIMMs are similarly placed. Thus,
-both csrow0 and csrow1 are populated. On the other hand, when 2 single
-ranked DIMMs are placed in slots DIMM_A0 and DIMM_B0, then they will
-have just one csrow (csrow0) and csrow1 will be empty. The pattern
-repeats itself for csrow2 and csrow3. Also note that some memory
-controllers don't have any logic to identify the memory module, see
-``rankX`` directories below.
-
-The representation of the above is reflected in the directory
-tree in EDAC's sysfs interface. Starting in directory
-``/sys/devices/system/edac/mc``, each memory controller will be
-represented by its own ``mcX`` directory, where ``X`` is the
-index of the MC::
-
- ..../edac/mc/
- |
- |->mc0
- |->mc1
- |->mc2
- ....
-
-Under each ``mcX`` directory each ``csrowX`` is again represented by a
-``csrowX``, where ``X`` is the csrow index::
-
- .../mc/mc0/
- |
- |->csrow0
- |->csrow2
- |->csrow3
- ....
-
-Notice that there is no csrow1, which indicates that csrow0 is composed
-of a single ranked DIMMs. This should also apply in both Channels, in
-order to have dual-channel mode be operational. Since both csrow2 and
-csrow3 are populated, this indicates a dual ranked set of DIMMs for
-channels 0 and 1.
-
-Within each of the ``mcX`` and ``csrowX`` directories are several EDAC
-control and attribute files.
-
-``mcX`` directories
--------------------
-
-In ``mcX`` directories are EDAC control and attribute files for
-this ``X`` instance of the memory controllers.
-
-For a description of the sysfs API, please see:
-
- Documentation/ABI/testing/sysfs-devices-edac
-
-
-``dimmX`` or ``rankX`` directories
-----------------------------------
-
-The recommended way to use the EDAC subsystem is to look at the information
-provided by the ``dimmX`` or ``rankX`` directories [#f5]_.
-
-A typical EDAC system has the following structure under
-``/sys/devices/system/edac/``\ [#f6]_::
-
- /sys/devices/system/edac/
- ├── mc
- │   ├── mc0
- │   │   ├── ce_count
- │   │   ├── ce_noinfo_count
- │   │   ├── dimm0
- │   │   │   ├── dimm_ce_count
- │   │   │   ├── dimm_dev_type
- │   │   │   ├── dimm_edac_mode
- │   │   │   ├── dimm_label
- │   │   │   ├── dimm_location
- │   │   │   ├── dimm_mem_type
- │   │   │   ├── dimm_ue_count
- │   │   │   ├── size
- │   │   │   └── uevent
- │   │   ├── max_location
- │   │   ├── mc_name
- │   │   ├── reset_counters
- │   │   ├── seconds_since_reset
- │   │   ├── size_mb
- │   │   ├── ue_count
- │   │   ├── ue_noinfo_count
- │   │   └── uevent
- │   ├── mc1
- │   │   ├── ce_count
- │   │   ├── ce_noinfo_count
- │   │   ├── dimm0
- │   │   │   ├── dimm_ce_count
- │   │   │   ├── dimm_dev_type
- │   │   │   ├── dimm_edac_mode
- │   │   │   ├── dimm_label
- │   │   │   ├── dimm_location
- │   │   │   ├── dimm_mem_type
- │   │   │   ├── dimm_ue_count
- │   │   │   ├── size
- │   │   │   └── uevent
- │   │   ├── max_location
- │   │   ├── mc_name
- │   │   ├── reset_counters
- │   │   ├── seconds_since_reset
- │   │   ├── size_mb
- │   │   ├── ue_count
- │   │   ├── ue_noinfo_count
- │   │   └── uevent
- │   └── uevent
- └── uevent
-
-In the ``dimmX`` directories are EDAC control and attribute files for
-this ``X`` memory module:
-
-- ``size`` - Total memory managed by this csrow attribute file
-
- This attribute file displays, in count of megabytes, the memory
- that this csrow contains.
-
-- ``dimm_ue_count`` - Uncorrectable Errors count attribute file
-
- This attribute file displays the total count of uncorrectable
- errors that have occurred on this DIMM. If panic_on_ue is set
- this counter will not have a chance to increment, since EDAC
- will panic the system.
-
-- ``dimm_ce_count`` - Correctable Errors count attribute file
-
- This attribute file displays the total count of correctable
- errors that have occurred on this DIMM. This count is very
- important to examine. CEs provide early indications that a
- DIMM is beginning to fail. This count field should be
- monitored for non-zero values and report such information
- to the system administrator.
-
-- ``dimm_dev_type`` - Device type attribute file
-
- This attribute file will display what type of DRAM device is
- being utilized on this DIMM.
- Examples:
-
- - x1
- - x2
- - x4
- - x8
-
-- ``dimm_edac_mode`` - EDAC Mode of operation attribute file
-
- This attribute file will display what type of Error detection
- and correction is being utilized.
-
-- ``dimm_label`` - memory module label control file
-
- This control file allows this DIMM to have a label assigned
- to it. With this label in the module, when errors occur
- the output can provide the DIMM label in the system log.
- This becomes vital for panic events to isolate the
- cause of the UE event.
-
- DIMM Labels must be assigned after booting, with information
- that correctly identifies the physical slot with its
- silk screen label. This information is currently very
- motherboard specific and determination of this information
- must occur in userland at this time.
-
-- ``dimm_location`` - location of the memory module
-
- The location can have up to 3 levels, and describe how the
- memory controller identifies the location of a memory module.
- Depending on the type of memory and memory controller, it
- can be:
-
- - *csrow* and *channel* - used when the memory controller
- doesn't identify a single DIMM - e. g. in ``rankX`` dir;
- - *branch*, *channel*, *slot* - typically used on FB-DIMM memory
- controllers;
- - *channel*, *slot* - used on Nehalem and newer Intel drivers.
-
-- ``dimm_mem_type`` - Memory Type attribute file
-
- This attribute file will display what type of memory is currently
- on this csrow. Normally, either buffered or unbuffered memory.
- Examples:
-
- - Registered-DDR
- - Unbuffered-DDR
-
-.. [#f5] On some systems, the memory controller doesn't have any logic
- to identify the memory module. On such systems, the directory is called ``rankX`` and works on a similar way as the ``csrowX`` directories.
- On modern Intel memory controllers, the memory controller identifies the
- memory modules directly. On such systems, the directory is called ``dimmX``.
-
-.. [#f6] There are also some ``power`` directories and ``subsystem``
- symlinks inside the sysfs mapping that are automatically created by
- the sysfs subsystem. Currently, they serve no purpose.
-
-``csrowX`` directories
-----------------------
-
-When CONFIG_EDAC_LEGACY_SYSFS is enabled, sysfs will contain the ``csrowX``
-directories. As this API doesn't work properly for Rambus, FB-DIMMs and
-modern Intel Memory Controllers, this is being deprecated in favor of
-``dimmX`` directories.
-
-In the ``csrowX`` directories are EDAC control and attribute files for
-this ``X`` instance of csrow:
-
-
-- ``ue_count`` - Total Uncorrectable Errors count attribute file
-
- This attribute file displays the total count of uncorrectable
- errors that have occurred on this csrow. If panic_on_ue is set
- this counter will not have a chance to increment, since EDAC
- will panic the system.
-
-
-- ``ce_count`` - Total Correctable Errors count attribute file
-
- This attribute file displays the total count of correctable
- errors that have occurred on this csrow. This count is very
- important to examine. CEs provide early indications that a
- DIMM is beginning to fail. This count field should be
- monitored for non-zero values and report such information
- to the system administrator.
-
-
-- ``size_mb`` - Total memory managed by this csrow attribute file
-
- This attribute file displays, in count of megabytes, the memory
- that this csrow contains.
-
-
-- ``mem_type`` - Memory Type attribute file
-
- This attribute file will display what type of memory is currently
- on this csrow. Normally, either buffered or unbuffered memory.
- Examples:
-
- - Registered-DDR
- - Unbuffered-DDR
-
-
-- ``edac_mode`` - EDAC Mode of operation attribute file
-
- This attribute file will display what type of Error detection
- and correction is being utilized.
-
-
-- ``dev_type`` - Device type attribute file
-
- This attribute file will display what type of DRAM device is
- being utilized on this DIMM.
- Examples:
-
- - x1
- - x2
- - x4
- - x8
-
-
-- ``ch0_ce_count`` - Channel 0 CE Count attribute file
-
- This attribute file will display the count of CEs on this
- DIMM located in channel 0.
-
-
-- ``ch0_ue_count`` - Channel 0 UE Count attribute file
-
- This attribute file will display the count of UEs on this
- DIMM located in channel 0.
-
-
-- ``ch0_dimm_label`` - Channel 0 DIMM Label control file
-
-
- This control file allows this DIMM to have a label assigned
- to it. With this label in the module, when errors occur
- the output can provide the DIMM label in the system log.
- This becomes vital for panic events to isolate the
- cause of the UE event.
-
- DIMM Labels must be assigned after booting, with information
- that correctly identifies the physical slot with its
- silk screen label. This information is currently very
- motherboard specific and determination of this information
- must occur in userland at this time.
-
-
-- ``ch1_ce_count`` - Channel 1 CE Count attribute file
-
-
- This attribute file will display the count of CEs on this
- DIMM located in channel 1.
-
-
-- ``ch1_ue_count`` - Channel 1 UE Count attribute file
-
-
- This attribute file will display the count of UEs on this
- DIMM located in channel 0.
-
-
-- ``ch1_dimm_label`` - Channel 1 DIMM Label control file
-
- This control file allows this DIMM to have a label assigned
- to it. With this label in the module, when errors occur
- the output can provide the DIMM label in the system log.
- This becomes vital for panic events to isolate the
- cause of the UE event.
-
- DIMM Labels must be assigned after booting, with information
- that correctly identifies the physical slot with its
- silk screen label. This information is currently very
- motherboard specific and determination of this information
- must occur in userland at this time.
-
-
-System Logging
---------------
-
-If logging for UEs and CEs is enabled, then system logs will contain
-information indicating that errors have been detected::
-
- EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0, channel 1 "DIMM_B1": amd76x_edac
- EDAC MC0: CE page 0x1e5, offset 0xfb0, grain 8, syndrome 0xb741, row 0, channel 1 "DIMM_B1": amd76x_edac
-
-
-The structure of the message is:
-
- +---------------------------------------+-------------+
- | Content | Example |
- +=======================================+=============+
- | The memory controller | MC0 |
- +---------------------------------------+-------------+
- | Error type | CE |
- +---------------------------------------+-------------+
- | Memory page | 0x283 |
- +---------------------------------------+-------------+
- | Offset in the page | 0xce0 |
- +---------------------------------------+-------------+
- | The byte granularity | grain 8 |
- | or resolution of the error | |
- +---------------------------------------+-------------+
- | The error syndrome | 0xb741 |
- +---------------------------------------+-------------+
- | Memory row | row 0 |
- +---------------------------------------+-------------+
- | Memory channel | channel 1 |
- +---------------------------------------+-------------+
- | DIMM label, if set prior | DIMM B1 |
- +---------------------------------------+-------------+
- | And then an optional, driver-specific | |
- | message that may have additional | |
- | information. | |
- +---------------------------------------+-------------+
-
-Both UEs and CEs with no info will lack all but memory controller, error
-type, a notice of "no info" and then an optional, driver-specific error
-message.
-
-
-PCI Bus Parity Detection
-------------------------
-
-On Header Type 00 devices, the primary status is looked at for any
-parity error regardless of whether parity is enabled on the device or
-not. (The spec indicates parity is generated in some cases). On Header
-Type 01 bridges, the secondary status register is also looked at to see
-if parity occurred on the bus on the other side of the bridge.
-
-
-Sysfs configuration
--------------------
-
-Under ``/sys/devices/system/edac/pci`` are control and attribute files as
-follows:
-
-
-- ``check_pci_parity`` - Enable/Disable PCI Parity checking control file
-
- This control file enables or disables the PCI Bus Parity scanning
- operation. Writing a 1 to this file enables the scanning. Writing
- a 0 to this file disables the scanning.
-
- Enable::
-
- echo "1" >/sys/devices/system/edac/pci/check_pci_parity
-
- Disable::
-
- echo "0" >/sys/devices/system/edac/pci/check_pci_parity
-
-
-- ``pci_parity_count`` - Parity Count
-
- This attribute file will display the number of parity errors that
- have been detected.
-
-
-Module parameters
------------------
-
-- ``edac_mc_panic_on_ue`` - Panic on UE control file
-
- An uncorrectable error will cause a machine panic. This is usually
- desirable. It is a bad idea to continue when an uncorrectable error
- occurs - it is indeterminate what was uncorrected and the operating
- system context might be so mangled that continuing will lead to further
- corruption. If the kernel has MCE configured, then EDAC will never
- notice the UE.
-
- LOAD TIME::
-
- module/kernel parameter: edac_mc_panic_on_ue=[0|1]
-
- RUN TIME::
-
- echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue
-
-
-- ``edac_mc_log_ue`` - Log UE control file
-
-
- Generate kernel messages describing uncorrectable errors. These errors
- are reported through the system message log system. UE statistics
- will be accumulated even when UE logging is disabled.
-
- LOAD TIME::
-
- module/kernel parameter: edac_mc_log_ue=[0|1]
-
- RUN TIME::
-
- echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue
-
-
-- ``edac_mc_log_ce`` - Log CE control file
-
-
- Generate kernel messages describing correctable errors. These
- errors are reported through the system message log system.
- CE statistics will be accumulated even when CE logging is disabled.
-
- LOAD TIME::
-
- module/kernel parameter: edac_mc_log_ce=[0|1]
-
- RUN TIME::
-
- echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce
-
-
-- ``edac_mc_poll_msec`` - Polling period control file
-
-
- The time period, in milliseconds, for polling for error information.
- Too small a value wastes resources. Too large a value might delay
- necessary handling of errors and might loose valuable information for
- locating the error. 1000 milliseconds (once each second) is the current
- default. Systems which require all the bandwidth they can get, may
- increase this.
-
- LOAD TIME::
-
- module/kernel parameter: edac_mc_poll_msec=[0|1]
-
- RUN TIME::
-
- echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec
-
-
-- ``panic_on_pci_parity`` - Panic on PCI PARITY Error
-
-
- This control file enables or disables panicking when a parity
- error has been detected.
-
-
- module/kernel parameter::
-
- edac_panic_on_pci_pe=[0|1]
-
- Enable::
-
- echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
-
- Disable::
-
- echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe
-
-
-
-EDAC device type
-----------------
-
-In the header file, edac_pci.h, there is a series of edac_device structures
-and APIs for the EDAC_DEVICE.
-
-User space access to an edac_device is through the sysfs interface.
-
-At the location ``/sys/devices/system/edac`` (sysfs) new edac_device devices
-will appear.
-
-There is a three level tree beneath the above ``edac`` directory. For example,
-the ``test_device_edac`` device (found at the http://bluesmoke.sourceforget.net
-website) installs itself as::
-
- /sys/devices/system/edac/test-instance
-
-in this directory are various controls, a symlink and one or more ``instance``
-directories.
-
-The standard default controls are:
-
- ============== =======================================================
- log_ce boolean to log CE events
- log_ue boolean to log UE events
- panic_on_ue boolean to ``panic`` the system if an UE is encountered
- (default off, can be set true via startup script)
- poll_msec time period between POLL cycles for events
- ============== =======================================================
-
-The test_device_edac device adds at least one of its own custom control:
-
- ============== ==================================================
- test_bits which in the current test driver does nothing but
- show how it is installed. A ported driver can
- add one or more such controls and/or attributes
- for specific uses.
- One out-of-tree driver uses controls here to allow
- for ERROR INJECTION operations to hardware
- injection registers
- ============== ==================================================
-
-The symlink points to the 'struct dev' that is registered for this edac_device.
-
-Instances
----------
-
-One or more instance directories are present. For the ``test_device_edac``
-case:
-
- +----------------+
- | test-instance0 |
- +----------------+
-
-
-In this directory there are two default counter attributes, which are totals of
-counter in deeper subdirectories.
-
- ============== ====================================
- ce_count total of CE events of subdirectories
- ue_count total of UE events of subdirectories
- ============== ====================================
-
-Blocks
-------
-
-At the lowest directory level is the ``block`` directory. There can be 0, 1
-or more blocks specified in each instance:
-
- +-------------+
- | test-block0 |
- +-------------+
-
-In this directory the default attributes are:
-
- ============== ================================================
- ce_count which is counter of CE events for this ``block``
- of hardware being monitored
- ue_count which is counter of UE events for this ``block``
- of hardware being monitored
- ============== ================================================
-
-
-The ``test_device_edac`` device adds 4 attributes and 1 control:
-
- ================== ====================================================
- test-block-bits-0 for every POLL cycle this counter
- is incremented
- test-block-bits-1 every 10 cycles, this counter is bumped once,
- and test-block-bits-0 is set to 0
- test-block-bits-2 every 100 cycles, this counter is bumped once,
- and test-block-bits-1 is set to 0
- test-block-bits-3 every 1000 cycles, this counter is bumped once,
- and test-block-bits-2 is set to 0
- ================== ====================================================
-
-
- ================== ====================================================
- reset-counters writing ANY thing to this control will
- reset all the above counters.
- ================== ====================================================
-
-
-Use of the ``test_device_edac`` driver should enable any others to create their own
-unique drivers for their hardware systems.
-
-The ``test_device_edac`` sample driver is located at the
-http://bluesmoke.sourceforge.net project site for EDAC.
-
-
-Usage of EDAC APIs on Nehalem and newer Intel CPUs
---------------------------------------------------
-
-On older Intel architectures, the memory controller was part of the North
-Bridge chipset. Nehalem, Sandy Bridge, Ivy Bridge, Haswell, Sky Lake and
-newer Intel architectures integrated an enhanced version of the memory
-controller (MC) inside the CPUs.
-
-This chapter will cover the differences of the enhanced memory controllers
-found on newer Intel CPUs, such as ``i7core_edac``, ``sb_edac`` and
-``sbx_edac`` drivers.
-
-.. note::
-
- The Xeon E7 processor families use a separate chip for the memory
- controller, called Intel Scalable Memory Buffer. This section doesn't
- apply for such families.
-
-1) There is one Memory Controller per Quick Patch Interconnect
- (QPI). At the driver, the term "socket" means one QPI. This is
- associated with a physical CPU socket.
-
- Each MC have 3 physical read channels, 3 physical write channels and
- 3 logic channels. The driver currently sees it as just 3 channels.
- Each channel can have up to 3 DIMMs.
-
- The minimum known unity is DIMMs. There are no information about csrows.
- As EDAC API maps the minimum unity is csrows, the driver sequentially
- maps channel/DIMM into different csrows.
-
- For example, supposing the following layout::
-
- Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
- dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
- dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
- Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
- dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
- Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
- dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
-
- The driver will map it as::
-
- csrow0: channel 0, dimm0
- csrow1: channel 0, dimm1
- csrow2: channel 1, dimm0
- csrow3: channel 2, dimm0
-
- exports one DIMM per csrow.
-
- Each QPI is exported as a different memory controller.
-
-2) The MC has the ability to inject errors to test drivers. The drivers
- implement this functionality via some error injection nodes:
-
- For injecting a memory error, there are some sysfs nodes, under
- ``/sys/devices/system/edac/mc/mc?/``:
-
- - ``inject_addrmatch/*``:
- Controls the error injection mask register. It is possible to specify
- several characteristics of the address to match an error code::
-
- dimm = the affected dimm. Numbers are relative to a channel;
- rank = the memory rank;
- channel = the channel that will generate an error;
- bank = the affected bank;
- page = the page address;
- column (or col) = the address column.
-
- each of the above values can be set to "any" to match any valid value.
-
- At driver init, all values are set to any.
-
- For example, to generate an error at rank 1 of dimm 2, for any channel,
- any bank, any page, any column::
-
- echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
- echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
-
- To return to the default behaviour of matching any, you can do::
-
- echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
- echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
-
- - ``inject_eccmask``:
- specifies what bits will have troubles,
-
- - ``inject_section``:
- specifies what ECC cache section will get the error::
-
- 3 for both
- 2 for the highest
- 1 for the lowest
-
- - ``inject_type``:
- specifies the type of error, being a combination of the following bits::
-
- bit 0 - repeat
- bit 1 - ecc
- bit 2 - parity
-
- - ``inject_enable``:
- starts the error generation when something different than 0 is written.
-
- All inject vars can be read. root permission is needed for write.
-
- Datasheet states that the error will only be generated after a write on an
- address that matches inject_addrmatch. It seems, however, that reading will
- also produce an error.
-
- For example, the following code will generate an error for any write access
- at socket 0, on any DIMM/address on channel 2::
-
- echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
- echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
- echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
- echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
- echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
- dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
-
- For socket 1, it is needed to replace "mc0" by "mc1" at the above
- commands.
-
- The generated error message will look like::
-
- EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
-
-3) Corrected Error memory register counters
-
- Those newer MCs have some registers to count memory errors. The driver
- uses those registers to report Corrected Errors on devices with Registered
- DIMMs.
-
- However, those counters don't work with Unregistered DIMM. As the chipset
- offers some counters that also work with UDIMMs (but with a worse level of
- granularity than the default ones), the driver exposes those registers for
- UDIMM memories.
-
- They can be read by looking at the contents of ``all_channel_counts/``::
-
- $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
- /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
- 0
- /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
- 0
- /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
- 0
-
- What happens here is that errors on different csrows, but at the same
- dimm number will increment the same counter.
- So, in this memory mapping::
-
- csrow0: channel 0, dimm0
- csrow1: channel 0, dimm1
- csrow2: channel 1, dimm0
- csrow3: channel 2, dimm0
-
- The hardware will increment udimm0 for an error at the first dimm at either
- csrow0, csrow2 or csrow3;
-
- The hardware will increment udimm1 for an error at the second dimm at either
- csrow0, csrow2 or csrow3;
-
- The hardware will increment udimm2 for an error at the third dimm at either
- csrow0, csrow2 or csrow3;
-
-4) Standard error counters
-
- The standard error counters are generated when an mcelog error is received
- by the driver. Since, with UDIMM, this is counted by software, it is
- possible that some errors could be lost. With RDIMM's, they display the
- contents of the registers
-
-Reference documents used on ``amd64_edac``
-------------------------------------------
-
-``amd64_edac`` module is based on the following documents
-(available from http://support.amd.com/en-us/search/tech-docs):
-
-1. :Title: BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD
- Opteron Processors
- :AMD publication #: 26094
- :Revision: 3.26
- :Link: http://support.amd.com/TechDocs/26094.PDF
-
-2. :Title: BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh
- Processors
- :AMD publication #: 32559
- :Revision: 3.00
- :Issue Date: May 2006
- :Link: http://support.amd.com/TechDocs/32559.pdf
-
-3. :Title: BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h
- Processors
- :AMD publication #: 31116
- :Revision: 3.00
- :Issue Date: September 07, 2007
- :Link: http://support.amd.com/TechDocs/31116.pdf
-
-4. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
- Models 30h-3Fh Processors
- :AMD publication #: 49125
- :Revision: 3.06
- :Issue Date: 2/12/2015 (latest release)
- :Link: http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf
-
-5. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h
- Models 60h-6Fh Processors
- :AMD publication #: 50742
- :Revision: 3.01
- :Issue Date: 7/23/2015 (latest release)
- :Link: http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
-
-6. :Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h
- Models 00h-0Fh Processors
- :AMD publication #: 48751
- :Revision: 3.03
- :Issue Date: 2/23/2015 (latest release)
- :Link: http://support.amd.com/TechDocs/48751_16h_bkdg.pdf
-
-Credits
-=======
-
-* Written by Doug Thompson <dougthompson@xmission.com>
-
- - 7 Dec 2005
- - 17 Jul 2007 Updated
-
-* |copy| Mauro Carvalho Chehab
-
- - 05 Aug 2009 Nehalem interface
- - 26 Oct 2016 Converted to ReST and cleanups at the Nehalem section
-
-* EDAC authors/maintainers:
-
- - Doug Thompson, Dave Jiang, Dave Peterson et al,
- - Mauro Carvalho Chehab
- - Borislav Petkov
- - original author: Thayne Harbaugh
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index ec62151fe672..a68e6d909274 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -41,7 +41,7 @@ If you are facing multiple issues with the Linux kernel at once, report each
separately. While writing your report, include all information relevant to the
issue, like the kernel and the distro used. In case of a regression, CC the
regressions mailing list (regressions@lists.linux.dev) to your report. Also try
-to pin-point the culprit with a bisection; if you succeed, include its
+to pinpoint the culprit with a bisection; if you succeed, include its
commit-id and CC everyone in the sign-off-by chain.
Once the report is out, answer any questions that come up and help where you
@@ -206,7 +206,7 @@ Reporting issues only occurring in older kernel version lines
This subsection is for you, if you tried the latest mainline kernel as outlined
above, but failed to reproduce your issue there; at the same time you want to
see the issue fixed in a still supported stable or longterm series or vendor
-kernels regularly rebased on those. If that the case, follow these steps:
+kernels regularly rebased on those. If that is the case, follow these steps:
* Prepare yourself for the possibility that going through the next few steps
might not get the issue solved in older releases: the fix might be too big
@@ -312,7 +312,7 @@ small modifications to a kernel based on a recent Linux version; that for
example often holds true for the mainline kernels shipped by Debian GNU/Linux
Sid or Fedora Rawhide. Some developers will also accept reports about issues
with kernels from distributions shipping the latest stable kernel, as long as
-its only slightly modified; that for example is often the case for Arch Linux,
+it's only slightly modified; that for example is often the case for Arch Linux,
regular Fedora releases, and openSUSE Tumbleweed. But keep in mind, you better
want to use a mainline Linux and avoid using a stable kernel for this
process, as outlined in the section 'Install a fresh kernel for testing' in more
@@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the
list of tracked regressions, to ensure it won't fall through the cracks.
What qualifies as security issue is left to your judgment. Consider reading
-Documentation/admin-guide/security-bugs.rst before proceeding, as it
+Documentation/process/security-bugs.rst before proceeding, as it
provides additional details how to best handle security issues.
An issue is a 'really severe problem' when something totally unacceptably bad
@@ -611,7 +611,7 @@ better place.
How to read the MAINTAINERS file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To illustrate how to use the :ref:`MAINTAINERS <maintainers>` file, lets assume
+To illustrate how to use the :ref:`MAINTAINERS <maintainers>` file, let's assume
the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that
case it's likely an issue in the WiFi driver. Obviously it could also be some
code it builds upon, but unless you suspect something like that stick to the
@@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
the report's text to these addresses; but on top of it put a small note where
you mention that you filed it with a link to the ticket.
-See Documentation/admin-guide/security-bugs.rst for more information.
+See Documentation/process/security-bugs.rst for more information.
Duties after the report went out
@@ -1543,7 +1543,7 @@ as well, because that will speed things up.
And note, it helps developers a great deal if you can specify the exact version
that introduced the problem. Hence if possible within a reasonable time frame,
-try to find that version using vanilla kernels. Lets assume something broke when
+try to find that version using vanilla kernels. Let's assume something broke when
your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
instructed above go and check the latest kernel from that version line, say
5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches
diff --git a/Documentation/admin-guide/reporting-regressions.rst b/Documentation/admin-guide/reporting-regressions.rst
index d8adccdae23f..946518355a2c 100644
--- a/Documentation/admin-guide/reporting-regressions.rst
+++ b/Documentation/admin-guide/reporting-regressions.rst
@@ -31,7 +31,7 @@ The important bits (aka "TL;DR")
Linux kernel regression tracking bot "regzbot" track the issue by specifying
when the regression started like this::
- #regzbot introduced v5.13..v5.14-rc1
+ #regzbot introduced: v5.13..v5.14-rc1
All the details on Linux kernel regressions relevant for users
@@ -42,12 +42,12 @@ The important basics
--------------------
-What is a "regression" and what is the "no regressions rule"?
+What is a "regression" and what is the "no regressions" rule?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's a regression if some application or practical use case running fine with
one Linux kernel works worse or not at all with a newer version compiled using a
-similar configuration. The "no regressions rule" forbids this to take place; if
+similar configuration. The "no regressions" rule forbids this to take place; if
it happens by accident, developers that caused it are expected to quickly fix
the issue.
@@ -173,7 +173,7 @@ Additional details about regressions
------------------------------------
-What is the goal of the "no regressions rule"?
+What is the goal of the "no regressions" rule?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Users should feel safe when updating kernel versions and not have to worry
@@ -199,8 +199,8 @@ Exceptions to this rule are extremely rare; in the past developers almost always
turned out to be wrong when they assumed a particular situation was warranting
an exception.
-Who ensures the "no regressions" is actually followed?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Who ensures the "no regressions" rule is actually followed?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The subsystem maintainers should take care of that, which are watched and
supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
deleted file mode 100644
index 82e29837d589..000000000000
--- a/Documentation/admin-guide/security-bugs.rst
+++ /dev/null
@@ -1,96 +0,0 @@
-.. _securitybugs:
-
-Security bugs
-=============
-
-Linux kernel developers take security very seriously. As such, we'd
-like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible. Please report security bugs to the
-Linux kernel security team.
-
-Contact
--------
-
-The Linux kernel security team can be contacted by email at
-<security@kernel.org>. This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably. It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
-
-As it is with any bug, the more information provided the easier it
-will be to diagnose and fix. Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
-information is helpful. Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
-Please send plain text emails without attachments where possible.
-It is much harder to have a context-quoted discussion about a complex
-issue if all the details are hidden away in attachments. Think of it like a
-:doc:`regular patch submission <../process/submitting-patches>`
-(even if you don't have a patch yet): describe the problem and impact, list
-reproduction steps, and follow it with a proposed fix, all in plain text.
-
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel. For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts. Fixes
-for publicly known bugs are released immediately.
-
-Although our preference is to release fixes for publicly undisclosed bugs
-as soon as they become available, this may be postponed at the request of
-the reporter or an affected party for up to 7 calendar days from the start
-of the release process, with an exceptional extension to 14 calendar days
-if it is agreed that the criticality of the bug requires more time. The
-only valid reason for deferring the publication of a fix is to accommodate
-the logistics of QA and large scale rollouts which require release
-coordination.
-
-While embargoed information may be shared with trusted individuals in
-order to develop a fix, such information will not be published alongside
-the fix or on any other disclosure channel without the permission of the
-reporter. This includes but is not limited to the original bug report
-and followup discussions (if any), exploits, CVE information or the
-identity of the reporter.
-
-In other words our only interest is in getting bugs fixed. All other
-information submitted to the security list and any followup discussions
-of the report are treated confidentially even after the embargo has been
-lifted, in perpetuity.
-
-Coordination
-------------
-
-Fixes for sensitive bugs, such as those that might lead to privilege
-escalations, may need to be coordinated with the private
-<linux-distros@vs.openwall.org> mailing list so that distribution vendors
-are well prepared to issue a fixed kernel upon public disclosure of the
-upstream fix. Distros will need some time to test the proposed patch and
-will generally request at least a few days of embargo, and vendor update
-publication prefers to happen Tuesday through Thursday. When appropriate,
-the security team can assist with this coordination, or the reporter can
-include linux-distros from the start. In this case, remember to prefix
-the email Subject line with "[vs]" as described in the linux-distros wiki:
-<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
-
-CVE assignment
---------------
-
-The security team does not normally assign CVEs, nor do we require them
-for reports or fixes, as this can needlessly complicate the process and
-may delay the bug handling. If a reporter wishes to have a CVE identifier
-assigned ahead of public disclosure, they will need to contact the private
-linux-distros list, described above. When such a CVE identifier is known
-before a patch is provided, it is desirable to mention it in the commit
-message if the reporter agrees.
-
-Non-disclosure agreements
--------------------------
-
-The Linux kernel security team is not a formal body and therefore unable
-to enter any non-disclosure agreements.
diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst
index 58b32832e50a..1609e7479249 100644
--- a/Documentation/admin-guide/serial-console.rst
+++ b/Documentation/admin-guide/serial-console.rst
@@ -33,8 +33,11 @@ The format of this option is::
9600n8. The maximum baudrate is 115200.
You can specify multiple console= options on the kernel command line.
-Output will appear on all of them. The last device will be used when
-you open ``/dev/console``. So, for example::
+
+The behavior is well defined when each device type is mentioned only once.
+In this case, the output will appear on all requested consoles. And
+the last device will be used when you open ``/dev/console``.
+So, for example::
console=ttyS1,9600 console=tty0
@@ -42,13 +45,42 @@ defines that opening ``/dev/console`` will get you the current foreground
virtual console, and kernel messages will appear on both the VGA
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
-Note that you can only define one console per device type (serial, video).
+The behavior is more complicated when the same device type is defined more
+times. In this case, there are the following two rules:
+
+1. The output will appear only on the first device of each defined type.
+
+2. ``/dev/console`` will be associated with the first registered device.
+ Where the registration order depends on how kernel initializes various
+ subsystems.
+
+ This rule is used also when the last console= parameter is not used
+ for other reasons. For example, because of a typo or because
+ the hardware is not available.
+
+The result might be surprising. For example, the following two command
+lines have the same result::
+
+ console=ttyS1,9600 console=tty0 console=tty1
+ console=tty0 console=ttyS1,9600 console=tty1
+
+The kernel messages are printed only on ``tty0`` and ``ttyS1``. And
+``/dev/console`` gets associated with ``tty0``. It is because kernel
+tries to register graphical consoles before serial ones. It does it
+because of the default behavior when no console device is specified,
+see below.
+
+Note that the last ``console=tty1`` parameter still makes a difference.
+The kernel command line is used also by systemd. It would use the last
+defined ``tty1`` as the login console.
If no console device is specified, the first device found capable of
acting as a system console will be used. At this time, the system
first looks for a VGA card and then for a serial port. So if you don't
have a VGA card in your system the first serial port will automatically
-become the console.
+become the console, unless the kernel is configured with the
+CONFIG_NULL_TTY_DEFAULT_CONSOLE option, then it will default to using the
+ttynull device.
You will need to create a new device to use ``/dev/console``. The official
``/dev/console`` is now character device 5,1.
diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt
index 1265c1eab31c..0d5965138f8f 100644
--- a/Documentation/admin-guide/spkguide.txt
+++ b/Documentation/admin-guide/spkguide.txt
@@ -7,7 +7,7 @@ Last modified on Mon Sep 27 14:26:31 2010
Document version 1.3
Copyright (c) 2005 Gene Collins
-Copyright (c) 2008 Samuel Thibault
+Copyright (c) 2008, 2023 Samuel Thibault
Copyright (c) 2009, 2010 the Speakup Team
Permission is granted to copy, distribute and/or modify this document
@@ -83,8 +83,7 @@ spkout -- Speak Out
txprt -- Transport
dummy -- Plain text terminal
-Note: Speakup does * NOT * support usb connections! Speakup also does *
-NOT * support the internal Tripletalk!
+Note: Speakup does * NOT * support the internal Tripletalk!
Speakup does support two other synthesizers, but because they work in
conjunction with other software, they must be loaded as modules after
@@ -94,6 +93,12 @@ These are as follows:
decpc -- DecTalk PC (not available at boot up)
soft -- One of several software synthesizers (not available at boot up)
+By default speakup looks for the synthesizer on the ttyS0 serial port. This can
+be changed with the device parameter of the modules, for instance for
+DoubleTalk LT:
+
+speakup_ltlk.dev=ttyUSB0
+
See the sections on loading modules and software synthesizers later in
this manual for further details. It should be noted here that the
speakup.synth boot parameter will have no effect if Speakup has been
@@ -1105,8 +1110,8 @@ speakup load
Alternatively, you can add the above line to your file
~/.bashrc or ~/.bash_profile.
-If your system administrator ran himself the script, all the users will be able
-to change from English to the language choosed by root and do directly
+If your system administrator himself ran the script, all the users will be able
+to change from English to the language chosen by root and do directly
speakupconf load (or add this to the ~/.bashrc or
~/.bash_profile file). If there are several languages to handle, the
administrator (or every user) will have to run the first steps until speakupconf
diff --git a/Documentation/admin-guide/syscall-user-dispatch.rst b/Documentation/admin-guide/syscall-user-dispatch.rst
index 60314953c728..c1768d9e80fa 100644
--- a/Documentation/admin-guide/syscall-user-dispatch.rst
+++ b/Documentation/admin-guide/syscall-user-dispatch.rst
@@ -53,26 +53,35 @@ following prctl:
prctl(PR_SET_SYSCALL_USER_DISPATCH, <op>, <offset>, <length>, [selector])
-<op> is either PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF, to enable and
-disable the mechanism globally for that thread. When
-PR_SYS_DISPATCH_OFF is used, the other fields must be zero.
-
-[<offset>, <offset>+<length>) delimit a memory region interval
-from which syscalls are always executed directly, regardless of the
-userspace selector. This provides a fast path for the C library, which
-includes the most common syscall dispatchers in the native code
-applications, and also provides a way for the signal handler to return
+<op> is either PR_SYS_DISPATCH_EXCLUSIVE_ON/PR_SYS_DISPATCH_INCLUSIVE_ON
+or PR_SYS_DISPATCH_OFF, to enable and disable the mechanism globally for
+that thread. When PR_SYS_DISPATCH_OFF is used, the other fields must be zero.
+
+For PR_SYS_DISPATCH_EXCLUSIVE_ON [<offset>, <offset>+<length>) delimit
+a memory region interval from which syscalls are always executed directly,
+regardless of the userspace selector. This provides a fast path for the
+C library, which includes the most common syscall dispatchers in the native
+code applications, and also provides a way for the signal handler to return
without triggering a nested SIGSYS on (rt\_)sigreturn. Users of this
interface should make sure that at least the signal trampoline code is
included in this region. In addition, for syscalls that implement the
trampoline code on the vDSO, that trampoline is never intercepted.
+For PR_SYS_DISPATCH_INCLUSIVE_ON [<offset>, <offset>+<length>) delimit
+a memory region interval from which syscalls are dispatched based on
+the userspace selector. Syscalls from outside of the range are always
+executed directly.
+
[selector] is a pointer to a char-sized region in the process memory
region, that provides a quick way to enable disable syscall redirection
thread-wide, without the need to invoke the kernel directly. selector
can be set to SYSCALL_DISPATCH_FILTER_ALLOW or SYSCALL_DISPATCH_FILTER_BLOCK.
Any other value should terminate the program with a SIGSYS.
+Additionally, a tasks syscall user dispatch configuration can be peeked
+and poked via the PTRACE_(GET|SET)_SYSCALL_USER_DISPATCH_CONFIG ptrace
+requests. This is useful for checkpoint/restart software.
+
Security Notes
--------------
diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst
index 2a501c9ddc55..9b7f65c3efd8 100644
--- a/Documentation/admin-guide/sysctl/fs.rst
+++ b/Documentation/admin-guide/sysctl/fs.rst
@@ -2,8 +2,6 @@
Documentation for /proc/sys/fs/
===============================
-kernel version 2.2.10
-
Copyright (c) 1998, 1999, Rik van Riel <riel@nl.linux.org>
Copyright (c) 2009, Shen Feng<shen@cn.fujitsu.com>
@@ -12,159 +10,135 @@ For general info and legal blurb, please look in intro.rst.
------------------------------------------------------------------------------
-This file contains documentation for the sysctl files in
-/proc/sys/fs/ and is valid for Linux kernel version 2.2.
+This file contains documentation for the sysctl files and directories
+in ``/proc/sys/fs/``.
The files in this directory can be used to tune and monitor
miscellaneous and general things in the operation of the Linux
-kernel. Since some of the files _can_ be used to screw up your
+kernel. Since some of the files *can* be used to screw up your
system, it is advisable to read both documentation and source
before actually making adjustments.
1. /proc/sys/fs
===============
-Currently, these files are in /proc/sys/fs:
-
-- aio-max-nr
-- aio-nr
-- dentry-state
-- dquot-max
-- dquot-nr
-- file-max
-- file-nr
-- inode-max
-- inode-nr
-- inode-state
-- nr_open
-- overflowuid
-- overflowgid
-- pipe-user-pages-hard
-- pipe-user-pages-soft
-- protected_fifos
-- protected_hardlinks
-- protected_regular
-- protected_symlinks
-- suid_dumpable
-- super-max
-- super-nr
+Currently, these files might (depending on your configuration)
+show up in ``/proc/sys/fs``:
+
+.. contents:: :local:
aio-nr & aio-max-nr
-------------------
-aio-nr is the running total of the number of events specified on the
-io_setup system call for all currently active aio contexts. If aio-nr
-reaches aio-max-nr then io_setup will fail with EAGAIN. Note that
-raising aio-max-nr does not result in the pre-allocation or re-sizing
-of any kernel data structures.
+``aio-nr`` shows the current system-wide number of asynchronous io
+requests. ``aio-max-nr`` allows you to change the maximum value
+``aio-nr`` can grow to. If ``aio-nr`` reaches ``aio-nr-max`` then
+``io_setup`` will fail with ``EAGAIN``. Note that raising
+``aio-max-nr`` does not result in the
+pre-allocation or re-sizing of any kernel data structures.
+dentry-negative
+----------------------------
+
+Policy for negative dentries. Set to 1 to always delete the dentry when a
+file is removed, and 0 to disable it. By default, this behavior is disabled.
dentry-state
------------
-From linux/include/linux/dcache.h::
+This file shows the values in ``struct dentry_stat_t``, as defined in
+``fs/dcache.c``::
struct dentry_stat_t dentry_stat {
- int nr_dentry;
- int nr_unused;
- int age_limit; /* age in seconds */
- int want_pages; /* pages requested by system */
- int nr_negative; /* # of unused negative dentries */
- int dummy; /* Reserved for future use */
+ long nr_dentry;
+ long nr_unused;
+ long age_limit; /* age in seconds */
+ long want_pages; /* pages requested by system */
+ long nr_negative; /* # of unused negative dentries */
+ long dummy; /* Reserved for future use */
};
Dentries are dynamically allocated and deallocated.
-nr_dentry shows the total number of dentries allocated (active
-+ unused). nr_unused shows the number of dentries that are not
+``nr_dentry`` shows the total number of dentries allocated (active
++ unused). ``nr_unused shows`` the number of dentries that are not
actively used, but are saved in the LRU list for future reuse.
-Age_limit is the age in seconds after which dcache entries
-can be reclaimed when memory is short and want_pages is
-nonzero when shrink_dcache_pages() has been called and the
+``age_limit`` is the age in seconds after which dcache entries
+can be reclaimed when memory is short and ``want_pages`` is
+nonzero when ``shrink_dcache_pages()`` has been called and the
dcache isn't pruned yet.
-nr_negative shows the number of unused dentries that are also
+``nr_negative`` shows the number of unused dentries that are also
negative dentries which do not map to any files. Instead,
they help speeding up rejection of non-existing files provided
by the users.
-dquot-max & dquot-nr
---------------------
-
-The file dquot-max shows the maximum number of cached disk
-quota entries.
-
-The file dquot-nr shows the number of allocated disk quota
-entries and the number of free disk quota entries.
-
-If the number of free cached disk quotas is very low and
-you have some awesome number of simultaneous system users,
-you might want to raise the limit.
-
-
file-max & file-nr
------------------
-The value in file-max denotes the maximum number of file-
+The value in ``file-max`` denotes the maximum number of file-
handles that the Linux kernel will allocate. When you get lots
of error messages about running out of file handles, you might
want to increase this limit.
Historically,the kernel was able to allocate file handles
dynamically, but not to free them again. The three values in
-file-nr denote the number of allocated file handles, the number
+``file-nr`` denote the number of allocated file handles, the number
of allocated but unused file handles, and the maximum number of
-file handles. Linux 2.6 always reports 0 as the number of free
+file handles. Linux 2.6 and later always reports 0 as the number of free
file handles -- this is not an error, it just means that the
number of allocated file handles exactly matches the number of
used file handles.
-Attempts to allocate more file descriptors than file-max are
-reported with printk, look for "VFS: file-max limit <number>
-reached".
+Attempts to allocate more file descriptors than ``file-max`` are
+reported with ``printk``, look for::
+ VFS: file-max limit <number> reached
-nr_open
--------
-
-This denotes the maximum number of file-handles a process can
-allocate. Default value is 1024*1024 (1048576) which should be
-enough for most machines. Actual limit depends on RLIMIT_NOFILE
-resource limit.
+in the kernel logs.
-inode-max, inode-nr & inode-state
----------------------------------
+inode-nr & inode-state
+----------------------
As with file handles, the kernel allocates the inode structures
dynamically, but can't free them yet.
-The value in inode-max denotes the maximum number of inode
-handlers. This value should be 3-4 times larger than the value
-in file-max, since stdin, stdout and network sockets also
-need an inode struct to handle them. When you regularly run
-out of inodes, you need to increase this value.
-
-The file inode-nr contains the first two items from
-inode-state, so we'll skip to that file...
+The file ``inode-nr`` contains the first two items from
+``inode-state``, so we'll skip to that file...
-Inode-state contains three actual numbers and four dummies.
-The actual numbers are, in order of appearance, nr_inodes,
-nr_free_inodes and preshrink.
+``inode-state`` contains three actual numbers and four dummies.
+The actual numbers are, in order of appearance, ``nr_inodes``,
+``nr_free_inodes`` and ``preshrink``.
-Nr_inodes stands for the number of inodes the system has
-allocated, this can be slightly more than inode-max because
-Linux allocates them one pageful at a time.
+``nr_inodes`` stands for the number of inodes the system has
+allocated.
-Nr_free_inodes represents the number of free inodes (?) and
-preshrink is nonzero when the nr_inodes > inode-max and the
+``nr_free_inodes`` represents the number of free inodes (?) and
+preshrink is nonzero when the
system needs to prune the inode list instead of allocating
more.
+mount-max
+---------
+
+This denotes the maximum number of mounts that may exist
+in a mount namespace.
+
+
+nr_open
+-------
+
+This denotes the maximum number of file-handles a process can
+allocate. Default value is 1024*1024 (1048576) which should be
+enough for most machines. Actual limit depends on ``RLIMIT_NOFILE``
+resource limit.
+
+
overflowgid & overflowuid
-------------------------
@@ -190,9 +164,9 @@ pipe-user-pages-soft
--------------------
Maximum total number of pages a non-privileged user may allocate for pipes
-before the pipe size gets limited to a single page. Once this limit is reached,
-new pipes will be limited to a single page in size for this user in order to
-limit total memory usage, and trying to increase them using fcntl() will be
+before the pipe size gets limited to two pages. Once this limit is reached,
+new pipes will be limited to two pages in size for this user in order to
+limit total memory usage, and trying to increase them using ``fcntl()`` will be
denied until usage goes below the limit again. The default value allows to
allocate up to 1024 pipes at their default size. When set to 0, no limit is
applied.
@@ -207,7 +181,7 @@ file.
When set to "0", writing to FIFOs is unrestricted.
-When set to "1" don't allow O_CREAT open on FIFOs that we don't own
+When set to "1" don't allow ``O_CREAT`` open on FIFOs that we don't own
in world writable sticky directories, unless they are owned by the
owner of the directory.
@@ -221,7 +195,7 @@ protected_hardlinks
A long-standing class of security issues is the hardlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
-directories like /tmp. The common method of exploitation of this flaw
+directories like ``/tmp``. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given hardlink (i.e. a
root process follows a hardlink created by another user). Additionally,
on systems without separated partitions, this stops unauthorized users
@@ -239,13 +213,13 @@ This protection is based on the restrictions in Openwall and grsecurity.
protected_regular
-----------------
-This protection is similar to protected_fifos, but it
+This protection is similar to `protected_fifos`_, but it
avoids writes to an attacker-controlled regular file, where a program
expected to create one.
When set to "0", writing to regular files is unrestricted.
-When set to "1" don't allow O_CREAT open on regular files that we
+When set to "1" don't allow ``O_CREAT`` open on regular files that we
don't own in world writable sticky directories, unless they are
owned by the owner of the directory.
@@ -257,7 +231,7 @@ protected_symlinks
A long-standing class of security issues is the symlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
-directories like /tmp. The common method of exploitation of this flaw
+directories like ``/tmp``. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
@@ -272,23 +246,25 @@ follower match, or when the directory owner matches the symlink's owner.
This protection is based on the restrictions in Openwall and grsecurity.
-suid_dumpable:
---------------
+suid_dumpable
+-------------
This value can be used to query and set the core dump mode for setuid
or otherwise protected/tainted binaries. The modes are
= ========== ===============================================================
-0 (default) traditional behaviour. Any process which has changed
+0 (default) Traditional behaviour. Any process which has changed
privilege levels or is execute only will not be dumped.
-1 (debug) all processes dump core when possible. The core dump is
+1 (debug) All processes dump core when possible. The core dump is
owned by the current user and no security is applied. This is
intended for system debugging situations only.
Ptrace is unchecked.
This is insecure as it allows regular users to examine the
memory contents of privileged processes.
-2 (suidsafe) any binary which normally would not be dumped is dumped
- anyway, but only if the "core_pattern" kernel sysctl is set to
+2 (suidsafe) Any binary which normally would not be dumped is dumped
+ anyway, but only if the ``core_pattern`` kernel sysctl (see
+ :ref:`Documentation/admin-guide/sysctl/kernel.rst <core_pattern>`)
+ is set to
either a pipe handler or a fully qualified path. (For more
details on this limitation, see CVE-2006-2451.) This mode is
appropriate when administrators are attempting to debug
@@ -301,36 +277,11 @@ or otherwise protected/tainted binaries. The modes are
= ========== ===============================================================
-super-max & super-nr
---------------------
-
-These numbers control the maximum number of superblocks, and
-thus the maximum number of mounted filesystems the kernel
-can have. You only need to increase super-max if you need to
-mount more filesystems than the current value in super-max
-allows you to.
-
-
-aio-nr & aio-max-nr
--------------------
-
-aio-nr shows the current system-wide number of asynchronous io
-requests. aio-max-nr allows you to change the maximum value
-aio-nr can grow to.
-
-
-mount-max
----------
-
-This denotes the maximum number of mounts that may exist
-in a mount namespace.
-
-
2. /proc/sys/fs/binfmt_misc
===========================
-Documentation for the files in /proc/sys/fs/binfmt_misc is
+Documentation for the files in ``/proc/sys/fs/binfmt_misc`` is
in Documentation/admin-guide/binfmt-misc.rst.
@@ -343,28 +294,32 @@ creation of a user space library that implements the POSIX message queues
API (as noted by the MSG tag in the POSIX 1003.1-2001 version of the System
Interfaces specification.)
-The "mqueue" filesystem contains values for determining/setting the amount of
-resources used by the file system.
+The "mqueue" filesystem contains values for determining/setting the
+amount of resources used by the file system.
-/proc/sys/fs/mqueue/queues_max is a read/write file for setting/getting the
-maximum number of message queues allowed on the system.
+``/proc/sys/fs/mqueue/queues_max`` is a read/write file for
+setting/getting the maximum number of message queues allowed on the
+system.
-/proc/sys/fs/mqueue/msg_max is a read/write file for setting/getting the
-maximum number of messages in a queue value. In fact it is the limiting value
-for another (user) limit which is set in mq_open invocation. This attribute of
-a queue must be less or equal then msg_max.
+``/proc/sys/fs/mqueue/msg_max`` is a read/write file for
+setting/getting the maximum number of messages in a queue value. In
+fact it is the limiting value for another (user) limit which is set in
+``mq_open`` invocation. This attribute of a queue must be less than
+or equal to ``msg_max``.
-/proc/sys/fs/mqueue/msgsize_max is a read/write file for setting/getting the
-maximum message size value (it is every message queue's attribute set during
-its creation).
+``/proc/sys/fs/mqueue/msgsize_max`` is a read/write file for
+setting/getting the maximum message size value (it is an attribute of
+every message queue, set during its creation).
-/proc/sys/fs/mqueue/msg_default is a read/write file for setting/getting the
-default number of messages in a queue value if attr parameter of mq_open(2) is
-NULL. If it exceed msg_max, the default value is initialized msg_max.
+``/proc/sys/fs/mqueue/msg_default`` is a read/write file for
+setting/getting the default number of messages in a queue value if the
+``attr`` parameter of ``mq_open(2)`` is ``NULL``. If it exceeds
+``msg_max``, the default value is initialized to ``msg_max``.
-/proc/sys/fs/mqueue/msgsize_default is a read/write file for setting/getting
-the default message size value if attr parameter of mq_open(2) is NULL. If it
-exceed msgsize_max, the default value is initialized msgsize_max.
+``/proc/sys/fs/mqueue/msgsize_default`` is a read/write file for
+setting/getting the default message size value if the ``attr``
+parameter of ``mq_open(2)`` is ``NULL``. If it exceeds
+``msgsize_max``, the default value is initialized to ``msgsize_max``.
4. /proc/sys/fs/epoll - Configuration options for the epoll interface
=====================================================================
@@ -378,7 +333,42 @@ Every epoll file descriptor can store a number of files to be monitored
for event readiness. Each one of these monitored files constitutes a "watch".
This configuration option sets the maximum number of "watches" that are
allowed for each user.
-Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes
-on a 64bit one.
-The current default value for max_user_watches is the 1/25 (4%) of the
-available low memory, divided for the "watch" cost in bytes.
+Each "watch" costs roughly 90 bytes on a 32-bit kernel, and roughly 160 bytes
+on a 64-bit one.
+The current default value for ``max_user_watches`` is 4% of the
+available low memory, divided by the "watch" cost in bytes.
+
+5. /proc/sys/fs/fuse - Configuration options for FUSE filesystems
+=====================================================================
+
+This directory contains the following configuration options for FUSE
+filesystems:
+
+``/proc/sys/fs/fuse/max_pages_limit`` is a read/write file for
+setting/getting the maximum number of pages that can be used for servicing
+requests in FUSE.
+
+``/proc/sys/fs/fuse/default_request_timeout`` is a read/write file for
+setting/getting the default timeout (in seconds) for a fuse server to
+reply to a kernel-issued request in the event where the server did not
+specify a timeout at mount. If the server set a timeout,
+then default_request_timeout will be ignored. The default
+"default_request_timeout" is set to 0. 0 indicates no default timeout.
+The maximum value that can be set is 65535.
+
+``/proc/sys/fs/fuse/max_request_timeout`` is a read/write file for
+setting/getting the maximum timeout (in seconds) for a fuse server to
+reply to a kernel-issued request. A value greater than 0 automatically opts
+the server into a timeout that will be set to at most "max_request_timeout",
+even if the server did not specify a timeout and default_request_timeout is
+set to 0. If max_request_timeout is greater than 0 and the server set a timeout
+greater than max_request_timeout or default_request_timeout is set to a value
+greater than max_request_timeout, the system will use max_request_timeout as the
+timeout. 0 indicates no max request timeout. The maximum value that can be set
+is 65535.
+
+For timeouts, if the server does not respond to the request by the time
+the set timeout elapses, then the connection to the fuse server will be aborted.
+Please note that the timeouts are not 100% precise (eg you may set 60 seconds but
+the timeout may kick in after 70 seconds). The upper margin of error for the
+timeout is roughly FUSE_TIMEOUT_TIMER_FREQ seconds.
diff --git a/Documentation/admin-guide/sysctl/index.rst b/Documentation/admin-guide/sysctl/index.rst
index 03346f98c7b9..4dd2c9b5d752 100644
--- a/Documentation/admin-guide/sysctl/index.rst
+++ b/Documentation/admin-guide/sysctl/index.rst
@@ -66,25 +66,31 @@ This documentation is about:
=============== ===============================================================
abi/ execution domains & personalities
-debug/ <empty>
-dev/ device specific information (eg dev/cdrom/info)
+<$ARCH> tuning controls for various CPU architecture (e.g. csky, s390)
+crypto/ <undocumented>
+debug/ <undocumented>
+dev/ device specific information (e.g. dev/cdrom/info)
fs/ specific filesystems
filehandle, inode, dentry and quota tuning
binfmt_misc <Documentation/admin-guide/binfmt-misc.rst>
kernel/ global kernel info / tuning
miscellaneous stuff
+ some architecture-specific controls
+ security (LSM) stuff
net/ networking stuff, for documentation look in:
<Documentation/networking/>
proc/ <empty>
sunrpc/ SUN Remote Procedure Call (NFS)
+user/ Per user namespace limits
vm/ memory management tuning
buffer and cache management
-user/ Per user per user namespace limits
+xen/ <undocumented>
=============== ===============================================================
-These are the subdirs I have on my system. There might be more
-or other subdirs in another setup. If you see another dir, I'd
-really like to hear about it :-)
+These are the subdirs I have on my system or have been discovered by
+searching through the source code. There might be more or other subdirs
+in another setup. If you see another dir, I'd really like to hear about
+it :-)
.. toctree::
:maxdepth: 1
diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index ee6572b1edad..239da22c4e28 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -65,6 +65,11 @@ combining the following values:
4 s3_beep
= =======
+arch
+====
+
+The machine hardware name, the same output as ``uname -m``
+(e.g. ``x86_64`` or ``aarch64``).
auto_msgmni
===========
@@ -90,7 +95,7 @@ is 0x15 and the full version number is 0x234, this file will contain
the value 340 = 0x154.
See the ``type_of_loader`` and ``ext_loader_type`` fields in
-Documentation/x86/boot.rst for additional information.
+Documentation/arch/x86/boot.rst for additional information.
bootloader_version (x86 only)
@@ -100,7 +105,7 @@ The complete bootloader version number. In the example above, this
file will contain the value 564 = 0x234.
See the ``type_of_loader`` and ``ext_loader_ver`` fields in
-Documentation/x86/boot.rst for additional information.
+Documentation/arch/x86/boot.rst for additional information.
bpf_stats_enabled
@@ -134,6 +139,8 @@ Highest valid capability of the running kernel. Exports
``CAP_LAST_CAP`` from the kernel.
+.. _core_pattern:
+
core_pattern
============
@@ -169,6 +176,8 @@ core_pattern
%f executable filename
%E executable path
%c maximum size of core file by resource limit RLIMIT_CORE
+ %C CPU the task ran on
+ %F pidfd number
%<OTHER> both are dropped
======== ==========================================
@@ -204,6 +213,17 @@ pid>/``).
This value defaults to 0.
+core_sort_vma
+=============
+
+The default coredump writes VMAs in address order. By setting
+``core_sort_vma`` to 1, VMAs will be written from smallest size
+to largest size. This is known to break at least elfutils, but
+can be handy when dealing with very large (and truncated)
+coredumps where the more useful debugging details are included
+in the smaller VMAs.
+
+
core_uses_pid
=============
@@ -288,12 +308,30 @@ kernel panic). This will output the contents of the ftrace buffers to
the console. This is very useful for capturing traces that lead to
crashes and outputting them to a serial console.
-= ===================================================
-0 Disabled (default).
-1 Dump buffers of all CPUs.
-2 Dump the buffer of the CPU that triggered the oops.
-= ===================================================
+======================= ===========================================
+0 Disabled (default).
+1 Dump buffers of all CPUs.
+2(orig_cpu) Dump the buffer of the CPU that triggered the
+ oops.
+<instance> Dump the specific instance buffer on all CPUs.
+<instance>=2(orig_cpu) Dump the specific instance buffer on the CPU
+ that triggered the oops.
+======================= ===========================================
+
+Multiple instance dump is also supported, and instances are separated
+by commas. If global buffer also needs to be dumped, please specify
+the dump mode (1/2/orig_cpu) first for global buffer.
+
+So for example to dump "foo" and "bar" instance buffer on all CPUs,
+user can::
+
+ echo "foo,bar" > /proc/sys/kernel/ftrace_dump_on_oops
+To dump global buffer and "foo" instance buffer on all
+CPUs along with the "bar" instance buffer on CPU that triggered the
+oops, user can::
+
+ echo "1,foo,bar=2" > /proc/sys/kernel/ftrace_dump_on_oops
ftrace_enabled, stack_tracer_enabled
====================================
@@ -359,13 +397,14 @@ a hung task is detected.
hung_task_panic
===============
-Controls the kernel's behavior when a hung task is detected.
+When set to a non-zero value, a kernel panic will be triggered if the
+number of hung tasks found during a single scan reaches this value.
This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.
-= =================================================
+= =======================================================
0 Continue operation. This is the default behavior.
-1 Panic immediately.
-= =================================================
+N Panic when N hung tasks are found during a single scan.
+= =======================================================
hung_task_check_count
@@ -375,6 +414,20 @@ The upper bound on the number of tasks that are checked.
This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.
+hung_task_detect_count
+======================
+
+Indicates the total number of tasks that have been detected as hung since
+the system boot.
+
+This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.
+
+hung_task_sys_info
+==================
+A comma separated list of extra system information to be dumped when
+hung task is detected, for example, "tasks,mem,timers,locks,...".
+Refer 'panic_sys_info' section below for more details.
+
hung_task_timeout_secs
======================
@@ -428,8 +481,8 @@ ignore-unaligned-usertrap
On architectures where unaligned accesses cause traps, and where this
feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN``;
-currently, ``arc`` and ``ia64``), controls whether all unaligned traps
-are logged.
+currently, ``arc``, ``parisc`` and ``loongarch``), controls whether all
+unaligned traps are logged.
= =============================================================
0 Log all unaligned accesses.
@@ -437,17 +490,53 @@ are logged.
setting.
= =============================================================
-See also `unaligned-trap`_ and `unaligned-dump-stack`_. On ``ia64``,
-this allows system administrators to override the
-``IA64_THREAD_UAC_NOPRINT`` ``prctl`` and avoid logs being flooded.
+See also `unaligned-trap`_.
+io_uring_disabled
+=================
+
+Prevents all processes from creating new io_uring instances. Enabling this
+shrinks the kernel's attack surface.
+
+= ======================================================================
+0 All processes can create io_uring instances as normal. This is the
+ default setting.
+1 io_uring creation is disabled (io_uring_setup() will fail with
+ -EPERM) for unprivileged processes not in the io_uring_group group.
+ Existing io_uring instances can still be used. See the
+ documentation for io_uring_group for more information.
+2 io_uring creation is disabled for all processes. io_uring_setup()
+ always fails with -EPERM. Existing io_uring instances can still be
+ used.
+= ======================================================================
+
+
+io_uring_group
+==============
+
+When io_uring_disabled is set to 1, a process must either be
+privileged (CAP_SYS_ADMIN) or be in the io_uring_group group in order
+to create an io_uring instance. If io_uring_group is set to -1 (the
+default), only processes with the CAP_SYS_ADMIN capability may create
+io_uring instances.
+
+
+kernel_sys_info
+===============
+A comma separated list of extra system information to be dumped when
+soft/hard lockup is detected, for example, "tasks,mem,timers,locks,...".
+Refer 'panic_sys_info' section below for more details.
+
+It serves as the default kernel control knob, which will take effect
+when a kernel module calls sys_info() with parameter==0.
kexec_load_disabled
===================
-A toggle indicating if the ``kexec_load`` syscall has been disabled.
-This value defaults to 0 (false: ``kexec_load`` enabled), but can be
-set to 1 (true: ``kexec_load`` disabled).
+A toggle indicating if the syscalls ``kexec_load`` and
+``kexec_file_load`` have been disabled.
+This value defaults to 0 (false: ``kexec_*load`` enabled), but can be
+set to 1 (true: ``kexec_*load`` disabled).
Once true, kexec can no longer be used, and the toggle cannot be set
back to false.
This allows a kexec image to be loaded before disabling the syscall,
@@ -455,6 +544,24 @@ allowing a system to set up (and later use) an image without it being
altered.
Generally used together with the `modules_disabled`_ sysctl.
+kexec_load_limit_panic
+======================
+
+This parameter specifies a limit to the number of times the syscalls
+``kexec_load`` and ``kexec_file_load`` can be called with a crash
+image. It can only be set with a more restrictive value than the
+current one.
+
+== ======================================================
+-1 Unlimited calls to kexec. This is the default setting.
+N Number of calls left.
+== ======================================================
+
+kexec_load_limit_reboot
+=======================
+
+Similar functionality as ``kexec_load_limit_panic``, but for a normal
+image.
kptr_restrict
=============
@@ -484,6 +591,11 @@ if leaking kernel pointer values to unprivileged users is a concern.
When ``kptr_restrict`` is set to 2, kernel pointers printed using
%pK will be replaced with 0s regardless of privileges.
+softlockup_sys_info & hardlockup_sys_info
+=========================================
+A comma separated list of extra system information to be dumped when
+soft/hard lockup is detected, for example, "tasks,mem,timers,locks,...".
+Refer 'panic_sys_info' section below for more details.
modprobe
========
@@ -541,6 +653,9 @@ default (``MSGMNB``).
``msgmni`` is the maximum number of IPC queues. 32000 by default
(``MSGMNI``).
+All of these parameters are set per ipc namespace. The maximum number of bytes
+in POSIX message queues is limited by ``RLIMIT_MSGQUEUE``. This limit is
+respected hierarchically in the each user namespace.
msg_next_id, sem_next_id, and shm_next_id (System V IPC)
========================================================
@@ -635,6 +750,17 @@ different types of memory (represented as different NUMA nodes) to
place the hot pages in the fast memory. This is implemented based on
unmapping and page fault too.
+numa_balancing_promote_rate_limit_MBps
+======================================
+
+Too high promotion/demotion throughput between different memory types
+may hurt application latency. This can be used to rate limit the
+promotion throughput. The per-node max promotion throughput in MB/s
+will be limited to be no more than the set value.
+
+A rule of thumb is to set this to less than 1/10 of the PMEM node
+write bandwidth.
+
oops_all_cpu_backtrace
======================
@@ -651,6 +777,15 @@ This is the default behavior.
an oops event is detected.
+oops_limit
+==========
+
+Number of kernel oopses after which the kernel should panic when
+``panic_on_oops`` is not set. Setting this to 0 disables checking
+the count. Setting this to 1 has the same effect as setting
+``panic_on_oops=1``. The default value is 10000.
+
+
osrelease, ostype & version
===========================
@@ -775,8 +910,9 @@ bit 1 print system memory info
bit 2 print timer info
bit 3 print locks info if ``CONFIG_LOCKDEP`` is on
bit 4 print ftrace buffer
-bit 5 print all printk messages in buffer
+bit 5 replay all kernel messages on consoles at the end of panic
bit 6 print all CPUs backtrace (if available in the arch)
+bit 7 print only tasks in uninterruptible (blocked) state
===== ============================================
So for example to print tasks and memory info on panic, user can::
@@ -784,6 +920,24 @@ So for example to print tasks and memory info on panic, user can::
echo 3 > /proc/sys/kernel/panic_print
+panic_sys_info
+==============
+
+A comma separated list of extra information to be dumped on panic,
+for example, "tasks,mem,timers,...". It is a human readable alternative
+to 'panic_print'. Possible values are:
+
+============= ===================================================
+tasks print all tasks info
+mem print system memory info
+timers print timers info
+locks print locks info if CONFIG_LOCKDEP is on
+ftrace print ftrace buffer
+all_bt print all CPUs backtrace (if available in the arch)
+blocked_tasks print only tasks in uninterruptible (blocked) state
+============= ===================================================
+
+
panic_on_rcu_stall
==================
@@ -894,16 +1048,31 @@ enabled, otherwise writing to this file will return ``-EBUSY``.
The default value is 8.
-perf_user_access (arm64 only)
-=================================
+perf_user_access (arm64 and riscv only)
+=======================================
-Controls user space access for reading perf event counters. When set to 1,
-user space can read performance monitor counter registers directly.
+Controls user space access for reading perf event counters.
-The default value is 0 (access disabled).
+* for arm64
+ The default value is 0 (access disabled).
-See Documentation/arm64/perf.rst for more information.
+ When set to 1, user space can read performance monitor counter registers
+ directly.
+ See Documentation/arch/arm64/perf.rst for more information.
+
+* for riscv
+ When set to 0, user space access is disabled.
+
+ The default value is 1, user space can read performance monitor counter
+ registers through perf, any direct access without perf intervention will trigger
+ an illegal instruction.
+
+ When set to 2, which enables legacy mode (user space has direct access to cycle
+ and insret CSRs only). Note that this legacy value is deprecated and will be
+ removed once all user space applications are fixed.
+
+ Note that the time CSR is always directly accessible to all modes.
pid_max
=======
@@ -976,7 +1145,8 @@ printk_ratelimit_burst
While long term we enforce one message per `printk_ratelimit`_
seconds, we do allow a burst of messages to pass through.
``printk_ratelimit_burst`` specifies the number of messages we can
-send before ratelimiting kicks in.
+send before ratelimiting kicks in. After `printk_ratelimit`_ seconds
+have elapsed, another burst of messages may be sent.
The default value is 10 messages.
@@ -1087,7 +1257,8 @@ automatically on platforms where it can run (that is,
platforms with asymmetric CPU topologies and having an Energy
Model available). If your platform happens to meet the
requirements for EAS but you do not want to use it, change
-this value to 0.
+this value to 0. On Non-EAS platforms, write operation fails and
+read doesn't return anything.
task_delayacct
===============
@@ -1181,15 +1352,20 @@ are doing anyway :)
shmall
======
-This parameter sets the total amount of shared memory pages that
-can be used system wide. Hence, ``shmall`` should always be at least
-``ceil(shmmax/PAGE_SIZE)``.
+This parameter sets the total amount of shared memory pages that can be used
+inside ipc namespace. The shared memory pages counting occurs for each ipc
+namespace separately and is not inherited. Hence, ``shmall`` should always be at
+least ``ceil(shmmax/PAGE_SIZE)``.
If you are not sure what the default ``PAGE_SIZE`` is on your Linux
system, you can run the following command::
# getconf PAGE_SIZE
+To reduce or disable the ability to allocate shared memory, you must create a
+new ipc namespace, set this parameter to the required value and prohibit the
+creation of a new ipc namespace in the current user namespace or cgroups can
+be used.
shmmax
======
@@ -1298,11 +1474,34 @@ watchdog work to be queued by the watchdog timer function, otherwise the NMI
watchdog — if enabled — can detect a hard lockup condition.
+split_lock_mitigate (x86 only)
+==============================
+
+On x86, each "split lock" imposes a system-wide performance penalty. On larger
+systems, large numbers of split locks from unprivileged users can result in
+denials of service to well-behaved and potentially more important users.
+
+The kernel mitigates these bad users by detecting split locks and imposing
+penalties: forcing them to wait and only allowing one core to execute split
+locks at a time.
+
+These mitigations can make those bad applications unbearably slow. Setting
+split_lock_mitigate=0 may restore some application performance, but will also
+increase system exposure to denial of service attacks from split lock users.
+
+= ===================================================================
+0 Disable the mitigation mode - just warns the split lock on kernel log
+ and exposes the system to denials of service from the split lockers.
+1 Enable the mitigation mode (this is the default) - penalizes the split
+ lockers with intentional performance degradation.
+= ===================================================================
+
+
stack_erasing
=============
This parameter can be used to control kernel stack erasing at the end
-of syscalls for kernels built with ``CONFIG_GCC_PLUGIN_STACKLEAK``.
+of syscalls for kernels built with ``CONFIG_KSTACK_ERASE``.
That erasing reduces the information which kernel stack leak bugs
can reveal and blocks some uninitialized stack variable attacks.
@@ -1310,7 +1509,7 @@ The tradeoff is the performance impact: on a single CPU system kernel
compilation sees a 1% slowdown, other systems and workloads may vary.
= ====================================================================
-0 Kernel stack erasing is disabled, STACKLEAK_METRICS are not updated.
+0 Kernel stack erasing is disabled, KSTACK_ERASE_METRICS are not updated.
1 Kernel stack erasing is enabled (default), it is performed before
returning to the userspace at the end of syscalls.
= ====================================================================
@@ -1392,6 +1591,13 @@ constant ``FUTEX_TID_MASK`` (0x3fffffff).
If a value outside of this range is written to ``threads-max`` an
``EINVAL`` error occurs.
+timer_migration
+===============
+
+When set to a non-zero value, attempt to migrate timers away from idle cpus to
+allow them to remain in low power states longer.
+
+Default is set (1).
traceoff_on_warning
===================
@@ -1420,29 +1626,13 @@ See Documentation/admin-guide/kernel-parameters.rst and
Documentation/trace/boottime-trace.rst.
-.. _unaligned-dump-stack:
-
-unaligned-dump-stack (ia64)
-===========================
-
-When logging unaligned accesses, controls whether the stack is
-dumped.
-
-= ===================================================
-0 Do not dump the stack. This is the default setting.
-1 Dump the stack.
-= ===================================================
-
-See also `ignore-unaligned-usertrap`_.
-
-
unaligned-trap
==============
On architectures where unaligned accesses cause traps, and where this
feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_ALLOW``; currently,
-``arc`` and ``parisc``), controls whether unaligned traps are caught
-and emulated (instead of failing).
+``arc``, ``parisc`` and ``loongarch``), controls whether unaligned traps
+are caught and emulated (instead of failing).
= ========================================================
0 Do not emulate unaligned accesses.
@@ -1484,6 +1674,16 @@ entry will default to 2 instead of 0.
2 Unprivileged calls to ``bpf()`` are disabled
= =============================================================
+
+warn_limit
+==========
+
+Number of kernel warnings after which the kernel should panic when
+``panic_on_warn`` is not set. Setting this to 0 disables checking
+the warning count. Setting this to 1 has the same effect as setting
+``panic_on_warn=1``. The default value is 0.
+
+
watchdog
========
diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
index 6394f5dc2303..369a738a6819 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -71,6 +71,8 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
- s390x
- riscv64
- riscv32
+ - loongarch64
+ - arc
And the older cBPF JIT supported on the following archs:
@@ -205,6 +207,19 @@ Will increase power usage.
Default: 0 (off)
+mem_pcpu_rsv
+------------
+
+Per-cpu reserved forward alloc cache size in page units. Default 1MB per CPU.
+
+bypass_prot_mem
+---------------
+
+Skip charging socket buffers to the global per-protocol memory
+accounting controlled by net.ipv4.tcp_mem, net.ipv4.udp_mem, etc.
+
+Default: 0 (off)
+
rmem_default
------------
@@ -215,6 +230,14 @@ rmem_max
The maximum receive socket buffer size in bytes.
+Default: 4194304
+
+rps_default_mask
+----------------
+
+The default RPS CPU mask used on newly created network devices. An empty
+mask means RPS disabled by default.
+
tstamp_allow_data
-----------------
Allow processes to receive tx timestamps looped together with the original
@@ -234,6 +257,8 @@ wmem_max
The maximum send socket buffer size in bytes.
+Default: 4194304
+
message_burst and message_cost
------------------------------
@@ -330,15 +355,18 @@ skb_defer_max
-------------
Max size (in skbs) of the per-cpu list of skbs being freed
-by the cpu which allocated them. Used by TCP stack so far.
+by the cpu which allocated them.
-Default: 64
+Default: 128
optmem_max
----------
Maximum ancillary buffer size allowed per socket. Ancillary data is a sequence
-of struct cmsghdr structures with appended data.
+of struct cmsghdr structures with appended data. TCP tx zerocopy also uses
+optmem_max as a limit for its internal structures.
+
+Default : 128 KB
fb_tunnels_only_for_init_net
----------------------------
@@ -380,12 +408,29 @@ Default : 0 (for compatibility reasons)
txrehash
--------
-Controls default hash rethink behaviour on listening socket when SO_TXREHASH
-option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt).
+Controls default hash rethink behaviour on socket when SO_TXREHASH option is set
+to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt).
If set to 1 (default), hash rethink is performed on listening socket.
If set to 0, hash rethink is not performed.
+txq_reselection_ms
+------------------
+
+Controls how often (in ms) a busy connected flow can select another tx queue.
+
+A resection is desirable when/if user thread has migrated and XPS
+would select a different queue. Same can occur without XPS
+if the flow hash has changed.
+
+But switching txq can introduce reorders, especially if the
+old queue is under high pressure. Modern TCP stacks deal
+well with reorders if they happen not too often.
+
+To disable this feature, set the value to 0.
+
+Default : 1000
+
gro_normal_batch
----------------
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 9b833e439f09..4d71211fdad8 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -28,6 +28,7 @@ Currently, these files are in /proc/sys/vm:
- compact_memory
- compaction_proactiveness
- compact_unevictable_allowed
+- defrag_mode
- dirty_background_bytes
- dirty_background_ratio
- dirty_bytes
@@ -36,6 +37,7 @@ Currently, these files are in /proc/sys/vm:
- dirtytime_expire_seconds
- dirty_writeback_centisecs
- drop_caches
+- enable_soft_offline
- extfrag_threshold
- highmem_is_dirtyable
- hugetlb_shm_group
@@ -43,6 +45,7 @@ Currently, these files are in /proc/sys/vm:
- legacy_va_layout
- lowmem_reserve_ratio
- max_map_count
+- mem_profiling (only if CONFIG_MEM_ALLOC_PROFILING=y)
- memory_failure_early_kill
- memory_failure_recovery
- min_free_kbytes
@@ -72,6 +75,7 @@ Currently, these files are in /proc/sys/vm:
- unprivileged_userfaultfd
- user_reserve_kbytes
- vfs_cache_pressure
+- vfs_cache_pressure_denom
- watermark_boost_factor
- watermark_scale_factor
- zone_reclaim_mode
@@ -128,6 +132,12 @@ to latency spikes in unsuspecting applications. The kernel employs
various heuristics to avoid wasting CPU cycles if it detects that
proactive compaction is not being effective.
+Setting the value above 80 will, in addition to lowering the acceptable level
+of fragmentation, make the compaction code more sensitive to increases in
+fragmentation, i.e. compaction will trigger more often, but reduce
+fragmentation by a smaller amount.
+This makes the fragmentation level more stable over time.
+
Be careful when setting it to extreme values like 100, as that may
cause excessive background compaction activity.
@@ -143,6 +153,14 @@ On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
to compaction, which would block the task from becoming active until the fault
is resolved.
+defrag_mode
+===========
+
+When set to 1, the page allocator tries harder to avoid fragmentation
+and maintain the ability to produce huge pages / higher-order pages.
+
+It is recommended to enable this right after boot, as fragmentation,
+once it occurred, can be long-lasting or even permanent.
dirty_background_bytes
======================
@@ -266,6 +284,43 @@ used::
These are informational only. They do not mean that anything is wrong
with your system. To disable them, echo 4 (bit 2) into drop_caches.
+enable_soft_offline
+===================
+Correctable memory errors are very common on servers. Soft-offline is kernel's
+solution for memory pages having (excessive) corrected memory errors.
+
+For different types of page, soft-offline has different behaviors / costs.
+
+- For a raw error page, soft-offline migrates the in-use page's content to
+ a new raw page.
+
+- For a page that is part of a transparent hugepage, soft-offline splits the
+ transparent hugepage into raw pages, then migrates only the raw error page.
+ As a result, user is transparently backed by 1 less hugepage, impacting
+ memory access performance.
+
+- For a page that is part of a HugeTLB hugepage, soft-offline first migrates
+ the entire HugeTLB hugepage, during which a free hugepage will be consumed
+ as migration target. Then the original hugepage is dissolved into raw
+ pages without compensation, reducing the capacity of the HugeTLB pool by 1.
+
+It is user's call to choose between reliability (staying away from fragile
+physical memory) vs performance / capacity implications in transparent and
+HugeTLB cases.
+
+For all architectures, enable_soft_offline controls whether to soft offline
+memory pages. When set to 1, kernel attempts to soft offline the pages
+whenever it thinks needed. When set to 0, kernel returns EOPNOTSUPP to
+the request to soft offline the pages. Its default value is 1.
+
+It is worth mentioning that after setting enable_soft_offline to 0, the
+following requests to soft offline pages will not be performed:
+
+- Request to soft offline pages from RAS Correctable Errors Collector.
+
+- On ARM, the request to soft offline pages from GHES driver.
+
+- On PARISC, the request to soft offline pages from Page Deallocation Table.
extfrag_threshold
=================
@@ -356,7 +411,7 @@ The lowmem_reserve_ratio is an array. You can see them by reading this file::
But, these values are not used directly. The kernel calculates # of protection
pages for each zones from them. These are shown as array of protection pages
-in /proc/zoneinfo like followings. (This is an example of x86-64 box).
+in /proc/zoneinfo like the following. (This is an example of x86-64 box).
Each zone has an array of protection pages like this::
Node 0, zone DMA
@@ -410,8 +465,8 @@ The minimum value is 1 (1/1 -> 100%). The value less than 1 completely
disables protection of the pages.
-max_map_count:
-==============
+max_map_count
+=============
This file contains the maximum number of memory map areas a process
may have. Memory map areas are used as a side-effect of calling
@@ -425,15 +480,30 @@ e.g., up to one or two maps per allocation.
The default value is 65530.
-memory_failure_early_kill:
-==========================
+mem_profiling
+==============
+
+Enable memory profiling (when CONFIG_MEM_ALLOC_PROFILING=y)
+
+1: Enable memory profiling.
+
+0: Disable memory profiling.
+
+Enabling memory profiling introduces a small performance overhead for all
+memory allocations.
+
+The default value depends on CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT.
+
+
+memory_failure_early_kill
+=========================
Control how to kill processes when uncorrected memory error (typically
a 2bit error in a memory module) is detected in the background by hardware
that cannot be handled by the kernel. In some cases (like the page
still having a valid copy on disk) the kernel will handle the failure
transparently without affecting any applications. But if there is
-no other uptodate copy of the data it will kill to prevent any data
+no other up-to-date copy of the data it will kill to prevent any data
corruptions from propagating.
1: Kill all processes that have the corrupted and not reloadable page mapped
@@ -742,8 +812,8 @@ overcommit_memory
This value contains a flag that enables memory overcommitment.
-When this flag is 0, the kernel attempts to estimate the amount
-of free memory left when userspace requests more memory.
+When this flag is 0, the kernel compares the userspace memory request
+size against total memory plus swap and rejects obvious overcommits.
When this flag is 1, the kernel pretends there is always enough
memory until it actually runs out.
@@ -926,6 +996,9 @@ calls without any restrictions.
The default value is 0.
+Another way to control permissions for userfaultfd is to use
+/dev/userfaultfd instead of userfaultfd(2). See
+Documentation/admin-guide/mm/userfaultfd.rst.
user_reserve_kbytes
===================
@@ -951,19 +1024,28 @@ vfs_cache_pressure
This percentage value controls the tendency of the kernel to reclaim
the memory which is used for caching of directory and inode objects.
-At the default value of vfs_cache_pressure=100 the kernel will attempt to
-reclaim dentries and inodes at a "fair" rate with respect to pagecache and
-swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
-to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
-never reclaim dentries and inodes due to memory pressure and this can easily
-lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
-causes the kernel to prefer to reclaim dentries and inodes.
+At the default value of vfs_cache_pressure=vfs_cache_pressure_denom the kernel
+will attempt to reclaim dentries and inodes at a "fair" rate with respect to
+pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the
+kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0,
+the kernel will never reclaim dentries and inodes due to memory pressure and
+this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure
+beyond vfs_cache_pressure_denom causes the kernel to prefer to reclaim dentries
+and inodes.
-Increasing vfs_cache_pressure significantly beyond 100 may have negative
-performance impact. Reclaim code needs to take various locks to find freeable
-directory and inode objects. With vfs_cache_pressure=1000, it will look for
-ten times more freeable objects than there are.
+Increasing vfs_cache_pressure significantly beyond vfs_cache_pressure_denom may
+have negative performance impact. Reclaim code needs to take various locks to
+find freeable directory and inode objects. When vfs_cache_pressure equals
+(10 * vfs_cache_pressure_denom), it will look for ten times more freeable
+objects than there are.
+
+Note: This setting should always be used together with vfs_cache_pressure_denom.
+
+vfs_cache_pressure_denom
+========================
+Defaults to 100 (minimum allowed value). Requires corresponding
+vfs_cache_pressure setting to take effect.
watermark_boost_factor
======================
diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/sysrq.rst
index 0a178ef0111d..9c7aa817adc7 100644
--- a/Documentation/admin-guide/sysrq.rst
+++ b/Documentation/admin-guide/sysrq.rst
@@ -49,37 +49,46 @@ How do I use the magic SysRq key?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On x86
- You press the key combo :kbd:`ALT-SysRq-<command key>`.
+ You press the key combo `ALT-SysRq-<command key>`.
.. note::
Some
keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is
also known as the 'Print Screen' key. Also some keyboards cannot
handle so many keys being pressed at the same time, so you might
- have better luck with press :kbd:`Alt`, press :kbd:`SysRq`,
- release :kbd:`SysRq`, press :kbd:`<command key>`, release everything.
+ have better luck with press `Alt`, press `SysRq`,
+ release `SysRq`, press `<command key>`, release everything.
On SPARC
- You press :kbd:`ALT-STOP-<command key>`, I believe.
+ You press `ALT-STOP-<command key>`, I believe.
On the serial console (PC style standard serial ports only)
You send a ``BREAK``, then within 5 seconds a command key. Sending
``BREAK`` twice is interpreted as a normal BREAK.
On PowerPC
- Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`.
- :kbd:`Print Screen` (or :kbd:`F13`) - :kbd:`<command key>` may suffice.
+ Press `ALT - Print Screen` (or `F13`) - `<command key>`.
+ `Print Screen` (or `F13`) - `<command key>` may suffice.
On other
If you know of the key combos for other architectures, please
submit a patch to be included in this section.
On all
- Write a character to /proc/sysrq-trigger. e.g.::
+ Write a single character to /proc/sysrq-trigger.
+ Only the first character is processed, the rest of the string is
+ ignored. However, it is not recommended to write any extra characters
+ as the behavior is undefined and might change in the future versions.
+ E.g.::
echo t > /proc/sysrq-trigger
-The :kbd:`<command key>` is case sensitive.
+ Alternatively, write multiple characters prepended by underscore.
+ This way, all characters will be processed. E.g.::
+
+ echo _reisub > /proc/sysrq-trigger
+
+The `<command key>` is case sensitive.
What are the 'command' keys?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -138,7 +147,7 @@ Command Function
``v`` Forcefully restores framebuffer console
``v`` Causes ETM buffer dump [ARM-specific]
-``w`` Dumps tasks that are in uninterruptable (blocked) state.
+``w`` Dumps tasks that are in uninterruptible (blocked) state.
``x`` Used by xmon interface on ppc/powerpc platforms.
Show global PMU Registers on sparc64.
@@ -152,6 +161,8 @@ Command Function
will be printed to your console. (``0``, for example would make
it so that only emergency messages like PANICs or OOPSes would
make it to your console.)
+
+``R`` Replay the kernel log messages on consoles.
=========== ===================================================================
Okay, so what can I use them for?
@@ -202,14 +213,21 @@ processes.
"just thaw ``it(j)``" is useful if your system becomes unresponsive due to a
frozen (probably root) filesystem via the FIFREEZE ioctl.
+``Replay logs(R)`` is useful to view the kernel log messages when system is hung
+or you are not able to use dmesg command to view the messages in printk buffer.
+User may have to press the key combination multiple times if console system is
+busy. If it is completely locked up, then messages won't be printed. Output
+messages depend on current console loglevel, which can be modified using
+sysrq[0-9] (see above).
+
Sometimes SysRq seems to get 'stuck' after using it, what can I do?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When this happens, try tapping shift, alt and control on both sides of the
keyboard, and hitting an invalid sysrq sequence again. (i.e., something like
-:kbd:`alt-sysrq-z`).
+`alt-sysrq-z`).
-Switching to another virtual console (:kbd:`ALT+Fn`) and then back again
+Switching to another virtual console (`ALT+Fn`) and then back again
should also help.
I hit SysRq, but nothing seems to happen, what's wrong?
@@ -272,7 +290,7 @@ exception the header line from the sysrq command is passed to all console
consumers as if the current loglevel was maximum. If only the header
is emitted it is almost certain that the kernel loglevel is too low.
Should you require the output on the console channel then you will need
-to temporarily up the console loglevel using :kbd:`alt-sysrq-8` or::
+to temporarily up the console loglevel using `alt-sysrq-8` or::
echo 8 > /proc/sysrq-trigger
diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
index 92a8a07f5c43..ed1f8f1e86c5 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -34,7 +34,7 @@ name of the command ('Comm:') that triggered the event::
You'll find a 'Not tainted: ' there if the kernel was not tainted at the
time of the event; if it was, then it will print 'Tainted: ' and characters
-either letters or blanks. In above example it looks like this::
+either letters or blanks. In the example above it looks like this::
Tainted: P W O
@@ -52,7 +52,7 @@ At runtime, you can query the tainted state by reading
tainted; any other number indicates the reasons why it is. The easiest way to
decode that number is the script ``tools/debugging/kernel-chktaint``, which your
distribution might ship as part of a package called ``linux-tools`` or
-``kernel-tools``; if it doesn't you can download the script from
+``kernel-tools``; if it doesn't, you can download the script from
`git.kernel.org <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/tools/debugging/kernel-chktaint>`_
and execute it with ``sh kernel-chktaint``, which would print something like
this on the machine that had the statements in the logs that were quoted earlier::
@@ -101,6 +101,7 @@ Bit Log Number Reason that got the kernel tainted
16 _/X 65536 auxiliary taint, defined for and used by distros
17 _/T 131072 kernel was built with the struct randomization plugin
18 _/N 262144 an in-kernel test has been run
+ 19 _/J 524288 userspace used a mutating debug operation in fwctl
=== === ====== ========================================================
Note: The character ``_`` is representing a blank in this table to make reading
@@ -182,3 +183,9 @@ More detailed explanation for tainting
produce extremely unusual kernel structure layouts (even performance
pathological ones), which is important to know when debugging. Set at
build time.
+
+ 18) ``N`` if an in-kernel test, such as a KUnit test, has been run.
+
+ 19) ``J`` if userspace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE
+ to use the devices debugging features. Device debugging features could
+ cause the device to malfunction in undefined ways.
diff --git a/Documentation/admin-guide/thermal/index.rst b/Documentation/admin-guide/thermal/index.rst
new file mode 100644
index 000000000000..e48bc0a1951b
--- /dev/null
+++ b/Documentation/admin-guide/thermal/index.rst
@@ -0,0 +1,9 @@
+=================
+Thermal Subsystem
+=================
+
+.. toctree::
+ :maxdepth: 1
+
+ intel_powerclamp
+ intel_thermal_throttle
diff --git a/Documentation/driver-api/thermal/intel_powerclamp.rst b/Documentation/admin-guide/thermal/intel_powerclamp.rst
index 3f6dfb0b3ea6..08509b978af4 100644
--- a/Documentation/driver-api/thermal/intel_powerclamp.rst
+++ b/Documentation/admin-guide/thermal/intel_powerclamp.rst
@@ -26,6 +26,8 @@ By:
- Generic Thermal Layer (sysfs)
- Kernel APIs (TBD)
+ (*) Module Parameters
+
INTRODUCTION
============
@@ -85,7 +87,7 @@ migrated, unless the CPU is taken offline. In this case, threads
belong to the offlined CPUs will be terminated immediately.
Running as SCHED_FIFO and relatively high priority, also allows such
-scheme to work for both preemptable and non-preemptable kernels.
+scheme to work for both preemptible and non-preemptible kernels.
Alignment of idle time around jiffies ensures scalability for HZ
values. This effect can be better visualized using a Perf timechart.
The following diagram shows the behavior of kernel thread
@@ -153,13 +155,15 @@ b) determine the amount of compensation needed at each target ratio
Compensation to each target ratio consists of two parts:
a) steady state error compensation
- This is to offset the error occurring when the system can
- enter idle without extra wakeups (such as external interrupts).
+
+ This is to offset the error occurring when the system can
+ enter idle without extra wakeups (such as external interrupts).
b) dynamic error compensation
- When an excessive amount of wakeups occurs during idle, an
- additional idle ratio can be added to quiet interrupts, by
- slowing down CPU activities.
+
+ When an excessive amount of wakeups occurs during idle, an
+ additional idle ratio can be added to quiet interrupts, by
+ slowing down CPU activities.
A debugfs file is provided for the user to examine compensation
progress and results, such as on a Westmere system::
@@ -281,6 +285,7 @@ cur_state returns value -1 instead of 0 which is to avoid confusing
100% busy state with the disabled state.
Example usage:
+
- To inject 25% idle time::
$ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
@@ -318,3 +323,23 @@ device, a PID based userspace thermal controller can manage to
control CPU temperature effectively, when no other thermal influence
is added. For example, a UltraBook user can compile the kernel under
certain temperature (below most active trip points).
+
+Module Parameters
+=================
+
+``cpumask`` (RW)
+ A bit mask of CPUs to inject idle. The format of the bitmask is same as
+ used in other subsystems like in /proc/irq/\*/smp_affinity. The mask is
+ comma separated 32 bit groups. Each CPU is one bit. For example for a 256
+ CPU system the full mask is:
+ ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
+
+ The rightmost mask is for CPU 0-32.
+
+``max_idle`` (RW)
+ Maximum injected idle time to the total CPU time ratio in percent range
+ from 1 to 100. Even if the cooling device max_state is always 100 (100%),
+ this parameter allows to add a max idle percent limit. The default is 50,
+ to match the current implementation of powerclamp driver. Also doesn't
+ allow value more than 75, if the cpumask includes every CPU present in
+ the system.
diff --git a/Documentation/admin-guide/thermal/intel_thermal_throttle.rst b/Documentation/admin-guide/thermal/intel_thermal_throttle.rst
new file mode 100644
index 000000000000..f4fbf9d5a4ec
--- /dev/null
+++ b/Documentation/admin-guide/thermal/intel_thermal_throttle.rst
@@ -0,0 +1,91 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+=======================================
+Intel thermal throttle events reporting
+=======================================
+
+:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+Introduction
+------------
+
+Intel processors have built in automatic and adaptive thermal monitoring
+mechanisms that force the processor to reduce its power consumption in order
+to operate within predetermined temperature limits.
+
+Refer to section "THERMAL MONITORING AND PROTECTION" in the "Intel® 64 and
+IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C, & 3D):
+System Programming Guide" for more details.
+
+In general, there are two mechanisms to control the core temperature of the
+processor. They are called "Thermal Monitor 1 (TM1) and Thermal Monitor 2 (TM2)".
+
+The status of the temperature sensor that triggers the thermal monitor (TM1/TM2)
+is indicated through the "thermal status flag" and "thermal status log flag" in
+MSR_IA32_THERM_STATUS for core level and MSR_IA32_PACKAGE_THERM_STATUS for
+package level.
+
+Thermal Status flag, bit 0 — When set, indicates that the processor core
+temperature is currently at the trip temperature of the thermal monitor and that
+the processor power consumption is being reduced via either TM1 or TM2, depending
+on which is enabled. When clear, the flag indicates that the core temperature is
+below the thermal monitor trip temperature. This flag is read only.
+
+Thermal Status Log flag, bit 1 — When set, indicates that the thermal sensor has
+tripped since the last power-up or reset or since the last time that software
+cleared this flag. This flag is a sticky bit; once set it remains set until
+cleared by software or until a power-up or reset of the processor. The default
+state is clear.
+
+It is possible that when user reads MSR_IA32_THERM_STATUS or
+MSR_IA32_PACKAGE_THERM_STATUS, TM1/TM2 is not active. In this case,
+"Thermal Status flag" will read "0" and the "Thermal Status Log flag" will be set
+to show any previous "TM1/TM2" activation. But since it needs to be cleared by
+the software, it can't show the number of occurrences of "TM1/TM2" activations.
+
+Hence, Linux provides counters of how many times the "Thermal Status flag" was
+set. Also presents how long the "Thermal Status flag" was active in milliseconds.
+Using these counters, users can check if the performance was limited because of
+thermal events. It is recommended to read from sysfs instead of directly reading
+MSRs as the "Thermal Status Log flag" is reset by the driver to implement rate
+control.
+
+Sysfs Interface
+---------------
+
+Thermal throttling events are presented for each CPU under
+"/sys/devices/system/cpu/cpuX/thermal_throttle/", where "X" is the CPU number.
+
+All these counters are read-only. They can't be reset to 0. So, they can potentially
+overflow after reaching the maximum 64 bit unsigned integer.
+
+``core_throttle_count``
+ Shows the number of times "Thermal Status flag" changed from 0 to 1 for this
+ CPU since OS boot and thermal vector is initialized. This is a 64 bit counter.
+
+``package_throttle_count``
+ Shows the number of times "Thermal Status flag" changed from 0 to 1 for the
+ package containing this CPU since OS boot and thermal vector is initialized.
+ Package status is broadcast to all CPUs; all CPUs in the package increment
+ this count. This is a 64-bit counter.
+
+``core_throttle_max_time_ms``
+ Shows the maximum amount of time for which "Thermal Status flag" has been
+ set to 1 for this CPU at the core level since OS boot and thermal vector
+ is initialized.
+
+``package_throttle_max_time_ms``
+ Shows the maximum amount of time for which "Thermal Status flag" has been
+ set to 1 for the package containing this CPU since OS boot and thermal
+ vector is initialized.
+
+``core_throttle_total_time_ms``
+ Shows the cumulative time for which "Thermal Status flag" has been
+ set to 1 for this CPU for core level since OS boot and thermal vector
+ is initialized.
+
+``package_throttle_total_time_ms``
+ Shows the cumulative time for which "Thermal Status flag" has been set
+ to 1 for the package containing this CPU since OS boot and thermal vector
+ is initialized.
diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst
index 2ed79f41a411..07303c1346fb 100644
--- a/Documentation/admin-guide/thunderbolt.rst
+++ b/Documentation/admin-guide/thunderbolt.rst
@@ -28,7 +28,7 @@ should be a userspace tool that handles all the low-level details, keeps
a database of the authorized devices and prompts users for new connections.
More details about the sysfs interface for Thunderbolt devices can be
-found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``.
+found in Documentation/ABI/testing/sysfs-bus-thunderbolt.
Those users who just want to connect any device without any sort of
manual work can add following line to
@@ -203,10 +203,10 @@ host controller or a device, it is important that the firmware can be
upgraded to the latest where possible bugs in it have been fixed.
Typically OEMs provide this firmware from their support site.
-There is also a central site which has links where to download firmware
-for some machines:
-
- `Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_
+Currently, recommended method of updating firmware is through "fwupd" tool.
+It uses LVFS (Linux Vendor Firmware Service) portal by default to get the
+latest firmware from hardware vendors and updates connected devices if found
+compatible. For details refer to: https://github.com/fwupd/fwupd.
Before you upgrade firmware on a device, host or retimer, please make
sure it is a suitable upgrade. Failing to do that may render the device
@@ -215,18 +215,40 @@ tools!
Host NVM upgrade on Apple Macs is not supported.
-Once the NVM image has been downloaded, you need to plug in a
-Thunderbolt device so that the host controller appears. It does not
-matter which device is connected (unless you are upgrading NVM on a
-device - then you need to connect that particular device).
+Fwupd is installed by default. If you don't have it on your system, simply
+use your distro package manager to get it.
+
+To see possible updates through fwupd, you need to plug in a Thunderbolt
+device so that the host controller appears. It does not matter which
+device is connected (unless you are upgrading NVM on a device - then you
+need to connect that particular device).
Note an OEM-specific method to power the controller up ("force power") may
be available for your system in which case there is no need to plug in a
Thunderbolt device.
-After that we can write the firmware to the non-active parts of the NVM
-of the host or device. As an example here is how Intel NUC6i7KYK (Skull
-Canyon) Thunderbolt controller NVM is upgraded::
+Updating firmware using fwupd is straightforward - refer to official
+readme on fwupd github.
+
+If firmware image is written successfully, the device shortly disappears.
+Once it comes back, the driver notices it and initiates a full power
+cycle. After a while device appears again and this time it should be
+fully functional.
+
+Device of interest should display new version under "Current version"
+and "Update State: Success" in fwupd's interface.
+
+Upgrading firmware manually
+---------------------------------------------------------------
+If possible, use fwupd to updated the firmware. However, if your device OEM
+has not uploaded the firmware to LVFS, but it is available for download
+from their side, you can use method below to directly upgrade the
+firmware.
+
+Manual firmware update can be done with 'dd' tool. To update firmware
+using this method, you need to write it to the non-active parts of NVM
+of the host or device. Example on how to update Intel NUC6i7KYK
+(Skull Canyon) Thunderbolt controller NVM::
# dd if=KYK_TBT_FW_0018.bin of=/sys/bus/thunderbolt/devices/0-0/nvm_non_active0/nvmem
@@ -235,10 +257,8 @@ upgrade process as follows::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
-If no errors are returned, the host controller shortly disappears. Once
-it comes back the driver notices it and initiates a full power cycle.
-After a while the host controller appears again and this time it should
-be fully functional.
+If no errors are returned, device should behave as described in previous
+section.
We can verify that the new NVM firmware is active by running the following
commands::
@@ -296,6 +316,39 @@ information is missing.
To recover from this mode, one needs to flash a valid NVM image to the
host controller in the same way it is done in the previous chapter.
+Tunneling events
+----------------
+The driver sends ``KOBJ_CHANGE`` events to userspace when there is a
+tunneling change in the ``thunderbolt_domain``. The notification carries
+following environment variables::
+
+ TUNNEL_EVENT=<EVENT>
+ TUNNEL_DETAILS=0:12 <-> 1:20 (USB3)
+
+Possible values for ``<EVENT>`` are:
+
+ activated
+ The tunnel was activated (created).
+
+ changed
+ There is a change in this tunnel. For example bandwidth allocation was
+ changed.
+
+ deactivated
+ The tunnel was torn down.
+
+ low bandwidth
+ The tunnel is not getting optimal bandwidth.
+
+ insufficient bandwidth
+ There is not enough bandwidth for the current tunnel requirements.
+
+The ``TUNNEL_DETAILS`` is only provided if the tunnel is known. For
+example, in case of Firmware Connection Manager this is missing or does
+not provide full tunnel information. In case of Software Connection Manager
+this includes full tunnel details. The format currently matches what the
+driver uses when logging. This may change over time.
+
Networking over Thunderbolt cable
---------------------------------
Thunderbolt technology allows software communication between two hosts
@@ -325,12 +378,7 @@ Forcing power
Many OEMs include a method that can be used to force the power of a
Thunderbolt controller to an "On" state even if nothing is connected.
If supported by your machine this will be exposed by the WMI bus with
-a sysfs attribute called "force_power".
-
-For example the intel-wmi-thunderbolt driver exposes this attribute in:
- /sys/bus/wmi/devices/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power
-
- To force the power to on, write 1 to this attribute file.
- To disable force power, write 0 to this attribute file.
+a sysfs attribute called "force_power", see
+Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt for details.
Note: it's currently not possible to query the force power state of a platform.
diff --git a/Documentation/admin-guide/unicode.rst b/Documentation/admin-guide/unicode.rst
index 290fe83ebe82..cba7e5017d36 100644
--- a/Documentation/admin-guide/unicode.rst
+++ b/Documentation/admin-guide/unicode.rst
@@ -3,11 +3,10 @@ Unicode support
Last update: 2005-01-17, version 1.4
-This file is maintained by H. Peter Anvin <unicode@lanana.org> as part
-of the Linux Assigned Names And Numbers Authority (LANANA) project.
-The current version can be found at:
-
- http://www.lanana.org/docs/unicode/admin-guide/unicode.rst
+Note: The original version of this document, which was maintained at
+lanana.org as part of the Linux Assigned Names And Numbers Authority
+(LANANA) project, is no longer existent. So, this version in the
+mainline Linux kernel is now the maintained main document.
Introduction
------------
diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
new file mode 100644
index 000000000000..d83601f2a459
--- /dev/null
+++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
@@ -0,0 +1,2222 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+.. [see the bottom of this file for redistribution information]
+
+=========================================
+How to verify bugs and bisect regressions
+=========================================
+
+This document describes how to check if some Linux kernel problem occurs in code
+currently supported by developers -- to then explain how to locate the change
+causing the issue, if it is a regression (e.g. did not happen with earlier
+versions).
+
+The text aims at people running kernels from mainstream Linux distributions on
+commodity hardware who want to report a kernel bug to the upstream Linux
+developers. Despite this intent, the instructions work just as well for users
+who are already familiar with building their own kernels: they help avoid
+mistakes occasionally made even by experienced developers.
+
+..
+ Note: if you see this note, you are reading the text's source file. You
+ might want to switch to a rendered version: it makes it a lot easier to
+ read and navigate this document -- especially when you want to look something
+ up in the reference section, then jump back to where you left off.
+..
+ Find the latest rendered version of this text here:
+ https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
+
+The essence of the process (aka 'TL;DR')
+========================================
+
+*[If you are new to building or bisecting Linux, ignore this section and head
+over to the* ':ref:`step-by-step guide <introguide_bissbs>`' *below. It utilizes
+the same commands as this section while describing them in brief fashion. The
+steps are nevertheless easy to follow and together with accompanying entries
+in a reference section mention many alternatives, pitfalls, and additional
+aspects, all of which might be essential in your present case.]*
+
+**In case you want to check if a bug is present in code currently supported by
+developers**, execute just the *preparations* and *segment 1*; while doing so,
+consider the newest Linux kernel you regularly use to be the 'working' kernel.
+In the following example that's assumed to be 6.0, which is why its sources
+will be used to prepare the .config file.
+
+**In case you face a regression**, follow the steps at least till the end of
+*segment 2*. Then you can submit a preliminary report -- or continue with
+*segment 3*, which describes how to perform a bisection needed for a
+full-fledged regression report. In the following example 6.0.13 is assumed to be
+the 'working' kernel and 6.1.5 to be the first 'broken', which is why 6.0
+will be considered the 'good' release and used to prepare the .config file.
+
+* **Preparations**: set up everything to build your own kernels::
+
+ # * Remove any software that depends on externally maintained kernel modules
+ # or builds any automatically during bootup.
+ # * Ensure Secure Boot permits booting self-compiled Linux kernels.
+ # * If you are not already running the 'working' kernel, reboot into it.
+ # * Install compilers and everything else needed for building Linux.
+ # * Ensure to have 15 Gigabyte free space in your home directory.
+ git clone -o mainline --no-checkout \
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ~/linux/
+ cd ~/linux/
+ git remote add -t master stable \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+ git switch --detach v6.0
+ # * Hint: if you used an existing clone, ensure no stale .config is around.
+ make olddefconfig
+ # * Ensure the former command picked the .config of the 'working' kernel.
+ # * Connect external hardware (USB keys, tokens, ...), start a VM, bring up
+ # VPNs, mount network shares, and briefly try the feature that is broken.
+ yes '' | make localmodconfig
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local'
+ ./scripts/config -e CONFIG_LOCALVERSION_AUTO
+ # * Note, when short on storage space, check the guide for an alternative:
+ ./scripts/config -d DEBUG_INFO_NONE -e KALLSYMS_ALL -e DEBUG_KERNEL \
+ -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS
+ # * Hint: at this point you might want to adjust the build configuration;
+ # you'll have to, if you are running Debian.
+ make olddefconfig
+ cp .config ~/kernel-config-working
+
+* **Segment 1**: build a kernel from the latest mainline codebase.
+
+ This among others checks if the problem was fixed already and which developers
+ later need to be told about the problem; in case of a regression, this rules
+ out a .config change as root of the problem.
+
+ a) Checking out latest mainline code::
+
+ cd ~/linux/
+ git switch --discard-changes --detach mainline/master
+
+ b) Build, install, and boot a kernel::
+
+ cp ~/kernel-config-working .config
+ make olddefconfig
+ make -j $(nproc --all)
+ # * Make sure there is enough disk space to hold another kernel:
+ df -h /boot/ /lib/modules/
+ # * Note: on Arch Linux, its derivatives and a few other distributions
+ # the following commands will do nothing at all or only part of the
+ # job. See the step-by-step guide for further details.
+ sudo make modules_install
+ command -v installkernel && sudo make install
+ # * Check how much space your self-built kernel actually needs, which
+ # enables you to make better estimates later:
+ du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
+ du -sh /lib/modules/$(make -s kernelrelease)/
+ # * Hint: the output of the following command will help you pick the
+ # right kernel from the boot menu:
+ make -s kernelrelease | tee -a ~/kernels-built
+ reboot
+ # * Once booted, ensure you are running the kernel you just built by
+ # checking if the output of the next two commands matches:
+ tail -n 1 ~/kernels-built
+ uname -r
+ cat /proc/sys/kernel/tainted
+
+ c) Check if the problem occurs with this kernel as well.
+
+* **Segment 2**: ensure the 'good' kernel is also a 'working' kernel.
+
+ This among others verifies the trimmed .config file actually works well, as
+ bisecting with it otherwise would be a waste of time:
+
+ a) Start by checking out the sources of the 'good' version::
+
+ cd ~/linux/
+ git switch --discard-changes --detach v6.0
+
+ b) Build, install, and boot a kernel as described earlier in *segment 1,
+ section b* -- just feel free to skip the 'du' commands, as you have a rough
+ estimate already.
+
+ c) Ensure the feature that regressed with the 'broken' kernel actually works
+ with this one.
+
+* **Segment 3**: perform and validate the bisection.
+
+ a) Retrieve the sources for your 'bad' version::
+
+ git remote set-branches --add stable linux-6.1.y
+ git fetch stable
+
+ b) Initialize the bisection::
+
+ cd ~/linux/
+ git bisect start
+ git bisect good v6.0
+ git bisect bad v6.1.5
+
+ c) Build, install, and boot a kernel as described earlier in *segment 1,
+ section b*.
+
+ In case building or booting the kernel fails for unrelated reasons, run
+ ``git bisect skip``. In all other outcomes, check if the regressed feature
+ works with the newly built kernel. If it does, tell Git by executing
+ ``git bisect good``; if it does not, run ``git bisect bad`` instead.
+
+ All three commands will make Git check out another commit; then re-execute
+ this step (e.g. build, install, boot, and test a kernel to then tell Git
+ the outcome). Do so again and again until Git shows which commit broke
+ things. If you run short of disk space during this process, check the
+ section 'Complementary tasks: cleanup during and after the process'
+ below.
+
+ d) Once your finished the bisection, put a few things away::
+
+ cd ~/linux/
+ git bisect log > ~/bisect-log
+ cp .config ~/bisection-config-culprit
+ git bisect reset
+
+ e) Try to verify the bisection result::
+
+ git switch --discard-changes --detach mainline/master
+ git revert --no-edit cafec0cacaca0
+ cp ~/kernel-config-working .config
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
+
+ This is optional, as some commits are impossible to revert. But if the
+ second command worked flawlessly, build, install, and boot one more kernel
+ kernel; just this time skip the first command copying the base .config file
+ over, as that already has been taken care off.
+
+* **Complementary tasks**: cleanup during and after the process.
+
+ a) To avoid running out of disk space during a bisection, you might need to
+ remove some kernels you built earlier. You most likely want to keep those
+ you built during segment 1 and 2 around for a while, but you will most
+ likely no longer need kernels tested during the actual bisection
+ (Segment 3 c). You can list them in build order using::
+
+ ls -ltr /lib/modules/*-local*
+
+ To then for example erase a kernel that identifies itself as
+ '6.0-rc1-local-gcafec0cacaca0', use this::
+
+ sudo rm -rf /lib/modules/6.0-rc1-local-gcafec0cacaca0
+ sudo kernel-install -v remove 6.0-rc1-local-gcafec0cacaca0
+ # * Note, on some distributions kernel-install is missing
+ # or does only part of the job.
+
+ b) If you performed a bisection and successfully validated the result, feel
+ free to remove all kernels built during the actual bisection (Segment 3 c);
+ the kernels you built earlier and later you might want to keep around for
+ a week or two.
+
+* **Optional task**: test a debug patch or a proposed fix later::
+
+ git fetch mainline
+ git switch --discard-changes --detach mainline/master
+ git apply /tmp/foobars-proposed-fix-v1.patch
+ cp ~/kernel-config-working .config
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1'
+
+ Build, install, and boot a kernel as described in *segment 1, section b* --
+ but this time omit the first command copying the build configuration over,
+ as that has been taken care of already.
+
+.. _introguide_bissbs:
+
+Step-by-step guide on how to verify bugs and bisect regressions
+===============================================================
+
+This guide describes how to set up your own Linux kernels for investigating bugs
+or regressions you intend to report. How far you want to follow the instructions
+depends on your issue:
+
+Execute all steps till the end of *segment 1* to **verify if your kernel problem
+is present in code supported by Linux kernel developers**. If it is, you are all
+set to report the bug -- unless it did not happen with earlier kernel versions,
+as then your want to at least continue with *segment 2* to **check if the issue
+qualifies as regression** which receive priority treatment. Depending on the
+outcome you then are ready to report a bug or submit a preliminary regression
+report; instead of the latter your could also head straight on and follow
+*segment 3* to **perform a bisection** for a full-fledged regression report
+developers are obliged to act upon.
+
+ :ref:`Preparations: set up everything to build your own kernels <introprep_bissbs>`.
+
+ :ref:`Segment 1: try to reproduce the problem with the latest codebase <introlatestcheck_bissbs>`.
+
+ :ref:`Segment 2: check if the kernels you build work fine <introworkingcheck_bissbs>`.
+
+ :ref:`Segment 3: perform a bisection and validate the result <introbisect_bissbs>`.
+
+ :ref:`Complementary tasks: cleanup during and after following this guide <introclosure_bissbs>`.
+
+ :ref:`Optional tasks: test reverts, patches, or later versions <introoptional_bissbs>`.
+
+The steps in each segment illustrate the important aspects of the process, while
+a comprehensive reference section holds additional details for almost all of the
+steps. The reference section sometimes also outlines alternative approaches,
+pitfalls, as well as problems that might occur at the particular step -- and how
+to get things rolling again.
+
+For further details on how to report Linux kernel issues or regressions check
+out Documentation/admin-guide/reporting-issues.rst, which works in conjunction
+with this document. It among others explains why you need to verify bugs with
+the latest 'mainline' kernel (e.g. versions like 6.0, 6.1-rc1, or 6.1-rc6),
+even if you face a problem with a kernel from a 'stable/longterm' series
+(say 6.0.13).
+
+For users facing a regression that document also explains why sending a
+preliminary report after segment 2 might be wise, as the regression and its
+culprit might be known already. For further details on what actually qualifies
+as a regression check out Documentation/admin-guide/reporting-regressions.rst.
+
+If you run into any problems while following this guide or have ideas how to
+improve it, :ref:`please let the kernel developers know <submit_improvements_vbbr>`.
+
+.. _introprep_bissbs:
+
+Preparations: set up everything to build your own kernels
+---------------------------------------------------------
+
+The following steps lay the groundwork for all further tasks.
+
+Note: the instructions assume you are building and testing on the same
+machine; if you want to compile the kernel on another system, check
+:ref:`Build kernels on a different machine <buildhost_bis>` below.
+
+.. _backup_bissbs:
+
+* Create a fresh backup and put system repair and restore tools at hand, just
+ to be prepared for the unlikely case of something going sideways.
+
+ [:ref:`details <backup_bisref>`]
+
+.. _vanilla_bissbs:
+
+* Remove all software that depends on externally developed kernel drivers or
+ builds them automatically. That includes but is not limited to DKMS, openZFS,
+ VirtualBox, and Nvidia's graphics drivers (including the GPLed kernel module).
+
+ [:ref:`details <vanilla_bisref>`]
+
+.. _secureboot_bissbs:
+
+* On platforms with 'Secure Boot' or similar solutions, prepare everything to
+ ensure the system will permit your self-compiled kernel to boot. The
+ quickest and easiest way to achieve this on commodity x86 systems is to
+ disable such techniques in the BIOS setup utility; alternatively, remove
+ their restrictions through a process initiated by
+ ``mokutil --disable-validation``.
+
+ [:ref:`details <secureboot_bisref>`]
+
+.. _rangecheck_bissbs:
+
+* Determine the kernel versions considered 'good' and 'bad' throughout this
+ guide:
+
+ * Do you follow this guide to verify if a bug is present in the code the
+ primary developers care for? Then consider the version of the newest kernel
+ you regularly use currently as 'good' (e.g. 6.0, 6.0.13, or 6.1-rc2).
+
+ * Do you face a regression, e.g. something broke or works worse after
+ switching to a newer kernel version? In that case it depends on the version
+ range during which the problem appeared:
+
+ * Something regressed when updating from a stable/longterm release
+ (say 6.0.13) to a newer mainline series (like 6.1-rc7 or 6.1) or a
+ stable/longterm version based on one (say 6.1.5)? Then consider the
+ mainline release your working kernel is based on to be the 'good'
+ version (e.g. 6.0) and the first version to be broken as the 'bad' one
+ (e.g. 6.1-rc7, 6.1, or 6.1.5). Note, at this point it is merely assumed
+ that 6.0 is fine; this hypothesis will be checked in segment 2.
+
+ * Something regressed when switching from one mainline version (say 6.0) to
+ a later one (like 6.1-rc1) or a stable/longterm release based on it
+ (say 6.1.5)? Then regard the last working version (e.g. 6.0) as 'good' and
+ the first broken (e.g. 6.1-rc1 or 6.1.5) as 'bad'.
+
+ * Something regressed when updating within a stable/longterm series (say
+ from 6.0.13 to 6.0.15)? Then consider those versions as 'good' and 'bad'
+ (e.g. 6.0.13 and 6.0.15), as you need to bisect within that series.
+
+ *Note, do not confuse 'good' version with 'working' kernel; the latter term
+ throughout this guide will refer to the last kernel that has been working
+ fine.*
+
+ [:ref:`details <rangecheck_bisref>`]
+
+.. _bootworking_bissbs:
+
+* Boot into the 'working' kernel and briefly use the apparently broken feature.
+
+ [:ref:`details <bootworking_bisref>`]
+
+.. _diskspace_bissbs:
+
+* Ensure to have enough free space for building Linux. 15 Gigabyte in your home
+ directory should typically suffice. If you have less available, be sure to pay
+ attention to later steps about retrieving the Linux sources and handling of
+ debug symbols: both explain approaches reducing the amount of space, which
+ should allow you to master these tasks with about 4 Gigabytes free space.
+
+ [:ref:`details <diskspace_bisref>`]
+
+.. _buildrequires_bissbs:
+
+* Install all software required to build a Linux kernel. Often you will need:
+ 'bc', 'binutils' ('ld' et al.), 'bison', 'flex', 'gcc', 'git', 'openssl',
+ 'pahole', 'perl', and the development headers for 'libelf' and 'openssl'. The
+ reference section shows how to quickly install those on various popular Linux
+ distributions.
+
+ [:ref:`details <buildrequires_bisref>`]
+
+.. _sources_bissbs:
+
+* Retrieve the mainline Linux sources; then change into the directory holding
+ them, as all further commands in this guide are meant to be executed from
+ there.
+
+ *Note, the following describe how to retrieve the sources using a full
+ mainline clone, which downloads about 2,75 GByte as of early 2024. The*
+ :ref:`reference section describes two alternatives <sources_bisref>` *:
+ one downloads less than 500 MByte, the other works better with unreliable
+ internet connections.*
+
+ Execute the following command to retrieve a fresh mainline codebase while
+ preparing things to add branches for stable/longterm series later::
+
+ git clone -o mainline --no-checkout \
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ~/linux/
+ cd ~/linux/
+ git remote add -t master stable \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+ [:ref:`details <sources_bisref>`]
+
+.. _stablesources_bissbs:
+
+* Is one of the versions you earlier established as 'good' or 'bad' a stable or
+ longterm release (say 6.1.5)? Then download the code for the series it belongs
+ to ('linux-6.1.y' in this example)::
+
+ git remote set-branches --add stable linux-6.1.y
+ git fetch stable
+
+.. _oldconfig_bissbs:
+
+* Start preparing a kernel build configuration (the '.config' file).
+
+ Before doing so, ensure you are still running the 'working' kernel an earlier
+ step told you to boot; if you are unsure, check the current kernelrelease
+ identifier using ``uname -r``.
+
+ Afterwards check out the source code for the version earlier established as
+ 'good'. In the following example command this is assumed to be 6.0; note that
+ the version number in this and all later Git commands needs to be prefixed
+ with a 'v'::
+
+ git switch --discard-changes --detach v6.0
+
+ Now create a build configuration file::
+
+ make olddefconfig
+
+ The kernel build scripts then will try to locate the build configuration file
+ for the running kernel and then adjust it for the needs of the kernel sources
+ you checked out. While doing so, it will print a few lines you need to check.
+
+ Look out for a line starting with '# using defaults found in'. It should be
+ followed by a path to a file in '/boot/' that contains the release identifier
+ of your currently working kernel. If the line instead continues with something
+ like 'arch/x86/configs/x86_64_defconfig', then the build infra failed to find
+ the .config file for your running kernel -- in which case you have to put one
+ there manually, as explained in the reference section.
+
+ In case you can not find such a line, look for one containing '# configuration
+ written to .config'. If that's the case you have a stale build configuration
+ lying around. Unless you intend to use it, delete it; afterwards run
+ 'make olddefconfig' again and check if it now picked up the right config file
+ as base.
+
+ [:ref:`details <oldconfig_bisref>`]
+
+.. _localmodconfig_bissbs:
+
+* Disable any kernel modules apparently superfluous for your setup. This is
+ optional, but especially wise for bisections, as it speeds up the build
+ process enormously -- at least unless the .config file picked up in the
+ previous step was already tailored to your and your hardware needs, in which
+ case you should skip this step.
+
+ To prepare the trimming, connect external hardware you occasionally use (USB
+ keys, tokens, ...), quickly start a VM, and bring up VPNs. And if you rebooted
+ since you started that guide, ensure that you tried using the feature causing
+ trouble since you started the system. Only then trim your .config::
+
+ yes '' | make localmodconfig
+
+ There is a catch to this, as the 'apparently' in initial sentence of this step
+ and the preparation instructions already hinted at:
+
+ The 'localmodconfig' target easily disables kernel modules for features only
+ used occasionally -- like modules for external peripherals not yet connected
+ since booting, virtualization software not yet utilized, VPN tunnels, and a
+ few other things. That's because some tasks rely on kernel modules Linux only
+ loads when you execute tasks like the aforementioned ones for the first time.
+
+ This drawback of localmodconfig is nothing you should lose sleep over, but
+ something to keep in mind: if something is misbehaving with the kernels built
+ during this guide, this is most likely the reason. You can reduce or nearly
+ eliminate the risk with tricks outlined in the reference section; but when
+ building a kernel just for quick testing purposes this is usually not worth
+ spending much effort on, as long as it boots and allows to properly test the
+ feature that causes trouble.
+
+ [:ref:`details <localmodconfig_bisref>`]
+
+.. _tagging_bissbs:
+
+* Ensure all the kernels you will build are clearly identifiable using a special
+ tag and a unique version number::
+
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local'
+ ./scripts/config -e CONFIG_LOCALVERSION_AUTO
+
+ [:ref:`details <tagging_bisref>`]
+
+.. _debugsymbols_bissbs:
+
+* Decide how to handle debug symbols.
+
+ In the context of this document it is often wise to enable them, as there is a
+ decent chance you will need to decode a stack trace from a 'panic', 'Oops',
+ 'warning', or 'BUG'::
+
+ ./scripts/config -d DEBUG_INFO_NONE -e KALLSYMS_ALL -e DEBUG_KERNEL \
+ -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS
+
+ But if you are extremely short on storage space, you might want to disable
+ debug symbols instead::
+
+ ./scripts/config -d DEBUG_INFO -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
+ -d DEBUG_INFO_DWARF4 -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE
+
+ [:ref:`details <debugsymbols_bisref>`]
+
+.. _configmods_bissbs:
+
+* Check if you may want or need to adjust some other kernel configuration
+ options:
+
+ * Are you running Debian? Then you want to avoid known problems by performing
+ additional adjustments explained in the reference section.
+
+ [:ref:`details <configmods_distros_bisref>`].
+
+ * If you want to influence other aspects of the configuration, do so now using
+ your preferred tool. Note, to use make targets like 'menuconfig' or
+ 'nconfig', you will need to install the development files of ncurses; for
+ 'xconfig' you likewise need the Qt5 or Qt6 headers.
+
+ [:ref:`details <configmods_individual_bisref>`].
+
+.. _saveconfig_bissbs:
+
+* Reprocess the .config after the latest adjustments and store it in a safe
+ place::
+
+ make olddefconfig
+ cp .config ~/kernel-config-working
+
+ [:ref:`details <saveconfig_bisref>`]
+
+.. _introlatestcheck_bissbs:
+
+Segment 1: try to reproduce the problem with the latest codebase
+----------------------------------------------------------------
+
+The following steps verify if the problem occurs with the code currently
+supported by developers. In case you face a regression, it also checks that the
+problem is not caused by some .config change, as reporting the issue then would
+be a waste of time. [:ref:`details <introlatestcheck_bisref>`]
+
+.. _checkoutmaster_bissbs:
+
+* Check out the latest Linux codebase.
+
+ * Are your 'good' and 'bad' versions from the same stable or longterm series?
+ Then check the `front page of kernel.org <https://kernel.org/>`_: if it
+ lists a release from that series without an '[EOL]' tag, checkout the series
+ latest version ('linux-6.1.y' in the following example)::
+
+ cd ~/linux/
+ git switch --discard-changes --detach stable/linux-6.1.y
+
+ Your series is unsupported, if is not listed or carrying a 'end of life'
+ tag. In that case you might want to check if a successor series (say
+ linux-6.2.y) or mainline (see next point) fix the bug.
+
+ * In all other cases, run::
+
+ cd ~/linux/
+ git switch --discard-changes --detach mainline/master
+
+ [:ref:`details <checkoutmaster_bisref>`]
+
+.. _build_bissbs:
+
+* Build the image and the modules of your first kernel using the config file you
+ prepared::
+
+ cp ~/kernel-config-working .config
+ make olddefconfig
+ make -j $(nproc --all)
+
+ If you want your kernel packaged up as deb, rpm, or tar file, see the
+ reference section for alternatives, which obviously will require other
+ steps to install as well.
+
+ [:ref:`details <build_bisref>`]
+
+.. _install_bissbs:
+
+* Install your newly built kernel.
+
+ Before doing so, consider checking if there is still enough space for it::
+
+ df -h /boot/ /lib/modules/
+
+ For now assume 150 MByte in /boot/ and 200 in /lib/modules/ will suffice; how
+ much your kernels actually require will be determined later during this guide.
+
+ Now install the kernel's modules and its image, which will be stored in
+ parallel to the your Linux distribution's kernels::
+
+ sudo make modules_install
+ command -v installkernel && sudo make install
+
+ The second command ideally will take care of three steps required at this
+ point: copying the kernel's image to /boot/, generating an initramfs, and
+ adding an entry for both to the boot loader's configuration.
+
+ Sadly some distributions (among them Arch Linux, its derivatives, and many
+ immutable Linux distributions) will perform none or only some of those tasks.
+ You therefore want to check if all of them were taken care of and manually
+ perform those that were not. The reference section provides further details on
+ that; your distribution's documentation might help, too.
+
+ Once you figured out the steps needed at this point, consider writing them
+ down: if you will build more kernels as described in segment 2 and 3, you will
+ have to perform those again after executing ``command -v installkernel [...]``.
+
+ [:ref:`details <install_bisref>`]
+
+.. _storagespace_bissbs:
+
+* In case you plan to follow this guide further, check how much storage space
+ the kernel, its modules, and other related files like the initramfs consume::
+
+ du -ch /boot/*$(make -s kernelrelease)* | tail -n 1
+ du -sh /lib/modules/$(make -s kernelrelease)/
+
+ Write down or remember those two values for later: they enable you to prevent
+ running out of disk space accidentally during a bisection.
+
+ [:ref:`details <storagespace_bisref>`]
+
+.. _kernelrelease_bissbs:
+
+* Show and store the kernelrelease identifier of the kernel you just built::
+
+ make -s kernelrelease | tee -a ~/kernels-built
+
+ Remember the identifier momentarily, as it will help you pick the right kernel
+ from the boot menu upon restarting.
+
+* Reboot into your newly built kernel. To ensure your actually started the one
+ you just built, you might want to verify if the output of these commands
+ matches::
+
+ tail -n 1 ~/kernels-built
+ uname -r
+
+.. _tainted_bissbs:
+
+* Check if the kernel marked itself as 'tainted'::
+
+ cat /proc/sys/kernel/tainted
+
+ If that command does not return '0', check the reference section, as the cause
+ for this might interfere with your testing.
+
+ [:ref:`details <tainted_bisref>`]
+
+.. _recheckbroken_bissbs:
+
+* Verify if your bug occurs with the newly built kernel. If it does not, check
+ out the instructions in the reference section to ensure nothing went sideways
+ during your tests.
+
+ [:ref:`details <recheckbroken_bisref>`]
+
+.. _recheckstablebroken_bissbs:
+
+* Did you just built a stable or longterm kernel? And were you able to reproduce
+ the regression with it? Then you should test the latest mainline codebase as
+ well, because the result determines which developers the bug must be submitted
+ to.
+
+ To prepare that test, check out current mainline::
+
+ cd ~/linux/
+ git switch --discard-changes --detach mainline/master
+
+ Now use the checked out code to build and install another kernel using the
+ commands the earlier steps already described in more detail::
+
+ cp ~/kernel-config-working .config
+ make olddefconfig
+ make -j $(nproc --all)
+ # * Check if the free space suffices holding another kernel:
+ df -h /boot/ /lib/modules/
+ sudo make modules_install
+ command -v installkernel && sudo make install
+ make -s kernelrelease | tee -a ~/kernels-built
+ reboot
+
+ Confirm you booted the kernel you intended to start and check its tainted
+ status::
+
+ tail -n 1 ~/kernels-built
+ uname -r
+ cat /proc/sys/kernel/tainted
+
+ Now verify if this kernel is showing the problem. If it does, then you need
+ to report the bug to the primary developers; if it does not, report it to the
+ stable team. See Documentation/admin-guide/reporting-issues.rst for details.
+
+ [:ref:`details <recheckstablebroken_bisref>`]
+
+Do you follow this guide to verify if a problem is present in the code
+currently supported by Linux kernel developers? Then you are done at this
+point. If you later want to remove the kernel you just built, check out
+:ref:`Complementary tasks: cleanup during and after following this guide <introclosure_bissbs>`.
+
+In case you face a regression, move on and execute at least the next segment
+as well.
+
+.. _introworkingcheck_bissbs:
+
+Segment 2: check if the kernels you build work fine
+---------------------------------------------------
+
+In case of a regression, you now want to ensure the trimmed configuration file
+you created earlier works as expected; a bisection with the .config file
+otherwise would be a waste of time. [:ref:`details <introworkingcheck_bisref>`]
+
+.. _recheckworking_bissbs:
+
+* Build your own variant of the 'working' kernel and check if the feature that
+ regressed works as expected with it.
+
+ Start by checking out the sources for the version earlier established as
+ 'good' (once again assumed to be 6.0 here)::
+
+ cd ~/linux/
+ git switch --discard-changes --detach v6.0
+
+ Now use the checked out code to configure, build, and install another kernel
+ using the commands the previous subsection explained in more detail::
+
+ cp ~/kernel-config-working .config
+ make olddefconfig
+ make -j $(nproc --all)
+ # * Check if the free space suffices holding another kernel:
+ df -h /boot/ /lib/modules/
+ sudo make modules_install
+ command -v installkernel && sudo make install
+ make -s kernelrelease | tee -a ~/kernels-built
+ reboot
+
+ When the system booted, you may want to verify once again that the
+ kernel you started is the one you just built::
+
+ tail -n 1 ~/kernels-built
+ uname -r
+
+ Now check if this kernel works as expected; if not, consult the reference
+ section for further instructions.
+
+ [:ref:`details <recheckworking_bisref>`]
+
+.. _introbisect_bissbs:
+
+Segment 3: perform the bisection and validate the result
+--------------------------------------------------------
+
+With all the preparations and precaution builds taken care of, you are now ready
+to begin the bisection. This will make you build quite a few kernels -- usually
+about 15 in case you encountered a regression when updating to a newer series
+(say from 6.0.13 to 6.1.5). But do not worry, due to the trimmed build
+configuration created earlier this works a lot faster than many people assume:
+overall on average it will often just take about 10 to 15 minutes to compile
+each kernel on commodity x86 machines.
+
+.. _bisectstart_bissbs:
+
+* Start the bisection and tell Git about the versions earlier established as
+ 'good' (6.0 in the following example command) and 'bad' (6.1.5)::
+
+ cd ~/linux/
+ git bisect start
+ git bisect good v6.0
+ git bisect bad v6.1.5
+
+ [:ref:`details <bisectstart_bisref>`]
+
+.. _bisectbuild_bissbs:
+
+* Now use the code Git checked out to build, install, and boot a kernel using
+ the commands introduced earlier::
+
+ cp ~/kernel-config-working .config
+ make olddefconfig
+ make -j $(nproc --all)
+ # * Check if the free space suffices holding another kernel:
+ df -h /boot/ /lib/modules/
+ sudo make modules_install
+ command -v installkernel && sudo make install
+ make -s kernelrelease | tee -a ~/kernels-built
+ reboot
+
+ If compilation fails for some reason, run ``git bisect skip`` and restart
+ executing the stack of commands from the beginning.
+
+ In case you skipped the 'test latest codebase' step in the guide, check its
+ description as for why the 'df [...]' and 'make -s kernelrelease [...]'
+ commands are here.
+
+ Important note: the latter command from this point on will print release
+ identifiers that might look odd or wrong to you -- which they are not, as it's
+ totally normal to see release identifiers like '6.0-rc1-local-gcafec0cacaca0'
+ if you bisect between versions 6.1 and 6.2 for example.
+
+ [:ref:`details <bisectbuild_bisref>`]
+
+.. _bisecttest_bissbs:
+
+* Now check if the feature that regressed works in the kernel you just built.
+
+ You again might want to start by making sure the kernel you booted is the one
+ you just built::
+
+ cd ~/linux/
+ tail -n 1 ~/kernels-built
+ uname -r
+
+ Now verify if the feature that regressed works at this kernel bisection point.
+ If it does, run this::
+
+ git bisect good
+
+ If it does not, run this::
+
+ git bisect bad
+
+ Be sure about what you tell Git, as getting this wrong just once will send the
+ rest of the bisection totally off course.
+
+ While the bisection is ongoing, Git will use the information you provided to
+ find and check out another bisection point for you to test. While doing so, it
+ will print something like 'Bisecting: 675 revisions left to test after this
+ (roughly 10 steps)' to indicate how many further changes it expects to be
+ tested. Now build and install another kernel using the instructions from the
+ previous step; afterwards follow the instructions in this step again.
+
+ Repeat this again and again until you finish the bisection -- that's the case
+ when Git after tagging a change as 'good' or 'bad' prints something like
+ 'cafecaca0c0dacafecaca0c0dacafecaca0c0da is the first bad commit'; right
+ afterwards it will show some details about the culprit including the patch
+ description of the change. The latter might fill your terminal screen, so you
+ might need to scroll up to see the message mentioning the culprit;
+ alternatively, run ``git bisect log > ~/bisection-log``.
+
+ [:ref:`details <bisecttest_bisref>`]
+
+.. _bisectlog_bissbs:
+
+* Store Git's bisection log and the current .config file in a safe place before
+ telling Git to reset the sources to the state before the bisection::
+
+ cd ~/linux/
+ git bisect log > ~/bisection-log
+ cp .config ~/bisection-config-culprit
+ git bisect reset
+
+ [:ref:`details <bisectlog_bisref>`]
+
+.. _revert_bissbs:
+
+* Try reverting the culprit on top of latest mainline to see if this fixes your
+ regression.
+
+ This is optional, as it might be impossible or hard to realize. The former is
+ the case, if the bisection determined a merge commit as the culprit; the
+ latter happens if other changes depend on the culprit. But if the revert
+ succeeds, it is worth building another kernel, as it validates the result of
+ a bisection, which can easily deroute; it furthermore will let kernel
+ developers know, if they can resolve the regression with a quick revert.
+
+ Begin by checking out the latest codebase depending on the range you bisected:
+
+ * Did you face a regression within a stable/longterm series (say between
+ 6.0.13 and 6.0.15) that does not happen in mainline? Then check out the
+ latest codebase for the affected series like this::
+
+ git fetch stable
+ git switch --discard-changes --detach linux-6.0.y
+
+ * In all other cases check out latest mainline::
+
+ git fetch mainline
+ git switch --discard-changes --detach mainline/master
+
+ If you bisected a regression within a stable/longterm series that also
+ happens in mainline, there is one more thing to do: look up the mainline
+ commit-id. To do so, use a command like ``git show abcdcafecabcd`` to
+ view the patch description of the culprit. There will be a line near
+ the top which looks like 'commit cafec0cacaca0 upstream.' or
+ 'Upstream commit cafec0cacaca0'; use that commit-id in the next command
+ and not the one the bisection blamed.
+
+ Now try reverting the culprit by specifying its commit id::
+
+ git revert --no-edit cafec0cacaca0
+
+ If that fails, give up trying and move on to the next step; if it works,
+ adjust the tag to facilitate the identification and prevent accidentally
+ overwriting another kernel::
+
+ cp ~/kernel-config-working .config
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
+
+ Build a kernel using the familiar command sequence, just without copying the
+ the base .config over::
+
+ make olddefconfig &&
+ make -j $(nproc --all)
+ # * Check if the free space suffices holding another kernel:
+ df -h /boot/ /lib/modules/
+ sudo make modules_install
+ command -v installkernel && sudo make install
+ make -s kernelrelease | tee -a ~/kernels-built
+ reboot
+
+ Now check one last time if the feature that made you perform a bisection works
+ with that kernel: if everything went well, it should not show the regression.
+
+ [:ref:`details <revert_bisref>`]
+
+.. _introclosure_bissbs:
+
+Complementary tasks: cleanup during and after the bisection
+-----------------------------------------------------------
+
+During and after following this guide you might want or need to remove some of
+the kernels you installed: the boot menu otherwise will become confusing or
+space might run out.
+
+.. _makeroom_bissbs:
+
+* To remove one of the kernels you installed, look up its 'kernelrelease'
+ identifier. This guide stores them in '~/kernels-built', but the following
+ command will print them as well::
+
+ ls -ltr /lib/modules/*-local*
+
+ You in most situations want to remove the oldest kernels built during the
+ actual bisection (e.g. segment 3 of this guide). The two ones you created
+ beforehand (e.g. to test the latest codebase and the version considered
+ 'good') might become handy to verify something later -- thus better keep them
+ around, unless you are really short on storage space.
+
+ To remove the modules of a kernel with the kernelrelease identifier
+ '*6.0-rc1-local-gcafec0cacaca0*', start by removing the directory holding its
+ modules::
+
+ sudo rm -rf /lib/modules/6.0-rc1-local-gcafec0cacaca0
+
+ Afterwards try the following command::
+
+ sudo kernel-install -v remove 6.0-rc1-local-gcafec0cacaca0
+
+ On quite a few distributions this will delete all other kernel files installed
+ while also removing the kernel's entry from the boot menu. But on some
+ distributions kernel-install does not exist or leaves boot-loader entries or
+ kernel image and related files behind; in that case remove them as described
+ in the reference section.
+
+ [:ref:`details <makeroom_bisref>`]
+
+.. _finishingtouch_bissbs:
+
+* Once you have finished the bisection, do not immediately remove anything you
+ set up, as you might need a few things again. What is safe to remove depends
+ on the outcome of the bisection:
+
+ * Could you initially reproduce the regression with the latest codebase and
+ after the bisection were able to fix the problem by reverting the culprit on
+ top of the latest codebase? Then you want to keep those two kernels around
+ for a while, but safely remove all others with a '-local' in the release
+ identifier.
+
+ * Did the bisection end on a merge-commit or seems questionable for other
+ reasons? Then you want to keep as many kernels as possible around for a few
+ days: it's pretty likely that you will be asked to recheck something.
+
+ * In other cases it likely is a good idea to keep the following kernels around
+ for some time: the one built from the latest codebase, the one created from
+ the version considered 'good', and the last three or four you compiled
+ during the actual bisection process.
+
+ [:ref:`details <finishingtouch_bisref>`]
+
+.. _introoptional_bissbs:
+
+Optional: test reverts, patches, or later versions
+--------------------------------------------------
+
+While or after reporting a bug, you might want or potentially will be asked to
+test reverts, debug patches, proposed fixes, or other versions. In that case
+follow these instructions.
+
+* Update your Git clone and check out the latest code.
+
+ * In case you want to test mainline, fetch its latest changes before checking
+ its code out::
+
+ git fetch mainline
+ git switch --discard-changes --detach mainline/master
+
+ * In case you want to test a stable or longterm kernel, first add the branch
+ holding the series you are interested in (6.2 in the example), unless you
+ already did so earlier::
+
+ git remote set-branches --add stable linux-6.2.y
+
+ Then fetch the latest changes and check out the latest version from the
+ series::
+
+ git fetch stable
+ git switch --discard-changes --detach stable/linux-6.2.y
+
+* Copy your kernel build configuration over::
+
+ cp ~/kernel-config-working .config
+
+* Your next step depends on what you want to do:
+
+ * In case you just want to test the latest codebase, head to the next step,
+ you are already all set.
+
+ * In case you want to test if a revert fixes an issue, revert one or multiple
+ changes by specifying their commit ids::
+
+ git revert --no-edit cafec0cacaca0
+
+ Now give that kernel a special tag to facilitates its identification and
+ prevent accidentally overwriting another kernel::
+
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
+
+ * In case you want to test a patch, store the patch in a file like
+ '/tmp/foobars-proposed-fix-v1.patch' and apply it like this::
+
+ git apply /tmp/foobars-proposed-fix-v1.patch
+
+ In case of multiple patches, repeat this step with the others.
+
+ Now give that kernel a special tag to facilitates its identification and
+ prevent accidentally overwriting another kernel::
+
+ ./scripts/config --set-str CONFIG_LOCALVERSION '-local-foobars-fix-v1'
+
+* Build a kernel using the familiar commands, just without copying the kernel
+ build configuration over, as that has been taken care of already::
+
+ make olddefconfig &&
+ make -j $(nproc --all)
+ # * Check if the free space suffices holding another kernel:
+ df -h /boot/ /lib/modules/
+ sudo make modules_install
+ command -v installkernel && sudo make install
+ make -s kernelrelease | tee -a ~/kernels-built
+ reboot
+
+* Now verify you booted the newly built kernel and check it.
+
+[:ref:`details <introoptional_bisref>`]
+
+.. _submit_improvements_vbbr:
+
+Conclusion
+----------
+
+You have reached the end of the step-by-step guide.
+
+Did you run into trouble following any of the above steps not cleared up by the
+reference section below? Did you spot errors? Or do you have ideas how to
+improve the guide?
+
+If any of that applies, please take a moment and let the maintainer of this
+document know by email (Thorsten Leemhuis <linux@leemhuis.info>), ideally while
+CCing the Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is
+vital to improve this text further, which is in everybody's interest, as it
+will enable more people to master the task described here -- and hopefully also
+improve similar guides inspired by this one.
+
+
+Reference section for the step-by-step guide
+============================================
+
+This section holds additional information for almost all the items in the above
+step-by-step guide.
+
+Preparations for building your own kernels
+------------------------------------------
+
+ *The steps in this section lay the groundwork for all further tests.*
+ [:ref:`... <introprep_bissbs>`]
+
+The steps in all later sections of this guide depend on those described here.
+
+[:ref:`back to step-by-step guide <introprep_bissbs>`].
+
+.. _backup_bisref:
+
+Prepare for emergencies
+~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Create a fresh backup and put system repair and restore tools at hand.*
+ [:ref:`... <backup_bissbs>`]
+
+Remember, you are dealing with computers, which sometimes do unexpected things
+-- especially if you fiddle with crucial parts like the kernel of an operating
+system. That's what you are about to do in this process. Hence, better prepare
+for something going sideways, even if that should not happen.
+
+[:ref:`back to step-by-step guide <backup_bissbs>`]
+
+.. _vanilla_bisref:
+
+Remove anything related to externally maintained kernel modules
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Remove all software that depends on externally developed kernel drivers or
+ builds them automatically.* [:ref:`...<vanilla_bissbs>`]
+
+Externally developed kernel modules can easily cause trouble during a bisection.
+
+But there is a more important reason why this guide contains this step: most
+kernel developers will not care about reports about regressions occurring with
+kernels that utilize such modules. That's because such kernels are not
+considered 'vanilla' anymore, as Documentation/admin-guide/reporting-issues.rst
+explains in more detail.
+
+[:ref:`back to step-by-step guide <vanilla_bissbs>`]
+
+.. _secureboot_bisref:
+
+Deal with techniques like Secure Boot
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *On platforms with 'Secure Boot' or similar techniques, prepare everything to
+ ensure the system will permit your self-compiled kernel to boot later.*
+ [:ref:`... <secureboot_bissbs>`]
+
+Many modern systems allow only certain operating systems to start; that's why
+they reject booting self-compiled kernels by default.
+
+You ideally deal with this by making your platform trust your self-built kernels
+with the help of a certificate. How to do that is not described
+here, as it requires various steps that would take the text too far away from
+its purpose; 'Documentation/admin-guide/module-signing.rst' and various web
+sides already explain everything needed in more detail.
+
+Temporarily disabling solutions like Secure Boot is another way to make your own
+Linux boot. On commodity x86 systems it is possible to do this in the BIOS Setup
+utility; the required steps vary a lot between machines and therefore cannot be
+described here.
+
+On mainstream x86 Linux distributions there is a third and universal option:
+disable all Secure Boot restrictions for your Linux environment. You can
+initiate this process by running ``mokutil --disable-validation``; this will
+tell you to create a one-time password, which is safe to write down. Now
+restart; right after your BIOS performed all self-tests the bootloader Shim will
+show a blue box with a message 'Press any key to perform MOK management'. Hit
+some key before the countdown exposes, which will open a menu. Choose 'Change
+Secure Boot state'. Shim's 'MokManager' will now ask you to enter three
+randomly chosen characters from the one-time password specified earlier. Once
+you provided them, confirm you really want to disable the validation.
+Afterwards, permit MokManager to reboot the machine.
+
+[:ref:`back to step-by-step guide <secureboot_bissbs>`]
+
+.. _bootworking_bisref:
+
+Boot the last kernel that was working
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Boot into the last working kernel and briefly recheck if the feature that
+ regressed really works.* [:ref:`...<bootworking_bissbs>`]
+
+This will make later steps that cover creating and trimming the configuration do
+the right thing.
+
+[:ref:`back to step-by-step guide <bootworking_bissbs>`]
+
+.. _diskspace_bisref:
+
+Space requirements
+~~~~~~~~~~~~~~~~~~
+
+ *Ensure to have enough free space for building Linux.*
+ [:ref:`... <diskspace_bissbs>`]
+
+The numbers mentioned are rough estimates with a big extra charge to be on the
+safe side, so often you will need less.
+
+If you have space constraints, be sure to hay attention to the :ref:`step about
+debug symbols' <debugsymbols_bissbs>` and its :ref:`accompanying reference
+section' <debugsymbols_bisref>`, as disabling then will reduce the consumed disk
+space by quite a few gigabytes.
+
+[:ref:`back to step-by-step guide <diskspace_bissbs>`]
+
+.. _rangecheck_bisref:
+
+Bisection range
+~~~~~~~~~~~~~~~
+
+ *Determine the kernel versions considered 'good' and 'bad' throughout this
+ guide.* [:ref:`...<rangecheck_bissbs>`]
+
+Establishing the range of commits to be checked is mostly straightforward,
+except when a regression occurred when switching from a release of one stable
+series to a release of a later series (e.g. from 6.0.13 to 6.1.5). In that case
+Git will need some hand holding, as there is no straight line of descent.
+
+That's because with the release of 6.0 mainline carried on to 6.1 while the
+stable series 6.0.y branched to the side. It's therefore theoretically possible
+that the issue you face with 6.1.5 only worked in 6.0.13, as it was fixed by a
+commit that went into one of the 6.0.y releases, but never hit mainline or the
+6.1.y series. Thankfully that normally should not happen due to the way the
+stable/longterm maintainers maintain the code. It's thus pretty safe to assume
+6.0 as a 'good' kernel. That assumption will be tested anyway, as that kernel
+will be built and tested in the segment '2' of this guide; Git would force you
+to do this as well, if you tried bisecting between 6.0.13 and 6.1.15.
+
+[:ref:`back to step-by-step guide <rangecheck_bissbs>`]
+
+.. _buildrequires_bisref:
+
+Install build requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Install all software required to build a Linux kernel.*
+ [:ref:`...<buildrequires_bissbs>`]
+
+The kernel is pretty stand-alone, but besides tools like the compiler you will
+sometimes need a few libraries to build one. How to install everything needed
+depends on your Linux distribution and the configuration of the kernel you are
+about to build.
+
+Here are a few examples what you typically need on some mainstream
+distributions:
+
+* Arch Linux and derivatives::
+
+ sudo pacman --needed -S bc binutils bison flex gcc git kmod libelf openssl \
+ pahole perl zlib ncurses qt6-base
+
+* Debian, Ubuntu, and derivatives::
+
+ sudo apt install bc binutils bison dwarves flex gcc git kmod libelf-dev \
+ libssl-dev make openssl pahole perl-base pkg-config zlib1g-dev \
+ libncurses-dev qt6-base-dev g++
+
+* Fedora and derivatives::
+
+ sudo dnf install binutils \
+ /usr/bin/{bc,bison,flex,gcc,git,openssl,make,perl,pahole,rpmbuild} \
+ /usr/include/{libelf.h,openssl/pkcs7.h,zlib.h,ncurses.h,qt6/QtGui/QAction}
+
+* openSUSE and derivatives::
+
+ sudo zypper install bc binutils bison dwarves flex gcc git \
+ kernel-install-tools libelf-devel make modutils openssl openssl-devel \
+ perl-base zlib-devel rpm-build ncurses-devel qt6-base-devel
+
+These commands install a few packages that are often, but not always needed. You
+for example might want to skip installing the development headers for ncurses,
+which you will only need in case you later might want to adjust the kernel build
+configuration using make the targets 'menuconfig' or 'nconfig'; likewise omit
+the headers of Qt6 if you do not plan to adjust the .config using 'xconfig'.
+
+You furthermore might need additional libraries and their development headers
+for tasks not covered in this guide -- for example when building utilities from
+the kernel's tools/ directory.
+
+[:ref:`back to step-by-step guide <buildrequires_bissbs>`]
+
+.. _sources_bisref:
+
+Download the sources using Git
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Retrieve the Linux mainline sources.*
+ [:ref:`...<sources_bissbs>`]
+
+The step-by-step guide outlines how to download the Linux sources using a full
+Git clone of Linus' mainline repository. There is nothing more to say about
+that -- but there are two alternatives ways to retrieve the sources that might
+work better for you:
+
+* If you have an unreliable internet connection, consider
+ :ref:`using a 'Git bundle'<sources_bundle_bisref>`.
+
+* If downloading the complete repository would take too long or requires too
+ much storage space, consider :ref:`using a 'shallow
+ clone'<sources_shallow_bisref>`.
+
+.. _sources_bundle_bisref:
+
+Downloading Linux mainline sources using a bundle
+"""""""""""""""""""""""""""""""""""""""""""""""""
+
+Use the following commands to retrieve the Linux mainline sources using a
+bundle::
+
+ wget -c \
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle
+ git clone --no-checkout clone.bundle ~/linux/
+ cd ~/linux/
+ git remote remove origin
+ git remote add mainline \
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+ git fetch mainline
+ git remote add -t master stable \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+In case the 'wget' command fails, just re-execute it, it will pick up where
+it left off.
+
+[:ref:`back to step-by-step guide <sources_bissbs>`]
+[:ref:`back to section intro <sources_bisref>`]
+
+.. _sources_shallow_bisref:
+
+Downloading Linux mainline sources using a shallow clone
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First, execute the following command to retrieve the latest mainline codebase::
+
+ git clone -o mainline --no-checkout --depth 1 -b master \
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ~/linux/
+ cd ~/linux/
+ git remote add -t master stable \
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+Now deepen your clone's history to the second predecessor of the mainline
+release of your 'good' version. In case the latter are 6.0 or 6.0.13, 5.19 would
+be the first predecessor and 5.18 the second -- hence deepen the history up to
+that version::
+
+ git fetch --shallow-exclude=v5.18 mainline
+
+Afterwards add the stable Git repository as remote and all required stable
+branches as explained in the step-by-step guide.
+
+Note, shallow clones have a few peculiar characteristics:
+
+* For bisections the history needs to be deepened a few mainline versions
+ farther than it seems necessary, as explained above already. That's because
+ Git otherwise will be unable to revert or describe most of the commits within
+ a range (say 6.1..6.2), as they are internally based on earlier kernels
+ releases (like 6.0-rc2 or 5.19-rc3).
+
+* This document in most places uses ``git fetch`` with ``--shallow-exclude=``
+ to specify the earliest version you care about (or to be precise: its git
+ tag). You alternatively can use the parameter ``--shallow-since=`` to specify
+ an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to
+ define the depth of the history you want to download. When using them while
+ bisecting mainline, ensure to deepen the history to at least 7 months before
+ the release of the mainline release your 'good' kernel is based on.
+
+* Be warned, when deepening your clone you might encounter an error like
+ 'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'.
+ In that case run ``git repack -d`` and try again.
+
+[:ref:`back to step-by-step guide <sources_bissbs>`]
+[:ref:`back to section intro <sources_bisref>`]
+
+.. _oldconfig_bisref:
+
+Start defining the build configuration for your kernel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Start preparing a kernel build configuration (the '.config' file).*
+ [:ref:`... <oldconfig_bissbs>`]
+
+*Note, this is the first of multiple steps in this guide that create or modify
+build artifacts. The commands used in this guide store them right in the source
+tree to keep things simple. In case you prefer storing the build artifacts
+separately, create a directory like '~/linux-builddir/' and add the parameter
+``O=~/linux-builddir/`` to all make calls used throughout this guide. You will
+have to point other commands there as well -- among them the ``./scripts/config
+[...]`` commands, which will require ``--file ~/linux-builddir/.config`` to
+locate the right build configuration.*
+
+Two things can easily go wrong when creating a .config file as advised:
+
+* The oldconfig target will use a .config file from your build directory, if
+ one is already present there (e.g. '~/linux/.config'). That's totally fine if
+ that's what you intend (see next step), but in all other cases you want to
+ delete it. This for example is important in case you followed this guide
+ further, but due to problems come back here to redo the configuration from
+ scratch.
+
+* Sometimes olddefconfig is unable to locate the .config file for your running
+ kernel and will use defaults, as briefly outlined in the guide. In that case
+ check if your distribution ships the configuration somewhere and manually put
+ it in the right place (e.g. '~/linux/.config') if it does. On distributions
+ where /proc/config.gz exists this can be achieved using this command::
+
+ zcat /proc/config.gz > .config
+
+ Once you put it there, run ``make olddefconfig`` again to adjust it to the
+ needs of the kernel about to be built.
+
+Note, the olddefconfig target will set any undefined build options to their
+default value. If you prefer to set such configuration options manually, use
+``make oldconfig`` instead. Then for each undefined configuration option you
+will be asked how to proceed; in case you are unsure what to answer, simply hit
+'enter' to apply the default value. Note though that for bisections you normally
+want to go with the defaults, as you otherwise might enable a new feature that
+causes a problem looking like regressions (for example due to security
+restrictions).
+
+Occasionally odd things happen when trying to use a config file prepared for one
+kernel (say 6.1) on an older mainline release -- especially if it is much older
+(say 5.15). That's one of the reasons why the previous step in the guide told
+you to boot the kernel where everything works. If you manually add a .config
+file you thus want to ensure it's from the working kernel and not from a one
+that shows the regression.
+
+In case you want to build kernels for another machine, locate its kernel build
+configuration; usually ``ls /boot/config-$(uname -r)`` will print its name. Copy
+that file to the build machine and store it as ~/linux/.config; afterwards run
+``make olddefconfig`` to adjust it.
+
+[:ref:`back to step-by-step guide <oldconfig_bissbs>`]
+
+.. _localmodconfig_bisref:
+
+Trim the build configuration for your kernel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Disable any kernel modules apparently superfluous for your setup.*
+ [:ref:`... <localmodconfig_bissbs>`]
+
+As explained briefly in the step-by-step guide already: with localmodconfig it
+can easily happen that your self-built kernels will lack modules for tasks you
+did not perform at least once before utilizing this make target. That happens
+when a task requires kernel modules which are only autoloaded when you execute
+it for the first time. So when you never performed that task since starting your
+kernel the modules will not have been loaded -- and from localmodconfig's point
+of view look superfluous, which thus disables them to reduce the amount of code
+to be compiled.
+
+You can try to avoid this by performing typical tasks that often will autoload
+additional kernel modules: start a VM, establish VPN connections, loop-mount a
+CD/DVD ISO, mount network shares (CIFS, NFS, ...), and connect all external
+devices (2FA keys, headsets, webcams, ...) as well as storage devices with file
+systems you otherwise do not utilize (btrfs, ext4, FAT, NTFS, XFS, ...). But it
+is hard to think of everything that might be needed -- even kernel developers
+often forget one thing or another at this point.
+
+Do not let that risk bother you, especially when compiling a kernel only for
+testing purposes: everything typically crucial will be there. And if you forget
+something important you can turn on a missing feature manually later and quickly
+run the commands again to compile and install a kernel that has everything you
+need.
+
+But if you plan to build and use self-built kernels regularly, you might want to
+reduce the risk by recording which modules your system loads over the course of
+a few weeks. You can automate this with `modprobed-db
+<https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to
+point localmodconfig to the list of modules modprobed-db noticed being used::
+
+ yes '' | make LSMOD='${HOME}'/.config/modprobed.db localmodconfig
+
+That parameter also allows you to build trimmed kernels for another machine in
+case you copied a suitable .config over to use as base (see previous step). Just
+run ``lsmod > lsmod_foo-machine`` on that system and copy the generated file to
+your build's host home directory. Then run these commands instead of the one the
+step-by-step guide mentions::
+
+ yes '' | make LSMOD=~/lsmod_foo-machine localmodconfig
+
+[:ref:`back to step-by-step guide <localmodconfig_bissbs>`]
+
+.. _tagging_bisref:
+
+Tag the kernels about to be build
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Ensure all the kernels you will build are clearly identifiable using a
+ special tag and a unique version identifier.* [:ref:`... <tagging_bissbs>`]
+
+This allows you to differentiate your distribution's kernels from those created
+during this process, as the file or directories for the latter will contain
+'-local' in the name; it also helps picking the right entry in the boot menu and
+not lose track of you kernels, as their version numbers will look slightly
+confusing during the bisection.
+
+[:ref:`back to step-by-step guide <tagging_bissbs>`]
+
+.. _debugsymbols_bisref:
+
+Decide to enable or disable debug symbols
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Decide how to handle debug symbols.* [:ref:`... <debugsymbols_bissbs>`]
+
+Having debug symbols available can be important when your kernel throws a
+'panic', 'Oops', 'warning', or 'BUG' later when running, as then you will be
+able to find the exact place where the problem occurred in the code. But
+collecting and embedding the needed debug information takes time and consumes
+quite a bit of space: in late 2022 the build artifacts for a typical x86 kernel
+trimmed with localmodconfig consumed around 5 Gigabyte of space with debug
+symbols, but less than 1 when they were disabled. The resulting kernel image and
+modules are bigger as well, which increases storage requirements for /boot/ and
+load times.
+
+In case you want a small kernel and are unlikely to decode a stack trace later,
+you thus might want to disable debug symbols to avoid those downsides. If it
+later turns out that you need them, just enable them as shown and rebuild the
+kernel.
+
+You on the other hand definitely want to enable them for this process, if there
+is a decent chance that you need to decode a stack trace later. The section
+'Decode failure messages' in Documentation/admin-guide/reporting-issues.rst
+explains this process in more detail.
+
+[:ref:`back to step-by-step guide <debugsymbols_bissbs>`]
+
+.. _configmods_bisref:
+
+Adjust build configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check if you may want or need to adjust some other kernel configuration
+ options:*
+
+Depending on your needs you at this point might want or have to adjust some
+kernel configuration options.
+
+.. _configmods_distros_bisref:
+
+Distro specific adjustments
+"""""""""""""""""""""""""""
+
+ *Are you running* [:ref:`... <configmods_bissbs>`]
+
+The following sections help you to avoid build problems that are known to occur
+when following this guide on a few commodity distributions.
+
+**Debian:**
+
+* Remove a stale reference to a certificate file that would cause your build to
+ fail::
+
+ ./scripts/config --set-str SYSTEM_TRUSTED_KEYS ''
+
+ Alternatively, download the needed certificate and make that configuration
+ option point to it, as `the Debian handbook explains in more detail
+ <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_
+ -- or generate your own, as explained in
+ Documentation/admin-guide/module-signing.rst.
+
+[:ref:`back to step-by-step guide <configmods_bissbs>`]
+
+.. _configmods_individual_bisref:
+
+Individual adjustments
+""""""""""""""""""""""
+
+ *If you want to influence the other aspects of the configuration, do so
+ now.* [:ref:`... <configmods_bissbs>`]
+
+At this point you can use a command like ``make menuconfig`` or ``make nconfig``
+to enable or disable certain features using a text-based user interface; to use
+a graphical configuration utility, run ``make xconfig`` instead. Both of them
+require development libraries from toolkits they are rely on (ncurses
+respectively Qt5 or Qt6); an error message will tell you if something required
+is missing.
+
+[:ref:`back to step-by-step guide <configmods_bissbs>`]
+
+.. _saveconfig_bisref:
+
+Put the .config file aside
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Reprocess the .config after the latest changes and store it in a safe place.*
+ [:ref:`... <saveconfig_bissbs>`]
+
+Put the .config you prepared aside, as you want to copy it back to the build
+directory every time during this guide before you start building another
+kernel. That's because going back and forth between different versions can alter
+.config files in odd ways; those occasionally cause side effects that could
+confuse testing or in some cases render the result of your bisection
+meaningless.
+
+[:ref:`back to step-by-step guide <saveconfig_bissbs>`]
+
+.. _introlatestcheck_bisref:
+
+Try to reproduce the problem with the latest codebase
+-----------------------------------------------------
+
+ *Verify the regression is not caused by some .config change and check if it
+ still occurs with the latest codebase.* [:ref:`... <introlatestcheck_bissbs>`]
+
+For some readers it might seem unnecessary to check the latest codebase at this
+point, especially if you did that already with a kernel prepared by your
+distributor or face a regression within a stable/longterm series. But it's
+highly recommended for these reasons:
+
+* You will run into any problems caused by your setup before you actually begin
+ a bisection. That will make it a lot easier to differentiate between 'this
+ most likely is some problem in my setup' and 'this change needs to be skipped
+ during the bisection, as the kernel sources at that stage contain an unrelated
+ problem that causes building or booting to fail'.
+
+* These steps will rule out if your problem is caused by some change in the
+ build configuration between the 'working' and the 'broken' kernel. This for
+ example can happen when your distributor enabled an additional security
+ feature in the newer kernel which was disabled or not yet supported by the
+ older kernel. That security feature might get into the way of something you
+ do -- in which case your problem from the perspective of the Linux kernel
+ upstream developers is not a regression, as
+ Documentation/admin-guide/reporting-regressions.rst explains in more detail.
+ You thus would waste your time if you'd try to bisect this.
+
+* If the cause for your regression was already fixed in the latest mainline
+ codebase, you'd perform the bisection for nothing. This holds true for a
+ regression you encountered with a stable/longterm release as well, as they are
+ often caused by problems in mainline changes that were backported -- in which
+ case the problem will have to be fixed in mainline first. Maybe it already was
+ fixed there and the fix is already in the process of being backported.
+
+* For regressions within a stable/longterm series it's furthermore crucial to
+ know if the issue is specific to that series or also happens in the mainline
+ kernel, as the report needs to be sent to different people:
+
+ * Regressions specific to a stable/longterm series are the stable team's
+ responsibility; mainline Linux developers might or might not care.
+
+ * Regressions also happening in mainline are something the regular Linux
+ developers and maintainers have to handle; the stable team does not care
+ and does not need to be involved in the report, they just should be told
+ to backport the fix once it's ready.
+
+ Your report might be ignored if you send it to the wrong party -- and even
+ when you get a reply there is a decent chance that developers tell you to
+ evaluate which of the two cases it is before they take a closer look.
+
+[:ref:`back to step-by-step guide <introlatestcheck_bissbs>`]
+
+.. _checkoutmaster_bisref:
+
+Check out the latest Linux codebase
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check out the latest Linux codebase.*
+ [:ref:`... <checkoutmaster_bissbs>`]
+
+In case you later want to recheck if an ever newer codebase might fix the
+problem, remember to run that ``git fetch --shallow-exclude [...]`` command
+again mentioned earlier to update your local Git repository.
+
+[:ref:`back to step-by-step guide <checkoutmaster_bissbs>`]
+
+.. _build_bisref:
+
+Build your kernel
+~~~~~~~~~~~~~~~~~
+
+ *Build the image and the modules of your first kernel using the config file
+ you prepared.* [:ref:`... <build_bissbs>`]
+
+A lot can go wrong at this stage, but the instructions below will help you help
+yourself. Another subsection explains how to directly package your kernel up as
+deb, rpm or tar file.
+
+Dealing with build errors
+"""""""""""""""""""""""""
+
+When a build error occurs, it might be caused by some aspect of your machine's
+setup that often can be fixed quickly; other times though the problem lies in
+the code and can only be fixed by a developer. A close examination of the
+failure messages coupled with some research on the internet will often tell you
+which of the two it is. To perform such investigation, restart the build
+process like this::
+
+ make V=1
+
+The ``V=1`` activates verbose output, which might be needed to see the actual
+error. To make it easier to spot, this command also omits the ``-j $(nproc
+--all)`` used earlier to utilize every CPU core in the system for the job -- but
+this parallelism also results in some clutter when failures occur.
+
+After a few seconds the build process should run into the error again. Now try
+to find the most crucial line describing the problem. Then search the internet
+for the most important and non-generic section of that line (say 4 to 8 words);
+avoid or remove anything that looks remotely system-specific, like your username
+or local path names like ``/home/username/linux/``. First try your regular
+internet search engine with that string, afterwards search Linux kernel mailing
+lists via `lore.kernel.org/all/ <https://lore.kernel.org/all/>`_.
+
+This most of the time will find something that will explain what is wrong; quite
+often one of the hits will provide a solution for your problem, too. If you
+do not find anything that matches your problem, try again from a different angle
+by modifying your search terms or using another line from the error messages.
+
+In the end, most issues you run into have likely been encountered and
+reported by others already. That includes issues where the cause is not your
+system, but lies in the code. If you run into one of those, you might thus find
+a solution (e.g. a patch) or workaround for your issue, too.
+
+Package your kernel up
+""""""""""""""""""""""
+
+The step-by-step guide uses the default make targets (e.g. 'bzImage' and
+'modules' on x86) to build the image and the modules of your kernel, which later
+steps of the guide then install. You instead can also directly build everything
+and directly package it up by using one of the following targets:
+
+* ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package
+
+* ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package
+
+* ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball
+
+This is just a selection of available make targets for this purpose, see
+``make help`` for others. You can also use these targets after running
+``make -j $(nproc --all)``, as they will pick up everything already built.
+
+If you employ the targets to generate deb or rpm packages, ignore the
+step-by-step guide's instructions on installing and removing your kernel;
+instead install and remove the packages using the package utility for the format
+(e.g. dpkg and rpm) or a package management utility build on top of them (apt,
+aptitude, dnf/yum, zypper, ...). Be aware that the packages generated using
+these two make targets are designed to work on various distributions utilizing
+those formats, they thus will sometimes behave differently than your
+distribution's kernel packages.
+
+[:ref:`back to step-by-step guide <build_bissbs>`]
+
+.. _install_bisref:
+
+Put the kernel in place
+~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Install the kernel you just built.* [:ref:`... <install_bissbs>`]
+
+What you need to do after executing the command in the step-by-step guide
+depends on the existence and the implementation of ``/sbin/installkernel``
+executable on your distribution.
+
+If installkernel is found, the kernel's build system will delegate the actual
+installation of your kernel image to this executable, which then performs some
+or all of these tasks:
+
+* On almost all Linux distributions installkernel will store your kernel's
+ image in /boot/, usually as '/boot/vmlinuz-<kernelrelease_id>'; often it will
+ put a 'System.map-<kernelrelease_id>' alongside it.
+
+* On most distributions installkernel will then generate an 'initramfs'
+ (sometimes also called 'initrd'), which usually are stored as
+ '/boot/initramfs-<kernelrelease_id>.img' or
+ '/boot/initrd-<kernelrelease_id>'. Commodity distributions rely on this file
+ for booting, hence ensure to execute the make target 'modules_install' first,
+ as your distribution's initramfs generator otherwise will be unable to find
+ the modules that go into the image.
+
+* On some distributions installkernel will then add an entry for your kernel
+ to your bootloader's configuration.
+
+You have to take care of some or all of the tasks yourself, if your
+distribution lacks an installkernel script or does only handle part of them.
+Consult the distribution's documentation for details. If in doubt, install the
+kernel manually::
+
+ sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease)
+ sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease)
+
+Now generate your initramfs using the tools your distribution provides for this
+process. Afterwards add your kernel to your bootloader configuration and reboot.
+
+[:ref:`back to step-by-step guide <install_bissbs>`]
+
+.. _storagespace_bisref:
+
+Storage requirements per kernel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check how much storage space the kernel, its modules, and other related files
+ like the initramfs consume.* [:ref:`... <storagespace_bissbs>`]
+
+The kernels built during a bisection consume quite a bit of space in /boot/ and
+/lib/modules/, especially if you enabled debug symbols. That makes it easy to
+fill up volumes during a bisection -- and due to that even kernels which used to
+work earlier might fail to boot. To prevent that you will need to know how much
+space each installed kernel typically requires.
+
+Note, most of the time the pattern '/boot/*$(make -s kernelrelease)*' used in
+the guide will match all files needed to boot your kernel -- but neither the
+path nor the naming scheme are mandatory. On some distributions you thus will
+need to look in different places.
+
+[:ref:`back to step-by-step guide <storagespace_bissbs>`]
+
+.. _tainted_bisref:
+
+Check if your newly built kernel considers itself 'tainted'
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Check if the kernel marked itself as 'tainted'.*
+ [:ref:`... <tainted_bissbs>`]
+
+Linux marks itself as tainted when something happens that potentially leads to
+follow-up errors that look totally unrelated. That is why developers might
+ignore or react scantly to reports from tainted kernels -- unless of course the
+kernel set the flag right when the reported bug occurred.
+
+That's why you want check why a kernel is tainted as explained in
+Documentation/admin-guide/tainted-kernels.rst; doing so is also in your own
+interest, as your testing might be flawed otherwise.
+
+[:ref:`back to step-by-step guide <tainted_bissbs>`]
+
+.. _recheckbroken_bisref:
+
+Check the kernel built from a recent mainline codebase
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Verify if your bug occurs with the newly built kernel.*
+ [:ref:`... <recheckbroken_bissbs>`]
+
+There are a couple of reasons why your bug or regression might not show up with
+the kernel you built from the latest codebase. These are the most frequent:
+
+* The bug was fixed meanwhile.
+
+* What you suspected to be a regression was caused by a change in the build
+ configuration the provider of your kernel carried out.
+
+* Your problem might be a race condition that does not show up with your kernel;
+ the trimmed build configuration, a different setting for debug symbols, the
+ compiler used, and various other things can cause this.
+
+* In case you encountered the regression with a stable/longterm kernel it might
+ be a problem that is specific to that series; the next step in this guide will
+ check this.
+
+[:ref:`back to step-by-step guide <recheckbroken_bissbs>`]
+
+.. _recheckstablebroken_bisref:
+
+Check the kernel built from the latest stable/longterm codebase
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Are you facing a regression within a stable/longterm release, but failed to
+ reproduce it with the kernel you just built using the latest mainline sources?
+ Then check if the latest codebase for the particular series might already fix
+ the problem.* [:ref:`... <recheckstablebroken_bissbs>`]
+
+If this kernel does not show the regression either, there most likely is no need
+for a bisection.
+
+[:ref:`back to step-by-step guide <recheckstablebroken_bissbs>`]
+
+.. _introworkingcheck_bisref:
+
+Ensure the 'good' version is really working well
+------------------------------------------------
+
+ *Check if the kernels you build work fine.*
+ [:ref:`... <introworkingcheck_bissbs>`]
+
+This section will reestablish a known working base. Skipping it might be
+appealing, but is usually a bad idea, as it does something important:
+
+It will ensure the .config file you prepared earlier actually works as expected.
+That is in your own interest, as trimming the configuration is not foolproof --
+and you might be building and testing ten or more kernels for nothing before
+starting to suspect something might be wrong with the build configuration.
+
+That alone is reason enough to spend the time on this, but not the only reason.
+
+Many readers of this guide normally run kernels that are patched, use add-on
+modules, or both. Those kernels thus are not considered 'vanilla' -- therefore
+it's possible that the thing that regressed might never have worked in vanilla
+builds of the 'good' version in the first place.
+
+There is a third reason for those that noticed a regression between
+stable/longterm kernels of different series (e.g. 6.0.13..6.1.5): it will
+ensure the kernel version you assumed to be 'good' earlier in the process (e.g.
+6.0) actually is working.
+
+[:ref:`back to step-by-step guide <introworkingcheck_bissbs>`]
+
+.. _recheckworking_bisref:
+
+Build your own version of the 'good' kernel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Build your own variant of the working kernel and check if the feature that
+ regressed works as expected with it.* [:ref:`... <recheckworking_bissbs>`]
+
+In case the feature that broke with newer kernels does not work with your first
+self-built kernel, find and resolve the cause before moving on. There are a
+multitude of reasons why this might happen. Some ideas where to look:
+
+* Check the taint status and the output of ``dmesg``, maybe something unrelated
+ went wrong.
+
+* Maybe localmodconfig did something odd and disabled the module required to
+ test the feature? Then you might want to recreate a .config file based on the
+ one from the last working kernel and skip trimming it down; manually disabling
+ some features in the .config might work as well to reduce the build time.
+
+* Maybe it's not a kernel regression and something that is caused by some fluke,
+ a broken initramfs (also known as initrd), new firmware files, or an updated
+ userland software?
+
+* Maybe it was a feature added to your distributor's kernel which vanilla Linux
+ at that point never supported?
+
+Note, if you found and fixed problems with the .config file, you want to use it
+to build another kernel from the latest codebase, as your earlier tests with
+mainline and the latest version from an affected stable/longterm series were
+most likely flawed.
+
+[:ref:`back to step-by-step guide <recheckworking_bissbs>`]
+
+Perform a bisection and validate the result
+-------------------------------------------
+
+ *With all the preparations and precaution builds taken care of, you are now
+ ready to begin the bisection.* [:ref:`... <introbisect_bissbs>`]
+
+The steps in this segment perform and validate the bisection.
+
+[:ref:`back to step-by-step guide <introbisect_bissbs>`].
+
+.. _bisectstart_bisref:
+
+Start the bisection
+~~~~~~~~~~~~~~~~~~~
+
+ *Start the bisection and tell Git about the versions earlier established as
+ 'good' and 'bad'.* [:ref:`... <bisectstart_bissbs>`]
+
+This will start the bisection process; the last of the commands will make Git
+check out a commit round about half-way between the 'good' and the 'bad' changes
+for you to test.
+
+[:ref:`back to step-by-step guide <bisectstart_bissbs>`]
+
+.. _bisectbuild_bisref:
+
+Build a kernel from the bisection point
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Build, install, and boot a kernel from the code Git checked out using the
+ same commands you used earlier.* [:ref:`... <bisectbuild_bissbs>`]
+
+There are two things worth of note here:
+
+* Occasionally building the kernel will fail or it might not boot due some
+ problem in the code at the bisection point. In that case run this command::
+
+ git bisect skip
+
+ Git will then check out another commit nearby which with a bit of luck should
+ work better. Afterwards restart executing this step.
+
+* Those slightly odd looking version identifiers can happen during bisections,
+ because the Linux kernel subsystems prepare their changes for a new mainline
+ release (say 6.2) before its predecessor (e.g. 6.1) is finished. They thus
+ base them on a somewhat earlier point like 6.1-rc1 or even 6.0 -- and then
+ get merged for 6.2 without rebasing nor squashing them once 6.1 is out. This
+ leads to those slightly odd looking version identifiers coming up during
+ bisections.
+
+[:ref:`back to step-by-step guide <bisectbuild_bissbs>`]
+
+.. _bisecttest_bisref:
+
+Bisection checkpoint
+~~~~~~~~~~~~~~~~~~~~
+
+ *Check if the feature that regressed works in the kernel you just built.*
+ [:ref:`... <bisecttest_bissbs>`]
+
+Ensure what you tell Git is accurate: getting it wrong just one time will bring
+the rest of the bisection totally off course, hence all testing after that point
+will be for nothing.
+
+[:ref:`back to step-by-step guide <bisecttest_bissbs>`]
+
+.. _bisectlog_bisref:
+
+Put the bisection log away
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Store Git's bisection log and the current .config file in a safe place.*
+ [:ref:`... <bisectlog_bissbs>`]
+
+As indicated above: declaring just one kernel wrongly as 'good' or 'bad' will
+render the end result of a bisection useless. In that case you'd normally have
+to restart the bisection from scratch. The log can prevent that, as it might
+allow someone to point out where a bisection likely went sideways -- and then
+instead of testing ten or more kernels you might only have to build a few to
+resolve things.
+
+The .config file is put aside, as there is a decent chance that developers might
+ask for it after you report the regression.
+
+[:ref:`back to step-by-step guide <bisectlog_bissbs>`]
+
+.. _revert_bisref:
+
+Try reverting the culprit
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *Try reverting the culprit on top of the latest codebase to see if this fixes
+ your regression.* [:ref:`... <revert_bissbs>`]
+
+This is an optional step, but whenever possible one you should try: there is a
+decent chance that developers will ask you to perform this step when you bring
+the bisection result up. So give it a try, you are in the flow already, building
+one more kernel shouldn't be a big deal at this point.
+
+The step-by-step guide covers everything relevant already except one slightly
+rare thing: did you bisected a regression that also happened with mainline using
+a stable/longterm series, but Git failed to revert the commit in mainline? Then
+try to revert the culprit in the affected stable/longterm series -- and if that
+succeeds, test that kernel version instead.
+
+[:ref:`back to step-by-step guide <revert_bissbs>`]
+
+Cleanup steps during and after following this guide
+---------------------------------------------------
+
+ *During and after following this guide you might want or need to remove some
+ of the kernels you installed.* [:ref:`... <introclosure_bissbs>`]
+
+The steps in this section describe clean-up procedures.
+
+[:ref:`back to step-by-step guide <introclosure_bissbs>`].
+
+.. _makeroom_bisref:
+
+Cleaning up during the bisection
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ *To remove one of the kernels you installed, look up its 'kernelrelease'
+ identifier.* [:ref:`... <makeroom_bissbs>`]
+
+The kernels you install during this process are easy to remove later, as its
+parts are only stored in two places and clearly identifiable. You thus do not
+need to worry to mess up your machine when you install a kernel manually (and
+thus bypass your distribution's packaging system): all parts of your kernels are
+relatively easy to remove later.
+
+One of the two places is a directory in /lib/modules/, which holds the modules
+for each installed kernel. This directory is named after the kernel's release
+identifier; hence, to remove all modules for one of the kernels you built,
+simply remove its modules directory in /lib/modules/.
+
+The other place is /boot/, where typically two up to five files will be placed
+during installation of a kernel. All of them usually contain the release name in
+their file name, but how many files and their exact names depend somewhat on
+your distribution's installkernel executable and its initramfs generator. On
+some distributions the ``kernel-install remove...`` command mentioned in the
+step-by-step guide will delete all of these files for you while also removing
+the menu entry for the kernel from your bootloader configuration. On others you
+have to take care of these two tasks yourself. The following command should
+interactively remove the three main files of a kernel with the release name
+'6.0-rc1-local-gcafec0cacaca0'::
+
+ rm -i /boot/{System.map,vmlinuz,initr}-6.0-rc1-local-gcafec0cacaca0
+
+Afterwards check for other files in /boot/ that have
+'6.0-rc1-local-gcafec0cacaca0' in their name and consider deleting them as well.
+Now remove the boot entry for the kernel from your bootloader's configuration;
+the steps to do that vary quite a bit between Linux distributions.
+
+Note, be careful with wildcards like '*' when deleting files or directories
+for kernels manually: you might accidentally remove files of a 6.0.13 kernel
+when all you want is to remove 6.0 or 6.0.1.
+
+[:ref:`back to step-by-step guide <makeroom_bissbs>`]
+
+Cleaning up after the bisection
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _finishingtouch_bisref:
+
+ *Once you have finished the bisection, do not immediately remove anything
+ you set up, as you might need a few things again.*
+ [:ref:`... <finishingtouch_bissbs>`]
+
+When you are really short of storage space removing the kernels as described in
+the step-by-step guide might not free as much space as you would like. In that
+case consider running ``rm -rf ~/linux/*`` as well now. This will remove the
+build artifacts and the Linux sources, but will leave the Git repository
+(~/linux/.git/) behind -- a simple ``git reset --hard`` thus will bring the
+sources back.
+
+Removing the repository as well would likely be unwise at this point: there
+is a decent chance developers will ask you to build another kernel to
+perform additional tests -- like testing a debug patch or a proposed fix.
+Details on how to perform those can be found in the section :ref:`Optional
+tasks: test reverts, patches, or later versions <introoptional_bissbs>`.
+
+Additional tests are also the reason why you want to keep the
+~/kernel-config-working file around for a few weeks.
+
+[:ref:`back to step-by-step guide <finishingtouch_bissbs>`]
+
+.. _introoptional_bisref:
+
+Test reverts, patches, or later versions
+----------------------------------------
+
+ *While or after reporting a bug, you might want or potentially will be asked
+ to test reverts, patches, proposed fixes, or other versions.*
+ [:ref:`... <introoptional_bissbs>`]
+
+All the commands used in this section should be pretty straight forward, so
+there is not much to add except one thing: when setting a kernel tag as
+instructed, ensure it is not much longer than the one used in the example, as
+problems will arise if the kernelrelease identifier exceeds 63 characters.
+
+[:ref:`back to step-by-step guide <introoptional_bissbs>`].
+
+
+Additional information
+======================
+
+.. _buildhost_bis:
+
+Build kernels on a different machine
+------------------------------------
+
+To compile kernels on another system, slightly alter the step-by-step guide's
+instructions:
+
+* Start following the guide on the machine where you want to install and test
+ the kernels later.
+
+* After executing ':ref:`Boot into the working kernel and briefly use the
+ apparently broken feature <bootworking_bissbs>`', save the list of loaded
+ modules to a file using ``lsmod > ~/test-machine-lsmod``. Then locate the
+ build configuration for the running kernel (see ':ref:`Start defining the
+ build configuration for your kernel <oldconfig_bisref>`' for hints on where
+ to find it) and store it as '~/test-machine-config-working'. Transfer both
+ files to the home directory of your build host.
+
+* Continue the guide on the build host (e.g. with ':ref:`Ensure to have enough
+ free space for building [...] <diskspace_bissbs>`').
+
+* When you reach ':ref:`Start preparing a kernel build configuration[...]
+ <oldconfig_bissbs>`': before running ``make olddefconfig`` for the first time,
+ execute the following command to base your configuration on the one from the
+ test machine's 'working' kernel::
+
+ cp ~/test-machine-config-working ~/linux/.config
+
+* During the next step to ':ref:`disable any apparently superfluous kernel
+ modules <localmodconfig_bissbs>`' use the following command instead::
+
+ yes '' | make localmodconfig LSMOD=~/lsmod_foo-machine localmodconfig
+
+* Continue the guide, but ignore the instructions outlining how to compile,
+ install, and reboot into a kernel every time they come up. Instead build
+ like this::
+
+ cp ~/kernel-config-working .config
+ make olddefconfig &&
+ make -j $(nproc --all) targz-pkg
+
+ This will generate a gzipped tar file whose name is printed in the last
+ line shown; for example, a kernel with the kernelrelease identifier
+ '6.0.0-rc1-local-g928a87efa423' built for x86 machines usually will
+ be stored as '~/linux/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz'.
+
+ Copy that file to your test machine's home directory.
+
+* Switch to the test machine to check if you have enough space to hold another
+ kernel. Then extract the file you transferred::
+
+ sudo tar -xvzf ~/linux-6.0.0-rc1-local-g928a87efa423-x86.tar.gz -C /
+
+ Afterwards :ref:`generate the initramfs and add the kernel to your boot
+ loader's configuration <install_bisref>`; on some distributions the following
+ command will take care of both these tasks::
+
+ sudo /sbin/installkernel 6.0.0-rc1-local-g928a87efa423 /boot/vmlinuz-6.0.0-rc1-local-g928a87efa423
+
+ Now reboot and ensure you started the intended kernel.
+
+This approach even works when building for another architecture: just install
+cross-compilers and add the appropriate parameters to every invocation of make
+(e.g. ``make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- [...]``).
+
+Additional reading material
+---------------------------
+
+* The `man page for 'git bisect' <https://git-scm.com/docs/git-bisect>`_ and
+ `fighting regressions with 'git bisect' <https://git-scm.com/docs/git-bisect-lk2009.html>`_
+ in the Git documentation.
+* `Working with git bisect <https://nathanchance.dev/posts/working-with-git-bisect/>`_
+ from kernel developer Nathan Chancellor.
+* `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_.
+* `Fully automated bisecting with 'git bisect run' <https://lwn.net/Articles/317154>`_.
+
+..
+ end-of-content
+..
+ This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If
+ you spot a typo or small mistake, feel free to let him know directly and
+ he'll fix it. You are free to do the same in a mostly informal way if you
+ want to contribute changes to the text -- but for copyright reasons please CC
+ linux-doc@vger.kernel.org and 'sign-off' your contribution as
+ Documentation/process/submitting-patches.rst explains in the section 'Sign
+ your work - the Developer's Certificate of Origin'.
+..
+ This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
+ of the file. If you want to distribute this text under CC-BY-4.0 only,
+ please use 'The Linux kernel development community' for author attribution
+ and link this as source:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
+
+..
+ Note: Only the content of this RST file as found in the Linux kernel sources
+ is available under CC-BY-4.0, as versions of this text that were processed
+ (for example by the kernel's build system) might contain content taken from
+ files which use a more restrictive license.
diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst
new file mode 100644
index 000000000000..35963491b9f1
--- /dev/null
+++ b/Documentation/admin-guide/workload-tracing.rst
@@ -0,0 +1,606 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+
+======================================================
+Discovering Linux kernel subsystems used by a workload
+======================================================
+
+:Authors: - Shuah Khan <skhan@linuxfoundation.org>
+ - Shefali Sharma <sshefali021@gmail.com>
+:maintained-by: Shuah Khan <skhan@linuxfoundation.org>
+
+Key Points
+==========
+
+ * Understanding system resources necessary to build and run a workload
+ is important.
+ * Linux tracing and strace can be used to discover the system resources
+ in use by a workload. The completeness of the system usage information
+ depends on the completeness of coverage of a workload.
+ * Performance and security of the operating system can be analyzed with
+ the help of tools such as:
+ `perf <https://man7.org/linux/man-pages/man1/perf.1.html>`_,
+ `stress-ng <https://www.mankier.com/1/stress-ng>`_,
+ `paxtest <https://github.com/opntr/paxtest-freebsd>`_.
+ * Once we discover and understand the workload needs, we can focus on them
+ to avoid regressions and use it to evaluate safety considerations.
+
+Methodology
+===========
+
+`strace <https://man7.org/linux/man-pages/man1/strace.1.html>`_ is a
+diagnostic, instructional, and debugging tool and can be used to discover
+the system resources in use by a workload. Once we discover and understand
+the workload needs, we can focus on them to avoid regressions and use it
+to evaluate safety considerations. We use strace tool to trace workloads.
+
+This method of tracing using strace tells us the system calls invoked by
+the workload and doesn't include all the system calls that can be invoked
+by it. In addition, this tracing method tells us just the code paths within
+these system calls that are invoked. As an example, if a workload opens a
+file and reads from it successfully, then the success path is the one that
+is traced. Any error paths in that system call will not be traced. If there
+is a workload that provides full coverage of a workload then the method
+outlined here will trace and find all possible code paths. The completeness
+of the system usage information depends on the completeness of coverage of a
+workload.
+
+The goal is tracing a workload on a system running a default kernel without
+requiring custom kernel installs.
+
+How do we gather fine-grained system information?
+=================================================
+
+strace tool can be used to trace system calls made by a process and signals
+it receives. System calls are the fundamental interface between an
+application and the operating system kernel. They enable a program to
+request services from the kernel. For instance, the open() system call in
+Linux is used to provide access to a file in the file system. strace enables
+us to track all the system calls made by an application. It lists all the
+system calls made by a process and their resulting output.
+
+You can generate profiling data combining strace and perf record tools to
+record the events and information associated with a process. This provides
+insight into the process. "perf annotate" tool generates the statistics of
+each instruction of the program. This document goes over the details of how
+to gather fine-grained information on a workload's usage of system resources.
+
+We used strace to trace the perf, stress-ng, paxtest workloads to illustrate
+our methodology to discover resources used by a workload. This process can
+be applied to trace other workloads.
+
+Getting the system ready for tracing
+====================================
+
+Before we can get started we will show you how to get your system ready.
+We assume that you have a Linux distribution running on a physical system
+or a virtual machine. Most distributions will include strace command. Let’s
+install other tools that aren’t usually included to build Linux kernel.
+Please note that the following works on Debian based distributions. You
+might have to find equivalent packages on other Linux distributions.
+
+Install tools to build Linux kernel and tools in kernel repository.
+scripts/ver_linux is a good way to check if your system already has
+the necessary tools::
+
+ sudo apt-get install build-essential flex bison yacc
+ sudo apt install libelf-dev systemtap-sdt-dev libslang2-dev libperl-dev libdw-dev
+
+cscope is a good tool to browse kernel sources. Let's install it now::
+
+ sudo apt-get install cscope
+
+Install stress-ng and paxtest::
+
+ apt-get install stress-ng
+ apt-get install paxtest
+
+Workload overview
+=================
+
+As mentioned earlier, we used strace to trace perf bench, stress-ng and
+paxtest workloads to show how to analyze a workload and identify Linux
+subsystems used by these workloads. Let's start with an overview of these
+three workloads to get a better understanding of what they do and how to
+use them.
+
+perf bench (all) workload
+-------------------------
+
+The perf bench command contains multiple multi-threaded microkernel
+benchmarks for executing different subsystems in the Linux kernel and
+system calls. This allows us to easily measure the impact of changes,
+which can help mitigate performance regressions. It also acts as a common
+benchmarking framework, enabling developers to easily create test cases,
+integrate transparently, and use performance-rich tooling subsystems.
+
+Stress-ng netdev stressor workload
+----------------------------------
+
+stress-ng is used for performing stress testing on the kernel. It allows
+you to exercise various physical subsystems of the computer, as well as
+interfaces of the OS kernel, using "stressor-s". They are available for
+CPU, CPU cache, devices, I/O, interrupts, file system, memory, network,
+operating system, pipelines, schedulers, and virtual machines. Please refer
+to the `stress-ng man-page <https://www.mankier.com/1/stress-ng>`_ to
+find the description of all the available stressor-s. The netdev stressor
+starts specified number (N) of workers that exercise various netdevice
+ioctl commands across all the available network devices.
+
+paxtest kiddie workload
+-----------------------
+
+paxtest is a program that tests buffer overflows in the kernel. It tests
+kernel enforcements over memory usage. Generally, execution in some memory
+segments makes buffer overflows possible. It runs a set of programs that
+attempt to subvert memory usage. It is used as a regression test suite for
+PaX, but might be useful to test other memory protection patches for the
+kernel. We used paxtest kiddie mode which looks for simple vulnerabilities.
+
+What is strace and how do we use it?
+====================================
+
+As mentioned earlier, strace which is a useful diagnostic, instructional,
+and debugging tool and can be used to discover the system resources in use
+by a workload. It can be used:
+
+ * To see how a process interacts with the kernel.
+ * To see why a process is failing or hanging.
+ * For reverse engineering a process.
+ * To find the files on which a program depends.
+ * For analyzing the performance of an application.
+ * For troubleshooting various problems related to the operating system.
+
+In addition, strace can generate run-time statistics on times, calls, and
+errors for each system call and report a summary when program exits,
+suppressing the regular output. This attempts to show system time (CPU time
+spent running in the kernel) independent of wall clock time. We plan to use
+these features to get information on workload system usage.
+
+strace command supports basic, verbose, and stats modes. strace command when
+run in verbose mode gives more detailed information about the system calls
+invoked by a process.
+
+Running strace -c generates a report of the percentage of time spent in each
+system call, the total time in seconds, the microseconds per call, the total
+number of calls, the count of each system call that has failed with an error
+and the type of system call made.
+
+ * Usage: strace <command we want to trace>
+ * Verbose mode usage: strace -v <command>
+ * Gather statistics: strace -c <command>
+
+We used the “-c” option to gather fine-grained run-time statistics in use
+by three workloads we have chose for this analysis.
+
+ * perf
+ * stress-ng
+ * paxtest
+
+What is cscope and how do we use it?
+====================================
+
+Now let’s look at `cscope <https://cscope.sourceforge.net/>`_, a command
+line tool for browsing C, C++ or Java code-bases. We can use it to find
+all the references to a symbol, global definitions, functions called by a
+function, functions calling a function, text strings, regular expression
+patterns, files including a file.
+
+We can use cscope to find which system call belongs to which subsystem.
+This way we can find the kernel subsystems used by a process when it is
+executed.
+
+Let’s checkout the latest Linux repository and build cscope database::
+
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
+ cd linux
+ cscope -R -p10 # builds cscope.out database before starting browse session
+ cscope -d -p10 # starts browse session on cscope.out database
+
+Note: Run "cscope -R -p10" to build the database and "cscope -d -p10" to
+enter into the browsing session. cscope by default uses the cscope.out
+database. To get out of this mode press ctrl+d. -p option is used to
+specify the number of file path components to display. -p10 is optimal
+for browsing kernel sources.
+
+What is perf and how do we use it?
+==================================
+
+Perf is an analysis tool based on Linux 2.6+ systems, which abstracts the
+CPU hardware difference in performance measurement in Linux, and provides
+a simple command line interface. Perf is based on the perf_events interface
+exported by the kernel. It is very useful for profiling the system and
+finding performance bottlenecks in an application.
+
+If you haven't already checked out the Linux mainline repository, you can do
+so and then build kernel and perf tool::
+
+ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
+ cd linux
+ make -j3 all
+ cd tools/perf
+ make
+
+Note: The perf command can be built without building the kernel in the
+repository and can be run on older kernels. However matching the kernel
+and perf revisions gives more accurate information on the subsystem usage.
+
+We used "perf stat" and "perf bench" options. For a detailed information on
+the perf tool, run "perf -h".
+
+perf stat
+---------
+The perf stat command generates a report of various hardware and software
+events. It does so with the help of hardware counter registers found in
+modern CPUs that keep the count of these activities. "perf stat cal" shows
+stats for cal command.
+
+Perf bench
+----------
+The perf bench command contains multiple multi-threaded microkernel
+benchmarks for executing different subsystems in the Linux kernel and
+system calls. This allows us to easily measure the impact of changes,
+which can help mitigate performance regressions. It also acts as a common
+benchmarking framework, enabling developers to easily create test cases,
+integrate transparently, and use performance-rich tooling.
+
+"perf bench all" command runs the following benchmarks:
+
+ * sched/messaging
+ * sched/pipe
+ * syscall/basic
+ * mem/memcpy
+ * mem/memset
+
+What is stress-ng and how do we use it?
+=======================================
+
+As mentioned earlier, stress-ng is used for performing stress testing on
+the kernel. It allows you to exercise various physical subsystems of the
+computer, as well as interfaces of the OS kernel, using stressor-s. They
+are available for CPU, CPU cache, devices, I/O, interrupts, file system,
+memory, network, operating system, pipelines, schedulers, and virtual
+machines.
+
+The netdev stressor starts N workers that exercise various netdevice ioctl
+commands across all the available network devices. The following ioctls are
+exercised:
+
+ * SIOCGIFCONF, SIOCGIFINDEX, SIOCGIFNAME, SIOCGIFFLAGS
+ * SIOCGIFADDR, SIOCGIFNETMASK, SIOCGIFMETRIC, SIOCGIFMTU
+ * SIOCGIFHWADDR, SIOCGIFMAP, SIOCGIFTXQLEN
+
+The following command runs the stressor::
+
+ stress-ng --netdev 1 -t 60 --metrics command.
+
+We can use the perf record command to record the events and information
+associated with a process. This command records the profiling data in the
+perf.data file in the same directory.
+
+Using the following commands you can record the events associated with the
+netdev stressor, view the generated report perf.data and annotate the to
+view the statistics of each instruction of the program::
+
+ perf record stress-ng --netdev 1 -t 60 --metrics command.
+ perf report
+ perf annotate
+
+What is paxtest and how do we use it?
+=====================================
+
+paxtest is a program that tests buffer overflows in the kernel. It tests
+kernel enforcements over memory usage. Generally, execution in some memory
+segments makes buffer overflows possible. It runs a set of programs that
+attempt to subvert memory usage. It is used as a regression test suite for
+PaX, and will be useful to test other memory protection patches for the
+kernel.
+
+paxtest provides kiddie and blackhat modes. The paxtest kiddie mode runs
+in normal mode, whereas the blackhat mode tries to get around the protection
+of the kernel testing for vulnerabilities. We focus on the kiddie mode here
+and combine "paxtest kiddie" run with "perf record" to collect CPU stack
+traces for the paxtest kiddie run to see which function is calling other
+functions in the performance profile. Then the "dwarf" (DWARF's Call Frame
+Information) mode can be used to unwind the stack.
+
+The following command can be used to view resulting report in call-graph
+format::
+
+ perf record --call-graph dwarf paxtest kiddie
+ perf report --stdio
+
+Tracing workloads
+=================
+
+Now that we understand the workloads, let's start tracing them.
+
+Tracing perf bench all workload
+-------------------------------
+
+Run the following command to trace perf bench all workload::
+
+ strace -c perf bench all
+
+**System Calls made by the workload**
+
+The below table shows the system calls invoked by the workload, number of
+times each system call is invoked, and the corresponding Linux subsystem.
+
++-------------------+-----------+-----------------+-------------------------+
+| System Call | # calls | Linux Subsystem | System Call (API) |
++===================+===========+=================+=========================+
+| getppid | 10000001 | Process Mgmt | sys_getpid() |
++-------------------+-----------+-----------------+-------------------------+
+| clone | 1077 | Process Mgmt. | sys_clone() |
++-------------------+-----------+-----------------+-------------------------+
+| prctl | 23 | Process Mgmt. | sys_prctl() |
++-------------------+-----------+-----------------+-------------------------+
+| prlimit64 | 7 | Process Mgmt. | sys_prlimit64() |
++-------------------+-----------+-----------------+-------------------------+
+| getpid | 10 | Process Mgmt. | sys_getpid() |
++-------------------+-----------+-----------------+-------------------------+
+| uname | 3 | Process Mgmt. | sys_uname() |
++-------------------+-----------+-----------------+-------------------------+
+| sysinfo | 1 | Process Mgmt. | sys_sysinfo() |
++-------------------+-----------+-----------------+-------------------------+
+| getuid | 1 | Process Mgmt. | sys_getuid() |
++-------------------+-----------+-----------------+-------------------------+
+| getgid | 1 | Process Mgmt. | sys_getgid() |
++-------------------+-----------+-----------------+-------------------------+
+| geteuid | 1 | Process Mgmt. | sys_geteuid() |
++-------------------+-----------+-----------------+-------------------------+
+| getegid | 1 | Process Mgmt. | sys_getegid |
++-------------------+-----------+-----------------+-------------------------+
+| close | 49951 | Filesystem | sys_close() |
++-------------------+-----------+-----------------+-------------------------+
+| pipe | 604 | Filesystem | sys_pipe() |
++-------------------+-----------+-----------------+-------------------------+
+| openat | 48560 | Filesystem | sys_opennat() |
++-------------------+-----------+-----------------+-------------------------+
+| fstat | 8338 | Filesystem | sys_fstat() |
++-------------------+-----------+-----------------+-------------------------+
+| stat | 1573 | Filesystem | sys_stat() |
++-------------------+-----------+-----------------+-------------------------+
+| pread64 | 9646 | Filesystem | sys_pread64() |
++-------------------+-----------+-----------------+-------------------------+
+| getdents64 | 1873 | Filesystem | sys_getdents64() |
++-------------------+-----------+-----------------+-------------------------+
+| access | 3 | Filesystem | sys_access() |
++-------------------+-----------+-----------------+-------------------------+
+| lstat | 1880 | Filesystem | sys_lstat() |
++-------------------+-----------+-----------------+-------------------------+
+| lseek | 6 | Filesystem | sys_lseek() |
++-------------------+-----------+-----------------+-------------------------+
+| ioctl | 3 | Filesystem | sys_ioctl() |
++-------------------+-----------+-----------------+-------------------------+
+| dup2 | 1 | Filesystem | sys_dup2() |
++-------------------+-----------+-----------------+-------------------------+
+| execve | 2 | Filesystem | sys_execve() |
++-------------------+-----------+-----------------+-------------------------+
+| fcntl | 8779 | Filesystem | sys_fcntl() |
++-------------------+-----------+-----------------+-------------------------+
+| statfs | 1 | Filesystem | sys_statfs() |
++-------------------+-----------+-----------------+-------------------------+
+| epoll_create | 2 | Filesystem | sys_epoll_create() |
++-------------------+-----------+-----------------+-------------------------+
+| epoll_ctl | 64 | Filesystem | sys_epoll_ctl() |
++-------------------+-----------+-----------------+-------------------------+
+| newfstatat | 8318 | Filesystem | sys_newfstatat() |
++-------------------+-----------+-----------------+-------------------------+
+| eventfd2 | 192 | Filesystem | sys_eventfd2() |
++-------------------+-----------+-----------------+-------------------------+
+| mmap | 243 | Memory Mgmt. | sys_mmap() |
++-------------------+-----------+-----------------+-------------------------+
+| mprotect | 32 | Memory Mgmt. | sys_mprotect() |
++-------------------+-----------+-----------------+-------------------------+
+| brk | 21 | Memory Mgmt. | sys_brk() |
++-------------------+-----------+-----------------+-------------------------+
+| munmap | 128 | Memory Mgmt. | sys_munmap() |
++-------------------+-----------+-----------------+-------------------------+
+| set_mempolicy | 156 | Memory Mgmt. | sys_set_mempolicy() |
++-------------------+-----------+-----------------+-------------------------+
+| set_tid_address | 1 | Process Mgmt. | sys_set_tid_address() |
++-------------------+-----------+-----------------+-------------------------+
+| set_robust_list | 1 | Futex | sys_set_robust_list() |
++-------------------+-----------+-----------------+-------------------------+
+| futex | 341 | Futex | sys_futex() |
++-------------------+-----------+-----------------+-------------------------+
+| sched_getaffinity | 79 | Scheduler | sys_sched_getaffinity() |
++-------------------+-----------+-----------------+-------------------------+
+| sched_setaffinity | 223 | Scheduler | sys_sched_setaffinity() |
++-------------------+-----------+-----------------+-------------------------+
+| socketpair | 202 | Network | sys_socketpair() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigprocmask | 21 | Signal | sys_rt_sigprocmask() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigaction | 36 | Signal | sys_rt_sigaction() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigreturn | 2 | Signal | sys_rt_sigreturn() |
++-------------------+-----------+-----------------+-------------------------+
+| wait4 | 889 | Time | sys_wait4() |
++-------------------+-----------+-----------------+-------------------------+
+| clock_nanosleep | 37 | Time | sys_clock_nanosleep() |
++-------------------+-----------+-----------------+-------------------------+
+| capget | 4 | Capability | sys_capget() |
++-------------------+-----------+-----------------+-------------------------+
+
+Tracing stress-ng netdev stressor workload
+------------------------------------------
+
+Run the following command to trace stress-ng netdev stressor workload::
+
+ strace -c stress-ng --netdev 1 -t 60 --metrics
+
+**System Calls made by the workload**
+
+The below table shows the system calls invoked by the workload, number of
+times each system call is invoked, and the corresponding Linux subsystem.
+
++-------------------+-----------+-----------------+-------------------------+
+| System Call | # calls | Linux Subsystem | System Call (API) |
++===================+===========+=================+=========================+
+| openat | 74 | Filesystem | sys_openat() |
++-------------------+-----------+-----------------+-------------------------+
+| close | 75 | Filesystem | sys_close() |
++-------------------+-----------+-----------------+-------------------------+
+| read | 58 | Filesystem | sys_read() |
++-------------------+-----------+-----------------+-------------------------+
+| fstat | 20 | Filesystem | sys_fstat() |
++-------------------+-----------+-----------------+-------------------------+
+| flock | 10 | Filesystem | sys_flock() |
++-------------------+-----------+-----------------+-------------------------+
+| write | 7 | Filesystem | sys_write() |
++-------------------+-----------+-----------------+-------------------------+
+| getdents64 | 8 | Filesystem | sys_getdents64() |
++-------------------+-----------+-----------------+-------------------------+
+| pread64 | 8 | Filesystem | sys_pread64() |
++-------------------+-----------+-----------------+-------------------------+
+| lseek | 1 | Filesystem | sys_lseek() |
++-------------------+-----------+-----------------+-------------------------+
+| access | 2 | Filesystem | sys_access() |
++-------------------+-----------+-----------------+-------------------------+
+| getcwd | 1 | Filesystem | sys_getcwd() |
++-------------------+-----------+-----------------+-------------------------+
+| execve | 1 | Filesystem | sys_execve() |
++-------------------+-----------+-----------------+-------------------------+
+| mmap | 61 | Memory Mgmt. | sys_mmap() |
++-------------------+-----------+-----------------+-------------------------+
+| munmap | 3 | Memory Mgmt. | sys_munmap() |
++-------------------+-----------+-----------------+-------------------------+
+| mprotect | 20 | Memory Mgmt. | sys_mprotect() |
++-------------------+-----------+-----------------+-------------------------+
+| mlock | 2 | Memory Mgmt. | sys_mlock() |
++-------------------+-----------+-----------------+-------------------------+
+| brk | 3 | Memory Mgmt. | sys_brk() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigaction | 21 | Signal | sys_rt_sigaction() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigprocmask | 1 | Signal | sys_rt_sigprocmask() |
++-------------------+-----------+-----------------+-------------------------+
+| sigaltstack | 1 | Signal | sys_sigaltstack() |
++-------------------+-----------+-----------------+-------------------------+
+| rt_sigreturn | 1 | Signal | sys_rt_sigreturn() |
++-------------------+-----------+-----------------+-------------------------+
+| getpid | 8 | Process Mgmt. | sys_getpid() |
++-------------------+-----------+-----------------+-------------------------+
+| prlimit64 | 5 | Process Mgmt. | sys_prlimit64() |
++-------------------+-----------+-----------------+-------------------------+
+| arch_prctl | 2 | Process Mgmt. | sys_arch_prctl() |
++-------------------+-----------+-----------------+-------------------------+
+| sysinfo | 2 | Process Mgmt. | sys_sysinfo() |
++-------------------+-----------+-----------------+-------------------------+
+| getuid | 2 | Process Mgmt. | sys_getuid() |
++-------------------+-----------+-----------------+-------------------------+
+| uname | 1 | Process Mgmt. | sys_uname() |
++-------------------+-----------+-----------------+-------------------------+
+| setpgid | 1 | Process Mgmt. | sys_setpgid() |
++-------------------+-----------+-----------------+-------------------------+
+| getrusage | 1 | Process Mgmt. | sys_getrusage() |
++-------------------+-----------+-----------------+-------------------------+
+| geteuid | 1 | Process Mgmt. | sys_geteuid() |
++-------------------+-----------+-----------------+-------------------------+
+| getppid | 1 | Process Mgmt. | sys_getppid() |
++-------------------+-----------+-----------------+-------------------------+
+| sendto | 3 | Network | sys_sendto() |
++-------------------+-----------+-----------------+-------------------------+
+| connect | 1 | Network | sys_connect() |
++-------------------+-----------+-----------------+-------------------------+
+| socket | 1 | Network | sys_socket() |
++-------------------+-----------+-----------------+-------------------------+
+| clone | 1 | Process Mgmt. | sys_clone() |
++-------------------+-----------+-----------------+-------------------------+
+| set_tid_address | 1 | Process Mgmt. | sys_set_tid_address() |
++-------------------+-----------+-----------------+-------------------------+
+| wait4 | 2 | Time | sys_wait4() |
++-------------------+-----------+-----------------+-------------------------+
+| alarm | 1 | Time | sys_alarm() |
++-------------------+-----------+-----------------+-------------------------+
+| set_robust_list | 1 | Futex | sys_set_robust_list() |
++-------------------+-----------+-----------------+-------------------------+
+
+Tracing paxtest kiddie workload
+-------------------------------
+
+Run the following command to trace paxtest kiddie workload::
+
+ strace -c paxtest kiddie
+
+**System Calls made by the workload**
+
+The below table shows the system calls invoked by the workload, number of
+times each system call is invoked, and the corresponding Linux subsystem.
+
++-------------------+-----------+-----------------+----------------------+
+| System Call | # calls | Linux Subsystem | System Call (API) |
++===================+===========+=================+======================+
+| read | 3 | Filesystem | sys_read() |
++-------------------+-----------+-----------------+----------------------+
+| write | 11 | Filesystem | sys_write() |
++-------------------+-----------+-----------------+----------------------+
+| close | 41 | Filesystem | sys_close() |
++-------------------+-----------+-----------------+----------------------+
+| stat | 24 | Filesystem | sys_stat() |
++-------------------+-----------+-----------------+----------------------+
+| fstat | 2 | Filesystem | sys_fstat() |
++-------------------+-----------+-----------------+----------------------+
+| pread64 | 6 | Filesystem | sys_pread64() |
++-------------------+-----------+-----------------+----------------------+
+| access | 1 | Filesystem | sys_access() |
++-------------------+-----------+-----------------+----------------------+
+| pipe | 1 | Filesystem | sys_pipe() |
++-------------------+-----------+-----------------+----------------------+
+| dup2 | 24 | Filesystem | sys_dup2() |
++-------------------+-----------+-----------------+----------------------+
+| execve | 1 | Filesystem | sys_execve() |
++-------------------+-----------+-----------------+----------------------+
+| fcntl | 26 | Filesystem | sys_fcntl() |
++-------------------+-----------+-----------------+----------------------+
+| openat | 14 | Filesystem | sys_openat() |
++-------------------+-----------+-----------------+----------------------+
+| rt_sigaction | 7 | Signal | sys_rt_sigaction() |
++-------------------+-----------+-----------------+----------------------+
+| rt_sigreturn | 38 | Signal | sys_rt_sigreturn() |
++-------------------+-----------+-----------------+----------------------+
+| clone | 38 | Process Mgmt. | sys_clone() |
++-------------------+-----------+-----------------+----------------------+
+| wait4 | 44 | Time | sys_wait4() |
++-------------------+-----------+-----------------+----------------------+
+| mmap | 7 | Memory Mgmt. | sys_mmap() |
++-------------------+-----------+-----------------+----------------------+
+| mprotect | 3 | Memory Mgmt. | sys_mprotect() |
++-------------------+-----------+-----------------+----------------------+
+| munmap | 1 | Memory Mgmt. | sys_munmap() |
++-------------------+-----------+-----------------+----------------------+
+| brk | 3 | Memory Mgmt. | sys_brk() |
++-------------------+-----------+-----------------+----------------------+
+| getpid | 1 | Process Mgmt. | sys_getpid() |
++-------------------+-----------+-----------------+----------------------+
+| getuid | 1 | Process Mgmt. | sys_getuid() |
++-------------------+-----------+-----------------+----------------------+
+| getgid | 1 | Process Mgmt. | sys_getgid() |
++-------------------+-----------+-----------------+----------------------+
+| geteuid | 2 | Process Mgmt. | sys_geteuid() |
++-------------------+-----------+-----------------+----------------------+
+| getegid | 1 | Process Mgmt. | sys_getegid() |
++-------------------+-----------+-----------------+----------------------+
+| getppid | 1 | Process Mgmt. | sys_getppid() |
++-------------------+-----------+-----------------+----------------------+
+| arch_prctl | 2 | Process Mgmt. | sys_arch_prctl() |
++-------------------+-----------+-----------------+----------------------+
+
+Conclusion
+==========
+
+This document is intended to be used as a guide on how to gather fine-grained
+information on the resources in use by workloads using strace.
+
+References
+==========
+
+ * `Discovery Linux Kernel Subsystems used by OpenAPS <https://elisa.tech/blog/2022/02/02/discovery-linux-kernel-subsystems-used-by-openaps>`_
+ * `ELISA-White-Papers-Discovering Linux kernel subsystems used by a workload <https://github.com/elisa-tech/ELISA-White-Papers/blob/master/Processes/Discovering_Linux_kernel_subsystems_used_by_a_workload.md>`_
+ * `strace <https://man7.org/linux/man-pages/man1/strace.1.html>`_
+ * `perf <https://man7.org/linux/man-pages/man1/perf.1.html>`_
+ * `paxtest README <https://github.com/opntr/paxtest-freebsd/blob/hardenedbsd/0.9.14-hbsd/README>`_
+ * `stress-ng <https://www.mankier.com/1/stress-ng>`_
+ * `Monitoring and managing system status and performance <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/index>`_
diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst
index 8de008c0c5ad..c85cd327af28 100644
--- a/Documentation/admin-guide/xfs.rst
+++ b/Documentation/admin-guide/xfs.rst
@@ -34,22 +34,6 @@ When mounting an XFS filesystem, the following options are accepted.
to the file. Specifying a fixed ``allocsize`` value turns off
the dynamic behaviour.
- attr2 or noattr2
- The options enable/disable an "opportunistic" improvement to
- be made in the way inline extended attributes are stored
- on-disk. When the new form is used for the first time when
- ``attr2`` is selected (either when setting or removing extended
- attributes) the on-disk superblock feature bit field will be
- updated to reflect this format being in use.
-
- The default behaviour is determined by the on-disk feature
- bit indicating that ``attr2`` behaviour is active. If either
- mount option is set, then that becomes the new default used
- by the filesystem.
-
- CRC enabled filesystems always use the ``attr2`` format, and so
- will reject the ``noattr2`` mount option if it is set.
-
discard or nodiscard (default)
Enable/disable the issuing of commands to let the block
device reclaim space freed by the filesystem. This is
@@ -75,12 +59,6 @@ When mounting an XFS filesystem, the following options are accepted.
across the entire filesystem rather than just on directories
configured to use it.
- ikeep or noikeep (default)
- When ``ikeep`` is specified, XFS does not delete empty inode
- clusters and keeps them around on disk. When ``noikeep`` is
- specified, empty inode clusters are returned to the free
- space pool.
-
inode32 or inode64 (default)
When ``inode32`` is specified, it indicates that XFS limits
inode creation to locations which will not result in inode
@@ -124,6 +102,14 @@ When mounting an XFS filesystem, the following options are accepted.
controls the size of each buffer and so is also relevant to
this case.
+ lifetime (default) or nolifetime
+ Enable data placement based on write life time hints provided
+ by the user. This turns on co-allocation of data of similar
+ life times when statistically favorable to reduce garbage
+ collection cost.
+
+ These options are only available for zoned rt file systems.
+
logbsize=value
Set the size of each in-memory log buffer. The size may be
specified in bytes, or in kilobytes with a "k" suffix.
@@ -143,6 +129,25 @@ When mounting an XFS filesystem, the following options are accepted.
optional, and the log section can be separate from the data
section or contained within it.
+ max_atomic_write=value
+ Set the maximum size of an atomic write. The size may be
+ specified in bytes, in kilobytes with a "k" suffix, in megabytes
+ with a "m" suffix, or in gigabytes with a "g" suffix. The size
+ cannot be larger than the maximum write size, larger than the
+ size of any allocation group, or larger than the size of a
+ remapping operation that the log can complete atomically.
+
+ The default value is to set the maximum I/O completion size
+ to allow each CPU to handle one at a time.
+
+ max_open_zones=value
+ Specify the max number of zones to keep open for writing on a
+ zoned rt device. Many open zones aids file data separation
+ but may impact performance on HDDs.
+
+ If ``max_open_zones`` is not specified, the value is determined
+ by the capabilities and the size of the zoned rt device.
+
noalign
Data allocations will not be aligned at stripe unit
boundaries. This is only relevant to filesystems created
@@ -192,7 +197,7 @@ When mounting an XFS filesystem, the following options are accepted.
are any integer multiple of a valid ``sunit`` value.
Typically the only time these mount options are necessary if
- after an underlying RAID device has had it's geometry
+ after an underlying RAID device has had its geometry
modified, such as adding a new disk to a RAID5 lun and
reshaping it.
@@ -226,9 +231,8 @@ latest version and try again.
The deprecation will take place in two parts. Support for mounting V4
filesystems can now be disabled at kernel build time via Kconfig option.
-The option will default to yes until September 2025, at which time it
-will be changed to default to no. In September 2030, support will be
-removed from the codebase entirely.
+These options were changed to default to no in September 2025. In
+September 2030, support will be removed from the codebase entirely.
Note: Distributors may choose to withdraw V4 format support earlier than
the dates listed above.
@@ -236,13 +240,12 @@ the dates listed above.
Deprecated Mount Options
========================
-=========================== ================
+============================ ================
Name Removal Schedule
-=========================== ================
+============================ ================
Mounting with V4 filesystem September 2030
-ikeep/noikeep September 2025
-attr2/noattr2 September 2025
-=========================== ================
+Mounting ascii-ci filesystem September 2030
+============================ ================
Removed Mount Options
@@ -257,6 +260,8 @@ Removed Mount Options
osyncisdsync/osyncisosync v4.0
barrier v4.19
nobarrier v4.19
+ ikeep/noikeep v6.18
+ attr2/noattr2 v6.18
=========================== =======
sysctls
@@ -284,9 +289,6 @@ The following sysctls are available for the XFS filesystem:
removes unused preallocation from clean inodes and releases
the unused space back to the free pool.
- fs.xfs.speculative_cow_prealloc_lifetime
- This is an alias for speculative_prealloc_lifetime.
-
fs.xfs.error_level (Min: 0 Default: 3 Max: 11)
A volume knob for error reporting when internal errors occur.
This will generate detailed messages & backtraces for filesystem
@@ -296,7 +298,7 @@ The following sysctls are available for the XFS filesystem:
XFS_ERRLEVEL_LOW: 1
XFS_ERRLEVEL_HIGH: 5
- fs.xfs.panic_mask (Min: 0 Default: 0 Max: 256)
+ fs.xfs.panic_mask (Min: 0 Default: 0 Max: 511)
Causes certain error conditions to call BUG(). Value is a bitmask;
OR together the tags which represent errors which should cause panics:
@@ -313,17 +315,6 @@ The following sysctls are available for the XFS filesystem:
This option is intended for debugging only.
- fs.xfs.irix_symlink_mode (Min: 0 Default: 0 Max: 1)
- Controls whether symlinks are created with mode 0777 (default)
- or whether their mode is affected by the umask (irix mode).
-
- fs.xfs.irix_sgid_inherit (Min: 0 Default: 0 Max: 1)
- Controls files created in SGID directories.
- If the group ID of the new file does not match the effective group
- ID or one of the supplementary group IDs of the parent dir, the
- ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl
- is set.
-
fs.xfs.inherit_sync (Min: 0 Default: 1 Max: 1)
Setting this to "1" will cause the "sync" flag set
by the **xfs_io(8)** chattr command on a directory to be
@@ -359,24 +350,20 @@ The following sysctls are available for the XFS filesystem:
Deprecated Sysctls
==================
-=========================================== ================
- Name Removal Schedule
-=========================================== ================
-fs.xfs.irix_sgid_inherit September 2025
-fs.xfs.irix_symlink_mode September 2025
-fs.xfs.speculative_cow_prealloc_lifetime September 2025
-=========================================== ================
-
+None currently.
Removed Sysctls
===============
-============================= =======
- Name Removed
-============================= =======
- fs.xfs.xfsbufd_centisec v4.0
- fs.xfs.age_buffer_centisecs v4.0
-============================= =======
+========================================== =======
+ Name Removed
+========================================== =======
+ fs.xfs.xfsbufd_centisec v4.0
+ fs.xfs.age_buffer_centisecs v4.0
+ fs.xfs.irix_symlink_mode v6.18
+ fs.xfs.irix_sgid_inherit v6.18
+ fs.xfs.speculative_cow_prealloc_lifetime v6.18
+========================================== =======
Error handling
==============
@@ -541,3 +528,24 @@ The interesting knobs for XFS workqueues are as follows:
nice Relative priority of scheduling the threads. These are the
same nice levels that can be applied to userspace processes.
============ ===========
+
+Zoned Filesystems
+=================
+
+For zoned file systems, the following attributes are exposed in:
+
+ /sys/fs/xfs/<dev>/zoned/
+
+ max_open_zones (Min: 1 Default: Varies Max: UINTMAX)
+ This read-only attribute exposes the maximum number of open zones
+ available for data placement. The value is determined at mount time and
+ is limited by the capabilities of the backing zoned device, file system
+ size and the max_open_zones mount option.
+
+ zonegc_low_space (Min: 0 Default: 0 Max: 100)
+ Define a percentage for how much of the unused space that GC should keep
+ available for writing. A high value will reclaim more of the space
+ occupied by unused blocks, creating a larger buffer against write
+ bursts at the cost of increased write amplification. Regardless
+ of this value, garbage collection will always aim to free a minimum
+ amount of blocks to keep max_open_zones open for data placement purposes.
diff --git a/Documentation/arc/features.rst b/Documentation/arc/features.rst
deleted file mode 100644
index b793583d688a..000000000000
--- a/Documentation/arc/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features arc
diff --git a/Documentation/arch.rst b/Documentation/arch.rst
deleted file mode 100644
index 41a66a8b38e4..000000000000
--- a/Documentation/arch.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-CPU Architectures
-=================
-
-These books provide programming details about architecture-specific
-implementation.
-
-.. toctree::
- :maxdepth: 2
-
- arc/index
- arm/index
- arm64/index
- ia64/index
- loongarch/index
- m68k/index
- mips/index
- nios2/index
- openrisc/index
- parisc/index
- powerpc/index
- riscv/index
- s390/index
- sh/index
- sparc/index
- x86/index
- xtensa/index
diff --git a/Documentation/arc/arc.rst b/Documentation/arch/arc/arc.rst
index 6c4d978f3f4e..6c4d978f3f4e 100644
--- a/Documentation/arc/arc.rst
+++ b/Documentation/arch/arc/arc.rst
diff --git a/Documentation/arch/arc/features.rst b/Documentation/arch/arc/features.rst
new file mode 100644
index 000000000000..49ff446ff744
--- /dev/null
+++ b/Documentation/arch/arc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features arc
diff --git a/Documentation/arc/index.rst b/Documentation/arch/arc/index.rst
index 7b098d4a5e3e..7b098d4a5e3e 100644
--- a/Documentation/arc/index.rst
+++ b/Documentation/arch/arc/index.rst
diff --git a/Documentation/arm/arm.rst b/Documentation/arch/arm/arm.rst
index 99d660fdf73f..7b41b89dd9bd 100644
--- a/Documentation/arm/arm.rst
+++ b/Documentation/arch/arm/arm.rst
@@ -141,7 +141,7 @@ ST506 hard drives
`*configure` harddrive set to 2). I've got an internal 20MB and a great
big external 5.25" FH 64MB drive (who could ever want more :-) ).
- I've just got 240K/s off it (a dd with bs=128k); thats about half of what
+ I've just got 240K/s off it (a dd with bs=128k); that's about half of what
RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
last week :-)
diff --git a/Documentation/arm/booting.rst b/Documentation/arch/arm/booting.rst
index 5974e37b3d20..5974e37b3d20 100644
--- a/Documentation/arm/booting.rst
+++ b/Documentation/arch/arm/booting.rst
diff --git a/Documentation/arm/cluster-pm-race-avoidance.rst b/Documentation/arch/arm/cluster-pm-race-avoidance.rst
index aa58603d3f28..aa58603d3f28 100644
--- a/Documentation/arm/cluster-pm-race-avoidance.rst
+++ b/Documentation/arch/arm/cluster-pm-race-avoidance.rst
diff --git a/Documentation/arch/arm/features.rst b/Documentation/arch/arm/features.rst
new file mode 100644
index 000000000000..0e76aaf68eca
--- /dev/null
+++ b/Documentation/arch/arm/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features arm
diff --git a/Documentation/arm/firmware.rst b/Documentation/arch/arm/firmware.rst
index efd844baec1d..efd844baec1d 100644
--- a/Documentation/arm/firmware.rst
+++ b/Documentation/arch/arm/firmware.rst
diff --git a/Documentation/arm/google/chromebook-boot-flow.rst b/Documentation/arch/arm/google/chromebook-boot-flow.rst
index 36da77684bba..36da77684bba 100644
--- a/Documentation/arm/google/chromebook-boot-flow.rst
+++ b/Documentation/arch/arm/google/chromebook-boot-flow.rst
diff --git a/Documentation/arch/arm/index.rst b/Documentation/arch/arm/index.rst
new file mode 100644
index 000000000000..fd43502ae924
--- /dev/null
+++ b/Documentation/arch/arm/index.rst
@@ -0,0 +1,85 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================
+ARM Architecture
+================
+
+.. toctree::
+ :maxdepth: 1
+
+ arm
+ booting
+ cluster-pm-race-avoidance
+ firmware
+ interrupts
+ kernel_mode_neon
+ kernel_user_helpers
+ memory
+ mem_alignment
+ tcm
+ setup
+ swp_emulation
+ uefi
+ vlocks
+ porting
+
+ features
+
+SoC-specific documents
+======================
+
+.. toctree::
+ :maxdepth: 1
+
+ google/chromebook-boot-flow
+
+ ixp4xx
+
+ marvell
+ microchip
+
+ netwinder
+ nwfpe/index
+
+ keystone/overview
+ keystone/knav-qmss
+
+ omap/index
+
+ pxa/mfp
+
+
+ sa1100/index
+
+ stm32/stm32f746-overview
+ stm32/overview
+ stm32/stm32h743-overview
+ stm32/stm32h750-overview
+ stm32/stm32f769-overview
+ stm32/stm32f429-overview
+ stm32/stm32mp13-overview
+ stm32/stm32mp151-overview
+ stm32/stm32mp157-overview
+ stm32/stm32-dma-mdma-chaining
+
+ sunxi
+
+ samsung/index
+
+ sunxi/clocks
+
+ spear/overview
+
+ sti/stih407-overview
+ sti/stih418-overview
+ sti/overview
+
+ vfp/release-notes
+
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arm/interrupts.rst b/Documentation/arch/arm/interrupts.rst
index 2ae70e0e9732..2ae70e0e9732 100644
--- a/Documentation/arm/interrupts.rst
+++ b/Documentation/arch/arm/interrupts.rst
diff --git a/Documentation/arm/ixp4xx.rst b/Documentation/arch/arm/ixp4xx.rst
index a57235616294..17aafc610908 100644
--- a/Documentation/arm/ixp4xx.rst
+++ b/Documentation/arch/arm/ixp4xx.rst
@@ -78,9 +78,9 @@ IXP4xx provides two methods of accessing PCI memory space:
1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
To access PCI via this space, we simply ioremap() the BAR
into the kernel and we can use the standard read[bwl]/write[bwl]
- macros. This is the preffered method due to speed but it
+ macros. This is the preferred method due to speed but it
limits the system to just 64MB of PCI memory. This can be
- problamatic if using video cards and other memory-heavy devices.
+ problematic if using video cards and other memory-heavy devices.
2) If > 64MB of memory space is required, the IXP4xx can be
configured to use indirect registers to access PCI This allows
diff --git a/Documentation/arm/kernel_mode_neon.rst b/Documentation/arch/arm/kernel_mode_neon.rst
index 9bfb71a2a9b9..9bfb71a2a9b9 100644
--- a/Documentation/arm/kernel_mode_neon.rst
+++ b/Documentation/arch/arm/kernel_mode_neon.rst
diff --git a/Documentation/arm/kernel_user_helpers.rst b/Documentation/arch/arm/kernel_user_helpers.rst
index eb6f3d916622..eb6f3d916622 100644
--- a/Documentation/arm/kernel_user_helpers.rst
+++ b/Documentation/arch/arm/kernel_user_helpers.rst
diff --git a/Documentation/arm/keystone/knav-qmss.rst b/Documentation/arch/arm/keystone/knav-qmss.rst
index 7f7638d80b42..7f7638d80b42 100644
--- a/Documentation/arm/keystone/knav-qmss.rst
+++ b/Documentation/arch/arm/keystone/knav-qmss.rst
diff --git a/Documentation/arm/keystone/overview.rst b/Documentation/arch/arm/keystone/overview.rst
index cd90298c493c..cd90298c493c 100644
--- a/Documentation/arm/keystone/overview.rst
+++ b/Documentation/arch/arm/keystone/overview.rst
diff --git a/Documentation/arm/marvell.rst b/Documentation/arch/arm/marvell.rst
index 370721518987..3d369a566038 100644
--- a/Documentation/arm/marvell.rst
+++ b/Documentation/arch/arm/marvell.rst
@@ -14,18 +14,20 @@ Orion family
Flavors:
- 88F5082
- - 88F5181
- - 88F5181L
- - 88F5182
+ - 88F5181 a.k.a Orion-1
+ - 88F5181L a.k.a Orion-VoIP
+ - 88F5182 a.k.a Orion-NAS
- Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf
- Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf
- User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf
- Functional Errata: https://web.archive.org/web/20210704165540/https://www.digriz.org.uk/ts78xx/88F5182_Functional_Errata.pdf
- - 88F5281
+ - 88F5281 a.k.a Orion-2
- Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
- - 88F6183
+ - 88F6183 a.k.a Orion-1-90
+ Homepage:
+ https://web.archive.org/web/20080607215437/http://www.marvell.com/products/media/index.jsp
Core:
Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
Linux kernel mach directory:
diff --git a/Documentation/arm/mem_alignment.rst b/Documentation/arch/arm/mem_alignment.rst
index aa22893b62bc..64bd77959300 100644
--- a/Documentation/arm/mem_alignment.rst
+++ b/Documentation/arch/arm/mem_alignment.rst
@@ -12,7 +12,7 @@ ones.
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
-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
a high performance cost. It better be rare.
diff --git a/Documentation/arm/memory.rst b/Documentation/arch/arm/memory.rst
index 0cb1e2938823..0cb1e2938823 100644
--- a/Documentation/arm/memory.rst
+++ b/Documentation/arch/arm/memory.rst
diff --git a/Documentation/arm/microchip.rst b/Documentation/arch/arm/microchip.rst
index e721d855f2c9..e721d855f2c9 100644
--- a/Documentation/arm/microchip.rst
+++ b/Documentation/arch/arm/microchip.rst
diff --git a/Documentation/arm/netwinder.rst b/Documentation/arch/arm/netwinder.rst
index 8eab66caa2ac..8eab66caa2ac 100644
--- a/Documentation/arm/netwinder.rst
+++ b/Documentation/arch/arm/netwinder.rst
diff --git a/Documentation/arm/nwfpe/index.rst b/Documentation/arch/arm/nwfpe/index.rst
index 3c4d2f9aa10e..3c4d2f9aa10e 100644
--- a/Documentation/arm/nwfpe/index.rst
+++ b/Documentation/arch/arm/nwfpe/index.rst
diff --git a/Documentation/arm/nwfpe/netwinder-fpe.rst b/Documentation/arch/arm/nwfpe/netwinder-fpe.rst
index cbb320960fc4..cbb320960fc4 100644
--- a/Documentation/arm/nwfpe/netwinder-fpe.rst
+++ b/Documentation/arch/arm/nwfpe/netwinder-fpe.rst
diff --git a/Documentation/arm/nwfpe/notes.rst b/Documentation/arch/arm/nwfpe/notes.rst
index 102e55af8439..102e55af8439 100644
--- a/Documentation/arm/nwfpe/notes.rst
+++ b/Documentation/arch/arm/nwfpe/notes.rst
diff --git a/Documentation/arm/nwfpe/nwfpe.rst b/Documentation/arch/arm/nwfpe/nwfpe.rst
index 35cd90dacbff..35cd90dacbff 100644
--- a/Documentation/arm/nwfpe/nwfpe.rst
+++ b/Documentation/arch/arm/nwfpe/nwfpe.rst
diff --git a/Documentation/arm/nwfpe/todo.rst b/Documentation/arch/arm/nwfpe/todo.rst
index 393f11b14540..393f11b14540 100644
--- a/Documentation/arm/nwfpe/todo.rst
+++ b/Documentation/arch/arm/nwfpe/todo.rst
diff --git a/Documentation/arm/omap/dss.rst b/Documentation/arch/arm/omap/dss.rst
index a40c4d9c717a..a40c4d9c717a 100644
--- a/Documentation/arm/omap/dss.rst
+++ b/Documentation/arch/arm/omap/dss.rst
diff --git a/Documentation/arm/omap/index.rst b/Documentation/arch/arm/omap/index.rst
index 8b365b212e49..8b365b212e49 100644
--- a/Documentation/arm/omap/index.rst
+++ b/Documentation/arch/arm/omap/index.rst
diff --git a/Documentation/arm/omap/omap.rst b/Documentation/arch/arm/omap/omap.rst
index f440c0f4613f..f440c0f4613f 100644
--- a/Documentation/arm/omap/omap.rst
+++ b/Documentation/arch/arm/omap/omap.rst
diff --git a/Documentation/arm/omap/omap_pm.rst b/Documentation/arch/arm/omap/omap_pm.rst
index a335e4c8ce2c..a335e4c8ce2c 100644
--- a/Documentation/arm/omap/omap_pm.rst
+++ b/Documentation/arch/arm/omap/omap_pm.rst
diff --git a/Documentation/arm/porting.rst b/Documentation/arch/arm/porting.rst
index bd21958bdb2d..bd21958bdb2d 100644
--- a/Documentation/arm/porting.rst
+++ b/Documentation/arch/arm/porting.rst
diff --git a/Documentation/arm/pxa/mfp.rst b/Documentation/arch/arm/pxa/mfp.rst
index ac34e5d7ee44..ac34e5d7ee44 100644
--- a/Documentation/arm/pxa/mfp.rst
+++ b/Documentation/arch/arm/pxa/mfp.rst
diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arch/arm/sa1100/assabet.rst
index a761e128fb08..a761e128fb08 100644
--- a/Documentation/arm/sa1100/assabet.rst
+++ b/Documentation/arch/arm/sa1100/assabet.rst
diff --git a/Documentation/arm/sa1100/cerf.rst b/Documentation/arch/arm/sa1100/cerf.rst
index 7fa71b609bf9..7fa71b609bf9 100644
--- a/Documentation/arm/sa1100/cerf.rst
+++ b/Documentation/arch/arm/sa1100/cerf.rst
diff --git a/Documentation/arm/sa1100/index.rst b/Documentation/arch/arm/sa1100/index.rst
index c9aed43280ff..c9aed43280ff 100644
--- a/Documentation/arm/sa1100/index.rst
+++ b/Documentation/arch/arm/sa1100/index.rst
diff --git a/Documentation/arm/sa1100/lart.rst b/Documentation/arch/arm/sa1100/lart.rst
index 94c0568d1095..94c0568d1095 100644
--- a/Documentation/arm/sa1100/lart.rst
+++ b/Documentation/arch/arm/sa1100/lart.rst
diff --git a/Documentation/arm/sa1100/serial_uart.rst b/Documentation/arch/arm/sa1100/serial_uart.rst
index ea983642b9be..ea983642b9be 100644
--- a/Documentation/arm/sa1100/serial_uart.rst
+++ b/Documentation/arch/arm/sa1100/serial_uart.rst
diff --git a/Documentation/arm/samsung/bootloader-interface.rst b/Documentation/arch/arm/samsung/bootloader-interface.rst
index a56f325dae78..a56f325dae78 100644
--- a/Documentation/arm/samsung/bootloader-interface.rst
+++ b/Documentation/arch/arm/samsung/bootloader-interface.rst
diff --git a/Documentation/arm/samsung/clksrc-change-registers.awk b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..7be1b8aa7cd9 100755
--- a/Documentation/arm/samsung/clksrc-change-registers.awk
+++ b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
diff --git a/Documentation/arch/arm/samsung/gpio.rst b/Documentation/arch/arm/samsung/gpio.rst
new file mode 100644
index 000000000000..27fae0d50361
--- /dev/null
+++ b/Documentation/arch/arm/samsung/gpio.rst
@@ -0,0 +1,32 @@
+===========================
+Samsung GPIO implementation
+===========================
+
+Introduction
+------------
+
+This outlines the Samsung GPIO implementation and the architecture
+specific calls provided alongside the drivers/gpio core.
+
+
+GPIOLIB integration
+-------------------
+
+The gpio implementation uses gpiolib as much as possible, only providing
+specific calls for the items that require Samsung specific handling, such
+as pin special-function or pull resistor control.
+
+GPIO numbering is synchronised between the Samsung and gpiolib system.
+
+
+PIN configuration
+-----------------
+
+Pin configuration is specific to the Samsung architecture, with each SoC
+registering the necessary information for the core gpio configuration
+implementation to configure pins as necessary.
+
+The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
+driver or machine to change gpio configuration.
+
+See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions.
diff --git a/Documentation/arm/samsung/index.rst b/Documentation/arch/arm/samsung/index.rst
index 8142cce3d23e..8142cce3d23e 100644
--- a/Documentation/arm/samsung/index.rst
+++ b/Documentation/arch/arm/samsung/index.rst
diff --git a/Documentation/arch/arm/samsung/overview.rst b/Documentation/arch/arm/samsung/overview.rst
new file mode 100644
index 000000000000..8b15a190169b
--- /dev/null
+++ b/Documentation/arch/arm/samsung/overview.rst
@@ -0,0 +1,76 @@
+==========================
+Samsung ARM Linux Overview
+==========================
+
+Introduction
+------------
+
+ The Samsung range of ARM SoCs spans many similar devices, from the initial
+ ARM9 through to the newest ARM cores. This document shows an overview of
+ the current kernel support, how to use it and where to find the code
+ that supports this.
+
+ The currently supported SoCs are:
+
+ - S3C64XX: S3C6400 and S3C6410
+ - S5PC110 / S5PV210
+
+
+Configuration
+-------------
+
+ A number of configurations are supplied, as there is no current way of
+ unifying all the SoCs into one kernel.
+
+ s5pc110_defconfig
+ - S5PC110 specific default configuration
+ s5pv210_defconfig
+ - S5PV210 specific default configuration
+
+
+Layout
+------
+
+ The directory layout is currently being restructured, and consists of
+ several platform directories and then the machine specific directories
+ of the CPUs being built for.
+
+ plat-samsung provides the base for all the implementations, and is the
+ last in the line of include directories that are processed for the build
+ specific information. It contains the base clock, GPIO and device definitions
+ to get the system running.
+
+ plat-s5p is for s5p specific builds, and contains common support for the
+ S5P specific systems. Not all S5Ps use all the features in this directory
+ due to differences in the hardware.
+
+
+Layout changes
+--------------
+
+ The old plat-s3c and plat-s5pc1xx directories have been removed, with
+ support moved to either plat-samsung or plat-s5p as necessary. These moves
+ where to simplify the include and dependency issues involved with having
+ so many different platform directories.
+
+
+Port Contributors
+-----------------
+
+ Ben Dooks (BJD)
+ Vincent Sanders
+ Herbert Potzl
+ Arnaud Patard (RTP)
+ Roc Wu
+ Klaus Fetscher
+ Dimitry Andric
+ Shannon Holland
+ Guillaume Gourat (NexVision)
+ Christer Weinigel (wingel) (Acer N30)
+ Lucas Correia Villa Real (S3C2400 port)
+
+
+Document Author
+---------------
+
+Copyright 2009-2010 Ben Dooks <ben-linux@fluff.org>
diff --git a/Documentation/arm/setup.rst b/Documentation/arch/arm/setup.rst
index 8e12ef3fb9a7..8e12ef3fb9a7 100644
--- a/Documentation/arm/setup.rst
+++ b/Documentation/arch/arm/setup.rst
diff --git a/Documentation/arm/spear/overview.rst b/Documentation/arch/arm/spear/overview.rst
index 1a77f6b213b6..1a77f6b213b6 100644
--- a/Documentation/arm/spear/overview.rst
+++ b/Documentation/arch/arm/spear/overview.rst
diff --git a/Documentation/arch/arm/sti/overview.rst b/Documentation/arch/arm/sti/overview.rst
new file mode 100644
index 000000000000..ae16aced800f
--- /dev/null
+++ b/Documentation/arch/arm/sti/overview.rst
@@ -0,0 +1,32 @@
+======================
+STi ARM Linux Overview
+======================
+
+Introduction
+------------
+
+ The ST Microelectronics Multimedia and Application Processors range of
+ CortexA9 System-on-Chip are supported by the 'STi' platform of
+ ARM Linux. Currently STiH407, STiH410 and STiH418 are supported.
+
+
+configuration
+-------------
+
+ The configuration for the STi platform is supported via the multi_v7_defconfig.
+
+Layout
+------
+
+ All the files for multiple machine families (STiH407, STiH410, and STiH418)
+ are located in the platform code contained in arch/arm/mach-sti
+
+ There is a generic board board-dt.c in the mach folder which support
+ Flattened Device Tree, which means, It works with any compatible board with
+ Device Trees.
+
+
+Document Author
+---------------
+
+ Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics
diff --git a/Documentation/arm/sti/stih407-overview.rst b/Documentation/arch/arm/sti/stih407-overview.rst
index 027e75bc7b7c..027e75bc7b7c 100644
--- a/Documentation/arm/sti/stih407-overview.rst
+++ b/Documentation/arch/arm/sti/stih407-overview.rst
diff --git a/Documentation/arm/sti/stih418-overview.rst b/Documentation/arch/arm/sti/stih418-overview.rst
index b563c1f4fe5a..b563c1f4fe5a 100644
--- a/Documentation/arm/sti/stih418-overview.rst
+++ b/Documentation/arch/arm/sti/stih418-overview.rst
diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arch/arm/stm32/overview.rst
index 85cfc8410798..85cfc8410798 100644
--- a/Documentation/arm/stm32/overview.rst
+++ b/Documentation/arch/arm/stm32/overview.rst
diff --git a/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst b/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
new file mode 100644
index 000000000000..301aa30890ae
--- /dev/null
+++ b/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
@@ -0,0 +1,415 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+STM32 DMA-MDMA chaining
+=======================
+
+
+Introduction
+------------
+
+ This document describes the STM32 DMA-MDMA chaining feature. But before going
+ further, let's introduce the peripherals involved.
+
+ To offload data transfers from the CPU, STM32 microprocessors (MPUs) embed
+ direct memory access controllers (DMA).
+
+ STM32MP1 SoCs embed both STM32 DMA and STM32 MDMA controllers. STM32 DMA
+ request routing capabilities are enhanced by a DMA request multiplexer
+ (STM32 DMAMUX).
+
+ **STM32 DMAMUX**
+
+ STM32 DMAMUX routes any DMA request from a given peripheral to any STM32 DMA
+ controller (STM32MP1 counts two STM32 DMA controllers) channels.
+
+ **STM32 DMA**
+
+ STM32 DMA is mainly used to implement central data buffer storage (usually in
+ the system SRAM) for different peripheral. It can access external RAMs but
+ without the ability to generate convenient burst transfer ensuring the best
+ load of the AXI.
+
+ **STM32 MDMA**
+
+ STM32 MDMA (Master DMA) is mainly used to manage direct data transfers between
+ RAM data buffers without CPU intervention. It can also be used in a
+ hierarchical structure that uses STM32 DMA as first level data buffer
+ interfaces for AHB peripherals, while the STM32 MDMA acts as a second level
+ DMA with better performance. As a AXI/AHB master, STM32 MDMA can take control
+ of the AXI/AHB bus.
+
+
+Principles
+----------
+
+ STM32 DMA-MDMA chaining feature relies on the strengths of STM32 DMA and
+ STM32 MDMA controllers.
+
+ STM32 DMA has a circular Double Buffer Mode (DBM). At each end of transaction
+ (when DMA data counter - DMA_SxNDTR - reaches 0), the memory pointers
+ (configured with DMA_SxSM0AR and DMA_SxM1AR) are swapped and the DMA data
+ counter is automatically reloaded. This allows the SW or the STM32 MDMA to
+ process one memory area while the second memory area is being filled/used by
+ the STM32 DMA transfer.
+
+ With STM32 MDMA linked-list mode, a single request initiates the data array
+ (collection of nodes) to be transferred until the linked-list pointer for the
+ channel is null. The channel transfer complete of the last node is the end of
+ transfer, unless first and last nodes are linked to each other, in such a
+ case, the linked-list loops on to create a circular MDMA transfer.
+
+ STM32 MDMA has direct connections with STM32 DMA. This enables autonomous
+ communication and synchronization between peripherals, thus saving CPU
+ resources and bus congestion. Transfer Complete signal of STM32 DMA channel
+ can triggers STM32 MDMA transfer. STM32 MDMA can clear the request generated
+ by the STM32 DMA by writing to its Interrupt Clear register (whose address is
+ stored in MDMA_CxMAR, and bit mask in MDMA_CxMDR).
+
+ .. table:: STM32 MDMA interconnect table with STM32 DMA
+
+ +--------------+----------------+-----------+------------+
+ | STM32 DMAMUX | STM32 DMA | STM32 DMA | STM32 MDMA |
+ | channels | channels | Transfer | request |
+ | | | complete | |
+ | | | signal | |
+ +==============+================+===========+============+
+ | Channel *0* | DMA1 channel 0 | dma1_tcf0 | *0x00* |
+ +--------------+----------------+-----------+------------+
+ | Channel *1* | DMA1 channel 1 | dma1_tcf1 | *0x01* |
+ +--------------+----------------+-----------+------------+
+ | Channel *2* | DMA1 channel 2 | dma1_tcf2 | *0x02* |
+ +--------------+----------------+-----------+------------+
+ | Channel *3* | DMA1 channel 3 | dma1_tcf3 | *0x03* |
+ +--------------+----------------+-----------+------------+
+ | Channel *4* | DMA1 channel 4 | dma1_tcf4 | *0x04* |
+ +--------------+----------------+-----------+------------+
+ | Channel *5* | DMA1 channel 5 | dma1_tcf5 | *0x05* |
+ +--------------+----------------+-----------+------------+
+ | Channel *6* | DMA1 channel 6 | dma1_tcf6 | *0x06* |
+ +--------------+----------------+-----------+------------+
+ | Channel *7* | DMA1 channel 7 | dma1_tcf7 | *0x07* |
+ +--------------+----------------+-----------+------------+
+ | Channel *8* | DMA2 channel 0 | dma2_tcf0 | *0x08* |
+ +--------------+----------------+-----------+------------+
+ | Channel *9* | DMA2 channel 1 | dma2_tcf1 | *0x09* |
+ +--------------+----------------+-----------+------------+
+ | Channel *10* | DMA2 channel 2 | dma2_tcf2 | *0x0A* |
+ +--------------+----------------+-----------+------------+
+ | Channel *11* | DMA2 channel 3 | dma2_tcf3 | *0x0B* |
+ +--------------+----------------+-----------+------------+
+ | Channel *12* | DMA2 channel 4 | dma2_tcf4 | *0x0C* |
+ +--------------+----------------+-----------+------------+
+ | Channel *13* | DMA2 channel 5 | dma2_tcf5 | *0x0D* |
+ +--------------+----------------+-----------+------------+
+ | Channel *14* | DMA2 channel 6 | dma2_tcf6 | *0x0E* |
+ +--------------+----------------+-----------+------------+
+ | Channel *15* | DMA2 channel 7 | dma2_tcf7 | *0x0F* |
+ +--------------+----------------+-----------+------------+
+
+ STM32 DMA-MDMA chaining feature then uses a SRAM buffer. STM32MP1 SoCs embed
+ three fast access static internal RAMs of various size, used for data storage.
+ Due to STM32 DMA legacy (within microcontrollers), STM32 DMA performances are
+ bad with DDR, while they are optimal with SRAM. Hence the SRAM buffer used
+ between STM32 DMA and STM32 MDMA. This buffer is split in two equal periods
+ and STM32 DMA uses one period while STM32 MDMA uses the other period
+ simultaneously.
+ ::
+
+ dma[1:2]-tcf[0:7]
+ .----------------.
+ ____________ ' _________ V____________
+ | STM32 DMA | / __|>_ \ | STM32 MDMA |
+ |------------| | / \ | |------------|
+ | DMA_SxM0AR |<=>| | SRAM | |<=>| []-[]...[] |
+ | DMA_SxM1AR | | \_____/ | | |
+ |____________| \___<|____/ |____________|
+
+ STM32 DMA-MDMA chaining uses (struct dma_slave_config).peripheral_config to
+ exchange the parameters needed to configure MDMA. These parameters are
+ gathered into a u32 array with three values:
+
+ * the STM32 MDMA request (which is actually the DMAMUX channel ID),
+ * the address of the STM32 DMA register to clear the Transfer Complete
+ interrupt flag,
+ * the mask of the Transfer Complete interrupt flag of the STM32 DMA channel.
+
+Device Tree updates for STM32 DMA-MDMA chaining support
+-------------------------------------------------------
+
+ **1. Allocate a SRAM buffer**
+
+ SRAM device tree node is defined in SoC device tree. You can refer to it in
+ your board device tree to define your SRAM pool.
+ ::
+
+ &sram {
+ my_foo_device_dma_pool: dma-sram@0 {
+ reg = <0x0 0x1000>;
+ };
+ };
+
+ Be careful of the start index, in case there are other SRAM consumers.
+ Define your pool size strategically: to optimise chaining, the idea is that
+ STM32 DMA and STM32 MDMA can work simultaneously, on each buffer of the
+ SRAM.
+ If the SRAM period is greater than the expected DMA transfer, then STM32 DMA
+ and STM32 MDMA will work sequentially instead of simultaneously. It is not a
+ functional issue but it is not optimal.
+
+ Don't forget to refer to your SRAM pool in your device node. You need to
+ define a new property.
+ ::
+
+ &my_foo_device {
+ ...
+ my_dma_pool = &my_foo_device_dma_pool;
+ };
+
+ Then get this SRAM pool in your foo driver and allocate your SRAM buffer.
+
+ **2. Allocate a STM32 DMA channel and a STM32 MDMA channel**
+
+ You need to define an extra channel in your device tree node, in addition to
+ the one you should already have for "classic" DMA operation.
+
+ This new channel must be taken from STM32 MDMA channels, so, the phandle of
+ the DMA controller to use is the MDMA controller's one.
+ ::
+
+ &my_foo_device {
+ [...]
+ my_dma_pool = &my_foo_device_dma_pool;
+ dmas = <&dmamux1 ...>, // STM32 DMA channel
+ <&mdma1 0 0x3 0x1200000a 0 0>; // + STM32 MDMA channel
+ };
+
+ Concerning STM32 MDMA bindings:
+
+ 1. The request line number : whatever the value here, it will be overwritten
+ by MDMA driver with the STM32 DMAMUX channel ID passed through
+ (struct dma_slave_config).peripheral_config
+
+ 2. The priority level : choose Very High (0x3) so that your channel will
+ take priority other the other during request arbitration
+
+ 3. A 32bit mask specifying the DMA channel configuration : source and
+ destination address increment, block transfer with 128 bytes per single
+ transfer
+
+ 4. The 32bit value specifying the register to be used to acknowledge the
+ request: it will be overwritten by MDMA driver, with the DMA channel
+ interrupt flag clear register address passed through
+ (struct dma_slave_config).peripheral_config
+
+ 5. The 32bit mask specifying the value to be written to acknowledge the
+ request: it will be overwritten by MDMA driver, with the DMA channel
+ Transfer Complete flag passed through
+ (struct dma_slave_config).peripheral_config
+
+Driver updates for STM32 DMA-MDMA chaining support in foo driver
+----------------------------------------------------------------
+
+ **0. (optional) Refactor the original sg_table if dmaengine_prep_slave_sg()**
+
+ In case of dmaengine_prep_slave_sg(), the original sg_table can't be used as
+ is. Two new sg_tables must be created from the original one. One for
+ STM32 DMA transfer (where memory address targets now the SRAM buffer instead
+ of DDR buffer) and one for STM32 MDMA transfer (where memory address targets
+ the DDR buffer).
+
+ The new sg_list items must fit SRAM period length. Here is an example for
+ DMA_DEV_TO_MEM:
+ ::
+
+ /*
+ * Assuming sgl and nents, respectively the initial scatterlist and its
+ * length.
+ * Assuming sram_dma_buf and sram_period, respectively the memory
+ * allocated from the pool for DMA usage, and the length of the period,
+ * which is half of the sram_buf size.
+ */
+ struct sg_table new_dma_sgt, new_mdma_sgt;
+ struct scatterlist *s, *_sgl;
+ dma_addr_t ddr_dma_buf;
+ u32 new_nents = 0, len;
+ int i;
+
+ /* Count the number of entries needed */
+ for_each_sg(sgl, s, nents, i)
+ if (sg_dma_len(s) > sram_period)
+ new_nents += DIV_ROUND_UP(sg_dma_len(s), sram_period);
+ else
+ new_nents++;
+
+ /* Create sg table for STM32 DMA channel */
+ ret = sg_alloc_table(&new_dma_sgt, new_nents, GFP_ATOMIC);
+ if (ret)
+ dev_err(dev, "DMA sg table alloc failed\n");
+
+ for_each_sg(new_dma_sgt.sgl, s, new_dma_sgt.nents, i) {
+ _sgl = sgl;
+ sg_dma_len(s) = min(sg_dma_len(_sgl), sram_period);
+ /* Targets the beginning = first half of the sram_buf */
+ s->dma_address = sram_buf;
+ /*
+ * Targets the second half of the sram_buf
+ * for odd indexes of the item of the sg_list
+ */
+ if (i & 1)
+ s->dma_address += sram_period;
+ }
+
+ /* Create sg table for STM32 MDMA channel */
+ ret = sg_alloc_table(&new_mdma_sgt, new_nents, GFP_ATOMIC);
+ if (ret)
+ dev_err(dev, "MDMA sg_table alloc failed\n");
+
+ _sgl = sgl;
+ len = sg_dma_len(sgl);
+ ddr_dma_buf = sg_dma_address(sgl);
+ for_each_sg(mdma_sgt.sgl, s, mdma_sgt.nents, i) {
+ size_t bytes = min_t(size_t, len, sram_period);
+
+ sg_dma_len(s) = bytes;
+ sg_dma_address(s) = ddr_dma_buf;
+ len -= bytes;
+
+ if (!len && sg_next(_sgl)) {
+ _sgl = sg_next(_sgl);
+ len = sg_dma_len(_sgl);
+ ddr_dma_buf = sg_dma_address(_sgl);
+ } else {
+ ddr_dma_buf += bytes;
+ }
+ }
+
+ Don't forget to release these new sg_tables after getting the descriptors
+ with dmaengine_prep_slave_sg().
+
+ **1. Set controller specific parameters**
+
+ First, use dmaengine_slave_config() with a struct dma_slave_config to
+ configure STM32 DMA channel. You just have to take care of DMA addresses,
+ the memory address (depending on the transfer direction) must point on your
+ SRAM buffer, and set (struct dma_slave_config).peripheral_size != 0.
+
+ STM32 DMA driver will check (struct dma_slave_config).peripheral_size to
+ determine if chaining is being used or not. If it is used, then STM32 DMA
+ driver fills (struct dma_slave_config).peripheral_config with an array of
+ three u32 : the first one containing STM32 DMAMUX channel ID, the second one
+ the channel interrupt flag clear register address, and the third one the
+ channel Transfer Complete flag mask.
+
+ Then, use dmaengine_slave_config with another struct dma_slave_config to
+ configure STM32 MDMA channel. Take care of DMA addresses, the device address
+ (depending on the transfer direction) must point on your SRAM buffer, and
+ the memory address must point to the buffer originally used for "classic"
+ DMA operation. Use the previous (struct dma_slave_config).peripheral_size
+ and .peripheral_config that have been updated by STM32 DMA driver, to set
+ (struct dma_slave_config).peripheral_size and .peripheral_config of the
+ struct dma_slave_config to configure STM32 MDMA channel.
+ ::
+
+ struct dma_slave_config dma_conf;
+ struct dma_slave_config mdma_conf;
+
+ memset(&dma_conf, 0, sizeof(dma_conf));
+ [...]
+ config.direction = DMA_DEV_TO_MEM;
+ config.dst_addr = sram_dma_buf; // SRAM buffer
+ config.peripheral_size = 1; // peripheral_size != 0 => chaining
+
+ dmaengine_slave_config(dma_chan, &dma_config);
+
+ memset(&mdma_conf, 0, sizeof(mdma_conf));
+ config.direction = DMA_DEV_TO_MEM;
+ mdma_conf.src_addr = sram_dma_buf; // SRAM buffer
+ mdma_conf.dst_addr = rx_dma_buf; // original memory buffer
+ mdma_conf.peripheral_size = dma_conf.peripheral_size; // <- dma_conf
+ mdma_conf.peripheral_config = dma_config.peripheral_config; // <- dma_conf
+
+ dmaengine_slave_config(mdma_chan, &mdma_conf);
+
+ **2. Get a descriptor for STM32 DMA channel transaction**
+
+ In the same way you get your descriptor for your "classic" DMA operation,
+ you just have to replace the original sg_list (in case of
+ dmaengine_prep_slave_sg()) with the new sg_list using SRAM buffer, or to
+ replace the original buffer address, length and period (in case of
+ dmaengine_prep_dma_cyclic()) with the new SRAM buffer.
+
+ **3. Get a descriptor for STM32 MDMA channel transaction**
+
+ If you previously get descriptor (for STM32 DMA) with
+
+ * dmaengine_prep_slave_sg(), then use dmaengine_prep_slave_sg() for
+ STM32 MDMA;
+ * dmaengine_prep_dma_cyclic(), then use dmaengine_prep_dma_cyclic() for
+ STM32 MDMA.
+
+ Use the new sg_list using SRAM buffer (in case of dmaengine_prep_slave_sg())
+ or, depending on the transfer direction, either the original DDR buffer (in
+ case of DMA_DEV_TO_MEM) or the SRAM buffer (in case of DMA_MEM_TO_DEV), the
+ source address being previously set with dmaengine_slave_config().
+
+ **4. Submit both transactions**
+
+ Before submitting your transactions, you may need to define on which
+ descriptor you want a callback to be called at the end of the transfer
+ (dmaengine_prep_slave_sg()) or the period (dmaengine_prep_dma_cyclic()).
+ Depending on the direction, set the callback on the descriptor that finishes
+ the overall transfer:
+
+ * DMA_DEV_TO_MEM: set the callback on the "MDMA" descriptor
+ * DMA_MEM_TO_DEV: set the callback on the "DMA" descriptor
+
+ Then, submit the descriptors whatever the order, with dmaengine_tx_submit().
+
+ **5. Issue pending requests (and wait for callback notification)**
+
+ As STM32 MDMA channel transfer is triggered by STM32 DMA, you must issue
+ STM32 MDMA channel before STM32 DMA channel.
+
+ If any, your callback will be called to warn you about the end of the overall
+ transfer or the period completion.
+
+ Don't forget to terminate both channels. STM32 DMA channel is configured in
+ cyclic Double-Buffer mode so it won't be disabled by HW, you need to terminate
+ it. STM32 MDMA channel will be stopped by HW in case of sg transfer, but not
+ in case of cyclic transfer. You can terminate it whatever the kind of transfer.
+
+ **STM32 DMA-MDMA chaining DMA_MEM_TO_DEV special case**
+
+ STM32 DMA-MDMA chaining in DMA_MEM_TO_DEV is a special case. Indeed, the
+ STM32 MDMA feeds the SRAM buffer with the DDR data, and the STM32 DMA reads
+ data from SRAM buffer. So some data (the first period) have to be copied in
+ SRAM buffer when the STM32 DMA starts to read.
+
+ A trick could be pausing the STM32 DMA channel (that will raise a Transfer
+ Complete signal, triggering the STM32 MDMA channel), but the first data read
+ by the STM32 DMA could be "wrong". The proper way is to prepare the first SRAM
+ period with dmaengine_prep_dma_memcpy(). Then this first period should be
+ "removed" from the sg or the cyclic transfer.
+
+ Due to this complexity, rather use the STM32 DMA-MDMA chaining for
+ DMA_DEV_TO_MEM and keep the "classic" DMA usage for DMA_MEM_TO_DEV, unless
+ you're not afraid.
+
+Resources
+---------
+
+ Application note, datasheet and reference manual are available on ST website
+ (STM32MP1_).
+
+ Dedicated focus on three application notes (AN5224_, AN4031_ & AN5001_)
+ dealing with STM32 DMAMUX, STM32 DMA and STM32 MDMA.
+
+.. _STM32MP1: https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html
+.. _AN5224: https://www.st.com/resource/en/application_note/an5224-stm32-dmamux-the-dma-request-router-stmicroelectronics.pdf
+.. _AN4031: https://www.st.com/resource/en/application_note/dm00046011-using-the-stm32f2-stm32f4-and-stm32f7-series-dma-controller-stmicroelectronics.pdf
+.. _AN5001: https://www.st.com/resource/en/application_note/an5001-stm32cube-expansion-package-for-stm32h7-series-mdma-stmicroelectronics.pdf
+
+:Authors:
+
+- Amelie Delaunay <amelie.delaunay@foss.st.com> \ No newline at end of file
diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arch/arm/stm32/stm32f429-overview.rst
index a7ebe8ea6697..a7ebe8ea6697 100644
--- a/Documentation/arm/stm32/stm32f429-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32f429-overview.rst
diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arch/arm/stm32/stm32f746-overview.rst
index 78befddc7740..335f0855a858 100644
--- a/Documentation/arm/stm32/stm32f746-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32f746-overview.rst
@@ -15,7 +15,7 @@ It features:
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
-- I2C, SPI, CAN busses support
+- I2C, SPI, CAN buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arch/arm/stm32/stm32f769-overview.rst
index e482980ddf21..ef31aadee68f 100644
--- a/Documentation/arm/stm32/stm32f769-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32f769-overview.rst
@@ -15,7 +15,7 @@ It features:
- SD/MMC/SDIO support*2
- Ethernet controller
- USB OTFG FS & HS controllers
-- I2C*4, SPI*6, CAN*3 busses support
+- I2C*4, SPI*6, CAN*3 buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface*2
- LCD controller
diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arch/arm/stm32/stm32h743-overview.rst
index 4e15f1a42730..7659df24d362 100644
--- a/Documentation/arm/stm32/stm32h743-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32h743-overview.rst
@@ -15,7 +15,7 @@ It features:
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
-- I2C, SPI, CAN busses support
+- I2C, SPI, CAN buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
diff --git a/Documentation/arm/stm32/stm32h750-overview.rst b/Documentation/arch/arm/stm32/stm32h750-overview.rst
index 0e51235c9547..be032b77d1f1 100644
--- a/Documentation/arm/stm32/stm32h750-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32h750-overview.rst
@@ -15,7 +15,7 @@ It features:
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
-- I2C, SPI, CAN busses support
+- I2C, SPI, CAN buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
diff --git a/Documentation/arm/stm32/stm32mp13-overview.rst b/Documentation/arch/arm/stm32/stm32mp13-overview.rst
index 3bb9492dad49..b5e9589fb06f 100644
--- a/Documentation/arm/stm32/stm32mp13-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32mp13-overview.rst
@@ -24,7 +24,7 @@ More details:
- ADC/DAC
- USB EHCI/OHCI controllers
- USB OTG
-- I2C, SPI, CAN busses support
+- I2C, SPI, CAN buses support
- Several general purpose timers
- Serial Audio interface
- LCD controller
diff --git a/Documentation/arch/arm/stm32/stm32mp151-overview.rst b/Documentation/arch/arm/stm32/stm32mp151-overview.rst
new file mode 100644
index 000000000000..b58c256ede9a
--- /dev/null
+++ b/Documentation/arch/arm/stm32/stm32mp151-overview.rst
@@ -0,0 +1,36 @@
+===================
+STM32MP151 Overview
+===================
+
+Introduction
+------------
+
+The STM32MP151 is a Cortex-A MPU aimed at various applications.
+It features:
+
+- Single Cortex-A7 application core
+- Standard memories interface support
+- Standard connectivity, widely inherited from the STM32 MCU family
+- Comprehensive security support
+
+More details:
+
+- Cortex-A7 core running up to @800MHz
+- FMC controller to connect SDRAM, NOR and NAND memories
+- QSPI
+- SD/MMC/SDIO support
+- Ethernet controller
+- ADC/DAC
+- USB EHCI/OHCI controllers
+- USB OTG
+- I2C, SPI buses support
+- Several general purpose timers
+- Serial Audio interface
+- LCD-TFT controller
+- DCMIPP
+- SPDIFRX
+- DFSDM
+
+:Authors:
+
+- Roan van Dijk <roan@protonic.nl>
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arch/arm/stm32/stm32mp157-overview.rst
index f62fdc8e7d8d..f62fdc8e7d8d 100644
--- a/Documentation/arm/stm32/stm32mp157-overview.rst
+++ b/Documentation/arch/arm/stm32/stm32mp157-overview.rst
diff --git a/Documentation/arm/sunxi.rst b/Documentation/arch/arm/sunxi.rst
index b85d1e2f2d47..b85d1e2f2d47 100644
--- a/Documentation/arm/sunxi.rst
+++ b/Documentation/arch/arm/sunxi.rst
diff --git a/Documentation/arm/sunxi/clocks.rst b/Documentation/arch/arm/sunxi/clocks.rst
index 23bd03f3e21f..dfe6d4887210 100644
--- a/Documentation/arm/sunxi/clocks.rst
+++ b/Documentation/arch/arm/sunxi/clocks.rst
@@ -5,7 +5,7 @@ Frequently asked questions about the sunxi clock system
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
-Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
+Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
diff --git a/Documentation/arm/swp_emulation.rst b/Documentation/arch/arm/swp_emulation.rst
index 6a608a9c3715..bf205e3de36e 100644
--- a/Documentation/arm/swp_emulation.rst
+++ b/Documentation/arch/arm/swp_emulation.rst
@@ -1,7 +1,7 @@
Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE)
---------------------------------------------------------------------
-ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds
+ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends
moving to the load-locked/store-conditional instructions LDREX and STREX.
ARMv7 multiprocessing extensions introduce the ability to disable these
diff --git a/Documentation/arm/tcm.rst b/Documentation/arch/arm/tcm.rst
index 1dc6c39220f9..7ce17a248af9 100644
--- a/Documentation/arm/tcm.rst
+++ b/Documentation/arch/arm/tcm.rst
@@ -71,7 +71,7 @@ in <asm/tcm.h>. Using this interface it is possible to:
- Have the remaining TCM RAM added to a special
allocation pool with gen_pool_create() and gen_pool_add()
- and provice tcm_alloc() and tcm_free() for this
+ and provide tcm_alloc() and tcm_free() for this
memory. Such a heap is great for things like saving
device state when shutting off device power domains.
diff --git a/Documentation/arch/arm/uefi.rst b/Documentation/arch/arm/uefi.rst
new file mode 100644
index 000000000000..2b7ad9bd7cd2
--- /dev/null
+++ b/Documentation/arch/arm/uefi.rst
@@ -0,0 +1,72 @@
+================================================
+The Unified Extensible Firmware Interface (UEFI)
+================================================
+
+UEFI, the Unified Extensible Firmware Interface, is a specification
+governing the behaviours of compatible firmware interfaces. It is
+maintained by the UEFI Forum - http://www.uefi.org/.
+
+UEFI is an evolution of its predecessor 'EFI', so the terms EFI and
+UEFI are used somewhat interchangeably in this document and associated
+source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers
+to legacy code or specifications.
+
+UEFI support in Linux
+=====================
+Booting on a platform with firmware compliant with the UEFI specification
+makes it possible for the kernel to support additional features:
+
+- UEFI Runtime Services
+- Retrieving various configuration information through the standardised
+ interface of UEFI configuration tables. (ACPI, SMBIOS, ...)
+
+For actually enabling [U]EFI support, enable:
+
+- CONFIG_EFI=y
+- CONFIG_EFIVAR_FS=y or m
+
+The implementation depends on receiving information about the UEFI environment
+in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF.
+
+UEFI stub
+=========
+The "stub" is a feature that extends the Image/zImage into a valid UEFI
+PE/COFF executable, including a loader application that makes it possible to
+load the kernel directly from the UEFI shell, boot menu, or one of the
+lightweight bootloaders like Gummiboot or rEFInd.
+
+The kernel image built with stub support remains a valid kernel image for
+booting in non-UEFI environments.
+
+UEFI kernel support on ARM
+==========================
+UEFI kernel support on the ARM architectures (arm and arm64) is only available
+when boot is performed through the stub.
+
+When booting in UEFI mode, the stub deletes any memory nodes from a provided DT.
+Instead, the kernel reads the UEFI memory map.
+
+The stub populates the FDT /chosen node with (and the kernel scans for) the
+following parameters:
+
+========================== ====== ===========================================
+Name Type Description
+========================== ====== ===========================================
+linux,uefi-system-table 64-bit Physical address of the UEFI System Table.
+
+linux,uefi-mmap-start 64-bit Physical address of the UEFI memory map,
+ populated by the UEFI GetMemoryMap() call.
+
+linux,uefi-mmap-size 32-bit Size in bytes of the UEFI memory map
+ pointed to in previous entry.
+
+linux,uefi-mmap-desc-size 32-bit Size in bytes of each entry in the UEFI
+ memory map.
+
+linux,uefi-mmap-desc-ver 32-bit Version of the mmap descriptor format.
+
+kaslr-seed 64-bit Entropy used to randomize the kernel image
+ base address location.
+
+bootargs String Kernel command line
+========================== ====== ===========================================
diff --git a/Documentation/arm/vfp/release-notes.rst b/Documentation/arch/arm/vfp/release-notes.rst
index c6b04937cee3..c6b04937cee3 100644
--- a/Documentation/arm/vfp/release-notes.rst
+++ b/Documentation/arch/arm/vfp/release-notes.rst
diff --git a/Documentation/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst
index a40a1742110b..737aa8661a21 100644
--- a/Documentation/arm/vlocks.rst
+++ b/Documentation/arch/arm/vlocks.rst
@@ -155,7 +155,7 @@ the basic algorithm:
optimisation.
If there are too many CPUs to read the currently_voting array in
- one transaction then multiple transations are still required. The
+ one transaction then multiple transactions are still required. The
implementation uses a simple loop of word-sized loads for this
case. The number of transactions is still fewer than would be
required if bytes were loaded individually.
diff --git a/Documentation/arm64/acpi_object_usage.rst b/Documentation/arch/arm64/acpi_object_usage.rst
index 0609da73970b..06d8a87971ef 100644
--- a/Documentation/arm64/acpi_object_usage.rst
+++ b/Documentation/arch/arm64/acpi_object_usage.rst
@@ -17,16 +17,37 @@ For ACPI on arm64, tables also fall into the following categories:
- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
- - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT,
- IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT,
- STAO, TCPA, TPM2, UEFI, XENV
+ - Optional: AGDI, BGRT, CEDT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT,
+ HMAT, IBFT, IORT, MCHI, MPAM, MPST, MSCT, NFIT, PMTT, PPTT, RASF, SBST,
+ SDEI, SLIT, SPMI, SRAT, STAO, TCPA, TPM2, UEFI, XENV
- - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx,
- PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+ - Not supported: AEST, APMT, BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT,
+ MSDM, OEMx, PDTT, PSDT, RAS2, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
====== ========================================================================
Table Usage for ARMv8 Linux
====== ========================================================================
+AEST Signature Reserved (signature == "AEST")
+
+ **Arm Error Source Table**
+
+ This table informs the OS of any error nodes in the system that are
+ compliant with the Arm RAS architecture.
+
+AGDI Signature Reserved (signature == "AGDI")
+
+ **Arm Generic diagnostic Dump and Reset Device Interface Table**
+
+ This table describes a non-maskable event, that is used by the platform
+ firmware, to request the OS to generate a diagnostic dump and reset the device.
+
+APMT Signature Reserved (signature == "APMT")
+
+ **Arm Performance Monitoring Table**
+
+ This table describes the properties of PMU support implemented by
+ components in the system.
+
BERT Section 18.3 (signature == "BERT")
**Boot Error Record Table**
@@ -47,6 +68,13 @@ BGRT Section 5.2.22 (signature == "BGRT")
Optional, not currently supported, with no real use-case for an
ARM server.
+CEDT Signature Reserved (signature == "CEDT")
+
+ **CXL Early Discovery Table**
+
+ This table allows the OS to discover any CXL Host Bridges and the Host
+ Bridge registers.
+
CPEP Section 5.2.18 (signature == "CPEP")
**Corrected Platform Error Polling table**
@@ -163,7 +191,7 @@ FPDT Section 5.2.23 (signature == "FPDT")
**Firmware Performance Data Table**
- Optional, not currently supported.
+ Optional, useful for boot performance profiling.
GTDT Section 5.2.24 (signature == "GTDT")
@@ -184,6 +212,15 @@ HEST Section 18.3.2 (signature == "HEST")
Must be supplied if RAS support is provided by the platform. It
is recommended this table be supplied.
+HMAT Section 5.2.28 (signature == "HMAT")
+
+ **Heterogeneous Memory Attribute Table**
+
+ This table describes the memory attributes, such as memory side cache
+ attributes and bandwidth and latency details, related to Memory Proximity
+ Domains. The OS uses this information to optimize the system memory
+ configuration.
+
HPET Signature Reserved (signature == "HPET")
**High Precision Event timer Table**
@@ -241,6 +278,13 @@ MCHI Signature Reserved (signature == "MCHI")
Optional, not currently supported.
+MPAM Signature Reserved (signature == "MPAM")
+
+ **Memory Partitioning And Monitoring table**
+
+ This table allows the OS to discover the MPAM controls implemented by
+ the subsystems.
+
MPST Section 5.2.21 (signature == "MPST")
**Memory Power State Table**
@@ -281,18 +325,39 @@ PCCT Section 14.1 (signature == "PCCT)
Recommend for use on arm64; use of PCC is recommended when using CPPC
to control performance and power for platform processors.
+PDTT Section 5.2.29 (signature == "PDTT")
+
+ **Platform Debug Trigger Table**
+
+ This table describes PCC channels used to gather debug logs of
+ non-architectural features.
+
+
PMTT Section 5.2.21.12 (signature == "PMTT")
**Platform Memory Topology Table**
Optional, not currently supported.
+PPTT Section 5.2.30 (signature == "PPTT")
+
+ **Processor Properties Topology Table**
+
+ This table provides the processor and cache topology.
+
PSDT Section 5.2.11.3 (signature == "PSDT")
**Persistent System Description Table**
Obsolete table, will not be supported.
+RAS2 Section 5.2.21 (signature == "RAS2")
+
+ **RAS Features 2 table**
+
+ This table provides interfaces for the RAS capabilities implemented in
+ the platform.
+
RASF Section 5.2.20 (signature == "RASF")
**RAS Feature table**
@@ -318,6 +383,12 @@ SBST Section 5.2.14 (signature == "SBST")
Optional, not currently supported.
+SDEI Signature Reserved (signature == "SDEI")
+
+ **Software Delegated Exception Interface table**
+
+ This table advertises the presence of the SDEI interface.
+
SLIC Signature Reserved (signature == "SLIC")
**Software LIcensing table**
diff --git a/Documentation/arch/arm64/amu.rst b/Documentation/arch/arm64/amu.rst
new file mode 100644
index 000000000000..ac1b3f0e211d
--- /dev/null
+++ b/Documentation/arch/arm64/amu.rst
@@ -0,0 +1,119 @@
+.. _amu_index:
+
+=======================================================
+Activity Monitors Unit (AMU) extension in AArch64 Linux
+=======================================================
+
+Author: Ionela Voinescu <ionela.voinescu@arm.com>
+
+Date: 2019-09-10
+
+This document briefly describes the provision of Activity Monitors Unit
+support in AArch64 Linux.
+
+
+Architecture overview
+---------------------
+
+The activity monitors extension is an optional extension introduced by the
+ARMv8.4 CPU architecture.
+
+The activity monitors unit, implemented in each CPU, provides performance
+counters intended for system management use. The AMU extension provides a
+system register interface to the counter registers and also supports an
+optional external memory-mapped interface.
+
+Version 1 of the Activity Monitors architecture implements a counter group
+of four fixed and architecturally defined 64-bit event counters.
+
+ - CPU cycle counter: increments at the frequency of the CPU.
+ - Constant counter: increments at the fixed frequency of the system
+ clock.
+ - Instructions retired: increments with every architecturally executed
+ instruction.
+ - Memory stall cycles: counts instruction dispatch stall cycles caused by
+ misses in the last level cache within the clock domain.
+
+When in WFI or WFE these counters do not increment.
+
+The Activity Monitors architecture provides space for up to 16 architected
+event counters. Future versions of the architecture may use this space to
+implement additional architected event counters.
+
+Additionally, version 1 implements a counter group of up to 16 auxiliary
+64-bit event counters.
+
+On cold reset all counters reset to 0.
+
+
+Basic support
+-------------
+
+The kernel can safely run a mix of CPUs with and without support for the
+activity monitors extension. Therefore, when CONFIG_ARM64_AMU_EXTN is
+selected we unconditionally enable the capability to allow any late CPU
+(secondary or hotplugged) to detect and use the feature.
+
+When the feature is detected on a CPU, we flag the availability of the
+feature but this does not guarantee the correct functionality of the
+counters, only the presence of the extension.
+
+Firmware (code running at higher exception levels, e.g. arm-tf) support is
+needed to:
+
+ - Enable access for lower exception levels (EL2 and EL1) to the AMU
+ registers.
+ - Enable the counters. If not enabled these will read as 0.
+ - Save/restore the counters before/after the CPU is being put/brought up
+ from the 'off' power state.
+
+When using kernels that have this feature enabled but boot with broken
+firmware the user may experience panics or lockups when accessing the
+counter registers. Even if these symptoms are not observed, the values
+returned by the register reads might not correctly reflect reality. Most
+commonly, the counters will read as 0, indicating that they are not
+enabled.
+
+If proper support is not provided in firmware it's best to disable
+CONFIG_ARM64_AMU_EXTN. To be noted that for security reasons, this does not
+bypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) to
+EL1 (kernel). Therefore, firmware should still ensure accesses to AMU registers
+are not trapped in EL2/EL3.
+
+The fixed counters of AMUv1 are accessible through the following system
+register definitions:
+
+ - SYS_AMEVCNTR0_CORE_EL0
+ - SYS_AMEVCNTR0_CONST_EL0
+ - SYS_AMEVCNTR0_INST_RET_EL0
+ - SYS_AMEVCNTR0_MEM_STALL_EL0
+
+Auxiliary platform specific counters can be accessed using
+SYS_AMEVCNTR1_EL0(n), where n is a value between 0 and 15.
+
+Details can be found in: arch/arm64/include/asm/sysreg.h.
+
+
+Userspace access
+----------------
+
+Currently, access from userspace to the AMU registers is disabled due to:
+
+ - Security reasons: they might expose information about code executed in
+ secure mode.
+ - Purpose: AMU counters are intended for system management use.
+
+Also, the presence of the feature is not visible to userspace.
+
+
+Virtualization
+--------------
+
+Currently, access from userspace (EL0) and kernelspace (EL1) on the KVM
+guest side is disabled due to:
+
+ - Security reasons: they might expose information about code executed
+ by other guests or the host.
+
+Any attempt to access the AMU registers will result in an UNDEFINED
+exception being injected into the guest.
diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst
index 47ecb9930dde..e59e4505d0d9 100644
--- a/Documentation/arm64/arm-acpi.rst
+++ b/Documentation/arch/arm64/arm-acpi.rst
@@ -1,40 +1,41 @@
-=====================
-ACPI on ARMv8 Servers
-=====================
-
-ACPI can be used for ARMv8 general purpose servers designed to follow
-the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
-Base Boot Requirements) [1] specifications. Please note that the SBBR
-can be retrieved simply by visiting [1], but the SBSA is currently only
-available to those with an ARM login due to ARM IP licensing concerns.
-
-The ARMv8 kernel implements the reduced hardware model of ACPI version
+===================
+ACPI on Arm systems
+===================
+
+ACPI can be used for Armv8 and Armv9 systems designed to follow
+the BSA (Arm Base System Architecture) [0] and BBR (Arm
+Base Boot Requirements) [1] specifications. Both BSA and BBR are publicly
+accessible documents.
+Arm Servers, in addition to being BSA compliant, comply with a set
+of rules defined in SBSA (Server Base System Architecture) [2].
+
+The Arm kernel implements the reduced hardware model of ACPI version
5.1 or later. Links to the specification and all external documents
it refers to are managed by the UEFI Forum. The specification is
available at http://www.uefi.org/specifications and documents referenced
by the specification can be found via http://www.uefi.org/acpi.
-If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
+If an Arm system does not meet the requirements of the BSA and BBR,
or cannot be described using the mechanisms defined in the required ACPI
specifications, then ACPI may not be a good fit for the hardware.
While the documents mentioned above set out the requirements for building
-industry-standard ARMv8 servers, they also apply to more than one operating
+industry-standard Arm systems, they also apply to more than one operating
system. The purpose of this document is to describe the interaction between
-ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
+ACPI and Linux only, on an Arm system -- that is, what Linux expects of
ACPI and what ACPI can expect of Linux.
-Why ACPI on ARM?
+Why ACPI on Arm?
----------------
Before examining the details of the interface between ACPI and Linux, it is
useful to understand why ACPI is being used. Several technologies already
exist in Linux for describing non-enumerable hardware, after all. In this
-section we summarize a blog post [2] from Grant Likely that outlines the
-reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
+section we summarize a blog post [3] from Grant Likely that outlines the
+reasoning behind ACPI on Arm systems. Actually, we snitch a good portion
of the summary text almost directly, to be honest.
-The short form of the rationale for ACPI on ARM is:
+The short form of the rationale for ACPI on Arm is:
- ACPI’s byte code (AML) allows the platform to encode hardware behavior,
while DT explicitly does not support this. For hardware vendors, being
@@ -47,7 +48,7 @@ The short form of the rationale for ACPI on ARM is:
- In the enterprise server environment, ACPI has established bindings (such
as for RAS) which are currently used in production systems. DT does not.
- Such bindings could be defined in DT at some point, but doing so means ARM
+ Such bindings could be defined in DT at some point, but doing so means Arm
and x86 would end up using completely different code paths in both firmware
and the kernel.
@@ -98,7 +99,7 @@ to replace the kernel.
When a Linux driver or subsystem is first implemented using ACPI, it by
definition ends up requiring a specific version of the ACPI specification
--- it's baseline. ACPI firmware must continue to work, even though it may
+-- its baseline. ACPI firmware must continue to work, even though it may
not be optimal, with the earliest kernel version that first provides support
for that baseline version of ACPI. There may be a need for additional drivers,
but adding new functionality (e.g., CPU power management) should not break
@@ -108,7 +109,7 @@ recent version of the kernel.
Relationship with Device Tree
-----------------------------
-ACPI support in drivers and subsystems for ARMv8 should never be mutually
+ACPI support in drivers and subsystems for Arm should never be mutually
exclusive with DT support at compile time.
At boot time the kernel will only use one description method depending on
@@ -121,15 +122,15 @@ time).
Booting using ACPI tables
-------------------------
-The only defined method for passing ACPI tables to the kernel on ARMv8
+The only defined method for passing ACPI tables to the kernel on Arm
is via the UEFI system configuration table. Just so it is explicit, this
means that ACPI is only supported on platforms that boot via UEFI.
-When an ARMv8 system boots, it can either have DT information, ACPI tables,
+When an Arm system boots, it can either have DT information, ACPI tables,
or in some very unusual cases, both. If no command line parameters are used,
the kernel will try to use DT for device enumeration; if there is no DT
present, the kernel will try to use ACPI tables, but only if they are present.
-In neither is available, the kernel will not boot. If acpi=force is used
+If neither is available, the kernel will not boot. If acpi=force is used
on the command line, the kernel will attempt to use ACPI tables first, but
fall back to DT if there are no ACPI tables present. The basic idea is that
the kernel will not fail to boot unless it absolutely has no other choice.
@@ -169,7 +170,7 @@ hardware reduced mode must be set to zero.
For the ACPI core to operate properly, and in turn provide the information
the kernel needs to configure devices, it expects to find the following
-tables (all section numbers refer to the ACPI 6.1 specification):
+tables (all section numbers refer to the ACPI 6.5 specification):
- RSDP (Root System Description Pointer), section 5.2.5
@@ -184,20 +185,76 @@ tables (all section numbers refer to the ACPI 6.1 specification):
- GTDT (Generic Timer Description Table), section 5.2.24
+ - PPTT (Processor Properties Topology Table), section 5.2.30
+
+ - DBG2 (DeBuG port table 2), section 5.2.6, specifically Table 5-6.
+
+ - APMT (Arm Performance Monitoring unit Table), section 5.2.6, specifically Table 5-6.
+
+ - AGDI (Arm Generic diagnostic Dump and Reset Device Interface Table), section 5.2.6, specifically Table 5-6.
+
- If PCI is supported, the MCFG (Memory mapped ConFiGuration
- Table), section 5.2.6, specifically Table 5-31.
+ Table), section 5.2.6, specifically Table 5-6.
- If booting without a console=<device> kernel parameter is
supported, the SPCR (Serial Port Console Redirection table),
- section 5.2.6, specifically Table 5-31.
+ section 5.2.6, specifically Table 5-6.
- If necessary to describe the I/O topology, SMMUs and GIC ITSs,
the IORT (Input Output Remapping Table, section 5.2.6, specifically
- Table 5-31).
+ Table 5-6).
+
+ - If NUMA is supported, the following tables are required:
+
+ - SRAT (System Resource Affinity Table), section 5.2.16
+
+ - SLIT (System Locality distance Information Table), section 5.2.17
+
+ - If NUMA is supported, and the system contains heterogeneous memory,
+ the HMAT (Heterogeneous Memory Attribute Table), section 5.2.28.
+
+ - If the ACPI Platform Error Interfaces are required, the following
+ tables are conditionally required:
+
+ - BERT (Boot Error Record Table, section 18.3.1)
+
+ - EINJ (Error INJection table, section 18.6.1)
+
+ - ERST (Error Record Serialization Table, section 18.5)
+
+ - HEST (Hardware Error Source Table, section 18.3.2)
+
+ - SDEI (Software Delegated Exception Interface table, section 5.2.6,
+ specifically Table 5-6)
+
+ - AEST (Arm Error Source Table, section 5.2.6,
+ specifically Table 5-6)
+
+ - RAS2 (ACPI RAS2 feature table, section 5.2.21)
+
+ - If the system contains controllers using PCC channel, the
+ PCCT (Platform Communications Channel Table), section 14.1
+
+ - If the system contains a controller to capture board-level system state,
+ and communicates with the host via PCC, the PDTT (Platform Debug Trigger
+ Table), section 5.2.29.
+
+ - If NVDIMM is supported, the NFIT (NVDIMM Firmware Interface Table), section 5.2.26
+
+ - If video framebuffer is present, the BGRT (Boot Graphics Resource Table), section 5.2.23
+
+ - If IPMI is implemented, the SPMI (Server Platform Management Interface),
+ section 5.2.6, specifically Table 5-6.
+
+ - If the system contains a CXL Host Bridge, the CEDT (CXL Early Discovery
+ Table), section 5.2.6, specifically Table 5-6.
+
+ - If the system supports MPAM, the MPAM (Memory Partitioning And Monitoring table), section 5.2.6,
+ specifically Table 5-6.
+
+ - If the system lacks persistent storage, the IBFT (ISCSI Boot Firmware
+ Table), section 5.2.6, specifically Table 5-6.
- - If NUMA is supported, the SRAT (System Resource Affinity Table)
- and SLIT (System Locality distance Information Table), sections
- 5.2.16 and 5.2.17, respectively.
If the above tables are not all present, the kernel may or may not be
able to boot properly since it may not be able to configure all of the
@@ -269,16 +326,14 @@ Drivers should look for device properties in the _DSD object ONLY; the _DSD
object is described in the ACPI specification section 6.2.5, but this only
describes how to define the structure of an object returned via _DSD, and
how specific data structures are defined by specific UUIDs. Linux should
-only use the _DSD Device Properties UUID [5]:
+only use the _DSD Device Properties UUID [4]:
- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
- - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
-
-The UEFI Forum provides a mechanism for registering device properties [4]
-so that they may be used across all operating systems supporting ACPI.
-Device properties that have not been registered with the UEFI Forum should
-not be used.
+Common device properties can be registered by creating a pull request to [4] so
+that they may be used across all operating systems supporting ACPI.
+Device properties that have not been registered with the UEFI Forum can be used
+but not as "uefi-" common properties.
Before creating new device properties, check to be sure that they have not
been defined before and either registered in the Linux kernel documentation
@@ -306,7 +361,7 @@ process.
Once registration and review have been completed, the kernel provides an
interface for looking up device properties in a manner independent of
-whether DT or ACPI is being used. This API should be used [6]; it can
+whether DT or ACPI is being used. This API should be used [5]; it can
eliminate some duplication of code paths in driver probing functions and
discourage divergence between DT bindings and ACPI device properties.
@@ -448,15 +503,15 @@ ASWG
----
The ACPI specification changes regularly. During the year 2014, for instance,
version 5.1 was released and version 6.0 substantially completed, with most of
-the changes being driven by ARM-specific requirements. Proposed changes are
+the changes being driven by Arm-specific requirements. Proposed changes are
presented and discussed in the ASWG (ACPI Specification Working Group) which
is a part of the UEFI Forum. The current version of the ACPI specification
-is 6.1 release in January 2016.
+is 6.5 release in August 2022.
Participation in this group is open to all UEFI members. Please see
http://www.uefi.org/workinggroup for details on group membership.
-It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification
+It is the intent of the Arm ACPI kernel code to follow the ACPI specification
as closely as possible, and to only implement functionality that complies with
the released standards from UEFI ASWG. As a practical matter, there will be
vendors that provide bad ACPI tables or violate the standards in some way.
@@ -470,12 +525,12 @@ likely be willing to assist in submitting ECRs.
Linux Code
----------
-Individual items specific to Linux on ARM, contained in the Linux
+Individual items specific to Linux on Arm, contained in the Linux
source code, are in the list that follows:
ACPI_OS_NAME
This macro defines the string to be returned when
- an ACPI method invokes the _OS method. On ARM64
+ an ACPI method invokes the _OS method. On Arm
systems, this macro will be "Linux" by default.
The command line parameter acpi_os=<string>
can be used to set it to some other value. The
@@ -485,36 +540,28 @@ ACPI_OS_NAME
ACPI Objects
------------
Detailed expectations for ACPI tables and object are listed in the file
-Documentation/arm64/acpi_object_usage.rst.
+Documentation/arch/arm64/acpi_object_usage.rst.
References
----------
-[0] http://silver.arm.com
- document ARM-DEN-0029, or newer:
- "Server Base System Architecture", version 2.3, dated 27 Mar 2014
+[0] https://developer.arm.com/documentation/den0094/latest
+ document Arm-DEN-0094: "Arm Base System Architecture", version 1.0C, dated 6 Oct 2022
+
+[1] https://developer.arm.com/documentation/den0044/latest
+ Document Arm-DEN-0044: "Arm Base Boot Requirements", version 2.0G, dated 15 Apr 2022
-[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf
- Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System
- Software on ARM Platforms", dated 16 Aug 2014
+[2] https://developer.arm.com/documentation/den0029/latest
+ Document Arm-DEN-0029: "Arm Server Base System Architecture", version 7.1, dated 06 Oct 2022
-[2] http://www.secretlab.ca/archives/151,
+[3] http://www.secretlab.ca/archives/151,
10 Jan 2015, Copyright (c) 2015,
Linaro Ltd., written by Grant Likely.
-[3] AMD ACPI for Seattle platform documentation
- http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf
-
-
-[4] http://www.uefi.org/acpi
- please see the link for the "ACPI _DSD Device
- Property Registry Instructions"
-
-[5] http://www.uefi.org/acpi
- please see the link for the "_DSD (Device
- Specific Data) Implementation Guide"
+[4] _DSD (Device Specific Data) Implementation Guide
+ https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
-[6] Kernel code for the unified device
+[5] Kernel code for the unified device
property interface can be found in
include/linux/property.h and drivers/base/property.c.
diff --git a/Documentation/arch/arm64/arm-cca.rst b/Documentation/arch/arm64/arm-cca.rst
new file mode 100644
index 000000000000..c48b7d4ab6bd
--- /dev/null
+++ b/Documentation/arch/arm64/arm-cca.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Arm Confidential Compute Architecture
+=====================================
+
+Arm systems that support the Realm Management Extension (RME) contain
+hardware to allow a VM guest to be run in a way which protects the code
+and data of the guest from the hypervisor. It extends the older "two
+world" model (Normal and Secure World) into four worlds: Normal, Secure,
+Root and Realm. Linux can then also be run as a guest to a monitor
+running in the Realm world.
+
+The monitor running in the Realm world is known as the Realm Management
+Monitor (RMM) and implements the Realm Management Monitor
+specification[1]. The monitor acts a bit like a hypervisor (e.g. it runs
+in EL2 and manages the stage 2 page tables etc of the guests running in
+Realm world), however much of the control is handled by a hypervisor
+running in the Normal World. The Normal World hypervisor uses the Realm
+Management Interface (RMI) defined by the RMM specification to request
+the RMM to perform operations (e.g. mapping memory or executing a vCPU).
+
+The RMM defines an environment for guests where the address space (IPA)
+is split into two. The lower half is protected - any memory that is
+mapped in this half cannot be seen by the Normal World and the RMM
+restricts what operations the Normal World can perform on this memory
+(e.g. the Normal World cannot replace pages in this region without the
+guest's cooperation). The upper half is shared, the Normal World is free
+to make changes to the pages in this region, and is able to emulate MMIO
+devices in this region too.
+
+A guest running in a Realm may also communicate with the RMM using the
+Realm Services Interface (RSI) to request changes in its environment or
+to perform attestation about its environment. In particular it may
+request that areas of the protected address space are transitioned
+between 'RAM' and 'EMPTY' (in either direction). This allows a Realm
+guest to give up memory to be returned to the Normal World, or to
+request new memory from the Normal World. Without an explicit request
+from the Realm guest the RMM will otherwise prevent the Normal World
+from making these changes.
+
+Linux as a Realm Guest
+----------------------
+
+To run Linux as a guest within a Realm, the following must be provided
+either by the VMM or by a `boot loader` run in the Realm before Linux:
+
+ * All protected RAM described to Linux (by DT or ACPI) must be marked
+ RIPAS RAM before handing control over to Linux.
+
+ * MMIO devices must be either unprotected (e.g. emulated by the Normal
+ World) or marked RIPAS DEV.
+
+ * MMIO devices emulated by the Normal World and used very early in boot
+ (specifically earlycon) must be specified in the upper half of IPA.
+ For earlycon this can be done by specifying the address on the
+ command line, e.g. with an IPA size of 33 bits and the base address
+ of the emulated UART at 0x1000000: ``earlycon=uart,mmio,0x101000000``
+
+ * Linux will use bounce buffers for communicating with unprotected
+ devices. It will transition some protected memory to RIPAS EMPTY and
+ expect to be able to access unprotected pages at the same IPA address
+ but with the highest valid IPA bit set. The expectation is that the
+ VMM will remove the physical pages from the protected mapping and
+ provide those pages as unprotected pages.
+
+References
+----------
+[1] https://developer.arm.com/documentation/den0137/
diff --git a/Documentation/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst
index 64a0b505da7d..57b8d7476f71 100644
--- a/Documentation/arm64/asymmetric-32bit.rst
+++ b/Documentation/arch/arm64/asymmetric-32bit.rst
@@ -55,7 +55,7 @@ sysfs
The subset of CPUs capable of running 32-bit tasks is described in
``/sys/devices/system/cpu/aarch32_el0`` and is documented further in
-``Documentation/ABI/testing/sysfs-devices-system-cpu``.
+Documentation/ABI/testing/sysfs-devices-system-cpu.
**Note:** CPUs are advertised by this file as they are detected and so
late-onlining of 32-bit-capable CPUs can result in the file contents
@@ -153,3 +153,11 @@ asymmetric system, a broken guest at EL1 could still attempt to execute
mode will return to host userspace with an ``exit_reason`` of
``KVM_EXIT_FAIL_ENTRY`` and will remain non-runnable until successfully
re-initialised by a subsequent ``KVM_ARM_VCPU_INIT`` operation.
+
+NOHZ FULL
+---------
+
+To avoid perturbing an adaptive-ticks CPU (specified using
+``nohz_full=``) when a 32-bit task is forcefully migrated, these CPUs
+are treated as 64-bit-only when support for asymmetric 32-bit systems
+is enabled.
diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
new file mode 100644
index 000000000000..26efca09aef3
--- /dev/null
+++ b/Documentation/arch/arm64/booting.rst
@@ -0,0 +1,608 @@
+=====================
+Booting AArch64 Linux
+=====================
+
+Author: Will Deacon <will.deacon@arm.com>
+
+Date : 07 September 2012
+
+This document is based on the ARM booting document by Russell King and
+is relevant to all public releases of the AArch64 Linux kernel.
+
+The AArch64 exception model is made up of a number of exception levels
+(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
+counterpart. EL2 is the hypervisor level, EL3 is the highest priority
+level and exists only in secure mode. Both are architecturally optional.
+
+For the purposes of this document, we will use the term `boot loader`
+simply to define all software that executes on the CPU(s) before control
+is passed to the Linux kernel. This may include secure monitor and
+hypervisor code, or it may just be a handful of instructions for
+preparing a minimal boot environment.
+
+Essentially, the boot loader should provide (as a minimum) the
+following:
+
+1. Setup and initialise the RAM
+2. Setup the device tree
+3. Decompress the kernel image
+4. Call the kernel image
+
+
+1. Setup and initialise RAM
+---------------------------
+
+Requirement: MANDATORY
+
+The boot loader is expected to find and initialise all RAM that the
+kernel will use for volatile data storage in the system. It performs
+this in a machine dependent manner. (It may use internal algorithms
+to automatically locate and size all RAM, or it may use knowledge of
+the RAM in the machine, or any other method the boot loader designer
+sees fit.)
+
+For Arm Confidential Compute Realms this includes ensuring that all
+protected RAM has a Realm IPA state (RIPAS) of "RAM".
+
+
+2. Setup the device tree
+-------------------------
+
+Requirement: MANDATORY
+
+The device tree blob (dtb) must be placed on an 8-byte boundary and must
+not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
+using blocks of up to 2 megabytes in size, it must not be placed within
+any 2M region which must be mapped with any specific attributes.
+
+NOTE: versions prior to v4.2 also require that the DTB be placed within
+the 512 MB region starting at text_offset bytes below the kernel Image.
+
+3. Decompress the kernel image
+------------------------------
+
+Requirement: OPTIONAL
+
+The AArch64 kernel does not currently provide a decompressor and
+therefore requires decompression (gzip etc.) to be performed by the boot
+loader if a compressed Image target (e.g. Image.gz) is used. For
+bootloaders that do not implement this requirement, the uncompressed
+Image target is available instead.
+
+
+4. Call the kernel image
+------------------------
+
+Requirement: MANDATORY
+
+The decompressed kernel image contains a 64-byte header as follows::
+
+ u32 code0; /* Executable code */
+ u32 code1; /* Executable code */
+ u64 text_offset; /* Image load offset, little endian */
+ u64 image_size; /* Effective Image size, little endian */
+ u64 flags; /* kernel flags, little endian */
+ u64 res2 = 0; /* reserved */
+ u64 res3 = 0; /* reserved */
+ u64 res4 = 0; /* reserved */
+ u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
+ u32 res5; /* reserved (used for PE COFF offset) */
+
+
+Header notes:
+
+- As of v3.17, all fields are little endian unless stated otherwise.
+
+- code0/code1 are responsible for branching to stext.
+
+- when booting through EFI, code0/code1 are initially skipped.
+ res5 is an offset to the PE header and the PE header has the EFI
+ entry point (efi_stub_entry). When the stub has done its work, it
+ jumps to code0 to resume the normal boot process.
+
+- Prior to v3.17, the endianness of text_offset was not specified. In
+ these cases image_size is zero and text_offset is 0x80000 in the
+ endianness of the kernel. Where image_size is non-zero image_size is
+ little-endian and must be respected. Where image_size is zero,
+ text_offset can be assumed to be 0x80000.
+
+- The flags field (introduced in v3.17) is a little-endian 64-bit field
+ composed as follows:
+
+ ============= ===============================================================
+ Bit 0 Kernel endianness. 1 if BE, 0 if LE.
+ Bit 1-2 Kernel Page size.
+
+ * 0 - Unspecified.
+ * 1 - 4K
+ * 2 - 16K
+ * 3 - 64K
+ Bit 3 Kernel physical placement
+
+ 0
+ 2MB aligned base should be as close as possible
+ to the base of DRAM, since memory below it is not
+ accessible via the linear mapping
+ 1
+ 2MB aligned base such that all image_size bytes
+ counted from the start of the image are within
+ the 48-bit addressable range of physical memory
+ Bits 4-63 Reserved.
+ ============= ===============================================================
+
+- When image_size is zero, a bootloader should attempt to keep as much
+ memory as possible free for use by the kernel immediately after the
+ end of the kernel image. The amount of space required will vary
+ depending on selected features, and is effectively unbound.
+
+The Image must be placed text_offset bytes from a 2MB aligned base
+address anywhere in usable system RAM and called there. The region
+between the 2 MB aligned base address and the start of the image has no
+special significance to the kernel, and may be used for other purposes.
+At least image_size bytes from the start of the image must be free for
+use by the kernel.
+NOTE: versions prior to v4.6 cannot make use of memory below the
+physical offset of the Image so it is recommended that the Image be
+placed as close as possible to the start of system RAM.
+
+If an initrd/initramfs is passed to the kernel at boot, it must reside
+entirely within a 1 GB aligned physical memory window of up to 32 GB in
+size that fully covers the kernel Image as well.
+
+Any memory described to the kernel (even that below the start of the
+image) which is not marked as reserved from the kernel (e.g., with a
+memreserve region in the device tree) will be considered as available to
+the kernel.
+
+Before jumping into the kernel, the following conditions must be met:
+
+- Quiesce all DMA capable devices so that memory does not get
+ corrupted by bogus network packets or disk data. This will save
+ you many hours of debug.
+
+- Primary CPU general-purpose register settings:
+
+ - x0 = physical address of device tree blob (dtb) in system RAM.
+ - x1 = 0 (reserved for future use)
+ - x2 = 0 (reserved for future use)
+ - x3 = 0 (reserved for future use)
+
+- CPU mode
+
+ All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
+ IRQ and FIQ).
+ The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order
+ to have access to the virtualisation extensions), or in EL1.
+
+- Caches, MMUs
+
+ The MMU must be off.
+
+ The instruction cache may be on or off, and must not hold any stale
+ entries corresponding to the loaded kernel image.
+
+ The address range corresponding to the loaded kernel image must be
+ cleaned to the PoC. In the presence of a system cache or other
+ coherent masters with caches enabled, this will typically require
+ cache maintenance by VA rather than set/way operations.
+ System caches which respect the architected cache maintenance by VA
+ operations must be configured and may be enabled.
+ System caches which do not respect architected cache maintenance by VA
+ operations (not recommended) must be configured and disabled.
+
+- Architected timers
+
+ CNTFRQ must be programmed with the timer frequency and CNTVOFF must
+ be programmed with a consistent value on all CPUs. If entering the
+ kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
+ available.
+
+- Coherency
+
+ All CPUs to be booted by the kernel must be part of the same coherency
+ domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
+ initialisation to enable the receiving of maintenance operations on
+ each CPU.
+
+- System registers
+
+ All writable architected system registers at or below the exception
+ level where the kernel image will be entered must be initialised by
+ software at a higher exception level to prevent execution in an UNKNOWN
+ state.
+
+ For all systems:
+ - If EL3 is present:
+
+ - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
+ executing on.
+ - The value of SCR_EL3.FIQ must be the same as the one present at boot
+ time whenever the kernel is executing.
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.HCE (bit 8) must be initialised to 0b1.
+
+ For systems with a GICv5 interrupt controller to be used in v5 mode:
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - ICH_HFGRTR_EL2.ICC_PPI_ACTIVERn_EL1 (bit 20) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_PPI_PRIORITYRn_EL1 (bit 19) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_PPI_PENDRn_EL1 (bit 18) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_PPI_ENABLERn_EL1 (bit 17) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_PPI_HMRn_EL1 (bit 16) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_IAFFIDR_EL1 (bit 7) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_ICSR_EL1 (bit 6) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_PCR_EL1 (bit 5) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_HPPIR_EL1 (bit 4) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_HAPR_EL1 (bit 3) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_CR0_EL1 (bit 2) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_IDRn_EL1 (bit 1) must be initialised to 0b1.
+ - ICH_HFGRTR_EL2.ICC_APR_EL1 (bit 0) must be initialised to 0b1.
+
+ - ICH_HFGWTR_EL2.ICC_PPI_ACTIVERn_EL1 (bit 20) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_PPI_PRIORITYRn_EL1 (bit 19) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_PPI_PENDRn_EL1 (bit 18) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_PPI_ENABLERn_EL1 (bit 17) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_ICSR_EL1 (bit 6) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_PCR_EL1 (bit 5) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_CR0_EL1 (bit 2) must be initialised to 0b1.
+ - ICH_HFGWTR_EL2.ICC_APR_EL1 (bit 0) must be initialised to 0b1.
+
+ - ICH_HFGITR_EL2.GICRCDNMIA (bit 10) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICRCDIA (bit 9) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDDI (bit 8) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDEOI (bit 7) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDHM (bit 6) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDRCFG (bit 5) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDPEND (bit 4) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDAFF (bit 3) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDPRI (bit 2) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDDIS (bit 1) must be initialised to 0b1.
+ - ICH_HFGITR_EL2.GICCDEN (bit 0) must be initialised to 0b1.
+
+ - The DT or ACPI tables must describe a GICv5 interrupt controller.
+
+ For systems with a GICv3 interrupt controller to be used in v3 mode:
+ - If EL3 is present:
+
+ - ICC_SRE_EL3.Enable (bit 3) must be initialised to 0b1.
+ - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
+ - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
+ all CPUs the kernel is executing on, and must stay constant
+ for the lifetime of the kernel.
+
+ - If the kernel is entered at EL1:
+
+ - ICC_SRE_EL2.Enable (bit 3) must be initialised to 0b1
+ - ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
+
+ - The DT or ACPI tables must describe a GICv3 interrupt controller.
+
+ For systems with a GICv3 interrupt controller to be used in
+ compatibility (v2) mode:
+
+ - If EL3 is present:
+
+ ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
+
+ - If the kernel is entered at EL1:
+
+ ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
+
+ - The DT or ACPI tables must describe a GICv2 interrupt controller.
+
+ For CPUs with pointer authentication functionality:
+
+ - If EL3 is present:
+
+ - SCR_EL3.APK (bit 16) must be initialised to 0b1
+ - SCR_EL3.API (bit 17) must be initialised to 0b1
+
+ - If the kernel is entered at EL1:
+
+ - HCR_EL2.APK (bit 40) must be initialised to 0b1
+ - HCR_EL2.API (bit 41) must be initialised to 0b1
+
+ For CPUs with Activity Monitors Unit v1 (AMUv1) extension present:
+
+ - If EL3 is present:
+
+ - CPTR_EL3.TAM (bit 30) must be initialised to 0b0
+ - CPTR_EL2.TAM (bit 30) must be initialised to 0b0
+ - AMCNTENSET0_EL0 must be initialised to 0b1111
+ - AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
+ - If the kernel is entered at EL1:
+
+ - AMCNTENSET0_EL0 must be initialised to 0b1111
+ - AMCNTENSET1_EL0 must be initialised to a platform specific value
+ having 0b1 set for the corresponding bit for each of the auxiliary
+ counters present.
+
+ For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
+
+ For CPUs with the Fine Grained Traps 2 (FEAT_FGT2) extension present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.FGTEn2 (bit 59) must be initialised to 0b1.
+
+ For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
+
+ - If EL3 is present and the kernel is entered at EL2:
+
+ - SCR_EL3.HXEn (bit 38) must be initialised to 0b1.
+
+ For CPUs with Advanced SIMD and floating point support:
+
+ - If EL3 is present:
+
+ - CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
+
+ - If EL2 is present and the kernel is entered at EL1:
+
+ - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
+
+ For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
+
+ - if EL3 is present:
+
+ - CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
+
+ - ZCR_EL3.LEN must be initialised to the same value for all CPUs the
+ kernel is executed on.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
+
+ - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
+
+ - ZCR_EL2.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ For CPUs with the Scalable Matrix Extension (FEAT_SME):
+
+ - If EL3 is present:
+
+ - CPTR_EL3.ESM (bit 12) must be initialised to 0b1.
+
+ - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1.
+
+ - SMCR_EL3.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - CPTR_EL2.TSM (bit 12) must be initialised to 0b0.
+
+ - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11.
+
+ - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1.
+
+ - SMCR_EL2.LEN must be initialised to the same value for all CPUs the
+ kernel will execute on.
+
+ - HFGRTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+ - HFGWTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+ - HFGRTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+ - HFGWTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+ For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
+
+ For CPUs with the Memory Tagging Extension feature (FEAT_MTE2):
+
+ - If EL3 is present:
+
+ - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
+
+ For CPUs with the Scalable Matrix Extension version 2 (FEAT_SME2):
+
+ - If EL3 is present:
+
+ - SMCR_EL3.EZT0 (bit 30) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1.
+
+ For CPUs with the Branch Record Buffer Extension (FEAT_BRBE):
+
+ - If EL3 is present:
+
+ - MDCR_EL3.SBRBE (bits 33:32) must be initialised to 0b01 or 0b11.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - BRBCR_EL2.CC (bit 3) must be initialised to 0b1.
+ - BRBCR_EL2.MPRED (bit 4) must be initialised to 0b1.
+
+ - HDFGRTR_EL2.nBRBDATA (bit 61) must be initialised to 0b1.
+ - HDFGRTR_EL2.nBRBCTL (bit 60) must be initialised to 0b1.
+ - HDFGRTR_EL2.nBRBIDR (bit 59) must be initialised to 0b1.
+
+ - HDFGWTR_EL2.nBRBDATA (bit 61) must be initialised to 0b1.
+ - HDFGWTR_EL2.nBRBCTL (bit 60) must be initialised to 0b1.
+
+ - HFGITR_EL2.nBRBIALL (bit 56) must be initialised to 0b1.
+ - HFGITR_EL2.nBRBINJ (bit 55) must be initialised to 0b1.
+
+ For CPUs with the Performance Monitors Extension (FEAT_PMUv3p9):
+
+ - If EL3 is present:
+
+ - MDCR_EL3.EnPM2 (bit 7) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HDFGRTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1.
+ - HDFGRTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1.
+ - HDFGRTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1.
+
+ - HDFGWTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1.
+ - HDFGWTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1.
+ - HDFGWTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1.
+
+ For CPUs with SPE data source filtering (FEAT_SPE_FDS):
+
+ - If EL3 is present:
+
+ - MDCR_EL3.EnPMS3 (bit 42) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HDFGRTR2_EL2.nPMSDSFR_EL1 (bit 19) must be initialised to 0b1.
+ - HDFGWTR2_EL2.nPMSDSFR_EL1 (bit 19) must be initialised to 0b1.
+
+ For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS):
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1.
+
+ - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b1 and the hypervisor
+ must handle MOPS exceptions as described in :ref:`arm64_mops_hyp`.
+
+ For CPUs with the Extended Translation Control Register feature (FEAT_TCR2):
+
+ - If EL3 is present:
+
+ - SCR_EL3.TCR2En (bit 43) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCRX_EL2.TCR2En (bit 14) must be initialised to 0b1.
+
+ For CPUs with the Stage 1 Permission Indirection Extension feature (FEAT_S1PIE):
+
+ - If EL3 is present:
+
+ - SCR_EL3.PIEn (bit 45) must be initialised to 0b1.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HFGRTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1.
+
+ - HFGWTR_EL2.nPIR_EL1 (bit 58) must be initialised to 0b1.
+
+ - HFGRTR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1.
+
+ - HFGRWR_EL2.nPIRE0_EL1 (bit 57) must be initialised to 0b1.
+
+ - For CPUs with Guarded Control Stacks (FEAT_GCS):
+
+ - GCSCR_EL1 must be initialised to 0.
+
+ - GCSCRE0_EL1 must be initialised to 0.
+
+ - If EL3 is present:
+
+ - SCR_EL3.GCSEn (bit 39) must be initialised to 0b1.
+
+ - If EL2 is present:
+
+ - GCSCR_EL2 must be initialised to 0.
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+ - HCRX_EL2.GCSEn must be initialised to 0b1.
+
+ - HFGITR_EL2.nGCSEPP (bit 59) must be initialised to 0b1.
+
+ - HFGITR_EL2.nGCSSTR_EL1 (bit 58) must be initialised to 0b1.
+
+ - HFGITR_EL2.nGCSPUSHM_EL1 (bit 57) must be initialised to 0b1.
+
+ - HFGRTR_EL2.nGCS_EL1 (bit 53) must be initialised to 0b1.
+
+ - HFGRTR_EL2.nGCS_EL0 (bit 52) must be initialised to 0b1.
+
+ - HFGWTR_EL2.nGCS_EL1 (bit 53) must be initialised to 0b1.
+
+ - HFGWTR_EL2.nGCS_EL0 (bit 52) must be initialised to 0b1.
+
+ - For CPUs with debug architecture i.e FEAT_Debugv8pN (all versions):
+
+ - If EL3 is present:
+
+ - MDCR_EL3.TDA (bit 9) must be initialized to 0b0
+
+ - For CPUs with FEAT_PMUv3:
+
+ - If EL3 is present:
+
+ - MDCR_EL3.TPM (bit 6) must be initialized to 0b0
+
+The requirements described above for CPU mode, caches, MMUs, architected
+timers, coherency and system registers apply to all CPUs. All CPUs must
+enter the kernel in the same exception level. Where the values documented
+disable traps it is permissible for these traps to be enabled so long as
+those traps are handled transparently by higher exception levels as though
+the values documented were set.
+
+The boot loader is expected to enter the kernel on each CPU in the
+following manner:
+
+- The primary CPU must jump directly to the first instruction of the
+ kernel image. The device tree blob passed by this CPU must contain
+ an 'enable-method' property for each cpu node. The supported
+ enable-methods are described below.
+
+ It is expected that the bootloader will generate these device tree
+ properties and insert them into the blob prior to kernel entry.
+
+- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
+ property in their cpu node. This property identifies a
+ naturally-aligned 64-bit zero-initalised memory location.
+
+ These CPUs should spin outside of the kernel in a reserved area of
+ memory (communicated to the kernel by a /memreserve/ region in the
+ device tree) polling their cpu-release-addr location, which must be
+ contained in the reserved region. A wfe instruction may be inserted
+ to reduce the overhead of the busy-loop and a sev will be issued by
+ the primary CPU. When a read of the location pointed to by the
+ cpu-release-addr returns a non-zero value, the CPU must jump to this
+ value. The value will be written as a single 64-bit little-endian
+ value, so CPUs must convert the read value to their native endianness
+ before jumping to it.
+
+- CPUs with a "psci" enable method should remain outside of
+ the kernel (i.e. outside of the regions of memory described to the
+ kernel in the memory node, or in a reserved area of memory described
+ to the kernel by a /memreserve/ region in the device tree). The
+ kernel will issue CPU_ON calls as described in ARM document number ARM
+ DEN 0022A ("Power State Coordination Interface System Software on ARM
+ processors") to bring CPUs into the kernel.
+
+ The device tree should contain a 'psci' node, as described in
+ Documentation/devicetree/bindings/arm/psci.yaml.
+
+- Secondary CPU general-purpose register settings
+
+ - x0 = 0 (reserved for future use)
+ - x1 = 0 (reserved for future use)
+ - x2 = 0 (reserved for future use)
+ - x3 = 0 (reserved for future use)
diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arch/arm64/cpu-feature-registers.rst
index 04ba83e1965f..add66afc7b03 100644
--- a/Documentation/arm64/cpu-feature-registers.rst
+++ b/Documentation/arch/arm64/cpu-feature-registers.rst
@@ -72,14 +72,15 @@ there are some issues with their usage.
process could be migrated to another CPU by the time it uses the
register value, unless the CPU affinity is set. Hence, there is no
guarantee that the value reflects the processor that it is
- currently executing on. The REVIDR is not exposed due to this
- constraint, as REVIDR makes sense only in conjunction with the
- MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
- at::
+ currently executing on. REVIDR and AIDR are not exposed due to this
+ constraint, as these registers only make sense in conjunction with
+ the MIDR. Alternately, MIDR_EL1, REVIDR_EL1, and AIDR_EL1 are exposed
+ via sysfs at::
/sys/devices/system/cpu/cpu$ID/regs/identification/
- \- midr
- \- revidr
+ \- midr_el1
+ \- revidr_el1
+ \- aidr_el1
3. Implementation
--------------------
@@ -92,7 +93,7 @@ operation if the source belongs to the supported system register space.
The infrastructure emulates only the following system register space::
- Op0=3, Op1=0, CRn=0, CRm=0,4,5,6,7
+ Op0=3, Op1=0, CRn=0, CRm=0,2,3,4,5,6,7
(See Table C5-6 'System instruction encodings for non-Debug System
register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
@@ -152,6 +153,8 @@ infrastructure:
+------------------------------+---------+---------+
| DIT | [51-48] | y |
+------------------------------+---------+---------+
+ | MPAM | [43-40] | n |
+ +------------------------------+---------+---------+
| SVE | [35-32] | y |
+------------------------------+---------+---------+
| GIC | [27-24] | n |
@@ -175,6 +178,8 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
+ | SME | [27-24] | y |
+ +------------------------------+---------+---------+
| MTE | [11-8] | y |
+------------------------------+---------+---------+
| SSBS | [7-4] | y |
@@ -266,6 +271,8 @@ infrastructure:
+------------------------------+---------+---------+
| SHA3 | [35-32] | y |
+------------------------------+---------+---------+
+ | B16B16 | [27-24] | y |
+ +------------------------------+---------+---------+
| BF16 | [23-20] | y |
+------------------------------+---------+---------+
| BitPerm | [19-16] | y |
@@ -288,11 +295,59 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
+ | CSSC | [55-52] | y |
+ +------------------------------+---------+---------+
+ | RPRFM | [51-48] | y |
+ +------------------------------+---------+---------+
+ | BC | [23-20] | y |
+ +------------------------------+---------+---------+
+ | MOPS | [19-16] | y |
+ +------------------------------+---------+---------+
+ | APA3 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | GPA3 | [11-8] | y |
+ +------------------------------+---------+---------+
| RPRES | [7-4] | y |
+------------------------------+---------+---------+
| WFXT | [3-0] | y |
+------------------------------+---------+---------+
+ 10) MVFR0_EL1 - AArch32 Media and VFP Feature Register 0
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | FPDP | [11-8] | y |
+ +------------------------------+---------+---------+
+
+ 11) MVFR1_EL1 - AArch32 Media and VFP Feature Register 1
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | SIMDFMAC | [31-28] | y |
+ +------------------------------+---------+---------+
+ | SIMDSP | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SIMDInt | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SIMDLS | [11-8] | y |
+ +------------------------------+---------+---------+
+
+ 12) ID_ISAR5_EL1 - AArch32 Instruction Set Attribute Register 5
+
+ +------------------------------+---------+---------+
+ | Name | bits | visible |
+ +------------------------------+---------+---------+
+ | CRC32 | [19-16] | y |
+ +------------------------------+---------+---------+
+ | SHA2 | [15-12] | y |
+ +------------------------------+---------+---------+
+ | SHA1 | [11-8] | y |
+ +------------------------------+---------+---------+
+ | AES | [7-4] | y |
+ +------------------------------+---------+---------+
+
Appendix I: Example
-------------------
diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
new file mode 100644
index 000000000000..8fb438bf7781
--- /dev/null
+++ b/Documentation/arch/arm64/cpu-hotplug.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _cpuhp_index:
+
+====================
+CPU Hotplug and ACPI
+====================
+
+CPU hotplug in the arm64 world is commonly used to describe the kernel taking
+CPUs online/offline using PSCI. This document is about ACPI firmware allowing
+CPUs that were not available during boot to be added to the system later.
+
+``possible`` and ``present`` refer to the state of the CPU as seen by linux.
+
+
+CPU Hotplug on physical systems - CPUs not present at boot
+----------------------------------------------------------
+
+Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
+being ``present``. An example would be a dual socket machine, where the package
+in one of the sockets can be replaced while the system is running.
+
+This is not supported.
+
+In the arm64 world CPUs are not a single device but a slice of the system.
+There are no systems that support the physical addition (or removal) of CPUs
+while the system is running, and ACPI is not able to sufficiently describe
+them.
+
+e.g. New CPUs come with new caches, but the platform's cache topology is
+described in a static table, the PPTT. How caches are shared between CPUs is
+not discoverable, and must be described by firmware.
+
+e.g. The GIC redistributor for each CPU must be accessed by the driver during
+boot to discover the system wide supported features. ACPI's MADT GICC
+structures can describe a redistributor associated with a disabled CPU, but
+can't describe whether the redistributor is accessible, only that it is not
+'always on'.
+
+arm64's ACPI tables assume that everything described is ``present``.
+
+
+CPU Hotplug on virtual systems - CPUs not enabled at boot
+---------------------------------------------------------
+
+Virtual systems have the advantage that all the properties the system will
+ever have can be described at boot. There are no power-domain considerations
+as such devices are emulated.
+
+CPU Hotplug on virtual systems is supported. It is distinct from physical
+CPU Hotplug as all resources are described as ``present``, but CPUs may be
+marked as disabled by firmware. Only the CPU's online/offline behaviour is
+influenced by firmware. An example is where a virtual machine boots with a
+single CPU, and additional CPUs are added once a cloud orchestrator deploys
+the workload.
+
+For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.
+
+Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
+brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
+``DENIED``.
+
+The ACPI tables must describe all the resources of the virtual machine. CPUs
+that firmware wishes to disable either from boot (or later) should not be
+``enabled`` in the MADT GICC structures, but should have the ``online capable``
+bit set, to indicate they can be enabled later. The boot CPU must be marked as
+``enabled``. The 'always on' GICR structure must be used to describe the
+redistributors.
+
+CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
+by the DSDT's Processor object's _STA method. On virtual systems the _STA method
+must always report the CPU as ``present``. Changes to the firmware policy can
+be notified to the OS via device-check or eject-request.
+
+CPUs described as ``enabled`` in the static table, should not have their _STA
+modified dynamically by firmware. Soft-restart features such as kexec will
+re-read the static properties of the system from these static tables, and
+may malfunction if these no longer describe the running system. Linux will
+re-discover the dynamic properties of the system from the _STA method later
+during boot.
diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
new file mode 100644
index 000000000000..a15df4956849
--- /dev/null
+++ b/Documentation/arch/arm64/elf_hwcaps.rst
@@ -0,0 +1,452 @@
+.. _elf_hwcaps_index:
+
+================
+ARM64 ELF hwcaps
+================
+
+This document describes the usage and semantics of the arm64 ELF hwcaps.
+
+
+1. Introduction
+---------------
+
+Some hardware or software features are only available on some CPU
+implementations, and/or with certain kernel configurations, but have no
+architected discovery mechanism available to userspace code at EL0. The
+kernel exposes the presence of these features to userspace through a set
+of flags called hwcaps, exposed in the auxiliary vector.
+
+Userspace software can test for features by acquiring the AT_HWCAP,
+AT_HWCAP2 or AT_HWCAP3 entry of the auxiliary vector, and testing
+whether the relevant flags are set, e.g.::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long hwcaps = getauxval(AT_HWCAP);
+ if (hwcaps & HWCAP_FP)
+ return true;
+
+ return false;
+ }
+
+Where software relies on a feature described by a hwcap, it should check
+the relevant hwcap flag to verify that the feature is present before
+attempting to make use of the feature.
+
+Features cannot be probed reliably through other means. When a feature
+is not available, attempting to use it may result in unpredictable
+behaviour, and is not guaranteed to result in any reliable indication
+that the feature is unavailable, such as a SIGILL.
+
+
+2. Interpretation of hwcaps
+---------------------------
+
+The majority of hwcaps are intended to indicate the presence of features
+which are described by architected ID registers inaccessible to
+userspace code at EL0. These hwcaps are defined in terms of ID register
+fields, and should be interpreted with reference to the definition of
+these fields in the ARM Architecture Reference Manual (ARM ARM).
+
+Such hwcaps are described below in the form::
+
+ Functionality implied by idreg.field == val.
+
+Such hwcaps indicate the availability of functionality that the ARM ARM
+defines as being present when idreg.field has value val, but do not
+indicate that idreg.field is precisely equal to val, nor do they
+indicate the absence of functionality implied by other values of
+idreg.field.
+
+Other hwcaps may indicate the presence of features which cannot be
+described by ID registers alone. These may be described without
+reference to ID registers, and may refer to other documentation.
+
+
+3. The hwcaps exposed in AT_HWCAP
+---------------------------------
+
+HWCAP_FP
+ Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
+
+HWCAP_ASIMD
+ Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
+
+HWCAP_EVTSTRM
+ The generic timer is configured to generate events at a frequency of
+ approximately 10KHz.
+
+HWCAP_AES
+ Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
+
+HWCAP_PMULL
+ Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
+
+HWCAP_SHA1
+ Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
+
+HWCAP_SHA2
+ Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
+
+HWCAP_CRC32
+ Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
+
+HWCAP_ATOMICS
+ Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
+
+HWCAP_FPHP
+ Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
+
+HWCAP_ASIMDHP
+ Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
+
+HWCAP_CPUID
+ EL0 access to certain ID registers is available, to the extent
+ described by Documentation/arch/arm64/cpu-feature-registers.rst.
+
+ These ID registers may imply the availability of features.
+
+HWCAP_ASIMDRDM
+ Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
+
+HWCAP_JSCVT
+ Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
+
+HWCAP_FCMA
+ Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
+
+HWCAP_LRCPC
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
+
+HWCAP_DCPOP
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
+
+HWCAP_SHA3
+ Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
+
+HWCAP_SM3
+ Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
+
+HWCAP_SM4
+ Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
+
+HWCAP_ASIMDDP
+ Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
+
+HWCAP_SHA512
+ Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
+
+HWCAP_SVE
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_ASIMDFHM
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
+
+HWCAP_DIT
+ Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
+
+HWCAP_USCAT
+ Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
+
+HWCAP_ILRCPC
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
+
+HWCAP_FLAGM
+ Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
+
+HWCAP_SSBS
+ Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
+
+HWCAP_SB
+ Functionality implied by ID_AA64ISAR1_EL1.SB == 0b0001.
+
+HWCAP_PACA
+ Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
+ ID_AA64ISAR1_EL1.API == 0b0001, as described by
+ Documentation/arch/arm64/pointer-authentication.rst.
+
+HWCAP_PACG
+ Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
+ ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
+ Documentation/arch/arm64/pointer-authentication.rst.
+
+HWCAP_GCS
+ Functionality implied by ID_AA64PFR1_EL1.GCS == 0b1, as
+ described by Documentation/arch/arm64/gcs.rst.
+
+HWCAP_CMPBR
+ Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0010.
+
+HWCAP_FPRCVT
+ Functionality implied by ID_AA64ISAR3_EL1.FPRCVT == 0b0001.
+
+HWCAP_F8MM8
+ Functionality implied by ID_AA64FPFR0_EL1.F8MM8 == 0b0001.
+
+HWCAP_F8MM4
+ Functionality implied by ID_AA64FPFR0_EL1.F8MM4 == 0b0001.
+
+HWCAP_SVE_F16MM
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.F16MM == 0b0001.
+
+HWCAP_SVE_ELTPERM
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.ELTPERM == 0b0001.
+
+HWCAP_SVE_AES2
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.AES == 0b0011.
+
+HWCAP_SVE_BFSCALE
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.B16B16 == 0b0010.
+
+HWCAP_SVE2P2
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.SVEver == 0b0011.
+
+HWCAP_SME2P2
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0011.
+
+HWCAP_SME_SBITPERM
+ Functionality implied by ID_AA64SMFR0_EL1.SBitPerm == 0b1.
+
+HWCAP_SME_AES
+ Functionality implied by ID_AA64SMFR0_EL1.AES == 0b1.
+
+HWCAP_SME_SFEXPA
+ Functionality implied by ID_AA64SMFR0_EL1.SFEXPA == 0b1.
+
+HWCAP_SME_STMOP
+ Functionality implied by ID_AA64SMFR0_EL1.STMOP == 0b1.
+
+HWCAP_SME_SMOP4
+ Functionality implied by ID_AA64SMFR0_EL1.SMOP4 == 0b1.
+
+HWCAP2_DCPODP
+ Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
+
+HWCAP2_SVE2
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.SVEver == 0b0001.
+
+HWCAP2_SVEAES
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.AES == 0b0001.
+
+HWCAP2_SVEPMULL
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.AES == 0b0010.
+
+HWCAP2_SVEBITPERM
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.BitPerm == 0b0001.
+
+HWCAP2_SVESHA3
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.SHA3 == 0b0001.
+
+HWCAP2_SVESM4
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.SM4 == 0b0001.
+
+HWCAP2_FLAGM2
+ Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
+
+HWCAP2_FRINT
+ Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
+
+HWCAP2_SVEI8MM
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.I8MM == 0b0001.
+
+HWCAP2_SVEF32MM
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.F32MM == 0b0001.
+
+HWCAP2_SVEF64MM
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.F64MM == 0b0001.
+
+HWCAP2_SVEBF16
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.BF16 == 0b0001.
+
+HWCAP2_I8MM
+ Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
+
+HWCAP2_BF16
+ Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
+
+HWCAP2_DGH
+ Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
+
+HWCAP2_RNG
+ Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
+
+HWCAP2_BTI
+ Functionality implied by ID_AA64PFR1_EL1.BT == 0b0001.
+
+HWCAP2_MTE
+ Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
+ by Documentation/arch/arm64/memory-tagging-extension.rst.
+
+HWCAP2_ECV
+ Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
+
+HWCAP2_AFP
+ Functionality implied by ID_AA64MMFR1_EL1.AFP == 0b0001.
+
+HWCAP2_RPRES
+ Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
+
+HWCAP2_MTE3
+ Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
+ by Documentation/arch/arm64/memory-tagging-extension.rst.
+
+HWCAP2_SME
+ Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
+ by Documentation/arch/arm64/sme.rst.
+
+HWCAP2_SME_I16I64
+ Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
+
+HWCAP2_SME_F64F64
+ Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
+
+HWCAP2_SME_I8I32
+ Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
+
+HWCAP2_SME_F16F32
+ Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
+
+HWCAP2_SME_B16F32
+ Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
+
+HWCAP2_SME_F32F32
+ Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
+
+HWCAP2_SME_FA64
+ Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
+
+HWCAP2_WFXT
+ Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
+
+HWCAP2_EBF16
+ Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
+
+HWCAP2_SVE_EBF16
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.BF16 == 0b0010.
+
+HWCAP2_CSSC
+ Functionality implied by ID_AA64ISAR2_EL1.CSSC == 0b0001.
+
+HWCAP2_RPRFM
+ Functionality implied by ID_AA64ISAR2_EL1.RPRFM == 0b0001.
+
+HWCAP2_SVE2P1
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.SVEver == 0b0010.
+
+HWCAP2_SME2
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0001.
+
+HWCAP2_SME2P1
+ Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0010.
+
+HWCAP2_SMEI16I32
+ Functionality implied by ID_AA64SMFR0_EL1.I16I32 == 0b0101
+
+HWCAP2_SMEBI32I32
+ Functionality implied by ID_AA64SMFR0_EL1.BI32I32 == 0b1
+
+HWCAP2_SMEB16B16
+ Functionality implied by ID_AA64SMFR0_EL1.B16B16 == 0b1
+
+HWCAP2_SMEF16F16
+ Functionality implied by ID_AA64SMFR0_EL1.F16F16 == 0b1
+
+HWCAP2_MOPS
+ Functionality implied by ID_AA64ISAR2_EL1.MOPS == 0b0001.
+
+HWCAP2_HBC
+ Functionality implied by ID_AA64ISAR2_EL1.BC == 0b0001.
+
+HWCAP2_SVE_B16B16
+ Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
+ ID_AA64ZFR0_EL1.B16B16 == 0b0001.
+
+HWCAP2_LRCPC3
+ Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0011.
+
+HWCAP2_LSE128
+ Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0011.
+
+HWCAP2_FPMR
+ Functionality implied by ID_AA64PFR2_EL1.FMR == 0b0001.
+
+HWCAP2_LUT
+ Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0001.
+
+HWCAP2_FAMINMAX
+ Functionality implied by ID_AA64ISAR3_EL1.FAMINMAX == 0b0001.
+
+HWCAP2_F8CVT
+ Functionality implied by ID_AA64FPFR0_EL1.F8CVT == 0b1.
+
+HWCAP2_F8FMA
+ Functionality implied by ID_AA64FPFR0_EL1.F8FMA == 0b1.
+
+HWCAP2_F8DP4
+ Functionality implied by ID_AA64FPFR0_EL1.F8DP4 == 0b1.
+
+HWCAP2_F8DP2
+ Functionality implied by ID_AA64FPFR0_EL1.F8DP2 == 0b1.
+
+HWCAP2_F8E4M3
+ Functionality implied by ID_AA64FPFR0_EL1.F8E4M3 == 0b1.
+
+HWCAP2_F8E5M2
+ Functionality implied by ID_AA64FPFR0_EL1.F8E5M2 == 0b1.
+
+HWCAP2_SME_LUTV2
+ Functionality implied by ID_AA64SMFR0_EL1.LUTv2 == 0b1.
+
+HWCAP2_SME_F8F16
+ Functionality implied by ID_AA64SMFR0_EL1.F8F16 == 0b1.
+
+HWCAP2_SME_F8F32
+ Functionality implied by ID_AA64SMFR0_EL1.F8F32 == 0b1.
+
+HWCAP2_SME_SF8FMA
+ Functionality implied by ID_AA64SMFR0_EL1.SF8FMA == 0b1.
+
+HWCAP2_SME_SF8DP4
+ Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
+
+HWCAP2_SME_SF8DP2
+ Functionality implied by ID_AA64SMFR0_EL1.SF8DP2 == 0b1.
+
+HWCAP2_SME_SF8DP4
+ Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
+
+HWCAP2_POE
+ Functionality implied by ID_AA64MMFR3_EL1.S1POE == 0b0001.
+
+HWCAP3_MTE_FAR
+ Functionality implied by ID_AA64PFR2_EL1.MTEFAR == 0b0001.
+
+HWCAP3_MTE_STORE_ONLY
+ Functionality implied by ID_AA64PFR2_EL1.MTESTOREONLY == 0b0001.
+
+HWCAP3_LSFE
+ Functionality implied by ID_AA64ISAR3_EL1.LSFE == 0b0001
+
+
+4. Unused AT_HWCAP bits
+-----------------------
+
+For interoperation with userspace, the kernel guarantees that bits 62
+and 63 of AT_HWCAP will always be returned as 0.
diff --git a/Documentation/arch/arm64/features.rst b/Documentation/arch/arm64/features.rst
new file mode 100644
index 000000000000..03321f4309d0
--- /dev/null
+++ b/Documentation/arch/arm64/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features arm64
diff --git a/Documentation/arch/arm64/gcs.rst b/Documentation/arch/arm64/gcs.rst
new file mode 100644
index 000000000000..226c0b008456
--- /dev/null
+++ b/Documentation/arch/arm64/gcs.rst
@@ -0,0 +1,227 @@
+===============================================
+Guarded Control Stack support for AArch64 Linux
+===============================================
+
+This document outlines briefly the interface provided to userspace by Linux in
+order to support use of the ARM Guarded Control Stack (GCS) feature.
+
+This is an outline of the most important features and issues only and not
+intended to be exhaustive.
+
+
+
+1. General
+-----------
+
+* GCS is an architecture feature intended to provide greater protection
+ against return oriented programming (ROP) attacks and to simplify the
+ implementation of features that need to collect stack traces such as
+ profiling.
+
+* When GCS is enabled a separate guarded control stack is maintained by the
+ PE which is writeable only through specific GCS operations. This
+ stores the call stack only, when a procedure call instruction is
+ performed the current PC is pushed onto the GCS and on RET the
+ address in the LR is verified against that on the top of the GCS.
+
+* When active the current GCS pointer is stored in the system register
+ GCSPR_EL0. This is readable by userspace but can only be updated
+ via specific GCS instructions.
+
+* The architecture provides instructions for switching between guarded
+ control stacks with checks to ensure that the new stack is a valid
+ target for switching.
+
+* The functionality of GCS is similar to that provided by the x86 Shadow
+ Stack feature, due to sharing of userspace interfaces the ABI refers to
+ shadow stacks rather than GCS.
+
+* Support for GCS is reported to userspace via HWCAP_GCS in the aux vector
+ AT_HWCAP entry.
+
+* GCS is enabled per thread. While there is support for disabling GCS
+ at runtime this should be done with great care.
+
+* GCS memory access faults are reported as normal memory access faults.
+
+* GCS specific errors (those reported with EC 0x2d) will be reported as
+ SIGSEGV with a si_code of SEGV_CPERR (control protection error).
+
+* GCS is supported only for AArch64.
+
+* On systems where GCS is supported GCSPR_EL0 is always readable by EL0
+ regardless of the GCS configuration for the thread.
+
+* The architecture supports enabling GCS without verifying that return values
+ in LR match those in the GCS, the LR will be ignored. This is not supported
+ by Linux.
+
+
+
+2. Enabling and disabling Guarded Control Stacks
+-------------------------------------------------
+
+* GCS is enabled and disabled for a thread via the PR_SET_SHADOW_STACK_STATUS
+ prctl(), this takes a single flags argument specifying which GCS features
+ should be used.
+
+* When set PR_SHADOW_STACK_ENABLE flag allocates a Guarded Control Stack
+ and enables GCS for the thread, enabling the functionality controlled by
+ GCSCRE0_EL1.{nTR, RVCHKEN, PCRSEL}.
+
+* When set the PR_SHADOW_STACK_PUSH flag enables the functionality controlled
+ by GCSCRE0_EL1.PUSHMEn, allowing explicit GCS pushes.
+
+* When set the PR_SHADOW_STACK_WRITE flag enables the functionality controlled
+ by GCSCRE0_EL1.STREn, allowing explicit stores to the Guarded Control Stack.
+
+* Any unknown flags will cause PR_SET_SHADOW_STACK_STATUS to return -EINVAL.
+
+* PR_LOCK_SHADOW_STACK_STATUS is passed a bitmask of features with the same
+ values as used for PR_SET_SHADOW_STACK_STATUS. Any future changes to the
+ status of the specified GCS mode bits will be rejected.
+
+* PR_LOCK_SHADOW_STACK_STATUS allows any bit to be locked, this allows
+ userspace to prevent changes to any future features.
+
+* There is no support for a process to remove a lock that has been set for
+ it.
+
+* PR_SET_SHADOW_STACK_STATUS and PR_LOCK_SHADOW_STACK_STATUS affect only the
+ thread that called them, any other running threads will be unaffected.
+
+* New threads inherit the GCS configuration of the thread that created them.
+
+* GCS is disabled on exec().
+
+* The current GCS configuration for a thread may be read with the
+ PR_GET_SHADOW_STACK_STATUS prctl(), this returns the same flags that
+ are passed to PR_SET_SHADOW_STACK_STATUS.
+
+* If GCS is disabled for a thread after having previously been enabled then
+ the stack will remain allocated for the lifetime of the thread. At present
+ any attempt to reenable GCS for the thread will be rejected, this may be
+ revisited in future.
+
+* It should be noted that since enabling GCS will result in GCS becoming
+ active immediately it is not normally possible to return from the function
+ that invoked the prctl() that enabled GCS. It is expected that the normal
+ usage will be that GCS is enabled very early in execution of a program.
+
+
+
+3. Allocation of Guarded Control Stacks
+----------------------------------------
+
+* When GCS is enabled for a thread a new Guarded Control Stack will be
+ allocated for it of half the standard stack size or 2 gigabytes,
+ whichever is smaller.
+
+* When a new thread is created by a thread which has GCS enabled then a
+ new Guarded Control Stack will be allocated for the new thread with
+ half the size of the standard stack.
+
+* When a stack is allocated by enabling GCS or during thread creation then
+ the top 8 bytes of the stack will be initialised to 0 and GCSPR_EL0 will
+ be set to point to the address of this 0 value, this can be used to
+ detect the top of the stack.
+
+* Additional Guarded Control Stacks can be allocated using the
+ map_shadow_stack() system call.
+
+* Stacks allocated using map_shadow_stack() can optionally have an end of
+ stack marker and cap placed at the top of the stack. If the flag
+ SHADOW_STACK_SET_TOKEN is specified a cap will be placed on the stack,
+ if SHADOW_STACK_SET_MARKER is not specified the cap will be the top 8
+ bytes of the stack and if it is specified then the cap will be the next
+ 8 bytes. While specifying just SHADOW_STACK_SET_MARKER by itself is
+ valid since the marker is all bits 0 it has no observable effect.
+
+* Stacks allocated using map_shadow_stack() must have a size which is a
+ multiple of 8 bytes larger than 8 bytes and must be 8 bytes aligned.
+
+* An address can be specified to map_shadow_stack(), if one is provided then
+ it must be aligned to a page boundary.
+
+* When a thread is freed the Guarded Control Stack initially allocated for
+ that thread will be freed. Note carefully that if the stack has been
+ switched this may not be the stack currently in use by the thread.
+
+
+4. Signal handling
+--------------------
+
+* A new signal frame record gcs_context encodes the current GCS mode and
+ pointer for the interrupted context on signal delivery. This will always
+ be present on systems that support GCS.
+
+* The record contains a flag field which reports the current GCS configuration
+ for the interrupted context as PR_GET_SHADOW_STACK_STATUS would.
+
+* The signal handler is run with the same GCS configuration as the interrupted
+ context.
+
+* When GCS is enabled for the interrupted thread a signal handling specific
+ GCS cap token will be written to the GCS, this is an architectural GCS cap
+ with the token type (bits 0..11) all clear. The GCSPR_EL0 reported in the
+ signal frame will point to this cap token.
+
+* The signal handler will use the same GCS as the interrupted context.
+
+* When GCS is enabled on signal entry a frame with the address of the signal
+ return handler will be pushed onto the GCS, allowing return from the signal
+ handler via RET as normal. This will not be reported in the gcs_context in
+ the signal frame.
+
+
+5. Signal return
+-----------------
+
+When returning from a signal handler:
+
+* If there is a gcs_context record in the signal frame then the GCS flags
+ and GCSPR_EL0 will be restored from that context prior to further
+ validation.
+
+* If there is no gcs_context record in the signal frame then the GCS
+ configuration will be unchanged.
+
+* If GCS is enabled on return from a signal handler then GCSPR_EL0 must
+ point to a valid GCS signal cap record, this will be popped from the
+ GCS prior to signal return.
+
+* If the GCS configuration is locked when returning from a signal then any
+ attempt to change the GCS configuration will be treated as an error. This
+ is true even if GCS was not enabled prior to signal entry.
+
+* GCS may be disabled via signal return but any attempt to enable GCS via
+ signal return will be rejected.
+
+
+6. ptrace extensions
+---------------------
+
+* A new regset NT_ARM_GCS is defined for use with PTRACE_GETREGSET and
+ PTRACE_SETREGSET.
+
+* The GCS mode, including enable and disable, may be configured via ptrace.
+ If GCS is enabled via ptrace no new GCS will be allocated for the thread.
+
+* Configuration via ptrace ignores locking of GCS mode bits.
+
+
+7. ELF coredump extensions
+---------------------------
+
+* NT_ARM_GCS notes will be added to each coredump for each thread of the
+ dumped process. The contents will be equivalent to the data that would
+ have been read if a PTRACE_GETREGSET of the corresponding type were
+ executed for each thread when the coredump was generated.
+
+
+
+8. /proc extensions
+--------------------
+
+* Guarded Control Stack pages will include "ss" in their VmFlags in
+ /proc/<pid>/smaps.
diff --git a/Documentation/arm64/hugetlbpage.rst b/Documentation/arch/arm64/hugetlbpage.rst
index a110124c11e3..a110124c11e3 100644
--- a/Documentation/arm64/hugetlbpage.rst
+++ b/Documentation/arch/arm64/hugetlbpage.rst
diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
new file mode 100644
index 000000000000..6a012c98bdcd
--- /dev/null
+++ b/Documentation/arch/arm64/index.rst
@@ -0,0 +1,42 @@
+.. _arm64_index:
+
+==================
+ARM64 Architecture
+==================
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi_object_usage
+ amu
+ arm-acpi
+ arm-cca
+ asymmetric-32bit
+ booting
+ cpu-feature-registers
+ cpu-hotplug
+ elf_hwcaps
+ gcs
+ hugetlbpage
+ kdump
+ legacy_instructions
+ memory
+ memory-tagging-extension
+ mops
+ perf
+ pointer-authentication
+ ptdump
+ silicon-errata
+ sme
+ sve
+ tagged-address-abi
+ tagged-pointers
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arch/arm64/kasan-offsets.sh
index 2dc5f9e18039..2dc5f9e18039 100644
--- a/Documentation/arm64/kasan-offsets.sh
+++ b/Documentation/arch/arm64/kasan-offsets.sh
diff --git a/Documentation/arch/arm64/kdump.rst b/Documentation/arch/arm64/kdump.rst
new file mode 100644
index 000000000000..56a89f45df28
--- /dev/null
+++ b/Documentation/arch/arm64/kdump.rst
@@ -0,0 +1,92 @@
+=======================================
+crashkernel memory reservation on arm64
+=======================================
+
+Author: Baoquan He <bhe@redhat.com>
+
+Kdump mechanism is used to capture a corrupted kernel vmcore so that
+it can be subsequently analyzed. In order to do this, a preliminarily
+reserved memory is needed to pre-load the kdump kernel and boot such
+kernel if corruption happens.
+
+That reserved memory for kdump is adapted to be able to minimally
+accommodate the kdump kernel and the user space programs needed for the
+vmcore collection.
+
+Kernel parameter
+================
+
+Through the kernel parameters below, memory can be reserved accordingly
+during the early stage of the first kernel booting so that a continuous
+large chunk of memomy can be found. The low memory reservation needs to
+be considered if the crashkernel is reserved from the high memory area.
+
+- crashkernel=size@offset
+- crashkernel=size
+- crashkernel=size,high crashkernel=size,low
+
+Low memory and high memory
+==========================
+
+For kdump reservations, low memory is the memory area under a specific
+limit, usually decided by the accessible address bits of the DMA-capable
+devices needed by the kdump kernel to run. Those devices not related to
+vmcore dumping can be ignored. On arm64, the low memory upper bound is
+not fixed: it is 1G on the RPi4 platform but 4G on most other systems.
+On special kernels built with CONFIG_ZONE_(DMA|DMA32) disabled, the
+whole system RAM is low memory. Outside of the low memory described
+above, the rest of system RAM is considered high memory.
+
+Implementation
+==============
+
+1) crashkernel=size@offset
+--------------------------
+
+The crashkernel memory must be reserved at the user-specified region or
+fail if already occupied.
+
+
+2) crashkernel=size
+-------------------
+
+The crashkernel memory region will be reserved in any available position
+according to the search order:
+
+Firstly, the kernel searches the low memory area for an available region
+with the specified size.
+
+If searching for low memory fails, the kernel falls back to searching
+the high memory area for an available region of the specified size. If
+the reservation in high memory succeeds, a default size reservation in
+the low memory will be done. Currently the default size is 128M,
+sufficient for the low memory needs of the kdump kernel.
+
+Note: crashkernel=size is the recommended option for crashkernel kernel
+reservations. The user would not need to know the system memory layout
+for a specific platform.
+
+3) crashkernel=size,high crashkernel=size,low
+---------------------------------------------
+
+crashkernel=size,(high|low) are an important supplement to
+crashkernel=size. They allows the user to specify how much memory needs
+to be allocated from the high memory and low memory respectively. On
+many systems the low memory is precious and crashkernel reservations
+from this area should be kept to a minimum.
+
+To reserve memory for crashkernel=size,high, searching is first
+attempted from the high memory region. If the reservation succeeds, the
+low memory reservation will be done subsequently.
+
+If reservation from the high memory failed, the kernel falls back to
+searching the low memory with the specified size in crashkernel=,high.
+If it succeeds, no further reservation for low memory is needed.
+
+Notes:
+
+- If crashkernel=,low is not specified, the default low memory
+ reservation will be done automatically.
+
+- if crashkernel=0,low is specified, it means that the low memory
+ reservation is omitted intentionally.
diff --git a/Documentation/arm64/legacy_instructions.rst b/Documentation/arch/arm64/legacy_instructions.rst
index 54401b22cb8f..54401b22cb8f 100644
--- a/Documentation/arm64/legacy_instructions.rst
+++ b/Documentation/arch/arm64/legacy_instructions.rst
diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arch/arm64/memory-tagging-extension.rst
index dbae47bba25e..679725030731 100644
--- a/Documentation/arm64/memory-tagging-extension.rst
+++ b/Documentation/arch/arm64/memory-tagging-extension.rst
@@ -221,7 +221,7 @@ programs should not retry in case of a non-zero system call return.
``NT_ARM_TAGGED_ADDR_CTRL`` allow ``ptrace()`` access to the tagged
address ABI control and MTE configuration of a process as per the
``prctl()`` options described in
-Documentation/arm64/tagged-address-abi.rst and above. The corresponding
+Documentation/arch/arm64/tagged-address-abi.rst and above. The corresponding
``regset`` is 1 element of 8 bytes (``sizeof(long))``).
Core dump support
diff --git a/Documentation/arch/arm64/memory.rst b/Documentation/arch/arm64/memory.rst
new file mode 100644
index 000000000000..678fbb418c3a
--- /dev/null
+++ b/Documentation/arch/arm64/memory.rst
@@ -0,0 +1,100 @@
+==============================
+Memory Layout on AArch64 Linux
+==============================
+
+Author: Catalin Marinas <catalin.marinas@arm.com>
+
+This document describes the virtual memory layout used by the AArch64
+Linux kernel. The architecture allows up to 4 levels of translation
+tables with a 4KB page size and up to 3 levels with a 64KB page size.
+
+AArch64 Linux uses either 3 levels or 4 levels of translation tables
+with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
+(256TB) virtual addresses, respectively, for both user and kernel. With
+64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
+virtual address, are used but the memory layout is the same.
+
+ARMv8.2 adds optional support for Large Virtual Address space. This is
+only available when running with a 64KB page size and expands the
+number of descriptors in the first level of translation.
+
+TTBRx selection is given by bit 55 of the virtual address. The
+swapper_pg_dir contains only kernel (global) mappings while the user pgd
+contains only user (non-global) mappings. The swapper_pg_dir address is
+written to TTBR1 and never written to TTBR0.
+
+When using KVM without the Virtualization Host Extensions, the
+hypervisor maps kernel pages in EL2 at a fixed (and potentially
+random) offset from the linear mapping. See the kern_hyp_va macro and
+kvm_update_va_mask function for more details. MMIO devices such as
+GICv2 gets mapped next to the HYP idmap page, as do vectors when
+ARM64_SPECTRE_V3A is enabled for particular CPUs.
+
+When using KVM with the Virtualization Host Extensions, no additional
+mappings are created, since the host kernel runs directly in EL2.
+
+52-bit VA support in the kernel
+-------------------------------
+If the ARMv8.2-LVA optional feature is present, and we are running
+with a 64KB page size; then it is possible to use 52-bits of address
+space for both userspace and kernel addresses. However, any kernel
+binary that supports 52-bit must also be able to fall back to 48-bit
+at early boot time if the hardware feature is not present.
+
+This fallback mechanism necessitates the kernel .text to be in the
+higher addresses such that they are invariant to 48/52-bit VAs. Due
+to the kasan shadow being a fraction of the entire kernel VA space,
+the end of the kasan shadow must also be in the higher half of the
+kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
+the end of the kasan shadow is invariant and dependent on ~0UL,
+whilst the start address will "grow" towards the lower addresses).
+
+In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
+is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
+this obviates the need for an extra variable read. The physvirt
+offset and vmemmap offsets are computed at early boot to enable
+this logic.
+
+As a single binary will need to support both 48-bit and 52-bit VA
+spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
+also must be sized large enough to accommodate a fixed PAGE_OFFSET.
+
+Most code in the kernel should not need to consider the VA_BITS, for
+code that does need to know the VA size the variables are
+defined as follows:
+
+VA_BITS constant the *maximum* VA space size
+
+VA_BITS_MIN constant the *minimum* VA space size
+
+vabits_actual variable the *actual* VA space size
+
+
+Maximum and minimum sizes can be useful to ensure that buffers are
+sized large enough or that addresses are positioned close enough for
+the "worst" case.
+
+52-bit userspace VAs
+--------------------
+To maintain compatibility with software that relies on the ARMv8.0
+VA space maximum size of 48-bits, the kernel will, by default,
+return virtual addresses to userspace from a 48-bit range.
+
+Software can "opt-in" to receiving VAs from a 52-bit space by
+specifying an mmap hint parameter that is larger than 48-bit.
+
+For example:
+
+.. code-block:: c
+
+ maybe_high_address = mmap(~0UL, size, prot, flags,...);
+
+It is also possible to build a debug kernel that returns addresses
+from a 52-bit space by enabling the following kernel config options:
+
+.. code-block:: sh
+
+ CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
+
+Note that this option is only intended for debugging applications
+and should not be used in production.
diff --git a/Documentation/arch/arm64/mops.rst b/Documentation/arch/arm64/mops.rst
new file mode 100644
index 000000000000..2ef5b147f8dc
--- /dev/null
+++ b/Documentation/arch/arm64/mops.rst
@@ -0,0 +1,44 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===================================
+Memory copy/set instructions (MOPS)
+===================================
+
+A MOPS memory copy/set operation consists of three consecutive CPY* or SET*
+instructions: a prologue, main and epilogue (for example: CPYP, CPYM, CPYE).
+
+A main or epilogue instruction can take a MOPS exception for various reasons,
+for example when a task is migrated to a CPU with a different MOPS
+implementation, or when the instruction's alignment and size requirements are
+not met. The software exception handler is then expected to reset the registers
+and restart execution from the prologue instruction. Normally this is handled
+by the kernel.
+
+For more details refer to "D1.3.5.7 Memory Copy and Memory Set exceptions" in
+the Arm Architecture Reference Manual DDI 0487K.a (Arm ARM).
+
+.. _arm64_mops_hyp:
+
+Hypervisor requirements
+-----------------------
+
+A hypervisor running a Linux guest must handle all MOPS exceptions from the
+guest kernel, as Linux may not be able to handle the exception at all times.
+For example, a MOPS exception can be taken when the hypervisor migrates a vCPU
+to another physical CPU with a different MOPS implementation.
+
+To do this, the hypervisor must:
+
+ - Set HCRX_EL2.MCE2 to 1 so that the exception is taken to the hypervisor.
+
+ - Have an exception handler that implements the algorithm from the Arm ARM
+ rules CNTMJ and MWFQH.
+
+ - Set the guest's PSTATE.SS to 0 in the exception handler, to handle a
+ potential step of the current instruction.
+
+ Note: Clearing PSTATE.SS is needed so that a single step exception is taken
+ on the next instruction (the prologue instruction). Otherwise prologue
+ would get silently stepped over and the single step exception taken on the
+ main instruction. Note that if the guest instruction is not being stepped
+ then clearing PSTATE.SS has no effect.
diff --git a/Documentation/arch/arm64/perf.rst b/Documentation/arch/arm64/perf.rst
new file mode 100644
index 000000000000..997fd716b82f
--- /dev/null
+++ b/Documentation/arch/arm64/perf.rst
@@ -0,0 +1,238 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _perf_index:
+
+====
+Perf
+====
+
+Perf Event Attributes
+=====================
+
+:Author: Andrew Murray <andrew.murray@arm.com>
+:Date: 2019-03-06
+
+exclude_user
+------------
+
+This attribute excludes userspace.
+
+Userspace always runs at EL0 and thus this attribute will exclude EL0.
+
+
+exclude_kernel
+--------------
+
+This attribute excludes the kernel.
+
+The kernel runs at EL2 with VHE and EL1 without. Guest kernels always run
+at EL1.
+
+For the host this attribute will exclude EL1 and additionally EL2 on a VHE
+system.
+
+For the guest this attribute will exclude EL1. Please note that EL2 is
+never counted within a guest.
+
+
+exclude_hv
+----------
+
+This attribute excludes the hypervisor.
+
+For a VHE host this attribute is ignored as we consider the host kernel to
+be the hypervisor.
+
+For a non-VHE host this attribute will exclude EL2 as we consider the
+hypervisor to be any code that runs at EL2 which is predominantly used for
+guest/host transitions.
+
+For the guest this attribute has no effect. Please note that EL2 is
+never counted within a guest.
+
+
+exclude_host / exclude_guest
+----------------------------
+
+These attributes exclude the KVM host and guest, respectively.
+
+The KVM host may run at EL0 (userspace), EL1 (non-VHE kernel) and EL2 (VHE
+kernel or non-VHE hypervisor).
+
+The KVM guest may run at EL0 (userspace) and EL1 (kernel).
+
+Due to the overlapping exception levels between host and guests we cannot
+exclusively rely on the PMU's hardware exception filtering - therefore we
+must enable/disable counting on the entry and exit to the guest. This is
+performed differently on VHE and non-VHE systems.
+
+For non-VHE systems we exclude EL2 for exclude_host - upon entering and
+exiting the guest we disable/enable the event as appropriate based on the
+exclude_host and exclude_guest attributes.
+
+For VHE systems we exclude EL1 for exclude_guest and exclude both EL0,EL2
+for exclude_host. Upon entering and exiting the guest we modify the event
+to include/exclude EL0 as appropriate based on the exclude_host and
+exclude_guest attributes.
+
+The statements above also apply when these attributes are used within a
+non-VHE guest however please note that EL2 is never counted within a guest.
+
+
+Accuracy
+--------
+
+On non-VHE hosts we enable/disable counters on the entry/exit of host/guest
+transition at EL2 - however there is a period of time between
+enabling/disabling the counters and entering/exiting the guest. We are
+able to eliminate counters counting host events on the boundaries of guest
+entry/exit when counting guest events by filtering out EL2 for
+exclude_host. However when using !exclude_hv there is a small blackout
+window at the guest entry/exit where host events are not captured.
+
+On VHE systems there are no blackout windows.
+
+Perf Userspace PMU Hardware Counter Access
+==========================================
+
+Overview
+--------
+The perf userspace tool relies on the PMU to monitor events. It offers an
+abstraction layer over the hardware counters since the underlying
+implementation is cpu-dependent.
+Arm64 allows userspace tools to have access to the registers storing the
+hardware counters' values directly.
+
+This targets specifically self-monitoring tasks in order to reduce the overhead
+by directly accessing the registers without having to go through the kernel.
+
+How-to
+------
+The focus is set on the armv8 PMUv3 which makes sure that the access to the pmu
+registers is enabled and that the userspace has access to the relevant
+information in order to use them.
+
+In order to have access to the hardware counters, the global sysctl
+kernel/perf_user_access must first be enabled:
+
+.. code-block:: sh
+
+ echo 1 > /proc/sys/kernel/perf_user_access
+
+It is necessary to open the event using the perf tool interface with config1:1
+attr bit set: the sys_perf_event_open syscall returns a fd which can
+subsequently be used with the mmap syscall in order to retrieve a page of memory
+containing information about the event. The PMU driver uses this page to expose
+to the user the hardware counter's index and other necessary data. Using this
+index enables the user to access the PMU registers using the `mrs` instruction.
+Access to the PMU registers is only valid while the sequence lock is unchanged.
+In particular, the PMSELR_EL0 register is zeroed each time the sequence lock is
+changed.
+
+The userspace access is supported in libperf using the perf_evsel__mmap()
+and perf_evsel__read() functions. See `tools/lib/perf/tests/test-evsel.c`_ for
+an example.
+
+About heterogeneous systems
+---------------------------
+On heterogeneous systems such as big.LITTLE, userspace PMU counter access can
+only be enabled when the tasks are pinned to a homogeneous subset of cores and
+the corresponding PMU instance is opened by specifying the 'type' attribute.
+The use of generic event types is not supported in this case.
+
+Have a look at `tools/perf/arch/arm64/tests/user-events.c`_ for an example. It
+can be run using the perf tool to check that the access to the registers works
+correctly from userspace:
+
+.. code-block:: sh
+
+ perf test -v user
+
+About chained events and counter sizes
+--------------------------------------
+The user can request either a 32-bit (config1:0 == 0) or 64-bit (config1:0 == 1)
+counter along with userspace access. The sys_perf_event_open syscall will fail
+if a 64-bit counter is requested and the hardware doesn't support 64-bit
+counters. Chained events are not supported in conjunction with userspace counter
+access. If a 32-bit counter is requested on hardware with 64-bit counters, then
+userspace must treat the upper 32-bits read from the counter as UNKNOWN. The
+'pmc_width' field in the user page will indicate the valid width of the counter
+and should be used to mask the upper bits as needed.
+
+.. Links
+.. _tools/perf/arch/arm64/tests/user-events.c:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm64/tests/user-events.c
+.. _tools/lib/perf/tests/test-evsel.c:
+ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/tests/test-evsel.c
+
+Event Counting Threshold
+==========================================
+
+Overview
+--------
+
+FEAT_PMUv3_TH (Armv8.8) permits a PMU counter to increment only on
+events whose count meets a specified threshold condition. For example if
+threshold_compare is set to 2 ('Greater than or equal'), and the
+threshold is set to 2, then the PMU counter will now only increment by
+when an event would have previously incremented the PMU counter by 2 or
+more on a single processor cycle.
+
+To increment by 1 after passing the threshold condition instead of the
+number of events on that cycle, add the 'threshold_count' option to the
+commandline.
+
+How-to
+------
+
+These are the parameters for controlling the feature:
+
+.. list-table::
+ :header-rows: 1
+
+ * - Parameter
+ - Description
+ * - threshold
+ - Value to threshold the event by. A value of 0 means that
+ thresholding is disabled and the other parameters have no effect.
+ * - threshold_compare
+ - | Comparison function to use, with the following values supported:
+ |
+ | 0: Not-equal
+ | 1: Equals
+ | 2: Greater-than-or-equal
+ | 3: Less-than
+ * - threshold_count
+ - If this is set, count by 1 after passing the threshold condition
+ instead of the value of the event on this cycle.
+
+The threshold, threshold_compare and threshold_count values can be
+provided per event, for example:
+
+.. code-block:: sh
+
+ perf stat -e stall_slot/threshold=2,threshold_compare=2/ \
+ -e dtlb_walk/threshold=10,threshold_compare=3,threshold_count/
+
+In this example the stall_slot event will count by 2 or more on every
+cycle where 2 or more stalls happen. And dtlb_walk will count by 1 on
+every cycle where the number of dtlb walks were less than 10.
+
+The maximum supported threshold value can be read from the caps of each
+PMU, for example:
+
+.. code-block:: sh
+
+ cat /sys/bus/event_source/devices/armv8_pmuv3/caps/threshold_max
+
+ 0x000000ff
+
+If a value higher than this is given, then opening the event will result
+in an error. The highest possible maximum is 4095, as the config field
+for threshold is limited to 12 bits, and the Perf tool will refuse to
+parse higher values.
+
+If the PMU doesn't support FEAT_PMUv3_TH, then threshold_max will read
+0, and attempting to set a threshold value will also result in an error.
+threshold_max will also read as 0 on aarch32 guests, even if the host
+is running on hardware with the feature.
diff --git a/Documentation/arm64/pointer-authentication.rst b/Documentation/arch/arm64/pointer-authentication.rst
index e5dad2e40aa8..e5dad2e40aa8 100644
--- a/Documentation/arm64/pointer-authentication.rst
+++ b/Documentation/arch/arm64/pointer-authentication.rst
diff --git a/Documentation/arch/arm64/ptdump.rst b/Documentation/arch/arm64/ptdump.rst
new file mode 100644
index 000000000000..51eb902ba41a
--- /dev/null
+++ b/Documentation/arch/arm64/ptdump.rst
@@ -0,0 +1,94 @@
+======================
+Kernel page table dump
+======================
+
+ptdump is a debugfs interface that provides a detailed dump of the
+kernel page tables. It offers a comprehensive overview of the kernel
+virtual memory layout as well as the attributes associated with the
+various regions in a human-readable format. It is useful to dump the
+kernel page tables to verify permissions and memory types. Examining the
+page table entries and permissions helps identify potential security
+vulnerabilities such as mappings with overly permissive access rights or
+improper memory protections.
+
+Memory hotplug allows dynamic expansion or contraction of available
+memory without requiring a system reboot. To maintain the consistency
+and integrity of the memory management data structures, arm64 makes use
+of the ``mem_hotplug_lock`` semaphore in write mode. Additionally, in
+read mode, ``mem_hotplug_lock`` supports an efficient implementation of
+``get_online_mems()`` and ``put_online_mems()``. These protect the
+offlining of memory being accessed by the ptdump code.
+
+In order to dump the kernel page tables, enable the following
+configurations and mount debugfs::
+
+ CONFIG_PTDUMP_DEBUGFS=y
+
+ mount -t debugfs nodev /sys/kernel/debug
+ cat /sys/kernel/debug/kernel_page_tables
+
+On analysing the output of ``cat /sys/kernel/debug/kernel_page_tables``
+one can derive information about the virtual address range of the entry,
+followed by size of the memory region covered by this entry, the
+hierarchical structure of the page tables and finally the attributes
+associated with each page. The page attributes provide information about
+access permissions, execution capability, type of mapping such as leaf
+level PTE or block level PGD, PMD and PUD, and access status of a page
+within the kernel memory. Assessing these attributes can assist in
+understanding the memory layout, access patterns and security
+characteristics of the kernel pages.
+
+Kernel virtual memory layout example::
+
+ start address end address size attributes
+ +---------------------------------------------------------------------------------------+
+ | ---[ Linear Mapping start ]---------------------------------------------------------- |
+ | .................. |
+ | 0xfff0000000000000-0xfff0000000210000 2112K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED |
+ | 0xfff0000000210000-0xfff0000001c00000 26560K PTE ro NX SHD AF UXN MEM/NORMAL |
+ | .................. |
+ | ---[ Linear Mapping end ]------------------------------------------------------------ |
+ +---------------------------------------------------------------------------------------+
+ | ---[ Modules start ]----------------------------------------------------------------- |
+ | .................. |
+ | 0xffff800000000000-0xffff800008000000 128M PTE |
+ | .................. |
+ | ---[ Modules end ]------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ vmalloc() area ]---------------------------------------------------------------- |
+ | .................. |
+ | 0xffff800008010000-0xffff800008200000 1984K PTE ro x SHD AF UXN MEM/NORMAL |
+ | 0xffff800008200000-0xffff800008e00000 12M PTE ro x SHD AF CON UXN MEM/NORMAL |
+ | .................. |
+ | ---[ vmalloc() end ]----------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ Fixmap start ]------------------------------------------------------------------ |
+ | .................. |
+ | 0xfffffbfffdb80000-0xfffffbfffdb90000 64K PTE ro x SHD AF UXN MEM/NORMAL |
+ | 0xfffffbfffdb90000-0xfffffbfffdba0000 64K PTE ro NX SHD AF UXN MEM/NORMAL |
+ | .................. |
+ | ---[ Fixmap end ]-------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ PCI I/O start ]----------------------------------------------------------------- |
+ | .................. |
+ | 0xfffffbfffe800000-0xfffffbffff800000 16M PTE |
+ | .................. |
+ | ---[ PCI I/O end ]------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+ | ---[ vmemmap start ]----------------------------------------------------------------- |
+ | .................. |
+ | 0xfffffc0002000000-0xfffffc0002200000 2M PTE RW NX SHD AF UXN MEM/NORMAL |
+ | 0xfffffc0002200000-0xfffffc0020000000 478M PTE |
+ | .................. |
+ | ---[ vmemmap end ]------------------------------------------------------------------- |
+ +---------------------------------------------------------------------------------------+
+
+``cat /sys/kernel/debug/kernel_page_tables`` output::
+
+ 0xfff0000001c00000-0xfff0000080000000 2020M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000080000000-0xfff0000800000000 30G PMD
+ 0xfff0000800000000-0xfff0000800700000 7M PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000800700000-0xfff0000800710000 64K PTE ro NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000800710000-0xfff0000880000000 2089920K PTE RW NX SHD AF UXN MEM/NORMAL-TAGGED
+ 0xfff0000880000000-0xfff0040000000000 4062G PMD
+ 0xfff0040000000000-0xffff800000000000 3964T PGD
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
new file mode 100644
index 000000000000..a7ec57060f64
--- /dev/null
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -0,0 +1,307 @@
+=======================================
+Silicon Errata and Software Workarounds
+=======================================
+
+Author: Will Deacon <will.deacon@arm.com>
+
+Date : 27 November 2015
+
+It is an unfortunate fact of life that hardware is often produced with
+so-called "errata", which can cause it to deviate from the architecture
+under specific circumstances. For hardware produced by ARM, these
+errata are broadly classified into the following categories:
+
+ ========== ========================================================
+ Category A A critical error without a viable workaround.
+ Category B A significant or critical error with an acceptable
+ workaround.
+ Category C A minor error that is not expected to occur under normal
+ operation.
+ ========== ========================================================
+
+For more information, consult one of the "Software Developers Errata
+Notice" documents available on infocenter.arm.com (registration
+required).
+
+As far as Linux is concerned, Category B errata may require some special
+treatment in the operating system. For example, avoiding a particular
+sequence of code, or configuring the processor in a particular way. A
+less common situation may require similar actions in order to declassify
+a Category A erratum into a Category C erratum. These are collectively
+known as "software workarounds" and are only required in the minority of
+cases (e.g. those cases that both require a non-secure workaround *and*
+can be triggered by Linux).
+
+For software workarounds that may adversely impact systems unaffected by
+the erratum in question, a Kconfig entry is added under "Kernel
+Features" -> "ARM errata workarounds via the alternatives framework".
+With the exception of workarounds for errata deemed "rare" by Arm, these
+are enabled by default and patched in at runtime when an affected CPU is
+detected. For less-intrusive workarounds, a Kconfig option is not
+available and the code is structured (preferably with a comment) in such
+a way that the erratum will not be hit.
+
+This approach can make it slightly onerous to determine exactly which
+errata are worked around in an arbitrary kernel source tree, so this
+file acts as a registry of software workarounds in the Linux Kernel and
+will be updated when new workarounds are committed and backported to
+stable kernels.
+
++----------------+-----------------+-----------------+-----------------------------+
+| Implementor | Component | Erratum ID | Kconfig |
++================+=================+=================+=============================+
+| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
++----------------+-----------------+-----------------+-----------------------------+
+| Ampere | AmpereOne AC04 | AC04_CPU_10 | AMPERE_ERRATUM_AC03_CPU_38 |
++----------------+-----------------+-----------------+-----------------------------+
+| Ampere | AmpereOne AC04 | AC04_CPU_23 | AMPERE_ERRATUM_AC04_CPU_23 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A510 | #3117295 | ARM64_ERRATUM_3117295 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A520 | #2966298 | ARM64_ERRATUM_2966298 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A55 | #2441007 | ARM64_ERRATUM_2441007 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #852523 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A72 | #853709 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #1490853 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A77 | #1491015 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X1 | #1502854 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1349291 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1490853 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V1 | #1619801 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA|
+| | | #562869,1047329 | |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | MMU-600 | #1076982,1209401| N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | MMU-700 | #2268618,2812531| N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
++----------------+-----------------+-----------------+-----------------------------+
+| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX GICv3 | #38539 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX SMMUv2 | #27704 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX2 SMMUv3| #74 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX2 SMMUv3| #126 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Marvell | ARM-MMU-500 | #582743 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
++----------------+-----------------+-----------------+-----------------------------+
+| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip0{6,7} | #161010701 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip0{6,7} | #161010803 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip{08,09,09A,10| #162001900 | N/A |
+| | ,10C,11} | | |
+| | SMMU PMCG | | |
++----------------+-----------------+-----------------+-----------------------------+
+| Hisilicon | Hip09 | #162100801 | HISILICON_ERRATUM_162100801 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo/Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
++----------------+-----------------+-----------------+-----------------------------+
+| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
++----------------+-----------------+-----------------+-----------------------------+
+| Rockchip | RK3568 | #3568002 | ROCKCHIP_ERRATUM_3568002 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| ASR | ASR8601 | #8601001 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
++----------------+-----------------+-----------------+-----------------------------+
+| Microsoft | Azure Cobalt 100| #2139208 | ARM64_ERRATUM_2139208 |
++----------------+-----------------+-----------------+-----------------------------+
+| Microsoft | Azure Cobalt 100| #2067961 | ARM64_ERRATUM_2067961 |
++----------------+-----------------+-----------------+-----------------------------+
+| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
++----------------+-----------------+-----------------+-----------------------------+
+| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 |
++----------------+-----------------+-----------------+-----------------------------+
diff --git a/Documentation/arm64/sme.rst b/Documentation/arch/arm64/sme.rst
index 16d2db4c2e2e..583f2ee9cb97 100644
--- a/Documentation/arm64/sme.rst
+++ b/Documentation/arch/arm64/sme.rst
@@ -18,14 +18,19 @@ model features for SME is included in Appendix A.
1. General
-----------
-* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA
- register state and TPIDR2_EL0 are tracked per thread.
+* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA and (when
+ present) ZTn register state and TPIDR2_EL0 are tracked per thread.
* The presence of SME is reported to userspace via HWCAP2_SME in the aux vector
AT_HWCAP2 entry. Presence of this flag implies the presence of the SME
instructions and registers, and the Linux-specific system interfaces
described in this document. SME is reported in /proc/cpuinfo as "sme".
+* The presence of SME2 is reported to userspace via HWCAP2_SME2 in the
+ aux vector AT_HWCAP2 entry. Presence of this flag implies the presence of
+ the SME2 instructions and ZT0, and the Linux-specific system interfaces
+ described in this document. SME2 is reported in /proc/cpuinfo as "sme2".
+
* Support for the execution of SME instructions in userspace can also be
detected by reading the CPU ID register ID_AA64PFR1_EL1 using an MRS
instruction, and checking that the value of the SME field is nonzero. [3]
@@ -44,6 +49,7 @@ model features for SME is included in Appendix A.
HWCAP2_SME_B16F32
HWCAP2_SME_F32F32
HWCAP2_SME_FA64
+ HWCAP2_SME2
This list may be extended over time as the SME architecture evolves.
@@ -52,8 +58,8 @@ model features for SME is included in Appendix A.
cpu-feature-registers.txt for details.
* Debuggers should restrict themselves to interacting with the target via the
- NT_ARM_SVE, NT_ARM_SSVE and NT_ARM_ZA regsets. The recommended way
- of detecting support for these regsets is to connect to a target process
+ NT_ARM_SVE, NT_ARM_SSVE, NT_ARM_ZA and NT_ARM_ZT regsets. The recommended
+ way of detecting support for these regsets is to connect to a target process
first and then attempt a
ptrace(PTRACE_GETREGSET, pid, NT_ARM_<regset>, &iov).
@@ -63,39 +69,29 @@ model features for SME is included in Appendix A.
vectors from 0 to VL/8-1 stored in the same endianness invariant format as is
used for SVE vectors.
-* On thread creation TPIDR2_EL0 is preserved unless CLONE_SETTLS is specified,
- in which case it is set to 0.
+* On thread creation PSTATE.ZA and TPIDR2_EL0 are preserved unless CLONE_VM
+ is specified, in which case PSTATE.ZA is set to 0 and TPIDR2_EL0 is set to 0.
2. Vector lengths
------------------
-SME defines a second vector length similar to the SVE vector length which is
+SME defines a second vector length similar to the SVE vector length which
controls the size of the streaming mode SVE vectors and the ZA matrix array.
The ZA matrix is square with each side having as many bytes as a streaming
mode SVE vector.
-3. Sharing of streaming and non-streaming mode SVE state
----------------------------------------------------------
-
-It is implementation defined which if any parts of the SVE state are shared
-between streaming and non-streaming modes. When switching between modes
-via software interfaces such as ptrace if no register content is provided as
-part of switching no state will be assumed to be shared and everything will
-be zeroed.
-
-
-4. System call behaviour
+3. System call behaviour
-------------------------
* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the
- ZA matrix are preserved.
+ ZA matrix and ZTn (if present) are preserved.
* On syscall PSTATE.SM will be cleared and the SVE registers will be handled
as per the standard SVE ABI.
-* Neither the SVE registers nor ZA are used to pass arguments to or receive
- results from any syscall.
+* None of the SVE registers, ZA or ZTn are used to pass arguments to
+ or receive results from any syscall.
* On process creation (eg, clone()) the newly created process will have
PSTATE.SM cleared.
@@ -106,10 +102,13 @@ be zeroed.
exceptions for execve() described in section 6.
-5. Signal handling
+4. Signal handling
-------------------
-* Signal handlers are invoked with streaming mode and ZA disabled.
+* Signal handlers are invoked with PSTATE.SM=0, PSTATE.ZA=0, and TPIDR2_EL0=0.
+
+* A new signal frame record TPIDR2_MAGIC is added formatted as a struct
+ tpidr2_context to allow access to TPIDR2_EL0 from signal handlers.
* A new signal frame record za_context encodes the ZA register contents on
signal delivery. [1]
@@ -134,6 +133,14 @@ be zeroed.
__reserved[] referencing this space. za_context is then written in the
extra space. Refer to [1] for further details about this mechanism.
+* If ZTn is supported and PSTATE.ZA==1 then a signal frame record for ZTn will
+ be generated.
+
+* The signal record for ZTn has magic ZT_MAGIC (0x5a544e01) and consists of a
+ standard signal frame header followed by a struct zt_context specifying
+ the number of ZTn registers supported by the system, then zt_context.nregs
+ blocks of 64 bytes of data per register.
+
5. Signal return
-----------------
@@ -151,6 +158,9 @@ When returning from a signal handler:
the signal frame does not match the current vector length, the signal return
attempt is treated as illegal, resulting in a forced SIGSEGV.
+* If ZTn is not supported or PSTATE.ZA==0 then it is illegal to have a
+ signal frame record for ZTn, resulting in a forced SIGSEGV.
+
6. prctl extensions
--------------------
@@ -214,16 +224,16 @@ prctl(PR_SME_SET_VL, unsigned long arg)
vector length that will be applied at the next execve() by the calling
thread.
- * Changing the vector length causes all of ZA, P0..P15, FFR and all bits of
- Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
+ * Changing the vector length causes all of ZA, ZTn, P0..P15, FFR and all
+ bits of Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
unspecified, including both streaming and non-streaming SVE state.
Calling PR_SME_SET_VL with vl equal to the thread's current vector
- length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
+ length, or calling PR_SME_SET_VL with the PR_SME_SET_VL_ONEXEC flag,
does not constitute a change to the vector length for this purpose.
- * Changing the vector length causes PSTATE.ZA and PSTATE.SM to be cleared.
+ * Changing the vector length causes PSTATE.ZA to be cleared.
Calling PR_SME_SET_VL with vl equal to the thread's current vector
- length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
+ length, or calling PR_SME_SET_VL with the PR_SME_SET_VL_ONEXEC flag,
does not constitute a change to the vector length for this purpose.
@@ -302,7 +312,7 @@ The regset data starts with struct user_za_header, containing:
VL is supported.
* The size and layout of the payload depends on the header fields. The
- SME_PT_ZA_*() macros are provided to facilitate access to the data.
+ ZA_PT_ZA*() macros are provided to facilitate access to the data.
* In either case, for SETREGSET it is permissible to omit the payload, in which
case the vector length and flags are changed and PSTATE.ZA is set to 0
@@ -317,6 +327,19 @@ The regset data starts with struct user_za_header, containing:
* The effect of writing a partial, incomplete payload is unspecified.
+* A new regset NT_ARM_ZT is defined for access to ZTn state via
+ PTRACE_GETREGSET and PTRACE_SETREGSET.
+
+* The NT_ARM_ZT regset consists of a single 512 bit register.
+
+* When PSTATE.ZA==0 reads of NT_ARM_ZT will report all bits of ZTn as 0.
+
+* Writes to NT_ARM_ZT will set PSTATE.ZA to 1.
+
+* If any register data is provided along with SME_PT_VL_ONEXEC then the
+ registers data will be interpreted with the current vector length, not
+ the vector length configured for use on exec.
+
8. ELF coredump extensions
---------------------------
@@ -331,6 +354,11 @@ The regset data starts with struct user_za_header, containing:
been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread
when the coredump was generated.
+* A NT_ARM_ZT note will be added to each coredump for each thread of the
+ dumped process. The contents will be equivalent to the data that would have
+ been read if a PTRACE_GETREGSET of NT_ARM_ZT were executed for each thread
+ when the coredump was generated.
+
* The NT_ARM_TLS note will be extended to two registers, the second register
will contain TPIDR2_EL0 on systems that support SME and will be read as
zero with writes ignored otherwise.
@@ -345,9 +373,8 @@ The regset data starts with struct user_za_header, containing:
/proc/sys/abi/sme_default_vector_length
Writing the text representation of an integer to this file sets the system
- default vector length to the specified value, unless the value is greater
- than the maximum vector length supported by the system in which case the
- default vector length is set to that maximum.
+ default vector length to the specified value rounded to a supported value
+ using the same rules as for setting vector length via PR_SME_SET_VL.
The result can be determined by reopening the file and reading its
contents.
@@ -406,6 +433,9 @@ In A64 state, SME adds the following:
For best system performance it is strongly encouraged for software to enable
ZA only when it is actively being used.
+* A new ZT0 register is introduced when SME2 is present. This is a 512 bit
+ register which is accessible when PSTATE.ZA is set, as ZA itself is.
+
* Two new 1 bit fields in PSTATE which may be controlled via the SMSTART and
SMSTOP instructions or by access to the SVCR system register:
@@ -428,4 +458,4 @@ References
[2] arch/arm64/include/uapi/asm/ptrace.h
AArch64 Linux ptrace ABI definitions
-[3] Documentation/arm64/cpu-feature-registers.rst
+[3] Documentation/arch/arm64/cpu-feature-registers.rst
diff --git a/Documentation/arm64/sve.rst b/Documentation/arch/arm64/sve.rst
index f338ee2df46d..a61c9d0efe4d 100644
--- a/Documentation/arm64/sve.rst
+++ b/Documentation/arch/arm64/sve.rst
@@ -52,6 +52,7 @@ model features for SVE is included in Appendix A.
HWCAP2_SVEBITPERM
HWCAP2_SVESHA3
HWCAP2_SVESM4
+ HWCAP2_SVE2P1
This list may be extended over time as the SVE architecture evolves.
@@ -116,11 +117,6 @@ the SVE instruction set architecture.
* The SVE registers are not used to pass arguments to or receive results from
any syscall.
-* In practice the affected registers/bits will be preserved or will be replaced
- with zeros on return from a syscall, but userspace should not make
- assumptions about this. The kernel behaviour may vary on a case-by-case
- basis.
-
* All other SVE state of a thread, including the currently configured vector
length, the state of the PR_SVE_VL_INHERIT flag, and the deferred vector
length (if any), is preserved across all syscalls, subject to the specific
@@ -174,7 +170,7 @@ the SVE instruction set architecture.
When returning from a signal handler:
* If there is no sve_context record in the signal frame, or if the record is
- present but contains no register data as desribed in the previous section,
+ present but contains no register data as described in the previous section,
then the SVE registers/bits become non-live and take unspecified values.
* If sve_context is present in the signal frame and contains full register
@@ -222,7 +218,7 @@ prctl(PR_SVE_SET_VL, unsigned long arg)
Defer the requested vector length change until the next execve()
performed by this thread.
- The effect is equivalent to implicit exceution of the following
+ The effect is equivalent to implicit execution of the following
call immediately after the next execve() (if any) by the thread:
prctl(PR_SVE_SET_VL, arg & ~PR_SVE_SET_VL_ONEXEC)
@@ -406,6 +402,15 @@ The regset data starts with struct user_sve_header, containing:
streaming mode and any SETREGSET of NT_ARM_SSVE will enter streaming mode
if the target was not in streaming mode.
+* On systems that do not support SVE it is permitted to use SETREGSET to
+ write SVE_PT_REGS_FPSIMD formatted data via NT_ARM_SVE, in this case the
+ vector length should be specified as 0. This allows streaming mode to be
+ disabled on systems with SME but not SVE.
+
+* If any register data is provided along with SVE_PT_VL_ONEXEC then the
+ registers data will be interpreted with the current vector length, not
+ the vector length configured for use on exec.
+
* The effect of writing a partial, incomplete payload is unspecified.
@@ -427,9 +432,8 @@ The regset data starts with struct user_sve_header, containing:
/proc/sys/abi/sve_default_vector_length
Writing the text representation of an integer to this file sets the system
- default vector length to the specified value, unless the value is greater
- than the maximum vector length supported by the system in which case the
- default vector length is set to that maximum.
+ default vector length to the specified value rounded to a supported value
+ using the same rules as for setting vector length via PR_SVE_SET_VL.
The result can be determined by reopening the file and reading its
contents.
@@ -605,7 +609,7 @@ References
[2] arch/arm64/include/uapi/asm/ptrace.h
AArch64 Linux ptrace ABI definitions
-[3] Documentation/arm64/cpu-feature-registers.rst
+[3] Documentation/arch/arm64/cpu-feature-registers.rst
[4] ARM IHI0055C
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf
diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arch/arm64/tagged-address-abi.rst
index 540a1d4fc6c9..fe24a3f158c5 100644
--- a/Documentation/arm64/tagged-address-abi.rst
+++ b/Documentation/arch/arm64/tagged-address-abi.rst
@@ -107,7 +107,7 @@ following behaviours are guaranteed:
A definition of the meaning of tagged pointers on AArch64 can be found
-in Documentation/arm64/tagged-pointers.rst.
+in Documentation/arch/arm64/tagged-pointers.rst.
3. AArch64 Tagged Address ABI Exceptions
-----------------------------------------
diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arch/arm64/tagged-pointers.rst
index 19d284b70384..f87a925ca9a5 100644
--- a/Documentation/arm64/tagged-pointers.rst
+++ b/Documentation/arch/arm64/tagged-pointers.rst
@@ -22,7 +22,7 @@ Passing tagged addresses to the kernel
All interpretation of userspace memory addresses by the kernel assumes
an address tag of 0x00, unless the application enables the AArch64
Tagged Address ABI explicitly
-(Documentation/arm64/tagged-address-abi.rst).
+(Documentation/arch/arm64/tagged-address-abi.rst).
This includes, but is not limited to, addresses found in:
@@ -60,11 +60,12 @@ that signal handlers in applications making use of tags cannot rely
on the tag information for user virtual addresses being maintained
in these fields unless the flag was set.
-Due to architecture limitations, bits 63:60 of the fault address
-are not preserved in response to synchronous tag check faults
-(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should
-treat the values of these bits as undefined in order to accommodate
-future architecture revisions which may preserve the bits.
+If FEAT_MTE_TAGGED_FAR (Armv8.9) is supported, bits 63:60 of the fault address
+are preserved in response to synchronous tag check faults (SEGV_MTESERR)
+otherwise not preserved even if SA_EXPOSE_TAGBITS was set.
+Applications should interpret the values of these bits based on
+the support for the HWCAP3_MTE_FAR. If the support is not present,
+the values of these bits should be considered as undefined otherwise valid.
For signals raised in response to watchpoint debug exceptions, the
tag information will be preserved regardless of the SA_EXPOSE_TAGBITS
diff --git a/Documentation/arch/index.rst b/Documentation/arch/index.rst
new file mode 100644
index 000000000000..3f9962e45c09
--- /dev/null
+++ b/Documentation/arch/index.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+CPU Architectures
+=================
+
+These books provide programming details about architecture-specific
+implementation.
+
+.. toctree::
+ :maxdepth: 2
+
+ arc/index
+ arm/index
+ arm64/index
+ loongarch/index
+ m68k/index
+ mips/index
+ nios2/index
+ openrisc/index
+ parisc/index
+ powerpc/index
+ riscv/index
+ s390/index
+ sh/index
+ sparc/index
+ x86/index
+ xtensa/index
diff --git a/Documentation/arch/loongarch/booting.rst b/Documentation/arch/loongarch/booting.rst
new file mode 100644
index 000000000000..91eccd410478
--- /dev/null
+++ b/Documentation/arch/loongarch/booting.rst
@@ -0,0 +1,42 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+Booting Linux/LoongArch
+=======================
+
+:Author: Yanteng Si <siyanteng@loongson.cn>
+:Date: 18 Nov 2022
+
+Information passed from BootLoader to kernel
+============================================
+
+LoongArch supports ACPI and FDT. The information that needs to be passed
+to the kernel includes the memmap, the initrd, the command line, optionally
+the ACPI/FDT tables, and so on.
+
+The kernel is passed the following arguments on `kernel_entry` :
+
+ - a0 = efi_boot: `efi_boot` is a flag indicating whether
+ this boot environment is fully UEFI-compliant.
+
+ - a1 = cmdline: `cmdline` is a pointer to the kernel command line.
+
+ - a2 = systemtable: `systemtable` points to the EFI system table.
+ All pointers involved at this stage are in physical addresses.
+
+Header of Linux/LoongArch kernel images
+=======================================
+
+Linux/LoongArch kernel images are EFI images. Being PE files, they have
+a 64-byte header structured like::
+
+ u32 MZ_MAGIC /* "MZ", MS-DOS header */
+ u32 res0 = 0 /* Reserved */
+ u64 kernel_entry /* Kernel entry point */
+ u64 _end - _text /* Kernel image effective size */
+ u64 load_offset /* Kernel image load offset from start of RAM */
+ u64 res1 = 0 /* Reserved */
+ u64 res2 = 0 /* Reserved */
+ u64 res3 = 0 /* Reserved */
+ u32 LINUX_PE_MAGIC /* Magic number */
+ u32 pe_header - _head /* Offset to the PE header */
diff --git a/Documentation/arch/loongarch/features.rst b/Documentation/arch/loongarch/features.rst
new file mode 100644
index 000000000000..009f44c7951f
--- /dev/null
+++ b/Documentation/arch/loongarch/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features loongarch
diff --git a/Documentation/arch/loongarch/index.rst b/Documentation/arch/loongarch/index.rst
new file mode 100644
index 000000000000..c779bfa00c05
--- /dev/null
+++ b/Documentation/arch/loongarch/index.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+LoongArch Architecture
+======================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ introduction
+ booting
+ irq-chip-model
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arch/loongarch/introduction.rst b/Documentation/arch/loongarch/introduction.rst
new file mode 100644
index 000000000000..5e6db78abeaf
--- /dev/null
+++ b/Documentation/arch/loongarch/introduction.rst
@@ -0,0 +1,390 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================
+Introduction to LoongArch
+=========================
+
+LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V. There are
+currently 3 variants: a reduced 32-bit version (LA32R), a standard 32-bit
+version (LA32S) and a 64-bit version (LA64). There are 4 privilege levels
+(PLVs) defined in LoongArch: PLV0~PLV3, from high to low. Kernel runs at PLV0
+while applications run at PLV3. This document introduces the registers, basic
+instruction set, virtual memory and some other topics of LoongArch.
+
+Registers
+=========
+
+LoongArch registers include general purpose registers (GPRs), floating point
+registers (FPRs), vector registers (VRs) and control status registers (CSRs)
+used in privileged mode (PLV0).
+
+GPRs
+----
+
+LoongArch has 32 GPRs ( ``$r0`` ~ ``$r31`` ); each one is 32-bit wide in LA32
+and 64-bit wide in LA64. ``$r0`` is hard-wired to zero, and the other registers
+are not architecturally special. (Except ``$r1``, which is hard-wired as the
+link register of the BL instruction.)
+
+The kernel uses a variant of the LoongArch register convention, as described in
+the LoongArch ELF psABI spec, in :ref:`References <loongarch-references>`:
+
+================= =============== =================== ============
+Name Alias Usage Preserved
+ across calls
+================= =============== =================== ============
+``$r0`` ``$zero`` Constant zero Unused
+``$r1`` ``$ra`` Return address No
+``$r2`` ``$tp`` TLS/Thread pointer Unused
+``$r3`` ``$sp`` Stack pointer Yes
+``$r4``-``$r11`` ``$a0``-``$a7`` Argument registers No
+``$r4``-``$r5`` ``$v0``-``$v1`` Return value No
+``$r12``-``$r20`` ``$t0``-``$t8`` Temp registers No
+``$r21`` ``$u0`` Percpu base address Unused
+``$r22`` ``$fp`` Frame pointer Yes
+``$r23``-``$r31`` ``$s0``-``$s8`` Static registers Yes
+================= =============== =================== ============
+
+.. Note::
+ The register ``$r21`` is reserved in the ELF psABI, but used by the Linux
+ kernel for storing the percpu base address. It normally has no ABI name,
+ but is called ``$u0`` in the kernel. You may also see ``$v0`` or ``$v1``
+ in some old code,however they are deprecated aliases of ``$a0`` and ``$a1``
+ respectively.
+
+FPRs
+----
+
+LoongArch has 32 FPRs ( ``$f0`` ~ ``$f31`` ) when FPU is present. Each one is
+64-bit wide on the LA64 cores.
+
+The floating-point register convention is the same as described in the
+LoongArch ELF psABI spec:
+
+================= ================== =================== ============
+Name Alias Usage Preserved
+ across calls
+================= ================== =================== ============
+``$f0``-``$f7`` ``$fa0``-``$fa7`` Argument registers No
+``$f0``-``$f1`` ``$fv0``-``$fv1`` Return value No
+``$f8``-``$f23`` ``$ft0``-``$ft15`` Temp registers No
+``$f24``-``$f31`` ``$fs0``-``$fs7`` Static registers Yes
+================= ================== =================== ============
+
+.. Note::
+ You may see ``$fv0`` or ``$fv1`` in some old code, however they are
+ deprecated aliases of ``$fa0`` and ``$fa1`` respectively.
+
+VRs
+----
+
+There are currently 2 vector extensions to LoongArch:
+
+- LSX (Loongson SIMD eXtension) with 128-bit vectors,
+- LASX (Loongson Advanced SIMD eXtension) with 256-bit vectors.
+
+LSX brings ``$v0`` ~ ``$v31`` while LASX brings ``$x0`` ~ ``$x31`` as the vector
+registers.
+
+The VRs overlap with FPRs: for example, on a core implementing LSX and LASX,
+the lower 128 bits of ``$x0`` is shared with ``$v0``, and the lower 64 bits of
+``$v0`` is shared with ``$f0``; same with all other VRs.
+
+CSRs
+----
+
+CSRs can only be accessed from privileged mode (PLV0):
+
+================= ===================================== ==============
+Address Full Name Abbrev Name
+================= ===================================== ==============
+0x0 Current Mode Information CRMD
+0x1 Pre-exception Mode Information PRMD
+0x2 Extension Unit Enable EUEN
+0x3 Miscellaneous Control MISC
+0x4 Exception Configuration ECFG
+0x5 Exception Status ESTAT
+0x6 Exception Return Address ERA
+0x7 Bad (Faulting) Virtual Address BADV
+0x8 Bad (Faulting) Instruction Word BADI
+0xC Exception Entrypoint Address EENTRY
+0x10 TLB Index TLBIDX
+0x11 TLB Entry High-order Bits TLBEHI
+0x12 TLB Entry Low-order Bits 0 TLBELO0
+0x13 TLB Entry Low-order Bits 1 TLBELO1
+0x18 Address Space Identifier ASID
+0x19 Page Global Directory Address for PGDL
+ Lower-half Address Space
+0x1A Page Global Directory Address for PGDH
+ Higher-half Address Space
+0x1B Page Global Directory Address PGD
+0x1C Page Walk Control for Lower- PWCL
+ half Address Space
+0x1D Page Walk Control for Higher- PWCH
+ half Address Space
+0x1E STLB Page Size STLBPS
+0x1F Reduced Virtual Address Configuration RVACFG
+0x20 CPU Identifier CPUID
+0x21 Privileged Resource Configuration 1 PRCFG1
+0x22 Privileged Resource Configuration 2 PRCFG2
+0x23 Privileged Resource Configuration 3 PRCFG3
+0x30+n (0≤n≤15) Saved Data register SAVEn
+0x40 Timer Identifier TID
+0x41 Timer Configuration TCFG
+0x42 Timer Value TVAL
+0x43 Compensation of Timer Count CNTC
+0x44 Timer Interrupt Clearing TICLR
+0x60 LLBit Control LLBCTL
+0x80 Implementation-specific Control 1 IMPCTL1
+0x81 Implementation-specific Control 2 IMPCTL2
+0x88 TLB Refill Exception Entrypoint TLBRENTRY
+ Address
+0x89 TLB Refill Exception BAD (Faulting) TLBRBADV
+ Virtual Address
+0x8A TLB Refill Exception Return Address TLBRERA
+0x8B TLB Refill Exception Saved Data TLBRSAVE
+ Register
+0x8C TLB Refill Exception Entry Low-order TLBRELO0
+ Bits 0
+0x8D TLB Refill Exception Entry Low-order TLBRELO1
+ Bits 1
+0x8E TLB Refill Exception Entry High-order TLBEHI
+ Bits
+0x8F TLB Refill Exception Pre-exception TLBRPRMD
+ Mode Information
+0x90 Machine Error Control MERRCTL
+0x91 Machine Error Information 1 MERRINFO1
+0x92 Machine Error Information 2 MERRINFO2
+0x93 Machine Error Exception Entrypoint MERRENTRY
+ Address
+0x94 Machine Error Exception Return MERRERA
+ Address
+0x95 Machine Error Exception Saved Data MERRSAVE
+ Register
+0x98 Cache TAGs CTAG
+0x180+n (0≤n≤3) Direct Mapping Configuration Window n DMWn
+0x200+2n (0≤n≤31) Performance Monitor Configuration n PMCFGn
+0x201+2n (0≤n≤31) Performance Monitor Overall Counter n PMCNTn
+0x300 Memory Load/Store WatchPoint MWPC
+ Overall Control
+0x301 Memory Load/Store WatchPoint MWPS
+ Overall Status
+0x310+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG1
+ Configuration 1
+0x311+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG2
+ Configuration 2
+0x312+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG3
+ Configuration 3
+0x313+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG4
+ Configuration 4
+0x380 Instruction Fetch WatchPoint FWPC
+ Overall Control
+0x381 Instruction Fetch WatchPoint FWPS
+ Overall Status
+0x390+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG1
+ Configuration 1
+0x391+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG2
+ Configuration 2
+0x392+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG3
+ Configuration 3
+0x393+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG4
+ Configuration 4
+0x500 Debug Register DBG
+0x501 Debug Exception Return Address DERA
+0x502 Debug Exception Saved Data Register DSAVE
+================= ===================================== ==============
+
+ERA, TLBRERA, MERRERA and DERA are sometimes also known as EPC, TLBREPC, MERREPC
+and DEPC respectively.
+
+Basic Instruction Set
+=====================
+
+Instruction formats
+-------------------
+
+LoongArch instructions are 32 bits wide, belonging to 9 basic instruction
+formats (and variants of them):
+
+=========== ==========================
+Format name Composition
+=========== ==========================
+2R Opcode + Rj + Rd
+3R Opcode + Rk + Rj + Rd
+4R Opcode + Ra + Rk + Rj + Rd
+2RI8 Opcode + I8 + Rj + Rd
+2RI12 Opcode + I12 + Rj + Rd
+2RI14 Opcode + I14 + Rj + Rd
+2RI16 Opcode + I16 + Rj + Rd
+1RI21 Opcode + I21L + Rj + I21H
+I26 Opcode + I26L + I26H
+=========== ==========================
+
+Rd is the destination register operand, while Rj, Rk and Ra ("a" stands for
+"additional") are the source register operands. I8/I12/I14/I16/I21/I26 are
+immediate operands of respective width. The longer I21 and I26 are stored
+in separate higher and lower parts in the instruction word, denoted by the "L"
+and "H" suffixes.
+
+List of Instructions
+--------------------
+
+For brevity, only instruction names (mnemonics) are listed here; please see the
+:ref:`References <loongarch-references>` for details.
+
+
+1. Arithmetic Instructions::
+
+ ADD.W SUB.W ADDI.W ADD.D SUB.D ADDI.D
+ SLT SLTU SLTI SLTUI
+ AND OR NOR XOR ANDN ORN ANDI ORI XORI
+ MUL.W MULH.W MULH.WU DIV.W DIV.WU MOD.W MOD.WU
+ MUL.D MULH.D MULH.DU DIV.D DIV.DU MOD.D MOD.DU
+ PCADDI PCADDU12I PCADDU18I
+ LU12I.W LU32I.D LU52I.D ADDU16I.D
+
+2. Bit-shift Instructions::
+
+ SLL.W SRL.W SRA.W ROTR.W SLLI.W SRLI.W SRAI.W ROTRI.W
+ SLL.D SRL.D SRA.D ROTR.D SLLI.D SRLI.D SRAI.D ROTRI.D
+
+3. Bit-manipulation Instructions::
+
+ EXT.W.B EXT.W.H CLO.W CLO.D SLZ.W CLZ.D CTO.W CTO.D CTZ.W CTZ.D
+ BYTEPICK.W BYTEPICK.D BSTRINS.W BSTRINS.D BSTRPICK.W BSTRPICK.D
+ REVB.2H REVB.4H REVB.2W REVB.D REVH.2W REVH.D BITREV.4B BITREV.8B BITREV.W BITREV.D
+ MASKEQZ MASKNEZ
+
+4. Branch Instructions::
+
+ BEQ BNE BLT BGE BLTU BGEU BEQZ BNEZ B BL JIRL
+
+5. Load/Store Instructions::
+
+ LD.B LD.BU LD.H LD.HU LD.W LD.WU LD.D ST.B ST.H ST.W ST.D
+ LDX.B LDX.BU LDX.H LDX.HU LDX.W LDX.WU LDX.D STX.B STX.H STX.W STX.D
+ LDPTR.W LDPTR.D STPTR.W STPTR.D
+ PRELD PRELDX
+
+6. Atomic Operation Instructions::
+
+ LL.W SC.W LL.D SC.D
+ AMSWAP.W AMSWAP.D AMADD.W AMADD.D AMAND.W AMAND.D AMOR.W AMOR.D AMXOR.W AMXOR.D
+ AMMAX.W AMMAX.D AMMIN.W AMMIN.D
+
+7. Barrier Instructions::
+
+ IBAR DBAR
+
+8. Special Instructions::
+
+ SYSCALL BREAK CPUCFG NOP IDLE ERTN(ERET) DBCL(DBGCALL) RDTIMEL.W RDTIMEH.W RDTIME.D
+ ASRTLE.D ASRTGT.D
+
+9. Privileged Instructions::
+
+ CSRRD CSRWR CSRXCHG
+ IOCSRRD.B IOCSRRD.H IOCSRRD.W IOCSRRD.D IOCSRWR.B IOCSRWR.H IOCSRWR.W IOCSRWR.D
+ CACOP TLBP(TLBSRCH) TLBRD TLBWR TLBFILL TLBCLR TLBFLUSH INVTLB LDDIR LDPTE
+
+Virtual Memory
+==============
+
+LoongArch supports direct-mapped virtual memory and page-mapped virtual memory.
+
+Direct-mapped virtual memory is configured by CSR.DMWn (n=0~3), it has a simple
+relationship between virtual address (VA) and physical address (PA)::
+
+ VA = PA + FixedOffset
+
+Page-mapped virtual memory has arbitrary relationship between VA and PA, which
+is recorded in TLB and page tables. LoongArch's TLB includes a fully-associative
+MTLB (Multiple Page Size TLB) and set-associative STLB (Single Page Size TLB).
+
+By default, the whole virtual address space of LA32 is configured like this:
+
+============ =========================== =============================
+Name Address Range Attributes
+============ =========================== =============================
+``UVRANGE`` ``0x00000000 - 0x7FFFFFFF`` Page-mapped, Cached, PLV0~3
+``KPRANGE0`` ``0x80000000 - 0x9FFFFFFF`` Direct-mapped, Uncached, PLV0
+``KPRANGE1`` ``0xA0000000 - 0xBFFFFFFF`` Direct-mapped, Cached, PLV0
+``KVRANGE`` ``0xC0000000 - 0xFFFFFFFF`` Page-mapped, Cached, PLV0
+============ =========================== =============================
+
+User mode (PLV3) can only access UVRANGE. For direct-mapped KPRANGE0 and
+KPRANGE1, PA is equal to VA with bit30~31 cleared. For example, the uncached
+direct-mapped VA of 0x00001000 is 0x80001000, and the cached direct-mapped
+VA of 0x00001000 is 0xA0001000.
+
+By default, the whole virtual address space of LA64 is configured like this:
+
+============ ====================== ======================================
+Name Address Range Attributes
+============ ====================== ======================================
+``XUVRANGE`` ``0x0000000000000000 - Page-mapped, Cached, PLV0~3
+ 0x3FFFFFFFFFFFFFFF``
+``XSPRANGE`` ``0x4000000000000000 - Direct-mapped, Cached / Uncached, PLV0
+ 0x7FFFFFFFFFFFFFFF``
+``XKPRANGE`` ``0x8000000000000000 - Direct-mapped, Cached / Uncached, PLV0
+ 0xBFFFFFFFFFFFFFFF``
+``XKVRANGE`` ``0xC000000000000000 - Page-mapped, Cached, PLV0
+ 0xFFFFFFFFFFFFFFFF``
+============ ====================== ======================================
+
+User mode (PLV3) can only access XUVRANGE. For direct-mapped XSPRANGE and
+XKPRANGE, PA is equal to VA with bits 60~63 cleared, and the cache attribute
+is configured by bits 60~61 in VA: 0 is for strongly-ordered uncached, 1 is
+for coherent cached, and 2 is for weakly-ordered uncached.
+
+Currently we only use XKPRANGE for direct mapping and XSPRANGE is reserved.
+
+To put this in action: the strongly-ordered uncached direct-mapped VA (in
+XKPRANGE) of 0x00000000_00001000 is 0x80000000_00001000, the coherent cached
+direct-mapped VA (in XKPRANGE) of 0x00000000_00001000 is 0x90000000_00001000,
+and the weakly-ordered uncached direct-mapped VA (in XKPRANGE) of 0x00000000
+_00001000 is 0xA0000000_00001000.
+
+Relationship of Loongson and LoongArch
+======================================
+
+LoongArch is a RISC ISA which is different from any other existing ones, while
+Loongson is a family of processors. Loongson includes 3 series: Loongson-1 is
+the 32-bit processor series, Loongson-2 is the low-end 64-bit processor series,
+and Loongson-3 is the high-end 64-bit processor series. Old Loongson is based on
+MIPS, while New Loongson is based on LoongArch. Take Loongson-3 as an example:
+Loongson-3A1000/3B1500/3A2000/3A3000/3A4000 are MIPS-compatible, while Loongson-
+3A5000 (and future revisions) are all based on LoongArch.
+
+.. _loongarch-references:
+
+References
+==========
+
+Official web site of Loongson Technology Corp. Ltd.:
+
+ http://www.loongson.cn/
+
+Developer web site of Loongson and LoongArch (Software and Documentation):
+
+ http://www.loongnix.cn/
+
+ https://github.com/loongson/
+
+ https://loongson.github.io/LoongArch-Documentation/
+
+Documentation of LoongArch ISA:
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-CN.pdf (in Chinese)
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-EN.pdf (in English)
+
+Documentation of LoongArch ELF psABI:
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.01-CN.pdf (in Chinese)
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.01-EN.pdf (in English)
+
+Linux kernel repository of Loongson and LoongArch:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
diff --git a/Documentation/arch/loongarch/irq-chip-model.rst b/Documentation/arch/loongarch/irq-chip-model.rst
new file mode 100644
index 000000000000..8f5c3345109e
--- /dev/null
+++ b/Documentation/arch/loongarch/irq-chip-model.rst
@@ -0,0 +1,256 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================================
+IRQ chip model (hierarchy) of LoongArch
+=======================================
+
+Currently, LoongArch based processors (e.g. Loongson-3A5000) can only work together
+with LS7A chipsets. The irq chips in LoongArch computers include CPUINTC (CPU Core
+Interrupt Controller), LIOINTC (Legacy I/O Interrupt Controller), EIOINTC (Extended
+I/O Interrupt Controller), HTVECINTC (Hyper-Transport Vector Interrupt Controller),
+PCH-PIC (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
+in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
+
+CPUINTC is a per-core controller (in CPU), LIOINTC/EIOINTC/HTVECINTC are per-package
+controllers (in CPU), while PCH-PIC/PCH-LPC/PCH-MSI are controllers out of CPU (i.e.,
+in chipsets). These controllers (in other words, irqchips) are linked in a hierarchy,
+and there are two models of hierarchy (legacy model and extended model).
+
+Legacy IRQ model
+================
+
+In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go
+to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, while all other devices
+interrupts go to PCH-PIC/PCH-LPC/PCH-MSI and gathered by HTVECINTC, and then go
+to LIOINTC, and then CPUINTC::
+
+ +-----+ +---------+ +-------+
+ | IPI | --> | CPUINTC | <-- | Timer |
+ +-----+ +---------+ +-------+
+ ^
+ |
+ +---------+ +-------+
+ | LIOINTC | <-- | UARTs |
+ +---------+ +-------+
+ ^
+ |
+ +-----------+
+ | HTVECINTC |
+ +-----------+
+ ^ ^
+ | |
+ +---------+ +---------+
+ | PCH-PIC | | PCH-MSI |
+ +---------+ +---------+
+ ^ ^ ^
+ | | |
+ +---------+ +---------+ +---------+
+ | PCH-LPC | | Devices | | Devices |
+ +---------+ +---------+ +---------+
+ ^
+ |
+ +---------+
+ | Devices |
+ +---------+
+
+Extended IRQ model
+==================
+
+In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go
+to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, while all other devices
+interrupts go to PCH-PIC/PCH-LPC/PCH-MSI and gathered by EIOINTC, and then go to
+to CPUINTC directly::
+
+ +-----+ +---------+ +-------+
+ | IPI | --> | CPUINTC | <-- | Timer |
+ +-----+ +---------+ +-------+
+ ^ ^
+ | |
+ +---------+ +---------+ +-------+
+ | EIOINTC | | LIOINTC | <-- | UARTs |
+ +---------+ +---------+ +-------+
+ ^ ^
+ | |
+ +---------+ +---------+
+ | PCH-PIC | | PCH-MSI |
+ +---------+ +---------+
+ ^ ^ ^
+ | | |
+ +---------+ +---------+ +---------+
+ | PCH-LPC | | Devices | | Devices |
+ +---------+ +---------+ +---------+
+ ^
+ |
+ +---------+
+ | Devices |
+ +---------+
+
+Virtual Extended IRQ model
+==========================
+
+In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt
+go to CPUINTC directly, CPU UARTS interrupts go to PCH-PIC, while all other
+devices interrupts go to PCH-PIC/PCH-MSI and gathered by V-EIOINTC (Virtual
+Extended I/O Interrupt Controller), and then go to CPUINTC directly::
+
+ +-----+ +-------------------+ +-------+
+ | IPI |--> | CPUINTC(0-255vcpu)| <-- | Timer |
+ +-----+ +-------------------+ +-------+
+ ^
+ |
+ +-----------+
+ | V-EIOINTC |
+ +-----------+
+ ^ ^
+ | |
+ +---------+ +---------+
+ | PCH-PIC | | PCH-MSI |
+ +---------+ +---------+
+ ^ ^ ^
+ | | |
+ +--------+ +---------+ +---------+
+ | UARTs | | Devices | | Devices |
+ +--------+ +---------+ +---------+
+
+
+Description
+-----------
+V-EIOINTC (Virtual Extended I/O Interrupt Controller) is an extension of
+EIOINTC, it only works in VM mode which runs in KVM hypervisor. Interrupts can
+be routed to up to four vCPUs via standard EIOINTC, however with V-EIOINTC
+interrupts can be routed to up to 256 virtual cpus.
+
+With standard EIOINTC, interrupt routing setting includes two parts: eight
+bits for CPU selection and four bits for CPU IP (Interrupt Pin) selection.
+For CPU selection there is four bits for EIOINTC node selection, four bits
+for EIOINTC CPU selection. Bitmap method is used for CPU selection and
+CPU IP selection, so interrupt can only route to CPU0 - CPU3 and IP0-IP3 in
+one EIOINTC node.
+
+With V-EIOINTC it supports to route more CPUs and CPU IP (Interrupt Pin),
+there are two newly added registers with V-EIOINTC.
+
+EXTIOI_VIRT_FEATURES
+--------------------
+This register is read-only register, which indicates supported features with
+V-EIOINTC. Feature EXTIOI_HAS_INT_ENCODE and EXTIOI_HAS_CPU_ENCODE is added.
+
+Feature EXTIOI_HAS_INT_ENCODE is part of standard EIOINTC. If it is 1, it
+indicates that CPU Interrupt Pin selection can be normal method rather than
+bitmap method, so interrupt can be routed to IP0 - IP15.
+
+Feature EXTIOI_HAS_CPU_ENCODE is extension of V-EIOINTC. If it is 1, it
+indicates that CPU selection can be normal method rather than bitmap method,
+so interrupt can be routed to CPU0 - CPU255.
+
+EXTIOI_VIRT_CONFIG
+------------------
+This register is read-write register, for compatibility interrupt routed uses
+the default method which is the same with standard EIOINTC. If the bit is set
+with 1, it indicated HW to use normal method rather than bitmap method.
+
+Advanced Extended IRQ model
+===========================
+
+In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go
+to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, PCH-MSI interrupts go
+to AVECINTC, and then go to CPUINTC directly, while all other devices interrupts
+go to PCH-PIC/PCH-LPC and gathered by EIOINTC, and then go to CPUINTC directly::
+
+ +-----+ +-----------------------+ +-------+
+ | IPI | --> | CPUINTC | <-- | Timer |
+ +-----+ +-----------------------+ +-------+
+ ^ ^ ^
+ | | |
+ +---------+ +----------+ +---------+ +-------+
+ | EIOINTC | | AVECINTC | | LIOINTC | <-- | UARTs |
+ +---------+ +----------+ +---------+ +-------+
+ ^ ^
+ | |
+ +---------+ +---------+
+ | PCH-PIC | | PCH-MSI |
+ +---------+ +---------+
+ ^ ^ ^
+ | | |
+ +---------+ +---------+ +---------+
+ | Devices | | PCH-LPC | | Devices |
+ +---------+ +---------+ +---------+
+ ^
+ |
+ +---------+
+ | Devices |
+ +---------+
+
+ACPI-related definitions
+========================
+
+CPUINTC::
+
+ ACPI_MADT_TYPE_CORE_PIC;
+ struct acpi_madt_core_pic;
+ enum acpi_madt_core_pic_version;
+
+LIOINTC::
+
+ ACPI_MADT_TYPE_LIO_PIC;
+ struct acpi_madt_lio_pic;
+ enum acpi_madt_lio_pic_version;
+
+EIOINTC::
+
+ ACPI_MADT_TYPE_EIO_PIC;
+ struct acpi_madt_eio_pic;
+ enum acpi_madt_eio_pic_version;
+
+HTVECINTC::
+
+ ACPI_MADT_TYPE_HT_PIC;
+ struct acpi_madt_ht_pic;
+ enum acpi_madt_ht_pic_version;
+
+PCH-PIC::
+
+ ACPI_MADT_TYPE_BIO_PIC;
+ struct acpi_madt_bio_pic;
+ enum acpi_madt_bio_pic_version;
+
+PCH-MSI::
+
+ ACPI_MADT_TYPE_MSI_PIC;
+ struct acpi_madt_msi_pic;
+ enum acpi_madt_msi_pic_version;
+
+PCH-LPC::
+
+ ACPI_MADT_TYPE_LPC_PIC;
+ struct acpi_madt_lpc_pic;
+ enum acpi_madt_lpc_pic_version;
+
+References
+==========
+
+Documentation of Loongson-3A5000:
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-CN.pdf (in Chinese)
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-EN.pdf (in English)
+
+Documentation of Loongson's LS7A chipset:
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-CN.pdf (in Chinese)
+
+ https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-EN.pdf (in English)
+
+.. Note::
+ - CPUINTC is CSR.ECFG/CSR.ESTAT and its interrupt controller described
+ in Section 7.4 of "LoongArch Reference Manual, Vol 1";
+ - LIOINTC is "Legacy I/OInterrupts" described in Section 11.1 of
+ "Loongson 3A5000 Processor Reference Manual";
+ - EIOINTC is "Extended I/O Interrupts" described in Section 11.2 of
+ "Loongson 3A5000 Processor Reference Manual";
+ - HTVECINTC is "HyperTransport Interrupts" described in Section 14.3 of
+ "Loongson 3A5000 Processor Reference Manual";
+ - PCH-PIC/PCH-MSI is "Interrupt Controller" described in Section 5 of
+ "Loongson 7A1000 Bridge User Manual";
+ - PCH-LPC is "LPC Interrupts" described in Section 24.3 of
+ "Loongson 7A1000 Bridge User Manual".
diff --git a/Documentation/m68k/buddha-driver.rst b/Documentation/arch/m68k/buddha-driver.rst
index 20e401413991..5d1bc824978b 100644
--- a/Documentation/m68k/buddha-driver.rst
+++ b/Documentation/arch/m68k/buddha-driver.rst
@@ -173,7 +173,7 @@ When accessing IDE registers with A6=1 (for example $84x),
the timing will always be mode 0 8-bit compatible, no matter
what you have selected in the speed register:
-781ns select, IOR/IOW after 4 clock cycles (=314ns) aktive.
+781ns select, IOR/IOW after 4 clock cycles (=314ns) active.
All the timings with a very short select-signal (the 355ns
fast accesses) depend on the accelerator card used in the
diff --git a/Documentation/arch/m68k/features.rst b/Documentation/arch/m68k/features.rst
new file mode 100644
index 000000000000..de7f0ccf7fc8
--- /dev/null
+++ b/Documentation/arch/m68k/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features m68k
diff --git a/Documentation/m68k/index.rst b/Documentation/arch/m68k/index.rst
index 0f890dbb5fe2..0f890dbb5fe2 100644
--- a/Documentation/m68k/index.rst
+++ b/Documentation/arch/m68k/index.rst
diff --git a/Documentation/m68k/kernel-options.rst b/Documentation/arch/m68k/kernel-options.rst
index 2008a20b4329..2008a20b4329 100644
--- a/Documentation/m68k/kernel-options.rst
+++ b/Documentation/arch/m68k/kernel-options.rst
diff --git a/Documentation/mips/booting.rst b/Documentation/arch/mips/booting.rst
index 7c18a4eab48b..7c18a4eab48b 100644
--- a/Documentation/mips/booting.rst
+++ b/Documentation/arch/mips/booting.rst
diff --git a/Documentation/arch/mips/features.rst b/Documentation/arch/mips/features.rst
new file mode 100644
index 000000000000..6e0ffe3e7354
--- /dev/null
+++ b/Documentation/arch/mips/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features mips
diff --git a/Documentation/mips/index.rst b/Documentation/arch/mips/index.rst
index 037f85a08fe3..037f85a08fe3 100644
--- a/Documentation/mips/index.rst
+++ b/Documentation/arch/mips/index.rst
diff --git a/Documentation/mips/ingenic-tcu.rst b/Documentation/arch/mips/ingenic-tcu.rst
index 2ce4cb1314dc..2ce4cb1314dc 100644
--- a/Documentation/mips/ingenic-tcu.rst
+++ b/Documentation/arch/mips/ingenic-tcu.rst
diff --git a/Documentation/arch/nios2/features.rst b/Documentation/arch/nios2/features.rst
new file mode 100644
index 000000000000..89913810ccb5
--- /dev/null
+++ b/Documentation/arch/nios2/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features nios2
diff --git a/Documentation/nios2/index.rst b/Documentation/arch/nios2/index.rst
index 4468fe1a1037..4468fe1a1037 100644
--- a/Documentation/nios2/index.rst
+++ b/Documentation/arch/nios2/index.rst
diff --git a/Documentation/nios2/nios2.rst b/Documentation/arch/nios2/nios2.rst
index 43da3f7cee76..43da3f7cee76 100644
--- a/Documentation/nios2/nios2.rst
+++ b/Documentation/arch/nios2/nios2.rst
diff --git a/Documentation/arch/openrisc/features.rst b/Documentation/arch/openrisc/features.rst
new file mode 100644
index 000000000000..bae2e25adfd6
--- /dev/null
+++ b/Documentation/arch/openrisc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features openrisc
diff --git a/Documentation/openrisc/index.rst b/Documentation/arch/openrisc/index.rst
index 6879f998b87a..6879f998b87a 100644
--- a/Documentation/openrisc/index.rst
+++ b/Documentation/arch/openrisc/index.rst
diff --git a/Documentation/arch/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst
new file mode 100644
index 000000000000..60b0a9e51d70
--- /dev/null
+++ b/Documentation/arch/openrisc/openrisc_port.rst
@@ -0,0 +1,127 @@
+==============
+OpenRISC Linux
+==============
+
+This is a port of Linux to the OpenRISC class of microprocessors; the initial
+target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k).
+
+For information about OpenRISC processors and ongoing development:
+
+ ======= ==============================
+ website https://openrisc.io
+ email linux-openrisc@vger.kernel.org
+ ======= ==============================
+
+---------------------------------------------------------------------
+
+Build instructions for OpenRISC toolchain and Linux
+===================================================
+
+In order to build and run Linux for OpenRISC, you'll need at least a basic
+toolchain and, perhaps, the architectural simulator. Steps to get these bits
+in place are outlined here.
+
+1) Toolchain
+
+Toolchain binaries can be obtained from openrisc.io or our github releases page.
+Instructions for building the different toolchains can be found on openrisc.io
+or Stafford's toolchain build and release scripts.
+
+ ========== ==========================================================
+ binaries https://github.com/stffrdhrn/or1k-toolchain-build/releases
+ toolchains https://openrisc.io/software
+ building https://github.com/stffrdhrn/or1k-toolchain-build
+ ========== ==========================================================
+
+2) Building
+
+Build the Linux kernel as usual::
+
+ make ARCH=openrisc CROSS_COMPILE="or1k-linux-" defconfig
+ make ARCH=openrisc CROSS_COMPILE="or1k-linux-"
+
+If you want to embed initramfs in the kernel, also pass ``CONFIG_INITRAMFS_SOURCE``. For example::
+
+ make ARCH=openrisc CROSS_COMPILE="or1k-linux-" CONFIG_INITRAMFS_SOURCE="path/to/rootfs path/to/devnodes"
+
+For more information on this, please check Documentation/filesystems/ramfs-rootfs-initramfs.rst.
+
+3) Running on FPGA (optional)
+
+The OpenRISC community typically uses FuseSoC to manage building and programming
+an SoC into an FPGA. The below is an example of programming a De0 Nano
+development board with the OpenRISC SoC. During the build FPGA RTL is code
+downloaded from the FuseSoC IP cores repository and built using the FPGA vendor
+tools. Binaries are loaded onto the board with openocd.
+
+::
+
+ git clone https://github.com/olofk/fusesoc
+ cd fusesoc
+ sudo pip install -e .
+
+ fusesoc init
+ fusesoc build de0_nano
+ fusesoc pgm de0_nano
+
+ openocd -f interface/altera-usb-blaster.cfg \
+ -f board/or1k_generic.cfg
+
+ telnet localhost 4444
+ > init
+ > halt; load_image vmlinux ; reset
+
+4) Running on a Simulator (optional)
+
+QEMU is a processor emulator which we recommend for simulating the OpenRISC
+platform. Please follow the OpenRISC instructions on the QEMU website to get
+Linux running on QEMU. You can build QEMU yourself, but your Linux distribution
+likely provides binary packages to support OpenRISC.
+
+ ============= ======================================================
+ qemu openrisc https://wiki.qemu.org/Documentation/Platforms/OpenRISC
+ ============= ======================================================
+
+---------------------------------------------------------------------
+
+Terminology
+===========
+
+In the code, the following particles are used on symbols to limit the scope
+to more or less specific processor implementations:
+
+========= =======================================
+openrisc: the OpenRISC class of processors
+or1k: the OpenRISC 1000 family of processors
+or1200: the OpenRISC 1200 processor
+========= =======================================
+
+---------------------------------------------------------------------
+
+History
+========
+
+18-11-2003 Matjaz Breskvar (phoenix@bsemi.com)
+ initial port of linux to OpenRISC/or32 architecture.
+ all the core stuff is implemented and seams usable.
+
+08-12-2003 Matjaz Breskvar (phoenix@bsemi.com)
+ complete change of TLB miss handling.
+ rewrite of exceptions handling.
+ fully functional sash-3.6 in default initrd.
+ a much improved version with changes all around.
+
+10-04-2004 Matjaz Breskvar (phoenix@bsemi.com)
+ a lot of bugfixes all over.
+ ethernet support, functional http and telnet servers.
+ running many standard linux apps.
+
+26-06-2004 Matjaz Breskvar (phoenix@bsemi.com)
+ port to 2.6.x
+
+30-11-2004 Matjaz Breskvar (phoenix@bsemi.com)
+ lots of bugfixes and enhancements.
+ added opencores framebuffer driver.
+
+09-10-2010 Jonas Bonn (jonas@southpole.se)
+ major rewrite to bring up to par with upstream Linux 2.6.36
diff --git a/Documentation/openrisc/todo.rst b/Documentation/arch/openrisc/todo.rst
index 420b18b87eda..420b18b87eda 100644
--- a/Documentation/openrisc/todo.rst
+++ b/Documentation/arch/openrisc/todo.rst
diff --git a/Documentation/parisc/debugging.rst b/Documentation/arch/parisc/debugging.rst
index de1b60402c5b..de1b60402c5b 100644
--- a/Documentation/parisc/debugging.rst
+++ b/Documentation/arch/parisc/debugging.rst
diff --git a/Documentation/arch/parisc/features.rst b/Documentation/arch/parisc/features.rst
new file mode 100644
index 000000000000..b3aa4d243b93
--- /dev/null
+++ b/Documentation/arch/parisc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features parisc
diff --git a/Documentation/parisc/index.rst b/Documentation/arch/parisc/index.rst
index 240685751825..240685751825 100644
--- a/Documentation/parisc/index.rst
+++ b/Documentation/arch/parisc/index.rst
diff --git a/Documentation/parisc/registers.rst b/Documentation/arch/parisc/registers.rst
index 59c8ecf3e856..59c8ecf3e856 100644
--- a/Documentation/parisc/registers.rst
+++ b/Documentation/arch/parisc/registers.rst
diff --git a/Documentation/powerpc/associativity.rst b/Documentation/arch/powerpc/associativity.rst
index 4d01c7368561..4d01c7368561 100644
--- a/Documentation/powerpc/associativity.rst
+++ b/Documentation/arch/powerpc/associativity.rst
diff --git a/Documentation/arch/powerpc/booting.rst b/Documentation/arch/powerpc/booting.rst
new file mode 100644
index 000000000000..472e97891aef
--- /dev/null
+++ b/Documentation/arch/powerpc/booting.rst
@@ -0,0 +1,110 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+DeviceTree Booting
+------------------
+
+During the development of the Linux/ppc64 kernel, and more specifically, the
+addition of new platform types outside of the old IBM pSeries/iSeries pair, it
+was decided to enforce some strict rules regarding the kernel entry and
+bootloader <-> kernel interfaces, in order to avoid the degeneration that had
+become the ppc32 kernel entry point and the way a new platform should be added
+to the kernel. The legacy iSeries platform breaks those rules as it predates
+this scheme, but no new board support will be accepted in the main tree that
+doesn't follow them properly. In addition, since the advent of the arch/powerpc
+merged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bit
+platforms which move into arch/powerpc will be required to use these rules as
+well.
+
+The main requirement that will be defined in more detail below is the presence
+of a device-tree whose format is defined after Open Firmware specification.
+However, in order to make life easier to embedded board vendors, the kernel
+doesn't require the device-tree to represent every device in the system and only
+requires some nodes and properties to be present. For example, the kernel does
+not require you to create a node for every PCI device in the system. It is a
+requirement to have a node for PCI host bridges in order to provide interrupt
+routing information and memory/IO ranges, among others. It is also recommended
+to define nodes for on chip devices and other buses that don't specifically fit
+in an existing OF specification. This creates a great flexibility in the way the
+kernel can then probe those and match drivers to device, without having to hard
+code all sorts of tables. It also makes it more flexible for board vendors to do
+minor hardware upgrades without significantly impacting the kernel code or
+cluttering it with special cases.
+
+
+Entry point
+~~~~~~~~~~~
+
+There is one single entry point to the kernel, at the start
+of the kernel image. That entry point supports two calling
+conventions:
+
+ a) Boot from Open Firmware. If your firmware is compatible
+ with Open Firmware (IEEE 1275) or provides an OF compatible
+ client interface API (support for "interpret" callback of
+ forth words isn't required), you can enter the kernel with:
+
+ r5 : OF callback pointer as defined by IEEE 1275
+ bindings to powerpc. Only the 32-bit client interface
+ is currently supported
+
+ r3, r4 : address & length of an initrd if any or 0
+
+ The MMU is either on or off; the kernel will run the
+ trampoline located in arch/powerpc/kernel/prom_init.c to
+ extract the device-tree and other information from open
+ firmware and build a flattened device-tree as described
+ in b). prom_init() will then re-enter the kernel using
+ the second method. This trampoline code runs in the
+ context of the firmware, which is supposed to handle all
+ exceptions during that time.
+
+ b) Direct entry with a flattened device-tree block. This entry
+ point is called by a) after the OF trampoline and can also be
+ called directly by a bootloader that does not support the Open
+ Firmware client interface. It is also used by "kexec" to
+ implement "hot" booting of a new kernel from a previous
+ running one. This method is what I will describe in more
+ details in this document, as method a) is simply standard Open
+ Firmware, and thus should be implemented according to the
+ various standard documents defining it and its binding to the
+ PowerPC platform. The entry point definition then becomes:
+
+ r3 : physical pointer to the device-tree block
+ (defined in chapter II) in RAM
+
+ r4 : physical pointer to the kernel itself. This is
+ used by the assembly code to properly disable the MMU
+ in case you are entering the kernel with MMU enabled
+ and a non-1:1 mapping.
+
+ r5 : NULL (as to differentiate with method a)
+
+Note about SMP entry: Either your firmware puts your other
+CPUs in some sleep loop or spin loop in ROM where you can get
+them out via a soft reset or some other means, in which case
+you don't need to care, or you'll have to enter the kernel
+with all CPUs. The way to do that with method b) will be
+described in a later revision of this document.
+
+Board supports (platforms) are not exclusive config options. An
+arbitrary set of board supports can be built in a single kernel
+image. The kernel will "know" what set of functions to use for a
+given platform based on the content of the device-tree. Thus, you
+should:
+
+ a) add your platform support as a _boolean_ option in
+ arch/powerpc/Kconfig, following the example of PPC_PSERIES
+ and PPC_PMAC. The latter is probably a good
+ example of a board support to start from.
+
+ b) create your main platform file as
+ "arch/powerpc/platforms/myplatform/myboard_setup.c" and add it
+ to the Makefile under the condition of your ``CONFIG_``
+ option. This file will define a structure of type "ppc_md"
+ containing the various callbacks that the generic code will
+ use to get to your platform specific code
+
+A kernel image may support multiple platforms, but only if the
+platforms feature the same core architecture. A single kernel build
+cannot support both configurations with Book E and configurations
+with classic Powerpc architectures.
diff --git a/Documentation/powerpc/bootwrapper.rst b/Documentation/arch/powerpc/bootwrapper.rst
index cdfa2bc8425f..cdfa2bc8425f 100644
--- a/Documentation/powerpc/bootwrapper.rst
+++ b/Documentation/arch/powerpc/bootwrapper.rst
diff --git a/Documentation/powerpc/cpu_families.rst b/Documentation/arch/powerpc/cpu_families.rst
index 9b84e045e713..f55433c6b8f3 100644
--- a/Documentation/powerpc/cpu_families.rst
+++ b/Documentation/arch/powerpc/cpu_families.rst
@@ -10,6 +10,7 @@ Book3S (aka sPAPR)
------------------
- Hash MMU (except 603 and e300)
+- Radix MMU (POWER9 and later)
- Software loaded TLB (603 and e300)
- Selectable Software loaded TLB in addition to hash MMU (755, 7450, e600)
- Mix of 32 & 64 bit::
@@ -101,6 +102,18 @@ Book3S (aka sPAPR)
+--------------+
| POWER8 |
+--------------+
+ |
+ |
+ v
+ +--------------+
+ | POWER9 |
+ +--------------+
+ |
+ |
+ v
+ +--------------+
+ | POWER10 |
+ +--------------+
+---------------+
@@ -115,24 +128,6 @@ IBM BookE
- All 32 bit::
+--------------+
- | 401 |
- +--------------+
- |
- |
- v
- +--------------+
- | 403 |
- +--------------+
- |
- |
- v
- +--------------+
- | 405 |
- +--------------+
- |
- |
- v
- +--------------+
| 440 |
+--------------+
|
diff --git a/Documentation/powerpc/cpu_features.rst b/Documentation/arch/powerpc/cpu_features.rst
index b7bcdd2f41bb..b7bcdd2f41bb 100644
--- a/Documentation/powerpc/cpu_features.rst
+++ b/Documentation/arch/powerpc/cpu_features.rst
diff --git a/Documentation/powerpc/dawr-power9.rst b/Documentation/arch/powerpc/dawr-power9.rst
index 310f2e0cea81..310f2e0cea81 100644
--- a/Documentation/powerpc/dawr-power9.rst
+++ b/Documentation/arch/powerpc/dawr-power9.rst
diff --git a/Documentation/arch/powerpc/dexcr.rst b/Documentation/arch/powerpc/dexcr.rst
new file mode 100644
index 000000000000..ab0724212fcd
--- /dev/null
+++ b/Documentation/arch/powerpc/dexcr.rst
@@ -0,0 +1,195 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================================
+DEXCR (Dynamic Execution Control Register)
+==========================================
+
+Overview
+========
+
+The DEXCR is a privileged special purpose register (SPR) introduced in
+PowerPC ISA 3.1B (Power10) that allows per-cpu control over several dynamic
+execution behaviours. These behaviours include speculation (e.g., indirect
+branch target prediction) and enabling return-oriented programming (ROP)
+protection instructions.
+
+The execution control is exposed in hardware as up to 32 bits ('aspects') in
+the DEXCR. Each aspect controls a certain behaviour, and can be set or cleared
+to enable/disable the aspect. There are several variants of the DEXCR for
+different purposes:
+
+DEXCR
+ A privileged SPR that can control aspects for userspace and kernel space
+HDEXCR
+ A hypervisor-privileged SPR that can control aspects for the hypervisor and
+ enforce aspects for the kernel and userspace.
+UDEXCR
+ An optional ultravisor-privileged SPR that can control aspects for the ultravisor.
+
+Userspace can examine the current DEXCR state using a dedicated SPR that
+provides a non-privileged read-only view of the userspace DEXCR aspects.
+There is also an SPR that provides a read-only view of the hypervisor enforced
+aspects, which ORed with the userspace DEXCR view gives the effective DEXCR
+state for a process.
+
+
+Configuration
+=============
+
+prctl
+-----
+
+A process can control its own userspace DEXCR value using the
+``PR_PPC_GET_DEXCR`` and ``PR_PPC_SET_DEXCR`` pair of
+:manpage:`prctl(2)` commands. These calls have the form::
+
+ prctl(PR_PPC_GET_DEXCR, unsigned long which, 0, 0, 0);
+ prctl(PR_PPC_SET_DEXCR, unsigned long which, unsigned long ctrl, 0, 0);
+
+The possible 'which' and 'ctrl' values are as follows. Note there is no relation
+between the 'which' value and the DEXCR aspect's index.
+
+.. flat-table::
+ :header-rows: 1
+ :widths: 2 7 1
+
+ * - ``prctl()`` which
+ - Aspect name
+ - Aspect index
+
+ * - ``PR_PPC_DEXCR_SBHE``
+ - Speculative Branch Hint Enable (SBHE)
+ - 0
+
+ * - ``PR_PPC_DEXCR_IBRTPD``
+ - Indirect Branch Recurrent Target Prediction Disable (IBRTPD)
+ - 3
+
+ * - ``PR_PPC_DEXCR_SRAPD``
+ - Subroutine Return Address Prediction Disable (SRAPD)
+ - 4
+
+ * - ``PR_PPC_DEXCR_NPHIE``
+ - Non-Privileged Hash Instruction Enable (NPHIE)
+ - 5
+
+.. flat-table::
+ :header-rows: 1
+ :widths: 2 8
+
+ * - ``prctl()`` ctrl
+ - Meaning
+
+ * - ``PR_PPC_DEXCR_CTRL_EDITABLE``
+ - This aspect can be configured with PR_PPC_SET_DEXCR (get only)
+
+ * - ``PR_PPC_DEXCR_CTRL_SET``
+ - This aspect is set / set this aspect
+
+ * - ``PR_PPC_DEXCR_CTRL_CLEAR``
+ - This aspect is clear / clear this aspect
+
+ * - ``PR_PPC_DEXCR_CTRL_SET_ONEXEC``
+ - This aspect will be set after exec / set this aspect after exec
+
+ * - ``PR_PPC_DEXCR_CTRL_CLEAR_ONEXEC``
+ - This aspect will be clear after exec / clear this aspect after exec
+
+Note that
+
+* which is a plain value, not a bitmask. Aspects must be worked with individually.
+
+* ctrl is a bitmask. ``PR_PPC_GET_DEXCR`` returns both the current and onexec
+ configuration. For example, ``PR_PPC_GET_DEXCR`` may return
+ ``PR_PPC_DEXCR_CTRL_EDITABLE | PR_PPC_DEXCR_CTRL_SET |
+ PR_PPC_DEXCR_CTRL_CLEAR_ONEXEC``. This would indicate the aspect is currently
+ set, it will be cleared when you run exec, and you can change this with the
+ ``PR_PPC_SET_DEXCR`` prctl.
+
+* The set/clear terminology refers to setting/clearing the bit in the DEXCR.
+ For example::
+
+ prctl(PR_PPC_SET_DEXCR, PR_PPC_DEXCR_IBRTPD, PR_PPC_DEXCR_CTRL_SET, 0, 0);
+
+ will set the IBRTPD aspect bit in the DEXCR, causing indirect branch prediction
+ to be disabled.
+
+* The status returned by ``PR_PPC_GET_DEXCR`` represents what value the process
+ would like applied. It does not include any alternative overrides, such as if
+ the hypervisor is enforcing the aspect be set. To see the true DEXCR state
+ software should read the appropriate SPRs directly.
+
+* The aspect state when starting a process is copied from the parent's state on
+ :manpage:`fork(2)`. The state is reset to a fixed value on
+ :manpage:`execve(2)`. The PR_PPC_SET_DEXCR prctl() can control both of these
+ values.
+
+* The ``*_ONEXEC`` controls do not change the current process's DEXCR.
+
+Use ``PR_PPC_SET_DEXCR`` with one of ``PR_PPC_DEXCR_CTRL_SET`` or
+``PR_PPC_DEXCR_CTRL_CLEAR`` to edit a given aspect.
+
+Common error codes for both getting and setting the DEXCR are as follows:
+
+.. flat-table::
+ :header-rows: 1
+ :widths: 2 8
+
+ * - Error
+ - Meaning
+
+ * - ``EINVAL``
+ - The DEXCR is not supported by the kernel.
+
+ * - ``ENODEV``
+ - The aspect is not recognised by the kernel or not supported by the
+ hardware.
+
+``PR_PPC_SET_DEXCR`` may also report the following error codes:
+
+.. flat-table::
+ :header-rows: 1
+ :widths: 2 8
+
+ * - Error
+ - Meaning
+
+ * - ``EINVAL``
+ - The ctrl value contains unrecognised flags.
+
+ * - ``EINVAL``
+ - The ctrl value contains mutually conflicting flags (e.g.,
+ ``PR_PPC_DEXCR_CTRL_SET | PR_PPC_DEXCR_CTRL_CLEAR``)
+
+ * - ``EPERM``
+ - This aspect cannot be modified with prctl() (check for the
+ PR_PPC_DEXCR_CTRL_EDITABLE flag with PR_PPC_GET_DEXCR).
+
+ * - ``EPERM``
+ - The process does not have sufficient privilege to perform the operation.
+ For example, clearing NPHIE on exec is a privileged operation (a process
+ can still clear its own NPHIE aspect without privileges).
+
+This interface allows a process to control its own DEXCR aspects, and also set
+the initial DEXCR value for any children in its process tree (up to the next
+child to use an ``*_ONEXEC`` control). This allows fine-grained control over the
+default value of the DEXCR, for example allowing containers to run with different
+default values.
+
+
+coredump and ptrace
+===================
+
+The userspace values of the DEXCR and HDEXCR (in this order) are exposed under
+``NT_PPC_DEXCR``. These are each 64 bits and readonly, and are intended to
+assist with core dumps. The DEXCR may be made writable in future. The top 32
+bits of both registers (corresponding to the non-userspace bits) are masked off.
+
+If the kernel config ``CONFIG_CHECKPOINT_RESTORE`` is enabled, then
+``NT_PPC_HASHKEYR`` is available and exposes the HASHKEYR value of the process
+for reading and writing. This is a tradeoff between increased security and
+checkpoint/restore support: a process should normally have no need to know its
+secret key, but restoring a process requires setting its original key. The key
+therefore appears in core dumps, and an attacker may be able to retrieve it from
+a coredump and effectively bypass ROP protection on any threads that share this
+key (potentially all threads from the same parent that have not run ``exec()``).
diff --git a/Documentation/powerpc/dscr.rst b/Documentation/arch/powerpc/dscr.rst
index 2ab99006014c..f735ec5375d5 100644
--- a/Documentation/powerpc/dscr.rst
+++ b/Documentation/arch/powerpc/dscr.rst
@@ -6,7 +6,7 @@ DSCR register in powerpc allows user to have some control of prefetch of data
stream in the processor. Please refer to the ISA documents or related manual
for more detailed information regarding how to use this DSCR to attain this
control of the prefetches . This document here provides an overview of kernel
-support for DSCR, related kernel objects, it's functionalities and exported
+support for DSCR, related kernel objects, its functionalities and exported
user interface.
(A) Data Structures:
diff --git a/Documentation/powerpc/eeh-pci-error-recovery.rst b/Documentation/arch/powerpc/eeh-pci-error-recovery.rst
index d6643a91bdf8..153d0af055b6 100644
--- a/Documentation/powerpc/eeh-pci-error-recovery.rst
+++ b/Documentation/arch/powerpc/eeh-pci-error-recovery.rst
@@ -315,7 +315,6 @@ network daemons and file systems that didn't need to be disturbed.
ideally, the reset should happen at or below the block layer,
so that the file systems are not disturbed.
- Reiserfs does not tolerate errors returned from the block device.
Ext3fs seems to be tolerant, retrying reads/writes until it does
succeed. Both have been only lightly tested in this scenario.
diff --git a/Documentation/arch/powerpc/elf_hwcaps.rst b/Documentation/arch/powerpc/elf_hwcaps.rst
new file mode 100644
index 000000000000..fce7489877b5
--- /dev/null
+++ b/Documentation/arch/powerpc/elf_hwcaps.rst
@@ -0,0 +1,232 @@
+.. _elf_hwcaps_powerpc:
+
+==================
+POWERPC ELF HWCAPs
+==================
+
+This document describes the usage and semantics of the powerpc ELF HWCAPs.
+
+
+1. Introduction
+---------------
+
+Some hardware or software features are only available on some CPU
+implementations, and/or with certain kernel configurations, but have no other
+discovery mechanism available to userspace code. The kernel exposes the
+presence of these features to userspace through a set of flags called HWCAPs,
+exposed in the auxiliary vector.
+
+Userspace software can test for features by acquiring the AT_HWCAP or
+AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
+flags are set, e.g.::
+
+ bool floating_point_is_present(void)
+ {
+ unsigned long HWCAPs = getauxval(AT_HWCAP);
+ if (HWCAPs & PPC_FEATURE_HAS_FPU)
+ return true;
+
+ return false;
+ }
+
+Where software relies on a feature described by a HWCAP, it should check the
+relevant HWCAP flag to verify that the feature is present before attempting to
+make use of the feature.
+
+HWCAP is the preferred method to test for the presence of a feature rather
+than probing through other means, which may not be reliable or may cause
+unpredictable behaviour.
+
+Software that targets a particular platform does not necessarily have to
+test for required or implied features. For example if the program requires
+FPU, VMX, VSX, it is not necessary to test those HWCAPs, and it may be
+impossible to do so if the compiler generates code requiring those features.
+
+2. Facilities
+-------------
+
+The Power ISA uses the term "facility" to describe a class of instructions,
+registers, interrupts, etc. The presence or absence of a facility indicates
+whether this class is available to be used, but the specifics depend on the
+ISA version. For example, if the VSX facility is available, the VSX
+instructions that can be used differ between the v3.0B and v3.1B ISA
+versions.
+
+3. Categories
+-------------
+
+The Power ISA before v3.0 uses the term "category" to describe certain
+classes of instructions and operating modes which may be optional or
+mutually exclusive, the exact meaning of the HWCAP flag may depend on
+context, e.g., the presence of the BOOKE feature implies that the server
+category is not implemented.
+
+4. HWCAP allocation
+-------------------
+
+HWCAPs are allocated as described in Power Architecture 64-Bit ELF V2 ABI
+Specification (which will be reflected in the kernel's uapi headers).
+
+5. The HWCAPs exposed in AT_HWCAP
+---------------------------------
+
+PPC_FEATURE_32
+ 32-bit CPU
+
+PPC_FEATURE_64
+ 64-bit CPU (userspace may be running in 32-bit mode).
+
+PPC_FEATURE_601_INSTR
+ The processor is PowerPC 601.
+ Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
+
+PPC_FEATURE_HAS_ALTIVEC
+ Vector (aka Altivec, VMX) facility is available.
+
+PPC_FEATURE_HAS_FPU
+ Floating point facility is available.
+
+PPC_FEATURE_HAS_MMU
+ Memory management unit is present and enabled.
+
+PPC_FEATURE_HAS_4xxMAC
+ The processor is 40x or 44x family.
+ Unused in the kernel since 732b32daef80 ("powerpc: Remove core support for 40x")
+
+PPC_FEATURE_UNIFIED_CACHE
+ The processor has a unified L1 cache for instructions and data, as
+ found in NXP e200.
+ Unused in the kernel since 39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)")
+
+PPC_FEATURE_HAS_SPE
+ Signal Processing Engine facility is available.
+
+PPC_FEATURE_HAS_EFP_SINGLE
+ Embedded Floating Point single precision operations are available.
+
+PPC_FEATURE_HAS_EFP_DOUBLE
+ Embedded Floating Point double precision operations are available.
+
+PPC_FEATURE_NO_TB
+ The timebase facility (mftb instruction) is not available.
+ This is a 601 specific HWCAP, so if it is known that the processor
+ running is not a 601, via other HWCAPs or other means, it is not
+ required to test this bit before using the timebase.
+ Unused in the kernel since f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
+
+PPC_FEATURE_POWER4
+ The processor is POWER4 or PPC970/FX/MP.
+ POWER4 support dropped from the kernel since 471d7ff8b51b ("powerpc/64s: Remove POWER4 support")
+
+PPC_FEATURE_POWER5
+ The processor is POWER5.
+
+PPC_FEATURE_POWER5_PLUS
+ The processor is POWER5+.
+
+PPC_FEATURE_CELL
+ The processor is Cell.
+
+PPC_FEATURE_BOOKE
+ The processor implements the embedded category ("BookE") architecture.
+
+PPC_FEATURE_SMT
+ The processor implements SMT.
+
+PPC_FEATURE_ICACHE_SNOOP
+ The processor icache is coherent with the dcache, and instruction storage
+ can be made consistent with data storage for the purpose of executing
+ instructions with the sequence (as described in, e.g., POWER9 Processor
+ User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi))::
+
+ sync
+ icbi (to any address)
+ isync
+
+PPC_FEATURE_ARCH_2_05
+ The processor supports the v2.05 userlevel architecture. Processors
+ supporting later architectures DO NOT set this feature.
+
+PPC_FEATURE_PA6T
+ The processor is PA6T.
+
+PPC_FEATURE_HAS_DFP
+ DFP facility is available.
+
+PPC_FEATURE_POWER6_EXT
+ The processor is POWER6.
+
+PPC_FEATURE_ARCH_2_06
+ The processor supports the v2.06 userlevel architecture. Processors
+ supporting later architectures also set this feature.
+
+PPC_FEATURE_HAS_VSX
+ VSX facility is available.
+
+PPC_FEATURE_PSERIES_PERFMON_COMPAT
+ The processor supports architected PMU events in the range 0xE0-0xFF.
+
+PPC_FEATURE_TRUE_LE
+ The processor supports true little-endian mode.
+
+PPC_FEATURE_PPC_LE
+ The processor supports "PowerPC Little-Endian", that uses address
+ munging to make storage access appear to be little-endian, but the
+ data is stored in a different format that is unsuitable to be
+ accessed by other agents not running in this mode.
+
+6. The HWCAPs exposed in AT_HWCAP2
+----------------------------------
+
+PPC_FEATURE2_ARCH_2_07
+ The processor supports the v2.07 userlevel architecture. Processors
+ supporting later architectures also set this feature.
+
+PPC_FEATURE2_HTM
+ Transactional Memory feature is available.
+
+PPC_FEATURE2_DSCR
+ DSCR facility is available.
+
+PPC_FEATURE2_EBB
+ EBB facility is available.
+
+PPC_FEATURE2_ISEL
+ isel instruction is available. This is superseded by ARCH_2_07 and
+ later.
+
+PPC_FEATURE2_TAR
+ TAR facility is available.
+
+PPC_FEATURE2_VEC_CRYPTO
+ v2.07 crypto instructions are available.
+
+PPC_FEATURE2_HTM_NOSC
+ System calls fail if called in a transactional state, see
+ Documentation/arch/powerpc/syscall64-abi.rst
+
+PPC_FEATURE2_ARCH_3_00
+ The processor supports the v3.0B / v3.0C userlevel architecture. Processors
+ supporting later architectures also set this feature.
+
+PPC_FEATURE2_HAS_IEEE128
+ IEEE 128-bit binary floating point is supported with VSX
+ quad-precision instructions and data types.
+
+PPC_FEATURE2_DARN
+ darn instruction is available.
+
+PPC_FEATURE2_SCV
+ The scv 0 instruction may be used for system calls, see
+ Documentation/arch/powerpc/syscall64-abi.rst.
+
+PPC_FEATURE2_HTM_NO_SUSPEND
+ A limited Transactional Memory facility that does not support suspend is
+ available, see Documentation/arch/powerpc/transactional_memory.rst.
+
+PPC_FEATURE2_ARCH_3_1
+ The processor supports the v3.1 userlevel architecture. Processors
+ supporting later architectures also set this feature.
+
+PPC_FEATURE2_MMA
+ MMA facility is available.
diff --git a/Documentation/powerpc/elfnote.rst b/Documentation/arch/powerpc/elfnote.rst
index 3ec8d61e9a33..3ec8d61e9a33 100644
--- a/Documentation/powerpc/elfnote.rst
+++ b/Documentation/arch/powerpc/elfnote.rst
diff --git a/Documentation/arch/powerpc/features.rst b/Documentation/arch/powerpc/features.rst
new file mode 100644
index 000000000000..ee4b95e04202
--- /dev/null
+++ b/Documentation/arch/powerpc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features powerpc
diff --git a/Documentation/powerpc/firmware-assisted-dump.rst b/Documentation/arch/powerpc/firmware-assisted-dump.rst
index e363fc48529a..7e266e749cd5 100644
--- a/Documentation/powerpc/firmware-assisted-dump.rst
+++ b/Documentation/arch/powerpc/firmware-assisted-dump.rst
@@ -120,6 +120,28 @@ to ensure that crash data is preserved to process later.
e.g.
# echo 1 > /sys/firmware/opal/mpipl/release_core
+-- Support for Additional Kernel Arguments in Fadump
+ Fadump has a feature that allows passing additional kernel arguments
+ to the fadump kernel. This feature was primarily designed to disable
+ kernel functionalities that are not required for the fadump kernel
+ and to reduce its memory footprint while collecting the dump.
+
+ Command to Add Additional Kernel Parameters to Fadump:
+ e.g.
+ # echo "nr_cpus=16" > /sys/kernel/fadump/bootargs_append
+
+ The above command is sufficient to add additional arguments to fadump.
+ An explicit service restart is not required.
+
+ Command to Retrieve the Additional Fadump Arguments:
+ e.g.
+ # cat /sys/kernel/fadump/bootargs_append
+
+Note: Additional kernel arguments for fadump with HASH MMU is only
+ supported if the RMA size is greater than 768 MB. If the RMA
+ size is less than 768 MB, the kernel does not export the
+ /sys/kernel/fadump/bootargs_append sysfs node.
+
Implementation details:
-----------------------
@@ -134,12 +156,12 @@ that are run. If there is dump data, then the
memory is held.
If there is no waiting dump data, then only the memory required to
-hold CPU state, HPTE region, boot memory dump, FADump header and
-elfcore header, is usually reserved at an offset greater than boot
-memory size (see Fig. 1). This area is *not* released: this region
-will be kept permanently reserved, so that it can act as a receptacle
-for a copy of the boot memory content in addition to CPU state and
-HPTE region, in the case a crash does occur.
+hold CPU state, HPTE region, boot memory dump, and FADump header is
+usually reserved at an offset greater than boot memory size (see Fig. 1).
+This area is *not* released: this region will be kept permanently
+reserved, so that it can act as a receptacle for a copy of the boot
+memory content in addition to CPU state and HPTE region, in the case
+a crash does occur.
Since this reserved memory area is used only after the system crash,
there is no point in blocking this significant chunk of memory from
@@ -153,22 +175,22 @@ that were present in CMA region::
o Memory Reservation during first kernel
- Low memory Top of memory
- 0 boot memory size |<--- Reserved dump area --->| |
- | | | Permanent Reservation | |
- V V | | V
- +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
- | | |///|////| DUMP | HDR | ELF |////| |
- +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
- | ^ ^ ^ ^ ^
- | | | | | |
- \ CPU HPTE / | |
- ------------------------------ | |
- Boot memory content gets transferred | |
- to reserved area by firmware at the | |
- time of crash. | |
- FADump Header |
- (meta area) |
+ Low memory Top of memory
+ 0 boot memory size |<------ Reserved dump area ----->| |
+ | | | Permanent Reservation | |
+ V V | | V
+ +-----------+-----/ /---+---+----+-----------+-------+----+-----+
+ | | |///|////| DUMP | HDR |////| |
+ +-----------+-----/ /---+---+----+-----------+-------+----+-----+
+ | ^ ^ ^ ^ ^
+ | | | | | |
+ \ CPU HPTE / | |
+ -------------------------------- | |
+ Boot memory content gets transferred | |
+ to reserved area by firmware at the | |
+ time of crash. | |
+ FADump Header |
+ (meta area) |
|
|
Metadata: This area holds a metadata structure whose
@@ -186,13 +208,20 @@ that were present in CMA region::
0 boot memory size |
| |<------------ Crash preserved area ------------>|
V V |<--- Reserved dump area --->| |
- +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
- | | |///|////| DUMP | HDR | ELF |////| |
- +-----------+-----/ /---+---+----+-------+-----+-----+----+--+
- | |
- V V
- Used by second /proc/vmcore
- kernel to boot
+ +----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
+ | |ELF| | |///|////| DUMP | HDR |/////| |
+ +----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
+ | | | | | |
+ ----- ------------------------------ ---------------
+ \ | |
+ \ | |
+ \ | |
+ \ | ----------------------------
+ \ | /
+ \ | /
+ \ | /
+ /proc/vmcore
+
+---+
|///| -> Regions (CPU, HPTE & Metadata) marked like this in the above
@@ -200,6 +229,12 @@ that were present in CMA region::
does not have CPU & HPTE regions while Metadata region is
not supported on pSeries currently.
+ +---+
+ |ELF| -> elfcorehdr, it is created in second kernel after crash.
+ +---+
+
+ Note: Memory from 0 to the boot memory size is used by second kernel
+
Fig. 2
@@ -353,26 +388,6 @@ TODO:
- Need to come up with the better approach to find out more
accurate boot memory size that is required for a kernel to
boot successfully when booted with restricted memory.
- - The FADump implementation introduces a FADump crash info structure
- in the scratch area before the ELF core header. The idea of introducing
- this structure is to pass some important crash info data to the second
- kernel which will help second kernel to populate ELF core header with
- correct data before it gets exported through /proc/vmcore. The current
- design implementation does not address a possibility of introducing
- additional fields (in future) to this structure without affecting
- compatibility. Need to come up with the better approach to address this.
-
- The possible approaches are:
-
- 1. Introduce version field for version tracking, bump up the version
- whenever a new field is added to the structure in future. The version
- field can be used to find out what fields are valid for the current
- version of the structure.
- 2. Reserve the area of predefined size (say PAGE_SIZE) for this
- structure and have unused area as reserved (initialized to zero)
- for future field additions.
-
- The advantage of approach 1 over 2 is we don't need to reserve extra space.
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
diff --git a/Documentation/arch/powerpc/htm.rst b/Documentation/arch/powerpc/htm.rst
new file mode 100644
index 000000000000..fcb4eb6306b1
--- /dev/null
+++ b/Documentation/arch/powerpc/htm.rst
@@ -0,0 +1,104 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _htm:
+
+===================================
+HTM (Hardware Trace Macro)
+===================================
+
+Athira Rajeev, 2 Mar 2025
+
+.. contents::
+ :depth: 3
+
+
+Basic overview
+==============
+
+H_HTM is used as an interface for executing Hardware Trace Macro (HTM)
+functions, including setup, configuration, control and dumping of the HTM data.
+For using HTM, it is required to setup HTM buffers and HTM operations can
+be controlled using the H_HTM hcall. The hcall can be invoked for any core/chip
+of the system from within a partition itself. To use this feature, a debugfs
+folder called "htmdump" is present under /sys/kernel/debug/powerpc.
+
+
+HTM debugfs example usage
+=========================
+
+.. code-block:: sh
+
+ # ls /sys/kernel/debug/powerpc/htmdump/
+ coreindexonchip htmcaps htmconfigure htmflags htminfo htmsetup
+ htmstart htmstatus htmtype nodalchipindex nodeindex trace
+
+Details on each file:
+
+* nodeindex, nodalchipindex, coreindexonchip specifies which partition to configure the HTM for.
+* htmtype: specifies the type of HTM. Supported target is hardwareTarget.
+* trace: is to read the HTM data.
+* htmconfigure: Configure/Deconfigure the HTM. Writing 1 to the file will configure the trace, writing 0 to the file will do deconfigure.
+* htmstart: start/Stop the HTM. Writing 1 to the file will start the tracing, writing 0 to the file will stop the tracing.
+* htmstatus: get the status of HTM. This is needed to understand the HTM state after each operation.
+* htmsetup: set the HTM buffer size. Size of HTM buffer is in power of 2
+* htminfo: provides the system processor configuration details. This is needed to understand the appropriate values for nodeindex, nodalchipindex, coreindexonchip.
+* htmcaps : provides the HTM capabilities like minimum/maximum buffer size, what kind of tracing the HTM supports etc.
+* htmflags : allows to pass flags to hcall. Currently supports controlling the wrapping of HTM buffer.
+
+To see the system processor configuration details:
+
+.. code-block:: sh
+
+ # cat /sys/kernel/debug/powerpc/htmdump/htminfo > htminfo_file
+
+The result can be interpreted using hexdump.
+
+To collect HTM traces for a partition represented by nodeindex as
+zero, nodalchipindex as 1 and coreindexonchip as 12
+
+.. code-block:: sh
+
+ # cd /sys/kernel/debug/powerpc/htmdump/
+ # echo 2 > htmtype
+ # echo 33 > htmsetup ( sets 8GB memory for HTM buffer, number is size in power of 2 )
+
+This requires a CEC reboot to get the HTM buffers allocated.
+
+.. code-block:: sh
+
+ # cd /sys/kernel/debug/powerpc/htmdump/
+ # echo 2 > htmtype
+ # echo 0 > nodeindex
+ # echo 1 > nodalchipindex
+ # echo 12 > coreindexonchip
+ # echo 1 > htmflags # to set noWrap for HTM buffers
+ # echo 1 > htmconfigure # Configure the HTM
+ # echo 1 > htmstart # Start the HTM
+ # echo 0 > htmstart # Stop the HTM
+ # echo 0 > htmconfigure # Deconfigure the HTM
+ # cat htmstatus # Dump the status of HTM entries as data
+
+Above will set the htmtype and core details, followed by executing respective HTM operation.
+
+Read the HTM trace data
+========================
+
+After starting the trace collection, run the workload
+of interest. Stop the trace collection after required period
+of time, and read the trace file.
+
+.. code-block:: sh
+
+ # cat /sys/kernel/debug/powerpc/htmdump/trace > trace_file
+
+This trace file will contain the relevant instruction traces
+collected during the workload execution. And can be used as
+input file for trace decoders to understand data.
+
+Benefits of using HTM debugfs interface
+=======================================
+
+It is now possible to collect traces for a particular core/chip
+from within any partition of the system and decode it. Through
+this enablement, a small partition can be dedicated to collect the
+trace data and analyze to provide important information for Performance
+analysis, Software tuning, or Hardware debug.
diff --git a/Documentation/powerpc/hvcs.rst b/Documentation/arch/powerpc/hvcs.rst
index 6808acde672f..6808acde672f 100644
--- a/Documentation/powerpc/hvcs.rst
+++ b/Documentation/arch/powerpc/hvcs.rst
diff --git a/Documentation/powerpc/imc.rst b/Documentation/arch/powerpc/imc.rst
index 633bcee7dc85..633bcee7dc85 100644
--- a/Documentation/powerpc/imc.rst
+++ b/Documentation/arch/powerpc/imc.rst
diff --git a/Documentation/arch/powerpc/index.rst b/Documentation/arch/powerpc/index.rst
new file mode 100644
index 000000000000..1be2ee3f0361
--- /dev/null
+++ b/Documentation/arch/powerpc/index.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======
+powerpc
+=======
+
+.. toctree::
+ :maxdepth: 1
+
+ associativity
+ booting
+ bootwrapper
+ cpu_families
+ cpu_features
+ dawr-power9
+ dexcr
+ dscr
+ eeh-pci-error-recovery
+ elf_hwcaps
+ elfnote
+ firmware-assisted-dump
+ htm
+ hvcs
+ imc
+ isa-versions
+ kaslr-booke32
+ mpc52xx
+ kvm-nested
+ papr_hcalls
+ pci_iov_resource_on_powernv
+ pmu-ebb
+ ptrace
+ qe_firmware
+ syscall64-abi
+ transactional_memory
+ ultravisor
+ vas-api
+ vcpudispatch_stats
+ vmemmap_dedup
+ vpa-dtl
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arch/powerpc/isa-versions.rst b/Documentation/arch/powerpc/isa-versions.rst
new file mode 100644
index 000000000000..a8d6b6028b3e
--- /dev/null
+++ b/Documentation/arch/powerpc/isa-versions.rst
@@ -0,0 +1,101 @@
+==========================
+CPU to ISA Version Mapping
+==========================
+
+Mapping of some CPU versions to relevant ISA versions.
+
+Note Power4 and Power4+ are not supported.
+
+========= ====================================================================
+CPU Architecture version
+========= ====================================================================
+Power10 Power ISA v3.1
+Power9 Power ISA v3.0B
+Power8 Power ISA v2.07
+e6500 Power ISA v2.06 with some exceptions
+e5500 Power ISA v2.06 with some exceptions, no Altivec
+Power7 Power ISA v2.06
+Power6 Power ISA v2.05
+PA6T Power ISA v2.04
+Cell PPU - Power ISA v2.02 with some minor exceptions
+ - Plus Altivec/VMX ~= 2.03
+Power5++ Power ISA v2.04 (no VMX)
+Power5+ Power ISA v2.03
+Power5 - PowerPC User Instruction Set Architecture Book I v2.02
+ - PowerPC Virtual Environment Architecture Book II v2.02
+ - PowerPC Operating Environment Architecture Book III v2.02
+PPC970 - PowerPC User Instruction Set Architecture Book I v2.01
+ - PowerPC Virtual Environment Architecture Book II v2.01
+ - PowerPC Operating Environment Architecture Book III v2.01
+ - Plus Altivec/VMX ~= 2.03
+Power4+ - PowerPC User Instruction Set Architecture Book I v2.01
+ - PowerPC Virtual Environment Architecture Book II v2.01
+ - PowerPC Operating Environment Architecture Book III v2.01
+Power4 - PowerPC User Instruction Set Architecture Book I v2.00
+ - PowerPC Virtual Environment Architecture Book II v2.00
+ - PowerPC Operating Environment Architecture Book III v2.00
+========= ====================================================================
+
+
+Key Features
+------------
+
+========== ==================
+CPU VMX (aka. Altivec)
+========== ==================
+Power10 Yes
+Power9 Yes
+Power8 Yes
+e6500 Yes
+e5500 No
+Power7 Yes
+Power6 Yes
+PA6T Yes
+Cell PPU Yes
+Power5++ No
+Power5+ No
+Power5 No
+PPC970 Yes
+Power4+ No
+Power4 No
+========== ==================
+
+========== ====
+CPU VSX
+========== ====
+Power10 Yes
+Power9 Yes
+Power8 Yes
+e6500 No
+e5500 No
+Power7 Yes
+Power6 No
+PA6T No
+Cell PPU No
+Power5++ No
+Power5+ No
+Power5 No
+PPC970 No
+Power4+ No
+Power4 No
+========== ====
+
+========== ====================================
+CPU Transactional Memory
+========== ====================================
+Power10 No (* see Power ISA v3.1, "Appendix A. Notes on the Removal of Transactional Memory from the Architecture")
+Power9 Yes (* see transactional_memory.txt)
+Power8 Yes
+e6500 No
+e5500 No
+Power7 No
+Power6 No
+PA6T No
+Cell PPU No
+Power5++ No
+Power5+ No
+Power5 No
+PPC970 No
+Power4+ No
+Power4 No
+========== ====================================
diff --git a/Documentation/powerpc/kasan.txt b/Documentation/arch/powerpc/kasan.txt
index f032b4eaf205..a4f647e4fffa 100644
--- a/Documentation/powerpc/kasan.txt
+++ b/Documentation/arch/powerpc/kasan.txt
@@ -40,7 +40,7 @@ checks can be delayed until after the MMU is set is up, and we can just not
instrument any code that runs with translations off after booting. This is the
current approach.
-To avoid this limitiation, the KASAN shadow would have to be placed inside the
+To avoid this limitation, the KASAN shadow would have to be placed inside the
linear mapping, using the same high-bits trick we use for the rest of the linear
mapping. This is tricky:
diff --git a/Documentation/powerpc/kaslr-booke32.rst b/Documentation/arch/powerpc/kaslr-booke32.rst
index 5681c1d1b65b..5681c1d1b65b 100644
--- a/Documentation/powerpc/kaslr-booke32.rst
+++ b/Documentation/arch/powerpc/kaslr-booke32.rst
diff --git a/Documentation/arch/powerpc/kvm-nested.rst b/Documentation/arch/powerpc/kvm-nested.rst
new file mode 100644
index 000000000000..574592505604
--- /dev/null
+++ b/Documentation/arch/powerpc/kvm-nested.rst
@@ -0,0 +1,656 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+Nested KVM on POWER
+====================================
+
+Introduction
+============
+
+This document explains how a guest operating system can act as a
+hypervisor and run nested guests through the use of hypercalls, if the
+hypervisor has implemented them. The terms L0, L1, and L2 are used to
+refer to different software entities. L0 is the hypervisor mode entity
+that would normally be called the "host" or "hypervisor". L1 is a
+guest virtual machine that is directly run under L0 and is initiated
+and controlled by L0. L2 is a guest virtual machine that is initiated
+and controlled by L1 acting as a hypervisor.
+
+Existing API
+============
+
+Linux/KVM has had support for Nesting as an L0 or L1 since 2018
+
+The L0 code was added::
+
+ commit 8e3f5fc1045dc49fd175b978c5457f5f51e7a2ce
+ Author: Paul Mackerras <paulus@ozlabs.org>
+ Date: Mon Oct 8 16:31:03 2018 +1100
+ KVM: PPC: Book3S HV: Framework and hcall stubs for nested virtualization
+
+The L1 code was added::
+
+ commit 360cae313702cdd0b90f82c261a8302fecef030a
+ Author: Paul Mackerras <paulus@ozlabs.org>
+ Date: Mon Oct 8 16:31:04 2018 +1100
+ KVM: PPC: Book3S HV: Nested guest entry via hypercall
+
+This API works primarily using a single hcall h_enter_nested(). This
+call made by the L1 to tell the L0 to start an L2 vCPU with the given
+state. The L0 then starts this L2 and runs until an L2 exit condition
+is reached. Once the L2 exits, the state of the L2 is given back to
+the L1 by the L0. The full L2 vCPU state is always transferred from
+and to L1 when the L2 is run. The L0 doesn't keep any state on the L2
+vCPU (except in the short sequence in the L0 on L1 -> L2 entry and L2
+-> L1 exit).
+
+The only state kept by the L0 is the partition table. The L1 registers
+it's partition table using the h_set_partition_table() hcall. All
+other state held by the L0 about the L2s is cached state (such as
+shadow page tables).
+
+The L1 may run any L2 or vCPU without first informing the L0. It
+simply starts the vCPU using h_enter_nested(). The creation of L2s and
+vCPUs is done implicitly whenever h_enter_nested() is called.
+
+In this document, we call this existing API the v1 API.
+
+New PAPR API
+===============
+
+The new PAPR API changes from the v1 API such that the creating L2 and
+associated vCPUs is explicit. In this document, we call this the v2
+API.
+
+h_enter_nested() is replaced with H_GUEST_VCPU_RUN(). Before this can
+be called the L1 must explicitly create the L2 using h_guest_create()
+and any associated vCPUs() created with h_guest_create_vCPU(). Getting
+and setting vCPU state can also be performed using h_guest_{g|s}et
+hcall.
+
+The basic execution flow is for an L1 to create an L2, run it, and
+delete it is:
+
+- L1 and L0 negotiate capabilities with H_GUEST_{G,S}ET_CAPABILITIES()
+ (normally at L1 boot time).
+
+- L1 requests the L0 create an L2 with H_GUEST_CREATE() and receives a token
+
+- L1 requests the L0 create an L2 vCPU with H_GUEST_CREATE_VCPU()
+
+- L1 and L0 communicate the vCPU state using the H_GUEST_{G,S}ET() hcall
+
+- L1 requests the L0 runs the vCPU running H_GUEST_VCPU_RUN() hcall
+
+- L1 deletes L2 with H_GUEST_DELETE()
+
+More details of the individual hcalls follows:
+
+HCALL Details
+=============
+
+This documentation is provided to give an overall understating of the
+API. It doesn't aim to provide all the details required to implement
+an L1 or L0. Latest version of PAPR can be referred to for more details.
+
+All these HCALLs are made by the L1 to the L0.
+
+H_GUEST_GET_CAPABILITIES()
+--------------------------
+
+This is called to get the capabilities of the L0 nested
+hypervisor. This includes capabilities such the CPU versions (eg
+POWER9, POWER10) that are supported as L2s::
+
+ H_GUEST_GET_CAPABILITIES(uint64 flags)
+
+ Parameters:
+ Input:
+ flags: Reserved
+ Output:
+ R3: Return code
+ R4: Hypervisor Supported Capabilities bitmap 1
+
+H_GUEST_SET_CAPABILITIES()
+--------------------------
+
+This is called to inform the L0 of the capabilities of the L1
+hypervisor. The set of flags passed here are the same as
+H_GUEST_GET_CAPABILITIES()
+
+Typically, GET will be called first and then SET will be called with a
+subset of the flags returned from GET. This process allows the L0 and
+L1 to negotiate an agreed set of capabilities::
+
+ H_GUEST_SET_CAPABILITIES(uint64 flags,
+ uint64 capabilitiesBitmap1)
+ Parameters:
+ Input:
+ flags: Reserved
+ capabilitiesBitmap1: Only capabilities advertised through
+ H_GUEST_GET_CAPABILITIES
+ Output:
+ R3: Return code
+ R4: If R3 = H_P2: The number of invalid bitmaps
+ R5: If R3 = H_P2: The index of first invalid bitmap
+
+H_GUEST_CREATE()
+----------------
+
+This is called to create an L2. A unique ID of the L2 created
+(similar to an LPID) is returned, which can be used on subsequent HCALLs to
+identify the L2::
+
+ H_GUEST_CREATE(uint64 flags,
+ uint64 continueToken);
+ Parameters:
+ Input:
+ flags: Reserved
+ continueToken: Initial call set to -1. Subsequent calls,
+ after H_Busy or H_LongBusyOrder has been
+ returned, value that was returned in R4.
+ Output:
+ R3: Return code. Notable:
+ H_Not_Enough_Resources: Unable to create Guest VCPU due to not
+ enough Hypervisor memory. See H_GUEST_CREATE_GET_STATE(flags =
+ takeOwnershipOfVcpuState)
+ R4: If R3 = H_Busy or_H_LongBusyOrder -> continueToken
+
+H_GUEST_CREATE_VCPU()
+---------------------
+
+This is called to create a vCPU associated with an L2. The L2 id
+(returned from H_GUEST_CREATE()) should be passed it. Also passed in
+is a unique (for this L2) vCPUid. This vCPUid is allocated by the
+L1::
+
+ H_GUEST_CREATE_VCPU(uint64 flags,
+ uint64 guestId,
+ uint64 vcpuId);
+ Parameters:
+ Input:
+ flags: Reserved
+ guestId: ID obtained from H_GUEST_CREATE
+ vcpuId: ID of the vCPU to be created. This must be within the
+ range of 0 to 2047
+ Output:
+ R3: Return code. Notable:
+ H_Not_Enough_Resources: Unable to create Guest VCPU due to not
+ enough Hypervisor memory. See H_GUEST_CREATE_GET_STATE(flags =
+ takeOwnershipOfVcpuState)
+
+H_GUEST_GET_STATE()
+-------------------
+
+This is called to get state associated with an L2 (Guest-wide or vCPU specific).
+This info is passed via the Guest State Buffer (GSB), a standard format as
+explained later in this doc, necessary details below:
+
+This can get either L2 wide or vcpu specific information. Examples of
+L2 wide is the timebase offset or process scoped page table
+info. Examples of vCPU specific are GPRs or VSRs. A bit in the flags
+parameter specifies if this call is L2 wide or vCPU specific and the
+IDs in the GSB must match this.
+
+The L1 provides a pointer to the GSB as a parameter to this call. Also
+provided is the L2 and vCPU IDs associated with the state to set.
+
+The L1 writes only the IDs and sizes in the GSB. L0 writes the
+associated values for each ID in the GSB::
+
+ H_GUEST_GET_STATE(uint64 flags,
+ uint64 guestId,
+ uint64 vcpuId,
+ uint64 dataBuffer,
+ uint64 dataBufferSizeInBytes);
+ Parameters:
+ Input:
+ flags:
+ Bit 0: getGuestWideState: Request state of the Guest instead
+ of an individual VCPU.
+ Bit 1: getHostWideState: Request stats of the Host. This causes
+ the guestId and vcpuId parameters to be ignored and attempting
+ to get the VCPU/Guest state will cause an error.
+ Bits 2-63: Reserved
+ guestId: ID obtained from H_GUEST_CREATE
+ vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
+ dataBuffer: A L1 real address of the GSB.
+ If takeOwnershipOfVcpuState, size must be at least the size
+ returned by ID=0x0001
+ dataBufferSizeInBytes: Size of dataBuffer
+ Output:
+ R3: Return code
+ R4: If R3 = H_Invalid_Element_Id: The array index of the bad
+ element ID.
+ If R3 = H_Invalid_Element_Size: The array index of the bad
+ element size.
+ If R3 = H_Invalid_Element_Value: The array index of the bad
+ element value.
+
+H_GUEST_SET_STATE()
+-------------------
+
+This is called to set L2 wide or vCPU specific L2 state. This info is
+passed via the Guest State Buffer (GSB), necessary details below:
+
+This can set either L2 wide or vcpu specific information. Examples of
+L2 wide is the timebase offset or process scoped page table
+info. Examples of vCPU specific are GPRs or VSRs. A bit in the flags
+parameter specifies if this call is L2 wide or vCPU specific and the
+IDs in the GSB must match this.
+
+The L1 provides a pointer to the GSB as a parameter to this call. Also
+provided is the L2 and vCPU IDs associated with the state to set.
+
+The L1 writes all values in the GSB and the L0 only reads the GSB for
+this call::
+
+ H_GUEST_SET_STATE(uint64 flags,
+ uint64 guestId,
+ uint64 vcpuId,
+ uint64 dataBuffer,
+ uint64 dataBufferSizeInBytes);
+ Parameters:
+ Input:
+ flags:
+ Bit 0: getGuestWideState: Request state of the Guest instead
+ of an individual VCPU.
+ Bit 1: returnOwnershipOfVcpuState Return Guest VCPU state. See
+ GET_STATE takeOwnershipOfVcpuState
+ Bits 2-63: Reserved
+ guestId: ID obtained from H_GUEST_CREATE
+ vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
+ dataBuffer: A L1 real address of the GSB.
+ If takeOwnershipOfVcpuState, size must be at least the size
+ returned by ID=0x0001
+ dataBufferSizeInBytes: Size of dataBuffer
+ Output:
+ R3: Return code
+ R4: If R3 = H_Invalid_Element_Id: The array index of the bad
+ element ID.
+ If R3 = H_Invalid_Element_Size: The array index of the bad
+ element size.
+ If R3 = H_Invalid_Element_Value: The array index of the bad
+ element value.
+
+H_GUEST_RUN_VCPU()
+------------------
+
+This is called to run an L2 vCPU. The L2 and vCPU IDs are passed in as
+parameters. The vCPU runs with the state set previously using
+H_GUEST_SET_STATE(). When the L2 exits, the L1 will resume from this
+hcall.
+
+This hcall also has associated input and output GSBs. Unlike
+H_GUEST_{S,G}ET_STATE(), these GSB pointers are not passed in as
+parameters to the hcall (This was done in the interest of
+performance). The locations of these GSBs must be preregistered using
+the H_GUEST_SET_STATE() call with ID 0x0c00 and 0x0c01 (see table
+below).
+
+The input GSB may contain only VCPU specific elements to be set. This
+GSB may also contain zero elements (ie 0 in the first 4 bytes of the
+GSB) if nothing needs to be set.
+
+On exit from the hcall, the output buffer is filled with elements
+determined by the L0. The reason for the exit is contained in GPR4 (ie
+NIP is put in GPR4). The elements returned depend on the exit
+type. For example, if the exit reason is the L2 doing a hcall (GPR4 =
+0xc00), then GPR3-12 are provided in the output GSB as this is the
+state likely needed to service the hcall. If additional state is
+needed, H_GUEST_GET_STATE() may be called by the L1.
+
+To synthesize interrupts in the L2, when calling H_GUEST_RUN_VCPU()
+the L1 may set a flag (as a hcall parameter) and the L0 will
+synthesize the interrupt in the L2. Alternatively, the L1 may
+synthesize the interrupt itself using H_GUEST_SET_STATE() or the
+H_GUEST_RUN_VCPU() input GSB to set the state appropriately::
+
+ H_GUEST_RUN_VCPU(uint64 flags,
+ uint64 guestId,
+ uint64 vcpuId,
+ uint64 dataBuffer,
+ uint64 dataBufferSizeInBytes);
+ Parameters:
+ Input:
+ flags:
+ Bit 0: generateExternalInterrupt: Generate an external interrupt
+ Bit 1: generatePrivilegedDoorbell: Generate a Privileged Doorbell
+ Bit 2: sendToSystemReset”: Generate a System Reset Interrupt
+ Bits 3-63: Reserved
+ guestId: ID obtained from H_GUEST_CREATE
+ vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
+ Output:
+ R3: Return code
+ R4: If R3 = H_Success: The reason L1 VCPU exited (ie. NIA)
+ 0x000: The VCPU stopped running for an unspecified reason. An
+ example of this is the Hypervisor stopping a VCPU running
+ due to an outstanding interrupt for the Host Partition.
+ 0x980: HDEC
+ 0xC00: HCALL
+ 0xE00: HDSI
+ 0xE20: HISI
+ 0xE40: HEA
+ 0xF80: HV Fac Unavail
+ If R3 = H_Invalid_Element_Id, H_Invalid_Element_Size, or
+ H_Invalid_Element_Value: R4 is offset of the invalid element
+ in the input buffer.
+
+H_GUEST_DELETE()
+----------------
+
+This is called to delete an L2. All associated vCPUs are also
+deleted. No specific vCPU delete call is provided.
+
+A flag may be provided to delete all guests. This is used to reset the
+L0 in the case of kdump/kexec::
+
+ H_GUEST_DELETE(uint64 flags,
+ uint64 guestId)
+ Parameters:
+ Input:
+ flags:
+ Bit 0: deleteAllGuests: deletes all guests
+ Bits 1-63: Reserved
+ guestId: ID obtained from H_GUEST_CREATE
+ Output:
+ R3: Return code
+
+Guest State Buffer
+==================
+
+The Guest State Buffer (GSB) is the main method of communicating state
+about the L2 between the L1 and L0 via H_GUEST_{G,S}ET() and
+H_GUEST_VCPU_RUN() calls.
+
+State may be associated with a whole L2 (eg timebase offset) or a
+specific L2 vCPU (eg. GPR state). Only L2 VCPU state maybe be set by
+H_GUEST_VCPU_RUN().
+
+All data in the GSB is big endian (as is standard in PAPR)
+
+The Guest state buffer has a header which gives the number of
+elements, followed by the GSB elements themselves.
+
+GSB header:
+
++----------+----------+-------------------------------------------+
+| Offset | Size | Purpose |
+| Bytes | Bytes | |
++==========+==========+===========================================+
+| 0 | 4 | Number of elements |
++----------+----------+-------------------------------------------+
+| 4 | | Guest state buffer elements |
++----------+----------+-------------------------------------------+
+
+GSB element:
+
++----------+----------+-------------------------------------------+
+| Offset | Size | Purpose |
+| Bytes | Bytes | |
++==========+==========+===========================================+
+| 0 | 2 | ID |
++----------+----------+-------------------------------------------+
+| 2 | 2 | Size of Value |
++----------+----------+-------------------------------------------+
+| 4 | As above | Value |
++----------+----------+-------------------------------------------+
+
+The ID in the GSB element specifies what is to be set. This includes
+archtected state like GPRs, VSRs, SPRs, plus also some meta data about
+the partition like the timebase offset and partition scoped page
+table information.
+
++--------+-------+----+--------+----------------------------------+
+| ID | Size | RW |(H)ost | Details |
+| | Bytes | |(G)uest | |
+| | | |(T)hread| |
+| | | |Scope | |
++========+=======+====+========+==================================+
+| 0x0000 | | RW | TG | NOP element |
++--------+-------+----+--------+----------------------------------+
+| 0x0001 | 0x08 | R | G | Size of L0 vCPU state. See: |
+| | | | | H_GUEST_GET_STATE: |
+| | | | | flags = takeOwnershipOfVcpuState |
++--------+-------+----+--------+----------------------------------+
+| 0x0002 | 0x08 | R | G | Size Run vCPU out buffer |
++--------+-------+----+--------+----------------------------------+
+| 0x0003 | 0x04 | RW | G | Logical PVR |
++--------+-------+----+--------+----------------------------------+
+| 0x0004 | 0x08 | RW | G | TB Offset (L1 relative) |
++--------+-------+----+--------+----------------------------------+
+| 0x0005 | 0x18 | RW | G |Partition scoped page tbl info: |
+| | | | | |
+| | | | |- 0x00 Addr part scope table |
+| | | | |- 0x08 Num addr bits |
+| | | | |- 0x10 Size root dir |
++--------+-------+----+--------+----------------------------------+
+| 0x0006 | 0x10 | RW | G |Process Table Information: |
+| | | | | |
+| | | | |- 0x0 Addr proc scope table |
+| | | | |- 0x8 Table size. |
++--------+-------+----+--------+----------------------------------+
+| 0x0007-| | | | Reserved |
+| 0x07FF | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x0800 | 0x08 | R | H | Current usage in bytes of the |
+| | | | | L0's Guest Management Space |
+| | | | | for an L1-Lpar. |
++--------+-------+----+--------+----------------------------------+
+| 0x0801 | 0x08 | R | H | Max bytes available in the |
+| | | | | L0's Guest Management Space for |
+| | | | | an L1-Lpar |
++--------+-------+----+--------+----------------------------------+
+| 0x0802 | 0x08 | R | H | Current usage in bytes of the |
+| | | | | L0's Guest Page Table Management |
+| | | | | Space for an L1-Lpar |
++--------+-------+----+--------+----------------------------------+
+| 0x0803 | 0x08 | R | H | Max bytes available in the L0's |
+| | | | | Guest Page Table Management |
+| | | | | Space for an L1-Lpar |
++--------+-------+----+--------+----------------------------------+
+| 0x0804 | 0x08 | R | H | Cumulative Reclaimed bytes from |
+| | | | | L0 Guest's Page Table Management |
+| | | | | Space due to overcommit |
++--------+-------+----+--------+----------------------------------+
+| 0x0805-| | | | Reserved |
+| 0x0BFF | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x0C00 | 0x10 | RW | T |Run vCPU Input Buffer: |
+| | | | | |
+| | | | |- 0x0 Addr of buffer |
+| | | | |- 0x8 Buffer Size. |
++--------+-------+----+--------+----------------------------------+
+| 0x0C01 | 0x10 | RW | T |Run vCPU Output Buffer: |
+| | | | | |
+| | | | |- 0x0 Addr of buffer |
+| | | | |- 0x8 Buffer Size. |
++--------+-------+----+--------+----------------------------------+
+| 0x0C02 | 0x08 | RW | T | vCPU VPA Address |
++--------+-------+----+--------+----------------------------------+
+| 0x0C03-| | | | Reserved |
+| 0x0FFF | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x1000-| 0x08 | RW | T | GPR 0-31 |
+| 0x101F | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x1020 | 0x08 | T | T | HDEC expiry TB |
++--------+-------+----+--------+----------------------------------+
+| 0x1021 | 0x08 | RW | T | NIA |
++--------+-------+----+--------+----------------------------------+
+| 0x1022 | 0x08 | RW | T | MSR |
++--------+-------+----+--------+----------------------------------+
+| 0x1023 | 0x08 | RW | T | LR |
++--------+-------+----+--------+----------------------------------+
+| 0x1024 | 0x08 | RW | T | XER |
++--------+-------+----+--------+----------------------------------+
+| 0x1025 | 0x08 | RW | T | CTR |
++--------+-------+----+--------+----------------------------------+
+| 0x1026 | 0x08 | RW | T | CFAR |
++--------+-------+----+--------+----------------------------------+
+| 0x1027 | 0x08 | RW | T | SRR0 |
++--------+-------+----+--------+----------------------------------+
+| 0x1028 | 0x08 | RW | T | SRR1 |
++--------+-------+----+--------+----------------------------------+
+| 0x1029 | 0x08 | RW | T | DAR |
++--------+-------+----+--------+----------------------------------+
+| 0x102A | 0x08 | RW | T | DEC expiry TB |
++--------+-------+----+--------+----------------------------------+
+| 0x102B | 0x08 | RW | T | VTB |
++--------+-------+----+--------+----------------------------------+
+| 0x102C | 0x08 | RW | T | LPCR |
++--------+-------+----+--------+----------------------------------+
+| 0x102D | 0x08 | RW | T | HFSCR |
++--------+-------+----+--------+----------------------------------+
+| 0x102E | 0x08 | RW | T | FSCR |
++--------+-------+----+--------+----------------------------------+
+| 0x102F | 0x08 | RW | T | FPSCR |
++--------+-------+----+--------+----------------------------------+
+| 0x1030 | 0x08 | RW | T | DAWR0 |
++--------+-------+----+--------+----------------------------------+
+| 0x1031 | 0x08 | RW | T | DAWR1 |
++--------+-------+----+--------+----------------------------------+
+| 0x1032 | 0x08 | RW | T | CIABR |
++--------+-------+----+--------+----------------------------------+
+| 0x1033 | 0x08 | RW | T | PURR |
++--------+-------+----+--------+----------------------------------+
+| 0x1034 | 0x08 | RW | T | SPURR |
++--------+-------+----+--------+----------------------------------+
+| 0x1035 | 0x08 | RW | T | IC |
++--------+-------+----+--------+----------------------------------+
+| 0x1036-| 0x08 | RW | T | SPRG 0-3 |
+| 0x1039 | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x103A | 0x08 | W | T | PPR |
++--------+-------+----+--------+----------------------------------+
+| 0x103B | 0x08 | RW | T | MMCR 0-3 |
+| 0x103E | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x103F | 0x08 | RW | T | MMCRA |
++--------+-------+----+--------+----------------------------------+
+| 0x1040 | 0x08 | RW | T | SIER |
++--------+-------+----+--------+----------------------------------+
+| 0x1041 | 0x08 | RW | T | SIER 2 |
++--------+-------+----+--------+----------------------------------+
+| 0x1042 | 0x08 | RW | T | SIER 3 |
++--------+-------+----+--------+----------------------------------+
+| 0x1043 | 0x08 | RW | T | BESCR |
++--------+-------+----+--------+----------------------------------+
+| 0x1044 | 0x08 | RW | T | EBBHR |
++--------+-------+----+--------+----------------------------------+
+| 0x1045 | 0x08 | RW | T | EBBRR |
++--------+-------+----+--------+----------------------------------+
+| 0x1046 | 0x08 | RW | T | AMR |
++--------+-------+----+--------+----------------------------------+
+| 0x1047 | 0x08 | RW | T | IAMR |
++--------+-------+----+--------+----------------------------------+
+| 0x1048 | 0x08 | RW | T | AMOR |
++--------+-------+----+--------+----------------------------------+
+| 0x1049 | 0x08 | RW | T | UAMOR |
++--------+-------+----+--------+----------------------------------+
+| 0x104A | 0x08 | RW | T | SDAR |
++--------+-------+----+--------+----------------------------------+
+| 0x104B | 0x08 | RW | T | SIAR |
++--------+-------+----+--------+----------------------------------+
+| 0x104C | 0x08 | RW | T | DSCR |
++--------+-------+----+--------+----------------------------------+
+| 0x104D | 0x08 | RW | T | TAR |
++--------+-------+----+--------+----------------------------------+
+| 0x104E | 0x08 | RW | T | DEXCR |
++--------+-------+----+--------+----------------------------------+
+| 0x104F | 0x08 | RW | T | HDEXCR |
++--------+-------+----+--------+----------------------------------+
+| 0x1050 | 0x08 | RW | T | HASHKEYR |
++--------+-------+----+--------+----------------------------------+
+| 0x1051 | 0x08 | RW | T | HASHPKEYR |
++--------+-------+----+--------+----------------------------------+
+| 0x1052 | 0x08 | RW | T | CTRL |
++--------+-------+----+--------+----------------------------------+
+| 0x1053 | 0x08 | RW | T | DPDES |
++--------+-------+----+--------+----------------------------------+
+| 0x1054-| | | | Reserved |
+| 0x1FFF | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x2000 | 0x04 | RW | T | CR |
++--------+-------+----+--------+----------------------------------+
+| 0x2001 | 0x04 | RW | T | PIDR |
++--------+-------+----+--------+----------------------------------+
+| 0x2002 | 0x04 | RW | T | DSISR |
++--------+-------+----+--------+----------------------------------+
+| 0x2003 | 0x04 | RW | T | VSCR |
++--------+-------+----+--------+----------------------------------+
+| 0x2004 | 0x04 | RW | T | VRSAVE |
++--------+-------+----+--------+----------------------------------+
+| 0x2005 | 0x04 | RW | T | DAWRX0 |
++--------+-------+----+--------+----------------------------------+
+| 0x2006 | 0x04 | RW | T | DAWRX1 |
++--------+-------+----+--------+----------------------------------+
+| 0x2007-| 0x04 | RW | T | PMC 1-6 |
+| 0x200c | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x200D | 0x04 | RW | T | WORT |
++--------+-------+----+--------+----------------------------------+
+| 0x200E | 0x04 | RW | T | PSPB |
++--------+-------+----+--------+----------------------------------+
+| 0x200F-| | | | Reserved |
+| 0x2FFF | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x3000-| 0x10 | RW | T | VSR 0-63 |
+| 0x303F | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0x3040-| | | | Reserved |
+| 0xEFFF | | | | |
++--------+-------+----+--------+----------------------------------+
+| 0xF000 | 0x08 | R | T | HDAR |
++--------+-------+----+--------+----------------------------------+
+| 0xF001 | 0x04 | R | T | HDSISR |
++--------+-------+----+--------+----------------------------------+
+| 0xF002 | 0x04 | R | T | HEIR |
++--------+-------+----+--------+----------------------------------+
+| 0xF003 | 0x08 | R | T | ASDR |
++--------+-------+----+--------+----------------------------------+
+
+
+Miscellaneous info
+==================
+
+State not in ptregs/hvregs
+--------------------------
+
+In the v1 API, some state is not in the ptregs/hvstate. This includes
+the vector register and some SPRs. For the L1 to set this state for
+the L2, the L1 loads up these hardware registers before the
+h_enter_nested() call and the L0 ensures they end up as the L2 state
+(by not touching them).
+
+The v2 API removes this and explicitly sets this state via the GSB.
+
+L1 Implementation details: Caching state
+----------------------------------------
+
+In the v1 API, all state is sent from the L1 to the L0 and vice versa
+on every h_enter_nested() hcall. If the L0 is not currently running
+any L2s, the L0 has no state information about them. The only
+exception to this is the location of the partition table, registered
+via h_set_partition_table().
+
+The v2 API changes this so that the L0 retains the L2 state even when
+it's vCPUs are no longer running. This means that the L1 only needs to
+communicate with the L0 about L2 state when it needs to modify the L2
+state, or when it's value is out of date. This provides an opportunity
+for performance optimisation.
+
+When a vCPU exits from a H_GUEST_RUN_VCPU() call, the L1 internally
+marks all L2 state as invalid. This means that if the L1 wants to know
+the L2 state (say via a kvm_get_one_reg() call), it needs call
+H_GUEST_GET_STATE() to get that state. Once it's read, it's marked as
+valid in L1 until the L2 is run again.
+
+Also, when an L1 modifies L2 vcpu state, it doesn't need to write it
+to the L0 until that L2 vcpu runs again. Hence when the L1 updates
+state (say via a kvm_set_one_reg() call), it writes to an internal L1
+copy and only flushes this copy to the L0 when the L2 runs again via
+the H_GUEST_VCPU_RUN() input buffer.
+
+This lazy updating of state by the L1 avoids unnecessary
+H_GUEST_{G|S}ET_STATE() calls.
diff --git a/Documentation/powerpc/mpc52xx.rst b/Documentation/arch/powerpc/mpc52xx.rst
index 5243b1763fad..5243b1763fad 100644
--- a/Documentation/powerpc/mpc52xx.rst
+++ b/Documentation/arch/powerpc/mpc52xx.rst
diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/arch/powerpc/papr_hcalls.rst
index fce8bc793660..805e1cb9bab9 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/arch/powerpc/papr_hcalls.rst
@@ -22,7 +22,7 @@ privileged operations. Currently there are two PAPR compliant hypervisors:
On PPC64 arch a guest kernel running on top of a PAPR hypervisor is called
a *pSeries guest*. A pseries guest runs in a supervisor mode (HV=0) and must
issue hypercalls to the hypervisor whenever it needs to perform an action
-that is hypervisor priviledged [3]_ or for other services managed by the
+that is hypervisor privileged [3]_ or for other services managed by the
hypervisor.
Hence a Hypercall (hcall) is essentially a request by the pseries guest
@@ -289,6 +289,17 @@ to be issued multiple times in order to be completely serviced. The
subsequent hcalls to the hypervisor until the hcall is completely serviced
at which point H_SUCCESS or other error is returned by the hypervisor.
+**H_HTM**
+
+| Input: flags, target, operation (op), op-param1, op-param2, op-param3
+| Out: *dumphtmbufferdata*
+| Return Value: *H_Success,H_Busy,H_LongBusyOrder,H_Partial,H_Parameter,
+ H_P2,H_P3,H_P4,H_P5,H_P6,H_State,H_Not_Available,H_Authority*
+
+H_HTM supports setup, configuration, control and dumping of Hardware Trace
+Macro (HTM) function and its data. HTM buffer stores tracing data for functions
+like core instruction, core LLAT and nest.
+
References
==========
.. [1] "Power Architecture Platform Reference"
diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.rst b/Documentation/arch/powerpc/pci_iov_resource_on_powernv.rst
index f5a5793e1613..f5a5793e1613 100644
--- a/Documentation/powerpc/pci_iov_resource_on_powernv.rst
+++ b/Documentation/arch/powerpc/pci_iov_resource_on_powernv.rst
diff --git a/Documentation/powerpc/pmu-ebb.rst b/Documentation/arch/powerpc/pmu-ebb.rst
index 4f474758eb55..4f474758eb55 100644
--- a/Documentation/powerpc/pmu-ebb.rst
+++ b/Documentation/arch/powerpc/pmu-ebb.rst
diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/arch/powerpc/ptrace.rst
index 77725d69eb4a..5629edf4d56e 100644
--- a/Documentation/powerpc/ptrace.rst
+++ b/Documentation/arch/powerpc/ptrace.rst
@@ -15,7 +15,7 @@ that's extendable and that covers both BookE and server processors, so
that GDB doesn't need to special-case each of them. We added the
following 3 new ptrace requests.
-1. PTRACE_PPC_GETHWDEBUGINFO
+1. PPC_PTRACE_GETHWDBGINFO
============================
Query for GDB to discover the hardware debug features. The main info to
@@ -48,7 +48,7 @@ features will have bits indicating whether there is support for::
#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
#define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 0x20
-2. PTRACE_SETHWDEBUG
+2. PPC_PTRACE_SETHWDEBUG
Sets a hardware breakpoint or watchpoint, according to the provided structure::
@@ -88,7 +88,7 @@ that the BookE supports. COMEFROM breakpoints available in server processors
are not contemplated, but that is out of the scope of this work.
ptrace will return an integer (handle) uniquely identifying the breakpoint or
-watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
+watchpoint just created. This integer will be used in the PPC_PTRACE_DELHWDEBUG
request to ask for its removal. Return -ENOSPC if the requested breakpoint
can't be allocated on the registers.
@@ -150,7 +150,7 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
-3. PTRACE_DELHWDEBUG
+3. PPC_PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
diff --git a/Documentation/powerpc/qe_firmware.rst b/Documentation/arch/powerpc/qe_firmware.rst
index 42f5103140c9..a358f152b7e7 100644
--- a/Documentation/powerpc/qe_firmware.rst
+++ b/Documentation/arch/powerpc/qe_firmware.rst
@@ -232,11 +232,11 @@ For example, to match the 8323, revision 1.0::
'extended_modes' is a bitfield that defines special functionality which has an
impact on the device drivers. Each bit has its own impact and has special
instructions for the driver associated with it. This field is stored in
-the QE library and available to any driver that calles qe_get_firmware_info().
+the QE library and available to any driver that calls qe_get_firmware_info().
'vtraps' is an array of 8 words that contain virtual trap values for each
virtual traps. As with 'extended_modes', this field is stored in the QE
-library and available to any driver that calles qe_get_firmware_info().
+library and available to any driver that calls qe_get_firmware_info().
'microcode' (type: struct qe_microcode):
For each RISC processor there is one 'microcode' structure. The first
diff --git a/Documentation/powerpc/syscall64-abi.rst b/Documentation/arch/powerpc/syscall64-abi.rst
index 56490c4c0c07..56490c4c0c07 100644
--- a/Documentation/powerpc/syscall64-abi.rst
+++ b/Documentation/arch/powerpc/syscall64-abi.rst
diff --git a/Documentation/powerpc/transactional_memory.rst b/Documentation/arch/powerpc/transactional_memory.rst
index 040a20675fd1..040a20675fd1 100644
--- a/Documentation/powerpc/transactional_memory.rst
+++ b/Documentation/arch/powerpc/transactional_memory.rst
diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/arch/powerpc/ultravisor.rst
index ba6b1bf1cc44..6d0407b2f5a1 100644
--- a/Documentation/powerpc/ultravisor.rst
+++ b/Documentation/arch/powerpc/ultravisor.rst
@@ -134,7 +134,7 @@ Hardware
* PTCR and partition table entries (partition table is in secure
memory). An attempt to write to PTCR will cause a Hypervisor
- Emulation Assitance interrupt.
+ Emulation Assistance interrupt.
* LDBAR (LD Base Address Register) and IMC (In-Memory Collection)
non-architected registers. An attempt to write to them will cause a
diff --git a/Documentation/powerpc/vas-api.rst b/Documentation/arch/powerpc/vas-api.rst
index bdb50fed903e..a9625a2fa0c6 100644
--- a/Documentation/powerpc/vas-api.rst
+++ b/Documentation/arch/powerpc/vas-api.rst
@@ -46,7 +46,7 @@ request queue into the application's virtual address space.
The application can then submit one or more requests to the engine by
using copy/paste instructions and pasting the CRBs to the virtual address
(aka paste_address) returned by mmap(). User space can close the
-established connection or send window by closing the file descriptior
+established connection or send window by closing the file descriptor
(close(fd)) or upon the process exit.
Note that applications can send several requests with the same window or
@@ -240,7 +240,7 @@ issued. This signal returns with the following siginfo struct::
siginfo.si_signo = SIGSEGV;
siginfo.si_errno = EFAULT;
siginfo.si_code = SEGV_MAPERR;
- siginfo.si_addr = CSB adress;
+ siginfo.si_addr = CSB address;
In the case of multi-thread applications, NX send windows can be shared
across all threads. For example, a child thread can open a send window,
diff --git a/Documentation/powerpc/vcpudispatch_stats.rst b/Documentation/arch/powerpc/vcpudispatch_stats.rst
index 5704657a5987..5704657a5987 100644
--- a/Documentation/powerpc/vcpudispatch_stats.rst
+++ b/Documentation/arch/powerpc/vcpudispatch_stats.rst
diff --git a/Documentation/arch/powerpc/vmemmap_dedup.rst b/Documentation/arch/powerpc/vmemmap_dedup.rst
new file mode 100644
index 000000000000..dc4db59fdf87
--- /dev/null
+++ b/Documentation/arch/powerpc/vmemmap_dedup.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========
+Device DAX
+==========
+
+The device-dax interface uses the tail deduplication technique explained in
+Documentation/mm/vmemmap_dedup.rst
+
+On powerpc, vmemmap deduplication is only used with radix MMU translation. Also
+with a 64K page size, only the devdax namespace with 1G alignment uses vmemmap
+deduplication.
+
+With 2M PMD level mapping, we require 32 struct pages and a single 64K vmemmap
+page can contain 1024 struct pages (64K/sizeof(struct page)). Hence there is no
+vmemmap deduplication possible.
+
+With 1G PUD level mapping, we require 16384 struct pages and a single 64K
+vmemmap page can contain 1024 struct pages (64K/sizeof(struct page)). Hence we
+require 16 64K pages in vmemmap to map the struct page for 1G PUD level mapping.
+
+Here's how things look like on device-dax after the sections are populated::
+ +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
+ | | | 0 | -------------> | 0 |
+ | | +-----------+ +-----------+
+ | | | 1 | -------------> | 1 |
+ | | +-----------+ +-----------+
+ | | | 2 | ----------------^ ^ ^ ^ ^ ^
+ | | +-----------+ | | | | |
+ | | | 3 | ------------------+ | | | |
+ | | +-----------+ | | | |
+ | | | 4 | --------------------+ | | |
+ | PUD | +-----------+ | | |
+ | level | | . | ----------------------+ | |
+ | mapping | +-----------+ | |
+ | | | . | ------------------------+ |
+ | | +-----------+ |
+ | | | 15 | --------------------------+
+ | | +-----------+
+ | |
+ | |
+ | |
+ +-----------+
+
+
+With 4K page size, 2M PMD level mapping requires 512 struct pages and a single
+4K vmemmap page contains 64 struct pages(4K/sizeof(struct page)). Hence we
+require 8 4K pages in vmemmap to map the struct page for 2M pmd level mapping.
+
+Here's how things look like on device-dax after the sections are populated::
+
+ +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
+ | | | 0 | -------------> | 0 |
+ | | +-----------+ +-----------+
+ | | | 1 | -------------> | 1 |
+ | | +-----------+ +-----------+
+ | | | 2 | ----------------^ ^ ^ ^ ^ ^
+ | | +-----------+ | | | | |
+ | | | 3 | ------------------+ | | | |
+ | | +-----------+ | | | |
+ | | | 4 | --------------------+ | | |
+ | PMD | +-----------+ | | |
+ | level | | 5 | ----------------------+ | |
+ | mapping | +-----------+ | |
+ | | | 6 | ------------------------+ |
+ | | +-----------+ |
+ | | | 7 | --------------------------+
+ | | +-----------+
+ | |
+ | |
+ | |
+ +-----------+
+
+With 1G PUD level mapping, we require 262144 struct pages and a single 4K
+vmemmap page can contain 64 struct pages (4K/sizeof(struct page)). Hence we
+require 4096 4K pages in vmemmap to map the struct pages for 1G PUD level
+mapping.
+
+Here's how things look like on device-dax after the sections are populated::
+
+ +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
+ | | | 0 | -------------> | 0 |
+ | | +-----------+ +-----------+
+ | | | 1 | -------------> | 1 |
+ | | +-----------+ +-----------+
+ | | | 2 | ----------------^ ^ ^ ^ ^ ^
+ | | +-----------+ | | | | |
+ | | | 3 | ------------------+ | | | |
+ | | +-----------+ | | | |
+ | | | 4 | --------------------+ | | |
+ | PUD | +-----------+ | | |
+ | level | | . | ----------------------+ | |
+ | mapping | +-----------+ | |
+ | | | . | ------------------------+ |
+ | | +-----------+ |
+ | | | 4095 | --------------------------+
+ | | +-----------+
+ | |
+ | |
+ | |
+ +-----------+
diff --git a/Documentation/arch/powerpc/vpa-dtl.rst b/Documentation/arch/powerpc/vpa-dtl.rst
new file mode 100644
index 000000000000..58d0022f993a
--- /dev/null
+++ b/Documentation/arch/powerpc/vpa-dtl.rst
@@ -0,0 +1,156 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _vpa-dtl:
+
+===================================
+DTL (Dispatch Trace Log)
+===================================
+
+Athira Rajeev, 19 April 2025
+
+.. contents::
+ :depth: 3
+
+
+Basic overview
+==============
+
+The pseries Shared Processor Logical Partition(SPLPAR) machines can
+retrieve a log of dispatch and preempt events from the hypervisor
+using data from Disptach Trace Log(DTL) buffer. With this information,
+user can retrieve when and why each dispatch & preempt has occurred.
+The vpa-dtl PMU exposes the Virtual Processor Area(VPA) DTL counters
+via perf.
+
+Infrastructure used
+===================
+
+The VPA DTL PMU counters do not interrupt on overflow or generate any
+PMI interrupts. Therefore, hrtimer is used to poll the DTL data. The timer
+nterval can be provided by user via sample_period field in nano seconds.
+vpa dtl pmu has one hrtimer added per vpa-dtl pmu thread. DTL (Dispatch
+Trace Log) contains information about dispatch/preempt, enqueue time etc.
+We directly copy the DTL buffer data as part of auxiliary buffer and it
+will be processed later. This will avoid time taken to create samples
+in the kernel space. The PMU driver collecting Dispatch Trace Log (DTL)
+entries makes use of AUX support in perf infrastructure. On the tools side,
+this data is made available as PERF_RECORD_AUXTRACE records.
+
+To correlate each DTL entry with other events across CPU's, an auxtrace_queue
+is created for each CPU. Each auxtrace queue has a array/list of auxtrace buffers.
+All auxtrace queues is maintained in auxtrace heap. The queues are sorted
+based on timestamp. When the different PERF_RECORD_XX records are processed,
+compare the timestamp of perf record with timestamp of top element in the
+auxtrace heap so that DTL events can be co-related with other events
+Process the auxtrace queue if the timestamp of element from heap is
+lower than timestamp from entry in perf record. Sometimes it could happen that
+one buffer is only partially processed. if the timestamp of occurrence of
+another event is more than currently processed element in the queue, it will
+move on to next perf record. So keep track of position of buffer to continue
+processing next time. Update the timestamp of the auxtrace heap with the timestamp
+of last processed entry from the auxtrace buffer.
+
+This infrastructure ensures dispatch trace log entries can be correlated
+and presented along with other events like sched.
+
+vpa-dtl PMU example usage
+=========================
+
+.. code-block:: sh
+
+ # ls /sys/devices/vpa_dtl/
+ events format perf_event_mux_interval_ms power subsystem type uevent
+
+
+To capture the DTL data using perf record:
+.. code-block:: sh
+
+ # ./perf record -a -e sched:\*,vpa_dtl/dtl_all/ -c 1000000000 sleep 1
+
+The result can be interpreted using perf record. Snippet of perf report -D
+
+.. code-block:: sh
+
+ # ./perf report -D
+
+There are different PERF_RECORD_XX records. In that records corresponding to
+auxtrace buffers includes:
+
+1. PERF_RECORD_AUX
+ Conveys that new data is available in AUX area
+
+2. PERF_RECORD_AUXTRACE_INFO
+ Describes offset and size of auxtrace data in the buffers
+
+3. PERF_RECORD_AUXTRACE
+ This is the record that defines the auxtrace data which here in case of
+ vpa-dtl pmu is dispatch trace log data.
+
+Snippet from perf report -D showing the PERF_RECORD_AUXTRACE dump
+
+.. code-block:: sh
+
+0 0 0x39b10 [0x30]: PERF_RECORD_AUXTRACE size: 0x690 offset: 0 ref: 0 idx: 0 tid: -1 cpu: 0
+.
+. ... VPA DTL PMU data: size 1680 bytes, entries is 35
+. 00000000: boot_tb: 21349649546353231, tb_freq: 512000000
+. 00000030: dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:7064, ready_to_enqueue_time:187, waiting_to_ready_time:6611773
+. 00000060: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:146, ready_to_enqueue_time:0, waiting_to_ready_time:15359437
+. 00000090: dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:4868, ready_to_enqueue_time:232, waiting_to_ready_time:5100709
+. 000000c0: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:179, ready_to_enqueue_time:0, waiting_to_ready_time:30714243
+. 000000f0: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:197, ready_to_enqueue_time:0, waiting_to_ready_time:15350648
+. 00000120: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:213, ready_to_enqueue_time:0, waiting_to_ready_time:15353446
+. 00000150: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:212, ready_to_enqueue_time:0, waiting_to_ready_time:15355126
+. 00000180: dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:6368, ready_to_enqueue_time:164, waiting_to_ready_time:5104665
+
+Above is representation of dtl entry of below format:
+
+struct dtl_entry {
+ u8 dispatch_reason;
+ u8 preempt_reason;
+ u16 processor_id;
+ u32 enqueue_to_dispatch_time;
+ u32 ready_to_enqueue_time;
+ u32 waiting_to_ready_time;
+ u64 timebase;
+ u64 fault_addr;
+ u64 srr0;
+ u64 srr1;
+
+};
+
+First two fields represent the dispatch reason and preempt reason. The post
+processing of PERF_RECORD_AUXTRACE records will translate to meaningful data
+for user to consume.
+
+Visualize the dispatch trace log entries with perf report
+=========================================================
+
+.. code-block:: sh
+
+ # ./perf record -a -e sched:*,vpa_dtl/dtl_all/ -c 1000000000 sleep 1
+ [ perf record: Woken up 1 times to write data ]
+ [ perf record: Captured and wrote 0.300 MB perf.data ]
+
+ # ./perf report
+ # Samples: 321 of event 'vpa-dtl'
+ # Event count (approx.): 321
+ #
+ # Children Self Command Shared Object Symbol
+ # ........ ........ ....... ................. ..............................
+ #
+ 100.00% 100.00% swapper [kernel.kallsyms] [k] plpar_hcall_norets_notrace
+
+Visualize the dispatch trace log entries with perf script
+=========================================================
+
+.. code-block:: sh
+
+ # ./perf script
+ migration/9 67 [009] 105373.359903: sched:sched_waking: comm=perf pid=13418 prio=120 target_cpu=009
+ migration/9 67 [009] 105373.359904: sched:sched_migrate_task: comm=perf pid=13418 prio=120 orig_cpu=9 dest_cpu=10
+ migration/9 67 [009] 105373.359907: sched:sched_stat_runtime: comm=migration/9 pid=67 runtime=4050 [ns]
+ migration/9 67 [009] 105373.359908: sched:sched_switch: prev_comm=migration/9 prev_pid=67 prev_prio=0 prev_state=S ==> next_comm=swapper/9 next_pid=0 next_prio=120
+ :256 256 [016] 105373.359913: vpa-dtl: timebase: 21403600706628832 dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:4854, ready_to_enqueue_time:139, waiting_to_ready_time:511842115 c0000000000fcd28 plpar_hcall_norets_notrace+0x18 ([kernel.kallsyms])
+ :256 256 [017] 105373.360012: vpa-dtl: timebase: 21403600706679454 dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:236, ready_to_enqueue_time:0, waiting_to_ready_time:133864583 c0000000000fcd28 plpar_hcall_norets_notrace+0x18 ([kernel.kallsyms])
+ perf 13418 [010] 105373.360048: sched:sched_stat_runtime: comm=perf pid=13418 runtime=139748 [ns]
+ perf 13418 [010] 105373.360052: sched:sched_waking: comm=migration/10 pid=72 prio=0 target_cpu=010
diff --git a/Documentation/arch/riscv/acpi.rst b/Documentation/arch/riscv/acpi.rst
new file mode 100644
index 000000000000..9870a282815b
--- /dev/null
+++ b/Documentation/arch/riscv/acpi.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+ACPI on RISC-V
+==============
+
+The ISA string parsing rules for ACPI are defined by `Version ASCIIDOC
+Conversion, 12/2022 of the RISC-V specifications, as defined by tag
+"riscv-isa-release-1239329-2023-05-23" (commit 1239329
+) <https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-isa-release-1239329-2023-05-23>`_
diff --git a/Documentation/arch/riscv/boot-image-header.rst b/Documentation/arch/riscv/boot-image-header.rst
new file mode 100644
index 000000000000..df2ffc173e80
--- /dev/null
+++ b/Documentation/arch/riscv/boot-image-header.rst
@@ -0,0 +1,59 @@
+=================================
+Boot image header in RISC-V Linux
+=================================
+
+:Author: Atish Patra <atish.patra@wdc.com>
+:Date: 20 May 2019
+
+This document only describes the boot image header details for RISC-V Linux.
+
+The following 64-byte header is present in decompressed Linux kernel image::
+
+ u32 code0; /* Executable code */
+ u32 code1; /* Executable code */
+ u64 text_offset; /* Image load offset, little endian */
+ u64 image_size; /* Effective Image size, little endian */
+ u64 flags; /* kernel flags, little endian */
+ u32 version; /* Version of this header */
+ u32 res1 = 0; /* Reserved */
+ u64 res2 = 0; /* Reserved */
+ u64 magic = 0x5643534952; /* Magic number, little endian, "RISCV" */
+ u32 magic2 = 0x05435352; /* Magic number 2, little endian, "RSC\x05" */
+ u32 res3; /* Reserved for PE COFF offset */
+
+This header format is compliant with PE/COFF header and largely inspired from
+ARM64 header. Thus, both ARM64 & RISC-V header can be combined into one common
+header in future.
+
+Notes
+=====
+
+- This header is also reused to support EFI stub for RISC-V. EFI specification
+ needs PE/COFF image header in the beginning of the kernel image in order to
+ load it as an EFI application. In order to support EFI stub, code0 is replaced
+ with "MZ" magic string and res3(at offset 0x3c) points to the rest of the
+ PE/COFF header.
+
+- version field indicate header version number
+
+ ========== =============
+ Bits 0:15 Minor version
+ Bits 16:31 Major version
+ ========== =============
+
+ This preserves compatibility across newer and older version of the header.
+ The current version is defined as 0.2.
+
+- The "magic" field is deprecated as of version 0.2. In a future
+ release, it may be removed. This originally should have matched up
+ with the ARM64 header "magic" field, but unfortunately does not.
+ The "magic2" field replaces it, matching up with the ARM64 header.
+
+- In current header, the flags field has only one field.
+
+ ===== ====================================
+ Bit 0 Kernel endianness. 1 if BE, 0 if LE.
+ ===== ====================================
+
+- Image size is mandatory for boot loader to load kernel image. Booting will
+ fail otherwise.
diff --git a/Documentation/arch/riscv/boot.rst b/Documentation/arch/riscv/boot.rst
new file mode 100644
index 000000000000..6077b587a842
--- /dev/null
+++ b/Documentation/arch/riscv/boot.rst
@@ -0,0 +1,169 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+RISC-V Kernel Boot Requirements and Constraints
+===============================================
+
+:Author: Alexandre Ghiti <alexghiti@rivosinc.com>
+:Date: 23 May 2023
+
+This document describes what the RISC-V kernel expects from bootloaders and
+firmware, and also the constraints that any developer must have in mind when
+touching the early boot process. For the purposes of this document, the
+``early boot process`` refers to any code that runs before the final virtual
+mapping is set up.
+
+Pre-kernel Requirements and Constraints
+=======================================
+
+The RISC-V kernel expects the following of bootloaders and platform firmware:
+
+Register state
+--------------
+
+The RISC-V kernel expects:
+
+ * ``$a0`` to contain the hartid of the current core.
+ * ``$a1`` to contain the address of the devicetree in memory.
+
+CSR state
+---------
+
+The RISC-V kernel expects:
+
+ * ``$satp = 0``: the MMU, if present, must be disabled.
+
+Reserved memory for resident firmware
+-------------------------------------
+
+The RISC-V kernel must not map any resident memory, or memory protected with
+PMPs, in the direct mapping, so the firmware must correctly mark those regions
+as per the devicetree specification and/or the UEFI specification.
+
+Kernel location
+---------------
+
+The RISC-V kernel expects to be placed at a PMD boundary (2MB aligned for rv64
+and 4MB aligned for rv32). Note that the EFI stub will physically relocate the
+kernel if that's not the case.
+
+Hardware description
+--------------------
+
+The firmware can pass either a devicetree or ACPI tables to the RISC-V kernel.
+
+The devicetree is either passed directly to the kernel from the previous stage
+using the ``$a1`` register, or when booting with UEFI, it can be passed using the
+EFI configuration table.
+
+The ACPI tables are passed to the kernel using the EFI configuration table. In
+this case, a tiny devicetree is still created by the EFI stub. Please refer to
+"EFI stub and devicetree" section below for details about this devicetree.
+
+Kernel entry
+------------
+
+On SMP systems, there are 2 methods to enter the kernel:
+
+- ``RISCV_BOOT_SPINWAIT``: the firmware releases all harts in the kernel, one hart
+ wins a lottery and executes the early boot code while the other harts are
+ parked waiting for the initialization to finish. This method is mostly used to
+ support older firmwares without SBI HSM extension and M-mode RISC-V kernel.
+- ``Ordered booting``: the firmware releases only one hart that will execute the
+ initialization phase and then will start all other harts using the SBI HSM
+ extension. The ordered booting method is the preferred booting method for
+ booting the RISC-V kernel because it can support CPU hotplug and kexec.
+
+UEFI
+----
+
+UEFI memory map
+~~~~~~~~~~~~~~~
+
+When booting with UEFI, the RISC-V kernel will use only the EFI memory map to
+populate the system memory.
+
+The UEFI firmware must parse the subnodes of the ``/reserved-memory`` devicetree
+node and abide by the devicetree specification to convert the attributes of
+those subnodes (``no-map`` and ``reusable``) into their correct EFI equivalent
+(refer to section "3.5.4 /reserved-memory and UEFI" of the devicetree
+specification v0.4-rc1).
+
+RISCV_EFI_BOOT_PROTOCOL
+~~~~~~~~~~~~~~~~~~~~~~~
+
+When booting with UEFI, the EFI stub requires the boot hartid in order to pass
+it to the RISC-V kernel in ``$a1``. The EFI stub retrieves the boot hartid using
+one of the following methods:
+
+- ``RISCV_EFI_BOOT_PROTOCOL`` (**preferred**).
+- ``boot-hartid`` devicetree subnode (**deprecated**).
+
+Any new firmware must implement ``RISCV_EFI_BOOT_PROTOCOL`` as the devicetree
+based approach is deprecated now.
+
+Early Boot Requirements and Constraints
+=======================================
+
+The RISC-V kernel's early boot process operates under the following constraints:
+
+EFI stub and devicetree
+-----------------------
+
+When booting with UEFI, the devicetree is supplemented (or created) by the EFI
+stub with the same parameters as arm64 which are described at the paragraph
+"UEFI kernel support on ARM" in Documentation/arch/arm/uefi.rst.
+
+Virtual mapping installation
+----------------------------
+
+The installation of the virtual mapping is done in 2 steps in the RISC-V kernel:
+
+1. ``setup_vm()`` installs a temporary kernel mapping in ``early_pg_dir`` which
+ allows discovery of the system memory. Only the kernel text/data are mapped
+ at this point. When establishing this mapping, no allocation can be done
+ (since the system memory is not known yet), so ``early_pg_dir`` page table is
+ statically allocated (using only one table for each level).
+
+2. ``setup_vm_final()`` creates the final kernel mapping in ``swapper_pg_dir``
+ and takes advantage of the discovered system memory to create the linear
+ mapping. When establishing this mapping, the kernel can allocate memory but
+ cannot access it directly (since the direct mapping is not present yet), so
+ it uses temporary mappings in the fixmap region to be able to access the
+ newly allocated page table levels.
+
+For ``virt_to_phys()`` and ``phys_to_virt()`` to be able to correctly convert
+direct mapping addresses to physical addresses, they need to know the start of
+the DRAM. This happens after step 1, right before step 2 installs the direct
+mapping (see ``setup_bootmem()`` function in arch/riscv/mm/init.c). Any usage of
+those macros before the final virtual mapping is installed must be carefully
+examined.
+
+Devicetree mapping via fixmap
+-----------------------------
+
+As the ``reserved_mem`` array is initialized with virtual addresses established
+by ``setup_vm()``, and used with the mapping established by
+``setup_vm_final()``, the RISC-V kernel uses the fixmap region to map the
+devicetree. This ensures that the devicetree remains accessible by both virtual
+mappings.
+
+Pre-MMU execution
+-----------------
+
+A few pieces of code need to run before even the first virtual mapping is
+established. These are the installation of the first virtual mapping itself,
+patching of early alternatives and the early parsing of the kernel command line.
+That code must be very carefully compiled as:
+
+- ``-fno-pie``: This is needed for relocatable kernels which use ``-fPIE``,
+ since otherwise, any access to a global symbol would go through the GOT which
+ is only relocated virtually.
+- ``-mcmodel=medany``: Any access to a global symbol must be PC-relative to
+ avoid any relocations to happen before the MMU is setup.
+- *all* instrumentation must also be disabled (that includes KASAN, ftrace and
+ others).
+
+As using a symbol from a different compilation unit requires this unit to be
+compiled with those flags, we advise, as much as possible, not to use external
+symbols.
diff --git a/Documentation/arch/riscv/cmodx.rst b/Documentation/arch/riscv/cmodx.rst
new file mode 100644
index 000000000000..40ba53bed5df
--- /dev/null
+++ b/Documentation/arch/riscv/cmodx.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================================================================
+Concurrent Modification and Execution of Instructions (CMODX) for RISC-V Linux
+==============================================================================
+
+CMODX is a programming technique where a program executes instructions that were
+modified by the program itself. Instruction storage and the instruction cache
+(icache) are not guaranteed to be synchronized on RISC-V hardware. Therefore, the
+program must enforce its own synchronization with the unprivileged fence.i
+instruction.
+
+CMODX in the Kernel Space
+-------------------------
+
+Dynamic ftrace
+---------------------
+
+Essentially, dynamic ftrace directs the control flow by inserting a function
+call at each patchable function entry, and patches it dynamically at runtime to
+enable or disable the redirection. In the case of RISC-V, 2 instructions,
+AUIPC + JALR, are required to compose a function call. However, it is impossible
+to patch 2 instructions and expect that a concurrent read-side executes them
+without a race condition. This series makes atmoic code patching possible in
+RISC-V ftrace. Kernel preemption makes things even worse as it allows the old
+state to persist across the patching process with stop_machine().
+
+In order to get rid of stop_machine() and run dynamic ftrace with full kernel
+preemption, we partially initialize each patchable function entry at boot-time,
+setting the first instruction to AUIPC, and the second to NOP. Now, atmoic
+patching is possible because the kernel only has to update one instruction.
+According to Ziccif, as long as an instruction is naturally aligned, the ISA
+guarantee an atomic update.
+
+By fixing down the first instruction, AUIPC, the range of the ftrace trampoline
+is limited to +-2K from the predetermined target, ftrace_caller, due to the lack
+of immediate encoding space in RISC-V. To address the issue, we introduce
+CALL_OPS, where an 8B naturally align metadata is added in front of each
+pacthable function. The metadata is resolved at the first trampoline, then the
+execution can be derect to another custom trampoline.
+
+CMODX in the User Space
+-----------------------
+
+Though fence.i is an unprivileged instruction, the default Linux ABI prohibits
+the use of fence.i in userspace applications. At any point the scheduler may
+migrate a task onto a new hart. If migration occurs after the userspace
+synchronized the icache and instruction storage with fence.i, the icache on the
+new hart will no longer be clean. This is due to the behavior of fence.i only
+affecting the hart that it is called on. Thus, the hart that the task has been
+migrated to may not have synchronized instruction storage and icache.
+
+There are two ways to solve this problem: use the riscv_flush_icache() syscall,
+or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl() and emit fence.i in
+userspace. The syscall performs a one-off icache flushing operation. The prctl
+changes the Linux ABI to allow userspace to emit icache flushing operations.
+
+As an aside, "deferred" icache flushes can sometimes be triggered in the kernel.
+At the time of writing, this only occurs during the riscv_flush_icache() syscall
+and when the kernel uses copy_to_user_page(). These deferred flushes happen only
+when the memory map being used by a hart changes. If the prctl() context caused
+an icache flush, this deferred icache flush will be skipped as it is redundant.
+Therefore, there will be no additional flush when using the riscv_flush_icache()
+syscall inside of the prctl() context.
+
+prctl() Interface
+---------------------
+
+Call prctl() with ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` as the first argument. The
+remaining arguments will be delegated to the riscv_set_icache_flush_ctx
+function detailed below.
+
+.. kernel-doc:: arch/riscv/mm/cacheflush.c
+ :identifiers: riscv_set_icache_flush_ctx
+
+Example usage:
+
+The following files are meant to be compiled and linked with each other. The
+modify_instruction() function replaces an add with 0 with an add with one,
+causing the instruction sequence in get_value() to change from returning a zero
+to returning a one.
+
+cmodx.c::
+
+ #include <stdio.h>
+ #include <sys/prctl.h>
+
+ extern int get_value();
+ extern void modify_instruction();
+
+ int main()
+ {
+ int value = get_value();
+ printf("Value before cmodx: %d\n", value);
+
+ // Call prctl before first fence.i is called inside modify_instruction
+ prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI_ON, PR_RISCV_SCOPE_PER_PROCESS);
+ modify_instruction();
+ // Call prctl after final fence.i is called in process
+ prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI_OFF, PR_RISCV_SCOPE_PER_PROCESS);
+
+ value = get_value();
+ printf("Value after cmodx: %d\n", value);
+ return 0;
+ }
+
+cmodx.S::
+
+ .option norvc
+
+ .text
+ .global modify_instruction
+ modify_instruction:
+ lw a0, new_insn
+ lui a5,%hi(old_insn)
+ sw a0,%lo(old_insn)(a5)
+ fence.i
+ ret
+
+ .section modifiable, "awx"
+ .global get_value
+ get_value:
+ li a0, 0
+ old_insn:
+ addi a0, a0, 0
+ ret
+
+ .data
+ new_insn:
+ addi a0, a0, 1
diff --git a/Documentation/arch/riscv/features.rst b/Documentation/arch/riscv/features.rst
new file mode 100644
index 000000000000..36e90144adab
--- /dev/null
+++ b/Documentation/arch/riscv/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features riscv
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
new file mode 100644
index 000000000000..06c5280b728a
--- /dev/null
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -0,0 +1,381 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+RISC-V Hardware Probing Interface
+---------------------------------
+
+The RISC-V hardware probing interface is based around a single syscall, which
+is defined in <asm/hwprobe.h>::
+
+ struct riscv_hwprobe {
+ __s64 key;
+ __u64 value;
+ };
+
+ long sys_riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count,
+ size_t cpusetsize, cpu_set_t *cpus,
+ unsigned int flags);
+
+The arguments are split into three groups: an array of key-value pairs, a CPU
+set, and some flags. The key-value pairs are supplied with a count. Userspace
+must prepopulate the key field for each element, and the kernel will fill in the
+value if the key is recognized. If a key is unknown to the kernel, its key field
+will be cleared to -1, and its value set to 0. The CPU set is defined by
+CPU_SET(3) with size ``cpusetsize`` bytes. For value-like keys (eg. vendor,
+arch, impl), the returned value will only be valid if all CPUs in the given set
+have the same value. Otherwise -1 will be returned. For boolean-like keys, the
+value returned will be a logical AND of the values for the specified CPUs.
+Usermode can supply NULL for ``cpus`` and 0 for ``cpusetsize`` as a shortcut for
+all online CPUs. The currently supported flags are:
+
+* :c:macro:`RISCV_HWPROBE_WHICH_CPUS`: This flag basically reverses the behavior
+ of sys_riscv_hwprobe(). Instead of populating the values of keys for a given
+ set of CPUs, the values of each key are given and the set of CPUs is reduced
+ by sys_riscv_hwprobe() to only those which match each of the key-value pairs.
+ How matching is done depends on the key type. For value-like keys, matching
+ means to be the exact same as the value. For boolean-like keys, matching
+ means the result of a logical AND of the pair's value with the CPU's value is
+ exactly the same as the pair's value. Additionally, when ``cpus`` is an empty
+ set, then it is initialized to all online CPUs which fit within it, i.e. the
+ CPU set returned is the reduction of all the online CPUs which can be
+ represented with a CPU set of size ``cpusetsize``.
+
+All other flags are reserved for future compatibility and must be zero.
+
+On success 0 is returned, on failure a negative error code is returned.
+
+The following keys are defined:
+
+* :c:macro:`RISCV_HWPROBE_KEY_MVENDORID`: Contains the value of ``mvendorid``,
+ as defined by the RISC-V privileged architecture specification.
+
+* :c:macro:`RISCV_HWPROBE_KEY_MARCHID`: Contains the value of ``marchid``, as
+ defined by the RISC-V privileged architecture specification.
+
+* :c:macro:`RISCV_HWPROBE_KEY_MIMPID`: Contains the value of ``mimpid``, as
+ defined by the RISC-V privileged architecture specification.
+
+* :c:macro:`RISCV_HWPROBE_KEY_BASE_BEHAVIOR`: A bitmask containing the base
+ user-visible behavior that this kernel supports. The following base user ABIs
+ are defined:
+
+ * :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: Support for rv32ima or
+ rv64ima, as defined by version 2.2 of the user ISA and version 1.10 of the
+ privileged ISA, with the following known exceptions (more exceptions may be
+ added, but only if it can be demonstrated that the user ABI is not broken):
+
+ * The ``fence.i`` instruction cannot be directly executed by userspace
+ programs (it may still be executed in userspace via a
+ kernel-controlled mechanism such as the vDSO).
+
+* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`: A bitmask containing the extensions
+ that are compatible with the :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`:
+ base system behavior.
+
+ * :c:macro:`RISCV_HWPROBE_IMA_FD`: The F and D extensions are supported, as
+ defined by commit cd20cee ("FMIN/FMAX now implement
+ minimumNumber/maximumNumber, not minNum/maxNum") of the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_IMA_C`: The C extension is supported, as defined
+ by version 2.2 of the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_IMA_V`: The V extension is supported, as defined by
+ version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is
+ supported, as defined in version 1.0 of the Bit-Manipulation ISA
+ extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBKB` The Zbkb extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBKC` The Zbkc extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZBKX` The Zbkx extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKND` The Zknd extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKNE` The Zkne extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKNH` The Zknh extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKSED` The Zksed extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKSH` The Zksh extension is supported, as
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZKT` The Zkt extension is supported, as defined
+ in version 1.0 of the Scalar Crypto ISA extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVBB`: The Zvbb extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVBC`: The Zvbc extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKB`: The Zvkb extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKG`: The Zvkg extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKNED`: The Zvkned extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKNHA`: The Zvknha extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKNHB`: The Zvknhb extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKSED`: The Zvksed extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKSH`: The Zvksh extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVKT`: The Zvkt extension is supported as
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFH`: The Zfh extension version 1.0 is supported
+ as defined in the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFHMIN`: The Zfhmin extension version 1.0 is
+ supported as defined in the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZIHINTNTL`: The Zihintntl extension version 1.0
+ is supported as defined in the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFH`: The Zvfh extension is supported as
+ defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
+ ("Remove draft warnings from Zvfh[min]").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFHMIN`: The Zvfhmin extension is supported as
+ defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
+ ("Remove draft warnings from Zvfh[min]").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFA`: The Zfa extension is supported as
+ defined in the RISC-V ISA manual starting from commit 056b6ff467c7
+ ("Zfa is ratified").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZTSO`: The Ztso extension is supported as
+ defined in the RISC-V ISA manual starting from commit 5618fb5a216b
+ ("Ztso is now ratified.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZACAS`: The Zacas extension is supported as
+ defined in the Atomic Compare-and-Swap (CAS) instructions manual starting
+ from commit 5059e0ca641c ("update to ratified").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICNTR`: The Zicntr extension version 2.0
+ is supported as defined in the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICOND`: The Zicond extension is supported as
+ defined in the RISC-V Integer Conditional (Zicond) operations extension
+ manual starting from commit 95cf1f9 ("Add changes requested by Ved
+ during signoff")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZIHINTPAUSE`: The Zihintpause extension is
+ supported as defined in the RISC-V ISA manual starting from commit
+ d8ab5c78c207 ("Zihintpause is ratified").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZIHPM`: The Zihpm extension version 2.0
+ is supported as defined in the RISC-V ISA manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE32F`: The Vector sub-extension Zve32f is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE64X`: The Vector sub-extension Zve64x is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE64F`: The Vector sub-extension Zve64f is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVE64D`: The Vector sub-extension Zve64d is
+ supported, as defined by version 1.0 of the RISC-V Vector extension manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZIMOP`: The Zimop May-Be-Operations extension is
+ supported as defined in the RISC-V ISA manual starting from commit
+ 58220614a5f ("Zimop is ratified/1.0").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZCA`: The Zca extension part of Zc* standard
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZCB`: The Zcb extension part of Zc* standard
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZCD`: The Zcd extension part of Zc* standard
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZCF`: The Zcf extension part of Zc* standard
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZCMOP`: The Zcmop May-Be-Operations extension is
+ supported as defined in the RISC-V ISA manual starting from commit
+ c732a4f39a4 ("Zcmop is ratified/1.0").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZAWRS`: The Zawrs extension is supported as
+ ratified in commit 98918c844281 ("Merge pull request #1217 from
+ riscv/zawrs") of riscv-isa-manual.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZAAMO`: The Zaamo extension is supported as
+ defined in the in the RISC-V ISA manual starting from commit e87412e621f1
+ ("integrate Zaamo and Zalrsc text (#1304)").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZALASR`: The Zalasr extension is supported as
+ frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZALRSC`: The Zalrsc extension is supported as
+ defined in the in the RISC-V ISA manual starting from commit e87412e621f1
+ ("integrate Zaamo and Zalrsc text (#1304)").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_SUPM`: The Supm extension is supported as
+ defined in version 1.0 of the RISC-V Pointer Masking extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZFBFMIN`: The Zfbfmin extension is supported as
+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de
+ ("Added Chapter title to BF16").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFBFMIN`: The Zvfbfmin extension is supported as
+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de
+ ("Added Chapter title to BF16").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFBFWMA`: The Zvfbfwma extension is supported as
+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de
+ ("Added Chapter title to BF16").
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICBOM`: The Zicbom extension is supported, as
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZABHA`: The Zabha extension is supported as
+ ratified in commit 49f49c842ff9 ("Update to Rafified state") of
+ riscv-zabha.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICBOP`: The Zicbop extension is supported, as
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
+ :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
+ mistakenly classified as a bitmask rather than a value.
+
+* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing
+ the performance of misaligned scalar native word accesses on the selected set
+ of processors.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN`: The performance of
+ misaligned scalar accesses is unknown.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED`: Misaligned scalar
+ accesses are emulated via software, either in or below the kernel. These
+ accesses are always extremely slow.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW`: Misaligned scalar native
+ word sized accesses are slower than the equivalent quantity of byte
+ accesses. Misaligned accesses may be supported directly in hardware, or
+ trapped and emulated by software.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_FAST`: Misaligned scalar native
+ word sized accesses are faster than the equivalent quantity of byte
+ accesses.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED`: Misaligned scalar
+ accesses are not supported at all and will generate a misaligned address
+ fault.
+
+* :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
+ represents the size of the Zicboz block in bytes.
+
+* :c:macro:`RISCV_HWPROBE_KEY_HIGHEST_VIRT_ADDRESS`: An unsigned long which
+ represent the highest userspace virtual address usable.
+
+* :c:macro:`RISCV_HWPROBE_KEY_TIME_CSR_FREQ`: Frequency (in Hz) of `time CSR`.
+
+* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`: An enum value describing the
+ performance of misaligned vector accesses on the selected set of processors.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_UNKNOWN`: The performance of misaligned
+ vector accesses is unknown.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_SLOW`: 32-bit misaligned accesses using vector
+ registers are slower than the equivalent quantity of byte accesses via vector registers.
+ Misaligned accesses may be supported directly in hardware, or trapped and emulated by software.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_FAST`: 32-bit misaligned accesses using vector
+ registers are faster than the equivalent quantity of byte accesses via vector registers.
+
+ * :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_UNSUPPORTED`: Misaligned vector accesses are
+ not supported at all and will generate a misaligned address fault.
+
+* :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_MIPS_0`: A bitmask containing the
+ mips vendor extensions that are compatible with the
+ :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
+
+ * MIPS
+
+ * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XMIPSEXECTL`: The xmipsexectl vendor
+ extension is supported in the MIPS ISA extensions spec.
+
+* :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0`: A bitmask containing the
+ thead vendor extensions that are compatible with the
+ :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
+
+ * T-HEAD
+
+ * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor
+ extension is supported in the T-Head ISA extensions spec starting from
+ commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
+
+* :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which
+ represents the size of the Zicbom block in bytes.
+
+* :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0`: A bitmask containing the
+ sifive vendor extensions that are compatible with the
+ :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
+
+ * SIFIVE
+
+ * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD`: The Xsfqmaccdod vendor
+ extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
+ Extensions Specification.
+
+ * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ`: The Xsfqmaccqoq vendor
+ extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
+ Instruction Extensions Specification.
+
+ * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF`: The Xsfvfnrclipxfqf
+ vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged
+ Clip Instructions Extensions Specification.
+
+ * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq
+ vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
+ Instruction Extensions Specification.
+
+* :c:macro:`RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE`: An unsigned int which
+ represents the size of the Zicbop block in bytes.
diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst
new file mode 100644
index 000000000000..eecf347ce849
--- /dev/null
+++ b/Documentation/arch/riscv/index.rst
@@ -0,0 +1,25 @@
+===================
+RISC-V architecture
+===================
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi
+ boot
+ boot-image-header
+ vm-layout
+ hwprobe
+ patch-acceptance
+ uabi
+ vector
+ cmodx
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arch/riscv/patch-acceptance.rst b/Documentation/arch/riscv/patch-acceptance.rst
new file mode 100644
index 000000000000..634aa222b410
--- /dev/null
+++ b/Documentation/arch/riscv/patch-acceptance.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+arch/riscv maintenance guidelines for developers
+================================================
+
+Overview
+--------
+The RISC-V instruction set architecture is developed in the open:
+in-progress drafts are available for all to review and to experiment
+with implementations. New module or extension drafts can change
+during the development process - sometimes in ways that are
+incompatible with previous drafts. This flexibility can present a
+challenge for RISC-V Linux maintenance. Linux maintainers disapprove
+of churn, and the Linux development process prefers well-reviewed and
+tested code over experimental code. We wish to extend these same
+principles to the RISC-V-related code that will be accepted for
+inclusion in the kernel.
+
+Patchwork
+---------
+
+RISC-V has a patchwork instance, where the status of patches can be checked:
+
+ https://patchwork.kernel.org/project/linux-riscv/list/
+
+If your patch does not appear in the default view, the RISC-V maintainers have
+likely either requested changes, or expect it to be applied to another tree.
+
+Automation runs against this patchwork instance, building/testing patches as
+they arrive. The automation applies patches against the current HEAD of the
+RISC-V `for-next` and `fixes` branches, depending on whether the patch has been
+detected as a fix. Failing those, it will use the RISC-V `master` branch.
+The exact commit to which a series has been applied will be noted on patchwork.
+Patches for which any of the checks fail are unlikely to be applied and in most
+cases will need to be resubmitted.
+
+Submit Checklist Addendum
+-------------------------
+We'll only accept patches for new modules or extensions if the
+specifications for those modules or extensions are listed as being
+unlikely to be incompatibly changed in the future. For
+specifications from the RISC-V foundation this means "Frozen" or
+"Ratified", for the UEFI forum specifications this means a published
+ECR. (Developers may, of course, maintain their own Linux kernel trees
+that contain code for any draft extensions that they wish.)
+
+Additionally, the RISC-V specification allows implementers to create
+their own custom extensions. These custom extensions aren't required
+to go through any review or ratification process by the RISC-V
+Foundation. To avoid the maintenance complexity and potential
+performance impact of adding kernel code for implementor-specific
+RISC-V extensions, we'll only consider patches for extensions that either:
+
+- Have been officially frozen or ratified by the RISC-V Foundation, or
+- Have been implemented in hardware that is widely available, per standard
+ Linux practice.
+
+(Implementers, may, of course, maintain their own Linux kernel trees containing
+code for any custom extensions that they wish.)
diff --git a/Documentation/arch/riscv/uabi.rst b/Documentation/arch/riscv/uabi.rst
new file mode 100644
index 000000000000..243e40062e34
--- /dev/null
+++ b/Documentation/arch/riscv/uabi.rst
@@ -0,0 +1,86 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+RISC-V Linux User ABI
+=====================
+
+ISA string ordering in /proc/cpuinfo
+------------------------------------
+
+The canonical order of ISA extension names in the ISA string is defined in
+chapter 27 of the unprivileged specification.
+The specification uses vague wording, such as should, when it comes to ordering,
+so for our purposes the following rules apply:
+
+#. Single-letter extensions come first, in canonical order.
+ The canonical order is "IMAFDQLCBKJTPVH".
+
+#. All multi-letter extensions will be separated from other extensions by an
+ underscore.
+
+#. Additional standard extensions (starting with 'Z') will be sorted after
+ single-letter extensions and before any higher-privileged extensions.
+
+#. For additional standard extensions, the first letter following the 'Z'
+ conventionally indicates the most closely related alphabetical
+ extension category. If multiple 'Z' extensions are named, they will be
+ ordered first by category, in canonical order, as listed above, then
+ alphabetically within a category.
+
+#. Standard supervisor-level extensions (starting with 'S') will be listed
+ after standard unprivileged extensions. If multiple supervisor-level
+ extensions are listed, they will be ordered alphabetically.
+
+#. Standard machine-level extensions (starting with 'Zxm') will be listed
+ after any lower-privileged, standard extensions. If multiple machine-level
+ extensions are listed, they will be ordered alphabetically.
+
+#. Non-standard extensions (starting with 'X') will be listed after all standard
+ extensions. If multiple non-standard extensions are listed, they will be
+ ordered alphabetically.
+
+An example string following the order is::
+
+ rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
+
+"isa" and "hart isa" lines in /proc/cpuinfo
+-------------------------------------------
+
+The "isa" line in /proc/cpuinfo describes the lowest common denominator of
+RISC-V ISA extensions recognized by the kernel and implemented on all harts. The
+"hart isa" line, in contrast, describes the set of extensions recognized by the
+kernel on the particular hart being described, even if those extensions may not
+be present on all harts in the system.
+
+In both lines, the presence of an extension guarantees only that the hardware
+has the described capability. Additional kernel support or policy changes may be
+required before an extension's capability is fully usable by userspace programs.
+Similarly, for S-mode extensions, presence in one of these lines does not
+guarantee that the kernel is taking advantage of the extension, or that the
+feature will be visible in guest VMs managed by this kernel.
+
+Inversely, the absence of an extension in these lines does not necessarily mean
+the hardware does not support that feature. The running kernel may not recognize
+the extension, or may have deliberately removed it from the listing.
+
+Misaligned accesses
+-------------------
+
+Misaligned scalar accesses are supported in userspace, but they may perform
+poorly. Misaligned vector accesses are only supported if the Zicclsm extension
+is supported.
+
+Pointer masking
+---------------
+
+Support for pointer masking in userspace (the Supm extension) is provided via
+the ``PR_SET_TAGGED_ADDR_CTRL`` and ``PR_GET_TAGGED_ADDR_CTRL`` ``prctl()``
+operations. Pointer masking is disabled by default. To enable it, userspace
+must call ``PR_SET_TAGGED_ADDR_CTRL`` with the ``PR_PMLEN`` field set to the
+number of mask/tag bits needed by the application. ``PR_PMLEN`` is interpreted
+as a lower bound; if the kernel is unable to satisfy the request, the
+``PR_SET_TAGGED_ADDR_CTRL`` operation will fail. The actual number of tag bits
+is returned in ``PR_PMLEN`` by the ``PR_GET_TAGGED_ADDR_CTRL`` operation.
+
+Additionally, when pointer masking is enabled (``PR_PMLEN`` is greater than 0),
+a tagged address ABI is supported, with the same interface and behavior as
+documented for AArch64 (Documentation/arch/arm64/tagged-address-abi.rst).
diff --git a/Documentation/arch/riscv/vector.rst b/Documentation/arch/riscv/vector.rst
new file mode 100644
index 000000000000..3987f5f76a9d
--- /dev/null
+++ b/Documentation/arch/riscv/vector.rst
@@ -0,0 +1,140 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Vector Extension Support for RISC-V Linux
+=========================================
+
+This document briefly outlines the interface provided to userspace by Linux in
+order to support the use of the RISC-V Vector Extension.
+
+1. prctl() Interface
+---------------------
+
+Two new prctl() calls are added to allow programs to manage the enablement
+status for the use of Vector in userspace. The intended usage guideline for
+these interfaces is to give init systems a way to modify the availability of V
+for processes running under its domain. Calling these interfaces is not
+recommended in libraries routines because libraries should not override policies
+configured from the parent process. Also, users must note that these interfaces
+are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
+to use in a portable code. To get the availability of V in an ELF program,
+please read :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
+auxiliary vector.
+
+* prctl(PR_RISCV_V_SET_CONTROL, unsigned long arg)
+
+ Sets the Vector enablement status of the calling thread, where the control
+ argument consists of two 2-bit enablement statuses and a bit for inheritance
+ mode. Other threads of the calling process are unaffected.
+
+ Enablement status is a tri-state value each occupying 2-bit of space in
+ the control argument:
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_DEFAULT`: Use the system-wide default
+ enablement status on execve(). The system-wide default setting can be
+ controlled via sysctl interface (see sysctl section below).
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_ON`: Allow Vector to be run for the
+ thread.
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_OFF`: Disallow Vector. Executing Vector
+ instructions under such condition will trap and casuse the termination of the thread.
+
+ arg: The control argument is a 5-bit value consisting of 3 parts, and
+ accessed by 3 masks respectively.
+
+ The 3 masks, PR_RISCV_V_VSTATE_CTRL_CUR_MASK,
+ PR_RISCV_V_VSTATE_CTRL_NEXT_MASK, and PR_RISCV_V_VSTATE_CTRL_INHERIT
+ represents bit[1:0], bit[3:2], and bit[4]. bit[1:0] accounts for the
+ enablement status of current thread, and the setting at bit[3:2] takes place
+ at next execve(). bit[4] defines the inheritance mode of the setting in
+ bit[3:2].
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_CUR_MASK`: bit[1:0]: Account for the
+ Vector enablement status for the calling thread. The calling thread is
+ not able to turn off Vector once it has been enabled. The prctl() call
+ fails with EPERM if the value in this mask is PR_RISCV_V_VSTATE_CTRL_OFF
+ but the current enablement status is not off. Setting
+ PR_RISCV_V_VSTATE_CTRL_DEFAULT here takes no effect but to set back
+ the original enablement status.
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_NEXT_MASK`: bit[3:2]: Account for the
+ Vector enablement setting for the calling thread at the next execve()
+ system call. If PR_RISCV_V_VSTATE_CTRL_DEFAULT is used in this mask,
+ then the enablement status will be decided by the system-wide
+ enablement status when execve() happen.
+
+ * :c:macro:`PR_RISCV_V_VSTATE_CTRL_INHERIT`: bit[4]: the inheritance
+ mode for the setting at PR_RISCV_V_VSTATE_CTRL_NEXT_MASK. If the bit
+ is set then the following execve() will not clear the setting in both
+ PR_RISCV_V_VSTATE_CTRL_NEXT_MASK and PR_RISCV_V_VSTATE_CTRL_INHERIT.
+ This setting persists across changes in the system-wide default value.
+
+ Return value:
+ * 0 on success;
+ * EINVAL: Vector not supported, invalid enablement status for current or
+ next mask;
+ * EPERM: Turning off Vector in PR_RISCV_V_VSTATE_CTRL_CUR_MASK if Vector
+ was enabled for the calling thread.
+
+ On success:
+ * A valid setting for PR_RISCV_V_VSTATE_CTRL_CUR_MASK takes place
+ immediately. The enablement status specified in
+ PR_RISCV_V_VSTATE_CTRL_NEXT_MASK happens at the next execve() call, or
+ all following execve() calls if PR_RISCV_V_VSTATE_CTRL_INHERIT bit is
+ set.
+ * Every successful call overwrites a previous setting for the calling
+ thread.
+
+* prctl(PR_RISCV_V_GET_CONTROL)
+
+ Gets the same Vector enablement status for the calling thread. Setting for
+ next execve() call and the inheritance bit are all OR-ed together.
+
+ Note that ELF programs are able to get the availability of V for itself by
+ reading :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
+ auxiliary vector.
+
+ Return value:
+ * a nonnegative value on success;
+ * EINVAL: Vector not supported.
+
+2. System runtime configuration (sysctl)
+-----------------------------------------
+
+To mitigate the ABI impact of expansion of the signal stack, a
+policy mechanism is provided to the administrators, distro maintainers, and
+developers to control the default Vector enablement status for userspace
+processes in form of sysctl knob:
+
+* /proc/sys/abi/riscv_v_default_allow
+
+ Writing the text representation of 0 or 1 to this file sets the default
+ system enablement status for new starting userspace programs. Valid values
+ are:
+
+ * 0: Do not allow Vector code to be executed as the default for new processes.
+ * 1: Allow Vector code to be executed as the default for new processes.
+
+ Reading this file returns the current system default enablement status.
+
+ At every execve() call, a new enablement status of the new process is set to
+ the system default, unless:
+
+ * PR_RISCV_V_VSTATE_CTRL_INHERIT is set for the calling process, and the
+ setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not
+ PR_RISCV_V_VSTATE_CTRL_DEFAULT. Or,
+
+ * The setting in PR_RISCV_V_VSTATE_CTRL_NEXT_MASK is not
+ PR_RISCV_V_VSTATE_CTRL_DEFAULT.
+
+ Modifying the system default enablement status does not affect the enablement
+ status of any existing process of thread that do not make an execve() call.
+
+3. Vector Register State Across System Calls
+---------------------------------------------
+
+As indicated by version 1.0 of the V extension [1], vector registers are
+clobbered by system calls.
+
+1: https://github.com/riscv/riscv-v-spec/blob/master/calling-convention.adoc
diff --git a/Documentation/arch/riscv/vm-layout.rst b/Documentation/arch/riscv/vm-layout.rst
new file mode 100644
index 000000000000..eabec99b5852
--- /dev/null
+++ b/Documentation/arch/riscv/vm-layout.rst
@@ -0,0 +1,136 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Virtual Memory Layout on RISC-V Linux
+=====================================
+
+:Author: Alexandre Ghiti <alex@ghiti.fr>
+:Date: 12 February 2021
+
+This document describes the virtual memory layout used by the RISC-V Linux
+Kernel.
+
+RISC-V Linux Kernel 32bit
+=========================
+
+RISC-V Linux Kernel SV32
+------------------------
+
+TODO
+
+RISC-V Linux Kernel 64bit
+=========================
+
+The RISC-V privileged architecture document states that the 64bit addresses
+"must have bits 63–48 all equal to bit 47, or else a page-fault exception will
+occur.": that splits the virtual address space into 2 halves separated by a very
+big hole, the lower half is where the userspace resides, the upper half is where
+the RISC-V Linux Kernel resides.
+
+RISC-V Linux Kernel SV39
+------------------------
+
+::
+
+ ========================================================================================================================
+ Start addr | Offset | End addr | Size | VM area description
+ ========================================================================================================================
+ | | | |
+ 0000000000000000 | 0 | 0000003fffffffff | 256 GB | user-space virtual memory, different per mm
+ __________________|____________|__________________|_________|___________________________________________________________
+ | | | |
+ 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -256 GB
+ | | | | starting offset of kernel mappings.
+ __________________|____________|__________________|_________|___________________________________________________________
+ |
+ | Kernel-space virtual memory, shared between all processes:
+ ____________________________________________________________|___________________________________________________________
+ | | | |
+ ffffffc4fea00000 | -236 GB | ffffffc4feffffff | 6 MB | fixmap
+ ffffffc4ff000000 | -236 GB | ffffffc4ffffffff | 16 MB | PCI io
+ ffffffc500000000 | -236 GB | ffffffc5ffffffff | 4 GB | vmemmap
+ ffffffc600000000 | -232 GB | ffffffd5ffffffff | 64 GB | vmalloc/ioremap space
+ ffffffd600000000 | -168 GB | fffffff5ffffffff | 128 GB | direct mapping of all physical memory
+ | | | |
+ fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan
+ __________________|____________|__________________|_________|____________________________________________________________
+ |
+ |
+ ____________________________________________________________|____________________________________________________________
+ | | | |
+ ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
+ ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
+ __________________|____________|__________________|_________|____________________________________________________________
+
+
+RISC-V Linux Kernel SV48
+------------------------
+
+::
+
+ ========================================================================================================================
+ Start addr | Offset | End addr | Size | VM area description
+ ========================================================================================================================
+ | | | |
+ 0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm
+ __________________|____________|__________________|_________|___________________________________________________________
+ | | | |
+ 0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -128 TB
+ | | | | starting offset of kernel mappings.
+ __________________|____________|__________________|_________|___________________________________________________________
+ |
+ | Kernel-space virtual memory, shared between all processes:
+ ____________________________________________________________|___________________________________________________________
+ | | | |
+ ffff8d7ffea00000 | -114.5 TB | ffff8d7ffeffffff | 6 MB | fixmap
+ ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io
+ ffff8d8000000000 | -114.5 TB | ffff8f7fffffffff | 2 TB | vmemmap
+ ffff8f8000000000 | -112.5 TB | ffffaf7fffffffff | 32 TB | vmalloc/ioremap space
+ ffffaf8000000000 | -80.5 TB | ffffef7fffffffff | 64 TB | direct mapping of all physical memory
+ ffffef8000000000 | -16.5 TB | fffffffeffffffff | 16.5 TB | kasan
+ __________________|____________|__________________|_________|____________________________________________________________
+ |
+ | Identical layout to the 39-bit one from here on:
+ ____________________________________________________________|____________________________________________________________
+ | | | |
+ ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
+ ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
+ __________________|____________|__________________|_________|____________________________________________________________
+
+
+RISC-V Linux Kernel SV57
+------------------------
+
+::
+
+ ========================================================================================================================
+ Start addr | Offset | End addr | Size | VM area description
+ ========================================================================================================================
+ | | | |
+ 0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm
+ __________________|____________|__________________|_________|___________________________________________________________
+ | | | |
+ 0100000000000000 | +64 PB | feffffffffffffff | ~16K PB | ... huge, almost 64 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -64 PB
+ | | | | starting offset of kernel mappings.
+ __________________|____________|__________________|_________|___________________________________________________________
+ |
+ | Kernel-space virtual memory, shared between all processes:
+ ____________________________________________________________|___________________________________________________________
+ | | | |
+ ff1bfffffea00000 | -57 PB | ff1bfffffeffffff | 6 MB | fixmap
+ ff1bffffff000000 | -57 PB | ff1bffffffffffff | 16 MB | PCI io
+ ff1c000000000000 | -57 PB | ff1fffffffffffff | 1 PB | vmemmap
+ ff20000000000000 | -56 PB | ff5fffffffffffff | 16 PB | vmalloc/ioremap space
+ ff60000000000000 | -40 PB | ffdeffffffffffff | 32 PB | direct mapping of all physical memory
+ ffdf000000000000 | -8 PB | fffffffeffffffff | 8 PB | kasan
+ __________________|____________|__________________|_________|____________________________________________________________
+ |
+ | Identical layout to the 39-bit one from here on:
+ ____________________________________________________________|____________________________________________________________
+ | | | |
+ ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
+ ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
+ __________________|____________|__________________|_________|____________________________________________________________
diff --git a/Documentation/s390/3270.ChangeLog b/Documentation/arch/s390/3270.ChangeLog
index ecaf60b6c381..ecaf60b6c381 100644
--- a/Documentation/s390/3270.ChangeLog
+++ b/Documentation/arch/s390/3270.ChangeLog
diff --git a/Documentation/s390/3270.rst b/Documentation/arch/s390/3270.rst
index e09e77954238..467eace91473 100644
--- a/Documentation/s390/3270.rst
+++ b/Documentation/arch/s390/3270.rst
@@ -116,7 +116,7 @@ Here are the installation steps in detail:
as a 3270, not a 3215.
5. Run the 3270 configuration script config3270. It is
- distributed in this same directory, Documentation/s390, as
+ distributed in this same directory, Documentation/arch/s390, as
config3270.sh. Inspect the output script it produces,
/tmp/mkdev3270, and then run that script. This will create the
necessary character special device files and make the necessary
@@ -125,7 +125,7 @@ Here are the installation steps in detail:
Then notify /sbin/init that /etc/inittab has changed, by issuing
the telinit command with the q operand::
- cd Documentation/s390
+ cd Documentation/arch/s390
sh config3270.sh
sh /tmp/mkdev3270
telinit q
diff --git a/Documentation/s390/cds.rst b/Documentation/arch/s390/cds.rst
index 7006d8209d2e..bcad2a14244a 100644
--- a/Documentation/s390/cds.rst
+++ b/Documentation/arch/s390/cds.rst
@@ -39,7 +39,7 @@ some of them are ESA/390 platform specific.
Note:
In order to write a driver for S/390, you also need to look into the interface
- described in Documentation/s390/driver-model.rst.
+ described in Documentation/arch/s390/driver-model.rst.
Note for porting drivers from 2.4:
diff --git a/Documentation/s390/common_io.rst b/Documentation/arch/s390/common_io.rst
index 846485681ce7..6dcb40cb7145 100644
--- a/Documentation/s390/common_io.rst
+++ b/Documentation/arch/s390/common_io.rst
@@ -136,5 +136,5 @@ debugfs entries
The level of logging can be changed to be more or less verbose by piping to
/sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
- documentation on the S/390 debug feature (Documentation/s390/s390dbf.rst)
+ documentation on the S/390 debug feature (Documentation/arch/s390/s390dbf.rst)
for details.
diff --git a/Documentation/s390/config3270.sh b/Documentation/arch/s390/config3270.sh
index 515e2f431487..515e2f431487 100644
--- a/Documentation/s390/config3270.sh
+++ b/Documentation/arch/s390/config3270.sh
diff --git a/Documentation/s390/driver-model.rst b/Documentation/arch/s390/driver-model.rst
index ad4bc2dbea43..e7488f02bb78 100644
--- a/Documentation/s390/driver-model.rst
+++ b/Documentation/arch/s390/driver-model.rst
@@ -244,7 +244,7 @@ information about the interrupt from the irb parameter.
--------------------
The ccwgroup mechanism is designed to handle devices consisting of multiple ccw
-devices, like lcs or ctc.
+devices, like qeth or ctc.
The ccw driver provides a 'group' attribute. Piping bus ids of ccw devices to
this attributes creates a ccwgroup device consisting of these ccw devices (if
@@ -305,24 +305,3 @@ xpram shows up under devices/system/ as 'xpram'.
For each cpu, a directory is created under devices/system/cpu/. Each cpu has an
attribute 'online' which can be 0 or 1.
-
-
-4. Other devices
-----------------
-
-4.1 Netiucv
------------
-
-The netiucv driver creates an attribute 'connection' under
-bus/iucv/drivers/netiucv. Piping to this attribute creates a new netiucv
-connection to the specified host.
-
-Netiucv connections show up under devices/iucv/ as "netiucv<ifnum>". The interface
-number is assigned sequentially to the connections defined via the 'connection'
-attribute.
-
-user
- - shows the connection partner.
-
-buffer
- - maximum buffer size. Pipe to it to change buffer size.
diff --git a/Documentation/arch/s390/features.rst b/Documentation/arch/s390/features.rst
new file mode 100644
index 000000000000..2883dc950681
--- /dev/null
+++ b/Documentation/arch/s390/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features s390
diff --git a/Documentation/arch/s390/index.rst b/Documentation/arch/s390/index.rst
new file mode 100644
index 000000000000..e75a6e5d2505
--- /dev/null
+++ b/Documentation/arch/s390/index.rst
@@ -0,0 +1,31 @@
+=================
+s390 Architecture
+=================
+
+.. toctree::
+ :maxdepth: 1
+
+ cds
+ 3270
+ driver-model
+ mm
+ monreader
+ qeth
+ s390dbf
+ vfio-ap
+ vfio-ap-locking
+ vfio-ccw
+ zfcpdump
+ common_io
+ pci
+
+ text_files
+
+ features
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/arch/s390/mm.rst b/Documentation/arch/s390/mm.rst
new file mode 100644
index 000000000000..084adad5eef9
--- /dev/null
+++ b/Documentation/arch/s390/mm.rst
@@ -0,0 +1,111 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+Memory Management
+=================
+
+Virtual memory layout
+=====================
+
+.. note::
+
+ - Some aspects of the virtual memory layout setup are not
+ clarified (number of page levels, alignment, DMA memory).
+
+ - Unused gaps in the virtual memory layout could be present
+ or not - depending on how partucular system is configured.
+ No page tables are created for the unused gaps.
+
+ - The virtual memory regions are tracked or untracked by KASAN
+ instrumentation, as well as the KASAN shadow memory itself is
+ created only when CONFIG_KASAN configuration option is enabled.
+
+::
+
+ =============================================================================
+ | Physical | Virtual | VM area description
+ =============================================================================
+ +- 0 --------------+- 0 --------------+
+ | | S390_lowcore | Low-address memory
+ | +- 8 KB -----------+
+ | | |
+ | | |
+ | | ... unused gap | KASAN untracked
+ | | |
+ +- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
+ |.amode31 text/data|.amode31 text/data| KASAN untracked
+ +- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB)
+ | | |
+ | | |
+ +- __kaslr_offset_phys | kernel rand. phys start
+ | | |
+ | kernel text/data | |
+ | | |
+ +------------------+ | kernel phys end
+ | | |
+ | | |
+ | | |
+ | | |
+ +- ident_map_size -+ |
+ | |
+ | ... unused gap | KASAN untracked
+ | |
+ +- __identity_base + identity mapping start (>= 2GB)
+ | |
+ | identity | phys == virt - __identity_base
+ | mapping | virt == phys + __identity_base
+ | |
+ | | KASAN tracked
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +---- vmemmap -----+ 'struct page' array start
+ | |
+ | virtually mapped |
+ | memory map | KASAN untracked
+ | |
+ +- __abs_lowcore --+
+ | |
+ | Absolute Lowcore | KASAN untracked
+ | |
+ +- __memcpy_real_area
+ | |
+ | Real Memory Copy| KASAN untracked
+ | |
+ +- VMALLOC_START --+ vmalloc area start
+ | | KASAN untracked or
+ | vmalloc area | KASAN shallowly populated in case
+ | | CONFIG_KASAN_VMALLOC=y
+ +- MODULES_VADDR --+ modules area start
+ | | KASAN allocated per module or
+ | modules area | KASAN shallowly populated in case
+ | | CONFIG_KASAN_VMALLOC=y
+ +- __kaslr_offset -+ kernel rand. virt start
+ | | KASAN tracked
+ | kernel text/data | phys == (kvirt - __kaslr_offset) +
+ | | __kaslr_offset_phys
+ +- kernel .bss end + kernel rand. virt end
+ | |
+ | ... unused gap | KASAN untracked
+ | |
+ +------------------+ UltraVisor Secure Storage limit
+ | |
+ | ... unused gap | KASAN untracked
+ | |
+ +KASAN_SHADOW_START+ KASAN shadow memory start
+ | |
+ | KASAN shadow | KASAN untracked
+ | |
+ +------------------+ ASCE limit
diff --git a/Documentation/s390/monreader.rst b/Documentation/arch/s390/monreader.rst
index 21cdfb699b49..21cdfb699b49 100644
--- a/Documentation/s390/monreader.rst
+++ b/Documentation/arch/s390/monreader.rst
diff --git a/Documentation/s390/pci.rst b/Documentation/arch/s390/pci.rst
index 8157f0cddbc2..d5755484d8e7 100644
--- a/Documentation/s390/pci.rst
+++ b/Documentation/arch/s390/pci.rst
@@ -40,7 +40,7 @@ For example:
Change the level of logging to be more or less verbose by piping
a number between 0 and 6 to /sys/kernel/debug/s390dbf/pci_*/level. For
details, see the documentation on the S/390 debug feature at
- Documentation/s390/s390dbf.rst.
+ Documentation/arch/s390/s390dbf.rst.
Sysfs entries
=============
@@ -51,7 +51,7 @@ Entries specific to zPCI functions and entries that hold zPCI information.
The slot entries are set up using the function identifier (FID) of the
PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits
- with 0 padding and lower case hexadecimal digitis.
+ with 0 padding and lower case hexadecimal digits.
- /sys/bus/pci/slots/XXXXXXXX/power
@@ -66,7 +66,7 @@ Entries specific to zPCI functions and entries that hold zPCI information.
- function_handle
Low-level identifier used for a configured PCI function.
- It might be useful for debuging.
+ It might be useful for debugging.
- pchid
Model-dependent location of the I/O adapter.
diff --git a/Documentation/s390/qeth.rst b/Documentation/arch/s390/qeth.rst
index f02fdaa68de0..f02fdaa68de0 100644
--- a/Documentation/s390/qeth.rst
+++ b/Documentation/arch/s390/qeth.rst
diff --git a/Documentation/s390/s390dbf.rst b/Documentation/arch/s390/s390dbf.rst
index af8bdc3629e7..aad6d88974fe 100644
--- a/Documentation/s390/s390dbf.rst
+++ b/Documentation/arch/s390/s390dbf.rst
@@ -243,9 +243,8 @@ Examples:
Changing the size of debug areas
------------------------------------
-It is possible the change the size of debug areas through piping
-the number of pages to the debugfs file "pages". The resize request will
-also flush the debug areas.
+To resize a debug area, write the desired page count to the "pages" file.
+Existing data is preserved if it fits; otherwise, oldest entries are dropped.
Example:
diff --git a/Documentation/s390/text_files.rst b/Documentation/arch/s390/text_files.rst
index c94d05d4fa17..c94d05d4fa17 100644
--- a/Documentation/s390/text_files.rst
+++ b/Documentation/arch/s390/text_files.rst
diff --git a/Documentation/s390/vfio-ap-locking.rst b/Documentation/arch/s390/vfio-ap-locking.rst
index 0dfcdb562e21..0dfcdb562e21 100644
--- a/Documentation/s390/vfio-ap-locking.rst
+++ b/Documentation/arch/s390/vfio-ap-locking.rst
diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst
index 61a0a3c6c7b4..eba1991fbdba 100644
--- a/Documentation/s390/vfio-ap.rst
+++ b/Documentation/arch/s390/vfio-ap.rst
@@ -297,7 +297,7 @@ of the VFIO AP mediated device driver::
| MDEV CORE |
| MODULE |
| mdev.ko |
- | +---------+ | mdev_register_device() +--------------+
+ | +---------+ | mdev_register_parent() +--------------+
| |Physical | +<-----------------------+ |
| | device | | | vfio_ap.ko |<-> matrix
| |interface| +----------------------->+ | device
@@ -380,6 +380,36 @@ matrix device.
control_domains:
A read-only file for displaying the control domain numbers assigned to the
vfio_ap mediated device.
+ ap_config:
+ A read/write file that, when written to, allows all three of the
+ vfio_ap mediated device's ap matrix masks to be replaced in one shot.
+ Three masks are given, one for adapters, one for domains, and one for
+ control domains. If the given state cannot be set then no changes are
+ made to the vfio-ap mediated device.
+
+ The format of the data written to ap_config is as follows:
+ {amask},{dmask},{cmask}\n
+
+ \n is a newline character.
+
+ amask, dmask, and cmask are masks identifying which adapters, domains,
+ and control domains should be assigned to the mediated device.
+
+ The format of a mask is as follows:
+ 0xNN..NN
+
+ Where NN..NN is 64 hexadecimal characters representing a 256-bit value.
+ The leftmost (highest order) bit represents adapter/domain 0.
+
+ For an example set of masks that represent your mdev's current
+ configuration, simply cat ap_config.
+
+ Setting an adapter or domain number greater than the maximum allowed for
+ the system will result in an error.
+
+ This attribute is intended to be used by automation. End users would be
+ better served using the respective assign/unassign attributes for
+ adapters, domains, and control domains.
* functions:
@@ -422,7 +452,7 @@ Configure the guest's AP resources
Configuring the AP resources for a KVM guest will be performed when the
VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier
function is called when userspace connects to KVM. The guest's AP resources are
-configured via it's APCB by:
+configured via its APCB by:
* Setting the bits in the APM corresponding to the APIDs assigned to the
vfio_ap mediated device via its 'assign_adapter' interface.
@@ -550,10 +580,8 @@ These are the steps:
following Kconfig elements selected:
* IOMMU_SUPPORT
* S390
- * ZCRYPT
- * S390_AP_IOMMU
+ * AP
* VFIO
- * VFIO_MDEV
* KVM
If using make menuconfig select the following to build the vfio_ap module::
@@ -971,6 +999,36 @@ the vfio_ap mediated device to which it is assigned as long as each new APQN
resulting from plugging it in references a queue device bound to the vfio_ap
device driver.
+Driver Features
+===============
+The vfio_ap driver exposes a sysfs file containing supported features.
+This exists so third party tools (like Libvirt and mdevctl) can query the
+availability of specific features.
+
+The features list can be found here: /sys/bus/matrix/devices/matrix/features
+
+Entries are space delimited. Each entry consists of a combination of
+alphanumeric and underscore characters.
+
+Example:
+cat /sys/bus/matrix/devices/matrix/features
+guest_matrix dyn ap_config
+
+the following features are advertised:
+
+---------------+---------------------------------------------------------------+
+| Flag | Description |
++==============+===============================================================+
+| guest_matrix | guest_matrix attribute exists. It reports the matrix of |
+| | adapters and domains that are or will be passed through to a |
+| | guest when the mdev is attached to it. |
++--------------+---------------------------------------------------------------+
+| dyn | Indicates hot plug/unplug of AP adapters, domains and control |
+| | domains for a guest to which the mdev is attached. |
++------------+-----------------------------------------------------------------+
+| ap_config | ap_config interface for one-shot modifications to mdev config |
++--------------+---------------------------------------------------------------+
+
Limitations
===========
Live guest migration is not supported for guests using AP devices without
diff --git a/Documentation/s390/vfio-ccw.rst b/Documentation/arch/s390/vfio-ccw.rst
index 8aad08a8b8a5..42960b7b0d70 100644
--- a/Documentation/s390/vfio-ccw.rst
+++ b/Documentation/arch/s390/vfio-ccw.rst
@@ -156,7 +156,7 @@ Below is a high Level block diagram::
| MDEV CORE |
| MODULE |
| mdev.ko |
- | +---------+ | mdev_register_device() +--------------+
+ | +---------+ | mdev_register_parent() +--------------+
| |Physical | +<-----------------------+ |
| | device | | | vfio_ccw.ko |<-> subchannel
| |interface| +----------------------->+ | device
@@ -176,7 +176,7 @@ The process of how these work together.
Use the 'mdev_create' sysfs file, we need to manually create one (and
only one for our case) mediated device.
3. vfio_mdev.ko drives the mediated ccw device.
- vfio_mdev is also the vfio device drvier. It will probe the mdev and
+ vfio_mdev is also the vfio device driver. It will probe the mdev and
add it to an iommu_group and a vfio_group. Then we could pass through
the mdev to a guest.
@@ -219,8 +219,8 @@ values may occur:
The operation was successful.
``-EOPNOTSUPP``
- The orb specified transport mode or an unidentified IDAW format, or the
- scsw specified a function other than the start function.
+ The ORB specified transport mode or the
+ SCSW specified a function other than the start function.
``-EIO``
A request was issued while the device was not in a state ready to accept
@@ -440,6 +440,6 @@ Reference
1. ESA/s390 Principles of Operation manual (IBM Form. No. SA22-7832)
2. ESA/390 Common I/O Device Commands manual (IBM Form. No. SA22-7204)
3. https://en.wikipedia.org/wiki/Channel_I/O
-4. Documentation/s390/cds.rst
+4. Documentation/arch/s390/cds.rst
5. Documentation/driver-api/vfio.rst
6. Documentation/driver-api/vfio-mediated-device.rst
diff --git a/Documentation/s390/zfcpdump.rst b/Documentation/arch/s390/zfcpdump.rst
index a61de7aa8778..a61de7aa8778 100644
--- a/Documentation/s390/zfcpdump.rst
+++ b/Documentation/arch/s390/zfcpdump.rst
diff --git a/Documentation/sh/booting.rst b/Documentation/arch/sh/booting.rst
index d851c49a01bf..d851c49a01bf 100644
--- a/Documentation/sh/booting.rst
+++ b/Documentation/arch/sh/booting.rst
diff --git a/Documentation/arch/sh/features.rst b/Documentation/arch/sh/features.rst
new file mode 100644
index 000000000000..fae48fe81e9b
--- /dev/null
+++ b/Documentation/arch/sh/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features sh
diff --git a/Documentation/arch/sh/index.rst b/Documentation/arch/sh/index.rst
new file mode 100644
index 000000000000..01fce7c131f1
--- /dev/null
+++ b/Documentation/arch/sh/index.rst
@@ -0,0 +1,50 @@
+=======================
+SuperH Interfaces Guide
+=======================
+
+:Author: Paul Mundt
+
+.. toctree::
+ :maxdepth: 1
+
+ booting
+ new-machine
+ register-banks
+
+ features
+
+Memory Management
+=================
+
+SH-4
+----
+
+Store Queue API
+~~~~~~~~~~~~~~~
+
+.. kernel-doc:: arch/sh/kernel/cpu/sh4/sq.c
+ :export:
+
+Machine Specific Interfaces
+===========================
+
+mach-dreamcast
+--------------
+
+.. kernel-doc:: arch/sh/boards/mach-dreamcast/rtc.c
+ :internal:
+
+mach-x3proto
+------------
+
+.. kernel-doc:: arch/sh/boards/mach-x3proto/ilsel.c
+ :export:
+
+Busses
+======
+
+Maple
+-----
+
+.. kernel-doc:: drivers/sh/maple/maple.c
+ :export:
diff --git a/Documentation/sh/new-machine.rst b/Documentation/arch/sh/new-machine.rst
index e501c52b3b30..e501c52b3b30 100644
--- a/Documentation/sh/new-machine.rst
+++ b/Documentation/arch/sh/new-machine.rst
diff --git a/Documentation/sh/register-banks.rst b/Documentation/arch/sh/register-banks.rst
index 2bef5c8fcbbc..2bef5c8fcbbc 100644
--- a/Documentation/sh/register-banks.rst
+++ b/Documentation/arch/sh/register-banks.rst
diff --git a/Documentation/sparc/adi.rst b/Documentation/arch/sparc/adi.rst
index 857ad30f9569..dbcd8b6e7bc3 100644
--- a/Documentation/sparc/adi.rst
+++ b/Documentation/arch/sparc/adi.rst
@@ -38,7 +38,7 @@ virtual addresses that contain 0xa in bits 63-60.
ADI is enabled on a set of pages using mprotect() with PROT_ADI flag.
When ADI is enabled on a set of pages by a task for the first time,
-kernel sets the PSTATE.mcde bit fot the task. Version tags for memory
+kernel sets the PSTATE.mcde bit for the task. Version tags for memory
addresses are set with an stxa instruction on the addresses using
ASI_MCD_PRIMARY or ASI_MCD_ST_BLKINIT_PRIMARY. ADI block size is
provided by the hypervisor to the kernel. Kernel returns the value of
@@ -97,7 +97,7 @@ With ADI enabled, following new traps may occur:
Disrupting memory corruption
----------------------------
- When a store accesses a memory localtion that has TTE.mcd=1,
+ When a store accesses a memory location that has TTE.mcd=1,
the task is running with ADI enabled (PSTATE.mcde=1), and the ADI
tag in the address used (bits 63:60) does not match the tag set on
the corresponding cacheline, a memory corruption trap occurs. By
diff --git a/Documentation/sparc/console.rst b/Documentation/arch/sparc/console.rst
index 73132db83ece..73132db83ece 100644
--- a/Documentation/sparc/console.rst
+++ b/Documentation/arch/sparc/console.rst
diff --git a/Documentation/arch/sparc/features.rst b/Documentation/arch/sparc/features.rst
new file mode 100644
index 000000000000..96835b6d598a
--- /dev/null
+++ b/Documentation/arch/sparc/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features sparc
diff --git a/Documentation/sparc/index.rst b/Documentation/arch/sparc/index.rst
index ae884224eec2..ae884224eec2 100644
--- a/Documentation/sparc/index.rst
+++ b/Documentation/arch/sparc/index.rst
diff --git a/Documentation/sparc/oradax/dax-hv-api.txt b/Documentation/arch/sparc/oradax/dax-hv-api.txt
index 73e8d506cf64..ef1a4c2bf08b 100644
--- a/Documentation/sparc/oradax/dax-hv-api.txt
+++ b/Documentation/arch/sparc/oradax/dax-hv-api.txt
@@ -22,7 +22,7 @@ Chapter 36. Coprocessor services
functionality offered may vary by virtual machine implementation.
The DAX is a virtual device to sun4v guests, with supported data operations indicated by the virtual device
- compatibilty property. Functionality is accessed through the submission of Command Control Blocks
+ compatibility property. Functionality is accessed through the submission of Command Control Blocks
(CCBs) via the ccb_submit API function. The operations are processed asynchronously, with the status
of the submitted operations reported through a Completion Area linked to each CCB. Each CCB has a
separate Completion Area and, unless execution order is specifically restricted through the use of serial-
@@ -41,7 +41,7 @@ Chapter 36. Coprocessor services
submissions until they succeed; waiting for an outstanding CCB to complete is not necessary, and would
not be a guarantee that a future submission would succeed.
- The availablility of DAX coprocessor command service is indicated by the presence of the DAX virtual
+ The availability of DAX coprocessor command service is indicated by the presence of the DAX virtual
device node in the guest MD (Section 8.24.17, “Database Analytics Accelerators (DAX) virtual-device
node”).
@@ -313,7 +313,7 @@ bits set, and terminate at a CCB that has the Conditional bit set, but not the P
Secondary Input Description
Format Code
- 0 Element is stored as value minus 1 (0 evalutes to 1, 1 evalutes
+ 0 Element is stored as value minus 1 (0 evaluates to 1, 1 evaluates
to 2, etc)
1 Element is stored as value
@@ -659,7 +659,7 @@ Offset Size Field Description
“Secondary Input Element Size”
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9:5] Operand size for first scan criteria value. In a scan value
- operation, this is one of two potential extact match values.
+ operation, this is one of two potential exact match values.
In a scan range operation, this is the size of the upper range
@@ -673,7 +673,7 @@ Offset Size Field Description
operand, minus 1. Values 0xF-0x1E are reserved. A value of
0x1F indicates this operand is not in use for this scan operation.
[4:0] Operand size for second scan criteria value. In a scan value
- operation, this is one of two potential extact match values.
+ operation, this is one of two potential exact match values.
In a scan range operation, this is the size of the lower range
boundary. The value of this field is the number of bytes in the
operand, minus 1. Values 0xF-0x1E are reserved. A value of
@@ -690,24 +690,24 @@ Offset Size Field Description
48 8 Output (same fields as Primary Input)
56 8 Symbol Table (if used by Primary Input). Same fields as Section 36.2.1.2,
“Extract command”
-64 4 Next 4 most significant bytes of first scan criteria operand occuring after the
+64 4 Next 4 most significant bytes of first scan criteria operand occurring after the
bytes specified at offset 40, if needed by the operand size. If first operand
is less than 8 bytes, the valid bytes are left-aligned to the lowest address.
-68 4 Next 4 most significant bytes of second scan criteria operand occuring after
+68 4 Next 4 most significant bytes of second scan criteria operand occurring after
the bytes specified at offset 44, if needed by the operand size. If second
operand is less than 8 bytes, the valid bytes are left-aligned to the lowest
address.
-72 4 Next 4 most significant bytes of first scan criteria operand occuring after the
+72 4 Next 4 most significant bytes of first scan criteria operand occurring after the
bytes specified at offset 64, if needed by the operand size. If first operand
is less than 12 bytes, the valid bytes are left-aligned to the lowest address.
-76 4 Next 4 most significant bytes of second scan criteria operand occuring after
+76 4 Next 4 most significant bytes of second scan criteria operand occurring after
the bytes specified at offset 68, if needed by the operand size. If second
operand is less than 12 bytes, the valid bytes are left-aligned to the lowest
address.
-80 4 Next 4 most significant bytes of first scan criteria operand occuring after the
+80 4 Next 4 most significant bytes of first scan criteria operand occurring after the
bytes specified at offset 72, if needed by the operand size. If first operand
is less than 16 bytes, the valid bytes are left-aligned to the lowest address.
-84 4 Next 4 most significant bytes of second scan criteria operand occuring after
+84 4 Next 4 most significant bytes of second scan criteria operand occurring after
the bytes specified at offset 76, if needed by the operand size. If second
operand is less than 16 bytes, the valid bytes are left-aligned to the lowest
address.
@@ -721,10 +721,10 @@ Offset Size Field Description
36.2.1.4. Translate commands
- The translate commands takes an input array of indicies, and a table of single bit values indexed by those
- indicies, and outputs a bit vector or index array created by reading the tables bit value at each index in
+ The translate commands takes an input array of indices, and a table of single bit values indexed by those
+ indices, and outputs a bit vector or index array created by reading the tables bit value at each index in
the input array. The output should therefore contain exactly one bit per index in the input data stream,
- when outputing as a bit vector. When outputing as an index array, the number of elements depends on the
+ when outputting as a bit vector. When outputting as an index array, the number of elements depends on the
values read in the bit table, but will always be less than, or equal to, the number of input elements. Only
a restricted subset of the possible input format types are supported. No variable width or Huffman/OZIP
encoded input streams are allowed. The primary input data element size must be 3 bytes or less.
@@ -742,7 +742,7 @@ Offset Size Field Description
code in the CCB header.
There are two supported formats for the output stream: the bit vector and index array formats (codes 0x8,
- 0xD, and 0xE). The index array format is an array of indicies of bits which would have been set if the
+ 0xD, and 0xE). The index array format is an array of indices of bits which would have been set if the
output format was a bit array.
The return value of the CCB completion area contains the number of bits set in the output bit vector,
@@ -1254,7 +1254,7 @@ EUNAVAILABLE The requested CCB operation could not be performed at this time.
submitted CCB, or may apply to a larger scope. The status should not be
interpreted as permanent, and the guest should attempt to submit CCBs in
the future which had previously been unable to be performed. The status
- data provides additional information about scope of the retricted availability
+ data provides additional information about scope of the restricted availability
as follows:
Value Description
0 Processing for the exact CCB instance submitted was unavailable,
@@ -1330,20 +1330,20 @@ EUNAVAILABLE The requested CCB operation could not be performed at this time.
of other CCBs ahead of the requested CCB, to provide a relative estimate of when the CCB may execute.
The dax return value is only valid when the state is ENQUEUED. The value returned is the DAX unit
- instance indentifier for the DAX unit processing the queue where the requested CCB is located. The value
+ instance identifier for the DAX unit processing the queue where the requested CCB is located. The value
matches the value that would have been, or was, returned by ccb_submit using the queue info flag.
The queue return value is only valid when the state is ENQUEUED. The value returned is the DAX
- queue instance indentifier for the DAX unit processing the queue where the requested CCB is located. The
+ queue instance identifier for the DAX unit processing the queue where the requested CCB is located. The
value matches the value that would have been, or was, returned by ccb_submit using the queue info flag.
36.3.2.1. Errors
- EOK The request was proccessed and the CCB state is valid.
+ EOK The request was processed and the CCB state is valid.
EBADALIGN address is not on a 64-byte aligned.
ENORADDR The real address provided for address is not valid.
EINVAL The CCB completion area contents are not valid.
- EWOULDBLOCK Internal resource contraints prevented the CCB state from being queried at this
+ EWOULDBLOCK Internal resource constraints prevented the CCB state from being queried at this
time. The guest should retry the request.
ENOACCESS The guest does not have permission to access the coprocessor virtual device
functionality.
@@ -1401,11 +1401,11 @@ EUNAVAILABLE The requested CCB operation could not be performed at this time.
36.3.3.2. Errors
- EOK The request was proccessed and the result is valid.
+ EOK The request was processed and the result is valid.
EBADALIGN address is not on a 64-byte aligned.
ENORADDR The real address provided for address is not valid.
EINVAL The CCB completion area contents are not valid.
- EWOULDBLOCK Internal resource contraints prevented the CCB from being killed at this time.
+ EWOULDBLOCK Internal resource constraints prevented the CCB from being killed at this time.
The guest should retry the request.
ENOACCESS The guest does not have permission to access the coprocessor virtual device
functionality.
@@ -1423,7 +1423,7 @@ EUNAVAILABLE The requested CCB operation could not be performed at this time.
36.3.4.1. Errors
- EOK The request was proccessed and the number of enabled/disabled DAX units
+ EOK The request was processed and the number of enabled/disabled DAX units
are valid.
diff --git a/Documentation/sparc/oradax/oracle-dax.rst b/Documentation/arch/sparc/oradax/oracle-dax.rst
index d1e14d572918..d1e14d572918 100644
--- a/Documentation/sparc/oradax/oracle-dax.rst
+++ b/Documentation/arch/sparc/oradax/oracle-dax.rst
diff --git a/Documentation/arch/x86/amd-debugging.rst b/Documentation/arch/x86/amd-debugging.rst
new file mode 100644
index 000000000000..d92bf59d62c7
--- /dev/null
+++ b/Documentation/arch/x86/amd-debugging.rst
@@ -0,0 +1,368 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Debugging AMD Zen systems
++++++++++++++++++++++++++
+
+Introduction
+============
+
+This document describes techniques that are useful for debugging issues with
+AMD Zen systems. It is intended for use by developers and technical users
+to help identify and resolve issues.
+
+S3 vs s2idle
+============
+
+On AMD systems, it's not possible to simultaneously support suspend-to-RAM (S3)
+and suspend-to-idle (s2idle). To confirm which mode your system supports you
+can look at ``cat /sys/power/mem_sleep``. If it shows ``s2idle [deep]`` then
+*S3* is supported. If it shows ``[s2idle]`` then *s2idle* is
+supported.
+
+On systems that support *S3*, the firmware will be utilized to put all hardware into
+the appropriate low power state.
+
+On systems that support *s2idle*, the kernel will be responsible for transitioning devices
+into the appropriate low power state. When all devices are in the appropriate low
+power state, the hardware will transition into a hardware sleep state.
+
+After a suspend cycle you can tell how much time was spent in a hardware sleep
+state by looking at ``cat /sys/power/suspend_stats/last_hw_sleep``.
+
+This flowchart explains how the AMD s2idle suspend flow works.
+
+.. kernel-figure:: suspend.svg
+
+This flowchart explains how the amd s2idle resume flow works.
+
+.. kernel-figure:: resume.svg
+
+s2idle debugging tool
+=====================
+
+As there are a lot of places that problems can occur, a debugging tool has been
+created at
+`amd-debug-tools <https://git.kernel.org/pub/scm/linux/kernel/git/superm1/amd-debug-tools.git/about/>`_
+that can help test for common problems and offer suggestions.
+
+If you have an s2idle issue, it's best to start with this and follow instructions
+from its findings. If you continue to have an issue, raise a bug with the
+report generated from this script to
+`drm/amd gitlab <https://gitlab.freedesktop.org/drm/amd/-/issues/new?issuable_template=s2idle_BUG_TEMPLATE>`_.
+
+Spurious s2idle wakeups from an IRQ
+===================================
+
+Spurious wakeups will generally have an IRQ set to ``/sys/power/pm_wakeup_irq``.
+This can be matched to ``/proc/interrupts`` to determine what device woke the system.
+
+If this isn't enough to debug the problem, then the following sysfs files
+can be set to add more verbosity to the wakeup process: ::
+
+ # echo 1 | sudo tee /sys/power/pm_debug_messages
+ # echo 1 | sudo tee /sys/power/pm_print_times
+
+After making those changes, the kernel will display messages that can
+be traced back to kernel s2idle loop code as well as display any active
+GPIO sources while waking up.
+
+If the wakeup is caused by the ACPI SCI, additional ACPI debugging may be
+needed. These commands can enable additional trace data: ::
+
+ # echo enable | sudo tee /sys/module/acpi/parameters/trace_state
+ # echo 1 | sudo tee /sys/module/acpi/parameters/aml_debug_output
+ # echo 0x0800000f | sudo tee /sys/module/acpi/parameters/debug_level
+ # echo 0xffff0000 | sudo tee /sys/module/acpi/parameters/debug_layer
+
+Spurious s2idle wakeups from a GPIO
+===================================
+
+If a GPIO is active when waking up the system ideally you would look at the
+schematic to determine what device it is associated with. If the schematic
+is not available, another tactic is to look at the ACPI _EVT() entry
+to determine what device is notified when that GPIO is active.
+
+For a hypothetical example, say that GPIO 59 woke up the system. You can
+look at the SSDT to determine what device is notified when GPIO 59 is active.
+
+First convert the GPIO number into hex. ::
+
+ $ python3 -c "print(hex(59))"
+ 0x3b
+
+Next determine which ACPI table has the ``_EVT`` entry. For example: ::
+
+ $ sudo grep EVT /sys/firmware/acpi/tables/SSDT*
+ grep: /sys/firmware/acpi/tables/SSDT27: binary file matches
+
+Decode this table::
+
+ $ sudo cp /sys/firmware/acpi/tables/SSDT27 .
+ $ sudo iasl -d SSDT27
+
+Then look at the table and find the matching entry for GPIO 0x3b. ::
+
+ Case (0x3B)
+ {
+ M000 (0x393B)
+ M460 (" Notify (\\_SB.PCI0.GP17.XHC1, 0x02)\n", Zero, Zero, Zero, Zero, Zero, Zero)
+ Notify (\_SB.PCI0.GP17.XHC1, 0x02) // Device Wake
+ }
+
+You can see in this case that the device ``\_SB.PCI0.GP17.XHC1`` is notified
+when GPIO 59 is active. It's obvious this is an XHCI controller, but to go a
+step further you can figure out which XHCI controller it is by matching it to
+ACPI.::
+
+ $ grep "PCI0.GP17.XHC1" /sys/bus/acpi/devices/*/path
+ /sys/bus/acpi/devices/device:2d/path:\_SB_.PCI0.GP17.XHC1
+ /sys/bus/acpi/devices/device:2e/path:\_SB_.PCI0.GP17.XHC1.RHUB
+ /sys/bus/acpi/devices/device:2f/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT1
+ /sys/bus/acpi/devices/device:30/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT1.CAM0
+ /sys/bus/acpi/devices/device:31/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT1.CAM1
+ /sys/bus/acpi/devices/device:32/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT2
+ /sys/bus/acpi/devices/LNXPOWER:0d/path:\_SB_.PCI0.GP17.XHC1.PWRS
+
+Here you can see it matches to ``device:2d``. Look at the ``physical_node``
+to determine what PCI device that actually is. ::
+
+ $ ls -l /sys/bus/acpi/devices/device:2d/physical_node
+ lrwxrwxrwx 1 root root 0 Feb 12 13:22 /sys/bus/acpi/devices/device:2d/physical_node -> ../../../../../pci0000:00/0000:00:08.1/0000:c2:00.4
+
+So there you have it: the PCI device associated with this GPIO wakeup was ``0000:c2:00.4``.
+
+The ``amd_s2idle.py`` script will capture most of these artifacts for you.
+
+s2idle PM debug messages
+========================
+
+During the s2idle flow on AMD systems, the ACPI LPS0 driver is responsible
+to check all uPEP constraints. Failing uPEP constraints does not prevent
+s0i3 entry. This means that if some constraints are not met, it is possible
+the kernel may attempt to enter s2idle even if there are some known issues.
+
+To activate PM debugging, either specify ``pm_debug_messagess`` kernel
+command-line option at boot or write to ``/sys/power/pm_debug_messages``.
+Unmet constraints will be displayed in the kernel log and can be
+viewed by logging tools that process kernel ring buffer like ``dmesg`` or
+``journalctl``."
+
+If the system freezes on entry/exit before these messages are flushed, a
+useful debugging tactic is to unbind the ``amd_pmc`` driver to prevent
+notification to the platform to start s0i3 entry. This will stop the
+system from freezing on entry or exit and let you view all the failed
+constraints. ::
+
+ cd /sys/bus/platform/drivers/amd_pmc
+ ls | grep AMD | sudo tee unbind
+
+After doing this, run the suspend cycle and look specifically for errors around: ::
+
+ ACPI: LPI: Constraint not met; min power state:%s current power state:%s
+
+Historical examples of s2idle issues
+====================================
+
+To help understand the types of issues that can occur and how to debug them,
+here are some historical examples of s2idle issues that have been resolved.
+
+Core offlining
+--------------
+An end user had reported that taking a core offline would prevent the system
+from properly entering s0i3. This was debugged using internal AMD tools
+to capture and display a stream of metrics from the hardware showing what changed
+when a core was offlined. It was determined that the hardware didn't get
+notification the offline cores were in the deepest state, and so it prevented
+CPU from going into the deepest state. The issue was debugged to a missing
+command to put cores into C3 upon offline.
+
+`commit d6b88ce2eb9d2 ("ACPI: processor idle: Allow playing dead in C3 state") <https://git.kernel.org/torvalds/c/d6b88ce2eb9d2>`_
+
+Corruption after resume
+-----------------------
+A big problem that occurred with Rembrandt was that there was graphical
+corruption after resume. This happened because of a misalignment of PSP
+and driver responsibility. The PSP will save and restore DMCUB, but the
+driver assumed it needed to reset DMCUB on resume.
+This actually was a misalignment for earlier silicon as well, but was not
+observed.
+
+`commit 79d6b9351f086 ("drm/amd/display: Don't reinitialize DMCUB on s0ix resume") <https://git.kernel.org/torvalds/c/79d6b9351f086>`_
+
+Back to Back suspends fail
+--------------------------
+When using a wakeup source that triggers the IRQ to wakeup, a bug in the
+pinctrl-amd driver may capture the wrong state of the IRQ and prevent the
+system going back to sleep properly.
+
+`commit b8c824a869f22 ("pinctrl: amd: Don't save/restore interrupt status and wake status bits") <https://git.kernel.org/torvalds/c/b8c824a869f22>`_
+
+Spurious timer based wakeup after 5 minutes
+-------------------------------------------
+The HPET was being used to program the wakeup source for the system, however
+this was causing a spurious wakeup after 5 minutes. The correct alarm to use
+was the ACPI alarm.
+
+`commit 3d762e21d5637 ("rtc: cmos: Use ACPI alarm for non-Intel x86 systems too") <https://git.kernel.org/torvalds/c/3d762e21d5637>`_
+
+Disk disappears after resume
+----------------------------
+After resuming from s2idle, the NVME disk would disappear. This was due to the
+BIOS not specifying the _DSD StorageD3Enable property. This caused the NVME
+driver not to put the disk into the expected state at suspend and to fail
+on resume.
+
+`commit e79a10652bbd3 ("ACPI: x86: Force StorageD3Enable on more products") <https://git.kernel.org/torvalds/c/e79a10652bbd3>`_
+
+Spurious IRQ1
+-------------
+A number of Renoir, Lucienne, Cezanne, & Barcelo platforms have a
+platform firmware bug where IRQ1 is triggered during s0i3 resume.
+
+This was fixed in the platform firmware, but a number of systems didn't
+receive any more platform firmware updates.
+
+`commit 8e60615e89321 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN") <https://git.kernel.org/torvalds/c/8e60615e89321>`_
+
+Hardware timeout
+----------------
+The hardware performs many actions besides accepting the values from
+amd-pmc driver. As the communication path with the hardware is a mailbox,
+it's possible that it might not respond quickly enough.
+This issue manifested as a failure to suspend: ::
+
+ PM: dpm_run_callback(): acpi_subsys_suspend_noirq+0x0/0x50 returns -110
+ amd_pmc AMDI0005:00: PM: failed to suspend noirq: error -110
+
+The timing problem was identified by comparing the values of the idle mask.
+
+`commit 3c3c8e88c8712 ("platform/x86: amd-pmc: Increase the response register timeout") <https://git.kernel.org/torvalds/c/3c3c8e88c8712>`_
+
+Failed to reach hardware sleep state with panel on
+--------------------------------------------------
+On some Strix systems certain panels were observed to block the system from
+entering a hardware sleep state if the internal panel was on during the sequence.
+
+Even though the panel got turned off during suspend it exposed a timing problem
+where an interrupt caused the display hardware to wake up and block low power
+state entry.
+
+`commit 40b8c14936bd2 ("drm/amd/display: Disable unneeded hpd interrupts during dm_init") <https://git.kernel.org/torvalds/c/40b8c14936bd2>`_
+
+Runtime power consumption issues
+================================
+
+Runtime power consumption is influenced by many factors, including but not
+limited to the configuration of the PCIe Active State Power Management (ASPM),
+the display brightness, the EPP policy of the CPU, and the power management
+of the devices.
+
+ASPM
+----
+For the best runtime power consumption, ASPM should be programmed as intended
+by the BIOS from the hardware vendor. To accomplish this the Linux kernel
+should be compiled with ``CONFIG_PCIEASPM_DEFAULT`` set to ``y`` and the
+sysfs file ``/sys/module/pcie_aspm/parameters/policy`` should not be modified.
+
+Most notably, if L1.2 is not configured properly for any devices, the SoC
+will not be able to enter the deepest idle state.
+
+EPP Policy
+----------
+The ``energy_performance_preference`` sysfs file can be used to set a bias
+of efficiency or performance for a CPU. This has a direct relationship on
+the battery life when more heavily biased towards performance.
+
+
+BIOS debug messages
+===================
+
+Most OEM machines don't have a serial UART for outputting kernel or BIOS
+debug messages. However BIOS debug messages are useful for understanding
+both BIOS bugs and bugs with the Linux kernel drivers that call BIOS AML.
+
+As the BIOS on most OEM AMD systems are based off an AMD reference BIOS,
+the infrastructure used for exporting debugging messages is often the same
+as AMD reference BIOS.
+
+Manually Parsing
+----------------
+There is generally an ACPI method ``\M460`` that different paths of the AML
+will call to emit a message to the BIOS serial log. This method takes
+7 arguments, with the first being a string and the rest being optional
+integers::
+
+ Method (M460, 7, Serialized)
+
+Here is an example of a string that BIOS AML may call out using ``\M460``::
+
+ M460 (" OEM-ASL-PCIe Address (0x%X)._REG (%d %d) PCSA = %d\n", DADR, Arg0, Arg1, PCSA, Zero, Zero)
+
+Normally when executed, the ``\M460`` method would populate the additional
+arguments into the string. In order to get these messages from the Linux
+kernel a hook has been added into ACPICA that can capture the *arguments*
+sent to ``\M460`` and print them to the kernel ring buffer.
+For example the following message could be emitted into kernel ring buffer::
+
+ extrace-0174 ex_trace_args : " OEM-ASL-PCIe Address (0x%X)._REG (%d %d) PCSA = %d\n", ec106000, 2, 1, 1, 0, 0
+
+In order to get these messages, you need to compile with ``CONFIG_ACPI_DEBUG``
+and then turn on the following ACPICA tracing parameters.
+This can be done either on the kernel command line or at runtime:
+
+* ``acpi.trace_method_name=\M460``
+* ``acpi.trace_state=method``
+
+NOTE: These can be very noisy at bootup. If you turn these parameters on
+the kernel command, please also consider turning up ``CONFIG_LOG_BUF_SHIFT``
+to a larger size such as 17 to avoid losing early boot messages.
+
+Tool assisted Parsing
+---------------------
+As mentioned above, parsing by hand can be tedious, especially with a lot of
+messages. To help with this, a tool has been created at
+`amd-debug-tools <https://git.kernel.org/pub/scm/linux/kernel/git/superm1/amd-debug-tools.git/about/>`_
+to help parse the messages.
+
+Random reboot issues
+====================
+
+When a random reboot occurs, the high-level reason for the reboot is stored
+in a register that will persist onto the next boot.
+
+There are 6 classes of reasons for the reboot:
+ * Software induced
+ * Power state transition
+ * Pin induced
+ * Hardware induced
+ * Remote reset
+ * Internal CPU event
+
+.. csv-table::
+ :header: "Bit", "Type", "Reason"
+ :align: left
+
+ "0", "Pin", "thermal pin BP_THERMTRIP_L was tripped"
+ "1", "Pin", "power button was pressed for 4 seconds"
+ "2", "Pin", "shutdown pin was tripped"
+ "4", "Remote", "remote ASF power off command was received"
+ "9", "Internal", "internal CPU thermal limit was tripped"
+ "16", "Pin", "system reset pin BP_SYS_RST_L was tripped"
+ "17", "Software", "software issued PCI reset"
+ "18", "Software", "software wrote 0x4 to reset control register 0xCF9"
+ "19", "Software", "software wrote 0x6 to reset control register 0xCF9"
+ "20", "Software", "software wrote 0xE to reset control register 0xCF9"
+ "21", "ACPI-state", "ACPI power state transition occurred"
+ "22", "Pin", "keyboard reset pin KB_RST_L was tripped"
+ "23", "Internal", "internal CPU shutdown event occurred"
+ "24", "Hardware", "system failed to boot before failed boot timer expired"
+ "25", "Hardware", "hardware watchdog timer expired"
+ "26", "Remote", "remote ASF reset command was received"
+ "27", "Internal", "an uncorrected error caused a data fabric sync flood event"
+ "29", "Internal", "FCH and MP1 failed warm reset handshake"
+ "30", "Internal", "a parity error occurred"
+ "31", "Internal", "a software sync flood event occurred"
+
+This information is read by the kernel at bootup and printed into
+the syslog. When a random reboot occurs this message can be helpful
+to determine the next component to debug.
diff --git a/Documentation/arch/x86/amd-hfi.rst b/Documentation/arch/x86/amd-hfi.rst
new file mode 100644
index 000000000000..bf3d3a1985a2
--- /dev/null
+++ b/Documentation/arch/x86/amd-hfi.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================================================
+Hardware Feedback Interface For Hetero Core Scheduling On AMD Platform
+======================================================================
+
+:Copyright: 2025 Advanced Micro Devices, Inc. All Rights Reserved.
+
+:Author: Perry Yuan <perry.yuan@amd.com>
+:Author: Mario Limonciello <mario.limonciello@amd.com>
+
+Overview
+--------
+
+AMD Heterogeneous Core implementations are comprised of more than one
+architectural class and CPUs are comprised of cores of various efficiency and
+power capabilities: performance-oriented *classic cores* and power-efficient
+*dense cores*. As such, power management strategies must be designed to
+accommodate the complexities introduced by incorporating different core types.
+Heterogeneous systems can also extend to more than two architectural classes
+as well. The purpose of the scheduling feedback mechanism is to provide
+information to the operating system scheduler in real time such that the
+scheduler can direct threads to the optimal core.
+
+The goal of AMD's heterogeneous architecture is to attain power benefit by
+sending background threads to the dense cores while sending high priority
+threads to the classic cores. From a performance perspective, sending
+background threads to dense cores can free up power headroom and allow the
+classic cores to optimally service demanding threads. Furthermore, the area
+optimized nature of the dense cores allows for an increasing number of
+physical cores. This improved core density will have positive multithreaded
+performance impact.
+
+AMD Heterogeneous Core Driver
+-----------------------------
+
+The ``amd_hfi`` driver delivers the operating system a performance and energy
+efficiency capability data for each CPU in the system. The scheduler can use
+the ranking data from the HFI driver to make task placement decisions.
+
+Thread Classification and Ranking Table Interaction
+----------------------------------------------------
+
+The thread classification is used to select into a ranking table that
+describes an efficiency and performance ranking for each classification.
+
+Threads are classified during runtime into enumerated classes. The classes
+represent thread performance/power characteristics that may benefit from
+special scheduling behaviors. The below table depicts an example of thread
+classification and a preference where a given thread should be scheduled
+based on its thread class. The real time thread classification is consumed
+by the operating system and is used to inform the scheduler of where the
+thread should be placed.
+
+Thread Classification Example Table
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++----------+----------------+-------------------------------+---------------------+---------+
+| class ID | Classification | Preferred scheduling behavior | Preemption priority | Counter |
++----------+----------------+-------------------------------+---------------------+---------+
+| 0 | Default | Performant | Highest | |
++----------+----------------+-------------------------------+---------------------+---------+
+| 1 | Non-scalable | Efficient | Lowest | PMCx1A1 |
++----------+----------------+-------------------------------+---------------------+---------+
+| 2 | I/O bound | Efficient | Lowest | PMCx044 |
++----------+----------------+-------------------------------+---------------------+---------+
+
+Thread classification is performed by the hardware each time that the thread is switched out.
+Threads that don't meet any hardware specified criteria are classified as "default".
+
+AMD Hardware Feedback Interface
+--------------------------------
+
+The Hardware Feedback Interface provides to the operating system information
+about the performance and energy efficiency of each CPU in the system. Each
+capability is given as a unit-less quantity in the range [0-255]. A higher
+performance value indicates higher performance capability, and a higher
+efficiency value indicates more efficiency. Energy efficiency and performance
+are reported in separate capabilities in the shared memory based ranking table.
+
+These capabilities may change at runtime as a result of changes in the
+operating conditions of the system or the action of external factors.
+Power Management firmware is responsible for detecting events that require
+a reordering of the performance and efficiency ranking. Table updates happen
+relatively infrequently and occur on the time scale of seconds or more.
+
+The following events trigger a table update:
+ * Thermal Stress Events
+ * Silent Compute
+ * Extreme Low Battery Scenarios
+
+The kernel or a userspace policy daemon can use these capabilities to modify
+task placement decisions. For instance, if either the performance or energy
+capabilities of a given logical processor becomes zero, it is an indication
+that the hardware recommends to the operating system to not schedule any tasks
+on that processor for performance or energy efficiency reasons, respectively.
+
+Implementation details for Linux
+--------------------------------
+
+The implementation of threads scheduling consists of the following steps:
+
+1. A thread is spawned and scheduled to the ideal core using the default
+ heterogeneous scheduling policy.
+2. The processor profiles thread execution and assigns an enumerated
+ classification ID.
+ This classification is communicated to the OS via logical processor
+ scope MSR.
+3. During the thread context switch out the operating system consumes the
+ workload (WL) classification which resides in a logical processor scope MSR.
+4. The OS triggers the hardware to clear its history by writing to an MSR,
+ after consuming the WL classification and before switching in the new thread.
+5. If due to the classification, ranking table, and processor availability,
+ the thread is not on its ideal processor, the OS will then consider
+ scheduling the thread on its ideal processor (if available).
+
+Ranking Table
+-------------
+The ranking table is a shared memory region that is used to communicate the
+performance and energy efficiency capabilities of each CPU in the system.
+
+The ranking table design includes rankings for each APIC ID in the system and
+rankings both for performance and efficiency for each workload classification.
+
+.. kernel-doc:: drivers/platform/x86/amd/hfi/hfi.c
+ :doc: amd_shmem_info
+
+Ranking Table update
+---------------------------
+The power management firmware issues an platform interrupt after updating the
+ranking table and is ready for the operating system to consume it. CPUs receive
+such interrupt and read new ranking table from shared memory which PCCT table
+has provided, then ``amd_hfi`` driver parses the new table to provide new
+consume data for scheduling decisions.
diff --git a/Documentation/arch/x86/amd-memory-encryption.rst b/Documentation/arch/x86/amd-memory-encryption.rst
new file mode 100644
index 000000000000..bd840df708ea
--- /dev/null
+++ b/Documentation/arch/x86/amd-memory-encryption.rst
@@ -0,0 +1,278 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+AMD Memory Encryption
+=====================
+
+Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) are
+features found on AMD processors.
+
+SME provides the ability to mark individual pages of memory as encrypted using
+the standard x86 page tables. A page that is marked encrypted will be
+automatically decrypted when read from DRAM and encrypted when written to
+DRAM. SME can therefore be used to protect the contents of DRAM from physical
+attacks on the system.
+
+SEV enables running encrypted virtual machines (VMs) in which the code and data
+of the guest VM are secured so that a decrypted version is available only
+within the VM itself. SEV guest VMs have the concept of private and shared
+memory. Private memory is encrypted with the guest-specific key, while shared
+memory may be encrypted with hypervisor key. When SME is enabled, the hypervisor
+key is the same key which is used in SME.
+
+A page is encrypted when a page table entry has the encryption bit set (see
+below on how to determine its position). The encryption bit can also be
+specified in the cr3 register, allowing the PGD table to be encrypted. Each
+successive level of page tables can also be encrypted by setting the encryption
+bit in the page table entry that points to the next table. This allows the full
+page table hierarchy to be encrypted. Note, this means that just because the
+encryption bit is set in cr3, doesn't imply the full hierarchy is encrypted.
+Each page table entry in the hierarchy needs to have the encryption bit set to
+achieve that. So, theoretically, you could have the encryption bit set in cr3
+so that the PGD is encrypted, but not set the encryption bit in the PGD entry
+for a PUD which results in the PUD pointed to by that entry to not be
+encrypted.
+
+When SEV is enabled, instruction pages and guest page tables are always treated
+as private. All the DMA operations inside the guest must be performed on shared
+memory. Since the memory encryption bit is controlled by the guest OS when it
+is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware
+forces the memory encryption bit to 1.
+
+Support for SME and SEV can be determined through the CPUID instruction. The
+CPUID function 0x8000001f reports information related to SME::
+
+ 0x8000001f[eax]:
+ Bit[0] indicates support for SME
+ Bit[1] indicates support for SEV
+ 0x8000001f[ebx]:
+ Bits[5:0] pagetable bit number used to activate memory
+ encryption
+ Bits[11:6] reduction in physical address space, in bits, when
+ memory encryption is enabled (this only affects
+ system physical addresses, not guest physical
+ addresses)
+
+If support for SME is present, MSR 0xc00100010 (MSR_AMD64_SYSCFG) can be used to
+determine if SME is enabled and/or to enable memory encryption::
+
+ 0xc0010010:
+ Bit[23] 0 = memory encryption features are disabled
+ 1 = memory encryption features are enabled
+
+If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if
+SEV is active::
+
+ 0xc0010131:
+ Bit[0] 0 = memory encryption is not active
+ 1 = memory encryption is active
+
+Linux relies on BIOS to set this bit if BIOS has determined that the reduction
+in the physical address space as a result of enabling memory encryption (see
+CPUID information above) will not conflict with the address space resource
+requirements for the system. If this bit is not set upon Linux startup then
+Linux itself will not set it and memory encryption will not be possible.
+
+The state of SME in the Linux kernel can be documented as follows:
+
+ - Supported:
+ The CPU supports SME (determined through CPUID instruction).
+
+ - Enabled:
+ Supported and bit 23 of MSR_AMD64_SYSCFG is set.
+
+ - Active:
+ Supported, Enabled and the Linux kernel is actively applying
+ the encryption bit to page table entries (the SME mask in the
+ kernel is non-zero).
+
+SME can also be enabled and activated in the BIOS. If SME is enabled and
+activated in the BIOS, then all memory accesses will be encrypted and it
+will not be necessary to activate the Linux memory encryption support.
+
+If the BIOS merely enables SME (sets bit 23 of the MSR_AMD64_SYSCFG),
+then memory encryption can be enabled by supplying mem_encrypt=on on the
+kernel command line. However, if BIOS does not enable SME, then Linux
+will not be able to activate memory encryption, even if configured to do
+so by default or the mem_encrypt=on command line parameter is specified.
+
+Secure Nested Paging (SNP)
+==========================
+
+SEV-SNP introduces new features (SEV_FEATURES[1:63]) which can be enabled
+by the hypervisor for security enhancements. Some of these features need
+guest side implementation to function correctly. The below table lists the
+expected guest behavior with various possible scenarios of guest/hypervisor
+SNP feature support.
+
++-----------------+---------------+---------------+------------------+
+| Feature Enabled | Guest needs | Guest has | Guest boot |
+| by the HV | implementation| implementation| behaviour |
++=================+===============+===============+==================+
+| No | No | No | Boot |
+| | | | |
++-----------------+---------------+---------------+------------------+
+| No | Yes | No | Boot |
+| | | | |
++-----------------+---------------+---------------+------------------+
+| No | Yes | Yes | Boot |
+| | | | |
++-----------------+---------------+---------------+------------------+
+| Yes | No | No | Boot with |
+| | | | feature enabled |
++-----------------+---------------+---------------+------------------+
+| Yes | Yes | No | Graceful boot |
+| | | | failure |
++-----------------+---------------+---------------+------------------+
+| Yes | Yes | Yes | Boot with |
+| | | | feature enabled |
++-----------------+---------------+---------------+------------------+
+
+More details in AMD64 APM[1] Vol 2: 15.34.10 SEV_STATUS MSR
+
+Reverse Map Table (RMP)
+=======================
+
+The RMP is a structure in system memory that is used to ensure a one-to-one
+mapping between system physical addresses and guest physical addresses. Each
+page of memory that is potentially assignable to guests has one entry within
+the RMP.
+
+The RMP table can be either contiguous in memory or a collection of segments
+in memory.
+
+Contiguous RMP
+--------------
+
+Support for this form of the RMP is present when support for SEV-SNP is
+present, which can be determined using the CPUID instruction::
+
+ 0x8000001f[eax]:
+ Bit[4] indicates support for SEV-SNP
+
+The location of the RMP is identified to the hardware through two MSRs::
+
+ 0xc0010132 (RMP_BASE):
+ System physical address of the first byte of the RMP
+
+ 0xc0010133 (RMP_END):
+ System physical address of the last byte of the RMP
+
+Hardware requires that RMP_BASE and (RPM_END + 1) be 8KB aligned, but SEV
+firmware increases the alignment requirement to require a 1MB alignment.
+
+The RMP consists of a 16KB region used for processor bookkeeping followed
+by the RMP entries, which are 16 bytes in size. The size of the RMP
+determines the range of physical memory that the hypervisor can assign to
+SEV-SNP guests. The RMP covers the system physical address from::
+
+ 0 to ((RMP_END + 1 - RMP_BASE - 16KB) / 16B) x 4KB.
+
+The current Linux support relies on BIOS to allocate/reserve the memory for
+the RMP and to set RMP_BASE and RMP_END appropriately. Linux uses the MSR
+values to locate the RMP and determine the size of the RMP. The RMP must
+cover all of system memory in order for Linux to enable SEV-SNP.
+
+Segmented RMP
+-------------
+
+Segmented RMP support is a new way of representing the layout of an RMP.
+Initial RMP support required the RMP table to be contiguous in memory.
+RMP accesses from a NUMA node on which the RMP doesn't reside
+can take longer than accesses from a NUMA node on which the RMP resides.
+Segmented RMP support allows the RMP entries to be located on the same
+node as the memory the RMP is covering, potentially reducing latency
+associated with accessing an RMP entry associated with the memory. Each
+RMP segment covers a specific range of system physical addresses.
+
+Support for this form of the RMP can be determined using the CPUID
+instruction::
+
+ 0x8000001f[eax]:
+ Bit[23] indicates support for segmented RMP
+
+If supported, segmented RMP attributes can be found using the CPUID
+instruction::
+
+ 0x80000025[eax]:
+ Bits[5:0] minimum supported RMP segment size
+ Bits[11:6] maximum supported RMP segment size
+
+ 0x80000025[ebx]:
+ Bits[9:0] number of cacheable RMP segment definitions
+ Bit[10] indicates if the number of cacheable RMP segments
+ is a hard limit
+
+To enable a segmented RMP, a new MSR is available::
+
+ 0xc0010136 (RMP_CFG):
+ Bit[0] indicates if segmented RMP is enabled
+ Bits[13:8] contains the size of memory covered by an RMP
+ segment (expressed as a power of 2)
+
+The RMP segment size defined in the RMP_CFG MSR applies to all segments
+of the RMP. Therefore each RMP segment covers a specific range of system
+physical addresses. For example, if the RMP_CFG MSR value is 0x2401, then
+the RMP segment coverage value is 0x24 => 36, meaning the size of memory
+covered by an RMP segment is 64GB (1 << 36). So the first RMP segment
+covers physical addresses from 0 to 0xF_FFFF_FFFF, the second RMP segment
+covers physical addresses from 0x10_0000_0000 to 0x1F_FFFF_FFFF, etc.
+
+When a segmented RMP is enabled, RMP_BASE points to the RMP bookkeeping
+area as it does today (16K in size). However, instead of RMP entries
+beginning immediately after the bookkeeping area, there is a 4K RMP
+segment table (RST). Each entry in the RST is 8-bytes in size and represents
+an RMP segment::
+
+ Bits[19:0] mapped size (in GB)
+ The mapped size can be less than the defined segment size.
+ A value of zero, indicates that no RMP exists for the range
+ of system physical addresses associated with this segment.
+ Bits[51:20] segment physical address
+ This address is left shift 20-bits (or just masked when
+ read) to form the physical address of the segment (1MB
+ alignment).
+
+The RST can hold 512 segment entries but can be limited in size to the number
+of cacheable RMP segments (CPUID 0x80000025_EBX[9:0]) if the number of cacheable
+RMP segments is a hard limit (CPUID 0x80000025_EBX[10]).
+
+The current Linux support relies on BIOS to allocate/reserve the memory for
+the segmented RMP (the bookkeeping area, RST, and all segments), build the RST
+and to set RMP_BASE, RMP_END, and RMP_CFG appropriately. Linux uses the MSR
+values to locate the RMP and determine the size and location of the RMP
+segments. The RMP must cover all of system memory in order for Linux to enable
+SEV-SNP.
+
+More details in the AMD64 APM Vol 2, section "15.36.3 Reverse Map Table",
+docID: 24593.
+
+Secure VM Service Module (SVSM)
+===============================
+
+SNP provides a feature called Virtual Machine Privilege Levels (VMPL) which
+defines four privilege levels at which guest software can run. The most
+privileged level is 0 and numerically higher numbers have lesser privileges.
+More details in the AMD64 APM Vol 2, section "15.35.7 Virtual Machine
+Privilege Levels", docID: 24593.
+
+When using that feature, different services can run at different protection
+levels, apart from the guest OS but still within the secure SNP environment.
+They can provide services to the guest, like a vTPM, for example.
+
+When a guest is not running at VMPL0, it needs to communicate with the software
+running at VMPL0 to perform privileged operations or to interact with secure
+services. An example fur such a privileged operation is PVALIDATE which is
+*required* to be executed at VMPL0.
+
+In this scenario, the software running at VMPL0 is usually called a Secure VM
+Service Module (SVSM). Discovery of an SVSM and the API used to communicate
+with it is documented in "Secure VM Service Module for SEV-SNP Guests", docID:
+58019.
+
+(Latest versions of the above-mentioned documents can be found by using
+a search engine like duckduckgo.com and typing in:
+
+ site:amd.com "Secure VM Service Module for SEV-SNP Guests", docID: 58019
+
+for example.)
diff --git a/Documentation/arch/x86/amd_hsmp.rst b/Documentation/arch/x86/amd_hsmp.rst
new file mode 100644
index 000000000000..a094f55c10b0
--- /dev/null
+++ b/Documentation/arch/x86/amd_hsmp.rst
@@ -0,0 +1,192 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================================
+AMD HSMP interface
+============================================
+
+Newer Fam19h(model 0x00-0x1f, 0x30-0x3f, 0x90-0x9f, 0xa0-0xaf),
+Fam1Ah(model 0x00-0x1f) EPYC server line of processors from AMD support
+system management functionality via HSMP (Host System Management Port).
+
+The Host System Management Port (HSMP) is an interface to provide
+OS-level software with access to system management functions via a
+set of mailbox registers.
+
+More details on the interface can be found in chapter
+"7 Host System Management Port (HSMP)" of the family/model PPR
+Eg: https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/programmer-references/55898_B1_pub_0_50.zip
+
+
+HSMP interface is supported on EPYC line of server CPUs and MI300A (APU).
+
+
+HSMP device
+============================================
+
+amd_hsmp driver under drivers/platforms/x86/amd/hsmp/ has separate driver files
+for ACPI object based probing, platform device based probing and for the common
+code for these two drivers.
+
+Kconfig option CONFIG_AMD_HSMP_PLAT compiles plat.c and creates amd_hsmp.ko.
+Kconfig option CONFIG_AMD_HSMP_ACPI compiles acpi.c and creates hsmp_acpi.ko.
+Selecting any of these two configs automatically selects CONFIG_AMD_HSMP. This
+compiles common code hsmp.c and creates hsmp_common.ko module.
+
+Both the ACPI and plat drivers create the miscdevice /dev/hsmp to let
+user space programs run hsmp mailbox commands.
+
+The ACPI object format supported by the driver is defined below.
+
+$ ls -al /dev/hsmp
+crw-r--r-- 1 root root 10, 123 Jan 21 21:41 /dev/hsmp
+
+Characteristics of the dev node:
+ * Write mode is used for running set/configure commands
+ * Read mode is used for running get/status monitor commands
+
+Access restrictions:
+ * Only root user is allowed to open the file in write mode.
+ * The file can be opened in read mode by all the users.
+
+In-kernel integration:
+ * Other subsystems in the kernel can use the exported transport
+ function hsmp_send_message().
+ * Locking across callers is taken care by the driver.
+
+
+HSMP sysfs interface
+====================
+
+1. Metrics table binary sysfs
+
+AMD MI300A MCM provides GET_METRICS_TABLE message to retrieve
+most of the system management information from SMU in one go.
+
+The metrics table is made available as hexadecimal sysfs binary file
+under per socket sysfs directory created at
+/sys/devices/platform/amd_hsmp/socket%d/metrics_bin
+
+Note: lseek() is not supported as entire metrics table is read.
+
+Metrics table definitions will be documented as part of Public PPR.
+The same is defined in the amd_hsmp.h header.
+
+2. HSMP telemetry sysfs files
+
+Following sysfs files are available at /sys/devices/platform/AMDI0097:0X/.
+
+* c0_residency_input: Percentage of cores in C0 state.
+* prochot_status: Reports 1 if the processor is at thermal threshold value,
+ 0 otherwise.
+* smu_fw_version: SMU firmware version.
+* protocol_version: HSMP interface version.
+* ddr_max_bw: Theoretical maximum DDR bandwidth in GB/s.
+* ddr_utilised_bw_input: Current utilized DDR bandwidth in GB/s.
+* ddr_utilised_bw_perc_input(%): Percentage of current utilized DDR bandwidth.
+* mclk_input: Memory clock in MHz.
+* fclk_input: Fabric clock in MHz.
+* clk_fmax: Maximum frequency of socket in MHz.
+* clk_fmin: Minimum frequency of socket in MHz.
+* cclk_freq_limit_input: Core clock frequency limit per socket in MHz.
+* pwr_current_active_freq_limit: Current active frequency limit of socket
+ in MHz.
+* pwr_current_active_freq_limit_source: Source of current active frequency
+ limit.
+
+ACPI device object format
+=========================
+The ACPI object format expected from the amd_hsmp driver
+for socket with ID00 is given below::
+
+ Device(HSMP)
+ {
+ Name(_HID, "AMDI0097")
+ Name(_UID, "ID00")
+ Name(HSE0, 0x00000001)
+ Name(RBF0, ResourceTemplate()
+ {
+ Memory32Fixed(ReadWrite, 0xxxxxxx, 0x00100000)
+ })
+ Method(_CRS, 0, NotSerialized)
+ {
+ Return(RBF0)
+ }
+ Method(_STA, 0, NotSerialized)
+ {
+ If(LEqual(HSE0, One))
+ {
+ Return(0x0F)
+ }
+ Else
+ {
+ Return(Zero)
+ }
+ }
+ Name(_DSD, Package(2)
+ {
+ Buffer(0x10)
+ {
+ 0x9D, 0x61, 0x4D, 0xB7, 0x07, 0x57, 0xBD, 0x48,
+ 0xA6, 0x9F, 0x4E, 0xA2, 0x87, 0x1F, 0xC2, 0xF6
+ },
+ Package(3)
+ {
+ Package(2) {"MsgIdOffset", 0x00010934},
+ Package(2) {"MsgRspOffset", 0x00010980},
+ Package(2) {"MsgArgOffset", 0x000109E0}
+ }
+ })
+ }
+
+HSMP HWMON interface
+====================
+HSMP power sensors are registered with the hwmon interface. A separate hwmon
+directory is created for each socket and the following files are generated
+within the hwmon directory.
+- power1_input (read only)
+- power1_cap_max (read only)
+- power1_cap (read, write)
+
+An example
+==========
+
+To access hsmp device from a C program.
+First, you need to include the headers::
+
+ #include <linux/amd_hsmp.h>
+
+Which defines the supported messages/message IDs.
+
+Next thing, open the device file, as follows::
+
+ int file;
+
+ file = open("/dev/hsmp", O_RDWR);
+ if (file < 0) {
+ /* ERROR HANDLING; you can check errno to see what went wrong */
+ exit(1);
+ }
+
+The following IOCTL is defined:
+
+``ioctl(file, HSMP_IOCTL_CMD, struct hsmp_message *msg)``
+ The argument is a pointer to a::
+
+ struct hsmp_message {
+ __u32 msg_id; /* Message ID */
+ __u16 num_args; /* Number of input argument words in message */
+ __u16 response_sz; /* Number of expected output/response words */
+ __u32 args[HSMP_MAX_MSG_LEN]; /* argument/response buffer */
+ __u16 sock_ind; /* socket number */
+ };
+
+The ioctl would return a non-zero on failure; you can read errno to see
+what happened. The transaction returns 0 on success.
+
+More details on the interface and message definitions can be found in chapter
+"7 Host System Management Port (HSMP)" of the respective family/model PPR
+eg: https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/programmer-references/55898_B1_pub_0_50.zip
+
+User space C-APIs are made available by linking against the esmi library,
+which is provided by the E-SMS project https://www.amd.com/en/developer/e-sms.html.
+See: https://github.com/amd/esmi_ib_library
diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst
new file mode 100644
index 000000000000..6d36ce86fd8e
--- /dev/null
+++ b/Documentation/arch/x86/boot.rst
@@ -0,0 +1,1464 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+The Linux/x86 Boot Protocol
+===========================
+
+On the x86 platform, the Linux kernel uses a rather complicated boot
+convention. This has evolved partially due to historical aspects, as
+well as the desire in the early days to have the kernel itself be a
+bootable image, the complicated PC memory model and due to changed
+expectations in the PC industry caused by the effective demise of
+real-mode DOS as a mainstream operating system.
+
+Currently, the following versions of the Linux/x86 boot protocol exist.
+
+============= ============================================================
+Old kernels zImage/Image support only. Some very early kernels
+ may not even support a command line.
+
+Protocol 2.00 (Kernel 1.3.73) Added bzImage and initrd support, as
+ well as a formalized way to communicate between the
+ boot loader and the kernel. setup.S made relocatable,
+ although the traditional setup area still assumed
+ writable.
+
+Protocol 2.01 (Kernel 1.3.76) Added a heap overrun warning.
+
+Protocol 2.02 (Kernel 2.4.0-test3-pre3) New command line protocol.
+ Lower the conventional memory ceiling. No overwrite
+ of the traditional setup area, thus making booting
+ safe for systems which use the EBDA from SMM or 32-bit
+ BIOS entry points. zImage deprecated but still
+ supported.
+
+Protocol 2.03 (Kernel 2.4.18-pre1) Explicitly makes the highest possible
+ initrd address available to the bootloader.
+
+Protocol 2.04 (Kernel 2.6.14) Extend the syssize field to four bytes.
+
+Protocol 2.05 (Kernel 2.6.20) Make protected mode kernel relocatable.
+ Introduce relocatable_kernel and kernel_alignment fields.
+
+Protocol 2.06 (Kernel 2.6.22) Added a field that contains the size of
+ the boot command line.
+
+Protocol 2.07 (Kernel 2.6.24) Added paravirtualised boot protocol.
+ Introduced hardware_subarch and hardware_subarch_data
+ and KEEP_SEGMENTS flag in load_flags.
+
+Protocol 2.08 (Kernel 2.6.26) Added crc32 checksum and ELF format
+ payload. Introduced payload_offset and payload_length
+ fields to aid in locating the payload.
+
+Protocol 2.09 (Kernel 2.6.26) Added a field of 64-bit physical
+ pointer to single linked list of struct setup_data.
+
+Protocol 2.10 (Kernel 2.6.31) Added a protocol for relaxed alignment
+ beyond the kernel_alignment added, new init_size and
+ pref_address fields. Added extended boot loader IDs.
+
+Protocol 2.11 (Kernel 3.6) Added a field for offset of EFI handover
+ protocol entry point.
+
+Protocol 2.12 (Kernel 3.8) Added the xloadflags field and extension fields
+ to struct boot_params for loading bzImage and ramdisk
+ above 4G in 64bit.
+
+Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in
+ xloadflags to support booting a 64-bit kernel from 32-bit
+ EFI
+
+Protocol 2.14 BURNT BY INCORRECT COMMIT
+ ae7e1238e68f2a472a125673ab506d49158c1889
+ ("x86/boot: Add ACPI RSDP address to setup_header")
+ DO NOT USE!!! ASSUME SAME AS 2.13.
+
+Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
+============= ============================================================
+
+.. note::
+ The protocol version number should be changed only if the setup header
+ is changed. There is no need to update the version number if boot_params
+ or kernel_info are changed. Additionally, it is recommended to use
+ xloadflags (in this case the protocol version number should not be
+ updated either) or kernel_info to communicate supported Linux kernel
+ features to the boot loader. Due to very limited space available in
+ the original setup header every update to it should be considered
+ with great care. Starting from the protocol 2.15 the primary way to
+ communicate things to the boot loader is the kernel_info.
+
+
+Memory Layout
+=============
+
+The traditional memory map for the kernel loader, used for Image or
+zImage kernels, typically looks like::
+
+ | |
+ 0A0000 +------------------------+
+ | Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
+ 09A000 +------------------------+
+ | Command line |
+ | Stack/heap | For use by the kernel real-mode code.
+ 098000 +------------------------+
+ | Kernel setup | The kernel real-mode code.
+ 090200 +------------------------+
+ | Kernel boot sector | The kernel legacy boot sector.
+ 090000 +------------------------+
+ | Protected-mode kernel | The bulk of the kernel image.
+ 010000 +------------------------+
+ | Boot loader | <- Boot sector entry point 0000:7C00
+ 001000 +------------------------+
+ | Reserved for MBR/BIOS |
+ 000800 +------------------------+
+ | Typically used by MBR |
+ 000600 +------------------------+
+ | BIOS use only |
+ 000000 +------------------------+
+
+When using bzImage, the protected-mode kernel was relocated to
+0x100000 ("high memory"), and the kernel real-mode block (boot sector,
+setup, and stack/heap) was made relocatable to any address between
+0x10000 and end of low memory. Unfortunately, in protocols 2.00 and
+2.01 the 0x90000+ memory range is still used internally by the kernel;
+the 2.02 protocol resolves that problem.
+
+It is desirable to keep the "memory ceiling" -- the highest point in
+low memory touched by the boot loader -- as low as possible, since
+some newer BIOSes have begun to allocate some rather large amounts of
+memory, called the Extended BIOS Data Area, near the top of low
+memory. The boot loader should use the "INT 12h" BIOS call to verify
+how much low memory is available.
+
+Unfortunately, if INT 12h reports that the amount of memory is too
+low, there is usually nothing the boot loader can do but to report an
+error to the user. The boot loader should therefore be designed to
+take up as little space in low memory as it reasonably can. For
+zImage or old bzImage kernels, which need data written into the
+0x90000 segment, the boot loader should make sure not to use memory
+above the 0x9A000 point; too many BIOSes will break above that point.
+
+For a modern bzImage kernel with boot protocol version >= 2.02, a
+memory layout like the following is suggested::
+
+ ~ ~
+ | Protected-mode kernel |
+ 100000 +------------------------+
+ | I/O memory hole |
+ 0A0000 +------------------------+
+ | Reserved for BIOS | Leave as much as possible unused
+ ~ ~
+ | Command line | (Can also be below the X+10000 mark)
+ X+10000 +------------------------+
+ | Stack/heap | For use by the kernel real-mode code.
+ X+08000 +------------------------+
+ | Kernel setup | The kernel real-mode code.
+ | Kernel boot sector | The kernel legacy boot sector.
+ X +------------------------+
+ | Boot loader | <- Boot sector entry point 0000:7C00
+ 001000 +------------------------+
+ | Reserved for MBR/BIOS |
+ 000800 +------------------------+
+ | Typically used by MBR |
+ 000600 +------------------------+
+ | BIOS use only |
+ 000000 +------------------------+
+
+ ... where the address X is as low as the design of the boot loader permits.
+
+
+The Real-Mode Kernel Header
+===========================
+
+In the following text, and anywhere in the kernel boot sequence, "a
+sector" refers to 512 bytes. It is independent of the actual sector
+size of the underlying medium.
+
+The first step in loading a Linux kernel should be to load the
+real-mode code (boot sector and setup code) and then examine the
+following header at offset 0x01f1. The real-mode code can total up to
+32K, although the boot loader may choose to load only the first two
+sectors (1K) and then examine the bootup sector size.
+
+The header looks like:
+
+=========== ======== ===================== ============================================
+Offset/Size Proto Name Meaning
+=========== ======== ===================== ============================================
+01F1/1 ALL(1) setup_sects The size of the setup in sectors
+01F2/2 ALL root_flags If set, the root is mounted readonly
+01F4/4 2.04+(2) syssize The size of the 32-bit code in 16-byte paras
+01F8/2 ALL ram_size DO NOT USE - for bootsect.S use only
+01FA/2 ALL vid_mode Video mode control
+01FC/2 ALL root_dev Default root device number
+01FE/2 ALL boot_flag 0xAA55 magic number
+0200/2 2.00+ jump Jump instruction
+0202/4 2.00+ header Magic signature "HdrS"
+0206/2 2.00+ version Boot protocol version supported
+0208/4 2.00+ realmode_swtch Boot loader hook (see below)
+020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete)
+020E/2 2.00+ kernel_version Pointer to kernel version string
+0210/1 2.00+ type_of_loader Boot loader identifier
+0211/1 2.00+ loadflags Boot protocol option flags
+0212/2 2.00+ setup_move_size Move to high memory size (used with hooks)
+0214/4 2.00+ code32_start Boot loader hook (see below)
+0218/4 2.00+ ramdisk_image initrd load address (set by boot loader)
+021C/4 2.00+ ramdisk_size initrd size (set by boot loader)
+0220/4 2.00+ bootsect_kludge DO NOT USE - for bootsect.S use only
+0224/2 2.01+ heap_end_ptr Free memory after setup end
+0226/1 2.02+(3) ext_loader_ver Extended boot loader version
+0227/1 2.02+(3) ext_loader_type Extended boot loader ID
+0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
+022C/4 2.03+ initrd_addr_max Highest legal initrd address
+0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
+0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
+0235/1 2.10+ min_alignment Minimum alignment, as a power of two
+0236/2 2.12+ xloadflags Boot protocol option flags
+0238/4 2.06+ cmdline_size Maximum size of the kernel command line
+023C/4 2.07+ hardware_subarch Hardware subarchitecture
+0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
+0248/4 2.08+ payload_offset Offset of kernel payload
+024C/4 2.08+ payload_length Length of kernel payload
+0250/8 2.09+ setup_data 64-bit physical pointer to linked list
+ of struct setup_data
+0258/8 2.10+ pref_address Preferred loading address
+0260/4 2.10+ init_size Linear memory required during initialization
+0264/4 2.11+ handover_offset Offset of handover entry point
+0268/4 2.15+ kernel_info_offset Offset of the kernel_info
+=========== ======== ===================== ============================================
+
+.. note::
+ (1) For backwards compatibility, if the setup_sects field contains 0,
+ the real value is 4.
+
+ (2) For boot protocol prior to 2.04, the upper two bytes of the syssize
+ field are unusable, which means the size of a bzImage kernel
+ cannot be determined.
+
+ (3) Ignored, but safe to set, for boot protocols 2.02-2.09.
+
+If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
+the boot protocol version is "old". Loading an old kernel, the
+following parameters should be assumed::
+
+ Image type = zImage
+ initrd not supported
+ Real-mode kernel must be located at 0x90000.
+
+Otherwise, the "version" field contains the protocol version,
+e.g. protocol version 2.01 will contain 0x0201 in this field. When
+setting fields in the header, you must make sure only to set fields
+supported by the protocol version in use.
+
+
+Details of Header Fields
+========================
+
+For each field, some are information from the kernel to the bootloader
+("read"), some are expected to be filled out by the bootloader
+("write"), and some are expected to be read and modified by the
+bootloader ("modify").
+
+All general purpose boot loaders should write the fields marked
+(obligatory). Boot loaders who want to load the kernel at a
+nonstandard address should fill in the fields marked (reloc); other
+boot loaders can ignore those fields.
+
+The byte order of all fields is little endian (this is x86, after all.)
+
+============ ===========
+Field name: setup_sects
+Type: read
+Offset/size: 0x1f1/1
+Protocol: ALL
+============ ===========
+
+ The size of the setup code in 512-byte sectors. If this field is
+ 0, the real value is 4. The real-mode code consists of the boot
+ sector (always one 512-byte sector) plus the setup code.
+
+============ =================
+Field name: root_flags
+Type: modify (optional)
+Offset/size: 0x1f2/2
+Protocol: ALL
+============ =================
+
+ If this field is nonzero, the root defaults to readonly. The use of
+ this field is deprecated; use the "ro" or "rw" options on the
+ command line instead.
+
+============ ===============================================
+Field name: syssize
+Type: read
+Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
+Protocol: 2.04+
+============ ===============================================
+
+ The size of the protected-mode code in units of 16-byte paragraphs.
+ For protocol versions older than 2.04 this field is only two bytes
+ wide, and therefore cannot be trusted for the size of a kernel if
+ the LOAD_HIGH flag is set.
+
+============ ===============
+Field name: ram_size
+Type: kernel internal
+Offset/size: 0x1f8/2
+Protocol: ALL
+============ ===============
+
+ This field is obsolete.
+
+============ ===================
+Field name: vid_mode
+Type: modify (obligatory)
+Offset/size: 0x1fa/2
+============ ===================
+
+ Please see the section on SPECIAL COMMAND LINE OPTIONS.
+
+============ =================
+Field name: root_dev
+Type: modify (optional)
+Offset/size: 0x1fc/2
+Protocol: ALL
+============ =================
+
+ The default root device device number. The use of this field is
+ deprecated, use the "root=" option on the command line instead.
+
+============ =========
+Field name: boot_flag
+Type: read
+Offset/size: 0x1fe/2
+Protocol: ALL
+============ =========
+
+ Contains 0xAA55. This is the closest thing old Linux kernels have
+ to a magic number.
+
+============ =======
+Field name: jump
+Type: read
+Offset/size: 0x200/2
+Protocol: 2.00+
+============ =======
+
+ Contains an x86 jump instruction, 0xEB followed by a signed offset
+ relative to byte 0x202. This can be used to determine the size of
+ the header.
+
+============ =======
+Field name: header
+Type: read
+Offset/size: 0x202/4
+Protocol: 2.00+
+============ =======
+
+ Contains the magic number "HdrS" (0x53726448).
+
+============ =======
+Field name: version
+Type: read
+Offset/size: 0x206/2
+Protocol: 2.00+
+============ =======
+
+ Contains the boot protocol version, in (major << 8) + minor format,
+ e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version
+ 10.17.
+
+============ =================
+Field name: realmode_swtch
+Type: modify (optional)
+Offset/size: 0x208/4
+Protocol: 2.00+
+============ =================
+
+ Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
+
+============ =============
+Field name: start_sys_seg
+Type: read
+Offset/size: 0x20c/2
+Protocol: 2.00+
+============ =============
+
+ The load low segment (0x1000). Obsolete.
+
+============ ==============
+Field name: kernel_version
+Type: read
+Offset/size: 0x20e/2
+Protocol: 2.00+
+============ ==============
+
+ If set to a nonzero value, contains a pointer to a NUL-terminated
+ human-readable kernel version number string, less 0x200. This can
+ be used to display the kernel version to the user. This value
+ should be less than (0x200 * setup_sects).
+
+ For example, if this value is set to 0x1c00, the kernel version
+ number string can be found at offset 0x1e00 in the kernel file.
+ This is a valid value if and only if the "setup_sects" field
+ contains the value 15 or higher, as::
+
+ 0x1c00 < 15 * 0x200 (= 0x1e00) but
+ 0x1c00 >= 14 * 0x200 (= 0x1c00)
+
+ 0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15.
+
+============ ==================
+Field name: type_of_loader
+Type: write (obligatory)
+Offset/size: 0x210/1
+Protocol: 2.00+
+============ ==================
+
+ If your boot loader has an assigned ID (see table below), enter
+ 0xTV here, where T is an identifier for the boot loader and V is
+ a version number. Otherwise, enter 0xFF here.
+
+ For boot loader IDs above T = 0xD, write T = 0xE to this field and
+ write the extended ID minus 0x10 to the ext_loader_type field.
+ Similarly, the ext_loader_ver field can be used to provide more than
+ four bits for the bootloader version.
+
+ For example, for T = 0x15, V = 0x234, write::
+
+ type_of_loader <- 0xE4
+ ext_loader_type <- 0x05
+ ext_loader_ver <- 0x23
+
+ Assigned boot loader IDs:
+
+ == =======================================
+ 0x0 LILO
+ (0x00 reserved for pre-2.00 bootloader)
+ 0x1 Loadlin
+ 0x2 bootsect-loader
+ (0x20, all other values reserved)
+ 0x3 Syslinux
+ 0x4 Etherboot/gPXE/iPXE
+ 0x5 ELILO
+ 0x7 GRUB
+ 0x8 U-Boot
+ 0x9 Xen
+ 0xA Gujin
+ 0xB Qemu
+ 0xC Arcturus Networks uCbootloader
+ 0xD kexec-tools
+ 0xE Extended (see ext_loader_type)
+ 0xF Special (0xFF = undefined)
+ 0x10 Reserved
+ 0x11 Minimal Linux Bootloader
+ <http://sebastian-plotz.blogspot.de>
+ 0x12 OVMF UEFI virtualization stack
+ 0x13 barebox
+ == =======================================
+
+ Please contact <hpa@zytor.com> if you need a bootloader ID value assigned.
+
+============ ===================
+Field name: loadflags
+Type: modify (obligatory)
+Offset/size: 0x211/1
+Protocol: 2.00+
+============ ===================
+
+ This field is a bitmask.
+
+ Bit 0 (read): LOADED_HIGH
+
+ - If 0, the protected-mode code is loaded at 0x10000.
+ - If 1, the protected-mode code is loaded at 0x100000.
+
+ Bit 1 (kernel internal): KASLR_FLAG
+
+ - Used internally by the compressed kernel to communicate
+ KASLR status to kernel proper.
+
+ - If 1, KASLR enabled.
+ - If 0, KASLR disabled.
+
+ Bit 5 (write): QUIET_FLAG
+
+ - If 0, print early messages.
+ - If 1, suppress early messages.
+
+ This requests to the kernel (decompressor and early
+ kernel) to not write early messages that require
+ accessing the display hardware directly.
+
+ Bit 6 (obsolete): KEEP_SEGMENTS
+
+ Protocol: 2.07+
+
+ - This flag is obsolete.
+
+ Bit 7 (write): CAN_USE_HEAP
+
+ Set this bit to 1 to indicate that the value entered in the
+ heap_end_ptr is valid. If this field is clear, some setup code
+ functionality will be disabled.
+
+
+============ ===================
+Field name: setup_move_size
+Type: modify (obligatory)
+Offset/size: 0x212/2
+Protocol: 2.00-2.01
+============ ===================
+
+ When using protocol 2.00 or 2.01, if the real mode kernel is not
+ loaded at 0x90000, it gets moved there later in the loading
+ sequence. Fill in this field if you want additional data (such as
+ the kernel command line) moved in addition to the real-mode kernel
+ itself.
+
+ The unit is bytes starting with the beginning of the boot sector.
+
+ This field is can be ignored when the protocol is 2.02 or higher, or
+ if the real-mode code is loaded at 0x90000.
+
+============ ========================
+Field name: code32_start
+Type: modify (optional, reloc)
+Offset/size: 0x214/4
+Protocol: 2.00+
+============ ========================
+
+ The address to jump to in protected mode. This defaults to the load
+ address of the kernel, and can be used by the boot loader to
+ determine the proper load address.
+
+ This field can be modified for two purposes:
+
+ 1. as a boot loader hook (see Advanced Boot Loader Hooks below.)
+
+ 2. if a bootloader which does not install a hook loads a
+ relocatable kernel at a nonstandard address it will have to modify
+ this field to point to the load address.
+
+============ ==================
+Field name: ramdisk_image
+Type: write (obligatory)
+Offset/size: 0x218/4
+Protocol: 2.00+
+============ ==================
+
+ The 32-bit linear address of the initial ramdisk or ramfs. Leave at
+ zero if there is no initial ramdisk/ramfs.
+
+============ ==================
+Field name: ramdisk_size
+Type: write (obligatory)
+Offset/size: 0x21c/4
+Protocol: 2.00+
+============ ==================
+
+ Size of the initial ramdisk or ramfs. Leave at zero if there is no
+ initial ramdisk/ramfs.
+
+============ ===============
+Field name: bootsect_kludge
+Type: kernel internal
+Offset/size: 0x220/4
+Protocol: 2.00+
+============ ===============
+
+ This field is obsolete.
+
+============ ==================
+Field name: heap_end_ptr
+Type: write (obligatory)
+Offset/size: 0x224/2
+Protocol: 2.01+
+============ ==================
+
+ Set this field to the offset (from the beginning of the real-mode
+ code) of the end of the setup stack/heap, minus 0x0200.
+
+============ ================
+Field name: ext_loader_ver
+Type: write (optional)
+Offset/size: 0x226/1
+Protocol: 2.02+
+============ ================
+
+ This field is used as an extension of the version number in the
+ type_of_loader field. The total version number is considered to be
+ (type_of_loader & 0x0f) + (ext_loader_ver << 4).
+
+ The use of this field is boot loader specific. If not written, it
+ is zero.
+
+ Kernels prior to 2.6.31 did not recognize this field, but it is safe
+ to write for protocol version 2.02 or higher.
+
+============ =====================================================
+Field name: ext_loader_type
+Type: write (obligatory if (type_of_loader & 0xf0) == 0xe0)
+Offset/size: 0x227/1
+Protocol: 2.02+
+============ =====================================================
+
+ This field is used as an extension of the type number in
+ type_of_loader field. If the type in type_of_loader is 0xE, then
+ the actual type is (ext_loader_type + 0x10).
+
+ This field is ignored if the type in type_of_loader is not 0xE.
+
+ Kernels prior to 2.6.31 did not recognize this field, but it is safe
+ to write for protocol version 2.02 or higher.
+
+============ ==================
+Field name: cmd_line_ptr
+Type: write (obligatory)
+Offset/size: 0x228/4
+Protocol: 2.02+
+============ ==================
+
+ Set this field to the linear address of the kernel command line.
+ The kernel command line can be located anywhere between the end of
+ the setup heap and 0xA0000; it does not have to be located in the
+ same 64K segment as the real-mode code itself.
+
+ Fill in this field even if your boot loader does not support a
+ command line, in which case you can point this to an empty string
+ (or better yet, to the string "auto".) If this field is left at
+ zero, the kernel will assume that your boot loader does not support
+ the 2.02+ protocol.
+
+============ ===============
+Field name: initrd_addr_max
+Type: read
+Offset/size: 0x22c/4
+Protocol: 2.03+
+============ ===============
+
+ The maximum address that may be occupied by the initial
+ ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this
+ field is not present, and the maximum address is 0x37FFFFFF. (This
+ address is defined as the address of the highest safe byte, so if
+ your ramdisk is exactly 131072 bytes long and this field is
+ 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
+
+============ ============================
+Field name: kernel_alignment
+Type: read/modify (reloc)
+Offset/size: 0x230/4
+Protocol: 2.05+ (read), 2.10+ (modify)
+============ ============================
+
+ Alignment unit required by the kernel (if relocatable_kernel is
+ true.) A relocatable kernel that is loaded at an alignment
+ incompatible with the value in this field will be realigned during
+ kernel initialization.
+
+ Starting with protocol version 2.10, this reflects the kernel
+ alignment preferred for optimal performance; it is possible for the
+ loader to modify this field to permit a lesser alignment. See the
+ min_alignment and pref_address field below.
+
+============ ==================
+Field name: relocatable_kernel
+Type: read (reloc)
+Offset/size: 0x234/1
+Protocol: 2.05+
+============ ==================
+
+ If this field is nonzero, the protected-mode part of the kernel can
+ be loaded at any address that satisfies the kernel_alignment field.
+ After loading, the boot loader must set the code32_start field to
+ point to the loaded code, or to a boot loader hook.
+
+============ =============
+Field name: min_alignment
+Type: read (reloc)
+Offset/size: 0x235/1
+Protocol: 2.10+
+============ =============
+
+ This field, if nonzero, indicates as a power of two the minimum
+ alignment required, as opposed to preferred, by the kernel to boot.
+ If a boot loader makes use of this field, it should update the
+ kernel_alignment field with the alignment unit desired; typically::
+
+ kernel_alignment = 1 << min_alignment;
+
+ There may be a considerable performance cost with an excessively
+ misaligned kernel. Therefore, a loader should typically try each
+ power-of-two alignment from kernel_alignment down to this alignment.
+
+============ ==========
+Field name: xloadflags
+Type: read
+Offset/size: 0x236/2
+Protocol: 2.12+
+============ ==========
+
+ This field is a bitmask.
+
+ Bit 0 (read): XLF_KERNEL_64
+
+ - If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+ Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+
+ - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+ Bit 2 (read): XLF_EFI_HANDOVER_32
+
+ - If 1, the kernel supports the 32-bit EFI handoff entry point
+ given at handover_offset.
+
+ Bit 3 (read): XLF_EFI_HANDOVER_64
+
+ - If 1, the kernel supports the 64-bit EFI handoff entry point
+ given at handover_offset + 0x200.
+
+ Bit 4 (read): XLF_EFI_KEXEC
+
+ - If 1, the kernel supports kexec EFI boot with EFI runtime support.
+
+
+============ ============
+Field name: cmdline_size
+Type: read
+Offset/size: 0x238/4
+Protocol: 2.06+
+============ ============
+
+ The maximum size of the command line without the terminating
+ zero. This means that the command line can contain at most
+ cmdline_size characters. With protocol version 2.05 and earlier, the
+ maximum size was 255.
+
+============ ====================================
+Field name: hardware_subarch
+Type: write (optional, defaults to x86/PC)
+Offset/size: 0x23c/4
+Protocol: 2.07+
+============ ====================================
+
+ In a paravirtualized environment the hardware low level architectural
+ pieces such as interrupt handling, page table handling, and
+ accessing process control registers needs to be done differently.
+
+ This field allows the bootloader to inform the kernel we are in one
+ one of those environments.
+
+ ========== ==============================
+ 0x00000000 The default x86/PC environment
+ 0x00000001 lguest
+ 0x00000002 Xen
+ 0x00000003 Intel MID (Moorestown, CloverTrail, Merrifield, Moorefield)
+ 0x00000004 CE4100 TV Platform
+ ========== ==============================
+
+============ =========================
+Field name: hardware_subarch_data
+Type: write (subarch-dependent)
+Offset/size: 0x240/8
+Protocol: 2.07+
+============ =========================
+
+ A pointer to data that is specific to hardware subarch
+ This field is currently unused for the default x86/PC environment,
+ do not modify.
+
+============ ==============
+Field name: payload_offset
+Type: read
+Offset/size: 0x248/4
+Protocol: 2.08+
+============ ==============
+
+ If non-zero then this field contains the offset from the beginning
+ of the protected-mode code to the payload.
+
+ The payload may be compressed. The format of both the compressed and
+ uncompressed data should be determined using the standard magic
+ numbers. The currently supported compression formats are gzip
+ (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
+ (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
+ 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
+ currently always ELF (magic number 7F 45 4C 46).
+
+============ ==============
+Field name: payload_length
+Type: read
+Offset/size: 0x24c/4
+Protocol: 2.08+
+============ ==============
+
+ The length of the payload.
+
+============ ===============
+Field name: setup_data
+Type: write (special)
+Offset/size: 0x250/8
+Protocol: 2.09+
+============ ===============
+
+ The 64-bit physical pointer to NULL terminated single linked list of
+ struct setup_data. This is used to define a more extensible boot
+ parameters passing mechanism. The definition of struct setup_data is
+ as follow::
+
+ struct setup_data {
+ __u64 next;
+ __u32 type;
+ __u32 len;
+ __u8 data[];
+ }
+
+ Where, the next is a 64-bit physical pointer to the next node of
+ linked list, the next field of the last node is 0; the type is used
+ to identify the contents of data; the len is the length of data
+ field; the data holds the real payload.
+
+ This list may be modified at a number of points during the bootup
+ process. Therefore, when modifying this list one should always make
+ sure to consider the case where the linked list already contains
+ entries.
+
+ The setup_data is a bit awkward to use for extremely large data objects,
+ both because the setup_data header has to be adjacent to the data object
+ and because it has a 32-bit length field. However, it is important that
+ intermediate stages of the boot process have a way to identify which
+ chunks of memory are occupied by kernel data.
+
+ Thus setup_indirect struct and SETUP_INDIRECT type were introduced in
+ protocol 2.15::
+
+ struct setup_indirect {
+ __u32 type;
+ __u32 reserved; /* Reserved, must be set to zero. */
+ __u64 len;
+ __u64 addr;
+ };
+
+ The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be
+ SETUP_INDIRECT itself since making the setup_indirect a tree structure
+ could require a lot of stack space in something that needs to parse it
+ and stack space can be limited in boot contexts.
+
+ Let's give an example how to point to SETUP_E820_EXT data using setup_indirect.
+ In this case setup_data and setup_indirect will look like this::
+
+ struct setup_data {
+ .next = 0, /* or <addr_of_next_setup_data_struct> */
+ .type = SETUP_INDIRECT,
+ .len = sizeof(setup_indirect),
+ .data[sizeof(setup_indirect)] = (struct setup_indirect) {
+ .type = SETUP_INDIRECT | SETUP_E820_EXT,
+ .reserved = 0,
+ .len = <len_of_SETUP_E820_EXT_data>,
+ .addr = <addr_of_SETUP_E820_EXT_data>,
+ },
+ }
+
+.. note::
+ SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished
+ from SETUP_INDIRECT itself. So, this kind of objects cannot be provided
+ by the bootloaders.
+
+============ ============
+Field name: pref_address
+Type: read (reloc)
+Offset/size: 0x258/8
+Protocol: 2.10+
+============ ============
+
+ This field, if nonzero, represents a preferred load address for the
+ kernel. A relocating bootloader should attempt to load at this
+ address if possible.
+
+ A non-relocatable kernel will unconditionally move itself and to run
+ at this address. A relocatable kernel will move itself to this address if it
+ loaded below this address.
+
+============ =======
+Field name: init_size
+Type: read
+Offset/size: 0x260/4
+============ =======
+
+ This field indicates the amount of linear contiguous memory starting
+ at the kernel runtime start address that the kernel needs before it
+ is capable of examining its memory map. This is not the same thing
+ as the total amount of memory the kernel needs to boot, but it can
+ be used by a relocating boot loader to help select a safe load
+ address for the kernel.
+
+ The kernel runtime start address is determined by the following algorithm::
+
+ if (relocatable_kernel) {
+ if (load_address < pref_address)
+ load_address = pref_address;
+ runtime_start = align_up(load_address, kernel_alignment);
+ } else {
+ runtime_start = pref_address;
+ }
+
+Hence the necessary memory window location and size can be estimated by
+a boot loader as::
+
+ memory_window_start = runtime_start;
+ memory_window_size = init_size;
+
+============ ===============
+Field name: handover_offset
+Type: read
+Offset/size: 0x264/4
+============ ===============
+
+ This field is the offset from the beginning of the kernel image to
+ the EFI handover protocol entry point. Boot loaders using the EFI
+ handover protocol to boot the kernel should jump to this offset.
+
+ See EFI HANDOVER PROTOCOL below for more details.
+
+============ ==================
+Field name: kernel_info_offset
+Type: read
+Offset/size: 0x268/4
+Protocol: 2.15+
+============ ==================
+
+ This field is the offset from the beginning of the kernel image to the
+ kernel_info. The kernel_info structure is embedded in the Linux image
+ in the uncompressed protected mode region.
+
+
+The kernel_info
+===============
+
+The relationships between the headers are analogous to the various data
+sections::
+
+ setup_header = .data
+ boot_params/setup_data = .bss
+
+What is missing from the above list? That's right::
+
+ kernel_info = .rodata
+
+We have been (ab)using .data for things that could go into .rodata or .bss for
+a long time, for lack of alternatives and -- especially early on -- inertia.
+Also, the BIOS stub is responsible for creating boot_params, so it isn't
+available to a BIOS-based loader (setup_data is, though).
+
+setup_header is permanently limited to 144 bytes due to the reach of the
+2-byte jump field, which doubles as a length field for the structure, combined
+with the size of the "hole" in struct boot_params that a protected-mode loader
+or the BIOS stub has to copy it into. It is currently 119 bytes long, which
+leaves us with 25 very precious bytes. This isn't something that can be fixed
+without revising the boot protocol entirely, breaking backwards compatibility.
+
+boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
+by adding setup_data entries. It cannot be used to communicate properties of
+the kernel image, because it is .bss and has no image-provided content.
+
+kernel_info solves this by providing an extensible place for information about
+the kernel image. It is readonly, because the kernel cannot rely on a
+bootloader copying its contents anywhere, but that is OK; if it becomes
+necessary it can still contain data items that an enabled bootloader would be
+expected to copy into a setup_data chunk.
+
+All kernel_info data should be part of this structure. Fixed size data have to
+be put before kernel_info_var_len_data label. Variable size data have to be put
+after kernel_info_var_len_data label. Each chunk of variable size data has to
+be prefixed with header/magic and its size, e.g.::
+
+ kernel_info:
+ .ascii "LToP" /* Header, Linux top (structure). */
+ .long kernel_info_var_len_data - kernel_info
+ .long kernel_info_end - kernel_info
+ .long 0x01234567 /* Some fixed size data for the bootloaders. */
+ kernel_info_var_len_data:
+ example_struct: /* Some variable size data for the bootloaders. */
+ .ascii "0123" /* Header/Magic. */
+ .long example_struct_end - example_struct
+ .ascii "Struct"
+ .long 0x89012345
+ example_struct_end:
+ example_strings: /* Some variable size data for the bootloaders. */
+ .ascii "ABCD" /* Header/Magic. */
+ .long example_strings_end - example_strings
+ .asciz "String_0"
+ .asciz "String_1"
+ example_strings_end:
+ kernel_info_end:
+
+This way the kernel_info is self-contained blob.
+
+.. note::
+ Each variable size data header/magic can be any 4-character string,
+ without \0 at the end of the string, which does not collide with
+ existing variable length data headers/magics.
+
+
+Details of the kernel_info Fields
+=================================
+
+============ ========
+Field name: header
+Offset/size: 0x0000/4
+============ ========
+
+ Contains the magic number "LToP" (0x506f544c).
+
+============ ========
+Field name: size
+Offset/size: 0x0004/4
+============ ========
+
+ This field contains the size of the kernel_info including kernel_info.header.
+ It does not count kernel_info.kernel_info_var_len_data size. This field should be
+ used by the bootloaders to detect supported fixed size fields in the kernel_info
+ and beginning of kernel_info.kernel_info_var_len_data.
+
+============ ========
+Field name: size_total
+Offset/size: 0x0008/4
+============ ========
+
+ This field contains the size of the kernel_info including kernel_info.header
+ and kernel_info.kernel_info_var_len_data.
+
+============ ==============
+Field name: setup_type_max
+Offset/size: 0x000c/4
+============ ==============
+
+ This field contains maximal allowed type for setup_data and setup_indirect structs.
+
+
+The Kernel Command Line
+=======================
+
+The kernel command line has become an important way for the boot
+loader to communicate with the kernel. Some of its options are also
+relevant to the boot loader itself, see "special command line options"
+below.
+
+The kernel command line is a null-terminated string. The maximum
+length can be retrieved from the field cmdline_size. Before protocol
+version 2.06, the maximum was 255 characters. A string that is too
+long will be automatically truncated by the kernel.
+
+If the boot protocol version is 2.02 or later, the address of the
+kernel command line is given by the header field cmd_line_ptr (see
+above.) This address can be anywhere between the end of the setup
+heap and 0xA0000.
+
+If the protocol version is *not* 2.02 or higher, the kernel
+command line is entered using the following protocol:
+
+ - At offset 0x0020 (word), "cmd_line_magic", enter the magic
+ number 0xA33F.
+
+ - At offset 0x0022 (word), "cmd_line_offset", enter the offset
+ of the kernel command line (relative to the start of the
+ real-mode kernel).
+
+ - The kernel command line *must* be within the memory region
+ covered by setup_move_size, so you may need to adjust this
+ field.
+
+
+Memory Layout of The Real-Mode Code
+===================================
+
+The real-mode code requires a stack/heap to be set up, as well as
+memory allocated for the kernel command line. This needs to be done
+in the real-mode accessible memory in bottom megabyte.
+
+It should be noted that modern machines often have a sizable Extended
+BIOS Data Area (EBDA). As a result, it is advisable to use as little
+of the low megabyte as possible.
+
+Unfortunately, under the following circumstances the 0x90000 memory
+segment has to be used:
+
+ - When loading a zImage kernel ((loadflags & 0x01) == 0).
+ - When loading a 2.01 or earlier boot protocol kernel.
+
+.. note::
+ For the 2.00 and 2.01 boot protocols, the real-mode code
+ can be loaded at another address, but it is internally
+ relocated to 0x90000. For the "old" protocol, the
+ real-mode code must be loaded at 0x90000.
+
+When loading at 0x90000, avoid using memory above 0x9a000.
+
+For boot protocol 2.02 or higher, the command line does not have to be
+located in the same 64K segment as the real-mode setup code; it is
+thus permitted to give the stack/heap the full 64K segment and locate
+the command line above it.
+
+The kernel command line should not be located below the real-mode
+code, nor should it be located in high memory.
+
+
+Sample Boot Configuration
+=========================
+
+As a sample configuration, assume the following layout of the real
+mode segment.
+
+ When loading below 0x90000, use the entire segment:
+
+ ============= ===================
+ 0x0000-0x7fff Real mode kernel
+ 0x8000-0xdfff Stack and heap
+ 0xe000-0xffff Kernel command line
+ ============= ===================
+
+ When loading at 0x90000 OR the protocol version is 2.01 or earlier:
+
+ ============= ===================
+ 0x0000-0x7fff Real mode kernel
+ 0x8000-0x97ff Stack and heap
+ 0x9800-0x9fff Kernel command line
+ ============= ===================
+
+Such a boot loader should enter the following fields in the header::
+
+ unsigned long base_ptr; /* base address for real-mode segment */
+
+ if (setup_sects == 0)
+ setup_sects = 4;
+
+ if (protocol >= 0x0200) {
+ type_of_loader = <type code>;
+ if (loading_initrd) {
+ ramdisk_image = <initrd_address>;
+ ramdisk_size = <initrd_size>;
+ }
+
+ if (protocol >= 0x0202 && loadflags & 0x01)
+ heap_end = 0xe000;
+ else
+ heap_end = 0x9800;
+
+ if (protocol >= 0x0201) {
+ heap_end_ptr = heap_end - 0x200;
+ loadflags |= 0x80; /* CAN_USE_HEAP */
+ }
+
+ if (protocol >= 0x0202) {
+ cmd_line_ptr = base_ptr + heap_end;
+ strcpy(cmd_line_ptr, cmdline);
+ } else {
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = heap_end;
+ setup_move_size = heap_end + strlen(cmdline) + 1;
+ strcpy(base_ptr + cmd_line_offset, cmdline);
+ }
+ } else {
+ /* Very old kernel */
+
+ heap_end = 0x9800;
+
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = heap_end;
+
+ /* A very old kernel MUST have its real-mode code loaded at 0x90000 */
+ if (base_ptr != 0x90000) {
+ /* Copy the real-mode kernel */
+ memcpy(0x90000, base_ptr, (setup_sects + 1) * 512);
+ base_ptr = 0x90000; /* Relocated */
+ }
+
+ strcpy(0x90000 + cmd_line_offset, cmdline);
+
+ /* It is recommended to clear memory up to the 32K mark */
+ memset(0x90000 + (setup_sects + 1) * 512, 0, (64 - (setup_sects + 1)) * 512);
+ }
+
+
+Loading The Rest of The Kernel
+==============================
+
+The 32-bit (non-real-mode) kernel starts at offset (setup_sects + 1) * 512
+in the kernel file (again, if setup_sects == 0 the real value is 4.)
+It should be loaded at address 0x10000 for Image/zImage kernels and
+0x100000 for bzImage kernels.
+
+The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01
+bit (LOAD_HIGH) in the loadflags field is set::
+
+ is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
+ load_address = is_bzImage ? 0x100000 : 0x10000;
+
+.. note::
+ Image/zImage kernels can be up to 512K in size, and thus use the entire
+ 0x10000-0x90000 range of memory. This means it is pretty much a
+ requirement for these kernels to load the real-mode part at 0x90000.
+ bzImage kernels allow much more flexibility.
+
+Special Command Line Options
+============================
+
+If the command line provided by the boot loader is entered by the
+user, the user may expect the following command line options to work.
+They should normally not be deleted from the kernel command line even
+though not all of them are actually meaningful to the kernel. Boot
+loader authors who need additional command line options for the boot
+loader itself should get them registered in
+Documentation/admin-guide/kernel-parameters.rst to make sure they will not
+conflict with actual kernel options now or in the future.
+
+ vga=<mode>
+ <mode> here is either an integer (in C notation, either
+ decimal, octal, or hexadecimal) or one of the strings
+ "normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
+ (meaning 0xFFFD). This value should be entered into the
+ vid_mode field, as it is used by the kernel before the command
+ line is parsed.
+
+ mem=<size>
+ <size> is an integer in C notation optionally followed by
+ (case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
+ << 30, << 40, << 50 or << 60). This specifies the end of
+ memory to the kernel. This affects the possible placement of
+ an initrd, since an initrd should be placed near end of
+ memory. Note that this is an option to *both* the kernel and
+ the bootloader!
+
+ initrd=<file>
+ An initrd should be loaded. The meaning of <file> is
+ obviously bootloader-dependent, and some boot loaders
+ (e.g. LILO) do not have such a command.
+
+In addition, some boot loaders add the following options to the
+user-specified command line:
+
+ BOOT_IMAGE=<file>
+ The boot image which was loaded. Again, the meaning of <file>
+ is obviously bootloader-dependent.
+
+ auto
+ The kernel was booted without explicit user intervention.
+
+If these options are added by the boot loader, it is highly
+recommended that they are located *first*, before the user-specified
+or configuration-specified command line. Otherwise, "init=/bin/sh"
+gets confused by the "auto" option.
+
+
+Running the Kernel
+==================
+
+The kernel is started by jumping to the kernel entry point, which is
+located at *segment* offset 0x20 from the start of the real mode
+kernel. This means that if you loaded your real-mode kernel code at
+0x90000, the kernel entry point is 9020:0000.
+
+At entry, ds = es = ss should point to the start of the real-mode
+kernel code (0x9000 if the code is loaded at 0x90000), sp should be
+set up properly, normally pointing to the top of the heap, and
+interrupts should be disabled. Furthermore, to guard against bugs in
+the kernel, it is recommended that the boot loader sets fs = gs = ds =
+es = ss.
+
+In our example from above, we would do::
+
+ /*
+ * Note: in the case of the "old" kernel protocol, base_ptr must
+ * be == 0x90000 at this point; see the previous sample code.
+ */
+ seg = base_ptr >> 4;
+
+ cli(); /* Enter with interrupts disabled! */
+
+ /* Set up the real-mode kernel stack */
+ _SS = seg;
+ _SP = heap_end;
+
+ _DS = _ES = _FS = _GS = seg;
+ jmp_far(seg + 0x20, 0); /* Run the kernel */
+
+If your boot sector accesses a floppy drive, it is recommended to
+switch off the floppy motor before running the kernel, since the
+kernel boot leaves interrupts off and thus the motor will not be
+switched off, especially if the loaded kernel has the floppy driver as
+a demand-loaded module!
+
+
+Advanced Boot Loader Hooks
+==========================
+
+If the boot loader runs in a particularly hostile environment (such as
+LOADLIN, which runs under DOS) it may be impossible to follow the
+standard memory location requirements. Such a boot loader may use the
+following hooks that, if set, are invoked by the kernel at the
+appropriate time. The use of these hooks should probably be
+considered an absolutely last resort!
+
+IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
+%edi across invocation.
+
+ realmode_swtch:
+ A 16-bit real mode far subroutine invoked immediately before
+ entering protected mode. The default routine disables NMI, so
+ your routine should probably do so, too.
+
+ code32_start:
+ A 32-bit flat-mode routine *jumped* to immediately after the
+ transition to protected mode, but before the kernel is
+ uncompressed. No segments, except CS, are guaranteed to be
+ set up (current kernels do, but older ones do not); you should
+ set them up to BOOT_DS (0x18) yourself.
+
+ After completing your hook, you should jump to the address
+ that was in this field before your boot loader overwrote it
+ (relocated, if appropriate.)
+
+
+32-bit Boot Protocol
+====================
+
+For machine with some new BIOS other than legacy BIOS, such as EFI,
+LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
+based on legacy BIOS can not be used, so a 32-bit boot protocol needs
+to be defined.
+
+In 32-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+traditionally known as "zero page"). The memory for struct boot_params
+should be allocated and initialized to all zero. Then the setup header
+from offset 0x01f1 of kernel image on should be loaded into struct
+boot_params and examined. The end of setup header can be calculated as
+follow::
+
+ 0x0202 + byte value at offset 0x0201
+
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as
+described in chapter Documentation/arch/x86/zero-page.rst.
+
+After setting up the struct boot_params, the boot loader can load the
+32/64-bit kernel in the same way as that of 16-bit boot protocol.
+
+In 32-bit boot protocol, the kernel is started by jumping to the
+32-bit kernel entry point, which is the start address of loaded
+32/64-bit kernel.
+
+At entry, the CPU must be in 32-bit protected mode with paging
+disabled; a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
+must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
+address of the struct boot_params; %ebp, %edi and %ebx must be zero.
+
+64-bit Boot Protocol
+====================
+
+For machine with 64bit cpus and 64bit kernel, we could use 64bit bootloader
+and we need a 64-bit boot protocol.
+
+In 64-bit boot protocol, the first step in loading a Linux kernel
+should be to setup the boot parameters (struct boot_params,
+traditionally known as "zero page"). The memory for struct boot_params
+could be allocated anywhere (even above 4G) and initialized to all zero.
+Then, the setup header at offset 0x01f1 of kernel image on should be
+loaded into struct boot_params and examined. The end of setup header
+can be calculated as follows::
+
+ 0x0202 + byte value at offset 0x0201
+
+In addition to read/modify/write the setup header of the struct
+boot_params as that of 16-bit boot protocol, the boot loader should
+also fill the additional fields of the struct boot_params as described
+in chapter Documentation/arch/x86/zero-page.rst.
+
+After setting up the struct boot_params, the boot loader can load
+64-bit kernel in the same way as that of 16-bit boot protocol, but
+kernel could be loaded above 4G.
+
+In 64-bit boot protocol, the kernel is started by jumping to the
+64-bit kernel entry point, which is the start address of loaded
+64-bit kernel plus 0x200.
+
+At entry, the CPU must be in 64-bit mode with paging enabled.
+The range with setup_header.init_size from start address of loaded
+kernel and zero page and command line buffer get ident mapping;
+a GDT must be loaded with the descriptors for selectors
+__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
+must be __BOOT_DS; interrupt must be disabled; %rsi must hold the base
+address of the struct boot_params.
+
+EFI Handover Protocol (deprecated)
+==================================
+
+This protocol allows boot loaders to defer initialisation to the EFI
+boot stub. The boot loader is required to load the kernel/initrd(s)
+from the boot media and jump to the EFI handover protocol entry point
+which is hdr->handover_offset bytes from the beginning of
+startup_{32,64}.
+
+The boot loader MUST respect the kernel's PE/COFF metadata when it comes
+to section alignment, the memory footprint of the executable image beyond
+the size of the file itself, and any other aspect of the PE/COFF header
+that may affect correct operation of the image as a PE/COFF binary in the
+execution context provided by the EFI firmware.
+
+The function prototype for the handover entry point looks like this::
+
+ void efi_stub_entry(void *handle, efi_system_table_t *table, struct boot_params *bp);
+
+'handle' is the EFI image handle passed to the boot loader by the EFI
+firmware, 'table' is the EFI system table - these are the first two
+arguments of the "handoff state" as described in section 2.3 of the
+UEFI specification. 'bp' is the boot loader-allocated boot params.
+
+The boot loader *must* fill out the following fields in bp::
+
+ - hdr.cmd_line_ptr
+ - hdr.ramdisk_image (if applicable)
+ - hdr.ramdisk_size (if applicable)
+
+All other fields should be zero.
+
+.. note::
+ The EFI Handover Protocol is deprecated in favour of the ordinary PE/COFF
+ entry point described below.
+
+.. _pe-coff-entry-point:
+
+PE/COFF entry point
+===================
+
+When compiled with ``CONFIG_EFI_STUB=y``, the kernel can be executed as a
+regular PE/COFF binary. See Documentation/admin-guide/efi-stub.rst for
+implementation details.
+
+The stub loader can request the initrd via a UEFI protocol. For this to work,
+the firmware or bootloader needs to register a handle which carries
+implementations of the ``EFI_LOAD_FILE2`` protocol and the device path
+protocol exposing the ``LINUX_EFI_INITRD_MEDIA_GUID`` vendor media device path.
+In this case, a kernel booting via the EFI stub will invoke
+``LoadFile2::LoadFile()`` method on the registered protocol to instruct the
+firmware to load the initrd into a memory location chosen by the kernel/EFI
+stub.
+
+This approach removes the need for any knowledge on the part of the EFI
+bootloader regarding the internal representation of boot_params or any
+requirements/limitations regarding the placement of the command line and
+ramdisk in memory, or the placement of the kernel image itself.
+
+For sample implementations, refer to `the original u-boot implementation`_ or
+`the OVMF implementation`_.
+
+.. _the original u-boot implementation: https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0
+.. _the OVMF implementation: https://github.com/tianocore/edk2/blob/1780373897f12c25075f8883e073144506441168/OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c
diff --git a/Documentation/x86/booting-dt.rst b/Documentation/arch/x86/booting-dt.rst
index 965a374071ab..b089ffd56e6e 100644
--- a/Documentation/x86/booting-dt.rst
+++ b/Documentation/arch/x86/booting-dt.rst
@@ -7,7 +7,7 @@ DeviceTree Booting
the decompressor (the real mode entry point goes to the same 32bit
entry point once it switched into protected mode). That entry point
supports one calling convention which is documented in
- Documentation/x86/boot.rst
+ Documentation/arch/x86/boot.rst
The physical pointer to the device-tree block is passed via setup_data
which requires at least boot protocol 2.09.
The type filed is defined as
diff --git a/Documentation/x86/buslock.rst b/Documentation/arch/x86/buslock.rst
index 7c051e714943..31f1bfdff16f 100644
--- a/Documentation/x86/buslock.rst
+++ b/Documentation/arch/x86/buslock.rst
@@ -26,13 +26,14 @@ Detection
=========
Intel processors may support either or both of the following hardware
-mechanisms to detect split locks and bus locks.
+mechanisms to detect split locks and bus locks. Some AMD processors also
+support bus lock detect.
#AC exception for split lock detection
--------------------------------------
Beginning with the Tremont Atom CPU split lock operations may raise an
-Alignment Check (#AC) exception when a split lock operation is attemped.
+Alignment Check (#AC) exception when a split lock operation is attempted.
#DB exception for bus lock detection
------------------------------------
@@ -53,8 +54,14 @@ parameter "split_lock_detect". Here is a summary of different options:
|off |Do nothing |Do nothing |
+------------------+----------------------------+-----------------------+
|warn |Kernel OOPs |Warn once per task and |
-|(default) |Warn once per task and |and continues to run. |
-| |disable future checking | |
+|(default) |Warn once per task, add a |and continues to run. |
+| |delay, add synchronization | |
+| |to prevent more than one | |
+| |core from executing a | |
+| |split lock in parallel. | |
+| |sysctl split_lock_mitigate | |
+| |can be used to avoid the | |
+| |delay and synchronization | |
| |When both features are | |
| |supported, warn in #AC | |
+------------------+----------------------------+-----------------------+
diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst
new file mode 100644
index 000000000000..9f2e47c4b1c8
--- /dev/null
+++ b/Documentation/arch/x86/cpuinfo.rst
@@ -0,0 +1,202 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+x86 Feature Flags
+=================
+
+Introduction
+============
+
+The list of feature flags in /proc/cpuinfo is not complete and
+represents an ill-fated attempt from long time ago to put feature flags
+in an easy to find place for userspace.
+
+However, the number of feature flags is growing with each CPU generation,
+leading to unparseable and unwieldy /proc/cpuinfo.
+
+What is more, those feature flags do not even need to be in that file
+because userspace doesn't care about them - glibc et al already use
+CPUID to find out what the target machine supports and what not.
+
+And even if it doesn't show a particular feature flag - although the CPU
+still does have support for the respective hardware functionality and
+said CPU supports CPUID faulting - userspace can simply probe for the
+feature and figure out if it is supported or not, regardless of whether
+it is being advertised somewhere.
+
+Furthermore, those flag strings become an ABI the moment they appear
+there and maintaining them forever when nothing even uses them is a lot
+of wasted effort.
+
+So, the current use of /proc/cpuinfo is to show features which the
+kernel has *enabled* and *supports*. As in: the CPUID feature flag is
+there, there's an additional setup which the kernel has done while
+booting and the functionality is ready to use. A perfect example for
+that is "user_shstk" where additional code enablement is present in the
+kernel to support shadow stack for user programs.
+
+So, if users want to know if a feature is available on a given system,
+they try to find the flag in /proc/cpuinfo. If a given flag is present,
+it means that
+
+* the kernel knows about the feature enough to have an X86_FEATURE bit
+
+* the kernel supports it and is currently making it available either to
+ userspace or some other part of the kernel
+
+* if the flag represents a hardware feature the hardware supports it.
+
+The absence of a flag in /proc/cpuinfo by itself means almost nothing to
+an end user.
+
+On the one hand, a feature like "vaes" might be fully available to user
+applications on a kernel that has not defined X86_FEATURE_VAES and thus
+there is no "vaes" in /proc/cpuinfo.
+
+On the other hand, a new kernel running on non-VAES hardware would also
+have no "vaes" in /proc/cpuinfo. There's no way for an application or
+user to tell the difference.
+
+The end result is that the flags field in /proc/cpuinfo is marginally
+useful for kernel debugging, but not really for anything else.
+Applications should instead use things like the glibc facilities for
+querying CPU support. Users should rely on tools like
+tools/arch/x86/kcpuid and cpuid(1).
+
+Regarding implementation, flags appearing in /proc/cpuinfo have an
+X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. These flags
+represent hardware features as well as software features.
+
+If the kernel cares about a feature or KVM want to expose the feature to
+a KVM guest, it should only then expose it to the guest when the guest
+needs to parse /proc/cpuinfo. Which, as mentioned above, is highly
+unlikely. KVM can synthesize the CPUID bit and the KVM guest can simply
+query CPUID and figure out what the hypervisor supports and what not. As
+already stated, /proc/cpuinfo is not a dumping ground for useless
+feature flags.
+
+
+How are feature flags created?
+==============================
+
+Feature flags can be derived from the contents of CPUID leaves
+--------------------------------------------------------------
+
+These feature definitions are organized mirroring the layout of CPUID
+leaves and grouped in words with offsets as mapped in enum cpuid_leafs
+in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details).
+If a feature is defined with a X86_FEATURE_<name> definition in
+cpufeatures.h, and if it is detected at run time, the flags will be
+displayed accordingly in /proc/cpuinfo. For example, the flag "avx2"
+comes from X86_FEATURE_AVX2 in cpufeatures.h.
+
+Flags can be from scattered CPUID-based features
+------------------------------------------------
+
+Hardware features enumerated in sparsely populated CPUID leaves get
+software-defined values. Still, CPUID needs to be queried to determine
+if a given feature is present. This is done in init_scattered_cpuid_features().
+For instance, X86_FEATURE_CQM_LLC is defined as 11*32 + 0 and its presence is
+checked at runtime in the respective CPUID leaf [EAX=f, ECX=0] bit EDX[1].
+
+The intent of scattering CPUID leaves is to not bloat struct
+cpuinfo_x86.x86_capability[] unnecessarily. For instance, the CPUID leaf
+[EAX=7, ECX=0] has 30 features and is dense, but the CPUID leaf [EAX=7, EAX=1]
+has only one feature and would waste 31 bits of space in the x86_capability[]
+array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted
+memory is not trivial.
+
+Flags can be created synthetically under certain conditions for hardware features
+---------------------------------------------------------------------------------
+
+Examples of conditions include whether certain features are present in
+MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed
+conditions are met, the features are enabled by the set_cpu_cap or
+setup_force_cpu_cap macros. For example, if bit 5 is set in MSR_IA32_CORE_CAPS,
+the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and
+"split_lock_detect" will be displayed. The flag "ring3mwait" will be
+displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors.
+
+Flags can represent purely software features
+--------------------------------------------
+These flags do not represent hardware features. Instead, they represent a
+software feature implemented in the kernel. For example, Kernel Page Table
+Isolation is purely software feature and its feature flag X86_FEATURE_PTI is
+also defined in cpufeatures.h.
+
+Naming of Flags
+===============
+
+The script arch/x86/kernel/cpu/mkcapflags.sh processes the
+#define X86_FEATURE_<name> from cpufeatures.h and generates the
+x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the
+resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming
+of flags in the x86_cap/bug_flags[] are as follows:
+
+Flags do not appear by default in /proc/cpuinfo
+-----------------------------------------------
+
+Feature flags are omitted by default from /proc/cpuinfo as it does not make
+sense for the feature to be exposed to userspace in most cases. For example,
+X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal
+kernel feature used in the alternative runtime patching functionality. So the
+flag does not appear in /proc/cpuinfo.
+
+Specify a flag name if absolutely needed
+----------------------------------------
+
+If the comment on the line for the #define X86_FEATURE_* starts with a
+double-quote character (""), the string inside the double-quote characters
+will be the name of the flags. For example, the flag "sse4_1" comes from
+the comment "sse4_1" following the X86_FEATURE_XMM4_1 definition.
+
+There are situations in which overriding the displayed name of the flag is
+needed. For instance, /proc/cpuinfo is a userspace interface and must remain
+constant. If, for some reason, the naming of X86_FEATURE_<name> changes, one
+shall override the new naming with the name already used in /proc/cpuinfo.
+
+Flags are missing when one or more of these happen
+==================================================
+
+The hardware does not enumerate support for it
+----------------------------------------------
+
+For example, when a new kernel is running on old hardware or the feature is
+not enabled by boot firmware. Even if the hardware is new, there might be a
+problem enabling the feature at run time, the flag will not be displayed.
+
+The kernel does not know about the flag
+---------------------------------------
+
+For example, when an old kernel is running on new hardware.
+
+The kernel disabled support for it at compile-time
+--------------------------------------------------
+
+For example, if Linear Address Masking (LAM) is not enabled when building (i.e.,
+CONFIG_ADDRESS_MASKING is not selected) the flag "lam" will not show up.
+Even though the feature will still be detected via CPUID, the kernel disables
+it by clearing via setup_clear_cpu_cap(X86_FEATURE_LAM).
+
+The feature is disabled at boot-time
+------------------------------------
+A feature can be disabled either using a command-line parameter or because
+it failed to be enabled. The command-line parameter clearcpuid= can be used
+to disable features using the feature number as defined in
+/arch/x86/include/asm/cpufeatures.h. For instance, User Mode Instruction
+Protection can be disabled using clearcpuid=514. The number 514 is calculated
+from #define X86_FEATURE_UMIP (16*32 + 2).
+
+In addition, there exists a variety of custom command-line parameters that
+disable specific features. The list of parameters includes, but is not limited
+to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using
+"no5lvl".
+
+The feature was known to be non-functional
+------------------------------------------
+
+The feature was known to be non-functional because a dependency was
+missing at runtime. For example, AVX flags will not show up if XSAVE feature
+is disabled since they depend on XSAVE feature. Another example would be broken
+CPUs and them missing microcode patches. Due to that, the kernel decides not to
+enable a feature.
diff --git a/Documentation/x86/earlyprintk.rst b/Documentation/arch/x86/earlyprintk.rst
index 51ef11e8f725..51ef11e8f725 100644
--- a/Documentation/x86/earlyprintk.rst
+++ b/Documentation/arch/x86/earlyprintk.rst
diff --git a/Documentation/x86/elf_auxvec.rst b/Documentation/arch/x86/elf_auxvec.rst
index 18e4744717f9..18e4744717f9 100644
--- a/Documentation/x86/elf_auxvec.rst
+++ b/Documentation/arch/x86/elf_auxvec.rst
diff --git a/Documentation/x86/entry_64.rst b/Documentation/arch/x86/entry_64.rst
index 0afdce3c06f4..0afdce3c06f4 100644
--- a/Documentation/x86/entry_64.rst
+++ b/Documentation/arch/x86/entry_64.rst
diff --git a/Documentation/x86/exception-tables.rst b/Documentation/arch/x86/exception-tables.rst
index efde1fef4fbd..6e7177363f8f 100644
--- a/Documentation/x86/exception-tables.rst
+++ b/Documentation/arch/x86/exception-tables.rst
@@ -297,7 +297,7 @@ vma occurs?
c) execution continues at local label 2 (address of the
instruction immediately after the faulting user access).
-The steps 8a to 8c in a certain way emulate the faulting instruction.
+ The steps a to c above in a certain way emulate the faulting instruction.
That's it, mostly. If you look at our example, you might ask why
we set EAX to -EFAULT in the exception handler code. Well, the
diff --git a/Documentation/arch/x86/features.rst b/Documentation/arch/x86/features.rst
new file mode 100644
index 000000000000..a33616346a38
--- /dev/null
+++ b/Documentation/arch/x86/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features x86
diff --git a/Documentation/x86/i386/IO-APIC.rst b/Documentation/arch/x86/i386/IO-APIC.rst
index ce4d8df15e7c..ce4d8df15e7c 100644
--- a/Documentation/x86/i386/IO-APIC.rst
+++ b/Documentation/arch/x86/i386/IO-APIC.rst
diff --git a/Documentation/x86/i386/index.rst b/Documentation/arch/x86/i386/index.rst
index 8747cf5bbd49..8747cf5bbd49 100644
--- a/Documentation/x86/i386/index.rst
+++ b/Documentation/arch/x86/i386/index.rst
diff --git a/Documentation/x86/ifs.rst b/Documentation/arch/x86/ifs.rst
index 97abb696a680..97abb696a680 100644
--- a/Documentation/x86/ifs.rst
+++ b/Documentation/arch/x86/ifs.rst
diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/index.rst
new file mode 100644
index 000000000000..f88bcfceb7f2
--- /dev/null
+++ b/Documentation/arch/x86/index.rst
@@ -0,0 +1,46 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================
+x86-specific Documentation
+==========================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ boot
+ booting-dt
+ cpuinfo
+ topology
+ exception-tables
+ kernel-stacks
+ entry_64
+ earlyprintk
+ orc-unwinder
+ zero-page
+ tlb
+ mtrr
+ pat
+ intel-hfi
+ shstk
+ iommu
+ intel_txt
+ amd-debugging
+ amd-memory-encryption
+ amd_hsmp
+ amd-hfi
+ tdx
+ pti
+ mds
+ microcode
+ tsx_async_abort
+ buslock
+ usb-legacy-support
+ i386/index
+ x86_64/index
+ ifs
+ sva
+ sgx
+ features
+ elf_auxvec
+ xstate
diff --git a/Documentation/x86/intel-hfi.rst b/Documentation/arch/x86/intel-hfi.rst
index 49dea58ea4fb..49dea58ea4fb 100644
--- a/Documentation/x86/intel-hfi.rst
+++ b/Documentation/arch/x86/intel-hfi.rst
diff --git a/Documentation/x86/intel_txt.rst b/Documentation/arch/x86/intel_txt.rst
index d83c1a2122c9..d83c1a2122c9 100644
--- a/Documentation/x86/intel_txt.rst
+++ b/Documentation/arch/x86/intel_txt.rst
diff --git a/Documentation/arch/x86/iommu.rst b/Documentation/arch/x86/iommu.rst
new file mode 100644
index 000000000000..41fbadfe2221
--- /dev/null
+++ b/Documentation/arch/x86/iommu.rst
@@ -0,0 +1,151 @@
+=================
+x86 IOMMU Support
+=================
+
+The architecture specs can be obtained from the below locations.
+
+- Intel: http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
+- AMD: https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/specifications/48882_3_07_PUB.pdf
+
+This guide gives a quick cheat sheet for some basic understanding.
+
+Basic stuff
+-----------
+
+ACPI enumerates and lists the different IOMMUs on the platform, and
+device scope relationships between devices and which IOMMU controls
+them.
+
+Some ACPI Keywords:
+
+- DMAR - Intel DMA Remapping table
+- DRHD - Intel DMA Remapping Hardware Unit Definition
+- RMRR - Intel Reserved Memory Region Reporting Structure
+- IVRS - AMD I/O Virtualization Reporting Structure
+- IVDB - AMD I/O Virtualization Definition Block
+- IVHD - AMD I/O Virtualization Hardware Definition
+
+What is Intel RMRR?
+^^^^^^^^^^^^^^^^^^^
+
+There are some devices the BIOS controls, for e.g USB devices to perform
+PS2 emulation. The regions of memory used for these devices are marked
+reserved in the e820 map. When we turn on DMA translation, DMA to those
+regions will fail. Hence BIOS uses RMRR to specify these regions along with
+devices that need to access these regions. OS is expected to setup
+unity mappings for these regions for these devices to access these regions.
+
+What is AMD IVRS?
+^^^^^^^^^^^^^^^^^
+
+The architecture defines an ACPI-compatible data structure called an I/O
+Virtualization Reporting Structure (IVRS) that is used to convey information
+related to I/O virtualization to system software. The IVRS describes the
+configuration and capabilities of the IOMMUs contained in the platform as
+well as information about the devices that each IOMMU virtualizes.
+
+The IVRS provides information about the following:
+
+- IOMMUs present in the platform including their capabilities and proper configuration
+- System I/O topology relevant to each IOMMU
+- Peripheral devices that cannot be otherwise enumerated
+- Memory regions used by SMI/SMM, platform firmware, and platform hardware. These are generally exclusion ranges to be configured by system software.
+
+How is an I/O Virtual Address (IOVA) generated?
+-----------------------------------------------
+
+Well behaved drivers call dma_map_*() calls before sending command to device
+that needs to perform DMA. Once DMA is completed and mapping is no longer
+required, driver performs dma_unmap_*() calls to unmap the region.
+
+Intel Specific Notes
+--------------------
+
+Graphics Problems?
+^^^^^^^^^^^^^^^^^^
+
+If you encounter issues with graphics devices, you can try adding
+option intel_iommu=igfx_off to turn off the integrated graphics engine.
+If this fixes anything, please ensure you file a bug reporting the problem.
+
+Some exceptions to IOVA
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Interrupt ranges are not address translated, (0xfee00000 - 0xfeefffff).
+The same is true for peer to peer transactions. Hence we reserve the
+address from PCI MMIO ranges so they are not allocated for IOVA addresses.
+
+AMD Specific Notes
+------------------
+
+Graphics Problems?
+^^^^^^^^^^^^^^^^^^
+
+If you encounter issues with integrated graphics devices, you can try adding
+option iommu=pt to the kernel command line use a 1:1 mapping for the IOMMU. If
+this fixes anything, please ensure you file a bug reporting the problem.
+
+Fault reporting
+---------------
+When errors are reported, the IOMMU signals via an interrupt. The fault
+reason and device that caused it is printed on the console.
+
+
+Kernel Log Samples
+------------------
+
+Intel Boot Messages
+^^^^^^^^^^^^^^^^^^^
+
+Something like this gets printed indicating presence of DMAR tables
+in ACPI:
+
+::
+
+ ACPI: DMAR (v001 A M I OEMDMAR 0x00000001 MSFT 0x00000097) @ 0x000000007f5b5ef0
+
+When DMAR is being processed and initialized by ACPI, prints DMAR locations
+and any RMRR's processed:
+
+::
+
+ ACPI DMAR:Host address width 36
+ ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed90000
+ ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed91000
+ ACPI DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000
+ ACPI DMAR:RMRR base: 0x00000000000ed000 end: 0x00000000000effff
+ ACPI DMAR:RMRR base: 0x000000007f600000 end: 0x000000007fffffff
+
+When DMAR is enabled for use, you will notice:
+
+::
+
+ PCI-DMA: Using DMAR IOMMU
+
+Intel Fault reporting
+^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000
+ DMAR:[fault reason 05] PTE Write access is not set
+ DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000
+ DMAR:[fault reason 05] PTE Write access is not set
+
+AMD Boot Messages
+^^^^^^^^^^^^^^^^^
+
+Something like this gets printed indicating presence of the IOMMU:
+
+::
+
+ iommu: Default domain type: Translated
+ iommu: DMA domain TLB invalidation policy: lazy mode
+
+AMD Fault reporting
+^^^^^^^^^^^^^^^^^^^
+
+::
+
+ AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 address=0xffffc02000 flags=0x0000]
+ AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 domain=0x0007 address=0xffffc02000 flags=0x0000]
diff --git a/Documentation/x86/kernel-stacks.rst b/Documentation/arch/x86/kernel-stacks.rst
index 6b0bcf027ff1..738671a4070b 100644
--- a/Documentation/x86/kernel-stacks.rst
+++ b/Documentation/arch/x86/kernel-stacks.rst
@@ -12,7 +12,7 @@ Most of the text from Keith Owens, hacked by AK
x86_64 page size (PAGE_SIZE) is 4K.
Like all other architectures, x86_64 has a kernel stack for every
-active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
+active thread. These thread stacks are THREAD_SIZE (4*PAGE_SIZE) big.
These stacks contain useful data as long as a thread is alive or a
zombie. While the thread is in user space the kernel stack is empty
except for the thread_info structure at the bottom.
diff --git a/Documentation/x86/mds.rst b/Documentation/arch/x86/mds.rst
index 5d4330be200f..3518671e1a85 100644
--- a/Documentation/x86/mds.rst
+++ b/Documentation/arch/x86/mds.rst
@@ -60,7 +60,7 @@ needed for exploiting MDS requires:
data
The existence of such a construct in the kernel cannot be excluded with
-100% certainty, but the complexity involved makes it extremly unlikely.
+100% certainty, but the complexity involved makes it extremely unlikely.
There is one exception, which is untrusted BPF. The functionality of
untrusted BPF is limited, but it needs to be thoroughly investigated
@@ -93,7 +93,10 @@ enters a C-state.
The kernel provides a function to invoke the buffer clearing:
- mds_clear_cpu_buffers()
+ x86_clear_cpu_buffers()
+
+Also macro CLEAR_CPU_BUFFERS can be used in ASM late in exit-to-user path.
+Other than CFLAGS.ZF, this macro doesn't clobber any registers.
The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state
(idle) transitions.
@@ -138,17 +141,30 @@ Mitigation points
When transitioning from kernel to user space the CPU buffers are flushed
on affected CPUs when the mitigation is not disabled on the kernel
- command line. The migitation is enabled through the static key
- mds_user_clear.
-
- The mitigation is invoked in prepare_exit_to_usermode() which covers
- all but one of the kernel to user space transitions. The exception
- is when we return from a Non Maskable Interrupt (NMI), which is
- handled directly in do_nmi().
-
- (The reason that NMI is special is that prepare_exit_to_usermode() can
- enable IRQs. In NMI context, NMIs are blocked, and we don't want to
- enable IRQs with NMIs blocked.)
+ command line. The mitigation is enabled through the feature flag
+ X86_FEATURE_CLEAR_CPU_BUF.
+
+ The mitigation is invoked just before transitioning to userspace after
+ user registers are restored. This is done to minimize the window in
+ which kernel data could be accessed after VERW e.g. via an NMI after
+ VERW.
+
+ **Corner case not handled**
+ Interrupts returning to kernel don't clear CPUs buffers since the
+ exit-to-user path is expected to do that anyways. But, there could be
+ a case when an NMI is generated in kernel after the exit-to-user path
+ has cleared the buffers. This case is not handled and NMI returning to
+ kernel don't clear CPU buffers because:
+
+ 1. It is rare to get an NMI after VERW, but before returning to userspace.
+ 2. For an unprivileged user, there is no known way to make that NMI
+ less rare or target it.
+ 3. It would take a large number of these precisely-timed NMIs to mount
+ an actual attack. There's presumably not enough bandwidth.
+ 4. The NMI in question occurs after a VERW, i.e. when user state is
+ restored and most interesting data is already scrubbed. What's left
+ is only the data that NMI touches, and that may or may not be of
+ any interest.
2. C-State transition
@@ -169,9 +185,9 @@ Mitigation points
idle clearing would be a window dressing exercise and is therefore not
activated.
- The invocation is controlled by the static key mds_idle_clear which is
- switched depending on the chosen mitigation mode and the SMT state of
- the system.
+ The invocation is controlled by the static key cpu_buf_idle_clear which is
+ switched depending on the chosen mitigation mode and the SMT state of the
+ system.
The buffer clear is only invoked before entering the C-State to prevent
that stale data from the idling CPU from spilling to the Hyper-Thread
diff --git a/Documentation/x86/microcode.rst b/Documentation/arch/x86/microcode.rst
index b627c6f36bcf..b627c6f36bcf 100644
--- a/Documentation/x86/microcode.rst
+++ b/Documentation/arch/x86/microcode.rst
diff --git a/Documentation/x86/mtrr.rst b/Documentation/arch/x86/mtrr.rst
index 9f0b1851771a..f65ef034da7a 100644
--- a/Documentation/x86/mtrr.rst
+++ b/Documentation/arch/x86/mtrr.rst
@@ -28,7 +28,7 @@ are aligned with platform MTRR setup. If MTRRs are only set up by the platform
firmware code though and the OS does not make any specific MTRR mapping
requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID.
-For details refer to Documentation/x86/pat.rst.
+For details refer to Documentation/arch/x86/pat.rst.
.. tip::
On Intel P6 family processors (Pentium Pro, Pentium II and later)
diff --git a/Documentation/x86/orc-unwinder.rst b/Documentation/arch/x86/orc-unwinder.rst
index cdb257015bd9..cdb257015bd9 100644
--- a/Documentation/x86/orc-unwinder.rst
+++ b/Documentation/arch/x86/orc-unwinder.rst
diff --git a/Documentation/x86/pat.rst b/Documentation/arch/x86/pat.rst
index 5d901771016d..5d901771016d 100644
--- a/Documentation/x86/pat.rst
+++ b/Documentation/arch/x86/pat.rst
diff --git a/Documentation/x86/pti.rst b/Documentation/arch/x86/pti.rst
index 4b858a9bad8d..57e8392f61d3 100644
--- a/Documentation/x86/pti.rst
+++ b/Documentation/arch/x86/pti.rst
@@ -26,9 +26,9 @@ comments in pti.c).
This approach helps to ensure that side-channel attacks leveraging
the paging structures do not function when PTI is enabled. It can be
-enabled by setting CONFIG_PAGE_TABLE_ISOLATION=y at compile time.
-Once enabled at compile-time, it can be disabled at boot with the
-'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt).
+enabled by setting CONFIG_MITIGATION_PAGE_TABLE_ISOLATION=y at compile
+time. Once enabled at compile-time, it can be disabled at boot with
+the 'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt).
Page Table Management
=====================
@@ -81,11 +81,9 @@ this protection comes at a cost:
and exit (it can be skipped when the kernel is interrupted,
though.) Moves to CR3 are on the order of a hundred
cycles, and are required at every entry and exit.
- b. A "trampoline" must be used for SYSCALL entry. This
- trampoline depends on a smaller set of resources than the
- non-PTI SYSCALL entry code, so requires mapping fewer
- things into the userspace page tables. The downside is
- that stacks must be switched at entry time.
+ b. Percpu TSS is mapped into the user page tables to allow SYSCALL64 path
+ to work under PTI. This doesn't have a direct runtime cost but it can
+ be argued it opens certain timing attack scenarios.
c. Global pages are disabled for all kernel structures not
mapped into both kernel and userspace page tables. This
feature of the MMU allows different processes to share TLB
@@ -167,7 +165,7 @@ that are worth noting here.
* Failures of the selftests/x86 code. Usually a bug in one of the
more obscure corners of entry_64.S
* Crashes in early boot, especially around CPU bringup. Bugs
- in the trampoline code or mappings cause these.
+ in the mappings cause these.
* Crashes at the first interrupt. Caused by bugs in entry_64.S,
like screwing up a page table switch. Also caused by
incorrectly mapping the IRQ handler entry code.
diff --git a/Documentation/arch/x86/resume.svg b/Documentation/arch/x86/resume.svg
new file mode 100644
index 000000000000..ad8839f762bf
--- /dev/null
+++ b/Documentation/arch/x86/resume.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than draw.io -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="582px" height="1152px" viewBox="-0.5 -0.5 582 1152" content="&lt;mxfile host=&quot;confluence.amd.com&quot; agent=&quot;Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0&quot; version=&quot;24.7.10&quot; scale=&quot;1&quot; border=&quot;0&quot;&gt;&#10; &lt;diagram id=&quot;lFF5s3GfZ4Py3fAf5dUH&quot; name=&quot;Page-1&quot;&gt;&#10; &lt;mxGraphModel dx=&quot;2364&quot; dy=&quot;1473&quot; grid=&quot;1&quot; gridSize=&quot;10&quot; guides=&quot;1&quot; tooltips=&quot;1&quot; connect=&quot;1&quot; arrows=&quot;1&quot; fold=&quot;1&quot; page=&quot;0&quot; pageScale=&quot;1&quot; pageWidth=&quot;850&quot; pageHeight=&quot;1100&quot; math=&quot;0&quot; shadow=&quot;0&quot;&gt;&#10; &lt;root&gt;&#10; &lt;mxCell id=&quot;0&quot; /&gt;&#10; &lt;mxCell id=&quot;1&quot; parent=&quot;0&quot; /&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-10&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-1&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-9&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-1&quot; value=&quot;Wakeup event occurs&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.start_2;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#0CF232;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;-240&quot; y=&quot;-190&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-8&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-3&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-4&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-56&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-3&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-13&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-3&quot; value=&quot;MP1 hands off control to OS&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;-190&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-4&quot; value=&quot;&amp;lt;span style=&amp;quot;background-color: rgb(232, 205, 151);&amp;quot;&amp;gt;&amp;lt;span style=&amp;quot;color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: center; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;&amp;quot;&amp;gt;OS Moves one core out of ACPI C3&amp;lt;/span&amp;gt;&amp;lt;br&amp;gt;&amp;lt;/span&amp;gt;&quot; style=&quot;verticalLabelPosition=middle;verticalAlign=middle;html=1;shape=process;whiteSpace=wrap;rounded=1;size=0.14;arcSize=6;labelPosition=center;align=center;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;240&quot; y=&quot;-170&quot; width=&quot;100&quot; height=&quot;60&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-11&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-9&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-3&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-9&quot; value=&quot;MP0/MP1 boot process&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;-80&quot; y=&quot;-190&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-27&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-13&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-16&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-13&quot; value=&quot;OS checks all wake sources&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;-40&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-29&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-15&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-17&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-44&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-29&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.28&quot; y=&quot;2&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;8&quot; y=&quot;-8&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-34&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-15&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-41&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-34&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.1165&quot; y=&quot;-1&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;153&quot; y=&quot;11&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-15&quot; value=&quot;ACPI fixed &amp;lt;br&amp;gt;event active&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;260&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-28&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-16&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-15&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-43&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-28&quot;&gt;&#10; &lt;mxGeometry y=&quot;2&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;8&quot; y=&quot;-15&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-57&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-16&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-58&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-57&quot;&gt;&#10; &lt;mxGeometry x=&quot;0.0145&quot; y=&quot;1&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;102&quot; y=&quot;9&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-16&quot; value=&quot;IRQ other &amp;lt;br&amp;gt;than ACPI SCI active&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;110&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-30&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-17&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;130&quot; y=&quot;560&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-65&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-30&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.4694&quot; y=&quot;1&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;9&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-36&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-17&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-35&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-45&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-36&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.2867&quot; y=&quot;2&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;5&quot; y=&quot;8&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-17&quot; value=&quot;GPIO&amp;lt;br&amp;gt;IRQ shared&amp;lt;br&amp;gt;with SCI&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;410&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-31&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;130&quot; y=&quot;660&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;mxPoint x=&quot;130&quot; y=&quot;710&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-32&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-23&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;130&quot; y=&quot;810&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-48&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-32&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.1714&quot; y=&quot;-4&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;14&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-52&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-23&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-53&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-52&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.5259&quot; y=&quot;-5&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;220&quot; y=&quot;15&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-62&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-23&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-54&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-64&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-62&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.7472&quot; y=&quot;3&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-92&quot; y=&quot;13&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-23&quot; value=&quot;Any PM&amp;lt;br&amp;gt;wakeup event&amp;lt;br&amp;gt;pending&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;860&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-24&quot; value=&quot;Kernel resumes system&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.terminator;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#0CF232;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;-240&quot; y=&quot;-20&quot; width=&quot;100&quot; height=&quot;60&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-26&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-24&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot; value=&quot;uPEP driver removes OS_HINT&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;-240&quot; y=&quot;110&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-37&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-35&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-40&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-37&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.56&quot; y=&quot;-2&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;67&quot; y=&quot;12&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-60&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=-0.008;entryY=0.422;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;entryPerimeter=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-35&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-38&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-50&quot; y=&quot;535&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;mxPoint x=&quot;20&quot; y=&quot;685&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-61&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-60&quot;&gt;&#10; &lt;mxGeometry x=&quot;0.1126&quot; y=&quot;-3&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-16&quot; y=&quot;-85&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-35&quot; value=&quot;Any GPIO&amp;lt;br&amp;gt;w/ WAKESTS&amp;lt;br&amp;gt;active&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;-90&quot; y=&quot;410&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-38&quot; value=&quot;Check for ACPI Notify() events&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;560&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-49&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-39&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-23&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-50&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-39&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-25&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-51&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontStyle=1;labelBackgroundColor=none;fontColor=#393C56;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;jeVlbFHk8Qahp5zcIn_D-50&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.4506&quot; y=&quot;-2&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;215&quot; y=&quot;12&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-39&quot; value=&quot;Any GPE &amp;lt;br&amp;gt;pending&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;80&quot; y=&quot;710&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-63&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;jeVlbFHk8Qahp5zcIn_D-54&quot; target=&quot;jeVlbFHk8Qahp5zcIn_D-55&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-54&quot; value=&quot;OS moves active &amp;lt;br&amp;gt;core back to&amp;lt;br&amp;gt;ACPI C3&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;240&quot; y=&quot;110&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;jeVlbFHk8Qahp5zcIn_D-55&quot; value=&quot;MP1 puts system back to sleep&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.terminator;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F27979;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;240&quot; y=&quot;-20&quot; width=&quot;100&quot; height=&quot;60&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;/root&gt;&#10; &lt;/mxGraphModel&gt;&#10; &lt;/diagram&gt;&#10;&lt;/mxfile&gt;&#10;"><defs/><g><g data-cell-id="0"><g data-cell-id="1"><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-10"><g><path d="M 101 51 L 154.63 51" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 159.88 51 L 152.88 54.5 L 154.63 51 L 152.88 47.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-1"><g><ellipse cx="51" cy="51" rx="50" ry="50" fill="#0cf232" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 51px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Wakeup event occurs</div></div></div></foreignObject><image x="2" y="37" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfQt0HMWV9nd7RpKBAGYhvBYSIPlhwyZZEi+WNBoJ8QwQjMFmRjYGAssuj+ADgSUPHnltCPsn7J8EAjiQEF4BWxowz8UJEBCS5iETE5YlwGbJ8gxgJ6wNDsiSZvr+1Ghm3Oqpnu6ehzQa3T7H5/hoqm5Xfbe6vqpbde8lyCMICAKCgCAgCGgQIEFFEBAEBAFBQBDQISAEIeNCEBAEBAFBQIuAEIQMDEFAEBAEBAEhCBkDgoAgIAgIAt4RkB2Ed6ykpCAgCAgCswoBIYhZpW7prCAgCAgC3hEQgvCOlZQUBAQBQWBWISAEMavULZ0VBAQBQcA7AjOKILq7T58zmn4vBtBxli4+YfCWBfH4/Zu9d3uiZFs4ejUB59vqvckGHZ4a6H3et7yOnmVE/AtLvbJl+X13vnxn56I90hwcBPCx3N82muAjh4di68qVKfUEAUFgdiIwowgiO6l3Rr9CjO9VOgmHwyfvlMH4GoBa7apnplNS8d47fA4JagtHbyLgjGqQl893F4oLQZSLnNQTBKqDQHt7ZBsYOBOEseRQ7MbqSJ0eKTOPIMLRIwj4dwDNOcgyzLQgFe9d4wfC1nBkngF6BMBORQQB3Jwa6jsTAHuVqSMcBq5JDfVd4FVGNcoJQVQDRZEhCPhHIBKJBP74lnEcs/l/AfobJnw1Ndj3ff+S6qfGjCOI9vbIXyNI/WB8PA8jMa5MxPsu8wNre0fP2SD+ib4OPzMWDB6+rn/ln73KDIUiB8GgRxjYZStx8aJUPHa/VxnVKCcEUQ0URYYg4B+B9s7oCjDOydcUgvCPYcU1uru7g6PpXe8EENkqjB9sCW4X6e+/ZYuXF2hkbARoI8D75eq/ZzIfPRyPDXmRp8q02c4fGHgtiEz30NDd/+NVRjXKCUFUA0WRIQj4R6C9M3oLGF8QgvCPXVVrtHVGLyTGDwpCCS8izd3JZOyPXl5UtAthPMZESQIXdiF+2b/4wNsfaXlpt5cyQhBeUJIygkD1ERCCqD6mZUls7YiEDaJfAtiunBV/m+0cQ50VAHhg8tmG9wm+o+P47U2a8wCAQ6Z79SAEUdaQkkqCQMUICEFUDGF1BMzrXrpLczr9a4A+XZDIdE4y3nuDlzeEOqLfZcKlubIZZl5EJtZZzzb8mIjauno+QSb/GsAe5RCWlzZ7LSME4RUpKScIVBcBIYjq4lmJNGrriN5GhFMKK3bGL1LxvtPcbh51d0c+NDpO94FwmKqbJ4Jg8O1XbWcbWeLwcsjc1hE5nohWAwhk2+PT5FUJEPa6QhDVRFNkCQLeERCC8I5VzUsW30Li4QCajhkaunNjqZcXr/a3mpLsMr1eU7XtSNTrYy3BDSf39/enndoyb95ZTXPmvDOPCREGHwLCPmDsbCk/AvDrxEYcjJWjozs+vm7djeNuwJZLEDmzm/L92NXyjg0wjBOTA6sSbu+dP//EnQNNwRNA+AcQHWDpywiAlwF62CTzxuHBmHJA9HR92P7BgXBrcrDvdLe25H/3Wt++aADwhyClOwcHV7+pZHV0RA4wDfoSTBwNwt65hcAImF9gwi/MsfSta9fe87bXdlWrXLbdaeMYwDwDoM8C2C0nW427V4hp0DT4Z3vvzqlYLJYp9d5QZ88S5qyTZ3aR42cHbZWrMf96chatxfhpC0cXEFC4RWg9V1RXUl97i9qIcR6ALgC7F/QKvMyg1RmDbnhyYNVrTrhpxk1p1focv9UaJ5XImXHXXPOdtfsxEPBnmHxkIhF7uiRB2G4bWa/IFvtGuJPOp486dbsPvT96DwNHFt5bwty11YmGvgHgwz6U9ycAF+y1B/eV+tjLIYj2zsh8MKkzFN/k0Nq6bIdAcPwKJpwLIOjWHwZSTHzm8GDsObeyXid4Jzle6zsRRDod2ATD+DaIL3TpW5qB6+cE+bL+/thf3PpV6e/ZMRTEcjB9HcD27vL4BTJwXmIg9rgTOc/viuwbMEmZSffNyyvHYbR4sUR3tgTXf8FpsVTL8eNEEPPDPfsb4FsJaHPBLkNEd3Ha/GIyGftfe1khCPeRN20ltI5pTItT8V5l6nF67N7OYwx8PjXU96iqoJHpGqYiHF68XxqBfkJ2Zakexzqt3Yv2MtKBu3Te2x6BzBDoxtGRHS9w2k34JQgncmBgWR4Xp7aFQj0Hs4FVluvBHrsBtav4cnKo7/pSuwmvE3wtCCKAzFEmBy5hwj967RTAw2Ywc9Jw/+rXvdfxV7Kte8k+lM6sKmMMZUD44dj7cy91GDvU3tlzDZiXW1rkuhO2tl5zNqgm2FMSg72rdL2s9fjREYQB/h0z3a5zkHXSBAP/YZjphYnE6lesZYQg/I3dqS5dFNrCzSRUNIA1ZwVF11VdDr/tN6LUJKEzdc07IrJjyxaKTdppTCCmtv5vAVgLkNolqDlT7SxCFpOBFdsxZlrqRIR+CEKZ22DyvQTsb3nBBi/k4EAsSkwa4BdBNAym0WxfCF0289lEv4kvSQ7G/s2JJKaRIF5iYA0BX7Tgovq1DjD+A8QtMDFhFrQ9BDwyOocj6x6NvVPtDyIUWvRRNoIPATjQJjsDxmtMSBHoXQbvQEAYwF7FbaAbx0Z2XK4jifZw5GiA7rNEKfBkHsq/o+hbKHEWNxXjx04QRLifObtrsO6UX2dgSOFWYqyCGD9rbtpwrnUnlI0NN/7+chD9nwkMzEOB/P+zf1Df9FaLBptrk/HYTdUeF7WUN2NNTAoUu3Oa+jj/sm3Lic88fPt7OtA09tGiFVJbR88iIr7bUr/kKqqtM3opMb6bL+9EUpoYUqrKvRmDL1o7EHtJ115l+84QrSDg0Mm/8xpksDiZjKmV+KTHK0E4TDYbifjUxGBMhTJxfBzqpomxIj0+/m27PV7Ze199A4cZZPzEttsYYeYlThcBppEgrH3PMOPeTMC40GaPpvauJQfBNG8D8ElrBQKtaA6uP7/UGZTfj9phgZFtmxngL2vGELV2Lv2UwembAPp7y/syDP5Kaii21Y8o92OltwOLFldE1yYHe1UwzElnTlM1fuwEYcV8wtQZOHt4cOV/Wtunxurrb5JydvuRzXy3gUw6PJHofdZJd3JI7XdU17i8/cDZ7WCtaJLW7A6KDrFLrIJ00WVZY+ZqbV26m9GUUWaswkRCRL2j7+94qtvBc9beHKBbrZ7jpfrphSAqIQflhT42vusKm+lFTfRnpOKxvlImo4O7I7sH01gJULeFUFPm2PhxukPeOiCIDAFXjI7M/a6TntrbI3+FAPUCOMIy3N8lk49OJGLJan0CmgVGBsyX77Unrip1JpU7yL4e4FMtbXkVGT48mYy9aG9fKBz9FgPf3Pp3b/5AmjE+BvDC5FBM+SsVnqkcP04EoXYDbPL5ugVWvqGhzuhiZihT1DaFseoSW0kIolqjvUpyNGcGk84UJg/MolDh2rMCjV3RUaYmLpR2S15shoLrasTads3OZxOZdFQi0fukHUo3gtBN0urcxMvOQb0rFOr5JBtZn4/8Nt3VVGRtY3t75OMIZA9DP5L7u6OderoJgoGbx0fmnu1G4upcAGnzV5NMdQ6r53KGvm6BATibiuzvUDeEjOamB62HsgR8OzHU960igghF2tnIOqHukPvNk5mp2DylN7VO5fjREcTEecL4UYnEPRtK6WJiYYa7ATqmQBAuV+mFIMoZ3TWuY9/WOoXIKD5Mdr6hZL+J4RQMsGjiZjzW0sQL7TdZVCA/06AzCPz3AH2UiIaaA+tP8WqC0Ez6as9+fGqoT908mvSUIggHM8VmZjrd5XC/8A77ClNt1Z12AE6q97pKnWaC8EXiRSv8KvrC2K+gAnDcAThibrvGCugDUmoPXt2dUIsOuB0JyLZDqeX40RKEjwirRTeyHL7vPOZCEDWe7MsRX+Sk5uCD0NbRcwwRqwk1f8/bMRR30YrfYWDYY0KVE1XWS5+rQRDpOXhRc0juixx0k4ffmFWqv3ZidTKZTS9BlL6eadebxpvecefpReeWMrrLGGWEoy+6becYkLI9HFW+AddubYPzmZcqo9lJa01sUz1+NAThKwin/YwTQhA+h24dFNc4vmlDdevCazgejhaHFC/aZmsiwlZrQihCtVKCAPGJYONMmx16nIhOc7qCqFOt5kpvebk4std9gwOWO/da7KaTIPz6ADjE47ooNdj3w0o+E+11boJvubr2wWFnoCG7krupokWaw0Q61eNHQxAvmcF0l9dryEX1hSAqGcrTU1ezKimyzzuF13AKxa0LKW6fMLxcma0EkQlP67f3NxE4HsTLVAKSQiiPiZNgryYmdaNLhRz/lL09Xg/K8/U0ZyHqIPJBwPCcN0PJYuZtiXC8xc4N3YQ8jQTheMZT0m5tC/fs1/PbIymrYr8CaNKdfLexxuAmAj4HYM98Wacdrz6kPpYnh/qu07xHl0lRW3aqx0+RHwTwex4PdA0Pr1zvhpf6XQhCRQ1qgMduK7RPNqXCazh1XxN2Y9K2fsLJhx/+4Drc3JwMX05FuTo0r3vpzs2Z9H5sYl+DsuESPsOACkKYD5ugbaIPgiil4TFmPi0Vj6lbOK5PqWuDrpVdCuhMVdNIEL5WmvmulRNyxQ23UpkP3eq6/l4i9EPxuYfezKTxwHY81J7q8eN3grfj5be+nEG4jrjpKWA/X1DX2BLxvn/Kt6YomQ/hstRg35WlWltMAJMPtYsIxOPhl9oZNG2z6WhiXAzCwdZrdH7QK5MgVIwe9W9O/l0M/B5B43Op/lUvu71/qj/waSSISbGY3HApjDN7vnQXk4QXudNFEJpzBa2ZSXOA7rhQmurx43eCF4IoHpENsYPQ2DafMHjLgnj8/s0qtmpbOHoTAWfkuu/prMBuQrLFerLL9HL4RaGuyKFs4rqcucjL/KDKZL1kQdkdxdY72d5NTPn3ZMNbZCPNMu6xyvLq2DXVH7gQBDBdBKG+G03ojUmmowlT1G63AnxybpCVDK0x1eNHCMLrFONcriEIQuOwVtjmVnBWUHx7hOmUVLz3jmKPU9cc1tQejqqwDVe57BjU6v4NAOtArJysnmgJbPdMJvPuTmkODgL4mGXl7/UMQlUpxD7q7u4O6BzdTOaFw/HYI6WGlOYDL2ul7XXYzjiCCEevJkB5Dk88VYjeqSEI1/hgXvF1K1fk22DbEWkWZi9lDD7cKTLAVI8fIQg3Dbv/3hAEobppC3lRuF3jJbyGE0yaPNPZq7H2j1Y5VKWG+s508iJuCy9pJZhrbAHCMh94mv6WYNwMEwPNzebLTpFAK7zFNEbAlxNDfT/Ot0/jrKYOvV0diIpMeR4j6LoPQ32J6SIIr5GBba0uzlECOF6l9oqJ8qGBQY8wsEt+lc5MC1LxXjWeavq4Ba8sugbq4hw41eNHCKLy4dE4BGFPI5o7ZyjKG+Hu9FNA1X64nY/1tO17YycQZWPnZ59SVyI123BVZTNAZyaHeu/ykhuhQoLQrjjbOqLnEGXvuk8kOZpoyBWpoT4Vhlybr0E/WXlLqlTOUC2O7eM9H4Q2DLvDit6P97xTP3TXUZ2ukfrBQnlRU1NmwOqlXY7viZ93WssWOUbmzto0u3ZtaI1JsrRkV9PxMykfhJsfgx0jvwQjh9TljrIpqKc5VIuNjcxd1jRn088tmed8bc8112Oz1+SoKXOpxZRQMhSBZhvuOhHb4dLcmPJzzdU5pEiaFEGpq4/5ZyPDOCY1tGpYpzJtMLcyQkqocAumwQ/RxIH50wT8NzFfF4/HXrW+1+6dzB6zBioZuonVyeSjc+By8gR2Gsq1MgXp4n0BpR3XdG3M4aHCgexEwH+ZwPOGyTe75U8J2UNv5MxMW0xj78lpdl3NrJjy8WNLGCQE4X8ibpgdRPHdbX6GDWMJmaaKnZ/LXe2eAKhocp6cv3qjwVhsUjaY2SG5stYD8SIN6O5+W3NQeFFZsWerLz8IR1LUm764f2wOTnAIV607uPQb9kGd7fzLB+RwuaXv+hhW9ltBQEmsJ5GLbUeZ/c37DkJtohJjc3Cs17DdmvAhvuqXGgca/b9rsHFcPL5KnUt5ekKd0VOYcYtlx+jpsoYmJlFWV8jgs9ZdtMcoAlM7foQgPI2NUoUahiBUJ60rzqwdmXApM76Xt/275YvQAWUPu8GEi8C4MJ8gyE2mJlCfL+9j3XmBaqePa66ldk26ydoxHHR2Zd4ROdKgbM6Awo0qP4Hj2ruWfAamqYLBWWLy8+qW4HbL+vtv2TJpkrdl/wO8BTlUV4lbtn3ndmbumaRTXwQBFUp7eSre9xO3r6yjY/HfmhRQPjEFJzTA0bHMTVzR7zr5fvJOTCSqCqozC2tY8qcyY+NHeUmVaicoJj6DmI61RBj2HL12SsePEITvsWav0FAEYVutZ2PlE2FxrtMZZv/2ziLTFWMAlE060qyuoLrJ1Njt1eTuKUqoIgcO0F0E/J1dcbqw4qqMWzTXoh1S6MRdTaPpYds7VC7qo5MDq35rL59LmboSRAstv7mGxVZlHUJjjzjdoNJf8SwdxTQbz/8NdZ2XrrCer/jfQWRruCZPcsgS+HzaMD5XKp+xzy+X2jujPwDjS5Pr0e0tQfOLpdKcKn2RQdfYwrN7Jr/swqur5xM2c9LgB4sCRYYTt+p8+HtM5fjxe4Zg14nf+vYzCI+7Kp9DYWqLNxRBaG2cOTzdckU4wa4/jMuSg6fE7iqCavMWPASQyhCXfzIM3MDjTZcMD9/xrv3d2QTuLcHzwHSxU85hp4NKvwSRnQA6Ij1EpBLfZPs18dHzfTCxVBczX78LyFZ60GBcHI/H/svWpxI+IM4TvkNKR0fslFevkaGriHBCETmoBvnbQeS7sBnE30Ea19qwyPXJ+KktCVKGCKcnBvsKlxiq8Uk77AIU5r9hBJanhlattV8uaO2MHEhMygdoUu5lP7sP1XaHixbWbjmF4dB2farGj98JvlKCKLpUATyHDC/U5d2oxpiYChkNRRAOMWTyM96DLcHtInYzhheQHbLBZSdELzI19t/8a0fA/ALIeCq7G1GpIlVKRMrmty7cLsreeiKsB+PjhfnbwRu8HIJwMMmUnOh0CVUsWBbSOObSXx5mS/M4UZSQDCK9eHBw9ZtOeshl+Fs5ibwmCivfjjhA/5NNAQp0gLGvBbcRMF0LYpVTeqfc+25NDvadbn+XAxGN2d65mVQWMtBLJfvkI0+Dl7FnLVMiTafC8m2o3a1KW1siJWoWL8M8ITkQU5nUPD8aj+l8XV9h0fOVpmL8TDVBFN2YnOhszreJVMbFgeambc4tZw7yrKgqF2woglDYOCgJ7CG8hhO2moPmbFGv1w2zE/A271zN4LO0K9uSSuUXyDROMwMcJkYhTaTTjZ5yCEK93sGOXvIAOtQZ+bzfBPBbu8rDZjBzkltkTYVd87abrlTnPj6wG2HiLwbMwLMmmepswDdBEHCBCfyDzrznoK4MCD8ce3/upW4Jhir5hidW33yXbdfiUaQiBzpJZzp0E6C5JZir4m2RpJNf6/Ez1QTh8A1Zuu7/koybXmr9e8MRhENoAk83NpzAdjBdeQmvURCZnejmbLoABOVnsL0Hxf4JzP8CEzcp04bXhPDlEoRqT1s4chGBvm/zjSh5XnJw15K9m5ivYmZ11hP00C8nk41j1Vye4OgHE/3VAD5c+h1qR4ZzkoOxJ4rGgg8Tk7oEQBmOU9C4nplPKk1O/AIZOC8xEHvci1+LB4xKFmltXbYDNY1/hwAVb8xyWcCxWjZfeCbddLnOpOmxPbobSCVDa3iRW8vxM9UEkQ3r0xn5AjFdr9NLuWZuLzjWqkzDEYT+rjVeRJq7k8nYH8sEsjikcZkZw9T5QrC5aRmDe0B0ABg759qktqKvENMgGCtHR3d83LoS1aSd1JqAKiGI3HnJvdac0cqUw8xLnHJn5PFU7Qs0ZXqy/QKpw8t8NNoMgLdUBjPAuLklaK4pdahaSj/KFDSWoROY+VwbdusBfopBK8ZH5v4yj1ulBJHL2Edt4SXzCaYi96Ms+lIhox9j4Od778GPl8oLXeaYc62WzRA4SgvAOI2BAwHsbiEyhckfwPh5Zjx9r5fbSm4v1NzIKxlaw02e9fdajJ9pIIhsl9TZj8GkrnEr06o1KrOvRaUf/GpVtuEIolZAidzGRUCb6cwhGGLjoiA9EwSKERCCkFEx6xEQgpj1Q0AAcEBACEKGxqxHQAhi1g8BAUAIQsaAIKBHQAhCRoYgoEdAdhAyMmY9AkIQs34ICACyg5AxIAjIDkLGgCDgBwHZQfhBS8o2JAKyg2hItUqnqoCAEEQVQBQRMxsBIYiZrT9pfe0QEIKoHbYieYYgIAQxQxQlzZxyBIQgphxyeWG9ISAEUW8akfbUCwJCEPWiCWmHICAICAJ1hoAQRJ0pRJojCAgCgkC9ICAEUS+akHYIAoKAIFBnCAhB1JlCpDmCgCAgCNQLAkIQ9aIJaYcgIAgIAnWGgBBEnSlEmiMICAKCQL0gIARRL5qQdggCgoAgUGcICEHUmUKkOYKAICAI1AsCQhD1oglphyAgCAgCdYaAEESdKUSaIwgIAoJAvSAgBFEvmpB2CAKCgCBQZwgIQdSZQqQ5goAgIAjUCwJCEPWiCWmHICAICAJ1hoAQRJ0pRJojCAgCgkC9ICAEUS+akHYIAoKAIFBnCAhB1JlCpDmCgCAgCNQLAkIQ9aIJaYcgIAgIAnWGgBBEnSlEmiMICAKCQL0gIARRL5qQdggCgoAgUGcICEHUmUKkOYKAICAI1AsCQhD1ook6ase8eWc1tbS8cygbfDqALgC7AwjkmriegGdAuG20hR9Y92jsnUqaPn/+iTsHmoInEFEPA58GsFtO3giAlwF62CTzxuHB2PMA2O+7qiW/s3PRHmkODgL4WL4NDByfGup7wEub/NQvKst4rKWJF/b3x94LdUU72cSVAFoBBAGs/0BHjzHhur1351QsFsvY29PaunS3QFOmh8E9IDoAjJ1zZdIA3gAwDFCsJWiu6e+P/cVLf6TM7EBACGJ26NlTL9vbI9vAwJkg+gaAD3uoNMLAT3m86evDw3e866F8oUhr67IdqGn8OwT8E4BtXOpmAB7kYOCMVP+ql728p9ry/Uzwuvb5qa8jiMz4eDTQ0vQ1MC60kLX1VWMMfD411Pdo/o8Hd0d2b8oYP2LmxTkycYNuM4i/gzSuTSZjiqDlmeUICEHM8gEwaTJJ020MHFkGJM+yQdHUQK9a5bs+oVCknQ26C8CeroUnF9jAwDLrJKirXwv5fib4qhMEuJ9hxAn8NQdyUJurxNgcHJvf0bW3Rz6OAN0H4ECfGCtZ/ekglj7ZH3vLf12p0UgICEE0kjbL7EsotOijbAQf0k4mhLfBGADoTwzegYAwgL00r3rDYGNhPL7qN6Wa0d4ZmQ8mZZbZ1VYuA8JLAOJgGiXwvgy0AdjeVm4DDOPo5MCq3+reUyv500sQ2AygBUBzts+Ml2Hgiez/TRwCwj4AlieH+q5Tf5p3RGTHli0U05D9ZoD/EzCenRDjrE8Gbh4fmXv2unU3jpc5rKRaAyAgBNEASqykC93dkQ+NprOr+c/Z5DzLhHNSg30Ju+2/tTNyIDHdRBMTuPV51gymjxnuX/26rk2t3Yv2MtLBNQA+afk9w4x7zQB/ee1ATBFE4cm2LUPfBONLk0wkzPfBxFK7GaSW8qeZIPKYjBDwtb/eg6+znDVQOLx430zG2JRMxv5XFWzviCgz4Q2W3cYIES4YfX/uLZoJn9q7lhwE07zNppd3yeSjE4lYspLxJXVnNgJCEDNbfxW3vq0jeg4RrrWZLvrG5vBZpQ6g1UF287abriyyiRN+lBzsu0h3oBwKR7/FwDet5ADmy/faE1fpDldz5ai9M3IxmP7V0sYxgBcmh2K/tAJQS/l1QRDMlyTjse+VOqzv7j59zmj6vRhAx1mwKewunAZMW/eSfZA2f0XA/vkyDFyTGuq7oOJBJgJmLAJCEDNWdZU3XJkimrfgoQ9uCoUsk0LKHBs/bu3ae952e0P2ttO279zOzD2Wsm8YnDkqHr/7d9b66iaN0ZRRB6iF3YNXM0Z2JzFO94Fw2FaZdGdLcP0X+vv71U0c1Fp+HRDESxmDD7fvsuw6UjhQU2bAMtFvNMFHDg/F1rnpsz0cPQ/ILhZyDw8H0HTM0NCdG93qyu+NiYAQRGPq1VOv2sLRIwj494JtG9CuzEsJC4V6PskG/9p6psCEr6YG+75vrdfWETmeiFZbdgGeJy4lJ9TZs4SZf5Gvz8DveTzQNTy8Ul3zRK3l1wFBxFqCG07OE6KTTjTtfM9kPno4HhtyGxShUM/BbPA9DLwH4CkDeJozfI3caHJDrnF/F4JoXN269izUEf0uEy6tZMXY3d0dHE3veieAiEXOgy3B7SL9/bdsyf+tLRy9moDzLWXWIIPFXiefcHjxfhkYiswyIPoNAXFO8915u3ut5U83QTDhstRgn/J/KPl0dBy/vUlz1CWAQyxYy60kN+Dkdy0CQhCzdGB8+qhTt/vQ+6NqtVi41lquzbm9o+dsEP/EAuUfgpTuHBxc/ab6m/ZdHic8L+qptXzVhmknCB9OeZqzGNWFTSCsMky6dcuWHdfJ7SQvI0vKCEHM0jEwr3vpLs3p9K8BUt7LEw/TOcl4r7r94utp7YiEDSJ1YLxdruIk85F2cmVanIr3KpNTxU+t5dcBQXg2E6m25nwglNnvIw7gjoDwNEy6lZvoV6n+Va+U46VeseJEQN0jIARR9yqqTQMrXRFbW9UajswzQI8A2ElHELnrpwMA9s39nmGmBal4r7ryWvFTa/l1QBC+zmtUe9s6ehYR8S0aPxId3htAWM1s3LL3HpnflLhRVrGuRMDMQkAIYmbpq2qtrTFBqKBJhThFbgRSaadqLX8mEoRqcwl/lVKQbyLg/2XGm67xGz6lUj1K/fpDQAii/nQyJS2qMUFMMonUegKvtfyZShA0YUlhAAAG00lEQVS5gUStnZFPENPFBJzkcUehqvoKnzIlg1ZeMuUICEFMOeT18cIaE8Qkk4i6gZRGoJ+AvWthYqq1/BlOEIUBF4lEAq+tN/anDJ/AhB4C/tYliF9Jz/j6GMnSiloiIARRS3TrWHY1D6nt/hQE/BkmH5lIxJ52nFzlkHqSGc46VDTk7fsMwsvQy3pdm1s+CzZPBWORJj6WEuPqhe3lXVJmZiIgBDEz9VZxq3UhGYjxs0S8T4Xf9vW0dUYvJMYP8pXsTmy6u/le7/VbG9IWjv6cgKMAfoVBTwPGbamhVcO1lq/aoCNUP/kgQqHIQTDoEQZ2seCkzScxVQRhxVbtLl5/A6eD6MfW8OsEPPKXbVtOfObh25XznDyzDAEhiFmmcGt3p9JRLtQR/SkT/nHr+7nIma6UKsLhk3fKYHwNQCpRTvZhplNS8d471P9rLV8X7oN97ILaOnqOIWLlwJZPvFSTHURbeEkrceZYImpn4EAVziQ11Pd1j8Oc2sLRfyXgq5byk3xaPMqRYg2CgBBEgyiynG7oQm0w01I//gmaA2LoQm3YQ2UA2EAmHZ5I9GZDT7s9uRwPytdih1zZN9mgw/M5KGotX0sQPpz9ij29s+nxqr6DaOuMfoUYKqBfjkUL2eg8ZYprC0cXEHC/EITbiJwdvwtBzA49a3tZo2B92ol/fldk34BJynkr7wuhJkhPOQdUOI+x8V1X2HYgk0J11Fq+Q0gRT+FCnBzXakEQGqfFdw02jovHV6l0qa5PEcEATxi8ZUE8fr/KSSHPLENACGKWKdzeXV24byY8NN7CJ5cT7ptAK5qD68/XBZXThuMmviQ5GPu3Ep681NYRiRLRzRbb+Jhup1Nr+ZrJU+VZODUx2He30zBqb4/8FQLUC+AIe5laEISO9AE8R2b62ERitfKYdnx0Ib+JcWUi3nfZLP9MZm33hSBmreonOu6cMIhfIAPnJQZij9sn746OyAEZohUEHGqDr+REFAqduKtpND1MwN9Z6mUYuMEcG/+GPcS4atuWNP0zAZd7SRhUa/k6cxqAjWBevtee6LV6IKtD31ffwGEG4RqA/kY3zGpBEOo9oc7oKcxQXtSF8w6AXzAZ539kTzym8ZSmUFfkUDaNnwK8n6Wt2tDts/yTmVXdF4KYVerWd7ZKKUc3gHhBcjC2thSkJVKCphn4HYFUytIMiD8FxkHWGzU5uSVJqJby9aauQm9VvuzHCPQuwB8GoQuMnS1YPAfQEMBn5f9WK4Job49sAwMrQbSwSBeEt4nxFIOy2fuyqV0Jn7W1Vf2kdOC2u5Ovp8EREIJocAV77d5EPKPAnQB1eq2ztRy/ACNwslOeaLu89q4ln4HJd9lWq66vVddnYdAJ+YNppwq1lJ/D6S7rbSq3hufbDeYF1gPkWhGEas/B3ZHdg2msBKjbrX2a39MEfHt0ZO73JOprGeg1UBUhiAZSZqVdmVh50nkgKJvzXA/yNhPw/eYg/6i/P+bplkxeZmvrsh0CwfErmHCuizevqpImxopMuulyr/GBainfh+xsvu1MEy9/sj/2lv0Mo5YEoUBT+uQAfTOXh2MbD/pURZ4lgy/QmRY91pdiDYSAEEQDKbNaXZk4lzCOAVglAVLpSHfP2bMzAN4CkAAo1hI01/glBnsb588/cedgc9MyBveA6ACLqWMEzC984KP2QDoQ+NmTA6teK6d/tZR/cNeSvQMmn01g5YW8T84cplKgvgLCIyb4x8ODsefzZzhTTRB5vGz6VH4ke1pIeTPArwLGozDMm/baDc9JNNdyRlpj1hGCaEy9Sq8EAUFAEKgYASGIiiEUAYKAICAINCYCQhCNqVfplSAgCAgCFSMgBFExhCJAEBAEBIHGREAIojH1Kr0SBAQBQaBiBIQgKoZQBAgCgoAg0JgICEE0pl6lV4KAICAIVIyAEETFEIoAQUAQEAQaEwEhiMbUq/RKEBAEBIGKERCCqBhCESAICAKCQGMiIATRmHqVXgkCgoAgUDECQhAVQygCBAFBQBBoTASEIBpTr9IrQUAQEAQqRkAIomIIRYAgIAgIAo2JgBBEY+pVeiUICAKCQMUICEFUDKEIEAQEAUGgMREQgmhMvUqvBAFBQBCoGAEhiIohFAGCgCAgCDQmAkIQjalX6ZUgIAgIAhUjIARRMYQiQBAQBASBxkRACKIx9Sq9EgQEAUGgYgSEICqGUAQIAoKAINCYCAhBNKZepVeCgCAgCFSMgBBExRCKAEFAEBAEGhMBIYjG1Kv0ShAQBASBihEQgqgYQhEgCAgCgkBjIiAE0Zh6lV4JAoKAIFAxAkIQFUMoAgQBQUAQaEwE/j/HPA4l32L2BwAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-8"><g><path d="M 421 51 L 474.63 51" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 479.88 51 L 472.88 54.5 L 474.63 51 L 472.88 47.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-56"><g><path d="M 371 101 L 371 144.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 149.88 L 367.5 142.88 L 371 144.63 L 374.5 142.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-3"><g><rect x="321" y="1" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 51px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">MP1 hands off control to OS</div></div></div></foreignObject><image x="322" y="37" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXt8XFW1/3edmTStKK2iQHmo+LgqPi7XSptkkhIpTwUqrZO0QKHIVUBquSCICgreK+Bb4YIoyqO8mmRsecgFKVhjk0kmhf5EfhXRq4IChVb4tVBoHjNz1q97HunJmX1mzpnnmWSdv/LJ7Mfa37XP/p699lprE+QRBAQBQUAQEAQ0CJCgIggIAoKAICAI6BAQgpB5IQgIAoKAIKBFQAhCJoYgIAgIAoKAEITMAUFAEBAEBAH3CMgOwj1WUlIQEAQEgSmFgBDElFK3DFYQEAQEAfcICEG4x0pKCgKCgCAwpRAQgphS6pbBCgKCgCDgHoG6JIjmto5bwThDN0xmOi0W7b7TPQTOJZvmd36ATP41gNm2UttN8NFD/ZFN9trt7eE3jsbpXhCOLEGGrQy8AsZGw8BDidH4gxs33v1yCe05Vg2FlrSZZN4PYG8QVg329SyvRD/ZNtvaFs1OcLAPwLsz/3PEspJyTNW257WG5xighwG8OYPBX4OUaOvrW/vCVMXE7bhDofD7TIP+AyaOA+FgAIFM3a0AngPoisH+bvUupZ7m5vAMGDgZhPMA+jCAN2V+GgbwIkDrG4OjF/X23rPDrQzVLjfpCAJApDG47ZTe3t5EqWA2hzrPBvFPNO1UmiDsXSaIaE2c6OJHN3Q9W+q4svXnHBWeOW0E9wDUnvqfEES5oPVtO0IQ3lUzZ87nGhpn7LiEgcsBBB1aSDLTibFo94Pq98zHZQ+ADzn1SMDDr72h8eQn1t3+unepqlNj0hEEA88GkWzv71/zt1IgbG9fPn008XoEoBN8QBBZEbYT8bKBvsj/lDI2VVdN+mkzXrkO4M+NtyUEUSqsvq8vBOFdRU2hjnOIcJ1lx5DTCAEvweSjBwYij7e0nLyvaTSsI+Bf8/VGjJ8PRHs+612i6tWYdAShoCuHmSmPeUl1Ue0dhHVGbAPxiYN9kY0lTBNqbgtfBKarJ0x6IYgSIK2PqkIQ3vQ0p33pW6clEr8G6CO2mspCsQWgBMBqV/GaGQ8cOTS0equj5YHwMpheSe/WeSYDV8b6en7oTaLqlp6UBAHQXY3BrWeUYmbKY17yThCM9Y0NvLC3N/KaG/W2t39q1thY40GmwSsJONO+rWUgZo7FTyjyXIKaWzs+D+C7AGZMkEcIwo166rqMEIQ39WnwAjPu4ETDeUNDd76qa01zRroNhNMH+3rWqe9XbxLUtvRkIYidABoBTMvA+XTS4AUbN0SeLgbe1OFSAGsAOj5TPw7AsHxte9tBeCQIq8zN85e0wDTvBrCv5f9JZqyIRXt05yOOQ87YUi9l4DLtdlkIopjpUld1hCC8qaupteNEAu7L1ipkwtY5qRDjqoFoz6XeevZH6UlBEOqLmhhjIMzPwJokotMG+rq7ioG5paXzQ2ykvJeyi7JaoNVBbtbzo2oEoeRvaetYzIzbJ3zxeySd5ubwWxCgnwL4tCMmQhDFTJe6qiME4U1ddoIA8FuDR06MRu9TH6U5j44gmGlxLNq91lvP/ig9KQgCjPUAHgSlzCaZp3gzU3Nrx3lA6lBKPduZ8VUiXFUrgtDsaJRcL7BBC2Ibuv9YYCpRc2vnJwG+GcDbbGXHLLsu8WLyxztZUSmEILzBm0MQBT7MtAQBnBTr7/mlt579UXryEITBXwHTPZaYhaLMTLmLMT9oMq4yiNQ2syY7CDVVdGciXGDizWsLH2ow3ai87mwmpSQIP2PGi7snwBV7OFXiIPzxWlZOCiEIb9gKQXjDyxelcw6BGOvHGgKd0xKJWyxuqUWZmTTmpRUmOGYLLqqqiUmBrtnq5vXW0gSkZXW3E6AVg/3dtze1dVxMjG/7iSBSciNwGkwsBdH7LWY1FYy0noGbD57Nv4lEIskiJiM1tS95BxLJRQboOAYOBbC/hTxVm4o0n2Tm7mQ8cY8bRwDNV+OE4LO5c0/ex5gWPINApwD4F0vA1FaA/w+DbogPz/rVpk03qrMuz0+q/4RxPGCeCaK5YOyTaeQ5EO43TP5RNBr5k/pfsQQRDocDz23FoTCNswA+BsA7LbrZCfA/AOMRBq0+eHbysSL143ns2QqHz19ycJCTS8DUacNYBaU9A9A6GOZNB+2HJ/PJlue9ySebCpid40H4ugkOnTQ7COUlNBo3TrUGtjFwS6y/5ywvngM289I2MmlB0jAbfUkQhEtifT3f0U1MzURXB9v3JAPGBdlgu6a2ji/5hSBmBPGnkQRdSYDysHIKRsoMlZ8i0zh9YKD7UZcvJbXM72hjk78P0Mdc1lHFEsS4IZlouMzJY0UVciKIXbve+tK06TvOB+HrFlJw6v6fAH1msL9bxbi48nRJLdovUMfune01GvOhtZ8EmH4I07zcDOBQr5HUzW3hI8CkTK6OQV8TB8VPkYHzBjZEfuN2LB50MqFoZpf8AwBH5YtTsFTaTAaf7ySbEMRETUwqghgxjYMnpMYg/AUJbh8cjDzvZgLqzEtIYrHmpfLHDiKPiWniRNe/sH4hCBA+A+YvAzTPjZ4yZXYy0/JCh3+pgMA37LgKjAtcLiA5IjDwe8NMLBwYWPt3nXw6gkAyeQICgW8AUAu42yfB4Eti/RHlG5+XJFSfIwm6loDT3Y5LBWYlwats5tJ8qTaoKRTuIKJbclyiC48oScA3R4dnXVnszqhAF+psbRnAiriyKSwKS5UukSDgG6PDs75tl00IYhITBLBXwhb9nGTmRbFoZNxNLd8M0pmXBvt7rtdsy6tPEPavfeB1k/m4oWikP88O4hZm3HzwAbxGt632CUEo77OdFrOIGs4wCI+D6f+CWLkvh8A4xL4QMvBnBI1jY71dzzjoVR8QqAqngpb4T4CxOVVX9cM8D6D36HYwanGd1rDtXF1sjYYgngf4CYub9MQxAQEGf4yAD2r6Kmh+0EbB7wFgGwPrCfQqgQ/h9PnT+AJKhPuYU95+szJVHAmiuS08F0zqcNXqYq2qKXPfAED/TEOZ20+m7TFmPj0WjXS7XbldlnPWK5Bg4A8EegxAEsQfBuMwDcElCXTj6PDM860koWKQRhONlwB4S1oWfgeAYy1ybWHgIQJZzIHmMGCkYooY3EDp8gdY6jwEkPXjYpiD9KM889YlDJUvNql2ECoQzX6Y68XMpDMvDQx0b641QWRyJj2w247aMj4lPO6OdFPJJwRhFW0niP8LCVw3OBhRtuPxJ21KwCq7iUh9CQ709+w5aLfWyU1Mp5azv5lsnvP2A7BeR5rz5p26t9GQ+ArAF9kW75S5Uc0HO5YFEjTuJODKaUG+3h4oqezmDaZ5EwNHT2iT6LrBvu6VTruIlraO05hxq40wtwB81kGz8bB1XKnYlzfs6GTGtRYnC2t3WoLIpJq5E6BF2cKKkMkwlgxu6HrcLluKtKZvPx1Eavdj+aLngbHp+MSmRyLpCOIyPE2h8ElEpFzYrYGeCYC+Z8aDV9vNgSnLQBArwPQ1224jyeAvxfojykSlfeSQugwKq3YTukPqbKRyTooMlwupxrx0f2Nwr3Bv760jtSYIfS6Y4t14s/ryGUEUTCHS0rLoHWwEH0D6cDn9OLsdUnNb57VgXmGZn/9AkhcMDkb+UmDOUlNb+Axi+rl1EXZK4ZKHILbBME4e3NA14NSfIv/GEYpMIIk8c9Yhz8+TSPLCfOPKsxvQEoQm1YwjQVrH1hQKdxLRbRb36TEGPhnr73mkHOuEw/hd5Shrnr/k32DyLwB+l0WWLQYnj4lG1/xBJ58QRDm0VuU28hGEJsmeKzNTjnmJ6ZzBaLcKLNN5flTFxJQ6hNyC5SD6b9vX0rDJvHAoGlFpm4t+fEQQrk0Rtl2eGvvTZjAxf6h37XNWIBxy6KxQJkM3gLW2nvLmJOIPWs9FmHBprK9HxcNMeBwIwnW0e3Nr+DiA7rUsqjvIpGN0h/AtbZ1LmPkOC3G9arBxQjTapVKo5300i7cqryeIUOfxRKzMS+mU1i4DM3UxO+WMJNaMP0mE5QN9PQqTgs+E9PbZ0oQfDfb1XKjbsQlBFITUfwXyEYSSNidmoMCWXdWxLZYTgtCquYNQBLcrMfz2IHAUw/wCkHL1nPAos1l8eNbZpR7++Ycg3JshWlo6D2eDVU6brA1dS9YqcpwC9HkGPgrgMBCSAU4e6yXLb848c4g01xKEy52rUmxr6+J3JRDoJaTuGMisx7nBVe3t7cHRxL53AQjvmRDud5IOAZd6grClmAB4KICG4/v779peaEVoauv4KjGUiUzdkfA4g+8tR6CYPsMyP6gcSewmyTwy5u4s8+hKCKKQtn34eyGC0GyPN5vxwFEq06JuOLkvOI+bl1T5kgmivBg+SWbiE04eNV668gtBePnC1HiZOH5te8FCV7YkgvBwL4l2t6LxUGtuDh+IIPWCoQ7S00Ti8YKsplDnqUSpHUj20RKEhogr7ZVUUF1aIvU4/tT7HAq3GkS/2p2wcq9Mp45mMCGIgmrxX4FCBKH50hgDeOFgf0RNipwnhwAs5iU/EYRyt6Qkf9qFDd2V0vxCEF5y1ejcEAtFlLsCQ1OoFIJwMke5+0BJ+bjmpGfQLGxu062Md9vSEj4MBj3MwFsz/9QShNYxIk1JT4FwMwcCkVhvl/LMcRWzUawOrPWa7GYv9+lmJnSvMz+yQ0yREEQ5NFflNgoRhBLHi5nJulDqsjX6YAexA4wrYfL1HrbSBbXiG4LwkKumwgRBodCS2WyYRzLjVABHTDj78WBiYsKFbnP9u83f0xTqXETEa7KKVV5FHA/Md9oZaz+G5i3djxqSGygd0a0eRzdXB2+pPc2mXIWxjoHV8em8oZyeSjrZc9PN8BNjweCCTb2rXyo42S0FtKY6B90KQXhB1idl3RCEWzOT5uXMubK0ygSRuYiEnwPjEQOBX46M7P37Us8bdKrzCUEU9Pu3yl4OglA635UwDggQHwrwe5npowQcDkD5vDtHcXshCA+k55og7LEwLg+OrfgVSgtiLZtOD//KNZy+dTB7/7LTKpDM7C5WJSjQVc6rcbMd5szXIsafbcvt7lAIwieLvhcx3BCEzsykc7ezL/46m27JBFHCRPaCi9eyU4ggaF5b+APEdBERTrIF5bmHbYoRhALGQzoPO46bieiyA/c37y9XXqaKEoTDOyoE4f718E1JNwShMzMxcG2sv+d860AKmZdUWSGI8qleswOo6A5CBaMFkuYPifApF1/B1oFuSwUJW1OkT0GCyAKidhMNM3YcR4CKMlYpUQrky0rVTDJw2/Qgr3R7m2K+mVZRgnBwKhCCKN+7X7WW3BJErplpos3SjXlJCKK8aq0mQTgERukGpLKq/pVA/SZTb7zBeFTZtd2aIdyaiJyQdFu/HAukFxOTs7zLp48kdrUSYTEYJwA4KN8sIdAN04JbV5ZyBbBqvxzjFxOTt/d50qXasA6/kJnJtjNwTA8uOwhvkypf6WoRRMYL5x6A1E2A1ud5Bu4AjF/Fg7R5U+/ql508cXxHEDmxCc4HzE460LjU5kvW50rxaa8g8+O7U35/JudgP92CqyjsQp2V75B6+XRbzjaoXFsD0Z7P2mWQHUQhrfjwd7c7CCW6JjfTuJnJ9kXieMGQEET5JkG1CEIXcasuSUKCL3TrCeY3gnAbJJhPW5pYgpIJwtqfymVFwfj1RDjN+n8vXl1O8je1dhy125lApUNP3T1PwEsw+eiBgYjKDeX6mZfryQUn+YQgXMPqn4JeCEJjZkpFhAaD8fhonO4F4cj0yJwjUoUgyqf7ahCEzo1R3VtujsVPcHMBkBptKHTSm0yarlJNKFfXzBTR37jn1kTkhKLb+rqFDbaYnUKayiS6U/cjZ72ScggiE3Gt0n8sUJYdBvZl5lOcMgfb+0ztKJLJB8Apz7C82BWS1/q7BMp5Qas8ZSe1iUlBpDEzpdJkgzBsuTgl7+1zQhDlmWyqlWoQhENkco6DQr5RaVK/O97Z7XaBL5Ug1FdMU2vHTQScOd6WBw+5NHHutwpgdbNd9skhCO148lxOpRuX292Xl5mlTbXhYfzp9aA9OBbf9wYm/LuFvBzvjZEdhBcN+aSslx2EEtluZlKpHUwDr1huU8t7f7UQRPkUXw2C0EXKOtmYdSNLp8h+5XZmVtdX7nlq7MWUmsu5if1cJ6vTJqpzCJRrCXVcyYSvZgfvZQfmQDDaRIdeZ1ZlkvU5p1cXgvCqIR+U90oQmqA5dYesejL3yOZPeCYEUT6lV4MgPnLMsr3euGv0bmsKbReXC6UGmb47gH4AhjqwnBAcxow7YtEedYPbhPQSVdxBpOUzsBpECy1aUZcEnZovpXZzc/g9CKQyxu5JlZ5uwCEXU7iZjVS+or0tDHnj2PDMFYWCNjVZY/NebuVldjmk+3Z1u6CDV5tKyX7c4Iau3+nkEILwoh2flPVKEPoskOODKZgOXAiifIqvBkEoaVtaO65g4PKJkvNjJuGMob7Ik/YRZa4m/SSYr9Zl0E2VdzBnVJMgUiSmv+lNe9lSOtBNXUhEN9luOctCoM/FpN9Fpe41NwN88cYNkaftGCryogCtzOC+5zIf5nthYqlb54BCs83pwiCn+8PTchlnMvhb9guDQPyVwb7I95w82YQgCmnDh797JYjUSxXqPBvEP8kZjou0zEIQ5ZsE1SKIzBfzrwG83SZ9EoxnmRBT13KmdglsfhSUSqtuvaEsCXWlKfBuyz0NvzV45MRo9L6d1jarTRApAmzrWMyM2zVXaaob7GIMehrgt4Ewv0DkuKMXUyi0+IMmBVRqdev1map7txiqsgUvgipidpXjylF1pFNwRyQEUYR2al2lGILQmJkyH4W4Jdbfc1a+rJRCEOXTeLUIQkmcSW6nrub0eqn9Tia6FEDUYH7IkvlUezlRLQgidWCdvvXuxxqScFKYOq/oYuZDLNfX5nVzzbiW3qm5l9rNpNhCBi8b2BBZ76awxzLU0tp5rmZX4KYZdW/19+PDs75W0Fxmjz0pcChe6lxwI3w1y0x6L6YsmA5mpoLmJVVfCKJ8U7KaBJExxxwBxk8czUYTh6YWjtuThnG5SjanOezWzpdSF4VS6qu7uolJeTY1FdBSivTijeZt04Zp7R737sLBdk3tS95JieQtALW5TFeSIKI1caKLK5G0zzrO9F3ldKP6HnAjmzpsD7DxhWi06zE3s1p2EG5Q8lmZYnYQWjOTC/OSEER5lV9tglDSW/IILVPWGQD7WxaTrQQ8wczdyXjiHlucRM7tY0TUPbpr5jLrl2cpC7ySr9T66pzh2RepiRjnAZhvGd8wmJ9iwh3mWGKVGlspqTZSea3MZJiAxQAp09t+ltmRTVfSnYwHur2kIC/DDKO5rZ3vDTKfwYRjkU5lnt01KnPgn4nxUIJo1cb+7v/1coeFEEQZtCNNCAKCgCAgCEw+BOrSxDT51CAjEgQEAUHAfwgIQfhPJyKRICAICAK+QEAIwhdqECEEAUFAEPAfAkIQ/tOJSCQICAKCgC8QEILwhRpECEFAEBAE/IeAEIT/dCISCQKCgCDgCwSEIHyhBhFCEBAEBAH/ISAE4T+diESCgCAgCPgCASEIX6hBhBAEBAFBwH8ICEH4TycikSAgCAgCvkBACMIXahAhBAFBQBDwHwJCEP7TiUgkCAgCgoAvEBCC8IUaRAhBQBAQBPyHgBCE/3QiEgkCgoAg4AsEhCB8oQYRQhAQBAQB/yEgBOE/nYhEgoAgIAj4AgEhCF+oQYQQBAQBQcB/CAhB+E8nIpEgIAgIAr5AQAjCF2oQIQQBQUAQ8B8CQhD+04lIJAgIAoKALxAQgvCFGkSIWiHQ3NZxKxhnjPdPWDXY17O8VvJMpn7nzPlcw/Tpr8xhQpjBR4DwTjD2sWD9MphfBIxHGHz/9OAb+nt7bx0pNwbhcDjwjxdwWIBpEROOzZED2MnAC2BsNAw8lBwLPDw0tHprueWox/aEIOpRazWSubk5PAMGzgJhbLA/cmONxChrt9UkiMmIn04ZbW2LZsc5+EUCzgIwy4PChgG6K2mYV27cEHnaQz1t0T1409cBvM1De0kAMYbxxVh/10YA7KHupCoqBDGp1FmZwagvsOdfNE5gNr8F0PuZcEmsr+c7lemtuq1WgyAmM35WbaUW5CBWgOlrAN5UgiYTDPx4epAv7e2NvFZMOy0tnYezYd6m5msx9TN1kiDcYY41rBwauvPVEtqp26pCEHWruuoJ3tzWcQMY52R7FILwhv1kxi+LxOHt4f0bEnQbA0fnQScBYAtACYDV2rM/gBl5ym9mgzpiG7r/6AXxptaOowi4E8C+XurlKfsIktw5OBj5f2Vqr26aEYKoG1XVTlD7V7YQhDddTGb8FBItLYveYRrBewn4Vw0yz4P4GsMM3BmNdr1gN9fMaV/61oZk4gRiXOLwtb/FYGNhNNr1mBvUlSxsBB8AcKit/I7dZw+3Arx6LBD826be1S9nZWlvXz59V2L47UHgKIb5BZ0cDNwSH5519qZNN8bdyDFZyghBTBZNVnAck3mBq4aJaTLjN+eo8MzGEYpodg7bibBydNesbjeLqjLDPfeC2n3QTQAOsE3nJ8lMfGJgYO3fC0xzam7r+AEY/2Etx4w7ONFwnkszETWFwicS0a0A3mxpZ4yZlsai3Wsr+Kr5rmkhCN+pxH8CTeYFTgii+PmmvJSmzXjlOoA/N7EVHuJgYEmst+sZr60rU1UwgdUAtVvrEvDw6HQOb3ok8opTm3Pnhw8JmPRrAIdkyxBR9+iumcvckJS13Zb54SPZpLsB7L3n//wgklg8OBgZ9jquei0vBFGvmqui3EIQpYE9WfFrCoVPIqKuiecI3JsIYumjvZEXi0XNYVeSZPCXYv2RHzi12xTqPJ6IfwkgkCmzjUxaMDDQvbkIWXS7ke0m+Oih/simItqryypCEHWptuoKPVkXOIWi7CCKm0tqEZ82ggcAarG0sA2Gcdzghq7fFdfqnlqh0OIPmhRYZzM3PZ00eIGTC2xTW8eXiPFtyxf/UAANx/f337W9GHlaWsLNbNCvrLsIZlo8lcxMU54g5s49eZ9AQ/BTRNTJwEcA7JeZTGob+czuF2CdSeaNQ30R5Unh2R862z4InwHR+yyBQsqj4+/E1JeEeVNi5M1DbrfBys88wcE+AO9OycpY39jAC7MugYfPX3JwwOSzCbwIwDszX3jKt1t91W1gwvUH78+xSCSi/pfztLeH3zgap3tBONLVi2ULLssj3+st8zva2MRVAOYBCAJQAUnrC8mk5FDjCnJyCZg6AfyLxZVyXFcwzJsO2g9POo3NPp5KEESp+DlhXonxu9KvplBza/g4gO4FMC37c7mdF3IX/FRPKwb7e67Xya0p/1uDR06MRu/bWcw41QH6tETi1yA6EEwp0xbBvGKgP3J7Me3VY50pSxDz5p26NzXE/4uAzxZwtVN6TQLcx8HAmW7tqulF2vwGAcsyC2Gh+fE8gIsPms09hRY3pwVYdTCSoCsJ+HzhPvkpMo3TBwa6H7ULVuoCp5MvGY93BBobvgzGBRYTgLXrMQY+GevvecQuz7y28KEGkzItHOVQ115lMxl8/sCGyG8KkXo9EEQlx19oUuo/INqDo4n9VgF8iuX3vF/3xfSTIkTTfAjAB/bU54Gx6fiE7iyiqa3jAmJYTVClmJiKEXnS1ZmSBJHZOv5C4y1RSMHbGDhVt4hZK2YOuNRXht0bo1D7SQZumx7klfkChHQLMMzkeQgYtwKkvszdPjuZabl9y1x2ggD3Mowogb/svMBrX3xqbu1cBvB1RQReJQj4xujwrG/n25n5nCAqPn63E8VaTncYrCKgG4Nbz+jt7VU747I9Ta0d1xCw0tLgq2TycQMDkcGcD4lQuNWglElorz2/0Y1jwzNXuN2dl03wSdLQlCOI5rbwXDCpgyx7EI2KmlTh/VEwjRL4EAaaNAtTXjtrS1vHYmYocrAHALltX4UQPRBv5FOcPDbsBMHA7wkYBTDXMi93UipdAD0N4kYAIXDKuyN7gJct+seEYRz76IauZ7P/UH7ho/FdK0D03vT/zI8D2b9T/9gI0OPjfbG5cTAaUe6JqSeHwAC1xVcypM0RjGdg4LfpppHO0ZNrOqDmtvBFYLpaI7OKtP0DgZRvfBLEHwbjMB3mBLpxdHjm+U4LRGUIojT8MjBWZfzFrGOZQLT/sZqXwHTOYLT7p8W0l6+Ol74czkWSzLjHDPDF5UjfUe7x+b29KUUQ89oXHWQkgg8C+JBFMY4TKPUlnaTLM37Vyl6efpjvhYmldne35vlL/g2mqb5grOSTJEJXAImL+/rWqkCh8Sft+00du/2tr7HniiHQDdOCW1fqvsg0C7C12X8y0wXxkZk99kVxXtvSjxicVBGm1vGruo52XfWj10PqPPINE/DlA2fz9RYzGrW2Lj4kmTR2WCNV9R4ySAD0PTMevNru054nzUNe75dKEIT9pfeKn6pfrfEXs0BpTDmvm8zHDUUj/cW0l69Oa+vidyUQ6CXg4PFyeRIqNoXCnUR02wTySldUZuLfgfETMxG8X5LxudPUlCKIltaOKxi43EoOYL7soAPw3Tx2f92X3NjuybZwsD+iyCD1ZBKDrQbRQkv76vD04sH+nh/ns4WniSvwC5t5aNhkXjgUjTxsV2WeBfhJJHnh4GDkL07q10aa2g65S13gHOVj/spgNKK8TPIe9re0nLyvaTSss0XmbifiZQN9EfXl6vikSZp/AfC7LIW2GJw8Jhpd84dCY0MFsrl6JYhqjt/dMjGxVEuo42dM+Pfsfxl4Nohke3//mr8V016+OqHQSW8yabra8R8xXi7PfFWxGY0zXrmG07EZ9t3ynq4ILyvnDiLcR6axXhflXe6x1GN7U4Yg5s1bup/RkFQHoONfz27D5/U2+Yk2V61LHPDNWH+PyiRZ0PupuTn8HgRSQT5v3/Mi6HcqDguwI6HkLIqtHecBUHb97PO0GUzMH+pgUR4PAAAL/UlEQVRd+5xuEntd4Bzkc32I2dLWuYSZ77C84GoXtnygr0f9r+ATCi1pM8m8f0KQE+FHg309F9p14ccdRDXHXxBMW4H2dnVAve9dAMKWn/4apESbfYfstW1d+ZS5M/F6BKAT9vzOT4wFgws29a5+SVcnTRI7Lsl8DO7Z+ecXKG2SZe6WHYaVR8uhxTpoI7NlV2Hy2a8KT0Ev9peWgT9zPDA/u1XVHKZtNuOBo7xsZZtzF26tjNoFuMAuwKqiebmHeXmxKBNBRBqD204pdIjpsCB4jWCl5rbOa8G8YnzchL8gwe2DgxHlLTb++I0gqj1+r6+u9mPJw9zz2p8qn6MjwBUhZby/VFp6dZbovJvQCsVPAcbVSJqRqRQ5bYdiyuwgchdwb2HzyhaahKHMG0kQPUZAlBO8RtnNW1tPeXMS8QetJiJiXDUQ7bnUywuhtbdqDv90BOGlP00/FScIJlwa6+tR8Q95Hx0GzHRaLNqtzk5cPxoS1LrR+o0gqj1+14BmCtYTQWREprmtne8NEJ8LhnLL9Zrh9Z/M/IVYNNLjxhLgFU+/l58SBPGRY5bt9cZdo3dbE4q5XbDcKLClJXwYDHqYgbdmyjv69OdrT/v1qLGJ6wjCS4Snpn7lCQI4Kdbfo2zJeR9NuoQX2KAFXlM+jwc5gVTwY+rRBXL5jSCqPf5C+rD/XocEYR0ChUJLZptIHp8JjNV5KeogUR6IP0OCL5xqu4kpQRClLqiFXiKNK15Ri5rqpyXUcSUTvjrep2b7rhlPkplOjEW7lYdWwacGBOHay6U51Hk2iH+yZxD57c1Og9XayjVk6zeCqPb4C04WWwHdxxaAkiKW83805Z552M27XsdgKZ8iDDbMI5lV0B+15o+3mXoxFVOCIDLurRssWR49LaiFJmBTa8eJBNxnKefKRqprNyddgDuC8HSeUgOCcC2fm/EX0kf2dzeLv5sybvtzKuflDKfa4y9mbMWeCRTTl1cvpmL6yNZJuZ1vxaFg+iIYyv3cHss0xsynx6KR7lL6qae6U4MgWsNzDJByF83md3e9YLlRZkUJQnMg53WBt4/Ba30vC5zqy2v7VvkqukBqyHZKEUSZDpPtOiLgJZh89MBAZE/wpJsXx0UZzccd1P0OsWjP6ZU8E1BpPhpM86bcey6cU324GE7dFRGCKIPKKksQnJORspQFuJgFfNIQBJDjSTWlCEIz/mKmvy66uRhHAjd9a/siXBjr6/mhm/qllHFIO+7aXFpK336pOyUIQuMZIiYmazZYoNKH1K53bBXdQdTBGUS1x1/MQtTcHD4QQeoF4z176lcmF1POmRyQs0Ar546RxOtfJGApYMwA+G1M+JYbr7lC49fFN1UqrUghWWrx+5QgiHo6pLa746qbtF57Q+PJT6y7/fXsBJnMO4jyHdLmBlgR4+cD0R6VvXf88dsOotrjL2bRSTsA5GRz/QeSvCBfFL/XvnTBrUCuiUcfO5K7W/Tavyrv1huumLbroc6UIAjdQVcxbq5NrR03E3AMwH/nVLI647ZYf9dQ0/zOD5DJKgp6dkbpRe1QdB4iukVtMhOE3aRQrH1bLS7UkNxA6XsjUg9rTBN+I4hqj7/YRUp7H4SHzAFu+m0KdZxDlIr4Hw9yc7pzIifOySEw0k2/1jIOa8clsb6e73htqx7LTwmCUIqx548B+P7G4F7h3t5bR9woThcMl7W7+iBQzrUJR43VK8FU8wyi2oFifiOIao/fzdzXlUnlHgtgDUDHW37fzjCOVx9NxbabradNPQM4pmvRpSdhxopYtMfiMu1dKgd9TJlb5aYOQeTm9/F0mYjGFjkh1kGTaiMnjXah6am5Ecttqo1JQxBac4FH7xtlAhmL73uDNaEc6jnVRgXHX2hO5vt9Xih8tEGpW+Ws7qBPkpn4xMDA2r8X27bD4bA20DHbh+6OChUvgaBxrNtLvnTyanYxRcc4FYtHLetNGYJwmEC3xIdnnV3oMhHtgoOJqToqkqzP1kd2onjdAdgnmNf61dxBpHZ7FUnWR9cN9nWri2cmJE702w6i2uMvZfFJvReJ/a5l8LnWdlILs0Gf8hr9rto4vD28fzCB1QC1W9tUZ3Gj0znsdEeKug20qbXjPwm4bOKYeIiDgSXFkIT+7pjKHMaXoodK1p0yBJF68XTpvom/MtgX+V4en2pqCoU7iOgWy5fSGDMttd7E5pDuO8HgS2L9EeWS55jR1SndNzMviUUj1gC81FzwusCXmyAK5X0qVT6HdNfa2+/sY3NI9+14yVMtCKIQftUcf6mLi9PXPoDtKlniQQegu9AVuhkZqGV++ONsGj+zpWpXP28D8YmDfZGNeXc0+vteVJV/7r6N98tI8mo3qTJSAXNb0Akidf6RjZ1S7bxqsHFCNNql7oOfEs/UIgj9PQPqms+fmmPxr2/cePfLVq2rvDMjCVLuc+qrpOgLg9SNVsmAcYH11jbVj5qIz24xFhLxf+deT+oc1l/qAuy1vsZ8lvfeCa/t67f24ZOIqMtmvkgQ44ZkouEy3YVBFDDOZPC3bOkS1I1zjh8B1SAIr/gpPJwuDCr3+Muxyjl84GSb/iuYvmuAfqm7cyHtJaRuLDS/BNDHNPIocj95cEPXgBtZM4f8KmvzmzTld4DQxYw18WDg8U29q9X7nvpwa2//1KyxscaDTINPI+A0AAfa6uedR25kq8cyU4oglILyXDnq9hrLvDbWclw5Wmg7XeoC7LV+rutlaqqru4e3AKQW7Q3TGmacmz3w99q+w4tTjis3leUh753E1SAIr/hlv6jLcOVqwfGXa9Fqbg6/BQFSV45+Ok+b43MmXYbfVuCu8c1sUIdXU1VTqHMREd9axD3mTqInC11dWy4c/dbOlCOIFEnobx0rqBu3ttVMRs5V9mtEC3aQuhYRPWPT+dw8ttaqm5hCocUfNCmwLneXkx3RxGjvMhGEapxaWjvP1ewKXEAJRfjfjw/P+lq+M6ZqEIRX/CyDq/j43QDptky+K3TdtpEp57hTdNtOnut13TaRLbcTjP8cG5l1TaGzSq8N10P5KUkQSjHz5p26dyAY/yYT1AFboVunPE/YVC4X5u8y82IX7auvqaeIcNFAX+SBQjlmSl2Ai6hPTW3hM4hJXZ1qT2Cm9ugTrpwsov2874rXi18YiAXY+EI02vVYoZewGgSROkD1gJ9d5kqOvxA+xfyeerca4isZ+CKAWR7aUFf03hykxJXluJ1O3SzXMH37IiJcAdD7Pcihig4DdFfCoG/YTcMe26nr4lOWILJamzv35H2C0xpOZbA6lHofGPtkfhsGq1ul8MtEIPDzYieJIoqAmQwTsDinfeCZ3R/J6xi0+uDZycdcHuZVfQeRxSqzUKnzmCMB7GeZ+RPSH5SbIDL9pC5+CTKfwYRjkQ6Ay9qZdwL4MzEeShCt2tjf/b+FSDYre5UIItWdW/wcVpSKjL+Sq5faUfzjBRwWYFqU0dlBE+ZN+l7oZwj0W2JERkZmbqrQVzo1tS95B8X5WCZW3lEfpXRQq/WcYhjg54iNqEm8dnqQf9PbG3mtkvjUQ9tTniDqQUkioyAgCAgCtUBACKIWqEufgoAgIAjUAQJCEHWgJBFREBAEBIFaICAEUQvUpU9BQBAQBOoAASGIOlCSiCgICAKCQC0QEIKoBerSpyAgCAgCdYCAEEQdKElEFAQEAUGgFggIQdQCdelTEBAEBIE6QEAIog6UJCIKAoKAIFALBIQgaoG69CkICAKCQB0gIARRB0oSEQUBQUAQqAUCQhC1QF36FAQEAUGgDhAQgqgDJYmIgoAgIAjUAgEhiFqgLn0KAoKAIFAHCAhB1IGSRERBQBAQBGqBgBBELVCXPgUBQUAQqAMEhCDqQEkioiAgCAgCtUBACKIWqEufgoAgIAjUAQJCEHWgJBFREBAEBIFaICAEUQvUpU9BQBAQBOoAASGIOlCSiCgICAKCQC0QEIKoBerSpyAgCAgCdYCAEEQdKElEFAQEAUGgFggIQdQCdelTEBAEBIE6QEAIog6UJCIKAoKAIFALBIQgaoG69CkICAKCQB0gIARRB0oSEQUBQUAQqAUCQhC1QF36FAQEAUGgDhD4/9vTzY6FRhb6AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-4"><g><rect x="481" y="21" width="100" height="60" rx="3.6" ry="3.6" fill="#f2cc8f" stroke="#e07a5f" pointer-events="all"/><path d="M 495 21 L 495 81 M 567 21 L 567 81" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 70px; height: 1px; padding-top: 51px; margin-left: 496px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><span style="background-color: rgb(232, 205, 151);"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: center; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;">OS Moves one core out of ACPI C3</span><br /></span></div></div></div></foreignObject><image x="496" y="30" width="70" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAARgAAAC4CAYAAAA45fPWAAAAAXNSR0IArs4c6QAAIABJREFUeF7tXQd4FUXXPioqvYkioCBNekep0qW3CNKlhYRACBAgdD8R6QmEFgiELkUQpApIEUFAkCpFqgiIFOnVDv//ru5ld+7s7uy9d3MNd+Z5vseP3Nkp78y8c86ZM2eeokROl/dNfZTIVcrqJAISgX8ReLlUl6cSE4xErQwdkwSTmMMr65II6BGQBCNnhERAIuAYApJgHINWFiwRkAhIgpFzQCIgEXAMAUkwjkErC5YISAQkwcg5IBGQCDiGgCQYx6CVBUsEJAKSYOQckAhIBBxDQBIMA+3fDx/SmXO/0Iov9tKWb76nM+ev0K07D1y5nk32DGXNnIHKlMhD9auXoLIl81La1CkcGaCLV27Spu1HaPWm/fT9qQt0/eY9XT2ZM6Wj13NloSplC1DNSkUpV46X6Jmnn3akLWyh3T+YS0vW7OLWFTesAzWp86ZP2nHqx8vUIDiGbt2+rysvRfLnaOWM3lS0QHaf1CMLcQYBSTD/4nr3/m80b+k2mvLxRreFbAV9tfKFaHD3ICqQJys99ZR3voSPHj2i3QdO0+CYJXTkxAWrqnW/v5AhNQ2OCKKg2m9Q8ueftfWt3cxmBAPijR/ZiZI94z3ZzVv2NfUdsdCteZJg7I6Yf/IHPMFAYlm1YZ8yiUEy3qS6VYvTqAEt6aUX0npUzK079ylq+EJFYvEm5XntZZo+qhMVzJvNm2JMvzUjGPR/9ewoypEtk1f1//7Hn9Qxajpt3n5EEoxXSPrv44AmmAe//k4DRi+mxau/MR0BSAbPP/ePRHD1+h3686+/DfNnTJ9aWdwV38hna1R/uX6HQvsl0K4Dp219Z5Q5XZqUNH9COL1RLJdPymMLMSMY5PWFmmSkHqF8KcE4Mqw+LzRgCebOvV8pbMBM+nLnUTdQoV60f7cytX+3Er2a9QU3u8b9B7/T13uO0/iZ6+jg0XNu38NOEz8ymOpVKyE0YCCsAaM+ofnLt7vlh/qFdhTJn50yZUxDKBsJkte1G3fpu+/P0ZxPt3H7AQliaXxPpQ++TlYE07hWaZr8UQev1CQj9UgSjK9H07nyApJgjBb0008/Rf27NqROLapSyhTPW6IOe8nRkz9T2MCZdPrsZV1+SBCfxEVQiUKvWZazdfcxatltEj18+PjiN8hh9tgwYTXnp4vXqVO/BIVwtKlV4wo0ZmArrxY6rwMswYD4/vr7IQETpCwvpVeMsNk9VJN++/1P6tA7XjG0I8G2pZYtCcZySv1nMgQcwWCSTpm3kT6auFw3CDgZmhXdmYoXymF7cKBqwYazdO23um9zZX+JlkzpQa9kyWhYJhZlt/dnK6dWasLp0IoZvSnnqy/aagtOmVp1n6wjGRDdypm9KX/urLbKssrMEgxwey5ZMvr2ux9cn8aPCCZIMp6k4z9cpEbBY+n23X9O8GpXKUZbdx2jX3/7Q/m3VJE8QTXxvwk4gjl84idq2nm8a+ICckgLsFfkzfmyxyNgJBW1a1qJhvdtbihBXL1xh+q3j6ZzP19z1T2ib3Pq2LyKR23hSUM4WerWvqZH5Rl9xBJMuVJ56e2KRWjohM9cn3ijJs1a/BUNHLPYRSZDIpvQkNhlkmB8OorOFxZQBMOTFqAWzY4Jo1qVi3qNNmwiTcLG04kfLrrKeu7ZZPTZ9EgqXZRvbD107Dw16jTWtXBwtLtseiSVKZ7Ho/bAttQifBLtP/Kj6/t3ar+hGF29PULXNohHMP/r8Q61jJjs8lnxVE1i1aOq5QpSz051lH5JCcajaeG3jwKKYFixG6j72kbx+ZcHqFPfBJ29oEOzygSphLfAWYKBgXlFQm+PVDV1Fg2KXkKzl3xFULVQJ060oge1cp2E+WK28Qhm5phQivhgru5Y2RM1iR0nYAeC1hKxXRUJRnHYpz5Z9Q1t3nGUfr58wwUD7G1QIYNql1ZUuhczmrsZ8Ei8R8faNCC8kS1oseGFDZhBazYfcH0X3KIqDY9qZlqOWV/Sp02pHAg0b1CO6lYtJmRL5FWGPm7Ydlg5YT18/LzO2RSnqgXzvkJBtUpTnarFKUO6VIbtDSiCiZm2hmKmfy4sXdiaLf9mxglTm55x9M2+U67PzXbyoycvKAvnnsYHxxsVyZM2e/INj2Dmjw+nZeu+1TnGYaKP/+A9W9KTVj1SbUh//PGXRwSDxfj55gP04fjPdKRi1ucGNUrS0F5NKUvmDIbZ2LlUrGAOWhLXndKlTSkMJ9TiBh2iCS4KSFbSLuyHO/aepD7DFtDZC1ct64HhHYcWIC1Rx0vYE0fGraKZi7foDh3MKoM6D3JNkyq5W7aAIRjerlOycE7lpMfXrv6841Wjnfz2nQfULHyizjArYhy2nF0OZzAiGFxv0Lr2w8C9elaUcqokknjqEU7TTp65ZJtgRP2ceO2y8mdipSxPVFt2npjNR+AyMm4lTVuwWQRGXR6Q35yYzqaEiQ/g6BkclUA79p6wXYeRHTNgCIbntCUijtpGmojs1sXuhqjztVdepNEDWyrqTWLdL7LTVyOCSZbsaTfv27njugjbuHjqEXZIVpW0UpGwoQRHTaevvz3u1i3s7LhDhkXxx59/0c59J+nCpccqk/qBmT8TS4T4xs584nkpGxnjzfykoN6VKpJT6Quktf1HzupsgGpfrDYtM9eNfLmyKio75qEZXmVL5KF547vqNuyAIZgvdxxVjnC1yRfeprxFyZNKcMoCFSJVSnf/GviwNA0brztJUsuFvtuiYXlq0aBcol5mtCIbI4JB/9id2Y6axFOPYB+xQzCwbQwas5jmLt2m6wakEtiicOTNkvalKzcJtqu1Ww7qvoGKtnRaTyqS71U3SNh+4uLpioRehHqsErsJGbkTGLlVmG1AN2/fp9FTVtEcpv+VyxZQXDF4cxAkizmo9cWK7FSHItrX4tpxzv98jXoPW+BG4KykHjAEEz9/k3LMqSZPRFqrSaP+jkkRPng2fbZ+j+uTbC9npLVz+yqGV16CcRiexWbXEHDiVaxADuUWd42KRRTCUT17Rdvmq3xmBMMuHlE1iZUKqlcsTLOiQxXjtB2C4R3Vi6gJGLfZS7YqF021C+3tt4pQwugQNzsGFhnsZ5d+uaXACoP64rjuVKlMfkuYtUSKzDgpgyrI2krYfiNvhdL5aGZ0CKVPa2xcRV9w2z1y6Me6vsC7umld95vuINeZn2xxtdvsYELNBCmxbc8puust2jFDvoAhGOivE2atdwFoJWJbzhCLDOyApU+XilbP7GPqa7N9zwkK7T+DbtzSh2Uwqypf7qxUu3JRalq3TKJKOGYEwxP/RdQkVj2CB3LbJm8p3RclGG8dF7Ewx8SvptgZ61ywg9gXTY6gymUK6IaCV5eImsRTr3jSNNoCXyCQnpqsVB1tA3l94dl5YKtq1yteJ43Mi+2ihACxSlt2QjOIc52ashddA4Zg2AVhJVFYAWv1++Q5G2jYpMfewqKEhhvdo6asUo6ZtbuoVX34Xb1D1eW9GoaSkkg5InnMCAbfs+qDyI6oxYwlZFGC4dm/7J7KwfkxKCRWd/3DSM37YushatdrqgsyETWJJVKjU0ZWQkIlRhKI0ZiJSFm8k09R8wFUy6DQWMKmAikR6mxIy2oE1T6gJJikQjDqRIEejbAN0xdsptPnroiseV0e7KSDujXy2A/CqkIrgmEXOkJILE+INPQxYSc5K2qLEgyOyaGeqsnT0BGsxGtEHCwZQU1aODGcqpYvZAghu/kYeTyz5CWqamor5vnasD47PJXeF97tkmBMbCJWC8zqd08lGF65WHzfHjxNy7/Yq9yahsewSIL6NGdsmO07TSJlWxEMqyZZLTyWQLTqEdojSjC9PppPC1fscHWBJSqRviHPtt3HqXn4RJfobyaB2rFf8KQFI/WRJbm33sxPc8eF2d40YBpAWWriYYK7cLi0q01QDetXL0ktG5aj8qVf98hRM2BUJHbiQSxdO6evpW+A6IRk87GTI3Wq5Mrt4kKvv+Jpka7vMEn3Hf6R1mzer5x6mBGOHZ3dTsOsCAZl2VGTtITMkzpECIZn+xGxifD6zTrBKf0xsEvsPniamoTGKrfJkcykNbYfRnl5kgfCbrB2IJExO3T8vELQauI5BUJibhkxiRt+RP0OGxaunSCwmmh41oAhGF9KFFaD6skpklWZZr9DTF+yepdhuE/YD2IGt/bpiZMIwYiqSeyuzgu5KUIwPOnA04ueV67dprrtxui8f40IhnXiNJPWWJ8nIwLk9cWbOaL91sj+iKsUuEsmcsiA08u61UpQy0blqULp1w3nVsAQzIZth6ht5GNjHABfOLEbVatgrCt7OqD3HvxGrSPiCDubmnB5ccGkcEqd0t2d2tN62O9wOhE3bwNFx6/R/WTlgu5J/SIEw1OTeMe4LHnwDIz/BYIxIyt2A+MZtVkiMnOV8AfBYB4Y+QOZzRGoUu2aVFIupLJuGAFDMLzTBU8uqIksRl5duFQ57v02Ip97lcfIMcvXfRUhGJ6axNuxrdQjlPNfIBizkxX2ZIin+uw9dIbeCY1VvGGRzK4G+Itg1MmHKx/TF35Ji1bu1IU2MZucvOsVAUMwvAFz6i4Se5KBQeFNTngX4/Ll5au3CL4IcMn2hZTDu3flqbHTaEKJEgxLtuxpjIh69F8hGDPfEJ5vC2u8Ze1yfULrUZ/O9bkQ+1Ld82bHwoaFaxSILAiy+e7YOVP3CdbzOWAIBiDzblN/OrWH8saRrxJvohn5ObBGUE+PVHltZ082zK4qeNJ3UYKxUpNYycToUqiIBONLIy9PCrVSqdmNRes7w14fsYo0yHN+Sywp2Gw+wNMc74Yt+XwXLVu7my5fve2WXaseBhTB8OLB4Gr+lOEdfWYA5bmpG8WcYY9CMVIiHq8ihMAeTfqLYKzUJK16ZBbWQoRgUBdLrJ4e7bJ310ROAVmnNq3fCjvWRlcDtGPLnnz6egxF5pFZHkg3X+06plxxUUObIj98aNbMiVJ8ngKKYHiu17D4x4/oSI1qehY7VjsAvKM+MwMrz1PT6N6LncnAO+L0dVQ7UQkG7WalAfWYNFmyZ3Sxc8xCbIoSTGI72mnHhXd1QN0wWOJj/Xx448tKuFZSD68Mdc4vX7+HcHqElzDxEmi96iVdYVwxPjgE2XPoDB04claR6LHpij6ch6BUPYbMc1Wv9RkKKIIBAid+uERBoeN0R3F2XgAwWuhG193NIubxJqQvCI/XR5EJbYfE7BAMq7qopycpnn9OF+PFLPqdKMHwVBu7R9UwcDbpHEs//vQ4qJPojXD2bg6M2n0719fF/BFVhXkSN2449w1rIBzAC31o3Gks4dhdTayh3VuPYbOxCTiCAchT52+iDzU3q/E3kAxuzIrchGUXojevCuCZ2He7THCdLKBs7ABYbDUrFRGeSGqbeHFQPI2Na0Y4dgiGpybhVCtNqhSu+1pWbRQlGCcuO1p5IWtxYq8OQFrr1akuBUdNczniiQZDhz0vpF8Cbfz6sKsKO5shL2wFjpTxVlb5Uq+7yuQ5Fdq588QSlNaJNSAJxiy4DkL/4bKWaIhBRFrrOniW2zvSGMiEUSFUr7r542tGsUsw+niRoFdIXeGLi0ZtsbvriUgydgmGlSxUj2aEDEWyWnSiBIOyeHYweKEumBBu+oSMUbgGszgqPKy06hDmEYKGbdI8f2vHzmb0ZpbVKxjoy6qN+6jLoFmWoSd4pCxKZLyQDVpHyYAkGEwKAAMj2hrOO9CILdqtfS1qVLOU4cuOuBsUv2Cz8lYPm0AuU4d3pIZvlxKSQODqj4fX8KQKL0Gqala/HJUrmYdeypTOZZCG6nH1+l3atvsYzVrylRvJoSwYOWdGh/o8LKhdgjF7ZxrttFp0dgjGiLQxrlAVG9Ys5RZwCioE4gXBVqFNogtN+w3r76L9zerSJzv+Rn2BlIvg4O/UedNtM8SNfByJI+aMaF94kjTwwlvrmMe8uEO8DY0NbRGwBAPgReOcat+mvnXngeKzYpSsYrkafQdfg9Y94rjhDkUkCl4ekV3b07LtEgxPTVLrFrklbIdg1A3E25CZolIoiyHPD0nNIxK2gleeUV/UIGSqRIhNin3dE+Uh38h+LRSpmJcg8fxv7FJKWPSl288gF7xUUDBvNuW3azfv0q79p3QvDagftQmqSCP7t3ARUkATDECxG6ndbEHiEhh2FbNo9GbfY+dBqEdEIvM2oS3YfWBQdCJ5QjBGj9mLGFDtEoxKMlHDF9LKDY9fzRTFArv3tJGdPL5Kwl4dQL12It7xSMZI4rbqE8hlWJ9mBHIzexvLyJZoVb76O8ZxZL/mutveAU8wKjiQZiAeI0gUnmC1k7CYB0U0ptw5Mtv5zHAnOXb6Ig2buJz7oL1VBQjOPKRnE+Wo0ZcPrbH1ekIwRmqSlXqEuj0hGHyHQNirNuxTwmCKjit2+X5dGgjF1jUaD94JkLee4570BfNh4pB2BA9qkYQ65n66TXmhE2tCJEHCB4HxVE9JMAyCkGjOnP+F1n/1HX3+5UE69/NV3cSEuAhHIjg9gVg8jZMhMnAQtSGKbtn5vfLmMx4Lg4qmTeojWHAYrFGxMOGN7cRInhAM2sX6doioR94QjIoFDPt4U+izdd8q/9U+vKY+VibykJgotjwyNbsaIFou8qEvB46epfmfbadv9p9S+qJGP1TnZ60qxahVo/KEcB2ebDRavNg6IBHBp6ZcybzU5p2KVKLQa/I2tZ0BlHklAhIB3yAgJRjf4ChLkQhIBDgISIKR00IiIBFwDAFJMI5BKwuWCEgEJMHIOSARkAg4hoAkGMeglQVLBCQCkmDkHJAISAQcQ0ASjGPQyoIlAhIBSTByDkgEJAKOISAJxjFoZcESAYmAJBg5ByQCEgHHEJAE4xi0smCJgETgP0cwl/dNfSSHRSIgEZAI8BCwIqynrGCTBGOFkPxdIhC4CEiCCdyxlz2XCDiOgCQYxyGWFUgEAhcBSTCBO/ay5xIBxxGQBOM4xLICiUDgIiAJJnDHXvZcIuA4ApJgHIdYViARCFwEJMEE7tjLnksEHEdAEozjEMsKJAKBi4AkmMAde9lziYDPELh05SZN+XgTtWhYjtRXK1G4JBifQSwLkggEHgJ43XT6ws00fsY6SpbsGVo5ozcVLZDdBYQkmMCbE7LHEgGfIHDtxl1qGByjPHyIlCL5c5JgfIKsLEQiIBGgK9duU912Y1yvbkqCkZNCIiAR8BkCkmB8BqUsSCIgEWARkAQj54REQCLgGAKSYByDVhYsEZAI+JVg/n74kL77/hx9suob2rzjqMsQhGFJmeJ5yp87KwXVLk2Na5WmFzOmFR6tyXM20LBJy13558V2oZqViir//vOvv2nLzqM0e8lWOnD0LN2680D5+7PJnqHXc2WhpvXKUIsG5ShDulTC9bEZH/z6u9KfhSt26OpAvmwvZ6QKpV+n9955i0oWeY2eefppj+vx9MObt+/Tui0HafkXe+nw8fMuDJ5++inKkS0TVa9QmNo2eYvy5nyZnnrKMp6YWzPU8ucv30HHf7hIwENNav/bvFORShR6TcFdJLETtVypvDR/fDilTPEc7T5wmj6auJz2Hf5RKSp92pRUuWxB6tSiqiXGRm31FRYifTPLc/HKTVq+fg99tn4PnTxzSZm/SNr2tQ6qoMxd0bnErg8Vy1QpnxdqrtX3h46dp0adxtKvv/0hVB4RNSSi1UaZLWcgG9EOxPL55gP04fjPdKRi1poGNUrS0F5NKUvmDJaNNiKYb/adosihH9PZC1cty+j63tvUt0sDSv78s5Z51Qy//f4nzfxkC42asso1Ecw+fu2VFylmcGuFcDxZyMIN+zcj/BHQttlLvqKHD62jmJYtkYcmDW1Pr2Z9QagqOFKNmrqaFq/+Rij/CxlS07A+zahhzVKWi4NHMLOiO9PEWetp6vxN3PqA6eK47lSpTH6334HFyLiVNGvxV0JtLV4oB00c0k5ZyImRQCbvj/2Utu46JlRdntdeplH9WwjNJSuCsKrQ6nu/Egx2swGjFwtPQm1nM6ZPTdNHdaKKb+QzxYAFYO64LgqRDY5ZIrSw1MKrlS9E8SODKW3qFFaY008Xr1OnfgmKRGY3dWlTgwZGNBbeze2Wj/x7D52htpFT6cate7Y+T5cmJSWMDuEuUm1B2/ecoND+M2yXjzKaNyhHI/s1V6RWo8QSDMivbMm8NH7mOsNvShbOSZ/ERbiN38Gj56hj1DSCdGAnQWoAIXZoVtmxDeHRo0e09PPd1Ouj+UKbFNv+fl0aUrf2NU3nkhVBWGFi9b3fCObOvV8pOGo6ff3tcbc+QFTGhIGI/seff9HOfSfpwqUb3HxY9PWqlTDEgQWgUc3StHrTPh25vJIlI5Uv9To992wyOvfzNdq1/xR3QAdHBCkDZpbQzmZdJ7icibR5X34xHb1ZPI8yydF/9AvOR2xqE1SRRvZv4QjJQBVsET6Jbt/9Rx3UJhEcQDJLp/WkIvle5cIAaTSkfwKXvEXKR6FWZM4SDObLX38/JCxIJOBcqUwB5f9v232MLl+9TSP6NqeOzavo2myGBSTKN4vnVubEtZt3advu4zr1Ti3o/e5B1LXt2z4nGfRlyryNirrHS/lyZ6WShf9Rq4+evEDfHTvHxbxd00o0LKqZ4VyyIghvCQab7bQFmwkSPQSKNZsPKGsaCVJl7cpF6YUMaVzVzF++HYv5oFG9QioSJsOgMYtp7tJtunIglUQPakW1qxRzE5Mhcg+KXkJrt+jrtprwLIDaCutWLU5DIptQ9myZdO0AGHHzNlB0/Brd3yF6Lk+INLQBGZGmUT2YRMdOX6TuH8yhIycu6Or6ILIJQZrxZQKG73adSKfPXtYVa9Q+TAhgwKodb79VRJFkWJXx8ImfqGnn8W7kFVT7DQXnzJnS6eqFerxqwz7qO2IhQU3RJiyM4X2bU7Jn3O1SLMGo30Gq+LBXU4VIVBsEMD5/8TqlS5OC0qd9bEsz2gjwbVTn+m52N7QVklnkhx/rpB3UOTsmjGpV/seu56v0xdZD1KFPvBtpYIPr0bEOpUmV3G3OGqnkZnPJaYLRNjLRjLxbdx+jlt0m6cArVjAHzYnpbGpXwWSBQZZVb4wmPDpnRDADuzWi8HY1DfV9ox0EKpbRZOLVZVUP2oiFjEW2dO23rvHAYlwxozflfPVFX81Zipm2hmKmf64rz6p9PByw8yycGE5VyxdylQVSDumXQBu/Puz6m6gaAeJr32eaTqXEt4smR1DlfyURs4mq/oa+RLSvZSlNYIMD3jC8a8lp6vCO1PDtUqbf/3L9DoX2S6BdB067voVNZtGkCK8OA7T9g1TbJGw8nfjhouvP8HoFqdeoWNh0PmCjahs5RUeC2LiXT+9F+XK724yeOIK58G3co27vz6YVX+z1aDFhwo+JX02xMx7r22aTkbfozQhJO3pXb9yhoJBY3Y4/ILwR9ehY222QeXntqDo4wWgZMYlgE1BTn9B61KdzfZ8QDK99sHfAsGx1enP/we/UpmccwTCuJpzmTf6og0vCgF3nndBYl/iLfJGd6lDfsAaWCx55f/zpKjXuNFZxJ1eT0TjxJJgsL6VX7rWw0igPPJxmNQoeq5O07Kg6vLbGjwhWTjh9kbA2wgbO1BUFrJvWfVOoeJykvdtlgm4sQlpWo6G9m7qNxRNHMF8v/eBRg+AYunX7vgssnn5shqTRYhn/wXuWAKJcMylEWy92urABMxS9UU3N6peliR+2c2seOyk8kUDYMnBKsSKhF2EH8jZB5G7Xa6puR2RvsprVwbYN9rE1c6Jc6iLUV4joarJSJ3l14RRn4JjFlm3kEUz96iUofmQnrkrF1sVKcp5IIGwZ1SsWplnRofT8c+InjTwMfv/jT+oYNZ02bz/i+rlquYI0e2yY8CkmNmHgCGlfTbB/rZ4VRSBibXriCCZuWIdH4YNnu/r40gtpafXsKMWgayfhWHHCrPWuT4wWIwug3frYengEgwHt+eHHutMwSAc8wjPrIwzMDTpEE8RwJNgflk2PpDLF89iBhpuXJQC7kxZta951otKmkkVyKgZQLGrYNW7feUDNwifqVBxIeZD27CS2//h2zMBWih+ONvEIxkiyZOvnSWMixnu2nN0HT1OT0FjFuIxkd14Z4cLDIG5YB2pSR0x6Uctl22d0TP/EEUyrxhUeaXVfT5kfVv3m4RNdJwe8m5kAmwUQi3XBpHBKnVJvJDMacPZ7HsHwFhiMmmE2jbT3HvxGrSPiCJNDTbwFZmfRIi9sPO16xetO7EQXpEhdOMWAM9W9fw21Zj4nZuXxdm8e3jyC0TpQ2iFx5F04sRtVq/DYniTSZ9iN6rYfQ5d+uaVk97TPbF1f7jhKrbpPdv05fbpUtHpmH8XR0U6CC0LjkHGKQ56aeET6pBFM8uoVC/+qFf+CW1Sl4VHN7GCn5OUxPW+SsQC+9WZ+mjsuzNTPQtsYEYLhtaVy2QL0ahYxpzS1Pnhmwkiq9U/xRBJgweQtyJnRoabH+3YGhCV7TxcF6mQlRp5nKdsfO5Ieb2dnj0pF+s4eueIbTyQNtq55y75WDNBq8lRNFlXvnzSCSV2uVN67WmOhJ+IpwBfdxUQIwmxCiXzvgTORyBxW8hjZfIQLICJ2t/V01zaqc8O2Q4rjnppwBWDt3L5ux9IibRaZ8CLHnaJtFWmTaB5P57LZhmbXdV9bVvcP5tKSNbtcf+LNJRG87awPs/aKjJu3Ee0cJRgREdDugn0SCIYlQCN1UnQhsfmcJBgeWYlMVEkwRCzB8Ba/JBiDmcKTYHgiqghB2GFoHkH91yWYpEww8I9aEted0qVN6RomSTBiWwFLMLyTNkkwNghGxAaTGBKMryUEselknItnI/LEsCkqFSQlFcmbtno7LrzvvV3wga4i+czIe+rHy8T60/AWTWJIMOwpiq9tHN5O5KRk5GWP03lGeW8kGPaUJnWq5IqDnvbpDG+drxo3AAAZmElEQVTx9uZ7Xxl5eSdyrRpXoHHvt9E1z1tCs/O9yLh5a4Oh4BZVH2kdsuye6qjoiE6UxCAYOP7Vbx+tnGypyRcGP28mqvZb3vG3J8fUPYbMo03bD1OObC9S0fyvUrMGZQm3lEXJ3qo/vON03qIQmahGdfE2A1HHS6v2++J39kTOUwLkzUme6wRLaHaNyrjprXU78beRF0d5fnW0c0JF8oX3JSYnJkXTsAmKlzOOJ/G/Vo3K+2R3ZSeCXf8jnq+PavPyt6OdHZWU5x+CkAvwJrcThwfXDZp1mUDPPPM0wU6UK/tLFNy8ihJEzJuU2I52rIHejp8Yb0PwO8HwrgrY3e0Ru6NJ51jl/oqajDxnE0OCQRtYN3dc8/90ag8qU0LcCxeXHXFPS02+ct5CeayrP26hr5zZW4kUKJLYu0asrwur2uCS5rJpkZRVICiYWj87VkbE4Y0Ew3Ojt3utg3cfzhvfHy3+vM3KrlTBu8xpdFWAJRhcJVg7p69QMDee5Op3gnHisiPvdq/RpHVCgkFdJ364REGh43ROclD/4NAmEqSKF0qhYN5syiL1JmSnisP5n68p3raq5yn+LnrZkTdh2asGTlx2NLrO4A3BoN+82/x2LqbywlLUqVJMCUjm7V0k3maAv3l72dFISuM5HrI35XkbEI9kkc/vBIOQmbwBRgCdBRPCCUxrlIzCNcBrFiETeXFEE0uCQdv+N3YpJSz6Utd83ICFu79ZhDaEOsDlNK0ui0JGD2hJiIviq8QL12B1ixj9WrVxH3UZNMsVXgOEPmNMiM4TmBeuAe1GLJKw1tVN1Q+jcA1GcVa8JRijtuL2eo/gOqa3y2/duU/BUQm0Y+8J17CY3eb3ZOx44Rpw490quBrq4oVrMIuZhA2nQcdoXUA3q42RNyfUftohGJ4HttdGXhCMUcApBNHBYuTFZcWkGhK7TAl6rE0AD6EQETSalxKLYFC3UUCnwvleUfqFNrJ6Pu6KdB8yVxemAWVZDbKvJi7Kad+0EvXr2tBNUoKOPfXjTRQ9TR94y27AKQS0wnUQNoYygjit/+o7ihq+0C28pplE4S3BoM9GwbFgm0K859w5MusgxqLasfck9Rm2wC2Osx3pR3TcjAJOISAWDPS8gFOfrNpJ78d86haN0WwT4V3URRsR82hUvxZuY4awIpgPRvGLzQiGZ/+CER/2LzV4mU8IBh3wRchM7BwJo0KoXnXxkJlOqUjqxDELwwgpBkGnM2VIo8TqUMM5spMOdosFE8OpQJ5sovNROJ9Z+0TCMMKYuWRKD0NJ0xchM63I1RcEA8DM2popYxoljKoa3hQBt3lhRrFpzBkX5tG1CLNB81XITBHyM3MUhQEb4VGxGew/clYXBAvtB+HhVQpV9TYjGJ59CWVAOnvxhX9eCrl45WZbIvrYCBuhkJnqxyAZ7F4rNzwOPiW6UsDg00Z2srwFm5gSjNp2npgq2i+Qy7zYrgSpx6nkafsQUmP+hHDLm71wIeg8YIZbGEyR/iBmMsKmmtmtfEUwaM+m7UeUSHw2ntVwdUMkCqNIn43ygGQQVpYnlYiUi4iN/bs2tAwoZmR6sKoDKmWLhuUV2x4C6SNZGaTRn34jF5kVPeL/XxQa5BOCQSFqXFaEwbx+UyzKPewS/bo0EArE5A+CQb/sPgui7gY88ddqoD353e5THUaiuVHdUBf/N24prd60X6h5CLKN4NTVKxSyPC72JcGgcXbbih0XCxeRAOw8ZSMEBCcT1Gg8saO+9WRVDgJoje7fUjk+F01mKiBbBjZ3REJEeFHELtI+aG9FMLzwsEz5y4ioBRH9ExmcSbYkGO23CFUAHfezdd8q/1UZEXnweFaR/NkpqFZpqlO1uK1TFX8RjNo3SGkbth1WglF9f+qCjkTRr1zZM1OboAq2+yU6cazyQadeunY3LV+/V/cwGtTPfLmyEuwneMzLznGztk64FKzcuI9Wb9zvVr76sNs7dd5QFoPoY2G+Jhi1vfBDwnE+sDhz/orrETr8jnebiubPTrAZgATNjPZWmHvyOwjgzPlflNvRkLq0D6+pDwUiXi9MAFBj7fj0sOuQ9xih+vghNpq6VYu5+m/0CJ7Zw22K7W3LdxQ3b6Py2J/6gNy/7YA6g6c7uO/IeEwwnoAuv5EISASeLAR8ZuR9smCRvZEISAR8gYAkGF+gKMuQCEgEuAhIgpETQyIgEXAMAUkwjkErC5YISAQkwcg5IBGQCDiGgCQYx6CVBUsEJAKSYOQckAhIBBxDQBKMY9DKgiUCEgFJMHIOSAQkAo4hIAnGMWhlwRIBiYAkGDkHJAISAccQ8JpgHGuZLFgiIBF44hGwvOz4xCMgOygRkAg4hoAkGMeglQVLBCQCkmDkHJAISAQcQ8DnBIMg4Y61VhYsEZAIOIqAldHWbuWSYOwiJvNLBJ5gBCTBPMGDK7smEfA3ApJg/D0Csn6JwBOMgCSYJ3hwZdckAv5GQBKMv0dA1i8ReIIRkATzBA+u7JpEwN8ISILx9wjI+iUCTzACkmCe4MGVXZMI+BsBSTCCI/Db73/S2i0HacaiLbrX6PACYuZM6ahKuYI0JLIJpUuTUrBEsWznf76mvP2rPi6Or557Nhl9Nj2SShfNJVaIF7nwCt/RExfo8y8PKC8K4sXNW3ceuErEi385X32RKr6RT3lKtGiB7JZvIfOaw77AabfJ6gPquXNkpiplC1DtKsVsv3DY/YO5ysuJarJ6BtVuG+3kx4uYwBtP7+IVR7ygqCbMuWwvZ6Q3iuZSXgStXLaA6Vveduudt+xr5b34cz9fo4cP//FzVV9Xbd6gnO5lR6uyJcFYIUREp368TB36TKPTZy8b5n7rzfw0d1yYz58UnbX4Kxo4ZrFbvR2aVaYRfZt7/ESoVbfxpOzkuRto5idbCOQqmvBuMd5tbh1U0da7zd4SDK99eV57mUb1b0EVSr8uhJO/CQZPqH6++QCNmrKKzl64Kgq5kg8Lv3+XBpQlcwZb36mZ8cZ0/5GLlE3UKtl5m1sSjAWa127cpSZh4+nEDxdNc+LN4nHvt7EaG1u/Y2F36B1PW7753u27LC+lp5UzelP2bJlslWmVGXWCVDDJmTeDrT7V/Y7H7ONHBBMeYhdJThCMWm+XNjVoYERjS8nKXwRj5+F5Myyx8D+IbELYfETf+UZ5R05coLaRUwhSk52E98TnxHQ2JTVJMBaIQlzsO2KhWy6oBhAbkaAy9A2rT2FtatgZH8u8ew+doXdCY+mPP/9S8uJBc0xGNUGCwWPkvkrYxcIHz6avvz1uWKSqEqptgeiuitHsR5jwU4Z3pPrVS1hKEE4SDNr1fvcg6tr2bdN2+INgQOLo++ipq0yH8YUMqen55551zbcHv/5umL9tk7doaO93hSTIH85doRbdJtFPF6/rysM4FyuQgwq9/gpBTd5/5Cx3k82V/SVaMqUHvZIlI7c9kmAsVic76WBjiR8ZrOj5WGROppFxK2nCrPUucglrXZ3iF2x2kUzJwjnpk7gIn+jfFy7doGZdJ9CZ87+4dQlSSHjbmlxdH4R35dodWrRyJ02Ytc5NncJETRgVQvWqlzCFiiWYFMmfUyQ02HRE0u9//ElXr9+ljV8fphGTV9Dd+7/pPoPd6tOpPahMiTyGxSU2wYBcBoz6hOYv3+7WJhBKaKvq9E7tN5TFy861+w9+p692fU8j41ZxVfc2QRVpZP8WplIbyugYNY227jqmq79900o0qHsQQd3VJmwmQ2KX0fL1e3R/b9e0Eg3v25ySPfO0Wz8kwZjMXgxAm55x9M2+U65cPTrWpgHhjUTmvFd5rt64Q0Ehsa7J89ILaSlhdAiFvz+bQAZIvjL23rn3KwVHTXeTXLJmzkATP2wnbMO4dec+9f5ogWIQ1qaM6VPT8um9KF/uLIaYeEsw2oLRjuCoBNqx94SuvrffKqJgmPz5fyQBNiUmwYCYp8zbSB9NXK5rBggZ8yukZTUhCQTSBex0H4xb6iZJjh7QkrD4jdKKL/ZS2MCZup+tJD0eKWLTXTmzN+XPnVUSjJ1VzyOYmdGhVK+a+W5spw6jvFt2HqVW3eNc0gpONObFdqXB0Uto8epvXJ95a+z96++HNGjMYpq7dJuuKWVL5KHpo0MIxGYnGe3KDWqUVNQlqE285EuCQfk8icxKKkpMgvli6yHq0CdeRwpYqCDASmXy24FcyQvjcEj/BF15ON1cMaO3csrHJp59z4qA1TLYzQ9/HxwRRN3a15QEY2fkeAQzL7YL1axU1E4xtvNi0Xd7fzZhh1GTKjlhYrbrNdX1d2+NvVt3H6OW3SbpJib07vnju3p8IoETqJYRk+jg0XOudmJnXjQ5giqXKZAoBINKeCdwYwa2ItgoeCmxCIZ3cABpdFZMZ6pRsbDt+YIPIBGNiV9NsTPW6b6HJDS0d1M3FevQsfOK+8Ovv/2h5IcKtnBiOFUtX0io/kHRS5TDADXBzhY/spObmiRVJBM4/UUw8D9o0CGaYHRVB39xXHdlZ4M/TIOO0S41Cb97auzl7WLY5ZdN60mw73iToCZ16pugM0o3rlWaJn/Ugaur+1qCQdvhXtAgOIZu3b7v6kqz+mUVtc+fBMMjvoHdGlFE+1pe2fVwCtSkcyz9+NPjI26jDWjZum8Vg76aXs+VhVYk9CKosyKJHS8jn6EngmAglu/Ye1IxNG7fc5yu37znwkjrIFSzUhFLg6jd0wwrsVtksNg87ATUDj52KvjFzF6y1fWZp8Ze9pQKBXqrcqmNgl2nRfgk2n/kR1c7zaQtJwgGRsm67cYozoFWOy1+TwwJhocL/HWWJ0TSixntqaO8uRUzbQ3FTP9c9xPcBUDu2gQVctvuY7Tn0Bnatf8UFS/0Gk0a2p5L/rx6tAcQ+N3IDyxJEwx24AXLtys+G+ypAQ8UiOkdmlVRHMFYC7ma398Ew5Oa2EXP2mcg3qoSjh1CY8VcnAIsmx5JZYobn7TYKX/Op1sVZ73alYspamWpIjkpVcrnuUUkFsGYeecmBsFs232cmodP1El2vjw4OP7DRWoXOZWK5H+ValcprnhYZ86U1ivJiB0wnuQb3KIqDY9q5ja2SZZgRHw2jBYDdozZMZ0pb86X3bL4m2B4vi8sedy4dY8ah4xTXMjVZFfyuH3nATULn0jfff/YTgLHqSVx3Sndv/49dsjE27yJRTD+VpHYnd/XpO7tOIh8j2sEYQNnuUjSzL6WJAnGzGcDDnCwVWTKkIYgju7cd5JgVGMTdM1Fk7oRFpU2fbnjqMtdGqoX/CqwoNWEex+vZnnB9W8ceXZuXZ1ezfr4byKDZJSHlSqMFj07Ue0ae4+evKAY+e5p/EWc8EYWxcIJgmENmWiLmbTgtAQD57h2veJ17gA5smWiNXOifKIeiWLtaT4ciS9ZvUtxPNV6eZudECY5gjFyDoJUEvu/96h00Zxu4iB2+u5D5upONQAyvvl0SnfD05LENvLyjv/6hNajPp3ru80Jnv3EjrF3w7ZD1Dby8WkUKjA7YfF0Uop+5wTB8OwRc8d1oVqV+aeAThMMzyZUvWJhmhUd6vLSFcUrsfKBVH65eps2bj+iOH1q7VloQ77cWWnBhPAnx5MX/hr9Ri7S4Vu/RknlHlDa1CkMcQfjjpi0gqbO36TLY3SMh0yJTTDsEbSZAZlnLLRj7GUXtKd2HF9NdF8TzIkfLlFQ6Did9Gkl5TlNMDyJysh24StcPS1n98HT1CQ0luAyYZTqVi1Oowa0NPWVSlISDG9RwY190aQIypAulSWWIJmug2YpV+DVZOZlmpgEw/N9qVquIM0eG2bo0ckjCVFfBl8vaEvwLTL4sj3fn/pZuSSK435tMttMkM8fBGPkoOYtnt5+z5Nw1TKxGXV5rwb16FDb0l6XpAiGtcDbdQ4CQLCyNwoeS7fvPo5pYjTIiUkwPJ8NK5WH1xdRYy+7mFKnSq7c/YGTnT+SNwQDMR52Nhis53y6jb7cedStC7B1LI3vaWorc5pgeIsWMYR8fUnWF+MnctghciqbpAiGNWx6cuoBSSFswAxas/nxfRkjPTgxCYb1fUmfLhWtntmHe9KlTiBc8OsYNZ02bz/imlNWaoCakV1MCGC0dm5fJXiWP5LIhPa0XaIXLv1BMInhGe4JbrjbBJX9zeK5lTtv127eJWzwvFvcZnaYJEMwPAu8p/orG4LBaHElFsHwVD8j12t2srAemfjdSvJBHva0ygmHQTsT2ymCsRMywmmC4fnA/FdVJN7YQVLcvucE9RuxyC0gFhztcE+PtYMmGYLh+X54eurBGrCMFldiEQzvRIjnfckbdF5ITRFjrzcqiR3iEM3rBMHg+HRor6bCd6qcJhiekTcpEYw6lka31Xl9STIEwzvi81S8ZAfa3wTDShOiag4GnGccFrFN8SSfhRO7UbUKYpfdRIlDNJ+3BIMrIfB9gqcubgWXLZnX8loI2zanCYa9Y4b6/el7JDo2vHwIUNU0bLzOkM67zyQJ5l/0eGSVGBIMz/fFm4FXvzW7WIg8vGNITyVCX7T3vyBROU0wPO/p/7ofjNnYsnZDnleyJBgi5YIX7w5OYhAML+iPLxaslRT0X9tNA4FgeAcMScmTl52XPJUvblgHalLnTVdWSTBE5C8Viafe+IJc1DLMjL28EyhPTuXM2osdu13veMqUIbXlxbtAIBhgxR4wOHEXKTp+DW3acYQa1ihJNSoWoVw5XrIMeO7JvOOZLVg7TJIhGF8aeVlrvpEPiNMSDM+PRRtM3M6g//33Q93bOfjWytjLLmpfT3ae8drI5hAoBGP3fpSdOYC8vBNJp6SkJ4pgeDuupway+P+/LoDgxWoyGgCnCYbVYUWMs0YTjneF3qo8HsEBU9hieAGc7Ux2XtwafG90OhYoBMMbJ4S0XDYtkhAD2dvEhvJAeaw9Dm1YuGIHHfz+HO0//CNd/OUWTRraznYo2EtXblLd9mN0jwKydrwkI8EAqCfJ0Y6303irovCeWDEz9vJUNJHo+yKLgHcXyCywUqAQDLDj2d0iO9WhvmENvIrbAuII6ZegRABQE2+TuffgN2odEacY+tUk6gGuHXueZz0bWiRJEQyvQzPGhNhiXju+CE5KMLxTHKOb0yILGnl4PjEI2r16dhRBSuOl3QdO07tdJrjeXkIeO/e7eGUavVJg5vMRSATDi1nsLbEbvVJgFGDLG9cIjDk2J4RtgCSkJjyvsnpWFOGAQU1JimCcuOxo9uSCUwTDUx984UlrpJaYGXuNXhWoUDofzYwOofRprS+RaknG6FUBuJMvi+9JmTKm4RJdIBEMADB6VWD+hHB6o5j9N8d5rwqYBYLiqVJ2pChefTwpKEkRDAaGF66hWvlCymNonoRrMHs0yimC4fm+WN2cFpVieJKRlbHXKIAXnn+NGdxa+F0k6OTdh8xze18JE312TJhhHBb0LdAIxoiI7bz7DNygFsXN20A4OWKT3bktemdrz3dnqE2PON2FYaOoBEmOYIwCTpktBjyP2XvYAiW4sTZZPXvpFMHwdHBfObnxpDwrYy8wOXD0rBKkW3vLXMXK7GVHLBQE9Jq2YDMtXbub+4ys1WNegUgw6LORKonfzF52VF/TXLZ2N035eKMuyL06ZkZ3g7Tzn6ceg2QQs7pTi6qEE01twn3AmYu/ojFTV7u9W47XIprWfez/kiRVJLXRvgiZCdUIz66WKPSaoXDgBMHwnK2snOJEpRc1H+9ZDCvPXnyLY2VEudOGCGXr1h6j42RP+4IDr50gl7D3alg+xh5oEoyKFe71hA2YpTwDa5TsvAeOMqqULUjxIztaqrcgKjxF/KHmRFVtg/ZtavwNIVa/O3aOu4HgyZXwdjW5Y5zkJBgVAIjjIf1nKIvCboK0M2NMKBXOZx77xAmC4R0Niyx+O33keema2Zq0ZRupOXbqR16IzFNHdKRKb+YXOhkJVIIBVmZqjl3co8LqK++IGz2Py5YHksETOINjlnDJw6x+kNCHvZpSx+ZVDDeQJEsw6sBgt8aLdhgkqwT9tldIPercupqb+Mf71gmC8SYKnVX/1N+NPIRFwjigDFzLx3vcwyYtd4tjbNUGTOweHetQp5ZVDZ+G4ZURyASj4oFTwNiZ65SngR8+fGQFte53hK8cFNGYcufIbOs7NbNR3GqjwvAEDWJg44KjWUrSBKN2DLrh5h1HCc8pfLP/lE5shy5brmRealSzNFWvUEiIWNRyfU0wTj+6pR1o3imBlbGXN1FgkN647TBt+Pow4Yj/6vU7Ov0bKhMcxfD+TsO3S1HRAtk9ckuXBPMYfaieO/eeVF63ANEj2NOtO48jMEJyQAyjN4rmojpVixNeujA74BBlHEgzZ87/QgtX7qS1Xx5QbkqrRIfNGWSCp23x9Avsl7DtWaUngmCsOil/lwhIBPyDgCQY/+Aua5UIBAQCkmACYphlJyUC/kFAEox/cJe1SgQCAgFJMAExzLKTEgH/ICAJxj+4y1olAgGBgCSYgBhm2UmJgH8QkATjH9xlrRKBgEBAEkxADLPspETAPwhIgvEP7rJWiUBAICAJJiCGWXZSIuAfBCTB+Ad3WatEICAQ+M8TTECMguykREAiIISA9fVKoWJkJomAREAi4I6AJBg5KyQCEgHHEJAE4xi0smCJgERAEoycAxIBiYBjCEiCcQxaWbBEQCIgCUbOAYmARMAxBCTBOAatLFgiIBGQBCPngERAIuAYApJgHINWFiwRkAhIgpFzQCIgEXAMAUkwjkErC5YISAT+D0udTC/E19fWAAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-11"><g><path d="M 261 51 L 314.63 51" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 319.88 51 L 312.88 54.5 L 314.63 51 L 312.88 47.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-9"><g><rect x="161" y="1" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 51px; margin-left: 162px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">MP0/MP1 boot process</div></div></div></foreignObject><image x="162" y="37" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmAXFWV9++8qk434kgYRiBARBwGlXGbL5h09ZJpDUsAQ4BQ3R0gJIojqEjEEXH/5BPkY5yRgY9FkC1sSVfJpsgutOnqqupARkBEPmAEJ8gSZFgidrq76p3hVld1Xr2679V7tXS97jrvr6Tr3O137ru/d8899xyCPIKAICAICAKCgAYBElQEAUFAEBAEBAEdAkIQMi8EAUFAEBAEtAgIQcjEEAQEAUFAEBCCkDkgCAgCgoAg4B0B2UF4x0okBQFBQBBoKgSEIJpK3TJYQUAQEAS8IyAE4R0rkRQEBAFBoKkQEIJoKnXLYAUBQUAQ8I5A4AliUVd0gQG6D8CupcPikRBaDk8kbnrN+5CdJdu7ei8k4PQSCcK61FBsja5kd/ex8zIcHgLwtxX2IQvgJYBfByjBwC/awvzg4GD8zxXWp4rRoq7o/zKIPgvGIQD2BRAGkAVjC4EGTYOvnL8np+PxuGq/qsemo7dM5qUjw/GEqlT0VxW0RYUXLPhcS+s73riemfsAvGaCDxlJxDfXroXSmtq7e79GjPOnfnF5F+rZD6m7MQjMcIJA0WJUDYQLelb+zZxM5pcAfWSaCULX7VEGfsITLd8ZGbnxTT/jWtjVd4ABXkdAe7lyDKSZ+OSRofgT5WTdfo909p0C4h9PyvBj4+Hwks2D6/9UniBEf35wb++M9hHRdQDmCEH4QS4YstFoNLTlBVoBwofTidh3gtEr917MdIIAMX6QHI59q1qw27t6DybgF/mXr7i6+u4gXLpOv4dBx6U2bvi1l/F1dEePZKbr9bstxxq2MdOa9PDALV7asMv09PSExzK73wQgmqMH4KJ0Ira2IOe+g4DozyPoke7oQjD9HMDu+SKyg/CIXQDEqL2rfyFg/nvuw20G7cJmPEEAtTEzOZqX1OxqGEHkpvYTZGaOSCZv+YPrV3zpAjIpTngVjI0AvQLwuwEcDOCvbHW9ZjIfVTAL+XmhFi6O7hcy6ZcA9lMmLGY+Nj0c/5lXghD9lUe7o+PYfdkI3wngQIu0EER56AIh0d7d9yVivgBAKP9OOpqsA9FhSydmAUHgTTJ5aTIZT1UKrqt5qRKC8PeFQAt6Vu42x+QDYJpnAlg2NZHyAyKigbG/7LJq8+YrJnRjXLjwmN2MOS132MxK28B8xvj2Xa+zlotEojshjNPApLa4U0TBwKOGOXFoMnnrVj84tndGjyIitfsIMbAljGxPInHz770ThOjPDe9FPcfuY2RCP1XHSiWkLmcQfqZqw2Rn8jnOzCSIya/i3QoaJ+DsZCL2vUpnQKQruhSg2/PmJXVoawJomarP7w7CH0FYu03tndFeIroGwE6WH0ZN5uUjw3F1WF/yRLp6vwjgYqs8EVYlh2I3O2HS0d27ghnKHDXVDhPOSg/F/sUPjsU7L76jNbxzdHDw2u2uBCH68wRx++K+D8Lk2wg4QFNAdhCeUGy8kBBEHXWgs2ET6DIGn7zjvICT4204YvP98Tcq6ApFuvsuAvNp+e3fM2B+HqCeBhBEbr8S6Y5+FUznWXcSDFyTTsTUmNk6xkWLVu5htGTvB/Chwt8ZOCediH3XLmvDRtfO4+ZE6OCRkfUve8Gxq+v4XbOYuKvwdasjGNHfJJJO+nPAWX0oLCOia13Ok4QgvEzSAMgIQdRRCdpDTubPgpQ76pTHUcVmJvsCq15kmrQVntQggoBu0bd7BxX6ZjXx5P/2bNbgJZs2xp8tpxZNO1kiOjE5NLChXFn1u5t7q+sOQvTnCG8kEv1rChuXMvNxNlOjMi8alr8JQXiZpAGQEYKooxJ0BMHAUeqw1XpnoVIzk828NA7wchD1g7G6UQSh2tUcmusWBGrv6r2KgE/vUAHd1Bp+efXg4GDGi1o6OnvPZcI3LbLx1vDW472Ud3NvdSMI0V+pZnJnQwZ9EQTlkTfXJvECEU7nyfsIhfs2QhBeJngAZIQg6qgEF4IYLXZLrcjMVGxeAnImFmNO9vyGE4T9ghJK7wzYTTw5UwbTienhgRu9qqS9s+9wIlbukzkPCwae4onQ4nJmJo17q94EprnomCeIptefVUcli0j+RwLumwjzSW3ZLNkuZDacIHp6ou8cy9BqMJ8Mog/kz7MyAD8DGPeYZF4xMhT/XRlTp+tUVQ4YoZbw0SB8BkTvt5w9qg+gPxDTUBbmVZntu444OXF4fRc+vrh/fpiz/WBSFxHVuU/BiWMUwHMA3QvDvGqfPfBEuQumke7ea4vWELdOMB5obeHlVV6O9TpMX3Iz8pBaLTAT4VDKdrHN9wtTYmIhujg1NHB6pLv3mgAShFq8j0onYmoxzz3qEJNMVi6m8/J/ep1MOjSZHHjI6yyotI5IJLo3wjQIxv7KvdXJNOVE8KK/Yg1pCOKVty/Drd1nHsfUYqS5se97vnudE67ENemA8elIV9+RAF8NQLlOOz3K4SOdBX1mU2LgKT/tq8U6ZJpnE7AqHwWgXPE/AjizgFc5Yevvi7qjBxpMP8q7gE+6oro/j5PBa5Mb4w86kZ8QRDkIa/S70wKjFkq7GcavF47OvJRKxO8uUe70eTFNoaZZMEoWBPvXP4BnzXBm8cjgLc97hV+RJLVkN1o9ZZhpRbmLc1bsdO6thfZFf1OacF3QLfrOEOOybKbl29Zb9IEhCOA6Bj9KIGXuUuFbvDyvEfGq5FBcXUQt+3Qsjn6SzdyFz73KChcLZBm4ri3Mp3v8GqdIV98qgJUHoP1uULmmM8qsPTY693zdzkUIohx8Nfq9zAJTfPvZ31ZNa15SppUAEETJ2YJuEW7v7DuBiG/YAbX/S4M5M8EE3Q7CJwv1eCHacu6tHgmiqfVnfUUiXdG1gPHhjEFnP7Rxwxb76xMgglBxz9qK3LAZz8HAr8A0BpgfBWiBhjy2gnhZaii+yW1p0Llf5+WzICjHi2HVDoH348lwMiULOxPunGjl48t4NWq9BfNtZRj4LYEezsUvI/4wGB+zuZ4r0SyBrhgb3WWtnSQindGTQcbCyfpYlc3/O/f/pwFD7T7yP/PTrS3vuNjqHl6j5bPqamasiUntIDQX3Dxvu53MS0p7jSYI2+3k/CQqtVOW7DL8EWSuXvtZQm762sJl2GeZF/dWLwTR7Prz8/YGiCAs3eaHTcJqeyyv3LlBa8u/gXGizVXb9TJmZHH/P8A077aEE5lchAkbQsicOTR0y4tWzFRso+dfpN63XYEvtJu6lCv8nPDLpzs5W+S9/5S3nvW+UQagfzUnwufZY6A5XTDNRQ8Afy2diCsTlfaRQ2o/M92nrNsOQlVVqZnJbl5i4Mh0IqbuE6DBBEGR7t4fgfFlK1Q6L61qPJCsdfsZryrnxb3VC0E0u/78vApBIwh1eD7WxlGnr/Tc4v0CzgTROUUk4XAZc9KLC+tBtNyCizocPjOViF3qdtDtcNvc8XJpR8cxu5tGy70EfNTSlicz2CSJ8U8Bfp+l7AsGZw8dHr75tzqdCkH4mek+ZT0QRCVmCpt5qTgCqZ8FUxvuu8Kb1PmX5OsgUq6O1sMy7QT000832P3W48W91QdBNK3+/LwKASMIT/HBbOHJC8PVXsbs6IhG2CC1e3hXQdDjhc+ceCQS3R+hXEyw90zhynw7TKxMpeKKaKaeju6+fuacabbwjqldyprkUMxirnXWTmdnf7dJ5h3WvoLw76mh2Fd0RCYE4Wem+5QtRxAaM8VWMmlJMjnwuFNTNg+cEpOKnwWzWoJQZwDj48Z7YfDRDJwKYO+SfjN/IzUcV4eCRbeo/fSzVgTh1b3VK0E0s/78vAoBIghflyk1C3/urpFyBrGOX3Pvx9et/hxJlIacKTE59/SsaRvLvBUH6FM72ue7kMUKO5G46Md+fqmCYj6DDPekUnHlTVX0CEH4mek+ZcsRhKpOM7lOSyVilzg1Zbt9PG41L+Ummt2H2a8Xk88xuom7beX99LNWBFFCrmXuXYj+3E0xXqdKgAjC18Ktc4Kwh+jX3eepJIx/V9eK92UQGiRg/o5dBJ2aGh64vPB/nYzfu0OqrkWd0S6DcjuenfN1l6wjhTaFILzO8grkPC4wtlwOrl8ENg+hYvNSwAjibmT5hFQq/t866BpBELa8GS+yQUvSGwfUZSjtI/pz1p+f1yEoBMGMG9LDMRWGpmg36zYW+1mZ+uj58ztaj3ns3uvfUuU6OqIfg0H3MfA35RZbt3a0uwPbx53GNbzsHNa1qYsA7eT9JwThZ6b7lPWywPgxU9i/gHVfKn4W3hqkHNUh4unSj59+1moHUbRb8+A1JfqrPqWr0l1gCKKSiL82d2z7bX1Nsq6KFu0c2dhDx9jmaPH5mSpR+oHoZYnSef855Y0RgvCCaIUyXhYYVbVXM5PNvKRNWepn4a0BQagDtJcIeIaJ72My7pi/h/lUuav8upehkq87PzsmP+6tBXWL/iqc+LZigSEID5co7SNu7+pdRsBUEikA/xmmTHfBbbXc734QLOf6Xe53P215XSeEIPyg6lPWxwJjNzOV5CZQobSLg9vpL5Z5VbzDl51rBjqfw3cVr8Vk93MPwo97awUE0XT68zMXAkMQtnAvXsbQ0dH3cTb4XksQwukjCDsZ2WOcedgFO42xZJ1wqEsIwsssqVDGK0FozEwl21Qv5iU/X9QNJ4iSm9T4lcHblw0P/2ybV7j93KT2497qlyCaUX9edRQoE1MFBKE50J1Ggij+CKzFR1VBb5pwGtpIyEIQfma6T1mvBKE1M3GxB4MX89KMIoiuXttXd/HW3QvU2lhMmkXAr3urX4JoRv150U9BJjA7CDExTanNq6VBCMLPTPcp65Mg3MwUdvOSYxY6r4pv+A6iNJqr51AjBTV4jebq1721QoJoKv35eRUCQxA1OKQGbF/1pR86FR9S288i7R5TtTukLr1PQYwrk8Oxf7LrVQjCz0z3KeuHINzMFCXmJZc81jOFIKYzH4Rf99ZKCKLZ9OfnVQgKQTgtgm5j0TiQFJliNB8pWWZalh4euMsPRh85dNXO7/zL2K0MHFIoZ++v3WOKgD/B5EOSyfgjftrS7rwJX0kPxS4QgvCDZJWyfghCZ6YoXIKxmZdcU5TOFIIoPXT3nftY5/2ltaMWuQ/6ONgT/VX5AuSLB4Ug7F//5Ua34ODoLnO24863k+10FGTt9wXkolw5FBv3+4yO5qqDTeNTHR8fnXtCy06vX74jNad79rkZRBCocU5qbUY6+0vu55ZrBQRhP1eZ1frz+uoHhyDgK/+7LSimGq62vGaX8buMYRymC33uhJmXHCray3Q+PnhU2+o8bnxi98uY8NmpvkioDa9TubZyfhcYu5lC5VEIsXGCaZhX57OfoVz+6plEECVhyyevuJ6TTsS+W+a2K0U6o2eB6DyLxp7NGrxk08a4irs/9dh04BhSQKd50V9t3ocAEYTKa6sNgmcfaf7D4jaAenb8po9yUJdgfXBoqy7B+iazUUqwvtrMd8+1+F1gNGamLDPWE2FlPnpj2S+gmUQQufGW5q8eZeZPp4fjMSeS0CVmcSKWStxbCwoW/Xme6q6CgSIIlUSH+dv77IUfOl3oVJGJyaCLir6ygXFmWqnLVugQ7jvD4LPSibiy6zuG9nAK983M/enhuPWCXg5jh3Df25hpTdlMivpw31thGEtTGzf8WmvVKH0/tWbc2syU2tYy60xMeYKwmyksHzDlE4TPNIJwmPCjaqfEWb7IGqXSJfHJ42Y4c7g9XWml7q1VEkRT6c/LKx0wglBdVhnebsiOTfzzpk23vmodg0p4FTbpcuthsfqdgWsmRueeokvRqX53ShjEjNuyIeMMu7lJ5ZzY8oKxnIj/X2l6UrpifHSX05zackoYpEv3muubIryQ8WkG/19bFjuVce4bqaH4vzrmp+7sOwXEP7ZgpAjlmNTGDUkvum+kzKwkCF0grQLIXtJpzjSCyE3g7uhCMP3clo1L/bSNgDSDngVYJZg/WJOm0TEdZKXurdUQRDPqr9wiECCCiANQSX3m5PucAXgzYDw6uUM32wH6gC2fiVo7R8xw9rhy+dJrkXK0XDKjfL9rkXJU+Ym4EpHLB2tWhdgBaAxkPpMdyxxvJ9pyc2I6fp+VBKExMxWw9HRPYCYSRG7r3B09kjmX7H1XH5PHdWtdqXtrNQTRrPpz01lQCIIIx+VyQTPOKCUB/QjUgj0R5pMeGoy/5GVe5iOurrOnEfVQVi26sfE2/nyZfNSFqqijq+/zml2Bh6ag8lb/28To3O847VIKlTjs8Kfa0OWb99KB6ZCZzQRRaqbw6K0wUwlCTZhF3dEDiekqmkzo7vqw2lkQn2zPKWwtVKl7aw0Ioin156SwoBAEA0fNn8d3bnnJ+AIxn6vZjVqHsA3E30cGF/tIxpMr//HF/fNbmH/IzCsAhMvNZYCfJMJXk0PxO/2EIi+8MwbTFeo4zwvpqfcmxMaXhoc3PFy+X5MS+Q+tGzU7fPWzNmio17rrKTdrCcJPvHY7wDOZINRYcrbZF0MHEZlrwLlLQ/vmX7IsGFsINGgafOX8PTntFjXWHqfJj3trtQTRzPrTvfBBIoh0IqZMmbkQ5BPc8kWCuQKg/fNzbBTMTzLhBnM8s65as4kiipCZjRKwAkTvB2O3PD4qCvJzb9+vuJdB6+fPyz7sJQKyy2JKC7v6/i7MvJoJhwE4wEJ+KrbZU8S4J0O0blNi4Gm/JFQgvbBpngXGkaBcUqOptMKVJC2qJzEU6g48QUwHCNKGICAICAKCQCkCQhAyKwQBQUAQEAS0CAhByMQQBAQBQUAQEIKQOSAICAKCgCDgHQHZQXjHSiQFAUFAEGgqBIQgmkrdMlhBQBAQBLwjIAThHSuRFAQEAUGgqRAQgmgqdctgBQFBQBDwjoAQhHesRFIQEAQEgaZCQAiiqdQtgxUEBAFBwDsCQhDesRJJQUAQEASaCgEhiKZStwxWEBAEBAHvCAhBeMdKJAUBQUAQaCoEhCCaSt0yWEFAEBAEvCMgBOEdK5EUBAQBQaCpEBCCaCp1y2AFAUFAEPCOgBCEd6xEUhAQBASBpkJACKKp1C2DFQQEAUHAOwJCEN6xEklBQBAQBJoKASGIplK3DFYQEAQEAe8ICEF4x0okBQFBQBBoKgSEIJpK3TJYQUAQEAS8IyAE4R0rkRQEBAFBoKkQEIJoKnXLYAUBQUAQ8I6AEIR3rERSEBAEBIGmQkAIoqnULYMVBAQBQcA7AkIQ3rESSUFAEBAEmgoBIYimUrcMVhAQBAQB7wgIQXjHSiQFAUFAEGgqBIQgmkrdMlhBQBAQBLwjIAThHatAS/b0RN85NkG3g/DJfEf/M0yZ7qGhW15U/+/sjL7fNOjLMLEUhPkAQgBGwfwkE24wxzPrNm269VUvg+zuPnZehsNDAP42J894oLWFlw8Oxt/qWNzbzSZ+AGARgDCAlwE8wIRL5u/J6Xg8ntW1EY1GQ1teDB1EZK4B4xAA++bLA4RXwfz/CTSQnQgNjIysV3VW/CxY8LmW1tY3PgHCSibutrSl+vYSgCQD10+Mzr178+YrJvw25DoW4GUCHgPhujkhvm1wMP5nv/Ur+QUHR3dpHaNlYJzEwEcA7JGvJzcGAp5g5oHsROY2r3q19qPe9VcyZikz/QgIQUw/5nVp0YkgMpnQ6zCMs0F8xtSCq+9BhoFL28L8rXKLlo4gshMTvaHWlq+DodpR5GN/xhk4Mp2I3W/9IbeYvkAriHKkMkk47k+GiG6eIDrzoY0btpQTtrf1/IvUC+CHAPb2UPaPAJ2aSgz8IkeD5R/qWBz9BJu4BKAPlBfHNhB/HxlcnErFRz3II6fnLH0fjFMA7OShTIYYl2UzLd8eGbnxzXLy9a6/XPvye7AQEIIIlj4q7o2OIELIHmpy6BtM+Kz3innEDGePGxm85XmnMiUEAR5kGMME/roDOaj1NTnehiM23x9/o1Cv6vP2DF1EwEnO5Rx7/gIZvCq5Mf6Al7FFItG/RohuBLDUi7xFJkvAOWOjc891201EItGdKGScw+C1/sdSHnPVn/wYBgAc7HMMit2egkFHpzcO/M6pbL3r99tnkW88AkIQjddBTXqgIYhnGbiLgC9YGsgAvBkwHgVxK0z8IwjvtXeAgPvG2jhqXcytMqUEgW0AWgHMyckxnoOBX+X+vaON01KJ2CWFenImjO0UZ+TMSfZnGwFpBj2b6yfQCcZ+moV3GzOtSQ8P3OIGomtbOfMVNgL0CoPfRUAXgH1s9WUZ/LV0Iv4jXTvKZDVnpzcuBvhzJb8TXiXGf+TGAoQYfBABf6/ZzT1BZuaIZPKWP/hsI2cmBBn/ASDrjhcPjrfhaJ1eXcZQk/prMsmlkmlHQAhi2iGvT4MagrA2lGXGbdmQcYbNLEORxf0fg2leB+BD1gIEumxO+OXTBwcHM/YeawiiIDJKwNf3nseXWM4aqKtrxX7ZrPF6KhX/byXY09MTHs/scRGDP2+r+wVm+tL8vczb7WcVH1/cPz+UNS8gwtE2otgKw1ia2rjh1zpkndviJ03G6e/ZCw9Y21Imr+dfytn2rwDwbkudLxicPXR4+Obf2tqhSHf0q2A6r7hf+vpV2YULj9nNmNPyfwg5M5HVHHdPa5iP05n42rv6ewjmnRazUpaB89rCfL5OfuHi6H5hky63EXCWiE5MDg1ssGNV7/rrM+ul1nojIARRb4SnqX4XgihrInEwLbxJJi9NJuMpzwTB/I3UcPz8cvb6RZ3RQwyi24tt6J7MLBTp6lU7InWGsMP+znw7TKzU2fE7OqIRNuhuAO+yjON+ZLmvQFg6FUW6owvB9HMAu0/9TnRxamjgdOv4FnVFFxig+wDs6qd+ANTeHV1NTJdaF30irEkOxW4oXcB7LyRAtT35aPpiL6N2TnO24zaAenb8xne0hneODg5eu90q395V3/qn6TWQZmqMgBBEjQFtVHVOBMHANROjc08p543T3tP/XmTMewg4oNwi5LCDeDZr8JJNG+PKlOL4qC/6scwe6wA+3iL0X8jyklQq/owH/Ki9q1d9fX/bIjtqMi8fGY6rhdr6UKS77yIwn1b4Y84WHzYOSw9ueK5cW+3dvV8jhiK8wmMfY0n9AFxNRfb+lY6l9KzmI4eu2vmdfxm71bobYOCodCKmCMz1iXRFlwI5Ms6Z/xjYEka2J5G4+feFgvWuv1wf5ffgIiAEEVzd+OqZA0FsJZOWJJMDj3uprGRBJDyDDPekUvE/Wss7EES8Nbz1eJ1Jylq2fXHfB8nkXwKYZ/l70flEub4uWrRyD6Mlq7yhpsxiigjTidjJ1q/7SCS6N8I0CMb+UwRBOCs9FPuXcm2o35WZJmSS6qs6/1BPlpmWpYcH7nL63WkH4NSepo0Sby+dbpnpxPTwgDp0d30W9Ry7j5EJ3QeQOst5hEFPtJB54dBQ/JVCwXrXX66P8ntwERCCCK5ufPVMTxB0U2v45dXlFu1CQ5rFW+uaqiMIJnwrPRRTrqquT3tn3wlEPGVC0X3RlqtD/d7R2XsuE765Q5YfGw+Hl2weXP+nqfF09R5MgHJRnTw8B3wRptrtbM/sfj0BHQA2g/k3HDI2FDyB2jujRxGROiCfPEdwIFS38UzuqHa/CUC0IEeMHySHY9+ylKP2zt7riHBi4W9evJK84JiXqXf9ProiokFCQAgiSNqooi/VfAUWmu3sPOqvTGpTZot/nFqICF9JD8UusHZNSxAeTR4dnb0/KXa71dvEy0HRXrr4v2aCDxlJxDdPEUR37xnEsHoe/crg7cuGh3+mvK6qfuwkpby//vyO1mMeu/f6t/xU3t7d+01inGshu5Jzgo7uvn7mHLFaD7VHGbidwOtawzsP2s8V/PSh3vX76YvIBgcBIYjg6KKqnmgI4nUy6dBkcuAhPxVHunuvBWP1VBnCutRQbE0ZgnjLZF46MhxPuH8tr2kby7wVB+hTli/hi9KJmLo74Ovp6lrxvgxCg4TcrfDcY7fL28fCjBvSwzF158LLpTfX/ui+/AF+GjAe9DWQyZ5/TFm0LAQxEkLL4YnETa8V/pb3fLqDgHaH+tVFx98SY4BDdNv8PcynnG6t68rXu37/mEiJICAgBBEELdSgD7p7EGY4s9jtwpuu2VLTDUrOFjQ7iJKvd13d2l2OjzOBMiRlJ4gSswkxrkwOx/6pBnBP3mguDm1Si2oLdRSFSSn8sbOz/yCTTHXgvJeHxtQu6Q4y6dqxsV0eLOekoOqrd/0e+iwiAUNACCJgCqm0O+ViMXmtt+SgekecpamYQYElCAvZ1JKMvJKdV4w9yGkJQpVzuQ/iVq0K43F1mDLnFmJzOQnXu34PYxeRACEgBBEgZVTTFSEIwOrZM1sJojBHcgu5aa4lYFXRXQ33SeQ5PEm9669mrkvZ6UNACGL6sK5rSzUjiJILU57OIAJnYnLwDqqriYkrNJdVOTGovad/X5rgw2DwajDUeYZbED/Xm+eavtS7/iqHL8XriYAQRD3Rnca67QRBwJ9g8iHJZPwRH93QuTuWHCJXbmKq3SG1xiW36I6CGnM9D6l1l8tqecbhQ2dFoiqmUlvbqwdkKbSKGH26WFtebmE7tV/v+isdt5SrDwJCEPXBddpr1ewgtHcY3DrW1XX8rllM3AWQyuUw+TCdmhoeuNxarlKCUHXYQzpU7Bra2Xc4ESuX3Jzbp44QS91H4dvNtb2rdxkRrgHzSyB6WAX2aw1vvU7dLSlx2dWc10z7RChukCLdvYeCoWJtTYUMUXcoeCK0uNq8Ggr2OtffYPikeSGIWTIHdDZ3As5OJmLf8zpETVwhremoKoKYzotyNhIB8CIbtMQt5LUdKzevrkhn3ykg/rGljK+LePlyhXAd6qLc8wA9wmze19byys2FC4653RKbnwJTROUKYiDZFt66yvMFyO7oGmK6xtLPIr3Wu36v80/kgoeAEETwdFJRj/Rul6Vxfdwq7+jq/R4D/3uHjL58VQQw976IAAAF9ElEQVShCbXh13avDlDDpnkPgA9ObXQ0oTY0YSyUuOewHvlgd3cCpG5Sl+yoOjr6PsRGLmyI9ev8nHQi9l2vdy0ikej+COXCebzHMpYis161N7bLEX+9669oQkuhQCAgBBEINVTfCQe/fBXm+7T0cMz6lattrLNzxd+bFLrX5mOvXUyrIYg6BesbB3h5KhFXUVunHl1bvoL1dfYdS8TrnUJ1qCRBMLAeRMutuwgQL0sNxTeV06pDKPJRhnFEOrFhsFBecykw6yfmUwkBAM9a78jUu/5yOMjvwUVACCK4uvHVM5eLW1sZOMGe6tNaeT6g20+Lzh6A32UM4zBdWs9qCEK1qwv3zcCjhplZ7pQwJ99ffbhvwDGPgi7cd7mESKqt/Je9upR2YAErdQg9p2Xr562mHYexlM3elgv33RntJcqZflxDlzuQ6lYvRKQP+V18+bHe9fuayCIcKASEIAKljso7U+Zmr1Pu43wOZeMnAL/P0rrrF2q1BOGSMEhFGF27zzyO2cNEqDazCP+QGf0lCYPcv9jVQeqPwPhyMbr8sEnhk0eG1v/Gag7KJQx6UWW5o6tsuyltwiCXsbwG5jNh4iZ7nopFi054Vyg8cQ4TVMKksJfdR2dnf7dJ5h22vBavMNMZE9t3ieluSi/qjh5oMNYBdJClDW1o9HrXX/nMlpKNREAIopHo17BtB4IYt5hHVGtTqTzz6TU/qb9kRVeMj+5ymlN4hmoJQnWkRilHR4mwKjkUu9kNyjJtPc9AgkBvAvxuEBaDsZutPtd2ytQ/CsIjYFJEpHKwfhSgBZqUo6NM/M/pofhlDmNxILqc9DaAfwMY+bDurDLhqXOTPUrrctRtveuv4WyXqqYLASGI6UK6zu04eDGtNYHPEPBRj81nQbhg/C9zv+kWu6cWBFEgiTnbSS2IvZp80+W6rL6eVxdyM5QTnjS1kEojqtry86iF+wvpofg6t4PnKupXfVGhMM5MJWIqu5xjIMGcjjPGpQCr29N+H5Wi9Lq2MJ+uS1GqKqt3/X47LPKNR0AIovE6qEkPtKElgKMoy8MUNi5l5uPcF2F+kgx8MbkxrqKRukY7rRVBqIFPmnRILdoqjejeHsDIEOgnY2Hju9bcDx7KWdu60JZvWlucgTQTnzwyFH/CZ/1ex6KArqSNU9/egZwDYK6XfgFQCZ/O1Jnu7OXz+qhb/R77K2IBQUAIIiCKqLYbTgSRT0tJ7V39CwnmWhDUxamCCeVlAA8wcPX8efyg1/DQtSSIwrjVDd3W1jc+AcJKJu4GsK/FDPMyAY8x80B2InPbpk23vloNXqqtlp1eX5qPY6RMMXvmyTMLxhYCDZoGXzl/T057xcTaH1V/uO21RSEYJzOZnQDtYzmIVuag/2LQHSbo6k2JgafLEbJurMV4lbQxCvDzxMZwFuZVme27jniJ5mofww591L7+avQnZacPASGI6cO6ri2VIYi6ti2VCwKCwOxEQAhiluhVCGKWKFKGIQgECAEhiAApo5quCEFUg56UFQQEAR0CQhCzZF4IQcwSRcowBIEAISAEESBlVNMVIYhq0JOygoAgIDuIWTwHhCBmsXJlaIJAgxCQHUSDgK91s0IQtUZU6hMEBAEhiFkyB4QgZokiZRiCQIAQEIIIkDKq6YoQRDXoSVlBQBCQM4hZPAeEIGaxcmVogkCDEJAdRIOAl2YFAUFAEAg6AkIQQdeQ9E8QEAQEgQYhIATRIOClWUFAEBAEgo6AEETQNST9EwQEAUGgQQgIQTQIeGlWEBAEBIGgIyAEEXQNSf8EAUFAEGgQAkIQDQJemhUEBAFBIOgICEEEXUPSP0FAEBAEGoSAEESDgJdmBQFBQBAIOgJCEEHXkPRPEBAEBIEGISAE0SDgpVlBQBAQBIKOgBBE0DUk/RMEBAFBoEEICEE0CHhpVhAQBASBoCMgBBF0DUn/BAFBQBBoEAJCEA0CXpoVBAQBQSDoCAhBBF1D0j9BQBAQBBqEgBBEg4CXZgUBQUAQCDoCQhBB15D0TxAQBASBBiHwPxbskUN/+NYeAAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-27"><g><path d="M 371 251 L 371 294.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 299.88 L 367.5 292.88 L 371 294.63 L 374.5 292.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-13"><g><rect x="321" y="151" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 201px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">OS checks all wake sources</div></div></div></foreignObject><image x="322" y="187" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmcHEXZ//fpmckmoCT8UG4UPF/xeNVA9o6rQCAiJCTMbsKNqCDkB4IoL4KirwgvIh78QARBLiXZHcMhKHKIS3ZnZzYQRUREROUykCAvAYQ9ZrqfH9Uzvenpqe6unp3ZY7b689l/dqqqq771dH2rnnoOgn40AhoBjYBGQCMgQYA0KhoBjYBGQCOgEZAhoAlCy4VGQCOgEdAISBHQBKEFQyOgEdAIaAQ0QWgZ0AhoBDQCGgF1BPQJQh0rXVIjoBHQCMwoBDRBzKjp1oPVCGgENALqCGiCUMdKl9QIaAQ0AjMKAU0QM2q69WA1AhoBjYA6AjOWIBobV+5kxPOfAtHBAOYD2BVAvAhdHsBGAv7CTGs5QXdle9c8BYDVoVUruWDBYTvEGxKLmXEogEZPP0wAzwP8FBj3GojdPjy83R82bLgqp9b61C3V0ZF800iObgPhE04vGTg0299z+9Tt9eT3rKm988vEuGisJ4TrM309x01+z+qjB83tndeBcWwYvu3ty3bJc7wPwDvrWX5nFEEkk8nYP5/HQRbTuQTsCyCmLtb8GDO+nhve/uZqLNCN7cm9DabvAtg/Wj+whYBLzFzi0sHBn72i3v+pVVITRGXzoQmiMtxUa2mCKEVqxhCEWJCJ6RoCmlSFRV6OHwPhpExf6v5K2mluTs6BYXwDxKe7TiyVNLXRYj5uMJ26txYnm0o6FKWOJogoaG0tqwmiMtxUa2mCmHkEQc1tXUcDfBmAN/sKCuFFML1c+J23BbBTgFDlCfjGyNC8i6KcJuxFMW/8EOCjVQU2pNwQMx+fTad6phtJaIKoTAI0QVSGm2otTRAziyCoqS15OoGEzta5X3AQyDPh7phl/E8iMfuB3t7rht3QzJ//ucScOS/vbYqdPqMTwByPkJkEumpkaO5piiRBze3JM8F0oUelZDLwgEG4HGa+b9as7Ta5+kLzO1bukMibHybCUT79eIlhLM72rxlU/QimQjlNEJXNgiaIynBTraUJYgYRREt753Jm3ChZ3G81DT5j/brUP1QER1wkxxoSl4BxlHdxB/HZmb7Ud8J28K2ty99vUezu4iW089rNIByT6esR/w+9AG9uTv4fxOhKAIeX9JtxX0OCl/T2pv6tMp6pUEYTRGWzoAmiMtxUa2mCmCEE0dyeXAAmYRGzo2vIQwT812678OWpVEpYCEV5qKk9eSwx/dBDOENEOHqgr2dtUGMtbZ1fZ+A8V5lXDDY+lU6vEZYQyo99hxGj6wEkXZVGAV6S6U/9WrmhSS6oCaKyCdAEURluqrU0QcwAgijo+unnAA50kwMTn5ztS4nFNXS37idQPqeSR6x4fvFg783Pyup9aNHR277p9ZFbGDhg7HeiyzJ93adW0hfZaYSBa7P9PSdU0p7qx1PNcpogKkNTE0RluKnW0gQxAwiipb1rBTP/1K0OItAVs+KbTu3t7RU+DuN5qLm987tgfMHdiLi0Hujv+bqsYanNNNNR2XT3zyrpSEdHR3wkv9P1AB/hqn+/wcOHpNO/eLWSNie6jiaIyhDXBFEZbqq1NEHUOUEUVDBYC9Bi11D/nDeMAx9Yt+YZVUEJKrfvwhV7xC3rLgDvc5V7xMrF9h8cXL3JW9eHIJZn0903V9qf5tauE0G2ZdZGgPIg6wlzJH/E+vW3vFhpmyr17PuYRHwpEXUx8CGXtdcQgCcButsi66rBvtSfg04zYQTR2HjkdkZ8NAnCpwH64JgFmm1txuuJ8BPO45eZTEq8t6LHGYv9DqL3grFDsaFIYwl7uTB4aGh4+eMgrGTidgBvLxpNFB0hMcDAjbmheb8OM3iohCD8rOeIcTVbfKofhqLf8dkvNcZgnODpN2DPA54kxl15ouvX93f/dSJPrx0dx80eyb/WAdBSgNsAepvHSvFVgJ8GjHsZtHqPXcwHVdTKmiDqnCBaWpLNbJDQxW/nDDVodx/2cfv9XvahAiYRHTXQ173GW0d4bVPCXEfAe8Z+G4eKqdI+j6eeWLApkfsmAZ+VXPp7mzYB7uN47Phs75onZe/1IwixSM6aveU0EL4WaJZcaPQFgD6d6e/+ZZTFSYwlFs+dz4TPq/iiMJBl4hMG+1KPRsFQOGY++xwJC7iLAeymUPefAJ0UNJ6oBCEW+VlzXr4M4M+53x9CDtTUmuwkoksU+y10thVhpIBJSZHCxiF/LohPUpAPV11+jAycMrAu9dsgWdEEUe8EIbkMJosPGhhIZaIKY1D5poVd7yOLfwNgl63l6KaG+KZjvWqsgkpox5s8F8ubQXxIpi+1vpr9qkVbRdIVdzoiHEmUZzMDR2b7e4QzX8kjIwgCH8OgTwG2WbHqk2fwWdn+1PdUSKKlpWtfNrAG4HeovqBYTpwqvpTp7xFGCqF3WEWLM6FCPCjie0wCzh8Zmvct2WkiCkH4kQNANzbErZNlVm82qW3El0B0fkQPfzHMoWrc8/nh1bxwxUdg8c8rmDunyVBZ0QRRxwRRPHamUFhkig8/PBqP77ehd/W/In6ogcWjvkt2LyJ2wMx0em54bk+YaqGafY/Slo81mGjCBEGYCafBNELgvbjgpe51RtwMwzgos27N793vlREEgOdKCRd5Bv5EoAdFXQbvQ8D7Jbt+JV+QgLHkAX4CRINiLAC/FYSFLpWT03VTxax5/v7JuQ3DlCoxSnBaKKhm1gH0AoO3I6ANwO6eOTEZ/OVsf0qEYil5VAnCVmvN2XIOA+eWLvT+5CBe5GOEYYLxDBOyBCqEdyH+IBgflpwmleYiigza/WpZ9nY24r8CsLenrrhTfEr4Ejl9s2WR8FHJ/ImqL1ngAwb7UxtkfdAEUccEIVXlAKmG+OYjqnA5XSZPLa2d32LCV1w/+AqfWDRmDeNWgDokgrkFhDWGRdcPD8/dMFXIorFj2e5GPn4ngA+4+mwy41Yrxl/y+pHYi75J5xUv8Lc6JjLfBgsr3bpuH4JwXpMnxhVmPnGuN95U8f7nUgBLPaIsPb05ZXwWGPs9+VzuG967G7GTfnojPmGQ8SPPjlV4r6/IplO/kC0w4rQ4mt/pUgYL9ZXr4ccsxqlv2xX3uXXh9o79eToEjKsAvNVVYaPB5qJ0eu2f3K0oEoSfU2bP6Gz+3IZ7U8WIAaU9tO9kZiWET85Ht/7CvaaBT8t8hsQcDufpi1QgIZcjqvwkHZUUnPI2prkdr2DCZ0rkELjSGs19zefejZraO1uI8SOP/AIB6l1NEHVMEC0tyQ/DoHsYeIszTGJcMJDuOadS4Qyq19TatYyIS/wfgiKStrau2Mci67YQVY29azYYv2SDb2uIbfuw18u7FmORtSnx3TDBfO7uu+LigAs/2eJU5qcRQBChfiXSHTrhCeS5I5NJ/dM7Fp8FRilMyb4dyZ3jeax2E7vQt1ujuU/JFibZHRiAe2FyVyaT+l+/uZOebiQLmQJBVEQOol9NbZ37vxHEUtznzCr209fwwjUOam5NngWyIwQ4z3Ns0H7Zdd3CUGHcT0tL1wfYsNW5Yz5NDJyf7e8R91SB6r729uRb84zbARKRkosPD8aQWNzff9NL3s5pgqhjgmhsTbYZZF9Qi1hK9sOEs7J9Pd8et5RKGpB8UOKFJ2XS3cLbWfoU7y5E7CT3rjyoewVVDtMvDcaaiTph2OHQE6a4Oxjrp/C1yA3NOzHshCNf/Et3lb4EwXx2Jp0SoVECP/zmtuRBAAmydRazLWTRooGB7ge8YEoWGCVVkdNOc3PyXYiRWKCEpYx4/AwSqLm961IwrxqTP+BxxI0D/S7r3X2VGD78wzR4P/fuPYQg/Jw5A08OTh+a2jtPJ8ZWtZZiKHGprIzDjLts0S5Y7ImTgPOoENdY4abWriOJbLN35/mHFc8vlPktaYKoY4Joaus8hICSo38tcww0tiXnG6B7AGwfhZAKEV3pFBDEyWZeRPIaAqHHsPjCdDr1l4h1lYs3tSYPJSJhhuuERA/U3ZYtyh5fFAYe51xsoWMG7EMQZQuiX4eL6q91APZyLcbSfBLek1DQCcDvfeWnKb6jIb5t0n26a25O7oY49YLxrijy4JRdsDC5V8yyicgZk8lMh2TT3ULNZz9BBCG7P2DCr3INfISfWimEoFTVs9Tc1nkdgP1E7hIGPQQYN1QrPlhLS9ciNngZgH3EfQ0xromiFZB8p76yrAlCE4TyIhlWsFKCcNot2qcvBvi0YrIgb0DBoC7YdwFmglc90Jt6PqyvUX9vauv8AQHC07v48J0wsVzV76Ctbfk7TBhCXWGC6EEC0pzntY6axYcgVBckSM1kmcp8S6TlKjhVek+nDDwTh9nR37/272OLd7mKZjNZtN/AQPcjKvgLVdhwfscbCWgBsAHMf+SYscatqvEjiPGSg00+5SrTmlolqWBSjTKaICpHsa7yQUyXE4RsumyrKGv4o7C4E8QHg+1dpEpCo41k8eHVNOOVhQZhwjnZvp4LKhe10po+C7fyO1QXfkFUecR6Cdij2IOyXbnKmCQnltE3LGcOdpvwlqlogKp7t8sIghk/JUCY1LrijnFfDIklMj2733glJxhRVPi0/B6MH1n5+B0yR1AV/CazjCaIytGvL4Jo7VpMxCJA39jCypJdZeVwldb0ufM4I9vXI2zyx/XYhGG+9iFmWkaE5SGEUVWfilp4fnvBUF3g/UBUrS+ZI3FhfgdgRDJ7ZuZtiOy0sGMOmOzRs3vVE2LhzqZ7jgm7T4kiKBKCeAJs98kdlFI0WUkwSGpq6/zvolWSX7eeBeEOZqydHd+mf7IMKMIwK/l+GF0g7Omqo1VMYQAWf68rghivykcRs7FiUa2YorbvLi8sdxIjOIwYZwH0H+Vtce/obCxV0TWH9UOyW65o1x30nrBQG2F9VCUI2akyrG3V3z0GENTU2nmDnbfD+bgYVw+ke4TnedUeyUV2QNvRZaIgZ3QTMT6p0GnhP7IBjB+bufyttQ7z4u2PnUL4n/kdLKNhbzDvBuIFBN7HEzZFNgxNEAqTK4rUFUHIdr4ipEC1P1IH26b2zq8Q41surH0taRTnI7RYMXyDSKr+fY9Tmm+oj9BGPQWiHMmjtu2UrzeCUCWsSvFyydyXiSGsvGTP6wAaSlSTilZh7sZsI4o4VoHpqxHCWYi4UlmG8cVs/xoRHSDU27wSLGzfCxOHg+kLPk6TKs1qglBBqd4Iwse72dfmWREjaTHZu7yWOuNpP6yuj8er8iVvUPuaIMLQL/zuPkFMPkHwoAnjmBhb3wbREtcIpJ7sKiN0FmNinFk8tarciVWUjjesP664Vj/wOBSGVc2DIdRiIkyMYxKtCSIMteLvdXWCEGOSHMFfqUUsJsnlp3h92QIt4seQZV3EoHcCLHZ3w1Y83+GXO0Jx3iAP+V2dsCLVutgNGsskniD+Fqd8e1/fzSKsR9UeWbytWpxe5SomHrTi5uFCpmRqVkg82aMO3FY9DdNCAlaCsMgnjIXTrG+okKjvFeXtmFLbbLkAjNNDDDeGAH6WQRsMUB9x/v7h4R0ej8956UMec3RNEIoTUXcEIfNkVfW6VMTMLtbc1nkKABFue+yjkEVzlTjTvWYxHzSYTvVHeZ+sbDHkt9uBqCqL36RdUgNSPwbZ2FV37E0ewwUC/gWLDxgYSD00Xvy99SflkhrYYMXzS10bDtlFszCJXpVN97hlZTzDp9bWFbtYMBeDRHRfmi+JjxXJmS2oM02tyS4iusF1AhDF8yC+jy26ySLKbBOf87TfhXmUE7H2gyidibojCJ98EE/D5P0ymdQT4/kqnLotLYftaBmJuwn4T1d70pwTsqiv1fLullySV4UgWlsPfbNFs4U12Mec8VVi5trU1vkTAhbJnKcm6gQhCb9iMvMyv1hK45EPyZ1UZDNX+1KdcC2Ynxf+IyKwX0N88w1OLDGFUBvwkc+qfgNunArxscwbPHHGqmLYUIxh9qs38owI3xDniWTarQmicqmuO4Io7O7LwjCIGzOlMBEKUEpNAf1yTsgEnIE/GFZu0cDALZsV3udbRBIsMPKC5Nd4S2vnj0uDo5V7Dgf1va3tiO1N5O50x8Bxm4VOFEHM71j5lln5/G8AEsmNCk8FuThEuA7L4F+9YQIqooc+RMBfifnydDr1tNOs97QiotNGjUkkmdMStaUKQYj+FD3hRW6SOWMkH/ANFMKTGyIK8kLAElF5YzFYB7sdAYPmu3Hh8ncbVkzkWhjLe1GNjZDETNkkwnEDfT3u0BmBn5FkI6VVTIoLT30ShB3KAqs9l3WR4u/4LpztncuZcaMnzHFgxjpJ0DugAusSd59ku0QGLs329wiv7HE/kvDkkbyCJaq+ksVyoghC0IE3PhKAqLtp2aagbPH3cTRblenvuVxlQqS7ZU9sL1WCEHr7xJwtVxJwvOvdo8x8TDad6vb2RxImJNJJS1Xlp4KDu4wkjlJU0pXNvyYIxYmoS4KwTxF2chFLBO5zOxAFJmMJwcwvEFpo9FFJsDfxqiEC/mu3XfhylVSI7r75JIKp6mW8bLFTPYXJo6eWhuqYQIJAY2vyAIPswH5ju2mArhodmrsqLPCgvyzxzQ3xbY90671lhgPCsk05WF8h1MVql669jJRVCcLud3mQQfHvR6x4frHXSEJ6yU7UPfL63KOVMJLFoaqCk6r3ni3qHVJr64p2i6w73A6OQTkh9B1E6SpYtwQhhuljCip+ujVvGKeq5qguptu8kIATy60o1BaaprbkGQQSUWXdpoLCdvx2g/m/VAPv+eVDoAgfs+LmAdJw38RnZ/pS3wmwc3fSVV7rWpBHmWmlOwf3RBJEIThi+YkyKHObg1ExM5zYce/vwm3IYl4ymE6JQI0lj0/K23tGZnMyyImxuJgLEhtLiCOsoGYlNn/encskCkGIjjW1dp5EZBtTjMkdga6YFd90qjdHiuTUqHrqLgv5LYtVpSp3nhNEWXQE1dN3QCZEX38lTRAziCBs9UJb58nFnMCu3aMNgtAl3wTDuLLBmP07rwWE2KXPnv3ie0yKfa54TPdmSkNY0nc31IXLc9sS43DJh1KMd2NcbRJ+67bIsE8Ls17aETGjBWR9BkyfkFiMPEpW/pMDAzc/VclH6FfH57LTZJ9ELb4JZBQTBkWJvBtVpeFzohQ8d4fBOFNC0NSyMPlxtnB5ued64KaAmts7v1tMmuSClh+0KH7CYN/qP7rJtWDfjwMAusaTJ2Q8CYPG3uuTqEpKcCJhkDErcQcVMgM6j29SJVHAd/NE+H6mr+eM8TrM+ajtxOn7G2zypbLgkWITlbD4bAYLL3ZpAEw/WdMEMbMIQoxW7GgPISIRjngsLHfZomingqRipi3bX2HnAJvripyBIoYxUF3rNxpsLEmn19hpOav9BKXpdKUDFTtNvxSUUvKayBOEg0nAiVIUeZaBfpG2spgKVBCxN76RiD2QiSO/PMiPIjDlqOs9AalNfdWWUU8QYmAyNYtfyHO5Os7ZULnSshI3gLkRIBHa3LsIV3PDEhQf6lWA/wgYxWi5LDLyCWunnTzfwQsMDLsCNsIvRpsmiJlHEPaIxa4iZlrfI7JTVap4hPqstfwYGThlYF1KWGxEDidQDGPwpWIYgyjhvcv6Y3/koGPX93c/Xm1iKDn9VJgs3ta/G7RUlllsMghCjKmlPXkwMwkjA//Ngi+YWx3SwvAu7NxJpBHtDCvr+T0wxHYlBFG4qC8/1fj4B/ndtakO4xE2qLNa2eTES8e3seI+jseOMXLWOW6rPD+zbU0QM5QgisOmprYVCwjWJUI9G5EoHiGic3fb2boj6qWy7MsqHJ2NcwA+QpL4PeRj5MeY6bw9duW11eiLypcvVAmxeO58Johcy2HE5ptT2nnXZBGEs1lIMF/MzMsVxiKqvAribyKPy1TzYYhKUcNDCMJn4hMG+1KP+s1JhQQBn/ziLzGMxbLEPi0tXfuywT+JkPlwiIEfcy7xVW8ecRX5CitTVF9+iwChMg6TP9Hc35jxFecbKXMqZdzXkOAlvb2pf5dshto7rwNDxDorPD5Z9aTOpBEcPcPGO1V+r+tL6iCQhb413pBYzGyHcBaZqoRKybmnEPcTG4tJW35Zyzj4IqbTcP71NgM4gMFtAL1dot7aBPDfQLjVZOO29f3df63k9FINobNxm5U4ksFdnqiZQ2B+TFy652Oxq8MMACaTIBwcRKrMWMLsssdih0IZU00I44HnAX4YMK5tiFt3eheSKFgWTU4PIuDoogrEUV+aYDxDoF7L4Kv32JmzYYRfKUGI/vp4JN/VEOfDfcZHC9q63h1nPpYJB9ohsxk7FMduY0TAoyDcMNLAt1cjknAYrraRhml+BkQHv3GH+B5XMMEhAE++4VB3N4NW77GL+aAbS0naWWk4dH2CmNkniDD5079rBDQCGgGNwNgBSkOhEdAIaAQ0AhoBCQIzVsWkpUEjoBHQCGgEghHQBKElRCOgEdAIaASkCGiC0IKhEdAIaAQ0ApogtAxoBDQCGgGNgDoC+gShjpUuqRHQCGgEZhQCmiBm1HTrwWoENAIaAXUENEGoY6VLagQ0AhqBGYWAJogZNd16sBoBjYBGQB0BTRDqWOmSGgGNgEZgRiGgCWJGTbcerEZAI6ARUEdAE4Q6VrqkRkAjoBGYUQhogphR060HqxHQCGgE1BHQBKGOlS6pEdAIaARmFAKaIGbUdOvBagQ0AhoBdQQ0QahjpUtqBDQCGoEZhYAmiBk13XqwGgGNgEZAHQFNEOpY6ZIaAY2ARmBGIaAJYkZNtx6sRkAjoBFQR0AThDpWuqRGQCOgEZhRCGiCqIPpbmrrPISAX4wNhXFfQ4KX9Pam/l0Hw9ND0AhoBCYJAU0QkwR8NV+rCaKaaOq2NAIaAQcBTRB1IAuaIOpgEvUQNAJTEAFNEFNwUqJ2SRNEVMR0eY2ARkAFAU0QKihN8TKaIKb4BOnuaQSmKQKaIKbpxLm7rQmiDiZRD0EjMAUR0AQxBSclapc0QURFTJfXCGgEVBDQBKGC0hQvowliik+Q7p5GYJoioAlimk6cVjHVwcTpIWgEpjgCdUEQTa1dRxLxT7dizQ+PxuP7behd/a8w/JvaOn9AwKlj5QhPIM8dmUzqn1HrMuGsbF/Pt/3qzZ//ucTs2S/PZ0KSwR8DYU8wdnCVHwL4WWIjDcbqkZG5v92w4aqcQj8iO8qJvjTM2XIOA+cCiLnecS9M7spkUv8b8l5a0Nb1bgP8aQIOBbAngDl2HcKLYP4Lgbrzo7mfrV9/y4thY6jm742NK3eKJcwuBneB6L0ujPMANgIYBCjVELfuHI8z4b4LV+wRZ3MFmLoAvAfAm4vjGALwJEB3w7Cu2X0nPJpKpUyVMTa3d14HxrEuebw+09dznEpdUUa1fkdH8k0jOboNhE8U2/5bnPLtfX03P9fYntzbYFwE0H72nBbmcz2DrsgNzft1kEwuWHDYDrFEfCkRdTHwIQA7eTGxyLpqsC/1ZwCsOi6nnN3vvLEYsI4H6KOu9sXcPkVMfZbBV++xM2dVMff2YaLkJ+rYJ6N8fRDEwq73kcW/AbBLEcTXLOaDBtOp/iBQJR+JKK5Ut63tiO1N5O4EqLH4jlfI4oMGBlIZ7zubm5NzYOAEEH0NwFsjTPQLAE7bfRfuCRL2ClRM1NyePBNMF1ZCDmIBIaZrCGhSGEueGFeY+cS5g4M/e0WhfMVF9u1I7pwwje8z83IAcYWGXgXxN5HHZZlMSizqSk9hAaXvAtjfg59f/UfI4NMG1qV+G7Yoqi7wfi9SrS8jCJj8McRoKYCLx8je+yKmkzLp7ivLF9Ujt6NE7psEfNa37tZKJsB9HI8dn+1d86QK6PY3FMcqMH3VRcQBVfkxMnCKCuZOIxMlPyrjnSpl6oIgZAt92G5eTEBTObHY88KEM7J9Pd8LmqTGtuR8A3QPgO0L5XgwhsTi/v6bXnLXa+xYtruRj/3cRSRR594k0FUjQ3NP89u5RSQIH3Lg3nwcKx/oTT3v18FkMhn753N0CgP/o7AIeJqhv8OgwzPr1vw+KgAq5Zubk+9CjG4DsLdK+dIy4WMvlqfmtq6jAb5MbZEqeUuegG+MDM27KGgHrrrA14IgCLg0ZG7/YRq83/p1qX+439/Skmxmg34OYNeI2G9m4Mhsf8+9QfWaOlbsSXlzTQXfkAnC90Zfn/eVsJP4BMlPRHgmv3hdEISAsaWt8+sMnOeCNNUQ33xEb2+vOHpKn6bWrmVEvFbyY3jd9s4vk30ML9IDcGm2v+c0d1vz90/ObRimFAMHeN4h1A1iIV4PkDglCIIRJ4sW15HZXWWUmVZm0903ywYSgSCoqT15LDH9sHSBV1og/U4dokuvAvxHwHjE7h/xB8H4sIRENoP4kExfan01RT8A55J+MXg7AtoA7O59PwPX5obmnRiwkASNP8/Anwj0IAAzYPyhZD+JBDEKYMRFfGLxvo9ArwFWE0D/AaIrMn3dQh07phpqbk8uANPtAHYsk3GCIJI0mEYIvBcXTpyOGs4pvhmGcZDfxqGlZdnb2Yj/SkL8JhjPMCFLoFeC5hagq0aH5q7ym9sJkp9qivyEtVU3BNHYmmwziH79xvF428IiFX6XUHb/MAZ78B1GR8dxs0fyr6UA+lSxyigDB3t3Qk0eEimWvdU0+AzvLsx5dWtr8r0m0RUEfLxUCvhOmFguU4WoEkRLe+dyZtzoIYdBK24ePth787NBUievixeY6fTc8Nwe78dXONVhVVGtVribKDyPWPH84rD3RfkCmluTQn0n1B7OXcoQEU4beX3edZJFgZoXrvgwLOsGAB9wvcdXRSjKNLUmDyWiNR7SywP0HSsXv9CrPgtQiZgM/nK2PyVUVGXPJBKE0xdBYj9g0zrXLWvivgWGmXOfMAun4/idHhxNZtxqxfhLXhm3ZcKk88D4QokKkPk2WFjplW2fhdu3ffHVN7av/KDB+WsA2scFbjDmEyA/UeR5KpXo9etGAAAR/ElEQVStG4KY37HyLbPy+d8AJC7GxCNdtB3wJXcI7nkJvIdoa1v+jjxivQTsMbbo5WL7Dw6u3uQ0Ii66jIQpjs5jixARdY+8PvdohePuHMToegBJpz0GnonD7OjvX/t3rwCpEMR4yMG+jLWsuwC8z/XuR2Hykkwm9USQQDe1de5PwM/cO0wGzs/294j7mMiXlN53SchaFFmV6e+5PLBfHSv2RN66iwqXy/bDklOg+H9Ly2E7WkbibgL+09XmS0R89EBf6pdB72leuOIjsPjnAL/DVW6jweaidHrtn7x1J5sgFE5SY12WnNpNMJ+7+664OODOTHYSGwV4SaY/JTZ4Y49kg6XSPooX2T8E+GhXc0/D5P288joR8jOVFvyofakbghC7h6a2TnFxerwDAjEuGEj3nCMDpaUl+WEYdA8DbymuDutAWDhW1ucyTvxe3E0KdY+9YxUfVba/5wT3gldcGMXiMavY5mayaL+Bge6CGibkKTsRAVvIokUDA90PeKuGEYRskRZ3JionB/Gu5rbOUwAIvbvzRFIVtbR3HsWM61w7fKkuOwwT2e+CiClhrnMt9C9Z4AMG+1MbwtorH5f8HqmlvWsFs20l55xQTCIcN9DX47Kc839ba+uKdousOwBsN1aK8P1MX88ZXpKcZIIIPEW5RyjbAKmSi9w4hG5qiG861lEJy9oPUxW5+yesqYxZiTvchhTiDmigv+fr3nHUWn7C5HAq/15PBAGJuesdDfFtk7291w2XLaqlprEvAfQFgMXlq20JxYyfZtM9x0h2udTc3nUpmFcV2zSJ6KiBvm6hfhh7BAFZBh1P4H0AejsR9c+KbToq6E7EXb+9fdkueY73AXin838GDs329wh9b8kTRBAyHTEDfzCs/JKBgZufChNOccyfNYxfvWGyKe5H7CfqCUDWBgIIOKxPITgpWaGJNlpauvZlg29h4DUAvzOAh9jkS92qDvkO01/d59N3r8z4qkAnlyDkBCkbk3eT9Ia1nTIx29h7SJeBxzkXW+icwiWkLD0BBMlKeRvlqmPJd1ZV+Ykiy1OxbF0RhFf1E6CW8Zw2+GETRjIGoZd2zFbl9xBeVVaQ6mc8E14Nghgxsbf3AjEKOYj+l1trRVsIHAxaWju/xYSvuDAJNQRQwa+19dA3WzRbkObHtpZXunRXaR4SdSKY6ahsuluozZQfyYlQqgKdTIII2BSVjbP8/i4aaQpcTRjihG2C6EEC0pzntUX/mzJtgOyUHga+ZO7KFv9ay09YH6f673VFEJLdnsnMy7Lp1NZsawC89w9C+PbYhT/7zEa6jghHFSdNuiMq/9DZ95QynskfL0HA4LOZ6Ua3jh3A32IwF8nuMfz66j2VeXd6qmMstxhTd2YMe4dEFy6qbAFhjWHR9cPDczeE3fsEjH8xEQsCctRLz7FB+2XXdQtHL+VHckcmzKnLHCsnlSBCHD2dwX5o0dHbvun1EXHyGrPOY8I52b6eC5QBCSgoux9UMT33Nild/CUn11rKTzXwmMw26oogBJDeiy3ZxWPZrrgoNE3tnacTY6t1iUSYyi7OqqQqEX0veFq/+B4LsUNBfKRtWujyclZWMQFPAzAk5pyRdOeiT5Kd/0YG7iJQqId3qWDz2wEc6Pyvmievog27cJR8m8/HNATCQ7Doek7QXdneNUK1pnRB3tzadSKIf7S13cqIraOjIz6S3/Emt+EBCGVe0pNKEIonI+nmhWm5nxl21AVOdmp74yrsLoBCVaLudzE4QQWZG/PPkN1L1lJ+oo59qpWvO4Io2+FL8jN7Pvqxk4K3rvdYKzmhRNK7Fief5nes3GGWmX8HW9jLIDtcwEc8YQmkchKBIHzlTJwAEDcOVPZg9YZ+qJ4EV4Kd79uLJxRxEe61s5fV2QzCzczGdXvsYj4Y6KXuNVUeR75vlcVfpUzQFKjWlzqX+txxed9XNG9dB2Cv4m8mMx2STXcLk9dxPxK15rjbHGtAQsr2xrLgE1V1+alexyenpbojCMlR3qsSKLt/cOI2lVvElF7ale1sFBcLcTJIzNlyEDHOBGHf6F7IBeGokCDEBb0IOzEWekLV2kS8s2zBqZ6cVpUgRLcihgBxRrKFgEvMXOJSWSiQ8hMj7mtI8JJKYjiVYSnbvExeLCZf+SojiLIoApXdS/mJ0mQQRK3kp3qfy+S0VHcEYe8GPAH43JeKkkvmMRNVrxqAgH/B4gMGBlIPFXcZJUEBg8xondNCy8Lkx9nC5UV1keos216iIDvQ2ZiTWXSCoL+LwIAk7MELzknOM8TMK7x3M7LOTSeCcDBvbE++j5jOJOBwxROFqPoIG9TpvVuoKUEAZRf1qicAP0FSrT+uE0SdEkQt5Ef1g5+q5eqTIAper1I/haJp490A5hW25aXBx7z3EC5y8VpWhJnDUXNb58mBgc8KUuFEGN0AYhHo7/6G2LYPm+Yr21ds5mo3uzX2kczRrWDNlFs0MHDL5iDhVF1wpqKAi9hRz2wy3kMmL2VCFwHvDwniV+blXVOCmGp3EIoqJskdQa1VTFU/barIazXkR+U9U7lMXRJEuQBvVRX53T84k+S9hyDG1QPpns+Wq66CLyub2lY0Eiyhky0G87PfIKJY/p5gXAsL62bNsp70U1WMy4oJeJqJDsv2df/OGZfEWU3Y4kudtdwC29La+WMmfMb5HwH3/HubhsMevvtG4TswrR77Dska/ijYEieqZZL4QWI8JV7Y1bukLgvPAke23CCOl5BV64/nBFHrS+oyJ1agqgRUqdBWIj+Vvmuq1KtLgvC7TJ4Tf+EPpZYk5Yu83z1EjnPvL431RJd5A5c5k1pQVe10PcBHuCb6VYBOyPR3i6iXoRY04yIImW67EHJ8NYiWuPr0isHGp9LpNcIhT/qUWXYpxLiaKsId1A+xO3x2I44D0f9zq/G8BOj1iPeqHVXHKvH4lkYNluQnUc4HITM/lVlKiT6PhyBk5qOVmLk2tXX+hIBFAD/FoIcA44Zs/5pBH6wCc62ozkO1yqnKT7XeN1nt1CVBCDDLwigwnTSaMNa64zXJnG8k5oj2JbdhsUiA4kSLlfpXOJModa6KGH+oTBUW5ZLa5/K8EBfIEvFuXJE3uXd0NpZuuDf1skwIJSFDpHFzwgTYng/CN8D8vHCMAuMBmPyTKHkY5P1b0UhsfpKImhnYuzinImeAyiPUhhcScJar8FjiHPG/iXaUKzPT9vfoLxufbGGtBUGIF3tPlkA0fyCpr0PRzLZK3uso4iHibW1PwF8s4M+Gxdc6d4piHPZJv4byoyKEU7lM3RKExBIiZTCusAjC6akQ8dXHh6H8HgLHEXCMK/tWYCwhVa/ZIMGQxD9St2Lyt66i5tbkWSA7UdDWh/nsTDolQpeXnWzGE3TQeYEsLk7UBcUPq/HeEZSFKQFKCEK6WClarzl9FpuO0dyOV7hVdX7RhiUB6u43ePiQdPoXr4YtJBIyF2pE6QlkPCcImyDK41NFijVWzCEhNitOfKoSa0OJ/Ieedr34SNSqZd7rtZafsDmb6r/XLUGU7VAITzBTN4Gd4H2+F1+SBf7+YkpJJ2NdYJgIyYcaSYfq57ijbMUUsIDJF2sExeSn5vbO73qtoIhw9EBfjyyXRpnMN7UlzyCQSMU6FuwOzCdm0qlrxvuBSOYq0kKisiDXJlifXEVZHk8MSguvnUJ2m5dvZGaR/nTrUyOCWLAwuVfMIuGc6PhC2EErQ3Jq2P2SEiZKQ3W0ti5/v0UxYUyy1ckNuGdkNif9TrvuYfuEIv+dOZpb5E6BOxHyM14Zn8z6dUsQheNjSb5pcakq/orqFf9LZulRvWTHLU+76BSRXLIpfzyCHDhGP/eEli4ceHy8VcOiuXoFrLE1eYBBdvY1d56GuxrifLjs0lz2sQJQygbWvHBFCyzrFk+4byULKpUPQxoIEHiUrPwnw4IRikxl3pDfMtNln3DfrzLTcWHewz7hvn0JWe4DEJzwpqgP/xKIzi9LgVojgrBPEeVJukSypLMzfanvBNyzUVNrspOIrnXJnywhlmxjIqzzbmyIWycH+aGIXBxk0KUlJzb7ohursukel1c8MBHyoyLHU7VMfROEx9y1ZI2XhOh2qwTKwiJsrRwai8dH6EwGruRc4myZQ5ad7L0hfgqYzvSz3fdLoxqVIIqOe1e6Q6MLCyvZB+QMW3IKED8NMXAR5xLfi5AwRyTzUT59qHw4Ugst8GMW49S37Yr7JJ7SVPBPMX6smqfBL2GQX75te5GKGcdzIUKw27s7cBH1yZPuKztiJ2+YdDERRC5p54RW8xOETRDyPBl2X63R3NfcO/XCySH5puE8fZGAc1USBvmcAgT3PMiIrcr2rxGZCUvUon7OksL4wO/0MRHyoyLHU7FMXRNEc3NyN8SpF4x3lYEfEkOpzHrHaUBR/ywXOruRITA/BjKECarIdLUdMZpAdvIh9wf+Kgib3H33sxSJShCiEz5qLN+QyoJUZs15+TKAPycR5NKUm4XkOK0Sj3GxeHxndnzzuaphz1U+Gjt7W7mFVqEq4UVi/I5Bdh5lO/Ul4aNg7OBpO2z3W42Uo6IHgekvRZ+KYR9Wu3KJOF0dslN4Ch8X4gYbY7ZVPGOZ9MB0GYiFWXLBvLqGJwhbjvxTjqqmYQ087QW0b88tGOvstL0CDwsfA2HPcpkRPkHW0sy61B9l8jRB8qMiylOuTF0ThDRAWmEKQh1vJLpJu6LfLt47s7ZOeM7LP+DCglq+swsUBX6MLOMYK8Zt7uCBfuGYKyGIwkLUeRKRnQhorH9BWe9skthmywVgnB59TCKss1oC+Uq+kn07kjvH81gNUEcF9fMimczI0LyLQqK+Uktb1+clpwKVV4oF85Lc0LyvhkWWrRDnISY+OWbFHrHIErr7CSEImyTkWfNCMbHjghm0NCwybqXtF3cIf4dBh/vlvHY6OUHyE4rJVCtQ1wRhC29ZNE57mX/Yib/kNyE+9xBh3tMlzdkf+uwtp4Eg0muqBJF7Acz/DQvXCPPPsstuHx+ESgmikJqRhF/GWJRVO1Ur8zHZdKrbB5uieoZ+4MlFHCDb/BgZOGVgXeq3Kj4glX4kYifIMTqPgFMjxLt6hAw+LUrfhBrDYLpKcKwKUTKQjbHxf9PpNQ+qjs2+V3iOOt9Y6AXObw2uJ06kOCnTl7q/7A6jxicIp1+NjUduF4vnzmfC50O81UWVvJ9qzv97PHI7SuS+ScBnFec28jsmSn5UZWAqlKt7gpBd+qkkH5GfPtQzbrknV9wvxGcljmRwF4je61JviDAbTxFTHxirR0bm/ta9u5SYmErDdVdKEPYpQu7xXRZywius9gK2CXvDMk4ArP0BEqG2HRIcAvhZEP1GJWJqtT+EYk7ixQCLnN6NRUsYJ1jhqwA/DRj3wrCu2X0nPBoUzTWgb7SgrevdceZjmWyCFbmtnfELk9THiXFXnuj69f3df62UGMVYRk1aysyf98jOJoCF6uyK3NC8XztyM1kE4eAUIOsF1Spwez4Wu/qBdWueqWTexf1ewwgdAsYxwu8FwM4ukhaY/A2Mn5i5/K3eOxDV902Q/Kh2Z1LL1T1BTCq6+uUaAY2ARmAaI6AJYhpPnu66RkAjoBGoJQKaIGqJrm5bI6AR0AhMYwQ0QUzjydNd1whoBDQCtURAE0Qt0dVtawQ0AhqBaYyAJohpPHm66xoBjYBGoJYIaIKoJbq6bY2ARkAjMI0R0AQxjSdPd10joBHQCNQSAU0QtURXt60R0AhoBKYxApogpvHk6a5rBDQCGoFaIqAJopbo6rY1AhoBjcA0RkATxDSePN11jYBGQCNQSwQ0QdQSXd22RkAjoBGYxghogpjGk6e7rhHQCGgEaomAJohaoqvb1ghoBDQC0xgBTRDTePJ01zUCGgGNQC0R0ARRS3R12xoBjYBGYBojoAliGk+e7rpGQCOgEaglApogaomublsjoBHQCExjBDRBTOPJ013XCGgENAK1REATRC3R1W1rBDQCGoFpjIAmiGk8ebrrGgGNgEaglghogqglurptjYBGQCMwjRHQBDGNJ093XSOgEdAI1BIBTRC1RFe3rRHQCGgEpjECmiCm8eTprmsENAIagVoioAmilujqtjUCGgGNwDRGQBPENJ483XWNgEZAI1BLBP4/pzMUf7+OmDIAAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-29"><g><path d="M 371 551 L 371 594.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 599.88 L 367.5 592.88 L 371 594.63 L 374.5 592.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-44"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 562px; margin-left: 382px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="375.5" y="556" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-34"><g><path d="M 321 501 L 51 501 L 51 407.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 402.12 L 54.5 409.12 L 51 407.37 L 47.5 409.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-41"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 512px; margin-left: 312px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="303" y="506" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-15"><g><path d="M 371 451 L 421 501 L 371 551 L 321 501 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 501px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">ACPI fixed <br />event active</div></div></div></foreignObject><image x="322" y="487" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfQuYHFWZ9vvV9GQSkNuPEK4KruuuKKwazMz0TIfRABIEAgk9k3BnUUDIwyoL+gu44iq46v+I5kFRlLuQTLfhogGEAM5menp6InFdREBWQLknyHITJpnpru/n1HTP1FSduk11D1Dz1fPwANPnUuc9p857znclyCMICAKCgCAgCGgQIEFFEBAEBAFBQBDQISAEIetCEBAEBAFBQIuAEIQsDEFAEBAEBAEhCFkDgoAgIAgIAuERkBtEeKykpCAgCAgCMwoBIYgZNd0yWEFAEBAEwiMgBBEeKykpCAgCgsCMQkAIYkZNtwxWEBAEBIHwCAhBhMeq7iXTnd0XM/DVyQ3TTS2pTSf39fWV696ho8H584/ZOdXSvIgZRwE4EMBuAOZUi6n+nwWwEcy3m+XU2qGhVZuivlMms2T3Mqf6Afxd1LrV8hUAzwP8MkAFBm6fneJf9/Xl/xa2vdbO7DwDtA7ATrU6DBxVKuR+GbaNqOXa27NzYOAYEM4GaH8A21XbGB4bD93Xktp63pbKrNOJ8a3x9gnXDfbnTona30wqr5nPx1JUzvT33/zcTMJhOsYqBDEdKGv6aG1dPtdortwD4MOOnzeTSQuLxd4HG/Fq2Wy26ZlNOMg06RICPg6gKWQ/aqO+xyQ+d6g//1DIOqgDQei6GmbgJzza/JWhoRtfDXqX6SaItgU9HySTc5q5tfEA1v1tm5ZjthneerYQRNAMTv5dCCIaXnFKC0HEQS9G3fbO7GEA3QZglrMZAr5WLOQujtG8tmprJrsfMV1FQFuMtstgugym+dXBwbw6Dfs+DSKIap/0OAw6dnD96v/ye4npJIh0+phdTaP5bgL+ye+diPHT4kDus22Z7i8KQQStIiGIaAjVr7QQRP2wDN1SV1dXamt57nUAH1etNArAsJ3mHzRHmw6eikjH4yWovbPnRIAvt4k6dEU3AfT62A+8LYC5PoP6FSp8/OBg/n/9Bt5YgrB6fojM8uHF4s1/8XqP6SSI9o6eM0D8I9e7EF4E0yvW34l3YOCSUn/uMiGI0J/NeEG5QUTHbKo1hCCmilyMep2dS99XRlMfAXtXN+N7x/5NC6vNVojohGJ/7+oY3dSqUnsmex6YvqkRJ70MwrVMdOXec81H8/m8EiONP11dp8weHd3ycZNMVVfdOiaJowhYt3U2Zzfekx/b+DSPliCiydlpXtfynWeZ/AGY5vlv6kSOdL0HUe/WN3Y4cePGKxXRup5pJYhM97VgnGx7ic0gnDTYn7tbsa7z5YQgoq9wIYjomE21hhDEVJGLUa+9s/tsAOo0P0YLjEtNA69MEjWgPsrqdKZ7KTNusCmfVZcVBn7Mo81fDiPDV6/Y1pE9koiutSt6x14e3xvsz52r2/zUz3UgCDvS6j26iegax3iGTebFQwN5pYh+ywiiqyv7rq2jdBsIn7TPbXEgd2GM5SJVHQgIQUzfkhCCmD6srZ4s65YmrAFoUbXrCjMvYcIzDkub2Mrq9gXLPgrT/BWAXW3DHGbis0r9+eu8NnUvSNoz2flgUpY/9vZeNdg4YmBgtbJUcj11JgiLknQ3IgauKRVyp+nGNF03CB1BMNPS0kDvzdO8zBLdnRDE9E2vEMT0YW31lE5n29kgtWlvr/6fgadSqHSlUsZm1+kzhrK6ama5CkSLbUOsEOicYqH3iqjkUGsjnek+gRnqJjEhbmK+DSaW65TWDSAI6C3A+IGRVGrhxr5Vf3VO6VtKEA02p53m5fu26E4IYvqmQQhi+rAeI4iO7kuYcMFEt7y2JbVttq/v2i0ueTQwZWW1zkpKnbJHh3c8w0tWHwYK3SkZwKtk8mHFYn7Q2UYjCEL10dbZ/X0CzrH195IJPmSokN8oBBFmJt+5ZYQgpm/uhCCmD2v9yZfpzMGB3h+P3S56PswGK4V1TYQzJWW1xkpKNR9bZDVxi+hZxsw/s98ivExzG0YQTvNQ4HWT+bChgXxhOglCQ+pBK2oSkQUpqdVcjpTnrmTw5+wNE+iKWalN54RxqNTe+kBXjgzvsCLosGAdCMrGIsA8FaCP2SzblCPlX4ip3zT4p3vvxiWnkUMQEPbfJ/VDNB+Mnau/Pw3CWsPk7w0M5P+o/iYEEQXZeGWFIOLhF6l2W0f2KCJS8uiaeGbSpq3RTyhJ0PgNI2xnVUctRTS72+rkW1KbjwuzoQT1MybiKd9GoFeZaQ0x7tlzT/PPug1iGglCieu03tGNFDE1miCsDbFryV5GOXWnw/HOVzFfm8P29uz70URqLbzHNq8PmqnyoqG+m5/2mmtrLaawAkxfCTCNrjbBj5CBs4vr87+OIr5UjptPP0fdbxo/fB/ALj5rb9z/xmzCfg59nXhSB320U/xdCGKKwEWtpj/Vuzd/jR195JN/W0fP8UTWCX/8YaYTSgO9N0Z977jlp5Eg3hIR03QQhJqD6uFCmT3XQqEoQiyZI6NHbNhwy4u6eZo37/Tmlm1euYGZe2y/+xoVWH11LduHypXVALVGnP8KCJeNvLHjBUE3E9WuujVsKdNKAk4K69GvHAwr4OsMol/YLOqEICJOVNjiQhBhkYpZTneq123abh8JZUkazbM63dH9EyZ8pvbKBPwVJh9SLOZ/F3MYkas3iCCorbNbeYSfWnuhmrK/UFjzuPMlG3qD6OhZRISjVZ8MbibgUwD2sL3DXQDZnfiGOUXfK/Wt/rO1GYf3pKb2TPd3wfj8pPExf3lwIK9iObl9LDq6zySyzKntBgWe5VW76fSS97KRugPAfg4cK2A8xYSSdXMEb09AJ4C93IsiWHylyGvWnFcuB/h0zaLazMB9qh8C78tjPji1WFYgwi+YsQDAjtW6QhCRv8xwFYQgwuEUu5TT9wHAExWDF25Yn3/C3riH/iC0slqvRPa28Ik9sIAGGkEQ8xdk920yLbHJvuPdM+5raebFuiB+jSSIyXPn9oMICgoYgSDgEcZjMwzjMGe4kY6OpR8yqUk5542TVZBj47yDszu0bKE8A4fYxlVhxq1mE5/vXKvK5Lg1s3x/g8tXAaSCPdaeCoO/WCrkv+u1PPR6ERUckk/ba3ess4srx25CL/cwY6XLD2esAyGIBn3IQhANAjbExuFpt5/OuJTAoZXV+tAW0fUY9YKlAQShPUn73bKSQhBqTlo7socYZMXwGhc1wWFmPKbwpZ9j7DZTe7REYp9njbisAuaL9toD3/FTQFcVzD8E+ERbe0+iwgsHB/N/cq4lD6J7CBVerCtfq+/hhyMEUa+PVdOOEEQDwa017fR9ADAC8OLBQl75Q7ie9vbsnkhRHxjvn/iR70QFS4MC5DVgQ46FUD3fp+rb8X9BpDyT7WE/njW4cujAwJo/6F42SQQx5ijoEjVViHBKsT9n6Z3aOrPnEujbNozULWBFaSDnjhFVBUzvWxIsKqrhrULHG7Oa19oDQXqRtuYAFKgXqfXT1pHtIaLrHUEu5QYR6yv1riwE0SBgJ53M3Db7QSIjas/0rATzCvsJMEwYcN1mWIscOg1DdXURlyDU6XRkxNgHBh/NwJkA9nR14iOHV2UTRhDQbcZQPjOp8iLDnLWL03s+jP+LZtP2vAF4rSN3G27R5pgIddebAGQn2gkfVkZv6ScipkZ920IQjULW52TGwMpSIfcvfl23dXYf/Ga+htvtJ6UwymrtZkj4Uqk/p06U0/40OpprkFw9iQShxtTRsSxjkrm25pGv/qbWlQF80KFDCIx2a8Xaciv9PUWgXotIY2Dh8k3R3Y6jWthprPTkBtGgL1sIokHA1prVnMw8Hbrsr9LZedxOFYze6TA1DLp5QOsDES16al0RaTBBhAo5nrQbRHWC1Kb+7wRc5DNhw0Q4sdifW+M3qbq1xoRzVTjyKIuho+Oo7UyarWJ1HTRez+YIapF1R7bTICvUjAonr57n2KCFpfW9D4ftK53OfgQGrWPg3dU6QhBhwYtYTggiImBRinv4PhRHZuNwvxDZ4+TiTkkaqKyOK9KJMr4wZRtEEM8AOH+v3TkXxns3oQThJWoan5aw3tY60+o340o6zXMDp1tn5qsiFduj2bZ19Cwh4nHCYuBRHm1aECX3idKXUHNlPQEfEIIInJZYBYQgYsHnX1l3mg8jJhonCEdgv7G/+yurdadBJYZR6S0fuPuGajKgBg7a0XQdCMLK4UzAn5h4HZOxVpe7wm9ESSUINea2zmWtBFN5WY/n27ZWSYATnR0vHT51WyGO26vLUsrHPNnrHTSm3HKDqNuETW5ICKJBwKpmNb4P9ejNMzCealyvBEyWH0RUEJNMECpUxVPP0RUEfNaOCwPfKhVyXw4T9kIIIuqKmjnlhSAaNNfK6WjWFtwBULreXQTdQpwRYxPoSR0J0iQThE5ZXQUntOmoEESk5TSjCgtBNGi6Nb4P9ezJV1mts4CKaikS9LLtnd3LAb6QmG5jg29radr2ARWy3Fnv7aATSSpBeJi7jk9BWDGTBh/PuFZB6yLodxExBSH09vpdCKIx86HzY1DhkZ8FSP072kO8gy38sarrq6zWO9qhbtFcdcp3r1uKEIQ+wmxtAUQJteFYNDorppFqmVnjZQNSwqpyGqugCjMdWRroVbqNuj5tnd1HEqAC7dWeyPoDjZ4tcht1HVSCGxOCaMDkemQ8C+UJrXsdXfKfAGW1jqDqdirU5K1Qom6tdZYQRGMIQusHQbByXxPjEts6CgwLrrEKAjfIdyad7vk4G6xiRNUC7UVelxqrKyGIBuxj1lpqULszulmN7wPiiHjmdS1/96xy+V6ADrAB66us1om4iKh36xs7nBgmFLPPBOqjigIrBgu5HzjrCUHUnyD0sYy4b2Q2jm56tZxyhrxg4L8Nc/TQYvGWzbp57eo6ZfbW8ut5gI6Y+D1caBd7e1WiuYuAnQj4owk8bJh8jT2KsI6M4PCVCNo8NHlVhCCCQJvi70IQUwTOq5reikgfuTVK12m3T4Q6KU6yMbe355ELYFLMnij918qmM91LmXHDpGBxwMNlw/jUb9avfkoIgm4D4ZM1HOoZzbXapo6gJymktQH9AkRNGou70Epu29pw5isfYeDTpULuHtu6cHltI4Kpq0e0YyGIqXzMIeoIQYQAKUoRnfhFxcIpFXKnhTE59OpLL9bxz1ndvmDZR51xeQAMM/OppYF8Lur7eETT9A0EJzeI+t4gwmz+HmlKfUVNUwkPPun2oM9699vKyOihzoRGGpFp6IOLh9WWEESUTSpCWSGICGCFKao5iflGbg3TpirjcTMJ8qym9kz2PDB90xH9tEyMKyrl5ouGhm58NegdqmkhT35Tbvw9TfrJu1pSfKwuD4NqVwiifgThESZbmz5UZYVD2VTinpq3sZoOv1SjHqJDuqElZZ7lNb+qURVAjwxaaU9SpQwpvCLIVqPyrgLRYtvaU0mCjnfcNiYtzWr6VBXq3JnMSAgi6COe4u9CEFMETldN7/tQPyc1nW4jyLM6IHPXyyBcy0RX6ryTle6juVI+ghhfAugfNWMODAQnBFE3gtBt4L6xlnRJefzCb3jkvlYXzfsZTStKhdUbnLfO1kx2P2JS2f1U1rfxJyiIosdt9DUQfx1lXG4Paz92QFFJjOgqR7a+Wn9CEHXcxxzz2KCWZ2CzmkBkkdOF+sGmt46Cr7K6dsJDilS6SuVta8+jYO/OYYbLKoH8eJpH53spxSdV+Fi/BC9yg7BCXhxVKuRUADvtE9bM1SMn9TWjwzue4WV04KGHUiLGZaWBvN3UdPzdfJLyKJOWF8FYD9ALIG6BiYPePGDs4x4YPQ7DPHpwff73fuvZQ5+lqrxGQIlBTwC8CwgLHGbezmaFIBq038oNon7A6kxLAzfvqN07vaSt+kSXD/b3nuOnUwgQE0V5DZWY/mfmSPM5YcRTcoOITxAeJ/tQ+Rp0uoUAURPGdFf8c4DfF2VhjJVV5EDHOlOgerRDbZnsycT0Q4fRg1+3Sl+xmpn3tUUpEIKIPlGhaghBhIIpuFCcLHDBrU+U8PDQDgwDXmuh6n17PgFn2GzRw7xCBdapzvhXnajBqwEhiHgE4aFwDswQZ58PTYY5BEV6bW09fntqHv16NcbTRHpT75USSa9lb8ZLTKXp6jUmunC0xbx+1jDdbLMWE4II8wVPoYwQxBRA01XR6wf0vgFxuvTIqBWkrHZ1qcQPs2e/Mo8JWQar+P27Vf+piaCqIidsBPPtZjm1NkpI5lqHQhDxCEInWnLmoA5aT1Xd2K0AddnKhsoVoeq2bKUjwTiJx5TDap3U1simN/NQPwbG1ZXR8q1Oa6Wg97L/bgUdfJ7aiHE2gAW2fobB/Ahbt9bydaoPieYaBdl4ZYUg4uEntQUBQUAQSCwCQhCJnVoZmCAgCAgC8RAQgoiHn9QWBAQBQSCxCAhBJHZqZWCCgCAgCMRDQAgiHn5SWxAQBASBxCIgBJHYqZWBCQKCgCAQDwEhiHj4SW1BQBAQBBKLgBBEYqdWBiYICAKCQDwEhCDi4Se1BQFBQBBILAJCEImdWhmYICAICALxEBCCiIef1BYEBAFBILEICEEkdmplYIKAICAIxENACCIeflJbEBAEBIHEIiAEkdiplYEJAoKAIBAPASGIePhJbUFAEBAEEouAEERip1YGJggIAoJAPASEIOLhJ7UFAUFAEEgsAkIQiZ1aGZggIAgIAvEQEIKIh5/UFgQEAUEgsQgIQSR2amVggoAgIAjEQ0AIIh5+UlsQEAQEgcQiIASR2KmVgQkC9UEgk1mye5lT/QD+rtriSyb4kKFCfmN9epBW3q4ICEG8XWdG3isSAh9fsGzvFJvnUoWvKxbzv4tUeYYWbm/PzoGB00AYGSzkr/SCQQhihi4QAEIQM3fuEzHy1tbjtzdmjXweTOcBKMvJNnhas9ls0zPPG0cwm/8B0D8y4Uul/ty3hSCCsZtpJYQgZtqMJ2i86fQxu7LR/GsA+4noI/zEtme6rwDjzFoNIYjw2M20kkIQM23GEzReEX1MbTLbM93XgnGyEMTU8JtJtYQgZtJsJ2ysQhBTm9CoBDG1XqRWEhAQgkjCLM7QMQhBTG3ihSCmhttMrCUEMRNnPSFjFoKY2kQKQUwNt5lYSwhiJs56QsYsBDG1iRSCmBpuM7GWEETEWe/qyr5ra9lYBJinAvQxAHOrTZQB/IWY+k2Df7r3blzK5/MVr+a7urpSW8tzrwP4OFuZfEtq83F9fX2qrdBPuqP7EiZcMFGB17akts329V27xacRmt/Z8/cG+J8JOArAPgDmWOUJL4L5jwTqLY+M3rhhwy0vhn2Ztkz3F4nxrVp5Bo4qFXK/VP8/b97pzc1zXj6MwJ9zYPcagEcZfJM5Ur7Or7/Wzuw8A7QOwE5h3snef5jyYct0dZ0ye2v59S6Ajga4E6D3ANjOVv81gJ8EjHsYtGrv3Sv3+60Hv34Vbi0tr3wChOVMnAHwXgApAGp9PQ+gyMANo8M7/mrjxitHnW1Za3aUbgPhk6HGR7husD93Sq1sEBHPOzi7w6wtuAOgdK0OMS4tDuQuDNVftdDYN7HrTQCytvWzslTI/YtfO8ps96nnmg4kMk8B4xAbPqraJgIeAOH6WU18a19f/m9R3mmmlxWCCLkCLKeiFFaA6SuOjcCjBX6EDJxdXJ9XZpisK5TO9Cxj5p8BaFK/M/BUCpWuQmHN4yFfC52dx+1UweidALVW61SI6IRif+9qrzZaM9n9iOkqAtpC9FMmxhWVcvNFQ0M3vhpU3osg2jPZg8D4kbK7D2ijDKbLYJpfHRzMDzvLvtUEYfldpMoXgViZidoJIWBYwevB2YDa+J5+jroBfAfAnkHYA3gGoDMHC72329dcowlCvVe6s/tiBr468Y481ITmRYXCTS+FeG+rSGfn0veV0dRHwN7VOq+SyYcVi/lBjzYovSD7CTbxgxDrSjXxGoi/jjIu162tsO85k8oJQYSY7bauZftQubLatgmHqGUVqYBw2cgbO16gO9m1ti6fazRX7gHw4VqDzHRCaaD3xrAdtHV2H0yA2hBmVes8UTF44Yb1+Sd0G84zz9HZDPzH+G0hbEegx2HQsYPrV/+XXxUXQTAvJiL1watNbuyGEuJhwh2jLXzcxnvyr9iLv5UE0b5g2Udh8s8Bfl+IIeiKlBn8pVIhf5nXoaFWqb09+3/QRGodHBaxrwoB39g6vOMltTU3LQSR7vkwG3wvgF2r7/u6yXzY0EC+EPb92zt6zgDxj2wkUxyZjcOda0D9rg5s1GR8g8HqdmEdsMI/PGSmKscO9d38dPg6M7OkEETAvKfTS97LRuoOmzNWrUYFjKeYUCLQqwzenoBOAHu5m6QrR4Z3WKEhCWrP9KwE8wrbRxFGPDRevK2z+/sEnFP7AwPXlAq50zQbELVnsueB6ZuaD0qJQ34PGA9a7RDvD8ZHNBv6ZhAfOdif3+AFm5MgAKwCcLStLUWairwGwLSVwPvy2E3GdRrXOXCNkTV/XrXHzNsQWeKx7avvMwLwWsD46/j7GfSjIFIL8+n7rANLtMjAb9Q6sOBTYyJ8DIydNW0HxjFSIpuWLZRnWOKSyY8l/sN6gF7wWXMVBn+xVMh/V1W2xGGjb6wA0d+PNWZ+Aqj9t/WHDW+KyibCk7C5YXAgf1Wt4yARkypn3bCbsAagRba1GCgeqpWtiuzyAB0xXt/Dw1uJ3GbNeeVygE/X4UOM3zJIrbEmBh9IwIeqIjl78YfILB9eLN78lzDzP1PLCEH4zLzHh1phxq1mE5+vOaVTa2b5/gaXrwLoQFvTkz5Ye5eaG8BzbNDC0vreh4MW5byu5e+eVS7fC9ABtg1y8WAh/ytn3XSmeykzbnBs+i8w0xdGt+yQc5LX2KkTalP5N0edB81UeZHX6UtDELVX8cStKr47vyq+U7L12vOgOdp08NDQqk06LMJsXEEYhvldycZHRne9ggmfmTyn+LE5MvpvHjoTast0p8kSq03cEK36RJcP9vcqUneJHq2+ynNXsqWnsT/8iMk45z174D67LsMSQz1PR4KhYintYqvxrMGVQwcG1vzBOcaoSuqwOGtuAA+MpFILN/atmiBsD8DbFvR8kEzrBrJ7tchmMmlhsdg7dmiZeDwOOnp8VLX584/Z2ZjV/O8EnOE4HN3VkuJjRS/h/RUIQfjsEJrNrgLmi/baA9/xV0BbiuwfAnyirfknUeGFg4P5P9m71Cn4wHTm4EDvj4M2r/bO7GEA3WYTL2k3VCuQnWneBeCDtjYfQoUXO9/H2WeVwJSooyY6ULvaN0qFnCIO1wbnQRBhcNN9+BVmXlIayP/irSSItFt84ouB/V0zmewuZcYvJ4snveXz6XS2nQ1SBF+7Fanm7kGFewYH8//rtSbaM9n5YFLGAOPz5EVEjSKI+Quy+zaZpDb5favvOfLmzerTpUJOiVF9n/bO7rMBXD5RiO9EBUudugIPEWMgPoqW2zLZk4nph/bbLBFOKfbnlB5QHg0CQhAey0KnHwA8RUWuVqqnlrV2RTABXysWchc7C2sUfGHETC7xlJfliPvjQ6CoyP6O6Uz3Ccy41nb68tRzaAmC+TaYWB6kGNTqZAgXlvpzl76VBOE+GcP3ZuMi2Y6e44ksY4Ta84SZKi/Q3MJcc8rAo0gZnyr1rf5z0A6mwV47T40iCJ1lHgOBYiateEqvi9OIZBFFVERtnd3qJnGRjYg89RxBeM+E34UgPGbZaWEEQHsD8Fsk7jZYe+XWnIoCxUyazVRr8aG7ofjdAHTjiXLL0d26/G4B9v50Zo5wmFxOPp1PT56CdLrnUDZ4CQAlNtyLGFdFMeHUzK9WD9Hent0TKeoD4/21cQYF0rPjoTnBV5jpyNJA7532co0iCNVHW0f2KCK6eeIwoV/zkw4g7hualth044t6A4hzy5kJhOAcoxCEftbVSUOZgZ46/qF6K389143GbE9r2aE7QQFYMVjI/cCrcc2HqD0Jhd2cgha/29cCWp8NjZlrJNNdVz9vA4IIwibo97BzoNFHecnhtV0qgt1S3vUGApQ/wkYw/56bjNVOfVYjCUJzcFGGA1q9WG0Q7kMF3dSS2nSy0x/IteYJf0KZuwYH888EzUHtd90hZCo+G2H7e6eXE4LQzKDGtwBMOLfUn1PmiaGfjo6jtjNptpILHzReyUO/oFHwaWWw1XbcBOZh8dHmEG8okQWPNi3wUvx6E1LPEiJeM/G7/mSouUH8p8FbjhwY+IVyhgt8XPVnEkFkur9ADMvyqPpEwi4Q3GqBRhKE6sJpWeevlHc58XnqnZyHBwLW/W2blmMeuPuG18OO3Xq/TPcFxLjEtpbDiHSjdJGYskIQWoJwOeyoUncBFMkkjsHNBHwKwB61brxOK5rbhufpUSOK8CyrOfk/y8BdBHJ53Pqvalbeu2os1uPl1Ofc4KN+xEkhCMtss/L6Acy0hBg9IMtTvfboRUzOMNyMn5UGcicF+UxE3Y0aTRCtHdlOgyxF+7bVd/PU2WhuV9qyWvEj+H8AQzmiRnxYmXDPtxFEZKe+iB2+Y4sLQWimLqozVqTZ9zgRe4Te0IqZNLoNzxOQczOI9K7+hbWbXJQNXtd8lPphzS/rOOZJTVmZ2Z4p72waLfuBeU8QzyfwgSD6Bw8fCD+CoLaO7uuJcILtMPHT4kDus/V+/0YThEZn5SlmchpoeCm1Izv7RQPtsRSVM/39Nz8XrVrySwtBvE0IQr2GRq/gEjNpLUV8vK+FIOr7EauNaksFx4Lp8x4OWGE6dJGrbgOMoqAO02mtTKMJwlrLjphcOjGThkg8va+FIKLMcP3KCkG8jQhCo+BziY40VhieJqdqaEIQ9flYbHGRvu9wSAvqoAzG0yBLzFgLh5J4gtD4jrhER26fD/Y0ORWCCFpmjfldCCIcQQSGR6jT9Ljt4B3KZ6fSGdBbfHidFv3MRusxhigioneKiMkK7bDNy5eC8YWAuD/DAD/NoI0GqJ+D1F7DAAAJcklEQVS4/J9btuz8aGrOSwc4ItBqCMIdyZQY70gRk3UwcYfecCmfNUpnrZ+Qam86b1j1+A6S0oYQhGYm0+nsR2DQOgbeXf1Za0/eiEXgUvAx7mtp5sUqHIBGURdoQpju6P6JPUREVKVx1DEmkSDaOrI9RHS97QagYCmD+D426SaTaHCb1JwnvcKrhzVzdYl+3qFK6tqa0VjQjccJ01gK+pr0HnDoidu+642tt9jjUzWKQKOu+SSXF4LQ3SBal8+l5sp6Aj5Q+7lR8mBn9xq57PhpUxOvJtCjt81pOjkF2/EoH0DSCELrJAg8SyYf6xOGehJkYQnCbX6JyGaubZ3dRxLhGjA/D6L7VWC/ltTm6+0+BdOhg1AAuMShtrXn9vnQh9awA+k87MB2eIqyRqVseASEIDRY6SJLAsEL2NmU0ilQc+UuAnYi4I8m8LBh8jXFYn4icqbuBuOIrV8jJ6evRJgwBhrnq8Bbh275WOE6CF+zbTy/QYWvdobPSBpBaEw2K1G9d9s6nD4k0FuAdfQsImLlN1MLXx3oUe+cqzAOjdNFEBqDinExk8tXIkT8MU3Ik0iOhFWsamJclZToaRXFltlcN7v5hTVRE3WF32bfuSWFIDzmThO/6FWDjSMGBlb3h51uTQyjUMHL3Ao+lSEOy7eW6Wpbtq1Q8fZ18Y2IqHfrGzucqMtRoRubLq6UCquty1qXNIJw63wQddPWxQ/SEoTGAEFNh69HvX2+woZEmS6CUO/mDCipDjUppC62J7kKmygrTtDEGk7t7dn3o8kKKKgyAFpPmINW2G8+aeWEIDxmtKNj6YdMarp7kpMbsG7rbM7qEpi4bg9dS/YyyikVA2c8GRCA31ZGRg8NSuHpVPCpD8gw6TMqlelEti1viw/Hu1B7pvu7YKgcCrVnmAgnFvtzNs9o76Xd1pk9l0Dftp1sVXTWM+w5A2q1k0YQzlMrAX+FyYcE3QJreHR0LMuYZK51RGfVEoRHsLvwwfrGbioq/0bNWkp7wp5OgnAfUHiIGZcSkUotWnWk8ze0sG3uc2BgFYgW21Zr6MCTHqHUhxnG4aXC6r6kbe71GI8QhDeKuo1VRQ2+oSVlnuUXQ97KdmXQSlf+AMaK0kDOljHLu3PNdVp9+Cr95Fh6Uo/QGroWdWQHYDMDxweFYm5fsCwN07zFEe77vw1z9NBi8ZbNzv7eYoIIdauK8uG0ucU+APOXBwfyKu+2NpVsrf2qGefP7YeM6m8vk0mHFou9v3G+iy7ctzIsCDqYVE/GKvT7frU2lRJ3VvPmzzlFJ06CCIpFFNch0SFOepkI65mtRE/q8Q3p7jp4dWQPMcgKcT+endCKeGvQ0QE5VKitI9tNRNdMym8SMtJwlDWTpLJCED6z2aq/Bah94X5G04pSYbXKrDZpk/DK9xzmI7e/ioe4oVYksuxVcwtQbQ0z8C0ebb7MmW/aJwe37+1jOglCkzAJalNkk88JCi0e9iP2mIdhFbqdK7xS14/Kv9Fs8pcZrLyg7QmQxrtl4KhSIaf0Dc7H42DC95uUOm2of9Xv7WtuzD9DZZ4jlQFuPKQLAM+EQS75P+CbGyQuQXjkuKiNO9DQwg6Qd0IlvATm82HiJlcOidbjt29KjX6DCSoJk30+Qt8+wq6XpJUTggiYUW0ilvEj2kT6RxC3wMRBjpg71ZIqn7N59OD6vPq4Qz0eoTeqdaMrzH3TNAJlBv5AoPutPNpjOZc7NClHKwz8v9mpzRd5KfSmkyD0xgQWRK+plJzqPwjmxcVCXmXSm+qjySEw3tTkVK1gldFNRVKd6+jsBQa2TIgH1SWElpYGelVYbNfjm3IUeJqBwlh6U94FhAWasB6+JK65nap3UKlTnwWoTIz1s5rnfK5mthuXIDwswcbG7ZNdz2vCAvAZBuF3YKp+a+Y/ATRPQ9TDTPyvpf78FVNdGDOhnhBEiFmOl6xekQMdO5W8yO7QGzV+CJdxzjm0CA5fOlRULunLRt7Y8QI/5fZ0EoR6ybaO7jOJrExk2sT1QeKTENMPtSE1b6WbiHF4mPKTy3A/p5pOMkbNC+0iR/ZJhKTqj22qpNKIKrFilEdtfGeV+vPXeYnAPESOtj4mZ7yLSxDWPDlDb4z1Fspow4tEp4iPam4YwPmDhZzKLucrJowCfBLLCkGEnNXW1uO3p+bRrxOgxAbj8k+f6uokdkWl3HyRU3wTskvos9rBN7RGiLYpvSD7CTZJhYywK9B9qvIjZODs4vq8ipzp+0FNN0FYHrbu9K72sWjzVoTAaVIRKwZTmS4h4CwvsZGjzceYccHee/AalZ7WdWoPYcMfNbwHAyUmPm2oP/9QwPh06TfHqzitiupBEDoLJCC0oYV2ODZ8vgNgzzBzGgGjMM0lvowQRMQptq63W60k8SfxmEJwN9vpddObeagfA+Pqymj51iBrpTBdu+XF4Sw+gtq2Pq5N2A+mcRpgHgyQMvvbrlrPChkBonuZjWv33r1yv18Obntf000Qqm8rqurzdDQznwvQ/rZxKD6rayhnK793pfIZEH0aY46UNszwZ4DuZtAqJ2aaDTK02bS6+TXPefkwAlSOcyXCqq25ChhPEahPWbjtvRuXws6Twk3pywwmlX7zkw6x2CRlfz0IQicO9ErBG7R2nb8rfFKzX2ptgnEak9kB0F62Q5wSAz7JoLUm6OoNhd7/CTrkRO0/yeWFIJI8uzI2QUAQEARiICAEEQM8qSoICAKCQJIREIJI8uzK2AQBQUAQiIGAEEQM8KSqICAICAJJRkAIIsmzK2MTBAQBQSAGAkIQMcCTqoKAICAIJBkBIYgkz66MTRAQBASBGAgIQcQAT6oKAoKAIJBkBIQgkjy7MjZBQBAQBGIgIAQRAzypKggIAoJAkhEQgkjy7MrYBAFBQBCIgYAQRAzwpKogIAgIAklGQAgiybMrYxMEBAFBIAYCQhAxwJOqgoAgIAgkGQEhiCTProxNEBAEBIEYCAhBxABPqgoCgoAgkGQEhCCSPLsyNkFAEBAEYiAgBBEDPKkqCAgCgkCSERCCSPLsytgEAUFAEIiBgBBEDPCkqiAgCAgCSUZACCLJsytjEwQEAUEgBgJCEDHAk6qCgCAgCCQZASGIJM+ujE0QEAQEgRgICEHEAE+qCgKCgCCQZASEIJI8uzI2QUAQEARiICAEEQM8qSoICAKCQJIREIJI8uzK2AQBQUAQiIGAEEQM8KSqICAICAJJRuD/Awi3JiXVPgeVAAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-28"><g><path d="M 371 401 L 371 444.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 449.88 L 367.5 442.88 L 371 444.63 L 374.5 442.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-43"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 412px; margin-left: 382px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="375.5" y="406" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-57"><g><path d="M 321 351 L 107.37 351" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 102.12 351 L 109.12 347.5 L 107.37 351 L 109.12 354.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-58"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 362px; margin-left: 312px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="303" y="356" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-16"><g><path d="M 371 301 L 421 351 L 371 401 L 321 351 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 351px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">IRQ other <br />than ACPI SCI active</div></div></div></foreignObject><image x="322" y="330" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfQmYXFWV/++8qupOQAUGZd9c/4IbGkl3dXeF1rAEBAKB6k6AGBQV1Awq4wqM4Ci4jaIMCiIoyJauIkAQZRXbdG0dzAwyDCKDoLImyBCIZOmq986fW13VeV11X733auuq1Hnfx/eRfnc593df3d+9556FII8gIAgIAoKAIKBBgAQVQUAQEAQEAUFAh4AQhHwXgoAgIAgIAloEhCDkwxAEBAFBQBAQgpBvQBAQBAQBQcA7AnKC8I6VlBQEBAFBoKMQEILoqOmWwQoCgoAg4B0BIQjvWElJQUAQEAQ6CgEhiI6abhmsICAICALeERCC8I5VQ0r2Roa+SIxv2xr/c5BykbGxm5/VdTg4GH3N1iytAuGDNQpkAniu8F8G4Nu7gzuOjo5evaXGdqdVnzPnE6FZs16aw4Qogw8F4QAwdp0qRHgBjL8Q6HfEiG/ZstPatWuvyNZThnZvKxJZtGeOg2MA3lwYy4sW+PDxRHxtu49N5G9tBIQgZnh+ZpAgdCPfCOKvI4dL0+n45lqgKSxq5wL4KIDZPtrawMBVIcp9z4kkfbTV0kXD4ehsGDgdhIl0In6Fk7BCEC09jdu1cEIQMzy9LUYQeTSY8OtsN5+89t74S37hUYseB+h8As7ySQylXdWNrPyOodHlo9Fo4OnnjGOYrW8B9HYmfCkzFvuOEESjkZf2/SIgBOEXsTqXrxNBbAToeX+i8RsAvNa5Dl0xsXmn5X7UPb2Diw+gnLkCoJ4KsqiTyXMA8WQZNzl4nIOBxZnRFX/xN77WLR2ODF0GxplFCYUgWneuOl0yIYgZ/gLqQhCEa9JjsdP8DmXOYdGdQltxAjGdZ9NvF5sxiejU1NjICi/thuctfi8svgngN5WX50eY8O1sIHj72tEb/176vqdnye5G0DoeZH1W7ajL69PjMOik9OoV/+VFllYvE44MXQ3GMiGIVp8pkU8IYoa/gZkkiOLQ8xffOePHAC+dDgenJmbhaDdVU1/fov3ZCP4awEElcD4D8On77Il74vG4uhSv+CjVy1PP0hCAHwJQJxz78zBZuaNTqZv/6tZOq78Xgmj1GRL5iggIQczwt9AKBKEgmDv3hF2NrtDtBPTaIHmZLF6QSsXTTjAVLlpvBNHCEnIZzQWx5P7RuLKU8vU4qqqYV8HCklov0H0J04DCQhANAFWabAgCQhANgdV7o61CEEri3v7hU4j4umnSM52ZTo78xGlEfZGhU5lxNYCAbddxz9ZZHHU7eVRCyeFUYhLhtNRYbLqM3uFuiZJCEC0xDSKEBwSEIDyA1MgirUQQPQPROQbonldVPLsUx1zpArWv74TdLCN0NwHvsWH0N5g8P52OP1YrbuFIdC6Yfglgtyl5gD8YVvaIVOqW9bW2P1P1hSBmCnnp1y8CQhB+Eatz+bYmiMjwYub8iaN4ejCZsTyTjF1eJ5iod2Do3whQl+jFx9flebVyqPuQJ58NvJ/IOg2MwwHsDyCYby/v3Md/ItCImQ2MjI/fuK5SP76dG0uMDtz8IPLvEThVqd9A+Uv+ot+Jkus+Bn627578Wy/3QLpxVMQCWEfAgyD8oivAt46Oxv/hBXMNJlMOoj2R6EFG3nmU5ufHMon3GgZdlt28851+LOu8yCJlnBEQgpjhr6OlCKI/OmAQ3QlgR7cTxODgabO25l6JA3SMDcKHrGzgMLcF0w/k4XD0LQjQbwDst60e3wETJzbiLiK/GD5DJxLhIo1ll070HBGtzBJ94f7VK57UFWgUQcwO4k9bcnQhAZ+aIi9HcPkRsowPp1Ij9/vAn/rmRT/AFn6kty4ra8mz74qOIGDyoQjQ8a9+f9919KFxUXn6GJsU9YCAEIQHkBpZpIUIQrtbZ6ZjM8mRO0ox6J03fCBZrBbuPafIBLgkk4h9pp54DQ4OBrfmdr8G4JNt7T7LBs3PrB75Y337ir5mS44uIeDD9jsVj308QwYvTa2O31davhEEAcJHwfxlF5+TUlE2MtNpmeTIzW5jUsYHFDC+wWA1n1P3S271Jt/zuBU0Txofvfkpp/I6giDgEga+VcHB8gnT4PlrVsef8CaHlKoVASGIWhGssX6rEIRO3w/CY8jxYDodf7qMIPqHFxHxStvfTScyqREi7eU5M53oZaHz2rfyCeneQnFGXp1UtrASkGHQEyDuBtAPxhs1C6d2Ac6ftrKbloPorZMNWx8Aiv+f/8MagB6Y6pStNelk/KrivzUqpgkQNk6LaQVsBuEBMP13JRkZeBRB48hKjocqflbX7JcuBfgTZUgQXiDGf+axAAIMfj8B79CcYCqaJWsIYgLAVpvz5noG7iPQK4DVmz/BEF2WHhtRHvoFJ0uvsyvlqkVACKJa5OpUrxUIoq9v+BA2sKLUyY2Ar6USsQt0Q+3rH7qQCefY3jVkV6/a7+uLHgyD7mHg9cX+iHFRKhlTsZ5qftQpZSK3+yUM/mRJY88w0z/vu5e1qlR/f8i8xfsGTOtiIiiViH2HvR6GsaCSU18dLqntYjqqdQq6/GsAer+9QqV5VTcs4Uj082D65vRx8SMW46z99sJ9pVgUTKTVXdEZJVjc1R3kk3T3EhVOVSaBfsimdZ5dhajwhmFmqzGbrvkD6eAGhCBmePJngiDUjnZi4uXdEQhGWDnHManIsJMXsIWHAEdT1Um1z243AIhuq8EPTgSD83We0rVCrDytKWSuJuBttrbi3cH1J4+OjuZqbr8/erhBtGq6asNdTZJfTAeGlP5/us7cxV+jjgSxHsTHpsfia5ww0JoLM+7rDvFC3cKts2QDcC9MHk6n4/9XAWvqjUSXEdOPbTg6miU7EQQDP89u3vkMuYiu9auuT30hiPrgWHUrdSGIqnvXV+S8KWluoZPXsvbHXWHRqVW8RvbncMfhx1RXd3ez2WJeOJ6MK5PhsqdOBDHBzB/OJOMjbviGB4Y+DeBSW7knrGBunuaOgMKR4UvAvNxW1o8HuwYLvTe+A0G4Oma6jVXe1xcBIYj64um7tRYjiBxAMZjWP1faLQ4MnLyLiewd0y5I25QgdJftAJanE7EfeZ3MfCypkHkvgHcW66idcCYRO12nL68PQXgLg6LkmVQh8t0Adi7Ip80nMXde9I0BK28xpu5X1OPbMVHTxgQDH8okYgqfqUdPEDweQOioROKGF71iL+Uai4AQRGPxdW29RQhiPQg3Gxb/IJmM/8lNaM2lqbo2dFRbuLXn9t5hMamLSqvUe5yBJ4MwBxOJlY+7yWV/X34n46xyqwdB+LmD0czXBrLoiFKT197+6HFEpCycJu9UKhgpOGGjUz/qZNXNKTOuyyRjyoJMLqH9fHwNLCsE0UBwvTRdJ4KoEO6b1d3CXhork00E/Fs2yNfcPxpXDlWef5RzBpe8viuX+w1A754aY9MJAr8zeMuxyeRtG73g7FSmr3/op0z42Lb3+cx6Ub+Z9XoHhg4j4FcAuirt0tW7ehCEHysuHaEzcFwmEVNe6lNPKcmpe6h/7NB9woN3X/uKH4x7I0PnEOPCSphqCcIlL4YfGaRsfRAQgqgPjlW3UheCcAn3nTdb3GHDh8D8zRKHJxVh9fLuIH/ZqwesGmgj7wR0QDaqP52zH1fpyzEwcOKbcgiMErBvcQy6RbhuBKFZ4J0+Qi8E4WB48L+A8Vv/HzcfrOI/2giiTHWkP0HQqZnkyPX++5MajUJACKJRyHpstxkEURRF2fp3bSGV2lKF1LY97Cvy6vZixVTPXayXRbgIeB1OEL5yUnuRzbczn8fvu1CsLM+6FnsfpOeveyldLQJCENUiV6d6zSQIJbKTQ1gls1bdUHsHhn5YSCtafN1UP4hqd/r2sTScIBxUJkIQ+lOo04mrTj81aaYKBIQgqgCtnlWaTRB5FYc2vpF64z3NqCY0uMnMizLJ+G31xEe11VvutQ3m2tURDScIBxmFIIQg6v0baVR7QhCNQtZjuzNBEJOLbnSYiH5hu1RVf95MhKWpsZg9hIZ2JFrzUKJLGxAKQdnWX0XAR2yC1OW00nCCcFCZtAtBuOXK9viJa4uJiqkW9JpXVwiieVjrF9rI0BcpH9p46inT17qpRVBFTmp1cR2aveEnJQuvMmVyjdWj5HGI5lr3YGoau3plcFWXaK71vKTWEKZjbKpWJIh3H7F0x9ds2nqLPRYVMa5MJWMfb8RPRAiiEajWv00hiPpj6qvFmTpBVFI1EeiyruC6s9zCWPSV54OAn11nb//QmUR8GhFd6pBLQOelrET35chWaUJK71KqNu3sHz6KiJXZaN6HgIC/w+LDU6n4tiB8BUFakSCUaGUmv002XZY7CF9LR1MKC0E0BWbnTmaSICZVTWqRzodhsAecqxgqojgahzzWrvGBCuQ0GwGsBOioQnsbCPiemQ1dMj5+/cv5Mk3IKNemjnJ1t2LK490/fAaI7cme1pNF81OpkYd8/EyK4TpUnK6nVJRaZuueWaHnV9o3HHKC8IHoDBYVgphB8PML9AypmIrDzv9Qc3QTgCOnQ8GjE7NwvFteaf1dhnugu76+aJiNfHKi103vlx4HWR8l0/wLG8FfAzjI9t536Ae36dXmtfDpsKUijQYt6y4ABxb7a3CojYYQRF/f8DvZyOf4sKd4/UYmEfuqV0dKnQGEzuJMCMLty2yN90IQMzwPM00Qavj9/YsjFlm3lyzWJoO/mEnEv18JIqe7DJU0hoOBxU55B/KZ256jXmL8K4DDSk4wKkLrplLyIKKRrZt2WlrPSJ8NCtY3AfDCdCKuCLDsaVUVk0oSBAM3gmihTWhPJ0JV3iFs+maGcXQmsWLUDoQQxAwvPB67F4LwCFSjirUCQUzmABj6PhifLRmnp6im2pDSkw09D+Az++zJsUr5kFXeAmJSlkq9FXD2E1XU13T1aMJ9u0W0LXSgD/cNOOZBUPVKCcItrpJbTmq3wXpxlCu24YDFozDoeJcMftTbHx0iop9PC5vuEPpcCMJt1lrjvRDEDM9DixAEegcXH4CcdVdJzgVl1eQpPn8FklDaiUeY8O1sIHi7Ll9EPhpqMBclovPtSYFs6ppH2TCPGV+98n8bMV0VEgY5EpxadE0Ev8uMxWUJg1xyNGicDB+GyQvT6fhjuvE1kyAqYPEimL8ACzeU5gLv6TnldYFg9htMUAmX7HlFHE8fQhCN+JLr36YQRP0x9dViqxCEErqWC2tV/5DB6B6hHP3CIW1nEZfNAJ4DiKFsnoA9KuQgLtYxmXGrGTA+d//qFU/6Athj4TqlHPXkR6K5DFZSKrXaMwDliLG6KzT7k8WAgc0kCCWICxbbUpvmsbXeA9AcTTDIzUz8L5mx+GW6KRCC8PhhznAxIYgZnoBWIginC2sGMtZE9pg1a255wQ2uvB47iOVgUncLr3Ur7/O9Y3pNn+1oixdiVakFTcWqslt1eWn+eWZalkmO3OFWuL//xHdYFFD5GVSUXc0zPS9CswmiSBL6uF1uo8u/V5uAL6QTMZVdThslWAjCE44zXkgIYoanoJUIQkFRy4W1HcqCCewXCnmKi4lqvKC9EUTXWIHst41c8IhXk9z8QEM0T4P5/O4QRvxEofXSubo8f+pZUgSh0oju7aFOjkA/3Ro0vuoj3aouPedUV6U5KWaCIJQwVWCh2CDDxKePj8UfroSdEISHL6sFighBzPAktBpBVLiwfsZg84hkcuX/+IFMWTnNmvXSHCZEGXwoCAeAsautDZWL4ikC/Y4Y8S1bdlprt1JSJqQB07qYCMeX7OpNIjo1NTaywo88Xssqubu7X/oACEuYOAJgf5saZR0BDzLziJnN3erlZKXrV13OG0znAVA5wXe3lXnFYl4wnown1N9miiCK8igsgrNe7AnAOJ3J6gdoH5tacCPAf2PQ7RboZ2sSI+qeyDW3iBCE1y9xZssJQcws/tK7NwSob170A2zRD4tpPf2ovbx1IaUEAUGgFAEhCPkm2gaBou8EgHNg4ZeZZMzu9ds24xBBBYF2QUAIol1mSuQUBAQBQaDJCAhBNBlw6U4QEAQEgXZBQAiiXWZK5BQEBAFBoMkICEE0GXDpThAQBASBdkFACKJdZkrkFAQEAUGgyQgIQTQZcOlOEBAEBIF2QUAIol1mSuQUBAQBQaDJCAhBNBlw6U4QEAQEgXZBQAiiXWZK5BQEBAFBoMkICEE0GXDpThAQBASBdkFACKJdZkrkFAQEAUGgyQgIQTQZcOlOEBAEBIF2QUAIol1mSuQUBAQBQaDJCAhBNBlw6U4QEAQEgXZBQAiiXWZK5BQEBAFBoMkICEE0GXDpThAQBASBdkFACKJdZkrkFAQEAUGgyQgIQTQZcOlOEBAEBIF2QUAIol1mSuQUBAQBQaDJCHQEQfQODB1LwG1T2DLu6w7xwtHR+D+ajLd0B2BwcDC4Nbf7NQCfbAeEgK+lErELmgHS3Lkn7BrsDh3FjOMAvB/AHgBmF/rOAXgGwFow/8rKBW8fH79xnV+5yr47vw0AmwE8B/CzYNxrEW7bb088EI/HTa9N9UaGvkiMb9vK/zlIucjY2M3Pem2jlnJz5nwi1L3jixG2jOMA6zCA9gPw2qk2CS+A+TmAEgz8KjuLV6+9N/5SLX061S2ThWgPMHa1lV8H8J8V1hwwVuy7u/WoH6yL7UQii/bMcXAMwJuLf2PClzJjse80YlyNbLOtCSIcjs6GgdNBmEgn4lc4ASUE0chPyH/bfX3D72SDfwNgt5LaD1nZwGHVLMZepIhGo4Gn1+FQy6ILCTgEQMBLPQBqQb7XIj57fCz+sMc6qANB6Lp6GsAX9tmTY14Wr5kiiJ6eU15nBHPngfjMaYTgDl6OGasC4HOTyfif3Iu7l5g7L/rGgGWcW9iQFDcB7hWBPzPjnH334pVesBaC8AJpE8rkf+jPGccwW98C6O1u7CwE0YRJ8dFFeGDo0wAu1VQxiejU1NjICh/NeSraE4keRExXEdDrqYK+UA5MF8Oyzk+n42p3X/FpEEEU+4xNzOJPuO22Z4AgKDww/CGAfwbgDW4YVXifA/HXkcN3vWCta0eRVCCY/QYTPgkgWL0sPMbBwIczoyv+4qUNOUF4QamBZcKRocvAUDuT/CME0UCw69z0nMOiO3Vtwa8B6is0nQVgbNvN8x0wcWK1i4JGXLVgLQVYEdI21UZ5wXUAvVL4onYEsHuFod8Jk09Jp+P/VwmeBhMEALpiYvNOy9euvUJhqH2aTBDUG4kuI6Yf29R1NX1BxLiSLT7L7/fQO2/4QLI4BuCdFQTYCNDzhTlXBLJXBSJ5hiw+KZWKp90GJAThhlCD34cjQ1eDsUwIosFAN6D5nv7ogEF0JwC1CIOIRpitAwF6d6G7l8niBV5+iB7Eo3Ak+nkwfVOjTtoAwtVMdIVO1zw4eNqsbHbLIRZZqq46dUxTRxFwz9ZZHK20g9cRBAPHZRKxX3qQHUpn3tX14m4UNCLM1vnqtFxSzyTCaamx2HWtQBDhSHQumNTYSlWHTxNwOSy6tatr61Ojo7duKMo7OBh9zcSEcQAMPp6R3/TtXTYW5q+kk3F1j8JecKsgR44JdxPzf3QHdxwdHb16i729vGbiaeMANvhzAD6qIbn1ID42PRZfU0kOIQgvs9TAMkIQDQS3sU1TODJ8CZiXF7shwlKL8UECPjL1tzpdVvdFhk5kxrUlP3STgZ9wNvSV8fHrX/YwXOrtjx5LRFcD2GVaecIP0mOxs50WrloJwt6Xum8jgy5hwsfsf2fgD4aVPSKVumW9bizNOkEU7gNvBNFCmxwmmC+EhW95OQHkF+hn6dMMfKtkzl60wIePJ+Jr3earr2/R/mwEfw3goOll+fcWYZnXO6TewcUHUM5cAVCPH7xVWSEIt1lq8HshiAYD3KDme3qW7G6EzHttx/78D58YexPRzbZdes2X1eF5i98Ly1InFftudjMTfyozFr/G6260CIXDrvRlg41jkskVymKl7KknQajGlXquewvFGTjcvggz86JMMr7NSs/2slkE0dcXDbORPxm+rtg9A9/IJGJf9Yl1UU115bRTG9Gl6bGRsyq1pU4jW3N0E4Ajp08GXdsdtD7l12rRAW91jKk4LiGIBi0gXpsVgvCKVGuV64sML2ZmpQ4pqGt4PIDQUaaZ3QFBGgXjLQWJa7qsdtrNEuisVGLkMp8L1hSIfZGhU5mhThLb1E3Mq2BhiW6HXG+CUIKEB6ILAFoFoMu2EF+SScQ+M5MniN7I0OeI8X2bDFWTvHb+CI8hx4PpdFxZcWmf3v6hM4nyxg9T80OE27oCfIpfcpjaGISjb0GAlMWdMs8tPs8YbB6RTK78H50gQhAzvO4IQczwBFTR/aTvw243AIhqFjbqHRhSFkZTaiag+stqh0X059nNO59R6ULXbVj5HWqWVoHwQVtZxzuTRhDEnMElr+/K5X5ju7NRmnlHv55mnSBKf5MA4t3B9SePjo4qnxLfT/lmAhvIoiNSqZH7dY1pTqdqp/8ogsaRXq2PHImn3JcElXx2hCB8T3dtFRx+mM6NEq5Jj8VOKxZwMXOlnoHo+wyij8HCAhD2LexAcgA/xqBVZPKV6XT8sSpHQb2Di/dHzlxkgBbwpG5UOWUVdznKxv45Ah5m5hEzm7t1zZpbXnDrS4PJNAco5QhmdAWXEUg5o73NZsGjnIH+k0GXZTfvfGctC6abjPb3Gt+HCQY+lEnElMpJtzOu6rLawQlvPVk0P5UaeciPzLqymoXLcbFoBEHofwuTJ7FE4oYXS2WeKYJgxnWZZOzD1Z7WClZIauduKOsyBucCbHzMSZ2nmxcAy9OJ2I9qnfNJP4r8KeKN29ri1MQsHK0zUhCCqBVxn/UbRRCbcsZeBvgaD7bxSuVxE+esT7mZNtqGRn3zhiJs8fcAUp66Xp8cMS4zc6HzKl2iOhHEpk2v/3vXrA2fAUHpfiuZdSp5ngfoo+nEyK+q/SF7HZRmoZqmgnDYATqqThx3e5PmjerHvKetTE27WXtfk3LmVhHoZWZaSYx7997b+ovOkap5BAFH7+hmEURf/9BPSy7Qq1Yxef2miuWUxdnW3CtxgI4p/o2BJ4MwBxOJlY/7bU9TXplKX8zgQYPxKzZ4VXdgxwdLraCK9YQg6oC4nyYaQRBk0E+ZWdlrT7dMqSDYpMVIbmEqdfNfK8mfN0/cYcNFYChzOa/eutOadOtLRxAwzWMQCHwNwJAPfHMM/lImEb+4USSh8X1Qx/+yxb93YOiHBKiLyOLje5Hp7R8+hSh/zzH1MNOpmeTI9T4wqUvRphFEC6iYNLibIP5Keiz+7436roqTNDBw4ptyCIwS8qf/4lO3TYHfj0EIwi9iNZbP7xCym5aD6K2TTVkfAIr/n//DGoAe2LYiWGvSyfhVxX9rVEwvgfKelXlb/PyTjwmD1ZOOM/wGEOaVxGnJF2PATZftbHs/GXfmT4Axqeog7gZzD0DqcrbM01M5CXWF1n9Sp8fVEMTTAD8I0FE2uDeD8ACY/lsRFYPfT8A7NH15NiOsZip7B4YOezW0hTqlFC9WX7GYF4wn4wl7e6U+EirEhV/P6tKdLAF/h8WHp1Lxbd9HNYOook4jCCIcju5dcqGvJHNcDJt1gtCrYZA/Deey2a95UZtWAXG+Sm//8FFErPwvpjZjTDg7MxZTm56mP0IQTYd8eoc1X1JPa44fIQOfTq2O/9a+01E22U89g2EQKasI+ymjom68ZyA6xwDdM70OPW6xdeZ+e+E+nSoiH7cmlPsKwJ8vWbwddecup6qNBFzYFeQflVpvHDJv8b4hy7qqxFRSeay5mhFWOe1lvg+AXn+rO2n4uax20M8/OBEMzl87euPfq5S/6mqNIAidrr1SJIFmEYTa7oT7o18C5Z0SSx8VNuM+sHHlxCzrbrfwIH4B14xx2v2W3/ZqLS8EUSuCNdavF0F48YbVOVtV+EFqFkP8DSbP93DJrbX/dlKPVCCI9TCME9KrV6ScYNbad3swI6xm2nQ73koLWt/A0AUMnG/ry/Nlte6HCfDt3cEdo0764mrG5LVOvQmir++E3SwjdDcB7/GKTxMJIu+nEdpKNxDjaBeMniImFfzw5mwwkK6VvDUWVM+yQfMzq0f+6HWu6llOCKKeaFbRVj0IwqsJXN4mO4CVdtWNk4WG1gTRhyXFwMDJu5jI3mH33mTCuZmx2EWlMDkQhMmM5Zlk7HI3WDWmoBXNCN3ac3qv2fFWtCjSnsA8nm60BFFi0VbtOKqpV0+CUCe/oGX+AqDB6QdgZz8MVa6ZBKH6U9/llhxdQoCyYPJ2/zap3r0PoHg1JwwNQTQ1pHnptyEEUc2vpY516kEQfnIP9EaGziHGhVNDcLgUDIej/0QB+hQD7wNwMAhmgM0j/VhSlH3sDgucliB8nAJ0F3t+4gR5mU6ddYmbykhHyAA8XVbryEXd46SSsY97kbfeZWokCJozuGTXUM48mAingvOGB6Whql9kGEdlEivGnWRvNkEU5KC+edEPsEU/dAmWpxNbhUK53yD+xt574E63MNu634Ha/HE2MK9RYePdvhMhCDeEGvy+DgShvSR1/JGVJhwCfmfwlmOTyds21nuoNRGED+ck7WnFRyA5L+PW5n1gOjOdHPlJpfrh/uEzQGw/BXm6rNYRhFukXy/jqLZMg6O5erISmiGCyEOm7vGefDbwfsA6g4CTPJhdl0DNj4BwZnos/junOdBulGY4IZgQRLW/mDrVqwNBPGEFc/PGR29+yotImh96w46wtRCEkzpKN0aHnZfnSKNecCu9T/Bqm643W3T3rLY5V23zgWgxFZMX3DyUUZe+5+yzB77vtsOeSYKwj6MYKdUyrIVEdBIYB3sMCV5xrPpTqrNfiAdsay4iBFEzhLU1UAeC8LXAN5ggqL9/8Z5sWB9kxikADp32w/GhYvJj2tdogtBbJNEN3cF1y9zCLzh4Q7teVrfDHURtX34+s13GIv6E56ikM5xy1GkpUNLrAAAYg0lEQVS8U6G1CYfB4GUuhFHxtCR3EDV+VRWqt2XK0ZoJwucRtB4EoRZk5bkdID4I4Lcy0/sKaS/3r5jtyg9B+FARNZogNL4PntRExW9VGzrB5bJapzZTlmr/2KH7hAfvvraQDKhxP6bSlmtWMRFeYM5f4K4xDNxlTgTu8atXb5UThBvqyrk0OOvFHjLoK8Q4Quer43Tf0tc/dCETzin2MZO+L0oGOUG4zXaD37cJQVBPJHogMX2eCMfpnO48wdSeBKEz9/U0XJdCT5gGz1+zOv6EXm1WHhBQOQ9uT34QfkFsF4Kwj6snsuTdBpvK870kG5z+BKrx4hY/CL8fikN5OUF4ANLvCUKZJAZM62IiHO/Z1G9SDpX0Rc3Jtly+bUgQDl61HpB2LeJ6Cmml3WSNVkyuYHgp0I4EocalS/zjdIel8cBXaYjFk9rLB+JSRgjCA4h+CGIyUQ3fBPCbXJpWUVX/TKCExTSaDRn3K4ehmi6pW0TF5BBZ0wPSXopUvqzWqLZQ71hM4YGhJQCfS0yrKgVu6wSCGBw8fuctuS5lAq7CqYRUpOIC3ioBVE2P5jvSngwc/I/qGotJGU6YbNxEMP7g5uAnKqaapr32yq2qYipczN5a5swEPM3AdYBxZzZID60dvVGF89bm1213gnDwY9isQpqr4FP+Z5/VacoelbbiZbXfWEV+5dFdoDvpvDuBIHSLMzEuSiVj5/rFtrS8zirNwVenLJ+IV4s5rzI6hDjRnlKEILyi2qByrUoQmo/IBOGnyPHZXnLyKrjanSC0vg8ePaF1n0t4YOjTQD5L2Lancnu6+4+6BSPUjs8htlQnEITWzNSnEYjTMtEzuGgfIxdcbc/D4OTMqU0SRfhSZiz2nVqXIYdNj+NGRQiiVsRrrN+KBOGQMS1jTWSP8RrJsr//uNdaNEtFpVSmrpNPm91BaGIp+XJK9LKLBFDxslqXH5mIRrZu2mlpjQmSKBwZ+j4Yny2RU5uYphMIQuGgmfPNFvPC8WRcBa2s+tHcLTiGg9GbVXuOg1ZRxp7+6OEG5dO82jzZnVWdQhBVT3l9KrYiQTh4JvtKeKPffU/PjldEsFYz1Vrr62ZSh4FT5FavX4KDT0TFewVlMtm9w0vXMvOwrR+TCKelxmLTckV4lSO/EEaGTmTGtSUOXn/MGcaR969e8WQZuZV74Cu9Yl2dEd3kb8YltY6QAR6dmIXja4jcqiHjyhZpupzhtW4MdJflACaYaUkmOaK9ZxGCcPsqG/y+FQnCQRfrOQ6Qw6LWVieIRh3zde26xnTKGwtYdwLYzfY5bmbmj2SS8ZjfJDbhSHQumNTpzt5exeCInXKCcPx2gZtg8hk+sjBOTZWOjN3ip+U3PTm6CcCR9iVIxeNii8/yquYt1tVGPVYvuXKARCGIBhOAW/OlBOF2KeaSk9qtO3ixYnr3EUt3fM2mrbfY8yz4ihgbJKW6UEHlpkXAdIocW+sJoNb6GtB0uv+65ILWn0zg5lntlLjJU0rX4vjyeUGepWUAfqCJJXRXd5BPKs25UazbKQShxjtpvVdGyGo1fYTI+PLee1i3u4UFybcTjs6mAJ1VCPluD07oKWy+A5Grk1uGiU/36oHu7IsBFU5/QXr1iv9yWjiEIFyX1MYW0KSmfBgmL3TKudAMgsirIMpzGagfyO8twjLdh1lITfohMH8ToLdrUXO48Kt1ga+1fqmsDond65aLQYuty+V3Ht/ZL10K8Cc02G4A4WomumLf3a1HSxcvdSIMmbljiPElh7l5mKzc0ZXSz3YSQRRUcB9nhkrjW5YdEQVLPiK+uTuQfXR09NYNhTnJR63tsvhtYGspGItfJeOdS+ZrMxGWpsZiK72sLA6qQFU1x4S7ifk/uoM7jpbmCFEX7tnslkNMw/qygze3JzmEILzMUgPLaKJ95icfwDMAqR3i6q7Q7E8WP4BmEUQ4HH0LAvQbAPuVDN8E40kmZFSy+/wpga33gfKkYN8lqVg7jwJ4sy09pzZybK0LfK31S6dXl5PYb7rQSp+M3nqo8mV1cUcKh9OZrb+pb2fyb2WmtdNEU/nCyeST3JJAdRpBKJOK3oHo5wj07YrhY/ytDdXkTKfwwPBJAKu0w3YT6dKe1wFUCMHCKv3w7hVE2wjQ6enEiFJhVTTXFoLwN8F1L93ff+I7LArcDWAvfeM8HkDoqETihhfV+2YRRL6v/uFFRHy1/9DG2MhEynY8aTDfxcDrC2PTRp6tdYGvtb4ddwczwIqWRn4/Cp2VWKENrQWRvX0XNZEfUZTZ8nXWROis8fHrFdFXfDqQIBQe1NMfPcwgUr8Bh9+nG3JT759n5n+u5s5ItVBBTeRZgELBhywKnDI+duODXioKQXhBqbFliuk51XG2NImKovcngzAHi4l6mkkQatjhSPRQMC53VBtNxybHwLWmYZyvLGE0l90mMy/KJOO32avVusDXWt8uSy1Z4Px8JnoPbfcw4MU+5s49YVejK/QFAs7QqDEqiZKPosow/iWTWLHGbQdZbKhDCSI/fPV9TeToowx8EcDefuYZwAYGfsLZ0EVeiLhS20rNGJr14iIiXODx92hv7mkAX4XJN/q54BaC8DnbjSreE4keZDCdB+CDJcfDabb3zSYINd78hzl7wwIClqrrCRWCwHYBvY6AB5l5xMzmbi3xkyi77NWZ6tW6wNda3z6nmvuBCYAXphNxZUVUt6enZ8nuRsi8tySIm9tldVn/am5mzXppDhOiDFY+J2pu7PNTUDlhLZh/ZeWCt/uNoqo67WSCKIKeTxq0zngbsXUMmML5TIuTWNs3dhsB/htg3EuGddvWV3YZq9FfRffNUe/g4v2RMxcZoAWvRjZ4i0aOfPgbMO7lgLFCdzfl5WMWgvCCkpQRBAQBQUAQaGsE2jJYX1sjLsILAoKAINAmCAhBtMlEiZiCgCAgCDQbASGIZiMu/QkCgoAg0CYICEG0yUSJmIKAICAINBsBIYhmIy79CQKCgCDQJggIQbTJRImYgoAgIAg0GwEhiGYjLv0JAoKAINAmCAhBtMlEiZiCgCAgCDQbASGIZiMu/QkCgoAg0CYICEG0yUSJmIKAICAINBsBIYhmIy79CQKCgCDQJggIQbTJRImYgoAgIAg0GwEhiGYjLv0JAoKAINAmCAhBtMlEiZiCgCAgCDQbASGIZiMu/QkCgoAg0CYICEG0yUSJmIKAICAINBsBIYhmIy79CQKCgCDQJggIQbTJRImYgoAgIAg0GwEhiGYjLv0JAoKAINAmCAhBtMlEiZiCgCAgCDQbASGIZiMu/QkCgoAg0CYICEG0yUSJmIKAICAINBsBIYhmIy79CQKCgCDQJggIQbTJRImYgoAgIAg0GwEhiGYjLv21FQK9kaEvEuPbU0ITrkmPxU5rq0GIsIJAlQgIQVQJnFRrbwQOmbd43yBbZ5PJ16RS8QecRiME0d7zLNLXhoAQRG34Se02Q6Cn55TXGV0TnwXT5wHkLPDh44n4WiGINptIEbcpCAhBNAVm6aQVEOjrO2E3NkK/BXBQQZ4XhSBaYWZEhlZFQAiiVWdG5Ko7ApHIoj1zHBwD8GYhiLrDKw1uhwgIQWyHkypD0iNQDUEIloJAJyMgBNHJs99hYxeC6LAJl+HWjIAQRM0QSgPtgoAQRLvMlMjZKggIQbTKTIgcDUdACKLhEEsH2xkCQhDb2YQ2YTjUO7h4f+TMRQZoAU9aBO0BIFDo2wTwHAEPM/OImc3dumbNLS9UK9fcuSfsGggFjyeiYQbeDWD3QlubAfwFoLstsq4YH4v/EQCX9tMzEJ1jgO4BsIsXGRg4LpOI/bJY1s0Poq8vGmaD7gTwukKdVyzmBePJeMJLf8UyAwMnvimHwCgB+xb+NsHAhzKJ2L2V2hkcjL5ma844CrA+AtD7bPjkAPyVmMYsg6/cdw/OxONxNTfyCAKeERCC8AxVxxekvnlDEbb4ewC93wcaOWJcZuZC542PX/+y13rKX4FC2a8T8HEAs13qmQCPcTDwkczoir/YyzaaIOYcFt2pawt+/SpR9RX7JcZFqWTsXK9jVeV6+4dPIeLrttXh1MQsHL323vhLunbC4ehsBLEcTP8K4LXuffEjZODTqdVxZeZbRqTu9aVEJyIgBNGJs+5zzHPmfCLUtcOGi8D4nO2k4KsVBv5gWLmFqdTNf3WrWNiV3wRgL7eyJe/XM3CKfdfdaIJQ/YcHhj4N4FLb4j4eQOioROKGF73IPzh42qytuVfiAB0zRTLA11KJ2AW6+r2Diw+gnLkCoB4v7dvKmCBcPLFp53PWrr0i67OuFO9ABIQgOnDSfQ6ZwpHo58H0zTJyILwA5j8BxkP5Nom7wdwD0FsABEv7IcaVXaH1nxwdHVXqD+0TjkTngkmpeHYrKaAWtycAJMG0lcBvZKBXs3teD8NYkF694r9U/cnFlD+rTiHMvAMRjrOpgyYAvh0w/j7Vl0GXF+vm63uIxdTXN/xONvg3Npk9qYeKffbOGz6QrHz9PQt/c3Tg6+tbtD8bwV/bnP2KzZhgPMmEDIFeZvDrCBgAsE850HTFxOadlgtJ+PwldGBxIYgOnHQ/Q9bvwOlxi60z99sL9+n02vlwFqHcVwBW4SzsRLGeLJqfSo1MEkrJ0zO4aB8jF7wDwDvtu15m3GoF+AtrVscVQUw9ef27SeeDoQhgWz/Mq2BhSTodV/cUU081l9ReCEJ3AmDgkkwi9hkvWIf7h88A8eXbyvIdMHFiqfxKndW9heIMHO4FH0XZPZEl7zI4d1WJWtBk8Bczifj3vcgnZToXASGIzp17LyOncGT4EjAvtxX+G0yen07HH3NpgHoj0WXEdKX95MFMp2aSI9fr6vYNDF3AwPn2xQ/M5+2zF75b4YJVd8JRJ4OF6URcXR43nCBUB32R4cXM+TuEwmU9PzgRDM5fO3rjttOJZtD5u4QAVgJ0lO318nQi9qPS4mVkBZge8EHhIvvHAC+tYh69fCdSZjtFQAhiO53YegxrzuCS13flcr8BSFkPFR/t4qXrb2Dg5F1MZO+w68qZcG5mLHZRafmeniW7GyFTWexMnR4Y+Hl2885nuKlC8gtgllaB8MFt7dIN3cF1y+zqrEadIFSfc+dF3xiwSKmJ3liQwZOaqVQ9xcCTQZiDicTKx+0Y6fABvKuKlDWY0RW6nSbVcvmHKtxz1OP7kTbaHwEhiPafw4aNIByO/hMF6FMMKPPJg0EwA2weWbp4VRIgHBm6GoxlU2Uc8in09kePI6KbbacN10B69n5Ld/AMPMrZwLzx8RvXFcs1kiDUets7MHQVAR8p9udFzVR+wV1ObKq98hMKvJ7kpmCq9pTTsA9MGm55BIQgWn6K2ltAzwQxMPRDAs7aNlq9Ht4JDeVHYML4FZTahej3BCQ5xyvT6fj/NYkgEB6ILgBoFYCuQp8PWdnAYXaSssuvOfmYRHRqamxkRck4deTz80widrofk1WNr0VVPhvt/UWK9H4QEILwg5aU9Y2AF4J49xFLd3zNpq232C9fnVRRvgWwVWjwCQIalZz2LqQoUpkBAOEx5HgwnY4/bR+ng6ru7MxY7GI/ePT3H/dai2YpC7FDp+oxnZlOjvzETztStnMQEILonLlu1kipv3/xnmxYH2TGKYXFaJujm0bFpFm4wUwnZpIjSuVUt6fRBKEE7esfupAJ50wJTXRpemxEnYzKnNPKLaT0ZTU7f9X8XQC5+pTYwWNwiIAj7f4l1Tj11W1CpKGWR0AIouWnqDUFVOqRTTljrwDxQQC/lZneR8AhAPbX+UBsWzDLczoXzFtX2y54TWY6NpMcUSavdXuaQhDloTe0aiaNB7bjpbZfZz9fgEmObV9wdVphIYhOm/Hqx0s9keiBxPT5vLMZY9eqmtIsSJoF0NcFtVc5mkEQmnsFrZqpPIYTO3pfC0F4nWEpV28EhCDqjeh22N4h8xbvGzCti4lwvM9QG+snrSnxhooniPKAem1LEGqcZZZJGjVTqc9HJZNTIYjt8EfVJkMSgmiTiZopMcPzFr8XFt8E8JtcZFj3qiPWnwmUsJhGsyHjfuUk5uWSWqNjb1sVk8KoLPRGyeWz5tL5ZbJ4QSoVT+swbtYJa6a+Mem3dREQgmjduZlxyQp68lsBGiwR5mkGrgOMO7NBemjt6I0qnLc2QqgXgtieLqkVToODg8Gtud1uABAt4GYy86JMMn6b+ndPf3TAoHyI8B0n31c26e3rix4Mg+5h4PXb2qv/Hc2Mf3AiQMshIATRclPSOgJpnLNUwLyfIsdnl8YJcpLaC0HozC+rMXPtHRj6GQFHAPxXBj0AGL/IJFaMF2Vrxh1EsS+N496U30Jvmc8HKnqnKy9qCpmrCXhbsX0mfCkzFvtO63wtIsn2iIAQxPY4q3UYk2YXrI4IGWsie4zXBEBau3sHq5m+/qGfMuFj20Tn27uDO0ZHR6/e4mU4Wl+BkrhPzSSIstAbBTXTRHdwa0n4kmfZoPmZ1SMq4ZH20QUDdDt16BoqEM1dBOxCwJ8s4I+GxT9PpeIPeMFYynQeAkIQnTfnnkasXXB9RChVnWjCYKsr62vSY7HTSoXQnFYqRn4tq19uXlq28DaTINTlfEmgw7wZKzNvma5eQrw7uP7kSiHQ1VjLQ3LgZYONY5LJFWOeJjQfrmPoVGZcbTM08BQvymv7Um77Q0AIYvub07qMSBeoT+VzSCVjKsOb66OSDHXv8NK1zDw8rbADQWiC3akTi8dgfYPBiexul5WcQMpCZjeZIMpCbyinNIWFzZHOKbRGGb79/Se+w6LA3dOc3IB7ts7iqFPWOXsjDqHU/9OcyB7h9UToOulSYLtDQAhiu5vS+gxIG/4CeBRB48jStJ6lPU6mw6Tvg/PpQou5qvPFmHFdJhn7sO5SWxvum/gr6bH4v1eIOUS9/dEhIvq5LTXpBDMtKfXE1hCEaywiL/kgnBAvJVmVVY+YLRC9N1/HIbSGQ3sUjgwpTFXuC9tD13YHrU+Njsb/4SSHmg8y6JLpBAqTGcszyZgtD0V9vh1pZftBQAhi+5nLuo9Es2Crdfr3FmHZ+Fj84dIOC6lJPwTmbwL0dq1AjPu6Q7xQt6D19Z2wm2WE7ibgPba6JgM/sSayXy3d6SqntC05+hcCzvOSMMjpVMQWn+V06V4LQagx6DEsjK5CGA4ddg6ngPycMALLM4kVa0qJtCcSPYiYVJTZqTDfk9zk/fRR9w9LGmwbBIQg2maqmi9oOBx9CwL5HAf7lfQ+Lb1l/pTA1vtAeVLYFndJRVZVpw7gzbYIp78zeMuxyeRtG3UjqpByNMfA/xDo95MRW/ldYBxc0p9q8mGyckfrcl/rL3vzUmwE6PnJhdO6IJWIX1uUrWaCKL8bKTZdMZCf42nAOSWrEv4FMFbnx6LSv1o4FIQDytuix2FYx6dXx/+7+V+V9NhOCAhBtNNszYCsvf3Di4hYXWy+1mf3G5noXJVD2mC+y2bD/4QVzM0bH735KcdF0Ltz3rQmVA4IGHR8JYug3v6hM4lwqZNHeGnwuloJQp/MSIntLeOclkSrxGeyLUUOdJI977bPeZXiHYSAEEQHTXa1Qw1HooeCcbmj2mh6w2qnf61pGOffv3rFkxq1zjSnMSeZVF7rQDD7DSZ8smLwv8kGcsS4zMyFzhsfv/7lSuN0SL9przLNqqhWglANayyQas7mpvChUPbrhPw9j/3U5jR8zxhV+51Ive0PASGI7W9OGzIidb8Qmr1hAQEqr3EfgD1su/B1BDzIzCNmNndryV1BWV5rIhrZummnpW6pRNVAVKrMYFfoFAYPg+j/2YIEbgbzIwB+mQsErlRk5HXg0Wg08PRzdDwznw3Qu6afjqYHzasHQfTOGz6QLFaquj0LMlYMreF1HKqc8nbv3krHgvFhBg4qnRcV/gSMn2nmxU83UrZDERCC6NCJl2ELAoKAIOCGgBCEG0LyXhAQBASBDkVACKJDJ16GLQgIAoKAGwJCEG4IyXtBQBAQBDoUASGIDp14GbYgIAgIAm4ICEG4ISTvBQFBQBDoUASEIDp04mXYgoAgIAi4ISAE4YaQvBcEBAFBoEMREILo0ImXYQsCgoAg4IaAEIQbQvJeEBAEBIEORUAIokMnXoYtCAgCgoAbAkIQbgjJe0FAEBAEOhQBIYgOnXgZtiAgCAgCbggIQbghJO8FAUFAEOhQBIQgOnTiZdiCgCAgCLghIAThhpC8FwQEAUGgQxEQgujQiZdhCwKCgCDghoAQhBtC8l4QEAQEgQ5FQAiiQydehi0ICAKCgBsCQhBuCMl7QUAQEAQ6FAEhiA6deBm2ICAICAJuCAhBuCEk7wUBQUAQ6FAEhCA6dOJl2IKAICAIuCEgBOGGkLwXBAQBQaBDEfj/6ItS8xKWbU8AAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-30"><g><path d="M 371 701 L 371 726 L 371 744.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 749.88 L 367.5 742.88 L 371 744.63 L 374.5 742.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-65"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 715px; margin-left: 382px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="375.5" y="709" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-36"><g><path d="M 321 651 L 257.37 651" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 252.12 651 L 259.12 647.5 L 257.37 651 L 259.12 654.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-45"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 662px; margin-left: 302px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="293" y="656" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-17"><g><path d="M 371 601 L 421 651 L 371 701 L 321 651 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 651px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">GPIO<br />IRQ shared<br />with SCI</div></div></div></foreignObject><image x="322" y="630" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tnXmcXFWZ93/Prep0B5SAIGGLiPpx3HUmQO+x2QMCgYTqJEAgyogoTFhGZARUVMBxUBl4WQQHJWzp7jJsRnax7a6tw2RkHERkQFCWLOokgNBb1X1eTnVV5/atc6vuvXW7uqry3L8gfZbnfJ9b53fP9hyCPEJACAgBISAENARIqAgBISAEhIAQ0BEQgZD3QggIASEgBLQERCDkxRACQkAICAERCHkHhIAQEAJCwD0BGUG4ZyUphYAQEAI7FAERiB3K3dJYISAEhIB7AiIQ7llJSiEgBITADkVABGKHcrc0VggIASHgnoAIhHtWktIlgfmHR+Y0jNACAj4DcAeI9gJjd0v2YQCbADwJpofTIXrgiYGel1wWPyVZZ+fivdMcHgTwfj/5AWQmbOFtAMUY+HlTmH/Z3x/9m9vymjsi8w3QowB2y+dh4PhUrO9nbsvQpZs//8yGpqbX5jMhwuBPg/DeKRwJfwXzJsB4jMHrmsI7xfr7bx0pp07JKwSsBEQg5H0IhEAkEgm9shmfZpO+BaAZQNhbwfwMMy4bH9nt7g0bbh53mzcAgdBVNczAj3i84WtDQ3e+XsqWoAVCtWmcw/9MwBkAdi1V/1ThpbsyhnnF+oHoCx7ySVIhoCUgAiEvRtkEmjsjHyGmWwhoKbsw8DNkGqclEr1PuClrmgQiVzX9AQadlBzo+XUxW4ISiNbWyGyEcQ6YvgbgnW7a75AmzcANTWG+xMtIqIz6JGudEhCBqFPHVqJZ2VHDRjqbgX8FMLtInbkpJeJsGuI5tikne9Y3ADojGev9KYCJPA7P9ApEttKnyUwfk0jc/UcnG4IQiIO6Ins1pOk2Bo4o0tw0gFcBSgOsfrt7leD+FBvUnRro/V0l3gepo/4IiEDUn08r0iI1Pz5rp21XgnE+gJCt0jQTHiHm/9cYRkz3FdvVtbJpfHzkIJPMcwAs1kxJDRNhRWKwb61ngSCsTg72rXQJguZ3Ld99lskfhGleCOA4e3uIqHf0rTkrnKa+yhWItrbF+5tG+D4CPqmx+RUQX2OYoTvj8Z6NdsGc37V8j4ZM+lhiXATQhzT5XzXYWBSP9/ynSx6STAhMEhCBkJfBDwFq7Yx8GUzfsXWmGWbca4b4Qi9z4ActWDYvbJrXvr1ofYLNmKfMcProof67X/Y0gvAmENaiqaU90k1EP7F9mQ+bzIuG4lG1EF3wlCMQakG/cYSimpHDViKsGn1r1143azJqNPfyRjX6oFsA7GMzsuQoyM9LIHnqn4AIRP37OPAWtrcv6zTJXAdgF0vhwwT8y7578/XRaFTtDPL0ZEcks1+7DuAzrRkZuDwV6/u601STdorJv0CoqrXix8BPUrE+tWhcMOXlVyCc2gzwEIdDy1L9PS96gghATVWF01gDUNcU5QMeHW3iyIbHoq95LVPS77gERCB2XN/7anlXV+Qdo+N0HwiHWgrIgPirycHo90qtGRSr1OFr+oWMwYc5jUimQSDQ3Lx8rtGQeQzAx7bby78ZC4cP29C/5i/2NvgViJb2yPFE1DN1tML96TCWP9EfVduAfT0OHDMM/koqFv2Br0Il0w5JQARih3S7/0a3dS5dxsx3WKeW1Nf1+PCuX3AzFVKq5ub2yBEG0X3WTpOZTk3Fe+/U5Z0OgVD1tHR0X0PAKkudW03wEUOx6IYgBEJ14rNG8ABAbZbytsAwFpbaNVWKofp7e/uSj5oUesQ23VRUbN2UK2l2LAIiEDuWv8tqbXYbZghrATraUtCrBmeOjMfX/raswnOZdXUw0DNvbz5VN3U1bQLR2f0VYnzX0qY3TeaFQ/FoLAiBaO2ILASyQjgrXx4TLkoN9v1bEByzIlfYBvXP5yRjfdcHVYeUU98ERCDq27+Btq6tLdLKBj00Ze2B6LrkYK/60i66HdWLIW2d3Z9n5nPBdCeH6N55c81nndY1KigQqoHa09Fep5i6urrCo+m5qwE+2cIl8K/73OL/wwA+vL0eTow14RhZi/DyRu64aUUgdlzfe255W3v3FUy42M1XtefCfWaooEAENsV08ILIASGTfgHggO3Nprsaw5tP7+/vV2cdAns0U2Wvk8kLE4loMrBKpKC6JSACUbeuDbZh+sVpHgqh4ehY7K6twdbmvrRpEghq6ehWJ8M/Ozn9A7wURqYrFlv7B7t1XkcQLR3dhxPwc+v0EpjOSsZ7b3LfcncpK1mXO4skVS0REIGoJW/NoK3NXYv3M9LhAetXb7Gtn5UydToEQvuFz3i8sYEX6Q79eRaIzu7ziWHdTeS4vlEux46OJe9LI9RPwLzJssrbBlyuSZK/hgiIQNSQs2bS1La2pQexwWpXzGTwuKAXVf20bxoEglo7u38AxnlWewj4ZiLWd5nORq8C0dbe/SMm/KOb0YkfJtY87e3Hv9OkJhVV9tOT/15E7MqtT/LXFwERiPry57S1pqWj+zgC7rdWEERI63INDlIgsjuoDPwLiC6xnRAvulPLi0BMLFDveReAiKXtz4cp3Tk4eLcKpRHoo0KajKbfjAJ07PaCnc90BFq5FFbzBEQgat6FlWlAS/vSU4iy5x8sH6Ll33lQrvXlCoRaWxkbM94Lg09g4CwA+xbYxPzVZDyqtrxqd2p5EwjNQcNp/qJv7ey+FYzTKyFI5fpT8lcXARGI6vJH1Vqj21PvdQSh60jdNtiprumO5kouQlSIQLj1oqSrNQIiELXmsRmyt7V96RdA/MNyRhA1KBAPIcOnJJPR/yuGXQRihl5KqXbaCYhATDvi+qggiDWIGhKIVwBcuN/e3Ocm8KAXgfjEkSt2fsdbo/fYorf+yuCR4+Lx+98I+m3RrXkw8CyPhxYMDa3ZHHR9Ul59ERCBqC9/TltrdPvpmXBBarDvareVVqlAZC8zIuA5Jn6UyVhX7OS2rq1eBELlr+SagOxicvt2SjodAREIeS9cEWhZsPTDZLI6/bt3PgMD16Zifee6KsBDIi8dbrmL1B7MckzqxV5ViH09h4C/wOQjEonok0HYYy1De36FcUcq3ndakOFRgrZbyqsOAiIQ1eGHqreio+Pk3TIYfxCg5kljp2n3jZcOtyYFQnOSuljE2nJejiBGfuXUL3lrm4AIRG37r6LWa+L6bCGTDkskep8K0pB6F4jW1si+CFM/GB/Yzm16YjFVY/ysIN8VKWt6CYhATC/fuipdF6K62Aljv42vd4FwiOb6J2T4sGQy+pxfbvZ8DhcfSTTXoADvAOWIQOwATg6qibpLbtSOGISNo/xcj+lkV70LhGq39j6IEterevVjS3v3WUS4bsrlTgHfOeHVJklfWwREIGrLXzNura7TAejmseE55wRxo5xq4A4hEPrLl7YyjKNTsZ6hch3d2hr5AELZkOLvsZQV+J0T5dop+aubgAhEdfun6qzLjSLuBajLYlwgd1Lny9sRBCIrhJrrVQE8TWb6mETi7j/6db7DndSohuCKftsk+WaGgAjEzHCv6VpbOyMHg0lFCN3T0pC0Wo8YHd71u+WMJNQtaKGMeTURTrDde629za0WdzHlmam1iLH03GsZ/EXrC5GdtjPohNRA7++8vigHdUX2CqexxibgcBMyxGtdkr7+CYhA1L+Pp6WFbR2RFQxSF9zMtnVuKcA4LxXrWe9ln33uesyLAHzOXqYq31Mspgrfd+BlxGN3htPXPoCtYD5nv33Q6+Y0NwBqWxA5hE3jRwC/z1bPFhAflxyMKp/IIwRcExCBcI1KEtoIUGtH95cAXKXr0AF+Bmz8uwH6WTzeo8JYT4mEGolEQi9uDu0TzmSOBKkoqvT3thDb+erSDNzQFOZLdJf11PIIYnJKLXsZU+inU86YbIf9PJiucuI4v2v5HrPS5iGA+RWADtS8pVtgGCcmB3oS8gYLAa8ERCC8EpP0VgLU2rH0MwD/GMC7i6BR9yy/ClDuvmXeGcDc0ij5GTJwdmIg+kun0Ug9CITi0NoaeRdC2RHZSR44KubvLJL+KTao289UVWnfSIodgYAIxI7g5WluY3PzKbuEwuOXM0HNpYcDqO55Zlw8bx9eW2p6pV4EQjFTo6qXN1I3gGtKCG4pxGli3JhJN1w6NHTn66USy9+FgBMBEQh5NwIjkF1gNs1zCTjDejWpywrSTFBXml45by9OlRKGfJn1JBCTU05KcBvGVzHwzx45qsCDPw5T+orpuJ3OpR8lWR0REIGoI2dWS1PUl/BLm40PUsZcRkStDPwdgH0so4uMiqAK8B8JFDOBR5vCO8X6+28d8dqGehSIPAPF8U8b8akQ02ImHAVgvylTc4S/gvEigX5FjOjIyJwN5ewg88pe0tc/ARGI+vextFAICAEh4IuACIQvbJJJCAgBIVD/BEQg6t/H0kIhIASEgC8CIhC+sEkmISAEhED9ExCBqH8fSwuFgBAQAr4IiED4wiaZhIAQEAL1T0AEov59LC0UAkJACPgiIALhC5tkEgJCQAjUPwERiPr3sbRQCAgBIeCLgAiEL2ySSQgIASFQ/wREIOrfx9JCISAEhIAvAiIQvrBJJiEgBIRA/RMQgah/H0sLhYAQEAK+CIhA+MImmYSAEBAC9U9ABKL+fSwtFAJCQAj4IiAC4QubZBICQkAI1D8BEYj697G0UAgIASHgi4AIhC9skkkICAEhUP8ERCDq38fSQiEgBISALwIiEL6wSSYhIASEQP0TEIGofx9LC4WAEBACvgiIQPjA1twRmW+AHgWwWz47A8enYn0/cyqutbP7VjBO91GdPctmgP8CGCkAD481mY9seCz6WgDlWouglq5l+yOdWWyAFjLwEQB7AQjlEg0D/DIzDRHR/dNkQ8BN8lZcV1fkHaPjdB8Ih7r1sbcaJPV0EujsXLx3msODAN6fq2erCT5iKBbdMJ311lvZIhA+PDrDAmG3OE2MGzPphkuHhu583UdzJrO0tkZmI0TLAXwLwL4eykoz4RGw8a1UrGc9APaQtyqTikBUpVtcGyUC4RpV0YQiED44VplAZFvAwH8bZnpRInH3H300iVo7ln4G4B96FAZ7VRlm3JsJGec/MdDzkg87qiaLCETVuMKXISIQvrAVZBKB8MExIIEYBrAJIPdf28RzwNjdyWQCHh1t4oiXKSc1aqCQcTmDz7VMIRV0/DlbRyf+wDsDmFsE3VZmXpmKR9WUm/v2+fDFdGURgZguspUpVwQiGM4iED44BiIQjMcbG3hRf3/0b15M6Opa2TSWGT6K2bwUoAPteQn4ZiLWd5mbMucfHpkza4RuBtCtSb+NgVsMk27cd1/zxWg0mrGmUXaMpt/sYqJ/IsaRAMK2MpQAXpiM9d1QiyIhAuHmDareNCIQwfhGBMIHx5kUiLy58+ef2dA4e9slDFxq+/J/IWPwYesHoi8Ua5rKP2v2a9cBfKYtXZqBy5vC/H234tXcGfkIMd1CQItdJIiwIjHYt9YH5hnNIgIxo/jLrlwEomyE2QJEIHxwrAaBUGZnRWKn125n5qWWZmSI6NTEYG9Psaa1tHefRYTrbOKyhYFTUrG+x7xiKTJV9arBmSPj8bW/9VrmTKYXgZhJ+uXXLQJRPkMRCJ8Mq0UglPnN7ZEOg+ghAGpdIPswcG0q1qfWFLRPa2vkAwjRLwC8x5JgC4iPSw5G1S4kX4/TqISIekffmrNiw4abx30VPAOZRCBmAHqAVYpABANTRhA+OFaTQGh+CGpcuDo52LfSoWnU2tn9AzDOmzrqwMrEYN8dPnBMyaLWNRpHKMrAEZY/DJvMi4biUXV2pCYeEYiacJOjkSIQwfhPBMIHx1oWiIMXRA4ImdnRwwGTTWe+DyaWJ5NRtbBc9tPevqzTJHMdgF22F0Z3NYY3n97f358uuwJNAVlhGqXjwDiNgU9YdlmpxfVNBDzNzL2Z8fS969ff89dSNpQSiObmU3YxwmMRED4H0McBvDNbJuGvYF5PhB9zGj/3y7S5eflcI5w+FkSfUbOJAPaxbQRQByafZ2BtxghF3W4rbuns/goxvptvf/6Ap2oPNYxfTMBnAewJYBjMzzDhDnMsvboYs0gkEnppY+hAInMlOPthsL/F1s0E/AaE22aF+F6361o6/2SnVBtfO4QNVh8/6gDjxE66LHM8wjCuyZ/DEYEo9Ya7+7sIhDtOU1JVk0B0dCx5XxqhfgLmTRpZZATR2r70C6DseYf8MwbwomQsqqapAnkc1ka2kEmHJRK9TwVSSa6QbEeeoW+D8QUAs12U7epgoZNAjA/v+tCspm3ngvD1SVFwrvTPAH0uGev9ududXGrB32D6AYDDi2w7ttfo+vyJTiDIMF6GyT8F+H36pvC6xvDOkf7+W0dsf6e2BZFD2MT1AH3IBfs3QPxtpHGdR+F0W49af/spp80vhcOZRjlJ7cIjJZKIQPhgWE0C0dbZfSozbrV2Jky4IDXYd7W9abmtqVGAjt3+N/7NWDh82Ib+NX/xgcIxS1vn0mXMrKas8uE5AKazkvHem4Kqp7U18i6EqDfXmXoqloFnYdAJqYHe3+ky6gSCwKfxBDvdtmCn+tMMvigViyp/FDsTQq0d3V96ey3pKpdCp6vvVYONRfF4z386GWMXCALOZWTFVYVT0T3aTQ8uz884FMlDZjhz0lD/3S+Xclput95FDHxDs5XaKftjBmfOMyl0n4TaKEW4+N9FIHzwqxaBaGtbvD8b4QdsP27HmDPNXYv3M9LhAev0EjH+IxHv+7wPDEWz6EY2zLgjFe87ze3XdLEKimzTzU6NgIz/ApABcSOAdnB2Sm27WGUL5/6xJpygO1ioEwgAGwHsbbFLbQn+LYGyHTKDDyTgo5qObCvDODoV6xlyalNbZ/cSZtyuEYc3oMQM9GS2PaoNbP4DKPvFXjhiKnG+xi4QuemZ/OFLNcUYB+gPudFEO4DnzfHQ4UNDazbnbS/CPjvdQ4z/YpDaZh0qwuRpMtPHlDj5T62dkS+D6Tua0ZTi8hhAfwb43SAssB0iVTvxPmyJDCCxmHz8yEUgfECrBoFo6Vr2XkpnegBqntoE57l+3Y6noL/q87Z84sgVO7/jrdF7pi5W81AIDUfHYndt9YF9SpaWjmVdBFOJY76TzDDwnaYwf1c3z63WXsIm3WRbPHfcEuwgEHkbHKepDlqwbF7YNK8FcIJbv+TyPJzr0PLZthJh1ehbu/bqdn/lvuA/y+B/tU11FZ0yLBCISSN5iMOhZan+nhfz/6QYDGfwnqHB6NOWtjh02vyMyVj1nn3wuP1Q5cEHn7i7MavhWzQxUrGK9MONYT7JaV1Cv5aFN8B8/tjIbrdZuah1kD+9ikMNMn7oMFUmAuHjRycC4QPaTAhE9qtt1tY9OUT/8PYX5ckELNJ8QRb9KmtpX3oKUXbaJ/+MMfAZP+ce3GBra+/+ERP+MZ+WgZfCyHTFYmv/4CZ/sTQtHd3XELBqMg3RdcnBXvX/jtM4EyfHcS9AXdvL1s+vFxGI4VKH/7Q7uQjPIc1dyWT0FXu7Wju6zwayZ1Lyz+sGG8fG4z0qGmnRp21B5FA26R7rhgBiXJmI912iy6gTiOx0W9g4yioOTpXq3v3sl3yGlyaT0f8rYiy1dEZOJyZ1sn5S1In0u+eygSMNrAGRes/zzxYYxonJgZ6EUz0Oo2qVXASi1Muk+bsIhA9ogQiEj3pLZPE8/zzdPxpNZxTIj1Q3OikVbj3PrrUjshAgNTc9S/2bk2g5CgTzV5PxqNoFVDTGlL0eANvIpCMTid4nrH7Urgu5ELt8GV1dXeHR9J53AYhMCnGRqTydQHgIz0KtnUuvBfM5lja4mSrKJ6eWjm41klCn/3MPJ8aacIx9mq+tLdLKRvZ8T34nXMZJTOy/i5aOZc0E80FrOP7pfteD/zlXR4kiED78UGUCkQF4kMOhz5b6Amxr776CCRdbmhxIh+2EcLoEQrvDiOnUVLz3zlLunFiHCT0KkFqbeJJBTzeQec3gYPTPUzvuwvsgALgKY6LK0a336EQsF2L9cwx0APgHAuaYzCcNxaOxUm3J/72Ac5F1CI1P3jSZF7qpT7NF2nWnnbdVU4Z2FFv4ruqFxIGRTsim9V1366taSycC4cNjVSIQapFunXXvd6mmaC4tmtYfjaYzCmpKi1rau28jwqmT36EldiWVYmP/u8MIItoY3nKym7McDiK2JBXvvdurLaXSlykQL5jh9AI3O4pa2iPHE5Gyf2Idoci0mZPNuhGPfUpMu4OsyLSZri7Netu0vuulfFSrfxeB8OG5gASiSLhvVn5RN7jZd6mMg+gmyox/b999Qy/bFwNLNaVg3n6a52U1AqGdZillt+7v2m20wDAD9xF4dWN4537Nvn3XVWk7eMIlqcG+K90U4pD/otRg37+5ye8lTVkC4SGqsP2rXoWX/9tOjSf+5pHb3/Ro78XEuGJ7nqnrQJodcJ4/LNRBQ2rIDBDwwVw9IhBenJRLKwLhA1ogAlHih5k9nbqJWsD4niZK6r3pMH/xif7oJi/mT9eUj5MN01lfbmfMOg2bvDkTW1AZvRyie+fNNZ/1IqjldvDl5i/l1/ldy/doSGdaCVA3AKqzGRMnudXjbYrJ1ahI9+UP8P8Cxi9L2Vr4d/4UgIMtAjFld1tb29KD2OBHAOw6MVDBX2DyEYlEVG31dfVo1qlEIFyRm5pIBMIHtEoIRN6s7O6lnbZdCcb5Uw7D+ZhSqaddTIpPe/uyA00y1YKzCkNR6slOyZFJt46OzvllqcCBpUJtlKosCIHI3v0x9vpc0wh/wgDNY+KDwdmO9b1FD9N5EYjicbsmm1li228pHKX+/nyY0p2Dg3ercyZo6eg+joD7LZmm/L1UYfm/26ZURSDcgrOkE4HwAa2SAqHMK3IwycsOEvXDO5wAFfYhu4Mn+wR8ujlfrMM5iMBPbaszBKGMeTVR9tyB7SCco3PV9N6Pw5S+It8p2VPOlEBk22Oa5xKgQrjv5+P19DaCEIHwhXhHySQC4cPTlRYIZaLTlIqXa0a1p5uBn6RifWeU2rbpFZNuFw8AV9MZXutS6S0d64pcsDk3xbxKBq9IDEQfn2mBUMHyQuHxy5nwRQ8hJZTZamSkDh5uD90uI4isO2UE4eYnUDyNCIQPhjMhEMpMh/3dKpzEV5OD0e+V6uT1sZjwlD2Ugg8kBVkKdrxM42jFVjm1dC3bn8b5KBh8OhhqvrtYED91+GphcqDn19ZyKjmCyG29/WnhqXh7y7JRS9VJ5xRAvzKY4vF4z8aWzu4LrRFaPa1BlDGCYML0LLrLFFMQP8FAyhCB8IFxpgRCrde1tkcuAmVj01ifkrF+8ok10Vxd3UDnBdPEgubc1QCfbMk3LdFcS9mlpueamv76wQyFVhBjKSg7fz/10RxMq5RAKPsaZm+7KRdm22rXNhB62KT7G4zxJ/faK7TFaZG9rF1MLgVCN2U4XXG8NL8vz+sHmkV1z2WUerd2hL+LQPjw8gwKhONU09sj6qJxbfLN1N8HgccbG3iRm1j9bW1LP8aG+ROG8XDGoJt09xDoY+jwg8hgiccwzz68UzSLuizpSDBus05DqVATPB5aYA1IVymB0JwYVg14CBk+pUToismGVkIgVGX20CnFRirlOE4zPZlh5sWpeNS6cF20io6Ok3fLYPxBy6hMBMKHU0QgfECbSYFQ5ja3R44wKBsuwjp1ou4EOCcV77Pe9aBrnSbcQTbqqatpKlvcoDQz7guBL4nHo79XlVXiRrmWBUs/TGweC6ZWVSUDiabwlhVuDrApG1s6IyuJ6ScWOAWdR8UEovB0+5+Q4cOSyehzLl/NgkOD0zHFpGzRjD79jArzp5xVaJCXVZRaZvPRpoY/r837zyGUStFrdO2sghiFuORf18lEIHy4d6YFQg2fx9Jzr2WwWtCcfNwGXVORYJE2H7YcIlJlbCXiFYnBqNrlpH1ywe4eAKjNlmAYxN9oDOHG0bTxfYDPtP496Dupyz3R66bzqIRAOJwtcLqcR+uT7M1zDRkV2vpjlhfBcUSoCfdd7HraKXVOjB5Z3UaobpzLPgxcnor1qcuTisamyqfX3Yeuu0Ndc4bmd2nDOMrtzXltHd2X5e6QyFctIwgffZ0IhA9oMy0Q2a+51sgHEMpeHbp990r2UBHdOCu8eVWpr+mW9shSIlJTLdu3vAJbmXllKh79mdMPXu0WajD5PAarOyS2H86a4Lgt92/W7aZev4hLekSzG8tTTCDNAnpBuInKCMTKptH0m1MucPJ4Olk3GpyWba65d04fYZX4uORgdH0pxzl82AwzjGNSsZ5+a/5yxMjhtyECUcpBmr+LQPiAVg0Cocxuae8+iygbJtraIbsKFV3kbIWrKzldbsssGRrbB344LYLDRUelD/lduP22EgKh2l4wr69EusTlQiqfOmn/8iZcACYV+iNs4/grg0eOi8fvV1tgpzzljCBUQbrpzVK38+UMoJb2SDdRdmpv+9So833oar3oB2CcZ2nAMBN/KTUYXe30AVPklkERCB8/NhEIH9CqRSAcOruiN6VZm1v0ZjBgGwO3GCbduO++5ov2HTS5LbPqXoXLHLZnjgFYmYz19bidfvDiCofLZP7MTOePj8zp052UnrjvGasBOtDa6ZjMi4bi0Uet9VdMIHRXs4L+QIb5+cRAVIWxmDJ1UyIES74JjiePyxUIp+nN7FkM5gth4i77RoQiHxNbiom6w90OTh8w1Lpg2adgmmpUvH26bbtTRSC8/MDyqu4jzw6fpVoEwumLTl1N6XLBOntKu3H2tlJ3/qqrLjcBNJp1PvEc2/WODu8EP0MGztZ1dAG8RLovzHyxbwD8P4Dx1MQ/8LvVxzqAuYX10s1jw3POsQtKpQSiREwpdc1nYuJaTfWYHwPo4wVTeyqqKmfXBfJ3JzhGaC1XIJQVDhsR8miHQXgSTP+Ts/mTAM3XjHLUaOCfU4PRG4u9C62dkYPBpKY8J9c9cukn62HwLjQRLr3YyXMRCB/be3tsAAAUgElEQVQ/OhlB+IBWTQJR5IvOy9w/tS2IHMImrgeydx0H+SixujcTMs53u8DotvJsJ542bgBYnZ72+qgrSm9rCvMq3fbeSgmEMtpjTClrO9Ngupob6AbbpgPHqLlBCEReJGaN0M0Aur2CB6BCnVyYjPWp2+VKLm7nQsSouz7sIuFYNRMeMAC1y+74XCIRCB+OEoHwAa2aBEKZX+6CdR5B9tBW09bFRNlpIy9CkQY4xgj9i2FmRtmg2zXD/Gz8o7RhfDdIocjOxW+ks97+Qr08H/3ThUvVtZ8X7rc39zkdPqukQCh7D+5Y+kEDvLpIdFprs9SI7jGT+AJ1X7TuhLzTKeegBEIZk2OvBOIqAPu64K7UIMXEZ9juuS6Z1UPMraxowjS/gTDdCMbpIhAl8TomEIHwwa7aBEI1wWHBelg3v+6iydlwFUhnFhughQx8JHc/RX4x/A0GNoKxnojuH2syH7FeGZm9JS2Mc8D0tcKdTnRXY3jz6aV2WbmwcUqS7FRZ42uHgLCcyWwHSE035BdDhwF+mdiIZ2Dekh7Zbagao7nm1xcMk/6RiTsB7D85NUMqzAb/noG1GSMUtYus/V5r1RGbY+PHrl9/z1+toIIUCOuHRbhpa3MIxhka9mq6708MWmeCfrw+1vu/bkYNDv6n5s7Ihw3QP4FxhIWP+kB5jmGstR7elFhMXn9FhelFIMpnKCU4EMhuiWW+ipmX5Do6VzusBKgQEALVQUAEojr8UNdW5COtGkT7cdr87AyH26hr1tI4IRAkARGIIGlKWUJACAiBOiIgAlFHzpSmCAEhIASCJCACESRNKUsICAEhUEcERCDqyJnSFCEgBIRAkAREIIKkKWUJASEgBOqIgAhEHTlTmiIEhIAQCJKACESQNKUsISAEhEAdERCBqCNnSlOEgBAQAkESEIEIkqaUJQSEgBCoIwIiEHXkTGmKEBACQiBIAiIQQdKUsoSAEBACdURABKKOnClNEQJCQAgESUAEIkiaUpYQEAJCoI4IiEDUkTOlKUJACAiBIAmIQARJU8oSAkJACNQRARGIOnKmNEUICAEhECQBEYggaUpZQkAICIE6IiACUUfOlKYIASEgBIIkIAIRJE0pSwgIASFQRwREIOrImdIUISAEhECQBEQggqQpZQkBISAE6oiACEQdOVOaIgSEgBAIkoAIRJA0pSwhIASEQB0REIGoI2fORFNaOru/QozvTtZNWJ0c7FsZlC3TXX5QdurKOWjBsnnhDB9DxEsY+AiAvQCEcmnTAF4l4PdM/CiTsW7eXPPZaDSamQ6bbLb8HYB9AIRzdQ0D/DIzDRHR/WNN5iMbHou+5seOAn8Bz4cp3Tk4ePdGP+VJnpklIAIxs/xrvna/HXi2w2LzAsrw6kQi+qQTCL/lzyBYalvQ3ckmfx+gAz3a8QqAryPDa5LJ6LDHvAXJ588/s6GhaetiIlwG0Ic8lJdm4PaMYXzjiYGelzzkgwiEF1rVn1YEovp9VNUWeu3Am5tP2cWYNXYemL4MIG2CjxiKRTfUg0C0tkbeRWHjBmY+yTJS8OO/p0wKnTI0uOY3fjIDoLYFkUPYxPUehcFe3RtMdMm8vcwb3I5sRCB8eqxKs4lAVKljasUsLwLR1nbinmw0/BIT0y3q2VovAnFQV2SvcBprAOoKyHdbYBgnJgd6El7KU6OGxtnbLmLgG5YpJHsRahprE0Cj2T8QzwFjd4d6MiD8CGm+wM2oRgTCi7eqP60IRPX7qKot9CIQnZ2L905zeBDA++tJIFSnPGv2a9cBfKbNWWkmPALGDynD/zU2ttuWDRtuHldpIpFIaNOmzJ7jHD4QhLOIcaS9Q2fgWYSNo1L9PS+6eQmK2KGyvwLG9dxgrEn19/wRAFvL7OqKvGNk3DiSiL8J4GOF9dHNY8Nzzsnb73rEJ2sQblxXtWlEIKrWNfVnWL0KRHN75AiD6D4As/NeU507UyjidpqopWvZeymd6QGo2ep5YvzHrIYtX+zv71eL2sUeau2MfBlM37FNbw0T8E3O8LVuRgBKuF7ZSGcz8K/W9gDIMOOcVLzvh8WMkBFEff1uRSDqy59V3Zp6FIiurq7waHruaoBPtsD/EzJ8WDIZfc6LQzo7I+9OM35mE4ktZNJhiUTvU0U75vbI8UTUY+vUtzBwSirW95gXO1Tats7uJcy43VZeyXaJQHglXd3pRSCq2z91ZV09CkRz8/K51JAZIOCDFmedk4z1Xe/HedrRCOGi1GDfvzmVp9Z2TKPhEQI+aUnzOhGfnBiM/tyPHWploqWj+1sEXDolP+Hfk4N9F9inqPJpRCB80q7SbCIQVeqYejSrLgWiIzLfAD0KYLecz940mRcOxaMxPz6cf3hkzqwRPKA2Ik1OVzHuSMX7TnPqlFs7us8GcN2U+pi/moxH1fmUKWsNXmzKbkU2zYcBfNiS74WMwYetH4i+oCtLBMIL4epPKwJR/T7KWtjcHukwiB4CsHPO5I1s0GGpgd7flWpCa/vSL4DYOndccvdQvkx7XgZ+kor1nZHveEotUjcXdqBFzWXg+FSs72eOX6SWg3hqvvyljXQIAZ8DcCiAubl8w2B+BgbWhJG5YzoPaWnat41MOjKR6H2ilF+c/t7S0X0NAZ/P7TRiYgzMapj9xf7+W0fseXSCAuApczx0+NDQms1+bcjna+voviy3Iyr/TxkiOjUx2KumswoeEYhyiVdXfhGI6vKHozXzu5bvMSud/gVAn9j+ZUmnpuK9d5ZogpoquIWAz1rTMZfOOzG/vuddatNNLm9B5zBTAtHaGfm02h3kYp9/GkxXwzS/4WaR1uvr0NYW+RQMepSBPSx5fU8xea2/paP7cALUNNKsfF5iXJmI913itSxd+ra2pR8zDV5LwH8T4X4yjcfj8R51Klo7MhGBCIJ69ZQhAlE9vihlSUFHb/+a1xWgExaVTu2OScT71Feq49PaGtkXYeoH4wMqEQMvhZHpisXW/iGfqeICAdwGYP3bI6mrbAuoRfkx4YHxRj7ZbwgJp8I7Ok7eLYPxB20Ly0+TmT4mkbhbbSed1qetvfsKJlxsqaSsKa5yjRWBKJdgdeUXgagufxS1pq1z6TJmvmP7NkYeCqHh6Fjsrq1OGdvalh7EBj8CYNepaUrnbZnYGXO3pb51jeGdI9apjlICMbF9k89TnTkz70SE4wHskrNlDOB1gPGXSdsM+mFyoOfXjgIEqLY22cThZQZiBHqdwAcw0ALgnQVMApiX135lF07DKDl9xmSses8+eNztKWSvr+Injlyx8zveGr2HgSPyebPba8dDC4KYXvJqj0ovAuGHWvXmEYGoXt8UWNbRseR9aYT6CZiX+2PJtQTN+kO+3JJrGLm58FWThjCdlYz33mQ1rJRAWNMGskhtKZCBFBOfMTQYfdpaT2trZDaFaFVu7nzybAKAogusfl8FJYJImw/bdjLli3uFgTtg0Oqgg/FpeCphKhBxv+3yk08Ewg+16s0jAlG9vimwrKtrZdNo+s0oQMcW67Tzf9OsIUwps9g6hGbqRLsff+YEouTJXt3BsQwzL07Fo/cH7faW9qWLifhW7chle2XDIDwJ8D2GaT4wMrL7s6VOJhezU7cBgIFrU7G+c4Nun9vyRCDckqqNdCIQteGnSSs1P8BoY3jLybqTtgV79Jl/DaID8tNNxTqTgs6H8XhjAy/q74/+beZHENw/1oQTSq0nqPYbDRl1SGwydAQTLkkN9l05HW5vWxA5lE1Sh8tUKG03j4qa+luD8XMzRHd4HWFoBaLEmQk3RpWTRgSiHHrVl1cEovp8UtSiwu2u/JuxcPiwDf1rts/j50qwpc0w0VnE5j9ZdkL9yuCR4+Lx+9+wV2rfW6/CNSRifZfZ083ACKLoNkubfdTS3n0bEU6d/PeA76uw81DRaqlh/Nu5barW6S03b9o2Bm5poPT33WzNbenoPo6AKaMhJlyQGuy72k1l05FGBGI6qM5cmSIQM8feV82aqR/HXSu2H+tGk0ILDc6ok7H5bavadQjNVJbbOoAiHXAQaxC6nVTFQNo7LC5x6MyXUzSZDj74xN1DDbNOAmUFWd3FkL8oyE0VamRxQ1OYL7GP2KaM3nQCYTtH4qayINOIQARJc+bLEoGYeR94tsC+eMyaaYWC9YfcFNFIhlYR44pcpdo5+cLFcOdRygyMIBxHPTqQBfY5TJV5doKHDCpS6mgaHcTGUiY+HMB+brKzOnuQ4ZOcYjrpzkDo3gU3dQWVRgQiKJLVUY4IRHX4wZMVbrafas4wZBcvW9qXHk3E6qRy9otWtw5hL7/YWkXFBcJjB18NAmF3bja0dppaiLAEDLXhoJhgOJ6pkDUITz8bSeyDgAiED2gznaXgC5/wHNLclUxG1ZWV2cf2dTk5UijIq+lwbSOUojt/Ki4QHtcQqlEg7O9PdjF9Vvo0MKndR/va/64ORI4P7/oF+44nzbZnVwcgp/P9lRHEdNKtfNkiEJVnXnaNmjWCMQY+Yw3rbF9/yMdtsh+uss/pF6xxaMTH2gARiLLdOVmAOr+BMC4E09dslwe9TiYvTCSiSWtt+lPccg4iOI9ISSIQNfoO2A/AWePvFAiIbZRgC8+QYabjUvHeBxUKTVBAx2202ZFKZ/dXiKGihk4807xIXax8nStrYQRhs1t78Y8uvpLunIucpK7RH3SVmi0CUaWOKWVWsXMKzV2L9zPS4QEA6sxDwTqDfR3C2vkU7vopHtRvRxaICY7mpYCxF8Aqyu4zTtuGS/nT+nd9hFb9yEBzUj7wWEyt7ZFvgnAUCGtLHfCTKSYvnq7+tCIQ1e8jrYX26QXrVJHT+kO+IPvcNQGP/m2nxhPfNRbK2E5qlw7HsQOPIDSh0AuCGfp9vQrDnOgPKuoWqoOM5qq9n6JIvCcRCL8er858IhDV6RdXVjktJtumkAo6ead1CFXp1FhP/CAyWFIsTPYOPYIoDLUdWCiPls7uiy3bkdUwUHuSPbtuEcJagI62vDS/SxvGUU8M9Lzk6kUqkqi1I7IQyN63PRlOHKC7GsObT9ed3heBKJd4deUXgaguf3iyxv7jVdtRm8I7XTRlFODQsdhEJLvIbRDtYY0W62ZP/Y4sEAcviBwQMukX+am8rPOY74OJ5eXcPaFdWyhywK8wym92WvHyVKzv6+XcKJcVHwNrQLTI8mKqCLyLkrGouryq4BGB8PQTrvrEIhBV7yJnA+1nHQAeMoGzCXRPPuKr0xmGwvMQfClA77dcLKTdOWO3ZkcWiImOfO5qgE+2dqDMfFoqHu31+2q1ty/5qEkhFaJ9e0wnTSTdfPnq1LYxq2EdTYQ5zz+vG2wcG4/3DPq0Q7tY7jSSydchAuGTdpVmE4GoUse4MUvzpbkVjKtAUDGT1JSA45SH5rT0f4Jo1/zlQEpsSt01oWzckQVCtb+9fVmnSeY6yx0X6p+3MvPKVDyqDiR6uhNazfk3jlDUeseDmzDlucON6hpQa/ynLTCME5MDPQk375M1TVtn9xJmqMCD1vKGTeZFQ/GouoNb+4hAeCVd3elFIKrbPyWt0+xiUZfJZ3cvAXBcZNZdNmOtzG3Y6DIFouSOGy/l62BN9zZXJdJj6bnXMviLtvrTBPpRiMa/7Sbwnsrb3Bn5iMFYDdCBNl+UnC6aP//MhlmzX7sO4DNtdrwB4m8jjevcTHsVOYsBAt04K7x5lW7tQUYQJX+qNZlABKIm3bbdaN0ulsm/lghLobmuMp+14OCd6y/GIucgdNefqqtP2eRVTp1XtQuE4tLWduKeHGpYB8ZBGk5pED9OoNvJ5IGRkd025k9Eq/MqY2Ovz2UKHQ7CWW8vBv+9Paif2mE22sSRUqHNVb0Oo4+8Sa+AcT03GGtS/T3qKlTryIba25ftbRqZU5xOc7u1Q0YQNd6h2MwXgahxf2YDwY3TfSAcam9KqVGAfR1iMn+J09PWerx04NoLjyYKewOgP6v/IJiXJWJRNbWRfbyUPxMjiHydbW2L9zeN8H0EfDKoV0oF6zPM9CIvd1u3tkbehRDdCWBhETuGAWzK3kwOVn3AXiXu934IGT4lmYz+X6m2iUCUIlRbfxeBqC1/aa11GAmU3HKpi+WjKlCxf1KxvjPczJ977cBb2rvPIsJ1TuGv7Xv4vZZvBzTdU0zW+tRdEMas8WvB2fsnvIT3tpudYca9mQY+54n+6Cavr2ixaSKPZanRj5qeusrN9JRW0IHnw5TudDvN5tE+ST7NBEQgphlwJYrXhX0utv6Qt8lpHaLYVaQlO+ASwfQmQl8bNwC8woHNlNAetSQQufZQc+fyjxMy3yHGkbaYSqVeh8zb242fMAxclBjoU7uPPC1w2wuf2IZrXJLbZeXl8qI0M+4LgS+Jx6O/L2W09e8ygvBCq/rTikBUv49KWli43TXbtWgPVtkLs48+yr2Qx02spEgkEnplE53AzBcA9PGp9zhP3T1VgwIxiVitCTSM0AICjlKzZbmw3nMtPsioqR4CnmamtekQPRDE4Ta7j3NTe10AnQBwB0B7ALDaMQzwy8w0RET3jzWZj7hZ89C9mCIQJX+uNZVABKKm3CXGCgEhIAQqR0AEonKspSYhIASEQE0REIGoKXeJsUJACAiByhEQgagca6lJCAgBIVBTBEQgaspdYqwQEAJCoHIERCAqx1pqEgJCQAjUFAERiJpylxgrBISAEKgcARGIyrGWmoSAEBACNUVABKKm3CXGCgEhIAQqR0AEonKspSYhIASEQE0REIGoKXeJsUJACAiByhEQgagca6lJCAgBIVBTBEQgaspdYqwQEAJCoHIERCAqx1pqEgJCQAjUFAERiJpylxgrBISAEKgcARGIyrGWmoSAEBACNUVABKKm3CXGCgEhIAQqR0AEonKspSYhIASEQE0REIGoKXeJsUJACAiByhEQgagca6lJCAgBIVBTBEQgaspdYqwQEAJCoHIERCAqx1pqEgJCQAjUFAERiJpylxgrBISAEKgcARGIyrGWmoSAEBACNUXg/wNgXgWow6KHCAAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-31"><g><path d="M 371 851 L 371 894.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 899.88 L 367.5 892.88 L 371 894.63 L 374.5 892.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-32"><g><path d="M 371 1001 L 371.5 1026.5 L 371.13 1044.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371.02 1049.88 L 367.67 1042.81 L 371.13 1044.63 L 374.66 1042.96 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-48"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 1023px; margin-left: 382px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="375.5" y="1017" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-52"><g><path d="M 321 1101 L 51 1101 L 51 407.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 402.12 L 54.5 409.12 L 51 407.37 L 47.5 409.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-53"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 1112px; margin-left: 312px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="303" y="1106" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-62"><g><path d="M 421 1101 L 531 1101 L 531 407.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 531 402.12 L 534.5 409.12 L 531 407.37 L 527.5 409.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-64"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 1112px; margin-left: 432px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="425.5" y="1106" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-23"><g><path d="M 371 1051 L 421 1101 L 371 1151 L 321 1101 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 1101px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Any PM<br />wakeup event<br />pending</div></div></div></foreignObject><image x="322" y="1080" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmcJFWV7ncis6oaUZYHsqOD+nPcBh1bu/aeGhp4gEDTDVnVLLIIgqM8GJ1BRuCNG+C4/GRkGlAUkUXoypRmGUaWRqbozMrMal47iPwYR0FGFhsamG5AqO6qzDiPm5VZHRVxI+JGZlZVZtaJ/6ryLud858b94px777kEeQQBQUAQEAQEAQ0CJKgIAoKAICAICAI6BIQgZFwIAoKAICAIaBEQgpCBIQgIAoKAICAEIWNAEBAEBAFBwBwB8SDMsZKSgoAgIAgsKASEIBaUuUVZQUAQEATMERCCMMdKSgoCgoAgsKAQEIJYUOYWZQUBQUAQMEdACMIcq5YouWRp4qCYTb8AcJBDoVfJ5iOy2VSuJZScJyW6+gaPIeCuGrofB/A8wJvAeMAm3PWOffFIKpUqmrTZ1T/4RWJ8U1eWGJdnR5MXm7QTVmbxwIl7thcKvwDoYHdZBo7NZ5L/GtaG/N4cCAhBNIed6iZld9/g5wCs9jRItDqXHj4PANetswXWUB0IQofYcwAuOGBfToYRRRBBADwWQ9uRmcwtW2o1S1ff4KEE/BuAdiGIWtFs7PpCEI1tn7pK192d2Akx3AbQkZqGnypavGzD+tRTde10ATU2SwRRQTA5sYjP3vhA6hU/SIMJAq/bzEeMjaYytZqkq2/wewSojwnPIx5Ereg2Vn0hiMayx6xK09OT6GaL7gWwS7mjCddX4Lm5TPKqWRWihRufZYIAQNdOjO967saN107qYAwhCNQjzBQUXlIyCUG01gAXgmgtewZq09M7eBkTLpomB8KV4NKXYDlUwNmJRTgq6Ct1AcEVWVUdQUSZMBcvPrutvX3LXhS3+pntLwP0PpcQRSKcnk0nb66GIIDa7RsUXhKCiDxkGr6CEETDm6g+AnZ2nri31VZ8AMCHyi/yMzG2TrYt+8dgvKfciyxW1wB3rQTh7FqFA8miK5lwlvP/DPzKsicPz2Zv3+wWVeNBKA9xO4C31cm+1N0/dCWYzy23pzwZC0CsIksUQqwBaqk6RwgIQcwR0PPdTXdf4giA7pz2FhgP2oW2FdQ2+c8EnDEtnyxWV22qehKEEmLxoYldO7ZRioHDHEIVmXllfjTl2S2lIYgnAf4VQCsr9Qn4ajaT/Eo1Sro/MgCoD453O3fECUFUg2zj1hGCaFzb1E2ygYGB+PbC3jcAfNL0RFHe9tjVmziWiNY6vgJlsbpK5OtNEEoMD7FPxfmvzGeS5xt4EE8C9DWAf1iPMKJLliKBzmPwF8okURJHCKLKwdOg1YQgGtQw9RSrr+/4dxUQGyHgwHK7Ewx8Ip9JPtDdndgfcRpxhJlUEVmsrsIAs0EQ2kVhxoMdbbx8ZCT1J6eYOg/CpthKiws3Oc4sVBtGdIeXHoNlnQrbTglBVDFYmqSKEESTGKoWMb1nH/jRiXh82caRW19SW2NccWX1HRh5sXpgIPHW7ZN0JwiHlGV9Mk6F/nR67Sb195IlK/aw2uOnEUh5Me91xMVfAPiXDLpmcny3e/126Kg2NLuwfMMtQXhpQiV12QI6GwShwVXZR3umQUcQygaTHP8H57bUasJMHsyIVqNg/xNi9JAQRC1vZ2PXFYJobPvULJ12gnGtM2jCGNMehqkAfgTxxht7vtS+aOv5IPyjgxT8mn0RoE/lMsPqEJbnwJ5OFwauz2eSZ0Y54OcNq0UnRJ0Cc0cQmEG+FVkCCOKDMw62+XggQbZ2jZEJgJfHqfirAsfTQhCmb0nzlROCaD6bRZJYd/ahEl6qNKQNY0RcrNYRBIrFoxGLfRXAYAShCwy+MJ9JXaGb9D3eEOEJFHggl0upE8cmD3X1DV7nXJhnwoX5dPJbJpWDyswZQUQIMSkP4o1Yx6QrNcYWG3zYWCa10VBnT3jJnowd2t6+3RKCMESwSYsJQTSp4UzF9p561YcnXGckVPORFqs1BPEcwI+6Tm2Pg/AImH6tFsUZ/DECPggg7tLHdwLr6Rn6EFusckntVa5TJKJTsunhNSaYaHJRbSablmWzw4+Z1J9rgvBZI0p1xDefNDIyUnDK4+dBqDCfexxEIUVdeEmlZenvX7mPEESto6ax6wtBNLZ9apJOE2uHX/xZ42movo0Xq/Wx8mnxXyPgsvY4X+VeWP340lUHttn2da6tnICPBzMwcPqi7YXXUwAdvQMcuqUj/sJp7glTB15P/9AqZlYHzcp79/keFHF8LpdSifJqembDg/DKC/hN7iEEMTN/UoQwky68lMuk7u3vX7mvEERNQ6bhKwtBNLyJqhdQs4XV98tc7blv34afA9Szo0fz2HwAQWyGZa3IrV+T9dNEu98/IHSkmTSNvB3ddl9mOiU/OvzT6lHeUbPeBNHTs2Iv22q7n4APO+Tz3YUURBCaMKJpmMkVXtqxwUEIoh6jprHbEIJobPtULZ1uMgSCv5b1J3F5ufpaDBPEhyCKzDg3P5r8flh9zUL5VrLp8Gx2+GF3XU2YyCjMpNnua0QsYbJXfq8nQSjPKm4XbwRoYEb/zHfCxok6jyeIIFQb1YSZNCfwp89gCEGYjozmLScE0by2C5S8a+nQ+8kuxer3dRQMDBlp4vu+oR535/rdUuYLyJrJO+jQlWehGQgPM3X3Dp0DYgdZhdeJMjxqJAhaPHDiHm2F4keIcAq4tLC/k6v/LQzryHxmzZhOLgOCcKXpDg+vubzQGbvbhCCijI7mLCsE0Zx2C5Vac+/DJrZoWX798H/6VdbH980Wq308CO1iqq7/vr6Tdi9i8h6AOiu/B53KdXscDDwTR3Egk7nt97r2NbqVtmqaeEehYJcLzHI21yKIv5RLp77jt6U3jCA0YaawBXoXEc84PwMhCNOR0bzlhCCa13a+kuvXE2A0WXf1Dp1MVFrEdT6hi9XaMwqEi/Pp5OUmEPuccfC9nUy3NTdoPUHjHT2mtmqOjd36gol8JmVmkSAKIL7ogH3w3aBLg8IIQhdmCtqI4N5B5U7xIQRhMiqau4wQRHPbTyu97sSx6VZQ/ZWk4YvVPgTxhXw6qc4zhD5RCUI1qNma60uCbo/KL59RqKABBWaBINRVo3mb+OyxdOrxMNkMCcI4zOQKL3lOmwtBhFmk+X8Xgmh+G3o00Nz4ZbwYq1/cRmg4ppoJ3il4NfXdROgXZtLcpFeX1Bpu4GsmCMLLzHgZjA2WhfuKE7F1UTwcE4KIEGZyh5c86T2EIFpw8nCpJATRYjbWnX2oj4rBC7rVTPC1EoQ2lMb0mdzo8A+cbXf2JRZboHUAdp/6f7hHVA1mNS5SV9PljDomBKENM2kwc4eXdLfRCUHUbLKGb0AIouFNFE1A3cGqaC34lg70QuaDIJSkmkSEd3fEd06MjPxkW0UT98QZ5RRxFOyaiCDcYSYvZjPTwGs9LiGIKKOjOcsKQTSn3bRS+4SH6qmh72L1fBGEZvF5xm4tjZcRtnOnaryahSA0YSb3DrfQ8JICSQii6qHSNBWFIJrGVOGC6s8xqJg2vRJe212CVX6k/WbmSfIPzcwXQfhszZ0mMu+Cffje/+hYTdVoFoIICzN5wks+t9AJQVQ7UpqnnhBE89gqVFLN2YfQxWW/RjULu6qob3vzRRClyc6zNZenQyY9fYNfYeDLFT3rmVrDjV2TEYRvmMm1e8k3tYcQROgr2fQFhCCa3oRTCvjkUtJeLGOqsvfksaqpX6yeT4LQbM0thUwWWfYzrkuMjHdzmWLkLNdMBOEOMzl2gD01Mx26v9coBFHNKGmuOkIQzWUvX2k7exN9FpHKmbRzpVA1N4c5O9CdifDbSjqfBKFYy3PHA9MpTPZvZu5eqm9qjWb2IHRhJuVdkW2POK+gDRpDQhAtMnkEqCEE0Ro21lwbCtNsnUEI6NpV5T2L1fNMENCk3rhenScgwjVlBasOt5kOkWbyIMoE4QozIUWEYWYMl9OhB95fLQRhOjKat5wQRPPablpy/dmH+izG6jwT3TmC+SYIDQaPAfyM48KiuqfWaHYPQrOb6Ukw/rDjXvHg8yJCEC0weYSoIATRAjbWnn3QHH6qRlWfvE6er/H5Jgilmyb1xrTKs5Fao9kJQhdmcuoUdl5ECKKaN6q56ghBNJe9PNJOnX3Y6xYACcePdV2M1eyO8ixWNwRB9CS62Sqtw+ziAmpWUmu0CEG4w0wVtUJDlEIQTT55GIgvBGEAUiMX0Z59MLgbIYpOursaAMw4cNYIBOHj7cxaao1WIAhdVtySXgZXkgpBRHmLmrOsEERz2m1a6lpugTNVPeCE9vRidSMQRClk0j/4RWJ8M0qoxBSHsHLNtkhd0UeT3NH33msnBkIQYSOi+X8XgmhiG/p8Mc/KYqzmStAZX+aNQhAaj2rWUmu0ggdRItW+QXeYKTS8pOoJQTTx5GEouhCEIVBSrDkQ8BJEfXZzNYf2IqUgUF8EhCDqi6e0Ns8IeC4GYjolPzr803kWS7oXBJoSASGIpjSbCK1DQBNyq+tuLkFdEFhoCAhBLDSLt7C+nnUSotW59PB5pT058ggCgkBkBIQgIkMmFRoRAeU9dGyjFAOHleULTBPRiDqITIJAoyEgBNFoFhF5QhHo7k68p6Nj8qWRkTu2JhKJ2LMvxA5m276agK7pysx3wsaJuVxqPLRBKSAICAJaBIQgZGA0HQJd/YMXEeOyAMFftdg6enR0TbrplBOBBYEGQkAIooGMIaKYIaC/p2K6bhHEX8qlU9+RtQczPKWUIOCHgBCEjI2mQ0B3YrmsRBGEKybe2O2ijRuvnWw6xURgQaDBEBCCaDCDiDjhCHQNrPozKthXAFgG4G0A1DrDQ2ThG9n1SRVWkl1L4TBKCUEgFAEhiFCIpIAgIAgIAgsTASGIhWl30VoQEAQEgVAEhCBCIZICgoAgIAgsTASEIBam3UVrQUAQEARCERCCCIVICggCgoAgsDAREIJYmHYXrQUBQUAQCEVACCIUIikgCAgCgsDCREAIYmHaXbQWBAQBQSAUASGIUIikgCAgCAgCCxMBIYiFaXfRWhAQBASBUASEIEIhkgKCgCAgCCxMBIQgmtzuXf2DXyTGN6fVINyQSydPb3K1RHxBQBBoAASEIBrACLWIIARRC3pSVxCoHYHO/sQHYjZ9vliIXTI2dusLtbfYOC0IQTSOLaqSRAiiKtikkiBQMwL9/Sv3LXLb/2XwpwH8IU6F/nR67aaaG26gBoQgGsgY1YgiBFENalJHEKgNgb6+oQ8XwfcB2Lvc0pNCELVhKrVnAQEhiFkAVZoUBEIQ6OxLLLZA6wDsLgQhw6VhERCCaFjTiGAtjIAQRAsbt5VUE4JoJWuKLs2CgBBEs1hqgcspBLHAB4CoPy8ICEHMC+zSaVQEhCCiIiblBYHaERCCqB3DWW9hYGAgvr2w1y0AEpXOGLgyn0meH9b54oET92wvFH4B0MGOutfnM8kzwy6919TdYoMPG8ukNvr129l54t5WvHA0iD4BYDGA/QDEHeVfAPhJBm4rWrHUw+vXPBOmg/q9GoIYGEi8dXvBuvrN/j7p7IMYP2Kbz8vlUuNBfScSidgzm2IfI7JPB+MwAO906PICAY+CcGN7jO8YGUn9yUQPtWWwwPE0gHc77HFsPpP813rX9/TFeLCjjZeXZaWuvlVLCLYaQ4c4dqm8BvCvieiaKHqZyG5aZsmSFXvE2uLHgfApEP05GHuU6yp7/TdA99tkXzuWTv1n0BhefGhi1/Zt+Pmb5XsqfRPj8uxo8mJTWVS5at+/2Rg/pTE9SXeCSjZTz4xdRQo7qz1+GoFOAvBeAG8rl1Pv3S8ZdM3k+G73btx47aQfBl19g8cQcJchRqFzgmE781qs6be5dvcOnQPi7+9AkcdiaDsyk7llSxCymi8A9U6Z1e1N9FlE9wLYeaoPzk4swlEbH0i94u5THaKxmL4L4FAAMUNrF5lxRzFmfT6MKKISxOLFZ7e17/TKaoDProIcqGdp4q/ZxlUAvc9Al9dA/HUUsDqMdBqBILZvRzvFrauZ+YQQW70Gxtcmtu32vaAJxQAfoyKdnSfvEotPXsqEv3F9VGjrM5Bn4jPH0qnH/Tro6Rv8CgNfjvreONvr6zv+XQXERgg4sPz/V8nmI7LZVM6n31kbP34E8cYbe77Uvmjr+SD8o4MU/GB5EaBP5TLD/6YjWCEIo+HaWIU0E70Rc3uJBSDgJdh8WDabeiRIS/ek7PP1Rd19g599k0S+DWCnKlH7o8XW8tHRNf/P96smQqoNP3IA6KaOuP3ZoK/97u7EThSzLmWw+rI2Jbqy2Dxmx4snjI2sfdZPj/kmCAt8hk10XZnITc2VnFjEZ+s+DEwbCCvX0zP0cbawBuB3hZV1/a68igtymeTVusmup2foQ2zxLwDsVa73us18xNhoKmPaj+bjzPdDabbHj44gUCwejVjsqwAGTXUCUGDwhflM6go3bkIQEVBslKI6d5mZTsmPDv80QEbq6h28kQinuMuE1dUMxAkGPpHPJB9wttXTP3g8M27SkMNrAH4LkCKhYmmyZfujoNIXuZdIZoY/PCqZehCKHDp22noxA5fMnODDycGfWKBY9WViKBf9KdUugz9GwAc1X7qPk104Kptd+wedXeaVIMBZZtpEhOMdsqkJdhSg3zN4F5oKN1UmU0cxunZifNdzZ8OT6O5PLAGTCrG5+y0A/ASIxsC0HeC3g7DUEXKqyFcE8Zdy6dR33JOdmrARw20AHVkpbBqeVeUHBk5ftL3wegqgo6frEy7Mp5Pfctt3LsaP5r18DuBHnfoBGAfhETD9OmSsaj8yu5eu+kvY/Jkp/ew9y7q3l/V9lRl3EdEb5b/HOU7/nB9Z89+NMldWI0fTh5iU0j29g5cx4SLHQA9cS9CtP5i+JF1Lh95PdunLa9+pOvzoRDy+bOPIrS9V2vj40lUHxm1bnbJ8v8MoW4hw3vY3dhvWTSblL6wzGPxPLld4AuDluUxKhbSqJQjq7k/8PZi+4fr6N/kC9qnLv7EZ571jPzyYSqUU0U0/U/Hetq8RcI6rv/s64nyCzlOZX4KYAWuBGNcUC22XjI399NXKLypu/uwmtd5S8jLU+lHlKTL4i/lMSoUR6/b09Kx8J1vxnwP4gKPRkmyFycmvbthw+8vOzpR8T/8Rh1hkfd/lbYwz86r8aMoTO9d4AJ6x7KeQ9z3AZrJpWTY7/JirzpyMHw1BOMV4jYDL2uN8lXvsqXe1zbavY5TW0nY8RKtz6eHz/NZyZJG6bkN99hvq6hs8lAAVNyyzuXfSdkrR6VlDcP4avA7R1Tt0MhHfPF1DM5C6+wY/B2C1o9VXLbaOHh1doxZhA5+epYlD2KbbAexSKRi0gGjgQdRCDtCv1eABFHkol0v9T4Ay1NWfOI2YVIij4hkViXB6Np3cgV+5gQYhiHEm/mw+nbrBb2Lo7k68BzG60zVxP1W0eNmG9SnlRdX8qMXficm9rmHCWY7G1ER/Rn40lQxagP74QGKfeAG3AjRQqavWJOyJyaPdpLJkaeKgmE3qY+egclmtN6xTyDvG+R4Ucbx7rWmuxk8AQWyGZa3IrV+T9TOMikJ0bKPUDJIgPIECD+Ryqed09YQgah7mc9dAd3dif8RpBIz3lHsNjKd29Q9+nhiVL77NAKvFKRUWUc8mtmhZfv2w2gnifqirb/A6As4o/1Bk5pXOrzOd642QrxFnJ9qdIYyb86PJU7ULZ8FrELpJWnVn4jmoctTdP3QlmM91yBgYKnIBpvBSnoQKa5Uf/YJ+QxAE85dyoymVOp2DRm9X36pOgn2PI82CKn5uLpO8qh6jXrM+4Bsq0k7eUySmJv53VMYpEZ2STQ+v8Y61vW8AWO3sKT0mYSZteEof1p2z8eNDEGqzx7n50aRjE4veQt19iSOAEvFXQkZbyabDs9nhh3U1hCDqMdLnqA3dpAqmz+RGh3/gFsFTlvEggHtApcXkqZeE6fj86PBad93SVtW2olpr+FD5N8+X49TLQ59ioA/ARwnY1WY+Icrin8crCFiHCPIgdOsgTPj5ZAefZLKwqvnC9PUA/Ext+pXaAATxmD0ZO9QkXbP2Cz9krSjKq+DeYeTnAQS1qdmldHdHfOfEyMhPtjnrdfUmjiUiNdbLGw+CvW9VV0NgWg9qLsePliBCvAAnDpodWYosfbdZC0FEGdENUNYT+gFSHfHNJ42MjBSc4rm9DfXFxMwp57ZVv68obyhL30etcNSDIGolB6WDZ/KI8MJVMNCRty5kNt8EQcBXs5nkV0xtpxkLQZ6nabPQTXTss/gb1Kg7jMrAM3EUBzKZ237vrKf56Alc8yqNC7fXCrqlI/7Cae53bS7Hj48HoZ0DdLj19Z20exGT9wDUOf2hKAShdna2xuNZNPOZzFwvTilExG3FX1qF+PrpWKzP16B7MdzPS6kV0VoJghk3E6B2cTl2v3A6hrblYedDnLK79SVg3Z/e0rHi0ftvej2Kjl39gxcR47IdddjzNTvPBBF5i2fnwMoDZowZoMhMx+RHh1XoqepH8yVbVbsa+XzXF7r6Br9HgFqQnXoCQqKaidgTZq00M5fjx4dYL86nk5ebGENbXwiidQjCdPupa/ItffW9saj96be+sf12xyKV52tQ035dvhgrg1ftrGorFLsJOBGA2jpYOempAsPOk74zxrsmxPQEuLTA7d4aabxQrjrQhu3AvwOsfzd54WaW4Y8AWOIgCM+BxHkmiKfseGFp0DkNt871+tJ3t6vZQKG+6O8GrOldcib4M/NbiHCsc7OD3xZuTZ++4TZNaEVbdq7Hj489vpBPJ9V5htBHCEIPUct4EEo9z3ZXl2vuWUB2TLyuup6vIo+HUkXMWfU/MfHq3rYVP9gCHcjES8ClifPPAg/TRSGIwFeBRyYW4TiT9YeQbYOhL1xIAc/lKvNMEA9ZvO2Y0dG71BkVo8c0dGbUmKNQxMNYkZr3C1VpzhL5hpk06yPa1DZzPX6iTvBGhC8eROt4EMrgmu2uM0IZuvWHSt6mrt6hI4lYHUoqLda54+TuNQ7TuLDaZx2z7fMJGAJwQKQ3ulK4eoJQh3Y6ZpxFMNypM9cv+LwSRBVkr0zT3T/4EzBOm7Yp4YZcOnl6VTYuV5oPgii9O57dcN5zABoi8Q3NzfX4EYKoZdT5120pD8J9AM69MOcikBlegjv264y3a74WQ2PWUfPnOEykvmJVHqnKFsVoIabphnisCOvUGNvfAtFyR/tqX/gRufVr/iNoSM31Cy4EMWWN+SIIzc4kT+iopyfRzVYpB1n5jI5/DrK5Hj9CEEIQJggEnlNwLZbOWEM4+PBP7uxch3CSi/ecRfBhuqkFwtjPnDsitMITXgarLJzIA/SQxTQ6OrpmU1f/4AXEUPvxp57IHsSO3Efag0rMd8LGiUEJ9GYrxu5nxGYjiCipJkwGbqWMhiDm5K5jzdkGT5hVs+jsu/NrrsePEESUUWZetqU8iNIXmOukcyVUFLT+UIHLuw4xtSvFHboKOkyk8s607bT1B47DdJXmt4Kwhm26q82afGSffWKb3SkqpicJt7sfjSA22vHCcY4FV81hNbXjJvgAkZswlWwqHXh2NPlp8+FlXnI+CYKB3/JkbKnJGYiKRr29x77NpkUqJPlXO4hcf/bGHIXS+J0Z6jRMIBmlD7+ynjAqMJ2yRrMN1C+1Rqn5uR4/QhD1GAHeNlqPINy5ksqTa6Fg7+VMTayb5P3WIVzEEbhP3OuGl0C/F0U+OSQ1xbR1at3m6o6D9/Ss2Mu22u4n4MOOIfA0irwsl0s94Te0enoHfzgj3UOVsXqToetzP4fxfRA9PYmPwKJ1DOy5w/HSH3TSkFHkHWma7ajGaSqC8NDo4buN1ATXKGU8B9scW8U163va1BrO/uZy/AhBRLG0edmWIwiNq1x6+WHz/o58TdqXzvvS8932ZPwsq62wdvpylZDDYp6zEkDoROwylzfTbBQPwmehtHxoSaVamM4Yy8D1k+O7neOXiVSTEj3wq9Fn2FXSLahLnZ5VWWyZ7XWL2l68zXmwSvuC+5xo1/XjJndVxu8krIYgirpUFEGvUT0Ogena1yaSjJCqpdKmWlOwLf75m2lO1EHRRwj4HTFfNTqaetpPr6m1thmpN6bfE89ZCZ9MBc625338BOxCcmMQlWDkJLU5yTRcSfcXuNr/bYE/4Mj4qv1i1LjFT4HwBTB+vCPvjv7UqALBZ++3NsWBH2iak63R1iB8CMIn9DXBzKfmR1PDOnk0C5dq0r00n0mqy1cC8xVV2isnt3PmBdLm+6n1oJNnAotGECqApj0NrMNFM5FGqh/ywujyF0X/yPDkwArMMTYtkjsnkfK044h/xXnK2O9UtluveR8/QhA1z80t50EoRDRpBtYQ420gqOs+AydcdziJCPcylw4cTVUNuGtCt3AZ8fSxbr2gLgShZNdN1gAes+OFI3WHxEremIVbPbugiI/JpVMbwkZfKWdRYe8rGaxuQqs84wzrqHxmzYizvg+5hoYxAvSK4kGoZsZt5uVjo6l1YXp19iYOs6iU2K3ijYWmpwhr0/m7pn1FQMb3TkzdW2Cr3UbOk/RrO+I7n+zOxeSWy/uBwmPMuJyI1NW+5RsUzch0bseP58rRwFxKbr3Fg9CP0JYkCI2bvrk8uEsDPGiRWReqcEAXGqv2xF2BLQzryHxmzVjQJFG6b+B55a2QSg3gvKtaVfM9yGWQ7ntGt129g58hKqUin74VjkDXtMdfOM+dS6dMtu7JUOH3W1h0nE/G20p/1NWbGCSi62ccAgzYQeXN8YNxInwym07e5oddd3fifyFGygNSV7rOeCKEmKbI30Cv8qUxP5tx50Kd12Z8JtYiAZduH9/tsqDLiXzwMCY/hYPLG9tKhPWOj6RIayI6sjPBWTFilPETdYKvN0GYelVRPhQaoWxLEkRpcM1My+3EOnCA67I67qjszSHkNmJP/9Aq5tJ9EY5rOen3ZNmfzq5PqTSTd0MUAAAV4ElEQVQVM0IzpQvcn6cuML5DQJfPoPDd6hiVIMqHne5w3hcQ9PXs4wUoMbeA+QLYuMVzB4D/HcqbEeB9+NwdoPo594D9MOzc9bXjghxc6Xc/dlSCKGP/4pu6nX/Avpx09/fsHzGk8hS50nxHSmFi+tLrvYASjd1tMf5+dDT1X662Au57Nvc+VJs+Gy0q3RlnvVUV5mr8zDVBaC5MKoL5kgP2w7f9diea2r6RyrUqQXgzke5APdAL0G3Pq1Q1OT1dvk3tbp/J/gUAWYDUJKSuLfwQQH/huUxdLYRzKTxQuTTIN1dQVIJQvfb2ruq3yb57Rp4en0tlVHnthSo78HRe46h0+jBAizVekLqM5+/y6dQ1fi+Az0U5leKbGXiQQK/6XLH5OEAZgM+etpdPDFq3SK0EB9A2LdvUGZX1U7bit5c9lB35saYKRrqnIeqLH3BtrWrqWQYyCo/AK1EJuTgKx6fTazeZ9q+7xncHLsE3ren6mIvxM9cE4XsrZWnc0CsMLsTYOsvkkjBTu8xHuZYlCF9PwCAcoNmJVPpitsGHjWVSG8MM1du76mM22SpG7byaMqya+r0Apiu4ja5Gwb6PgPeWK/leXlINQUxdBDT4XTD+1ilU0AL01KRB10a8AL7SvLrf+YJcJqlulwtc3DY+ZOgQvBKyAPMxzgOGETyILQS6hMEXR7CZsU4mhvcr09Of+AQzqbvNd4/ezo4Dk1HrasJ9qomqt/LO9viZa4Lwe4dmvE8B65VR7TFf5VuWILQ3uxnemKVfhwg+Pe024JK+ofda4BsCwkbOKupO5wds4i+MpVOPRzmlWyVBoJwOWqWmrlx+VCLBoPWSqXuZafDN9Rx1udL+JoNWXXbDxGcqvUzKqzIR0pSoA393FNv43IdHUs97dq+ZexAl8qd47GUqFG8EqD9I1mp0MtVdV650bzLzt5n5eI1npqvyGoi/jgJWB52WD5JJtwMJ8E+tYaLfbI6feSAI6K53deIQdFWwCV6NUKZlCUKBq/kKMlpg03kf1Ri7sr5g2XQWE6tJ553TL3jJFeX/YuC2ohVLPbx+zTPOAeG+89fvVrFqCaKET29iiIhudFyzqP59X0ecT3Bf7u6UTW2ZjS/a0hmDdSaT3QuQSkJY2dHzGsBPM+huG/TjDZnh34V5DX4vwlSiQz6HwCsdGW/Vvv4/gLDOBv/LWDqlroYteSW1EoTyDpXNnnseRzDjcwCpWwFVWKkIxjOwcK/N/KOxTOqX1epUy0uvdhjF2opDDB4C6N0A9i63pz4wngf4UcC6viNu3xNkPxMZfHbkRbpUya+f2Rg/80EQSj+1oYBi1hnM9lkgep8rK7PxhUUmNpmPMi1NEPMBqPTZ+Aho1iCMw4eNr51IKAjUDwEhiPphKS01CQJCEE1iKBFz3hEQgph3E4gAc42AEMRcIy79NSsCQhDNajmRu2oEhCCqhk4qLjAEhCAWmMFFXUAIQkaBIGCGgBCEGU5SqoUQEIJoIWOKKrOKgBDErMIrjTciAkIQjWgVkakRERCCaESriEyzioAQxKzCK423EAJCEC1kTFHFDAEhCDOcpJQgIAQhY2DBISAEseBMLgpXiYAQRJXASTVBQBAQBFodASGIVrew6CcICAKCQJUICEFUCZxUEwQEAUGg1REQgmh1C4t+goAgIAhUiYAQRJXASTVBQBAQBFodASGIVrew6CcICAKCQJUICEFUCZxUEwQEAUGg1REQgmh1C4t+goAgIAhUiYAQRJXASTVBQBAQBFodASGIVrew6CcICAKCQJUICEFUCZxUEwQEAUGg1REQgmh1C4t+goAgIAhUiYAQRJXASTVBQBAQBFodASGIVrew6CcICAKCQJUICEFUCZxUEwQEAUGg1REQgmh1C4t+s45AZ19isQVaB2D3cmdPxqnQn06v3eTuvKt/8IvE+Ob0/wk35NLJ02ddSOlAEKgCASGIKkCTKoKAEwEhCBkPrYqAEESrWlb0mjMEhCDmDGrpaI4REIKYY8Clu9ZDQAii9WwqGk0hIAQhI0EQqBEBIYgaAZTqDYuAEETDmkYEaxYEohBEs+gkcgoC4kHIGBAE6oCAEEQdQJQmGhIB8SAa0iwiVDMhIATRTNYSWaMgIAQRBS0pKwhoEBCCkGHRqggIQbSAZbv6Bo8h4K6KKky4MJ9Ofkv93d2d2AkWVoDwOYD+AsDbyuVeAPAgE646cB/Op1KpYrVQJBKJ2DObYh8jsk8H4zAA7wQQr/RDwKMg3Nge4ztGRlJ/MulnYCDx1u2TdCcIh5TLzzh8tmTJij2s9vhpBDoJwHtn6sW/ZNA1k+O73btx47WTJv25y5T6L1hHAvYZIFoCxh7lMs+CcLdl8z+Pjqb+S/0vCkGYHpSbb/3VuKE4PsGMTwH0UQB7l/QnvAzmDW583XoxcGw+k/zXarCXOo2DgBBE49iiakn8CKKnZ+jjbNk3AvS+4Mb5NyB8JpdOPRRRCOpZmvhrtnFVeB+lll8D8ddRwOpcLjUe1JffBPnGG3u+1L5o6/kg/KODFPyaehGgT+Uyw/8GgE10U2T37CYafPNU9PcAvD2gTgFMV8C2v2zH8IF6n6SeL/0VBXT1JgaJ6F9C9FeQTo8bIQiT0dV8ZYQgms9mHol1BEFkZWDbtwPYy1BFNWFfkMskrzaZTEtfmDHrUgafDyBm2Ee5GI/Z8eIJYyNrn/Wrp5sgUSwejVjsqwDUBG76FBh8YT6TuiJML9XntgJdScCppjoR40dF8A0WkfLg6pZqYz70X7z47Lb2t2y9HIzPm+oPYJyZz7CI/oyBf6oYRTwI0+HZ2OWEIBrbPkbSeQgC+CGAv6Kp0Evl2czAgwR6FeB3AegFsJOrg3EifDKbTt4W1HFpItnpldUAn+0pR3iZGCrE85SaZBj8MQI+6Ag5Vao8TnbhqGx27R90fWkmyOcAfhSgIx3lx0F4BEy/Dulriw0+bCyT2uinV6BOwDR2BD6IgS6n90KEu5ixFMBu5fZrzsU01/orz6G7P/H3YPqGhxxKYSWsB+hFgN8OwlJHyE2pPA5W3gT9pRCE0SvbNIWEIJrGVP6CugnCVfJFAOcfsC8nnesM5a/lvyPgEtfkvRmWdURu/Zr/8OnRZyLh39iM896xHx50r2dMrRe0fY2Ac1yTz30dcT5Bty6hmSCd4rxGwGXtcb7KXffjS1cd2Gbb1zFKayE7HqLVufTweX5eRE//4CnM+IlLvj8CfOYB+2KdUydFJh1v2TrEjCsdXoOzt9kgiFnVv6s3cSwRrXF9NGjHjkkYTjyIFphY5CR1axjRjyAY+C0sOi6/fvg//Sb7crz5+pkTA93SEX/htJGRkYK7nmZBVhV5AEUeyuVS/xOAKHX1J04jJhXCqnguRSKcnk0nb3bXCyAIRWArcuvXZH29gUMTu3Zso9QMkiA8gQIP5HKp59z1enpW7GVbbfcT8GHHb4+jyMtzudQTfv109yeWgEktxLrDeLNJEHXXv0zgd9OUZ1R6DMYOupYOvR823+HyVCv1ZZG6BaYX8SBawIg+BLGFYR2Zz6wZC1GRunsTF4JKoYXKs5lsWpbNDj/mqkvd/UNXgvlc50QaFCpy1+/qG1SehPJaKlNRdmIRjtr4QOoVZ1kfgigy49z8aPL7YWbr7kscAdCdANrLZbeSTYdns8MPewiif2gVMyuSqqylvGqxdfTo6Jp0WD9dvYkhIrrR0Y+qMlsEMVf6j9vMy8dGUyqFeeDT27uq3yb7bgC7OAuKBxGGXHP8LgTRHHYKlFJLECEhFWeDKiwTt+37ALx/etp2bJWt/G/J0sRBMZt+AeCg8v98PQA/gTVtTDDwiXwm+UAoQQR4Ae7++vqOf1cBsRECDpzWSbP1cmBgIL69sNctABI72vD3oNz9lLYRx3Cba21kdgiiAfWfWrvwfDQoD0Q8iBaYW4QgWsCIGoJ4lWw+IptN5UzV6+ob/B4BKkZf+bK/uyO+c2Jk5CfbKv8px6nXTn9pR5iwKm3oJmRiXJ4dTV4cShBAqiO++SRd6MtLECftXsTkPQB1BhFEd3dif8RpBIz3TJdjOiU/OvxTY+x6h04mKnkglWd2CGIW9NcQaZGZV+ZHU9PnasJw6OxN9FlE9wLYOQjrsHbk98ZDQAii8WwSWSIvQfBYDG1HZjK3bDFtrKt3aCURT+9eUjFonowtHRu7VR2oKz09vYOXMeGiyt8ErPvTWzpWPHr/Ta+b9qPKdfUPXkSMy4LISBdiYsLF+XTycpO+tPU1X7WayW0TW7QsYN3G031PT+IjsGgdA3uWf5wVgpgN/bv6Bg8lQJ0TKYXiGHgmjuJAJnPb701wVmU6O0/cm9qK651rEeJBmKLX2OWEIBrbPkbSeba5Mm7OjybVXn6jw2Gll9x7beaMraH6UAz/DrD+3UjIGYX4IwCWOAjCQ2g+BPGFfDqpzjOEPqYEYUKMYZ1pJsjZIoi669/dO3QOiJ1rOg9ZvO2Y0dG7XgvTu/L7wYd/cue3vrH9duemACEIU/Qau5wQRGPbx0g6zUE54y/tSgeaUMPrNvMRY6OpjCoTsu3USM6AQp4J1XSC92vTtL4n9QXjwY42Xm6aEsQHm9khiAhx/Qj6z/TmqtBfYdDdP/gTME6r2EMIotZXojHqC0E0hh1qkiIoF5Npw/39K/ctcFzt2nm37iUXgvBHMixvkrNmDbmYIi38mhKEe2IH4YZcOnm66biplBOCiIpYc5QXgmgOOwVKKQThhcd0glzoHoQQRAtMALOoghDELII7V03XgyDUoSeyWW1h3bcst2sNwpNdFc6ssfXW1XSClxCTHgFT/DwbBiTEVO+h3NTtCUE0tfmmhHcThEoglx1NfjqKalOZX/l+Rz6hGbt5dAuR1fRjKpPpBFczQbhSpQcdcvPrq6/Ps6W2mdYgPk+M7zp0k0Vq00G6AMoJQbSAkTXbXD1nGMLU7PLs5edHJ+LxZRtHbn2pUrend/CHTDhruq0qvzbDZFG/zxVBaIgxNLGfW37NAn/zEETv0JFErNKFlE6RV7PNdfHAiXu2Fwq/AOjgCjaySG0yyhu/jBBE49soVELNQbmnihYv27A+pTKqmjzU1Td4HQFnOF7w6/OZ5JnOrbKaLZF+KTmC+qycvFUnl58F6BFme92ithdvcx6AmyuC0O3hB9NncqPDPzABruTBTSW623GAcJZSbUSZdE3x05DbBMDLc5mUOvhm9MhBOSOYmrKQEERTmm2m0BqCKBLRKdn0sMrOGfroU2h46/f0DH2IrdI6xXRyOgYuzWeS6vIeozMX3d2J9yBWStfxDgcZXZnPJNW9EtOP6QTnp1yE+h5yRATPaOp8yN43AKxutqs8TeNBDAycvmh74fUUQEfvEN881UjpgiFPfq3SYJBUG6FvXuMXEIJofBuFSqjLxcTAryx78vBs9vbNIQ1Qd//gd8H4W0e5x+zJ2KHOU9Tqt/L1pbeCaLmj7GYQH5NLpzaECaom04nC3lcy+G8cZccZ1lH5zJqReSIIaBL7GeeY8klW1zQEoTDvqSFZYffSVX8J21bexoyMtkIQYW9Dc/wuBNEcdgqU0v8+CLqpI25/NuDQF3X3DX72zRw633am+w7andTZmzjMolKW1OnLhkxSQzuuspyZWpz5Ttg40X0FaQQPQItNlPp+xMfAye4kgs7Oyt6QwuIDLiGaiiB06b7fvLUvNN1558DKA6xC7GfOfFcOr1A8iBaYW4QgWsCIQRcGMZBn4jPH0qnHnap2dp68C7VNfsN9iY8qb09MHr1hw+0v66Dx8QJU0S1gvgA2bnFP9qqvWHzyUiYozyFu4n1EmeD1cmq25QaEPXzudtDeoT11YY66kIiuA7Cfpv+mIgglv8+FQX9kpv9z4H72nc4Lk5T+T/8Rh1hkfb98O6EHAvEgWmBikQuDWsOIGoKYBGA57jcogqAWrEfBtB2wPwzQYs01oEbhosW6C3l2QOm8BhQBfY0z8d/l06lr6jHBu9uohmB6+gePZ8ZNmqtY1Q12+alrVLVXbrq7bzqCmErb7Qk1TukVfuWoe7zJGkRrTC0QD6IFDKnZ5jpCoIcYUCm0nV/sAdrS72HRCQFXjc6oq0iifRtd+2YoYrAKCMcBXJDLJNXtctrF7WomeKccVdbX3XoXpp5ar1jDzAcB1FMu3IwEgdJVqju98j2eumu8cnlSmP5bAP4HgL7ol6YlrAH5vXEREIJoXNsYS+YhCMaDdqFthdVWWArwjwG8PaCxAjGuKRbaLhkb++mrxp2qG3ZKoRZSBKHWMPY3qesX8qqHB1AHgig10dmf+AAxqW2/01dw+uj2GhNdPNlh39g+TmtBOKSZCULJbnLftAOLx9iiwTae3OrK41VkpmPyo8P3mIwJKdO4CAhBNK5tjCXTEUQlI+nUWsPEWQCdSsAHyx7FOJh/Awu3xlG8OZ1eu8m4M01B9eUZX7SlMwbrTCa7F6ADHGGa1wB+mkF326Afb8gM/85kS2yVHsC0dLXWVxPlM89TFzE+B2ApgH3KX9Ul7Jhwsz1RuEGt1TRzsj4/uyudJop0HBinMuGjYOxRKlsKN/EGIly1/z64V61NaBI9Rj5sWMv4k7qzh4AQxOxhO2ctBxHEnAkhHS1YBNyH7Qh4CTYfls2mHlmwoLSI4kIQLWBIIYgWMGITq6BJV+K7BtPEai5I0YUgWsDsQhAtYMR5UqEUHitQCsCfA3gEzL+GjWtzudRzpiJ19w2qMNzqSvlqr6I17U/KzR0CQhBzh/Ws9SQEMWvQLoiG3XdCEOPy7GhS7YALfXSH7KLUD+1ACswrAkIQ8wp/fToXgqgPjgu1FfelSaWT8XHrf+dH1vx3ECZqc0L7Tq+sxtS22MrzKtl8RDabyi1UPFtJbyGIFrCmEEQLGHEeVejsSyy2QOsA7L5DDP6NzTjvHfvhQecp6srvKsGjVaRvE+E455kJAl3THn/hPGdm3nlUTbquEQEhiBoBbITqQhCNYIWmliHwFDUxfjl1ilw9rM7UqAOBe3s0JuTiKBxf67bppkayxYQXgmgBgwpBtIAR51mFqcVq62qAP1mNKGphejLOpz48knq+mvpSpzEREIJoTLtEkkoIIhJcUtgHgYinqCutbAXjMth8lTtJowDd/AgIQTS/DT13Uke58KYF1BcV6oxAKSdTxyt/DcKJmpPxBQB/IKY0GLdu377rv2/ceK1K1idPCyIgBNGCRhWVBAFBQBCoBwJCEPVAUdoQBAQBQaAFERCCaEGjikqCgCAgCNQDASGIeqAobQgCgoAg0IIICEG0oFFFJUFAEBAE6oGAEEQ9UJQ2BAFBQBBoQQSEIFrQqKKSICAICAL1QEAIoh4oShuCgCAgCLQgAkIQLWhUUUkQEAQEgXogIARRDxSlDUFAEBAEWhABIYgWNKqoJAgIAoJAPRAQgqgHitKGICAICAItiIAQRAsaVVQSBAQBQaAeCAhB1ANFaUMQEAQEgRZE4P8DLfZkEZ5avf0AAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-24"><g><path d="M 31.61 171 L 70.39 171 C 87.29 171 101 184.43 101 201 C 101 217.57 87.29 231 70.39 231 L 31.61 231 C 14.71 231 1 217.57 1 201 C 1 184.43 14.71 171 31.61 171 Z" fill="#0cf232" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 201px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Kernel resumes system</div></div></div></foreignObject><image x="2" y="187" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tnX18XFWZx3/PnUkTRGlZVgpYQNQPu6Cia6GZZJIYF6iAQEthJuGlUD+sgMqCb/iCrKLAIotvdAsIyktBoZmhpXUriK01NpNJUiyLCMgigkrlpSxbCkKaZOY+y5nMpDd3zr1z72Rmkpl57n/JnHPuOd/z3PM7r88hyCMEhIAQEAJCQEOAhIoQEAJCQAgIAR0BEQixCyEgBISAENASEIEQwxACQkAICAERCLEBISAEhIAQ8E5ARhDeWUlIISAEhEBdERCBqKvqlsIKASEgBLwTEIHwzkpCCgEhIATqioAIRF1VtxRWCAgBIeCdwLQKRKg9+kViXGPJ7h+DlGrv61vzvPciTA7Z2h49lRl3AtjD+gsT7htr5DO2bozvLDZtiVc6Au3tS/ZPcbAPwLtzqTJw8mAi9l+le4ukJASEwFQI1JRAOIkDgNhoE58n4jAVUyltXBGI0vKU1IRAOQjUjECEwl1LiPh2AG+zgRJxKIflTDFNEYgpApToQqACBGpCIFrbIx9jJjWttLeIQwWspgSvEIEoAURJQgiUmUDVC0SoLXoMAT8BsO9kVnRnY9D8VG9v/G9lZijJF0FABKIIaBJFCFSYQFULREtHdytM814RhwpbTQleJwJRAoiShBAoM4GqFYiW9sgCMKkdLzJyKLORlCN5EYhyUJU0hUBpCVSlQIg4lNYIpiM1EYjpoC7vFAL+CFSdQITD3UeaZK4DcIC1qMT4EZt80cBAfNgfAgk9HQREIKaDurxTCPgjUFUC0dLR/U8w+R6A31UucejsjLx1JGUcD5gfB+hDAOZm35UC8Gdi6jMN/tGB+/FgPB5Pe8EdaoueRMBPc2GZ8KXBvth/tLRE9oCBcwH6PAjvBJAC+CmGsTpt0E0Pbl71rIrjFF/9FolEAs++QCFifBpAB4D9AAQAKKH8E4PWWNPykl97mMw7ng8cSWQuA+NYAAcDCGbDvUjAIyDcMSvAa71uCii3QGTqcYzWgfDP2XxOHMJsbo8cbmQOaNLRmQOVhJfBvIVBN44Nz/n51q03jzlxKod92N/V3Hz63EBDuovBXSD6BzD2sdjgcwCGAIo3Bs37vfBubovMN0AbLLv8dpjgY4cS8a1e7MFPfPvhV+vhx6y9nwJStkrvt2xJf/FN293EhOudvqsFC07Zx5gVPIcYZ4HoH7MHYTPfJANr04ZxXe578VIma5hy2Lc9D/OPicxuHKGTwDibgSMs7YpqQ14g4HFm7kmPpdZu2XLvy37LUK7wVSMQoY6uw2DyWgIOLYc4ZIw3iAvB9G+asxQa/vwEGfh0cnP8VwDYrYJ0DTwHUncZqcA9ADXr4/Ijo8Hg0Vt77/5fJ4FY0NZ1qAFeSUCogIGkiegeTpmfGhiI/58PY6LWjshH2MT1QOajLPS8BuIrkMKKQiO56RAIpPnDCNBiANfaT9pPFIzpgoH+npvsBS2nfeTedVRnZL+GtPF9Zj7VIsBuzD3x9tPA617mJ76DQKxvaev6GMC3Ani7W4EI2DAW5LMf7I2/sLsDZHyKmK8q8F2mCPjGyPCca9wE3vbustl37j2ZDkWargDjfEebm5ypFDFuTKcaLhsa+smrhT64cv9eFQLR0hJ5DwKkppUOnwyEbh4dnn2hD4PQ8gx1dr+TUulVzo21YzWkQfje6BtzLnXLg72BB+hbBJ7PyPTGtY8y9mQidrn6UScQBvgxh7Mfjpll4LeGmVqUTK75cyHDUg0iBYwrGXxxdkRSKIrldx4yg+nThnrXbHOKNB0CQcByBr7l8qE+kzb46C2b489Y811u+1DvcrZxL9i5NxXE6blG1R7DTwNfcoFgXgTCewikXOrkRp2uhVIiMdLEEezY+43GPXZex+DzPNpgmoHvDyZilxTqtJXbvrN1+ncIUA+AY7zUojUMA0/CoMWDm3t+7zduKcPPeIFobV1yMBvB+8olDs7pIw3Gs0wYJNCrDN6LgDYA8/IrwF2o8gQiM6VhnTbgrYDxW4BV70oZ0zCZdHQy2fOoTiCI8FPmzKjBuoNrGwMJlddMOoQOyzsmsqzWamY1bP9kb2+vGp5rn/nzz2uYtcfOFRj/MCc/hJeJ8RCDVCMaYPCRBLxX8/E/TmbqBCcxmgaBGAUwYumFbmdgE4FeB8xQZoREdONAX89F1salEvaRmX7YRXFNh+E1gH8HGBk7cLNBBm4bG55zvq6jMp0CAeBuAGrUlvONpqZRx+2duBFAGIxD7AJAwJeZ2ATT1ZbfXgOwEaCXLN+K3XPCq2TycclkfGA67dvlGxoG8xMg4yEAaTcGAPeONmHxdLoImtEC4fBxpgl088jw7IunOnJw+DDTzFhrBvgSe08SaojRfvr7DU7dAtCRFgNMM/iLg4n4d3VGmT+CyIWip8lEdzLZ82DuP8qwmppePrSh4eX/yTXizvEzc1uDTIHzh/ru/p21YVPzqtuep3MAfN82NN9uFR9NfqmlPfIF24epkn7CZFx00AHYZF97GZ8fbvgmITOMVusfueeBxiCfppsnnwaByOVJ2c91nDYvs06DHdXRfSCM9Ji1F14p+2gJR84FkZrWyrEbJsLFI2/MuV1j49TS0f1BmOYdAN5nYe3YME6zQExwZ+Amc3Tsa7Y5dmppjy4EQ5XH2uFR60BGlskOMF847wD0WG0vu6bxZRB9dZLdEa2wC72FU0XsO9TW3UkwVcc2J4xqdHN1U5Cv0X0PCzoihwRNusnWSVBTw2cl+3pWlXJU4CetGSsQShxMI7iOgA/YCvTHANILE4nVT/spqLbhzvcmmwbzZfMOwLVuC9DZhcobAF5qSfcvSPPRAwPxp+zvcmjgdzCM4wcTq4YKlcNJILzs3NI5MMwtkuveq2lMVLCNSHNXgfULCrVHziGmG6wfBRGWJftiP7a/a7oEwq2nnVdvFbCPzs5lTSOp1+MAnWh5/4UDidj1bnahpr2QMh+wrskxsHwwEVNTgpOeGSAQqqf8lYG++Ledpn5a2qJqk8UKTZm3g/ikgb74Fh0P1aFq2OOVmwj4+O7fd6/feWBRFvsOtUWvI0CNRscfd9HKBFEdklm7sBagTktZ1jcG94z09t6+q1A7UY7fZ6RAjAYQcF3AZV4HE6cXWgh1A6Z2ihgN6Y2Te2He1zSyveb11gVi67qB9d36Bp7uagy+eI7bVE8uDV388fWEsYXJ5L3b3cqZ6WUFsBqg43PhmPHjwf7Y2ZqPlVrau5ar3polTdepItu7KdQWVSOJyywGnhxtwgn2YfI0CUTB6YdcvitlH+o91JDebGnoPe8wym9UeSiAhuMTibt2WOtl+gWC70cap7p9r21tp74rhUAvAQda8q5G8xcO9sd+4CqW4+52fgZgVjbc82zQ0Zr5+4rY9xELl+751jdG7rWOBry6sm9pixwHZNZbM2Vh4Nkg0p2l6BAXIyAzTiCYKEpsfmeyiuYVrWCPpBCM1vaubmZWPdvcsN5xBOCUVn4a+p6LtoFnOmuwv0f5kCr4aONnt8oWjAygNRy9igmXToRlbGps4EX2oa4a5gZM+iWQmRNWT9ppBOD0Xk0aowx8bDARU2I88UyPQOgbUF1ZKmUfGg6vm8zHDfXHE4XqtrW16yg2WDVErwN4yAAe5jQvtzfE0ywQnqZJNNuSAcJTSHHnwED8r64C0dF1GJms7Hb/bDityFbKvnVlYY/fe3PnknlGKrABILU+8zCDHm8g87q+vvhLheyhHL/PNIHYAfCLti2Vap/wagBq2GWdo/Q8RaMBp3q6t1iHpWrqYTARO7fQ7gdrWppej/bj1jTwr5BJC61rDwV6SJPOUQDw3IiodEPhrjOJMmI4/jgIRCgcOZmI1kyIpscP1Jr3zs7O4Ehq37vUEY3c/4nx78n+mJonnlaBcBk52fFXzD7C4ZPfZlKTchnz4d2ZcN+V5LchmGaBcOrNTyqGzm4AxBuD288oNMrWiKxWICpo3xQKR+8gwlm7P7mZsSvJr+3MNIGw5z8zUpi3H7677QV8Ln/hFI+awdTxbtspdUDa2s7YO42x+63bWpnwucG+2Pf8ANR+3Jp99BqB8HVznib+M2Yw1eG13HnxHQTCPtJQ2w3/9pbGUx75xZ2qh+r5CbVHLyWG2reeU6S8edTpGEG4rb1MFv7K2kdrW/RyBr5uA/wKCKsMk1bu2jV761Q2ZEyvQHgftbW0R28HQ22syPZj9GsqdkP0KhCVtG/NCFRle5iBdQRe2Rjcs3e61hU8f8hq6cRP4FKH1Vw5an3FpAXj8YVhugfARyfnw/u6QS6ew3znAwAVPB9gfTeDG2g8PxNuP3S95fwG3vtHo96Xdw4CeJLHAh1DQ3erE6gFHy8Coe/B8R8AQx0E9PnwBwEssAhE3tz4tAiEx2F+pe0jewZCTZEc5AB6GISHYdJKbqAHBntXKTt1PZxpTWdaBcKhM6IrZ55AeJxG9SIQlbZv3RqlrcwpBh4jRg8HaO2Bc80nvXpm8PkxTin4TBUI7W6icPjU95oU+IXND5PveXKHnTpTAjkRmbByoC+2zJqYlwba7eWViK+dAy4NEZVK3ohpWgTC453XlbaPTCfA+UZEXS1sB2ENs3H7gfunf1OoYZlWgfA4TaQKWV6ByHO9Ujrr1ti3StzJb5zDi9UZj/Vk0u0jI7N/NZURYykLNhMFwnWraWt79CxmqKtFrfvtt8MwjhvYvOq/vcCpdANQiQZ+qgIjArGbYKXtI/dm5SOKmNTaWCHXKdbqfoWA76THGpY7uWaYVoHQdJicbLXWBEKVU52vCaTN7xFlDgta2yy3T1b5Ubs1SKmr+vrWPO+lTStXmJkmEGkCrhwZnnOVk4Kqfc+Nb9l5JzN3WaHkjud7OXVY6QZABEJGEG4jTNvHTc3tkcOI6QsEnObNL1gmhUfZoKjONYMIBFDpDpC9wc4IhWleTIA6O2W7w8axeX+ODF6a3BzfVC4BKJTuTBMIT4u3ukNCqqAMXDmYiH2t0PzsVD+YQlDtv1erQHhd1PXLQ4Wvsikmz2cTimHhFCfjZfRF41BK82ImdDm4NLFG127amKq9+4mft644g0cQ5bRvFzugUGf3wTTGH4XB54Ch1utyp6110XzNjpTS/lRaVSkQKuO6E8IZH0aEpcm+mNoW6/i0tkY+CIM2MPD32UBpZjppsL/n/lIDVulVg0DoDveok9rJ/tgnysFkJgtEpe3DK9/MqWtz14fA5lIwljj0RPNOYftp4HV58RN/pgpEpe3ba53mXOukKbCUGF1Zt/+To3s4he31fX7DVa1AuDjDKnjyV3N6FeXsTVSDQGRENxz9IRP+ZcKIfOxA8Wt4M1kgKm0fftmp8BlfW89hGYj+09oD1W1NVq7yvRwkc8pHKNx1PBGrsxq5OXTHEdVMFYhK23cxdao67Dq/VMqzq59di0W+WxutagVClWb81GFQ9fqtTsuAAq449P5vCrsDsBPMNiTKH87eBPyPCfzeMPm2ZDL+sDVstQhES7jrfBBb3RoUcuynM6qcOwN1UG4bQA8zmxuaGl5abT3wNJMFopL2EWrrbiZOn0BELQwcnj2wqe4k8fKoA31XE/AlS2AvO8b8HdRsj36WGFZHlFUpEJWy74wgs3kimFqUiyUGkk3B7UsLHfjL1WGoPbKMmG6z1Om0THGq91e1QGREIhw51qCM7xLrPF5BVxwa52CvGmyc2N+/qs/Ll5npkeTvqNK6lagWgWht7XofGxmXBROLaF7XdXLMdHv6dU7kZrJAqLJUyj7yetw+R21eDmFqWTOdOtjfo07Nuz4OzgSrUiAqZd9TPbHtZ0qvUP1N9feqFwglcvkO4jJYXL1A6s5U+NoJpR+9PJQeHVtovzKwWgQi6z75bhAtshiWK0erAarDSKOpucsZ/EnL/4cZxgmDiVW91rAzXSAqZR/N4UibQfTzN2+52zPLx1dHRXPY9NcG7zqpv/+nal995tF5DvDiXVTFDYe7200y1wPYy0uPdiZPMVXKvjUHLX2d1coTGMCX54SpioI1fi0IhIOb3MyuJjePp2q+77tgfGYyULqzMWh+yu2u38xtVAYtnzRfDzh6nqwWgXAakXm83YpC4UiUKDM03j2ac5jum+kCkZ0PLrt9ZF083wdQq8UOC66jqbC63Xy6k/zZTtQk32OFOlCZUZTjTY6oyhFEpex7/NT23JUAn+G3o6V3+e3NJ1UphSGXVk0IRMaY2yMLwKQW0mx7jJ1dcTiuYYB/wwhcOJhYpXzQT3Jp4HSYyW30UU0C4TAKUIjVpS2XwMRded5Cm8/cKxAcu5IJauRgvVbScfRRBQLhvMZVYvvQH/50vqBJNfjjd4UbPwT4XZaG4TmD0wv7+1c/Zm8sNL1SlczTZJifsN+rnrljoWlnlIiVbzLdHdJVKxCVsm+HkddLzPTZsV2zY9qb/9ojhxuMlbbLyIZN5kVD/fEN5RCAQmnWjECM9/h0N6FhlJnPHuyPq7th8x5nYcms0KirQTdnrjhU1yOa+LB2GxroaRjm4oHNcXWrW95TTQKhMu9yBab6edwvEFO2rOYHAJqvuXJ0mIk/P9gXv1HHpBoEwr3jUTr7cJj6GMc2+YpXvOno7RAmfEhznazrupvrQTHGn2Dg12AayaQ/fpJ74ipP1fkBYZgZJ2frsmoFolL27TwCzRCcdJVs9vpUNYKcm/+t+Pc1V6jR9/N7LQmEW8PmetikpaP7n2DyPbbemEeOShzoNDc3H9UmELmPaNYuuhlA1CMIazDlKuCSgURM3S6ndSpXLQKREYky24d6x1Gdkf2CKXV/s/U2Mc/kU+qyqpHhOde4+fAprhzjrseDafqWxdNqVQtEJexbvcPh5kmvlaquKL2jKcgXuU13e02s2HA1JRC7P2ZTLfpNmmoqtADd3HzmXtQwdgUB6mCY28nGHOsUMW5Mpxouc/KBkwtYjQKh8p6911oJxLUA3uHFyMbvyOZzh/rij7uFryaBUOUop33kOKmRBAfo69mrKr3YoIr6KBl8sX2ayIm9D99AytvoDU1B/qpqoGx+kqpeIMpt3zn+2W/ogjdH2Fe+eT/8HC/fEAB1QdIl8/bnWCFHjB7TKzpYzQmEIhEKRy8gytxvO9k5FvNXBvrj17i54shMr4zQSWCcrfalA9jPks6Lb95D/Ucwbk2Ppdbadys51UK1CkSuPGpOOti0ozkA41wmMwzQPIuIquHyXxi03gTduiXR84dCrk5UutUmEBMsymAfdrvJ9jyPB1idJWnOei/Ore1keAPGRhjmLfPm4vEiGpGMvycD9K9gHAvg4OwUoRr5/YlBa9IG3fTg5lXPTojX5LsaakIgymnf9jrN+JBr3PkREE7XfEPDAG8jNvrTMG9J7dp7SLy5Fq1pElEICAEhIAQqQWBaRxCVKKC8QwgIASEgBIojIAJRHDeJJQSEgBCoeQIiEDVfxVJAISAEhEBxBEQgiuMmsYSAEBACNU9ABKLmq1gKKASEgBAojoAIRHHcJJYQEAJCoOYJiEDUfBVLAYWAEBACxREQgSiOm8QSAkJACNQ8ARGImq9iKaAQEAJCoDgCIhDFcZNYQkAICIGaJyACUfNVLAUUAkJACBRHQASiOG4SSwgIASFQ8wREIGq+iqWAQkAICIHiCIhAFMdNYgkBISAEap6ACETNV7EUUAgIASFQHAERiOK4SSwhIASEQM0TEIGo+SqWAgoBISAEiiMgAlEcN4klBISAEKh5AiIQNV/FUkAhIASEQHEERCCK4yaxhIAQEAI1T0AEouarWAooBISAECiOgAhEcdwkVo0TOKqj+8Agm5+jNK9MJuMP13hxpXhCQEtABEIMQwhYCDQ3n7mXMWv0M2D6AoCUCT52KBHfKpCEQD0SEIGox1qXMmsJtLaesi8bDb8CcHg2wA4RCDGWeiYgAlHPtS9ln0SgvX3J/ikO9gF4twiEGIcQAEQgxAqEQJaACISYghCYTEAEQixCCIhAiA0IAVmkFhsQAm4EZAQh9iEEZAQhNiAEtAREIMQwhIAIhNgAgPnHRGY3jtBJYJzNwBEA5mbBpAG8QMDjzNyTHkut3bLl3pedoC3oiBwSMOmXAA7JhWHClwb7Yv/hB3RLS2QPBLAaoOMn0mE6a7C/5ye6dEqV/+a2yHwDtAHA3l7yy8DJg4nYf7mFjUQigWefDxxJZC4D41gABwMIZuO8SMAjINwxK8Bre3vjf/Py3s7OyFtHxmgdCP+cDf/HIKXa+/rWPK/+VuI2xg2fJpinAvSe7PtSAD/FMFanDbrpwc2rntW8i5rbI4cZoH+FieNAOBBAAMBrAJ5k4hVNAdzjNZ9eyiJhqoeArEFUT12VJKeZhiZNV4BxPoA9PCSaIsaN6VTDZUNDP3lV18CE2qK3EPDxid8YmxobeJGfRkXTUD+TNvjoLZvjz1jfWer8l1ggqLUj8hE2cT1A/+iB7WsgvgIprBgYiA+7hXcSiFQq8AoM4xsg/qxFhHRJpQj4xsjwnGu2br15TAVoaYn8HQWNG5j5tKwoOGXhOTJ4aXJzfJOHMkmQGiIgAlFDlVmoKKpBQIB6ABxTKKz9dwaehEGLBzf3/N7+W0tb5DiA1gGYlf3N9/mBUHv0i8S4ZmL0ANw2mIidC4Bz/ytH/kslEGoERAHjSgZfXKCx1aDnITOYPm2od802p3rRCQTS6RM5GPgOMU7wWJ9pEH9loC/+7dbWJQeZRnAdAR/wGPc1BpYMJmIbPYaXYDVAQASiBirRSxHmzz+vYdYeO1cAfJ4t/DCYnwAZDwFQDUgjgDA4M2WkphosD/eONmHx1o3xndb/NjefPtdoSKuG4325/6veajIRu9xT3o6JzJ61C/cB1JoNPwrwooFE/Oe5+OXKf6iz+52U4s+o0RQzv4UIJwPYy5KP9YDxvxPlMOgHA5tX/be1XC55UxvJXybGQwxSI6EAg48k4L2a3v7jZKZOSCbX/FnHTCMQfwX4EeuUXHZaaCNALwH8dhA6wNjHlt4OkBEhNr/EyEx/jT+MP8HAr8E0ApgfAGh+fh45OdqEE+z176WOJUx1EhCBqM56853rUFt3J8G8zzKtlGbg6qYgX6ObClJrC0GTbprUiABpIjor2dezyp6BUFv0OgIu2v1/741Ja2ukhQ1SYpBrmB81xwLHDA3d/WIuvXLnX72nyEVqammPfAFMV08WVH7CZFx00AHYFI/H1brOxLNgwSn7GLMavknITPNZRfiBxiCfpqsPjUBYk9xBhItG3pjTk5s+Uj9m1nUMfBlEX7W9Z3T3aI9/YxLOGeqLP25NMOOLykzfAVCn5f95wu3bECVCVREQgaiq6io+s3kNONGKgb4e1aBPTOHYU1cLwbN2Ye3kRoLXNwb3jPT23r7LGl7TyL9KJh+XTMYHCuW6tS16OQNfz4Ujxr8n+2OqUZt4yp3/YgXCYYpqI9LcNTAQ/z+XslOoPXIOMd1gFW0iLEv2xX5sj+ciENtBfNJAX3yL7l26xf8JzsCGkSaOOI0I1OgKKfMBAg7NxWFg+WAipqbR5KkDAiIQdVDJRyxcuudb3xi51zoa8LIbJ9MLta0vMPBsEOnORGL101Z0WTGxThOpY/oFp5na2s7YO42x+wFqzqaXJyyVyH+RAkEt7V3LwXyhhYXrVJHN3CjUFlUjict2/18/8nIRiAsHErHr3cw4FO46k4jtovOcwemF/f2rH3ONmz8y1HYQ6uAzqssiikDUQbXrGhd22UJqRdLcuWSekQpsAEitTTzMoMcbyLyury/+kh2dfaEZKDzNFGqLHkPAzyxTHnnz3JXKv98pJs0W37TTCMDJzDRpjDLwMftisINAaHd62d+lG+WwZhOAdgQS7jofxD+Y+K2IHWp18InVbBFFIGq2aicVjELh6B1EOMsyVeC4K6lYJK2tXe9jg9WZiH2zabxuMh831B9POKWZv3YBXY+4Ivn3KxChcORkIlozMb9PeAop7hwYiP/VK8POzs7gSGrfuwBEcnF0U2x6gdBP99nf3dZ26rtSCPQSMmccMo/XDkKoLXoSAT8VgfBao7UVTgSiturTsTSt7V3dzJlpBuui6DAD6wi8sjG4Z699XcEvms7OZU0jqdfjAJ3o1tjlftPsftpOJh2dTPY8an93JfLvVyBaw9GrmHDpRFmBDX97S+Mpj/ziztf9sAu1Ry8lxlW74+Q3/DqB0AmJ7r2acmlHKbq4IhB+arL2wopA1F6dakuU3TmznoCQQ5FTDDxGjB4O0NoD55pP2nffeEGVP9/NQwE0HJ9I3LXDHj///IRzj7gS+fcjELqeP8B/AAx1n4TPhz8IYIFFIPKYaafZPJ5Y91Mue8ZFIHxWZY0FF4GosQp1K0443H2kSaY60HaAh2IrVwvryaTbR0Zm/8q6fdItrmZO3WmaKW+Bt9C0R7nz76chLbDt1ANe1yCT3GiokFNZh/FTLhGIqVZdbcUXgait+ixYGrW/PZA2v0eExT5O/Co3ELcGKXVVzveP04vGe9ZzVwJ8Ri6MbmtkS0vkHQhSLxjKb5B6PC24ljP/fhrSGSEQHvxCKbB+yiUCUfATqqsAIhB1Vd27C5tpaE3zYgKWWhaVC9Hw5JNHM3X0yGgwePTW3rsnTiTbF3i97qrJZbAc+ffTkIpAeHMyWMig5PeZTUAEYmbXTyVyR6HO7oNpjD8Kg88BQ82Huznx2w7DOM7ubsKaUc3i86RFUc0oYyondEuW/6kKRDFebL1WsHaKSUYQXvFJuCIJiEAUCa5Woym/Qk1NLx+apsBSYnSB8M68sno4he128lmzTpHnWqNYvlPJvx+B0B3eI8aPkv2xTxSbd7d4IhDloCppFiIgAlGIUH3/Ti3t0YVg3GGdhlKeXXks0GH1lWTH1ByOtBmU8a+05/hvPDHNZN+y6nW7ZhFV4Sv/fgRC5aU1HP0hE/5lIl9lPEQmAlFE7UuUKRMQgZgywpmfQKij6zBi80Qwtai7ghi5rY7OAAAFx0lEQVRINgW3L+3t7U15yX2oPbKMmG6zhC3ozlvjeiM3zfRL2/0RBX02VSr/fgWixX7KGHA8x+HCObebSx2U2wbQw8zmhqaGl1Zb60cEwoulSphSExCBKDXRGZjeVE/8alw1FBQIhcHuekONFNjkGybvXvLgjmOKJ5a95t+vQGhOjivPh1cOJmJfc3OCaDWRlpbIexDI3Mh3UO7/ul1fIhAz8MOqgyyJQNRBJWtcLfjyGZQnMMAzZjDV4XbBTWYKxu56g7EJxCvevG1NuQvPXS5U0NlcpfLvVyCy7rTvBtEiixm5ele1mptarB9NzV3O4E9a/j/MME4YTKzqnRw278pRJUYFrz9Vafgtl/W9clCuDhoIt+FtfRe/PkqvO5sAwFNDpnf5jXhjcPsZhaaoNK6mnyfCJmacmSXvaUqmUvnXNKQFfUk1hyPHGpS5TW9i55fb7XsWi6NQOBIlykzd7d41xrwOJk63X0EqI4j6+FZnWillBDHTaqRM+QmHu9tNMtdbLuVRb3qJmT47tmt2THdSurk9crjBWAnQkdYersm8aKg/vsFLVh1cTWejenM2pwJXIv/zO0//+1mp1C8BOiJXNrUziU2+yOnOaIdRgIq+A8yXwMRd9rjNzWfuFQiOXckENXIIehl9iEB4sTYJU2oCIhClJjpz01M7er4Lhrpe0/68BvDvACPrJI/frmaIAMzND0o3jw7PvnAKrjcmkizkWsP27rLnX+dsMJuH18av8VQ3iJqXJxPxO615U6Osxl0Ut92+lwsyDMLDYPrd+D+crvPEMBN/frAvfqPOhEQgZu6HVcs5E4Go5dq1lS3TyKSMGwBWp6f9PuqK0juagnyR7kpMp8QcpodUcE+uNazpViL/oXD0AiKscHJD4rQld3wqjm4GEPULFoByZXLJQCKmbpfT3vAnAlEEVYkyZQIiEFNGWF0JRCKRwLbn6YI3pzauBDDHY+7V/QaXzNufY8V5eLXdmzDeCt42mIid63W3Ty6f5c6/BxFyXH/J5k0JxLUA3uGFLQODTHyu/U5oe1wRCC80JUypCYhAlJpolaSnThw3Nu78CAinM5lhgOZZFkuHAd5GbPSnYd6S2rX3kNcpJV3xda43AF40kIirg3RFPeXMv2ro//oCLWbmzwH0fgBv251JZ/fluTAqb8GmHc0BGOdq2KrpvL8waL0JunVLoucPXkRSBKIoM5FIUyQgAjFFgBK9MAGNQJTMtUbht0sIISAEiiUgAlEsOYnnmYDdu2sZXWt4zpMEFAJCoDABEYjCjCTEFAhoFqkLutaYwuskqhAQAiUkIAJRQpiSVD6BfHcUfD/SONXpXIEwFAJCYOYQEIGYOXVRczlRi7Wz9ti5AuDzsoVLE9FZyb4e5WpDHiEgBGY4ARGIGV5B1ZK95s4l8wKjPJpM3ps5UNbSEnk3G/Qt69WmDPzWMMcWJpP3bq+Wckk+hUA9ExCBqOfaL2HZQ+GuJUS82iVJXw4CS5g1SUoICIEiCYhAFAlOok0mEGqLHkPAzyxeWm2I/LnoEL5CQAhMPwERiOmvg5rIgebOBWu5YqNNfN7WjfGdNVFYKYQQqBMCIhB1UtHlLmZn5+I5I6nGb4N4MRj7AEgBvJWIrn3Hfry2GBcd5c6zpC8EhIA7AREIsRAhIASEgBDQEhCBEMMQAkJACAgBEQixASEgBISAEPBOQEYQ3llJSCEgBIRAXREQgair6pbCCgEhIAS8ExCB8M5KQgoBISAE6oqACERdVbcUVggIASHgnYAIhHdWElIICAEhUFcERCDqqrqlsEJACAgB7wREILyzkpBCQAgIgboiIAJRV9UthRUCQkAIeCcgAuGdlYQUAkJACNQVARGIuqpuKawQEAJCwDsBEQjvrCSkEBACQqCuCIhA1FV1S2GFgBAQAt4JiEB4ZyUhhYAQEAJ1RUAEoq6qWworBISAEPBOQATCOysJKQSEgBCoKwL/D5yktjRWSi00AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-26"><g><path d="M 51 301 L 51 237.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 232.12 L 54.5 239.12 L 51 237.37 L 47.5 239.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-25"><g><rect x="1" y="301" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 351px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">uPEP driver removes OS_HINT</div></div></div></foreignObject><image x="2" y="330" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tnXucW2Wd/z/fk2SmLAp0UcpVRPfnT/GGW+hkkkkdLWCLlEshmRYolJ+7XLSLq7uIIquooKvu6tIfF0WUq9BJpLSIIBRxnMltytZFRURXQAUpFFkExGlncs53fTLJzJnkOck5uUwymW/+6auT5/J93t8n53Oe2/chyEcICAEhIASEgIYACRUhIASEgBAQAjoCIhDSL4SAEBACQkBLQARCOoYQEAJCQAiIQEgfEAJCQAgIAfcEZAThnpWkFAJCQAjMKwIiEPPK3dJYISAEhIB7AiIQ7llJSiEgBITAvCIgAjGv3C2NFQJCQAi4JyAC4Z5VU1MG+2IrCbizjkrGADwD8A4w7rcId77uADyUSCRMN2X29EUXG6CtABa6SV9TGsKNmZH4Ol3eVre/pvbUkSkYiX2MGF+cKqICmzqqyWedzbrqtVXytxcBEYg28UcDHpC6lvwewIUHH8DxakLRAQJRV/tnuxvM5kN7NuuabY5SX3MJiEA0l6/r0pskEMX64+ML+Jzt9ydedDKoQwXCdftdO6pBCWfzoT2bdTUIjxTTJgREINrEEU0WCAB07fjY3uu3b792QtfkDheIqu2f7W4wmw/t2axrtjlKfc0lIALRXL6uS9cJBAMnZJPx77opZPHicwJdXS/sR34jwmx9GqA3l+QzibAuPRK/xa1AeKnfjY2V0rS6/fXa7zX/bD60Z7MurxwkfXsTEIFoE//U+4C0N6O3N7oHGbSBCX9n/zsDPzGsiWPT6Tt2ljZbN4KYSwJRb/tnuxvIQ3u2iUt9tRAQgaiFWhPyNFIglHmLj47u3b2LEgwcYzPXZOZV2VSibLdUJwlELe1vgksrFikCMdvEpb5aCIhA1EKtCXkaLRDKxN6+6HKAtgDoKprMwIZsMv7hTh5BFNvmpf1NcKkIxGxDlfoaTkAEouFIayuwGQKxuH/Na7pyuR8A9I4pqxgPdAf4xKGhxJ/slnbaCCI/ivDQ/tq8VnsuGUHUzk5yzh4BEYgKrMt+xA4PV6civORvhkD090dftXuCtoDw3mkbedSHwIpk8tYXOl0gvLS/ET+5o5auPsTP5mpYWAPKbxLYA0COgZ8DfBNPdF03Ovrtl1RdXgSiNG1xbain5/S9KDBxMQFnA9gPwBiYH2XCLdZ47sZt2+543k1doVC0lw36PoC9ChxesZiXj6YSSS9c+vpOeUMOviECDinkG2fg/dlk/P5K5eT9lDNWANbZAP0tgEWF9DkAvyWmEcvg6w7Zn7PVzvMU64lEVh2QY/8IgDfm/zb9230ltDQWYQufB9ADwA/gWQAPMOEqL3V4YTNX04pAzDuBwGN+ykVGRjbtmJ8CoW9/PT9g9aD2+ScuY8L5hQeOU3HPAfT/MsnB7wUjsQvdnqTWCQQZxlOw+Dt/EZ436Cvju7r9e0aHhm7YVU2M1HpV1y7cDVCoWBYxPp9OxT/phUswPHA6Edt2yXF6fAGOczp/ozZTwI/1YPoXAK+uXhc/SgY+lB5O/DD/yK/w0QmEOTER83UHPg7GRwD4NNldCVp1OzsnhQjEfBOIeTTFpB1BeBwFVvupB5cOvIUsjgN4W7W0he/HmPlsg+j1DPzrVJ5KYUhKwnIQ8GEGzgVwuEOdJhGdkR4Z3OhmBKHS9PbFPgTgyuny9CNNpzb2969bsDv3SgKg46dEBvhMOhm/VJcn2L/69ZQzNwKk3uK9fEwQvjr+530udjrToworEwjwEMNIEfjjDuKgNKeioHkxslPSikB0sED09kYPgp+GwPgbWzMT3f6dpw0NDanh+9SnE9cgvLS/lh90KLTqUDb8d2se1CbAjwJGVpXL4CMJeKttdPECGGkQ3l+LQIDwPBj7FgUHQAqgxwujiTCAx6wJ39Gjo7epqRNX01mh0MDb2OAfFKaqVDZPb9MFoVT5DyjY9YIFPmY0mdheyrYiN8aTTMgS6CUG70VAH4CDy/1T+eBnuUDgZQDdUxs2GL+BgR/ly7XwbhBeD2B9Jhm/qpa+0Kl5RCA6WCBCkYHVzPkh/9RwmgkXZUfiXyptdicKhJf2e/2Bq4OJ3X/14s3MPGDPS8DWnMHnbhtOPGH/+5IlJ+9rdAU+S5Nv/uXTGx5GENPl8ij7fauzQxt/U/ybGjWNmXjd6EjikeLfqk0xqXS6EYDTjjcdq97wwLkg/prNtntg4pRMJqGCSE59nLdfY7Pl4wtLuakj8D2RNW83OPdNgI60FWUy+GPZZOIrOns0AlFMNkbAxw86gK+yrWdQX98ph5mm8cdMJvE/XvtCJ6cXgehQgQiFTt7PMgL3EfBOWxNfIouXp9OJTKcLhNf2e/2R94SjxxiU30KsFqLzH2JcxxZfUPpQtJVNvZHoP4PpC2Ui4VEgGPgV/Mb77OLg1AY3AqHylgsq/3Tc71+2fei2P1Tik19L8OF2gFbY0mnfxstsAUwwX3LwgfhypQXowkL21QCvtdXxO5i8LJNJ/LrUPkeBYP5EJpVQUXQrrmF47Q+dml4EogMFIr+bxjJvAqh/RvOYt6gdNroHWLNjMVU7ld3IXVy1tN/LD7y/v9+/O7foRoBPK+ZjIGuNTxxf3DnkVJ4aeQT2+OPXCzuPppN5FAiqML9fWrdbgViyNHqYzyI1TXRYoQxX00yl01MMPOmH2Z9M3v643ZaenjWLjICpdjTZ1msqTxXZ8xdGYXcREJwSZQcODgLxhGnwMs0oxYv751VaEYjOEAha3L9m30DOPIIIZ4ARs7/ZFpr4AsNYkU1uHNU1eY4LRN3t9/Kr12znnLEoXK0szXw/4E0gPG1DdSsQahAU7It90y5ebqaZyhe46dZu/7Nnla5zaab8HEcATgzdjnIcBEK7/lbNX/P5exGINhaIBnZME8SfyIwk/s1paN2OAjGb7fdSVzAcPYGINhWniZzemJ3KnByB7HcrgOhUGm8C8YTlzy0dHdr0lBu7PQiE7vT9w/YF79L6NDvFnMRSJz7XZ5PxD3iZ7tGIs1YsdQLBhE9mR+Lq/IN8XBIQgeh8gciB+OKD98dXKs3xdrBAuGq/y99LPlkoHLucCRdP55k+c+C2nGAk9hFiTC+wehEIj1t1vQiE5vT5OMAnZpIJdZCu7FPWbwi/Ro77M5mEuqxq6tPXd9pCExP32Le1MuGj2ZH4V90yU+nC4RNebdECFeH43VP5mM7LpAa/bi9HKxAeoiN7samT04pAdK5AqKtGsxbxOfYdLU7NbcddTHX+8Dy130NdFAzHbspP5RU+anE6nYr/vYcyEAwPrCBi9aCb3NHkRSAAT1MlXgRCK4BEV2ZGBi/QvemXl61Pq3nzV1XdC9BvvXBjcICA9wE40Ma/7FCfRiA8Tct5samT04pAdIpAEJ5nzu+P32YYuNcc920t7oN304HnvEDU2X43jFQa3eE7p63DlcrUvHk739dd5/3VngWiPPSGdppJcwLbcVG7qSNUjbhqBMLxXIZb38/HdCIQbSwQ1Xb+NLLDtqNAzGb73bKcDwKhaaN2mqk8hpPz6WsRCLc9rL3SiUCIQOQJiEC4+2HOB4FQJMp2JmmmmUJ9sUsZ+PTUVE+FrbciEO76V7ulEoEQgRCB8PCrnC8CUbYVt2TxWbPo7HgI0+EFpKlTPjLF5KFTV0gqAiECIQLh8bfUG4ndAMZZU9kqLDA7Fd0TjvYZlA+xvWc+jZdFao/1eV2DmFxrKduKO+M2wjL7wdrQGsX2h0LRI2DQVgZeU/ibyUwrs6nBezzid5VcBMIVpqqJRCAqICqLL+Nxe2EoHPvGjHuhK+Rv5Eniql7XJJApJvfUgpHYxcS4fCqHx36h8pWFxm4zgVA2lh5KY2Dq3EKwL3YFAWpnU/FTMdCdOkVNAXOYgDcVM9SyuO/WSyIQbklVTicCUWkE0RdbSYD9/uYfGbxrZSp1p4oMWfHzjmPX7vmqP+++Y8ad0CIQjsxaLZDV/Gn/vmyLKrCDDVqWHR78hctyyg6NtdsIQrWjLPRGYZppvNu/u+Smwqrt1wUDRJVRh45lQWjuJWAhAb+0gF8YFl+fTicesqcXgXDZE6skE4HwJhCuT7Bqwh/bb7Wacd1n/o2yXIxUNLETssm42ivf9I+MINwj1oUR9/I2rIl51HZTTAUa1BsZ2ADm9YX/57exMvOuGdNjLs9llIfkwEsGG8enUhvVzW+uPqFI7Axm3GALdqjdWisC4Qpn1UQiEBUQlc+zouKpUltR6g1RhXa+ZEbxMoLoiBGEWjEoeXCqdrmNK6TvG204xaQa1dsXXQ7ko9Z2qf+rm+bUv7aT5K7jUIXDp7zVIt99Mw65AVt3L+Co061z9g7T07/qYCPnV2sW9suZfmyOTxxbGiRRBKLqs99VAhGICph0b4oq3n+VDk3BcDRGRNeXBcwTgegUgYDuYQfwUM6PNQ8OJZ5xaKhz32hTgSgNvcHAT4jZAtG78m10CK3h1P7eSOwrYPzjzO/p5m6/9cGhoUTZyLqYToUUJ4M2zFjTA0xmrM+m4rZ7KCZziEC4ev5XTSQCURlR+VzxZPrNOcO44MHhjU/as6twxP5A4NOOdxOLQHSMQEyOInR3O+jvTVbbY3fl6J8Ko0p/GYg2FQhlZ+l5hxm2VwjDoXO2wyhAjUn+k+Fbn01u3FYa0qMnEj2cmFSU2akw35Pa5PyyJgJR9dnvKoEIRBVMFQ745ADeDhg/UfOhmmslTWJczQR1R+9kfP05JhCuepDHRE5z9a1eg/HYjHxydbdD1x4vXgnwOZr8TzGQVFdngvjtYByhCcE+na2dBaI89EbRbrdTrjPw9EaiS8Ck1tb20wilChczDNBzIO62XQdakpQeh2GdlBlO/EznOxGIWnp0eR4RiOocqbcv9sG/7Ff/csUf+MxyTAIug5W7ng2/uoDljSIQk4A6SSBUexxuOqvWq14m4BoGVIC/hfnEbSwQusOBBW+6unFOB6N36ep3weLvFO7RrsZLIw50amZ44385ZRSB8IjUIbkIhDuOFFoafQ9buAqgN1fJ8hwz/0M2lYhHIqv2z7Ff7dAQgShA6zSBUM2KRqO+p3aQuqTpCgCvrdw/+FGyjDNNw7IM0Na5IBCqPZodSGqK5zPpZPxSdz+h8lQ9PafvRYGJz9GkUE5d3VqhvBwxrjFzgUtGR7/9UqV6RSBq9crMfCIQHjgWrotcTuDzAfpbAIsKb3/Pg/mXRHRNl483FxfbyjqpTDF13AjC3n3Um/a4SScx8/kg+r9g7GvrH9sYdM3E2D7f37792ol2juaq+0lotm1XDK3h4WcFFRW2ezetBONMBg4HsL9tG+uzf7mH+jEwvmVO5DZXu9K1WK8IhBcPOKcVgWgMRylFCAgBIdBxBEQgOs6l0iAhIASEQGMIiEA0hqOUIgSEgBDoOAIiEB3nUmmQEBACQqAxBEQgGsNRShECQkAIdBwBEYiOc6k0SAgIASHQGAIiEI3hKKUIASEgBDqOgAhEx7lUGiQEhIAQaAwBEYjGcJRShIAQEAIdR0AEouNcKg0SAkJACDSGgAhEYzhKKUJACAiBjiMgAtFxLpUGCQEhIAQaQ0AEojEcpRQhIASEQMcREIHoOJdKg4SAEBACjSEgAtEYjlKKEBACQqDjCIhAdJxLpUFCQAgIgcYQEIFoDEcpRQgIASHQcQREIDrOpdIgISAEhEBjCIhANIajlCIEhIAQ6DgCIhAd51JpkBAQAkKgMQREIBrDUUoRAkJACHQcARGIjnOpNEgICAEh0BgCIhCN4SilCAEhIAQ6joAIRMe5VBokBISAEGgMARGIxnCUUoSAEBACHUdABKLjXCoNEgJCQAg0hoAIRGM4SilCQAgIgY4jIALRcS6VBgkBISAEGkNABKIxHKUUISAEhEDHERCB6DiXSoOEgBAQAo0hIALRGI5NL6W/P/qq3RO0BYT3Fip7zE+5yMjIph09kejhBuOLAC0DsAcIz4N5G4OumRjb5/vbt1874WRgvtycsQKwzgbobwEsKqTNAfgtMY1YBl93yP6cTSQSppuGBvtiKwm4s5iWCRdlR+JfUv+PRqO+3z+D5cz4EIiWgLFvPp0Lm5Wt4yadxMznA/R2AK8GoGx6hoH7mPjfRkcSvwDAbuy0p1F2PbnDdySRtQ6MYwAcCsBvs+2XBBo0J3yDo6O3PVup/MVHR/fu2oW7AQoV0xHj8+lU/JNe7Orv7/fvzu13q8I2xRLYkE3GP1ypnIptAZ4l4Kcg3NTl481DQ4k/ebGpmFa1sXs3rQTjTAbeYes3eX8Q8AgzD5oTuc3btt3xfC11SJ7WExCBaL0PXFmgEwiY/G746CQAX84Lg+7DdF4mNfj10q96e6N7wI/1YPqXwoO2ih38KBn4UHo48cNqD2AngQiFBo5iw7oJoDdXqexhNiiWHR5UD/u8fPT2Dbwf4G8BeG2FvCYDNy3w8wVuH3z5h+nTdAoRPg/gjS6ckSOi2yeILnxweOOTTulDfbFLGfj09Pc86kNgRTJ56wsu6sgn6es75Q05+IYIOKSQ5yWyeHk6ncg4lEGhpdH3sIWrXDBWRbwM4s8hhyszmcSYG7vy/dCkz4FxrmOfm1lQjhjXmLnAJaOj337JTR2Spn0IiEC0jy8qWqITCAI2MPCvFX6oT5gGL9s2nHjCXniwf/XrKWduBKjHY/NNEL46/ud9Lq40KtEJBCz6NRHf4E6M8lY9QlbuuHR60++CfdGPEOiLU2/01Y3+Dkw+s9pDTzHdlaMNBJwJwFe92BkpniaD16aHEw/o8oVCA29jg38AYL/C969YzMtHU4mk23p6wwPngvhrNpFJjy/AcdvvT7xYWoYSfPIZlzFYjS48toVHLb956ujQpqcq2dbbG/1r+GgQwNFu21BMx8CvYNBJNtH3WoSkbwEBEYgWQK+lSo1AjAPYbXvg7mTgAQK9AljB/Bsk0TWZkcEL7G/8odCqQ9nw3w3g8BI7TDCeZEKWQC8xeC8C+gAcXG4vXTs+tvd6J5EoFQgi3MmMoO1haQL8KGBkVdkMPpKAt5YKADGus8D3E9H1NhFUb7opgB4v2Kim3IoP4aKpJhGdkR4Z3OjEOj9FsosSjPx0UunnZQKyDHoCxN0AwmAcpnnwvsxM67KpwU26BzZ8uB2gFbaHZNXpoWLa/v51C3bnXkkAdPxUfttUnb2+xYvPCXTt8eKVAJ9T1hLC88T4cb4tgM+JtU2Qf6tjVqGOMTA/CjJ+nJ/uq8iLh8YX4CSdwNXym5A8zScgAtF8xg2pQSMQ0w9D0BVsWpfY35iPWrr6EBjmxINDiWeKCR0eiiYzNls+vrB0pKGmdnoia95ucO6bAB1pa4jJ4I9lk4mv6BpXKhAlaTabBn+0tK6eyJp3EJsJAt5krweABSAAYIyAz7DJG+ztVFNETz2NdSD6/zNHUnwPTJyiG0Wouf3x3KINDLWWMePzNDP9wyEHWltK11sUT59pfZUIakrP/oa+E4axPDO88b/KRKJ8BPDTcb9/2fah2/5QrVMElw68haz8COSAQtqdZNGydHrw4ZK81BuJ/jOYvjDTLn7UYlzwugPxQGlbliw5eV+jK/BZQn6ayN6We7v9fKpuei7Yt7qfYKkXi+JUpprO+8ICP39Rl37J0uhhfou+XiLAVYW7Ghf5fnYJiEDMLu+aa3MSCAaunxjb59xKUz7FSoOR2Mcov5g99THBfMnBB+LLlRagCwvZVwO81pb3dzB5WSaT+HVpo5wFovLIo7cvuhygLQC6SsocI8La9Ej8dgeA1BuOXgTKPySLnx1s0DLdlEZPOHqMQfl6bOs2rqZZqLcv9sGyNR/mLbCwplSM1EPSZ5F6yKvRh/qMM/D+bDJ+f7WO0NsX+xCAK6fT6QWvpy+62ABtBbDQVub9MHkgk0n8T4V6KBiJnkVMV9sf+kRYlx6J36Lx6RUEqNHo5IfoytLRaWmewmL9ZoD6be24q9u/Z3Ro6IZd1RjI960nIALReh+4ssBBIKotWk6V3dOzZpERMNWD6W3TFVZ+YNsNK7x13kXITxVNPiOAz6ST8Us1D5MZu5gK3z9sTfiOrrQDqK/vtIUmJu4pWxsh/EdmJP7RSovjmjdu7cN4cmfQohsBPs1mt6PYaZxDwb6Yevu+xPbdmMV84mgqoR7UUx9dXexiF1J+A0Hp9BTTGdnU4LdL7KHeyMAGMK+3/b24dqOdKirNX94WLlvneMexa/d81Z9332EfDTBwQjYZ/261zlsq+gw86YfZn0ze/ni1vPJ96wmIQLTeB64s0AuE+50xocjAamZWb4bFKQUvD8W8jeVlsHbKRDeCcBKT0sb3RmI3gHGW7e8vWOBjRpOJ7ZVALe5f85quXO4HAKktl/mP7iGmERKVdH0mGb/KlSMA6MRWjeSyyfgHSkUsGI6eQERqjaLAXc/MXrdmgVu72UAzQjGdRgBObXMzytH1PdYLVlk1Pf2rDjZyvq0AqbWchxj0SICsK0ZGEs+55S3pWkdABKJ17D3VrP+R4pZsKq524FTb96/eer9JwNm2h6f2gVbJKM22S+3OHI1AuJ5aCYVjlzPh4mk73Imglo/mLTcYHjidKC+URRGp6Y1WY6dWLDViMg7wiZlk4vtOrMunAunWbv+zZw0NDamzKVOfMvEh/Bo57s9kEr9327l0Zy00ZzYoGI7dRIQzbNxkV5JbyHM4nQjEHHGe9gHosKultEm6qRsmfDQ7Ev+ql+aHwye82qIFalrh3VP5NOcsyra5ephWKH84sqs5a7cCEQrHvsGEv7MJkKvySzkF+2JHE/A923qJ40gn2BdzPX+vaYfJzKuyqcTUwcOiLaUiRcDWP/1V98k/ve/mV7z4NRiJXUyMyysx0YxAVfIxBrYQ+MZu/55Dsq7ghfrcSCsCMTf8hHqG+Zo3f9XqewFyM089rQXgAAHvA3Bg8Y+6E8KaEcTUqe9quMsEgnBjZiS+rlo+NwKh3TrqYk1AV7eOqdO8fE842mcQqRHDnoWyHNdjNIvO2rS6N3+A/xsw1EFGjx8+AsASm0CUHerTrUGVVJJj4OfEGGQfbT5kkfUrtyfvPRoryWeRgAjELMKupyo3D0Cn8h12utRjznRezQO8XCDcTROpQpsrEGXhSmAPA+IFSCSy6oAc+0fsp6+dBEITesNxmqn0BLbTonaFbc9emuGUVivo4fDqIy2y1O6vqReECpW9DOAusuiG3bv3/qGbXXaNMFzKaCwBEYjG8mxaaXNaIBgPdAf4RDfhL+a0QFSY8itvV/k2UY2QOJ6+boVAqM5d4TxIpb6vDjd+y0+5y1XssKb9SKTghhMQgWg40uYUKAJRmasbPvWs45TWrh1BVNjZo9mZVDZ1FApFe9nIT0XtNVlf+ZbToh2tEohi/XmhsKwPE6DOxpSeZHdyVsXwJM355Uip9RAQgaiH3izmdfMAdDJHM8Xkautorc0rm2KaLyOICmcDNGcbyhafNYvO2nMmyi+NFLta/VzIR8H+1YfSBL8PBp8FhlrP0AeOnMzgePK8TjskexMIiEA0AWoziqxHIEKh6BEwaCsDrynYZjLTymxq8J5m2Nq+AqGJb1TjIrXmPEVVppottlNbjTU7zZxCa+Rdpju8pmJXpVPxv2+GT92WqWI2LVjw/JtM8q0lxgAIry/L6+IUttv6JF1zCYhANJdvw0qvRyDUXnwKmMP2OEe1Ls66aVC7CoSyvXTLac1bQ8MDK4hYbfnNH4Aj4A+w+Jh0OvGQE6OyQ2m2cwvl22adY0kVyy/bsuthpObGjw1IQ72R2LFg3GSfhlKRXXnCt7TavRoNqF+KqJOACESdAGcrez0CodveCVR/AJW2rSA09xKwkIBfWsAvDIuvL30otrVAzPJBOTtDTeiNqWmmsrMSDvd42MsrDweOiqMOh75aDNehLiV6CqCHmK2tCwLP3V48mJcfLbF1PJh6ASxmIL3Av3Nt6cE9p99CMBJdR5yPyFv8NHWKc7Z+k/OhHhGIOeLlegRCNbE8+BteMtg4PpXaqLZquvqEIrEzmKHudCiG69CekG5rgSiPkup5q6taoPVb1r0A3lIE5xRqoxSsJjbRBj/8l9pjULmNV6RZ+FZH6i/LJuOfcnG6Pm9ab2/0b+DLBxR8na0tM8KS13tie7bXwFx1ZknkioAIhCtMrU9Ur0CEw6e81SLffTMOuQFbdy/gqJv4/JMxdfxqzcIW7A8/Nscnji29UrKdBaJJwfqqhs8o9qDy0Bs8yozPE5G6WrRwkE4fWqNMbFRQPwO3gehE23c7QbwyM5LYVq3XOoQ9H2MYx2WTG4eK+TWHAj3FfCqPR4UnLH9uabULiqrZL983n4AIRPMZN6SGegUif21nJPYVMP5xpkF0c7ff+mClMwr528oM2jAzRAXUPRLrs6m47cazyZLbWSCUfbpw3wz8xLByJ6bTmyqdLteH+wYc71HQOb9kOumPRBhmxgmFtI6hNXRlObTFTZwkCoajsZLLmABN6HIHUXUlRPqQ30h0+3ee5naKqiE/ICmkJgIiEDVhm/1MDRAIOIwC1GzEfzJ867PJjeqtc0bgv55I9HBiUoH+psJ8q9arxV2n0Ue7C0SFC4NUhNEPH3wAx0vDRKhzDyb8X2bG6rILg1y+sRd7Tfl5hxn9qWpYdHvqCm15AcwXwsKtpfdU9PScvpfPP3EZE9SFSX43o49weHXEIuuu6TMa+VzPMdNHJnbtHdedlFZ9x2DcWHLZlDY0+uz/oqRGNwREINxQaoM0jRAI1YzeSHQJmNTum/LDTYTnwRgG6Ln81ZEW3q3dpgh6HIZ1UmY48TOHN+SZ90F42F3TzJPUdlsbdOVotYuMtD1Hc2J6Ol0NW0CrtGUMhIfAVPCV9U6AFmvu9x5j4n/KjiSucejuDiPQfOqXAf4ZYBRuu+PXqujwABaVl+X+DpI2+NnNexNEIOZIF2iUQORFYunqd8Hi7wD8Bu/NV+JAp+qu2CyW1e4jiKKdkw+w1OXCAAARLElEQVRqUg/EmOa+6Wpo1NvzWbWeJdHc7qfqcx0WvdS4QluuLbSlmu2l36tQGBdmknF1u5xj6HiHmwXd1qWuKL1pgZ8vcBNyxW2hkq65BEQgmsu3YaU3UiCUUWqagQITnyNAHayqdPK12IYcMa4xc4FLRke//VKlhs0VgVBtyN9pvYOUQHwZwEEuHJYj0Dd2+41Publb2qk83Q6kSqE1XNhVS1uUGmSZ+AOjI4lHPNRx3l9GIJcB2MdNHgDqfooLdVN3LvNLshYREIFoEXiv1TZaIOxv0d27aSUYZzJwOID9bW/Tz/7lHurHwPiWOZHbXLpbyakNc0kgpjgsPifQ3f3ie0BYw8QRAIfapmGeJeCnzDzohUMlH+vOpri9da9a31Gnmf0LXujxwfgAkxUG6GDbS4CaDvodg+6yQN/alhz8b7dbYu31qjqmeZXVMQbwU8RGyoT1zdyuhaMSzbWa19rzexGI9vSLWCUEhIAQaDkBEYiWu0AMEAJCQAi0JwERiPb0i1glBISAEGg5ARGIlrtADBACQkAItCcBEYj29ItYJQSEgBBoOQERiJa7QAwQAkJACLQnARGI9vSLWCUEhIAQaDkBEYiWu0AMEAJCQAi0JwERiPb0i1glBISAEGg5ARGIlrtADBACQkAItCcBEYj29ItYJQSEgBBoOQERiJa7QAwQAkJACLQnARGI9vSLWCUEhIAQaDkBEYiWu0AMEAJCQAi0JwERiPb0i1glBISAEGg5ARGIlrtADBACQkAItCcBEYj29ItYJQSEgBBoOQERiJa7QAwQAkJACLQnARGI9vSLWCUEhIAQaDkBEYiWu0AMEAJCQAi0JwERiPb0i1glBISAEGg5ARGIlrtADBACQkAItCcBEYj29ItYJQSEgBBoOQERiJa7QAwQAkJACLQnARGI9vSLWCUEhIAQaDkBEYiWu6CyAdFo1Pfks8abyLRWg3A0QG8EsMiW62UGdhhMaYt408QCHt5+f+LFZjTrqKWrD/GbfBwRn8LA4QD2B+Ar1JUD8DQBv2TirUzGXYcssn6VSCTMZtjSiDJ7+qKLDdBWAAuL5TFwQjYZ/2495ff3R1+1e4K2gPDeqXIYD3QH+MShocSfnMrujcRuAOMst3mCfbGVBNw5szy6dnxs7/Xbt187UU8bymwh3JgZia+zlxmJrDogx/4RAKpPNvvzggU+ZjSZ2N7siqT8aQIiEG3aG3p6Tt/L6Bo/F0wfBnCQBzNzTLiP4fvE6MhtPwPAHvLqklJoaSzCFv87QEd6LOv3AD4Fk2/LZBJjHvM2PXlnCgTGmHl1NpUoEQ5vOEUgvPHq1NQiEG3mWTVieGoHxf7yVnsFgNfWYZ7JjM1mgNc/OJR4ppZyenujf01+42pmPtU2UqilqIct8p0+OnLbT2vJ3Kw8HSoQCtfDlj+3YnRo01O1shOBqJVcZ+UTgWgjf6qpiV052kDAmRUeyGrK5hmAdk+azkpEXl2hGU+TwWvTw4kHvDT1qP7o/v4cbgOo30u+Cml3wjBOzgxvTDeovLqL6WCBAIGu6fI/e8HQ0JCa+vP8EYHwjKwjM4hAtIlbFx8d3Tuwm24lxnEak/7IwDcNi6456CDrN6Xz+kpYxk1jmcX8cQKO0ojLy8y0Lpsa3OSmuYsXnxPo2uPFKwE+pyR9fvoKjK+RyT8eH1+4szjXrUY+zzxj7jfB/iNBOI8YxwLw2/Mz8Cv4jfdlhzb+xo0dzU7TyQIBYMxiPnE0lVBrLJ4/bgTCa6Fe11i8li/pG09ABKLxTD2XWOGBPAbmz3YHcGWlxU1bhdS7dPURsKybALytxJCdIF6ZGUlsq2ZgTzh6jEG0BcAexbTq4c7ki7qdJgr2r3495cyNAPXY6yPGdV2BnefX+mZbzXYv33e4QKjFp58Y1sSx6fQdO71wUWlFILwS68z0IhCt9yv1RqL/DKYvzHzzp8fJwup0evBBrybmd9HkjKsBXluS9xGycsel05t+61Rmf3+/f3du0Y0An2ZL8zuYvCyTSfzaiy2RSPS1OcZ3S0RiJ1m0LJ0efNhLWc1I2+kCkWdG+I/MSPyjXjcriEA0o8fNvTJFIFrss96lq98Fy/o+gP3sb+sw6KTs8OAvajXPaVRSbW66p2fNIgqYwwS8yVb3+kwyflUttmhHI4SLsiPxL9VSXiPzdKBAqJ1iu+zbdmudahKBaGRPm7tliUC00HcOb+sN2aaomhUKnbyfZQTuI+Cdtma+RBYvT6cTGV3TNQ/NVyzm5aOpRLIWVGptpWsX7gYoNCWAjFuyqbhaiK93C24tJk3l6UCBeIyADQz8a8n0YNYanzh+27Y7nncLTATCLanOTicC0UL/hkIDb2ODf2AfPTR6jj4YHlhFxLcB6JpqKtGVmZHBC3QPaM1D849k0bG1THUV6wv2xa4g4O8Lu6+YGMNdgT3OHxq6Qb3ttuzTkQJh5ZaxEbi4dIMBA5dlk/FPuRVlEYiWdcu2qlgEooXuCPXFLmXg027f7msxVXuqF3jCNHjZtuHEE6VlhkLRI2DQVgZe04gpplpsnq08nSgQfspFJnxd3chZ95ZME75ksHF8KrVRnXyu+hGBqIpoXiQQgWiRm3VTLwCnxxfguEaHyugND5wL4q/ZmmoS0RnpkcGNpc3v6zttoYmJe0oWlqsubrcIY13VdqpAjIxs2hEMRweISO1mmx45gofGF+AkN/1LBKKurtUxmUUgWuTK4NKBt5CVn146oGgCAxuyybgKrdHQj9e6NCMbNTPxqMW44HUH4oF2jq/kBVwnC4TapBDY449fJ+DsGUyYP5FJJb5YbapJBMJLT+rctCIQLfJtMDywgohVULhisDsw0xnZ1OC3G22SdlRQIXicOsOgmaIomvV7Bm6BQTe2ezC+ahw7WSBU2x38+ALDWJFNbhytxEcEolrvmR/fi0C0yM/BSOwjxPiKrfq6dgtVaQYFw7GbiHCGLd1jar5aTUfo8hYWt2+oEsZjDISHAL7DsKy7d+3a91f1RhGdTXfoBKJp9c9ONNcyn4YisTOYofw49SICF1NNIhBN6wlzqmARiBa5KxSOXc6Ei23VNzWccWEnkdq5VPzsYIOWVTprEVoafS9bdDOAA11iyjHwc4PxPctHt7T7CGM+CISaaur+qxdvZuYBmw9NEH8iM5L4N6epJhEIlz2+w5OJQLTIwWU/QKDiG329ZgYjsY8RQ809Fz+uBEmFHafAxOcK21SnQm+4tCcfQypAuX93Gqm4LKcpyeaDQChwvb3Rv4GP1HrX62wgK4ZeEYFoSpebc4WKQLTIZXNFIIp4liw5eV9foOtUkPUPAL3ZY/hvNbK4eoGfP+kyptSseGW+CISCGQzHziPClSV+u7fbz6fqfCICMStdsO0rEYFokYvmmkDYMU3GekIfsTHAxEcDONgNRhU8jkw+1WtMJzdl15Km0xep7Ux6e6N7wMBtIDrRPtXE4I9lkwn7Wlj+axGIWnpU5+URgWiRT0Ph2DeY8He26p+w/Lml9VzyUqkppWseBPwBFh+TTiceqhdB4R6LIBFOAeP4KoLRNmcq5pNAKB+Hw6e81SLffSVrSuqejuWZ4Y3/NUNQSq8/1Vw56rXfSLhvr8Ran14EokU+qHVNoEZzPe9iqrGefDYV8M/oyp3pdF0qA9dPjO1zbqt3PM03gchPNfVFP0ogFSjRtqsJZVNNMoKo5xfQOXlFIFrkS82F8yYzrcymBu9ptEnh8AmvtmiBOnPxblvZPzJ418pU6s6XG11fsbz8tIYfF4LpX0ouD6oYMLBZ9pSWOx8FYnJ6kL4D4H0zppoY67Op+NRpexGI2eqF7V2PCESL/KM73UyMz6dT8U822iSHuq5Lp+IqgF6zP9r7LprVVi+NmY8CofjoQswDeNpg89hU6vaf59PIFJOXrtSxaUUgWuRafRC95sRiCoYHTifiW+xN1Z3anjzdbV0CGPsDvCeARxsxynCIO3VXt3/PaCsjus5XgXCcamLeAgtrMpnEmAhEix4MbVatCEQLHaKL5uol4qYb0/PTPD7cDtAKW3ptNNfSoH4MPOmH2Z9M3v64m7oqpSk7qOfiZHG9dVbLP58FQol29y5KMHCMfaqJCOvSI/FbRCCq9Z758b0IRAv9rL0Pgmhw95/3XtuoBVzdjW5Od04E+2JHE/A9WwRQk5lXZVOJO+vFFIzELibG5VPliECUIfW6y0ezjuXpsGVvJLoETGptauo2QwD562Xhp0vAOGvKSNnFVO9PYE7mF4ForduoNzKwAczrbWaMM/OZ2VRisF7T1OE2oytwFwFBW1mOC8RLlkYP81n5E7eHTT/Ip6cdarVn8ua8/W4FEC2WwW1wq9x8HkEU/EC94ehFoPx96NNaQDTIzBaANSIQtfb6zsgnAtFiPzruTSdemRlJbKvVPMc7qRnXdQV2nj80NJQrLdvhCtS6BUvbRqbzMqnBr9favkbkE4EACutDmwHqt081AVACERCBaERPm7tliEC0ge8c9qbvZOD0bDJ+v1cTJ7cyGlcDvLYkb9VDauHw6ohF1l0A9rLlfYGZ12VTCTUd4ekeaYe5bscb7by2tZ70IhCT9IJ9q3sIltpevdCRp0wx1dPV5mxeEYg2cJ3T2z6AMQI+wyZvUDtL3JjaE4kebjBuBOjIkvRjRFibHonfXqkcNYoYzy3awODzS9LlCPQNH018zm3gPSdbvN6P7KbdtaQRgZgeH+immmYwFYGopYvN+TwiEG3iwsmhPl0LIKYx6TkwvkpM8YMOsn5TeqNbMTYSQP8IQMVGsp+SVcWNMfPZ2VQi7mYEEAqdvB/7AneBcZTGlhyIHyDQzWTx8K5dC3cUF9T7+9ctGB9/aRGT72gQzgPoXaW2ELB19wKOurn2stmuEYGYJuywXjWdQASi2d2xLcsXgWgjt6gtqeQzLmOwuna09CFftNQE8AxAu/N/IN4bjH0rNONpMnhtejjxgJemhkKrDrUM/xYC3uklX6W0KlifYeVOTKc3/bZRZdZTjgjETHoO04uTiUQg6ulqczavCET7uY5CS6PvYQtXFcJq12qhyYzNps/4yIPDG5+spRB1F4TRNbEBnL+Jzkmw3BQ9aUuA1z84lHjGTYbZSCMCUUaZgn2xzxJwSfk3uDEzEl9Xj1+8buOtpy7J2xgCIhCN4djwUiYPuJHaZvhZAAd5qCDHjC0+8CdTqcQvPeRzSko9kTVvJ5hfIMaxJTGVqhVvMvCgYeCi9HB8xM30VrUCG/m9CEQ5TTW9aBmB+8pGjjKCaGTXmzNliUC0v6toSd/A//GRdSIYJwF0KID9bW/0LwP8O4CSAG/u9u851KzwFWqdJLCLltJkoDd1tkLdA7HIhjA//UXAI8x0e85Hd9c6epkNt4hA6CnrDlfKFNNs9Mj2q0MEov18IhYJASEgBNqCgAhEW7hBjBACQkAItB8BEYj284lYJASEgBBoCwIiEG3hBjFCCAgBIdB+BEQg2s8nYpEQEAJCoC0IiEC0hRvECCEgBIRA+xEQgWg/n8wrizR3GjS1/Uy4KDsS/1JTK5HChUCHEBCB6BBHztVmiEDMVc+J3fOBgAjEfPByG7dRBKKNnSOmzXsCIhDzvgsIACEgBISAnoAIhPQMISAEhIAQ0BIQgZCOIQSEgBAQAiIQ0geEgBAQAkLAPQEZQbhnJSmFgBAQAvOKgAjEvHK3NFYICAEh4J6ACIR7VpJSCAgBITCvCIhAzCt3S2OFgBAQAu4JiEC4ZyUphYAQEALzioAIxLxytzRWCAgBIeCegAiEe1aSUggIASEwrwiIQMwrd0tjhYAQEALuCYhAuGclKYWAEBAC84qACMS8crc0VggIASHgnoAIhHtWklIICAEhMK8I/C+wpca3TmA5zAAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-37"><g><path d="M 151 651 L 51 651 L 51 407.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 402.12 L 54.5 409.12 L 51 407.37 L 47.5 409.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-40"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 662px; margin-left: 142px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="133" y="656" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-60"><g><path d="M 201 701 L 201 793.2 L 313.83 793.2" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 319.08 793.2 L 312.08 796.7 L 313.83 793.2 L 312.08 789.7 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-61"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 712px; margin-left: 211px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="204.5" y="706" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-35"><g><path d="M 201 601 L 251 651 L 201 701 L 151 651 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 651px; margin-left: 152px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Any GPIO<br />w/ WAKESTS<br />active</div></div></div></foreignObject><image x="152" y="630" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXl8ZFWV//e8qiQNCN38YIBmUXBhRkR+agtJKkmboZt9aeimkm4WgWEUkBYEF2QZxRFwmx8IP1REEJSlOylpFpEdjJ2qVAXsGX4OgwwfBBF6sBuUTUgnqXrnx61UJS/v3VfvvVpS23n/KF13Ofd7bu733nPOPZcgnyAgCAgCgoAgoEGABBVBQBAQBAQBQUCHgBCEzAtBQBAQBAQBLQJCEDIxBAFBQBAQBIQgZA4IAoKAICAI+EdAThD+sZKSgoAgIAg0FQJCEE2lbhmsICAICAL+ERCC8I+VlBQEBAFBoKkQEIJoKnXLYAUBQUAQ8I+AEIR/rOak5AGLo3uFTHoEwF6WDt8kkw8dGYkl50SIJu9k0dLo/JYttJiAIwDuBtEuYOxggWUMwJ8BPAGmB9Ihuvfx9WtfLAa2np7lC9McHgbwgWLqA8hMycKvAxRn4FfzwvzroaHY3/y2194dXWSAHgKwfb4OA0en4oO/9NuGrpzCsXWLcTAzH03E7QDtDmCrXNm83C+AcCeTcc8eO5vPxGIx9e/y1QgCQhA1ooi8GJ3dfWcBuMYhFtE1yeGBswFwjYncEOJEo9HQxk34FJv0rwDaAYSDDYyfZsYlk1u2X7dhw3WTfuuWgSB0XY0x8BOebPmX0dFb3/SSpcwEQR3dKw8AmV8jxsEBcdxIwHdbw/zTIATnNT75vXgEhCCKx67sNTs7o1shhNsBOkzT+PMZg5c8tj72fNk7bvIG23ui+xDTDQR0lA4FP02m8emRkYHH/bRVIYLIdU3PwaDjkuvX/kchWcpFEPsvXrlHKGNeSYRjAIT8jN+lzCvM/PlUIjYoG6ISUCxDVSGIMoBYriYikWgnG3Q/gO1ybU4AaLW0vzoZH/xBufpr9nayp4aX6SwGvm0xfWh35FNmHJo6vRHPt5mc7HXeAui0ZHzgF14LXGUJIivWU2SmDx8ZWfeCm77LQRCRxdED2aSbAexaYF4pXF6Z+p3bAOxSgEgyDPx8XpjPltNE9f5ShSCqh72j50hX32VMuHCaHAhXg6HMSjmS4JGJeTh8w8OxN2pI7LoUZdGiz7a0bv365WCcq1mk0kx4kJj/b1sYcd0C1dt7yrzJyS37m2SuBrBcY0oZI8JJI8ODtxcCSEsQhJ8lhwdP8QksLepdtUOryXvDNL8M4Cj7eIhoYPyd+Se5mb5KJYiOrv7lRHwTgG1tMqtF/nGD6NutIfMRO45Zgt5o7GkafCYBpwFYYB8zE+6dbOPjZc77nA1lLiYEUWZAi22uvX3VzkZL5mEA+2b3V8CLITZOMA3zp2B8MNeuOKuLBXh2PersiX4JTN+yLaYZZtxphvjLQUx5yrQSNs2r33VaK9OK9XvSDKcPGx1a95Kb2GUgCGvT1NEV7SOiG20nojGTedloIqYc0Y6vFILo7IkeACblzN5pdsP8W5PCp40Or/lPr1OUqtfbG33PljR9kYCLnWRL102MzV8dxLdTnmkirQhB1Mgc6OyOHgrQXdOnBcajZrrlWGqZ/D4Bp06LKc7qkjXW1bWyxyTzHospT7U5RsBXd1vIPygmkiZ7ItnqjWsA/qxVQAYuTcUHv+a2SJaZIFTXWvJj4MZUfFDt0h1BDsUSRCSy/H1shO8FsI9lzBkCXcUZ8+JkMqaivQJ9Hd19Swm41UY4GRBfkByO/ZsfsgnUoRQuiIAQRA1MkN7e3vB4euefAXx8XhxiXD6SGLyooyt6NBGts+x0xVldgs7UTnV8ku4C4UDrolaOBUiFdbZtoRgDB1naLqivChAE7KfRKVn4dxPh8JINQ2tetcNXDEGoOTuR3vlqBp85mxxw6fjYgstK2e27nEo2wzAO9XK4lzA1pKoGASGIGpgW3d0r3p9GaIiAPXLiTLxruz0iFR98uLMzuhvCNGQxM6ki4qwuUm+Rnv6VzHyL1bSkdteTYwtOL2VRy4vT3hU9yKDsSTAf7w9mOjGVGFC7YsdXCYJQnXR0911FyPqv8t9rJvig0XhsQzkIQhNQoZp9oC3Mx5XDqdzR1XcGUTbc2xINRbe1hTedPDQ0lC5S/VItIAJCEAEBq0Rx592HWbs96uzpvxrMyhma+4I7qzU75z+EKd0zPLzuZdXoAQccu4PRGj6ZQOoUs7fF4bgJ4H9n0I8mxxbcX2gRjXT3XcLA16fFJDyLNPcmk7GNQXBzmNvAoyG0HBaP3/ZakHbsZV3CiP/H4MzBicTt/1VK2/m6uj4YWLvHQj5RZ7qqGEH09H2FGN+xjOltk/nQ0UQsXgaC0MxJuBJQMbi6nPQ2k0lLRkYGniymTakTHAEhiOCYlbWG9g/B5mdwLpiYPmH4FcaNIN55Z8dXW+e9fg4Iyk5uj0KxN/8KQP+UjA/8yqctO8PMy1OJ2N1+5VQ29I7uPnUnYdrvQsA3RuKDlwRoQ1tUu+utgE8n0tP3GWY+B0y3cojuLHRDeA4JQjkftLejg5qY9Lf9y7+7z0VHrbGGepdrLpQ6l5qlvhBElTWtu/uQNy/lRVvUu2rH1nT6EYD2m9mdB7tZrSMIZDJHIhT6xrux8n0BYEgz+PxUPHalnSRcds+uzlFdnxqTWtl2prYwYtW96646AB4lFZ1DgiibiUljpssQ0YkjwwNrSwLDVlk77xH89FxOmZqtLSGIKmvcaSvWm1M0i1sgZ7WGIDYqx6Xt1vYYKJtfSIUmhhj8SQI+oonxd11sNKlCAsnpXHz4PmSwopiIGKtq9SaL8piuSplCFSIIxylMhU2HkemNx29/rlQTk8a/8TIbtCS1fuD3pWChqzuXfZVb9kZoTwiiilrURZu4HaFdnIK+ndUuNt386N8i4LLWMP/A7mBUMf4tpnmDLTIHcDHNdCzu/zCZrJINLsw17nt3qYvmKpdDvr13+e5GOrzemgSxUOjnXE2LShCE1gTEeLSthZfpHMhBTEz7HXzSNu95Z/yO2fOhckTb0dV/AlE2qGD6K0ciwbnSb733IwRRRQ1qQlhdd+ZTmTFxL0ARy5+K75vVBQhChQ8em1y/dsQNCm34posDWr/I+7NP2xe2QrveoGqLRPr3Z4MftN7WZcL5qeHB7wZtq5zlK0AQ1NnTdwUYX7DKWch2H4Qg1KaGWjLraSqQIf/F2sKbj69EdFGt6q2cc6CW2xKCqJJ29AtpYXNKhzMyZQLgZcl4TOVvKvi5xf8zY3UqMXitV32No/x1MulgXVI6jY3al5nJuVv0RyxesqvfO7r7jiJglrO8Fnai5SSIrA/IwFdBdJHthnjBSK0gBKEJyQaCpQbxo67pMpoTqXK2X52KD54TqCEpXBQCQhBFwVZ6Jd3E9zKnRCL9+7KRNd/MpDXwGYWjj5byH4aqWxjcFliNo9nTzKRyG42n344BdGQOXc86QbRQq6aKUglC6XViwtgTBh/DwBkAdnPgwnxBMhFTIa/aVPFBCEJbtoInsVLxCTJHpKwTASGIKs0KjTPX09GnWUSV9L525y4nCN+mge7u47fPYPI+gNRbCdmvwA5cFydfsC8NYT5pToaWjo6u2VQOFWlOX4Xk13apWxz9yuaGVaWzuRLw0Pg8jhZKdicE4VeLzVdOCKIKOtf7E+BrsdbthL1OHmqIOoJgwkWp4cHL/UCgrV/g1bFcTh11XyKbidbLn+AgTJ8nIz+yqzKdXf2ng3iWKS2oiakOCeJ+ZPiEZDL210I4CUH4nUXNV04Iogo610Qk+Tan6C8peceGuxDEeanhQXWfwfMLShDaE4dLygnN/YnAFwG9BlAOH0QdEYS6uf7l3RfyoJ/Eg0EIIhKJfgwGPcTAjtMnyQAbDS892X/XmTaJcf1IYvAzQduS8sEREIIIjlnJNTSx3b7MRFMnAWdiPwCezuqgC7x9kMXUd6TegP6U5PStlD9s0n6iyZ5qCL4JUpWvUYLIvo9NwLNM/FAxbzsHIYi59glIFFPJy01JDQhBlARf8Mr6TJvB23HWKBzxU8wCb+2jmPqak5LWz2L3D1QincJcRsPU8oKrm2lB5NXNA+Xn+NvWbcf+7sGb3y7HTLa2kUu3MevRJWZakUoMqAzH8lUYASGICgNsb16XTbRMIhQ8hRSzwJdKENrkeExnJBMDP863rZGrbKk1rPLrTF4ocHmsFJ0EWXDnekdeKkGo+vYTsJd/qRQs7X0R8CpMPmhkJPZEKe1KXX8ICEH4w6kspVzMQ2VpO9eI683qahCEkkmTqfaetvA20aGhm7ao352njPKk1tCBqjHtVSQ7aMMThPONEt8+tCCTXUvqZcrsG0SOZi4rBDGH2tffY8BfwFTEG9Mczj0Qr/4397k7q6tFEBrTzqxFWeOn8J0+JKjqNJf9UAlzVqMThC5Qwuvd66C6mtpc2F5ZVKl+y5TZtxh5mrGOEMQcal1z98HTuewmnsvbBq7tVYsgpk5NO90GIDrDY1NmJnu4byVNFapvXXgxA88gbBySGlr7x3JNhUYniKlnTe1vlOBNg40jE4m1w+XAMXcrfA2Illnaq4j5sRzyNmobQhBzpFmXXEolPYSji+0H9M7qahFE1ozkeMWNs2amsfTbHzFADwHYfkoN5Uut4aZWl5fKrpsYm7+6HC/KqX6bgCCgPQ2Dhybm4ZhCl/L8/rlFevpOZMZN8qKcX8QqU04IojK4Olpt74p2G0QqZ9I2+R9LPS7rjvpuu/BqEoQ99UZexjSFjrO8elYRO7ZdETmivhOgXstvmXK8SZ1vrxkIYuoU4UwKCFDJZOvyJrWcHuZorbJ2IwQxN6BX6olGXbtqRA47fjUJQmOSUC/NnUCEEy25l8qaWqOQWl0WoLQi7PGxBd8p5SSh0qOHMuaVRDjG9u619jW3eoximibCqRTq9wHYdzbedHNb2PxcMW9T5+6rqPe7Z/KNAWUl8Ln5k2+MXoQg5kCP+rsP5YnW0Z1MoHl1q8oEoXM43gHCR8H44JR1KdgLeaWqLdIdPYlBKtx2K2tbDKQA4wup+NrH3JLb6fpWxBA2zfMB/JO9TVU+UC6mCmZH1cke5MRjr+9CtmrEvzUJJ48Ox57yoyvlc6AQnZ1703yWTvzkk/LTh5QJjoAQRHDMAtfQ3n2w3QcI3GiugkteJ4ezutoEoQ9ZnB512VNr+MCTOrv7Pveuye97ugUd4KfBxvcN0C8TibUv28kiGo2G/rgptGs4kzkYpLKo0sdtKbbzIqQZ+OG8MF+k21HX8wkiP8BIT/QIZrp5xpc0jX4GwMMAf78tjLh9/ArDjRuNPZm4D4RzAfydRm8PI8P9XvmkfOhbihSBgBBEEaAFqaKN4vGZgdVvP5roKIfDt9oEocaiCWnNDbH8qTV8Yked3f1HAPxTl8VpepEH8D8Apaf+gZUfaWfvPvhpMnDWyPrYr91OI41AEFndZh9kwlqA318Al7cAeiWHoSZMe1bNDAM/nxfms4sxVXnrRkr4QUAIwg9KJZTRR3uUN1pH+4gLMOu+QU0QRCTayUbWUb+dFdJSnfUlqCdbtb39hO1C4clLmXCm5v3tYpr/AzMu3GNXvt0rWV6jEESZcVQkco7fZIPFKEjq+ENACMIfTkWXKuUVOL+dFrihPe2srgWCcHmTomaiU7IOZtM8h4DTrE+T+tRDmgnqSdPL99iFU17EkG+zkQgiP6aurujfZ0CXEUHdYbBc5PREUmWh/RoyvCaZjKkkhPJVGQEhiAoqwMU/UJFoHd2tU6uzuhYIQkGtSb1xHzJYUUsLgrKNv7jJ2Jsy5koi6mTg72231pVt/c8Av0CguAk8NC+8dTyfPiTIlGpEgsiPX825LWn6R4NpuUkcIWAhgG1zv2cxJOApE3w/wqF1qaG1LwQJDAiCs5QtDgEhiOJwk1pFIqDxl1QstUaRIko1QUAQyCEgBCFTYc4QsKcHqXRqjTkbmHQkCDQoAkIQDarYWhyWM3NreZ31tThmkUkQqGcEhCDqWXv1Jbv91nfRiQrra9girSBQvwgIQdSv7upKcueNW+93tOtqgCKsINCACAhBNKBSqzmkbMoEMnZtbd1qo4rq6e09Zd5E5p3jmHGF5TJahhmrU4nBa6spq/QtCAgChREQgpAZUlYEurqO3takeb8E8Cm3hlW+I3Ni8sjHHrvjL2XtXBoTBASBsiIgBFFWOKUxdWIYT78ds2RptYOyGcRHJYdjKhmefIKAIFDDCAhB1LBy6lW0zp6+m8A4WSP/a0R80shw7Ff1OjaRWxBoJgSEIJpJ23M01s7u/iMZfCkBH8mlWtgMIJY2jO88vn7ti3MkhnQjCAgCJSIgBFEigFJdEBAEBIFGRUAIolE1K+MSBAQBQaBEBIQgSgRQqgsCgoAg0KgICEE0qmZlXIKAICAIlIiAEESJAEp1QUAQEAQaFQEhiEbVrIxLEBAEBIESERCCKBFAqS4ICAKCQKMiIATRqJqVcQkCgoAgUCICQhAlAijVBQFBQBBoVASEIBpVszIuQUAQEARKREAIokQApbogIAgIAo2KgBDE3GuWOrr7biDg1FzXsbbw5uOHhobSQURZ1Ltqx9Z0+hGA9svXY8YtqcTgpwFwkLbcM7Dy7ybC4SUbhta8GqQ9VTbS1XcZEy6cqResLefzpNmWns8YvOSx9bHng8pjLe9IJsh4tK2Flw0Nxf5WZLvU2RP9Epi+BSBkaSNDoOvGx+afs2HDdZP5f+/o7juKgLuL7MtXNSacnxoe/K6vwrlCixZ9tqVtm9d62DSOBsylAL0XwLbTbRD+AuY/AxRn4FeT83j9hodjb/jpo6dn+cI0h4cBfMBP+RLLvGaCDxqNxzZ4tRONRkN/ehkfCzEtZ8IhIOwJxg6Wem8x8DIYjxkGHshMhB4aHV2zyavdRvldCGKONelY2JnOSCYGflyEGHaiUbxQ1ILe3b3i/WmEhgjYwybH2ybzoaOJWDyIfL290feMT9JdIBxYJHnZnye1dr86GR/8QRB57GXLTBCu5ADClRPvLLjQSg5KllojiPb2E7YzwumLQXzGLELwBjnNjLtC4IsSidh/FypeawShHraCgdNA9DXLQ1beIwYyAFIM44up+FqVsj7QZsxPB7VURghijrXR3hXtNojuB7ANgJfZoCWp9QO/L0aMzq7+00E8/SobAa/C5INGRmJPBGmvoyt6NBGts+1+s00UsxPVEk4AImxvX7Wz0ZJ5GMC+znGU/lRpGQmCOrqj5xLoO7mstXlxM27kUGMEQZ3d/UcA/NOAi6RdLWkQfxNpfC+ZjI3p5l4tEUQk0r8/G+bPAfqHIH8ntrJKx7eYEy1nj47e+mYJ7dR0VSGIOVZPpLvvEga+PrX6lmbaaO+OLjJADwHYfmanTiemEgO3BhlWR3ffVQScra/D97SFt4mq50P9ttnR1X8YEatX5fLmFt9HftVHpKd/JTPfkquvdmwmgJZc/xMAL0vGY4pki/rKRBDU2d33uXeJ/nsAtrIIUpAcaoggqKMnejIx/dAmf1GYqkrEuJ5NPltHErVCEB3dfUsJUH8fOxU90NkVH0aG+5PJ2F/L1F5NNSMEMYfqsJteiHH5SGLwomJF6O4+fvsMJu8DqH2aIICrU/HBc/y2qWnjpdxivPMUh+HFMDK98fjtz/ltU+N/GA2h5bB4/LbXvNro7e0Nj6d3ug1ANFf2ZQDqdHPWTF26rS286eSgfpt8/TIQhNvimiHg0vGxBZfZzUrWcWtMTIEI1AtDP7939kQPAJMicftCuZGAa2HSna2t4y8NDd35er49NX8nJow9YfAxDChz1G6OvpgvSCZi6kRVkumlDDpyiBaJLH8fG+F7Aexj+/H1d30PNwG8ZiIUfm7D0Br1FG5WfuWfeyc99t4wsJRhfl536mDgxsmxBacX0rkfndRiGSGIOdRKx+L+D5PJjwBYCGCCgSNS8UFlSin6i3T1/YQJ/zzdQMBTieMUQvhZtq2ZF+EyzLw8lYj5cqrqHN4cgLQikf592chilFu4eNRk/ItBNGA5KZXkrC5x8aGOrmgfEd1oPzn4IQcFbbUJImd/XwOiZZaJlwHzZTDxbTczkXWSKufuxpfpLAa+bcOhLGRXoo50f0/U2dN3BRhfsP6oAjs43XKWTzOR0v1RRHST9dSe/VtmWpVKDKiNTEN9QhBzqM6Orv4TiLKmE4DwLNLcm0zGNpYiwqw2i9jx2/0YYFI7Q2UvmPZtBFng23uX726kw+sB7JUbVyCC6ezuUyeFa/KYqN0ZT7Z8wQhP3mF1egMo2lldyuIT6elbwYybiyWHWiAIXYQYA5em4oPKYRtk558/SV0/y39FdE1yeECZLIO0NevPoBQd6f6eDlgc3Stkktp45OcliGhg/J35JwXd+UcWRw9kk+4AsN1MX3wfMljhh1xL+Xuf67pCEHOHeFnCW+3i2k4l6mffJxONOSe7+1ONzPZtsG8TUc7Gq96cbp06iPg3US1aGp3fugX3AhSZJgie8ql09PR9hRjKdJH7indWF7v4lIMcaoEgOnr6ziXGFZa59KQ5GVpaTPim9jRShs1PsTpy+3PW+MU2k0lLRkYGnixiCdCdRspycipClopWEYKoKLwzjZcxvHWWxF1dR29r0jxlS/7U9NJJuCg1PHi519A6O6O7IUxDYHxwquwUEaj/Z/Nt+J78joU8gMnLFuGlxJiO8tI45It2Vhez+HR09S8nYmVamLkXoGBivnj3XfG9WCymnOm+vqqbmHr6brKYEJXMRd3FyQ/WFlSg/vl1MungkZGBx30BoilUjI4K9aXZYPje9Oja1Z7CmFY0mpmp7glC56hVZhI/dws0u2/fYZ2Ouh67Jtvi53vB9fMHpolC8vUHr9ntTzu4HW36wFRzIlGRLX4d8Zq7DzMRVNmdagi3A5QlsKmvOGd10MUn0hM9gpmUWWk6WizLoUWQg5K61gii2AuWeS1Y/hYMgN5mcDrExj8nEmvVxbiivqA68urESRD4jcFbjkok7n7Lq67u9+kNH9FuYMpeFiSYl4zEY2qeNMxX9wSR+4Ozh2n6WyD18f8+61r8CT4Wq9kTtHjziG7m2e8xMPAMT4YWe5kM7NFGnDPnZDF1YuOJi7q/QC2Z9QTsnZPTt7nLeZrJtjDLz2D3TxR7jyTI4uMSFlk0OdQCQTgCG4CiTUyVWgmD6MiPDBqzWikmJj9dNkSZxiAI+2Lm0waqi//3ubg6bjFbF1f7zLDvfgPsqn1NMs3FNM8jvua286xLe442fWDqMBH5qJMfoMZM4bhEqDvxFeOs9rv4dC5eGYFpKmekNRQ0A+ILksOxfyvWCVvtE4Q9sCF7GipxTL4maoBCfnXkt0mN+VLt+a+bGJu/OqiT2m+fjVCuIQhCE6HgmSJCZ7vPKdSzrma3W/BGdCXCW62TT5fawsvM5lhsbb4CTbiq52nAERHl07btkgvKcWLRmbCA4KcxP4uPyz2Bsiyk1SYIXUQPgDQxfpSenPzGY4/doe4BVPXzo6MgAuoCIBQxMuNOM8RfLjW/VxBZ6qlsQxCEbuHwShHhshud0p2Hvd1uuwcK3zauRHirfZLZzUXqVutIYvAzbpPRvovUnWo6evouJMZl+TY8Tj7U0dX3cyKcON2nD7+FKuu8+4AMEZ04Mjyw1jHO2bes1c+BndVei48LOaQZfH4qHruy2JNDfizVJgi1de7sip4PyiYXtH8qbcajYOP6iXnmg36T8ZV70fPSUTH9dXRF+4no5/kIO0sbmXdv5/8HGNea6fA9XqbZYvqu1zoNQRAKfOfuNcCi7dReQXu786ZwwZj8ioS32kXWkFahKA27TNrTgaPNAhFJmuyynmau6QXTHsJawDSl3/0Gc1YXWny6ulZ+0iTzLgC7zsaYh0NoWebnNrjXYlADBAG1o24Zp9uIcbiHvC8R08Mm8brJcChZTGZfLzx0v1eCILLZard64yoGf1aXd2xajmzWWjxKhLvJNB5NJNaq2/xF3+koZvy1UqdhCMIeBukVf29z1L0E8BhAH8odIVyzomrMOQUjkioV3mqfQBo/hKvZyyGTy4IcxJTmDEP1l1lWe/QvfNFKk8UWgRyObovPuBn6EEz+BcDv1/6BEr6fHB48r9TFosLZXH1HyKm5vCVNVxOgUsRb05S7r0+5xROgWCVPGJUgCDWoKZJ4/fxcPrSwz4X4LVIZXJkHmu2E0TAEoQl3dbWZ28uq27oG429M+HxuwrjufjWpIEYm5uFwt6N4JcNbrZNbY8d3vcGscdhpT0xa050l0snav+ZG942p+OBpXoup8+TjbTLq7I4eCpDa5Wcv4+U+3zerdYsPDL5AhbJaIrB0a8cYEU4aGR683efCoi1WKwSRE44ii6P/yCZdpc+eW3CkmXfTxTxuEF+62y64P8hdEC/8KkUQ+X7be6L7GEzXqYA93+Q4LTQ/DRjfQsaMNdrNabteGoYg1MA0dnhtDL5jt8t0BgN/m06DoRpzsZ87Umx7xPnbwltLupzj9Udlj/V28xk4Qv4K+Ars41Vkqlv47aGThaK6LOPQ3X3wfNNC91hSEGe1Y/EB/pS9PA7sbpFNkcE6Ziy3ptVQUW4IG4ekhtb+0Usfbr/XGEFkxVS5lV58OfRJwDydgOMCvguh/mCeBuGM5HDsN8XiYq1XaYLIk+MB3f0fChGfCcbxRWR4fYWZP59KxAa9NkLlwKQabTQUQfi1mdt2u9kjecg0DDb4QQALsvygWQg1O+qCkT32XX2QnEbFTAY/znO39Bpur2/5MR1pTm++3rnQ5sfxebFO4wfy7azWEIQd7uxJYfydBXe3bvXGNZiyWVu/B9rCfFyxL9DVIkFYB5dNxLfR2NM0zGVEdBwYH/OZElw5uC/cfRdcUeppYo4Iwjps6upaudBE5jAi6uepk4X11rzbn6RK7/4TpPm8RjxNNBRB+LSZ22zYU7by8BhCsy95OW3omtQUBXe7tkipQEnriiEIzfifN8PpxaND61QK7+znll7DzfmqWfwdYcBeIbNuY9GLrtqPAAAZ10lEQVTcfXiTTD50ZCSW9Bq//klSf85qD4IYY+ZT87vCXPLB+2zml5LCXWvBSe2Fr44wmLAUBp/sQRglYTM9T+3pQAKkbAkytgJls4TBhnkgMx8PUHdhwmjMOxUNRRCa3bFjUbabJ/Inhd7e3pDtHQKHs0+TmqKgnX0uwlutE1wzfudiPvVgijWZnuf7EfYLhfYQ4lyeomm7vJ+LgPq7D/7vNLjEtftyVhcgiFnkkMe2vSt6kEFZn4f1YaA3DTaOLCadRL0RhH0RVY7e8LzX2smgC4hxsO01PVX8NYZxWCq+drTYxboKJ4iCoqpT1UubsA+YvghGn+ZENcHMn04lYiotfcN8DUUQ2R2y7RlOu1lH53/I522y2+btdnSbWcPrRDAn4a32megYA+G81PCgit3Pfpr0Gp4JxuwEYE/uZiMQL1ym5HC8+1CevykCvjESH7ykUGsuBKElh1w7Spf/SsDFtnafNMPpw6wnND+jqHeCsI6xvWfVfgZn1Atttudh/Z3m3PCqNYKwyrn/4pV7tJjmDQxkMx/PfP43OH7mSS2UaTiCcF6Am52q2kYgs04J9uge62UzTeRTwZfW5iq81T6J7GOwJmLzSq/hNiHtmFrTkdjb9AovniYq69OrZf1L8P4j1RDEGBN/LjUcU48laePdDzjg2B2M1pZ7aMo2bfmCmxYaiSCmyN75UpvfeVCPBKFkVifYti0Us5GEZxaGsk71OWis4QjC456C7bbvbD+DM9ncDLlo0k0XvEw3V+Gt9jnijPCZGWOxvgINptN/CBpC9nzD2sU8VK7p7umsLnZ32tG9sp1gKn/ErKyuRDhlZHhw6iEoH1+1CKK395gFW9Kt6ma8MjOqN753yZ2SS34JTeNP8kzNUgiqYnVkb1OZMrek3/4iAasAYyuA/44J3/aTDt9LlVo/mM/sAV5t18rvDUcQ2R1NV99lTLgwD3LeVOTmf5h5f3b2e8gEvAqTDxoZiT2he3mtUErxuQxvtU2mWSRoHYOf9BpuE9MRNZT7Q3BkkiWcnxoe/G7BP379PYZNKlV08D8MblML3exY9sLmjRIWH+rsiX4JnE1RYb1YthnERyWHY4/5kb9aBKELD/bjL/I1ptnP6WarMHB0Kj6o3ioJ/JWgo1l9+c3zFVhAdYroXbVjazr9CED7Ta81PuZ/MX1Vq05DEoSbM7m9K9plEN0PYJupGex8N0Lnh5jXsmnA5sAu6Ayd6/BW++Rx+GFyD5nYfAWBdnh2TPPmNxtx+Dlia+4+BLsJbR2vOvUZLRn1rrfVBl5QP6UsPi6mBRDw0Pg8jvrJXVQtgtAulmWKDtI8NVsTBKHmiiNrc4Asw4UWZpfHujw3SNVa7IvptyEJwrloTJlZWifNFZa3lrUpCRw2fOBq0+Dvz3rP1uOPypb2wpfTthjludWxm8PULpGw5duzXp4L+EdiD49VC2J6YnJVqDV8E0BHTsninV7DJZOo51sThfDRpW0v5KwuhSCUHJ2LV34cpqk2GtY04OrFGF+pOKpFEEr2iNP3M2YyLxtNxB4qZQ5qbuf7zsWl67dUHVnb1Ji/VBbX1anE4PS768WMXZPeBtxgr8o1JEGobJUd3X03EHBqTvFvG4yjTMKZ6tJoocVM8+jNbwh8A4NuzJsVvCJlrBOyVGddcRP3+O1nPxnK98AIfQ2mqcJbF+baDLQoa0Jo/wDi48GkMq5mH4L38zKZ7i0Ct8ytfseuvxPh/o52ORafjq6+M4hwjc3U5CsVR1UJIhLtZCN7it5uBl8empiHY/ycflx0onmj2XuzUEi/5dBRvn3dpqQsN+Kdc8DXBVG/87oWyjUqQcBhbwddwTCX5u2FbikjNAuhyuT4jOXNZy8ziv0inqfTtgITYZYM2T8GxpWzFrQinGn2CDAmfJMY3yxksrOOTftsaMCTjHa3qX2O1D2nUzkWn2zSt63fuJmZ+20yPUVm+vCRkXUvuOm1mgRRQO5fIMOnJ5Oxvwadj5GevhXMUE9tTt8T8dpEefVRDh1Z+nAJU+ZRDodWFpM2RZ8SvrTQXi9MqvF74xKE02m2ObeQufof8grQPE9o0U3hnVG1wlvtk8dKkMpRzcATKnolV853xk9ru5q0G8pBt8Rvm9q7D4Uzt/r+m9CcTFzfrC7X4tPRu3JPpM0HHAn+mO+CiVVuqReqSRAKUFcTGfhpIuOru+1i3uMnVYYifArR2bnMqNZLhH9Chpckk7FnfSvQVrBcOso363IjXv38CoCvIsNr/KTKyF6Y+x/0g0idHq3RbEVfnCwWo7mo17AEoX1lbQbRgguk/nnCqcpe+ZSqFd7qIAhNVMlMGXfzS6FJp4namJjJqOrdpsb+HchRXkg2F9+G1lldzsVHt3v2esKz2gShcIz09H2GGT/U3IJWP29k4BYiXtcWmnxmaOjO13PY06LeVTu0mrw32DwJjJX53GUW3fgys3ktbuXU0fTGbyqLgArp1eVYeh2Etcy4fTIcemLD0Br1ql72TowKD56YaNvdNPhEQvZBrN1s8pclvYgXJtX4vWEJQoFpz25qWSAL5lDS+CHyVT0dzlUMb501fzQ5lKZ/9yK5AhNR9xaDL+LUy+N9qS3AH4UuOkpFFzluVpdz8VEmG5eEfq7pJiqcrM+q50JhptTRHT2XQN9xIYkA0E8XLdure+XUkXUguawAN/lMxOcHgwyBrhsfm39OI75t3dAE4XYScPM/5GeD/u1jZbHAs0hzbzIZ26ibOdUOb3WcIrr7riLgbPu/lxJpoTflqLd9eXkqEbvb7S9K94ZDqXZqe18u+n7SnAwttT4jWe7FR3eTOCebNhVHjRCEEpHau6JLDSK1YNpe0POzNs4qU9bU1+XWkVVS9/Qggcf8Fhj/OrFlwVWNSA7ZCRIYkjqqoH83wPvN6dzp41xiXGEbbsHIn2qHtzoIoit6NBGpI7X1UldJkRa6t7x9RGqV/Aqcn2nnckPbcbO6EotP7sKgiuiy2uLVn9h1E2PzV1sXkBoiiCysyhw7kaZ/YuArGvOJF/SvM/Bjnmy5fHT01je9Cvv9vRI6svatTn4t815bToRLAPoHv3LlyqnXJ29LG/SNx9evfTFg3boq3tAEoQl3Vcrx5aDV7Ua9HsGx3ir2sWhWfKLoFnP11m5bCy8r9i0DrW/Ho029f4DvQwYr/DgGgwDV2d13FpANP7V8s6NLKrT4aEI9syI4snzWGkHkgco+GrTJ2JvYPBJMnUD2HQh1S91Kem8B/CfAeJgM8+7xt7cfrsTuuUI60k0l6uhd+T6a5EOYuBfAJ2gqFNzqpxgD+CViI6He5p4X5l8X+/cTZC7XQtlGJ4hawFhkEAQEAUGgLhEQgqhLtYnQgoAgIAhUHgEhiMpjLD0IAoKAIFCXCAhB1KXaRGhBQBAQBCqPgBBE5TGWHgQBQUAQqEsEhCDqUm0itCAgCAgClUdACKLyGEsPgoAgIAjUJQJCEHWpNhFaEBAEBIHKIyAEUXmMpQdBQBAQBOoSASGIulSbCC0ICAKCQOUREIKoPMbSgyAgCAgCdYmAEERdqk2EFgQEAUGg8ggIQVQeY+lBEBAEBIG6REAIoi7VJkILAoKAIFB5BIQgKo+x9CAICAKCQF0iIARRl2oToQUBQUAQqDwCQhCVx1h6EAQEAUGgLhEQgqhLtYnQgoAgIAhUHgEhiMpjLD0IAoKAIFCXCAhB1KXaRGhBQBAQBCqPgBBE5TGWHgQBQUAQqEsEhCDqUm0itCAgCAgClUdACKLyGEsPgoAgIAjUJQJCEHWpNhFaEBAEBIHKIyAEUXmMpQdBQBAQBOoSASGIulSbCD1XCHT09H2FGN+Z7o/ws+Tw4Clz1b/0IwhUEwEhiGqiL31XDYH9F6/cI8zmeZThn42MxJ5wE0QIomoqko5rAAEhiBpQgogwdwi0t5+wndE68QUwfQlA2gQfNBqPbRCCmDsdSE/1g4AQRP3oSiQtEYFI5Nid2Gj5NYB9ck29JgRRIqhSvaEREIJoaPXK4KwI9PQsX5jm8DCADwhByNwQBLwREILwxkhKNAgCxRBEgwxdhiEIFIWAEERRsEmlekRACKIetSYyVxMBIYhqoi99zykCQhBzCrd01gAICEE0gBJlCP4QEILwh5OUEgTyCAhByFwIigB19K58H9KZ5QboUJ6KCNoFQCjXUAbAnwl4ipkHMpPpOx977I6/BO0kX/6AA47dIdQSPoaI+hnYD8DOud/GAPwRoAdNMq8bHY79HgDb+2nvji4yQA8B2N6PDAwcnYoP/jJf1useRCQS7WSD7gewXa7O2ybzoaOJWNxPf/ky3d0r3p9GaIiAPXL/NsHAEan44MOF2untjb5nPG0cBpinAvQJCz5pAC8Q07Bp8PV77MKpWCymdCOfIOAbASEI31A1fUGKLO7rYZP/D0CfDIBGmhg/yqRbLh4dvfVNv/XUfQVqmfwmAZ8BsJVHvQzAwxwOnZoaWvtHa9lKE8SipdH5rVtw77tEFZnedTEuH0kMXuR3rKpcR1f/CUR8y0wdHpmYh8M3PBx7Q9dOZ2d0K4SxGkz/AmBb7774aTJw1sj6mArzdRCpd30p0YwICEE0o9YDjnnRos+2tG79+uVgnGs5KQRqhYH/Z5jpZSMj617wqpjblf8CwK5eZW2/b2bgBOuuu9IEofrv7O47C8A1lsV9NISWw+Lx217zI39v7ynzxtNvxwA6cppkgG+MxAcv0dXv6F25J6UzawFq99O+pUwGhCsn3llw4YYN100GrCvFmxABIYgmVHrAIVNnT/RLYPqWgxwIfwHzfwPGk9k2idvA3A7QBwGE7f0Q4/rWls1nDg0NKfOH9uvsiR4AJmXi2clWQC1uzwNIgGmcwHsx0KHZPW+GYRyaXL/2P1T9qcWUv6BOIcy8NRGOtpiDJgC+BzBene7LoGvzdbP1feRiikT692WDH7HI7Ms8lO+zY3H/h8nM1l+Y+zfXC3yRyPL3sRG+13LZL99MBowXmZAi0JsM3o6AbgC7O4Gm6ybG5q8Wkgj4l9CExYUgmlDpQYas34HTcyabZ7x3Vzyqs2tn01m0pC8AWKWzsBLFZjJpycjIwBSh2L723uW7G+nwfQD2te56mXGnGeIvP7Y+pghi+sva3zP0dTAUAcz0w3wXTKxKJmPKTzH9FeOk9kMQuhMAA1en4oPn+MG6s6v/dBBfO1OW70MGK+zyK3NW2xaKMXCQH3wUZbf3rPqowekbbGbBDIO/korHrvAjn5RpXgSEIJpX935GTp09/VeDebWl8J+Q4SXJZOxZjwaooyd6MjFdbz15MNOJqcTArbq6ke6+Sxj4unXxA/PFu++K7xVwsOpOOOpksCwZjynnccUJQnUQ6elfyZz1IeSc9fy7iXB4yYahNTOnE82gs76EEG4H6DDLz6uT8cEf2Is7yArI+MAHOUf2DwE+qQg9+pknUqZBERCCaFDFlmNYi3pX7diaTj8CkIoeyn/axUvXX3f38dtnMHmf1VbOhItSw4OX28u3t6/a2WjJqIid6dMDAzdOji043csUkl0AJ+kuEA6caZduawtvOtlqzqrUCUL1ecDi6F4hk5SZaK+cDL7MTHbzFAMvhpHpjcdvf86KkQ4fwL+pSEWDGa0t99CUWS77UQE/Rznmj7RR/wgIQdS/Dis2gs7O6P+iEH2OARU++TEQMiHOHGJfvAoJ0NnTdxMYJ0+XcXlPoaMrejQRrbOcNjwT6Vn7te/gGXiGJ0OLR0fXbMqXqyRBqPW2o7vvBgJOzffnx8zkdHA7iU215zyhwO9JbhqmYk85FZtg0nDNIyAEUfMqqm8BfRNEd99VBJw9M1q9Hd4NDXWPIAPjV1BmF6LfEpDgNN+eTMb+OkcEgc7u6KEA3QWgNdfnk+ZkaKmVpKzya04+GSI6cWR4YK1tnDryuTEVHzwtSMiq5q5FUXc26ntGivRBEBCCCIKWlA2MgB+C2O/gk7Z5zzvjd1idr26mqMACWCpU+AQBjUlO6wvJi+QIACA8izT3JpOxjdZxupjqzksND14ZBI+urqO3NWmeihD71HQ9pjOSiYEfB2lHyjYPAkIQzaPruRopdXWtXMiGeSAzTsgtRjMX3TQmJs3CDWZakUoMKJNT2b5KE4QSNNLVdxkTLpwWmuia5PCAOhk5Lqc5I6T0ZTU7f9X8AwB53imxgsfgFgIOsd4voSIu9ZVNIdJQzSMgBFHzKqpNAZV55J20sWuIeB+AP8RMnyBgfwDv092BmFkwnW8658Jb11scvBlmOiqVGFAhr2X75oQgnKk3tGYmzQ1sV6d20Mt+gQCTN7YDwdVshYUgmk3jxY+X2nuiHyamL2UvmzF2KKopzYKkWQADOaj9yjEXBKHxK2jNTM4cTux6+1oIwq+GpVy5ERCCKDeiDdje/otX7hHKmFcS4ZiAqTY2T0VT4u8KniCcCfXqliDUOB2RSRozk/3OR6GQUyGIBvyjqpMhCUHUiaKqJWbn4pUfh8m/APj9HjJsevci1h8IFDeZhiZbjMfVJTE/TmqNjb1uTUwKI0fqDZvzWeN0fpNMPnRkJJbUYTxXJ6xqzTHpt3YREIKoXd1UXbKcnfxOgHptwmxk4BbAuH8yTE9uGFqj0nlrM4T6IYhGclIrnHp7e8Pj6Z1uAxDN4ZZh5uWpROxu9d/tXdFug7IpwreZ+r1wSG8kEv0YDHqIgR1n2iu/j6bqE04EqDkEhCBqTiW1I5DmcpZKmPcTpPk8e54gN6n9EIQu/LKYMNeO7r6fEnAwwC8w6AnA+HkqvnY0L9tc+CDyfWku7k3fW+hw3PlAwdvp6hY1tWTWE7B3vn0mnJ8aHvxu7cwWkaQRERCCaEStlmFMml2wOiKkzInJI/0+AKSNu3eJmol09f2ECf88Izrf0xbeJjo0dNMWP8PR3hWw5X2aS4JwpN7ImZkm2sLjtvQlL7NBS1LrB9SDR9pPlwzQ69ShayhHNA8QsD0B/20CvzdMvnFkJPaEH4ylTPMhIATRfDr3NWLtghsgQ6nqRJMGW7msf5YcHjzFLoTmtFIw86ujvjO81LHwziVBKOe8LdFhNoyVmbfMNi8h1hbefHyhFOhqrM6UHHjTYOPIRGLtsC+FZtN19J3IjJssgQa+8kX5bV/KNR4CQhCNp9OyjEiXqE+95zCSGFQvvHl+6pGhtq3fuJmZ+2cVdiEITbI7dWLxmayvNzwxudOPbCcQR8rsOSYIR+oNdSlNYWG5SOeWWsOBb1fXio+YFHpw1iU34KHxeRx1e3XO2ohLKvV/z0xMHuz3ROipdCnQcAgIQTScSsszIG36C+AZhI1D7M962nuceg6TrgBnnwvNv1WdLcaMW1KJwU/rnNradN/EFySHY/9WIOcQdXRF+4joRsvTpBPMtMp+E1tDEJ65iPy8B+GGuJ1k1at6xGyC6OPZOi6pNVzao86ePoWpevvC8tHNbWHzc0NDsb+5yaH0QQZdPZtAkWHG6lRi0PIORXnmjrTSOAgIQTSOLss+Es2Crdbp35qEk0eHY0/ZO8w9TXoEmL8F0D9oBWI82tbCy3QLWiRy7E6m0fIgAf/bUjfDwI/Nicmv2Xe66lLaljR9kYCL/TwY5HYqYpPPdnO6l0IQagx6DHOjK5CGQ4edyykgqxNGaHUqvvYxO5G290T3ISaVZXY6zfcUN/k/fZR9YkmDdYOAEETdqGruBe3sjH4QoewbB++19T7recvsKYHNT4CypDCTd0llVlWnDuADlgynvzF4y1GJxN1v6UZU4MnRNAP/RaDfTmVs5Y+C8TFbf6rJp8hMH657+1rv7M1K8RZAr0wtnOYlI/HYzXnZSiYIp28k33TBRH6upwH3J1mV8H8BY312LOr5VxOfAmFPZ1v0HAzzmOT62H/O/aySHusJASGIetJWFWTt6OpfTsTKsbltwO7fYqKL1BvSBvMDlhj+581wevHo0LqXXBdB/5fzZjWh3oCAQccUigjq6Oo7gwjXuN0ItyevK5Ug9I8ZKbH9vTinJdEi8ZlqS5EDHWd9dzugXqV4EyEgBNFEyi52qJ090U+Bca2r2Wh2w2qnf3PGML7++Pq1L2rMOrMujbnJpN61DoUnL2XCmQWT/001kCbGjzLplotHR299s9A4XZ7ftFaZFVVUKkGohjURSCW/5qbwoZbJbxKyfh7rqc1t+L4xKnaeSL3GQ0AIovF0WpERKf9Cy1avH0qAetc4AmAXyy58EwG/Y+aBzGT6TpuvwPGuNRENjL8z/ySvp0TVQNRTmeHWlhMY3A+iv7ckCRwD89MAfpkOha5XZOR34NFoNLTxz3QMM58H0Ednn45mJ80rB0F0LO7/MJmsTHULczIWTK3hdxyqnLrt3jZOR4HxaQb2setFpT8B46cavQTpRso2KQJCEE2qeBm2ICAICAJeCAhBeCEkvwsCgoAg0KQICEE0qeJl2IKAICAIeCEgBOGFkPwuCAgCgkCTIiAE0aSKl2ELAoKAIOCFgBCEF0LyuyAgCAgCTYqAEESTKl6GLQgIAoKAFwJCEF4Iye+CgCAgCDQpAkIQTap4GbYgIAgIAl4ICEF4ISS/CwKCgCDQpAgIQTSp4mXYgoAgIAh4ISAE4YWQ/C4ICAKCQJMiIATRpIqXYQsCgoAg4IWAEIQXQvK7ICAICAJNioAQRJMqXoYtCAgCgoAXAkIQXgjJ74KAICAINCkCQhBNqngZtiAgCAgCXggIQXghJL8LAoKAINCkCAhBNKniZdiCgCAgCHghIAThhZD8LggIAoJAkyIgBNGkipdhCwKCgCDghYAQhBdC8rsgIAgIAk2KgBBEkypehi0ICAKCgBcCQhBeCMnvgoAgIAg0KQL/H52JHfOwXYv9AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-38"><g><rect x="321" y="751" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 801px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Check for ACPI Notify() events</div></div></div></foreignObject><image x="322" y="787" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfX2cHEWd/vPtmc0moBIOJYABRT09UQENZF9mN67yjkBCwuxugEA4FERy4BvyEVFRwZdDUfOLcqIoAYTsDOFNBAkvrtl522A8DhH5CQoCAglwvAn7NtPfS/XObHp6qrurZ3p3ZyfVfyU71dVVT708Vd9Xgn40AhoBjYBGQCMgQYA0KhoBjYBGQCOgEZAhoAlCzwuNgEZAI6ARkCKgCUJPDI2ARkAjoBHQBKHngEZAI6AR0AioI6BvEOpY6ZIaAY2ARmCHQkATxA413LqzGgGNgEZAHQFNEOpY6ZIaAY2ARmCHQkATxA413LqzGgGNgEZAHYEZRxDxeDzyxDM4MMK0lAlHAJgPYN5ElwkvgPE4gX5HjOTw8C6bN2++YkwdEqC1o/tYAm6deIdxb3MTL+7vT/4zSD07UtmurvgbRsboFhA+Wuo3A8flUolf1REO1NrRu5BgngtY7SzNmwKAZwH+O4zIquzGdf9dR22e0qYsXBTfN2LSPQD2tX34FTL5yEwmmZ3sxkzF+hZ9aO3s/gIxvlNDf14F6DkC/5WJ7yqwccumVN8jAFi1zrbO7qvAOLWe95kZQxALFx6/mzGr6TwCzgQwV3UQADwH5q/DxJXZbHJI5T1NECoolZepd4IQ7RvO02oCTgEQkfWQgOdh8mGZTPL+4Ag0xhttHd1nA1hT0RuiNdmBvnOCbIBBEJnK9R0SQci69yAZfG5mY/K3KjhpgggyQ1zKtrXF5yCKVWD6MoA3Vl8lP0ymcUom03efXx2aIPwQqvy9zgmC2jq7LwPj0149Y+AvPBZZNDh4/ZbgCMz8N6y1FsF6gI6S9OaxgsGHbNqYfCzMnk7H+p5EghBVF0D4/ujrcy/wk1xogqhxJh3cFd+jKU9XM3CYR1XiVvAsQAywuBHtAWCOS3lxLTw9m+q7wYvhNUEEH7h6JojWRT3vJZOF2GRPR8/sc6cZwIOv7dS87IEN17wWHIGZ/0Z7e7yNDfoNgDcVezMKYJatZ6uyqcSPwurpdK3vSSaIIknwF7MDye967TOaIGqYSe3tS9/GRvR2APs5qikwcB+BLhudbW7YfHfyZcfvFIv17slk/jsDn5OIo4aIsCIzkFjv1jxNEMEHrq4JwqlTEqc85ktg4tuqYsfgiMy8N9pj3Zcw4YIJciCsBkOIlYokwZnR2ThasuYCd3Y617cLQbxogg8bTCU3q3Smq2vl7NHRV+axET1mGwl8FcBbHO+9YrBxTDq9bsCtPk0QKkhLyiw4NL5L8zAlK28O9DcyzE8oy/ja4v+CCP1k28nwBMdnnja4cHg6vf5PsiZqggg+cHVNEBUKSR6MoOmoVOq6F4P3tDHfaGlZPs9oKtwN4P2ihww8GWHjJNMwfw7Gu4q9DkVZPd3rOwyCsM+CtvF9pg/AoWWzg/kWmFjudgjRBFHFWurq6oqO5uetZvBZ5a9zfz6K5ff1J58NUu2CBWc0zZrz8hqAz7C/R0R9I6/vskImJ9QEEQTh8bIziSCYcW0unRDKamWLk+CIzKw32jriRwJ0y8RtgXGvmW86nprGfkDAaRO9qVFZXQ/rO2yCEPW53Ig8byWaIKpYIy2x+GEGWRPVrkfYbEbzSwb7b3yqiipRtJC4jYBW2/tDJvPiwXTyLmedmiCCozyTCAKEtdmBxMrgvWzMN8SmPZKftxbgE0s9JMY3M+nEl1pj8eOI6Eab5VdNyup6WN+TQRCiTqkFGNMns+k+IcWoeDRBBFxPLlYULzKMo3KpdYMBqysr3hrrWUrE15cr3ei65uiWU/v7+/P2wpoggiOtCSI4ZvXyRkfHsnfkEeknYO9im0a36fk+lksl7m5ri78VUeq3iZlEkaqU1fWyvieLIKTGEB6HEU0QAVeAxIoCqPFKW2qCkHvOGsbtALXbmiU9DfkQBLV0xD9kEH0cJo4EWYtK2NXnAX6UQbdQgX+WzSYfDdj9ieLCWejJZyIHEZkrwZYF19sARIsFthDwAAhXz4rwzbU674nbVaQpuoSIehjY3+Y8Jix8Ht+G1waTzCsGB5J/9hLJVEsQYlHB5JsJeLf9dsfMp+XSyUQ1YqCWjvgCAyRuhruqjgETzs8NJP7Tq/zBi3r3jnKhF0w9GG9vyex6AisY5pXz5+GhZDIpnO98H6fDVsm5sKXlpDdR09gFRfHO7gCGwPwwE641R/NrN2266QXfyhULVJ58+YHRaPSQzf3XPw+A2jp7VoN51fbqqlNW18v6niyC6Oxcumeeo0Ip/U4b9Mnm6NYTnYdQ8bsmCMUJWirW2tH9Q4JlNVF6XjOZjxxMJ1MBq5IWb+/o+RQTfwZMv2bwbbOjnJNtsG4E8Xre2MsAr3WIqmTfKhDRDZw3P5XNJv83QNupfVH8I2ziRwD9m8J7r4L4G8hjTVBrnOIG9A0CPuFhFlxqQgHgAY5GTsv1r3tc1q5qCMJFbjtUCzmItoVNEC2d8f0MpsuKSkipk50DE2WHKRlBkGE8BZNvAPgd8jnAtzVHd4739181rDBHPIvIxs15KKvQTwATN4wg36+X9T2lBOERhUETRIDZ09Fx4q4FjN0BUIvtpDIt1iYygiCDfsrMPw50KgX+xzDzizOZG//uB4W4flPEuJjBIgyEyiZkq5IHzWjhBFUdTfEkJ3xB9vJrl+P3rQycJEQPzveCEoQrORB/KjeQXFvNzaHUphAJgto6elYALDyLgzpp5gn42sjQ3O94OUw5CYKAc3k8WoDTvHuCrIno5MxA37qAYyc/NEl8H0ripdILC7qWv3lWPn8PQOKGOf4EvNnX0/qeUoLQIqYwpqmwAogfCIPuYuDNE3OQ8bNMOiFOuFP6SAjiZZAl4tl5+wKxYj5tFPFYAH4LCIvA2M3ZUAZ+MTY090yvTcLN0mp8IeIFYvyBQcKDNbLt5nMQAe+ziZxKn3yIzPzRfmTU1hlfCCYRH0mILeyP8AAV30iDaYTA+/K4Ut+5MW6FYRzpjFcUhCCEg1Q0j+sB6rI1YIhDIAdr8Xf1vp3yLLymi4YOfCCAhdu/xY8AhgiHMPEw4+Zcuu8O25+orTP+eTB9S0LYeQb+RKDfj3vO8gfAEN9wOmgWCHTFyNAu57qNf0VMoPFYYqV5JERXaYD+VrxNxAD81RyLHBqWt3flqV5uAuzwkRAwBVJW19P6niyCkB1MSsp+2QambxABtvWKTVm862EBEKDqwEWlbdm+lTxMBs52+mIIvcFTT6NHnKwctww/23GXjYgfNhnn7LMX7nXKs4tWWV8vxqWy3zbubI7yCW56iZaupfONfFRsgpate/EpiM3RjPB5zjAK1qZfoK8WQ1SUdCCAxL5blSBcbODFRnheNpUQN7TQTU8lm7CvFVPRekec0u2bfh6g75pj0W8NDv7yFfvE8ggZUWDwF3KppBBRVTzuQeN4kKORXrtIT2A8VMA+gwPJhwJPaskLTt8HUUTcejKpxEXO4lL9QQBldT2t78kiiPaO7ou2hXMQTnO2tcVLc+nk9sCfth81QQSYxZKFUpWcM8AnXYu6EQQBd43M5riXJ2l7Z/cyZlxj31i8FKAu4pC7UeAeH/0FtXbGTyUmsamWNrECEVZmBhLXyjonm8BgvnD+XrjUQ6kqI7BRgBdnU0kRlsF6VAhiOshBuhn4mLm2tx+/u2k0bSDgABuOLxLxisxA8tdec6xtUe8HJfoDV8dMGUGImFCIGke46XvCmOMWLpUmrK52+3IjD3VldT2t78kgiFhs2ftMimxwiG09b1maIALMZMkECuT6HuBTvkVlBKG6aGWmfB6OWRILESiJioqdoNaObnGTuHB7p+SLVnZaVBF/uW3+QLmJsB9BWL/njR8DvMI2AJN6cyh9J+gNor2zp5eZBcmWbmeexOucULFYb6dJ5m22mEbiaP6D7EDis84bkowg3E7xvhM3QAGZ7wPAd6CAZW4GD7JN3nlQcGtCPa3vsAmipXP5/sSFpMMSz3XMSxhpgggwYZ1gTWfoZRlBBFm0rZ3dFxDjkonuu1gySGLvB9qIRP2SOqQ3ryCnRentw7FpOiOfehGEi44lz+Dzc6nk9ydDrGTvQxCCEDF2RvKvJQESMXaKj/fGKcGrkvgJjyLPXdls8h+ebQNCtdxz3bDlAQw9/Rva23vez4YV9HC7/kpRWV1P67tWghDi5GefLew+xtGDQPgkMQ536gRVDpSaIGogCKGMi1K+c2DgxmcCVBNKUQlBBFq0kvd/Z/Dwsen0ra+WbQ7OK77LJuLVqfGT4O7XAYiXyskUYxJlpOdp0flN4UxVgCHEKwUQ/Z6ANOd5fUkM5kYQY0NzfyMJdTJl5CDdDDxETBKnMTDTybl03y+DTK6WWLzDICsyasmwQU7clYlrHjOj+UWqFmlB2mQvK/H6fYYNOiS3sU/4u0gfOXmqKasrNsNpXN8uBFEtlLL3fAOCipc0QQSAXGIjXU8ipkCLVkIQUrJzWoYIHcc/d2o+Pmi46YobC8rt5Pc/fMXOb3h95CZ78EMmfCk3kPhmgCHyLCojCCKcAMYHeFwEtl2ZzvhKNp24eLJvDqUGB7lBtMZ6jiJiYeVVaq/vxikDRmYaKtNFVbRtCrIXujiNujp0lR9qek4issRv9sfXs7qe1vckE4RSSgFNEAF3nnqSUapu8G5dVHlfdvIHKs0v1WCsMOMs8x+ReXgy07Jcuk/E2AnlkTpcAZsALHCaiTKQM0fHjgnTG9irE0EIoi3WcyaI/2t7fWVexcpYScdXcnORzHuljVq5IZKCEosk4dip5FshT0nqr6yup/U9SQSRJ6L1Y0Tn3bdx3ZMq46NvECooFcu0xipOJgVmOtZhmx6gxuqL1hqLSY0gKnM4V9/iijfLbixF89aNtjzDoWPrQhDuXWL+YjadFDmBQzdrdX40CEGEeaKv2ABUCGIKAglKTvPKPg1y5TYqrNoqxqCO1ndIBLEF4OcBSjHw67HZvDFongxNEAF2PInMtn78IAJe++uOICpjE4UuvvMhCBGXaATATrYpEUoQRpUpVjcEIZlHQdqm0le/MjJrNr931H6XB74svVtP69uFIEJfE364aYLwQ8j2u0w5SPXjSX1vcxMvVg2MpwmibOCtHL0g4zqYlumnPbyHp2NfgOnjWTTIJjypNwigQnwUpG1h4CEx4Q2jWlGH5y2knta3Jgj1IRc5nOvicTEvDDUWk4gHk0d+vTChJcKtZBr3ptPrhJVUmZhjukRMKhFFqxksyeKcKhFTWQJ3iRxaeHGvyqUTNpl/NT30fifIJjypBDHNIiYX8VCYgLsqq+tpfWuCUB/yuiEIl0ELZF7q121ZuADZLWUqCEJmWTRZN6ZpU1Izvj86PPf8Uhwil8RNnulf/cZU5fcgBBGekrrSn0I615xmrpOog5D7MYjYT+TM664AK4vQK+I2uD0EC7yV1ZIDwrSsb00QCsNbLFJXBCGbwGJRzWraepYsnrp6N62SMq9lqfXGVBCEaFB7rPunTPj4RD8C6jpU+x+LHfdGk2YL080Pl96pxsy1taP75wThFMR/Z9D9gHF1KZGTnyd16buyjGJe6V9V++hVLghBtHZ0H0qA8PeYZU0a4HmYfFgmk7w/SFuErJ+aChvt3rVM+GxuICEcAyeeIG0L8n1ZWYnvg69y2e2bLsl/POurl/WtCUJ9JtUVQbhcgV8x2DgmnV4nEnFU/bjESnlQFhlzqgii8rSKrWTSIZlM34MBOloiPuEo9xRA9zObd81uem69nVQryMjhK+H3PVm4ZrsDmSpBuOQkHmXmU3LppEj8HvoTZBOedke5SbpBuMRSqkmEK5m/glKlWRrFoNbL+tYEob7E6oogRLNlcWxqtZt3CRIHN5n/VBGE7ETFwMW5VOIrquafbW3xdyFCIvzBPhO3A2B1LpUQeSUmHolyMhAZScRzZQ5kqgRhLc6u3rcjb95ZdrqexAB1QQhCKisPeLOzSHBs98vLboeqoTYmiSBkVkRBwsfIthSZTwQDT0ZR6Eql1v9N9k49rG9NEDOYIFxOmKJHKhFOK3rulmuBrWQ+Y4dnMjdtdb40VQRhXdMNXA+ixbY2bAXxsdmBpHAy83xcsBpiGEfnUuv67S+7LGbfXBWlk1/FhucI7BaEIESd7Z3dJzPjKrsTHYEunxXdck4I4sQy3IIQxHjbJiNYH63JDvSJbInlBhFTo4OQiVfDMOuU1Ssg9FBWd0VH8/NWM/gsx+SesvWtCcJvZ9n+e93dIKwF2r70bWxEb6/MqsXSXAxu3RU5hJtM80p7iIliWZHWstctTvtUEYRoi0wmbwX6MmiJV1wccZdvjcW7iegXZTkLJLkaSvhIw30TfzE7kPyux41F9p1RZlpu98QOShAu5Og5LurTurxkYIKQh/t+lZlW+nmfu4T7liZZkm5Uk3CDkPs+BA5AKIVf6t/go6ye7vWtCUJ9JdUlQYjme2U+25YS8T4CXTY629zg9F4UN4Y5c17er2Dlnka3LMsXfDbFqSQIjxvTi2A+Dyauc4ZfFvmkI9Gxi5kgTmE2KxJ43j5c8hwUGPiJOTr2FWfoC7HpD+fpc8Vw4qEkDLJPzdaO3haCKRIY7Vr6u9fNTn1a10YQ1gYyHkixImEQMS4v5JsulCUMoohxGoO/7cjCJzLOuZJwUPKqBgOp70NIybhc4jr5Kr+nc31rglCfRXVLEOM3iXgbG+SdO9lK0Vgy0+NmAHt45HTOg/iC+XvgMo8EOZhKghD9dNORlG47INwPpj+O/988ACAR38hODOIHkbLzc7mB5OVew++xMFXTaErzVQS9QRTbKMlnYclgAulh/KZ7lZtwGClHxUXvitGhXVYFSDnqm+3Or7/23+Uxv9QisKp+R2Id5amsnrjRTtP61gShOrKWFV99Px5ioqANf9pkXjmYTt7tpwCeaoIokcSsYboCsG49QZ9AiXdcxCC+3/QSfVVJEHC51YRiuVbqUJUEIV6n9o6esyS3Al+sAAjC/d7Y0Nwve+Ujr6FtKm2A1PfBw9JIqVJHIZnlF6BmkTcd61sThPoo1z1BiK6IBB3/2IIPmyZdss1G/WCPG4Ks5y8R8L3CWNNqp1jADabpIIhSP596hgRBXArgrSrDKCy8mPj0oHmKPcRUss/m3UQrpcLVEoS1WKXiHO4fnY0lQQOgyRpf6ybc0hnfz2CLvFtV5p4Ykwgb/5FOr/u93xjW2rbA9cM/sJ5fnc7fPTy0fcOAT8f61gShPsIzgiDs3bEUbtH8MSD6GEAHAPyWMpmvJXLC4wT6HTGSw8O7bPY6wUk3lI7uYwnYnmg8oJmjSiwmryESepTo7BdbIjBOZzJjAM236VJeBfgJBt1mgn6+KdX3iN+NyOtbwrs5OqvpJAb3gOg9YOxWLD8E5oe3ScB+lY9EfuYXwrgWghD9bZrz0k8IOM3W1gKDv5BLJS9Tn87ykiFtwrSwo+dfo8ynMuEIAO+2zTuRCOovxLgzT7Q2yJiE1DZpx130A1Lfn1oxbuuIHwnQLSUHw/H6/MOAO787FetbE4T6aM84glDvmi6pEdAIaAQ0ArUgoAmiFvT0uxoBjYBGoIER0ATRwIOru6YR0AhoBGpBQBNELejpdzUCGgGNQAMjoAmigQdXd00joBHQCNSCgCaIWtDT72oENAIagQZGQBNEAw+u7ppGQCOgEagFAU0QtaCn39UIaAQ0Ag2MgCaIBh5c3TWNgEZAI1ALApogakFPv6sR0AhoBBoYAU0QDTy4umsaAY2ARqAWBDRB1IKeflcjoBHQCDQwApogGnhwddc0AhoBjUAtCGiCqAU9/a5GQCOgEWhgBDRBNPDg6q5pBDQCGoFaENAEUQt6+l2NgEZAI9DACGiCaODB1V3TCGgENAK1IKAJohb09LsaAY2ARqCBEdAE0cCDq7umEdAIaARqQUATRC3o6Xc1AhoBjUADI6AJooEHV3dNI6AR0AjUgsCMI4jOzqV75jk6AOCdto4/RGb+6Ezmxr/XAkZrR/exBNxqq+OvUcp3Dgzc+Ewt9U7Hu11d8TeMjNEtIHy09H0GjsulEr/ya08sFn+PadCnYeJIEPYGECm+swXAUwBdlE313eZXz2T+3tYZXwgm0ZfdGfgfwxw7PJO5aWvpm1b/83QDgCMADBFhRWYgsX4y26Tr1gg0GgKNQhAg0OWzolvO6e/vz1c7SDOBIOLxeOTJp2kZCB/IpRJfdutrNQSxYMEZTc1zXjqfga8CiLrUXWCmY3PpvjuqxbnW9xYcGt+leZiSDBwGoECElZmBxLXOemOx3k6TTEFkbwIQyiGi1rbr9+sHgba2+BwYOB2E0WwqeUX9tKx+WtIwBCFOiczcm0sn7TeAQEjXOUFQa0fvQsD8AQGtIKzNDiRWhkkQrbHuTxJhje3GUFE9Ac/D5MMymeT9gcANrzC1xeLng+hbVpWMe5ubeHF/f/Kfzk90dXVFR8d2v5wJHx8vil+MDc09c/PmK8bCa46uaaYhIA5Z/3jWOIbZ/DZA/8aE83MDif+caf2YivY2EkEIvB40o/mjBvtvfKoa8OqZIFo7e/6DmL8/sXmHTBALupa/eVY+fw9A+zuwEzeypwHKAyxuFf80xyIfHRy8Xoibpvxp7ehtIZji9rKrOBSYzIsH08m73BoSiy17n0mRDQD2AjDKzKfk0sm+KW+4/mDdINDW2X05GJ8sNUgThPvQNBpBbBOP4wfZgcRnxw+MwZ76JojuLxDjOxM9CpkgWjriCwyQ2GjFxjt+OGdcy/mmswcHf/lKMCQnp7RDrwAi6ht5fZcVPjcCau3o/joBFxZbVdMhYnJ6pmudSgTaOruvAuNUTRD+qDceQSicKt1gaSSC8B/68hLOvjPwZBSFrlRq/d+C1jVZ5ds7u09mxlXFW9QrZPKRmUwy6/e9trb4uxChewDsYxEfcHEulfhKNYcIv2/p3+sfAU0Q6mPUiAQhNoAKqxYVSDRBlFlw/c7g4WPT6VtfVcFussu0tx+/u2k0bSDggPFv0XXN0S2nqholtHd0X1RUvouXnza4cHg6vf5Pk91uXX/9IaAJQn1MGoUghBnqnmXdrkLUpAnCRhAeyl/16RVeSYcCfRTgxdlU8jeqX2hv73k/GyxuEbuP80v1okjVb+py9YmAJgj1cWkIgiDgXAbOBLCfreuvGGwck06vEz4TSo8miPokiMrbA2dGZ+PozXcnX1YaWADComkkP28twCcW39G3CFXwGqycJgj1AW0IghAOYAZhFjOuATCn1H0Gcubo2DGbNt30ggokYRDEwoXH7xZpii4B4d9B9B4wdit+W1gD/Z2YBgowr8wP7zroZ27pnMiefXCc+P38IFwcDr1hIqwtEH8tYlry/H0ncK7CTNCyQY9gPUBHTdTDdHIu3fdLZyPaO3t6mVn4OZQc9lZlU4kfqYypvUxrLH4cEd1YqoeAr2VSiYuC1hO0vOW78kzkICJzJdjy3Xibzc9kCwEPgHD1rAjfLDPXtX+vvT3exgaJm5Pw7RDPaybzkYPpZCpIuzo6lr0jj0g/wXKEFM8oAx/LpRJ3e9UzbihgHAWYpwH0IQDznPPbNPhne+/BuWQyWVBpU8VcdMzlgxf17h0x+UwCLwXw9uIaF3U/C2AjE37k9T3ZWvBsl48BSEvL8nmRpkIPg3ska/xpAIMAJZuj5h1+46mCz3SWaRiCGBua+5umOS/9hIDT7IAGUUjWQhDjk9j8GgErPJzM7E37x7bFfd78PTnhtpDqkSCyA4nTWju6ryzDuQpxlMRq6rGCwYds2ph8zA6ShEi2kkmHZDJ9DwZdOG1t8bciSv1gvKv47oPmWOTQSTTZpfZF8Y+wiR8Je3uF9r4K4m8gjzXZbHJIVl44Cc4axu0AtZd+J8Y3M+nElxTqnyjSGus5icgi3eLjfSuzxiGKVWASzplv9P8WP0wGzs5sTP7WzxjAjSDEN4bzdAkBn/JfU/wwmcYpmUzffc62hUUQB3fF92gqGD9g5mX+7bFa4Tue/jhOb4mGIQgRQqK1q/ftyJt3EvBuG6wvMoyjcql1g35QV0sQ7YviH2WTxO1F2NoHeQoMXD07yufIThp1ShAr2zriRwJ0C4BZxc6+aIIPG0wlN6t2vrWz3GxXOLHlUonTnZtJBZFUQUa2NgmTVzu5FYjo5MxA3zrVdquWExsqRYyLGXyul+OhvD4eNKOFE9z8edo6us8GLIfG0uY+GEHTUanUdS+qtK+ra+XskfxrSYCOmSAZj9uUWFeUL6wDqEWlfluZAgjfH3197gVet2UZQcAsnI2IcVXAb77KTCtz6T5xS5x4wiCIoiWcmPN2MbYiHNyfj2L5ff1JceOZUU9DEYRAvjUW7yGiq22bl9hz+kdnY4mfzLoagmjv7F7mFG0VZ4BYHOI0nAbTCIH3ZeEBLTl9MeH2sWY+0dm+tlj8dJCxcLw+PhBA8d/W/x8BDHE6K/7MjzQ37bSmv/+qYfEHPxFTV9eSuSP55vMB/EuxAiH2EHGLSs/TDNxJoO1ex2xuyqaTV4orttFUEKKI96tsMM4VITkFuyqdHdZHqOa0bP9+5ck5mDWUyuoWIUtmzXl5DcBnVJQnvECMPzBIzI0Igw8i4H2SE6lraJAKhbuieKjUltZFPe8l01LYlww7XAm+vX3p29iI3i7ZGAtgPMmEHIFeYfCbCOgAML8SI7pidGiXVW4k4SQIYYVIwEj5fMerBOQs3IibAcTAlpizJHYsffbPecM44r6N654s/cEixLHXV4HoX8f/Zn4EKP3b+sMmgLZHBijO89L7jtAu9u69CvAfAcO6zXphMFO9+BuOIMTilImawPzFbDopHM1cHeiCEkTbot4PwjSFPHjcMmb8EbGB1kWQP88Z5E/Iop96hrq3OaP9EMBb7DPNL5aU88QddqiNir77nNRbO7p/SMA52/ugrjiWyNGloh4JydUcB6riRkJ4FHnuymaTQuQXxkNtnfHPg62kqPbMAAAQ9klEQVRQILbNix82GefssxfudYoUhd7KmNUknPmEoYV9w7uzOconOG+XshsAA6tzqYS4rfg+bbGeM0H8X7axuwMFLHOKtVw2xgIzbjYjfJ5THChsw1o6l3/A4PyVAB1kXxMM/kIulbxM1jgffdhzzPSZseFdEk6Caelcvr/BBaGzmjioFOv31FEFVVKPH9ToJ7axEcEfzx15fe5VEtKjtkW9B8I0xSHV3i5lvx3fAZzCAg1HEAI7p2NUEU9fUVMQgigG+roeRItt4yXkxudlU4kfexFRS9fS+UY+coPj+uwZNqLeCEKyySsvANVbgfOkG4bzniSkiJJyVnVNyjzSAdyNAvdks8n/9aiHWjvjpxKTmDslQwvXQISVint+YDQaPWRz//XPe7VVZhwAQLqhVsw5oADmC+fvhUu9FNBFRfaPARb6uNLzBAp8SDabfNTZPg+CeAgFXix7p1SH9Ibjc7gJQhAyMnbDy94vmbg7CImrzrfJLteQBCFAc3jdWjgScNfIbI67iZqCEIRkgwzkoSslMeZbYGK5TEFZbwQhVZYqWAV1dJy4awFjd9jI0ZVYWmM9S4nYFqKbA8naZYtn3Nx19+sAxEu/M+FLuYHEN0NYbNTW2bMazKtsdQWJIusMCyLOGVKT3oWL4vs6rMmUiM4pnnIjXZkYEfAWFdnxK96KbrMCSxYfN6sxF4LwjbNVqrdSJ4PHzGh+kasOJ0CoDYEDNRU22vSayvq2WnVFIczHmqtoWIKwQlfv9PI1zNxjQ6kA4i9mB5LflZ3wgxBEpYgFgS1iJBPbdfLVG0EITCtPmP5iptaO7kMJ+PV2HZH7O+2x7kuYcMHERs64NpdOnOJnFeO3KiarXsmm7XoDcGtjgI3fqXAXBxRfMVPlnJPrYCSmxa43ALe+qN5ypAQRwBihJRbvMMgy/d252BbPTTzIDULSNmWz4vb2noPZ4JsYeA3AHwzgfi7wajcLNb95Ox2/NyxBCDAdkTxL+G6FYRyZ3bjuv52AqxKE5BRclfJUYosOMH0ym+4T8s6ypx4JQqIs9V08EmJ1kxdTa6z7aiKcPHECrcKcU7aoKhXVCCWsiNPPAlXoN2Q3HDfFvMSazPOQItPpuFhxychHamXmtWlJ5rd0fsgIIogxguQ7oRFELHbcG02aLRJTfXh7X2euVVJQkmlogrBOufIcB1LlnypBtLfHD4RBdzHw5iLgStd75+BI5ZsuTjr1SBBSc0mPTVwitnD1aZBaYRE+mxtIiJDnNT2tsZ6jiFgs+pJCOJTMgc6biRBp/nOn5uMf2HCNOEEqP62d3RcQ4xLbhnRbc3TneMlCrfR3mT7FKwSJqoJedgDiKrCXbq6SA5CMIJhpmdNc1Q1AyfuhEYT4plNnVmzHSyCsM0xaOzy8y2Y/p1flwa+zgg1PEC7K5ILMqkKVICrFJHiGDTokt7Hvz0HH17mpuCXAqUeCGCfgCocrVz1B5YmXpRufqFe6aSimTPUbA+dGGUYSJNnJv8IU2a9hE79XmDS7Yloxf4jWZAf6hHVZhbVe5RySl5XebIE7AQqU0pfBTTRuOj3hHyS7GUjGOpC12mQThIvRi300h0C4Hyat5Sa6M9e/TuAUON2A8vSYwoINTxACSxdz1ApRUwCCCC13dcWidZG91itBSGTmbmKmCgUuu4TWmGqCAKCseHRbm4GdsYItctcbjqrJsMz3xC20hoslVrAWu5WW3JCDbvDOqoO+H0QHUfpW0WBChJpX8CLHVhBuZDau2nvPwu9VQ46EA3C4tewQBGGddDvinyWQSCu43c7cYTVUFwQBSDeDeiUISRA8qbJUEuZCGlqjNL1lp1gRc0t4zNe6BII4iql+a7oIQvJdqdNhJZG4W4RpgpCPektnfD9iEp74E5ZZCvPjJQK+VxhrWl0vibcU2jxRZIchCGc2siICwulnVS6dsJyG6oMg5Au3XgnCuqFVhN6otMl3KnDdQmuUZqY0w11IBBH0xKmyoKaLIMbxd4TekIiZKnxPPEySNUF4jji1dMbfS0yfJ+AExRuFqPBBNqi7GjG0yvybrDI7DEF4iJomwj7XBUHMMBGTwFWifC5T2ktuGb75HCbzBiExMpgUEdNU5TqW5Loo8w4P4ntijWdl+tma8fHawGol7KDvVyNikrXfitK7xXg3FXgJE3pcQqbYX51x6W53KIIQvnKyMAil3MZNc146klCWVU0u7qmw5a9eSe00+3SzfKnnG0Tx9lUeesN2ipXoKXx9RqZSSR2GDmL/w1fs/IbXR4TNuwjnbT3E+FkmnfjEZJ3uSvVKFOQFZl6aSydvtTb8Cj8BlobWKNUnIdBASuOg/Q26wTvrD/p+WAThbIdl1WcOfwhsrgBDhCa3h+ApFa8qVH1QTMMqv6MRBNziyxBhpcl4WYkgKoOdVbWAgmwq9U4Qkk1oIvSD02FKxcZd4sEqdBuh6CAmw4pJLMj2WPdPmfDxicUZwNmr1gXtxNguwgvge2I1Q4p9FTk/VPsUdIOvV4Kwt8uKu/Y0VoLo/9lz1FRr+qyKZdjldjiCGD/t9rYQzDu2Bc3b1QboEwSsZkB4WZce6Q1CO8pVTkMPK5l7HCG2lWI2ufhBnJ8bSAhDg5oeVVFi0I9UBsFDNbkrStZeIhTIUyLKKLN51+ym59Z75d+uuKUVnfRGm6Mjs/L5ewDav9gfX5Nsefwh71uHDKsi0Yjw+7sS8P9N4M+Gyb/IZJLbI6fKTZoDibSCEkyQG4S1V3DhaCJqY2C/IvGKnBgqj3A4/BYBImqy556iUtl0lNkhCcISNcXi54OsiJv2Z7Q8TLjcomicZJzRTFERZthvQCXB0GZUqA1n/5z9ETcFNvnH5Ul6/MNxFOut8KRWCSXhh7n4vWIjD+mkL/EsDxSfy2pbW/xdiFgZ+/Yp9UWx304zYksPxMzDjjAUyebo1hO9yMZqR0XOCQRO4SuJhyZ1KA26wTvHOOj7gQjCkbfEzU/Jbd5N1mFEZZ6HUWZHJQhL1DRrGDcD1OUBZBD780Cbgdz5xv2UVu8iJoFhxQbJuBfEa7ZlUxMJeUrJhZRlsJUexVDa3PwWxmTFYnJxytwK4mOzA8lNfu0SuoTR/LzVDD7LVnaIYRydS63r93vfaU0mCFq8Y4tnpZwgSRamxi/Ypb194xGLo+KWbg95/YfC6NjhzhTAQTf4qSQISZynQEQpOQSGEtbFby6E9fsOSxDjtwCpqMmOrStBuGwGeQafn0slRTgIV09Kt3DfzNxbUiz6nc4B783SL2FQRf0d3eXOf1WcqiWhpJ8hwr3MOKn4vUAil8qQGGohrb0WhzSXQhVhJNy+0RKLH2aQlW3Pnhv9LzBoiY+JI7XG4t1E9Av7u/CI8OtsgzP0hpV4h9kE0QetssFiQ1FbZ/dlYHy6/Dt0TXPU/JRXrmUrm55Bq8v0MUCZSbm9zukmCC+dmCxqMQClCL2ykN8q+rewNvcw6tmhCUIsmdaObpGo5UIXMD1j9LglDBIJVQoR4zP2rFaifsss7mljMRELxZUjPal3KGWZfBuGcXx247qMrO3TQRAW6VaE3rC3zj20hqwPTlPXMEJiSBSwvgEGgyw0l1uAqOJFMJ8HE9c5o3m2tJz0pkh07GImiJtD1PY95dtH6R2XuEHjP3uE4ZD10eUWIM4+v2dEVuVS68StqOwg5OZM5nX7mGqCkIiHPfNOyFIHAO4JoATS47nIjZ8C/A4bthMm9UHm1HSW3dEJArK49bYB8Q3iFkbKUZWruyT+k2hmAcCzAI2AzEcLI/kTS9f36SIIiUnrBJxeoTXkJFeZOzloHc56iyGYNwCYO/5b7beSipP8ofFdmocpaTd5tZUZj9vD9Mfxv5kHALRAknJ0iIk/lxtIXh5kg5DlKSm+7+t7IvtOW2d8IZiE93qlySbhBTA2AvSclQbUxIdBeHtlPfQ3GOaS7MZksc/lJaaaICSHLdGgPICnAcoTY+OspjlnlYIjukgLiqRblkIWVmphwofA2M2Bg2eqgSBjPJVld3iCEGDHYr2dJpm3AXiTA3xfghDli6KQtc40ogoDKTb4xOhsPssvX3Z7+/G7m0bTBgIOkNXrTPwyXQQhC71RbK9naA03rJwyXEWFrSv0FZtDwFO1wphaRcZFE3TFNnGESDEb9FHKTCir1N2ju3oiHL8p8w2O07BinwQ50Amy8PqlCqaaIFzSANj6UxnN4OCu+B7RPK730Vm6YZIXyZJGhuZ+Z6ZFfdUEUTwHyOWt7lZMzplw8KLevZuYL2XmZZLToGTi8MNE+HxmICkSwitFfizeIkQOXpkDTpmoZLoIYpww48cR0Y32uFd+oTXcVlalZVD1G51E/1DVqVpxZ7REisUc5JcCeKvKewzkmPj0wYHkQyrlZWUkFkgim+LXMqnERdXWKcRg1DT2DQKE49+EfsWjPnESv7yQb7rQLwbRVBOEJVquTO860RW3LHviJsER+moxF7sKBqLOB8ngczMbk79VXefVjtFkvKcJooiqywld6QZhHxhBFBGzECdgGYjeY7tqilPh49vEkxsYdH21UR5F/VHTPB+Mj4Gwd9kmbIuOOp0EIQu94ZWnwGtiSzb1qnUGleE7lE1ua1p7IrthdPaLLREYpzOZMYDm2zbZVwF+gkG3maCfb0r1PVLrRiIJRqjke6LSScvRdISOBeMU4RcAYA/bHNyyLQ/1X8H4eWEsf7PTWsmt/mkgCKspQl9iMAn940cBzLO1z3OOFXNuHwWw8FVpKeoTS7ojazwB424Y5pXz5+EhHc1VZWbpMjsMAhKC8A2t4QWOxEvYN7WmrD6JAl3Z5HaHGTzdUY2ADYEZd4PQo1f/CMjs8TPpxJeqbbnE1DAw4UhMcKvSiVTbB/2eRmAmIqAJYiaOWh23WaKkDkW84Ugdq+zwVYLKad3DwMW5VOIrtYpz6ngodNM0AjUjoAmiZgh1BXYEJEplz8ihquhV6ogCxQZyhqF4AgU+JJtNPqr6fV1OI7AjIqAJYkcc9Unqs1DGzprz8hqAzyh+IvBJ31sX0X0yM0TaR5EVUDnkgTOsib49TNIE0NU2HAKaIBpuSKemQ8LLNjLKo5nMTc+JL7a1xd/JBn2bCEtKVi0i1INhjh2eydy0NYxWOS2zSnk8fGzLnd7yMy5pSxjY6To0AtUgoAmiGtT0O8I5cCkRr/eAoiBybGQGEteGCZfDqdH3FuG4PUxKm8Lsn65LI1BPCGiCqKfRmEFtcQn9YeuBd2ypGrpafiPwDmZXFnBO8cZRQ9P0qxqBxkJAE0RjjeeU9cYnsb0IH3KGX/iQahvriJ81ykzLc+k+4bld9tij9TLwF0SNI3L96x6v9rv6PY3AjoaAJogdbcRD6m9X15K5I/nm74J4SdFbPA/wZiK69K178M2T7T1qDyIn03U4AqwNEWFFZiDhJRILCRldjUagcRDQBNE4Y6l7ohHQCGgEQkVAE0SocOrKNAIaAY1A4yCgCaJxxlL3RCOgEdAIhIqAJohQ4dSVaQQ0AhqBxkFAE0TjjKXuiUZAI6ARCBUBTRChwqkr0whoBDQCjYOAJojGGUvdE42ARkAjECoCmiBChVNXphHQCGgEGgcBTRCNM5a6JxoBjYBGIFQENEGECqeuTCOgEdAINA4CmiAaZyx1TzQCGgGNQKgIaIIIFU5dmUZAI6ARaBwENEE0zljqnmgENAIagVAR0AQRKpy6Mo2ARkAj0DgIaIJonLHUPdEIaAQ0AqEioAkiVDh1ZRoBjYBGoHEQ0ATROGOpe6IR0AhoBEJFQBNEqHDqyjQCGgGNQOMg8H91paTKirrUQgAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-49"><g><path d="M 371 1001 L 371 1044.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 371 1049.88 L 367.5 1042.88 L 371 1044.63 L 374.5 1042.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-50"><g><path d="M 321 951 L 51 951 L 51 407.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 402.12 L 54.5 409.12 L 51 407.37 L 47.5 409.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-51"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 962px; margin-left: 312px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="303" y="956" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-39"><g><path d="M 371 901 L 421 951 L 371 1001 L 321 951 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 951px; margin-left: 322px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Any GPE <br />pending</div></div></div></foreignObject><image x="322" y="937" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tnXucW2WZx3/PSabTggouQrkr6Mf7ZbXKJHOpo1ws10IhMy0goLggwsJ6AVTcXV0BRfyosEUQUblJOwnlJgpyqWMnk2Tqpy4iy/aDF7yAQAFbWnDameQ82zeTTM+cvOfknORkkpw+559+mry35/uceX95b89LkEcICAEhIASEgIYACRUhIASEgBAQAjoCIhDyXggBISAEhICWgAiEvBhCQAgIASEgAiHvgBAQAkJACHgnICMI76wkpRAQAkJgpyIgArFTuVuMFQJCQAh4JyAC4Z2VpBQCQkAI7FQERCB2KneLsUJACAgB7wREILyzapmU/f390W35+TcBfLK1UQR8JZNOfrllGhrihixYcFbH3Lmb32OicCwIhwH0egB7A4iUzC4AeBbgP4PxkEm458B98EgqlVKf+35ifQMXEeMK3xl3ZNgC0PME/gMTP1hg4+616aHfAWAvZcZ6B44l4B4vaWtNw4SLcyPJb9SaX/IFT0AEInimDS+xu3vwnWzwwwD2slX2mDkZOWxsbMVzDW/ETlrBIQsTBxkmfYGApQBe7RPDJga+Z05MXrl27Z0v+skbgEDoqnuMDL4gsyb1i2pCIQLhx1vhSSsC0Ya+jPcOnAtguabpBSI6NTMytLINzWrpJnd1nfKaSHTyUiacAyBaZ2O3MNElB+xtftfriKJBAqHMKIDw7Yl/7P7Fdeuun3SySwSiTo+3aXYRiDZz3ILDErvN2YqfAdRdarr6ozZ2TG3wfSjgxGw2Nd5mprVsc7u7Bz/ABlYCfLBLI0tTSrRtKg132qac7FlVx/x95PkzXnzVQIEoiQR/ITuS+qbTSEIEomVfz4Y2TASioXiDL7yrJ9FrEN0PYFdVOhENMZtvA+jdpdo2k8mLMplUNvjad74Su/sSRzPTLQBeW2k9rwcb3zFAPxkdXfmMvXNNJBKRp5823mAa+BiBzwKwZ2UZdP3E+G7nuf16V3k0ArHRBB8+lk6t8+KV/v4z5k5MbJ7PRvSY7e38T01bNhtsHDM6unJEV55GIHzV76WNkqb1CIhAtJ5P3FpE8b7Bq8F8XjkRET5qMj5MwMemP5PF6kC8Gu9LHAKmn1Su9fB6k3H+gftitdcpong8MY8idD5Pdc7zLA0cZ+aludGU6wJwvQJhBRKPJ/4JERoC1OK65WG+GyaW6UY0IhCBvFJtV4gIRBu5rKtr2Xyjo/AQgHeWml38FUeM/YjoDssOGlmsrtOvhxxywh7GnI57CYjZirodBT47m039vZYquvsGTmSGGpFMiwQDOXNi8hi3hesgBUK1u7t7yevZiP4MwNstdjiOCkQgavF2++cRgWgjH3b3DS5l5lst6w1jEXQcWShM7oIoDYPxppI5slhdp191c/4EPLhtLifWPZR6qY7iKd6X+ByYvmbdElttc0HQAqHar93swPTJ7OjQ9+z2iUDU4fE2zioC0SbOmzr7sNdtABLlJjNwdS6dvEAtRcR6B35gnWYCZLG6VteqrawRk9Q24oMsrJ9A1PhIbnjln2ott5yvu/uEvUyj4wEC3mMpK9UZ3XDy8PBwXld+IwQitnDwbWQWt0vvM10n4absSPIMEYh6vRyO/CIQbeJHzdmHCQaOzqWTasoJ8d7EIoDuBjCnZFJNi9X2joiB43LppJqHhzoc1jFv0yICnwPQ+wDML9W1BcATDL7NnMjf5DZVou18azggpeb0EcEqgI6c7sSZTs2NDv24XpdqflkXmHFebjR5Xb1ll/Nr6vgLmfmFmcwdf54tgejrW7JPnqNqUfqN1YRKRhBBeb69yhGBaBN/aX5Bzlhn0KxPqCOy5RGGZyudBCLel/ggGNcB9NYqheXB9G2Y5n86bN+sHO0wVnd28OLh4dTLXhva1ZtYYIAetOwuerJg8KFr16Se9FqGLp1mG7FKFviaTunXe3L7Kew0M1bNje6SHh6+catT2xsxgtAKhIMvRCDqeavaN68IRBv4Ttdp6Tr/WO/AVQScbzHJd8dWIRDMi4nogO3baq+07b5xJceEn0128sm6+XrNaMf3lkmNkP0ol06eWe1EcDV327cRq/TEuDwzmrykWt5Gfj9rAiFTTI10Y9uVLQLRBi6L9Q4cRsBPLdNHr5jMi8ZGU2lr8zWdm+/Fak1HtALA8RZxUAe81K/0UTBtI/BBPLXTpyLshFNsHd1ox08cKY1gTgC8OJtOqfMhdT0a+7Ws66qkhsyNEAjNKMxRDGUEUYPTQpBFBKL1nVhx9gHgzMRcHGX/da6fHvG3WO1yYlfNw99lRvhC+zROcT0gigvB9O+2MBSOI5jK0Y7eJp17ursTcTaKhwVfU/re90jJwe0U6xm4mQinTn9P+D3y3J/Npp5u5qvSCIHo7h34culcRtm0AjMv0Z3JEIFopvebV7cIRPPYe6o5Hk/sZ9vCCreol5o/el+L1Q4CUQDzl/bfF1e6HAzTbt906nA0nbzndtptDGoKqKfnuFebNFctyH9w2jk1rI94cqzPREELRE/Pie8wKfIAgH0tTXFcxxGB8OmwkCQXgWhxR1aefcAGMunQTGboMV3TddMGIFqeHRlSaxNVQztrBcLlhO2MKa7Kg3xKzC7JjSQvt7dVN9rxMs3U23vyawuYvA+grlKZnoWlmqu1i7YOc/LVygr6+yAFoqtv2buJCykC3jyjnYTvZEeSn9G9Jw2OxeR7DSpovlKenoAIRAu/GSp+zrb8KymAVPyc0uM+ZaTb/ulnF46mI3KcdrCj053VgEsHW1lX9WmmyvWY6nm8uri398SD84gME6AW5aeeEAiEign17LOFvSY5+n4QPkmMI+wRaRlwPechAuH1LQpXOhGIFvan9t4Hh5OuVjPiPYNng9i6Z9/zYrVmd9Bfoyj0p9Or/ugFVXfPwGVM+KKXDlZjX9UFYc1OrfOy6eQ1XtpWLY1+9KU/OOZUVn9/4lXbJuluED5crb6K732Jqe/S3TKMq5hemZHkKqdEIhCB8m6bwkQgWthV9rl2Bjx11tpfwh5PVmtGEL80eOuxo6P3qMNwVZ+K/C6dnm6E5LaeoNn95DrdVrWxtgR+ThaHSCDUTXNnZtNDt7tNQYpA+H2bwpFeBKJF/ajfkUS3dUafO90pHEPZFIcrST3N1ds7eBV/6OVdOk949IFbXvGCyo9AqPJiPYOnEBXjS5UeLsaXSqdv22ivr/L8BN/bGd014XbAzEuby2mCWINooxFEnohWTRJd+Ks1K/9ajZMsUlcjFM7vRSBa1K+asw+ep4mUSZrFbXV5RNXFar8dvB2f3/ya0BtO00wV2305oNAaZRsW9C973Zx8/mHL3RrwK5AtLBDPAfwCQGkGfjo5l9f4CTooAtGiHUWDmyUC0WDANRavOftQY0kzs1UNR+G3g69XIHSjHd0pcc1236q2+CXmsCng0Ylo9NB1wyte8FueW3qtkPhbg5jVnT8iEEF6v33KEoFoQV/pAtoF1Myqo5DZFghll2bqqKJTjvUkjrPeecFAIKE17FwrFtmBhnTEIhABvdFSTEMJiEA0FG9thWunh2orSpPLfZtsMwRCs/g8I1KtZpQRWGiNihFQZVgTlSSwnVLl+kQgAnuhpaAGEhCBaCDcWop2OMcwDuDZYtg43w+re5CtcZJcF6ubIRDKpIrtq5b1Es2IKqjQGhU0dXGinEKb+HaFJYMIRD30JO9sERCBmC3SHuvRnn3wsLjsVLz21jCX8polEJWBBnl6msk+ogoqtIYTM024kglmPi03mlL3OAfyiEAEglEKaTABEYgGA/ZbvKZzqnp4zK0O7d5+wDnmTt/ARcS4YrpMnyeJaxUYXYTW0oVID9tuy/O0Xdcvd2t6hzhFj5OZP8rpQh+/9YlA+CUm6ZtBQASiGdQd6tTEGVJnl7SRW7022+FMBJy2iNbawZfbU0/+ijMYjMvZ5O/ODFZYHw+P3Cjek7gYVLw32qKVgdxJXSxPBMKjJyRZUwmIQDQV/8zKNRfpuEZu9dp0XblOd1bX08Gr9tSTv2J6jbEaxMu332K30nIXRuALxjqOakTTuZVSDBxuF4nJKJ/2q+HUs17529OVwqOfVwqPvmN9SLa51opU8jWIgAhEg8DWUKzu7EMgoST0IxNop2rq6eDrFQjNAv0zRFjNjFNKPAPh4dU3h/QOvtkA/6Qi6inwPIDPo8ArHK5V1VYxNWrAIIi+AmC/ikQiEF5dI+lmiYAIxCyBrlaN/uxDcKEkNGsb2pPVzRSIosBUhN6wkguORzV/lL+PL1z6Xph8O8AHa/JsAuFGwyzcsHXrHk+sW3f9pD1Nf//xu2/Ld8QYdDoBi52ubWUgZ4JOX5seekLXtiDDfXu13ZpODsrVQq3984hAtIgPNR1j1UNtfpqu3R2lWaxutkC4HRIMOrSGV36x/qVvoHzhZoD6quR5DqBSzCqOli7jUf+6PVtA/FXksdxtNNKCAuEVn690DByXSyfVpU3ytAABEYgWcILD2YdAQ0lo72qYsn3GnH6zBcJpUR0uO69mw4XqToWnnqEBAFcBUGdL6n22gOk6Mx+9dGzsx5urFSYCUY2QfN8IAiIQjaDqs8x6b4HzWp3+hPbMk9XNFghliz2shvqsUaE1vLIrp1PrCFsLOIkYF29fPH+r3/wAr2fCFXMjuH14OPWy1/wiEF5JSbogCYhABEmzxrJ0B7MAXpxNp+6vsUhtNv0p4ZmL1a0gELrQG43gUS/bYjuj+WOY6DAA7yNgnxmn1gkvgvlZwMgR8XBhIvLg2NiK52qpVwSiFmqSp14CIhD1EpT8gRPQCETDQmsE3ngpUAiEiIAIRIicGRZT7Oc2Gh1aIyzcxA4hEDQBEYigiUp5dRHQLFI3PLRGXQ2WzEIgxAREIELs3HY0rXI7rnt48na0UdosBNqFgAhEu3hqJ2jnggVndcyZ99JygM8qmRvoWZCdAKGYKAQCJSACEShOKcwrga7+JftHJngik7lTha1APJ54Ixv0dSIcDyCiPmPgN4Y5eUQmc+cGr+VKOiEgBIIjIAIRHEspyQeBWM/gEiJe5ZKlQIQzMiPJW30UK0mFgBAIkIAIRIAwpSjvBGL6qz0tBdD1E+O7naeLb+S9FkkpBIRAPQREIOqhJ3lrJqA9Pb6jtOTEXD5r3UOpl2quQDIKASFQNwERiLoRSgG1EJiKctr5TRAfD8YeAPIAryOiK/fbm+9KpVKFWsqVPEJACARHQAQiOJZSkhAQAkIgVAREIELlTjFGCAgBIRAcARGI4FhKSUJACAiBUBEQgQiVO8UYISAEhEBwBEQggmMpJQkBISAEQkVABCJU7hRjhIAQEALBERCBCI6llCQEhIAQCBUBEYhQuVOMEQJCQAgER0AEIjiWUpIQEAJCIFQERCBC5U4xRggIASEQHAERiOBYSklCQAgIgVAREIEIlTvFmGYQiPUNXESMK6brJtyUHUmeoWuLn7TNsEXqFAJWAiIQ8j4IgToJ+On0/aSts1mSXQjUTUAEom6EUsDOTsBPp+8n7c7OVexvPgERiOb7QFrQ5gT8dPp+0rY5Fml+CAiIQITAiWJCcwn46fT9pG2uVVK7EABEIOQtEAJ1EpBOv06Akr1lCYhAtKxrpGHtQkAEol08Je30S0AEwi8xSS8EbAREIOSVCCsBEYiwelbsmjUCIhCzhloqmmUCIhCzDLwR1cV6B44l4J5y2Uy4ODeS/Ib6fzyemAcDJ4BwLkDvAvDqUrrnAKxmwjUH7M25VCpVqLVtiUQi8tdnIu8nMs8A43AArwcQLddDwKMg3DwnwncND6de9lJPf3/iVdsm6W4QPlxK/4co5ftGRu54Rv3/kENO2MOYEz2dQCcDePNMu/jXDLp2cnz3+9etu37SS332NB9YuPSAKBeWwsQyEL0VwDwAeQb+F+CbeXLODWNjP96s8vkRCK9pm22/em8oiqOZ8XGA3gdgfpER4UUwr7XztdvFwHG5dPIntbCXPK1DQASidXxRc0ucBKK7e/ADbJg3A8UOzuXh9SB8MjuS+qXPRlD3wsSH2MQ11esolrwFxF9FHsuz2dS4W11OHeQ//vG6F+bM3XQBCP9hEQWnop4H6OPZ9NBPAbAX27q6TnlNJDp5KRPOsYicLut02bG+gQuDPkndLPuVBMR6EgNE9N8A9vT63ohAeHm72i+NCET7+ayixTqBIDLSMM07Aezl0UTVYV+YTSe/66UzLf7CjBiXMvgCABGPdZSS8ZgZLZw0NnzHU075dB0kCoVjEIl8BcCAj/ryDL44l059u5pdsYWDbyOTkwDe6bH8cWb+mEH0Bga+Pp0ngFAbzbB/wYKzOubssulyMD7tw6daBjKC8PgGtXgyEYgWd5CX5lUIBPB9AB+kqamX8rOBgdUE2rx9iuRgAD2laRNrFeNE+GhmJLnKrd5iRzLvpeUAn1WRjvAiMdQUz5Oqk2Hw+wl4h+bX+ONk5o/KZO74s64uTQf5NMCPAnSkJf04CI+A6bdV6tpogg8fS6fWOdnV3b3k9WxEfwbg7bY0BYDXA0ZOfa6xZyMYGRCObrBANNR+NXKI9yU+B6avVYhDcVoJawB6HuA9QVgIxh4z/MBqFErvLX8mAuHlL7f104hAtL6PqrbQLhC2DM8DuGD/fThpXWdQHfDWPH2WgC/ZOu8NMIxF2TUr/8ehYoeOhNebjPMP3Ber7esZU+sFHf9FwNm2zufnnVE+SbcuoREIa3O2EHDZnChfY8+r1g46TPMHjOJayI6HaHl2ZOh83ShCCV7nLi/dwsyDM7IAD+YNPnvtmpQSu+nHxZ6pNI0ZQTTMflVwrCdxHBGttP1o0L47as3pqWdIjeKucpqGEoGo+mfbFglEINrCTe6NdBIIBp6AQcfn1gz9n1NnX5pv/tHMjoFu64w+d/rw8HDenq+rN7HAAD24vXN4reW7h1DgwWw29XeXllKsL3E6MakpLLXgq54CEc7IjCRvtedzEQglYCdk16zMONW14LDEbp1bKTVDJAi/R577s9nU0xU29SQON4jutjIgxg1s8vkuayVuv7jrjuY6m/aXBO9eAmJlNh7eHagpOZh8l22kWixCBCIEHUvxt448bU/AQSA2Mowjc+mVY1UMpHhP4mJQcWqh/Gwgkw7NZIYes+WleN/g1WA+z/K561SRPX+sd0CNJNSopfRwZmIujlr3UOola1qHDrLAjPNyo8nrqjkt3ptYBBQ7/TmltJvIpCMymaFfzaynP7otP/8mgNVuqHLnljMnJo9Zu/bOF93qUSOPjnmbvkfAx2aka9wIInD7Vbu7+waXMrMS6fJa0rjJvHhsNKV+CLg+PT1L+0wy7wXwGmtCEYhq5NrjexGI9vCTayu1AuEypWIvrLil0zR/DuBt052kZats+bNDFiYOipj0MICDSp85jgCcGqwpY4KBo3Pp5ENVBcJlFGCvr7f3xIPziAwTcICl46/YeqlJVyCiUzMjQ2q6perT3T34TjZYMdmxGaBRAtEA+/v7lUDudRuAxA5jnUeQGiC6Hw0ygqj65rRHAhGI9vCTX4HYTCYvymRSWa/mxXoHriJAzdGXHr63M7prYnj4xq3lT0rz1HdM/9L00WGVy9B1SMS4PDOavKSqQACpzuiGk3VTX5UCcfJrC5i8D6AuN4Gw28TAX6Mo9KfTq/7ohZ22g22UQDTAfp1AMvOS3Ghq+lxNNQ5dPYleg+h+ALu6sa5WjnzfegREIFrPJ75bVDmC4LEIOo5Mp2/b6LWwWM/gEiKe3r2k5qB5MrJwbGyFOlBXfLp7Bi5jwhfL/yfgwZd36Tzh0QduecVrPSpdrG/gi8S4zE2MdFNMTLgkN5K83Etd2vyaw1t2m4BKYaxWX6xv4NPE+NZ0ugYJRCPsj/UOHEaAOidSnIrzK5AqT1fXsvnUUVhjXYuQKaZqb017fC8C0R5+cm1lxTZXxq250eRp1fb9WwvVLD7P2Bqqn4rg3wHGL/wj5H9Wh6EtAlEhaA4C8ZncSFKdZ6j6eBQIivUM3EyEU6dFj3FDZjT5L1UrsCSI9QweScTq1PDUHH7jBCJo+xHvGTwbxNY1nV8avPXY0dF7tnhl8O4jPrrrq/6x7U7rpgARCK/0WjudCERr+8dT6zQH5Tz/0i5XoJlqeMVkXjQ2mkqrNFW2nXpqp0uiGWE0nOrz0+l4EQgHEZoOU+LVqApxbZRA+Ahf4cV+ZV/FaI6xurODF3sNiVJmFO8buBGM08v/9+Mrr5wl3ewTEIGYfeaB1+gWi8lrZX19S/bJc3QEwBt1f+QiEM4k21kg7B272+jH7V0SgfD6l9Ze6UQg2stf2taKQFRi8fILWkYQgAhECDqABpogAtFAuLNVdBACUYpDpLZr7lNqt20NoiK6KqxRY4O21UsH71anl/wiEDLFFPR7G7byRCBC4FG7QKhTwH4XWqciv/IDAHYvIXmGDTq0fApbtxBZSz1ecXvp4OsVCJU/iF/QFds822sNYuYOLEAWqb2+pDtBOhGIEDhZs8214gxDNTNjPYOnEBVP05YefnQiGj103fCKF8qfdPcMfJ8Jn9iRpLYFzWptUd/PlkAEsUhbwa6dBMK2A6uWba4L+pe9bk4+/zBA755+e3wsqHt5HyRNcwiIQDSHe6C1ak5SP1kw+FB7kDmXSinWO/ADa8gIBn6USyfPtG6V1WyJdArJ4WZf+eStOrn7FECPMJsPzu14fpX1ANysCYR9iyowY+TkwVEV7Bq2zdVHp+uVn2b32gTAi7PplDr45umRg3KeMLVlIhGItnTbzEZrBMJXuAh9CI3KcBO6sBIMXJpLJ9XlPZ4u5InHE29CpBiu40DLr82rc+mkuldi+vHawTm5z2v+eDyxH6I0DMabptujCTPiVI+GXePOQTRAIPr7z5i7Lf9KCqBjdtjoL9RGZXwtCdYXgm6laIIIRAg8qYvFxMBvDHPyiEzmzg1VTKR438C3wPg3S7rHzMnIYdZT1Oq70vWlK0C02JJ2A4iPzY6k1lZDqQ7bTeTnX81gdVtb+RlnGEfl0iuHmyEQU/cgVAQg/AsKfGg2m/p9NXa6zrGdRhDKPk2wvs0GG8eMjq5U255dn/jCpe+FaarRxoyLqeQcRDVy7fG9CER7+Mm1lc73QdAtnVHzUy6HnijeO/Cp7TF0rrSGunbbndSlCY3tJTS05SrLmaHFme9W9z7bw2p7HQHUO4JQ+Xt6TnyHSRG1QL/vjvJ4OB/Fsl8Np551qKN8NactVHoDT1I3YAShbNOF+95+a9/jKPBiN5Hs6l+yv5GP3G6NdzU9CvPR1hD8CYbWBBGIELjW7cIgBnJMfObYSOpxq6nq7mXqmPya/RIfld4t1LXDKEAVvRHMF8LEbfbO3uWeZ8fRx2wKhPNtaryeDJybWZNS4USmp9BcLluaQtxGi9Tld8LhwqC/MdO/HrCvebf1Eih1YdBf/oYPG2RcV7qdsOKvSEYQIehYZIopHE7UCMQkAMMS378AgroVbRRM2wDzPQAt0FwD6mm6SHshj2XKyHINKFzqGmfiz+ZGUtfqvDDLAgHXa1SBpxhIF69rJX4XGCqWVPnSo8rmt6FATIlkxVRjWfCqXTlqf98k3Hc4uhZZgwiDHzXbXIcJ9EsGVAjtqDcb6Y8w6CSXq0ZnFKNEYs5Wun77VIS6etLvMw7gwmw6qW6X0y5uz7ZAKAOKdeaN7wL8UR8GqetPr2VABfibumWvPQWiKJKd8166iqfuGi9fHlQNxUaAPw/QRU5hWqoVIN+3LgGZYmpd33huWYVAMFab+Y4TjI78QoB/6HRvcKmCPDGuLeQ7vjQ29uPNnitVN8zsuJtYrWHs5yWv05SXPW8zBEK1wct9yzvayuvJNE4rGKY54xrWNhUI//bjMTZooIMnN9nieBWY6djc6NB9Xt4JSdO6BEQgWtc3nlumE4hyRM6ptYaJTwB0GgHvKI0oxsG8HgZWRFG4dWTkjmc8V6ZJqH55Rudu7IrAOJPJ7AFof8sUzBaA/8Kge03QD9emh37nZUtsswSibJ6qf6JAxzPzOSB6Cxh7lEYHL4J5LYOunRzf/f51666fbOdgfU5+L9sPxmlMeJ/dfiJcs9/euF+tTWgCPc4I01LPuyV5m0tABKK5/AOp3U0gAqlAChECLgTsh+0IeAEmH57JpB4RcO1NQASivf1XbL0IRAic2MYmaOJ4Vdzv0cbm7dRNF4EIgftFIELgxCaZMLUwTykAbwHwCJh/CxPXZ7Opp702Kd47cC6A5eX0tV5F67U+STd7BEQgZo91w2oSgWgY2p2iYHtEW2JcnhlNqh1wVR/dITs/+atWIAmaSkAEoqn4g6lcBCIYjjtrKbG+gYuIcUXZ/uLJ+Kjxkdzwyj+5MXE4O7KZTF6UyaSyOyvPMNktAhECb4pAhMCJTTShYhdWsS283mScf+C+WG09RV1upgpSaBToSiIcbz0zQaBr50SfO98ambeJpknVdRIQgagTYCtkF4FoBS+0dRtcT1ET49cMUifxlXDsqeL7AZhfYTEhG0X+xHq3Tbc1yZA1XgQiBA4VgQiBE5tsQo2nyKdbrRamJ6N8mktwwyZbKNXXQkAEohZqLZZHBKLFHNKmzfF3inzayE1gXAaTr7EHaWxTDNJsCwERiBC8DiIQIXBiC5lQjMnU+dKHQFimORmfB/BnYhoBY8W2bbv9Qp0mb6HmS1MCJCACESBMKUoICAEhECYCIhBh8qbYIgSEgBAIkIAIRIAwpSghIASEQJgIiECEyZtiixAQAkIgQAIiEAHClKKEgBAQAmEiIAIRJm+KLUJACAiBAAmIQAQIU4oSAkJACISJgAhEmLwptggBISAEAiQgAhEgTClKCAgBIRAmAiIQYfKm2CIEhIAQCJCACESAMKUoISAEhECYCIhAhMmbYosQEAJCIEACIhABwpSihIAQEAJhIiACESZvii1CQAgIgQAJiEAECFOKEgJCQAiEiYAIRJiFIhQEAAAALElEQVS8KbYIASEgBAIkIAIRIEwpSggIASEQJgIiEGHyptgiBISAEAiQwP8DT5NGvC3HI6sAAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-63"><g><path d="M 531 301 L 531 237.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 531 232.12 L 534.5 239.12 L 531 237.37 L 527.5 239.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-54"><g><rect x="481" y="301" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 351px; margin-left: 482px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">OS moves active <br />core back to<br />ACPI C3</div></div></div></foreignObject><image x="482" y="330" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmcXFWV//e8qk4noBAGJawCjj8XxpVIeo8t+x5IqO6EnUERhIEBQQbFHXBchm1ABGXYSXcXRMEIAhHbdFdXNZCRQQYZB5EdEmXIInS6u+qdX251Vef1q/te3Vf1Xq/n/ZNPuu76vcv33nPPQpBPEBAEBAFBQBDQIECCiiAgCAgCgoAgoENACELmhSAgCAgCgoAWASEImRiCgCAgCAgCQhAyBwQBQUAQEATMEZAbhDlWklIQEAQEgRmFgBDEjBpu6awgIAgIAuYICEGYYyUpBQFBQBCYUQgIQcyo4ZbOCgKCgCBgjsC4EsT8AxPbz9psHczMRxNxHUC7A5hTaG4OwBsAvwjCz5mslXvMs/+YTCbV30P9EolE7KXX8ckY02ImHALCXmDs6KhkEwOvg/GYZeGh3FDskf7+5WtDbYQUJggIAhOGQGtr4l2Dw3QfCPsXG8HA0Znerl9MWKMmYcXjQRBU37x0Acj+OjEOBhAPgMOrBHx/Vpz/o7s7+bcA+bRJGxoSc2DhdBB9HcB7A5SnSCrDsL6U6e14DAAHyCtJBQFBYBwRqGtJ7BOz6fxcNnap18FOCMJsQCIliP0WLt0jlrOvIsIxAGJmTdKm+gsz/1MmleyqdHNubGzfjy37doA+XEU7ciDcaQ/VnNvff9fGKsqRrIKAIBAyAi0ti3fJcc3XGPx5AC/GKdvS07PidV01QhBm4EdGEI0LE/uzTXcA2NWnKZsA+svI71wLYGcfIskxcPvsOJ8b9DZR39x2IAF3AdjJDJayqVYhx+3pdPL/yqaUBIKAIBA5As3N7Z/IgR8CMK9Q2Z+EIKqHPRKCqG9qX0zEtwJ4t6uJapN/3CL611kx+9fujV69Dbz6qrWXbfFZBJwOYK67i0x4YLiWj1+zKrnBpPuNjYv3ZCv+AIB9XOnXb3l7uBXg5UOx+PNrupe/WbydtLaeOvud7MD74sCBDPufdLcOBm4ZHpj7hTVrbho2aYekEQQEgegQqGtOzLdAjwDYQQgiPJxDJ4iGlsQCMKmHHtdpnZ+wKX56f8/y35uIidQVcHOWvkTApaXvFnTT0MD25xhsztTQ0nYlGP/shIwZd3K25mxDMRHVNyWOIiJFeMXJp4obYqZlmVTnivCGQ0oSBASBShAIShCV1DET84RKEB6n9RyBruGcfWk6nRwICrKHeCgH4kvSPckf+pHNgoWJvWM2/RrA3sV6iahz8J3tTzIglzFNLYjMfgZgu60/8IPIYUkl/QqKg6QXBAQBbwSEIKKZHaERRGtra3woO+9aBp/laGqOgMsGB+ZeHnRDdnbX41ayDpZ1aHp1x++8oKlvaj+MiNVtpvhAvo5sOqCvr/PpCuDU3UbessEH9fcm11RQnmQRBASBkBAQgggJSFcxoRFEY2OigS361dgTNh6qjfNxQR+VdV2tb2o7kwjXjX3Eprtr42tP6e7uzmrztLR9mRjfc5z4+2OoOay39+63KoFT10dmWiJipkrQlDyCQHgICEGEh6WzpLAIghpa2q8F8zmOwkM9XevU0gD43gjqSwgCv7V481Gp1P2bKoFzfuuy98zKZn8Not3AlH8kJ9jf7OtNKm2tUD53m53GOwU7jmNBOBugjzmUAJQR36NMuH6PnTmjMy5csODYHa1Z8VOIcSIor+qrDBQVsb7IwM9zlnXN46s7Xq6kE/Pnn1FTW7vhs2zxqVvasdCljbaWgKdAuH2wln9RTrlAQ8Jv28yH9qeSvUHa1ty85P1ZxLoJ2KOQb2iLgsQRmd6uVX7l5OdZ1joMsE8DaF+HVkweK2LqsS3+qRfOJm2sq1s2L1aTa2dwO4g+5DDSVHW8BqAfoGRt3H4wjMOVSZtUGjWOs2dvmM+EBIM/ozEgHQD4FWIrBcbywcHtf1ONZCCvBm/nEgQsceGg1ucfwfzLbCz2U695Wd/cdhQB9xv2b8x+ZKLm2tjSvpSZ7yweShl4OY5ca2/vvc8b1plPVteUaLYof3jetpDvdbbogMzqzj/4laPWbKwmfgwI/+jCR4nqXwDoYZvsm/p7kqqcSGyzQiEInawf8D/dBwG4mLagHbUcwKzi3wj4Vl9v1zc9bhDnE+NKx2/ViJgqaXLgPB4EsbKhuf0IgP+jnIEfAY8Mx/nkx7uTb6jKlWbYy29YXyTmyzVaZc72ZRWWgwNzv2e66CswPBxg4Cc8XPM1LwWBEWt7PLBl8jeOjjHjir5U11eDgFnf1H4CUX5xFz7uG5qNw70IKt+XOM4B09fK4FQs71mycHbf6uRvTBfnfq2JnWty1tXMvMTQYHQTiL+DLK6L8p2rgnEsgqpU1M/bfRfuCuLxQBFDDfMPDHHIAtSFnP1PbrXyqAlCt68x04mZVKdSmTf+GpvaLmfCV7Zm8N8b6+pO2C4WH76MCUpcX9awmJURL/Hp/T3JZ4wbZZgwFIJwMy2AHBGd2NfT2WHYDqNkoyd40MdNFr6GudWZ31QDyqhNYScqIQjmRVuM8z5AICUqKztZVHsUSQzO5gTe2uGd2jkbrmHwGYaGikoN+epMb9dF5Ta9/GaXpdsZOKgCDJ5mi9q8TlANzW1nA3lxYnEzDiQaVGrKg9m3kwAdOUoyfgeJ1qV7UTbXAVBdwL4ow8mrht6Z+5VypNrQkPgAYnSfRt3aoEruzsaxrEj6BhmMk9S1Lt7dysbuqaDvxTqUEspNgwPbn1cOAzU1G5rbjwP4ZjMSdswAdaOw6BjnnImaIPLtLZWMJGvj6473Emu7gdfsWb5744hBLzoAfr/xII4kVLeKi9K9XT8qt3aDlBsKQdQ3t11DwLmOio2uUEEaWkwbpC7daVSRFzN+bsf4osdWJ/9cSRuizKMRi6kbk7JEL/qsygK8BrD+C5Q3LmwC57W0xliqE/AvTGyD6buO39TVfdWIcSIrVyMHahbqRrL50L6+ZNqrnz62JYqd3gRjtaqDwdsR0AxA+dxyf69ZbC1KpTqecP/Q2Nj+UbZYaZ8VVaWNxEOjc2Rh+0fIzuffpfA3T3GnT19yYLzMhAyBNvr3xf/QoeZh7WZKash0E8C/B6y80oRfHVHY3fi0q+AXDY85DFnVfFG3uqIhmnPYjFS+G1valjBDiWOLc7lYRpaB/yaQmgtKQ/FjYHxSk+5pO549rL97xSsqY8PCpZ+CzWeOFGK/p3AgKEoXNjLjfiJ6p1DJAMfp6kx3xwvq/yYipnwdzYlDgTyxF8sNtLcVtDB/OZqf8Byy3JpOJ191z3tvEwElCubnQNQPpsH82iUsdPmPU8UZaXcG2b+qJoiPH3zStu96Z/BnYyc/BzrxBWlwqeggL3zzdLJV35RoJ6LbnWKpQn05gH8Hxo/tbHzlZHHGpyGIIjzqdH+jPTT89cce+5ky6it+SrvqYDBUH522J8qAzyqQw1vqfWj3XdHpFAUURAv/AiIlvtlKMETXpXs6FeGXyDVHZPR0D4BDXOP2NBPOzPR09bnzKd84xHQzAfXuPM4FX/xNdwNg4NpMb9d5JnOloan9CyD+8da0enVkjw3S7wBBdS3LPmZx9maAPu1oS47BX870Jp3izNGfG5oSyv/XjQ6MB4hw3uA7c2/VnLqpYeHST8JWbmHwUUcdZYnbBBtnGo+59vOcxRd4HZ6amhIfyhHdQMBnx9bnr/I9spnbSg7vnKNZYtyQHR7+lmtOo7Hx2J0Qm3UtMx83dm7i6nRP1wUlcywiQzmt1ILpzHSqU41n2a/kQOuxtjwOKp745B2Ovob9LbJ+7LptDDDz0kwqafo249uHqglCPbhRTW41AR901BToGlYWZUeCkSsYP+y0smbCxZmeru/rysk/oJqIWUZOvo8S4X6yrUdTqQ7lwyWShx+//nos2rIng1KxzGgt60B8VLonqZwMlnwKn5o5628k4DTHhvrUUDx+wJru5X91Z9Brk6FraDaf4fcAreqZtc36K8A432TBl4ot2bNNzjbmSS+GewE6zPH3c9K9XdeX9KVUiSEH5kt33xU/8JOpFx6yfwTwSY4yX0KOD0ink88569GRHQBte8Zs3q1L90LWfsi5roKQZLk1pdatVZNTD/ajJGRqIzSCMd2mnriK9fg94CoV+MHsvNsAPt7RLrWRnebnXy0/Z+ZsuA4jItLip31HDKrFZHqDUJU2Nrd9k4FvONbHytr4tonu7ls3++GswXhoy6F0Ubo3qYhy9MubCAzvdAMTPhcEH5VWiXrjWSwHqNUxFhl7aPhIN+mWmxO636smCI22iBIz3Jbu6VIaLaF/9aXiA7WL+54uR0hi/cWFQTaS4wPYROrxh7lzPG8YeoIob5CnHYcRcdo5mVSX4zRdOiQl12BAe43WiezUA5npZMyPwzYb7mDmdkcrXrM4d3Aqde9/O1umeSA0EjO5xVNeG5dugwzyPjWiFVaz0nkr0ilMaA5Qxtp91b7F+C0+zZgHUuDQvO+tJ5sO7uvrfNxdr0ZkCDBfkk4l1bua7yFMPWjHbVv5WPpIsVwtzhHdIPIEUarCbyRmKhVP6SUrGnzKHgidGBfet5RI9X2Fv4f2Blw1QWiYG34n+moZQ3lszHK8B8Dfj5ZlSEhK1GEx3YQRUUdA77L8LGB9Fzk7GaVGiYYgjAZbqwbsI+90joOGdLWbmGZT0Z6I/MZYt1l4zBeqb25TYqnRm025g4Cqt3RT1WuMaBQrtDcA37641CCB0luOZr4aq+0WbstKfPs2gP+0gCc5x9eGMf8aGxOftC06jcCfBmhPIuqdFVt7ounjq24deol6NXP6D1nLOsRUrdp9gldKGH/bpvbYpx6+Q+GS/6K8QWjXVnkxU8kDt5fGpbt/QQ5dxf5Xessptx/PKIIogEELmtv/X4z4LDDUlTeoh9eqXY/7nuxKxR5Gp5WRa/xOdzuv/QCMRH2axa4liFJ1veBvTfp2svbKrnkgfNoejh0YwMe/F7nqyOeWTG+XchBpLFbU3NpKNv+mpqPfbdNsZc3/ma3jHp1WUrkFH9bvpgShFbH5vHHp2qduK0R0NwHrADxBRN2cte9zEmWUBKE/eJR5c2lI7IY4dYPxgUKftG9IWlGXj8jca/zcN7pKbTbc5c9EgnBiQE1NS3exkTuMiNp55Gbh9kCrGxOl3vgTZPmCME5zY07zVVh/N7S03QrGKcXyTE7cKq0JQeiUEUzLdwNY+ogMrWtmzQOh742lZJPwuEE1Nx+/Qw7DDzpVO5lwQaan66ogG6h289ecLEtPd/lalDfhDsum2zZv3n6NgYpokKZFntaUIHRvlFF4H4iaIDS3bH8j3abE0USkHHmOSCoYj9bW8CK34aPmkJFjpqMyqc4HgwziiLpyfLXD75yRSLZcHVUThLqqwqJHGHjP6MZE+Gqmp+uKcpVX8rtO1k6Mn/alulSQkGq/PGGwZe/PrB7USKlo+hBG+DYVJddxj4ml62gJQRieREwIolptDmd7NfJrbzVUt5GRz+mzBDuPtB7vNQ8B9GKQCcTgGhrR5hqNeUIaoz6NjNhdzQAIT8Km27iGHsp0d6h2GN9kgrS5mrQjltZvftBG7GgQn1Bwgz8qqtWJmDQbt+dbRTVti5ogPG7oXsoGJTdUL8UEzVpQh6CVgFWiIOKHDzNvQ4Sjna6OKjHqC/0GUc2bQCUTIqgWUyV1FPMoVbJX1mIfMH0JjDaNXvYQM5+cSSU7q6nHmVcjrzUSE6kyoiQI0xOjCQ6axexjp1Di40srZtI8oHueoHTvZibtNkrj8R7mEyNFV+w6EFYwW7fusUvuiSBWykZt9E9E81uX7Tgrl30/29jbory7kU8xoIxTdTYQo6XpCMK9Xgn4K2w+qK8v+WQIbR0tImqCUBVpNOu03pw1ChaeYuKAxn6BIAvjLbjqG4ROhqZ7RArUM5/EhYV2rzNJFFdWdxPy7gFs++ZSYyd/Fw5B+116CjbXCJvCBOFpy6KZX1oxU6mmiff7yEQQhJoHPvYgftNkPQH/lhuuudYwfknQKZf3wVQzZ/2hxLgQhP00ByGjMnUEodkAfSO9GVWkSTQeBNFQ+q6gFTNpFCA8D3nTniDUWLmNQcJ6INFNFnddUZ1IdHV7GFYZa6WYTP4ZShC+GJZoJmlERxpNF08fXRNFEIXxp7qWxEeI6UIClBGYyZuXyurrnsRkbmnSUOPCxGfZxvUBY7XnrcxB+RvFqFX0dCcID9cbY8RMGpsPXy3EmUEQ7geZiHwx6R4XgdKTotKc2Jx9W0WjWwZYc5RpOhP+NYx3Ea1b8/Iqb8brd4YShK9tQIlqrOvxWTMvfK2Og4i4jAeugoR5R4prrQ9Sjo9hQjsB/1DG39YYVxMVVOnMQg3NbV/c4mH0B2VuDEUPs2tArNyv/LY2tu1TudzGHdzq5to3CJcn06gOdONxg1DglWjWud4INe9bf85ZfICXZfp43bAqnStVi5hUxWFGbvPriEbtUTmmKzkpelivGsvy/dqge6wNQ9ZXrHOyEkSYj9Rue4pym4bmgTDHzIuL7gRKH/r8VRA1ihUVaY5Uuui88uXnrb15X7B9EhiLPVSwy1phm7SrvnlpHcFWmjLOMLp59zME6xbYWD1rlv2Cl7tx0zep6fJIXcRUcxgZc7gpcQVURqXXHdSs3FowGdsw04RCEB5Xr40WW0emUh3KqK3qr+A3aDmIFjkK8zx5lvpA8XaSFaRxOtXGmUAQWg+pFWqP1be0jXHDzsAfeTi20M8flsY3/6jdgsaBo+8mqlW9NNT4CjJXqkmbV5B4DaeC6N+dJ/ww3vc8XF9sAuj0dG+n8rNVVoPKmCBK1S8R9M1QvUMNZWkFAx/aIhX4Hxv4Qxy5a5xxGcbrBqHGtMSwrTB3NGukrCGp/rCy9fBTzRwKI29YBAGtOT24e2g2jikXJMakI40tbScy41bTiHI6F+QmbifKtUWnIhl0wvvVMVlvEPmFUeLXPlpDOSdOJbfUgphpqDY+mA/itNUFfFnDQv0Ns7w7E/e4FYhG+UvaobhxWTbf4tTQyZ/UOXc4ETUwsI/yyprp7VIxJ0w+pS75XQIudiSu+pFXO4eByzK9XV83IYf8XND5RNM4zQzDfsbEIHFcCcLteqMgZtpsW3uM9SJc3n+Y9mYe0JCwMB4ftS1+gEaCgD1JwP8S8/WpVPIlk4nmlSY0ghi5RbRdCcY/j62selsBDze4vnJrbbAP5VM+bh1SdPlbCXAaZ3VlN6Qg9UxmgtC52mCmZUFCrlbhmsXtuiCvxsrMm13RuoxEiRrnhoFvvJpDS4lqbTV2LWreRCGj1unem0Tbc85jnXNIL1cbGkNBX4t493oxcdw4ngShcQiZ3wOQw77OIFU6mxjNXqCLORHU7Ys6SHx7Czlc6ig/lH0pTIJAwZpPyTWdbooVd9xRG7e/WEn4xMKmpCI4OV1imDiz0oGmDkj9HI8trYQk9EQVbuS8yUwQETnrM3YS536DUgtQLQhHtC4jv1UqT1PTkn+wKaa8Am81cisEWjK58XrM9f/MDQ0f7PSiqdmMAxFR2GFzC6RzIAFbYxTknTqaW+96Gf55EoQuXr2hsz69j7FSd/TjSRAKQzdBMvFpxHS4w9WNsXv2uqbEQRblY0444mSYH6z1rtR5RW182xPKeZwtd3gNlSDywLUkFoBJ+Z5x+TjiJ2zCKaZh8RRLU4zOLXhgHRNgpBgxrdxC9iYsqFCJ/4IcLzdxlVGQB6v4wSrKmfNRL9BiLzcY+cXrdrVh6IhwBHuXqw1DubqJJXWx7Tp330x4YLiWj6/E3TeBbpgVX3uuiZM493Wcgf8iZhtEn8q3z9A5YaEvXjfesoeZ/Ny06FqXe2at51yPoFXPkJ09vK9vha/ldr3G5bfhqdR3qmm9HwC3DA/M/UI5lx+KHDhG9xDwCXclXqJWL3ffRDipr6drjE2Ts8zCursIRJc5RMtayYGbIMqp2gdx960Ds9T1Bvds8QasDhsjTkSDeEBQ7tMtuN9XcwRcNjgw93K/MWloSPwdYqQMdVXwr+I3YDMv6k8lHzHZc/zShE4QqrLGlsQRzKQiRzk3U/WTilS1CuCra+Podd8o1IR49VVrLyZuA+XjBqgoVu5vFXLc7o5P69XJwg1E+UTR6Zvn/eEw497heOzJNd3LVSCe/ANda+sxc4eGane3LT6RgBMB7Oaqw+QWE3h8JjtBeAcMYs8Yzd5BZmC0UTpB9PBrNJIkoOzW+wDBTzBi52R6O1QMjTEPtl7Gbn6HFv37GT9rM8593654VGMpXbBPsH7iCgajdY0edJJ5RloEbuThmkt0BnnKvXmsNn42mC70st3wU9bQ3djyYTKZv11bg+vce8FIfTX/Bs6vPUcwK33AII2vJN/YHtUShAfpOYcikLaZR0AlNf1WWowLU6nk/7jG2ceGxfz2UW7uREIQeZIwi62qNCfUaV4BoeI0KAb2itegIqrdPjvO5wYVVQV0c1AOszzRBYjDa1LeaJrJThAjY7t4T7biD2jjK5uHHPUNZOQFmtYOZSRxWY0RXZk+YR7HhE/Nh3e18RkQ9ioth56HZR+TXp38vbYO/QmxQGp4kxj/yaB8+FsC782EfaMOJ6knrXyT1Kb9LMj6z3x4XhU2llEPwh4uF/mbQFjr8FaqRH2+Pth8Qo6O+KJiUvjFGPxpnU2IHwnr49XnAX0TTBsYnI2x9bmiVmW1BJFfByXu3kdH31hsOubw4x2SVSV7hYFeR/jb/bVq0IR0HNklPT0rVMCzqr/ICEK1rK7uhO1i8eHLmHBWGQOgch1RJHLe7rtwV6V+aepaln3c4px6y3C9j5SruuT3TWB8e2jz3GvKXccDlzwFREzFPhWC3d8NUEvwfvKzsGLHp1d3/C5oXq1MOl9IeY0Rr7oKsY3vqSBQvNqBnodFx5Xriy7yV4C+Z5W9z+DA3O+FNeeMIy1qG8nPkm2dbMe4mRijYVaZcWcm1XWynyaUj3ShDBxlXaR7iAy3Fut0XhcGQWhcbxQq07uvNxnvyvHJr4F+O547rhiz26S+cmkiJYhi5XkRA+hyIigbBtOIbiq7Cuz9ddO3gnKdzfucmf3WYiJ8M6BrgZGTFejurEXfMg10Uq49ut+nwg2i2O4R2xQ6GwQV03quQX9VlL7vz4rz1UFvgc6ydRo0XsFYDNqUT6IOM1Qz/B0ClFfgMW9eHmXk4wXnsjWXmvpIUnhxjL5BgIr3bVKHqvppsvi8vtXJ35iqoJr2OR/Sc/b680BQ6q0mLj/+okRCsHGzersr0WozfANSfs1iOfsqIhxjELhrE4i/gyyuK/deWI6Ene83YRCEh/2XsaKE1zjl/b4x/4CZlxjul8YYmc6NYrpxIYhiZWpQNmfpsxbTYpu4kYBdHBNTvU+8QcAzNvhXiMdWROj2mOpbl+5Jw3wIE6tYrvu62lIgBH6F2ErZxCtmx/k31WxqpgMzlQjCOa6DWeswgFWM4kYAOxcWfn5MAfQBlKyN2w+GgaFG3mysMVJuHPL+tgbpKDBOVnYLjr6orGu3xKH+Exj/kRvO/rzSmL+FmNZFvOpcotVNAL8EWKtg2TfvPg/PVHprLtfX4u9K3h+fVXMCg5Uixocc4i2lU/8iMfWAsXxwcPvfOG8wmrCtOSKc2tfTdadJ3flwornc50B0BEZi2hdJSmHwewJ1ZoeG7wqC84hyi3Uas63K/bCLiEdVoEMiCKWG7NYI83WtYYJLMY3CN1aTa8+PC0g9fhe96RbWFT8FWLeEta50bRtXgggCjqQVBAQBQUAQmFgEhCAmFn+pXRAQBASBSYuAEMSkHRppmCAgCAgCE4uAEMTE4i+1CwKCgCAwaREQgpi0QyMNEwQEAUFgYhEQgphY/KV2QUAQEAQmLQJCEJN2aKRhgoAgIAhMLAJCEBOLv9QuCAgCgsCkRUAIYtIOjTRMEBAEBIGJRUAIYmLxl9oFAUFAEJi0CAhBTNqhkYYJAoKAIDCxCAhBTCz+UrsgIAgIApMWASGISTs00jBBQBAQBCYWASGIicVfahcEBAFBYNIiIAQxaYdGGiYICAKCwMQiIAQxsfhL7YKAICAITFoEhCAm7dBIwwQBQUAQmFgEhCAmFn+pXRAQBASBSYuAEMSkHRppmCAgCAgCE4uAEMTE4i+1CwKCgCAwaREQgpi0QyMNEwQEAUFgYhEQgphY/KX2ChFobU28a3CY7gNh/2IRDByd6e36RYVFzohs9S1tXybG90Y7S7gt3dN16ozovHQyMAJCEIEhkwyTAQEhiMpGYSoQRF1LYp+YTefnsrFL+/uXr62sp5IrDASEIMJAUcoYdwSEICqDfDITREvL4l1yXPM1Bn8ewItxyrb09Kx4vbKeSq4wEBCCCANFKWPcERCCqAzyyUoQzc3tn8iBHwIwr9CzPwlBVDbGYeYSgggTTSlr3BAQgqgM6slKEHXNifkW6BEAOwhBVDa2UeQSgogCVSkzcgSEICqDWAiiMtxmai4hiJk68lO830IQlQ2gEERluM3UXEIQM3Xkp3i/hSAqG0AhiMpwm6m5hCBm6shP8X4LQVQ2gEIQleE2U3MJQRiM/Pz5Z9TU1m74LAjLmLgFwJ4A4gByAN4A0MfAHcMDc3+1Zs1NwwZFjklSLJ8tVgZLCwHsDCBWSLSWgKdAuH2wln+xZlVyg0n5mg10VCtE6ZlbeWMpOgDAHBDeBPNjDLqhXB8WLDh2x1hN/BgQ/hFEHwJjx0J7BgC8ANDDNtk39fck/wCATdpaSZpyBLFgYWLvmE1fAuMIEPYo4LkJ4N8TqDM7NHzXY4/97M1K6lZ56uqWzbPi2SNBdASA+QB2LcyJYpFrAf4TA/fmrFjy8dUdL1daV5jzrxKCyGOdtX60pT8nOftAjJ+yzeem00k19oG/+ua2owi43zDjWzb4oP7e5Bq/9D7zM6tUZ4mpJwf75uzmHforWauGbZ02yYQgfIYykUjEXnmd2gD8AMBuBqP+KkBnpns7f2myOTY0JObAwukc9GxmAAAgAElEQVQg+jqA9xqUP8DAT3i45mv9/Xdt9EuvIwjk+DOI0TGF/szR5mc6M53qvNH9W13dCdvF4sOXMeEs10aoLwbIMPHp/T3JZwz6FTiJF0FQjlfBsr4F4vPLtHMAhBtrY/y17u7k30wbMEKudCWAAx0kXi57jhk/z8Ws84MQRRTzLyhBKHKaNWfDdQCfESY5qLLCJIj9Fi7dI2bb3yJAkZg6vJX7XgVw0e67cFcymVQHPfk0CAhBeEyLhobE3yFGdwE4NODMyRFw2eDA3Mv9Tij7tSZ2rsnS7QwcFLB8lfxptqgts7pTndK1n44gCLiWgX/N3xr0359zFh/w2Orkn50/Nza278cWOgB+f8C2qpPlRenerh+ZEGaQsnUEQeCTbaKlxDjcvCzut+O54/q7V7xSJg81NLd90Zdcy1f6msXWolSq44lySaOaf0EIwoscALqjNm5/MQix6vobFkE0LkzszzbdUbjFlYPW+XuOgdtnx/ncavsSpNKplFYIQjNa8w9MbF+7mZLazTsvjsFqgP7C4O0IaAawu6uYHIO/nOlNqpNmydfYuHhPtuIPANin5Eez8lU2381Gs4EOARgE8O5CnesYeJRAbwN2PUAfBtEN6Z7Oc52beUNLYgGYlH+jnVxtzQL8HIj6wTQI8HtBWOgQORWT50B8Sbon+cMwSUJHEACU1e0ujnaqNq4BrP8CcS1sfAaEvdyYE/DI4GxO+InvGlvaljBDbUJuct0E4I8APVkQOcbA9r4g+rCWiBmP1tbwIr8NKcr5Z0oQebHWnPVfZeDSsTelcMhBjUHDwqWfgs1njoyH/R6AjgQwqzA+G5lxPxG9U/j/AMfp6kx3xwtjDi/e45IDQR10Ump+EnhvBuod83+0GCY8MFzLx5uKb6fSBl9tW4UgXAi2trbGh7LzrmWwEqU4Pn7WZpz7vl3xqPNKmhcDvEFHgXGTS0z0msW5g1Ope//bWcqIPJfuAXCIq+qnmXBmpqerz72RKrEGMd1MIxPc+T1tx7OH6U6/Hhuoypsj0DWcsy91yo7VFR1Wbvjx7qR6U8l/HkSWJcYN2eHhb7ll+AqLl17D/hZZP3bdNgaYeWkmlTSVN5ed1z79y/eRgRt5uOYSlyiOGhYu/SRs+3YAHx1TCeHqdE/XBToSU9jEbVtZ+X7EkectIpw7+M7cTt1NUYkPKWadxmB1YyuSsso+BPCidG/yV7pORj3/DAmCGloSF4Lpuy4xWtfQbD4jio20EkO5EYKxFY7Ow0uOCB0xZC9yu+lwiOyucYt0CXTDrPjac7u7u9VbhXwFBIQgXFOhsTHRwBapSbed46dVyHF7Op38P6+Zoz1pE13nPpHXN7WdSYTrgi68/HV/m/VXgKFk68UHbMBjY/PaQBm4ZXhg7hfKPdDlN6rhnW5gwuccfVYb/WmZVLLL7zagxGfxLJYD1FrMy0DGHho+spqH4RKidXlzLfxe9sZSEN90Ft4RisV6PoI2NLedDeTHrPhttNg6MpXq6Cm3kxTEHz9zzidiXNGX6vqqLm/k86+8N9dxJweFQ1CCKLzfLQfRIuf8NBFp1rUu3t3Kxu4BqM6Z12Ze1J9KKmtu+YQgtHOAGlrarwXzOY6N7Y+IW4e4r7a63CWnM2CMTF+JDmZtxgNbNH0aK9k489f+bTbcwcztjvq9byqlG+hGsvnQvr5kutwKaGxs/yhb/GvH6azsxusss6Eh8QHESOV/X3HjJqIT+3o6O8rVbfK79w2Cbhoa2P6ccgSoaR+gIfTW1lNnD2bfThbEHyNN06TzarMi2sHsTncDSIyOOePOTKrrZA3JRjr/VP1lbhBU35I4hZjUm5FTlBbZzaGISVCC0BEpA5dleruUwkdZ7Tnt+DPfBxvLKtXKMpm3Uy2N3CAcI9bQkNgNceoG4wOji5lwcaan6/smA1tQrVSb4t7FTZGZjsqkOh/ML87mtgMJUBpORTmrr7hBV6dm4wZr2qjfQLk/hprDenvvfqtcfxqb277JwDcqIbJiHncZAK+sjW+b6O6+dXO5+sv97kEQ2kd2r7JK24en7eHYgU4X0/mTaoz+kUfemvYlYHub+bj+VLK3XBuLv5dsyh7vEFHPv3IEoXtnGS/5fFCCqG9uu4YA9V5W/ErGrtz4aG6GRqq05cqdTr8LQThGU7OBryObDujr63zaZNDVaXFzdqc7CFA3hDVg/j3HrI6itlFjU9vlTPjK1rLMN+xiHt2JVLfxatVAvU+uY7qnzRuAKEdPhU2JZovy4rpt1d8YeDmOXGtv773Pm+Dpl0ZLEAFO9qpszab0ts18aJDN36QfpgQR9fzzI4iJJAePsfD05trcfPwOOQw/6BQR+YntvMaouXnJ+7OIdRPydjIjn4eat8k4T8c0QhBOgmhpO58YTs2j31q8+ahU6n6lqVLV9/GDT9r2Xe8M/sypGcXAtZnervOCFtzQ1P4FEP/Yka9kMVWzyWsWTs55EzJt74isN77acaMaYuCITG/XKtMyvNLpCZCWZFKdK0zL1m00TLgg09N1lWkZJumMCSLC+Vdsp07ExIw7CVAq3Y7HXu6JoWaRyW3TBINyaYLcIBobE5+ERY8w8J5CuRXNK734UCLsOcdKCMKBRkNL261gnDJ6mDA8cZeb/Or3+a3L3jMrm/01QB+v9rRS5zqZAyi5GntsoCdmUp1qI/D9NOUrUdhKwPprubzO35l5GyIc7XygZSajNpSrR9O/wOIB3W1MWQf3pbpUwJqqPjXeNdlcAwHLACj1za2aTF4ipgjnnw9BPAfOK2S41ZiNH+KrAqqQOQhBaG5ar7NFB/jZBXm1seRWb6CGHEZ/p0oZQhBbR4rqm9puJ8KJxT+FtVmo8lS0rCzHldbL348SUIUxlDWLyYwgDOsLaMAUaK7r3ksCFVBIrCGIP9vx7EIDg7cx1bkPBQgQo1mdQIeGNs6zrfjHLdAeTLwAjAVA3tbCyxhRydp0thCRzj9PgvAFn7uHZuOYKNRa3dUGJAi3i46KgwuZ3u4qmaPTIY8QhPeGo338rXTQIyYIJd8/OtPbpQza8l85X0V+/ZiiBFHRJlHf0vYVYlw+ikcZgii4dDiPAKVJ5jaQNJseGoKoRiRoVulIKo2mnTO7MkqrHaNGzXxJOpX8nolmUJB2TFqCACqaR9X0fTLnFYKYHgRR8rgqBGG27EpEDB4EEdQXlaN29X6ltMaK6r7aG8TEEwT352CdHGP7+y7bgnWwrEPTqzt+Z4ZoZakmzQ0CwRVHKuvx1MglBDFKEKX66iJiGp3Ek+5UNZ4iJg/DqtIVPuImRbmCyAD0W4splUp1vF7f0nYR5b3nFj7tDSLa+VesWn+D2OqPSrNRA+NgHzBpCELeIMbMayEIBxxT5ZHa/UhHwF9h80F9fUnlDyj/VXWDaGo/jIiVuCpvsa0rf6LPPxE+Uo+xclbGiTVz1t9IwGmuPq8HoYNtur/GGn5y551j67y8gprKuaOcfz4EscaOZ49xvN1QfXPbt2nEB1PxU95oz8mkupyac6FOgYAE4bYnqviR2m1Pofxy/W2b2mOfeviOt0Pt4BQtTAjCMXAl8mggsJprXn5PuAXMb4DoCeXYrza+7nZgr7jbIrfSG0q9Sx2SgT/ycGyh08CrGoLQqBHmmHlxmL6Uql0vmv4FVsXVaZa5taw8XF/8Cjk+wc/1irN/pgQR5fwr+hgy8cXU2HjsTrZV8zABn3D04yXk+IB0OvlctWOnyx+IIBa2f4TsvJV/0TFj4LFXbdCpnle6JqPAZDKUKQThJAjXyVl5Bw2qPldqDIdkbXzd8WqBTrihnKEWk1YlN6ARmoJVWX3bFj+w5TSqHKA9ScD/EvP1qVTypWonv9bdt4+PI119ms2/RBtMM55BN8oS7SQPLSbURzz/FAYmBJFP15Q4moiUW5RRbSxTP16VjG0QghBDuUoQriyPEIQDN42rDPXrOenerutN4NX5WnJaZupcbTDTsiDGXToZsamrDbemk0+fSnwCAQi+MZaKKgITrlcbPVyJ9A3NxuGGapmaPvKY/KZW635zIx95rianDAO3eo/1kHNHPf+CEISHaG2ImU/OpJLK0WGoXxCCyPej1NXGH7KWdUiQgEya95jAtjShgjAJCxOCcAzKyIYw7zaAjy/+WYlvjJ31NbUvJuLlDl9LY1x1ROSsT+sOpBoRk+p7XVPiIIvovrH6/GaO8FR+vStmXlEb3/aECH0xGcvK65uX1hFs5SNrB8cUGHMY0FnaBpRR6+T5XnYQiHr+BSGI/BiWOlxUf/Z0MV/N/haUICJx1gd+EDksEWd9W0dSCMI1q3UTzySgTGExqQ11NAiQkmfOqll3ltPHvM7dt4lDNC93315+7KslCA93ykbR8jzcaQ+E6U7ZJx6EUss8Nr26Q8XV0H66sQKgPYE2NrX9xOXy/C2GdVimt6Pfb0MciROCC8B0hSYEpufbVuTzr7y77zHd0s3XKGInuAminN8uj/mZZfDFmd6kcpXi6dHVy9132DFLqiHMyZJXCKJ0JKihpe1KMP557E/8hE3x0/t7lv/eOflGgpCosKF0syvkYcCAQfwsWTi7b3XyN+7J3dSU+FCO6AYCPutq7jNkZw/v61vxorsb1RKE9y1A/cIrLcaFqVTyf1z1UuPCxGfZxvX5CHVjPvPbh8niKBMwaBOYzx/avMPtTrffPmPlKTppbGlfysx3uqKqPU+W/XndWKk6Xn6D6sH4oSbAU7FrfmrDkc4/0zeIYkMLt96fO2N7AAiV7PM3G83DM5gv3X1X/MBLO8wrYJBX/O/82LxmLSLify8NTxru/DSZw1MhjRCEZpR8Qz4CrzDQS6CNPmE2B4hwUl9P1726SRBSyNF1ID4q3ZN8TFdHGAShyvUJtal+HsWiEH51f41PH6Unm44ju8Qd4auaBaLpnwpCr2J0H+goVxmprXKEh9W1T4WmvGronblf0cWQWLDg2B2tWTUrPTb7tQD6VPkjddofBehjJWEtCcrfkfJ1VAxC5esWJMr5F5QgVK+ampa22GSvHONTK+QAUFrFCFV53raENjA4G2Prc+4gTT7z0zjkqImEoJq5OpXzCkF4jN7IyYlUGNG2gAM8wMRfzPQkbzO45t4NUEvA8lWxz8KKHe9n3RoWQYyQROII5nxQeKe83rDZW42wDDMYJdP0709k0zK27H93RQrzKy9LwLcGB+Z+zy/AUFPT0k/bZCvx4a5GjduaKAumq7iGfoSs/RABHyz8tJ5sOrivr/Nxr/Kimn+VEITapnW36iABegxw87g5bc3p5eixoP2l1tt7DepxJsltEQmrYEhnGSo2BCx+6icXgvAZQ78YtrpsKqwmE5/e35N8xmRqjMhR6WwQVPjJuQZ5NhHw/Vlxvtov6L0qJ0yCUOUpH0Q1zD9g5iUambqu6ZtA/B1kcV0Uj346gohTtiWbjQ1S3PoRMx/nCuvqaqO3SE/XmQXN7R+0wLf5iI3cG88qm/gCNRd0j90mTgujmH8VEgQKrtvVo74zlrfRe4zBvM4n0YWqdeb1i/kQfH7ys0S4sK8n+UDUfqZM+z8Z0wlBGIxKQeXvUAJOUgdqADsXNp8cGC8TqNu2+Kd77MwZL3mpXzX5zS5rHQawCks5tnzgjYIYI1kbtx8sRwzFesImiGK5Sm0zVpNrZ6iwp6Q8084r/KZOY28A/BRg3RKkrQZDUJLEiyAKYiyqb166gGCrWBtKrDTSxry4gh9j0A3DA3N/VS4sqbvS4vuCZdPnmFjd/PYcJcuRsv+HgXtzVizpVrd0Ry8LEqM7zPlXKUEoLOqbEu1EdLtDS0/9+aHaOB9nOi/LjbU6NFHMOo3Z/hwo/47l9Io7alPkVc6IM8VcgoAlIPoQGDsW0g4Ayg0KPcyg5XvsknuikrVarv3T7XchiOk2otIfQUAQEARCQkAIIiQgpRhBQBAQBKYbAkIQ021EpT+CgCAgCISEgBBESEBKMYKAICAITDcEhCCm24hKfwQBQUAQCAkBIYiQgJRiBAFBQBCYbggIQUy3EZX+CAKCgCAQEgJCECEBKcUIAoKAIDDdEBCCmG4jKv0RBAQBQSAkBIQgQgJSihEEBAFBYLohIAQx3UZU+iMICAKCQEgICEGEBKQUIwgIAoLAdENACGK6jaj0RxAQBASBkBAQgggJSClGEBAEBIHphoAQxHQbUemPICAICAIhISAEERKQUowgIAgIAtMNASGI6Tai0h9BQBAQBEJCQAgiJCClGEFAEBAEphsCQhDTbUSlP4KAICAIhISAEERIQEoxgoAgIAhMNwSEIKbbiEp/BAFBQBAICQEhiJCAlGIEAUFAEJhuCAhBTLcRlf4IAoKAIBASAkIQIQEpxQgCgoAgMN0QEIKYbiMq/REEBAFBICQEhCBCAnIyFNPY3PZNBr4xti10d2187Snd3d3ZqNu4YMGxO8Zraw5jxtEAPg1gZwBzCvWq+l8DsAbMv7Sz8ZX9/cvXBm1TS8viXbIc7wHw90HzFtLnALwB8HqAehn45ew4/6a7O/k30/LqmhPzLdAjAHYo5mHg6Exv1y9MywgrXSKRiL30Oj4ZY1rMhEMA7A5g3mj5hDfBeIFAvyVGcvPm7desWXPTcLX1z59/Rk3NnPWHEvgsgPZ11DkA4AWAHrbJvqm/J/kHAFxtfZJ/YhAQgpgY3EOvta5u2TyrJrcKwEddha8jmw7o6+t8OvRKAagN6tW1+Ixt0+UE7AcgZliP2qhX2cQX9PcknzHMgxAIQlfVAAM/4eGar/X337WxXFsmA0EoMrZm1VxEwBcAzC3XZsfvfwHzt2Hj5nQ6qTbzoB/VNyXaiOjfAby3XGYGMkx8epAxLlem/D5+CAhBjB/WkdbU0Jw4FKD7AMxyV0TAt/p6u74ZdgPqWhL7ENPNBNRXUXYWTFfBtr9hsmFFRBCF5tPzsOi49OqO3/n1ZyIJoqEhMQdxnAOmrwF4d+W487NkWyf39XU+blqGujXM2mb9FWCcH+AgoIpXRHRRurfrR3KbMEV7cqQTgpgc41BVK1pbW+OD2Xm3AXx8oSAlQrAci/hpezh2YCUiHY+GUUNz+0kAX1dmk1oL0NsjZfC2Y0QfpQX/Cjk+IZ1O/p8fGNESRL7mZ8jOHt7Xt+JFr3ZMFEHs15rYuSZLtzNwkA9GajN+A6At0kZW69sp5nNn2wTQ6eneznsMNm5qaEp8E0Rf1ZDDKwz0EmgjwO8FYSEYO7oqy4H4knRP8ocGdVW1HiRzeAgIQYSH5YSV1Ny85P1ZxLoJ2KOwGf965F86oNCoHBGd2NfT2RFCI6mhJXEhmL6r2SjWg3ArE920xzz7j8lkUomRRr/W1lNnDw9v3s8mW+VVt44x4igCHhmczYk1q5IbvNqpJQjCbemerlMN+0bzW5ftOMvmD8K2L9ryJnJUSTuIOgff2f4kL1n9RBBEY+PiPdmKPwBgH/fGy8DjBLpyaLb9sAY7ampauguT/Y8MfEkjjhogwkl9PV33+uFX35Q4mojU/Cm+Kan59TxZ9uf7Vid/49z0ldjx5desRUSsxFC7OspdB8s6tNwNzXAcJdk4ICAEMQ4gR11FQ3Pb2QDUaX6EFhhX2BY2EON7W+sO57G6saVtCTPuGLtRIMfAjTxcc4mJDF81sb4pcRQR3ep86B1pPK5O93Rd4HXKDIEgnMNRlKff4urPgM28qD+VVA/RJd94E8T8AxPb126mZOnNQb9Be823hobE3yFGNwI4zpXmNYtzB6dS9/63Lq+qf9ZmPLDl4bnR8XvZm1ZDS2IBmNTD/U6j+YiuS/d0niu3iKh3hXDKF4IIB8cJKyUvk47hXoAOKzQix8xKo+VVl6ZN1Y/VDQuXfgq2/asxCx4YYOIvZnqStwVd9NoNBNhosXVkKtWhNJVKvpAJIk9JuhsRA7dkertO1/VpPAlCiQ+HsvOu5by2kPPj7mwcyx7vTr4RZPLl3xHmbLgO4DPGMKXPrUnzvuVLoM5y3YcXEJ5DllvT6eSrQdotaScGASGIicE9tFobGxMNbJHatLdThTLwchy51njcWjc4TPeBsH+xsmoeq/NEZGE5iBY5Gp8j0Ll9vZ03BCWHYhmNLW0nMkPdJLaKm5jvg41lukfrCAgCeg0wfmooHj9gTffyv7oHazwJoq4pcZBFeeUDh2gHa+x49pj+7hWvVDKRChpQK13KBV6bPtU3tylFhNO21sUPIoclJkoF9QvbP0I2K5HnLoX8b9vMh/ankr2VtF3yjC8CQhDji3fotTU2tV3OhK84Fu/K2vi2ie7uWzfXt7R9eayYCRU/Vuu0pNQpe3hg7heq0atvbU28y01kADaSzYf29SXTbsCiIAhVR31z2zUEKNFH8XvLBh/U35tcM1EEobkdqqa8xbAOy/R29Fczmeqb2hcT8fKxWm+lYsjm5uN3yGH4QYDqRutjOjOd6lSiqrKfbrwmymakbGMlQQkCQhBTeFJoT76OxdvY2P5RtvKnt6IMuKLHao2WlEKtapHV1ltE+1JmvtN5i/C67URGEKVk6nnSHa8bhPt2mMcrJBm+x7vCn3MWH/DY6uSfi2Mzotq6cSHs3EIiamDQ39tsn2J6AyhVoECOmY7KpDofnMJLb8Y0XQhiCg91QbNkhWNjHbNp60+gPHrDMO26RkygsiZr4+uOD8NCe4TosvcpNUlmupcYq3bbzX7BrQWlKh1HglDiOq119HgRhOZWE6p4prG5/YtMfD6YfsnglbPjnAliUW4yfzQ3z9fZogMyqzuVhbV8kxwBIYhJPkBezdOf6ks3/4am9i+A+MeOcgKf/Oub2k8gyp/wt0oZmE7MpDrvGm/4xpEgJlTEpBXtgPtjqDmst/fut8Yb90rqK9xSfg5Qq2PieL4vVVKH5IkWASGIaPGNrHTdqZ41m7bmio+gj9WNTW0/YcLnip0h4K+w+aC+vuSTkXXQo+CICKLkIbb42N/be+/z7qaMxw2isTHxSVj0CAPvGcWd8dO+VNfnxxvzSurbb+HSPWps+2aXaq6vhlol9UieaBEQgogW38hKL1EfBErkx6pyj/cD48dq/SOyt4ZPZB0uFBwFQSxYmNg7ZpN6q9l760kXj9bW8CKdyGU8CKK+ue0oAu4fg2eAx+Gox0FXfn6u2LGPw7aVfyhl1R93pMsy+OJMb/KqSjXeJqJPM71OIYgpOAN0m7af3n5jS8kjsPFjtd61RfB3jLBgjoAgqKGl7Uow/tnZRr9b1rgQROmj+dAWi+kjMr1dyiHjpPlGDiA73a38Nvo06i/M/E+ZVLJLyGHSDJ1RQ4QgjGCaXIk02i1DAC9K9yaVPUTJ19CQ2A1x6gbjA1t/NNNlj2BDrgrMMNtTsO34F41/IV/L4gkiCM83kaoArTKzh5qyo1T+X7Jxym674TGd0kGV1Uv2iBEQgogY4CiK12i3lBMZUUNL+7VgPsfRHqPHat1mSBMoC6+WINSGNjRk7QWLj2HgTAC7lYwR8yXpVFK5KdHGMRgPgmhoabsVjFOKbZvIdx+/ORzAeeLTZPF5br9NUawPKTM8BIQgwsNyXErS2T4wcG2mt+s8vwbUN7cduCVewy+dhlEmj9XazZBwcaan6/vj0mFXJQE2pIqaZ+IwcCIIAsCf4pRt6elZ8XpFHYsoU0FZ4l4CXmGQsp+IbVGZ/TQB/+B6g1AtkHeIiMYhqmKFIKJCNqJyNe8JRrrxerXJ8pbVWhuIYN5TQ0UiYoIwcjk+HgQRxLI7VIBDKiwfXbCm5htMUD6knI/VRt5jQ2qGFFMlAkIQVQI4ntk9bB/6hmbjcD8X2cU2akKSln2srlakEzY+ERGEchx30e67cJeJnHxcCKL0kXpSvkGUGV8vb7l/yFrWIY+v7ng57Pkh5YWLgBBEuHhGWpruNG8iJholCJdjv5G/+z9W624eSgzzt21qj33q4TsKwYAi7faYwkMgiHxAHQKeY+JHmKyVutgVfj0aF4IoNU6cqi4qVKChi0H5+CFbv0musjt+M3py1yQEMbnHZ0zrNLYPYbTe0zGeKlyvxji97CCCgjgeBFHXlGi2KO+lV0XiK3C5uZO8oH2KMr1HvPTQXLVE2faZXrYQxBSZAR7O1UJpfblbiNtj7ERq1EwGkdd4EITWAn4CtceqnGg6l+FTym1Ilf2fstmFIKbI0Gk9e4bXdl81WZ0GlM6tRzXNaWhuWwbwV4npPrb4vtrYtk8pl+XuMmcKQajwrIPZt5MAHemQy4S6qSrxYRZZpYH0VyLcT7b1aCrVobSktOq91YyvxvX8pNTKqqaP0zGvEMTUGFWdHUMWwGsAqX+DfcTbu4LK+z5W6w3twvPmqnt897qlzBSCUAOq2VSNNNZMJ4Pu0BGVjYsQhOmoTK50QhCTazy0rfGIeGYc1ctdqC74T5nHah1BhaZVo4lboQ6xWu2smUQQOlzUBj6rZt1ZIbhZ141pyUFBOQ20LTrNAj7CwIfAeM7C5mNSqfs3BVk69S1tXyHG5Y7bkGfEviDlStpoERCCiBbfUErX2D6gGhHP/NZl75mVzf4aoI87Guj7WK09bfrEMQ7Qca0vJADnpHu7rp+pIibVbw9Hi6F4RG1qWvIPNsUeBrCrA+MSUWMh8ty9jjRGFvjOcfMQlwWOSxJgTknSkBAQgggJyKiK8XCGpvXcGqQNGpsIEOOKvlTXV3XlqMhitdtsuIOZ2x2/54hwal9P15hYEYHa0dK2hBl3uGIue+rJz6QbhMKxqWlpi032ymLMcfU3BjL20PCRjz32szeDYF1MqxQeajdT0uWKG6yxkK9WtVrVOdms8SvBbKbmEYKY5COvEzP4eW417Y5erONvWd2wcOmnYNtK9bIYwlRVN8DMp1XiqbOhJbEATL9wlZdjxjmZVJczyNFot2YaQagDwlB23rUMVhbJzm8VctyeTif/z3TMVbp8CNE5G64D+AxnPgb+y7KHD+7r+9k659894gOxpu4AAASJSURBVGK/hBwfkE4nnytXtwcZBb6FlKtHfo8GASGIaHANrVSN7YOv51bTij1uJuUsq6mhJXEhOG/0FHPUlSXGDblszaX9/XdtLNeGRCIRe+V1Uo7orgbwblf6h2rjfJxX6MuZRhAKm8bGxXuyFX8AwD5jseJnycLZpg7wPIL4FEl+aSaVHBt/olBZQcy03OXH65HB2Zzws+BX5EIWXesMNpUvknB1uqfrgii0pcrNPfk9GAJCEMHwGtfUetuH8IzUdG8b5SyrvU6gBWDWg3ArE92ks05Wbx81ueyRxLgYoA9rwHyG7OzhfX0rXvQCeiYShMLC47alfsptiRPxOIGuHJptP+zesNV4zZmzYZ9cPvY02lyivHx+EF+S7kn+0GvD9hAvquRP2BQ/vb9n+e9deamuZdnHiHM3ElDvuqlUJR4b1wUolanok/JNVgR01rTljNqC9MXDwtX3sTq/WTUk5iBOKsiOCn/pvEk4q3ep4fJ7NbeF0fRKxEE5Pq6c2GKmEsTITSLRwBbd43pYHjvkhDfBtGHkj1wLYGffMSL+yu4748pyPqjULca24vcR8AnNHHuFgV4CbWTwdgQ0A9hddwBAjheVG+Mgc1jSRouAEES0+FZTuk4NsezmHbRCt5V0Pj/RdemeznP9RABlxERBmpED4U57qOZcE/HUTCYIBaqPmCgI5irtazbzqf2ppIpQZ2QYV9e6eHcrG7sHoLqglQHcz/HY0kx3xwvB80qOiUJACGKikC9TbzVR4IJ0ycNCu1wAotEqlFtna1bNRQSoOMRzA9SdA5BhWF/K9HY8ZrpJzXSCUPgqcn51LT5j23T5lhgf+/ncEHTDsZ6Af8sN11xrQsjuAkZujzgHTF/zuxE68q2Hsn+w+fp0OqkcJco3hRAQgpikg6V/H9DbBlTTBQ8tlXKP1SVVKjn17Nkb5jMhweDPFEQbTvFGQeSENWD+pZ2Nr+zvX742aNuFIMYilhcTxrNHgugIgD4BuER5eZETXiDQb4mR3Lx5+zVr1tw0HBR3d/p8qNGsdRhgnwbQvgDmFdIo4n8DQB9Aydq4/aCXwkG1bZD80SMgBBE9xlKDICAICAJTEgEhiCk5bNJoQUAQEASiR0AIInqMpQZBQBAQBKYkAkIQU3LYpNGCgCAgCESPgBBE9BhLDYKAICAITEkEhCCm5LBJowUBQUAQiB4BIYjoMZYaBAFBQBCYkggIQUzJYZNGCwKCgCAQPQJCENFjLDUIAoKAIDAlERCCmJLDJo0WBAQBQSB6BIQgosdYahAEBAFBYEoiIAQxJYdNGi0ICAKCQPQICEFEj7HUIAgIAoLAlERACGJKDps0WhAQBASB6BEQgogeY6lBEBAEBIEpiYAQxJQcNmm0ICAICALRIyAEET3GUoMgIAgIAlMSASGIKTls0mhBQBAQBKJHQAgieoylBkFAEBAEpiQCQhBTctik0YKAICAIRI+AEET0GEsNgoAgIAhMSQSEIKbksEmjBQFBQBCIHgEhiOgxlhoEAUFAEJiSCAhBTMlhk0YLAoKAIBA9Av8fOT8cXA9P5EoAAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="jeVlbFHk8Qahp5zcIn_D-55"><g><path d="M 511.61 171 L 550.39 171 C 567.29 171 581 184.43 581 201 C 581 217.57 567.29 231 550.39 231 L 511.61 231 C 494.71 231 481 217.57 481 201 C 481 184.43 494.71 171 511.61 171 Z" fill="#f27979" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 201px; margin-left: 482px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">MP1 puts system back to sleep</div></div></div></foreignObject><image x="482" y="187" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXtgXEX1/+fc3U1SUChflAIWER+o+OJLgbxrFKgtAi0tm7RApfxQHlKpIogiX/EBAiKi/VaQNwWFJmuhIMqjiLFJNptC+QLW6hcRVJ4t8i1QaJpk954fc7Ob3L079965d3dDkp37V5uduffM58zMZ+bMOWcI+tEIaAQ0AhoBjYAEAdKoaAQ0AhoBjYBGQIaAJgjdLzQCGgGNgEZAioAmCN0xNAIaAY2ARkAThO4DGgGNgEZAI6COgN5BqGOlS2oENAIagYpCQBNERalbN1YjoBHQCKgjoAlCHStdUiOgEdAIVBQCmiAqSt26sRoBjYBGQB2Bogiirrn1G8S4TPY5Yvww2dPxbXVR3EvOaFn0rqp0+vcAfdJZioFjUt0dv5HVrmtqPZqAu4uQoR/ASwC/CMaDJuHu9+6FxxKJRKaId0qr1tfHP4gI/R7Ae8F4qDrGczs7E2+U+jv6fRoBjYBGQBWBshEEwH0RxOZ0d9+2VVUYt3J1Ta2HE/BbAFVjTBAykZ4HcO70vbijVEQxY8apsdiUV68h4GTrg5ogiu0yVv36+vgUGDgFhMHe7sS1JXmpfsm4ROCQmQv3ibJ5NmV4ZTKZeGxcCjkBhSojQeBNk3l2X0+iu1hc6ppaf0bAWbL3lHkH4SV6x2ANn7rhwcRrRbaP6pvj54DpEgARTRBFogkgHo9Hnn/JOIrZvBSgjzDhvFRXx4+Kf7N+w3hDoLb2hF2MqsGvgukcAGkTfERfd2LDeJNzospTToJAKcxMXual4cV2WU1MPnqlawf7d126YcO1Q2E7QENz6wJm3Apgysg79A4iLJzDO4fm1qvBOD33Ek0QRcE5bis3NBy7BxuxPwA4ICvkVk0QpVVXWQkC4ORgDY4sZpXtZV4KQxBehOKEVph+qqq27kFRo5nZvFCsRh1lMkRYkuzq+GUYtTQ0xz/PTIIcdsurrwkiDJwjdeqbW28G4yRNEEXBOO4rNzfP3yvN0S4AH9AEUR51lZogBgEMAHhnVtzXyeTZyWSiN6T4VN/cthzMS7P1xUrdGDHFhNhBBCEIu8zCnk0GLWfCF+1/Z+BxwxyalUzeuSVAG6muOX4SMV2Vt3MYmdH0IXUALAuKaoIoBr2JU1cTRPl1VWqC+DvAjwM0Pyc6Ad9Ldnd8N0xTamsXTTNimQcBfDxbX/xbrBb2G51Lg5mYwhKE+N6Mw+O7Vu+gBANH2NqTYeb5qZ6EkreURTQR4yIGL7MTnd5BhOkh8jqaIEqH5Xh+kyaI8munDARB3wf4ulGPo/Bmpvqm+GyA7sq+K0Ogsxh8tm1LGfgMohiCEOpwyGRpiIHlqe4OMeF7Pg0NbYewYd4iMVWJndeoh5Y2MflB6fm7Joii4JswlTVBlF9VJScIkyLzDU7faotZCGtmcpqXNsIwvgDTTLydBCE9NPeZ0IULXoz5cmZeACDqUOt9TNxOTDeN/F0TRFE9XxNEUfBNmMqaIMqvqpITRJTSzUMc/abdLTWMmanAvES0AmnzUkToj28nQbS0xN8xMER3gfDZUfW4x3zIy1s10wKXgf6pl8WmvDo7L6BvDAhCItffhe66uu54UQjX2Bj/sGnQV2FiNgj7ZM1h/WD+KxN+aQ6mV65ff+crKl20tik+wwCttR3GB/I28avvgbFcPMLK3q6OJW6yi74XiWXaGNwGog+DsXu2bBrACwD6AEpUR817xyqY0TJvDtDRYHyBAREwOi0rkwjafImATczcnhlKr/HSy6Ez4/tFTCsgc9RMG8IN2IoxiWA1QHNyODLTiame9l/JcC2V/JK+4NkFVSwGwi362RcjBxOZS8CW+Xhf20JuMwFPgHBLVYTXqOrbb3wJchvi2JkEcwFAH8x+Lw3wUwxjdcagax5et+pZSeOotjn+UQP0FcfY3AbgSSZeURPBr1Xl9Bu/5SKIj+UFtoWY8BymnEGA50Yp87jDa2HMTUwuk1He5GoHXVaegRQTn9LXldgkyhZEfIfAy0/Rzt/dOnA6HXkVhvE9EH9NstuxvybNwFU1Uf62X2f0m+D9ZPerXyqCOKQlvmcsY/zUZacnE3MbiH+ANFb09iZE1H3JH6ttGfoBGKdJHRoKv5gmxtWZdOyCvr5fvS6bYOqaWm8YCcoUBUL0N4lOnskYfNj6dYlnCvp/CeUvMUFQw8z4Z9jEzyVm36L0XYrxlVtA5tzo6+vj/0FR4ypmPs71/HJY6hfI4MXJdYmHiu2QZSGI7ZHqIUdqjEArRgAF5iVzKHJ4VdWAMS4JwmOAOTrKywCWOaOwxwtBRJCZZXLkW05PLe9Oxn1mNHNcX+cdz7muyCfADiKb6kScd+V86gOMLe5MR7Ho4c7ESwEq+RYVEwIi1A7gcN/CjgIMPAmD5qXWtf/FWVdyjhZ0fMKZZoeBm1LdHacMH8kNP+WQv1QEoeQs4gq6f5+XEQQymaM4GrmCGEcq6jMD4m/1diV+3NAw/72mEb2LgE8p1t3GwPxUd4dw7An9lIUghJnCGf0cJFhJZl7q7Wo/q7l5/p5vN0HU18ffgyh1giG2hbknUR3dcnxnZ6cwQeQ9oqPsSNN1xNwDEzfIVprjhCCeYeBeAr5sa4DY8m4AjMdBXA0Tnwbhfc42ErB2oIbjbvEufjsAv97rV7+lZUnNwND2pSD60PC7zM8AuX9bf1gP0Gj6BTbX9/Ykbsh918U7Tfy8DeA/AcZG8R8G70JAE4DpTpnFBDnUP/W0YoIm7e+0YnCmvLYC4FMd37LMfCDjUQBiAqkWFkGwZTIajsQfebhzsAbznHqReAciiBlY4FW1A78DqCH7KWuH39uduG8E0zLJX9ey8H2U5q+K3RQz70SEYwDsYpPjHsD49wgEBv2id92q/1HEFiC8QoxHGSR2QhEGH0zAxyS76U1kpo9MJu/4p6z/SgjieYCfsJvkhvsXHgToZYDfDcJMmzkz99qtICNObJ6X5z3J+AcM/BFMA4D5KYBmFMoY3kEo9/FyEkR+/qQA21iZeUl0Psmh1JibmBqa2xYyswiMGxmMQchP1pnGCUHYRcswY00mYnzNYQel+pkLD4QpPLFGXI+tegS6uiq6+SwZSfpN8MUShLN+0EPq+sb4KSC6xqbTfiIsG9g+9WbJhO+GQVhnDGnz65oWthDM39nMShkGLqmJ8mUyk544W4iadI3TBZuITkx2ta9yfqQwfY36ZNLQEK9ngwQZ5CbmjWKH39d3++bcd8otv/hOyEPqwtQ2ltD8V5Nx1nv3xkPOHGuHHnrs7kZV7PsEy8xnJ+H7q6N8nEwfPmbPrUQ4a2D71HZ7/8rmDvsmiESSU/t3bF6O/IhJOClnns7hbeWiMjPCQ7LFpusC4vYba87fy0YQEm8f1W2sw7zETwxGo4dt6Lz93283QYjQftOIPeDY5hU9MYwzgsgQcNFA/9SL3VbDLqYDVxzGM0FYu4/0mwmAjrINjqW93R0/9xpMYiWLtHk/Afvnyqm6O6sM0oIJnGiF2EXbTTjO92RX9mvyJwm+pzq6c7yz8+Yd9vKSSV65Hzc0tX6XgQtHVpmSzM3llj8sQbiYqB5Ehtt6exP/56EbWXCrayYFD4LYAuKje7sS62Xfkh3+21bznjv1cvTJshGEaFQYM5Nz+2sfdG8nQbgwNMB8F0wsKuaQcjwRhKqpRNYZ4TKJjWeCEP2NYpl1toledSGD+qbWMwGsGB3opclg/MlZi3d+x/aBO+27ARVvHCGH83yBgWejyLR0d69+2j4hScxESmampqbjd8tg6F6AarPvKyCWsZA/JEE4zzbFazxNRY5JnOqaWsVO4gKbzqXphDwIwn/x0dh2ApFlpbA/LxicmdXTs/rPnguXgsSm8gWCyiJFlCk3QTjSdPO9yGCB12Ra1xg/hojuyG6xBhn4fO6gZYwJgma0LNo9ls4cSIQTwWiVeJFsZRhzUt2r+lQBl5UbRwSxhUw6LJlst2zufk/BfSCEp5Dmlt7ehEiJPvKMZ4KQ9CnlLMTDgY8sJvI3ATxqAI9xhpcXs1gQoEk93zxcSPOwbpk/3UhH1gIkziYeY9CmGJk/6+pKCAeJvKfwPhd/M1NhbrTCOmMlf1ATk8TFN3AuNck78uaoHMAuBCH19HLqRbbLkTkByMZnfWPbaSD+xchvAUz7sveVlSAkZia/CUgwtM0Fb9S8JIQvBUH4TXoBfh/xMPDa9qu8b/wQBN1WHd18kuwcQUpsM9s+SiYLn/q9sr9LB8t4JojGxmPeaVKNuHDq06NtLI9XkkpfyJahusbWW6yFSfbx8koK8N68og0NbR9nw9LfHtkffMlRknpftiIeE/mDEoRj8SmWx9IFjReeLS0t0YH0HreJrPK5crKs1S7xUlJzn/N7TU0L3p9GpJNgxR9Zj1eMib1+qeeSshKEEFyxQ1ltdHoIOW2644gg0iA+f/qe+EkpLg0qtVJVJoxiVnm598smVyacnerquNIuw3gmCCGn06aelf1VEFYZJq3csWPXDaXyTlLRjSWTxBkCQD8DdxF4ZXV0507nuYLqu3PlZOcvXin6Jd5Prgu+sZA/KEE0NLZezITzRyZ2YO0bO1Uf+8QDt4odoPJT19x6PjEuHq1QaMaRjS/V6w8k7ZIuvGQCl3ouGQuCUDYzORi+YDUzDghCRK2mTOJTnV4Eyr1LUrDUSlWRRdKBXyWTZiWT7Q+r1M+VcXoMQRKlPN4JIu+6V3nj+0F4DCat5Bjdn+pcJVwbR/z9g+ClWjbrOXMPAXUudUSg4p+J0c4RWrPPNPPJMIuVugJ7t/s5SmH8hLt9eyzkD0IQspU/wH8DDHGfRMCHDwRwqI0gCm7PlC7AFCPWg7TLKXip55KyE0QAM5PTvFQA+pgTBOEVZrwCxnrDwP2ZwchauytfwF7lWrzUSlWRS9KBnzGj6ZleAW+y9zpXZQAKYkLGO0GIdtU1ts0n4pttqeq9YNwCwh3Mxs377JV5JMzErKKjxsaFB5tkiuC9vRXKC5/6e8ikmwcGdv2D6o5HYlN3MzMVHPD6mT3KLX+QiTRwtL0C4LYiBZkUitmhB2nXhCcIa/A5T9aZTu/taRd+5yOP07wk246VgiBUvUGC9Y/iSo8TgnBNF+LVuoKDTsmh2EQgCNHG2ub4AcQkzsDcVu0yKF4l4IrMUGy5S2qLojqH8J6LZMwriTDPJ72C/Tsi7ceNUUpfnMut5SbE8Mp62kqAj8+VkbnrSgJElQ5cyyl/kIl0XBCEx+2Xdv0EaddkIQinmangsMbPvCSA0ARR1FyTV9kvmZjqlyYTQWTbbCVDI6ZzCBA5b3KXX/lBspENapWltvCrqPK7NdGa5jICFtsOlf2qKuXkkZiORmKPch9wHvCqetXk6pdD/iATqSaIxBt+nUX2e9lNTOKjEjPTi2zQYbbB5Gte0gQRRr3udUpGEM7d4QQ8g3BDycryudnYnzI8jwltLikX7NU3mtH0nKBmuoCapbqWhfvSEH8OBp8EhrCHj95nXviyLTCM2c50E/ZiksPnvENRyS6jmAjdkslfLEEUmwHBS28uSTqPSXV3CI85zydIuybFDkI0wsvMVGBecrmFTu8g/LqW+u/ODkzAv2HyEclkYjRnkf/rZO6MBZcnTRQTk19zLa8fc8dBYHMxGOLWxJx7qL2qbyCU33eC/C5yNtXUvLJ/hiKLidEmy5XlFsBo/45X5LPknKIgtUYQme1li5E/yEQqC94jxvXJno4vhZVdE4QPcoWBNnC1Y0sCbEbMTI7tq2vIvyaI0nVlyQpH2ZUuJ4UkqhaQnC/VFcZLKEcrW4uLxrY5RCxWXrn8NJ71g+ZiCoOq2F089wKWgOi/7St4kbgwjOtkGBkkdai+uXUWGCJX1gh5iRgKHorM9HKwqG2MNxlk5Vfaefi9ozFITpdVVXfNEG0KJH8QghCyNDS2XpeXqbjIIDJNECUkCKeZyZYC4BlHcJw0dF2IogkixJBzqSL10w54f7jqzkCit0AutXXNrV8jxk9sTSkZQdQ1LawlzhxJRPUMHJC1rf+XItLCNHoJAefZyoc67M9bzQtCZfMoMNULCy0DyZrolsXKAYzN8SV5NxQCvoQsy9CazWLwe8f9Eb45m6wFwRjIH5QgCqKMAb/AXVk3yHlziUC550SWYGZzbU3s5dV2/WgTk1jZNbd+gxiXqQ6OgtxMTCeSaXba02d7pR3WBKE4bSkUc4n0dCVn2SsLA8zkqRqkemNakOppFylVPB+XZHqlIwhnHw64qizwQIP7Ltqvrbnfi434VSVupzzO8Sx2CmzyVfnp7RXSceSnywkcsawqf1CCkESOi2CWi1LdHd9RjWuRxczIvL40QYQjCIc3ExJEaGeGuBRFmA88VyeaIFSnGP9yLl4dIs330lRPx2guF5dXNTYu+JhJkQccPvpS+7vUFKWQnVR8urFxYbNJ5j221NLizyUjiELTCl432Diqp2dVlz+K0kXSHw3ecXRPz90iLiHUI0m1EChnUAHBAEoxLgUTKOMhEK9467Y1kS68KtsY3zOWsZI/KEFk02nfDqK5NsV4Zle1K1Ac1g+mpy1n8Bm2v/czjCNT3as688sWXk2s6mIftF15u8+m1qNLeX3xmHgx5Rog8Wb6Oxj/HL3f2Xt1ogki1HwjreSVjpiBE7xuoqodTgj3a1tGT/GNv6QN43Nu9+gWXHMJ+A5Mj1veAhGEl81cltVUNcOnLKNtKezzstgEKOAllCBP+V0YvCjrFJJU0y8S4SFmnJAtr2SSGSv5JfOBby6p2sb4EQaRCD4c8fxSzHNFdY3xViK6Kc9rzCWbs95BhNhBiE4myc000lf93M40QYwJQYiPuN21nL3D17gO4PfbpPFd4UpWtSKZ8NNkmF9KrkuIdAcjqSuEZ0us5rVWIhY5nd4tabUnQUj62CZkeG5vb+IpGYINza0nMkNEUdsuaXG/QEYIPnyXcQEOSimZVbTosnN6mZm+NrRj1w5ZpLQI9DMYKwE62L7CNZnn9vUk1qp8tzD1hr2WeurosZBfsuCE8Exik89yy6jrsguwdqVgPhcmbnPWra09YZdIdOgiJoidQ1Rl96EJIjxBOM1MObx9D9I0QagMcbUyLjsI281V1nu2EZAS1y9mr9v8rNy1k64d7N91qVd6B89AJdv1iW8lotuPhyOZRwLUhGcQCP3M1vWS1mA2wUf0dSc2SFfCzpTHw4XEdbAvAJQmxrqq2JQzcsnuXEwPw7Xyr6CEJR/hIMnVkCXL7pttk/Do+QkY4npN55N3Fap1XSUgrv+cVljUXzf2OhKX1pGf/VJrOL5ddvldzqesfjt8jadQn/ndZHfiVrtsHlfMimLDebeY/jRcx+06T/Qz8ddTXYmrZX1QE0RIgpCxvgWwwuGgJghZVwz3NxcvpmUm8P8CXIyeAeHKwe1Tz1fJ/VM/c+F/wuRfO3YfPg0YTr0dzdClYJyULexJEC7nI7bvFCakO6Qlvmc0jdsdVzaqgpsWzhUD/VMvU8FB9aWWjtLGVQCL6Omgj7ii9JaaKJ8luxLT7WUu5iFRXCm1hv29YyF/XWPr6UTWpU2O+7iHJXEz+Q2b4ujat8yJ4p6XoI9IZXJub3fHVW6H25ogQhKE0ITMzORnXhL1NEEE7cfu5d06MGW4h6LGVcws0kxIB93wW/mvZOBMp3nIT8IAuXlEttKraqL8bTHBOWIb/HabsushR0Rzu2VN7CQ4QhcSIK729IpOtjdzIxm8LCgOfjjlfrfiLV6k098ybVwEYKpiPXFh07nT9+KOMIkEZebAoKk1xkp+BRIqSB7pkE0QxOUA3qOCLYsdNfEpftmcNUEURxBOM5PfgLd0pwlCpQurlfHpwFTXtPBQgrkMBBF4tXv2reJS+ocYuHGfvfgPYSaf7HusfEcG6CtgHAFg36xtV6zM/sGgOzIGXWM/8A5IENZnhm3yJK6HFKYxu/nF8zAzO+nMAVj4uourNUU21ZztWZh3/gUYD8Iwb5g+DZuKwEFNWeLwecapserq1z4DwiImsxGg6TYS6wf4OWKjJwPzhvSO3fqK2cnIUm8APLe3OyEC6UI95ZRfkOjzL9E8Zj4boE/k58/yvwZWyBat2VobgXGKBFtL3wy6xwTduL67/W8qLrGaIEJ1E11pvCBQTAceL23QcpQHAQlBlCy1Rnkk1m8tFwJFubmWSyj93vIjoAmi/BhP1C84s7uWwnV3omJR6XJrgqjQHqAJokIV79NsySG1b2oNjeTkRUATxOTVrWfLNEFUqOJ9ml2YjoLvRQYL3OIKNIqTGwFNEJNbv66t0wRRoYr3aLY4rK2a8toKgE/NFssQ0YnJrnaRakM/FYiAJogKVLposiaIClV8ttkiXUpkkAeTyTutgLL6+vgH2KBL7VebMvC4YQ7NSibv3FLZaFVu6zVBVKjuNUFUqOKzza5rbJtPxKs9UPBNn1LZCFZG6zVBVIaeC1qpCaJCFZ8jiKZWt5Q32RLBUnRUNpqTt/WaICavbj1bpgmiQhWfMzE1xWcYIJHAbzcJEh2DNXzqhgcTr1U2Srr1miAqtA9ogqhQxWeb3dIyb+pAuvrHIJ6XjZRPA7yBiC5/z568ZiyiwytbAxOj9ZogJoaetJQaAY2ARmDMEdAEMeaQ6w9qBDQCGoGJgYAmiImhJy2lRkAjoBEYcwQ0QYw55PqDGgGNgEZgYiCgCWJi6ElLqRHQCGgExhwBTRBjDrn+oEZAI6ARmBgIaIKYGHrSUmoENAIagTFHQBPEmEOuP6gR0AhoBCYGApogJoaetJQaAY2ARmDMEdAEMeaQ6w9qBDQCGoGJgYAmiImhJy2lRkAjoBEYcwQqgiDqmlqPJuDuEXQZD1XHeG5nZ+KNMUd8gnxQ52qaIIpSELO2MDHfVhN8RF93YoNCdV2kghHQBFHByvdq+kQgiPr6+BQYOAWEwd7uxLValXIENEHonhEWAU0QYZGb5PXGM0HE4/HI8y8ZRzGblwL0ESacl+rq+NEkV0no5mmCCA1dxVfUBFHxXUAOwHgmiPrm1qvBOD0nuSYI706sCUIP8rAIaIIIi9wkrzfOCeJmME7SBKHWCTVBqOGkSxUioAlC9wopApogJk/H0AQxeXQ51i3RBDHWiE+Q72mCmCCKUhBTE4QCSLqIFAFNELpj6B3EJO8DmiAmuYLL2DxNEGUEdyK/Wu8gJrL28mXXBDF5dDnWLal4gpgx49RY9U5b5zLjawB9AsA7AWTAeJZAnabB1++zJ6eKuMSd6loW7ot0Zr4Bms3AAQD2BBDJKjsD4CUCNjFze2YovWb9+jtfCdsRDj302N0jseg8Impj4JMApmXf1Q/gHwA9YJJ5bV9X4i8A2O07YQmibmbbR2HyGgL2t727n5lPTvUkOry+GUQWT3wIK3u7Opb4YXjIzIX7RDmzEExtGJZX6F48I1jBMG+YPg2bitC/nxgFv9fWLpoWiWXaGNwGog+DsXu2UBrACwD6AEpUR817VYI9iyUI4Vb87IuRg4nMJWAcAWBfANGsTJsJeAKEW6oivEZFHi9ArH6XNuYA5skAHWTrv6Lt/ySmrqBjsrl5/l5pjnYB+ID17fxAWaprWngowVwG4LO2720D+E9EdHUp2hW4E4yTChVNEIODxkfZMG8RvvQ++tgI4qW9XYk/BtAbNcxsbWaTrwDo4AD10sS4OpOOXdDX96vXVevV1p6wC8WGfkDAlwBM8amXAbiLo5GTU52r/iErG4YgGhrm78tG9HcYJsHcUxQ5iJfIZCmGIGqb4wcYTD8BcLiNqL1euZEMXpZcl/hDGIJT1eEhLfE9Yxnjp8y8wDYBe1XfBuIfII0Vvb0JQWrSpwiCoIaZ8c+wiZ8rjBHxbSV5ZEJaQY9RLAXTf9mI2qPt/FcycKaKTtwIYmAAVRQ1rmLm43z6wTYwvj+4Y+rPNmy4dkhVn5OhXMUSBAO3EOG/1TqjpWoxAM/t7e64ym+SELuSqp1e/SGsXcnITiFQf2HgccNMz00m7/inX8WGhng9G/RrAHv7lXX8voWBE1LdHQ866wUlCFdyIP5yqiux0g8zL7lLSBBU39S2GOAVAfSeEy1NwPcG+qdeVo5Jor4+/kFE6C4HuSqqkzvTUSx6uDPxkqxCGIIQEzZFjIsYLFbWud2uqjx9ZjRzXF/nHc+pVKhrWfg+SmdWAVSrUt5WJgPClYPbp57vpRMZQRjgk02iG7KLBNXPdgzW8KkbHky8plphoperVIJ4DWRtkXe2KVBMlg8R6HWA3w+gUbIS7yfC4mRXx2oPxVN9c/wcMF1SMLAIr4D5fwFjo1WfuBrMtQB9ULZiJMb1VbEtZ3R2dorttfSpb44fCqbfANjDUUAMnmcA9IBpgMD7MVAnmRi3wDBm965b9T/2+kEIQqx8o2ncDlCL7R39XAJyEO9raVlSMzC0fSmIPjT8fvMzQO7f1h/WA/TYyLfZXN/bkxCD3/646wVIM/BnAj1imReJPwHGgRL9Zwh07UD/rstKSRIzDo/vWr2DEgzLfGN/LDNHrr8weBcCmgBMd3YGBm4a6p96mkyuoARhLXCmvLYC4FMLOh3hFWI8yiDRtyIMPpiAj0n67yYy00f6LXBcFhbis5aZlwkpMSa92g7QtYP9uy5100kBQYCTzPQiEcROLfeIBWAPQE9nvyXMTc4xJQat57c85oUJ+VNlEkT+vPE0GeaXnFtVMUHuSNPXCbjA0flfMDgzq6dn9Z9lGpcMRtGpnjbZPP29e+MhmS1bmIeMWPpbAJ/j+NYWMumwZLJ9mFAcT23L/OlGOnovgI/bfsowY40Z4XPXr0uIQTzyWJN+hi4E46t532G+CyYW2c0UqgThMrkp77bCjJr65tbAgXJ1jfFjiGiVY9JPA/Rjcyh6idOc52HyyDD4G6nuhDBRleSpb4yfAqJrbAsKsRBZNrB96s2SSY/qZy48EKYwjebp/XUyeXYymegt6CfBkvW5EClmlP2ZAAAR1klEQVT/1WScJevD4tzLqIp9n4DTHIui+6ujfJzbuYRL33Htv2Ig1TYv+oTB6RscZltPnRQSRB5CUpOuOHd57kVB2NYuw74zL7n+S9KJyvSSSicIv1UO1TXGW4noJvvE4rGyp/rmtuVgXmrT17+Q4cN6exNP+eiQ6prjJxHT9fZBxkwnpnrafyWr29DU+l0GLrSTA5gvmL43Lvc4VJVNAIMAz+3tTtyXe5cKQbwd5CDkC0oQDQ3H7mEasQcI+JQNq61EvDjZlfitl17qZy78T5j86+yuMlfUc5EQZKxau6P0mwmAjrLVW9rb3fFzr/cIswzS5v12ZwAGlqe6O4RJKO8JsoOQL3DwIDLc1tub+D8PmXL9V5hgc2dgGSIsSXZ1/FJWr6659RvEuCxg/x0+k0obVwG8WGWceRCE7y7XxfT3TMbgw5wLsCB6nyhlK5kgtoD46N6uxHrfibupVayOxE4i90hX9jNaFr2rKp3+PUDCeyj3+A72XMGmpuN3y2DoXrstlgnfTnV1/LBg0NcummbEMuLsYGT34GVmsNeX2/Tpturo5pNy5iw/gnAZpGXdOeTaEJggmtsWMrOYpEY8x7wmLifWjY0Lm00y7wGwy8hvhJ/2dnWcXczZiniX8FiiWGadbaJXTsVd39R6JgBxnpJ9uC+C2Jzu7tu22tsQgCBkCxy/RZT9U1RXMFY4OViDI512e9FuZ/8NYr7J7lruoWGzqfWIM6Jkd8d3nfpzJQjmb/X2JARBuXrziXfVNS2sJZhip75bmHE9UchAJmfFEoRbZ5KBdOjM+H4Rk34PYD+vDlJfH/8PitCXGRDueQeCkIlw5nPd3aufVu0kzskPLi6bWZPJHbZJT3liEbI0OCZNBp7kocjMvr7bN4vfvQjCxUadZvB5qe7ElX4DThULt3JBCEK+Qud7kcECL88fx7cLJ07CU0hzS29v4vli2iOZvN40mWf39SS6/d7b0NB2CBt8JwNvAnjUAB7jDC93tkuVICT93HMHoDhWBhn4vNMRwtn/AKjutEc+W/gOfmIwGj1sQ+ft/7bL5kIQG82hyOG5/u6FdUtLS3RwaI+rmfDFUS6ujDtlKpUgPG37ks4iVkY3EHCy7bdEdXTL8V4HyH4DXPa7MkE0tf6MgLNG3xFs0mtqWvD+DAxhXsmA6BECejjNq3NmBDeCGOqfep/kAHPMyEG0NwhBiHamEekkYJ8cVl5mOzed1TbGmwwiYYLLOTZIJ76gOm9sPOadJtUIJ4NP23Tp6ZUU9BuqBFGw6AhBgmIyHUjvcRuAeE5OYvww2dPxbZvcBeNJ7H5T3R2nBFlcSHQrJVcZQQRZIA7vIloPJ0CMl6psO15kgw5LrWsX8UST9qlUgvijwTuO7um5e5uqZusa204gsswU1uNccau+x6+cCkF8ctbind+xfUCsHEe8XtxMUX7fc/tdRhBEOA6MT/CwuW3U9ZHxnd6ejouCDO6wcgUliLrGtjlELCbgnLyhBrbMfFiqNOOSsyTRzFdBWGWYtHLHjl03FOM1pUoQDY2tFzPh/JGJHVj7xk7Vxz7xwK1ih6L81DW3nk+Mi22Ed091dOd4Z+fNO8TfXEypZ6e6OsTuU/mRkivT6b097eLAf+QpZpeWe0nWIWSdzYqQYaajUz3twvQ0aZ/KJAjFSFu71p0rSAL+DZOPSCYTo+6V4boJNTYu3IsN87PMOCG7khwNdJPIKlsRMdOCVE+7MDmV5HGJPRDnNTOc7rsMpMzBoaOKiQAPInSQHUR9Y9tpIP6FbbKSmiH8vi9bGbuZ//ze5fw9exAqTJjvdanbD8JjMGklx+j+VOcqERvjaTfP67sKXkzS9oH/BhgiODDgw8JF+FAb5nlnI7Jd3Vsbw/sB8o35sQvC4BgBn7N7GUl2K5CMl2fMaHqmapyG+KZ0R10BF1VVJEGEWW2rrsLcRpLoYNvTxt4R4gMA/hAzHfTWlvUQR9qCwuoSghiL1Uzg4DTFA7+AM420eBCCKPCUKeI+cpXdXdj21TW2zSfimxUD+LaAcAezcfM+e2Ue8UsDotJ3A+s7WEP/HqV0c1fXHS+Kai6eUsHe6FZabUEV2IKgaDorTRvG0VsqlSACX1EpmZT9DoWptjn+UWI6hwjH2PLpBFO/jCAUVoTBPlJY2mfCEPmjBgDsZKu5lWHMSXWv6iv22371xw1BFEE2sjaKFCDEJM66Rjxz/LAQpigCrsgMxZa7pWbRBOGZi0kB4uEi5VwgKAsxxgU1QSgCLtkWuxKESAIXyZhXEmFewDQFW4a99fDuEbHGH0FY6Q1Axm0wLddPexCRZ2CUItS+xcYNQQDlcFQYXVgAIkdQLoGgHy4b2aBW2aGpJghNEH6dx31DFrbmBKpX19R6NAF350Qup4nJJbBKhtbmtwJ9/k6gbpOpcyhmPCzc81RWKRKyKvmBmcsOIi/3jSzQiRlLUz0dNpt/6TvKuCGIEGdZQdCwsqhuNvanDM9jQptLSgv7Kzea0fQcp209LEGU6hDe2WYVeYLg5FfWJ5urX3Xrd5m7dLnwURJojApV5A4izOGi85CagWejyLTYYxxEZHHVDqxx5CQSqnyegV8Cxn1DUdq4ofN2kc5besioQhBv2yE148rBHVPPy3nUyIKVRDpqr1QkpejXQQiidIfUhRHPIqI+2dMhsueOyWNNUuaOg8DmYjDmy3MFoSAwU2VClnnGlat9DQ3xA2HQWgbelQWu5Ascu0Kc4yWMB6Kqx9SYdIQx/EhFEgSFcN+TTDQFUauS4B+x4r4OaT5bNShLhSBknTXMrqiuqfVGAmYB/E+2kt0Zt+TOEPwiqXN9tLYxfoRBVhbSEc8rImof2L7r4mJcM73GQBCCcPqvh/U+k0Q8gwmBXTNLNbatXEEvYAmIREbiUewlfVuFIIRcDY2t141FMJgLloHPBVWxlCyoArs6S3btJYmDUW3D21WuIglCtvr3UsCwB8O0lQAfP2KmcgT2yLwcgrp/SlcpLmaMgsEMzvM19+tQUl90W94nVYKwokzT05Yz+AzbNweZ+QupnkS7nxxhfg9CEOM9UM5K48CZI4moXlwmlQ0YE3ciqDwi4OwSAs6zFc7zGBJ/VyWIwkUQggaUis/los5FoNxzIssus7m2Jvby6tE0LrL8U8ECPa12DacpEfmodiPgf03gL4bJNzldzyUEkSGiE5Nd7SJ5o9JTiiBCpQ+Ns0IVSRAiejhIB2loaPs4Gyz81HPpfwvqSydcl+Rpbn1A8h1xZC29HU2yWwk0mLN3SIjI4Fx+obxVlSpBiLa4JI57ElHjc24XEhUzDoIQhDTVRkDvI2mqhRBRxrI2F+uG6zxfAxCaIGT9j4GLUt0d31GNu5DFdMiSCBbmkcLrBhtH9fSsEje/KT0Nza0nMkO4BueCIKWrenmqjfzcY0EXiIB6faXGjNNClUoQ4gDgccMcmpVM3ik8h1wfkXcoNuXVaxxpNgryuMgibYPYcIevPn3tVmYW11+OPi4EIcsPpZ6sT5JbBvkruCAEIYSVDFYQ6Oqq6Oazyp2OxO+wUGb6Kz5ZH63o7WoXqU6UA9ZknUySwiPQRClxFCjw8VfeQYhb3QzcDqK5NllVk1rCZTfZzzCOTHWv6rS3v7FxwcdMijyQF+QGrB2o4bjKhTwuqe4fzQwOzXIGbLrkYuo3mef29STW+s3NEjNqQfZjv3dM1N8rliCEwsQEziaf5XY+kLXzngsikUZiJLWEbEKSpr8AlFbRw3cP0E/A1nWhebd3MeOXqZ6OL8gmImm6b+Jv9XYlfuwxcclSmA8y0yJ7JHZQgrDaUDi5iOtGF6Z6EiMeZKUYKM4dhCx61v4dl3Tf25hpiV/0uYtXmvSSpTBtyzo2/O6tu8IbbPWVMqjKdm4yLFQJQnxfdqYkDnVh0DyfvEPS1PiQ3DWSbSfVN7eKPi/uJrGviG6tjppf9rrb2rrtzqDleeclgLhHQupB55bNVaVdUv0H3IGG6RfjpU5FE4RFEsDatMGnOXO7Cw+dSHXsCjBOzJ+0uXOwBvNkqxx5Th1+xCSc1NeV2ORUevZq0s+D+RLXO389OqPLxJdh4BpzcOg7zpWU6yVIRVwYZG+TLC2y6k4tyICoK0hUiE3I8FyvOzfcLgxyu/87e+XmyQy+1BGLIG6c8yPhIM2R7r4A9wt6RLcdvivauE7lnoogBOGyCxDt2Qrmc2HitoJssbUn7BKJDl3EBHEOJW5qzD2euw+XXYBY2zzCiCxNda8SqV3ydmhuwYRiHLvtPnwuDHr5rbYtm74Xd9gj0rOLwzYQiXTq9jTfgXZ4gTrCOCxcmQTB+C0IYsWWU3xGDEjASFnZTWF+CiCRc8je2a2b4WDQcc7rOXN69cipk3d9okU4bB4Eoo84bjgTEcpPAviALWukZ1oAjytHVa/RlK5Wg+4gcqvCwvsArBEeyI7tN04kh6miiriW9QWAxA1h66piU87IJYcbXbG6XAWrfuVoWa6cdNl9DYudf8UnrKtjCQdJIvNdiSsIQYhPelyBKn4ezgvF9KdhAd3GCsRlPF9PdSWu9tKnR/+12g7GOoBetq7nNfFpEN5X+D4xLs15vesSWZnyS8gOqYXgAGIjJe3fAotA1cMlQYolXxz49fW3+/eKJAgCvsnAG2+lbr5ccu+wm05cI1XzVtHBcurYq25jIpESucdgvt/mI+6bWCxAcF5e27y22CEJAi67mpKuumT263ylyS/OsVbeTW1nSHYFKuNQEO4VQ/1T/6sc7rsu93qryGWRo0hfPdA/9bJS3EmdI4mqHXQtgFZVIWzlAl0cFbb/ZhnUc9EmykgIYiuBLmCwGG/2TABeTQ3UphCYjcsqFUkQ2TOEy+ub2j4P8I15qS0K1SS9s9ZnVfRpMH7hajbKrywmnlszhnHhw+tWPSs57M4w83w/O76419plmy8T1bdNYQlCfExuznE3zYUYGbLrLUde4+fGLMwUBluTn8h5lHfmI5NFuCtH2PhKT8+qR0LIqlxF7CQ4Qhdm7/kYzejr/YaNZPAy553q9ipBdxC5usP3MpMgCLGQeo9KQwRWTHyKzKTqVV/0X4oN/YBgncOptN23D+e+JyMIE3wERSOvUDpzC0DNXrKFbZMKXuO9TCUTxI+EcoY75uAXSZw1jJp80gA/xTBWZwy6RkzcQRWZ9X6aTYC4N1eYs/a0TUabCXiCmdszQ+k1jrOCgtvLggSeibOTaFXsBAYL++mHbaaIfrAwo+E36Ujker82FUMQLp5fJb/sPTvRi7spPgtgmk1HKrey0aFNbR+KMp/EZKWM3t9mUhD3hDxJjPvTRCvXd7f/rVhvpSD9J3ud6xyARSxBbXaVmzN3bgP4X4DxIAzzhunTsKkU2Vy95BP6jNZsrY3AOIXJbARoum0St+Rh0D0m6MZisbLMWwN0NBhfEHEhznEj0tOAcaNk3Lg2wY0g+roTGwQJPv8SZjPjTICasn3AMgnDwH0m8/V93YlHx1L/QfpKuctWBEGUG0T9fo2ARmD8IuBFEONX6vEhmSaI8aEHLYVGQCNQJgQ0QYQHVhNEeOx0TY2ARmACIKAJIrySNEGEx07X1AhoBCYAApogwitJE0R47HRNjYBGYAIgoAkivJI0QYTHTtfUCGgEJgACmiDCK0kTRHjsdE2NgEZgAiCgCSK8kjRBhMdO19QIaAQmAAKaIMIrSRNEeOx0TY2ARmACIKAJIrySNEGEx07X1AhoBCYAApogwitJE0R47HRNjYBGQCMwqRHQBDGp1asbpxHQCGgEwiOgCSI8drqmRkAjoBGY1AhogpjU6tWN0whoBDQC4RHQBBEeO11TI6AR0AhMagQ0QUxq9erGaQQ0AhqB8AhoggiPna6pEdAIaAQmNQKaICa1enXjNAIaAY1AeAQ0QYTHTtfUCGgENAKTGgFNEJNavbpxGgGNgEYgPAKaIMJjp2tqBDQCGoFJjYAmiEmtXt04jYBGQCMQHgFNEOGx0zU1AhoBjcCkRkATxKRWr26cRkAjoBEIj4AmiPDY6ZoaAY2ARmBSI6AJYlKrVzdOI6AR0AiER0ATRHjsdE2NgEZAIzCpEdAEManVqxunEdAIaATCI/D/Ac6OmMpaS1RPAAAAAElFTkSuQmCC"/></switch></g></g></g></g></g></g></svg> \ No newline at end of file
diff --git a/Documentation/x86/sgx.rst b/Documentation/arch/x86/sgx.rst
index 2bcbffacbed5..d90796adc2ec 100644
--- a/Documentation/x86/sgx.rst
+++ b/Documentation/arch/x86/sgx.rst
@@ -245,7 +245,7 @@ SGX will likely become unusable because the memory available to SGX is
limited. However, while this may be fatal to SGX, the rest of the kernel
is unlikely to be impacted and should continue to work.
-As a result, when this happpens, user should stop running any new
+As a result, when this happens, user should stop running any new
SGX workloads, (or just any new workloads), and migrate all valuable
workloads. Although a machine reboot can recover all EPC memory, the bug
should be reported to Linux developers.
diff --git a/Documentation/arch/x86/shstk.rst b/Documentation/arch/x86/shstk.rst
new file mode 100644
index 000000000000..60260e809baf
--- /dev/null
+++ b/Documentation/arch/x86/shstk.rst
@@ -0,0 +1,179 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================================
+Control-flow Enforcement Technology (CET) Shadow Stack
+======================================================
+
+CET Background
+==============
+
+Control-flow Enforcement Technology (CET) covers several related x86 processor
+features that provide protection against control flow hijacking attacks. CET
+can protect both applications and the kernel.
+
+CET introduces shadow stack and indirect branch tracking (IBT). A shadow stack
+is a secondary stack allocated from memory which cannot be directly modified by
+applications. When executing a CALL instruction, the processor pushes the
+return address to both the normal stack and the shadow stack. Upon
+function return, the processor pops the shadow stack copy and compares it
+to the normal stack copy. If the two differ, the processor raises a
+control-protection fault. IBT verifies indirect CALL/JMP targets are intended
+as marked by the compiler with 'ENDBR' opcodes. Not all CPU's have both Shadow
+Stack and Indirect Branch Tracking. Today in the 64-bit kernel, only userspace
+shadow stack and kernel IBT are supported.
+
+Requirements to use Shadow Stack
+================================
+
+To use userspace shadow stack you need HW that supports it, a kernel
+configured with it and userspace libraries compiled with it.
+
+The kernel Kconfig option is X86_USER_SHADOW_STACK. When compiled in, shadow
+stacks can be disabled at runtime with the kernel parameter: nousershstk.
+
+To build a user shadow stack enabled kernel, Binutils v2.29 or LLVM v6 or later
+are required.
+
+At run time, /proc/cpuinfo shows CET features if the processor supports
+CET. "user_shstk" means that userspace shadow stack is supported on the current
+kernel and HW.
+
+Application Enabling
+====================
+
+An application's CET capability is marked in its ELF note and can be verified
+from readelf/llvm-readelf output::
+
+ readelf -n <application> | grep -a SHSTK
+ properties: x86 feature: SHSTK
+
+The kernel does not process these applications markers directly. Applications
+or loaders must enable CET features using the interface described in section 4.
+Typically this would be done in dynamic loader or static runtime objects, as is
+the case in GLIBC.
+
+Enabling arch_prctl()'s
+=======================
+
+Elf features should be enabled by the loader using the below arch_prctl's. They
+are only supported in 64 bit user applications. These operate on the features
+on a per-thread basis. The enablement status is inherited on clone, so if the
+feature is enabled on the first thread, it will propagate to all the thread's
+in an app.
+
+arch_prctl(ARCH_SHSTK_ENABLE, unsigned long feature)
+ Enable a single feature specified in 'feature'. Can only operate on
+ one feature at a time.
+
+arch_prctl(ARCH_SHSTK_DISABLE, unsigned long feature)
+ Disable a single feature specified in 'feature'. Can only operate on
+ one feature at a time.
+
+arch_prctl(ARCH_SHSTK_LOCK, unsigned long features)
+ Lock in features at their current enabled or disabled status. 'features'
+ is a mask of all features to lock. All bits set are processed, unset bits
+ are ignored. The mask is ORed with the existing value. So any feature bits
+ set here cannot be enabled or disabled afterwards.
+
+arch_prctl(ARCH_SHSTK_UNLOCK, unsigned long features)
+ Unlock features. 'features' is a mask of all features to unlock. All
+ bits set are processed, unset bits are ignored. Only works via ptrace.
+
+arch_prctl(ARCH_SHSTK_STATUS, unsigned long addr)
+ Copy the currently enabled features to the address passed in addr. The
+ features are described using the bits passed into the others in
+ 'features'.
+
+The return values are as follows. On success, return 0. On error, errno can
+be::
+
+ -EPERM if any of the passed feature are locked.
+ -ENOTSUPP if the feature is not supported by the hardware or
+ kernel.
+ -EINVAL arguments (non existing feature, etc)
+ -EFAULT if could not copy information back to userspace
+
+The feature's bits supported are::
+
+ ARCH_SHSTK_SHSTK - Shadow stack
+ ARCH_SHSTK_WRSS - WRSS
+
+Currently shadow stack and WRSS are supported via this interface. WRSS
+can only be enabled with shadow stack, and is automatically disabled
+if shadow stack is disabled.
+
+Proc Status
+===========
+To check if an application is actually running with shadow stack, the
+user can read the /proc/$PID/status. It will report "wrss" or "shstk"
+depending on what is enabled. The lines look like this::
+
+ x86_Thread_features: shstk wrss
+ x86_Thread_features_locked: shstk wrss
+
+Implementation of the Shadow Stack
+==================================
+
+Shadow Stack Size
+-----------------
+
+A task's shadow stack is allocated from memory to a fixed size of
+MIN(RLIMIT_STACK, 4 GB). In other words, the shadow stack is allocated to
+the maximum size of the normal stack, but capped to 4 GB. In the case
+of the clone3 syscall, there is a stack size passed in and shadow stack
+uses this instead of the rlimit.
+
+Signal
+------
+
+The main program and its signal handlers use the same shadow stack. Because
+the shadow stack stores only return addresses, a large shadow stack covers
+the condition that both the program stack and the signal alternate stack run
+out.
+
+When a signal happens, the old pre-signal state is pushed on the stack. When
+shadow stack is enabled, the shadow stack specific state is pushed onto the
+shadow stack. Today this is only the old SSP (shadow stack pointer), pushed
+in a special format with bit 63 set. On sigreturn this old SSP token is
+verified and restored by the kernel. The kernel will also push the normal
+restorer address to the shadow stack to help userspace avoid a shadow stack
+violation on the sigreturn path that goes through the restorer.
+
+So the shadow stack signal frame format is as follows::
+
+ |1...old SSP| - Pointer to old pre-signal ssp in sigframe token format
+ (bit 63 set to 1)
+ | ...| - Other state may be added in the future
+
+
+32 bit ABI signals are not supported in shadow stack processes. Linux prevents
+32 bit execution while shadow stack is enabled by the allocating shadow stacks
+outside of the 32 bit address space. When execution enters 32 bit mode, either
+via far call or returning to userspace, a #GP is generated by the hardware
+which, will be delivered to the process as a segfault. When transitioning to
+userspace the register's state will be as if the userspace ip being returned to
+caused the segfault.
+
+Fork
+----
+
+The shadow stack's vma has VM_SHADOW_STACK flag set; its PTEs are required
+to be read-only and dirty. When a shadow stack PTE is not RO and dirty, a
+shadow access triggers a page fault with the shadow stack access bit set
+in the page fault error code.
+
+When a task forks a child, its shadow stack PTEs are copied and both the
+parent's and the child's shadow stack PTEs are cleared of the dirty bit.
+Upon the next shadow stack access, the resulting shadow stack page fault
+is handled by page copy/re-use.
+
+When a pthread child is created, the kernel allocates a new shadow stack
+for the new thread. New shadow stack creation behaves like mmap() with respect
+to ASLR behavior. Similarly, on thread exit the thread's shadow stack is
+disabled.
+
+Exec
+----
+
+On exec, shadow stack features are disabled by the kernel. At which point,
+userspace can choose to re-enable, or lock them.
diff --git a/Documentation/arch/x86/suspend.svg b/Documentation/arch/x86/suspend.svg
new file mode 100644
index 000000000000..a69073c018d5
--- /dev/null
+++ b/Documentation/arch/x86/suspend.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than draw.io -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="407px" height="1132px" viewBox="-0.5 -0.5 407 1132" content="&lt;mxfile host=&quot;confluence.amd.com&quot; agent=&quot;Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0&quot; version=&quot;24.7.10&quot; scale=&quot;1&quot; border=&quot;0&quot;&gt;&#10; &lt;diagram id=&quot;46NsKM0iVOHTgNer6hpB&quot; name=&quot;Page-1&quot;&gt;&#10; &lt;mxGraphModel dx=&quot;1964&quot; dy=&quot;1073&quot; grid=&quot;1&quot; gridSize=&quot;10&quot; guides=&quot;1&quot; tooltips=&quot;1&quot; connect=&quot;1&quot; arrows=&quot;1&quot; fold=&quot;1&quot; page=&quot;0&quot; pageScale=&quot;1&quot; pageWidth=&quot;850&quot; pageHeight=&quot;1100&quot; math=&quot;0&quot; shadow=&quot;0&quot;&gt;&#10; &lt;root&gt;&#10; &lt;mxCell id=&quot;0&quot; /&gt;&#10; &lt;mxCell id=&quot;1&quot; parent=&quot;0&quot; /&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-21&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-4&quot; target=&quot;8N6JJebqrzA787TgpwUj-12&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-4&quot; value=&quot;SFH driver notifies MP2 to stop all sensor collection&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;420&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-6&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-51&quot; target=&quot;8N6JJebqrzA787TgpwUj-4&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;330&quot; y=&quot;400&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;mxPoint x=&quot;170&quot; y=&quot;450&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-37&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];labelBackgroundColor=none;fontColor=#393C56;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-6&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.2133&quot; y=&quot;-1&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-22&quot; y=&quot;16&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-9&quot; value=&quot;Abort suspend; details logged in dmesg&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.terminator;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F27979;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;425&quot; y=&quot;140&quot; width=&quot;100&quot; height=&quot;60&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-12&quot; value=&quot;Failures?&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;280&quot; y=&quot;420&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-18&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;entryPerimeter=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; target=&quot;8N6JJebqrzA787TgpwUj-9&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;380&quot; y=&quot;320&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-19&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];labelBackgroundColor=none;fontColor=#393C56;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-18&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.3265&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-27&quot; y=&quot;10&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-24&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-12&quot; target=&quot;8N6JJebqrzA787TgpwUj-28&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;340&quot; y=&quot;570&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;mxPoint x=&quot;180&quot; y=&quot;620&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-38&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];labelBackgroundColor=none;fontColor=#393C56;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-24&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.0038&quot; y=&quot;2&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint y=&quot;13&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-26&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;entryPerimeter=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;exitPerimeter=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-12&quot; target=&quot;8N6JJebqrzA787TgpwUj-9&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;410&quot; y=&quot;530&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;mxPoint x=&quot;555&quot; y=&quot;230&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;Array as=&quot;points&quot;&gt;&#10; &lt;mxPoint x=&quot;475&quot; y=&quot;470&quot; /&gt;&#10; &lt;/Array&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-35&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];labelBackgroundColor=none;fontColor=#393C56;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-26&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.7458&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-1&quot; y=&quot;10&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-30&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-28&quot; target=&quot;8N6JJebqrzA787TgpwUj-29&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-28&quot; value=&quot;All devices go into deepest D-state or F-state&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;570&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-29&quot; value=&quot;Failures?&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;280&quot; y=&quot;570&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-31&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-29&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;330&quot; y=&quot;760&quot; as=&quot;sourcePoint&quot; /&gt;&#10; &lt;mxPoint x=&quot;170&quot; y=&quot;720&quot; as=&quot;targetPoint&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-64&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];strokeColor=#E07A5F;fontColor=#393C56;fillColor=#F2CC8F;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-31&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.0683&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint y=&quot;15&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-34&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;entryPerimeter=0;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-29&quot; target=&quot;8N6JJebqrzA787TgpwUj-9&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-36&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];labelBackgroundColor=none;fontColor=#393C56;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-34&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.8315&quot; y=&quot;-1&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;2&quot; y=&quot;9&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-46&quot; value=&quot;GPIO driver suspends non-wake GPIOs&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;720&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-47&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-48&quot; target=&quot;8N6JJebqrzA787TgpwUj-50&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-48&quot; value=&quot;Suspend initiated from userspace&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.start_2;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#0CF232;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;120&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-49&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-50&quot; target=&quot;8N6JJebqrzA787TgpwUj-51&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-50&quot; value=&quot;GPU driver shuts down clocks and sends SMU messages&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;270&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-51&quot; value=&quot;Failures?&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;280&quot; y=&quot;270&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-53&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-54&quot; target=&quot;8N6JJebqrzA787TgpwUj-56&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-54&quot; value=&quot;ACPI s2idle driver notifies EC using _DSM&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;870&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-55&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-56&quot; target=&quot;8N6JJebqrzA787TgpwUj-58&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-56&quot; value=&quot;uPEP driver (amd-pmc) sends OS_HINT&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;1010&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-57&quot; value=&quot;&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;labelBackgroundColor=none;strokeColor=#E07A5F;fontColor=default;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-58&quot; target=&quot;8N6JJebqrzA787TgpwUj-59&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-58&quot; value=&quot;Put all x86 CPU cores into ACPI C3&quot; style=&quot;rounded=1;whiteSpace=wrap;html=1;absoluteArcSize=1;arcSize=14;strokeWidth=2;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;120&quot; y=&quot;1150&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-59&quot; value=&quot;s2idle loop waiting for IRQ &amp;lt;br&amp;gt;to wake&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.terminator;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#0CF232;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;280&quot; y=&quot;1170&quot; width=&quot;100&quot; height=&quot;60&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-65&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;exitPerimeter=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;strokeColor=#E07A5F;fontColor=#393C56;fillColor=#F2CC8F;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-60&quot; target=&quot;8N6JJebqrzA787TgpwUj-54&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-66&quot; value=&quot;no&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];strokeColor=#E07A5F;fontColor=#393C56;fillColor=#F2CC8F;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;8N6JJebqrzA787TgpwUj-65&quot;&gt;&#10; &lt;mxGeometry x=&quot;-0.144&quot; y=&quot;-4&quot; relative=&quot;1&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-4&quot; y=&quot;14&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-60&quot; value=&quot;Failures?&quot; style=&quot;strokeWidth=2;html=1;shape=mxgraph.flowchart.decision;whiteSpace=wrap;labelBackgroundColor=none;fillColor=#F2CC8F;strokeColor=#E07A5F;fontColor=#393C56;&quot; vertex=&quot;1&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;280&quot; y=&quot;720&quot; width=&quot;100&quot; height=&quot;100&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-61&quot; style=&quot;edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;entryPerimeter=0;strokeColor=#E07A5F;fontColor=#393C56;fillColor=#F2CC8F;&quot; edge=&quot;1&quot; parent=&quot;1&quot; source=&quot;8N6JJebqrzA787TgpwUj-60&quot; target=&quot;8N6JJebqrzA787TgpwUj-9&quot;&gt;&#10; &lt;mxGeometry relative=&quot;1&quot; as=&quot;geometry&quot; /&gt;&#10; &lt;/mxCell&gt;&#10; &lt;mxCell id=&quot;8N6JJebqrzA787TgpwUj-62&quot; value=&quot;yes&quot; style=&quot;edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];labelBackgroundColor=none;fontColor=#393C56;fontStyle=1;&quot; vertex=&quot;1&quot; connectable=&quot;0&quot; parent=&quot;1&quot;&gt;&#10; &lt;mxGeometry x=&quot;440&quot; y=&quot;620&quot; as=&quot;geometry&quot;&gt;&#10; &lt;mxPoint x=&quot;-14&quot; y=&quot;160&quot; as=&quot;offset&quot; /&gt;&#10; &lt;/mxGeometry&gt;&#10; &lt;/mxCell&gt;&#10; &lt;/root&gt;&#10; &lt;/mxGraphModel&gt;&#10; &lt;/diagram&gt;&#10;&lt;/mxfile&gt;&#10;"><defs/><g><g data-cell-id="0"><g data-cell-id="1"><g data-cell-id="8N6JJebqrzA787TgpwUj-21"><g><path d="M 101 351 L 154.63 351" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 159.88 351 L 152.88 354.5 L 154.63 351 L 152.88 347.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-4"><g><rect x="1" y="301" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 351px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">SFH driver notifies MP2 to stop all sensor collection</div></div></div></foreignObject><image x="2" y="322.5" width="98" height="61" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAD0CAYAAACB1LEoAAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXlgXFW9/+d7Z6YpoCxPpICg4i7uVppMkol5lFWWQsskLYuAuID2gfioKKDoE+GHqEgfi7IIZWuTkQpYQUAxNjPJpFDl8RARkUWQpcpjE9Jk5t7vjzOZSW/unHvn3tkyk3zvX23mrJ/vOedzzvd8v99DkE8QEAQEAUFAENAgQIKKICAICAKCgCCgQ0AIQsaFICAICAKCgBYBIQgZGIKAICAICAJCEDIGBAFBQBAQBPwjICcI/1hJSkFAEBAEZhUCQhCzStzSWUFAEBAE/CMgBOEfK0kpCAgCgsCsQkAIYlaJWzorCAgCgoB/BIQg/GNVccq9upbuHjb5U0S8hIE9AewMIJQvOAvgaQL+zMR3MRnrdp9nPZxIJMygFUdjPdeAcWzQfH7SM+H09GD/95xp2zp7DiHgVtvfX7DA+44kExv9lOuWJhZbvEuWw4MA3jmZhrBqeLD/uErKrWbe1s74fAN0F4Ad8uX+NUzZ2ODg2meqWY8qqy3W81VinN+oWFS7v1Le9CIgBFF7/Km9qyfGFv8AoE8ErO7vAL4Jk1cPDydG/eYVgvCLVHXSCUFUB0cppfEQEIKooUyi0fi/Udi4lJmPsJ0UyqnxAYtCR40Mrr7fT2YhCD8oVS+NEET1sJSSGgsBIYgayWOv7vjO4SxWA9RdpSo2wTAOH16/ZqhUeUIQpRCq7u9CENXFU0prHASEIGogi/nzPx+Zs9VLFwP8eUfxWSbcCcaPyeTfj4/vsGnjxsszKk08Hg89+6y5U4bDnwDhRGLsByBsz8/Awwgb+6cH1jzu1ewigmDc3RLhRQMDiX/VoLu5IuUOQu4gajW2pNzpQ0AIogbYt3bE9zWIbgGwVaF4tbgzheJ+1URt3UvfTllzDUCt9iYS48o5kU0nDQwMqEtt7ScEUQOhehRZzxNEfXsmtc12BIQgqjwCuru7w2PZeasAPtJW9N9g8sLh4cQjQaqLxeJvzjJ+4SCJTWTRwqGhvgeEIIKgWbu0QhC1w1ZKnl4EhCCqjH9r67J5FDHXE/AeW9HLh5P9l5RTlfY04mJqWihfThDlIF1+HiGI8rGTnI2NgBBEleWjWSxetZgPGEklkuVUNX+f+HZzNuM2gNon1VWM69Op/k8DYF2ZQhDlIF1+HiGI8rGTnI2NgBBEleWjWSxeJIv2Gxrqu6fcqto6ey4i4HMAngWIibF+TmSrkwYGrtksBFEuqt75urvjbxjLGgcC1vEgWgDGm/I5ngJhnWHxj1KpxJ/V34IQhNPRjYFD08n+X7S2HrUtRTJnEHA8gJ0AjIL5ISZcb41nV23Y8PPnVV2lHOXa2+NRNuhXALbNt7esDUpn55J3ZBEaIGD3fDnjDByUTvb/2gu5KbiBPg5gXj69ujN7gpgGLYOv3H1nTvt1Ai1yltxidPHqhI8RzlViyBt1PAfgbiZcEqSO2oyi5i9VCKLKMmxvj38UBt3FwI7VUDGV0zw5QZSD2kQeZU321DPU87pX9EUA3uxRUhZMF8KyzrZC2NOvJ7WOIMgwnoLFPwP4Hfr6eF1LeJu42hCUIgjdiZMY5w6l+s8MgkpbR+9RRHz9ljw8ND4Xn9r468RL2k1JNL4VwlgOpm8AeGPpuvghMvClofWJ37qdhAtl6AjCzGR6Qi2Rr4FxqouPkS9CK93O2Z1CCKLK8u/sPHIHE5nbHRfLD5KV/dTQ0NonqlydtjghiPJQVrvfzVlaSYBS3xVCoHgWpqzKTPAqg0iFGSkZasO5wBNwCgNfwEToFd1nEtHRQ4N9a/ycIFSaaGfPlwBcbFvcR0KIHJhM3viCH2S6u4+bO5Z9NQHQwYX0BHx7KNn/LV1+N4s7H3WZIFw4/tr2ZxTMvXV5isOt8ADDSBH4a+5y8iY0H22TJACEIGowDNo7e77FwNlTi+aHLMbJb90Vd/s9WpfbNCGI4Mh5+K6owjYxcDeBXibwHgy02XfJRLiVGV0Ats/X7BqLSXMCeN6mvlLhVFIAPZo/TXQA+KuVCe0zMrJaqU5KqphUmvb23g+ywb/Jq6rUnwLtptu6et9PVi7/Lvn+uMbVam9f/DY2wrdpCM4E40kmpBVuDN6WgE4AuxVLhy4fH91uuRtJaOJxvQKgBcCcXFmMx2Hgd7l/W/gkCG8HULZhSPDRM3NzCEHUQLZqR4WsdYfDkqlQ098ZuB4GrSo3GF+pJgtBlEKo+Pf2WM/RzLjGsSN9GuATdtsFd9lJXZFJy9Yv9jJjpe3UYC/UP0FM5uIRDoeW2p0g1Ylm1MRbRwYTDxaSlVIxqXS6EwADK9PJ/lP8IBPt6P0CiH+8JS3fDhNLnPHAlDqrZTMlGNjXVq7JjJutEK/YsD7xmKM+ao0t+5DB2asccclMBn81nUz8UNc+bcDGiYSjBHztLbvwJTb5UGfnkj1M03hxeDjxf376K2ncERCCqNHoaOvoXUzEasHx0seOgnAfwD83LOu2zZvf9LDXUdtvUxuEIPw2N3i6KkdzbW8/fCfLiNxJwEdsjXkQJi/y8l2JxuILwPQL2069kD0QQfj1kFeF+yEIla491ruUOXeHkFeV8f3j4fDCjQOr/+kFeFTdJYRwE0AH2tJpd+NFbQFMMJ+12664wOuUnL/IvhTgY2x1uPoKuRIE89eHUwkV2VZrzRd8YEkOJwJCEDUcE+1d8b3ZousA7OqzmiwDfzQYv7RCdH25J4waxGIqGb5aE2rDZ5fLSFZtgihaTPGywcbBqdQaFWbc82vriPcS0bWT6o6J1IEIwku/76zcL0Es6IrvEbJIqYn2yJfhS83kVE8x8GQYZncyedOj9rYofx8jYiqLpg9u+bu3qsief8GCw99kzImsowl1Xe5zw8GFIB4zDV6oOaWUEpn8HgABIYgAYJWTNG+++J28mepk6A2fZb3IwFURyv4gyNsCQhA+0c2pY5Tn+043KgMm20J3Y0v4uWO9wpkU0rrsuIMQRCAzVL8Eodbbts6eq/Jms7nm+lEzFV9wkxaL4hMKAkcL8HvKcSGIREt405F+ZOR/NEhKJwJCEHUaE2rHFIrMOQJk/QdA7/NrJZNvnjpZXDo3zGf6CbgnBOFfqNFo/C0I0wAY7yrkYqaj06m+G/yWUmwSGugE8ZgVznaNDKx9yk99AQgC0c74AUAuJtjEZS7wgP3C21lfTvWToVtA2Dv/2xQLKlt6HflcnU72nxBE3aPxtdCSpY4gmHBmerBf+T/IV0MEhCBqCK5b0RM6WHQSG71MvI/esqM4NwP/QyYfUSqmU4MQRFO8KNfaEe80KOdYtk0e8WfYoIXp9X1/8js0NL4v/k8QASPtBiGI+d3LdpyTzf4GoA/n+zIO8KLhZEL1t+grcvgjPIIsdw8PJ9TDVZOfzpSbCV9JD/Zf6Bczla6j49A3WjRX3eF8cjIf04nDqb6f2MvREkTewTBIfZI2OAJCEMExq3qOvP19GxGWgKFszzWmgJPVlvSpaJBL6qYgiLwxwU0FdHNRdzOhroJZqR9ha+Jv+ScIIJCqJAhBqLa3d/R8lwlnTPaD6OLhwb6TdTv94rL1aTU7f1X8HQAF8vNhcISA/e13dDqnPg1BBFLL+ZGhpNEjIATRgCMjdwE4J/tpMCmzxLc4m8jA1ZnR7b/gZvEkBOFfqEWLYsAdvapJo5rxTxABL9wDE0Rx6A2tmknjge16qa0JLeIf8FIpNXhoCKIqm49STZHfxVGuocdA7gI0jBX58AX2x4NeJosPGBpKDOs6IAThX6wznSA05KVVMxXHcGJX72shCP/jq9lTygmi8SVI0Vj8NDCdZ7/Y9oqvIwThX6gznSAUEkWWSRo1k9P738v0VgjC//hq9pRCEFWUYFtH74FE1lmAsTPA6tLzIYM3H5JK3apCA5T96QKwAVsCuDkLFoLwD/VsIIii0BuOy2fNpbPnCVVDEDVV+YiKyf94rnZKIYgqIuoMUeDmZFROlfmQ3+pyceLz0JULQfhHWOPgV9Ip0Fm6ZoFtmDsI1VaNr4fJzIvTqYQKMIhiSy59aI1CvzVWWyYzHZJO9d3uH3n/KYUg/GNV7ZRCEFVEtK2zZx8CfmmzO58yESupqi3WcwYxvisEkXO5XTU82H9cJXhuWex692KD77QF2gu8G9ZY9TQUQai+Op3SlKFDwW+haPNRItCd7tVELvHKYSWyEoKoBL3K8gpBVIbflNya8AYA8y2wsMwZ6CxItTpvX/Z4VU5OEP7R1T4Rq7HF9yqxrSN+KBGttd0RNRxBFI3NvJppvCU85vCVKOkHogsGCHifOnT45bFXQS13IODPFvAnw+Krh4YS99nTC0H4H8/VTikEUUVEJxbyeasAPtJW7DgzfzqdSvSVW1VHx5IPWBRSu9wtMZ08FjEhiEBIF3kFe6nvnCW7yLzhCEKdu6Kx3pVgXp7vQ86MlZk3OxwFffllFIfk8B+/avL0VhxBV2taKwQRaDxXNbEQRFXhVN6hS2MWWetsTz6qGl5g5uPSqYTyGg0UedIlpLJnoDIhiGBC1YSkMIlw3NBgv+1FNX2ZLvJuRIIoCr2hLOFUr2yOdG6hNYo6r9u0EHDX2FyOu706Zy+ktXvxbkY2rO4sbMH+8HtzPLNf4XnVQnohiGDjuZqphSCqiWb+QnA8O28lg09yFJ0l0BUhynzHb+C91lh8T4OxyhE7XzHMOelk/zfdyEYIIphQc/4mBlaDaJEtp3ok6CivN5ij0fi7EMrFOnK+BteQBOEMvZEL3cJsgehjuX67hNZwQZOisZ4fgvHlqb/TdS1h64teMcMU3mTQSiZ81pZXvSOxPJ3qt71DMfGrEESw8VzN1EIQ1UQzX5Z6X4BDkXVg7KUpPgti9TrZdWTx+s2bd3im4BGtdLvj4y/PYwrtA8KJrwdaUxN3ytOXfnZpQhDBherytsMrIP4OsrjYfoc08W61eiSHrnIJ5d6QBKFQ0b92mMfLIwyHDlGXU4Dat9zLCC1PJ9dscG5i1KaHmFSU2ckw3xPc5H76EIIIPp6rlUMIolpIOspRTzFaRvgWxyM0FdWmdnyGlV1U6m1rIYjyYG6P9Sxhhnq/wxmW/RUC0gx6DOA3g9BleyZUV1njEkRx6I1C+z0D+bkh6vFoklr11XOq6wH6B4hbbM+BOoqjR2FYhw2vT/yvrh4hiPLGczVyCUFUA0WXMtRbEMaczEowjg4Y3ttZYu4ZRzPCy+8ZSDxbqslCEKUQcv2d2mLxY4npUg1JuGVS9xVrmHkPgNrziRqWIDShN/JN9vfinA6EaNfSj8Hin+Xf0Q4IviIHOmJ4/Zo/uGUUgggIaRWTC0FUEUyXonLv8BLM84ixHwB7TKVStZuvW5rcYxg4fWh9v3rdzNcFtxBEKVi9f3dTg2hyvcJEZ2ZarGvnjNJa2zsKDUsQqg8aCyTX19z8IlnGw1hZYlxmZiNnjYzc8LJXPUIQfqVQ/XRCENXH1LVEZZEU2Uxd+RDHSgerwnrPs2UwATxLwIPMdFM2RLfds37Nk0GbKAQRFLHi9Oqe4clnqY0YXwLQBWDn/ClwFMwPMeF6azy7SlncNHI0Vx0SbV297yeL1XOku+R/9wytEQTNnNXdGB0Cxqd54vK+gJsq5rnX36H+Kxg/NTPZm53WSnKCCIJ0fdIKQdQHZ6lFEBAEBIGmQ0AIoulEJg0WBAQBQaA+CAhB1AdnqUUQEAQEgaZDQAii6UQmDRYEBAFBoD4ICEHUB2epRRAQBASBpkNACKLpRCYNFgQEAUGgPggIQdQHZ6lFEBAEBIGmQ0AIoulEJg0WBAQBQaA+CAhB1AdnqUUQEAQEgaZDQAii6UQmDRYEBAFBoD4ICEHUB2epRRAQBASBpkNACKLpRCYNFgQEAUGgPggIQdQHZ6lFEBAEBIGmQ0AIoulEJg0WBAQBQaA+CAhB1AdnqUUQEAQEgaZDQAii6UQmDRYEBAFBoD4ICEHUB2epRRAQBASBpkNACKLpRCYNFgQEAUGgPggIQdQHZ6lFEBAEBIGmQ0AIoulEJg0WBAQBQaA+CAhB1AdnqUUQEAQEgaZDQAiiSUTW3R1/w1iGbgFh70KTGTg0nez/RakutLYetS1Fxj9LjKNB9D4AW+XzvMLAM0ToawmFVo5lzL5yyi9V/0z8PRrruQaMY3V9Y6aj06m+G6rR77au3veTxb8BsIujvBcs8L4jycRGXT1tsZ6vEuP8CtrwCkD/IPBfmfguk41bNiT7/gKAyyyT2rqXvo0y5vEgOgiEt4PxpnxZWQBPA0iRRdeMjW33240bL8+UWY9kqyICQhBVBLPcolpj8T1DFp1qZkNnjYysfk5XTrkE0d4V35stug7Arm7tI8aVcyJ8arkEVG6/mzmfF0EASLSENx05MDCgFr6KvmhH7xdA/GNNIbUmCF27HyCDTxlan/htEKJY0Nn7nhD4pwDaAIR8APIPAKfstgv3JxIJ00f6ipL4mX8VVdDEmYUgplF4sdjiXUyOfIPBnwPwRJiyscHBtc9UiyA6OpZ8wKLQnV7koOpiwlfmhvgKIQj/g8HzBAE8GYbZnUze9Kj/EotTdncfN3cs+2oCoIMbhCBUM0wQLhx/bfszfOzyKdrZewTAVwF4YxlY9I/P5c9v/HXipTLylswSZP6VLGyGJhCCmCbBdnb2fsQE3wFgXr4Jf602QbR19lxEwMmaLj4H0KsTf+cdmWnp3Ig1KAThfzCUOEGgGmomD/WSauh0nCAKAJkg/vrwYOL7XieJ9ljPEmao02tBpVnIn2XgjwS6VxEOgffgidOFhkTo8vHR7Zb7ICP/wgMQdP4FKnwGJRaCmCZhtnbG5xuguwDsUAuCcFFJPcwUio8Mrr7f2e1yVVjTBN+0V1uKIAC6sSX83LGVqJk81EvlEIQnoRSPh+Pmjo+/PI+NsDq9nA3gzY40LxtsHJxKrRnUCSMajb8LIVJ3J2+1/Z4F6PtWJnzeyMgNL9vzxePx0FPPUM/r8+EiR10mg7+aTiZ+WE2hB51/1ay7mcoSgpgmadV6gKrjc5bDavK+s9DFauxqpwmuhqtWQxCvAGgBMCff2MdMgxduWJ94rJzGR6PxrRDCTQAdmM+vLm0Nmw4/6AkiEEHY2xyNxv8NIeoDsM+UvjDfAgvLhocTo44+UjTW80Mwvmz7+ygRjhka7L/JC488sdwCYE9buoqw1NVX6/lXjswbMY8QxDRJpdYDVEMQL5JF+w0N9d0zTV2eUdU6CYKBNDHGQejKd9QkoqOHBvvWlNPx9vbeD7KRs17aKZ//5wC6bSfOuhGEqr+9ffHb2Ajf5li4tW1Y0BXfI2TlTg97TG5OgHPSyf5v+rnc7uhYGrPIWgdgWxt2y4eT/ZeUg6UQRPmoCUGUj11FOaeBIMreQVbU0RmauegEwbgbwO0gXLCly+WrmaKdPV8CcHG+rBeYcQYRzp0uglDtcLRpomlMJw6n+n5iF3NbR+9RRHx9uScAzelJFVU1yzBVWK3n30wZ9kIQ0yTJWg9QzQlCCKKKstYShMFfB9PNNp+FslQjxQsk324xzjWIbp1OgtBemhNWDQ/2HzeFIIqNIwIv7ho/jt8ZvPmQVOpWpcqr+Kv1/Ku4gQ1SQMMThHOg2J3D5s//fCSy1YsHEPgkgD5uswhSg+hhBt9ojWdXbdjw8+fLxXvBgsPfFIqEDwPhMyB6r8O55wliGjRhXZXdvMNIKUuLts6eQwhQk9zPN2VB93OJXPritKjaScspP+WXarQHVkpH/ThAd1pkXT4ymPiTH1WDsz4l7/DcF1pDME5g4hiAtwEI59IRngfjcWLckSVaVaFTV6muQkcQ45FQ75xs9mqbWWpZaiaNemm5BU47jBrqqmJSgOjutZw7+w/vd8w2b3ht7OcM7FsAkQlnpgf71enH96eZK55Wfn4KrmT+uZVfzfXBTx/qnaZpCSIai38SjB8DOc9gry8LpgthWWdrLtNc8+3VtXT3kGV9m4BjJhch73r+DmCFl3NPJQPUzwI+XQShPLVD4cw5TDjJD1ZKX8/EJ4wMJh70OeCprSPeQ0Q/APAWP3nKqMNPsZNpdATREuFFYxnjKLtjGwNXp5P9JwQhRIcqZxNZtNA0rJaGJAjG3arfAwOJfylwcr4bmdeWg9AO0EdAvB0D30sP9n8vCMBtsZ5TiWGzXOL7x8PhhRsHVv8zSDn2tJXMP2edtVgfyu1XLfM1H0EwLyKi3YGcrtdpX+2KFRNuy7TwkX6cbvx4H7tUZDJw7dwwn1yYMNUaoI1KEO3tvXuxgTUAvyPgQFWnihXDyf5LvRbPnPnj01gBonN8euHamzHKxF9MDyZWBVmg/fTDjSA2W8buU0JjEB5BlruHhxNqA1Hy06mXYGKJFcKeDUkQGhVTyU6WTkBtnT1XEXB8ISkBd/1r65bD77/zurz/TulCnCmqRRC1Wh+C96j2OZqOIACsBnCYjRyUZ6cyJUyBaczL6YYJp5fayXg49wSpR0tG0a6lH4PFJ06I1doxr4oomEW+zIxbiei1vNhHOUw/Sg+seXxiZ1Y6FlO0I34CyFig0jPz1kQ41GYJMg7wOsCw78D+ryU8dv7AwM0v+infORyjsfgCMKlYUAVLm0KSLMCPgGhEyQTgN+ese7bE3imkK+lw5SIPE4wnmZAm0IQ9PfGHwPioZtPwAsM4MJ1cM1LN6eRGEMA2WYf3s8nMi9OphC/Vok69pKx3NDrzuquYNG0AMc4dSvWfWU1sdVZQ1ainkvlX6F8t14dqYlitspqRICYXF2bcbIV4hdPWPLcLC2MFmL7hUHk8YGVC+7jFO5oYQNavHAueSYQ1IWRXOMNgeDj3gECXzQk/d7Kbo1TQS7KgC3jQS+qg5buYPWaJcVk2k/m2895HYfW3p7G3QcaPHaeNUWZeqltAc/rdOREVKkTdL+U/HjANfEbnX6D6sDlL/0nAWVPlXr41kdtEcyMIdXJ0OrgFUTPp1EtDQ30PNAJBtHf2fIsnnOZsc9A/+fldtDQX1C+TxQcMDSWG/ZZRKl3Q+afKq+f6UKr99fq9WQnCBPNZu+2KCzyCeVE0Fj8NTOfZVBOuu7kcqRhYDaJFNvB9qUFauxfvZmRDPwOo1Z7XYl40kkoob+miL+gADbqA15Iguru7w+OZnS5jwmft/WXm49OpRL+XOmev7vjO4aw6BZKy6c996r7AGs8c7CSVts6efQj4pc35zJPg88VRtCN+Oign98L3DBu0ML2+T12OV+XzIogiax+faiaNemldS3ib+MDANZunmyBc4nqVZaXlJQD9qZRvV2q2IHeIpYQcdP7Ve30o1f56/d6cBOHuwTkFt9bWZfOMiPlrAB+cXIxcLCra2+NRNkidHiadcziAc482tIBHO4MO0EYiCI0apKSqyC4YDVZaa5+ii0qf+m6t3KsYgju3m3SG+7Zd1mqC7PlSMxXhavMxmE6CaI0t+zCxmSDgPVMmGOFHw4P9X6nW/c78feLbtWymhN0CCoBnSI9yF8qg86/e60O5/ap2vmYkCF+TTQGldrpj2Z1uBBCfBM5lkdEEtvOzW50iD40jkaueOOgAbSiCcKga3E4AXoO1WF3Bk7vlQj6NqsGvPT1FO3uuAbAQ4CcYdB9gXFvNewgvgsgRiDNMN9HFw4N9KnCi63sKjv5OOfXUkyCUOvDZZ82dMhz+BAgnEmM/p3UaAw8jbOxfuCOrdGFS5DBnM10OQMVjmvyCbNKCtCHo/Kv3+hCkL7VM23QEwQFDKbd39HyXCWd4EURn55E7mMjcblcRlXMp1tm55B1ZhAYIUFZWE5/G01T9OegAbRSC0LbDx+W/cxC3dsQ7Dcqd2LbJwaSRa1tH72IitsfuqZlVUtBJVoogNE5lnhuOYlynEmYVCCJoF73S+4qr5LdCpb4hg1Y6VJZQlktjcznux/LQb12FdEHm33SsD0H7U6v0TUcQAAJ5VBbtQjUniPb2+Edh0F0M7JgHepyBg9LJfqWe8v1p4/e7nFiCDFDVgEYhCA0Jmsx0SDrVd7tvoBRB5u5twutt8XqKMNdZs+TeIwD/QfnAWNnwOjeDgyBtKSdtKYLQjAVlRbZoOJlQpFj0FY0Hx8aigQhCvTR3wnCy72fVUC3lxnXWuBRg5W80+THwP4aVXTQ0tPaJcuRTKk+Q+Tcd60Op9tfr96YjiKD20H4IQnMZWvalZtGJxeFIVM4OppEIwrnzB6Azny05fjVmuLo3FJQ9/H/lrZLcynwKhHXMuGlueOukutAtWXkVEpQiCFVFEDWTfZzqTlMNQBBZIropQ7TinvVrnqwChMhHiVVPsx5QT3JQdQUhiOlYH6qBbzXKaDqCgM+LygI4PgnCGQKjbLf+ovpmGEEEdDYKNEZ1fipKNx0ZoxuJ8SkfhSn/i41gXGFmsjdXEmKlVF1+CMKvmklzOiy6a5kGgngO4H8ClGTgl5m5vL6aqh4Xyz91KBmxwuYRIwNrnyolg0p+D0gQdV8fKulbNfMKQaiHcotjJFWPIABtWUEGaCOdIOpNELmd+IRfy/K8X4vfpyvVW8ZphvGf6eSaDdVQh9gnnh+C0KmZdKpL51jQvdtRBYJomGCNeYe1nxV73/NANoxl9wwknq3mIqcrK8j8m471odb991u+EETNCYJHQogcmEze+IJdKEEG6GwniAJuOUc4E0cQ47R8DK6Qj4GeJeDbY6Pbn18qmKKPsiaT+CEInZqJgZXpZP8p9rpKqZdcVCJ196QOgo9LWhVT6xAiUhZmhZcUC0lr+v60sz1B5l9tCUK/PlQB66oUIQRRa4KY+Sqmsk9blYzgnOppM3URsAyE/TRhPOzFV/3ZSr8EUaxmmhp0zo96aYYQhDI9/qImhpoKYXMFsvyVajrClRpbDUMQLutDqfbX63chiAmCcHrsln1J7bSXdrtUDzJAG+oE0dF7IBGr+Eu53TsB/4TF+w4NJe6r16DV1EMdHUt3sWAeCMLnAJqviSob2K/Fqz9GGfWvAAAgAElEQVR+CaKUmskxDlzDgzezikmFaW/Z6sUzeSIEiv3UlwXxGbvtjB96RESoybAKMv+mY32oSafLKFQIQhFEV+/7p0TgBMoy3dTFwifGlUOp/s9VcsRtJILQmPz5dlwsY3yWlUWFYg5b5rX2cB7KPLYcc1y3BvgliFJqJodRg2voimYliAlyeOkiBn/eQQ5VNZcNOlACEcQ0rA9B+1Or9EIQAKbDESbIAG0kgpjfvWzHOdnsbwD68OSg9OEl7BzAKqyEZfBtr5uwZl+PznsfAX8h5ktSqcTfcotqNP5vCBkHA+qNZ6tNLS4hWAclkzc96mcytHYtebdhhX5rfz/CTzRfP2Xn2ucRasNZhkbNlLuXCoczmbEM3QLC3hN53IMKNiNBKHKYs/WL54JxqoMcNjFwVFA/I7+y8ZMuyPybjvXBTx/qkUYIIo+yxpX+T1nD2D+IzbcmNMRMDLVB0VjvSjAvtw3Qv8HkhcPDiUd8Dlqdf8MUtV40Gn8LwjQAxrvyZQY6qVTL47saJwiNmulVi/kAEEZtbzx4vj7XhAShC5apSPBRGHTE8Po1f/A5VmqSLAhBqAbUe32oSafLKFQIIg9aTYJxwT0KZdAB2iie1Aqu1o74vgbRLVPfXqDLx0e3W+7HUkgfNpnXtoS3Oarg6KaLo0VEfWOvbXeMrzqKCUY54i1Jp/rWljFPirIEOUHkThyO2EwqlItl4CVinJ8v3DMyarMRhG6M5OI3GXRYNaPqlivLoPOv3utDuf2qdj4hiDyiLuF8sww+PZ1MXOhlR+8W7tvtnYPcItsZn29/IaxUjKlGIggXrEwCzhkb3f67Xgt43nu2D8A+tsE8qguN3h7rXcrM19vDtYP468ODie+X8GsoCvldCt+gEysoQWjuuTbm61QX6p7qJd14AdCwZq7t7YfvZBmROwn4iA3XTSA+ZHgwoXxSpv0LOv/qvT5MO0D5BghB2CTh9iCIepjIDBmnOtVNKurlk08bi4j4vwHsOlWo3jtq3cW41xsXjUQQuR2x/nEltW6vMxinpVKJPzsGObV3xf+dLVxS/I64Hiv1YJAxJ7KOAHUHUfhcHyXKLaStR21Lkcx5BHxhit67yqGpgxKENk7Xlj6VVJ810wlCo2qtuplxpQto0PnnMebNWqwPlfavWvmFIBxIVuNJQT9RKLWXvbmNJJ4H00sMzobY+GwqtWZQ/bnRCEK1yQMr9fNTDCTVk6AM3paQu4h1Pk2q+jscRnaJ87W+glj06qzcr1OfNSVuAXMrQOrOIuwQ64NkZT9VzcBvQQkit8A4Q4AXGunjQaFmIQjdWxxVWqyq6m8TdP4V+lCv9aFKmFVcjBCEBsK2CVt/9dD9mwMirMI7KI/Qk3zEraForOeHYHzZrQ57yIVGJIgJkogfxEzXaTxjfUDnK+4OtcXixxLTpZr3pn3UgQfYoJ5q673LIQjNrjXXfj9PkjYLQWjUgn5k5CdNVQlCbcWCzD97A+u0PvjBpOZphCBcIFa29BHmC5h5iWZHqsnFDxHhtKHBxG1+4/7ont+0F2x/k6JRCUK1NzhWeAXE30EWF/v1nm1v792LDf6p/XXAErNjlIErOBP5xsjIDS9XeyaVQxAuaqaS6iXV9mYhCI21T7WgrzZBIMj8c3Yi+JgPvj5UC7hKyhGCKIGeGgghy4wTsARE77WFdFDvVT8O0J0MWr37Lua95XiD5h5LCRnHM1ufBdH7HLvkyaiejUwQBQiVeiEUMXsZ3AvQOwHMy/+mTlbPAnw/YFzdErZuHxhI/KuMgUsLOnvfHWY+lgn7g/B2mzxydRDwIAjXjrXwL3yc4spowkSWcggil6/opTk8gix3Dw8n/u7VmGYhiCJcyka4KGPVCSInD5/zz60btV4fqgdfeSU1PEGU1y3JJQgIAoKAIFApAkIQlSIo+QUBQUAQmKEICEHMUMFKtwQBQUAQqBQBIYhKEZT8goAgIAjMUASEIGaoYKVbgoAgIAhUioAQRKUISn5BQBAQBGYoAkIQM1Sw0i1BQBAQBCpFQAiiUgQlvyAgCAgCMxQBIYgZKljpliAgCAgClSIgBFEpgpJfEBAEBIEZioAQxAwVrHRLEBAEBIFKERCCqBRByS8ICAKCwAxFQAhihgpWuiUICAKCQKUICEFUiqDkFwQEAUFghiIgBDFDBSvdEgQEAUGgUgSEICpFUPILAoKAIDBDERCCmKGClW4JAoKAIFApAkIQlSIo+QUBQUAQmKEICEHMUMFKtwQBQUAQqBQBIYhKEZT8goAgIAjMUASEIGaoYKVbgoAgIAhUioAQRKUISn5BQBAQBGYoAkIQM1Sw0i1BQBAQBCpFQAiiUgQlvyAgCAgCMxQBIYgZKljpliAgCAgClSIgBFEpgpJ/WhCIxRbvkuXwIIB3FhrAwKHpZP8vnA1q7YzPN0B3Adgh/9sLFnjfkWRi47Q0XioVBJoEASEID0FFo/GtYOAEEMaHk4nLm0Sms6KZQhCzQszSyWlGQAhCI4B4PB76+7PGwczW/wPofUw4PT3Y/71plpVUb0NACEKGgyBQewSEIDQYR2M9l4Fx4qTqQgii9iMxYA1CEAEBk+SCQBkICEHoCeIaMI4VgihjRNUpixBEnYCWamY1AkIQQhBNOQGEIJpSbNLoJkNACEIIosmG7ERzhSCaUmzS6CZDQAhCCKLJhqwQRFMKTBrdlAgIQQhBNOXAlRNEU4pNGt1kCDQ1Qcyf//lIeO4LrSEYJzBxDMDbAIRzMiA8D8bjxLgjS7RqQ7LvLwBYJ5/u7vgbxjJ0Cwh7+5IfYdXwYP9xXmmVqeyTz4Q+QWQdB8a+xW3jPxOoz8yE+kZGVj/nq14AbbGerxLj/EJ6u3NYa+tR21Jk/LPEOBpE7wOwFQATjCdh4FcW+L9HBhN/csPBbxsCpqO27qVvQ9ZcbIAOYGBPADsDCOXLMQE8S8CDzNxnZrI3b9jw8+dL1dHIBNHaumxeKGL2MrgXRO8F4035/mQBPA1gBKBES9i6fWAg8a9SfXX7fcGCw98UioQPA+EzjnpGATwO0J0WWZcHkbnX+FLzLbLViwcQ+CSAPg5gXr5trwB4mME3WuPZVX7k5+zT/H3i27WM0SFgfJqBD9vKLmt8lIGZks0TxDRowroqu3mHkY0bL8/4kU3RWGTc3RLhRQMDiVfbu3pibOFcAK35tUnN9buZcMnuO3M6kUio/jXs16wEQW0d8R4i+gGAt/hBl4E0E58wMph40Jm+mgSRI4anaQlRblBMevl6tDFLRDdliFbcs37Nk6X64jKB10U7ew8C+KcA3uxVhsLBAh27Idn3cKm6KvydJiYH/wCgTwQoK0uMy8xs5KyRkRtedsvXiASxV3d854hp/IiZl0xuVLw7/gqIv4MsLh4eTqhF3denNgKhcOYcJpzkpx6vse+s0I0gorH4J8H4sfILKtHILJguhGWd7adPubln0nfA+EJ+Q1MKA1/jw1nIXl1Ldw9Z1rcJOMYPZgD+DmDFbrtwf6lFXEcQZibTE2qJfA2MU22bIXuzxhk4KJ3s/3WpDk/n701HEGoBfupprADROS7Ae+E5ysRfTA8mVtl30dUiCFXO5iytJODTZbTtaTL4mKH1ibu9OlA0gZkXqYlFRFf7nGCq+BeI+JihwcQvazH41E5zztYvnusxOUpWy8D/GFZ20dDQ2id0iRuNIKLR+LsQolswcUIK+PFANoxl9wwkni2Vsb29dy82sAbgd5RK6/hdEdCK4WT/pV4nSN34IqLdAVwQYHyBCbdlWvjIjb9OvOTWzmg0/m8IUR+AfQL2RakCHoZBh6XX96kTsefX3hXfmy26DsCupdI6fjcZuHZumE/2OukVj0UeYBgpAn/NfR3gofG5+JQXPgHbWpPkTUcQ7bGeJcxQwlbqk8KXU6MwIU2giV0n8YfA+KhmUL/AMA5MJ9eMFDJ3dx83dyzz2nIQvXvib9a/A4V/5/6wAaD7Jmtja8NwKnGVXSK5I/JmSjBy6iTn9wqpEwzoMRC3AOgAYw/N4HmFmY5Lp/rWuklbs8M7n4DP2+IMKUXa4zDwOzCNAdZHAJqv2TVtAvEhw4OJDVUeWRSNxU8D03lF/cup/fjPgPFAXkYtYG4F6F26XR0xrpwT2XTSwMCAOv5P+RqJIDxk/wrA/1voL4O3JaATwG7O/jBwdWZ0+y94qTWisfgCMKlYUzs58mcBfgREIxMy5zeD0GVTbW2ZJ8RfHx5MfN+NJJzjC8BqAIfZ5pEJwmMAUqouAu/BQBuANxb1ycPBNLeJ2OqliwFWY9f+jYL5IZDx+5x61HO+8MD4XBzmtci6rBeqviD98CQ7zVhUKjc1z+fkOlaYj7mlBZ8E4e0Alg8n+y+p8tyrenFNRRA5neucyJ0AlP4z//GAaeAzG9Yn1KCd8uV39P9JwFlTFyC6sSX83LG6hUcVEI31BHKU6+7uDo9n563knG52yvc0M/3H7rtatziPqbkjr2ldSJSbfAV9vMq8CYZxwPD6NX/QSVszgW3J+CEy8KWh9Ynf2heAHG4tkR9A3U1MresBK5w9cGRg7VPVGlmawHiKrR+12Drxrbvibt1xXalMjEj26wCf5iCKTWTRwqGhvglCsX2NRBDRjvgJIPqJDdtRIpwy9tr212gWfIp2Lf0oLOtaAB+0dellsviAoaHEsE4W7e2L38ZG+DbHCSWnbslmMt926v3VSftvT2Nvg4wfO04bo8y8NJ1K3BpwfJnMuNkK8QrnXMvFLAtjBZi+4ZDfA1YmtI/ujq2tc2k3wVL9KWz01G79vLlhPl+3W1/QFd8jbNFPHBswk4iOHhrsW6PrS7Rr6cdgWb9yEKpJhDUhZFcMDq59xp4vp514hnpe32xd5FTVEuiyOeHnTva7WcmXO0rA196yC19iG/fU2blkD9M0XhweTvxfteZdrcppKoJo6+zZhwClFplgZsB1ANoAo2hH/HRQbkdb+J5hgxa6HU+DEkRrR3xfg3LqBduphkessHlEicWXop09Xyw6vjPfAgvLdDpcd4LwVlO4qeYI+PZQsv9bVRpgFI31rgTzclt5f4PJC4eHE4+UqIPaYvFjielKO4kx09HpVN8NjUoQudNn9tUEQAfb2lhyd9jWvfTtyFp3EPCeQj4GVqaT/ac4+5rbgGR2uowJn7X9phb649OpRL+Xykjdi4Sz6hRA3bZ60tZ45mDdZbLL+DLBfNZuu+ICD3287uRoMvNiHRm1dfZcRMDJk/0hunh4sE/9X2tIotKpk9qczbjZ3heA17WEt4kPDFyz2Y5bPtDmahApFWzh86Vma+1evJuRDf0MIHWxPJnXYl40kkqoqMBTPt1mJZeA+evDqYQyKHHtU5XmXc2KaS6CiPWcSowfbhlUpa2JVFplVWJETHUZNLljc1t4VPogBKEm71h23iqAjyxjUVRZqK2z57/yp5ySg1E3gXP62LCxf3pgzeNeIyVvhfITAo63pfNDsr4G4PzuZTvOyWZ/A5CyQil8JRfLQsLOziN3MJG53T4xmXBmerBfXfiXnJTTEe5bjS2KmOttC73vUOLRzp4vAbh4S8d4JITIgcnkjS/YO9ve3vtBNvg3tp2wUr14qors+fP3Iyr/W/N/d915awnCY8Nir0c7zzTy+/B+x2zzhtfGfm4/DbjJzin3aGf8ACC3GcttEhl4MgyzO5m86dGpmMWjbJA6PWxb+DsD56ST/d/0s2BrMFMLvnbj5kIQj5kGL9RpNnxNpgZJ1GwEMcXEE0CiJbzpSDdVkQ1jtVO/BsBCgJ/g3H2Cca39HmLKhAqgYmrr6n0/WbnJu0s5i6IrgQFXp5P9JzgHs8sOz/cirFEBue7ygo5RdelIIfoiT6gAPwqCGWJzf+fk9SrXSc5wMSluFBWTph2vWswHjKQSyVL4TVw4s1ooXwXwewO4j01e6Tw5tnf2fIuBs20LnesJwK1OZxluO2/N+PI9PiY2SzvdCCA+2Q6N/HRGIV4btikkNLG7vwsgpeO/j0EPRsi6aHAw8Q97uqITij9twxT4igkcWvJ3IQi/a1OpYTKtvzcXQXT0Libim2yIaa2SKkU0yAmiraP3KCK+3jZ5tTuaUm1q7+j5LhPOsO0m7x8PhxduHFj9zykD3+EHASDQTkWnEnFTbZRqcy1+bzaC6Og49I0WzVUXx5+0yc63VVIpDLWLaRnRhVs74p0G5XbU23jtvDVGEIHGc9E41hM8tXX0XEuUuxPLfUGskkphpjuJEuPcoVT/maXy2n/v7FzyjixCAwQoK658Q+nE4VSfum+a/LSbFZeTb5D6GyFtUxGEuqgKWaR268oCqPCZAP9B2Whb2fC6IE5nbgIIQhDtHT1XTNUN63WipYStuV/R7lY0O7zAO5W2WM8ZxPhuoU0E3PWvrVsOv//O69ROdlq/ZiMIBVbx7jwH4YsgrDEsWrV583Yb/TpdOcHXLFImMx2STvXdHkRQE3r18Hrb3NHa4WvG1+8M3nxIKnWrsswp+RXldzkBtsd6lzLnNlZ2A41RBm553TJqVUt4mwHnvULJyvMJ2tvjH4VBdzGwY/5PZfkcaO+XNP0Jcpr124dGSddUBOGir3di+RQI65hx09zw1slyBplfgqjmbly3W9HpZYt2eGXsVNo6ew4hwG7F8tcwZWNOq446DVLq6Fi6CxvW3sw4Kr8T33LZ3+AqJoWRVl89FbxREO6DRas4QnekB9Yo3w5fF5fOnT+AcaUeAowpJ8tSsmLmrYlw6BSdvMYAwDm+gm4e/BKEsqwz5kTW0YSJrO7LMvBHYvRxiG7efZ71cCmHtUIhms2Wp1GKF3ZFJ6ItXtKTHvCVqBlLyW26f282gshZMkTG6EZifMoHeMo+fCMYV/gN4ZCb8D7vIKp1/Fd1+t2FFDsy0RIvvwkdRn7VDT7w9Z1EYfVa1tg1RLwnwO9mpo+/bpG215QQJLrSmoAgVLPbJtSf6p6ryB9A061NIKxlNq7ZfRfzXq+FT0PmvjEvlVD3UqLfBd6t7CD5OzqWfsIiS104+3FgUyeYdWTRNWNj2/3W60RWzQ1QUX/8EYRvQ4VSMpru35uOIPI7NmV3vTxvd+1nQqpsKuZJmmH8Zzq5RjmHue7gGoYgNLpmr1g5fgeT5qK6FgOaWmPx9xPTabmd65Z4RH6bOZGuSQhCNbU1Ft+TmK7y2BXr+v4iAT8wM5GVutAiM5kgFBge/kBe40SZq/40TNnv6k69NSUIoOi0rdnc1WI+BZs3VUrdlARR6HvOEc7EEcQ4LR8jxq7PdIMoq2z/x0a3P99tF9IwBOFDBeDXPNAORq0JosxJr5q4KUcJ9nhSTUQQeYy3ECNwhM8Thcr6ABvU4/TNmekEURiX+VhJp+RjJTk9xd3msjY8TW0JotgUWQiiSmxUy2JyqqfN1EXAMhD2K7FjNRn81XQyscWnwta4hiEI4NB0sl9ZyEx+1ThBaHS0VbuDmPBe5Z/5iBX0HMB/JVDSYhrIRIx7lMVWM15Su43rXODG54z3kMmHMaGXgA+UCBRX5NlezcXOz/wLoiLSlVdp/tw9Y/fSt1GG94fBx7qEy7FXXRR5oJqYiYrJz6hpvjS5i08L5oEgfM4lFpGrg5h/gij2oi3XZFTjT6G1VtFcUn8lPdh/YRAR5fXlNnNh1prUBilTpdV7uuZK+TsD1wPGrzJhemDjwGoVzlur4ptJBOHEL2fUYG3+ONg6BozFmphKKssUn5a2jt4DiVhtEnKnYwL+CYv3HRpKbIkNFlRQHukrXeArze9smnLunDv3+feYFDqGGL35OEZTkzm8sKt5Se30p9Bd2ssJoooDcDqKUsfXsGVeO9VFH67mgn4JQvXFzwDy02e/C4HmBKENz+BVp8bnQhuuwE+77Wk0posqINoVyPJX/IR+VmXNZIKwY5UPfXIciP7bHqLFuQBpTDZ9O64FlV9uPDv9bHy8fWKvp9L8JdpM0ViP0g6oOFaTaijlQ8GZUFfBxN3vZqsUPjqPbxVAcijV/zl7XiGIUkjW4feJ0MCGinfTBVjKNC4UgnWQXy/d1q4l7zaskApiN/l+hM6KQ7dIuaXLTahpd5QLFja4mpZXdrHrvGhzb0+4xPzRDRmt01mD30G0dS5tJTY/RURR9RiSisqaTvaroHV+PhVm5TwCTrclnqLu04Yv8RG3yFm5CtdhGXzb6yFdVGTc+wj4CzFfkkol/lbNBd4PQeQWcLYOBlNUHTwZGJob3nSMj4gIuaa2xeLHEefC2xe+KZfCDeAoJ5fUfkZ/NdNEo/G3IEwDYKjQ0OoLtJMKsjAGOkFoQm14EYoOk4kTjnUHgPcXfs8vNH5CbXhGAS1eKIpi1ATK7yZTbRwll+BzbmVoYg41vBWTHx211zzwoS+vJABioWpdvC+tb4CfBd6zPz5OIG0d8UOJSIW0nzAqITyCLHcPDyfUIz0lPz9GFppQG3/KGsb+fh7lKjRA4zToN9SGEERJKVY5gW6HSkR9Y69td4wfL1UNwYBZ70MQhCBqFKxPOUMtGk4mVGiEKV8lwdT0ES75dphY4lcF5CZW3U5Xdxx3zT//85GWrV+6jpl7p6Rp8BOExpHtZYONg1OpNYN+poAfz2V9tGC6fHx0u+W+xr427DWvbQlvc5TTkbQeBKHzDifCcUOD/ZMhazxJyEkwwGNWONtlj5zc3l6DYH3QzxVRMfkZ6XVIo9dx+4pqWRTy2y0KpOqGkyBKxXHRTeBSL6Ll4dKH+wbuaAnzEbq4+C7B+kwCzhkb3f67bguGyytv48y0LKijnU7ULhE6fUWZnXhPgH4IVgYFU0IvgBnXp1P96oW+KZfafh0LVVv97DjLHb75i/nbXn//ud1WxoNkZT/l9hre5A5VE/JbN9ZcQleXlHluLOtfbRt1C11dD4Jw2VT5esDKxRCiKNyMC2ZZBp+eTiaUUYerH5RbuG+3dzSEIMqdPVXO5+Ke7/poSm5xaD1qW4pklJ5XvXm7xU+C8KPhwf6v6AaK5nj6IExe5PamgceDQSrC5Cm6d23VoDIRvoAZS4seDPJ46c2FIFRXcw+6mCHjVOcxOq/CWpl/GWxSKkFOYH5EqY9JxPdahGN1b4HnSesgMJ/n+taxxnNVtaVRCEK1pT3WczQzlBe1zQ+HH7IYJ7s8kkTtXfF/Z8u4wmEO/LTB5n6p1E1/dOLt8viNGr7rDMZpqVTiz448+TpwSTG27qePehCEamdHx9KYRdY6e+gPAP9gplMzm7fr1210lCOiwVjleOPclezcHgxymycT78kbi4hYGQ44vLvdMROC8LM61CmN/ridq3zqs4vqqUL35yw9d3jRjt4vgPjHji6py72nAVKEtH5OZKuT7MfzKj05ql4iO2ZosN8esbaUiikDwLAtThMxbED3TmRUF/q5h+adToS+drlBxOoRk8j5JGwIbH0clGvX1Kdj1dsWwDttj0Jpg8U1EkG47FYnoCM8T4zf556bzf2X92DCx8t5DtTj+UxV9FMMJNWTu/mnTffWmtEShsPILnGLu1UvglBQRGM96tT4Zc0Ym/JUa+4JVUCd0OYVp/VWtVXjyVFlWTY2l+NuT5sKQQRZJWqftvDymHp83b64+K1Z67Fqz9zRseQDFoXU06YuMWL0D7tMHH/pMgDq2UI/Xt32atXu6dhSUTo1J4jVBHqRJ9729Vmnr9fu/OI5lcCCxSSy532FiVQ45pTBfIctEmeRfrnRThCqPbqX2wIAWNK7v1BWeyx+EDOpN9l3CFB+PmlpudeRIJAzHMkal77uMHlM8L5APVF67dwwn6xTxdrLy5uQr3I+I+qjThWep398Lp/k9e61EIQPJOudJP/Yyk8d7/p6NUOFEr6CM5Fv6GLeODJ6kpDX/YXtXdsL7Ca1Hg3LEuiKsbDxTefbD7o8ugm82858wpPPGl8kZhXC2ys21Ssg/g6yuLjSS2kvoKOx+CdV+HVXtdHUzOrEc51pGGcr1ZjmsltrrdZIJ4hCd9RJgkN0dv4pTb+blwfI4FOc74h74atUhhHmC5h5SQnP7EIxvuVeT4JQjcvPlxNf78c5ALb3uY4oa6cVOtWtW/7gmPFDRDhtaDCh3s32jLwrBOFTatOQjBZ09r47zHwsE/bPeVluCQqn2P9ZAh4E4dqxFv6F1y5A1/YJnSedBUAd1+3H25Kvhin9ekvLS/8OwjImjjmilj5HwP3M3Bckyqxqo9cEVgM1w5EvEXEvOPdmhjpRTBzXGT+1snMSPsixKmLMP296QD62jlIP7Gw74Xj1v8isU3dX0ogEUQAuvzM+EGD1spp611idRMP535U8/gYYv4ZhXbXbPDzoN4y1UzDqic9QxOxlKMsvUmq5whjNjX2A7weMq1vC1u2ldtmFsutNEIV6p84XqwOg3WwaglGAnyI2Uiasq7KbdxjxY72lG8gTMZ/MOAFLQPRe23qhAgA+/rqxwZ0MWl0qyq69bCGIqiwZUkg1EKh0AlejDVKGICAIzA4Emjqa6+wQ0dReCkHMRqlLnwWB6UFACGJ6cC+7ViGIsqGTjIKAIBAQASGIgIBNd3IhiOmWgNQvCMweBIQgmkzWQhBNJjBpriDQxAgIQTSZ8IQgmkxg0lxBoIkREIJoMuEJQTSZwKS5gkATIyAE0WTCE4JoMoFJcwWBJkZACKLJhCcE0WQCk+YKAk2MgBBEkwlPCKLJBCbNFQSaGAEhiCYWnjRdEBAEBIFaIiAEUUt0pWxBQBAQBJoYASGIJhaeNF0QEAQEgVoiIARRS3SlbEFAEBAEmhgBIYgmFp40XRAQBASBWiIgBFFLdKVsQUAQEASaGAEhiCYWnjRdEBAEBIFaIiAEUUt0pWxBQBAQBJoYASGIJhaeNF0QEAQEgVoiIARRS3SlbEFAEBAEmhgBIYgmFp40XRAQBASBWiIgBFFLdGdp2a2d8fkG6C4AO+QheMEC7zuSTGx0QhKN9VwDxrGTfyesGlYfS0YAABFYSURBVB7sP26WQufa7e7u+BvGMnQLCHsXEjFwaDrZ/wvBShCoFQJCELVCdhaXKwQRTPitsfieIYtONbOhs0ZGVj+nyy0EEQxTSV0dBIQgqoOjlGJDQAjC33CIxRbvYnLkGwz+HIAnwpSNDQ6ufUYIwh9+kqr2CAhB1B7jWVeDEERpkXd29n7EBN8BYF4+9V+FIErjJinqi4AQRH3xnhW1CUGUFrMGIyGI0rBJijojIARRZ8BnQ3VCEKWlHJQgSpcoKQSB6iMgBFF9TGd9iUIQpYeAEERpjCTF9CMgBDH9MphxLRCCKC1SIYjSGEmK6UdACGL6ZTDjWiAEUVqkQhClMZIU04+AEMT0y8CzBQsWHP6mUCR8GBH1MvBhm9XLKIDHAbrTIuvykcHEnwBw0O4UygfhMyB6LxhvypeRVaaXxDRowroqu3mHkY0bL8/4Kb+eBJHzD8gaBwLW8QB93IbPZPstg6/cfWdOJxIJ00/73dLs1bV095BlxglY4sDqFQAPg/mX2VDoynvWr3lSV0ZbZ88hBNzqsw1TnAur4Qeh2h9mcymYegG8B8Ab822ZHEswrKt2m4cH/WLVFuv5KjHOL/TJ7rw3f/7nI5GtXjyAwCc5ZJPDi8E3WuPZVRs2/Px5n5hIsjojIARRZ8D9VtfaetS2FMl8hwBlI79ViXwmwIMcDh2fHljzuJ86JhY769sEHAMg7CPP3wGs2G0X7i+1eNSDIKLR+FYIYzmYvmFb6Dy6wQ+RgS8NrU/8NiiRKqwizBcw8xIfWGUB6odp/cfwcOL/7A2aLoJQjngG0w8B7AMg5EPWD5DBp/jByo0gorH4J8H4MUDvK1FfFkwXwrLOHh5OKKKSr4EQEIJoIGEUmtLeHo+yQT8DsGvA5m1i4Kh0sv/XXvnau+J7s0XXlVG+ycC1c8N88sBA4l9uddSaINq6l76dsuYagFoD4mOCcOH4a9uf4fM0RNHO3iMAvsofCW1pDasThUGHpdf3qZNd7psGglDtPwbgi4O2H0CWgG+PjW5/vhdWRQTBvIiIdgdwgY+NzSRgTLgt08JHbvx14qWAMpXkNURACKKG4JZTdDQWXwAmFV9nJ0d+tbg9BiAFpjEC78FAm2bib4JhHDC8fs0fdPW3x3qWMEORg/NU4rd8lJrMtSSI9vbFb2MjfBuAPYvwYTzJhDSBXmbwtgR0AtitGAe6fHx0u+WlSMIDqywDfyTQvQBMEH8IjI9qMH3ACmcPHBlY+5RqQ7Rr6cdg8YkT7bF2BOhgAHPy7XuZGbcS0Wv5/49ymH5UOBGWoWKiaCx+GpjO05wa/LbfJNDlY6PbneKGlZMgAKwGcJgNiyDj6vT0YP/3ypk3kqc2CAhB1AbXskpt7V68m5EN3w7gg7YCTGbcbIV4xYb1CUUQk19u0TDpbDC+PEX1wXwLLCxzHtknFijrVw7yMYmwJoTsCmeYh3g8HnrqGep5PejeRQDebK+bQJfNCT938sDAgNL1T/lqRRDz94lv17KZEgzs6wcfqCNGbNmHDM5eBdAnpuQBfzWdTCi1i/ZzwSpLjMuymcy3nXrz9vbDd0JozkpmPmLKgkz40fBg/1ecaq2gl9RBCaKtI34oEa1xkJZSf33fyoTPGxm54WV7xz1UdiZ7YKUhiEKxruM2X9eKvHrQrt58wMqE9nGLR1XWpJJMFSEgBFERfNXN3N7Z8y0GzrYvZGA+a7ddcYGH3l+3UxwHeNFwMqHIIPflJqWB1SBaZCtf6XxXDCf7L/XSy08QV+hnDpXOqMW8aCSVUFFb60IQmsXI9IEP8hfZlwKs7lsK399g8sLh4cQjzvZ3d3eHx7LzVgF8pB0rZj4+nUr0u2GlLmXnbPXSxQB/3pZvE1m0cGio7wF7PbUkCEVWlhG5k4CP2Op8gYiPGRpM/NJr1OZPOT8D+B22dE8bbO6XSt30R2deF4LwIxfduDWZeXE6lfB7kV/dCSilFSEgBNEgg6K1ddk8I2Kqu4PJ0wMDV2dGt/9CKVWIbncJ0I0t4eeOLezw8/caijC2LXSZgXPSyf5v+rm0jUbj70KIfgPgrZOQuZxUanGC0OED+FMVqfYqay1jTmQdTajlcp/SsQ8l+7/lHALt7b0fZINVX7eo+Zi/PpxKKGsdT0uxnKWQZakYS+/3qqemBBHrXcrM19tOMuqUeNzQYL/6W8mvo2NpzCJrnX2swOUkpCUIl3HhrFg75glnpgf7zy3ZSElQFwSEIOoCc+lK8iqBtbZJ7fqGgq60dseioC5JORPqKhzX2zp7LiLgZFvewMf5aGfPlwCoC8/Cp21jLQjC2T8AricAN7SLy+D7x8PhhRsHVv/Tnkez6P0paxj7u5mvFhGM4yRIwF3/2rrl8PvvvO7VQtpaEUR393Fzx7KvJvL3G/nq+HaYWBLASoiisd6VYF4+2TfCI8hy9/BwQlmzTX66U53fU8DESW2nGwHEbfXIeyCll4u6pRCCqBvU3hUVL+DBJnVn55J3mDCU+sAE0b0EpDjLNylTy87OI3cwkbndriIixrlDqf4zg3Rf1ZFFaIAAZaUy8TGdOJzq+4m9nBoQBLV19lxFwPGT1QJXp5P9J5Ta0dvbpWn/qxbzASOpRLKQTrvAEl08PNinyNWXn0lrR7yTiG4kYBOAe4logLPWLfYFulYEoZMRMx2dTvXdEETWqg8GkTpxbpPPN87AQU4LOY2Z65NhmN3J5E2P+qmvvaPnu0w4QwjCD1r1TyMEUX/Mi2r88H7HbPOG18Z+br985Soetdvb4x+FQXcxsKPXZC8FhX7xLH4BrtoEoSM4JnwlPdh/Yak223/v6Dj0jRbNVRZin3QjOKX2oIi5niYcySY4kGlJOtWnTndV+2pFEG0dvQcSsepjwd/hGTZood3c1k8n5ncv23FONvsbgJRzZn4vgCIrI80J4ncGbz4klbpVOcOV/Iryy4uCJTGrZwIhiHqi7VKXejgmy+FBAO+sxaLU1tmzDwHqdFEwqSxr0VBtK9rxMe5uifAiu19E9QlCc3IB7gDoiSDiY3CEgP3t/h/Ok5Sm7S+SRfsNDfXdE6SuUmlrRRDRjt4vgPjHW+rXq9FKtc+v+se5wOvUaV51CUGUksT0/i4EMb3452rPm7euB7BHvjkmMx2STvUpk9eKP42DlufbA4EmdB0IQrOYVozJZAGOHWt7e+9ebPCdALZXaQj4Jyzed2gocV/1KgVqRRBFC65GPn774ee98EoX+Erz++2LpCsPASGI8nCraq4gO+5yKq4pQQBFZBOkP34WoXoSRDWx8pJVUxKEhmwqXeArzV/OfJA8/hEQgvCPVc1SBllQy2lENRe9Yp0zj4QQOTCZvPGFQtuC9EcIAjvkcavKi3I1PUEAiZbwpiPtzpGVLvCV5i9nPkge/wgIQfjHqmYpNZYnomKyoR2EcCoVktN6R1RMONZNHaf+XukCX2n+SuUt+b0REIJogBHSTJfUTnNcnzb+rj4dfk4QGiusqhKofQjIJfUEGjqLNWJcOZTqV9GFJ79KF/hK8zfA9J3RTRCCaADx6swvyzFzbevs+SkB+wH8BIPuA4xr08k1I21dve8nK+cZvEu+u2UtsDpzXN2iEWTH74cgtKanVGxyWQ1RagwGApu5Ks/28SytZeC9BPzZAv4UhnmR3TegZncQDou1ck9ALpgXmRZXusBXmr8aMpcy3BEQgmiQ0dHe0XMFEz67pTm8riW8TXxg4JrNfpqo9RXIO0g1u6NclbyDkV/07iBgh8LCbVh8td1CSeuTAqxMJ/tP8SMHlcaPQ16tCGK6HeUQ0I9BCMLvqJqedEIQ04N7Ua2aUBLaIG9uzdXEWpri66AJtREofIRW3wzULdSGJszHywYbB6dSa5T/iK+vPdZzNDOusTmRab2DNUETA4Ul8RPSo1YEoSXTgKauygdiPLPTZVM2LH5DbQhB+BqLzZJICKJBJLWgK75HyMoFwyv4Qqi4Dj6D9WkmNKaG6qhJsD5HHQUoq61iUuV2dCz5gEUh5Z8w+YiSuv8Ym8txP4/MuIRS/705ntmvOHR37sGmKYEN4TNYnzZwoiZUR60IQmGl2WxUIVifPtxIpSeASvM3yPSdsc0Qgmgg0WrDfRN/fXgw8X2POEDU1hHvIaKrbbH/x5lpmT08hEu47yyDT08nEypkhWucIbdw38y8VBeauRYEoXzWorGeH+bfvrBJja5rCVtf9HrhTvWdDFo5VYUH9V7B8nSq3+Z1PFGsW7hvIhwzNNh/k9uQyb2f8TRWgOicUkEXnRgx4BnDKMh7EC7hvl9hpuNKhQxxCfft+ghVpQt8pfkbaPrOyKYIQTSQWF0mtnrm8yfWeOabzp2uWjQ2Z+k/CTirkgeD1INEZsg41RmtVC14Tz5tLCLi/y5+ntQ91HaNCKLgce58UElx272M0PJ0cs2Good5YvE9iUkF+psM861EXur0oTuxABgF83+1RHCxk5BUOPFQS+QHYBzt58EgneGA19sWQQgipw50eTBIPXhkZiNn6R4MopBxPIP/n+OVQvVinusmpdIFvtL8DTR9Z2RThCAaTKweT476fSbyQbKynxoaWquNU1SNJ0dLLa61IgglKg981Kr/PBjrAfoHiFtg4ZMgvL1YxPQoDOuw4fWJ//USvwdWoyDcByaVP8TgTxDwgSkkXYKEdMHwcm3J9YFeYnA2xMZnC3csQQli4sRV8ZOjqhjP51krXeArzd9g03fGNUcIogFF6nLML9lS9QYEDDqsVOTOfMTPVc5nREtWoEKJA/3jc/kkL71/LQkiRxITbzs7Xz3z0fzcCvwoDDrC7c1uZyHtsfhBzKTe8C54PPushweyYSy7ZyDxrEsGF5XZltT2MN1lEESus+2dvSdpTgV++qA2JD/IjG7/Da8Hqypd4CvN76cjkqZ8BIQgyseupjlbW4/aNhTOnMOEk5w7U03FubeSdaoDt0aql88izBcw8xIf5SvNzUNEOG1oMHFbqXcRak0Qqk8KH4pkvkOActzayocwAmNUKFNhFTKtC4lw2BT1kb7SV0D8HWRxcakHevbqju8czmI1QN26ouyRZsskiFyxrbH4ngbT5Urz5KP96jIqHWLjP1KpNfeWwrXSBb7S/KXaJ79XhoAQRGX41Ty30m2H50SOYnAviN4LxpvylSp9+EMAfpENha70+9qZs8G5xc8y4wQsKSofePz1TeidDFq9+y7mvR7vYk8pth4EUahw/j7x7VrG6BAwPs3AngB2ti2Cz73+DvVfwfipmcne7LzDCSq83HOipvlZEB2Eifci3pgv4xWA/5dAfdnxzA1B6sldoCvdP1uq3Pc5yG4y9lElBJFvIy3o7H13mPlYplzIc0f78TAx7sgSrdqQ7PtLqU1AAbtKF/hK8weVoaQPhoAQRDC8JLUgIAgIArMGASGIWSNq6aggIAgIAsEQEIIIhpekFgQEAUFg1iAgBDFrRC0dFQQEAUEgGAJCEMHwktSCgCAgCMwaBIQgZo2opaOCgCAgCARDQAgiGF6SWhAQBASBWYOAEMSsEbV0VBAQBASBYAgIQQTDS1ILAoKAIDBrEBCCmDWilo4KAoKAIBAMASGIYHhJakFAEBAEZg0CQhCzRtTSUUFAEBAEgiEgBBEML0ktCAgCgsCsQUAIYtaIWjoqCAgCgkAwBIQgguElqQUBQUAQmDUICEHMGlFLRwUBQUAQCIaAEEQwvCS1ICAICAKzBgEhiFkjaumoICAICALBEBCCCIaXpBYEBAFBYNYgIAQxa0QtHRUEBAFBIBgCQhDB8JLUgoAgIAjMGgSEIGaNqKWjgoAgIAgEQ0AIIhhekloQEAQEgVmDgBDErBG1dFQQEAQEgWAICEEEw0tSCwKCgCAwaxAQgpg1opaOCgKCgCAQDAEhiGB4SWpBQBAQBGYNAkIQs0bU0lFBQBAQBIIh8P8B94GApsa48RAAAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-6"><g><path d="M 211 251 L 211 276 L 51 276 L 51 294.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 299.88 L 47.5 292.88 L 51 294.63 L 54.5 292.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-37"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 292px; margin-left: 132px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="125.5" y="286" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-9"><g><path d="M 336.61 21 L 375.39 21 C 392.29 21 406 34.43 406 51 C 406 67.57 392.29 81 375.39 81 L 336.61 81 C 319.71 81 306 67.57 306 51 C 306 34.43 319.71 21 336.61 21 Z" fill="#f27979" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 51px; margin-left: 307px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Abort suspend; details logged in dmesg</div></div></div></foreignObject><image x="307" y="30" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXt8XFW1/3edmTQFlMdVeQmKr6ugcrkUmkwmiUGeBaHQMknLW1FAqCgIchW86hVU5CrCBQrigxaEJkN5aOUhyI3Na1KocqUiKoIK8ijyK6VCmmTmrB/7zEx65sw+5+wzSabJZJ1/+mlmP7/78d1r7b3WIsgnCAgCgoAgIAhoECBBRRAQBAQBQUAQ0CEgBCHzQhAQBAQBQUCLgBCETAxBQBAQBAQBIQiZA4KAICAICALmCIgEYY6VpBQEBAFBYEYhIAQxo4ZbOisICAKCgDkCQhDmWElKQUAQEARmFAJCEDNquKWzgoAgIAiYIzCtCaKpuf2rDHyltLt0a338xVO7u7uz5jCUpmxsbj+agJ+O/ZXxUH0dz+/uTv+z0jIlnyAgCNQeAo0t7V8gxuVjPSMsG+jpOq1WejptCaKhYfEuVl3uQQAf8gzGerLp4P7+znWVDpIQRDhyB7Yu2jPO9vmU42X9/elHw3NICkGg9hAQgpiiY5poTh0B0N0AZnmbSMDX+nu7vlpp04Ug/JFraDhxe2vWyOfAdAGArA0+dLA3vbZSrCWfIDCdERCCmIKj19bWFh/O7rIM4BMKzRsFYAGIFf6/zh6NHTI4eNuLlTRfCEKPWlPTcTuzVfe/APYppNggBFHJDJM8tYKAEMQUHMnm5oXvziLWTcCe+ebxL/P/0sGF5uaI6KT+ns4VlTRfCEKPWkvLgt2yHO8B8B4hiEpmluSpNQSEIKbgiCaa288BcE2xacT4hm1hY8llESq/rBaCEIKYgtNemjQFERCCmGKDkkiktkEMKwGaV5QWmHkBE/5ugR4AsFPh7xVfVgtBCEFMsWkvzZmiCAhBTLGBaWpKJdii+wBs7yiXgGfiyLXF49b64VG6G4SPjkkWFV5WC0EIQUyxaS/NmaIICEFMsYFpSrZfxoQvbWkWr6qPb5fq7r5pc9lgARVdVgtBCEFMsWkvzZmiCAhBTKGB0do+MJ010Nd5g2pmU1PHh9hyLqx3LqqfKrmsDiKIOXPOqKvfdsN8ZpwH0IcBvBlADoxnCNRtW/yDPXflTDqdzlUKnVNH/caD2GJlcNMKYFfXC60XCfgtCMuH6/lnax9MbzSpp60t9SaPhPXnOGVbenrueL6hJbWP5Rj7OJf824DwMpjXMGgpYK0n2Pe6VHeB1TFwTKa362cmbTJNo8Y9VpfrYHAHiN4PxlsKeZUx5HMABgFK18fte02MGRuaU3M86shIr7Eqza/GNT57Q0MM1ulM3ALgnQDiTl8czPEXYtyfJVq2prfzT3kBOfjzblBu/NWTZKob+SQxTgLRB5yxLcxVWLjPBv/PYE/69yb1+LXCmVdZax5gfxyg/QHs4hqbvxJTT9Q1UfYYwmOoqmxwYjafSeAFAPYa6xfwAoDVTLh2PGswb+OTWwQbi124ZRn4HcDLeXTWDwYHf/Kq6qcQRNgMreLvjcnUMUR0h2uzLLln0NxPqLk/JmGYNtWPIEZGrL3ZspcDzmIL+taBeMlAT/pXpnWqdE77LZwOov8E8DaDvEMM3MijdV8uTtjAhVyqgvszcvwRxOhYAFcUFllZdvUAgAmf3hoEcWBbate6nPU9Zl44tpEGg7IJxF9HFtcMDKSH/JJWusEXy6sgPzUmU+1E9B0AbzcYV8UMGSY+fbAn/XhQeh+CWJVo7jgK4B+FzSNVjw06dU1v5x9N2lVM48zVOJaA6cuFQ1JIdn6CLJzTvzqtnkkHEp8fQagKNmfpMgLODp8P/ATZ1in9/Z0Pm/ZLEWosPnppYb7niVv/vQTQJwZ6O3/e2NJ+YRRL6kRL+01gnOoqduygZtrOaqabNpbUGtsH7eafSHacCeLrXSBGvqzWEQQDy4nwP2aLwaldbVAXDvR2XRe2IFRiZzPM0nIGDq1gAqxji9ozqzvVaVD76SQIAq5m4Ft+5ADgaQY+S8CyahNEIpF6L2KOIWTR5iICLNydjWPxw91pdaIs+yrY4EvKiJI/lUrFnn0OF4LoUtfBxrQvQ0x8dqYnrfDXbqplBME8X40nEf04YFy99W8g4pP7e9I/N2lYY9uivSibWwFQg0l6V5ocCFeOvL7jl9au/b6yXdJ+OoKAnTsHMeumiHVuYqbTMn2d6lAZ+DW2duxNNndpPDP45Rti5o9bRHsV1lA+XYirDSGIsJGo8PfCACr10W7FIpjppExf50/cRZbbSKgxi2ZZrSGIjSBHFbCdq671DDxEoFffEDvfDSCpWZBDRDi5v6drZVC3m5oWvJOt+D3azTCvelgN0EsM3p6AZgB7aMp7zmJrfl/fikd0dWkIYgTAsIvwiv15DbAbHSmJaGmO7O/GbOuzqm/MvC0Rjik+EAAwoiQ0wPrHWJ0WXT+wesVvKhxmJ9ucQ1I71G+mtIYsNwH8GGA5blSC8GDgx6NDO56p24iibPC6fkTJ39TSvpAZN3vmhqOSZEImP3/UxsIfBmM/zRzawLDmZXpXDOraopEgLifgjBJCZ/wFFn4FpmHA/jeA5mhO4OtBfPRAT3pNhXO1pE/Bc5W+PzK0wxI/kvASBAP/R/m5OtfVtk2kpCzQ0yCud9Yf410aEv591rIOf3j1imf8+hWw/nIAPwFYmcJ8O4CAD7qw2wBGPwhHjZUtBDGepV95Xq/tgzrd5iw+eM3q9NPuUvWSRrTL6jKCKGk2PUWW/SmvqKw24M1Z+jwBl3gW33MW5w7r61v5O9+NO0u3Azjc8/s6JpyV6enq954e1Z0BMf2QgEZvHjuenTfYfcez3ro0BFFMkiPQVZyzL3GrZZQeFlZu1H0Kr5ahXCKZUmo2da9UtIxXRPvZ4dd3vEmzqVCiddF+sJXqr8Qv16tk8xH9/ekBLxZRNvjxEMTcuce9JTar7hcAlG6+8HF3zsInvPNW/eg/h/xtejQPM1xN1qt1nHbV130H6m5iC8Yq3zq/+RNA3Dlm3GXH+EJNn6ihZfGHLc7+EKADXA3LMfgLmd70d3X4auaZO9lLzHTe6OYdurxzoaFl8b4W59SB0eufbclAb9e1urryd4obb2bmDvfvBDyQtfhMb58Udtasuv8i4EytRCgEUfkmX2lO3eamToiZ3q7TdaJ3U0vHIma+xTWAkSyrAwjicbKzR/b33/FXn74Udc0l4j0xfjCrbv2ndR5mG5PtZxE5Rn/FzVAV3TUym88IuoBWE3vWtq98A85luSsv4XsDPV3ne3HxI4igk7a3j9UgiLa202YPZ19LA/QxV/2+C7yYRqk9kLXvJ+Bfx7Zi4OpMb5eSfkq+ahFEY3P7IQQotU3RX5jJqzpKJFMXgeibrkY/zxYdrFMh+hNEsJrNT/UVJG1r6sqB+ZI9dscVQY8yChfZ1wF8sqtPf0OODx4YSD9pMM+KSR5Hjufr8hQTaKWBAG/MDcnUoRY5qkx1ge98ar2yzecG3GNRoiV1AdgZI/e6FRVTpZv8ePJ5bR8Kqo35A71pZQ9R9iUSqbcjTt1gvHfLj3wvclgYdHk5ttl43X3nfzASwdX8amxuVycMJUkUP+09iFKlzNqMewBqcm1qGXtk9GNr1tz5chhmPqcfrcTiQxC+p2xd3dUgCPViiepyq10bvfELo3IpkwdjqJvX23vrBnd/qkYQLe3nEWPLKdnQFbTutZ5Onar6pCMIBv6IuHV4pnvFX4LmkJo/ddu8cgMBH3el05KY3ntysKrIXXfh5L3KLfX6kZGPBDFkM88f7EsrY9jAT6dtsOPZVq9krdM2OJf2BuvPB7tQgghr+1T7fVpcUjc2t19FwLlhk9j1OyVaOq4G85KwTVo3IDoJIso9xtzW1LtiNqn7EqUTLX5lp2DNCVPp9H2JT9dWzdNeMOGiTE/Xt93p9QSh30D9Jmk1CEJTx2s28xGDfenesMXT1NRxIFt8JwOvAfi1BTzKOb7aeyioIkGUxgoA0vXx9ScYxCqhRHP7TQAOBvivDHoUsJbr7iF8JIhQiauIpQaLnPJMkOlLb4mHop6Ql0vlvhKA3ziVl8G/HYnHD17bfduWOywAWoKIEJOlIZlqtsgxpi3eGWoPGZr7ykiaBt3aC7ukDpvDU+33KU8Q2tOUj+rADa5m8zW+rNYQRNSXUEqKUHcE7pNZ2eagMfrTnniDJk3+FLTzrQBSW9KVP+3VqukYt2T6uk4xeWWlyq4GQSSTx7zZptnKjuIjrv4EvkqKuqiqRhDJjgVE7H6gEPoqKWpfNAShvZvzK1en0uPy9VU2n4NUvH51aTZkLfnrCEI9t+7v67rYBB9NPVqC8D6bL3pl6O1d+ZRJPdq1ZyglmpQ/FdJMeYLQnFyMTpTNzSfslMPovZ5ncSY6YGgI4lcWbz66r++nm0wHrTHZcSKRcw/ifErs59FYa9EF+b6Hnbzdm14fVqfdsWetmoVpVJ3maW/Z22otQWgkjaAKq0EQqn59pEC8AsIKy6ZlmzfvsDbomWQYaNUiCB9JUr2M+Q0Y19vZ+KpKXdIX+6ghCFMpZQymxpb2LxHjsuIf1AXtP7etP+63v7hZSWLQrSUmnJ/p6boyDGv371rydxm6FtPqCIKZFpo8V41ykAnyymDar8YK1Yim5W/tdFOaIHxsH/pHZuNIEwtizUZjJEKWEUQFpwKvmEvAP2DzocXoa3PaFr91Vjb7S4D2HZsEmsViMkFMRGq9BFH+THgqEETBBkKp6N7h054hEB6FTcu4ju7PdK9QjwZCrY6LZVWLIHzuo7xdehaEVcxYOTu+ba9yGWMy5n4EwYSLMz1d34hURvmdW8kBQ/d0/A27zvsB8nusoa2ewXWUf623+xgZaSQDDUHkmOnoTF+nsugP/QwPMtSYbFe2Teoll/Opy+n+vq5PhVbgStCY7JhHxErizV9WV7BXRKmv2mmnNEHobB+i3AVoLrfVPhJ6We0liEoWXdgmpD0lVeimIqwuNal8XoJFcothuPAmZA435tUzSg+vXJmEfetBuIPZumnP3XKPhLk5McErqMIo+dVDhLphupUYR4Z1QkXoA3gtGDfmRrN3mTxUKDeUMz9pjxGmR2fvVbVo+mvQFcMkmg11vPPMJP9ESNSqh2XYCEEYDvwEJNO8RpiAUhH6ckdDEGWXvmENaWhbsIeVja92XVSX6EEnmSDUcbpk859uBOEsPn97jyD4XyHgO7nRuqv93I9E2eB1FUXNH90thVOr8uWVYVifz/SuUMZrZpbUFRwywvojBOE/3YQgwnbCSfpd9wR0oqoKk0ImgiDCLsommSDK7mmmI0EUxpsaWlJ7E9MFBBxvKFGorL7uR8I2xLB5Vml+xxAuh+OJcUHBn1fpG3p9xVk1X4eHdrxcd+8S5KwvrB9jEkSI80IhCCEI07lUtXR69dCEVR94WS0qJj3OJqL7hI2QpiBl3PXMi9a/Uo6PZUKHx+2BrmqtZXClG7zphmqCgaN62kytBOUxFIe5PNTqsvtaHk8EQWhe/JXcQYwXLxM83GnGO89M8ouKyWxUpuodhM6OoeDamdS/0T7iHTwLMPCyejIuqb163Ym8pPYucO+FuAJrGksQvmPtPNG0N+8Ptk8GQ7l+Lrp5d+cpswkY74Y33vyaDlEyuWg3G7l5IHzKx1eS9lBTRhAVvC4q3Pe4nuOW2ic0NaX2g0UPMPDWQtsjXRpHW6zjf05tQhCqTWWO8yq4Pyh7IFJBGVHxqWb6KUkQeqvN8MtlP+ASzakjAMecvujyIPCy2ksQ3md/JgNU/vS01ChN9/68klcUqi3ep3beJ7W1ShDucSi4jjgNRMrj7ha3CZ4nmw5eec+dbsePxtbaTn7vyxUgUv6w+ePEI7Bzyq18myutdlPWSBBa9yJBdYY999RYt2uNMcP6Zfq76QbvV55pfu/zXkQwxivW7X3OLq+YTEd5HOk0tg/wczVgUo32tA7/y+oyFVMhrGk0A5pdlgF8QrF9OsOirW4oF/FC03ThmYyJX5rG5kUNxLkjiSjBwD4F3FTMAZNPGXR9k4CLXInLbEI0/XiFbDrMNHZA2dt3DUEkEql/QcxS/qRa895xEYvBPsp0DjW0LnyfZcdU7ISx+BE6C/lyOwg2fgbue3Dw2Mfo/WNFP7AViEb5y9rpDdXaH2zg95bNPy4+/S6O2XjnmWl+DdH7+rzymXzlBrEiQZis08rT6C2D9Z5bo9SiM77ys87UGMoZ2U8U22Ma2U7naoOZFpsaBKn6dBeIpq42okZ/M114UcbFm7Zsw4t4qtOMnQlBqAOIkSGWjzPBMglC4w9M68LCDytTHbnGUC70lZ67Ts1dnza/5kXhqxZbH+vrW9FjOt5NLe0nMUM9XS5ezo8wcFSmt+tBdxnjnWem+XU+23Rrx69/WkNIIQjT6VBZOq1voQDPraa1aP2m+MSs1vliUj7pLXv0sP7+O9cH1RnFAdokOevTugWZLncQGqO/SBuRZsMss4LXWtkTXTPQ06n8fQUa3CWTi1pssle5YmKo6VBGELqDDhF1Dr++w8kmVuDazUtDYlpfTMx3q3CZYY4pCxEMbwORCjJU+PSSQTK58IM2xZTr8i1GbsADw7M5ZWK0Wnj2rQzd3K64f50bGT3Ma+9husH7rcMI+XV3naY+pnROOcVQznRDrjSd5qQS2YGdrm4fyUQrGfi5+w5zA+znQjnoVKJz982Ee0br+YRK3H0TaOms+Ivneh3CTRJBGLk9iTIXfJ43h7lZd6rQufz2kRJ1vrJCvfUGRLnT3kHo3M6D+IsDPen/DiGiMpfffn6CfJz15Qi4dHhox8v8yMjHXfxIgARLiZb274LxudLxpJvr4/bZQbHAFRGRRVcz4ZOuvCqOxJJMX5c7+qPzc4QNXju1ouTXER8Q7CrdsZDPh5Atj9onEkSU5R4trX5z0Ht8jFZyPrXubkNnWR0UMCgokIg+CAt3j8zGsX6bfd5Xvi5gkH8M32Qy9f4c0VICDvLg4LuRTgRB6O5ywkizsnEqU0Wo/fQJm3HuO3bHQxpLaWpqTR3EtnVjIbpfsVrfYE2a+OZq3WuDQTlS4eyN7USsfA/pYoVrCULn4lpZSxNjaXZ09Gs6S2kVF5nqRtU9SmlAGp84HwEBg5xAPrmYdZ43mlr+Ety+GoCKRz72hUk4PlKAGptHGLElOoM+P2NHtY78pI8oG7xufkXM7xPbQb/+AgKD5ZsiAYMqWfJmeTTqBWMPrCY16F9HlV9Wa0KO/hwEFbNhp0I97lCEOf8wjvQULDo+LATnBIUcDTwBTwRB+OjfFSSbVEjU/Pqwv9rfm1YhNiv+9KqPQnGEl4nxayfUpFMfv4sJ+2vsCHJBp/WACHtKyTQWotMpPx+5b8zlh9rcQBhidsKvqs/3FZMuIE0hj3Kr8SSIBp1QoCpsJnMDQCqGiQpv6/58iV9DECrWs+XS82cZ+B2BCqFoC+FkvYFuACMpLdGSmgsm5Xuo/EmxKzyu0x8bHwFhr/KJoNaFfezA6vRjE7DBlxURkSDgSFPbbLwGYBWq1fs9y0CvExrWPyzsljxCEBWv+7CMOn1gpAu3sArU7+Uvh9QuU6p/1jxz/Q8G/vmGf/krIgSC97Xk1bUzfzqL3QpQi0k/StPwE7BiJwQR0UQQhKrTJwLeWHOiuGUO6ueBbald41nc5nnqaQpNoPVxsZBE66J/h823e6SOkDry6od4jr4FxqlhBOGoI1pSpxLTdRHmjrsNgfNIQxC3EegVzm92JpbaSgIYtOO543WhanVgVIZbsaTwQ1PUDd7bxkry+0S9C5tvKi72UoayXSkcHoUgwjCr7PfxRoEzrdXHQrvECMnH1cYVieaOowD+kY+aodgER4WQy9Zd4ucLyK+t+ZMznQOC8nu/o0Gf1AT99qw4fy9IB6zKmSiCMFhIkd1NB+HBMfpKIVjUmG1DCC7ryOLPemOG++VR6pZYzr6SyFG3BG2o6iR+3ew4X6yw9hhZhdpBFIIZqbnjjZfs17QhBm7k0bovB82jMoIgLNtjVz79mRess4lZufAOcna4CcRfRxbXhF1oextZUIV9nfKbo8nYGK+LSjZ4d/sqze/cIT5P7W9s9leFrHFH5Um2dUrOsm0LpKLc5bULQhAG21YFSfT3AzCOjGVapbMJx7ASoHmuPCWX1UG+mPILY+STpAK+E32gsDgcdQHDWpmz6Aavzte0bcV0hU14HsAqCJBSbe1a2LyUA7cXAPQDlK6P2/eGEUNJmaN0NwgfLf4t6jPXYj61kP7+Ah3LzOcD9OHSTShalDoTbDx4NBRe0hTVMJsA/htgPQjL/uEeu+DxMG+umjodf08W6DNgJz7HOwtqniEAf2HQHd5xjUoQhTppbnPH++LMpzLhcEf9wnhL4TdnbAl4HITlw/X8M5PXQTqCGOjpOk2VqTbKUa47h4g7wE50Q0WACq/HwPiRnZ2VjnqI8WKn7g3rh+loME5RdiuuuaqSvvhGHOo/q7pMvdMW253luHo++55CfaEEPBEE4V4rIzlnfn8aRO8fGyNHhcZrGLR0dGjH+9QDgKjO+sqst4GyZ9gma6JaaaakJXW1Oi/1CALTHYEggpjufavl9rsOoUIQtTzQ0jdBYGsiIASxNdGvvG7XuAlBVA6j5BQEBIEgBIQgpt/8cNtkVeLnrZo9FhVTNdGWugSBCUZACGKCAa1CcY6/MdjKqlz5pPpaf2/XV6tQbUVVCEFUBJtkEgSmBgJCEFNjHAxb4TXoNHXrYVj8xCcTgph4TKVEQaBqCAhBVA3qcVekDPLqt914MzN3qNdkzHRaFMec425ABQUIQVQAmmQRBKYKAkIQU2UkzNqRNzLMfZds6wum7uXNSp6cVEIQk4OrlCoIVAUBIYiqwDxjKxGCmLFDLx2vBQSEIGphFKduH4Qgpu7YSMsEgVAEhCBCIZIE40BACGIc4ElWQUAQEARqGQEhiFoeXembICAICALjQEAIYhzgSVZBQBAQBGoZASGIWh5d6ZsgIAgIAuNAQAhiHOBJVkFAEBAEahkBIYhaHl3pmyAgCAgC40BACGIc4ElWQUAQEARqGQEhiFoeXembICAICALjQEAIYhzgSVZBQBAQBGoZASGIWh5d6ZsgIAgIAuNAQAhiHOBJVkFAEBAEahmBaUEQ4m8m+hRsa0u9aXiU7gbho8XcDByT6e36mbe0MnwZD9XX8fzu7vQ/o9dc/RzTvf3VR6z2a2xpWbBbluM9AN5T6O0GG3zoYG967UT0Psr6moj6tlYZQhAThPyBrYv2jLN9PuV4WX9/+tEJKrbiYqJM4Om+wU739lc8yJLRFwEhiImZHEIQ48SxoeHE7a1ZI58D0wUAshN5ShlP04Qgpo8ENJ5xlrx6BIQgJmZmCEGMA8empuN2ZqvufwHsMxli7DiaBiEIIYjxzJ/pnlcIYmJGUAhiHDhO9iQcR9OEIKbRHcp4xlnyigQxmXNACGIc6E5lgojSremuw5/u7Y8yVpLWDIFaWZtmvZ28VEIQ48C2VibhdN9gp3v7xzEFJasPArWyNrf2AAtBjGMEamUSTvcNdrq3fxxTULIKQUzqHBCCGAe8QhDjAG8CswpBTCCYNVJUrazNrT0cW40g8nYDuUWwsRhEHwCwjXomysDvAF7Oo7N+MDj4k1cVQOM1lEulUrFnno8dQGSfBsahAN4JIF4A/0UCfgvC8lkxvivMOKyhOTXHAj0AYCeTwfMzTnPlpca2Re9ENrfAAh3B+RdRuwKIFdLkALxAwOPM3Jkbzd61Zs2dL4fVXY1XTHPmnFEXn72hIQbrdCZuKcGV8DIYfyHG/VmiZWt6O/8EgMPaXcnv4yUI1Y/6+o0HscWnAWj14D82P4br+WdrH0xvrKSNKk9+HtJBBHzCU88mgB8joqXuOdjY3H40AT8t1seEizI9Xd82qT+RSG1DcRzFrOqi/QHs4uRzxoXXMGjp6NCO961d+/1R3RozmLdjzZjI9RXUN884KQNQV5/wC4Z1VaZ3xRo1zyabIKKsr7K2eAxR1V4Ys/lMAi8AsFdhL3TWPYDVTLh2z105k06n1d+q+lWdIJTdQCw+eikTPu3apHWdfgmgTwz0dv68saX9QmJcPpaIsGygp0st5rCPmlpTB7GNawGHhMK+TSD+OrK4ZmAgPaRLPIEEQU2t7S1s83cAOiCsYa7fs8RYmsvWXVIkUF3eKBO4gg2WGpOpdiL6DoC3m7SdgQwTnz7Yk37cJH2UNBW03ylebaKwcDqI/hPA2wzqHGLgRh6t+3IQ9rpyEi2pj4BxvcE8fImZP5PpS3c1Nrd/rAKCKI7N/4T3iZ8A4ayBnvSvvBgaEsSEry+fMTCtJ0dEt3PWPjsez9VPFUtqP4JQfd2cpcsIODtkL1Sc9wTZ1in9/Z0PG8zTCUtSVYJobO3Ym2zuAvAhwx4MMfPHLaK9GPhWFIJwTlAx61IGf9Z1GjeslgfteO74we47nvVmmAiCUCehWdu+8g0wzovetnyLGPg/y87O7++/46/VJAh1Wnz2OVwIoksraPsQE5+d6Ukvm0hpohKCOLAttWtdlpYzHIky6reOLWrPrO78vUFGSjS3qw3gisLJ0CALcmC+BBY9AcadxQxhEkSF80q7xsIIYrLWlxccR2rY5pWLGPhK+CY6lvtBi3Ofsyl291RwtaEjCNi5cxCzbgKowWRCFNJsYqbTMn2dd0TIM66kVSOIpqYF72Qrfo/LqKzY8JxiR8DK5Dc+PoCAD7omwwYw+kE4ypQgnIWyzcZrAD6jDB3Cy8T4NYOeVhucpr5ilsfJzh7p3YAb2xbtRVn+nFrszLwtEY4BsH0h0wjAqwDrH2P1WnT9wOoVv3G1gxItqQvA9M2yDTYv/v8BsNY56YnrwdwA0Ht1i4MYP5hVt/7T3d3dWW8/J0uCaGppX8iMmz2bXQ6MZ5iQIZCjFgTxh8HYT7MpbmBY8zK9KwbHNXNdmaMSRMBcLKhgsBqglxi8PQHNAPbQtPU5i635fX0rHgnqhw9eKssmUlIV6GkN2+i4AAAgAElEQVSfepQ6QfkNmmtIECHzKt8ngN8GQisYb3G1ewispAn697G6fPx2qd8nc315sPTvE7AJwIMBfXoQwN4uCXer+WLyEoQ63BEw7B5b93xw1j2QBONdmkPY77OWdfjDq1c8M1HrJ6icqhCEcwrYduPNzNzhbgwBD2QtPnPN6rTarMe+uXOPe4s1q+6/CDhTe0oNVjH5TCp+wmac+47d8ZBXlxdQ3/31cT7e716iEj2nXgKhp2y2z9K1TYHiuPOoy34RYOXOo3h3on5aTzYd3N/fmScU1zcZBKFwis2q+wUApdMufNyds/AJ7xiqH1UbNmfp8wRcUtpuurU+/uKpOmKrZNJHIQgHlyzdDuBwT13rmHBWpqer3yvdNLSk9iGmHxLQ6M1jx7PzdJKmSpdoXfTvsO37AOzsyuenxgxVowRJEI3J1DFEtMJDyC8B+Oweu3GXe847UuDz1P7GPdpVfmqoAAmiausrmVzUYpO9ynUAc4gVzOeNbN5pefH+RP1R9elvz+GjFlnXv3GH+W7NPJoyBOFp20vMdN7o5h263P1x1n3L4n0tzv1Eo3FZMtDbdW0layVqnqoQREMydahFpMQ9dRHtfOr0yzaf66frV0kCTtq+dxA+KqAHkeOOgYH0/wsAiBpbUqcS03WuduaIcFp/T9ctunwVEAQlWjquBvMSV3l/Q44PHhhIPxkyeMX2/cBNmsx0UqavU02iSSeIxub2Qwj4OYBZhcrW2aOxQwYHb3sxCNdEMnURyJGYit/zbNHBhiqa0DkdhSAak+1nEeEaz8Gja2Q2nxF0Ae2rviF8b6Cn63wvqfgcitYzcGKmt0udbrWfUn3Fs7gNoDZvAj+CKBxwVrkJjIE/wqJjgzBWKl/YfBcB/1pWl48EUa31Vbgfug1E811tWw/LOm5g9QpF4tovQDqcigTxOHI8P2jta/tTRW/Lk04QbW1t8eHsLssAPqE4ourC0h4Z/VjYaxy1yOq2eeUGAj5eMhv8JQjdBqxVFfnML2psbleSizrxFj7uH5mNI3WbR1SCmNO2+K2zstlfArSvq37j00Bz8wk75TB6r1tvyYSLMz1d36gKQbS0n0eM747VZfhYoKFh8S5WXU5timN3T37EFsoGmgSmBDHnkNQOszbjHoCaos5Fld5n03/O4txhfX0rf+duWlNTKsEWKemhqH7MMWNJpq/r+rA+JhKp9yJGvwTwDndaP4JoaulYxMzqEFN8+TZkM88f7Eur13aBn88pXd1x6VzDV2196fALOqy5O9nYvKiBYN/reWk41QjCeIwSze3nAM6hpvg9bcezrX6Sa9iYR/l90gmiuXnhu7OIdROwZ6Fh6qXBSf09nUocDv2amjo+xBarxbJFTPfZmOa2pt4Vs52FpXR36guUAHSVa8oYYeAo3akvKkEkEql/oRidzXkVzX4g5GKcO7y3d+VToUAUEiRa2m8C49SwTXoyVExlGzGQro+vP8FAVaQuam8CcDDAf2XQo4C1fKLuIUwJQiMBqTuj+QO9abWRG326+ajbuJuS7Zcx4UtbCvU/aOgq1mwK0NWTP4DtfKvSsmwpJ5IKT7fpawmimutrnPjp+jS1CCKCFNCQTDVb5Bw2tiuM8YT2JWjiTzpBFHSj6tbdOd0w8EwcuTbTTVG7AHwIwlsXCE8iy20DA+m/G61+R29evuCI8Y3+vq6LvWVEJQjTNgSl26oEkexYQMQrXe2blFdJUXEyJQjNpjMYQ9283t5bN5jWqd+QeVV9fLtUd/dNm1U5PpKesQ1Dvoyyg5WWIHQHMGZekOlLj9lPhPVNswFpCaJa60t3uPFbg359m+xNNcoBTLNPKBW7dk/R9UczxrVDEJpFWbKYwiav+r3RULXhrUtdgv9z2/rjfvuLm18zqaeYprGl/UvEuMx1+tO2eaYRhOYE6Uhpb5zCf6Pe+NvZ+KqQ+4gow2Cc1oQg9j3s5O3e9Prwne5nrQxcnentUs+gI32JZMeZIHariv4cp2xLT88dzzvzNf+cW0myuxUKfs1mPmKwL91rWpG2vRpDOa9UFPUAptqjVIBUl1vtvovQqZiqtb40G6KvFO9LEOV9mtBNdbwEwUwLTZ+rbo19pojrZEsQ1JhsX06Ek8YqZPygv6/rU6YLxVlwyY55RKxCZeZ1rBoJwudk9yfAUvEaIn6snmeOPS8EWHvSrNLAUTK5aDe27I8y40QAHyl5qeIjTUWZwCYbbAFAzR1NGbTPgrCKGStnx7ftLZ6qIw5ApOQm7dfe/zCdNdDXeUOkytSGGiLya1RZFemMm5LtNzLhk8X26VRMGrL6lcWbj+7r+6l6Bmr0+ZBnyR1ENddXU1PHgWyxei23Y3654x+w+dAokRo1fZpKBJFjpqMzfZ3qniT0q9I+o23HpBKEdpOK4C6g2OKylxNagiiPwRyKvHmCkhNiMdtEDpzC6vWstXuMeB+A38dM+7/xYuhAj1uQ8hZXlyCgLnrrhulWYhxpAF8W4LVg3GjqIsSgzLIkJgShE/PDjMH82qJ5yVOy+TSWq+K08yesr2XWzToJwivtRtBtu+v3qi692OjWclj7I/xeKoF5XIwAqAg/T5+mEkFEastE7jMRxsRJKgRhhthkEAQ1tKT2JqYLHGO7UsMls1blR1D75HeSJAinXc4TxDiWgOnLAN5s2Fhl+JVhWJ8v+ssxzBeabAoQRInO3qQ9oZ3S+CDTShCGjxbC6hOCCEOo9Pco62u8G/x480frWWlqIQgz9CaUIBznXDn7SiIcG9FdxfoCqW/xG7QVCKIImWMIl8PxxLig4GOo+MwyCNUsAV8bHtrxcq9hkNlQlKcy2ZAnWYIouWMwaY9JX00kCNNHC2H1CUGEISQEEQ0hg9RbW8UU5rvGoAuBSSph9rx1Ld/uY+3pru9FgP9MoF6bqXu0znp4bfdt/zDdEKKccCZiQ3NUT5uplaC88+KwEIkox+AvZHrTW2wqxjEYJu2fZIKYkSqmyVpfXi+2omJasNtkOh4MWnqTKkE46ogJEIHLLgU1p2bdRZuy1o56IR5ln4pKEAVDrbs0VrJ/Z+AWwLpvNE7r1nbfptx5a11jm+JZbYLw4OZcrNvIzQPhUwDN0fiSMrHCNhoOE4KYyEtq7yW09xK17FEFMGmX1GUv/IBJuaSu5voKu+MxmRSaS/VIev+wOqKsr6j7hLfu8eYP68tWJYiyJ6MVXKI1JjtOJHIsRfOfj1rF++oDFdQVBcyoA6exeM2BcCOyfH6Ay5GSJk0TgihpsxP7w84t9xBjpJccQeNiQhBtbafNHs6+lgboY2PTqMIDhHdTVm4teDTWWnzi29SU2g8WPcDAWwt1RX7mqmuv7sTuJaNKnrnqyNPnmWvJq6rJWl8NbQv2sLLx1W6D16i2HRpbFCGIKJvb2FZbQaYoWTSnqah+eNTTSuUobYu7DR+C0Dz583VmF9CHohWmskx9FqBHme0HZte9tNJrMRyFIHTPBE1djhTbmkwe82abZqvnvuqpayBZRjnhmGywygocMUttrq2ArZzWxWKwjzI1eGxoXfg+y46pJ8dj8SMmSkVh0n4F1tY0lANg7FJFtXUchnKRrcNNDeWqtb4mwmZlIqSQoH0uyvqKsk/o6hxv/ij7tTft5KuYEqm3I07dYCiX1c4XZWPQGmf5SRAatxwMXJrp7VIBYYyimen84PgZVEUZOK11bURDrShuR6JMYJMNNlE+jrkop7qJuo/STXaT9qt8OlcbzLTY1GBJlaFzVqc92Te3X0XAuVvaG83VRlNL+0nMUO5Jxi7+9a42yiUjIJqrjXL/Y85iKfPFpHUzMknrS+PWJZKb66bm9q8WYkgUh0AkiAqYYtIJIu+VdRweTMuc5/mrmHw9QBIfPdCTVqEIAz91yh/J7nI1g1W0u+I3xLCOzPSu6PZmjkIQOjE+yh2Jn8v0aj1z1bogIeocfn2Hk01eI2kIBlGsSYMGzpQgJslZn1ZKHY+zuYKKRRlRlQTWiuCs71WLrY/19a3oCZvzPi7JtQRRzfU1HjLycXYoBBE2GTS/V4MgkEwu/KBNMWUZubvrRNWdjWPxw91pFXdV9xVDJ/64LOhMgBdRnWtxE9fHinYKYTRL62O+W8XN1t0RaAjCV9fsIzb/EXHr8Ez3ir8EjV3e7oC+C1YXvltOlI40xrgl09d1ildCmmgJQtWlv0PhLw70pP87REIjr8vvSnTlfhiZEoQjRWjcfTPhntF6PqESd98EWjor/uK5XvWjn7vvMHfVeRKj7wNQ8RpKvijuvt/IH+pKOk9Esdt1Uc38jAiruL4o0dKu5rwKzrXlsBYSkTCvCqVOAId44BOCmKoE4R/bgZ8gC+f0r04r3fSYCsg/0EyhhwEE4SMFqIwbwHwhbNzq3ewD4mSvR4D04ScV+MW50Ii9qtuP2IRTdbGaCzEIjgLzN31jGftcxE8GQejiDgBwYmRnR0e/pnPfrrClutFvlgV/8omjUMEcVr66vlASszzgcYJ/wCD9XFTtSSZT788RLSXgIE/7Al3J+wUMItB/cM7+sWceUkPL4g9bnP2hX4zyCgIGPcdMn9lzd/tub8CgkOA6fu6+HWeWGil7UtaXT2wHv5jslGhdtB9se7lPSGMhiAoWV1UkCNWuwDCFwLMM9DrhKv1DVW7pXkgcAnUKq99MaZ94w0MgPAqmx/IF2v/m8wxTeSr9fKYnvdQPV91Lk0LaTflQiOrBlf3V/t60CtGpLJC1fv4dh3elITtjYHt/EH2gLLSnCgQDvMcVtEf7rHEyCEL1QXeCLPRZudV4EkSDYBoOCZcaJUZH6LSOQhCOJOQf/jZKyNHAw0Ox0T4BitTPJiFHbQB1xbJC7u50J+58VieUbWDI0VEAVsl9R1DI0SqtL2fNtKTmgkk9zHBH5VM/ja3jkNCwRfiEIEJXUnmCqhGEqjp/erOue8MA7OQIbVULaSnDUa/sVJjwvhHliuUGieoGdQ8BuHCgt0tFlwu83A7YAPJN9bj1LfjpUZePpi4qis3dxETK5XifxXy/6wml9o39ZBGEo4orj7xnAOlYknVsUftERZNTpUYlCIfo8uqVWwFqidL4fFp+AlbsBE+scb9iqLE5dR6BLtfFFffJNATG10F8mPtpcNjjDkettc3Gqzgfi93Eql1VvwHg/wDoC4WDR76HAQShfq/W+nLGNx/JUEVN9JKE79AptaEFZJmdmPFOP23woYO9aRXne9xflPUV5a5S17Dx5h9PZ6tKEKqhJvFwt3SInyDbOiVn2bYFUtGxjAnCU9cV7ueVQYCpp6dMfLpO5aPLZ0B6ZUF1Ei2pjyj32L5qo9KKsgzcnLOsr6hA5Rq1lvY1UZQJXMkGW/C4+SMfcV4H1RADN/Jo3ZcHB3/y6ngmrTdvJe1XZeQvXekcEBTxOp5DQz51WPn2rDh/zy9OuU/+0HjTrnzPkcUnz7KwZniU7gbho8XfmHB+pqfryqA2RltfcMi6jkdf8VjqGtmouOqatPVV7GsE9zRZMF0J2/4K4rTUFVxLCCJsdmt+rzpBFNugNrCRHB3LzJ8G0fvHXDM44jCvYdDS0aEd71MvZEy8uQb1XZ2s4rM3NMRgnc5kJwHaw6W62QTw3xi0ygb9aE1v55/CpAZvXWqh/P0Fpy/nA/ThUulA7yq8EE71CAKUNKVCYO7qOvW9SMBvmblT4wW17FUYaV4TTTZBFDCguc0d74szn8qEw0HYy+ViQznne4HUZSlh+XA9/yzoEriCuTuWpVKCcM/F4aw1D2Bl++IeC6cPAPoBStfH7XsjEkNJtzxj3gpgl0ICNQcfA+Na2LhT3U1EGT+/g4taX2CcwoT9veuLCNe+fVfcp+4mxntCnez15eqf4+DSAn0GjENdno4d9SbDWpmz6AZ1kHIOAKVeHIQgKlhkW40gKmirZBEEZgwCGrsZo1N9JQB5jfIqib9QSb2SZ+ojIAQx9cdIWjgDEdC4m5jQE7AbUm+Ankqd483AYar5LgtB1PwQSwe3BgKJ5vYfqrf4b3i3/QOA37DFtwysThdezoW3KNGcOgKgu4uv1bz+nkrVY5QG8H5Avc7jx2Dj+1HisCea288BcE2xzEpD9Yb3SlJMNwSEIKbbiEl7pwUCGlcRZY8V/DriY2Tnm9/rwNH7ci4IMJ1tS5T802IwpJEVIyAEUTF0klEQ8EegMZk6hojucD082MCw5mV6VwyG4EaJltQFYPqmK2+OiE7q7+lcoctbFlhI2coYWOj72Ca9SjYf0d+fHpDxFQSEIGQOCAKTgEDexbl9P4C9XcW/xEznjW7eoUvnv0qd5uN1dV9hgvIFFnflu78+zsf7vaDSORBUtho249x37I6H3FbUxTKVE0wrR1d4oxr6uQ6ZBIikyGmAgBDENBgkaeL0RCDIitp51gprneqZYwnMaARhz3IDN3oKln1syP1FoBU1MX7NoKfzKLIKV6ue8haf2G4BlzAQR3ZhT88dz09PxKXVE42AEMREIyrlCQIFBPKWza9czMAlESyb3fgZW50bGGwGjou6mB6N8ykBzjNlXGcgAkIQM3DQpctVRSCKFXWxYRVZnUe0oi7W9QoYl8Hma02jGlYVPalsqyIgBLFV4ZfKZwoCavN+5vnYAQReDNiHAPQOl8X9hFts19dvPAiExRrPAVkAfyWmHjBuGx7e4X9N4nnMlHGSfpYiIAQhM0IQEAQEAUFAi4AQhEwMQUAQEAQEASEImQOCgCAgCAgC5giIBGGOlaQUBAQBQWBGISAEMaOGWzorCAgCgoA5AkIQ5lhJSkFAEBAEZhQCQhAzarils4KAICAImCMgBGGOlaQUBAQBQWBGISAEMaOGWzorCAgCgoA5AkIQ5lhJSkFAEBAEZhQCQhAzarils4KAICAImCMgBGGOlaQUBAQBQWBGISAEMaOGWzorCAgCgoA5AkIQ5lhJSkFAEBAEZhQCQhAzarils4KAICAImCMgBGGOlaR0IdDSsmC3LMd7ALyn8OcNNvjQwd70WgFKEBAEagMBIYjaGMeq90IIouqQS4WCQNUREIKoOuS1UaEQRG2Mo/RCEAhCQAhC5kdFCAhBVASbZBIEphUCQhDTarimTmOFIKbOWEhLBIHJQkAIYrKQrfFyhSBqfICle4IAACEImQYVISAEURFskkkQmFYICEFMq+GaOo0Vgpg6YyEtEQQmCwEhiMlCtsbLFYKo8QGW7gkComKSOeBGYM6cM+rq6zcexBafBuCjAHZxfie8DMYvGNZVmd4VawBwFIIoS8t4qL6O53d3p/+pik8mU++3LfocbBwBwp4AYgCGwPwEE26xR7LL1qy582XvaKVSqdgzL1AjMc7RtHcdA98ZHdrxvrVrvz9awUjT3OaO91ngTxBwDIC9AGyzBQ/+A4E6syOjP9G1zaQ+hXd89oaGGKzTmbgFwDsBxF2Y/4UY92eJlq3p7fyTwt2kXG+aRCL1Xo7RJz39yAL8JMNambPohodXr3hG5Qsbq0rqlzzTFwGRIKbv2E1ky6mpNXUQ27gWoA8EFJwjots5a58dj+fqTS2p/Tad4WHMorh1HTMfXyAFv6o3AbRkoLfz5uIm2di2aC/K5pYDpDbWoG8dW9SeWd35e1PAGlpS+xDTDwloNMiTJcbSXLbuksHBn7xqkN6h3MZkqp2IvgPg7SZ5GMgw8emDPenHTdKrNAe2pXaNjdI1RDg2BN8sA9fNjvPFuVzuzSXj6iFz07olXW0gIARRG+NYcS8cqWGbVy5i4Ctjp9fw0h60OPc5m2J3m7ja0BEEMX3WtvgWAv4tvDonxRARTu7v6VqZTC46wCZb1b27SV4GnoFFh4eRhJJI/v48ncPAt8akBZMKnDT0FCw6fmD1it8EZVF1PPscLgTRpSGbtq6YISY+O9OTXhYmTSRaF/07bL4d4HcbdwEoH1chiAjw1V5SIYjaG9MoPaJES+oCMH1Ts1ltAvAgQC8B/DYQWsF4i6vwBwHs7ToB+/pi8hIEA/9HwDCAua7y1jPwEIFeJfC7OH96f7OnM7+32DrTJvt6APsUfssB/ARgZfL/txsLUpBSU7k+urU+/uKp3d3dWR+AQrDgxwBrXZ4L+MNg7KchkfUgPnqgJ63UcNqvqaV9ITOUJJRXV+W/HBjPMCGj+h9SxwaGNS/Tu2LQt46mBe9kK36PC6NiUiUp/I5Aj6g/MPgAAj5YejBQWJJSLe7kZBKC8IN5RvxdCGJGDLO+k8nkohab7FUAtnel2ATm80Y277TcrbtXJ9+/PYePWmRd73MqNSYIz8b9lM32We/YHQ+l0+lc8beGhhO3p/jotUQ4ydP6EQCzCn+7K2tZ5xb152N5WxbvS5xLE/CvrrzryaaD+/s785u85/PZuF9ipvNGN+/Q5b3HaGtLvWl4FEtA9J+ezX6dHc/OG+y+41lvHXPnHveW2Ky6XwDYf8tv3J2z8Ik1q9NPe9OrOjZn6fMEXFK6ifuTndOuLN0O4HBXeTlm3JWLWed5sTqwddGesZx9pa8aSghiBu8QYgcxYwc/kUhtAwu3gWi+exOFZR03sHpFfwWn00oI4nGys0f299/xV119DQ2Ld7HqckpS+VD57/T9kaEdlvhdQDc2L2og2PeOnYSd0zCdNdDXeYO3LLVJxm37/oJEVPz5ceR4/sBA+smgSdLY3H4IAT8BsHMxHQOXZnq7FHGUXCoX0v7cRXDr7NHYIYODt70YUAclkqmLQI6UV/yeZ4sO1qnMmlraT2LGTS6JMEfApcNDO17mh1VBzXgx54moVPISgpixe4TquEgQM3T4m5pSCbboPpf0kCPCaf09XbeEQaLdfIGoBDEC8PyB3rRqg+/XlGy/jAlfcidQKirLHj2sv//O9X4Z29pOmz2cfS0N0MdcG/fVmd6uz3rzJJrb1Suoa0qIMkRV5C5Dsyk/nbP4YK9U0NjSfh4xvjuWl7BsoKdLvRgL/HREyUwnZfo6FTGNfXMOSe0wazPuAahp7I/Md8PG4oGB9FBQJQ5JbLvxZmbuKEknBBE2PDX9uxBETQ9vlI2X+0dm48i1D6Y3GkBCiZaOq8G8xJU2IkGY1dfY3H40AT8tIQjCRZmerm+HtbOxuf0qAs4N2pB1m6qfBOBXn35jLpdWGlvav0CMy13lpOvj608IuBcpJqVEc7uSCg4G+K8MehSwlnvvIRqSqWaLHNLfrpDxVbL5iP7+9EAYVur3pqaOD7HFv3RLQ3IHYYJc7aYRgqjdsfXtWV5/TneDHFsH5yPGN/r7ui42hUOzGUUiCAa0p3lv/Zp6XrOZjxjsS/eGtbVsQ9ac2BuaU3Ms0AMuVVRFgY80kk7Z5t+Y7FhAxCtd7TZ+lRTWV2eD90pbEU//bW1t8eHszrcCSI3VF7EMk3ZKmumDgBDE9BmrCWtpc/PCd2cR6yY4RmnqG2HgqExvl9L3G31K7UF1udWui+BoBKFRkegq1mzgvvp3b34TgmhMdpxIxGNqNQb+yKOx1pB7gbKmlm/+/NuRePzgtd23/aOYeG5r6l0xm9QJ/V2uAtQrrN+Acb2dja+KWm+xHJ1KLSrpq7LK1GBCEEbroVYTCUHU6sgG9KupqeNAtli9ptnRkR6Af8DmQ/v704+awrHvYSdv96bXh+9k4NBCnmgEARyT6e36WVh9GoL4c5yyLT09dzwflteEIDQn/+cYuJ9AEa2vWVlBj70cUrYXceTaentXPuVqJzU2t/9X4VWSX/OfBWEVM1bOjm/b29190+awfqrf57QtfuusbPaXAO1bTM9MCzN9nXeY5C+maUx2zCNiNS75y2ohiCjw1VxaIYiaG9LwDmn0+sabrrv0REv7TWCcWgFBGKuJJpsgPH0IB888hZYw1X1F3TDdSowjDYpS7jDWgnFjbjR7V5BLj4a2BXtY2fhqt3TChiTsbkcZ3kIQBsNUu0mEIGp3bH17NgUIwljPX2sEoQbFeWIcxxIwfVljDOg3bspGJMOwPl/0hxW4sQe8Kgua8kIQM3BDCOiyEMQMnA9CEFsGvdoShHu6OYZwORxPjAv01t/ayZkl4GvDQzte7rZrmKjLdiGIGbghCEHIoLsREIIIIAhD24SJnlGO6mkztRKwGITDPG5NvNXlGPyFTG96zKZCVEwTPSJSnkJAJIgZOA8m4rSpeRIZ5ZJ6yqiYmpLtNzLhk8VpQMAD/9y2/rjf/uLm17bi1KBkctFuNnLzQPgUQHM0jhRLrLA1r8ogl9RbcQRrpGohiBoZyCjd0Jw2c8y8INOXLjFICyqzufmEnXIYvReghkK6aUkQGuvmJ5HltoGB9N+jYDqZafOuQBzX5m2uenLMdHSmr1O5E4HmVVlk2xZVTiLZcSaIlTPE/CeX1JM5tFO+bCGIKT9EE99A3WZiarhWbE0UKSRKcCFvbyf7klrjH8nIBYi3nY67DsLXwPwCiB4B42Hk+EdFFxeJROpfELOU24/WvMdZxGKwj/I8g/Ud7IbWhe+z7Nj/uuNHsMeivPzJLt+LHBaGudkoViqGchO/1qZ7iUIQ030EK2y/xu3D77OWdbjX26df8U3N7V8txJAoJpmWEoTOzxERdQ6/vsPJppHolJdWa1bdqtIAQ7yqPr5dqmjHkEik3o44dYPx3gJgkaQ2nfW7lyA0ZBfJ1YaKPIeYY8j3DpEgKlxYNZZNCKLGBtS0Ozq/O6Y+iLQbSTRnfVPmDkLdwyVa2r8Lxudc2I0FJzLBs7E5dT6BlG+ooifUHJjPHOhL/zDodB6FiDQEU3bHoPMJZVqHkh5GsrtczeBPl/RZVEwmU6Bm0whB1OzQhnZMuzGGRSzLq0qoE8AhnhqmpQSh+pBMLvygTTFlWe6OUKcCGJ0Y5n4k0bqoCbZ9p8fdt9bbbFNLxyJmx63HFiIh/uJAT/q/QyLElbn89rHUhs7dN5gv2WN3XOGOt+EZO+UM8Ow3nPxdURYESQgidCHVcgIhiFoe3ZC+Nekjj/nFWMig3NUAAASdSURBVKZE66L9YNvL9fEZIrn7nkoShIOSRgpQfx5i4HIerbvSG286wNjNV/rQq6Lg4J0dHf2azlLaCZxUN/pNAs4sidVA+N5AT9f5XmLxCxhEhBUxZC/0uigptEm5/ygtvzh3hCBm8A4hz1xn9OCrzidaUnPBpHzvjAW8KYAyBMKjYHqMwdsT0AxgjwDApq0Eofqk4iHM2mbjNQCfoemjO1Sncq6n4jwnNSFHcwz89+z4+kv8XHg3JFOHWkQqnrY75KiqUrnVeBJEg2AaBnE9mBsAUncWcU+bAgMt+UhETh3hIUfhjtgnr5hm+A4hEsQMnwD503N5VLQwWJhwj6U2HMYxhbTTmiDGSGLbV74BxnmaGN1hkORAuHLk9R2/FHK5TY0tqVOJ6ToNSYTVoX5fxxa166LJuTMnk4sOsMlWRORWm4WV3wXQUwD/x1hCkSDCMKvp34Uganp4zTsXGpt4S1FZMF0J2/4K4rS0Qmd9U07F5EKKmlpTB7FNV/mo0jSg8hNk4Zz+1Wn1DLUkzKjfCBQ86v7IvA5H3XUjj9Z92avu8qsjypgW3XfUbfuKino3FtRoihgOmk9kSTmhCAhBTCic074wamhJ7W2BPgN23HgrF9ZKveGoPxjWypxFNxSfwo7Dm+tUJghnEFOpVOzZF7EPbOt0wD4EIPX0882FER4C+FkQ/ZLZumnP3XKPBFwAB00Kmtvc8b4486lMOByEvVwuNpRzvhcIeByE5cP1/DPDaH/e+vJjytYZgH24S2U1NqZ1NHpt8W7CxEX6tJ/l0gFjBIQgjKGShIJA7SPgNbYjxg/6+7o+Vfs9lx7qEBCCkHkhCAgCRQSoMdm+nAgnFf/gNcYTqGYWAkIQM2u8pbc1jEDBS++NAJ4F8AgR3Tsr9uLP/V5UeaHQWJWX+HuqYeikaz4ICEHI1BAEagQBr98qP2M6v+56jeyi5q8RGKUbLgSEIGQ6CAI1goDOHQeYvzjQl1avkgJfV+ntYejW+viLp5pKIDUCo3RDCELmgCBQewg4/pRGd17qjm+hXqAFWWorA8G62RvbifhKAG9zobIelnXEwOoVv6k9pKRHpgiIBGGKlKQTBKYBAkFW1CWW2sofFNv7g+gDGoO9ISb+fKYnvXQadFmaOIkICEFMIrhStCCwNRCoxDLe1c5NAC0Z6O28OUwttTX6JnVWFwEhiOriLbUJAlVBIIIVdbE9yjAvYxOfMdiTfrwqjZRKpjwCQhBTfoikgYJA5Qg4RGHnUgQsBOg9AHYZK43wMpj/wMDKnBVLmwaLqrw1knO6ISAEMd1GTNorCAgCgkCVEBCCqBLQUo0gIAgIAtMNASGI6TZi0l5BQBAQBKqEgBBElYCWagQBQUAQmG4ICEFMtxGT9goCgoAgUCUEhCCqBLRUIwgIAoLAdENACGK6jZi0VxAQBASBKiEgBFEloKUaQUAQEASmGwJCENNtxKS9goAgIAhUCQEhiCoBLdUIAoKAIDDdEBCCmG4jJu0VBAQBQaBKCAhBVAloqUYQEAQEgemGgBDEdBsxaa8gIAgIAlVCQAiiSkBLNYKAICAITDcE/j8AD6rFgBlvJgAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-12"><g><path d="M 211 301 L 261 351 L 211 401 L 161 351 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 351px; margin-left: 162px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Failures?</div></div></div></foreignObject><image x="162" y="344.5" width="98" height="17" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAABECAYAAACbHqJdAAAAAXNSR0IArs4c6QAAEYRJREFUeF7tnX90HNV1x793dmSJkGJoSAyEH/lVTpJSmoONtSvt6ojfhNgxAXYlEwxOSUKaUtOkpTmltE0bk4SQk5xwCBRSBwwES7sYDHVLiF2ieH9o5dQpJYSmSSAtuBhMXWMIyJJ255a32hWj3ZndmZFmdq298+fO+/l5b+c789699xHkEgJCQAgIASFgQYCEihAQAkJACAgBKwIiEDIvhIAQEAJCwJKACIRMDCEgBISAEBCBkDkgBISAEBACzgnIF4RzVpJSCAgBIdBWBEQg2mq4pbNCQAgIAecERCCcs5KUQkAICIG2IiAC0VbDLZ0VAkJACDgnIALhnFVgKSOxxF1gXOFHhUz4Qj6d/JofZTspMxxL/DkxbpxJS9g4mk6urc4bi110bIH1NID3Vu4x8NF8JvmPTuqRNE0hQMujA7+jM1/BhPMAnAzgt8otKQJ4AUAOoFSnbjwyMpL6TVNaKZU6JiAC4RhVcAlFIAARiODm23zU1B2Lf5CYNhAQdljeOAPf4amOvxob+94rDvNIsoAJiEAEDNxJdSIQIhBO5kmLpKFINPFZADcBOMxDm55kjRL5HcP/4SGvZPGZgAiEz4C9FC8CIQLhZd40IQ9FYvE/A9NXAISq6i+C8GsAWTBNAPx2EPrAeFttO+kZaHTJ6I6hf2tCH6TKOgREIFpwetQIBOOxzg5etRDWbGUPogUnnMcmhaOD3QTjEQBHmYooArRBp6kvptMP7DEXHY/HQ88+jzM1ws0AvX92tTwy2YULd21PHfDYHMnmAwERCB+gzrXIhSwQTtnIHoRTUs1JF4nED4OGTSBaNUsciP9iNJ36OgC2a9np/fFj9AI2AdRvzsuMq/PZ5N83p0dSqxUBEYgWnBciELLE1ILTclaTenriEdbo+wCOqNxg4M6p8SOv2rXrjqlG7Q/3D74LBeNRmrZ0Kl+cm+zCBfIV0YhecPdFIIJj7bgmEQgRCMeTpUkJa5YKgb1k0Fm53PCTTpsUiSb+CMAtpvR7WKOzZMPaKUH/04lA+M/YdQ0iECIQridNgBn6+/v1icI77gMQN739P4IiLh4dTY07bUpPz8DprPEPABxZzjPJwEfymeR2p2VIOn8JiED4y9dT6a0gEN3dq5doemEFiD4CYCmA4wDopg69CPDTDGwuaqHUj3cMPeeks35sUteU6XJT303+6rQV573u7o8fQR1T1xHwCQDvADAO5p8z4V5jsrBx584H99nxUZu3z+0JLSMy1oJxDoCTTKxfJOAJEO5eFOItXg0Vlp4dX9w5QSvBuJyBUwEsKben5MBGwFPMPFycKmyp11aVp79/bdfE1OtXQ8MpYF4G0NHE2JDLJv/SyRyopJF9Jje0mpNWBKI53OvW2kyBUA5PGtM3AJxtYbpo1+4iM7YUQ9rnGgnFQhQI0rTdMPh+gN9jDYi3duqHx0dG7jpYdZ96+uJnsIFv11r1WJb0Koi/hAJucfqm3t8ff+tEkb4ExlUO/RQKxLitWOi43m8Htp6e+Ieg0TYGji73dr8BPmcsk9rVgn/LtmySCEQLDnuTBGKuDk+K5PMaa6uy2aF/tcO60ASCgGsYpYfvB236XCSiy3Lp4SHzfWUFRCFtPYOvcSHE5SJ4zNCLl4yNPLC73vSNROK/jRANl8Xe1Uxn4BfQ6EI/9wNq9yD4iUldP2vXyKb/ddVYSewbAREI39B6L7gZAtETS1zMjHss3jJfhXpYgB4HoJYjQmDjNFDJjr3Wc7bB8s5CEwgQ9pmcv9T6exagZ8pfE70AnjamQmePjW16sTIjli79dMeiww7cAvCna2YJYR8xfsIg5WQWYvAyAn63anlPZXuKjMIFudwD/2010+rUUVr6Amk/KY0ncSeAXjDeXStU/vkm9PRcdBJr+j/PElaiW0bTw+vqmch6/1dJTi8ERCC8UPM5T9ACcXrf4Am6YTwK4AOmru0nwrqJ148ctjJbLL8Bf4LBXzUFZFPZJwFeNZpJKRPImmvBCcRMD3mM9dBgfmTovyo/qeWd8SJOHEunnjKBsPE+5p8bjHUnHofHUqmUEuKZa/nyj71NW9TxdzT9pWL2WH60U+dLrPYlwtHBfoKhHsAVES8y8JUunW+0Sr+8L/5u3aDbGaU9kMpl+fUz1+lv82XzvMbFc7PZzT+ba/mSf/4IiEDMH8t5KylogbAwN3xFY21FNjukoqnWvXr64meyQQ+a7eGJ8WW7DcuFKBCl5RhdO88sDnbQuqPxpRpoW5X38XYUeWB0NPV/dWBTOBa/gphuNT/0ibA2l07eW50vHE18iwD1Nj59OXg7VxvZiw5iy2wHNtv9k0ZTw/J+d/9Fx2uF0P0AdZsSjBNhTS6d3OypUMnkGwERCN/Qei/Yh1hMT+tUiFWHPlAtLFmkFF5LAbTCzcOkktbK5JEZ9+azycutlgoWokAQ8Le5TPKLDkacIrGBm8F8tSlt3aWiqjIpHE2oL4nr3/y91rns1HPXHP7W1yceNH8NOA2VHonGzwfoIQCLVB0MPKej2J/JbH7GQf/qJgn3DXwABm+Z7RxXWuZq6H0917olvzcCIhDeuPmaK0iBKIVMCNEfMBAFcBoBiw3mS8ayqYzTTs7FTBTzcB6Em/qt+uQmv4WD2GsG8/lOeKllnJBB/wKU1vvVVbT7ArBjb1FGje9AyXJpih4C4cxKOcx0WT47/L1GY1p+w98GkNqbeJxBT3WQ8a10OvVSo7z17pc9r+8vm0tXkhbBfP3xx+Gm6mW1udQleeePgAjE/LGct5KCFIj5aPScHrCHvkD82tALfY0sihTncG/8o0T0wMw+AuFXKHD/6Gjqf5yOg9UXm8WSHoV7E3cT4bIZgQjAKsmuD5FYfDmY1EFPyj+kcqkN/WtHM0m1ZGYbt8kpF0nnDwERCH+4zqlUEQh3ntRuBGrevyBcOOX19CZuYMJ1lTYQsO03b+n82BM/uOc1NxMmHEtcR4wb3sxTu0/QExsYZGa1N2He1FaH9DxE4I2d+uEjFn4ZbprhKK2ltRLwKkBXjmaG1ReFiIMjks1JJALRHO51aw16k9oLgqX9q4/uKBQjBKwGoPYvKkdLqr+8bXjyBbgHkerU9146MjJSqMfRJjzFLwHth+7584cALDcJxFgIHR/OZO7bX/mtbPm0tc4JbwUGfkaMYQ7RlhOWGL+Y72UeZWrb+ZYD9zDzgKmP+4l4TS6d+if3/ZYcQRMQgQiauIP6WkUg1Ab25OQrSwxNP1UDncDEy8GlB9O76nrltpNA2CyRVQ+z1b6Ag6ngNImlEUJv7+Aygwy14azCpDS6lL/LVjLoromJxT90EpG1UYEWEV8nmfnyfDalnPfkOgQIiEC04CA1UyCUT0TIMK4hQL31He8JjwhEDbZmCIRqRGk8i8Y3iXChC49ttT/wXZ0KN1hZvjmdE9VLagC7DujntC5J5w8BEQh/uM6p1GYIhAo2F9Kn1jPhDy28duv1R715qqWNE2cSiUC0jEBUGmIS/jVVm8X1xvZ50nhNbkfqMbcT2tJ8mukzo9nh292WJembR0AEonnsbWsOWiBsnJdq2zcdVkJ5CucB+pHGlM1mh/aEY4lriXGjCIT9ZLI0PSV8IZ9Ofi3gKUjh/sGTaIrPg8ZXgKH2M2pDprzZqL3QtPPdnhcdjV56VBFTj5gc4orMtDKfHVZHlMp1iBAQgWjBgQpSINRGYsdhL99eDlNtpvEyCENs0MMd2tTjxxwT2mu3ienGimjBbVI73IOwcl4jxj/ksslPNXMKqvHv6tp3cpFCa4gxACrtL82+HHhhV2exCOUtkVqbOdAe6xaB8AjOz2xBCoTV0ZFvmOx/H0X+eIPQDzMImi0Qkd6Bq0D85lnGLkxPVSd6ehPfYcIn5/MLyGp+uKnHz/lVp2yKxBLngnG3eRlKhRLhqVCfOeBgo/aJQDQidGjcF4FowXEKVCCqbPMBPIsinzU6mvqVQzQ1TlmBm7lGEysJeNjU3h9pfHBlNvuw2h+pe1m92c9H+60qrREyD8d0qqhK5XAd6jS33SrKLrOxravjpc0VU1sV0oLYWAGmiDrsiYFcl753TSNT3Eqbw7H4WmK609QHeftvNJEW6H0RiBYc2KAEwsY23+5wG0tSpZPnOorqiMhT5vMN3M1pY+FagXDu3awepgar8BfHzmf7Lb8gegZOYa1U14xHMQPr85nkXzt1GItE4u9DqBSuY8YogIGb85mkOleidM3VY9sioKAIRAs+J4JokghEEJRd1hGcQNQG6nPp3WsRPK70qAvUUa67Nx7ViFR48cPLqOuGHDcNh2/tt/yCUHGvNGwC0SrT/b0gXjmaTu1sNE2UoE8WltzMYGVpVrnGGdoF+czQSOWHaPTi9xQQGiHghPJvrmI+1QgM4FhwG/VB7h9aBEQgWnC8ghII1fWadXFgP0P7cD4zNFYPjTpHefcL+DyYvmxhFmu7xOPHJnUkEn8ndBoB432VNiuhm+ji+K7tqQM2/aBwbzxBVFpKmW3FMw8CZ8euuzd+jkalaKkzdTo8vc26vcwPwcBq8xGk01+GSzYCfKlbIbIO+Q1H3uIt+FeSJs2RgAjEHAH6kT1QgbCM2UPPkGZ8KrcjpcJAzIqVo4ThuRcoDMbX64RxsA0v7odAqHX5cDSxwcISa0tB09ZVn5OtwlDoHR1/Y+vz4aNA2HwFqGm0H8zXwsB91edN1/FRsf366O0djBlkbDWf0wHgJWb63NTBxUkrT+np88ixEaBl5i8Ug3nVWDalzrBwfFmee+HQ4stxJZLQdwIiEL4jdl9BkALRIGaPOiYzB1A51LNxCkC/V3WCHKCiknJpXf2Icm9tlyR8EgjYHMSjmlMAeBeg/bvNEZ5FYtzKVIonNR2G20eBUMWrt/TOg5SqOr2tMlHGQXgcTD+d/sH4fYCWWnyljTPxn+bTqdvsvpAiscQ3wPgTi/uvAvxTQHty+h6/XX1MAlhSm5bumBxffLXb0BsiEO7/962YQwSiBUclSIFQ3XcZs8dMrACmb3IH3YqC8ajpIJiXyaBzc7nhH1fj9UsgStY90cRn39iHuKmB45e5SUUC1sMo3MmarjZ+3xuEQFREYtFBuuONs6UTHqago1DZJee8gnYrwMp72u2ljii9u0vndVZHlDYqTASiEaFD474IRAuOU9ACoRAsjw6crIE31lk2mvVgBbDdIP68Om/ZKqwC23gJ+ygQqn3U0xc/gw18G6D3Nxjal5j5j/PZVDIWu+iYAuvqeNXABEK1rbSPs4eUQChRe6eTqchAnomvrDrn2jZruY7PvPEFsh7AkU7qAKDOp7j2+GM56TXCqwiEQ9ItnkwEogUHqBkCUXlgqf0FzaBPMnEMwEkzSxulMBv8nwxsLmqhVPW6fvW51upBZkxOrdi588F9ZsQ+C0SpqrJ3+PlUsvah02aWTsp9IKLbFoV4S+XNuMak1uclpuopp9qrd+3vDkG7ksnoBUgFSaxsYqvloGcZtNUAfXdnZviXTk1izfWUQm93HjgDhNUWdYwDvJtYyxZhbCgcPGrM7ZJSdZ9EIFrwweKhSSIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCAgAuEBmmQRAkJACLQDARGIdhhl6aMQEAJCwAMBEQgP0CSLEBACQqAdCIhAtMMoSx+FgBAQAh4IiEB4gCZZhIAQEALtQEAEoh1GWfooBISAEPBAQATCAzTJIgSEgBBoBwIiEO0wytJHISAEhIAHAiIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCDw/9PUXuoYdJv9AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-18"><g><path d="M 261 201 L 356 201.5 L 356 87.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 356 82.12 L 359.5 89.12 L 356 87.37 L 352.5 89.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-19"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 212px; margin-left: 307px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="298" y="206" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-24"><g><path d="M 211 401 L 211 426 L 51 426 L 51 444.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 449.88 L 47.5 442.88 L 51 444.63 L 54.5 442.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-38"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 442px; margin-left: 132px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">no</div></div></div></foreignObject><image x="125.5" y="436" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABF9JREFUaEPtWF9oW1Uc/n43uc3UgYrI/NMxUfBBxJfaNUtSiboVKVunmUm7qtgHGfPFoi+iqDDElw3BjeGD+uJ07Zorq7M6FYbEpvlXiTIf6hBfRFlZVGZbtX+S3J/cuIwsPdecW0tuLec83vM757vf953zO79zCOus0TrjA0VorTuqHFIONVkBteSaLLhjOOWQY8maPEA51GTBHcMphxxL1uQByqH2+/o2e0xzkBh7QNgMwANgDsDXDLxenL/us3z+reJKjGlr26f7fDP3g7CXiTsBbAHgvTTXBQK+BeHYoo/H8meMGRHGZYc6OyM3l9ibBHDHFYGEdzPJ+MC2bdGroGkHQPxsDYhgTj4Hwv5M0vhSllQ0GvX8PE0xAIcB3Cgxbp6Bt7mov5zLHZ+tjZcitOTjQX2RhojRLQFmhVw0mXtyKWOiUXx7OHqTXqJjDOxoFLu8n89B8/Rnxk98U+1rTAgYBmgO4H1OABnImkvFnZOTo7/ZjesIR1q1kucDgDqczF0XWwDxrkzSmLS+yxCy9oN2aa84wS0zcySbMj4SDarsl6tn3mPmXieT2sROkVnqTqdP/ihDqDpHGcAYNH6ldROmrI/nz3sCJplvArhbBMTAkexEfFDU5w/2Roh4GECLoP8XML+wpHtP5RPDv4bDAxuKxYX2MpkHCfALkwHjnRa98LQsoTKYX2q9BYcMw7CIXW7+cN9tKJmfE3CnAMjweQv9iUSiVNvXtj16bcsCTgMUEIyZQpl3ZzLGD/V9VmIijY4w4SnBuFky+SFJQpxe2oBuu1QZCMZeY8KLy0AYX/h03p1IGH9cIUIotp2ATwTuzGqs7UylTljZVti2bn3kBq1F/1jklLUipAgx4flsMn7QDsQf7H2MiN+XJWQrAGjI573wZL2j9fMGOnv7mCt41hlY0zgnRwjoyU7Ex2wJhWK7CFi++QUO3dP1xDUb/1ocFaVpZno8mxo53ihJhEJ7bi/BkyBUDvbaNi1D6HcyqSudHvlqNQh1dOzdRHp5XLDnGuJU8UOh/uvLKH4qSPd/yhC6aIJ35CaM/GoQsq1IrMO4AU4VPxyOblws0ikQHqj/J0VI5JLfwR76l+Xy/1xyayEpNFzbThyyHPaHYocJeGa5281J26tPKBjtIaKTgvrwPx2sBBxoelKwXLFSt6aXz9jUgCstfQpk0oOuEKosu2BsPxGO2lTxjotTEN7IJOPPuUbIKlB9C2Ss7GJXV/AAZzWz2JVOjxZcI2T9UiAQ2cKa9zSAuxqVO3b9DHwPjR7Ojo98Z8W4Sqiyn/65tQ4BZD2KOGoMnKUyP1p71XCdkMWg5pHkEIBbJVjNgfhVlHA0kzHma+PXBKHqD1nEfpr23EtkDoArjybCZ6wWD39Yf8eqzqEeGiWWg6shyiFX5ZcAVw5JiORqiHLIVfklwJVDEiK5GqIcclV+CXDlkIRIroYoh1yVXwJcOSQhkqshyiFX5ZcAVw5JiORqyLpz6G8sXc9b1Ei9agAAAABJRU5ErkJggg=="/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-26"><g><path d="M 261 351 L 356 351 L 356 87.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 356 82.12 L 359.5 89.12 L 356 87.37 L 352.5 89.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-35"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 362px; margin-left: 307px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="298" y="356" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-30"><g><path d="M 101 501 L 154.63 501" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 159.88 501 L 152.88 504.5 L 154.63 501 L 152.88 497.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-28"><g><rect x="1" y="451" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 501px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">All devices go into deepest D-state or F-state</div></div></div></foreignObject><image x="2" y="480" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tvXuAXEWZNv68p3suASVhUW4miq6XFQVdA5lrh8FwCxAuCT2TIAlgXEDIgqLIT8RdXcHLuqvCD4ygXBKEZKYJgkaQizg709PdEwjyIYsIiAoYSJAvhAiTmek+75c6fcnp03VO1+lbuid1/iFM16l666k69VS99V4I+tEIaAQ0AhoBjYAEAdKoaAQ0AhoBjYBGQIaAJgg9LzQCGgGNgEZAioAmCD0xNAIaAY2ARkAThJ4DGgGNgEZAI6COgD5BqGOlS2oENAIagT0KAU0Qe9Rw685qBDQCGgF1BDRBqGOlS2oENAIagT0KAU0Qe9Rw685qBDQCGgF1BMoiiM7u3q8x8O/5zdEdLcHNZw8ODibVxcgv2R7q/RIxvpP7K+PhliY+dXAw8ndnnR2h3lvBODv3d8Kq+PDAOaW2Xen3nPIx4fLE8MB/Vrqdeqqvvbt3AQE/Vxm/epJbyzJ1EejpCb9tfJLuAeGT2V4ycEoiOvCLqdvr8ntWMkG0tS05wGhKPQTgow4xtpBJ82Kx/idLFU8TRKnI1cd7miDqYxy0FLsQaASC6OgIT4OB5SBMxKORG+th/EomiI7u8AkA3QOg2dkRAr4eiw58rdQOaoIoFbn6eE8TRH2Mg5aiMQgiHA4H/vqKcTKz+W2A/qmetAwlEURPT09wPHnAKoDPzAzBJAADQCDz/0+ak4FjRkfXbC5lkmqCKAW1+nlHE0T9jIWWJI1APZ8gOkK9K8G4IKf6qiM1dEkE0d296H1JBAYJmJXuFP86/V+al+lkiojOig33ry1lgmqCKAW1+nlHE0T9jIWWpCEIIu8eteFPEB3dvRcBuC47+YjxTdPAtryLZZR+Wa0JQn/WGgGNwJ6CQD0bsvg+QVgXKQGsA2h+9rTAzAuZ8FcD9CCAfTN/L/myWhPEnvJp6H5qBDQCU4ogOjvDHWzQrwDsYymXgBeDSPUEg8YWpxlZqZfVmiD0R6MR0AjsKQhMLYLo6r2aCVfsGjxe3xLcOzw4eOuOgoUdKOmyWhPEnvJp6H5qBDQCU4YgpL4PTBfER/pvEMPc2dn3UTasC+v9y7msrnOCoDndfR8wwJ8m8KkAvR9AEMAYCI/D5Otg4mfxeGRMYFDu4FvWF0ljPmCeC9AnAByQwVY4Iv6FmIZNg38y60BORCKRlNvnJrE8E0UjLcEtZ/p1auz02CSISsu9pJ49+7ymlpZtR4OwhIlDAN6TwVj07xUAMQZumxyb8auNG28UFnS+HmFW+OLLgSOIzHPAONZWv6hnMwFPgLC6OcB3y5wzVRqbfUx4ess4LQBjGQOH28bN6gMBTzFzf2oyefeGDT97TaXOSpXp6Ai/nwP0GQJOAXAIgGkAkgA/xzDWpQy64ZGhtS+K9kKhhQclOTgM4B+t9j2cVmXyzZlz+n6BpuBpIHwaRB8CYz/n/E3BvCm5Y9/RUsZSFRM/VkzF+nzk3MWzAiafT+CFNvyyc3OICdd7fY8yWTz7oej8K+QKcmoxmPoAfBDA2zP1irXozwA9AMO8aeYBeMprrbDL4usOor0rfAoR3WUzZ827Z5DcT4gZlTthqA5mvRKENTFS5veJcJoNA0m3+GkyjWWxWP8jpRKEhWUQK8D0VdtAe0DIT5OBi2JDkd+kNX+FT2eobzEz/zQre1Y9GI2ue151bLq7z9w3hcn7AGpz2wSUShBi4X7pZeoF8F0A71KQ6a8AXRCP9v/Src+OOqhzbvhoNnG9sDdXqH87iL+BJK7LEn6xd6yPP0XfAOP8zMJb7JUkMVamkk1Xjo7e/kaxwuX8fmRP+MDAJF1XfP4iycAPW4P8lVQq9fZSCCK9iJpfJ2BphtyLif5XAJfNPIgHVBevYhXaf68EQYj6diTpagIuLN6nXWuAU85KE0RbKHyowfQ9AMd4r0s5SZ4kgy/xWiuyJZUJQr4DLVz8O7r6zgfxj2yg+L6srkeC6Jwb/iSbdBuAgxUn5hYYxulg8zx7KBAVE7b2nsWHUDK11rYIKzaJFAjfn3hrxhWy3ZjsBMhMZyVG+m9XbaC9u/cYAsSCnHWQ/FPK4HkbhiJ/ytZRCkF0dIT/AQEScpygKkuOoICrxsdmXO21AxWESwHjKgZfovgR2cTgUTOYOmN08K6XvGTL9KE/86H66gYDz8Cg0xJD/b/39aJi4Y65i/8ZJt8J8PsUXxHFHjI49TmTAsIhVvkEUcK3khUpxcDq1iBfXOrJza1v5RIEzNRFCBi3+vwmtzPTOYmRfrGpzj0VJAjq6O5bCrCwKM2eFlSHNynuiMfHZnzH67tRJoj2uX0fJtNSHx2UlUC2uBT6SAB+L6vrjSA6QuE5YBIxW7KqsywE4li+ETD+D4hbAHSB8V7bDv0ZIrwGRkcOsyJOMJ2dC9/DRvBeAIc6RjoFxotMSBDoDQbvQ0A3gJmFM4JunBibvkIy8NQR6rsWzCt2vePvhNfe3XsNARfn+gPckogOLLfv4P0ShKWO2UERhqXuyX/S+A0B9KpHn1MM/lIiGhG7qIJHqKyap227DuDzZPUT4zEGCYILMPgIAj4i2SE+RWbyxFjsrr/4bGMMzE+DjMcAQeCF88Q2FoMTrTht40ORbapfuUo5jzklTgr/S6BHRT3yvvPTAAm1Zto6sYiKqTPUu4gZYiMl1Fb2R2xeBMYjYBon8HsZaJctbEy4d7KFz6wkDuUQBAP/h4BxAHNsHdpOQMKaN55jit8nDeP4rMpOvN/Tc07r+ORbK0D0gXR95tFA9t/WHzYA9HiuLTY3xEciNzm/jI5Q+Itg+pZkw2MfVzHnDgPj47IxIdCN42PTL3EjCWWCcPo+ACjYOaY7X+BlLf7s67K6nghC6FCN5qb1lJ7M2UdM9p+mxie/4NQfz5kbfm/AtI57Qg1V8HidIFwWyhQz7jYDfJl9l56pmNpCSw4zOHkTQEfY5XNbMCUngJfZoHkqO9fZPUve0ZxM/hogoVMXzwTAp8ajEWHVlnv8EISYLxPJA65l8GfzweKnTcbF7z4YD9tVDpYa6hVLty9i1bzT9s4mg1PHjYys+1+1D0lev3g3M+b/QbDURNnoAOKn+1uCfIZsd9vevbiHYApizy6MYjf8rdYgf0dWXsyToEk3OEixLAdT2XxL32HRnQCOz5sfjLtTAePz9oVL/F5UjeoVONM6pZhiLtg3UikirA0gednw8F0v22W0qRSvcYwlCLSyObj5Yr/3YzIM0uuSerC+gjuI/EpfZabPT+6YPuBcVNtCSw43OCVOwc74dCvi0YHr3WQrRQ2dUfcLR2Q7EScB+i9zMvgtp7rSQ2XtublSIggXcAt2jlkAnLpusXPy41ldTwTR3tV7AZHlFJhdKFJgvnLmwfium67Ua8fqRRASK7CibeUmf9L4IcBC35t9XkCK58XjkefsE1OQUPMO3Lvzwqoz93eboYHbJBZ/l8TfkhK/H4Jwmk1n2n8IKe6LxyP/1/2jkpzqiK6LD/eL003uDqatOzzb4Z8jqixavwgL0B4Kn01MP7Qv+kQ4JzY8IO5x8h7nyQoSWZzvZMbiboB6dv3m70TnNV7it85Q71nMuNU+f6mISs4yEpj2+lcYuLJgd+pCEJlAc2tAdKpNJnE5elk8OiAwlN6LibJtPQtnGsnAnQ71zZjJfOroSET4VpX9VIggnkKKT3V+U3bhpKe1IqcuvwTR2Xn6/qbR9AABH7O1vZWIl8aGI0L96/q4qBrdNldC+1P8kXzE0p1jtqaOjvC7EKRBMISFT+bh+5DCIpXLvnohCNliSkT9429NX1rM4kL+8QNuBCGPjuuqKioYNNlJx021VximXWlRKlBPCQ/62MjAVySLpWq474I6LV180Dg+Mbj2z8VmpoRQnadaiUoNnqoiR5vU3t0rThJioczO49hEK060qz8OP27p3m97a/xn9tOAaihpJ+mWYjjghpN8M8D3wMSSYt+hRRJ7bbuNmYVFjK378tD7MqJn4KpEdODfVAwIhGUVAiRU2O/eBbWarMXmifi9AgShTFgybYsZTM51u8PyTRAOY5P0Bly+cZFh09W1OGSSuT7ry2aVIfwgPjxwqXOslAiiYHdUXGUk+zCVL6vrhSDausLdBllOgXtngH6DTD4hFovEVSalLOKtG0FITl3SE4BXu4V18BMTweC8jYNr/mZ/T7KrLqpmkhCYKxaqJwjZRkLlEj/bl4w6Tywq4t5HPClmWpAY6b9P/I/sdz8fkksdEwyclIgOiFD31iNdfBQv/zO75wcBEndYjzPoqSYyrxkejryqMse8ypQ7fyVm6653ECWsEQWiSxbWrSb42NFoZGO5WJRNED7MeyW4e/bDD0FY9xfJNyMAnWxjbeXNd+adwvWZ8ByS3BOPR4Q1We4pShBSyxfg2kR0QFiDuD4SXbfyZXW9EEThDpVHA2iaH43esVVlwkpMQt1OEGKnehMB52brZcnlb7E2JQYCb5rMJ4yORKL2d+XmyPDUkxaaOHPBTjrbhipBSOaI8iYivTD3BHck97+NAKEu2wjm33HAWJu9TymQ2eUj8MI1fae2/x0AwtlykpMTtXf1ribCWbbxq6pVUrG5IH4v8Ffxschl8XX2XXZJLZvnbqdLL7llBi5QVH8Ww6NcgvDTH0k/KkYQMoz8WiIKrCQkVrDxEeWKEoRkZytddJwDJJs0qpfV9UAQsoWBFYjRiUNnV++PmfCZ3MIhsWJyIZJLE8MD3y828e2/d3Wd8naTWoW11VG5v7t8YIXmyJ4qwEIC87DGUiaIUO/niWG3PPofg3csGBn5+XY//XYr61wgCXjw73u1nP7EA7e96af+9lDvFcS4etc7hSo5yXciio8xcM9Oi51VLcG9B0W0AT/tllNWttP0s8jlyN45RhKS6ewMfxwGPcjAOzLvSRebYv2R7o4VncSK113eJTUzLXKaq7q1KbnkrhhBtHf1zSdi8Y1n70SLnv5lckoMTqSbV0+CcPF9cN05FiyOhSlJlS6r64EgZIstE3wv2u2OD0ymQpHunID7AZKaVLpNTAY3UdpaJeer4bYoSNp03b1LVEGeO31Vgig4WjN+mhgZWKaisy6+IBTu/AF+FjCEI6HPh4WJoM3EsfAk6WLtZm8nbXrI6OcA3T3rAPOZajiEZRuULgA+FrkcQTgXJAlBlGMZJ9lQ5Yfy8XnqcRvYMk8QearLYpOnmgQh2dhJ1cjFZJRtgCEhY0+CkPk++PFpkFuoFL+srgeCkJm6qV482gfHuVjKCMLF0qbYGKv97rIDczFHlqqZJHcbnt7xigRRoJYhxk9iIwP/otYx71K+nZH8NfrHICVDTrPNrq7FR5hkCqcyFWdKcUpaTybdOj4+/TfFjB78iZe1DAoO2e5nhBmR7xzMBXNTThD5RgmAFB+VPvj59lXqy5YpkyB83YVUkyAqiY9zg+abICSXRn7GxK1s0YtePyCodLIUoac6QQhMJPcKBZddMiIppvNUIQjpB1vBTFq7gyAEpkX9COSTUZiD3hyk5NVO0ill7op3JJsOX4tctt3dThBlkI0dO00QhTOpYO2UkL/rCUJqIlfqbHW8V+wUogmiQkCLajx0uBIDhALVkcQSSOog6XVqkl1sTlWCyOKQiUV0SSYWkdMD322AN5HBS2NDkYfLnQFThyD8GYZUScXki1wb9gQhCd7pShAuDkzlztvs+56e1Zog4GtCljEohX4Ijl18e1ffp4isAH+Zp3imQLUThNQ6qKoqJj8mtGVg6nyV2nsWv4cm+XgYfLZLyAP7OyKG1wnxobW/LUeGtPmsVjFpFZP7LFLRvrgRhMyPQYSX3gSQ+K+/h3i6LcyveNfzsroeCKJSO1znAitbpCRWIL4uxfwNRn7pAnM32zFTcpHl6SCZrVmFIETZal5Sy5zXKnnHUSrmwgGttfW1D6YosJQYfSAr3Hb+o+CFXax9cTqkptQQpcM+W48fS5zcWNb4ktrpT1Gq5ZkTn6miYqrcJXWhP4Xs+5AShNyrt/jlstuklTmMAe711QNBWKEWCm3bXcOLuPXdaWopvaSWfcwV1Md7LSYSVWLu9CIxUlCKqaVKEIXmo/Bt5mq1RbgFzK+A6FER2K8luGW1iOHjNDEuFmiu2KJbhd+pI9R7HBir7fGLhDc5Twbmjo6u2Vxqmy4EKfV892qjYEGSXVIXBvIsaYNTTVKfKgThtBgj4G8w+dhYLLIruJ/CpJFuICRWmlKCkNl0F7uY9FyECoO8ieLunrih3i8R4zu5Or0ChIV6b7WH0/bSuSvgllfEaaIKyD2T3epVPYVUyDsSmUG/n4B9CfiDCfzeMPmWYpPHGXojS2LOxUHVD0SZICpg012YvGhXEqRKhJ4XG4VMBFzhKPeSiLLJbD7Y2vTqumwgOYtI2TwZTCJq72wGYq3BLUtVA821h8LnENMttnlUERWjJLGTL49bqSmk5FvcAxzlfI1HNe8gdrujnHRSuERu9bPgFsb/AVxj+dQJQUgu+iaYaYmqw4w0Po3LyUBiMfaGwcbJIyNrRTYvpUcSmE3JYakwpIJwBMOS8STdbPMgVnKQFIKqEoTkAly87unRbQeiWOBBWagIP/GBRFuyGEFOoizXY7tSF8rOSSLxTyhqQWivQx4fSR6LSRJqoyDMdbFJLImt5Wth9qp/qpwgpJtJn74iVgTlyf1X2h14oRpqw+Wj8q1acQ6WNK6LS0ynOlExicVhGgJYB9D8bH8YSJgTkycXSxPpFuzM7aK0q2vRR0wKPJDn5AY8ON7KYZW4+JlLSRGDyB5q+LHUxORxxWR19lMEjDNM+oxIZUrArHTf3UNrSBYmpWB9UhNaP8H6uvoWEvEaW/KiwgyHBpwRRreAeEF8OLKh2ILlEop8jGGcmIiuHcy+L9nV+QqeJsnU+Cev4G7F5M7+Xk6wSdcw7C6LUVWC9XmooVUxyJabKgQh+iOPll1usL7CSMiirQIVk2Qnq3QxWWzAXE4m0svqeiEI0ae2rvCxBpFwfrLFXafbWoLmhW5Zr6w495twGYiucoZL9rCkEfro74HxuXwsvdvK7HKnkUHX5u0IrMB1WJEYGbBn93MdJok6Riy8Iv2n5dLvxwJI9QRhTfbOcAcbVkDEfbLCiYvJYsSY2d2KccklVhKXbM1NWz5rV+3Ixk8xexu1d4V7iSzVz66x58IIoy5Oh0pE5BL1t6Rc4bLBlYX7Lhau3lKrdfeKtJoi9Wt+4h9/4b6TDL48EY2IkDG+w30z8+LESOTnxdYWld8biSCKhURxCfctzV7nxMYl3Ler5VweQch9H/zp3b0GSx6vpvCyup4Iwi23gzhJMPHy0eHIU/Y+W0naW5r+G2wFbrMnm0nvwz0un11OAeKtRxmBFYnoWrHrzfvQRD5aYhKB/uwJjQTzF11k8+ROJzqyR0a1/+wriJ4fgkjr+GXEyI+aFFw+Orzmd/Y+p5PMiMxzJDJs2T2WpTHt3RMSYSuYL4OJO5yhr9vaPrVPIDh5FRNEEqOgDQjXRV8aQhlwTS5jbT6sXMJY5Uj2pBxWWnlhlCQMckvi45EsKd1cCQmDRMIrWXIiMZYvbjJOJeL/v9D7XD3UvTIOk3QPCJ/MlnfzLPd7h+Bs3+/7EvVc0bwTbgmD3PKbZ1Lunsvgbzuy+ImMc1+OD0f+S0bieQQhifCnHIFVZZDk1lGFl9X1RBCiXx4pMe1pFMVuyS1dZQ6eYjtxj/Sm4ryXS79ppTk0cZTUTBL0PAzztPhQRCyuSo/LLjjzrj8LNp8E4YWvaP8lBqIizSrA7wRhrsNkWpQZI8LS2PDAOllnPVOaAmMgPA6mDFbmxwCaLUk5OsbEX0gMR1a6AOpCdFbp7QD/DjCezKyyIhOeiEArUnk6nsoujKJymfoy06hCylGRNTCXf7wmKUf9bm5UJnhdnyC6+s4HsfOkn3MrIMZQc9O0zzqCPVIFUo6K/ZlbemILVjtByHwffF1qqQyUxOoEzuxb9UYQol9H9oQPDCaxJj/7V9EebyLGrUy4IrdrUTBfLTHBfKYJQQ50RimOVhJdeGY9owviI/03FO1tpoBfgsiScPMOEmlEhVrLzyMW7gsTw5FVXmqM9Om4pPotAlLJjJZO71mQ2U+1LyJF6erWIF/sprpUrUhWzmecqGwVAxCbDfD/l6tT4UI0E3FUjIc9JayK+KmdKsOBiVb+rMq9m0qF2TL1TBAeBJ4R39WbnDq7+z4rORWoQCM2B/89OTbjq15xwHIEUW4WOBWJRBkXD+08+/p6JAghu0deV0n3eZiDgWVImocRkNOjFjtBZCsSag5qmvwGASJ4nTMBvAzupNvxUnVsXE54RUNrOOsvhSBEHV45imV9cFPzufXXVr/Qrb9LBZcS27hg5wlE3D/NUGkDgEjSctnMg3igmhFefcSJSopwOONjM77TtNfrIiR7zuRc1XFNtNXE/F1mXiQ5jcm+l6eJ8MXYcETk9Xa9r1DEs6BYPROES3pbGyfjxSBSPdHouudl/U+rKq3Nj1AzF6i1ne+IOR1g419HRtY+WgzPHEG4xLNXNjks1lD2d5dkNXmX1fVKENk+pPW0wbMJdCbSnqpvz/wmHJseZsL1sw7khPjYVaK5emFnqUfGaQEYyzh9IXugbRJs3pmH+o9g3JyaTN5dzFpJZYwK9aHFQ2tUiiCy9Yh7n6Zpr5+QiWMkVDHZPqfAeJFAg8LCKouxSr/sZUT9wdatbQEYy5nMLoBm2khYqINeYNB6E3Tzhmj/s6UsWJYVW8u2o0FYImljDOCXiI2RFMybkjv2Ha10NFcPTKgtFP6wwcZ5gHk8QCItsLhnSQL8HMNY10ST12eDBhZ8iz7zM6RjUqXCBCwC0Yds6kFxKvvzztzoDzBozayDUo9WkxzrnCCs4cos9CK9rbgnsasfVUzMaU533weCzGczWSH/7euSiBz8DDHuTxKt8jOniyYM8vvx6fIaAY3A1EGgIOlSBUOyTx2Upm5PNEFM3bHVPdMIlItAYbgZhTu0chvV79cPApog6mcstCQagYoikFFv/jgdIgSPEtF9zYHNv1QNASK5kyopxlJFO6UrqykCmiBqCrduTCNQOwScITyEh7zXZadTMqeTnd/3a9dT3VK1ENAEUS1kdb0agd2MgNQykfnL8ZGIsErytBSS++P4N1jYzRDo5stEQBNEmQDq1zUC9YqANCgbYJlDJycnvy6zerMsyFq39RKxCI9h92OoSCKjesVKyyVHQBOEnhkagSmMgJcXtTBrBdEomMYt02k2PwGif5L43RTzIp/CCO7ZXdMEsWePv+79HoBAJuz37fakRD66vR2gFfFo/23F1FI+6tRFGwQBTRANMlBaTI1AOQj48KLONiPCXiRM4vOcASnLkUO/21gIaIJorPHS0moEykIgz7MZ9I95HrtWMEj+AwPrUkYg8sjQ2hfLaky/3PAIaIJo+CHUHdAIaAQ0AtVBQBNEdXDVtWoENAIagYZHQBNEww+h7oBGQCOgEagOApogqoOrrlUjoBHQCDQ8ApogGn4IdQc0AhoBjUB1ENAEUR1cda0aAY2ARqDhEdAE0fBDqDugEdAIaASqg4AmiOrgqmvVCGgENAINj4AmiIYfQt0BjYBGQCNQHQQ0QVQHV12rRkAjoBFoeAQ0QTT8EOoOaAQ0AhqB6iDQkATRHur9EjFE0pP0Q1gVHx44pzoQ6Vo1Av4RKJijfqqwYiLRNgL/0QT/CsHAXYnBtX/R0VT9gKjLVgIBTRCVQFHX0XAIiKB1QTYvpRSvisUij1e6A2URhFQYfpqZ/n3WwbwuEomISKtT7unoCE+DgeUgTMSjkRvrrYPhcDjw4iZaBMJhiejAV+tNvmrIowmiGqjqOusWgba2T+1jNE98DkxfBJA0wceORiMbKy1w5Qkie1jGg5NBXvbIYOSVSsu8u+oTC+9fXzFOZja/DdA/MeHyxPDAf+4ueSTtUnv34jmA+QMC2vckjYUmiDqahVqU6iLQ2Xn6/mw0/QbAoZmWtjYaQQi5GXgGBp2WGOr/fXURq03tHaHelWBckG2t3giiPdT3r8RWCtaAJeMepNLWBFGbb0C3UgcIhEILD0pycBiAyIMgnloShFJb1m76r8n9gOb9mXgBiJeJXbUEvqfITJ4Yi90l7iYa+ukI9d4Kxtn1SxB77p2nJoiG/rS08H4QaASCcPZHEMZLL5NYPH8A4O2O3+9vCfIZg4ORv/vBod7KaoKotxHZJY8miPodGy1ZhRFoRILIQtAxd3EnTPNnjrzSKWasSIwM/KjCUNW0Ok0QNYXbV2OaIHzBpQs3MgKNTBAC985Q7yJm3AZgmm0cnjQnA8eMjq7Z3KhjowmifkdOE0T9jo2WrMIINDpB9PT0BCeSB1zL4M/aoEkR0Vmx4f61FYarZtVpgqgZ1L4bqhuCSNulpxbDxBKQdSkndklJBv4X4NU82fyT0dHb3xA9LNdRzrJnfjlwBJF5DhjHAngPgGAGvc0EPAHC6uYA312ufrenJ/y28aQxHzDPBegTtiTxSQB/IaZh0+CfzDqQE6r27QULHePhliY+NSOrZZJHMC8B8Elbe9sB/h0RrSy3X7XAb/Yx4ekt47QAjGUMHG7rh/ABeIWAp5i5PzWZvHvDhp+95jbz27rDsw3QgwD2Vfk6GDglER34hUpZrzISM1elS+pi7XZ1LfqISYEHABy8qyyvbwnuHR4cvHVHsffL+X327POagq1b2wIwljNxKO+7sZz78Gdi3J8kWrUh2v+sm2Of9U1M0j0ga34WfxSshnp6zmkdT77ZA9BpAHcD9G7HnY2Y/y8AxkMMWjProNSjXt+bk7Q8hcz//lyLzplz+n6BpuBpIHwaRB8CY79M4TEAfwboAZPMG0eHI8I6jYsDU/0Su50ghF16IDh5FRPErii7SMt6/ipAn45H+3/ZHuq9rERPauqcGz6aTVzvYhnibHc7iL+BJK6LxyNiEJUfy+kniBVgEg5w6MdNAAAgAElEQVQ1zstFST38NBm4KDYUEWaYnpPDjSDGx9FMQeOHzHxGziRPLvF2MP5jYseMazZuvHFSuVM7Z3C18bMWjxR9A4zzHaoUNzGTxFiZSjZdmd1A2AtONYIQp4jx5AGrAD4z208GXgwi1RONrnvex1j6KUrtXeFeIvpvAO9SeZGBBBMvHx2OPOUsX0mCsPxagskrQSzMZBW+sxxqnt9bJQnCxxpnCeeFnQr2lSyzWwmifW7fh8nkAQAfVezUGDOfaxAdwsC3c+8o7DDEgk0B4yoGi5112p5Z+eFRM5g6Y3TwrpdUXmnvWXwIJVNrAWpTKW8rkwLh+xNvzbjCa+GWEYQBPtckugnAMT7aHJho5fM2PhTZVuydWuDX0RH+BwSo32cfsh+V1DdgqhGE6Gx7V9+niPin9nnDzAsTI5GfFxtHv79bVlSbcBmIrvL/3WCMiS9MDEdW2Tc9lSKIjrmL/xkm37lTw/A+v/3KlE8y+PJENCJ8HPI2ZZUiiM7OviPZwNoSZBQb0svi0YEfFtswlth3pdd2G0F0di58DxvBe21OS1mBUwA/DRiJNJvyEQR8xHa62ApGDISTVAlCHI2bp227DuDzClAhvEaMxxj0J/EBSNrLvqJkd+7ZL8aLTEgQ6A0G70NAN4CZhSNFN06MTV/hRhKFunSOMdPLRFhkq0tMsBGAns+0JY7z+/ttS5SvBX4ebYyB+WmQ8RiAFIhbAHSB8d7CBYsHJ1pxmp3w0mTNnxOnEWbeiwinANgng8MEwOsB4285XAz6UXxo7W+Vvh6PQtVSMYkmOzvDH4dBDzLwjqwITPhKYnjgm+XK7Xzf5WI8Bdtctt4hPgyMj0tOfVsZxvxEdO1otm5LHTT51goQfSD9N/NoIPtv6w8bdqqKdoU/YXNDfCQiNj+5x+M7s1S3DDwivjNLNPB7mfAJm0rHXpVU9dfRFV4OMuakC7LoV+bf1v8/CxjipJ/5mZ9tadrrOqeKryMUngMmoa50fndJgJ8D0SiYxgF+JwhzJfKJ+f7l+HDkv3YXSewWghCLQcte225j5j77SBHwYNLg8zcMRcRinXuE7s5obvoPgqV2KNz9e58gqCMU/iKYvpX/Lj9tMi5+98F42KmL9GjP0+7c0pvvoAjDutfIPsIU8W4zwJc5+yXmbltoyWEGJ28C6Ii8d8BfSkQj37PjkP235LLVXkyqcknb0wu5rFOGTX+NFHu0JWSsBX7t3Yt7CKbYMGQtdFIMfKs1yN+R3QPNmRt+b9CkG5xYe13YNvoltef4K5yiZXPJ62+Wzry5Sdx3iLuz7Go4mDLwaclchjgZ7EjSFwi4Ml9dTHe0BDefPTg4KBbvgsfvJbV1WT+5/0omfCb/m8EN5sTkv7ncSVF7qLeTGMIkOF9jQXRdfLj/YrdFuJQ7TxcCs77N5OTk150yiu/zhU34pEHGjxynDaE1WVyN06HKfNgtBNHWFT7WILrHvtsgxk/Y5Is9dP0uC5W367uLiuEhpLgvHo/8Xw+QqD0UPpuYxBEvt2gR4ZzY8ID9eJ+rQrJrTIH5ypkH47teF2KZi+wfArzUJs8LSPG8eDzynFNGD4KQHunt73d0hN+PgIV9NtyE+PlPKYPnyT76WuHX3t17DQHiI00/RT5aUUQQcvMO3A1Qj20Bc72wnSoEIVXRKF6UqiwK2TLt3b3HEPBLAM2Zv6mY1FJHV/hykLUhyz4vs0Hz3EKD+CWIzs6+j7LBv7bvzBm4KhEd+LdiO+1QKPzOJOMX+epfHg2gaX40esdWGT5+CcKFwCz1eGIkIlTqrneMR/aEDwwmscY+p8WdhDkxebKXMYafcfVTtuYE4XLJpgSAOHk0TXv9BgLOzeuk++6JOkJ914J5ha28kqoou0y1d/eKk4vYEWUejk204kSn3r6tbckBRlPqofzdibeqyN6HzKllvRUMLNs48PVYdOBrygTB/OX4SESEQfe85G7vXtxGMO9zWPasiEcHrne0VRP8Dj9u6d5ve2v8Z/bTgKo1UUd3+ATAIjxrEfO6sNUE4WdpsKwFP0+MXadYxVOK7FtgprMSI/23yyTwSxAdXX3ng9juHKhCXLmmJXc4fzKDyblud4x+CUJCYL5URZlNnCBAYYklnt1mylxzgujuXvS+JAKDBMwqpfOy3YNb8CyhhgiYJIAW+uoM0O4nANnkldQxsVO/eVIiOiDIIPd0hvoWM1sXh1kVmOsJwO0zLayDn5gIBudtHFyzS0cOwOUEofyRSHc4kh1orfCT7Yi9FhQ7fm09C2caycCDAIm7iccZ9FQTmdcMD0deVSDWipieysazmncQ6U3W/ncACOe2LcAzPBmYW0mHOUkfIi3BLWe6qYpsOFBHd++tAOYB/Be27hOM1fZ7CDtmfgmis7PvODZ4IQChlp1JjJtiIwNfUaU/yanYcx74Joju3q8x8O+2sVHaAOetJ446xF1ZLUyZnRjWnCDau8KnENFd2YXUr4me7ONwIwhnWyA8hyT3xOORv6pOJll7xPimY0JSe3fvTfaTDQO3JKIDy4vt5u1ySMjzTZP5hNGRSNReTkYQ5HLacOunRH1QoAaoKX5dvauJcJZ9wat0xNKpcoIQCrh2B14A/hikZGh4+K6XVed2sXLtXX0LiXidrVxRFWaxOmW/+yWIUtrI21QU+sZUjCCkm50Swpe3dYW7DaJfAdhbyO53nSwXo+z7NSeIzq7eq5lwxa4O+GdG1aOvsy1xCf73vVpOf+KB2970A2B7qPcKYlztJnN395n7pjB5n12vyYRLE8MDwnxO+enqOuXtJrUKq4ejci8xXRAf6b+hCEFIicSr4fTOOzhkP10x04LESL9QPVlPrfCz2io8gYk/jzFwz04rlFUtwb0Hy3UEmyoEITcTlZ82lSefpKDkBClKCSvD34LxIzMZXF+JE8tUIgiZhsT5XamMieT7lGouVOoqp0ytCaJg5yMup2MjA//ipxPtXX3ziVgspK7x2aUnDad5mnKjBWZueZdakkkhar4fIF+hmBncRMDxdisjyWlFpmLy1KHKullsp1NL/IR8sjsYh9yWVz0x+jlAd886wHxG1fM8W8+UJogqXFJbJ5WCO7iC2fQSCOuZsa41uFe0FBKvBUFYprWpNw9npoXE6APhEFtPKnaCcO78ARSaUiusOxKTbKiqXRWqVy5SU4IotiipSl2gQ5Rcnvl2xlFtPF0u7zjv1xnLV1OSvkkWuv8xeMeCkZGfb1etu5jqrJb4ZWXu6lp8hEmmuHC2m+G6dUn0dT2ZdOv4+PTfqHiETxWCkJ1YnafjIqbQbpgWqKmEpVjTON1BjBMV5paw798Ixo+LhUCx11Upgsjm0jCNlkPB/C4QzyHwEY6wFrJuVIwg2rt7FxBQcYdFIfTuSKSkCUJh1kuK1BdBlLh7LPAWtZHR7iAIgbOIyRVImd8nwmk+PHeFU+DNQUpe7aWDnzoEUWDoUZDlrFIEIcbEf9gY64sRMbMSDOMLiejaDV53ceUQhOV7kcIZYPqcw6HWz5etCcIFLU0QfqbRrrKaIErDLftW0QtViyhM8xIChG+IxANcKsAmMnhpbCjysOzXqUIQEjWG2F3m3XlVkiCyWGYXY2J8MRPLTCVkTVIYUIyPzfiO2ymvFILIJFLq3WmqfQ2Ad/qYjkkwhFpMnFKz/h2aIDRBVO+I5tdszsdklhYtEs1VqfpM9MsIQCdnX7AfYSulDlQSxrsQtfcsfg9N8vEw+GyXcA72GrbAME6QhcuYKgQhMT8tuMCsBkHYQbZUTztoLkFEX8ZxLmEssq94euv7JQgrLMter38TjM8XOWWOAfwSgzYaoGHi5P/s2LHfM8FpWw93RPitJkEU3QxV4BupWhU1PUFYx1VH/tlSEoAX7KAkenqZ81UpF+IqyEti46RKsVxQaUuUcX78Iom9Xxv4YhZTtcRPtd+inFgcWltf+2CKAksll43pqly8sKcCQVjqngDWATQ/h1sJ5tt+MFcoS11diw8ykZoPwr8ANFsSmdnVT8cvQbR3hfuIaLXtBCBETIL4YTbpDpMovldw2gtuF+Z+N3R+/CCcBjQE/A0mHxuLRXbFllIAtF6K1JwgCkxGS9CfF3hCunh4dnb1/jgvXksJbakMlPAcpabUEAEflO3GVerwU0ay0HmGMpDVLbG8KtiF1go/P313lKWOUK/YvYrFIqeGciPMqUAQnZ3hDjYs+/hswEFhI+/b56YMzIu+auV2MVOr80OgwHXT5IcgMuFV7hWR522CbCKTz4jFIvGiwgGoJkHIN4vVibSr0tdyy9SeIJwmqoDfxa3AKc3tFCJxyd9CJs2Lxfqf9AFcNtyE8Fp9SUSZZDYfbG16dV3Wo1SmrgH4PqSwyE8eiQzR3E/AvjuP7n8wgd8bJt/i3H1IFjrfrvgqTnC1ws8K+87myWDqEIcEBmKtwS1LFTx2rWFsD4XPIaZbbGMqVRk0OkG4xPgRZpSnxqMRQRoVe9Kh1w2hfpwLmCL8SyAA8yTVnBNtcxd9wDADIuJpLn+EmxWOH4KQ3L+kvOKjyQCROABWTMU0u2fJO5qTyV8DJJJcpR+FuGJOOUXECNPge3eG+REBDh8n4Flivn5kJPJCxQZZoaKaE0RHR/hdCNIgGO8vZbctdd5xO0GUEdQrK5skLorYsV2biA6IvBK5p6O79yIA19n+9IbBxskjI2uHFcbBKtIZ6j2LGSJEQfbyT+ocI9cve0fMtMsgi4cFFL5fTlA0P/ipkJUXhqo7wkYnCGno7SqdiiXfacpPzgk/d1h+CEISR8n3BlMSn61iBJGOflwQ/81v2B2Z/4nffqouO57lak4QZQIod9xxIQhLX2tgDYhOtaGwBcQL4sMRYXrn+bjkAB5jGCcmomsH7S/LUkEK2/TxVg6rJOTJeE4KL2Z7KOLHUhOTxzmjOLpcQI6ZzKeOjkREek3PRxJNV7oLrRV+8vhc6jGzCggGkDoONjJBuOQWqFooaKmfDFH/+FvTl6r4nEg3gkyLEiP9IsxO3uOHIJynWr86/q6uxSGTzPV2FR2AShIEZNGqAfXAnelESKY4Edqs9/iuluDenyrFEbHYeuD1++4gCLjk1R1MBrHkkcHIKy4CZ9MeClVCNvx2uqhHlEnZYAkdtUKcH3l7zPeIvNkS1ZHQh38PDJGcxvbQbS1B80Kv3NZWtjaDri2Ib89YkRgZsEettOp1s1BR6Zc0C5fHLrQW+MlPNFAicnnIb0iDyklw8x2iRPVjq1SwPstip3XrMhCJsC2OlJrqi46q3PZykvAnqlFJC0J+e8USchKELHpAVq6CKAriB8Uoxpn7mzsljpivk0nHxWL9j8hw8hu00GVjlSLgqvGxGVd7EaxLVkXlzV8p41x3BOGVhEaWl9k9EUmmax4E4XIKEC9uBfNlMHGHc7H3yCHruWi5nALEDH6UEVghcxhqC4UPJSYR6C8X5jvNee6njyImjCKK6SUzD+IBeyiKTOrIPqEPdYT59lSF1Qo/l53dq8z0+ckd0wdkH5XAzmCsciRbcv2YZPphhTwkJX1zpRKEIIRgcPs/UBN/mMg8FQyRe7rAD8TP6bSkDriHP3FNeiPaEd8ONU1+qyC5F+EH8eGBS2UOcwW5QICnkOJTZblQXOJDjQlfC07xtbI7P3Fp3mTylxksQvpI8957hZeX3cXBME6PD62NuWErPwVYbLbeYHxxZCTyB8e7Hvneq7sRqEeC8E5jCbzEQNRKGeieynBXv4rEqXfJ9JZ9fwyEx8H0u/QfzI+5mOmJSJZfSAxHVnoB6pFmUKz6r4ExBNCrVupME0c5YsJkGe95GOZp8aFIRqb8FmWX1EJwAE25kva2RErDdK5qZ1J3pR1hjfBzOYFZPdoO8O8AI2NcYPVHWLEcUDgW7h+T3JggWz9Z4cEJ5tdi0chtpS6quZ1uqPdLxBC5Oarw+MuRXo4AcnWJVWN+2kwxn5nbABJ3i85F2DMHi2QBztSPTQAJQhpqbpr22Yx6xSs+lOo8eZWBHbaUAyLOkVT9JQSRRD4Wfxae4q8ANA4yn0uNJ890qoJd0rVmhyO3xnmmBCbEg0guqmSUXj/zYbeomLICumRSKyb/dgJWMoS9Nfa1CiskMkmrIuhGAML70u/jK4F4ecnU6XkYdIZXXmSZLp1AVzJYxMRXiWMk+u+rT7XAr8T5kB1LkaJ0dWuQL/ZS57V39V5AZBkTSL2AvdQbfiaN5ATh53W3ssJa7U5OmhcWyYZYibaydcgyK/qp/0k2qNctm5yoSK5ytjeRn/HNZ3woh6w8zMHAMmPS/IpdpeuV07uz8/T9TaPpAQI+Juu4l/qsMxQ+iZnEhiO9Vvl6arcRcBNrtxKEEMqfyzw/TaaxLGWYZp4npAJBONr6rt38zmvMRLo/Jl4+Ohx5ys/YZo7a36A0keXfmcgrkuaSlhV1u2ylYOA1Slr256Fq9Mk2VlXDL9PGBTt3oVcBmKGIucjvcZlTrSZ7V4GEVJPieIpWYYJQjmukiJfvYp2dfUeywTcX5HN2r0mEav8xTzZ9dXT09jeKNOhJQrIFOKN2vpqAC93URo42/8iMK2YdzOuE6rXg1FLEGixzihAZ8WRhXzzvsiwVF/N3mXmRoqzbQfwNJHGdHzN534Oq8MJuJ4isjGLAJ1J0GjN/Ni/6oqUq4Q0MWjk5NuNXQhetEs3Vq++Wnrd1a1sAxnImswugmbZFXBxTX2DQehN084Zo/7N+kv4427XUM+O0AIxlnM4DfaBt97p5Zx7qP4Jxs5/ol17WOFZEy1dwAjMuAqg7o1ZKgfEiDPzKZP7JaDTyWFl9qgF+YoxaWrYdDcISyRhZIRSIjZEUzJuSO/YdVbGsyY5NGiNrrl0K0GH5qjfv/MQK35RVpEyCEPPibwBFGfjlZCsPqVjCqcpWRjma0933gSDz2Uw43lKPMvbL1GepXEjcHxBWj7fwL/zKnL5TIpHe95MO9aHrAmw55aVSnwHRSUg7qmbVqOKE/OedDnUPMGjNrINSj9rv5CQm3EXN0tMOgOblYJwEsjJi5k6hKqG4hZ9ToCnVx+A+gP7R1seMuoqfAIxbWoLmfV6n4DLGz/erdUMQviXfg1+opbnmHgyz7rpGYI9HQBNEA04BTRANOGhaZI1AAyKgCaIBB00TRAMOmhZZI9CACGiCaMBB0wTRgIOmRdYINCACmiAacNA0QTTgoGmRNQINiIAmiAYcNE0QDThoWmSNQAMioAmiAQdNE0QDDpoWWSPQgAhogmjAQdME0YCDpkXWCDQgApogGnDQNEE04KBpkTUCDYiAJogGHDRNEA04aFpkjUADIqAJogEHTYusEdAIaARqgYAmiFqgrNvQCGgENAINiIAmiAYcNC2yRkAjoBGoBQKaIGqBsm5DI6AR0Ag0IAKaIBpw0LTIGgGNgEagFghogqgFyroNjYBGQCPQgAhogmjAQdMiawQ0AhqBWiCgCaIWKOs2NAIaAY1AAyKgCaIBB02LrBHQCGgEaoGAJohaoKzb0AhoBDQCDYiAJogGHDQtskZAI6ARqAUCmiBqgbJuQyOgEdAINCACmiAacNC0yBoBjYBGoBYIaIKoBcq6DY2ARkAj0IAIaIJowEHTImsENAIagVogoAmiFijv4W10hHpvBePsasDAhMsTwwP/WY26dZ0agT0dAU0Qe/oMqEH/NUG4gxwOhwMvbqJFIByWiA58tQbD4auJepfPV2d0Yd8IaILwDZl+wS8CmiCkiFF79+I5gPkDAtpBWBUfHjjHL7ZVLF/v8lWx67rqLAKaIPRcqDoCmiAKIW4P9f0rMX8fQMD6tc4Iot7lq/qk1Q1kpqUGQiNQZQQKCILxcEsTnzo4GPl7lZuu2+rbQ71fIsZ3cgLWHUHUt3x1O7BTTDB9gphiA1qP3dEEITtB1PcCXO8EVo/zfCrKpAliKo5qnfVJE4QmiDqbklocRQQ0QSgCpYuVjoAmCE0Qpc8e/ebuREATxO5Efw9pWxOEJog9ZKpPuW5qgqjDIZ09+7ymlpZtR7PBwuxxLoADc9YuwGYCngBh9XgL/2LjQ5FtKl3o6Qm/bXyS7gHhk5nyfwxSMjQ8fNfLbaHwoYZ1YUrzAEwD4TUwb2DQysmxGb/auPHGSZU23Mo0MkEIP4CXNuNQmMZygI8DcIiFUfrZDvALgPEQg9bMOij1aCQSSSnj4AWqwkW+mCetrdtmMyHM4KNAOASM/WzVjgH8ErExAsaa8fHpv/EaS1/WZgryCTmseZc05gPmuQB9AsABGfmSAP5CTMOmwT+ZdSAnvLArZ/7pd0tHQBNE6dhV/M2OjvA0GFgOon8D8E6FBsYY+DFPNn11dPT2N7zKywgCKT4KAToNwHdti15+NUwXxEf6b1CQxbVIoxJERyh8FJiuA/BRtf7z02TgothQ5DcA2PlOpRbgEuZJVpRXAVwy8yAekC3GlZJPNGbJGMQKMAnnv7cXx88bu+Lv6xLVQEATRDVQLaHOI3vCBzYlaTUDx5bw+pNsUG9iqP/3bu/KCIKAaxn4tis5AH9KGTxvw1DkTyXIlHulAQmC2rvCvUR0iwc2bpCkCLhqfGzG1c7deiUW4LaehTONZOBOgNpKHJMUgW4cH5t+STXkEzK19yw+hJKptSXImALh+xNvzbii3FNridjo1xwIaIKogynR2bnwPWwE7wVwaIE4lroHQwC9yuB9COgGMFMi9iaDjVNHRtY+KuuShCAmAIzbdndbGHiYQG8CZjtA/wSilfHh/otlu2E/sDUaQXSEwnPA9AsA+zv6uRlATIyF+DuB38vCC7pwhzzBzMsSI5F++/sdXeHlIGNO+m/8cQCZf1v//yxgiJNH5md+tqVpr+sGB2/dkf3T7GPC01t2UESyiRBqrVcAbMjKBrA4gXbaVDp2USaYaUlipP+uSson6vKYyykwXmRCgkBveM9lunFibPoKTRJ+vrLqlNUEUR1clWtN62jpTgDHO156kgkXJIYHYs4FWtwZENNNVoiG/OdJM5icPzp410tOASQEkS0idpTXcMq8Mh6PjGX/eOTcxbNgpCYfGYyIhaesp5EIoqfnnNbx5Ju3A7Qwt1YDz5BhLI4PrX3cORbiHqC5desyEAmvaJsqhWMTrTjR7Y6oFD+DgnfSAt6dMvhSt1NeV1f4QymilQQcnT+IfB9SWGQfc/vvpcjnQmApZtxtBvgyiYzUFlpymMHJmwA6wtZ+isFfSkQj3ytr4umXy0ZAE0TZEJZXQXtX7wVEEHrudMiF9DMw0crneV1AWwvTXq9/E4zP571L+EF8eOBS50LmRhAM3DI5NuP8au7WGokg2uf2fZhM/jWAgzJjsYVMmheL9T/pNdLtXeE+IloNoDlTboKBkxLRgYdk7/ldgNvalhxgNKVEXbn7ECLqH39r+tJiY2fdBwRoFYCwjfReDCLVE42ue74S8ok6JASWAvOVMw/Gd70uoDMX2T8EeKlNlheQ4nnxeOS58r4w/XY5CGiCKAe9Mt8VO67mHbgXIKEKsB4GEubE5MkbNvzstWLVW9ZOe227jZn7bGU3GZw6bmRk3f/a33chiDfI5BNisUi8WFvl/O5L967WUM4CS624eqn2rr75RCzUS2nCVrTWSS/CWAfQ/GxrxPhmbGTgK5VYgNu7e48h4Jc2AlIirmzbbV3hboPoVzsNEvbO/O11Mum4WKz/kUrIJyMwQF1VNGfO6fsZzU3r7adiAr4eiw58TX30dMlKI6AJotKI+qhP8tFPAHxqPBoRH7LS09nZ91E2rB1vTl8uy5EgJwgeDaBpfjR6x1alxkos1FAE0d27gICf7+qqOkbtod4riCHubF4C6HEG35OIDgiyKXj8niA6O8MfNw06l8BHAPQeIoo2BzafNTg4KMxFiz6h0MKDkhwcBvCP2cIMnFIx+UJ9i5n5p7bTrO8TQGdBHfzERDA4b+Pgmr8V7aAuUBUENEFUBVa1Sju7eq9mwhWlLEbZd3p6eoLjyf3vsKsPAF7fEtw7bL/glBEEM36aGBlYVu4ldLHeNhJBdHb2HckGPwBgRqZfrlZJxfrt9btfgiinLfFulQmC2rt7xZ3YuTbyuSURHVjuZ251dy96XxKBQQJmZep502Q+YXQkEi23//r90hDQBFEabmW/dfhxS/d+21vjP7NbpDBwbSI6cInfyju6+s4H8Y9s7xWoYKQEUaNsbI1EEDK1XxpXfhqEmzkQiCQG1/7Fz8InG8+pRBDd3Wfum8LkfXazViZcmhgeEBf3yk9X1ylvN6lVnLiOyr1UAT8cZQF0wQIENEHspkkxu2fJO5qTyV8DdHi5H4NEv7zVBB87Go1s3HXSKPCkBjOdlRjpv73aEDTSJbXAojPUexYzbnUYDuyCKW16/AADayZbeUjVm92Ocy0IIu1p/doHTQROAfGnLNNlmzFEpVRMkp2/6Or9AAkiVX4Y3ERpa76Dsy953eMoV6wLloyAJoiSoSvvRb9Hfq/W2rrDsw3QgwD2zZRTIwgPHXR5vct/u1YEIcNUoR8Fpy3r8n/atmsYfJ4rSeyqOJU5XaxKUmDtI0NrX1Ros9Dip/R8EDS7Z8l+zank+9jEew2ywln8MwNi45ENayEVqVIEIZl/KhColSkdF7X6dSlPBDRB7KYJUmWCENZQeReQUhWTJggx+lKLKCsG08vUu5N0r1EMe5KdSU8S0ZXvOtBc72XaWc4JQhBY07TXTyDGF0E4sgRvb0tWTRC76eNvoGY1QeymwaoyQRRc7mmCcB1oT5PZ3GIMXA5AhLcIKkyZFAOrW4N8sVvWvBIJgjrnho9mE9dn1EUKolhFLC9mkHWiyAYa1AShit4eXE4TxG4a/CoThFYxqY+rsk+F8LLekXyrmwiLwDjZJeRJrmUCrWwObr5YZopaAkFQR3fvhZ6BFdMtC7PXTQA2glj4t/xPS2DvJ1KpN/atlpmriopTfTh0yXpCQBPEbhqNSrsncxgAAAbTSURBVF5SO/0pCPgbTD42FouI0BDWsyecIGo9lOkxNI/eGfL70xnLm9zuPCOLqzObX4Jo717cRjDvs90zpU8G4N8SjFtgYqi52fyz24nF74bEj3zCRwMGPcjAOzL9TjHTgsRIv5BXPw2MgCaI3TR4mZg/EYDETtR6iPGT2MjAv/gVqT3U+3li5OLWMPAMTwbmjo6uEcHlNEH4BbSE8m1tn9qHgpPXE+Es++tu5p5+FuC0r8sBqwA+01b3doCWx6P9Io5XQWhxZxeqSRDCi5qaUkMEfDDbrsxZswRY9Su7GQFNELtxAHa7o9wUu6Qudygz4TJOyCROamdgf2Y+U9VRyzpRpFL3gq2L4wzrY1V8eEAkfsp7/BCEzIyUgasS0QGRN6QoOYiGJQ6AFbuDkG12AO9ggLKxyhDN/QTsS8AfTOD3hsm32E/C5Y6xft8fApog/OFV0dKyUBuyMMxejcpMDFVDbXhZsVSyo7Uycy1X5ko4Exb01cVM0w9BSPxcPAMBynDo6O69CLCCQuaeSlkxiQol9b9hsHHyyMhaEd5D6ZH4n/jup1JDupAyApoglKGqfMEqBeuT6r31HYTa+DlPdX6CJ7oQzFcSwwPfLOcEIdlI+NLxd3SE348AiXhd764WQXR1LfqISQERomSXkxvw4Hgrh1UcCdOJkILizsKeve+x1MTkcSqBK9VGV5fyi4AmCL+IVbi8LNw3E+6dbOEzSwn37WY5owlCbeA6O8MdbFhRT/fZ9YZaVFJJyG/XWEKS0NiRluCWM2UWT5JLYKEeUgrTLsiBA3QnAR9zIsBMi5xJg7Jl/MiXeYc6Qr3fA+Nz+e3QbS1B80K3y3Pr9NERnkYGXcuEz9jeFXkkViRGBuwhZNQGUZeqGAKaICoGZWkVuScMcs/R654EBk+RmTwxFrurIMSBJgi18XEJoe6V9Ca9wAXoYgb+Pc9pjfkemFgiS8ojiZ+1BYZxenxorUgQlfe4xIcSvhY38GTTl2X5yEX47EBL8CIwfdEtJ7TXRbIf+bLCupwCxDXJo4zAikR07QbV5Ffk4/ShNrK6VCkIaIIoBbUKv1OhlKNbQLwgPhwRH2HBowlCfdBk6pLM23lpM60wHGx+AmTFOCowcfUaD4naSDSRSR1K4yDzudR48sysesUjPtQYWAQSNB4T71upPBntICsiqj0J1XYQNoPx/iwSTJCqv8TvfuXL1umRrlXkaM2lzwVxC0wcBcIhhSNDz8MwT4sPRX6nPmq6ZDUQ0ARRDVRLqDOTjP4OgEL+X+enYQTOjA+t/a3bu5og/KGaWSBFIENnXmqVijaRwUtjQ5GH3Qp3dp6+v2k0PSBT/Yh3GMjL+OYzPpSjWX6aTGOZGeDuPHNoj3DvfuWzN9gxd/E/w+Q7AX6fClj5ZQQ50Blec9l/nfqNUhHQBFEqclV4zzKzNOgiEEQWsmw+Aq+WthPwn81B/oGXjldUoAnC/4C19yw+hJKpWzKkbd+Nu1WWJKJ1k0SXqQTtK0JCBfcX6fzXr18CgjBvteW/du3bq2D+D5i4Sai5Ck4FhOeQ5J54PPJXWQ1+5bPXYfmFNE1+gwDh1+M8XcmaSxJjZSrZdKVMZeZ/9PQblUBAE0QlUKxwHZkcvfMBFjmERTrSAzPqgowKAjGAIi1B875ixJAVTRNE6YN05NzFswJmKkzAIoBERjZ7lNTNO3Mp/5FA/anJQL/dOVGlRVF30DQvB+Mkp1rILRy7uF8INjd9isF9IPoQGPtl2hJhNv5CTMNgrBkfn/4be75qSVrQFBHOiQ0PiExw0qcU+ewVifuTlnFaAMYyBg61zWVRzMIOjJtTk8m7tbWSyoypbRlNELXFW7emEdAIaAQaBgFNEA0zVFpQjYBGQCNQWwQ0QdQWb92aRkAjoBFoGAQ0QTTMUGlBNQIaAY1AbRHQBFFbvHVrGgGNgEagYRDQBNEwQ6UF1QhoBDQCtUVAE0Rt8dataQQ0AhqBhkFAE0TDDJUWVCOgEdAI1BYBTRC1xVu3phHQCGgEGgYBTRANM1RaUI2ARkAjUFsENEHUFm/dmkZAI6ARaBgENEE0zFBpQTUCGgGNQG0R0ARRW7x1axoBjYBGoGEQ0ATRMEOlBdUIaAQ0ArVFQBNEbfHWrWkENAIagYZBQBNEwwyVFlQjoBHQCNQWAU0QtcVbt6YR0AhoBBoGAU0QDTNUWlCNgEZAI1BbBDRB1BZv3ZpGQCOgEWgYBDRBNMxQaUE1AhoBjUBtEdAEUVu8dWsaAY2ARqBhENAE0TBDpQXVCGgENAK1RUATRG3x1q1pBDQCGoGGQUATRMMMlRZUI6AR0AjUFoH/Bzc2K9R2TznNAAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-29"><g><path d="M 211 451 L 261 501 L 211 551 L 161 501 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 501px; margin-left: 162px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Failures?</div></div></div></foreignObject><image x="162" y="494.5" width="98" height="17" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAABECAYAAACbHqJdAAAAAXNSR0IArs4c6QAAEYRJREFUeF7tnX90HNV1x793dmSJkGJoSAyEH/lVTpJSmoONtSvt6ojfhNgxAXYlEwxOSUKaUtOkpTmltE0bk4SQk5xwCBRSBwwES7sYDHVLiF2ieH9o5dQpJYSmSSAtuBhMXWMIyJJ255a32hWj3ZndmZFmdq298+fO+/l5b+c789699xHkEgJCQAgIASFgQYCEihAQAkJACAgBKwIiEDIvhIAQEAJCwJKACIRMDCEgBISAEBCBkDkgBISAEBACzgnIF4RzVpJSCAgBIdBWBEQg2mq4pbNCQAgIAecERCCcs5KUQkAICIG2IiAC0VbDLZ0VAkJACDgnIALhnFVgKSOxxF1gXOFHhUz4Qj6d/JofZTspMxxL/DkxbpxJS9g4mk6urc4bi110bIH1NID3Vu4x8NF8JvmPTuqRNE0hQMujA7+jM1/BhPMAnAzgt8otKQJ4AUAOoFSnbjwyMpL6TVNaKZU6JiAC4RhVcAlFIAARiODm23zU1B2Lf5CYNhAQdljeOAPf4amOvxob+94rDvNIsoAJiEAEDNxJdSIQIhBO5kmLpKFINPFZADcBOMxDm55kjRL5HcP/4SGvZPGZgAiEz4C9FC8CIQLhZd40IQ9FYvE/A9NXAISq6i+C8GsAWTBNAPx2EPrAeFttO+kZaHTJ6I6hf2tCH6TKOgREIFpwetQIBOOxzg5etRDWbGUPogUnnMcmhaOD3QTjEQBHmYooArRBp6kvptMP7DEXHY/HQ88+jzM1ws0AvX92tTwy2YULd21PHfDYHMnmAwERCB+gzrXIhSwQTtnIHoRTUs1JF4nED4OGTSBaNUsciP9iNJ36OgC2a9np/fFj9AI2AdRvzsuMq/PZ5N83p0dSqxUBEYgWnBciELLE1ILTclaTenriEdbo+wCOqNxg4M6p8SOv2rXrjqlG7Q/3D74LBeNRmrZ0Kl+cm+zCBfIV0YhecPdFIIJj7bgmEQgRCMeTpUkJa5YKgb1k0Fm53PCTTpsUiSb+CMAtpvR7WKOzZMPaKUH/04lA+M/YdQ0iECIQridNgBn6+/v1icI77gMQN739P4IiLh4dTY07bUpPz8DprPEPABxZzjPJwEfymeR2p2VIOn8JiED4y9dT6a0gEN3dq5doemEFiD4CYCmA4wDopg69CPDTDGwuaqHUj3cMPeeks35sUteU6XJT303+6rQV573u7o8fQR1T1xHwCQDvADAO5p8z4V5jsrBx584H99nxUZu3z+0JLSMy1oJxDoCTTKxfJOAJEO5eFOItXg0Vlp4dX9w5QSvBuJyBUwEsKben5MBGwFPMPFycKmyp11aVp79/bdfE1OtXQ8MpYF4G0NHE2JDLJv/SyRyopJF9Jje0mpNWBKI53OvW2kyBUA5PGtM3AJxtYbpo1+4iM7YUQ9rnGgnFQhQI0rTdMPh+gN9jDYi3duqHx0dG7jpYdZ96+uJnsIFv11r1WJb0Koi/hAJucfqm3t8ff+tEkb4ExlUO/RQKxLitWOi43m8Htp6e+Ieg0TYGji73dr8BPmcsk9rVgn/LtmySCEQLDnuTBGKuDk+K5PMaa6uy2aF/tcO60ASCgGsYpYfvB236XCSiy3Lp4SHzfWUFRCFtPYOvcSHE5SJ4zNCLl4yNPLC73vSNROK/jRANl8Xe1Uxn4BfQ6EI/9wNq9yD4iUldP2vXyKb/ddVYSewbAREI39B6L7gZAtETS1zMjHss3jJfhXpYgB4HoJYjQmDjNFDJjr3Wc7bB8s5CEwgQ9pmcv9T6exagZ8pfE70AnjamQmePjW16sTIjli79dMeiww7cAvCna2YJYR8xfsIg5WQWYvAyAn63anlPZXuKjMIFudwD/2010+rUUVr6Amk/KY0ncSeAXjDeXStU/vkm9PRcdBJr+j/PElaiW0bTw+vqmch6/1dJTi8ERCC8UPM5T9ACcXrf4Am6YTwK4AOmru0nwrqJ148ctjJbLL8Bf4LBXzUFZFPZJwFeNZpJKRPImmvBCcRMD3mM9dBgfmTovyo/qeWd8SJOHEunnjKBsPE+5p8bjHUnHofHUqmUEuKZa/nyj71NW9TxdzT9pWL2WH60U+dLrPYlwtHBfoKhHsAVES8y8JUunW+0Sr+8L/5u3aDbGaU9kMpl+fUz1+lv82XzvMbFc7PZzT+ba/mSf/4IiEDMH8t5KylogbAwN3xFY21FNjukoqnWvXr64meyQQ+a7eGJ8WW7DcuFKBCl5RhdO88sDnbQuqPxpRpoW5X38XYUeWB0NPV/dWBTOBa/gphuNT/0ibA2l07eW50vHE18iwD1Nj59OXg7VxvZiw5iy2wHNtv9k0ZTw/J+d/9Fx2uF0P0AdZsSjBNhTS6d3OypUMnkGwERCN/Qei/Yh1hMT+tUiFWHPlAtLFmkFF5LAbTCzcOkktbK5JEZ9+azycutlgoWokAQ8Le5TPKLDkacIrGBm8F8tSlt3aWiqjIpHE2oL4nr3/y91rns1HPXHP7W1yceNH8NOA2VHonGzwfoIQCLVB0MPKej2J/JbH7GQf/qJgn3DXwABm+Z7RxXWuZq6H0917olvzcCIhDeuPmaK0iBKIVMCNEfMBAFcBoBiw3mS8ayqYzTTs7FTBTzcB6Em/qt+uQmv4WD2GsG8/lOeKllnJBB/wKU1vvVVbT7ArBjb1FGje9AyXJpih4C4cxKOcx0WT47/L1GY1p+w98GkNqbeJxBT3WQ8a10OvVSo7z17pc9r+8vm0tXkhbBfP3xx+Gm6mW1udQleeePgAjE/LGct5KCFIj5aPScHrCHvkD82tALfY0sihTncG/8o0T0wMw+AuFXKHD/6Gjqf5yOg9UXm8WSHoV7E3cT4bIZgQjAKsmuD5FYfDmY1EFPyj+kcqkN/WtHM0m1ZGYbt8kpF0nnDwERCH+4zqlUEQh3ntRuBGrevyBcOOX19CZuYMJ1lTYQsO03b+n82BM/uOc1NxMmHEtcR4wb3sxTu0/QExsYZGa1N2He1FaH9DxE4I2d+uEjFn4ZbprhKK2ltRLwKkBXjmaG1ReFiIMjks1JJALRHO51aw16k9oLgqX9q4/uKBQjBKwGoPYvKkdLqr+8bXjyBbgHkerU9146MjJSqMfRJjzFLwHth+7584cALDcJxFgIHR/OZO7bX/mtbPm0tc4JbwUGfkaMYQ7RlhOWGL+Y72UeZWrb+ZYD9zDzgKmP+4l4TS6d+if3/ZYcQRMQgQiauIP6WkUg1Ab25OQrSwxNP1UDncDEy8GlB9O76nrltpNA2CyRVQ+z1b6Ag6ngNImlEUJv7+Aygwy14azCpDS6lL/LVjLoromJxT90EpG1UYEWEV8nmfnyfDalnPfkOgQIiEC04CA1UyCUT0TIMK4hQL31He8JjwhEDbZmCIRqRGk8i8Y3iXChC49ttT/wXZ0KN1hZvjmdE9VLagC7DujntC5J5w8BEQh/uM6p1GYIhAo2F9Kn1jPhDy28duv1R715qqWNE2cSiUC0jEBUGmIS/jVVm8X1xvZ50nhNbkfqMbcT2tJ8mukzo9nh292WJembR0AEonnsbWsOWiBsnJdq2zcdVkJ5CucB+pHGlM1mh/aEY4lriXGjCIT9ZLI0PSV8IZ9Ofi3gKUjh/sGTaIrPg8ZXgKH2M2pDprzZqL3QtPPdnhcdjV56VBFTj5gc4orMtDKfHVZHlMp1iBAQgWjBgQpSINRGYsdhL99eDlNtpvEyCENs0MMd2tTjxxwT2mu3ienGimjBbVI73IOwcl4jxj/ksslPNXMKqvHv6tp3cpFCa4gxACrtL82+HHhhV2exCOUtkVqbOdAe6xaB8AjOz2xBCoTV0ZFvmOx/H0X+eIPQDzMImi0Qkd6Bq0D85lnGLkxPVSd6ehPfYcIn5/MLyGp+uKnHz/lVp2yKxBLngnG3eRlKhRLhqVCfOeBgo/aJQDQidGjcF4FowXEKVCCqbPMBPIsinzU6mvqVQzQ1TlmBm7lGEysJeNjU3h9pfHBlNvuw2h+pe1m92c9H+60qrREyD8d0qqhK5XAd6jS33SrKLrOxravjpc0VU1sV0oLYWAGmiDrsiYFcl753TSNT3Eqbw7H4WmK609QHeftvNJEW6H0RiBYc2KAEwsY23+5wG0tSpZPnOorqiMhT5vMN3M1pY+FagXDu3awepgar8BfHzmf7Lb8gegZOYa1U14xHMQPr85nkXzt1GItE4u9DqBSuY8YogIGb85mkOleidM3VY9sioKAIRAs+J4JokghEEJRd1hGcQNQG6nPp3WsRPK70qAvUUa67Nx7ViFR48cPLqOuGHDcNh2/tt/yCUHGvNGwC0SrT/b0gXjmaTu1sNE2UoE8WltzMYGVpVrnGGdoF+czQSOWHaPTi9xQQGiHghPJvrmI+1QgM4FhwG/VB7h9aBEQgWnC8ghII1fWadXFgP0P7cD4zNFYPjTpHefcL+DyYvmxhFmu7xOPHJnUkEn8ndBoB432VNiuhm+ji+K7tqQM2/aBwbzxBVFpKmW3FMw8CZ8euuzd+jkalaKkzdTo8vc26vcwPwcBq8xGk01+GSzYCfKlbIbIO+Q1H3uIt+FeSJs2RgAjEHAH6kT1QgbCM2UPPkGZ8KrcjpcJAzIqVo4ThuRcoDMbX64RxsA0v7odAqHX5cDSxwcISa0tB09ZVn5OtwlDoHR1/Y+vz4aNA2HwFqGm0H8zXwsB91edN1/FRsf366O0djBlkbDWf0wHgJWb63NTBxUkrT+np88ixEaBl5i8Ug3nVWDalzrBwfFmee+HQ4stxJZLQdwIiEL4jdl9BkALRIGaPOiYzB1A51LNxCkC/V3WCHKCiknJpXf2Icm9tlyR8EgjYHMSjmlMAeBeg/bvNEZ5FYtzKVIonNR2G20eBUMWrt/TOg5SqOr2tMlHGQXgcTD+d/sH4fYCWWnyljTPxn+bTqdvsvpAiscQ3wPgTi/uvAvxTQHty+h6/XX1MAlhSm5bumBxffLXb0BsiEO7/962YQwSiBUclSIFQ3XcZs8dMrACmb3IH3YqC8ajpIJiXyaBzc7nhH1fj9UsgStY90cRn39iHuKmB45e5SUUC1sMo3MmarjZ+3xuEQFREYtFBuuONs6UTHqago1DZJee8gnYrwMp72u2ljii9u0vndVZHlDYqTASiEaFD474IRAuOU9ACoRAsjw6crIE31lk2mvVgBbDdIP68Om/ZKqwC23gJ+ygQqn3U0xc/gw18G6D3Nxjal5j5j/PZVDIWu+iYAuvqeNXABEK1rbSPs4eUQChRe6eTqchAnomvrDrn2jZruY7PvPEFsh7AkU7qAKDOp7j2+GM56TXCqwiEQ9ItnkwEogUHqBkCUXlgqf0FzaBPMnEMwEkzSxulMBv8nwxsLmqhVPW6fvW51upBZkxOrdi588F9ZsQ+C0SpqrJ3+PlUsvah02aWTsp9IKLbFoV4S+XNuMak1uclpuopp9qrd+3vDkG7ksnoBUgFSaxsYqvloGcZtNUAfXdnZviXTk1izfWUQm93HjgDhNUWdYwDvJtYyxZhbCgcPGrM7ZJSdZ9EIFrwweKhSSIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCAgAuEBmmQRAkJACLQDARGIdhhl6aMQEAJCwAMBEQgP0CSLEBACQqAdCIhAtMMoSx+FgBAQAh4IiEB4gCZZhIAQEALtQEAEoh1GWfooBISAEPBAQATCAzTJIgSEgBBoBwIiEO0wytJHISAEhIAHAiIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCDw/9PUXuoYdJv9AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-31"><g><path d="M 211 551 L 211 576 L 51.5 576 L 51.13 594.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51.02 599.88 L 47.66 592.81 L 51.13 594.63 L 54.66 592.95 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-64"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 592px; margin-left: 139px;"><div data-drawio-colors="color: #393C56; background-color: rgb(255, 255, 255); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; background-color: rgb(255, 255, 255); white-space: nowrap;">no</div></div></div></foreignObject><image x="132.5" y="586" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABKNJREFUaEPtWH1MU1cU/wFmWAoraJawyFacgIIoLszMBHCZm07M5A+D4seyaMQvVDY+WoFCakVWSoFaUReNcTP6h44lOpdpNsVghpqp6BgwjNvYMqe2dmUw5pCvdrtNSlree7nvMdYH5N2/mt5zzzm/8zvn3POun9PpdGICLT8J0BhnU2JojBMEiSGJIR9HQEo5HwdcsDmJIcEh8/EBiSEfB1ywOYkhwSHz8QHBDFkf2/FJ7XnUX/kGVqsdDocDQUEyzIyZjjWr38aCV+dh0qSAEcEYGBjE7dutuFh3Fd82tcFi+R2Dg4MuXVOmKBA1Q4nUpQuRlJSIYHkQq40hQHb7H9i6XYsHD6xegstSX0NxURZ6e/tw9FgtTp3+YsgIm0alchrU+Zl4eV4cb1AkKHWXr8Nk/hidnX9SzwUGPoO05W9gc2YG5HKZlzwvQO+/tx67dftx7fodqjEiEBIiR0W5GglzZ1Hl7R2dKN17EDdufkeVHS5AgqfTZiMmOnJoiwpo8ZtJrpT67NwlQQbjZ0fDaNgFhSKE89xjmx2a4mq0fv+jIN2ewmFhChgNasTFRrn+pgIi9eBwOF21ImT5+/tDX5aHlORXWI+Retmz9wAu1V0TopZVdnpkBKqMBQgPf44OyK2BOJiclIhNmatAFJDV3HwPxuqjaG+/z2poZXoqcv5NV7ZVf+UGtDoz+vsHGNuhoc9i25Y1SEmZj1BFCPr6+tHW9hMOfngSLa0/sOpLW74IqrxMfoAImC2bMrBubRrIb8/1yGJDTm4Zfr3/iGFo0esLXDkeEODd9f568jfy8vVobrnHOEOCZdCrEBERztgjjclk/gjnPr/M2CPNwVRZxA/QnPgYVFUWcrbKw0dO4fiJMwwjiYnxqNCrIJNN9tq7easZ+epyBjvEqUpDARISuJtJV1c3VLsMrEyRjKDWEPEka9s6vLM2jTPXv/yqAbrSGt6AuAKwZHEySjRZDEaHKyZ1t3tPDaOuZ8dF8QNEWjCpH67VcLUR6oIKXoB6nvaisKiStU1rS3birSXJ1Cbx8KEV23fqQC55zzV1ahgdUHCwHOZqDWJjZ4wKoI6OLmTt0DJqjo8dtwPd3U+Qm/8Bo93LJgfSAZFL0mwqxqyZL40KIK6JhI8dtwM9PU+hLjSisbGF4RO1hvgYEpJyEw4QV7qM25QTvSmMdsqRpCdTde2nFxj575O2/X8A+rrhFgo1VYx75L9erBs3pPu+yxFaSOvOzillnQFHOvqQqbtmX4k4gAioM2cvosp0jHWKH8lwmrFqGbJ3vCseIDKgFpeYRvRhN7z4oqOU2FetAWHJ5/eQpzMWiw15qnL8/Mtv1HGHS+DFF55HuV6FSOU0l4iogIgD5KtVq9uPpqa7gkERZspKc70+NUQHRFC4H0kOHDoJm62DCow8CWxYvwLpK5aCPJh4rjEByO0QAdZ2tx3nL9S7aovrGWthynzGN5Zbh+B3OWr4RBaQAIlMANW8xBA1RCILSAyJTADVvMQQNUQiC0gMiUwA1fzEY4gKeZwJ+I0zf6nuSoCoIRJZQGJIZAKo5iWGqCESWUBiSGQCqOYnHEP/ADZNm1jj/+tzAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-34"><g><path d="M 261 501 L 356 501 L 356 87.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 356 82.12 L 359.5 89.12 L 356 87.37 L 352.5 89.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-36"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 512px; margin-left: 307px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="298" y="506" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-46"><g><rect x="1" y="601" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 651px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">GPIO driver suspends non-wake GPIOs</div></div></div></foreignObject><image x="2" y="630" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfQuUXFWV9rdvVT8CIwk/ComAgKM44uigkfS7bQ2vICGQUN0dIAFlBIRMGFBEAX9foIOOIgyIoEgCQtJdvEGRh9j0o7o6EEVEjP4KCAgkyIQQoV917/5zblV137517r3n1qO7uvvctViLdJ3ndx7f2fvsvQ9BfxoBjYBGQCOgEZAgQBoVjYBGQCOgEdAIyBDQBKHnhUZAI6AR0AhIEdAEoSeGRkAjoBHQCGiC0HNAI6AR0AhoBNQR0BKEOlY6pUZAI6ARmFUIaIKYVcOtO6sR0AhoBNQR0AShjpVOqRHQCGgEZhUCmiBm1XDrzmoENAIaAXUENEGoY+WbcuHCMyqqq9/4NwvmUhAOB+gAAPMBRDIZTQCvAPxXMB62CPe8awGeiMfj4u+hvpaW2D8Nj9LdIHwiVMaJibcysAOMTYaBB1LDo/dv2nTna6rlNTUtX5DiaA+Af87mYcKFyZ7Ob6uWIUsXi8UiL2w1DibTas/gKMrfx5F2JwMvG0wJi/iO0Wru3vxwfEchdU523tqm1i8Q4/Kxegnr+3s6TytFOyazrlK0X5c5tQhogigQ/0XNsYMMi75EQDuAt4Us7nUGrrNGRr8TZnMuEkG4m5oiottHiS54rHvjC0H9KDZB1NScvIdROXImmM4FsG9Q/Y7fU0x4kBH50kDPht8B4BB5pyTpZG7ak1nXlICpKy0pApog8oRXbGiR6OilTPgsgGiexWSz7WSii/efb/1ARaIoEUFk27KdiFcleuI/8+tTsQhCSAwvvkytAK4E8I4CcDSZcZdZwWse64q/UkA5Jc86mZv2ZNZVcuB0BZOOgCaIPCCvr287jA1sBPjdPtkzKiUaTqfhKpfKyZ3VBOFHSPH5/f3xQb9mlZggRNXbQLy0vye+yasdxSAI0Y+hFF1FwGqHKi4XF1s1N4ajIBE/Se0lMnhVojv+SB5DOylZJnPTnsy6JgU8XcmkIqAJIiTc9U2xTzLTzbtOvHvmZuUtYOP7Bujevr6NL7vVHeK0/Le/GQdaBj5F4DPkJ2a6fmRw7prNm68f9WqalCAYj1RV8LKurvg/VLrU0nL8vJGRqv0sg9cS8Cm3FMRA0hoZPdZL9VUoQSw8PDa3YphuJcYxkvYK1dsNhkXX7ruv9ZxbqhL9HzGNxRbzFwk4TEIuO5nptGRfxx0qWEx2msnctCezrsnGUddXegQ0QYTAuK4ptghM9wLYe2I23mIx1r7rnXhERUUk8tbVxeZQhNYy8BUAcxzlDTJze7Ivfk8pCcJZdl1zez0s605Xv4TKZk2yr/OHsnYUQhDiQr9yzo6rkSZJ5zcI5q9XVeBqRaKjuub2Q2FZNwH4V1dZgVJQiKEvalK9aRcVTl1YCRHQBKEI7qJFJ+xlVFbcR0CtK8ttMPnM/v74/yoWNSFZfVPrCmYIiWSMJIJO78WQINxtlbUDPlJJAQRBdU2xz4PpWxNP/vQMWWhPJDoeC4ujjUfK+AHAq1x5nyYrdUwiccdfw5ZZyvSaIEqJri67mAhoglBEM2dRAyDgoeFqjhVoZinbME0iOiXR07FR1rxSEISQaBDB7QAtcdT5Mhu0ONnd8Qd3O/IliLrm9g/Dsn7hlFYY+BMMOl5Wj+LwwEsqIdC1ldGta7u6ulKqZZU6nSaIUiOsyy8WApogFJAUpqwRi34J4KBscntTixpHJbs2PqdQhG+S+voT9raMigcJ+DdHwnhVdNtJso2tFAQh6q1raDsTxBNUSgwcl+ztFGq1CV8+BNHS0hIdTu2zHuCTHIUFqtRU8fXA8Q2y+OhEIt6vWk6p02mCKDXCuvxiIaAJQgHJusbWcwBc7Ujqq59XKDIniaSO58lKNcvUI6UiiNrG1qUETLj7YKZTkn0dtxSDIOrr2/6VDRZEO3aHQ4wfV1Zs+2yxTvi1DW3LiXgDgMqxNhNd3d/TsbaUPhKHNbfvH2WzHRZWguhfMirDFAO/32XtdhOPVv54YOCWN0SbwhCEO22WsIWZNVWMXpQxMBB4ivubLUz4qTWSWp81Lgiqq74+VscGCYlujwxeb1rMRw/0xXvDzOPGxhXvTiHSRcD+mXwjDHwy2dv5sF85GfXgEsD6FEAfcThFConvr8TUYxn84/3nc1L1fi/n8DKuKn2zvrm1iS18E0BNxjBjK4BHmHBNmDrCYDOd02qCCBg9YW1TOYSfA1TvSPqUNRo5fGBgg5hcRflqm9veTxZ37vIe7mXG7dXR3Xq7utYNyQqfVILw8I7OR4Kob2z9auZSPtutop/uPUyAnzUNXrypO/5sUQbLUUgIf5hXAfp0f2/Hz2qbWi9Q9aSWEQQZxouw+DZvM2u+ryq6e0zMnyCCkM1vYnwz0dd5cRisahvaTibin47n4cRINY7xUr/aKs0o1oDpy2oOpryFDJyT6I7/KojoZQRhjo62RqoqvgjGeR4m1UqEFgaTmZBWE0TAKNY0xBoNsk9Yu2eT5rOAijlZJpUgiqRikhOt/yaSL2YSVZnvnU6+9YyReq4FlVeRQp32KYPoQAb+a1zC8Q614d7gCTh3V6iRMwEc4lHJhL4GEYQoI1d65YEIKpb09t66XQWblpbTqodTb8YBOnZsjQBfS/R2flWWv7al/UBKmRsBEqf4MJ/wFbpi5K15F/mZgeceXriLYfQR+Ive/jalmYthOleOaTVBBIyK5HI6LxG8mINfMoJwxwgCPPsaVoLIbKZCvbQgiwUDVyV7O0VojaJ+k1FXff3yA9iI/lyyUZsAbwGMpOgUgz9KwAccfibbwUiA8Ml8CAKE18DYK5NXOFT2AfRMRppoAPAXp3SrQhAS1V+o07QE7+0W+IiB3vhm98D64sZ4gQlJAr3B4D0IaASwX+7k8PcVkszNnQCEo2pa7ch4DgYetf/fwsdAOBDAmv7ezmuKOhFnQGGaIPwHkWobWm8iwimOxfxnpLilvz/+t6ka/1IQhPSET/Dsa2iCaGhbQsTisjsbvBBe9xuF4trYeNKeJkbvn3BCDelI6NcGYTFVtduOm5m5zZlOWLWlDD7TrcrKmEh/ndIn/7H+50UQY5l4gKORdqeRhJgXgybeNdATfzqbTIUgZBJAGPLOldj4fphY4Y4IIOZY1RDFGTjCgZsdIsWK8AUSFSDVNK38oMGpGwD66IQ84C8ke+Pfk42TbG5mCZWAL+67gK9x3GdQY+OKg0zTeD1fU/VC52s559cE4TM6DQ3Hvc2iarGpfWx8XYbzWC7F4JeCIGobWs8isi/iHRsY3VoV3Xqq7AI5NEE0tZ5HDOeCLqUklkvswF+ilGrq6blDeLgX9NU0xI4wiO52+q6Iy3a2eK1PmBQP/w/bXtozmqvMvDqMBZ0KQQgw6pva2pntO4TM+POTI9Ho4s1dG/7uB5aHebT0NC7piwnmS/Z7J77jdwHt4efyPExe3N8f/7O7fZ4Ewfyl/r64iKJb9gEdC5qgRcysCcIHTOlEK2FoZtVxLSZB2MHyXsJpIPoft0e3xbxsoC/+kOopzS/cd31D62VMuMhRlqcaQhUHv3S1ja1XEiAsl7Kfp09HmPpkprpBjo3Z8oXkUTHn9esylkfj1YYkCPLR77v7okoQElNuJTWTWz3FwAtRmC29vbc/42xLTc3KfYwKU1g0OTzeg8PKZMuQOap64eBBECUzVAgzf6ZbWk0QPiMmMd3zPe1N1uAXShBCpfBWavBdUeBwhvUfgG2WOeFj4MbRwXlnel0GhpUg6ppa14FxqqOSop3oZbhLTqtFISTJnAh1AS4z9Q0pQYSSvFQJQsgxtY2tNzjJS0XNlHvBLZc6cyUUeEoAXutIVcrxIAhPv6LJWrfTsR5NED6jVtMYW2iAxAl6PDBfSAmioMirHnUVVKbaLA0MUTFbCaK2IXYcEYkggLYqxuvE7AVzWgLZ+1YAsbE04SSIZ61oqnmg644XVYYyBEGgrjF2NGCrzrI+JL7m3JJ56EWWMvK5MdnbeXoYdY+EnKVk6TE3L072dAr/B/2FQEAThA9YMmsYv9OerKiCNvMpIAgGfksmnyjT7Tr7N1sJIldVNu5zoLruat33MWEIIuRlexiCWNiy8u2VqdQvAfpQpi8jAC/r740LM++cL+cA5WHUIDMaYML5yZ7OK1QxE+nkd4J0Vn9fx3WBc9PDXDtM/bMxrSYIn1Evxh3ENCKI18G4DBZfE/QehYAsLEHUN7T+iAn/7oA71Ek47OJ0b+QE/B0WH5FIxJ8IW5Yjfc7lt7icTvR1fiZMmbVui64wBAGEUpWEIQjRhxwC9PFCzy1b7rEuVdUCDwAUKogigysIOArAO7N4y3ySJHMzlFouzFjO9LSaIHxGWHKisgP0/WO3qhOefPDmN1UmR5kShAhj8BLAL4r3sQ1E7h0a2uO3fs5H7r6GJYhS3Ql4jEFJrJhkY5nPO9ySk7e6FVNIFWdogsgNvSFVM0nMoj0vtaWqWpXFo5JGgodkbhbl/kmlOTMtjSYInxGV2YcDauZ/YSeKlEjCqJhCqh7Ctq9ggsiN82Qy09JkX8f9hbbFnV+qigAeNXhoaV/fPcJpKq9vNhCEpI9SNVNuDCdv72tNEHlNt7LIpAkiYBgmyzxzxhNEOtbUBE/qUoUskd0d5aMKck+N2UAQos85lkkSNZM7rpaf6a0miLLY6/NqhCaIANhqG1sP3/Ws5c8mRActgVv+TCcIuaqtNPFvcgPHoShe27OFIHJMcV2Xz5JLZ9+gixKCKKnKR6uY8uICaSZNEAFYyh18ir+xzXSCEDDLorkabBzb17exp1hT2sOzt2hOUjn+HCHvBEQ/cwJAhrmkDllf2DsI0T6JKa7JzMuzz+DmBrCUh9bIjml9fexQGPQQA2/P/K1k6kVRviaIYq0m+1E0/QUhINnYRph5dbIv3hGUV/X3WUEQsvcgiDqG35q7KswFuR+mXmEwivXmRG1T60UkrL2yXx53PzkSTpkRhE3mrtAbwnEy67cg8VL3DXQnDllUYXYTcPAYbB5h5FXXi186TRDFQDFdhiYIBSwbGlZ8wKLIg07zOgCBzmQKRY8lmQ0EIeZbXVPbVWBe48CmaGTr8W54Ud+cyDFRBcKG8MhxGgvlST0JEoQYm5zQGxk100hVdNjlKxHYfw9jD2lAP1/yTxPNAwTsScAfLeAPhsU3uk2XNUGE2Xn802qCUMOS6hpiF4LoW87kRXqT2i5ylhAEPMh2G4iX9vfEN6kNR24qzzepi/xiXV1dbF9EqQuM9+RzGpY9X1uOBCEhc9uMlZmHXO+jKPllSF5MfCOserG+qfUUZqxzBJSUmtZqgsh3FeXm0wShiKVHqGLbL2I0yqsf64q/olhUTjLP17VmkJmrs9O1jbHzCfRtV+jrbQycHPREpQxjj2ifImlRpbxM3TIpSDWukJAeRNjvSyb0owxVTKJ97tAbwupM/N0RdFE5DpXsYBDmgFXTsnw/IxUVJtGOYH/4tTkyemT2edUsppog8t2JNEEUhNyixraDDfC9Tl1qpsBXAXwRJm9Q8ULONiItNaANRF8DsG9O42YoQXid9sW7ysJckk2+ShXHmqbYIQZjveu9AAHlIBFWJXo6by9o0CWZ5VIQd6WiWOlzUKDahlgrEd3oipobLtz3JKmYRLfdjqJ2GBZmC0QftmHxeS9EAhvVNbV+D4z/nPgb3VwVtc7u6or/w2ucxAGKDLrK5Ynv+S68JojizXgtQYTEsq65/cM+7wG/vut1qnWGZf54aGivP8kuXltajp83nKqoZdCpBCzL2Swy7bFDSINO3dTb8Sd3EwuN5hqyy9LkYT2p3YWkPXHp+l2n/FZJBa+CcQUxde67r/Wc+62AtMQgXhsjsdkcLnmEx37aM9kX7wwTDC4ELh5vO8jfTRbtHUrR5zKSQ1T1ICDS5WOF5Cy/0PwSA43x4n3CcMiw9JACxBA9zoisSfZuFCrGCW81iAMAMYkos7XOMv2kD00QIWZyQFJNEHlgmXlT9yaAmgKybwUoE5KDxcYgYsjkbhATC9kJ4m8ghau9TtEzgSBEl+2TYcS4lMHi2dHcl9bSuJgAXgFoOH1q5bmOJzdl8L9EBq9KdMcfyWNolbP4SEGijBcZ6BVPZ4L4g2Ac6nUQSPcpxINBkyhBiKblekyPQeQbyM8LyLqm2CIwiUe49pYQpXhOtRugV0Fc5XgO1JWUnoFhHd/fHf+drB5NEMrTODChJohAiOQJ7Id2XiZx+r0SwDvyLMaZbSeYfmilopcODNzyhl95M4UgMn2k+ubYx9nCNbJ3KULgaj9daUaM8x7r3vhCiHx5J/W5+/ArcycB1zIgAvylw8iXMUF4xxLLP+RMgBQeMB6CHOjE/u6Nv/FKqAki7ykt4ezilTUrS7LVByZOJMaF+W1wvIUJl1dHcJufHtYJ7gwjCLtraQc3Wgng69L7GO/ZlWLG3RHwxX198T9O9iQMd1DgLWQZq03Dsia8M1LGBGGPTWPrOYD9HO3YF+ZVO9mY1NScvAdVjH6D0kQ5R2HcUsS41kxVXBJ0gNIEoYCmYhItQSgCpZLM9rqOpo5lIqEX/wgBCwC8zbGqXgPzK4CRJOIucyTy0MDAhq0qZc90gnDuPYsa294bIWsZGMcDdACA+Q4V1E6AnweoF+C7qqK7d3V1rRsKi2Gx0wvSHjHpeGb+LIjeN6YGI4gx38Sga0cH5/1C3EuVczRXGS6S2FZF8y2xrQOHaSkYqxk4xDXWWwH+Cxg/MUdTd7mtlbQEUexZnFueJojSY6xr0AhoBDQC0xIBTRDTcth0ozUCGgGNQOkR0ARReox1DRoBjYBGYFoioAliWg6bbrRGQCOgESg9ApogSo+xrkEjoBHQCExLBDRBTMth043WCGgENAKlR0ATROkx1jVoBDQCGoFpiYAmiGk5bLrRGgGNgEag9Ahogig9xroGjYBGQCMwLRHQBDEth003WiOgEdAIlB4BTRClx1jXoBHQCGgEpiUCmiCm5bDpRmsENAIagdIjoAmi9BjrGjQCGgGNwLREQBPEtBw23WiNgEZAI1B6BDRBlB5jXYNGQCOgEZiWCGiCmJbDphutEdAIaARKj4AmiNJjrGvQCGgENALTEgFNENNy2HSjNQIaAY1A6RHQBFF6jHUNGgGNgEZgWiKgCWJaDptutEZAI6ARKD0CmiBKj7GuQSOgEdAITEsENEFMy2HTjS5XBOqaWteBcWq2fUy4MNnT+e1yba9ul0bADwFNEHp+aASKiIAmiCKCqYuacgQ0QUz5EOgGzCQENEHMpNHUfdEEoeeARqCICGiCKCKYuqgpR0ATxJQPgW7ATEJAE8RMGk3dF00Qeg5oBIqIgCaIIoKpi5pyBDRBTPkQ6AbMJAQ0Qcyk0dR90QSh54BGoIgIaIIoIpi6qClHQBPElA+BbsBMQkATxEwaTd2XaUcQsVgs8uJWHALLOB3gIwEcCGBOZih3Avw8YDzMoA37LzAfj8fjZtAw1za1foEYl4+lYzxSVcHLurri/wjKK37PN//ChWdURKu310RgnM7ETQAOABC16yS8BsZzxHggRbR+U2/H/wPAQe1xt4WB45K9nfeKfDU1J+9BFSP/ToxTQPQvGdxMMF6AgV9Y4P8Z6In/QaUer3a0tMT+aThlLAGsTwH0EQD7ZNKmAPyVmHosg3+8/3xOqoyNjW9j61IC7snW6XQ+E/PhhVeolhjnAGgGMB9ABMAggOcYdIdp0HWPdW98IQg7j99pUWPbew3wpwm8DKD3ZMZoEIQnYPHVsHBnf39c1Id8CWLh4bG5VcO0FIzVDHzIgZuYv68Q8DQzd5ijqbs2bbrztTz7EpjNb/6I+Vox5/WjCfxZ19juBPAnBt9qjaTWF9K+RYtO2CtSET0ehE+D6H1g7OWePyasG1JDew5s3nz9aGCHADQ1LV+Q4mgPgH+207vW92HN7ftHLD6TwMsd+4mNO4BuJlwTZr6qtGm6pJlWBFHXFPsYmK4G8K9qAPMWMnBOojv+K79NL98NPtuGPPJTbUOslYi+C2Bflb4wkGTi0wd64k/7pfdY4PfVNbZ9EuCfAHiHX35RjwU6dVNvx59U2pVNU1cXm4Mo1oDpywDeFpxXbWz8CGJRY9vBBng9AbUB9ZlEdBunrLP7++P/G9y2dAp74zCtK4hwfIZ0PLLyFrKM1YlEx2NhCcImVJO+AcaZjoOOXxNTxLjWTFVcMjBwyxuqfVFN50UQ6bWHHwL2wcK3fWC6Apb1lSxpqtSd3qStrxGwauyQ5J/xbwAu2G8BdwYdNLwIQhQ/lKLLCDg7uM7xMVbpz0xJM10IIruh3qi4iJzjYxJw6fDgvMu8Thx5bPATxj9MflsCegkXgOhS/01HOsUGmfjsZE98vRfh5SxwFqdezCGiMNhtJ+JViZ74z1Qmem1L+4GUMjcCVKOS3pHGBOGKkbfmXeR3GpRJEAb498x0M4A9Vetk4LeGlVqWSNzx16A89c2xT7Bll//OoLSZ37fBME4AW2eohtqoq4v9H0SoA8DhinWMJWPgTzDo+GR3h5D4ivbJ5g8R7Q/gO2HWHhN+PlrFJ21+OL4jqHF5YJ0t0mTgpuoor/WT9mUEAcs8BxFjXcg5u5OZTkv2ddwR1KeZ8vu0IIi6ptgiMAk1yd4u4LcCSAD0qvg7gQ/i9GnSfYIdYebVyb64WIw5X5gNvtD89U2tK5ghNp6sWkwUaat5mJAkUPpUSPxBMA6VLMrtDGNJsnfjgEpbGLicgDMmbKSM52DgUTANA9a/AbRQcoLaBuKl/T3xTX6Tvb5++QFsRH8O4BBXugl9YvAeBDQC2C+3PLp+ZHDuGk8Cd6mYiHAPsz3OzvnwIgO9afz4HSA0O9QTY1US48eVFds+29XVJVRe0s9nvqUA3gwYvwVxFYAGMA7KEr3YtCmtGqzLFuwVi0moayrn7LgaYDE2zm8QzFtAxq/teSGpZzwxd41U43iVTVh1w8pZC8AGwJagsvNVkPqzAPrE/PFZc1CJQ+WxHtJrQr0eXzJyE4Q4KBAwDGCRA5edJKR00LP+mOMPKcM4qgCVpepQlEW6sieIlpbTqodTb94CkNAP2p+9EA2jvb974xPuk7S98Kq3rwbRFROJghMj1ThGtpgmiyBs/WplxYMAhG4+25su08CnN3XHxaKb8An1w1CKPkfAJRM3cLq1Krr1VNkmJ1ngjjLlah27XVUV34W4m0jr77PfU1Y0tWSg644XZbPV1psPUZyBIxy/m8y4y4rwBZI+UU3Tyg8anLoBoI9OyAP+QrI3/j1ZPW4JwpkmrXqLnDnQs+F3zrlgS2ovkwia933XgWEbWbQ4keh4SlaXwMKorLjPpbYSm9VPzeHRz7n164uaYwdFLBLtFptozue1SdY2trcQLEGsYxsvA9+qjvLlstOwqCdq0XVurInolERPx8Zi7SY+88dzXDPqxQsy6sX0HVr6e8oajRw+MLBBHORyvrrm9g/Dsn7hInqTCBsjSF3Q03PHy85MmTFt3XXYudKtKiXQtZXRrWtlayJHgpjYkleZ6bzRobmd7gNKTdPKDxls3iJRaa/p7+28pliYl3M5ZU8Qtc1t7yeLfwlgQQZI3wWeBbu2IdZGRDcBqMz8bYSBTyZ7Ox92D8hkEURtY+vhBAi1TbZNvgso006qa4hdCKJvOdr9Mhu0WKZe8F7g3JWKYuVjXXFx8Zbzeam+CPhaorfzq7I8krpMMF+y3zvxHT+9cOYi+wcAC31z9nseJi/u74//OWd8XBJE9nchDbDFa/103bITqt/Jtrah9SwiiHuuLFEG9slHGvA8Rdc2tl5JwNqxvhJd3d/TIf7taYggCLlyCHcB1DKOEd9XFd091tW1bqgYG43H/AnEQMi8dU2xz4PteTqGHTMvT/bFxwwMsm20ScXABhAJFWj2Exf9F/T3dv7AD4ealuX7GanIbS710KDFvGygL/6QGwcfgngaJi+TzblsGVIJOaQRSzHGZarKKH+CaGhbQsRCvZSedIqDY0/ACG4HaIljQ/lmoq/z4ikjiKbW84gxfkomrO/v6TwtaPBralbuY1SYgtjGLueZ6ZRkX4c43Uz4ZAvc1ldHjaOSXRuf86srY6VyHQGfcqSTkpisTYC/qshZt+yk7kVGMgkifZ8wemQicec2vz7J5gEzfprs61ydI32mN+CfA1Q/NmeIOobfmrsqyGJGvnlDShAfOnLV7v/01vCdTmnAaW3m25/G2NEA3Z09ZDDwQhRmS2/v7c8EzSOV36UEwXw3LKwMunSWzlPCxcmezm+6666vj9WxQUJ62CP7GwOXJns7/6+KFV1dXew9iJA4OL5rrGyPdnoQhCehuNta19gqLOTEoSH7PWtFU81ekrUKztMlTfkTRM7pkQciqFjS23vr9iCQa5taLyK2T2kvAvQEg+/Omnw6806aBOE2pwXiVdFtJ/npwzPtpLrG1nUAFgP8VwY9ARg3ye4hPE6AyiJxTWNsoQESp7Ds5a8pOwXWN7W1M/NPHadFTwnAa5xyy+AnR6LRxZu7Nvx9wvhIJAgV/Xa2jPqG1suYcNH4RiI3Y65piDUaZG9au2fSvkEWH51IxPuD5pr4vc61eYu/ydppS1CjdDcInxjbHD0I311v5vT8EEDiDuQJBj1dQdaVPT1x+x6u0E8mFXpJAe66WlpaosOpvW8FEBv7zeMQlCNBBaijZP2SbNzbLfARA73xzc70UoJQPGiKciTzQlpPodiXY/6yJ4j6+rbD2GCht5+XATDQKiks0JNGEA1ty4n4dkf7Aq2SCu4L8Kxp8GLZHYes7MydTxygY8c2L+CqZG/nuY70VNvYeoNT0mDgxmRv5+kqp79sOY2NK96dQqSLAGElI743LeajB/rivc62SSQIaTovrGob2k4mssks/XlsDrmbo/phRBTb2HjSniZG73eqPjyIjGobWm8isu98Mk0qjVVSofMnrISSQ8YSgpDhRAypdO/Xfsn8EYy2A3DAAAAgAElEQVR8Vn9fx3VBBBGmPkk9miDCTqxSpc+I7hPE/syS2gLCTzgSiSe7NgqzxUAnMs8NZJIc5TIXmkIsFpYv2c8E+DfCxtxKRe/zutBTxVdyAlSVUsaqyEhel2X/QMBD/9it6oQnH7z5TZ+N8PxkT6cwDFD+GhqOe5tF1UJ9+LHxzTt3gUsIIpSIn5NfQhCy0y/nEmNg3+obWn/EhH8f2/g9XpSTSGAiyyADd++yDFpfFd29q1j3CoGNdiSQzJ9HDR5a2td3j3CGC/xy8ksIor4+digMeoiBt2cK9Lwf9KtQdpiBpD6ZBMFMK1TNVSX5NUEEzoRJTFDf1HoKM4SKxWlhM96CtGnhgwxsGK3m7rBmf5MlQYiLvNrG1q9nrJK8EHwRhPuYcXt1dLfesJtEjh27hw7Yb/gkG/JfopRqylqVSE9uwAMABfoXOOtlcAUBRzl9DWQnuxw/COG1OxppViVTFYKQkRUTQpNereueyUsV5mEt5YQnxcDvidHBEbpr/32sPwU5hBVjSbrnj/twEFSHCkFIjDU8jS6C6lNRH0o2eJOZlib7Ou4PKl/8rglCBaUpTCMuT6vm7LiS0zbjcpIYb584kQvpYn2KIhtV7JUnkSAgJKKKYbqVGMcoQJq2u2f8SDXEQq6jk/pJKdset87VrWaQ3FModEUxieQEqLLBhyI8iQQhPWU6wpQott43LIi7jIaG9o9aZIkLZxVnPHGCv48sWjc8PPdXQZfmqu11p1PZ4H2xdkvjKuMJTDiAhGm7ytotdINXyR9gSuvVpbz7HQajQtKW/R1EtnN+NtABADxFRJfsO9+6z+sEpjLJQi2KgAuw8GEp7NpFbJgkw/hcsnejcF6TqtRyCCKPTU5CABNEak0Q3rPBL26ULJd6OI8JuYU56E+ilLrM7StQyGYg8k57gpCQjcoG74ebSn5NEIXOvCLlHw8YhguFgUFwDJX05urnkj/ZBJGFwnaEM3EiMT6fiXETJB2JrClhDjo8OO9y2SlSE0TuRFORQKZCgnC2NBOL6NxMLCJ3xACv1fMSGbwq0R1/pEjLawYQRK5hgcoGrwlCjsC0kSBkzReXVEOptxqJsAIMYXUjCeMwntPL23KqCMLZJ1v1NETNBKwE4UhZmAhHepM9PI+LQRASHfEEUThIwijWZpUtR2WD95Xw3GayZaJi8mgz1ba0H0CjfBQMPtUj3Iozq4gBdXR/98bfFAP3aS9BqI1tqEtmFYLREkQxZl+Jy1jYsvLtlSnr47tCfn86YxnjjHckapd6YZcDQbigoYaG9gUWzCUgfMYjVpLUgU1ySR3+ojXHHHeif4LECiXUpV/YaTAZBCH1TfCwQPIlI5dJbRh/DVm5QmKurn7tYJMiq4jRBrLD20/8FLywVTGfJIJwRxTI+5La7U8hu1RX2eALlSBU8Z1u6aa1BOEHtv32QXT0GqetuUgvs0ypa2g7E8Q/HCsvhBONyOM2bVT19ladLEL9ELXMmyaGWIB0U5ZIEG4fhsBqcyxDMDGcg/CYpQqzm4CDs4UVuhEWKgEUIb/MNyG0b4cbuyLjQnVNrUK6FCFkxtRQwlM+jFWXL1YKl8yF5peEz8nrgCHzSBfhVxJ9nZ9xtlETROCS90xQ1gSRCZMgQgssFvdnDOzNzCe5Ham8emdLFKb5czAOG0ujZlWhbPstm6QygkiHdjaEGqwZsEQk0kgE1idVQyTUNK94r2FFxLsWY+9HyDYfibOXZ5BCGW4qJ2mp/Tn4fphYERSOwVlnhmgeIGDPXaq1P1rAHwyLb0wk4iII49g3GRKEqMxtogrIPbu95psKdnY9Ir4YW8eCSUR9XchAojq6bZWCR71ddW1T7DRiO3x79gulMil0gy80fxk4yoXCq1CCyX97nvqcZU0QqgvOD0b3Ay4yR5pCHLEkpyGpp25dXWxfRKkLDPEimfikISwK3nxyw3mEChchiZEjzS8Jc/CGwcaxfX0bxctdSp/Ev0XqMDVZBCG5WxlhppWqDlXS+EISNVVtQ+w4IhJvCqSNEgh/Ropb+vvj4hGcwK+Ud0CToWKySc4drBDhw2hLnPpUQ21oggicZekEZU0QooE5Irt48Wxk9FiVZw09CCYneJgk1srILu/mZf29cRGXx++TO74peuqSYiA40QAJwUDmDVpIsDV5hE25ZNDQsOIDFkVECJQxG36h/x2u5piKo2I6plBUOCo5Xwf8tTkyeqR7bCeLIKSB/RTnm+2rs9uOm5m5zTlhZFKexNFQhLg+LdHTOR4OxGfW5RAMEMqzvFAJoBj5SxKsz0OKLVQCKDS/4l5clsnKnyAkUR9Vo4ZKQn5LY/jINl+Fzc77lTuPOwxJeAXxIMyX+nvi/x0QKiQn5LdXjByPYH2B8avskNW7vf5NMM5zOCP6naCFPvx7YPznxJlNN1dFrbP9XvgSGzEZdJUzJEVaosKaZF/n+F1QpuDJIghRXU1D7AiD7GipDgMH/z75vRIoD9Yngtrtsx7gkxzYKT3Q5BE1NnQ4Fa/daLIkCI9w3ykGX5jsjYuQLZ6hc7zCfTNzuyy0eKEbfKH5y3LnV2xU2ROEx8nM71EacdqeQxFay8BXJix077DFOcHnMvjdlTKMtW5vbBEmIVpR8RUmfFbqh+FBEB7hFew3hlOjo1+TSUX2ZXvF6LcI9pvF434ShO/393Se715IHgQhumNjZkaM89z9SV+CW1e5H70JknA8pADRpMcZkTUyh76aptghxCQC/U14R9qPkCeTILzedvB6E9znsSV7CnldUjc0tDdZZN3nDHcNwPPxGpu8mmKHGIz1rseWlMNWq+wJk0UQtlTs8WCQ1zwVRPzCS8YyIv6fXO9z71DzhW7wheZXwb1c05Q9QQjgZOqMDKDupzojYOsjIPth9RwTV78nNH28g8efmQQiDP4oAR9wEINJjB8w2X4Y6SB8PlZQ8hOqnUvU82cQDdhPgYqnJplrABJ3Fs5XukTap8lKHSN7W1lCEKMADAe5pGP8gB5PYyguzG283E56nnU4J7PP85xCgSliZHXbT8KK/lj4mNRME/QMDOv4/u64eBUu55tMghCVe7yUZ5Os4xlMcdp1z4WctvtYMXlIYHYROwH+HWBkXr3jdwhtK4B9ctFRf4NDZROaTIIQ7SnGk6NB0n6hG3yh+VVwL9c004IgBHgZ5y3xQI6ql6kTcxWPU/HmwtkhH2e3VTewUjeyERVRWv85iCDsgH1NsVOJSbya5SYxlXnyFBvU6vVYvYQgNhDodcU4Vpn6ecCKmieqPoiSPgnybQC/W6UDE9MIcqAT/Ry9JpsgRPsOa4nNj6bEe8zO19sCe/cSMdY5357wM3P1eFkvsJJMAt/oAKqFuNNNNkHYazv9KNh69zOiCn0Q4Wc6R6r5s373XoVu8IXmV+hH2SaZNgRhT6SW9gMpZd4IUJNC0D6RJUVEt48SXaAStE9s3vXNsY+zhWsyp2q/gXuVmf8j2RfvbGpaPj/FUWG9o0IQdpmZdy5+Innv1qtOEQr6Rzxa8eWBgVve8EokW+D7zefTX3jFOJuYRQjvt/l0aieIv4EUrg5jrirKy6jCvkEQjn1KxGer1sxUxSV+/ckcDpYSMP5sZUg/lXwJJlzMLO7haGQ1UtYHnW0N8oPIxBg7a5eUeKnjzZOgDUNYO12w3wLuLHaE16kgCJuQm9v3r2D+DjOvUAufw1uI8PlET1y86+0b6r/QDb7Q/EGDWc6/TyuCyAKZjltjxghYAZDYlJ2i99Zdbx3/hUAd5mikQzUktHOQxuM98WcB+shY+bbKhP9IRNdWRviu7EVszgRS38BoUWPbe6PMpzLhKFv9wtgre0IE8AoBT4Nw03AV36tiHeS3wEU7R7niHCJuA9vqMKFWSqszGD+xUpXxoM06aDLb6plhWgrGagYOATDfQeb22Ii6VKPTTiVBZPuavjuKnkogcaksnAOzJLt1l1/LI0y4Zv/5nBSbddhgfdk67Lu2qh0fB2Elk9UAkAgbk5UwBwF+kdjoM2HdkBrac2A6R3P1m0MT1jbR+xzrQQQofG7XGe5BBm3Yf4H5uCo5FrrBF5o/aM2U8+/TkiDKGdCpbluhJ8Cpbr+uXyOgESgfBDRBlM9YFKUlmiCKAqMuRCOgEZgOjnJ6lMIhoAkiHF46tUZAI+CNgJYgZtjs0AQxwwZUd0cjMIUIaIKYQvBLUbUmiFKgqsvUCMxOBDRBzLBx1wQxwwZUd0cjMIUIaIKYQvBLUbUmiFKgqsvUCMxOBDRBzLBx1wQxwwZUd0cjMIUIaIKYQvBLUbUmiFKgqsvUCMxOBDRBzLBx1wQxwwZUd0cjMIUIaIKYQvB11RoBjYBGoJwR0ARRzqOj26YR0AhoBKYQAU0QUwi+rlojoBHQCJQzApogynl0dNs0AhoBjcAUIqAJYgrB11VrBDQCGoFyRkATRDmPjm6bRkAjoBGYQgQ0QUwh+LpqjYBGQCNQzghogijn0dFt0whoBDQCU4iAJogpBF9XrRHQCGgEyhkBTRDlPDq6bRoBjYBGYAoR0AQxheDrqjUCGgGNQDkjoAminEdHt00joBHQCEwhApogphB8XbVGQCOgEShnBDRBlPPo6LZpBDQCGoEpREATxBSCr6vWCGgENALljIAmiHIenRK1rbaxdSkB94wVz3ikqoKXdXXF/1GiKqdtsTU1K/eJVJpHWBaOAmERAQsAvM3RoZ0MvAzGJsPAA6nh0fs3bbrztXw6nDMu4QsZBPAKwKI9D1uEe961AE/E43FTtaic90SAv0Qp1dTTc8fLqmXI0gkcjWjqWBB9EsBCAO8EEM2kTQF4iYA/MtPtXEEPJLs2/hUAF1Knzls4ApogCsdw2pWgCcJ/yBYuPKOionr7ciJ8GaB/ARAJMcgmA48ZBl+87z54NNTm7CbuEJX6JP0bgAv2W8CdKm0pJkHEYrHI317B0RbTJQQcFg5H3sKMr44O7XnH5s3XjxYHCl1KWAQ0QYRFbAak1wThOYhU3xz7OFu4JkMMBY4293A0sjrZtfE5lYKKIEH4VdM5Us1nbH44vsMvUbEIoqYpdggx3UBArUrfvdPwFhDO6u+JP1pYOTp3PghogsgHtWmeRxNE7gDW1cXmUMS4lMHnBpx0dwL06ngJ/A6Xysld+Etk8YmJRLw/aNqUmCAA0PUjg3PX+J3Ii0AQVNfYtgrgq31xIbwGpgxZ8e4A9vHBJ0XA14YH512upYmgWVTc3zVBFBfPaVGaJoiJw7Tw8NjcyiG6HkCrZAAHQegEGddXGdW/7upaN+RO09IS+6cR01jMbP0HQC0SgtkG4qX9PfFNvqd3iYqJgeOSvZ33qkwsoRqrrNy+N0WNJmbrKxIpyCTCaYmezp96lVcgQVBtY+w8Al3uuF/IVpViwoMRy/iviorqx9w4irbPmbPjEJP4PLA9DnNcbTQJdP3w4NxzNUmozIbipNEEURwcp1UpmiDGh8veVOfsuBrgM1yDmCLGtanR0a+FuXQWqhWDsR6gj7rKe6Aqyif6GQLIJIgwBOGsz5aIDLqKCf/u/DsDvzWs0SMTiTu3ySZtIQRR39S6ghk3Szb3u0yDz9/UHX9WZaEsWnTCXpGqiu+CcYqLbE0Qf6m/J/7f+gJbBcnC02iCKBzDaVeCJojxIatvaj2FGetcG9F2Zj4t2RcXJ/fQljRCIqkaojgDRzgmR/DpvUAJwj0RvdrBzMuTffFxKzZHxnwJoq4ptghMAq+9HcUNEvDFfRfwNSoX5K72U21T7FRi+oGLcAaJsCrR03n7tFt407DBmiCm4aAV2mRNEGkED2tu3z9qWQ8AeP+ETa0IG1B9/fID2Ij+HMAh42VzYqQax3hdFBdTgsjWWdcYOxqguwFUZv/GwFXJ3k5x15Lz5UMQQsU2nKLbABzlxJGJz072xNfnQ7LZcjykkqesaGrJQNcdLxa6FnR+fwQ0QczCGaIJIj3o9Y2tX2XgKxOmAPOX+vviQoceWnJwT6XahtaziCAua7Nmsm9azEcP9MV7pZtzkSUIUcfClpVvr0ylfgnQh8bq9PF7yYcg6pva2plZ3GuMmQMT6NrK6Na1XV1dwsehkI/qmlq/B8Z/OgsRl9aJ3s6vFlKwzhuMwKwkiNqGtpOJ7Amd+fjJkWh08eauDX8Pgqy2sfVKAtaOpSP8GSlu6e+PC3tz38+dlwkXJns6v+2VSejHq6t3LGRCjMEfA+FAMPZypB8E+EViow+MDcPDc3+lcoGXD0GItlTNef1iBi5xqWMehslt/f3x/w3oPi1qbHuvAf40AccBOHBMdWBbtPAfCdSRGhm9JYzOPwhzr99tx60K82EA/zo2CwL082HrktXht7GVQoKwT/ejdDcIn3DM94EIKpb09t66PYfUmlq/QAxBkNnP11FO3HUggtsBWuLI84eUYRz1WPfGF8JiJkvvIek9ZY1GDh8Y2LA1qA7b2bHCbGNwG4je51hDtoMegAGA4lVR637tLDoRzdlJEM1t7yeLf4m0V6z4fE92Wcjki00tb2PjSXuaGL0foJpMeW+QxUfLzB/tRWfgdBD9XwDCjFL1E+aX5wY5ReVBEFTXFPs8mL6VDzmEtIm3L4fNVMUlAwO3vKHa8bDpZKdeAGv6ezuvCVuWX/r6xrbvMqwGsHFjkIfw5BGEt3d0WAmivj5Wxwb9AsAeWRxKcbqXtMskolMSPR0bvfA/rCU2v8I0vs/MKyRWVbJsO0H8DaRwdX9/XHilz/pvVhKEbKMPOs2LmVKbSyz2BGLC+cmeziv8ZlNNY2yhAXoIwJ7pdCw9xdW0LN/PSEVucxBJ2EkaaA4YkiA8yIG7UlGsfKwr/opXA21P2pfpHAb+S2LZEtAvegYGndjfvfE3YQEISt/S0hIdTu19K4BYNi0DL0RhtvT23v5MUP5S/T5pBFFEFZNETed58CkEN/nao1uroltPlamx6upi70HEvntx3AGptiB4bquWNN3TzUqCEIMmmdjxqui2k/x0prUNbcuJWGY9EZzXJbrLLgo9rE5Ec0UsHbERbxp30rIdtOo9HIxGmGllsq/jDtkEDUEQHpYkSgvIS+oQTdoJ8O8A4ym7fcQfBONQCYko+Q+EXYR1dbF9EaUuMN7jyBs4hmHrCZu+FAQRtq9hJIiWltOqh1NvxgE6dryv6uraMPiEqctnHU2Ydwzeg4BGAPu528LAjaOD885UUdmG6cd0SztrCaKmIdZokC0aCy9OQOEuIef+YWy0/ReFZHKP7IrX88lkb6fQgY99ksUpfvO1IW9oiL3PJLqWgI9PnHx8P0yskInKqgQhtyDhAStqnhhkQeJhffIqM503OjS3073w0lId1mTUak4nqaJbrNTXtx3GBj8IYN6YBBFwHzQZC7sUBCFTpflJy2EIQuj2qcLsJuDgySDa+obWy5hwkaOu7Rb4iIHe+Gbn+NQ1xIR69jqHOlSYxp47/Na8dZINn+qa2w+FZd3kvI8CUBJJaDLmUTHrmLUEIbHukG7aWbAldwjOcfC9w2hsXPHuFCJdBOyfyZRzwSa90CTqGH5r7qqgU0z6opCEOaGSykSFIAohB49Lxadh8rL+/vif/SZwbWPr4QTc4rSnZ+DSZG+nuI8p2LJI1C2TBPN1SCvmYiw2QdTXn7C3ZVQ8SMC/Odrpu/GFIYj6+tihMOghBt6eLZ8Y30z0dV5cTFyyZamMm1zSCL5bqm1pPxAp6wEn2fmZA5eif+VY5qwlCCEz1Da2imBin1KZ3DmLgdENQvO4EEFn9fd1iFNLzlfbEDuOiIS6xzYDFOJrsrfzdOeGl9kYf+awV99GFi1OJDrSapiAL0ciAl4ni45MJDoec2cNIgjZJi3uTFQkB1FXXWPrOYBt3pn9QqmKJM5rz5oGL1b1xA3CSrIJSk+iQeUU+/diEkSapM2bMqE/xpvKfDcsrPS6hA1DEJI5J+7jfC3zCsFMskbEBeCEdSeRapTHNnfeyu8JC+nDdMs7mwlCnCTd5q73VUV3j8ni7bjSbgfoPwEWl6+2JRQzfprs61wtOeVSXVPbVWBek5kcUusLQUCWQZ8i8EcBOoCIeisjW09RtSNvalq+IMXRHgD/nJ2EXqdiP4KQecSmwzOkliUSd4gY/b5fOq4Rfg6QuB+xv7ASgKwM90YQ1A6/31VVFYXUkU/eAgmCFras3KsiZR5KhFM84hltZxhLkr0bB7zaF4YgCmxvaIhyDT1sA5EJhCRZB0oWiqIxGdXjnQy8CeDXBvAEm3zVbLZomtUE4Vb9+FiyuKQNftKEEYtA6C2zZqvyewi3KqtU1jLFIIhhE4e4wyWEIQexyCSLWPkE59wxJJt40S6R65pa14FxqqO+0G0sIPKqZ10FlKmy2SrFMZruBNHQcNzbLKoWIT8+5hCbAi3uVACcjWlmNUFI9JWmLE6N+/5BqIj2X8CfeeElWmef1tKfdOHniuHsKaUUMgELJQgY/CVmutl14fiXCMwjw5h+uqUyBv7Eo5FmFYcmZ/9z9c3Fs46RGBvMdIJIgfii/ebje0ExkaY7QdiSgMxDHngdhI2GReuHhuZuDrrXK2QtzqS8s5ogxEC6F4TsYirnVJzRe9Y2tZ5HjO+NTQiXPlRWfjFVJWlP69cOthA5DsQnu18/U1YxAc8DMCTmfoEB5tyLQXLyf4mBBwgU8lUwPsAZ26eYklcx7iAKOO1PpgQhzKOTFvEZAz3xp1U2rlAE0dC2hIjFaX0sxAYzrfAyr1ap3y+Nx51Hjg9SxgdCOMK+y6M8EcL9CVi0Psh5sdA2T/f8s54gciadxImorqHtTBD/0C0puPO6L58lEkrok6q4TBe65Uoz9W62cJBB9BEAH2ZAxNbxe2RF6P6lbwmE2dyEBICocZTqq2gS9U2x1kg+2Enrdo2nSGMy09JkX8f9qo0Ng6GrzNIRBOE1ZhG2JP0+tjkSeSi05BYi1IbKnYAqnirpVKyYsuVk0ooovc73w72q2QbCHczGuv0XmI8HSVkqbZ0paWY9QUjMXV9mgxYnuzv+kBnknPuHbNymXIuJiVYPOeatPh6szgllv4k85/WjifF5kP2Wr/vxFKX5lydBiAdxxGPy2QflbasrVaeh6UAQKtYwSgArJJIQSSiCmGzz2zAShEytSYwfJ/o6P6MATegktU2tFxHjMkdGT0s9kSZkiJdssa8T8F1ztOKqUoZ6Cd35Kcow6wnCVgO5AvAx0ynJvg5hi58TDdMpJbhDNhDwd1h8RCIRf8Iu12UlpWAjnu+byCYYL4BsiWKMTMITBD0jAgMSeJUreuYgM7d7vSHgnLvTgSAkfilS0+NirMmZTBAe3s2egQALwVNWl+L9FtU0xd5PTJ8n4ERFiUI09Sk2qNVxUCyk+dM2ryYIeyP39lPI8bp13TO47yEc5OL2swgyt6O6xtazd3l2fydAYshGoNwMYvHO8aNVkd2fNM039szbzNWevuOxj2SObkEvkWVXQA5BENb393SeVk4rxMOZSjk6aJi+zGSCsA9BuSqpknggy0gdQCjLNhEb7IWtxsFk8vFMaCPgAwFB/IruxR9m7pRDWk0QAHIn37iqyOv+ITt47nuIrIidq7ryt8KpbWyvIVhCB54J5mfXYAL8G4JxIyx0V1Zaz3mFIy7Iigl4nolOSPZ0/DrbL+lLa4Tv9/d0nu/n0Vzf0Poj5zOXBDz0j92qTnjywZuFbXnZfBJnvsDooPk0fqYThCyaa1i/FxVcSzFe9kHBGvoI2BIS83LXa3jZZhU9wq9Kf8sljSYIAF6XyXOir/52YtTP3E3e6x5ilEc/MDHWE13d39Mh3pHICReRVlXtsx7gkxwTYydAp/f3doiXugJDTBREELKL+XTI8Q0gWuZo0xsGG8f29W0UDnnSL8eySyHG1VQshkXNsYMiFglLl4PG6+eukWoc7/XiWz7tnOkE4fEexPMweXFQWBVVPD1ChhT1zQkhXbz4Ek4D0f84JfhyPeCoYldoOk0QGQRzTihMZ41UGLc7X+OShciQhI62L7kNi9scr5VJ/Suyg+ehEw8Vf0gagE7Visnj8ryuuf3DsCwR0NDxzrD/Jiq5AB7ZJQUt6++Ni3KUP3s8CF8D8ysgehyMx2DyT4ro1Sp7qUzJmUy5E+n7raUEON9/njGX1FkcPJ41VTZsCMBTqGq/TumHqsY+rzcnbEmczWOIqI6BQzJr9suKYybq+hYBFzrS+z6YpFjutE2mCSIzdBKTvbjBuNYiCDvvdMRXiZ+D+HPuPQROI2C14xUv31hCEvtu38CBstkmEcHVzVy9rauoriF2Ich+KMhx0PZ+lrOQoIPZChYtOmEvo7LiPgJqHZUW3cFQFqANgIj8uSrR0ykL6x56oc8KgpBLm0UhW4+owJ7SQ86diKLlYHZgJeOlCSL0rJ+BGXKitRL+zEwdBM5GpvQ8+Uk2+EeRDoGcfbHO9zJNcuoOZZfv5RikbMXks4jkmzW2wTCO9njMR3YyD7Xp1jbGzieQeIo164BlgvnM/r74DcWeeh4bkFDvrenv7bhZRb3n1SYPM8sZJ0GI/sulTZgEXDo8OO+yPDyXPd4i8SdwyVoMVIs6x09y6f6owUNL+/ru2VnsuTcdytMShGOUXOau4lJV/JdRr3hfMnvExXccfr0jvYpEsrDJqr4Hghw4Qre5QjqnBR4Pr9agaK7uiVvTEDvCIPt1Lqc/xgNVUT5Rdmne0LDiAxZFxHsL73SUtY2Bk91vYLjrqmtur4dl3ekK9/1bwxo9MpG4c1uxF5VQEY6k9v7irkuer7qeUxVeyPcazF/s64v/MUS9abNKi75OBHF/M+ZPkiljRhKEPY+bWlcwQ5Cq22/nrpRhrFV9o7qm5uQ9qGJUqHrOdI2JsLa7fmRw7hovwpEGegSeJit1TFCwSZlEqWCaHmJqTL+kmiCcBOEyd52gVZGE6M7+LnvC0pHX7XiXM0s8JrXJwHU8WvElmcOOOJzNChgAAAVOSURBVNlHqqLngOnzXrbdXqGXwxJExnHvOmdo9LT3MdYk+zqzHuYT+iWRAsTvgwxczqMVV7j7ZF92RrEGTEJf7PR+DSV95LMERf8qd3v9m2Ccl7shQYzDYwT63kjU+NXmrg1/d9ch8kd3f+1Ag43jwfh0JuSJrCk7wfj6yNC8K2Ub3GRHR5U1MIyjnCS/n6m2MM++FYZxXZVR/Wt3xORs2BiTImdk5lmOB7SwEGSL1wbdQ0kt8MBbLMbad70Tj0g8pTP+R8aPAH63o18vGWwe2dd3++/zmVczIY8mCMcoejzPmE7hcf+QzZ5jvZP9QVEHKp/UdiGDYN4CMoQJqmk/k8ioBdmPD43FwLGf8SRsdT6jyYSLkz2d33RP1LAEIfJ7qLE8rVXsTXfOjqsBPkOyUFIM/J5Aj2dMecWibJCcPMXm/N/V0W2XqIY9z3dR2jbyrxhnE7Pw1PULzyAes39FvJNq10U8F4y9guplIMnEp/vFRJoBBGEjUtsQW0pEIsyF02R7IkQkQoLQjsziqgIwX0LO2TwpcSk9PDjvchVVlX3YyLXAS5dFeI0Yv2bQs+l/8kFM+IhkDItyhxI0L8r9d00QjhHykQQC4wDJAomleUXtARWxoVbN2XElpzdU58avMId4C1nGaivCjc7ggV5vVORDEKIRtQ2tZxHZDwGNtY98Xr0LOJkH9csE4YqRt+ZdpLIpBBWm+rtwEoyY1hVEOD78OMhq4cfJoM8lujuFabCvufIMIQgbhOLhyFvIwDmJ7vivgvBzon9YS2x+NIUNOQ8mqU2EUISkVuT0TKUJwjVukkBuYl4+mY2/5DXMHvcQQd7TE4qzN9Tq188FQTyvqRJk7FUwfx0WbhBid85lt4cPQr4EYb8bnSLhl3GUo+EjzLw62Rfv8MAmI77Tla43f31WTH6bQhGXoH2PYIC+4PHwTlBVIlpopwX+9kBPXMT0CvRjsQk41yTW0xItqAH5/l6gisldLdU2ti8iWN8V3QtJuE8R0SX7zrfuyzd4npAkOEJfIUD4H6nGM3uKDD43LCHli3e559ME4RohaYRKn/uHbHa59JHfk4XifiFaWXEyg9tA9D6H+Cv0uH8lph4wNgwPz/2V83QtMTGVhuvOlyDSm5jU4zswJIHtiLQVh8AyTgeswwESoZizJDgI8Isg+mW5RdRM68Z3LGTiExjcKF77c6lD7NAnBPyRmfsNRO4dGtrjt/lIPTOQIMZWlz2nqyqWMOM4AB/NYJjdtMfDxzD/zEpF7wsbhdZvo00fbIwlAIs322syxhNZ44GdAD8PGA/DsG7Ybx88nS8hlftmn0/7NEHkg5rOoxHQCGgEZgECmiBmwSDrLmoENAIagXwQ0ASRD2o6j0ZAI6ARmAUIaIKYBYOsu6gR0AhoBPJBQBNEPqjpPBoBjYBGYBYgoAliFgyy7qJGQCOgEcgHAU0Q+aCm82gENAIagVmAgCaIWTDIuosaAY2ARiAfBDRB5IOazqMR0AhoBGYBApogZsEg6y5qBDQCGoF8ENAEkQ9qOo9GQCOgEZgFCGiCmAWDrLuoEdAIaATyQUATRD6o6TwaAY2ARmAWIKAJYhYMsu6iRkAjoBHIBwFNEPmgpvNoBDQCGoFZgIAmiFkwyLqLGgGNgEYgHwQ0QeSDms6jEdAIaARmAQKaIGbBIOsuagQ0AhqBfBDQBJEPajqPRkAjoBGYBQhogpgFg6y7qBHQCGgE8kFAE0Q+qOk8GgGNgEZgFiCgCWIWDLLuokZAI6ARyAcBTRD5oKbzaAQ0AhqBWYCAJohZMMi6ixoBjYBGIB8E/j80OxKJiN+5EAAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-47"><g><path d="M 51 101 L 51 144.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 149.88 L 47.5 142.88 L 51 144.63 L 54.5 142.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-48"><g><ellipse cx="51" cy="51" rx="50" ry="50" fill="#0cf232" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 51px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Suspend initiated from userspace</div></div></div></foreignObject><image x="2" y="37" width="98" height="32" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAACACAYAAAARZ/7/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmAHFW1/neqe5aAj0WURUDBBRUVl0hm7TgSQHZCkp5J2AUUEQRRkB+LT1FAffjkgWAUZV+SmYawGAEBcch0T/cE8uQhDyMisoQlIC8BhMlMd9X55VYvqa6+VXWruyfpmdz6K5muust3z73fveeehaAfjYBGQCOgEdAISBAgjYpGQCOgEdAIaARkCGiC0HKhEdAIaAQ0AlIENEFowdAIaAQ0AhoBTRBaBjQCGgGNgEZAHQF9glDHSr+pEdAIaAQ2KwQ0QWxWw607qxHQCGgE1BHQBKGOlX5TI6AR0AhsVghogtishlt3ViOgEdAIqCMwIQQxffpXm1q2XBNjyzgMsPYF6P0A/q3ULMLrYH4FoCQDv8u28rIVDybeUG+2flMjUD8E2mO93yHGTxzyeUN6aOD4etUQi83ZKcfRIQAfKpS5xgLvN5JMrKhXHWHL6emJv2ssS3eBsE/xWwYOyyQHfhu2LNn7E11+Pdo4FcuotyzXlSDa2o7ayojmLgDx18oIIXgkcsy4KwI+P5VK/DX4df2GRqB+CNR7UrlbNtUIoi0W3zNi0ZlmLnLByMii1ZOVIDo64tNg4EQQxtPJxNX1k6hNV1K9ZbleBEEd3X0HA3wtgPfWAE8OxD9EDpem04nRGsrRn2oElBGo96SaqgQhiM7kpu8y+CsAnotSLjY0tOTlyUYQ8Xg88uIrxiHM1o8B+hgTzskMDfyHssA08Iv1luV6EAS1x+LHEdMvAEyrB3bE+A1bfLomiXqgqcsIQqDek2oqEkR3d9+nTfDvAexQ6N/fJytBdMR6F4IhtBz2ownCe4bUTBAdsfgMMAm95faual4k4Jew6M7m5rFVg4N3ri3+LvST4+PGbjB4NsMeqJ0rmsh8bjqVEHphDprg+neNQC0IaIIoLJQ+dxBt3fHpBugBANtOAYK4HozjNEEEz5qaCKKgw1sEosMdVZlgvhgWfqxyArCPey/TqQz82HUC2eQXecHw6TemAgITTRBTAaOwBNHIfe6I9WqCUBygmgiiszPewQbdB2CrEhsDF2WSA/8ecudfVFP9BkCk1HaiK9ND/aeHLEux6/o1jUAeAU0QwZKgCSIYo0Z4o96yXBNBtMd6zyTGzxzAPGFlI/t6WTb4ASg9jRCeRo570unEi40Avm7D1ESg3pNqKqKkCWJyjGq9ZbkmgnAf1QAkWqKvHjk4OJirBs7OWN98Zr7ZcYpYSxbtPzzc/0g15elvNAIqCNR7UqnUOdne0QQxOUas3rJcV4Jgxs2Z1MCx1aqE2mf2fZws/gMAA6C3GZyLsHFSKrVYOBmVPRKBDXVnUe334s5k1WrsCcs4EeD9AezmuDt5C+DnAeNBBi3adSfz0UQiYQaJVnt376EE3F1S0znM7gonqyNAOBWgTzn8S4T9+UNMuGrXHTmjUo9XO0SfXng58nki63gw9gPwAQDRwvurCXgchBubI3zn4GDiX0H9Eb9LHKXKrF5mzDhiO6M5ehyBjgSwR3m/+L8ZtDA7us19K1ZcnVWpz/3O3jPn7xplcz4sLADRxwpjlGPgfwG+kbPNvxkZueXNjaFiCuMH4Z7gTuc14YDaNG3tAQQ+BaDPOSyK3gLwFINvtcZzNyxffsfrQZipOLK55TKgzLL5p1K+X3k9Pce3juXe7gFoNsDdFc62gPJck7XFty8EJUdJIcORpuhsEE4A0UfB2K5QrjDRfxag+y2yrh4ZSvyl2jVRlLcpZbkmgujs6v01E05ygF21iilIoBuBIDpi8S+A6UoAn1RrL68kA6cOL0v80U9AvAiis7NvbzasG4Wttn99vBKEr6WHEg+rtav0FnXOjH+RLVwVXIf9zVsFP5UrgwwQvAjinXfe88/m1rVngCDuqTZ418sb/hpAJ6ST/b9TnWDCWTMSzV7EhFMcJCcrvVR2e6z37EbxpPYiiLzs4ZcK45QD02WwrO/5jZHKAr4pCKJ6Z1vvuVZvggghY7bcMZBh4hNHhhJPhpmfIeqZMFmuiSDau/qOIrJVQsXHBPG56aHET1UndBjAnO9WewIolhHye2rvivcS0XVV+HqYBFw0NrrNxV67YRlBEBlJWNYdEvNhL8jEruXsdHJA+KMEmgaLkwlFjIsYfEaZYYDSgPCIFTXnjQwuWeX1uowgYJqHIBK5EECvUjX5l3IMPieTTFwW1K/CCXRAncAxysxfNoh2K1jR5WtU3EGq9qGmEwTz4US0K4BLw8geE+7JtvCRXiFsGpEgOmbO/ywsvm39Ce+Dqti63pPKSj0JIr9pw+Iq2hhqfjaKLNdEEDNmxnePWCRUQrs7BipHjIW5bPZClaNulYKAkAt8RTVhvvfx9RBqnmGAXsuvK7w7A+2SnfE4Mx+bSSX6Zf2tIAjg1wC+QHnVS/F5lYGHCPRmQTi7JAvGKBGOGR4auN0PV6GqaJ72xpUAf7XiPcLrxBAqnn8I4mDw5wn4hGQ3/iRZuYOGh5c8J6tLMilfBPhxgA50vD8KwmNg+nNAXYHqw87OOR9gI3oPgD1d7TEBXgkYGfF3SX/WgDEMwsGl7xqIIAAsAjDbMdYmCGJsUmAa85E5XwcwFYIoLNgFhzLrPQAdAqC5gNObzLibiN4p/H+Uo/RfmcHFz4r/q5TvHCef8RP3mc8x8Ehe9gvzjPA5h0rHWVSFrNjqquw7p4HoI/kXrS8CxX/bf1i+XpX1WKkQtpanU4lr3HLtsw7kAH4aRCNiTAB+LwgzJe1T2kA3kizXRBBirDq64ueA6EeSRUKEzXgIbPxmvNW6v97B+MIs8LIFTPX7gi70FoDmFMth4CkyjPnpZYuFUJXt1u3Ft3XNsSASO16HCoWHx1txkAyHgKO8IJ8zdtmJB5z3DGICrsvRtwm4wLV4vwrDOCC9bPGfPEiCOmLxs8D2mG0wKQavtBinv/99eMh9n5G/L2j6AQEnu04bv2+J8jzZvUTAru0tAi5ujvJV7m+FvrXJsq5h2HchGx4fk2c7OOQWb9zEzH1lnwAP5Aw+efmyhFhQS49Pf/LvNBZBFNttMuNOK8Jnu/tj31NFcTaYvuuSBU+Vb9gFPOwldZjye3p6ouPZ7Re61NUmA7+yxrP/7rHRpPZYbyfZajeXyjfAPL4aPwiPRdtzMyzu9Z5/CfsYZPzSddoQp9b5mVSidOfolM1Gk+VaCQLT941v3TRGtxLjII8FqfjnVcT0oEW8JBuNpFcMLvpnwPu+P6su8F6FqH7vuDjfqVDWq2TRrOHh/if8GtjeFe8johsdO67x9buggzPJgQfd33kRhCAiGDQ7s6xfXHLJHg/VF93aEl19nMyaTNJvUe6DMLkvnU78n0+fZCFVTCIcPzw04FQz2kX4EIQgsCPSyxYPe9UlZKplHSXKSMLH5LmtK76fQXSX80SlEK7FgygbkiCE8+kFu7wPl/oYI8j6YzLzHNliFGYBF+M0kQTR2dn3STZs45RSNAZW9KeKxeLvzTF+C1DbBnnikQiaDkwmb10jk7GwBOFBYLZ6MpNKCJWmp0p37574jtGcOAVST7Et4k7CGs8eIiO+RpPlmgmiuBisy9EVBAgLJseu1G+5ESG/8RBAiWpOGKoLfM0E0dV3IBGLUCL5fjEeamniw4OseexdXQS3O1UqxLhkODVwviJBrGEYB2aSi0cCiFR2ivMiMeqI9V0B5tMcZfqqilx1U3t3rzhJiFNL4ZGfjDwIQuyCT8ukBsSuz/fp6I4fANiLflGlITV5FpN3LLfDDQALa6jCEHlPQGelBaugXxHw5bLGNNoJgvkuYY0VZBjQ1rZgB6PJFBuQkhEFE87PDA1c4ga7kQiio6vvZBA7ZSKUsYvkLvQfVjQ30+uOLCxBSAhMSVVUxLyjI/5hRGxVvEh7IB6TiI4eHupf7ByXRpTluhBEoZMFixi6PMQlYREfcZx8xCC+aOcdcZ+KyeZGIwiXCSrgvztxDnh7rPc8YghP8FVCx8ngu2Tx9qUniBBe5LYZnGWJQGofLy2SkgiVkjsjzxOA1+otKUN6MpISRAjHx+7uuR/MITJIgLigLS78FfkKJO9JJ59Xf2S71wZTMXmeAioXfUGW298KIF76zYPsGokgOjv79meDhQr38wB2IcY1so2U1xiGXQtCE0R37/cZ+F7YDYizvZ2uMgBe2hLdMj44eP264nuNKMv1JAi7n0WbesA6mYB5CqaMrnFXM9kMKxRu4VL9Pm+1wPcD2KbE/gFWSV6C7PV3CUG8SRYfMDycSKuW1d7deznBJqPiclohgO1d8cOIaEnpNBRiwS6Wmt/llC9CspORxwlC2ZGyu/vIbU1k73WqDmQJbdx9YuCFKMyeZPL2Z1Swk/WnkQgibH86u3ovZsJ5k4kgVMbJ7x3VuVwsIwxBSIm0ivDgbV3xboPssERbinbIxrURZbnuBOEcSDsQ34vGbpZhCVO9eWB8RtFUT1xwn7fLjviZ12kirFBUSxBCH968Dvesd3rpLC/DJrJrORJJZAYXC0ueQNNSdYJQP6UUy2zv6ptDxCXrJXF/wdnITGfYE/fiQcAD/9qi5YjH77/p7TCTtHAyutiPjDwmllTdIatbdYdbsSBKdmZBfasIGdNYKqaHDV53aCp1t3CGC3xUPWlV8S1WOJF3EIGdCngh7FoQhiBku3pmOjST6r83TLvbeubsYuSiyxwWnxUn70aU5QklCDeARcJgwr4w+LgAwvDV84UVimoJQnzXGes9mhnXe96v2ClUcT8Di6pJn1ph5lqFR3oQHtKdMvhvgCGc+EI+LIh+hoMgKi4FPQjiW5mhAWHdFfgoLmDU3tV7IxGOLhYoLqeHUwMioY3y0+6+Z2oggghL4psLQdjWhebbezHTHGL0geyIBsXH1yw6DEG4d/4AxoV6CDBCGdkw8xZEOKwssCnT0ZlU/y2FRjekLG9UgnDPWHFJGG1d00YGnUsMEbaiGN6hNNBeF7VBC2LQ6hDme9v0bNobl3PebyDoEj5vd0+4IUeRxY8sW/xCUFskjnLKO+1i2ZKdztsW8wEjqURSvBPaWSio0eW/VySPUVzgPWtR+b5ux393roMGIoiw6q6pRBD5DWVuO8to2RPMO4N4BoE/7wprIZOhuhFESG/yULPGmaioUWV5kxKEE8222IK9DDYFm7rCWMhNNsMs8LJRC/u9HYPpZRIewOISPkxa1SeI6IKdd7SWeqnL/GIxqUqcxFtX6LxKl7qaILyRrJAFTRAVYG0sFZPt32NiHpi+6eGgqTIlNEEUEzvVKMsNQxBi1GXOKF6XdGEXeLdUVfv9hoBpOEeYhwfE+ylWK6y0bmyN8uky81hNEJVzXp8giooHtcBxRQQn6wmihg1YDoxVILzPYRKtCWJTEkRPz+xt1uWaxSXlvus9YpsA7Mh5fZqwkKnpkYT8lppRVrvAFxtX6/d5tc3xrety73QTYS4YIgzBLn6dJ9DC5ujq090ObPUgCIlDX3B0zSqsMVQHV2WB9ytL5ftGPZa7+1VLLKbNQcVkRx/YYu0lYJwZoMIdBXgVg1YYoCHi3MPr1m33VHTamr1c6VAnkiB8c3Grzg/3e40qy1WdIKb3LHhPcy73B4D2KnbUywksLGCSha5MVVKvBb4eBOHuWx4XEeeFTxCxlCQWW1IHNjdBVHPRKjHHfZkNmlX0wt5r/2O2fNc7Y3c4vZOrqUd1PFUW+FoJQnxfkZOkiiN1xUVkFWX49UUTRB4dmZmy+Lsk6oD4sx2qhy261SJKbxGd9rzTZ8CJd9i5HOaS2m3AQMA/YfF+w8OJDbGbVCdFwHuNKMtVEUQhPlGiELyrOPpKHsZBWErMwaSCFbRjDqqnwnIFCAwIF1RmmdC2HbUVRbNXOS1s7ElCqLDkqbwIq3SiCaq70puUHx+PRmc5Q5pUhGdX9AoPqlv2+8YiiAqT2yr6VIGdJoiKIZ2oOwgPM/KXyOJ5qn5AE0kQnZ3xz8CgBxh4TwEUZcfFsPOmEWW5KoIQHa/0DMSoxXz4SCrxQFhgyhZWl0MJAGmIBcmuLFT2OUm61AqCKITLECEfZomNDgPbM/ORRcugoH7aJwrTvAeMvUvvShYfiaXEP0yDZ7mDsvnUJ0JgXOMMGcHAdZnkwIlO/wxJSAOluFKueovhOoS3bt5DnK0HWpteu92pOttoBOE2UQXKTk5BYyQiL7mxC6vWCapDnyC8TxASM9LQ3v1uH6D1wS3rpmKSaUsQIspBUTaEx75l8D3rw9SI6LSPEfA3Yr4qlUo8X3xHsmnd5LJcPUF0xjvYsD0Dt9owQXhwvBWza4jcSh2x3p+B8U1HmRU7YfGb1GqHaa7KPYj0BCQRqnroBVWOjRKCCBUuQh5CozLWSy1B0YrjIYkrI054V2SSAyKvROnZWATR0RHfGVEaBOPDxcqd5oNBi7c0ZL0+QWy0E4QkjlLoRVESX6xuBGFHrK6MX/Y8TJ6VTieeDpKvwu+SGGaVG5lGlOWqCcIrLO16M9XbYPLJAZFBpbh2xnrnMuOmsqicwIXDyYHvuz+QhWJQZfaurvkxi6yl5eQm33W4vRv9IjG626jqTSyztWbgfwwru//w8B2vBgihhFQhDXZWSF+6CESHO8p8FcSHpocSy4OE3Y5qmdvhCrZTXpaeUYZxUCa5eHBTEESNE1g2cRsr3HdIsppsVkzuU21YHX+YuVza5MR6rwfjONUNhSzCKkBXj49ufZpKStx8Xg1LbKZL0WoBXtIS3fIo171KLWQ0IbJcNUEIcOUdF7/wSiLj//nZ/jsXk3x2Mzq9EBBrmuM3P6auVA0AgYtdYQcsooS6E8tIdx2d0pOSmnBILt/KnNdKR8uKgIDFX+imlqj1dZ/IsdTR3ft1d7Yxvx20TNgVwoqLBslDi3tEGt1YJwjRsK6uuZ+wKCLiZQlTx8LDg7koFjwymHjFg/i8swSGXJSDiHUqqpiCYkSpjr9ErQIwn5tOJX4SFL6mMDdvKx93ezR81c3uU32QgY3HxiowU6S9RnbE340IiURh+zo3VV7q+EaT5ZoIQnS4M9b7FWaINJduL2jx84sM3EzES1oi2acGB+9cWwCJpvcs2K7Z4j3A1jFgzHcEwyviGJgdrSL4nP0lPUOG9RV3Hmjbf6H1jV4iFqEeZI5uUoLwOCl5Jm8pCIWc8DwWUz9vTa98tiJfLTVlf+RO4hN0wvE4BYhmrwHz2bBwqzustE9uXE9CVl0gvBbXkN97JkGS5QS3nbHkyZbyzdEEUTEsEqMQ3xwVquPnkZVylIAL2eQrZCHO80ml+FwGi5AqsnXH02JKdKwysCWehMmH+6mMfDbDSw3GWalU4q8u0HzyvftuMBtKlmsmiPwlX/xMAgnGlw5W0A5L8rtSHmJf72DGszDwsFdaRhHjBiRyEtvxUewF0gLvN5JMrHC3R87q9lsmGC8wIVNIhxgBW58D0cdkJq5eqhwJQWQBGA6b8LI0k4D1aYCmS/AOPEGJRksT8mzotDMNqEjP6FXXKBN/OzOUWCgbX9UFok4EAd80qsAqBpL2GBF/KjBopCaIimGRXtbmyfR1ML3B4FyEjZNSqcVD4s8hxl+uGsm34C2A/wwYheRcLDZ2ImjmDq4GvsbAurLQ8D73kRJjDVGcuDx+CSCRJW5Zc9O0U9xmtTIVuKMdJRlj8FYE7CPNJ09IR5GbOzS05GUv2W8kWa4HQdhi0tYV33d98ncR0M5xzK+CGoDXmPkbQZmaiiVXl+g8r36ImvRjhy7S92KrvbtXOAWKUCAOPaJy/14ig48ZXpZ4SPaFxMx1kEAPMyCSCymSLj0Dg+b5pBotqzpvXkhXAxDhQ8I+gQnYQywQ0rqr+d7+Jmf8AuBjQnRIpD9dyIDYjW5rf6cJQgaf7K6r7L2Cs6wdfC7M+IXISilpFw9xNHKskbXOd6Ys9UqUJArw2fAVyveOptwZix/MTOKeNC8roR4esaLmPK9ERs6iGkWW60UQdt9Ep8ZzdAID3wGwcyjsgLUiBy1nmy4ZGbnFTk6u+ogjZ8S0LiOyk7v7BdPLrTdV/UVrlM8Xen2XLjLQD6K9Z/5ulDOvAyimELRPND9HRLdnic72C9pXQRCMh6xc0xFGU24mwNcGxH6y8+KauaYLwuLmCG9wqep4eam83GMVZoGQjXO134cL2cAryTKONQ3LKvPE1QQhnXqy9JnOF526/LDjV1D7XUyAuFNT2RT9nRnn7fo+vl3EOKs4Ffj7w8jS55a6EnS/Yqu4mC9l5rmKbX0LxD9EDlcGZQV04tkIslxXgih2zk4atNrYg9g6BEwdgJ0HYkeX2kUcH58HjAfJsO4ee3vbIRWLAB/SoLZY/OMG6BtgO+H9BwqDJ3a7zzJoiWnQr5wLdViCKNZtE5JlxgmYC9CHXEfe1et3sH8nUL+ZjfQ78zF4tV1GEMW0pvm7hvGT1t+tHOsIXjYK5pUwsCgK82a/46oKyRaj6kZgnMhkdQEkQoYUjQXscWLQUgt07fJk/9+CLg/D7iDrSRDFsuzNikmzmfmUsuiftkqElzNoYXZ0m/uEzOlgfXnUvDydneOTNygxvsxsnSRRpZYSQoUlCOfcipqmKPtgAHs4Eo7Z83h9Xpb7GbRo153MR53BLyUm3G8abBxSVHnJZKwtFt/TYBLpc4U6yKm2khqTuMsQKV4jTWYfg/tc64AJ4BWAHweM61qi1r1BKYr95ummlOUJIQiVRUm/swEBP4LQOGkENAIagU2FgCaITYW8o15NEA0wCLoJGgGNQAUCmiAaQCg0QTTAIOgmaAQ0ApogGlEGNEE04qjoNmkENAL6BNEAMqAJogEGQTdBI6AR0CeIRpQBTRCNOCq6TRoBjYA+QTSADGiCaIBB0E3QCGgE9AmiEWVAE0Qjjopuk0ZAI6BPEA0gA5ogGmAQdBM0AhoBfYJoRBnQBNGIo6LbpBHQCOgThJYBjYBGQCOgEZAioAlCC4ZGQCOgEdAIaILQMqAR0AhoBDQC6gjoE4Q6VvpNjYBGQCOwWSGgCWKzGm7dWY2ARkAjoI6AJgh1rPSbGgGNgEZgs0JAE8RmNdy6sxoBjYBGQB0BTRDqWOk3NQIaAY3AZoWAJojNarh1ZzUCGgGNgDoCmiDUsdJvagQ0AhqBzQoBTRCb1XDrzmoENAIaAXUEGpIgurriH7UM+iYsHADCrgAihS6tBrAKoO+nk/1L1bup39QIaAQ0AhqBsAg0FEFMn/7VppZpa89h4HsAoh6dMZnp0Eyq/96wndXvawQ0AhoBjYA6Ag1FEO1dvV8jwpWOE0NFTwj4Jyzeb3g48Zh6N/WbGgGNgEZAIxAWgYYhiOk9C97TnMv9AaC9XJ3IAXgJoBzA4lTxLysb2WdkZJFQN+lHI6AR0AhoBCYIgYYhiLbu+HQD9ACAbYt9ZcbNnGs6dWTkljcnqP+6WI2ARkAjoBHwQKBhCMKdNIeBF6Iwe5LJ25/Ro6cR0AhoBDQCGx+BhiUIAA8bvO7QVOrutzY+LLpGjYBGQCOgEWhcgmA81NLEhw8OJv6lh0kjoBHQCGgENj4CmiA2Pua6Ro2ARkAjMCkQ2GQEEYvN2SnH0SEAH1JGinBDemjgePF+T0/8XWNZuguEfQrf/z1KudjQ0JKX22LxPQ3GTwCaBWAaCK+DeTmDFmZHt7lvxYqrs151zphxxHaRpuhsEE4A0UfB2K7wrrCmeo6YhkxY1+TWbTviV46z/Ir7FcI5maGB/xDvxOPxyIuv4ABmnAqiGaX6FNosMBg3aTYznwLQpwD8GwATwCsM3M/EPx0ZSvwFACtjrPiibPwYOCyTHPitShHVfi/wWrUae8IyTgR4fwC72WOcf94C+HnAeJBBi3bdyXw0kUgIPKp5aEZ330cM8AkEHFZWT35s/kqg/tx49pbly+94XbWC9ljvd8iWzfxTxKyt7aitqCl7HgFfBrA9gFEwr2TCzdZ47gZZHcJvKNq6pi0C40QmjgH4QMl/yG4jniXG73NENyxP9v9NRQ682ifamm/j+EnEOBpEHyvgboLxAgzcZ4F/Xou8if60tr4xnQlxBn8BhN0c8080YRTgVcRGCoxFY2Nb/1F1DsrGZ++Z83eNWGacgLmuuS7U2k+B+Xe5SOQ3jyxb/ILq+Drf81lLRgE8C9D9FllX14JZNe0K882UIgiY/AVEaDaASx2LRjkeTF9Lp/p/5QYpLyzWhQQc4+Ok5/zsRQBn77ITDwQtQl4E0dnZtzcb1o2APdn8nifYoN7Msn6x2IuHOrr7Dgb4WgDv9fnQZODG1iifXm9VXbULfLGt1XzfEYt/AUzCT+aTakLOK8nAqcPLEn9UWRyLZYoNBjFdQ0C7Qj05Yiw0c00XqFjbyRZgMoxVsPg2gD8or4+XtkS3jA8OXr+uOP7tXfFeIvpPADsrtFEQUYaJTxwZSjzp974HQSxVlDe7Hgt03PJk/1Mq7RLvdHTEp8HAiSD69wB5dhf5GoAzVOag80Mx15uYL2XmuQpzPQfQAEzrG+l04v9U+iSINBLNXsSEUxTKVx4blbrr/c6UIggCrmDgx57kAPzDNHjW8mWJfziB7JwZ34ctugnA+0ICrLQAywgCFj1NxNcXdv0q1T5JVu6g4eElz7d3x88kkNiFenmbu8u7DSYfm04nxM6lLk81C7yz4pDfU2FBvM5nbL36ZRJw0djoNhcH7Tbt09zLdGqADHnUQ8/AoHnpZYv/FGYBJuAMBk4GsKfHdyYRHT081L9Y/G6foF7C2SC6yM+h1KOsUSb+emYocYMXYVYQBPPhAnMiCoP9GiI+Zngo8bsgYWvrmbOLkYvcBlBb0Lue+ICuHhvd+oyg8S1srOYBfE2IeWdXy+JEYdBsxyZN2pz8pg+Lvcnes5dibp6dTg78IsxmpkrMlD/bZATR0zN7m7FcyzkA3p1vLYvj8ZccLX+Jgd8TaIM6iK3l6VRCDK5MxTQOYMwx8K8y8BCB3gasdnuXTrQwPdR/unMAOmOmjklYAAAU70lEQVS9c5khyKGopig2wQRBEEkKTGME3p3zO0qhxil7mHBPtoWPXPFg4g0Z8m6CIMLdzHZZQpUgHhPglYCRyQsjf56AT7gJgBi/scAPuiarEKwUQM8weCuCrXIrllvqi3ORUZYOnxdDLvAVJYX5viMWnwEmobpy90s4Sw4DJHaS8BmjcWY+NpNK9Pt0iTpi8bPA9CPJwitUV38GjCfs74k/BcZnJDLzKogPTQ8llnvV416A8+rPkhqzNJaFBaYLwN+tbGTfomOoh7zaah4mZAiU9xnybuMahnFgJrl4RCqrlSqwnxDwVad/klBdwcDDYl4A1qcBmi7ZrARiMX3f+NYt6yjBwH6utthqUgDLi2MLsDgpdwLYQdLucWZakEn1L/GTbZ+5nmPgfwn0qD0XvbF7wormDhwZXLJKVo+PnAon36dBNJLHjN8LwkyX+iy/DhCfmx5K/LRRSGKTEYQbYPciigArJskdxIbFEHQ5m9YFzh2zOFbCMLOPDCaE4NlPx8z5n4Vl3edaeEwiLI4gd7a4z3C20969vUy96yfL5e6jMIEWNkdXnz44OCjuKsqeir6V/3ynafC33KeattiCvYjNBAF7OF4XE8cC0CT0sQRcyCZf4exnYYd5PIh+Xr6A8b0wMbdep4gwC7xsMql+39NzfOtY7u1bAJpTLEfs5sgw5qeXLRbhVsruV4Qeu7l1zbEguqyczHl4vBUHeZG4x+LxGjOdmV239YB7d5qXP5xWUIs4Nxe+i0gFQZTA4RGORuZnBhc/W/yTqGPUxPuLaiFbp93cdD+Az23AlAdNAye45Uf8Lr5fl6NvE3BB+QJOt7ZEVx8nlVUXQZSPnVxlZ7erpek/Ie4mNgTWFJ9Wg4V0PhTbIQJ5mkQLCfiiq22+8u0x1231YC6bvdB9x9PZecT2iDRfwczzyvpE+K/00MC33HLX2TnnA2xE73GdBD3LF/P0+Zewj0HGL12njVFmnp9JJe72I7uN9duUIwgGrsuObnNy0HGzoPdcBCJxhC4+Ssc8j2PxqMV8+EgqIbzBFQmCrh4f3fo0r7Z2dMcPAOguAM2uIkeJcMzw0MDtHoJCHV3xc0D2brj4vMwGzQo6IqsKnuoC71We6vftM/s+Thb/AcBOhbJeJYtmDQ/353fzHk97V7yPiG50YDfOwMGZ5MCD7k/E5iFqWb8H8HHHb0/C5MPT6cTTvvV09+5LwC3OTQYDF2WSA0KfXmEcICMIW30RNb7kJAdZne35uoTapigPTzhPF/WQBR8CG8xFscC5wXLW56X6EpuY4eTA991ta2tbsIPRZIqxKN0nEVH/2DtbH6M0dyMk1GTxYrl+jrU9PT3RsdwONwB8pHOuM/OXM6nEgNdu3d5sTHvjSoDFCar4VMifKH88u/1CJpwUpnzx7t498R2jOSwCqMfRl4w1nj0kjPGD6rwN+95UI4g3yeIDhocT6SAgOjvjHWyQOD1s5RgYz4ntLq+jI/5hREgsXO8v/cZ8FywscO/SPU4QgZO7u/vIbU1k763Qz3rsYpxtlCysngtkEFay31UXeK+yVb9v7+o7kIiFeikf8l3RP8beAERwO0AHFttAjEuGUwPnV4xld++pgB0ksrQIBKmKnGV0xnqPZoa4TyqGpZfedYlvZAuw1yLqbmd7rPdMYvys9HeHVZ/fGMoWY2Y6OpPqF8RW9tRCYGJBbZq29lcFS6xiuVI5l5CdEvEXC23rincbZM/fLQt/W0sW7T883P+Iu0+dnX2fZMPeZGxQUTKfm04lxD2er4WfbPPgHi9J+aFURZK1pOzeqZr5Wa9vphhB8EgETQcmk7euCQKovbv3cgLEfYSvIPuV01G5sKyxwPuNJBMrnN/JCEJ1UeiI9V4PxnGO8qR1uNspC34Yxgw1CD/VBd6rHNXvK7ELMcax3vOI7TEWOUQeY/BdbjNcoQdvXod71pscCv22/fidAGT9kZUBD2s5yQL8tsV8wEgqkQzCXPJtoiX66pEyVZGrLOro7hUENgvg5xj0GGDcKLuH8DhBnJZODlwV1D7xuySmmsnMc9wqk87O+Gcsg75M4M8D9AEiSjZHVh+t0Be7GaryI96V9OkvOcP4kqr5amd37/cLKQjsugl44F9btBzx+P03vS3+7/7dtuQKeQJwlwFUWK6pwF/3d6YUQYjgfpnUwLFBuwLZztxrd+mHeHf33A/mEBkk2EmNCqtLpRmthCCUd/OdXb0XM+G8De1QWyBldzSTkSDyViEs9O7bFDBQtkpSmS2SBU2JgN1lV44TpIu3ZLH6hxXNzfS6+CzbaHT1zSFip1ox0CpJBYOyOirvIDxPQ7KyC3dGCYAOcRDuFZnkwBlh2+L3vipByNoDoivdxip+dYnTChHdSsCrAB4lokHOWXcJTYF0njn8nFT77D4RNUosuqlFEIoDI3YvMOgBBt5TGEDlBds54HLh2+DMV3y3lkCElQuK2s5iqhCEdHduA8srQbiWI5FEZnDxc0GbAq+J2t7VdxQR3+xYzJ7ibGRm2HDy7RWLNz8+Ho3OWjG46J++C7CiykyUMWNmfPeIZas1d3eUKSzg/gTGL61cdGnYdrtxqeGUUiqqPX9yu7j4B/eOW3XRrAdBCPUaNZnLnMYezDQ3yOJJtY2STWJVCc3y95rRZY6xrWpNUm236ntTiyA89KoVk6Dysq/qC9yKnaNkwktOECWv76CBkphFlrzJ/b6dKgQh+ijR8Zd3PW8qej8Di7KtvMzLUkmGl2TnX2leHTRIecIqM9P22gHWuABTe3fvDwpWSV6tWgXCUmbc3hrdIulwrlPqRYUfBOH8zNDAJUofF16qRd796sl7Wr++h4XIYSA+quBgWrz3KXmlO8uQnBA97yrC9LH4ruQuZFyohwCjbGMQVDYzb0Fke+xvuBNVXM+Cyq7l96lFEIqhHuopwBUTXokg1NREYmA1QQD5VLRvXM55a5LSguAh+HmfEsINOYosDtIzS+54aplPzm/l91FuFY7iRXOxYHGiahqjW4lxkEJDhf39CjB+bWZzd6pYxVQ6yoXfbdeoLqHpPQu2azZzH2QLuxtEwqT3swyIRGIyH4gSDDIVqltFWe+MlAEm7ApD5P0KK2pEaqok4GNNEHmAlHf0bjwlO8KKssL6eDjr0ASRR8PPByVAxp8gogt23tFaKguJMtkIQvTVttCK4jQwfTeER7DwockwjG9nkouFI5/UescvFpPqQhT2Xqdg/XQAMc4CYe8qvOXtpskIop6bQVn/NUGoSkWN74VdRGtRodRTaCR3BBWWVGH7pgnCW5hKiwkgvPBFeAaVcCOeIVEmI0EU0bEd4UzMsxfWfDyvoNOV+DQnLOjGRrf5iczfYCMTBHXOjH+RLVylEI/MKRT5AIFknyhKToqaIGpchCWf6xNEvU8QKiqmEBeT+gThLfTCSGBd7p1uIswFQ1jN7OI3RWTe7hUEEVLlE3ZKVjueQfXYqqd1NJOABSDsLwnjULbAMvg7mWRig09F4dd6EITEx0F2Qhemt1/3DayZb1MhJz1WgFj4Nz3cEtnycdN8c1t3NGgZQbjVXRtBxVS1NiJojDfF75srQbg9Uqu+pHb7U8gsNvQJolK0Vc0Uw0yKvO+H9cX1Ib9PAPAFWawktxd2Z1fvr50esBNhcVOPE2EYHISpflfX/J0smAeC8BWPWElyBzZ3LCbCtzJDAyJsifKjYtHV3j2/jWDdWxbjKR+T7E8E4zpYWNbcbD3rFYVYVX4m+pLa7chZbwJSBn2CXtw8CaIyfENVpml77X/Mlu96Z+wOZ7AxEVBvODXwlbJFobv3UAI2xFaZAieIWh3xJKbGUh1ytXJv5y6IZq8isuMDlR52LXgS7+SnkeOedDohwrnX/ZmoE4RfQ/PewKYIK18K5yACwzHToZlUv1ikS4/kBBHah0Hiu1MWrtwj9MVbAJ2YTvbfpmKyrEwQleajCGvmauddydGS9VZyH11/QvurBfwlCvPyZPL2ZyRyLHUMrLsgbaQCN0uC2OSOclOAIKR3QCHsyytCaEguGQvhMkQ8KpH4qZ2B7Zn5SBWvYzF/bBIzzXvA9sVn/nGpkCTqEGGmeHg6mRBhHJQf26uecCGYXwHRo2A8ApOvrQi7UqUVU0dH/N2IGEKNNjMfnRiRCKyDxSKl0si2mXM/YlgRkRejlD9CZiUjuVPzDXLorlvFcUzmYBrWe13iQCndYMg2cQyEIj1Je0ve77KNUlhHPIGhCNdhGXzPehNmoVJ7jIC/EfNVqVTieZXxnah3NkuCEGBKQm2Ecr+3y6j0OlULtTFVCSKEzbwE/4oJrrLYBE2MoDuGWoLGFesW0UyN5qal5QmG5A6N1Z4gOjriOyNKg2B8uFBvqJ2qKpYSmVaOb5Zf6CpinFV8L/Md8Aqk6DW+kjA3nifQyjAWCIyD5qy3M9Y3n9l2piwYAZQ5QVJHrO8KMJ/m+OZ5mDwrKNCj432Zf0vVau+gORHm982WICYkWB/kIbWn4h1EXk2w/a3OiJrw6L9bIKWBDj3MFN3qijBxbjwWRbfjF3XEen8Gxjcd7QyKllvWpfbu+LcIJFLIFq2ITDCfXMxd4ny5WoKQ4a0a/VTULyEYqapFGovJIwilZFxFZjhXhOTKOSE5tYVS8YaRHw/SAhSD9UnTCrhCdbR1xfczyI667Aj77h+p2YmdPBQ5L2mJbnlUWEfHMIu/yrubLUF4hPvOMficTDIhLuU8ozx6hfv2iuM+FQnC4wQVuLDmVSUkEvfs6xZQuaNTZdRdQG3ySUJ+SwPjdXXN/YRFERHvyZlRUCScOkoWHtw1uTthWXe4wn3/j2Fl9x8evkPE7iknkypVTPZCV7GTVU4wUxH+PYSnt6g6MP6VHRp7i7WXgHGmgyiliXw87p9Uw/R/mCN0GwGfrpAfDxWnV7jvgJD5Xtn7KrQEHmtJIGYF4pbNB8/UASqLej3f2WwJwh4cj4RBzLjTjBhnur1whbPWCy8ZhxOxSMbjSk/qvWhNVYKQWIgIWNeI4/Yu70O/0zFtQ4IUXOFl8y4jCNuLeos3bmLmPofgm2KMrAifLUuUIyYsRej0QgTODbs6n52w5BQgqhtl4CecbbrMnW/ax1nNlySrPUGIxshVWfBMSiO+sS/rm7I/onxa0w1+Eh4h4z2iudok4TUvCiGxr1ivOxf54EuP1wnHI76W8FX5FWebzpXl9s4nJYqeCqazvJwD/TyPPTYBo2D+QUsTrnRbS3kmQfLAzWMtEfvMpQbjrFQq8VfXwu3jA6K2AaonEXiVtVkTRH5XVnvKUWEaOdbKcdWUo6o5DaS7dEU7/VocCVUFzyNRSvHzYsrXNz1SLD4JUNKZjMUr2qzH5LYXLVeqzQjY+hzIdhpzp5D1TYHpkRym2JfylJTgDwIQ6UAr0tQy8NPW6KsXeIWtroUg7AVfqs6wm1me1pK4BcxtAIk7C7czYTG/uQhyWPZICEKk/DUc5OLEQiQ4zKfzrXTS86yjMO/cOTSK7RCL9kqQ8d82KYk0uiI9L9kRk52OgG+BsNpxJwMOuAPzmeujIDwGpj+LOjxT/gbMc5/yRd9WMZAUKWF9UgMLI4p0FLm57myWqnOy3u9t9gRhL8L5pDQiQ5XIexvmEeELBsZb+RS/AHFT9QRhL1hVJJ0vJoAH86HEEElb7McvHHlBb12WuS3EQL1EBh8zvCzxkN83HmoS1WpEDvPLxt/Z5jy/jGi1EoSww2qPxY8jJpHc3k1QKm19gg3q9cosKCGIRQRaqxgHqziSI1bUnOcXwjxkfC1Xv3glWcaxVoS7nQmUVML9d8biBzOTyEG/rQpYG95h34x6xfeqL9+eAYG4hWtz7W9rgihgKI7JTcyXMvNctfANvJIIZw0PJUQeWt+sVFOZIGySaDtqq0g0exETTgnALq+maOLTROrKsF677T3zd6OceR1AMeWwEkS3Z4nODgra55hKhaM/ibzjpXSY/lNNnqtZ9k0dCMIutmDmea16G2112a852/RdmQqn2FZZ+3bZkU984RXj68QsQnj/mw8Wb4H4h8jhSpXc5/n84WvPAEGkZ/Urt1jla0IlBAvXiPIrLrsJSj4sYq5HTOsyIlslFhSeJFSfREPDryUIXUftS79aCZogXDjZwmOZcQLmguijjpAFIl/1s+szj93PoEW77mQ+Kgv+Jl0UpqCjnKyfeez4ZALPAbBbYYcr7LqfA+EBC/zzkaHEX4qEGpYginWWjRHoQ64on6sB/juB+s1spL/a/Ah2cMDV2BOWcSJg7QuQSC1bXMRGAV4Foj8wG9eHkoUaLqklmNOM7r6PRJmPY8KXQNjNIa/idPsKAU+CcONYC/9WJQy6H4EJ57QsN51KxH1gOyeFWFzfAvjPYFxr5ZoTfuTjtSQJfX+0uekoBve55pwtO8Q0BMaisbGt/+g8nUlMlE0iHD88NFDK7+G3DNp3J6Z5EogOBrCHY3ztPgkZyo1nb1GJgiurR7Qv0mT22f0ql1N7bAB+HDCua4la93p5jKst4xP3VsMQxMR1UZesEdAIqCJQrxOOan36vcZGQBNEY4+Pbp1GYKMioAlio8Ld8JVpgmj4IdIN1AhsPAQ0QWw8rCdDTZogJsMo6TZqBDYSApogNhLQk6QaTRCTZKB0MzUCGwMBTRAbA+XJU4cmiMkzVrqlGoEJR0ATxIRDPKkq0AQxqYZLN1YjMLEIaIKYWHwnW+maICbbiOn2agQmEAFNEBMI7iQsWhPEJBw03WSNwEQhoAliopCdnOVqgpic46ZbrRGYEAQ0QUwIrJO2UE0Qk3bodMM1AhoBjcDEIqAJYmLx1aVrBDQCGoFJi4AmiEk7dLrhGgGNgEZgYhHQBDGx+OrSNQIaAY3ApEVAE8SkHTrdcI2ARkAjMLEIaIKYWHx16RoBjYBGYNIioAli0g6dbrhGQCOgEZhYBDRBTCy+unSNgEZAIzBpEdAEMWmHTjdcI6AR0AhMLAKaICYWX126RkAjoBGYtAhogpi0Q6cbrhHQCGgEJhYBTRATi68uXSOgEdAITFoENEFM2qHTDdcIaAQ0AhOLgCaIicVXl64R0AhoBCYtApogJu3Q6YZrBDQCGoGJRUATxMTiq0vXCGgENAKTFgFNEJN26HTDNQIaAY3AxCKgCWJi8dWlawQ0AhqBSYvA/wcO/kj32m27bwAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-49"><g><path d="M 101 201 L 154.63 201" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 159.88 201 L 152.88 204.5 L 154.63 201 L 152.88 197.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-50"><g><rect x="1" y="151" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 201px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">GPU driver shuts down clocks and sends SMU messages</div></div></div></foreignObject><image x="2" y="172.5" width="98" height="61" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAD0CAYAAACB1LEoAAAAAXNSR0IArs4c6QAAIABJREFUeF7sfXmAXFWV/ndeVacbkG1UNkHAUVRcRg2kq7u62lbWCCGQUNUJEIKiLBJhYEBGYFRGkFFHEQZEEISwJd0lIQiyKvaku7qrA1FEjMgoqCBLkB+b0Eu9984v91VV59Wr+7ba6K6+9Rek7/qd++5377lnIaifQkAhoBBQCCgEJAiQQkUhoBBQCCgEFAIyBBRBqHWhEFAIKAQUAlIEFEGohaEQUAgoBBQCiiDUGlAIKAQUAgqB4AioG0RwrFRJhYBCQCEwqxBQBDGrxK0mqxBQCCgEgiOgCCI4VqqkQkAhoBCYVQgogphV4laTVQgoBBQCwRFoGEHMnXtSS1vba/9iwlgAwoEA7QlgFwCRwnANAM8D/Bcwfm4SfvruXfFIOp0W/x7q19OTfNtEju4A4dOhKpYWfoGBV8FYr2m4T5/I3bN+/e0vBW2vI5G6AYzlU+UZD7a28MKBgfQ/grYhKxfrSi0g4Kf2vzFwRHao/85q2q1l3Vgi9WVifGuqTcLKkcH+E2rZR7GtRvZVj/GrNvMIyL7Z6bauZ6Os6k4Q87qTe2smfYWAJQC2DQnyKwxcbU7mvhNmc64RQTiHqhPRbTmicx5at/ppv3koglAE4bdG1N+3IDAbCKKjI7kVNJwIwuTIUPqamSD/uhFEe/ux20WiuYuYcCqAaJVgvM5E5++xi/mDIDeKOhFEcQovE/Gy4cH0z7zmpAhCEUSVa35WVW9mgkgmk5G/Pa8dzmz+F0AfYMK52cH+b88EAdeFIDo7e/dnDasBfo8HCAWVEk3ky3CrQ+XkrGqA8CPofNbISHrMC9w6E4ToehOIF4wMpte7jUMRhCKImbABTJcxNjNBdCRSV4FxShHrWU0QnYnkYcx0E4AdyxcfPw7Wvq+B7sxkVj8nWMFexmLav2l7mRo+S+CTALyzvA26ZnJs+xUbNlyTc1vcUoII+QbQ03PkDpOTrbubGp9OwGedtyAGsuZk7nA31ZciCEUQ02XznQnjaHKCKHmPnLUE0ZFIzgOTeCzdqXRR8uMm4/R374YHg6iIRF2hr6MInc7A1wBsZWtvjJmXZDPpkodae3+1IAh7ex3dSzphmrc75mUwY0U20/9D2QeoCKIxBDETNj81Rn8EFEH4Y/RWlKiZimnevKPers1puYuAmGMiP4HBJ4+MpP9fJRPsTKQWM0PcSKZIwu/0XmuCEOOWjQMetxJFEIogKlnvs7WOIojpKfmaEUSZuSEAAh6YaOPkhp+nX61i+tSRSJ4NpkvsJrFEdNzwYN9qWbv1IAjLAiGC2wCab+vzOdbogOy6vt87x6EIQhFEFWt+1lVVBDE9RV4TghCmrBGTfgFg76mHGOAJRLVDsgOr/1zt1Ds7j9rJ1FruJ+BfbG2lW6ObjhkYGNCd7deDICy1V7z3ZBCXqJTcbLUVQSiCqHbdz6b6iiCmp7RrQhAdXanTAFxhm6Knfr4SKCR9/JVMvXt4eM1fGkUQUic1puOymb5bmv0GsX/3kj2ibCyBiaUg+kBB5acz8LvN1mo3cm7OtaOjt7wmcAjjvOYsWyRcYSZNLbnzCgYC4k1rDMyPM+Fmc1JfWTQO8OurszPZwRrdC2C7gozeMJkPHc2kh8Ksw66uxe/RERkgYI9CvUkGDssO9f/cqx1r49O1+YD5WYA+AWDnQnlxsPkLMQ2aGl+7xy6cDfo+l0gs2lXn6CCAf7ba2qLqfKOzO5VgE98E0F4wrHgBwINMuDJMH37YzD0wuX3rBC0A43gGPmqbl2WdSMBGZu4zcvraID5MfgQh1oMWnUyC8DmAPjLlU0V4CczrifBj1vEzPwtHMa/2ruRcDfSAzZDmZRN80OhQeoPfvIPUD21F6eNI2t6+dOdIi9HL4F4QvR+Mt9vW0LMARgFKt0bNe6p1xHXOv2qCEAtlzjjuBqjT1vhjZi5y4OjoKrE4a/KLdfd+kEzu3+yFPcSM29qiWw8NDNwwLmu8XjcIKUG42DQ3yw0ihD/LiwB9bmSo72exROqcoJ7UMoIgTXsGJv/E3Uya72qNbpMU8vcjCNn6JMY3hzP954dZmLF477FEfPOWOjw82YbPuKlPLZVkFCvA9B/BHET5cdJw2vC69C+d1n3OccoIwsjlUpHWln8H40ybKtZeNRCh+WFifVsGfQOMkx3GI25VdWJcZegtFxQPEEG/WXFYyI3tcO+ctlfOAOGrAXCcWoNeGM4Ugti/J7lLi6F9n5kXB/Qlex3E34COK4IQpZ+sxd+rJoj2eLJLI+uEtk2xw0o+wCCDDVqmoQThEuaiGQhiipSBDwfEXliYfVYj2ouB/5qq43FCcm7wBJzBsDaffV36NOzvT34EIdoov33yaAQt84eGbn05yLx6ek5om9DfSAN0+NQaBy4cHur/uqx+rGfJXqQbqwESp/gwP+Hrc+nkmzuc52XGXUYQ4AGGliHwv7uQg9gvPQktyCA7OpL/hAj1ASJUTrgfC5WzRkfK3utES7JvlsDHcx7zVIjedAafmx1KX+pGEjOBIDo6ku9FhO7w+A48IOEBPYqlDw2knw+Bm7Ro1QQheZyu6Apf7UTs9etGEM4YQ4DrXGc6QXR2LtqTtejdkgVqAPw4oGUF5gzej4AP2U44L4MxDMJhlRAELJXB1BVaOERmAHqycJuIA/iT/XYahCA6O3s/zBqLN7Ki+XWo03SBKEX9XQtzclVJeOLGeJoJWQK9xuDtCOgCsHv52vf29SknCLwOQDiazrHaYvwZGv7X+m8TnwRhLwArRob6r6z0OxOx1OZs9eoVyPsn2X+W6g+k/QqAAbIcXuNg6z2yGGetUJ4HJttwpOzW5aKWEb5SRcxFG5ZKk0APu6y94rheZmjzs0OrR2XzrT9BnNA2kXtzBYjel+/f/BRQ/G/rH9YD9MjU2NhcP5JJX1f8f0t9N05pBg5yjP91gH8LaI8V5u+6hhi4Pje2w8leB40ga6FagqBYPHUjEY6zbQZ/hM49IyPpvwUZQD3K1IMgpKo0gutcZzJBiM2gdetXb2LmXrt8hFWarvHJ69eln7L/e8HE+T8pf/J3bArWPdU1WJ/M+i3fNo9yNLLEbuQg5Dpm4N2jg+mNxf6DEITsBsDA5dmh/jOCrL9y4wS+BwYWO6/xLh+2eI9ba0b4HCduApn2xNKPaKxfB9B+trEYDP5ydij9Pdn4JARRLDZGwL+/a1e+0vaeQV1di/c2DO2VSk3NReOxriU9BFMcGIrm5gYDl7RF+VsyvbcwXImadLVjkyu5/dnn5qO3d1VTWW9jpnk5gCNLsaJbW6MvLJcZsdSbIJwyc+4Ffo5yHfHkiSC62vYtjRHhjIk3d7hBsuFTR/eSj8E0b0TpTf81MvnQ4eH0SJA17lamKoKIx4/Y1qQ24Rj3yS1sWJuopdVMqh4EEYunTiGyHuJtG6D7IpzJBNEeTx6kkXW9nfI9Ica1bPLpHrpNmTlyXowhCcJSRwS0gAtCEGIInYneJczWG0JBfvzoZDR6wIaBVX/3Wmsu5s3S07iE7AwwX7D7bviO1wN04SH7BwAvs43lrzD4gJGR9B+d43MlCOavjGTSIopuSYSCar6lKSLuSl1GwOlbDoJ0xchgn/h/174Kh6q1APVsGcOW96OABCE2x2XDg/23uc1DSsweh7fpTBCyw0yQ259Qa0I37yNgnyJOYQ5BdSEI6UKtY2jnoAu9lgQhwn888yxOANH/OD26TeaFo5m0sIYo+81Ugujp6YlO6DuvBPgY20LzDCtSLCduHi1bvXJ1wfJoCyYhCYI89PtOoIMShMQUO5CayameYuDpKIyeoaHbnrSPRViaaC2GsGiyvdf4h4UptiFzNHXDwYUgnjI0PkBySwn62biW++jBy7Z525sTt9tvA0FDcXd0JQ8FrMOGpf5yw8/1BhGQ9Jz9AHiFTDp4eLjvIefEpjNBiHVELcY620Yf2MKq2rc22QKo6gYhMf3zPC1WvVIDNlAtQQgWf1Mfe3cUOJBhfklEYHR27afjm6kEIZGpq1pAJg6Jvj/sDSLUG1ZQghD3mFhX6jo7eQU5YZV/dPJbY/kNBa43ALdlHPSW40IQrn5BAT8b12JSE1QX8+6yzbhn0e6aHnkAIPE28QiDNraQedngYPrFADeIwKTXbvUTXefwxZLmSZnOBCGRbeDvIR8klQWRvwHgV5rA2+DLq7FoqoogJECHJojQNsP2VeVyMq2qzWBf00Yy9c/IfDCK1WcqQcTiySOIaE1RFeN24nODKX8D2elWAMmpMuFuEE+ZUb17dGDNM0FEEYIgIDlleppjS9aRG1nKyOf67FD/iWHUPRJylm4OMoJgwvnZwX7h/1CPX9lbo59VUthBuHyzgUnPhcQWZzN9Yi2X/KYzQUjV9qidVVJYuVRFEBLrjqYnCAZ+QwYfLdMN28GfqQTRGU9dzITztsxFrjP2WmixROpMYmx5YA1DECGj7oYhiLk9S98xR9d/AZBw7BK/SYAXjgylhZl22a9sI3HRa3d1HbOjgdw9drNWJpyVHewXppaBf/I3PTplJNMnHiynflKCqHNWQckNSYxnjIE7CLyyNbrNgJtfUhAApBt8CNJzqS/NuzCdCUJg1dmV+nohSKkduldAWK2ZtHJ8fPsN1VonBZGJKFMVQdTiDaKq035jbxCvgHExTL4yyJVthhJE2UlRPE4PZ/q/EHRBiXKxeO98IhbGC/kH4TAEAQQ+NVp9hUxvWkaA5P7YWt62vKxU1QrcB1CZl78XjgxuIeAQALsVy8l8iqpRQ4SRo72sRzDOYrG8CSqjjyO0do+dzSeCeoaLBsJs8LI5hKk/3Qmi4AMhzKrf7SKvMRAegUkruYXuyw6sFuus5oYJVROE5ERmBej7x9atRz16/01CD+b7m6YEIcIgPAvwMyI/tobInePj2/0mDGvPRIII85F5CVZy8g5u5hrSyCE0QZSH3pCqmSRmza6P2lJVq+/KD1hAgoeEIAI/ZAbsVVosHl+yn0mmeHCeIjCP9oRvxl1k0g0TE9v/0u/b8Qu14TfuMGt3uhNE4ZC1iIhvCOA9LopvAmENs3bDHrsaD4chZj9cq7pByE2ygpkP+g3M+XcpkYS5QYRUXYQdn7O8IghbrJswN4g6E4RkHUnVTOUxnNy9r2cLQYg1LvwOIoZ5KZHld1Du8yL/cITD44+jpF88OLhGOL+V/RRBlGPSnkjuS0zCsMKZQsFre3qFgO8auZbLvUKbBN3fqiII0Um5zhp1Oc3MeIJAuPAObgKUxIOqGd5hTmEz9QYhxl1mmSRRMzn1wF6mt7OJIIpyt4jCNM8gQPhuOBKEua6OZ0njZcPr0g8GOQAGNaUVbYVZuzPhBmHDh9oTyQ8S09kEHB3wRiGqP8YapdxCmzSMIGJdqQMJ+NmUm3++56rc+oOeMNx029WauQYFz6tcLJE6j8SbxZbfn6KkJ9xOUEH7LHsARu0IOcxHNpMJoswU1/H4LHl09vRKrXbDCSr7Yrm3SsXkMk6K9SzZk3J8CDReDsbHfIL4bYKmHTqybvWv7e2pG4T/KhA+WU+/oO1DBh/JhF5HiBtZA4+ZUX1+UItAWQNV3yDkDkLVBwYLcsKYzgThDM9AwN9h8kHDw+ktMVj810RZiZjToxWoCfEUOypTjYVU+Yh2ygI4TiMVU/60WWaKazDzomIa2/IAlPLQGkXMOjuTH4NGDzDwjsK/Gcy0IJvpu6cCEftWmWYEUTJe4SzZ1vbSPgZFlhGjtxAHqnROkhubIghfsZcVsFT85vgnwOYyMBa53OSqOqxXTRBi1BKzrElmPj6bSYvIjzX5zTQVk+RmVbIJVQKKy4P+/2o8viCT+al4FKz6V3bzqeDtpiw09jQjCGvNOkJvCMfHot+ChIQ9PzKJ9yv84u1UI6jpTBCOeVFHInUwGCJO0JQaSvhQcC7SbU8H0EiCCBN8USanMis9n1t82FhMlawNt4gPYY2GnH3XhCDi8cUfMilyv8O6wdeZLAwQM40g5F7m/vFrvDCReSkH8QYOg7Nk8bumVXVpt8xpLJSZa8gbS1grpuKYy0JvFNRMk63RCYevhO/8XYw1pAH9vGRRIBoRT2dHAv5gAr/XTL7eeetsNEFYGyqbh4OpA8BcBobbopuWyQLhSTfURPIEYrre9reyd7NGEoQEP9ewHPL5OPx8akgQsa4l7cTGZ4iog4F9CwcXkVMkyE98e5cQcK6tcFUahpoQhLB074gnzwVZeaOnfjXKSW21N9MIwiXo1rMaGwdnMrf9Loi0naexWFdKREy9wPbvVd9KnOPo6Ei+C1EaAOO9xb+FOQ3L0s9OR4Kw1myi93IwryjM0zJjZeZxR36TQH4ZkoyHr2msHZ7JrBaZ3wL9OhOp45ghTBuL1kFS09qGE4TDux4egfBkEw3yRvMWEwSYSep17ZyPy3ftaSgS5gZRduAJeYOXGLFMC4KAWwxzQRK5KB9fTfIK1+xc09jMVSwsmfdppaTZkUjOA5NwPrNbjNQ8c59k4xRTCRpXSJxgnCQWzlGuQTcIMSln6A3hlCb+3eZJHjgOlewWHUbWhVhC4s3CnpzpV8Zk7mBnys5GE4Q8PhdOGB7st2XYc+dAZ/gWAGXhVBpJEDLPd3g4TNpnFo8vSZhk3mVLYSv+XDOCkCRgC3XQkEQUrkoFXasbhIXhvK7efTTwnfaQswVwRWCuf4fBq4J4IRcFkl804qGLLgTwrrIlON0JovOonUyt5X4C/qV07PywSVhuz2vg9nkVdIsCAxFqfMfS2wNWZDP9Pwx0PA1RSK4y9I0HQ7F4MkVkqRKmwoRb3U7DNwgxLKejpxVGhdkE0ccL4w6T20To278Hxr+WQk03tUbNL3rlChYHINLociZ8Poh8G00Qsgi/eecsXjAymF7vtbTkIb/LveUbSRCywI1B5uOR5S0UQXhl3HRJ4RxIXS8L+V1tds+aEoR1Kute8nGPfMIinsgNmmlcOz7+9idk3pU9PUfuMKG3xBi0nICFbiZzDGRN0PL1Q31PlF8DBbHQHSB8eupvIa9qIfZTz6KF09NqyTx0JtxPzP8zGY0+vGFg1UtFd3nxsUxOansx8QIQHy+LJhvmdFrBXFxyO8jzJovxjuv0bwX1VzQokYtylb4hFPuotr5L3Jt88wFPlcWxuNwChFgfZkRWZIdWi820JCSCmzOUl3wbTRBifi4n5xeZ6czc+Pb9sm9ZzE1jrHQkQxqThclvMEFAcqsRAn+SNPMLzrzgVhj7tldTRCxia71T8j15EoTE6GEjDF7oFs9NomoUy+Zxk3H6u3fDgxJPaersTn6KTe1Hjjzu1ai0C2ekCnYPvyqFnLw3ApTwKfsCQIWQHCw2FuHCX77BlDbim5h7OvhB2IZMsa7kmQQSiVz85uYHbeHvPGpGjaOrsW/268gjxaSo+gwDQyJ1Jog/4mv7Pk1vEGIi5R7TU8h4BvJzw89FFVggHCud6jqAXrRSc25JB+pojp6EZh45si79W1k/bwVB5FWPshuSNcKSVJgAi020E8DO5eOX58hoNEF4hvgppmxlmtgciHBvznsyb1uciyBvEMaYcUTh37xvEPHek0HsvOkXwvmQyJa3bk7LVqcWgx1aKnUNq0AkDsilP8JLxPjV5gO0ldXRGh/hE7Y0vcXyIv3rV0YG0/9dTZymmt8giqOzVCPPkUg2fpkL6/rtUc6/vw6mH5p69CI/F/JpRhCWHAvql6scaqKwGAid+E9YN79YTfrIoJ1aOOqaM9OZX/XXCbiKARHgL68Sm8YE4b5RVB4yxucW7YOfIAc62ulIZq/0FhFE3lAk/HqY2rAYuLEtyqfL1G2NJggxqMrklFe1Rg36LzCWByEIFytPm0jLoyzs35PcJapjVWk2Pr9Pb+rvuvD8nxjb4Vt+MbD8WqwbQRQ7ttQPBo4mFqZX5Yl3/AYorlZM+FZbBD/x0uPa25mGBGENr/Bhn7/50fdzPt6mMlgeI43PcF5//fGrrkQ4oufHydSONzTT1DA9YzHJ0JBYIImgkxcOD/V/vVL02tuP3Y5act+gPFGWvsnIG3XNu+ws/lYRhBhHYT2csvk2fBGAHQLiI/LTn7P7rtzvFkjurSAIMfYQsaVEtNoftEX5fLEPOSyT/MLdUCyRXE5MP5CtBbecK+ImwRH6WiHVa5A1JKZU032i7gRhX0CW13VUP5yJDgTwCQJ2LYktQuIKzs8DWpaIB4zJyAN2Z5qAi1FuEvsWvUHIxixM5cb1N7s00HwGi3zeuzuu49b1M28Lz/ciGllTz5C+QXC13kUMOpKZTwXR+6eutHmZrWfQVbmxHe4VJ5bpHM1VNleJ41RNEr6LvizrvglaAMbxwq4dwC42M9YXNueh/hMYPzZy+lqntZKbXN5KgiiOSaggW1tf/RQIS5nMOEBiDRc3sTERCZlYyxgwr9PHdxz1O8m+VQRRmI8V70gDfQmMgwDsWVAHiyCDf2bQGkOjqx9at/rp4vxDEoRVLf8mQ8JMXbyN2tVvnlnjCje3+QCLJFztDlW8UO/9FdB+Ds28bvedsXHaRHMNsrGoMgoBhYBCQCEwMxFo6A1iZkKkRq0QUAgoBGYnAoogZqfc1awVAgoBhYAvAoogfCFSBRQCCgGFwOxEQBHE7JS7mrVCQCGgEPBFQBGEL0SqgEJAIaAQmJ0IKIKYnXJXs1YIKAQUAr4IKILwhUgVUAgoBBQCsxMBRRCzU+5q1goBhYBCwBcBRRC+EKkCCgGFgEJgdiKgCGJ2yl3NWiGgEFAI+CKgCMIXIlVAIaAQUAjMTgQUQcxOuatZKwQUAgoBXwQUQfhCpAooBBQCCoHZiYAiiNkpdzVrhYBCQCHgi4AiCF+IVAGFgEJAITA7EVAEMTvlrmatEFAIKAR8EVAE4QuRKqAQUAgoBGYnAoogZqfc1awVAgoBhYAvAoogfCFSBRQCCgGFwOxEQBHE7JS7mrVCQCGgEPBFYFoSRCyR+jIxvjU1esLKkcH+E3xnowrMCgTau5JzNdADAHYsTPhlE3zQ6FB6Q7MC0NOTfNtEju4A4dPFOTJwRHao/85mnbOalxwByfr/U5T0xODgmudqjZkiiFojqtqrOwKKIPIQK4Ko+1Kblh0oglA3iGm5MKfLoBRBKIKYLmvxrRiHIghFEG/FupsxfSqCUAQxYxZrHQaqCEIRRB2WVfM0qQhCEUTzrObwM1EEoQgi/KqZRTUUQSiCmEXLvWyqiiAUQczm9e87d0UQiiB8F0kTF1AEoQiiiZd39VNTBKEIovpVNHNbUAShCGLmrt4GjFwRhCKIBiyzadtFUxLE/t1L9oiysQQmloLoAwC2AqAz8DuAb+TcnGtHR295TUilWke5uXNPamltffVTrLFwrusGsAuASEHiLxDwKAg3TrTynRt+nn7VbSX09PREJ/SdbgWQLJZh4PLsUP8Zfqtnbs/Sd8zR9V8A9FFb3euzQ/0n5k3Y3X+SuiWOYLGu1AICfjrVLuHc7GD/t8X/J5PJyNPPU4wYpznmPgbgzwxaY2h09UPrVj/tN4da/12sgYhpJAlYDKL3g/H2Qh+vA3gCzD/TI5Fr/cZWLUHUan0EwWfevKPeHmmJHklEvQyItbBzoZ4lD4DuN8m8ZnQw/XuvdVGpo1ysu/eDMHktAfvYxjvGzJ/NZtL9bn3OPTC5fesELQDjeMe4DQDPE7CRmfuMnL52/frbXwqCRY3KUKxnyZ7QjUUa6FAG9nV83xWNT4JvifOZkKM2J7qcQMcgj+W2xf0E4F8x6Krc2A73bthwTa6SeVr969p8wPwsiObZvo1nQLhLM/n7mUz6D6LtpiKI9vZjt4tEcxcx4VQAUQ/wXgTocyNDfT+LJVLnVOJJ3dGR3AoaTgTRVwG8M4Cgxhj4Eeda/qNITs46HfHek0H8wy3/zqMRtMwfGrr1Za/2JUIU32KwuvFkl0Z0L4BtCmfF4ck2fKZIZm4EMa+rdx8NvJKAmM/cDSL6CevmF0dG0v8vAE5VFRHE0ML8HWZe7LMGRD86QP0wzC+5ja1SgqjH+nADRqx7asl9g4AvFA5DXhgaAA9yNPLZ7MDqP8sKVkIQnZ2L9mQtejfym2jx50kOVj8GfQOMkwOM25IXMa4y9JYL3L6hqhbPlsrU2Z1KsMnfBWi/EG0GGp8bQbz55jv+PqftlTNAEHtKkRTcup/aw/wOgcUGxIHumecotTkqwGU+e5YOpkthml8zI9jXEUlgZnpSi9MLmSxOKR8OKFBr8WpEezHwX1N1AoTa2L8nuUuLTjcycFDAvuzFHmONUtl1feIUV/KreDMqIxaAgL/D5IOGh9OPeI3ReYMixjeHM/3nF+vICEID/46ZbrKFn/CFgYHfaKa+cHh4zV98C1dWgDq6eo8G+LoAH1dJDyxuFBodWSuZ1Gt9yGDp7Ex2sEY/AbBbSNg2MXBsdqj/5856YQnClRyIv5gdTK+UbWAdHcl/QoT6ABwYctziSuwqr7BtOcuLG9+crV/5Jhhn2jQBoZr1W+sygoBhHI5I5EIAYgMP+tMZfG52KH2pH0mIPsd1upyA44POixjXGuCVGpHQIBRDzcw8gnBZoAJkcVp6HNCy4n8YvB8BH7KdLF8GYxiEw4IShEdfYld+CYx1AL3I4O0I6AKwu0Taz2qsLcxkVj9s/5u4as8Zx92bVQGdxX9npuOymb5bPFYMxeKpG4lwnLOMX13JQp1k4DD7puEkCCL8lNm6Nexk6+8ZBoYI9BrA7wSh23Zt3QIt49o5LZtOHRgY0IN+AUHLdSZSi5khSEuoE+0/S7VIIIG1AeKPgPExSbnHzKg+f3RgzTP2ymFJu57rw4lFRyI5D0wiPpJdFvl1T3gKQAZMEwTem/M3PeepdBM07dCRdat/bW87DEEIMozqWAVQj62NMfYgB2sT3urVKwA+yTGnMTA/DtJ+VZBVK4A4GHuXb2o8MNmGI73UtkHXjq0cdSSSZ4NhmZgIAAAgAElEQVTpkrL+rG+b/wBoj1nliVvB3A7Qe2U3VbG5uq11Cb5/A/hRgObbMQThETD9VoxFsncVi/rGBvPAW7QhDgoPim9Xtk4K37tQne9Q6HBmEYSl49361ZuYude+IAh4QNf45PXr0uJDmfrl9Xst/0mwrrXFt4ItBTxuEHndnXVaO8Sx+B5jwinZwf5hJ5O3J5L7EtN1ElWMdEPqjKcuZsJ5UwQBeL4lyN4fbHU93zAKt65fANg1X4cfnYxGD9gwsOrvxTacBGGfNwNZpsjJo4OrxCKeeusoXGWXb15U33dsSpvIpAOGh/vyH1mNfh3dSz4O0xRqMvtGaV339VzuQqfeurPzqJ0QmXM5Mx9dsgYI3x8Z7D/LPpcwBNGI9VGErL1n0e6aHr3HcWM2mLHWjPA5znVfUOd8DYx/LdnQmO8Qb3UjI2nxTmH9ghKE9XYwTmnHTVq0c87IUP8P3E61sa4lPQRTqKOKZG4wcElblL81MJD+h3NZzOtO7h016WpHP0J1edzwYN/qGi0jmb5dMMGTJpunvHs3PJhOp8WbQ8lPqPe0Fv0rAJ/tIArXtS7D19bo6wRcPCfKVzqxsNSnpnldmeaC6IqRwb7T3fDuTKSOY8YNjv3uWYBP3H1XPGCfV34/faWXGZe7aAhmFkG0x5MHaUR32E+Egr3Z5NPti94hV6+Tgms011g8dQoRrnAA3T/Zxid5nWRcr62SDSnWlTqQgJ8BmOO2advn0l72hlCyhXu+Q8TivccS8c1TNSQLzY0gAmAM2amebY/ctfiw84/7O68EWDzoFX/+D6PyU2zZRx2GIBqxPooT7OxKfZ2Br9nmbID5gt13w3dkG1mhnGzdTwK8cGQoLQg2MEFUSg6ig1hX6jICxIaW//lscKJI4Xa9tvSmwne1RrdJDgzcMF6DtUQdid7LwbzC1tZfYfABIyPpP/q0T7FEcjkxXWvfG9xu8B4EIW50R42sWy0OmtKfFHfCH6Fzz8hI+m/OSuIwZGot9xPwL7a/bYTBC73m5XE7nTkEIdscxKnWnMwd7mftIDbtlq1euZqAz5aA6nKDkKp/AvZlLXD5TedZjY2DM5nbflccQ0dH8l2I0gAY4uoqfm+YzIeOZtJDshUTS6TOJMb3Cn/bBLB4vBJqNPF7jjU6QKZbF59lrCslbjbF+RvMvCibSU9ZLBU+5hIrJvFveR1r7uDh4ds3eX041kNtBLfZr87MuDmb6Rd6UE/rqqAffGdn74dZY3EL2nJ7YP7KSCYtQrh79mFZu5nmfQA+OLVXARcOD/V/vfj/QQmiUetDjKu9fenOWosh3g6m3tsYuD43tsPJfpYt8s2Jbm2NvrC8qPrzu0EUrGB+APAym5x8bw6i7EcPXrbN296cuN1+Cg4aKbajK3koYB0GrcMTA09HYfQMDd32ZND14rrxSiwBAawYGeq/MkjbXV3H7Gggdw9A7cXyTDg/O9j/TWd9F4IQt78V2Uy/zUhF3rMTBwCvkEkHDw/3PVRGEIneJczWIbCoLXlNY+3wTGb1oN+8YvFkLxHduOWwatWYOQTR1bX4PToiAwTsUZhsqGundHNxIYjykz3KTl5+gMv6c56oZeauYDplJNN3dflCc5jGMh7cvH/cA8J3phYp0+Jspm+Ns65kk3nK0PgAp2pCdoMIcwtwqszAeLC1hRfKVAl++LkQZGk+D+D3uqYd4me+WmzLeRIXqsl/bN161KP33/SGtRkHzAfRqPVhkXY8eQQRCZkWP3pfPbQdu07HpiEefTkX6R4dXfWCKOdFEC767FCPpWW5Jvzf2azh59VqkQcAEm8TjzBoYwuZlw0Opl+sZO3Y64hHc4rQFxn4BICPgWBE2DgkDPl0JFI3gCFUq/mfy14iJQiPW4BzbpJ9TxqOXbqXoPQw4IWb7IA3owjC+aGEPVFIAXQRatlGF9CM1C4AucDKr8llqh8g3RrddIzzcdd52xB+E8yctputuvlSSDY0aR8SgvC80TgXXNlcakgQPT0ntE3ob6QBOnzLR+mtjy0jyniyi4huJUDchh4mogHWzTuK6smgBNHQ9eFU0YDvgYHFHirVkmmLDcaAJtSYBogeJiDDOt9WNPV1Iwhhey95XA5MDsVt02lUUU+rpGqJI0z9qgjC5RuX9S+9rUgSOkm0EfAzXPH9fmfSDULyUYbWSTpUNFLWd7kWB3JicwJe7utQfmUrezx2OV043h8sFRG3GL/S9Og6wLL8EPdw6Ym9/GQvv6VICOIpM6p3O6193D6ksvo1JAhxC6IWY53dMYtdbkxhPnR72SAE0cj1Ie3LRZVR6ZxlBEGEo8H4CAMXlLzBMb46kum/yE+d53WDKfxN+AndsdmSZmVrdJuBGr0rVApBRfWqIQg3dZRsIH4qwGIdyfukl8pZOufOzuTHoNEDDLyjUGDGqJjKzDvFw+lwpl84CwX+xeK984lYmArmr+uSG4TUUshF7ePXsURoZeqBIOanoh+HD4Ml/Dfb5vzVoeMtWxSS9l0XTpkfhEMd4TffuhJEufrHVRfrN063vwchiEauj0Ri0a46R4X++J+LY641KbroyNeLpzSn5V/QNz87vgVLwrs8nCzzpsmMPo7Q2j12Np/weHivVLS1qEfx+JJdWTM/zYxjAXyyxHw6hIqJCWdlB/uFP4PvLyhBxOK9i4j4tql1EvLbFfUkh7CZQRBSkCqwkCnbACRClX6UFeboDbLhCMGUmbs65lamXrGdzB11yx6fy24oHqf6ajf4aut7fS2dnb37s8b3F220gzoH+n6BtgJB5NXI9VEwb91yQwQMZlqQzfQJk9ea/HzMMMv7CGgUYK8Yjy/ZzyRTPDgHcfAT4VHuIpNumJjY/pd+D/E1AcHWiMDjTV3bLUK8L8DvY6ZPbLY03B/Anp7e+mEIIsR+EpggnHHmKri9u3l9T/uc1E1EENIHJom5a4n6TPb+UIzb5LwVlXlHO8xbvR6dq93gq63v9bFL1F81P91MA4IoWR9BxlPtBulDEMIXYALA1rZ+XmZo87NDq0fD9G3FyzLMS4lwZFDvXgDCWurHUdIvrscmVRg/tSeSHySms4lwhMzpM9A8FUEEgqlYiEKV9incRAQhffR1qi2cD/AOAim5JTitHOyWOZKHcm8zWkewvrBWSIogwq16CQGUyOctJgjhoX0pSLsVpnmX4/R/X2uUj67EOi0fWNE8gwBhNuv0CncD8FnSeNnwurSw3KvZr0LSEv0LIwexx22Jy6YIIpRcFEGEMJv081OIJVLnEePiggRK3hCcD5l2cim3bPAO6lftBl9tfa8V5nzPmQ0qJplpd4NUTBY5TL65w3lCxVMWBdlSdQWz4/eQqRU9lXJ8CDRe7hISxV5dGiok1K5kK5z3yOefbI74/B6fNl7Y7APyJwINmUwDuRbtIRF9oKpHaqVisti1pr+gAgmzydT7kdqpOvLa1JwmokVVkdf7Q3Gu5e8QeT21s3+/kOLVbvDV1veUXRM+Uvutj7fskZpx6eT4DucW9f8uD81ljp/VfPDC56Kt7aV9DIosI0YvCHuVtRfACzvIGOSe2lbNvzFwM6Ddm4vSYxsGVolw41IHzKD7UdA3BLdxB61fCxWsxKS25mrcuqiYRKOOU7SrSafXAikPN4GyUBsye/tKLKYKY7Z7PluRKe1OSvaxuj0m67q5k91BULbJu71DOIjD19mv2g2+2vqeBJGPR2R/sBV23lLHQK+PbVKnNQy8n4A/mMDvozAuKzpIBVHpNHJ9xONHbGtSm7C6ExYz1i+MiWSxTqwr9WMCDgb4Lwx6BNBuLL4hBN2ApGFuiPom3tx+WR0ekqkjkToYDOHZO6WG8vp+ghDD1IGq3ONY3Jh+BJ3PCupfMt0IwmnEASCUQ6XARnJjnUEE4TRR9Q4tIVsvznATrt6PjXSEKg5U4sloqZJg8rts8ZqkITLKBct3mbno57UWfc1UtNgA3pvVbvDV1vf6yGvhfyD5ACrS+TdyfXTGUz9iwue3YBMuJpHU0crmzRyUIMR71qS+8+UMFvlXir9JZj4+m0mLUN5lP+vQw+bhYOoQZrMMDLdFNy0LGuE3lkieQEzX2xoOvek5B+WSrCtQyJ5iWzLiDuNJHTTciOgvqHxkfkJuURncvjOJ1/7MIQipp2AIU1cRJTJikojjk3cqE78QoTaYaaksjIUb2LLEPn5hK5y6XuEJqYH3tUV8lfowSDbPp0A4C4wfb4nS6O92X+0GX219v1OgJGjdY2YucmAxbIRv/bKTY2lE2yA3CNGHLNRGvdaHM1SGeCANEyW3kENCBOfbroBPyRoKugFZ8+5Zshd0874SZ0WRryGqHSJLSFS24QQ4pNhlGFQefnK3/93FMzmUI2yYsD1h8JXNI0T98gNwCFNXl0CYM4cgxHZeVQTGrpQI+y08Q7f8Ghusz/fDdj7EMrCaGNtO5bDwELhTnUSEe5lxRHGyQdzuq93gq63v96FLNjsgoF2+PCZOaaiOoBtSnYL1SdeH7GATPFhfT3Qyt9NVjhtISaiOEBuQJR5ZOGkCXTUn+sLpzpuBPH4aThge7N8SVdhD6JITbSjPflnTMkfHMCpkt5QDb/UNQsxVEtjPIAqGdzy+JGGSZa1WPEiIJmcUQSAeX/whkyLCWcrmcMMDehRLHxpIP++y1igWT6aIrKtqaYIZj3wQsnDOTLg718rHVBLu2+0jso9ZsniFOZ1ID2qlCPV6ZC7zEi8FI5DbfbUbfLX1/QjCLdw3EZYND/ZPeZE627FyVjyLc0AkwkS4Br0LShDWaVoSDr5e60Ma7pv4KyOD6f/2CHshW/eTzptOWIIopFddBaKFNpxFyPUlzujALvLaBOIFI4Np4a3t+nN5SJbGEPNbN/a/u6gqXW9B9rrW3KP0PbCV7rUkv4xb5OKw+DrnEqa+i2xcswkW++roSL4XEStyrj2F7MwjiPwtQpYFih8nDacNr0v/0v7BCHDHdfq3ws2hPG91RQmD5H0JNOPx5PsNoqsI+JRD0BvJ1D8TIAVn+TVxS0PS94fin2VRH7dUDaa3rnaDr7Z+kA9dfkiAyE72n60tuMJpmy8scCKtLd8FW1n4tnzUdUsYVPv14RLnXyTeudqczH3VGe7edd1XkTDILptY15J2gim8uYupKV3DwrucTF9kpjNz49v3yx64ReItjbHSkSN6zGReOJpJPxBknXiVkRCu2DYeNgnLRwfTG511CzleDgPzJQB9QNq2y+0+zAYvazdsfZfcDq+D+BvQcYX9ET6f7EukUiaRulfm5T6zbhACQJ+UelvSYbqnm9wiB5+c1DVKKRnoxFQclORaXfyT5y1AdjIqVvR7+5jqexo7ytk/Ho+Uo2NBUjcKZ8KJNk46b4JhbhBiPI1cHx5JXYKmWZUeUsJuQAU5iINMmcqWgYuyQ/1fddxqhEWSOHWL7HbO3+sA/3YqtadIYQuIFLw7lxelaybHtl9RC4upwolZvEe+29GPAcbTTMjmU+oiAjY/AbJIwa59EB7mTxRiZBWSfeF/NR5fkMn8VIQKmfpViG9V9T2+D5HBLsugp7zSBduGP/MIQgzeAl3XnElM/A4WApyrGNb1MH/y8SEIUaQQl/5WgBJ+HZT/nR+HFjnGmQfYqx3Xm0CAB6dy6xqrp8CWH9XeAKqtHwbfzkTyMGYSeamnTrHB6rurJMMSRKPXRwjnrhIovEJsV7qBudxqpAlqKvxei3MQN6Ub26J8eiWe225rohDcTqTmdObu9ltGrzPR+SIHuMZ8ny3yqfR9pFJ8i4OosH4x651IBevM2+42P/FesZqZ956yfJxpbxD2mRVyIac2bxCXlbi8S6fPj5OpHW9opqmBxBU1MEGI5vK6PToNBLEwigm9vRaSIKNvz4ny98MuamneA5/3h+JA5O8Q3t7T9klUu8FXW9/vy3T+PWSoBOk1295mJQTR6PUh8iJHormLmCDMTcvVpqUgWbm6Db3lgtHRW8SJuOxX4QZktVO47Yo80bZNiAcm23Ck83ZW+F5P2Txm8Q4U5BsSXYi0mufsviv31yPCa0ci+UkwfuiqNnJgycBNhqZ9TSSokrwXSlXA1eAruq+mvlDVEZPIJBnz+bYs0su1mjfOGaM1IHy6UH5m3iDskxUAThp0JDOfCqL3TwXbIrwE5vUMukokPxFX0yDRXL2ALJyE5gOcLFyFdynotcWVUzySD29OAZpujZr3hCWGko3aGZnRCm1QniLUOVbZ7cMZvM9rftVu8NXWD0sQxfJWOlHD+DyIDgOwj+1UaKkwCNSnT+Zu8UtNWylBlJz2dK3u60P0J95WonNajmVwb8m6FwHumB/frI29U49ErvXLtlfNBuSSytdg8JezQ+liatwSsVpWQK2vfgqEpUxmHKDdbQQzBvAzxFrGgHmdPr7jaC1USl7rqjCHQwuxoYR6q/hNi2ovEPAoM/cZOX2tY/2UWVWSxHGwGnyrJQhRXxDz089TjBinAei2zc9aJ0y42ZzUV4q5ScY68wmi0k1F1VMIKAQUAgqBtwaBmsdiemumoXpVCCgEFAIKgVojoAii1oiq9hQCCgGFQJMgoAiiSQSppqEQUAgoBGqNgCKIWiOq2lMIKAQUAk2CgCKIJhGkmoZCQCGgEKg1Aoogao2oak8hoBBQCDQJAoogmkSQahoKAYWAQqDWCCiCqDWiqj2FgEJAIdAkCCiCaBJBqmkoBBQCCoFaI6AIotaIqvYUAgoBhUCTIKAIokkEqaahEFAIKARqjYAiiFojqtpTCCgEFAJNgoAiiCYRpJqGQkAhoBCoNQKKIGqNqGpPIaAQUAg0CQKKIJpEkGoaCgGFgEKg1ggogqg1oqo9hYBCQCHQJAgogmgSQappKAQUAgqBWiOgCKLWiKr2FAIKAYVAkyCgCKJJBKmmoRBQCCgEao2AIohaI6raUwgoBBQCTYKAIogmEaSahkJAIaAQqDUCiiBqjahqTyGgEFAINAkCiiCaRJBqGgoBhYBCoNYIKIKoNaKqPYWAQkAh0CQIKIJoEkE26zQ6EqkbwFhenB8Tzs0O9n+7Gea7f/eSPaIGf4aIFzOwL4BdAEQKc9MBPEvAH5j4ASbtrj12Np9Ip9NGmLknEot21Tk6COCfnfUYeDoKo2do6LYnw7TpVrYj3nsyiH9Y9nfGg60tvHBgIP0P5996epJvm8jRHSB8eupvhJUjg/0nVDumWCL1ZWJ8y9bOyyb4oNGh9IZq254t9RVBzBZJz9B5NiFBUGd3KsEmfxeg/UKK5W8AvgqDV42MpMeC1PUiCFGfmY7LZvpuCdKWV5menhPaJvQ30gAdrgiiWjSnT31FENNHFmokEgSaiSA6OpL/RFHtB8x8tO2mUIncHzMpcuzo4KpH/Sr7EQSAdGt00zEDAwPixlLxL9bd+0Ey+RcAdlUEUTGM066iIohpJxI1IDsCzUIQ+/ckd4nqWAVQT40kvAmadtTIutXDXu35EUSt1Eyu6iXrmqJUTDWSecObUQTRcMhVh2EQaAaCmDv3pJY5W716BcAnOeauM+F+MH5IBv9qcnLHTRs2XJMTZZLJZOT5542dchzdD4RTiHEwgKi9PgNPIKodkh1Y/Wc3TP0IAoBBRMcND/atDiMXe1lP9ZIiiEphnRb1FEFMCzGoQbgh0AwE0R5PHqQR3QFgq+I8xebOFEkGUROJOrGeJXuRbqwGqN2OFTGundOy6VQ3FZGUIAgvgfH2Le3Qra3RF5ZXqmbq7Oz9MGuWemmnQpuTAOZMta9uEDP2A1cEMWNFNzsGPtMJoqenJzqh77wS4GNsEvsrDD5gZCT9xzBSTCSS79QZdzpIYhOZdMDwcN9jsrZkBEGEW5gtq6Hie8FThsYHrF+XfirMeIplO7pSpwG4ovD/LwMYAHCUIohK0JxedRRBTC95qNE4EJjpBNHevnRnajHWEbCPbWorRob6r6xE2NLbiIfpr4wgGPg6gfezWRxVrGbq6EhuhQhuA2i+NR/Gg0w0QuDzFUFUIuHpVUcRxPSShxpNsxFEV3KuBnoAwI6Fqb1hMh86mkkPVSLsuQcmt58zjrsB6izWZ8bN2Uz/8db27PhJCYJwLpn0aqnPQmVqJol6aQUTtinxP1AqpkpEPS3qKIKoUAziQ22doAVgHM/ARwHsXGhKODI9T8BGZu4zcvra9etvf6nCbmA5EunafMD8LECfsPUjzBL/QkyDpsbX7rELZ4M6UZVtGo4PWDhwRUw+mcCLAOxV0J1b8wKwjglXhunPMXea19X7Pg38OQIvBOi9hcfXMRAegclXwMTtRTv/Sm8QjZKPn1zbywniFTLp4OHhvof86rr9PdaVuoyAL+TlQUyMdXNatjp1YOCG8aAEAaI7HWapFamZHOolS91lRvgziiAqle70qqcIIqQ8rA3boG+AcbL90dGjGZ0YVxl6ywWjo7e8FrQ76+oexQow/QeAbf3r8eOk4bThdelfyk6S9vpuBCHKjOt0MQFfdFrMlPfPj5OpHR9mo7OIxzAvJcKR3n4AW9oOSxCNko+/PPIlOjuTH4NGDzDwDludilVMQfstlnO7QbRFtr7c4dhmMPOibCb906B9lKmXwPfAwGKO0pcUQQRFcXqXUwQRQj7C0QkR6gNwYIhqVlHLJFGjI7Pr+n7vV9fNYsWvnjBZBOHSyTd3OK9oLimrIyMImMZpiGg3OK1kfPp8nZlOyGb61viNrbM7+Wk26SYAu/mVLfzdsvMHmycFDbXRKPkEHL9VrKvrmB0N5O5x4LqRTP0zw8Nr/hKmrUrKuhGECFfi9F1g4PrsUP+JfgeM4jhk6iXxtlIW4kKpmCoR3bSoowgioBg8bNnHwPw4SPtVfoPmVgBxMPYuPyXzwGQbjtzw8/Srbt12di7ak7Xo3cjH5rH/DDCeZkKWQK8xeDsCugDsXt4WXTM5tv0KN5JwbhoM/IaACQDzbG29TkCWQU95zwm/1zXtkIfWrX7abU4dieQ8MN1pM4MsFtUB3gBov5H1IUiV8iaZHcUKbrGYGiWfgMulpFhnV+rrDHyttC4/bjJOf/dueDCoarCSvr0Iosz7mfBH6NwzMpIWIT18fzL1krCmUgThC92MKaAIIqCoYl1Legim2LiLtuwGA5e0RflbsiBk87qTe0dNupqBg2xdeFqLWHrzcUo76zBjrRnhcyRmiNSeWPoRjfXrHHF9DAZ/OTuU/p5sej7OUy8y05m58e37nQTTnlj6UY0NEbfnw452XVUm8+Yd9XZtTstdBMTsOIBwszGR+zfn+4zALWKSGLdQQ5X93AiiEfIJuFTKiokbIXTzPoclU7Hc3xi4GRqtrCQYn9+YvAhC4uAWWM3kpl4Sb0eKIPykMnP+rggioKwKD4OnTxUnumJksE/8f5nlSLFMweJkbWl4Bb6rNbpNUvagKIk+aYD5gt13w3e8TpmFh+wfALzMNh1XW3sPgtgIgxd62edLbzgeKoRYPHUKkWUjX4xS6jsnj9sA3AnCeritq3wCLhVpsVi8dxER3+DznpR/qAffrpnm3ePjb3/CS1UYZDxeBCHqV6pmKlMvMZ0ykum7WrSpCCKIZGZGGUUQAeT00YOXbfO2Nydut5/sGTgiO9Qv1Caev46u5KGA5UVreZa6xb4R9vJai/Hz0tO5t6rI3rHspE7AhcND/V93DtCFIMZM5oWjmbQwyfSZU4ljlCj7lBnVu0cH1jxjrygzySSivok3t1/mt/HJyRVSgmiEfPwwCfL3Ct5hdAZ+pzF+Zkbo5kpuGH4EUamayaFeeo41OqD4vqYIIshqmBllFEEEkJMsZn3QMMntPYt21/TIAwCJt4lHGLSxhczLBgfTL9q77kz0LmHmm20n7dDetuVt8KOT0egBGwZW/d3el5QgPG4BToja48kujeheANsU/iaNsy8p9xqZfOjwcHokAOxwkqtFsBKnsEbIJ8h4g5Rpbz92O2rJfaNgpjoVeiNIXQCvMHBdC+nfHRxc81yQOn4EIVEzTQK8cGQoLeQr/ZXjXXorVgQRRDIzo4wiiGByolg8dSMRjisWD2OVFKALinWlriPgs7b2Q1mUiHpdXYvfoyMyQMAehXakTlnS8AuMbw5n+rd4v3oMWtKPlCDKVWY8GkHL/KGhW0U4Bt+fzALIRcVUb/n4jjVsAXHji7TMORpkfgmgD4QM/y1uFj9oi/L5svcvv8OAE8OySKw+6tMy3w6bekn0rQgi7GqYvuUVQQSUjeSEL2qOMXAHgVe2RrcZkL0rBGneZSM8KzvYf2mQ+sUy8fgR25rUJtRen5yq5/h4xb9LT5VMi4OYq7rULyOIfAyinW4VgUltpHd5dqj/jDBz6oynfsSEz0+14RJWop7yCTPeSsrm35DQRaz1MrEwoZZYppW3bFmfGXy015uR3w3C2tDLczk8ZuYiB46OrnpBNh8HAZSolxRBVLICpm8dRRABZeNijWOvbemLidHHEVobRl8sOZGLdu8DKJSdPINbCDjE7mtAkpuBZNMwmGlBNtN3TxA4JPXLCEJGVkwITXqxROpMYkxZY7k9UtdTPkEwqWUZQRjjOsWIsBgMkaHNizA8fSqCEEQYNZNEnVeWcEjdIGq5Gt7athRBhMA/Hl+yn0mmeHAO4uz1OoC7yKQbJia2/6XXo6wkHEOIUfkUleT3DbLBe7UapL5LkLhAD/v2vmNdqQUETHn3euWkrpd8aieMylqyDBjm6MeDSdy+3uVsRTi45cZ2OFm2xoIQhGgvqJrJuVZlb3GKICqT83SspQgipFSCh4soaVjkD/5xlPSLZY+LiiDchRCGIEQr9ZBPyCVSt+KF8CvnFMKv2JMHuT7+ByWIcjWT3MDBvvm7WeQpgqjbEmh4w4ogKoQ8H9DOPIMA4XtQTJTi19qzpPGy4XXpB+0FFUHUjiCKLdVSPn5CbfDfqSORPBtMl9gftmWqRDGuoAQhUzMxcFh2qF+YXlu/IOolUa5qgkaMbXYAABzvSURBVKhVnuxE6sslMaGAP0VJTwS1AGuwXKdld4ogqhcLxXqW7Ek5PgQaLwfjYz5B/ESMoUNH1q3+dbFrCUFIrYKqH2q+hSAqIq++gtR/K1RMLmOuWj6V4h6L984nMi8AtF0AFibBj2s8viCT+alQP1b8k/mXAHIHzKAEIQYjcZorMSoIol4KSxAAyizQvHJYhwHNaeAARRBh4LPKKoIIDZl3BeEF3Nb20j4GRZYRoxdkhcsu/TnMCCURP0M9GoedQpANvlqCkPomeCS2cesvFu89lsjyD7F+Xm8QQXCoRD5B2pWVkWy4T0dh9AwN3fZkpW0W65V59rv4sYQhCD81k+Nm4BoePMwNwiKUfPjyKS94Kx1rLtLtZkUVBDtpnuwQvj5B+pgNZRRB1FfK1JFIHQzGjXY1lPMDkGUdq3YjrHaDr0F9mW9CaN+OznjqYiacVyuCcFJ1EPlUukRiXakDCfiZLT9z4FhHfn3GEqnziHHxVLkaEISXmqmc8N0TDIUliLIHcqDqG3RHR/JdiNIAGCLfSP5w4ZFYyQ/v2fp3RRABJG+drNg8HEwiquhcBobbopuWBU3yHkskTyCm621dlXwA0tNOIbZ+MXFOgGGiQDQiKNyOBPzBBH6vmXz98HD6EXv9RtwgrJOhw0QVkD98us0t6C2k3vIJgr2sTCHw4C8AK7JvcZe6AyaWhpGrs22pj4nL5hfmBiH6cW7WxbcNh3rJM+hkWIKQeNyLoVSVM0PmhQ+JT1Clsp0t9RRBBJB0LJ48gohEzoN8wLmQYZGDvDE4YtuIXl7TWDs8k1k9GGCIVpHOROo4ZoiAcMXAeJPOh0ZRrlEEIZn3JDMtDeqQ19mZ7GDNCumx3dT+KlFTNUI+QWVgL5ffyHdeCfAxtn+fZObjs5m0yCtS0S8eX/whkyL3l5hbu2x+YQlComayvN910r9ge/D1zD4XliDm9ix9xxxd/wVAIjOj9RNOgJqZO3h4+PZNYUESasTWrV+9iZl7bXWrvpWEHUczlFcEEUCKEkc2gwgnDA/2T+nGvZop28Akwe1kHz0BD0y0cdIrf0Sx33zMp6hwdLOH4v6VMZk72BlSu1EEUR4S2vrws+Zk7nC/NKwuH7n0DaIR8gmwTKRF4vElCZPMu+wkB+BlZj4hm0kLr3fXaMCyBl1Cwrtu2GEJQnKbfYOZkgQ+G4RP58fknb86LEFYhxtpzozgwSrtWHUmUouZIZJT2WJd5bPdVXNzq3QNzOR6iiACSM/lJLgJxAtGBtPrvZpwiUpa5n0qvrqOROp7YPxraXt0U2vU/KJXzB2xEZNGl9tDUojkRcxYkc30/9A5vkYRhOi3PZ48SCMrmq3tY/WeUzKZjDzzLM4B0UXOGEXyYH3Sk3qt5RNgpZQXEWtnUt/5cgaf6virTqAfRSj3jaBml+2J5L4aY6Uj94dgmIuyQ/1flZFNWIIQY5S8CdwurFwB7CjWFREdNzzYt9oNkEoIQnorynewVte0070SUhXHYX0HETq9kJzJHggxcKTiioTcxJUUQQQUrstJ0DW5jrU5yj9o18XqcgsQ3/3DjMiK7NBqQUYlJ07RBzGJQH/2hDzCPM319tFIgnDL7SBuEkx84uhgeqNdBFYQu9aW74KtwIhFVdlUEbfH+0bIJ+BSKSvW2XnUThxpuQuM/SVt6CB+kEA3kcnrxsd3fK7oES1O85OTr+3MFDkQhFM2h43/uBMTv1tmJQQhic20ZdgB1KuVEIToINaVPItA35bIXeTJ6Adp17Rq4xsHBta+UhxQT8+RO0wYLfsw0yKCtWbKPM2Bym4ilcq7meopggguTZcTvtXA6wD/FtAeyzfH7xS3ZgA7lzfvvVg90nOKtw+RfnMdQC9aKTpNfFJqRgt6Epp55Mi69G9l02skQYj+XdQi4k8ih/ZTADJg0hm8HwEfAmD3Ei6Zgod1V0PkE3y5lJYUiZZMLXoHAf9SaRvOenk9vb7QK7d1JQQhN5oorOwAeasrJQhLrbjVq5cx+KSQ0W29IO2fbOOTgqhpayWXZmpHEUQIabpkbgvagkhRemNblE/3C9Hc0b3k4zD5JwC/J2jjtiPek9DoaLsjnrONRhOE6H//nuQuUR2rSrPr+c7uWWLcENTMtVHy8R21SwGRC0Kbk7vc7XYUol2hPlxrtPCKhwbSz3vVq4QgRHsSNZNF6My8KJtJT8XGkvVdKUFYh4m5J7XM2frlfwXThT4Op35w6WC6FKb5NfXu4AeV+98VQYTEztKPP0enbD7lCv34DgGriyTw5+y+K/cHTVBfQWIZnRhXGXrLBaOjt7wWctMIZeFRKcEUYgmtKMQS2tYbOx7kaOR46OZHggbrE+01Sj4B5S4rZuURJxiXEONgr9uSpLI4ZDykaTh3eF2/sG7zfeCulCCkaqYA6iUx5moIojjneDz5fgN0MREWhsUIwhCC+CSn+rIKmc3aqoogKhS9dR1uffVTICxlMuMAiZDMxYexMYCfIdYyBszr9PEdR/1SbLoNw1LPTNACMI5nYF8Au9iu3y9szkP9JzB+bOT0tX6WQcU+Kt3ga1U/H5o7upxAwvxzH1ueZpF/4EEmXLnHLpwVZBo2WF9xjI2ST4XLx6omZNsyTt2FEO3iDUmsIbta0gDwPAEbmek2PUJ3B3mstY+pUoKQqZlE1NjsUP+JfsRUC4KYkuMWjA4DuAtEu4DxdtscRSBMcYt6BMw/M/XoXdV4YFcjz2asqwiiGaWq5qQQUAgoBGqAgCKIGoComlAIKAQUAs2IgCKIZpSqmpNCQCGgEKgBAoogagCiakIhoBBQCDQjAoogmlGqak4KAYWAQqAGCCiCqAGIqgmFgEJAIdCMCCiCaEapqjkpBBQCCoEaIKAIogYgqiYUAgoBhUAzIqAIohmlquakEFAIKARqgIAiiBqAqJpQCCgEFALNiIAiiGaUqpqTQkAhoBCoAQKKIGoAompCIaAQUAg0IwKKIJpRqmpOCgGFgEKgBggogqgBiKoJhYBCQCHQjAgogmhGqao5KQQUAgqBGiCgCKIGIKomFAIKAYVAMyKgCKIZparmpBBQCCgEaoCAIogagKiaUAgoBBQCzYiAIohmlKqak0JAIaAQqAECiiBqAKJqQiGgEFAINCMCiiCaUapqTgoBhYBCoAYIKIKoAYiqCYWAQkAh0IwIKIJoRqmqOSkEFAIKgRogoAiiBiCqJhQCCgGFQDMioAiiGaWq5qQQUAgoBGqAgCKIGoComlAIKAQUAs2IgCKIZpSqmpNCQCGgEKgBAoogagCiakIhoBBQCDQjAoogmlGqak4KAYWAQqAGCCiCqAGIqgmFgEJAIdCMCCiCaIBUY12pBQT8tNgVE87NDvZ/W/x/MpmM/O15HMqM00A0D4y3W+UIL4F5PYOuyo3tcO+GDdfknEPt6Um+bdKgI5n5VIA+AmBbAAaA5xm4n4n/e3Qw/XsAXME0aV5X7/s08OcIOALAXgC2so3tDwTq0ydzt6xff/tLFbSPuXNPaom2vdwegXYiEycA7AkguqUP/JkY9+lEK9cP9f1f2HnUu/3CnCnWs2RP6MYiDXQoA/sC2AVApPB3Sx4EbGTmPiOnr60UL7FWnn6OPkXA5wB02/p5HeDfEtFVcyK8dmAg/Q/Rt9e6CyKvefOOenukJXokCJ8D0fun1iYwBuDPAN1vknlNpWusQfIJMlVVxgUBRRANWBpuH2pnZ+/+rJk3AvQBn2E8xhqlsuv6xGZv0UdHV+9hAP8YwDs96hoM3NgW5dOLm0aQ6bYnkvsS03UExAKU14lxlaG3XDA6estrAcpb44/Fkyki+i6AdwWpw0CWiU8cHUxvDFC+3u1bc+jsTiXY5O8CtF+AMRWLVIIXOhLJT4LxwwBr5UVm/lI2k+6PdaUOdzuYeI23vf3Y7SLR3EVMOHWKsD0qhJRNI+QfQhyqqBcCiiAasD5kBAGT/kjENxRO/UFGsZFM/TPDw2v+GutKnkmgbwX5eAsN/wQGHz8ykhYnP9efdZt5jk5j4L+mbgtBRpbnrCeh0dEj61b/2q+PZ57FOSC6yHbKDtrLGBN/MTuYXul2mxBzqGf7YqDi5Dtn61e+CcaZFczBmisDv9FMfeHw8Jq/+EyeOrpSXwTwnRAyMcB8ATR6HIzbi+3bb65ufeYPLVgN8HuCCqVQTqytc0aG+n/gddNrhHxCjlsV90BAEUQDloeTIIjwU2brdL5ToXsD4McBLZvfPHg/Aj7kJABiXGuCf05E19s2C/FhZsQGzeDtCPi0rd3i7AwiOm54sG+111roSCTPBtMlkk3PUmEA2mN5LuCPgPExyYa1CcQLRgbT6103oERqMTNuctQ1wHiaCVkC5W8h7n28zNDmZ4dWj8r66Kxz+9btzQ2nvFrwDzacWsHcDtB7ZWQu5DmnZdOpAwMDeki8RPHXSdyqQE8V5N4FYHdbO0K1tQHAvKAE0ZFIzgPTnZL1owP8RxCNgmkC4HeC0G1TOU2tMxB/ZWQw/d9uJNEA+TTgi549XSiCaICsnQTh6HKtofFZ69eln7L/e3ti6UeJjTQB+zg+ehNAC4AxAi5kgy+33wwKJ7QTQPQ/pZsw3wMDi91uES4f7ovMdGZufPt+5xuIeP+YyGEFiL7q2OwfM6P6/NGBNc84obV02nNa7gfwiS1/4wFDw+ec8xd/F32M6/RvBFxQusHSra3RF5Y7N9Z6ty/G1N6VnKuBHgCw45Y50JMmm6e8ezc8mE6nxcZc8hMqG61F/wrAZzuIYhOZdMDwcF+eeB2/ju4lH4dp3uvYsF8H8Teg4wqHLKmzO/kpNnGlmxrK6wbR2bloT9aidyP/hlL8WeowPZe70PluItbZX5/FpzXSfui4bYwx85JsJj315lZsrBHyacDnPKu6UATRAHG7EwRdMzm2/QrZA7QYVkdX8lCA7gAwxzHMMSIsGx7sv81l+NQRT54Lsm4Dxd9zrNEBtneMqT/s371kj6hp3gfgg7byG2HwwpGR9B+9IIp1pQ4k4Bb7JsbARdmhfkEcJY/jhbI/s83nMTMXOXB0dNULHn0Enku928/fHnovB/MK23j/CoMP8MPJendJJJcT07X2GxozHZfN9An8Sn5CjdW69as3MXOv7Q+bGDg2O9T/cze89u9J7hLVsQqgHmcZN4Lo6emJTuZ2uooJn7fVERv9Z8VbhpfKSNafeJMwJ3OHO0mlAfJpwNc8u7pQBNEAebsQhO/m2NV1zI4GcvcA1F4yTML3Rwb7z/L6cGPdvR8kk38BYNdC3UkGDpNtLh1dqdMAXGHfiPxURfbxdCZSxzFDvKcULXeeMjQ+wHkriCVSZxLje1N1CStHBvtP8BNBe/vSnbUWQ2yKHy6WlW2s9W5/bs/Sd8zR9V8A9FHbmFeMDPVf6TcH8XeZPJlwfnaw/5vO+p2dyQ7WSNwetiv8zWDGimym/4d+fXV0JN+LCAnZv9te1o0gOjt7P8yatVa2qDx9VEX2diX9SVWa9ZaPHy7q7+ERUAQRHrPQNWQEIdRDw0P9X/drrCORugGM5bZyL5vgg0aH0kK/7PqTbWYMHJEd6hc65qnf3AOT288Zx93CKGdq83W5Abh1JmsDTKeMZPqutteJJVJfJoZ4XC/+0q3RTcd46eALBcVDrSCgAwD+C4MeAbQbne8Q9W6/oyP5TxShL3JeRfYxEIwIG4cMDd32pJ8ci38vk6cLSXbGUxcz4bwt7fLwZBs+s+Hn6VeD9CUhfbgSRFfq6wx8zSZ/6Q3Aq99ORxsA39Ua3SY5MHDDeLFeveUTBBdVJhwCiiDC4VVRaQlBuJ7mnR1INorRCFrmDw3d+rLXYPJvBHQHyHq0tn4ygpDo1AMRkP84Ubb5x+K9i4jYrhbztUoKA3i92w8zFreyQQjC5aYx5TsTZBxdXYvfoyMyQMAeU/K3+d8U/026TiTl/Ppsjye7NLJuPNsU1trTURg9dvKcCfLxm+ds+7siiAZIvMzMFSj7eNyGUX7qKj+ZyeoGJYhYvPdYIr7ZRiJPcC7S7fMuUNZl+cfPj05GowdsGFj192Lhed3JvSOmpfrY29aAsOD6tbDxN/XoXWH7tQ+k3u3XYqkEIQiJevANk/nQ0Ux6KOgYPnrwsm3e9ubE7Qwc5EUQEiIxmGlBNtN3T9C+RLn2nkW7a3p0nU22ZYegmSCfMHOeDWUVQTRAypIbxJ+ipCcGB9c859d9GUEE1NsHJYjyGwqeZeA+ApV5bnuPlYUX9CE2opGRIMW6Uv9ZsEpya+4ZEO5ixm1t0a2H7CoKP6ysh+D6th9gCGVFKB5fsitr5qeZcSyAT5ZYfUnkKXnMfcqM6t0yyzCvAXXGUz+yPzzLVEzOkz+ASaEeArQpYg8yaWbemsjyuC++mUDyTjQd5RNkerO2jCKIBoi+nCA4kJpIDK3eBCF546gVIlJVlXivaJmgW4nxmQAdCfv7DWD8KGiIinq37zZmQchv6tpuEeJ9AX4fM32CgP1LwofIKssIolwVF/hAYe/CuXZkBOFjgh1ARO5FZP29VfKpaiKzuLIiiAYIv+wjZDzY2sILg4S/aDaCEHB3dCS3QhQrwPQfITzJhX9BlqH9W3ZotXDEc40vVe/2C0uG2hPJDxLT2dbJuRhDK+x6khGE8zE/xHqZ7gTRCPmHFYEq746AIogGrA5FEHKQLUc4A0cT4+yCc1fRTNZLKrqwAJsY2+Fbbv4jxcr1al/4jUQM81IiHBky1MYmKwyjPX7WLCSIesunAZ/0rOlCEUQDRD2jCCLgG0etYbNUD+PUTcBSEA72OZEbDP5ydii9xafCZ0C1aj/v3cw/CRCr6AWA/0SgIZNpINeiPSQe7AM9Ur+1KqaK1FnVrodayafacaj6pQgogmjAipjOBOF8yCTggX9s3XrUo/ff9EYDoHHrwnrYNWHMB+ELAM2VxDLydTT0GH9F7Rf8PdZKvJT/xsDNgHZvLkqPbRhYJcKfS1VgAQliPhELf5Upx8N6PVLH4r0lfRHwd5h80PBw+pEmlv9bOLWZ1bUiiAbIazoThMS79Y/QuWdkJP23BkATqIt8KBBDhEW3h4+oyBxT1mHQ9jsTvUuYLZPgLbkeCD+Czmf5Rcot9huEIDo7kx+DRg8w8I5CvdBmrj09J7RN6G+kATq82Lfs0VjSl8HMi2SxlAIJqw6FgsqnDl3P+iYVQTRgCUxrgsjHUrLHRxJmjgtHhtLC6Snwz/LcJVwI5udB9DAYD8HgHxc3TuGFjIgmNqtuwBSRbCMRmIcF9UJu7178Ps2M/NKeP8K+4dW7fRGvaELf6VaR42lqw3WJOeQGWjx+xLYmtYmbgTB1zf8kKj2XECuBQ3qIZoM6yknDhxBdMTLYd3qYBE0iXIep8d2bTZhFZNpHCPg/Yr4yk0n/VYyn3vIJvFBVwVAIKIIIBVdlhaczQcjiHBFR38Sb2y/zewQuoiGidGpzWu4qTTBU6tDX0ZF8F6I0AIYIfS1+oU6qfh6/9W5f6t0MXJ4d6j8j6KqQxDySEoRoL9aVuowAsUkXfuFCbUjiY7mF2qgmAOEUzUn8T0qCQ9ZbPkFloMqFQ0ARRDi8Kio9nQkiH6E09T0w/tU2Ob9osSU4xLqSZxFIpFDdonphPnkkk76uWFB2Ag9DRJINRjhiLc5m+taIPurdvuykLfI5DGf6vxBkUbhEZ3UlCFmwPiKcMDzYP+X17tZvwatZeEJPBTcUZd1iMbXHkwdpZEUNzqeUtX7ekYbtfcvDkvOa1ug2xxYdHestnyAyUGXCI6AIIjxmoWtMc4JAPL74QyZFRJ6G3WyT8w0tLcp2dC/phGmKrGXFSKCFbGm5g4eHbxdmnVM/uQ7fO8FMcbdyhi9nSbiSerYvDV0BPIGodkh2YPWfvRZF3i+DBAkLMikx5WXGzdlM//FOdY5buG9o2lEj61YPu/WXf0inawCknGXcCMIan4ZVIFpoq2MQcNHE2A4Xe90k86oj6gNwoP2AYTIvHM2kRd6Mhsk/9IepKvgioAjCF6LqC0x3ghAzlNwCxD+PMfAtzrVc6sw37eGM5nr7kKui4JqURgxAJNuhltwlBJxcsrlKQp7Xu/3yiKVihPywSVguy5VdSE16GJgvcc0l7eEE55YwiED/zoZ5vTNhUHti6Uc01q9zy5HtlTDIpS8xv7s0xtmZTPoPji/BI0GR/PZRb/lU/6WqFpwIKIJowJqYCQRhbWZbvXoFwCdJINEZ+B2BHhZvBwUfgLgk5ajBwH+3RTdd4BbCW67OsHosTWtJ7JWus5ifuyyfcz3bd8uzYGFSmjI1AjY/AaIPlKVWFbcO4J9tSZP+V+PxBZnMT1+XLcVYPHUKkZWrw+lEGCTlaDH7oNW0X05ql6yCxWE9w8CQSAnrkdpWqMxGotAXu8UZq6d8GvApz7ouFEE0QOQzgSAEDIUT7zfBODOkh7CoboBw6eSbO5zn87hdzKwmktvbdN6BBfEYa5SSZcYrtFDX9gtRa0Vuim0Djzhf8HUmOl/kD9eY77OZsPoF4qNYV/JMAok8GtGAfY6B8Q0QH2w3DfYjCNF2ZyJ5GDOJnOG2lKoBewWPmlHjaJ+ggnWVT9CRqnLBEFAEEQynqkrNFIIobrD53MZ0mfOR0x0Efpw0nDa8Li3MUF1jJNnrd3b27s8a/zh4H5a660eca/kPp7pLNq56tt+RSH5ShCd3VRuVDkjcvm4yNO1rD61b/bTksTuINZdvvmlbl8+SxsvmaFhflg+EcFZ2sP9Sv8Us/A5amL/DzIsDkpJbnmzXruopH7/5qb8HR0ARRHCsKi45wwjCmqdISv/MC9gXpnYiYB4IkEhfWTw1jwH8DIh+wazdsMeuxsPpdFoE0wv7o3ldve+LMi9nwiEg7GULsSHae56AjSDcONHKdwbNpmYbRN3aF7etlq1eOZSAZeLgDWAX263rBQIeZeY+SRTaMrPSoNZcjj67AexcmOvrAP8WjCth4nbxNhE03LuXwIQJdKTF6GWIvNgk1GLF/izZAPwooF3fGjXvCRJ4UtJX3eQTdiGq8nIEFEGolaEQaEIEJH4bNfM8b0K41JRcEFAEoZaGQqAJEZBkeKsolWwTQqOmFAIBRRAhwFJFFQKNQqCjKyWcDEUYFGFe+mvW+OaRdenfBu2/oyt5KGA5v80RdRioKJXs/2/vjlEaiIIwjs+sG4KNnsAD2FtExAPYiIUpFC9gKdgpWOYq0ZwgtRK0t7axELTQUhDyZBMDi0lMJr4Ub+ffjy9vflN8xe6s8/4eddUUICCqOVe6Slxg/H+RS6eevx5Pe3243O6UJbu5/z5xOq4fUYCAiIjJUQjEEmjsNPdVtfiMyGj/4T1Itnd/136Y8Ru6vds8l6Ct8qdPVPWkd3vdjnU/zvEhQED4mDNdJiYw/MR1vysim6Wrv4WgZ1+f6zeTdk2KTeW8VrsKKqe/Xk/t1vNwuOCbRonJcd2YAgRETE3OQiCiwF9b1IPXWiV7HD5fCGsapCEqG+MLjvokWf/A8vwiYgsclbgAAZH4ALl+dQUGzxJWPy6CyOUCm+0FzKyt8+ri0VkUAQIiCiOHILA0AcsW9egSpq3zpd2cg5MXICCSHyENeBAoNtufX1a2VMLRhM32n81m6Ylo5x+bzR4o6dEgQEAYsChFAAEEPAkQEJ6mTa8IIICAQYCAMGBRigACCHgSICA8TZteEUAAAYMAAWHAohQBBBDwJEBAeJo2vSKAAAIGAQLCgEUpAggg4EmAgPA0bXpFAAEEDAIEhAGLUgQQQMCTAAHhadr0igACCBgECAgDFqUIIICAJwECwtO06RUBBBAwCBAQBixKEUAAAU8CBISnadMrAgggYBAgIAxYlCKAAAKeBAgIT9OmVwQQQMAgQEAYsChFAAEEPAkQEJ6mTa8IIICAQeAbGWDfHvqz/kUAAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-51"><g><path d="M 211 151 L 261 201 L 211 251 L 161 201 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 201px; margin-left: 162px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Failures?</div></div></div></foreignObject><image x="162" y="194.5" width="98" height="17" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAABECAYAAACbHqJdAAAAAXNSR0IArs4c6QAAEYRJREFUeF7tnX90HNV1x793dmSJkGJoSAyEH/lVTpJSmoONtSvt6ojfhNgxAXYlEwxOSUKaUtOkpTmltE0bk4SQk5xwCBRSBwwES7sYDHVLiF2ieH9o5dQpJYSmSSAtuBhMXWMIyJJ255a32hWj3ZndmZFmdq298+fO+/l5b+c789699xHkEgJCQAgIASFgQYCEihAQAkJACAgBKwIiEDIvhIAQEAJCwJKACIRMDCEgBISAEBCBkDkgBISAEBACzgnIF4RzVpJSCAgBIdBWBEQg2mq4pbNCQAgIAecERCCcs5KUQkAICIG2IiAC0VbDLZ0VAkJACDgnIALhnFVgKSOxxF1gXOFHhUz4Qj6d/JofZTspMxxL/DkxbpxJS9g4mk6urc4bi110bIH1NID3Vu4x8NF8JvmPTuqRNE0hQMujA7+jM1/BhPMAnAzgt8otKQJ4AUAOoFSnbjwyMpL6TVNaKZU6JiAC4RhVcAlFIAARiODm23zU1B2Lf5CYNhAQdljeOAPf4amOvxob+94rDvNIsoAJiEAEDNxJdSIQIhBO5kmLpKFINPFZADcBOMxDm55kjRL5HcP/4SGvZPGZgAiEz4C9FC8CIQLhZd40IQ9FYvE/A9NXAISq6i+C8GsAWTBNAPx2EPrAeFttO+kZaHTJ6I6hf2tCH6TKOgREIFpwetQIBOOxzg5etRDWbGUPogUnnMcmhaOD3QTjEQBHmYooArRBp6kvptMP7DEXHY/HQ88+jzM1ws0AvX92tTwy2YULd21PHfDYHMnmAwERCB+gzrXIhSwQTtnIHoRTUs1JF4nED4OGTSBaNUsciP9iNJ36OgC2a9np/fFj9AI2AdRvzsuMq/PZ5N83p0dSqxUBEYgWnBciELLE1ILTclaTenriEdbo+wCOqNxg4M6p8SOv2rXrjqlG7Q/3D74LBeNRmrZ0Kl+cm+zCBfIV0YhecPdFIIJj7bgmEQgRCMeTpUkJa5YKgb1k0Fm53PCTTpsUiSb+CMAtpvR7WKOzZMPaKUH/04lA+M/YdQ0iECIQridNgBn6+/v1icI77gMQN739P4IiLh4dTY07bUpPz8DprPEPABxZzjPJwEfymeR2p2VIOn8JiED4y9dT6a0gEN3dq5doemEFiD4CYCmA4wDopg69CPDTDGwuaqHUj3cMPeeks35sUteU6XJT303+6rQV573u7o8fQR1T1xHwCQDvADAO5p8z4V5jsrBx584H99nxUZu3z+0JLSMy1oJxDoCTTKxfJOAJEO5eFOItXg0Vlp4dX9w5QSvBuJyBUwEsKben5MBGwFPMPFycKmyp11aVp79/bdfE1OtXQ8MpYF4G0NHE2JDLJv/SyRyopJF9Jje0mpNWBKI53OvW2kyBUA5PGtM3AJxtYbpo1+4iM7YUQ9rnGgnFQhQI0rTdMPh+gN9jDYi3duqHx0dG7jpYdZ96+uJnsIFv11r1WJb0Koi/hAJucfqm3t8ff+tEkb4ExlUO/RQKxLitWOi43m8Htp6e+Ieg0TYGji73dr8BPmcsk9rVgn/LtmySCEQLDnuTBGKuDk+K5PMaa6uy2aF/tcO60ASCgGsYpYfvB236XCSiy3Lp4SHzfWUFRCFtPYOvcSHE5SJ4zNCLl4yNPLC73vSNROK/jRANl8Xe1Uxn4BfQ6EI/9wNq9yD4iUldP2vXyKb/ddVYSewbAREI39B6L7gZAtETS1zMjHss3jJfhXpYgB4HoJYjQmDjNFDJjr3Wc7bB8s5CEwgQ9pmcv9T6exagZ8pfE70AnjamQmePjW16sTIjli79dMeiww7cAvCna2YJYR8xfsIg5WQWYvAyAn63anlPZXuKjMIFudwD/2010+rUUVr6Amk/KY0ncSeAXjDeXStU/vkm9PRcdBJr+j/PElaiW0bTw+vqmch6/1dJTi8ERCC8UPM5T9ACcXrf4Am6YTwK4AOmru0nwrqJ148ctjJbLL8Bf4LBXzUFZFPZJwFeNZpJKRPImmvBCcRMD3mM9dBgfmTovyo/qeWd8SJOHEunnjKBsPE+5p8bjHUnHofHUqmUEuKZa/nyj71NW9TxdzT9pWL2WH60U+dLrPYlwtHBfoKhHsAVES8y8JUunW+0Sr+8L/5u3aDbGaU9kMpl+fUz1+lv82XzvMbFc7PZzT+ba/mSf/4IiEDMH8t5KylogbAwN3xFY21FNjukoqnWvXr64meyQQ+a7eGJ8WW7DcuFKBCl5RhdO88sDnbQuqPxpRpoW5X38XYUeWB0NPV/dWBTOBa/gphuNT/0ibA2l07eW50vHE18iwD1Nj59OXg7VxvZiw5iy2wHNtv9k0ZTw/J+d/9Fx2uF0P0AdZsSjBNhTS6d3OypUMnkGwERCN/Qei/Yh1hMT+tUiFWHPlAtLFmkFF5LAbTCzcOkktbK5JEZ9+azycutlgoWokAQ8Le5TPKLDkacIrGBm8F8tSlt3aWiqjIpHE2oL4nr3/y91rns1HPXHP7W1yceNH8NOA2VHonGzwfoIQCLVB0MPKej2J/JbH7GQf/qJgn3DXwABm+Z7RxXWuZq6H0917olvzcCIhDeuPmaK0iBKIVMCNEfMBAFcBoBiw3mS8ayqYzTTs7FTBTzcB6Em/qt+uQmv4WD2GsG8/lOeKllnJBB/wKU1vvVVbT7ArBjb1FGje9AyXJpih4C4cxKOcx0WT47/L1GY1p+w98GkNqbeJxBT3WQ8a10OvVSo7z17pc9r+8vm0tXkhbBfP3xx+Gm6mW1udQleeePgAjE/LGct5KCFIj5aPScHrCHvkD82tALfY0sihTncG/8o0T0wMw+AuFXKHD/6Gjqf5yOg9UXm8WSHoV7E3cT4bIZgQjAKsmuD5FYfDmY1EFPyj+kcqkN/WtHM0m1ZGYbt8kpF0nnDwERCH+4zqlUEQh3ntRuBGrevyBcOOX19CZuYMJ1lTYQsO03b+n82BM/uOc1NxMmHEtcR4wb3sxTu0/QExsYZGa1N2He1FaH9DxE4I2d+uEjFn4ZbprhKK2ltRLwKkBXjmaG1ReFiIMjks1JJALRHO51aw16k9oLgqX9q4/uKBQjBKwGoPYvKkdLqr+8bXjyBbgHkerU9146MjJSqMfRJjzFLwHth+7584cALDcJxFgIHR/OZO7bX/mtbPm0tc4JbwUGfkaMYQ7RlhOWGL+Y72UeZWrb+ZYD9zDzgKmP+4l4TS6d+if3/ZYcQRMQgQiauIP6WkUg1Ab25OQrSwxNP1UDncDEy8GlB9O76nrltpNA2CyRVQ+z1b6Ag6ngNImlEUJv7+Aygwy14azCpDS6lL/LVjLoromJxT90EpG1UYEWEV8nmfnyfDalnPfkOgQIiEC04CA1UyCUT0TIMK4hQL31He8JjwhEDbZmCIRqRGk8i8Y3iXChC49ttT/wXZ0KN1hZvjmdE9VLagC7DujntC5J5w8BEQh/uM6p1GYIhAo2F9Kn1jPhDy28duv1R715qqWNE2cSiUC0jEBUGmIS/jVVm8X1xvZ50nhNbkfqMbcT2tJ8mukzo9nh292WJembR0AEonnsbWsOWiBsnJdq2zcdVkJ5CucB+pHGlM1mh/aEY4lriXGjCIT9ZLI0PSV8IZ9Ofi3gKUjh/sGTaIrPg8ZXgKH2M2pDprzZqL3QtPPdnhcdjV56VBFTj5gc4orMtDKfHVZHlMp1iBAQgWjBgQpSINRGYsdhL99eDlNtpvEyCENs0MMd2tTjxxwT2mu3ienGimjBbVI73IOwcl4jxj/ksslPNXMKqvHv6tp3cpFCa4gxACrtL82+HHhhV2exCOUtkVqbOdAe6xaB8AjOz2xBCoTV0ZFvmOx/H0X+eIPQDzMImi0Qkd6Bq0D85lnGLkxPVSd6ehPfYcIn5/MLyGp+uKnHz/lVp2yKxBLngnG3eRlKhRLhqVCfOeBgo/aJQDQidGjcF4FowXEKVCCqbPMBPIsinzU6mvqVQzQ1TlmBm7lGEysJeNjU3h9pfHBlNvuw2h+pe1m92c9H+60qrREyD8d0qqhK5XAd6jS33SrKLrOxravjpc0VU1sV0oLYWAGmiDrsiYFcl753TSNT3Eqbw7H4WmK609QHeftvNJEW6H0RiBYc2KAEwsY23+5wG0tSpZPnOorqiMhT5vMN3M1pY+FagXDu3awepgar8BfHzmf7Lb8gegZOYa1U14xHMQPr85nkXzt1GItE4u9DqBSuY8YogIGb85mkOleidM3VY9sioKAIRAs+J4JokghEEJRd1hGcQNQG6nPp3WsRPK70qAvUUa67Nx7ViFR48cPLqOuGHDcNh2/tt/yCUHGvNGwC0SrT/b0gXjmaTu1sNE2UoE8WltzMYGVpVrnGGdoF+czQSOWHaPTi9xQQGiHghPJvrmI+1QgM4FhwG/VB7h9aBEQgWnC8ghII1fWadXFgP0P7cD4zNFYPjTpHefcL+DyYvmxhFmu7xOPHJnUkEn8ndBoB432VNiuhm+ji+K7tqQM2/aBwbzxBVFpKmW3FMw8CZ8euuzd+jkalaKkzdTo8vc26vcwPwcBq8xGk01+GSzYCfKlbIbIO+Q1H3uIt+FeSJs2RgAjEHAH6kT1QgbCM2UPPkGZ8KrcjpcJAzIqVo4ThuRcoDMbX64RxsA0v7odAqHX5cDSxwcISa0tB09ZVn5OtwlDoHR1/Y+vz4aNA2HwFqGm0H8zXwsB91edN1/FRsf366O0djBlkbDWf0wHgJWb63NTBxUkrT+np88ixEaBl5i8Ug3nVWDalzrBwfFmee+HQ4stxJZLQdwIiEL4jdl9BkALRIGaPOiYzB1A51LNxCkC/V3WCHKCiknJpXf2Icm9tlyR8EgjYHMSjmlMAeBeg/bvNEZ5FYtzKVIonNR2G20eBUMWrt/TOg5SqOr2tMlHGQXgcTD+d/sH4fYCWWnyljTPxn+bTqdvsvpAiscQ3wPgTi/uvAvxTQHty+h6/XX1MAlhSm5bumBxffLXb0BsiEO7/962YQwSiBUclSIFQ3XcZs8dMrACmb3IH3YqC8ajpIJiXyaBzc7nhH1fj9UsgStY90cRn39iHuKmB45e5SUUC1sMo3MmarjZ+3xuEQFREYtFBuuONs6UTHqago1DZJee8gnYrwMp72u2ljii9u0vndVZHlDYqTASiEaFD474IRAuOU9ACoRAsjw6crIE31lk2mvVgBbDdIP68Om/ZKqwC23gJ+ygQqn3U0xc/gw18G6D3Nxjal5j5j/PZVDIWu+iYAuvqeNXABEK1rbSPs4eUQChRe6eTqchAnomvrDrn2jZruY7PvPEFsh7AkU7qAKDOp7j2+GM56TXCqwiEQ9ItnkwEogUHqBkCUXlgqf0FzaBPMnEMwEkzSxulMBv8nwxsLmqhVPW6fvW51upBZkxOrdi588F9ZsQ+C0SpqrJ3+PlUsvah02aWTsp9IKLbFoV4S+XNuMak1uclpuopp9qrd+3vDkG7ksnoBUgFSaxsYqvloGcZtNUAfXdnZviXTk1izfWUQm93HjgDhNUWdYwDvJtYyxZhbCgcPGrM7ZJSdZ9EIFrwweKhSSIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCAgAuEBmmQRAkJACLQDARGIdhhl6aMQEAJCwAMBEQgP0CSLEBACQqAdCIhAtMMoSx+FgBAQAh4IiEB4gCZZhIAQEALtQEAEoh1GWfooBISAEPBAQATCAzTJIgSEgBBoBwIiEO0wytJHISAEhIAHAiIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCDw/9PUXuoYdJv9AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-53"><g><path d="M 51 851 L 51 884.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 889.88 L 47.5 882.88 L 51 884.63 L 54.5 882.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-54"><g><rect x="1" y="751" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 801px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">ACPI s2idle driver notifies EC using _DSM</div></div></div></foreignObject><image x="2" y="780" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmAXEWd/+f7uiczAeVYlBtB13XXYz02yNxxNOEUCBB6JuEKKyooEUUXkWNXWQEPdkHzA6MoiqCQmTZcolyRHTNH94SNusgiIorKZYJsQITJzHS/74960z1587ree/X6mu7p7/sHMl1Vr+rzrVefqm99D4I8goAgIAgIAoKABgESVAQBQUAQEAQEAR0CQhAyLwQBQUAQEAS0CAhByMQQBAQBQUAQEIKQOSAICAKCgCBgjoCcIMyxkpKCgCAgCDQUAkIQDSVuGawgIAgIAuYICEGYYyUlBQFBQBBoKASEIBpK3DJYQUAQEATMESiZIA5ZnHh9zKafAHi967V/IZuPGB1Npsy7UlzJRCIR++MzeGeM6QQmHA5gfwB7zbRGeA6M3xPop8RIbt++6+bNm6+divK2np7Eqyam6HYQ3helnqfsFgZeAGOTZeGezMTUXZs23fqcaXvd3Sfsk+H4EIC/zddhwvnpoYEvm7ZRq+V6ek5vmcyOH87MJwNoBbAvgLjT35z8QNyfodi6Bzaue8JkHDqZMXBsenjghyb1o5Rp6+79NDG+5Jpz300NDZyua6O9u/d6MFaZlI3Sh3orq5nP22zwoWPDyc3lHks131Xuvs91eyUTRHtX79kAri4YCNHVqaH+cwBwJQZ5yCHH72EtaDqPgDMB7BbhHc+C+d9h47pUKjluUq9MBOF9VYaI1k8RnWey6M1Hgli06MNNTQu3fYxA/2oowywzbsvGrHPDMBOCMJnZc1emmot2Nd81d4hW5s0lEUR7e2IhYlgP0JGa7j2etXjJpo3Jx8vZdeedcawGO4vKq4tvmx8h2zptdLT/gbA2KkQQ+dduI+JTR4eSPwrqx3wjiPb2xN8gRt8HcEQY/prfQzETgigC1SpWqeaiXc13VRHCqryqJILo6Ei0s0V3A9gl19tJAAtcPV+dGh64plwjeXdPYu+mDN3AwKEBbapTwZ8AYoDV+PYGsNCn/IsAnZEa7v9B0EmnwgShurYVxMekhpKb/MY1nwhi0dLErs3bKamV47RKaSNAz4K4GUAn2FFfxjzYBGImBFGur64y7VRz0a7muyqD1ty1WhpBdPZexoQLZ8iBsAYMpVbKkQSPTrbgqM0bki+UOsSOjhMOZCv+YwBv8bSVZeABAl052WLfq3kXdXau2IfJ/gADn9KoMsaJcOro0MB6vz5qCYJxf3MTLxscTP7VZGw9PcftNjnZvL9t8TkE/POMjj1XmYG0PTl1tN+9xDwiCGrr6v13Ai724PYQE85KDw2Mesn63YtXHBDL2lcR4TgPUTxkxzNHjg3e8qRXBkIQJrNy7spUc9Gu5rvmDtHKvLlogmhtXbmX1ZTdAOBtqmsMPBFj62Tbsr8Nxhtz3S3LZbX/jpN+R5b9odGNyf8yuevIqTW+AeBED5xPW5w9bGRk/f/qYC4HQbjbbV+8ogO2fSuAPV1/V/r11emRga/r+jBfCKKzc/lbbYrdm7uIdoZKwH0TLZwI2kgoY4Qnn8Z5ILrUTRIEXDI6PPC5ynweZq3KJbUZTu5SsmhHx2wuahRNEO1diSMAun3mtMC43840HU9NU1/J7ZCnx1PiZXVPT098MrPXGgZ/ZDZAPJiJY+UDg8k/RQFOXYwuWPjC1QB/2F2PiPonXt71VJ2FU7kJQr23o7t3OTNunKX+CjiVzBeC6Ojq/dwrur/PurD/I7K8JJVKPhYmRyW75p1euJGZ+1xlH7KnYkvHxm7eEla/Ur8LQURHVggiOmZzUaMoglCL9kRmr+8CfFK+08S4fHRk4KK2zsSxRHSLa5dX0mV1a2fiUIscInLfI2y245njdKoFExBzFlB3EtDmKj9uMy8bG0ne522jEgThc8H/DFu0JL2x/1fePswHgujqOmn3LKbuAkiZsuZPD5FOAAUbE+Alm/mIsZHksInsK1FGCCI6qkIQ0TGbixpFEURX1/I3ZBAbJOCAXKcnX7kHeH96eGBDe3tiP8Rp0KVmUkWKuqz2WUS3Mawj08PrxkoBrK2z7wQivnn2pTrd1BzfsmpwcDDjbrsSBKHab+/sOxPEs1RKfrb684Eg2hb3vZlsVj4z++Twjby4a3FgWp4e6Vebkjl5hCCiwy4EER2zuahRFEEU+j7wg5Px+JLNgzf/WSmV2rv71oB59Y4BFXdZrbGSKlllle+TutdYsB0/BqjDBbz2tFMpgmjr6j2GgDvcgmemU9Ij/cr8c9YzFwShVDrxlm2tMVhnMHE3gAO9DmzEuCdD9N1Nw/2/CbsHauvsO5KIlaNa3iLpcTueWRzlJKi9fNY4DJZ6Sa0uxuOcXQEbK0H0D7kTbIaB/wX4Bp5a8K2xse//RQmpmgThjCtjHQnY/wzQP7mcQtWm5g/ENGRb/K0D9uZ0MpnMVnNRcVSAzS+8ly1WToLKqXTaYXXaMu1ehvXV9PA6ZanHUQiioOwOVexLHYt7u9nG5TkHS+VcqVSN9zPhmjwGYe/SrQV5jUgU/KY1K3veBCCRr8fAmvTwwMeD2lH3a088EzuYyD4d7Fho7vjOgC0EPAjCDQtifJu5UUyBc+9v45TpHhq65ZnW7sRbLMexk5Y489qRD29i0Nqp8d3udqvZIxOEdrH03DNo1AAzJ4wogLd19X6V4FhF5Z/IO86g93V09X2Uic8F048YfGdLnNM6AVSVIHy8o6tMENTWmeglov8EsJ+JzJQVFhOfMTaUfNivfPviFe+CzWcD/E4Ar2VgexNletSkNXmHKqOMI6gpu5GAN83UYTorNdKvjA9mnmIJorX15F1i8alLmaDuvKa9ufXPswB9IDXc/6O27t7zKu1JHd3/hx8hC2ebGnCY4u9TjjoWJ97LNq4BHDL1e7JE9APO2B+Nx7PNnsgAvp7UOoLITk31xpqbPgPGuRoTaPX+mTUnjCBU4cK7MR6LoenI4eGbtplio9GshBnpmOKW78KLIP48Mrg6zMlXM/9/iyy/BzFSloBX+Jr+e76lyASh833Iq5fyo1jUs/I1CzKZnwD09hlwI15W6/TVQHShmQo3qFxVCcInHES1CMLPWsgQx3Em/mh6KPndsNOEYXsFxVq7EosskLon2j33Y5aZjkmP9N9VKkHkVGADecs8gz6OM/M/W0QHMfDFHXMdZQ210daz4iDKZNe5724M+qaKZEG4avLl3S6MGl7GsH04p4aFz5+fMzwIIlR3kxsszn7Cppi6W8yHjjEnCPAgwxoh8Gd8yEFNvxkTeyOC6Oh7G1uO+jNvWRh5M1qoMvbXnCjCp5h1KYPV6cLr4xMCP4/Z8eyJQSdvHUEQsCY3T/38wgo0KJEJonBXr1+0O2b7SKgBR7qs7uhIvBMW3cfAa/JoEeNboyMDHzKdvOUqVzGC8MbwCbhwrRZBaK2r1ELDeIIJaQI5ahUQ/yMY6iTgnWxluSPyk513p6fMq+PI9gwPr/9dKQQR5GcD8COAlVbtv3LSPJiAt7pOF9vAGAXh/ZUgiMB+uWTC4F0I6MrFIvPAR9dOju+6ugIkQe3diX8B0xc0i9yLADY4Do/g14KwGIw9XB1TJvJvdp1QIxAEVNvKiXLa34rxe1j4qfP/Nt4DwkHue08TgtDdd5qoh/LjUfHEJjIvJQE6Ov83v1hpfpaU098VniPGzxikIlDENPMt3/zDZGeOGh295Q+6b0WzZikn5glX9ImtDNxPoJcAu805+RGt9YZHikQQXt+H6fHo7dC19wcRLqt1+nloVAnlIoGgdipBENo7EMJjyHBPKpV8ytufahCEsu6KLWhSPgpKt517eDBr4QO6kCkKl+0Z+lTO6c21e9Rf9pcqK+dewLbvyS0suebMDQv8DAB8zGcd/4yMxWd6x56zglPOfioOWOHuj8pzgvDx/3HiUdkxPk8jE2rtXvmPFmeuA+hgF95ZBn86PZy8slQZuOt3dq7otsm+0xVJQf38IpjPndy++w1uQnKCaj6N91lkff2VO5w3aPoRhSDy1ccJ+Mx++/A1rvsW6upa/vps1no+lUr+nypoQhCqnOYE4L5bDYROY4CxlWxaMjra/5CXrfWkyo/YjHNety/u994dBcy3e5rjfKKxWny6I1kCfZWz9sVuNZX6tmBlp7xuA5EIQmPC6itU/SWw+WV1wcWfS6dYzklu0lYlCKKts/csIifIoWuB8V9Yq0EQbV29SwlQMaHy4VJMfAyovTNxPsjZReYfX3NdE7x1ZXx2XZMAL0sNJ1W4l1lPlDsInSm1Oq2yzecE6Hr9d89lIgjNN5AF88X774srgi6gcxfZXwP4VBcoxv4mJjJydtwWbgbRMlf5rbCs41Mb1ylveO0TcCKKThDMF6RGkiqKbmBAUFOC0ESmNr471Rju3IUslnvnj0ZFqnDagCz35QnNBzpq606sIqavuU7tWSKcPjo08D2T+a/KMPCdqfHdzjQ9TRoThM73AWAtCPnO6hZ5vw/aO0BN3YqFAw77IMpJEDkd/+kg+n8e9YyvH4bqX1UIorv3XGLs2GUGLHRuzHQnSz9rrDCsfRcWjWNhVOdG3QlCN6/Dwp7k+zgdjfb5b8xyDFU/loEgdJgC5qoina9POb3ONRoC38Wq4NvuWtFKsNWdUf4eSRWJShDGKmtTgvCZC6FWSFr1lN4aUWPhiUBVkQc7TZga/abbJ35c2KV5wednTBCaI5RqLNC/oaPw4sfYTNUbN5+AP8PmQ0dHk78odpEptl6pBKH0ky9nxl8XB5Yy7I/pLD3CmL1KBDE7rwGQbI5vPcnrF6LBkdq7eq8HsATgPzDoF4B1Q6m+Kvn3dHQn3s9MyuvcvaAE7ohNTxAayxNlaXPK6FD/OpP5op/jpauYOrr7VjCz2hnmT5iRTwCFbcwyRzcZnm+ZwjtGc+2A3hQ+MkGYzk1jFZMabKGWJBwzzRzQkpfmhGJMqnlBmJ5y9AQR3cjHmCA0eR9C1Qi6ixvTy+qCxCrAjB1vSTO7iMpViOYauouoCkFMOw+6gxZW3CopTBw+cauKCrCoO0F4FwS/S2+/fups38twglA7xevcJxO1gUgPD5wRpk5x91NDfpEtc3Tj1n0PUf0GWjsTXRY5kaB3zr0j0gmCCRelhwaU/0PoY3qCUA1pTm6+asz8iwu1HXpVcQH5BNw5RplvOuy1GyTG99IjA6dFmUNGBOHjVGbE4G2dfScTOTsh9xPqWa3xgagtFVPotDQrwMD/UJZPDItFVA2C8MkOmH1FLfhzML5uZ+J3VjPmUe5ORDkNuoMaZhh8fno4eVXUEO06gtDshO9sju+cGBy8fruZBB1HOWPVnElGOZ2JNxM+mR4aUGM2fjo7j321TS3KMfE9M5XKYOgRFEnBtHMaf5ZoBBEhO2AUgnBOEV7/qwATfc1CnGXmE9IjyVkOsKpd71xTRhB/3an5+AfvvfElU9yc/nX3XkiMy3bU4YI5a+pQGvZeI4LQ6xvNjuH6RSf8OFrzdxBhyIb//jyUkG2+JszpRTVVDYJQR3+fUNzu0TwJwp3MWN8S32k4ykIaDslMCWrv6jsR4Os8SaGMyEG1YqhiorbO3huIcEr+zcWYUhd4iJd4B6FZgFX37gFIa9LohyuDmwhOGl6VwtV5ou70dW13dPS9my1W1m5OJsdi1L9vP+zUnV/18sStrpwgUQgi0kkoKkFoTje+xhqaS2dtWe1JE/wbwFKRqCM+jqPpIS6CKHDq058g9FEagl5uRBCa3bzxBZH+chvhx7bCk4fWISoiskUVL4OKSYVBeBrgJ8HYYCH2w+3bd/kfU0uCKhIE1GmxaYJuIsZRBmBlAN4MxjezU5nbouTYDmhb3Wd8VOPtqRJBnZcaHlBWHKFpbE0Ioly7rIJFokSC8LF0MRCHQRFDw4OgljQm6EWpfz2nqSgEEUmbEJUgNBoT3/VK45ejvdQuwxoSJJIC/E3mv8FsUeQf/OitKcJqmfwebCuvYXGVIK4gpILJm0otU+oldanvryZBqHdFD+vgjFDF/UkzrE/l4+1EHbdjyrrT85drwidEvgsx+UCEIKJKaLr8fCcIZ4xeJ1aNmklDJL4nm3lLEBpriuJmVWGtwFOI7phdzPG/HJ1tNILIY+Y4wmVxIjH+JWd5ZRISIKPMKSfGd/tSlBNSQDKn0PzTOhkLQfjMfDlBKGBCTyAay6QC1VGh6t1fdT4vCcJHPVSONTffhu9ltd4CKrqZVlBn1WVgBpn1SodKhDvItu4fGVmnAsfNUmE0KkG4sXNUT9tpMUFFN8VhnrAJXpgjee629pywv5WJ/UATa+hpsvnE0dFkKuqkm2cEEbqgRcWnlPKNcILQ+DYUXD5rLp19c5uU67RqKjeT+W/SVqCKycfG+zkwFZFjmlUoBnVZ5grJEHxZrbmojnQ5FQaALhyI7pQiBFGApJPn20b2SBA+BNAiTeRTEy9sKP8a2HzbrOis0wxtZN3lJ2PTD8TEqihsHhWoQ0u8g9DEIZuz+zfd2DV3JJEJTHNpWzN3EPkxey0w3abGGkszv9AaTnOaS3llMFCx2HKm8z9sbgcShMb3IfRy2e+FPsl/AtvTEZQCdUHT1o8YOG+Fjr0wbwW0TlJCEMFQTsdIyt4AUI+rZOii1tm54mCbbBXRc8bKJlf/bmT55JDQA4GdMv1ACkwGA9K++r2wwJS7RILQhTT3C/wWNskr8fv0iS++EcDrc+37mnb6vV+zwNYcQRRYYLr8FgrD0gRHlVA4dHT2fpMJH5zBpIi5ZipP0/kf1p4vQfjEUoocI93dAV0GNcD/stpHxfUXi62jR0bWDYUNLuj3zs7lb7Uppkz13IuTj4laQfINtcW9v7mJl5km8Cilr6pupc1cp+8ALBWJcvF0dEfEYrDf742S6jeO1sXL/86yY8pkbyZ/RNCilssN8YPCwG10Y3Pc/mipuJp+IJokRqEOoB4MCpzaSnWU81GvBoa10e70p3Nn3EPA7q+oBn9tA7+ybP5OqdEIdLvhKJFPVV+jnEKiWiF5sSi2vmb9mSHCAstOAwMazfoXeOrw+dby4TpUUqInAfoFs31fS9Oz692bZtP5H7Yu+RKEzoqo1FguOp+IMM9VXcRI01g5foP3iZIJvwWtEU4QmlSxkXaFUXSsPgHbypq7wPQD0aXIjbJb1/r5lHiCUPNWc3qPvDHq6O49hRkqBEreuMA4+FzYwqFR//4qY1mHP7Bx3RNhdZ3ddFfv53I5JPLFa+4EMS2HxBEAqVOuE8BSEWEc8c+5c6uHrWH5Aeo0Igxcmh4e+DcT022nP+2JNyJGKm/F6/Lt6sjZdP6HycqPIHRBpSLrGTUv17WrigVcVvfEJzN7rWGwyvDlfkwiIBZ0wS8Wu9J5W/bUYaOjt271VmoEgtA58gQFw/NipF1oNbmifaKAZgm4dGJ8t8uiWD4FTe4IH4huTprGPdI7FpaBIHQnXOV5O9HCic0bkqF3gDk1kAqI9zYXTj/LTk4dVg5/lVIWO90iFzFYX6S1qNgThHPSaV25l9WUVbkrcjjyGDMuJyKVWjQXJsQsvL1vBFziY1JDSZWKNfBR36hmLRxnWEelh9cNuitHmP+B79QShN73IVzHFjZAB/DCGCyzsj/p2vAPERwtraLSlTfZ9nUu783861RmsBU693hVoBEIwtnVFQaIy4L4gtRQ8j9CdjgFIb/9dlU+Yc7LntAmygeiVzfyYCaOld74+K75mU/L+p2CpEllIIjpgHa9V4LxidnfRLgKzslWZtGaWfpuQOWRWJ0eGfi6yXdqUEbXv1B/lZw5cz+ApZ531OQJQvXRo056nggbmXFsrv+RTtq60PIMPAqLjktv7P9VAO76+cZ8u8qb7o3GEGX+B8laSxBa3wcDHZvBpHI8dRdsx48B6nCVD738bu9OHAImFVfGHZdHNZF9JeXpAwS6crLFvte7u1InhoULX3hL1sk9jV5NBrTQRbBRCEIXIhpAhhhrM1NTl+h2niqHMzVNfaEgeQ7hK6mhgU+6iUWf8AcP2fHMkUHpE03mlcmpzy9h0PRirMuMpt+AOP4h2kRJuV6UhyDgcwpQkP43I7Za55CoEtITkwr0p+6RZp4opw9TvH02bs58yWaaLh4b+/509sHph9oXr3gnbPsGn5SuNUsQPsnP8uMystbLF/Y5Baift4H5PNi4qSCHhH+e9K3wOX1UjCD0MUOipQsNm2Aa/aqaPzc1x7esCrJOygnqBxqrF/eX4DLDZZWWcO+AnK8ZEF+4/964MjQByxTdDsL7Zl40zy6p8+PS7XByv6mwGo+BaAxMEyBuBnMrQG/UmLhqo9Pq5R42W8J/190ZRP1AAtNAAk8yMOykW/VPteqeg2XLSR2wMXLSU4Kx0UnrqeSxI92mBzT6HSz7uNTG5C/D0YxWIqB/4yD8Aky/DE6HOvO+miUIn01tjvboam+azjAE/e5Ac/VmcJv+t/0OHzNydVr7VHoouVb3vqjz36/PBScIre+DweIdBor7d59gZEY3+gFqoihdUGWftplPHxtJKv1iYGyfRjlB5Hd6msxVUbB9iC3q9R6XAz+yKK1rypaDIFSzjpwzljcTW1jvXiRgLUP5g+TyVZTpBJF/sb/FV1jX1O+KHOjE1MZ1PzcpXUwZn6i7gU0x4ccWkHGpamqWINRANJfy6s9FX/pPfw90LeBoNaI+oXHJKkYQpWSBMx1lgId2aBhw9Q6Vle2pLXiPbdNlr6TIfHfACUHXpecJ+M/sVNMazxHYt/sNRhAODrmInd/2UQfosBpn4Js81fSvOlx9Ek6ZTpmwxeb89NDAl92Fiv1AnIx/z5D6aL8K4LXBHeRHyLZOy1q2bYHuqxRBqD7kVHmfp2kiWmgAnJ+qx6Bq9CJq4xbL2lcR4biQ7zEDpqtg259FnNaCsSr3tpomCP3GOTwqdRCSrrl2hds8PKiOsuBk4jPGhpIPB5Urdv5725x1gvDZ5UXSsZlOLa/52HS96IA7F+rxzNEgej9A7wBYfdSvnunH9DH89wT6KTGS27fvujmqpUwjEkQOPzqkq+/v4syrmHA4CAe5Qmyo4Hx/IuBhEG6YaOYfBlnXVDJCablOEF6CmczSccz8ERD9/cy4nfnEmxi0dmp8t7vVXCp3NNegb8hRT0zQMWCcxsBbPCrULa/kof4tGN8uY3Rd009alaPW7sSbLdDHwDgUwIE59aOjnmRY67MWfSNvClur0Vx1A9b5ppRq9p9/j1Jvxlu2tcZgncFkdwK0v2sT8CLAf2TQnTbo25uG+38TpvFQ7VaEIKLMBCkrCAgCgoAgML8RCA33Pb+HL6MTBAQBQUAQ8ENACELmhiAgCAgCgoAWASEImRiCgCAgCAgCQhAyBwQBQUAQEATMEZAThDlWUlIQEAQEgYZCQAiiocQtgxUEBAFBwBwBIQhzrKSkICAICAINhYAQREOJWwYrCAgCgoA5AkIQ5lhJSUFAEBAEGgoBIYiGErcMVhAQBAQBcwSEIMyxkpKCgCAgCDQUAkIQDSVuGawgIAgIAuYICEGYYyUlBQFBQBBoKASEIBpK3DJYQUAQEATMERCCMMdKSgoCgoAg0FAICEE0lLhlsIKAICAImCMgBGGOlZQUBAQBQaChEBCCaChxy2AFAUFAEDBHQAjCHCspKQgIAoJAQyEgBNFQ4pbBCgKCgCBgjoAQhDlWxiXbunqPIeCOmQqM+5ubeNngYPKvIY1QW9eKQwj2xwG8D8BeufJZAH8C+A+wYqvZtvcvsn3jMcyXgj09iVdNTNHtIAfPSj2/jVOme2jolmeKfcG7F684IJ7lo4h4OQN/D2BfAPFce+MAP8lMY0R0x2SLfe/mDckXin1XI9bTzQMGjk0PD/ywEfEwHbMQhClSANrbEwth4QwQJlPDyWv9qhZDEGoCb8/QGgJOAxDTtU3An2HzobZFBwhBmAmulgli0aIPNzW1bDuBCJ8D6B/MRuSUyjBwY9ayPvvAxnVPRKjXsEWFIIoTvRCEAW6JRCL21J+so5ntL6oPmQnnp4cGvlxGgqD27t4rwfhEUHcYeJSnYoupKXuIEISB4ADUKEFQx+LEe9nGNRGJwTvoF5noogP2tr+WTCbVKVMeHwSEIIqbGkIQBri1d/euBeOsfNFyE0Tb4r43k80/AbCPpzvj06olYoCbATz00k7Ny3d6eeJ9QhAGgqtBglCnhuaFz5//ikA/61IheQeTUynShPMD8a5g7OEz4iwI30SGP5lKJdV8kUeDgBBEcdNCCMIAt/bu3uvBWFUxgvDeWQBZMF8GG1/UffTFqLAMhjkvi2hPEITvpoYGTq/2gBU5LFj4wtUAf1jz7qfAuIabrJvTg+v+AIDdZRwV5JR1GBFfAuBthfXp2snxXVdv3nztVLXHVQ/vE4IoTkpCEAa4RSUIgyZnFWnr7v00Mb604488FkPTkcPDN22L2paUn41ADREEtXcn/gVMX/DcMY0TcAlneY3JCcBRdz5DZzPwRQALXaPNMmN1emTg6zIHBIFyISAEYYBktQmCGd9Ljwyoy+pZu0iDrkoRDwK1QhBtnYljiWidZ1HfysDJ6eGBDVEF19Hdu5wZN3ra+yOyvCSVSj4WtT0pLwjoEBCCMJgX1SYIzJEKxACKuitSCwTR0XH8nrbVdC8B73AB+BciPml0KPmjIkGltq7efyfg4ln1CV9JDQ18UjYXRaIq1TzTSQAJRUAIIhSimi1QCwTR3tV7NoCrZ4HEfEFqJKnUikWfEh3fCdu+B8CbXW0/nrV4yaaNycdrVijSsbpBoGwnCM2HOMt56JBDjt/DWhBfRaCTALwJwKtzKG0B+GcMWjs1vtvdxV6yKd3sE8/EDiayTwfjUAAHzliJEJ4D868J1J+divWPjd28JUhCkU0jPTv+sEvk1q7EIgt0H4DdTWeK23IqrP2wNgOxArYQ8CAINyyI8W0Gzn3a1y1amti1eYKOAeM0Bt7udfoj4GFm7s9OZW7btOnW58L6XOzvc02Kf+WIAAAgAElEQVQQCocF2/FjgDpcY3jInootDZuHJmPu6Or9XM4iKl88S0SnjA71K3VWyY93cxT1dFts/XLPnyiX1N3dJ+yT4fgQgL91APQ4uipijtl8JoFPAHBQTs2XszzDRiZcc8DenC7W9Li9PfFGjtEHCTjW1X4G4McY1vqsRd/I+7+E9bXUCVBxgnj55df8eUHL8x8H4d9cpODX72cB+kBquF8du412Vs5i9zQtJ8LlMwINRiVDROuniM7zczKaxwQR1f7+RRB/HhlcbXKBqmB3sMvS58E406Mf95NKhhhrs5mmi8fGvv+XUie0t/5cE0RbV+9SAtR8XpDvGzEuHx0ZuKgcY+3o6HubbfF6Av6HCHeQbd0/MrJOeXQbfT9hfSh2gc+3G7V+peZPOQhCjWl7hi4j4KMBJsq5ofMjZFunjY72PxCGcf73d/ck9o5N0dVEOM7PWTZXVjlKfq0lzhdls9lXB5GZ6bv9ylWUIJDNHo1YTJnl9UboaIbB56eHk1eFTXIT7+OA9z5NFp86ujF5v9GiEjSAOjhBKC9wilmXMliF8dB6avsPkcfsePbEscFbngyCob098TeIUT+ApRHknduk4VFYdFx6Y/+votYNKj/XBNHR2XsZEy509fElm/mIsZHkcDnHWam2oi7w3n5EqV/J+VMqQcDOno2YdT1ArRGwfpGZTk+P9N8SVqd98Yp3weYfAPyGsLKu3zdYnP2ETbHb/U47EdrSFq0kQTwF8IMAHel68zgIvwDTL9UixeCDCXirho232eBDx4aTm/0G6BxBt1OS4aiTvM+LBKQZ9DjIcTDrBOP1moVRK8CentNbJqZeXg2iv5tu2H4vkP9/5w+bAPrFzEvZ3pQaSV6X/3eYCqitZ8VBlGHlNZ0zU+R3AjhkxyD4N4D1X+5BMeO29Ej/XepvYe17wQi0vyc8Rwyl4lM66yCZPEx25qjR0VuUjX7BE/COcTA/ArJ+BuXfESgPHpxswXHljDM0lwTx9sNO3flVL0/c6p6jeW/4cqiXSv34TepHWeB17ZnWr/T8KYUgWJ3OAOW06PpGYbrG/CpjWYcHhUTp6DjhQLbiPwbwFg+G6qTwvwT6b/V3/XrJjwCkYrZNq6vN476ZiB+VJAh3BxSYly2I8zVenbbS5zXZ9nUFCz3R1amh/nN0p4ienp74ZGavNQz+iGeUTzPTxw7Y177dq/9z9IZZ+yrN8W0rLOuI1MZ1P/dDLOolddQFvMAPIsSKKWL7Pvb3/IjNOOd1++J+L1bT90VNykJGqYncp417muN8ou5eoq1rRQ/BVpM8b5ufZeALLXH+kq78IYsTr4/b9A2P3MuqP1fynEuCKNAPT3/BdzbHd04MDl6/3egLneNCpgu86bfjd4dR6flTCkF4xvYsM507tX3XAe99aWv3yrdbnP2+xpFxdWp44BodRk6/MvQDAIe7flc+LbdlY9a5XmIJWMemq9chQagF+PjUxnWjfpNIexogPIYM96RSyae89Vo7E4daROpY5XIUMlKDUHtXr9IfXjGrLvPtsLHST89ezwThcyG+AVnuS6WS/xew/lBbd2IVMX3NvegT4fTRoYHveeu1dfV+lQBF6NNPAMHni+QucG8DqGdHe+VdQOeSIHTYM7AmPTyg1Hx18VSPICo7f8pEEA8jy8uC/Ey0p4GARbuju/cUZlzv2ohlCbh0Yny3y/wMdnLhWi7iaRPn2eriOiMIY+/O9q7EEYCz6Ocv854nmw7zXvKo08NEZq/vAqysofJPFAchnf34uM28bGwkqSyLCp46Jghq7+5bA+bVrkEFqoo8g9dgxaOTLTjKrQbyUaUYhVL2yp2BJ+LI9gwPr/9dOVbQyAYHUV8acNrTEkRIoMeor690+WoQRDXmTxkIInCNcMtBY9b8uB3PLPbe4Wkt3EI2qzObKxXTa6cXbmTmvllzoK4IIuAU4J3YXV3L35BBbJCAA/K/6eK1+wS28z3C6T6g1taVe1lNWeW9OhPThoHvpIcHztCptOqVIJQaJ2aTCgKo7l/Uk/U7AfgtNJo2Jhl4v9v7V/vxMZ2SHulXx+3Ap7XnhP2tTOw+gNRd0S8Y9HAT2V8dGko+G1bX5Pe5JIgCVaCaXIRPpocGlAFGXTzVIIhqzJ+SCSLCwtvameiyiO5+RVOxc07I2jtVTbm/kM1HjI4mUyaTQ1mwseUE+dxzpnyEfpq8o9J3EMnm+NaTBgcHM2Gd6eo6afcspu5yWwloCaKz72QinlFxFLvjLLQu4Qcn4/Elmwdv/rO3r/VKELnwDsqCYvoYGoGw8xhMn9j2vAlAIv83jZkmtXX23kCEU1zkXhGrpLB55P295giizpLUVIMg1Mys9PwplSCimCZrNrtagihYgyIu7rpvs67uIJhwUXpoQPknhD6mAuzo7P0mEz64o8HidNYa+3Rfy6l6JQjvBCTgvr/u1Hz8g/fe+FKoQFwF2rp7LyTGZUGYd3T3rWB2iNutEx1n4HYCf7c5vvPgXFzMzjFBFPhAhIWKjyKXapStEkGg0vPHdH1RmOqMC5hpuYm5qk/9grXFsZTMvJQE6OiAjVeoiNu6e88lxpV1eYKIcpw2EaAO1GIv/UxVWgr4eiQI7e4CheazoTPQKVBghlsQbTZn+XQnAW0+bU6b7DH6OUa3HbCX/WixnqZmfZ4uVXOX1HIHoQ21Xun5Y7K+5OeVhiCyzHRM3sw8bP5p6hcQxKKela9ZkMn8BCAVZWD6K4tAQvk6bZ19RxKxSps6vTGLeAoJG0tFVUxRcr6aCFBbpsgPTrtL8Dn+1ydBVDQXszYHc2fnioNtspWhgcqnHPa8COBOsun6iYld/6vYECthL5lLgtBtQojxrdGRgQ+F9btWfq/WCUKNt5Lzx2R9CSCIUL8st7xMCGL67i2+0XU/qFzfjQw73O8qMIQQgpidgL7YI7uWIHzIRgiiYLnSEoQqFWqnrV/5VCa0b8cpc9nQ0C0qTETZnrkliMJ7NfGDCE7WVKn5U3MEURiPLRIJ5T8QIYjhAXV8cp6KnyB8LG+EIMwJIl9yOqCZ/XECTp1lZRG89PuGPymWMeaSIHRqPvGkNsvmV+75IwRR3BckKqZ8xMZp+1btEW++EESxp63iptZMLWrrWXEgTfHhsHgVGCqsiDsTmrf5UM/2KP2ZS4JQ/Wzv7DsTxO4sb2WPxdTembgEhMNBWG/Z9o+3b9/j0XKp7KqpYvKRa1nmT80RhKiY/Bdc3UQwEWA5L6k1/hS+F1H1SBA656Na0H8rL9CWlufelKXYqcToAznhkmc/Bl7YpiQx1wShc5aLYjIZNk6ds1U5Tyk1QBCzICh2/pisL/kXmdwhBMnFpL7yxaKm7EaaTn3gPHJJHYCqqQC9IR2KNt303P4T8GfYfOjoaHJHEL5cf+uRIFTXC0yCy3yBFbZ4GfxO7d29h4Fxg1sNVc4Fbq4JQkXRRQzrPUErQwO4GWDnFNFEIFBuBTc1x7esMvE/CntPYQgVMxWRale3SYmaTyKkf8bzx3R9Ue8zWeBLJQifDVzkMPAFJ9Qyf+N1pWJSQmkTRznjaK4a9cZWsmnJ6Gj/Q2ELg+v3fLgO5Sj3pIpiy2zf19L07Pr8AuScxtg+GkztABYxMNoS33qq6QLV1p04nZi+43pnURd2pifTMi9SoVDqbPwZuDQ9PKBypBSdt8EhHws3g2iZqxOTAC9LDSeVJ2/JjzeQZJR86bpdsg77asyfWiOI3AbOEwqe70IWy81zrxQ6sTa0matDEGoxsh338n1mjmYRTV11qRrnY6gNnSt+1IVJZbdCzAnX8boZvD0B50r12NaoYeYVQfjY+P/FYuvokZF1KnNZMY8+Sm+Zd5AFkYaBn1q8/ZiRkTuUmXLgo0uWpCWIzsSxRFS0x7/J/KlFgtDgEynUhu7bbHiCqFCwvsBdV72qmHx2mFtBfExqKLkp7AP3Cas+zrCOSg+vG8zX19j7R4r5VEAwgDa4WVh/a/UEMX3ydRZBlQbUfUEfGunYb8wd3b3LmXGjpz3jgHKmWHpP7ACMTqFOxFFdMDlNcMNqzJ9aJAjd/RER9U+8vOupYUYGvikPyrxBqDsVk5rYunDfKqmHZWeW+SW0yX0Q+nDfgG+eA1XPSxBhl4wR8zWgkvkgfLAyiZNEbZ2JXiJH9bNjUdNEm/QhbSMi0of8hnEMr7CFbq7vIPL9C0iIEymtq0P6cZwHpn/1Jtoi0NoF8S3nmKr2wrBzvjVt/nS6dnJ819V+i5hKA/zk0zgPRJcWhKPWEEQ15k8tEoSjZtKE+wbzxfvviysCIg34rWON7Umdn9ABCYNUBNCP778PD3jBVRdPWcSvYMYKz6QNXcgKLuqAwLjwtUQQAVhtA/N5sHGTV+fZ2nryLrH41KVMUAmZ4q6FxBerzs4V3TbZdwLYxVXeN7mKs/h0J95iMb4L0MGuOmXdBdcKQajxhWRBfAqMa7jJujk9uE5l7XPfTVBn54p9bCt7MphULon9vIu7MtaYaOFEObPxqXf4xLJSyaC+wVNNF3jziKvov1aWrvDNq+wTHr3S86dWCcLplyZhEBHWxZA5z+s4GpDMa3pKyAliGocypRwdJ8Kpo0MD64N2U5rLXlVcRah9GqAMMTYuaFr4kXwwuloiCAOs3GlgVXrVdwC0SJMGdpyJP5UeSq71wUpZlFwJhkql6n1eBPiXgJW7HOfXqs0TAJUq0fME705Ndr3uMhUP1pd/meGHmcu7rMKgHxEwFuVZ/ieA2AkQDuwd4jtyN7J8ckgCqKjQzZRv6+w7gYhvduVqyf+m+jkC0O98UsmOg+lqEKvgmtMpMf3zZ1R0/tQqQShIOjuXv9Wm2L2aEDUGKUcxOUsuhvPQdDLUpYopP7hp9QSpBatXk286DAO1u11lEoArQIC5d/Cs4HW1RhB5kliwna7NYRWGjfd3tRCclxoeUNnlfK1upndD1tcAVt7TUR+1K72hJc7n6FKURm0sX77WCEL1K0hNFHGcGRB/HhlcYWr5ErF9p7ijHtvp+cvBODfCd6Y2FB+N2bGHbLLV4hdGENOnlQrNn1omiGmSiBTHLC/GAYecwZ+ZkasQxOwp7ug7nyFFECqNaMHRW/NBZAj0zYm49W+63A8+H5Au/aZLJrOzoNUiQajOFoGVYoM0E58xNpR82GRxyb3jrFdOIEr/vJtJHQAqrex5OtWgYX3fYrVIEPnOTidjsi7KZUcM8i73ji/DjNtj4ItGRpK/LhUjk/quufNVAOoEGPDwIyCclRpK/rTgDiMk33ql5k+tE4QCM0IcqgwBl0yM7/alpp2eV+G+v5QXRrF+YX7CrOsThHtQjtVE8wvvBWElE3cDONClJtlCwIPM3J+dyty2adOtz5l8FN4y0zpzUnlg3+dRj8wKn1CrBJEfj8Iq3rKtNQbrDCa7E6D9XSoMpQ76I4PutEHf3jTc/5tibPVny6PgHeMAP0lsjWRhX5fZvvtYmNVGMfJSdWqZIPJjykUI6HnFx+Q4gLsAeo1nfjl4MdMYEd0x2WLfW+67BlN8FZ6TWTqOmT8Cor8HY49c3S0A/4xBa6fGd7s7L8+oBOGeozu+59LnTz0QRG7s1NqdeLPF1ocB+3CA3phbxzIAP8aw1jfR1DX5u4moBi6mcnYRTtQqUl4QEAQEAUGgFhAoSApW5nDyZTtB1AJY0gdBQBAQBBoIgcJUrRGdhsOwEoIIQ0h+FwQEAUGgAgjkVNHfnA5hg/8morsWxLb8yNSPRYUysZqyGwC8Lde9SJnvTIYkBGGCkpQRBAQBQaDMCHjvZxizjV3CXud1sotaP6x99bsQhAlKUkYQEAQEgTIj0N6e2A9xGgRDXURPP8wXpEaSyiopMIhje3fiEDCpZGp77uhW+aL45tsUgiiz0KU5QUAQEARMEHCiHEztuZYJypEw/yjH27WZqalLdNaWyjqwqeWFXiK+ymNuXNZEW0IQJhKUMoKAICAIVBCBIC9qZdYKojEwTTgOimz/E4j+QeNVHxbloOgRyAmiaOikoiAgCAgCpSOQC/utwq+41EXG7b4I0OrUcL+K7Ft0bhG/twlBGMtBCgoCgoAgUBkEInhR5zuQfSWeV9om/rBplINiei4EUQxqUkcQEAQEgQog4BCFnU0QsBygv53lUU94Dsy/ZmB91oolH9i47okKdGFWk0IQlUZY2hcEBAFBoE4REIKoU8FJtwUBQUAQqDQCQhCVRljaFwQEAUGgThEQgqhTwUm3BQFBQBCoNAJCEJVGWNoXBAQBQaBOERCCqFPBSbcFAUFAEKg0AkIQlUZY2hcEBAFBoE4REIKoU8FJtwUBQUAQqDQCQhCVRljaFwQEAUGgThEQgqhTwUm3BQFBQBCoNAJCEJVGWNoXBAQBQaBOERCCqFPBSbcFAUFAEKg0AkIQlUZY2hcEBAFBoE4REIKoU8FJtwUBQUAQqDQCQhCVRljaFwQEAUGgThEQgqhTwc2Hbrd19R5DwB1FjkVl0noWsP8ExgaOWesO2Mt+NJlMqkQqZXtUDuDmnbd1s20dC9hLAXodgFfPvGA6Rv+fABpm4EdTLbxx84bkC1E70N7dez0Yq3T1mOmU9Ei/yjhW8tO2uO/NZPNPAOzjaWybDT50bDi5ueSXSAPzBgEhiHkjyvobSIkEoRvwU2D+Imxcl0olx0tBpLX15F2seOZiEJ81ixDCG80w4/YY+KKRkeSvw4tPlwgiCADJ5vjWkwYHBzOm7fmVa+/sOxPEX9f8LgRRKrjzsL4QxDwUar0MqQIEkR/6Q2xRb3pj/6+KwILau/reD/C3Aby2iPr5KhkQfx4ZXGFCVoEnCOCJOLI9w8Prf1dCf9DTc3rLROalJEBHC0GUgmTj1BWCaBxZ19xIK0gQaqxbGTg5PTywIcLAqa07sYqYvgZgYYR6vkWJ8S22+Zwwkgg5QaAcaqYA9ZLqv5wgyiHwedaGEMQ8E2g9DUdHEAwcmx4e+GHIOGhRz8o9Yhn7b2KM94LsDwL0LgAxT72tID4mNZTcZIJLe3fiEDCpd+/pKf8UAV+HTbctWDDx5ODgbc/nf+/pSbxqctI6CBYfx4BSR+1X8C7mC1IjyS8BYF/VT8AdxHQduqk5vmVVKWqmAPWSEITJBGnAMkIQDSj0WhlyCQThHQK1diaWWkTXA9jX8+NDdjxz5NjgLU8Gjbu9PbEQFm4G0TJXuSyYL4ONL4adAFSdRCIRe+oZOpuBL3pOIKG7c80J4kUAzQAW5PrzeNbiJZs2Jh8vRn7O+GJYD9CRufpTACwXqYb2sZj3Sp36RkAIor7lV9e9LyNBODi0tyfeiBjdDuAts4AhfCU1NPDJoB18R0einS26G8Au+boMXJoeHvi3oHoaAeTVVN+adaIhujo11H+OX1tegmAgTYxJEBbn3pElolNGh/rXFSP0jo6+t7HlWC/lT0e3AugBsHuuPSGIYoCd53WEIOa5gGt5eOUmCIck9GqirWTTktHR/of88Gjr7j2XGFe6fn/InootHRu7eUtUDLWnEcJjyHBPKpV8StdewQmCcT+Au0C4Ykf54tVM7V29ZwO4Ok8GzLiQCJcLQUSVbmOVF4JoLHnX1GgrQRBqgG1diU8S6MvuHTwBl4wOD3zODwCNiqck09KO7r4VzPw9Vx+eJ5sOGx3tf8CYICy+AEy3uXwWilIzFaqX+C6bcblFpHxQ5ARRU19FbXVGCKK25NFQvakUQXR0HL+nbTXdS8A7dgDKD07G40s2D978Z5MFmhnfS48MnBZRvTTTtMtiyALoJQZnYmx9cGRk3ZDJ+8G4f7Ip1rcgk/mOyyy1KDWTRr202ganLdB9QhAN9clFHqwQRGTIpEK5EKgUQaj+dXT1fo6Bz7r6+pLNfMTYSHJY1/+Ozt5vMuGD5VAxFYOPTsXU3MTLJqask92ObQx8Jz08cEYU4vKolxx1W9aym4UgipFUY9URgmgsedfUaCtJEK2diS6LnEvnnfODZsL56aEBpXoqeNo6+04mclRC+ScL4gtSQ8n/iLIYFwuwH0Fst60DZoXGCLnL8L5fp15CFsvtGN4iBFGstBqnnhBE48i65kZaUYJoXbkXNWU3EvCmGYIIUBsdsjjx+phNysrn9S6gMsRYm5maumTTplufqySAfgQB7JzxeD9nmfmE9EjSKIaVTr2UGh64prUrsUgIopISnR9tC0HMDznW5SgqSRDKgW1iim4H4X0z4DDuV2qbwcHkXzWAUXtn4nwQfUHzmwqbcT/Y+tZki31vMcH4wgTkRxCqr14HtyhqJp16SVlzCUGESUR+VwgIQcg8mDMEKkkQalAay6TfxinTPTR0yzO6QS9amti1aYJuIsZRIaA8SUwbbOJbpuKxlN/FdxRggwiiIESGoZpJo166szm+c2Jw8PrtQhBRpNO4ZYUgGlf2cz7yWiMIBYg6eWzP0BoClAWTN3SHHjMn5LfyW6BksSeMIILQBNkzUjMVqJeYzkqN9H9DDUIIYs6nf110QAiiLsQ0PztZaYLo6Oy9jAkX5tEj4M+w+dDR0eQvQhCljsWJ97JNXwXwtojoZxl4wCK+dL+9cbdpfooggnBOQ94w3SGe2apOW3fvp4mhYkCp5xm2aEk+wq0QRESpNmhxIYgGFXwtDLvSBNHW3XshMS5zjTVSOAkVW+mJZ2IHA/aZBJwYMS+EMn56BISzUkPJn4bhHUYQmkisgZ7ehXcwPKNekhNEmDTkd9emSsAQBOYGgUoThOYOYtYuOsqonUB8T1kH2Za9jIhOBOOdhiHB1QX3hfvvjSuDThNhBKFRM00CvCw1nFSmvAVPwQnBpV4Sgogi+cYuKyeIxpb/nI5+Dggi8JI6Chh5wmDCUli8KoQwQn0qwggiqprJrV5iTcIhUTFFkXbjlhWCaFzZz/nIK0kQPT098YnMnjepKNz5gTLwKE/FFhcTgC8MLJW7Ot6yrZUsuoAYhwGIe+psY1hHpofXjenaMiEIUzWTxsS3IK6UEESYROV3hYAQhMyDOUOgkgTR1XXS7llM3QVQ68wAg/0gyoZDa/fKt1uc/X7hBbd/NFYTgtCpmV65EH+/N2ued/HXZaMTgiibuOd1Q0IQ81q8tT24yhLE8jdkEBsk4IA8Cir95+jIwIeqgUpHxwkHshX/sTs3hU7Vk++LCUHo1EwMrEkPD3zcPaYw9ZLcQVRjBsyPdwhBzA851uUoKkkQbZ2JY4nollm+DJ6LWgVaT89xu23PLFCWTksJaAKwd27HreqW9GhCfk/qdvzOwu9NOepz2ilUM82OUmuiXhKCKEmsDVVZCKKhxF1bg60gQVB7d98aMK92jVhr4rqoZ+VrFmQyPwHo7a6TxuWjIwMXlYqW5s5AJaXW5tw2JYgwNZNHdeQbHlxUTKVKtzHqC0E0hpxrcpSVIght4D2fHblmwYXyig6I2WSMZWvPCftbmfhGdwDAUgkiTM3kcY7zTTAkBGEsxoYuKATR0OKf28FXiiA8i2R+kKtVFFPdiDW5I8Zt5mVjI0mVUKfoRxNy3DernOkJQnVGo2Yai6HpyHh8amp2gEL/S3EhiKLF2lAVhSAaSty1NdhKEIRPTupfZSzr8Ac2rntCSxAdiXa2nNwRu+z4nQcnW3BcCZFbqb2790owPuFq0zerXRSC0Jx6nGRIIIy7QngHZp8Tgqitb6FWeyMEUauSaYB+lZsgdJZDALIM/nR6OHmlH6TKh6F5pxduZOY+T5kfIMtnplLJ/4sqjo7u3uXMuNHtbR2UFzsKQejUTMS43Lbwgiv2UmD+aiGIqBJtzPJCEI0p95oYdbkIQnk1P/kMDgXoOgD7ugdHwH0TLZwIOwm0L17xLti2OkXsORscfoTI+sx+e9t3mgTeUyG2KUbn5NKdLnS19UdkeUkqlXxMB35UgtBcgG/Otbto+r/+6iX1qxBETXwCNd8JIYiaF9H87WCxBDEd5iKzB8fiBxHTYcw4A4SDNEg9THbmqNHRW/5ggmJHd++HmPE1jRe0qv4UA98j4luaY1OPDg7e9nyuTVrUs3KPBTa/CWyfCsYKALt53jdOhFNHhwbW+/UjKkFoL9d3NB4aDlwIwmRGSBkhCJkDc4aAjiDK1xn6HSw6MbVx3c8jtEltXYlzCaRCZHtDZURoZlbRDIPPTw8nrwrKbR2VINQbCkKA519rkFBICKJYcTZWPSGIxpJ3TY22cgTBQxyPnZYeXPf7IgZMrZ2JpRbR9V51VRFtPcvMH0uPJAeCyMFZ7A0d5dx90PlZqN9NUpIKQRQhzQasIgTRgEKvlSFXgCAeIqKLTe8LgnBQHsmTGfoAA58GsF9EzJ5n4Bs81XT52Nj3/2JStxiC8FEzhaqXVH+EIEykImWEIGQOzBkCJREE4TlmJ9XnJsvCPdnJ2H2ViNLqJA3aYr2J2D4aTO2Akwdib08uiBcB/iNgbSDLvmPipd2HNm++dioKsMUQhFbNZKBeEoKIIpnGLisE0djyl9ELAoKAIOCLgBCETA5BQBAQBAQBLQJCEDIxBAFBQBAQBIQgZA4IAoKAICAImCMgJwhzrKSkICAICAINhYAQREOJWwYrCAgCgoA5AkIQ5ljNy5IlmZoWgQgTzk8PDXy5iKpSRRAQBKqMgBBElQGvtdcJQdSaRKQ/gkDtICAEUTuymJOeCEHMCezyUkGgLhAQgqgLMUknBQFBQBCoPgJCENXHXN4oCAgCgkBdICAEURdikk4KAoKAIFB9BIQgqo+5vFEQEAQEgbpAQAiiLsQknRQEBAFBoPoICEFUH3N5oyAgCAgCdYGAEERdiEk6KQgIAoJA9REQgqg+5vJGQUAQEATqAgEhiLoQk3RSEBAEBIHqIyAEUX3M5Y2CgCAgCNQFAkIQdSEm6aQgIAgIAtVHQAii+pjLGwUBQUAQqAsEhCDqQkzSSUFAEBAEqo+AEET1MZc3CgKCgCBQFwgIQdSFmKSTgoAgIAhUH4H/D7YtySn4oWQAAAABSURBVLYKOmtRAAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-55"><g><path d="M 51 991 L 51 1024.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 1029.88 L 47.5 1022.88 L 51 1024.63 L 54.5 1022.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-56"><g><rect x="1" y="891" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 941px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">uPEP driver (amd-pmc) sends OS_HINT</div></div></div></foreignObject><image x="2" y="920" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXmcXEW1//fc7plJRFkeSsKqqM+nuKERZu0wGggJsiZ2TwIE8OljjSg8EUWeuPtckfxYBFEIIMl0S1hEkEXeODO9TDA+UETkg4DsRHlhUSaZ6b7nR/UyuXO7bnfd7p6enp5z/8kn07Wd76mqb9WpU6cI8gkCgoAgIAgIAhoESFARBAQBQUAQEAR0CAhBSL8QBAQBQUAQ0CIgBCEdQxAQBAQBQUAIQvqAICAICAKCgDkCsoMwx0pSCgKCgCAwqxAQgphV6hZhBQFBQBAwR0AIwhwrSSkICAKCwKxCQAhiVqlbhBUEBAFBwBwBIQhzrKY0ZUdP5AgCbqmiklEAzwH8LBh324Rb9tkd98VisYxJme094QUW6C4Au5ikrygNYW1yKHqSLu90y1+RPFVk6ghFPkeMb08UUQKbKqrJZq1nXdW2VfI3FgJCEA2ijxpMkDpJngZwzl67c7QcUTQBQVQlf727QT0n7XrWVW8cpb6pRUAIYmrxNS59igiiUH90bA6fvOnu2EteDWpSgjCW31hRNUpYz0m7nnXVCB4ppkEQEIJoEEVMMUEAoCvGRndavWnTFeM6kZucIMrKX+9uUM9Ju5511RtHqW9qERCCmFp8jUvXEQQDR6aGo78wKWTBgpNbWlu37EZBK8RsXwDQO135MkQ4KTEUvc6UIPzUb9LGUmmmW/5q2+83fz0n7XrW5RcHSd/YCAhBNIh+qp0gnWJ0dobnkkVrmPBJ598ZuN+yxxcnEjdudout20HMJIKoVv56dwOZtOuNuNRXCQJCEJWgNgV5akkQqnkLDg7v1LaVYgwc4mhuhpmXpeKxIm+pZiKISuSfApWWLFIIot6IS32VICAEUQlqU5Cn1gShmtjZE14C0M0AWgtNZmBNajj66WbeQRRk8yP/FKhUCKLeoEp9NUdACKLmkFZW4FQQxILelW9sTad/DdD7JlrFuKethY8aGIj9w9nSZttBZHcRPuSvTGuV55IdROXYSc76ISAEUQLrokHsMbl6FeEn/1QQRG9v+PXbxulmED6yvY08EkDL0uHh67c0O0H4kb8WQ+6AhSv2DnJmBWysBGWdBOYCSDPwR4Cv4fHWK0dGfvayqssPQbjTFs6G2tuP25Faxs8j4OMAdgMwCuaHmHCdPZZeu3HjjS+Y1NXVFe5ki34FYMc8Dv+0mZeMxGPDfnDp6Vn+1jQCAwTsnc83xsBHU8PRu0uVk9VT2loK2B8H6IMA5uXTpwH8lZiGbIuv3Hs+p8rd5ynUEwot2z3NwSEAb8v+bfvY/WfXwkiIbXwTQDuAIIDnAdzDhEv81OEHm5maVghi1hEE/hKkdGhoaMOzs5Mg9PJXM4DVRB0Ijn+dCaflJxyv4v4G0L8nh/t/2RGKnGN6k1pHEGRZT8Hmn79GPG/VV8a3tgV3CA8MXL21HBmp86rWrbgNoK5CWcT4ZiIe/aIfXDq6+44jYoeXHCfG5uAwr/s3ypkCQawG038BeEP5uvghsnBGYjD2P9kpv8SnI4jM+Hgk0NbyeTDOAhDQZDcitPLtbJ4UQhCzjSBmkYlJu4PwuQssN9Q7Fva9i2yOAnhPubT530eZ+eMW0VsY+O+JPKXCkLjCchDwaQZOAbCfR50ZIjo+MdS/3mQHodJ09kTOAHDx9vL0O00vGXt7T5qzLf3PGECHT5AM8JXEcPTLujwdvSveQunMeoDUKt7PlwHhwrFXdz7P606PKqyIIMADDCtO4M97kIPinJKE5qeRzZJWCKKJCaKzM7wngjQAxtsdYsbagpuPHRgYUNv3ia8ZzyD8yF/JgO7qWvZmtoK3aSbqDMAPAVZKlcvgDxHwbsfuYgsYCRA+WglBgPACGLsWCAdAHKBH87uJbgB/sccDB4+MrFOmEyNzVldX33vY4l/nTVUqm6/VdJ4oVf7d8+3aYoMPGRmObXJjWxI3xpNMSBHoZQbvSEAPgL2K9VP64mcxQeAVAG0TDhuMx2HhN9lybRwEwlsArE4ORy+ppC80ax4hiCYmiK5Q3wrm7JZ/YjvNhHNTQ9HvuMVuRoLwI7/fAa4uJra97qVrmbnPmZeAu9IWn7JxMPaY8+8HHnjMrlZry1cpt/IvNm/42EFsL5dHOBhYkRpY/3jhb2rXNJrBPiNDsQcLfytnYlLpdDsAL483HVad3X2ngPhHjrbdjgyWJ5MxFURy4vN2v8ZNdoDPceOmrsC3h1a+1+L0TwD6kKOoDIM/lxqO/UDXHg1BFJKNEvD5PXfnSxznGdTTs3zfTMZ6MZmM/Z/fvtDM6YUgmpQgurqO2c22Wu4k4P0OEV8mm5ckErFksxOEX/n9DvL27vAhFmVdiNVBdPYjxpVs85nuSdFRNnWGwp8F07eKSMInQTDwMILWoU5y8JLBhCBU3mJC5d+PBYOLNg2s+3spfLJnCQHcANBSRzrtaryoLUAGzOfvtQe+W+oAOn+QfSnAqxx1PIEML0omY4+42+dJEMxfSMZjKopuyTMMv/2hWdMLQTQhQWS9aezMNQD1ThKP+WblYaObwKY6FlO5W9m19OKqRH4/A7y3tze4LT1vLcDHFvIxkLLHxg8veA55lad2Hi1zX7w873m0PZlPgqAS9n133aYEceDC8L4Bm5SZaN98GUZmJrd5ioEng8j0Dg/f8KizLe3tK+dZLRnl0eQ4ryltKnLmz+/CbiWgY4KUPXDwIIjHMhYv0uxS/Kh/VqUVgmgOgqAFvSt3bUln9ifC8WBEnCvbvIhbGNbS1PD6EZ3IM5wgqpbfz6jXuHNOOhQuV5bG3g/4IwhfbqimBKE2QR09kZ84ycvEzFR8wE3XtwWfP9F9zqUx+XnuALwwNN3leBCE9vytnL5m8+9CEA1MEDXsmBkQfyE5FPue19a6EQminvL7qaujO3wkEW0omIm8VsxeZeZ2ILtdDyA8kcYfQTxmB9MLRwY2PGXSbh8Eobt9/4DzwNtdn8ZTzIssdeRzVWo4+gk/5h4NOWvJUkcQTPhiaiiq7j/IZ4iAEETzE0QaxOftNR8/KGXjbWKCMJLfcLxkk3V1R77BhPO259l+58C0nI5Q5CxibD9g9UMQPl11/RCE5vb5GMBHJYdj6iJd0VfUbwiPIM29yWRMPVY18fX0HLtLBuO3O91amXB2aih6oSlmKl1395FvsGmOinB80EQ+plOT8f7LneVoCcJHdGQ/bWrmtEIQzUsQ6qnRlE18stOjxUvcRvRiqnLg+ZLfR13U0R25JmvKy3/qcDoRj/6HjzLQ0d23lIjVRJfzaPJDEIAvU4kfgtASINHFyaH+M3Ur/eKy9Wk1K39V1R0A/dUPbgxuIeBQAHs48C+61KchCF9mOT9taua0QhDNQhCEF5iz/vEbLQt3ZMYCdxX84E068IwniCrlN8FIpdFdvvNyHS5Vpmbl7f1ed5XvV/smiOLQG1ozk+YGtueh9pTuUDXkqiEIz3sZprqfjemEIBqYIMp5/tSywzYiQdRTflMsZwNBaGTUmpmKYzh5374WgjDtYY2VTghCCCKLgBCE2cCcDQShkCjyTNKYmbp6Il9m4IIJU08J11shCLP+1WiphCCEIIQgfIzK2UIQRa64rsNnzaGz5yVMjwXIlJp8xMTko1OXSCoEIQQhBOFzLHWGIleDceJEthIHzF5Ft3eHeyzKhtjeIZvGzyG1z/r8nkHkzlqKXHEnvUZY1H6wNrRGQf6urvD+sOguBt6Y/1uGmY5Ixftv9wm/UXIhCCOYyiYSgigBUVF8GZ/uhV3dkR9Pehe6RP5a3iQuq3VNAjExmaPWEYqcR4xvTOTw2S9UvqLQ2A1GEKqN7ktpDEzcW+joiVxEgPJsKnwlA92pW9TUkhkk4B2FDJUc7ptqSQjCFKnS6YQgSu0geiJHEOB8v/k3Fm89Ih6/RUWGLPm9b/GqHV7/6rYbJ70JLQThidl0E2Q5fTp/L3JRBZ5lixalBvv/ZFhO0aWxRttBKDmKQm/kzUxjbcFtrpcKy8qvCwaIMrsOHZZ5ormDgF0I+LMN/Mmy+apEInafM70QhGFPLJNMCMIfQRjfYNWEP3a+ajXpuc/sirKYjFQ0sSNTw1HlKz/ln+wgzCHWhRH3sxrWxDxqOBNTHg3qDPWtAfPq/P+zbqzMvHWSeczwXkZxSA68bLF1eDy+Xr38ZvR1hSLHM+NqR7BDrWutEIQRnGUTCUGUgKjYzoqSt0odRakVogrtfP6k4mUH0RQ7CHVi4Jo4lVymcYX0faMBTUxKqM6e8BIgG7W2Vf1fvTSn/nXcJDeOQ9XdvfzdNgXunHTJDbhr2xwOe7065+ww7b3L9rLSQXVm4Xyc6XeZsfHF7iCJQhBl536jBEIQJWDSrRRVvP8yHZo6usMRIrqqKGCeEESzEAR0kx3AA+kgVt47EHvOQ1DvvtGgBOEOvcHA/cRsg+gDWRk9Qmt4yd8ZivwAjM9M/p2ubQvapw8MxIp21oV0KqQ4WbRm0pkekGHG6lQ86niHIpdDCMJo/i+bSAiiNETFtuJc+pvSlnXmvYPrn3RmV+GIgy0tF3i+TSwE0TQEkdtF6N520L+brNxjt6bpP/O7ymAREA1KEKqd7vsOk9peIgyHTtkeuwC1J/ktI7A6Nbx+ozukR3sovB8xqSizE2G+c9zkvVgTgig79xslEIIoA1OJCz5pgDcB1v3KHqp5VjJDjEuZoN7ozcXXn2EEYdSDfCbystVP9xmMTzGyydXbDq1zX7oY4JM1+Z9iYFg9nQni94KxvyYE+/ZsjUwQxaE3Cu02NblOgqczFD4QTOpsbTcNUapwMYMA/Q3EbY7nQF1J6VFY9tHJwdgfdLoTgqikRxfnEYIojyN19kROf81f/bslB/jkcjIEfB12+iq2guoBlrcJQeQAaiaCUPJ4vHRWrle9QsBlDKgAf7tkEzcwQeguB+a1afTinA6MzoUrPgCbf55/R7scXhpyoI8lB9f/r1dGIQifkHokF4Iww5G6FoY/zDYuAeidZbL8jZk/lYrHoqHQsvlpDioPDSGIPGjNRhBKrHA4HHjqWVKPNF0E4E2l+wc/RLZ1QsaybQt010wgCCWPxgNJmXi+khiOftlsCBWnam8/bkdqGf8a5Yhy4unWEuWliXFZJt1y/sjIz14uVa8QRKVamZxPCMIHjvnnIpcQ+DSAPghgXn719wKY/0xEl7UG+KbCYVtRJxUTU9PtIJzdR620xzJ0NDOfBqJ/A2NXR//YyKDLxkd3/tWmTVeMN3I0V92Q0Lhtlwyt4WNYQUWFbdtGR4BxAgP7AZjvcGN9/rV3qP8Cxk8z4+mbyj3pWqhXCMKPBrzTCkHUBkcpRRAQBASBpkNACKLpVCoCCQKCgCBQGwSEIGqDo5QiCAgCgkDTISAE0XQqFYEEAUFAEKgNAkIQtcFRShEEBAFBoOkQEIJoOpWKQIKAICAI1AYBIYja4CilCAKCgCDQdAgIQTSdSkUgQUAQEARqg4AQRG1wlFIEAUFAEGg6BIQgmk6lIpAgIAgIArVBQAiiNjhKKYKAICAINB0CQhBNp1IRSBAQBASB2iAgBFEbHKUUQUAQEASaDgEhiKZTqQgkCAgCgkBtEBCCqA2OUoogIAgIAk2HgBBE06lUBBIEBAFBoDYICEHUBkcpRRAQBASBpkNACKLpVCoCCQKCgCBQGwSEIGqDo5QiCAgCgkDTISAE0XQqFYEEAUFAEKgNAkIQtcFRShEEBAFBoOkQqClBLDg4vFPbVooxcAiAUZv5qJF47K6mQ60BBAqFlu2e5uAQgLflm7PFBh8yMhzb1ADNkyZUiEBHT/hsAn0HQACgK8ZGd1q9adMV4xUWJ9kaFIGZMn5rSRDUGQp/FkzfUp2biPq3vbrTKuncU9NDZ0oHmxrpm7fUAw88ZlerteVWAjrUIosIqxJD0RuaV+LZKdlMGb81I4iOnhXtBPt2ALsAkNXsFPf7mdLBphiGpiy+o7tvGRGvA9DKwMMIWoemBtY/3pTCzlKhZsr4rQlBKNNS61bcBFBvVt+EHyaHomcD4Fmq/ykXe6Z0sCkHogkr6OwMz4WFdSA6SonHwFXjozufIrvx5lH2TBm/NSGIyXZTPIEML0omY480jzobT5KZ0sEaD7mZ0aLu7hUhm+xbAeyoTE3MvCIVj90yM1ovrSyHwEwZv1UTRGdn+O0I0K8B7JPbPOArieHol8sBJL9Xh8BM6WDVSTl7cy9YcHJL2+teupaZ+/K7iJQ9Nn74xo03vjB7UWkeyWfK+K2WIKgzFPkBGJ/Jq+6xjMWLNg7GHmseVTamJDOlgzUmejOjVV1d4U626Ff5XUSGGatT8eiPZkbrpZWlEJgp47cqgujuXv5umwJ3Atgjd/ZAFyeH+s+Us4epHxwzpYNNPRLNW0P2LCKAGwBamt9F3G/Z44sTiRs3N6/Us0OymTJ+qyEI9+7hZbJ5SSIRS84OFU+vlDOlg00vSjO/9q5Q3wpmvi53LwKyi5j5Ks1KMFPGb8UEceDC8L4BO3v2sG9OZ3w7MlieTMZGfeqQOnpXvBnpzDILtISB/QDMzw8IVVQGwHMEPMjM/Znx9E0mdtje3vDrt43TzSB8JN+evwQpHRoa2vBsQUHj3HIGwV4O0NsBBAGkAX6EYd2QsejyewfXP6mRhdpD4XdZoE/BxhIQ9s639RUADzPxxXMC+PnAQOwfPnFA1u7c9tKH2eKTgGy75+V2ZngBjDsZ1kWp4fUbFdj17GAdPZEjCJg4IGXCuamhqLrMhbzHzTEgnAHQewG8IS/38wDuYcIle8/nVCwWU3os+3WEIp8jxrcLCRk4MjUc/UW1deXuFwRPJMbxIHongLk5feOvDNyUsayLPPRdts0FvYGwkolDAN6c70/ZvgsgwcC146M7/8qvJ1JnZ3hPBGkADNVHleoTY3Nw2Ka7Yy+VbVgFCcLhcOCp57EfbOsTr9W1GMBb8lip0l4B+AnAuptB6/bePfNbU73qxtGBPX3/aoH/nYAjJ9WT7e/8ZwL1p8fGf2Yy3gvll+o/Sk8tc19cQuDTAPrgxPjKyoWHGXy9PZZe66c+p1z1Gr/t7SvnBVoyfQzuA9G/gbFrvh2qPz8DYASgWFvQvr2SecgpU8UE0dkTOQPAxY7CVieHo5f46JPUtTASYpu/D9CHfORLE+OyTLrl/JGRn73slc+LINLpwIuwrK+A+Kz8IPYqIq0O3LeN7vztwqDu7Az/CwWtS5n5Yw4C0+V/hixelRiM3WMoF3UtDH+YbVwCZCcvry9DRD/ntH16MJhpq9dNai+C6OrqO4At+5oybVaT2kMgnJociv2mHB4eA/zWzp6+jwL8UwBvKlUGAXeNB/mEewdiamKGmvCefM46nZi/4SAvXRFF+i7X1uxk+ixFAHwXwJ7l0gN4GqBTk8P9v/RhhqWOnshPCPh4vvwxgI9KDsfU2URNv85Q+CAwqTH9HrOC+SGycEZiMPY/PuRBeyi8HzEpmdRlwHKf0XgvRxA52fCj8n0VaTBdCNu+wMdity7j94De8PyWjPVDZl5eZu4qwPEKiL+GNC72IcskfVREEJrJ19fFOMW0ra978ZtgqElabZ19fwzcb9npoxKJDX/VZdYRBDKZwzkY+D4xDjOsMAPiLySHYt/r6lq2j20Fbybg/YZ5X2FgWWo4enep9NlVx9wXz2XgAkOlq+LutjjzGZsCN9cj1IaOIIisYdj2jQB2M8RD7SzPSQ5HLy01mRQRBPNRILydQGpXoXZ5ZT9FEtvmcBhbdnm1be5LFzH4ZMN+lmHgh6nh6DnlJjy1WECAfgZgSdkGTU6QIeDr20Z3/obpbqKjO3wkEW3YLgNd3xZ8/sSBgQG1YqzFRx3d4QgRXeXYLZiWayyPItSnn6UzGPhv//XQo7DoY8nB9f9bqmG6/kNEapevSFztGo0+Jtw23sbHltup1Wv85r1F1XhXFhafHw+kg1hZWDT5yVwRQbi8K9RYGgmgZenw8PVbDCqfFJJjUvr81hKwHsj+nbgNzO0OE9Dk5IwrW1s2n6YbKBqCeBrg3xcO/PIFqa3l3QD9DeA3gbDQsV0r1LUFZIWJbTWJqxhTuY/xOCz8BkzbAPv9AC0onsDKmgO8schte0u1TRHPuxwrV18kbaCniSRFBAH8GMBBBLzDUc5mBu4h0MsAvxVAt2ZAlg0d4R7gANSN4qMdZSkz4CbAuj/bP1Q9nDVzTlpoEPB5JrYLoV+0+gYO1uwqyp6luWKOTYYyZw4cVH2KwTsS0ANgLxfeGQZ/LjUc+4GJHnp6lr81jcAAIWvOVF9NvQU7Q+EDwaTMeG6yV2bCRG58KEsn78u5VX/BjFho/hgzn5CKx/pLyFOmr/MfHOP+vWDsr+k/m0F8RHIopsys2s+g/2RAUF6WcTV2S8gEpynVo7q6jN8S/U2Z/CZwK9HfKr5sWRFBuJVAjCsT8eh/mHT29p7wAgukAvipkBz5jx612T51nz1wj86m2d5+3I5WS/oLAH/WNQlvJpsWJRL9OUJxfBqCcP68hQhnbnt1537nKi5vT/88iL7omnDGVNiDXAH8W5tw4shQ7EFngQcsXLF30M4oc0vuNnnuK2kOcF2GKuR5BcxnjW3d5Rpn29Tq64ln8BGLrB/lJ2C3yHUjCFfFavL49F67c9SpO4X/1jT9JwHnu3UGy1ritRLUDPBCdWp1f7k9Nv4ll41YOUssBuMa1wSnAtxZeT1uAfPqvfZAv7ONnvou4Y3X29sbHEvPW8NZO7bz44dsxpnuPpw1Qz1HR4Bxhcs89ozFmcXx+A1/LDduNH05w8zLanFxrrf3pDnb0v/8GUDLCu1Q4T3IslYkB9ff595JZXf/c7acAKILJxNF6cVQVyiynBnXuib9vzHTWeNbd4q6d1M5mbEaRF9y5XnADqaXjgxseEqHW8n+w7jJDvA5bjf8bD8I4hww/Zerrz5gjwcOHhlZp4iy6KvX+O3sDn8CRJc75iS10Pr0tld3vlqzC6XOhSv2h61Mv5NMhWUXPjoZfRNEvkPFADp8okMxHZ+K96vtdrmPOkN9a9RgdSQ0vXlNHaHwicR0pXPyZo+6SxBEyVWI27XQKVDBdOG17ezoXfEWpO07nCtrBtakhqOfdgPjDqeQ/30zLOuY5OD6hBeQXV3L3sxW8DbNVrPuBJGNE2TR0anB/j95tNfDdOFtIvEY4BOmPi/Tj+ZMrNCkkvrOH1xe7rDxqyp+PxYMLto0sO7vbrmKd8/ZFHcjw33JZOz/vPSmXaX7cAvv6IlcRIByIc9+Xv2q3AB0/96xsO9dZLNyNtm90Ae9Fl3OvB3d4T4iUpNQfuGEMQY+qjOp5hZP9h35HW+hmAeR4aPKRVzo6IkcTICaWyZ2Nwx8PTUcVcRRFMrHs/8wn7/XHvhuiUN13W7Ak4jrNX518y2Asue9fuaiUn3GN0G09y7by0oHB7d7L+GfNvOSkXhsuFznXNC78o2t6fSvAXqfI21ZYQtpe3qO3SWD8dsBap8YKIQvpoai33TXXYIgytbX0d13HFHWtdD5Ga343AMZ4FvbgjuEBwau3uosTDPRZIhwUmIo6q63CFZXYMTC7/UmiC0Ma2lqeP1IGb1TZ3f4XFA2yu/EpO01CekHeHkPOY0ZRtVl5Baan4TUwXFhsnuWLVqkIb6iBY6fYHoa2YxNRZo++RuLtx4Rj9+iTJEVfx3dfUuJWJmXciY6xj1tLXxUOe8X3UKKGN9MxKNq9z3p05B3WVPRpLESihzPjKsdC0NP3LT9h/lm2FhZ7qBWeQdZLRllup04pGeP+aVe41e1iVoyg45Fp/E4L8bd11FAVgX+CaI73GNR9nbnDnklPmYH0wu9tnxORWe9gAJ0OgPKxWx/EDIBzhw6PHzDo6Y9vDMUuRqMEyfSE9Ymh6LKLXTS50EQRgNSZwZTAdNSw9FPlD287O47BcTbb7t6DLiu7sg3mHDe9kaXPa9wyqfbiRl3HFOsC+ncZxC5nmN+KVK3gvSy72oGuPLcOj4x1L++VLu1+iY8gjT3JpOxp0vl1ayitVgWu5zCxE49UXWxa7giMDoiFe9XUZBLfu1VjLuSsrtcmP2cJ3aEIucRZ3c1TwF0H4NvLrgkF+rMB/K8DaCuwt9K7QB0bdWVAaZTk/F+ZXaZ9On6j6k5TpkPt6V3u145v5WbX+o1fjXu7MYL8pyXId/IwD8B/M4C7uMMrylHlJMmmnIds0gBuVDEjvj0/lnJb53O9NURhH41726PbjXqZcoqwsc94DQEoZvMvFZfXlhpJox6EoRve6bpzkozwL1W864FgWZwA7G24OZjy3n7mN4p0ew0PM/AdHpTE9DW9G7XEqAmy01g/gMHrPUlTHQTxWj65Itk0+JEov/easZTfhJR0RB2zpdj7JVkUq9msVVRPy2ekPW61bhJPxlEptd0EVpUj2YBWs/x29195BtsmqN2eAdtx7tyryQTnVVHEK6LTMou/4/XtR3z+zuvVSw15V81BGE6CWsmDE/7aiUEoRnsxuUX6qtm6+lXScU7CP+LgvwbBxMLC2Wa4fHAQvcBYDFBmNfl7humdnpjgghFziKG0/OoJmYeE31o9K0M8BOXCE3KMF6dZxNm7678lAOBWGpgvXIlryh0v9s05qX3cu139x+vcyLNAsOXjoryawii3uO3qyfy5bwbvBOmF0FYb9m0duvWnTaZukyXw9n9u28Tk+kE7bchJdJTd/eK3dmyP8KM4/JMut2f2YeJycBtLdsM0wlD1+aiyVSzg3Cv2gj4O2w+JJGIKa8Ro+99i1ft8PpXt6ntY8H1tqKVmUllRW6ujOtS8egJfiYN05Vk0QA1tIkrOYoIwnHju5ScpvouKr8CHEzw1qXRrVqZcHZqKKq8iar6uopt/JPLm7jJj3Xjc3iw3N0AZ2bNyv8ZBu4gkM9nVFndTj+0UDYD2p1BkYelzwWsCUHUe/y6I2ZrlD0Kwn2waS230B3VEHrDEoQxSPg7AAAbC0lEQVQaAK+mrT0CxPsB/K/M9EECDnCELdAPAj8EYehtZTphVEoQGpv+pDAgpqPdNWEVEYRGDpOii9qiuSindQwoVbhm1aW1pWpWgEZmojoQBHV0R64hwvEFOf24d5sAXyqNB0FMhDyppvzcZS/jC4WZ/O5ibZoC68uFJylaUFbT0Ml5tQsikwm+VBNM8tdr/Drbmd9BqYN69x0UnTibQdjAbF1dZTgUf4fUfg5xDPpBNqYRMX2WCEdqLqgZFJE9Zjc+pDbdkgtBbI9ZpZRQKhaTmZK0uzKticRkgHrVOZU7iKmcoE0w1LqXG+6QTMp3hA25qFw4E1d5DxDR+XvOt2/VuZAKQXijX26B587pM0RJIfuLBHw/M96yplRoIq9W+jIxeXiKaCfoUp1SebUEMvaFRNkbsn5Cbagwx6rN2+PxCEEUPLrquYPwvXLV7WZ0hC0EYTyh+PKgMiEJlWZ7QDucC0C5k5uEN1GXGK+ZE+Qz3e6xQhDG+jQ1EW9fWAMqJpzJjkI14gG2KGLiEOFssU+CMHcD81zlLVzxAdj8c4/bwM5szwP8FwIN20wD4y3WverikukZiHbFZ3ioJzuI2u8gTF1JG5cgivt+PU1MmjOnKSEI5wBUu5at6Vd7iLAcDHUx1h0yZNIwJ9BlrcHnz3R6jZmOV1MCK5eumv6T3S27nHB0ForpMDHp5M4Gonzeegdl+Ggm9BHw7jKEXvIWuq4OXwShCqhG4Xl/5ptc4ShUsU8zcB1g/Wo8SA9sGlinnlXUek2Y1t/IBGF6YFtqMGjMfaYrkHJjrOh394CoZGLUuFNq3VdNBuh0mJh0fZ+n/5Da907Ot/IdGXIXXe0Pvxby+9+LnEVy6Yrcfru6Iz9mwicLxUy112M1/ceUIBp1/GbNkPbWD4LtVWCo0Cm6QJplLwpXvINQGd0K9zoD0HVE1+MnKokKnPVjpPls08sbTUEQxbfRfcfW0dwqrxtBeN0OLzX5FN8E1oezqGaAT+UZRH7yUBfDVNjwwufLhTJbhronQ7gKzM+B6LcqsF9bcPM15e5qTKUXUyWkoeKjUXD8EuehvSrH7VnV4XYNNry8WEmbTCf4kv3UYAehiSbRcOM3e6b0DE4C0f9zxrLyS9C+dxCVuiHqDrgZ8PUQu/bSyAw8g9CaCzxiNnl15lqsYkwHoWZLbXQj3VG++02DbHRJ3c30hiYId1gKwOgSnxNn0wtfbt2YnuGY6jS7I8o9aboEoEWKuxjYjZmPNQmbo/JndxSZzG3grLdh7nONR83lwores8iGjSB8xUGs9yLDP3UvLKvpP6YEU8/xmw2rw5nDiKhTPaaWHzcqqKDJp8bdtwjZ86TC58tj0j9BFN+k9gxs5pRAG0fJ56TY1dX3HraygcW2b51mIEFoOyLwp7RlHVrObbCAqebyTB13EDAKf1Foqy7EhFf4jGoG+FTvIDRyKBGNt+x+Qka4R7/pGY7JrFFIUwvPrHI7el18IyLq3/bqTqtML3flXgNsuXXyA0P6qAjV9B9Tgqjn+K10QV7QcbXnJb4Jwm1L9rqw4u6oukB9fmzZWV/t1710LTP3TSp7hhKEjuxMY9R4XJypJ0GoHcD9lj2+OJG4UXmWlfrcb5ertJ5hlKsZ4FNNELld8Ly1AB9bENhXsL7c4kq9b1EICmgcqmOqYjG5dzR+dvUeBOO+I6PTf9l3QZwdqqMnfDaB1BO3BY/HDJhPScZjPykiUgMTUanOatr/6jV+NXp/2WLr8Hh8/ZDJYqDam+W+CUJz5d8oTITHtuxhBK1DUwPrHy8lbC5eO/0ADPXmxCS3WK+DwkY+pM7Lqh04THx6aii21vOQPveSmXqYRT124/zqShC5iunatqB9eonIn9TZEznd/ZpXqRvtpgNU11+mmiBUnbpw3+XCwKt8uhfB1ALJ68Ert3ydriCQfm3JXuNLH76crhgb3Wl1uRW+JuS39vJjd/fyd9sUUPGe9nC0Qz0wdVy5Fxc7F67ocr9cWGpxUk3/8bODUJ2/MxRRc9JnHDKN1nr8anedwINkpw/zek1zYvegeX7ANNxQoQzfBKE9SzC88q+PKaJ/gEc1MP806UfB/C3Pt2Q9QjHMAIKAx9sOXm/wej0EUtDlNBBE1tUsxcSfcD+glD3EbBlX9s9TJr3fUebcqZoBXg+C8JgY8g9JBT8xMrTuD05yz11AU+FQSK12nROkUfj4gnKLvIE8QmubrCqdaTx25ipMuvZxnTzZzaUAnZmPD7Q97E2JsNqaXYAqapSBb/N4y4XuS1z5R3xW5x/xcfr6l9x9VNN/fBJE3cavPhSK/oGqwuIz98a99WPXdQJffS67BPTbobIdxB3S2jBqZomYIhkwnmRCKvdkJQJg+4MgeqfrNakM1CM1wNsc23StJ8lMIIgslt7PPebiqzD9odRTgg791ZMgnK+1qSZMesbR+wlWlH0HoJoBXieCQMknR4GnGBjOP73q9YytLxOLxjnDaNduOrY9Vvg5vZqNS5W27MNMrXNfuhi598HdX5qBPxLot9k6vZ+sVRfyvjcnuPl8L6+vavqPX4Ko1/j1eJwohyHhBWL8jkHqGdXcs7CED2oiU5R9dEvXXyoiiGIPGu8XuNyV+owp4sz+CueeAo1bzHcw8Mb8j9r3KGYKQWQ7pebVrHKDWz2qbgFpZhyZT1tHguABAv2GAaUPk5u2qutW9Oi8HzfqehGEwju39Sf1jGiknK5cv5c1QxSNmeJX30o+hemzPdnklfRBRz3PkMWrEoOxe0rVnbcIfBOMs3xGUCgsQi4ce3Xn80qZvupNEJVi53f8HtAbnh9Mq/fZJz1pbKrqNAFf2Ta687fLmQ3dBVZEEJrXpHytaDpD4YPA+JGn2WhyK9Xq4tqMZV2gPHw0h91aH+SZRBBKXB/hR9JguhC2fQGCdJnj8aT6EQTjHjvdcozVkl4I8E/LxO7xMplpO3c1A7yeBKEa7zd+kZc5rtwoL9qx+3isqVzZzt/VM5WUzlwFUMhwAk8T0Q3jROeYet+plULO/EEq5tPEy22l28kPkYUzEoOx/ykXQbia/pOd7Cs85K7H+FXzLgfogvzTs9tNe6XBe4As/rQJdjXbQaiCig7NfNpEHTFfVqmzPwDzHZ3yeQJ+z8z9mfH0TcWP1E9+11rnNjfTCCKvnGycFQv0KXA2jLcKcaxW6GmAH2FYN2QsurwwGP0G+/IzWUyaOEo8gpQ7axj75Gs7hBMcV/1HwfwQLKwLInPd0NCGZ03rrnSAZvuk67XBeoR3z+4mFpzc0jL3xSUEuPty1kRDoAHb4iv3ns+pEm8iayHSnPn5fqzJFPtCuuxkZ2fCBCx/zRFBmXPnOcoohMDpz4wH+t3veZjWlSXX57EfbOsTgH0wQPs44gqNAvwUiH7tNyJpNf2nGoKo5/jNzm1paynA6uU7FS9LnW0VdvKvvHbT/QnAuhuW/ZO95uFBv33OqcOKdhCqgGKfcHMzk2knknSNgYDJGxeN0dLma0VxmPTy73M3Hwoi0XQhUDFBqAa7vJIquiE5XYJLveYICEGYY1XrlK6H531dUKx1W6S82YdAVQRR7P1A17cFnz+xXFyZ2QfzzJZYCGJ69Of2gfdziW16Wiy1NhsCVRGExifc+GZoswHZzPIIQUyPdjt7wipO0s15l+4MEU5KDEWvm57WSK2zEYFqCaJwQ1TFR1KHTOri1NdTw9EvlfM2mI1gz1SZhSDqrzn3BTbZPdRfB1JjhRfl3MC5PAeeQIYXJZOxRwTg5kBACKL+euzuXhGyyb4VwI7ZG8fMK1Lx2C31b4nUOJsRqHoHocBzR1uUXURzdSkhiPrq07178Bv9tL6tldqaGYGaEIQCyLXi8R3zo5lBnumyCUHUV4Pt3eFDLMqePajLULIjry/8UpsDgZoRhDqw7uiJfJWA81X5fiJVikYaGwEhiPrpx/Us7xgzn5CKx1T0XvkEgbojUEuCcAcxG7WZjxqJx+6qu1RSYU0REIKoKZwlC+vojpxKhItzUQXMwm7Xr3VS02xDoKYEMdvAE3kFAUFAEGhmBIQgmlm7IpsgIAgIAlUgIARRBXiSVRAQBASBZkZACKKZtSuyCQKCgCBQBQJCEFWAJ1kFAUFAEGhmBIQgmlm7IpsgIAgIAlUgIARRBXiSVRAQBASBZkZACKKZtSuyCQKCgCBQBQJCEFWAJ1kFAUFAEGhmBIQgmlm7IpsgIAgIAlUgIARRBXiSVRAQBASBZkZACKKZtSuyCQKCgCBQBQJCEFWAJ1kFAUFAEGhmBIQgmlm7IpsgIAgIAlUgIARRBXiSVRAQBASBZkZACKLBtRsOhwNPPm+9gzL2ChAOBuhtAOY5mv0KA89aTAmbeMP4HB7cdHfspakQ64CFK/YOZvgwIl7OwH4A5ufeLch+aQDPEPBnJr6Lybp173n2w7FYLDMVbalFme094QUWSL1XskuhPAaOTA1Hf1FN+b294ddvG6ebQfjIRDmMe9pa+KiBgdg/vMruDEWuBuNE0zxF73RkM9bmDYmithDWJoeiJznbHgot2z3NwSEAqk9O9bfFBh8yMhzbNNUVSfnbERCCaNDe0N5+3I5W69gpYPo0gD19NDPNhDsZgS+MDK37AwD2kVeXlLoWRkJs8/cB+pDPsp4G8CVkeF0yGRv1mXfKkzcnQWCUmVek4rFbqgFQCKIa9JonrxBEg+lS7RieepYir61qLwLwpiqal2HGTZkWXn3vQOy5Ssrp7Az/CwWtS5n5Y46dQiVFPWBT4LiRoXW/ryTzVOVpUoJQcD1gB9NLRwY2PFUpdkIQlSLXXPmEIBpIn8o0sTVNawg4ocSErEw2zwG0Ldd0ViTyhhJiPEMWr0oMxu7xI+oBveH5wTTWAdTrJ1+JtJthWcckB9cnalRe1cU0MUGAQJe1Bp8/c2BgQJn+fH9CEL4ha8oMQhANolb1WH3LNrqeGIdpmvQiAz+xbLpszz3tx912fUUsYxlrkc38eQIO0JDLK8x0Uirev8FE3AULTm5pnfvSxQCf7EqfNV+B8SPK8O/GxnbZvGnTFeMqjdr5PPdcZrdxDn4IhFOJsRhA0JmfgYcRtA5NDax/3KQdU52mmQkCQFVvwpsQhF/9+D1j8Vu+pK89AkIQtcfUd4klJuRRMH+1rQUXlzrcdFRInQtX7A/bvgbAe1wN2QziI5JDsY3lGtjeHT7EIroZwNxCWjW5MwXCpmaijt4Vb6F0Zj1A7c76iHFla8vm0ypd2ZZru5/fm5wg1OHT/ZY9vjiRuHGzH1xUWiEIv4g1Z3ohiOnXK3WGwp8F07cmr/zpUbKxIpHov9dvE7NeNGnrUoBXufI+SHb6sERiw1+9yuzt7Q1uS89bC/CxjjRPIMOLksnYI37aEgqF35Rm/MJFEpvJpkWJRP8DfsqairTNThBZzAg/TA5Fz/brrCAEMRU9buaVKQQxzTrrXLjiA7DtXwHYzblah0VHpwb7/1Rp87x2JeVs0+3tK+dRS2aQgHc46l6dHI5eUklbtLsRwrmpoeh3KimvlnmakCCUp9hWp9tupaYmIYha9rSZW5YQxDTqzmO1XhM3RSVWV9cxu9lWy50EvN8h5stk85JEIpbUia6ZNP9pMy8ZiceGK4FKna20bsVtAHVNECDjulQ8qg7iq3XBraRJE3makCD+QsAaBv7bZR5M2WPjh2/ceOMLpoAJQZgi1dzphCCmUb9dXX3vYYt/7dw91NpG39Hdt4yI1wFonRCV6OLkUP+ZuglaM2m+SDYtrsTUVaivoydyEQH/kfe+YmIMtrbMPW1g4Gq12p22rykJwk4vYqvlPLeDAQNfTw1Hv2RKykIQ09YtG6piIYhpVEdXT+TLDFxgurqvpKnaW73AYxmLF20cjD3mLrOrK7w/LLqLgTfWwsRUSZvrlacZCSJI6dB4oLUNafsOl5nwZYutw+Px9ermc9lPCKIsRLMigRDENKlZZ3oBODE2B4fVOlRGZ3ffKSD+kUPUDBEdnxjqX+8Wv6fn2F0yGL/ddbBc9nB7mmCsqtpmJYihoQ3PdnSH+4hIebNt3zmCB8bm4GiT/iUEUVXXaprMQhDTpMqOhX3vIjtrXtq90AQG1qSGoyq0Rk0/v3VpdjbKMvGQzThznz1wTyPHV/IDXDMThHJSaJn74uUEfHwSJsxfSMZj3y5nahKC8NOTmjetEMQ06baju28pEaugcIVgd2Cm41Px/p/VuknaXUGJ4HHqDoPGRFFo1tMMXAeL1jZ6ML5yODYzQSjZPfS4hWEtTQ2vHymFjxBEud4zO34XgpgmPXeEImcR4weO6qvyFiojBnV0R64hwvGOdH9R9mpljtDlzR9uX10mjMcoCPcBfKNl27dt3brrw4Wb1dMEq69qdQThqwA/iesTzbVIp12hyPHMUHqcWIjAwNQkBOFHuc2bVghimnTb1R35BhPOc1Q/peGM855EynOp8D3LFi0qddeia2H4I2zTtQD2MIQpzcAfLcYv7QBd1+g7jNlAEMrU1Pa6l65l5j6HDjMg/kJyKPY9L1OTEIRhj2/yZEIQ06TgogEIlFzRV9vMjlDkc8RQtufCZ0RIKuw4tYx/Le+mOhF6w7A92RhSLZT+vtdOxbCcKUk2GwhCAdfZGX47AqTOu/ZxAFky9IoQxJR0uRlXqBDENKlsphBEAZ4DDzxm10BL68dA9qcAeqfP8N9qZ3HpnCB/0TCmVF20MlsIQoHZ0R05lQgXu/R2R1uQP6bTiRBEXbpgw1ciBDFNKpppBOGEKRfrCT3EVh8THwxgLxMYVfA4yvDH/MZ0Mim7kjTNfkjtxKSzMzwXFtaB6CinqYnBn0sNx5xnYdmfhSAq6VHNl0cIYpp02tUd+TETPumo/jE7mF5YzSMvpURxn3kQ8HfYfEgiEbuvWgjy71h0EGE5GIeXIYyGuVMxmwhC6bi7e/m7bQrc6TpTUu90LEkOrv/fSYTifv5U8+So334j4b79Ijb96YUgpkkHlZ4JVNhc315MFdaTzaYC/lmt6RO8nktl4Krx0Z1PmW6Pp9lGEFlTU0/4bAKpQIkOryYUmZpkB1HNCGievEIQ06RLzYPzGWY6IhXvv73WTeruPvINNs1Rdy4OcpT9G4u3HhGP3/JKresrlJc1awRxDpj+y/V4UMmAgVPVHne5s5EgcuZB+jmAQyeZmhirU/HoxG17IYh69cLGrkcIYpr0o7vdTIxvJuLRL9a6SR51XZmIR1UAvan+tO9dTJWsfoSZjQSh8NGFmAfwjMWZxfH4DX/MphETk5+u1LRphSCmSbX6IHpTE4upo7vvOCK+zimq7tZ27na3fT5gzQd4BwAP1WKX4RF36ta24A7h6YzoOlsJwtPUxHwzbKxMJmOjQhDTNDE0WLVCENOoEF00Vz8RN02anjXzBHADQEsd6bXRXN1B/Rh4MohM7/DwDY+a1FUqTdFFPYObxdXWWS7/bCYIRdptWynGwCFOUxMRTkoMRa8TgijXe2bH70IQ06hn7XsQRP3bXt1pVa0OcHUvunm9OdHREzmYgF86IoBmmHlZKh67pVqYOkKR84jxjYlyhCCKIPXr5aM5x/J12bIzFD4QTOpsauI1QwDZ52URpPPBOHGikeLFVO0QmJH5hSCmV23UGepbA+bVjmaMMfMJqXisv9qmqcttVmvLrQR0OMryPCA+cGF434CdvXG77/aJfLvZodL25F7O2+16AOFCGdwAr8rN5h1EXg/U2R0+F5R9D307FxD1M7MNYKUQRKW9vjnyCUFMsx49fdOJj0gOxTZW2jzPN6kZV7a2bD5tYGAg7S7b4wnUqglLKyPTqcl4/+WVyleLfEIQQP586CaAep2mJgCKIFqEIGrR02ZuGUIQDaA7D9/0zQwclxqO3u23iTlXRutSgFe58pa9pNbdvSJkk30rgB0debcw80mpeEyZI3y9I+1h6/Z80c6vrNWkF4LIodfRs6KdYCv36l088RQTUzVdbcbmFYJoANV5rfYBjBLwFc7wGuVZYtLU9lB4P4uxFqAPudKPEmFVYih6Q6ly1C5iLD1vDYNPc6VLE+jHARr/mmngPa+2+H0f2UTuStIIQWzfH+hMTZMwFYKopIvN+DxCEA2iwtxWn64AENE06W9gXEhM0T33tB93v+hWiI0E0GcAqNhIzluyqrhRZv54Kh6LmuwAurqO2Y0DLbeCcYCmLWkQ30Oga8nmwa1bd3m2cKDe23vSnLGxl+cxBQ4G4VSAPuBuCwF3bZvDYZNnL6daNUIQ2xH2OK/ankAIYqq7Y0OWLwTRQGpRLqkUsL7OYPXsqHuSL7Q0A+A5gLZl/0C8Exi7lhDjGbJ4VWIwdo8fUbu6lr3ZtoI3E/B+P/lKpVXB+iw7fVQiseGvtSqzmnKEICaj52FezCUSgqimq83YvEIQjac66loY/jDbuCQfVrvSFmaYcVMmYJ117+D6JyspRL0FYbWOrwFnX6LzIiyTonNtaeHV9w7EnjPJUI80QhBFKFNHT+SrBJxf/AvWJoeiJ1WjF79uvNXUJXlrg4AQRG1wrHkpuQtupNwMvwpgTx8VpJlxcwD8xXg89mcf+bySUnto5XsJmW8RY7ErplK54jMM3GtZODcxGB0yMW+VK7CWvwtBFKOpzIu21XJn0c5RdhC17HozpiwhiMZXFR3Y0/evAbKPAuNogN4MYL5jRf8KwE8ANAzwTW3BHQamKnyFOidp2UoLKRfoTd2tUO9AzHNAmDV/EfAgM92QDtBtle5e6qEWIQg9yrrLlWJiqkePbLw6hCAaTyfSIkFAEBAEGgIBIYiGUIM0QhAQBASBxkNACKLxdCItEgQEAUGgIRAQgmgINUgjBAFBQBBoPASEIBpPJ9IiQUAQEAQaAgEhiIZQgzRCEBAEBIHGQ0AIovF0MqtapHnTYErlZ8K5qaHod6a0EilcEGgSBIQgmkSRM1UMIYiZqjlp92xAQAhiNmi5gWUUgmhg5UjTZj0CQhCzvgsIAIKAICAI6BEQgpCeIQgIAoKAIKBFQAhCOoYgIAgIAoKAEIT0AUFAEBAEBAFzBGQHYY6VpBQEBAFBYFYhIAQxq9QtwgoCgoAgYI6AEIQ5VpJSEBAEBIFZhYAQxKxStwgrCAgCgoA5AkIQ5lhJSkFAEBAEZhUCQhCzSt0irCAgCAgC5ggIQZhjJSkFAUFAEJhVCAhBzCp1i7CCgCAgCJgjIARhjpWkFAQEAUFgViEgBDGr1C3CCgKCgCBgjoAQhDlWklIQEAQEgVmFwP8HEnP+awTfrQQAAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-57"><g><path d="M 101 1081 L 154.63 1081" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 159.88 1081 L 152.88 1084.5 L 154.63 1081 L 152.88 1077.5 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-58"><g><rect x="1" y="1031" width="100" height="100" rx="7" ry="7" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 1081px; margin-left: 2px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Put all x86 CPU cores into ACPI C3</div></div></div></foreignObject><image x="2" y="1060" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfXlgnFW59+95Z7IUlMIFgWIRQS8I+rl8hWaZpDeylEWg0DpJSqnUjUUqXLigH4siCi4Xr0tvEUX5EBCaZCjQiuxibDKZSfmqgIi4olKWFrmlrZAmmXmfr2cyk75557zbLMlM+rx/tZmzPO/vnPf8znnOsxDkEQQEAUFAEBAENAiQoCIICAKCgCAgCOgQEIKQeSEICAKCgCCgRUAIQiaGICAICAKCgBCEzAFBQBAQBAQB/wjICcI/VlJSEBAEBIHdCgEhiN1quOVlBQFBQBDwj4AQhH+spKQgIAgIArsVAkIQu9Vwy8sKAoKAIOAfgSkhiLa26FuGR2kNCMf6FzWv5CYGtoKx3jDwcGp49MH16+99rYj2pKpPBBpaonMM0KMA9slW2WKCTxjsj22wN9HU2v5jMM4Z/zvhtkRfzzKfXVVksTlzzq2pmfH6SQQsBdAM4EAAIQBpAK8AGGDgjtGhvR/asOHm0WJfYu7cM/cN19YsYXAHiI4AY99sm0Ngfg7AT1Oh0I+eWNf1QrF9FVs/Go2G/v4yPhhiWsiEEwHMBnCAZfxfA+OvBPolMWI7dszcUAhGja3tnyPGN4qQdztArxL4z0z8aJqNNev7u/8IgP202djSfhoBay1lHb8BP+3lyrS2LpyV4nAfgHdVwjdTzQRhxz1FRKtHiS6vhA9FNymamqIzYOCTIIwk+mM3B5k4lVR2NyYIaoxE24novwG8zceYvArg4tmzuCcWiynyCPQ0NCzZKxQevY4JFwAIe1ROEeOmdKrm6sHBO7cF6qgEhRWJGbU1lxNwHoC9AzT5Kpi/DBO3JBKxIb/1SkAQuq6eIYMvHlgX+4UXUQhB+B2pAsqV6ATh1PMWIl460Bf7WQGilaWK2lW9+IpxKrP5dYDew4TPJ/t6/rMsnU1Co7sjQahTQ+0er38VjEuypwW/SKdB+CFSfGmQBbBpXueHYPLdAB/mtyNVjoGnDDO1YGDgnr8FqVdo2cymJ4zlYPoCgLcW2g7Az5FpfGxgoPsJP22UiSBU12q8vj3y5t5Xup1shCD8jFKBZcpMEEqqzSA+LdEXW1+giCWt1tTafhMY5+caFYKoOhUTNbVGLwPT1/LIgaBUJuuUuoLBexEyatP98ycQ3TwyNHO5H3VKU2t0Lph+qmlnCIQnwfQbENcBiIBxqF0mAh4drufohsdiW0s6kW2NHdMWPbAmRbczcIJLP+pU8ApADLDSWCh13AyH8krt88lEf/fdnjv44lVMbtCkQXxFoi/2TSc5hCDKOLO0BMF4vK6GF/T2xv7pp+u2tjP2Hhmpm20afBEBH7cfwRlImiOjp1bCvYRdDy8EUV0EEYl0tppk3g9gL8vc3ALm5bMPQrdVfZTRwb+EYw0yvm/b/Y8w0+JkvPset/nd0LZwtpEKPwjgfZZyjuqjhtboUQbjNoCOtrbLwHXJ/p4vei20fr41XZnm5oWHsBF+AMBRtt/TDDxBoG+N1JuPaEiKIpHOWUzmJxj4D406aogISwf6ela7yaY5QQS6A2hrW1Y/MrLtADbCp+7E6BqNynCbwcap8XiXug/Ie4QgCp05PuqVgiCs3TTN62yGad5r23GlmbE8Ge/5vg+RylpECKJ6L6nb2trCw6kDbgP4LMsk8TyhNjVF340QrZm4gPLASD1OcdnZU1Nr+7fA+HdLX0PM/PFkPNbjtNjPOT46s24HxWw7+efTBh+3fl3s+VJPbof+ANBfyDA/7UeHr2Rqaor+C0L0AwAftcn4ksHp+fH46t86yV4sQUxYP8bk6AZw/IT+mNfAxGKdalAIotSzytJeqQlCNd3c2r6IGXdMOL4GPJWU65WFIKqXIFpaFh2WQqiXgINz88PvCbC5tf1sZvzYogJ6w2Q+aTAe69fNtUhk0XtNCj0C4KDs756qjlw7mnshpdE5PxHvVgtwyR5FmCOpA1YwWF2cWx7uTYWx+InemLLi8v1k7nZmbF0J8LnWSkTUPfzmzKVOKrlSEkRm/dCfiBxPJUIQvoc4eMFyEETmsiyE1QCdbJHoZTbouOS67t8Fl7J0NYQgqpcgGlvajydAGTzUZmeE7znV1BR9O8LUC8a7x2eTy6Ld3NL+pZ2KeqXuGHsCbHDGTjr73wUgOl6d8ZNkvOdjpVQzNUSiJxiUORlZ7xE2mOHUGYO992ws5KvJWkDdT0Cjpf6QybxgMB5T5tR5T6kJQnXQ1NJ+IYCVE3lPT7JCEIWMtM865SCIzABHOs4D8QSVEgOnJ/t71IXflD1CEFVNEHZ79z+HKdXa13fPy14TSjfPnU4fLS1n7ZPG6IMANWTbHQF4QaI/9pBXP7nfs/NfLXAvAZQC+MG68B6X9fb+eIffNtzKOWzCtjCMk5P9XYPF9NEY6VhIxKssRKxUVnfVhTed09vbm7K3XQ6CaJzXcSSZ/HMAs8b7c/DbEYIoZrQ96paLIDSDBmY6OxnvvtMqUt7kCrBTU+141Q9spVUm5zF1fK+v3zqHCVEG/xsI77Q4WalXGQJ4I7ERB2PV8PDMX/ixsqkEM9fGSPR0Iuqy7WSfMcOpk/3sZLN3BGoxeIdlbjxLZuoUq4moZk49b4ZT8/z0EYQg8jHlp0fC4eM29K76Rxk/xUBNNzdHm9ggRVi7LuuJVib6ui8q9pSi7jVqd+ABgJTjYe5xvEcpB0FondSAWF1481l2khKCCDR1ghWeVILQ+Bx4LfBeb+NVf6oJYpdDHikrFj8OXblX9uXYVQkE4agLJ3wn0ddzqduCpYizbo+tdzBzh2Ws1WVwZzIes3rHork5+kEY9CgD++V29jutdD6S7O95zGueaO8vmBbpLJnsp19i/Ggg3vNprz4m8/fGlvbvEqDIIPe43qkEla25peMzTHwJmH7G4Pvrw5x0smqcNIJw2DwKQQQd3QDlJ5UgNComrwXe61W86k8lQYyZSYbutqgqvF7H/nuaQDcPD8282Ok0UQkEoYR2MAl1NU9U9TSXx8rBTGsWqtvZel2gZgGlxpb2LxNwtZ8dcXOk/YdM+NR42TJcMAedCNbyGhWY4uDBEGpO7u+/a0sxbRdSd9IIQlRMhQxPcXXKRhD5zjPaHY7XAu/1dl71lY318Oiby0H0r2NtmR8Gcv/O/GE9QE/uWgzM9Yl47Bavfr1+dzY/HI8RpPpVpwT1cauThTrO74qTs6sDV5v9SiGIDEloL025d6QeZ+jMSTWWQgoLx/IOhJIm4Lrhob2vdyDRXEiOW60qMCcSev/8pXu+5c3hey1mqiO2Uwo1tEaPNECfhYmTQBmLKhX7KROLiQk/MUdSt5XT50dzklKub1N2yikHQegswYjx1YF4z1X2b09OEF6rURG/l4MgtDpMwp+Q4rZEIvaiVVyvBd7r1YLWn6xLaofwA/elDb7UyR4+EokekSa6iYAPT3xvfhBpLNLZgFcSQaibTI3vQJrBn0v2x75lfaes6m0ViBZY/u7p0+BkiqmcMUNsfK6mpv4JdRGsys2YsfWoNPhLAE6zeji7eTfPaVu8X20q9XOA3p+Va9y8UjnCEdMtNgsf3RQdYmAFpfnaICE9vOZ67nfd/V45zGh9y5O/GQzkKKfrJ8+KDEgz80K72lHVFYLwO1IFlCsHQTRG2s8nypioqZ1V9tFbQQRd4PN2D/bJ6XHJPRkE0dCw+ACjJq304uMeuD5VIcphaQZCdNsEE0nghTDSbf39q/9if/8KIwg0N5+5v2nUPELAByyy5jlbNbZELyWQioGVmyNaItFN6QxJ1L9+MQjqXidIzCHlWXx7fZgvctKnay5HMxfhNFozl4iVH0WA/grzR/D6jDWbD/spx6uJkv5e6hOE/mQJ50tyieZa0vGc0FgpCUKFNtj4EpZhLMKm1Tbb0Y56OhKExl5/M5l03MBA9zN+RrIhEm0xKGOhsme2/Otk0nxd8LRKIwglr07VZCXIseB3pnq/XXGSXDxlnTDL+DaEjK/tDC7XCaDGA9sNMIxPJ9Z1KXWiYxhpjfrmzwSsYODrtjm9mYHHCbTNLe5TOWIxlXpB9jMn3cqUUp6G1sXvJ07HCDh8Qp8uBg9ygih2BF3qF0sQSsf/ZmroHWHgeIb5WRUh1d4dA7eODu19nk5HPB0JQi0ypkEfJ/DRAB1CRP21oU1n62zIdUOjM/Fz8iGpRIJQqibNpXDGMqm+Bo8Pp0gFgFP5CTIPA39A2Dgx2dv1Vz9TXW1EXniJFhHhqxNi9XtXVurNy91CfmvwHAEwvOvkwM+RgQs1ISyoeV70w2ziRvs3QKCbasObLvI7/l6vYT8FE/APmHzCwEBs112aVyMl/L0YglBj+cor6f1HOXw0COcTY74mlpvr/BCCKOFg2psKbOUTXJY8e3ZrE9ORIIJDNLHGNCAI6Dxy1T0BgXoBvtyiWvIVEC6H0Nj9Fqn8He0anDcy0G/Z1bdkk+TYiz6ENC9JJGL/Y/9BGyYjW8jPaSAb08geS8jTmivInMlL/AT4dhgM0o/fsmUM961E8JwfQhB+R6qAcuUkCBUPn9L80UQi9icn0YQg8pGZDgSh3soh8qrthf2H3nayDFPEw8SfHOyLPWtHc+686KFGmm4gwhl+LqpdCMJ1o2PtV+/45+yJHPSz1fhAFH0pHFQG101eMY1NrOsr5LgQROkAz2upTATxOhjXw+Qbvaw4hCDGhmTM0/q1w02ETgfxkqyaYvySv8pUTLl5plM1Weegb29rVUl3se3lJ6LqZe/GLgfRdRMMJzR6bQeCSBNh2UBfz0/8fop5VjgOVnx+2/NYkKcbQQTKSCkEUcgs8lmnBAShYrO8pMJEgPGYgdBPd+zY6yk/YSIyH31AKyT7awWtPxlWTC7Q05y2xfvWplOHsYlDDaL/DeBDDCiTSp0PxHhTVUoQyJo83wdQmw2XQGoXnWXYzpBfD9eF+aN+8pY4mMfmGQ9oCaKAxV13l+HX69vr022MdCwhYitZpZnptGS8W+WumPSnBCqmTQD/A6B+Bn42Ws/rgiRYEoIo45AXe0ldrGhBF/hqIwi1MNXMeP0kYlwGwjEuGbxcoaxWgshsAsZiNamL6V2WRoQnRkKhU/zGN8q2oRL85E5V28jkkwYGYgm/c1Cpm0ImqZhPKvNb5rEH7NOF5AD4/rrwntEggfYUoVFNep3VGkcXi8yv7NZyGiu3soQT9ytbMZfUfvtwKycEUQoUHdoQgihbTmpHqxaP4dzp24UXQJkTxbipcLUShEP46LHFOUCmteZI+/VMuNKC3S8N3nFaPL52e4DPQ6m8lKObynqYeyYEgNMGiSsggGOQ4IAB5M8U1ZHYdPOkDoKJhiBKEpdKexc4hTnsVY7YSX+EIMpCENTU0v6ZnX4MN3icGLLqOWwAsdoJ/7IutOfT6fS2fVIcVukV3zW+03UIlV6hZq45sb3uIHyrmfIsdwpYtJVQja3tlxBjl1e3zbFS+z0U0Fc5CSITPib1RgwglaIz+5Q2FpOK95RCarUyoSXCWjKNx+PxLhVWPc+HZKpPEM3NHcewwSq5095e30uQBVYX0sRvgqog/fgtKwQxtq0MlA87qIpqMu4gGls6Gwim0gfvYxn89M6cAr8mGLfCxLraWvOvAbx51VepzaVRyQShsWJKZ30K9rB8yE8Z5uj8gYF7N7t9KCUjiHyvW7uJKDVG2m8nwtmWxTewismBIC5N9vV82++C4FZOsyiXZNec61MXTtzplDLVBKHLHcGEorHWOLw6foelGFOvNnZLgshLLBSQIPIjb7oTTLkJwiFvsi9zvdwEmQ5mrnrVEveC6Osq38UE8vQRFjxv3ArM0OZ1gtCeMhA8H4RmDEt6kdzc3PE+NjIJdca90dUCXluz+YISOORRU2vHCjAvt25wiOjsgb5ulfdjwjPVBKGJn6UW8luT/T2fLCY3hua9HCMaeC3upfh9tyQIjf7Qt25ZE3nT8wRSboLQ5h0IoGtXEynIkblCTxC6oH25bGfrdV7Wbikts4v2laRMp4tUqeT7EORfQGsugQNnlNO04Ts9qp/FxGEj4ltl59aHQyykZ8zR0PGDg6s2VRpB6FK8AnCU1w+++ox9wTcKfvryW0YIYgwp31nCtGkJpzhYn25xCWreqMvHW00qJl0sJuuFtC6gn3KqdFM1aY77wRdtXRBFTQhpfb6FQI5u+TvwgCdjP4uGzhFROQ2aI6OnFhpu3NEZ0eVydqpPEAorTYrjNDOWJ+M9E9Ie+8FVlXHAtuhTid/+deV2S4IoYremvwCdYoLQLGSBVAsO6Ter5g7C7+KvTVPqomrS+0G4546wfWTUFIl+HkRfs/zd0VRWs+g5BpzM21Hr76CWJ/p7bixmgbDXdczkBzyGNHfoQom49e8SSt2dvMsQ7jsoTjoTZgCe4eN1/TiQZOANSdB38Cq/WxJEJiJnmHrBeHcOIB8xb7RJYDL1AxKEUxISr8Fy+l1r+eASrNDajiIHDtHdtlDZY6/lkB6zwlRMOtWSNn1o1j/kBzaTU23ZHEY6hyyld2eTL/Lw2KfG1ug5xPQ9q1WZWwj2Y+Z1Hhw2zYcBHLlrjOgvMOijiXVdv3Ye/4WHsBF+AMBRuTJep6NC55qq19yc399Ye45BBbXdqfetMc1bLImScuVcx0QVqoQThEMuEiXeFnWXMvsgdMdiMWUk4fqonB8G4zaAjp5QsIBow159Bf19tySIbORPu226wu6+lGFc9MS6rhesQKrLz3BNzTVMuMAe9dEPQWji2DyLNC9wixcVZCAdEr6rPAQ/4NGaKwYH79xmb0+9U6gufCGYLnPKN+BkXldJBKHPKOcca8nhtOQYfsMtFhNg/Huyv2u9/VIye1mu0o2eNzE/CfJyVNjHpbm1fREz7rCZKm8H8VeQwkorKalwHn9/CccaZHwf4MMsbY0w88eS8ZgK4FeWp6k1OhdMP50QPn2sJzXvniDQt0bqzUfs3snjSZUyuaczwQ+tIfoz9UF8RaIv9k23y94KIQintLdZzPk5sPEdA+aDO3bs83Iu0sNYiJsts9igeQxeCqZjNetKQSeRUg/27koQcAmQlgJ4A2A8pT7uncnTjybgvZYBTBPje0xQ9uBj3rFeJ4hIx3kgtusls/4IlCLGutqaGRcE8ZrVLCxnM0Mll7EkTMqUyqSlBBm/Gvt4eS9iNFrSVuaa2g7CJuupiglXJft6VHjrCU+lEIQuJ7WfMN66nNRu4bGdd8xqq4HXwFiXSeVKXKdUyeDMvLCPw3ZmWpaMdyvPbLeHmlqjl4Ezaqm8NkgFCQQ975YPAvAfjLCYBSVrlqq81Q9ybCeDD20d+z2Dz4Ga98pVT4H4ytkH4lteO+9KIQgleCTSebRJ5hpXHIIBvYWIlw70xX4WrFrpS++2BJE5HvpzLLOinslFDDN1KxthZe435lTmQRAOFhqWdot3OFK7kroZW7/L4HNdPkCHGcTPkWl8zAxxi9Whix3MOiuBIBx04b4C3DmkHnVVa7ip4nx8li+RwUsH1sUe91E2E+jvxZfpQk3CIK/qaRC+PfLm3lf6jUvm1aDX7y5qIq+q9t9fMpmXDcZjKiuiY3KlXKVKIggl09yWjsNDMO/MUxMFRUGp6UzjY7pEXYGbKkGF3ZkgFHxBQlO8ysyfTcZjPa2tCw+c4HXsbS2i1Ufnxo9d0nsGGeMC0mK+CuYvw8QtSnWRd9ntEDCuEghCe+EcQGerzTCnzBTDqZMHe+/ZqMM9QyxhLAfTF3ymAQ0UIdTeZ4B81Krqi8z8H2p++llgg8wrr7IZQtuEfzNNup6Qif1lP/m4NfE6Af+VHq1ZoVOFOlWsNIJQcmZT9y4G8GUAb/fCzfa772jUAdstqvjuThAZ8MaD24EvADLRTseinGaOx/x7IrqpNsT35byQ8xySvAki09zYZRRdDUDpHK2RVEvqkZq5M6mtWcLgDhAdAca+2Vmi1Fp/I6Y+5Tg2PDzzF9adpsZqR7sjn2qC0KmWVHRfg9Pz4/HVv/X5RegsjNSg3zwyNHO52w4847GcMk4GOKrubG1qExUl9M8E6k6NjN5ZqOmn5R2ooTV6pMHGuQCrzGfvtOjtlX/AOgbuGB3a+6HJOjW44ZuZQ+HUqSD6CEAfAPhtE8h0TCX3VwL9khixHTtmbihE7kokiBwumeyDm4zDic1TiekEBo7Iqp/CFuzU2G0sFgefc73gYlNCEAVLKxUFAUFAEBAEJg0BIYhJg1o6EgQEAUGguhAQgqiu8RJpBQFBQBCYNASEICYNaulIEBAEBIHqQkAIorrGS6QVBAQBQWDSEBCCmDSopSNBQBAQBKoLASGI6hovkVYQEAQEgUlDQAhi0qCWjgQBQUAQqC4EhCCqa7xEWkFAEBAEJg0BIYhJg1o6EgQEAUGguhAQgqiu8RJpBQFBQBCYNASEICYNaulIEBAEBIHqQkAIorrGS6QVBAQBQWDSEBCCmDSopSNBQBAQBKoLASGI6hovkVYQEAQEgUlDQAhi0qCWjgQBQUAQqC4EhCCqa7xEWkFAEBAEJg0BIYhJg1o6EgQEAUGguhAQgqiu8RJpBQFBQBCYNASEICYNaulIEBAEBIHqQkAIorrGS6QVBAQBQWDSEBCCmDSopSM/CDS2tn+OGN8YL0u4LdHXs8xPXSlTGgTa2trCw6kDbgP4LGuLBFw70N/zpdL04t7KMfM6Dw6n+RQiXsTAEQAOAhDO1hoCeCMzDRLR2pF685ENj8W2BpWrsaX9NALWBq1nKT8E4BWAXwbjMZOw9h2z8GQsFkv7bTNvvgN/DlOqta/vnpf9tlHOckIQ5URX2g6MQDUQRENr9KiQSZekU6GrBwdXbQr8khVeobm5431s8M8B7G8T9RlzNHR8ud55zpxza2rqtywkwpcAek8AmFIM3JE2jGueWNf1gt96JSAIXVcvArh89izu8UMUQhB+R0vKCQIAKpkgWlsXzkpzzRcY/GkAf6uknV4pJ09TS/uFAFZq2kwT0dkDfd1dpewPADXPi36YTdwYkBjsYmxnoqsOPtD8nq/FufgThBsMPSP1fK7XyUYIosQzSZqb3ghUKkG0tHR8IA1+GMAB2RGoKFVAqWbFnOOjM2t34AG1ZmfbHAVgAAiN/Z8fRBqLEomYUq8U/ahTQ92M1z/PwDUWFZK9XaWyeQWg4cwPxDPB2Neh8zQIP0SKL/WSsUwnCItYdPPI0MzlGzbcrDDUPkIQRU8haWB3QqBSCaKhJTrHAD0KYJ/pTBANkWiLQfQQgD0zazFRN7N5JEDvz773NjL5pIGBWKLYeanIoXbG1pUAn6tp60UwbuQaY1Wyt+tvipmsZdraom/ZMWrMJ+JrAbwvv76PxVlzgmDg9GR/z0/9vFtG/tot+1PYaGU2r9GcftJEWDbQ1/MTIQg/iEoZQaBKEdhNCIKaWjtWgHl5bpiIsNRkHEvAx8f/VprLampqjV4Gpq/tOp1kehhSl+Gc5hVeJwBVOBqNhl58mS5k4OsAZlimV5oZy5Pxnu87Ls5FEoS13aam6AwyaAUTPmX9OwNPGebo/IGBezfr5JATRJUuCCK2IGBFYHcgiIaGxQcYNenHLDvyLSb4BGK8nYjusSzkRV9WN0aipxORusuwLuqbGViS7O9RMgR6mlvbFzHjDlt7f0eaj0skYn/SLs4lJAjVvlLP1e2gGAMnTCQqXpiMx7TWUkIQgYZZCgsClYnA7kAQza0dncys1CG5+4bBEGpOTqdH90CYesF4d3Z0irqsbm4+c3/TqHmEgA9YRnsbEZ810Bf7WYEzgBpb2r9MwNUT6hO+k+jrudSuolJldHcQQVRMOjmbWqInAbQGQG3udwZWJPt7LpYTRIEjK9UEgUpHYLoTxJjvw/53Ka2NZmFTi+8tVjVTMZfVWisp5isS8Zjyf5lw1xBkXmR8J0xTGRIcaan3fNrg49aviz1vb6scBDGnbfF+tanUzy13NuqNHq+r4QW9vbF/5slg9/sRPwh/Q650iy+8HDqawIsBng/gnZbj4yYCngbh9toQ36cD3quX8fbJXAbOHAkPGbeiILwG5t8TqDs9GuoOYvdtPzLmdiQNDUv2oprRK7MfmbIvHwLzc0z4iTmSum39+ntfc5LZVVagaCzGj8fDdBoYH2NAXUjmrHUyFiQEPMvM3enR1H1usnrh7vW730tqdUk5PEprQDg22+YEq6K5c8/c16gNn0Mg5ex1OIC3ZsttAvhXDLppdGjvh1wtTIKZQWbUMYP9sQ1u76jkCtWEzwDhEyA6wmKNk1Kms8TUl4Z5S2rHPoNusnnhGPR3je/DCAMfyal7NDvjgi6rNVZSStSiVVa5921uaf9S1iIq9yfH0045CEIzLxXnZU5i/f13bRGCCDoz88tnbaLpu3rrhLwKrwO4evYs/r4f2+fMYvsSLSLCVwG8y4e4KSJaPUp0uR8nHB1BkGFshMl3A3yYvj++vy68Z7S398c7bL8HtQ/fDuKvIIWVfi74VF+ZCZ2mr4Bxnk1/6wRNihg3pVM1Vw8O3rnNB36BihRLEG++ud8/autfvxiEL1pIwUmGVwH6RKK/W6k18nauAc0gXQlC7W5DpnktAUtdzDmtcgZyuAoEsqawRhc+YdHW3E8owBxVJ07yNLa0H0+AwntcBUOMrw7Ee64q9h1UfUV0psGrCXiKCGvJNB6Px7uUV7Kv8S1WxaQnCGfvaLmDCDDqyhIAYfoWGMoRKasH9dsA3VEXNj/jdprImMalaAUBHwvePl4ig5cOrIs97iaRfcAJuJiRWXyPcqin3eFkrCJCxnUMVrrLgFjwoBlOf3Sw956NbrI2NUX/BSHqBnC8X5Rz5Rj4Aww6I7mu+3dB6wbBDw6hNnQnCKTTpyIUUmaP7QFkSjH488n+2Lfti0ipCKJ5XvRYNkldoKpwEUGeNAO314f5okJOyX470u3qdYt/Y0v7dwm4yNJu4J1/c6T9eiZcaWnjDZP5pMF4rN+vvKUqN2mO12EnAAAcJElEQVQnCFExFT9kHjbR2wlIMuh5ENcBiIBxqH3hJNBNteFNF/X29qrj+oTHwcIgV8ZX+wC2M9OyZLxbWXRoH80O+DWLGkE5F8UB+kv2NBEB8Gd7+AJXLAivEUOpSJRONcTgowl4r2ZX+iyZqVMGBu5RNuR5j0sfGdUXyPgVgLQb3gD3jtTjDC9v0SCzo4gTxIsAPw3QyZb+hkB4Eky/8cBKu/tvmtf5IZh8/lh75n4AnWrZ+W5jxloiejPb3xCH6TvJ3q6/Wt/XwbpGFVEOXWoM42AaJvChDDTqTj1MeGC0js8qJc5WGTW7eu2ibfeRUO8QxLP6/fOX7vmWN4fvtVr5qI0Gj4bmBVHjBplPbmXLQRBNTdG32y70lQixuvDms3TrkpwgfI5mY0v0UgL9p23Rf5WZLhndMbPHpo+lSKSjwSTzVptzypDJvGAwHlMOTeOPuoAbSR2wgsEX2MR5iZk+e/BB5hq7eiqjEkib3ybCGTaZNsMwTkqs6/q17tU0A54txoMcDnVaFxC1Cx5K4x2DfbFnLW052IfzcybjoncchMftso7p22uUBYc6qVhPGw/Xhfmj2suxls42gvmARa2kdqtfqw/zN3Tl586LHho26Qd2E74gC4SfqVAEQVibV4R/fW2Yb7S/ixrXGtO8xfYeyiNsZaKvW+2OtZekhVxSjxGMqZzOrDGNlPNUVwipy+0B2ZT6c+PLpE4/Sr36NusLuW1+/ODqUibP92Hnnd/ASD1OsROS/v7Av2e1ClWS4nDfRNWuo3q1yNfyrl4Ogsi3BAOY8PlkX49a2/IeIQjvcYJafEImqeBg6lSQe55Fmhc42TCrQs3NCw9hI6wWOYv6Jn/CNkSiJxiUMT2z2Fz7UsNQU0v7Z3Z6ld4woS7zGphYrNPz6wgio44JGyfad5c6aDQLkSr2GNLckUjE/sftQ29sjZ5DTN+zLvpOnpx56gKPBVL1m10g7gOobZccpf3AS0AQisDPTKzrGnDCSnuaJPwJKW5LJGJK95/3BCWIjLrUwCoQLbA0pk6Qlyf6e9QYOVrrNLQtnG2kQncD1GCtq9v8+Pi8XIvodrxuC5rmEtj3ZbVubhdyj1HsO+fql5ogHM13XTzPhSB8jKbG7G0Lwzg52d816FW9MdKxkIhXWY/+1lAADqGLXR1obH3q7Ku1JxVVT0cQAcIka3ZzcFUVecuavxt0OOr7CjFgt2Zh4IUw0m39/av/4jVWfn4vkiA8vWdzMmiscl4nk+YPDHQ/UQqCaG6ONrGRCVmxV649Bq5L9veoy3NPU86mpui7Ecpsmt4xLo/LxsQPtroymh3vZjLpuIGB7md84uB5+sq1oyUIl911oe/kt14pCWLMxDZ9+8TNkxpp582kw3pRUTG+pjzct+7Wnxg/qq3ZfIFOZ2cffO0FG+HSZF+PunRE47yOI8nMhC6eZam7PNHfc6PfieRgwXFrsr/nk3kXm/l2zb4v4TQnKc9YLvZ30LQxwVxRlddhzkxnJ+Pdd3phkt3dPgqQugt6kkHP1pD53b6+2Ktedf38XhRBeJwCrP23tCw6LIVQLwEHWxZwR5IMeoIoxYWubuPkx5TWD85j82BZ/XDqjVj2biVbzV1llDkZhbDadtfj67JauyBbvlW/cpeqXJEEQXPaFu9bk0p/kAhngzOGEVavcCWm50ZXThAeo6lZwEcAXpDoj6ndl6+nsaX9K8q/QNnqA/i1StyR7OuJZwgi0rGEKOMdmnkK3fHmW1/w0yPh8HEbelf9wyqkZsCfN8OpeV4WRWOyZsIP7AppEGDBy8mgc3jSmBFSY6T99szE3oVLWaySfA2gpVBRBOFyGWiXo6XlrH3SGH3QqsZxM3EMQhC6tgsx5dSRGJjOT8S7fxAUV115bd4HH+03RTrOA7E1xpGvy+oiF+RSvPKENgJaqQXtXxl4XJHoi33T7cQoBOFFEJGOk4lYRU/MXa76XlD9jFhzpP2HEwNoFaYz11h6aC1f8gbcxcTNLr+dhAh49J971J359CN3vOHnXXNlGlvbryTG9bvq5L+z7jJNOe8xsGanRc1tdeE9ezV+GUHEKKhsMQTBhKuSfT3Kv8Xz0Z6iXCJ5BiGI5uboB2HQowzslxUk7xTnKaDTDr+EGfbs9wl+N09a4vIRBlznA+F23+EHo2LKlJEgUiC+cvaB+JaXb5YQhBdB5KtkfmnwjtPi8bXbixl8VVd3hC70UsyvSkIz4I4mbtb30+38Af4jYPwiOA78QQBzLQSR58mZtXy6n8ZMK3WPytL1W2J0c4juO/gA8w9ekz24nPk1iiSIcdWilyzlJAjNQvgyG3RcIT4jeSfXABsONwz0Fkl0V1140zleql2Hez3Py+pquIPwmjcev6uoA0mT+FybZaJjNSEIb4KYsNstdNes60a7CBR4KaYz0dOpJPwucHZ5HTwwi5yv49W1F1+RSOfRJpnKusuPA5ci7PvJpB8PD8/8RbnCQPjFL+gC7wfvUqmYNDvTgi8eizmRuk0eDYn5UhPl2tSeQD0s4XSbLHXfOBDvUY6xk/4UfYIgvMaswvJgvWHg4fRI6NGg/hxCEB7D3tTa/mMwzhkvVsIjdNkJQkM2fhc4PwtWCb8YxwXKxd/DrXtlrvl/w5S6vtTJ1f3it9sSRGmCuems5Uox3RwD46nGdXczQGEq31IIWwl3IkIQ05kgNJY/fhe4SiGInBzZWEEXZ2MF2ZPVO42ir/AjQT5mv/jtvgThHPjNL84Ofkd+q7uVcz2FOESMnVae1EFBFILwQKxUF7PTUcU0RRd41NjWeQiN8okw+Bww1H2G3XzPCrerZ3nRH4z/WEzKQs2XL4eSKSjBBLmkrnQVk4OBQtChcijvYSabbwHl2wzcr4BNkei1IJwIwmrDNB/YsWPfP+hUonKC8EZ0yv0gNAxakZfUGnPcNDOdlox3P2iF2e8O2D40Oue1qdTP5uRTMZvq6187PE2hpcToAGXCrk98fHhhe0/FsRJ+8Qu6wPs5sZXwDsIesbTgS2q7P0Wxd3QOfgxKZfgKQJ4OfPnjyCokSC6UuvrZ9bJad1FdiAmw03xyCDyoPaUIQXh/lVNPEGOe0KstogY2c1WTjkD3ZnIsAL8ylANXNqdtqT6wRps5LgH/gMknDAzEniwFQag28kxyS2Sx4j0NfJegptb2+WDcbo0vVMqAa9OCIPKdM7WbCS/Uy7Fp0Po+FEHw2uQ/Lu05ENTvUoZxop9w+l6Y6TK6AXrrLCEILzSBKSeIUtiM253hrAk6ptxRLsClu8YByTXsgcPw5i4gVWawjQA9yWw+Wl/z6uqc+WLmNMTmqWBqUiGWGBioD29e6mXemOuvsTW6jJhutfTvK1mO93ScHieISnaU08RSKkrF4xCpwPWyWhvQLkAYEqd55BD/ytHxVgjC+4uccoLQ2mMH2NHobLKtvg66CRxUt69LZciAv1AbAQhCt7sLEr9HDbcuho/d96NYj22NmkAIwvataUJtBN4la9SvReHsYEWkjdzqvXSMlXDwiYBb6BYHH5xtBhunxuNdKtprIY8+CrJbLgZNxsAg91iFCGmvI5fUPlDU7Go8Y5jkmtUsVhN2DGUK1ue8K7E7/gUgCIcd0GYQn5boi633gtIhrPkQwzgl2d/Vm6uvsUcPFPMpj2CAwGpBp3eZDiqmjLqwHMH6fHgru80Rnfol6GZJ175ereN+WZ2dQ102AwjPSLxO7+eQd8MxqKZqR04QXitKBaiYlIhO4b7dEt5kd8v5GdE0OwZduG8GnjLM1AKnhDpZ6PThvgHnPAtFEITq00FWP3GSqDESbSfKqH52WR1pokk6kKYvItKH/HZOiOI9BSeWqBaC8ApL4UD2jtnrrCg4hftm5s5kPLY2KKbjc7m1YwWYl1vqF6LCzOtefzJxv6x2SVgVKG3uWBZKXA6mL9iTZnnl0BCC8J5JU65iyonYGGk/nwgrJya8ob+YbJ6vSZJDTfM6PwjTVJel77O8ZtCEQSoC6cWzZ3GPPYyE8pxOI3wDMzrzEga57Oj9LnBOQ+OS3GgLmC+HibvseSgaGpbsFQqPXscElRApbF0AnE4fkUhnq0nm/dZw1ACcEjRlmmxojR5lMG4D6GgvzL2nnr6EX/wm24pJZ8UG5qtnH4QbnEKQOCUMYsZ96ZBxif1SdixfurGAiP8737udbh4Zmrm8UA92/SasdE5qGi2AZxhwjyyPL4JxI9cYq5K9XSorotXCiiKRzlmmkV4CJpWS9+322aSsvYbrOeqWhU8IwvsrrRiC8EqzCcY6gF5l8F4EtACYbXs91+iJJUo5OkSEpQN9PVarqwli+F3g3IbGQ1ZrGk2VCvMDAM3RpBwdYuL/SPbFbnLoS1kkqfzf/675fTvAvwGMbE6AjCljM4AD8ssWt3DZ2/OL32QTxJy2xfvVplI/B+j9E2QmFWqBtjI4FWLjU3YdeilSjvpZ7Lw+9XxDjmDpQr3a11pHAa6X1RYtgAozf5JLHxYzXFZr1oEevjkPIc1LPBJsiYrJa1BRISqmnJwZktjj9a+CcYk937THu6QJuG54aO/r3XZYY+oRUgumit1uTc3pA6rM7vocu99DoQucV4dZWW/OyupV3P67r8xlmUU2ZXwP4KVBO1D5iBm4vT7MF+lSlBbQXqZKpRKE+lZcCDUju9PFbNZE+jZ7GlEfGKngbz0j9XxBMfmoHUxLPRdvH/KNF9EHm8z87Jl7xU1NFEQGACqK6leQwg26bI9536pcUnvCWzEnCIuk1Dwv+mE2caMt37TDy/BzZODCgXUxFfXU09HHkvdXpRHNO5pqOkkR6IfDYeOL9twPOoH8LnCeIwOgAFkVAEkm/qTfaJLZPs7feQK5DsDefuQCoNJyXq5Tzfms71jML36TfYJQAh/TFj0wnMKqvKxh2bdxc/jK5MJmvoGZF2lOexo8+DkiXDbQF1MpdT3ntRvu2jS2ASwF/Y6p3kPbf87qMTWYcRXAZ3mcEOwipZixJgS+Kh6P/d6vvKJi8kaqEgkiI3VGH/sKNRomfYqJWwEcYvmwNgFYx8Ado0N7P1SIXladVurqtn4YhMW69gl4mpm706Op+9avv/c1byjHSvhd4Py2p8opWcP1WxpCMD7JZEYAUuq13EW0Ugf9nUH3m6D/u76/+4+FLCgT8cjrYwjgjcRGPA3zltSOfQYLwdzPO/vFbyoIQsmvdrsUMj7ObH4KRO+xLWSeod3HYl6lowQsAtERYOybxUWd+v4K0CMMWnXwrPT/K1V4dc39QOCkXH7GTpd50cuzWtduNkx/204fnjMAbgFI5dWwqjcz85GZBolo7Ui9+UghJywhCO9RrViC8BZdSggCgoAgIAiUEwEhiHKiK20LAoKAIFDFCAhBVPHgieiCgCAgCJQTASGIcqIrbQsCgoAgUMUICEFU8eCJ6IKAICAIlBMBIYhyoittCwKCgCBQxQgIQVTx4InogoAgIAiUEwEhiHKiK20LAoKAIFDFCAhBVPHgieiCgCAgCJQTASGIcqIrbQsCgoAgUMUICEFU8eCJ6IKAICAIlBMBIYhyoittCwKCgCBQxQgIQVTx4InogoAgIAiUEwEhiHKiK20LAoKAIFDFCAhBVPHgieiCgCAgCJQTASGIcqIrbQsCgoAgUMUICEFU8eCJ6IKAICAIlBMBIYhyoittCwKCgCBQxQgIQVTx4InogoAgIAiUEwEhiHKiK20LAoKAIFDFCAhBVPHgieiCgCAgCJQTASGIcqIrbQsCgoAgUMUICEFU8eCJ6IKAICAIlBMBIYhyoittCwKCgCBQxQgIQVTx4InogoAgIAiUEwEhiHKiK21PGgLHzOs8OJzmU4h4EQNHADgIQDgrwBDAG5lpkIjWjtSbj2x4LLa1FMKpfkMmn0fghQDeCWBGtt1NBDwNwu21Ib6vtzf2z1L0J20IApOJgBDEZKItfZUUgTlzzq2pqd+ykAhfAug9ARpPMXBH2jCueWJd1wsB6o0XPaYtemBolFYS4QwAIY82toP4K0hhZSIRGyqkP6kjCEwFAkIQU4G69FksAtQ8L/phNnFjQGKw97udia46+EDze7FYLO1XqKZ5nR+CyXcDfJjfOmPleNAMpz862HvPxmD1pLQgMDUICEFMDe7Sa4EIqFND3YzXP8/ANRYVkr01tdi/AtBw5gfimWDs69BlGoQfIsWX+tndz23pODwE836A/tXW3hAIT4LpN+pEweCjCXivRsZnyUydMjBwz98KhECqCQKThoAQxKRBLR0Vi4Aih9oZW1cCfK6mrRfBuJFrjFXJ3i61+LK1TFtb9C07Ro35RHwtgPfl16ebR4ZmLt+w4eZRJzlVG8MpuhvAiZYyaQZ+wKM1VwwO3rnNWre1deGsNMI3MKPTqoYi0E214U0X9fb2porFROoLAuVEQAiinOhK26VEgJpao5eB6Ws2nf8QAddymlf4OQFEo9HQiy/ThQx83XKhrORMM2N5Mt7zfSehm1s7Opn5J5b+0yC+ItEX+6adkHJtOJDaZjLpuIGB7mdKCZC0JQiUGgEhiFIjKu2VBYHGSPR0IuqyLeqbGViS7O95LGinza3ti5hxh629vyPNxyUSsT/Z22tqis5ACKsBOnn8N+Y1MLHYi5gaGhYfYNSklYzjJxcmfD7Z1/OfQeWW8oLAZCIgBDGZaEtfBSHQ3Hzm/qZR8wgBH7A0sI2Izxroi/2soEYBamxp/zIBV0+oT/hOoq/nUvuJoKElOscAPQpgn2z5EYAXJPpjD/npv7Gl/bsEXGQpG6sLbz5L1Ex+0JMyU4WAEMRUIS/9+kagqaX9QgArJ1RgviIRj33DSbXjp/GM74RpPgzgSEv559MGH7d+Xex5axuNkY4lRBn1Uvbhp0fC4eM29K76h5++GlvbP0cMJe/Yw3i8roYXiH+EH/SkzFQhIAQxVchLv74QmHN8dGbtDjwAULOlwjPmaOj4wcFVm3w14lKouaX9S1mLqFypNBGdPdDXrdRZ409z88JDmELHg4wmgJuJ8Kva0OZlfk8AzZH265lwZa5BAh795x51Zz79yB1vFPsOUl8QKBcCQhDlQlbaLQkCjS3txxOg1Ei144sr46sD8Z6rStFBc3PH+0yDVxPwFBHWkmk8Ho93vVzMycQul+7+goEVyf6ei0vxDtKGIFAuBIQgyoWstFsSBOw7bwBvmMwnDcZj/SXpYBIaaYxEO4jodgvJDZnMCwbjMXWnIY8gULEICEFU7NCIYO+fv3TPt7w5fC8DJ+TQYOAPPBqaVwr1UrkRVia1G1+mcwB8B8Bbx09ARN3Db85c6uZzUW7ZpH1BwA8CQhB+UJIyU4KAcjRLcbgPwLt2CcD314X3jPb2/njHlAjl0akihb9uCh2kAgeC+PKJsme8954yzNQC8aSuxNETmewICEHInKhYBDSmpWqBrUjdfUMk2mIQKZPXPR0AVY5496VrePkTvbFXKhZ0EUwQsCAgBCHToWIR0BJEhTqYNba0n0bAWgcwRwn4toHw1/v779pSsYCLYIKADQEhCJkSFYuAbtFlwqXJvp5vV5rQeX4OegGHGPghj9Z8wR63qdLeR+QRBBQCQhAyDyoWAS1BAKcn+3t+WmlCN7d0/BfDPAVEg2AVRZbfBsI8XRRZuYeotNETeZwQEIKQuVGxCOh8IKophpG6sP77SzjWIKyw561QjnLD9RwtVWa7ih1EEayqERCCqOrhm97CV9MdhNtINDVF/wUh6gZwvLVcNZHd9J5p8nZygpA5UHUItLQsOiyFUC8BB+eEJ8aPBuI9n662l2ls63wnUubDBBy+S/Zg8Zyq7Z1F3upHQE4Q1T+G0/YNWlrO2ieN0QcBarAsqhXtB+F6ksgPOlh1XuHTdrLJi2kREIKQiVGxCLS1tYWHU/vfBSCaE7KaPKntwGpVZkxnJ+Pdd1bsIIhguzUCQhC79fBX/ss3RTrOA7E1y1vJd91Nkei1IJwIwmrDNB/YsWPfP5QjDIbOM1zuISp/Du7OEgpB7M6jXwXvrtt1UwmjuerCiZfrlCIEUQUTTkScgIAQhEyIikZAm+oT+F3KME58Yl3XC8UK39QSPQmgNdZw4gDdVRfedE4u18OYDPQJEI4B89EgOpBNOjcZ774nSP8NbQtnG6nwOgCHjtdjOj8R7/5BkHakrCAwWQgIQUwW0tJPwQg0t3Z0MmeyuYUsdxHXJft7vlhM3obMwm9gFYgWWITLSyUaiZz+VpPqlXPev42XI1qZ6OtWKUTZ74tp/DpGGPhIITm1/fYp5QSBYhAQgigGPak7KQjMnXvmvkZtzf0ENFo63GawcWo83qWivRbyUFNr9DIwfc1KPE6pQDU5pbWpSZ0EURfuI6P738SET+0iGfwJKW5LJGIvFvICUkcQKDcCQhDlRljaLwkCjZHo6USk0oDOsDS4GYZxZmJd10DQTppb2xcx4w5be46JfHSqKAZ8n2K0/RVwCgn6nlJeECgGASGIYtCTupOGwJw559bUzti6EuBzbZ1uB/FXkMLKRCI25CVQRq0UxuVg+gKAsLU8gW6qDW+6SJdnuq0t+pbhUVoDwrGWOkNEWDrQ17Pard+meZ3NMM17AexvKfeSwen58fjq33rJLL8LAlOFgBDEVCEv/QZGQFkc1e2gmDXDnKWRF8G4kWuMVcnerr/Z7gYoEumcZRrpJWBSeaDfbu/cT2ykSKSz1STzfgB7WUkCzF+uq8HK3t7YP63tKlIZSdGFDKj82eMZ5QCkibBsoK9H3avIIwhULAJCEBU7NCKYDoFsXCPlWHaSC0LqJPEKQAywmuMH2lRJ9qoPIc1LEonY/3igTo0t0UsI9A376QPAEAhPguk3mTaI/xcYH9T0mwbz1bMPwg2xWCwtoywIVDICQhCVPDoimxYBNzVRQMhSWfXUDX7UU9m2qaml/TM7M8fd4EE6OlGGCPg/b5/FNwo5BBwpKT4lCAhBTAns0mkpEJg7L3poyDSuAvisgIt1ihlrQuCr4vHY7wuRpaE1ehQx3WKzrHJqSp0UkibxuYN9sWcL6U/qCAJTgYAQxFSgLn2WFIG2tmX1w6k32gA6A+AWgPYDcIClkyGANzLTIBGtHak3HylRHgaa29Lxrwb4EwScDuCdFqLaDuAPxHg4RXTb+v7uPwbxmSgpQNKYIFAgAkIQBQIn1QQBQUAQmO4ICEFM9xGW9xMEBAFBoEAEhCAKBE6qCQKCgCAw3REQgpjuIyzvJwgIAoJAgQgIQRQInFQTBAQBQWC6IyAEMd1HWN5PEBAEBIECERCCKBA4qSYICAKCwHRHQAhiuo+wvJ8gIAgIAgUiIARRIHBSTRAQBASB6Y6AEMR0H2F5P0FAEBAECkRACKJA4KSaICAICALTHQEhiOk+wvJ+goAgIAgUiIAQRIHASTVBQBAQBKY7AkIQ032E5f0EAUFAECgQASGIAoGTaoKAICAITHcEhCCm+wjL+wkCgoAgUCACQhAFAifVBAFBQBCY7ggIQUz3EZb3EwQEAUGgQASEIAoETqoJAoKAIDDdERCCmO4jLO8nCAgCgkCBCAhBFAicVBMEBAFBYLojIAQx3UdY3k8QEAQEgQIREIIoEDipJggIAoLAdEdACGK6j7C8nyAgCAgCBSLw/wHDpzQgBC3utgAAAABJRU5ErkJggg=="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-59"><g><path d="M 191.61 1051 L 230.39 1051 C 247.29 1051 261 1064.43 261 1081 C 261 1097.57 247.29 1111 230.39 1111 L 191.61 1111 C 174.71 1111 161 1097.57 161 1081 C 161 1064.43 174.71 1051 191.61 1051 Z" fill="#0cf232" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 1081px; margin-left: 162px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">s2idle loop waiting for IRQ <br />to wake</div></div></div></foreignObject><image x="162" y="1060" width="98" height="46" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAAC4CAYAAAD5Tns/AAAAAXNSR0IArs4c6QAAIABJREFUeF7tfQl4ZFWV/++8qnS6QQVGZWdAxxWXUVvI3gZZ7JalpZtKuoGGRkZkaUUckFHAFXWUUZQPbQWRTSGpkk1RBBQzSVWq0tijIoOMo6IDgg36b6CFdJKqd/7cV1XJy6v7tqqXpKpy3vfxfXTqLuf+7nv3d+85555DkEcQEAQEAUFAENAgQIKKICAICAKCgCCgQ0AIQt4LQUAQEAQEAS0CQhDyYggCgoAgIAgIQcg7IAgIAoKAIBAcATlBBMdKSgoCgoAgsKgQEIJYVNMtgxUEBAFBIDgCQhDBsZKSgoAgIAgsKgSEIBbVdMtgBQFBQBAIjoAQRHCs6rZkb+/GpZOF8Xcx80kA2gDsCyBuCUz4Gxh/BPFgnmID9w8PPBpkIL29iRdNTNEdILyzXJ6B43Lp5A+C1A9Tpr2n7yPE+MJ0HcL12ZHkRl0bHT1914FxapCyYWSY77I9PWv2yXN8BMA/zTW+8z026a95EBCCaOC5XL78jJaWZds/QKBLAOweYCgFZtxeiBnn+RGFEEQANGsoIgRRA3hSdd4QEIKYN6ij7aijI/EPiNF3AaysouXtRLxhdCT1Q7e6QhBVoBqiihBECLCk6IIhIASxYNBX3/HyIxK7te6kFANHVrRSVCkNA/QUiFsBdIHxCgAxR9knQXxsdiS1RSeJEET18xOkphBEEJSkzEIjIASx0DMQvn9q7+77NAEXO6o+yIQzcyPJUQBs/+2QFesOiBXMy4nwHgdRPGjG86vGhm59zCmGEET4iQlTQwgiDFpSdqEQEIJYKOSr7Lera+0bTIrdUzJEW60QcO/EUk5s/UnqGbdmE4lE7LHHcQGILrWTBAGfGk0nP1mlOJFUEyN1Eca5cgKIZJKkkUWJgBBEg017Z3ffJxn4hE3s/0OBD89mU7/zG4oyarfu8syNzNxvK/ugORU7Ymzs5m1+9efqdyEIIYi5erek3doQEIKoDb95rd3dfeIeBUzdBZByZS2fHkKdADq6EysBugPAklITz5nMK8cyqfS8DsbWmRCEEMRCvXvSrzcCQhAN9Ia0r+h/PZn8UwD7VLu4a3XfTGtzmcFbFwoKIQghiIV696RfIYgFeweUSie+dHtbDMbpTNwD4EDnBTZi3J0nun5LevB/ncZlp+DtXf2riFhdVCt7JD1ixvMrdEZmt0Frjc+EC3MjyS/a69RqpFaG8TgX1sHEehC9DsAyAHkG/hvgG3hqybfGxr77rOpzPgnCGlfeWAWYpwH0NgB7lcadB/AnYhoxDf7WAXtzLpVKFebq5YnCSD2NMZNSGb4GwItL8o4D+CNA98Awr9l/LzxUy1gs1WTrM4exwery4goAe9vewW0EPADCDROt/AMvO5jP+/X7OOV7RkZufUKV6+pKvNY06EMwsRKEA0r9jYP5YSZ8x5zMX79ly21/m6v5kXanNRQCxRwgQO1diT4i+hKA/YK0z0COiU8fG0k95Fa+Y8W6t8LkcwB+C4CXM7CzhfK95Y8qSD9tbev3opbCMBUXlNLWlc7MZga/GQVBtLWd9JJYfOpSJpw1TYZ6wZ4C6L3Z9OAP23v6Lpjrm9QdHYlliGMT2LpUWF5IPSDjh8nAOaPDqZ/5EXcQ3J1laiGItp7EwQbTlwEcoXFf1onzIBl8btixWJgZOB1EH1fvW4BxjjNwNU+1XFIm/xAbFYsg8vnY0zCMT4H4PJ/3R202vr40zhcNDaX+HkA2KVIFAqJiqgI0rypu3kIBuxln4rNzI6nr52JRUjK0dSeWG6B7AexRkqnATMfmMoN31UoQJRVYEsAbA4+X+TSD6CAG/n26TsShNtp71x1E+cKA3XYTUL4CCJdPPr/7x7ZuvWoqYJ1AxaokCOro7t8A8JXBSG6WKHnlsTYxvvsXgozlkN7E3i15ukF718Z/hA+yQX254cHfhCGIGApHmRz7KBP+xb+L6d3NmBkvnBDmFB28bSkpBBHxO9DZ07eWGTeWVCrl1gtgPMqEHIEstQqI3wSGOgko1Yv92c4wVuXSA2MRi2Y15/SCYuDROAq96fQtf6iFIDo71xzIRvxHAA52yF0A+GHAyKm/M/jtBLzBtjvcDsYoCEfPBUF4ymWbEwa/hIBuAPtX4k5XTY7vtinIwhp0zqogCOroSZwPps9rTg2W6o5APwdQ8Hi3CgS6amJ8t3O9xuKBWTm2l3UR0xszPG6wsTqTGVAyVTwaFeYjDNxFwNm2wnmAtwLGr6xLnybeAcJBzsaCuHkHnRcpNxsBIYgI34hDDz3+pbElLeqOgtJtlx4eKhh475bh1CPOrtRHsjNP/1q69FYMrmc9dFNrfNupQ0NDSi8e2WPprE3zbgCv9+srjA3CxX3Wup+RN/j9zrErnIwlLeqy3/u1KpKIThAuN86teFRmjC/QzAm19ax/k8H5awB6uw34AoM/kkunlFonkicsQbR3JY4jogHHhiIP0H+YU/HPO1U6Hio1z7EUbTT0PQDvcgzU9SKmUnkR0zUEtDvrhLmIOQtvfcww6lix7i0wzRucp1QCbV4S3/bBqL+ZSCa7gRsRgohw8tq7+44gQMU3KruQBrljQB1diQtB1s6w/DzBBh3udUQPK7ZaxJcse+ZKgM+w1Z0EeHU2nfqxjryCRnNt60ocaZDlOjt9GiLGt9jkD2azKWUw1T3uO+KICKLC+K1218wX778vLvMy2pYM2V8HeINN8MD3TYLMTRiC6Ow8fk/TaLmHgH+2te0bT0uVLdmtvveCY8ArbXUfN7hwVCZzy387ZW3v6juTCEqFZQ/Nkpxcymd4GaCt92uXpz8HhrIdzNQlfCU7kvywU2Wq24CUZCkQcOnE+O6fdTvllOKQDZZsMOUhPEsmrxwdTWWD4C9lgiEgBBEMp0Cl2nv6ziPGzC7TY6GzN6gMx0ZL4Sf2XREznZzLDKpgfJE8OtUXEQ1OPL/bBt2HGPQE0dvbG5/I73U9wCeWBVUGd3Ny6hg/L5NiNNqnv0nAabMGGQFB6DAFgquKSqecO+274ihvnYciiJ7+dcz8HdvCWyDCxtGRpPqb79PVta7HJPNOAC+ZLqxZuNWJa8lO/OgF76fOsHOpyrucJLVk5EYQDFw7Nb77+/3UecquhLx59yxnC6IrsyODH5wr+50v0E1YQAgiwknV7FhTrfEnTwxw7KWO7r7rABwO8J8Y9EvAuCEqO0RnT+JoZlJ2kbJhWo3ac0cclCC6u9e+Mo/YEMFyRVRPgYhOHh0ZVOoQ36ezs/+NbFh3O/a0LV4154PorFxUQ58AKtvgBybj8cO3Dt38V9+B+RQIShAq18dE/rkUQMfMNMl3oYC1HqczZ+/U0dN/BZg32TD+HfLcm82m/lz+m+YE7HrCdBuebj45oBs1gCfJpMNHRwcfDIKvxj26YkxB2pEy7ggIQUT4drR39a8h4ltsTc65V5Kf+B0r1nXCNG+btQAD40TYMDqStMs6q6mgBFHSjatLdpZawc3o7SZn8QSy500AEhEShApoqHTi0ycTtTPNpZOnh9ldasgvslvnQQlCIwOqOV22dSW6DSKlSty1hPMkA0fn0kl1crWezq6+zzLhYzYiGouhZVU6fdN2v/es/Lt2PsF3tsZ3TQwNXbdzplxlQqqwtjfNxdGKMQWVW8rpERCCiPDNOHRF4hUxk9RuWIXXLj/Ki+cXYHzDzMfvnM+YR6UdoVJTzezOrctqfGEunbrca7EMShCaRaViMfCDOIxqLkhGOV1IEiZ8ODeSVGMO/HR1Hfdik5aqi4nvmK7ElXdGAjdoKxiUIDSXI6uyTy3vXf+yJfn8TwF6c1kM+87+zUdt2PVFz0/cZndrZeCKXDp5btjxdXT1vx/E37DVm3UJTv1d+36FVKvq5qeaeQ47vsVUXggi2tl2C8Vt7+UxEO5kxi1L47uk7buqCEVR/vInAHyNw18+EDm4fsCVKUepvavvBiKcXJZdGadHM8n3hRlLxSJYow1Ct+t+wV57N0B/CiMXg1uo6M2jUrhaDzE+N5pJXhSmHV3ZoARRudhWp+byO6npCARVkqHmtLLdBB85lk5tLWOhIYinyaSjRkcH7w+DbZANQ5j2pOxsBIQgIn4jlKGvZYJuIsa7AzRd9PNmXF2Yyt/uZ9QN0J61hnV09ylf8sscLpHKm+iCbDr59SBqliAniKBhO/zkrri8VyNBaC4D+okQ/PeAjgd+DQYliAo9O+O+1hZeXc3tYa/FNKg8fuNSv2vwD0IQocPGqL4qT7AIavcLMpRFX0YIYg5egfBhHSwhVNyfHMP411x6QGV5m5X0J4iYrq6GQGhbiBCEC+LNRBA2spljgqjIdaF5vyrUUEHe+SgJNEh/i62MEMQczrh1Ea6AE4hxPmAFrHOm/dT1HiokQrmBkm+4iqd0gqPRQP7yTkGEIBYBQWBmtz3HBFFh3BeCmMOFJ8KmhSAiBNOrKUv1tJNWEFR0UxwFxks9yoe6udvWu2Z/Ix/7nibW0ONk8gnVXB5qMoKoUHHM07S7dhN0QY5yh1znKqbqThDdfV8lQN19KD4RnfAW+v2ol/6FIBZmJqira90+JgqrQHgfQMs1kSuD3MKGcvWDybfPujBU1E/9igp8QpBMczoIghCEqheFkbDCqFmjDaKzM/EWGHQvAy8rjU0bkHBhpr7Ya1CCiM5IXXmfwu5QEKWR2nmfgoC/wuQjR0dTvyxj7ny/dGUCzE+Fk0S1nlcB+lqURYQg6mDaizGSCjcA1GsTx3dR6+pa93aTTBXiYtrLplT/xyjwSdls6v9VO7ygBNHe0/cxYnx2up8qjKjtXf0nEVk3hX13gUEISRfSXHdZq1psoqgXlCCCLLZB5HHBZNr1V3chrxqPNCWL022Zgd/yVGyF3cVb836FvsOgc2eu1vMqCIaLsYwQRESzXrQBGOq26wrAVEHLYjGYRzujpLp117Zi7asNM6ZyD0znj/Ba1Fxi7Kgz9o2tcfPsarxc7LIFJojKJEZh/fQrLrV5qQmCEEREt49RWlRVOIc9XlAN/o8J/MYw+Vr7Trja1ycoQSymi3JhQ5kE8Zaqdn6kXnmvJkhEgkBHR2I/xGkIjFeVGiww85pcJvX9IB2EcRl1Ccccae6CoAShGTfC7Na1lwtrVDEpvDu6+84BrKBz5edZg41jMpmBkSDzocp09vSdzAwVAqXsXBB6l+vWV1CC0JJdyFOaugMxObXn5ll5FgiBQm0w0/ow6Wh1LsbBQ23w6ORSvDtoVjpn6HogXP2g78FiLicniIhmX3cRySsYnrNb7UKryRVdyvJ1M4hW29rwjYAZdphBCcK6d+GM8+MT58kmi/5iYQQE0dW19g0mxVTo9ZlLbsC9E0s5EWQBKhr+4yqJkj350X8VJqeOiuK+SlCCKBLVXATrqwxsN0fB+rTxlVyC9alQ7JtymaT9Frb21dXNL4BN2XTya2HfdSnvjoAQRIRvh+5DBvFHsyOp//C511AR8tstppE+HHPwKKVBhxuCIKD/WHkoH8f6+4dSf3Hps5yW9dqKpEkREESRuPq+DMaHZvfvr4JTJEwGXeHIbBZ48QqCcSiC0If73sFMG/129y6qyCdhGCuzwwO/cMqqe7+Y8KOpVj6xmnDfbnkaPMJ9P8nASfYYUU4ZXbz2fpM3jHfdPzzwaBD8pUwwBIQgguEUqJQuRDSAPDE256emPqXbeaocztQy9fmK5DmacMz6hD940C0pSyChXQqFIYjiYqzLdqbP6+yeKKkkTDQEAZdTgOLqnzNim3QXEt2S30SdtSwMQShU3BIGqXerkG+5WJcwiGLGaQxWqVztObhVxjnXTYt7wiD3HN1dXYnXFog2E3CY43V6iMz8u0dHb60IceJBEKqJHSD+DPK40hGxljpXJA5j07jakd8iVPjzWr6LxVZXCCLiGdclzyl1ocJq/A5EY2CasFIoMrcBpGwWtmxyVmnth6XRq0cifVAdMVfGYpru3yUhUfn3xxhIW+lW3VOtzowlIoJQDXb0JA4Fkwq4Zw9YWOyL8DcwrPSZXiktAfoDDPM92eHUryMBPISbq62/KFKOqkH7pk+NKOXokyA+NjuSUlEBKh4Xgpi0JduyiIKs6AL0SCm96Tu18xhgTFHN22JrRwgi+hmn9p7EqcSkYh45800H6U2b8F2nHw7SWJAyURCE6qe4+zScmdj8RFCLwGaGug9SylcRIUFYJLFi3VthsjOrmp9cpd8VOdAJOnVMwAa0xcKeIMrCdHb3n6U5FQQRReWt/tLU+O6X+CXjUY2V1Dg3AdQTpPHZZfhhGLETvTDTEQQB55rAex2Z87y6j9QxI/w4m7+GEMQczXFnZ/8hbPC3nblzPbobZ+Bqnmq5xKkuUHU0se8jkzwqglACJRKJ2GNPUN8Li/1XAbzcW0h+mEzjlIJhmgbo3rkiCGvBK6ryPkNFIgpC3JZqUKe+iQL4KgnC6lqpwQymq9RrESR8i8rwF2PjA5nMwM/DyF50iKBzQFDRa3cPUFeR/ReXxPkrfm7WbipMKnCG4sbXmVmFjPEITeOu8gogpxQJiIAQRECgqixGh3b3vzrOfCoT3gXCQbYQGyo4318IeAiEGyZa+QdeRsC5jFAaJUGUcVILwGSB3sPMZ4HotdPjttQ6vIVBm6fGd/+x2s1GHc3Va67USax1go4F4xQGDgawt20h2vZCHurfg/HtCKPrRnmCsLc1+90CXmOzNewA8Fti3J0nun5LevB/qwn+aJ/LibyxCmCV1EmlIy1jZr3DAEYBSrXGzbv8iGFWm1N0BwhKbWQ9NhUmtXevO5RgnusIS7PthXtG9zHw7QP24Z955RWv8nuVag4EhCDklRAEBIF5RyCkE8S8yycdFhEQgpA3QRAQBOYdASGIeYe8qg6FIKqCTSoJAoJALQgIQdSC3vzVFYKYP6ylJ0FAECghIATRGK+CEERjzJNIKQg0FQJCEI0xnUIQjTFPIqUg0FQICEE0xnQKQTTGPImUgkBTISAE0RjTKQTRGPMkUgoCTYWAEERjTKcQRGPMk0gpCDQVAkIQjTGdQhCNMU8ipSDQVAgIQTTGdApBNMY8iZSCgCAgCMw7AkIQ8w65dCgICAKCQGMgIATRGPMkUgoCgoAgMO8ICEHMO+TSoSAgCAgCjYGAEERjzJNIKQgIAoLAvCMgBDHvkEuHgoAgIAg0BgJCEI0xTyKlICAICALzjoAQxLxDLh0KAoKAINAYCAhBNMY8iZSCgCAgCMw7AkIQ8w65dCgICAKCQGMgIATRGPMkUgoCgoAgMO8ICEHMO+T+HbZ39x1LwPenSzLua23h1UNDqb/71/YvMdft+0vQ+CU6OhLLYOB4EM4B6E0AXlwa1TiAvwB0X2t84vyhodufbvzReo+grTux3ADdC2CPckkGjsulkz9wq1nxDlYP0g6AngL4VwxOIx67NTc08CcAXH2TFTWpvXfdgcgX1higlQwcDGBvALGZOefHmGmMiL4/udS8Z+tPUs9E2P+CNSUEsWDQu3dc7QJeWrROB2Eym05dFfjjjJiA6hDSSEVqX9H/ejI5CeCNbg0TcO/fd2k9/oF7bnwu0s7rsLEFJogKRBjIMfHpYyOph2qBy/qeYrQewKcB7BeirTwT7gEbn86lB7ZETFYhxKi9qBBE7RhG3kJYgkgkErE//8U4htn8d4Bex4QLcyPJLwpBRD416Ow8fk/TaLmHgH/2ap0Y3xrNJN8XvQT112K9EUQJoR3MtDGXGby1CsSoo7v/aIC/EZIYnF0VmHF7IWacd//wwKNVyLHgVYQgFnwKKgUISxAdPX2bwTiz3JIQxNxNakdX//tB1sIx+yH8DUxFtQLxbgx8NjeSvHzuJKmfliMiiEJJNTcRfGTc6lD1OKs+CeJjsyMptYsP9KhTA8WMSxl8rk2FVLHwz5aVdwWwl0cH25l5Yy6TUiq3KFVfgcZUSyEhiFrQm6O6VRDEdWCcKgQxRxNia7ajp28W1gCeBOGU7Ejynkb7+KNCKyKC2G6CjxxLp7aGkUudnh/bhoNh0vkATgQQn12fRyeX4t1BbALLj0jstmQnKdVsn0aGpxm4xjBp8377mX9MpVKK0Kaf3t6NSyfyz/Uy0QeIcVSlHFC2qQuy6eTXG+k9EYII8zbWaVnnouV3gqjTYdS9WLokN8T43GgmeVHdCz+HAi4kQdiH1d7ddwQB3wWwp+3vBSI6eXRkcMALguXLz2hZsuyZKwE+w1Euz8ClS+P8paBOIm09iYOJ6RoC2h1tjRNhw+hI8pY5nI5ImxaCiBTOhWlMCGJ+cNdmQWNaW6Wee36Enode6oUg1FA7e/pOZsZ1s9VDdFNrfNupQ0NDeTc42rv6ziTClQ610pMMnJRLJ38SFkYPVdXjBheOymRu+e+wbS5EeSGIhUA94j6FICIG1KU5SZOpB6aeCKK7+8Q9Cpi6C6C2GWn5gcl4/PCtQzf/VTeCjo7EqxCjnwL4R9vvoe0XzrbdTiVENDjx/G4btm69amp+3tzqexGCqB67uqkpBDE/UyEEUf8EoSTU2Il+H6d8z8jIrU9oRkAdPX1fBuNDtt8KRNg4OpL8Tq1vlrJrtO6kFANH2toaN5lXj2VS6u5IXT91SRDtXf0nEbFtcrx3AHaE27v7vkrAB6f/Rvgd8tybzab+7DcTzrp+uny1Q1i69JnlTEgw+B0gHATGS+0vAsCPERsZMG6emNjtZ0F2DX5Gat1C5Tk2wvXZkeTGchm/9mfh2dP3EWJ8ofw3+wUoNf6WZU+vJPBZAL3N5smx4wWD4W8ZfJM5mb9+y5bb/uaHve53ZYB89Ak6jID3Alhh81jZAfCviWjzkhjfXtYNO8flN39BZGp3jD9AHV9jq8KttfWZw9hgNSf2canmtxHwAAg3TLTyD4IYV1UlzTsxvSgqnbhhzSEdDmAZLI8r3sKgzVPju/84yDvpNe56OkGEJYhDVyReETOt08MrpsfIfAdMrM9mU8qwXPPT1bWuxyTzTgAvmWnMX+1Vc8cRNFCfBFG8iKQmbZ/SGJ8zmVeOZVJprzG7LJyB6mqOps+SyStHR1NZZ58zF9Lo4wBeHmIengJw7v77cNLpBeEgOc+b1PVAEB09iXeA8Q1178Jn/HkwXQ7T/ESYDy5E+08x8wdymVSyvbvvGPsN9HojiCrem3EGruaplkvGxr77bMh3//co8DsQo/cAuMwiBt3DdGY2M/jNEO9wRdF6Ioje3t74RH7PmwAkbIK6niA0bsuTAK/OplM/rgUTe11rQ7DLMzcyc7/t70+SSYePjg4+GFU/c9FOXRKE9ijvc/lLgVO64WonFgszJnzYzye98iXnsRhaVqXTN223A9/Wu2Z/Ix/73mwdZ6ipKRDoqonx3c5127n57fAXlCCYVxPRAZ6LjgYOJvxoqpVPDLAjpo7uvrNDtl8A88Uw6GEwbit3X08EcUhvYu+WPN3gUDUEfXEeZIP6csODv3GroDtBEHAFA//uSg7AIwWDD98ynHokqCC6cvVEEDp7gtut9pJragqgY2bGFVxbEQazzp7+dcyWVqQcnkMtTDWTcxgZqilblwShBtLZ3fdJBj5hG1SqNf7kid6eCP1riFjnQuZft1KVckUunVSXZaYfF32i+r10yQdbinFhLFpSJ4tOlws0k8y03s37xZ8gNi6dmHp+E4heXezLPAwo/7/1ByXHL6cFZ3NLNpO6pvxvv/btY9aoWG4GoHal5R1pAQS1wGTANEHgV3DRva8cm2hGjAAk39nTt5YZN2oWtR2kQiiAHmHwSwjoBrC/TVY1B8qH/tBICaKrfxWRNV4wuIWAdwHY19bv3QCp2D/lZ5zj9JXc0MAfy3/o7FxzIBvxH6EYw2f2Y6l7MKzeG5dxlcs/brCxOpMZ+HlFG3oV0yQAdemsPA/KI+c+Aj0HmO3WyY9oc3ZkUKlja7q8VS8E4WYUdtsoFDd78WG7emmubsB3d699ZR6xIQLU5qq4QjC+k8skT6kVf937ENXf6pYg2roS3QaROuapW4pAAFtChf1hZmny9GLQ7CQmGTja6d7moo++vWDwh912YV1didcWiDYTcNjsSeO7UMBandolzAKu2gxrpA7TvocO3gojYMb4AufYLVVKHBeA6RLHhaEHzanYEWNjN2/TvcAdK9a9Faap5tzux74DxJ9BHlc6sKLOFYnD2MTX3NRcUZwg7HJWY6S26uTpeygSi/15kAln5kaSo84FwsOP/kEznl81NnTrY078PE6V6sT6VS6YF9vxO2TFugNgFKbuH0r9pdbFpB4IwsOt1PWUVLHGWKv23Ozq33zUhl1f9PzEbbNPkHotRa3zEWX9uiWI5b3rX7Ykn/8pQG8uDVi7aJfB0Lu3TUPlaYfQsHvFQtbWtn4vo6Wg/KGnA7QFdVcrBf263q4XZeDROAq96fQtf3BOaJgFfIEIwlLp7L8vLvOwpVBHT+J8MH3edqwuMPOaXCY1E6m2NHg3Pa2fH7pS3cTzuBmgXieO9UAQLv71ycmlfIaXus3aDe/y9OfAOG+WWoLwlexI8sNOUnEjCAaunRrf/f21GqK9Fp0FIgha3rv+pUsK+Vcy0xoCTtbETfK8mFbpDAPPNabWhbezq+9qJvzL9AnCYw2ota+o6tctQagzQ3t3n7qNeFp5sF63Vjs7E2+BQfcy8DKrvDq2k+UhUnw8dgbtXYnjiEgF9bL0g+qjyqWTp9s/wtItzR8CWFJqMZSRSbNbeZpMOmp0dPD+hiOIgF4eOlJlwkW5keTnnGPu7Ex0sGGdGMueHuqEsimXSVbGPXJUdvFjV7Ynz6CFYT+isCeIYugG/AggpWosvZbImZNTxwTx7HIhTe1FKxeCcHW0CDv2eSCIKEVSbeUZfGEunVLxsLQqNM3p2NcDrRYh57u/WmSdXnOjaGSu2tC4u97ZGt81MTR03c6KRXW2a+x2gD4EsDLQWZ5QHvo+6ujpvwLMm0ptaq/mKwIyDTqNwG/FXwhkAAAexUlEQVQH6EAiSi+JbTvZyyZil7GnZ80+eY6PAPgn22KhjZlf5ycI11OAc060HiUOl9tync6uvs8y4WMzbQSPoaPqdHT3nQNYN2Gnn4UmCM2mIrSHTGdn/xvZsDz6ptVuunHpCWJ+VBgRnSCiXEb+DNCZ2fSg2tC52lcq3zkIQThmoZ5PEHCqfjzUMo7TBj9QgJGIwbxhxttI753gVGV5qX5qeYObhSDC4lPxEWoIQqceDLu4a42AC3yC0JCe1jPO673Su21yxUZJHwZkfoygdUIQeYC3gnEFTNwWxKVac6FuvgliTlVataxXDXGC0BiPtbtX5wKjVEQH7MPve/Rxuo7I0k2qRzv5laqfyo8vCqCbhSAA/KfBO4/NZL6vLsP5PhXHag1BaNyTA91dsXeuMwKGJRm/wYRRMWnlASo84/z6tE5HlSHGK/z6q3UND9K/X5mICMI73Dfxbo5LqCWxeNRg419bWpb9UqdZ8JJd49Qy3wThqmb2w3y+fq/rE4QCwbnAsOYjq3hBS/aG9p6+84jxZZvOocLvuGIBi9CLoXjT+m+vMRE7DsQnlbxtpv2g3dIy1rOKKWymtEAEUYzCabfvPGLG8yt03jpeH0aFEXABTxAaJ4uqPWQ09quKhcwlkODJucygim46p09EBOG7OCvPqxaTP8pglYjJFtab/gAy35sdSf1nmIHOt01gvvsLg4Vb2boniIqPQ5Me07HDmn7RnHWdxmfNCcX3JdUAOeNNYeIVBlkhJ97KgPK+8koiopSjjWeDcLEhuL1ggQiiq+L+ilfsHNf3vmIzsYAEEebE6PchaxbgYAThkxfar9+gv88XQZTl6exJHM1M6q7MdA5sAONMfHZuJKW8BQPd6xAvJv8ZrnuC0OzEnmCDDrfdKq2wP5QjNyovGmopDBPwmiIUs412FXrrgLmZp2MQMc4H4RCPm6qeMyAEUYSn8hSH+1pbeHXQ+PtlkBcRQVRsLsKov/yXhXAl5psglHQuFypD5VvQOBFUfcrzQ8zlHoTn/Sy/Nufj97onCGsBcQTgY6bpo7PGyDztouo08BHwV5h85Ohoyrpl7NxBBEj+4ns5y2XSCmA8CrJOFNMxcYQghCCCfOSaBbjCRrPYCKLkBv9pAi52YBg4TLfWsUHj4h5kjvzK6G5tA/CN8ODX7lz/3hgE4XFPobOz/xA2WKV73L14SJh9E9Jph7CRi/OehZ9hNGiMIJWU5HEr7AOxCvT3n62xXR8oFJ7doyncXEXFdAcI7yx/mG4kLyomvfp0+rTX3Tc7IKWLE4nXAli6Z3K785KkspNNLOWEX9wvfSwmeN72r3ZBdt610q1V1bY9l/UagiAqmX5GVeRmfyiD5rRDlGOtVKquvIN0tXevayOYdzn0noUXIj/+gmBcCxPDS5aYf3RTi4RZMOrZSI25IYhVRKwSupcN+GKktn31TlWI8ySsii7CE0RRPan/LtXFp49mMykVpt7THqHxEAuUojTMolzUZOx1PcAqZ3b5CXXRNkx/UZZtCIJwMyYviz/1q9mhfSsXeTc7xBRPvWF2rCe60i1wmcsE7wDo9Gx6UMXZ8TWKCUGUXlsNwVTcggf8TnMV34BuN7iQbq46eaoNBFdxCla5NqZiK+wxrRYrQXiqmgxjZXZ44BdeC6Y+H0RwG1jxIqN5LcO4u2DQN+8fHnjU2Z8+H4R7LLYoF/ha22oIglCDrLgpy3TmZItxiz1eky5EhuaikWXkNkzut0WL9bwd7KKrvDSXTqp8EL7koOSvUIUVK4oXEwCXOFqbsunk14K+4HJRLvGiiSkKpP4KimnQcgthpLbL1tl5/J6m0XIPAf88S+ZgIWGUqtlpyyiA+KPZkdR/+H3fjnUpz4w7YuCLMpnU/yhZJKNc0LeoxnKalzBlMDabBKWaKEZ8dbnDUGmHwEYCTrHpkj3j4mv80EPfgNSGghCCmH4rKi8thQu1oUtWv5AniKL6o+J+h2eYd90nol18Ne67i/gEUVQ1Fe2UAw6PwklmPiWXSQ16LT/tvesOQt68e8bb0Sq9nYg3jI6k1P0c7aOLtVUqOA7iT7TGsHkib3wJ4DPsDQQN8lnjkhlJ9YY5QVTsMgm/Y6ZBAl9UQsL1DoNmgVcXapTrazljnac3geZDLzDTsbnMoLJJ+D6uweSEIKax0wXrC5oXuOQhouZiOtJucb/QlMH6tLrrxU4QLoEN1WvgGiLd/uG2dyX6iegGWzBOiySYeWMuk1KbUK2moHR570Oly3vOHChPl/JxzCQJAv4PBT48m039znfhqIMCDUMQpR2ZPd/0cwDUf6UgZu5G5ko7hAN5n9vTGh25FfE1SBhlRQ4co+9VHH+tAIK0Vpc0qFYjtZ+7bpj2g1x089ydOXM6uxi53cJ9wzCOzw4PqJwJHrs4ugpAn7PAQhNEcWfbdyaRFURw5gZ9gOx6buG+CbR5SXzbB51BIhc7QSisu7rWvsGkmPJotCd0Ut+qrzrYLdmQigpLjM2FfMvFXmlf29pOekksPnUpE85y5ECxv5ah7mnUAT+gsQjC4e5qB1Bnfyj/7pKntvyz8+Jdxby4HCULDHyTp1o+qntxDj30+JfGWuPngOl8XXY1rx1umAVcQ5zqTw+hwKvddilh2p8vglBCuyUMItC/ccG81pkwqK1n/ZsMzl8D0Nt1H1M9EIR7wiB+mAycMzqc+plzd+qeZAoPkZl/9+jorfYMdtbQhSAsGKijK3EhyMpBYn+2M4xVufTAmNei60ESqtrTDFxjmLR5v/3MPzrzoJScElROkk+6pCNWGf42ZtNJpQYLZLcUggiJQEdHYj/EaQiMV1VU9TkFVMRlKjcQ8Pa0TsddamIczA+DjP9SqUettJGMdpCVWtB+tNwBwja77G65EcIs4NbCWhnMTf25dB+D1A5oeEnLsrPKwczCtD+fBOG24y7hHCTlqAmgZXpqF1jFVJYjopSjnhfAhCCKaNdosIZ1kl329IUlBxZbvKdZK87swIKugQSdq5T7piDkUjhvxRvqBOFxEvCNoaRNLxhCT118cZ75KhcNTvaFP8Bk8cNkGqeYMe62Bw90y1ERZgFXnbsdrWcEmx1iJEz7800QRbfFxHkEUj7sbh+oE/NxMD4D4qPsl6bq4QRRFrRoJ4ndBFBPgBfGUYQfhhE70ctlUwhiBjIXg3UhqE1LvYN+6WzDz+F0DStVbyFmnKdzia2h3Tmp2lAE4b5b9r7kpuq52CFC+dtbR9ClT58LgnJvdRqkdBP0FJg/DRPXKPVIhbHbJc92mAW81Cm19yROJaav6+JCOXM4hGl/AQhCDSnMB/o4GbxhiYEtFW6ehA/nRpIqo1gkT62LsJV61qBzQFCOFcWb/96POjV9cUmcv+IXl6pW2fwE8fp9od1cnbLVarAut2fFXFu6fQ2RpTZ6XQiMVG6KNCP2b4ZZmGDDCiw4y4FCBRcE8O28YXyhnomi4QjC5WWsSBHqnEyXxCuhE7iodpV9Ib6k5SQG94PotbY49Uqt8ydiGgHj5omJ3X5mzwWsScGp3dWEWcDt41TJ7g0mFZtGhYKwR5KdRYRh2l8ggrCGNR0UEdgAWOljy2PaAfCvwfhaOTnMfCyQUfVRtEsYqwBOKK0IgL1Lp9KS6gKjAKVa4+ZdfsRQnv+oZAuxCE4XrTeCUIK5nqpdcnr7jJvae9cdiHxhjQFaycDBtjlTVXcw8AQYW4jo+5NLzXvsYT6sjUEcm8B0SeXGkm5qjW87NWhmymrmp5Y6DUcQtQxW6jYvAprLdqFckZsXGRlZvSBgucQyX8bMa0vq02cNNo7JZAZUKuK6fIQg6nJaRKiwCGiiZfrapcL2IeUFgSgQUEQRM81zDaL9OW+eFiQ9ahT9VtOGEEQ1qEmdyBHo6O67BoDKLKdCFPyCDf5Odjj166AddXQnVgJ0R/miE2viFQVtS8oJAoJAEQEhCHkT6gIBTTrGwLHyXYySgevXBQAihCBQhwgIQdThpCxGkTTx8gNdbrIuR/Ukzgdbl6PK7seRh2xejHMiYxYEhCDkHagLBJReNm6adwN4vU2gp5jpvKmduyXt3mDl3y1vspaWT2jCG9zdGucTgnoA1QUAIoQgUIcICEHU4aQsVpF0cYtKWBTdWmE8qP7tcVtdHSj+AMN8Txj7xWLFW8YtCPghIAThh5D8Pm8IlMIcXMTFPMMhb6tbYj7IBvXlhgd/M29CS0eCQBMjIATRxJPboEMLc4u6PMRxBq7mqZZLvCJuNigeIrYgsGAICEEsGPTSsRcCiUQi9ugTsbcTeD1gHgHQP9puoVZ941hQFwQEgeAICEEEx0pKCgKCgCCwqBAQglhU0y2DFQQEAUEgOAJCEMGxkpKCgCAgCCwqBIQgFtV0y2AFAUFAEAiOgBBEcKykpCAgCAgCiwoBIYhFNd0yWEFAEBAEgiMgBBEcKykpCAgCgsCiQkAIYlFNtwxWEBAEBIHgCAhBBMdKSgoCgoAgsKgQEIJYVNMtgxUEBAFBIDgCQhDBsZKSgoAgIAgsKgSEIBbVdMtgBQFBQBAIjoAQRHCspKQgIAgIAosKASGIRTXdMlhBQBAQBIIjIAQRHCspKQgIAoLAokJACGJRTbcMtlEQ6O1NvGhiiu4A4Z1lmRk4LpdO/qBRxiByNj4CQhCNP4euI+joSCyDgdNBmMymU1c18VCbbmhCEE03pQ05ICGIhpw2b6FVNrY//8U4htn8d4Bex4QLcyPJLzbhUJt2SEIQTTu1DTUwIYiGmq5gwnb09G0G48xp1YQQRDDg6qiUEEQdTcYiFkUIogknv6On7zowThWCaNzJFYJo3LlrJsmFIJppNktjEYJo/EkVgmj8OWyGEQhBNMMsOsYgBNH4kyoE0fhz2AwjEIJohlkUgmi6WRSCaLopbcgBCUE05LR5Cy0niMafVCGIxp/DZhiBEEQTzKJuMfEcFuH67Ehyo1cZ5Sr76BOxtxOZG8E4EsCBAOJWHcLfwPw/BBosTMUGx8Zu3hY1jG1diW6D6McAdi21/QQbdHhuePA3fn11dPW/H8TfsJXbboKPHEuntoaty8C1uXTydADsUpfae9cdiHxhjQFaycDBAPYGECuVLwD4CwEPMfNgYSp/+5Ytt/3NT45qCaJ9Rf/rYfLtBLzG1sc4M5+Wy6SSHuOwilv95o1VgHkaQG8DsFepnTyAPxHTiGnwtw7Ym3OpVEqNTZ4mRkAIogkmN0qCsIjhcVpLhM8B+KcA8OSJ6JYpogvuHx54NED5QEWW965/2ZJ8/qcAvblcgZlOzmUGv+vTALV3911DwGn2ckHq9vb2xifye94EIFFe3Ino5NGRwQFNn9S5oq+HTf4SQG8PNKhioTwxNhfyLRePjX33Wbd61RBEZ+eaA9mI/whFkio/gcjBulQZxyYwXQLgxf7j4YfJwDmjw6mf+ZGOf1tSol4REIKo15kJIVdUBKHa2ZmnKwg4xbYDDirJ42TwhtHh1H1BK4Rd6APs5qEjFtUPMb41mkm+z6vPjo7EfojTEBivUuUYeDSOQm86fcsf7PWWLz+jZckuT38OjPOqwMlqioFfGWZ+9ejorX/SyRSWIFzJgfjs3Ejqeq9FvL133UGULwwA1BZy7gogXD75/O4f27r1qqmQdaV4AyAgBNEAk+QnYm/vxqUTU89vAtGri2XNw4Dy/1t/2ALQL6fbYXNLNpO6Ztaid0Rit9adlGJY6iTns4OAHIMeAXErgC4wXqFZHHcw08ZcZvBWP5mD/N7Z07+Omb8z0w+PxdCyKp2+abtb/c7O/kPY4HsA7D67jH/d9q7EcUSkZC+ph/jO1viuiaGh63ba2qKOnsT5YPp8xfhLqjfAeNAqr7BibgNIEU5RPWdviPGtJS1PnjU0NKTUN7OeMARxSG9i73geNwPUa2tknAOQgwuxqGYKYDzKhByBnmXwSwjoBrB/JfZ01eT4bpuEJIK81Y1VRgiiseYrkLRhjdRKtTKZ3+sKBp/l6OBxZvrAAfuadzj1zYesWHdArGBeToT3OBbKJ2EYK7PDA78IJKxHoe7uta/MIzZEwAGlYr62BI39odyDrw2jvbvvqwR8cFokpjOzmcFv2kVs604sN0D3Athj5u/0B5PNM/9xX9yn08u3tZ30EqMl/1GAz3cQxZNk0uGjo4NFQrE9QQliuZ7YxwFckE0nv+51cnCpW2DG7WaML9gynHrEyWltPevfZHD+GodarcDgj+TSqS/XOudSv74QEIKor/mIRJqwBNHWlTjSILoDwLIZAXjMjBdOGBu69TEPoaiju+/sFwzJl82qy3wHTKzPZlNqoar6sU5G+edSAB3jtWiXf9PYEGb17WWH6O4+cY8Cpu6yqVl0izd19PRfAeZNtob/DwU+PJtN/c5noNTekziVmL5lJ1Q3mYIQRC3koGRt7+n7CDG+YJO7AOaL998Xl3kZoEuG7K8DvKEKHKp+H6Ti/CMgBDH/mM95j2EIorio7nU9wCdW+bEro/CnCbjYVn/cZF49lkmpnXZNj2YRS7XGnzxRp5Zpa1u/F7UUhqc9eJh/ASKlCrPUTQxckUsnz9UJVHEyYNzX2sKrh4ZSfy+Xd7FvbMqmk18LMkgNCYEJF+VGksohYNbjRxAui3Sgk4PqSGFltBR+AuCNMx0HVxUdeujxLzWWtNxJQHu5PgGfGk0nPxkECynTGAgIQTTGPIWSMgxBKLdIMvmnAPaxdRJ40XNbbIIYlIMMqtLdlR+YjMcP3zp081+d9R1lC0x0JrH5AZsn1H8avPPYTOb7O5x1O7r7zgFwpddi19GR+AeK0dkMKPfPt4BQiHHhXU4jtte4nHMDF5djL4KwjOTLnrkS4DNsfeUZfGEunbo8iFdRpX0HQU9C011qbESucxNkrqVM/SEgBFF/c1KzRKEIoqv/JCLLEGw9bp47fkJ1dvV9lgkfmynnvpD7tWX/XbPrfs5kXjmWSaWd7ThOG0+YFFtpcEGdbMpuq1o7hEaV5dpHGNl1ZWsliKnx3X9cKzko87nTFbgaQtfYiOYMt1pxl/rVISAEUR1udV0rDEF0dvVdzYR/sS3sOs8d3/G2d/cdQcAPASwpFfY1KPs2WirgNB7r8ltU2B9KKqKdBfogMT5baqrAzGtymdT3Z5OQ0xgeDblFTRBEOAGMN3FRnVe+iKdY/ePZTPLSICcHJZOLquvDuZGkOn0Efrq6jnuxSUtVhrt3TFfSGPYDNygF6w4BIYi6m5LaBQpKEDojsJee3ksyzW5SnUYiSZEZxP1Uc4fBsje0d/WvImK1iFkLqm58zvarxcAFH+rqWrcPG+Y7mXFSaTGdcQYIoWIquitjudO9loGcOTl1TJAb2kWCqPAOU3++GyDtnQy3eWdwCwHvArBvuQwxPjeaSV5U+1ssLdQDAkIQ9TALEcsQnCA0eY+rTC7U07NmnzzHR+y3r6MiiIoFjfA75Lk3m039uQyd4wQzfVKoqKsxPjtOKNpTht8UKZvB83lj3xjxwQC/mpne9sKJ6pBZIUp0jYQjCHcxmD+azaSUR5JbSJDpunpXXb8RBvw9QBiXgC1JsTpAQAiiDiYhahHqhiCqJBsnHpqTziQDR+fSSeWFYz1O+0M5btObj9qw64uen7itfAHQaWOpULdoyMftZNDWk3g9MZ1PhOPAeGlV81gdQagYSBMAdrH1uZ1hrMqlB8b85BCC8ENIfp8+EQoUzYdA3RBEsNhJgSbAeQHOrsqoIBDHKcFhQC8w07G5zOBdqmNNUEBXN9qyoB6XBP3G8qQV6hB4+XTB8ARhhbcAGTfBNO+0q3eUmqg1zifYXXN1AglB+E2T/C4E0cTvQN0QREQ2CGshd95gtpFAW++a/Y18fBiwwn9U2Bmcdgg7uTjvWfgF9etYse6tMPl7AL/S5xXa9sJFst8TKG0yDU21GPcr19xavJis8Be22Ee6i27M2JTLJO2RbCvE1BBEZA4FTfxZLcqhiYqpCac9OEFU3lSu1kCruU8xa6deK8xOVZBdVeRmfyj36bRDEHDv33dpPf4fJmMFx01tz3Ac6ubykp243RHzSHXzZwa+Axg/norTg1uHblbhvLW2gJoIgnH55M7dLyzHPNJdVgPwuMGFozKZW/7bDfPOzsRbYNC9DLysVCbSuap1rqV+/SAgBFE/cxGZJEEJQnXodCEtL54P3HPjc2EEqtilA3+FyUeOjqZmggSGaVBT1s2Y7FAhVSzybnYI1cXsWE98FwpY6xYiRHO5TO3or0aePxw0rEgtBKEz+uvCpBDR4MTzu21wC55XceNcsVlE9qIap1iq1xkCQhB1NiFRiBOKIOr8opwdj47uxErAihll3bVQp52l8V0unHUK0HgpqbIOErGM3AbRy+zRYr0WSV2cp7Dupdp7AyFsEDqCcAm0OMnMp+QyqUHd+6SNcQVvctS1UyKauwnYg4D/MYHfGCZfG+WmIIrvQdqoHgEhiOqxq9uaoQhCE2oj7G5SGW3jpnk3gNeXQanmZq4foM67DgCPmcA5BLqtHPHVTUVWeR+CLwbon2yJhZ4lk1eOjqayOjm0l8s8Yjvp2ujs7H8jG1ZYkz2nf6+RIKxTYO+6g5A31UI9nUWOgd8ibrwrNzTwR50sztAiAJ412DgmkxlQrsqBns6evpOZcZ3tXkaFd1mghqRQ3SIgBFG3U1O9YGEIYo6C9U0CvDqbTqmUoZE9ml38djAue8EvSAWIU6cK1zsMlZfD+Ocg2r2cHEiRjVeuCV2gviBJiMqDV/GTWnd55kZm7p8FSAQEYZ2QKhdrEGjzkvi2D+oCG3Z1rX2DSTGVN2Pmkhtw78RSTmz9SeoZv0krOQYoTzBbsD/8V2Fy6qigF/b8+pDfFx4BIYiFn4PIJXAShN/tVp0e2y/jWUlofbjvgO6W1Qxck+9B5SywvJcAuBqZnXYIZ99+xnldfb9dermPYjpP+jIYKqPdTIgMpSZjfCeXSaoMfrOM2n7RXJ3yW30YuBlEq22/qXSj65yhRabnrqdPyfSh2W3Rja1x82wvV1nVFxl0xewQLYqc/T2oqplzqbNwCAhBLBz2c9ZzReIb4CEUeLVbzgKPhEFPATh3/3046cwPoG5OFxC/jBnrKhIGER+bHUmpsBCRP54+/C72h7IQlQEFp8ULpBrp7O77JAOfmD0o/rlJOHVsJPWQc7Cl1KRHg/nzAL1OC4aLzGEJQrXd3r2ujWCqXf10MqMi0U8dNTp6m7qDMetxOQUorvo5I7Yplx5QcziLuNp6EgcTk8r5PR3mWzWqnBuCnj4ifymkwTlDQAhizqBduIZdsqqptJaPA5QnxvCSlmVn2VNpuiSfKQ8iaMrRcSJsGB1J3jJXo/fKv+13CnDaIaZlDHh7uqMj8SrESNkQ/tExvlnpOS3CZPNtIIsUbEmYoG5A/7YUjqQc1FAbgrwagihFaXXm5lAr/KW5dPLjOtfbjp7EoWBSsapm7CLlwVkpVDEM0FNW+lQT7wDhoMq5pT/AMN+THU79eq7mXdpdGASEIBYG9zntVadfdux6tfr2op8/bQbQp8k37SfzU8x0avmGsl/hWn53OQn4xlByCVKnFtBrc+nk6UHiGLV39a8hYmWYfXHIMexgIhXELmMw3227g/CIGc+vcGbuq5Ig0Nl5/J6m0XIPAf9sk8/TAB3i8p9myIoc6IQoUsyGxFOKzwMCQhDzAPICdFFOb6lyEtt3sJYoXjkfEolE7LEnSBGESiO6XwDZ8wS6eiJufFyXxCdA/dBFNKHFVRu+Oafd7BB+t6edAnb0JN4Bxjdc1UazK+QZuLFgGJ+4f3jgUY2xW0ts1RKE6roUnXbAkUJ2aHIp3uNmgFZ5s6ll6jMEy05S8c5oJkmdRDcX8i0Xj41999nQkygVGgIBIYiGmKbqhFT6YoNJ5Q54J4C9bK34JnaxvG5anzkMhPVM3OOISrqNgAeYebAwlb99vr1WKt1dLdarSBGqQ815+qg2QZLCp2XZ0ysJUHmZOwHsbTt1eeFTkddad7GtFoIoyfZNmwuvgqLA4I/k0qkve71Nlqpxgo4F4xQGDnaOS4UPAePbCzHv1X0FUqsWBIQgakFP6goCgoAg0MQICEE08eTK0AQBQUAQqAUBIYha0JO6goAgIAg0MQJCEE08uTI0QUAQEARqQUAIohb0pK4gIAgIAk2MgBBEE0+uDE0QEAQEgVoQEIKoBT2pKwgIAoJAEyMgBNHEkytDEwQEAUGgFgSEIGpBT+oKAoKAINDECAhBNPHkytAEAUFAEKgFASGIWtCTuoKAICAINDECQhBNPLkyNEFAEBAEakFACKIW9KSuICAICAJNjIAQRBNPrgxNEBAEBIFaEBCCqAU9qSsICAKCQBMjIATRxJMrQxMEBAFBoBYEhCBqQU/qCgKCgCDQxAgIQTTx5MrQBAFBQBCoBQEhiFrQk7qCgCAgCDQxAkIQTTy5MjRBQBAQBGpBQAiiFvSkriAgCAgCTYyAEEQTT64MTRAQBASBWhAQgqgFPakrCAgCgkATIyAE0cSTK0MTBAQBQaAWBP4/px9TTYaZec0AAAAASUVORK5CYII="/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-65"><g><path d="M 211 701 L 211 726 L 51 726 L 51 744.63" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 51 749.88 L 47.5 742.88 L 51 744.63 L 54.5 742.88 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g><g data-cell-id="8N6JJebqrzA787TgpwUj-66"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 737px; margin-left: 143px;"><div data-drawio-colors="color: #393C56; background-color: rgb(255, 255, 255); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; background-color: rgb(255, 255, 255); white-space: nowrap;">no</div></div></div></foreignObject><image x="136.5" y="731" width="13" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADQAAAA/CAYAAACvv+soAAAAAXNSR0IArs4c6QAABKNJREFUaEPtWH1MU1cU/wFmWAoraJawyFacgIIoLszMBHCZm07M5A+D4seyaMQvVDY+WoFCakVWSoFaUReNcTP6h44lOpdpNsVghpqp6BgwjNvYMqe2dmUw5pCvdrtNSlree7nvMdYH5N2/mt5zzzm/8zvn3POun9PpdGICLT8J0BhnU2JojBMEiSGJIR9HQEo5HwdcsDmJIcEh8/EBiSEfB1ywOYkhwSHz8QHBDFkf2/FJ7XnUX/kGVqsdDocDQUEyzIyZjjWr38aCV+dh0qSAEcEYGBjE7dutuFh3Fd82tcFi+R2Dg4MuXVOmKBA1Q4nUpQuRlJSIYHkQq40hQHb7H9i6XYsHD6xegstSX0NxURZ6e/tw9FgtTp3+YsgIm0alchrU+Zl4eV4cb1AkKHWXr8Nk/hidnX9SzwUGPoO05W9gc2YG5HKZlzwvQO+/tx67dftx7fodqjEiEBIiR0W5GglzZ1Hl7R2dKN17EDdufkeVHS5AgqfTZiMmOnJoiwpo8ZtJrpT67NwlQQbjZ0fDaNgFhSKE89xjmx2a4mq0fv+jIN2ewmFhChgNasTFRrn+pgIi9eBwOF21ImT5+/tDX5aHlORXWI+Retmz9wAu1V0TopZVdnpkBKqMBQgPf44OyK2BOJiclIhNmatAFJDV3HwPxuqjaG+/z2poZXoqcv5NV7ZVf+UGtDoz+vsHGNuhoc9i25Y1SEmZj1BFCPr6+tHW9hMOfngSLa0/sOpLW74IqrxMfoAImC2bMrBubRrIb8/1yGJDTm4Zfr3/iGFo0esLXDkeEODd9f568jfy8vVobrnHOEOCZdCrEBERztgjjclk/gjnPr/M2CPNwVRZxA/QnPgYVFUWcrbKw0dO4fiJMwwjiYnxqNCrIJNN9tq7easZ+epyBjvEqUpDARISuJtJV1c3VLsMrEyRjKDWEPEka9s6vLM2jTPXv/yqAbrSGt6AuAKwZHEySjRZDEaHKyZ1t3tPDaOuZ8dF8QNEWjCpH67VcLUR6oIKXoB6nvaisKiStU1rS3birSXJ1Cbx8KEV23fqQC55zzV1ahgdUHCwHOZqDWJjZ4wKoI6OLmTt0DJqjo8dtwPd3U+Qm/8Bo93LJgfSAZFL0mwqxqyZL40KIK6JhI8dtwM9PU+hLjSisbGF4RO1hvgYEpJyEw4QV7qM25QTvSmMdsqRpCdTde2nFxj575O2/X8A+rrhFgo1VYx75L9erBs3pPu+yxFaSOvOzillnQFHOvqQqbtmX4k4gAioM2cvosp0jHWKH8lwmrFqGbJ3vCseIDKgFpeYRvRhN7z4oqOU2FetAWHJ5/eQpzMWiw15qnL8/Mtv1HGHS+DFF55HuV6FSOU0l4iogIgD5KtVq9uPpqa7gkERZspKc70+NUQHRFC4H0kOHDoJm62DCow8CWxYvwLpK5aCPJh4rjEByO0QAdZ2tx3nL9S7aovrGWthynzGN5Zbh+B3OWr4RBaQAIlMANW8xBA1RCILSAyJTADVvMQQNUQiC0gMiUwA1fzEY4gKeZwJ+I0zf6nuSoCoIRJZQGJIZAKo5iWGqCESWUBiSGQCqOYnHEP/ADZNm1jj/+tzAAAAAElFTkSuQmCC"/></switch></g></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-60"><g><path d="M 211 601 L 261 651 L 211 701 L 161 651 Z" fill="#f2cc8f" stroke="#e07a5f" stroke-width="2" stroke-miterlimit="10" pointer-events="all"/></g><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 98px; height: 1px; padding-top: 651px; margin-left: 162px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Failures?</div></div></div></foreignObject><image x="162" y="644.5" width="98" height="17" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAYgAAABECAYAAACbHqJdAAAAAXNSR0IArs4c6QAAEYRJREFUeF7tnX90HNV1x793dmSJkGJoSAyEH/lVTpJSmoONtSvt6ojfhNgxAXYlEwxOSUKaUtOkpTmltE0bk4SQk5xwCBRSBwwES7sYDHVLiF2ieH9o5dQpJYSmSSAtuBhMXWMIyJJ255a32hWj3ZndmZFmdq298+fO+/l5b+c789699xHkEgJCQAgIASFgQYCEihAQAkJACAgBKwIiEDIvhIAQEAJCwJKACIRMDCEgBISAEBCBkDkgBISAEBACzgnIF4RzVpJSCAgBIdBWBEQg2mq4pbNCQAgIAecERCCcs5KUQkAICIG2IiAC0VbDLZ0VAkJACDgnIALhnFVgKSOxxF1gXOFHhUz4Qj6d/JofZTspMxxL/DkxbpxJS9g4mk6urc4bi110bIH1NID3Vu4x8NF8JvmPTuqRNE0hQMujA7+jM1/BhPMAnAzgt8otKQJ4AUAOoFSnbjwyMpL6TVNaKZU6JiAC4RhVcAlFIAARiODm23zU1B2Lf5CYNhAQdljeOAPf4amOvxob+94rDvNIsoAJiEAEDNxJdSIQIhBO5kmLpKFINPFZADcBOMxDm55kjRL5HcP/4SGvZPGZgAiEz4C9FC8CIQLhZd40IQ9FYvE/A9NXAISq6i+C8GsAWTBNAPx2EPrAeFttO+kZaHTJ6I6hf2tCH6TKOgREIFpwetQIBOOxzg5etRDWbGUPogUnnMcmhaOD3QTjEQBHmYooArRBp6kvptMP7DEXHY/HQ88+jzM1ws0AvX92tTwy2YULd21PHfDYHMnmAwERCB+gzrXIhSwQTtnIHoRTUs1JF4nED4OGTSBaNUsciP9iNJ36OgC2a9np/fFj9AI2AdRvzsuMq/PZ5N83p0dSqxUBEYgWnBciELLE1ILTclaTenriEdbo+wCOqNxg4M6p8SOv2rXrjqlG7Q/3D74LBeNRmrZ0Kl+cm+zCBfIV0YhecPdFIIJj7bgmEQgRCMeTpUkJa5YKgb1k0Fm53PCTTpsUiSb+CMAtpvR7WKOzZMPaKUH/04lA+M/YdQ0iECIQridNgBn6+/v1icI77gMQN739P4IiLh4dTY07bUpPz8DprPEPABxZzjPJwEfymeR2p2VIOn8JiED4y9dT6a0gEN3dq5doemEFiD4CYCmA4wDopg69CPDTDGwuaqHUj3cMPeeks35sUteU6XJT303+6rQV573u7o8fQR1T1xHwCQDvADAO5p8z4V5jsrBx584H99nxUZu3z+0JLSMy1oJxDoCTTKxfJOAJEO5eFOItXg0Vlp4dX9w5QSvBuJyBUwEsKben5MBGwFPMPFycKmyp11aVp79/bdfE1OtXQ8MpYF4G0NHE2JDLJv/SyRyopJF9Jje0mpNWBKI53OvW2kyBUA5PGtM3AJxtYbpo1+4iM7YUQ9rnGgnFQhQI0rTdMPh+gN9jDYi3duqHx0dG7jpYdZ96+uJnsIFv11r1WJb0Koi/hAJucfqm3t8ff+tEkb4ExlUO/RQKxLitWOi43m8Htp6e+Ieg0TYGji73dr8BPmcsk9rVgn/LtmySCEQLDnuTBGKuDk+K5PMaa6uy2aF/tcO60ASCgGsYpYfvB236XCSiy3Lp4SHzfWUFRCFtPYOvcSHE5SJ4zNCLl4yNPLC73vSNROK/jRANl8Xe1Uxn4BfQ6EI/9wNq9yD4iUldP2vXyKb/ddVYSewbAREI39B6L7gZAtETS1zMjHss3jJfhXpYgB4HoJYjQmDjNFDJjr3Wc7bB8s5CEwgQ9pmcv9T6exagZ8pfE70AnjamQmePjW16sTIjli79dMeiww7cAvCna2YJYR8xfsIg5WQWYvAyAn63anlPZXuKjMIFudwD/2010+rUUVr6Amk/KY0ncSeAXjDeXStU/vkm9PRcdBJr+j/PElaiW0bTw+vqmch6/1dJTi8ERCC8UPM5T9ACcXrf4Am6YTwK4AOmru0nwrqJ148ctjJbLL8Bf4LBXzUFZFPZJwFeNZpJKRPImmvBCcRMD3mM9dBgfmTovyo/qeWd8SJOHEunnjKBsPE+5p8bjHUnHofHUqmUEuKZa/nyj71NW9TxdzT9pWL2WH60U+dLrPYlwtHBfoKhHsAVES8y8JUunW+0Sr+8L/5u3aDbGaU9kMpl+fUz1+lv82XzvMbFc7PZzT+ba/mSf/4IiEDMH8t5KylogbAwN3xFY21FNjukoqnWvXr64meyQQ+a7eGJ8WW7DcuFKBCl5RhdO88sDnbQuqPxpRpoW5X38XYUeWB0NPV/dWBTOBa/gphuNT/0ibA2l07eW50vHE18iwD1Nj59OXg7VxvZiw5iy2wHNtv9k0ZTw/J+d/9Fx2uF0P0AdZsSjBNhTS6d3OypUMnkGwERCN/Qei/Yh1hMT+tUiFWHPlAtLFmkFF5LAbTCzcOkktbK5JEZ9+azycutlgoWokAQ8Le5TPKLDkacIrGBm8F8tSlt3aWiqjIpHE2oL4nr3/y91rns1HPXHP7W1yceNH8NOA2VHonGzwfoIQCLVB0MPKej2J/JbH7GQf/qJgn3DXwABm+Z7RxXWuZq6H0917olvzcCIhDeuPmaK0iBKIVMCNEfMBAFcBoBiw3mS8ayqYzTTs7FTBTzcB6Em/qt+uQmv4WD2GsG8/lOeKllnJBB/wKU1vvVVbT7ArBjb1FGje9AyXJpih4C4cxKOcx0WT47/L1GY1p+w98GkNqbeJxBT3WQ8a10OvVSo7z17pc9r+8vm0tXkhbBfP3xx+Gm6mW1udQleeePgAjE/LGct5KCFIj5aPScHrCHvkD82tALfY0sihTncG/8o0T0wMw+AuFXKHD/6Gjqf5yOg9UXm8WSHoV7E3cT4bIZgQjAKsmuD5FYfDmY1EFPyj+kcqkN/WtHM0m1ZGYbt8kpF0nnDwERCH+4zqlUEQh3ntRuBGrevyBcOOX19CZuYMJ1lTYQsO03b+n82BM/uOc1NxMmHEtcR4wb3sxTu0/QExsYZGa1N2He1FaH9DxE4I2d+uEjFn4ZbprhKK2ltRLwKkBXjmaG1ReFiIMjks1JJALRHO51aw16k9oLgqX9q4/uKBQjBKwGoPYvKkdLqr+8bXjyBbgHkerU9146MjJSqMfRJjzFLwHth+7584cALDcJxFgIHR/OZO7bX/mtbPm0tc4JbwUGfkaMYQ7RlhOWGL+Y72UeZWrb+ZYD9zDzgKmP+4l4TS6d+if3/ZYcQRMQgQiauIP6WkUg1Ab25OQrSwxNP1UDncDEy8GlB9O76nrltpNA2CyRVQ+z1b6Ag6ngNImlEUJv7+Aygwy14azCpDS6lL/LVjLoromJxT90EpG1UYEWEV8nmfnyfDalnPfkOgQIiEC04CA1UyCUT0TIMK4hQL31He8JjwhEDbZmCIRqRGk8i8Y3iXChC49ttT/wXZ0KN1hZvjmdE9VLagC7DujntC5J5w8BEQh/uM6p1GYIhAo2F9Kn1jPhDy28duv1R715qqWNE2cSiUC0jEBUGmIS/jVVm8X1xvZ50nhNbkfqMbcT2tJ8mukzo9nh292WJembR0AEonnsbWsOWiBsnJdq2zcdVkJ5CucB+pHGlM1mh/aEY4lriXGjCIT9ZLI0PSV8IZ9Ofi3gKUjh/sGTaIrPg8ZXgKH2M2pDprzZqL3QtPPdnhcdjV56VBFTj5gc4orMtDKfHVZHlMp1iBAQgWjBgQpSINRGYsdhL99eDlNtpvEyCENs0MMd2tTjxxwT2mu3ienGimjBbVI73IOwcl4jxj/ksslPNXMKqvHv6tp3cpFCa4gxACrtL82+HHhhV2exCOUtkVqbOdAe6xaB8AjOz2xBCoTV0ZFvmOx/H0X+eIPQDzMImi0Qkd6Bq0D85lnGLkxPVSd6ehPfYcIn5/MLyGp+uKnHz/lVp2yKxBLngnG3eRlKhRLhqVCfOeBgo/aJQDQidGjcF4FowXEKVCCqbPMBPIsinzU6mvqVQzQ1TlmBm7lGEysJeNjU3h9pfHBlNvuw2h+pe1m92c9H+60qrREyD8d0qqhK5XAd6jS33SrKLrOxravjpc0VU1sV0oLYWAGmiDrsiYFcl753TSNT3Eqbw7H4WmK609QHeftvNJEW6H0RiBYc2KAEwsY23+5wG0tSpZPnOorqiMhT5vMN3M1pY+FagXDu3awepgar8BfHzmf7Lb8gegZOYa1U14xHMQPr85nkXzt1GItE4u9DqBSuY8YogIGb85mkOleidM3VY9sioKAIRAs+J4JokghEEJRd1hGcQNQG6nPp3WsRPK70qAvUUa67Nx7ViFR48cPLqOuGHDcNh2/tt/yCUHGvNGwC0SrT/b0gXjmaTu1sNE2UoE8WltzMYGVpVrnGGdoF+czQSOWHaPTi9xQQGiHghPJvrmI+1QgM4FhwG/VB7h9aBEQgWnC8ghII1fWadXFgP0P7cD4zNFYPjTpHefcL+DyYvmxhFmu7xOPHJnUkEn8ndBoB432VNiuhm+ji+K7tqQM2/aBwbzxBVFpKmW3FMw8CZ8euuzd+jkalaKkzdTo8vc26vcwPwcBq8xGk01+GSzYCfKlbIbIO+Q1H3uIt+FeSJs2RgAjEHAH6kT1QgbCM2UPPkGZ8KrcjpcJAzIqVo4ThuRcoDMbX64RxsA0v7odAqHX5cDSxwcISa0tB09ZVn5OtwlDoHR1/Y+vz4aNA2HwFqGm0H8zXwsB91edN1/FRsf366O0djBlkbDWf0wHgJWb63NTBxUkrT+np88ixEaBl5i8Ug3nVWDalzrBwfFmee+HQ4stxJZLQdwIiEL4jdl9BkALRIGaPOiYzB1A51LNxCkC/V3WCHKCiknJpXf2Icm9tlyR8EgjYHMSjmlMAeBeg/bvNEZ5FYtzKVIonNR2G20eBUMWrt/TOg5SqOr2tMlHGQXgcTD+d/sH4fYCWWnyljTPxn+bTqdvsvpAiscQ3wPgTi/uvAvxTQHty+h6/XX1MAlhSm5bumBxffLXb0BsiEO7/962YQwSiBUclSIFQ3XcZs8dMrACmb3IH3YqC8ajpIJiXyaBzc7nhH1fj9UsgStY90cRn39iHuKmB45e5SUUC1sMo3MmarjZ+3xuEQFREYtFBuuONs6UTHqago1DZJee8gnYrwMp72u2ljii9u0vndVZHlDYqTASiEaFD474IRAuOU9ACoRAsjw6crIE31lk2mvVgBbDdIP68Om/ZKqwC23gJ+ygQqn3U0xc/gw18G6D3Nxjal5j5j/PZVDIWu+iYAuvqeNXABEK1rbSPs4eUQChRe6eTqchAnomvrDrn2jZruY7PvPEFsh7AkU7qAKDOp7j2+GM56TXCqwiEQ9ItnkwEogUHqBkCUXlgqf0FzaBPMnEMwEkzSxulMBv8nwxsLmqhVPW6fvW51upBZkxOrdi588F9ZsQ+C0SpqrJ3+PlUsvah02aWTsp9IKLbFoV4S+XNuMak1uclpuopp9qrd+3vDkG7ksnoBUgFSaxsYqvloGcZtNUAfXdnZviXTk1izfWUQm93HjgDhNUWdYwDvJtYyxZhbCgcPGrM7ZJSdZ9EIFrwweKhSSIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCAgAuEBmmQRAkJACLQDARGIdhhl6aMQEAJCwAMBEQgP0CSLEBACQqAdCIhAtMMoSx+FgBAQAh4IiEB4gCZZhIAQEALtQEAEoh1GWfooBISAEPBAQATCAzTJIgSEgBBoBwIiEO0wytJHISAEhIAHAiIQHqBJFiEgBIRAOxAQgWiHUZY+CgEhIAQ8EBCB8ABNsggBISAE2oGACEQ7jLL0UQgIASHggYAIhAdokkUICAEh0A4ERCDaYZSlj0JACAgBDwREIDxAkyxCQAgIgXYgIALRDqMsfRQCQkAIeCDw/9PUXuoYdJv9AAAAAElFTkSuQmCC"/></switch></g></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-61"><g><path d="M 261 651 L 356 651 L 356 87.37" fill="none" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 356 82.12 L 359.5 89.12 L 356 87.37 L 352.5 89.12 Z" fill="#e07a5f" stroke="#e07a5f" stroke-miterlimit="10" pointer-events="all"/></g></g><g data-cell-id="8N6JJebqrzA787TgpwUj-62"><g><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 662px; margin-left: 308px;"><div data-drawio-colors="color: #393C56; " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: rgb(57, 60, 86); line-height: 1.2; pointer-events: all; font-weight: bold; white-space: nowrap;">yes</div></div></div></foreignObject><image x="299" y="656" width="18" height="15.75" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80VatEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3Xzt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQeAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41CQd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pSqfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHCKiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiwzyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADjIQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94nxgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpLdOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO11PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpFmimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXlyY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9hBKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7XANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGcwEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOjBLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUDPAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8krO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RBt1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwmx9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmnc0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWOM4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsnAX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN/n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WDElOGjAAAAAElFTkSuQmCC"/></switch></g></g></g></g></g></g></svg> \ No newline at end of file
diff --git a/Documentation/x86/sva.rst b/Documentation/arch/x86/sva.rst
index 2e9b8b0f9a0f..6a759984d471 100644
--- a/Documentation/x86/sva.rst
+++ b/Documentation/arch/x86/sva.rst
@@ -25,7 +25,7 @@ to cache translations for virtual addresses. The IOMMU driver uses the
mmu_notifier() support to keep the device TLB cache and the CPU cache in
sync. When an ATS lookup fails for a virtual address, the device should
use the PRI in order to request the virtual address to be paged into the
-CPU page tables. The device must use ATS again in order the fetch the
+CPU page tables. The device must use ATS again in order to fetch the
translation before use.
Shared Hardware Workqueues
@@ -107,7 +107,7 @@ process share the same page tables, thus the same MSR value.
PASID Life Cycle Management
===========================
-PASID is initialized as INVALID_IOASID (-1) when a process is created.
+PASID is initialized as IOMMU_PASID_INVALID (-1) when a process is created.
Only processes that access SVA-capable devices need to have a PASID
allocated. This allocation happens when a process opens/binds an SVA-capable
@@ -216,7 +216,7 @@ submitting work and processing completions.
Single Root I/O Virtualization (SR-IOV) focuses on providing independent
hardware interfaces for virtualizing hardware. Hence, it's required to be
-almost fully functional interface to software supporting the traditional
+an almost fully functional interface to software supporting the traditional
BARs, space for interrupts via MSI-X, its own register layout.
Virtual Functions (VFs) are assisted by the Physical Function (PF)
driver.
diff --git a/Documentation/arch/x86/tdx.rst b/Documentation/arch/x86/tdx.rst
new file mode 100644
index 000000000000..61670e7df2f7
--- /dev/null
+++ b/Documentation/arch/x86/tdx.rst
@@ -0,0 +1,446 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Intel Trust Domain Extensions (TDX)
+=====================================
+
+Intel's Trust Domain Extensions (TDX) protect confidential guest VMs from
+the host and physical attacks by isolating the guest register state and by
+encrypting the guest memory. In TDX, a special module running in a special
+mode sits between the host and the guest and manages the guest/host
+separation.
+
+TDX Host Kernel Support
+=======================
+
+TDX introduces a new CPU mode called Secure Arbitration Mode (SEAM) and
+a new isolated range pointed by the SEAM Ranger Register (SEAMRR). A
+CPU-attested software module called 'the TDX module' runs inside the new
+isolated range to provide the functionalities to manage and run protected
+VMs.
+
+TDX also leverages Intel Multi-Key Total Memory Encryption (MKTME) to
+provide crypto-protection to the VMs. TDX reserves part of MKTME KeyIDs
+as TDX private KeyIDs, which are only accessible within the SEAM mode.
+BIOS is responsible for partitioning legacy MKTME KeyIDs and TDX KeyIDs.
+
+Before the TDX module can be used to create and run protected VMs, it
+must be loaded into the isolated range and properly initialized. The TDX
+architecture doesn't require the BIOS to load the TDX module, but the
+kernel assumes it is loaded by the BIOS.
+
+TDX boot-time detection
+-----------------------
+
+The kernel detects TDX by detecting TDX private KeyIDs during kernel
+boot. Below dmesg shows when TDX is enabled by BIOS::
+
+ [..] virt/tdx: BIOS enabled: private KeyID range: [16, 64)
+
+TDX module initialization
+---------------------------------------
+
+The kernel talks to the TDX module via the new SEAMCALL instruction. The
+TDX module implements SEAMCALL leaf functions to allow the kernel to
+initialize it.
+
+If the TDX module isn't loaded, the SEAMCALL instruction fails with a
+special error. In this case the kernel fails the module initialization
+and reports the module isn't loaded::
+
+ [..] virt/tdx: module not loaded
+
+Initializing the TDX module consumes roughly ~1/256th system RAM size to
+use it as 'metadata' for the TDX memory. It also takes additional CPU
+time to initialize those metadata along with the TDX module itself. Both
+are not trivial. The kernel initializes the TDX module at runtime on
+demand.
+
+Besides initializing the TDX module, a per-cpu initialization SEAMCALL
+must be done on one cpu before any other SEAMCALLs can be made on that
+cpu.
+
+The kernel provides two functions, tdx_enable() and tdx_cpu_enable() to
+allow the user of TDX to enable the TDX module and enable TDX on local
+cpu respectively.
+
+Making SEAMCALL requires VMXON has been done on that CPU. Currently only
+KVM implements VMXON. For now both tdx_enable() and tdx_cpu_enable()
+don't do VMXON internally (not trivial), but depends on the caller to
+guarantee that.
+
+To enable TDX, the caller of TDX should: 1) temporarily disable CPU
+hotplug; 2) do VMXON and tdx_enable_cpu() on all online cpus; 3) call
+tdx_enable(). For example::
+
+ cpus_read_lock();
+ on_each_cpu(vmxon_and_tdx_cpu_enable());
+ ret = tdx_enable();
+ cpus_read_unlock();
+ if (ret)
+ goto no_tdx;
+ // TDX is ready to use
+
+And the caller of TDX must guarantee the tdx_cpu_enable() has been
+successfully done on any cpu before it wants to run any other SEAMCALL.
+A typical usage is do both VMXON and tdx_cpu_enable() in CPU hotplug
+online callback, and refuse to online if tdx_cpu_enable() fails.
+
+User can consult dmesg to see whether the TDX module has been initialized.
+
+If the TDX module is initialized successfully, dmesg shows something
+like below::
+
+ [..] virt/tdx: 262668 KBs allocated for PAMT
+ [..] virt/tdx: module initialized
+
+If the TDX module failed to initialize, dmesg also shows it failed to
+initialize::
+
+ [..] virt/tdx: module initialization failed ...
+
+TDX Interaction to Other Kernel Components
+------------------------------------------
+
+TDX Memory Policy
+~~~~~~~~~~~~~~~~~
+
+TDX reports a list of "Convertible Memory Region" (CMR) to tell the
+kernel which memory is TDX compatible. The kernel needs to build a list
+of memory regions (out of CMRs) as "TDX-usable" memory and pass those
+regions to the TDX module. Once this is done, those "TDX-usable" memory
+regions are fixed during module's lifetime.
+
+To keep things simple, currently the kernel simply guarantees all pages
+in the page allocator are TDX memory. Specifically, the kernel uses all
+system memory in the core-mm "at the time of TDX module initialization"
+as TDX memory, and in the meantime, refuses to online any non-TDX-memory
+in the memory hotplug.
+
+Physical Memory Hotplug
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Note TDX assumes convertible memory is always physically present during
+machine's runtime. A non-buggy BIOS should never support hot-removal of
+any convertible memory. This implementation doesn't handle ACPI memory
+removal but depends on the BIOS to behave correctly.
+
+CPU Hotplug
+~~~~~~~~~~~
+
+TDX module requires the per-cpu initialization SEAMCALL must be done on
+one cpu before any other SEAMCALLs can be made on that cpu. The kernel
+provides tdx_cpu_enable() to let the user of TDX to do it when the user
+wants to use a new cpu for TDX task.
+
+TDX doesn't support physical (ACPI) CPU hotplug. During machine boot,
+TDX verifies all boot-time present logical CPUs are TDX compatible before
+enabling TDX. A non-buggy BIOS should never support hot-add/removal of
+physical CPU. Currently the kernel doesn't handle physical CPU hotplug,
+but depends on the BIOS to behave correctly.
+
+Note TDX works with CPU logical online/offline, thus the kernel still
+allows to offline logical CPU and online it again.
+
+Erratum
+~~~~~~~
+
+The first few generations of TDX hardware have an erratum. A partial
+write to a TDX private memory cacheline will silently "poison" the
+line. Subsequent reads will consume the poison and generate a machine
+check.
+
+A partial write is a memory write where a write transaction of less than
+cacheline lands at the memory controller. The CPU does these via
+non-temporal write instructions (like MOVNTI), or through UC/WC memory
+mappings. Devices can also do partial writes via DMA.
+
+Theoretically, a kernel bug could do partial write to TDX private memory
+and trigger unexpected machine check. What's more, the machine check
+code will present these as "Hardware error" when they were, in fact, a
+software-triggered issue. But in the end, this issue is hard to trigger.
+
+If the platform has such erratum, the kernel prints additional message in
+machine check handler to tell user the machine check may be caused by
+kernel bug on TDX private memory.
+
+Kexec
+~~~~~~~
+
+Currently kexec doesn't work on the TDX platforms with the aforementioned
+erratum. It fails when loading the kexec kernel image. Otherwise it
+works normally.
+
+Interaction vs S3 and deeper states
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TDX cannot survive from S3 and deeper states. The hardware resets and
+disables TDX completely when platform goes to S3 and deeper. Both TDX
+guests and the TDX module get destroyed permanently.
+
+The kernel uses S3 for suspend-to-ram, and use S4 and deeper states for
+hibernation. Currently, for simplicity, the kernel chooses to make TDX
+mutually exclusive with S3 and hibernation.
+
+The kernel disables TDX during early boot when hibernation support is
+available::
+
+ [..] virt/tdx: initialization failed: Hibernation support is enabled
+
+Add 'nohibernate' kernel command line to disable hibernation in order to
+use TDX.
+
+ACPI S3 is disabled during kernel early boot if TDX is enabled. The user
+needs to turn off TDX in the BIOS in order to use S3.
+
+TDX Guest Support
+=================
+Since the host cannot directly access guest registers or memory, much
+normal functionality of a hypervisor must be moved into the guest. This is
+implemented using a Virtualization Exception (#VE) that is handled by the
+guest kernel. A #VE is handled entirely inside the guest kernel, but some
+require the hypervisor to be consulted.
+
+TDX includes new hypercall-like mechanisms for communicating from the
+guest to the hypervisor or the TDX module.
+
+New TDX Exceptions
+------------------
+
+TDX guests behave differently from bare-metal and traditional VMX guests.
+In TDX guests, otherwise normal instructions or memory accesses can cause
+#VE or #GP exceptions.
+
+Instructions marked with an '*' conditionally cause exceptions. The
+details for these instructions are discussed below.
+
+Instruction-based #VE
+~~~~~~~~~~~~~~~~~~~~~
+
+- Port I/O (INS, OUTS, IN, OUT)
+- HLT
+- MONITOR, MWAIT
+- WBINVD, INVD
+- VMCALL
+- RDMSR*,WRMSR*
+- CPUID*
+
+Instruction-based #GP
+~~~~~~~~~~~~~~~~~~~~~
+
+- All VMX instructions: INVEPT, INVVPID, VMCLEAR, VMFUNC, VMLAUNCH,
+ VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON
+- ENCLS, ENCLU
+- GETSEC
+- RSM
+- ENQCMD
+- RDMSR*,WRMSR*
+
+RDMSR/WRMSR Behavior
+~~~~~~~~~~~~~~~~~~~~
+
+MSR access behavior falls into three categories:
+
+- #GP generated
+- #VE generated
+- "Just works"
+
+In general, the #GP MSRs should not be used in guests. Their use likely
+indicates a bug in the guest. The guest may try to handle the #GP with a
+hypercall but it is unlikely to succeed.
+
+The #VE MSRs are typically able to be handled by the hypervisor. Guests
+can make a hypercall to the hypervisor to handle the #VE.
+
+The "just works" MSRs do not need any special guest handling. They might
+be implemented by directly passing through the MSR to the hardware or by
+trapping and handling in the TDX module. Other than possibly being slow,
+these MSRs appear to function just as they would on bare metal.
+
+CPUID Behavior
+~~~~~~~~~~~~~~
+
+For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID
+return values (in guest EAX/EBX/ECX/EDX) are configurable by the
+hypervisor. For such cases, the Intel TDX module architecture defines two
+virtualization types:
+
+- Bit fields for which the hypervisor controls the value seen by the guest
+ TD.
+
+- Bit fields for which the hypervisor configures the value such that the
+ guest TD either sees their native value or a value of 0. For these bit
+ fields, the hypervisor can mask off the native values, but it can not
+ turn *on* values.
+
+A #VE is generated for CPUID leaves and sub-leaves that the TDX module does
+not know how to handle. The guest kernel may ask the hypervisor for the
+value with a hypercall.
+
+#VE on Memory Accesses
+----------------------
+
+There are essentially two classes of TDX memory: private and shared.
+Private memory receives full TDX protections. Its content is protected
+against access from the hypervisor. Shared memory is expected to be
+shared between guest and hypervisor and does not receive full TDX
+protections.
+
+A TD guest is in control of whether its memory accesses are treated as
+private or shared. It selects the behavior with a bit in its page table
+entries. This helps ensure that a guest does not place sensitive
+information in shared memory, exposing it to the untrusted hypervisor.
+
+#VE on Shared Memory
+~~~~~~~~~~~~~~~~~~~~
+
+Access to shared mappings can cause a #VE. The hypervisor ultimately
+controls whether a shared memory access causes a #VE, so the guest must be
+careful to only reference shared pages it can safely handle a #VE. For
+instance, the guest should be careful not to access shared memory in the
+#VE handler before it reads the #VE info structure (TDG.VP.VEINFO.GET).
+
+Shared mapping content is entirely controlled by the hypervisor. The guest
+should only use shared mappings for communicating with the hypervisor.
+Shared mappings must never be used for sensitive memory content like kernel
+stacks. A good rule of thumb is that hypervisor-shared memory should be
+treated the same as memory mapped to userspace. Both the hypervisor and
+userspace are completely untrusted.
+
+MMIO for virtual devices is implemented as shared memory. The guest must
+be careful not to access device MMIO regions unless it is also prepared to
+handle a #VE.
+
+#VE on Private Pages
+~~~~~~~~~~~~~~~~~~~~
+
+An access to private mappings can also cause a #VE. Since all kernel
+memory is also private memory, the kernel might theoretically need to
+handle a #VE on arbitrary kernel memory accesses. This is not feasible, so
+TDX guests ensure that all guest memory has been "accepted" before memory
+is used by the kernel.
+
+A modest amount of memory (typically 512M) is pre-accepted by the firmware
+before the kernel runs to ensure that the kernel can start up without
+being subjected to a #VE.
+
+The hypervisor is permitted to unilaterally move accepted pages to a
+"blocked" state. However, if it does this, page access will not generate a
+#VE. It will, instead, cause a "TD Exit" where the hypervisor is required
+to handle the exception.
+
+Linux #VE handler
+-----------------
+
+Just like page faults or #GP's, #VE exceptions can be either handled or be
+fatal. Typically, an unhandled userspace #VE results in a SIGSEGV.
+An unhandled kernel #VE results in an oops.
+
+Handling nested exceptions on x86 is typically nasty business. A #VE
+could be interrupted by an NMI which triggers another #VE and hilarity
+ensues. The TDX #VE architecture anticipated this scenario and includes a
+feature to make it slightly less nasty.
+
+During #VE handling, the TDX module ensures that all interrupts (including
+NMIs) are blocked. The block remains in place until the guest makes a
+TDG.VP.VEINFO.GET TDCALL. This allows the guest to control when interrupts
+or a new #VE can be delivered.
+
+However, the guest kernel must still be careful to avoid potential
+#VE-triggering actions (discussed above) while this block is in place.
+While the block is in place, any #VE is elevated to a double fault (#DF)
+which is not recoverable.
+
+MMIO handling
+-------------
+
+In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
+mapping which will cause a VMEXIT on access, and then the hypervisor
+emulates the access. That is not possible in TDX guests because VMEXIT
+will expose the register state to the host. TDX guests don't trust the host
+and can't have their state exposed to the host.
+
+In TDX, MMIO regions typically trigger a #VE exception in the guest. The
+guest #VE handler then emulates the MMIO instruction inside the guest and
+converts it into a controlled TDCALL to the host, rather than exposing
+guest state to the host.
+
+MMIO addresses on x86 are just special physical addresses. They can
+theoretically be accessed with any instruction that accesses memory.
+However, the kernel instruction decoding method is limited. It is only
+designed to decode instructions like those generated by io.h macros.
+
+MMIO access via other means (like structure overlays) may result in an
+oops.
+
+Shared Memory Conversions
+-------------------------
+
+All TDX guest memory starts out as private at boot. This memory can not
+be accessed by the hypervisor. However, some kernel users like device
+drivers might have a need to share data with the hypervisor. To do this,
+memory must be converted between shared and private. This can be
+accomplished using some existing memory encryption helpers:
+
+ * set_memory_decrypted() converts a range of pages to shared.
+ * set_memory_encrypted() converts memory back to private.
+
+Device drivers are the primary user of shared memory, but there's no need
+to touch every driver. DMA buffers and ioremap() do the conversions
+automatically.
+
+TDX uses SWIOTLB for most DMA allocations. The SWIOTLB buffer is
+converted to shared on boot.
+
+For coherent DMA allocation, the DMA buffer gets converted on the
+allocation. Check force_dma_unencrypted() for details.
+
+Attestation
+===========
+
+Attestation is used to verify the TDX guest trustworthiness to other
+entities before provisioning secrets to the guest. For example, a key
+server may want to use attestation to verify that the guest is the
+desired one before releasing the encryption keys to mount the encrypted
+rootfs or a secondary drive.
+
+The TDX module records the state of the TDX guest in various stages of
+the guest boot process using the build time measurement register (MRTD)
+and runtime measurement registers (RTMR). Measurements related to the
+guest initial configuration and firmware image are recorded in the MRTD
+register. Measurements related to initial state, kernel image, firmware
+image, command line options, initrd, ACPI tables, etc are recorded in
+RTMR registers. For more details, as an example, please refer to TDX
+Virtual Firmware design specification, section titled "TD Measurement".
+At TDX guest runtime, the attestation process is used to attest to these
+measurements.
+
+The attestation process consists of two steps: TDREPORT generation and
+Quote generation.
+
+TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT)
+from the TDX module. TDREPORT is a fixed-size data structure generated by
+the TDX module which contains guest-specific information (such as build
+and boot measurements), platform security version, and the MAC to protect
+the integrity of the TDREPORT. A user-provided 64-Byte REPORTDATA is used
+as input and included in the TDREPORT. Typically it can be some nonce
+provided by attestation service so the TDREPORT can be verified uniquely.
+More details about the TDREPORT can be found in Intel TDX Module
+specification, section titled "TDG.MR.REPORT Leaf".
+
+After getting the TDREPORT, the second step of the attestation process
+is to send it to the Quoting Enclave (QE) to generate the Quote. TDREPORT
+by design can only be verified on the local platform as the MAC key is
+bound to the platform. To support remote verification of the TDREPORT,
+TDX leverages Intel SGX Quoting Enclave to verify the TDREPORT locally
+and convert it to a remotely verifiable Quote. Method of sending TDREPORT
+to QE is implementation specific. Attestation software can choose
+whatever communication channel available (i.e. vsock or TCP/IP) to
+send the TDREPORT to QE and receive the Quote.
+
+References
+==========
+
+TDX reference material is collected here:
+
+https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html
diff --git a/Documentation/x86/tlb.rst b/Documentation/arch/x86/tlb.rst
index 82ec58ae63a8..82ec58ae63a8 100644
--- a/Documentation/x86/tlb.rst
+++ b/Documentation/arch/x86/tlb.rst
diff --git a/Documentation/arch/x86/topology.rst b/Documentation/arch/x86/topology.rst
new file mode 100644
index 000000000000..86bec8ac2c4d
--- /dev/null
+++ b/Documentation/arch/x86/topology.rst
@@ -0,0 +1,421 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+x86 Topology
+============
+
+This documents and clarifies the main aspects of x86 topology modelling and
+representation in the kernel. Update/change when doing changes to the
+respective code.
+
+The architecture-agnostic topology definitions are in
+Documentation/admin-guide/cputopology.rst. This file holds x86-specific
+differences/specialities which must not necessarily apply to the generic
+definitions. Thus, the way to read up on Linux topology on x86 is to start
+with the generic one and look at this one in parallel for the x86 specifics.
+
+Needless to say, code should use the generic functions - this file is *only*
+here to *document* the inner workings of x86 topology.
+
+Started by Thomas Gleixner <tglx@linutronix.de> and Borislav Petkov <bp@alien8.de>.
+
+The main aim of the topology facilities is to present adequate interfaces to
+code which needs to know/query/use the structure of the running system wrt
+threads, cores, packages, etc.
+
+The kernel does not care about the concept of physical sockets because a
+socket has no relevance to software. It's an electromechanical component. In
+the past a socket always contained a single package (see below), but with the
+advent of Multi Chip Modules (MCM) a socket can hold more than one package. So
+there might be still references to sockets in the code, but they are of
+historical nature and should be cleaned up.
+
+The topology of a system is described in the units of:
+
+ - packages
+ - cores
+ - threads
+
+Package
+=======
+Packages contain a number of cores plus shared resources, e.g. DRAM
+controller, shared caches etc.
+
+Modern systems may also use the term 'Die' for package.
+
+AMD nomenclature for package is 'Node'.
+
+Package-related topology information in the kernel:
+
+ - topology_num_threads_per_package()
+
+ The number of threads in a package.
+
+ - topology_num_cores_per_package()
+
+ The number of cores in a package.
+
+ - topology_max_dies_per_package()
+
+ The maximum number of dies in a package.
+
+ - cpuinfo_x86.topo.die_id:
+
+ The physical ID of the die.
+
+ - cpuinfo_x86.topo.pkg_id:
+
+ The physical ID of the package. This information is retrieved via CPUID
+ and deduced from the APIC IDs of the cores in the package.
+
+ Modern systems use this value for the socket. There may be multiple
+ packages within a socket. This value may differ from topo.die_id.
+
+ - cpuinfo_x86.topo.logical_pkg_id:
+
+ The logical ID of the package. As we do not trust BIOSes to enumerate the
+ packages in a consistent way, we introduced the concept of logical package
+ ID so we can sanely calculate the number of maximum possible packages in
+ the system and have the packages enumerated linearly.
+
+ - topology_max_packages():
+
+ The maximum possible number of packages in the system. Helpful for per
+ package facilities to preallocate per package information.
+
+ - cpuinfo_x86.topo.llc_id:
+
+ - On Intel, the first APIC ID of the list of CPUs sharing the Last Level
+ Cache
+
+ - On AMD, the Node ID or Core Complex ID containing the Last Level
+ Cache. In general, it is a number identifying an LLC uniquely on the
+ system.
+
+Cores
+=====
+A core consists of 1 or more threads. It does not matter whether the threads
+are SMT- or CMT-type threads.
+
+AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses
+"core".
+
+Threads
+=======
+A thread is a single scheduling unit. It's the equivalent to a logical Linux
+CPU.
+
+AMDs nomenclature for CMT threads is "Compute Unit Core". The kernel always
+uses "thread".
+
+Thread-related topology information in the kernel:
+
+ - topology_core_cpumask():
+
+ The cpumask contains all online threads in the package to which a thread
+ belongs.
+
+ The number of online threads is also printed in /proc/cpuinfo "siblings."
+
+ - topology_sibling_cpumask():
+
+ The cpumask contains all online threads in the core to which a thread
+ belongs.
+
+ - topology_logical_package_id():
+
+ The logical package ID to which a thread belongs.
+
+ - topology_physical_package_id():
+
+ The physical package ID to which a thread belongs.
+
+ - topology_core_id();
+
+ The ID of the core to which a thread belongs. It is also printed in /proc/cpuinfo
+ "core_id."
+
+ - topology_logical_core_id();
+
+ The logical core ID to which a thread belongs.
+
+
+
+System topology enumeration
+===========================
+
+The topology on x86 systems can be discovered using a combination of vendor
+specific CPUID leaves which enumerate the processor topology and the cache
+hierarchy.
+
+The CPUID leaves in their preferred order of parsing for each x86 vendor is as
+follows:
+
+1) AMD
+
+ 1) CPUID leaf 0x80000026 [Extended CPU Topology] (Core::X86::Cpuid::ExCpuTopology)
+
+ The extended CPUID leaf 0x80000026 is the extension of the CPUID leaf 0xB
+ and provides the topology information of Core, Complex, CCD (Die), and
+ Socket in each level.
+
+ Support for the leaf is discovered by checking if the maximum extended
+ CPUID level is >= 0x80000026 and then checking if `LogProcAtThisLevel`
+ in `EBX[15:0]` at a particular level (starting from 0) is non-zero.
+
+ The `LevelType` in `ECX[15:8]` at the level provides the topology domain
+ the level describes - Core, Complex, CCD(Die), or the Socket.
+
+ The kernel uses the `CoreMaskWidth` from `EAX[4:0]` to discover the
+ number of bits that need to be right-shifted from `ExtendedLocalApicId`
+ in `EDX[31:0]` in order to get a unique Topology ID for the topology
+ level. CPUs with the same Topology ID share the resources at that level.
+
+ CPUID leaf 0x80000026 also provides more information regarding the power
+ and efficiency rankings, and about the core type on AMD processors with
+ heterogeneous characteristics.
+
+ If CPUID leaf 0x80000026 is supported, further parsing is not required.
+
+ 2) CPUID leaf 0x0000000B [Extended Topology Enumeration] (Core::X86::Cpuid::ExtTopEnum)
+
+ The extended CPUID leaf 0x0000000B is the predecessor on the extended
+ CPUID leaf 0x80000026 and only describes the core, and the socket domains
+ of the processor topology.
+
+ The support for the leaf is discovered by checking if the maximum supported
+ CPUID level is >= 0xB and then if `EBX[31:0]` at a particular level
+ (starting from 0) is non-zero.
+
+ The `LevelType` in `ECX[15:8]` at the level provides the topology domain
+ that the level describes - Thread, or Processor (Socket).
+
+ The kernel uses the `CoreMaskWidth` from `EAX[4:0]` to discover the
+ number of bits that need to be right-shifted from the `ExtendedLocalApicId`
+ in `EDX[31:0]` to get a unique Topology ID for that topology level. CPUs
+ sharing the Topology ID share the resources at that level.
+
+ If CPUID leaf 0xB is supported, further parsing is not required.
+
+
+ 3) CPUID leaf 0x80000008 ECX [Size Identifiers] (Core::X86::Cpuid::SizeId)
+
+ If neither the CPUID leaf 0x80000026 nor 0xB is supported, the number of
+ CPUs on the package is detected using the Size Identifier leaf
+ 0x80000008 ECX.
+
+ The support for the leaf is discovered by checking if the supported
+ extended CPUID level is >= 0x80000008.
+
+ The shifts from the APIC ID for the Socket ID is calculated from the
+ `ApicIdSize` field in `ECX[15:12]` if it is non-zero.
+
+ If `ApicIdSize` is reported to be zero, the shift is calculated as the
+ order of the `number of threads` calculated from `NC` field in
+ `ECX[7:0]` which describes the `number of threads - 1` on the package.
+
+ Unless Extended APIC ID is supported, the APIC ID used to find the
+ Socket ID is from the `LocalApicId` field of CPUID leaf 0x00000001
+ `EBX[31:24]`.
+
+ The topology parsing continues to detect if Extended APIC ID is
+ supported or not.
+
+
+ 4) CPUID leaf 0x8000001E [Extended APIC ID, Core Identifiers, Node Identifiers]
+ (Core::X86::Cpuid::{ExtApicId,CoreId,NodeId})
+
+ The support for Extended APIC ID can be detected by checking for the
+ presence of `TopologyExtensions` in `ECX[22]` of CPUID leaf 0x80000001
+ [Feature Identifiers] (Core::X86::Cpuid::FeatureExtIdEcx).
+
+ If Topology Extensions is supported, the APIC ID from `ExtendedApicId`
+ from CPUID leaf 0x8000001E `EAX[31:0]` should be preferred over that from
+ `LocalApicId` field of CPUID leaf 0x00000001 `EBX[31:24]` for topology
+ enumeration.
+
+ On processors of Family 0x17 and above that do not support CPUID leaf
+ 0x80000026 or CPUID leaf 0xB, the shifts from the APIC ID for the Core
+ ID is calculated using the order of `number of threads per core`
+ calculated using the `ThreadsPerCore` field in `EBX[15:8]` which
+ describes `number of threads per core - 1`.
+
+ On Processors of Family 0x15, the Core ID from `EBX[7:0]` is used as the
+ `cu_id` (Compute Unit ID) to detect CPUs that share the compute units.
+
+
+ All AMD processors that support the `TopologyExtensions` feature store the
+ `NodeId` from the `ECX[7:0]` of CPUID leaf 0x8000001E
+ (Core::X86::Cpuid::NodeId) as the per-CPU `node_id`. On older processors,
+ the `node_id` was discovered using MSR_FAM10H_NODE_ID MSR (MSR
+ 0x0xc001_100c). The presence of the NODE_ID MSR was detected by checking
+ `ECX[19]` of CPUID leaf 0x80000001 [Feature Identifiers]
+ (Core::X86::Cpuid::FeatureExtIdEcx).
+
+
+2) Intel
+
+ On Intel platforms, the CPUID leaves that enumerate the processor
+ topology are as follows:
+
+ 1) CPUID leaf 0x1F (V2 Extended Topology Enumeration Leaf)
+
+ The CPUID leaf 0x1F is the extension of the CPUID leaf 0xB and provides
+ the topology information of Core, Module, Tile, Die, DieGrp, and Socket
+ in each level.
+
+ The support for the leaf is discovered by checking if the supported
+ CPUID level is >= 0x1F and then `EBX[31:0]` at a particular level
+ (starting from 0) is non-zero.
+
+ The `Domain Type` in `ECX[15:8]` of the sub-leaf provides the topology
+ domain that the level describes - Core, Module, Tile, Die, DieGrp, and
+ Socket.
+
+ The kernel uses the value from `EAX[4:0]` to discover the number of
+ bits that need to be right shifted from the `x2APIC ID` in `EDX[31:0]`
+ to get a unique Topology ID for the topology level. CPUs with the same
+ Topology ID share the resources at that level.
+
+ If CPUID leaf 0x1F is supported, further parsing is not required.
+
+
+ 2) CPUID leaf 0x0000000B (Extended Topology Enumeration Leaf)
+
+ The extended CPUID leaf 0x0000000B is the predecessor of the V2 Extended
+ Topology Enumeration Leaf 0x1F and only describes the core, and the
+ socket domains of the processor topology.
+
+ The support for the leaf is iscovered by checking if the supported CPUID
+ level is >= 0xB and then checking if `EBX[31:0]` at a particular level
+ (starting from 0) is non-zero.
+
+ CPUID leaf 0x0000000B shares the same layout as CPUID leaf 0x1F and
+ should be enumerated in a similar manner.
+
+ If CPUID leaf 0xB is supported, further parsing is not required.
+
+
+ 3) CPUID leaf 0x00000004 (Deterministic Cache Parameters Leaf)
+
+ On Intel processors that support neither CPUID leaf 0x1F, nor CPUID leaf
+ 0xB, the shifts for the SMT domains is calculated using the number of
+ CPUs sharing the L1 cache.
+
+ Processors that feature Hyper-Threading is detected using `EDX[28]` of
+ CPUID leaf 0x1 (Basic CPUID Information).
+
+ The order of `Maximum number of addressable IDs for logical processors
+ sharing this cache` from `EAX[25:14]` of level-0 of CPUID 0x4 provides
+ the shifts from the APIC ID required to compute the Core ID.
+
+ The APIC ID and Package information is computed using the data from
+ CPUID leaf 0x1.
+
+
+ 4) CPUID leaf 0x00000001 (Basic CPUID Information)
+
+ The mask and shifts to derive the Physical Package (socket) ID is
+ computed using the `Maximum number of addressable IDs for logical
+ processors in this physical package` from `EBX[23:16]` of CPUID leaf
+ 0x1.
+
+ The APIC ID on the legacy platforms is derived from the `Initial APIC
+ ID` field from `EBX[31:24]` of CPUID leaf 0x1.
+
+
+3) Centaur and Zhaoxin
+
+ Similar to Intel, Centaur and Zhaoxin use a combination of CPUID leaf
+ 0x00000004 (Deterministic Cache Parameters Leaf) and CPUID leaf 0x00000001
+ (Basic CPUID Information) to derive the topology information.
+
+
+
+System topology examples
+========================
+
+.. note::
+ The alternative Linux CPU enumeration depends on how the BIOS enumerates the
+ threads. Many BIOSes enumerate all threads 0 first and then all threads 1.
+ That has the "advantage" that the logical Linux CPU numbers of threads 0 stay
+ the same whether threads are enabled or not. That's merely an implementation
+ detail and has no practical impact.
+
+1) Single Package, Single Core::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+
+2) Single Package, Dual Core
+
+ a) One thread per core::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+ -> [core 1] -> [thread 0] -> Linux CPU 1
+
+ b) Two threads per core::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+ -> [thread 1] -> Linux CPU 1
+ -> [core 1] -> [thread 0] -> Linux CPU 2
+ -> [thread 1] -> Linux CPU 3
+
+ Alternative enumeration::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+ -> [thread 1] -> Linux CPU 2
+ -> [core 1] -> [thread 0] -> Linux CPU 1
+ -> [thread 1] -> Linux CPU 3
+
+ AMD nomenclature for CMT systems::
+
+ [node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
+ -> [Compute Unit Core 1] -> Linux CPU 1
+ -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
+ -> [Compute Unit Core 1] -> Linux CPU 3
+
+4) Dual Package, Dual Core
+
+ a) One thread per core::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+ -> [core 1] -> [thread 0] -> Linux CPU 1
+
+ [package 1] -> [core 0] -> [thread 0] -> Linux CPU 2
+ -> [core 1] -> [thread 0] -> Linux CPU 3
+
+ b) Two threads per core::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+ -> [thread 1] -> Linux CPU 1
+ -> [core 1] -> [thread 0] -> Linux CPU 2
+ -> [thread 1] -> Linux CPU 3
+
+ [package 1] -> [core 0] -> [thread 0] -> Linux CPU 4
+ -> [thread 1] -> Linux CPU 5
+ -> [core 1] -> [thread 0] -> Linux CPU 6
+ -> [thread 1] -> Linux CPU 7
+
+ Alternative enumeration::
+
+ [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
+ -> [thread 1] -> Linux CPU 4
+ -> [core 1] -> [thread 0] -> Linux CPU 1
+ -> [thread 1] -> Linux CPU 5
+
+ [package 1] -> [core 0] -> [thread 0] -> Linux CPU 2
+ -> [thread 1] -> Linux CPU 6
+ -> [core 1] -> [thread 0] -> Linux CPU 3
+ -> [thread 1] -> Linux CPU 7
+
+ AMD nomenclature for CMT systems::
+
+ [node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
+ -> [Compute Unit Core 1] -> Linux CPU 1
+ -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
+ -> [Compute Unit Core 1] -> Linux CPU 3
+
+ [node 1] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 4
+ -> [Compute Unit Core 1] -> Linux CPU 5
+ -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 6
+ -> [Compute Unit Core 1] -> Linux CPU 7
diff --git a/Documentation/x86/tsx_async_abort.rst b/Documentation/arch/x86/tsx_async_abort.rst
index 583ddc185ba2..583ddc185ba2 100644
--- a/Documentation/x86/tsx_async_abort.rst
+++ b/Documentation/arch/x86/tsx_async_abort.rst
diff --git a/Documentation/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst
index e01c08b7c981..b17bf122270a 100644
--- a/Documentation/x86/usb-legacy-support.rst
+++ b/Documentation/arch/x86/usb-legacy-support.rst
@@ -20,11 +20,7 @@ It has several drawbacks, though:
features (wheel, extra buttons, touchpad mode) of the real PS/2 mouse may
not be available.
-2) If CONFIG_HIGHMEM64G is enabled, the PS/2 mouse emulation can cause
- system crashes, because the SMM BIOS is not expecting to be in PAE mode.
- The Intel E7505 is a typical machine where this happens.
-
-3) If AMD64 64-bit mode is enabled, again system crashes often happen,
+2) If AMD64 64-bit mode is enabled, again system crashes often happen,
because the SMM BIOS isn't expecting the CPU to be in 64-bit mode. The
BIOS manufacturers only test with Windows, and Windows doesn't do 64-bit
yet.
@@ -38,11 +34,6 @@ Problem 1)
compiled-in, too.
Problem 2)
- can currently only be solved by either disabling HIGHMEM64G
- in the kernel config or USB Legacy support in the BIOS. A BIOS update
- could help, but so far no such update exists.
-
-Problem 3)
is usually fixed by a BIOS update. Check the board
manufacturers web site. If an update is not available, disable USB
Legacy support in the BIOS. If this alone doesn't help, try also adding
diff --git a/Documentation/x86/x86_64/5level-paging.rst b/Documentation/arch/x86/x86_64/5level-paging.rst
index b792bbdc0b01..ad7ddc13f79d 100644
--- a/Documentation/x86/x86_64/5level-paging.rst
+++ b/Documentation/arch/x86/x86_64/5level-paging.rst
@@ -20,16 +20,7 @@ physical address space. This "ought to be enough for anybody" ©.
QEMU 2.9 and later support 5-level paging.
Virtual memory layout for 5-level paging is described in
-Documentation/x86/x86_64/mm.rst
-
-
-Enabling 5-level paging
-=======================
-CONFIG_X86_5LEVEL=y enables the feature.
-
-Kernel with CONFIG_X86_5LEVEL=y still able to boot on 4-level hardware.
-In this case additional page table level -- p4d -- will be folded at
-runtime.
+Documentation/arch/x86/x86_64/mm.rst
User-space and large virtual address space
==========================================
diff --git a/Documentation/x86/x86_64/cpu-hotplug-spec.rst b/Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst
index 8d1c91f0c880..8d1c91f0c880 100644
--- a/Documentation/x86/x86_64/cpu-hotplug-spec.rst
+++ b/Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst
diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst
index ff9bcfd2cc14..970ee94eb551 100644
--- a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
+++ b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst
@@ -18,7 +18,7 @@ For more information on the features of cpusets, see
Documentation/admin-guide/cgroup-v1/cpusets.rst.
There are a number of different configurations you can use for your needs. For
more information on the numa=fake command line option and its various ways of
-configuring fake nodes, see Documentation/x86/x86_64/boot-options.rst.
+configuring fake nodes, see Documentation/admin-guide/kernel-parameters.txt
For the purposes of this introduction, we'll assume a very primitive NUMA
emulation setup of "numa=fake=4*512,". This will split our system memory into
diff --git a/Documentation/arch/x86/x86_64/fred.rst b/Documentation/arch/x86/x86_64/fred.rst
new file mode 100644
index 000000000000..9f57e7b91f7e
--- /dev/null
+++ b/Documentation/arch/x86/x86_64/fred.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+Flexible Return and Event Delivery (FRED)
+=========================================
+
+Overview
+========
+
+The FRED architecture defines simple new transitions that change
+privilege level (ring transitions). The FRED architecture was
+designed with the following goals:
+
+1) Improve overall performance and response time by replacing event
+ delivery through the interrupt descriptor table (IDT event
+ delivery) and event return by the IRET instruction with lower
+ latency transitions.
+
+2) Improve software robustness by ensuring that event delivery
+ establishes the full supervisor context and that event return
+ establishes the full user context.
+
+The new transitions defined by the FRED architecture are FRED event
+delivery and, for returning from events, two FRED return instructions.
+FRED event delivery can effect a transition from ring 3 to ring 0, but
+it is used also to deliver events incident to ring 0. One FRED
+instruction (ERETU) effects a return from ring 0 to ring 3, while the
+other (ERETS) returns while remaining in ring 0. Collectively, FRED
+event delivery and the FRED return instructions are FRED transitions.
+
+In addition to these transitions, the FRED architecture defines a new
+instruction (LKGS) for managing the state of the GS segment register.
+The LKGS instruction can be used by 64-bit operating systems that do
+not use the new FRED transitions.
+
+Furthermore, the FRED architecture is easy to extend for future CPU
+architectures.
+
+Software based event dispatching
+================================
+
+FRED operates differently from IDT in terms of event handling. Instead
+of directly dispatching an event to its handler based on the event
+vector, FRED requires the software to dispatch an event to its handler
+based on both the event's type and vector. Therefore, an event dispatch
+framework must be implemented to facilitate the event-to-handler
+dispatch process. The FRED event dispatch framework takes control
+once an event is delivered, and employs a two-level dispatch.
+
+The first level dispatching is event type based, and the second level
+dispatching is event vector based.
+
+Full supervisor/user context
+============================
+
+FRED event delivery atomically save and restore full supervisor/user
+context upon event delivery and return. Thus it avoids the problem of
+transient states due to %cr2 and/or %dr6, and it is no longer needed
+to handle all the ugly corner cases caused by half baked entry states.
+
+FRED allows explicit unblock of NMI with new event return instructions
+ERETS/ERETU, avoiding the mess caused by IRET which unconditionally
+unblocks NMI, e.g., when an exception happens during NMI handling.
+
+FRED always restores the full value of %rsp, thus ESPFIX is no longer
+needed when FRED is enabled.
+
+LKGS
+====
+
+LKGS behaves like the MOV to GS instruction except that it loads the
+base address into the IA32_KERNEL_GS_BASE MSR instead of the GS
+segment’s descriptor cache. With LKGS, it ends up with avoiding
+mucking with kernel GS, i.e., an operating system can always operate
+with its own GS base address.
+
+Because FRED event delivery from ring 3 and ERETU both swap the value
+of the GS base address and that of the IA32_KERNEL_GS_BASE MSR, plus
+the introduction of LKGS instruction, the SWAPGS instruction is no
+longer needed when FRED is enabled, thus is disallowed (#UD).
+
+Stack levels
+============
+
+4 stack levels 0~3 are introduced to replace the nonreentrant IST for
+event handling, and each stack level should be configured to use a
+dedicated stack.
+
+The current stack level could be unchanged or go higher upon FRED
+event delivery. If unchanged, the CPU keeps using the current event
+stack. If higher, the CPU switches to a new event stack specified by
+the MSR of the new stack level, i.e., MSR_IA32_FRED_RSP[123].
+
+Only execution of a FRED return instruction ERET[US], could lower the
+current stack level, causing the CPU to switch back to the stack it was
+on before a previous event delivery that promoted the stack level.
diff --git a/Documentation/x86/x86_64/fsgs.rst b/Documentation/arch/x86/x86_64/fsgs.rst
index 50960e09e1f6..6bda4d16d3f7 100644
--- a/Documentation/x86/x86_64/fsgs.rst
+++ b/Documentation/arch/x86/x86_64/fsgs.rst
@@ -125,17 +125,17 @@ FSGSBASE instructions enablement
FSGSBASE instructions compiler support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-GCC version 4.6.4 and newer provide instrinsics for the FSGSBASE
+GCC version 4.6.4 and newer provide intrinsics for the FSGSBASE
instructions. Clang 5 supports them as well.
=================== ===========================
_readfsbase_u64() Read the FS base register
- _readfsbase_u64() Read the GS base register
+ _readgsbase_u64() Read the GS base register
_writefsbase_u64() Write the FS base register
_writegsbase_u64() Write the GS base register
=================== ===========================
-To utilize these instrinsics <immintrin.h> must be included in the source
+To utilize these intrinsics <immintrin.h> must be included in the source
code and the compiler option -mfsgsbase has to be added.
Compiler support for FS/GS based addressing
diff --git a/Documentation/arch/x86/x86_64/index.rst b/Documentation/arch/x86/x86_64/index.rst
new file mode 100644
index 000000000000..a0261957a08a
--- /dev/null
+++ b/Documentation/arch/x86/x86_64/index.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+x86_64 Support
+==============
+
+.. toctree::
+ :maxdepth: 2
+
+ uefi
+ mm
+ 5level-paging
+ fake-numa-for-cpusets
+ cpu-hotplug-spec
+ machinecheck
+ fsgs
+ fred
diff --git a/Documentation/x86/x86_64/machinecheck.rst b/Documentation/arch/x86/x86_64/machinecheck.rst
index cea12ee97200..cea12ee97200 100644
--- a/Documentation/x86/x86_64/machinecheck.rst
+++ b/Documentation/arch/x86/x86_64/machinecheck.rst
diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
new file mode 100644
index 000000000000..a6cf05d51bd8
--- /dev/null
+++ b/Documentation/arch/x86/x86_64/mm.rst
@@ -0,0 +1,180 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+Memory Management
+=================
+
+Complete virtual memory map with 4-level page tables
+====================================================
+
+.. note::
+
+ - Negative addresses such as "-23 TB" are absolute addresses in bytes, counted down
+ from the top of the 64-bit address space. It's easier to understand the layout
+ when seen both in absolute addresses and in distance-from-top notation.
+
+ For example 0xffffe90000000000 == -23 TB, it's 23 TB lower than the top of the
+ 64-bit address space (ffffffffffffffff).
+
+ Note that as we get closer to the top of the address space, the notation changes
+ from TB to GB and then MB/KB.
+
+ - "16M TB" might look weird at first sight, but it's an easier way to visualize size
+ notation than "16 EB", which few will recognize at first sight as 16 exabytes.
+ It also shows it nicely how incredibly large 64-bit address space is.
+
+::
+
+ ========================================================================================================================
+ Start addr | Offset | End addr | Size | VM area description
+ ========================================================================================================================
+ | | | |
+ 0000000000000000 | 0 | 00007fffffffefff | ~128 TB | user-space virtual memory, different per mm
+ 00007ffffffff000 | ~128 TB | 00007fffffffffff | 4 kB | ... guard hole
+ __________________|____________|__________________|_________|___________________________________________________________
+ | | | |
+ 0000800000000000 | +128 TB | 7fffffffffffffff | ~8 EB | ... huge, almost 63 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -8 EB
+ | | | | starting offset of kernel mappings.
+ | | | |
+ | | | | LAM relaxes canonicallity check allowing to create aliases
+ | | | | for userspace memory here.
+ __________________|____________|__________________|_________|___________________________________________________________
+ |
+ | Kernel-space virtual memory, shared between all processes:
+ __________________|____________|__________________|_________|___________________________________________________________
+ | | | |
+ 8000000000000000 | -8 EB | ffff7fffffffffff | ~8 EB | ... huge, almost 63 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -128 TB
+ | | | | starting offset of kernel mappings.
+ | | | |
+ | | | | LAM_SUP relaxes canonicallity check allowing to create
+ | | | | aliases for kernel memory here.
+ ____________________________________________________________|___________________________________________________________
+ | | | |
+ ffff800000000000 | -128 TB | ffff87ffffffffff | 8 TB | ... guard hole, also reserved for hypervisor
+ ffff880000000000 | -120 TB | ffff887fffffffff | 0.5 TB | LDT remap for PTI
+ ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory (page_offset_base)
+ ffffc88000000000 | -55.5 TB | ffffc8ffffffffff | 0.5 TB | ... unused hole
+ ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base)
+ ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
+ ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
+ ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
+ ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
+ __________________|____________|__________________|_________|____________________________________________________________
+ |
+ | Identical layout to the 56-bit one from here on:
+ ____________________________________________________________|____________________________________________________________
+ | | | |
+ fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
+ | | | | vaddr_end for KASLR
+ fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
+ fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
+ ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
+ ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
+ ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
+ ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
+ ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
+ ffffffff80000000 |-2048 MB | | |
+ ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
+ ffffffffff000000 | -16 MB | | |
+ FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
+ ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
+ ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
+ __________________|____________|__________________|_________|___________________________________________________________
+
+
+Complete virtual memory map with 5-level page tables
+====================================================
+
+.. note::
+
+ - With 56-bit addresses, user-space memory gets expanded by a factor of 512x,
+ from 0.125 PB to 64 PB. All kernel mappings shift down to the -64 PB starting
+ offset and many of the regions expand to support the much larger physical
+ memory supported.
+
+::
+
+ ========================================================================================================================
+ Start addr | Offset | End addr | Size | VM area description
+ ========================================================================================================================
+ | | | |
+ 0000000000000000 | 0 | 00fffffffffff000 | ~64 PB | user-space virtual memory, different per mm
+ 00fffffffffff000 | ~64 PB | 00ffffffffffffff | 4 kB | ... guard hole
+ __________________|____________|__________________|_________|___________________________________________________________
+ | | | |
+ 0100000000000000 | +64 PB | 7fffffffffffffff | ~8 EB | ... huge, almost 63 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -8EB TB
+ | | | | starting offset of kernel mappings.
+ | | | |
+ | | | | LAM relaxes canonicallity check allowing to create aliases
+ | | | | for userspace memory here.
+ __________________|____________|__________________|_________|___________________________________________________________
+ |
+ | Kernel-space virtual memory, shared between all processes:
+ ____________________________________________________________|___________________________________________________________
+ 8000000000000000 | -8 EB | feffffffffffffff | ~8 EB | ... huge, almost 63 bits wide hole of non-canonical
+ | | | | virtual memory addresses up to the -64 PB
+ | | | | starting offset of kernel mappings.
+ | | | |
+ | | | | LAM_SUP relaxes canonicallity check allowing to create
+ | | | | aliases for kernel memory here.
+ ____________________________________________________________|___________________________________________________________
+ | | | |
+ ff00000000000000 | -64 PB | ff0fffffffffffff | 4 PB | ... guard hole, also reserved for hypervisor
+ ff10000000000000 | -60 PB | ff10ffffffffffff | 0.25 PB | LDT remap for PTI
+ ff11000000000000 | -59.75 PB | ff90ffffffffffff | 32 PB | direct mapping of all physical memory (page_offset_base)
+ ff91000000000000 | -27.75 PB | ff9fffffffffffff | 3.75 PB | ... unused hole
+ ffa0000000000000 | -24 PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base)
+ ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
+ ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
+ ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
+ ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
+ __________________|____________|__________________|_________|____________________________________________________________
+ |
+ | Identical layout to the 47-bit one from here on:
+ ____________________________________________________________|____________________________________________________________
+ | | | |
+ fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
+ | | | | vaddr_end for KASLR
+ fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
+ fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
+ ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
+ ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
+ ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
+ ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
+ ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
+ ffffffff80000000 |-2048 MB | | |
+ ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
+ ffffffffff000000 | -16 MB | | |
+ FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
+ ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
+ ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
+ __________________|____________|__________________|_________|___________________________________________________________
+
+Architecture defines a 64-bit virtual address. Implementations can support
+less. Currently supported are 48- and 57-bit virtual addresses. Bits 63
+through to the most-significant implemented bit are sign extended.
+This causes hole between user space and kernel addresses if you interpret them
+as unsigned.
+
+The direct mapping covers all memory in the system up to the highest
+memory address (this means in some cases it can also include PCI memory
+holes).
+
+We map EFI runtime services in the 'efi_pgd' PGD in a 64GB large virtual
+memory window (this size is arbitrary, it can be raised later if needed).
+The mappings are not part of any other kernel PGD and are only available
+during EFI runtime calls.
+
+Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
+physical memory, vmalloc/ioremap space and virtual memory map are randomized.
+Their order is preserved but their base will be offset early at boot time.
+
+Be very careful vs. KASLR when changing anything here. The KASLR address
+range must not overlap with anything except the KASAN shadow area, which is
+correct as KASAN disables KASLR.
+
+For both 4- and 5-level layouts, the KSTACK_ERASE_POISON value in the last 2MB
+hole: ffffffffffff4111
diff --git a/Documentation/arch/x86/x86_64/uefi.rst b/Documentation/arch/x86/x86_64/uefi.rst
new file mode 100644
index 000000000000..e84592dbd6c1
--- /dev/null
+++ b/Documentation/arch/x86/x86_64/uefi.rst
@@ -0,0 +1,75 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+General note on [U]EFI x86_64 support
+=====================================
+
+The nomenclature EFI and UEFI are used interchangeably in this document.
+
+Although the tools below are _not_ needed for building the kernel,
+the needed bootloader support and associated tools for x86_64 platforms
+with EFI firmware and specifications are listed below.
+
+1. UEFI specification: http://www.uefi.org
+
+2. Booting Linux kernel on UEFI x86_64 platform can either be
+ done using the <Documentation/admin-guide/efi-stub.rst> or using a
+ separate bootloader.
+
+3. x86_64 platform with EFI/UEFI firmware.
+
+Mechanics
+---------
+
+Refer to <Documentation/admin-guide/efi-stub.rst> to learn how to use the EFI stub.
+
+Below are general EFI setup guidelines on the x86_64 platform,
+regardless of whether you use the EFI stub or a separate bootloader.
+
+- Build the kernel with the following configuration::
+
+ CONFIG_FB_EFI=y
+ CONFIG_FRAMEBUFFER_CONSOLE=y
+
+ If EFI runtime services are expected, the following configuration should
+ be selected::
+
+ CONFIG_EFI=y
+ CONFIG_EFIVAR_FS=y or m # optional
+
+- Create a VFAT partition on the disk with the EFI System flag
+ You can do this with fdisk with the following commands:
+
+ 1. g - initialize a GPT partition table
+ 2. n - create a new partition
+ 3. t - change the partition type to "EFI System" (number 1)
+ 4. w - write and save the changes
+
+ Afterwards, initialize the VFAT filesystem by running mkfs::
+
+ mkfs.fat /dev/<your-partition>
+
+- Copy the boot files to the VFAT partition:
+ If you use the EFI stub method, the kernel acts also as an EFI executable.
+
+ You can just copy the bzImage to the EFI/boot/bootx64.efi path on the partition
+ so that it will automatically get booted, see the <Documentation/admin-guide/efi-stub.rst> page
+ for additional instructions regarding passage of kernel parameters and initramfs.
+
+ If you use a custom bootloader, refer to the relevant documentation for help on this part.
+
+- If some or all EFI runtime services don't work, you can try following
+ kernel command line parameters to turn off some or all EFI runtime
+ services.
+
+ noefi
+ turn off all EFI runtime services
+ reboot_type=k
+ turn off EFI reboot runtime service
+
+- If the EFI memory map has additional entries not in the E820 map,
+ you can include those entries in the kernels memory map of available
+ physical RAM by using the following kernel command line parameter.
+
+ add_efi_memmap
+ include EFI memory map of available physical RAM
diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst
new file mode 100644
index 000000000000..cec05ac464c1
--- /dev/null
+++ b/Documentation/arch/x86/xstate.rst
@@ -0,0 +1,174 @@
+Using XSTATE features in user space applications
+================================================
+
+The x86 architecture supports floating-point extensions which are
+enumerated via CPUID. Applications consult CPUID and use XGETBV to
+evaluate which features have been enabled by the kernel XCR0.
+
+Up to AVX-512 and PKRU states, these features are automatically enabled by
+the kernel if available. Features like AMX TILE_DATA (XSTATE component 18)
+are enabled by XCR0 as well, but the first use of related instruction is
+trapped by the kernel because by default the required large XSTATE buffers
+are not allocated automatically.
+
+The purpose for dynamic features
+--------------------------------
+
+Legacy userspace libraries often have hard-coded, static sizes for
+alternate signal stacks, often using MINSIGSTKSZ which is typically 2KB.
+That stack must be able to store at *least* the signal frame that the
+kernel sets up before jumping into the signal handler. That signal frame
+must include an XSAVE buffer defined by the CPU.
+
+However, that means that the size of signal stacks is dynamic, not static,
+because different CPUs have differently-sized XSAVE buffers. A compiled-in
+size of 2KB with existing applications is too small for new CPU features
+like AMX. Instead of universally requiring larger stack, with the dynamic
+enabling, the kernel can enforce userspace applications to have
+properly-sized altstacks.
+
+Using dynamically enabled XSTATE features in user space applications
+--------------------------------------------------------------------
+
+The kernel provides an arch_prctl(2) based mechanism for applications to
+request the usage of such features. The arch_prctl(2) options related to
+this are:
+
+-ARCH_GET_XCOMP_SUPP
+
+ arch_prctl(ARCH_GET_XCOMP_SUPP, &features);
+
+ ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of
+ type uint64_t. The second argument is a pointer to that storage.
+
+-ARCH_GET_XCOMP_PERM
+
+ arch_prctl(ARCH_GET_XCOMP_PERM, &features);
+
+ ARCH_GET_XCOMP_PERM stores the features for which the userspace process
+ has permission in userspace storage of type uint64_t. The second argument
+ is a pointer to that storage.
+
+-ARCH_REQ_XCOMP_PERM
+
+ arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr);
+
+ ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled
+ feature or a feature set. A feature set can be mapped to a facility, e.g.
+ AMX, and can require one or more XSTATE components to be enabled.
+
+ The feature argument is the number of the highest XSTATE component which
+ is required for a facility to work.
+
+When requesting permission for a feature, the kernel checks the
+availability. The kernel ensures that sigaltstacks in the process's tasks
+are large enough to accommodate the resulting large signal frame. It
+enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent
+sigaltstack(2) calls. If an installed sigaltstack is smaller than the
+resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also,
+sigaltstack(2) results in -ENOMEM if the requested altstack is too small
+for the permitted features.
+
+Permission, when granted, is valid per process. Permissions are inherited
+on fork(2) and cleared on exec(3).
+
+The first use of an instruction related to a dynamically enabled feature is
+trapped by the kernel. The trap handler checks whether the process has
+permission to use the feature. If the process has no permission then the
+kernel sends SIGILL to the application. If the process has permission then
+the handler allocates a larger xstate buffer for the task so the large
+state can be context switched. In the unlikely cases that the allocation
+fails, the kernel sends SIGSEGV.
+
+AMX TILE_DATA enabling example
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Below is the example of how userspace applications enable
+TILE_DATA dynamically:
+
+ 1. The application first needs to query the kernel for AMX
+ support::
+
+ #include <asm/prctl.h>
+ #include <sys/syscall.h>
+ #include <stdio.h>
+ #include <unistd.h>
+
+ #ifndef ARCH_GET_XCOMP_SUPP
+ #define ARCH_GET_XCOMP_SUPP 0x1021
+ #endif
+
+ #ifndef ARCH_XCOMP_TILECFG
+ #define ARCH_XCOMP_TILECFG 17
+ #endif
+
+ #ifndef ARCH_XCOMP_TILEDATA
+ #define ARCH_XCOMP_TILEDATA 18
+ #endif
+
+ #define MASK_XCOMP_TILE ((1 << ARCH_XCOMP_TILECFG) | \
+ (1 << ARCH_XCOMP_TILEDATA))
+
+ unsigned long features;
+ long rc;
+
+ ...
+
+ rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
+
+ if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE)
+ printf("AMX is available.\n");
+
+ 2. After that, determining support for AMX, an application must
+ explicitly ask permission to use it::
+
+ #ifndef ARCH_REQ_XCOMP_PERM
+ #define ARCH_REQ_XCOMP_PERM 0x1023
+ #endif
+
+ ...
+
+ rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA);
+
+ if (!rc)
+ printf("AMX is ready for use.\n");
+
+Note this example does not include the sigaltstack preparation.
+
+Dynamic features in signal frames
+---------------------------------
+
+Dynamically enabled features are not written to the signal frame upon signal
+entry if the feature is in its initial configuration. This differs from
+non-dynamic features which are always written regardless of their
+configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
+field to determine if a features was written.
+
+Dynamic features for virtual machines
+-------------------------------------
+
+The permission for the guest state component needs to be managed separately
+from the host, as they are exclusive to each other. A coupled of options
+are extended to control the guest permission:
+
+-ARCH_GET_XCOMP_GUEST_PERM
+
+ arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features);
+
+ ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it
+ provides the same semantics and functionality but for the guest
+ components.
+
+-ARCH_REQ_XCOMP_GUEST_PERM
+
+ arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr);
+
+ ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the
+ same semantics for the guest permission. While providing a similar
+ functionality, this comes with a constraint. Permission is frozen when the
+ first VCPU is created. Any attempt to change permission after that point
+ is going to be rejected. So, the permission has to be requested before the
+ first VCPU creation.
+
+Note that some VMMs may have already established a set of supported state
+components. These options are not presumed to support any particular VMM.
diff --git a/Documentation/x86/zero-page.rst b/Documentation/arch/x86/zero-page.rst
index 45aa9cceb4f1..45aa9cceb4f1 100644
--- a/Documentation/x86/zero-page.rst
+++ b/Documentation/arch/x86/zero-page.rst
diff --git a/Documentation/xtensa/atomctl.rst b/Documentation/arch/xtensa/atomctl.rst
index 1ecbd0ba9a2e..75d174169430 100644
--- a/Documentation/xtensa/atomctl.rst
+++ b/Documentation/arch/xtensa/atomctl.rst
@@ -23,7 +23,7 @@ doing a Cached (WB) transaction and use the Memory RCW for un-cached
operations.
For systems without an coherent cache controller, non-MX, we always
-use the memory controllers RCW, thought non-MX controlers likely
+use the memory controllers RCW, though non-MX controllers likely
support the Internal Operation.
CUSTOMER-WARNING:
diff --git a/Documentation/xtensa/booting.rst b/Documentation/arch/xtensa/booting.rst
index e1b83707e5b6..e1b83707e5b6 100644
--- a/Documentation/xtensa/booting.rst
+++ b/Documentation/arch/xtensa/booting.rst
diff --git a/Documentation/arch/xtensa/features.rst b/Documentation/arch/xtensa/features.rst
new file mode 100644
index 000000000000..28dcce1759be
--- /dev/null
+++ b/Documentation/arch/xtensa/features.rst
@@ -0,0 +1,3 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. kernel-feat:: features xtensa
diff --git a/Documentation/xtensa/index.rst b/Documentation/arch/xtensa/index.rst
index 69952446a9be..69952446a9be 100644
--- a/Documentation/xtensa/index.rst
+++ b/Documentation/arch/xtensa/index.rst
diff --git a/Documentation/xtensa/mmu.rst b/Documentation/arch/xtensa/mmu.rst
index 450573afa31a..450573afa31a 100644
--- a/Documentation/xtensa/mmu.rst
+++ b/Documentation/arch/xtensa/mmu.rst
diff --git a/Documentation/arm/features.rst b/Documentation/arm/features.rst
deleted file mode 100644
index 7414ec03dd15..000000000000
--- a/Documentation/arm/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features arm
diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst
deleted file mode 100644
index 495ada7915e1..000000000000
--- a/Documentation/arm/index.rst
+++ /dev/null
@@ -1,86 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-================
-ARM Architecture
-================
-
-.. toctree::
- :maxdepth: 1
-
- arm
- booting
- cluster-pm-race-avoidance
- firmware
- interrupts
- kernel_mode_neon
- kernel_user_helpers
- memory
- mem_alignment
- tcm
- setup
- swp_emulation
- uefi
- vlocks
- porting
-
- features
-
-SoC-specific documents
-======================
-
-.. toctree::
- :maxdepth: 1
-
- google/chromebook-boot-flow
-
- ixp4xx
-
- marvell
- microchip
-
- netwinder
- nwfpe/index
-
- keystone/overview
- keystone/knav-qmss
-
- omap/index
-
- pxa/mfp
-
-
- sa1100/index
-
- stm32/stm32f746-overview
- stm32/overview
- stm32/stm32h743-overview
- stm32/stm32h750-overview
- stm32/stm32f769-overview
- stm32/stm32f429-overview
- stm32/stm32mp13-overview
- stm32/stm32mp157-overview
-
- sunxi
-
- samsung/index
- samsung-s3c24xx/index
-
- sunxi/clocks
-
- spear/overview
-
- sti/stih416-overview
- sti/stih407-overview
- sti/stih418-overview
- sti/overview
- sti/stih415-overview
-
- vfp/release-notes
-
-
-.. only:: subproject and html
-
- Indices
- =======
-
- * :ref:`genindex`
diff --git a/Documentation/arm/samsung-s3c24xx/cpufreq.rst b/Documentation/arm/samsung-s3c24xx/cpufreq.rst
deleted file mode 100644
index cd22697cf606..000000000000
--- a/Documentation/arm/samsung-s3c24xx/cpufreq.rst
+++ /dev/null
@@ -1,77 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0-only
-
-=======================
-S3C24XX CPUfreq support
-=======================
-
-Introduction
-------------
-
- The S3C24XX series support a number of power saving systems, such as
- the ability to change the core, memory and peripheral operating
- frequencies. The core control is exported via the CPUFreq driver
- which has a number of different manual or automatic controls over the
- rate the core is running at.
-
- There are two forms of the driver depending on the specific CPU and
- how the clocks are arranged. The first implementation used as single
- PLL to feed the ARM, memory and peripherals via a series of dividers
- and muxes and this is the implementation that is documented here. A
- newer version where there is a separate PLL and clock divider for the
- ARM core is available as a separate driver.
-
-
-Layout
-------
-
- The code core manages the CPU specific drivers, any data that they
- need to register and the interface to the generic drivers/cpufreq
- system. Each CPU registers a driver to control the PLL, clock dividers
- and anything else associated with it. Any board that wants to use this
- framework needs to supply at least basic details of what is required.
-
- The core registers with drivers/cpufreq at init time if all the data
- necessary has been supplied.
-
-
-CPU support
------------
-
- The support for each CPU depends on the facilities provided by the
- SoC and the driver as each device has different PLL and clock chains
- associated with it.
-
-
-Slow Mode
----------
-
- The SLOW mode where the PLL is turned off altogether and the
- system is fed by the external crystal input is currently not
- supported.
-
-
-sysfs
------
-
- The core code exports extra information via sysfs in the directory
- devices/system/cpu/cpu0/arch-freq.
-
-
-Board Support
--------------
-
- Each board that wants to use the cpufreq code must register some basic
- information with the core driver to provide information about what the
- board requires and any restrictions being placed on it.
-
- The board needs to supply information about whether it needs the IO bank
- timings changing, any maximum frequency limits and information about the
- SDRAM refresh rate.
-
-
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2009 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/eb2410itx.rst b/Documentation/arm/samsung-s3c24xx/eb2410itx.rst
deleted file mode 100644
index 7863c93652f8..000000000000
--- a/Documentation/arm/samsung-s3c24xx/eb2410itx.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-===================================
-Simtec Electronics EB2410ITX (BAST)
-===================================
-
- http://www.simtec.co.uk/products/EB2410ITX/
-
-Introduction
-------------
-
- The EB2410ITX is a S3C2410 based development board with a variety of
- peripherals and expansion connectors. This board is also known by
- the shortened name of Bast.
-
-
-Configuration
--------------
-
- To set the default configuration, use `make bast_defconfig` which
- supports the commonly used features of this board.
-
-
-Support
--------
-
- Official support information can be found on the Simtec Electronics
- website, at the product page http://www.simtec.co.uk/products/EB2410ITX/
-
- Useful links:
-
- - Resources Page http://www.simtec.co.uk/products/EB2410ITX/resources.html
-
- - Board FAQ at http://www.simtec.co.uk/products/EB2410ITX/faq.html
-
- - Bootloader info http://www.simtec.co.uk/products/SWABLE/resources.html
- and FAQ http://www.simtec.co.uk/products/SWABLE/faq.html
-
-
-MTD
----
-
- The NAND and NOR support has been merged from the linux-mtd project.
- Any problems, see http://www.linux-mtd.infradead.org/ for more
- information or up-to-date versions of linux-mtd.
-
-
-IDE
----
-
- Both onboard IDE ports are supported, however there is no support for
- changing speed of devices, PIO Mode 4 capable drives should be used.
-
-
-Maintainers
------------
-
- This board is maintained by Simtec Electronics.
-
-
-Copyright 2004 Ben Dooks, Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/gpio.rst b/Documentation/arm/samsung-s3c24xx/gpio.rst
deleted file mode 100644
index f4a8c800a457..000000000000
--- a/Documentation/arm/samsung-s3c24xx/gpio.rst
+++ /dev/null
@@ -1,172 +0,0 @@
-====================
-S3C24XX GPIO Control
-====================
-
-Introduction
-------------
-
- The s3c2410 kernel provides an interface to configure and
- manipulate the state of the GPIO pins, and find out other
- information about them.
-
- There are a number of conditions attached to the configuration
- of the s3c2410 GPIO system, please read the Samsung provided
- data-sheet/users manual to find out the complete list.
-
- See Documentation/arm/samsung/gpio.rst for the core implementation.
-
-
-GPIOLIB
--------
-
- With the event of the GPIOLIB in drivers/gpio, support for some
- of the GPIO functions such as reading and writing a pin will
- be removed in favour of this common access method.
-
- Once all the extant drivers have been converted, the functions
- listed below will be removed (they may be marked as __deprecated
- in the near future).
-
- The following functions now either have a `s3c_` specific variant
- or are merged into gpiolib. See the definitions in
- arch/arm/mach-s3c/gpio-cfg.h:
-
- - s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
- - s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
- - s3c2410_gpio_getirq() gpio_to_irq()
- - s3c2410_gpio_cfgpin() s3c_gpio_cfgpin()
- - s3c2410_gpio_getcfg() s3c_gpio_getcfg()
- - s3c2410_gpio_pullup() s3c_gpio_setpull()
-
-
-GPIOLIB conversion
-------------------
-
-If you need to convert your board or driver to use gpiolib from the phased
-out s3c2410 API, then here are some notes on the process.
-
-1) If your board is exclusively using an GPIO, say to control peripheral
- power, then it will require to claim the gpio with gpio_request() before
- it can use it.
-
- It is recommended to check the return value, with at least WARN_ON()
- during initialisation.
-
-2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
- as they have the same arguments, and can either take the pin specific
- values, or the more generic special-function-number arguments.
-
-3) s3c2410_gpio_pullup() changes have the problem that while the
- s3c2410_gpio_pullup(x, 1) can be easily translated to the
- s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
- are not so easy.
-
- The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
- of some of the devices, a pull-down) and as such the new API distinguishes
- between the UP and DOWN case. There is currently no 'just turn on' setting
- which may be required if this becomes a problem.
-
-4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
- does not implicitly configure the relevant gpio to output. The gpio
- direction should be changed before using gpio_set_value().
-
-5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
- has been set to input. It is currently unknown what the behaviour is
- when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
- would return the value the pin is supposed to be outputting).
-
-6) s3c2410_gpio_getirq() should be directly replaceable with the
- gpio_to_irq() call.
-
-The s3c2410_gpio and `gpio_` calls have always operated on the same gpio
-numberspace, so there is no problem with converting the gpio numbering
-between the calls.
-
-
-Headers
--------
-
- See arch/arm/mach-s3c/regs-gpio-s3c24xx.h for the list
- of GPIO pins, and the configuration values for them. This
- is included by using #include <mach/regs-gpio.h>
-
-
-PIN Numbers
------------
-
- Each pin has an unique number associated with it in regs-gpio.h,
- e.g. S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
- the GPIO functions which pin is to be used.
-
- With the conversion to gpiolib, there is no longer a direct conversion
- from gpio pin number to register base address as in earlier kernels. This
- is due to the number space required for newer SoCs where the later
- GPIOs are not contiguous.
-
-
-Configuring a pin
------------------
-
- The following function allows the configuration of a given pin to
- be changed.
-
- void s3c_gpio_cfgpin(unsigned int pin, unsigned int function);
-
- e.g.:
-
- s3c_gpio_cfgpin(S3C2410_GPA(0), S3C_GPIO_SFN(1));
- s3c_gpio_cfgpin(S3C2410_GPE(8), S3C_GPIO_SFN(2));
-
- which would turn GPA(0) into the lowest Address line A0, and set
- GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
-
-
-Reading the current configuration
----------------------------------
-
- The current configuration of a pin can be read by using standard
- gpiolib function:
-
- s3c_gpio_getcfg(unsigned int pin);
-
- The return value will be from the same set of values which can be
- passed to s3c_gpio_cfgpin().
-
-
-Configuring a pull-up resistor
-------------------------------
-
- A large proportion of the GPIO pins on the S3C2410 can have weak
- pull-up resistors enabled. This can be configured by the following
- function:
-
- void s3c_gpio_setpull(unsigned int pin, unsigned int to);
-
- Where the to value is S3C_GPIO_PULL_NONE to set the pull-up off,
- and S3C_GPIO_PULL_UP to enable the specified pull-up. Any other
- values are currently undefined.
-
-
-Getting and setting the state of a PIN
---------------------------------------
-
- These calls are now implemented by the relevant gpiolib calls, convert
- your board or driver to use gpiolib.
-
-
-Getting the IRQ number associated with a PIN
---------------------------------------------
-
- A standard gpiolib function can map the given pin number to an IRQ
- number to pass to the IRQ system.
-
- int gpio_to_irq(unsigned int pin);
-
- Note, not all pins have an IRQ.
-
-
-Author
--------
-
-Ben Dooks, 03 October 2004
-Copyright 2004 Ben Dooks, Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/h1940.rst b/Documentation/arm/samsung-s3c24xx/h1940.rst
deleted file mode 100644
index 62a562c178e3..000000000000
--- a/Documentation/arm/samsung-s3c24xx/h1940.rst
+++ /dev/null
@@ -1,41 +0,0 @@
-=============
-HP IPAQ H1940
-=============
-
-http://www.handhelds.org/projects/h1940.html
-
-Introduction
-------------
-
- The HP H1940 is a S3C2410 based handheld device, with
- bluetooth connectivity.
-
-
-Support
--------
-
- A variety of information is available
-
- handhelds.org project page:
-
- http://www.handhelds.org/projects/h1940.html
-
- handhelds.org wiki page:
-
- http://handhelds.org/moin/moin.cgi/HpIpaqH1940
-
- Herbert Pötzl pages:
-
- http://vserver.13thfloor.at/H1940/
-
-
-Maintainers
------------
-
- This project is being maintained and developed by a variety
- of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
-
- Thanks to the many others who have also provided support.
-
-
-(c) 2005 Ben Dooks
diff --git a/Documentation/arm/samsung-s3c24xx/index.rst b/Documentation/arm/samsung-s3c24xx/index.rst
deleted file mode 100644
index ccb951a0bedb..000000000000
--- a/Documentation/arm/samsung-s3c24xx/index.rst
+++ /dev/null
@@ -1,20 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-==========================
-Samsung S3C24XX SoC Family
-==========================
-
-.. toctree::
- :maxdepth: 1
-
- h1940
- gpio
- cpufreq
- suspend
- usb-host
- s3c2412
- eb2410itx
- nand
- smdk2440
- s3c2413
- overview
diff --git a/Documentation/arm/samsung-s3c24xx/nand.rst b/Documentation/arm/samsung-s3c24xx/nand.rst
deleted file mode 100644
index 938995694ee7..000000000000
--- a/Documentation/arm/samsung-s3c24xx/nand.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-====================
-S3C24XX NAND Support
-====================
-
-Introduction
-------------
-
-Small Page NAND
----------------
-
-The driver uses a 512 byte (1 page) ECC code for this setup. The
-ECC code is not directly compatible with the default kernel ECC
-code, so the driver enforces its own OOB layout and ECC parameters
-
-Large Page NAND
----------------
-
-The driver is capable of handling NAND flash with a 2KiB page
-size, with support for hardware ECC generation and correction.
-
-Unlike the 512byte page mode, the driver generates ECC data for
-each 256 byte block in an 2KiB page. This means that more than
-one error in a page can be rectified. It also means that the
-OOB layout remains the default kernel layout for these flashes.
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2007 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/overview.rst b/Documentation/arm/samsung-s3c24xx/overview.rst
deleted file mode 100644
index 14535e5cffb7..000000000000
--- a/Documentation/arm/samsung-s3c24xx/overview.rst
+++ /dev/null
@@ -1,311 +0,0 @@
-==========================
-S3C24XX ARM Linux Overview
-==========================
-
-
-
-Introduction
-------------
-
- The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
- by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
- S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443 and S3C2450 devices
- are supported.
-
- Support for the S3C2400 and S3C24A0 series was never completed and the
- corresponding code has been removed after a while. If someone wishes to
- revive this effort, partial support can be retrieved from earlier Linux
- versions.
-
- The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
- included under the arch/arm/mach-s3c directory. Note, while core
- support for these SoCs is in, work on some of the extra peripherals
- and extra interrupts is still ongoing.
-
-
-Configuration
--------------
-
- A generic S3C2410 configuration is provided, and can be used as the
- default by `make s3c2410_defconfig`. This configuration has support
- for all the machines, and the commonly used features on them.
-
- Certain machines may have their own default configurations as well,
- please check the machine specific documentation.
-
-
-Layout
-------
-
- The core support files, register, kernel and paltform data are located in the
- platform code contained in arch/arm/mach-s3c with headers in
- arch/arm/mach-s3c/include
-
-arch/arm/mach-s3c:
-
- Files in here are either common to all the s3c24xx family,
- or are common to only some of them with names to indicate this
- status. The files that are not common to all are generally named
- with the initial cpu they support in the series to ensure a short
- name without any possibility of confusion with newer devices.
-
- As an example, initially s3c244x would cover s3c2440 and s3c2442, but
- with the s3c2443 which does not share many of the same drivers in
- this directory, the name becomes invalid. We stick to s3c2440-<x>
- to indicate a driver that is s3c2440 and s3c2442 compatible.
-
- This does mean that to find the status of any given SoC, a number
- of directories may need to be searched.
-
-
-Machines
---------
-
- The currently supported machines are as follows:
-
- Simtec Electronics EB2410ITX (BAST)
-
- A general purpose development board, see EB2410ITX.txt for further
- details
-
- Simtec Electronics IM2440D20 (Osiris)
-
- CPU Module from Simtec Electronics, with a S3C2440A CPU, nand flash
- and a PCMCIA controller.
-
- Samsung SMDK2410
-
- Samsung's own development board, geared for PDA work.
-
- Samsung/Aiji SMDK2412
-
- The S3C2412 version of the SMDK2440.
-
- Samsung/Aiji SMDK2413
-
- The S3C2412 version of the SMDK2440.
-
- Samsung/Meritech SMDK2440
-
- The S3C2440 compatible version of the SMDK2440, which has the
- option of an S3C2440 or S3C2442 CPU module.
-
- Thorcom VR1000
-
- Custom embedded board
-
- HP IPAQ 1940
-
- Handheld (IPAQ), available in several varieties
-
- HP iPAQ rx3715
-
- S3C2440 based IPAQ, with a number of variations depending on
- features shipped.
-
- Acer N30
-
- A S3C2410 based PDA from Acer. There is a Wiki page at
- http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
-
- AML M5900
-
- American Microsystems' M5900
-
- Nex Vision Nexcoder
- Nex Vision Otom
-
- Two machines by Nex Vision
-
-
-Adding New Machines
--------------------
-
- The architecture has been designed to support as many machines as can
- be configured for it in one kernel build, and any future additions
- should keep this in mind before altering items outside of their own
- machine files.
-
- Machine definitions should be kept in arch/arm/mach-s3c,
- and there are a number of examples that can be looked at.
-
- Read the kernel patch submission policies as well as the
- Documentation/arm directory before submitting patches. The
- ARM kernel series is managed by Russell King, and has a patch system
- located at http://www.arm.linux.org.uk/developer/patches/
- as well as mailing lists that can be found from the same site.
-
- As a courtesy, please notify <ben-linux@fluff.org> of any new
- machines or other modifications.
-
- Any large scale modifications, or new drivers should be discussed
- on the ARM kernel mailing list (linux-arm-kernel) before being
- attempted. See http://www.arm.linux.org.uk/mailinglists/ for the
- mailing list information.
-
-
-I2C
----
-
- The hardware I2C core in the CPU is supported in single master
- mode, and can be configured via platform data.
-
-
-RTC
----
-
- Support for the onboard RTC unit, including alarm function.
-
- This has recently been upgraded to use the new RTC core,
- and the module has been renamed to rtc-s3c to fit in with
- the new rtc naming scheme.
-
-
-Watchdog
---------
-
- The onchip watchdog is available via the standard watchdog
- interface.
-
-
-NAND
-----
-
- The current kernels now have support for the s3c2410 NAND
- controller. If there are any problems the latest linux-mtd
- code can be found from http://www.linux-mtd.infradead.org/
-
- For more information see Documentation/arm/samsung-s3c24xx/nand.rst
-
-
-SD/MMC
-------
-
- The SD/MMC hardware pre S3C2443 is supported in the current
- kernel, the driver is drivers/mmc/host/s3cmci.c and supports
- 1 and 4 bit SD or MMC cards.
-
- The SDIO behaviour of this driver has not been fully tested. There is no
- current support for hardware SDIO interrupts.
-
-
-Serial
-------
-
- The s3c2410 serial driver provides support for the internal
- serial ports. These devices appear as /dev/ttySAC0 through 3.
-
- To create device nodes for these, use the following commands
-
- mknod ttySAC0 c 204 64
- mknod ttySAC1 c 204 65
- mknod ttySAC2 c 204 66
-
-
-GPIO
-----
-
- The core contains support for manipulating the GPIO, see the
- documentation in GPIO.txt in the same directory as this file.
-
- Newer kernels carry GPIOLIB, and support is being moved towards
- this with some of the older support in line to be removed.
-
- As of v2.6.34, the move towards using gpiolib support is almost
- complete, and very little of the old calls are left.
-
- See Documentation/arm/samsung-s3c24xx/gpio.rst for the S3C24XX specific
- support and Documentation/arm/samsung/gpio.rst for the core Samsung
- implementation.
-
-
-Clock Management
-----------------
-
- The core provides the interface defined in the header file
- include/asm-arm/hardware/clock.h, to allow control over the
- various clock units
-
-
-Suspend to RAM
---------------
-
- For boards that provide support for suspend to RAM, the
- system can be placed into low power suspend.
-
- See Suspend.txt for more information.
-
-
-SPI
----
-
- SPI drivers are available for both the in-built hardware
- (although there is no DMA support yet) and a generic
- GPIO based solution.
-
-
-LEDs
-----
-
- There is support for GPIO based LEDs via a platform driver
- in the LED subsystem.
-
-
-Platform Data
--------------
-
- Whenever a device has platform specific data that is specified
- on a per-machine basis, care should be taken to ensure the
- following:
-
- 1) that default data is not left in the device to confuse the
- driver if a machine does not set it at startup
-
- 2) the data should (if possible) be marked as __initdata,
- to ensure that the data is thrown away if the machine is
- not the one currently in use.
-
- The best way of doing this is to make a function that
- kmalloc()s an area of memory, and copies the __initdata
- and then sets the relevant device's platform data. Making
- the function `__init` takes care of ensuring it is discarded
- with the rest of the initialisation code::
-
- static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)
- {
- struct s3c2410_xxx_mach_info *npd;
-
- npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);
- if (npd) {
- memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info));
- s3c_device_xxx.dev.platform_data = npd;
- } else {
- printk(KERN_ERR "no memory for xxx platform data\n");
- }
- }
-
- Note, since the code is marked as __init, it should not be
- exported outside arch/arm/mach-s3c/, or exported to
- modules via EXPORT_SYMBOL() and related functions.
-
-
-Port Contributors
------------------
-
- Ben Dooks (BJD)
- Vincent Sanders
- Herbert Potzl
- Arnaud Patard (RTP)
- Roc Wu
- Klaus Fetscher
- Dimitry Andric
- Shannon Holland
- Guillaume Gourat (NexVision)
- Christer Weinigel (wingel) (Acer N30)
- Lucas Correia Villa Real (S3C2400 port)
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2004-2006 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/s3c2412.rst b/Documentation/arm/samsung-s3c24xx/s3c2412.rst
deleted file mode 100644
index 68b985fc6bf4..000000000000
--- a/Documentation/arm/samsung-s3c24xx/s3c2412.rst
+++ /dev/null
@@ -1,121 +0,0 @@
-==========================
-S3C2412 ARM Linux Overview
-==========================
-
-Introduction
-------------
-
- The S3C2412 is part of the S3C24XX range of ARM9 System-on-Chip CPUs
- from Samsung. This part has an ARM926-EJS core, capable of running up
- to 266MHz (see data-sheet for more information)
-
-
-Clock
------
-
- The core clock code provides a set of clocks to the drivers, and allows
- for source selection and a number of other features.
-
-
-Power
------
-
- No support for suspend/resume to RAM in the current system.
-
-
-DMA
----
-
- No current support for DMA.
-
-
-GPIO
-----
-
- There is support for setting the GPIO to input/output/special function
- and reading or writing to them.
-
-
-UART
-----
-
- The UART hardware is similar to the S3C2440, and is supported by the
- s3c2410 driver in the drivers/serial directory.
-
-
-NAND
-----
-
- The NAND hardware is similar to the S3C2440, and is supported by the
- s3c2410 driver in the drivers/mtd/nand/raw directory.
-
-
-USB Host
---------
-
- The USB hardware is similar to the S3C2410, with extended clock source
- control. The OHCI portion is supported by the ohci-s3c2410 driver, and
- the clock control selection is supported by the core clock code.
-
-
-USB Device
-----------
-
- No current support in the kernel
-
-
-IRQs
-----
-
- All the standard, and external interrupt sources are supported. The
- extra sub-sources are not yet supported.
-
-
-RTC
----
-
- The RTC hardware is similar to the S3C2410, and is supported by the
- s3c2410-rtc driver.
-
-
-Watchdog
---------
-
- The watchdog hardware is the same as the S3C2410, and is supported by
- the s3c2410_wdt driver.
-
-
-MMC/SD/SDIO
------------
-
- No current support for the MMC/SD/SDIO block.
-
-IIC
----
-
- The IIC hardware is the same as the S3C2410, and is supported by the
- i2c-s3c24xx driver.
-
-
-IIS
----
-
- No current support for the IIS interface.
-
-
-SPI
----
-
- No current support for the SPI interfaces.
-
-
-ATA
----
-
- No current support for the on-board ATA block.
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2006 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/s3c2413.rst b/Documentation/arm/samsung-s3c24xx/s3c2413.rst
deleted file mode 100644
index 1f51e207fc46..000000000000
--- a/Documentation/arm/samsung-s3c24xx/s3c2413.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-==========================
-S3C2413 ARM Linux Overview
-==========================
-
-Introduction
-------------
-
- The S3C2413 is an extended version of the S3C2412, with an camera
- interface and mobile DDR memory support. See the S3C2412 support
- documentation for more information.
-
-
-Camera Interface
-----------------
-
- This block is currently not supported.
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2006 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/smdk2440.rst b/Documentation/arm/samsung-s3c24xx/smdk2440.rst
deleted file mode 100644
index 524fd0b4afaf..000000000000
--- a/Documentation/arm/samsung-s3c24xx/smdk2440.rst
+++ /dev/null
@@ -1,57 +0,0 @@
-=========================
-Samsung/Meritech SMDK2440
-=========================
-
-Introduction
-------------
-
- The SMDK2440 is a two part evaluation board for the Samsung S3C2440
- processor. It includes support for LCD, SmartMedia, Audio, SD and
- 10MBit Ethernet, and expansion headers for various signals, including
- the camera and unused GPIO.
-
-
-Configuration
--------------
-
- To set the default configuration, use `make smdk2440_defconfig` which
- will configure the common features of this board, or use
- `make s3c2410_config` to include support for all s3c2410/s3c2440 machines
-
-
-Support
--------
-
- Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which
- includes linux based USB download tools.
-
- Some of the h1940 patches that can be found from the H1940 project
- site at http://www.handhelds.org/projects/h1940.html can also be
- applied to this board.
-
-
-Peripherals
------------
-
- There is no current support for any of the extra peripherals on the
- base-board itself.
-
-
-MTD
----
-
- The NAND flash should be supported by the in kernel MTD NAND support,
- NOR flash will be added later.
-
-
-Maintainers
------------
-
- This board is being maintained by Ben Dooks, for more info, see
- http://www.fluff.org/ben/smdk2440/
-
- Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440,
- and to Simtec Electronics for allowing me time to work on this.
-
-
-(c) 2004 Ben Dooks
diff --git a/Documentation/arm/samsung-s3c24xx/suspend.rst b/Documentation/arm/samsung-s3c24xx/suspend.rst
deleted file mode 100644
index b4f3ae9fe76e..000000000000
--- a/Documentation/arm/samsung-s3c24xx/suspend.rst
+++ /dev/null
@@ -1,137 +0,0 @@
-=======================
-S3C24XX Suspend Support
-=======================
-
-
-Introduction
-------------
-
- The S3C24XX supports a low-power suspend mode, where the SDRAM is kept
- in Self-Refresh mode, and all but the essential peripheral blocks are
- powered down. For more information on how this works, please look
- at the relevant CPU datasheet from Samsung.
-
-
-Requirements
-------------
-
- 1) A bootloader that can support the necessary resume operation
-
- 2) Support for at least 1 source for resume
-
- 3) CONFIG_PM enabled in the kernel
-
- 4) Any peripherals that are going to be powered down at the same
- time require suspend/resume support.
-
-
-Resuming
---------
-
- The S3C2410 user manual defines the process of sending the CPU to
- sleep and how it resumes. The default behaviour of the Linux code
- is to set the GSTATUS3 register to the physical address of the
- code to resume Linux operation.
-
- GSTATUS4 is currently left alone by the sleep code, and is free to
- use for any other purposes (for example, the EB2410ITX uses this to
- save memory configuration in).
-
-
-Machine Support
----------------
-
- The machine specific functions must call the s3c_pm_init() function
- to say that its bootloader is capable of resuming. This can be as
- simple as adding the following to the machine's definition:
-
- INITMACHINE(s3c_pm_init)
-
- A board can do its own setup before calling s3c_pm_init, if it
- needs to setup anything else for power management support.
-
- There is currently no support for over-riding the default method of
- saving the resume address, if your board requires it, then contact
- the maintainer and discuss what is required.
-
- Note, the original method of adding an late_initcall() is wrong,
- and will end up initialising all compiled machines' pm init!
-
- The following is an example of code used for testing wakeup from
- an falling edge on IRQ_EINT0::
-
-
- static irqreturn_t button_irq(int irq, void *pw)
- {
- return IRQ_HANDLED;
- }
-
- statuc void __init machine_init(void)
- {
- ...
-
- request_irq(IRQ_EINT0, button_irq, IRQF_TRIGGER_FALLING,
- "button-irq-eint0", NULL);
-
- enable_irq_wake(IRQ_EINT0);
-
- s3c_pm_init();
- }
-
-
-Debugging
----------
-
- There are several important things to remember when using PM suspend:
-
- 1) The uart drivers will disable the clocks to the UART blocks when
- suspending, which means that use of printascii() or similar direct
- access to the UARTs will cause the debug to stop.
-
- 2) While the pm code itself will attempt to re-enable the UART clocks,
- care should be taken that any external clock sources that the UARTs
- rely on are still enabled at that point.
-
- 3) If any debugging is placed in the resume path, then it must have the
- relevant clocks and peripherals setup before use (ie, bootloader).
-
- For example, if you transmit a character from the UART, the baud
- rate and uart controls must be setup beforehand.
-
-
-Configuration
--------------
-
- The S3C2410 specific configuration in `System Type` defines various
- aspects of how the S3C2410 suspend and resume support is configured
-
- `S3C2410 PM Suspend debug`
-
- This option prints messages to the serial console before and after
- the actual suspend, giving detailed information on what is
- happening
-
-
- `S3C2410 PM Suspend Memory CRC`
-
- Allows the entire memory to be checksummed before and after the
- suspend to see if there has been any corruption of the contents.
-
- Note, the time to calculate the CRC is dependent on the CPU speed
- and the size of memory. For an 64Mbyte RAM area on an 200MHz
- S3C2410, this can take approximately 4 seconds to complete.
-
- This support requires the CRC32 function to be enabled.
-
-
- `S3C2410 PM Suspend CRC Chunksize (KiB)`
-
- Defines the size of memory each CRC chunk covers. A smaller value
- will mean that the CRC data block will take more memory, but will
- identify any faults with better precision
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2004 Simtec Electronics
diff --git a/Documentation/arm/samsung-s3c24xx/usb-host.rst b/Documentation/arm/samsung-s3c24xx/usb-host.rst
deleted file mode 100644
index 7aaffac89e04..000000000000
--- a/Documentation/arm/samsung-s3c24xx/usb-host.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-========================
-S3C24XX USB Host support
-========================
-
-
-
-Introduction
-------------
-
- This document details the S3C2410/S3C2440 in-built OHCI USB host support.
-
-Configuration
--------------
-
- Enable at least the following kernel options:
-
- menuconfig::
-
- Device Drivers --->
- USB support --->
- <*> Support for Host-side USB
- <*> OHCI HCD support
-
-
- .config:
-
- - CONFIG_USB
- - CONFIG_USB_OHCI_HCD
-
-
- Once these options are configured, the standard set of USB device
- drivers can be configured and used.
-
-
-Board Support
--------------
-
- The driver attaches to a platform device, which will need to be
- added by the board specific support file in arch/arm/mach-s3c,
- such as mach-bast.c or mach-smdk2410.c
-
- The platform device's platform_data field is only needed if the
- board implements extra power control or over-current monitoring.
-
- The OHCI driver does not ensure the state of the S3C2410's MISCCTRL
- register, so if both ports are to be used for the host, then it is
- the board support file's responsibility to ensure that the second
- port is configured to be connected to the OHCI core.
-
-
-Platform Data
--------------
-
- See include/linux/platform_data/usb-ohci-s3c2410.h for the
- descriptions of the platform device data. An implementation
- can be found in arch/arm/mach-s3c/simtec-usb.c .
-
- The `struct s3c2410_hcd_info` contains a pair of functions
- that get called to enable over-current detection, and to
- control the port power status.
-
- The ports are numbered 0 and 1.
-
- power_control:
- Called to enable or disable the power on the port.
-
- enable_oc:
- Called to enable or disable the over-current monitoring.
- This should claim or release the resources being used to
- check the power condition on the port, such as an IRQ.
-
- report_oc:
- The OHCI driver fills this field in for the over-current code
- to call when there is a change to the over-current state on
- an port. The ports argument is a bitmask of 1 bit per port,
- with bit X being 1 for an over-current on port X.
-
- The function s3c2410_usb_report_oc() has been provided to
- ensure this is called correctly.
-
- port[x]:
- This is struct describes each port, 0 or 1. The platform driver
- should set the flags field of each port to S3C_HCDFLG_USED if
- the port is enabled.
-
-
-
-Document Author
----------------
-
-Ben Dooks, Copyright 2005 Simtec Electronics
diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arm/samsung/gpio.rst
deleted file mode 100644
index f6e27b07c993..000000000000
--- a/Documentation/arm/samsung/gpio.rst
+++ /dev/null
@@ -1,40 +0,0 @@
-===========================
-Samsung GPIO implementation
-===========================
-
-Introduction
-------------
-
-This outlines the Samsung GPIO implementation and the architecture
-specific calls provided alongside the drivers/gpio core.
-
-
-S3C24XX (Legacy)
-----------------
-
-See Documentation/arm/samsung-s3c24xx/gpio.rst for more information
-about these devices. Their implementation has been brought into line
-with the core samsung implementation described in this document.
-
-
-GPIOLIB integration
--------------------
-
-The gpio implementation uses gpiolib as much as possible, only providing
-specific calls for the items that require Samsung specific handling, such
-as pin special-function or pull resistor control.
-
-GPIO numbering is synchronised between the Samsung and gpiolib system.
-
-
-PIN configuration
------------------
-
-Pin configuration is specific to the Samsung architecture, with each SoC
-registering the necessary information for the core gpio configuration
-implementation to configure pins as necessary.
-
-The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
-driver or machine to change gpio configuration.
-
-See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions.
diff --git a/Documentation/arm/samsung/overview.rst b/Documentation/arm/samsung/overview.rst
deleted file mode 100644
index e74307897416..000000000000
--- a/Documentation/arm/samsung/overview.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-==========================
-Samsung ARM Linux Overview
-==========================
-
-Introduction
-------------
-
- The Samsung range of ARM SoCs spans many similar devices, from the initial
- ARM9 through to the newest ARM cores. This document shows an overview of
- the current kernel support, how to use it and where to find the code
- that supports this.
-
- The currently supported SoCs are:
-
- - S3C24XX: See Documentation/arm/samsung-s3c24xx/overview.rst for full list
- - S3C64XX: S3C6400 and S3C6410
- - S5PC110 / S5PV210
-
-
-S3C24XX Systems
----------------
-
- There is still documentation in Documnetation/arm/Samsung-S3C24XX/ which
- deals with the architecture and drivers specific to these devices.
-
- See Documentation/arm/samsung-s3c24xx/overview.rst for more information
- on the implementation details and specific support.
-
-
-Configuration
--------------
-
- A number of configurations are supplied, as there is no current way of
- unifying all the SoCs into one kernel.
-
- s5pc110_defconfig
- - S5PC110 specific default configuration
- s5pv210_defconfig
- - S5PV210 specific default configuration
-
-
-Layout
-------
-
- The directory layout is currently being restructured, and consists of
- several platform directories and then the machine specific directories
- of the CPUs being built for.
-
- plat-samsung provides the base for all the implementations, and is the
- last in the line of include directories that are processed for the build
- specific information. It contains the base clock, GPIO and device definitions
- to get the system running.
-
- plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs.
-
- plat-s5p is for s5p specific builds, and contains common support for the
- S5P specific systems. Not all S5Ps use all the features in this directory
- due to differences in the hardware.
-
-
-Layout changes
---------------
-
- The old plat-s3c and plat-s5pc1xx directories have been removed, with
- support moved to either plat-samsung or plat-s5p as necessary. These moves
- where to simplify the include and dependency issues involved with having
- so many different platform directories.
-
-
-Port Contributors
------------------
-
- Ben Dooks (BJD)
- Vincent Sanders
- Herbert Potzl
- Arnaud Patard (RTP)
- Roc Wu
- Klaus Fetscher
- Dimitry Andric
- Shannon Holland
- Guillaume Gourat (NexVision)
- Christer Weinigel (wingel) (Acer N30)
- Lucas Correia Villa Real (S3C2400 port)
-
-
-Document Author
----------------
-
-Copyright 2009-2010 Ben Dooks <ben-linux@fluff.org>
diff --git a/Documentation/arm/sti/overview.rst b/Documentation/arm/sti/overview.rst
deleted file mode 100644
index 70743617a74f..000000000000
--- a/Documentation/arm/sti/overview.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-======================
-STi ARM Linux Overview
-======================
-
-Introduction
-------------
-
- The ST Microelectronics Multimedia and Application Processors range of
- CortexA9 System-on-Chip are supported by the 'STi' platform of
- ARM Linux. Currently STiH415, STiH416 SOCs are supported with both
- B2000 and B2020 Reference boards.
-
-
-configuration
--------------
-
- A generic configuration is provided for both STiH415/416, and can be used as the
- default by::
-
- make stih41x_defconfig
-
-Layout
-------
-
- All the files for multiple machine families (STiH415, STiH416, and STiG125)
- are located in the platform code contained in arch/arm/mach-sti
-
- There is a generic board board-dt.c in the mach folder which support
- Flattened Device Tree, which means, It works with any compatible board with
- Device Trees.
-
-
-Document Author
----------------
-
- Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics
diff --git a/Documentation/arm/sti/stih415-overview.rst b/Documentation/arm/sti/stih415-overview.rst
deleted file mode 100644
index b67452d610c4..000000000000
--- a/Documentation/arm/sti/stih415-overview.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-================
-STiH415 Overview
-================
-
-Introduction
-------------
-
- The STiH415 is the next generation of HD, AVC set-top box processors
- for satellite, cable, terrestrial and IP-STB markets.
-
- Features:
-
- - ARM Cortex-A9 1.0 GHz, dual-core CPU
- - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2
diff --git a/Documentation/arm/sti/stih416-overview.rst b/Documentation/arm/sti/stih416-overview.rst
deleted file mode 100644
index 93f17d74d8db..000000000000
--- a/Documentation/arm/sti/stih416-overview.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-================
-STiH416 Overview
-================
-
-Introduction
-------------
-
- The STiH416 is the next generation of HD, AVC set-top box processors
- for satellite, cable, terrestrial and IP-STB markets.
-
- Features
- - ARM Cortex-A9 1.2 GHz dual core CPU
- - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2
diff --git a/Documentation/arm/uefi.rst b/Documentation/arm/uefi.rst
deleted file mode 100644
index 9b0b5e458a1e..000000000000
--- a/Documentation/arm/uefi.rst
+++ /dev/null
@@ -1,74 +0,0 @@
-================================================
-The Unified Extensible Firmware Interface (UEFI)
-================================================
-
-UEFI, the Unified Extensible Firmware Interface, is a specification
-governing the behaviours of compatible firmware interfaces. It is
-maintained by the UEFI Forum - http://www.uefi.org/.
-
-UEFI is an evolution of its predecessor 'EFI', so the terms EFI and
-UEFI are used somewhat interchangeably in this document and associated
-source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers
-to legacy code or specifications.
-
-UEFI support in Linux
-=====================
-Booting on a platform with firmware compliant with the UEFI specification
-makes it possible for the kernel to support additional features:
-
-- UEFI Runtime Services
-- Retrieving various configuration information through the standardised
- interface of UEFI configuration tables. (ACPI, SMBIOS, ...)
-
-For actually enabling [U]EFI support, enable:
-
-- CONFIG_EFI=y
-- CONFIG_EFIVAR_FS=y or m
-
-The implementation depends on receiving information about the UEFI environment
-in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF.
-
-UEFI stub
-=========
-The "stub" is a feature that extends the Image/zImage into a valid UEFI
-PE/COFF executable, including a loader application that makes it possible to
-load the kernel directly from the UEFI shell, boot menu, or one of the
-lightweight bootloaders like Gummiboot or rEFInd.
-
-The kernel image built with stub support remains a valid kernel image for
-booting in non-UEFI environments.
-
-UEFI kernel support on ARM
-==========================
-UEFI kernel support on the ARM architectures (arm and arm64) is only available
-when boot is performed through the stub.
-
-When booting in UEFI mode, the stub deletes any memory nodes from a provided DT.
-Instead, the kernel reads the UEFI memory map.
-
-The stub populates the FDT /chosen node with (and the kernel scans for) the
-following parameters:
-
-========================== ====== ===========================================
-Name Size Description
-========================== ====== ===========================================
-linux,uefi-system-table 64-bit Physical address of the UEFI System Table.
-
-linux,uefi-mmap-start 64-bit Physical address of the UEFI memory map,
- populated by the UEFI GetMemoryMap() call.
-
-linux,uefi-mmap-size 32-bit Size in bytes of the UEFI memory map
- pointed to in previous entry.
-
-linux,uefi-mmap-desc-size 32-bit Size in bytes of each entry in the UEFI
- memory map.
-
-linux,uefi-mmap-desc-ver 32-bit Version of the mmap descriptor format.
-
-linux,initrd-start 64-bit Physical start address of an initrd
-
-linux,initrd-end 64-bit Physical end address of an initrd
-
-kaslr-seed 64-bit Entropy used to randomize the kernel image
- base address location.
-========================== ====== ===========================================
diff --git a/Documentation/arm64/amu.rst b/Documentation/arm64/amu.rst
deleted file mode 100644
index 01f2de2b0450..000000000000
--- a/Documentation/arm64/amu.rst
+++ /dev/null
@@ -1,119 +0,0 @@
-.. _amu_index:
-
-=======================================================
-Activity Monitors Unit (AMU) extension in AArch64 Linux
-=======================================================
-
-Author: Ionela Voinescu <ionela.voinescu@arm.com>
-
-Date: 2019-09-10
-
-This document briefly describes the provision of Activity Monitors Unit
-support in AArch64 Linux.
-
-
-Architecture overview
----------------------
-
-The activity monitors extension is an optional extension introduced by the
-ARMv8.4 CPU architecture.
-
-The activity monitors unit, implemented in each CPU, provides performance
-counters intended for system management use. The AMU extension provides a
-system register interface to the counter registers and also supports an
-optional external memory-mapped interface.
-
-Version 1 of the Activity Monitors architecture implements a counter group
-of four fixed and architecturally defined 64-bit event counters.
-
- - CPU cycle counter: increments at the frequency of the CPU.
- - Constant counter: increments at the fixed frequency of the system
- clock.
- - Instructions retired: increments with every architecturally executed
- instruction.
- - Memory stall cycles: counts instruction dispatch stall cycles caused by
- misses in the last level cache within the clock domain.
-
-When in WFI or WFE these counters do not increment.
-
-The Activity Monitors architecture provides space for up to 16 architected
-event counters. Future versions of the architecture may use this space to
-implement additional architected event counters.
-
-Additionally, version 1 implements a counter group of up to 16 auxiliary
-64-bit event counters.
-
-On cold reset all counters reset to 0.
-
-
-Basic support
--------------
-
-The kernel can safely run a mix of CPUs with and without support for the
-activity monitors extension. Therefore, when CONFIG_ARM64_AMU_EXTN is
-selected we unconditionally enable the capability to allow any late CPU
-(secondary or hotplugged) to detect and use the feature.
-
-When the feature is detected on a CPU, we flag the availability of the
-feature but this does not guarantee the correct functionality of the
-counters, only the presence of the extension.
-
-Firmware (code running at higher exception levels, e.g. arm-tf) support is
-needed to:
-
- - Enable access for lower exception levels (EL2 and EL1) to the AMU
- registers.
- - Enable the counters. If not enabled these will read as 0.
- - Save/restore the counters before/after the CPU is being put/brought up
- from the 'off' power state.
-
-When using kernels that have this feature enabled but boot with broken
-firmware the user may experience panics or lockups when accessing the
-counter registers. Even if these symptoms are not observed, the values
-returned by the register reads might not correctly reflect reality. Most
-commonly, the counters will read as 0, indicating that they are not
-enabled.
-
-If proper support is not provided in firmware it's best to disable
-CONFIG_ARM64_AMU_EXTN. To be noted that for security reasons, this does not
-bypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) to
-EL1 (kernel). Therefore, firmware should still ensure accesses to AMU registers
-are not trapped in EL2/EL3.
-
-The fixed counters of AMUv1 are accessible though the following system
-register definitions:
-
- - SYS_AMEVCNTR0_CORE_EL0
- - SYS_AMEVCNTR0_CONST_EL0
- - SYS_AMEVCNTR0_INST_RET_EL0
- - SYS_AMEVCNTR0_MEM_STALL_EL0
-
-Auxiliary platform specific counters can be accessed using
-SYS_AMEVCNTR1_EL0(n), where n is a value between 0 and 15.
-
-Details can be found in: arch/arm64/include/asm/sysreg.h.
-
-
-Userspace access
-----------------
-
-Currently, access from userspace to the AMU registers is disabled due to:
-
- - Security reasons: they might expose information about code executed in
- secure mode.
- - Purpose: AMU counters are intended for system management use.
-
-Also, the presence of the feature is not visible to userspace.
-
-
-Virtualization
---------------
-
-Currently, access from userspace (EL0) and kernelspace (EL1) on the KVM
-guest side is disabled due to:
-
- - Security reasons: they might expose information about code executed
- by other guests or the host.
-
-Any attempt to access the AMU registers will result in an UNDEFINED
-exception being injected into the guest.
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
deleted file mode 100644
index 8aefa1001ae5..000000000000
--- a/Documentation/arm64/booting.rst
+++ /dev/null
@@ -1,412 +0,0 @@
-=====================
-Booting AArch64 Linux
-=====================
-
-Author: Will Deacon <will.deacon@arm.com>
-
-Date : 07 September 2012
-
-This document is based on the ARM booting document by Russell King and
-is relevant to all public releases of the AArch64 Linux kernel.
-
-The AArch64 exception model is made up of a number of exception levels
-(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
-counterpart. EL2 is the hypervisor level, EL3 is the highest priority
-level and exists only in secure mode. Both are architecturally optional.
-
-For the purposes of this document, we will use the term `boot loader`
-simply to define all software that executes on the CPU(s) before control
-is passed to the Linux kernel. This may include secure monitor and
-hypervisor code, or it may just be a handful of instructions for
-preparing a minimal boot environment.
-
-Essentially, the boot loader should provide (as a minimum) the
-following:
-
-1. Setup and initialise the RAM
-2. Setup the device tree
-3. Decompress the kernel image
-4. Call the kernel image
-
-
-1. Setup and initialise RAM
----------------------------
-
-Requirement: MANDATORY
-
-The boot loader is expected to find and initialise all RAM that the
-kernel will use for volatile data storage in the system. It performs
-this in a machine dependent manner. (It may use internal algorithms
-to automatically locate and size all RAM, or it may use knowledge of
-the RAM in the machine, or any other method the boot loader designer
-sees fit.)
-
-
-2. Setup the device tree
--------------------------
-
-Requirement: MANDATORY
-
-The device tree blob (dtb) must be placed on an 8-byte boundary and must
-not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
-using blocks of up to 2 megabytes in size, it must not be placed within
-any 2M region which must be mapped with any specific attributes.
-
-NOTE: versions prior to v4.2 also require that the DTB be placed within
-the 512 MB region starting at text_offset bytes below the kernel Image.
-
-3. Decompress the kernel image
-------------------------------
-
-Requirement: OPTIONAL
-
-The AArch64 kernel does not currently provide a decompressor and
-therefore requires decompression (gzip etc.) to be performed by the boot
-loader if a compressed Image target (e.g. Image.gz) is used. For
-bootloaders that do not implement this requirement, the uncompressed
-Image target is available instead.
-
-
-4. Call the kernel image
-------------------------
-
-Requirement: MANDATORY
-
-The decompressed kernel image contains a 64-byte header as follows::
-
- u32 code0; /* Executable code */
- u32 code1; /* Executable code */
- u64 text_offset; /* Image load offset, little endian */
- u64 image_size; /* Effective Image size, little endian */
- u64 flags; /* kernel flags, little endian */
- u64 res2 = 0; /* reserved */
- u64 res3 = 0; /* reserved */
- u64 res4 = 0; /* reserved */
- u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
- u32 res5; /* reserved (used for PE COFF offset) */
-
-
-Header notes:
-
-- As of v3.17, all fields are little endian unless stated otherwise.
-
-- code0/code1 are responsible for branching to stext.
-
-- when booting through EFI, code0/code1 are initially skipped.
- res5 is an offset to the PE header and the PE header has the EFI
- entry point (efi_stub_entry). When the stub has done its work, it
- jumps to code0 to resume the normal boot process.
-
-- Prior to v3.17, the endianness of text_offset was not specified. In
- these cases image_size is zero and text_offset is 0x80000 in the
- endianness of the kernel. Where image_size is non-zero image_size is
- little-endian and must be respected. Where image_size is zero,
- text_offset can be assumed to be 0x80000.
-
-- The flags field (introduced in v3.17) is a little-endian 64-bit field
- composed as follows:
-
- ============= ===============================================================
- Bit 0 Kernel endianness. 1 if BE, 0 if LE.
- Bit 1-2 Kernel Page size.
-
- * 0 - Unspecified.
- * 1 - 4K
- * 2 - 16K
- * 3 - 64K
- Bit 3 Kernel physical placement
-
- 0
- 2MB aligned base should be as close as possible
- to the base of DRAM, since memory below it is not
- accessible via the linear mapping
- 1
- 2MB aligned base may be anywhere in physical
- memory
- Bits 4-63 Reserved.
- ============= ===============================================================
-
-- When image_size is zero, a bootloader should attempt to keep as much
- memory as possible free for use by the kernel immediately after the
- end of the kernel image. The amount of space required will vary
- depending on selected features, and is effectively unbound.
-
-The Image must be placed text_offset bytes from a 2MB aligned base
-address anywhere in usable system RAM and called there. The region
-between the 2 MB aligned base address and the start of the image has no
-special significance to the kernel, and may be used for other purposes.
-At least image_size bytes from the start of the image must be free for
-use by the kernel.
-NOTE: versions prior to v4.6 cannot make use of memory below the
-physical offset of the Image so it is recommended that the Image be
-placed as close as possible to the start of system RAM.
-
-If an initrd/initramfs is passed to the kernel at boot, it must reside
-entirely within a 1 GB aligned physical memory window of up to 32 GB in
-size that fully covers the kernel Image as well.
-
-Any memory described to the kernel (even that below the start of the
-image) which is not marked as reserved from the kernel (e.g., with a
-memreserve region in the device tree) will be considered as available to
-the kernel.
-
-Before jumping into the kernel, the following conditions must be met:
-
-- Quiesce all DMA capable devices so that memory does not get
- corrupted by bogus network packets or disk data. This will save
- you many hours of debug.
-
-- Primary CPU general-purpose register settings:
-
- - x0 = physical address of device tree blob (dtb) in system RAM.
- - x1 = 0 (reserved for future use)
- - x2 = 0 (reserved for future use)
- - x3 = 0 (reserved for future use)
-
-- CPU mode
-
- All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
- IRQ and FIQ).
- The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order
- to have access to the virtualisation extensions), or in EL1.
-
-- Caches, MMUs
-
- The MMU must be off.
-
- The instruction cache may be on or off, and must not hold any stale
- entries corresponding to the loaded kernel image.
-
- The address range corresponding to the loaded kernel image must be
- cleaned to the PoC. In the presence of a system cache or other
- coherent masters with caches enabled, this will typically require
- cache maintenance by VA rather than set/way operations.
- System caches which respect the architected cache maintenance by VA
- operations must be configured and may be enabled.
- System caches which do not respect architected cache maintenance by VA
- operations (not recommended) must be configured and disabled.
-
-- Architected timers
-
- CNTFRQ must be programmed with the timer frequency and CNTVOFF must
- be programmed with a consistent value on all CPUs. If entering the
- kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
- available.
-
-- Coherency
-
- All CPUs to be booted by the kernel must be part of the same coherency
- domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
- initialisation to enable the receiving of maintenance operations on
- each CPU.
-
-- System registers
-
- All writable architected system registers at or below the exception
- level where the kernel image will be entered must be initialised by
- software at a higher exception level to prevent execution in an UNKNOWN
- state.
-
- For all systems:
- - If EL3 is present:
-
- - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
- executing on.
- - The value of SCR_EL3.FIQ must be the same as the one present at boot
- time whenever the kernel is executing.
-
- - If EL3 is present and the kernel is entered at EL2:
-
- - SCR_EL3.HCE (bit 8) must be initialised to 0b1.
-
- For systems with a GICv3 interrupt controller to be used in v3 mode:
- - If EL3 is present:
-
- - ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
- - ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
- all CPUs the kernel is executing on, and must stay constant
- for the lifetime of the kernel.
-
- - If the kernel is entered at EL1:
-
- - ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
- - ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
-
- - The DT or ACPI tables must describe a GICv3 interrupt controller.
-
- For systems with a GICv3 interrupt controller to be used in
- compatibility (v2) mode:
-
- - If EL3 is present:
-
- ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
-
- - If the kernel is entered at EL1:
-
- ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
-
- - The DT or ACPI tables must describe a GICv2 interrupt controller.
-
- For CPUs with pointer authentication functionality:
-
- - If EL3 is present:
-
- - SCR_EL3.APK (bit 16) must be initialised to 0b1
- - SCR_EL3.API (bit 17) must be initialised to 0b1
-
- - If the kernel is entered at EL1:
-
- - HCR_EL2.APK (bit 40) must be initialised to 0b1
- - HCR_EL2.API (bit 41) must be initialised to 0b1
-
- For CPUs with Activity Monitors Unit v1 (AMUv1) extension present:
-
- - If EL3 is present:
-
- - CPTR_EL3.TAM (bit 30) must be initialised to 0b0
- - CPTR_EL2.TAM (bit 30) must be initialised to 0b0
- - AMCNTENSET0_EL0 must be initialised to 0b1111
- - AMCNTENSET1_EL0 must be initialised to a platform specific value
- having 0b1 set for the corresponding bit for each of the auxiliary
- counters present.
-
- - If the kernel is entered at EL1:
-
- - AMCNTENSET0_EL0 must be initialised to 0b1111
- - AMCNTENSET1_EL0 must be initialised to a platform specific value
- having 0b1 set for the corresponding bit for each of the auxiliary
- counters present.
-
- For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
-
- - If EL3 is present and the kernel is entered at EL2:
-
- - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
-
- For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
-
- - If EL3 is present and the kernel is entered at EL2:
-
- - SCR_EL3.HXEn (bit 38) must be initialised to 0b1.
-
- For CPUs with Advanced SIMD and floating point support:
-
- - If EL3 is present:
-
- - CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
-
- - If EL2 is present and the kernel is entered at EL1:
-
- - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
-
- For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
-
- - if EL3 is present:
-
- - CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
-
- - ZCR_EL3.LEN must be initialised to the same value for all CPUs the
- kernel is executed on.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
-
- - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
-
- - ZCR_EL2.LEN must be initialised to the same value for all CPUs the
- kernel will execute on.
-
- For CPUs with the Scalable Matrix Extension (FEAT_SME):
-
- - If EL3 is present:
-
- - CPTR_EL3.ESM (bit 12) must be initialised to 0b1.
-
- - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1.
-
- - SMCR_EL3.LEN must be initialised to the same value for all CPUs the
- kernel will execute on.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - CPTR_EL2.TSM (bit 12) must be initialised to 0b0.
-
- - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11.
-
- - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1.
-
- - SMCR_EL2.LEN must be initialised to the same value for all CPUs the
- kernel will execute on.
-
- For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64)
-
- - If EL3 is present:
-
- - SMCR_EL3.FA64 (bit 31) must be initialised to 0b1.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - SMCR_EL2.FA64 (bit 31) must be initialised to 0b1.
-
- For CPUs with the Memory Tagging Extension feature (FEAT_MTE2):
-
- - If EL3 is present:
-
- - SCR_EL3.ATA (bit 26) must be initialised to 0b1.
-
- - If the kernel is entered at EL1 and EL2 is present:
-
- - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
-
-The requirements described above for CPU mode, caches, MMUs, architected
-timers, coherency and system registers apply to all CPUs. All CPUs must
-enter the kernel in the same exception level. Where the values documented
-disable traps it is permissible for these traps to be enabled so long as
-those traps are handled transparently by higher exception levels as though
-the values documented were set.
-
-The boot loader is expected to enter the kernel on each CPU in the
-following manner:
-
-- The primary CPU must jump directly to the first instruction of the
- kernel image. The device tree blob passed by this CPU must contain
- an 'enable-method' property for each cpu node. The supported
- enable-methods are described below.
-
- It is expected that the bootloader will generate these device tree
- properties and insert them into the blob prior to kernel entry.
-
-- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
- property in their cpu node. This property identifies a
- naturally-aligned 64-bit zero-initalised memory location.
-
- These CPUs should spin outside of the kernel in a reserved area of
- memory (communicated to the kernel by a /memreserve/ region in the
- device tree) polling their cpu-release-addr location, which must be
- contained in the reserved region. A wfe instruction may be inserted
- to reduce the overhead of the busy-loop and a sev will be issued by
- the primary CPU. When a read of the location pointed to by the
- cpu-release-addr returns a non-zero value, the CPU must jump to this
- value. The value will be written as a single 64-bit little-endian
- value, so CPUs must convert the read value to their native endianness
- before jumping to it.
-
-- CPUs with a "psci" enable method should remain outside of
- the kernel (i.e. outside of the regions of memory described to the
- kernel in the memory node, or in a reserved area of memory described
- to the kernel by a /memreserve/ region in the device tree). The
- kernel will issue CPU_ON calls as described in ARM document number ARM
- DEN 0022A ("Power State Coordination Interface System Software on ARM
- processors") to bring CPUs into the kernel.
-
- The device tree should contain a 'psci' node, as described in
- Documentation/devicetree/bindings/arm/psci.yaml.
-
-- Secondary CPU general-purpose register settings
-
- - x0 = 0 (reserved for future use)
- - x1 = 0 (reserved for future use)
- - x2 = 0 (reserved for future use)
- - x3 = 0 (reserved for future use)
diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
deleted file mode 100644
index bb34287c8e01..000000000000
--- a/Documentation/arm64/elf_hwcaps.rst
+++ /dev/null
@@ -1,282 +0,0 @@
-.. _elf_hwcaps_index:
-
-================
-ARM64 ELF hwcaps
-================
-
-This document describes the usage and semantics of the arm64 ELF hwcaps.
-
-
-1. Introduction
----------------
-
-Some hardware or software features are only available on some CPU
-implementations, and/or with certain kernel configurations, but have no
-architected discovery mechanism available to userspace code at EL0. The
-kernel exposes the presence of these features to userspace through a set
-of flags called hwcaps, exposed in the auxilliary vector.
-
-Userspace software can test for features by acquiring the AT_HWCAP or
-AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
-flags are set, e.g.::
-
- bool floating_point_is_present(void)
- {
- unsigned long hwcaps = getauxval(AT_HWCAP);
- if (hwcaps & HWCAP_FP)
- return true;
-
- return false;
- }
-
-Where software relies on a feature described by a hwcap, it should check
-the relevant hwcap flag to verify that the feature is present before
-attempting to make use of the feature.
-
-Features cannot be probed reliably through other means. When a feature
-is not available, attempting to use it may result in unpredictable
-behaviour, and is not guaranteed to result in any reliable indication
-that the feature is unavailable, such as a SIGILL.
-
-
-2. Interpretation of hwcaps
----------------------------
-
-The majority of hwcaps are intended to indicate the presence of features
-which are described by architected ID registers inaccessible to
-userspace code at EL0. These hwcaps are defined in terms of ID register
-fields, and should be interpreted with reference to the definition of
-these fields in the ARM Architecture Reference Manual (ARM ARM).
-
-Such hwcaps are described below in the form::
-
- Functionality implied by idreg.field == val.
-
-Such hwcaps indicate the availability of functionality that the ARM ARM
-defines as being present when idreg.field has value val, but do not
-indicate that idreg.field is precisely equal to val, nor do they
-indicate the absence of functionality implied by other values of
-idreg.field.
-
-Other hwcaps may indicate the presence of features which cannot be
-described by ID registers alone. These may be described without
-reference to ID registers, and may refer to other documentation.
-
-
-3. The hwcaps exposed in AT_HWCAP
----------------------------------
-
-HWCAP_FP
- Functionality implied by ID_AA64PFR0_EL1.FP == 0b0000.
-
-HWCAP_ASIMD
- Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0000.
-
-HWCAP_EVTSTRM
- The generic timer is configured to generate events at a frequency of
- approximately 10KHz.
-
-HWCAP_AES
- Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001.
-
-HWCAP_PMULL
- Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0010.
-
-HWCAP_SHA1
- Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
-
-HWCAP_SHA2
- Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
-
-HWCAP_CRC32
- Functionality implied by ID_AA64ISAR0_EL1.CRC32 == 0b0001.
-
-HWCAP_ATOMICS
- Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0010.
-
-HWCAP_FPHP
- Functionality implied by ID_AA64PFR0_EL1.FP == 0b0001.
-
-HWCAP_ASIMDHP
- Functionality implied by ID_AA64PFR0_EL1.AdvSIMD == 0b0001.
-
-HWCAP_CPUID
- EL0 access to certain ID registers is available, to the extent
- described by Documentation/arm64/cpu-feature-registers.rst.
-
- These ID registers may imply the availability of features.
-
-HWCAP_ASIMDRDM
- Functionality implied by ID_AA64ISAR0_EL1.RDM == 0b0001.
-
-HWCAP_JSCVT
- Functionality implied by ID_AA64ISAR1_EL1.JSCVT == 0b0001.
-
-HWCAP_FCMA
- Functionality implied by ID_AA64ISAR1_EL1.FCMA == 0b0001.
-
-HWCAP_LRCPC
- Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0001.
-
-HWCAP_DCPOP
- Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0001.
-
-HWCAP_SHA3
- Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
-
-HWCAP_SM3
- Functionality implied by ID_AA64ISAR0_EL1.SM3 == 0b0001.
-
-HWCAP_SM4
- Functionality implied by ID_AA64ISAR0_EL1.SM4 == 0b0001.
-
-HWCAP_ASIMDDP
- Functionality implied by ID_AA64ISAR0_EL1.DP == 0b0001.
-
-HWCAP_SHA512
- Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.
-
-HWCAP_SVE
- Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
-
-HWCAP_ASIMDFHM
- Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
-
-HWCAP_DIT
- Functionality implied by ID_AA64PFR0_EL1.DIT == 0b0001.
-
-HWCAP_USCAT
- Functionality implied by ID_AA64MMFR2_EL1.AT == 0b0001.
-
-HWCAP_ILRCPC
- Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0010.
-
-HWCAP_FLAGM
- Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0001.
-
-HWCAP_SSBS
- Functionality implied by ID_AA64PFR1_EL1.SSBS == 0b0010.
-
-HWCAP_SB
- Functionality implied by ID_AA64ISAR1_EL1.SB == 0b0001.
-
-HWCAP_PACA
- Functionality implied by ID_AA64ISAR1_EL1.APA == 0b0001 or
- ID_AA64ISAR1_EL1.API == 0b0001, as described by
- Documentation/arm64/pointer-authentication.rst.
-
-HWCAP_PACG
- Functionality implied by ID_AA64ISAR1_EL1.GPA == 0b0001 or
- ID_AA64ISAR1_EL1.GPI == 0b0001, as described by
- Documentation/arm64/pointer-authentication.rst.
-
-HWCAP2_DCPODP
- Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
-
-HWCAP2_SVE2
- Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
-
-HWCAP2_SVEAES
- Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
-
-HWCAP2_SVEPMULL
- Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
-
-HWCAP2_SVEBITPERM
- Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
-
-HWCAP2_SVESHA3
- Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
-
-HWCAP2_SVESM4
- Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
-
-HWCAP2_FLAGM2
- Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
-
-HWCAP2_FRINT
- Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
-
-HWCAP2_SVEI8MM
- Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
-
-HWCAP2_SVEF32MM
- Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
-
-HWCAP2_SVEF64MM
- Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
-
-HWCAP2_SVEBF16
- Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
-
-HWCAP2_I8MM
- Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
-
-HWCAP2_BF16
- Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
-
-HWCAP2_DGH
- Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
-
-HWCAP2_RNG
- Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
-
-HWCAP2_BTI
- Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
-
-HWCAP2_MTE
- Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
- by Documentation/arm64/memory-tagging-extension.rst.
-
-HWCAP2_ECV
- Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
-
-HWCAP2_AFP
- Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
-
-HWCAP2_RPRES
- Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
-
-HWCAP2_MTE3
- Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
- by Documentation/arm64/memory-tagging-extension.rst.
-
-HWCAP2_SME
- Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
- by Documentation/arm64/sme.rst.
-
-HWCAP2_SME_I16I64
- Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
-
-HWCAP2_SME_F64F64
- Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
-
-HWCAP2_SME_I8I32
- Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
-
-HWCAP2_SME_F16F32
- Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
-
-HWCAP2_SME_B16F32
- Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
-
-HWCAP2_SME_F32F32
- Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
-
-HWCAP2_SME_FA64
- Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
-
-HWCAP2_WFXT
- Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
-
-HWCAP2_EBF16
- Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
-
-HWCAP2_SVE_EBF16
- Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0010.
-
-4. Unused AT_HWCAP bits
------------------------
-
-For interoperation with userspace, the kernel guarantees that bits 62
-and 63 of AT_HWCAP will always be returned as 0.
diff --git a/Documentation/arm64/features.rst b/Documentation/arm64/features.rst
deleted file mode 100644
index dfa4cb3cd3ef..000000000000
--- a/Documentation/arm64/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features arm64
diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst
deleted file mode 100644
index ae21f8118830..000000000000
--- a/Documentation/arm64/index.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-.. _arm64_index:
-
-==================
-ARM64 Architecture
-==================
-
-.. toctree::
- :maxdepth: 1
-
- acpi_object_usage
- amu
- arm-acpi
- asymmetric-32bit
- booting
- cpu-feature-registers
- elf_hwcaps
- hugetlbpage
- legacy_instructions
- memory
- memory-tagging-extension
- perf
- pointer-authentication
- silicon-errata
- sme
- sve
- tagged-address-abi
- tagged-pointers
-
- features
-
-.. only:: subproject and html
-
- Indices
- =======
-
- * :ref:`genindex`
diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
deleted file mode 100644
index 2a641ba7be3b..000000000000
--- a/Documentation/arm64/memory.rst
+++ /dev/null
@@ -1,167 +0,0 @@
-==============================
-Memory Layout on AArch64 Linux
-==============================
-
-Author: Catalin Marinas <catalin.marinas@arm.com>
-
-This document describes the virtual memory layout used by the AArch64
-Linux kernel. The architecture allows up to 4 levels of translation
-tables with a 4KB page size and up to 3 levels with a 64KB page size.
-
-AArch64 Linux uses either 3 levels or 4 levels of translation tables
-with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
-(256TB) virtual addresses, respectively, for both user and kernel. With
-64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
-virtual address, are used but the memory layout is the same.
-
-ARMv8.2 adds optional support for Large Virtual Address space. This is
-only available when running with a 64KB page size and expands the
-number of descriptors in the first level of translation.
-
-User addresses have bits 63:48 set to 0 while the kernel addresses have
-the same bits set to 1. TTBRx selection is given by bit 63 of the
-virtual address. The swapper_pg_dir contains only kernel (global)
-mappings while the user pgd contains only user (non-global) mappings.
-The swapper_pg_dir address is written to TTBR1 and never written to
-TTBR0.
-
-
-AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
-
- Start End Size Use
- -----------------------------------------------------------------------
- 0000000000000000 0000ffffffffffff 256TB user
- ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
- [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
- ffff800000000000 ffff800007ffffff 128MB modules
- ffff800008000000 fffffbffefffffff 124TB vmalloc
- fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
- fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
- fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
- fffffbffff800000 fffffbffffffffff 8MB [guard region]
- fffffc0000000000 fffffdffffffffff 2TB vmemmap
- fffffe0000000000 ffffffffffffffff 2TB [guard region]
-
-
-AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
-
- Start End Size Use
- -----------------------------------------------------------------------
- 0000000000000000 000fffffffffffff 4PB user
- fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
- [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
- ffff800000000000 ffff800007ffffff 128MB modules
- ffff800008000000 fffffbffefffffff 124TB vmalloc
- fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
- fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
- fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
- fffffbffff800000 fffffbffffffffff 8MB [guard region]
- fffffc0000000000 ffffffdfffffffff ~4TB vmemmap
- ffffffe000000000 ffffffffffffffff 128GB [guard region]
-
-
-Translation table lookup with 4KB pages::
-
- +--------+--------+--------+--------+--------+--------+--------+--------+
- |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
- +--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | | |
- | | | | | v
- | | | | | [11:0] in-page offset
- | | | | +-> [20:12] L3 index
- | | | +-----------> [29:21] L2 index
- | | +---------------------> [38:30] L1 index
- | +-------------------------------> [47:39] L0 index
- +-------------------------------------------------> [63] TTBR0/1
-
-
-Translation table lookup with 64KB pages::
-
- +--------+--------+--------+--------+--------+--------+--------+--------+
- |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
- +--------+--------+--------+--------+--------+--------+--------+--------+
- | | | | |
- | | | | v
- | | | | [15:0] in-page offset
- | | | +----------> [28:16] L3 index
- | | +--------------------------> [41:29] L2 index
- | +-------------------------------> [47:42] L1 index (48-bit)
- | [51:42] L1 index (52-bit)
- +-------------------------------------------------> [63] TTBR0/1
-
-
-When using KVM without the Virtualization Host Extensions, the
-hypervisor maps kernel pages in EL2 at a fixed (and potentially
-random) offset from the linear mapping. See the kern_hyp_va macro and
-kvm_update_va_mask function for more details. MMIO devices such as
-GICv2 gets mapped next to the HYP idmap page, as do vectors when
-ARM64_SPECTRE_V3A is enabled for particular CPUs.
-
-When using KVM with the Virtualization Host Extensions, no additional
-mappings are created, since the host kernel runs directly in EL2.
-
-52-bit VA support in the kernel
--------------------------------
-If the ARMv8.2-LVA optional feature is present, and we are running
-with a 64KB page size; then it is possible to use 52-bits of address
-space for both userspace and kernel addresses. However, any kernel
-binary that supports 52-bit must also be able to fall back to 48-bit
-at early boot time if the hardware feature is not present.
-
-This fallback mechanism necessitates the kernel .text to be in the
-higher addresses such that they are invariant to 48/52-bit VAs. Due
-to the kasan shadow being a fraction of the entire kernel VA space,
-the end of the kasan shadow must also be in the higher half of the
-kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
-the end of the kasan shadow is invariant and dependent on ~0UL,
-whilst the start address will "grow" towards the lower addresses).
-
-In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
-is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
-this obviates the need for an extra variable read. The physvirt
-offset and vmemmap offsets are computed at early boot to enable
-this logic.
-
-As a single binary will need to support both 48-bit and 52-bit VA
-spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
-also must be sized large enough to accommodate a fixed PAGE_OFFSET.
-
-Most code in the kernel should not need to consider the VA_BITS, for
-code that does need to know the VA size the variables are
-defined as follows:
-
-VA_BITS constant the *maximum* VA space size
-
-VA_BITS_MIN constant the *minimum* VA space size
-
-vabits_actual variable the *actual* VA space size
-
-
-Maximum and minimum sizes can be useful to ensure that buffers are
-sized large enough or that addresses are positioned close enough for
-the "worst" case.
-
-52-bit userspace VAs
---------------------
-To maintain compatibility with software that relies on the ARMv8.0
-VA space maximum size of 48-bits, the kernel will, by default,
-return virtual addresses to userspace from a 48-bit range.
-
-Software can "opt-in" to receiving VAs from a 52-bit space by
-specifying an mmap hint parameter that is larger than 48-bit.
-
-For example:
-
-.. code-block:: c
-
- maybe_high_address = mmap(~0UL, size, prot, flags,...);
-
-It is also possible to build a debug kernel that returns addresses
-from a 52-bit space by enabling the following kernel config options:
-
-.. code-block:: sh
-
- CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
-
-Note that this option is only intended for debugging applications
-and should not be used in production.
diff --git a/Documentation/arm64/perf.rst b/Documentation/arm64/perf.rst
deleted file mode 100644
index 1f87b57c2332..000000000000
--- a/Documentation/arm64/perf.rst
+++ /dev/null
@@ -1,166 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. _perf_index:
-
-====
-Perf
-====
-
-Perf Event Attributes
-=====================
-
-:Author: Andrew Murray <andrew.murray@arm.com>
-:Date: 2019-03-06
-
-exclude_user
-------------
-
-This attribute excludes userspace.
-
-Userspace always runs at EL0 and thus this attribute will exclude EL0.
-
-
-exclude_kernel
---------------
-
-This attribute excludes the kernel.
-
-The kernel runs at EL2 with VHE and EL1 without. Guest kernels always run
-at EL1.
-
-For the host this attribute will exclude EL1 and additionally EL2 on a VHE
-system.
-
-For the guest this attribute will exclude EL1. Please note that EL2 is
-never counted within a guest.
-
-
-exclude_hv
-----------
-
-This attribute excludes the hypervisor.
-
-For a VHE host this attribute is ignored as we consider the host kernel to
-be the hypervisor.
-
-For a non-VHE host this attribute will exclude EL2 as we consider the
-hypervisor to be any code that runs at EL2 which is predominantly used for
-guest/host transitions.
-
-For the guest this attribute has no effect. Please note that EL2 is
-never counted within a guest.
-
-
-exclude_host / exclude_guest
-----------------------------
-
-These attributes exclude the KVM host and guest, respectively.
-
-The KVM host may run at EL0 (userspace), EL1 (non-VHE kernel) and EL2 (VHE
-kernel or non-VHE hypervisor).
-
-The KVM guest may run at EL0 (userspace) and EL1 (kernel).
-
-Due to the overlapping exception levels between host and guests we cannot
-exclusively rely on the PMU's hardware exception filtering - therefore we
-must enable/disable counting on the entry and exit to the guest. This is
-performed differently on VHE and non-VHE systems.
-
-For non-VHE systems we exclude EL2 for exclude_host - upon entering and
-exiting the guest we disable/enable the event as appropriate based on the
-exclude_host and exclude_guest attributes.
-
-For VHE systems we exclude EL1 for exclude_guest and exclude both EL0,EL2
-for exclude_host. Upon entering and exiting the guest we modify the event
-to include/exclude EL0 as appropriate based on the exclude_host and
-exclude_guest attributes.
-
-The statements above also apply when these attributes are used within a
-non-VHE guest however please note that EL2 is never counted within a guest.
-
-
-Accuracy
---------
-
-On non-VHE hosts we enable/disable counters on the entry/exit of host/guest
-transition at EL2 - however there is a period of time between
-enabling/disabling the counters and entering/exiting the guest. We are
-able to eliminate counters counting host events on the boundaries of guest
-entry/exit when counting guest events by filtering out EL2 for
-exclude_host. However when using !exclude_hv there is a small blackout
-window at the guest entry/exit where host events are not captured.
-
-On VHE systems there are no blackout windows.
-
-Perf Userspace PMU Hardware Counter Access
-==========================================
-
-Overview
---------
-The perf userspace tool relies on the PMU to monitor events. It offers an
-abstraction layer over the hardware counters since the underlying
-implementation is cpu-dependent.
-Arm64 allows userspace tools to have access to the registers storing the
-hardware counters' values directly.
-
-This targets specifically self-monitoring tasks in order to reduce the overhead
-by directly accessing the registers without having to go through the kernel.
-
-How-to
-------
-The focus is set on the armv8 PMUv3 which makes sure that the access to the pmu
-registers is enabled and that the userspace has access to the relevant
-information in order to use them.
-
-In order to have access to the hardware counters, the global sysctl
-kernel/perf_user_access must first be enabled:
-
-.. code-block:: sh
-
- echo 1 > /proc/sys/kernel/perf_user_access
-
-It is necessary to open the event using the perf tool interface with config1:1
-attr bit set: the sys_perf_event_open syscall returns a fd which can
-subsequently be used with the mmap syscall in order to retrieve a page of memory
-containing information about the event. The PMU driver uses this page to expose
-to the user the hardware counter's index and other necessary data. Using this
-index enables the user to access the PMU registers using the `mrs` instruction.
-Access to the PMU registers is only valid while the sequence lock is unchanged.
-In particular, the PMSELR_EL0 register is zeroed each time the sequence lock is
-changed.
-
-The userspace access is supported in libperf using the perf_evsel__mmap()
-and perf_evsel__read() functions. See `tools/lib/perf/tests/test-evsel.c`_ for
-an example.
-
-About heterogeneous systems
----------------------------
-On heterogeneous systems such as big.LITTLE, userspace PMU counter access can
-only be enabled when the tasks are pinned to a homogeneous subset of cores and
-the corresponding PMU instance is opened by specifying the 'type' attribute.
-The use of generic event types is not supported in this case.
-
-Have a look at `tools/perf/arch/arm64/tests/user-events.c`_ for an example. It
-can be run using the perf tool to check that the access to the registers works
-correctly from userspace:
-
-.. code-block:: sh
-
- perf test -v user
-
-About chained events and counter sizes
---------------------------------------
-The user can request either a 32-bit (config1:0 == 0) or 64-bit (config1:0 == 1)
-counter along with userspace access. The sys_perf_event_open syscall will fail
-if a 64-bit counter is requested and the hardware doesn't support 64-bit
-counters. Chained events are not supported in conjunction with userspace counter
-access. If a 32-bit counter is requested on hardware with 64-bit counters, then
-userspace must treat the upper 32-bits read from the counter as UNKNOWN. The
-'pmc_width' field in the user page will indicate the valid width of the counter
-and should be used to mask the upper bits as needed.
-
-.. Links
-.. _tools/perf/arch/arm64/tests/user-events.c:
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm64/tests/user-events.c
-.. _tools/lib/perf/tests/test-evsel.c:
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/tests/test-evsel.c
diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
deleted file mode 100644
index 17d9fc5d14fb..000000000000
--- a/Documentation/arm64/silicon-errata.rst
+++ /dev/null
@@ -1,207 +0,0 @@
-=======================================
-Silicon Errata and Software Workarounds
-=======================================
-
-Author: Will Deacon <will.deacon@arm.com>
-
-Date : 27 November 2015
-
-It is an unfortunate fact of life that hardware is often produced with
-so-called "errata", which can cause it to deviate from the architecture
-under specific circumstances. For hardware produced by ARM, these
-errata are broadly classified into the following categories:
-
- ========== ========================================================
- Category A A critical error without a viable workaround.
- Category B A significant or critical error with an acceptable
- workaround.
- Category C A minor error that is not expected to occur under normal
- operation.
- ========== ========================================================
-
-For more information, consult one of the "Software Developers Errata
-Notice" documents available on infocenter.arm.com (registration
-required).
-
-As far as Linux is concerned, Category B errata may require some special
-treatment in the operating system. For example, avoiding a particular
-sequence of code, or configuring the processor in a particular way. A
-less common situation may require similar actions in order to declassify
-a Category A erratum into a Category C erratum. These are collectively
-known as "software workarounds" and are only required in the minority of
-cases (e.g. those cases that both require a non-secure workaround *and*
-can be triggered by Linux).
-
-For software workarounds that may adversely impact systems unaffected by
-the erratum in question, a Kconfig entry is added under "Kernel
-Features" -> "ARM errata workarounds via the alternatives framework".
-These are enabled by default and patched in at runtime when an affected
-CPU is detected. For less-intrusive workarounds, a Kconfig option is not
-available and the code is structured (preferably with a comment) in such
-a way that the erratum will not be hit.
-
-This approach can make it slightly onerous to determine exactly which
-errata are worked around in an arbitrary kernel source tree, so this
-file acts as a registry of software workarounds in the Linux Kernel and
-will be updated when new workarounds are committed and backported to
-stable kernels.
-
-+----------------+-----------------+-----------------+-----------------------------+
-| Implementor | Component | Erratum ID | Kconfig |
-+================+=================+=================+=============================+
-| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A55 | #1530923 | ARM64_ERRATUM_1530923 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #852523 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A72 | #853709 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1349291 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
-+----------------+-----------------+-----------------+-----------------------------+
-| ARM | MMU-500 | #841119,826419 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX GICv3 | #38539 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX SMMUv2 | #27704 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 SMMUv3| #74 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 SMMUv3| #126 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Marvell | ARM-MMU-500 | #582743 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{6,7} | #161010701 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip0{6,7} | #161010803 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
-+----------------+-----------------+-----------------+-----------------------------+
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo/Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
-+----------------+-----------------+-----------------+-----------------------------+
-| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
-+----------------+-----------------+-----------------+-----------------------------+
-
-+----------------+-----------------+-----------------+-----------------------------+
-| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
-+----------------+-----------------+-----------------+-----------------------------+
diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
index 0f1ffa03db09..bee3b1bca9a7 100644
--- a/Documentation/atomic_t.txt
+++ b/Documentation/atomic_t.txt
@@ -171,14 +171,14 @@ The rule of thumb:
- RMW operations that are conditional are unordered on FAILURE,
otherwise the above rules apply.
-Except of course when an operation has an explicit ordering like:
+Except of course when a successful operation has an explicit ordering like:
{}_relaxed: unordered
{}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
{}_release: the W of the RMW (or atomic_set) is a RELEASE
Where 'unordered' is against other memory locations. Address dependencies are
-not defeated.
+not defeated. Conditional operations are still unordered on FAILURE.
Fully ordered primitives are ordered against everything prior and everything
subsequent. Therefore a fully ordered primitive is like having an smp_mb()
@@ -324,7 +324,7 @@ atomic operations.
Specifically 'simple' cmpxchg() loops are expected to not starve one another
indefinitely. However, this is not evident on LL/SC architectures, because
-while an LL/SC architecure 'can/should/must' provide forward progress
+while an LL/SC architecture 'can/should/must' provide forward progress
guarantees between competing LL/SC sections, such a guarantee does not
transfer to cmpxchg() implemented using LL/SC. Consider:
diff --git a/Documentation/block/bfq-iosched.rst b/Documentation/block/bfq-iosched.rst
index df3a8a47f58c..a0ff0eb11e7f 100644
--- a/Documentation/block/bfq-iosched.rst
+++ b/Documentation/block/bfq-iosched.rst
@@ -9,7 +9,7 @@ controllers), BFQ's main features are:
- BFQ guarantees a high system and application responsiveness, and a
low latency for time-sensitive applications, such as audio or video
players;
-- BFQ distributes bandwidth, and not just time, among processes or
+- BFQ distributes bandwidth, not just time, among processes or
groups (switching back to time distribution when needed to keep
throughput high).
@@ -111,7 +111,7 @@ Higher speed for code-development tasks
If some additional workload happens to be executed in parallel, then
BFQ executes the I/O-related components of typical code-development
-tasks (compilation, checkout, merge, ...) much more quickly than CFQ,
+tasks (compilation, checkout, merge, etc.) much more quickly than CFQ,
NOOP or DEADLINE.
High throughput
@@ -127,9 +127,9 @@ Strong fairness, bandwidth and delay guarantees
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
BFQ distributes the device throughput, and not just the device time,
-among I/O-bound applications in proportion their weights, with any
+among I/O-bound applications in proportion to their weights, with any
workload and regardless of the device parameters. From these bandwidth
-guarantees, it is possible to compute tight per-I/O-request delay
+guarantees, it is possible to compute a tight per-I/O-request delay
guarantees by a simple formula. If not configured for strict service
guarantees, BFQ switches to time-based resource sharing (only) for
applications that would otherwise cause a throughput loss.
@@ -199,7 +199,7 @@ plus a lot of code, are borrowed from CFQ.
- On flash-based storage with internal queueing of commands
(typically NCQ), device idling happens to be always detrimental
- for throughput. So, with these devices, BFQ performs idling
+ to throughput. So, with these devices, BFQ performs idling
only when strictly needed for service guarantees, i.e., for
guaranteeing low latency or fairness. In these cases, overall
throughput may be sub-optimal. No solution currently exists to
@@ -212,7 +212,7 @@ plus a lot of code, are borrowed from CFQ.
and to reduce their latency. The most important action taken to
achieve this goal is to give to the queues associated with these
applications more than their fair share of the device
- throughput. For brevity, we call just "weight-raising" the whole
+ throughput. For brevity, we call it just "weight-raising" the whole
sets of actions taken by BFQ to privilege these queues. In
particular, BFQ provides a milder form of weight-raising for
interactive applications, and a stronger form for soft real-time
@@ -231,7 +231,7 @@ plus a lot of code, are borrowed from CFQ.
responsive in detecting interleaved I/O (cooperating processes),
that it enables BFQ to achieve a high throughput, by queue
merging, even for queues for which CFQ needs a different
- mechanism, preemption, to get a high throughput. As such EQM is a
+ mechanism, preemption, to get a high throughput. As such, EQM is a
unified mechanism to achieve a high throughput with interleaved
I/O.
@@ -254,7 +254,7 @@ plus a lot of code, are borrowed from CFQ.
- First, with any proportional-share scheduler, the maximum
deviation with respect to an ideal service is proportional to
the maximum budget (slice) assigned to queues. As a consequence,
- BFQ can keep this deviation tight not only because of the
+ BFQ can keep this deviation tight, not only because of the
accurate service of B-WF2Q+, but also because BFQ *does not*
need to assign a larger budget to a queue to let the queue
receive a higher fraction of the device throughput.
@@ -327,7 +327,7 @@ applications. Unset this tunable if you need/want to control weights.
slice_idle
----------
-This parameter specifies how long BFQ should idle for next I/O
+This parameter specifies how long BFQ should idle for the next I/O
request, when certain sync BFQ queues become empty. By default
slice_idle is a non-zero value. Idling has a double purpose: boosting
throughput and making sure that the desired throughput distribution is
@@ -365,7 +365,7 @@ terms of I/O-request dispatches. To guarantee that the actual service
order then corresponds to the dispatch order, the strict_guarantees
tunable must be set too.
-There is an important flipside for idling: apart from the above cases
+There is an important flip side to idling: apart from the above cases
where it is beneficial also for throughput, idling can severely impact
throughput. One important case is random workload. Because of this
issue, BFQ tends to avoid idling as much as possible, when it is not
@@ -475,7 +475,7 @@ max_budget
Maximum amount of service, measured in sectors, that can be provided
to a BFQ queue once it is set in service (of course within the limits
-of the above timeout). According to what said in the description of
+of the above timeout). According to what was said in the description of
the algorithm, larger values increase the throughput in proportion to
the percentage of sequential I/O requests issued. The price of larger
values is that they coarsen the granularity of short-term bandwidth
diff --git a/Documentation/block/biovecs.rst b/Documentation/block/biovecs.rst
index ddb867e0185b..b9dc0c9dbee4 100644
--- a/Documentation/block/biovecs.rst
+++ b/Documentation/block/biovecs.rst
@@ -134,6 +134,7 @@ Usage of helpers:
bio_for_each_bvec_all()
bio_first_bvec_all()
bio_first_page_all()
+ bio_first_folio_all()
bio_last_bvec_all()
* The following helpers iterate over single-page segment. The passed 'struct
diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst
index 31f52f326971..fc06761b6ea9 100644
--- a/Documentation/block/blk-mq.rst
+++ b/Documentation/block/blk-mq.rst
@@ -56,7 +56,7 @@ sent to the software queue.
Then, after the requests are processed by software queues, they will be placed
at the hardware queue, a second stage queue where the hardware has direct access
to process those requests. However, if the hardware does not have enough
-resources to accept more requests, blk-mq will places requests on a temporary
+resources to accept more requests, blk-mq will place requests on a temporary
queue, to be sent in the future, when the hardware is able.
Software staging queues
diff --git a/Documentation/block/capability.rst b/Documentation/block/capability.rst
deleted file mode 100644
index 2ae7f064736a..000000000000
--- a/Documentation/block/capability.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-===============================
-Generic Block Device Capability
-===============================
-
-This file documents the sysfs file ``block/<disk>/capability``.
-
-``capability`` is a bitfield, printed in hexadecimal, indicating which
-capabilities a specific block device supports:
-
-.. kernel-doc:: include/linux/blkdev.h
diff --git a/Documentation/block/cmdline-partition.rst b/Documentation/block/cmdline-partition.rst
index 530bedff548a..526ba201dddc 100644
--- a/Documentation/block/cmdline-partition.rst
+++ b/Documentation/block/cmdline-partition.rst
@@ -39,13 +39,16 @@ blkdevparts=<blkdev-def>[;<blkdev-def>]
create a link to block device partition with the name "PARTNAME".
User space application can access partition by partition name.
+ro
+ read-only. Flag the partition as read-only.
+
Example:
eMMC disk names are "mmcblk0" and "mmcblk0boot0".
bootargs::
- 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
+ 'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot)ro,-(kernel)'
dmesg::
diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst
index 07a97aa26668..99905e880a0e 100644
--- a/Documentation/block/data-integrity.rst
+++ b/Documentation/block/data-integrity.rst
@@ -153,18 +153,11 @@ bio_free() will automatically free the bip.
4.2 Block Device
----------------
-Because the format of the protection data is tied to the physical
-disk, each block device has been extended with a block integrity
-profile (struct blk_integrity). This optional profile is registered
-with the block layer using blk_integrity_register().
-
-The profile contains callback functions for generating and verifying
-the protection data, as well as getting and setting application tags.
-The profile also contains a few constants to aid in completing,
-merging and splitting the integrity metadata.
+Block devices can set up the integrity information in the integrity
+sub-struture of the queue_limits structure.
Layered block devices will need to pick a profile that's appropriate
-for all subdevices. blk_integrity_compare() can help with that. DM
+for all subdevices. queue_limits_stack_integrity() can help with that. DM
and MD linear, RAID0 and RAID1 are currently supported. RAID4/5/6
will require extra work due to the application tag.
@@ -209,7 +202,7 @@ will require extra work due to the application tag.
sector must be set, and the bio should have all data pages
added. It is up to the caller to ensure that the bio does not
change while I/O is in progress.
- Complete bio with error if prepare failed for some reson.
+ Complete bio with error if prepare failed for some reason.
5.3 Passing Existing Integrity Metadata
@@ -250,42 +243,6 @@ will require extra work due to the application tag.
integrity upon completion.
-5.4 Registering A Block Device As Capable Of Exchanging Integrity Metadata
---------------------------------------------------------------------------
-
- To enable integrity exchange on a block device the gendisk must be
- registered as capable:
-
- `int blk_integrity_register(gendisk, blk_integrity);`
-
- The blk_integrity struct is a template and should contain the
- following::
-
- static struct blk_integrity my_profile = {
- .name = "STANDARDSBODY-TYPE-VARIANT-CSUM",
- .generate_fn = my_generate_fn,
- .verify_fn = my_verify_fn,
- .tuple_size = sizeof(struct my_tuple_size),
- .tag_size = <tag bytes per hw sector>,
- };
-
- 'name' is a text string which will be visible in sysfs. This is
- part of the userland API so chose it carefully and never change
- it. The format is standards body-type-variant.
- E.g. T10-DIF-TYPE1-IP or T13-EPP-0-CRC.
-
- 'generate_fn' generates appropriate integrity metadata (for WRITE).
-
- 'verify_fn' verifies that the data buffer matches the integrity
- metadata.
-
- 'tuple_size' must be set to match the size of the integrity
- metadata per sector. I.e. 8 for DIF and EPP.
-
- 'tag_size' must be set to identify how many bytes of tag space
- are available per hardware sector. For DIF this is either 2 or
- 0 depending on the value of the Control Mode Page ATO bit.
-
----------------------------------------------------------------------
2007-12-24 Martin K. Petersen <martin.petersen@oracle.com>
diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst
index c4c73db748a8..9fea696f9daa 100644
--- a/Documentation/block/index.rst
+++ b/Documentation/block/index.rst
@@ -10,7 +10,6 @@ Block
bfq-iosched
biovecs
blk-mq
- capability
cmdline-partition
data-integrity
deadline-iosched
@@ -19,7 +18,6 @@ Block
kyber-iosched
null_blk
pr
- request
stat
switching-sched
writeback_cache_control
diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst
index 4d151fbe2058..6380e6ab492b 100644
--- a/Documentation/block/inline-encryption.rst
+++ b/Documentation/block/inline-encryption.rst
@@ -77,10 +77,10 @@ Basic design
============
We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
-how it will be used. This includes the actual bytes of the key; the size of the
-key; the algorithm and data unit size the key will be used with; and the number
-of bytes needed to represent the maximum data unit number the key will be used
-with.
+how it will be used. This includes the type of the key (raw or
+hardware-wrapped); the actual bytes of the key; the size of the key; the
+algorithm and data unit size the key will be used with; and the number of bytes
+needed to represent the maximum data unit number the key will be used with.
We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It
contains a data unit number and a pointer to a blk_crypto_key. We add pointers
@@ -142,7 +142,7 @@ Therefore, we also introduce *blk-crypto-fallback*, which is an implementation
of inline encryption using the kernel crypto API. blk-crypto-fallback is built
into the block layer, so it works on any block device without any special setup.
Essentially, when a bio with an encryption context is submitted to a
-request_queue that doesn't support that encryption context, the block layer will
+block_device that doesn't support that encryption context, the block layer will
handle en/decryption of the bio using blk-crypto-fallback.
For encryption, the data cannot be encrypted in-place, as callers usually rely
@@ -187,7 +187,7 @@ API presented to users of the block layer
``blk_crypto_config_supported()`` allows users to check ahead of time whether
inline encryption with particular crypto settings will work on a particular
-request_queue -- either via hardware or via blk-crypto-fallback. This function
+block_device -- either via hardware or via blk-crypto-fallback. This function
takes in a ``struct blk_crypto_config`` which is like blk_crypto_key, but omits
the actual bytes of the key and instead just contains the algorithm, data unit
size, etc. This function can be useful if blk-crypto-fallback is disabled.
@@ -195,7 +195,7 @@ size, etc. This function can be useful if blk-crypto-fallback is disabled.
``blk_crypto_init_key()`` allows users to initialize a blk_crypto_key.
Users must call ``blk_crypto_start_using_key()`` before actually starting to use
-a blk_crypto_key on a request_queue (even if ``blk_crypto_config_supported()``
+a blk_crypto_key on a block_device (even if ``blk_crypto_config_supported()``
was called earlier). This is needed to initialize blk-crypto-fallback if it
will be needed. This must not be called from the data path, as this may have to
allocate resources, which may deadlock in that case.
@@ -207,7 +207,7 @@ for en/decryption. Users don't need to worry about freeing the bio_crypt_ctx
later, as that happens automatically when the bio is freed or reset.
Finally, when done using inline encryption with a blk_crypto_key on a
-request_queue, users must call ``blk_crypto_evict_key()``. This ensures that
+block_device, users must call ``blk_crypto_evict_key()``. This ensures that
the key is evicted from all keyslots it may be programmed into and unlinked from
any kernel data structures it may be linked into.
@@ -221,9 +221,9 @@ as follows:
5. ``blk_crypto_evict_key()`` (after all I/O has completed)
6. Zeroize the blk_crypto_key (this has no dedicated function)
-If a blk_crypto_key is being used on multiple request_queues, then
+If a blk_crypto_key is being used on multiple block_devices, then
``blk_crypto_config_supported()`` (if used), ``blk_crypto_start_using_key()``,
-and ``blk_crypto_evict_key()`` must be called on each request_queue.
+and ``blk_crypto_evict_key()`` must be called on each block_device.
API presented to device drivers
===============================
@@ -270,8 +270,7 @@ Request queue based layered devices like dm-rq that wish to support inline
encryption need to create their own blk_crypto_profile for their request_queue,
and expose whatever functionality they choose. When a layered device wants to
pass a clone of that request to another request_queue, blk-crypto will
-initialize and prepare the clone as necessary; see
-``blk_crypto_insert_cloned_request()``.
+initialize and prepare the clone as necessary.
Interaction between inline encryption and blk integrity
=======================================================
@@ -302,3 +301,250 @@ kernel will pretend that the device does not support hardware inline encryption
When the crypto API fallback is enabled, this means that all bios with and
encryption context will use the fallback, and IO will complete as usual. When
the fallback is disabled, a bio with an encryption context will be failed.
+
+.. _hardware_wrapped_keys:
+
+Hardware-wrapped keys
+=====================
+
+Motivation and threat model
+---------------------------
+
+Linux storage encryption (dm-crypt, fscrypt, eCryptfs, etc.) traditionally
+relies on the raw encryption key(s) being present in kernel memory so that the
+encryption can be performed. This traditionally isn't seen as a problem because
+the key(s) won't be present during an offline attack, which is the main type of
+attack that storage encryption is intended to protect from.
+
+However, there is an increasing desire to also protect users' data from other
+types of attacks (to the extent possible), including:
+
+- Cold boot attacks, where an attacker with physical access to a system suddenly
+ powers it off, then immediately dumps the system memory to extract recently
+ in-use encryption keys, then uses these keys to decrypt user data on-disk.
+
+- Online attacks where the attacker is able to read kernel memory without fully
+ compromising the system, followed by an offline attack where any extracted
+ keys can be used to decrypt user data on-disk. An example of such an online
+ attack would be if the attacker is able to run some code on the system that
+ exploits a Meltdown-like vulnerability but is unable to escalate privileges.
+
+- Online attacks where the attacker fully compromises the system, but their data
+ exfiltration is significantly time-limited and/or bandwidth-limited, so in
+ order to completely exfiltrate the data they need to extract the encryption
+ keys to use in a later offline attack.
+
+Hardware-wrapped keys are a feature of inline encryption hardware that is
+designed to protect users' data from the above attacks (to the extent possible),
+without introducing limitations such as a maximum number of keys.
+
+Note that it is impossible to **fully** protect users' data from these attacks.
+Even in the attacks where the attacker "just" gets read access to kernel memory,
+they can still extract any user data that is present in memory, including
+plaintext pagecache pages of encrypted files. The focus here is just on
+protecting the encryption keys, as those instantly give access to **all** user
+data in any following offline attack, rather than just some of it (where which
+data is included in that "some" might not be controlled by the attacker).
+
+Solution overview
+-----------------
+
+Inline encryption hardware typically has "keyslots" into which software can
+program keys for the hardware to use; the contents of keyslots typically can't
+be read back by software. As such, the above security goals could be achieved
+if the kernel simply erased its copy of the key(s) after programming them into
+keyslot(s) and thereafter only referred to them via keyslot number.
+
+However, that naive approach runs into a couple problems:
+
+- It limits the number of unlocked keys to the number of keyslots, which
+ typically is a small number. In cases where there is only one encryption key
+ system-wide (e.g., a full-disk encryption key), that can be tolerable.
+ However, in general there can be many logged-in users with many different
+ keys, and/or many running applications with application-specific encrypted
+ storage areas. This is especially true if file-based encryption (e.g.
+ fscrypt) is being used.
+
+- Inline crypto engines typically lose the contents of their keyslots if the
+ storage controller (usually UFS or eMMC) is reset. Resetting the storage
+ controller is a standard error recovery procedure that is executed if certain
+ types of storage errors occur, and such errors can occur at any time.
+ Therefore, when inline crypto is being used, the operating system must always
+ be ready to reprogram the keyslots without user intervention.
+
+Thus, it is important for the kernel to still have a way to "remind" the
+hardware about a key, without actually having the raw key itself.
+
+Somewhat less importantly, it is also desirable that the raw keys are never
+visible to software at all, even while being initially unlocked. This would
+ensure that a read-only compromise of system memory will never allow a key to be
+extracted to be used off-system, even if it occurs when a key is being unlocked.
+
+To solve all these problems, some vendors of inline encryption hardware have
+made their hardware support *hardware-wrapped keys*. Hardware-wrapped keys
+are encrypted keys that can only be unwrapped (decrypted) and used by hardware
+-- either by the inline encryption hardware itself, or by a dedicated hardware
+block that can directly provision keys to the inline encryption hardware.
+
+(We refer to them as "hardware-wrapped keys" rather than simply "wrapped keys"
+to add some clarity in cases where there could be other types of wrapped keys,
+such as in file-based encryption. Key wrapping is a commonly used technique.)
+
+The key which wraps (encrypts) hardware-wrapped keys is a hardware-internal key
+that is never exposed to software; it is either a persistent key (a "long-term
+wrapping key") or a per-boot key (an "ephemeral wrapping key"). The long-term
+wrapped form of the key is what is initially unlocked, but it is erased from
+memory as soon as it is converted into an ephemerally-wrapped key. In-use
+hardware-wrapped keys are always ephemerally-wrapped, not long-term wrapped.
+
+As inline encryption hardware can only be used to encrypt/decrypt data on-disk,
+the hardware also includes a level of indirection; it doesn't use the unwrapped
+key directly for inline encryption, but rather derives both an inline encryption
+key and a "software secret" from it. Software can use the "software secret" for
+tasks that can't use the inline encryption hardware, such as filenames
+encryption. The software secret is not protected from memory compromise.
+
+Key hierarchy
+-------------
+
+Here is the key hierarchy for a hardware-wrapped key::
+
+ Hardware-wrapped key
+ |
+ |
+ <Hardware KDF>
+ |
+ -----------------------------
+ | |
+ Inline encryption key Software secret
+
+The components are:
+
+- *Hardware-wrapped key*: a key for the hardware's KDF (Key Derivation
+ Function), in ephemerally-wrapped form. The key wrapping algorithm is a
+ hardware implementation detail that doesn't impact kernel operation, but a
+ strong authenticated encryption algorithm such as AES-256-GCM is recommended.
+
+- *Hardware KDF*: a KDF (Key Derivation Function) which the hardware uses to
+ derive subkeys after unwrapping the wrapped key. The hardware's choice of KDF
+ doesn't impact kernel operation, but it does need to be known for testing
+ purposes, and it's also assumed to have at least a 256-bit security strength.
+ All known hardware uses the SP800-108 KDF in Counter Mode with AES-256-CMAC,
+ with a particular choice of labels and contexts; new hardware should use this
+ already-vetted KDF.
+
+- *Inline encryption key*: a derived key which the hardware directly provisions
+ to a keyslot of the inline encryption hardware, without exposing it to
+ software. In all known hardware, this will always be an AES-256-XTS key.
+ However, in principle other encryption algorithms could be supported too.
+ Hardware must derive distinct subkeys for each supported encryption algorithm.
+
+- *Software secret*: a derived key which the hardware returns to software so
+ that software can use it for cryptographic tasks that can't use inline
+ encryption. This value is cryptographically isolated from the inline
+ encryption key, i.e. knowing one doesn't reveal the other. (The KDF ensures
+ this.) Currently, the software secret is always 32 bytes and thus is suitable
+ for cryptographic applications that require up to a 256-bit security strength.
+ Some use cases (e.g. full-disk encryption) won't require the software secret.
+
+Example: in the case of fscrypt, the fscrypt master key (the key that protects a
+particular set of encrypted directories) is made hardware-wrapped. The inline
+encryption key is used as the file contents encryption key, while the software
+secret (rather than the master key directly) is used to key fscrypt's KDF
+(HKDF-SHA512) to derive other subkeys such as filenames encryption keys.
+
+Note that currently this design assumes a single inline encryption key per
+hardware-wrapped key, without any further key derivation. Thus, in the case of
+fscrypt, currently hardware-wrapped keys are only compatible with the "inline
+encryption optimized" settings, which use one file contents encryption key per
+encryption policy rather than one per file. This design could be extended to
+make the hardware derive per-file keys using per-file nonces passed down the
+storage stack, and in fact some hardware already supports this; future work is
+planned to remove this limitation by adding the corresponding kernel support.
+
+Kernel support
+--------------
+
+The inline encryption support of the kernel's block layer ("blk-crypto") has
+been extended to support hardware-wrapped keys as an alternative to raw keys,
+when hardware support is available. This works in the following way:
+
+- A ``key_types_supported`` field is added to the crypto capabilities in
+ ``struct blk_crypto_profile``. This allows device drivers to declare that
+ they support raw keys, hardware-wrapped keys, or both.
+
+- ``struct blk_crypto_key`` can now contain a hardware-wrapped key as an
+ alternative to a raw key; a ``key_type`` field is added to
+ ``struct blk_crypto_config`` to distinguish between the different key types.
+ This allows users of blk-crypto to en/decrypt data using a hardware-wrapped
+ key in a way very similar to using a raw key.
+
+- A new method ``blk_crypto_ll_ops::derive_sw_secret`` is added. Device drivers
+ that support hardware-wrapped keys must implement this method. Users of
+ blk-crypto can call ``blk_crypto_derive_sw_secret()`` to access this method.
+
+- The programming and eviction of hardware-wrapped keys happens via
+ ``blk_crypto_ll_ops::keyslot_program`` and
+ ``blk_crypto_ll_ops::keyslot_evict``, just like it does for raw keys. If a
+ driver supports hardware-wrapped keys, then it must handle hardware-wrapped
+ keys being passed to these methods.
+
+blk-crypto-fallback doesn't support hardware-wrapped keys. Therefore,
+hardware-wrapped keys can only be used with actual inline encryption hardware.
+
+All the above deals with hardware-wrapped keys in ephemerally-wrapped form only.
+To get such keys in the first place, new block device ioctls have been added to
+provide a generic interface to creating and preparing such keys:
+
+- ``BLKCRYPTOIMPORTKEY`` converts a raw key to long-term wrapped form. It takes
+ in a pointer to a ``struct blk_crypto_import_key_arg``. The caller must set
+ ``raw_key_ptr`` and ``raw_key_size`` to the pointer and size (in bytes) of the
+ raw key to import. On success, ``BLKCRYPTOIMPORTKEY`` returns 0 and writes
+ the resulting long-term wrapped key blob to the buffer pointed to by
+ ``lt_key_ptr``, which is of maximum size ``lt_key_size``. It also updates
+ ``lt_key_size`` to be the actual size of the key. On failure, it returns -1
+ and sets errno. An errno of ``EOPNOTSUPP`` indicates that the block device
+ does not support hardware-wrapped keys. An errno of ``EOVERFLOW`` indicates
+ that the output buffer did not have enough space for the key blob.
+
+- ``BLKCRYPTOGENERATEKEY`` is like ``BLKCRYPTOIMPORTKEY``, but it has the
+ hardware generate the key instead of importing one. It takes in a pointer to
+ a ``struct blk_crypto_generate_key_arg``.
+
+- ``BLKCRYPTOPREPAREKEY`` converts a key from long-term wrapped form to
+ ephemerally-wrapped form. It takes in a pointer to a ``struct
+ blk_crypto_prepare_key_arg``. The caller must set ``lt_key_ptr`` and
+ ``lt_key_size`` to the pointer and size (in bytes) of the long-term wrapped
+ key blob to convert. On success, ``BLKCRYPTOPREPAREKEY`` returns 0 and writes
+ the resulting ephemerally-wrapped key blob to the buffer pointed to by
+ ``eph_key_ptr``, which is of maximum size ``eph_key_size``. It also updates
+ ``eph_key_size`` to be the actual size of the key. On failure, it returns -1
+ and sets errno. Errno values of ``EOPNOTSUPP`` and ``EOVERFLOW`` mean the
+ same as they do for ``BLKCRYPTOIMPORTKEY``. An errno of ``EBADMSG`` indicates
+ that the long-term wrapped key is invalid.
+
+Userspace needs to use either ``BLKCRYPTOIMPORTKEY`` or ``BLKCRYPTOGENERATEKEY``
+once to create a key, and then ``BLKCRYPTOPREPAREKEY`` each time the key is
+unlocked and added to the kernel. Note that these ioctls have no relevance for
+raw keys; they are only for hardware-wrapped keys.
+
+Testability
+-----------
+
+Both the hardware KDF and the inline encryption itself are well-defined
+algorithms that don't depend on any secrets other than the unwrapped key.
+Therefore, if the unwrapped key is known to software, these algorithms can be
+reproduced in software in order to verify the ciphertext that is written to disk
+by the inline encryption hardware.
+
+However, the unwrapped key will only be known to software for testing if the
+"import" functionality is used. Proper testing is not possible in the
+"generate" case where the hardware generates the key itself. The correct
+operation of the "generate" mode thus relies on the security and correctness of
+the hardware RNG and its use to generate the key, as well as the testing of the
+"import" mode as that should cover all parts other than the key generation.
+
+For an example of a test that verifies the ciphertext written to disk in the
+"import" mode, see the fscrypt hardware-wrapped key tests in xfstests, or
+`Android's vts_kernel_encryption_test
+<https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/main/encryption/>`_.
diff --git a/Documentation/block/ioprio.rst b/Documentation/block/ioprio.rst
index f72b0de65af7..4662e1ff3d81 100644
--- a/Documentation/block/ioprio.rst
+++ b/Documentation/block/ioprio.rst
@@ -6,17 +6,16 @@ Block io priorities
Intro
-----
-With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
-priorities are supported for reads on files. This enables users to io nice
-processes or process groups, similar to what has been possible with cpu
-scheduling for ages. This document mainly details the current possibilities
-with cfq; other io schedulers do not support io priorities thus far.
+The io priority feature enables users to io nice processes or process groups,
+similar to what has been possible with cpu scheduling for ages. Support for io
+priorities is io scheduler dependent and currently supported by bfq and
+mq-deadline.
Scheduling classes
------------------
-CFQ implements three generic scheduling classes that determine how io is
-served for a process.
+Three generic scheduling classes are implemented for io priorities that
+determine how io is served for a process.
IOPRIO_CLASS_RT: This is the realtime io class. This scheduling class is given
higher priority than any other in the system, processes from this class are
@@ -80,9 +79,6 @@ ionice.c tool::
#elif defined(__x86_64__)
#define __NR_ioprio_set 251
#define __NR_ioprio_get 252
- #elif defined(__ia64__)
- #define __NR_ioprio_set 1274
- #define __NR_ioprio_get 1275
#else
#error "Unsupported arch"
#endif
diff --git a/Documentation/block/request.rst b/Documentation/block/request.rst
deleted file mode 100644
index 747021e1ffdb..000000000000
--- a/Documentation/block/request.rst
+++ /dev/null
@@ -1,99 +0,0 @@
-============================
-struct request documentation
-============================
-
-Jens Axboe <jens.axboe@oracle.com> 27/05/02
-
-
-.. FIXME:
- No idea about what does mean - seems just some noise, so comment it
-
- 1.0
- Index
-
- 2.0 Struct request members classification
-
- 2.1 struct request members explanation
-
- 3.0
-
-
- 2.0
-
-
-
-Short explanation of request members
-====================================
-
-Classification flags:
-
- = ====================
- D driver member
- B block layer member
- I I/O scheduler member
- = ====================
-
-Unless an entry contains a D classification, a device driver must not access
-this member. Some members may contain D classifications, but should only be
-access through certain macros or functions (eg ->flags).
-
-<linux/blkdev.h>
-
-=============================== ======= =======================================
-Member Flag Comment
-=============================== ======= =======================================
-struct list_head queuelist BI Organization on various internal
- queues
-
-``void *elevator_private`` I I/O scheduler private data
-
-unsigned char cmd[16] D Driver can use this for setting up
- a cdb before execution, see
- blk_queue_prep_rq
-
-unsigned long flags DBI Contains info about data direction,
- request type, etc.
-
-int rq_status D Request status bits
-
-kdev_t rq_dev DBI Target device
-
-int errors DB Error counts
-
-sector_t sector DBI Target location
-
-unsigned long hard_nr_sectors B Used to keep sector sane
-
-unsigned long nr_sectors DBI Total number of sectors in request
-
-unsigned long hard_nr_sectors B Used to keep nr_sectors sane
-
-unsigned short nr_phys_segments DB Number of physical scatter gather
- segments in a request
-
-unsigned short nr_hw_segments DB Number of hardware scatter gather
- segments in a request
-
-unsigned int current_nr_sectors DB Number of sectors in first segment
- of request
-
-unsigned int hard_cur_sectors B Used to keep current_nr_sectors sane
-
-int tag DB TCQ tag, if assigned
-
-``void *special`` D Free to be used by driver
-
-``char *buffer`` D Map of first segment, also see
- section on bouncing SECTION
-
-``struct completion *waiting`` D Can be used by driver to get signalled
- on request completion
-
-``struct bio *bio`` DBI First bio in request
-
-``struct bio *biotail`` DBI Last bio in request
-
-``struct request_queue *q`` DB Request queue this request belongs to
-
-``struct request_list *rl`` B Request list this request came from
-=============================== ======= =======================================
diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst
index 2122d1a4a541..8c4030bcabb6 100644
--- a/Documentation/block/ublk.rst
+++ b/Documentation/block/ublk.rst
@@ -115,15 +115,15 @@ managing and controlling ublk devices with help of several control commands:
- ``UBLK_CMD_START_DEV``
- After the server prepares userspace resources (such as creating per-queue
- pthread & io_uring for handling ublk IO), this command is sent to the
+ After the server prepares userspace resources (such as creating I/O handler
+ threads & io_uring for handling ublk IO), this command is sent to the
driver for allocating & exposing ``/dev/ublkb*``. Parameters set via
``UBLK_CMD_SET_PARAMS`` are applied for creating the device.
- ``UBLK_CMD_STOP_DEV``
Halt IO on ``/dev/ublkb*`` and remove the device. When this command returns,
- ublk server will release resources (such as destroying per-queue pthread &
+ ublk server will release resources (such as destroying I/O handler threads &
io_uring).
- ``UBLK_CMD_DEL_DEV``
@@ -144,19 +144,114 @@ managing and controlling ublk devices with help of several control commands:
For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's
responsibility to save IO target specific info in userspace.
+- ``UBLK_CMD_GET_DEV_INFO2``
+ Same purpose with ``UBLK_CMD_GET_DEV_INFO``, but ublk server has to
+ provide path of the char device of ``/dev/ublkc*`` for kernel to run
+ permission check, and this command is added for supporting unprivileged
+ ublk device, and introduced with ``UBLK_F_UNPRIVILEGED_DEV`` together.
+ Only the user owning the requested device can retrieve the device info.
+
+ How to deal with userspace/kernel compatibility:
+
+ 1) if kernel is capable of handling ``UBLK_F_UNPRIVILEGED_DEV``
+
+ If ublk server supports ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ublk server should send ``UBLK_CMD_GET_DEV_INFO2``, given anytime
+ unprivileged application needs to query devices the current user owns,
+ when the application has no idea if ``UBLK_F_UNPRIVILEGED_DEV`` is set
+ given the capability info is stateless, and application should always
+ retrieve it via ``UBLK_CMD_GET_DEV_INFO2``
+
+ If ublk server doesn't support ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ``UBLK_CMD_GET_DEV_INFO`` is always sent to kernel, and the feature of
+ UBLK_F_UNPRIVILEGED_DEV isn't available for user
+
+ 2) if kernel isn't capable of handling ``UBLK_F_UNPRIVILEGED_DEV``
+
+ If ublk server supports ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ``UBLK_CMD_GET_DEV_INFO2`` is tried first, and will be failed, then
+ ``UBLK_CMD_GET_DEV_INFO`` needs to be retried given
+ ``UBLK_F_UNPRIVILEGED_DEV`` can't be set
+
+ If ublk server doesn't support ``UBLK_F_UNPRIVILEGED_DEV``:
+
+ ``UBLK_CMD_GET_DEV_INFO`` is always sent to kernel, and the feature of
+ ``UBLK_F_UNPRIVILEGED_DEV`` isn't available for user
+
+- ``UBLK_CMD_START_USER_RECOVERY``
+
+ This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This
+ command is accepted after the old process has exited, ublk device is quiesced
+ and ``/dev/ublkc*`` is released. User should send this command before he starts
+ a new process which re-opens ``/dev/ublkc*``. When this command returns, the
+ ublk device is ready for the new process.
+
+- ``UBLK_CMD_END_USER_RECOVERY``
+
+ This command is valid if ``UBLK_F_USER_RECOVERY`` feature is enabled. This
+ command is accepted after ublk device is quiesced and a new process has
+ opened ``/dev/ublkc*`` and get all ublk queues be ready. When this command
+ returns, ublk device is unquiesced and new I/O requests are passed to the
+ new process.
+
+- user recovery feature description
+
+ Three new features are added for user recovery: ``UBLK_F_USER_RECOVERY``,
+ ``UBLK_F_USER_RECOVERY_REISSUE``, and ``UBLK_F_USER_RECOVERY_FAIL_IO``. To
+ enable recovery of ublk devices after the ublk server exits, the ublk server
+ should specify the ``UBLK_F_USER_RECOVERY`` flag when creating the device. The
+ ublk server may additionally specify at most one of
+ ``UBLK_F_USER_RECOVERY_REISSUE`` and ``UBLK_F_USER_RECOVERY_FAIL_IO`` to
+ modify how I/O is handled while the ublk server is dying/dead (this is called
+ the ``nosrv`` case in the driver code).
+
+ With just ``UBLK_F_USER_RECOVERY`` set, after the ublk server exits,
+ ublk does not delete ``/dev/ublkb*`` during the whole
+ recovery stage and ublk device ID is kept. It is ublk server's
+ responsibility to recover the device context by its own knowledge.
+ Requests which have not been issued to userspace are requeued. Requests
+ which have been issued to userspace are aborted.
+
+ With ``UBLK_F_USER_RECOVERY_REISSUE`` additionally set, after the ublk server
+ exits, contrary to ``UBLK_F_USER_RECOVERY``,
+ requests which have been issued to userspace are requeued and will be
+ re-issued to the new process after handling ``UBLK_CMD_END_USER_RECOVERY``.
+ ``UBLK_F_USER_RECOVERY_REISSUE`` is designed for backends who tolerate
+ double-write since the driver may issue the same I/O request twice. It
+ might be useful to a read-only FS or a VM backend.
+
+ With ``UBLK_F_USER_RECOVERY_FAIL_IO`` additionally set, after the ublk server
+ exits, requests which have issued to userspace are failed, as are any
+ subsequently issued requests. Applications continuously issuing I/O against
+ devices with this flag set will see a stream of I/O errors until a new ublk
+ server recovers the device.
+
+Unprivileged ublk device is supported by passing ``UBLK_F_UNPRIVILEGED_DEV``.
+Once the flag is set, all control commands can be sent by unprivileged
+user. Except for command of ``UBLK_CMD_ADD_DEV``, permission check on
+the specified char device(``/dev/ublkc*``) is done for all other control
+commands by ublk driver, for doing that, path of the char device has to
+be provided in these commands' payload from ublk server. With this way,
+ublk device becomes container-ware, and device created in one container
+can be controlled/accessed just inside this container.
+
Data plane
----------
-ublk server needs to create per-queue IO pthread & io_uring for handling IO
-commands via io_uring passthrough. The per-queue IO pthread
-focuses on IO handling and shouldn't handle any control & management
-tasks.
+The ublk server should create dedicated threads for handling I/O. Each
+thread should have its own io_uring through which it is notified of new
+I/O, and through which it can complete I/O. These dedicated threads
+should focus on IO handling and shouldn't handle any control &
+management tasks.
The's IO is assigned by a unique tag, which is 1:1 mapping with IO
request of ``/dev/ublkb*``.
UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
-the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for
+the driver. A fixed mmapped area (array) on ``/dev/ublkc*`` is provided for
exporting IO info to the server; such as IO offset, length, OP/flags and
buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id
and IO tag directly.
@@ -171,6 +266,18 @@ with specified IO tag in the command data:
destined to ``/dev/ublkb*``. This command is sent only once from the server
IO pthread for ublk driver to setup IO forward environment.
+ Once a thread issues this command against a given (qid,tag) pair, the thread
+ registers itself as that I/O's daemon. In the future, only that I/O's daemon
+ is allowed to issue commands against the I/O. If any other thread attempts
+ to issue a command against a (qid,tag) pair for which the thread is not the
+ daemon, the command will fail. Daemons can be reset only be going through
+ recovery.
+
+ The ability for every (qid,tag) pair to have its own independent daemon task
+ is indicated by the ``UBLK_F_PER_IO_DAEMON`` feature. If this feature is not
+ supported by the driver, daemons must be per-queue instead - i.e. all I/Os
+ associated to a single qid must be handled by the same task.
+
- ``UBLK_IO_COMMIT_AND_FETCH_REQ``
When an IO request is destined to ``/dev/ublkb*``, the driver stores
@@ -215,27 +322,112 @@ with specified IO tag in the command data:
``UBLK_IO_COMMIT_AND_FETCH_REQ`` to the server, ublkdrv needs to copy
the server buffer (pages) read to the IO request pages.
-Future development
-==================
+Zero copy
+---------
-Container-aware ublk deivice
-----------------------------
+ublk zero copy relies on io_uring's fixed kernel buffer, which provides
+two APIs: `io_buffer_register_bvec()` and `io_buffer_unregister_bvec`.
-ublk driver doesn't handle any IO logic. Its function is well defined
-for now and very limited userspace interfaces are needed, which is also
-well defined too. It is possible to make ublk devices container-aware block
-devices in future as Stefan Hajnoczi suggested [#stefan]_, by removing
-ADMIN privilege.
+ublk adds IO command of `UBLK_IO_REGISTER_IO_BUF` to call
+`io_buffer_register_bvec()` for ublk server to register client request
+buffer into io_uring buffer table, then ublk server can submit io_uring
+IOs with the registered buffer index. IO command of `UBLK_IO_UNREGISTER_IO_BUF`
+calls `io_buffer_unregister_bvec()` to unregister the buffer, which is
+guaranteed to be live between calling `io_buffer_register_bvec()` and
+`io_buffer_unregister_bvec()`. Any io_uring operation which supports this
+kind of kernel buffer will grab one reference of the buffer until the
+operation is completed.
-Zero copy
----------
+ublk server implementing zero copy or user copy has to be CAP_SYS_ADMIN and
+be trusted, because it is ublk server's responsibility to make sure IO buffer
+filled with data for handling read command, and ublk server has to return
+correct result to ublk driver when handling READ command, and the result
+has to match with how many bytes filled to the IO buffer. Otherwise,
+uninitialized kernel IO buffer will be exposed to client application.
+
+ublk server needs to align the parameter of `struct ublk_param_dma_align`
+with backend for zero copy to work correctly.
+
+For reaching best IO performance, ublk server should align its segment
+parameter of `struct ublk_param_segment` with backend for avoiding
+unnecessary IO split, which usually hurts io_uring performance.
+
+Auto Buffer Registration
+------------------------
+
+The ``UBLK_F_AUTO_BUF_REG`` feature automatically handles buffer registration
+and unregistration for I/O requests, which simplifies the buffer management
+process and reduces overhead in the ublk server implementation.
+
+This is another feature flag for using zero copy, and it is compatible with
+``UBLK_F_SUPPORT_ZERO_COPY``.
+
+Feature Overview
+~~~~~~~~~~~~~~~~
+
+This feature automatically registers request buffers to the io_uring context
+before delivering I/O commands to the ublk server and unregisters them when
+completing I/O commands. This eliminates the need for manual buffer
+registration/unregistration via ``UBLK_IO_REGISTER_IO_BUF`` and
+``UBLK_IO_UNREGISTER_IO_BUF`` commands, then IO handling in ublk server
+can avoid dependency on the two uring_cmd operations.
+
+IOs can't be issued concurrently to io_uring if there is any dependency
+among these IOs. So this way not only simplifies ublk server implementation,
+but also makes concurrent IO handling becomes possible by removing the
+dependency on buffer registration & unregistration commands.
+
+Usage Requirements
+~~~~~~~~~~~~~~~~~~
+
+1. The ublk server must create a sparse buffer table on the same ``io_ring_ctx``
+ used for ``UBLK_IO_FETCH_REQ`` and ``UBLK_IO_COMMIT_AND_FETCH_REQ``. If
+ uring_cmd is issued on a different ``io_ring_ctx``, manual buffer
+ unregistration is required.
+
+2. Buffer registration data must be passed via uring_cmd's ``sqe->addr`` with the
+ following structure::
-Zero copy is a generic requirement for nbd, fuse or similar drivers. A
-problem [#xiaoguang]_ Xiaoguang mentioned is that pages mapped to userspace
-can't be remapped any more in kernel with existing mm interfaces. This can
-occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that
-big requests (IO size >= 256 KB) may benefit a lot from zero copy.
+ struct ublk_auto_buf_reg {
+ __u16 index; /* Buffer index for registration */
+ __u8 flags; /* Registration flags */
+ __u8 reserved0; /* Reserved for future use */
+ __u32 reserved1; /* Reserved for future use */
+ };
+ ublk_auto_buf_reg_to_sqe_addr() is for converting the above structure into
+ ``sqe->addr``.
+
+3. All reserved fields in ``ublk_auto_buf_reg`` must be zeroed.
+
+4. Optional flags can be passed via ``ublk_auto_buf_reg.flags``.
+
+Fallback Behavior
+~~~~~~~~~~~~~~~~~
+
+If auto buffer registration fails:
+
+1. When ``UBLK_AUTO_BUF_REG_FALLBACK`` is enabled:
+
+ - The uring_cmd is completed
+ - ``UBLK_IO_F_NEED_REG_BUF`` is set in ``ublksrv_io_desc.op_flags``
+ - The ublk server must manually deal with the failure, such as, register
+ the buffer manually, or using user copy feature for retrieving the data
+ for handling ublk IO
+
+2. If fallback is not enabled:
+
+ - The ublk I/O request fails silently
+ - The uring_cmd won't be completed
+
+Limitations
+~~~~~~~~~~~
+
+- Requires same ``io_ring_ctx`` for all operations
+- May require manual buffer management in fallback cases
+- io_ring_ctx buffer table has a max size of 16K, which may not be enough
+ in case that too many ublk devices are handled by this single io_ring_ctx
+ and each one has very large queue depth
References
==========
@@ -247,7 +439,3 @@ References
.. [#userspace_nbdublk] https://gitlab.com/rwmjones/libnbd/-/tree/nbdublk
.. [#userspace_readme] https://github.com/ming1/ubdsrv/blob/master/README
-
-.. [#stefan] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/
-
-.. [#xiaoguang] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/
diff --git a/Documentation/block/writeback_cache_control.rst b/Documentation/block/writeback_cache_control.rst
index b208488d0aae..c3707d071780 100644
--- a/Documentation/block/writeback_cache_control.rst
+++ b/Documentation/block/writeback_cache_control.rst
@@ -46,41 +46,50 @@ worry if the underlying devices need any explicit cache flushing and how
the Forced Unit Access is implemented. The REQ_PREFLUSH and REQ_FUA flags
may both be set on a single bio.
+Feature settings for block drivers
+----------------------------------
-Implementation details for bio based block drivers
---------------------------------------------------------------
+For devices that do not support volatile write caches there is no driver
+support required, the block layer completes empty REQ_PREFLUSH requests before
+entering the driver and strips off the REQ_PREFLUSH and REQ_FUA bits from
+requests that have a payload.
-These drivers will always see the REQ_PREFLUSH and REQ_FUA bits as they sit
-directly below the submit_bio interface. For remapping drivers the REQ_FUA
-bits need to be propagated to underlying devices, and a global flush needs
-to be implemented for bios with the REQ_PREFLUSH bit set. For real device
-drivers that do not have a volatile cache the REQ_PREFLUSH and REQ_FUA bits
-on non-empty bios can simply be ignored, and REQ_PREFLUSH requests without
-data can be completed successfully without doing any work. Drivers for
-devices with volatile caches need to implement the support for these
-flags themselves without any help from the block layer.
+For devices with volatile write caches the driver needs to tell the block layer
+that it supports flushing caches by setting the
+ BLK_FEAT_WRITE_CACHE
-Implementation details for request_fn based block drivers
----------------------------------------------------------
+flag in the queue_limits feature field. For devices that also support the FUA
+bit the block layer needs to be told to pass on the REQ_FUA bit by also setting
+the
-For devices that do not support volatile write caches there is no driver
-support required, the block layer completes empty REQ_PREFLUSH requests before
-entering the driver and strips off the REQ_PREFLUSH and REQ_FUA bits from
-requests that have a payload. For devices with volatile write caches the
-driver needs to tell the block layer that it supports flushing caches by
-doing::
+ BLK_FEAT_FUA
+
+flag in the features field of the queue_limits structure.
+
+Implementation details for bio based block drivers
+--------------------------------------------------
+
+For bio based drivers the REQ_PREFLUSH and REQ_FUA bit are simply passed on to
+the driver if the driver sets the BLK_FEAT_WRITE_CACHE flag and the driver
+needs to handle them.
+
+*NOTE*: The REQ_FUA bit also gets passed on when the BLK_FEAT_FUA flags is
+_not_ set. Any bio based driver that sets BLK_FEAT_WRITE_CACHE also needs to
+handle REQ_FUA.
- blk_queue_write_cache(sdkp->disk->queue, true, false);
+For remapping drivers the REQ_FUA bits need to be propagated to underlying
+devices, and a global flush needs to be implemented for bios with the
+REQ_PREFLUSH bit set.
-and handle empty REQ_OP_FLUSH requests in its prep_fn/request_fn. Note that
-REQ_PREFLUSH requests with a payload are automatically turned into a sequence
-of an empty REQ_OP_FLUSH request followed by the actual write by the block
-layer. For devices that also support the FUA bit the block layer needs
-to be told to pass through the REQ_FUA bit using::
+Implementation details for blk-mq drivers
+-----------------------------------------
- blk_queue_write_cache(sdkp->disk->queue, true, true);
+When the BLK_FEAT_WRITE_CACHE flag is set, REQ_OP_WRITE | REQ_PREFLUSH requests
+with a payload are automatically turned into a sequence of a REQ_OP_FLUSH
+request followed by the actual write by the block layer.
-and the driver must handle write requests that have the REQ_FUA bit set
-in prep_fn/request_fn. If the FUA bit is not natively supported the block
-layer turns it into an empty REQ_OP_FLUSH request after the actual write.
+When the BLK_FEAT_FUA flags is set, the REQ_FUA bit is simply passed on for the
+REQ_OP_WRITE request, else a REQ_OP_FLUSH request is sent by the block layer
+after the completion of the write request for bio submissions with the REQ_FUA
+bit set.
diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
index a210b8a4df00..eb19c945f4d5 100644
--- a/Documentation/bpf/bpf_design_QA.rst
+++ b/Documentation/bpf/bpf_design_QA.rst
@@ -140,11 +140,6 @@ A: Because if we picked one-to-one relationship to x64 it would have made
it more complicated to support on arm64 and other archs. Also it
needs div-by-zero runtime check.
-Q: Why there is no BPF_SDIV for signed divide operation?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A: Because it would be rarely used. llvm errors in such case and
-prints a suggestion to use unsigned divide instead.
-
Q: Why BPF has implicit prologue and epilogue?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A: Because architectures like sparc have register windows and in general
@@ -208,6 +203,10 @@ data structures and compile with kernel internal headers. Both of these
kernel internals are subject to change and can break with newer kernels
such that the program needs to be adapted accordingly.
+New BPF functionality is generally added through the use of kfuncs instead of
+new helpers. Kfuncs are not considered part of the stable API, and have their own
+lifecycle expectations as described in :ref:`BPF_kfunc_lifecycle_expectations`.
+
Q: Are tracepoints part of the stable ABI?
------------------------------------------
A: NO. Tracepoints are tied to internal implementation details hence they are
@@ -236,8 +235,8 @@ A: NO. Classic BPF programs are converted into extend BPF instructions.
Q: Can BPF call arbitrary kernel functions?
-------------------------------------------
-A: NO. BPF programs can only call a set of helper functions which
-is defined for every program type.
+A: NO. BPF programs can only call specific functions exposed as BPF helpers or
+kfuncs. The set of available functions is defined for every program type.
Q: Can BPF overwrite arbitrary kernel memory?
---------------------------------------------
@@ -263,7 +262,12 @@ Q: New functionality via kernel modules?
Q: Can BPF functionality such as new program or map types, new
helpers, etc be added out of kernel module code?
-A: NO.
+A: Yes, through kfuncs and kptrs
+
+The core BPF functionality such as program types, maps and helpers cannot be
+added to by modules. However, modules can expose functionality to BPF programs
+by exporting kfuncs (which may return pointers to module-internal data
+structures as kptrs).
Q: Directly calling kernel function is an ABI?
----------------------------------------------
@@ -278,7 +282,8 @@ kernel functions have already been used by other kernel tcp
cc (congestion-control) implementations. If any of these kernel
functions has changed, both the in-tree and out-of-tree kernel tcp cc
implementations have to be changed. The same goes for the bpf
-programs and they have to be adjusted accordingly.
+programs and they have to be adjusted accordingly. See
+:ref:`BPF_kfunc_lifecycle_expectations` for details.
Q: Attaching to arbitrary kernel functions is an ABI?
-----------------------------------------------------
@@ -298,3 +303,49 @@ A: NO.
The BTF_ID macro does not cause a function to become part of the ABI
any more than does the EXPORT_SYMBOL_GPL macro.
+
+Q: What is the compatibility story for special BPF types in map values?
+-----------------------------------------------------------------------
+Q: Users are allowed to embed bpf_spin_lock, bpf_timer fields in their BPF map
+values (when using BTF support for BPF maps). This allows to use helpers for
+such objects on these fields inside map values. Users are also allowed to embed
+pointers to some kernel types (with __kptr_untrusted and __kptr BTF tags). Will the
+kernel preserve backwards compatibility for these features?
+
+A: It depends. For bpf_spin_lock, bpf_timer: YES, for kptr and everything else:
+NO, but see below.
+
+For struct types that have been added already, like bpf_spin_lock and bpf_timer,
+the kernel will preserve backwards compatibility, as they are part of UAPI.
+
+For kptrs, they are also part of UAPI, but only with respect to the kptr
+mechanism. The types that you can use with a __kptr_untrusted and __kptr tagged
+pointer in your struct are NOT part of the UAPI contract. The supported types can
+and will change across kernel releases. However, operations like accessing kptr
+fields and bpf_kptr_xchg() helper will continue to be supported across kernel
+releases for the supported types.
+
+For any other supported struct type, unless explicitly stated in this document
+and added to bpf.h UAPI header, such types can and will arbitrarily change their
+size, type, and alignment, or any other user visible API or ABI detail across
+kernel releases. The users must adapt their BPF programs to the new changes and
+update them to make sure their programs continue to work correctly.
+
+NOTE: BPF subsystem specially reserves the 'bpf\_' prefix for type names, in
+order to introduce more special fields in the future. Hence, user programs must
+avoid defining types with 'bpf\_' prefix to not be broken in future releases.
+In other words, no backwards compatibility is guaranteed if one using a type
+in BTF with 'bpf\_' prefix.
+
+Q: What is the compatibility story for special BPF types in allocated objects?
+------------------------------------------------------------------------------
+Q: Same as above, but for allocated objects (i.e. objects allocated using
+bpf_obj_new for user defined types). Will the kernel preserve backwards
+compatibility for these features?
+
+A: NO.
+
+Unlike map value types, the API to work with allocated objects and any support
+for special fields inside them is exposed through kfuncs, and thus has the same
+lifecycle expectations as the kfuncs themselves. See
+:ref:`BPF_kfunc_lifecycle_expectations` for details.
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
index 761474bd7fe6..45bc5c5cd793 100644
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@ -7,8 +7,8 @@ workflows related to reporting bugs, submitting patches, and queueing
patches for stable kernels.
For general information about submitting patches, please refer to
-`Documentation/process/`_. This document only describes additional specifics
-related to BPF.
+Documentation/process/submitting-patches.rst. This document only describes
+additional specifics related to BPF.
.. contents::
:local:
@@ -44,6 +44,33 @@ is a guarantee that the reported issue will be overlooked.**
Submitting patches
==================
+Q: How do I run BPF CI on my changes before sending them out for review?
+------------------------------------------------------------------------
+A: BPF CI is GitHub based and hosted at https://github.com/kernel-patches/bpf.
+While GitHub also provides a CLI that can be used to accomplish the same
+results, here we focus on the UI based workflow.
+
+The following steps lay out how to start a CI run for your patches:
+
+- Create a fork of the aforementioned repository in your own account (one time
+ action)
+
+- Clone the fork locally, check out a new branch tracking either the bpf-next
+ or bpf branch, and apply your to-be-tested patches on top of it
+
+- Push the local branch to your fork and create a pull request against
+ kernel-patches/bpf's bpf-next_base or bpf_base branch, respectively
+
+Shortly after the pull request has been created, the CI workflow will run. Note
+that capacity is shared with patches submitted upstream being checked and so
+depending on utilization the run can take a while to finish.
+
+Note furthermore that both base branches (bpf-next_base and bpf_base) will be
+updated as patches are pushed to the respective upstream branches they track. As
+such, your patch set will automatically (be attempted to) be rebased as well.
+This behavior can result in a CI run being aborted and restarted with the new
+base line.
+
Q: To which mailing list do I need to submit my BPF patches?
------------------------------------------------------------
A: Please submit your BPF patches to the bpf kernel mailing list:
@@ -101,7 +128,8 @@ into the bpf-next tree will make their way into net-next tree. net and
net-next are both run by David S. Miller. From there, they will go
into the kernel mainline tree run by Linus Torvalds. To read up on the
process of net and net-next being merged into the mainline tree, see
-the :ref:`netdev-FAQ`
+the documentation on netdev subsystem at
+Documentation/process/maintainer-netdev.rst.
@@ -120,7 +148,8 @@ request)::
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
---------------------------------------------------------------------------------
-A: The process is the very same as described in the :ref:`netdev-FAQ`,
+A: The process is the very same as described in the netdev subsystem
+documentation at Documentation/process/maintainer-netdev.rst,
so please read up on it. The subject line must indicate whether the
patch is a fix or rather "next-like" content in order to let the
maintainers know whether it is targeted at bpf or bpf-next.
@@ -179,8 +208,9 @@ ii) run extensive BPF test suite and
Once the BPF pull request was accepted by David S. Miller, then
the patches end up in net or net-next tree, respectively, and
make their way from there further into mainline. Again, see the
-:ref:`netdev-FAQ` for additional information e.g. on how often they are
-merged to mainline.
+documentation for netdev subsystem at
+Documentation/process/maintainer-netdev.rst for additional information
+e.g. on how often they are merged to mainline.
Q: How long do I need to wait for feedback on my BPF patches?
-------------------------------------------------------------
@@ -203,7 +233,8 @@ Q: Are patches applied to bpf-next when the merge window is open?
-----------------------------------------------------------------
A: For the time when the merge window is open, bpf-next will not be
processed. This is roughly analogous to net-next patch processing,
-so feel free to read up on the :ref:`netdev-FAQ` about further details.
+so feel free to read up on the netdev docs at
+Documentation/process/maintainer-netdev.rst about further details.
During those two weeks of merge window, we might ask you to resend
your patch series once bpf-next is open again. Once Linus released
@@ -351,6 +382,14 @@ In case of new BPF instructions, once the changes have been accepted
into the Linux kernel, please implement support into LLVM's BPF back
end. See LLVM_ section below for further information.
+Q: What "BPF_INTERNAL" symbol namespace is for?
+-----------------------------------------------
+A: Symbols exported as BPF_INTERNAL can only be used by BPF infrastructure
+like preload kernel modules with light skeleton. Most symbols outside
+of BPF_INTERNAL are not expected to be used by code outside of BPF either.
+Symbols may lack the designation because they predate the namespaces,
+or due to an oversight.
+
Stable submission
=================
@@ -367,7 +406,8 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
netdev@vger.kernel.org
The process in general is the same as on netdev itself, see also the
-:ref:`netdev-FAQ`.
+the documentation on networking subsystem at
+Documentation/process/maintainer-netdev.rst.
Q: Do you also backport to kernels not currently maintained as stable?
----------------------------------------------------------------------
@@ -383,7 +423,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
What should I do?
A: The same rules apply as with netdev patch submissions in general, see
-the :ref:`netdev-FAQ`.
+the netdev docs at Documentation/process/maintainer-netdev.rst.
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
ask the BPF maintainers to queue the patches instead. This can be done
@@ -434,15 +474,15 @@ needed::
$ sudo make run_tests
-See the kernels selftest `Documentation/dev-tools/kselftest.rst`_
-document for further documentation.
+See :doc:`kernel selftest documentation </dev-tools/kselftest>`
+for details.
To maximize the number of tests passing, the .config of the kernel
under test should match the config file fragment in
tools/testing/selftests/bpf as closely as possible.
Finally to ensure support for latest BPF Type Format features -
-discussed in `Documentation/bpf/btf.rst`_ - pahole version 1.16
+discussed in Documentation/bpf/btf.rst - pahole version 1.16
is required for kernels built with CONFIG_DEBUG_INFO_BTF=y.
pahole is delivered in the dwarves package or can be built
from source at
@@ -571,9 +611,10 @@ Q: I have added a new BPF instruction to the kernel, how can I integrate
it into LLVM?
A: LLVM has a ``-mcpu`` selector for the BPF back end in order to allow
-the selection of BPF instruction set extensions. By default the
-``generic`` processor target is used, which is the base instruction set
-(v1) of BPF.
+the selection of BPF instruction set extensions. Before llvm version 20,
+the ``generic`` processor target is used, which is the base instruction
+set (v1) of BPF. Since llvm 20, the default processor target has changed
+to instruction set v3.
LLVM has an option to select ``-mcpu=probe`` where it will probe the host
kernel for supported BPF instruction set extensions and selects the
@@ -603,12 +644,12 @@ test coverage.
Q: clang flag for target bpf?
-----------------------------
-Q: In some cases clang flag ``-target bpf`` is used but in other cases the
+Q: In some cases clang flag ``--target=bpf`` is used but in other cases the
default clang target, which matches the underlying architecture, is used.
What is the difference and when I should use which?
A: Although LLVM IR generation and optimization try to stay architecture
-independent, ``-target <arch>`` still has some impact on generated code:
+independent, ``--target=<arch>`` still has some impact on generated code:
- BPF program may recursively include header file(s) with file scope
inline assembly codes. The default target can handle this well,
@@ -626,7 +667,7 @@ independent, ``-target <arch>`` still has some impact on generated code:
The clang option ``-fno-jump-tables`` can be used to disable
switch table generation.
-- For clang ``-target bpf``, it is guaranteed that pointer or long /
+- For clang ``--target=bpf``, it is guaranteed that pointer or long /
unsigned long types will always have a width of 64 bit, no matter
whether underlying clang binary or default target (or kernel) is
32 bit. However, when native clang target is used, then it will
@@ -636,7 +677,7 @@ independent, ``-target <arch>`` still has some impact on generated code:
while the BPF LLVM back end still operates in 64 bit. The native
target is mostly needed in tracing for the case of walking ``pt_regs``
or other kernel structures where CPU's register width matters.
- Otherwise, ``clang -target bpf`` is generally recommended.
+ Otherwise, ``clang --target=bpf`` is generally recommended.
You should use default target when:
@@ -653,16 +694,11 @@ when:
into these structures is verified by the BPF verifier and may result
in verification failures if the native architecture is not aligned with
the BPF architecture, e.g. 64-bit. An example of this is
- BPF_PROG_TYPE_SK_MSG require ``-target bpf``
+ BPF_PROG_TYPE_SK_MSG require ``--target=bpf``
.. Links
-.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
-.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
.. _selftests:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
-.. _Documentation/dev-tools/kselftest.rst:
- https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
-.. _Documentation/bpf/btf.rst: btf.rst
Happy BPF hacking!
diff --git a/Documentation/bpf/bpf_iterators.rst b/Documentation/bpf/bpf_iterators.rst
new file mode 100644
index 000000000000..189e3ec1c6c8
--- /dev/null
+++ b/Documentation/bpf/bpf_iterators.rst
@@ -0,0 +1,589 @@
+=============
+BPF Iterators
+=============
+
+--------
+Overview
+--------
+
+BPF supports two separate entities collectively known as "BPF iterators": BPF
+iterator *program type* and *open-coded* BPF iterators. The former is
+a stand-alone BPF program type which, when attached and activated by user,
+will be called once for each entity (task_struct, cgroup, etc) that is being
+iterated. The latter is a set of BPF-side APIs implementing iterator
+functionality and available across multiple BPF program types. Open-coded
+iterators provide similar functionality to BPF iterator programs, but gives
+more flexibility and control to all other BPF program types. BPF iterator
+programs, on the other hand, can be used to implement anonymous or BPF
+FS-mounted special files, whose contents are generated by attached BPF iterator
+program, backed by seq_file functionality. Both are useful depending on
+specific needs.
+
+When adding a new BPF iterator program, it is expected that similar
+functionality will be added as open-coded iterator for maximum flexibility.
+It's also expected that iteration logic and code will be maximally shared and
+reused between two iterator API surfaces.
+
+------------------------
+Open-coded BPF Iterators
+------------------------
+
+Open-coded BPF iterators are implemented as tightly-coupled trios of kfuncs
+(constructor, next element fetch, destructor) and iterator-specific type
+describing on-the-stack iterator state, which is guaranteed by the BPF
+verifier to not be tampered with outside of the corresponding
+constructor/destructor/next APIs.
+
+Each kind of open-coded BPF iterator has its own associated
+struct bpf_iter_<type>, where <type> denotes a specific type of iterator.
+bpf_iter_<type> state needs to live on BPF program stack, so make sure it's
+small enough to fit on BPF stack. For performance reasons its best to avoid
+dynamic memory allocation for iterator state and size the state struct big
+enough to fit everything necessary. But if necessary, dynamic memory
+allocation is a way to bypass BPF stack limitations. Note, state struct size
+is part of iterator's user-visible API, so changing it will break backwards
+compatibility, so be deliberate about designing it.
+
+All kfuncs (constructor, next, destructor) have to be named consistently as
+bpf_iter_<type>_{new,next,destroy}(), respectively. <type> represents iterator
+type, and iterator state should be represented as a matching
+`struct bpf_iter_<type>` state type. Also, all iter kfuncs should have
+a pointer to this `struct bpf_iter_<type>` as the very first argument.
+
+Additionally:
+ - Constructor, i.e., `bpf_iter_<type>_new()`, can have arbitrary extra
+ number of arguments. Return type is not enforced either.
+ - Next method, i.e., `bpf_iter_<type>_next()`, has to return a pointer
+ type and should have exactly one argument: `struct bpf_iter_<type> *`
+ (const/volatile/restrict and typedefs are ignored).
+ - Destructor, i.e., `bpf_iter_<type>_destroy()`, should return void and
+ should have exactly one argument, similar to the next method.
+ - `struct bpf_iter_<type>` size is enforced to be positive and
+ a multiple of 8 bytes (to fit stack slots correctly).
+
+Such strictness and consistency allows to build generic helpers abstracting
+important, but boilerplate, details to be able to use open-coded iterators
+effectively and ergonomically (see libbpf's bpf_for_each() macro). This is
+enforced at kfunc registration point by the kernel.
+
+Constructor/next/destructor implementation contract is as follows:
+ - constructor, `bpf_iter_<type>_new()`, always initializes iterator state on
+ the stack. If any of the input arguments are invalid, constructor should
+ make sure to still initialize it such that subsequent next() calls will
+ return NULL. I.e., on error, *return error and construct empty iterator*.
+ Constructor kfunc is marked with KF_ITER_NEW flag.
+
+ - next method, `bpf_iter_<type>_next()`, accepts pointer to iterator state
+ and produces an element. Next method should always return a pointer. The
+ contract between BPF verifier is that next method *guarantees* that it
+ will eventually return NULL when elements are exhausted. Once NULL is
+ returned, subsequent next calls *should keep returning NULL*. Next method
+ is marked with KF_ITER_NEXT (and should also have KF_RET_NULL as
+ NULL-returning kfunc, of course).
+
+ - destructor, `bpf_iter_<type>_destroy()`, is always called once. Even if
+ constructor failed or next returned nothing. Destructor frees up any
+ resources and marks stack space used by `struct bpf_iter_<type>` as usable
+ for something else. Destructor is marked with KF_ITER_DESTROY flag.
+
+Any open-coded BPF iterator implementation has to implement at least these
+three methods. It is enforced that for any given type of iterator only
+applicable constructor/destructor/next are callable. I.e., verifier ensures
+you can't pass number iterator state into, say, cgroup iterator's next method.
+
+From a 10,000-feet BPF verification point of view, next methods are the points
+of forking a verification state, which are conceptually similar to what
+verifier is doing when validating conditional jumps. Verifier is branching out
+`call bpf_iter_<type>_next` instruction and simulates two outcomes: NULL
+(iteration is done) and non-NULL (new element is returned). NULL is simulated
+first and is supposed to reach exit without looping. After that non-NULL case
+is validated and it either reaches exit (for trivial examples with no real
+loop), or reaches another `call bpf_iter_<type>_next` instruction with the
+state equivalent to already (partially) validated one. State equivalency at
+that point means we technically are going to be looping forever without
+"breaking out" out of established "state envelope" (i.e., subsequent
+iterations don't add any new knowledge or constraints to the verifier state,
+so running 1, 2, 10, or a million of them doesn't matter). But taking into
+account the contract stating that iterator next method *has to* return NULL
+eventually, we can conclude that loop body is safe and will eventually
+terminate. Given we validated logic outside of the loop (NULL case), and
+concluded that loop body is safe (though potentially looping many times),
+verifier can claim safety of the overall program logic.
+
+------------------------
+BPF Iterators Motivation
+------------------------
+
+There are a few existing ways to dump kernel data into user space. The most
+popular one is the ``/proc`` system. For example, ``cat /proc/net/tcp6`` dumps
+all tcp6 sockets in the system, and ``cat /proc/net/netlink`` dumps all netlink
+sockets in the system. However, their output format tends to be fixed, and if
+users want more information about these sockets, they have to patch the kernel,
+which often takes time to publish upstream and release. The same is true for popular
+tools like `ss <https://man7.org/linux/man-pages/man8/ss.8.html>`_ where any
+additional information needs a kernel patch.
+
+To solve this problem, the `drgn
+<https://www.kernel.org/doc/html/latest/bpf/drgn.html>`_ tool is often used to
+dig out the kernel data with no kernel change. However, the main drawback for
+drgn is performance, as it cannot do pointer tracing inside the kernel. In
+addition, drgn cannot validate a pointer value and may read invalid data if the
+pointer becomes invalid inside the kernel.
+
+The BPF iterator solves the above problem by providing flexibility on what data
+(e.g., tasks, bpf_maps, etc.) to collect by calling BPF programs for each kernel
+data object.
+
+----------------------
+How BPF Iterators Work
+----------------------
+
+A BPF iterator is a type of BPF program that allows users to iterate over
+specific types of kernel objects. Unlike traditional BPF tracing programs that
+allow users to define callbacks that are invoked at particular points of
+execution in the kernel, BPF iterators allow users to define callbacks that
+should be executed for every entry in a variety of kernel data structures.
+
+For example, users can define a BPF iterator that iterates over every task on
+the system and dumps the total amount of CPU runtime currently used by each of
+them. Another BPF task iterator may instead dump the cgroup information for each
+task. Such flexibility is the core value of BPF iterators.
+
+A BPF program is always loaded into the kernel at the behest of a user space
+process. A user space process loads a BPF program by opening and initializing
+the program skeleton as required and then invoking a syscall to have the BPF
+program verified and loaded by the kernel.
+
+In traditional tracing programs, a program is activated by having user space
+obtain a ``bpf_link`` to the program with ``bpf_program__attach()``. Once
+activated, the program callback will be invoked whenever the tracepoint is
+triggered in the main kernel. For BPF iterator programs, a ``bpf_link`` to the
+program is obtained using ``bpf_link_create()``, and the program callback is
+invoked by issuing system calls from user space.
+
+Next, let us see how you can use the iterators to iterate on kernel objects and
+read data.
+
+------------------------
+How to Use BPF iterators
+------------------------
+
+BPF selftests are a great resource to illustrate how to use the iterators. In
+this section, we’ll walk through a BPF selftest which shows how to load and use
+a BPF iterator program. To begin, we’ll look at `bpf_iter.c
+<https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/prog_tests/bpf_iter.c>`_,
+which illustrates how to load and trigger BPF iterators on the user space side.
+Later, we’ll look at a BPF program that runs in kernel space.
+
+Loading a BPF iterator in the kernel from user space typically involves the
+following steps:
+
+* The BPF program is loaded into the kernel through ``libbpf``. Once the kernel
+ has verified and loaded the program, it returns a file descriptor (fd) to user
+ space.
+* Obtain a ``link_fd`` to the BPF program by calling the ``bpf_link_create()``
+ specified with the BPF program file descriptor received from the kernel.
+* Next, obtain a BPF iterator file descriptor (``bpf_iter_fd``) by calling the
+ ``bpf_iter_create()`` specified with the ``bpf_link`` received from Step 2.
+* Trigger the iteration by calling ``read(bpf_iter_fd)`` until no data is
+ available.
+* Close the iterator fd using ``close(bpf_iter_fd)``.
+* If needed to reread the data, get a new ``bpf_iter_fd`` and do the read again.
+
+The following are a few examples of selftest BPF iterator programs:
+
+* `bpf_iter_tcp4.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_tcp4.c>`_
+* `bpf_iter_task_vmas.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_task_vmas.c>`_
+* `bpf_iter_task_file.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_task_file.c>`_
+
+Let us look at ``bpf_iter_task_file.c``, which runs in kernel space:
+
+Here is the definition of ``bpf_iter__task_file`` in `vmlinux.h
+<https://facebookmicrosites.github.io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html#btf>`_.
+Any struct name in ``vmlinux.h`` in the format ``bpf_iter__<iter_name>``
+represents a BPF iterator. The suffix ``<iter_name>`` represents the type of
+iterator.
+
+::
+
+ struct bpf_iter__task_file {
+ union {
+ struct bpf_iter_meta *meta;
+ };
+ union {
+ struct task_struct *task;
+ };
+ u32 fd;
+ union {
+ struct file *file;
+ };
+ };
+
+In the above code, the field 'meta' contains the metadata, which is the same for
+all BPF iterator programs. The rest of the fields are specific to different
+iterators. For example, for task_file iterators, the kernel layer provides the
+'task', 'fd' and 'file' field values. The 'task' and 'file' are `reference
+counted
+<https://facebookmicrosites.github.io/bpf/blog/2018/08/31/object-lifetime.html#file-descriptors-and-reference-counters>`_,
+so they won't go away when the BPF program runs.
+
+Here is a snippet from the ``bpf_iter_task_file.c`` file:
+
+::
+
+ SEC("iter/task_file")
+ int dump_task_file(struct bpf_iter__task_file *ctx)
+ {
+ struct seq_file *seq = ctx->meta->seq;
+ struct task_struct *task = ctx->task;
+ struct file *file = ctx->file;
+ __u32 fd = ctx->fd;
+
+ if (task == NULL || file == NULL)
+ return 0;
+
+ if (ctx->meta->seq_num == 0) {
+ count = 0;
+ BPF_SEQ_PRINTF(seq, " tgid gid fd file\n");
+ }
+
+ if (tgid == task->tgid && task->tgid != task->pid)
+ count++;
+
+ if (last_tgid != task->tgid) {
+ last_tgid = task->tgid;
+ unique_tgid_count++;
+ }
+
+ BPF_SEQ_PRINTF(seq, "%8d %8d %8d %lx\n", task->tgid, task->pid, fd,
+ (long)file->f_op);
+ return 0;
+ }
+
+In the above example, the section name ``SEC(iter/task_file)``, indicates that
+the program is a BPF iterator program to iterate all files from all tasks. The
+context of the program is ``bpf_iter__task_file`` struct.
+
+The user space program invokes the BPF iterator program running in the kernel
+by issuing a ``read()`` syscall. Once invoked, the BPF
+program can export data to user space using a variety of BPF helper functions.
+You can use either ``bpf_seq_printf()`` (and BPF_SEQ_PRINTF helper macro) or
+``bpf_seq_write()`` function based on whether you need formatted output or just
+binary data, respectively. For binary-encoded data, the user space applications
+can process the data from ``bpf_seq_write()`` as needed. For the formatted data,
+you can use ``cat <path>`` to print the results similar to ``cat
+/proc/net/netlink`` after pinning the BPF iterator to the bpffs mount. Later,
+use ``rm -f <path>`` to remove the pinned iterator.
+
+For example, you can use the following command to create a BPF iterator from the
+``bpf_iter_ipv6_route.o`` object file and pin it to the ``/sys/fs/bpf/my_route``
+path:
+
+::
+
+ $ bpftool iter pin ./bpf_iter_ipv6_route.o /sys/fs/bpf/my_route
+
+And then print out the results using the following command:
+
+::
+
+ $ cat /sys/fs/bpf/my_route
+
+
+-------------------------------------------------------
+Implement Kernel Support for BPF Iterator Program Types
+-------------------------------------------------------
+
+To implement a BPF iterator in the kernel, the developer must make a one-time
+change to the following key data structure defined in the `bpf.h
+<https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/include/linux/bpf.h>`_
+file.
+
+::
+
+ struct bpf_iter_reg {
+ const char *target;
+ bpf_iter_attach_target_t attach_target;
+ bpf_iter_detach_target_t detach_target;
+ bpf_iter_show_fdinfo_t show_fdinfo;
+ bpf_iter_fill_link_info_t fill_link_info;
+ bpf_iter_get_func_proto_t get_func_proto;
+ u32 ctx_arg_info_size;
+ u32 feature;
+ struct bpf_ctx_arg_aux ctx_arg_info[BPF_ITER_CTX_ARG_MAX];
+ const struct bpf_iter_seq_info *seq_info;
+ };
+
+After filling the data structure fields, call ``bpf_iter_reg_target()`` to
+register the iterator to the main BPF iterator subsystem.
+
+The following is the breakdown for each field in struct ``bpf_iter_reg``.
+
+.. list-table::
+ :widths: 25 50
+ :header-rows: 1
+
+ * - Fields
+ - Description
+ * - target
+ - Specifies the name of the BPF iterator. For example: ``bpf_map``,
+ ``bpf_map_elem``. The name should be different from other ``bpf_iter`` target names in the kernel.
+ * - attach_target and detach_target
+ - Allows for target specific ``link_create`` action since some targets
+ may need special processing. Called during the user space link_create stage.
+ * - show_fdinfo and fill_link_info
+ - Called to fill target specific information when user tries to get link
+ info associated with the iterator.
+ * - get_func_proto
+ - Permits a BPF iterator to access BPF helpers specific to the iterator.
+ * - ctx_arg_info_size and ctx_arg_info
+ - Specifies the verifier states for BPF program arguments associated with
+ the bpf iterator.
+ * - feature
+ - Specifies certain action requests in the kernel BPF iterator
+ infrastructure. Currently, only BPF_ITER_RESCHED is supported. This means
+ that the kernel function cond_resched() is called to avoid other kernel
+ subsystem (e.g., rcu) misbehaving.
+ * - seq_info
+ - Specifies the set of seq operations for the BPF iterator and helpers to
+ initialize/free the private data for the corresponding ``seq_file``.
+
+`Click here
+<https://lore.kernel.org/bpf/20210212183107.50963-2-songliubraving@fb.com/>`_
+to see an implementation of the ``task_vma`` BPF iterator in the kernel.
+
+---------------------------------
+Parameterizing BPF Task Iterators
+---------------------------------
+
+By default, BPF iterators walk through all the objects of the specified types
+(processes, cgroups, maps, etc.) across the entire system to read relevant
+kernel data. But often, there are cases where we only care about a much smaller
+subset of iterable kernel objects, such as only iterating tasks within a
+specific process. Therefore, BPF iterator programs support filtering out objects
+from iteration by allowing user space to configure the iterator program when it
+is attached.
+
+--------------------------
+BPF Task Iterator Program
+--------------------------
+
+The following code is a BPF iterator program to print files and task information
+through the ``seq_file`` of the iterator. It is a standard BPF iterator program
+that visits every file of an iterator. We will use this BPF program in our
+example later.
+
+::
+
+ #include <vmlinux.h>
+ #include <bpf/bpf_helpers.h>
+
+ char _license[] SEC("license") = "GPL";
+
+ SEC("iter/task_file")
+ int dump_task_file(struct bpf_iter__task_file *ctx)
+ {
+ struct seq_file *seq = ctx->meta->seq;
+ struct task_struct *task = ctx->task;
+ struct file *file = ctx->file;
+ __u32 fd = ctx->fd;
+ if (task == NULL || file == NULL)
+ return 0;
+ if (ctx->meta->seq_num == 0) {
+ BPF_SEQ_PRINTF(seq, " tgid pid fd file\n");
+ }
+ BPF_SEQ_PRINTF(seq, "%8d %8d %8d %lx\n", task->tgid, task->pid, fd,
+ (long)file->f_op);
+ return 0;
+ }
+
+----------------------------------------
+Creating a File Iterator with Parameters
+----------------------------------------
+
+Now, let us look at how to create an iterator that includes only files of a
+process.
+
+First, fill the ``bpf_iter_attach_opts`` struct as shown below:
+
+::
+
+ LIBBPF_OPTS(bpf_iter_attach_opts, opts);
+ union bpf_iter_link_info linfo;
+ memset(&linfo, 0, sizeof(linfo));
+ linfo.task.pid = getpid();
+ opts.link_info = &linfo;
+ opts.link_info_len = sizeof(linfo);
+
+``linfo.task.pid``, if it is non-zero, directs the kernel to create an iterator
+that only includes opened files for the process with the specified ``pid``. In
+this example, we will only be iterating files for our process. If
+``linfo.task.pid`` is zero, the iterator will visit every opened file of every
+process. Similarly, ``linfo.task.tid`` directs the kernel to create an iterator
+that visits opened files of a specific thread, not a process. In this example,
+``linfo.task.tid`` is different from ``linfo.task.pid`` only if the thread has a
+separate file descriptor table. In most circumstances, all process threads share
+a single file descriptor table.
+
+Now, in the userspace program, pass the pointer of struct to the
+``bpf_program__attach_iter()``.
+
+::
+
+ link = bpf_program__attach_iter(prog, &opts);
+ iter_fd = bpf_iter_create(bpf_link__fd(link));
+
+If both *tid* and *pid* are zero, an iterator created from this struct
+``bpf_iter_attach_opts`` will include every opened file of every task in the
+system (in the namespace, actually.) It is the same as passing a NULL as the
+second argument to ``bpf_program__attach_iter()``.
+
+The whole program looks like the following code:
+
+::
+
+ #include <stdio.h>
+ #include <unistd.h>
+ #include <bpf/bpf.h>
+ #include <bpf/libbpf.h>
+ #include "bpf_iter_task_ex.skel.h"
+
+ static int do_read_opts(struct bpf_program *prog, struct bpf_iter_attach_opts *opts)
+ {
+ struct bpf_link *link;
+ char buf[16] = {};
+ int iter_fd = -1, len;
+ int ret = 0;
+
+ link = bpf_program__attach_iter(prog, opts);
+ if (!link) {
+ fprintf(stderr, "bpf_program__attach_iter() fails\n");
+ return -1;
+ }
+ iter_fd = bpf_iter_create(bpf_link__fd(link));
+ if (iter_fd < 0) {
+ fprintf(stderr, "bpf_iter_create() fails\n");
+ ret = -1;
+ goto free_link;
+ }
+ /* not check contents, but ensure read() ends without error */
+ while ((len = read(iter_fd, buf, sizeof(buf) - 1)) > 0) {
+ buf[len] = 0;
+ printf("%s", buf);
+ }
+ printf("\n");
+ free_link:
+ if (iter_fd >= 0)
+ close(iter_fd);
+ bpf_link__destroy(link);
+ return 0;
+ }
+
+ static void test_task_file(void)
+ {
+ LIBBPF_OPTS(bpf_iter_attach_opts, opts);
+ struct bpf_iter_task_ex *skel;
+ union bpf_iter_link_info linfo;
+ skel = bpf_iter_task_ex__open_and_load();
+ if (skel == NULL)
+ return;
+ memset(&linfo, 0, sizeof(linfo));
+ linfo.task.pid = getpid();
+ opts.link_info = &linfo;
+ opts.link_info_len = sizeof(linfo);
+ printf("PID %d\n", getpid());
+ do_read_opts(skel->progs.dump_task_file, &opts);
+ bpf_iter_task_ex__destroy(skel);
+ }
+
+ int main(int argc, const char * const * argv)
+ {
+ test_task_file();
+ return 0;
+ }
+
+The following lines are the output of the program.
+::
+
+ PID 1859
+
+ tgid pid fd file
+ 1859 1859 0 ffffffff82270aa0
+ 1859 1859 1 ffffffff82270aa0
+ 1859 1859 2 ffffffff82270aa0
+ 1859 1859 3 ffffffff82272980
+ 1859 1859 4 ffffffff8225e120
+ 1859 1859 5 ffffffff82255120
+ 1859 1859 6 ffffffff82254f00
+ 1859 1859 7 ffffffff82254d80
+ 1859 1859 8 ffffffff8225abe0
+
+------------------
+Without Parameters
+------------------
+
+Let us look at how a BPF iterator without parameters skips files of other
+processes in the system. In this case, the BPF program has to check the pid or
+the tid of tasks, or it will receive every opened file in the system (in the
+current *pid* namespace, actually). So, we usually add a global variable in the
+BPF program to pass a *pid* to the BPF program.
+
+The BPF program would look like the following block.
+
+ ::
+
+ ......
+ int target_pid = 0;
+
+ SEC("iter/task_file")
+ int dump_task_file(struct bpf_iter__task_file *ctx)
+ {
+ ......
+ if (task->tgid != target_pid) /* Check task->pid instead to check thread IDs */
+ return 0;
+ BPF_SEQ_PRINTF(seq, "%8d %8d %8d %lx\n", task->tgid, task->pid, fd,
+ (long)file->f_op);
+ return 0;
+ }
+
+The user space program would look like the following block:
+
+ ::
+
+ ......
+ static void test_task_file(void)
+ {
+ ......
+ skel = bpf_iter_task_ex__open_and_load();
+ if (skel == NULL)
+ return;
+ skel->bss->target_pid = getpid(); /* process ID. For thread id, use gettid() */
+ memset(&linfo, 0, sizeof(linfo));
+ linfo.task.pid = getpid();
+ opts.link_info = &linfo;
+ opts.link_info_len = sizeof(linfo);
+ ......
+ }
+
+``target_pid`` is a global variable in the BPF program. The user space program
+should initialize the variable with a process ID to skip opened files of other
+processes in the BPF program. When you parametrize a BPF iterator, the iterator
+calls the BPF program fewer times which can save significant resources.
+
+---------------------------
+Parametrizing VMA Iterators
+---------------------------
+
+By default, a BPF VMA iterator includes every VMA in every process. However,
+you can still specify a process or a thread to include only its VMAs. Unlike
+files, a thread can not have a separate address space (since Linux 2.6.0-test6).
+Here, using *tid* makes no difference from using *pid*.
+
+----------------------------
+Parametrizing Task Iterators
+----------------------------
+
+A BPF task iterator with *pid* includes all tasks (threads) of a process. The
+BPF program receives these tasks one after another. You can specify a BPF task
+iterator with *tid* parameter to include only the tasks that match the given
+*tid*.
diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
index cf8722f96090..3b60583f5db2 100644
--- a/Documentation/bpf/btf.rst
+++ b/Documentation/bpf/btf.rst
@@ -102,7 +102,8 @@ Each type contains the following common data::
* bits 24-28: kind (e.g. int, ptr, array...etc)
* bits 29-30: unused
* bit 31: kind_flag, currently used by
- * struct, union, fwd, enum and enum64.
+ * struct, union, enum, fwd, enum64,
+ * decl_tag and type_tag
*/
__u32 info;
/* "size" is used by INT, ENUM, STRUCT, UNION and ENUM64.
@@ -272,10 +273,8 @@ In this case, if the base type is an int type, it must be a regular int type:
* ``BTF_INT_OFFSET()`` must be 0.
* ``BTF_INT_BITS()`` must be equal to ``{1,2,4,8,16} * 8``.
-The following kernel patch introduced ``kind_flag`` and explained why both
-modes exist:
-
- https://github.com/torvalds/linux/commit/9d5f9f701b1891466fb3dbb1806ad97716f95cc3#diff-fa650a64fdd3968396883d2fe8215ff3
+Commit 9d5f9f701b18 introduced ``kind_flag`` and explains why both modes
+exist.
2.2.6 BTF_KIND_ENUM
~~~~~~~~~~~~~~~~~~~
@@ -370,7 +369,7 @@ No additional type data follow ``btf_type``.
* ``info.kind_flag``: 0
* ``info.kind``: BTF_KIND_FUNC
* ``info.vlen``: linkage information (BTF_FUNC_STATIC, BTF_FUNC_GLOBAL
- or BTF_FUNC_EXTERN)
+ or BTF_FUNC_EXTERN - see :ref:`BTF_Function_Linkage_Constants`)
* ``type``: a BTF_KIND_FUNC_PROTO type
No additional type data follow ``btf_type``.
@@ -426,9 +425,8 @@ following data::
__u32 linkage;
};
-``struct btf_var`` encoding:
- * ``linkage``: currently only static variable 0, or globally allocated
- variable in ELF sections 1
+``btf_var.linkage`` may take the values: BTF_VAR_STATIC, BTF_VAR_GLOBAL_ALLOCATED or BTF_VAR_GLOBAL_EXTERN -
+see :ref:`BTF_Var_Linkage_Constants`.
Not all type of global variables are supported by LLVM at this point.
The following is currently available:
@@ -481,7 +479,7 @@ No additional type data follow ``btf_type``.
``struct btf_type`` encoding requirement:
* ``name_off``: offset to a non-empty string
- * ``info.kind_flag``: 0
+ * ``info.kind_flag``: 0 or 1
* ``info.kind``: BTF_KIND_DECL_TAG
* ``info.vlen``: 0
* ``type``: ``struct``, ``union``, ``func``, ``var`` or ``typedef``
@@ -492,7 +490,6 @@ No additional type data follow ``btf_type``.
__u32 component_idx;
};
-The ``name_off`` encodes btf_decl_tag attribute string.
The ``type`` should be ``struct``, ``union``, ``func``, ``var`` or ``typedef``.
For ``var`` or ``typedef`` type, ``btf_decl_tag.component_idx`` must be ``-1``.
For the other three types, if the btf_decl_tag attribute is
@@ -502,12 +499,21 @@ the attribute is applied to a ``struct``/``union`` member or
a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a
valid index (starting from 0) pointing to a member or an argument.
+If ``info.kind_flag`` is 0, then this is a normal decl tag, and the
+``name_off`` encodes btf_decl_tag attribute string.
+
+If ``info.kind_flag`` is 1, then the decl tag represents an arbitrary
+__attribute__. In this case, ``name_off`` encodes a string
+representing the attribute-list of the attribute specifier. For
+example, for an ``__attribute__((aligned(4)))`` the string's contents
+is ``aligned(4)``.
+
2.2.18 BTF_KIND_TYPE_TAG
~~~~~~~~~~~~~~~~~~~~~~~~
``struct btf_type`` encoding requirement:
* ``name_off``: offset to a non-empty string
- * ``info.kind_flag``: 0
+ * ``info.kind_flag``: 0 or 1
* ``info.kind``: BTF_KIND_TYPE_TAG
* ``info.vlen``: 0
* ``type``: the type with ``btf_type_tag`` attribute
@@ -525,6 +531,14 @@ type_tag, then zero or more const/volatile/restrict/typedef
and finally the base type. The base type is one of
int, ptr, array, struct, union, enum, func_proto and float types.
+Similarly to decl tags, if the ``info.kind_flag`` is 0, then this is a
+normal type tag, and the ``name_off`` encodes btf_type_tag attribute
+string.
+
+If ``info.kind_flag`` is 1, then the type tag represents an arbitrary
+__attribute__, and the ``name_off`` encodes a string representing the
+attribute-list of the attribute specifier.
+
2.2.19 BTF_KIND_ENUM64
~~~~~~~~~~~~~~~~~~~~~~
@@ -551,6 +565,38 @@ The ``btf_enum64`` encoding:
If the original enum value is signed and the size is less than 8,
that value will be sign extended into 8 bytes.
+2.3 Constant Values
+-------------------
+
+.. _BTF_Function_Linkage_Constants:
+
+2.3.1 Function Linkage Constant Values
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. table:: Function Linkage Values and Meanings
+
+ =================== ===== ===========
+ kind value description
+ =================== ===== ===========
+ ``BTF_FUNC_STATIC`` 0x0 definition of subprogram not visible outside containing compilation unit
+ ``BTF_FUNC_GLOBAL`` 0x1 definition of subprogram visible outside containing compilation unit
+ ``BTF_FUNC_EXTERN`` 0x2 declaration of a subprogram whose definition is outside the containing compilation unit
+ =================== ===== ===========
+
+
+.. _BTF_Var_Linkage_Constants:
+
+2.3.2 Variable Linkage Constant Values
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. table:: Variable Linkage Values and Meanings
+
+ ============================ ===== ===========
+ kind value description
+ ============================ ===== ===========
+ ``BTF_VAR_STATIC`` 0x0 definition of global variable not visible outside containing compilation unit
+ ``BTF_VAR_GLOBAL_ALLOCATED`` 0x1 definition of global variable visible outside containing compilation unit
+ ``BTF_VAR_GLOBAL_EXTERN`` 0x2 declaration of global variable whose definition is outside the containing compilation unit
+ ============================ ===== ===========
+
3. BTF Kernel API
=================
@@ -726,8 +772,8 @@ same as the one describe in :ref:`BTF_Type_String`.
4.2 .BTF.ext section
--------------------
-The .BTF.ext section encodes func_info and line_info which needs loader
-manipulation before loading into the kernel.
+The .BTF.ext section encodes func_info, line_info and CO-RE relocations
+which needs loader manipulation before loading into the kernel.
The specification for .BTF.ext section is defined at ``tools/lib/bpf/btf.h``
and ``tools/lib/bpf/btf.c``.
@@ -745,15 +791,20 @@ The current header of .BTF.ext section::
__u32 func_info_len;
__u32 line_info_off;
__u32 line_info_len;
+
+ /* optional part of .BTF.ext header */
+ __u32 core_relo_off;
+ __u32 core_relo_len;
};
It is very similar to .BTF section. Instead of type/string section, it
-contains func_info and line_info section. See :ref:`BPF_Prog_Load` for details
-about func_info and line_info record format.
+contains func_info, line_info and core_relo sub-sections.
+See :ref:`BPF_Prog_Load` for details about func_info and line_info
+record format.
The func_info is organized as below.::
- func_info_rec_size
+ func_info_rec_size /* __u32 value */
btf_ext_info_sec for section #1 /* func_info for section #1 */
btf_ext_info_sec for section #2 /* func_info for section #2 */
...
@@ -773,7 +824,7 @@ Here, num_info must be greater than 0.
The line_info is organized as below.::
- line_info_rec_size
+ line_info_rec_size /* __u32 value */
btf_ext_info_sec for section #1 /* line_info for section #1 */
btf_ext_info_sec for section #2 /* line_info for section #2 */
...
@@ -787,7 +838,21 @@ kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct
bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the
beginning of section (``btf_ext_info_sec->sec_name_off``).
-4.2 .BTF_ids section
+The core_relo is organized as below.::
+
+ core_relo_rec_size /* __u32 value */
+ btf_ext_info_sec for section #1 /* core_relo for section #1 */
+ btf_ext_info_sec for section #2 /* core_relo for section #2 */
+
+``core_relo_rec_size`` specifies the size of ``bpf_core_relo``
+structure when .BTF.ext is generated. All ``bpf_core_relo`` structures
+within a single ``btf_ext_info_sec`` describe relocations applied to
+section named by ``btf_ext_info_sec->sec_name_off``.
+
+See :ref:`Documentation/bpf/llvm_reloc.rst <btf-co-re-relocations>`
+for more information on CO-RE relocations.
+
+4.3 .BTF_ids section
--------------------
The .BTF_ids section encodes BTF ID values that are used within the kernel.
@@ -848,6 +913,81 @@ and is used as a filter when resolving the BTF ID value.
All the BTF ID lists and sets are compiled in the .BTF_ids section and
resolved during the linking phase of kernel build by ``resolve_btfids`` tool.
+4.4 .BTF.base section
+---------------------
+Split BTF - where the .BTF section only contains types not in the associated
+base .BTF section - is an extremely efficient way to encode type information
+for kernel modules, since they generally consist of a few module-specific
+types along with a large set of shared kernel types. The former are encoded
+in split BTF, while the latter are encoded in base BTF, resulting in more
+compact representations. A type in split BTF that refers to a type in
+base BTF refers to it using its base BTF ID, and split BTF IDs start
+at last_base_BTF_ID + 1.
+
+The downside of this approach however is that this makes the split BTF
+somewhat brittle - when the base BTF changes, base BTF ID references are
+no longer valid and the split BTF itself becomes useless. The role of the
+.BTF.base section is to make split BTF more resilient for cases where
+the base BTF may change, as is the case for kernel modules not built every
+time the kernel is for example. .BTF.base contains named base types; INTs,
+FLOATs, STRUCTs, UNIONs, ENUM[64]s and FWDs. INTs and FLOATs are fully
+described in .BTF.base sections, while composite types like structs
+and unions are not fully defined - the .BTF.base type simply serves as
+a description of the type the split BTF referred to, so structs/unions
+have 0 members in the .BTF.base section. ENUM[64]s are similarly recorded
+with 0 members. Any other types are added to the split BTF. This
+distillation process then leaves us with a .BTF.base section with
+such minimal descriptions of base types and .BTF split section which refers
+to those base types. Later, we can relocate the split BTF using both the
+information stored in the .BTF.base section and the new .BTF base; the type
+information in the .BTF.base section allows us to update the split BTF
+references to point at the corresponding new base BTF IDs.
+
+BTF relocation happens on kernel module load when a kernel module has a
+.BTF.base section, and libbpf also provides a btf__relocate() API to
+accomplish this.
+
+As an example consider the following base BTF::
+
+ [1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
+ [2] STRUCT 'foo' size=8 vlen=2
+ 'f1' type_id=1 bits_offset=0
+ 'f2' type_id=1 bits_offset=32
+
+...and associated split BTF::
+
+ [3] PTR '(anon)' type_id=2
+
+i.e. split BTF describes a pointer to struct foo { int f1; int f2 };
+
+.BTF.base will consist of::
+
+ [1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
+ [2] STRUCT 'foo' size=8 vlen=0
+
+If we relocate the split BTF later using the following new base BTF::
+
+ [1] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
+ [2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
+ [3] STRUCT 'foo' size=8 vlen=2
+ 'f1' type_id=2 bits_offset=0
+ 'f2' type_id=2 bits_offset=32
+
+...we can use our .BTF.base description to know that the split BTF reference
+is to struct foo, and relocation results in new split BTF::
+
+ [4] PTR '(anon)' type_id=3
+
+Note that we had to update BTF ID and start BTF ID for the split BTF.
+
+So we see how .BTF.base plays the role of facilitating later relocation,
+leading to more resilient split BTF.
+
+.BTF.base sections will be generated automatically for out-of-tree kernel module
+builds - i.e. where KBUILD_EXTMOD is set (as it would be for "make M=path/2/mod"
+cases). .BTF.base generation requires pahole support for the "distilled_base"
+BTF feature; this is available in pahole v1.28 and later.
+
5. Using BTF
============
@@ -990,7 +1130,7 @@ format.::
} g2;
int main() { return 0; }
int test() { return 0; }
- -bash-4.4$ clang -c -g -O2 -target bpf t2.c
+ -bash-4.4$ clang -c -g -O2 --target=bpf t2.c
-bash-4.4$ readelf -S t2.o
......
[ 8] .BTF PROGBITS 0000000000000000 00000247
@@ -1000,7 +1140,7 @@ format.::
[10] .rel.BTF.ext REL 0000000000000000 000007e0
0000000000000040 0000000000000010 16 9 8
......
- -bash-4.4$ clang -S -g -O2 -target bpf t2.c
+ -bash-4.4$ clang -S -g -O2 --target=bpf t2.c
-bash-4.4$ cat t2.s
......
.section .BTF,"",@progbits
@@ -1062,4 +1202,9 @@ format.::
7. Testing
==========
-Kernel bpf selftest `test_btf.c` provides extensive set of BTF-related tests.
+The kernel BPF selftest `tools/testing/selftests/bpf/prog_tests/btf.c`_
+provides an extensive set of BTF-related tests.
+
+.. Links
+.. _tools/testing/selftests/bpf/prog_tests/btf.c:
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/bpf/prog_tests/btf.c
diff --git a/Documentation/bpf/clang-notes.rst b/Documentation/bpf/clang-notes.rst
index 528feddf2db9..2c872a1ee08e 100644
--- a/Documentation/bpf/clang-notes.rst
+++ b/Documentation/bpf/clang-notes.rst
@@ -20,6 +20,12 @@ Arithmetic instructions
For CPU versions prior to 3, Clang v7.0 and later can enable ``BPF_ALU`` support with
``-Xclang -target-feature -Xclang +alu32``. In CPU version 3, support is automatically included.
+Jump instructions
+=================
+
+If ``-O0`` is used, Clang will generate the ``BPF_CALL | BPF_X | BPF_JMP`` (0x8d)
+instruction, which is not supported by the Linux kernel verifier.
+
Atomic operations
=================
diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst
new file mode 100644
index 000000000000..b5d47a04da5d
--- /dev/null
+++ b/Documentation/bpf/cpumasks.rst
@@ -0,0 +1,384 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _cpumasks-header-label:
+
+==================
+BPF cpumask kfuncs
+==================
+
+1. Introduction
+===============
+
+``struct cpumask`` is a bitmap data structure in the kernel whose indices
+reflect the CPUs on the system. Commonly, cpumasks are used to track which CPUs
+a task is affinitized to, but they can also be used to e.g. track which cores
+are associated with a scheduling domain, which cores on a machine are idle,
+etc.
+
+BPF provides programs with a set of :ref:`kfuncs-header-label` that can be
+used to allocate, mutate, query, and free cpumasks.
+
+2. BPF cpumask objects
+======================
+
+There are two different types of cpumasks that can be used by BPF programs.
+
+2.1 ``struct bpf_cpumask *``
+----------------------------
+
+``struct bpf_cpumask *`` is a cpumask that is allocated by BPF, on behalf of a
+BPF program, and whose lifecycle is entirely controlled by BPF. These cpumasks
+are RCU-protected, can be mutated, can be used as kptrs, and can be safely cast
+to a ``struct cpumask *``.
+
+2.1.1 ``struct bpf_cpumask *`` lifecycle
+----------------------------------------
+
+A ``struct bpf_cpumask *`` is allocated, acquired, and released, using the
+following functions:
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_create
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_acquire
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_release
+
+For example:
+
+.. code-block:: c
+
+ struct cpumask_map_value {
+ struct bpf_cpumask __kptr * cpumask;
+ };
+
+ struct array_map {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, int);
+ __type(value, struct cpumask_map_value);
+ __uint(max_entries, 65536);
+ } cpumask_map SEC(".maps");
+
+ static int cpumask_map_insert(struct bpf_cpumask *mask, u32 pid)
+ {
+ struct cpumask_map_value local, *v;
+ long status;
+ struct bpf_cpumask *old;
+ u32 key = pid;
+
+ local.cpumask = NULL;
+ status = bpf_map_update_elem(&cpumask_map, &key, &local, 0);
+ if (status) {
+ bpf_cpumask_release(mask);
+ return status;
+ }
+
+ v = bpf_map_lookup_elem(&cpumask_map, &key);
+ if (!v) {
+ bpf_cpumask_release(mask);
+ return -ENOENT;
+ }
+
+ old = bpf_kptr_xchg(&v->cpumask, mask);
+ if (old)
+ bpf_cpumask_release(old);
+
+ return 0;
+ }
+
+ /**
+ * A sample tracepoint showing how a task's cpumask can be queried and
+ * recorded as a kptr.
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(record_task_cpumask, struct task_struct *task, u64 clone_flags)
+ {
+ struct bpf_cpumask *cpumask;
+ int ret;
+
+ cpumask = bpf_cpumask_create();
+ if (!cpumask)
+ return -ENOMEM;
+
+ if (!bpf_cpumask_full(task->cpus_ptr))
+ bpf_printk("task %s has CPU affinity", task->comm);
+
+ bpf_cpumask_copy(cpumask, task->cpus_ptr);
+ return cpumask_map_insert(cpumask, task->pid);
+ }
+
+----
+
+2.1.1 ``struct bpf_cpumask *`` as kptrs
+---------------------------------------
+
+As mentioned and illustrated above, these ``struct bpf_cpumask *`` objects can
+also be stored in a map and used as kptrs. If a ``struct bpf_cpumask *`` is in
+a map, the reference can be removed from the map with bpf_kptr_xchg(), or
+opportunistically acquired using RCU:
+
+.. code-block:: c
+
+ /* struct containing the struct bpf_cpumask kptr which is stored in the map. */
+ struct cpumasks_kfunc_map_value {
+ struct bpf_cpumask __kptr * bpf_cpumask;
+ };
+
+ /* The map containing struct cpumasks_kfunc_map_value entries. */
+ struct {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, int);
+ __type(value, struct cpumasks_kfunc_map_value);
+ __uint(max_entries, 1);
+ } cpumasks_kfunc_map SEC(".maps");
+
+ /* ... */
+
+ /**
+ * A simple example tracepoint program showing how a
+ * struct bpf_cpumask * kptr that is stored in a map can
+ * be passed to kfuncs using RCU protection.
+ */
+ SEC("tp_btf/cgroup_mkdir")
+ int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path)
+ {
+ struct bpf_cpumask *kptr;
+ struct cpumasks_kfunc_map_value *v;
+ u32 key = 0;
+
+ /* Assume a bpf_cpumask * kptr was previously stored in the map. */
+ v = bpf_map_lookup_elem(&cpumasks_kfunc_map, &key);
+ if (!v)
+ return -ENOENT;
+
+ bpf_rcu_read_lock();
+ /* Acquire a reference to the bpf_cpumask * kptr that's already stored in the map. */
+ kptr = v->cpumask;
+ if (!kptr) {
+ /* If no bpf_cpumask was present in the map, it's because
+ * we're racing with another CPU that removed it with
+ * bpf_kptr_xchg() between the bpf_map_lookup_elem()
+ * above, and our load of the pointer from the map.
+ */
+ bpf_rcu_read_unlock();
+ return -EBUSY;
+ }
+
+ bpf_cpumask_setall(kptr);
+ bpf_rcu_read_unlock();
+
+ return 0;
+ }
+
+----
+
+2.2 ``struct cpumask``
+----------------------
+
+``struct cpumask`` is the object that actually contains the cpumask bitmap
+being queried, mutated, etc. A ``struct bpf_cpumask`` wraps a ``struct
+cpumask``, which is why it's safe to cast it as such (note however that it is
+**not** safe to cast a ``struct cpumask *`` to a ``struct bpf_cpumask *``, and
+the verifier will reject any program that tries to do so).
+
+As we'll see below, any kfunc that mutates its cpumask argument will take a
+``struct bpf_cpumask *`` as that argument. Any argument that simply queries the
+cpumask will instead take a ``struct cpumask *``.
+
+3. cpumask kfuncs
+=================
+
+Above, we described the kfuncs that can be used to allocate, acquire, release,
+etc a ``struct bpf_cpumask *``. This section of the document will describe the
+kfuncs for mutating and querying cpumasks.
+
+3.1 Mutating cpumasks
+---------------------
+
+Some cpumask kfuncs are "read-only" in that they don't mutate any of their
+arguments, whereas others mutate at least one argument (which means that the
+argument must be a ``struct bpf_cpumask *``, as described above).
+
+This section will describe all of the cpumask kfuncs which mutate at least one
+argument. :ref:`cpumasks-querying-label` below describes the read-only kfuncs.
+
+3.1.1 Setting and clearing CPUs
+-------------------------------
+
+bpf_cpumask_set_cpu() and bpf_cpumask_clear_cpu() can be used to set and clear
+a CPU in a ``struct bpf_cpumask`` respectively:
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_set_cpu bpf_cpumask_clear_cpu
+
+These kfuncs are pretty straightforward, and can be used, for example, as
+follows:
+
+.. code-block:: c
+
+ /**
+ * A sample tracepoint showing how a cpumask can be queried.
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(test_set_clear_cpu, struct task_struct *task, u64 clone_flags)
+ {
+ struct bpf_cpumask *cpumask;
+
+ cpumask = bpf_cpumask_create();
+ if (!cpumask)
+ return -ENOMEM;
+
+ bpf_cpumask_set_cpu(0, cpumask);
+ if (!bpf_cpumask_test_cpu(0, cast(cpumask)))
+ /* Should never happen. */
+ goto release_exit;
+
+ bpf_cpumask_clear_cpu(0, cpumask);
+ if (bpf_cpumask_test_cpu(0, cast(cpumask)))
+ /* Should never happen. */
+ goto release_exit;
+
+ /* struct cpumask * pointers such as task->cpus_ptr can also be queried. */
+ if (bpf_cpumask_test_cpu(0, task->cpus_ptr))
+ bpf_printk("task %s can use CPU %d", task->comm, 0);
+
+ release_exit:
+ bpf_cpumask_release(cpumask);
+ return 0;
+ }
+
+----
+
+bpf_cpumask_test_and_set_cpu() and bpf_cpumask_test_and_clear_cpu() are
+complementary kfuncs that allow callers to atomically test and set (or clear)
+CPUs:
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_test_and_set_cpu bpf_cpumask_test_and_clear_cpu
+
+----
+
+We can also set and clear entire ``struct bpf_cpumask *`` objects in one
+operation using bpf_cpumask_setall() and bpf_cpumask_clear():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_setall bpf_cpumask_clear
+
+3.1.2 Operations between cpumasks
+---------------------------------
+
+In addition to setting and clearing individual CPUs in a single cpumask,
+callers can also perform bitwise operations between multiple cpumasks using
+bpf_cpumask_and(), bpf_cpumask_or(), and bpf_cpumask_xor():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_and bpf_cpumask_or bpf_cpumask_xor
+
+The following is an example of how they may be used. Note that some of the
+kfuncs shown in this example will be covered in more detail below.
+
+.. code-block:: c
+
+ /**
+ * A sample tracepoint showing how a cpumask can be mutated using
+ bitwise operators (and queried).
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(test_and_or_xor, struct task_struct *task, u64 clone_flags)
+ {
+ struct bpf_cpumask *mask1, *mask2, *dst1, *dst2;
+
+ mask1 = bpf_cpumask_create();
+ if (!mask1)
+ return -ENOMEM;
+
+ mask2 = bpf_cpumask_create();
+ if (!mask2) {
+ bpf_cpumask_release(mask1);
+ return -ENOMEM;
+ }
+
+ // ...Safely create the other two masks... */
+
+ bpf_cpumask_set_cpu(0, mask1);
+ bpf_cpumask_set_cpu(1, mask2);
+ bpf_cpumask_and(dst1, (const struct cpumask *)mask1, (const struct cpumask *)mask2);
+ if (!bpf_cpumask_empty((const struct cpumask *)dst1))
+ /* Should never happen. */
+ goto release_exit;
+
+ bpf_cpumask_or(dst1, (const struct cpumask *)mask1, (const struct cpumask *)mask2);
+ if (!bpf_cpumask_test_cpu(0, (const struct cpumask *)dst1))
+ /* Should never happen. */
+ goto release_exit;
+
+ if (!bpf_cpumask_test_cpu(1, (const struct cpumask *)dst1))
+ /* Should never happen. */
+ goto release_exit;
+
+ bpf_cpumask_xor(dst2, (const struct cpumask *)mask1, (const struct cpumask *)mask2);
+ if (!bpf_cpumask_equal((const struct cpumask *)dst1,
+ (const struct cpumask *)dst2))
+ /* Should never happen. */
+ goto release_exit;
+
+ release_exit:
+ bpf_cpumask_release(mask1);
+ bpf_cpumask_release(mask2);
+ bpf_cpumask_release(dst1);
+ bpf_cpumask_release(dst2);
+ return 0;
+ }
+
+----
+
+The contents of an entire cpumask may be copied to another using
+bpf_cpumask_copy():
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_copy
+
+----
+
+.. _cpumasks-querying-label:
+
+3.2 Querying cpumasks
+---------------------
+
+In addition to the above kfuncs, there is also a set of read-only kfuncs that
+can be used to query the contents of cpumasks.
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_first bpf_cpumask_first_zero bpf_cpumask_first_and
+ bpf_cpumask_test_cpu bpf_cpumask_weight
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_equal bpf_cpumask_intersects bpf_cpumask_subset
+ bpf_cpumask_empty bpf_cpumask_full
+
+.. kernel-doc:: kernel/bpf/cpumask.c
+ :identifiers: bpf_cpumask_any_distribute bpf_cpumask_any_and_distribute
+
+----
+
+Some example usages of these querying kfuncs were shown above. We will not
+replicate those examples here. Note, however, that all of the aforementioned
+kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so
+please take a look there if you're looking for more examples of how they can be
+used.
+
+.. _tools/testing/selftests/bpf/progs/cpumask_success.c:
+ https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/bpf/progs/cpumask_success.c
+
+
+4. Adding BPF cpumask kfuncs
+============================
+
+The set of supported BPF cpumask kfuncs are not (yet) a 1-1 match with the
+cpumask operations in include/linux/cpumask.h. Any of those cpumask operations
+could easily be encapsulated in a new kfunc if and when required. If you'd like
+to support a new cpumask operation, please feel free to submit a patch. If you
+do add a new cpumask kfunc, please document it here, and add any relevant
+selftest testcases to the cpumask selftest suite.
diff --git a/Documentation/bpf/fs_kfuncs.rst b/Documentation/bpf/fs_kfuncs.rst
new file mode 100644
index 000000000000..8762c3233a3d
--- /dev/null
+++ b/Documentation/bpf/fs_kfuncs.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _fs_kfuncs-header-label:
+
+=====================
+BPF filesystem kfuncs
+=====================
+
+BPF LSM programs need to access filesystem data from LSM hooks. The following
+BPF kfuncs can be used to get these data.
+
+ * ``bpf_get_file_xattr()``
+
+ * ``bpf_get_fsverity_digest()``
+
+To avoid recursions, these kfuncs follow the following rules:
+
+1. These kfuncs are only permitted from BPF LSM function.
+2. These kfuncs should not call into other LSM hooks, i.e. security_*(). For
+ example, ``bpf_get_file_xattr()`` does not use ``vfs_getxattr()``, because
+ the latter calls LSM hook ``security_inode_getxattr``.
diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
new file mode 100644
index 000000000000..06288cc719b3
--- /dev/null
+++ b/Documentation/bpf/graph_ds_impl.rst
@@ -0,0 +1,267 @@
+=========================
+BPF Graph Data Structures
+=========================
+
+This document describes implementation details of new-style "graph" data
+structures (linked_list, rbtree), with particular focus on the verifier's
+implementation of semantics specific to those data structures.
+
+Although no specific verifier code is referred to in this document, the document
+assumes that the reader has general knowledge of BPF verifier internals, BPF
+maps, and BPF program writing.
+
+Note that the intent of this document is to describe the current state of
+these graph data structures. **No guarantees** of stability for either
+semantics or APIs are made or implied here.
+
+.. contents::
+ :local:
+ :depth: 2
+
+Introduction
+------------
+
+The BPF map API has historically been the main way to expose data structures
+of various types for use within BPF programs. Some data structures fit naturally
+with the map API (HASH, ARRAY), others less so. Consequently, programs
+interacting with the latter group of data structures can be hard to parse
+for kernel programmers without previous BPF experience.
+
+Luckily, some restrictions which necessitated the use of BPF map semantics are
+no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
+BPF allocator, it is now possible to implement BPF data structures whose API
+and semantics more closely match those exposed to the rest of the kernel.
+
+Two such data structures - linked_list and rbtree - have many verification
+details in common. Because both have "root"s ("head" for linked_list) and
+"node"s, the verifier code and this document refer to common functionality
+as "graph_api", "graph_root", "graph_node", etc.
+
+Unless otherwise stated, examples and semantics below apply to both graph data
+structures.
+
+Unstable API
+------------
+
+Data structures implemented using the BPF map API have historically used BPF
+helper functions - either standard map API helpers like ``bpf_map_update_elem``
+or map-specific helpers. The new-style graph data structures instead use kfuncs
+to define their manipulation helpers. Because there are no stability guarantees
+for kfuncs, the API and semantics for these data structures can be evolved in
+a way that breaks backwards compatibility if necessary.
+
+Root and node types for the new data structures are opaquely defined in the
+``uapi/linux/bpf.h`` header.
+
+Locking
+-------
+
+The new-style data structures are intrusive and are defined similarly to their
+vanilla kernel counterparts:
+
+.. code-block:: c
+
+ struct node_data {
+ long key;
+ long data;
+ struct bpf_rb_node node;
+ };
+
+ struct bpf_spin_lock glock;
+ struct bpf_rb_root groot __contains(node_data, node);
+
+The "root" type for both linked_list and rbtree expects to be in a map_value
+which also contains a ``bpf_spin_lock`` - in the above example both global
+variables are placed in a single-value arraymap. The verifier considers this
+spin_lock to be associated with the ``bpf_rb_root`` by virtue of both being in
+the same map_value and will enforce that the correct lock is held when
+verifying BPF programs that manipulate the tree. Since this lock checking
+happens at verification time, there is no runtime penalty.
+
+Non-owning references
+---------------------
+
+**Motivation**
+
+Consider the following BPF code:
+
+.. code-block:: c
+
+ struct node_data *n = bpf_obj_new(typeof(*n)); /* ACQUIRED */
+
+ bpf_spin_lock(&lock);
+
+ bpf_rbtree_add(&tree, n); /* PASSED */
+
+ bpf_spin_unlock(&lock);
+
+From the verifier's perspective, the pointer ``n`` returned from ``bpf_obj_new``
+has type ``PTR_TO_BTF_ID | MEM_ALLOC``, with a ``btf_id`` of
+``struct node_data`` and a nonzero ``ref_obj_id``. Because it holds ``n``, the
+program has ownership of the pointee's (object pointed to by ``n``) lifetime.
+The BPF program must pass off ownership before exiting - either via
+``bpf_obj_drop``, which ``free``'s the object, or by adding it to ``tree`` with
+``bpf_rbtree_add``.
+
+(``ACQUIRED`` and ``PASSED`` comments in the example denote statements where
+"ownership is acquired" and "ownership is passed", respectively)
+
+What should the verifier do with ``n`` after ownership is passed off? If the
+object was ``free``'d with ``bpf_obj_drop`` the answer is obvious: the verifier
+should reject programs which attempt to access ``n`` after ``bpf_obj_drop`` as
+the object is no longer valid. The underlying memory may have been reused for
+some other allocation, unmapped, etc.
+
+When ownership is passed to ``tree`` via ``bpf_rbtree_add`` the answer is less
+obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
+but that would result in programs with useful, common coding patterns being
+rejected, e.g.:
+
+.. code-block:: c
+
+ int x;
+ struct node_data *n = bpf_obj_new(typeof(*n)); /* ACQUIRED */
+
+ bpf_spin_lock(&lock);
+
+ bpf_rbtree_add(&tree, n); /* PASSED */
+ x = n->data;
+ n->data = 42;
+
+ bpf_spin_unlock(&lock);
+
+Both the read from and write to ``n->data`` would be rejected. The verifier
+can do better, though, by taking advantage of two details:
+
+ * Graph data structure APIs can only be used when the ``bpf_spin_lock``
+ associated with the graph root is held
+
+ * Both graph data structures have pointer stability
+
+ * Because graph nodes are allocated with ``bpf_obj_new`` and
+ adding / removing from the root involves fiddling with the
+ ``bpf_{list,rb}_node`` field of the node struct, a graph node will
+ remain at the same address after either operation.
+
+Because the associated ``bpf_spin_lock`` must be held by any program adding
+or removing, if we're in the critical section bounded by that lock, we know
+that no other program can add or remove until the end of the critical section.
+This combined with pointer stability means that, until the critical section
+ends, we can safely access the graph node through ``n`` even after it was used
+to pass ownership.
+
+The verifier considers such a reference a *non-owning reference*. The ref
+returned by ``bpf_obj_new`` is accordingly considered an *owning reference*.
+Both terms currently only have meaning in the context of graph nodes and API.
+
+**Details**
+
+Let's enumerate the properties of both types of references.
+
+*owning reference*
+
+ * This reference controls the lifetime of the pointee
+
+ * Ownership of pointee must be 'released' by passing it to some graph API
+ kfunc, or via ``bpf_obj_drop``, which ``free``'s the pointee
+
+ * If not released before program ends, verifier considers program invalid
+
+ * Access to the pointee's memory will not page fault
+
+*non-owning reference*
+
+ * This reference does not own the pointee
+
+ * It cannot be used to add the graph node to a graph root, nor ``free``'d via
+ ``bpf_obj_drop``
+
+ * No explicit control of lifetime, but can infer valid lifetime based on
+ non-owning ref existence (see explanation below)
+
+ * Access to the pointee's memory will not page fault
+
+From verifier's perspective non-owning references can only exist
+between spin_lock and spin_unlock. Why? After spin_unlock another program
+can do arbitrary operations on the data structure like removing and ``free``-ing
+via bpf_obj_drop. A non-owning ref to some chunk of memory that was remove'd,
+``free``'d, and reused via bpf_obj_new would point to an entirely different thing.
+Or the memory could go away.
+
+To prevent this logic violation all non-owning references are invalidated by the
+verifier after a critical section ends. This is necessary to ensure the "will
+not page fault" property of non-owning references. So if the verifier hasn't
+invalidated a non-owning ref, accessing it will not page fault.
+
+Currently ``bpf_obj_drop`` is not allowed in the critical section, so
+if there's a valid non-owning ref, we must be in a critical section, and can
+conclude that the ref's memory hasn't been dropped-and- ``free``'d or
+dropped-and-reused.
+
+Any reference to a node that is in an rbtree _must_ be non-owning, since
+the tree has control of the pointee's lifetime. Similarly, any ref to a node
+that isn't in rbtree _must_ be owning. This results in a nice property:
+graph API add / remove implementations don't need to check if a node
+has already been added (or already removed), as the ownership model
+allows the verifier to prevent such a state from being valid by simply checking
+types.
+
+However, pointer aliasing poses an issue for the above "nice property".
+Consider the following example:
+
+.. code-block:: c
+
+ struct node_data *n, *m, *o, *p;
+ n = bpf_obj_new(typeof(*n)); /* 1 */
+
+ bpf_spin_lock(&lock);
+
+ bpf_rbtree_add(&tree, n); /* 2 */
+ m = bpf_rbtree_first(&tree); /* 3 */
+
+ o = bpf_rbtree_remove(&tree, n); /* 4 */
+ p = bpf_rbtree_remove(&tree, m); /* 5 */
+
+ bpf_spin_unlock(&lock);
+
+ bpf_obj_drop(o);
+ bpf_obj_drop(p); /* 6 */
+
+Assume the tree is empty before this program runs. If we track verifier state
+changes here using numbers in above comments:
+
+ 1) n is an owning reference
+
+ 2) n is a non-owning reference, it's been added to the tree
+
+ 3) n and m are non-owning references, they both point to the same node
+
+ 4) o is an owning reference, n and m non-owning, all point to same node
+
+ 5) o and p are owning, n and m non-owning, all point to the same node
+
+ 6) a double-free has occurred, since o and p point to same node and o was
+ ``free``'d in previous statement
+
+States 4 and 5 violate our "nice property", as there are non-owning refs to
+a node which is not in an rbtree. Statement 5 will try to remove a node which
+has already been removed as a result of this violation. State 6 is a dangerous
+double-free.
+
+At a minimum we should prevent state 6 from being possible. If we can't also
+prevent state 5 then we must abandon our "nice property" and check whether a
+node has already been removed at runtime.
+
+We prevent both by generalizing the "invalidate non-owning references" behavior
+of ``bpf_spin_unlock`` and doing similar invalidation after
+``bpf_rbtree_remove``. The logic here being that any graph API kfunc which:
+
+ * takes an arbitrary node argument
+
+ * removes it from the data structure
+
+ * returns an owning reference to the removed node
+
+May result in a state where some other non-owning reference points to the same
+node. So ``remove``-type kfuncs must be considered a non-owning reference
+invalidation point as well.
diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst
index 1b50de1983ee..0bb5cb8157f1 100644
--- a/Documentation/bpf/index.rst
+++ b/Documentation/bpf/index.rst
@@ -12,23 +12,27 @@ that goes into great technical depth about the BPF Architecture.
.. toctree::
:maxdepth: 1
- instruction-set
verifier
libbpf/index
+ standardization/index
btf
faq
syscall_api
helpers
kfuncs
+ cpumasks
+ fs_kfuncs
programs
maps
bpf_prog_run
classic_vs_extended.rst
+ bpf_iterators
bpf_licensing
test_debug
clang-notes
linux-notes
other
+ redirect
.. only:: subproject and html
diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst
deleted file mode 100644
index 5d798437dad4..000000000000
--- a/Documentation/bpf/instruction-set.rst
+++ /dev/null
@@ -1,328 +0,0 @@
-.. contents::
-.. sectnum::
-
-========================================
-eBPF Instruction Set Specification, v1.0
-========================================
-
-This document specifies version 1.0 of the eBPF instruction set.
-
-
-Registers and calling convention
-================================
-
-eBPF has 10 general purpose registers and a read-only frame pointer register,
-all of which are 64-bits wide.
-
-The eBPF calling convention is defined as:
-
-* R0: return value from function calls, and exit value for eBPF programs
-* R1 - R5: arguments for function calls
-* R6 - R9: callee saved registers that function calls will preserve
-* R10: read-only frame pointer to access stack
-
-R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if
-necessary across calls.
-
-Instruction encoding
-====================
-
-eBPF has two instruction encodings:
-
-* the basic instruction encoding, which uses 64 bits to encode an instruction
-* the wide instruction encoding, which appends a second 64-bit immediate value
- (imm64) after the basic instruction for a total of 128 bits.
-
-The basic instruction encoding looks as follows:
-
-============= ======= =============== ==================== ============
-32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
-============= ======= =============== ==================== ============
-immediate offset source register destination register opcode
-============= ======= =============== ==================== ============
-
-Note that most instructions do not use all of the fields.
-Unused fields shall be cleared to zero.
-
-Instruction classes
--------------------
-
-The three LSB bits of the 'opcode' field store the instruction class:
-
-========= ===== =============================== ===================================
-class value description reference
-========= ===== =============================== ===================================
-BPF_LD 0x00 non-standard load operations `Load and store instructions`_
-BPF_LDX 0x01 load into register operations `Load and store instructions`_
-BPF_ST 0x02 store from immediate operations `Load and store instructions`_
-BPF_STX 0x03 store from register operations `Load and store instructions`_
-BPF_ALU 0x04 32-bit arithmetic operations `Arithmetic and jump instructions`_
-BPF_JMP 0x05 64-bit jump operations `Arithmetic and jump instructions`_
-BPF_JMP32 0x06 32-bit jump operations `Arithmetic and jump instructions`_
-BPF_ALU64 0x07 64-bit arithmetic operations `Arithmetic and jump instructions`_
-========= ===== =============================== ===================================
-
-Arithmetic and jump instructions
-================================
-
-For arithmetic and jump instructions (``BPF_ALU``, ``BPF_ALU64``, ``BPF_JMP`` and
-``BPF_JMP32``), the 8-bit 'opcode' field is divided into three parts:
-
-============== ====== =================
-4 bits (MSB) 1 bit 3 bits (LSB)
-============== ====== =================
-operation code source instruction class
-============== ====== =================
-
-The 4th bit encodes the source operand:
-
- ====== ===== ========================================
- source value description
- ====== ===== ========================================
- BPF_K 0x00 use 32-bit immediate as source operand
- BPF_X 0x08 use 'src_reg' register as source operand
- ====== ===== ========================================
-
-The four MSB bits store the operation code.
-
-
-Arithmetic instructions
------------------------
-
-``BPF_ALU`` uses 32-bit wide operands while ``BPF_ALU64`` uses 64-bit wide operands for
-otherwise identical operations.
-The 'code' field encodes the operation as below:
-
-======== ===== ==========================================================
-code value description
-======== ===== ==========================================================
-BPF_ADD 0x00 dst += src
-BPF_SUB 0x10 dst -= src
-BPF_MUL 0x20 dst \*= src
-BPF_DIV 0x30 dst /= src
-BPF_OR 0x40 dst \|= src
-BPF_AND 0x50 dst &= src
-BPF_LSH 0x60 dst <<= src
-BPF_RSH 0x70 dst >>= src
-BPF_NEG 0x80 dst = ~src
-BPF_MOD 0x90 dst %= src
-BPF_XOR 0xa0 dst ^= src
-BPF_MOV 0xb0 dst = src
-BPF_ARSH 0xc0 sign extending shift right
-BPF_END 0xd0 byte swap operations (see `Byte swap instructions`_ below)
-======== ===== ==========================================================
-
-``BPF_ADD | BPF_X | BPF_ALU`` means::
-
- dst_reg = (u32) dst_reg + (u32) src_reg;
-
-``BPF_ADD | BPF_X | BPF_ALU64`` means::
-
- dst_reg = dst_reg + src_reg
-
-``BPF_XOR | BPF_K | BPF_ALU`` means::
-
- src_reg = (u32) src_reg ^ (u32) imm32
-
-``BPF_XOR | BPF_K | BPF_ALU64`` means::
-
- src_reg = src_reg ^ imm32
-
-
-Byte swap instructions
-~~~~~~~~~~~~~~~~~~~~~~
-
-The byte swap instructions use an instruction class of ``BPF_ALU`` and a 4-bit
-'code' field of ``BPF_END``.
-
-The byte swap instructions operate on the destination register
-only and do not use a separate source register or immediate value.
-
-The 1-bit source operand field in the opcode is used to select what byte
-order the operation convert from or to:
-
-========= ===== =================================================
-source value description
-========= ===== =================================================
-BPF_TO_LE 0x00 convert between host byte order and little endian
-BPF_TO_BE 0x08 convert between host byte order and big endian
-========= ===== =================================================
-
-The 'imm' field encodes the width of the swap operations. The following widths
-are supported: 16, 32 and 64.
-
-Examples:
-
-``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means::
-
- dst_reg = htole16(dst_reg)
-
-``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means::
-
- dst_reg = htobe64(dst_reg)
-
-Jump instructions
------------------
-
-``BPF_JMP32`` uses 32-bit wide operands while ``BPF_JMP`` uses 64-bit wide operands for
-otherwise identical operations.
-The 'code' field encodes the operation as below:
-
-======== ===== ========================= ============
-code value description notes
-======== ===== ========================= ============
-BPF_JA 0x00 PC += off BPF_JMP only
-BPF_JEQ 0x10 PC += off if dst == src
-BPF_JGT 0x20 PC += off if dst > src unsigned
-BPF_JGE 0x30 PC += off if dst >= src unsigned
-BPF_JSET 0x40 PC += off if dst & src
-BPF_JNE 0x50 PC += off if dst != src
-BPF_JSGT 0x60 PC += off if dst > src signed
-BPF_JSGE 0x70 PC += off if dst >= src signed
-BPF_CALL 0x80 function call
-BPF_EXIT 0x90 function / program return BPF_JMP only
-BPF_JLT 0xa0 PC += off if dst < src unsigned
-BPF_JLE 0xb0 PC += off if dst <= src unsigned
-BPF_JSLT 0xc0 PC += off if dst < src signed
-BPF_JSLE 0xd0 PC += off if dst <= src signed
-======== ===== ========================= ============
-
-The eBPF program needs to store the return value into register R0 before doing a
-BPF_EXIT.
-
-
-Load and store instructions
-===========================
-
-For load and store instructions (``BPF_LD``, ``BPF_LDX``, ``BPF_ST``, and ``BPF_STX``), the
-8-bit 'opcode' field is divided as:
-
-============ ====== =================
-3 bits (MSB) 2 bits 3 bits (LSB)
-============ ====== =================
-mode size instruction class
-============ ====== =================
-
-The mode modifier is one of:
-
- ============= ===== ==================================== =============
- mode modifier value description reference
- ============= ===== ==================================== =============
- BPF_IMM 0x00 64-bit immediate instructions `64-bit immediate instructions`_
- BPF_ABS 0x20 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_
- BPF_IND 0x40 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_
- BPF_MEM 0x60 regular load and store operations `Regular load and store operations`_
- BPF_ATOMIC 0xc0 atomic operations `Atomic operations`_
- ============= ===== ==================================== =============
-
-The size modifier is one of:
-
- ============= ===== =====================
- size modifier value description
- ============= ===== =====================
- BPF_W 0x00 word (4 bytes)
- BPF_H 0x08 half word (2 bytes)
- BPF_B 0x10 byte
- BPF_DW 0x18 double word (8 bytes)
- ============= ===== =====================
-
-Regular load and store operations
----------------------------------
-
-The ``BPF_MEM`` mode modifier is used to encode regular load and store
-instructions that transfer data between a register and memory.
-
-``BPF_MEM | <size> | BPF_STX`` means::
-
- *(size *) (dst_reg + off) = src_reg
-
-``BPF_MEM | <size> | BPF_ST`` means::
-
- *(size *) (dst_reg + off) = imm32
-
-``BPF_MEM | <size> | BPF_LDX`` means::
-
- dst_reg = *(size *) (src_reg + off)
-
-Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``.
-
-Atomic operations
------------------
-
-Atomic operations are operations that operate on memory and can not be
-interrupted or corrupted by other access to the same memory region
-by other eBPF programs or means outside of this specification.
-
-All atomic operations supported by eBPF are encoded as store operations
-that use the ``BPF_ATOMIC`` mode modifier as follows:
-
-* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations
-* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations
-* 8-bit and 16-bit wide atomic operations are not supported.
-
-The 'imm' field is used to encode the actual atomic operation.
-Simple atomic operation use a subset of the values defined to encode
-arithmetic operations in the 'imm' field to encode the atomic operation:
-
-======== ===== ===========
-imm value description
-======== ===== ===========
-BPF_ADD 0x00 atomic add
-BPF_OR 0x40 atomic or
-BPF_AND 0x50 atomic and
-BPF_XOR 0xa0 atomic xor
-======== ===== ===========
-
-
-``BPF_ATOMIC | BPF_W | BPF_STX`` with 'imm' = BPF_ADD means::
-
- *(u32 *)(dst_reg + off16) += src_reg
-
-``BPF_ATOMIC | BPF_DW | BPF_STX`` with 'imm' = BPF ADD means::
-
- *(u64 *)(dst_reg + off16) += src_reg
-
-In addition to the simple atomic operations, there also is a modifier and
-two complex atomic operations:
-
-=========== ================ ===========================
-imm value description
-=========== ================ ===========================
-BPF_FETCH 0x01 modifier: return old value
-BPF_XCHG 0xe0 | BPF_FETCH atomic exchange
-BPF_CMPXCHG 0xf0 | BPF_FETCH atomic compare and exchange
-=========== ================ ===========================
-
-The ``BPF_FETCH`` modifier is optional for simple atomic operations, and
-always set for the complex atomic operations. If the ``BPF_FETCH`` flag
-is set, then the operation also overwrites ``src_reg`` with the value that
-was in memory before it was modified.
-
-The ``BPF_XCHG`` operation atomically exchanges ``src_reg`` with the value
-addressed by ``dst_reg + off``.
-
-The ``BPF_CMPXCHG`` operation atomically compares the value addressed by
-``dst_reg + off`` with ``R0``. If they match, the value addressed by
-``dst_reg + off`` is replaced with ``src_reg``. In either case, the
-value that was at ``dst_reg + off`` before the operation is zero-extended
-and loaded back to ``R0``.
-
-64-bit immediate instructions
------------------------------
-
-Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
-encoding for an extra imm64 value.
-
-There is currently only one such instruction.
-
-``BPF_LD | BPF_DW | BPF_IMM`` means::
-
- dst_reg = imm64
-
-
-Legacy BPF Packet access instructions
--------------------------------------
-
-eBPF previously introduced special instructions for access to packet data that were
-carried over from classic BPF. However, these instructions are
-deprecated and should no longer be used.
diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
index 0f858156371d..e38941370b90 100644
--- a/Documentation/bpf/kfuncs.rst
+++ b/Documentation/bpf/kfuncs.rst
@@ -1,3 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _kfuncs-header-label:
+
=============================
BPF Kernel Functions (kfuncs)
=============================
@@ -9,7 +13,7 @@ BPF Kernel Functions or more commonly known as kfuncs are functions in the Linux
kernel which are exposed for use by BPF programs. Unlike normal BPF helpers,
kfuncs do not have a stable interface and can change from one kernel release to
another. Hence, BPF programs need to be updated in response to changes in the
-kernel.
+kernel. See :ref:`BPF_kfunc_lifecycle_expectations` for more information.
2. Defining a kfunc
===================
@@ -33,16 +37,14 @@ prototype in a header for the wrapper kfunc.
An example is given below::
/* Disables missing prototype warnings */
- __diag_push();
- __diag_ignore_all("-Wmissing-prototypes",
- "Global kfuncs as their definitions will be in BTF");
+ __bpf_kfunc_start_defs();
- struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
+ __bpf_kfunc struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
{
return find_get_task_by_vpid(nr);
}
- __diag_pop();
+ __bpf_kfunc_end_defs();
A wrapper kfunc is often needed when we need to annotate parameters of the
kfunc. Otherwise one may directly make the kfunc visible to the BPF program by
@@ -62,7 +64,7 @@ kfunc with a __tag, where tag may be one of the supported annotations.
This annotation is used to indicate a memory and size pair in the argument list.
An example is given below::
- void bpf_memzero(void *mem, int mem__sz)
+ __bpf_kfunc void bpf_memzero(void *mem, int mem__sz)
{
...
}
@@ -72,6 +74,109 @@ argument as its size. By default, without __sz annotation, the size of the type
of the pointer is used. Without __sz annotation, a kfunc cannot accept a void
pointer.
+2.2.2 __k Annotation
+--------------------
+
+This annotation is only understood for scalar arguments, where it indicates that
+the verifier must check the scalar argument to be a known constant, which does
+not indicate a size parameter, and the value of the constant is relevant to the
+safety of the program.
+
+An example is given below::
+
+ __bpf_kfunc void *bpf_obj_new(u32 local_type_id__k, ...)
+ {
+ ...
+ }
+
+Here, bpf_obj_new uses local_type_id argument to find out the size of that type
+ID in program's BTF and return a sized pointer to it. Each type ID will have a
+distinct size, hence it is crucial to treat each such call as distinct when
+values don't match during verifier state pruning checks.
+
+Hence, whenever a constant scalar argument is accepted by a kfunc which is not a
+size parameter, and the value of the constant matters for program safety, __k
+suffix should be used.
+
+2.2.3 __uninit Annotation
+-------------------------
+
+This annotation is used to indicate that the argument will be treated as
+uninitialized.
+
+An example is given below::
+
+ __bpf_kfunc int bpf_dynptr_from_skb(..., struct bpf_dynptr_kern *ptr__uninit)
+ {
+ ...
+ }
+
+Here, the dynptr will be treated as an uninitialized dynptr. Without this
+annotation, the verifier will reject the program if the dynptr passed in is
+not initialized.
+
+2.2.4 __opt Annotation
+-------------------------
+
+This annotation is used to indicate that the buffer associated with an __sz or __szk
+argument may be null. If the function is passed a nullptr in place of the buffer,
+the verifier will not check that length is appropriate for the buffer. The kfunc is
+responsible for checking if this buffer is null before using it.
+
+An example is given below::
+
+ __bpf_kfunc void *bpf_dynptr_slice(..., void *buffer__opt, u32 buffer__szk)
+ {
+ ...
+ }
+
+Here, the buffer may be null. If buffer is not null, it at least of size buffer_szk.
+Either way, the returned buffer is either NULL, or of size buffer_szk. Without this
+annotation, the verifier will reject the program if a null pointer is passed in with
+a nonzero size.
+
+2.2.5 __str Annotation
+----------------------------
+This annotation is used to indicate that the argument is a constant string.
+
+An example is given below::
+
+ __bpf_kfunc bpf_get_file_xattr(..., const char *name__str, ...)
+ {
+ ...
+ }
+
+In this case, ``bpf_get_file_xattr()`` can be called as::
+
+ bpf_get_file_xattr(..., "xattr_name", ...);
+
+Or::
+
+ const char name[] = "xattr_name"; /* This need to be global */
+ int BPF_PROG(...)
+ {
+ ...
+ bpf_get_file_xattr(..., name, ...);
+ ...
+ }
+
+2.2.6 __prog Annotation
+---------------------------
+This annotation is used to indicate that the argument needs to be fixed up to
+the bpf_prog_aux of the caller BPF program. Any value passed into this argument
+is ignored, and rewritten by the verifier.
+
+An example is given below::
+
+ __bpf_kfunc int bpf_wq_set_callback_impl(struct bpf_wq *wq,
+ int (callback_fn)(void *map, int *key, void *value),
+ unsigned int flags,
+ void *aux__prog)
+ {
+ struct bpf_prog_aux *aux = aux__prog;
+ ...
+ }
+
.. _BPF_kfunc_nodef:
2.3 Using an existing kernel function
@@ -89,14 +194,28 @@ In addition to kfuncs' arguments, verifier may need more information about the
type of kfunc(s) being registered with the BPF subsystem. To do so, we define
flags on a set of kfuncs as follows::
- BTF_SET8_START(bpf_task_set)
+ BTF_KFUNCS_START(bpf_task_set)
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
- BTF_SET8_END(bpf_task_set)
+ BTF_KFUNCS_END(bpf_task_set)
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
along with it. Ofcourse, it is also allowed to specify no flags.
+kfunc definitions should also always be annotated with the ``__bpf_kfunc``
+macro. This prevents issues such as the compiler inlining the kfunc if it's a
+static kernel function, or the function being elided in an LTO build as it's
+not used in the rest of the kernel. Developers should not manually add
+annotations to their kfunc to prevent these issues. If an annotation is
+required to prevent such an issue with your kfunc, it is a bug and should be
+added to the definition of the macro so that other kfuncs are similarly
+protected. An example is given below::
+
+ __bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
+ {
+ ...
+ }
+
2.4.1 KF_ACQUIRE flag
---------------------
@@ -120,47 +239,83 @@ both are orthogonal to each other.
---------------------
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
-passed in to it. There can be only one referenced pointer that can be passed in.
-All copies of the pointer being released are invalidated as a result of invoking
-kfunc with this flag.
+passed in to it. There can be only one referenced pointer that can be passed
+in. All copies of the pointer being released are invalidated as a result of
+invoking kfunc with this flag. KF_RELEASE kfuncs automatically receive the
+protection afforded by the KF_TRUSTED_ARGS flag described below.
-2.4.4 KF_KPTR_GET flag
-----------------------
-
-The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument
-as a pointer to kptr, safely increments the refcount of the object it points to,
-and returns a reference to the user. The rest of the arguments may be normal
-arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with
-KF_ACQUIRE and KF_RET_NULL flags.
-
-2.4.5 KF_TRUSTED_ARGS flag
+2.4.4 KF_TRUSTED_ARGS flag
--------------------------
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
-indicates that the all pointer arguments will always have a guaranteed lifetime,
-and pointers to kernel objects are always passed to helpers in their unmodified
-form (as obtained from acquire kfuncs).
+indicates that the all pointer arguments are valid, and that all pointers to
+BTF objects have been passed in their unmodified form (that is, at a zero
+offset, and without having been obtained from walking another pointer, with one
+exception described below).
+
+There are two types of pointers to kernel objects which are considered "valid":
+
+1. Pointers which are passed as tracepoint or struct_ops callback arguments.
+2. Pointers which were returned from a KF_ACQUIRE kfunc.
+
+Pointers to non-BTF objects (e.g. scalar pointers) may also be passed to
+KF_TRUSTED_ARGS kfuncs, and may have a non-zero offset.
+
+The definition of "valid" pointers is subject to change at any time, and has
+absolutely no ABI stability guarantees.
+
+As mentioned above, a nested pointer obtained from walking a trusted pointer is
+no longer trusted, with one exception. If a struct type has a field that is
+guaranteed to be valid (trusted or rcu, as in KF_RCU description below) as long
+as its parent pointer is valid, the following macros can be used to express
+that to the verifier:
+
+* ``BTF_TYPE_SAFE_TRUSTED``
+* ``BTF_TYPE_SAFE_RCU``
+* ``BTF_TYPE_SAFE_RCU_OR_NULL``
+
+For example,
+
+.. code-block:: c
+
+ BTF_TYPE_SAFE_TRUSTED(struct socket) {
+ struct sock *sk;
+ };
+
+or
+
+.. code-block:: c
+
+ BTF_TYPE_SAFE_RCU(struct task_struct) {
+ const cpumask_t *cpus_ptr;
+ struct css_set __rcu *cgroups;
+ struct task_struct __rcu *real_parent;
+ struct task_struct *group_leader;
+ };
+
+In other words, you must:
+
+1. Wrap the valid pointer type in a ``BTF_TYPE_SAFE_*`` macro.
+
+2. Specify the type and name of the valid nested field. This field must match
+ the field in the original type definition exactly.
-It can be used to enforce that a pointer to a refcounted object acquired from a
-kfunc or BPF helper is passed as an argument to this kfunc without any
-modifications (e.g. pointer arithmetic) such that it is trusted and points to
-the original object.
+A new type declared by a ``BTF_TYPE_SAFE_*`` macro also needs to be emitted so
+that it appears in BTF. For example, ``BTF_TYPE_SAFE_TRUSTED(struct socket)``
+is emitted in the ``type_is_trusted()`` function as follows:
-Meanwhile, it is also allowed pass pointers to normal memory to such kfuncs,
-but those can have a non-zero offset.
+.. code-block:: c
-This flag is often used for kfuncs that operate (change some property, perform
-some operation) on an object that was obtained using an acquire kfunc. Such
-kfuncs need an unchanged pointer to ensure the integrity of the operation being
-performed on the expected object.
+ BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct socket));
-2.4.6 KF_SLEEPABLE flag
+
+2.4.5 KF_SLEEPABLE flag
-----------------------
The KF_SLEEPABLE flag is used for kfuncs that may sleep. Such kfuncs can only
be called by sleepable BPF programs (BPF_F_SLEEPABLE).
-2.4.7 KF_DESTRUCTIVE flag
+2.4.6 KF_DESTRUCTIVE flag
--------------------------
The KF_DESTRUCTIVE flag is used to indicate functions calling which is
@@ -169,6 +324,56 @@ rebooting or panicking. Due to this additional restrictions apply to these
calls. At the moment they only require CAP_SYS_BOOT capability, but more can be
added later.
+2.4.7 KF_RCU flag
+-----------------
+
+The KF_RCU flag is a weaker version of KF_TRUSTED_ARGS. The kfuncs marked with
+KF_RCU expect either PTR_TRUSTED or MEM_RCU arguments. The verifier guarantees
+that the objects are valid and there is no use-after-free. The pointers are not
+NULL, but the object's refcount could have reached zero. The kfuncs need to
+consider doing refcnt != 0 check, especially when returning a KF_ACQUIRE
+pointer. Note as well that a KF_ACQUIRE kfunc that is KF_RCU should very likely
+also be KF_RET_NULL.
+
+2.4.8 KF_RCU_PROTECTED flag
+---------------------------
+
+The KF_RCU_PROTECTED flag is used to indicate that the kfunc must be invoked in
+an RCU critical section. This is assumed by default in non-sleepable programs,
+and must be explicitly ensured by calling ``bpf_rcu_read_lock`` for sleepable
+ones.
+
+If the kfunc returns a pointer value, this flag also enforces that the returned
+pointer is RCU protected, and can only be used while the RCU critical section is
+active.
+
+The flag is distinct from the ``KF_RCU`` flag, which only ensures that its
+arguments are at least RCU protected pointers. This may transitively imply that
+RCU protection is ensured, but it does not work in cases of kfuncs which require
+RCU protection but do not take RCU protected arguments.
+
+.. _KF_deprecated_flag:
+
+2.4.9 KF_DEPRECATED flag
+------------------------
+
+The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
+changed or removed in a subsequent kernel release. A kfunc that is
+marked with KF_DEPRECATED should also have any relevant information
+captured in its kernel doc. Such information typically includes the
+kfunc's expected remaining lifespan, a recommendation for new
+functionality that can replace it if any is available, and possibly a
+rationale for why it is being removed.
+
+Note that while on some occasions, a KF_DEPRECATED kfunc may continue to be
+supported and have its KF_DEPRECATED flag removed, it is likely to be far more
+difficult to remove a KF_DEPRECATED flag after it's been added than it is to
+prevent it from being added in the first place. As described in
+:ref:`BPF_kfunc_lifecycle_expectations`, users that rely on specific kfuncs are
+encouraged to make their use-cases known as early as possible, and participate
+in upstream discussions regarding whether to keep, change, deprecate, or remove
+those kfuncs if and when such discussions occur.
+
2.5 Registering the kfuncs
--------------------------
@@ -176,10 +381,10 @@ Once the kfunc is prepared for use, the final step to making it visible is
registering it with the BPF subsystem. Registration is done per BPF program
type. An example is shown below::
- BTF_SET8_START(bpf_task_set)
+ BTF_KFUNCS_START(bpf_task_set)
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
- BTF_SET8_END(bpf_task_set)
+ BTF_KFUNCS_END(bpf_task_set)
static const struct btf_kfunc_id_set bpf_task_kfunc_set = {
.owner = THIS_MODULE,
@@ -191,3 +396,317 @@ type. An example is shown below::
return register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &bpf_task_kfunc_set);
}
late_initcall(init_subsystem);
+
+2.6 Specifying no-cast aliases with ___init
+--------------------------------------------
+
+The verifier will always enforce that the BTF type of a pointer passed to a
+kfunc by a BPF program, matches the type of pointer specified in the kfunc
+definition. The verifier, does, however, allow types that are equivalent
+according to the C standard to be passed to the same kfunc arg, even if their
+BTF_IDs differ.
+
+For example, for the following type definition:
+
+.. code-block:: c
+
+ struct bpf_cpumask {
+ cpumask_t cpumask;
+ refcount_t usage;
+ };
+
+The verifier would allow a ``struct bpf_cpumask *`` to be passed to a kfunc
+taking a ``cpumask_t *`` (which is a typedef of ``struct cpumask *``). For
+instance, both ``struct cpumask *`` and ``struct bpf_cpmuask *`` can be passed
+to bpf_cpumask_test_cpu().
+
+In some cases, this type-aliasing behavior is not desired. ``struct
+nf_conn___init`` is one such example:
+
+.. code-block:: c
+
+ struct nf_conn___init {
+ struct nf_conn ct;
+ };
+
+The C standard would consider these types to be equivalent, but it would not
+always be safe to pass either type to a trusted kfunc. ``struct
+nf_conn___init`` represents an allocated ``struct nf_conn`` object that has
+*not yet been initialized*, so it would therefore be unsafe to pass a ``struct
+nf_conn___init *`` to a kfunc that's expecting a fully initialized ``struct
+nf_conn *`` (e.g. ``bpf_ct_change_timeout()``).
+
+In order to accommodate such requirements, the verifier will enforce strict
+PTR_TO_BTF_ID type matching if two types have the exact same name, with one
+being suffixed with ``___init``.
+
+.. _BPF_kfunc_lifecycle_expectations:
+
+3. kfunc lifecycle expectations
+===============================
+
+kfuncs provide a kernel <-> kernel API, and thus are not bound by any of the
+strict stability restrictions associated with kernel <-> user UAPIs. This means
+they can be thought of as similar to EXPORT_SYMBOL_GPL, and can therefore be
+modified or removed by a maintainer of the subsystem they're defined in when
+it's deemed necessary.
+
+Like any other change to the kernel, maintainers will not change or remove a
+kfunc without having a reasonable justification. Whether or not they'll choose
+to change a kfunc will ultimately depend on a variety of factors, such as how
+widely used the kfunc is, how long the kfunc has been in the kernel, whether an
+alternative kfunc exists, what the norm is in terms of stability for the
+subsystem in question, and of course what the technical cost is of continuing
+to support the kfunc.
+
+There are several implications of this:
+
+a) kfuncs that are widely used or have been in the kernel for a long time will
+ be more difficult to justify being changed or removed by a maintainer. In
+ other words, kfuncs that are known to have a lot of users and provide
+ significant value provide stronger incentives for maintainers to invest the
+ time and complexity in supporting them. It is therefore important for
+ developers that are using kfuncs in their BPF programs to communicate and
+ explain how and why those kfuncs are being used, and to participate in
+ discussions regarding those kfuncs when they occur upstream.
+
+b) Unlike regular kernel symbols marked with EXPORT_SYMBOL_GPL, BPF programs
+ that call kfuncs are generally not part of the kernel tree. This means that
+ refactoring cannot typically change callers in-place when a kfunc changes,
+ as is done for e.g. an upstreamed driver being updated in place when a
+ kernel symbol is changed.
+
+ Unlike with regular kernel symbols, this is expected behavior for BPF
+ symbols, and out-of-tree BPF programs that use kfuncs should be considered
+ relevant to discussions and decisions around modifying and removing those
+ kfuncs. The BPF community will take an active role in participating in
+ upstream discussions when necessary to ensure that the perspectives of such
+ users are taken into account.
+
+c) A kfunc will never have any hard stability guarantees. BPF APIs cannot and
+ will not ever hard-block a change in the kernel purely for stability
+ reasons. That being said, kfuncs are features that are meant to solve
+ problems and provide value to users. The decision of whether to change or
+ remove a kfunc is a multivariate technical decision that is made on a
+ case-by-case basis, and which is informed by data points such as those
+ mentioned above. It is expected that a kfunc being removed or changed with
+ no warning will not be a common occurrence or take place without sound
+ justification, but it is a possibility that must be accepted if one is to
+ use kfuncs.
+
+3.1 kfunc deprecation
+---------------------
+
+As described above, while sometimes a maintainer may find that a kfunc must be
+changed or removed immediately to accommodate some changes in their subsystem,
+usually kfuncs will be able to accommodate a longer and more measured
+deprecation process. For example, if a new kfunc comes along which provides
+superior functionality to an existing kfunc, the existing kfunc may be
+deprecated for some period of time to allow users to migrate their BPF programs
+to use the new one. Or, if a kfunc has no known users, a decision may be made
+to remove the kfunc (without providing an alternative API) after some
+deprecation period so as to provide users with a window to notify the kfunc
+maintainer if it turns out that the kfunc is actually being used.
+
+It's expected that the common case will be that kfuncs will go through a
+deprecation period rather than being changed or removed without warning. As
+described in :ref:`KF_deprecated_flag`, the kfunc framework provides the
+KF_DEPRECATED flag to kfunc developers to signal to users that a kfunc has been
+deprecated. Once a kfunc has been marked with KF_DEPRECATED, the following
+procedure is followed for removal:
+
+1. Any relevant information for deprecated kfuncs is documented in the kfunc's
+ kernel docs. This documentation will typically include the kfunc's expected
+ remaining lifespan, a recommendation for new functionality that can replace
+ the usage of the deprecated function (or an explanation as to why no such
+ replacement exists), etc.
+
+2. The deprecated kfunc is kept in the kernel for some period of time after it
+ was first marked as deprecated. This time period will be chosen on a
+ case-by-case basis, and will typically depend on how widespread the use of
+ the kfunc is, how long it has been in the kernel, and how hard it is to move
+ to alternatives. This deprecation time period is "best effort", and as
+ described :ref:`above<BPF_kfunc_lifecycle_expectations>`, circumstances may
+ sometimes dictate that the kfunc be removed before the full intended
+ deprecation period has elapsed.
+
+3. After the deprecation period the kfunc will be removed. At this point, BPF
+ programs calling the kfunc will be rejected by the verifier.
+
+4. Core kfuncs
+==============
+
+The BPF subsystem provides a number of "core" kfuncs that are potentially
+applicable to a wide variety of different possible use cases and programs.
+Those kfuncs are documented here.
+
+4.1 struct task_struct * kfuncs
+-------------------------------
+
+There are a number of kfuncs that allow ``struct task_struct *`` objects to be
+used as kptrs:
+
+.. kernel-doc:: kernel/bpf/helpers.c
+ :identifiers: bpf_task_acquire bpf_task_release
+
+These kfuncs are useful when you want to acquire or release a reference to a
+``struct task_struct *`` that was passed as e.g. a tracepoint arg, or a
+struct_ops callback arg. For example:
+
+.. code-block:: c
+
+ /**
+ * A trivial example tracepoint program that shows how to
+ * acquire and release a struct task_struct * pointer.
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(task_acquire_release_example, struct task_struct *task, u64 clone_flags)
+ {
+ struct task_struct *acquired;
+
+ acquired = bpf_task_acquire(task);
+ if (acquired)
+ /*
+ * In a typical program you'd do something like store
+ * the task in a map, and the map will automatically
+ * release it later. Here, we release it manually.
+ */
+ bpf_task_release(acquired);
+ return 0;
+ }
+
+
+References acquired on ``struct task_struct *`` objects are RCU protected.
+Therefore, when in an RCU read region, you can obtain a pointer to a task
+embedded in a map value without having to acquire a reference:
+
+.. code-block:: c
+
+ #define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
+ private(TASK) static struct task_struct *global;
+
+ /**
+ * A trivial example showing how to access a task stored
+ * in a map using RCU.
+ */
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(task_rcu_read_example, struct task_struct *task, u64 clone_flags)
+ {
+ struct task_struct *local_copy;
+
+ bpf_rcu_read_lock();
+ local_copy = global;
+ if (local_copy)
+ /*
+ * We could also pass local_copy to kfuncs or helper functions here,
+ * as we're guaranteed that local_copy will be valid until we exit
+ * the RCU read region below.
+ */
+ bpf_printk("Global task %s is valid", local_copy->comm);
+ else
+ bpf_printk("No global task found");
+ bpf_rcu_read_unlock();
+
+ /* At this point we can no longer reference local_copy. */
+
+ return 0;
+ }
+
+----
+
+A BPF program can also look up a task from a pid. This can be useful if the
+caller doesn't have a trusted pointer to a ``struct task_struct *`` object that
+it can acquire a reference on with bpf_task_acquire().
+
+.. kernel-doc:: kernel/bpf/helpers.c
+ :identifiers: bpf_task_from_pid
+
+Here is an example of it being used:
+
+.. code-block:: c
+
+ SEC("tp_btf/task_newtask")
+ int BPF_PROG(task_get_pid_example, struct task_struct *task, u64 clone_flags)
+ {
+ struct task_struct *lookup;
+
+ lookup = bpf_task_from_pid(task->pid);
+ if (!lookup)
+ /* A task should always be found, as %task is a tracepoint arg. */
+ return -ENOENT;
+
+ if (lookup->pid != task->pid) {
+ /* bpf_task_from_pid() looks up the task via its
+ * globally-unique pid from the init_pid_ns. Thus,
+ * the pid of the lookup task should always be the
+ * same as the input task.
+ */
+ bpf_task_release(lookup);
+ return -EINVAL;
+ }
+
+ /* bpf_task_from_pid() returns an acquired reference,
+ * so it must be dropped before returning from the
+ * tracepoint handler.
+ */
+ bpf_task_release(lookup);
+ return 0;
+ }
+
+4.2 struct cgroup * kfuncs
+--------------------------
+
+``struct cgroup *`` objects also have acquire and release functions:
+
+.. kernel-doc:: kernel/bpf/helpers.c
+ :identifiers: bpf_cgroup_acquire bpf_cgroup_release
+
+These kfuncs are used in exactly the same manner as bpf_task_acquire() and
+bpf_task_release() respectively, so we won't provide examples for them.
+
+----
+
+Other kfuncs available for interacting with ``struct cgroup *`` objects are
+bpf_cgroup_ancestor() and bpf_cgroup_from_id(), allowing callers to access
+the ancestor of a cgroup and find a cgroup by its ID, respectively. Both
+return a cgroup kptr.
+
+.. kernel-doc:: kernel/bpf/helpers.c
+ :identifiers: bpf_cgroup_ancestor
+
+.. kernel-doc:: kernel/bpf/helpers.c
+ :identifiers: bpf_cgroup_from_id
+
+Eventually, BPF should be updated to allow this to happen with a normal memory
+load in the program itself. This is currently not possible without more work in
+the verifier. bpf_cgroup_ancestor() can be used as follows:
+
+.. code-block:: c
+
+ /**
+ * Simple tracepoint example that illustrates how a cgroup's
+ * ancestor can be accessed using bpf_cgroup_ancestor().
+ */
+ SEC("tp_btf/cgroup_mkdir")
+ int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path)
+ {
+ struct cgroup *parent;
+
+ /* The parent cgroup resides at the level before the current cgroup's level. */
+ parent = bpf_cgroup_ancestor(cgrp, cgrp->level - 1);
+ if (!parent)
+ return -ENOENT;
+
+ bpf_printk("Parent id is %d", parent->self.id);
+
+ /* Return the parent cgroup that was acquired above. */
+ bpf_cgroup_release(parent);
+ return 0;
+ }
+
+4.3 struct cpumask * kfuncs
+---------------------------
+
+BPF provides a set of kfuncs that can be used to query, allocate, mutate, and
+destroy struct cpumask * objects. Please refer to :ref:`cpumasks-header-label`
+for more details.
diff --git a/Documentation/bpf/libbpf/index.rst b/Documentation/bpf/libbpf/index.rst
index 3722537d1384..7545a2049692 100644
--- a/Documentation/bpf/libbpf/index.rst
+++ b/Documentation/bpf/libbpf/index.rst
@@ -1,21 +1,33 @@
.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
+.. _libbpf:
+
+======
libbpf
======
+If you are looking to develop BPF applications using the libbpf library, this
+directory contains important documentation that you should read.
+
+To get started, it is recommended to begin with the :doc:`libbpf Overview
+<libbpf_overview>` document, which provides a high-level understanding of the
+libbpf APIs and their usage. This will give you a solid foundation to start
+exploring and utilizing the various features of libbpf to develop your BPF
+applications.
+
.. toctree::
:maxdepth: 1
+ libbpf_overview
API Documentation <https://libbpf.readthedocs.io/en/latest/api.html>
+ program_types
libbpf_naming_convention
libbpf_build
-This is documentation for libbpf, a userspace library for loading and
-interacting with bpf programs.
-All general BPF questions, including kernel functionality, libbpf APIs and
-their application, should be sent to bpf@vger.kernel.org mailing list.
-You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the
-mailing list search its `archive <https://lore.kernel.org/bpf/>`_.
-Please search the archive before asking new questions. It very well might
-be that this was already addressed or answered before.
+All general BPF questions, including kernel functionality, libbpf APIs and their
+application, should be sent to bpf@vger.kernel.org mailing list. You can
+`subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the mailing list
+search its `archive <https://lore.kernel.org/bpf/>`_. Please search the archive
+before asking new questions. It may be that this was already addressed or
+answered before.
diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst
index c5ac97f3d4c4..b5b41b61b3c0 100644
--- a/Documentation/bpf/libbpf/libbpf_naming_convention.rst
+++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst
@@ -83,8 +83,8 @@ This prevents from accidentally exporting a symbol, that is not supposed
to be a part of ABI what, in turn, improves both libbpf developer- and
user-experiences.
-ABI versionning
----------------
+ABI versioning
+--------------
To make future ABI extensions possible libbpf ABI is versioned.
Versioning is implemented by ``libbpf.map`` version script that is
@@ -148,7 +148,7 @@ API documentation convention
The libbpf API is documented via comments above definitions in
header files. These comments can be rendered by doxygen and sphinx
for well organized html output. This section describes the
-convention in which these comments should be formated.
+convention in which these comments should be formatted.
Here is an example from btf.h:
diff --git a/Documentation/bpf/libbpf/libbpf_overview.rst b/Documentation/bpf/libbpf/libbpf_overview.rst
new file mode 100644
index 000000000000..f4d22f0c62b0
--- /dev/null
+++ b/Documentation/bpf/libbpf/libbpf_overview.rst
@@ -0,0 +1,236 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+libbpf Overview
+===============
+
+libbpf is a C-based library containing a BPF loader that takes compiled BPF
+object files and prepares and loads them into the Linux kernel. libbpf takes the
+heavy lifting of loading, verifying, and attaching BPF programs to various
+kernel hooks, allowing BPF application developers to focus only on BPF program
+correctness and performance.
+
+The following are the high-level features supported by libbpf:
+
+* Provides high-level and low-level APIs for user space programs to interact
+ with BPF programs. The low-level APIs wrap all the bpf system call
+ functionality, which is useful when users need more fine-grained control
+ over the interactions between user space and BPF programs.
+* Provides overall support for the BPF object skeleton generated by bpftool.
+ The skeleton file simplifies the process for the user space programs to access
+ global variables and work with BPF programs.
+* Provides BPF-side APIS, including BPF helper definitions, BPF maps support,
+ and tracing helpers, allowing developers to simplify BPF code writing.
+* Supports BPF CO-RE mechanism, enabling BPF developers to write portable
+ BPF programs that can be compiled once and run across different kernel
+ versions.
+
+This document will delve into the above concepts in detail, providing a deeper
+understanding of the capabilities and advantages of libbpf and how it can help
+you develop BPF applications efficiently.
+
+BPF App Lifecycle and libbpf APIs
+==================================
+
+A BPF application consists of one or more BPF programs (either cooperating or
+completely independent), BPF maps, and global variables. The global
+variables are shared between all BPF programs, which allows them to cooperate on
+a common set of data. libbpf provides APIs that user space programs can use to
+manipulate the BPF programs by triggering different phases of a BPF application
+lifecycle.
+
+The following section provides a brief overview of each phase in the BPF life
+cycle:
+
+* **Open phase**: In this phase, libbpf parses the BPF
+ object file and discovers BPF maps, BPF programs, and global variables. After
+ a BPF app is opened, user space apps can make additional adjustments
+ (setting BPF program types, if necessary; pre-setting initial values for
+ global variables, etc.) before all the entities are created and loaded.
+
+* **Load phase**: In the load phase, libbpf creates BPF
+ maps, resolves various relocations, and verifies and loads BPF programs into
+ the kernel. At this point, libbpf validates all the parts of a BPF application
+ and loads the BPF program into the kernel, but no BPF program has yet been
+ executed. After the load phase, it’s possible to set up the initial BPF map
+ state without racing with the BPF program code execution.
+
+* **Attachment phase**: In this phase, libbpf
+ attaches BPF programs to various BPF hook points (e.g., tracepoints, kprobes,
+ cgroup hooks, network packet processing pipeline, etc.). During this
+ phase, BPF programs perform useful work such as processing
+ packets, or updating BPF maps and global variables that can be read from user
+ space.
+
+* **Tear down phase**: In the tear down phase,
+ libbpf detaches BPF programs and unloads them from the kernel. BPF maps are
+ destroyed, and all the resources used by the BPF app are freed.
+
+BPF Object Skeleton File
+========================
+
+BPF skeleton is an alternative interface to libbpf APIs for working with BPF
+objects. Skeleton code abstract away generic libbpf APIs to significantly
+simplify code for manipulating BPF programs from user space. Skeleton code
+includes a bytecode representation of the BPF object file, simplifying the
+process of distributing your BPF code. With BPF bytecode embedded, there are no
+extra files to deploy along with your application binary.
+
+You can generate the skeleton header file ``(.skel.h)`` for a specific object
+file by passing the BPF object to the bpftool. The generated BPF skeleton
+provides the following custom functions that correspond to the BPF lifecycle,
+each of them prefixed with the specific object name:
+
+* ``<name>__open()`` – creates and opens BPF application (``<name>`` stands for
+ the specific bpf object name)
+* ``<name>__load()`` – instantiates, loads,and verifies BPF application parts
+* ``<name>__attach()`` – attaches all auto-attachable BPF programs (it’s
+ optional, you can have more control by using libbpf APIs directly)
+* ``<name>__destroy()`` – detaches all BPF programs and
+ frees up all used resources
+
+Using the skeleton code is the recommended way to work with bpf programs. Keep
+in mind, BPF skeleton provides access to the underlying BPF object, so whatever
+was possible to do with generic libbpf APIs is still possible even when the BPF
+skeleton is used. It's an additive convenience feature, with no syscalls, and no
+cumbersome code.
+
+Other Advantages of Using Skeleton File
+---------------------------------------
+
+* BPF skeleton provides an interface for user space programs to work with BPF
+ global variables. The skeleton code memory maps global variables as a struct
+ into user space. The struct interface allows user space programs to initialize
+ BPF programs before the BPF load phase and fetch and update data from user
+ space afterward.
+
+* The ``skel.h`` file reflects the object file structure by listing out the
+ available maps, programs, etc. BPF skeleton provides direct access to all the
+ BPF maps and BPF programs as struct fields. This eliminates the need for
+ string-based lookups with ``bpf_object_find_map_by_name()`` and
+ ``bpf_object_find_program_by_name()`` APIs, reducing errors due to BPF source
+ code and user-space code getting out of sync.
+
+* The embedded bytecode representation of the object file ensures that the
+ skeleton and the BPF object file are always in sync.
+
+BPF Helpers
+===========
+
+libbpf provides BPF-side APIs that BPF programs can use to interact with the
+system. The BPF helpers definition allows developers to use them in BPF code as
+any other plain C function. For example, there are helper functions to print
+debugging messages, get the time since the system was booted, interact with BPF
+maps, manipulate network packets, etc.
+
+For a complete description of what the helpers do, the arguments they take, and
+the return value, see the `bpf-helpers
+<https://man7.org/linux/man-pages/man7/bpf-helpers.7.html>`_ man page.
+
+BPF CO-RE (Compile Once – Run Everywhere)
+=========================================
+
+BPF programs work in the kernel space and have access to kernel memory and data
+structures. One limitation that BPF applications come across is the lack of
+portability across different kernel versions and configurations. `BCC
+<https://github.com/iovisor/bcc/>`_ is one of the solutions for BPF
+portability. However, it comes with runtime overhead and a large binary size
+from embedding the compiler with the application.
+
+libbpf steps up the BPF program portability by supporting the BPF CO-RE concept.
+BPF CO-RE brings together BTF type information, libbpf, and the compiler to
+produce a single executable binary that you can run on multiple kernel versions
+and configurations.
+
+To make BPF programs portable libbpf relies on the BTF type information of the
+running kernel. Kernel also exposes this self-describing authoritative BTF
+information through ``sysfs`` at ``/sys/kernel/btf/vmlinux``.
+
+You can generate the BTF information for the running kernel with the following
+command:
+
+::
+
+ $ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
+
+The command generates a ``vmlinux.h`` header file with all kernel types
+(:doc:`BTF types <../btf>`) that the running kernel uses. Including
+``vmlinux.h`` in your BPF program eliminates dependency on system-wide kernel
+headers.
+
+libbpf enables portability of BPF programs by looking at the BPF program’s
+recorded BTF type and relocation information and matching them to BTF
+information (vmlinux) provided by the running kernel. libbpf then resolves and
+matches all the types and fields, and updates necessary offsets and other
+relocatable data to ensure that BPF program’s logic functions correctly for a
+specific kernel on the host. BPF CO-RE concept thus eliminates overhead
+associated with BPF development and allows developers to write portable BPF
+applications without modifications and runtime source code compilation on the
+target machine.
+
+The following code snippet shows how to read the parent field of a kernel
+``task_struct`` using BPF CO-RE and libbf. The basic helper to read a field in a
+CO-RE relocatable manner is ``bpf_core_read(dst, sz, src)``, which will read
+``sz`` bytes from the field referenced by ``src`` into the memory pointed to by
+``dst``.
+
+.. code-block:: C
+ :emphasize-lines: 6
+
+ //...
+ struct task_struct *task = (void *)bpf_get_current_task();
+ struct task_struct *parent_task;
+ int err;
+
+ err = bpf_core_read(&parent_task, sizeof(void *), &task->parent);
+ if (err) {
+ /* handle error */
+ }
+
+ /* parent_task contains the value of task->parent pointer */
+
+In the code snippet, we first get a pointer to the current ``task_struct`` using
+``bpf_get_current_task()``. We then use ``bpf_core_read()`` to read the parent
+field of task struct into the ``parent_task`` variable. ``bpf_core_read()`` is
+just like ``bpf_probe_read_kernel()`` BPF helper, except it records information
+about the field that should be relocated on the target kernel. i.e, if the
+``parent`` field gets shifted to a different offset within
+``struct task_struct`` due to some new field added in front of it, libbpf will
+automatically adjust the actual offset to the proper value.
+
+Getting Started with libbpf
+===========================
+
+Check out the `libbpf-bootstrap <https://github.com/libbpf/libbpf-bootstrap>`_
+repository with simple examples of using libbpf to build various BPF
+applications.
+
+See also `libbpf API documentation
+<https://libbpf.readthedocs.io/en/latest/api.html>`_.
+
+libbpf and Rust
+===============
+
+If you are building BPF applications in Rust, it is recommended to use the
+`Libbpf-rs <https://github.com/libbpf/libbpf-rs>`_ library instead of bindgen
+bindings directly to libbpf. Libbpf-rs wraps libbpf functionality in
+Rust-idiomatic interfaces and provides libbpf-cargo plugin to handle BPF code
+compilation and skeleton generation. Using Libbpf-rs will make building user
+space part of the BPF application easier. Note that the BPF program themselves
+must still be written in plain C.
+
+libbpf logging
+==============
+
+By default, libbpf logs informational and warning messages to stderr. The
+verbosity of these messages can be controlled by setting the environment
+variable LIBBPF_LOG_LEVEL to either warn, info, or debug. A custom log
+callback can be set using ``libbpf_set_print()``.
+
+Additional Documentation
+========================
+
+* `Program types and ELF Sections <https://libbpf.readthedocs.io/en/latest/program_types.html>`_
+* `API naming convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html>`_
+* `Building libbpf <https://libbpf.readthedocs.io/en/latest/libbpf_build.html>`_
+* `API documentation Convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html#api-documentation-convention>`_
diff --git a/Documentation/bpf/libbpf/program_types.rst b/Documentation/bpf/libbpf/program_types.rst
new file mode 100644
index 000000000000..3b837522834b
--- /dev/null
+++ b/Documentation/bpf/libbpf/program_types.rst
@@ -0,0 +1,253 @@
+.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
+
+.. _program_types_and_elf:
+
+Program Types and ELF Sections
+==============================
+
+The table below lists the program types, their attach types where relevant and the ELF section
+names supported by libbpf for them. The ELF section names follow these rules:
+
+- ``type`` is an exact match, e.g. ``SEC("socket")``
+- ``type+`` means it can be either exact ``SEC("type")`` or well-formed ``SEC("type/extras")``
+ with a '``/``' separator between ``type`` and ``extras``.
+
+When ``extras`` are specified, they provide details of how to auto-attach the BPF program. The
+format of ``extras`` depends on the program type, e.g. ``SEC("tracepoint/<category>/<name>")``
+for tracepoints or ``SEC("usdt/<path>:<provider>:<name>")`` for USDT probes. The extras are
+described in more detail in the footnotes.
+
+
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| Program Type | Attach Type | ELF Section Name | Sleepable |
++===========================================+========================================+==================================+===========+
+| ``BPF_PROG_TYPE_CGROUP_DEVICE`` | ``BPF_CGROUP_DEVICE`` | ``cgroup/dev`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_CGROUP_SKB`` | | ``cgroup/skb`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET_EGRESS`` | ``cgroup_skb/egress`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET_INGRESS`` | ``cgroup_skb/ingress`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_CGROUP_SOCKOPT`` | ``BPF_CGROUP_GETSOCKOPT`` | ``cgroup/getsockopt`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_SETSOCKOPT`` | ``cgroup/setsockopt`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_CGROUP_SOCK_ADDR`` | ``BPF_CGROUP_INET4_BIND`` | ``cgroup/bind4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET4_CONNECT`` | ``cgroup/connect4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET4_GETPEERNAME`` | ``cgroup/getpeername4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET4_GETSOCKNAME`` | ``cgroup/getsockname4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET6_BIND`` | ``cgroup/bind6`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET6_CONNECT`` | ``cgroup/connect6`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET6_GETPEERNAME`` | ``cgroup/getpeername6`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET6_GETSOCKNAME`` | ``cgroup/getsockname6`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UDP4_RECVMSG`` | ``cgroup/recvmsg4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UDP4_SENDMSG`` | ``cgroup/sendmsg4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UDP6_RECVMSG`` | ``cgroup/recvmsg6`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UDP6_SENDMSG`` | ``cgroup/sendmsg6`` | |
+| +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UNIX_CONNECT`` | ``cgroup/connect_unix`` | |
+| +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UNIX_SENDMSG`` | ``cgroup/sendmsg_unix`` | |
+| +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UNIX_RECVMSG`` | ``cgroup/recvmsg_unix`` | |
+| +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UNIX_GETPEERNAME`` | ``cgroup/getpeername_unix`` | |
+| +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_UNIX_GETSOCKNAME`` | ``cgroup/getsockname_unix`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_CGROUP_SOCK`` | ``BPF_CGROUP_INET4_POST_BIND`` | ``cgroup/post_bind4`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET6_POST_BIND`` | ``cgroup/post_bind6`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET_SOCK_CREATE`` | ``cgroup/sock_create`` | |
++ + +----------------------------------+-----------+
+| | | ``cgroup/sock`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_CGROUP_INET_SOCK_RELEASE`` | ``cgroup/sock_release`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_CGROUP_SYSCTL`` | ``BPF_CGROUP_SYSCTL`` | ``cgroup/sysctl`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_EXT`` | | ``freplace+`` [#fentry]_ | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_FLOW_DISSECTOR`` | ``BPF_FLOW_DISSECTOR`` | ``flow_dissector`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_KPROBE`` | | ``kprobe+`` [#kprobe]_ | |
++ + +----------------------------------+-----------+
+| | | ``kretprobe+`` [#kprobe]_ | |
++ + +----------------------------------+-----------+
+| | | ``ksyscall+`` [#ksyscall]_ | |
++ + +----------------------------------+-----------+
+| | | ``kretsyscall+`` [#ksyscall]_ | |
++ + +----------------------------------+-----------+
+| | | ``uprobe+`` [#uprobe]_ | |
++ + +----------------------------------+-----------+
+| | | ``uprobe.s+`` [#uprobe]_ | Yes |
++ + +----------------------------------+-----------+
+| | | ``uretprobe+`` [#uprobe]_ | |
++ + +----------------------------------+-----------+
+| | | ``uretprobe.s+`` [#uprobe]_ | Yes |
++ + +----------------------------------+-----------+
+| | | ``usdt+`` [#usdt]_ | |
++ + +----------------------------------+-----------+
+| | | ``usdt.s+`` [#usdt]_ | Yes |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_KPROBE_MULTI`` | ``kprobe.multi+`` [#kpmulti]_ | |
++ + +----------------------------------+-----------+
+| | | ``kretprobe.multi+`` [#kpmulti]_ | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_KPROBE_SESSION`` | ``kprobe.session+`` [#kpmulti]_ | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_UPROBE_MULTI`` | ``uprobe.multi+`` [#upmul]_ | |
++ + +----------------------------------+-----------+
+| | | ``uprobe.multi.s+`` [#upmul]_ | Yes |
++ + +----------------------------------+-----------+
+| | | ``uretprobe.multi+`` [#upmul]_ | |
++ + +----------------------------------+-----------+
+| | | ``uretprobe.multi.s+`` [#upmul]_ | Yes |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_UPROBE_SESSION`` | ``uprobe.session+`` [#upmul]_ | |
++ + +----------------------------------+-----------+
+| | | ``uprobe.session.s+`` [#upmul]_ | Yes |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_LIRC_MODE2`` | ``BPF_LIRC_MODE2`` | ``lirc_mode2`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_LSM`` | ``BPF_LSM_CGROUP`` | ``lsm_cgroup+`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_LSM_MAC`` | ``lsm+`` [#lsm]_ | |
++ + +----------------------------------+-----------+
+| | | ``lsm.s+`` [#lsm]_ | Yes |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_LWT_IN`` | | ``lwt_in`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_LWT_OUT`` | | ``lwt_out`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_LWT_SEG6LOCAL`` | | ``lwt_seg6local`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_LWT_XMIT`` | | ``lwt_xmit`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_NETFILTER`` | | ``netfilter`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_PERF_EVENT`` | | ``perf_event`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE`` | | ``raw_tp.w+`` [#rawtp]_ | |
++ + +----------------------------------+-----------+
+| | | ``raw_tracepoint.w+`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_RAW_TRACEPOINT`` | | ``raw_tp+`` [#rawtp]_ | |
++ + +----------------------------------+-----------+
+| | | ``raw_tracepoint+`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SCHED_ACT`` | | ``action`` [#tc_legacy]_ | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SCHED_CLS`` | | ``classifier`` [#tc_legacy]_ | |
++ + +----------------------------------+-----------+
+| | | ``tc`` [#tc_legacy]_ | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_NETKIT_PRIMARY`` | ``netkit/primary`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_NETKIT_PEER`` | ``netkit/peer`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TCX_INGRESS`` | ``tc/ingress`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TCX_EGRESS`` | ``tc/egress`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TCX_INGRESS`` | ``tcx/ingress`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TCX_EGRESS`` | ``tcx/egress`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SK_LOOKUP`` | ``BPF_SK_LOOKUP`` | ``sk_lookup`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SK_MSG`` | ``BPF_SK_MSG_VERDICT`` | ``sk_msg`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SK_REUSEPORT`` | ``BPF_SK_REUSEPORT_SELECT_OR_MIGRATE`` | ``sk_reuseport/migrate`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_SK_REUSEPORT_SELECT`` | ``sk_reuseport`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SK_SKB`` | | ``sk_skb`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_SK_SKB_STREAM_PARSER`` | ``sk_skb/stream_parser`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_SK_SKB_STREAM_VERDICT`` | ``sk_skb/stream_verdict`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SOCKET_FILTER`` | | ``socket`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SOCK_OPS`` | ``BPF_CGROUP_SOCK_OPS`` | ``sockops`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_STRUCT_OPS`` | | ``struct_ops+`` [#struct_ops]_ | |
++ + +----------------------------------+-----------+
+| | | ``struct_ops.s+`` [#struct_ops]_ | Yes |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_SYSCALL`` | | ``syscall`` | Yes |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_TRACEPOINT`` | | ``tp+`` [#tp]_ | |
++ + +----------------------------------+-----------+
+| | | ``tracepoint+`` [#tp]_ | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_TRACING`` | ``BPF_MODIFY_RETURN`` | ``fmod_ret+`` [#fentry]_ | |
++ + +----------------------------------+-----------+
+| | | ``fmod_ret.s+`` [#fentry]_ | Yes |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_FENTRY`` | ``fentry+`` [#fentry]_ | |
++ + +----------------------------------+-----------+
+| | | ``fentry.s+`` [#fentry]_ | Yes |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_FEXIT`` | ``fexit+`` [#fentry]_ | |
++ + +----------------------------------+-----------+
+| | | ``fexit.s+`` [#fentry]_ | Yes |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_ITER`` | ``iter+`` [#iter]_ | |
++ + +----------------------------------+-----------+
+| | | ``iter.s+`` [#iter]_ | Yes |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_TRACE_RAW_TP`` | ``tp_btf+`` [#fentry]_ | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+| ``BPF_PROG_TYPE_XDP`` | ``BPF_XDP_CPUMAP`` | ``xdp.frags/cpumap`` | |
++ + +----------------------------------+-----------+
+| | | ``xdp/cpumap`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_XDP_DEVMAP`` | ``xdp.frags/devmap`` | |
++ + +----------------------------------+-----------+
+| | | ``xdp/devmap`` | |
++ +----------------------------------------+----------------------------------+-----------+
+| | ``BPF_XDP`` | ``xdp.frags`` | |
++ + +----------------------------------+-----------+
+| | | ``xdp`` | |
++-------------------------------------------+----------------------------------------+----------------------------------+-----------+
+
+
+.. rubric:: Footnotes
+
+.. [#fentry] The ``fentry`` attach format is ``fentry[.s]/<function>``.
+.. [#kprobe] The ``kprobe`` attach format is ``kprobe/<function>[+<offset>]``. Valid
+ characters for ``function`` are ``a-zA-Z0-9_.`` and ``offset`` must be a valid
+ non-negative integer.
+.. [#ksyscall] The ``ksyscall`` attach format is ``ksyscall/<syscall>``.
+.. [#uprobe] The ``uprobe`` attach format is ``uprobe[.s]/<path>:<function>[+<offset>]``.
+.. [#upmul] The ``uprobe.multi`` attach format is ``uprobe.multi[.s]/<path>:<function-pattern>``
+ where ``function-pattern`` supports ``*`` and ``?`` wildcards.
+.. [#usdt] The ``usdt`` attach format is ``usdt/<path>:<provider>:<name>``.
+.. [#kpmulti] The ``kprobe.multi`` attach format is ``kprobe.multi/<pattern>`` where ``pattern``
+ supports ``*`` and ``?`` wildcards. Valid characters for pattern are
+ ``a-zA-Z0-9_.*?``.
+.. [#lsm] The ``lsm`` attachment format is ``lsm[.s]/<hook>``.
+.. [#rawtp] The ``raw_tp`` attach format is ``raw_tracepoint[.w]/<tracepoint>``.
+.. [#tc_legacy] The ``tc``, ``classifier`` and ``action`` attach types are deprecated, use
+ ``tcx/*`` instead.
+.. [#struct_ops] The ``struct_ops`` attach format supports ``struct_ops[.s]/<name>`` convention,
+ but ``name`` is ignored and it is recommended to just use plain
+ ``SEC("struct_ops[.s]")``. The attachments are defined in a struct initializer
+ that is tagged with ``SEC(".struct_ops[.link]")``.
+.. [#tp] The ``tracepoint`` attach format is ``tracepoint/<category>/<name>``.
+.. [#iter] The ``iter`` attach format is ``iter[.s]/<struct-name>``.
diff --git a/Documentation/bpf/linux-notes.rst b/Documentation/bpf/linux-notes.rst
index 956b0c86699d..00d2693de025 100644
--- a/Documentation/bpf/linux-notes.rst
+++ b/Documentation/bpf/linux-notes.rst
@@ -12,10 +12,41 @@ Byte swap instructions
``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
+Jump instructions
+=================
+
+``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function
+integer would be read from a specified register, is not currently supported
+by the verifier. Any programs with this instruction will fail to load
+until such support is added.
+
+Maps
+====
+
+Linux only supports the 'map_val(map)' operation on array maps with a single element.
+
+Linux uses an fd_array to store maps associated with a BPF program. Thus,
+map_by_idx(imm) uses the fd at that index in the array.
+
+Variables
+=========
+
+The following 64-bit immediate instruction specifies that a variable address,
+which corresponds to some integer stored in the 'imm' field, should be loaded:
+
+========================= ====== === ========================================= =========== ==============
+opcode construction opcode src pseudocode imm type dst type
+========================= ====== === ========================================= =========== ==============
+BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
+========================= ====== === ========================================= =========== ==============
+
+On Linux, this integer is a BTF ID.
+
Legacy BPF Packet access instructions
=====================================
-As mentioned in the `ISA standard documentation <instruction-set.rst#legacy-bpf-packet-access-instructions>`_,
+As mentioned in the `ISA standard documentation
+<instruction-set.html#legacy-bpf-packet-access-instructions>`_,
Linux has special eBPF instructions for access to packet data that have been
carried over from classic BPF to retain the performance of legacy socket
filters running in the eBPF interpreter.
diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst
index ca8957d5b671..44188e219d32 100644
--- a/Documentation/bpf/llvm_reloc.rst
+++ b/Documentation/bpf/llvm_reloc.rst
@@ -28,7 +28,7 @@ For example, for the following code::
return g1 + g2 + l1 + l2;
}
-Compiled with ``clang -target bpf -O2 -c test.c``, the following is
+Compiled with ``clang --target=bpf -O2 -c test.c``, the following is
the code with ``llvm-objdump -dr test.o``::
0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
@@ -48,7 +48,7 @@ the code with ``llvm-objdump -dr test.o``::
14: 0f 10 00 00 00 00 00 00 r0 += r1
15: 95 00 00 00 00 00 00 00 exit
-There are four relations in the above for four ``LD_imm64`` instructions.
+There are four relocations in the above for four ``LD_imm64`` instructions.
The following ``llvm-readelf -r test.o`` shows the binary values of the four
relocations::
@@ -79,14 +79,16 @@ The following is the symbol table with ``llvm-readelf -s test.o``::
The 6th entry is global variable ``g1`` with value 0.
Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3,
-for global variable ``g2`` which has a symbol value 4, the offset
-from the start of ``.data`` section.
-
-The third and fourth relocations refers to static variables ``l1``
-and ``l2``. From ``.rel.text`` section above, it is not clear
-which symbols they really refers to as they both refers to
+has a type of ``R_BPF_64_64`` and refers to entry 7 in the symbol table.
+The second relocation resolves to global variable ``g2`` which has a symbol
+value 4. The symbol value represents the offset from the start of ``.data``
+section where the initial value of the global variable ``g2`` is stored.
+
+The third and fourth relocations refer to static variables ``l1``
+and ``l2``. From the ``.rel.text`` section above, it is not clear
+to which symbols they really refer as they both refer to
symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type
-and represents a section. So for static variable or function,
+and represents a section. So for a static variable or function,
the section offset is written to the original insn
buffer, which is called ``A`` (addend). Looking at
above insn ``7`` and ``11``, they have section offset ``8`` and ``12``.
@@ -155,7 +157,7 @@ and ``call`` instructions. For example::
return gfunc(a, b) + lfunc(a, b) + global;
}
-Compiled with ``clang -target bpf -O2 -c test.c``, we will have
+Compiled with ``clang --target=bpf -O2 -c test.c``, we will have
following code with `llvm-objdump -dr test.o``::
Disassembly of section .text:
@@ -201,7 +203,7 @@ The following is an example to show how R_BPF_64_ABS64 could be generated::
int global() { return 0; }
struct t { void *g; } gbl = { global };
-Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a
+Compiled with ``clang --target=bpf -O2 -g -c test.c``, we will see a
relocation below in ``.data`` section with command
``llvm-readelf -r test.o``::
@@ -238,3 +240,307 @@ The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations::
Offset Info Type Symbol's Value Symbol's Name
000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text
0000000000000040 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text
+
+.. _btf-co-re-relocations:
+
+=================
+CO-RE Relocations
+=================
+
+From object file point of view CO-RE mechanism is implemented as a set
+of CO-RE specific relocation records. These relocation records are not
+related to ELF relocations and are encoded in .BTF.ext section.
+See :ref:`Documentation/bpf/btf.rst <BTF_Ext_Section>` for more
+information on .BTF.ext structure.
+
+CO-RE relocations are applied to BPF instructions to update immediate
+or offset fields of the instruction at load time with information
+relevant for target kernel.
+
+Field to patch is selected basing on the instruction class:
+
+* For BPF_ALU, BPF_ALU64, BPF_LD `immediate` field is patched;
+* For BPF_LDX, BPF_STX, BPF_ST `offset` field is patched;
+* BPF_JMP, BPF_JMP32 instructions **should not** be patched.
+
+Relocation kinds
+================
+
+There are several kinds of CO-RE relocations that could be split in
+three groups:
+
+* Field-based - patch instruction with field related information, e.g.
+ change offset field of the BPF_LDX instruction to reflect offset
+ of a specific structure field in the target kernel.
+
+* Type-based - patch instruction with type related information, e.g.
+ change immediate field of the BPF_ALU move instruction to 0 or 1 to
+ reflect if specific type is present in the target kernel.
+
+* Enum-based - patch instruction with enum related information, e.g.
+ change immediate field of the BPF_LD_IMM64 instruction to reflect
+ value of a specific enum literal in the target kernel.
+
+The complete list of relocation kinds is represented by the following enum:
+
+.. code-block:: c
+
+ enum bpf_core_relo_kind {
+ BPF_CORE_FIELD_BYTE_OFFSET = 0, /* field byte offset */
+ BPF_CORE_FIELD_BYTE_SIZE = 1, /* field size in bytes */
+ BPF_CORE_FIELD_EXISTS = 2, /* field existence in target kernel */
+ BPF_CORE_FIELD_SIGNED = 3, /* field signedness (0 - unsigned, 1 - signed) */
+ BPF_CORE_FIELD_LSHIFT_U64 = 4, /* bitfield-specific left bitshift */
+ BPF_CORE_FIELD_RSHIFT_U64 = 5, /* bitfield-specific right bitshift */
+ BPF_CORE_TYPE_ID_LOCAL = 6, /* type ID in local BPF object */
+ BPF_CORE_TYPE_ID_TARGET = 7, /* type ID in target kernel */
+ BPF_CORE_TYPE_EXISTS = 8, /* type existence in target kernel */
+ BPF_CORE_TYPE_SIZE = 9, /* type size in bytes */
+ BPF_CORE_ENUMVAL_EXISTS = 10, /* enum value existence in target kernel */
+ BPF_CORE_ENUMVAL_VALUE = 11, /* enum value integer value */
+ BPF_CORE_TYPE_MATCHES = 12, /* type match in target kernel */
+ };
+
+Notes:
+
+* ``BPF_CORE_FIELD_LSHIFT_U64`` and ``BPF_CORE_FIELD_RSHIFT_U64`` are
+ supposed to be used to read bitfield values using the following
+ algorithm:
+
+ .. code-block:: c
+
+ // To read bitfield ``f`` from ``struct s``
+ is_signed = relo(s->f, BPF_CORE_FIELD_SIGNED)
+ off = relo(s->f, BPF_CORE_FIELD_BYTE_OFFSET)
+ sz = relo(s->f, BPF_CORE_FIELD_BYTE_SIZE)
+ l = relo(s->f, BPF_CORE_FIELD_LSHIFT_U64)
+ r = relo(s->f, BPF_CORE_FIELD_RSHIFT_U64)
+ // define ``v`` as signed or unsigned integer of size ``sz``
+ v = *({s|u}<sz> *)((void *)s + off)
+ v <<= l
+ v >>= r
+
+* The ``BPF_CORE_TYPE_MATCHES`` queries matching relation, defined as
+ follows:
+
+ * for integers: types match if size and signedness match;
+ * for arrays & pointers: target types are recursively matched;
+ * for structs & unions:
+
+ * local members need to exist in target with the same name;
+
+ * for each member we recursively check match unless it is already behind a
+ pointer, in which case we only check matching names and compatible kind;
+
+ * for enums:
+
+ * local variants have to have a match in target by symbolic name (but not
+ numeric value);
+
+ * size has to match (but enum may match enum64 and vice versa);
+
+ * for function pointers:
+
+ * number and position of arguments in local type has to match target;
+ * for each argument and the return value we recursively check match.
+
+CO-RE Relocation Record
+=======================
+
+Relocation record is encoded as the following structure:
+
+.. code-block:: c
+
+ struct bpf_core_relo {
+ __u32 insn_off;
+ __u32 type_id;
+ __u32 access_str_off;
+ enum bpf_core_relo_kind kind;
+ };
+
+* ``insn_off`` - instruction offset (in bytes) within a code section
+ associated with this relocation;
+
+* ``type_id`` - BTF type ID of the "root" (containing) entity of a
+ relocatable type or field;
+
+* ``access_str_off`` - offset into corresponding .BTF string section.
+ String interpretation depends on specific relocation kind:
+
+ * for field-based relocations, string encodes an accessed field using
+ a sequence of field and array indices, separated by colon (:). It's
+ conceptually very close to LLVM's `getelementptr <GEP_>`_ instruction's
+ arguments for identifying offset to a field. For example, consider the
+ following C code:
+
+ .. code-block:: c
+
+ struct sample {
+ int a;
+ int b;
+ struct { int c[10]; };
+ } __attribute__((preserve_access_index));
+ struct sample *s;
+
+ * Access to ``s[0].a`` would be encoded as ``0:0``:
+
+ * ``0``: first element of ``s`` (as if ``s`` is an array);
+ * ``0``: index of field ``a`` in ``struct sample``.
+
+ * Access to ``s->a`` would be encoded as ``0:0`` as well.
+ * Access to ``s->b`` would be encoded as ``0:1``:
+
+ * ``0``: first element of ``s``;
+ * ``1``: index of field ``b`` in ``struct sample``.
+
+ * Access to ``s[1].c[5]`` would be encoded as ``1:2:0:5``:
+
+ * ``1``: second element of ``s``;
+ * ``2``: index of anonymous structure field in ``struct sample``;
+ * ``0``: index of field ``c`` in anonymous structure;
+ * ``5``: access to array element #5.
+
+ * for type-based relocations, string is expected to be just "0";
+
+ * for enum value-based relocations, string contains an index of enum
+ value within its enum type;
+
+* ``kind`` - one of ``enum bpf_core_relo_kind``.
+
+.. _GEP: https://llvm.org/docs/LangRef.html#getelementptr-instruction
+
+.. _btf_co_re_relocation_examples:
+
+CO-RE Relocation Examples
+=========================
+
+For the following C code:
+
+.. code-block:: c
+
+ struct foo {
+ int a;
+ int b;
+ unsigned c:15;
+ } __attribute__((preserve_access_index));
+
+ enum bar { U, V };
+
+With the following BTF definitions:
+
+.. code-block::
+
+ ...
+ [2] STRUCT 'foo' size=8 vlen=2
+ 'a' type_id=3 bits_offset=0
+ 'b' type_id=3 bits_offset=32
+ 'c' type_id=4 bits_offset=64 bitfield_size=15
+ [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
+ [4] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
+ ...
+ [16] ENUM 'bar' encoding=UNSIGNED size=4 vlen=2
+ 'U' val=0
+ 'V' val=1
+
+Field offset relocations are generated automatically when
+``__attribute__((preserve_access_index))`` is used, for example:
+
+.. code-block:: c
+
+ void alpha(struct foo *s, volatile unsigned long *g) {
+ *g = s->a;
+ s->a = 1;
+ }
+
+ 00 <alpha>:
+ 0: r3 = *(s32 *)(r1 + 0x0)
+ 00: CO-RE <byte_off> [2] struct foo::a (0:0)
+ 1: *(u64 *)(r2 + 0x0) = r3
+ 2: *(u32 *)(r1 + 0x0) = 0x1
+ 10: CO-RE <byte_off> [2] struct foo::a (0:0)
+ 3: exit
+
+
+All relocation kinds could be requested via built-in functions.
+E.g. field-based relocations:
+
+.. code-block:: c
+
+ void bravo(struct foo *s, volatile unsigned long *g) {
+ *g = __builtin_preserve_field_info(s->b, 0 /* field byte offset */);
+ *g = __builtin_preserve_field_info(s->b, 1 /* field byte size */);
+ *g = __builtin_preserve_field_info(s->b, 2 /* field existence */);
+ *g = __builtin_preserve_field_info(s->b, 3 /* field signedness */);
+ *g = __builtin_preserve_field_info(s->c, 4 /* bitfield left shift */);
+ *g = __builtin_preserve_field_info(s->c, 5 /* bitfield right shift */);
+ }
+
+ 20 <bravo>:
+ 4: r1 = 0x4
+ 20: CO-RE <byte_off> [2] struct foo::b (0:1)
+ 5: *(u64 *)(r2 + 0x0) = r1
+ 6: r1 = 0x4
+ 30: CO-RE <byte_sz> [2] struct foo::b (0:1)
+ 7: *(u64 *)(r2 + 0x0) = r1
+ 8: r1 = 0x1
+ 40: CO-RE <field_exists> [2] struct foo::b (0:1)
+ 9: *(u64 *)(r2 + 0x0) = r1
+ 10: r1 = 0x1
+ 50: CO-RE <signed> [2] struct foo::b (0:1)
+ 11: *(u64 *)(r2 + 0x0) = r1
+ 12: r1 = 0x31
+ 60: CO-RE <lshift_u64> [2] struct foo::c (0:2)
+ 13: *(u64 *)(r2 + 0x0) = r1
+ 14: r1 = 0x31
+ 70: CO-RE <rshift_u64> [2] struct foo::c (0:2)
+ 15: *(u64 *)(r2 + 0x0) = r1
+ 16: exit
+
+
+Type-based relocations:
+
+.. code-block:: c
+
+ void charlie(struct foo *s, volatile unsigned long *g) {
+ *g = __builtin_preserve_type_info(*s, 0 /* type existence */);
+ *g = __builtin_preserve_type_info(*s, 1 /* type size */);
+ *g = __builtin_preserve_type_info(*s, 2 /* type matches */);
+ *g = __builtin_btf_type_id(*s, 0 /* type id in this object file */);
+ *g = __builtin_btf_type_id(*s, 1 /* type id in target kernel */);
+ }
+
+ 88 <charlie>:
+ 17: r1 = 0x1
+ 88: CO-RE <type_exists> [2] struct foo
+ 18: *(u64 *)(r2 + 0x0) = r1
+ 19: r1 = 0xc
+ 98: CO-RE <type_size> [2] struct foo
+ 20: *(u64 *)(r2 + 0x0) = r1
+ 21: r1 = 0x1
+ a8: CO-RE <type_matches> [2] struct foo
+ 22: *(u64 *)(r2 + 0x0) = r1
+ 23: r1 = 0x2 ll
+ b8: CO-RE <local_type_id> [2] struct foo
+ 25: *(u64 *)(r2 + 0x0) = r1
+ 26: r1 = 0x2 ll
+ d0: CO-RE <target_type_id> [2] struct foo
+ 28: *(u64 *)(r2 + 0x0) = r1
+ 29: exit
+
+Enum-based relocations:
+
+.. code-block:: c
+
+ void delta(struct foo *s, volatile unsigned long *g) {
+ *g = __builtin_preserve_enum_value(*(enum bar *)U, 0 /* enum literal existence */);
+ *g = __builtin_preserve_enum_value(*(enum bar *)V, 1 /* enum literal value */);
+ }
+
+ f0 <delta>:
+ 30: r1 = 0x1 ll
+ f0: CO-RE <enumval_exists> [16] enum bar::U = 0
+ 32: *(u64 *)(r2 + 0x0) = r1
+ 33: r1 = 0x1 ll
+ 108: CO-RE <enumval_value> [16] enum bar::V = 1
+ 35: *(u64 *)(r2 + 0x0) = r1
+ 36: exit
diff --git a/Documentation/bpf/map_array.rst b/Documentation/bpf/map_array.rst
new file mode 100644
index 000000000000..fa56ff75190c
--- /dev/null
+++ b/Documentation/bpf/map_array.rst
@@ -0,0 +1,263 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+================================================
+BPF_MAP_TYPE_ARRAY and BPF_MAP_TYPE_PERCPU_ARRAY
+================================================
+
+.. note::
+ - ``BPF_MAP_TYPE_ARRAY`` was introduced in kernel version 3.19
+ - ``BPF_MAP_TYPE_PERCPU_ARRAY`` was introduced in version 4.6
+
+``BPF_MAP_TYPE_ARRAY`` and ``BPF_MAP_TYPE_PERCPU_ARRAY`` provide generic array
+storage. The key type is an unsigned 32-bit integer (4 bytes) and the map is
+of constant size. The size of the array is defined in ``max_entries`` at
+creation time. All array elements are pre-allocated and zero initialized when
+created. ``BPF_MAP_TYPE_PERCPU_ARRAY`` uses a different memory region for each
+CPU whereas ``BPF_MAP_TYPE_ARRAY`` uses the same memory region. The value
+stored can be of any size for ``BPF_MAP_TYPE_ARRAY`` and not more than
+``PCPU_MIN_UNIT_SIZE`` (32 kB) for ``BPF_MAP_TYPE_PERCPU_ARRAY``. All
+array elements are aligned to 8 bytes.
+
+Since kernel 5.5, memory mapping may be enabled for ``BPF_MAP_TYPE_ARRAY`` by
+setting the flag ``BPF_F_MMAPABLE``. The map definition is page-aligned and
+starts on the first page. Sufficient page-sized and page-aligned blocks of
+memory are allocated to store all array values, starting on the second page,
+which in some cases will result in over-allocation of memory. The benefit of
+using this is increased performance and ease of use since userspace programs
+would not be required to use helper functions to access and mutate data.
+
+Usage
+=====
+
+Kernel BPF
+----------
+
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+Array elements can be retrieved using the ``bpf_map_lookup_elem()`` helper.
+This helper returns a pointer into the array element, so to avoid data races
+with userspace reading the value, the user must use primitives like
+``__sync_fetch_and_add()`` when updating the value in-place.
+
+bpf_map_update_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
+
+Array elements can be updated using the ``bpf_map_update_elem()`` helper.
+
+``bpf_map_update_elem()`` returns 0 on success, or negative error in case of
+failure.
+
+Since the array is of constant size, ``bpf_map_delete_elem()`` is not supported.
+To clear an array element, you may use ``bpf_map_update_elem()`` to insert a
+zero value to that index.
+
+Per CPU Array
+-------------
+
+Values stored in ``BPF_MAP_TYPE_ARRAY`` can be accessed by multiple programs
+across different CPUs. To restrict storage to a single CPU, you may use a
+``BPF_MAP_TYPE_PERCPU_ARRAY``.
+
+When using a ``BPF_MAP_TYPE_PERCPU_ARRAY`` the ``bpf_map_update_elem()`` and
+``bpf_map_lookup_elem()`` helpers automatically access the slot for the current
+CPU.
+
+bpf_map_lookup_percpu_elem()
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu)
+
+The ``bpf_map_lookup_percpu_elem()`` helper can be used to lookup the array
+value for a specific CPU. Returns value on success , or ``NULL`` if no entry was
+found or ``cpu`` is invalid.
+
+Concurrency
+-----------
+
+Since kernel version 5.1, the BPF infrastructure provides ``struct bpf_spin_lock``
+to synchronize access.
+
+Userspace
+---------
+
+Access from userspace uses libbpf APIs with the same names as above, with
+the map identified by its ``fd``.
+
+Examples
+========
+
+Please see the ``tools/testing/selftests/bpf`` directory for functional
+examples. The code samples below demonstrate API usage.
+
+Kernel BPF
+----------
+
+This snippet shows how to declare an array in a BPF program.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, u32);
+ __type(value, long);
+ __uint(max_entries, 256);
+ } my_map SEC(".maps");
+
+
+This example BPF program shows how to access an array element.
+
+.. code-block:: c
+
+ int bpf_prog(struct __sk_buff *skb)
+ {
+ struct iphdr ip;
+ int index;
+ long *value;
+
+ if (bpf_skb_load_bytes(skb, ETH_HLEN, &ip, sizeof(ip)) < 0)
+ return 0;
+
+ index = ip.protocol;
+ value = bpf_map_lookup_elem(&my_map, &index);
+ if (value)
+ __sync_fetch_and_add(value, skb->len);
+
+ return 0;
+ }
+
+Userspace
+---------
+
+BPF_MAP_TYPE_ARRAY
+~~~~~~~~~~~~~~~~~~
+
+This snippet shows how to create an array, using ``bpf_map_create_opts`` to
+set flags.
+
+.. code-block:: c
+
+ #include <bpf/libbpf.h>
+ #include <bpf/bpf.h>
+
+ int create_array()
+ {
+ int fd;
+ LIBBPF_OPTS(bpf_map_create_opts, opts, .map_flags = BPF_F_MMAPABLE);
+
+ fd = bpf_map_create(BPF_MAP_TYPE_ARRAY,
+ "example_array", /* name */
+ sizeof(__u32), /* key size */
+ sizeof(long), /* value size */
+ 256, /* max entries */
+ &opts); /* create opts */
+ return fd;
+ }
+
+This snippet shows how to initialize the elements of an array.
+
+.. code-block:: c
+
+ int initialize_array(int fd)
+ {
+ __u32 i;
+ long value;
+ int ret;
+
+ for (i = 0; i < 256; i++) {
+ value = i;
+ ret = bpf_map_update_elem(fd, &i, &value, BPF_ANY);
+ if (ret < 0)
+ return ret;
+ }
+
+ return ret;
+ }
+
+This snippet shows how to retrieve an element value from an array.
+
+.. code-block:: c
+
+ int lookup(int fd)
+ {
+ __u32 index = 42;
+ long value;
+ int ret;
+
+ ret = bpf_map_lookup_elem(fd, &index, &value);
+ if (ret < 0)
+ return ret;
+
+ /* use value here */
+ assert(value == 42);
+
+ return ret;
+ }
+
+BPF_MAP_TYPE_PERCPU_ARRAY
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This snippet shows how to initialize the elements of a per CPU array.
+
+.. code-block:: c
+
+ int initialize_array(int fd)
+ {
+ int ncpus = libbpf_num_possible_cpus();
+ long values[ncpus];
+ __u32 i, j;
+ int ret;
+
+ for (i = 0; i < 256 ; i++) {
+ for (j = 0; j < ncpus; j++)
+ values[j] = i;
+ ret = bpf_map_update_elem(fd, &i, &values, BPF_ANY);
+ if (ret < 0)
+ return ret;
+ }
+
+ return ret;
+ }
+
+This snippet shows how to access the per CPU elements of an array value.
+
+.. code-block:: c
+
+ int lookup(int fd)
+ {
+ int ncpus = libbpf_num_possible_cpus();
+ __u32 index = 42, j;
+ long values[ncpus];
+ int ret;
+
+ ret = bpf_map_lookup_elem(fd, &index, &values);
+ if (ret < 0)
+ return ret;
+
+ for (j = 0; j < ncpus; j++) {
+ /* Use per CPU value here */
+ assert(values[j] == 42);
+ }
+
+ return ret;
+ }
+
+Semantics
+=========
+
+As shown in the example above, when accessing a ``BPF_MAP_TYPE_PERCPU_ARRAY``
+in userspace, each value is an array with ``ncpus`` elements.
+
+When calling ``bpf_map_update_elem()`` the flag ``BPF_NOEXIST`` can not be used
+for these maps.
diff --git a/Documentation/bpf/map_bloom_filter.rst b/Documentation/bpf/map_bloom_filter.rst
new file mode 100644
index 000000000000..c82487f2fe0d
--- /dev/null
+++ b/Documentation/bpf/map_bloom_filter.rst
@@ -0,0 +1,174 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+=========================
+BPF_MAP_TYPE_BLOOM_FILTER
+=========================
+
+.. note::
+ - ``BPF_MAP_TYPE_BLOOM_FILTER`` was introduced in kernel version 5.16
+
+``BPF_MAP_TYPE_BLOOM_FILTER`` provides a BPF bloom filter map. Bloom
+filters are a space-efficient probabilistic data structure used to
+quickly test whether an element exists in a set. In a bloom filter,
+false positives are possible whereas false negatives are not.
+
+The bloom filter map does not have keys, only values. When the bloom
+filter map is created, it must be created with a ``key_size`` of 0. The
+bloom filter map supports two operations:
+
+- push: adding an element to the map
+- peek: determining whether an element is present in the map
+
+BPF programs must use ``bpf_map_push_elem`` to add an element to the
+bloom filter map and ``bpf_map_peek_elem`` to query the map. These
+operations are exposed to userspace applications using the existing
+``bpf`` syscall in the following way:
+
+- ``BPF_MAP_UPDATE_ELEM`` -> push
+- ``BPF_MAP_LOOKUP_ELEM`` -> peek
+
+The ``max_entries`` size that is specified at map creation time is used
+to approximate a reasonable bitmap size for the bloom filter, and is not
+otherwise strictly enforced. If the user wishes to insert more entries
+into the bloom filter than ``max_entries``, this may lead to a higher
+false positive rate.
+
+The number of hashes to use for the bloom filter is configurable using
+the lower 4 bits of ``map_extra`` in ``union bpf_attr`` at map creation
+time. If no number is specified, the default used will be 5 hash
+functions. In general, using more hashes decreases both the false
+positive rate and the speed of a lookup.
+
+It is not possible to delete elements from a bloom filter map. A bloom
+filter map may be used as an inner map. The user is responsible for
+synchronising concurrent updates and lookups to ensure no false negative
+lookups occur.
+
+Usage
+=====
+
+Kernel BPF
+----------
+
+bpf_map_push_elem()
+~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_push_elem(struct bpf_map *map, const void *value, u64 flags)
+
+A ``value`` can be added to a bloom filter using the
+``bpf_map_push_elem()`` helper. The ``flags`` parameter must be set to
+``BPF_ANY`` when adding an entry to the bloom filter. This helper
+returns ``0`` on success, or negative error in case of failure.
+
+bpf_map_peek_elem()
+~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_peek_elem(struct bpf_map *map, void *value)
+
+The ``bpf_map_peek_elem()`` helper is used to determine whether
+``value`` is present in the bloom filter map. This helper returns ``0``
+if ``value`` is probably present in the map, or ``-ENOENT`` if ``value``
+is definitely not present in the map.
+
+Userspace
+---------
+
+bpf_map_update_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_update_elem (int fd, const void *key, const void *value, __u64 flags)
+
+A userspace program can add a ``value`` to a bloom filter using libbpf's
+``bpf_map_update_elem`` function. The ``key`` parameter must be set to
+``NULL`` and ``flags`` must be set to ``BPF_ANY``. Returns ``0`` on
+success, or negative error in case of failure.
+
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_lookup_elem (int fd, const void *key, void *value)
+
+A userspace program can determine the presence of ``value`` in a bloom
+filter using libbpf's ``bpf_map_lookup_elem`` function. The ``key``
+parameter must be set to ``NULL``. Returns ``0`` if ``value`` is
+probably present in the map, or ``-ENOENT`` if ``value`` is definitely
+not present in the map.
+
+Examples
+========
+
+Kernel BPF
+----------
+
+This snippet shows how to declare a bloom filter in a BPF program:
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_BLOOM_FILTER);
+ __type(value, __u32);
+ __uint(max_entries, 1000);
+ __uint(map_extra, 3);
+ } bloom_filter SEC(".maps");
+
+This snippet shows how to determine presence of a value in a bloom
+filter in a BPF program:
+
+.. code-block:: c
+
+ void *lookup(__u32 key)
+ {
+ if (bpf_map_peek_elem(&bloom_filter, &key) == 0) {
+ /* Verify not a false positive and fetch an associated
+ * value using a secondary lookup, e.g. in a hash table
+ */
+ return bpf_map_lookup_elem(&hash_table, &key);
+ }
+ return 0;
+ }
+
+Userspace
+---------
+
+This snippet shows how to use libbpf to create a bloom filter map from
+userspace:
+
+.. code-block:: c
+
+ int create_bloom()
+ {
+ LIBBPF_OPTS(bpf_map_create_opts, opts,
+ .map_extra = 3); /* number of hashes */
+
+ return bpf_map_create(BPF_MAP_TYPE_BLOOM_FILTER,
+ "ipv6_bloom", /* name */
+ 0, /* key size, must be zero */
+ sizeof(ipv6_addr), /* value size */
+ 10000, /* max entries */
+ &opts); /* create options */
+ }
+
+This snippet shows how to add an element to a bloom filter from
+userspace:
+
+.. code-block:: c
+
+ int add_element(struct bpf_map *bloom_map, __u32 value)
+ {
+ int bloom_fd = bpf_map__fd(bloom_map);
+ return bpf_map_update_elem(bloom_fd, NULL, &value, BPF_ANY);
+ }
+
+References
+==========
+
+https://lwn.net/ml/bpf/20210831225005.2762202-1-joannekoong@fb.com/
diff --git a/Documentation/bpf/map_cgrp_storage.rst b/Documentation/bpf/map_cgrp_storage.rst
new file mode 100644
index 000000000000..5d3f603efffa
--- /dev/null
+++ b/Documentation/bpf/map_cgrp_storage.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Meta Platforms, Inc. and affiliates.
+
+=========================
+BPF_MAP_TYPE_CGRP_STORAGE
+=========================
+
+The ``BPF_MAP_TYPE_CGRP_STORAGE`` map type represents a local fix-sized
+storage for cgroups. It is only available with ``CONFIG_CGROUPS``.
+The programs are made available by the same Kconfig. The
+data for a particular cgroup can be retrieved by looking up the map
+with that cgroup.
+
+This document describes the usage and semantics of the
+``BPF_MAP_TYPE_CGRP_STORAGE`` map type.
+
+Usage
+=====
+
+The map key must be ``sizeof(int)`` representing a cgroup fd.
+To access the storage in a program, use ``bpf_cgrp_storage_get``::
+
+ void *bpf_cgrp_storage_get(struct bpf_map *map, struct cgroup *cgroup, void *value, u64 flags)
+
+``flags`` could be 0 or ``BPF_LOCAL_STORAGE_GET_F_CREATE`` which indicates that
+a new local storage will be created if one does not exist.
+
+The local storage can be removed with ``bpf_cgrp_storage_delete``::
+
+ long bpf_cgrp_storage_delete(struct bpf_map *map, struct cgroup *cgroup)
+
+The map is available to all program types.
+
+Examples
+========
+
+A BPF program example with BPF_MAP_TYPE_CGRP_STORAGE::
+
+ #include <vmlinux.h>
+ #include <bpf/bpf_helpers.h>
+ #include <bpf/bpf_tracing.h>
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_CGRP_STORAGE);
+ __uint(map_flags, BPF_F_NO_PREALLOC);
+ __type(key, int);
+ __type(value, long);
+ } cgrp_storage SEC(".maps");
+
+ SEC("tp_btf/sys_enter")
+ int BPF_PROG(on_enter, struct pt_regs *regs, long id)
+ {
+ struct task_struct *task = bpf_get_current_task_btf();
+ long *ptr;
+
+ ptr = bpf_cgrp_storage_get(&cgrp_storage, task->cgroups->dfl_cgrp, 0,
+ BPF_LOCAL_STORAGE_GET_F_CREATE);
+ if (ptr)
+ __sync_fetch_and_add(ptr, 1);
+
+ return 0;
+ }
+
+Userspace accessing map declared above::
+
+ #include <linux/bpf.h>
+ #include <linux/libbpf.h>
+
+ __u32 map_lookup(struct bpf_map *map, int cgrp_fd)
+ {
+ __u32 *value;
+ value = bpf_map_lookup_elem(bpf_map__fd(map), &cgrp_fd);
+ if (value)
+ return *value;
+ return 0;
+ }
+
+Difference Between BPF_MAP_TYPE_CGRP_STORAGE and BPF_MAP_TYPE_CGROUP_STORAGE
+============================================================================
+
+The old cgroup storage map ``BPF_MAP_TYPE_CGROUP_STORAGE`` has been marked as
+deprecated (renamed to ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED``). The new
+``BPF_MAP_TYPE_CGRP_STORAGE`` map should be used instead. The following
+illusates the main difference between ``BPF_MAP_TYPE_CGRP_STORAGE`` and
+``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED``.
+
+(1). ``BPF_MAP_TYPE_CGRP_STORAGE`` can be used by all program types while
+ ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED`` is available only to cgroup program types
+ like BPF_CGROUP_INET_INGRESS or BPF_CGROUP_SOCK_OPS, etc.
+
+(2). ``BPF_MAP_TYPE_CGRP_STORAGE`` supports local storage for more than one
+ cgroup while ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED`` only supports one cgroup
+ which is attached by a BPF program.
+
+(3). ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED`` allocates local storage at attach time so
+ ``bpf_get_local_storage()`` always returns non-NULL local storage.
+ ``BPF_MAP_TYPE_CGRP_STORAGE`` allocates local storage at runtime so
+ it is possible that ``bpf_cgrp_storage_get()`` may return null local storage.
+ To avoid such null local storage issue, user space can do
+ ``bpf_map_update_elem()`` to pre-allocate local storage before a BPF program
+ is attached.
+
+(4). ``BPF_MAP_TYPE_CGRP_STORAGE`` supports deleting local storage by a BPF program
+ while ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED`` only deletes storage during
+ prog detach time.
+
+So overall, ``BPF_MAP_TYPE_CGRP_STORAGE`` supports all ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED``
+functionality and beyond. It is recommended to use ``BPF_MAP_TYPE_CGRP_STORAGE``
+instead of ``BPF_MAP_TYPE_CGROUP_STORAGE_DEPRECATED``.
diff --git a/Documentation/bpf/map_cpumap.rst b/Documentation/bpf/map_cpumap.rst
new file mode 100644
index 000000000000..923cfc8ab51f
--- /dev/null
+++ b/Documentation/bpf/map_cpumap.rst
@@ -0,0 +1,177 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+===================
+BPF_MAP_TYPE_CPUMAP
+===================
+
+.. note::
+ - ``BPF_MAP_TYPE_CPUMAP`` was introduced in kernel version 4.15
+
+.. kernel-doc:: kernel/bpf/cpumap.c
+ :doc: cpu map
+
+An example use-case for this map type is software based Receive Side Scaling (RSS).
+
+The CPUMAP represents the CPUs in the system indexed as the map-key, and the
+map-value is the config setting (per CPUMAP entry). Each CPUMAP entry has a dedicated
+kernel thread bound to the given CPU to represent the remote CPU execution unit.
+
+Starting from Linux kernel version 5.9 the CPUMAP can run a second XDP program
+on the remote CPU. This allows an XDP program to split its processing across
+multiple CPUs. For example, a scenario where the initial CPU (that sees/receives
+the packets) needs to do minimal packet processing and the remote CPU (to which
+the packet is directed) can afford to spend more cycles processing the frame. The
+initial CPU is where the XDP redirect program is executed. The remote CPU
+receives raw ``xdp_frame`` objects.
+
+Usage
+=====
+
+Kernel BPF
+----------
+bpf_redirect_map()
+^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_redirect_map(struct bpf_map *map, u32 key, u64 flags)
+
+Redirect the packet to the endpoint referenced by ``map`` at index ``key``.
+For ``BPF_MAP_TYPE_CPUMAP`` this map contains references to CPUs.
+
+The lower two bits of ``flags`` are used as the return code if the map lookup
+fails. This is so that the return value can be one of the XDP program return
+codes up to ``XDP_TX``, as chosen by the caller.
+
+User space
+----------
+.. note::
+ CPUMAP entries can only be updated/looked up/deleted from user space and not
+ from an eBPF program. Trying to call these functions from a kernel eBPF
+ program will result in the program failing to load and a verifier warning.
+
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_update_elem(int fd, const void *key, const void *value, __u64 flags);
+
+CPU entries can be added or updated using the ``bpf_map_update_elem()``
+helper. This helper replaces existing elements atomically. The ``value`` parameter
+can be ``struct bpf_cpumap_val``.
+
+ .. code-block:: c
+
+ struct bpf_cpumap_val {
+ __u32 qsize; /* queue size to remote target CPU */
+ union {
+ int fd; /* prog fd on map write */
+ __u32 id; /* prog id on map read */
+ } bpf_prog;
+ };
+
+The flags argument can be one of the following:
+ - BPF_ANY: Create a new element or update an existing element.
+ - BPF_NOEXIST: Create a new element only if it did not exist.
+ - BPF_EXIST: Update an existing element.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_lookup_elem(int fd, const void *key, void *value);
+
+CPU entries can be retrieved using the ``bpf_map_lookup_elem()``
+helper.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_delete_elem(int fd, const void *key);
+
+CPU entries can be deleted using the ``bpf_map_delete_elem()``
+helper. This helper will return 0 on success, or negative error in case of
+failure.
+
+Examples
+========
+Kernel
+------
+
+The following code snippet shows how to declare a ``BPF_MAP_TYPE_CPUMAP`` called
+``cpu_map`` and how to redirect packets to a remote CPU using a round robin scheme.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_CPUMAP);
+ __type(key, __u32);
+ __type(value, struct bpf_cpumap_val);
+ __uint(max_entries, 12);
+ } cpu_map SEC(".maps");
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, __u32);
+ __type(value, __u32);
+ __uint(max_entries, 12);
+ } cpus_available SEC(".maps");
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+ __type(key, __u32);
+ __type(value, __u32);
+ __uint(max_entries, 1);
+ } cpus_iterator SEC(".maps");
+
+ SEC("xdp")
+ int xdp_redir_cpu_round_robin(struct xdp_md *ctx)
+ {
+ __u32 key = 0;
+ __u32 cpu_dest = 0;
+ __u32 *cpu_selected, *cpu_iterator;
+ __u32 cpu_idx;
+
+ cpu_iterator = bpf_map_lookup_elem(&cpus_iterator, &key);
+ if (!cpu_iterator)
+ return XDP_ABORTED;
+ cpu_idx = *cpu_iterator;
+
+ *cpu_iterator += 1;
+ if (*cpu_iterator == bpf_num_possible_cpus())
+ *cpu_iterator = 0;
+
+ cpu_selected = bpf_map_lookup_elem(&cpus_available, &cpu_idx);
+ if (!cpu_selected)
+ return XDP_ABORTED;
+ cpu_dest = *cpu_selected;
+
+ if (cpu_dest >= bpf_num_possible_cpus())
+ return XDP_ABORTED;
+
+ return bpf_redirect_map(&cpu_map, cpu_dest, 0);
+ }
+
+User space
+----------
+
+The following code snippet shows how to dynamically set the max_entries for a
+CPUMAP to the max number of cpus available on the system.
+
+.. code-block:: c
+
+ int set_max_cpu_entries(struct bpf_map *cpu_map)
+ {
+ if (bpf_map__set_max_entries(cpu_map, libbpf_num_possible_cpus()) < 0) {
+ fprintf(stderr, "Failed to set max entries for cpu_map map: %s",
+ strerror(errno));
+ return -1;
+ }
+ return 0;
+ }
+
+References
+===========
+
+- https://developers.redhat.com/blog/2021/05/13/receive-side-scaling-rss-with-ebpf-and-cpumap#redirecting_into_a_cpumap
diff --git a/Documentation/bpf/map_devmap.rst b/Documentation/bpf/map_devmap.rst
new file mode 100644
index 000000000000..927312c7b8c8
--- /dev/null
+++ b/Documentation/bpf/map_devmap.rst
@@ -0,0 +1,238 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+=================================================
+BPF_MAP_TYPE_DEVMAP and BPF_MAP_TYPE_DEVMAP_HASH
+=================================================
+
+.. note::
+ - ``BPF_MAP_TYPE_DEVMAP`` was introduced in kernel version 4.14
+ - ``BPF_MAP_TYPE_DEVMAP_HASH`` was introduced in kernel version 5.4
+
+``BPF_MAP_TYPE_DEVMAP`` and ``BPF_MAP_TYPE_DEVMAP_HASH`` are BPF maps primarily
+used as backend maps for the XDP BPF helper call ``bpf_redirect_map()``.
+``BPF_MAP_TYPE_DEVMAP`` is backed by an array that uses the key as
+the index to lookup a reference to a net device. While ``BPF_MAP_TYPE_DEVMAP_HASH``
+is backed by a hash table that uses a key to lookup a reference to a net device.
+The user provides either <``key``/ ``ifindex``> or <``key``/ ``struct bpf_devmap_val``>
+pairs to update the maps with new net devices.
+
+.. note::
+ - The key to a hash map doesn't have to be an ``ifindex``.
+ - While ``BPF_MAP_TYPE_DEVMAP_HASH`` allows for densely packing the net devices
+ it comes at the cost of a hash of the key when performing a look up.
+
+The setup and packet enqueue/send code is shared between the two types of
+devmap; only the lookup and insertion is different.
+
+Usage
+=====
+Kernel BPF
+----------
+bpf_redirect_map()
+^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_redirect_map(struct bpf_map *map, u32 key, u64 flags)
+
+Redirect the packet to the endpoint referenced by ``map`` at index ``key``.
+For ``BPF_MAP_TYPE_DEVMAP`` and ``BPF_MAP_TYPE_DEVMAP_HASH`` this map contains
+references to net devices (for forwarding packets through other ports).
+
+The lower two bits of *flags* are used as the return code if the map lookup
+fails. This is so that the return value can be one of the XDP program return
+codes up to ``XDP_TX``, as chosen by the caller. The higher bits of ``flags``
+can be set to ``BPF_F_BROADCAST`` or ``BPF_F_EXCLUDE_INGRESS`` as defined
+below.
+
+With ``BPF_F_BROADCAST`` the packet will be broadcast to all the interfaces
+in the map, with ``BPF_F_EXCLUDE_INGRESS`` the ingress interface will be excluded
+from the broadcast.
+
+.. note::
+ - The key is ignored if BPF_F_BROADCAST is set.
+ - The broadcast feature can also be used to implement multicast forwarding:
+ simply create multiple DEVMAPs, each one corresponding to a single multicast group.
+
+This helper will return ``XDP_REDIRECT`` on success, or the value of the two
+lower bits of the ``flags`` argument if the map lookup fails.
+
+More information about redirection can be found :doc:`redirect`
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+Net device entries can be retrieved using the ``bpf_map_lookup_elem()``
+helper.
+
+User space
+----------
+.. note::
+ DEVMAP entries can only be updated/deleted from user space and not
+ from an eBPF program. Trying to call these functions from a kernel eBPF
+ program will result in the program failing to load and a verifier warning.
+
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_update_elem(int fd, const void *key, const void *value, __u64 flags);
+
+Net device entries can be added or updated using the ``bpf_map_update_elem()``
+helper. This helper replaces existing elements atomically. The ``value`` parameter
+can be ``struct bpf_devmap_val`` or a simple ``int ifindex`` for backwards
+compatibility.
+
+ .. code-block:: c
+
+ struct bpf_devmap_val {
+ __u32 ifindex; /* device index */
+ union {
+ int fd; /* prog fd on map write */
+ __u32 id; /* prog id on map read */
+ } bpf_prog;
+ };
+
+The ``flags`` argument can be one of the following:
+ - ``BPF_ANY``: Create a new element or update an existing element.
+ - ``BPF_NOEXIST``: Create a new element only if it did not exist.
+ - ``BPF_EXIST``: Update an existing element.
+
+DEVMAPs can associate a program with a device entry by adding a ``bpf_prog.fd``
+to ``struct bpf_devmap_val``. Programs are run after ``XDP_REDIRECT`` and have
+access to both Rx device and Tx device. The program associated with the ``fd``
+must have type XDP with expected attach type ``xdp_devmap``.
+When a program is associated with a device index, the program is run on an
+``XDP_REDIRECT`` and before the buffer is added to the per-cpu queue. Examples
+of how to attach/use xdp_devmap progs can be found in the kernel selftests:
+
+- ``tools/testing/selftests/bpf/prog_tests/xdp_devmap_attach.c``
+- ``tools/testing/selftests/bpf/progs/test_xdp_with_devmap_helpers.c``
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+.. c:function::
+ int bpf_map_lookup_elem(int fd, const void *key, void *value);
+
+Net device entries can be retrieved using the ``bpf_map_lookup_elem()``
+helper.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+.. c:function::
+ int bpf_map_delete_elem(int fd, const void *key);
+
+Net device entries can be deleted using the ``bpf_map_delete_elem()``
+helper. This helper will return 0 on success, or negative error in case of
+failure.
+
+Examples
+========
+
+Kernel BPF
+----------
+
+The following code snippet shows how to declare a ``BPF_MAP_TYPE_DEVMAP``
+called tx_port.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_DEVMAP);
+ __type(key, __u32);
+ __type(value, __u32);
+ __uint(max_entries, 256);
+ } tx_port SEC(".maps");
+
+The following code snippet shows how to declare a ``BPF_MAP_TYPE_DEVMAP_HASH``
+called forward_map.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_DEVMAP_HASH);
+ __type(key, __u32);
+ __type(value, struct bpf_devmap_val);
+ __uint(max_entries, 32);
+ } forward_map SEC(".maps");
+
+.. note::
+
+ The value type in the DEVMAP above is a ``struct bpf_devmap_val``
+
+The following code snippet shows a simple xdp_redirect_map program. This program
+would work with a user space program that populates the devmap ``forward_map`` based
+on ingress ifindexes. The BPF program (below) is redirecting packets using the
+ingress ``ifindex`` as the ``key``.
+
+.. code-block:: c
+
+ SEC("xdp")
+ int xdp_redirect_map_func(struct xdp_md *ctx)
+ {
+ int index = ctx->ingress_ifindex;
+
+ return bpf_redirect_map(&forward_map, index, 0);
+ }
+
+The following code snippet shows a BPF program that is broadcasting packets to
+all the interfaces in the ``tx_port`` devmap.
+
+.. code-block:: c
+
+ SEC("xdp")
+ int xdp_redirect_map_func(struct xdp_md *ctx)
+ {
+ return bpf_redirect_map(&tx_port, 0, BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS);
+ }
+
+User space
+----------
+
+The following code snippet shows how to update a devmap called ``tx_port``.
+
+.. code-block:: c
+
+ int update_devmap(int ifindex, int redirect_ifindex)
+ {
+ int ret;
+
+ ret = bpf_map_update_elem(bpf_map__fd(tx_port), &ifindex, &redirect_ifindex, 0);
+ if (ret < 0) {
+ fprintf(stderr, "Failed to update devmap_ value: %s\n",
+ strerror(errno));
+ }
+
+ return ret;
+ }
+
+The following code snippet shows how to update a hash_devmap called ``forward_map``.
+
+.. code-block:: c
+
+ int update_devmap(int ifindex, int redirect_ifindex)
+ {
+ struct bpf_devmap_val devmap_val = { .ifindex = redirect_ifindex };
+ int ret;
+
+ ret = bpf_map_update_elem(bpf_map__fd(forward_map), &ifindex, &devmap_val, 0);
+ if (ret < 0) {
+ fprintf(stderr, "Failed to update devmap_ value: %s\n",
+ strerror(errno));
+ }
+ return ret;
+ }
+
+References
+===========
+
+- https://lwn.net/Articles/728146/
+- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=6f9d451ab1a33728adb72d7ff66a7b374d665176
+- https://elixir.bootlin.com/linux/latest/source/net/core/filter.c#L4106
diff --git a/Documentation/bpf/map_hash.rst b/Documentation/bpf/map_hash.rst
index e85120878b27..8606bf958a8c 100644
--- a/Documentation/bpf/map_hash.rst
+++ b/Documentation/bpf/map_hash.rst
@@ -1,5 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2022 Red Hat, Inc.
+.. Copyright (C) 2022-2023 Isovalent, Inc.
===============================================
BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants
@@ -29,12 +30,28 @@ will automatically evict the least recently used entries when the hash
table reaches capacity. An LRU hash maintains an internal LRU list that
is used to select elements for eviction. This internal LRU list is
shared across CPUs but it is possible to request a per CPU LRU list with
-the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``.
+the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``. The
+following table outlines the properties of LRU maps depending on the a
+map type and the flags used to create the map.
+
+======================== ========================= ================================
+Flag ``BPF_MAP_TYPE_LRU_HASH`` ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
+======================== ========================= ================================
+**BPF_F_NO_COMMON_LRU** Per-CPU LRU, global map Per-CPU LRU, per-cpu map
+**!BPF_F_NO_COMMON_LRU** Global LRU, global map Global LRU, per-cpu map
+======================== ========================= ================================
Usage
=====
-.. c:function::
+Kernel BPF
+----------
+
+bpf_map_update_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
Hash entries can be added or updated using the ``bpf_map_update_elem()``
@@ -49,14 +66,22 @@ parameter can be used to control the update behaviour:
``bpf_map_update_elem()`` returns 0 on success, or negative error in
case of failure.
-.. c:function::
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
Hash entries can be retrieved using the ``bpf_map_lookup_elem()``
helper. This helper returns a pointer to the value associated with
``key``, or ``NULL`` if no entry was found.
-.. c:function::
+bpf_map_delete_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
long bpf_map_delete_elem(struct bpf_map *map, const void *key)
Hash entries can be deleted using the ``bpf_map_delete_elem()``
@@ -70,7 +95,11 @@ For ``BPF_MAP_TYPE_PERCPU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
the ``bpf_map_update_elem()`` and ``bpf_map_lookup_elem()`` helpers
automatically access the hash slot for the current CPU.
-.. c:function::
+bpf_map_lookup_percpu_elem()
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu)
The ``bpf_map_lookup_percpu_elem()`` helper can be used to lookup the
@@ -89,7 +118,11 @@ See ``tools/testing/selftests/bpf/progs/test_spin_lock.c``.
Userspace
---------
-.. c:function::
+bpf_map_get_next_key()
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
int bpf_map_get_next_key(int fd, const void *cur_key, void *next_key)
In userspace, it is possible to iterate through the keys of a hash using
@@ -183,3 +216,50 @@ Userspace walking the map elements from the map declared above:
cur_key = &next_key;
}
}
+
+Internals
+=========
+
+This section of the document is targeted at Linux developers and describes
+aspects of the map implementations that are not considered stable ABI. The
+following details are subject to change in future versions of the kernel.
+
+``BPF_MAP_TYPE_LRU_HASH`` and variants
+--------------------------------------
+
+Updating elements in LRU maps may trigger eviction behaviour when the capacity
+of the map is reached. There are various steps that the update algorithm
+attempts in order to enforce the LRU property which have increasing impacts on
+other CPUs involved in the following operation attempts:
+
+- Attempt to use CPU-local state to batch operations
+- Attempt to fetch ``target_free`` free nodes from global lists
+- Attempt to pull any node from a global list and remove it from the hashmap
+- Attempt to pull any node from any CPU's list and remove it from the hashmap
+
+The number of nodes to borrow from the global list in a batch, ``target_free``,
+depends on the size of the map. Larger batch size reduces lock contention, but
+may also exhaust the global structure. The value is computed at map init to
+avoid exhaustion, by limiting aggregate reservation by all CPUs to half the map
+size. With a minimum of a single element and maximum budget of 128 at a time.
+
+This algorithm is described visually in the following diagram. See the
+description in commit 3a08c2fd7634 ("bpf: LRU List") for a full explanation of
+the corresponding operations:
+
+.. kernel-figure:: map_lru_hash_update.dot
+ :alt: Diagram outlining the LRU eviction steps taken during map update.
+
+ LRU hash eviction during map update for ``BPF_MAP_TYPE_LRU_HASH`` and
+ variants. See the dot file source for kernel function name code references.
+
+Map updates start from the oval in the top right "begin ``bpf_map_update()``"
+and progress through the graph towards the bottom where the result may be
+either a successful update or a failure with various error codes. The key in
+the top right provides indicators for which locks may be involved in specific
+operations. This is intended as a visual hint for reasoning about how map
+contention may impact update operations, though the map type and flags may
+impact the actual contention on those locks, based on the logic described in
+the table above. For instance, if the map is created with type
+``BPF_MAP_TYPE_LRU_PERCPU_HASH`` and flags ``BPF_F_NO_COMMON_LRU`` then all map
+properties would be per-cpu.
diff --git a/Documentation/bpf/map_lpm_trie.rst b/Documentation/bpf/map_lpm_trie.rst
new file mode 100644
index 000000000000..f9cd579496c9
--- /dev/null
+++ b/Documentation/bpf/map_lpm_trie.rst
@@ -0,0 +1,197 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+=====================
+BPF_MAP_TYPE_LPM_TRIE
+=====================
+
+.. note::
+ - ``BPF_MAP_TYPE_LPM_TRIE`` was introduced in kernel version 4.11
+
+``BPF_MAP_TYPE_LPM_TRIE`` provides a longest prefix match algorithm that
+can be used to match IP addresses to a stored set of prefixes.
+Internally, data is stored in an unbalanced trie of nodes that uses
+``prefixlen,data`` pairs as its keys. The ``data`` is interpreted in
+network byte order, i.e. big endian, so ``data[0]`` stores the most
+significant byte.
+
+LPM tries may be created with a maximum prefix length that is a multiple
+of 8, in the range from 8 to 2048. The key used for lookup and update
+operations is a ``struct bpf_lpm_trie_key_u8``, extended by
+``max_prefixlen/8`` bytes.
+
+- For IPv4 addresses the data length is 4 bytes
+- For IPv6 addresses the data length is 16 bytes
+
+The value type stored in the LPM trie can be any user defined type.
+
+.. note::
+ When creating a map of type ``BPF_MAP_TYPE_LPM_TRIE`` you must set the
+ ``BPF_F_NO_PREALLOC`` flag.
+
+Usage
+=====
+
+Kernel BPF
+----------
+
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+The longest prefix entry for a given data value can be found using the
+``bpf_map_lookup_elem()`` helper. This helper returns a pointer to the
+value associated with the longest matching ``key``, or ``NULL`` if no
+entry was found.
+
+The ``key`` should have ``prefixlen`` set to ``max_prefixlen`` when
+performing longest prefix lookups. For example, when searching for the
+longest prefix match for an IPv4 address, ``prefixlen`` should be set to
+``32``.
+
+bpf_map_update_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
+
+Prefix entries can be added or updated using the ``bpf_map_update_elem()``
+helper. This helper replaces existing elements atomically.
+
+``bpf_map_update_elem()`` returns ``0`` on success, or negative error in
+case of failure.
+
+ .. note::
+ The flags parameter must be one of BPF_ANY, BPF_NOEXIST or BPF_EXIST,
+ but the value is ignored, giving BPF_ANY semantics.
+
+bpf_map_delete_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_delete_elem(struct bpf_map *map, const void *key)
+
+Prefix entries can be deleted using the ``bpf_map_delete_elem()``
+helper. This helper will return 0 on success, or negative error in case
+of failure.
+
+Userspace
+---------
+
+Access from userspace uses libbpf APIs with the same names as above, with
+the map identified by ``fd``.
+
+bpf_map_get_next_key()
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_get_next_key (int fd, const void *cur_key, void *next_key)
+
+A userspace program can iterate through the entries in an LPM trie using
+libbpf's ``bpf_map_get_next_key()`` function. The first key can be
+fetched by calling ``bpf_map_get_next_key()`` with ``cur_key`` set to
+``NULL``. Subsequent calls will fetch the next key that follows the
+current key. ``bpf_map_get_next_key()`` returns ``0`` on success,
+``-ENOENT`` if ``cur_key`` is the last key in the trie, or negative
+error in case of failure.
+
+``bpf_map_get_next_key()`` will iterate through the LPM trie elements
+from leftmost leaf first. This means that iteration will return more
+specific keys before less specific ones.
+
+Examples
+========
+
+Please see ``tools/testing/selftests/bpf/test_lpm_map.c`` for examples
+of LPM trie usage from userspace. The code snippets below demonstrate
+API usage.
+
+Kernel BPF
+----------
+
+The following BPF code snippet shows how to declare a new LPM trie for IPv4
+address prefixes:
+
+.. code-block:: c
+
+ #include <linux/bpf.h>
+ #include <bpf/bpf_helpers.h>
+
+ struct ipv4_lpm_key {
+ __u32 prefixlen;
+ __u32 data;
+ };
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_LPM_TRIE);
+ __type(key, struct ipv4_lpm_key);
+ __type(value, __u32);
+ __uint(map_flags, BPF_F_NO_PREALLOC);
+ __uint(max_entries, 255);
+ } ipv4_lpm_map SEC(".maps");
+
+The following BPF code snippet shows how to lookup by IPv4 address:
+
+.. code-block:: c
+
+ void *lookup(__u32 ipaddr)
+ {
+ struct ipv4_lpm_key key = {
+ .prefixlen = 32,
+ .data = ipaddr
+ };
+
+ return bpf_map_lookup_elem(&ipv4_lpm_map, &key);
+ }
+
+Userspace
+---------
+
+The following snippet shows how to insert an IPv4 prefix entry into an
+LPM trie:
+
+.. code-block:: c
+
+ int add_prefix_entry(int lpm_fd, __u32 addr, __u32 prefixlen, struct value *value)
+ {
+ struct ipv4_lpm_key ipv4_key = {
+ .prefixlen = prefixlen,
+ .data = addr
+ };
+ return bpf_map_update_elem(lpm_fd, &ipv4_key, value, BPF_ANY);
+ }
+
+The following snippet shows a userspace program walking through the entries
+of an LPM trie:
+
+
+.. code-block:: c
+
+ #include <bpf/libbpf.h>
+ #include <bpf/bpf.h>
+
+ void iterate_lpm_trie(int map_fd)
+ {
+ struct ipv4_lpm_key *cur_key = NULL;
+ struct ipv4_lpm_key next_key;
+ struct value value;
+ int err;
+
+ for (;;) {
+ err = bpf_map_get_next_key(map_fd, cur_key, &next_key);
+ if (err)
+ break;
+
+ bpf_map_lookup_elem(map_fd, &next_key, &value);
+
+ /* Use key and value here */
+
+ cur_key = &next_key;
+ }
+ }
diff --git a/Documentation/bpf/map_lru_hash_update.dot b/Documentation/bpf/map_lru_hash_update.dot
new file mode 100644
index 000000000000..ab10058f5b79
--- /dev/null
+++ b/Documentation/bpf/map_lru_hash_update.dot
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (C) 2022-2023 Isovalent, Inc.
+digraph {
+ node [colorscheme=accent4,style=filled] # Apply colorscheme to all nodes
+ graph [splines=ortho, nodesep=1]
+
+ subgraph cluster_key {
+ label = "Key\n(locks held during operation)";
+ rankdir = TB;
+
+ remote_lock [shape=rectangle,fillcolor=4,label="remote CPU LRU lock"]
+ hash_lock [shape=rectangle,fillcolor=3,label="hashtab lock"]
+ lru_lock [shape=rectangle,fillcolor=2,label="LRU lock"]
+ local_lock [shape=rectangle,fillcolor=1,label="local CPU LRU lock"]
+ no_lock [shape=rectangle,label="no locks held"]
+ }
+
+ begin [shape=oval,label="begin\nbpf_map_update()"]
+
+ // Nodes below with an 'fn_' prefix are roughly labeled by the C function
+ // names that initiate the corresponding logic in kernel/bpf/bpf_lru_list.c.
+ // Number suffixes and errno suffixes handle subsections of the corresponding
+ // logic in the function as of the writing of this dot.
+
+ // cf. __local_list_pop_free() / bpf_percpu_lru_pop_free()
+ local_freelist_check [shape=diamond,fillcolor=1,
+ label="Local freelist\nnode available?"];
+ use_local_node [shape=rectangle,
+ label="Use node owned\nby this CPU"]
+
+ // cf. bpf_lru_pop_free()
+ common_lru_check [shape=diamond,
+ label="Map created with\ncommon LRU?\n(!BPF_F_NO_COMMON_LRU)"];
+
+ fn_bpf_lru_list_pop_free_to_local [shape=rectangle,fillcolor=2,
+ label="Flush local pending,
+ Rotate Global list, move
+ target_free
+ from global -> local"]
+ // Also corresponds to:
+ // fn__local_list_flush()
+ // fn_bpf_lru_list_rotate()
+ fn___bpf_lru_node_move_to_free[shape=diamond,fillcolor=2,
+ label="Able to free\ntarget_free\nnodes?"]
+
+ fn___bpf_lru_list_shrink_inactive [shape=rectangle,fillcolor=3,
+ label="Shrink inactive list
+ up to remaining
+ target_free
+ (global LRU -> local)"]
+ fn___bpf_lru_list_shrink [shape=diamond,fillcolor=2,
+ label="> 0 entries in\nlocal free list?"]
+ fn___bpf_lru_list_shrink2 [shape=rectangle,fillcolor=2,
+ label="Steal one node from
+ inactive, or if empty,
+ from active global list"]
+ fn___bpf_lru_list_shrink3 [shape=rectangle,fillcolor=3,
+ label="Try to remove\nnode from hashtab"]
+
+ local_freelist_check2 [shape=diamond,label="Htab removal\nsuccessful?"]
+ common_lru_check2 [shape=diamond,
+ label="Map created with\ncommon LRU?\n(!BPF_F_NO_COMMON_LRU)"];
+
+ subgraph cluster_remote_lock {
+ label = "Iterate through CPUs\n(start from current)";
+ style = dashed;
+ rankdir=LR;
+
+ local_freelist_check5 [shape=diamond,fillcolor=4,
+ label="Steal a node from\nper-cpu freelist?"]
+ local_freelist_check6 [shape=rectangle,fillcolor=4,
+ label="Steal a node from
+ (1) Unreferenced pending, or
+ (2) Any pending node"]
+ local_freelist_check7 [shape=rectangle,fillcolor=3,
+ label="Try to remove\nnode from hashtab"]
+ fn_htab_lru_map_update_elem [shape=diamond,
+ label="Stole node\nfrom remote\nCPU?"]
+ fn_htab_lru_map_update_elem2 [shape=diamond,label="Iterated\nall CPUs?"]
+ // Also corresponds to:
+ // use_local_node()
+ // fn__local_list_pop_pending()
+ }
+
+ fn_bpf_lru_list_pop_free_to_local2 [shape=rectangle,
+ label="Use node that was\nnot recently referenced"]
+ local_freelist_check4 [shape=rectangle,
+ label="Use node that was\nactively referenced\nin global list"]
+ fn_htab_lru_map_update_elem_ENOMEM [shape=oval,label="return -ENOMEM"]
+ fn_htab_lru_map_update_elem3 [shape=rectangle,
+ label="Use node that was\nactively referenced\nin (another?) CPU's cache"]
+ fn_htab_lru_map_update_elem4 [shape=rectangle,fillcolor=3,
+ label="Update hashmap\nwith new element"]
+ fn_htab_lru_map_update_elem5 [shape=oval,label="return 0"]
+ fn_htab_lru_map_update_elem_EBUSY [shape=oval,label="return -EBUSY"]
+ fn_htab_lru_map_update_elem_EEXIST [shape=oval,label="return -EEXIST"]
+ fn_htab_lru_map_update_elem_ENOENT [shape=oval,label="return -ENOENT"]
+
+ begin -> local_freelist_check
+ local_freelist_check -> use_local_node [xlabel="Y"]
+ local_freelist_check -> common_lru_check [xlabel="N"]
+ common_lru_check -> fn_bpf_lru_list_pop_free_to_local [xlabel="Y"]
+ common_lru_check -> fn___bpf_lru_list_shrink_inactive [xlabel="N"]
+ fn_bpf_lru_list_pop_free_to_local -> fn___bpf_lru_node_move_to_free
+ fn___bpf_lru_node_move_to_free ->
+ fn_bpf_lru_list_pop_free_to_local2 [xlabel="Y"]
+ fn___bpf_lru_node_move_to_free ->
+ fn___bpf_lru_list_shrink_inactive [xlabel="N"]
+ fn___bpf_lru_list_shrink_inactive -> fn___bpf_lru_list_shrink
+ fn___bpf_lru_list_shrink -> fn_bpf_lru_list_pop_free_to_local2 [xlabel = "Y"]
+ fn___bpf_lru_list_shrink -> fn___bpf_lru_list_shrink2 [xlabel="N"]
+ fn___bpf_lru_list_shrink2 -> fn___bpf_lru_list_shrink3
+ fn___bpf_lru_list_shrink3 -> local_freelist_check2
+ local_freelist_check2 -> local_freelist_check4 [xlabel = "Y"]
+ local_freelist_check2 -> common_lru_check2 [xlabel = "N"]
+ common_lru_check2 -> local_freelist_check5 [xlabel = "Y"]
+ common_lru_check2 -> fn_htab_lru_map_update_elem_ENOMEM [xlabel = "N"]
+ local_freelist_check5 -> fn_htab_lru_map_update_elem [xlabel = "Y"]
+ local_freelist_check5 -> local_freelist_check6 [xlabel = "N"]
+ local_freelist_check6 -> local_freelist_check7
+ local_freelist_check7 -> fn_htab_lru_map_update_elem
+
+ fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem3 [xlabel = "Y"]
+ fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem2 [xlabel = "N"]
+ fn_htab_lru_map_update_elem2 ->
+ fn_htab_lru_map_update_elem_ENOMEM [xlabel = "Y"]
+ fn_htab_lru_map_update_elem2 -> local_freelist_check5 [xlabel = "N"]
+ fn_htab_lru_map_update_elem3 -> fn_htab_lru_map_update_elem4
+
+ use_local_node -> fn_htab_lru_map_update_elem4
+ fn_bpf_lru_list_pop_free_to_local2 -> fn_htab_lru_map_update_elem4
+ local_freelist_check4 -> fn_htab_lru_map_update_elem4
+
+ fn_htab_lru_map_update_elem4 -> fn_htab_lru_map_update_elem5 [headlabel="Success"]
+ fn_htab_lru_map_update_elem4 ->
+ fn_htab_lru_map_update_elem_EBUSY [xlabel="Hashtab lock failed"]
+ fn_htab_lru_map_update_elem4 ->
+ fn_htab_lru_map_update_elem_EEXIST [xlabel="BPF_EXIST set and\nkey already exists"]
+ fn_htab_lru_map_update_elem4 ->
+ fn_htab_lru_map_update_elem_ENOENT [headlabel="BPF_NOEXIST set\nand no such entry"]
+
+ // Create invisible pad nodes to line up various nodes
+ pad0 [style=invis]
+ pad1 [style=invis]
+ pad2 [style=invis]
+ pad3 [style=invis]
+ pad4 [style=invis]
+
+ // Line up the key with the top of the graph
+ no_lock -> local_lock [style=invis]
+ local_lock -> lru_lock [style=invis]
+ lru_lock -> hash_lock [style=invis]
+ hash_lock -> remote_lock [style=invis]
+ remote_lock -> local_freelist_check5 [style=invis]
+ remote_lock -> fn___bpf_lru_list_shrink [style=invis]
+
+ // Line up return code nodes at the bottom of the graph
+ fn_htab_lru_map_update_elem -> pad0 [style=invis]
+ pad0 -> pad1 [style=invis]
+ pad1 -> pad2 [style=invis]
+ //pad2-> fn_htab_lru_map_update_elem_ENOMEM [style=invis]
+ fn_htab_lru_map_update_elem4 -> pad3 [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem5 [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem_EBUSY [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem_EEXIST [style=invis]
+ pad3 -> fn_htab_lru_map_update_elem_ENOENT [style=invis]
+
+ // Reduce diagram width by forcing some nodes to appear above others
+ local_freelist_check4 -> fn_htab_lru_map_update_elem3 [style=invis]
+ common_lru_check2 -> pad4 [style=invis]
+ pad4 -> local_freelist_check5 [style=invis]
+}
diff --git a/Documentation/bpf/map_of_maps.rst b/Documentation/bpf/map_of_maps.rst
new file mode 100644
index 000000000000..7b5617c2d017
--- /dev/null
+++ b/Documentation/bpf/map_of_maps.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+========================================================
+BPF_MAP_TYPE_ARRAY_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS
+========================================================
+
+.. note::
+ - ``BPF_MAP_TYPE_ARRAY_OF_MAPS`` and ``BPF_MAP_TYPE_HASH_OF_MAPS`` were
+ introduced in kernel version 4.12
+
+``BPF_MAP_TYPE_ARRAY_OF_MAPS`` and ``BPF_MAP_TYPE_HASH_OF_MAPS`` provide general
+purpose support for map in map storage. One level of nesting is supported, where
+an outer map contains instances of a single type of inner map, for example
+``array_of_maps->sock_map``.
+
+When creating an outer map, an inner map instance is used to initialize the
+metadata that the outer map holds about its inner maps. This inner map has a
+separate lifetime from the outer map and can be deleted after the outer map has
+been created.
+
+The outer map supports element lookup, update and delete from user space using
+the syscall API. A BPF program is only allowed to do element lookup in the outer
+map.
+
+.. note::
+ - Multi-level nesting is not supported.
+ - Any BPF map type can be used as an inner map, except for
+ ``BPF_MAP_TYPE_PROG_ARRAY``.
+ - A BPF program cannot update or delete outer map entries.
+
+For ``BPF_MAP_TYPE_ARRAY_OF_MAPS`` the key is an unsigned 32-bit integer index
+into the array. The array is a fixed size with ``max_entries`` elements that are
+zero initialized when created.
+
+For ``BPF_MAP_TYPE_HASH_OF_MAPS`` the key type can be chosen when defining the
+map. The kernel is responsible for allocating and freeing key/value pairs, up to
+the max_entries limit that you specify. Hash maps use pre-allocation of hash
+table elements by default. The ``BPF_F_NO_PREALLOC`` flag can be used to disable
+pre-allocation when it is too memory expensive.
+
+Usage
+=====
+
+Kernel BPF Helper
+-----------------
+
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+Inner maps can be retrieved using the ``bpf_map_lookup_elem()`` helper. This
+helper returns a pointer to the inner map, or ``NULL`` if no entry was found.
+
+Examples
+========
+
+Kernel BPF Example
+------------------
+
+This snippet shows how to create and initialise an array of devmaps in a BPF
+program. Note that the outer array can only be modified from user space using
+the syscall API.
+
+.. code-block:: c
+
+ struct inner_map {
+ __uint(type, BPF_MAP_TYPE_DEVMAP);
+ __uint(max_entries, 10);
+ __type(key, __u32);
+ __type(value, __u32);
+ } inner_map1 SEC(".maps"), inner_map2 SEC(".maps");
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_ARRAY_OF_MAPS);
+ __uint(max_entries, 2);
+ __type(key, __u32);
+ __array(values, struct inner_map);
+ } outer_map SEC(".maps") = {
+ .values = { &inner_map1,
+ &inner_map2 }
+ };
+
+See ``progs/test_btf_map_in_map.c`` in ``tools/testing/selftests/bpf`` for more
+examples of declarative initialisation of outer maps.
+
+User Space
+----------
+
+This snippet shows how to create an array based outer map:
+
+.. code-block:: c
+
+ int create_outer_array(int inner_fd) {
+ LIBBPF_OPTS(bpf_map_create_opts, opts, .inner_map_fd = inner_fd);
+ int fd;
+
+ fd = bpf_map_create(BPF_MAP_TYPE_ARRAY_OF_MAPS,
+ "example_array", /* name */
+ sizeof(__u32), /* key size */
+ sizeof(__u32), /* value size */
+ 256, /* max entries */
+ &opts); /* create opts */
+ return fd;
+ }
+
+
+This snippet shows how to add an inner map to an outer map:
+
+.. code-block:: c
+
+ int add_devmap(int outer_fd, int index, const char *name) {
+ int fd;
+
+ fd = bpf_map_create(BPF_MAP_TYPE_DEVMAP, name,
+ sizeof(__u32), sizeof(__u32), 256, NULL);
+ if (fd < 0)
+ return fd;
+
+ return bpf_map_update_elem(outer_fd, &index, &fd, BPF_ANY);
+ }
+
+References
+==========
+
+- https://lore.kernel.org/netdev/20170322170035.923581-3-kafai@fb.com/
+- https://lore.kernel.org/netdev/20170322170035.923581-4-kafai@fb.com/
diff --git a/Documentation/bpf/map_queue_stack.rst b/Documentation/bpf/map_queue_stack.rst
new file mode 100644
index 000000000000..8d14ed49d6e1
--- /dev/null
+++ b/Documentation/bpf/map_queue_stack.rst
@@ -0,0 +1,146 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+=========================================
+BPF_MAP_TYPE_QUEUE and BPF_MAP_TYPE_STACK
+=========================================
+
+.. note::
+ - ``BPF_MAP_TYPE_QUEUE`` and ``BPF_MAP_TYPE_STACK`` were introduced
+ in kernel version 4.20
+
+``BPF_MAP_TYPE_QUEUE`` provides FIFO storage and ``BPF_MAP_TYPE_STACK``
+provides LIFO storage for BPF programs. These maps support peek, pop and
+push operations that are exposed to BPF programs through the respective
+helpers. These operations are exposed to userspace applications using
+the existing ``bpf`` syscall in the following way:
+
+- ``BPF_MAP_LOOKUP_ELEM`` -> peek
+- ``BPF_MAP_LOOKUP_AND_DELETE_ELEM`` -> pop
+- ``BPF_MAP_UPDATE_ELEM`` -> push
+
+``BPF_MAP_TYPE_QUEUE`` and ``BPF_MAP_TYPE_STACK`` do not support
+``BPF_F_NO_PREALLOC``.
+
+Usage
+=====
+
+Kernel BPF
+----------
+
+bpf_map_push_elem()
+~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_push_elem(struct bpf_map *map, const void *value, u64 flags)
+
+An element ``value`` can be added to a queue or stack using the
+``bpf_map_push_elem`` helper. The ``flags`` parameter must be set to
+``BPF_ANY`` or ``BPF_EXIST``. If ``flags`` is set to ``BPF_EXIST`` then,
+when the queue or stack is full, the oldest element will be removed to
+make room for ``value`` to be added. Returns ``0`` on success, or
+negative error in case of failure.
+
+bpf_map_peek_elem()
+~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_peek_elem(struct bpf_map *map, void *value)
+
+This helper fetches an element ``value`` from a queue or stack without
+removing it. Returns ``0`` on success, or negative error in case of
+failure.
+
+bpf_map_pop_elem()
+~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_map_pop_elem(struct bpf_map *map, void *value)
+
+This helper removes an element into ``value`` from a queue or
+stack. Returns ``0`` on success, or negative error in case of failure.
+
+
+Userspace
+---------
+
+bpf_map_update_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_update_elem (int fd, const void *key, const void *value, __u64 flags)
+
+A userspace program can push ``value`` onto a queue or stack using libbpf's
+``bpf_map_update_elem`` function. The ``key`` parameter must be set to
+``NULL`` and ``flags`` must be set to ``BPF_ANY`` or ``BPF_EXIST``, with the
+same semantics as the ``bpf_map_push_elem`` kernel helper. Returns ``0`` on
+success, or negative error in case of failure.
+
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_lookup_elem (int fd, const void *key, void *value)
+
+A userspace program can peek at the ``value`` at the head of a queue or stack
+using the libbpf ``bpf_map_lookup_elem`` function. The ``key`` parameter must be
+set to ``NULL``. Returns ``0`` on success, or negative error in case of
+failure.
+
+bpf_map_lookup_and_delete_elem()
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_lookup_and_delete_elem (int fd, const void *key, void *value)
+
+A userspace program can pop a ``value`` from the head of a queue or stack using
+the libbpf ``bpf_map_lookup_and_delete_elem`` function. The ``key`` parameter
+must be set to ``NULL``. Returns ``0`` on success, or negative error in case of
+failure.
+
+Examples
+========
+
+Kernel BPF
+----------
+
+This snippet shows how to declare a queue in a BPF program:
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_QUEUE);
+ __type(value, __u32);
+ __uint(max_entries, 10);
+ } queue SEC(".maps");
+
+
+Userspace
+---------
+
+This snippet shows how to use libbpf's low-level API to create a queue from
+userspace:
+
+.. code-block:: c
+
+ int create_queue()
+ {
+ return bpf_map_create(BPF_MAP_TYPE_QUEUE,
+ "sample_queue", /* name */
+ 0, /* key size, must be zero */
+ sizeof(__u32), /* value size */
+ 10, /* max entries */
+ NULL); /* create options */
+ }
+
+
+References
+==========
+
+https://lwn.net/ml/netdev/153986858555.9127.14517764371945179514.stgit@kernel/
diff --git a/Documentation/bpf/map_sk_storage.rst b/Documentation/bpf/map_sk_storage.rst
new file mode 100644
index 000000000000..4e9d23ab9ecd
--- /dev/null
+++ b/Documentation/bpf/map_sk_storage.rst
@@ -0,0 +1,159 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+=======================
+BPF_MAP_TYPE_SK_STORAGE
+=======================
+
+.. note::
+ - ``BPF_MAP_TYPE_SK_STORAGE`` was introduced in kernel version 5.2
+
+``BPF_MAP_TYPE_SK_STORAGE`` is used to provide socket-local storage for BPF
+programs. A map of type ``BPF_MAP_TYPE_SK_STORAGE`` declares the type of storage
+to be provided and acts as the handle for accessing the socket-local
+storage. The values for maps of type ``BPF_MAP_TYPE_SK_STORAGE`` are stored
+locally with each socket instead of with the map. The kernel is responsible for
+allocating storage for a socket when requested and for freeing the storage when
+either the map or the socket is deleted.
+
+.. note::
+ - The key type must be ``int`` and ``max_entries`` must be set to ``0``.
+ - The ``BPF_F_NO_PREALLOC`` flag must be used when creating a map for
+ socket-local storage.
+
+Usage
+=====
+
+Kernel BPF
+----------
+
+bpf_sk_storage_get()
+~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ void *bpf_sk_storage_get(struct bpf_map *map, void *sk, void *value, u64 flags)
+
+Socket-local storage for ``map`` can be retrieved from socket ``sk`` using the
+``bpf_sk_storage_get()`` helper. If the ``BPF_LOCAL_STORAGE_GET_F_CREATE``
+flag is used then ``bpf_sk_storage_get()`` will create the storage for ``sk``
+if it does not already exist. ``value`` can be used together with
+``BPF_LOCAL_STORAGE_GET_F_CREATE`` to initialize the storage value, otherwise
+it will be zero initialized. Returns a pointer to the storage on success, or
+``NULL`` in case of failure.
+
+.. note::
+ - ``sk`` is a kernel ``struct sock`` pointer for LSM or tracing programs.
+ - ``sk`` is a ``struct bpf_sock`` pointer for other program types.
+
+bpf_sk_storage_delete()
+~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ long bpf_sk_storage_delete(struct bpf_map *map, void *sk)
+
+Socket-local storage for ``map`` can be deleted from socket ``sk`` using the
+``bpf_sk_storage_delete()`` helper. Returns ``0`` on success, or negative
+error in case of failure.
+
+User space
+----------
+
+bpf_map_update_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_update_elem(int map_fd, const void *key, const void *value, __u64 flags)
+
+Socket-local storage for map ``map_fd`` can be added or updated locally to a
+socket using the ``bpf_map_update_elem()`` libbpf function. The socket is
+identified by a `socket` ``fd`` stored in the pointer ``key``. The pointer
+``value`` has the data to be added or updated to the socket ``fd``. The type
+and size of ``value`` should be the same as the value type of the map
+definition.
+
+The ``flags`` parameter can be used to control the update behaviour:
+
+- ``BPF_ANY`` will create storage for `socket` ``fd`` or update existing storage.
+- ``BPF_NOEXIST`` will create storage for `socket` ``fd`` only if it did not
+ already exist, otherwise the call will fail with ``-EEXIST``.
+- ``BPF_EXIST`` will update existing storage for `socket` ``fd`` if it already
+ exists, otherwise the call will fail with ``-ENOENT``.
+
+Returns ``0`` on success, or negative error in case of failure.
+
+bpf_map_lookup_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_lookup_elem(int map_fd, const void *key, void *value)
+
+Socket-local storage for map ``map_fd`` can be retrieved from a socket using
+the ``bpf_map_lookup_elem()`` libbpf function. The storage is retrieved from
+the socket identified by a `socket` ``fd`` stored in the pointer
+``key``. Returns ``0`` on success, or negative error in case of failure.
+
+bpf_map_delete_elem()
+~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ int bpf_map_delete_elem(int map_fd, const void *key)
+
+Socket-local storage for map ``map_fd`` can be deleted from a socket using the
+``bpf_map_delete_elem()`` libbpf function. The storage is deleted from the
+socket identified by a `socket` ``fd`` stored in the pointer ``key``. Returns
+``0`` on success, or negative error in case of failure.
+
+Examples
+========
+
+Kernel BPF
+----------
+
+This snippet shows how to declare socket-local storage in a BPF program:
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_SK_STORAGE);
+ __uint(map_flags, BPF_F_NO_PREALLOC);
+ __type(key, int);
+ __type(value, struct my_storage);
+ } socket_storage SEC(".maps");
+
+This snippet shows how to retrieve socket-local storage in a BPF program:
+
+.. code-block:: c
+
+ SEC("sockops")
+ int _sockops(struct bpf_sock_ops *ctx)
+ {
+ struct my_storage *storage;
+ struct bpf_sock *sk;
+
+ sk = ctx->sk;
+ if (!sk)
+ return 1;
+
+ storage = bpf_sk_storage_get(&socket_storage, sk, 0,
+ BPF_LOCAL_STORAGE_GET_F_CREATE);
+ if (!storage)
+ return 1;
+
+ /* Use 'storage' here */
+
+ return 1;
+ }
+
+
+Please see the ``tools/testing/selftests/bpf`` directory for functional
+examples.
+
+References
+==========
+
+https://lwn.net/ml/netdev/20190426171103.61892-1-kafai@fb.com/
diff --git a/Documentation/bpf/map_sockmap.rst b/Documentation/bpf/map_sockmap.rst
new file mode 100644
index 000000000000..2d630686a00b
--- /dev/null
+++ b/Documentation/bpf/map_sockmap.rst
@@ -0,0 +1,498 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright Red Hat
+
+==============================================
+BPF_MAP_TYPE_SOCKMAP and BPF_MAP_TYPE_SOCKHASH
+==============================================
+
+.. note::
+ - ``BPF_MAP_TYPE_SOCKMAP`` was introduced in kernel version 4.14
+ - ``BPF_MAP_TYPE_SOCKHASH`` was introduced in kernel version 4.18
+
+``BPF_MAP_TYPE_SOCKMAP`` and ``BPF_MAP_TYPE_SOCKHASH`` maps can be used to
+redirect skbs between sockets or to apply policy at the socket level based on
+the result of a BPF (verdict) program with the help of the BPF helpers
+``bpf_sk_redirect_map()``, ``bpf_sk_redirect_hash()``,
+``bpf_msg_redirect_map()`` and ``bpf_msg_redirect_hash()``.
+
+``BPF_MAP_TYPE_SOCKMAP`` is backed by an array that uses an integer key as the
+index to look up a reference to a ``struct sock``. The map values are socket
+descriptors. Similarly, ``BPF_MAP_TYPE_SOCKHASH`` is a hash backed BPF map that
+holds references to sockets via their socket descriptors.
+
+.. note::
+ The value type is either __u32 or __u64; the latter (__u64) is to support
+ returning socket cookies to userspace. Returning the ``struct sock *`` that
+ the map holds to user-space is neither safe nor useful.
+
+These maps may have BPF programs attached to them, specifically a parser program
+and a verdict program. The parser program determines how much data has been
+parsed and therefore how much data needs to be queued to come to a verdict. The
+verdict program is essentially the redirect program and can return a verdict
+of ``__SK_DROP``, ``__SK_PASS``, or ``__SK_REDIRECT``.
+
+When a socket is inserted into one of these maps, its socket callbacks are
+replaced and a ``struct sk_psock`` is attached to it. Additionally, this
+``sk_psock`` inherits the programs that are attached to the map.
+
+A sock object may be in multiple maps, but can only inherit a single
+parse or verdict program. If adding a sock object to a map would result
+in having multiple parser programs the update will return an EBUSY error.
+
+The supported programs to attach to these maps are:
+
+.. code-block:: c
+
+ struct sk_psock_progs {
+ struct bpf_prog *msg_parser;
+ struct bpf_prog *stream_parser;
+ struct bpf_prog *stream_verdict;
+ struct bpf_prog *skb_verdict;
+ };
+
+.. note::
+ Users are not allowed to attach ``stream_verdict`` and ``skb_verdict``
+ programs to the same map.
+
+The attach types for the map programs are:
+
+- ``msg_parser`` program - ``BPF_SK_MSG_VERDICT``.
+- ``stream_parser`` program - ``BPF_SK_SKB_STREAM_PARSER``.
+- ``stream_verdict`` program - ``BPF_SK_SKB_STREAM_VERDICT``.
+- ``skb_verdict`` program - ``BPF_SK_SKB_VERDICT``.
+
+There are additional helpers available to use with the parser and verdict
+programs: ``bpf_msg_apply_bytes()`` and ``bpf_msg_cork_bytes()``. With
+``bpf_msg_apply_bytes()`` BPF programs can tell the infrastructure how many
+bytes the given verdict should apply to. The helper ``bpf_msg_cork_bytes()``
+handles a different case where a BPF program cannot reach a verdict on a msg
+until it receives more bytes AND the program doesn't want to forward the packet
+until it is known to be good.
+
+Finally, the helpers ``bpf_msg_pull_data()`` and ``bpf_msg_push_data()`` are
+available to ``BPF_PROG_TYPE_SK_MSG`` BPF programs to pull in data and set the
+start and end pointers to given values or to add metadata to the ``struct
+sk_msg_buff *msg``.
+
+All these helpers will be described in more detail below.
+
+Usage
+=====
+Kernel BPF
+----------
+bpf_msg_redirect_map()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_redirect_map(struct sk_msg_buff *msg, struct bpf_map *map, u32 key, u64 flags)
+
+This helper is used in programs implementing policies at the socket level. If
+the message ``msg`` is allowed to pass (i.e., if the verdict BPF program
+returns ``SK_PASS``), redirect it to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKMAP``) at index ``key``. Both ingress and egress interfaces
+can be used for redirection. The ``BPF_F_INGRESS`` value in ``flags`` is used
+to select the ingress path otherwise the egress path is selected. This is the
+only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_sk_redirect_map()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sk_redirect_map(struct sk_buff *skb, struct bpf_map *map, u32 key u64 flags)
+
+Redirect the packet to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKMAP``) at index ``key``. Both ingress and egress interfaces
+can be used for redirection. The ``BPF_F_INGRESS`` value in ``flags`` is used
+to select the ingress path otherwise the egress path is selected. This is the
+only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+socket entries of type ``struct sock *`` can be retrieved using the
+``bpf_map_lookup_elem()`` helper.
+
+bpf_sock_map_update()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sock_map_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags)
+
+Add an entry to, or update a ``map`` referencing sockets. The ``skops`` is used
+as a new value for the entry associated to ``key``. The ``flags`` argument can
+be one of the following:
+
+- ``BPF_ANY``: Create a new element or update an existing element.
+- ``BPF_NOEXIST``: Create a new element only if it did not exist.
+- ``BPF_EXIST``: Update an existing element.
+
+If the ``map`` has BPF programs (parser and verdict), those will be inherited
+by the socket being added. If the socket is already attached to BPF programs,
+this results in an error.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_sock_hash_update()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sock_hash_update(struct bpf_sock_ops *skops, struct bpf_map *map, void *key, u64 flags)
+
+Add an entry to, or update a sockhash ``map`` referencing sockets. The ``skops``
+is used as a new value for the entry associated to ``key``.
+
+The ``flags`` argument can be one of the following:
+
+- ``BPF_ANY``: Create a new element or update an existing element.
+- ``BPF_NOEXIST``: Create a new element only if it did not exist.
+- ``BPF_EXIST``: Update an existing element.
+
+If the ``map`` has BPF programs (parser and verdict), those will be inherited
+by the socket being added. If the socket is already attached to BPF programs,
+this results in an error.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_msg_redirect_hash()
+^^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_redirect_hash(struct sk_msg_buff *msg, struct bpf_map *map, void *key, u64 flags)
+
+This helper is used in programs implementing policies at the socket level. If
+the message ``msg`` is allowed to pass (i.e., if the verdict BPF program returns
+``SK_PASS``), redirect it to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKHASH``) using hash ``key``. Both ingress and egress
+interfaces can be used for redirection. The ``BPF_F_INGRESS`` value in
+``flags`` is used to select the ingress path otherwise the egress path is
+selected. This is the only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_sk_redirect_hash()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_sk_redirect_hash(struct sk_buff *skb, struct bpf_map *map, void *key, u64 flags)
+
+This helper is used in programs implementing policies at the skb socket level.
+If the sk_buff ``skb`` is allowed to pass (i.e., if the verdict BPF program
+returns ``SK_PASS``), redirect it to the socket referenced by ``map`` (of type
+``BPF_MAP_TYPE_SOCKHASH``) using hash ``key``. Both ingress and egress
+interfaces can be used for redirection. The ``BPF_F_INGRESS`` value in
+``flags`` is used to select the ingress path otherwise the egress path is
+selected. This is the only flag supported for now.
+
+Returns ``SK_PASS`` on success, or ``SK_DROP`` on error.
+
+bpf_msg_apply_bytes()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_apply_bytes(struct sk_msg_buff *msg, u32 bytes)
+
+For socket policies, apply the verdict of the BPF program to the next (number
+of ``bytes``) of message ``msg``. For example, this helper can be used in the
+following cases:
+
+- A single ``sendmsg()`` or ``sendfile()`` system call contains multiple
+ logical messages that the BPF program is supposed to read and for which it
+ should apply a verdict.
+- A BPF program only cares to read the first ``bytes`` of a ``msg``. If the
+ message has a large payload, then setting up and calling the BPF program
+ repeatedly for all bytes, even though the verdict is already known, would
+ create unnecessary overhead.
+
+Returns 0
+
+bpf_msg_cork_bytes()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_cork_bytes(struct sk_msg_buff *msg, u32 bytes)
+
+For socket policies, prevent the execution of the verdict BPF program for
+message ``msg`` until the number of ``bytes`` have been accumulated.
+
+This can be used when one needs a specific number of bytes before a verdict can
+be assigned, even if the data spans multiple ``sendmsg()`` or ``sendfile()``
+calls.
+
+Returns 0
+
+bpf_msg_pull_data()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_msg_pull_data(struct sk_msg_buff *msg, u32 start, u32 end, u64 flags)
+
+For socket policies, pull in non-linear data from user space for ``msg`` and set
+pointers ``msg->data`` and ``msg->data_end`` to ``start`` and ``end`` bytes
+offsets into ``msg``, respectively.
+
+If a program of type ``BPF_PROG_TYPE_SK_MSG`` is run on a ``msg`` it can only
+parse data that the (``data``, ``data_end``) pointers have already consumed.
+For ``sendmsg()`` hooks this is likely the first scatterlist element. But for
+calls relying on MSG_SPLICE_PAGES (e.g., ``sendfile()``) this will be the
+range (**0**, **0**) because the data is shared with user space and by default
+the objective is to avoid allowing user space to modify data while (or after)
+BPF verdict is being decided. This helper can be used to pull in data and to
+set the start and end pointers to given values. Data will be copied if
+necessary (i.e., if data was not linear and if start and end pointers do not
+point to the same chunk).
+
+A call to this helper is susceptible to change the underlying packet buffer.
+Therefore, at load time, all checks on pointers previously done by the verifier
+are invalidated and must be performed again, if the helper is used in
+combination with direct packet access.
+
+All values for ``flags`` are reserved for future usage, and must be left at
+zero.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+Look up a socket entry in the sockmap or sockhash map.
+
+Returns the socket entry associated to ``key``, or NULL if no entry was found.
+
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
+
+Add or update a socket entry in a sockmap or sockhash.
+
+The flags argument can be one of the following:
+
+- BPF_ANY: Create a new element or update an existing element.
+- BPF_NOEXIST: Create a new element only if it did not exist.
+- BPF_EXIST: Update an existing element.
+
+Returns 0 on success, or a negative error in case of failure.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_map_delete_elem(struct bpf_map *map, const void *key)
+
+Delete a socket entry from a sockmap or a sockhash.
+
+Returns 0 on success, or a negative error in case of failure.
+
+User space
+----------
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_update_elem(int fd, const void *key, const void *value, __u64 flags)
+
+Sockmap entries can be added or updated using the ``bpf_map_update_elem()``
+function. The ``key`` parameter is the index value of the sockmap array. And the
+``value`` parameter is the FD value of that socket.
+
+Under the hood, the sockmap update function uses the socket FD value to
+retrieve the associated socket and its attached psock.
+
+The flags argument can be one of the following:
+
+- BPF_ANY: Create a new element or update an existing element.
+- BPF_NOEXIST: Create a new element only if it did not exist.
+- BPF_EXIST: Update an existing element.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_lookup_elem(int fd, const void *key, void *value)
+
+Sockmap entries can be retrieved using the ``bpf_map_lookup_elem()`` function.
+
+.. note::
+ The entry returned is a socket cookie rather than a socket itself.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_delete_elem(int fd, const void *key)
+
+Sockmap entries can be deleted using the ``bpf_map_delete_elem()``
+function.
+
+Returns 0 on success, or negative error in case of failure.
+
+Examples
+========
+
+Kernel BPF
+----------
+Several examples of the use of sockmap APIs can be found in:
+
+- `tools/testing/selftests/bpf/progs/test_sockmap_kern.h`_
+- `tools/testing/selftests/bpf/progs/sockmap_parse_prog.c`_
+- `tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c`_
+- `tools/testing/selftests/bpf/progs/test_sockmap_listen.c`_
+- `tools/testing/selftests/bpf/progs/test_sockmap_update.c`_
+
+The following code snippet shows how to declare a sockmap.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_SOCKMAP);
+ __uint(max_entries, 1);
+ __type(key, __u32);
+ __type(value, __u64);
+ } sock_map_rx SEC(".maps");
+
+The following code snippet shows a sample parser program.
+
+.. code-block:: c
+
+ SEC("sk_skb/stream_parser")
+ int bpf_prog_parser(struct __sk_buff *skb)
+ {
+ return skb->len;
+ }
+
+The following code snippet shows a simple verdict program that interacts with a
+sockmap to redirect traffic to another socket based on the local port.
+
+.. code-block:: c
+
+ SEC("sk_skb/stream_verdict")
+ int bpf_prog_verdict(struct __sk_buff *skb)
+ {
+ __u32 lport = skb->local_port;
+ __u32 idx = 0;
+
+ if (lport == 10000)
+ return bpf_sk_redirect_map(skb, &sock_map_rx, idx, 0);
+
+ return SK_PASS;
+ }
+
+The following code snippet shows how to declare a sockhash map.
+
+.. code-block:: c
+
+ struct socket_key {
+ __u32 src_ip;
+ __u32 dst_ip;
+ __u32 src_port;
+ __u32 dst_port;
+ };
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_SOCKHASH);
+ __uint(max_entries, 1);
+ __type(key, struct socket_key);
+ __type(value, __u64);
+ } sock_hash_rx SEC(".maps");
+
+The following code snippet shows a simple verdict program that interacts with a
+sockhash to redirect traffic to another socket based on a hash of some of the
+skb parameters.
+
+.. code-block:: c
+
+ static inline
+ void extract_socket_key(struct __sk_buff *skb, struct socket_key *key)
+ {
+ key->src_ip = skb->remote_ip4;
+ key->dst_ip = skb->local_ip4;
+ key->src_port = skb->remote_port >> 16;
+ key->dst_port = (bpf_htonl(skb->local_port)) >> 16;
+ }
+
+ SEC("sk_skb/stream_verdict")
+ int bpf_prog_verdict(struct __sk_buff *skb)
+ {
+ struct socket_key key;
+
+ extract_socket_key(skb, &key);
+
+ return bpf_sk_redirect_hash(skb, &sock_hash_rx, &key, 0);
+ }
+
+User space
+----------
+Several examples of the use of sockmap APIs can be found in:
+
+- `tools/testing/selftests/bpf/prog_tests/sockmap_basic.c`_
+- `tools/testing/selftests/bpf/test_sockmap.c`_
+- `tools/testing/selftests/bpf/test_maps.c`_
+
+The following code sample shows how to create a sockmap, attach a parser and
+verdict program, as well as add a socket entry.
+
+.. code-block:: c
+
+ int create_sample_sockmap(int sock, int parse_prog_fd, int verdict_prog_fd)
+ {
+ int index = 0;
+ int map, err;
+
+ map = bpf_map_create(BPF_MAP_TYPE_SOCKMAP, NULL, sizeof(int), sizeof(int), 1, NULL);
+ if (map < 0) {
+ fprintf(stderr, "Failed to create sockmap: %s\n", strerror(errno));
+ return -1;
+ }
+
+ err = bpf_prog_attach(parse_prog_fd, map, BPF_SK_SKB_STREAM_PARSER, 0);
+ if (err){
+ fprintf(stderr, "Failed to attach_parser_prog_to_map: %s\n", strerror(errno));
+ goto out;
+ }
+
+ err = bpf_prog_attach(verdict_prog_fd, map, BPF_SK_SKB_STREAM_VERDICT, 0);
+ if (err){
+ fprintf(stderr, "Failed to attach_verdict_prog_to_map: %s\n", strerror(errno));
+ goto out;
+ }
+
+ err = bpf_map_update_elem(map, &index, &sock, BPF_NOEXIST);
+ if (err) {
+ fprintf(stderr, "Failed to update sockmap: %s\n", strerror(errno));
+ goto out;
+ }
+
+ out:
+ close(map);
+ return err;
+ }
+
+References
+===========
+
+- https://github.com/jrfastab/linux-kernel-xdp/commit/c89fd73cb9d2d7f3c716c3e00836f07b1aeb261f
+- https://lwn.net/Articles/731133/
+- http://vger.kernel.org/lpc_net2018_talks/ktls_bpf_paper.pdf
+- https://lwn.net/Articles/748628/
+- https://lore.kernel.org/bpf/20200218171023.844439-7-jakub@cloudflare.com/
+
+.. _`tools/testing/selftests/bpf/progs/test_sockmap_kern.h`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/test_sockmap_kern.h
+.. _`tools/testing/selftests/bpf/progs/sockmap_parse_prog.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/sockmap_parse_prog.c
+.. _`tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/sockmap_verdict_prog.c
+.. _`tools/testing/selftests/bpf/prog_tests/sockmap_basic.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+.. _`tools/testing/selftests/bpf/test_sockmap.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/test_sockmap.c
+.. _`tools/testing/selftests/bpf/test_maps.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/test_maps.c
+.. _`tools/testing/selftests/bpf/progs/test_sockmap_listen.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/test_sockmap_listen.c
+.. _`tools/testing/selftests/bpf/progs/test_sockmap_update.c`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/progs/test_sockmap_update.c
diff --git a/Documentation/bpf/map_xskmap.rst b/Documentation/bpf/map_xskmap.rst
new file mode 100644
index 000000000000..dc143edd9233
--- /dev/null
+++ b/Documentation/bpf/map_xskmap.rst
@@ -0,0 +1,192 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+===================
+BPF_MAP_TYPE_XSKMAP
+===================
+
+.. note::
+ - ``BPF_MAP_TYPE_XSKMAP`` was introduced in kernel version 4.18
+
+The ``BPF_MAP_TYPE_XSKMAP`` is used as a backend map for XDP BPF helper
+call ``bpf_redirect_map()`` and ``XDP_REDIRECT`` action, like 'devmap' and 'cpumap'.
+This map type redirects raw XDP frames to `AF_XDP`_ sockets (XSKs), a new type of
+address family in the kernel that allows redirection of frames from a driver to
+user space without having to traverse the full network stack. An AF_XDP socket
+binds to a single netdev queue. A mapping of XSKs to queues is shown below:
+
+.. code-block:: none
+
+ +---------------------------------------------------+
+ | xsk A | xsk B | xsk C |<---+ User space
+ =========================================================|==========
+ | Queue 0 | Queue 1 | Queue 2 | | Kernel
+ +---------------------------------------------------+ |
+ | Netdev eth0 | |
+ +---------------------------------------------------+ |
+ | +=============+ | |
+ | | key | xsk | | |
+ | +---------+ +=============+ | |
+ | | | | 0 | xsk A | | |
+ | | | +-------------+ | |
+ | | | | 1 | xsk B | | |
+ | | BPF |-- redirect -->+-------------+-------------+
+ | | prog | | 2 | xsk C | |
+ | | | +-------------+ |
+ | | | |
+ | | | |
+ | +---------+ |
+ | |
+ +---------------------------------------------------+
+
+.. note::
+ An AF_XDP socket that is bound to a certain <netdev/queue_id> will *only*
+ accept XDP frames from that <netdev/queue_id>. If an XDP program tries to redirect
+ from a <netdev/queue_id> other than what the socket is bound to, the frame will
+ not be received on the socket.
+
+Typically an XSKMAP is created per netdev. This map contains an array of XSK File
+Descriptors (FDs). The number of array elements is typically set or adjusted using
+the ``max_entries`` map parameter. For AF_XDP ``max_entries`` is equal to the number
+of queues supported by the netdev.
+
+.. note::
+ Both the map key and map value size must be 4 bytes.
+
+Usage
+=====
+
+Kernel BPF
+----------
+bpf_redirect_map()
+^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ long bpf_redirect_map(struct bpf_map *map, u32 key, u64 flags)
+
+Redirect the packet to the endpoint referenced by ``map`` at index ``key``.
+For ``BPF_MAP_TYPE_XSKMAP`` this map contains references to XSK FDs
+for sockets attached to a netdev's queues.
+
+.. note::
+ If the map is empty at an index, the packet is dropped. This means that it is
+ necessary to have an XDP program loaded with at least one XSK in the
+ XSKMAP to be able to get any traffic to user space through the socket.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+
+XSK entry references of type ``struct xdp_sock *`` can be retrieved using the
+``bpf_map_lookup_elem()`` helper.
+
+User space
+----------
+.. note::
+ XSK entries can only be updated/deleted from user space and not from
+ a BPF program. Trying to call these functions from a kernel BPF program will
+ result in the program failing to load and a verifier warning.
+
+bpf_map_update_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_update_elem(int fd, const void *key, const void *value, __u64 flags)
+
+XSK entries can be added or updated using the ``bpf_map_update_elem()``
+helper. The ``key`` parameter is equal to the queue_id of the queue the XSK
+is attaching to. And the ``value`` parameter is the FD value of that socket.
+
+Under the hood, the XSKMAP update function uses the XSK FD value to retrieve the
+associated ``struct xdp_sock`` instance.
+
+The flags argument can be one of the following:
+
+- BPF_ANY: Create a new element or update an existing element.
+- BPF_NOEXIST: Create a new element only if it did not exist.
+- BPF_EXIST: Update an existing element.
+
+bpf_map_lookup_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_lookup_elem(int fd, const void *key, void *value)
+
+Returns ``struct xdp_sock *`` or negative error in case of failure.
+
+bpf_map_delete_elem()
+^^^^^^^^^^^^^^^^^^^^^
+.. code-block:: c
+
+ int bpf_map_delete_elem(int fd, const void *key)
+
+XSK entries can be deleted using the ``bpf_map_delete_elem()``
+helper. This helper will return 0 on success, or negative error in case of
+failure.
+
+.. note::
+ When `libxdp`_ deletes an XSK it also removes the associated socket
+ entry from the XSKMAP.
+
+Examples
+========
+Kernel
+------
+
+The following code snippet shows how to declare a ``BPF_MAP_TYPE_XSKMAP`` called
+``xsks_map`` and how to redirect packets to an XSK.
+
+.. code-block:: c
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_XSKMAP);
+ __type(key, __u32);
+ __type(value, __u32);
+ __uint(max_entries, 64);
+ } xsks_map SEC(".maps");
+
+
+ SEC("xdp")
+ int xsk_redir_prog(struct xdp_md *ctx)
+ {
+ __u32 index = ctx->rx_queue_index;
+
+ if (bpf_map_lookup_elem(&xsks_map, &index))
+ return bpf_redirect_map(&xsks_map, index, 0);
+ return XDP_PASS;
+ }
+
+User space
+----------
+
+The following code snippet shows how to update an XSKMAP with an XSK entry.
+
+.. code-block:: c
+
+ int update_xsks_map(struct bpf_map *xsks_map, int queue_id, int xsk_fd)
+ {
+ int ret;
+
+ ret = bpf_map_update_elem(bpf_map__fd(xsks_map), &queue_id, &xsk_fd, 0);
+ if (ret < 0)
+ fprintf(stderr, "Failed to update xsks_map: %s\n", strerror(errno));
+
+ return ret;
+ }
+
+For an example on how create AF_XDP sockets, please see the AF_XDP-example and
+AF_XDP-forwarding programs in the `bpf-examples`_ directory in the `libxdp`_ repository.
+For a detailed explanation of the AF_XDP interface please see:
+
+- `libxdp-readme`_.
+- `AF_XDP`_ kernel documentation.
+
+.. note::
+ The most comprehensive resource for using XSKMAPs and AF_XDP is `libxdp`_.
+
+.. _libxdp: https://github.com/xdp-project/xdp-tools/tree/master/lib/libxdp
+.. _AF_XDP: https://www.kernel.org/doc/html/latest/networking/af_xdp.html
+.. _bpf-examples: https://github.com/xdp-project/bpf-examples
+.. _libxdp-readme: https://github.com/xdp-project/xdp-tools/tree/master/lib/libxdp#using-af_xdp-sockets
diff --git a/Documentation/bpf/maps.rst b/Documentation/bpf/maps.rst
index f41619e312ac..6f069f3d6f4b 100644
--- a/Documentation/bpf/maps.rst
+++ b/Documentation/bpf/maps.rst
@@ -1,52 +1,82 @@
-=========
-eBPF maps
+========
+BPF maps
+========
+
+BPF 'maps' provide generic storage of different types for sharing data between
+kernel and user space. There are several storage types available, including
+hash, array, bloom filter and radix-tree. Several of the map types exist to
+support specific BPF helpers that perform actions based on the map contents. The
+maps are accessed from BPF programs via BPF helpers which are documented in the
+`man-pages`_ for `bpf-helpers(7)`_.
+
+BPF maps are accessed from user space via the ``bpf`` syscall, which provides
+commands to create maps, lookup elements, update elements and delete elements.
+More details of the BPF syscall are available in `ebpf-syscall`_ and in the
+`man-pages`_ for `bpf(2)`_.
+
+Map Types
=========
-'maps' is a generic storage of different types for sharing data between kernel
-and userspace.
+.. toctree::
+ :maxdepth: 1
+ :glob:
-The maps are accessed from user space via BPF syscall, which has commands:
+ map_*
-- create a map with given type and attributes
- ``map_fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)``
- using attr->map_type, attr->key_size, attr->value_size, attr->max_entries
- returns process-local file descriptor or negative error
+Usage Notes
+===========
-- lookup key in a given map
- ``err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)``
- using attr->map_fd, attr->key, attr->value
- returns zero and stores found elem into value or negative error
+.. c:function::
+ int bpf(int command, union bpf_attr *attr, u32 size)
-- create or update key/value pair in a given map
- ``err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)``
- using attr->map_fd, attr->key, attr->value
- returns zero or negative error
+Use the ``bpf()`` system call to perform the operation specified by
+``command``. The operation takes parameters provided in ``attr``. The ``size``
+argument is the size of the ``union bpf_attr`` in ``attr``.
-- find and delete element by key in a given map
- ``err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)``
- using attr->map_fd, attr->key
+**BPF_MAP_CREATE**
-- to delete map: close(fd)
- Exiting process will delete maps automatically
+Create a map with the desired type and attributes in ``attr``:
-userspace programs use this syscall to create/access maps that eBPF programs
-are concurrently updating.
+.. code-block:: c
-maps can have different types: hash, array, bloom filter, radix-tree, etc.
+ int fd;
+ union bpf_attr attr = {
+ .map_type = BPF_MAP_TYPE_ARRAY; /* mandatory */
+ .key_size = sizeof(__u32); /* mandatory */
+ .value_size = sizeof(__u32); /* mandatory */
+ .max_entries = 256; /* mandatory */
+ .map_flags = BPF_F_MMAPABLE;
+ .map_name = "example_array";
+ };
-The map is defined by:
+ fd = bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
- - type
- - max number of elements
- - key size in bytes
- - value size in bytes
+Returns a process-local file descriptor on success, or negative error in case of
+failure. The map can be deleted by calling ``close(fd)``. Maps held by open
+file descriptors will be deleted automatically when a process exits.
-Map Types
-=========
+.. note:: Valid characters for ``map_name`` are ``A-Z``, ``a-z``, ``0-9``,
+ ``'_'`` and ``'.'``.
-.. toctree::
- :maxdepth: 1
- :glob:
+**BPF_MAP_LOOKUP_ELEM**
+
+Lookup key in a given map using ``attr->map_fd``, ``attr->key``,
+``attr->value``. Returns zero and stores found elem into ``attr->value`` on
+success, or negative error on failure.
+
+**BPF_MAP_UPDATE_ELEM**
+
+Create or update key/value pair in a given map using ``attr->map_fd``, ``attr->key``,
+``attr->value``. Returns zero on success or negative error on failure.
+
+**BPF_MAP_DELETE_ELEM**
+
+Find and delete element by key in a given map using ``attr->map_fd``,
+``attr->key``. Returns zero on success or negative error on failure.
- map_* \ No newline at end of file
+.. Links:
+.. _man-pages: https://www.kernel.org/doc/man-pages/
+.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
+.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
+.. _ebpf-syscall: https://docs.kernel.org/userspace-api/ebpf/syscall.html
diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst
index 3d61963403b4..7e6b12018802 100644
--- a/Documentation/bpf/other.rst
+++ b/Documentation/bpf/other.rst
@@ -6,4 +6,5 @@ Other
:maxdepth: 1
ringbuf
- llvm_reloc \ No newline at end of file
+ llvm_reloc
+ graph_ds_impl
diff --git a/Documentation/bpf/prog_cgroup_sockopt.rst b/Documentation/bpf/prog_cgroup_sockopt.rst
index 172f957204bf..1226a94af07a 100644
--- a/Documentation/bpf/prog_cgroup_sockopt.rst
+++ b/Documentation/bpf/prog_cgroup_sockopt.rst
@@ -98,10 +98,65 @@ can access only the first ``PAGE_SIZE`` of that data. So it has to options:
indicates that the kernel should use BPF's trimmed ``optval``.
When the BPF program returns with the ``optlen`` greater than
-``PAGE_SIZE``, the userspace will receive ``EFAULT`` errno.
+``PAGE_SIZE``, the userspace will receive original kernel
+buffers without any modifications that the BPF program might have
+applied.
Example
=======
+Recommended way to handle BPF programs is as follows:
+
+.. code-block:: c
+
+ SEC("cgroup/getsockopt")
+ int getsockopt(struct bpf_sockopt *ctx)
+ {
+ /* Custom socket option. */
+ if (ctx->level == MY_SOL && ctx->optname == MY_OPTNAME) {
+ ctx->retval = 0;
+ optval[0] = ...;
+ ctx->optlen = 1;
+ return 1;
+ }
+
+ /* Modify kernel's socket option. */
+ if (ctx->level == SOL_IP && ctx->optname == IP_FREEBIND) {
+ ctx->retval = 0;
+ optval[0] = ...;
+ ctx->optlen = 1;
+ return 1;
+ }
+
+ /* optval larger than PAGE_SIZE use kernel's buffer. */
+ if (ctx->optlen > PAGE_SIZE)
+ ctx->optlen = 0;
+
+ return 1;
+ }
+
+ SEC("cgroup/setsockopt")
+ int setsockopt(struct bpf_sockopt *ctx)
+ {
+ /* Custom socket option. */
+ if (ctx->level == MY_SOL && ctx->optname == MY_OPTNAME) {
+ /* do something */
+ ctx->optlen = -1;
+ return 1;
+ }
+
+ /* Modify kernel's socket option. */
+ if (ctx->level == SOL_IP && ctx->optname == IP_FREEBIND) {
+ optval[0] = ...;
+ return 1;
+ }
+
+ /* optval larger than PAGE_SIZE use kernel's buffer. */
+ if (ctx->optlen > PAGE_SIZE)
+ ctx->optlen = 0;
+
+ return 1;
+ }
+
See ``tools/testing/selftests/bpf/progs/sockopt_sk.c`` for an example
of BPF program that handles socket options.
diff --git a/Documentation/bpf/prog_flow_dissector.rst b/Documentation/bpf/prog_flow_dissector.rst
index 4d86780ab0f1..f24270b8b034 100644
--- a/Documentation/bpf/prog_flow_dissector.rst
+++ b/Documentation/bpf/prog_flow_dissector.rst
@@ -113,7 +113,7 @@ Flags
used by ``eth_get_headlen`` to estimate length of all headers for GRO.
* ``BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL`` - tells BPF flow dissector to
stop parsing as soon as it reaches IPv6 flow label; used by
- ``___skb_get_hash`` and ``__skb_get_hash_symmetric`` to get flow hash.
+ ``___skb_get_hash`` to get flow hash.
* ``BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP`` - tells BPF flow dissector to stop
parsing as soon as it reaches encapsulated headers; used by routing
infrastructure.
diff --git a/Documentation/bpf/prog_lsm.rst b/Documentation/bpf/prog_lsm.rst
index 0dc3fb0d9544..ad2be02f30c2 100644
--- a/Documentation/bpf/prog_lsm.rst
+++ b/Documentation/bpf/prog_lsm.rst
@@ -18,7 +18,7 @@ LSM hook:
.. c:function:: int file_mprotect(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot);
Other LSM hooks which can be instrumented can be found in
-``include/linux/lsm_hooks.h``.
+``security/security.c``.
eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel
headers for accessing information from the attached eBPF program's context.
diff --git a/Documentation/bpf/programs.rst b/Documentation/bpf/programs.rst
index 620eb667ac7a..c99000ab6d9b 100644
--- a/Documentation/bpf/programs.rst
+++ b/Documentation/bpf/programs.rst
@@ -7,3 +7,6 @@ Program Types
:glob:
prog_*
+
+For a list of all program types, see :ref:`program_types_and_elf` in
+the :ref:`libbpf` documentation.
diff --git a/Documentation/bpf/redirect.rst b/Documentation/bpf/redirect.rst
new file mode 100644
index 000000000000..2fa2b0b05004
--- /dev/null
+++ b/Documentation/bpf/redirect.rst
@@ -0,0 +1,81 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2022 Red Hat, Inc.
+
+========
+Redirect
+========
+XDP_REDIRECT
+############
+Supported maps
+--------------
+
+XDP_REDIRECT works with the following map types:
+
+- ``BPF_MAP_TYPE_DEVMAP``
+- ``BPF_MAP_TYPE_DEVMAP_HASH``
+- ``BPF_MAP_TYPE_CPUMAP``
+- ``BPF_MAP_TYPE_XSKMAP``
+
+For more information on these maps, please see the specific map documentation.
+
+Process
+-------
+
+.. kernel-doc:: net/core/filter.c
+ :doc: xdp redirect
+
+.. note::
+ Not all drivers support transmitting frames after a redirect, and for
+ those that do, not all of them support non-linear frames. Non-linear xdp
+ bufs/frames are bufs/frames that contain more than one fragment.
+
+Debugging packet drops
+----------------------
+Silent packet drops for XDP_REDIRECT can be debugged using:
+
+- bpf_trace
+- perf_record
+
+bpf_trace
+^^^^^^^^^
+The following bpftrace command can be used to capture and count all XDP tracepoints:
+
+.. code-block:: none
+
+ sudo bpftrace -e 'tracepoint:xdp:* { @cnt[probe] = count(); }'
+ Attaching 12 probes...
+ ^C
+
+ @cnt[tracepoint:xdp:mem_connect]: 18
+ @cnt[tracepoint:xdp:mem_disconnect]: 18
+ @cnt[tracepoint:xdp:xdp_exception]: 19605
+ @cnt[tracepoint:xdp:xdp_devmap_xmit]: 1393604
+ @cnt[tracepoint:xdp:xdp_redirect]: 22292200
+
+.. note::
+ The various xdp tracepoints can be found in ``source/include/trace/events/xdp.h``
+
+The following bpftrace command can be used to extract the ``ERRNO`` being returned as
+part of the err parameter:
+
+.. code-block:: none
+
+ sudo bpftrace -e \
+ 'tracepoint:xdp:xdp_redirect*_err {@redir_errno[-args->err] = count();}
+ tracepoint:xdp:xdp_devmap_xmit {@devmap_errno[-args->err] = count();}'
+
+perf record
+^^^^^^^^^^^
+The perf tool also supports recording tracepoints:
+
+.. code-block:: none
+
+ perf record -a -e xdp:xdp_redirect_err \
+ -e xdp:xdp_redirect_map_err \
+ -e xdp:xdp_exception \
+ -e xdp:xdp_devmap_xmit
+
+References
+===========
+
+- https://github.com/xdp-project/xdp-tutorial/tree/master/tracing02-xdp-monitor
diff --git a/Documentation/bpf/ringbuf.rst b/Documentation/bpf/ringbuf.rst
index 6a615cd62bda..a99cd05d79d4 100644
--- a/Documentation/bpf/ringbuf.rst
+++ b/Documentation/bpf/ringbuf.rst
@@ -124,7 +124,7 @@ buffer. Currently 4 are supported:
- ``BPF_RB_AVAIL_DATA`` returns amount of unconsumed data in ring buffer;
- ``BPF_RB_RING_SIZE`` returns the size of ring buffer;
-- ``BPF_RB_CONS_POS``/``BPF_RB_PROD_POS`` returns current logical possition
+- ``BPF_RB_CONS_POS``/``BPF_RB_PROD_POS`` returns current logical position
of consumer/producer, respectively.
Returned values are momentarily snapshots of ring buffer state and could be
@@ -146,7 +146,7 @@ Design and Implementation
This reserve/commit schema allows a natural way for multiple producers, either
on different CPUs or even on the same CPU/in the same BPF program, to reserve
independent records and work with them without blocking other producers. This
-means that if BPF program was interruped by another BPF program sharing the
+means that if BPF program was interrupted by another BPF program sharing the
same ring buffer, they will both get a record reserved (provided there is
enough space left) and can work with it and submit it independently. This
applies to NMI context as well, except that due to using a spinlock during
diff --git a/Documentation/bpf/standardization/abi.rst b/Documentation/bpf/standardization/abi.rst
new file mode 100644
index 000000000000..41514137cb7b
--- /dev/null
+++ b/Documentation/bpf/standardization/abi.rst
@@ -0,0 +1,28 @@
+.. contents::
+.. sectnum::
+
+===================================================
+BPF ABI Recommended Conventions and Guidelines v1.0
+===================================================
+
+This is version 1.0 of an informational document containing recommended
+conventions and guidelines for producing portable BPF program binaries.
+
+Registers and calling convention
+================================
+
+BPF has 10 general purpose registers and a read-only frame pointer register,
+all of which are 64-bits wide.
+
+The BPF calling convention is defined as:
+
+* R0: return value from function calls, and exit value for BPF programs
+* R1 - R5: arguments for function calls
+* R6 - R9: callee saved registers that function calls will preserve
+* R10: read-only frame pointer to access stack
+
+R0 - R5 are scratch registers and BPF programs needs to spill/fill them if
+necessary across calls.
+
+The BPF program needs to store the return value into register R0 before doing an
+``EXIT``.
diff --git a/Documentation/bpf/standardization/index.rst b/Documentation/bpf/standardization/index.rst
new file mode 100644
index 000000000000..a50c3baf6345
--- /dev/null
+++ b/Documentation/bpf/standardization/index.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
+
+===================
+BPF Standardization
+===================
+
+This directory contains documents that are being iterated on as part of the BPF
+standardization effort with the IETF. See the `IETF BPF Working Group`_ page
+for the working group charter, documents, and more.
+
+.. toctree::
+ :maxdepth: 1
+
+ instruction-set
+ abi
+
+.. Links:
+.. _IETF BPF Working Group: https://datatracker.ietf.org/wg/bpf/about/
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
new file mode 100644
index 000000000000..39c74611752b
--- /dev/null
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -0,0 +1,790 @@
+.. contents::
+.. sectnum::
+
+======================================
+BPF Instruction Set Architecture (ISA)
+======================================
+
+eBPF, also commonly
+referred to as BPF, is a technology with origins in the Linux kernel
+that can run untrusted programs in a privileged context such as an
+operating system kernel. This document specifies the BPF instruction
+set architecture (ISA).
+
+As a historical note, BPF originally stood for Berkeley Packet Filter,
+but now that it can do so much more than packet filtering, the acronym
+no longer makes sense. BPF is now considered a standalone term that
+does not stand for anything. The original BPF is sometimes referred to
+as cBPF (classic BPF) to distinguish it from the now widely deployed
+eBPF (extended BPF).
+
+Documentation conventions
+=========================
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+"OPTIONAL" in this document are to be interpreted as described in
+BCP 14 `<https://www.rfc-editor.org/info/rfc2119>`_
+`<https://www.rfc-editor.org/info/rfc8174>`_
+when, and only when, they appear in all capitals, as shown here.
+
+For brevity and consistency, this document refers to families
+of types using a shorthand syntax and refers to several expository,
+mnemonic functions when describing the semantics of instructions.
+The range of valid values for those types and the semantics of those
+functions are defined in the following subsections.
+
+Types
+-----
+This document refers to integer types with the notation `SN` to specify
+a type's signedness (`S`) and bit width (`N`), respectively.
+
+.. table:: Meaning of signedness notation
+
+ ==== =========
+ S Meaning
+ ==== =========
+ u unsigned
+ s signed
+ ==== =========
+
+.. table:: Meaning of bit-width notation
+
+ ===== =========
+ N Bit width
+ ===== =========
+ 8 8 bits
+ 16 16 bits
+ 32 32 bits
+ 64 64 bits
+ 128 128 bits
+ ===== =========
+
+For example, `u32` is a type whose valid values are all the 32-bit unsigned
+numbers and `s16` is a type whose valid values are all the 16-bit signed
+numbers.
+
+Functions
+---------
+
+The following byteswap functions are direction-agnostic. That is,
+the same function is used for conversion in either direction discussed
+below.
+
+* be16: Takes an unsigned 16-bit number and converts it between
+ host byte order and big-endian
+ (`IEN137 <https://www.rfc-editor.org/ien/ien137.txt>`_) byte order.
+* be32: Takes an unsigned 32-bit number and converts it between
+ host byte order and big-endian byte order.
+* be64: Takes an unsigned 64-bit number and converts it between
+ host byte order and big-endian byte order.
+* bswap16: Takes an unsigned 16-bit number in either big- or little-endian
+ format and returns the equivalent number with the same bit width but
+ opposite endianness.
+* bswap32: Takes an unsigned 32-bit number in either big- or little-endian
+ format and returns the equivalent number with the same bit width but
+ opposite endianness.
+* bswap64: Takes an unsigned 64-bit number in either big- or little-endian
+ format and returns the equivalent number with the same bit width but
+ opposite endianness.
+* le16: Takes an unsigned 16-bit number and converts it between
+ host byte order and little-endian byte order.
+* le32: Takes an unsigned 32-bit number and converts it between
+ host byte order and little-endian byte order.
+* le64: Takes an unsigned 64-bit number and converts it between
+ host byte order and little-endian byte order.
+
+Definitions
+-----------
+
+.. glossary::
+
+ Sign Extend
+ To `sign extend an` ``X`` `-bit number, A, to a` ``Y`` `-bit number, B ,` means to
+
+ #. Copy all ``X`` bits from `A` to the lower ``X`` bits of `B`.
+ #. Set the value of the remaining ``Y`` - ``X`` bits of `B` to the value of
+ the most-significant bit of `A`.
+
+.. admonition:: Example
+
+ Sign extend an 8-bit number ``A`` to a 16-bit number ``B`` on a big-endian platform:
+ ::
+
+ A: 10000110
+ B: 11111111 10000110
+
+Conformance groups
+------------------
+
+An implementation does not need to support all instructions specified in this
+document (e.g., deprecated instructions). Instead, a number of conformance
+groups are specified. An implementation MUST support the base32 conformance
+group and MAY support additional conformance groups, where supporting a
+conformance group means it MUST support all instructions in that conformance
+group.
+
+The use of named conformance groups enables interoperability between a runtime
+that executes instructions, and tools such as compilers that generate
+instructions for the runtime. Thus, capability discovery in terms of
+conformance groups might be done manually by users or automatically by tools.
+
+Each conformance group has a short ASCII label (e.g., "base32") that
+corresponds to a set of instructions that are mandatory. That is, each
+instruction has one or more conformance groups of which it is a member.
+
+This document defines the following conformance groups:
+
+* base32: includes all instructions defined in this
+ specification unless otherwise noted.
+* base64: includes base32, plus instructions explicitly noted
+ as being in the base64 conformance group.
+* atomic32: includes 32-bit atomic operation instructions (see `Atomic operations`_).
+* atomic64: includes atomic32, plus 64-bit atomic operation instructions.
+* divmul32: includes 32-bit division, multiplication, and modulo instructions.
+* divmul64: includes divmul32, plus 64-bit division, multiplication,
+ and modulo instructions.
+* packet: deprecated packet access instructions.
+
+Instruction encoding
+====================
+
+BPF has two instruction encodings:
+
+* the basic instruction encoding, which uses 64 bits to encode an instruction
+* the wide instruction encoding, which appends a second 64 bits
+ after the basic instruction for a total of 128 bits.
+
+Basic instruction encoding
+--------------------------
+
+A basic instruction is encoded as follows::
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | opcode | regs | offset |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | imm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+**opcode**
+ operation to perform, encoded as follows::
+
+ +-+-+-+-+-+-+-+-+
+ |specific |class|
+ +-+-+-+-+-+-+-+-+
+
+ **specific**
+ The format of these bits varies by instruction class
+
+ **class**
+ The instruction class (see `Instruction classes`_)
+
+**regs**
+ The source and destination register numbers, encoded as follows
+ on a little-endian host::
+
+ +-+-+-+-+-+-+-+-+
+ |src_reg|dst_reg|
+ +-+-+-+-+-+-+-+-+
+
+ and as follows on a big-endian host::
+
+ +-+-+-+-+-+-+-+-+
+ |dst_reg|src_reg|
+ +-+-+-+-+-+-+-+-+
+
+ **src_reg**
+ the source register number (0-10), except where otherwise specified
+ (`64-bit immediate instructions`_ reuse this field for other purposes)
+
+ **dst_reg**
+ destination register number (0-10), unless otherwise specified
+ (future instructions might reuse this field for other purposes)
+
+**offset**
+ signed integer offset used with pointer arithmetic, except where
+ otherwise specified (some arithmetic instructions reuse this field
+ for other purposes)
+
+**imm**
+ signed integer immediate value
+
+Note that the contents of multi-byte fields ('offset' and 'imm') are
+stored using big-endian byte ordering on big-endian hosts and
+little-endian byte ordering on little-endian hosts.
+
+For example::
+
+ opcode offset imm assembly
+ src_reg dst_reg
+ 07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little
+ dst_reg src_reg
+ 07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big
+
+Note that most instructions do not use all of the fields.
+Unused fields SHALL be cleared to zero.
+
+Wide instruction encoding
+--------------------------
+
+Some instructions are defined to use the wide instruction encoding,
+which uses two 32-bit immediate values. The 64 bits following
+the basic instruction format contain a pseudo instruction
+with 'opcode', 'dst_reg', 'src_reg', and 'offset' all set to zero.
+
+This is depicted in the following figure::
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | opcode | regs | offset |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | imm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | next_imm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+**opcode**
+ operation to perform, encoded as explained above
+
+**regs**
+ The source and destination register numbers (unless otherwise
+ specified), encoded as explained above
+
+**offset**
+ signed integer offset used with pointer arithmetic, unless
+ otherwise specified
+
+**imm**
+ signed integer immediate value
+
+**reserved**
+ unused, set to zero
+
+**next_imm**
+ second signed integer immediate value
+
+Instruction classes
+-------------------
+
+The three least significant bits of the 'opcode' field store the instruction class:
+
+.. table:: Instruction class
+
+ ===== ===== =============================== ===================================
+ class value description reference
+ ===== ===== =============================== ===================================
+ LD 0x0 non-standard load operations `Load and store instructions`_
+ LDX 0x1 load into register operations `Load and store instructions`_
+ ST 0x2 store from immediate operations `Load and store instructions`_
+ STX 0x3 store from register operations `Load and store instructions`_
+ ALU 0x4 32-bit arithmetic operations `Arithmetic and jump instructions`_
+ JMP 0x5 64-bit jump operations `Arithmetic and jump instructions`_
+ JMP32 0x6 32-bit jump operations `Arithmetic and jump instructions`_
+ ALU64 0x7 64-bit arithmetic operations `Arithmetic and jump instructions`_
+ ===== ===== =============================== ===================================
+
+Arithmetic and jump instructions
+================================
+
+For arithmetic and jump instructions (``ALU``, ``ALU64``, ``JMP`` and
+``JMP32``), the 8-bit 'opcode' field is divided into three parts::
+
+ +-+-+-+-+-+-+-+-+
+ | code |s|class|
+ +-+-+-+-+-+-+-+-+
+
+**code**
+ the operation code, whose meaning varies by instruction class
+
+**s (source)**
+ the source operand location, which unless otherwise specified is one of:
+
+ .. table:: Source operand location
+
+ ====== ===== ==============================================
+ source value description
+ ====== ===== ==============================================
+ K 0 use 32-bit 'imm' value as source operand
+ X 1 use 'src_reg' register value as source operand
+ ====== ===== ==============================================
+
+**instruction class**
+ the instruction class (see `Instruction classes`_)
+
+Arithmetic instructions
+-----------------------
+
+``ALU`` uses 32-bit wide operands while ``ALU64`` uses 64-bit wide operands for
+otherwise identical operations. ``ALU64`` instructions belong to the
+base64 conformance group unless noted otherwise.
+The 'code' field encodes the operation as below, where 'src' refers to the
+the source operand and 'dst' refers to the value of the destination
+register.
+
+.. table:: Arithmetic instructions
+
+ ===== ===== ======= ===================================================================================
+ name code offset description
+ ===== ===== ======= ===================================================================================
+ ADD 0x0 0 dst += src
+ SUB 0x1 0 dst -= src
+ MUL 0x2 0 dst \*= src
+ DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0
+ SDIV 0x3 1 dst = (src == 0) ? 0 : ((src == -1 && dst == LLONG_MIN) ? LLONG_MIN : (dst s/ src))
+ OR 0x4 0 dst \|= src
+ AND 0x5 0 dst &= src
+ LSH 0x6 0 dst <<= (src & mask)
+ RSH 0x7 0 dst >>= (src & mask)
+ NEG 0x8 0 dst = -dst
+ MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst
+ SMOD 0x9 1 dst = (src == 0) ? dst : ((src == -1 && dst == LLONG_MIN) ? 0: (dst s% src))
+ XOR 0xa 0 dst ^= src
+ MOV 0xb 0 dst = src
+ MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src
+ ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask)
+ END 0xd 0 byte swap operations (see `Byte swap instructions`_ below)
+ ===== ===== ======= ===================================================================================
+
+Underflow and overflow are allowed during arithmetic operations, meaning
+the 64-bit or 32-bit value will wrap. If BPF program execution would
+result in division by zero, the destination register is instead set to zero.
+Otherwise, for ``ALU64``, if execution would result in ``LLONG_MIN``
+divided by -1, the destination register is instead set to ``LLONG_MIN``. For
+``ALU``, if execution would result in ``INT_MIN`` divided by -1, the
+destination register is instead set to ``INT_MIN``.
+
+If execution would result in modulo by zero, for ``ALU64`` the value of
+the destination register is unchanged whereas for ``ALU`` the upper
+32 bits of the destination register are zeroed. Otherwise, for ``ALU64``,
+if execution would resuslt in ``LLONG_MIN`` modulo -1, the destination
+register is instead set to 0. For ``ALU``, if execution would result in
+``INT_MIN`` modulo -1, the destination register is instead set to 0.
+
+``{ADD, X, ALU}``, where 'code' = ``ADD``, 'source' = ``X``, and 'class' = ``ALU``, means::
+
+ dst = (u32) ((u32) dst + (u32) src)
+
+where '(u32)' indicates that the upper 32 bits are zeroed.
+
+``{ADD, X, ALU64}`` means::
+
+ dst = dst + src
+
+``{XOR, K, ALU}`` means::
+
+ dst = (u32) dst ^ (u32) imm
+
+``{XOR, K, ALU64}`` means::
+
+ dst = dst ^ imm
+
+Note that most arithmetic instructions have 'offset' set to 0. Only three instructions
+(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'.
+
+Division, multiplication, and modulo operations for ``ALU`` are part
+of the "divmul32" conformance group, and division, multiplication, and
+modulo operations for ``ALU64`` are part of the "divmul64" conformance
+group.
+The division and modulo operations support both unsigned and signed flavors.
+
+For unsigned operations (``DIV`` and ``MOD``), for ``ALU``,
+'imm' is interpreted as a 32-bit unsigned value. For ``ALU64``,
+'imm' is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then
+interpreted as a 64-bit unsigned value.
+
+For signed operations (``SDIV`` and ``SMOD``), for ``ALU``,
+'imm' is interpreted as a 32-bit signed value. For ``ALU64``, 'imm'
+is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then
+interpreted as a 64-bit signed value.
+
+Note that there are varying definitions of the signed modulo operation
+when the dividend or divisor are negative, where implementations often
+vary by language such that Python, Ruby, etc. differ from C, Go, Java,
+etc. This specification requires that signed modulo MUST use truncated division
+(where -13 % 3 == -1) as implemented in C, Go, etc.::
+
+ a % n = a - n * trunc(a / n)
+
+The ``MOVSX`` instruction does a move operation with sign extension.
+``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into
+32-bit operands, and zeroes the remaining upper 32 bits.
+``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
+operands into 64-bit operands. Unlike other arithmetic instructions,
+``MOVSX`` is only defined for register source operands (``X``).
+
+``{MOV, K, ALU64}`` means::
+
+ dst = (s64)imm
+
+``{MOV, X, ALU}`` means::
+
+ dst = (u32)src
+
+``{MOVSX, X, ALU}`` with 'offset' 8 means::
+
+ dst = (u32)(s32)(s8)src
+
+
+The ``NEG`` instruction is only defined when the source bit is clear
+(``K``).
+
+Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31)
+for 32-bit operations.
+
+Byte swap instructions
+----------------------
+
+The byte swap instructions use instruction classes of ``ALU`` and ``ALU64``
+and a 4-bit 'code' field of ``END``.
+
+The byte swap instructions operate on the destination register
+only and do not use a separate source register or immediate value.
+
+For ``ALU``, the 1-bit source operand field in the opcode is used to
+select what byte order the operation converts from or to. For
+``ALU64``, the 1-bit source operand field in the opcode is reserved
+and MUST be set to 0.
+
+.. table:: Byte swap instructions
+
+ ===== ======== ===== =================================================
+ class source value description
+ ===== ======== ===== =================================================
+ ALU LE 0 convert between host byte order and little endian
+ ALU BE 1 convert between host byte order and big endian
+ ALU64 Reserved 0 do byte swap unconditionally
+ ===== ======== ===== =================================================
+
+The 'imm' field encodes the width of the swap operations. The following widths
+are supported: 16, 32 and 64. Width 64 operations belong to the base64
+conformance group and other swap operations belong to the base32
+conformance group.
+
+Examples:
+
+``{END, LE, ALU}`` with 'imm' = 16/32/64 means::
+
+ dst = le16(dst)
+ dst = le32(dst)
+ dst = le64(dst)
+
+``{END, BE, ALU}`` with 'imm' = 16/32/64 means::
+
+ dst = be16(dst)
+ dst = be32(dst)
+ dst = be64(dst)
+
+``{END, TO, ALU64}`` with 'imm' = 16/32/64 means::
+
+ dst = bswap16(dst)
+ dst = bswap32(dst)
+ dst = bswap64(dst)
+
+Jump instructions
+-----------------
+
+``JMP32`` uses 32-bit wide operands and indicates the base32
+conformance group, while ``JMP`` uses 64-bit wide operands for
+otherwise identical operations, and indicates the base64 conformance
+group unless otherwise specified.
+The 'code' field encodes the operation as below:
+
+.. table:: Jump instructions
+
+ ======== ===== ======= ================================= ===================================================
+ code value src_reg description notes
+ ======== ===== ======= ================================= ===================================================
+ JA 0x0 0x0 PC += offset {JA, K, JMP} only
+ JA 0x0 0x0 PC += imm {JA, K, JMP32} only
+ JEQ 0x1 any PC += offset if dst == src
+ JGT 0x2 any PC += offset if dst > src unsigned
+ JGE 0x3 any PC += offset if dst >= src unsigned
+ JSET 0x4 any PC += offset if dst & src
+ JNE 0x5 any PC += offset if dst != src
+ JSGT 0x6 any PC += offset if dst > src signed
+ JSGE 0x7 any PC += offset if dst >= src signed
+ CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_
+ CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
+ CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
+ EXIT 0x9 0x0 return {CALL, K, JMP} only
+ JLT 0xa any PC += offset if dst < src unsigned
+ JLE 0xb any PC += offset if dst <= src unsigned
+ JSLT 0xc any PC += offset if dst < src signed
+ JSLE 0xd any PC += offset if dst <= src signed
+ ======== ===== ======= ================================= ===================================================
+
+where 'PC' denotes the program counter, and the offset to increment by
+is in units of 64-bit instructions relative to the instruction following
+the jump instruction. Thus 'PC += 1' skips execution of the next
+instruction if it's a basic instruction or results in undefined behavior
+if the next instruction is a 128-bit wide instruction.
+
+Example:
+
+``{JSGE, X, JMP32}`` means::
+
+ if (s32)dst s>= (s32)src goto +offset
+
+where 's>=' indicates a signed '>=' comparison.
+
+``{JLE, K, JMP}`` means::
+
+ if dst <= (u64)(s64)imm goto +offset
+
+``{JA, K, JMP32}`` means::
+
+ gotol +imm
+
+where 'imm' means the branch offset comes from the 'imm' field.
+
+Note that there are two flavors of ``JA`` instructions. The
+``JMP`` class permits a 16-bit jump offset specified by the 'offset'
+field, whereas the ``JMP32`` class permits a 32-bit jump offset
+specified by the 'imm' field. A > 16-bit conditional jump may be
+converted to a < 16-bit conditional jump plus a 32-bit unconditional
+jump.
+
+All ``CALL`` and ``JA`` instructions belong to the
+base32 conformance group.
+
+Helper functions
+~~~~~~~~~~~~~~~~
+
+Helper functions are a concept whereby BPF programs can call into a
+set of function calls exposed by the underlying platform.
+
+Historically, each helper function was identified by a static ID
+encoded in the 'imm' field. Further documentation of helper functions
+is outside the scope of this document and standardization is left for
+future work, but use is widely deployed and more information can be
+found in platform-specific documentation (e.g., Linux kernel documentation).
+
+Platforms that support the BPF Type Format (BTF) support identifying
+a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
+identifies the helper name and type. Further documentation of BTF
+is outside the scope of this document and standardization is left for
+future work, but use is widely deployed and more information can be
+found in platform-specific documentation (e.g., Linux kernel documentation).
+
+Program-local functions
+~~~~~~~~~~~~~~~~~~~~~~~
+Program-local functions are functions exposed by the same BPF program as the
+caller, and are referenced by offset from the instruction following the call
+instruction, similar to ``JA``. The offset is encoded in the 'imm' field of
+the call instruction. An ``EXIT`` within the program-local function will
+return to the caller.
+
+Load and store instructions
+===========================
+
+For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
+8-bit 'opcode' field is divided as follows::
+
+ +-+-+-+-+-+-+-+-+
+ |mode |sz |class|
+ +-+-+-+-+-+-+-+-+
+
+**mode**
+ The mode modifier is one of:
+
+ .. table:: Mode modifier
+
+ ============= ===== ==================================== =============
+ mode modifier value description reference
+ ============= ===== ==================================== =============
+ IMM 0 64-bit immediate instructions `64-bit immediate instructions`_
+ ABS 1 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_
+ IND 2 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_
+ MEM 3 regular load and store operations `Regular load and store operations`_
+ MEMSX 4 sign-extension load operations `Sign-extension load operations`_
+ ATOMIC 6 atomic operations `Atomic operations`_
+ ============= ===== ==================================== =============
+
+**sz (size)**
+ The size modifier is one of:
+
+ .. table:: Size modifier
+
+ ==== ===== =====================
+ size value description
+ ==== ===== =====================
+ W 0 word (4 bytes)
+ H 1 half word (2 bytes)
+ B 2 byte
+ DW 3 double word (8 bytes)
+ ==== ===== =====================
+
+ Instructions using ``DW`` belong to the base64 conformance group.
+
+**class**
+ The instruction class (see `Instruction classes`_)
+
+Regular load and store operations
+---------------------------------
+
+The ``MEM`` mode modifier is used to encode regular load and store
+instructions that transfer data between a register and memory.
+
+``{MEM, <size>, STX}`` means::
+
+ *(size *) (dst + offset) = src
+
+``{MEM, <size>, ST}`` means::
+
+ *(size *) (dst + offset) = imm
+
+``{MEM, <size>, LDX}`` means::
+
+ dst = *(unsigned size *) (src + offset)
+
+Where '<size>' is one of: ``B``, ``H``, ``W``, or ``DW``, and
+'unsigned size' is one of: u8, u16, u32, or u64.
+
+Sign-extension load operations
+------------------------------
+
+The ``MEMSX`` mode modifier is used to encode :term:`sign-extension<Sign Extend>` load
+instructions that transfer data between a register and memory.
+
+``{MEMSX, <size>, LDX}`` means::
+
+ dst = *(signed size *) (src + offset)
+
+Where '<size>' is one of: ``B``, ``H``, or ``W``, and
+'signed size' is one of: s8, s16, or s32.
+
+Atomic operations
+-----------------
+
+Atomic operations are operations that operate on memory and can not be
+interrupted or corrupted by other access to the same memory region
+by other BPF programs or means outside of this specification.
+
+All atomic operations supported by BPF are encoded as store operations
+that use the ``ATOMIC`` mode modifier as follows:
+
+* ``{ATOMIC, W, STX}`` for 32-bit operations, which are
+ part of the "atomic32" conformance group.
+* ``{ATOMIC, DW, STX}`` for 64-bit operations, which are
+ part of the "atomic64" conformance group.
+* 8-bit and 16-bit wide atomic operations are not supported.
+
+The 'imm' field is used to encode the actual atomic operation.
+Simple atomic operation use a subset of the values defined to encode
+arithmetic operations in the 'imm' field to encode the atomic operation:
+
+.. table:: Simple atomic operations
+
+ ======== ===== ===========
+ imm value description
+ ======== ===== ===========
+ ADD 0x00 atomic add
+ OR 0x40 atomic or
+ AND 0x50 atomic and
+ XOR 0xa0 atomic xor
+ ======== ===== ===========
+
+
+``{ATOMIC, W, STX}`` with 'imm' = ADD means::
+
+ *(u32 *)(dst + offset) += src
+
+``{ATOMIC, DW, STX}`` with 'imm' = ADD means::
+
+ *(u64 *)(dst + offset) += src
+
+In addition to the simple atomic operations, there also is a modifier and
+two complex atomic operations:
+
+.. table:: Complex atomic operations
+
+ =========== ================ ===========================
+ imm value description
+ =========== ================ ===========================
+ FETCH 0x01 modifier: return old value
+ XCHG 0xe0 | FETCH atomic exchange
+ CMPXCHG 0xf0 | FETCH atomic compare and exchange
+ =========== ================ ===========================
+
+The ``FETCH`` modifier is optional for simple atomic operations, and
+always set for the complex atomic operations. If the ``FETCH`` flag
+is set, then the operation also overwrites ``src`` with the value that
+was in memory before it was modified.
+
+The ``XCHG`` operation atomically exchanges ``src`` with the value
+addressed by ``dst + offset``.
+
+The ``CMPXCHG`` operation atomically compares the value addressed by
+``dst + offset`` with ``R0``. If they match, the value addressed by
+``dst + offset`` is replaced with ``src``. In either case, the
+value that was at ``dst + offset`` before the operation is zero-extended
+and loaded back to ``R0``.
+
+64-bit immediate instructions
+-----------------------------
+
+Instructions with the ``IMM`` 'mode' modifier use the wide instruction
+encoding defined in `Instruction encoding`_, and use the 'src_reg' field of the
+basic instruction to hold an opcode subtype.
+
+The following table defines a set of ``{IMM, DW, LD}`` instructions
+with opcode subtypes in the 'src_reg' field, using new terms such as "map"
+defined further below:
+
+.. table:: 64-bit immediate instructions
+
+ ======= ========================================= =========== ==============
+ src_reg pseudocode imm type dst type
+ ======= ========================================= =========== ==============
+ 0x0 dst = (next_imm << 32) | imm integer integer
+ 0x1 dst = map_by_fd(imm) map fd map
+ 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address
+ 0x3 dst = var_addr(imm) variable id data address
+ 0x4 dst = code_addr(imm) integer code address
+ 0x5 dst = map_by_idx(imm) map index map
+ 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address
+ ======= ========================================= =========== ==============
+
+where
+
+* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_)
+* map_by_idx(imm) means to convert a 32-bit index into an address of a map
+* map_val(map) gets the address of the first value in a given map
+* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id
+* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions
+* the 'imm type' can be used by disassemblers for display
+* the 'dst type' can be used for verification and JIT compilation purposes
+
+Maps
+~~~~
+
+Maps are shared memory regions accessible by BPF programs on some platforms.
+A map can have various semantics as defined in a separate document, and may or
+may not have a single contiguous memory region, but the 'map_val(map)' is
+currently only defined for maps that do have a single contiguous memory region.
+
+Each map can have a file descriptor (fd) if supported by the platform, where
+'map_by_fd(imm)' means to get the map with the specified file descriptor. Each
+BPF program can also be defined to use a set of maps associated with the
+program at load time, and 'map_by_idx(imm)' means to get the map with the given
+index in the set associated with the BPF program containing the instruction.
+
+Platform Variables
+~~~~~~~~~~~~~~~~~~
+
+Platform variables are memory regions, identified by integer ids, exposed by
+the runtime and accessible by BPF programs on some platforms. The
+'var_addr(imm)' operation means to get the address of the memory region
+identified by the given id.
+
+Legacy BPF Packet access instructions
+-------------------------------------
+
+BPF previously introduced special instructions for access to packet data that were
+carried over from classic BPF. These instructions used an instruction
+class of ``LD``, a size modifier of ``W``, ``H``, or ``B``, and a
+mode modifier of ``ABS`` or ``IND``. The 'dst_reg' and 'offset' fields were
+set to zero, and 'src_reg' was set to zero for ``ABS``. However, these
+instructions are deprecated and SHOULD no longer be used. All legacy packet
+access instructions belong to the "packet" conformance group.
diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst
index d4326caf01f9..510d15bc697b 100644
--- a/Documentation/bpf/verifier.rst
+++ b/Documentation/bpf/verifier.rst
@@ -192,7 +192,7 @@ checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs.
As well as range-checking, the tracked information is also used for enforcing
alignment of pointer accesses. For instance, on most systems the packet pointer
is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump
-over the Ethernet header, then reads IHL and addes (IHL * 4), the resulting
+over the Ethernet header, then reads IHL and adds (IHL * 4), the resulting
pointer will have a variable offset known to be 4n+2 for some n, so adding the 2
bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through
that pointer are safe.
@@ -316,6 +316,37 @@ Pruning considers not only the registers but also the stack (and any spilled
registers it may hold). They must all be safe for the branch to be pruned.
This is implemented in states_equal().
+Some technical details about state pruning implementation could be found below.
+
+Register liveness tracking
+--------------------------
+
+In order to make state pruning effective, liveness state is tracked for each
+register and stack slot. The basic idea is to track which registers and stack
+slots are actually used during subseqeuent execution of the program, until
+program exit is reached. Registers and stack slots that were never used could be
+removed from the cached state thus making more states equivalent to a cached
+state. This could be illustrated by the following program::
+
+ 0: call bpf_get_prandom_u32()
+ 1: r1 = 0
+ 2: if r0 == 0 goto +1
+ 3: r0 = 1
+ --- checkpoint ---
+ 4: r0 = r1
+ 5: exit
+
+Suppose that a state cache entry is created at instruction #4 (such entries are
+also called "checkpoints" in the text below). The verifier could reach the
+instruction with one of two possible register states:
+
+* r0 = 1, r1 = 0
+* r0 = 0, r1 = 0
+
+However, only the value of register ``r1`` is important to successfully finish
+verification. The goal of the liveness tracking algorithm is to spot this fact
+and figure out that both states are actually equivalent.
+
Understanding eBPF verifier messages
====================================
diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst
index 7964fe134277..b97a4e9b9bd3 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -217,7 +217,7 @@ current *struct* is::
int (*media_changed)(struct cdrom_device_info *, int);
int (*tray_move)(struct cdrom_device_info *, int);
int (*lock_door)(struct cdrom_device_info *, int);
- int (*select_speed)(struct cdrom_device_info *, int);
+ int (*select_speed)(struct cdrom_device_info *, unsigned long);
int (*get_last_session) (struct cdrom_device_info *,
struct cdrom_multisession *);
int (*get_mcn)(struct cdrom_device_info *, struct cdrom_mcn *);
@@ -273,7 +273,6 @@ The drive-specific, minor-like information that is registered with
__u8 media_written; /* dirty flag, DVD+RW bookkeeping */
unsigned short mmc3_profile; /* current MMC3 profile */
int for_data; /* unknown:TBD */
- int (*exit)(struct cdrom_device_info *);/* unknown:TBD */
int mrw_mode_page; /* which MRW mode page is in use */
};
@@ -396,7 +395,7 @@ action need be taken, and the return value should be 0.
::
- int select_speed(struct cdrom_device_info *cdi, int speed)
+ int select_speed(struct cdrom_device_info *cdi, unsigned long speed)
Some CD-ROM drives are capable of changing their head-speed. There
are several reasons for changing the speed of a CD-ROM drive. Badly
diff --git a/Documentation/cdrom/index.rst b/Documentation/cdrom/index.rst
index e87a8785bc1a..3ac4f716612f 100644
--- a/Documentation/cdrom/index.rst
+++ b/Documentation/cdrom/index.rst
@@ -1,14 +1,13 @@
.. SPDX-License-Identifier: GPL-2.0
-=====
-cdrom
-=====
+======
+CD-ROM
+======
.. toctree::
:maxdepth: 1
cdrom-standard
- packet-writing
.. only:: subproject and html
diff --git a/Documentation/cdrom/packet-writing.rst b/Documentation/cdrom/packet-writing.rst
deleted file mode 100644
index 43db58c50d29..000000000000
--- a/Documentation/cdrom/packet-writing.rst
+++ /dev/null
@@ -1,139 +0,0 @@
-==============
-Packet writing
-==============
-
-Getting started quick
----------------------
-
-- Select packet support in the block device section and UDF support in
- the file system section.
-
-- Compile and install kernel and modules, reboot.
-
-- You need the udftools package (pktsetup, mkudffs, cdrwtool).
- Download from https://github.com/pali/udftools
-
-- Grab a new CD-RW disc and format it (assuming CD-RW is hdc, substitute
- as appropriate)::
-
- # cdrwtool -d /dev/hdc -q
-
-- Setup your writer::
-
- # pktsetup dev_name /dev/hdc
-
-- Now you can mount /dev/pktcdvd/dev_name and copy files to it. Enjoy::
-
- # mount /dev/pktcdvd/dev_name /cdrom -t udf -o rw,noatime
-
-
-Packet writing for DVD-RW media
--------------------------------
-
-DVD-RW discs can be written to much like CD-RW discs if they are in
-the so called "restricted overwrite" mode. To put a disc in restricted
-overwrite mode, run::
-
- # dvd+rw-format /dev/hdc
-
-You can then use the disc the same way you would use a CD-RW disc::
-
- # pktsetup dev_name /dev/hdc
- # mount /dev/pktcdvd/dev_name /cdrom -t udf -o rw,noatime
-
-
-Packet writing for DVD+RW media
--------------------------------
-
-According to the DVD+RW specification, a drive supporting DVD+RW discs
-shall implement "true random writes with 2KB granularity", which means
-that it should be possible to put any filesystem with a block size >=
-2KB on such a disc. For example, it should be possible to do::
-
- # dvd+rw-format /dev/hdc (only needed if the disc has never
- been formatted)
- # mkudffs /dev/hdc
- # mount /dev/hdc /cdrom -t udf -o rw,noatime
-
-However, some drives don't follow the specification and expect the
-host to perform aligned writes at 32KB boundaries. Other drives do
-follow the specification, but suffer bad performance problems if the
-writes are not 32KB aligned.
-
-Both problems can be solved by using the pktcdvd driver, which always
-generates aligned writes::
-
- # dvd+rw-format /dev/hdc
- # pktsetup dev_name /dev/hdc
- # mkudffs /dev/pktcdvd/dev_name
- # mount /dev/pktcdvd/dev_name /cdrom -t udf -o rw,noatime
-
-
-Packet writing for DVD-RAM media
---------------------------------
-
-DVD-RAM discs are random writable, so using the pktcdvd driver is not
-necessary. However, using the pktcdvd driver can improve performance
-in the same way it does for DVD+RW media.
-
-
-Notes
------
-
-- CD-RW media can usually not be overwritten more than about 1000
- times, so to avoid unnecessary wear on the media, you should always
- use the noatime mount option.
-
-- Defect management (ie automatic remapping of bad sectors) has not
- been implemented yet, so you are likely to get at least some
- filesystem corruption if the disc wears out.
-
-- Since the pktcdvd driver makes the disc appear as a regular block
- device with a 2KB block size, you can put any filesystem you like on
- the disc. For example, run::
-
- # /sbin/mke2fs /dev/pktcdvd/dev_name
-
- to create an ext2 filesystem on the disc.
-
-
-Using the pktcdvd sysfs interface
----------------------------------
-
-Since Linux 2.6.20, the pktcdvd module has a sysfs interface
-and can be controlled by it. For example the "pktcdvd" tool uses
-this interface. (see http://tom.ist-im-web.de/linux/software/pktcdvd )
-
-"pktcdvd" works similar to "pktsetup", e.g.::
-
- # pktcdvd -a dev_name /dev/hdc
- # mkudffs /dev/pktcdvd/dev_name
- # mount -t udf -o rw,noatime /dev/pktcdvd/dev_name /dvdram
- # cp files /dvdram
- # umount /dvdram
- # pktcdvd -r dev_name
-
-
-For a description of the sysfs interface look into the file:
-
- Documentation/ABI/testing/sysfs-class-pktcdvd
-
-
-Using the pktcdvd debugfs interface
------------------------------------
-
-To read pktcdvd device infos in human readable form, do::
-
- # cat /sys/kernel/debug/pktcdvd/pktcdvd[0-7]/info
-
-For a description of the debugfs interface look into the file:
-
- Documentation/ABI/testing/debugfs-pktcdvd
-
-
-
-Links
------
-
-See http://fy.chalmers.se/~appro/linux/DVD+RW/ for more information
-about DVD writing.
diff --git a/Documentation/conf.py b/Documentation/conf.py
index b50c85083149..1ea2ae5c6276 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -1,25 +1,134 @@
-# -*- coding: utf-8 -*-
-#
-# The Linux Kernel documentation build configuration file, created by
-# sphinx-quickstart on Fri Feb 12 13:51:46 2016.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
+# SPDX-License-Identifier: GPL-2.0-only
+# pylint: disable=C0103,C0209
+
+"""
+The Linux Kernel documentation build configuration file.
+"""
-import sys
import os
-import sphinx
import shutil
+import sys
+
+from textwrap import dedent
+
+import sphinx
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.abspath("sphinx"))
+
+# Minimal supported version
+needs_sphinx = "3.4.3"
+
+# Get Sphinx version
+major, minor, patch = sphinx.version_info[:3] # pylint: disable=I1101
+
+# Include_patterns were added on Sphinx 5.1
+if (major < 5) or (major == 5 and minor < 1):
+ has_include_patterns = False
+else:
+ has_include_patterns = True
+ # Include patterns that don't contain directory names, in glob format
+ include_patterns = ["**.rst"]
+
+# Location of Documentation/ directory
+doctree = os.path.abspath(".")
+
+# Exclude of patterns that don't contain directory names, in glob format.
+exclude_patterns = []
+
+# List of patterns that contain directory names in glob format.
+dyn_include_patterns = []
+dyn_exclude_patterns = ["output"]
+
+# Currently, only netlink/specs has a parser for yaml.
+# Prefer using include patterns if available, as it is faster
+if has_include_patterns:
+ dyn_include_patterns.append("netlink/specs/*.yaml")
+else:
+ dyn_exclude_patterns.append("netlink/*.yaml")
+ dyn_exclude_patterns.append("devicetree/bindings/**.yaml")
+ dyn_exclude_patterns.append("core-api/kho/bindings/**.yaml")
+
+# Properly handle directory patterns and LaTeX docs
+# -------------------------------------------------
+
+def config_init(app, config):
+ """
+ Initialize path-dependent variabled
+
+ On Sphinx, all directories are relative to what it is passed as
+ SOURCEDIR parameter for sphinx-build. Due to that, all patterns
+ that have directory names on it need to be dynamically set, after
+ converting them to a relative patch.
+
+ As Sphinx doesn't include any patterns outside SOURCEDIR, we should
+ exclude relative patterns that start with "../".
+ """
+
+ # setup include_patterns dynamically
+ if has_include_patterns:
+ for p in dyn_include_patterns:
+ full = os.path.join(doctree, p)
+
+ rel_path = os.path.relpath(full, start=app.srcdir)
+ if rel_path.startswith("../"):
+ continue
+
+ config.include_patterns.append(rel_path)
+
+ # setup exclude_patterns dynamically
+ for p in dyn_exclude_patterns:
+ full = os.path.join(doctree, p)
+
+ rel_path = os.path.relpath(full, start=app.srcdir)
+ if rel_path.startswith("../"):
+ continue
+
+ config.exclude_patterns.append(rel_path)
+
+ # LaTeX and PDF output require a list of documents with are dependent
+ # of the app.srcdir. Add them here
+
+ # Handle the case where SPHINXDIRS is used
+ if not os.path.samefile(doctree, app.srcdir):
+ # Add a tag to mark that the build is actually a subproject
+ tags.add("subproject")
+
+ # get index.rst, if it exists
+ doc = os.path.basename(app.srcdir)
+ fname = "index"
+ if os.path.exists(os.path.join(app.srcdir, fname + ".rst")):
+ latex_documents.append((fname, doc + ".tex",
+ "Linux %s Documentation" % doc.capitalize(),
+ "The kernel development community",
+ "manual"))
+ return
+
+ # When building all docs, or when a main index.rst doesn't exist, seek
+ # for it on subdirectories
+ for doc in os.listdir(app.srcdir):
+ fname = os.path.join(doc, "index")
+ if not os.path.exists(os.path.join(app.srcdir, fname + ".rst")):
+ continue
+
+ has = False
+ for l in latex_documents:
+ if l[0] == fname:
+ has = True
+ break
+
+ if not has:
+ latex_documents.append((fname, doc + ".tex",
+ "Linux %s Documentation" % doc.capitalize(),
+ "The kernel development community",
+ "manual"))
# helper
# ------
+
def have_command(cmd):
"""Search ``cmd`` in the ``PATH`` environment.
@@ -28,92 +137,89 @@ def have_command(cmd):
"""
return shutil.which(cmd) is not None
-# Get Sphinx version
-major, minor, patch = sphinx.version_info[:3]
-
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-sys.path.insert(0, os.path.abspath('sphinx'))
-from load_config import loadConfig
# -- General configuration ------------------------------------------------
-# If your documentation needs a minimal Sphinx version, state it here.
-needs_sphinx = '1.7'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
- 'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
- 'maintainers_include', 'sphinx.ext.autosectionlabel',
- 'kernel_abi', 'kernel_feat']
-
-if major >= 3:
- if (major > 3) or (minor > 0 or patch >= 2):
- # Sphinx c function parser is more pedantic with regards to type
- # checking. Due to that, having macros at c:function cause problems.
- # Those needed to be scaped by using c_id_attributes[] array
- c_id_attributes = [
- # GCC Compiler types not parsed by Sphinx:
- "__restrict__",
-
- # include/linux/compiler_types.h:
- "__iomem",
- "__kernel",
- "noinstr",
- "notrace",
- "__percpu",
- "__rcu",
- "__user",
-
- # include/linux/compiler_attributes.h:
- "__alias",
- "__aligned",
- "__aligned_largest",
- "__always_inline",
- "__assume_aligned",
- "__cold",
- "__attribute_const__",
- "__copy",
- "__pure",
- "__designated_init",
- "__visible",
- "__printf",
- "__scanf",
- "__gnu_inline",
- "__malloc",
- "__mode",
- "__no_caller_saved_registers",
- "__noclone",
- "__nonstring",
- "__noreturn",
- "__packed",
- "__pure",
- "__section",
- "__always_unused",
- "__maybe_unused",
- "__used",
- "__weak",
- "noinline",
- "__fix_address",
-
- # include/linux/memblock.h:
- "__init_memblock",
- "__meminit",
-
- # include/linux/init.h:
- "__init",
- "__ref",
-
- # include/linux/linkage.h:
- "asmlinkage",
- ]
-
-else:
- extensions.append('cdomain')
+# Add any Sphinx extensions in alphabetic order
+extensions = [
+ "automarkup",
+ "kernel_abi",
+ "kerneldoc",
+ "kernel_feat",
+ "kernel_include",
+ "kfigure",
+ "maintainers_include",
+ "parser_yaml",
+ "rstFlatTable",
+ "sphinx.ext.autosectionlabel",
+ "sphinx.ext.ifconfig",
+ "translations",
+]
+# Since Sphinx version 3, the C function parser is more pedantic with regards
+# to type checking. Due to that, having macros at c:function cause problems.
+# Those needed to be escaped by using c_id_attributes[] array
+c_id_attributes = [
+ # GCC Compiler types not parsed by Sphinx:
+ "__restrict__",
+
+ # include/linux/compiler_types.h:
+ "__iomem",
+ "__kernel",
+ "noinstr",
+ "notrace",
+ "__percpu",
+ "__rcu",
+ "__user",
+ "__force",
+ "__counted_by_le",
+ "__counted_by_be",
+
+ # include/linux/compiler_attributes.h:
+ "__alias",
+ "__aligned",
+ "__aligned_largest",
+ "__always_inline",
+ "__assume_aligned",
+ "__cold",
+ "__attribute_const__",
+ "__copy",
+ "__pure",
+ "__designated_init",
+ "__visible",
+ "__printf",
+ "__scanf",
+ "__gnu_inline",
+ "__malloc",
+ "__mode",
+ "__no_caller_saved_registers",
+ "__noclone",
+ "__nonstring",
+ "__noreturn",
+ "__packed",
+ "__pure",
+ "__section",
+ "__always_unused",
+ "__maybe_unused",
+ "__used",
+ "__weak",
+ "noinline",
+ "__fix_address",
+ "__counted_by",
+
+ # include/linux/memblock.h:
+ "__init_memblock",
+ "__meminit",
+
+ # include/linux/init.h:
+ "__init",
+ "__ref",
+
+ # include/linux/linkage.h:
+ "asmlinkage",
+
+ # include/linux/btf.h
+ "__bpf_kfunc",
+]
# Ensure that autosectionlabel will produce unique names
autosectionlabel_prefix_document = True
@@ -122,54 +228,51 @@ autosectionlabel_maxdepth = 2
# Load math renderer:
# For html builder, load imgmath only when its dependencies are met.
# mathjax is the default math renderer since Sphinx 1.8.
-have_latex = have_command('latex')
-have_dvipng = have_command('dvipng')
+have_latex = have_command("latex")
+have_dvipng = have_command("dvipng")
load_imgmath = have_latex and have_dvipng
# Respect SPHINX_IMGMATH (for html docs only)
-if 'SPHINX_IMGMATH' in os.environ:
- env_sphinx_imgmath = os.environ['SPHINX_IMGMATH']
- if 'yes' in env_sphinx_imgmath:
+if "SPHINX_IMGMATH" in os.environ:
+ env_sphinx_imgmath = os.environ["SPHINX_IMGMATH"]
+ if "yes" in env_sphinx_imgmath:
load_imgmath = True
- elif 'no' in env_sphinx_imgmath:
+ elif "no" in env_sphinx_imgmath:
load_imgmath = False
else:
sys.stderr.write("Unknown env SPHINX_IMGMATH=%s ignored.\n" % env_sphinx_imgmath)
-# Always load imgmath for Sphinx <1.8 or for epub docs
-load_imgmath = (load_imgmath or (major == 1 and minor < 8)
- or 'epub' in sys.argv)
-
if load_imgmath:
extensions.append("sphinx.ext.imgmath")
- math_renderer = 'imgmath'
+ math_renderer = "imgmath"
else:
- math_renderer = 'mathjax'
+ math_renderer = "mathjax"
# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
+templates_path = ["sphinx/templates"]
-# The suffix(es) of source filenames.
-# You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
-source_suffix = '.rst'
+# The suffixes of source filenames that will be automatically parsed
+source_suffix = {
+ ".rst": "restructuredtext",
+ ".yaml": "yaml",
+}
# The encoding of source files.
-#source_encoding = 'utf-8-sig'
+# source_encoding = 'utf-8-sig'
# The master toctree document.
-master_doc = 'index'
+master_doc = "index"
# General information about the project.
-project = 'The Linux Kernel'
-copyright = 'The kernel development community'
-author = 'The kernel development community'
+project = "The Linux Kernel"
+copyright = "The kernel development community" # pylint: disable=W0622
+author = "The kernel development community"
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
-# In a normal build, version and release are are set to KERNELVERSION and
+# In a normal build, version and release are set to KERNELVERSION and
# KERNELRELEASE, respectively, from the Makefile via Sphinx command line
# arguments.
#
@@ -178,68 +281,86 @@ author = 'The kernel development community'
try:
makefile_version = None
makefile_patchlevel = None
- for line in open('../Makefile'):
- key, val = [x.strip() for x in line.split('=', 2)]
- if key == 'VERSION':
- makefile_version = val
- elif key == 'PATCHLEVEL':
- makefile_patchlevel = val
- if makefile_version and makefile_patchlevel:
- break
-except:
+ with open("../Makefile", encoding="utf=8") as fp:
+ for line in fp:
+ key, val = [x.strip() for x in line.split("=", 2)]
+ if key == "VERSION":
+ makefile_version = val
+ elif key == "PATCHLEVEL":
+ makefile_patchlevel = val
+ if makefile_version and makefile_patchlevel:
+ break
+except Exception:
pass
finally:
if makefile_version and makefile_patchlevel:
- version = release = makefile_version + '.' + makefile_patchlevel
+ version = release = makefile_version + "." + makefile_patchlevel
else:
version = release = "unknown version"
+
+def get_cline_version():
+ """
+ HACK: There seems to be no easy way for us to get at the version and
+ release information passed in from the makefile...so go pawing through the
+ command-line options and find it for ourselves.
+ """
+
+ c_version = c_release = ""
+ for arg in sys.argv:
+ if arg.startswith("version="):
+ c_version = arg[8:]
+ elif arg.startswith("release="):
+ c_release = arg[8:]
+ if c_version:
+ if c_release:
+ return c_version + "-" + c_release
+ return c_version
+ return version # Whatever we came up with before
+
+
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
-language = 'en'
+language = "en"
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
-#today = ''
+# today = ''
# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-exclude_patterns = ['output']
+# today_fmt = '%B %d, %Y'
# The reST default role (used for this markup: `text`) to use for all
# documents.
-#default_role = None
+# default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
+# add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
-#add_module_names = True
+# add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
-#show_authors = False
+# show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
+pygments_style = "sphinx"
# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
+# modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
-#keep_warnings = False
+# keep_warnings = False
# If true, `todo` and `todoList` produce output, else they produce nothing.
todo_include_todos = False
-primary_domain = 'c'
-highlight_language = 'none'
+primary_domain = "c"
+highlight_language = "none"
# -- Options for HTML output ----------------------------------------------
@@ -247,39 +368,45 @@ highlight_language = 'none'
# a list of builtin themes.
# Default theme
-html_theme = 'sphinx_rtd_theme'
+html_theme = "alabaster"
html_css_files = []
if "DOCS_THEME" in os.environ:
html_theme = os.environ["DOCS_THEME"]
-if html_theme == 'sphinx_rtd_theme' or html_theme == 'sphinx_rtd_dark_mode':
+if html_theme in ["sphinx_rtd_theme", "sphinx_rtd_dark_mode"]:
# Read the Docs theme
try:
import sphinx_rtd_theme
+
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_css_files = [
- 'theme_overrides.css',
+ "theme_overrides.css",
]
# Read the Docs dark mode override theme
- if html_theme == 'sphinx_rtd_dark_mode':
+ if html_theme == "sphinx_rtd_dark_mode":
try:
- import sphinx_rtd_dark_mode
- extensions.append('sphinx_rtd_dark_mode')
+ import sphinx_rtd_dark_mode # pylint: disable=W0611
+
+ extensions.append("sphinx_rtd_dark_mode")
except ImportError:
- html_theme == 'sphinx_rtd_theme'
+ html_theme = "sphinx_rtd_theme"
+
+ if html_theme == "sphinx_rtd_theme":
+ # Add color-specific RTD normal mode
+ html_css_files.append("theme_rtd_colors.css")
- if html_theme == 'sphinx_rtd_theme':
- # Add color-specific RTD normal mode
- html_css_files.append('theme_rtd_colors.css')
+ html_theme_options = {
+ "navigation_depth": -1,
+ }
except ImportError:
- html_theme = 'classic'
+ html_theme = "alabaster"
if "DOCS_CSS" in os.environ:
css = os.environ["DOCS_CSS"].split(" ")
@@ -287,250 +414,115 @@ if "DOCS_CSS" in os.environ:
for l in css:
html_css_files.append(l)
-if major <= 1 and minor < 8:
- html_context = {
- 'css_files': [],
- }
-
- for l in html_css_files:
- html_context['css_files'].append('_static/' + l)
-
-if html_theme == 'classic':
+if html_theme == "alabaster":
html_theme_options = {
- 'rightsidebar': False,
- 'stickysidebar': True,
- 'collapsiblesidebar': True,
- 'externalrefs': False,
-
- 'footerbgcolor': "white",
- 'footertextcolor': "white",
- 'sidebarbgcolor': "white",
- 'sidebarbtncolor': "black",
- 'sidebartextcolor': "black",
- 'sidebarlinkcolor': "#686bff",
- 'relbarbgcolor': "#133f52",
- 'relbartextcolor': "white",
- 'relbarlinkcolor': "white",
- 'bgcolor': "white",
- 'textcolor': "black",
- 'headbgcolor': "#f2f2f2",
- 'headtextcolor': "#20435c",
- 'headlinkcolor': "#c60f0f",
- 'linkcolor': "#355f7c",
- 'visitedlinkcolor': "#355f7c",
- 'codebgcolor': "#3f3f3f",
- 'codetextcolor': "white",
-
- 'bodyfont': "serif",
- 'headfont': "sans-serif",
+ "description": get_cline_version(),
+ "page_width": "65em",
+ "sidebar_width": "15em",
+ "fixed_sidebar": "true",
+ "font_size": "inherit",
+ "font_family": "serif",
}
sys.stderr.write("Using %s theme\n" % html_theme)
-# Theme options are theme-specific and customize the look and feel of a theme
-# further. For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-#html_theme_path = []
-
-# The name for this set of Sphinx documents. If None, it defaults to
-# "<project> v<release> documentation".
-#html_title = None
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['sphinx-static']
-
-# Add any extra paths that contain custom files (such as robots.txt or
-# .htaccess) here, relative to this directory. These files are copied
-# directly to the root of the documentation.
-#html_extra_path = []
+html_static_path = ["sphinx-static"]
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-#html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-html_use_smartypants = False
+# If true, Docutils "smart quotes" will be used to convert quotes and dashes
+# to typographically correct entities. However, conversion of "--" to "—"
+# is not always what we want, so enable only quotes.
+smartquotes_action = "q"
# Custom sidebar templates, maps document names to template names.
-# Note that the RTD theme ignores this.
-html_sidebars = { '**': ['searchbox.html', 'localtoc.html', 'sourcelink.html']}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-#html_domain_indices = True
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
+# Note that the RTD theme ignores this
+html_sidebars = {"**": ["searchbox.html",
+ "kernel-toc.html",
+ "sourcelink.html"]}
-# If true, links to the reST sources are added to the pages.
-#html_show_sourcelink = True
+# about.html is available for alabaster theme. Add it at the front.
+if html_theme == "alabaster":
+ html_sidebars["**"].insert(0, "about.html")
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Language to be used for generating the HTML full-text search index.
-# Sphinx supports the following languages:
-# 'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
-# 'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'
-#html_search_language = 'en'
-
-# A dictionary with options for the search language support, empty by default.
-# Now only 'ja' uses this config value
-#html_search_options = {'type': 'default'}
-
-# The name of a javascript file (relative to the configuration directory) that
-# implements a search results scorer. If empty, the default will be used.
-#html_search_scorer = 'scorer.js'
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+html_logo = "images/logo.svg"
# Output file base name for HTML help builder.
-htmlhelp_basename = 'TheLinuxKerneldoc'
+htmlhelp_basename = "TheLinuxKerneldoc"
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
- 'papersize': 'a4paper',
-
+ "papersize": "a4paper",
+ "passoptionstopackages": dedent(r"""
+ \PassOptionsToPackage{svgnames}{xcolor}
+ """),
# The font size ('10pt', '11pt' or '12pt').
- 'pointsize': '11pt',
-
+ "pointsize": "11pt",
+ # Needed to generate a .ind file
+ "printindex": r"\footnotesize\raggedright\printindex",
# Latex figure (float) alignment
- #'figure_align': 'htbp',
-
+ # 'figure_align': 'htbp',
# Don't mangle with UTF-8 chars
- 'inputenc': '',
- 'utf8extra': '',
-
+ "fontenc": "",
+ "inputenc": "",
+ "utf8extra": "",
# Set document margins
- 'sphinxsetup': '''
+ "sphinxsetup": dedent(r"""
hmargin=0.5in, vmargin=1in,
parsedliteralwraps=true,
verbatimhintsturnover=false,
- ''',
-
+ """),
+ #
+ # Some of our authors are fond of deep nesting; tell latex to
+ # cope.
+ #
+ "maxlistdepth": "10",
# For CJK One-half spacing, need to be in front of hyperref
- 'extrapackages': r'\usepackage{setspace}',
-
- # Additional stuff for the LaTeX preamble.
- 'preamble': '''
- % Use some font with UTF-8 support with XeLaTeX
- \\usepackage{fontspec}
- \\setsansfont{DejaVu Sans}
- \\setromanfont{DejaVu Serif}
- \\setmonofont{DejaVu Sans Mono}
- ''',
-}
-
-# Fix reference escape troubles with Sphinx 1.4.x
-if major == 1:
- latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
-
-
-# Load kerneldoc specific LaTeX settings
-latex_elements['preamble'] += '''
+ "extrapackages": r"\usepackage{setspace}",
+ "fontpkg": dedent(r"""
+ \usepackage{fontspec}
+ \setmainfont{DejaVu Serif}
+ \setsansfont{DejaVu Sans}
+ \setmonofont{DejaVu Sans Mono}
+ \newfontfamily\headingfont{DejaVu Serif}
+ """),
+ "preamble": dedent(r"""
% Load kerneldoc specific LaTeX settings
- \\input{kerneldoc-preamble.sty}
-'''
-
-# With Sphinx 1.6, it is possible to change the Bg color directly
-# by using:
-# \definecolor{sphinxnoteBgColor}{RGB}{204,255,255}
-# \definecolor{sphinxwarningBgColor}{RGB}{255,204,204}
-# \definecolor{sphinxattentionBgColor}{RGB}{255,255,204}
-# \definecolor{sphinximportantBgColor}{RGB}{192,255,204}
-#
-# However, it require to use sphinx heavy box with:
-#
-# \renewenvironment{sphinxlightbox} {%
-# \\begin{sphinxheavybox}
-# }
-# \\end{sphinxheavybox}
-# }
-#
-# Unfortunately, the implementation is buggy: if a note is inside a
-# table, it isn't displayed well. So, for now, let's use boring
-# black and white notes.
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title,
-# author, documentclass [howto, manual, or own class]).
-# Sorted in alphabetical order
-latex_documents = [
-]
+ \input{kerneldoc-preamble.sty}
+ """)
+}
-# Add all other index files from Documentation/ subdirectories
-for fn in os.listdir('.'):
- doc = os.path.join(fn, "index")
- if os.path.exists(doc + ".rst"):
- has = False
- for l in latex_documents:
- if l[0] == doc:
- has = True
- break
- if not has:
- latex_documents.append((doc, fn + '.tex',
- 'Linux %s Documentation' % fn.capitalize(),
- 'The kernel development community',
- 'manual'))
+# This will be filled up by config-inited event
+latex_documents = []
# The name of an image file (relative to this directory) to place at the top of
# the title page.
-#latex_logo = None
+# latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
-#latex_use_parts = False
+# latex_use_parts = False
# If true, show page references after internal links.
-#latex_show_pagerefs = False
+# latex_show_pagerefs = False
# If true, show URL addresses after external links.
-#latex_show_urls = False
+# latex_show_urls = False
# Documents to append as an appendix to all manuals.
-#latex_appendices = []
+# latex_appendices = []
# If false, no module index is generated.
-#latex_domain_indices = True
+# latex_domain_indices = True
# Additional LaTeX stuff to be copied to build directory
latex_additional_files = [
- 'sphinx/kerneldoc-preamble.sty',
+ "sphinx/kerneldoc-preamble.sty",
]
@@ -539,12 +531,11 @@ latex_additional_files = [
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
- (master_doc, 'thelinuxkernel', 'The Linux Kernel Documentation',
- [author], 1)
+ (master_doc, "thelinuxkernel", "The Linux Kernel Documentation", [author], 1)
]
# If true, show URL addresses after external links.
-#man_show_urls = False
+# man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
@@ -552,24 +543,15 @@ man_pages = [
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
-texinfo_documents = [
- (master_doc, 'TheLinuxKernel', 'The Linux Kernel Documentation',
- author, 'TheLinuxKernel', 'One line description of project.',
- 'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-# If true, do not generate a @detailmenu in the "Top" node's menu.
-#texinfo_no_detailmenu = False
-
+texinfo_documents = [(
+ master_doc,
+ "TheLinuxKernel",
+ "The Linux Kernel Documentation",
+ author,
+ "TheLinuxKernel",
+ "One line description of project.",
+ "Miscellaneous",
+ ),]
# -- Options for Epub output ----------------------------------------------
@@ -579,68 +561,10 @@ epub_author = author
epub_publisher = author
epub_copyright = copyright
-# The basename for the epub file. It defaults to the project name.
-#epub_basename = project
-
-# The HTML theme for the epub output. Since the default themes are not
-# optimized for small screen space, using the same theme for HTML and epub
-# output is usually not wise. This defaults to 'epub', a theme designed to save
-# visual space.
-#epub_theme = 'epub'
-
-# The language of the text. It defaults to the language option
-# or 'en' if the language is not set.
-#epub_language = ''
-
-# The scheme of the identifier. Typical schemes are ISBN or URL.
-#epub_scheme = ''
-
-# The unique identifier of the text. This can be a ISBN number
-# or the project homepage.
-#epub_identifier = ''
-
-# A unique identification for the text.
-#epub_uid = ''
-
-# A tuple containing the cover image and cover page html template filenames.
-#epub_cover = ()
-
-# A sequence of (type, uri, title) tuples for the guide element of content.opf.
-#epub_guide = ()
-
-# HTML files that should be inserted before the pages created by sphinx.
-# The format is a list of tuples containing the path and title.
-#epub_pre_files = []
-
-# HTML files that should be inserted after the pages created by sphinx.
-# The format is a list of tuples containing the path and title.
-#epub_post_files = []
-
# A list of files that should not be packed into the epub file.
-epub_exclude_files = ['search.html']
+epub_exclude_files = ["search.html"]
-# The depth of the table of contents in toc.ncx.
-#epub_tocdepth = 3
-
-# Allow duplicate toc entries.
-#epub_tocdup = True
-
-# Choose between 'default' and 'includehidden'.
-#epub_tocscope = 'default'
-
-# Fix unsupported image types using the Pillow.
-#epub_fix_images = False
-
-# Scale large images.
-#epub_max_image_width = 0
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#epub_show_urls = 'inline'
-
-# If false, no index is generated.
-#epub_use_index = True
-
-#=======
+# =======
# rst2pdf
#
# Grouping the document tree into PDF files. List of tuples
@@ -652,17 +576,16 @@ epub_exclude_files = ['search.html']
# multiple PDF files here actually tries to get the cross-referencing right
# *between* PDF files.
pdf_documents = [
- ('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
+ ("kernel-documentation", "Kernel", "Kernel", "J. Random Bozo"),
]
# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
# the Docs). In a normal build, these are supplied from the Makefile via command
# line arguments.
-kerneldoc_bin = '../scripts/kernel-doc'
-kerneldoc_srctree = '..'
-
-# ------------------------------------------------------------------------------
-# Since loadConfig overwrites settings from the global namespace, it has to be
-# the last statement in the conf.py file
-# ------------------------------------------------------------------------------
-loadConfig(globals())
+kerneldoc_bin = "../scripts/kernel-doc.py"
+kerneldoc_srctree = ".."
+
+def setup(app):
+ """Patterns need to be updated at init time on older Sphinx versions"""
+
+ app.connect('config-inited', config_init)
diff --git a/Documentation/core-api/asm-annotations.rst b/Documentation/core-api/asm-annotations.rst
index bc514ed59887..11c96d3f9ad6 100644
--- a/Documentation/core-api/asm-annotations.rst
+++ b/Documentation/core-api/asm-annotations.rst
@@ -44,7 +44,7 @@ information. In particular, on properly annotated objects, ``objtool`` can be
run to check and fix the object if needed. Currently, ``objtool`` can report
missing frame pointer setup/destruction in functions. It can also
automatically generate annotations for the ORC unwinder
-(Documentation/x86/orc-unwinder.rst)
+(Documentation/arch/x86/orc-unwinder.rst)
for most code. Both of these are especially important to support reliable
stack traces which are in turn necessary for kernel live patching
(Documentation/livepatch/livepatch.rst).
diff --git a/Documentation/core-api/assoc_array.rst b/Documentation/core-api/assoc_array.rst
index 792bbf9939e1..19d89f92bf8d 100644
--- a/Documentation/core-api/assoc_array.rst
+++ b/Documentation/core-api/assoc_array.rst
@@ -92,18 +92,18 @@ There are two functions for dealing with the script:
void assoc_array_apply_edit(struct assoc_array_edit *edit);
-This will perform the edit functions, interpolating various write barriers
-to permit accesses under the RCU read lock to continue. The edit script
-will then be passed to ``call_rcu()`` to free it and any dead stuff it points
-to.
+ This will perform the edit functions, interpolating various write barriers
+ to permit accesses under the RCU read lock to continue. The edit script
+ will then be passed to ``call_rcu()`` to free it and any dead stuff it
+ points to.
2. Cancel an edit script::
void assoc_array_cancel_edit(struct assoc_array_edit *edit);
-This frees the edit script and all preallocated memory immediately. If
-this was for insertion, the new object is _not_ released by this function,
-but must rather be released by the caller.
+ This frees the edit script and all preallocated memory immediately. If
+ this was for insertion, the new object is *not* released by this function,
+ but must rather be released by the caller.
These functions are guaranteed not to fail.
@@ -123,43 +123,43 @@ This points to a number of methods, all of which need to be provided:
unsigned long (*get_key_chunk)(const void *index_key, int level);
-This should return a chunk of caller-supplied index key starting at the
-*bit* position given by the level argument. The level argument will be a
-multiple of ``ASSOC_ARRAY_KEY_CHUNK_SIZE`` and the function should return
-``ASSOC_ARRAY_KEY_CHUNK_SIZE bits``. No error is possible.
+ This should return a chunk of caller-supplied index key starting at the
+ *bit* position given by the level argument. The level argument will be a
+ multiple of ``ASSOC_ARRAY_KEY_CHUNK_SIZE`` and the function should return
+ ``ASSOC_ARRAY_KEY_CHUNK_SIZE bits``. No error is possible.
2. Get a chunk of an object's index key::
unsigned long (*get_object_key_chunk)(const void *object, int level);
-As the previous function, but gets its data from an object in the array
-rather than from a caller-supplied index key.
+ As the previous function, but gets its data from an object in the array
+ rather than from a caller-supplied index key.
3. See if this is the object we're looking for::
bool (*compare_object)(const void *object, const void *index_key);
-Compare the object against an index key and return ``true`` if it matches and
-``false`` if it doesn't.
+ Compare the object against an index key and return ``true`` if it matches
+ and ``false`` if it doesn't.
4. Diff the index keys of two objects::
int (*diff_objects)(const void *object, const void *index_key);
-Return the bit position at which the index key of the specified object
-differs from the given index key or -1 if they are the same.
+ Return the bit position at which the index key of the specified object
+ differs from the given index key or -1 if they are the same.
5. Free an object::
void (*free_object)(void *object);
-Free the specified object. Note that this may be called an RCU grace period
-after ``assoc_array_apply_edit()`` was called, so ``synchronize_rcu()`` may be
-necessary on module unloading.
+ Free the specified object. Note that this may be called an RCU grace period
+ after ``assoc_array_apply_edit()`` was called, so ``synchronize_rcu()`` may
+ be necessary on module unloading.
Manipulation Functions
@@ -171,7 +171,7 @@ There are a number of functions for manipulating an associative array:
void assoc_array_init(struct assoc_array *array);
-This initialises the base structure for an associative array. It can't fail.
+ This initialises the base structure for an associative array. It can't fail.
2. Insert/replace an object in an associative array::
@@ -182,21 +182,21 @@ This initialises the base structure for an associative array. It can't fail.
const void *index_key,
void *object);
-This inserts the given object into the array. Note that the least
-significant bit of the pointer must be zero as it's used to type-mark
-pointers internally.
+ This inserts the given object into the array. Note that the least
+ significant bit of the pointer must be zero as it's used to type-mark
+ pointers internally.
-If an object already exists for that key then it will be replaced with the
-new object and the old one will be freed automatically.
+ If an object already exists for that key then it will be replaced with the
+ new object and the old one will be freed automatically.
-The ``index_key`` argument should hold index key information and is
-passed to the methods in the ops table when they are called.
+ The ``index_key`` argument should hold index key information and is
+ passed to the methods in the ops table when they are called.
-This function makes no alteration to the array itself, but rather returns
-an edit script that must be applied. ``-ENOMEM`` is returned in the case of
-an out-of-memory error.
+ This function makes no alteration to the array itself, but rather returns
+ an edit script that must be applied. ``-ENOMEM`` is returned in the case of
+ an out-of-memory error.
-The caller should lock exclusively against other modifiers of the array.
+ The caller should lock exclusively against other modifiers of the array.
3. Delete an object from an associative array::
@@ -206,15 +206,15 @@ The caller should lock exclusively against other modifiers of the array.
const struct assoc_array_ops *ops,
const void *index_key);
-This deletes an object that matches the specified data from the array.
+ This deletes an object that matches the specified data from the array.
-The ``index_key`` argument should hold index key information and is
-passed to the methods in the ops table when they are called.
+ The ``index_key`` argument should hold index key information and is
+ passed to the methods in the ops table when they are called.
-This function makes no alteration to the array itself, but rather returns
-an edit script that must be applied. ``-ENOMEM`` is returned in the case of
-an out-of-memory error. ``NULL`` will be returned if the specified object is
-not found within the array.
+ This function makes no alteration to the array itself, but rather returns
+ an edit script that must be applied. ``-ENOMEM`` is returned in the case of
+ an out-of-memory error. ``NULL`` will be returned if the specified object
+ is not found within the array.
The caller should lock exclusively against other modifiers of the array.
@@ -225,14 +225,14 @@ The caller should lock exclusively against other modifiers of the array.
assoc_array_clear(struct assoc_array *array,
const struct assoc_array_ops *ops);
-This deletes all the objects from an associative array and leaves it
-completely empty.
+ This deletes all the objects from an associative array and leaves it
+ completely empty.
-This function makes no alteration to the array itself, but rather returns
-an edit script that must be applied. ``-ENOMEM`` is returned in the case of
-an out-of-memory error.
+ This function makes no alteration to the array itself, but rather returns
+ an edit script that must be applied. ``-ENOMEM`` is returned in the case of
+ an out-of-memory error.
-The caller should lock exclusively against other modifiers of the array.
+ The caller should lock exclusively against other modifiers of the array.
5. Destroy an associative array, deleting all objects::
@@ -240,14 +240,14 @@ The caller should lock exclusively against other modifiers of the array.
void assoc_array_destroy(struct assoc_array *array,
const struct assoc_array_ops *ops);
-This destroys the contents of the associative array and leaves it
-completely empty. It is not permitted for another thread to be traversing
-the array under the RCU read lock at the same time as this function is
-destroying it as no RCU deferral is performed on memory release -
-something that would require memory to be allocated.
+ This destroys the contents of the associative array and leaves it
+ completely empty. It is not permitted for another thread to be traversing
+ the array under the RCU read lock at the same time as this function is
+ destroying it as no RCU deferral is performed on memory release -
+ something that would require memory to be allocated.
-The caller should lock exclusively against other modifiers and accessors
-of the array.
+ The caller should lock exclusively against other modifiers and accessors
+ of the array.
6. Garbage collect an associative array::
@@ -257,24 +257,24 @@ of the array.
bool (*iterator)(void *object, void *iterator_data),
void *iterator_data);
-This iterates over the objects in an associative array and passes each one to
-``iterator()``. If ``iterator()`` returns ``true``, the object is kept. If it
-returns ``false``, the object will be freed. If the ``iterator()`` function
-returns ``true``, it must perform any appropriate refcount incrementing on the
-object before returning.
+ This iterates over the objects in an associative array and passes each one
+ to ``iterator()``. If ``iterator()`` returns ``true``, the object is kept.
+ If it returns ``false``, the object will be freed. If the ``iterator()``
+ function returns ``true``, it must perform any appropriate refcount
+ incrementing on the object before returning.
-The internal tree will be packed down if possible as part of the iteration
-to reduce the number of nodes in it.
+ The internal tree will be packed down if possible as part of the iteration
+ to reduce the number of nodes in it.
-The ``iterator_data`` is passed directly to ``iterator()`` and is otherwise
-ignored by the function.
+ The ``iterator_data`` is passed directly to ``iterator()`` and is otherwise
+ ignored by the function.
-The function will return ``0`` if successful and ``-ENOMEM`` if there wasn't
-enough memory.
+ The function will return ``0`` if successful and ``-ENOMEM`` if there wasn't
+ enough memory.
-It is possible for other threads to iterate over or search the array under
-the RCU read lock while this function is in progress. The caller should
-lock exclusively against other modifiers of the array.
+ It is possible for other threads to iterate over or search the array under
+ the RCU read lock while this function is in progress. The caller should
+ lock exclusively against other modifiers of the array.
Access Functions
@@ -289,19 +289,19 @@ There are two functions for accessing an associative array:
void *iterator_data),
void *iterator_data);
-This passes each object in the array to the iterator callback function.
-``iterator_data`` is private data for that function.
+ This passes each object in the array to the iterator callback function.
+ ``iterator_data`` is private data for that function.
-This may be used on an array at the same time as the array is being
-modified, provided the RCU read lock is held. Under such circumstances,
-it is possible for the iteration function to see some objects twice. If
-this is a problem, then modification should be locked against. The
-iteration algorithm should not, however, miss any objects.
+ This may be used on an array at the same time as the array is being
+ modified, provided the RCU read lock is held. Under such circumstances,
+ it is possible for the iteration function to see some objects twice. If
+ this is a problem, then modification should be locked against. The
+ iteration algorithm should not, however, miss any objects.
-The function will return ``0`` if no objects were in the array or else it will
-return the result of the last iterator function called. Iteration stops
-immediately if any call to the iteration function results in a non-zero
-return.
+ The function will return ``0`` if no objects were in the array or else it
+ will return the result of the last iterator function called. Iteration
+ stops immediately if any call to the iteration function results in a
+ non-zero return.
2. Find an object in an associative array::
@@ -310,14 +310,14 @@ return.
const struct assoc_array_ops *ops,
const void *index_key);
-This walks through the array's internal tree directly to the object
-specified by the index key..
+ This walks through the array's internal tree directly to the object
+ specified by the index key.
-This may be used on an array at the same time as the array is being
-modified, provided the RCU read lock is held.
+ This may be used on an array at the same time as the array is being
+ modified, provided the RCU read lock is held.
-The function will return the object if found (and set ``*_type`` to the object
-type) or will return ``NULL`` if the object was not found.
+ The function will return the object if found (and set ``*_type`` to the
+ object type) or will return ``NULL`` if the object was not found.
Index Key Form
@@ -399,10 +399,11 @@ fixed levels. For example::
In the above example, there are 7 nodes (A-G), each with 16 slots (0-f).
Assuming no other meta data nodes in the tree, the key space is divided
-thusly::
+thusly:
+ =========== ====
KEY PREFIX NODE
- ========== ====
+ =========== ====
137* D
138* E
13[0-69-f]* C
@@ -410,10 +411,12 @@ thusly::
e6* G
e[0-57-f]* F
[02-df]* A
+ =========== ====
So, for instance, keys with the following example index keys will be found in
-the appropriate nodes::
+the appropriate nodes:
+ =============== ======= ====
INDEX KEY PREFIX NODE
=============== ======= ====
13694892892489 13 C
@@ -422,12 +425,13 @@ the appropriate nodes::
138bbb89003093 138 E
1394879524789 12 C
1458952489 1 B
- 9431809de993ba - A
- b4542910809cd - A
+ 9431809de993ba \- A
+ b4542910809cd \- A
e5284310def98 e F
e68428974237 e6 G
e7fffcbd443 e F
- f3842239082 - A
+ f3842239082 \- A
+ =============== ======= ====
To save memory, if a node can hold all the leaves in its portion of keyspace,
then the node will have all those leaves in it and will not have any metadata
@@ -441,8 +445,9 @@ metadata pointer. If the metadata pointer is there, any leaf whose key matches
the metadata key prefix must be in the subtree that the metadata pointer points
to.
-In the above example list of index keys, node A will contain::
+In the above example list of index keys, node A will contain:
+ ==== =============== ==================
SLOT CONTENT INDEX KEY (PREFIX)
==== =============== ==================
1 PTR TO NODE B 1*
@@ -450,11 +455,16 @@ In the above example list of index keys, node A will contain::
any LEAF b4542910809cd
e PTR TO NODE F e*
any LEAF f3842239082
+ ==== =============== ==================
-and node B::
+and node B:
- 3 PTR TO NODE C 13*
- any LEAF 1458952489
+ ==== =============== ==================
+ SLOT CONTENT INDEX KEY (PREFIX)
+ ==== =============== ==================
+ 3 PTR TO NODE C 13*
+ any LEAF 1458952489
+ ==== =============== ==================
Shortcuts
diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst
index 5c0552e78c58..889fc84ccd1b 100644
--- a/Documentation/core-api/cachetlb.rst
+++ b/Documentation/core-api/cachetlb.rst
@@ -88,13 +88,17 @@ changes occur:
This is used primarily during fault processing.
-5) ``void update_mmu_cache(struct vm_area_struct *vma,
- unsigned long address, pte_t *ptep)``
+5) ``void update_mmu_cache_range(struct vm_fault *vmf,
+ struct vm_area_struct *vma, unsigned long address, pte_t *ptep,
+ unsigned int nr)``
- At the end of every page fault, this routine is invoked to
- tell the architecture specific code that a translation
- now exists at virtual address "address" for address space
- "vma->vm_mm", in the software page tables.
+ At the end of every page fault, this routine is invoked to tell
+ the architecture specific code that translations now exists
+ in the software page tables for address space "vma->vm_mm"
+ at virtual address "address" for "nr" consecutive pages.
+
+ This routine is also invoked in various other places which pass
+ a NULL "vmf".
A port may use this information in any way it so chooses.
For example, it could use this event to pre-load TLB
@@ -269,7 +273,7 @@ maps this page at its virtual address.
If D-cache aliasing is not an issue, these two routines may
simply call memcpy/memset directly and do nothing more.
- ``void flush_dcache_page(struct page *page)``
+ ``void flush_dcache_folio(struct folio *folio)``
This routines must be called when:
@@ -277,7 +281,7 @@ maps this page at its virtual address.
and / or in high memory
b) the kernel is about to read from a page cache page and user space
shared/writable mappings of this page potentially exist. Note
- that {get,pin}_user_pages{_fast} already call flush_dcache_page
+ that {get,pin}_user_pages{_fast} already call flush_dcache_folio
on any page found in the user address space and thus driver
code rarely needs to take this into account.
@@ -291,7 +295,7 @@ maps this page at its virtual address.
The phrase "kernel writes to a page cache page" means, specifically,
that the kernel executes store instructions that dirty data in that
- page at the page->virtual mapping of that page. It is important to
+ page at the kernel virtual mapping of that page. It is important to
flush here to handle D-cache aliasing, to make sure these kernel stores
are visible to user space mappings of that page.
@@ -302,21 +306,22 @@ maps this page at its virtual address.
If D-cache aliasing is not an issue, this routine may simply be defined
as a nop on that architecture.
- There is a bit set aside in page->flags (PG_arch_1) as "architecture
+ There is a bit set aside in folio->flags (PG_arch_1) as "architecture
private". The kernel guarantees that, for pagecache pages, it will
clear this bit when such a page first enters the pagecache.
- This allows these interfaces to be implemented much more efficiently.
- It allows one to "defer" (perhaps indefinitely) the actual flush if
- there are currently no user processes mapping this page. See sparc64's
- flush_dcache_page and update_mmu_cache implementations for an example
- of how to go about doing this.
+ This allows these interfaces to be implemented much more
+ efficiently. It allows one to "defer" (perhaps indefinitely) the
+ actual flush if there are currently no user processes mapping this
+ page. See sparc64's flush_dcache_folio and update_mmu_cache_range
+ implementations for an example of how to go about doing this.
- The idea is, first at flush_dcache_page() time, if page_file_mapping()
- returns a mapping, and mapping_mapped on that mapping returns %false,
- just mark the architecture private page flag bit. Later, in
- update_mmu_cache(), a check is made of this flag bit, and if set the
- flush is done and the flag bit is cleared.
+ The idea is, first at flush_dcache_folio() time, if
+ folio_flush_mapping() returns a mapping, and mapping_mapped() on that
+ mapping returns %false, just mark the architecture private page
+ flag bit. Later, in update_mmu_cache_range(), a check is made
+ of this flag bit, and if set the flush is done and the flag bit
+ is cleared.
.. important::
@@ -326,12 +331,6 @@ maps this page at its virtual address.
dirty. Again, see sparc64 for examples of how
to deal with this.
- ``void flush_dcache_folio(struct folio *folio)``
- This function is called under the same circumstances as
- flush_dcache_page(). It allows the architecture to
- optimise for flushing the entire folio of pages instead
- of flushing one page at a time.
-
``void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long user_vaddr, void *dst, void *src, int len)``
``void copy_from_user_page(struct vm_area_struct *vma, struct page *page,
@@ -352,7 +351,7 @@ maps this page at its virtual address.
When the kernel needs to access the contents of an anonymous
page, it calls this function (currently only
- get_user_pages()). Note: flush_dcache_page() deliberately
+ get_user_pages()). Note: flush_dcache_folio() deliberately
doesn't work for an anonymous page. The default
implementation is a nop (and should remain so for all coherent
architectures). For incoherent architectures, it should flush
@@ -369,7 +368,7 @@ maps this page at its virtual address.
``void flush_icache_page(struct vm_area_struct *vma, struct page *page)``
All the functionality of flush_icache_page can be implemented in
- flush_dcache_page and update_mmu_cache. In the future, the hope
+ flush_dcache_folio and update_mmu_cache_range. In the future, the hope
is to remove this interface completely.
The final category of APIs is for I/O to deliberately aliased address
diff --git a/Documentation/core-api/cgroup.rst b/Documentation/core-api/cgroup.rst
new file mode 100644
index 000000000000..734ea21e1e17
--- /dev/null
+++ b/Documentation/core-api/cgroup.rst
@@ -0,0 +1,9 @@
+==================
+Cgroup Kernel APIs
+==================
+
+Device Memory Cgroup API (dmemcg)
+=================================
+.. kernel-doc:: kernel/cgroup/dmem.c
+ :export:
+
diff --git a/Documentation/core-api/cleanup.rst b/Documentation/core-api/cleanup.rst
new file mode 100644
index 000000000000..527eb2f8ec6e
--- /dev/null
+++ b/Documentation/core-api/cleanup.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Scope-based Cleanup Helpers
+===========================
+
+.. kernel-doc:: include/linux/cleanup.h
+ :doc: scope-based cleanup helpers
diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
index f75778d37488..e1b0eeabbb5e 100644
--- a/Documentation/core-api/cpu_hotplug.rst
+++ b/Documentation/core-api/cpu_hotplug.rst
@@ -40,12 +40,6 @@ Command Line Switches
supplied here is lower than the number of physically available CPUs, then
those CPUs can not be brought online later.
-``additional_cpus=n``
- Use this to limit hotpluggable CPUs. This option sets
- ``cpu_possible_mask = cpu_present_mask + additional_cpus``
-
- This option is limited to the IA64 architecture.
-
``possible_cpus=n``
This option sets ``possible_cpus`` bits in ``cpu_possible_mask``.
@@ -127,17 +121,8 @@ bring CPU4 back online::
$ echo 1 > /sys/devices/system/cpu/cpu4/online
smpboot: Booting Node 0 Processor 4 APIC 0x1
-The CPU is usable again. This should work on all CPUs. CPU0 is often special
-and excluded from CPU hotplug. On X86 the kernel option
-*CONFIG_BOOTPARAM_HOTPLUG_CPU0* has to be enabled in order to be able to
-shutdown CPU0. Alternatively the kernel command option *cpu0_hotplug* can be
-used. Some known dependencies of CPU0:
-
-* Resume from hibernate/suspend. Hibernate/suspend will fail if CPU0 is offline.
-* PIC interrupts. CPU0 can't be removed if a PIC interrupt is detected.
-
-Please let Fenghua Yu <fenghua.yu@intel.com> know if you find any dependencies
-on CPU0.
+The CPU is usable again. This should work on all CPUs, but CPU0 is often special
+and excluded from CPU hotplug.
The CPU hotplug coordination
============================
@@ -404,8 +389,8 @@ multi-instance state the following function is available:
* cpuhp_setup_state_multi(state, name, startup, teardown)
The @state argument is either a statically allocated state or one of the
-constants for dynamically allocated states - CPUHP_PREPARE_DYN,
-CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
+constants for dynamically allocated states - CPUHP_BP_PREPARE_DYN,
+CPUHP_AP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
which a dynamic state should be allocated.
The @name argument is used for sysfs output and for instrumentation. The
@@ -597,7 +582,7 @@ notifications on online and offline operations::
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on offline operations::
- state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
+ state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
if (state < 0)
return state;
....
@@ -606,7 +591,7 @@ for notifications on offline operations::
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on online operations without invoking the callbacks::
- state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
+ state = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
if (state < 0)
return state;
....
@@ -615,7 +600,7 @@ for notifications on online operations without invoking the callbacks::
Setup, use and teardown a dynamically allocated multi-instance state in the
ONLINE section for notifications on online and offline operation::
- state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
+ state = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
if (state < 0)
return state;
....
@@ -631,7 +616,7 @@ ONLINE section for notifications on online and offline operation::
....
cpuhp_remove_instance(state, &inst2->node);
....
- remove_multi_state(state);
+ cpuhp_remove_multi_state(state);
Testing of hotplug states
@@ -750,6 +735,26 @@ will receive all events. A script like::
can process the event further.
+When changes to the CPUs in the system occur, the sysfs file
+/sys/devices/system/cpu/crash_hotplug contains '1' if the kernel
+updates the kdump capture kernel list of CPUs itself (via elfcorehdr and
+other relevant kexec segment), or '0' if userspace must update the kdump
+capture kernel list of CPUs.
+
+The availability depends on the CONFIG_HOTPLUG_CPU kernel configuration
+option.
+
+To skip userspace processing of CPU hot un/plug events for kdump
+(i.e. the unload-then-reload to obtain a current list of CPUs), this sysfs
+file can be used in a udev rule as follows:
+
+ SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
+
+For a CPU hot un/plug event, if the architecture supports kernel updates
+of the elfcorehdr (which contains the list of CPUs) and other relevant
+kexec segments, then the rule skips the unload-then-reload of the kdump
+capture kernel.
+
Kernel Inline Documentations Reference
======================================
diff --git a/Documentation/core-api/debugging-via-ohci1394.rst b/Documentation/core-api/debugging-via-ohci1394.rst
index 981ad4f89fd3..cb3d3228dfc8 100644
--- a/Documentation/core-api/debugging-via-ohci1394.rst
+++ b/Documentation/core-api/debugging-via-ohci1394.rst
@@ -23,9 +23,9 @@ Retrieving a full system memory dump is also possible over the FireWire,
using data transfer rates in the order of 10MB/s or more.
With most FireWire controllers, memory access is limited to the low 4 GB
-of physical address space. This can be a problem on IA64 machines where
-memory is located mostly above that limit, but it is rarely a problem on
-more common hardware such as x86, x86-64 and PowerPC.
+of physical address space. This can be a problem on machines where memory is
+located mostly above that limit, but it is rarely a problem on more common
+hardware such as x86, x86-64 and PowerPC.
At least LSI FW643e and FW643e2 controllers are known to support access to
physical addresses above 4 GB, but this feature is currently not enabled by
diff --git a/Documentation/core-api/dma-api-howto.rst b/Documentation/core-api/dma-api-howto.rst
index 828846804e25..96fce2a9aa90 100644
--- a/Documentation/core-api/dma-api-howto.rst
+++ b/Documentation/core-api/dma-api-howto.rst
@@ -8,7 +8,7 @@ Dynamic DMA mapping Guide
This is a guide to device driver writers on how to use the DMA API
with example pseudo-code. For a concise description of the API, see
-DMA-API.txt.
+Documentation/core-api/dma-api.rst.
CPU and DMA addresses
=====================
@@ -155,7 +155,7 @@ a device with limitations, it needs to be decreased.
Special note about PCI: PCI-X specification requires PCI-X devices to support
64-bit addressing (DAC) for all transactions. And at least one platform (SGI
-SN2) requires 64-bit consistent allocations to operate correctly when the IO
+SN2) requires 64-bit coherent allocations to operate correctly when the IO
bus is in PCI-X mode.
For correct operation, you must set the DMA mask to inform the kernel about
@@ -174,7 +174,7 @@ used instead:
int dma_set_mask(struct device *dev, u64 mask);
- The setup for consistent allocations is performed via a call
+ The setup for coherent allocations is performed via a call
to dma_set_coherent_mask()::
int dma_set_coherent_mask(struct device *dev, u64 mask);
@@ -185,7 +185,7 @@ device struct of your device is embedded in the bus-specific device struct of
your device. For example, &pdev->dev is a pointer to the device struct of a
PCI device (pdev is a pointer to the PCI device struct of your device).
-These calls usually return zero to indicated your device can perform DMA
+These calls usually return zero to indicate your device can perform DMA
properly on the machine given the address mask you provided, but they might
return an error if the mask is too small to be supportable on the given
system. If it returns non-zero, your device cannot perform DMA properly on
@@ -203,13 +203,33 @@ setting the DMA mask fails. In this manner, if a user of your driver reports
that performance is bad or that the device is not even detected, you can ask
them for the kernel messages to find out exactly why.
-The standard 64-bit addressing device would do something like this::
+The 24-bit addressing device would do something like this::
- if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(24))) {
dev_warn(dev, "mydev: No suitable DMA available\n");
goto ignore_this_device;
}
+The standard 64-bit addressing device would do something like this::
+
+ dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))
+
+dma_set_mask_and_coherent() never return fail when DMA_BIT_MASK(64). Typical
+error code like::
+
+ /* Wrong code */
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)))
+ dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))
+
+dma_set_mask_and_coherent() will never return failure when bigger than 32.
+So typical code like::
+
+ /* Recommended code */
+ if (support_64bit)
+ dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
+ else
+ dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+
If the device only supports 32-bit addressing for descriptors in the
coherent allocations, but supports full 64-bits for streaming mappings
it would look like this::
@@ -221,7 +241,7 @@ it would look like this::
The coherent mask will always be able to set the same or a smaller mask as
the streaming mask. However for the rare case that a device driver only
-uses consistent allocations, one would have to check the return value from
+uses coherent allocations, one would have to check the return value from
dma_set_coherent_mask().
Finally, if your device can only drive the low 24-bits of
@@ -278,20 +298,20 @@ Types of DMA mappings
There are two types of DMA mappings:
-- Consistent DMA mappings which are usually mapped at driver
+- Coherent DMA mappings which are usually mapped at driver
initialization, unmapped at the end and for which the hardware should
guarantee that the device and the CPU can access the data
in parallel and will see updates made by each other without any
explicit software flushing.
- Think of "consistent" as "synchronous" or "coherent".
+ Think of "coherent" as "synchronous".
- The current default is to return consistent memory in the low 32
+ The current default is to return coherent memory in the low 32
bits of the DMA space. However, for future compatibility you should
- set the consistent mask even if this default is fine for your
+ set the coherent mask even if this default is fine for your
driver.
- Good examples of what to use consistent mappings for are:
+ Good examples of what to use coherent mappings for are:
- Network card DMA ring descriptors.
- SCSI adapter mailbox command data structures.
@@ -300,13 +320,13 @@ There are two types of DMA mappings:
The invariant these examples all require is that any CPU store
to memory is immediately visible to the device, and vice
- versa. Consistent mappings guarantee this.
+ versa. Coherent mappings guarantee this.
.. important::
- Consistent DMA memory does not preclude the usage of
+ Coherent DMA memory does not preclude the usage of
proper memory barriers. The CPU may reorder stores to
- consistent memory just as it may normal memory. Example:
+ coherent memory just as it may normal memory. Example:
if it is important for the device to see the first word
of a descriptor updated before the second, you must do
something like::
@@ -345,10 +365,10 @@ Also, systems with caches that aren't DMA-coherent will work better
when the underlying buffers don't share cache lines with other data.
-Using Consistent DMA mappings
-=============================
+Using Coherent DMA mappings
+===========================
-To allocate and map large (PAGE_SIZE or so) consistent DMA regions,
+To allocate and map large (PAGE_SIZE or so) coherent DMA regions,
you should do::
dma_addr_t dma_handle;
@@ -365,10 +385,10 @@ __get_free_pages() (but takes size instead of a page order). If your
driver needs regions sized smaller than a page, you may prefer using
the dma_pool interface, described below.
-The consistent DMA mapping interfaces, will by default return a DMA address
+The coherent DMA mapping interfaces, will by default return a DMA address
which is 32-bit addressable. Even if the device indicates (via the DMA mask)
-that it may address the upper 32-bits, consistent allocation will only
-return > 32-bit addresses for DMA if the consistent DMA mask has been
+that it may address the upper 32-bits, coherent allocation will only
+return > 32-bit addresses for DMA if the coherent DMA mask has been
explicitly changed via dma_set_coherent_mask(). This is true of the
dma_pool interface as well.
@@ -477,7 +497,7 @@ program address space. Such platforms can and do report errors in the
kernel logs when the DMA controller hardware detects violation of the
permission setting.
-Only streaming mappings specify a direction, consistent mappings
+Only streaming mappings specify a direction, coherent mappings
implicitly have a direction attribute setting of
DMA_BIDIRECTIONAL.
diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst
index 829f20a193ca..ca75b3541679 100644
--- a/Documentation/core-api/dma-api.rst
+++ b/Documentation/core-api/dma-api.rst
@@ -8,15 +8,15 @@ This document describes the DMA API. For a more gentle introduction
of the API (and actual examples), see Documentation/core-api/dma-api-howto.rst.
This API is split into two pieces. Part I describes the basic API.
-Part II describes extensions for supporting non-consistent memory
+Part II describes extensions for supporting non-coherent memory
machines. Unless you know that your driver absolutely has to support
-non-consistent platforms (this is usually only legacy platforms) you
+non-coherent platforms (this is usually only legacy platforms) you
should only use the API described in part I.
-Part I - dma_API
+Part I - DMA API
----------------
-To get the dma_API, you must #include <linux/dma-mapping.h>. This
+To get the DMA API, you must #include <linux/dma-mapping.h>. This
provides dma_addr_t and the interfaces described below.
A dma_addr_t can hold any valid DMA address for the platform. It can be
@@ -33,13 +33,13 @@ Part Ia - Using large DMA-coherent buffers
dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
-Consistent memory is memory for which a write by either the device or
+Coherent memory is memory for which a write by either the device or
the processor can immediately be read by the processor or device
without having to worry about caching effects. (You may however need
to make sure to flush the processor's write buffers before telling
devices to read that memory.)
-This routine allocates a region of <size> bytes of consistent memory.
+This routine allocates a region of <size> bytes of coherent memory.
It returns a pointer to the allocated region (in the processor's virtual
address space) or NULL if the allocation failed.
@@ -48,15 +48,14 @@ It also returns a <dma_handle> which may be cast to an unsigned integer the
same width as the bus and given to the device as the DMA address base of
the region.
-Note: consistent memory can be expensive on some platforms, and the
+Note: coherent memory can be expensive on some platforms, and the
minimum allocation length may be as big as a page, so you should
-consolidate your requests for consistent memory as much as possible.
+consolidate your requests for coherent memory as much as possible.
The simplest way to do that is to use the dma_pool calls (see below).
-The flag parameter (dma_alloc_coherent() only) allows the caller to
-specify the ``GFP_`` flags (see kmalloc()) for the allocation (the
-implementation may choose to ignore flags that affect the location of
-the returned memory, like GFP_DMA).
+The flag parameter allows the caller to specify the ``GFP_`` flags (see
+kmalloc()) for the allocation (the implementation may ignore flags that affect
+the location of the returned memory, like GFP_DMA).
::
@@ -64,19 +63,18 @@ the returned memory, like GFP_DMA).
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle)
-Free a region of consistent memory you previously allocated. dev,
-size and dma_handle must all be the same as those passed into
-dma_alloc_coherent(). cpu_addr must be the virtual address returned by
-the dma_alloc_coherent().
+Free a previously allocated region of coherent memory. dev, size and dma_handle
+must all be the same as those passed into dma_alloc_coherent(). cpu_addr must
+be the virtual address returned by dma_alloc_coherent().
-Note that unlike their sibling allocation calls, these routines
-may only be called with IRQs enabled.
+Note that unlike the sibling allocation call, this routine may only be called
+with IRQs enabled.
Part Ib - Using small DMA-coherent buffers
------------------------------------------
-To get this part of the dma_API, you must #include <linux/dmapool.h>
+To get this part of the DMA API, you must #include <linux/dmapool.h>
Many drivers need lots of small DMA-coherent memory regions for DMA
descriptors or I/O buffers. Rather than allocating in units of a page
@@ -85,78 +83,29 @@ much like a struct kmem_cache, except that they use the DMA-coherent allocator,
not __get_free_pages(). Also, they understand common hardware constraints
for alignment, like queue heads needing to be aligned on N-byte boundaries.
+.. kernel-doc:: mm/dmapool.c
+ :export:
-::
-
- struct dma_pool *
- dma_pool_create(const char *name, struct device *dev,
- size_t size, size_t align, size_t alloc);
-
-dma_pool_create() initializes a pool of DMA-coherent buffers
-for use with a given device. It must be called in a context which
-can sleep.
-
-The "name" is for diagnostics (like a struct kmem_cache name); dev and size
-are like what you'd pass to dma_alloc_coherent(). The device's hardware
-alignment requirement for this type of data is "align" (which is expressed
-in bytes, and must be a power of two). If your device has no boundary
-crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated
-from this pool must not cross 4KByte boundaries.
-
-::
-
- void *
- dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
- dma_addr_t *handle)
-
-Wraps dma_pool_alloc() and also zeroes the returned memory if the
-allocation attempt succeeded.
-
-
-::
-
- void *
- dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
- dma_addr_t *dma_handle);
-
-This allocates memory from the pool; the returned memory will meet the
-size and alignment requirements specified at creation time. Pass
-GFP_ATOMIC to prevent blocking, or if it's permitted (not
-in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow
-blocking. Like dma_alloc_coherent(), this returns two values: an
-address usable by the CPU, and the DMA address usable by the pool's
-device.
-
-::
-
- void
- dma_pool_free(struct dma_pool *pool, void *vaddr,
- dma_addr_t addr);
-
-This puts memory back into the pool. The pool is what was passed to
-dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what
-were returned when that routine allocated the memory being freed.
-
-::
-
- void
- dma_pool_destroy(struct dma_pool *pool);
-
-dma_pool_destroy() frees the resources of the pool. It must be
-called in a context which can sleep. Make sure you've freed all allocated
-memory back to the pool before you destroy it.
+.. kernel-doc:: include/linux/dmapool.h
Part Ic - DMA addressing limitations
------------------------------------
+DMA mask is a bit mask of the addressable region for the device. In other words,
+if applying the DMA mask (a bitwise AND operation) to the DMA address of a
+memory region does not clear any bits in the address, then the device can
+perform DMA to that memory region.
+
+All the below functions which set a DMA mask may fail if the requested mask
+cannot be used with the device, or if the device is not capable of doing DMA.
+
::
int
dma_set_mask_and_coherent(struct device *dev, u64 mask)
-Checks to see if the mask is possible and updates the device
-streaming and coherent DMA mask parameters if it is.
+Updates both streaming and coherent DMA masks.
Returns: 0 if successful and a negative error if not.
@@ -165,8 +114,7 @@ Returns: 0 if successful and a negative error if not.
int
dma_set_mask(struct device *dev, u64 mask)
-Checks to see if the mask is possible and updates the device
-parameters if it is.
+Updates only the streaming DMA mask.
Returns: 0 if successful and a negative error if not.
@@ -175,8 +123,7 @@ Returns: 0 if successful and a negative error if not.
int
dma_set_coherent_mask(struct device *dev, u64 mask)
-Checks to see if the mask is possible and updates the device
-parameters if it is.
+Updates only the coherent DMA mask.
Returns: 0 if successful and a negative error if not.
@@ -231,12 +178,32 @@ transfer memory ownership. Returns %false if those calls can be skipped.
unsigned long
dma_get_merge_boundary(struct device *dev);
-Returns the DMA merge boundary. If the device cannot merge any the DMA address
+Returns the DMA merge boundary. If the device cannot merge any DMA address
segments, the function returns 0.
Part Id - Streaming DMA mappings
--------------------------------
+Streaming DMA allows to map an existing buffer for DMA transfers and then
+unmap it when finished. Map functions are not guaranteed to succeed, so the
+return value must be checked.
+
+.. note::
+
+ In particular, mapping may fail for memory not addressable by the
+ device, e.g. if it is not within the DMA mask of the device and/or a
+ connecting bus bridge. Streaming DMA functions try to overcome such
+ addressing constraints, either by using an IOMMU (a device which maps
+ I/O DMA addresses to physical memory addresses), or by copying the
+ data to/from a bounce buffer if the kernel is configured with a
+ :doc:`SWIOTLB <swiotlb>`. However, these methods are not always
+ available, and even if they are, they may still fail for a number of
+ reasons.
+
+ In short, a device driver may need to be wary of where buffers are
+ located in physical memory, especially if the DMA mask is less than 32
+ bits.
+
::
dma_addr_t
@@ -246,9 +213,7 @@ Part Id - Streaming DMA mappings
Maps a piece of processor virtual memory so it can be accessed by the
device and returns the DMA address of the memory.
-The direction for both APIs may be converted freely by casting.
-However the dma_API uses a strongly typed enumerator for its
-direction:
+The DMA API uses a strongly typed enumerator for its direction:
======================= =============================================
DMA_NONE no direction (used for debugging)
@@ -259,31 +224,13 @@ DMA_BIDIRECTIONAL direction isn't known
.. note::
- Not all memory regions in a machine can be mapped by this API.
- Further, contiguous kernel virtual space may not be contiguous as
+ Contiguous kernel virtual space may not be contiguous as
physical memory. Since this API does not provide any scatter/gather
capability, it will fail if the user tries to map a non-physically
contiguous piece of memory. For this reason, memory to be mapped by
this API should be obtained from sources which guarantee it to be
physically contiguous (like kmalloc).
- Further, the DMA address of the memory must be within the
- dma_mask of the device (the dma_mask is a bit mask of the
- addressable region for the device, i.e., if the DMA address of
- the memory ANDed with the dma_mask is still equal to the DMA
- address, then the device can perform DMA to the memory). To
- ensure that the memory allocated by kmalloc is within the dma_mask,
- the driver may specify various platform-dependent flags to restrict
- the DMA address range of the allocation (e.g., on x86, GFP_DMA
- guarantees to be within the first 16MB of available DMA addresses,
- as required by ISA devices).
-
- Note also that the above constraints on physical contiguity and
- dma_mask may not apply if the platform has an IOMMU (a device which
- maps an I/O DMA address to a physical memory address). However, to be
- portable, device driver writers may *not* assume that such an IOMMU
- exists.
-
.. warning::
Memory coherency operates at a granularity called the cache
@@ -325,8 +272,7 @@ DMA_BIDIRECTIONAL direction isn't known
enum dma_data_direction direction)
Unmaps the region previously mapped. All the parameters passed in
-must be identical to those passed in (and returned) by the mapping
-API.
+must be identical to those passed to (and returned by) dma_map_single().
::
@@ -376,10 +322,10 @@ action (e.g. reduce current DMA mapping usage or delay and try again later).
dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction)
-Returns: the number of DMA address segments mapped (this may be shorter
-than <nents> passed in if some elements of the scatter/gather list are
-physically or virtually adjacent and an IOMMU maps them with a single
-entry).
+Maps a scatter/gather list for DMA. Returns the number of DMA address segments
+mapped, which may be smaller than <nents> passed in if several consecutive
+sglist entries are merged (e.g. with an IOMMU, or if some adjacent segments
+just happen to be physically contiguous).
Please note that the sg cannot be mapped again if it has been mapped once.
The mapping process is allowed to destroy information in the sg.
@@ -403,9 +349,8 @@ With scatterlists, you use the resulting mapping like this::
where nents is the number of entries in the sglist.
The implementation is free to merge several consecutive sglist entries
-into one (e.g. with an IOMMU, or if several pages just happen to be
-physically contiguous) and returns the actual number of sg entries it
-mapped them to. On failure 0, is returned.
+into one. The returned number is the actual number of sg entries it
+mapped them to. On failure, 0 is returned.
Then you should loop count times (note: this can be less than nents times)
and use sg_dma_address() and sg_dma_len() macros where you previously
@@ -448,7 +393,7 @@ DMA address entries returned.
Synchronise a single contiguous or scatter/gather mapping for the CPU
and device. With the sync_sg API, all the parameters must be the same
-as those passed into the single mapping API. With the sync_single API,
+as those passed into the sg mapping API. With the sync_single API,
you can use dma_handle and size parameters that aren't identical to
those passed into the single mapping API to do a partial sync.
@@ -530,6 +475,77 @@ routines, e.g.:::
....
}
+Part Ie - IOVA-based DMA mappings
+---------------------------------
+
+These APIs allow a very efficient mapping when using an IOMMU. They are an
+optional path that requires extra code and are only recommended for drivers
+where DMA mapping performance, or the space usage for storing the DMA addresses
+matter. All the considerations from the previous section apply here as well.
+
+::
+
+ bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
+ phys_addr_t phys, size_t size);
+
+Is used to try to allocate IOVA space for mapping operation. If it returns
+false this API can't be used for the given device and the normal streaming
+DMA mapping API should be used. The ``struct dma_iova_state`` is allocated
+by the driver and must be kept around until unmap time.
+
+::
+
+ static inline bool dma_use_iova(struct dma_iova_state *state)
+
+Can be used by the driver to check if the IOVA-based API is used after a
+call to dma_iova_try_alloc. This can be useful in the unmap path.
+
+::
+
+ int dma_iova_link(struct device *dev, struct dma_iova_state *state,
+ phys_addr_t phys, size_t offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs);
+
+Is used to link ranges to the IOVA previously allocated. The start of all
+but the first call to dma_iova_link for a given state must be aligned
+to the DMA merge boundary returned by ``dma_get_merge_boundary())``, and
+the size of all but the last range must be aligned to the DMA merge boundary
+as well.
+
+::
+
+ int dma_iova_sync(struct device *dev, struct dma_iova_state *state,
+ size_t offset, size_t size);
+
+Must be called to sync the IOMMU page tables for IOVA-range mapped by one or
+more calls to ``dma_iova_link()``.
+
+For drivers that use a one-shot mapping, all ranges can be unmapped and the
+IOVA freed by calling:
+
+::
+
+ void dma_iova_destroy(struct device *dev, struct dma_iova_state *state,
+ size_t mapped_len, enum dma_data_direction dir,
+ unsigned long attrs);
+
+Alternatively drivers can dynamically manage the IOVA space by unmapping
+and mapping individual regions. In that case
+
+::
+
+ void dma_iova_unlink(struct device *dev, struct dma_iova_state *state,
+ size_t offset, size_t size, enum dma_data_direction dir,
+ unsigned long attrs);
+
+is used to unmap a range previously mapped, and
+
+::
+
+ void dma_iova_free(struct device *dev, struct dma_iova_state *state);
+
+is used to free the IOVA space. All regions must have been unmapped using
+``dma_iova_unlink()`` before calling ``dma_iova_free()``.
Part II - Non-coherent DMA allocations
--------------------------------------
@@ -704,19 +720,19 @@ memory or doing partial flushes.
of two for easy alignment.
-Part III - Debug drivers use of the DMA-API
+Part III - Debug drivers use of the DMA API
-------------------------------------------
-The DMA-API as described above has some constraints. DMA addresses must be
+The DMA API as described above has some constraints. DMA addresses must be
released with the corresponding function with the same size for example. With
the advent of hardware IOMMUs it becomes more and more important that drivers
do not violate those constraints. In the worst case such a violation can
result in data corruption up to destroyed filesystems.
-To debug drivers and find bugs in the usage of the DMA-API checking code can
+To debug drivers and find bugs in the usage of the DMA API checking code can
be compiled into the kernel which will tell the developer about those
violations. If your architecture supports it you can select the "Enable
-debugging of DMA-API usage" option in your kernel configuration. Enabling this
+debugging of DMA API usage" option in your kernel configuration. Enabling this
option has a performance impact. Do not enable it in production kernels.
If you boot the resulting kernel will contain code which does some bookkeeping
@@ -745,7 +761,7 @@ example warning message may look like this::
[<ffffffff80235177>] find_busiest_group+0x207/0x8a0
[<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
[<ffffffff803c7ea3>] check_unmap+0x203/0x490
- [<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
+ [<ffffffff803c8259>] debug_dma_unmap_phys+0x49/0x50
[<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
[<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
[<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
@@ -755,7 +771,7 @@ example warning message may look like this::
<EOI> <4>---[ end trace f6435a98e2a38c0e ]---
The driver developer can find the driver and the device including a stacktrace
-of the DMA-API call which caused this warning.
+of the DMA API call which caused this warning.
Per default only the first error will result in a warning message. All other
errors will only silently counted. This limitation exist to prevent the code
@@ -763,7 +779,7 @@ from flooding your kernel log. To support debugging a device driver this can
be disabled via debugfs. See the debugfs interface documentation below for
details.
-The debugfs directory for the DMA-API debugging code is called dma-api/. In
+The debugfs directory for the DMA API debugging code is called dma-api/. In
this directory the following files can currently be found:
=============================== ===============================================
@@ -811,7 +827,7 @@ dma-api/driver_filter You can write a name of a driver into this file
If you have this code compiled into your kernel it will be enabled by default.
If you want to boot without the bookkeeping anyway you can provide
-'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
+'dma_debug=off' as a boot parameter. This will disable DMA API debugging.
Notice that you can not enable it again at runtime. You have to reboot to do
so.
@@ -839,8 +855,14 @@ that a driver may be leaking mappings.
dma-debug interface debug_dma_mapping_error() to debug drivers that fail
to check DMA mapping errors on addresses returned by dma_map_single() and
dma_map_page() interfaces. This interface clears a flag set by
-debug_dma_map_page() to indicate that dma_mapping_error() has been called by
+debug_dma_map_phys() to indicate that dma_mapping_error() has been called by
the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
this flag is still set, prints warning message that includes call trace that
leads up to the unmap. This interface can be called from dma_mapping_error()
routines to enable DMA mapping error check debugging.
+
+Functions and structures
+========================
+
+.. kernel-doc:: include/linux/scatterlist.h
+.. kernel-doc:: lib/scatterlist.c
diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
index 1887d92e8e92..0bdc2be65e57 100644
--- a/Documentation/core-api/dma-attributes.rst
+++ b/Documentation/core-api/dma-attributes.rst
@@ -130,3 +130,21 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged
subsystem that the buffer is fully accessible at the elevated privilege
level (and ideally inaccessible or at least read-only at the
lesser-privileged levels).
+
+DMA_ATTR_MMIO
+-------------
+
+This attribute indicates the physical address is not normal system
+memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page()
+functions, it may not be cacheable, and access using CPU load/store
+instructions may not be allowed.
+
+Usually this will be used to describe MMIO addresses, or other non-cacheable
+register addresses. When DMA mapping this sort of address we call
+the operation Peer to Peer as a one device is DMA'ing to another device.
+For PCI devices the p2pdma APIs must be used to determine if
+DMA_ATTR_MMIO is appropriate.
+
+For architectures that require cache flushing for DMA coherence
+DMA_ATTR_MMIO will not perform any cache flushing. The address
+provided must never be mapped cacheable into the CPU.
diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst
index e12f22ab33c7..71d8eedc0549 100644
--- a/Documentation/core-api/entry.rst
+++ b/Documentation/core-api/entry.rst
@@ -18,7 +18,7 @@ exceptions`_, `NMI and NMI-like exceptions`_.
Non-instrumentable code - noinstr
---------------------------------
-Most instrumentation facilities depend on RCU, so intrumentation is prohibited
+Most instrumentation facilities depend on RCU, so instrumentation is prohibited
for entry code before RCU starts watching and exit code after RCU stops
watching. In addition, many architectures must save and restore register state,
which means that (for example) a breakpoint in the breakpoint entry code would
@@ -105,7 +105,7 @@ has to do extra work between the various steps. In such cases it has to
ensure that enter_from_user_mode() is called first on entry and
exit_to_user_mode() is called last on exit.
-Do not nest syscalls. Nested systcalls will cause RCU and/or context tracking
+Do not nest syscalls. Nested syscalls will cause RCU and/or context tracking
to print a warning.
KVM
@@ -115,8 +115,8 @@ Entering or exiting guest mode is very similar to syscalls. From the host
kernel point of view the CPU goes off into user space when entering the
guest and returns to the kernel on exit.
-kvm_guest_enter_irqoff() is a KVM-specific variant of exit_to_user_mode()
-and kvm_guest_exit_irqoff() is the KVM variant of enter_from_user_mode().
+guest_state_enter_irqoff() is a KVM-specific variant of exit_to_user_mode()
+and guest_state_exit_irqoff() is the KVM variant of enter_from_user_mode().
The state operations have the same ordering.
Task work handling is done separately for guest at the boundary of the
diff --git a/Documentation/core-api/floating-point.rst b/Documentation/core-api/floating-point.rst
new file mode 100644
index 000000000000..a8d0d4b05052
--- /dev/null
+++ b/Documentation/core-api/floating-point.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Floating-point API
+==================
+
+Kernel code is normally prohibited from using floating-point (FP) registers or
+instructions, including the C float and double data types. This rule reduces
+system call overhead, because the kernel does not need to save and restore the
+userspace floating-point register state.
+
+However, occasionally drivers or library functions may need to include FP code.
+This is supported by isolating the functions containing FP code to a separate
+translation unit (a separate source file), and saving/restoring the FP register
+state around calls to those functions. This creates "critical sections" of
+floating-point usage.
+
+The reason for this isolation is to prevent the compiler from generating code
+touching the FP registers outside these critical sections. Compilers sometimes
+use FP registers to optimize inlined ``memcpy`` or variable assignment, as
+floating-point registers may be wider than general-purpose registers.
+
+Usability of floating-point code within the kernel is architecture-specific.
+Additionally, because a single kernel may be configured to support platforms
+both with and without a floating-point unit, FPU availability must be checked
+both at build time and at run time.
+
+Several architectures implement the generic kernel floating-point API from
+``linux/fpu.h``, as described below. Some other architectures implement their
+own unique APIs, which are documented separately.
+
+Build-time API
+--------------
+
+Floating-point code may be built if the option ``ARCH_HAS_KERNEL_FPU_SUPPORT``
+is enabled. For C code, such code must be placed in a separate file, and that
+file must have its compilation flags adjusted using the following pattern::
+
+ CFLAGS_foo.o += $(CC_FLAGS_FPU)
+ CFLAGS_REMOVE_foo.o += $(CC_FLAGS_NO_FPU)
+
+Architectures are expected to define one or both of these variables in their
+top-level Makefile as needed. For example::
+
+ CC_FLAGS_FPU := -mhard-float
+
+or::
+
+ CC_FLAGS_NO_FPU := -msoft-float
+
+Normal kernel code is assumed to use the equivalent of ``CC_FLAGS_NO_FPU``.
+
+Runtime API
+-----------
+
+The runtime API is provided in ``linux/fpu.h``. This header cannot be included
+from files implementing FP code (those with their compilation flags adjusted as
+above). Instead, it must be included when defining the FP critical sections.
+
+.. c:function:: bool kernel_fpu_available( void )
+
+ This function reports if floating-point code can be used on this CPU or
+ platform. The value returned by this function is not expected to change
+ at runtime, so it only needs to be called once, not before every
+ critical section.
+
+.. c:function:: void kernel_fpu_begin( void )
+ void kernel_fpu_end( void )
+
+ These functions create a floating-point critical section. It is only
+ valid to call ``kernel_fpu_begin()`` after a previous call to
+ ``kernel_fpu_available()`` returned ``true``. These functions are only
+ guaranteed to be callable from (preemptible or non-preemptible) process
+ context.
+
+ Preemption may be disabled inside critical sections, so their size
+ should be minimized. They are *not* required to be reentrant. If the
+ caller expects to nest critical sections, it must implement its own
+ reference counting.
diff --git a/Documentation/core-api/folio_queue.rst b/Documentation/core-api/folio_queue.rst
new file mode 100644
index 000000000000..b7628896d2b6
--- /dev/null
+++ b/Documentation/core-api/folio_queue.rst
@@ -0,0 +1,209 @@
+.. 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 these 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);
+
+Cleared by::
+
+ void folioq_unmark(struct folio_queue *folioq, unsigned int slot);
+ void folioq_unmark2(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);
+
+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
diff --git a/Documentation/core-api/genericirq.rst b/Documentation/core-api/genericirq.rst
index f959c9b53f61..582bde9bf5a9 100644
--- a/Documentation/core-api/genericirq.rst
+++ b/Documentation/core-api/genericirq.rst
@@ -210,7 +210,7 @@ implemented (simplified excerpt)::
}
}
- noop(struct irq_data *data))
+ noop(struct irq_data *data)
{
}
@@ -264,7 +264,7 @@ The following control flow is implemented (simplified excerpt)::
desc->irq_data.chip->irq_unmask();
desc->status &= ~pending;
handle_irq_event(desc->action);
- } while (status & pending);
+ } while (desc->status & pending);
desc->status &= ~running;
diff --git a/Documentation/core-api/gfp_mask-from-fs-io.rst b/Documentation/core-api/gfp_mask-from-fs-io.rst
index e7c32a8de126..858b2fbcb36c 100644
--- a/Documentation/core-api/gfp_mask-from-fs-io.rst
+++ b/Documentation/core-api/gfp_mask-from-fs-io.rst
@@ -55,14 +55,16 @@ scope.
What about __vmalloc(GFP_NOFS)
==============================
-vmalloc doesn't support GFP_NOFS semantic because there are hardcoded
-GFP_KERNEL allocations deep inside the allocator which are quite non-trivial
-to fix up. That means that calling ``vmalloc`` with GFP_NOFS/GFP_NOIO is
-almost always a bug. The good news is that the NOFS/NOIO semantic can be
-achieved by the scope API.
+Since v5.17, and specifically after the commit 451769ebb7e79 ("mm/vmalloc:
+alloc GFP_NO{FS,IO} for vmalloc"), GFP_NOFS/GFP_NOIO are now supported in
+``[k]vmalloc`` by implicitly using scope API.
+
+In earlier kernels ``vmalloc`` didn't support GFP_NOFS semantic because there
+were hardcoded GFP_KERNEL allocations deep inside the allocator. That means
+that calling ``vmalloc`` with GFP_NOFS/GFP_NOIO was almost always a bug.
In the ideal world, upper layers should already mark dangerous contexts
-and so no special care is required and vmalloc should be called without
-any problems. Sometimes if the context is not really clear or there are
-layering violations then the recommended way around that is to wrap ``vmalloc``
-by the scope API with a comment explaining the problem.
+and so no special care is required and ``vmalloc`` should be called without any
+problems. Sometimes if the context is not really clear or there are layering
+violations then the recommended way around that (on pre-v5.17 kernels) is to
+wrap ``vmalloc`` by the scope API with a comment explaining the problem.
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index b0e7b4771fff..5eb0fbbbc323 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -24,6 +24,7 @@ it.
printk-index
symbol-namespaces
asm-annotations
+ real-time/index
Data structures and low-level utilities
=======================================
@@ -35,8 +36,11 @@ Library functionality that is used throughout the kernel.
kobject
kref
+ cleanup
assoc_array
+ folio_queue
xarray
+ maple_tree
idr
circular-buffers
rbtree
@@ -47,6 +51,11 @@ Library functionality that is used throughout the kernel.
errseq
wrappers/atomic_t
wrappers/atomic_bitops
+ floating-point
+ union_find
+ min_heap
+ parser
+ list
Low level entry and exit
========================
@@ -101,11 +110,14 @@ more memory-management documentation in Documentation/mm/index.rst.
dma-api-howto
dma-attributes
dma-isa-lpc
+ swiotlb
mm-api
+ cgroup
genalloc
pin_user_pages
boot-time-mm
gfp_mask-from-fs-io
+ kho/index
Interfaces for kernel debugging
===============================
@@ -126,6 +138,8 @@ Documents that don't fit elsewhere or which have yet to be categorized.
:maxdepth: 1
librs
+ liveupdate
+ netlink
.. only:: subproject and html
diff --git a/Documentation/core-api/irq/concepts.rst b/Documentation/core-api/irq/concepts.rst
index 4273806a606b..7c4564f3cbdf 100644
--- a/Documentation/core-api/irq/concepts.rst
+++ b/Documentation/core-api/irq/concepts.rst
@@ -2,23 +2,24 @@
What is an IRQ?
===============
-An IRQ is an interrupt request from a device.
-Currently they can come in over a pin, or over a packet.
-Several devices may be connected to the same pin thus
-sharing an IRQ.
+An IRQ is an interrupt request from a device. Currently, they can come
+in over a pin, or over a packet. Several devices may be connected to
+the same pin thus sharing an IRQ. Such as on legacy PCI bus: All devices
+typically share 4 lanes/pins. Note that each device can request an
+interrupt on each of the lanes.
An IRQ number is a kernel identifier used to talk about a hardware
-interrupt source. Typically this is an index into the global irq_desc
-array, but except for what linux/interrupt.h implements the details
-are architecture specific.
+interrupt source. Typically, this is an index into the global irq_desc
+array or sparse_irqs tree. But except for what linux/interrupt.h
+implements, the details are architecture specific.
An IRQ number is an enumeration of the possible interrupt sources on a
-machine. Typically what is enumerated is the number of input pins on
-all of the interrupt controller in the system. In the case of ISA
-what is enumerated are the 16 input pins on the two i8259 interrupt
-controllers.
+machine. Typically, what is enumerated is the number of input pins on
+all of the interrupt controllers in the system. In the case of ISA,
+what is enumerated are the 8 input pins on each of the two i8259
+interrupt controllers.
Architectures can assign additional meaning to the IRQ numbers, and
-are encouraged to in the case where there is any manual configuration
-of the hardware involved. The ISA IRQs are a classic example of
+are encouraged to in the case where there is any manual configuration
+of the hardware involved. The ISA IRQs are a classic example of
assigning this kind of additional meaning.
diff --git a/Documentation/core-api/irq/irq-affinity.rst b/Documentation/core-api/irq/irq-affinity.rst
index 29da5000836a..9cb460cf60b6 100644
--- a/Documentation/core-api/irq/irq-affinity.rst
+++ b/Documentation/core-api/irq/irq-affinity.rst
@@ -9,9 +9,9 @@ ChangeLog:
/proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify
which target CPUs are permitted for a given IRQ source. It's a bitmask
-(smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs. It's not
+(smp_affinity) or CPU list (smp_affinity_list) of allowed CPUs. It's not
allowed to turn off all CPUs, and if an IRQ controller does not support
-IRQ affinity then the value will not change from the default of all cpus.
+IRQ affinity then the value will not change from the default of all CPUs.
/proc/irq/default_smp_affinity specifies default affinity mask that applies
to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask
@@ -60,7 +60,7 @@ Now lets restrict that IRQ to CPU(4-7).
This time around IRQ44 was delivered only to the last four processors.
i.e counters for the CPU0-3 did not change.
-Here is an example of limiting that same irq (44) to cpus 1024 to 1031::
+Here is an example of limiting that same IRQ (44) to CPUs 1024 to 1031::
[root@moon 44]# echo 1024-1031 > smp_affinity_list
[root@moon 44]# cat smp_affinity_list
diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst
index f88a6ee67a35..68eb2612e8a4 100644
--- a/Documentation/core-api/irq/irq-domain.rst
+++ b/Documentation/core-api/irq/irq-domain.rst
@@ -1,75 +1,91 @@
===============================================
-The irq_domain interrupt number mapping library
+The irq_domain Interrupt Number Mapping Library
===============================================
The current design of the Linux kernel uses a single large number
-space where each separate IRQ source is assigned a different number.
-This is simple when there is only one interrupt controller, but in
-systems with multiple interrupt controllers the kernel must ensure
+space where each separate IRQ source is assigned a unique number.
+This is simple when there is only one interrupt controller. But in
+systems with multiple interrupt controllers, the kernel must ensure
that each one gets assigned non-overlapping allocations of Linux
IRQ numbers.
The number of interrupt controllers registered as unique irqchips
-show a rising tendency: for example subdrivers of different kinds
+shows a rising tendency. For example, subdrivers of different kinds
such as GPIO controllers avoid reimplementing identical callback
mechanisms as the IRQ core system by modelling their interrupt
-handlers as irqchips, i.e. in effect cascading interrupt controllers.
+handlers as irqchips. I.e. in effect cascading interrupt controllers.
-Here the interrupt number loose all kind of correspondence to
-hardware interrupt numbers: whereas in the past, IRQ numbers could
-be chosen so they matched the hardware IRQ line into the root
-interrupt controller (i.e. the component actually fireing the
-interrupt line to the CPU) nowadays this number is just a number.
+So in the past, IRQ numbers could be chosen so that they match the
+hardware IRQ line into the root interrupt controller (i.e. the
+component actually firing the interrupt line to the CPU). Nowadays,
+this number is just a number and the number has no
+relationship to hardware interrupt numbers.
-For this reason we need a mechanism to separate controller-local
-interrupt numbers, called hardware irq's, from Linux IRQ numbers.
+For this reason, we need a mechanism to separate controller-local
+interrupt numbers, called hardware IRQs, from Linux IRQ numbers.
The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
-irq numbers, but they don't provide any support for reverse mapping of
+IRQ numbers, but they don't provide any support for reverse mapping of
the controller-local IRQ (hwirq) number into the Linux IRQ number
space.
-The irq_domain library adds mapping between hwirq and IRQ numbers on
-top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
-preferred over interrupt controller drivers open coding their own
+The irq_domain library adds a mapping between hwirq and IRQ numbers on
+top of the irq_alloc_desc*() API. An irq_domain to manage the mapping
+is preferred over interrupt controller drivers open coding their own
reverse mapping scheme.
-irq_domain also implements translation from an abstract irq_fwspec
-structure to hwirq numbers (Device Tree and ACPI GSI so far), and can
-be easily extended to support other IRQ topology data sources.
+irq_domain also implements a translation from an abstract struct
+irq_fwspec to hwirq numbers (Device Tree, non-DT firmware node, ACPI
+GSI, and software node so far), and can be easily extended to support
+other IRQ topology data sources. The implementation is performed
+without any extra platform support code.
-irq_domain usage
+irq_domain Usage
================
-
-An interrupt controller driver creates and registers an irq_domain by
-calling one of the irq_domain_add_*() or irq_domain_create_*() functions
-(each mapping method has a different allocator function, more on that later).
-The function will return a pointer to the irq_domain on success. The caller
-must provide the allocator function with an irq_domain_ops structure.
+struct irq_domain could be defined as an irq domain controller. That
+is, it handles the mapping between hardware and virtual interrupt
+numbers for a given interrupt domain. The domain structure is
+generally created by the PIC code for a given PIC instance (though a
+domain can cover more than one PIC if they have a flat number model).
+It is the domain callbacks that are responsible for setting the
+irq_chip on a given irq_desc after it has been mapped.
+
+The host code and data structures use a fwnode_handle pointer to
+identify the domain. In some cases, and in order to preserve source
+code compatibility, this fwnode pointer is "upgraded" to a DT
+device_node. For those firmware infrastructures that do not provide a
+unique identifier for an interrupt controller, the irq_domain code
+offers a fwnode allocator.
+
+An interrupt controller driver creates and registers a struct irq_domain
+by calling one of the irq_domain_create_*() functions (each mapping
+method has a different allocator function, more on that later). The
+function will return a pointer to the struct irq_domain on success. The
+caller must provide the allocator function with a struct irq_domain_ops
+pointer.
In most cases, the irq_domain will begin empty without any mappings
between hwirq and IRQ numbers. Mappings are added to the irq_domain
by calling irq_create_mapping() which accepts the irq_domain and a
-hwirq number as arguments. If a mapping for the hwirq doesn't already
-exist then it will allocate a new Linux irq_desc, associate it with
-the hwirq, and call the .map() callback so the driver can perform any
-required hardware setup.
+hwirq number as arguments. If a mapping for the hwirq doesn't already
+exist, irq_create_mapping() allocates a new Linux irq_desc, associates
+it with the hwirq, and calls the :c:member:`irq_domain_ops.map()`
+callback. In there, the driver can perform any required hardware
+setup.
Once a mapping has been established, it can be retrieved or used via a
variety of methods:
- irq_resolve_mapping() returns a pointer to the irq_desc structure
- for a given domain and hwirq number, and NULL if there was no
+ for a given domain and hwirq number, or NULL if there was no
mapping.
- irq_find_mapping() returns a Linux IRQ number for a given domain and
- hwirq number, and 0 if there was no mapping
-- irq_linear_revmap() is now identical to irq_find_mapping(), and is
- deprecated
+ hwirq number, or 0 if there was no mapping
- generic_handle_domain_irq() handles an interrupt described by a
domain and a hwirq number
-Note that irq domain lookups must happen in contexts that are
-compatible with a RCU read-side critical section.
+Note that irq_domain lookups must happen in contexts that are
+compatible with an RCU read-side critical section.
The irq_create_mapping() function must be called *at least once*
before any call to irq_find_mapping(), lest the descriptor will not
@@ -77,13 +93,14 @@ be allocated.
If the driver has the Linux IRQ number or the irq_data pointer, and
needs to know the associated hwirq number (such as in the irq_chip
-callbacks) then it can be directly obtained from irq_data->hwirq.
+callbacks) then it can be directly obtained from
+:c:member:`irq_data.hwirq`.
-Types of irq_domain mappings
+Types of irq_domain Mappings
============================
There are several mechanisms available for reverse mapping from hwirq
-to Linux irq, and each mechanism uses a different allocation function.
+to Linux IRQ, and each mechanism uses a different allocation function.
Which reverse map type should be used depends on the use case. Each
of the reverse map types are described below:
@@ -92,48 +109,36 @@ Linear
::
- irq_domain_add_linear()
irq_domain_create_linear()
-The linear reverse map maintains a fixed size table indexed by the
+The linear reverse map maintains a fixed-size table indexed by the
hwirq number. When a hwirq is mapped, an irq_desc is allocated for
the hwirq, and the IRQ number is stored in the table.
The Linear map is a good choice when the maximum number of hwirqs is
fixed and a relatively small number (~ < 256). The advantages of this
-map are fixed time lookup for IRQ numbers, and irq_descs are only
+map are fixed-time lookup for IRQ numbers, and irq_descs are only
allocated for in-use IRQs. The disadvantage is that the table must be
as large as the largest possible hwirq number.
-irq_domain_add_linear() and irq_domain_create_linear() are functionally
-equivalent, except for the first argument is different - the former
-accepts an Open Firmware specific 'struct device_node', while the latter
-accepts a more general abstraction 'struct fwnode_handle'.
-
-The majority of drivers should use the linear map.
+The majority of drivers should use the Linear map.
Tree
----
::
- irq_domain_add_tree()
irq_domain_create_tree()
The irq_domain maintains a radix tree map from hwirq numbers to Linux
IRQs. When an hwirq is mapped, an irq_desc is allocated and the
hwirq is used as the lookup key for the radix tree.
-The tree map is a good choice if the hwirq number can be very large
+The Tree map is a good choice if the hwirq number can be very large
since it doesn't need to allocate a table as large as the largest
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
dependent on how many entries are in the table.
-irq_domain_add_tree() and irq_domain_create_tree() are functionally
-equivalent, except for the first argument is different - the former
-accepts an Open Firmware specific 'struct device_node', while the latter
-accepts a more general abstraction 'struct fwnode_handle'.
-
Very few drivers should need this mapping.
No Map
@@ -141,7 +146,7 @@ No Map
::
- irq_domain_add_nomap()
+ irq_domain_create_nomap()
The No Map mapping is to be used when the hwirq number is
programmable in the hardware. In this case it is best to program the
@@ -159,17 +164,15 @@ Legacy
::
- irq_domain_add_simple()
- irq_domain_add_legacy()
irq_domain_create_simple()
irq_domain_create_legacy()
The Legacy mapping is a special case for drivers that already have a
range of irq_descs allocated for the hwirqs. It is used when the
-driver cannot be immediately converted to use the linear mapping. For
+driver cannot be immediately converted to use the Linear mapping. For
example, many embedded system board support files use a set of #defines
for IRQ numbers that are passed to struct device registrations. In that
-case the Linux IRQ numbers cannot be dynamically assigned and the legacy
+case the Linux IRQ numbers cannot be dynamically assigned and the Legacy
mapping should be used.
As the name implies, the \*_legacy() functions are deprecated and only
@@ -177,25 +180,25 @@ exist to ease the support of ancient platforms. No new users should be
added. Same goes for the \*_simple() functions when their use results
in the legacy behaviour.
-The legacy map assumes a contiguous range of IRQ numbers has already
+The Legacy map assumes a contiguous range of IRQ numbers has already
been allocated for the controller and that the IRQ number can be
calculated by adding a fixed offset to the hwirq number, and
visa-versa. The disadvantage is that it requires the interrupt
controller to manage IRQ allocations and it requires an irq_desc to be
allocated for every hwirq, even if it is unused.
-The legacy map should only be used if fixed IRQ mappings must be
-supported. For example, ISA controllers would use the legacy map for
+The Legacy map should only be used if fixed IRQ mappings must be
+supported. For example, ISA controllers would use the Legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
-Most users of legacy mappings should use irq_domain_add_simple() or
-irq_domain_create_simple() which will use a legacy domain only if an IRQ range
-is supplied by the system and will otherwise use a linear domain mapping.
-The semantics of this call are such that if an IRQ range is specified then
-descriptors will be allocated on-the-fly for it, and if no range is
-specified it will fall through to irq_domain_add_linear() or
-irq_domain_create_linear() which means *no* irq descriptors will be allocated.
+Most users of legacy mappings should use irq_domain_create_simple()
+which will use a legacy domain only if an IRQ range is supplied by the
+system and will otherwise use a linear domain mapping. The semantics of
+this call are such that if an IRQ range is specified then descriptors
+will be allocated on-the-fly for it, and if no range is specified it
+will fall through to irq_domain_create_linear() which means *no* IRQ
+descriptors will be allocated.
A typical use case for simple domains is where an irqchip provider
is supporting both dynamic and static IRQ assignments.
@@ -206,18 +209,12 @@ that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
-irq_domain_add_simple() and irq_domain_create_simple() as well as
-irq_domain_add_legacy() and irq_domain_create_legacy() are functionally
-equivalent, except for the first argument is different - the former
-accepts an Open Firmware specific 'struct device_node', while the latter
-accepts a more general abstraction 'struct fwnode_handle'.
-
-Hierarchy IRQ domain
+Hierarchy IRQ Domain
--------------------
On some architectures, there may be multiple interrupt controllers
involved in delivering an interrupt from the device to the target CPU.
-Let's look at a typical interrupt delivering path on x86 platforms::
+Let's look at a typical interrupt delivery path on x86 platforms::
Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
@@ -230,8 +227,8 @@ There are three interrupt controllers involved:
To support such a hardware topology and make software architecture match
hardware architecture, an irq_domain data structure is built for each
interrupt controller and those irq_domains are organized into hierarchy.
-When building irq_domain hierarchy, the irq_domain near to the device is
-child and the irq_domain near to CPU is parent. So a hierarchy structure
+When building irq_domain hierarchy, the irq_domain nearest the device is
+child and the irq_domain nearest the CPU is parent. So a hierarchy structure
as below will be built for the example above::
CPU Vector irq_domain (root irq_domain to manage CPU vectors)
@@ -253,20 +250,40 @@ There are four major interfaces to use hierarchy irq_domain:
4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
to stop delivering the interrupt.
-Following changes are needed to support hierarchy irq_domain:
+The following is needed to support hierarchy irq_domain:
-1) a new field 'parent' is added to struct irq_domain; it's used to
+1) The :c:member:`parent` field in struct irq_domain is used to
maintain irq_domain hierarchy information.
-2) a new field 'parent_data' is added to struct irq_data; it's used to
- build hierarchy irq_data to match hierarchy irq_domains. The irq_data
- is used to store irq_domain pointer and hardware irq number.
-3) new callbacks are added to struct irq_domain_ops to support hierarchy
- irq_domain operations.
-
-With support of hierarchy irq_domain and hierarchy irq_data ready, an
-irq_domain structure is built for each interrupt controller, and an
+2) The :c:member:`parent_data` field in struct irq_data is used to
+ build hierarchy irq_data to match hierarchy irq_domains. The
+ irq_data is used to store irq_domain pointer and hardware irq
+ number.
+3) The :c:member:`alloc()`, :c:member:`free()`, and other callbacks in
+ struct irq_domain_ops to support hierarchy irq_domain operations.
+
+With the support of hierarchy irq_domain and hierarchy irq_data ready,
+an irq_domain structure is built for each interrupt controller, and an
irq_data structure is allocated for each irq_domain associated with an
-IRQ. Now we could go one step further to support stacked(hierarchy)
+IRQ.
+
+For an interrupt controller driver to support hierarchy irq_domain, it
+needs to:
+
+1) Implement irq_domain_ops.alloc() and irq_domain_ops.free()
+2) Optionally, implement irq_domain_ops.activate() and
+ irq_domain_ops.deactivate().
+3) Optionally, implement an irq_chip to manage the interrupt controller
+ hardware.
+4) There is no need to implement irq_domain_ops.map() and
+ irq_domain_ops.unmap(). They are unused with hierarchy irq_domain.
+
+Note the hierarchy irq_domain is in no way x86-specific, and is
+heavily used to support other architectures, such as ARM, ARM64 etc.
+
+Stacked irq_chip
+~~~~~~~~~~~~~~~~
+
+Now, we could go one step further to support stacked (hierarchy)
irq_chip. That is, an irq_chip is associated with each irq_data along
the hierarchy. A child irq_chip may implement a required action by
itself or by cooperating with its parent irq_chip.
@@ -276,22 +293,28 @@ with the hardware managed by itself and may ask for services from its
parent irq_chip when needed. So we could achieve a much cleaner
software architecture.
-For an interrupt controller driver to support hierarchy irq_domain, it
-needs to:
-
-1) Implement irq_domain_ops.alloc and irq_domain_ops.free
-2) Optionally implement irq_domain_ops.activate and
- irq_domain_ops.deactivate.
-3) Optionally implement an irq_chip to manage the interrupt controller
- hardware.
-4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
- they are unused with hierarchy irq_domain.
-
-Hierarchy irq_domain is in no way x86 specific, and is heavily used to
-support other architectures, such as ARM, ARM64 etc.
-
Debugging
=========
Most of the internals of the IRQ subsystem are exposed in debugfs by
turning CONFIG_GENERIC_IRQ_DEBUGFS on.
+
+Structures and Public Functions Provided
+========================================
+
+This chapter contains the autogenerated documentation of the structures
+and exported kernel API functions which are used for IRQ domains.
+
+.. kernel-doc:: include/linux/irqdomain.h
+
+.. kernel-doc:: kernel/irq/irqdomain.c
+ :export:
+
+Internal Functions Provided
+===========================
+
+This chapter contains the autogenerated documentation of the internal
+functions.
+
+.. kernel-doc:: kernel/irq/irqdomain.c
+ :internal:
diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst
index 0793c400d4b0..e8211c4ca662 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -3,12 +3,6 @@ The Linux Kernel API
====================
-List Management Functions
-=========================
-
-.. kernel-doc:: include/linux/list.h
- :internal:
-
Basic C Library Functions
=========================
@@ -36,6 +30,9 @@ String Conversions
String Manipulation
-------------------
+.. kernel-doc:: include/linux/fortify-string.h
+ :internal:
+
.. kernel-doc:: lib/string.c
:export:
@@ -93,6 +90,12 @@ Command-line Parsing
.. kernel-doc:: lib/cmdline.c
:export:
+Error Pointers
+--------------
+
+.. kernel-doc:: include/linux/err.h
+ :internal:
+
Sorting
-------
@@ -118,37 +121,47 @@ Text Searching
CRC and Math Functions in Linux
===============================
+Arithmetic Overflow Checking
+----------------------------
+
+.. kernel-doc:: include/linux/overflow.h
+ :internal:
+
CRC Functions
-------------
-.. kernel-doc:: lib/crc4.c
+.. kernel-doc:: lib/crc/crc4.c
:export:
-.. kernel-doc:: lib/crc7.c
+.. kernel-doc:: lib/crc/crc7.c
:export:
-.. kernel-doc:: lib/crc8.c
+.. kernel-doc:: lib/crc/crc8.c
:export:
-.. kernel-doc:: lib/crc16.c
+.. kernel-doc:: lib/crc/crc16.c
:export:
-.. kernel-doc:: lib/crc32.c
-
-.. kernel-doc:: lib/crc-ccitt.c
+.. kernel-doc:: lib/crc/crc-ccitt.c
:export:
-.. kernel-doc:: lib/crc-itu-t.c
+.. kernel-doc:: lib/crc/crc-itu-t.c
:export:
+.. kernel-doc:: include/linux/crc32.h
+
+.. kernel-doc:: include/linux/crc64.h
+
Base 2 log and power Functions
------------------------------
.. kernel-doc:: include/linux/log2.h
:internal:
-Integer power Functions
------------------------
+Integer log and power Functions
+-------------------------------
+
+.. kernel-doc:: include/linux/int_log.h
.. kernel-doc:: lib/math/int_pow.c
:export:
@@ -165,9 +178,6 @@ Division Functions
.. kernel-doc:: include/linux/math64.h
:internal:
-.. kernel-doc:: lib/math/div64.c
- :functions: div_s64_rem div64_u64_rem div64_u64 div64_s64
-
.. kernel-doc:: lib/math/gcd.c
:export:
@@ -214,12 +224,30 @@ relay interface
Module Support
==============
-Module Loading
---------------
+Kernel module auto-loading
+--------------------------
-.. kernel-doc:: kernel/kmod.c
+.. kernel-doc:: kernel/module/kmod.c
:export:
+Module debugging
+----------------
+
+.. kernel-doc:: kernel/module/stats.c
+ :doc: module debugging statistics overview
+
+dup_failed_modules - tracks duplicate failed modules
+****************************************************
+
+.. kernel-doc:: kernel/module/stats.c
+ :doc: dup_failed_modules - tracks duplicate failed modules
+
+module statistics debugfs counters
+**********************************
+
+.. kernel-doc:: kernel/module/stats.c
+ :doc: module statistics debugfs counters
+
Inter Module support
--------------------
@@ -388,3 +416,15 @@ Read-Copy Update (RCU)
.. kernel-doc:: include/linux/rcu_sync.h
.. kernel-doc:: kernel/rcu/sync.c
+
+.. kernel-doc:: kernel/rcu/tasks.h
+
+.. kernel-doc:: kernel/rcu/tree_stall.h
+
+.. kernel-doc:: include/linux/rcupdate_trace.h
+
+.. kernel-doc:: include/linux/rcupdate_wait.h
+
+.. kernel-doc:: include/linux/rcuref.h
+
+.. kernel-doc:: include/linux/rcutree.h
diff --git a/Documentation/core-api/kho/bindings/kho.yaml b/Documentation/core-api/kho/bindings/kho.yaml
new file mode 100644
index 000000000000..11e8ab7b219d
--- /dev/null
+++ b/Documentation/core-api/kho/bindings/kho.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+title: Kexec HandOver (KHO) root tree
+
+maintainers:
+ - Mike Rapoport <rppt@kernel.org>
+ - Changyuan Lyu <changyuanl@google.com>
+
+description: |
+ System memory preserved by KHO across kexec.
+
+properties:
+ compatible:
+ enum:
+ - kho-v1
+
+ preserved-memory-map:
+ description: |
+ physical address (u64) of an in-memory structure describing all preserved
+ folios and memory ranges.
+
+patternProperties:
+ "$[0-9a-f_]+^":
+ $ref: sub-fdt.yaml#
+ description: physical address of a KHO user's own FDT.
+
+required:
+ - compatible
+ - preserved-memory-map
+
+additionalProperties: false
+
+examples:
+ - |
+ kho {
+ compatible = "kho-v1";
+ preserved-memory-map = <0xf0be16 0x1000000>;
+
+ memblock {
+ fdt = <0x80cc16 0x1000000>;
+ };
+ };
diff --git a/Documentation/core-api/kho/bindings/memblock/memblock.yaml b/Documentation/core-api/kho/bindings/memblock/memblock.yaml
new file mode 100644
index 000000000000..d388c28eb91d
--- /dev/null
+++ b/Documentation/core-api/kho/bindings/memblock/memblock.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+title: Memblock reserved memory
+
+maintainers:
+ - Mike Rapoport <rppt@kernel.org>
+
+description: |
+ Memblock can serialize its current memory reservations created with
+ reserve_mem command line option across kexec through KHO.
+ The post-KHO kernel can then consume these reservations and they are
+ guaranteed to have the same physical address.
+
+properties:
+ compatible:
+ enum:
+ - reserve-mem-v1
+
+patternProperties:
+ "$[0-9a-f_]+^":
+ $ref: reserve-mem.yaml#
+ description: reserved memory regions
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ memblock {
+ compatible = "memblock-v1";
+ n1 {
+ compatible = "reserve-mem-v1";
+ start = <0xc06b 0x4000000>;
+ size = <0x04 0x00>;
+ };
+ };
diff --git a/Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml b/Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml
new file mode 100644
index 000000000000..10282d3d1bcd
--- /dev/null
+++ b/Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+title: Memblock reserved memory regions
+
+maintainers:
+ - Mike Rapoport <rppt@kernel.org>
+
+description: |
+ Memblock can serialize its current memory reservations created with
+ reserve_mem command line option across kexec through KHO.
+ This object describes each such region.
+
+properties:
+ compatible:
+ enum:
+ - reserve-mem-v1
+
+ start:
+ description: |
+ physical address (u64) of the reserved memory region.
+
+ size:
+ description: |
+ size (u64) of the reserved memory region.
+
+required:
+ - compatible
+ - start
+ - size
+
+additionalProperties: false
+
+examples:
+ - |
+ n1 {
+ compatible = "reserve-mem-v1";
+ start = <0xc06b 0x4000000>;
+ size = <0x04 0x00>;
+ };
diff --git a/Documentation/core-api/kho/bindings/sub-fdt.yaml b/Documentation/core-api/kho/bindings/sub-fdt.yaml
new file mode 100644
index 000000000000..b9a3d2d24850
--- /dev/null
+++ b/Documentation/core-api/kho/bindings/sub-fdt.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+title: KHO users' FDT address
+
+maintainers:
+ - Mike Rapoport <rppt@kernel.org>
+ - Changyuan Lyu <changyuanl@google.com>
+
+description: |
+ Physical address of an FDT blob registered by a KHO user.
+
+properties:
+ fdt:
+ description: |
+ physical address (u64) of an FDT blob.
+
+required:
+ - fdt
+
+additionalProperties: false
+
+examples:
+ - |
+ memblock {
+ fdt = <0x80cc16 0x1000000>;
+ };
diff --git a/Documentation/core-api/kho/concepts.rst b/Documentation/core-api/kho/concepts.rst
new file mode 100644
index 000000000000..d626d1dbd678
--- /dev/null
+++ b/Documentation/core-api/kho/concepts.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+.. _kho-concepts:
+
+=======================
+Kexec Handover Concepts
+=======================
+
+Kexec HandOver (KHO) is a mechanism that allows Linux to preserve memory
+regions, which could contain serialized system states, across kexec.
+
+It introduces multiple concepts:
+
+KHO FDT
+=======
+
+Every KHO kexec carries a KHO specific flattened device tree (FDT) blob
+that describes preserved memory regions. These regions contain either
+serialized subsystem states, or in-memory data that shall not be touched
+across kexec. After KHO, subsystems can retrieve and restore preserved
+memory regions from KHO FDT.
+
+KHO only uses the FDT container format and libfdt library, but does not
+adhere to the same property semantics that normal device trees do: Properties
+are passed in native endianness and standardized properties like ``regs`` and
+``ranges`` do not exist, hence there are no ``#...-cells`` properties.
+
+KHO is still under development. The FDT schema is unstable and would change
+in the future.
+
+Scratch Regions
+===============
+
+To boot into kexec, we need to have a physically contiguous memory range that
+contains no handed over memory. Kexec then places the target kernel and initrd
+into that region. The new kernel exclusively uses this region for memory
+allocations before during boot up to the initialization of the page allocator.
+
+We guarantee that we always have such regions through the scratch regions: On
+first boot KHO allocates several physically contiguous memory regions. Since
+after kexec these regions will be used by early memory allocations, there is a
+scratch region per NUMA node plus a scratch region to satisfy allocations
+requests that do not require particular NUMA node assignment.
+By default, size of the scratch region is calculated based on amount of memory
+allocated during boot. The ``kho_scratch`` kernel command line option may be
+used to explicitly define size of the scratch regions.
+The scratch regions are declared as CMA when page allocator is initialized so
+that their memory can be used during system lifetime. CMA gives us the
+guarantee that no handover pages land in that region, because handover pages
+must be at a static physical memory location and CMA enforces that only
+movable pages can be located inside.
+
+After KHO kexec, we ignore the ``kho_scratch`` kernel command line option and
+instead reuse the exact same region that was originally allocated. This allows
+us to recursively execute any amount of KHO kexecs. Because we used this region
+for boot memory allocations and as target memory for kexec blobs, some parts
+of that memory region may be reserved. These reservations are irrelevant for
+the next KHO, because kexec can overwrite even the original kernel.
+
+.. _kho-finalization-phase:
+
+KHO finalization phase
+======================
+
+To enable user space based kexec file loader, the kernel needs to be able to
+provide the FDT that describes the current kernel's state before
+performing the actual kexec. The process of generating that FDT is
+called serialization. When the FDT is generated, some properties
+of the system may become immutable because they are already written down
+in the FDT. That state is called the KHO finalization phase.
+
+Public API
+==========
+.. kernel-doc:: kernel/liveupdate/kexec_handover.c
+ :export:
diff --git a/Documentation/core-api/kho/fdt.rst b/Documentation/core-api/kho/fdt.rst
new file mode 100644
index 000000000000..62505285d60d
--- /dev/null
+++ b/Documentation/core-api/kho/fdt.rst
@@ -0,0 +1,80 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+=======
+KHO FDT
+=======
+
+KHO uses the flattened device tree (FDT) container format and libfdt
+library to create and parse the data that is passed between the
+kernels. The properties in KHO FDT are stored in native format.
+It includes the physical address of an in-memory structure describing
+all preserved memory regions, as well as physical addresses of KHO users'
+own FDTs. Interpreting those sub FDTs is the responsibility of KHO users.
+
+KHO nodes and properties
+========================
+
+Property ``preserved-memory-map``
+---------------------------------
+
+KHO saves a special property named ``preserved-memory-map`` under the root node.
+This node contains the physical address of an in-memory structure for KHO to
+preserve memory regions across kexec.
+
+Property ``compatible``
+-----------------------
+
+The ``compatible`` property determines compatibility between the kernel
+that created the KHO FDT and the kernel that attempts to load it.
+If the kernel that loads the KHO FDT is not compatible with it, the entire
+KHO process will be bypassed.
+
+Property ``fdt``
+----------------
+
+Generally, a KHO user serialize its state into its own FDT and instructs
+KHO to preserve the underlying memory, such that after kexec, the new kernel
+can recover its state from the preserved FDT.
+
+A KHO user thus can create a node in KHO root tree and save the physical address
+of its own FDT in that node's property ``fdt`` .
+
+Examples
+========
+
+The following example demonstrates KHO FDT that preserves two memory
+regions created with ``reserve_mem`` kernel command line parameter::
+
+ /dts-v1/;
+
+ / {
+ compatible = "kho-v1";
+
+ preserved-memory-map = <0x40be16 0x1000000>;
+
+ memblock {
+ fdt = <0x1517 0x1000000>;
+ };
+ };
+
+where the ``memblock`` node contains an FDT that is requested by the
+subsystem memblock for preservation. The FDT contains the following
+serialized data::
+
+ /dts-v1/;
+
+ / {
+ compatible = "memblock-v1";
+
+ n1 {
+ compatible = "reserve-mem-v1";
+ start = <0xc06b 0x4000000>;
+ size = <0x04 0x00>;
+ };
+
+ n2 {
+ compatible = "reserve-mem-v1";
+ start = <0xc067 0x4000000>;
+ size = <0x04 0x00>;
+ };
+ };
diff --git a/Documentation/core-api/kho/index.rst b/Documentation/core-api/kho/index.rst
new file mode 100644
index 000000000000..0c63b0c5c143
--- /dev/null
+++ b/Documentation/core-api/kho/index.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+========================
+Kexec Handover Subsystem
+========================
+
+.. toctree::
+ :maxdepth: 1
+
+ concepts
+ fdt
+
+.. only:: subproject and html
diff --git a/Documentation/core-api/kref.rst b/Documentation/core-api/kref.rst
index c61eea6f1bf2..8db9ff03d952 100644
--- a/Documentation/core-api/kref.rst
+++ b/Documentation/core-api/kref.rst
@@ -3,7 +3,7 @@ Adding reference counters (krefs) to kernel objects
===================================================
:Author: Corey Minyard <minyard@acm.org>
-:Author: Thomas Hellstrom <thellstrom@vmware.com>
+:Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
A lot of this was lifted from Greg Kroah-Hartman's 2004 OLS paper and
presentation on krefs, which can be found at:
@@ -321,3 +321,8 @@ rcu grace period after release_entry_rcu was called. That can be accomplished
by using kfree_rcu(entry, rhead) as done above, or by calling synchronize_rcu()
before using kfree, but note that synchronize_rcu() may sleep for a
substantial amount of time.
+
+Functions and structures
+========================
+
+.. kernel-doc:: include/linux/kref.h
diff --git a/Documentation/core-api/list.rst b/Documentation/core-api/list.rst
new file mode 100644
index 000000000000..86873ce9adbf
--- /dev/null
+++ b/Documentation/core-api/list.rst
@@ -0,0 +1,776 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+=====================
+Linked Lists in Linux
+=====================
+
+:Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+.. contents::
+
+Introduction
+============
+
+Linked lists are one of the most basic data structures used in many programs.
+The Linux kernel implements several different flavours of linked lists. The
+purpose of this document is not to explain linked lists in general, but to show
+new kernel developers how to use the Linux kernel implementations of linked
+lists.
+
+Please note that while linked lists certainly are ubiquitous, they are rarely
+the best data structure to use in cases where a simple array doesn't already
+suffice. In particular, due to their poor data locality, linked lists are a bad
+choice in situations where performance may be of consideration. Familiarizing
+oneself with other in-kernel generic data structures, especially for concurrent
+accesses, is highly encouraged.
+
+Linux implementation of doubly linked lists
+===========================================
+
+Linux's linked list implementations can be used by including the header file
+``<linux/list.h>``.
+
+The doubly-linked list will likely be the most familiar to many readers. It's a
+list that can efficiently be traversed forwards and backwards.
+
+The Linux kernel's doubly-linked list is circular in nature. This means that to
+get from the head node to the tail, we can just travel one edge backwards.
+Similarly, to get from the tail node to the head, we can simply travel forwards
+"beyond" the tail and arrive back at the head.
+
+Declaring a node
+----------------
+
+A node in a doubly-linked list is declared by adding a struct list_head
+member to the data structure you wish to be contained in the list:
+
+.. code-block:: c
+
+ struct clown {
+ unsigned long long shoe_size;
+ const char *name;
+ struct list_head node; /* the aforementioned member */
+ };
+
+This may be an unfamiliar approach to some, as the classical explanation of a
+linked list is a list node data structure with pointers to the previous and next
+list node, as well the payload data. Linux chooses this approach because it
+allows for generic list modification code regardless of what data structure is
+contained within the list. Since the struct list_head member is not a pointer
+but part of the data structure proper, the container_of() pattern can be used by
+the list implementation to access the payload data regardless of its type, while
+staying oblivious to what said type actually is.
+
+Declaring and initializing a list
+---------------------------------
+
+A doubly-linked list can then be declared as just another struct list_head,
+and initialized with the LIST_HEAD_INIT() macro during initial assignment, or
+with the INIT_LIST_HEAD() function later:
+
+.. code-block:: c
+
+ struct clown_car {
+ int tyre_pressure[4];
+ struct list_head clowns; /* Looks like a node! */
+ };
+
+ /* ... Somewhere later in our driver ... */
+
+ static int circus_init(struct circus_priv *circus)
+ {
+ struct clown_car other_car = {
+ .tyre_pressure = {10, 12, 11, 9},
+ .clowns = LIST_HEAD_INIT(other_car.clowns)
+ };
+
+ INIT_LIST_HEAD(&circus->car.clowns);
+
+ return 0;
+ }
+
+A further point of confusion to some may be that the list itself doesn't really
+have its own type. The concept of the entire linked list and a
+struct list_head member that points to other entries in the list are one and
+the same.
+
+Adding nodes to the list
+------------------------
+
+Adding a node to the linked list is done through the list_add() macro.
+
+We'll return to our clown car example to illustrate how nodes get added to the
+list:
+
+.. code-block:: c
+
+ static int circus_fill_car(struct circus_priv *circus)
+ {
+ struct clown_car *car = &circus->car;
+ struct clown *grock;
+ struct clown *dimitri;
+
+ /* State 1 */
+
+ grock = kzalloc(sizeof(*grock), GFP_KERNEL);
+ if (!grock)
+ return -ENOMEM;
+ grock->name = "Grock";
+ grock->shoe_size = 1000;
+
+ /* Note that we're adding the "node" member */
+ list_add(&grock->node, &car->clowns);
+
+ /* State 2 */
+
+ dimitri = kzalloc(sizeof(*dimitri), GFP_KERNEL);
+ if (!dimitri)
+ return -ENOMEM;
+ dimitri->name = "Dimitri";
+ dimitri->shoe_size = 50;
+
+ list_add(&dimitri->node, &car->clowns);
+
+ /* State 3 */
+
+ return 0;
+ }
+
+In State 1, our list of clowns is still empty::
+
+ .------.
+ v |
+ .--------. |
+ | clowns |--'
+ '--------'
+
+This diagram shows the singular "clowns" node pointing at itself. In this
+diagram, and all following diagrams, only the forward edges are shown, to aid in
+clarity.
+
+In State 2, we've added Grock after the list head::
+
+ .--------------------.
+ v |
+ .--------. .-------. |
+ | clowns |---->| Grock |--'
+ '--------' '-------'
+
+This diagram shows the "clowns" node pointing at a new node labeled "Grock".
+The Grock node is pointing back at the "clowns" node.
+
+In State 3, we've added Dimitri after the list head, resulting in the following::
+
+ .------------------------------------.
+ v |
+ .--------. .---------. .-------. |
+ | clowns |---->| Dimitri |---->| Grock |--'
+ '--------' '---------' '-------'
+
+This diagram shows the "clowns" node pointing at a new node labeled "Dimitri",
+which then points at the node labeled "Grock". The "Grock" node still points
+back at the "clowns" node.
+
+If we wanted to have Dimitri inserted at the end of the list instead, we'd use
+list_add_tail(). Our code would then look like this:
+
+.. code-block:: c
+
+ static int circus_fill_car(struct circus_priv *circus)
+ {
+ /* ... */
+
+ list_add_tail(&dimitri->node, &car->clowns);
+
+ /* State 3b */
+
+ return 0;
+ }
+
+This results in the following list::
+
+ .------------------------------------.
+ v |
+ .--------. .-------. .---------. |
+ | clowns |---->| Grock |---->| Dimitri |--'
+ '--------' '-------' '---------'
+
+This diagram shows the "clowns" node pointing at the node labeled "Grock",
+which points at the new node labeled "Dimitri". The node labeled "Dimitri"
+points back at the "clowns" node.
+
+Traversing the list
+-------------------
+
+To iterate the list, we can loop through all nodes within the list with
+list_for_each().
+
+In our clown example, this results in the following somewhat awkward code:
+
+.. code-block:: c
+
+ static unsigned long long circus_get_max_shoe_size(struct circus_priv *circus)
+ {
+ unsigned long long res = 0;
+ struct clown *e;
+ struct list_head *cur;
+
+ list_for_each(cur, &circus->car.clowns) {
+ e = list_entry(cur, struct clown, node);
+ if (e->shoe_size > res)
+ res = e->shoe_size;
+ }
+
+ return res;
+ }
+
+The list_entry() macro internally uses the aforementioned container_of() to
+retrieve the data structure instance that ``node`` is a member of.
+
+Note how the additional list_entry() call is a little awkward here. It's only
+there because we're iterating through the ``node`` members, but we really want
+to iterate through the payload, i.e. the ``struct clown`` that contains each
+node's struct list_head. For this reason, there is a second macro:
+list_for_each_entry()
+
+Using it would change our code to something like this:
+
+.. code-block:: c
+
+ static unsigned long long circus_get_max_shoe_size(struct circus_priv *circus)
+ {
+ unsigned long long res = 0;
+ struct clown *e;
+
+ list_for_each_entry(e, &circus->car.clowns, node) {
+ if (e->shoe_size > res)
+ res = e->shoe_size;
+ }
+
+ return res;
+ }
+
+This eliminates the need for the list_entry() step, and our loop cursor is now
+of the type of our payload. The macro is given the member name that corresponds
+to the list's struct list_head within the clown data structure so that it can
+still walk the list.
+
+Removing nodes from the list
+----------------------------
+
+The list_del() function can be used to remove entries from the list. It not only
+removes the given entry from the list, but poisons the entry's ``prev`` and
+``next`` pointers, so that unintended use of the entry after removal does not
+go unnoticed.
+
+We can extend our previous example to remove one of the entries:
+
+.. code-block:: c
+
+ static int circus_fill_car(struct circus_priv *circus)
+ {
+ /* ... */
+
+ list_add(&dimitri->node, &car->clowns);
+
+ /* State 3 */
+
+ list_del(&dimitri->node);
+
+ /* State 4 */
+
+ return 0;
+ }
+
+The result of this would be this::
+
+ .--------------------.
+ v |
+ .--------. .-------. | .---------.
+ | clowns |---->| Grock |--' | Dimitri |
+ '--------' '-------' '---------'
+
+This diagram shows the "clowns" node pointing at the node labeled "Grock",
+which points back at the "clowns" node. Off to the side is a lone node labeled
+"Dimitri", which has no arrows pointing anywhere.
+
+Note how the Dimitri node does not point to itself; its pointers are
+intentionally set to a "poison" value that the list code refuses to traverse.
+
+If we wanted to reinitialize the removed node instead to make it point at itself
+again like an empty list head, we can use list_del_init() instead:
+
+.. code-block:: c
+
+ static int circus_fill_car(struct circus_priv *circus)
+ {
+ /* ... */
+
+ list_add(&dimitri->node, &car->clowns);
+
+ /* State 3 */
+
+ list_del_init(&dimitri->node);
+
+ /* State 4b */
+
+ return 0;
+ }
+
+This results in the deleted node pointing to itself again::
+
+ .--------------------. .-------.
+ v | v |
+ .--------. .-------. | .---------. |
+ | clowns |---->| Grock |--' | Dimitri |--'
+ '--------' '-------' '---------'
+
+This diagram shows the "clowns" node pointing at the node labeled "Grock",
+which points back at the "clowns" node. Off to the side is a lone node labeled
+"Dimitri", which points to itself.
+
+Traversing whilst removing nodes
+--------------------------------
+
+Deleting entries while we're traversing the list will cause problems if we use
+list_for_each() and list_for_each_entry(), as deleting the current entry would
+modify the ``next`` pointer of it, which means the traversal can't properly
+advance to the next list entry.
+
+There is a solution to this however: list_for_each_safe() and
+list_for_each_entry_safe(). These take an additional parameter of a pointer to
+a struct list_head to use as temporary storage for the next entry during
+iteration, solving the issue.
+
+An example of how to use it:
+
+.. code-block:: c
+
+ static void circus_eject_insufficient_clowns(struct circus_priv *circus)
+ {
+ struct clown *e;
+ struct clown *n; /* temporary storage for safe iteration */
+
+ list_for_each_entry_safe(e, n, &circus->car.clowns, node) {
+ if (e->shoe_size < 500)
+ list_del(&e->node);
+ }
+ }
+
+Proper memory management (i.e. freeing the deleted node while making sure
+nothing still references it) in this case is left as an exercise to the reader.
+
+Cutting a list
+--------------
+
+There are two helper functions to cut lists with. Both take elements from the
+list ``head``, and replace the contents of the list ``list``.
+
+The first such function is list_cut_position(). It removes all list entries from
+``head`` up to and including ``entry``, placing them in ``list`` instead.
+
+In this example, it's assumed we start with the following list::
+
+ .----------------------------------------------------------------.
+ v |
+ .--------. .-------. .---------. .-----. .---------. |
+ | clowns |---->| Grock |---->| Dimitri |---->| Pic |---->| Alfredo |--'
+ '--------' '-------' '---------' '-----' '---------'
+
+With the following code, every clown up to and including "Pic" is moved from
+the "clowns" list head to a separate struct list_head initialized at local
+stack variable ``retirement``:
+
+.. code-block:: c
+
+ static void circus_retire_clowns(struct circus_priv *circus)
+ {
+ struct list_head retirement = LIST_HEAD_INIT(retirement);
+ struct clown *grock, *dimitri, *pic, *alfredo;
+ struct clown_car *car = &circus->car;
+
+ /* ... clown initialization, list adding ... */
+
+ list_cut_position(&retirement, &car->clowns, &pic->node);
+
+ /* State 1 */
+ }
+
+The resulting ``car->clowns`` list would be this::
+
+ .----------------------.
+ v |
+ .--------. .---------. |
+ | clowns |---->| Alfredo |--'
+ '--------' '---------'
+
+Meanwhile, the ``retirement`` list is transformed to the following::
+
+ .--------------------------------------------------.
+ v |
+ .------------. .-------. .---------. .-----. |
+ | retirement |---->| Grock |---->| Dimitri |---->| Pic |--'
+ '------------' '-------' '---------' '-----'
+
+The second function, list_cut_before(), is much the same, except it cuts before
+the ``entry`` node, i.e. it removes all list entries from ``head`` up to but
+excluding ``entry``, placing them in ``list`` instead. This example assumes the
+same initial starting list as the previous example:
+
+.. code-block:: c
+
+ static void circus_retire_clowns(struct circus_priv *circus)
+ {
+ struct list_head retirement = LIST_HEAD_INIT(retirement);
+ struct clown *grock, *dimitri, *pic, *alfredo;
+ struct clown_car *car = &circus->car;
+
+ /* ... clown initialization, list adding ... */
+
+ list_cut_before(&retirement, &car->clowns, &pic->node);
+
+ /* State 1b */
+ }
+
+The resulting ``car->clowns`` list would be this::
+
+ .----------------------------------.
+ v |
+ .--------. .-----. .---------. |
+ | clowns |---->| Pic |---->| Alfredo |--'
+ '--------' '-----' '---------'
+
+Meanwhile, the ``retirement`` list is transformed to the following::
+
+ .--------------------------------------.
+ v |
+ .------------. .-------. .---------. |
+ | retirement |---->| Grock |---->| Dimitri |--'
+ '------------' '-------' '---------'
+
+It should be noted that both functions will destroy links to any existing nodes
+in the destination ``struct list_head *list``.
+
+Moving entries and partial lists
+--------------------------------
+
+The list_move() and list_move_tail() functions can be used to move an entry
+from one list to another, to either the start or end respectively.
+
+In the following example, we'll assume we start with two lists ("clowns" and
+"sidewalk" in the following initial state "State 0"::
+
+ .----------------------------------------------------------------.
+ v |
+ .--------. .-------. .---------. .-----. .---------. |
+ | clowns |---->| Grock |---->| Dimitri |---->| Pic |---->| Alfredo |--'
+ '--------' '-------' '---------' '-----' '---------'
+
+ .-------------------.
+ v |
+ .----------. .-----. |
+ | sidewalk |---->| Pio |--'
+ '----------' '-----'
+
+We apply the following example code to the two lists:
+
+.. code-block:: c
+
+ static void circus_clowns_exit_car(struct circus_priv *circus)
+ {
+ struct list_head sidewalk = LIST_HEAD_INIT(sidewalk);
+ struct clown *grock, *dimitri, *pic, *alfredo, *pio;
+ struct clown_car *car = &circus->car;
+
+ /* ... clown initialization, list adding ... */
+
+ /* State 0 */
+
+ list_move(&pic->node, &sidewalk);
+
+ /* State 1 */
+
+ list_move_tail(&dimitri->node, &sidewalk);
+
+ /* State 2 */
+ }
+
+In State 1, we arrive at the following situation::
+
+ .-----------------------------------------------------.
+ | |
+ v |
+ .--------. .-------. .---------. .---------. |
+ | clowns |---->| Grock |---->| Dimitri |---->| Alfredo |--'
+ '--------' '-------' '---------' '---------'
+
+ .-------------------------------.
+ v |
+ .----------. .-----. .-----. |
+ | sidewalk |---->| Pic |---->| Pio |--'
+ '----------' '-----' '-----'
+
+In State 2, after we've moved Dimitri to the tail of sidewalk, the situation
+changes as follows::
+
+ .-------------------------------------.
+ | |
+ v |
+ .--------. .-------. .---------. |
+ | clowns |---->| Grock |---->| Alfredo |--'
+ '--------' '-------' '---------'
+
+ .-----------------------------------------------.
+ v |
+ .----------. .-----. .-----. .---------. |
+ | sidewalk |---->| Pic |---->| Pio |---->| Dimitri |--'
+ '----------' '-----' '-----' '---------'
+
+As long as the source and destination list head are part of the same list, we
+can also efficiently bulk move a segment of the list to the tail end of the
+list. We continue the previous example by adding a list_bulk_move_tail() after
+State 2, moving Pic and Pio to the tail end of the sidewalk list.
+
+.. code-block:: c
+
+ static void circus_clowns_exit_car(struct circus_priv *circus)
+ {
+ struct list_head sidewalk = LIST_HEAD_INIT(sidewalk);
+ struct clown *grock, *dimitri, *pic, *alfredo, *pio;
+ struct clown_car *car = &circus->car;
+
+ /* ... clown initialization, list adding ... */
+
+ /* State 0 */
+
+ list_move(&pic->node, &sidewalk);
+
+ /* State 1 */
+
+ list_move_tail(&dimitri->node, &sidewalk);
+
+ /* State 2 */
+
+ list_bulk_move_tail(&sidewalk, &pic->node, &pio->node);
+
+ /* State 3 */
+ }
+
+For the sake of brevity, only the altered "sidewalk" list at State 3 is depicted
+in the following diagram::
+
+ .-----------------------------------------------.
+ v |
+ .----------. .---------. .-----. .-----. |
+ | sidewalk |---->| Dimitri |---->| Pic |---->| Pio |--'
+ '----------' '---------' '-----' '-----'
+
+Do note that list_bulk_move_tail() does not do any checking as to whether all
+three supplied ``struct list_head *`` parameters really do belong to the same
+list. If you use it outside the constraints the documentation gives, then the
+result is a matter between you and the implementation.
+
+Rotating entries
+----------------
+
+A common write operation on lists, especially when using them as queues, is
+to rotate it. A list rotation means entries at the front are sent to the back.
+
+For rotation, Linux provides us with two functions: list_rotate_left() and
+list_rotate_to_front(). The former can be pictured like a bicycle chain, taking
+the entry after the supplied ``struct list_head *`` and moving it to the tail,
+which in essence means the entire list, due to its circular nature, rotates by
+one position.
+
+The latter, list_rotate_to_front(), takes the same concept one step further:
+instead of advancing the list by one entry, it advances it *until* the specified
+entry is the new front.
+
+In the following example, our starting state, State 0, is the following::
+
+ .-----------------------------------------------------------------.
+ v |
+ .--------. .-------. .---------. .-----. .---------. .-----. |
+ | clowns |-->| Grock |-->| Dimitri |-->| Pic |-->| Alfredo |-->| Pio |-'
+ '--------' '-------' '---------' '-----' '---------' '-----'
+
+The example code being used to demonstrate list rotations is the following:
+
+.. code-block:: c
+
+ static void circus_clowns_rotate(struct circus_priv *circus)
+ {
+ struct clown *grock, *dimitri, *pic, *alfredo, *pio;
+ struct clown_car *car = &circus->car;
+
+ /* ... clown initialization, list adding ... */
+
+ /* State 0 */
+
+ list_rotate_left(&car->clowns);
+
+ /* State 1 */
+
+ list_rotate_to_front(&alfredo->node, &car->clowns);
+
+ /* State 2 */
+
+ }
+
+In State 1, we arrive at the following situation::
+
+ .-----------------------------------------------------------------.
+ v |
+ .--------. .---------. .-----. .---------. .-----. .-------. |
+ | clowns |-->| Dimitri |-->| Pic |-->| Alfredo |-->| Pio |-->| Grock |-'
+ '--------' '---------' '-----' '---------' '-----' '-------'
+
+Next, after the list_rotate_to_front() call, we arrive in the following
+State 2::
+
+ .-----------------------------------------------------------------.
+ v |
+ .--------. .---------. .-----. .-------. .---------. .-----. |
+ | clowns |-->| Alfredo |-->| Pio |-->| Grock |-->| Dimitri |-->| Pic |-'
+ '--------' '---------' '-----' '-------' '---------' '-----'
+
+As is hopefully evident from the diagrams, the entries in front of "Alfredo"
+were cycled to the tail end of the list.
+
+Swapping entries
+----------------
+
+Another common operation is that two entries need to be swapped with each other.
+
+For this, Linux provides us with list_swap().
+
+In the following example, we have a list with three entries, and swap two of
+them. This is our starting state in "State 0"::
+
+ .-----------------------------------------.
+ v |
+ .--------. .-------. .---------. .-----. |
+ | clowns |-->| Grock |-->| Dimitri |-->| Pic |-'
+ '--------' '-------' '---------' '-----'
+
+.. code-block:: c
+
+ static void circus_clowns_swap(struct circus_priv *circus)
+ {
+ struct clown *grock, *dimitri, *pic;
+ struct clown_car *car = &circus->car;
+
+ /* ... clown initialization, list adding ... */
+
+ /* State 0 */
+
+ list_swap(&dimitri->node, &pic->node);
+
+ /* State 1 */
+ }
+
+The resulting list at State 1 is the following::
+
+ .-----------------------------------------.
+ v |
+ .--------. .-------. .-----. .---------. |
+ | clowns |-->| Grock |-->| Pic |-->| Dimitri |-'
+ '--------' '-------' '-----' '---------'
+
+As is evident by comparing the diagrams, the "Pic" and "Dimitri" nodes have
+traded places.
+
+Splicing two lists together
+---------------------------
+
+Say we have two lists, in the following example one represented by a list head
+we call "knie" and one we call "stey". In a hypothetical circus acquisition,
+the two list of clowns should be spliced together. The following is our
+situation in "State 0"::
+
+ .-----------------------------------------.
+ | |
+ v |
+ .------. .-------. .---------. .-----. |
+ | knie |-->| Grock |-->| Dimitri |-->| Pic |--'
+ '------' '-------' '---------' '-----'
+
+ .-----------------------------.
+ v |
+ .------. .---------. .-----. |
+ | stey |-->| Alfredo |-->| Pio |--'
+ '------' '---------' '-----'
+
+The function to splice these two lists together is list_splice(). Our example
+code is as follows:
+
+.. code-block:: c
+
+ static void circus_clowns_splice(void)
+ {
+ struct clown *grock, *dimitri, *pic, *alfredo, *pio;
+ struct list_head knie = LIST_HEAD_INIT(knie);
+ struct list_head stey = LIST_HEAD_INIT(stey);
+
+ /* ... Clown allocation and initialization here ... */
+
+ list_add_tail(&grock->node, &knie);
+ list_add_tail(&dimitri->node, &knie);
+ list_add_tail(&pic->node, &knie);
+ list_add_tail(&alfredo->node, &stey);
+ list_add_tail(&pio->node, &stey);
+
+ /* State 0 */
+
+ list_splice(&stey, &dimitri->node);
+
+ /* State 1 */
+ }
+
+The list_splice() call here adds all the entries in ``stey`` to the list
+``dimitri``'s ``node`` list_head is in, after the ``node`` of ``dimitri``. A
+somewhat surprising diagram of the resulting "State 1" follows::
+
+ .-----------------------------------------------------------------.
+ | |
+ v |
+ .------. .-------. .---------. .---------. .-----. .-----. |
+ | knie |-->| Grock |-->| Dimitri |-->| Alfredo |-->| Pio |-->| Pic |--'
+ '------' '-------' '---------' '---------' '-----' '-----'
+ ^
+ .-------------------------------'
+ |
+ .------. |
+ | stey |--'
+ '------'
+
+Traversing the ``stey`` list no longer results in correct behavior. A call of
+list_for_each() on ``stey`` results in an infinite loop, as it never returns
+back to the ``stey`` list head.
+
+This is because list_splice() did not reinitialize the list_head it took
+entries from, leaving its pointer pointing into what is now a different list.
+
+If we want to avoid this situation, list_splice_init() can be used. It does the
+same thing as list_splice(), except reinitalizes the donor list_head after the
+transplant.
+
+Concurrency considerations
+--------------------------
+
+Concurrent access and modification of a list needs to be protected with a lock
+in most cases. Alternatively and preferably, one may use the RCU primitives for
+lists in read-mostly use-cases, where read accesses to the list are common but
+modifications to the list less so. See Documentation/RCU/listRCU.rst for more
+details.
+
+Further reading
+---------------
+
+* `How does the kernel implements Linked Lists? - KernelNewbies <https://kernelnewbies.org/FAQ/LinkedLists>`_
+
+Full List API
+=============
+
+.. kernel-doc:: include/linux/list.h
+ :internal:
diff --git a/Documentation/core-api/liveupdate.rst b/Documentation/core-api/liveupdate.rst
new file mode 100644
index 000000000000..7960eb15a81f
--- /dev/null
+++ b/Documentation/core-api/liveupdate.rst
@@ -0,0 +1,61 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+Live Update Orchestrator
+========================
+:Author: Pasha Tatashin <pasha.tatashin@soleen.com>
+
+.. kernel-doc:: kernel/liveupdate/luo_core.c
+ :doc: Live Update Orchestrator (LUO)
+
+LUO Sessions
+============
+.. kernel-doc:: kernel/liveupdate/luo_session.c
+ :doc: LUO Sessions
+
+LUO Preserving File Descriptors
+===============================
+.. kernel-doc:: kernel/liveupdate/luo_file.c
+ :doc: LUO File Descriptors
+
+Live Update Orchestrator ABI
+============================
+.. kernel-doc:: include/linux/kho/abi/luo.h
+ :doc: Live Update Orchestrator ABI
+
+The following types of file descriptors can be preserved
+
+.. toctree::
+ :maxdepth: 1
+
+ ../mm/memfd_preservation
+
+Public API
+==========
+.. kernel-doc:: include/linux/liveupdate.h
+
+.. kernel-doc:: include/linux/kho/abi/luo.h
+ :functions:
+
+.. kernel-doc:: kernel/liveupdate/luo_core.c
+ :export:
+
+.. kernel-doc:: kernel/liveupdate/luo_file.c
+ :export:
+
+Internal API
+============
+.. kernel-doc:: kernel/liveupdate/luo_core.c
+ :internal:
+
+.. kernel-doc:: kernel/liveupdate/luo_session.c
+ :internal:
+
+.. kernel-doc:: kernel/liveupdate/luo_file.c
+ :internal:
+
+See Also
+========
+
+- :doc:`Live Update uAPI </userspace-api/liveupdate>`
+- :doc:`/core-api/kho/concepts`
diff --git a/Documentation/core-api/local_ops.rst b/Documentation/core-api/local_ops.rst
index 2ac3f9f29845..0b42ceaaf3c4 100644
--- a/Documentation/core-api/local_ops.rst
+++ b/Documentation/core-api/local_ops.rst
@@ -191,7 +191,7 @@ Here is a sample module which implements a basic per cpu counter using
static void __exit test_exit(void)
{
- del_timer_sync(&test_timer);
+ timer_shutdown_sync(&test_timer);
}
module_init(test_init);
diff --git a/Documentation/core-api/maple_tree.rst b/Documentation/core-api/maple_tree.rst
new file mode 100644
index 000000000000..ccdd1615cf97
--- /dev/null
+++ b/Documentation/core-api/maple_tree.rst
@@ -0,0 +1,221 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+
+==========
+Maple Tree
+==========
+
+:Author: Liam R. Howlett
+
+Overview
+========
+
+The Maple Tree is a B-Tree data type which is optimized for storing
+non-overlapping ranges, including ranges of size 1. The tree was designed to
+be simple to use and does not require a user written search method. It
+supports iterating over a range of entries and going to the previous or next
+entry in a cache-efficient manner. The tree can also be put into an RCU-safe
+mode of operation which allows reading and writing concurrently. Writers must
+synchronize on a lock, which can be the default spinlock, or the user can set
+the lock to an external lock of a different type.
+
+The Maple Tree maintains a small memory footprint and was designed to use
+modern processor cache efficiently. The majority of the users will be able to
+use the normal API. An :ref:`maple-tree-advanced-api` exists for more complex
+scenarios. The most important usage of the Maple Tree is the tracking of the
+virtual memory areas.
+
+The Maple Tree can store values between ``0`` and ``ULONG_MAX``. The Maple
+Tree reserves values with the bottom two bits set to '10' which are below 4096
+(ie 2, 6, 10 .. 4094) for internal use. If the entries may use reserved
+entries then the users can convert the entries using xa_mk_value() and convert
+them back by calling xa_to_value(). If the user needs to use a reserved
+value, then the user can convert the value when using the
+:ref:`maple-tree-advanced-api`, but are blocked by the normal API.
+
+The Maple Tree can also be configured to support searching for a gap of a given
+size (or larger).
+
+Pre-allocating of nodes is also supported using the
+:ref:`maple-tree-advanced-api`. This is useful for users who must guarantee a
+successful store operation within a given
+code segment when allocating cannot be done. Allocations of nodes are
+relatively small at around 256 bytes.
+
+.. _maple-tree-normal-api:
+
+Normal API
+==========
+
+Start by initialising a maple tree, either with DEFINE_MTREE() for statically
+allocated maple trees or mt_init() for dynamically allocated ones. A
+freshly-initialised maple tree contains a ``NULL`` pointer for the range ``0``
+- ``ULONG_MAX``. There are currently two types of maple trees supported: the
+allocation tree and the regular tree. The regular tree has a higher branching
+factor for internal nodes. The allocation tree has a lower branching factor
+but allows the user to search for a gap of a given size or larger from either
+``0`` upwards or ``ULONG_MAX`` down. An allocation tree can be used by
+passing in the ``MT_FLAGS_ALLOC_RANGE`` flag when initialising the tree.
+
+You can then set entries using mtree_store() or mtree_store_range().
+mtree_store() will overwrite any entry with the new entry and return 0 on
+success or an error code otherwise. mtree_store_range() works in the same way
+but takes a range. mtree_load() is used to retrieve the entry stored at a
+given index. You can use mtree_erase() to erase an entire range by only
+knowing one value within that range, or mtree_store() call with an entry of
+NULL may be used to partially erase a range or many ranges at once.
+
+If you want to only store a new entry to a range (or index) if that range is
+currently ``NULL``, you can use mtree_insert_range() or mtree_insert() which
+return -EEXIST if the range is not empty.
+
+You can search for an entry from an index upwards by using mt_find().
+
+You can walk each entry within a range by calling mt_for_each(). You must
+provide a temporary variable to store a cursor. If you want to walk each
+element of the tree then ``0`` and ``ULONG_MAX`` may be used as the range. If
+the caller is going to hold the lock for the duration of the walk then it is
+worth looking at the mas_for_each() API in the :ref:`maple-tree-advanced-api`
+section.
+
+Sometimes it is necessary to ensure the next call to store to a maple tree does
+not allocate memory, please see :ref:`maple-tree-advanced-api` for this use case.
+
+You can use mtree_dup() to duplicate an entire maple tree. It is a more
+efficient way than inserting all elements one by one into a new tree.
+
+Finally, you can remove all entries from a maple tree by calling
+mtree_destroy(). If the maple tree entries are pointers, you may wish to free
+the entries first.
+
+Allocating Nodes
+----------------
+
+The allocations are handled by the internal tree code. See
+:ref:`maple-tree-advanced-alloc` for other options.
+
+Locking
+-------
+
+You do not have to worry about locking. See :ref:`maple-tree-advanced-locks`
+for other options.
+
+The Maple Tree uses RCU and an internal spinlock to synchronise access:
+
+Takes RCU read lock:
+ * mtree_load()
+ * mt_find()
+ * mt_for_each()
+ * mt_next()
+ * mt_prev()
+
+Takes ma_lock internally:
+ * mtree_store()
+ * mtree_store_range()
+ * mtree_insert()
+ * mtree_insert_range()
+ * mtree_erase()
+ * mtree_dup()
+ * mtree_destroy()
+ * mt_set_in_rcu()
+ * mt_clear_in_rcu()
+
+If you want to take advantage of the internal lock to protect the data
+structures that you are storing in the Maple Tree, you can call mtree_lock()
+before calling mtree_load(), then take a reference count on the object you
+have found before calling mtree_unlock(). This will prevent stores from
+removing the object from the tree between looking up the object and
+incrementing the refcount. You can also use RCU to avoid dereferencing
+freed memory, but an explanation of that is beyond the scope of this
+document.
+
+.. _maple-tree-advanced-api:
+
+Advanced API
+============
+
+The advanced API offers more flexibility and better performance at the
+cost of an interface which can be harder to use and has fewer safeguards.
+You must take care of your own locking while using the advanced API.
+You can use the ma_lock, RCU or an external lock for protection.
+You can mix advanced and normal operations on the same array, as long
+as the locking is compatible. The :ref:`maple-tree-normal-api` is implemented
+in terms of the advanced API.
+
+The advanced API is based around the ma_state, this is where the 'mas'
+prefix originates. The ma_state struct keeps track of tree operations to make
+life easier for both internal and external tree users.
+
+Initialising the maple tree is the same as in the :ref:`maple-tree-normal-api`.
+Please see above.
+
+The maple state keeps track of the range start and end in mas->index and
+mas->last, respectively.
+
+mas_walk() will walk the tree to the location of mas->index and set the
+mas->index and mas->last according to the range for the entry.
+
+You can set entries using mas_store(). mas_store() will overwrite any entry
+with the new entry and return the first existing entry that is overwritten.
+The range is passed in as members of the maple state: index and last.
+
+You can use mas_erase() to erase an entire range by setting index and
+last of the maple state to the desired range to erase. This will erase
+the first range that is found in that range, set the maple state index
+and last as the range that was erased and return the entry that existed
+at that location.
+
+You can walk each entry within a range by using mas_for_each(). If you want
+to walk each element of the tree then ``0`` and ``ULONG_MAX`` may be used as
+the range. If the lock needs to be periodically dropped, see the locking
+section mas_pause().
+
+Using a maple state allows mas_next() and mas_prev() to function as if the
+tree was a linked list. With such a high branching factor the amortized
+performance penalty is outweighed by cache optimization. mas_next() will
+return the next entry which occurs after the entry at index. mas_prev()
+will return the previous entry which occurs before the entry at index.
+
+mas_find() will find the first entry which exists at or above index on
+the first call, and the next entry from every subsequent calls.
+
+mas_find_rev() will find the first entry which exists at or below the last on
+the first call, and the previous entry from every subsequent calls.
+
+If the user needs to yield the lock during an operation, then the maple state
+must be paused using mas_pause().
+
+There are a few extra interfaces provided when using an allocation tree.
+If you wish to search for a gap within a range, then mas_empty_area()
+or mas_empty_area_rev() can be used. mas_empty_area() searches for a gap
+starting at the lowest index given up to the maximum of the range.
+mas_empty_area_rev() searches for a gap starting at the highest index given
+and continues downward to the lower bound of the range.
+
+.. _maple-tree-advanced-alloc:
+
+Advanced Allocating Nodes
+-------------------------
+
+Allocations are usually handled internally to the tree, however if allocations
+need to occur before a write occurs then calling mas_expected_entries() will
+allocate the worst-case number of needed nodes to insert the provided number of
+ranges. This also causes the tree to enter mass insertion mode. Once
+insertions are complete calling mas_destroy() on the maple state will free the
+unused allocations.
+
+.. _maple-tree-advanced-locks:
+
+Advanced Locking
+----------------
+
+The maple tree uses a spinlock by default, but external locks can be used for
+tree updates as well. To use an external lock, the tree must be initialized
+with the ``MT_FLAGS_LOCK_EXTERN flag``, this is usually done with the
+MTREE_INIT_EXT() #define, which takes an external lock as an argument.
+
+Functions and structures
+========================
+
+.. kernel-doc:: include/linux/maple_tree.h
+.. kernel-doc:: lib/maple_tree.c
diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst
index 5954ddf6ee13..0f19dd524323 100644
--- a/Documentation/core-api/memory-allocation.rst
+++ b/Documentation/core-api/memory-allocation.rst
@@ -45,8 +45,9 @@ here we briefly outline their recommended usage:
* If the allocation is performed from an atomic context, e.g interrupt
handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and
IO or filesystem operations. Consequently, under memory pressure
- ``GFP_NOWAIT`` allocation is likely to fail. Allocations which
- have a reasonable fallback should be using ``GFP_NOWARN``.
+ ``GFP_NOWAIT`` allocation is likely to fail. Users of this flag need
+ to provide a suitable fallback to cope with such failures where
+ appropriate.
* If you think that accessing memory reserves is justified and the kernel
will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.
* Untrusted allocations triggered from userspace should be a subject
@@ -144,8 +145,10 @@ configuration, but it is a good practice to use `kmalloc` for objects
smaller than page size.
The address of a chunk allocated with `kmalloc` is aligned to at least
-ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
-alignment is also guaranteed to be at least the respective size.
+ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
+alignment is also guaranteed to be at least the respective size. For other
+sizes, the alignment is guaranteed to be at least the largest power-of-two
+divisor of the size.
Chunks allocated with kmalloc() can be resized with krealloc(). Similarly
to kmalloc_array(): a helper for resizing arrays is provided in the form of
@@ -170,7 +173,16 @@ should be used if a part of the cache might be copied to the userspace.
After the cache is created kmem_cache_alloc() and its convenience
wrappers can allocate memory from that cache.
-When the allocated memory is no longer needed it must be freed. You can
-use kvfree() for the memory allocated with `kmalloc`, `vmalloc` and
-`kvmalloc`. The slab caches should be freed with kmem_cache_free(). And
-don't forget to destroy the cache with kmem_cache_destroy().
+When the allocated memory is no longer needed it must be freed.
+
+Objects allocated by `kmalloc` can be freed by `kfree` or `kvfree`. Objects
+allocated by `kmem_cache_alloc` can be freed with `kmem_cache_free`, `kfree`
+or `kvfree`, where the latter two might be more convenient thanks to not
+needing the kmem_cache pointer.
+
+The same rules apply to _bulk and _rcu flavors of freeing functions.
+
+Memory allocated by `vmalloc` can be freed with `vfree` or `kvfree`.
+Memory allocated by `kvmalloc` can be freed with `kvfree`.
+Caches created by `kmem_cache_create` should be freed with
+`kmem_cache_destroy` only after freeing all the allocated objects first.
diff --git a/Documentation/core-api/memory-hotplug.rst b/Documentation/core-api/memory-hotplug.rst
index 682259ee633a..8fc97c2379de 100644
--- a/Documentation/core-api/memory-hotplug.rst
+++ b/Documentation/core-api/memory-hotplug.rst
@@ -9,6 +9,9 @@ Memory hotplug event notifier
Hotplugging events are sent to a notification queue.
+Memory notifier
+----------------
+
There are six types of notification defined in ``include/linux/memory.h``:
MEM_GOING_ONLINE
@@ -56,20 +59,18 @@ The third argument (arg) passes a pointer of struct memory_notify::
struct memory_notify {
unsigned long start_pfn;
unsigned long nr_pages;
- int status_change_nid_normal;
- int status_change_nid;
}
- start_pfn is start_pfn of online/offline memory.
- nr_pages is # of pages of online/offline memory.
-- status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
- is (will be) set/clear, if this is -1, then nodemask status is not changed.
-- status_change_nid is set node id when N_MEMORY of nodemask is (will be)
- set/clear. It means a new(memoryless) node gets new memory by online and a
- node loses all memory. If this is -1, then nodemask status is not changed.
- If status_changed_nid* >= 0, callback should create/discard structures for the
- node if necessary.
+It is possible to get notified for MEM_CANCEL_ONLINE without having been notified
+for MEM_GOING_ONLINE, and the same applies to MEM_CANCEL_OFFLINE and
+MEM_GOING_OFFLINE.
+This can happen when a consumer fails, meaning we break the callchain and we
+stop calling the remaining consumers of the notifier.
+It is then important that users of memory_notify make no assumptions and get
+prepared to handle such cases.
The callback routine shall return one of the values
NOTIFY_DONE, NOTIFY_OK, NOTIFY_BAD, NOTIFY_STOP
@@ -83,6 +84,78 @@ further processing of the notification queue.
NOTIFY_STOP stops further processing of the notification queue.
+Numa node notifier
+------------------
+
+There are six types of notification defined in ``include/linux/node.h``:
+
+NODE_ADDING_FIRST_MEMORY
+ Generated before memory becomes available to this node for the first time.
+
+NODE_CANCEL_ADDING_FIRST_MEMORY
+ Generated if NODE_ADDING_FIRST_MEMORY fails.
+
+NODE_ADDED_FIRST_MEMORY
+ Generated when memory has become available fo this node for the first time.
+
+NODE_REMOVING_LAST_MEMORY
+ Generated when the last memory available to this node is about to be offlined.
+
+NODE_CANCEL_REMOVING_LAST_MEMORY
+ Generated when NODE_CANCEL_REMOVING_LAST_MEMORY fails.
+
+NODE_REMOVED_LAST_MEMORY
+ Generated when the last memory available to this node has been offlined.
+
+A callback routine can be registered by calling::
+
+ hotplug_node_notifier(callback_func, priority)
+
+Callback functions with higher values of priority are called before callback
+functions with lower values.
+
+A callback function must have the following prototype::
+
+ int callback_func(
+
+ struct notifier_block *self, unsigned long action, void *arg);
+
+The first argument of the callback function (self) is a pointer to the block
+of the notifier chain that points to the callback function itself.
+The second argument (action) is one of the event types described above.
+The third argument (arg) passes a pointer of struct node_notify::
+
+ struct node_notify {
+ int nid;
+ }
+
+- nid is the node we are adding or removing memory to.
+
+It is possible to get notified for NODE_CANCEL_ADDING_FIRST_MEMORY without
+having been notified for NODE_ADDING_FIRST_MEMORY, and the same applies to
+NODE_CANCEL_REMOVING_LAST_MEMORY and NODE_REMOVING_LAST_MEMORY.
+This can happen when a consumer fails, meaning we break the callchain and we
+stop calling the remaining consumers of the notifier.
+It is then important that users of node_notify make no assumptions and get
+prepared to handle such cases.
+
+The callback routine shall return one of the values
+NOTIFY_DONE, NOTIFY_OK, NOTIFY_BAD, NOTIFY_STOP
+defined in ``include/linux/notifier.h``
+
+NOTIFY_DONE and NOTIFY_OK have no effect on the further processing.
+
+NOTIFY_BAD is used as response to the NODE_ADDING_FIRST_MEMORY,
+NODE_REMOVING_LAST_MEMORY, NODE_ADDED_FIRST_MEMORY or
+NODE_REMOVED_LAST_MEMORY action to cancel hotplugging.
+It stops further processing of the notification queue.
+
+NOTIFY_STOP stops further processing of the notification queue.
+
+Please note that we should not fail for NODE_ADDED_FIRST_MEMORY /
+NODE_REMOVED_FIRST_MEMORY, as memory_hotplug code cannot rollback at that
+point anymore.
+
Locking Internals
=================
diff --git a/Documentation/core-api/min_heap.rst b/Documentation/core-api/min_heap.rst
new file mode 100644
index 000000000000..9f57766581df
--- /dev/null
+++ b/Documentation/core-api/min_heap.rst
@@ -0,0 +1,302 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+Min Heap API
+============
+
+:Author: Kuan-Wei Chiu <visitorckw@gmail.com>
+
+Introduction
+============
+
+The Min Heap API provides a set of functions and macros for managing min-heaps
+in the Linux kernel. A min-heap is a binary tree structure where the value of
+each node is less than or equal to the values of its children, ensuring that
+the smallest element is always at the root.
+
+This document provides a guide to the Min Heap API, detailing how to define and
+use min-heaps. Users should not directly call functions with **__min_heap_*()**
+prefixes, but should instead use the provided macro wrappers.
+
+In addition to the standard version of the functions, the API also includes a
+set of inline versions for performance-critical scenarios. These inline
+functions have the same names as their non-inline counterparts but include an
+**_inline** suffix. For example, **__min_heap_init_inline** and its
+corresponding macro wrapper **min_heap_init_inline**. The inline versions allow
+custom comparison and swap functions to be called directly, rather than through
+indirect function calls. This can significantly reduce overhead, especially
+when CONFIG_MITIGATION_RETPOLINE is enabled, as indirect function calls become
+more expensive. As with the non-inline versions, it is important to use the
+macro wrappers for inline functions instead of directly calling the functions
+themselves.
+
+Data Structures
+===============
+
+Min-Heap Definition
+-------------------
+
+The core data structure for representing a min-heap is defined using the
+**MIN_HEAP_PREALLOCATED** and **DEFINE_MIN_HEAP** macros. These macros allow
+you to define a min-heap with a preallocated buffer or dynamically allocated
+memory.
+
+Example:
+
+.. code-block:: c
+
+ #define MIN_HEAP_PREALLOCATED(_type, _name, _nr)
+ struct _name {
+ size_t nr; /* Number of elements in the heap */
+ size_t size; /* Maximum number of elements that can be held */
+ _type *data; /* Pointer to the heap data */
+ _type preallocated[_nr]; /* Static preallocated array */
+ }
+
+ #define DEFINE_MIN_HEAP(_type, _name) MIN_HEAP_PREALLOCATED(_type, _name, 0)
+
+A typical heap structure will include a counter for the number of elements
+(`nr`), the maximum capacity of the heap (`size`), and a pointer to an array of
+elements (`data`). Optionally, you can specify a static array for preallocated
+heap storage using **MIN_HEAP_PREALLOCATED**.
+
+Min Heap Callbacks
+------------------
+
+The **struct min_heap_callbacks** provides customization options for ordering
+elements in the heap and swapping them. It contains two function pointers:
+
+.. code-block:: c
+
+ struct min_heap_callbacks {
+ bool (*less)(const void *lhs, const void *rhs, void *args);
+ void (*swp)(void *lhs, void *rhs, void *args);
+ };
+
+- **less** is the comparison function used to establish the order of elements.
+- **swp** is a function for swapping elements in the heap. If swp is set to
+ NULL, the default swap function will be used, which swaps the elements based on their size
+
+Macro Wrappers
+==============
+
+The following macro wrappers are provided for interacting with the heap in a
+user-friendly manner. Each macro corresponds to a function that operates on the
+heap, and they abstract away direct calls to internal functions.
+
+Each macro accepts various parameters that are detailed below.
+
+Heap Initialization
+--------------------
+
+.. code-block:: c
+
+ min_heap_init(heap, data, size);
+
+- **heap**: A pointer to the min-heap structure to be initialized.
+- **data**: A pointer to the buffer where the heap elements will be stored. If
+ `NULL`, the preallocated buffer within the heap structure will be used.
+- **size**: The maximum number of elements the heap can hold.
+
+This macro initializes the heap, setting its initial state. If `data` is
+`NULL`, the preallocated memory inside the heap structure will be used for
+storage. Otherwise, the user-provided buffer is used. The operation is **O(1)**.
+
+**Inline Version:** min_heap_init_inline(heap, data, size)
+
+Accessing the Top Element
+-------------------------
+
+.. code-block:: c
+
+ element = min_heap_peek(heap);
+
+- **heap**: A pointer to the min-heap from which to retrieve the smallest
+ element.
+
+This macro returns a pointer to the smallest element (the root) of the heap, or
+`NULL` if the heap is empty. The operation is **O(1)**.
+
+**Inline Version:** min_heap_peek_inline(heap)
+
+Heap Insertion
+--------------
+
+.. code-block:: c
+
+ success = min_heap_push(heap, element, callbacks, args);
+
+- **heap**: A pointer to the min-heap into which the element should be inserted.
+- **element**: A pointer to the element to be inserted into the heap.
+- **callbacks**: A pointer to a `struct min_heap_callbacks` providing the
+ `less` and `swp` functions.
+- **args**: Optional arguments passed to the `less` and `swp` functions.
+
+This macro inserts an element into the heap. It returns `true` if the insertion
+was successful and `false` if the heap is full. The operation is **O(log n)**.
+
+**Inline Version:** min_heap_push_inline(heap, element, callbacks, args)
+
+Heap Removal
+------------
+
+.. code-block:: c
+
+ success = min_heap_pop(heap, callbacks, args);
+
+- **heap**: A pointer to the min-heap from which to remove the smallest element.
+- **callbacks**: A pointer to a `struct min_heap_callbacks` providing the
+ `less` and `swp` functions.
+- **args**: Optional arguments passed to the `less` and `swp` functions.
+
+This macro removes the smallest element (the root) from the heap. It returns
+`true` if the element was successfully removed, or `false` if the heap is
+empty. The operation is **O(log n)**.
+
+**Inline Version:** min_heap_pop_inline(heap, callbacks, args)
+
+Heap Maintenance
+----------------
+
+You can use the following macros to maintain the heap's structure:
+
+.. code-block:: c
+
+ min_heap_sift_down(heap, pos, callbacks, args);
+
+- **heap**: A pointer to the min-heap.
+- **pos**: The index from which to start sifting down.
+- **callbacks**: A pointer to a `struct min_heap_callbacks` providing the
+ `less` and `swp` functions.
+- **args**: Optional arguments passed to the `less` and `swp` functions.
+
+This macro restores the heap property by moving the element at the specified
+index (`pos`) down the heap until it is in the correct position. The operation
+is **O(log n)**.
+
+**Inline Version:** min_heap_sift_down_inline(heap, pos, callbacks, args)
+
+.. code-block:: c
+
+ min_heap_sift_up(heap, idx, callbacks, args);
+
+- **heap**: A pointer to the min-heap.
+- **idx**: The index of the element to sift up.
+- **callbacks**: A pointer to a `struct min_heap_callbacks` providing the
+ `less` and `swp` functions.
+- **args**: Optional arguments passed to the `less` and `swp` functions.
+
+This macro restores the heap property by moving the element at the specified
+index (`idx`) up the heap. The operation is **O(log n)**.
+
+**Inline Version:** min_heap_sift_up_inline(heap, idx, callbacks, args)
+
+.. code-block:: c
+
+ min_heapify_all(heap, callbacks, args);
+
+- **heap**: A pointer to the min-heap.
+- **callbacks**: A pointer to a `struct min_heap_callbacks` providing the
+ `less` and `swp` functions.
+- **args**: Optional arguments passed to the `less` and `swp` functions.
+
+This macro ensures that the entire heap satisfies the heap property. It is
+called when the heap is built from scratch or after many modifications. The
+operation is **O(n)**.
+
+**Inline Version:** min_heapify_all_inline(heap, callbacks, args)
+
+Removing Specific Elements
+--------------------------
+
+.. code-block:: c
+
+ success = min_heap_del(heap, idx, callbacks, args);
+
+- **heap**: A pointer to the min-heap.
+- **idx**: The index of the element to delete.
+- **callbacks**: A pointer to a `struct min_heap_callbacks` providing the
+ `less` and `swp` functions.
+- **args**: Optional arguments passed to the `less` and `swp` functions.
+
+This macro removes an element at the specified index (`idx`) from the heap and
+restores the heap property. The operation is **O(log n)**.
+
+**Inline Version:** min_heap_del_inline(heap, idx, callbacks, args)
+
+Other Utilities
+===============
+
+- **min_heap_full(heap)**: Checks whether the heap is full.
+ Complexity: **O(1)**.
+
+.. code-block:: c
+
+ bool full = min_heap_full(heap);
+
+- `heap`: A pointer to the min-heap to check.
+
+This macro returns `true` if the heap is full, otherwise `false`.
+
+**Inline Version:** min_heap_full_inline(heap)
+
+- **min_heap_empty(heap)**: Checks whether the heap is empty.
+ Complexity: **O(1)**.
+
+.. code-block:: c
+
+ bool empty = min_heap_empty(heap);
+
+- `heap`: A pointer to the min-heap to check.
+
+This macro returns `true` if the heap is empty, otherwise `false`.
+
+**Inline Version:** min_heap_empty_inline(heap)
+
+Example Usage
+=============
+
+An example usage of the min-heap API would involve defining a heap structure,
+initializing it, and inserting and removing elements as needed.
+
+.. code-block:: c
+
+ #include <linux/min_heap.h>
+
+ int my_less_function(const void *lhs, const void *rhs, void *args) {
+ return (*(int *)lhs < *(int *)rhs);
+ }
+
+ struct min_heap_callbacks heap_cb = {
+ .less = my_less_function, /* Comparison function for heap order */
+ .swp = NULL, /* Use default swap function */
+ };
+
+ void example_usage(void) {
+ /* Pre-populate the buffer with elements */
+ int buffer[5] = {5, 2, 8, 1, 3};
+ /* Declare a min-heap */
+ DEFINE_MIN_HEAP(int, my_heap);
+
+ /* Initialize the heap with preallocated buffer and size */
+ min_heap_init(&my_heap, buffer, 5);
+
+ /* Build the heap using min_heapify_all */
+ my_heap.nr = 5; /* Set the number of elements in the heap */
+ min_heapify_all(&my_heap, &heap_cb, NULL);
+
+ /* Peek at the top element (should be 1 in this case) */
+ int *top = min_heap_peek(&my_heap);
+ pr_info("Top element: %d\n", *top);
+
+ /* Pop the top element (1) and get the new top (2) */
+ min_heap_pop(&my_heap, &heap_cb, NULL);
+ top = min_heap_peek(&my_heap);
+ pr_info("New top element: %d\n", *top);
+
+ /* Insert a new element (0) and recheck the top */
+ int new_element = 0;
+ min_heap_push(&my_heap, &new_element, &heap_cb, NULL);
+ top = min_heap_peek(&my_heap);
+ pr_info("Top element after insertion: %d\n", *top);
+ }
diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst
index 1ebcc6c3fafe..68193a4cfcf5 100644
--- a/Documentation/core-api/mm-api.rst
+++ b/Documentation/core-api/mm-api.rst
@@ -19,9 +19,6 @@ User Space Memory Access
Memory Allocation Controls
==========================
-.. kernel-doc:: include/linux/gfp.h
- :internal:
-
.. kernel-doc:: include/linux/gfp_types.h
:doc: Page mobility and placement hints
@@ -40,7 +37,7 @@ The Slab Cache
.. kernel-doc:: include/linux/slab.h
:internal:
-.. kernel-doc:: mm/slab.c
+.. kernel-doc:: mm/slub.c
:export:
.. kernel-doc:: mm/slab_common.c
@@ -94,12 +91,6 @@ Memory pools
.. kernel-doc:: mm/mempool.c
:export:
-DMA pools
-=========
-
-.. kernel-doc:: mm/dmapool.c
- :export:
-
More Memory Management Functions
================================
@@ -118,3 +109,26 @@ More Memory Management Functions
.. kernel-doc:: include/linux/mmzone.h
.. kernel-doc:: mm/util.c
:functions: folio_mapping
+
+.. kernel-doc:: mm/rmap.c
+.. kernel-doc:: mm/migrate.c
+.. kernel-doc:: mm/mmap.c
+.. kernel-doc:: mm/kmemleak.c
+.. #kernel-doc:: mm/hmm.c (build warnings)
+.. kernel-doc:: mm/memremap.c
+.. kernel-doc:: mm/hugetlb.c
+.. kernel-doc:: mm/swap.c
+.. kernel-doc:: mm/memcontrol.c
+.. #kernel-doc:: mm/memory-tiers.c (build warnings)
+.. kernel-doc:: mm/shmem.c
+.. kernel-doc:: mm/migrate_device.c
+.. #kernel-doc:: mm/nommu.c (duplicates kernel-doc from other files)
+.. kernel-doc:: mm/mapping_dirty_helpers.c
+.. #kernel-doc:: mm/memory-failure.c (build warnings)
+.. kernel-doc:: mm/percpu.c
+.. kernel-doc:: mm/maccess.c
+.. kernel-doc:: mm/vmscan.c
+.. kernel-doc:: mm/memory_hotplug.c
+.. kernel-doc:: mm/mmu_notifier.c
+.. kernel-doc:: mm/balloon_compaction.c
+.. kernel-doc:: mm/huge_memory.c
diff --git a/Documentation/core-api/netlink.rst b/Documentation/core-api/netlink.rst
new file mode 100644
index 000000000000..9f692b02bfe6
--- /dev/null
+++ b/Documentation/core-api/netlink.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+
+.. _kernel_netlink:
+
+===================================
+Netlink notes for kernel developers
+===================================
+
+General guidance
+================
+
+Attribute enums
+---------------
+
+Older families often define "null" attributes and commands with value
+of ``0`` and named ``unspec``. This is supported (``type: unused``)
+but should be avoided in new families. The ``unspec`` enum values are
+not used in practice, so just set the value of the first attribute to ``1``.
+
+Message enums
+-------------
+
+Use the same command IDs for requests and replies. This makes it easier
+to match them up, and we have plenty of ID space.
+
+Use separate command IDs for notifications. This makes it easier to
+sort the notifications from replies (and present them to the user
+application via a different API than replies).
+
+Answer requests
+---------------
+
+Older families do not reply to all of the commands, especially NEW / ADD
+commands. User only gets information whether the operation succeeded or
+not via the ACK. Try to find useful data to return. Once the command is
+added whether it replies with a full message or only an ACK is uAPI and
+cannot be changed. It's better to err on the side of replying.
+
+Specifically NEW and ADD commands should reply with information identifying
+the created object such as the allocated object's ID (without having to
+resort to using ``NLM_F_ECHO``).
+
+NLM_F_ECHO
+----------
+
+Make sure to pass the request info to genl_notify() to allow ``NLM_F_ECHO``
+to take effect. This is useful for programs that need precise feedback
+from the kernel (for example for logging purposes).
+
+Support dump consistency
+------------------------
+
+If iterating over objects during dump may skip over objects or repeat
+them - make sure to report dump inconsistency with ``NLM_F_DUMP_INTR``.
+This is usually implemented by maintaining a generation id for the
+structure and recording it in the ``seq`` member of struct netlink_callback.
+
+Netlink specification
+=====================
+
+Documentation of the Netlink specification parts which are only relevant
+to the kernel space.
+
+Globals
+-------
+
+kernel-policy
+~~~~~~~~~~~~~
+
+Defines whether the kernel validation policy is ``global`` i.e. the same for all
+operations of the family, defined for each operation individually - ``per-op``,
+or separately for each operation and operation type (do vs dump) - ``split``.
+New families should use ``per-op`` (default) to be able to narrow down the
+attributes accepted by a specific command.
+
+checks
+------
+
+Documentation for the ``checks`` sub-sections of attribute specs.
+
+unterminated-ok
+~~~~~~~~~~~~~~~
+
+Accept strings without the null-termination (for legacy families only).
+Switches from the ``NLA_NUL_STRING`` to ``NLA_STRING`` policy type.
+
+max-len
+~~~~~~~
+
+Defines max length for a binary or string attribute (corresponding
+to the ``len`` member of struct nla_policy). For string attributes terminating
+null character is not counted towards ``max-len``.
+
+The field may either be a literal integer value or a name of a defined
+constant. String types may reduce the constant by one
+(i.e. specify ``max-len: CONST - 1``) to reserve space for the terminating
+character so implementations should recognize such pattern.
+
+min-len
+~~~~~~~
+
+Similar to ``max-len`` but defines minimum length.
diff --git a/Documentation/core-api/packing.rst b/Documentation/core-api/packing.rst
index d8c341fe383e..f68f1e08fef9 100644
--- a/Documentation/core-api/packing.rst
+++ b/Documentation/core-api/packing.rst
@@ -151,16 +151,195 @@ the more significant 4-byte word.
We always think of our offsets as if there were no quirk, and we translate
them afterwards, before accessing the memory region.
+Note on buffer lengths not multiple of 4
+----------------------------------------
+
+To deal with memory layout quirks where groups of 4 bytes are laid out "little
+endian" relative to each other, but "big endian" within the group itself, the
+concept of groups of 4 bytes is intrinsic to the packing API (not to be
+confused with the memory access, which is performed byte by byte, though).
+
+With buffer lengths not multiple of 4, this means one group will be incomplete.
+Depending on the quirks, this may lead to discontinuities in the bit fields
+accessible through the buffer. The packing API assumes discontinuities were not
+the intention of the memory layout, so it avoids them by effectively logically
+shortening the most significant group of 4 octets to the number of octets
+actually available.
+
+Example with a 31 byte sized buffer given below. Physical buffer offsets are
+implicit, and increase from left to right within a group, and from top to
+bottom within a column.
+
+No quirks:
+
+::
+
+ 31 29 28 | Group 7 (most significant)
+ 27 26 25 24 | Group 6
+ 23 22 21 20 | Group 5
+ 19 18 17 16 | Group 4
+ 15 14 13 12 | Group 3
+ 11 10 9 8 | Group 2
+ 7 6 5 4 | Group 1
+ 3 2 1 0 | Group 0 (least significant)
+
+QUIRK_LSW32_IS_FIRST:
+
+::
+
+ 3 2 1 0 | Group 0 (least significant)
+ 7 6 5 4 | Group 1
+ 11 10 9 8 | Group 2
+ 15 14 13 12 | Group 3
+ 19 18 17 16 | Group 4
+ 23 22 21 20 | Group 5
+ 27 26 25 24 | Group 6
+ 30 29 28 | Group 7 (most significant)
+
+QUIRK_LITTLE_ENDIAN:
+
+::
+
+ 30 28 29 | Group 7 (most significant)
+ 24 25 26 27 | Group 6
+ 20 21 22 23 | Group 5
+ 16 17 18 19 | Group 4
+ 12 13 14 15 | Group 3
+ 8 9 10 11 | Group 2
+ 4 5 6 7 | Group 1
+ 0 1 2 3 | Group 0 (least significant)
+
+QUIRK_LITTLE_ENDIAN | QUIRK_LSW32_IS_FIRST:
+
+::
+
+ 0 1 2 3 | Group 0 (least significant)
+ 4 5 6 7 | Group 1
+ 8 9 10 11 | Group 2
+ 12 13 14 15 | Group 3
+ 16 17 18 19 | Group 4
+ 20 21 22 23 | Group 5
+ 24 25 26 27 | Group 6
+ 28 29 30 | Group 7 (most significant)
+
Intended use
------------
Drivers that opt to use this API first need to identify which of the above 3
quirk combinations (for a total of 8) match what the hardware documentation
-describes. Then they should wrap the packing() function, creating a new
-xxx_packing() that calls it using the proper QUIRK_* one-hot bits set.
+describes.
+
+There are 3 supported usage patterns, detailed below.
+
+packing()
+^^^^^^^^^
+
+This API function is deprecated.
The packing() function returns an int-encoded error code, which protects the
programmer against incorrect API use. The errors are not expected to occur
-durring runtime, therefore it is reasonable for xxx_packing() to return void
-and simply swallow those errors. Optionally it can dump stack or print the
-error description.
+during runtime, therefore it is reasonable to wrap packing() into a custom
+function which returns void and swallows those errors. Optionally it can
+dump stack or print the error description.
+
+.. code-block:: c
+
+ void my_packing(void *buf, u64 *val, int startbit, int endbit,
+ size_t len, enum packing_op op)
+ {
+ int err;
+
+ /* Adjust quirks accordingly */
+ err = packing(buf, val, startbit, endbit, len, op, QUIRK_LSW32_IS_FIRST);
+ if (likely(!err))
+ return;
+
+ if (err == -EINVAL) {
+ pr_err("Start bit (%d) expected to be larger than end (%d)\n",
+ startbit, endbit);
+ } else if (err == -ERANGE) {
+ if ((startbit - endbit + 1) > 64)
+ pr_err("Field %d-%d too large for 64 bits!\n",
+ startbit, endbit);
+ else
+ pr_err("Cannot store %llx inside bits %d-%d (would truncate)\n",
+ *val, startbit, endbit);
+ }
+ dump_stack();
+ }
+
+pack() and unpack()
+^^^^^^^^^^^^^^^^^^^
+
+These are const-correct variants of packing(), and eliminate the last "enum
+packing_op op" argument.
+
+Calling pack(...) is equivalent, and preferred, to calling packing(..., PACK).
+
+Calling unpack(...) is equivalent, and preferred, to calling packing(..., UNPACK).
+
+pack_fields() and unpack_fields()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The library exposes optimized functions for the scenario where there are many
+fields represented in a buffer, and it encourages consumer drivers to avoid
+repetitive calls to pack() and unpack() for each field, but instead use
+pack_fields() and unpack_fields(), which reduces the code footprint.
+
+These APIs use field definitions in arrays of ``struct packed_field_u8`` or
+``struct packed_field_u16``, allowing consumer drivers to minimize the size
+of these arrays according to their custom requirements.
+
+The pack_fields() and unpack_fields() API functions are actually macros which
+automatically select the appropriate function at compile time, based on the
+type of the fields array passed in.
+
+An additional benefit over pack() and unpack() is that sanity checks on the
+field definitions are handled at compile time with ``BUILD_BUG_ON`` rather
+than only when the offending code is executed. These functions return void and
+wrapping them to handle unexpected errors is not necessary.
+
+It is recommended, but not required, that you wrap your packed buffer into a
+structured type with a fixed size. This generally makes it easier for the
+compiler to enforce that the correct size buffer is used.
+
+Here is an example of how to use the fields APIs:
+
+.. code-block:: c
+
+ /* Ordering inside the unpacked structure is flexible and can be different
+ * from the packed buffer. Here, it is optimized to reduce padding.
+ */
+ struct data {
+ u64 field3;
+ u32 field4;
+ u16 field1;
+ u8 field2;
+ };
+
+ #define SIZE 13
+
+ typedef struct __packed { u8 buf[SIZE]; } packed_buf_t;
+
+ static const struct packed_field_u8 fields[] = {
+ PACKED_FIELD(100, 90, struct data, field1),
+ PACKED_FIELD(90, 87, struct data, field2),
+ PACKED_FIELD(86, 30, struct data, field3),
+ PACKED_FIELD(29, 0, struct data, field4),
+ };
+
+ void unpack_your_data(const packed_buf_t *buf, struct data *unpacked)
+ {
+ BUILD_BUG_ON(sizeof(*buf) != SIZE;
+
+ unpack_fields(buf, sizeof(*buf), unpacked, fields,
+ QUIRK_LITTLE_ENDIAN);
+ }
+
+ void pack_your_data(const struct data *unpacked, packed_buf_t *buf)
+ {
+ BUILD_BUG_ON(sizeof(*buf) != SIZE;
+
+ pack_fields(buf, sizeof(*buf), unpacked, fields,
+ QUIRK_LITTLE_ENDIAN);
+ }
diff --git a/Documentation/core-api/padata.rst b/Documentation/core-api/padata.rst
index 35175710b43c..05b73c6c105f 100644
--- a/Documentation/core-api/padata.rst
+++ b/Documentation/core-api/padata.rst
@@ -42,7 +42,7 @@ padata_shells associated with it, each allowing a separate series of jobs.
Modifying cpumasks
------------------
-The CPUs used to run jobs can be changed in two ways, programatically with
+The CPUs used to run jobs can be changed in two ways, programmatically with
padata_set_cpumask() or via sysfs. The former is defined::
int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type,
diff --git a/Documentation/core-api/parser.rst b/Documentation/core-api/parser.rst
new file mode 100644
index 000000000000..45750d04b895
--- /dev/null
+++ b/Documentation/core-api/parser.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+==============
+Generic parser
+==============
+
+Overview
+========
+
+The generic parser is a simple parser for parsing mount options,
+filesystem options, driver options, subsystem options, etc.
+
+Parser API
+==========
+
+.. kernel-doc:: lib/parser.c
+ :export:
diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst
index b18416f4500f..c16ca163b55e 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -55,18 +55,17 @@ flags the caller provides. The caller is required to pass in a non-null struct
pages* array, and the function then pins pages by incrementing each by a special
value: GUP_PIN_COUNTING_BIAS.
-For compound pages, the GUP_PIN_COUNTING_BIAS scheme is not used. Instead,
-an exact form of pin counting is achieved, by using the 2nd struct page
-in the compound page. A new struct page field, compound_pincount, has
-been added in order to support this.
-
-This approach for compound pages avoids the counting upper limit problems that
-are discussed below. Those limitations would have been aggravated severely by
-huge pages, because each tail page adds a refcount to the head page. And in
-fact, testing revealed that, without a separate compound_pincount field,
-page overflows were seen in some huge page stress tests.
-
-This also means that huge pages and compound pages do not suffer
+For large folios, the GUP_PIN_COUNTING_BIAS scheme is not used. Instead,
+the extra space available in the struct folio is used to store the
+pincount directly.
+
+This approach for large folios avoids the counting upper limit problems
+that are discussed below. Those limitations would have been aggravated
+severely by huge pages, because each tail page adds a refcount to the
+head page. And in fact, testing revealed that, without a separate pincount
+field, refcount overflows were seen in some huge page stress tests.
+
+This also means that huge pages and large folios do not suffer
from the false positives problem that is mentioned below.::
Function
@@ -113,6 +112,12 @@ pages:
This also leads to limitations: there are only 31-10==21 bits available for a
counter that increments 10 bits at a time.
+* Because of that limitation, special handling is applied to the zero pages
+ when using FOLL_PIN. We only pretend to pin a zero page - we don't alter its
+ refcount or pincount at all (it is permanent, so there's no need). The
+ unpinning functions also don't do anything to a zero page. This is
+ transparent to the caller.
+
* Callers must specifically request "dma-pinned tracking of pages". In other
words, just calling get_user_pages() will not suffice; a new set of functions,
pin_user_page() and related, must be used.
@@ -127,7 +132,7 @@ CASE 1: Direct IO (DIO)
-----------------------
There are GUP references to pages that are serving
as DIO buffers. These buffers are needed for a relatively short time (so they
-are not "long term"). No special synchronization with page_mkclean() or
+are not "long term"). No special synchronization with folio_mkclean() or
munmap() is provided. Therefore, flags to set at the call site are: ::
FOLL_PIN
@@ -139,7 +144,7 @@ CASE 2: RDMA
------------
There are GUP references to pages that are serving as DMA
buffers. These buffers are needed for a long time ("long term"). No special
-synchronization with page_mkclean() or munmap() is provided. Therefore, flags
+synchronization with folio_mkclean() or munmap() is provided. Therefore, flags
to set at the call site are: ::
FOLL_PIN | FOLL_LONGTERM
@@ -148,6 +153,8 @@ NOTE: Some pages, such as DAX pages, cannot be pinned with longterm pins. That's
because DAX pages do not have a separate page cache, and so "pinning" implies
locking down file system blocks, which is not (yet) supported in that way.
+.. _mmu-notifier-registration-case:
+
CASE 3: MMU notifier registration, with or without page faulting hardware
-------------------------------------------------------------------------
Device drivers can pin pages via get_user_pages*(), and register for mmu
@@ -163,7 +170,7 @@ callback, simply remove the range from the device's page tables.
Either way, as long as the driver unpins the pages upon mmu notifier callback,
then there is proper synchronization with both filesystem and mm
-(page_mkclean(), munmap(), etc). Therefore, neither flag needs to be set.
+(folio_mkclean(), munmap(), etc). Therefore, neither flag needs to be set.
CASE 4: Pinning for struct page manipulation only
-------------------------------------------------
@@ -189,20 +196,20 @@ INCORRECT (uses FOLL_GET calls):
write to the data within the pages
put_page()
-page_maybe_dma_pinned(): the whole point of pinning
-===================================================
+folio_maybe_dma_pinned(): the whole point of pinning
+====================================================
-The whole point of marking pages as "DMA-pinned" or "gup-pinned" is to be able
-to query, "is this page DMA-pinned?" That allows code such as page_mkclean()
+The whole point of marking folios as "DMA-pinned" or "gup-pinned" is to be able
+to query, "is this folio DMA-pinned?" That allows code such as folio_mkclean()
(and file system writeback code in general) to make informed decisions about
-what to do when a page cannot be unmapped due to such pins.
+what to do when a folio cannot be unmapped due to such pins.
What to do in those cases is the subject of a years-long series of discussions
and debates (see the References at the end of this document). It's a TODO item
here: fill in the details once that's worked out. Meanwhile, it's safe to say
that having this available: ::
- static inline bool page_maybe_dma_pinned(struct page *page)
+ static inline bool folio_maybe_dma_pinned(struct folio *folio)
...is a prerequisite to solving the long-running gup+DMA problem.
@@ -221,7 +228,7 @@ Unit testing
============
This file::
- tools/testing/selftests/vm/gup_test.c
+ tools/testing/selftests/mm/gup_test.c
has the following new calls to exercise the new pin*() wrapper functions:
@@ -264,9 +271,9 @@ place.)
Other diagnostics
=================
-dump_page() has been enhanced slightly, to handle these new counting
-fields, and to better report on compound pages in general. Specifically,
-for compound pages, the exact (compound_pincount) pincount is reported.
+dump_page() has been enhanced slightly to handle these new counting
+fields, and to better report on large folios in general. Specifically,
+for large folios, the exact pincount is reported.
References
==========
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index dbe1aacc79d0..c0b1b6089307 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -15,9 +15,10 @@ Integer types
If variable is of Type, use printk format specifier:
------------------------------------------------------------
- char %d or %x
+ signed char %d or %hhx
unsigned char %u or %x
- short int %d or %x
+ char %u or %x
+ short int %d or %hx
unsigned short int %u or %x
int %d or %x
unsigned int %u or %x
@@ -27,9 +28,9 @@ Integer types
unsigned long long %llu or %llx
size_t %zu or %zx
ssize_t %zd or %zx
- s8 %d or %x
+ s8 %d or %hhx
u8 %u or %x
- s16 %d or %x
+ s16 %d or %hx
u16 %u or %x
s32 %d or %x
u32 %u or %x
@@ -208,12 +209,17 @@ Struct Resources
::
%pr [mem 0x60000000-0x6fffffff flags 0x2200] or
+ [mem 0x60000000 flags 0x2200] or
[mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
+ [mem 0x0000000060000000 flags 0x2200]
%pR [mem 0x60000000-0x6fffffff pref] or
+ [mem 0x60000000 pref] or
[mem 0x0000000060000000-0x000000006fffffff pref]
+ [mem 0x0000000060000000 pref]
For printing struct resources. The ``R`` and ``r`` specifiers result in a
-printed resource with (R) or without (r) a decoded flags member.
+printed resource with (R) or without (r) a decoded flags member. If start is
+equal to end only print the start value.
Passed by reference.
@@ -230,6 +236,19 @@ width of the CPU data path.
Passed by reference.
+Struct Range
+------------
+
+::
+
+ %pra [range 0x0000000060000000-0x000000006fffffff] or
+ [range 0x0000000060000000]
+
+For printing struct range. struct range holds an arbitrary range of u64
+values. If start is equal to end only print the start value.
+
+Passed by reference.
+
DMA address types dma_addr_t
----------------------------
@@ -502,7 +521,7 @@ Fwnode handles
%pfw[fP]
-For printing information on fwnode handles. The default is to print the full
+For printing information on an fwnode_handle. The default is to print the full
node name, including the path. The modifiers are functionally equivalent to
%pOF above.
@@ -528,11 +547,13 @@ Time and date
%pt[RT]s YYYY-mm-dd HH:MM:SS
%pt[RT]d YYYY-mm-dd
%pt[RT]t HH:MM:SS
- %pt[RT][dt][r][s]
+ %ptSp <seconds>.<nanoseconds>
+ %pt[RST][dt][r][s]
For printing date and time as represented by::
- R struct rtc_time structure
+ R content of struct rtc_time
+ S content of struct timespec64
T time64_t type
in human readable format.
@@ -544,6 +565,11 @@ The %pt[RT]s (space) will override ISO 8601 separator by using ' ' (space)
instead of 'T' (Capital T) between date and time. It won't have any effect
when date or time is omitted.
+The %ptSp is equivalent to %lld.%09ld for the content of the struct timespec64.
+When the other specifiers are given, it becomes the respective equivalent of
+%ptT[dt][r][s].%09ld. In other words, the seconds are being printed in
+the human readable format followed by a dot and nanoseconds.
+
Passed by reference.
struct clk
@@ -552,9 +578,8 @@ struct clk
::
%pC pll1
- %pCn pll1
-For printing struct clk structures. %pC and %pCn print the name of the clock
+For printing struct clk structures. %pC prints the name of the clock
(Common Clock Framework) or a unique 32-bit ID (legacy clock framework).
Passed by reference.
@@ -575,8 +600,8 @@ The field width is passed by value, the bitmap is passed by reference.
Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
printing cpumask and nodemask.
-Flags bitfields such as page flags, gfp_flags
----------------------------------------------
+Flags bitfields such as page flags and gfp_flags
+--------------------------------------------------------
::
@@ -586,9 +611,13 @@ Flags bitfields such as page flags, gfp_flags
For printing flags bitfields as a collection of symbolic constants that
would construct the value. The type of flags is given by the third
-character. Currently supported are [p]age flags, [v]ma_flags (both
-expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag
-names and print order depends on the particular type.
+character. Currently supported are:
+
+ - p - [p]age flags, expects value of type (``unsigned long *``)
+ - v - [v]ma_flags, expects value of type (``unsigned long *``)
+ - g - [g]fp_flags, expects value of type (``gfp_t *``)
+
+The flag names and print order depends on the particular type.
Note that this format should not be used directly in the
:c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags()
@@ -625,6 +654,38 @@ Examples::
%p4cc Y10 little-endian (0x20303159)
%p4cc NV12 big-endian (0xb231564e)
+Generic FourCC code
+-------------------
+
+::
+ %p4c[h[R]lb] gP00 (0x67503030)
+
+Print a generic FourCC code, as both ASCII characters and its numerical
+value as hexadecimal.
+
+The generic FourCC code is always printed in the big-endian format,
+the most significant byte first. This is the opposite of V4L/DRM FourCCs.
+
+The additional ``h``, ``hR``, ``l``, and ``b`` specifiers define what
+endianness is used to load the stored bytes. The data might be interpreted
+using the host, reversed host byte order, little-endian, or big-endian.
+
+Passed by reference.
+
+Examples for a little-endian machine, given &(u32)0x67503030::
+
+ %p4ch gP00 (0x67503030)
+ %p4chR 00Pg (0x30305067)
+ %p4cl gP00 (0x67503030)
+ %p4cb 00Pg (0x30305067)
+
+Examples for a big-endian machine, given &(u32)0x67503030::
+
+ %p4ch gP00 (0x67503030)
+ %p4chR 00Pg (0x30305067)
+ %p4cl 00Pg (0x30305067)
+ %p4cb gP00 (0x67503030)
+
Rust
----
@@ -638,7 +699,7 @@ Do *not* use it from C.
Thanks
======
-If you add other %p extensions, please extend <lib/test_printf.c> with
-one or more test cases, if at all feasible.
+If you add other %p extensions, please extend <lib/tests/printf_kunit.c>
+with one or more test cases, if at all feasible.
Thank you for your cooperation and attention.
diff --git a/Documentation/core-api/printk-index.rst b/Documentation/core-api/printk-index.rst
index 3062f37d119b..1979c5dd32fe 100644
--- a/Documentation/core-api/printk-index.rst
+++ b/Documentation/core-api/printk-index.rst
@@ -4,7 +4,7 @@
Printk Index
============
-There are many ways how to monitor the state of the system. One important
+There are many ways to monitor the state of the system. One important
source of information is the system log. It provides a lot of information,
including more or less important warnings and error messages.
@@ -101,7 +101,7 @@ their own wrappers adding __printk_index_emit().
Only few subsystem specific wrappers have been updated so far,
for example, dev_printk(). As a result, the printk formats from
-some subsystes can be missing in the printk index.
+some subsystems can be missing in the printk index.
Subsystem specific prefix
diff --git a/Documentation/core-api/protection-keys.rst b/Documentation/core-api/protection-keys.rst
index bf28ac0401f3..7eb7c6023e09 100644
--- a/Documentation/core-api/protection-keys.rst
+++ b/Documentation/core-api/protection-keys.rst
@@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on:
* Intel server CPUs, Skylake and later
* Intel client CPUs, Tiger Lake (11th Gen Core) and later
* 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
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
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
========
@@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys::
int pkey_mprotect(unsigned long start, size_t len,
unsigned long prot, int pkey);
-Before a pkey can be used, it must first be allocated with
-pkey_alloc(). An application calls the WRPKRU instruction
-directly in order to change access permissions to memory covered
-with a key. In this example WRPKRU is wrapped by a C function
-called pkey_set().
+Before a pkey can be used, it must first be allocated with pkey_alloc(). An
+application writes to the architecture specific CPU register directly in order
+to change access permissions to memory covered with a key. In this example
+this is wrapped by a C function called pkey_set().
::
int real_prot = PROT_READ|PROT_WRITE;
@@ -64,9 +82,9 @@ is no longer in use::
munmap(ptr, PAGE_SIZE);
pkey_free(pkey);
-.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.
- An example implementation can be found in
- tools/testing/selftests/x86/protection_keys.c.
+.. note:: pkey_set() is a wrapper around writing to the CPU register.
+ Example implementations can be found in
+ tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h
Behavior
========
@@ -96,3 +114,7 @@ with a read()::
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
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().
diff --git a/Documentation/core-api/real-time/architecture-porting.rst b/Documentation/core-api/real-time/architecture-porting.rst
new file mode 100644
index 000000000000..d822fac29922
--- /dev/null
+++ b/Documentation/core-api/real-time/architecture-porting.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================================
+Porting an architecture to support PREEMPT_RT
+=============================================
+
+:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+This list outlines the architecture specific requirements that must be
+implemented in order to enable PREEMPT_RT. Once all required features are
+implemented, ARCH_SUPPORTS_RT can be selected in architecture’s Kconfig to make
+PREEMPT_RT selectable.
+Many prerequisites (genirq support for example) are enforced by the common code
+and are omitted here.
+
+The optional features are not strictly required but it is worth to consider
+them.
+
+Requirements
+------------
+
+Forced threaded interrupts
+ CONFIG_IRQ_FORCED_THREADING must be selected. Any interrupts that must
+ remain in hard-IRQ context must be marked with IRQF_NO_THREAD. This
+ requirement applies for instance to clocksource event interrupts,
+ perf interrupts and cascading interrupt-controller handlers.
+
+PREEMPTION support
+ Kernel preemption must be supported and requires that
+ CONFIG_ARCH_NO_PREEMPT remain unselected. Scheduling requests, such as those
+ issued from an interrupt or other exception handler, must be processed
+ immediately.
+
+POSIX CPU timers and KVM
+ POSIX CPU timers must expire from thread context rather than directly within
+ the timer interrupt. This behavior is enabled by setting the configuration
+ option CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK.
+ When KVM is enabled, CONFIG_KVM_XFER_TO_GUEST_WORK must also be set to ensure
+ that any pending work, such as POSIX timer expiration, is handled before
+ transitioning into guest mode.
+
+Hard-IRQ and Soft-IRQ stacks
+ Soft interrupts are handled in the thread context in which they are raised. If
+ a soft interrupt is triggered from hard-IRQ context, its execution is deferred
+ to the ksoftirqd thread. Preemption is never disabled during soft interrupt
+ handling, which makes soft interrupts preemptible.
+ If an architecture provides a custom __do_softirq() implementation that uses a
+ separate stack, it must select CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK. The
+ functionality should only be enabled when CONFIG_SOFTIRQ_ON_OWN_STACK is set.
+
+FPU and SIMD access in kernel mode
+ FPU and SIMD registers are typically not used in kernel mode and are therefore
+ not saved during kernel preemption. As a result, any kernel code that uses
+ these registers must be enclosed within a kernel_fpu_begin() and
+ kernel_fpu_end() section.
+ The kernel_fpu_begin() function usually invokes local_bh_disable() to prevent
+ interruptions from softirqs and to disable regular preemption. This allows the
+ protected code to run safely in both thread and softirq contexts.
+ On PREEMPT_RT kernels, however, kernel_fpu_begin() must not call
+ local_bh_disable(). Instead, it should use preempt_disable(), since softirqs
+ are always handled in thread context under PREEMPT_RT. In this case, disabling
+ preemption alone is sufficient.
+ The crypto subsystem operates on memory pages and requires users to "walk and
+ map" these pages while processing a request. This operation must occur outside
+ the kernel_fpu_begin()/ kernel_fpu_end() section because it requires preemption
+ to be enabled. These preemption points are generally sufficient to avoid
+ excessive scheduling latency.
+
+Exception handlers
+ Exception handlers, such as the page fault handler, typically enable interrupts
+ early, before invoking any generic code to process the exception. This is
+ necessary because handling a page fault may involve operations that can sleep.
+ Enabling interrupts is especially important on PREEMPT_RT, where certain
+ locks, such as spinlock_t, become sleepable. For example, handling an
+ invalid opcode may result in sending a SIGILL signal to the user task. A
+ debug excpetion will send a SIGTRAP signal.
+ In both cases, if the exception occurred in user space, it is safe to enable
+ interrupts early. Sending a signal requires both interrupts and kernel
+ preemption to be enabled.
+
+Optional features
+-----------------
+
+Timer and clocksource
+ A high-resolution clocksource and clockevents device are recommended. The
+ clockevents device should support the CLOCK_EVT_FEAT_ONESHOT feature for
+ optimal timer behavior. In most cases, microsecond-level accuracy is
+ sufficient
+
+Lazy preemption
+ This mechanism allows an in-kernel scheduling request for non-real-time tasks
+ to be delayed until the task is about to return to user space. It helps avoid
+ preempting a task that holds a sleeping lock at the time of the scheduling
+ request.
+ With CONFIG_GENERIC_IRQ_ENTRY enabled, supporting this feature requires
+ defining a bit for TIF_NEED_RESCHED_LAZY, preferably near TIF_NEED_RESCHED.
+
+Serial console with NBCON
+ With PREEMPT_RT enabled, all console output is handled by a dedicated thread
+ rather than directly from the context in which printk() is invoked. This design
+ allows printk() to be safely used in atomic contexts.
+ However, this also means that if the kernel crashes and cannot switch to the
+ printing thread, no output will be visible preventing the system from printing
+ its final messages.
+ There are exceptions for immediate output, such as during panic() handling. To
+ support this, the console driver must implement new-style lock handling. This
+ involves setting the CON_NBCON flag in console::flags and providing
+ implementations for the write_atomic, write_thread, device_lock, and
+ device_unlock callbacks.
diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
new file mode 100644
index 000000000000..83ec9aa1c61a
--- /dev/null
+++ b/Documentation/core-api/real-time/differences.rst
@@ -0,0 +1,242 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+How realtime kernels differ
+===========================
+
+:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+Preface
+=======
+
+With forced-threaded interrupts and sleeping spin locks, code paths that
+previously caused long scheduling latencies have been made preemptible and
+moved into process context. This allows the scheduler to manage them more
+effectively and respond to higher-priority tasks with reduced latency.
+
+The following chapters provide an overview of key differences between a
+PREEMPT_RT kernel and a standard, non-PREEMPT_RT kernel.
+
+Locking
+=======
+
+Spinning locks such as spinlock_t are used to provide synchronization for data
+structures accessed from both interrupt context and process context. For this
+reason, locking functions are also available with the _irq() or _irqsave()
+suffixes, which disable interrupts before acquiring the lock. This ensures that
+the lock can be safely acquired in process context when interrupts are enabled.
+
+However, on a PREEMPT_RT system, interrupts are forced-threaded and no longer
+run in hard IRQ context. As a result, there is no need to disable interrupts as
+part of the locking procedure when using spinlock_t.
+
+For low-level core components such as interrupt handling, the scheduler, or the
+timer subsystem the kernel uses raw_spinlock_t. This lock type preserves
+traditional semantics: it disables preemption and, when used with _irq() or
+_irqsave(), also disables interrupts. This ensures proper synchronization in
+critical sections that must remain non-preemptible or with interrupts disabled.
+
+Execution context
+=================
+
+Interrupt handling in a PREEMPT_RT system is invoked in process context through
+the use of threaded interrupts. Other parts of the kernel also shift their
+execution into threaded context by different mechanisms. The goal is to keep
+execution paths preemptible, allowing the scheduler to interrupt them when a
+higher-priority task needs to run.
+
+Below is an overview of the kernel subsystems involved in this transition to
+threaded, preemptible execution.
+
+Interrupt handling
+------------------
+
+All interrupts are forced-threaded in a PREEMPT_RT system. The exceptions are
+interrupts that are requested with the IRQF_NO_THREAD, IRQF_PERCPU, or
+IRQF_ONESHOT flags.
+
+The IRQF_ONESHOT flag is used together with threaded interrupts, meaning those
+registered using request_threaded_irq() and providing only a threaded handler.
+Its purpose is to keep the interrupt line masked until the threaded handler has
+completed.
+
+If a primary handler is also provided in this case, it is essential that the
+handler does not acquire any sleeping locks, as it will not be threaded. The
+handler should be minimal and must avoid introducing delays, such as
+busy-waiting on hardware registers.
+
+
+Soft interrupts, bottom half handling
+-------------------------------------
+
+Soft interrupts are raised by the interrupt handler and are executed after the
+handler returns. Since they run in thread context, they can be preempted by
+other threads. Do not assume that softirq context runs with preemption
+disabled. This means you must not rely on mechanisms like local_bh_disable() in
+process context to protect per-CPU variables. Because softirq handlers are
+preemptible under PREEMPT_RT, this approach does not provide reliable
+synchronization.
+
+If this kind of protection is required for performance reasons, consider using
+local_lock_nested_bh(). On non-PREEMPT_RT kernels, this allows lockdep to
+verify that bottom halves are disabled. On PREEMPT_RT systems, it adds the
+necessary locking to ensure proper protection.
+
+Using local_lock_nested_bh() also makes the locking scope explicit and easier
+for readers and maintainers to understand.
+
+
+per-CPU variables
+-----------------
+
+Protecting access to per-CPU variables solely by using preempt_disable() should
+be avoided, especially if the critical section has unbounded runtime or may
+call APIs that can sleep.
+
+If using a spinlock_t is considered too costly for performance reasons,
+consider using local_lock_t. On non-PREEMPT_RT configurations, this introduces
+no runtime overhead when lockdep is disabled. With lockdep enabled, it verifies
+that the lock is only acquired in process context and never from softirq or
+hard IRQ context.
+
+On a PREEMPT_RT kernel, local_lock_t is implemented using a per-CPU spinlock_t,
+which provides safe local protection for per-CPU data while keeping the system
+preemptible.
+
+Because spinlock_t on PREEMPT_RT does not disable preemption, it cannot be used
+to protect per-CPU data by relying on implicit preemption disabling. If this
+inherited preemption disabling is essential and if local_lock_t cannot be used
+due to performance constraints, brevity of the code, or abstraction boundaries
+within an API then preempt_disable_nested() may be a suitable alternative. On
+non-PREEMPT_RT kernels, it verifies with lockdep that preemption is already
+disabled. On PREEMPT_RT, it explicitly disables preemption.
+
+Timers
+------
+
+By default, an hrtimer is executed in hard interrupt context. The exception is
+timers initialized with the HRTIMER_MODE_SOFT flag, which are executed in
+softirq context.
+
+On a PREEMPT_RT kernel, this behavior is reversed: hrtimers are executed in
+softirq context by default, typically within the ktimersd thread. This thread
+runs at the lowest real-time priority, ensuring it executes before any
+SCHED_OTHER tasks but does not interfere with higher-priority real-time
+threads. To explicitly request execution in hard interrupt context on
+PREEMPT_RT, the timer must be marked with the HRTIMER_MODE_HARD flag.
+
+Memory allocation
+-----------------
+
+The memory allocation APIs, such as kmalloc() and alloc_pages(), require a
+gfp_t flag to indicate the allocation context. On non-PREEMPT_RT kernels, it is
+necessary to use GFP_ATOMIC when allocating memory from interrupt context or
+from sections where preemption is disabled. This is because the allocator must
+not sleep in these contexts waiting for memory to become available.
+
+However, this approach does not work on PREEMPT_RT kernels. The memory
+allocator in PREEMPT_RT uses sleeping locks internally, which cannot be
+acquired when preemption is disabled. Fortunately, this is generally not a
+problem, because PREEMPT_RT moves most contexts that would traditionally run
+with preemption or interrupts disabled into threaded context, where sleeping is
+allowed.
+
+What remains problematic is code that explicitly disables preemption or
+interrupts. In such cases, memory allocation must be performed outside the
+critical section.
+
+This restriction also applies to memory deallocation routines such as kfree()
+and free_pages(), which may also involve internal locking and must not be
+called from non-preemptible contexts.
+
+IRQ work
+--------
+
+The irq_work API provides a mechanism to schedule a callback in interrupt
+context. It is designed for use in contexts where traditional scheduling is not
+possible, such as from within NMI handlers or from inside the scheduler, where
+using a workqueue would be unsafe.
+
+On non-PREEMPT_RT systems, all irq_work items are executed immediately in
+interrupt context. Items marked with IRQ_WORK_LAZY are deferred until the next
+timer tick but are still executed in interrupt context.
+
+On PREEMPT_RT systems, the execution model changes. Because irq_work callbacks
+may acquire sleeping locks or have unbounded execution time, they are handled
+in thread context by a per-CPU irq_work kernel thread. This thread runs at the
+lowest real-time priority, ensuring it executes before any SCHED_OTHER tasks
+but does not interfere with higher-priority real-time threads.
+
+The exception are work items marked with IRQ_WORK_HARD_IRQ, which are still
+executed in hard interrupt context. Lazy items (IRQ_WORK_LAZY) continue to be
+deferred until the next timer tick and are also executed by the irq_work/
+thread.
+
+RCU callbacks
+-------------
+
+RCU callbacks are invoked by default in softirq context. Their execution is
+important because, depending on the use case, they either free memory or ensure
+progress in state transitions. Running these callbacks as part of the softirq
+chain can lead to undesired situations, such as contention for CPU resources
+with other SCHED_OTHER tasks when executed within ksoftirqd.
+
+To avoid running callbacks in softirq context, the RCU subsystem provides a
+mechanism to execute them in process context instead. This behavior can be
+enabled by setting the boot command-line parameter rcutree.use_softirq=0. This
+setting is enforced in kernels configured with PREEMPT_RT.
+
+Spin until ready
+================
+
+The "spin until ready" pattern involves repeatedly checking (spinning on) the
+state of a data structure until it becomes available. This pattern assumes that
+preemption, soft interrupts, or interrupts are disabled. If the data structure
+is marked busy, it is presumed to be in use by another CPU, and spinning should
+eventually succeed as that CPU makes progress.
+
+Some examples are hrtimer_cancel() or timer_delete_sync(). These functions
+cancel timers that execute with interrupts or soft interrupts disabled. If a
+thread attempts to cancel a timer and finds it active, spinning until the
+callback completes is safe because the callback can only run on another CPU and
+will eventually finish.
+
+On PREEMPT_RT kernels, however, timer callbacks run in thread context. This
+introduces a challenge: a higher-priority thread attempting to cancel the timer
+may preempt the timer callback thread. Since the scheduler cannot migrate the
+callback thread to another CPU due to affinity constraints, spinning can result
+in livelock even on multiprocessor systems.
+
+To avoid this, both the canceling and callback sides must use a handshake
+mechanism that supports priority inheritance. This allows the canceling thread
+to suspend until the callback completes, ensuring forward progress without
+risking livelock.
+
+In order to solve the problem at the API level, the sequence locks were extended
+to allow a proper handover between the the spinning reader and the maybe
+blocked writer.
+
+Sequence locks
+--------------
+
+Sequence counters and sequential locks are documented in
+Documentation/locking/seqlock.rst.
+
+The interface has been extended to ensure proper preemption states for the
+writer and spinning reader contexts. This is achieved by embedding the writer
+serialization lock directly into the sequence counter type, resulting in
+composite types such as seqcount_spinlock_t or seqcount_mutex_t.
+
+These composite types allow readers to detect an ongoing write and actively
+boost the writer’s priority to help it complete its update instead of spinning
+and waiting for its completion.
+
+If the plain seqcount_t is used, extra care must be taken to synchronize the
+reader with the writer during updates. The writer must ensure its update is
+serialized and non-preemptible relative to the reader. This cannot be achieved
+using a regular spinlock_t because spinlock_t on PREEMPT_RT does not disable
+preemption. In such cases, using seqcount_spinlock_t is the preferred solution.
+
+However, if there is no spinning involved i.e., if the reader only needs to
+detect whether a write has started and not serialize against it then using
+seqcount_t is reasonable.
diff --git a/Documentation/core-api/real-time/index.rst b/Documentation/core-api/real-time/index.rst
new file mode 100644
index 000000000000..7e14c4ea3d59
--- /dev/null
+++ b/Documentation/core-api/real-time/index.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Real-time preemption
+=====================
+
+This documentation is intended for Linux kernel developers and contributors
+interested in the inner workings of PREEMPT_RT. It explains key concepts and
+the required changes compared to a non-PREEMPT_RT configuration.
+
+.. toctree::
+ :maxdepth: 2
+
+ theory
+ differences
+ architecture-porting
diff --git a/Documentation/core-api/real-time/theory.rst b/Documentation/core-api/real-time/theory.rst
new file mode 100644
index 000000000000..43d0120737f8
--- /dev/null
+++ b/Documentation/core-api/real-time/theory.rst
@@ -0,0 +1,116 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Theory of operation
+=====================
+
+:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+Preface
+=======
+
+PREEMPT_RT transforms the Linux kernel into a real-time kernel. It achieves
+this by replacing locking primitives, such as spinlock_t, with a preemptible
+and priority-inheritance aware implementation known as rtmutex, and by enforcing
+the use of threaded interrupts. As a result, the kernel becomes fully
+preemptible, with the exception of a few critical code paths, including entry
+code, the scheduler, and low-level interrupt handling routines.
+
+This transformation places the majority of kernel execution contexts under the
+control of the scheduler and significantly increasing the number of preemption
+points. Consequently, it reduces the latency between a high-priority task
+becoming runnable and its actual execution on the CPU.
+
+Scheduling
+==========
+
+The core principles of Linux scheduling and the associated user-space API are
+documented in the man page sched(7)
+`sched(7) <https://man7.org/linux/man-pages/man7/sched.7.html>`_.
+By default, the Linux kernel uses the SCHED_OTHER scheduling policy. Under
+this policy, a task is preempted when the scheduler determines that it has
+consumed a fair share of CPU time relative to other runnable tasks. However,
+the policy does not guarantee immediate preemption when a new SCHED_OTHER task
+becomes runnable. The currently running task may continue executing.
+
+This behavior differs from that of real-time scheduling policies such as
+SCHED_FIFO. When a task with a real-time policy becomes runnable, the
+scheduler immediately selects it for execution if it has a higher priority than
+the currently running task. The task continues to run until it voluntarily
+yields the CPU, typically by blocking on an event.
+
+Sleeping spin locks
+===================
+
+The various lock types and their behavior under real-time configurations are
+described in detail in Documentation/locking/locktypes.rst.
+In a non-PREEMPT_RT configuration, a spinlock_t is acquired by first disabling
+preemption and then actively spinning until the lock becomes available. Once
+the lock is released, preemption is enabled. From a real-time perspective,
+this approach is undesirable because disabling preemption prevents the
+scheduler from switching to a higher-priority task, potentially increasing
+latency.
+
+To address this, PREEMPT_RT replaces spinning locks with sleeping spin locks
+that do not disable preemption. On PREEMPT_RT, spinlock_t is implemented using
+rtmutex. Instead of spinning, a task attempting to acquire a contended lock
+disables CPU migration, donates its priority to the lock owner (priority
+inheritance), and voluntarily schedules out while waiting for the lock to
+become available.
+
+Disabling CPU migration provides the same effect as disabling preemption, while
+still allowing preemption and ensuring that the task continues to run on the
+same CPU while holding a sleeping lock.
+
+Priority inheritance
+====================
+
+Lock types such as spinlock_t and mutex_t in a PREEMPT_RT enabled kernel are
+implemented on top of rtmutex, which provides support for priority inheritance
+(PI). When a task blocks on such a lock, the PI mechanism temporarily
+propagates the blocked task’s scheduling parameters to the lock owner.
+
+For example, if a SCHED_FIFO task A blocks on a lock currently held by a
+SCHED_OTHER task B, task A’s scheduling policy and priority are temporarily
+inherited by task B. After this inheritance, task A is put to sleep while
+waiting for the lock, and task B effectively becomes the highest-priority task
+in the system. This allows B to continue executing, make progress, and
+eventually release the lock.
+
+Once B releases the lock, it reverts to its original scheduling parameters, and
+task A can resume execution.
+
+Threaded interrupts
+===================
+
+Interrupt handlers are another source of code that executes with preemption
+disabled and outside the control of the scheduler. To bring interrupt handling
+under scheduler control, PREEMPT_RT enforces threaded interrupt handlers.
+
+With forced threading, interrupt handling is split into two stages. The first
+stage, the primary handler, is executed in IRQ context with interrupts disabled.
+Its sole responsibility is to wake the associated threaded handler. The second
+stage, the threaded handler, is the function passed to request_irq() as the
+interrupt handler. It runs in process context, scheduled by the kernel.
+
+From waking the interrupt thread until threaded handling is completed, the
+interrupt source is masked in the interrupt controller. This ensures that the
+device interrupt remains pending but does not retrigger the CPU, allowing the
+system to exit IRQ context and handle the interrupt in a scheduled thread.
+
+By default, the threaded handler executes with the SCHED_FIFO scheduling policy
+and a priority of 50 (MAX_RT_PRIO / 2), which is midway between the minimum and
+maximum real-time priorities.
+
+If the threaded interrupt handler raises any soft interrupts during its
+execution, those soft interrupt routines are invoked after the threaded handler
+completes, within the same thread. Preemption remains enabled during the
+execution of the soft interrupt handler.
+
+Summary
+=======
+
+By using sleeping locks and forced-threaded interrupts, PREEMPT_RT
+significantly reduces sections of code where interrupts or preemption is
+disabled, allowing the scheduler to preempt the current execution context and
+switch to a higher-priority task.
diff --git a/Documentation/core-api/refcount-vs-atomic.rst b/Documentation/core-api/refcount-vs-atomic.rst
index 79a009ce11df..94e628c1eb49 100644
--- a/Documentation/core-api/refcount-vs-atomic.rst
+++ b/Documentation/core-api/refcount-vs-atomic.rst
@@ -86,7 +86,19 @@ Memory ordering guarantee changes:
* none (both fully unordered)
-case 2) - increment-based ops that return no value
+case 2) - non-"Read/Modify/Write" (RMW) ops with release ordering
+-----------------------------------------------------------------
+
+Function changes:
+
+ * atomic_set_release() --> refcount_set_release()
+
+Memory ordering guarantee changes:
+
+ * none (both provide RELEASE ordering)
+
+
+case 3) - increment-based ops that return no value
--------------------------------------------------
Function changes:
@@ -98,7 +110,7 @@ Memory ordering guarantee changes:
* none (both fully unordered)
-case 3) - decrement-based RMW ops that return no value
+case 4) - decrement-based RMW ops that return no value
------------------------------------------------------
Function changes:
@@ -110,7 +122,7 @@ Memory ordering guarantee changes:
* fully unordered --> RELEASE ordering
-case 4) - increment-based RMW ops that return a value
+case 5) - increment-based RMW ops that return a value
-----------------------------------------------------
Function changes:
@@ -126,7 +138,20 @@ Memory ordering guarantees changes:
result of obtaining pointer to the object!
-case 5) - generic dec/sub decrement-based RMW ops that return a value
+case 6) - increment-based RMW ops with acquire ordering that return a value
+---------------------------------------------------------------------------
+
+Function changes:
+
+ * atomic_inc_not_zero() --> refcount_inc_not_zero_acquire()
+ * no atomic counterpart --> refcount_add_not_zero_acquire()
+
+Memory ordering guarantees changes:
+
+ * fully ordered --> ACQUIRE ordering on success
+
+
+case 7) - generic dec/sub decrement-based RMW ops that return a value
---------------------------------------------------------------------
Function changes:
@@ -139,7 +164,7 @@ Memory ordering guarantees changes:
* fully ordered --> RELEASE ordering + ACQUIRE ordering on success
-case 6) other decrement-based RMW ops that return a value
+case 8) other decrement-based RMW ops that return a value
---------------------------------------------------------
Function changes:
@@ -154,7 +179,7 @@ Memory ordering guarantees changes:
.. note:: atomic_add_unless() only provides full order on success.
-case 7) - lock-based RMW
+case 9) - lock-based RMW
------------------------
Function changes:
diff --git a/Documentation/core-api/swiotlb.rst b/Documentation/core-api/swiotlb.rst
new file mode 100644
index 000000000000..9e0fe027dd3b
--- /dev/null
+++ b/Documentation/core-api/swiotlb.rst
@@ -0,0 +1,321 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+DMA and swiotlb
+===============
+
+swiotlb is a memory buffer allocator used by the Linux kernel DMA layer. It is
+typically used when a device doing DMA can't directly access the target memory
+buffer because of hardware limitations or other requirements. In such a case,
+the DMA layer calls swiotlb to allocate a temporary memory buffer that conforms
+to the limitations. The DMA is done to/from this temporary memory buffer, and
+the CPU copies the data between the temporary buffer and the original target
+memory buffer. This approach is generically called "bounce buffering", and the
+temporary memory buffer is called a "bounce buffer".
+
+Device drivers don't interact directly with swiotlb. Instead, drivers inform
+the DMA layer of the DMA attributes of the devices they are managing, and use
+the normal DMA map, unmap, and sync APIs when programming a device to do DMA.
+These APIs use the device DMA attributes and kernel-wide settings to determine
+if bounce buffering is necessary. If so, the DMA layer manages the allocation,
+freeing, and sync'ing of bounce buffers. Since the DMA attributes are per
+device, some devices in a system may use bounce buffering while others do not.
+
+Because the CPU copies data between the bounce buffer and the original target
+memory buffer, doing bounce buffering is slower than doing DMA directly to the
+original memory buffer, and it consumes more CPU resources. So it is used only
+when necessary for providing DMA functionality.
+
+Usage Scenarios
+---------------
+swiotlb was originally created to handle DMA for devices with addressing
+limitations. As physical memory sizes grew beyond 4 GiB, some devices could
+only provide 32-bit DMA addresses. By allocating bounce buffer memory below
+the 4 GiB line, these devices with addressing limitations could still work and
+do DMA.
+
+More recently, Confidential Computing (CoCo) VMs have the guest VM's memory
+encrypted by default, and the memory is not accessible by the host hypervisor
+and VMM. For the host to do I/O on behalf of the guest, the I/O must be
+directed to guest memory that is unencrypted. CoCo VMs set a kernel-wide option
+to force all DMA I/O to use bounce buffers, and the bounce buffer memory is set
+up as unencrypted. The host does DMA I/O to/from the bounce buffer memory, and
+the Linux kernel DMA layer does "sync" operations to cause the CPU to copy the
+data to/from the original target memory buffer. The CPU copying bridges between
+the unencrypted and the encrypted memory. This use of bounce buffers allows
+device drivers to "just work" in a CoCo VM, with no modifications
+needed to handle the memory encryption complexity.
+
+Other edge case scenarios arise for bounce buffers. For example, when IOMMU
+mappings are set up for a DMA operation to/from a device that is considered
+"untrusted", the device should be given access only to the memory containing
+the data being transferred. But if that memory occupies only part of an IOMMU
+granule, other parts of the granule may contain unrelated kernel data. Since
+IOMMU access control is per-granule, the untrusted device can gain access to
+the unrelated kernel data. This problem is solved by bounce buffering the DMA
+operation and ensuring that unused portions of the bounce buffers do not
+contain any unrelated kernel data.
+
+Core Functionality
+------------------
+The primary swiotlb APIs are swiotlb_tbl_map_single() and
+swiotlb_tbl_unmap_single(). The "map" API allocates a bounce buffer of a
+specified size in bytes and returns the physical address of the buffer. The
+buffer memory is physically contiguous. The expectation is that the DMA layer
+maps the physical memory address to a DMA address, and returns the DMA address
+to the driver for programming into the device. If a DMA operation specifies
+multiple memory buffer segments, a separate bounce buffer must be allocated for
+each segment. swiotlb_tbl_map_single() always does a "sync" operation (i.e., a
+CPU copy) to initialize the bounce buffer to match the contents of the original
+buffer.
+
+swiotlb_tbl_unmap_single() does the reverse. If the DMA operation might have
+updated the bounce buffer memory and DMA_ATTR_SKIP_CPU_SYNC is not set, the
+unmap does a "sync" operation to cause a CPU copy of the data from the bounce
+buffer back to the original buffer. Then the bounce buffer memory is freed.
+
+swiotlb also provides "sync" APIs that correspond to the dma_sync_*() APIs that
+a driver may use when control of a buffer transitions between the CPU and the
+device. The swiotlb "sync" APIs cause a CPU copy of the data between the
+original buffer and the bounce buffer. Like the dma_sync_*() APIs, the swiotlb
+"sync" APIs support doing a partial sync, where only a subset of the bounce
+buffer is copied to/from the original buffer.
+
+Core Functionality Constraints
+------------------------------
+The swiotlb map/unmap/sync APIs must operate without blocking, as they are
+called by the corresponding DMA APIs which may run in contexts that cannot
+block. Hence the default memory pool for swiotlb allocations must be
+pre-allocated at boot time (but see Dynamic swiotlb below). Because swiotlb
+allocations must be physically contiguous, the entire default memory pool is
+allocated as a single contiguous block.
+
+The need to pre-allocate the default swiotlb pool creates a boot-time tradeoff.
+The pool should be large enough to ensure that bounce buffer requests can
+always be satisfied, as the non-blocking requirement means requests can't wait
+for space to become available. But a large pool potentially wastes memory, as
+this pre-allocated memory is not available for other uses in the system. The
+tradeoff is particularly acute in CoCo VMs that use bounce buffers for all DMA
+I/O. These VMs use a heuristic to set the default pool size to ~6% of memory,
+with a max of 1 GiB, which has the potential to be very wasteful of memory.
+Conversely, the heuristic might produce a size that is insufficient, depending
+on the I/O patterns of the workload in the VM. The dynamic swiotlb feature
+described below can help, but has limitations. Better management of the swiotlb
+default memory pool size remains an open issue.
+
+A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE
+bytes, which is 256 KiB with current definitions. When a device's DMA settings
+are such that the device might use swiotlb, the maximum size of a DMA segment
+must be limited to that 256 KiB. This value is communicated to higher-level
+kernel code via dma_map_mapping_size() and swiotlb_max_mapping_size(). If the
+higher-level code fails to account for this limit, it may make requests that
+are too large for swiotlb, and get a "swiotlb full" error.
+
+A key device DMA setting is "min_align_mask", which is a power of 2 minus 1
+so that some number of low order bits are set, or it may be zero. swiotlb
+allocations ensure these min_align_mask bits of the physical address of the
+bounce buffer match the same bits in the address of the original buffer. When
+min_align_mask is non-zero, it may produce an "alignment offset" in the address
+of the bounce buffer that slightly reduces the maximum size of an allocation.
+This potential alignment offset is reflected in the value returned by
+swiotlb_max_mapping_size(), which can show up in places like
+/sys/block/<device>/queue/max_sectors_kb. For example, if a device does not use
+swiotlb, max_sectors_kb might be 512 KiB or larger. If a device might use
+swiotlb, max_sectors_kb will be 256 KiB. When min_align_mask is non-zero,
+max_sectors_kb might be even smaller, such as 252 KiB.
+
+swiotlb_tbl_map_single() also takes an "alloc_align_mask" parameter. This
+parameter specifies the allocation of bounce buffer space must start at a
+physical address with the alloc_align_mask bits set to zero. But the actual
+bounce buffer might start at a larger address if min_align_mask is non-zero.
+Hence there may be pre-padding space that is allocated prior to the start of
+the bounce buffer. Similarly, the end of the bounce buffer is rounded up to an
+alloc_align_mask boundary, potentially resulting in post-padding space. Any
+pre-padding or post-padding space is not initialized by swiotlb code. The
+"alloc_align_mask" parameter is used by IOMMU code when mapping for untrusted
+devices. It is set to the granule size - 1 so that the bounce buffer is
+allocated entirely from granules that are not used for any other purpose.
+
+Data structures concepts
+------------------------
+Memory used for swiotlb bounce buffers is allocated from overall system memory
+as one or more "pools". The default pool is allocated during system boot with a
+default size of 64 MiB. The default pool size may be modified with the
+"swiotlb=" kernel boot line parameter. The default size may also be adjusted
+due to other conditions, such as running in a CoCo VM, as described above. If
+CONFIG_SWIOTLB_DYNAMIC is enabled, additional pools may be allocated later in
+the life of the system. Each pool must be a contiguous range of physical
+memory. The default pool is allocated below the 4 GiB physical address line so
+it works for devices that can only address 32-bits of physical memory (unless
+architecture-specific code provides the SWIOTLB_ANY flag). In a CoCo VM, the
+pool memory must be decrypted before swiotlb is used.
+
+Each pool is divided into "slots" of size IO_TLB_SIZE, which is 2 KiB with
+current definitions. IO_TLB_SEGSIZE contiguous slots (128 slots) constitute
+what might be called a "slot set". When a bounce buffer is allocated, it
+occupies one or more contiguous slots. A slot is never shared by multiple
+bounce buffers. Furthermore, a bounce buffer must be allocated from a single
+slot set, which leads to the maximum bounce buffer size being IO_TLB_SIZE *
+IO_TLB_SEGSIZE. Multiple smaller bounce buffers may co-exist in a single slot
+set if the alignment and size constraints can be met.
+
+Slots are also grouped into "areas", with the constraint that a slot set exists
+entirely in a single area. Each area has its own spin lock that must be held to
+manipulate the slots in that area. The division into areas avoids contending
+for a single global spin lock when swiotlb is heavily used, such as in a CoCo
+VM. The number of areas defaults to the number of CPUs in the system for
+maximum parallelism, but since an area can't be smaller than IO_TLB_SEGSIZE
+slots, it might be necessary to assign multiple CPUs to the same area. The
+number of areas can also be set via the "swiotlb=" kernel boot parameter.
+
+When allocating a bounce buffer, if the area associated with the calling CPU
+does not have enough free space, areas associated with other CPUs are tried
+sequentially. For each area tried, the area's spin lock must be obtained before
+trying an allocation, so contention may occur if swiotlb is relatively busy
+overall. But an allocation request does not fail unless all areas do not have
+enough free space.
+
+IO_TLB_SIZE, IO_TLB_SEGSIZE, and the number of areas must all be powers of 2 as
+the code uses shifting and bit masking to do many of the calculations. The
+number of areas is rounded up to a power of 2 if necessary to meet this
+requirement.
+
+The default pool is allocated with PAGE_SIZE alignment. If an alloc_align_mask
+argument to swiotlb_tbl_map_single() specifies a larger alignment, one or more
+initial slots in each slot set might not meet the alloc_align_mask criterium.
+Because a bounce buffer allocation can't cross a slot set boundary, eliminating
+those initial slots effectively reduces the max size of a bounce buffer.
+Currently, there's no problem because alloc_align_mask is set based on IOMMU
+granule size, and granules cannot be larger than PAGE_SIZE. But if that were to
+change in the future, the initial pool allocation might need to be done with
+alignment larger than PAGE_SIZE.
+
+Dynamic swiotlb
+---------------
+When CONFIG_SWIOTLB_DYNAMIC is enabled, swiotlb can do on-demand expansion of
+the amount of memory available for allocation as bounce buffers. If a bounce
+buffer request fails due to lack of available space, an asynchronous background
+task is kicked off to allocate memory from general system memory and turn it
+into an swiotlb pool. Creating an additional pool must be done asynchronously
+because the memory allocation may block, and as noted above, swiotlb requests
+are not allowed to block. Once the background task is kicked off, the bounce
+buffer request creates a "transient pool" to avoid returning an "swiotlb full"
+error. A transient pool has the size of the bounce buffer request, and is
+deleted when the bounce buffer is freed. Memory for this transient pool comes
+from the general system memory atomic pool so that creation does not block.
+Creating a transient pool has relatively high cost, particularly in a CoCo VM
+where the memory must be decrypted, so it is done only as a stopgap until the
+background task can add another non-transient pool.
+
+Adding a dynamic pool has limitations. Like with the default pool, the memory
+must be physically contiguous, so the size is limited to MAX_PAGE_ORDER pages
+(e.g., 4 MiB on a typical x86 system). Due to memory fragmentation, a max size
+allocation may not be available. The dynamic pool allocator tries smaller sizes
+until it succeeds, but with a minimum size of 1 MiB. Given sufficient system
+memory fragmentation, dynamically adding a pool might not succeed at all.
+
+The number of areas in a dynamic pool may be different from the number of areas
+in the default pool. Because the new pool size is typically a few MiB at most,
+the number of areas will likely be smaller. For example, with a new pool size
+of 4 MiB and the 256 KiB minimum area size, only 16 areas can be created. If
+the system has more than 16 CPUs, multiple CPUs must share an area, creating
+more lock contention.
+
+New pools added via dynamic swiotlb are linked together in a linear list.
+swiotlb code frequently must search for the pool containing a particular
+swiotlb physical address, so that search is linear and not performant with a
+large number of dynamic pools. The data structures could be improved for
+faster searches.
+
+Overall, dynamic swiotlb works best for small configurations with relatively
+few CPUs. It allows the default swiotlb pool to be smaller so that memory is
+not wasted, with dynamic pools making more space available if needed (as long
+as fragmentation isn't an obstacle). It is less useful for large CoCo VMs.
+
+Data Structure Details
+----------------------
+swiotlb is managed with four primary data structures: io_tlb_mem, io_tlb_pool,
+io_tlb_area, and io_tlb_slot. io_tlb_mem describes a swiotlb memory allocator,
+which includes the default memory pool and any dynamic or transient pools
+linked to it. Limited statistics on swiotlb usage are kept per memory allocator
+and are stored in this data structure. These statistics are available under
+/sys/kernel/debug/swiotlb when CONFIG_DEBUG_FS is set.
+
+io_tlb_pool describes a memory pool, either the default pool, a dynamic pool,
+or a transient pool. The description includes the start and end addresses of
+the memory in the pool, a pointer to an array of io_tlb_area structures, and a
+pointer to an array of io_tlb_slot structures that are associated with the pool.
+
+io_tlb_area describes an area. The primary field is the spin lock used to
+serialize access to slots in the area. The io_tlb_area array for a pool has an
+entry for each area, and is accessed using a 0-based area index derived from the
+calling processor ID. Areas exist solely to allow parallel access to swiotlb
+from multiple CPUs.
+
+io_tlb_slot describes an individual memory slot in the pool, with size
+IO_TLB_SIZE (2 KiB currently). The io_tlb_slot array is indexed by the slot
+index computed from the bounce buffer address relative to the starting memory
+address of the pool. The size of struct io_tlb_slot is 24 bytes, so the
+overhead is about 1% of the slot size.
+
+The io_tlb_slot array is designed to meet several requirements. First, the DMA
+APIs and the corresponding swiotlb APIs use the bounce buffer address as the
+identifier for a bounce buffer. This address is returned by
+swiotlb_tbl_map_single(), and then passed as an argument to
+swiotlb_tbl_unmap_single() and the swiotlb_sync_*() functions. The original
+memory buffer address obviously must be passed as an argument to
+swiotlb_tbl_map_single(), but it is not passed to the other APIs. Consequently,
+swiotlb data structures must save the original memory buffer address so that it
+can be used when doing sync operations. This original address is saved in the
+io_tlb_slot array.
+
+Second, the io_tlb_slot array must handle partial sync requests. In such cases,
+the argument to swiotlb_sync_*() is not the address of the start of the bounce
+buffer but an address somewhere in the middle of the bounce buffer, and the
+address of the start of the bounce buffer isn't known to swiotlb code. But
+swiotlb code must be able to calculate the corresponding original memory buffer
+address to do the CPU copy dictated by the "sync". So an adjusted original
+memory buffer address is populated into the struct io_tlb_slot for each slot
+occupied by the bounce buffer. An adjusted "alloc_size" of the bounce buffer is
+also recorded in each struct io_tlb_slot so a sanity check can be performed on
+the size of the "sync" operation. The "alloc_size" field is not used except for
+the sanity check.
+
+Third, the io_tlb_slot array is used to track available slots. The "list" field
+in struct io_tlb_slot records how many contiguous available slots exist starting
+at that slot. A "0" indicates that the slot is occupied. A value of "1"
+indicates only the current slot is available. A value of "2" indicates the
+current slot and the next slot are available, etc. The maximum value is
+IO_TLB_SEGSIZE, which can appear in the first slot in a slot set, and indicates
+that the entire slot set is available. These values are used when searching for
+available slots to use for a new bounce buffer. They are updated when allocating
+a new bounce buffer and when freeing a bounce buffer. At pool creation time, the
+"list" field is initialized to IO_TLB_SEGSIZE down to 1 for the slots in every
+slot set.
+
+Fourth, the io_tlb_slot array keeps track of any "padding slots" allocated to
+meet alloc_align_mask requirements described above. When
+swiotlb_tbl_map_single() allocates bounce buffer space to meet alloc_align_mask
+requirements, it may allocate pre-padding space across zero or more slots. But
+when swiotlb_tbl_unmap_single() is called with the bounce buffer address, the
+alloc_align_mask value that governed the allocation, and therefore the
+allocation of any padding slots, is not known. The "pad_slots" field records
+the number of padding slots so that swiotlb_tbl_unmap_single() can free them.
+The "pad_slots" value is recorded only in the first non-padding slot allocated
+to the bounce buffer.
+
+Restricted pools
+----------------
+The swiotlb machinery is also used for "restricted pools", which are pools of
+memory separate from the default swiotlb pool, and that are dedicated for DMA
+use by a particular device. Restricted pools provide a level of DMA memory
+protection on systems with limited hardware protection capabilities, such as
+those lacking an IOMMU. Such usage is specified by DeviceTree entries and
+requires that CONFIG_DMA_RESTRICTED_POOL is set. Each restricted pool is based
+on its own io_tlb_mem data structure that is independent of the main swiotlb
+io_tlb_mem.
+
+Restricted pools add swiotlb_alloc() and swiotlb_free() APIs, which are called
+from the dma_alloc_*() and dma_free_*() APIs. The swiotlb_alloc/free() APIs
+allocate/free slots from/to the restricted pool directly and do not go through
+swiotlb_tbl_map/unmap_single().
diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
index 12e4aecdae94..034898e81ba2 100644
--- a/Documentation/core-api/symbol-namespaces.rst
+++ b/Documentation/core-api/symbol-namespaces.rst
@@ -6,18 +6,8 @@ The following document describes how to use Symbol Namespaces to structure the
export surface of in-kernel symbols exported through the family of
EXPORT_SYMBOL() macros.
-.. Table of Contents
-
- === 1 Introduction
- === 2 How to define Symbol Namespaces
- --- 2.1 Using the EXPORT_SYMBOL macros
- --- 2.2 Using the DEFAULT_SYMBOL_NAMESPACE define
- === 3 How to use Symbols exported in Namespaces
- === 4 Loading Modules that use namespaced Symbols
- === 5 Automatically creating MODULE_IMPORT_NS statements
-
-1. Introduction
-===============
+Introduction
+============
Symbol Namespaces have been introduced as a means to structure the export
surface of the in-kernel API. It allows subsystem maintainers to partition
@@ -28,25 +18,28 @@ kernel. As of today, modules that make use of symbols exported into namespaces,
are required to import the namespace. Otherwise the kernel will, depending on
its configuration, reject loading the module or warn about a missing import.
-2. How to define Symbol Namespaces
-==================================
+Additionally, it is possible to put symbols into a module namespace, strictly
+limiting which modules are allowed to use these symbols.
+
+How to define Symbol Namespaces
+===============================
Symbols can be exported into namespace using different methods. All of them are
changing the way EXPORT_SYMBOL and friends are instrumented to create ksymtab
entries.
-2.1 Using the EXPORT_SYMBOL macros
-==================================
+Using the EXPORT_SYMBOL macros
+------------------------------
In addition to the macros EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), that allow
exporting of kernel symbols to the kernel symbol table, variants of these are
available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and
-EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace.
-Please note that due to macro expansion that argument needs to be a
-preprocessor symbol. E.g. to export the symbol ``usb_stor_suspend`` into the
+EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace as a
+string constant. Note that this string must not contain whitespaces.
+E.g. to export the symbol ``usb_stor_suspend`` into the
namespace ``USB_STORAGE``, use::
- EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE);
+ EXPORT_SYMBOL_NS(usb_stor_suspend, "USB_STORAGE");
The corresponding ksymtab entry struct ``kernel_symbol`` will have the member
``namespace`` set accordingly. A symbol that is exported without a namespace will
@@ -54,8 +47,8 @@ refer to ``NULL``. There is no default namespace if none is defined. ``modpost``
and kernel/module/main.c make use the namespace at build time or module load
time, respectively.
-2.2 Using the DEFAULT_SYMBOL_NAMESPACE define
-=============================================
+Using the DEFAULT_SYMBOL_NAMESPACE define
+-----------------------------------------
Defining namespaces for all symbols of a subsystem can be very verbose and may
become hard to maintain. Therefore a default define (DEFAULT_SYMBOL_NAMESPACE)
@@ -68,7 +61,7 @@ is to define the default namespace in the ``Makefile`` of the subsystem. E.g. to
export all symbols defined in usb-common into the namespace USB_COMMON, add a
line like this to drivers/usb/common/Makefile::
- ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON
+ ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE='"USB_COMMON"'
That will affect all EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() statements. A
symbol exported with EXPORT_SYMBOL_NS() while this definition is present, will
@@ -78,14 +71,30 @@ as this argument has preference over a default symbol namespace.
A second option to define the default namespace is directly in the compilation
unit as preprocessor statement. The above example would then read::
- #undef DEFAULT_SYMBOL_NAMESPACE
- #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON
+ #define DEFAULT_SYMBOL_NAMESPACE "USB_COMMON"
+
+within the corresponding compilation unit before the #include for
+<linux/export.h>. Typically it's placed before the first #include statement.
+
+Using the EXPORT_SYMBOL_FOR_MODULES() macro
+-------------------------------------------
-within the corresponding compilation unit before any EXPORT_SYMBOL macro is
-used.
+Symbols exported using this macro are put into a module namespace. This
+namespace cannot be imported. These exports are GPL-only as they are only
+intended for in-tree modules.
-3. How to use Symbols exported in Namespaces
-============================================
+The macro takes a comma separated list of module names, allowing only those
+modules to access this symbol. Simple tail-globs are supported.
+
+For example::
+
+ EXPORT_SYMBOL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")
+
+will limit usage of this symbol to modules whose name matches the given
+patterns.
+
+How to use Symbols exported in Namespaces
+=========================================
In order to use symbols that are exported into namespaces, kernel modules need
to explicitly import these namespaces. Otherwise the kernel might reject to
@@ -94,7 +103,7 @@ for the namespaces it uses symbols from. E.g. a module using the
usb_stor_suspend symbol from above, needs to import the namespace USB_STORAGE
using a statement like::
- MODULE_IMPORT_NS(USB_STORAGE);
+ MODULE_IMPORT_NS("USB_STORAGE");
This will create a ``modinfo`` tag in the module for each imported namespace.
This has the side effect, that the imported namespaces of a module can be
@@ -107,11 +116,10 @@ inspected with modinfo::
It is advisable to add the MODULE_IMPORT_NS() statement close to other module
-metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). Refer to section
-5. for a way to create missing import statements automatically.
+metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE().
-4. Loading Modules that use namespaced Symbols
-==============================================
+Loading Modules that use namespaced Symbols
+===========================================
At module loading time (e.g. ``insmod``), the kernel will check each symbol
referenced from the module for its availability and whether the namespace it
@@ -122,8 +130,8 @@ allow loading of modules that don't satisfy this precondition, a configuration
option is available: Setting MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y will
enable loading regardless, but will emit a warning.
-5. Automatically creating MODULE_IMPORT_NS statements
-=====================================================
+Automatically creating MODULE_IMPORT_NS statements
+==================================================
Missing namespaces imports can easily be detected at build time. In fact,
modpost will emit a warning if a module uses a symbol from a namespace
@@ -155,3 +163,6 @@ in-tree modules::
You can also run nsdeps for external module builds. A typical usage is::
$ make -C <path_to_kernel_src> M=$PWD nsdeps
+
+Note: it will happily generate an import statement for the module namespace;
+which will not work and generates build and runtime failures.
diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst
index 5cb8b883ae83..533ac5dd5750 100644
--- a/Documentation/core-api/this_cpu_ops.rst
+++ b/Documentation/core-api/this_cpu_ops.rst
@@ -53,7 +53,6 @@ preemption and interrupts::
this_cpu_add_return(pcp, val)
this_cpu_xchg(pcp, nval)
this_cpu_cmpxchg(pcp, oval, nval)
- this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2)
this_cpu_sub(pcp, val)
this_cpu_inc(pcp)
this_cpu_dec(pcp)
@@ -139,12 +138,22 @@ get_cpu/put_cpu sequence requires. No processor number is
available. Instead, the offset of the local per cpu area is simply
added to the per cpu offset.
-Note that this operation is usually used in a code segment when
-preemption has been disabled. The pointer is then used to
-access local per cpu data in a critical section. When preemption
-is re-enabled this pointer is usually no longer useful since it may
-no longer point to per cpu data of the current processor.
-
+Note that this operation can only be used in code segments where
+smp_processor_id() may be used, for example, where preemption has been
+disabled. The pointer is then used to access local per cpu data in a
+critical section. When preemption is re-enabled this pointer is usually
+no longer useful since it may no longer point to per cpu data of the
+current processor.
+
+The special cases where it makes sense to obtain a per-CPU pointer in
+preemptible code are addressed by raw_cpu_ptr(), but such use cases need
+to handle cases where two different CPUs are accessing the same per cpu
+variable, which might well be that of a third CPU. These use cases are
+typically performance optimizations. For example, SRCU implements a pair
+of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe()
+uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses
+atomic_inc_long() to handle migration between the raw_cpu_ptr() and
+the atomic_inc_long().
Per cpu variables and offsets
-----------------------------
@@ -242,7 +251,6 @@ safe::
__this_cpu_add_return(pcp, val)
__this_cpu_xchg(pcp, nval)
__this_cpu_cmpxchg(pcp, oval, nval)
- __this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2)
__this_cpu_sub(pcp, val)
__this_cpu_inc(pcp)
__this_cpu_dec(pcp)
diff --git a/Documentation/core-api/unaligned-memory-access.rst b/Documentation/core-api/unaligned-memory-access.rst
index 1ee82419d8aa..5ceeb80eb539 100644
--- a/Documentation/core-api/unaligned-memory-access.rst
+++ b/Documentation/core-api/unaligned-memory-access.rst
@@ -203,7 +203,7 @@ Avoiding unaligned accesses
===========================
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
access::
diff --git a/Documentation/core-api/union_find.rst b/Documentation/core-api/union_find.rst
new file mode 100644
index 000000000000..6df8b94fdb5a
--- /dev/null
+++ b/Documentation/core-api/union_find.rst
@@ -0,0 +1,106 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Union-Find in Linux
+====================
+
+
+:Date: June 21, 2024
+:Author: Xavier <xavier_qy@163.com>
+
+What is union-find, and what is it used for?
+------------------------------------------------
+
+Union-find is a data structure used to handle the merging and querying
+of disjoint sets. The primary operations supported by union-find are:
+
+ Initialization: Resetting each element as an individual set, with
+ each set's initial parent node pointing to itself.
+
+ Find: Determine which set a particular element belongs to, usually by
+ returning a “representative element” of that set. This operation
+ is used to check if two elements are in the same set.
+
+ Union: Merge two sets into one.
+
+As a data structure used to maintain sets (groups), union-find is commonly
+utilized to solve problems related to offline queries, dynamic connectivity,
+and graph theory. It is also a key component in Kruskal's algorithm for
+computing the minimum spanning tree, which is crucial in scenarios like
+network routing. Consequently, union-find is widely referenced. Additionally,
+union-find has applications in symbolic computation, register allocation,
+and more.
+
+Space Complexity: O(n), where n is the number of nodes.
+
+Time Complexity: Using path compression can reduce the time complexity of
+the find operation, and using union by rank can reduce the time complexity
+of the union operation. These optimizations reduce the average time
+complexity of each find and union operation to O(α(n)), where α(n) is the
+inverse Ackermann function. This can be roughly considered a constant time
+complexity for practical purposes.
+
+This document covers use of the Linux union-find implementation. For more
+information on the nature and implementation of union-find, see:
+
+ Wikipedia entry on union-find
+ https://en.wikipedia.org/wiki/Disjoint-set_data_structure
+
+Linux implementation of union-find
+-----------------------------------
+
+Linux's union-find implementation resides in the file "lib/union_find.c".
+To use it, "#include <linux/union_find.h>".
+
+The union-find data structure is defined as follows::
+
+ struct uf_node {
+ struct uf_node *parent;
+ unsigned int rank;
+ };
+
+In this structure, parent points to the parent node of the current node.
+The rank field represents the height of the current tree. During a union
+operation, the tree with the smaller rank is attached under the tree with the
+larger rank to maintain balance.
+
+Initializing union-find
+-----------------------
+
+You can complete the initialization using either static or initialization
+interface. Initialize the parent pointer to point to itself and set the rank
+to 0.
+Example::
+
+ struct uf_node my_node = UF_INIT_NODE(my_node);
+
+or
+
+ uf_node_init(&my_node);
+
+Find the Root Node of union-find
+--------------------------------
+
+This operation is mainly used to determine whether two nodes belong to the same
+set in the union-find. If they have the same root, they are in the same set.
+During the find operation, path compression is performed to improve the
+efficiency of subsequent find operations.
+Example::
+
+ int connected;
+ struct uf_node *root1 = uf_find(&node_1);
+ struct uf_node *root2 = uf_find(&node_2);
+ if (root1 == root2)
+ connected = 1;
+ else
+ connected = 0;
+
+Union Two Sets in union-find
+----------------------------
+
+To union two sets in the union-find, you first find their respective root nodes
+and then link the smaller node to the larger node based on the rank of the root
+nodes.
+Example::
+
+ uf_union(&node_1, &node_2);
diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst
index 3b22ed137662..165ca73e8351 100644
--- a/Documentation/core-api/workqueue.rst
+++ b/Documentation/core-api/workqueue.rst
@@ -1,6 +1,6 @@
-====================================
-Concurrency Managed Workqueue (cmwq)
-====================================
+=========
+Workqueue
+=========
:Date: September, 2010
:Author: Tejun Heo <tj@kernel.org>
@@ -25,8 +25,8 @@ there is no work item left on the workqueue the worker becomes idle.
When a new work item gets queued, the worker begins executing again.
-Why cmwq?
-=========
+Why Concurrency Managed Workqueue?
+==================================
In the original wq implementation, a multi threaded (MT) wq had one
worker thread per CPU and a single threaded (ST) wq had one worker
@@ -77,10 +77,12 @@ wants a function to be executed asynchronously it has to set up a work
item pointing to that function and queue that work item on a
workqueue.
-Special purpose threads, called worker threads, execute the functions
-off of the queue, one after the other. If no work is queued, the
-worker threads become idle. These worker threads are managed in so
-called worker-pools.
+A work item can be executed in either a thread or the BH (softirq) context.
+
+For threaded workqueues, special purpose threads, called [k]workers, execute
+the functions off of the queue, one after the other. If no work is queued,
+the worker threads become idle. These worker threads are managed in
+worker-pools.
The cmwq design differentiates between the user-facing workqueues that
subsystems and drivers queue work items on and the backend mechanism
@@ -91,6 +93,12 @@ for high priority ones, for each possible CPU and some extra
worker-pools to serve work items queued on unbound workqueues - the
number of these backing pools is dynamic.
+BH workqueues use the same framework. However, as there can only be one
+concurrent execution context, there's no need to worry about concurrency.
+Each per-CPU BH worker pool contains only one pseudo worker which represents
+the BH execution context. A BH workqueue can be considered a convenience
+interface to softirq.
+
Subsystems and drivers can create and queue work items through special
workqueue API functions as they see fit. They can influence some
aspects of the way the work items are executed by setting flags on the
@@ -106,7 +114,7 @@ unless specifically overridden, a work item of a bound workqueue will
be queued on the worklist of either normal or highpri worker-pool that
is associated to the CPU the issuer is running on.
-For any worker pool implementation, managing the concurrency level
+For any thread pool implementation, managing the concurrency level
(how many execution contexts are active) is an important issue. cmwq
tries to keep the concurrency at a minimal but sufficient level.
Minimal to save resources and sufficient in that the system is used at
@@ -164,6 +172,23 @@ resources, scheduled and executed.
``flags``
---------
+``WQ_BH``
+ BH workqueues can be considered a convenience interface to softirq. BH
+ workqueues are always per-CPU and all BH work items are executed in the
+ queueing CPU's softirq context in the queueing order.
+
+ All BH workqueues must have 0 ``max_active`` and ``WQ_HIGHPRI`` is the
+ only allowed additional flag.
+
+ BH work items cannot sleep. All other features such as delayed queueing,
+ flushing and canceling are supported.
+
+``WQ_PERCPU``
+ Work items queued to a per-cpu wq are bound to a specific CPU.
+ This flag is the right choice when cpu locality is important.
+
+ This flag is the complement of ``WQ_UNBOUND``.
+
``WQ_UNBOUND``
Work items queued to an unbound wq are served by the special
worker-pools which host workers which are not bound to any
@@ -220,17 +245,16 @@ resources, scheduled and executed.
``max_active``
--------------
-``@max_active`` determines the maximum number of execution contexts
-per CPU which can be assigned to the work items of a wq. For example,
-with ``@max_active`` of 16, at most 16 work items of the wq can be
-executing at the same time per CPU.
+``@max_active`` determines the maximum number of execution contexts per
+CPU which can be assigned to the work items of a wq. For example, with
+``@max_active`` of 16, at most 16 work items of the wq can be executing
+at the same time per CPU. This is always a per-CPU attribute, even for
+unbound workqueues.
-Currently, for a bound wq, the maximum limit for ``@max_active`` is
-512 and the default value used when 0 is specified is 256. For an
-unbound wq, the limit is higher of 512 and 4 *
-``num_possible_cpus()``. These values are chosen sufficiently high
-such that they are not the limiting factor while providing protection
-in runaway cases.
+The maximum limit for ``@max_active`` is 2048 and the default value used
+when 0 is specified is 1024. These values are chosen sufficiently high
+such that they are not the limiting factor while providing protection in
+runaway cases.
The number of active work items of a wq is usually regulated by the
users of the wq, more specifically, by how many work items the users
@@ -238,15 +262,11 @@ may queue at the same time. Unless there is a specific need for
throttling the number of active work items, specifying '0' is
recommended.
-Some users depend on the strict execution ordering of ST wq. The
-combination of ``@max_active`` of 1 and ``WQ_UNBOUND`` used to
-achieve this behavior. Work items on such wq were always queued to the
-unbound worker-pools and only one work item could be active at any given
-time thus achieving the same ordering property as ST wq.
-
-In the current implementation the above configuration only guarantees
-ST behavior within a given NUMA node. Instead ``alloc_ordered_queue()`` should
-be used to achieve system-wide ST behavior.
+Some users depend on strict execution ordering where only one work item
+is in flight at any given time and the work items are processed in
+queueing order. While the combination of ``@max_active`` of 1 and
+``WQ_UNBOUND`` used to achieve this behavior, this is no longer the
+case. Use alloc_ordered_workqueue() instead.
Example Execution Scenarios
@@ -343,11 +363,366 @@ Guidelines
difference in execution characteristics between using a dedicated wq
and a system wq.
+ Note: If something may generate more than @max_active outstanding
+ work items (do stress test your producers), it may saturate a system
+ wq and potentially lead to deadlock. It should utilize its own
+ dedicated workqueue rather than the system wq.
+
* Unless work items are expected to consume a huge amount of CPU
cycles, using a bound wq is usually beneficial due to the increased
level of locality in wq operations and work item execution.
+Affinity Scopes
+===============
+
+An unbound workqueue groups CPUs according to its affinity scope to improve
+cache locality. For example, if a workqueue is using the default affinity
+scope of "cache", it will group CPUs according to last level cache
+boundaries. A work item queued on the workqueue will be assigned to a worker
+on one of the CPUs which share the last level cache with the issuing CPU.
+Once started, the worker may or may not be allowed to move outside the scope
+depending on the ``affinity_strict`` setting of the scope.
+
+Workqueue currently supports the following affinity scopes.
+
+``default``
+ Use the scope in module parameter ``workqueue.default_affinity_scope``
+ which is always set to one of the scopes below.
+
+``cpu``
+ CPUs are not grouped. A work item issued on one CPU is processed by a
+ worker on the same CPU. This makes unbound workqueues behave as per-cpu
+ workqueues without concurrency management.
+
+``smt``
+ CPUs are grouped according to SMT boundaries. This usually means that the
+ logical threads of each physical CPU core are grouped together.
+
+``cache``
+ CPUs are grouped according to cache boundaries. Which specific cache
+ boundary is used is determined by the arch code. L3 is used in a lot of
+ cases. This is the default affinity scope.
+
+``numa``
+ CPUs are grouped according to NUMA boundaries.
+
+``system``
+ All CPUs are put in the same group. Workqueue makes no effort to process a
+ work item on a CPU close to the issuing CPU.
+
+The default affinity scope can be changed with the module parameter
+``workqueue.default_affinity_scope`` and a specific workqueue's affinity
+scope can be changed using ``apply_workqueue_attrs()``.
+
+If ``WQ_SYSFS`` is set, the workqueue will have the following affinity scope
+related interface files under its ``/sys/devices/virtual/workqueue/WQ_NAME/``
+directory.
+
+``affinity_scope``
+ Read to see the current affinity scope. Write to change.
+
+ When default is the current scope, reading this file will also show the
+ current effective scope in parentheses, for example, ``default (cache)``.
+
+``affinity_strict``
+ 0 by default indicating that affinity scopes are not strict. When a work
+ item starts execution, workqueue makes a best-effort attempt to ensure
+ that the worker is inside its affinity scope, which is called
+ repatriation. Once started, the scheduler is free to move the worker
+ anywhere in the system as it sees fit. This enables benefiting from scope
+ locality while still being able to utilize other CPUs if necessary and
+ available.
+
+ If set to 1, all workers of the scope are guaranteed always to be in the
+ scope. This may be useful when crossing affinity scopes has other
+ implications, for example, in terms of power consumption or workload
+ isolation. Strict NUMA scope can also be used to match the workqueue
+ behavior of older kernels.
+
+
+Affinity Scopes and Performance
+===============================
+
+It'd be ideal if an unbound workqueue's behavior is optimal for vast
+majority of use cases without further tuning. Unfortunately, in the current
+kernel, there exists a pronounced trade-off between locality and utilization
+necessitating explicit configurations when workqueues are heavily used.
+
+Higher locality leads to higher efficiency where more work is performed for
+the same number of consumed CPU cycles. However, higher locality may also
+cause lower overall system utilization if the work items are not spread
+enough across the affinity scopes by the issuers. The following performance
+testing with dm-crypt clearly illustrates this trade-off.
+
+The tests are run on a CPU with 12-cores/24-threads split across four L3
+caches (AMD Ryzen 9 3900x). CPU clock boost is turned off for consistency.
+``/dev/dm-0`` is a dm-crypt device created on NVME SSD (Samsung 990 PRO) and
+opened with ``cryptsetup`` with default settings.
+
+
+Scenario 1: Enough issuers and work spread across the machine
+-------------------------------------------------------------
+
+The command used: ::
+
+ $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k --ioengine=libaio \
+ --iodepth=64 --runtime=60 --numjobs=24 --time_based --group_reporting \
+ --name=iops-test-job --verify=sha512
+
+There are 24 issuers, each issuing 64 IOs concurrently. ``--verify=sha512``
+makes ``fio`` generate and read back the content each time which makes
+execution locality matter between the issuer and ``kcryptd``. The following
+are the read bandwidths and CPU utilizations depending on different affinity
+scope settings on ``kcryptd`` measured over five runs. Bandwidths are in
+MiBps, and CPU util in percents.
+
+.. list-table::
+ :widths: 16 20 20
+ :header-rows: 1
+
+ * - Affinity
+ - Bandwidth (MiBps)
+ - CPU util (%)
+
+ * - system
+ - 1159.40 ±1.34
+ - 99.31 ±0.02
+
+ * - cache
+ - 1166.40 ±0.89
+ - 99.34 ±0.01
+
+ * - cache (strict)
+ - 1166.00 ±0.71
+ - 99.35 ±0.01
+
+With enough issuers spread across the system, there is no downside to
+"cache", strict or otherwise. All three configurations saturate the whole
+machine but the cache-affine ones outperform by 0.6% thanks to improved
+locality.
+
+
+Scenario 2: Fewer issuers, enough work for saturation
+-----------------------------------------------------
+
+The command used: ::
+
+ $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
+ --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=8 \
+ --time_based --group_reporting --name=iops-test-job --verify=sha512
+
+The only difference from the previous scenario is ``--numjobs=8``. There are
+a third of the issuers but is still enough total work to saturate the
+system.
+
+.. list-table::
+ :widths: 16 20 20
+ :header-rows: 1
+
+ * - Affinity
+ - Bandwidth (MiBps)
+ - CPU util (%)
+
+ * - system
+ - 1155.40 ±0.89
+ - 97.41 ±0.05
+
+ * - cache
+ - 1154.40 ±1.14
+ - 96.15 ±0.09
+
+ * - cache (strict)
+ - 1112.00 ±4.64
+ - 93.26 ±0.35
+
+This is more than enough work to saturate the system. Both "system" and
+"cache" are nearly saturating the machine but not fully. "cache" is using
+less CPU but the better efficiency puts it at the same bandwidth as
+"system".
+
+Eight issuers moving around over four L3 cache scope still allow "cache
+(strict)" to mostly saturate the machine but the loss of work conservation
+is now starting to hurt with 3.7% bandwidth loss.
+
+
+Scenario 3: Even fewer issuers, not enough work to saturate
+-----------------------------------------------------------
+
+The command used: ::
+
+ $ fio --filename=/dev/dm-0 --direct=1 --rw=randrw --bs=32k \
+ --ioengine=libaio --iodepth=64 --runtime=60 --numjobs=4 \
+ --time_based --group_reporting --name=iops-test-job --verify=sha512
+
+Again, the only difference is ``--numjobs=4``. With the number of issuers
+reduced to four, there now isn't enough work to saturate the whole system
+and the bandwidth becomes dependent on completion latencies.
+
+.. list-table::
+ :widths: 16 20 20
+ :header-rows: 1
+
+ * - Affinity
+ - Bandwidth (MiBps)
+ - CPU util (%)
+
+ * - system
+ - 993.60 ±1.82
+ - 75.49 ±0.06
+
+ * - cache
+ - 973.40 ±1.52
+ - 74.90 ±0.07
+
+ * - cache (strict)
+ - 828.20 ±4.49
+ - 66.84 ±0.29
+
+Now, the tradeoff between locality and utilization is clearer. "cache" shows
+2% bandwidth loss compared to "system" and "cache (struct)" whopping 20%.
+
+
+Conclusion and Recommendations
+------------------------------
+
+In the above experiments, the efficiency advantage of the "cache" affinity
+scope over "system" is, while consistent and noticeable, small. However, the
+impact is dependent on the distances between the scopes and may be more
+pronounced in processors with more complex topologies.
+
+While the loss of work-conservation in certain scenarios hurts, it is a lot
+better than "cache (strict)" and maximizing workqueue utilization is
+unlikely to be the common case anyway. As such, "cache" is the default
+affinity scope for unbound pools.
+
+* As there is no one option which is great for most cases, workqueue usages
+ that may consume a significant amount of CPU are recommended to configure
+ the workqueues using ``apply_workqueue_attrs()`` and/or enable
+ ``WQ_SYSFS``.
+
+* An unbound workqueue with strict "cpu" affinity scope behaves the same as
+ ``WQ_CPU_INTENSIVE`` per-cpu workqueue. There is no real advanage to the
+ latter and an unbound workqueue provides a lot more flexibility.
+
+* Affinity scopes are introduced in Linux v6.5. To emulate the previous
+ behavior, use strict "numa" affinity scope.
+
+* The loss of work-conservation in non-strict affinity scopes is likely
+ originating from the scheduler. There is no theoretical reason why the
+ kernel wouldn't be able to do the right thing and maintain
+ work-conservation in most cases. As such, it is possible that future
+ scheduler improvements may make most of these tunables unnecessary.
+
+
+Examining Configuration
+=======================
+
+Use tools/workqueue/wq_dump.py to examine unbound CPU affinity
+configuration, worker pools and how workqueues map to the pools: ::
+
+ $ tools/workqueue/wq_dump.py
+ Affinity Scopes
+ ===============
+ wq_unbound_cpumask=0000000f
+
+ CPU
+ nr_pods 4
+ pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
+ pod_node [0]=0 [1]=0 [2]=1 [3]=1
+ cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
+
+ SMT
+ nr_pods 4
+ pod_cpus [0]=00000001 [1]=00000002 [2]=00000004 [3]=00000008
+ pod_node [0]=0 [1]=0 [2]=1 [3]=1
+ cpu_pod [0]=0 [1]=1 [2]=2 [3]=3
+
+ CACHE (default)
+ nr_pods 2
+ pod_cpus [0]=00000003 [1]=0000000c
+ pod_node [0]=0 [1]=1
+ cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
+
+ NUMA
+ nr_pods 2
+ pod_cpus [0]=00000003 [1]=0000000c
+ pod_node [0]=0 [1]=1
+ cpu_pod [0]=0 [1]=0 [2]=1 [3]=1
+
+ SYSTEM
+ nr_pods 1
+ pod_cpus [0]=0000000f
+ pod_node [0]=-1
+ cpu_pod [0]=0 [1]=0 [2]=0 [3]=0
+
+ Worker Pools
+ ============
+ pool[00] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 0
+ pool[01] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 0
+ pool[02] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 1
+ pool[03] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 1
+ pool[04] ref= 1 nice= 0 idle/workers= 4/ 4 cpu= 2
+ pool[05] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 2
+ pool[06] ref= 1 nice= 0 idle/workers= 3/ 3 cpu= 3
+ pool[07] ref= 1 nice=-20 idle/workers= 2/ 2 cpu= 3
+ pool[08] ref=42 nice= 0 idle/workers= 6/ 6 cpus=0000000f
+ pool[09] ref=28 nice= 0 idle/workers= 3/ 3 cpus=00000003
+ pool[10] ref=28 nice= 0 idle/workers= 17/ 17 cpus=0000000c
+ pool[11] ref= 1 nice=-20 idle/workers= 1/ 1 cpus=0000000f
+ pool[12] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=00000003
+ pool[13] ref= 2 nice=-20 idle/workers= 1/ 1 cpus=0000000c
+
+ Workqueue CPU -> pool
+ =====================
+ [ workqueue \ CPU 0 1 2 3 dfl]
+ events percpu 0 2 4 6
+ events_highpri percpu 1 3 5 7
+ events_long percpu 0 2 4 6
+ events_unbound unbound 9 9 10 10 8
+ events_freezable percpu 0 2 4 6
+ events_power_efficient percpu 0 2 4 6
+ events_freezable_pwr_ef percpu 0 2 4 6
+ rcu_gp percpu 0 2 4 6
+ rcu_par_gp percpu 0 2 4 6
+ slub_flushwq percpu 0 2 4 6
+ netns ordered 8 8 8 8 8
+ ...
+
+See the command's help message for more info.
+
+
+Monitoring
+==========
+
+Use tools/workqueue/wq_monitor.py to monitor workqueue operations: ::
+
+ $ tools/workqueue/wq_monitor.py events
+ total infl CPUtime CPUhog CMW/RPR mayday rescued
+ events 18545 0 6.1 0 5 - -
+ events_highpri 8 0 0.0 0 0 - -
+ events_long 3 0 0.0 0 0 - -
+ events_unbound 38306 0 0.1 - 7 - -
+ events_freezable 0 0 0.0 0 0 - -
+ events_power_efficient 29598 0 0.2 0 0 - -
+ events_freezable_pwr_ef 10 0 0.0 0 0 - -
+ sock_diag_events 0 0 0.0 0 0 - -
+
+ total infl CPUtime CPUhog CMW/RPR mayday rescued
+ events 18548 0 6.1 0 5 - -
+ events_highpri 8 0 0.0 0 0 - -
+ events_long 3 0 0.0 0 0 - -
+ events_unbound 38322 0 0.1 - 7 - -
+ events_freezable 0 0 0.0 0 0 - -
+ events_power_efficient 29603 0 0.2 0 0 - -
+ events_freezable_pwr_ef 10 0 0.0 0 0 - -
+ sock_diag_events 0 0 0.0 0 0 - -
+
+ ...
+
+See the command's help message for more info.
+
+
Debugging
=========
@@ -370,8 +745,8 @@ of possible problems:
The first one can be tracked using tracing: ::
- $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
- $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
+ $ echo workqueue:workqueue_queue_work > /sys/kernel/tracing/set_event
+ $ cat /sys/kernel/tracing/trace_pipe > out.txt
(wait a few secs)
^C
@@ -387,6 +762,7 @@ the stack trace of the offending worker thread. ::
The work item's function should be trivially visible in the stack
trace.
+
Non-reentrance Conditions
=========================
diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst
index 77e0ece2b1d6..c6c91cbd0c3c 100644
--- a/Documentation/core-api/xarray.rst
+++ b/Documentation/core-api/xarray.rst
@@ -42,8 +42,8 @@ call xa_tag_pointer() to create an entry with a tag, xa_untag_pointer()
to turn a tagged entry back into an untagged pointer and xa_pointer_tag()
to retrieve the tag of an entry. Tagged pointers use the same bits that
are used to distinguish value entries from normal pointers, so you must
-decide whether they want to store value entries or tagged pointers in
-any particular XArray.
+decide whether you want to store value entries or tagged pointers in any
+particular XArray.
The XArray does not support storing IS_ERR() pointers as some
conflict with value entries or internal entries.
@@ -52,8 +52,9 @@ An unusual feature of the XArray is the ability to create entries which
occupy a range of indices. Once stored to, looking up any index in
the range will return the same entry as looking up any other index in
the range. Storing to any index will store to all of them. Multi-index
-entries can be explicitly split into smaller entries, or storing ``NULL``
-into any entry will cause the XArray to forget about the range.
+entries can be explicitly split into smaller entries. Unsetting (using
+xa_erase() or xa_store() with ``NULL``) any entry will cause the XArray
+to forget about the range.
Normal API
==========
@@ -63,13 +64,14 @@ for statically allocated XArrays or xa_init() for dynamically
allocated ones. A freshly-initialised XArray contains a ``NULL``
pointer at every index.
-You can then set entries using xa_store() and get entries
-using xa_load(). xa_store will overwrite any entry with the
-new entry and return the previous entry stored at that index. You can
-use xa_erase() instead of calling xa_store() with a
-``NULL`` entry. There is no difference between an entry that has never
-been stored to, one that has been erased and one that has most recently
-had ``NULL`` stored to it.
+You can then set entries using xa_store() and get entries using
+xa_load(). xa_store() will overwrite any entry with the new entry and
+return the previous entry stored at that index. You can unset entries
+using xa_erase() or by setting the entry to ``NULL`` using xa_store().
+There is no difference between an entry that has never been stored to
+and one that has been erased with xa_erase(); an entry that has most
+recently had ``NULL`` stored to it is also equivalent except if the
+XArray was initialized with ``XA_FLAGS_ALLOC``.
You can conditionally replace an entry at an index by using
xa_cmpxchg(). Like cmpxchg(), it will only succeed if
@@ -487,7 +489,19 @@ Storing ``NULL`` into any index of a multi-index entry will set the
entry at every index to ``NULL`` and dissolve the tie. A multi-index
entry can be split into entries occupying smaller ranges by calling
xas_split_alloc() without the xa_lock held, followed by taking the lock
-and calling xas_split().
+and calling xas_split() or calling xas_try_split() with xa_lock. The
+difference between xas_split_alloc()+xas_split() and xas_try_alloc() is
+that xas_split_alloc() + xas_split() split the entry from the original
+order to the new order in one shot uniformly, whereas xas_try_split()
+iteratively splits the entry containing the index non-uniformly.
+For example, to split an order-9 entry, which takes 2^(9-6)=8 slots,
+assuming ``XA_CHUNK_SHIFT`` is 6, xas_split_alloc() + xas_split() need
+8 xa_node. xas_try_split() splits the order-9 entry into
+2 order-8 entries, then split one order-8 entry, based on the given index,
+to 2 order-7 entries, ..., and split one order-1 entry to 2 order-0 entries.
+When splitting the order-6 entry and a new xa_node is needed, xas_try_split()
+will try to allocate one if possible. As a result, xas_try_split() would only
+need 1 xa_node instead of 8.
Functions and structures
========================
diff --git a/Documentation/cpu-freq/cpu-drivers.rst b/Documentation/cpu-freq/cpu-drivers.rst
index d84ededb66f9..c5635ac3de54 100644
--- a/Documentation/cpu-freq/cpu-drivers.rst
+++ b/Documentation/cpu-freq/cpu-drivers.rst
@@ -109,8 +109,7 @@ Then, the driver must fill in the following values:
+-----------------------------------+--------------------------------------+
|policy->cpuinfo.transition_latency | the time it takes on this CPU to |
| | switch between two frequencies in |
-| | nanoseconds (if appropriate, else |
-| | specify CPUFREQ_ETERNAL) |
+| | nanoseconds |
+-----------------------------------+--------------------------------------+
|policy->cur | The current operating frequency of |
| | this CPU (if appropriate) |
diff --git a/Documentation/cpu-freq/index.rst b/Documentation/cpu-freq/index.rst
index aba7831ab1cb..de25740651f7 100644
--- a/Documentation/cpu-freq/index.rst
+++ b/Documentation/cpu-freq/index.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-==============================================================================
-Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
-==============================================================================
+========================================================================
+CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
+========================================================================
Author: Dominik Brodowski <linux@brodo.de>
@@ -20,18 +20,15 @@ Author: Dominik Brodowski <linux@brodo.de>
Mailing List
------------
-There is a CPU frequency changing CVS commit and general list where
-you can report bugs, problems or submit patches. To post a message,
-send an email to linux-pm@vger.kernel.org.
+There is a CPU frequency general list where you can report bugs,
+problems or submit patches. To post a message, send an email to
+linux-pm@vger.kernel.org.
Links
-----
the FTP archives:
* ftp://ftp.linux.org.uk/pub/linux/cpufreq/
-how to access the CVS repository:
-* http://cvs.arm.linux.org.uk/
-
the CPUFreq Mailing list:
* http://vger.kernel.org/vger-lists.html#linux-pm
diff --git a/Documentation/crypto/api-aead.rst b/Documentation/crypto/api-aead.rst
index d15256f1ae36..78d073319f96 100644
--- a/Documentation/crypto/api-aead.rst
+++ b/Documentation/crypto/api-aead.rst
@@ -1,3 +1,6 @@
+Authenticated Encryption With Associated Data (AEAD)
+====================================================
+
Authenticated Encryption With Associated Data (AEAD) Algorithm Definitions
--------------------------------------------------------------------------
diff --git a/Documentation/crypto/api-akcipher.rst b/Documentation/crypto/api-akcipher.rst
index 40aa8746e2a1..a31f5aef7667 100644
--- a/Documentation/crypto/api-akcipher.rst
+++ b/Documentation/crypto/api-akcipher.rst
@@ -1,3 +1,6 @@
+Asymmetric Cipher
+=================
+
Asymmetric Cipher Algorithm Definitions
---------------------------------------
@@ -8,10 +11,10 @@ Asymmetric Cipher API
---------------------
.. kernel-doc:: include/crypto/akcipher.h
- :doc: Generic Public Key API
+ :doc: Generic Public Key Cipher API
.. kernel-doc:: include/crypto/akcipher.h
- :functions: crypto_alloc_akcipher crypto_free_akcipher crypto_akcipher_set_pub_key crypto_akcipher_set_priv_key crypto_akcipher_maxsize crypto_akcipher_encrypt crypto_akcipher_decrypt crypto_akcipher_sign crypto_akcipher_verify
+ :functions: crypto_alloc_akcipher crypto_free_akcipher crypto_akcipher_set_pub_key crypto_akcipher_set_priv_key crypto_akcipher_maxsize crypto_akcipher_encrypt crypto_akcipher_decrypt
Asymmetric Cipher Request Handle
--------------------------------
diff --git a/Documentation/crypto/api-digest.rst b/Documentation/crypto/api-digest.rst
index 7a1e670d6ce1..02a2bcc26a64 100644
--- a/Documentation/crypto/api-digest.rst
+++ b/Documentation/crypto/api-digest.rst
@@ -1,3 +1,6 @@
+Message Digest
+==============
+
Message Digest Algorithm Definitions
------------------------------------
diff --git a/Documentation/crypto/api-kpp.rst b/Documentation/crypto/api-kpp.rst
index 7d86ab906bdf..5794e2d10c95 100644
--- a/Documentation/crypto/api-kpp.rst
+++ b/Documentation/crypto/api-kpp.rst
@@ -1,3 +1,6 @@
+Key-agreement Protocol Primitives (KPP)
+=======================================
+
Key-agreement Protocol Primitives (KPP) Cipher Algorithm Definitions
--------------------------------------------------------------------
diff --git a/Documentation/crypto/api-rng.rst b/Documentation/crypto/api-rng.rst
index 10ba7436cee4..23a94c0b272e 100644
--- a/Documentation/crypto/api-rng.rst
+++ b/Documentation/crypto/api-rng.rst
@@ -1,3 +1,6 @@
+Random Number Generator (RNG)
+=============================
+
Random Number Algorithm Definitions
-----------------------------------
diff --git a/Documentation/crypto/api-sig.rst b/Documentation/crypto/api-sig.rst
new file mode 100644
index 000000000000..4d8aba8aee8e
--- /dev/null
+++ b/Documentation/crypto/api-sig.rst
@@ -0,0 +1,18 @@
+Asymmetric Signature
+====================
+
+Asymmetric Signature Algorithm Definitions
+------------------------------------------
+
+.. kernel-doc:: include/crypto/sig.h
+ :functions: sig_alg
+
+Asymmetric Signature API
+------------------------
+
+.. kernel-doc:: include/crypto/sig.h
+ :doc: Generic Public Key Signature API
+
+.. kernel-doc:: include/crypto/sig.h
+ :functions: crypto_alloc_sig crypto_free_sig crypto_sig_set_pubkey crypto_sig_set_privkey crypto_sig_keysize crypto_sig_maxsize crypto_sig_digestsize crypto_sig_sign crypto_sig_verify
+
diff --git a/Documentation/crypto/api-skcipher.rst b/Documentation/crypto/api-skcipher.rst
index 04d6cc5357c8..4b7c8160790a 100644
--- a/Documentation/crypto/api-skcipher.rst
+++ b/Documentation/crypto/api-skcipher.rst
@@ -1,3 +1,6 @@
+Symmetric Key Cipher
+====================
+
Block Cipher Algorithm Definitions
----------------------------------
diff --git a/Documentation/crypto/api.rst b/Documentation/crypto/api.rst
index b91b31736df8..8b2a90521886 100644
--- a/Documentation/crypto/api.rst
+++ b/Documentation/crypto/api.rst
@@ -1,11 +1,8 @@
Programming Interface
=====================
-.. class:: toc-title
-
- Table of contents
-
.. toctree::
+ :caption: Table of contents
:maxdepth: 2
api-skcipher
@@ -13,4 +10,5 @@ Programming Interface
api-digest
api-rng
api-akcipher
+ api-sig
api-kpp
diff --git a/Documentation/crypto/architecture.rst b/Documentation/crypto/architecture.rst
index 646c3380a7ed..249b54d0849f 100644
--- a/Documentation/crypto/architecture.rst
+++ b/Documentation/crypto/architecture.rst
@@ -196,8 +196,6 @@ the aforementioned cipher types:
- CRYPTO_ALG_TYPE_CIPHER Single block cipher
-- CRYPTO_ALG_TYPE_COMPRESS Compression
-
- CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data
(MAC)
@@ -214,6 +212,8 @@ the aforementioned cipher types:
- CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher
+- CRYPTO_ALG_TYPE_SIG Asymmetric signature
+
- CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
decompression instead of performing the operation on one segment
diff --git a/Documentation/crypto/async-tx-api.rst b/Documentation/crypto/async-tx-api.rst
index bfc773991bdc..f88a7809385e 100644
--- a/Documentation/crypto/async-tx-api.rst
+++ b/Documentation/crypto/async-tx-api.rst
@@ -66,7 +66,7 @@ features surfaced as a result:
::
struct dma_async_tx_descriptor *
- async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
+ async_<operation>(<op specific parameters>, struct async_submit_ctl *submit)
3.2 Supported operations
------------------------
@@ -150,38 +150,38 @@ of an operation.
Perform a xor->copy->xor operation where each operation depends on the
result from the previous operation::
- void callback(void *param)
- {
- struct completion *cmp = param;
+ #include <linux/async_tx.h>
- complete(cmp);
+ static void callback(void *param)
+ {
+ complete(param);
}
- void run_xor_copy_xor(struct page **xor_srcs,
- int xor_src_cnt,
- struct page *xor_dest,
- size_t xor_len,
- struct page *copy_src,
- struct page *copy_dest,
- size_t copy_len)
+ #define NDISKS 2
+
+ static void run_xor_copy_xor(struct page **xor_srcs,
+ struct page *xor_dest,
+ size_t xor_len,
+ struct page *copy_src,
+ struct page *copy_dest,
+ size_t copy_len)
{
struct dma_async_tx_descriptor *tx;
- addr_conv_t addr_conv[xor_src_cnt];
struct async_submit_ctl submit;
addr_conv_t addr_conv[NDISKS];
struct completion cmp;
init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
addr_conv);
- tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
+ tx = async_xor(xor_dest, xor_srcs, 0, NDISKS, xor_len, &submit);
- submit->depend_tx = tx;
+ submit.depend_tx = tx;
tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
init_completion(&cmp);
init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
callback, &cmp, addr_conv);
- tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
+ tx = async_xor(xor_dest, xor_srcs, 0, NDISKS, xor_len, &submit);
async_tx_issue_pending_all();
diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst
index d562ea17d994..7ef850e28016 100644
--- a/Documentation/crypto/crypto_engine.rst
+++ b/Documentation/crypto/crypto_engine.rst
@@ -36,12 +36,6 @@ engine using ``crypto_engine_stop()`` and destroy the engine with
Before transferring any request, you have to fill the context enginectx by
providing functions for the following:
-* ``prepare_crypt_hardware``: Called once before any prepare functions are
- called.
-
-* ``unprepare_crypt_hardware``: Called once after all unprepare functions have
- been called.
-
* ``prepare_cipher_request``/``prepare_hash_request``: Called before each
corresponding request is performed. If some processing or other preparatory
work is required, do it here.
diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
index f225a953ab4b..9b7782f4f6e0 100644
--- a/Documentation/crypto/devel-algos.rst
+++ b/Documentation/crypto/devel-algos.rst
@@ -172,7 +172,7 @@ Here are schematics of how these functions are called when operated from
other part of the kernel. Note that the .setkey() call might happen
before or after any of these schematics happen, but must not happen
during any of these are in-flight. Please note that calling .init()
-followed immediately by .finish() is also a perfectly valid
+followed immediately by .final() is also a perfectly valid
transformation.
::
@@ -235,6 +235,4 @@ Specifics Of Asynchronous HASH Transformation
Some of the drivers will want to use the Generic ScatterWalk in case the
implementation needs to be fed separate chunks of the scatterlist which
-contains the input data. The buffer containing the resulting hash will
-always be properly aligned to .cra_alignmask so there is no need to
-worry about this.
+contains the input data.
diff --git a/Documentation/crypto/device_drivers/index.rst b/Documentation/crypto/device_drivers/index.rst
new file mode 100644
index 000000000000..c81d311ac61b
--- /dev/null
+++ b/Documentation/crypto/device_drivers/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Hardware Device Driver Specific Documentation
+---------------------------------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ octeontx2
diff --git a/Documentation/crypto/device_drivers/octeontx2.rst b/Documentation/crypto/device_drivers/octeontx2.rst
new file mode 100644
index 000000000000..7e469b173ac8
--- /dev/null
+++ b/Documentation/crypto/device_drivers/octeontx2.rst
@@ -0,0 +1,25 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================
+octeontx2 devlink support
+=========================
+
+This document describes the devlink features implemented by the ``octeontx2 CPT``
+device drivers.
+
+Parameters
+==========
+
+The ``octeontx2`` driver implements the following driver-specific parameters.
+
+.. list-table:: Driver-specific parameters implemented
+ :widths: 5 5 5 85
+
+ * - Name
+ - Type
+ - Mode
+ - Description
+ * - ``t106_mode``
+ - u8
+ - runtime
+ - Used to configure CN10KA B0/CN10KB CPT to work as CN10KA A0/A1.
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index 21338fa92642..4ee667c446f9 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -1,6 +1,6 @@
-=======================
-Linux Kernel Crypto API
-=======================
+==========
+Crypto API
+==========
:Author: Stephan Mueller
:Author: Marek Vasut
@@ -9,11 +9,8 @@ This documentation outlines the Linux kernel crypto API with its
concepts, details about developing cipher implementations, employment of the API
for cryptographic use cases, as well as programming examples.
-.. class:: toc-title
-
- Table of contents
-
.. toctree::
+ :caption: Table of contents
:maxdepth: 2
intro
@@ -28,3 +25,6 @@ for cryptographic use cases, as well as programming examples.
api
api-samples
descore-readme
+ device_drivers/index
+ krb5
+ sha3
diff --git a/Documentation/crypto/krb5.rst b/Documentation/crypto/krb5.rst
new file mode 100644
index 000000000000..beffa0133446
--- /dev/null
+++ b/Documentation/crypto/krb5.rst
@@ -0,0 +1,262 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Kerberos V Cryptography API
+===========================
+
+.. Contents:
+
+ - Overview.
+ - Small Buffer.
+ - Encoding Type.
+ - Key Derivation.
+ - PRF+ Calculation.
+ - Kc, Ke And Ki Derivation.
+ - Crypto Functions.
+ - Preparation Functions.
+ - Encryption Mode.
+ - Checksum Mode.
+ - The krb5enc AEAD algorithm
+
+Overview
+========
+
+This API provides Kerberos 5-style cryptography for key derivation, encryption
+and checksumming for use in network filesystems and can be used to implement
+the low-level crypto that's needed for GSSAPI.
+
+The following crypto types are supported::
+
+ KRB5_ENCTYPE_AES128_CTS_HMAC_SHA1_96
+ KRB5_ENCTYPE_AES256_CTS_HMAC_SHA1_96
+ KRB5_ENCTYPE_AES128_CTS_HMAC_SHA256_128
+ KRB5_ENCTYPE_AES256_CTS_HMAC_SHA384_192
+ KRB5_ENCTYPE_CAMELLIA128_CTS_CMAC
+ KRB5_ENCTYPE_CAMELLIA256_CTS_CMAC
+
+ KRB5_CKSUMTYPE_HMAC_SHA1_96_AES128
+ KRB5_CKSUMTYPE_HMAC_SHA1_96_AES256
+ KRB5_CKSUMTYPE_CMAC_CAMELLIA128
+ KRB5_CKSUMTYPE_CMAC_CAMELLIA256
+ KRB5_CKSUMTYPE_HMAC_SHA256_128_AES128
+ KRB5_CKSUMTYPE_HMAC_SHA384_192_AES256
+
+The API can be included by::
+
+ #include <crypto/krb5.h>
+
+Small Buffer
+------------
+
+To pass small pieces of data about, such as keys, a buffer structure is
+defined, giving a pointer to the data and the size of that data::
+
+ struct krb5_buffer {
+ unsigned int len;
+ void *data;
+ };
+
+Encoding Type
+=============
+
+The encoding type is defined by the following structure::
+
+ struct krb5_enctype {
+ int etype;
+ int ctype;
+ const char *name;
+ u16 key_bytes;
+ u16 key_len;
+ u16 Kc_len;
+ u16 Ke_len;
+ u16 Ki_len;
+ u16 prf_len;
+ u16 block_len;
+ u16 conf_len;
+ u16 cksum_len;
+ ...
+ };
+
+The fields of interest to the user of the API are as follows:
+
+ * ``etype`` and ``ctype`` indicate the protocol number for this encoding
+ type for encryption and checksumming respectively. They hold
+ ``KRB5_ENCTYPE_*`` and ``KRB5_CKSUMTYPE_*`` constants.
+
+ * ``name`` is the formal name of the encoding.
+
+ * ``key_len`` and ``key_bytes`` are the input key length and the derived key
+ length. (I think they only differ for DES, which isn't supported here).
+
+ * ``Kc_len``, ``Ke_len`` and ``Ki_len`` are the sizes of the derived Kc, Ke
+ and Ki keys. Kc is used for in checksum mode; Ke and Ki are used in
+ encryption mode.
+
+ * ``prf_len`` is the size of the result from the PRF+ function calculation.
+
+ * ``block_len``, ``conf_len`` and ``cksum_len`` are the encryption block
+ length, confounder length and checksum length respectively. All three are
+ used in encryption mode, but only the checksum length is used in checksum
+ mode.
+
+The encoding type is looked up by number using the following function::
+
+ const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype);
+
+Key Derivation
+==============
+
+Once the application has selected an encryption type, the keys that will be
+used to do the actual crypto can be derived from the transport key.
+
+PRF+ Calculation
+----------------
+
+To aid in key derivation, a function to calculate the Kerberos GSSAPI
+mechanism's PRF+ is provided::
+
+ int crypto_krb5_calc_PRFplus(const struct krb5_enctype *krb5,
+ const struct krb5_buffer *K,
+ unsigned int L,
+ const struct krb5_buffer *S,
+ struct krb5_buffer *result,
+ gfp_t gfp);
+
+This can be used to derive the transport key from a source key plus additional
+data to limit its use.
+
+Crypto Functions
+================
+
+Once the keys have been derived, crypto can be performed on the data. The
+caller must leave gaps in the buffer for the storage of the confounder (if
+needed) and the checksum when preparing a message for transmission. An enum
+and a pair of functions are provided to aid in this::
+
+ enum krb5_crypto_mode {
+ KRB5_CHECKSUM_MODE,
+ KRB5_ENCRYPT_MODE,
+ };
+
+ size_t crypto_krb5_how_much_buffer(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t data_size, size_t *_offset);
+
+ size_t crypto_krb5_how_much_data(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t *_buffer_size, size_t *_offset);
+
+All these functions take the encoding type and an indication the mode of crypto
+(checksum-only or full encryption).
+
+The first function returns how big the buffer will need to be to house a given
+amount of data; the second function returns how much data will fit in a buffer
+of a particular size, and adjusts down the size of the required buffer
+accordingly. In both cases, the offset of the data within the buffer is also
+returned.
+
+When a message has been received, the location and size of the data with the
+message can be determined by calling::
+
+ void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t *_offset, size_t *_len);
+
+The caller provides the offset and length of the message to the function, which
+then alters those values to indicate the region containing the data (plus any
+padding). It is up to the caller to determine how much padding there is.
+
+Preparation Functions
+---------------------
+
+Two functions are provided to allocated and prepare a crypto object for use by
+the action functions::
+
+ struct crypto_aead *
+ crypto_krb5_prepare_encryption(const struct krb5_enctype *krb5,
+ const struct krb5_buffer *TK,
+ u32 usage, gfp_t gfp);
+ struct crypto_shash *
+ crypto_krb5_prepare_checksum(const struct krb5_enctype *krb5,
+ const struct krb5_buffer *TK,
+ u32 usage, gfp_t gfp);
+
+Both of these functions take the encoding type, the transport key and the usage
+value used to derive the appropriate subkey(s). They create an appropriate
+crypto object, an AEAD template for encryption and a synchronous hash for
+checksumming, set the key(s) on it and configure it. The caller is expected to
+pass these handles to the action functions below.
+
+Encryption Mode
+---------------
+
+A pair of functions are provided to encrypt and decrypt a message::
+
+ ssize_t crypto_krb5_encrypt(const struct krb5_enctype *krb5,
+ struct crypto_aead *aead,
+ struct scatterlist *sg, unsigned int nr_sg,
+ size_t sg_len,
+ size_t data_offset, size_t data_len,
+ bool preconfounded);
+ int crypto_krb5_decrypt(const struct krb5_enctype *krb5,
+ struct crypto_aead *aead,
+ struct scatterlist *sg, unsigned int nr_sg,
+ size_t *_offset, size_t *_len);
+
+In both cases, the input and output buffers are indicated by the same
+scatterlist.
+
+For the encryption function, the output buffer may be larger than is needed
+(the amount of output generated is returned) and the location and size of the
+data are indicated (which must match the encoding). If no confounder is set,
+the function will insert one.
+
+For the decryption function, the offset and length of the message in buffer are
+supplied and these are shrunk to fit the data. The decryption function will
+verify any checksums within the message and give an error if they don't match.
+
+Checksum Mode
+-------------
+
+A pair of function are provided to generate the checksum on a message and to
+verify that checksum::
+
+ ssize_t crypto_krb5_get_mic(const struct krb5_enctype *krb5,
+ struct crypto_shash *shash,
+ const struct krb5_buffer *metadata,
+ struct scatterlist *sg, unsigned int nr_sg,
+ size_t sg_len,
+ size_t data_offset, size_t data_len);
+ int crypto_krb5_verify_mic(const struct krb5_enctype *krb5,
+ struct crypto_shash *shash,
+ const struct krb5_buffer *metadata,
+ struct scatterlist *sg, unsigned int nr_sg,
+ size_t *_offset, size_t *_len);
+
+In both cases, the input and output buffers are indicated by the same
+scatterlist. Additional metadata can be passed in which will get added to the
+hash before the data.
+
+For the get_mic function, the output buffer may be larger than is needed (the
+amount of output generated is returned) and the location and size of the data
+are indicated (which must match the encoding).
+
+For the verification function, the offset and length of the message in buffer
+are supplied and these are shrunk to fit the data. An error will be returned
+if the checksums don't match.
+
+The krb5enc AEAD algorithm
+==========================
+
+A template AEAD crypto algorithm, called "krb5enc", is provided that hashes the
+plaintext before encrypting it (the reverse of authenc). The handle returned
+by ``crypto_krb5_prepare_encryption()`` may be one of these, but there's no
+requirement for the user of this API to interact with it directly.
+
+For reference, its key format begins with a BE32 of the format number. Only
+format 1 is provided and that continues with a BE32 of the Ke key length
+followed by a BE32 of the Ki key length, followed by the bytes from the Ke key
+and then the Ki key.
+
+Using specifically ordered words means that the static test data doesn't
+require byteswapping.
diff --git a/Documentation/crypto/sha3.rst b/Documentation/crypto/sha3.rst
new file mode 100644
index 000000000000..37640f295118
--- /dev/null
+++ b/Documentation/crypto/sha3.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================
+SHA-3 Algorithm Collection
+==========================
+
+.. contents::
+
+Overview
+========
+
+The SHA-3 family of algorithms, as specified in NIST FIPS-202 [1]_, contains six
+algorithms based on the Keccak sponge function. The differences between them
+are: the "rate" (how much of the state buffer gets updated with new data between
+invocations of the Keccak function and analogous to the "block size"), what
+domain separation suffix gets appended to the input data, and how much output
+data is extracted at the end. The Keccak sponge function is designed such that
+arbitrary amounts of output can be obtained for certain algorithms.
+
+Four digest algorithms are provided:
+
+ - SHA3-224
+ - SHA3-256
+ - SHA3-384
+ - SHA3-512
+
+Additionally, two Extendable-Output Functions (XOFs) are provided:
+
+ - SHAKE128
+ - SHAKE256
+
+The SHA-3 library API supports all six of these algorithms. The four digest
+algorithms are also supported by the crypto_shash and crypto_ahash APIs.
+
+This document describes the SHA-3 library API.
+
+
+Digests
+=======
+
+The following functions compute SHA-3 digests::
+
+ void sha3_224(const u8 *in, size_t in_len, u8 out[SHA3_224_DIGEST_SIZE]);
+ void sha3_256(const u8 *in, size_t in_len, u8 out[SHA3_256_DIGEST_SIZE]);
+ void sha3_384(const u8 *in, size_t in_len, u8 out[SHA3_384_DIGEST_SIZE]);
+ void sha3_512(const u8 *in, size_t in_len, u8 out[SHA3_512_DIGEST_SIZE]);
+
+For users that need to pass in data incrementally, an incremental API is also
+provided. The incremental API uses the following struct::
+
+ struct sha3_ctx { ... };
+
+Initialization is done with one of::
+
+ void sha3_224_init(struct sha3_ctx *ctx);
+ void sha3_256_init(struct sha3_ctx *ctx);
+ void sha3_384_init(struct sha3_ctx *ctx);
+ void sha3_512_init(struct sha3_ctx *ctx);
+
+Input data is then added with any number of calls to::
+
+ void sha3_update(struct sha3_ctx *ctx, const u8 *in, size_t in_len);
+
+Finally, the digest is generated using::
+
+ void sha3_final(struct sha3_ctx *ctx, u8 *out);
+
+which also zeroizes the context. The length of the digest is determined by the
+initialization function that was called.
+
+
+Extendable-Output Functions
+===========================
+
+The following functions compute the SHA-3 extendable-output functions (XOFs)::
+
+ void shake128(const u8 *in, size_t in_len, u8 *out, size_t out_len);
+ void shake256(const u8 *in, size_t in_len, u8 *out, size_t out_len);
+
+For users that need to provide the input data incrementally and/or receive the
+output data incrementally, an incremental API is also provided. The incremental
+API uses the following struct::
+
+ struct shake_ctx { ... };
+
+Initialization is done with one of::
+
+ void shake128_init(struct shake_ctx *ctx);
+ void shake256_init(struct shake_ctx *ctx);
+
+Input data is then added with any number of calls to::
+
+ void shake_update(struct shake_ctx *ctx, const u8 *in, size_t in_len);
+
+Finally, the output data is extracted with any number of calls to::
+
+ void shake_squeeze(struct shake_ctx *ctx, u8 *out, size_t out_len);
+
+and telling it how much data should be extracted. Note that performing multiple
+squeezes, with the output laid consecutively in a buffer, gets exactly the same
+output as doing a single squeeze for the combined amount over the same buffer.
+
+More input data cannot be added after squeezing has started.
+
+Once all the desired output has been extracted, zeroize the context::
+
+ void shake_zeroize_ctx(struct shake_ctx *ctx);
+
+
+Testing
+=======
+
+To test the SHA-3 code, use sha3_kunit (CONFIG_CRYPTO_LIB_SHA3_KUNIT_TEST).
+
+Since the SHA-3 algorithms are FIPS-approved, when the kernel is booted in FIPS
+mode the SHA-3 library also performs a simple self-test. This is purely to meet
+a FIPS requirement. Normal testing done by kernel developers and integrators
+should use the much more comprehensive KUnit test suite instead.
+
+
+References
+==========
+
+.. [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
+
+
+API Function Reference
+======================
+
+.. kernel-doc:: include/crypto/sha3.h
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
index b45dabbf69d6..8158b363cd98 100644
--- a/Documentation/crypto/userspace-if.rst
+++ b/Documentation/crypto/userspace-if.rst
@@ -131,9 +131,9 @@ from the kernel crypto API. If the buffer is too small for the message
digest, the flag MSG_TRUNC is set by the kernel.
In order to set a message digest key, the calling application must use
-the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
-operation is performed without the initial HMAC state change caused by
-the key.
+the setsockopt() option of ALG_SET_KEY or ALG_SET_KEY_BY_KEY_SERIAL. If the
+key is not set the HMAC operation is performed without the initial HMAC state
+change caused by the key.
Symmetric Cipher API
--------------------
@@ -302,10 +302,9 @@ follows:
Depending on the RNG type, the RNG must be seeded. The seed is provided
-using the setsockopt interface to set the key. For example, the
-ansi_cprng requires a seed. The DRBGs do not require a seed, but may be
-seeded. The seed is also known as a *Personalization String* in NIST SP 800-90A
-standard.
+using the setsockopt interface to set the key. The SP800-90A DRBGs do
+not require a seed, but may be seeded. The seed is also known as a
+*Personalization String* in NIST SP 800-90A standard.
Using the read()/recvmsg() system calls, random numbers can be obtained.
The kernel generates at most 128 bytes in one call. If user space
@@ -382,6 +381,15 @@ mentioned optname:
- the RNG cipher type to provide the seed
+- ALG_SET_KEY_BY_KEY_SERIAL -- Setting the key via keyring key_serial_t.
+ This operation behaves the same as ALG_SET_KEY. The decrypted
+ data is copied from a keyring key, and uses that data as the
+ key for symmetric encryption.
+
+ The passed in key_serial_t must have the KEY_(POS|USR|GRP|OTH)_SEARCH
+ permission set, otherwise -EPERM is returned. Supports key types: user,
+ logon, encrypted, and trusted.
+
- ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size for
AEAD ciphers. For a encryption operation, the authentication tag of
the given size will be generated. For a decryption operation, the
diff --git a/Documentation/dev-tools/autofdo.rst b/Documentation/dev-tools/autofdo.rst
new file mode 100644
index 000000000000..bcf06e7d6ffa
--- /dev/null
+++ b/Documentation/dev-tools/autofdo.rst
@@ -0,0 +1,168 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===================================
+Using AutoFDO with the Linux kernel
+===================================
+
+This enables AutoFDO build support for the kernel when using
+the Clang compiler. AutoFDO (Auto-Feedback-Directed Optimization)
+is a type of profile-guided optimization (PGO) used to enhance the
+performance of binary executables. It gathers information about the
+frequency of execution of various code paths within a binary using
+hardware sampling. This data is then used to guide the compiler's
+optimization decisions, resulting in a more efficient binary. AutoFDO
+is a powerful optimization technique, and data indicates that it can
+significantly improve kernel performance. It's especially beneficial
+for workloads affected by front-end stalls.
+
+For AutoFDO builds, unlike non-FDO builds, the user must supply a
+profile. Acquiring an AutoFDO profile can be done in several ways.
+AutoFDO profiles are created by converting hardware sampling using
+the "perf" tool. It is crucial that the workload used to create these
+perf files is representative; they must exhibit runtime
+characteristics similar to the workloads that are intended to be
+optimized. Failure to do so will result in the compiler optimizing
+for the wrong objective.
+
+The AutoFDO profile often encapsulates the program's behavior. If the
+performance-critical codes are architecture-independent, the profile
+can be applied across platforms to achieve performance gains. For
+instance, using the profile generated on Intel architecture to build
+a kernel for AMD architecture can also yield performance improvements.
+
+There are two methods for acquiring a representative profile:
+(1) Sample real workloads using a production environment.
+(2) Generate the profile using a representative load test.
+When enabling the AutoFDO build configuration without providing an
+AutoFDO profile, the compiler only modifies the dwarf information in
+the kernel without impacting runtime performance. It's advisable to
+use a kernel binary built with the same AutoFDO configuration to
+collect the perf profile. While it's possible to use a kernel built
+with different options, it may result in inferior performance.
+
+One can collect profiles using AutoFDO build for the previous kernel.
+AutoFDO employs relative line numbers to match the profiles, offering
+some tolerance for source changes. This mode is commonly used in a
+production environment for profile collection.
+
+In a profile collection based on a load test, the AutoFDO collection
+process consists of the following steps:
+
+#. Initial build: The kernel is built with AutoFDO options
+ without a profile.
+
+#. Profiling: The above kernel is then run with a representative
+ workload to gather execution frequency data. This data is
+ collected using hardware sampling, via perf. AutoFDO is most
+ effective on platforms supporting advanced PMU features like
+ LBR on Intel machines.
+
+#. AutoFDO profile generation: Perf output file is converted to
+ the AutoFDO profile via offline tools.
+
+The support requires a Clang compiler LLVM 17 or later.
+
+Preparation
+===========
+
+Configure the kernel with::
+
+ CONFIG_AUTOFDO_CLANG=y
+
+Customization
+=============
+
+The default CONFIG_AUTOFDO_CLANG setting covers kernel space objects for
+AutoFDO builds. One can, however, enable or disable AutoFDO build for
+individual files and directories by adding a line similar to the following
+to the respective kernel Makefile:
+
+- For enabling a single file (e.g. foo.o) ::
+
+ AUTOFDO_PROFILE_foo.o := y
+
+- For enabling all files in one directory ::
+
+ AUTOFDO_PROFILE := y
+
+- For disabling one file ::
+
+ AUTOFDO_PROFILE_foo.o := n
+
+- For disabling all files in one directory ::
+
+ AUTOFDO_PROFILE := n
+
+Workflow
+========
+
+Here is an example workflow for AutoFDO kernel:
+
+1) Build the kernel on the host machine with LLVM enabled,
+ for example, ::
+
+ $ make menuconfig LLVM=1
+
+ Turn on AutoFDO build config::
+
+ CONFIG_AUTOFDO_CLANG=y
+
+ With a configuration that with LLVM enabled, use the following command::
+
+ $ scripts/config -e AUTOFDO_CLANG
+
+ After getting the config, build with ::
+
+ $ make LLVM=1
+
+2) Install the kernel on the test machine.
+
+3) Run the load tests. The '-c' option in perf specifies the sample
+ event period. We suggest using a suitable prime number, like 500009,
+ for this purpose.
+
+ - For Intel platforms::
+
+ $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
+
+ - For AMD platforms:
+
+ The supported systems are: Zen3 with BRS, or Zen4 with amd_lbr_v2. To check,
+
+ For Zen3::
+
+ $ cat /proc/cpuinfo | grep " brs"
+
+ For Zen4::
+
+ $ cat /proc/cpuinfo | grep amd_lbr_v2
+
+ The following command generated the perf data file::
+
+ $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
+
+4) (Optional) Download the raw perf file to the host machine.
+
+5) To generate an AutoFDO profile, two offline tools are available:
+ create_llvm_prof and llvm_profgen. The create_llvm_prof tool is part
+ of the AutoFDO project and can be found on GitHub
+ (https://github.com/google/autofdo), version v0.30.1 or later.
+ The llvm_profgen tool is included in the LLVM compiler itself. It's
+ important to note that the version of llvm_profgen doesn't need to match
+ the version of Clang. It needs to be the LLVM 19 release of Clang
+ or later, or just from the LLVM trunk. ::
+
+ $ llvm-profgen --kernel --binary=<vmlinux> --perfdata=<perf_file> -o <profile_file>
+
+ or ::
+
+ $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> --format=extbinary --out=<profile_file>
+
+ Note that multiple AutoFDO profile files can be merged into one via::
+
+ $ llvm-profdata merge -o <profile_file> <profile_1> <profile_2> ... <profile_n>
+
+6) Rebuild the kernel using the AutoFDO profile file with the same config as step 1,
+ (Note CONFIG_AUTOFDO_CLANG needs to be enabled)::
+
+ $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<profile_file>
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index b52452bc2963..fa2988dd4657 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -168,7 +168,7 @@ Available options:
- --fix
- This is an EXPERIMENTAL feature. If correctable errors exists, a file
+ This is an EXPERIMENTAL feature. If correctable errors exist, a file
<inputfile>.EXPERIMENTAL-checkpatch-fixes is created which has the
automatically fixable errors corrected.
@@ -181,7 +181,7 @@ Available options:
- --ignore-perl-version
- Override checking of perl version. Runtime errors maybe encountered after
+ Override checking of perl version. Runtime errors may be encountered after
enabling this flag if the perl version does not meet the minimum specified.
- --codespell
@@ -342,24 +342,6 @@ API usage
See: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#full-list-of-rcu-apis
- **DEPRECATED_VARIABLE**
- EXTRA_{A,C,CPP,LD}FLAGS are deprecated and should be replaced by the new
- flags added via commit f77bf01425b1 ("kbuild: introduce ccflags-y,
- asflags-y and ldflags-y").
-
- The following conversion scheme maybe used::
-
- EXTRA_AFLAGS -> asflags-y
- EXTRA_CFLAGS -> ccflags-y
- EXTRA_CPPFLAGS -> cppflags-y
- EXTRA_LDFLAGS -> ldflags-y
-
- See:
-
- 1. https://lore.kernel.org/lkml/20070930191054.GA15876@uranus.ravnborg.org/
- 2. https://lore.kernel.org/lkml/1313384834-24433-12-git-send-email-lacombar@gmail.com/
- 3. https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#compilation-flags
-
**DEVICE_ATTR_FUNCTIONS**
The function names used in DEVICE_ATTR is unusual.
Typically, the store and show functions are used with <attr>_store and
@@ -470,8 +452,6 @@ API usage
usleep_range() should be preferred over udelay(). The proper way of
using usleep_range() is mentioned in the kernel docs.
- See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms
-
Comments
--------
@@ -481,16 +461,9 @@ Comments
line comments is::
/*
- * This is the preferred style
- * for multi line comments.
- */
-
- The networking comment style is a bit different, with the first line
- not empty like the former::
-
- /* This is the preferred comment style
- * for files in net/ and drivers/net/
- */
+ * This is the preferred style
+ * for multi line comments.
+ */
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting
@@ -515,6 +488,15 @@ Comments
See: https://lore.kernel.org/lkml/20131006222342.GT19510@leaf/
+ **UNCOMMENTED_RGMII_MODE**
+ Historically, the RGMII PHY modes specified in Device Trees have been
+ used inconsistently, often referring to the usage of delays on the PHY
+ side rather than describing the board.
+
+ PHY modes "rgmii", "rgmii-rxid" and "rgmii-txid" modes require the clock
+ signal to be delayed on the PCB; this unusual configuration should be
+ described in a comment. If they are not (meaning that the delay is realized
+ internally in the MAC or PHY), "rgmii-id" is the correct PHY mode.
Commit message
--------------
@@ -612,6 +594,13 @@ Commit message
See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
+ **BAD_FIXES_TAG**
+ The Fixes: tag is malformed or does not follow the community conventions.
+ This can occur if the tag have been split into multiple lines (e.g., when
+ pasted in an email program with word wrapping enabled).
+
+ See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
+
Comparison style
----------------
@@ -899,6 +888,20 @@ Macros, Attributes and Symbols
See: https://lore.kernel.org/lkml/1399671106.2912.21.camel@joe-AO725/
+ **MACRO_ARG_UNUSED**
+ If function-like macros do not utilize a parameter, it might result
+ in a build warning. We advocate for utilizing static inline functions
+ to replace such macros.
+ For example, for a macro such as the one below::
+
+ #define test(a) do { } while (0)
+
+ there would be a warning like below::
+
+ WARNING: Argument 'a' is not used in function-like macro.
+
+ See: https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl
+
**SINGLE_STATEMENT_DO_WHILE_MACRO**
For the multi-statement macros, it is necessary to use the do-while
loop to avoid unpredictable code paths. The do-while loop helps to
@@ -1235,6 +1238,16 @@ Others
The patch file does not appear to be in unified-diff format. Please
regenerate the patch file before sending it to the maintainer.
+ **PLACEHOLDER_USE**
+ Detects unhandled placeholder text left in cover letters or commit headers/logs.
+ Common placeholders include lines like::
+
+ *** SUBJECT HERE ***
+ *** BLURB HERE ***
+
+ These typically come from autogenerated templates. Replace them with a proper
+ subject and description before sending.
+
**PRINTF_0XDECIMAL**
Prefixing 0x with decimal output is defective and should be corrected.
diff --git a/Documentation/dev-tools/checkuapi.rst b/Documentation/dev-tools/checkuapi.rst
new file mode 100644
index 000000000000..9072f21b50b0
--- /dev/null
+++ b/Documentation/dev-tools/checkuapi.rst
@@ -0,0 +1,477 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+============
+UAPI Checker
+============
+
+The UAPI checker (``scripts/check-uapi.sh``) is a shell script which
+checks UAPI header files for userspace backwards-compatibility across
+the git tree.
+
+Options
+=======
+
+This section will describe the options with which ``check-uapi.sh``
+can be run.
+
+Usage::
+
+ check-uapi.sh [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-i] [-q] [-v]
+
+Available options::
+
+ -b BASE_REF Base git reference to use for comparison. If unspecified or empty,
+ will use any dirty changes in tree to UAPI files. If there are no
+ dirty changes, HEAD will be used.
+ -p PAST_REF Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
+ will use BASE_REF^1. Must be an ancestor of BASE_REF. Only headers
+ that exist on PAST_REF will be checked for compatibility.
+ -j JOBS Number of checks to run in parallel (default: number of CPU cores).
+ -l ERROR_LOG Write error log to file (default: no error log is generated).
+ -i Ignore ambiguous changes that may or may not break UAPI compatibility.
+ -q Quiet operation.
+ -v Verbose operation (print more information about each header being checked).
+
+Environmental args::
+
+ ABIDIFF Custom path to abidiff binary
+ CC C compiler (default is "gcc")
+ ARCH Target architecture of C compiler (default is host arch)
+
+Exit codes::
+
+ 0) Success
+ 1) ABI difference detected
+ 2) Prerequisite not met
+
+Examples
+========
+
+Basic Usage
+-----------
+
+First, let's try making a change to a UAPI header file that obviously
+won't break userspace::
+
+ cat << 'EOF' | patch -l -p1
+ --- a/include/uapi/linux/acct.h
+ +++ b/include/uapi/linux/acct.h
+ @@ -21,7 +21,9 @@
+ #include <asm/param.h>
+ #include <asm/byteorder.h>
+
+ -/*
+ +#define FOO
+ +
+ +/*
+ * comp_t is a 16-bit "floating" point number with a 3-bit base 8
+ * exponent and a 13-bit fraction.
+ * comp2_t is 24-bit with 5-bit base 2 exponent and 20 bit fraction
+ diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
+ EOF
+
+Now, let's use the script to validate::
+
+ % ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ All 912 UAPI headers compatible with x86 appear to be backwards compatible
+
+Let's add another change that *might* break userspace::
+
+ cat << 'EOF' | patch -l -p1
+ --- a/include/uapi/linux/bpf.h
+ +++ b/include/uapi/linux/bpf.h
+ @@ -74,7 +74,7 @@ struct bpf_insn {
+ __u8 dst_reg:4; /* dest register */
+ __u8 src_reg:4; /* source register */
+ __s16 off; /* signed offset */
+ - __s32 imm; /* signed immediate constant */
+ + __u32 imm; /* unsigned immediate constant */
+ };
+
+ /* Key of an a BPF_MAP_TYPE_LPM_TRIE entry */
+ EOF
+
+The script will catch this::
+
+ % ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ ==== ABI differences detected in include/linux/bpf.h from HEAD -> dirty tree ====
+ [C] 'struct bpf_insn' changed:
+ type size hasn't changed
+ 1 data member change:
+ type of '__s32 imm' changed:
+ typedef name changed from __s32 to __u32 at int-ll64.h:27:1
+ underlying type 'int' changed:
+ type name changed from 'int' to 'unsigned int'
+ type size hasn't changed
+ ==================================================================================
+
+ error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+In this case, the script is reporting the type change because it could
+break a userspace program that passes in a negative number. Now, let's
+say you know that no userspace program could possibly be using a negative
+value in ``imm``, so changing to an unsigned type there shouldn't hurt
+anything. You can pass the ``-i`` flag to the script to ignore changes
+in which the userspace backwards compatibility is ambiguous::
+
+ % ./scripts/check-uapi.sh -i
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ All 912 UAPI headers compatible with x86 appear to be backwards compatible
+
+Now, let's make a similar change that *will* break userspace::
+
+ cat << 'EOF' | patch -l -p1
+ --- a/include/uapi/linux/bpf.h
+ +++ b/include/uapi/linux/bpf.h
+ @@ -71,8 +71,8 @@ enum {
+
+ struct bpf_insn {
+ __u8 code; /* opcode */
+ - __u8 dst_reg:4; /* dest register */
+ __u8 src_reg:4; /* source register */
+ + __u8 dst_reg:4; /* dest register */
+ __s16 off; /* signed offset */
+ __s32 imm; /* signed immediate constant */
+ };
+ EOF
+
+Since we're re-ordering an existing struct member, there's no ambiguity,
+and the script will report the breakage even if you pass ``-i``::
+
+ % ./scripts/check-uapi.sh -i
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ ==== ABI differences detected in include/linux/bpf.h from HEAD -> dirty tree ====
+ [C] 'struct bpf_insn' changed:
+ type size hasn't changed
+ 2 data member changes:
+ '__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
+ '__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)
+ ==================================================================================
+
+ error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Let's commit the breaking change, then commit the innocuous change::
+
+ % git commit -m 'Breaking UAPI change' include/uapi/linux/bpf.h
+ [detached HEAD f758e574663a] Breaking UAPI change
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+ % git commit -m 'Innocuous UAPI change' include/uapi/linux/acct.h
+ [detached HEAD 2e87df769081] Innocuous UAPI change
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+Now, let's run the script again with no arguments::
+
+ % ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from HEAD... OK
+ Installing user-facing UAPI headers from HEAD^1... OK
+ Checking changes to UAPI headers between HEAD^1 and HEAD...
+ All 912 UAPI headers compatible with x86 appear to be backwards compatible
+
+It doesn't catch any breaking change because, by default, it only
+compares ``HEAD`` to ``HEAD^1``. The breaking change was committed on
+``HEAD~2``. If we wanted the search scope to go back further, we'd have to
+use the ``-p`` option to pass a different past reference. In this case,
+let's pass ``-p HEAD~2`` to the script so it checks UAPI changes between
+``HEAD~2`` and ``HEAD``::
+
+ % ./scripts/check-uapi.sh -p HEAD~2
+ Installing user-facing UAPI headers from HEAD... OK
+ Installing user-facing UAPI headers from HEAD~2... OK
+ Checking changes to UAPI headers between HEAD~2 and HEAD...
+ ==== ABI differences detected in include/linux/bpf.h from HEAD~2 -> HEAD ====
+ [C] 'struct bpf_insn' changed:
+ type size hasn't changed
+ 2 data member changes:
+ '__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
+ '__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)
+ ==============================================================================
+
+ error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Alternatively, we could have also run with ``-b HEAD~``. This would set the
+base reference to ``HEAD~`` so then the script would compare it to ``HEAD~^1``.
+
+Architecture-specific Headers
+-----------------------------
+
+Consider this change::
+
+ cat << 'EOF' | patch -l -p1
+ --- a/arch/arm64/include/uapi/asm/sigcontext.h
+ +++ b/arch/arm64/include/uapi/asm/sigcontext.h
+ @@ -70,6 +70,7 @@ struct sigcontext {
+ struct _aarch64_ctx {
+ __u32 magic;
+ __u32 size;
+ + __u32 new_var;
+ };
+
+ #define FPSIMD_MAGIC 0x46508001
+ EOF
+
+This is a change to an arm64-specific UAPI header file. In this example, I'm
+running the script from an x86 machine with an x86 compiler, so, by default,
+the script only checks x86-compatible UAPI header files::
+
+ % ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ No changes to UAPI headers were applied between HEAD and dirty tree
+
+With an x86 compiler, we can't check header files in ``arch/arm64``, so the
+script doesn't even try.
+
+If we want to check the header file, we'll have to use an arm64 compiler and
+set ``ARCH`` accordingly::
+
+ % CC=aarch64-linux-gnu-gcc ARCH=arm64 ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ ==== ABI differences detected in include/asm/sigcontext.h from HEAD -> dirty tree ====
+ [C] 'struct _aarch64_ctx' changed:
+ type size changed from 64 to 96 (in bits)
+ 1 data member insertion:
+ '__u32 new_var', at offset 64 (in bits) at sigcontext.h:73:1
+ -- snip --
+ [C] 'struct zt_context' changed:
+ type size changed from 128 to 160 (in bits)
+ 2 data member changes (1 filtered):
+ '__u16 nregs' offset changed from 64 to 96 (in bits) (by +32 bits)
+ '__u16 __reserved[3]' offset changed from 80 to 112 (in bits) (by +32 bits)
+ =======================================================================================
+
+ error - 1/884 UAPI headers compatible with arm64 appear _not_ to be backwards compatible
+
+We can see with ``ARCH`` and ``CC`` set properly for the file, the ABI
+change is reported properly. Also notice that the total number of UAPI
+header files checked by the script changes. This is because the number
+of headers installed for arm64 platforms is different than x86.
+
+Cross-Dependency Breakages
+--------------------------
+
+Consider this change::
+
+ cat << 'EOF' | patch -l -p1
+ --- a/include/uapi/linux/types.h
+ +++ b/include/uapi/linux/types.h
+ @@ -52,7 +52,7 @@ typedef __u32 __bitwise __wsum;
+ #define __aligned_be64 __be64 __attribute__((aligned(8)))
+ #define __aligned_le64 __le64 __attribute__((aligned(8)))
+
+ -typedef unsigned __bitwise __poll_t;
+ +typedef unsigned short __bitwise __poll_t;
+
+ #endif /* __ASSEMBLY__ */
+ #endif /* _UAPI_LINUX_TYPES_H */
+ EOF
+
+Here, we're changing a ``typedef`` in ``types.h``. This doesn't break
+a UAPI in ``types.h``, but other UAPIs in the tree may break due to
+this change::
+
+ % ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ ==== ABI differences detected in include/linux/eventpoll.h from HEAD -> dirty tree ====
+ [C] 'struct epoll_event' changed:
+ type size changed from 96 to 80 (in bits)
+ 2 data member changes:
+ type of '__poll_t events' changed:
+ underlying type 'unsigned int' changed:
+ type name changed from 'unsigned int' to 'unsigned short int'
+ type size changed from 32 to 16 (in bits)
+ '__u64 data' offset changed from 32 to 16 (in bits) (by -16 bits)
+ ========================================================================================
+ include/linux/eventpoll.h did not change between HEAD and dirty tree...
+ It's possible a change to one of the headers it includes caused this error:
+ #include <linux/fcntl.h>
+ #include <linux/types.h>
+
+Note that the script noticed the failing header file did not change,
+so it assumes one of its includes must have caused the breakage. Indeed,
+we can see ``linux/types.h`` is used from ``eventpoll.h``.
+
+UAPI Header Removals
+--------------------
+
+Consider this change::
+
+ cat << 'EOF' | patch -l -p1
+ diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
+ index ebb180aac74e..a9c88b0a8b3b 100644
+ --- a/include/uapi/asm-generic/Kbuild
+ +++ b/include/uapi/asm-generic/Kbuild
+ @@ -31,6 +31,6 @@ mandatory-y += stat.h
+ mandatory-y += statfs.h
+ mandatory-y += swab.h
+ mandatory-y += termbits.h
+ -mandatory-y += termios.h
+ +#mandatory-y += termios.h
+ mandatory-y += types.h
+ mandatory-y += unistd.h
+ EOF
+
+This script removes a UAPI header file from the install list. Let's run
+the script::
+
+ % ./scripts/check-uapi.sh
+ Installing user-facing UAPI headers from dirty tree... OK
+ Installing user-facing UAPI headers from HEAD... OK
+ Checking changes to UAPI headers between HEAD and dirty tree...
+ ==== UAPI header include/asm/termios.h was removed between HEAD and dirty tree ====
+
+ error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Removing a UAPI header is considered a breaking change, and the script
+will flag it as such.
+
+Checking Historic UAPI Compatibility
+------------------------------------
+
+You can use the ``-b`` and ``-p`` options to examine different chunks of your
+git tree. For example, to check all changed UAPI header files between tags
+v6.0 and v6.1, you'd run::
+
+ % ./scripts/check-uapi.sh -b v6.1 -p v6.0
+ Installing user-facing UAPI headers from v6.1... OK
+ Installing user-facing UAPI headers from v6.0... OK
+ Checking changes to UAPI headers between v6.0 and v6.1...
+
+ --- snip ---
+ error - 37/907 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+Note: Before v5.3, a header file needed by the script is not present,
+so the script is unable to check changes before then.
+
+You'll notice that the script detected many UAPI changes that are not
+backwards compatible. Knowing that kernel UAPIs are supposed to be stable
+forever, this is an alarming result. This brings us to the next section:
+caveats.
+
+Caveats
+=======
+
+The UAPI checker makes no assumptions about the author's intention, so some
+types of changes may be flagged even though they intentionally break UAPI.
+
+Removals For Refactoring or Deprecation
+---------------------------------------
+
+Sometimes drivers for very old hardware are removed, such as in this example::
+
+ % ./scripts/check-uapi.sh -b ba47652ba655
+ Installing user-facing UAPI headers from ba47652ba655... OK
+ Installing user-facing UAPI headers from ba47652ba655^1... OK
+ Checking changes to UAPI headers between ba47652ba655^1 and ba47652ba655...
+ ==== UAPI header include/linux/meye.h was removed between ba47652ba655^1 and ba47652ba655 ====
+
+ error - 1/910 UAPI headers compatible with x86 appear _not_ to be backwards compatible
+
+The script will always flag removals (even if they're intentional).
+
+Struct Expansions
+-----------------
+
+Depending on how a structure is handled in kernelspace, a change which
+expands a struct could be non-breaking.
+
+If a struct is used as the argument to an ioctl, then the kernel driver
+must be able to handle ioctl commands of any size. Beyond that, you need
+to be careful when copying data from the user. Say, for example, that
+``struct foo`` is changed like this::
+
+ struct foo {
+ __u64 a; /* added in version 1 */
+ + __u32 b; /* added in version 2 */
+ + __u32 c; /* added in version 2 */
+ }
+
+By default, the script will flag this kind of change for further review::
+
+ [C] 'struct foo' changed:
+ type size changed from 64 to 128 (in bits)
+ 2 data member insertions:
+ '__u32 b', at offset 64 (in bits)
+ '__u32 c', at offset 96 (in bits)
+
+However, it is possible that this change was made safely.
+
+If a userspace program was built with version 1, it will think
+``sizeof(struct foo)`` is 8. That size will be encoded in the
+ioctl value that gets sent to the kernel. If the kernel is built
+with version 2, it will think the ``sizeof(struct foo)`` is 16.
+
+The kernel can use the ``_IOC_SIZE`` macro to get the size encoded
+in the ioctl code that the user passed in and then use
+``copy_struct_from_user()`` to safely copy the value::
+
+ int handle_ioctl(unsigned long cmd, unsigned long arg)
+ {
+ switch _IOC_NR(cmd) {
+ 0x01: {
+ struct foo my_cmd; /* size 16 in the kernel */
+
+ ret = copy_struct_from_user(&my_cmd, arg, sizeof(struct foo), _IOC_SIZE(cmd));
+ ...
+
+``copy_struct_from_user`` will zero the struct in the kernel and then copy
+only the bytes passed in from the user (leaving new members zeroized).
+If the user passed in a larger struct, the extra members are ignored.
+
+If you know this situation is accounted for in the kernel code, you can
+pass ``-i`` to the script, and struct expansions like this will be ignored.
+
+Flex Array Migration
+--------------------
+
+While the script handles expansion into an existing flex array, it does
+still flag initial migration to flex arrays from 1-element fake flex
+arrays. For example::
+
+ struct foo {
+ __u32 x;
+ - __u32 flex[1]; /* fake flex */
+ + __u32 flex[]; /* real flex */
+ };
+
+This change would be flagged by the script::
+
+ [C] 'struct foo' changed:
+ type size changed from 64 to 32 (in bits)
+ 1 data member change:
+ type of '__u32 flex[1]' changed:
+ type name changed from '__u32[1]' to '__u32[]'
+ array type size changed from 32 to 'unknown'
+ array type subrange 1 changed length from 1 to 'unknown'
+
+At this time, there's no way to filter these types of changes, so be
+aware of this possible false positive.
+
+Summary
+-------
+
+While many types of false positives are filtered out by the script,
+it's possible there are some cases where the script flags a change
+which does not break UAPI. It's also possible a change which *does*
+break userspace would not be flagged by this script. While the script
+has been run on much of the kernel history, there could still be corner
+cases that are not accounted for.
+
+The intention is for this script to be used as a quick check for
+maintainers or automated tooling, not as the end-all authority on
+patch compatibility. It's best to remember: use your best judgment
+(and ideally a unit test in userspace) to make sure your UAPI changes
+are backwards-compatible!
diff --git a/Documentation/process/clang-format.rst b/Documentation/dev-tools/clang-format.rst
index 1d089a847c1b..1d089a847c1b 100644
--- a/Documentation/process/clang-format.rst
+++ b/Documentation/dev-tools/clang-format.rst
diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst
index d9976069ed12..6e70a1e9a3c0 100644
--- a/Documentation/dev-tools/coccinelle.rst
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -219,7 +219,7 @@ instance::
cat cocci.err
You can use SPFLAGS to add debugging flags; for instance you may want to
-add both --profile --show-trying to SPFLAGS when debugging. For example
+add both ``--profile --show-trying`` to SPFLAGS when debugging. For example
you may want to use::
rm -f err.log
@@ -248,27 +248,19 @@ variables for .cocciconfig is as follows:
- Your current user's home directory is processed first
- Your directory from which spatch is called is processed next
-- The directory provided with the --dir option is processed last, if used
-
-Since coccicheck runs through make, it naturally runs from the kernel
-proper dir; as such the second rule above would be implied for picking up a
-.cocciconfig when using ``make coccicheck``.
+- The directory provided with the ``--dir`` option is processed last, if used
``make coccicheck`` also supports using M= targets. If you do not supply
any M= target, it is assumed you want to target the entire kernel.
The kernel coccicheck script has::
- if [ "$KBUILD_EXTMOD" = "" ] ; then
- OPTIONS="--dir $srctree $COCCIINCLUDE"
- else
- OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
- fi
-
-KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
-the spatch --dir argument is used, as such third rule applies when whether M=
-is used or not, and when M= is used the target directory can have its own
-.cocciconfig file. When M= is not passed as an argument to coccicheck the
-target directory is the same as the directory from where spatch was called.
+ OPTIONS="--dir $srcroot $COCCIINCLUDE"
+
+Here, $srcroot refers to the source directory of the target: it points to the
+external module's source directory when M= used, and otherwise, to the kernel
+source directory. The third rule ensures the spatch reads the .cocciconfig from
+the target directory, allowing external modules to have their own .cocciconfig
+file.
If not using the kernel's coccicheck target, keep the above precedence
order logic of .cocciconfig reading. If using the kernel's coccicheck target,
diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst
index 5fce2b06f229..075df6a4598d 100644
--- a/Documentation/dev-tools/gcov.rst
+++ b/Documentation/dev-tools/gcov.rst
@@ -23,7 +23,7 @@ Possible uses:
associated code is never run?)
.. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
-.. _lcov: http://ltp.sourceforge.net/coverage/lcov.php
+.. _lcov: https://github.com/linux-test-project/lcov
Preparation
@@ -75,6 +75,17 @@ Only files which are linked to the main kernel image or are compiled as
kernel modules are supported by this mechanism.
+Module specific configs
+-----------------------
+
+Gcov kernel configs for specific modules are described below:
+
+CONFIG_GCOV_PROFILE_RDS:
+ Enables GCOV profiling on RDS for checking which functions or
+ lines are executed. This config is used by the rds selftest to
+ generate coverage reports. If left unset the report is omitted.
+
+
Files
-----
diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst b/Documentation/dev-tools/gdb-kernel-debugging.rst
deleted file mode 100644
index 8e0f1fe8d17a..000000000000
--- a/Documentation/dev-tools/gdb-kernel-debugging.rst
+++ /dev/null
@@ -1,175 +0,0 @@
-.. highlight:: none
-
-Debugging kernel and modules via gdb
-====================================
-
-The kernel debugger kgdb, hypervisors like QEMU or JTAG-based hardware
-interfaces allow to debug the Linux kernel and its modules during runtime
-using gdb. Gdb comes with a powerful scripting interface for python. The
-kernel provides a collection of helper scripts that can simplify typical
-kernel debugging steps. This is a short tutorial about how to enable and use
-them. It focuses on QEMU/KVM virtual machines as target, but the examples can
-be transferred to the other gdb stubs as well.
-
-
-Requirements
-------------
-
-- gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true
- for distributions)
-
-
-Setup
------
-
-- Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and
- www.qemu.org for more details). For cross-development,
- https://landley.net/aboriginal/bin keeps a pool of machine images and
- toolchains that can be helpful to start from.
-
-- Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave
- CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
- CONFIG_FRAME_POINTER, keep it enabled.
-
-- Install that kernel on the guest, turn off KASLR if necessary by adding
- "nokaslr" to the kernel command line.
- Alternatively, QEMU allows to boot the kernel directly using -kernel,
- -append, -initrd command line switches. This is generally only useful if
- you do not depend on modules. See QEMU documentation for more details on
- this mode. In this case, you should build the kernel with
- CONFIG_RANDOMIZE_BASE disabled if the architecture supports KASLR.
-
-- Enable the gdb stub of QEMU/KVM, either
-
- - at VM startup time by appending "-s" to the QEMU command line
-
- or
-
- - during runtime by issuing "gdbserver" from the QEMU monitor
- console
-
-- cd /path/to/linux-build
-
-- Start gdb: gdb vmlinux
-
- Note: Some distros may restrict auto-loading of gdb scripts to known safe
- directories. In case gdb reports to refuse loading vmlinux-gdb.py, add::
-
- add-auto-load-safe-path /path/to/linux-build
-
- to ~/.gdbinit. See gdb help for more details.
-
-- Attach to the booted guest::
-
- (gdb) target remote :1234
-
-
-Examples of using the Linux-provided gdb helpers
-------------------------------------------------
-
-- Load module (and main kernel) symbols::
-
- (gdb) lx-symbols
- loading vmlinux
- scanning for modules in /home/user/linux/build
- loading @0xffffffffa0020000: /home/user/linux/build/net/netfilter/xt_tcpudp.ko
- loading @0xffffffffa0016000: /home/user/linux/build/net/netfilter/xt_pkttype.ko
- loading @0xffffffffa0002000: /home/user/linux/build/net/netfilter/xt_limit.ko
- loading @0xffffffffa00ca000: /home/user/linux/build/net/packet/af_packet.ko
- loading @0xffffffffa003c000: /home/user/linux/build/fs/fuse/fuse.ko
- ...
- loading @0xffffffffa0000000: /home/user/linux/build/drivers/ata/ata_generic.ko
-
-- Set a breakpoint on some not yet loaded module function, e.g.::
-
- (gdb) b btrfs_init_sysfs
- Function "btrfs_init_sysfs" not defined.
- Make breakpoint pending on future shared library load? (y or [n]) y
- Breakpoint 1 (btrfs_init_sysfs) pending.
-
-- Continue the target::
-
- (gdb) c
-
-- Load the module on the target and watch the symbols being loaded as well as
- the breakpoint hit::
-
- loading @0xffffffffa0034000: /home/user/linux/build/lib/libcrc32c.ko
- loading @0xffffffffa0050000: /home/user/linux/build/lib/lzo/lzo_compress.ko
- loading @0xffffffffa006e000: /home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko
- loading @0xffffffffa01b1000: /home/user/linux/build/fs/btrfs/btrfs.ko
-
- Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
- 36 btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj);
-
-- Dump the log buffer of the target kernel::
-
- (gdb) lx-dmesg
- [ 0.000000] Initializing cgroup subsys cpuset
- [ 0.000000] Initializing cgroup subsys cpu
- [ 0.000000] Linux version 3.8.0-rc4-dbg+ (...
- [ 0.000000] Command line: root=/dev/sda2 resume=/dev/sda1 vga=0x314
- [ 0.000000] e820: BIOS-provided physical RAM map:
- [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
- [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
- ....
-
-- Examine fields of the current task struct(supported by x86 and arm64 only)::
-
- (gdb) p $lx_current().pid
- $1 = 4998
- (gdb) p $lx_current().comm
- $2 = "modprobe\000\000\000\000\000\000\000"
-
-- Make use of the per-cpu function for the current or a specified CPU::
-
- (gdb) p $lx_per_cpu("runqueues").nr_running
- $3 = 1
- (gdb) p $lx_per_cpu("runqueues", 2).nr_running
- $4 = 0
-
-- Dig into hrtimers using the container_of helper::
-
- (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next
- (gdb) p *$container_of($next, "struct hrtimer", "node")
- $5 = {
- node = {
- node = {
- __rb_parent_color = 18446612133355256072,
- rb_right = 0x0 <irq_stack_union>,
- rb_left = 0x0 <irq_stack_union>
- },
- expires = {
- tv64 = 1835268000000
- }
- },
- _softexpires = {
- tv64 = 1835268000000
- },
- function = 0xffffffff81078232 <tick_sched_timer>,
- base = 0xffff88003fd0d6f0,
- state = 1,
- start_pid = 0,
- start_site = 0xffffffff81055c1f <hrtimer_start_range_ns+20>,
- start_comm = "swapper/2\000\000\000\000\000\000"
- }
-
-
-List of commands and functions
-------------------------------
-
-The number of commands and convenience functions may evolve over the time,
-this is just a snapshot of the initial version::
-
- (gdb) apropos lx
- function lx_current -- Return current task
- function lx_module -- Find module by name and return the module variable
- function lx_per_cpu -- Return per-cpu variable
- function lx_task_by_pid -- Find Linux task by PID and return the task_struct variable
- function lx_thread_info -- Calculate Linux thread_info from task variable
- lx-dmesg -- Print Linux kernel log buffer
- lx-lsmod -- List currently loaded modules
- lx-symbols -- (Re-)load symbols of Linux kernel and currently loaded modules
-
-Detailed help can be obtained via "help <command-name>" for commands and "help
-function <function-name>" for convenience functions.
diff --git a/Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst b/Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst
new file mode 100644
index 000000000000..d69f24c0d9e1
--- /dev/null
+++ b/Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst
@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================================
+Linux Kernel GPIO based sloppy logic analyzer
+=============================================
+
+:Author: Wolfram Sang
+
+Introduction
+============
+
+This document briefly describes how to run the GPIO based in-kernel sloppy
+logic analyzer running on an isolated CPU.
+
+The sloppy logic analyzer will utilize a few GPIO lines in input mode on a
+system to rapidly sample these digital lines, which will, if the Nyquist
+criteria is met, result in a time series log with approximate waveforms as they
+appeared on these lines. One way to use it is to analyze external traffic
+connected to these GPIO lines with wires (i.e. digital probes), acting as a
+common logic analyzer.
+
+Another feature is to snoop on on-chip peripherals if the I/O cells of these
+peripherals can be used in GPIO input mode at the same time as they are being
+used as inputs or outputs for the peripheral. That means you could e.g. snoop
+I2C traffic without any wiring (if your hardware supports it). In the pin
+control subsystem such pin controllers are called "non-strict": a certain pin
+can be used with a certain peripheral and as a GPIO input line at the same
+time.
+
+Note that this is a last resort analyzer which can be affected by latencies,
+non-deterministic code paths and non-maskable interrupts. It is called 'sloppy'
+for a reason. However, for e.g. remote development, it may be useful to get a
+first view and aid further debugging.
+
+Setup
+=====
+
+Your kernel must have CONFIG_DEBUG_FS and CONFIG_CPUSETS enabled. Ideally, your
+runtime environment does not utilize cpusets otherwise, then isolation of a CPU
+core is easiest. If you do need cpusets, check that helper script for the
+sloppy logic analyzer does not interfere with your other settings.
+
+Tell the kernel which GPIOs are used as probes. For a Device Tree based system,
+you need to use the following bindings. Because these bindings are only for
+debugging, there is no official schema::
+
+ i2c-analyzer {
+ compatible = "gpio-sloppy-logic-analyzer";
+ probe-gpios = <&gpio6 21 GPIO_OPEN_DRAIN>, <&gpio6 4 GPIO_OPEN_DRAIN>;
+ probe-names = "SCL", "SDA";
+ };
+
+Note that you must provide a name for every GPIO specified. Currently a
+maximum of 8 probes are supported. 32 are likely possible but are not
+implemented yet.
+
+Usage
+=====
+
+The logic analyzer is configurable via files in debugfs. However, it is
+strongly recommended to not use them directly, but to use the script
+``tools/gpio/gpio-sloppy-logic-analyzer``. Besides checking parameters more
+extensively, it will isolate the CPU core so you will have the least
+disturbance while measuring.
+
+The script has a help option explaining the parameters. For the above DT
+snippet which analyzes an I2C bus at 400kHz on a Renesas Salvator-XS board, the
+following settings are used: The isolated CPU shall be CPU1 because it is a big
+core in a big.LITTLE setup. Because CPU1 is the default, we don't need a
+parameter. The bus speed is 400kHz. So, the sampling theorem says we need to
+sample at least at 800kHz. However, falling edges of both signals in an I2C
+start condition happen faster, so we need a higher sampling frequency, e.g.
+``-s 1500000`` for 1.5MHz. Also, we don't want to sample right away but wait
+for a start condition on an idle bus. So, we need to set a trigger to a falling
+edge on SDA while SCL stays high, i.e. ``-t 1H+2F``. Last is the duration, let
+us assume 15ms here which results in the parameter ``-d 15000``. So,
+altogether::
+
+ gpio-sloppy-logic-analyzer -s 1500000 -t 1H+2F -d 15000
+
+Note that the process will return you back to the prompt but a sub-process is
+still sampling in the background. Unless this has finished, you will not find a
+result file in the current or specified directory. For the above example, we
+will then need to trigger I2C communication::
+
+ i2cdetect -y -r <your bus number>
+
+Result is a .sr file to be consumed with PulseView or sigrok-cli from the free
+`sigrok`_ project. It is a zip file which also contains the binary sample data
+which may be consumed by other software. The filename is the logic analyzer
+instance name plus a since-epoch timestamp.
+
+.. _sigrok: https://sigrok.org/
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
index 4621eac290f4..4b8425e348ab 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -10,29 +10,34 @@ whole; patches welcome!
A brief overview of testing-specific tools can be found in
Documentation/dev-tools/testing-overview.rst
-.. class:: toc-title
-
- Table of contents
+Tools that are specific to debugging can be found in
+Documentation/process/debugging/index.rst
.. toctree::
+ :caption: Table of contents
:maxdepth: 2
testing-overview
checkpatch
+ clang-format
coccinelle
sparse
kcov
gcov
kasan
+ kmsan
ubsan
kmemleak
kcsan
+ lkmm/index
kfence
- gdb-kernel-debugging
- kgdb
kselftest
kunit/index
ktap
+ checkuapi
+ gpio-sloppy-logic-analyzer
+ autofdo
+ propeller
.. only:: subproject and html
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index 1772fd457fed..a034700da7c4 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -1,5 +1,8 @@
-The Kernel Address Sanitizer (KASAN)
-====================================
+.. SPDX-License-Identifier: GPL-2.0
+.. Copyright (C) 2023, Google LLC.
+
+Kernel Address Sanitizer (KASAN)
+================================
Overview
--------
@@ -41,8 +44,8 @@ Support
Architectures
~~~~~~~~~~~~~
-Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, and
-xtensa, and the tag-based KASAN modes are supported only on arm64.
+Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, xtensa,
+and loongarch, and the tag-based KASAN modes are supported only on arm64.
Compilers
~~~~~~~~~
@@ -107,13 +110,24 @@ effectively disables ``panic_on_warn`` for KASAN reports.
Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot
parameter can be used to control panic and reporting behaviour:
-- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
- report or also panic the kernel (default: ``report``). The panic happens even
- if ``kasan_multi_shot`` is enabled.
+- ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether
+ to only print a KASAN report, panic the kernel, or panic the kernel on
+ invalid writes only (default: ``report``). The panic happens even if
+ ``kasan_multi_shot`` is enabled. Note that when using asynchronous mode of
+ Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always panics on
+ asynchronously checked accesses (including reads).
+
+Software and Hardware Tag-Based KASAN modes (see the section about various
+modes below) support altering stack trace collection behavior:
+
+- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
+ traces collection (default: ``on``).
+- ``kasan.stack_ring_size=<number of entries>`` specifies the number of entries
+ in the stack ring (default: ``32768``).
-Hardware Tag-Based KASAN mode (see the section about various modes below) is
-intended for use in production as a security mitigation. Therefore, it supports
-additional boot parameters that allow disabling KASAN or controlling features:
+Hardware Tag-Based KASAN mode is intended for use in production as a security
+mitigation. Therefore, it supports additional boot parameters that allow
+disabling KASAN altogether or controlling its features:
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
@@ -129,11 +143,28 @@ additional boot parameters that allow disabling KASAN or controlling features:
Asymmetric mode: a bad access is detected synchronously on reads and
asynchronously on writes.
+- ``kasan.write_only=off`` or ``kasan.write_only=on`` controls whether KASAN
+ checks the write (store) accesses only or all accesses (default: ``off``).
+
- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc
allocations (default: ``on``).
-- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
- traces collection (default: ``on``).
+- ``kasan.page_alloc.sample=<sampling interval>`` makes KASAN tag only every
+ Nth page_alloc allocation with the order equal or greater than
+ ``kasan.page_alloc.sample.order``, where N is the value of the ``sample``
+ parameter (default: ``1``, or tag every such allocation).
+ This parameter is intended to mitigate the performance overhead introduced
+ by KASAN.
+ Note that enabling this parameter makes Hardware Tag-Based KASAN skip checks
+ of allocations chosen by sampling and thus miss bad accesses to these
+ allocations. Use the default value for accurate bug detection.
+
+- ``kasan.page_alloc.sample.order=<minimum page order>`` specifies the minimum
+ order of allocations that are affected by sampling (default: ``3``).
+ Only applies when ``kasan.page_alloc.sample`` is set to a value greater
+ than ``1``.
+ This parameter is intended to allow sampling only large page_alloc
+ allocations, which is the biggest source of the performance overhead.
Error reports
~~~~~~~~~~~~~
@@ -141,7 +172,7 @@ Error reports
A typical KASAN report looks like this::
==================================================================
- BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
+ BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [kasan_test]
Write of size 1 at addr ffff8801f44ec37b by task insmod/2760
CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698
@@ -151,8 +182,8 @@ A typical KASAN report looks like this::
print_address_description+0x73/0x280
kasan_report+0x144/0x187
__asan_report_store1_noabort+0x17/0x20
- kmalloc_oob_right+0xa8/0xbc [test_kasan]
- kmalloc_tests_init+0x16/0x700 [test_kasan]
+ kmalloc_oob_right+0xa8/0xbc [kasan_test]
+ kmalloc_tests_init+0x16/0x700 [kasan_test]
do_one_initcall+0xa5/0x3ae
do_init_module+0x1b6/0x547
load_module+0x75df/0x8070
@@ -172,8 +203,8 @@ A typical KASAN report looks like this::
save_stack+0x43/0xd0
kasan_kmalloc+0xa7/0xd0
kmem_cache_alloc_trace+0xe1/0x1b0
- kmalloc_oob_right+0x56/0xbc [test_kasan]
- kmalloc_tests_init+0x16/0x700 [test_kasan]
+ kmalloc_oob_right+0x56/0xbc [kasan_test]
+ kmalloc_tests_init+0x16/0x700 [kasan_test]
do_one_initcall+0xa5/0x3ae
do_init_module+0x1b6/0x547
load_module+0x75df/0x8070
@@ -249,6 +280,27 @@ traces point to places in code that interacted with the object but that are not
directly present in the bad access stack trace. Currently, this includes
call_rcu() and workqueue queuing.
+CONFIG_KASAN_EXTRA_INFO
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Enabling CONFIG_KASAN_EXTRA_INFO allows KASAN to record and report more
+information. The extra information currently supported is the CPU number and
+timestamp at allocation and free. More information can help find the cause of
+the bug and correlate the error with other system events, at the cost of using
+extra memory to record more information (more cost details in the help text of
+CONFIG_KASAN_EXTRA_INFO).
+
+Here is the report with CONFIG_KASAN_EXTRA_INFO enabled (only the
+different parts are shown)::
+
+ ==================================================================
+ ...
+ Allocated by task 134 on cpu 5 at 229.133855s:
+ ...
+ Freed by task 136 on cpu 3 at 230.199335s:
+ ...
+ ==================================================================
+
Implementation details
----------------------
@@ -462,19 +514,14 @@ Tests
~~~~~
There are KASAN tests that allow verifying that KASAN works and can detect
-certain types of memory corruptions. The tests consist of two parts:
+certain types of memory corruptions.
-1. Tests that are integrated with the KUnit Test Framework. Enabled with
-``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
+All KASAN tests are integrated with the KUnit Test Framework and can be enabled
+via ``CONFIG_KASAN_KUNIT_TEST``. The tests can be run and partially verified
automatically in a few different ways; see the instructions below.
-2. Tests that are currently incompatible with KUnit. Enabled with
-``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can
-only be verified manually by loading the kernel module and inspecting the
-kernel log for KASAN reports.
-
-Each KUnit-compatible KASAN test prints one of multiple KASAN reports if an
-error is detected. Then the test prints its number and status.
+Each KASAN test prints one of multiple KASAN reports if an error is detected.
+Then the test prints its number and status.
When a test passes::
@@ -482,15 +529,15 @@ When a test passes::
When a test fails due to a failed ``kmalloc``::
- # kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163
+ # kmalloc_large_oob_right: ASSERTION FAILED at mm/kasan/kasan_test.c:245
Expected ptr is not null, but is
- not ok 4 - kmalloc_large_oob_right
+ not ok 5 - kmalloc_large_oob_right
When a test fails due to a missing KASAN report::
- # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974
+ # kmalloc_double_kzfree: EXPECTATION FAILED at mm/kasan/kasan_test.c:709
KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
- not ok 44 - kmalloc_double_kzfree
+ not ok 28 - kmalloc_double_kzfree
At the end the cumulative status of all KASAN tests is printed. On success::
@@ -501,16 +548,16 @@ Or, if one of the tests failed::
not ok 1 - kasan
-There are a few ways to run KUnit-compatible KASAN tests.
+There are a few ways to run the KASAN tests.
1. Loadable module
- With ``CONFIG_KUNIT`` enabled, KASAN-KUnit tests can be built as a loadable
- module and run by loading ``test_kasan.ko`` with ``insmod`` or ``modprobe``.
+ With ``CONFIG_KUNIT`` enabled, the tests can be built as a loadable module
+ and run by loading ``kasan_test.ko`` with ``insmod`` or ``modprobe``.
2. Built-In
- With ``CONFIG_KUNIT`` built-in, KASAN-KUnit tests can be built-in as well.
+ With ``CONFIG_KUNIT`` built-in, the tests can be built-in as well.
In this case, the tests will run at boot as a late-init call.
3. Using kunit_tool
diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst
index d83c9ab49427..8127849d40f5 100644
--- a/Documentation/dev-tools/kcov.rst
+++ b/Documentation/dev-tools/kcov.rst
@@ -1,42 +1,50 @@
-kcov: code coverage for fuzzing
+KCOV: code coverage for fuzzing
===============================
-kcov exposes kernel code coverage information in a form suitable for coverage-
-guided fuzzing (randomized testing). Coverage data of a running kernel is
-exported via the "kcov" debugfs file. Coverage collection is enabled on a task
-basis, and thus it can capture precise coverage of a single system call.
+KCOV collects and exposes kernel code coverage information in a form suitable
+for coverage-guided fuzzing. Coverage data of a running kernel is exported via
+the ``kcov`` debugfs file. Coverage collection is enabled on a task basis, and
+thus KCOV can capture precise coverage of a single system call.
-Note that kcov does not aim to collect as much coverage as possible. It aims
-to collect more or less stable coverage that is function of syscall inputs.
-To achieve this goal it does not collect coverage in soft/hard interrupts
-and instrumentation of some inherently non-deterministic parts of kernel is
-disabled (e.g. scheduler, locking).
+Note that KCOV does not aim to collect as much coverage as possible. It aims
+to collect more or less stable coverage that is a function of syscall inputs.
+To achieve this goal, it does not collect coverage in soft/hard interrupts
+(unless remove coverage collection is enabled, see below) and from some
+inherently non-deterministic parts of the kernel (e.g. scheduler, locking).
-kcov is also able to collect comparison operands from the instrumented code
-(this feature currently requires that the kernel is compiled with clang).
+Besides collecting code coverage, KCOV can also collect comparison operands.
+See the "Comparison operands collection" section for details.
+
+Besides collecting coverage data from syscall handlers, KCOV can also collect
+coverage for annotated parts of the kernel executing in background kernel
+tasks or soft interrupts. See the "Remote coverage collection" section for
+details.
Prerequisites
-------------
-Configure the kernel with::
+KCOV relies on compiler instrumentation and requires GCC 6.1.0 or later
+or any Clang version supported by the kernel.
- CONFIG_KCOV=y
+Collecting comparison operands is supported with GCC 8+ or with Clang.
-CONFIG_KCOV requires gcc 6.1.0 or later.
+To enable KCOV, configure the kernel with::
-If the comparison operands need to be collected, set::
+ CONFIG_KCOV=y
+
+To enable comparison operands collection, set::
CONFIG_KCOV_ENABLE_COMPARISONS=y
-Profiling data will only become accessible once debugfs has been mounted::
+Coverage data only becomes accessible once debugfs has been mounted::
mount -t debugfs none /sys/kernel/debug
Coverage collection
-------------------
-The following program demonstrates coverage collection from within a test
-program using kcov:
+The following program demonstrates how to use KCOV to collect coverage for a
+single syscall from within a test program:
.. code-block:: c
@@ -84,7 +92,7 @@ program using kcov:
perror("ioctl"), exit(1);
/* Reset coverage from the tail of the ioctl() call. */
__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
- /* That's the target syscal call. */
+ /* Call the target syscall call. */
read(-1, NULL, 0);
/* Read number of PCs collected. */
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
@@ -103,7 +111,7 @@ program using kcov:
return 0;
}
-After piping through addr2line output of the program looks as follows::
+After piping through ``addr2line`` the output of the program looks as follows::
SyS_read
fs/read_write.c:562
@@ -121,12 +129,13 @@ After piping through addr2line output of the program looks as follows::
fs/read_write.c:562
If a program needs to collect coverage from several threads (independently),
-it needs to open /sys/kernel/debug/kcov in each thread separately.
+it needs to open ``/sys/kernel/debug/kcov`` in each thread separately.
The interface is fine-grained to allow efficient forking of test processes.
-That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode,
-mmaps coverage buffer and then forks child processes in a loop. Child processes
-only need to enable coverage (disable happens automatically on thread end).
+That is, a parent process opens ``/sys/kernel/debug/kcov``, enables trace mode,
+mmaps coverage buffer, and then forks child processes in a loop. The child
+processes only need to enable coverage (it gets disabled automatically when
+a thread exits).
Comparison operands collection
------------------------------
@@ -205,52 +214,78 @@ Comparison operands collection is similar to coverage collection:
return 0;
}
-Note that the kcov modes (coverage collection or comparison operands) are
-mutually exclusive.
+Note that the KCOV modes (collection of code coverage or comparison operands)
+are mutually exclusive.
Remote coverage collection
--------------------------
-With KCOV_ENABLE coverage is collected only for syscalls that are issued
-from the current process. With KCOV_REMOTE_ENABLE it's possible to collect
-coverage for arbitrary parts of the kernel code, provided that those parts
-are annotated with kcov_remote_start()/kcov_remote_stop().
-
-This allows to collect coverage from two types of kernel background
-threads: the global ones, that are spawned during kernel boot in a limited
-number of instances (e.g. one USB hub_event() worker thread is spawned per
-USB HCD); and the local ones, that are spawned when a user interacts with
-some kernel interface (e.g. vhost workers); as well as from soft
-interrupts.
-
-To enable collecting coverage from a global background thread or from a
-softirq, a unique global handle must be assigned and passed to the
-corresponding kcov_remote_start() call. Then a userspace process can pass
-a list of such handles to the KCOV_REMOTE_ENABLE ioctl in the handles
-array field of the kcov_remote_arg struct. This will attach the used kcov
-device to the code sections, that are referenced by those handles.
-
-Since there might be many local background threads spawned from different
-userspace processes, we can't use a single global handle per annotation.
-Instead, the userspace process passes a non-zero handle through the
-common_handle field of the kcov_remote_arg struct. This common handle gets
-saved to the kcov_handle field in the current task_struct and needs to be
-passed to the newly spawned threads via custom annotations. Those threads
-should in turn be annotated with kcov_remote_start()/kcov_remote_stop().
-
-Internally kcov stores handles as u64 integers. The top byte of a handle
-is used to denote the id of a subsystem that this handle belongs to, and
-the lower 4 bytes are used to denote the id of a thread instance within
-that subsystem. A reserved value 0 is used as a subsystem id for common
-handles as they don't belong to a particular subsystem. The bytes 4-7 are
-currently reserved and must be zero. In the future the number of bytes
-used for the subsystem or handle ids might be increased.
-
-When a particular userspace process collects coverage via a common
-handle, kcov will collect coverage for each code section that is annotated
-to use the common handle obtained as kcov_handle from the current
-task_struct. However non common handles allow to collect coverage
-selectively from different subsystems.
+Besides collecting coverage data from handlers of syscalls issued from a
+userspace process, KCOV can also collect coverage for parts of the kernel
+executing in other contexts - so-called "remote" coverage.
+
+Using KCOV to collect remote coverage requires:
+
+1. Modifying kernel code to annotate the code section from where coverage
+ should be collected with ``kcov_remote_start`` and ``kcov_remote_stop``.
+
+2. Using ``KCOV_REMOTE_ENABLE`` instead of ``KCOV_ENABLE`` in the userspace
+ process that collects coverage.
+
+Both ``kcov_remote_start`` and ``kcov_remote_stop`` annotations and the
+``KCOV_REMOTE_ENABLE`` ioctl accept handles that identify particular coverage
+collection sections. The way a handle is used depends on the context where the
+matching code section executes.
+
+KCOV supports collecting remote coverage from the following contexts:
+
+1. Global kernel background tasks. These are the tasks that are spawned during
+ kernel boot in a limited number of instances (e.g. one USB ``hub_event``
+ worker is spawned per one USB HCD).
+
+2. Local kernel background tasks. These are spawned when a userspace process
+ interacts with some kernel interface and are usually killed when the process
+ exits (e.g. vhost workers).
+
+3. Soft interrupts.
+
+For #1 and #3, a unique global handle must be chosen and passed to the
+corresponding ``kcov_remote_start`` call. Then a userspace process must pass
+this handle to ``KCOV_REMOTE_ENABLE`` in the ``handles`` array field of the
+``kcov_remote_arg`` struct. This will attach the used KCOV device to the code
+section referenced by this handle. Multiple global handles identifying
+different code sections can be passed at once.
+
+For #2, the userspace process instead must pass a non-zero handle through the
+``common_handle`` field of the ``kcov_remote_arg`` struct. This common handle
+gets saved to the ``kcov_handle`` field in the current ``task_struct`` and
+needs to be passed to the newly spawned local tasks via custom kernel code
+modifications. Those tasks should in turn use the passed handle in their
+``kcov_remote_start`` and ``kcov_remote_stop`` annotations.
+
+KCOV follows a predefined format for both global and common handles. Each
+handle is a ``u64`` integer. Currently, only the one top and the lower 4 bytes
+are used. Bytes 4-7 are reserved and must be zero.
+
+For global handles, the top byte of the handle denotes the id of a subsystem
+this handle belongs to. For example, KCOV uses ``1`` as the USB subsystem id.
+The lower 4 bytes of a global handle denote the id of a task instance within
+that subsystem. For example, each ``hub_event`` worker uses the USB bus number
+as the task instance id.
+
+For common handles, a reserved value ``0`` is used as a subsystem id, as such
+handles don't belong to a particular subsystem. The lower 4 bytes of a common
+handle identify a collective instance of all local tasks spawned by the
+userspace process that passed a common handle to ``KCOV_REMOTE_ENABLE``.
+
+In practice, any value can be used for common handle instance id if coverage
+is only collected from a single userspace process on the system. However, if
+common handles are used by multiple processes, unique instance ids must be
+used for each process. One option is to use the process id as the common
+handle instance id.
+
+The following program demonstrates using KCOV to collect coverage from both
+local tasks spawned by the process and the global task that handles USB bus #1:
.. code-block:: c
@@ -326,7 +361,12 @@ selectively from different subsystems.
*/
sleep(2);
- n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
+ /*
+ * The load to the coverage count should be an acquire to pair with
+ * pair with the corresponding write memory barrier (smp_wmb()) on
+ * the kernel-side in kcov_move_area().
+ */
+ n = __atomic_load_n(&cover[0], __ATOMIC_ACQUIRE);
for (i = 0; i < n; i++)
printf("0x%lx\n", cover[i + 1]);
if (ioctl(fd, KCOV_DISABLE, 0))
diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst
index 3ae866dcc924..8575178aa87f 100644
--- a/Documentation/dev-tools/kcsan.rst
+++ b/Documentation/dev-tools/kcsan.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2019, Google LLC.
-The Kernel Concurrency Sanitizer (KCSAN)
-========================================
+Kernel Concurrency Sanitizer (KCSAN)
+====================================
The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which
relies on compile-time instrumentation, and uses a watchpoint-based sampling
@@ -91,6 +91,16 @@ the below options are available:
behaviour when encountering a data race is deemed safe. Please see
`"Marking Shared-Memory Accesses" in the LKMM`_ for more information.
+* Similar to ``data_race(...)``, the type qualifier ``__data_racy`` can be used
+ to document that all data races due to accesses to a variable are intended
+ and should be ignored by KCSAN::
+
+ struct foo {
+ ...
+ int __data_racy stats_counter;
+ ...
+ };
+
* Disabling data race detection for entire functions can be accomplished by
using the function attribute ``__no_kcsan``::
@@ -193,7 +203,7 @@ they happen concurrently in different threads, and at least one of them is a
least one is a write. For a more thorough discussion and definition, see `"Plain
Accesses and Data Races" in the LKMM`_.
-.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt#n1922
+.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt?id=8f6629c004b193d23612641c3607e785819e97ab#n2164
Relationship with the Linux-Kernel Memory Consistency Model (LKMM)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -351,7 +361,8 @@ Alternatives Considered
-----------------------
An alternative data race detection approach for the kernel can be found in the
-`Kernel Thread Sanitizer (KTSAN) <https://github.com/google/ktsan/wiki>`_.
+`Kernel Thread Sanitizer (KTSAN)
+<https://github.com/google/kernel-sanitizers/blob/master/KTSAN.md>`_.
KTSAN is a happens-before data race detector, which explicitly establishes the
happens-before order between memory operations, which can then be used to
determine data races as defined in `Data Races`_.
diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst
index 936f6aaa75c8..541899353865 100644
--- a/Documentation/dev-tools/kfence.rst
+++ b/Documentation/dev-tools/kfence.rst
@@ -53,6 +53,13 @@ configurable via the Kconfig option ``CONFIG_KFENCE_DEFERRABLE``.
The KUnit test suite is very likely to fail when using a deferrable timer
since it currently causes very unpredictable sample intervals.
+By default KFENCE will only sample 1 heap allocation within each sample
+interval. *Burst mode* allows to sample successive heap allocations, where the
+kernel boot parameter ``kfence.burst`` can be set to a non-zero value which
+denotes the *additional* successive allocations within a sample interval;
+setting ``kfence.burst=N`` means that ``1 + N`` successive allocations are
+attempted through KFENCE for each sample interval.
+
The KFENCE memory pool is of fixed size, and if the pool is exhausted, no
further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default
255), the number of available guarded objects can be controlled. Each object
diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst
index 5483fd39ef29..7d784e03f3f9 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -161,6 +161,7 @@ See the include/linux/kmemleak.h header for the functions prototype.
- ``kmemleak_free_percpu`` - notify of a percpu memory block freeing
- ``kmemleak_update_trace`` - update object allocation stack trace
- ``kmemleak_not_leak`` - mark an object as not a leak
+- ``kmemleak_transient_leak`` - mark an object as a transient leak
- ``kmemleak_ignore`` - do not scan or report an object as leak
- ``kmemleak_scan_area`` - add scan areas inside a memory block
- ``kmemleak_no_scan`` - do not scan a memory block
@@ -227,7 +228,7 @@ Testing with kmemleak-test
--------------------------
To check if you have all set up to use kmemleak, you can use the kmemleak-test
-module, a module that deliberately leaks memory. Set CONFIG_DEBUG_KMEMLEAK_TEST
+module, a module that deliberately leaks memory. Set CONFIG_SAMPLE_KMEMLEAK
as module (it can't be used as built-in) and boot the kernel with kmemleak
enabled. Load the module and perform a scan with::
diff --git a/Documentation/dev-tools/kmsan.rst b/Documentation/dev-tools/kmsan.rst
new file mode 100644
index 000000000000..0dc668b183f6
--- /dev/null
+++ b/Documentation/dev-tools/kmsan.rst
@@ -0,0 +1,435 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. Copyright (C) 2022, Google LLC.
+
+===============================
+Kernel Memory Sanitizer (KMSAN)
+===============================
+
+KMSAN is a dynamic error detector aimed at finding uses of uninitialized
+values. It is based on compiler instrumentation, and is quite similar to the
+userspace `MemorySanitizer tool`_.
+
+An important note is that KMSAN is not intended for production use, because it
+drastically increases kernel memory footprint and slows the whole system down.
+
+Usage
+=====
+
+Building the kernel
+-------------------
+
+In order to build a kernel with KMSAN you will need a fresh Clang (14.0.6+).
+Please refer to `LLVM documentation`_ for the instructions on how to build Clang.
+
+Now configure and build the kernel with CONFIG_KMSAN enabled.
+
+Example report
+--------------
+
+Here is an example of a KMSAN report::
+
+ =====================================================
+ BUG: KMSAN: uninit-value in test_uninit_kmsan_check_memory+0x1be/0x380 [kmsan_test]
+ test_uninit_kmsan_check_memory+0x1be/0x380 mm/kmsan/kmsan_test.c:273
+ kunit_run_case_internal lib/kunit/test.c:333
+ kunit_try_run_case+0x206/0x420 lib/kunit/test.c:374
+ kunit_generic_run_threadfn_adapter+0x6d/0xc0 lib/kunit/try-catch.c:28
+ kthread+0x721/0x850 kernel/kthread.c:327
+ ret_from_fork+0x1f/0x30 ??:?
+
+ Uninit was stored to memory at:
+ do_uninit_local_array+0xfa/0x110 mm/kmsan/kmsan_test.c:260
+ test_uninit_kmsan_check_memory+0x1a2/0x380 mm/kmsan/kmsan_test.c:271
+ kunit_run_case_internal lib/kunit/test.c:333
+ kunit_try_run_case+0x206/0x420 lib/kunit/test.c:374
+ kunit_generic_run_threadfn_adapter+0x6d/0xc0 lib/kunit/try-catch.c:28
+ kthread+0x721/0x850 kernel/kthread.c:327
+ ret_from_fork+0x1f/0x30 ??:?
+
+ Local variable uninit created at:
+ do_uninit_local_array+0x4a/0x110 mm/kmsan/kmsan_test.c:256
+ test_uninit_kmsan_check_memory+0x1a2/0x380 mm/kmsan/kmsan_test.c:271
+
+ Bytes 4-7 of 8 are uninitialized
+ Memory access of size 8 starts at ffff888083fe3da0
+
+ CPU: 0 PID: 6731 Comm: kunit_try_catch Tainted: G B E 5.16.0-rc3+ #104
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
+ =====================================================
+
+The report says that the local variable ``uninit`` was created uninitialized in
+``do_uninit_local_array()``. The third stack trace corresponds to the place
+where this variable was created.
+
+The first stack trace shows where the uninit value was used (in
+``test_uninit_kmsan_check_memory()``). The tool shows the bytes which were left
+uninitialized in the local variable, as well as the stack where the value was
+copied to another memory location before use.
+
+A use of uninitialized value ``v`` is reported by KMSAN in the following cases:
+
+ - in a condition, e.g. ``if (v) { ... }``;
+ - in an indexing or pointer dereferencing, e.g. ``array[v]`` or ``*v``;
+ - when it is copied to userspace or hardware, e.g. ``copy_to_user(..., &v, ...)``;
+ - when it is passed as an argument to a function, and
+ ``CONFIG_KMSAN_CHECK_PARAM_RETVAL`` is enabled (see below).
+
+The mentioned cases (apart from copying data to userspace or hardware, which is
+a security issue) are considered undefined behavior from the C11 Standard point
+of view.
+
+Disabling the instrumentation
+-----------------------------
+
+A function can be marked with ``__no_kmsan_checks``. Doing so makes KMSAN
+ignore uninitialized values in that function and mark its output as initialized.
+As a result, the user will not get KMSAN reports related to that function.
+
+Another function attribute supported by KMSAN is ``__no_sanitize_memory``.
+Applying this attribute to a function will result in KMSAN not instrumenting
+it, which can be helpful if we do not want the compiler to interfere with some
+low-level code (e.g. that marked with ``noinstr`` which implicitly adds
+``__no_sanitize_memory``).
+
+This however comes at a cost: stack allocations from such functions will have
+incorrect shadow/origin values, likely leading to false positives. Functions
+called from non-instrumented code may also receive incorrect metadata for their
+parameters.
+
+As a rule of thumb, avoid using ``__no_sanitize_memory`` explicitly.
+
+It is also possible to disable KMSAN for a single file (e.g. main.o)::
+
+ KMSAN_SANITIZE_main.o := n
+
+or for the whole directory::
+
+ KMSAN_SANITIZE := n
+
+in the Makefile. Think of this as applying ``__no_sanitize_memory`` to every
+function in the file or directory. Most users won't need KMSAN_SANITIZE, unless
+their code gets broken by KMSAN (e.g. runs at early boot time).
+
+KMSAN checks can also be temporarily disabled for the current task using
+``kmsan_disable_current()`` and ``kmsan_enable_current()`` calls. Each
+``kmsan_enable_current()`` call must be preceded by a
+``kmsan_disable_current()`` call; these call pairs may be nested. One needs to
+be careful with these calls, keeping the regions short and preferring other
+ways to disable instrumentation, where possible.
+
+Support
+=======
+
+In order for KMSAN to work the kernel must be built with Clang, which so far is
+the only compiler that has KMSAN support. The kernel instrumentation pass is
+based on the userspace `MemorySanitizer tool`_.
+
+The runtime library only supports x86_64 at the moment.
+
+How KMSAN works
+===============
+
+KMSAN shadow memory
+-------------------
+
+KMSAN associates a metadata byte (also called shadow byte) with every byte of
+kernel memory. A bit in the shadow byte is set if the corresponding bit of the
+kernel memory byte is uninitialized. Marking the memory uninitialized (i.e.
+setting its shadow bytes to ``0xff``) is called poisoning, marking it
+initialized (setting the shadow bytes to ``0x00``) is called unpoisoning.
+
+When a new variable is allocated on the stack, it is poisoned by default by
+instrumentation code inserted by the compiler (unless it is a stack variable
+that is immediately initialized). Any new heap allocation done without
+``__GFP_ZERO`` is also poisoned.
+
+Compiler instrumentation also tracks the shadow values as they are used along
+the code. When needed, instrumentation code invokes the runtime library in
+``mm/kmsan/`` to persist shadow values.
+
+The shadow value of a basic or compound type is an array of bytes of the same
+length. When a constant value is written into memory, that memory is unpoisoned.
+When a value is read from memory, its shadow memory is also obtained and
+propagated into all the operations which use that value. For every instruction
+that takes one or more values the compiler generates code that calculates the
+shadow of the result depending on those values and their shadows.
+
+Example::
+
+ int a = 0xff; // i.e. 0x000000ff
+ int b;
+ int c = a | b;
+
+In this case the shadow of ``a`` is ``0``, shadow of ``b`` is ``0xffffffff``,
+shadow of ``c`` is ``0xffffff00``. This means that the upper three bytes of
+``c`` are uninitialized, while the lower byte is initialized.
+
+Origin tracking
+---------------
+
+Every four bytes of kernel memory also have a so-called origin mapped to them.
+This origin describes the point in program execution at which the uninitialized
+value was created. Every origin is associated with either the full allocation
+stack (for heap-allocated memory), or the function containing the uninitialized
+variable (for locals).
+
+When an uninitialized variable is allocated on stack or heap, a new origin
+value is created, and that variable's origin is filled with that value. When a
+value is read from memory, its origin is also read and kept together with the
+shadow. For every instruction that takes one or more values, the origin of the
+result is one of the origins corresponding to any of the uninitialized inputs.
+If a poisoned value is written into memory, its origin is written to the
+corresponding storage as well.
+
+Example 1::
+
+ int a = 42;
+ int b;
+ int c = a + b;
+
+In this case the origin of ``b`` is generated upon function entry, and is
+stored to the origin of ``c`` right before the addition result is written into
+memory.
+
+Several variables may share the same origin address, if they are stored in the
+same four-byte chunk. In this case every write to either variable updates the
+origin for all of them. We have to sacrifice precision in this case, because
+storing origins for individual bits (and even bytes) would be too costly.
+
+Example 2::
+
+ int combine(short a, short b) {
+ union ret_t {
+ int i;
+ short s[2];
+ } ret;
+ ret.s[0] = a;
+ ret.s[1] = b;
+ return ret.i;
+ }
+
+If ``a`` is initialized and ``b`` is not, the shadow of the result would be
+0xffff0000, and the origin of the result would be the origin of ``b``.
+``ret.s[0]`` would have the same origin, but it will never be used, because
+that variable is initialized.
+
+If both function arguments are uninitialized, only the origin of the second
+argument is preserved.
+
+Origin chaining
+~~~~~~~~~~~~~~~
+
+To ease debugging, KMSAN creates a new origin for every store of an
+uninitialized value to memory. The new origin references both its creation stack
+and the previous origin the value had. This may cause increased memory
+consumption, so we limit the length of origin chains in the runtime.
+
+Clang instrumentation API
+-------------------------
+
+Clang instrumentation pass inserts calls to functions defined in
+``mm/kmsan/nstrumentation.c`` into the kernel code.
+
+Shadow manipulation
+~~~~~~~~~~~~~~~~~~~
+
+For every memory access the compiler emits a call to a function that returns a
+pair of pointers to the shadow and origin addresses of the given memory::
+
+ typedef struct {
+ void *shadow, *origin;
+ } shadow_origin_ptr_t
+
+ shadow_origin_ptr_t __msan_metadata_ptr_for_load_{1,2,4,8}(void *addr)
+ shadow_origin_ptr_t __msan_metadata_ptr_for_store_{1,2,4,8}(void *addr)
+ shadow_origin_ptr_t __msan_metadata_ptr_for_load_n(void *addr, uintptr_t size)
+ shadow_origin_ptr_t __msan_metadata_ptr_for_store_n(void *addr, uintptr_t size)
+
+The function name depends on the memory access size.
+
+The compiler makes sure that for every loaded value its shadow and origin
+values are read from memory. When a value is stored to memory, its shadow and
+origin are also stored using the metadata pointers.
+
+Handling locals
+~~~~~~~~~~~~~~~
+
+A special function is used to create a new origin value for a local variable and
+set the origin of that variable to that value::
+
+ void __msan_poison_alloca(void *addr, uintptr_t size, char *descr)
+
+Access to per-task data
+~~~~~~~~~~~~~~~~~~~~~~~
+
+At the beginning of every instrumented function KMSAN inserts a call to
+``__msan_get_context_state()``::
+
+ kmsan_context_state *__msan_get_context_state(void)
+
+``kmsan_context_state`` is declared in ``include/linux/kmsan.h``::
+
+ struct kmsan_context_state {
+ char param_tls[KMSAN_PARAM_SIZE];
+ char retval_tls[KMSAN_RETVAL_SIZE];
+ char va_arg_tls[KMSAN_PARAM_SIZE];
+ char va_arg_origin_tls[KMSAN_PARAM_SIZE];
+ u64 va_arg_overflow_size_tls;
+ char param_origin_tls[KMSAN_PARAM_SIZE];
+ depot_stack_handle_t retval_origin_tls;
+ };
+
+This structure is used by KMSAN to pass parameter shadows and origins between
+instrumented functions (unless the parameters are checked immediately by
+``CONFIG_KMSAN_CHECK_PARAM_RETVAL``).
+
+Passing uninitialized values to functions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Clang's MemorySanitizer instrumentation has an option,
+``-fsanitize-memory-param-retval``, which makes the compiler check function
+parameters passed by value, as well as function return values.
+
+The option is controlled by ``CONFIG_KMSAN_CHECK_PARAM_RETVAL``, which is
+enabled by default to let KMSAN report uninitialized values earlier.
+Please refer to the `LKML discussion`_ for more details.
+
+Because of the way the checks are implemented in LLVM (they are only applied to
+parameters marked as ``noundef``), not all parameters are guaranteed to be
+checked, so we cannot give up the metadata storage in ``kmsan_context_state``.
+
+String functions
+~~~~~~~~~~~~~~~~
+
+The compiler replaces calls to ``memcpy()``/``memmove()``/``memset()`` with the
+following functions. These functions are also called when data structures are
+initialized or copied, making sure shadow and origin values are copied alongside
+with the data::
+
+ void *__msan_memcpy(void *dst, void *src, uintptr_t n)
+ void *__msan_memmove(void *dst, void *src, uintptr_t n)
+ void *__msan_memset(void *dst, int c, uintptr_t n)
+
+Error reporting
+~~~~~~~~~~~~~~~
+
+For each use of a value the compiler emits a shadow check that calls
+``__msan_warning()`` in the case that value is poisoned::
+
+ void __msan_warning(u32 origin)
+
+``__msan_warning()`` causes KMSAN runtime to print an error report.
+
+Inline assembly instrumentation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+KMSAN instruments every inline assembly output with a call to::
+
+ void __msan_instrument_asm_store(void *addr, uintptr_t size)
+
+, which unpoisons the memory region.
+
+This approach may mask certain errors, but it also helps to avoid a lot of
+false positives in bitwise operations, atomics etc.
+
+Sometimes the pointers passed into inline assembly do not point to valid memory.
+In such cases they are ignored at runtime.
+
+
+Runtime library
+---------------
+
+The code is located in ``mm/kmsan/``.
+
+Per-task KMSAN state
+~~~~~~~~~~~~~~~~~~~~
+
+Every task_struct has an associated KMSAN task state that holds the KMSAN
+context (see above) and a per-task counter disallowing KMSAN reports::
+
+ struct kmsan_context {
+ ...
+ unsigned int depth;
+ struct kmsan_context_state cstate;
+ ...
+ }
+
+ struct task_struct {
+ ...
+ struct kmsan_context kmsan;
+ ...
+ }
+
+KMSAN contexts
+~~~~~~~~~~~~~~
+
+When running in a kernel task context, KMSAN uses ``current->kmsan.cstate`` to
+hold the metadata for function parameters and return values.
+
+But in the case the kernel is running in the interrupt, softirq or NMI context,
+where ``current`` is unavailable, KMSAN switches to per-cpu interrupt state::
+
+ DEFINE_PER_CPU(struct kmsan_ctx, kmsan_percpu_ctx);
+
+Metadata allocation
+~~~~~~~~~~~~~~~~~~~
+
+There are several places in the kernel for which the metadata is stored.
+
+1. Each ``struct page`` instance contains two pointers to its shadow and
+origin pages::
+
+ struct page {
+ ...
+ struct page *shadow, *origin;
+ ...
+ };
+
+At boot-time, the kernel allocates shadow and origin pages for every available
+kernel page. This is done quite late, when the kernel address space is already
+fragmented, so normal data pages may arbitrarily interleave with the metadata
+pages.
+
+This means that in general for two contiguous memory pages their shadow/origin
+pages may not be contiguous. Consequently, if a memory access crosses the
+boundary of a memory block, accesses to shadow/origin memory may potentially
+corrupt other pages or read incorrect values from them.
+
+In practice, contiguous memory pages returned by the same ``alloc_pages()``
+call will have contiguous metadata, whereas if these pages belong to two
+different allocations their metadata pages can be fragmented.
+
+For the kernel data (``.data``, ``.bss`` etc.) and percpu memory regions
+there also are no guarantees on metadata contiguity.
+
+In the case ``__msan_metadata_ptr_for_XXX_YYY()`` hits the border between two
+pages with non-contiguous metadata, it returns pointers to fake shadow/origin regions::
+
+ char dummy_load_page[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
+ char dummy_store_page[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
+
+``dummy_load_page`` is zero-initialized, so reads from it always yield zeroes.
+All stores to ``dummy_store_page`` are ignored.
+
+2. For vmalloc memory and modules, there is a direct mapping between the memory
+range, its shadow and origin. KMSAN reduces the vmalloc area by 3/4, making only
+the first quarter available to ``vmalloc()``. The second quarter of the vmalloc
+area contains shadow memory for the first quarter, the third one holds the
+origins. A small part of the fourth quarter contains shadow and origins for the
+kernel modules. Please refer to ``arch/x86/include/asm/pgtable_64_types.h`` for
+more details.
+
+When an array of pages is mapped into a contiguous virtual memory space, their
+shadow and origin pages are similarly mapped into contiguous regions.
+
+References
+==========
+
+E. Stepanov, K. Serebryany. `MemorySanitizer: fast detector of uninitialized
+memory use in C++
+<https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43308.pdf>`_.
+In Proceedings of CGO 2015.
+
+.. _MemorySanitizer tool: https://clang.llvm.org/docs/MemorySanitizer.html
+.. _LLVM documentation: https://llvm.org/docs/GettingStarted.html
+.. _LKML discussion: https://lore.kernel.org/all/20220614144853.3693273-1-glider@google.com/
diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
index 12b575b76b20..18c2da67fae4 100644
--- a/Documentation/dev-tools/kselftest.rst
+++ b/Documentation/dev-tools/kselftest.rst
@@ -31,11 +31,21 @@ kselftest runs as a userspace process. Tests that can be written/run in
userspace may wish to use the `Test Harness`_. Tests that need to be
run in kernel space may wish to use a `Test Module`_.
+Documentation on the tests
+==========================
+
+For documentation on the kselftests themselves, see:
+
+.. toctree::
+
+ testing-devices
+
Running the selftests (hotplug tests are run in limited mode)
=============================================================
To build the tests::
+ $ make headers
$ make -C tools/testing/selftests
To run the tests::
@@ -111,7 +121,7 @@ You can specify multiple tests to skip::
You can also specify a restricted list of tests to run together with a
dedicated skiplist::
- $ make TARGETS="bpf breakpoints size timers" SKIP_TARGETS=bpf kselftest
+ $ make TARGETS="breakpoints size timers" SKIP_TARGETS=size kselftest
See the top-level tools/testing/selftests/Makefile for the list of all
possible targets.
@@ -164,10 +174,32 @@ To see the list of available tests, the `-l` option can be used::
The `-c` option can be used to run all the tests from a test collection, or
the `-t` option for specific single tests. Either can be used multiple times::
- $ ./run_kselftest.sh -c bpf -c seccomp -t timers:posix_timers -t timer:nanosleep
+ $ ./run_kselftest.sh -c size -c seccomp -t timers:posix_timers -t timer:nanosleep
For other features see the script usage output, seen with the `-h` option.
+Timeout for selftests
+=====================
+
+Selftests are designed to be quick and so a default timeout is used of 45
+seconds for each test. Tests can override the default timeout by adding
+a settings file in their directory and set a timeout variable there to the
+configured a desired upper timeout for the test. Only a few tests override
+the timeout with a value higher than 45 seconds, selftests strives to keep
+it that way. Timeouts in selftests are not considered fatal because the
+system under which a test runs may change and this can also modify the
+expected time it takes to run a test. If you have control over the systems
+which will run the tests you can configure a test runner on those systems to
+use a greater or lower timeout on the command line as with the `-o` or
+the `--override-timeout` argument. For example to use 165 seconds instead
+one would use::
+
+ $ ./run_kselftest.sh --override-timeout 165
+
+You can look at the TAP output to see if you ran into the timeout. Test
+runners which know a test must run under a specific time can then optionally
+treat these timeouts then as fatal.
+
Packaging selftests
===================
@@ -187,7 +219,7 @@ option is supported, such as::
tests by using variables specified in `Running a subset of selftests`_
section::
- $ make -C tools/testing/selftests gen_tar TARGETS="bpf" FORMAT=.xz
+ $ make -C tools/testing/selftests gen_tar TARGETS="size" FORMAT=.xz
.. _tar's auto-compress: https://www.gnu.org/software/tar/manual/html_node/gzip.html#auto_002dcompress
@@ -205,6 +237,13 @@ In general, the rules for selftests are
* Don't cause the top-level "make run_tests" to fail if your feature is
unconfigured.
+ * The output of tests must conform to the TAP standard to ensure high
+ testing quality and to capture failures/errors with specific details.
+ The kselftest.h and kselftest_harness.h headers provide wrappers for
+ outputting test results. These wrappers should be used for pass,
+ fail, exit, and skip messages. CI systems can easily parse TAP output
+ messages to detect test results.
+
Contributing new tests (details)
================================
@@ -222,6 +261,10 @@ Contributing new tests (details)
TEST_PROGS, TEST_GEN_PROGS mean it is the executable tested by
default.
+ TEST_GEN_MODS_DIR should be used by tests that require modules to be built
+ before the test starts. The variable will contain the name of the directory
+ containing the modules.
+
TEST_CUSTOM_PROGS should be used by tests that require custom build
rules and prevent common build rule use.
@@ -232,9 +275,21 @@ Contributing new tests (details)
TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the
executable which is not tested by default.
+
TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
test.
+ TEST_INCLUDES is similar to TEST_FILES, it lists files which should be
+ included when exporting or installing the tests, with the following
+ differences:
+
+ * symlinks to files in other directories are preserved
+ * the part of paths below tools/testing/selftests/ is preserved when
+ copying the files to the output directory
+
+ TEST_INCLUDES is meant to list dependencies located in other directories of
+ the selftests hierarchy.
+
* First use the headers inside the kernel source and/or git repo, and then the
system headers. Headers for the kernel release as opposed to headers
installed by the distro on the system should be the primary focus to be able
@@ -292,7 +347,7 @@ kselftest. We use kselftests for lib/ as an example.
1. Create the test module
2. Create the test script that will run (load/unload) the module
- e.g. ``tools/testing/selftests/lib/printf.sh``
+ e.g. ``tools/testing/selftests/lib/bitmap.sh``
3. Add line to config file e.g. ``tools/testing/selftests/lib/config``
diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst
index d0a9565b0f44..a9810bed5fd4 100644
--- a/Documentation/dev-tools/ktap.rst
+++ b/Documentation/dev-tools/ktap.rst
@@ -5,7 +5,7 @@ The Kernel Test Anything Protocol (KTAP), version 1
===================================================
TAP, or the Test Anything Protocol is a format for specifying test results used
-by a number of projects. It's website and specification are found at this `link
+by a number of projects. Its website and specification are found at this `link
<https://testanything.org/>`_. The Linux Kernel largely uses TAP output for test
results. However, Kernel testing frameworks have special needs for test results
which don't align with the original TAP specification. Thus, a "Kernel TAP"
@@ -20,6 +20,7 @@ machine-readable, whereas the diagnostic data is unstructured and is there to
aid human debugging.
KTAP output is built from four different types of lines:
+
- Version lines
- Plan lines
- Test case result lines
@@ -38,6 +39,7 @@ All KTAP-formatted results begin with a "version line" which specifies which
version of the (K)TAP standard the result is compliant with.
For example:
+
- "KTAP version 1"
- "TAP version 13"
- "TAP version 14"
@@ -80,8 +82,8 @@ have the number 1 and the number then must increase by 1 for each additional
subtest within the same test at the same nesting level.
The description is a description of the test, generally the name of
-the test, and can be any string of words (can't include #). The
-description is optional, but recommended.
+the test, and can be any string of characters other than # or a
+newline. The description is optional, but recommended.
The directive and any diagnostic data is optional. If either are present, they
must follow a hash sign, "#".
@@ -276,6 +278,7 @@ Example KTAP output
This output defines the following hierarchy:
A single test called "main_test", which fails, and has three subtests:
+
- "example_test_1", which passes, and has one subtest:
- "test_1", which passes, and outputs the diagnostic message "test_1: initializing test_1"
diff --git a/Documentation/dev-tools/kunit/api/clk.rst b/Documentation/dev-tools/kunit/api/clk.rst
new file mode 100644
index 000000000000..eeaa50089453
--- /dev/null
+++ b/Documentation/dev-tools/kunit/api/clk.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========
+Clk API
+========
+
+The KUnit clk API is used to test clk providers and clk consumers.
+
+.. kernel-doc:: drivers/clk/clk_kunit_helpers.c
+ :export:
diff --git a/Documentation/dev-tools/kunit/api/functionredirection.rst b/Documentation/dev-tools/kunit/api/functionredirection.rst
new file mode 100644
index 000000000000..3791efc2fcca
--- /dev/null
+++ b/Documentation/dev-tools/kunit/api/functionredirection.rst
@@ -0,0 +1,162 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+Function Redirection API
+========================
+
+Overview
+========
+
+When writing unit tests, it's important to be able to isolate the code being
+tested from other parts of the kernel. This ensures the reliability of the test
+(it won't be affected by external factors), reduces dependencies on specific
+hardware or config options (making the test easier to run), and protects the
+stability of the rest of the system (making it less likely for test-specific
+state to interfere with the rest of the system).
+
+While for some code (typically generic data structures, helpers, and other
+"pure functions") this is trivial, for others (like device drivers,
+filesystems, core subsystems) the code is heavily coupled with other parts of
+the kernel.
+
+This coupling is often due to global state in some way: be it a global list of
+devices, the filesystem, or some hardware state. Tests need to either carefully
+manage, isolate, and restore state, or they can avoid it altogether by
+replacing access to and mutation of this state with a "fake" or "mock" variant.
+
+By refactoring access to such state, such as by introducing a layer of
+indirection which can use or emulate a separate set of test state. However,
+such refactoring comes with its own costs (and undertaking significant
+refactoring before being able to write tests is suboptimal).
+
+A simpler way to intercept and replace some of the function calls is to use
+function redirection via static stubs.
+
+
+Static Stubs
+============
+
+Static stubs are a way of redirecting calls to one function (the "real"
+function) to another function (the "replacement" function).
+
+It works by adding a macro to the "real" function which checks to see if a test
+is running, and if a replacement function is available. If so, that function is
+called in place of the original.
+
+Using static stubs is pretty straightforward:
+
+1. Add the KUNIT_STATIC_STUB_REDIRECT() macro to the start of the "real"
+ function.
+
+ This should be the first statement in the function, after any variable
+ declarations. KUNIT_STATIC_STUB_REDIRECT() takes the name of the
+ function, followed by all of the arguments passed to the real function.
+
+ For example:
+
+ .. code-block:: c
+
+ void send_data_to_hardware(const char *str)
+ {
+ KUNIT_STATIC_STUB_REDIRECT(send_data_to_hardware, str);
+ /* real implementation */
+ }
+
+2. Write one or more replacement functions.
+
+ These functions should have the same function signature as the real function.
+ In the event they need to access or modify test-specific state, they can use
+ kunit_get_current_test() to get a struct kunit pointer. This can then
+ be passed to the expectation/assertion macros, or used to look up KUnit
+ resources.
+
+ For example:
+
+ .. code-block:: c
+
+ void fake_send_data_to_hardware(const char *str)
+ {
+ struct kunit *test = kunit_get_current_test();
+ KUNIT_EXPECT_STREQ(test, str, "Hello World!");
+ }
+
+3. Activate the static stub from your test.
+
+ From within a test, the redirection can be enabled with
+ kunit_activate_static_stub(), which accepts a struct kunit pointer,
+ the real function, and the replacement function. You can call this several
+ times with different replacement functions to swap out implementations of the
+ function.
+
+ In our example, this would be
+
+ .. code-block:: c
+
+ kunit_activate_static_stub(test,
+ send_data_to_hardware,
+ fake_send_data_to_hardware);
+
+4. Call (perhaps indirectly) the real function.
+
+ Once the redirection is activated, any call to the real function will call
+ the replacement function instead. Such calls may be buried deep in the
+ implementation of another function, but must occur from the test's kthread.
+
+ For example:
+
+ .. code-block:: c
+
+ send_data_to_hardware("Hello World!"); /* Succeeds */
+ send_data_to_hardware("Something else"); /* Fails the test. */
+
+5. (Optionally) disable the stub.
+
+ When you no longer need it, disable the redirection (and hence resume the
+ original behaviour of the 'real' function) using
+ kunit_deactivate_static_stub(). Otherwise, it will be automatically disabled
+ when the test exits.
+
+ For example:
+
+ .. code-block:: c
+
+ kunit_deactivate_static_stub(test, send_data_to_hardware);
+
+
+It's also possible to use these replacement functions to test to see if a
+function is called at all, for example:
+
+.. code-block:: c
+
+ void send_data_to_hardware(const char *str)
+ {
+ KUNIT_STATIC_STUB_REDIRECT(send_data_to_hardware, str);
+ /* real implementation */
+ }
+
+ /* In test file */
+ int times_called = 0;
+ void fake_send_data_to_hardware(const char *str)
+ {
+ times_called++;
+ }
+ ...
+ /* In the test case, redirect calls for the duration of the test */
+ kunit_activate_static_stub(test, send_data_to_hardware, fake_send_data_to_hardware);
+
+ send_data_to_hardware("hello");
+ KUNIT_EXPECT_EQ(test, times_called, 1);
+
+ /* Can also deactivate the stub early, if wanted */
+ kunit_deactivate_static_stub(test, send_data_to_hardware);
+
+ send_data_to_hardware("hello again");
+ KUNIT_EXPECT_EQ(test, times_called, 1);
+
+
+
+API Reference
+=============
+
+.. kernel-doc:: include/kunit/static_stub.h
+ :internal:
diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst
index 45ce04823f9f..5cdb552a0808 100644
--- a/Documentation/dev-tools/kunit/api/index.rst
+++ b/Documentation/dev-tools/kunit/api/index.rst
@@ -4,17 +4,45 @@
API Reference
=============
.. toctree::
+ :hidden:
test
resource
+ functionredirection
+ clk
+ of
+ platformdevice
-This section documents the KUnit kernel testing API. It is divided into the
+
+This page documents the KUnit kernel testing API. It is divided into the
following sections:
+Core KUnit API
+==============
+
Documentation/dev-tools/kunit/api/test.rst
- - documents all of the standard testing API
+ - Documents all of the standard testing API
Documentation/dev-tools/kunit/api/resource.rst
- - documents the KUnit resource API
+ - Documents the KUnit resource API
+
+Documentation/dev-tools/kunit/api/functionredirection.rst
+
+ - Documents the KUnit Function Redirection API
+
+Driver KUnit API
+================
+
+Documentation/dev-tools/kunit/api/clk.rst
+
+ - Documents the KUnit clk API
+
+Documentation/dev-tools/kunit/api/of.rst
+
+ - Documents the KUnit device tree (OF) API
+
+Documentation/dev-tools/kunit/api/platformdevice.rst
+
+ - Documents the KUnit platform device API
diff --git a/Documentation/dev-tools/kunit/api/of.rst b/Documentation/dev-tools/kunit/api/of.rst
new file mode 100644
index 000000000000..cb4193dcddbb
--- /dev/null
+++ b/Documentation/dev-tools/kunit/api/of.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Device Tree (OF) API
+====================
+
+The KUnit device tree API is used to test device tree (of_*) dependent code.
+
+.. kernel-doc:: include/kunit/of.h
+ :internal:
+
+.. kernel-doc:: drivers/of/of_kunit_helpers.c
+ :export:
diff --git a/Documentation/dev-tools/kunit/api/platformdevice.rst b/Documentation/dev-tools/kunit/api/platformdevice.rst
new file mode 100644
index 000000000000..49ddd5729003
--- /dev/null
+++ b/Documentation/dev-tools/kunit/api/platformdevice.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===================
+Platform Device API
+===================
+
+The KUnit platform device API is used to test platform devices.
+
+.. kernel-doc:: lib/kunit/platform.c
+ :export:
diff --git a/Documentation/dev-tools/kunit/api/resource.rst b/Documentation/dev-tools/kunit/api/resource.rst
index 0a94f831259e..ec6002a6b0db 100644
--- a/Documentation/dev-tools/kunit/api/resource.rst
+++ b/Documentation/dev-tools/kunit/api/resource.rst
@@ -11,3 +11,12 @@ state on a per-test basis, register custom cleanup actions, and more.
.. kernel-doc:: include/kunit/resource.h
:internal:
+
+Managed Devices
+---------------
+
+Functions for using KUnit-managed struct device and struct device_driver.
+Include ``kunit/device.h`` to use these.
+
+.. kernel-doc:: include/kunit/device.h
+ :internal:
diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst
index 8efe792bdcb9..f335f883f8f6 100644
--- a/Documentation/dev-tools/kunit/architecture.rst
+++ b/Documentation/dev-tools/kunit/architecture.rst
@@ -4,16 +4,17 @@
KUnit Architecture
==================
-The KUnit architecture can be divided into two parts:
+The KUnit architecture is divided into two parts:
- `In-Kernel Testing Framework`_
-- `kunit_tool (Command Line Test Harness)`_
+- `kunit_tool (Command-line Test Harness)`_
In-Kernel Testing Framework
===========================
The kernel testing library supports KUnit tests written in C using
-KUnit. KUnit tests are kernel code. KUnit does several things:
+KUnit. These KUnit tests are kernel code. KUnit performs the following
+tasks:
- Organizes tests
- Reports test results
@@ -22,19 +23,17 @@ KUnit. KUnit tests are kernel code. KUnit does several things:
Test Cases
----------
-The fundamental unit in KUnit is the test case. The KUnit test cases are
-grouped into KUnit suites. A KUnit test case is a function with type
-signature ``void (*)(struct kunit *test)``.
-These test case functions are wrapped in a struct called
-struct kunit_case.
+The test case is the fundamental unit in KUnit. KUnit test cases are organised
+into suites. A KUnit test case is a function with type signature
+``void (*)(struct kunit *test)``. These test case functions are wrapped in a
+struct called struct kunit_case.
.. note:
``generate_params`` is optional for non-parameterized tests.
-Each KUnit test case gets a ``struct kunit`` context
-object passed to it that tracks a running test. The KUnit assertion
-macros and other KUnit utilities use the ``struct kunit`` context
-object. As an exception, there are two fields:
+Each KUnit test case receives a ``struct kunit`` context object that tracks a
+running test. The KUnit assertion macros and other KUnit utilities use the
+``struct kunit`` context object. As an exception, there are two fields:
- ``->priv``: The setup functions can use it to store arbitrary test
user data.
@@ -77,12 +76,13 @@ Executor
The KUnit executor can list and run built-in KUnit tests on boot.
The Test suites are stored in a linker section
-called ``.kunit_test_suites``. For code, see:
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/vmlinux.lds.h?h=v5.15#n945.
+called ``.kunit_test_suites``. For the code, see ``KUNIT_TABLE()`` macro
+definition in
+`include/asm-generic/vmlinux.lds.h <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/vmlinux.lds.h?h=v6.0#n950>`_.
The linker section consists of an array of pointers to
``struct kunit_suite``, and is populated by the ``kunit_test_suites()``
-macro. To run all tests compiled into the kernel, the KUnit executor
-iterates over the linker section array.
+macro. The KUnit executor iterates over the linker section array in order to
+run all the tests that are compiled into the kernel.
.. kernel-figure:: kunit_suitememorydiagram.svg
:alt: KUnit Suite Memory
@@ -90,17 +90,17 @@ iterates over the linker section array.
KUnit Suite Memory Diagram
On the kernel boot, the KUnit executor uses the start and end addresses
-of this section to iterate over and run all tests. For code, see:
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/executor.c
-
+of this section to iterate over and run all tests. For the implementation of the
+executor, see
+`lib/kunit/executor.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/executor.c>`_.
When built as a module, the ``kunit_test_suites()`` macro defines a
``module_init()`` function, which runs all the tests in the compilation
unit instead of utilizing the executor.
In KUnit tests, some error classes do not affect other tests
or parts of the kernel, each KUnit case executes in a separate thread
-context. For code, see:
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/try-catch.c?h=v5.15#n58
+context. See the ``kunit_try_catch_run()`` function in
+`lib/kunit/try-catch.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/try-catch.c?h=v5.15#n58>`_.
Assertion Macros
----------------
@@ -111,37 +111,36 @@ All expectations/assertions are formatted as:
- ``{EXPECT|ASSERT}`` determines whether the check is an assertion or an
expectation.
+ In the event of a failure, the testing flow differs as follows:
- - For an expectation, if the check fails, marks the test as failed
- and logs the failure.
+ - For expectations, the test is marked as failed and the failure is logged.
- - An assertion, on failure, causes the test case to terminate
- immediately.
+ - Failing assertions, on the other hand, result in the test case being
+ terminated immediately.
- - Assertions call function:
- ``void __noreturn kunit_abort(struct kunit *)``.
+ - Assertions call the function:
+ ``void __noreturn __kunit_abort(struct kunit *)``.
- - ``kunit_abort`` calls function:
+ - ``__kunit_abort`` calls the function:
``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``.
- - ``kunit_try_catch_throw`` calls function:
+ - ``kunit_try_catch_throw`` calls the function:
``void kthread_complete_and_exit(struct completion *, long) __noreturn;``
and terminates the special thread context.
- ``<op>`` denotes a check with options: ``TRUE`` (supplied property
- has the boolean value “true”), ``EQ`` (two supplied properties are
+ has the boolean value "true"), ``EQ`` (two supplied properties are
equal), ``NOT_ERR_OR_NULL`` (supplied pointer is not null and does not
- contain an “err” value).
+ contain an "err" value).
- ``[_MSG]`` prints a custom message on failure.
Test Result Reporting
---------------------
-KUnit prints test results in KTAP format. KTAP is based on TAP14, see:
-https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-specification.md.
-KTAP (yet to be standardized format) works with KUnit and Kselftest.
-The KUnit executor prints KTAP results to dmesg, and debugfs
-(if configured).
+KUnit prints the test results in KTAP format. KTAP is based on TAP14, see
+Documentation/dev-tools/ktap.rst.
+KTAP works with KUnit and Kselftest. The KUnit executor prints KTAP results to
+dmesg, and debugfs (if configured).
Parameterized Tests
-------------------
@@ -150,33 +149,35 @@ Each KUnit parameterized test is associated with a collection of
parameters. The test is invoked multiple times, once for each parameter
value and the parameter is stored in the ``param_value`` field.
The test case includes a KUNIT_CASE_PARAM() macro that accepts a
-generator function.
-The generator function is passed the previous parameter and returns the next
-parameter. It also provides a macro to generate common-case generators based on
-arrays.
+generator function. The generator function is passed the previous parameter
+and returns the next parameter. It also includes a macro for generating
+array-based common-case generators.
-kunit_tool (Command Line Test Harness)
+kunit_tool (Command-line Test Harness)
======================================
-kunit_tool is a Python script ``(tools/testing/kunit/kunit.py)``
-that can be used to configure, build, exec, parse and run (runs other
-commands in order) test results. You can either run KUnit tests using
-kunit_tool or can include KUnit in kernel and parse manually.
+``kunit_tool`` is a Python script, found in ``tools/testing/kunit/kunit.py``. It
+is used to configure, build, execute, parse test results and run all of the
+previous commands in correct order (i.e., configure, build, execute and parse).
+You have two options for running KUnit tests: either build the kernel with KUnit
+enabled and manually parse the results (see
+Documentation/dev-tools/kunit/run_manual.rst) or use ``kunit_tool``
+(see Documentation/dev-tools/kunit/run_wrapper.rst).
- ``configure`` command generates the kernel ``.config`` from a
``.kunitconfig`` file (and any architecture-specific options).
- For some architectures, additional config options are specified in the
- ``qemu_config`` Python script
- (For example: ``tools/testing/kunit/qemu_configs/powerpc.py``).
+ The Python scripts available in ``qemu_configs`` folder
+ (for example, ``tools/testing/kunit/qemu configs/powerpc.py``) contains
+ additional configuration options for specific architectures.
It parses both the existing ``.config`` and the ``.kunitconfig`` files
- and ensures that ``.config`` is a superset of ``.kunitconfig``.
- If this is not the case, it will combine the two and run
- ``make olddefconfig`` to regenerate the ``.config`` file. It then
- verifies that ``.config`` is now a superset. This checks if all
- Kconfig dependencies are correctly specified in ``.kunitconfig``.
- ``kunit_config.py`` includes the parsing Kconfigs code. The code which
- runs ``make olddefconfig`` is a part of ``kunit_kernel.py``. You can
- invoke this command via: ``./tools/testing/kunit/kunit.py config`` and
+ to ensure that ``.config`` is a superset of ``.kunitconfig``.
+ If not, it will combine the two and run ``make olddefconfig`` to regenerate
+ the ``.config`` file. It then checks to see if ``.config`` has become a superset.
+ This verifies that all the Kconfig dependencies are correctly specified in the
+ file ``.kunitconfig``. The ``kunit_config.py`` script contains the code for parsing
+ Kconfigs. The code which runs ``make olddefconfig`` is part of the
+ ``kunit_kernel.py`` script. You can invoke this command through:
+ ``./tools/testing/kunit/kunit.py config`` and
generate a ``.config`` file.
- ``build`` runs ``make`` on the kernel tree with required options
(depends on the architecture and some options, for example: build_dir)
@@ -184,8 +185,8 @@ kunit_tool or can include KUnit in kernel and parse manually.
To build a KUnit kernel from the current ``.config``, you can use the
``build`` argument: ``./tools/testing/kunit/kunit.py build``.
- ``exec`` command executes kernel results either directly (using
- User-mode Linux configuration), or via an emulator such
- as QEMU. It reads results from the log via standard
+ User-mode Linux configuration), or through an emulator such
+ as QEMU. It reads results from the log using standard
output (stdout), and passes them to ``parse`` to be parsed.
If you already have built a kernel with built-in KUnit tests,
you can run the kernel and display the test results with the ``exec``
diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst
index f5d13f1d37be..b3593ae29ace 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -16,7 +16,6 @@ KUnit - Linux Kernel Unit Testing
api/index
style
faq
- tips
running_tips
This section details the kernel unit testing framework.
@@ -100,14 +99,11 @@ Read also :ref:`kinds-of-tests`.
How do I use it?
================
-* Documentation/dev-tools/kunit/start.rst - for KUnit new users.
-* Documentation/dev-tools/kunit/architecture.rst - KUnit architecture.
-* Documentation/dev-tools/kunit/run_wrapper.rst - run kunit_tool.
-* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit_tool.
-* Documentation/dev-tools/kunit/usage.rst - write tests.
-* Documentation/dev-tools/kunit/tips.rst - best practices with
- examples.
-* Documentation/dev-tools/kunit/api/index.rst - KUnit APIs
- used for testing.
-* Documentation/dev-tools/kunit/faq.rst - KUnit common questions and
- answers.
+You can find a step-by-step guide to writing and running KUnit tests in
+Documentation/dev-tools/kunit/start.rst
+
+Alternatively, feel free to look through the rest of the KUnit documentation,
+or to experiment with tools/testing/kunit/kunit.py and the example test under
+lib/kunit/kunit-example-test.c
+
+Happy testing!
diff --git a/Documentation/dev-tools/kunit/run_manual.rst b/Documentation/dev-tools/kunit/run_manual.rst
index e7b46421f247..98e8d5b28808 100644
--- a/Documentation/dev-tools/kunit/run_manual.rst
+++ b/Documentation/dev-tools/kunit/run_manual.rst
@@ -35,6 +35,12 @@ or be built into the kernel.
a good way of quickly testing everything applicable to the current
config.
+ KUnit can be enabled or disabled at boot time, and this behavior is
+ controlled by the kunit.enable kernel parameter.
+ By default, kunit.enable is set to 1 because KUNIT_DEFAULT_ENABLED is
+ enabled by default. To ensure that tests are executed as expected,
+ verify that kunit.enable=1 at boot time.
+
Once we have built our kernel (and/or modules), it is simple to run
the tests. If the tests are built-in, they will run automatically on the
kernel boot. The results will be written to the kernel log (``dmesg``)
@@ -49,9 +55,52 @@ loaded.
The results will appear in TAP format in ``dmesg``.
+debugfs
+=======
+
+KUnit can be accessed from userspace via the debugfs filesystem (See more
+information about debugfs at Documentation/filesystems/debugfs.rst).
+
+If ``CONFIG_KUNIT_DEBUGFS`` is enabled, the KUnit debugfs filesystem is
+mounted at /sys/kernel/debug/kunit. You can use this filesystem to perform
+the following actions.
+
+Retrieve Test Results
+=====================
+
+You can use debugfs to retrieve KUnit test results. The test results are
+accessible from the debugfs filesystem in the following read-only file:
+
+.. code-block :: bash
+
+ /sys/kernel/debug/kunit/<test_suite>/results
+
+The test results are printed in a KTAP document. Note this document is separate
+to the kernel log and thus, may have different test suite numbering.
+
+Run Tests After Kernel Has Booted
+=================================
+
+You can use the debugfs filesystem to trigger built-in tests to run after
+boot. To run the test suite, you can use the following command to write to
+the ``/sys/kernel/debug/kunit/<test_suite>/run`` file:
+
+.. code-block :: bash
+
+ echo "any string" > /sys/kernel/debugfs/kunit/<test_suite>/run
+
+As a result, the test suite runs and the results are printed to the kernel
+log.
+
+However, this feature is not available with KUnit suites that use init data,
+because init data may have been discarded after the kernel boots. KUnit
+suites that use init data should be defined using the
+kunit_test_init_section_suites() macro.
+
+Also, you cannot use this feature to run tests concurrently. Instead a test
+will wait to run until other tests have completed or failed.
+
.. note ::
- If ``CONFIG_KUNIT_DEBUGFS`` is enabled, KUnit test results will
- be accessible from the ``debugfs`` filesystem (if mounted).
- They will be in ``/sys/kernel/debug/kunit/<test_suite>/results``, in
- TAP format.
+ For test authors, to use this feature, tests will need to correctly initialise
+ and/or clean up any data, so the test runs correctly a second time.
diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst
index 6b33caf6c8ab..6697c71ee8ca 100644
--- a/Documentation/dev-tools/kunit/run_wrapper.rst
+++ b/Documentation/dev-tools/kunit/run_wrapper.rst
@@ -182,6 +182,8 @@ via UML. To run tests on qemu, by default it requires two flags:
is ignored), the tests will run via UML. Non-UML architectures,
for example: i386, x86_64, arm and so on; run on qemu.
+ ``--arch help`` lists all valid ``--arch`` values.
+
- ``--cross_compile``: Specifies the Kbuild toolchain. It passes the
same argument as passed to the ``CROSS_COMPILE`` variable used by
Kbuild. As a reminder, this will be the prefix for the toolchain
@@ -251,14 +253,15 @@ command line arguments:
compiling a kernel (using ``build`` or ``run`` commands). For example:
to enable compiler warnings, we can pass ``--make_options W=1``.
-- ``--alltests``: Builds a UML kernel with all config options enabled
- using ``make allyesconfig``. This allows us to run as many tests as
- possible.
+- ``--alltests``: Enable a predefined set of options in order to build
+ as many tests as possible.
+
+ .. note:: The list of enabled options can be found in
+ ``tools/testing/kunit/configs/all_tests.config``.
- .. note:: It is slow and prone to breakage as new options are
- added or modified. Instead, enable all tests
- which have satisfied dependencies by adding
- ``CONFIG_KUNIT_ALL_TESTS=y`` to your ``.kunitconfig``.
+ If you only want to enable all tests with otherwise satisfied
+ dependencies, instead add ``CONFIG_KUNIT_ALL_TESTS=y`` to your
+ ``.kunitconfig``.
- ``--kunitconfig``: Specifies the path or the directory of the ``.kunitconfig``
file. For example:
@@ -320,3 +323,15 @@ command line arguments:
- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or
saves to a file if a filename is specified.
+
+- ``--filter``: Specifies filters on test attributes, for example, ``speed!=slow``.
+ Multiple filters can be used by wrapping input in quotes and separating filters
+ by commas. Example: ``--filter "speed>slow, module=example"``.
+
+- ``--filter_action``: If set to ``skip``, filtered tests will be shown as skipped
+ in the output rather than showing no output.
+
+- ``--list_tests``: If set, lists all tests that will be run.
+
+- ``--list_tests_attr``: If set, lists all tests that will be run and all of their
+ attributes.
diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst
index 8e8c493f17d1..bd689db6fdd2 100644
--- a/Documentation/dev-tools/kunit/running_tips.rst
+++ b/Documentation/dev-tools/kunit/running_tips.rst
@@ -139,6 +139,17 @@ If your installed version of gcc doesn't work, you can tweak the steps:
$ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6
$ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6
+Alternatively, LLVM-based toolchains can also be used:
+
+.. code-block:: bash
+
+ # Build with LLVM and append coverage options to the current config
+ $ ./tools/testing/kunit/kunit.py run --make_options LLVM=1 --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config
+ $ llvm-profdata merge -sparse default.profraw -o default.profdata
+ $ llvm-cov export --format=lcov .kunit/vmlinux -instr-profile default.profdata > coverage.info
+ # The coverage.info file is in lcov-compatible format and it can be used to e.g. generate HTML report
+ $ genhtml -o /tmp/coverage_html coverage.info
+
Running tests manually
======================
@@ -262,3 +273,176 @@ other code executed during boot, e.g.
# Reset coverage counters before running the test.
$ echo 0 > /sys/kernel/debug/gcov/reset
$ modprobe kunit-example-test
+
+
+Test Attributes and Filtering
+=============================
+
+Test suites and cases can be marked with test attributes, such as speed of
+test. These attributes will later be printed in test output and can be used to
+filter test execution.
+
+Marking Test Attributes
+-----------------------
+
+Tests are marked with an attribute by including a ``kunit_attributes`` object
+in the test definition.
+
+Test cases can be marked using the ``KUNIT_CASE_ATTR(test_name, attributes)``
+macro to define the test case instead of ``KUNIT_CASE(test_name)``.
+
+.. code-block:: c
+
+ static const struct kunit_attributes example_attr = {
+ .speed = KUNIT_VERY_SLOW,
+ };
+
+ static struct kunit_case example_test_cases[] = {
+ KUNIT_CASE_ATTR(example_test, example_attr),
+ };
+
+.. note::
+ To mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``.
+ This is a helpful macro as the slow attribute is the most commonly used.
+
+Test suites can be marked with an attribute by setting the "attr" field in the
+suite definition.
+
+.. code-block:: c
+
+ static const struct kunit_attributes example_attr = {
+ .speed = KUNIT_VERY_SLOW,
+ };
+
+ static struct kunit_suite example_test_suite = {
+ ...,
+ .attr = example_attr,
+ };
+
+.. note::
+ Not all attributes need to be set in a ``kunit_attributes`` object. Unset
+ attributes will remain uninitialized and act as though the attribute is set
+ to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset.
+ These unset attributes will not be reported and may act as a default value
+ for filtering purposes.
+
+Reporting Attributes
+--------------------
+
+When a user runs tests, attributes will be present in the raw kernel output (in
+KTAP format). Note that attributes will be hidden by default in kunit.py output
+for all passing tests but the raw kernel output can be accessed using the
+``--raw_output`` flag. This is an example of how test attributes for test cases
+will be formatted in kernel output:
+
+.. code-block:: none
+
+ # example_test.speed: slow
+ ok 1 example_test
+
+This is an example of how test attributes for test suites will be formatted in
+kernel output:
+
+.. code-block:: none
+
+ KTAP version 2
+ # Subtest: example_suite
+ # module: kunit_example_test
+ 1..3
+ ...
+ ok 1 example_suite
+
+Additionally, users can output a full attribute report of tests with their
+attributes, using the command line flag ``--list_tests_attr``:
+
+.. code-block:: bash
+
+ kunit.py run "example" --list_tests_attr
+
+.. note::
+ This report can be accessed when running KUnit manually by passing in the
+ module_param ``kunit.action=list_attr``.
+
+Filtering
+---------
+
+Users can filter tests using the ``--filter`` command line flag when running
+tests. As an example:
+
+.. code-block:: bash
+
+ kunit.py run --filter speed=slow
+
+
+You can also use the following operations on filters: "<", ">", "<=", ">=",
+"!=", and "=". Example:
+
+.. code-block:: bash
+
+ kunit.py run --filter "speed>slow"
+
+This example will run all tests with speeds faster than slow. Note that the
+characters < and > are often interpreted by the shell, so they may need to be
+quoted or escaped, as above.
+
+Additionally, you can use multiple filters at once. Simply separate filters
+using commas. Example:
+
+.. code-block:: bash
+
+ kunit.py run --filter "speed>slow, module=kunit_example_test"
+
+.. note::
+ You can use this filtering feature when running KUnit manually by passing
+ the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``.
+
+Filtered tests will not run or show up in the test output. You can use the
+``--filter_action=skip`` flag to skip filtered tests instead. These tests will be
+shown in the test output in the test but will not run. To use this feature when
+running KUnit manually, use the module param ``kunit.filter_action=skip``.
+
+Rules of Filtering Procedure
+----------------------------
+
+Since both suites and test cases can have attributes, there may be conflicts
+between attributes during filtering. The process of filtering follows these
+rules:
+
+- Filtering always operates at a per-test level.
+
+- If a test has an attribute set, then the test's value is filtered on.
+
+- Otherwise, the value falls back to the suite's value.
+
+- If neither are set, the attribute has a global "default" value, which is used.
+
+List of Current Attributes
+--------------------------
+
+``speed``
+
+This attribute indicates the speed of a test's execution (how slow or fast the
+test is).
+
+This attribute is saved as an enum with the following categories: "normal",
+"slow", or "very_slow". The assumed default speed for tests is "normal". This
+indicates that the test takes a relatively trivial amount of time (less than
+1 second), regardless of the machine it is running on. Any test slower than
+this could be marked as "slow" or "very_slow".
+
+The macro ``KUNIT_CASE_SLOW(test_name)`` can be easily used to set the speed
+of a test case to "slow".
+
+``module``
+
+This attribute indicates the name of the module associated with the test.
+
+This attribute is automatically saved as a string and is printed for each suite.
+Tests can also be filtered using this attribute.
+
+``is_init``
+
+This attribute indicates whether the test uses init data or functions.
+
+This attribute is automatically saved as a boolean and tests can also be
+filtered using this attribute.
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index f4f504f1fb15..a98235326bab 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -250,15 +250,20 @@ Now we are ready to write the test cases.
};
kunit_test_suite(misc_example_test_suite);
+ MODULE_LICENSE("GPL");
+
2. Add the following lines to ``drivers/misc/Kconfig``:
.. code-block:: kconfig
config MISC_EXAMPLE_TEST
tristate "Test for my example" if !KUNIT_ALL_TESTS
- depends on MISC_EXAMPLE && KUNIT=y
+ depends on MISC_EXAMPLE && KUNIT
default KUNIT_ALL_TESTS
+Note: If your test does not support being built as a loadable module (which is
+discouraged), replace tristate by bool, and depend on KUNIT=y instead of KUNIT.
+
3. Add the following lines to ``drivers/misc/Makefile``:
.. code-block:: make
@@ -294,13 +299,11 @@ Congrats! You just wrote your first KUnit test.
Next Steps
==========
-* Documentation/dev-tools/kunit/architecture.rst - KUnit architecture.
-* Documentation/dev-tools/kunit/run_wrapper.rst - run kunit_tool.
-* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit_tool.
-* Documentation/dev-tools/kunit/usage.rst - write tests.
-* Documentation/dev-tools/kunit/tips.rst - best practices with
- examples.
-* Documentation/dev-tools/kunit/api/index.rst - KUnit APIs
- used for testing.
-* Documentation/dev-tools/kunit/faq.rst - KUnit common questions and
- answers.
+If you're interested in using some of the more advanced features of kunit.py,
+take a look at Documentation/dev-tools/kunit/run_wrapper.rst
+
+If you'd like to run tests without using kunit.py, check out
+Documentation/dev-tools/kunit/run_manual.rst
+
+For more information on writing KUnit tests (including some common techniques
+for testing different things), see Documentation/dev-tools/kunit/usage.rst
diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst
index b6d0d7359f00..eac81a714a29 100644
--- a/Documentation/dev-tools/kunit/style.rst
+++ b/Documentation/dev-tools/kunit/style.rst
@@ -188,15 +188,26 @@ For example, a Kconfig entry might look like:
Test File and Module Names
==========================
-KUnit tests can often be compiled as a module. These modules should be named
-after the test suite, followed by ``_test``. If this is likely to conflict with
-non-KUnit tests, the suffix ``_kunit`` can also be used.
+KUnit tests are often compiled as a separate module. To avoid conflicting
+with regular modules, KUnit modules should be named after the test suite,
+followed by ``_kunit`` (e.g. if "foobar" is the core module, then
+"foobar_kunit" is the KUnit test module).
-The easiest way of achieving this is to name the file containing the test suite
-``<suite>_test.c`` (or, as above, ``<suite>_kunit.c``). This file should be
-placed next to the code under test.
+Test source files, whether compiled as a separate module or an
+``#include`` in another source file, are best kept in a ``tests/``
+subdirectory to not conflict with other source files (e.g. for
+tab-completion).
+
+Note that the ``_test`` suffix has also been used in some existing
+tests. The ``_kunit`` suffix is preferred, as it makes the distinction
+between KUnit and non-KUnit tests clearer.
+
+So for the common case, name the file containing the test suite
+``tests/<suite>_kunit.c``. The ``tests`` directory should be placed at
+the same level as the code under test. For example, tests for
+``lib/string.c`` live in ``lib/tests/string_kunit.c``.
If the suite name contains some or all of the name of the test's parent
-directory, it may make sense to modify the source filename to reduce redundancy.
-For example, a ``foo_firmware`` suite could be in the ``foo/firmware_test.c``
-file.
+directory, it may make sense to modify the source filename to reduce
+redundancy. For example, a ``foo_firmware`` suite could be in the
+``foo/tests/firmware_kunit.c`` file.
diff --git a/Documentation/dev-tools/kunit/tips.rst b/Documentation/dev-tools/kunit/tips.rst
deleted file mode 100644
index 492d2ded2f5a..000000000000
--- a/Documentation/dev-tools/kunit/tips.rst
+++ /dev/null
@@ -1,190 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-============================
-Tips For Writing KUnit Tests
-============================
-
-Exiting early on failed expectations
-------------------------------------
-
-``KUNIT_EXPECT_EQ`` and friends will mark the test as failed and continue
-execution. In some cases, it's unsafe to continue and you can use the
-``KUNIT_ASSERT`` variant to exit on failure.
-
-.. code-block:: c
-
- void example_test_user_alloc_function(struct kunit *test)
- {
- void *object = alloc_some_object_for_me();
-
- /* Make sure we got a valid pointer back. */
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object);
- do_something_with_object(object);
- }
-
-Allocating memory
------------------
-
-Where you would use ``kzalloc``, you should prefer ``kunit_kzalloc`` instead.
-KUnit will ensure the memory is freed once the test completes.
-
-This is particularly useful since it lets you use the ``KUNIT_ASSERT_EQ``
-macros to exit early from a test without having to worry about remembering to
-call ``kfree``.
-
-Example:
-
-.. code-block:: c
-
- void example_test_allocation(struct kunit *test)
- {
- char *buffer = kunit_kzalloc(test, 16, GFP_KERNEL);
- /* Ensure allocation succeeded. */
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buffer);
-
- KUNIT_ASSERT_STREQ(test, buffer, "");
- }
-
-
-Testing static functions
-------------------------
-
-If you don't want to expose functions or variables just for testing, one option
-is to conditionally ``#include`` the test file at the end of your .c file, e.g.
-
-.. code-block:: c
-
- /* In my_file.c */
-
- static int do_interesting_thing();
-
- #ifdef CONFIG_MY_KUNIT_TEST
- #include "my_kunit_test.c"
- #endif
-
-Injecting test-only code
-------------------------
-
-Similarly to the above, it can be useful to add test-specific logic.
-
-.. code-block:: c
-
- /* In my_file.h */
-
- #ifdef CONFIG_MY_KUNIT_TEST
- /* Defined in my_kunit_test.c */
- void test_only_hook(void);
- #else
- void test_only_hook(void) { }
- #endif
-
-This test-only code can be made more useful by accessing the current kunit
-test, see below.
-
-Accessing the current test
---------------------------
-
-In some cases, you need to call test-only code from outside the test file, e.g.
-like in the example above or if you're providing a fake implementation of an
-ops struct.
-There is a ``kunit_test`` field in ``task_struct``, so you can access it via
-``current->kunit_test``.
-
-Here's a slightly in-depth example of how one could implement "mocking":
-
-.. code-block:: c
-
- #include <linux/sched.h> /* for current */
-
- struct test_data {
- int foo_result;
- int want_foo_called_with;
- };
-
- static int fake_foo(int arg)
- {
- struct kunit *test = current->kunit_test;
- struct test_data *test_data = test->priv;
-
- KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg);
- return test_data->foo_result;
- }
-
- static void example_simple_test(struct kunit *test)
- {
- /* Assume priv is allocated in the suite's .init */
- struct test_data *test_data = test->priv;
-
- test_data->foo_result = 42;
- test_data->want_foo_called_with = 1;
-
- /* In a real test, we'd probably pass a pointer to fake_foo somewhere
- * like an ops struct, etc. instead of calling it directly. */
- KUNIT_EXPECT_EQ(test, fake_foo(1), 42);
- }
-
-
-Note: here we're able to get away with using ``test->priv``, but if you wanted
-something more flexible you could use a named ``kunit_resource``, see
-Documentation/dev-tools/kunit/api/test.rst.
-
-Failing the current test
-------------------------
-
-But sometimes, you might just want to fail the current test. In that case, we
-have ``kunit_fail_current_test(fmt, args...)`` which is defined in ``<kunit/test-bug.h>`` and
-doesn't require pulling in ``<kunit/test.h>``.
-
-E.g. say we had an option to enable some extra debug checks on some data structure:
-
-.. code-block:: c
-
- #include <kunit/test-bug.h>
-
- #ifdef CONFIG_EXTRA_DEBUG_CHECKS
- static void validate_my_data(struct data *data)
- {
- if (is_valid(data))
- return;
-
- kunit_fail_current_test("data %p is invalid", data);
-
- /* Normal, non-KUnit, error reporting code here. */
- }
- #else
- static void my_debug_function(void) { }
- #endif
-
-
-Customizing error messages
---------------------------
-
-Each of the ``KUNIT_EXPECT`` and ``KUNIT_ASSERT`` macros have a ``_MSG`` variant.
-These take a format string and arguments to provide additional context to the automatically generated error messages.
-
-.. code-block:: c
-
- char some_str[41];
- generate_sha1_hex_string(some_str);
-
- /* Before. Not easy to tell why the test failed. */
- KUNIT_EXPECT_EQ(test, strlen(some_str), 40);
-
- /* After. Now we see the offending string. */
- KUNIT_EXPECT_EQ_MSG(test, strlen(some_str), 40, "some_str='%s'", some_str);
-
-Alternatively, one can take full control over the error message by using ``KUNIT_FAIL()``, e.g.
-
-.. code-block:: c
-
- /* Before */
- KUNIT_EXPECT_EQ(test, some_setup_function(), 0);
-
- /* After: full control over the failure message. */
- if (some_setup_function())
- KUNIT_FAIL(test, "Failed to setup thing for testing");
-
-Next Steps
-==========
-* Optional: see the Documentation/dev-tools/kunit/usage.rst page for a more
- in-depth explanation of KUnit.
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 2737863ef365..ebd06f5ea455 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -112,11 +112,51 @@ terminates the test case if the condition is not satisfied. For example:
KUNIT_EXPECT_LE(test, a[i], a[i + 1]);
}
-In this example, the method under test should return pointer to a value. If the
-pointer returns null or an errno, we want to stop the test since the following
-expectation could crash the test case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us
-to bail out of the test case if the appropriate conditions are not satisfied to
-complete the test.
+In this example, we need to be able to allocate an array to test the ``sort()``
+function. So we use ``KUNIT_ASSERT_NOT_ERR_OR_NULL()`` to abort the test if
+there's an allocation error.
+
+.. note::
+ In other test frameworks, ``ASSERT`` macros are often implemented by calling
+ ``return`` so they only work from the test function. In KUnit, we stop the
+ current kthread on failure, so you can call them from anywhere.
+
+.. note::
+ Warning: There is an exception to the above rule. You shouldn't use assertions
+ in the suite's exit() function, or in the free function for a resource. These
+ run when a test is shutting down, and an assertion here prevents further
+ cleanup code from running, potentially leading to a memory leak.
+
+Customizing error messages
+--------------------------
+
+Each of the ``KUNIT_EXPECT`` and ``KUNIT_ASSERT`` macros have a ``_MSG``
+variant. These take a format string and arguments to provide additional
+context to the automatically generated error messages.
+
+.. code-block:: c
+
+ char some_str[41];
+ generate_sha1_hex_string(some_str);
+
+ /* Before. Not easy to tell why the test failed. */
+ KUNIT_EXPECT_EQ(test, strlen(some_str), 40);
+
+ /* After. Now we see the offending string. */
+ KUNIT_EXPECT_EQ_MSG(test, strlen(some_str), 40, "some_str='%s'", some_str);
+
+Alternatively, one can take full control over the error message by using
+``KUNIT_FAIL()``, e.g.
+
+.. code-block:: c
+
+ /* Before */
+ KUNIT_EXPECT_EQ(test, some_setup_function(), 0);
+
+ /* After: full control over the failure message. */
+ if (some_setup_function())
+ KUNIT_FAIL(test, "Failed to setup thing for testing");
+
Test Suites
~~~~~~~~~~~
@@ -126,7 +166,12 @@ many similar tests. In order to reduce duplication in these closely related
tests, most unit testing frameworks (including KUnit) provide the concept of a
*test suite*. A test suite is a collection of test cases for a unit of code
with optional setup and teardown functions that run before/after the whole
-suite and/or every test case. For example:
+suite and/or every test case.
+
+.. note::
+ A test case will only run if it is associated with a test suite.
+
+For example:
.. code-block:: c
@@ -156,7 +201,10 @@ after everything else. ``kunit_test_suite(example_test_suite)`` registers the
test suite with the KUnit test framework.
.. note::
- A test case will only run if it is associated with a test suite.
+ The ``exit`` and ``suite_exit`` functions will run even if ``init`` or
+ ``suite_init`` fail. Make sure that they can handle any inconsistent
+ state which may result from ``init`` or ``suite_init`` encountering errors
+ or exiting early.
``kunit_test_suite(...)`` is a macro which tells the linker to put the
specified test suite in a special linker section so that it can be run by KUnit
@@ -494,11 +542,31 @@ There is more boilerplate code involved, but it can:
Parameterized Testing
~~~~~~~~~~~~~~~~~~~~~
-The table-driven testing pattern is common enough that KUnit has special
-support for it.
+To run a test case against multiple inputs, KUnit provides a parameterized
+testing framework. This feature formalizes and extends the concept of
+table-driven tests discussed previously.
+
+A KUnit test is determined to be parameterized if a parameter generator function
+is provided when registering the test case. A test user can either write their
+own generator function or use one that is provided by KUnit. The generator
+function is stored in ``kunit_case->generate_params`` and can be set using the
+macros described in the section below.
-By reusing the same ``cases`` array from above, we can write the test as a
-"parameterized test" with the following.
+To establish the terminology, a "parameterized test" is a test which is run
+multiple times (once per "parameter" or "parameter run"). Each parameter run has
+both its own independent ``struct kunit`` (the "parameter run context") and
+access to a shared parent ``struct kunit`` (the "parameterized test context").
+
+Passing Parameters to a Test
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+There are three ways to provide the parameters to a test:
+
+Array Parameter Macros:
+
+ KUnit provides special support for the common table-driven testing pattern.
+ By applying either ``KUNIT_ARRAY_PARAM`` or ``KUNIT_ARRAY_PARAM_DESC`` to the
+ ``cases`` array from the previous section, we can create a parameterized test
+ as shown below:
.. code-block:: c
@@ -507,7 +575,7 @@ By reusing the same ``cases`` array from above, we can write the test as a
const char *str;
const char *sha1;
};
- const struct sha1_test_case cases[] = {
+ static const struct sha1_test_case cases[] = {
{
.str = "hello world",
.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
@@ -518,13 +586,9 @@ By reusing the same ``cases`` array from above, we can write the test as a
},
};
- // Need a helper function to generate a name for each test case.
- static void case_to_desc(const struct sha1_test_case *t, char *desc)
- {
- strcpy(desc, t->str);
- }
- // Creates `sha1_gen_params()` to iterate over `cases`.
- KUNIT_ARRAY_PARAM(sha1, cases, case_to_desc);
+ // Creates `sha1_gen_params()` to iterate over `cases` while using
+ // the struct member `str` for the case description.
+ KUNIT_ARRAY_PARAM_DESC(sha1, cases, str);
// Looks no different from a normal test.
static void sha1_test(struct kunit *test)
@@ -540,30 +604,324 @@ By reusing the same ``cases`` array from above, we can write the test as a
}
// Instead of KUNIT_CASE, we use KUNIT_CASE_PARAM and pass in the
- // function declared by KUNIT_ARRAY_PARAM.
+ // function declared by KUNIT_ARRAY_PARAM or KUNIT_ARRAY_PARAM_DESC.
static struct kunit_case sha1_test_cases[] = {
KUNIT_CASE_PARAM(sha1_test, sha1_gen_params),
{}
};
-Exiting Early on Failed Expectations
-------------------------------------
+Custom Parameter Generator Function:
+
+ The generator function is responsible for generating parameters one-by-one
+ and has the following signature:
+ ``const void* (*)(struct kunit *test, const void *prev, char *desc)``.
+ You can pass the generator function to the ``KUNIT_CASE_PARAM``
+ or ``KUNIT_CASE_PARAM_WITH_INIT`` macros.
+
+ The function receives the previously generated parameter as the ``prev`` argument
+ (which is ``NULL`` on the first call) and can also access the parameterized
+ test context passed as the ``test`` argument. KUnit calls this function
+ repeatedly until it returns ``NULL``, which signifies that a parameterized
+ test ended.
+
+ Below is an example of how it works:
+
+.. code-block:: c
+
+ #define MAX_TEST_BUFFER_SIZE 8
+
+ // Example generator function. It produces a sequence of buffer sizes that
+ // are powers of two, starting at 1 (e.g., 1, 2, 4, 8).
+ static const void *buffer_size_gen_params(struct kunit *test, const void *prev, char *desc)
+ {
+ long prev_buffer_size = (long)prev;
+ long next_buffer_size = 1; // Start with an initial size of 1.
+
+ // Stop generating parameters if the limit is reached or exceeded.
+ if (prev_buffer_size >= MAX_TEST_BUFFER_SIZE)
+ return NULL;
+
+ // For subsequent calls, calculate the next size by doubling the previous one.
+ if (prev)
+ next_buffer_size = prev_buffer_size << 1;
+
+ return (void *)next_buffer_size;
+ }
+
+ // Simple test to validate that kunit_kzalloc provides zeroed memory.
+ static void buffer_zero_test(struct kunit *test)
+ {
+ long buffer_size = (long)test->param_value;
+ // Use kunit_kzalloc to allocate a zero-initialized buffer. This makes the
+ // memory "parameter run managed," meaning it's automatically cleaned up at
+ // the end of each parameter run.
+ int *buf = kunit_kzalloc(test, buffer_size * sizeof(int), GFP_KERNEL);
+
+ // Ensure the allocation was successful.
+ KUNIT_ASSERT_NOT_NULL(test, buf);
+
+ // Loop through the buffer and confirm every element is zero.
+ for (int i = 0; i < buffer_size; i++)
+ KUNIT_EXPECT_EQ(test, buf[i], 0);
+ }
+
+ static struct kunit_case buffer_test_cases[] = {
+ KUNIT_CASE_PARAM(buffer_zero_test, buffer_size_gen_params),
+ {}
+ };
+
+Runtime Parameter Array Registration in the Init Function:
+
+ For scenarios where you might need to initialize a parameterized test, you
+ can directly register a parameter array to the parameterized test context.
+
+ To do this, you must pass the parameterized test context, the array itself,
+ the array size, and a ``get_description()`` function to the
+ ``kunit_register_params_array()`` macro. This macro populates
+ ``struct kunit_params`` within the parameterized test context, effectively
+ storing a parameter array object. The ``get_description()`` function will
+ be used for populating parameter descriptions and has the following signature:
+ ``void (*)(struct kunit *test, const void *param, char *desc)``. Note that it
+ also has access to the parameterized test context.
+
+ .. important::
+ When using this way to register a parameter array, you will need to
+ manually pass ``kunit_array_gen_params()`` as the generator function to
+ ``KUNIT_CASE_PARAM_WITH_INIT``. ``kunit_array_gen_params()`` is a KUnit
+ helper that will use the registered array to generate the parameters.
+
+ If needed, instead of passing the KUnit helper, you can also pass your
+ own custom generator function that utilizes the parameter array. To
+ access the parameter array from within the parameter generator
+ function use ``test->params_array.params``.
+
+ The ``kunit_register_params_array()`` macro should be called within a
+ ``param_init()`` function that initializes the parameterized test and has
+ the following signature ``int (*)(struct kunit *test)``. For a detailed
+ explanation of this mechanism please refer to the "Adding Shared Resources"
+ section that is after this one. This method supports registering both
+ dynamically built and static parameter arrays.
+
+ The code snippet below shows the ``example_param_init_dynamic_arr`` test that
+ utilizes ``make_fibonacci_params()`` to create a dynamic array, which is then
+ registered using ``kunit_register_params_array()``. To see the full code
+ please refer to lib/kunit/kunit-example-test.c.
+
+.. code-block:: c
+
+ /*
+ * Example of a parameterized test param_init() function that registers a dynamic
+ * array of parameters.
+ */
+ static int example_param_init_dynamic_arr(struct kunit *test)
+ {
+ size_t seq_size;
+ int *fibonacci_params;
+
+ kunit_info(test, "initializing parameterized test\n");
+
+ seq_size = 6;
+ fibonacci_params = make_fibonacci_params(test, seq_size);
+ if (!fibonacci_params)
+ return -ENOMEM;
+ /*
+ * Passes the dynamic parameter array information to the parameterized test
+ * context struct kunit. The array and its metadata will be stored in
+ * test->parent->params_array. The array itself will be located in
+ * params_data.params.
+ */
+ kunit_register_params_array(test, fibonacci_params, seq_size,
+ example_param_dynamic_arr_get_desc);
+ return 0;
+ }
+
+ static struct kunit_case example_test_cases[] = {
+ /*
+ * Note how we pass kunit_array_gen_params() to use the array we
+ * registered in example_param_init_dynamic_arr() to generate
+ * parameters.
+ */
+ KUNIT_CASE_PARAM_WITH_INIT(example_params_test_with_init_dynamic_arr,
+ kunit_array_gen_params,
+ example_param_init_dynamic_arr,
+ example_param_exit_dynamic_arr),
+ {}
+ };
-We can use ``KUNIT_EXPECT_EQ`` to mark the test as failed and continue
-execution. In some cases, it is unsafe to continue. We can use the
-``KUNIT_ASSERT`` variant to exit on failure.
+Adding Shared Resources
+^^^^^^^^^^^^^^^^^^^^^^^
+All parameter runs in this framework hold a reference to the parameterized test
+context, which can be accessed using the parent ``struct kunit`` pointer. The
+parameterized test context is not used to execute any test logic itself; instead,
+it serves as a container for shared resources.
+
+It's possible to add resources to share between parameter runs within a
+parameterized test by using ``KUNIT_CASE_PARAM_WITH_INIT``, to which you pass
+custom ``param_init()`` and ``param_exit()`` functions. These functions run once
+before and once after the parameterized test, respectively.
+
+The ``param_init()`` function, with the signature ``int (*)(struct kunit *test)``,
+can be used for adding resources to the ``resources`` or ``priv`` fields of
+the parameterized test context, registering the parameter array, and any other
+initialization logic.
+
+The ``param_exit()`` function, with the signature ``void (*)(struct kunit *test)``,
+can be used to release any resources that were not parameterized test managed (i.e.
+not automatically cleaned up after the parameterized test ends) and for any other
+exit logic.
+
+Both ``param_init()`` and ``param_exit()`` are passed the parameterized test
+context behind the scenes. However, the test case function receives the parameter
+run context. Therefore, to manage and access shared resources from within a test
+case function, you must use ``test->parent``.
+
+For instance, finding a shared resource allocated by the Resource API requires
+passing ``test->parent`` to ``kunit_find_resource()``. This principle extends to
+all other APIs that might be used in the test case function, including
+``kunit_kzalloc()``, ``kunit_kmalloc_array()``, and others (see
+Documentation/dev-tools/kunit/api/test.rst and the
+Documentation/dev-tools/kunit/api/resource.rst).
+
+.. note::
+ The ``suite->init()`` function, which executes before each parameter run,
+ receives the parameter run context. Therefore, any resources set up in
+ ``suite->init()`` are cleaned up after each parameter run.
+
+The code below shows how you can add the shared resources. Note that this code
+utilizes the Resource API, which you can read more about here:
+Documentation/dev-tools/kunit/api/resource.rst. To see the full version of this
+code please refer to lib/kunit/kunit-example-test.c.
.. code-block:: c
- void example_test_user_alloc_function(struct kunit *test)
+ static int example_resource_init(struct kunit_resource *res, void *context)
+ {
+ ... /* Code that allocates memory and stores context in res->data. */
+ }
+
+ /* This function deallocates memory for the kunit_resource->data field. */
+ static void example_resource_free(struct kunit_resource *res)
{
- void *object = alloc_some_object_for_me();
+ kfree(res->data);
+ }
- /* Make sure we got a valid pointer back. */
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object);
- do_something_with_object(object);
+ /* This match function locates a test resource based on defined criteria. */
+ static bool example_resource_alloc_match(struct kunit *test, struct kunit_resource *res,
+ void *match_data)
+ {
+ return res->data && res->free == example_resource_free;
}
+ /* Function to initialize the parameterized test. */
+ static int example_param_init(struct kunit *test)
+ {
+ int ctx = 3; /* Data to be stored. */
+ void *data = kunit_alloc_resource(test, example_resource_init,
+ example_resource_free,
+ GFP_KERNEL, &ctx);
+ if (!data)
+ return -ENOMEM;
+ kunit_register_params_array(test, example_params_array,
+ ARRAY_SIZE(example_params_array));
+ return 0;
+ }
+
+ /* Example test that uses shared resources in test->resources. */
+ static void example_params_test_with_init(struct kunit *test)
+ {
+ int threshold;
+ const struct example_param *param = test->param_value;
+ /* Here we pass test->parent to access the parameterized test context. */
+ struct kunit_resource *res = kunit_find_resource(test->parent,
+ example_resource_alloc_match,
+ NULL);
+
+ threshold = *((int *)res->data);
+ KUNIT_ASSERT_LE(test, param->value, threshold);
+ kunit_put_resource(res);
+ }
+
+ static struct kunit_case example_test_cases[] = {
+ KUNIT_CASE_PARAM_WITH_INIT(example_params_test_with_init, kunit_array_gen_params,
+ example_param_init, NULL),
+ {}
+ };
+
+As an alternative to using the KUnit Resource API for sharing resources, you can
+place them in ``test->parent->priv``. This serves as a more lightweight method
+for resource storage, best for scenarios where complex resource management is
+not required.
+
+As stated previously ``param_init()`` and ``param_exit()`` get the parameterized
+test context. So, you can directly use ``test->priv`` within ``param_init/exit``
+to manage shared resources. However, from within the test case function, you must
+navigate up to the parent ``struct kunit`` i.e. the parameterized test context.
+Therefore, you need to use ``test->parent->priv`` to access those same
+resources.
+
+The resources placed in ``test->parent->priv`` will need to be allocated in
+memory to persist across the parameter runs. If memory is allocated using the
+KUnit memory allocation APIs (described more in the "Allocating Memory" section
+below), you won't need to worry about deallocation. The APIs will make the memory
+parameterized test 'managed', ensuring that it will automatically get cleaned up
+after the parameterized test concludes.
+
+The code below demonstrates example usage of the ``priv`` field for shared
+resources:
+
+.. code-block:: c
+
+ static const struct example_param {
+ int value;
+ } example_params_array[] = {
+ { .value = 3, },
+ { .value = 2, },
+ { .value = 1, },
+ { .value = 0, },
+ };
+
+ /* Initialize the parameterized test context. */
+ static int example_param_init_priv(struct kunit *test)
+ {
+ int ctx = 3; /* Data to be stored. */
+ int arr_size = ARRAY_SIZE(example_params_array);
+
+ /*
+ * Allocate memory using kunit_kzalloc(). Since the `param_init`
+ * function receives the parameterized test context, this memory
+ * allocation will be scoped to the lifetime of the parameterized test.
+ */
+ test->priv = kunit_kzalloc(test, sizeof(int), GFP_KERNEL);
+
+ /* Assign the context value to test->priv.*/
+ *((int *)test->priv) = ctx;
+
+ /* Register the parameter array. */
+ kunit_register_params_array(test, example_params_array, arr_size, NULL);
+ return 0;
+ }
+
+ static void example_params_test_with_init_priv(struct kunit *test)
+ {
+ int threshold;
+ const struct example_param *param = test->param_value;
+
+ /* By design, test->parent will not be NULL. */
+ KUNIT_ASSERT_NOT_NULL(test, test->parent);
+
+ /* Here we use test->parent->priv to access the shared resource. */
+ threshold = *(int *)test->parent->priv;
+
+ KUNIT_ASSERT_LE(test, param->value, threshold);
+ }
+
+ static struct kunit_case example_tests[] = {
+ KUNIT_CASE_PARAM_WITH_INIT(example_params_test_with_init_priv,
+ kunit_array_gen_params,
+ example_param_init_priv, NULL),
+ {}
+ };
+
Allocating Memory
-----------------
@@ -585,17 +943,109 @@ For example:
KUNIT_ASSERT_STREQ(test, buffer, "");
}
+Registering Cleanup Actions
+---------------------------
+
+If you need to perform some cleanup beyond simple use of ``kunit_kzalloc``,
+you can register a custom "deferred action", which is a cleanup function
+run when the test exits (whether cleanly, or via a failed assertion).
+
+Actions are simple functions with no return value, and a single ``void*``
+context argument, and fulfill the same role as "cleanup" functions in Python
+and Go tests, "defer" statements in languages which support them, and
+(in some cases) destructors in RAII languages.
+
+These are very useful for unregistering things from global lists, closing
+files or other resources, or freeing resources.
+
+For example:
+
+.. code-block:: C
+
+ static void cleanup_device(void *ctx)
+ {
+ struct device *dev = (struct device *)ctx;
+
+ device_unregister(dev);
+ }
+
+ void example_device_test(struct kunit *test)
+ {
+ struct my_device dev;
+
+ device_register(&dev);
+
+ kunit_add_action(test, &cleanup_device, &dev);
+ }
+
+Note that, for functions like device_unregister which only accept a single
+pointer-sized argument, it's possible to automatically generate a wrapper
+with the ``KUNIT_DEFINE_ACTION_WRAPPER()`` macro, for example:
+
+.. code-block:: C
+
+ KUNIT_DEFINE_ACTION_WRAPPER(device_unregister, device_unregister_wrapper, struct device *);
+ kunit_add_action(test, &device_unregister_wrapper, &dev);
+
+You should do this in preference to manually casting to the ``kunit_action_t`` type,
+as casting function pointers will break Control Flow Integrity (CFI).
+
+``kunit_add_action`` can fail if, for example, the system is out of memory.
+You can use ``kunit_add_action_or_reset`` instead which runs the action
+immediately if it cannot be deferred.
+
+If you need more control over when the cleanup function is called, you
+can trigger it early using ``kunit_release_action``, or cancel it entirely
+with ``kunit_remove_action``.
+
Testing Static Functions
------------------------
-If we do not want to expose functions or variables for testing, one option is to
-conditionally ``#include`` the test file at the end of your .c file. For
-example:
+If you want to test static functions without exposing those functions outside of
+testing, one option is conditionally export the symbol. When KUnit is enabled,
+the symbol is exposed but remains static otherwise. To use this method, follow
+the template below.
+
+.. code-block:: c
+
+ /* In the file containing functions to test "my_file.c" */
+
+ #include <kunit/visibility.h>
+ #include <my_file.h>
+ ...
+ VISIBLE_IF_KUNIT int do_interesting_thing()
+ {
+ ...
+ }
+ EXPORT_SYMBOL_IF_KUNIT(do_interesting_thing);
+
+ /* In the header file "my_file.h" */
+
+ #if IS_ENABLED(CONFIG_KUNIT)
+ int do_interesting_thing(void);
+ #endif
+
+ /* In the KUnit test file "my_file_test.c" */
+
+ #include <kunit/visibility.h>
+ #include <my_file.h>
+ ...
+ MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
+ ...
+ // Use do_interesting_thing() in tests
+
+For a full example, see this `patch <https://lore.kernel.org/all/20221207014024.340230-3-rmoar@google.com/>`_
+where a test is modified to conditionally expose static functions for testing
+using the macros above.
+
+As an **alternative** to the method above, you could conditionally ``#include``
+the test file at the end of your .c file. This is not recommended but works
+if needed. For example:
.. code-block:: c
- /* In my_file.c */
+ /* In "my_file.c" */
static int do_interesting_thing();
@@ -625,17 +1075,22 @@ as shown in next section: *Accessing The Current Test*.
Accessing The Current Test
--------------------------
-In some cases, we need to call test-only code from outside the test file.
-For example, see example in section *Injecting Test-Only Code* or if
-we are providing a fake implementation of an ops struct. Using
-``kunit_test`` field in ``task_struct``, we can access it via
-``current->kunit_test``.
+In some cases, we need to call test-only code from outside the test file. This
+is helpful, for example, when providing a fake implementation of a function, or
+to fail any current test from within an error handler.
+We can do this via the ``kunit_test`` field in ``task_struct``, which we can
+access using the ``kunit_get_current_test()`` function in ``kunit/test-bug.h``.
+
+``kunit_get_current_test()`` is safe to call even if KUnit is not enabled. If
+KUnit is not enabled, or if no test is running in the current task, it will
+return ``NULL``. This compiles down to either a no-op or a static key check,
+so will have a negligible performance impact when no test is running.
-The example below includes how to implement "mocking":
+The example below uses this to implement a "mock" implementation of a function, ``foo``:
.. code-block:: c
- #include <linux/sched.h> /* for current */
+ #include <kunit/test-bug.h> /* for kunit_get_current_test */
struct test_data {
int foo_result;
@@ -644,7 +1099,7 @@ The example below includes how to implement "mocking":
static int fake_foo(int arg)
{
- struct kunit *test = current->kunit_test;
+ struct kunit *test = kunit_get_current_test();
struct test_data *test_data = test->priv;
KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg);
@@ -675,7 +1130,7 @@ Each test can have multiple resources which have string names providing the same
flexibility as a ``priv`` member, but also, for example, allowing helper
functions to create resources without conflicting with each other. It is also
possible to define a clean up function for each resource, making it easy to
-avoid resource leaks. For more information, see Documentation/dev-tools/kunit/api/test.rst.
+avoid resource leaks. For more information, see Documentation/dev-tools/kunit/api/resource.rst.
Failing The Current Test
------------------------
@@ -703,3 +1158,57 @@ structures as shown below:
static void my_debug_function(void) { }
#endif
+``kunit_fail_current_test()`` is safe to call even if KUnit is not enabled. If
+KUnit is not enabled, or if no test is running in the current task, it will do
+nothing. This compiles down to either a no-op or a static key check, so will
+have a negligible performance impact when no test is running.
+
+Managing Fake Devices and Drivers
+---------------------------------
+
+When testing drivers or code which interacts with drivers, many functions will
+require a ``struct device`` or ``struct device_driver``. In many cases, setting
+up a real device is not required to test any given function, so a fake device
+can be used instead.
+
+KUnit provides helper functions to create and manage these fake devices, which
+are internally of type ``struct kunit_device``, and are attached to a special
+``kunit_bus``. These devices support managed device resources (devres), as
+described in Documentation/driver-api/driver-model/devres.rst
+
+To create a KUnit-managed ``struct device_driver``, use ``kunit_driver_create()``,
+which will create a driver with the given name, on the ``kunit_bus``. This driver
+will automatically be destroyed when the corresponding test finishes, but can also
+be manually destroyed with ``driver_unregister()``.
+
+To create a fake device, use the ``kunit_device_register()``, which will create
+and register a device, using a new KUnit-managed driver created with ``kunit_driver_create()``.
+To provide a specific, non-KUnit-managed driver, use ``kunit_device_register_with_driver()``
+instead. Like with managed drivers, KUnit-managed fake devices are automatically
+cleaned up when the test finishes, but can be manually cleaned up early with
+``kunit_device_unregister()``.
+
+The KUnit devices should be used in preference to ``root_device_register()``, and
+instead of ``platform_device_register()`` in cases where the device is not otherwise
+a platform device.
+
+For example:
+
+.. code-block:: c
+
+ #include <kunit/device.h>
+
+ static void test_my_device(struct kunit *test)
+ {
+ struct device *fake_device;
+ const char *dev_managed_string;
+
+ // Create a fake device.
+ fake_device = kunit_device_register(test, "my_device");
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fake_device)
+
+ // Pass it to functions which need a device.
+ dev_managed_string = devm_kstrdup(fake_device, "Hello, World!");
+
+ // Everything is cleaned up automatically when the test ends.
+ } \ No newline at end of file
diff --git a/Documentation/dev-tools/lkmm/docs/access-marking.rst b/Documentation/dev-tools/lkmm/docs/access-marking.rst
new file mode 100644
index 000000000000..80058a4da980
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/access-marking.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Access Marking
+--------------
+
+Literal include of ``tools/memory-model/Documentation/access-marking.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/access-marking.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/cheatsheet.rst b/Documentation/dev-tools/lkmm/docs/cheatsheet.rst
new file mode 100644
index 000000000000..37681f6a6a8c
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/cheatsheet.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Cheatsheet
+----------
+
+Literal include of ``tools/memory-model/Documentation/cheatsheet.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/cheatsheet.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/control-dependencies.rst b/Documentation/dev-tools/lkmm/docs/control-dependencies.rst
new file mode 100644
index 000000000000..5ae97e8861eb
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/control-dependencies.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Control Dependencies
+--------------------
+
+Literal include of ``tools/memory-model/Documentation/control-dependencies.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/control-dependencies.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/explanation.rst b/Documentation/dev-tools/lkmm/docs/explanation.rst
new file mode 100644
index 000000000000..0bcba9a5ddf7
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/explanation.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Explanation
+-----------
+
+Literal include of ``tools/memory-model/Documentation/explanation.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/explanation.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/glossary.rst b/Documentation/dev-tools/lkmm/docs/glossary.rst
new file mode 100644
index 000000000000..849aefdf3d6e
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/glossary.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Glossary
+--------
+
+Literal include of ``tools/memory-model/Documentation/glossary.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/glossary.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/herd-representation.rst b/Documentation/dev-tools/lkmm/docs/herd-representation.rst
new file mode 100644
index 000000000000..f7b41f286eb9
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/herd-representation.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+herd-representation
+-------------------
+
+Literal include of ``tools/memory-model/Documentation/herd-representation.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/herd-representation.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/index.rst b/Documentation/dev-tools/lkmm/docs/index.rst
new file mode 100644
index 000000000000..abbddcc009de
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/index.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Documentation
+=============
+
+.. toctree::
+ :maxdepth: 1
+
+ readme
+ simple
+ ordering
+ litmus-tests
+ locking
+ recipes
+ control-dependencies
+ access-marking
+ cheatsheet
+ explanation
+ herd-representation
+ glossary
+ references
diff --git a/Documentation/dev-tools/lkmm/docs/litmus-tests.rst b/Documentation/dev-tools/lkmm/docs/litmus-tests.rst
new file mode 100644
index 000000000000..3293f4540156
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/litmus-tests.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Litmus Tests
+------------
+
+Literal include of ``tools/memory-model/Documentation/litmus-tests.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/litmus-tests.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/locking.rst b/Documentation/dev-tools/lkmm/docs/locking.rst
new file mode 100644
index 000000000000..b5eae4c0acb7
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/locking.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Locking
+-------
+
+Literal include of ``tools/memory-model/Documentation/locking.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/locking.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/ordering.rst b/Documentation/dev-tools/lkmm/docs/ordering.rst
new file mode 100644
index 000000000000..a2343c12462d
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/ordering.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Ordering
+--------
+
+Literal include of ``tools/memory-model/Documentation/ordering.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/ordering.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/readme.rst b/Documentation/dev-tools/lkmm/docs/readme.rst
new file mode 100644
index 000000000000..51e7a64e4435
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/readme.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+README (for LKMM Documentation)
+-------------------------------
+
+Literal include of ``tools/memory-model/Documentation/README``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/README
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/recipes.rst b/Documentation/dev-tools/lkmm/docs/recipes.rst
new file mode 100644
index 000000000000..e55952640047
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/recipes.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Recipes
+-------
+
+Literal include of ``tools/memory-model/Documentation/recipes.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/recipes.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/references.rst b/Documentation/dev-tools/lkmm/docs/references.rst
new file mode 100644
index 000000000000..c6831b3c9c02
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/references.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+References
+----------
+
+Literal include of ``tools/memory-model/Documentation/references.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/references.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/docs/simple.rst b/Documentation/dev-tools/lkmm/docs/simple.rst
new file mode 100644
index 000000000000..5c1094c95f45
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/docs/simple.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Simple
+------
+
+Literal include of ``tools/memory-model/Documentation/simple.txt``.
+
+------------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/Documentation/simple.txt
+ :literal:
diff --git a/Documentation/dev-tools/lkmm/index.rst b/Documentation/dev-tools/lkmm/index.rst
new file mode 100644
index 000000000000..e52782449ca3
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/index.rst
@@ -0,0 +1,15 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================================
+Linux Kernel Memory Consistency Model (LKMM)
+============================================
+
+This section literally renders documents under ``tools/memory-model/``
+and ``tools/memory-model/Documentation/``, which are maintained in
+the *pure* plain text form.
+
+.. toctree::
+ :maxdepth: 2
+
+ readme
+ docs/index
diff --git a/Documentation/dev-tools/lkmm/readme.rst b/Documentation/dev-tools/lkmm/readme.rst
new file mode 100644
index 000000000000..a7f847109584
--- /dev/null
+++ b/Documentation/dev-tools/lkmm/readme.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+README (for LKMM)
+=================
+
+Literal include of ``tools/memory-model/README``.
+
+------------------------------------------------------------
+
+.. kernel-include:: tools/memory-model/README
+ :literal:
diff --git a/Documentation/dev-tools/propeller.rst b/Documentation/dev-tools/propeller.rst
new file mode 100644
index 000000000000..92195958e3db
--- /dev/null
+++ b/Documentation/dev-tools/propeller.rst
@@ -0,0 +1,162 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Using Propeller with the Linux kernel
+=====================================
+
+This enables Propeller build support for the kernel when using Clang
+compiler. Propeller is a profile-guided optimization (PGO) method used
+to optimize binary executables. Like AutoFDO, it utilizes hardware
+sampling to gather information about the frequency of execution of
+different code paths within a binary. Unlike AutoFDO, this information
+is then used right before linking phase to optimize (among others)
+block layout within and across functions.
+
+A few important notes about adopting Propeller optimization:
+
+#. Although it can be used as a standalone optimization step, it is
+ strongly recommended to apply Propeller on top of AutoFDO,
+ AutoFDO+ThinLTO or Instrument FDO. The rest of this document
+ assumes this paradigm.
+
+#. Propeller uses another round of profiling on top of
+ AutoFDO/AutoFDO+ThinLTO/iFDO. The whole build process involves
+ "build-afdo - train-afdo - build-propeller - train-propeller -
+ build-optimized".
+
+#. Propeller requires LLVM 19 release or later for Clang/Clang++
+ and the linker(ld.lld).
+
+#. In addition to LLVM toolchain, Propeller requires a profiling
+ conversion tool: https://github.com/google/autofdo with a release
+ after v0.30.1: https://github.com/google/autofdo/releases/tag/v0.30.1.
+
+The Propeller optimization process involves the following steps:
+
+#. Initial building: Build the AutoFDO or AutoFDO+ThinLTO binary as
+ you would normally do, but with a set of compile-time / link-time
+ flags, so that a special metadata section is created within the
+ kernel binary. The special section is only intend to be used by the
+ profiling tool, it is not part of the runtime image, nor does it
+ change kernel run time text sections.
+
+#. Profiling: The above kernel is then run with a representative
+ workload to gather execution frequency data. This data is collected
+ using hardware sampling, via perf. Propeller is most effective on
+ platforms supporting advanced PMU features like LBR on Intel
+ machines. This step is the same as profiling the kernel for AutoFDO
+ (the exact perf parameters can be different).
+
+#. Propeller profile generation: Perf output file is converted to a
+ pair of Propeller profiles via an offline tool.
+
+#. Optimized build: Build the AutoFDO or AutoFDO+ThinLTO optimized
+ binary as you would normally do, but with a compile-time /
+ link-time flag to pick up the Propeller compile time and link time
+ profiles. This build step uses 3 profiles - the AutoFDO profile,
+ the Propeller compile-time profile and the Propeller link-time
+ profile.
+
+#. Deployment: The optimized kernel binary is deployed and used
+ in production environments, providing improved performance
+ and reduced latency.
+
+Preparation
+===========
+
+Configure the kernel with::
+
+ CONFIG_AUTOFDO_CLANG=y
+ CONFIG_PROPELLER_CLANG=y
+
+Customization
+=============
+
+The default CONFIG_PROPELLER_CLANG setting covers kernel space objects
+for Propeller builds. One can, however, enable or disable Propeller build
+for individual files and directories by adding a line similar to the
+following to the respective kernel Makefile:
+
+- For enabling a single file (e.g. foo.o)::
+
+ PROPELLER_PROFILE_foo.o := y
+
+- For enabling all files in one directory::
+
+ PROPELLER_PROFILE := y
+
+- For disabling one file::
+
+ PROPELLER_PROFILE_foo.o := n
+
+- For disabling all files in one directory::
+
+ PROPELLER__PROFILE := n
+
+
+Workflow
+========
+
+Here is an example workflow for building an AutoFDO+Propeller kernel:
+
+1) Assuming an AutoFDO profile is already collected following
+ instructions in the AutoFDO document, build the kernel on the host
+ machine, with AutoFDO and Propeller build configs ::
+
+ CONFIG_AUTOFDO_CLANG=y
+ CONFIG_PROPELLER_CLANG=y
+
+ and ::
+
+ $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo-profile-name>
+
+2) Install the kernel on the test machine.
+
+3) Run the load tests. The '-c' option in perf specifies the sample
+ event period. We suggest using a suitable prime number, like 500009,
+ for this purpose.
+
+ - For Intel platforms::
+
+ $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
+
+ - For AMD platforms::
+
+ $ perf record --pfm-event RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
+
+ Note you can repeat the above steps to collect multiple <perf_file>s.
+
+4) (Optional) Download the raw perf file(s) to the host machine.
+
+5) Use the create_llvm_prof tool (https://github.com/google/autofdo) to
+ generate Propeller profile. ::
+
+ $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file>
+ --format=propeller --propeller_output_module_name
+ --out=<propeller_profile_prefix>_cc_profile.txt
+ --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
+
+ "<propeller_profile_prefix>" can be something like "/home/user/dir/any_string".
+
+ This command generates a pair of Propeller profiles:
+ "<propeller_profile_prefix>_cc_profile.txt" and
+ "<propeller_profile_prefix>_ld_profile.txt".
+
+ If there are more than 1 perf_file collected in the previous step,
+ you can create a temp list file "<perf_file_list>" with each line
+ containing one perf file name and run::
+
+ $ create_llvm_prof --binary=<vmlinux> --profile=@<perf_file_list>
+ --format=propeller --propeller_output_module_name
+ --out=<propeller_profile_prefix>_cc_profile.txt
+ --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
+
+6) Rebuild the kernel using the AutoFDO and Propeller
+ profiles. ::
+
+ CONFIG_AUTOFDO_CLANG=y
+ CONFIG_PROPELLER_CLANG=y
+
+ and ::
+
+ $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<profile_file> CLANG_PROPELLER_PROFILE_PREFIX=<propeller_profile_prefix>
diff --git a/Documentation/dev-tools/testing-devices.rst b/Documentation/dev-tools/testing-devices.rst
new file mode 100644
index 000000000000..ab26adb99051
--- /dev/null
+++ b/Documentation/dev-tools/testing-devices.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. Copyright (c) 2024 Collabora Ltd
+
+=============================
+Device testing with kselftest
+=============================
+
+
+There are a few different kselftests available for testing devices generically,
+with some overlap in coverage and different requirements. This document aims to
+give an overview of each one.
+
+Note: Paths in this document are relative to the kselftest folder
+(``tools/testing/selftests``).
+
+Device oriented kselftests:
+
+* Devicetree (``dt``)
+
+ * **Coverage**: Probe status for devices described in Devicetree
+ * **Requirements**: None
+
+* Error logs (``devices/error_logs``)
+
+ * **Coverage**: Error (or more critical) log messages presence coming from any
+ device
+ * **Requirements**: None
+
+* Discoverable bus (``devices/probe``)
+
+ * **Coverage**: Presence and probe status of USB or PCI devices that have been
+ described in the reference file
+ * **Requirements**: Manually describe the devices that should be tested in a
+ YAML reference file (see ``devices/probe/boards/google,spherion.yaml`` for
+ an example)
+
+* Exist (``devices/exist``)
+
+ * **Coverage**: Presence of all devices
+ * **Requirements**: Generate the reference (see ``devices/exist/README.rst``
+ for details) on a known-good kernel
+
+Therefore, the suggestion is to enable the error log and devicetree tests on all
+(DT-based) platforms, since they don't have any requirements. Then to greatly
+improve coverage, generate the reference for each platform and enable the exist
+test. The discoverable bus test can be used to verify the probe status of
+specific USB or PCI devices, but is probably not worth it for most cases.
diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst
index 0aaf6ea53608..1619e5e5cc9c 100644
--- a/Documentation/dev-tools/testing-overview.rst
+++ b/Documentation/dev-tools/testing-overview.rst
@@ -104,6 +104,8 @@ Some of these tools are listed below:
KASAN and can be used in production. See Documentation/dev-tools/kfence.rst
* lockdep is a locking correctness validator. See
Documentation/locking/lockdep-design.rst
+* Runtime Verification (RV) supports checking specific behaviours for a given
+ subsystem. See Documentation/trace/rv/runtime-verification.rst
* There are several other pieces of debug instrumentation in the kernel, many
of which can be found in lib/Kconfig.debug
diff --git a/Documentation/dev-tools/ubsan.rst b/Documentation/dev-tools/ubsan.rst
index 1be6618e232d..e3591f8e9d5b 100644
--- a/Documentation/dev-tools/ubsan.rst
+++ b/Documentation/dev-tools/ubsan.rst
@@ -1,5 +1,7 @@
-The Undefined Behavior Sanitizer - UBSAN
-========================================
+.. SPDX-License-Identifier: GPL-2.0
+
+Undefined Behavior Sanitizer - UBSAN
+====================================
UBSAN is a runtime undefined behaviour checker.
@@ -47,34 +49,22 @@ Report example
Usage
-----
-To enable UBSAN configure kernel with::
-
- CONFIG_UBSAN=y
-
-and to check the entire kernel::
-
- CONFIG_UBSAN_SANITIZE_ALL=y
-
-To enable instrumentation for specific files or directories, add a line
-similar to the following to the respective kernel Makefile:
+To enable UBSAN, configure the kernel with::
-- For a single file (e.g. main.o)::
+ CONFIG_UBSAN=y
- UBSAN_SANITIZE_main.o := y
-
-- For all files in one directory::
-
- UBSAN_SANITIZE := y
-
-To exclude files from being instrumented even if
-``CONFIG_UBSAN_SANITIZE_ALL=y``, use::
+To exclude files from being instrumented use::
UBSAN_SANITIZE_main.o := n
-and::
+and to exclude all targets in one directory use::
UBSAN_SANITIZE := n
+When disabled for all targets, specific files can be enabled using::
+
+ UBSAN_SANITIZE_main.o := y
+
Detection of unaligned accesses controlled through the separate option -
CONFIG_UBSAN_ALIGNMENT. It's off by default on architectures that support
unaligned accesses (CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y). One could
diff --git a/Documentation/devicetree/bindings/.gitignore b/Documentation/devicetree/bindings/.gitignore
index a77719968a7e..51ddb26d93f0 100644
--- a/Documentation/devicetree/bindings/.gitignore
+++ b/Documentation/devicetree/bindings/.gitignore
@@ -2,3 +2,8 @@
*.example.dts
/processed-schema*.yaml
/processed-schema*.json
+
+#
+# We don't want to ignore the following even if they are dot-files
+#
+!.yamllint
diff --git a/Documentation/devicetree/bindings/.yamllint b/Documentation/devicetree/bindings/.yamllint
index 214abd3ec440..8f9dd18dfe04 100644
--- a/Documentation/devicetree/bindings/.yamllint
+++ b/Documentation/devicetree/bindings/.yamllint
@@ -1,6 +1,11 @@
extends: relaxed
rules:
+ quoted-strings:
+ required: only-when-needed
+ extra-allowed:
+ - '[$^[]'
+ - '^/$'
line-length:
# 80 chars should be enough, but don't fail if a line is longer
max: 110
@@ -19,13 +24,13 @@ rules:
colons: {max-spaces-before: 0, max-spaces-after: 1}
commas: {min-spaces-after: 1, max-spaces-after: 1}
comments:
- require-starting-space: false
+ require-starting-space: true
min-spaces-from-content: 1
comments-indentation: disable
document-start:
present: true
empty-lines:
- max: 3
+ max: 1
max-end: 1
empty-values:
forbid-in-block-mappings: true
diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
index 1eaccf135b30..8d6f85f4455d 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
DT_SCHEMA_LINT = $(shell which yamllint || \
echo "warning: python package 'yamllint' not installed, skipping" >&2)
-DT_SCHEMA_MIN_VERSION = 2022.3
+DT_SCHEMA_MIN_VERSION = 2023.9
PHONY += check_dtschema_version
check_dtschema_version:
@@ -25,20 +25,26 @@ quiet_cmd_extract_ex = DTEX $@
$(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE
$(call if_changed,extract_ex)
-find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
+find_all_cmd = find $(src) \( -name '*.yaml' ! \
-name 'processed-schema*' \)
-find_cmd = $(find_all_cmd) | grep -F "$(DT_SCHEMA_FILES)"
-CHK_DT_DOCS := $(shell $(find_cmd))
+find_cmd = $(find_all_cmd) | \
+ sed 's|^$(srctree)/||' | \
+ grep -F -e "$(subst :," -e ",$(DT_SCHEMA_FILES))" | \
+ sed 's|^|$(srctree)/|'
+CHK_DT_EXAMPLES := $(patsubst $(srctree)/%.yaml,%.example.dtb, \
+ $(shell $(find_cmd) | xargs grep -l '^examples:'))
quiet_cmd_yamllint = LINT $(src)
cmd_yamllint = ($(find_cmd) | \
xargs -n200 -P$$(nproc) \
- $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true
+ $(DT_SCHEMA_LINT) -f parsable -c $(src)/.yamllint >&2) \
+ && touch $@ || true
-quiet_cmd_chk_bindings = CHKDT $@
+quiet_cmd_chk_bindings = CHKDT $(src)
cmd_chk_bindings = ($(find_cmd) | \
- xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(srctree)/$(src)) || true
+ xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(src)) \
+ && touch $@ || true
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = f=$$(mktemp) ; \
@@ -46,32 +52,35 @@ quiet_cmd_mk_schema = SCHEMA $@
$(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \
rm -f $$f
-define rule_chkdt
- $(if $(DT_SCHEMA_LINT),$(call cmd,yamllint),)
- $(call cmd,chk_bindings)
- $(call cmd,mk_schema)
-endef
-
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
override DTC_FLAGS := \
-Wno-avoid_unnecessary_addr_size \
-Wno-graph_child_address \
- -Wno-interrupt_provider \
-Wno-unique_unit_address \
-Wunique_unit_address_if_enabled
-# Disable undocumented compatible checks until warning free
-override DT_CHECKER_FLAGS ?=
+$(obj)/processed-schema.json: $(DT_DOCS) check_dtschema_version FORCE
+ $(call if_changed,mk_schema)
+
+targets += .dt-binding.checked .yamllint.checked
+$(obj)/.yamllint.checked: $(DT_DOCS) $(src)/.yamllint FORCE
+ $(if $(DT_SCHEMA_LINT),$(call if_changed,yamllint),)
-$(obj)/processed-schema.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE
- $(call if_changed_rule,chkdt)
+$(obj)/.dt-binding.checked: $(DT_DOCS) FORCE
+ $(call if_changed,chk_bindings)
always-y += processed-schema.json
-always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dts, $(CHK_DT_DOCS))
-always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dtb, $(CHK_DT_DOCS))
+targets += $(patsubst $(obj)/%,%, $(CHK_DT_EXAMPLES))
+targets += $(patsubst $(obj)/%.dtb,%.dts, $(CHK_DT_EXAMPLES))
# Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of
# build artifacts here before they are processed by scripts/Makefile.clean
clean-files = $(shell find $(obj) \( -name '*.example.dts' -o \
-name '*.example.dtb' \) -delete 2>/dev/null)
+
+dt_compatible_check: $(obj)/processed-schema.json
+ $(Q)$(srctree)/scripts/dtc/dt-extract-compatibles $(srctree) | xargs dt-check-compatible -v -s $<
+
+PHONY += dt_binding_check
+dt_binding_check: $(obj)/.dt-binding.checked $(obj)/.yamllint.checked $(CHK_DT_EXAMPLES)
diff --git a/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
new file mode 100644
index 000000000000..99e2865f0e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Domain Access Controllers
+
+maintainers:
+ - Oleksii Moisieiev <oleksii_moisieiev@epam.com>
+
+description: |+
+ Common access controllers properties
+
+ Access controllers are in charge of stating which of the hardware blocks under
+ their responsibility (their domain) can be accesssed by which compartment. A
+ compartment can be a cluster of CPUs (or coprocessors), a range of addresses
+ or a group of hardware blocks. An access controller's domain is the set of
+ resources covered by the access controller.
+
+ This device tree binding can be used to bind devices to their access
+ controller provided by access-controllers property. In this case, the device
+ is a consumer and the access controller is the provider.
+
+ An access controller can be represented by any node in the device tree and
+ can provide one or more configuration parameters, needed to control parameters
+ of the consumer device. A consumer node can refer to the provider by phandle
+ and a set of phandle arguments, specified by '#access-controller-cells'
+ property in the access controller node.
+
+ Access controllers are typically used to set/read the permissions of a
+ hardware block and grant access to it. Any of which depends on the access
+ controller. The capabilities of each access controller are defined by the
+ binding of the access controller device.
+
+ Each node can be a consumer for the several access controllers.
+
+# always select the core schema
+select: true
+
+properties:
+ "#access-controller-cells":
+ description:
+ Number of cells in an access-controllers specifier;
+ Can be any value as specified by device tree binding documentation
+ of a particular provider. The node is an access controller.
+
+ access-controller-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ A list of access-controllers names, sorted in the same order as
+ access-controllers entries. Consumer drivers will use
+ access-controller-names to match with existing access-controllers entries.
+
+ access-controllers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ A list of access controller specifiers, as defined by the
+ bindings of the access-controllers provider.
+
+additionalProperties: true
+
+examples:
+ - |
+ clock_controller: access-controllers@50000 {
+ reg = <0x50000 0x400>;
+ #access-controller-cells = <2>;
+ };
+
+ bus_controller: bus@60000 {
+ reg = <0x60000 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ #access-controller-cells = <3>;
+
+ uart4: serial@60100 {
+ reg = <0x60100 0x400>;
+ clocks = <&clk_serial>;
+ access-controllers = <&clock_controller 1 2>,
+ <&bus_controller 1 3 5>;
+ access-controller-names = "clock", "bus";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arc/archs-pct.txt b/Documentation/devicetree/bindings/arc/archs-pct.txt
deleted file mode 100644
index e4b9dcee6d41..000000000000
--- a/Documentation/devicetree/bindings/arc/archs-pct.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* ARC HS Performance Counters
-
-The ARC HS can be configured with a pipeline performance monitor for counting
-CPU and cache events like cache misses and hits. Like conventional PCT there
-are 100+ hardware conditions dynamically mapped to up to 32 counters.
-It also supports overflow interrupts.
-
-Required properties:
-
-- compatible : should contain
- "snps,archs-pct"
-
-Example:
-
-pmu {
- compatible = "snps,archs-pct";
-};
diff --git a/Documentation/devicetree/bindings/arc/snps,archs-pct.yaml b/Documentation/devicetree/bindings/arc/snps,archs-pct.yaml
new file mode 100644
index 000000000000..532f7584f59f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arc/snps,archs-pct.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arc/snps,archs-pct.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARC HS Performance Counters
+
+maintainers:
+ - Aryabhatta Dey <aryabhattadey35@gmail.com>
+
+description:
+ The ARC HS can be configured with a pipeline performance monitor for counting
+ CPU and cache events like cache misses and hits. Like conventional PCT there
+ are 100+ hardware conditions dynamically mapped to up to 32 counters.
+ It also supports overflow interrupts.
+
+properties:
+ compatible:
+ const: snps,archs-pct
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
index 02dc72c97645..e012f612f039 100644
--- a/Documentation/devicetree/bindings/arm/actions.yaml
+++ b/Documentation/devicetree/bindings/arm/actions.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/actions.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Actions Semi platforms device tree bindings
+title: Actions Semi platforms
maintainers:
- Andreas Färber <afaerber@suse.de>
diff --git a/Documentation/devicetree/bindings/arm/airoha,en7581-chip-scu.yaml b/Documentation/devicetree/bindings/arm/airoha,en7581-chip-scu.yaml
new file mode 100644
index 000000000000..67c449d804c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/airoha,en7581-chip-scu.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/airoha,en7581-chip-scu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha Chip SCU Controller for EN7581 SoC
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The airoha chip-scu block provides a configuration interface for clock,
+ io-muxing and other functionalities used by multiple controllers (e.g. clock,
+ pinctrl, ecc) on EN7581 SoC.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - airoha,en7581-chip-scu
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ syscon@1fa20000 {
+ compatible = "airoha,en7581-chip-scu", "syscon";
+ reg = <0x0 0x1fa20000 0x0 0x388>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/airoha.yaml b/Documentation/devicetree/bindings/arm/airoha.yaml
index fc19b1a6f37b..7c38c08dbf3f 100644
--- a/Documentation/devicetree/bindings/arm/airoha.yaml
+++ b/Documentation/devicetree/bindings/arm/airoha.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/airoha.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Airoha SoC based Platforms Device Tree Bindings
+title: Airoha SoC based Platforms
maintainers:
- Felix Fietkau <nbd@nbd.name>
@@ -22,6 +22,10 @@ properties:
- enum:
- airoha,en7523-evb
- const: airoha,en7523
+ - items:
+ - enum:
+ - airoha,en7581-evb
+ - const: airoha,en7581
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index e6de1d7f516c..db61537b7115 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/altera.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Altera's SoCFPGA platform device tree bindings
+title: Altera's SoCFPGA platform
maintainers:
- Dinh Nguyen <dinguyen@kernel.org>
@@ -31,6 +31,9 @@ properties:
- description: Mercury+ AA1 boards
items:
- enum:
+ - enclustra,mercury-aa1-pe1
+ - enclustra,mercury-aa1-pe3
+ - enclustra,mercury-aa1-st1
- google,chameleon-v3
- const: enclustra,mercury-aa1
- const: altr,socfpga-arria10
@@ -46,10 +49,31 @@ properties:
- novtech,chameleon96
- samtec,vining
- terasic,de0-atlas
+ - terasic,de10-nano
- terasic,socfpga-cyclone5-sockit
- const: altr,socfpga-cyclone5
- const: altr,socfpga
+ - description: Mercury SA1 boards
+ items:
+ - enum:
+ - enclustra,mercury-sa1-pe1
+ - enclustra,mercury-sa1-pe3
+ - enclustra,mercury-sa1-st1
+ - const: enclustra,mercury-sa1
+ - const: altr,socfpga-cyclone5
+ - const: altr,socfpga
+
+ - description: Mercury+ SA2 boards
+ items:
+ - enum:
+ - enclustra,mercury-sa2-pe1
+ - enclustra,mercury-sa2-pe3
+ - enclustra,mercury-sa2-st1
+ - const: enclustra,mercury-sa2
+ - const: altr,socfpga-cyclone5
+ - const: altr,socfpga
+
- description: Stratix 10 boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
index 572381306681..4683bd1293fa 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
@@ -9,20 +9,120 @@ title: Altera SOCFPGA Clock Manager
maintainers:
- Dinh Nguyen <dinguyen@kernel.org>
-description: test
+description:
+ This binding describes the Altera SOCFGPA Clock Manager and its associated
+ tree of clocks, pll's, and clock gates for the Cyclone5, Arria5 and Arria10
+ chip families.
properties:
compatible:
items:
- const: altr,clk-mgr
+
reg:
maxItems: 1
+ clocks:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^osc[0-9]$':
+ type: object
+
+ '^[a-z0-9,_]+(clk|pll|clk_gate|clk_divided)(@[a-f0-9]+)?$':
+ type: object
+ $ref: '#/$defs/clock-props'
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - altr,socfpga-pll-clock
+ - altr,socfpga-perip-clk
+ - altr,socfpga-gate-clk
+ - altr,socfpga-a10-pll-clock
+ - altr,socfpga-a10-perip-clk
+ - altr,socfpga-a10-gate-clk
+ - fixed-clock
+
+ clocks:
+ description: one or more phandles to input clock
+ minItems: 1
+ maxItems: 5
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^[a-z0-9,_]+(clk|pll)(@[a-f0-9]+)?$':
+ type: object
+ $ref: '#/$defs/clock-props'
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - altr,socfpga-perip-clk
+ - altr,socfpga-gate-clk
+ - altr,socfpga-a10-perip-clk
+ - altr,socfpga-a10-gate-clk
+
+ clocks:
+ description: one or more phandles to input clock
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - compatible
+ - clocks
+ - '#clock-cells'
+
+ required:
+ - compatible
+ - '#clock-cells'
+
required:
- compatible
+ - reg
additionalProperties: false
+$defs:
+ clock-props:
+ properties:
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ clk-gate:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: gating register offset
+ - description: bit index
+
+ div-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: divider register offset
+ - description: bit shift
+ - description: bit width
+
+ fixed-divider:
+ $ref: /schemas/types.yaml#/definitions/uint32
+
examples:
- |
clkmgr@ffd04000 {
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
deleted file mode 100644
index 77ca635765e1..000000000000
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Altera SOCFPGA SDRAM Controller
-
-Required properties:
-- compatible : Should contain "altr,sdr-ctl" and "syscon".
- syscon is required by the Altera SOCFPGA SDRAM EDAC.
-- reg : Should contain 1 register range (address and length)
-
-Example:
- sdr: sdr@ffc25000 {
- compatible = "altr,sdr-ctl", "syscon";
- reg = <0xffc25000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
deleted file mode 100644
index f5ad0ff69fae..000000000000
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Altera SOCFPGA SDRAM Error Detection & Correction [EDAC]
-The EDAC accesses a range of registers in the SDRAM controller.
-
-Required properties:
-- compatible : should contain "altr,sdram-edac" or "altr,sdram-edac-a10"
-- altr,sdr-syscon : phandle of the sdr module
-- interrupts : Should contain the SDRAM ECC IRQ in the
- appropriate format for the IRQ controller.
-
-Example:
- sdramedac {
- compatible = "altr,sdram-edac";
- altr,sdr-syscon = <&sdr>;
- interrupts = <0 39 4>;
- };
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
deleted file mode 100644
index 82edbaaa3f85..000000000000
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Altera SOCFPGA System Manager
-
-Required properties:
-- compatible : "altr,sys-mgr"
-- reg : Should contain 1 register ranges(address and length)
-- cpu1-start-addr : CPU1 start address in hex.
-
-Example:
- sysmgr@ffd08000 {
- compatible = "altr,sys-mgr";
- reg = <0xffd08000 0x1000>;
- cpu1-start-addr = <0xffd080c4>;
- };
-
-ARM64 - Stratix10
-Required properties:
-- compatible : "altr,sys-mgr-s10"
-- reg : Should contain 1 register range(address and length)
- for system manager register.
-
-Example:
- sysmgr@ffd12000 {
- compatible = "altr,sys-mgr-s10";
- reg = <0xffd12000 0x228>;
- };
diff --git a/Documentation/devicetree/bindings/arm/amazon,al.yaml b/Documentation/devicetree/bindings/arm/amazon,al.yaml
index 0f03135d91b6..37dbb4768e5b 100644
--- a/Documentation/devicetree/bindings/arm/amazon,al.yaml
+++ b/Documentation/devicetree/bindings/arm/amazon,al.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/amazon,al.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Amazon's Annapurna Labs Alpine Platform Device Tree Bindings
+title: Amazon's Annapurna Labs Alpine Platform
maintainers:
- Hanna Hawa <hhhawa@amazon.com>
diff --git a/Documentation/devicetree/bindings/arm/amd,pensando.yaml b/Documentation/devicetree/bindings/arm/amd,pensando.yaml
new file mode 100644
index 000000000000..e5c2591834a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amd,pensando.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/amd,pensando.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Pensando SoC Platforms
+
+maintainers:
+ - Brad Larson <blarson@amd.com>
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+
+ - description: Boards with Pensando Elba SoC
+ items:
+ - enum:
+ - amd,pensando-elba-ortano
+ - const: amd,pensando-elba
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/amd,seattle.yaml b/Documentation/devicetree/bindings/arm/amd,seattle.yaml
new file mode 100644
index 000000000000..7a3fc05b19eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amd,seattle.yaml
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/amd,seattle.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Seattle SoC Platforms
+
+maintainers:
+ - Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+ - Tom Lendacky <thomas.lendacky@amd.com>
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - description: Boards with AMD Seattle SoC
+ items:
+ - const: amd,seattle-overdrive
+ - const: amd,seattle
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index f5c1b6cae4c9..08d9963fe925 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -4,22 +4,14 @@
$id: http://devicetree.org/schemas/arm/amlogic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Amlogic MesonX device tree bindings
+title: Amlogic SoC based Platforms
maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ - Jerome Brunet <jbrunet@baylibre.com>
- Kevin Hilman <khilman@baylibre.com>
-description: |+
- Work in progress statement:
-
- Device tree files and bindings applying to Amlogic SoCs and boards are
- considered "unstable". Any Amlogic device tree binding may change at
- any time. Be sure to use a device tree binary and a kernel image
- generated from the same source tree.
-
- Please refer to Documentation/devicetree/bindings/ABI.rst for a definition of a
- stable binding/ABI.
-
properties:
$nodename:
const: '/'
@@ -35,6 +27,7 @@ properties:
items:
- enum:
- minix,neo-x8
+ - tcu,fernsehfee3
- const: amlogic,meson8
- description: Boards with the Amlogic Meson8m2 SoC
@@ -81,6 +74,13 @@ properties:
- const: amlogic,s805x
- const: amlogic,meson-gxl
+ - description: Boards with the Amlogic Meson GXL S805Y SoC
+ items:
+ - enum:
+ - xiaomi,aquaman
+ - const: amlogic,s805y
+ - const: amlogic,meson-gxl
+
- description: Boards with the Amlogic Meson GXL S905W SoC
items:
- enum:
@@ -99,6 +99,7 @@ properties:
- libretech,aml-s905x-cc
- libretech,aml-s905x-cc-v2
- nexbox,a95x
+ - osmc,vero4k
- const: amlogic,s905x
- const: amlogic,meson-gxl
@@ -115,6 +116,13 @@ properties:
- const: amlogic,s905d
- const: amlogic,meson-gxl
+ - description: Boards with the Amlogic Meson GXLX S905L SoC
+ items:
+ - enum:
+ - amlogic,p271
+ - const: amlogic,s905l
+ - const: amlogic,meson-gxlx
+
- description: Boards with the Amlogic Meson GXM S912 SoC
items:
- enum:
@@ -126,7 +134,9 @@ properties:
- libretech,aml-s912-pc
- minix,neo-u9h
- nexbox,a1
+ - oranth,tx9-pro
- tronsmart,vega-s96
+ - ugoos,am3
- videostrong,gxm-kiii-pro
- wetek,core2
- const: amlogic,s912
@@ -146,6 +156,7 @@ properties:
- enum:
- amediatech,x96-max
- amlogic,u200
+ - freebox,fbx8am
- radxa,zero
- seirobotics,sei510
- const: amlogic,g12a
@@ -153,7 +164,19 @@ properties:
- description: Boards with the Amlogic Meson G12B A311D SoC
items:
- enum:
+ - bananapi,bpi-m2s
- khadas,vim3
+ - libretech,aml-a311d-cc
+ - radxa,zero2
+ - const: amlogic,a311d
+ - const: amlogic,g12b
+
+ - description: Boards using the BPI-CM4 module with Amlogic Meson G12B A311D SoC
+ items:
+ - enum:
+ - bananapi,bpi-cm4io
+ - mntre,reform2-cm4
+ - const: bananapi,bpi-cm4
- const: amlogic,a311d
- const: amlogic,g12b
@@ -163,7 +186,12 @@ properties:
- azw,gsking-x
- azw,gtking
- azw,gtking-pro
+ - bananapi,bpi-m2s
+ - dream,dreambox-one
+ - dream,dreambox-two
+ - hardkernel,odroid-go-ultra
- hardkernel,odroid-n2
+ - hardkernel,odroid-n2l
- hardkernel,odroid-n2-plus
- khadas,vim3
- ugoos,am6
@@ -175,6 +203,7 @@ properties:
- enum:
- amediatech,x96-air
- amediatech,x96-air-gbit
+ - bananapi,bpi-m2-pro
- bananapi,bpi-m5
- cyx,a95xf3-air
- cyx,a95xf3-air-gbit
@@ -182,6 +211,7 @@ properties:
- hardkernel,odroid-hc4
- haochuangyi,h96-max
- khadas,vim3l
+ - libretech,aml-s905d3-cc
- seirobotics,sei610
- const: amlogic,sm1
@@ -189,14 +219,60 @@ properties:
items:
- enum:
- amlogic,ad401
+ - amlogic,ad402
- const: amlogic,a1
+ - description: Boards with the Amlogic A4 A113L2 SoC
+ items:
+ - enum:
+ - amlogic,ba400
+ - const: amlogic,a4
+
+ - description: Boards with the Amlogic A5 A113X2 SoC
+ items:
+ - enum:
+ - amlogic,av400
+ - const: amlogic,a5
+
+ - description: Boards with the Amlogic C3 C302X/C308L SoC
+ items:
+ - enum:
+ - amlogic,aw409
+ - amlogic,aw419
+ - const: amlogic,c3
+
- description: Boards with the Amlogic Meson S4 S805X2 SoC
items:
- enum:
- amlogic,aq222
- const: amlogic,s4
+ - description: Boards with the Amlogic S6 S905X5 SoC
+ items:
+ - enum:
+ - amlogic,bl209
+ - const: amlogic,s6
+
+ - description: Boards with the Amlogic S7 S805X3 SoC
+ items:
+ - enum:
+ - amlogic,bp201
+ - const: amlogic,s7
+
+ - description: Boards with the Amlogic S7D S905X5M SoC
+ items:
+ - enum:
+ - amlogic,bm202
+ - const: amlogic,s7d
+
+ - description: Boards with the Amlogic T7 A311D2 SoC
+ items:
+ - enum:
+ - amlogic,an400
+ - khadas,vim4
+ - const: amlogic,a311d2
+ - const: amlogic,t7
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
index 1748f1605cc7..fa7c403c874a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson Firmware registers Interface
@@ -25,10 +25,21 @@ select:
properties:
compatible:
- items:
- - const: amlogic,meson-gx-ao-secure
- - const: syscon
-
+ oneOf:
+ - items:
+ - const: amlogic,meson-gx-ao-secure
+ - const: syscon
+ - items:
+ - enum:
+ - amlogic,a4-ao-secure
+ - amlogic,c3-ao-secure
+ - amlogic,s4-ao-secure
+ - amlogic,s6-ao-secure
+ - amlogic,s7-ao-secure
+ - amlogic,s7d-ao-secure
+ - amlogic,t7-ao-secure
+ - const: amlogic,meson-gx-ao-secure
+ - const: syscon
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
index eee7cda9f91b..09b27e98d4c9 100644
--- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface
diff --git a/Documentation/devicetree/bindings/arm/amlogic/analog-top.txt b/Documentation/devicetree/bindings/arm/amlogic/analog-top.txt
deleted file mode 100644
index 101dc21014ec..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/analog-top.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Amlogic Meson8 and Meson8b "analog top" registers:
---------------------------------------------------
-
-The analog top registers contain information about the so-called
-"metal revision" (which encodes the "minor version") of the SoC.
-
-Required properties:
-- reg: the register range of the analog top registers
-- compatible: depending on the SoC this should be one of:
- - "amlogic,meson8-analog-top"
- - "amlogic,meson8b-analog-top"
- along with "syscon"
-
-
-Example:
-
- analog_top: analog-top@81a8 {
- compatible = "amlogic,meson8-analog-top", "syscon";
- reg = <0x81a8 0x14>;
- };
diff --git a/Documentation/devicetree/bindings/arm/amlogic/assist.txt b/Documentation/devicetree/bindings/arm/amlogic/assist.txt
deleted file mode 100644
index 7656812b67b9..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/assist.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Amlogic Meson6/Meson8/Meson8b assist registers:
------------------------------------------------
-
-The assist registers contain basic information about the SoC,
-for example the encoded SoC part number.
-
-Required properties:
-- reg: the register range of the assist registers
-- compatible: should be "amlogic,meson-mx-assist" along with "syscon"
-
-
-Example:
-
- assist: assist@7c00 {
- compatible = "amlogic,meson-mx-assist", "syscon";
- reg = <0x7c00 0x200>;
- };
diff --git a/Documentation/devicetree/bindings/arm/amlogic/bootrom.txt b/Documentation/devicetree/bindings/arm/amlogic/bootrom.txt
deleted file mode 100644
index 407e27f230ab..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/bootrom.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Amlogic Meson6/Meson8/Meson8b bootrom:
---------------------------------------
-
-The bootrom register area can be used to access SoC specific
-information, such as the "misc version".
-
-Required properties:
-- reg: the register range of the bootrom registers
-- compatible: should be "amlogic,meson-mx-bootrom" along with "syscon"
-
-
-Example:
-
- bootrom: bootrom@d9040000 {
- compatible = "amlogic,meson-mx-bootrom", "syscon";
- reg = <0xd9040000 0x10000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/amlogic/pmu.txt b/Documentation/devicetree/bindings/arm/amlogic/pmu.txt
deleted file mode 100644
index 72f8d08198b6..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/pmu.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Amlogic Meson8 and Meson8b power-management-unit:
--------------------------------------------------
-
-The pmu is used to turn off and on different power domains of the SoCs
-This includes the power to the CPU cores.
-
-Required node properties:
-- compatible value : depending on the SoC this should be one of:
- "amlogic,meson8-pmu"
- "amlogic,meson8b-pmu"
-- reg : physical base address and the size of the registers window
-
-Example:
-
- pmu@c81000e4 {
- compatible = "amlogic,meson8b-pmu", "syscon";
- reg = <0xc81000e0 0x18>;
- };
diff --git a/Documentation/devicetree/bindings/arm/apm.yaml b/Documentation/devicetree/bindings/arm/apm.yaml
new file mode 100644
index 000000000000..ea0d362cea3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apm.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/apm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC Platforms
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - description: Boards with X-Gene1 Soc
+ items:
+ - const: apm,mustang
+ - const: apm,xgene-storm
+
+ - description: Boards with X-Gene2 SoC
+ items:
+ - const: apm,merlin
+ - const: apm,xgene-shadowcat
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt b/Documentation/devicetree/bindings/arm/apm/scu.txt
deleted file mode 100644
index b45be06625fd..000000000000
--- a/Documentation/devicetree/bindings/arm/apm/scu.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-APM X-GENE SoC series SCU Registers
-
-This system clock unit contain various register that control block resets,
-clock enable/disables, clock divisors and other deepsleep registers.
-
-Properties:
- - compatible : should contain two values. First value must be:
- - "apm,xgene-scu"
- second value must be always "syscon".
-
- - reg : offset and length of the register set.
-
-Example :
- scu: system-clk-controller@17000000 {
- compatible = "apm,xgene-scu","syscon";
- reg = <0x0 0x17000000 0x0 0x400>;
- };
diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml
index 8d93e8a6cc18..5c2629ec3d4c 100644
--- a/Documentation/devicetree/bindings/arm/apple.yaml
+++ b/Documentation/devicetree/bindings/arm/apple.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/apple.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Apple ARM Machine Device Tree Bindings
+title: Apple ARM Machine
maintainers:
- Hector Martin <marcan@marcan.st>
@@ -12,19 +12,109 @@ maintainers:
description: |
ARM platforms using SoCs designed by Apple Inc., branded "Apple Silicon".
- This currently includes devices based on the "M1" SoC:
+ This currently includes devices based on the "A7" SoC:
+
+ - iPhone 5s
+ - iPad Air (1)
+ - iPad mini 2
+ - iPad mini 3
+
+ Devices based on the "A8" SoC:
+
+ - iPhone 6
+ - iPhone 6 Plus
+ - iPad mini 4
+ - iPod touch 6
+ - Apple TV HD
+
+ Device based on the "A8X" SoC:
+
+ - iPad Air 2
+
+ Devices based on the "A9" SoC:
+
+ - iPhone 6s
+ - iPhone 6s Plus
+ - iPhone SE (2016)
+ - iPad 5
+
+ Devices based on the "A9X" SoC:
+
+ - iPad Pro (9.7-inch)
+ - iPad Pro (12.9-inch)
+
+ Devices based on the "A10" SoC:
+
+ - iPhone 7
+ - iPhone 7 Plus
+ - iPod touch 7
+ - iPad 6
+ - iPad 7
+
+ Devices based on the "A10X" SoC:
+
+ - Apple TV 4K (1st generation)
+ - iPad Pro (2nd Generation) (10.5 Inch)
+ - iPad Pro (2nd Generation) (12.9 Inch)
+
+ Devices based on the "T2" SoC:
+
+ - Apple T2 MacBookPro15,2 (j132)
+ - Apple T2 iMacPro1,1 (j137)
+ - Apple T2 MacBookAir8,2 (j140a)
+ - Apple T2 MacBookAir8,1 (j140k)
+ - Apple T2 MacBookPro16,1 (j152f)
+ - Apple T2 MacPro7,1 (j160)
+ - Apple T2 Macmini8,1 (j174)
+ - Apple T2 iMac20,1 (j185)
+ - Apple T2 iMac20,2 (j185f)
+ - Apple T2 MacBookPro15,4 (j213)
+ - Apple T2 MacBookPro16,2 (j214k)
+ - Apple T2 MacBookPro16,4 (j215)
+ - Apple T2 MacBookPro16,3 (j223)
+ - Apple T2 MacBookAir9,1 (j230k)
+ - Apple T2 MacBookPro15,1 (j680)
+ - Apple T2 MacBookPro15,3 (j780)
+
+ Devices based on the "A11" SoC:
+
+ - iPhone 8
+ - iPhone 8 Plus
+ - iPhone X
+
+ Devices based on the "M1" SoC:
- Mac mini (M1, 2020)
- MacBook Pro (13-inch, M1, 2020)
- MacBook Air (M1, 2020)
- iMac (24-inch, M1, 2021)
- And devices based on the "M1 Pro" and "M1 Max" SoCs:
+ Devices based on the "M2" SoC:
+
+ - MacBook Air (M2, 2022)
+ - MacBook Air (15-inch, M2, 2023)
+ - MacBook Pro (13-inch, M2, 2022)
+ - Mac mini (M2, 2023)
+
+ Devices based on the "M1 Pro", "M1 Max" and "M1 Ultra" SoCs:
- MacBook Pro (14-inch, M1 Pro, 2021)
- MacBook Pro (14-inch, M1 Max, 2021)
- MacBook Pro (16-inch, M1 Pro, 2021)
- MacBook Pro (16-inch, M1 Max, 2021)
+ - Mac Studio (M1 Max, 2022)
+ - Mac Studio (M1 Ultra, 2022)
+
+ Devices based on the "M2 Pro", "M2 Max" and "M2 Ultra" SoCs:
+
+ - MacBook Pro (14-inch, M2 Pro, 2023)
+ - MacBook Pro (14-inch, M2 Max, 2023)
+ - MacBook Pro (16-inch, M2 Pro, 2023)
+ - MacBook Pro (16-inch, M2 Max, 2023)
+ - Mac mini (M2 Pro, 2023)
+ - Mac Studio (M2 Max, 2023)
+ - Mac Studio (M2 Ultra, 2023)
+ - Mac Pro (M2 Ultra, 2023)
The compatible property should follow this format:
@@ -57,6 +147,135 @@ properties:
const: "/"
compatible:
oneOf:
+ - description: Apple A7 SoC based platforms
+ items:
+ - enum:
+ - apple,j71 # iPad Air (Wi-Fi)
+ - apple,j72 # iPad Air (Cellular)
+ - apple,j73 # iPad Air (Cellular, China)
+ - apple,j85 # iPad mini 2 (Wi-Fi)
+ - apple,j85m # iPad mini 3 (Wi-Fi)
+ - apple,j86 # iPad mini 2 (Cellular)
+ - apple,j86m # iPad mini 3 (Cellular)
+ - apple,j87 # iPad mini 2 (Cellular, China)
+ - apple,j87m # iPad mini 3 (Cellular, China)
+ - apple,n51 # iPhone 5s (GSM)
+ - apple,n53 # iPhone 5s (LTE)
+ - const: apple,s5l8960x
+ - const: apple,arm-platform
+
+ - description: Apple A8 SoC based platforms
+ items:
+ - enum:
+ - apple,j42d # Apple TV HD
+ - apple,j96 # iPad mini 4 (Wi-Fi)
+ - apple,j97 # iPad mini 4 (Cellular)
+ - apple,n56 # iPhone 6 Plus
+ - apple,n61 # iPhone 6
+ - apple,n102 # iPod touch 6
+ - const: apple,t7000
+ - const: apple,arm-platform
+
+ - description: Apple A8X SoC based platforms
+ items:
+ - enum:
+ - apple,j81 # iPad Air 2 (Wi-Fi)
+ - apple,j82 # iPad Air 2 (Cellular)
+ - const: apple,t7001
+ - const: apple,arm-platform
+
+ - description: Apple Samsung A9 SoC based platforms
+ items:
+ - enum:
+ - apple,j71s # iPad 5 (Wi-Fi) (S8000)
+ - apple,j72s # iPad 5 (Cellular) (S8000)
+ - apple,n66 # iPhone 6s Plus (S8000)
+ - apple,n69u # iPhone SE (S8000)
+ - apple,n71 # iPhone 6S (S8000)
+ - const: apple,s8000
+ - const: apple,arm-platform
+
+ - description: Apple TSMC A9 SoC based platforms
+ items:
+ - enum:
+ - apple,j71t # iPad 5 (Wi-Fi) (S8003)
+ - apple,j72t # iPad 5 (Cellular) (S8003)
+ - apple,n66m # iPhone 6s Plus (S8003)
+ - apple,n69 # iPhone SE (S8003)
+ - apple,n71m # iPhone 6S (S8003)
+ - const: apple,s8003
+ - const: apple,arm-platform
+
+ - description: Apple A9X SoC based platforms
+ items:
+ - enum:
+ - apple,j127 # iPad Pro (9.7-inch) (Wi-Fi)
+ - apple,j128 # iPad Pro (9.7-inch) (Cellular)
+ - apple,j98a # iPad Pro (12.9-inch) (Wi-Fi)
+ - apple,j99a # iPad Pro (12.9-inch) (Cellular)
+ - const: apple,s8001
+ - const: apple,arm-platform
+
+ - description: Apple A10 SoC based platforms
+ items:
+ - enum:
+ - apple,d10 # iPhone 7 (Qualcomm)
+ - apple,d11 # iPhone 7 (Intel)
+ - apple,d101 # iPhone 7 Plus (Qualcomm)
+ - apple,d111 # iPhone 7 Plus (Intel)
+ - apple,j71b # iPad 6 (Wi-Fi)
+ - apple,j72b # iPad 6 (Cellular)
+ - apple,j171 # iPad 7 (Wi-Fi)
+ - apple,j172 # iPad 7 (Cellular)
+ - apple,n112 # iPod touch 7
+ - const: apple,t8010
+ - const: apple,arm-platform
+
+ - description: Apple A10X SoC based platforms
+ items:
+ - enum:
+ - apple,j105a # Apple TV 4K (1st Generation)
+ - apple,j120 # iPad Pro 2 (12.9-inch) (Wi-Fi)
+ - apple,j121 # iPad Pro 2 (12.9-inch) (Cellular)
+ - apple,j207 # iPad Pro 2 (10.5-inch) (Wi-Fi)
+ - apple,j208 # iPad Pro 2 (10.5-inch) (Cellular)
+ - const: apple,t8011
+ - const: apple,arm-platform
+
+ - description: Apple T2 SoC based platforms
+ items:
+ - enum:
+ - apple,j132 # Apple T2 MacBookPro15,2 (j132)
+ - apple,j137 # Apple T2 iMacPro1,1 (j137)
+ - apple,j140a # Apple T2 MacBookAir8,2 (j140a)
+ - apple,j140k # Apple T2 MacBookAir8,1 (j140k)
+ - apple,j152f # Apple T2 MacBookPro16,1 (j152f)
+ - apple,j160 # Apple T2 MacPro7,1 (j160)
+ - apple,j174 # Apple T2 Macmini8,1 (j174)
+ - apple,j185 # Apple T2 iMac20,1 (j185)
+ - apple,j185f # Apple T2 iMac20,2 (j185f)
+ - apple,j213 # Apple T2 MacBookPro15,4 (j213)
+ - apple,j214k # Apple T2 MacBookPro16,2 (j214k)
+ - apple,j215 # Apple T2 MacBookPro16,4 (j215)
+ - apple,j223 # Apple T2 MacBookPro16,3 (j223)
+ - apple,j230k # Apple T2 MacBookAir9,1 (j230k)
+ - apple,j680 # Apple T2 MacBookPro15,1 (j680)
+ - apple,j780 # Apple T2 MacBookPro15,3 (j780)
+ - const: apple,t8012
+ - const: apple,arm-platform
+
+ - description: Apple A11 SoC based platforms
+ items:
+ - enum:
+ - apple,d20 # iPhone 8 (Global)
+ - apple,d21 # iPhone 8 Plus (Global)
+ - apple,d22 # iPhone X (Global)
+ - apple,d201 # iPhone 8 (GSM)
+ - apple,d211 # iPhone 8 Plus (GSM)
+ - apple,d221 # iPhone X (GSM)
+ - const: apple,t8015
+ - const: apple,arm-platform
+
- description: Apple M1 SoC based platforms
items:
- enum:
@@ -67,6 +286,17 @@ properties:
- apple,j457 # iMac (24-inch, 2x USB-C, M1, 2021)
- const: apple,t8103
- const: apple,arm-platform
+
+ - description: Apple M2 SoC based platforms
+ items:
+ - enum:
+ - apple,j413 # MacBook Air (M2, 2022)
+ - apple,j415 # MacBook Air (15-inch, M2, 2023)
+ - apple,j473 # Mac mini (M2, 2023)
+ - apple,j493 # MacBook Pro (13-inch, M2, 2022)
+ - const: apple,t8112
+ - const: apple,arm-platform
+
- description: Apple M1 Pro SoC based platforms
items:
- enum:
@@ -74,14 +304,49 @@ properties:
- apple,j316s # MacBook Pro (16-inch, M1 Pro, 2021)
- const: apple,t6000
- const: apple,arm-platform
+
- description: Apple M1 Max SoC based platforms
items:
- enum:
- apple,j314c # MacBook Pro (14-inch, M1 Max, 2021)
- apple,j316c # MacBook Pro (16-inch, M1 Max, 2021)
+ - apple,j375c # Mac Studio (M1 Max, 2022)
- const: apple,t6001
- const: apple,arm-platform
+ - description: Apple M1 Ultra SoC based platforms
+ items:
+ - enum:
+ - apple,j375d # Mac Studio (M1 Ultra, 2022)
+ - const: apple,t6002
+ - const: apple,arm-platform
+
+ - description: Apple M2 Pro SoC based platforms
+ items:
+ - enum:
+ - apple,j414s # MacBook Pro (14-inch, M2 Pro, 2023)
+ - apple,j416s # MacBook Pro (16-inch, M2 Pro, 2023)
+ - apple,j474s # Mac mini (M2 Pro, 2023)
+ - const: apple,t6020
+ - const: apple,arm-platform
+
+ - description: Apple M2 Max SoC based platforms
+ items:
+ - enum:
+ - apple,j414c # MacBook Pro (14-inch, M2 Max, 2023)
+ - apple,j416c # MacBook Pro (16-inch, M2 Max, 2023)
+ - apple,j475c # Mac Studio (M2 Max, 2023)
+ - const: apple,t6021
+ - const: apple,arm-platform
+
+ - description: Apple M2 Ultra SoC based platforms
+ items:
+ - enum:
+ - apple,j180d # Mac Pro (M2 Ultra, 2023)
+ - apple,j475d # Mac Studio (M2 Ultra, 2023)
+ - const: apple,t6022
+ - const: apple,arm-platform
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml
index 0dc957a56d35..b88f41a225a3 100644
--- a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml
+++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml
@@ -20,13 +20,26 @@ properties:
pattern: "^power-management@[0-9a-f]+$"
compatible:
- items:
- - enum:
- - apple,t8103-pmgr
- - apple,t6000-pmgr
- - const: apple,pmgr
- - const: syscon
- - const: simple-mfd
+ oneOf:
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,s5l8960x-pmgr
+ - apple,t7000-pmgr
+ - apple,s8000-pmgr
+ - apple,t8010-pmgr
+ - apple,t8015-pmgr
+ - apple,t8103-pmgr
+ - apple,t8112-pmgr
+ - apple,t6000-pmgr
+ - const: apple,pmgr
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - const: apple,t6020-pmgr
+ - const: apple,t8103-pmgr
+ - const: syscon
+ - const: simple-mfd
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml
index 1706134b75a3..d28303d909e1 100644
--- a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/arm,cci-400.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM CCI Cache Coherent Interconnect Device Tree Binding
+title: ARM CCI Cache Coherent Interconnect
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml
index d783d9276124..2bae06eed693 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml
@@ -61,6 +61,9 @@ properties:
maxItems: 1
description: Address translation error interrupt
+ power-domains:
+ maxItems: 1
+
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
index 72ffe4d1e948..2a91670ccb8c 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
@@ -92,11 +92,15 @@ properties:
maxItems: 1
cpu:
- $ref: /schemas/types.yaml#/definitions/phandle
description:
- Handle to cpu this device is associated with. This must appear in the
- base cti node if compatible string arm,coresight-cti-v8-arch is used,
- or may appear in a trig-conns child node when appropriate.
+ Handle to cpu this CTI is associated with.
+
+ power-domains:
+ maxItems: 1
+
+ label:
+ description:
+ Description of a coresight device.
arm,cti-ctm-id:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -110,12 +114,12 @@ properties:
description:
defines a phandle reference to an associated CoreSight trace device.
When the associated trace device is enabled, then the respective CTI
- will be enabled. Use in a trig-conns node, or in CTI base node when
- compatible string arm,coresight-cti-v8-arch used. If the associated
- device has not been registered then the node name will be stored as
- the connection name for later resolution. If the associated device is
- not a CoreSight device or not registered then the node name will remain
- the connection name and automatic enabling will not occur.
+ will be enabled. Use in CTI base node when compatible string
+ arm,coresight-cti-v8-arch used. If the associated device has not been
+ registered then the node name will be stored as the connection name for
+ later resolution. If the associated device is not a CoreSight device or
+ not registered then the node name will remain the connection name and
+ automatic enabling will not occur.
# size cells and address cells required if trig-conns node present.
"#size-cells":
@@ -127,6 +131,8 @@ properties:
patternProperties:
'^trig-conns@([0-9]+)$':
type: object
+ additionalProperties: false
+
description:
A trigger connections child node which describes the trigger signals
between this CTI and another hardware device. This device may be a CPU,
@@ -138,6 +144,21 @@ patternProperties:
reg:
maxItems: 1
+ cpu:
+ description:
+ Handle to cpu this trigger connection is associated with.
+
+ arm,cs-dev-assoc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ defines a phandle reference to an associated CoreSight trace device.
+ When the associated trace device is enabled, then the respective CTI
+ will be enabled. If the associated device has not been registered
+ then the node name will be stored as the connection name for later
+ resolution. If the associated device is not a CoreSight device or
+ not registered then the node name will remain the connection name
+ and automatic enabling will not occur.
+
arm,trig-in-sigs:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
@@ -284,7 +305,7 @@ examples:
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = <PE_DBGTRIGGER
PE_PMUIRQ>;
- arm,trig-out-sigs=<0 1 2 >;
+ arm,trig-out-sigs = <0 1 2 >;
arm,trig-out-types = <PE_EDBGREQ
PE_DBGRESTART
PE_CTIIRQ>;
@@ -306,24 +327,24 @@ examples:
trig-conns@0 {
reg = <0>;
- arm,trig-in-sigs=<0>;
- arm,trig-in-types=<GEN_INTREQ>;
- arm,trig-out-sigs=<0>;
- arm,trig-out-types=<GEN_HALTREQ>;
+ arm,trig-in-sigs = <0>;
+ arm,trig-in-types = <GEN_INTREQ>;
+ arm,trig-out-sigs = <0>;
+ arm,trig-out-types = <GEN_HALTREQ>;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
- arm,trig-out-sigs=<2 3>;
- arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>;
+ arm,trig-out-sigs = <2 3>;
+ arm,trig-out-types = <GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
- arm,trig-in-sigs=<1 6>;
- arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>;
+ arm,trig-in-sigs = <1 6>;
+ arm,trig-in-types = <GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "g_counter";
};
};
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
new file mode 100644
index 000000000000..ed091dc0c10a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-sink.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Coresight Dummy sink component
+
+description: |
+ CoreSight components are compliant with the ARM CoreSight architecture
+ specification and can be connected in various topologies to suit a particular
+ SoCs tracing needs. These trace components can generally be classified as
+ sinks, links and sources. Trace data produced by one or more sources flows
+ through the intermediate links connecting the source to the currently selected
+ sink.
+
+ The Coresight dummy sink component is for the specific coresight sink devices
+ kernel don't have permission to access or configure, e.g., CoreSight EUD on
+ Qualcomm platforms. It is a mini-USB hub implemented to support the USB-based
+ debug and trace capabilities. For this device, a dummy driver is needed to
+ register it as Coresight sink device in kernel side, so that path can be
+ created in the driver. Then the trace flow would be transferred to EUD via
+ coresight link of AP processor. It provides Coresight API for operations on
+ dummy source devices, such as enabling and disabling them. It also provides
+ the Coresight dummy source paths for debugging.
+
+ The primary use case of the coresight dummy sink is to build path in kernel
+ side for dummy sink component.
+
+maintainers:
+ - Mike Leach <mike.leach@linaro.org>
+ - Suzuki K Poulose <suzuki.poulose@arm.com>
+ - James Clark <james.clark@linaro.org>
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Hao Zhang <quic_hazha@quicinc.com>
+
+properties:
+ compatible:
+ enum:
+ - arm,coresight-dummy-sink
+
+ label:
+ description:
+ Description of a coresight device.
+
+ in-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description: Input connection from the Coresight Trace bus to
+ dummy sink, such as Embedded USB debugger(EUD).
+
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - in-ports
+
+additionalProperties: false
+
+examples:
+ # Minimum dummy sink definition. Dummy sink connect to coresight replicator.
+ - |
+ sink {
+ compatible = "arm,coresight-dummy-sink";
+
+ in-ports {
+ port {
+ eud_in_replicator_swao: endpoint {
+ remote-endpoint = <&replicator_swao_out_eud>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
new file mode 100644
index 000000000000..78337be42b55
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,coresight-dummy-source.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Coresight Dummy source component
+
+description: |
+ CoreSight components are compliant with the ARM CoreSight architecture
+ specification and can be connected in various topologies to suit a particular
+ SoCs tracing needs. These trace components can generally be classified as
+ sinks, links and sources. Trace data produced by one or more sources flows
+ through the intermediate links connecting the source to the currently selected
+ sink.
+
+ The Coresight dummy source component is for the specific coresight source
+ devices kernel don't have permission to access or configure. For some SOCs,
+ there would be Coresight source trace components on sub-processor which
+ are connected to AP processor via debug bus. For these devices, a dummy driver
+ is needed to register them as Coresight source devices, so that paths can be
+ created in the driver. It provides Coresight API for operations on dummy
+ source devices, such as enabling and disabling them. It also provides the
+ Coresight dummy source paths for debugging.
+
+ The primary use case of the coresight dummy source is to build path in kernel
+ side for dummy source component.
+
+maintainers:
+ - Mike Leach <mike.leach@linaro.org>
+ - Suzuki K Poulose <suzuki.poulose@arm.com>
+ - James Clark <james.clark@linaro.org>
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Hao Zhang <quic_hazha@quicinc.com>
+
+properties:
+ compatible:
+ enum:
+ - arm,coresight-dummy-source
+
+ label:
+ description:
+ Description of a coresight device.
+
+ arm,static-trace-id:
+ description: If dummy source needs static id support, use this to set trace id.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 111
+
+ out-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description: Output connection from the source to Coresight
+ Trace bus.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - out-ports
+
+additionalProperties: false
+
+examples:
+ # Minimum dummy source definition. Dummy source connect to coresight funnel.
+ - |
+ source {
+ compatible = "arm,coresight-dummy-source";
+
+ out-ports {
+ port {
+ dummy_riscv_out_funnel_swao: endpoint {
+ remote-endpoint = <&funnel_swao_in_dummy_riscv>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
index 1eeedc22857c..b74db15e5f8a 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
@@ -54,6 +54,13 @@ properties:
- const: apb_pclk
- const: atclk
+ power-domains:
+ maxItems: 1
+
+ label:
+ description:
+ Description of a coresight device.
+
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml
index a26ed9214e00..17ea936b796f 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml
@@ -54,6 +54,13 @@ properties:
- const: apb_pclk
- const: atclk
+ label:
+ description:
+ Description of a coresight device.
+
+ power-domains:
+ maxItems: 1
+
qcom,replicator-loses-context:
type: boolean
description:
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml
index fd06ede26ceb..892df7aca1ac 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml
@@ -54,6 +54,13 @@ properties:
- const: apb_pclk
- const: atclk
+ label:
+ description:
+ Description of a coresight device.
+
+ power-domains:
+ maxItems: 1
+
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml
index e0377ce48537..71f2e1ed27e5 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml
@@ -73,6 +73,9 @@ properties:
- const: apb_pclk
- const: atclk
+ power-domains:
+ maxItems: 1
+
arm,coresight-loses-context-with-cpu:
type: boolean
description:
@@ -82,6 +85,10 @@ properties:
CPU powers down the coresight component also powers down and loses its
context.
+ label:
+ description:
+ Description of a coresight device.
+
arm,cp14:
type: boolean
description:
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml
index 374083956b20..9598a3d0a95b 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml
@@ -27,6 +27,13 @@ properties:
compatible:
const: arm,coresight-static-funnel
+ power-domains:
+ maxItems: 1
+
+ label:
+ description:
+ Description of a coresight device.
+
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml
index a34d8583830c..b81851b26c74 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml
@@ -27,6 +27,26 @@ properties:
compatible:
const: arm,coresight-static-replicator
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ oneOf:
+ - items:
+ - enum: [apb_pclk, atclk]
+ - items: # Zynq-700
+ - const: apb_pclk
+ - const: dbg_trc
+ - const: dbg_apb
+
+ label:
+ description:
+ Description of a coresight device.
+
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
@@ -42,7 +62,22 @@ properties:
patternProperties:
'^port@[01]$':
description: Output connections to CoreSight Trace bus
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ filter-source:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the coresight trace source device matching the
+ hard coded filtering for this port
+
+ remote-endpoint: true
required:
- compatible
@@ -69,6 +104,7 @@ examples:
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&etb_in_port>;
+ filter-source = <&tpdm_video>;
};
};
@@ -76,6 +112,7 @@ examples:
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&tpiu_in_port>;
+ filter-source = <&tpdm_mdss>;
};
};
};
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml
index 905008faa012..378380c3f5aa 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml
@@ -61,6 +61,9 @@ properties:
- const: apb_pclk
- const: atclk
+ power-domains:
+ maxItems: 1
+
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml
index 3463b6e53aef..96dd5b5f771a 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml
@@ -55,6 +55,16 @@ properties:
- const: apb_pclk
- const: atclk
+ label:
+ description:
+ Description of a coresight device.
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
arm,buffer-size:
$ref: /schemas/types.yaml#/definitions/uint32
deprecated: true
@@ -95,6 +105,29 @@ properties:
and ETF configurations.
$ref: /schemas/graph.yaml#/properties/port
+ memory-region:
+ items:
+ - description: Reserved trace buffer memory for ETR and ETF sinks.
+ For ETR, this reserved memory region is used for trace data capture.
+ Same region is used for trace data retention as well after a panic
+ or watchdog reset.
+ This reserved memory region is used as trace buffer or used for trace
+ data retention only if specifically selected by the user in sysfs
+ interface.
+ The default memory usage models for ETR in sysfs/perf modes are
+ otherwise unaltered.
+
+ For ETF, this reserved memory region is used by default for
+ retention of trace data synced from internal SRAM after a panic
+ or watchdog reset.
+ - description: Reserved meta data memory. Used for ETR and ETF sinks
+ for storing metadata.
+
+ memory-region-names:
+ items:
+ - const: tracedata
+ - const: metadata
+
required:
- compatible
- reg
@@ -109,6 +142,9 @@ examples:
etr@20070000 {
compatible = "arm,coresight-tmc", "arm,primecell";
reg = <0x20070000 0x1000>;
+ memory-region = <&etr_trace_mem_reserved>,
+ <&etr_mdata_mem_reserved>;
+ memory-region-names = "tracedata", "metadata";
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml
index e80d48200c37..a207f6899e67 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml
@@ -54,6 +54,13 @@ properties:
- const: apb_pclk
- const: atclk
+ label:
+ description:
+ Description of a coresight device.
+
+ power-domains:
+ maxItems: 1
+
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml b/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml
index a77f88223801..cff1cdaadb13 100644
--- a/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/arm/arm,corstone1000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Corstone1000 Device Tree Bindings
+title: ARM Corstone1000
maintainers:
- - Vishnu Banavath <vishnu.banavath@arm.com>
- - Rui Miguel Silva <rui.silva@linaro.org>
+ - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
+ - Hugues Kamba Mpiana <hugues.kambampiana@arm.com>
description: |+
ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
diff --git a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml
index 5f07fb166c56..9c2c9ac9705a 100644
--- a/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml
@@ -1,9 +1,9 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Embedded Trace Extensions
@@ -23,7 +23,7 @@ description: |
properties:
$nodename:
- pattern: "^ete([0-9a-f]+)$"
+ pattern: "^ete(-[0-9]+)?$"
compatible:
items:
- const: arm,embedded-trace-extension
@@ -33,6 +33,9 @@ properties:
Handle to the cpu this ETE is bound to.
$ref: /schemas/types.yaml#/definitions/phandle
+ power-domains:
+ maxItems: 1
+
out-ports:
description: |
Output connections from the ETE to legacy CoreSight trace bus.
@@ -52,13 +55,13 @@ examples:
# An ETE node without legacy CoreSight connections
- |
- ete0 {
+ ete-0 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_0>;
};
# An ETE node with legacy CoreSight connections
- |
- ete1 {
+ ete-1 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_1>;
diff --git a/Documentation/devicetree/bindings/arm/arm,integrator.yaml b/Documentation/devicetree/bindings/arm/arm,integrator.yaml
index 528eee64290a..1bdbd1b7ee38 100644
--- a/Documentation/devicetree/bindings/arm/arm,integrator.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,integrator.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/arm,integrator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Integrator Boards Device Tree Bindings
+title: ARM Integrator Boards
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -40,45 +40,6 @@ properties:
items:
- const: arm,integrator-sp
- core-module@10000000:
- type: object
- description: the root node in the Integrator platforms must contain
- a core module child node. They are always at physical address
- 0x10000000 in all the Integrator variants.
- properties:
- compatible:
- items:
- - const: arm,core-module-integrator
- - const: syscon
- - const: simple-mfd
- reg:
- maxItems: 1
-
- required:
- - compatible
- - reg
-
-patternProperties:
- "^syscon@[0-9a-f]+$":
- description: All Integrator boards must provide a system controller as a
- node in the root of the device tree.
- type: object
- properties:
- compatible:
- items:
- - enum:
- - arm,integrator-ap-syscon
- - arm,integrator-cp-syscon
- - arm,integrator-sp-syscon
- - const: syscon
- reg:
- maxItems: 1
-
- required:
- - compatible
- - reg
-
-
required:
- compatible
- core-module@10000000
diff --git a/Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml b/Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml
new file mode 100644
index 000000000000..ce5f2e1ec1ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,juno-fpga-apb-regs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Juno FPGA APB Registers
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+
+properties:
+ compatible:
+ items:
+ - const: arm,juno-fpga-apb-regs
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+patternProperties:
+ "^led@[0-9a-f]+,[0-9a-f]$":
+ $ref: /schemas/leds/register-bit-led.yaml#
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@10000 {
+ compatible = "arm,juno-fpga-apb-regs", "syscon", "simple-mfd";
+ reg = <0x010000 0x1000>;
+ ranges = <0x0 0x10000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ led@8,0 {
+ compatible = "register-bit-led";
+ reg = <0x08 0x04>;
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "vexpress:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/arm,morello.yaml b/Documentation/devicetree/bindings/arm/arm,morello.yaml
new file mode 100644
index 000000000000..e843b97fa485
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,morello.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,morello.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Morello Platforms
+
+maintainers:
+ - Vincenzo Frascino <vincenzo.frascino@arm.com>
+
+description: |+
+ The Morello architecture is an experimental extension to Armv8.2-A,
+ which extends the AArch64 state with the principles proposed in
+ version 7 of the Capability Hardware Enhanced RISC Instructions
+ (CHERI) ISA.
+
+ ARM's Morello Platforms are built as a research project to explore
+ capability architectures based on arm.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Arm Morello System Platforms
+ items:
+ - enum:
+ - arm,morello-sdp
+ - arm,morello-fvp
+ - const: arm,morello
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/arm,realview.yaml b/Documentation/devicetree/bindings/arm/arm,realview.yaml
index 4f9b21f49e84..3c5f1688dbd7 100644
--- a/Documentation/devicetree/bindings/arm/arm,realview.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,realview.yaml
@@ -4,15 +4,15 @@
$id: http://devicetree.org/schemas/arm/arm,realview.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM RealView Boards Device Tree Bindings
+title: ARM RealView Boards
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
- The ARM RealView series of reference designs were built to explore the ARM
- 11, Cortex A-8 and Cortex A-9 CPUs. This included new features compared to
- the earlier CPUs such as TrustZone and multicore (MPCore).
+ The ARM RealView series of reference designs were built to explore the Arm11,
+ Cortex-A8, and Cortex-A9 CPUs. This included new features compared to the
+ earlier CPUs such as TrustZone and multicore (MPCore).
properties:
$nodename:
@@ -75,43 +75,6 @@ properties:
type: object
description: All RealView boards must provide a syscon system controller
node inside the soc node.
- properties:
- compatible:
- oneOf:
- - items:
- - const: arm,realview-eb11mp-revb-syscon
- - const: arm,realview-eb-syscon
- - const: syscon
- - const: simple-mfd
- - items:
- - const: arm,realview-eb11mp-revc-syscon
- - const: arm,realview-eb-syscon
- - const: syscon
- - const: simple-mfd
- - items:
- - const: arm,realview-eb-syscon
- - const: syscon
- - const: simple-mfd
- - items:
- - const: arm,realview-pb1176-syscon
- - const: syscon
- - const: simple-mfd
- - items:
- - const: arm,realview-pb11mp-syscon
- - const: syscon
- - const: simple-mfd
- - items:
- - const: arm,realview-pba8-syscon
- - const: syscon
- - const: simple-mfd
- - items:
- - const: arm,realview-pbx-syscon
- - const: syscon
- - const: simple-mfd
-
- required:
- - compatible
- - reg
required:
- compatible
diff --git a/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml
index b1322658063a..f5b54b4fc55d 100644
--- a/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml
@@ -1,9 +1,9 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Trace Buffer Extensions
@@ -19,7 +19,8 @@ description: |
properties:
$nodename:
- const: "trbe"
+ const: trbe
+
compatible:
items:
- const: arm,trace-buffer-extension
@@ -40,10 +41,10 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
- trbe {
- compatible = "arm,trace-buffer-extension";
- interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
- };
+ trbe {
+ compatible = "arm,trace-buffer-extension";
+ interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ };
...
diff --git a/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml
new file mode 100644
index 000000000000..3b060c36b90c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,versatile-sysreg.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,versatile-sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Versatile system registers
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ This is a system control registers block, providing multiple low level
+ platform functions like board detection and identification, software
+ interrupt generation, MMC and NOR Flash control, etc.
+
+properties:
+ compatible:
+ items:
+ - const: arm,versatile-sysreg
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ panel:
+ type: object
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+...
diff --git a/Documentation/devicetree/bindings/arm/arm,versatile.yaml b/Documentation/devicetree/bindings/arm/arm,versatile.yaml
index 34b437c72751..7a3caf6af200 100644
--- a/Documentation/devicetree/bindings/arm/arm,versatile.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,versatile.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/arm,versatile.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Versatile Boards Device Tree Bindings
+title: ARM Versatile Boards
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -14,6 +14,14 @@ description: |+
with various pluggable interface boards, in essence the Versatile PB version
is a superset of the Versatile AB version.
+ The root node in the Versatile platforms must contain a core module child
+ node. They are always at physical address 0x10000000 in all the Versatile
+ variants.
+
+ When fitted with the IB2 Interface Board, the Versatile AB will present an
+ optional system controller node which controls the extra peripherals on the
+ interface board.
+
properties:
$nodename:
const: '/'
@@ -32,38 +40,6 @@ properties:
items:
- const: arm,versatile-pb
- core-module@10000000:
- type: object
- description: the root node in the Versatile platforms must contain
- a core module child node. They are always at physical address
- 0x10000000 in all the Versatile variants.
- properties:
- compatible:
- items:
- - const: arm,core-module-versatile
- - const: syscon
- - const: simple-mfd
- reg:
- maxItems: 1
-
- required:
- - compatible
- - reg
-
-patternProperties:
- "^syscon@[0-9a-f]+$":
- type: object
- description: When fitted with the IB2 Interface Board, the Versatile
- AB will present an optional system controller node which controls the
- extra peripherals on the interface board.
- properties:
- compatible:
- contains:
- const: arm,versatile-ib2-syscon
- required:
- - compatible
- - reg
-
required:
- compatible
- core-module@10000000
diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
index a4b4452afc1d..4cdca5320544 100644
--- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/arm,vexpress-juno.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Versatile Express and Juno Boards Device Tree Bindings
+title: ARM Versatile Express and Juno Boards
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
@@ -103,8 +103,9 @@ properties:
- const: arm,juno-r2
- const: arm,juno
- const: arm,vexpress
- - description: Arm AEMv8a Versatile Express Real-Time System Model
- (VE RTSM) is a programmers view of the Versatile Express with Arm
+ - description: Arm AEMv8a (Architecture Envelope Model)
+ Versatile Express Real-Time System Model (VE RTSM)
+ is a programmers view of the Versatile Express with Arm
v8A hardware. See ARM DUI 0575D.
items:
- const: arm,rtsm_ve,aemv8a
@@ -122,14 +123,14 @@ properties:
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position
in the stack be be described this attribute.
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
arm,vexpress,dcc:
description: When describing tiles consisting of more than one DCC, its
number can be specified with this attribute.
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
@@ -139,11 +140,12 @@ patternProperties:
the connection between the motherboard and any tiles. Sometimes the
compatible is placed directly under this node, sometimes it is placed
in a subnode named "motherboard-bus". Sometimes the compatible includes
- "arm,vexpress,v2?-p1" sometimes (on software models) is is just
+ "arm,vexpress,v2?-p1" sometimes (on software models) it is just
"simple-bus". If the compatible is placed in the "motherboard-bus" node,
it is stricter and always has two compatibles.
type: object
- $ref: '/schemas/simple-bus.yaml'
+ $ref: /schemas/simple-bus.yaml
+ unevaluatedProperties: false
properties:
compatible:
@@ -179,13 +181,13 @@ patternProperties:
- const: simple-bus
arm,v2m-memory-map:
description: This describes the memory map type.
- $ref: '/schemas/types.yaml#/definitions/string'
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- rs1
- rs2
arm,hbi:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
@@ -196,7 +198,7 @@ patternProperties:
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml
index c72aab706484..b8c5cacb09bd 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml
@@ -2,8 +2,8 @@
# Copyright 2021 Joel Stanley, IBM Corp.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ASPEED Secure Boot Controller
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 217a1d674863..9298c1a75dd1 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/aspeed/aspeed.yaml#
@@ -17,6 +17,7 @@ properties:
- description: AST2400 based boards
items:
- enum:
+ - delta,ahe50dc-bmc
- facebook,galaxy100-bmc
- facebook,wedge100-bmc
- facebook,wedge40-bmc
@@ -34,7 +35,10 @@ properties:
- ampere,mtjade-bmc
- aspeed,ast2500-evb
- asrock,e3c246d4i-bmc
+ - asrock,e3c256d4i-bmc
- asrock,romed8hm3-bmc
+ - asrock,spc621d8hm3-bmc
+ - asrock,x570d4u-bmc
- bytedance,g220a-bmc
- facebook,cmm-bmc
- facebook,minipack-bmc
@@ -42,6 +46,7 @@ properties:
- facebook,yamp-bmc
- facebook,yosemitev2-bmc
- facebook,wedge400-bmc
+ - facebook,wedge400-data64-bmc
- hxt,stardragon4800-rep2-bmc
- ibm,mihawk-bmc
- ibm,mowgli-bmc
@@ -70,20 +75,41 @@ properties:
- description: AST2600 based boards
items:
- enum:
+ - ampere,mtjefferson-bmc
- ampere,mtmitchell-bmc
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
+ - asus,x4tf-bmc
- facebook,bletchley-bmc
+ - facebook,catalina-bmc
+ - facebook,clemente-bmc
- facebook,cloudripper-bmc
+ - facebook,darwin-bmc
- facebook,elbert-bmc
- facebook,fuji-bmc
+ - facebook,fuji-data64-bmc
+ - facebook,greatlakes-bmc
+ - facebook,harma-bmc
+ - facebook,minerva-cmc
+ - facebook,santabarbara-bmc
+ - facebook,yosemite4-bmc
+ - facebook,yosemite5-bmc
+ - ibm,balcones-bmc
+ - ibm,blueridge-bmc
+ - ibm,bonnell-bmc
- ibm,everest-bmc
+ - ibm,fuji-bmc
- ibm,rainier-bmc
+ - ibm,sbp1-bmc
+ - ibm,system1-bmc
- ibm,tacoma-bmc
+ - inventec,starscream-bmc
- inventec,transformer-bmc
- jabil,rbp-bmc
- - nuvia,dc-scm-bmc
+ - nvidia,gb200nvl-bmc
+ - qcom,dc-scm-v1-bmc
- quanta,s6q-bmc
+ - ufispace,ncplite-bmc
- const: aspeed,ast2600
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml b/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml
new file mode 100644
index 000000000000..ad4a98a4ee67
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/atmel,sama5d2-secumod.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/atmel,sama5d2-secumod.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 Security Module (SECUMOD)
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+
+description:
+ The Security Module also offers the PIOBU pins which can be used as GPIO pins.
+ Note that they maintain their voltage during Backup/Self-refresh.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: atmel,sama5d2-secumod
+ - const: syscon
+ - items:
+ - enum:
+ - microchip,sama7d65-secumod
+ - microchip,sama7g5-secumod
+ - const: atmel,sama5d2-secumod
+ - const: syscon
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ security-module@fc040000 {
+ compatible = "atmel,sama5d2-secumod", "syscon";
+ reg = <0xfc040000 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
index 9e2e66a7566d..3a34b7a2e8d4 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/atmel-at91.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Atmel AT91 device tree bindings.
+title: Atmel AT91.
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
@@ -23,8 +23,6 @@ properties:
- const: atmel,at91rm9200
- items:
- enum:
- - olimex,sam9-l9260
- - enum:
- atmel,at91sam9260
- atmel,at91sam9261
- atmel,at91sam9263
@@ -36,6 +34,37 @@ properties:
- atmel,at91sam9x60
- const: atmel,at91sam9
+ - description: Olimex SAM9-L9260
+ items:
+ - const: olimex,sam9-l9260
+ - const: atmel,at91sam9260
+ - const: atmel,at91sam9
+
+ - description: Calao USB A9260
+ items:
+ - const: calao,usb-a9260
+ - const: atmel,at91sam9260
+ - const: atmel,at91sam9
+
+ - description: Calao USB A9263
+ items:
+ - const: calao,usb-a9263
+ - const: atmel,at91sam9263
+ - const: atmel,at91sam9
+
+ - description: Calao USB A9G20
+ items:
+ - const: calao,usb-a9g20
+ - const: atmel,at91sam9g20
+ - const: atmel,at91sam9
+
+ - description: Calao USB A9G20-LPW
+ items:
+ - const: calao,usb-a9g20-lpw
+ - const: calao,usb-a9g20
+ - const: atmel,at91sam9g20
+ - const: atmel,at91sam9
+
- items:
- enum:
- overkiz,kizboxmini-base # Overkiz kizbox Mini Base Board
@@ -79,6 +108,13 @@ properties:
- const: atmel,sama5d2
- const: atmel,sama5
+ - description: Microchip SAMA5D29 Curiosity
+ items:
+ - const: microchip,sama5d29-curiosity
+ - const: atmel,sama5d29
+ - const: atmel,sama5d2
+ - const: atmel,sama5
+
- items:
- const: atmel,sama5d27
- const: atmel,sama5d2
@@ -91,12 +127,20 @@ properties:
- const: atmel,sama5d2
- const: atmel,sama5
- - description: SAM9X60-EK board
+ - description: Microchip SAM9X60 Evaluation Boards
items:
- - const: microchip,sam9x60ek
+ - enum:
+ - microchip,sam9x60ek
+ - microchip,sam9x60-curiosity
- const: microchip,sam9x60
- const: atmel,at91sam9
+ - description: Microchip SAM9X7 Evaluation Boards
+ items:
+ - const: microchip,sam9x75-curiosity
+ - const: microchip,sam9x7
+ - const: atmel,at91sam9
+
- description: Nattis v2 board with Natte v2 power board
items:
- const: axentia,nattis-2
@@ -165,11 +209,24 @@ properties:
- const: atmel,sama5d4
- const: atmel,sama5
+ - description: Microchip SAMA7D65 Curiosity Board
+ items:
+ - const: microchip,sama7d65-curiosity
+ - const: microchip,sama7d65
+ - const: microchip,sama7d6
+ - const: microchip,sama7
+
- items:
- const: microchip,sama7g5ek # SAMA7G5 Evaluation Kit
- const: microchip,sama7g5
- const: microchip,sama7
+ - description: Microchip SAMA7G54 Curiosity Board
+ items:
+ - const: microchip,sama7g54-curiosity
+ - const: microchip,sama7g5
+ - const: microchip,sama7
+
- description: Microchip LAN9662 Evaluation Boards.
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index ab1b352344ae..5ce54f9befe6 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -2,6 +2,7 @@ Atmel system registers
Chipid required properties:
- compatible: Should be "atmel,sama5d2-chipid" or "microchip,sama7g5-chipid"
+ "microchip,sama7d65-chipid"
- reg : Should contain registers location and length
PIT Timer required properties:
@@ -11,7 +12,9 @@ PIT Timer required properties:
shared across all System Controller members.
PIT64B Timer required properties:
-- compatible: Should be "microchip,sam9x60-pit64b"
+- compatible: Should be "microchip,sam9x60-pit64b" or
+ "microchip,sam9x7-pit64b", "microchip,sam9x60-pit64b"
+ "microchip,sama7d65-pit64b", "microchip,sam9x60-pit64b"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for PIT64B timer
- clocks: Should contain the available clock sources for PIT64B timer.
@@ -26,12 +29,14 @@ Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt"
RAMC SDRAM/DDR Controller required properties:
-- compatible: Should be "atmel,at91rm9200-sdramc", "syscon"
- "atmel,at91sam9260-sdramc",
- "atmel,at91sam9g45-ddramc",
- "atmel,sama5d3-ddramc",
- "microchip,sam9x60-ddramc",
- "microchip,sama7g5-uddrc"
+- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" or
+ "atmel,at91sam9260-sdramc" or
+ "atmel,at91sam9g45-ddramc" or
+ "atmel,sama5d3-ddramc" or
+ "microchip,sam9x60-ddramc" or
+ "microchip,sama7g5-uddrc" or
+ "microchip,sama7d65-uddrc", "microchip,sama7g5-uddrc" or
+ "microchip,sam9x7-ddramc", "atmel,sama5d3-ddramc".
- reg: Should contain registers location and length
Examples:
@@ -41,151 +46,3 @@ Examples:
reg = <0xffffe800 0x200>;
};
-RAMC PHY Controller required properties:
-- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon"
-- reg: Should contain registers location and length
-
-Example:
-
- ddr3phy: ddr3phy@e3804000 {
- compatible = "microchip,sama7g5-ddr3phy", "syscon";
- reg = <0xe3804000 0x1000>;
-};
-
-SHDWC Shutdown Controller
-
-required properties:
-- compatible: Should be "atmel,<chip>-shdwc".
- <chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
-- reg: Should contain registers location and length
-- clocks: phandle to input clock.
-
-optional properties:
-- atmel,wakeup-mode: String, operation mode of the wakeup mode.
- Supported values are: "none", "high", "low", "any".
-- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
-
-optional at91sam9260 properties:
-- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
-
-optional at91sam9rl properties:
-- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
-- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
-
-optional at91sam9x5 properties:
-- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
-
-Example:
-
- shdwc@fffffd10 {
- compatible = "atmel,at91sam9260-shdwc";
- reg = <0xfffffd10 0x10>;
- clocks = <&clk32k>;
- };
-
-SHDWC SAMA5D2-Compatible Shutdown Controller
-
-1) shdwc node
-
-required properties:
-- compatible: should be "atmel,sama5d2-shdwc", "microchip,sam9x60-shdwc" or
- "microchip,sama7g5-shdwc"
-- reg: should contain registers location and length
-- clocks: phandle to input clock.
-- #address-cells: should be one. The cell is the wake-up input index.
-- #size-cells: should be zero.
-
-optional properties:
-
-- debounce-delay-us: minimum wake-up inputs debouncer period in
- microseconds. It's usually a board-related property.
-- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
-
-optional microchip,sam9x60-shdwc or microchip,sama7g5-shdwc properties:
-- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
-
-The node contains child nodes for each wake-up input that the platform uses.
-
-2) input nodes
-
-Wake-up input nodes are usually described in the "board" part of the Device
-Tree. Note also that input 0 is linked to the wake-up pin and is frequently
-used.
-
-Required properties:
-- reg: should contain the wake-up input index [0 - 15].
-
-Optional properties:
-- atmel,wakeup-active-high: boolean, the corresponding wake-up input described
- by the child, forces the wake-up of the core power supply on a high level.
- The default is to be active low.
-
-Example:
-
-On the SoC side:
- shdwc@f8048010 {
- compatible = "atmel,sama5d2-shdwc";
- reg = <0xf8048010 0x10>;
- clocks = <&clk32k>;
- #address-cells = <1>;
- #size-cells = <0>;
- atmel,wakeup-rtc-timer;
- };
-
-On the board side:
- shdwc@f8048010 {
- debounce-delay-us = <976>;
-
- input@0 {
- reg = <0>;
- };
-
- input@1 {
- reg = <1>;
- atmel,wakeup-active-high;
- };
- };
-
-Special Function Registers (SFR)
-
-Special Function Registers (SFR) manage specific aspects of the integrated
-memory, bridge implementations, processor and other functionality not controlled
-elsewhere.
-
-required properties:
-- compatible: Should be "atmel,<chip>-sfr", "syscon" or
- "atmel,<chip>-sfrbu", "syscon"
- <chip> can be "sama5d3", "sama5d4" or "sama5d2".
- It also can be "microchip,sam9x60-sfr", "syscon".
-- reg: Should contain registers location and length
-
- sfr@f0038000 {
- compatible = "atmel,sama5d3-sfr", "syscon";
- reg = <0xf0038000 0x60>;
- };
-
-Security Module (SECUMOD)
-
-The Security Module macrocell provides all necessary secure functions to avoid
-voltage, temperature, frequency and mechanical attacks on the chip. It also
-embeds secure memories that can be scrambled.
-
-The Security Module also offers the PIOBU pins which can be used as GPIO pins.
-Note that they maintain their voltage during Backup/Self-refresh.
-
-required properties:
-- compatible: Should be "atmel,<chip>-secumod", "syscon".
- <chip> can be "sama5d2".
-- reg: Should contain registers location and length
-- gpio-controller: Marks the port as GPIO controller.
-- #gpio-cells: There are 2. The pin number is the
- first, the second represents additional
- parameters such as GPIO_ACTIVE_HIGH/LOW.
-
-
- secumod@fc040000 {
- compatible = "atmel,sama5d2-secumod", "syscon";
- reg = <0xfc040000 0x100>;
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/arm/axiado.yaml b/Documentation/devicetree/bindings/arm/axiado.yaml
new file mode 100644
index 000000000000..bfabe7b32e65
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axiado.yaml
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/axiado.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axiado Platforms
+
+maintainers:
+ - Harshit Shah <hshah@axiado.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: AX3000 based boards
+ items:
+ - enum:
+ - axiado,ax3000-evk # Axiado AX3000 Evaluation Board
+ - const: axiado,ax3000 # Axiado AX3000 SoC
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/axis.txt b/Documentation/devicetree/bindings/arm/axis.txt
deleted file mode 100644
index ae345e1c8d2b..000000000000
--- a/Documentation/devicetree/bindings/arm/axis.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Axis Communications AB
-ARTPEC series SoC Device Tree Bindings
-
-ARTPEC-6 ARM SoC
-================
-
-Required root node properties:
-- compatible = "axis,artpec6";
-
-ARTPEC-6 System Controller
---------------------------
-
-The ARTPEC-6 has a system controller with mixed functions controlling DMA, PCIe
-and resets.
-
-Required properties:
-- compatible: "axis,artpec6-syscon", "syscon"
-- reg: Address and length of the register bank.
-
-Example:
- syscon {
- compatible = "axis,artpec6-syscon", "syscon";
- reg = <0xf8000000 0x48>;
- };
-
-ARTPEC-6 Development board:
----------------------------
-Required root node properties:
-- compatible = "axis,artpec6-dev-board", "axis,artpec6";
diff --git a/Documentation/devicetree/bindings/arm/axis.yaml b/Documentation/devicetree/bindings/arm/axis.yaml
new file mode 100644
index 000000000000..63e9aca85db7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axis.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/axis.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axis ARTPEC platforms
+
+maintainers:
+ - Jesper Nilsson <jesper.nilsson@axis.com>
+ - Lars Persson <lars.persson@axis.com>
+ - linux-arm-kernel@axis.com
+
+description: |
+ ARM platforms using SoCs designed by Axis branded as "ARTPEC".
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Axis ARTPEC-6 SoC board
+ items:
+ - enum:
+ - axis,artpec6-dev-board
+ - const: axis,artpec6
+
+ - description: Axis ARTPEC-8 SoC board
+ items:
+ - enum:
+ - axis,artpec8-grizzly
+ - const: axis,artpec8
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/axxia.yaml b/Documentation/devicetree/bindings/arm/axxia.yaml
index e0d2bb71cf50..d60907e43efc 100644
--- a/Documentation/devicetree/bindings/arm/axxia.yaml
+++ b/Documentation/devicetree/bindings/arm/axxia.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/axxia.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Axxia AXM55xx device tree bindings
+title: Axxia AXM55xx
maintainers:
- Anders Berg <anders.berg@lsi.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml
index 8051a75c2c79..2729a542c4f3 100644
--- a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/bcm2835.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM2711/BCM2835 Platforms Device Tree Bindings
+title: Broadcom BCM2711/BCM2835 Platforms
maintainers:
- Eric Anholt <eric@anholt.net>
@@ -23,6 +23,12 @@ properties:
- raspberrypi,4-model-b
- const: brcm,bcm2711
+ - description: BCM2712 based Boards
+ items:
+ - enum:
+ - raspberrypi,5-model-b
+ - const: brcm,bcm2712
+
- description: BCM2835 based Boards
items:
- enum:
@@ -46,6 +52,7 @@ properties:
- description: BCM2837 based Boards
items:
- enum:
+ - raspberrypi,2-model-b-rev2
- raspberrypi,3-model-a-plus
- raspberrypi,3-model-b
- raspberrypi,3-model-b-plus
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml
index c60324357435..f2bcac0096b7 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm11351.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM11351 device tree bindings
+title: Broadcom BCM11351
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml
index b3020757380f..cf4e254e32f1 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm21664.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM21664 device tree bindings
+title: Broadcom BCM21664
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml
index 37f3a6fcde76..eafec29ba7ab 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm23550.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM23550 device tree bindings
+title: Broadcom BCM23550
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
index 958df32b4899..f47d74a5b0b6 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4708.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM4708 device tree bindings
+title: Broadcom BCM4708
description:
Broadcom BCM4708/47081/4709/47094/53012 Wi-Fi/network SoCs based
@@ -25,13 +25,16 @@ properties:
- enum:
- asus,rt-ac56u
- asus,rt-ac68u
+ - buffalo,wxr-1750dhp
+ - buffalo,wzr-1166dhp
+ - buffalo,wzr-1166dhp2
- buffalo,wzr-1750dhp
- linksys,ea6300-v1
- linksys,ea6500-v2
- - luxul,xap-1510v1
+ - luxul,xap-1510-v1
- luxul,xwc-1000
- - netgear,r6250v1
- - netgear,r6300v2
+ - netgear,r6250-v1
+ - netgear,r6300-v2
- smartrg,sr400ac
- brcm,bcm94708
- const: brcm,bcm4708
@@ -42,8 +45,8 @@ properties:
- asus,rt-n18u
- buffalo,wzr-600dhp2
- buffalo,wzr-900dhp
- - luxul,xap-1410v1
- - luxul,xwr-1200v1
+ - luxul,xap-1410-v1
+ - luxul,xwr-1200-v1
- tplink,archer-c5-v2
- const: brcm,bcm47081
- const: brcm,bcm4708
@@ -51,6 +54,7 @@ properties:
- description: BCM4709 based boards
items:
- enum:
+ - asus,rt-ac3200
- asus,rt-ac87u
- buffalo,wxr-1900dhp
- linksys,ea9200
@@ -64,14 +68,17 @@ properties:
- description: BCM47094 based boards
items:
- enum:
+ - asus,rt-ac3100
+ - asus,rt-ac5300
- asus,rt-ac88u
- dlink,dir-885l
+ - dlink,dir-890l
- linksys,panamera
- luxul,abr-4500-v1
- luxul,xap-1610-v1
- luxul,xbr-4500-v1
- luxul,xwc-2000-v1
- - luxul,xwr-3100v1
+ - luxul,xwr-3100-v1
- luxul,xwr-3150-v1
- netgear,r8500
- phicomm,k3
@@ -97,6 +104,7 @@ properties:
- description: BCM53016 based boards
items:
- enum:
+ - dlink,dwl-8610ap
- meraki,mr32
- const: brcm,bcm53016
- const: brcm,bcm4708
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml
new file mode 100644
index 000000000000..81b9a4a641c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm53573.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm53573.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM53573 SoCs family
+
+description:
+ Broadcom BCM53573 / BCM47189 Wi-Fi SoCs derived from Northstar.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: BCM53573 based boards
+ items:
+ - enum:
+ - tenda,ac6-v1
+ - tenda,w15e-v1
+ - const: brcm,bcm53573
+
+ - description: BCM47189 based boards
+ items:
+ - enum:
+ - brcm,bcm947189acdbmr
+ - luxul,xap-810-v1
+ - luxul,xap-1440-v1
+ - tenda,ac9
+ - const: brcm,bcm47189
+ - const: brcm,bcm53573
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml
index 84866e29cab0..354bb1420cdd 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcmbca.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Broadband SoC device tree bindings
+title: Broadcom Broadband SoC
description:
Broadcom Broadband SoCs include family of high performance DSL/PON/Wireless
@@ -34,6 +34,7 @@ properties:
- enum:
- netgear,r8000p
- tplink,archer-c2300-v1
+ - zyxel,ex3510b
- const: brcm,bcm4906
- const: brcm,bcm4908
- const: brcm,bcmbca
@@ -115,6 +116,7 @@ properties:
items:
- enum:
- brcm,bcm96846
+ - genexis,xg6846b
- const: brcm,bcm6846
- const: brcm,bcmbca
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml
index 432ccf990f9e..a0a3f32db54e 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,cygnus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Cygnus device tree bindings
+title: Broadcom Cygnus
maintainers:
- Ray Jui <rjui@broadcom.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml
index 294948399f82..cc6add0e933a 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,hr2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Hurricane 2 device tree bindings
+title: Broadcom Hurricane 2
description:
Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml
index c4847abbecd8..6696598eca0e 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,ns2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom North Star 2 (NS2) device tree bindings
+title: Broadcom North Star 2 (NS2)
maintainers:
- Ray Jui <rjui@broadcom.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml
index 7d184ba7d180..a43b2d4d936b 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,nsp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Northstar Plus device tree bindings
+title: Broadcom Northstar Plus
description:
Broadcom Northstar Plus family of SoCs are used for switching control
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml
index c638e04ebae0..c6ccb78aab0a 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,stingray.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Stingray device tree bindings
+title: Broadcom Stingray
maintainers:
- Ray Jui <rjui@broadcom.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml
index 4eba182abd53..3f441352fbf0 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bcm/brcm,vulcan-soc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Vulcan device tree bindings
+title: Broadcom Vulcan
maintainers:
- Robert Richter <rrichter@marvell.com>
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index b369b374fc4a..8349c0a854d9 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -30,6 +30,7 @@ properties:
clocks:
type: object
+ additionalProperties: false
properties:
compatible:
@@ -45,8 +46,33 @@ properties:
- compatible
- "#clock-cells"
+ gpio:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: raspberrypi,firmware-gpio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ The first cell is the pin number, and the second cell is used to
+ specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
+
+ gpio-line-names:
+ minItems: 8
+
+ required:
+ - compatible
+ - gpio-controller
+ - "#gpio-cells"
+
reset:
type: object
+ additionalProperties: false
properties:
compatible:
@@ -63,6 +89,7 @@ properties:
pwm:
type: object
+ additionalProperties: false
properties:
compatible:
@@ -76,8 +103,28 @@ properties:
- compatible
- "#pwm-cells"
+ touchscreen:
+ type: object
+ $ref: /schemas/input/touchscreen/touchscreen.yaml#
additionalProperties: false
+ properties:
+ compatible:
+ const: raspberrypi,firmware-ts
+
+ firmware:
+ deprecated: true
+ description: Phandle to RPi's firmware device node.
+
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+ required:
+ - compatible
+
required:
- compatible
- mboxes
@@ -95,6 +142,12 @@ examples:
#clock-cells = <1>;
};
+ expgpio: gpio {
+ compatible = "raspberrypi,firmware-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
@@ -104,5 +157,11 @@ examples:
compatible = "raspberrypi,firmware-poe-pwm";
#pwm-cells = <2>;
};
+
+ ts: touchscreen {
+ compatible = "raspberrypi,firmware-ts";
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/arm/bitmain.yaml b/Documentation/devicetree/bindings/arm/bitmain.yaml
index 90ba02be48ce..55a5a570b5bc 100644
--- a/Documentation/devicetree/bindings/arm/bitmain.yaml
+++ b/Documentation/devicetree/bindings/arm/bitmain.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/bitmain.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bitmain platform device tree bindings
+title: Bitmain platform
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
diff --git a/Documentation/devicetree/bindings/arm/blaize.yaml b/Documentation/devicetree/bindings/arm/blaize.yaml
new file mode 100644
index 000000000000..af39e2756407
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/blaize.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/blaize.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Blaize Platforms
+
+maintainers:
+ - James Cowgill <james.cowgill@blaize.com>
+ - Matt Redfearn <matt.redfearn@blaize.com>
+ - Neil Jones <neil.jones@blaize.com>
+ - Nikolaos Pasaloukos <nikolaos.pasaloukos@blaize.com>
+
+description: |
+ Blaize Platforms using SoCs designed by Blaize Inc.
+
+ The products based on the BLZP1600 SoC:
+
+ - BLZP1600-SoM: SoM (System on Module)
+ - BLZP1600-CB2: Development board CB2 based on BLZP1600-SoM
+
+ BLZP1600 SoC integrates a dual core ARM Cortex A53 cluster
+ and a Blaize Graph Streaming Processor for AI and ML workloads,
+ plus a suite of connectivity and other peripherals.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Blaize BLZP1600 based boards
+ items:
+ - enum:
+ - blaize,blzp1600-cb2
+ - const: blaize,blzp1600
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/bst.yaml b/Documentation/devicetree/bindings/arm/bst.yaml
new file mode 100644
index 000000000000..a3a7f424fd57
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bst.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/bst.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BST platforms
+
+description:
+ Black Sesame Technologies (BST) is a semiconductor company that produces
+ automotive-grade system-on-chips (SoCs) for intelligent driving, focusing
+ on computer vision and AI capabilities. The BST C1200 family includes SoCs
+ for ADAS (Advanced Driver Assistance Systems) and autonomous driving
+ applications.
+
+maintainers:
+ - Ge Gordon <gordon.ge@bst.ai>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: BST C1200 CDCU1.0 ADAS 4C2G board
+ items:
+ - const: bst,c1200-cdcu1.0-adas-4c2g
+ - const: bst,c1200
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/calxeda.yaml b/Documentation/devicetree/bindings/arm/calxeda.yaml
index 46f78addebb0..3e9f5e1d862e 100644
--- a/Documentation/devicetree/bindings/arm/calxeda.yaml
+++ b/Documentation/devicetree/bindings/arm/calxeda.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/calxeda.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Calxeda Platforms Device Tree Bindings
+title: Calxeda Platforms
maintainers:
- Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml
index a9fe01238a88..76b65ea149b6 100644
--- a/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml
+++ b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.yaml
@@ -16,7 +16,7 @@ maintainers:
properties:
compatible:
- const: "calxeda,hb-sregs-l2-ecc"
+ const: calxeda,hb-sregs-l2-ecc
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/arm/cavium,thunder-88xx.yaml b/Documentation/devicetree/bindings/arm/cavium,thunder-88xx.yaml
new file mode 100644
index 000000000000..d7c813118c1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cavium,thunder-88xx.yaml
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cavium,thunder-88xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cavium Thunder 88xx SoC
+
+maintainers:
+ - Robert Richter <rric@kernel.org>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ items:
+ - const: cavium,thunder-88xx
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
deleted file mode 100644
index 6f63a5866902..000000000000
--- a/Documentation/devicetree/bindings/arm/cavium-thunder.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Cavium Thunder platform device tree bindings
---------------------------------------------
-
-Boards with Cavium's Thunder SoC shall have following properties.
-
-Root Node
----------
-Required root node properties:
-
- - compatible = "cavium,thunder-88xx";
diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder2.txt b/Documentation/devicetree/bindings/arm/cavium-thunder2.txt
deleted file mode 100644
index dc5dd65cbce7..000000000000
--- a/Documentation/devicetree/bindings/arm/cavium-thunder2.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Cavium ThunderX2 CN99XX platform tree bindings
-----------------------------------------------
-
-Boards with Cavium ThunderX2 CN99XX SoC shall have the root property:
- compatible = "cavium,thunderx2-cn9900", "brcm,vulcan-soc";
-
-These SoC uses the "cavium,thunder2" core which will be compatible
-with "brcm,vulcan".
diff --git a/Documentation/devicetree/bindings/arm/cci-control-port.yaml b/Documentation/devicetree/bindings/arm/cci-control-port.yaml
index c9114866213f..c29d250a6d77 100644
--- a/Documentation/devicetree/bindings/arm/cci-control-port.yaml
+++ b/Documentation/devicetree/bindings/arm/cci-control-port.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/cci-control-port.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: CCI Interconnect Bus Masters binding
+title: CCI Interconnect Bus Masters
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
diff --git a/Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml b/Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml
new file mode 100644
index 000000000000..170aad5dd7ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cirrus/cirrus,ep9301.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cirrus/cirrus,ep9301.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP93xx platforms
+
+description:
+ The EP93xx SoC is a ARMv4T-based with 200 MHz ARM9 CPU.
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: The TS-7250 is a compact, full-featured Single Board
+ Computer (SBC) based upon the Cirrus EP9302 ARM9 CPU
+ items:
+ - const: technologic,ts7250
+ - const: cirrus,ep9301
+
+ - description: The Liebherr BK3 is a derivate from ts7250 board
+ items:
+ - const: liebherr,bk3
+ - const: cirrus,ep9301
+
+ - description: EDB302 is an evaluation board by Cirrus Logic,
+ based on a Cirrus Logic EP9302 CPU
+ items:
+ - const: cirrus,edb9302
+ - const: cirrus,ep9301
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/cix.yaml b/Documentation/devicetree/bindings/arm/cix.yaml
new file mode 100644
index 000000000000..114dab4bc4d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cix.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CIX platforms
+
+maintainers:
+ - Peter Chen <peter.chen@cixtech.com>
+ - Fugang Duan <fugang.duan@cixtech.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: Radxa Orion O6
+ items:
+ - const: radxa,orion-o6
+ - const: cix,sky1
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp b/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp
index 35e5afb6d9ad..cc7b1402a31f 100644
--- a/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp
+++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp
@@ -27,16 +27,6 @@ Properties:
- reg : Offset and length of the register set for the device
-* Alpine System-Fabric Service Registers
-
-The System-Fabric Service Registers allow various operation on CPU and
-system fabric, like powering CPUs off.
-
-Properties:
-- compatible : Should contain "al,alpine-sysfabric-service" and "syscon".
-- reg : Offset and length of the register set for the device
-
-
Example:
cpus {
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index a07c5bac7c46..736b7ab1bd0a 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -4,15 +4,15 @@
$id: http://devicetree.org/schemas/arm/cpus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM CPUs bindings
+title: ARM CPUs
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
description: |+
- The device tree allows to describe the layout of CPUs in a system through
- the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
- defining properties for every cpu.
+ The device tree allows to describe the layout of CPUs in a system through the
+ "cpus" node, which in turn contains a number of subnodes (ie "cpu") defining
+ properties for every cpu.
Bindings for CPU nodes follow the Devicetree Specification, available from:
@@ -41,52 +41,57 @@ description: |+
properties:
reg:
maxItems: 1
- description: |
- Usage and definition depend on ARM architecture version and
- configuration:
+ description: >
+ Usage and definition depend on ARM architecture version and configuration:
- On uniprocessor ARM architectures previous to v7
- this property is required and must be set to 0.
+ On uniprocessor ARM architectures previous to v7 this property is required
+ and must be set to 0.
- On ARM 11 MPcore based systems this property is
- required and matches the CPUID[11:0] register bits.
+ On ARM 11 MPcore based systems this property is required and matches the
+ CPUID[11:0] register bits.
- Bits [11:0] in the reg cell must be set to
- bits [11:0] in CPU ID register.
+ Bits [11:0] in the reg cell must be set to bits [11:0] in CPU ID register.
All other bits in the reg cell must be set to 0.
- On 32-bit ARM v7 or later systems this property is
- required and matches the CPU MPIDR[23:0] register
- bits.
+ On 32-bit ARM v7 or later systems this property is required and matches
+ the CPU MPIDR[23:0] register bits.
- Bits [23:0] in the reg cell must be set to
- bits [23:0] in MPIDR.
+ Bits [23:0] in the reg cell must be set to bits [23:0] in MPIDR.
All other bits in the reg cell must be set to 0.
- On ARM v8 64-bit systems this property is required
- and matches the MPIDR_EL1 register affinity bits.
+ On ARM v8 64-bit systems this property is required and matches the
+ MPIDR_EL1 register affinity bits.
* If cpus node's #address-cells property is set to 2
- The first reg cell bits [7:0] must be set to
- bits [39:32] of MPIDR_EL1.
+ The first reg cell bits [7:0] must be set to bits [39:32] of
+ MPIDR_EL1.
- The second reg cell bits [23:0] must be set to
- bits [23:0] of MPIDR_EL1.
+ The second reg cell bits [23:0] must be set to bits [23:0] of
+ MPIDR_EL1.
* If cpus node's #address-cells property is set to 1
- The reg cell bits [23:0] must be set to bits [23:0]
- of MPIDR_EL1.
+ The reg cell bits [23:0] must be set to bits [23:0] of MPIDR_EL1.
All other bits in the reg cells must be set to 0.
compatible:
enum:
- - apple,icestorm
+ - apm,potenza
+ - apm,strega
+ - apple,avalanche
+ - apple,blizzard
+ - apple,cyclone
- apple,firestorm
+ - apple,hurricane-zephyr
+ - apple,icestorm
+ - apple,mistral
+ - apple,monsoon
+ - apple,twister
+ - apple,typhoon
- arm,arm710t
- arm,arm720t
- arm,arm740t
@@ -118,6 +123,10 @@ properties:
- arm,arm1176jzf-s
- arm,arm11mpcore
- arm,armv8 # Only for s/w models
+ - arm,c1-nano
+ - arm,c1-premium
+ - arm,c1-pro
+ - arm,c1-ultra
- arm,cortex-a5
- arm,cortex-a7
- arm,cortex-a8
@@ -139,8 +148,16 @@ properties:
- arm,cortex-a77
- arm,cortex-a78
- arm,cortex-a78ae
+ - arm,cortex-a78c
+ - arm,cortex-a320
- arm,cortex-a510
+ - arm,cortex-a520
+ - arm,cortex-a520ae
- arm,cortex-a710
+ - arm,cortex-a715
+ - arm,cortex-a720
+ - arm,cortex-a720ae
+ - arm,cortex-a725
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
@@ -149,12 +166,22 @@ properties:
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
+ - arm,cortex-r52
- arm,cortex-x1
+ - arm,cortex-x1c
- arm,cortex-x2
+ - arm,cortex-x3
+ - arm,cortex-x4
+ - arm,cortex-x925
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
+ - arm,neoverse-n3
- arm,neoverse-v1
+ - arm,neoverse-v2
+ - arm,neoverse-v3
+ - arm,neoverse-v3ae
+ - arm,rainier
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan
@@ -174,20 +201,30 @@ properties:
- nvidia,tegra194-carmel
- qcom,krait
- qcom,kryo
+ - qcom,kryo240
- qcom,kryo250
- qcom,kryo260
- qcom,kryo280
+ - qcom,kryo360
- qcom,kryo385
+ - qcom,kryo465
- qcom,kryo468
+ - qcom,kryo470
- qcom,kryo485
- qcom,kryo560
- qcom,kryo570
+ - qcom,kryo660
+ - qcom,kryo670
- qcom,kryo685
- qcom,kryo780
+ - qcom,oryon
- qcom,scorpion
+ - samsung,mongoose-m2
+ - samsung,mongoose-m3
+ - samsung,mongoose-m5
enable-method:
- $ref: '/schemas/types.yaml#/definitions/string'
+ $ref: /schemas/types.yaml#/definitions/string
oneOf:
# On ARM v8 64-bit this property is required
- enum:
@@ -236,106 +273,150 @@ properties:
cpu-release-addr:
oneOf:
- - $ref: '/schemas/types.yaml#/definitions/uint32'
- - $ref: '/schemas/types.yaml#/definitions/uint64'
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - $ref: /schemas/types.yaml#/definitions/uint64
description:
The DT specification defines this as 64-bit always, but some 32-bit Arm
systems have used a 32-bit value which must be supported.
- Required for systems that have an "enable-method"
- property value of "spin-table".
cpu-idle-states:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
maxItems: 1
- description: |
- List of phandles to idle state nodes supported
- by this cpu (see ./idle-states.yaml).
+ description:
+ List of phandles to idle state nodes supported by this cpu (see
+ ./idle-states.yaml).
capacity-dmips-mhz:
description:
- u32 value representing CPU capacity (see ./cpu-capacity.txt) in
- DMIPS/MHz, relative to highest capacity-dmips-mhz
- in the system.
+ u32 value representing CPU capacity (see ../cpu/cpu-capacity.txt) in
+ DMIPS/MHz, relative to highest capacity-dmips-mhz in the system.
cci-control-port: true
dynamic-power-coefficient:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- description:
- A u32 value that represents the running time dynamic
- power coefficient in units of uW/MHz/V^2. The
- coefficient can either be calculated from power
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ A u32 value that represents the running time dynamic power coefficient in
+ units of uW/MHz/V^2. The coefficient can either be calculated from power
measurements or derived by analysis.
- The dynamic power consumption of the CPU is
- proportional to the square of the Voltage (V) and
- the clock frequency (f). The coefficient is used to
+ The dynamic power consumption of the CPU is proportional to the square of
+ the Voltage (V) and the clock frequency (f). The coefficient is used to
calculate the dynamic power as below -
Pdyn = dynamic-power-coefficient * V^2 * f
where voltage is in V, frequency is in MHz.
+ interconnects:
+ minItems: 1
+ maxItems: 3
+
+ nvmem-cells:
+ maxItems: 1
+
+ nvmem-cell-names:
+ const: speed_grade
+
performance-domains:
maxItems: 1
- description:
- List of phandles and performance domain specifiers, as defined by
- bindings of the performance domain provider. See also
- dvfs/performance-domain.yaml.
power-domains:
- description:
- List of phandles and PM domain specifiers, as defined by bindings of the
- PM domain provider (see also ../power_domain.txt).
+ minItems: 1
+ maxItems: 2
power-domain-names:
description:
- A list of power domain name strings sorted in the same order as the
- power-domains property.
-
For PSCI based platforms, the name corresponding to the index of the PSCI
- PM domain provider, must be "psci".
+ PM domain provider, must be "psci". For SCMI based platforms, the name
+ corresponding to the index of an SCMI performance domain provider, must be
+ "perf".
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ psci, perf, cpr ]
- qcom,saw:
- $ref: '/schemas/types.yaml#/definitions/phandle'
- description: |
- Specifies the SAW* node associated with this CPU.
+ resets:
+ maxItems: 1
- Required for systems that have an "enable-method" property
- value of "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2"
+ arm-supply:
+ deprecated: true
+ description: Use 'cpu-supply' instead
- * arm/msm/qcom,saw2.txt
+ cpu0-supply:
+ deprecated: true
+ description: Use 'cpu-supply' instead
- qcom,acc:
- $ref: '/schemas/types.yaml#/definitions/phandle'
- description: |
- Specifies the ACC* node associated with this CPU.
+ mem-supply: true
+
+ proc-supply:
+ deprecated: true
+ description: Use 'cpu-supply' instead
+
+ pu-supply:
+ deprecated: true
+ description: Only for i.MX6Q/DL/SL SoCs.
- Required for systems that have an "enable-method" property
- value of "qcom,kpss-acc-v1", "qcom,kpss-acc-v2", "qcom,msm8226-smp" or
- "qcom,msm8916-smp".
+ soc-supply:
+ deprecated: true
+ description: Only for i.MX6/7 Soc.
- * arm/msm/qcom,kpss-acc.txt
+ sram-supply:
+ deprecated: true
+ description: Use 'mem-supply' instead
+
+ fsl,soc-operating-points:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: FSL i.MX6 Soc operation-points when change cpu frequency
+ deprecated: true
+ items:
+ items:
+ - description: Frequency in kHz
+ - description: Voltage for OPP in uV
+
+ mediatek,cci:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Link to Mediatek Cache Coherent Interconnect
+
+ edac-enabled:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ A72 CPUs support Error Detection And Correction (EDAC) on their L1 and
+ L2 caches. This flag marks this function as usable.
+
+ qcom,saw:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Specifies the SAW node associated with this CPU.
+
+ qcom,acc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Specifies the ACC node associated with this CPU.
+
+ qcom,freq-domain:
+ description: Specifies the QCom CPUFREQ HW associated with the CPU.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
rockchip,pmu:
- $ref: '/schemas/types.yaml#/definitions/phandle'
- description: |
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: >
Specifies the syscon node controlling the cpu core power domains.
- Optional for systems that have an "enable-method"
- property value of "rockchip,rk3066-smp"
- While optional, it is the preferred way to get access to
- the cpu-core power-domains.
+ Optional for systems that have an "enable-method" property value of
+ "rockchip,rk3066-smp". While optional, it is the preferred way to get
+ access to the cpu-core power-domains.
secondary-boot-reg:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- description: |
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
Required for systems that have an "enable-method" property value of
"brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp".
- This includes the following SoCs: |
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664, BCM23550
+ This includes the following SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664, BCM23550,
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
The secondary-boot-reg property is a u32 value that specifies the
@@ -344,22 +425,77 @@ properties:
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
-if:
- # If the enable-method property contains one of those values
- properties:
- enable-method:
- contains:
- enum:
- - brcm,bcm11351-cpu-method
- - brcm,bcm23550
- - brcm,bcm-nsp-smp
- # and if enable-method is present
- required:
- - enable-method
-
-then:
- required:
- - secondary-boot-reg
+ thermal-idle:
+ type: object
+
+allOf:
+ - $ref: /schemas/cpu.yaml#
+ - $ref: /schemas/opp/opp-v1.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: arm,cortex-a72
+ then:
+ # Allow edac-enabled only for Cortex A72
+ properties:
+ edac-enabled: false
+
+ - if:
+ # If the enable-method property contains one of those values
+ properties:
+ enable-method:
+ contains:
+ enum:
+ - brcm,bcm11351-cpu-method
+ - brcm,bcm23550
+ - brcm,bcm-nsp-smp
+ # and if enable-method is present
+ required:
+ - enable-method
+ then:
+ required:
+ - secondary-boot-reg
+ - if:
+ properties:
+ enable-method:
+ enum:
+ - spin-table
+ - renesas,r9a06g032-smp
+ required:
+ - enable-method
+ then:
+ required:
+ - cpu-release-addr
+ - if:
+ properties:
+ enable-method:
+ enum:
+ - qcom,kpss-acc-v1
+ - qcom,kpss-acc-v2
+ - qcom,msm8226-smp
+ - qcom,msm8916-smp
+ required:
+ - enable-method
+ then:
+ required:
+ - qcom,acc
+ - qcom,saw
+ else:
+ if:
+ # 2 Qualcomm platforms bootloaders need qcom,acc and qcom,saw yet use
+ # "spin-table" or "psci" enable-methods. Disallowing the properties for
+ # all other CPUs is the best we can do as there's not any way to
+ # distinguish these Qualcomm platforms.
+ not:
+ properties:
+ compatible:
+ const: arm,cortex-a53
+ then:
+ properties:
+ qcom,acc: false
+ qcom,saw: false
required:
- device_type
@@ -369,7 +505,7 @@ required:
dependencies:
rockchip,pmu: [enable-method]
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/arm/digicolor.yaml b/Documentation/devicetree/bindings/arm/digicolor.yaml
index a35de3c9e284..0cf9ddaa527e 100644
--- a/Documentation/devicetree/bindings/arm/digicolor.yaml
+++ b/Documentation/devicetree/bindings/arm/digicolor.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/digicolor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Conexant Digicolor Platforms Device Tree Bindings
+title: Conexant Digicolor Platforms
maintainers:
- Baruch Siach <baruch@tkos.co.il>
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
index 9a426110a14a..5d033570b57b 100644
--- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: OP-TEE Device Tree Bindings
+title: OP-TEE
maintainers:
- Jens Wiklander <jens.wiklander@linaro.org>
@@ -28,7 +28,8 @@ properties:
maxItems: 1
description: |
This interrupt which is used to signal an event by the secure world
- software is expected to be edge-triggered.
+ software is expected to be either a per-cpu interrupt or an
+ edge-triggered peripheral interrupt.
method:
enum: [smc, hvc]
diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
index 9d1857c0aa07..e3980b659f63 100644
--- a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
+++ b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/firmware/tlm,trusted-foundations.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Trusted Foundations
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml b/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml
new file mode 100644
index 000000000000..1f515bea3959
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/freescale/fsl,imx51-m4if.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Multi Master Multi Memory Interface (M4IF) and Tigerp module
+
+description: collect the imx devices, which only have compatible and reg property
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx51-m4if
+ - fsl,imx51-tigerp
+ - fsl,imx51-aipstz
+ - fsl,imx53-aipstz
+ - fsl,imx7d-pcie-phy
+ - items:
+ - const: fsl,imx53-tigerp
+ - const: fsl,imx51-tigerp
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ m4if@83fd8000 {
+ compatible = "fsl,imx51-m4if";
+ reg = <0x83fd8000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml
index 3b26040f8f18..9d377e193c12 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml
@@ -28,6 +28,14 @@ properties:
reg:
maxItems: 1
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: divcore
+ - const: hsrun_divcore
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.yaml b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.yaml
index 526f508cb98d..bd39cf107f3e 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.yaml
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.yaml
@@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX7ULP System Integration Module
maintainers:
- - Anson Huang <anson.huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
description: |
The system integration module (SIM) provides system control and chip configuration
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
deleted file mode 100644
index 44aa3c451ccf..000000000000
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Freescale Vybrid Miscellaneous System Control - CPU Configuration
-
-The MSCM IP contains multiple sub modules, this binding describes the first
-block of registers which contains CPU configuration information.
-
-Required properties:
-- compatible: "fsl,vf610-mscm-cpucfg", "syscon"
-- reg: the register range of the MSCM CPU configuration registers
-
-Example:
- mscm_cpucfg: cpucfg@40001000 {
- compatible = "fsl,vf610-mscm-cpucfg", "syscon";
- reg = <0x40001000 0x800>;
- }
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
deleted file mode 100644
index 6dd6f399236d..000000000000
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Freescale Vybrid Miscellaneous System Control - Interrupt Router
-
-The MSCM IP contains multiple sub modules, this binding describes the second
-block of registers which control the interrupt router. The interrupt router
-allows to configure the recipient of each peripheral interrupt. Furthermore
-it controls the directed processor interrupts. The module is available in all
-Vybrid SoC's but is only really useful in dual core configurations (VF6xx
-which comes with a Cortex-A5/Cortex-M4 combination).
-
-Required properties:
-- compatible: "fsl,vf610-mscm-ir"
-- reg: the register range of the MSCM Interrupt Router
-- fsl,cpucfg: The handle to the MSCM CPU configuration node, required
- to get the current CPU ID
-- interrupt-controller: Identifies the node as an interrupt controller
-- #interrupt-cells: Two cells, interrupt number and cells.
- The hardware interrupt number according to interrupt
- assignment of the interrupt router is required.
- Flags get passed only when using GIC as parent. Flags
- encoding as documented by the GIC bindings.
-
-Example:
- mscm_ir: interrupt-controller@40001800 {
- compatible = "fsl,vf610-mscm-ir";
- reg = <0x40001800 0x400>;
- fsl,cpucfg = <&mscm_cpucfg>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <&intc>;
- }
diff --git a/Documentation/devicetree/bindings/arm/freescale/m4if.txt b/Documentation/devicetree/bindings/arm/freescale/m4if.txt
deleted file mode 100644
index 93bd7b867a53..000000000000
--- a/Documentation/devicetree/bindings/arm/freescale/m4if.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-* Freescale Multi Master Multi Memory Interface (M4IF) module
-
-Required properties:
-- compatible : Should be "fsl,imx51-m4if"
-- reg : Address and length of the register set for the device
-
-Example:
-
-m4if: m4if@83fd8000 {
- compatible = "fsl,imx51-m4if";
- reg = <0x83fd8000 0x1000>;
-};
diff --git a/Documentation/devicetree/bindings/arm/freescale/tigerp.txt b/Documentation/devicetree/bindings/arm/freescale/tigerp.txt
deleted file mode 100644
index 19e2aad63d6e..000000000000
--- a/Documentation/devicetree/bindings/arm/freescale/tigerp.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-* Freescale Tigerp platform module
-
-Required properties:
-- compatible : Should be "fsl,imx51-tigerp"
-- reg : Address and length of the register set for the device
-
-Example:
-
-tigerp: tigerp@83fa0000 {
- compatible = "fsl,imx51-tigerp";
- reg = <0x83fa0000 0x28>;
-};
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0cea264a9de2..68a2d5fecc43 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -4,11 +4,10 @@
$id: http://devicetree.org/schemas/arm/fsl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX Platforms Device Tree Bindings
+title: Freescale i.MX Platforms
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Li Yang <leoyang.li@nxp.com>
properties:
$nodename:
@@ -25,8 +24,11 @@ properties:
- description: i.MX23 based Boards
items:
- enum:
+ - creative,x-fi3
- fsl,imx23-evk
+ - fsl,stmp378x-devb
- olimex,imx23-olinuxino
+ - sandisk,sansa_fuze_plus
- const: fsl,imx23
- description: i.MX25 Product Development Kit
@@ -87,13 +89,59 @@ properties:
- description: i.MX28 based Boards
items:
- enum:
+ - amarula,imx28-rmm
- armadeus,imx28-apf28 # APF28 SoM
- - armadeus,imx28-apf28dev # APF28 SoM on APF28Dev board
+ - bluegiga,apx4devkit # Bluegiga APx4 SoM on dev board
+ - crystalfontz,cfa10036 # Crystalfontz CFA-10036 SoM
+ - eukrea,mbmx28lc
- fsl,imx28-evk
- i2se,duckbill
- i2se,duckbill-2
+ - karo,tx28 # Ka-Ro electronics TX28 module
+ - lwn,imx28-btt3
+ - lwn,imx28-xea
+ - msr,m28cu3 # M28 SoM with custom base board
+ - schulercontrol,imx28-sps1
- technologic,imx28-ts4600
- const: fsl,imx28
+
+ - description: i.MX28 Aries M28 SoM Board
+ items:
+ - const: aries,m28
+ - const: denx,m28
+ - const: fsl,imx28
+
+ - description: i.MX28 Aries M28EVK Board
+ items:
+ - const: aries,m28evk
+ - const: denx,m28evk
+ - const: fsl,imx28
+
+ - description: i.MX28 Armadeus Systems APF28Dev Board
+ items:
+ - const: armadeus,imx28-apf28dev
+ - const: armadeus,imx28-apf28
+ - const: fsl,imx28
+
+ - description: i.MX28 Crystalfontz CFA-10036 based Boards
+ items:
+ - enum:
+ - crystalfontz,cfa10037
+ - crystalfontz,cfa10049
+ - crystalfontz,cfa10057
+ - crystalfontz,cfa10058
+ - const: crystalfontz,cfa10036
+ - const: fsl,imx28
+
+ - description: i.MX28 Crystalfontz CFA-10037 based Boards
+ items:
+ - enum:
+ - crystalfontz,cfa10055
+ - crystalfontz,cfa10056
+ - const: crystalfontz,cfa10037
+ - const: crystalfontz,cfa10036
+ - const: fsl,imx28
+
- description: i.MX28 Duckbill 2 based Boards
items:
- enum:
@@ -103,6 +151,19 @@ properties:
- const: i2se,duckbill-2
- const: fsl,imx28
+ - description: i.MX28 Eukrea Electromatique MBMX283LC Board
+ items:
+ - const: eukrea,mbmx283lc
+ - const: eukrea,mbmx28lc
+ - const: fsl,imx28
+
+ - description: i.MX28 Eukrea Electromatique MBMX287LC Board
+ items:
+ - const: eukrea,mbmx287lc
+ - const: eukrea,mbmx283lc
+ - const: eukrea,mbmx28lc
+ - const: fsl,imx28
+
- description: i.MX31 based Boards
items:
- enum:
@@ -173,6 +234,7 @@ properties:
- kiebackpeter,imx53-ddc # K+P imx53 DDC
- kiebackpeter,imx53-hsc # K+P imx53 HSC
- menlo,m53menlo # i.MX53 Menlo board
+ - starterkit,sk-imx53
- voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668
- const: fsl,imx53
@@ -236,12 +298,12 @@ properties:
- technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi
- technologic,imx6q-ts4900
- technologic,imx6q-ts7970
- - toradex,apalis_imx6q # Apalis iMX6 Modules
- udoo,imx6q-udoo # Udoo i.MX6 Quad Board
- uniwest,imx6q-evi # Uniwest Evi
- variscite,dt6customboard
- wand,imx6q-wandboard # Wandboard i.MX6 Quad Board
- ysoft,imx6q-yapp4-crux # i.MX6 Quad Y Soft IOTA Crux board
+ - ysoft,imx6q-yapp4-pegasus # i.MX6 Quad Y Soft IOTA Pegasus board
- zealz,imx6q-gk802 # Zealz GK802
- zii,imx6q-zii-rdu2 # ZII RDU2 Board
- const: fsl,imx6q
@@ -301,6 +363,12 @@ properties:
- const: gw,ventana
- const: fsl,imx6q
+ - description: i.MX6Q Kontron SMARC-sAMX6i on SMARC Eval Carrier 2.0
+ items:
+ - const: kontron,imx6q-samx6i-ads2
+ - const: kontron,imx6q-samx6i
+ - const: fsl,imx6q
+
- description: i.MX6Q PHYTEC phyBOARD-Mira
items:
- enum:
@@ -312,7 +380,9 @@ properties:
- description: i.MX6Q PHYTEC phyFLEX-i.MX6
items:
- - const: phytec,imx6q-pbab01 # PHYTEC phyFLEX carrier board
+ - enum:
+ - comvetia,imx6q-lxr # Comvetia LXR board
+ - phytec,imx6q-pbab01 # PHYTEC phyFLEX carrier board
- const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
- const: fsl,imx6q
@@ -322,10 +392,17 @@ properties:
- toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board
- toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6Q/D Module on Ixora V1.1 Carrier Board
- toradex,apalis_imx6q-ixora-v1.2 # Apalis iMX6Q/D Module on Ixora V1.2 Carrier Board
- - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board
+ - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board v1.0/v1.1
+ - toradex,apalis_imx6q-eval-v1.2 # Apalis iMX6Q/D Module on Apalis Evaluation Board v1.2
- const: toradex,apalis_imx6q
- const: fsl,imx6q
+ - description: i.MX6Q Variscite VAR-SOM-MX6 Boards
+ items:
+ - const: variscite,mx6customboard
+ - const: variscite,var-som-imx6q
+ - const: fsl,imx6q
+
- description: TQ-Systems TQMa6Q SoM (variant A) on MBa6x
items:
- const: tq,imx6q-mba6x-a
@@ -352,6 +429,7 @@ properties:
- prt,prtwd3 # Protonic WD3 board
- wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board
- ysoft,imx6qp-yapp4-crux-plus # i.MX6 Quad Plus Y Soft IOTA Crux+ board
+ - ysoft,imx6qp-yapp4-pegasus-plus # i.MX6 Quad Plus Y Soft IOTA Pegasus+ board
- zii,imx6qp-zii-rdu2 # ZII RDU2+ Board
- const: fsl,imx6qp
@@ -400,6 +478,7 @@ properties:
- prt,prtvt7 # Protonic VT7 board
- rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board
- riot,imx6s-riotboard # RIoTboard i.MX6S
+ - sielaff,imx6dl-board # Sielaff i.MX6 Solo Board
- skov,imx6dl-skov-revc-lt2 # SKOV IMX6 CPU SoloCore lt2
- skov,imx6dl-skov-revc-lt6 # SKOV IMX6 CPU SoloCore lt6
- solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite
@@ -412,13 +491,14 @@ properties:
- technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- - toradex,colibri_imx6dl # Colibri iMX6 Modules
- udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board
- vdl,lanmcu # Van der Laan LANMCU board
- wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board
- - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board
+ - ysoft,imx6dl-yapp4-draco # i.MX6 Solo Y Soft IOTA Draco board
- ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board
+ - ysoft,imx6dl-yapp4-lynx # i.MX6 DualLite Y Soft IOTA Lynx board
- ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board
+ - ysoft,imx6dl-yapp4-phoenix # i.MX6 DualLite Y Soft IOTA Phoenix board
- ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board
- const: fsl,imx6dl
@@ -445,9 +525,11 @@ properties:
- const: dfi,fs700e-m60
- const: fsl,imx6dl
- - description: i.MX6DL DHCOM PicoITX Board
+ - description: i.MX6DL DHCOM based Boards
items:
- - const: dh,imx6dl-dhcom-picoitx
+ - enum:
+ - dh,imx6dl-dhcom-pdk2 # i.MX6DL DHCOM SoM on PDK2 board
+ - dh,imx6dl-dhcom-picoitx # i.MX6DL DHCOM SoM on PicoITX board
- const: dh,imx6dl-dhcom-som
- const: fsl,imx6dl
@@ -471,6 +553,12 @@ properties:
- const: gw,ventana
- const: fsl,imx6dl
+ - description: i.MX6DL Kontron SMARC-sAMX6i on SMARC Eval Carrier 2.0
+ items:
+ - const: kontron,imx6dl-samx6i-ads2
+ - const: kontron,imx6dl-samx6i
+ - const: fsl,imx6dl
+
- description: i.MX6DL PHYTEC phyBOARD-Mira
items:
- enum:
@@ -520,8 +608,10 @@ properties:
items:
- enum:
- fsl,imx6sl-evk # i.MX6 SoloLite EVK Board
+ - kobo,aura2
- kobo,tolino-shine2hd
- kobo,tolino-shine3
+ - kobo,tolino-vision
- kobo,tolino-vision5
- revotics,imx6sl-warp # Revotics WaRP Board
- const: fsl,imx6sl
@@ -534,6 +624,14 @@ properties:
- kobo,librah2o
- const: fsl,imx6sll
+ - description: i.MX6SLL Kobo Clara 2e Rev. A/B
+ items:
+ - enum:
+ - kobo,clara2e-a
+ - kobo,clara2e-b
+ - const: kobo,clara2e
+ - const: fsl,imx6sll
+
- description: i.MX6SX based Boards
items:
- enum:
@@ -590,6 +688,12 @@ properties:
- const: phytec,imx6ul-pcl063 # PHYTEC phyCORE-i.MX 6UL
- const: fsl,imx6ul
+ - description: i.MX6UL Variscite VAR-SOM-MX6 Boards
+ items:
+ - const: variscite,mx6ulconcerto
+ - const: variscite,var-som-imx6ul
+ - const: fsl,imx6ul
+
- description: Kontron BL i.MX6UL (N631X S) Board
items:
- const: kontron,bl-imx6ul # Kontron BL i.MX6UL Carrier Board
@@ -632,9 +736,7 @@ properties:
- joz,jozacp # JOZ Access Point
- kontron,sl-imx6ull # Kontron SL i.MX6ULL SoM
- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board
- - toradex,colibri-imx6ull # Colibri iMX6ULL Modules
- - toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module
- - toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Modules
+ - uni-t,uti260b # UNI-T UTi260B Thermal Camera
- const: fsl,imx6ull
- description: i.MX6ULL Armadeus Systems OPOS6ULDev Board
@@ -643,6 +745,40 @@ properties:
- const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
- const: fsl,imx6ull
+ - description: i.MX6ULL chargebyte Tarragon Boards
+ items:
+ - enum:
+ - chargebyte,imx6ull-tarragon-master
+ - chargebyte,imx6ull-tarragon-micro
+ - chargebyte,imx6ull-tarragon-slave
+ - chargebyte,imx6ull-tarragon-slavext
+ - const: fsl,imx6ull
+
+ - description: i.MX6ULL DHCOM SoM based Boards
+ items:
+ - enum:
+ - dh,imx6ull-dhcom-drc02
+ - dh,imx6ull-dhcom-pdk2
+ - dh,imx6ull-dhcom-picoitx
+ - const: dh,imx6ull-dhcom-som # The DHCOR is soldered on the DHCOM
+ - const: dh,imx6ull-dhcor-som
+ - const: fsl,imx6ull
+
+ - description: i.MX6ULL DHCOR SoM based Boards
+ items:
+ - const: marantec,imx6ull-dhcor-maveo-box
+ - const: dh,imx6ull-dhcor-som
+ - const: fsl,imx6ull
+
+ - description: i.MX6ULL Engicam MicroGEA SoM based boards
+ items:
+ - enum:
+ - engicam,microgea-imx6ull-bmm # i.MX6ULL Engicam MicroGEA BMM Board
+ - engicam,microgea-imx6ull-gtw # i.MX6ULL Engicam MicroGEA GTW Board
+ - engicam,microgea-imx6ull-rmm # i.MX6ULL Engicam MicroGEA RMM Board
+ - const: engicam,microgea-imx6ull # i.MX6ULL Engicam MicroGEA SoM
+ - const: fsl,imx6ull
+
- description: i.MX6ULL PHYTEC phyBOARD-Segin
items:
- enum:
@@ -697,19 +833,27 @@ properties:
- const: kontron,sl-imx6ull # Kontron SL i.MX6ULL SoM
- const: fsl,imx6ull
- - description: TQ Systems TQMa6ULLx SoM on MBa6ULx board
+ - description: TQ-Systems TQMa6ULLx SoM on MBa6ULx board
items:
- enum:
- - tq,imx6ull-tqma6ull2-mba6ulx
- - const: tq,imx6ull-tqma6ull2 # MCIMX6Y2
+ - tq,imx6ull-tqma6ull2-mba6ulx # TQMa6ULL socketable SoM with MCIMX6Y2 on MBa6ULx EVK
+ - const: tq,imx6ull-tqma6ull2 # TQMa6ULL socketable SoM with MCIMX6Y2
- const: fsl,imx6ull
- - description: TQ Systems TQMa6ULLxL SoM on MBa6ULx[L] board
+ - description: TQ-Systems TQMa6ULLxL SoM on MBa6ULx[L] board
items:
- enum:
- - tq,imx6ull-tqma6ull2l-mba6ulx # using LGA adapter
- - tq,imx6ull-tqma6ull2l-mba6ulxl
- - const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
+ - tq,imx6ull-tqma6ull2l-mba6ulx # TQMa6ULLxL LGA SoM with socketable Adapter on MBa6ULx EVK
+ - tq,imx6ull-tqma6ull2l-mba6ulxl # TQMa6ULLxL LGA SoM on MBa6ULxL gateway board
+ - const: tq,imx6ull-tqma6ull2l # TQMa6ULLxL LGA SoM with MCIMX6Y2
+ - const: fsl,imx6ull
+
+ - description: Seeed Stuido i.MX6ULL SoM on dev boards
+ items:
+ - enum:
+ - seeed,imx6ull-seeed-npi-emmc
+ - seeed,imx6ull-seeed-npi-nand
+ - const: seeed,imx6ull-seeed-npi
- const: fsl,imx6ull
- description: i.MX6ULZ based Boards
@@ -759,8 +903,6 @@ properties:
- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
- technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph
- technexion,imx7d-pico-pi # TechNexion i.MX7D Pico-Pi
- - toradex,colibri-imx7d # Colibri iMX7D Module
- - toradex,colibri-imx7d-emmc # Colibri iMX7D 1GB (eMMC) Module
- zii,imx7d-rmu2 # ZII RMU2 Board
- zii,imx7d-rpu2 # ZII RPU2 Board
- const: fsl,imx7d
@@ -818,6 +960,8 @@ properties:
- emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
- fsl,imx8mm-evk # i.MX8MM EVK Board
+ - fsl,imx8mm-evkb # i.MX8MM EVKB Board
+ - gateworks,imx8mm-gw75xx-0x # i.MX8MM Gateworks Board
- gateworks,imx8mm-gw7904
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
- gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit
@@ -825,16 +969,25 @@ properties:
- gw,imx8mm-gw7901 # i.MX8MM Gateworks Board
- gw,imx8mm-gw7902 # i.MX8MM Gateworks Board
- gw,imx8mm-gw7903 # i.MX8MM Gateworks Board
+ - innocomm,wb15-evk # i.MX8MM Innocomm EVK board with WB15 SoM
- kontron,imx8mm-sl # i.MX8MM Kontron SL (N801X) SOM
- kontron,imx8mm-osm-s # i.MX8MM Kontron OSM-S (N802X) SOM
- - menlo,mx8menlo # i.MX8MM Menlo board with Verdin SoM
- - toradex,verdin-imx8mm # Verdin iMX8M Mini Modules
- - toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT
- - toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules
- - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module
- prt,prt8mm # i.MX8MM Protonic PRT8MM Board
- const: fsl,imx8mm
+ - description: Compulab i.MX8MM UCM SoM based boards
+ items:
+ - enum:
+ - compulab,imx8mm-iot-gateway # i.MX8MM Compulab IoT-Gateway
+ - const: compulab,imx8mm-ucm-som # i.MX8MM Compulab UCM SoM
+ - const: fsl,imx8mm
+
+ - description: Emtop i.MX8MM based Boards
+ items:
+ - const: ees,imx8mm-emtop-baseboard # i.MX8MM Emtop SoM on i.MX8M Mini Baseboard V1
+ - const: ees,imx8mm-emtop-som # i.MX8MM Emtop SOM-IMX8MMLPD4 module
+ - const: fsl,imx8mm
+
- description: Engicam i.Core MX8M Mini SoM based boards
items:
- enum:
@@ -858,8 +1011,12 @@ properties:
- description: Toradex Boards with Verdin iMX8M Mini Modules
items:
- enum:
+ - menlo,mx8menlo # Verdin iMX8M Mini Module on i.MX8MM Menlo board
- toradex,verdin-imx8mm-nonwifi-dahlia # Verdin iMX8M Mini Module on Dahlia
- toradex,verdin-imx8mm-nonwifi-dev # Verdin iMX8M Mini Module on Verdin Development Board
+ - toradex,verdin-imx8mm-nonwifi-ivy # Verdin iMX8M Mini Module on Ivy
+ - toradex,verdin-imx8mm-nonwifi-mallow # Verdin iMX8M Mini Module on Mallow
+ - toradex,verdin-imx8mm-nonwifi-yavia # Verdin iMX8M Mini Module on Yavia
- const: toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Module without Wi-Fi / BT
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -869,13 +1026,18 @@ properties:
- enum:
- toradex,verdin-imx8mm-wifi-dahlia # Verdin iMX8M Mini Wi-Fi / BT Module on Dahlia
- toradex,verdin-imx8mm-wifi-dev # Verdin iMX8M Mini Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-imx8mm-wifi-ivy # Verdin iMX8M Mini Wi-Fi / BT Module on Ivy
+ - toradex,verdin-imx8mm-wifi-mallow # Verdin iMX8M Mini Wi-Fi / BT Module on Mallow
+ - toradex,verdin-imx8mm-wifi-yavia # Verdin iMX8M Mini Wi-Fi / BT Module on Yavia
- const: toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Module
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
- description: PHYTEC phyCORE-i.MX8MM SoM based boards
items:
- - const: phytec,imx8mm-phyboard-polis-rdk # phyBOARD-Polis RDK
+ - enum:
+ - phytec,imx8mm-phyboard-polis-rdk # phyBOARD-Polis RDK
+ - phytec,imx8mm-phygate-tauri-l # phyGATE-Tauri-L Gateway
- const: phytec,imx8mm-phycore-som # phyCORE-i.MX8MM SoM
- const: fsl,imx8mm
@@ -892,6 +1054,7 @@ properties:
one compatible is needed.
items:
- enum:
+ - cloos,imx8mm-phg # i.MX8MM Cloos PHG Board
- tq,imx8mm-tqma8mqml-mba8mx # TQ-Systems GmbH i.MX8MM TQMa8MQML SOM on MBa8Mx
- const: tq,imx8mm-tqma8mqml # TQ-Systems GmbH i.MX8MM TQMa8MQML SOM
- const: fsl,imx8mm
@@ -910,7 +1073,10 @@ properties:
- description: Variscite VAR-SOM-MX8MN based boards
items:
- - const: variscite,var-som-mx8mn-symphony
+ - enum:
+ - dimonoff,gateway-evk # i.MX8MN Dimonoff Gateway EVK Board
+ - rve,gateway # i.MX8MN RVE Gateway Board
+ - variscite,var-som-mx8mn-symphony
- const: variscite,var-som-mx8mn
- const: fsl,imx8mn
@@ -928,13 +1094,38 @@ properties:
- description: i.MX8MP based Boards
items:
- enum:
- - dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM
- - dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board
+ - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
+ - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
+ - emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit
- fsl,imx8mp-evk # i.MX8MP EVK Board
+ - fsl,imx8mp-evk-revb4 # i.MX8MP EVK Rev B4 Board
+ - gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
+ - gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
+ - gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
- - toradex,verdin-imx8mp # Verdin iMX8M Plus Modules
- - toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Modules without Wi-Fi / BT
- - toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
+ - gateworks,imx8mp-gw75xx-2x # i.MX8MP Gateworks Board
+ - gateworks,imx8mp-gw82xx-2x # i.MX8MP Gateworks Board
+ - gocontroll,moduline-display # GOcontroll Moduline Display controller
+ - prt,prt8ml # Protonic PRT8ML
+ - skov,imx8mp-skov-basic # SKOV i.MX8MP baseboard without frontplate
+ - skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel
+ - skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel
+ - skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" panel
+ - skov,imx8mp-skov-revc-hdmi # SKOV i.MX8MP climate control without panel
+ - skov,imx8mp-skov-revc-bd500 # SKOV i.MX8MP climate control with LED frontplate
+ - skov,imx8mp-skov-revc-jutouch-jt101tm023 # SKOV i.MX8MP climate control with 10" JuTouch panel
+ - skov,imx8mp-skov-revc-tian-g07017 # SKOV i.MX8MP climate control with 7" panel
+ - ultratronik,imx8mp-ultra-mach-sbc # Ultratronik SBC i.MX8MP based board
+ - ysoft,imx8mp-iota2-lumpy # Y Soft i.MX8MP IOTA2 Lumpy Board
+ - const: fsl,imx8mp
+
+ - description: ABB Boards with i.MX8M Plus Modules from ADLink
+ items:
+ - enum:
+ - abb,imx8mp-aristanetos3-adpismarc # i.MX8MP ABB SoM on PI SMARC Board
+ - abb,imx8mp-aristanetos3-helios # i.MX8MP ABB SoM on helios Board
+ - abb,imx8mp-aristanetos3-proton2s # i.MX8MP ABB SoM on proton2s Board
+ - const: abb,imx8mp-aristanetos3-som # i.MX8MP ABB SoM
- const: fsl,imx8mp
- description: Avnet (MSC Branded) Boards with SM2S i.MX8M Plus Modules
@@ -944,6 +1135,28 @@ properties:
- const: avnet,sm2s-imx8mp # SM2S-IMX8PLUS SoM
- const: fsl,imx8mp
+ - description: Boundary Devices Nitrogen8M Plus ENC Carrier Board
+ items:
+ - const: boundary,imx8mp-nitrogen-enc-carrier-board
+ - const: boundary,imx8mp-nitrogen-som
+ - const: fsl,imx8mp
+
+ - description: Boundary Device Nitrogen8MP Universal SMARC Carrier Board
+ items:
+ - const: boundary,imx8mp-nitrogen-smarc-universal-board
+ - const: boundary,imx8mp-nitrogen-smarc-som
+ - const: fsl,imx8mp
+
+ - description: i.MX8MP DHCOM based Boards
+ items:
+ - enum:
+ - dh,imx8mp-dhcom-drc02 # i.MX8MP DHCOM SoM on DRC02 board
+ - dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board
+ - dh,imx8mp-dhcom-pdk3 # i.MX8MP DHCOM SoM on PDK3 board
+ - dh,imx8mp-dhcom-picoitx # i.MX8MP DHCOM SoM on PicoITX board
+ - const: dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM
+ - const: fsl,imx8mp
+
- description: Engicam i.Core MX8M Plus SoM based boards
items:
- enum:
@@ -951,17 +1164,78 @@ properties:
- const: engicam,icore-mx8mp # i.MX8MP Engicam i.Core MX8M Plus SoM
- const: fsl,imx8mp
+ - description: Kontron i.MX8MP OSM-S SoM based Boards
+ items:
+ - const: kontron,imx8mp-bl-osm-s # Kontron BL i.MX8MP OSM-S Board
+ - const: kontron,imx8mp-osm-s # Kontron i.MX8MP OSM-S SoM
+ - const: fsl,imx8mp
+
+ - description: Kontron i.MX8MP SMARC based Boards
+ items:
+ - const: kontron,imx8mp-smarc-eval-carrier # Kontron i.MX8MP SMARC Eval Carrier
+ - const: kontron,imx8mp-smarc # Kontron i.MX8MP SMARC Module
+ - const: kontron,imx8mp-osm-s # Kontron i.MX8MP OSM-S SoM
+ - const: fsl,imx8mp
+
+ - description: PHYTEC phyCORE-i.MX8MP FPSC based boards
+ items:
+ - enum:
+ - phytec,imx8mp-libra-rdk-fpsc # i.MX 8M Plus Libra RDK
+ - const: phytec,imx8mp-phycore-fpsc # phyCORE-i.MX 8M Plus FPSC
+ - const: fsl,imx8mp
+
- description: PHYTEC phyCORE-i.MX8MP SoM based boards
items:
- const: phytec,imx8mp-phyboard-pollux-rdk # phyBOARD-Pollux RDK
- const: phytec,imx8mp-phycore-som # phyCORE-i.MX8MP SoM
- const: fsl,imx8mp
+ - description: Polyhex DEBIX i.MX8MP based SBCs
+ items:
+ - enum:
+ - polyhex,imx8mp-debix-model-a # Polyhex Debix Model A Board
+ - const: polyhex,imx8mp-debix # Polyhex i.MX8MP Debix SBCs
+ - const: fsl,imx8mp
+
+ - description: Polyhex DEBIX i.MX8MP SOM A based boards
+ items:
+ - enum:
+ - polyhex,imx8mp-debix-som-a-bmb-08 # Polyhex Debix SOM A on SOM A I/O board
+ - const: polyhex,imx8mp-debix-som-a # Polyhex Debix SOM A
+ - const: fsl,imx8mp
+
+ - description: SolidRun i.MX8MP SoM based boards
+ items:
+ - enum:
+ - solidrun,imx8mp-cubox-m # SolidRun i.MX8MP SoM on CuBox-M
+ - solidrun,imx8mp-hummingboard-mate # SolidRun i.MX8MP SoM on HummingBoard Mate
+ - solidrun,imx8mp-hummingboard-pro # SolidRun i.MX8MP SoM on HummingBoard Pro
+ - solidrun,imx8mp-hummingboard-pulse # SolidRun i.MX8MP SoM on HummingBoard Pulse
+ - solidrun,imx8mp-hummingboard-ripple # SolidRun i.MX8MP SoM on HummingBoard Ripple
+ - const: solidrun,imx8mp-sr-som
+ - const: fsl,imx8mp
+
+ - description: TechNexion EDM-G-IMX8M-PLUS SoM based boards
+ items:
+ - enum:
+ - technexion,edm-g-imx8mp-wb # TechNexion EDM-G-IMX8MP SOM on WB-EDM-G
+ - const: technexion,edm-g-imx8mp # TechNexion EDM-G-IMX8MP SOM
+ - const: fsl,imx8mp
+
+ - description: Toradex Boards with SMARC iMX8M Plus Modules
+ items:
+ - const: toradex,smarc-imx8mp-dev # Toradex SMARC iMX8M Plus on Toradex SMARC Development Board
+ - const: toradex,smarc-imx8mp # Toradex SMARC iMX8M Plus Module
+ - const: fsl,imx8mp
+
- description: Toradex Boards with Verdin iMX8M Plus Modules
items:
- enum:
- toradex,verdin-imx8mp-nonwifi-dahlia # Verdin iMX8M Plus Module on Dahlia
- toradex,verdin-imx8mp-nonwifi-dev # Verdin iMX8M Plus Module on Verdin Development Board
+ - toradex,verdin-imx8mp-nonwifi-ivy # Verdin iMX8M Plus Module on Ivy
+ - toradex,verdin-imx8mp-nonwifi-mallow # Verdin iMX8M Plus Module on Mallow
+ - toradex,verdin-imx8mp-nonwifi-yavia # Verdin iMX8M Plus Module on Yavia
- const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -971,6 +1245,9 @@ properties:
- enum:
- toradex,verdin-imx8mp-wifi-dahlia # Verdin iMX8M Plus Wi-Fi / BT Module on Dahlia
- toradex,verdin-imx8mp-wifi-dev # Verdin iMX8M Plus Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-imx8mp-wifi-ivy # Verdin iMX8M Plus Wi-Fi / BT Module on Ivy
+ - toradex,verdin-imx8mp-wifi-mallow # Verdin iMX8M Plus Wi-Fi / BT Module on Mallow
+ - toradex,verdin-imx8mp-wifi-yavia # Verdin iMX8M Plus Wi-Fi / BT Module on Yavia
- const: toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Module
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -983,8 +1260,15 @@ properties:
version as an industrial computing device.
items:
- enum:
- - tq,imx8mp-tqma8mpql-mba8mpxl # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM on MBa8MPxL
- - const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
+ - tq,imx8mp-tqma8mpql-mba8mpxl # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM on MBa8MPxL
+ - tq,imx8mp-tqma8mpql-mba8mp-ras314 # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM on MBa8MP-RAS314
+ - const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
+ - const: fsl,imx8mp
+
+ - description: Variscite VAR-SOM-MX8M Plus based boards
+ items:
+ - const: variscite,var-som-mx8mp-symphony
+ - const: variscite,var-som-mx8mp
- const: fsl,imx8mp
- description: i.MX8MQ based Boards
@@ -996,12 +1280,17 @@ properties:
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- google,imx8mq-phanbell # Google Coral Edge TPU
- kontron,pitx-imx8m # Kontron pITX-imx8m Board
- - mntre,reform2 # MNT Reform2 Laptop
- purism,librem5-devkit # Purism Librem5 devkit
- solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
- technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk
- const: fsl,imx8mq
+ - description: i.MX8MQ NITROGEN SoM based Boards
+ items:
+ - const: mntre,reform2 # MNT Reform2 Laptop
+ - const: boundary,imx8mq-nitrogen8m-som # i.MX8MQ NITROGEN SoM
+ - const: fsl,imx8mq
+
- description: Purism Librem5 phones
items:
- enum:
@@ -1032,6 +1321,26 @@ properties:
items:
- enum:
- fsl,imx8qm-mek # i.MX8QM MEK Board
+ - fsl,imx8qm-mek-revd # i.MX8QM MEK Rev D Board
+ - const: fsl,imx8qm
+
+ - description: i.MX8QM Boards with Toradex Apalis iMX8 Modules
+ items:
+ - enum:
+ - toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation V1.0/V1.1 Board
+ - toradex,apalis-imx8-eval-v1.2 # Apalis iMX8 Module on Apalis Evaluation V1.2 Board
+ - toradex,apalis-imx8-ixora-v1.1 # Apalis iMX8 Module on Ixora V1.1 Carrier Board
+ - const: toradex,apalis-imx8
+ - const: fsl,imx8qm
+
+ - description: i.MX8QM Boards with Toradex Apalis iMX8 V1.1 Modules
+ items:
+ - enum:
+ - toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. V1.0/V1.1 Board
+ - toradex,apalis-imx8-v1.1-eval-v1.2 # Apalis iMX8 V1.1 Module on Apalis Eval. V1.2 Board
+ - toradex,apalis-imx8-v1.1-ixora-v1.1 # Apalis iMX8 V1.1 Module on Ixora V1.1 C. Board
+ - toradex,apalis-imx8-v1.1-ixora-v1.2 # Apalis iMX8 V1.1 Module on Ixora V1.2 C. Board
+ - const: toradex,apalis-imx8-v1.1
- const: fsl,imx8qm
- description: i.MX8QXP based Boards
@@ -1039,7 +1348,7 @@ properties:
- enum:
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
- - toradex,colibri-imx8x # Colibri iMX8X Modules
+ - fsl,imx8qxp-mek-wcpu # i.MX8QXP MEK WCPU Board
- const: fsl,imx8qxp
- description: i.MX8DXL based Boards
@@ -1048,31 +1357,194 @@ properties:
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
- const: fsl,imx8dxl
- - description: i.MX8QXP Boards with Toradex Coilbri iMX8X Modules
+ - description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
items:
- enum:
+ - toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board
- toradex,colibri-imx8x-eval-v3 # Colibri iMX8X Module on Colibri Evaluation Board V3
+ - toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board
+ - toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2
- const: toradex,colibri-imx8x
- - const: fsl,imx8qxp
+ - enum:
+ - fsl,imx8qxp
+ - fsl,imx8dx
+
+ - description:
+ TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip
+ variants. It is designed to be clicked on different carrier boards
+ MBa8Xx is the starterkit
+ oneOf:
+ - items:
+ - enum:
+ - tq,imx8dxp-tqma8xdp-mba8xx # TQ-Systems GmbH TQMa8XDP SOM on MBa8Xx
+ - const: tq,imx8dxp-tqma8xdp # TQ-Systems GmbH TQMa8XDP SOM (with i.MX8DXP)
+ - const: fsl,imx8dxp
+ - items:
+ - enum:
+ - tq,imx8qxp-tqma8xqp-mba8xx # TQ-Systems GmbH TQMa8XQP SOM on MBa8Xx
+ - const: tq,imx8qxp-tqma8xqp # TQ-Systems GmbH TQMa8XQP SOM (with i.MX8QXP)
+ - const: fsl,imx8qxp
+
+ - description:
+ TQMa8XxS is a series of SOM featuring NXP i.MX8X system-on-chip
+ variants. It has the SMARC-2.0 form factor and is designed to be placed on
+ different carrier boards. MB-SMARC-2 is a carrier reference design.
+ oneOf:
+ - items:
+ - enum:
+ - tq,imx8qxp-tqma8xqps-mb-smarc-2 # TQ-Systems GmbH TQMa8QXPS SOM on MB-SMARC-2
+ - const: tq,imx8qxp-tqma8xqps # TQ-Systems GmbH TQMa8QXPS SOM
+ - const: fsl,imx8qxp
+ - items:
+ - enum:
+ - tq,imx8dxp-tqma8xdps-mb-smarc-2 # TQ-Systems GmbH TQMa8XDPS SOM on MB-SMARC-2
+ - const: tq,imx8dxp-tqma8xdps # TQ-Systems GmbH TQMa8XDPS SOM
+ - const: fsl,imx8dxp
- description: i.MX8ULP based Boards
items:
- enum:
+ - fsl,imx8ulp-9x9-evk # i.MX8ULP EVK9 Board
- fsl,imx8ulp-evk # i.MX8ULP EVK Board
- const: fsl,imx8ulp
+ - description: i.MX91 based Boards
+ items:
+ - enum:
+ - fsl,imx91-11x11-evk # i.MX91 11x11 EVK Board
+ - const: fsl,imx91
+
- description: i.MX93 based Boards
items:
- enum:
+ - fsl,imx93-9x9-qsb # i.MX93 9x9 QSB Board
- fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board
+ - fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board
- const: fsl,imx93
+ - description: i.MX94 based Boards
+ items:
+ - enum:
+ - fsl,imx943-evk # i.MX943 EVK Board
+ - const: fsl,imx94
+
+ - description: i.MX95 based Boards
+ items:
+ - enum:
+ - fsl,imx95-15x15-evk # i.MX95 15x15 EVK Board
+ - fsl,imx95-19x19-evk # i.MX95 19x19 EVK Board
+ - toradex,verdin-imx95-19x19-evk # i.MX95 Verdin Evaluation Kit (EVK)
+ - const: fsl,imx95
+
+ - description: PHYTEC i.MX 95 FPSC based Boards
+ items:
+ - enum:
+ - phytec,imx95-libra-rdk-fpsc # Libra-i.MX 95 FPSC
+ - const: phytec,imx95-phycore-fpsc # phyCORE-i.MX 95 FPSC
+ - const: fsl,imx95
+
+ - description: Toradex Boards with SMARC iMX95 Modules
+ items:
+ - const: toradex,smarc-imx95-dev # Toradex SMARC iMX95 on Toradex SMARC Development Board
+ - const: toradex,smarc-imx95 # Toradex SMARC iMX95 Module
+ - const: fsl,imx95
+
+ - description: i.MXRT1050 based Boards
+ items:
+ - enum:
+ - fsl,imxrt1050-evk # i.MXRT1050 EVK Board
+ - const: fsl,imxrt1050
+
+ - description: i.MXRT1170 based Boards
+ items:
+ - enum:
+ - fsl,imxrt1170-evk # i.MXRT1170 EVK Board
+ - const: fsl,imxrt1170
+
+ - description:
+ TQMa91xxLA and TQMa91xxCA are two series of feature compatible SOM
+ using NXP i.MX91 SOC in 11x11 mm package.
+ TQMa91xxLA is designed to be soldered on different carrier boards.
+ TQMa91xxCA is a compatible variant using board to board connectors.
+ All SOM and CPU variants use the same device tree hence only one
+ compatible is needed. Bootloader disables all features not present
+ in the assembled SOC.
+ MBa91xxCA mainboard can be used as starterkit for the SOM
+ soldered on an adapter board or for the connector variant
+ MBa91xxLA mainboard is a single board computer using the solderable
+ SOM variant
+ items:
+ - enum:
+ - tq,imx91-tqma9131-mba91xxca # TQ-Systems GmbH i.MX91 TQMa91xxCA/LA SOM on MBa91xxCA
+ - const: tq,imx91-tqma9131 # TQ-Systems GmbH i.MX91 TQMa91xxCA/LA SOM
+ - const: fsl,imx91
+
+ - description:
+ TQMa93xxLA and TQMa93xxCA are two series of feature compatible SOM
+ using NXP i.MX93 SOC in 11x11 mm package.
+ TQMa93xxLA is designed to be soldered on different carrier boards.
+ TQMa93xxCA is a compatible variant using board to board connectors.
+ All SOM and CPU variants use the same device tree hence only one
+ compatible is needed. Bootloader disables all features not present
+ in the assembled SOC.
+ MBa91xxCA mainboard can be used as starterkit for the SOM
+ soldered on an adapter board or for the connector variant
+ to evaluate RGB display support.
+ MBa93xxCA mainboard can be used as starterkit for the SOM
+ soldered on an adapter board or for the connector variant
+ MBa93xxLA mainboard is a single board computer using the solderable
+ SOM variant
+ items:
+ - enum:
+ - tq,imx93-tqma9352-mba91xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa91xxCA
+ - tq,imx93-tqma9352-mba93xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa93xxCA
+ - tq,imx93-tqma9352-mba93xxla # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA SBC
+ - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
+ - const: fsl,imx93
+
+ - description: PHYTEC phyCORE-i.MX91 SoM based boards
+ items:
+ - enum:
+ - phytec,imx91-phyboard-segin # phyBOARD-Segin with i.MX91
+ - const: phytec,imx91-phycore-som # phyCORE-i.MX91 SoM
+ - const: fsl,imx91
+
+ - description: PHYTEC phyCORE-i.MX93 SoM based boards
+ items:
+ - enum:
+ - phytec,imx93-phyboard-nash # phyBOARD-Nash-i.MX93
+ - phytec,imx93-phyboard-segin # phyBOARD-Segin with i.MX93
+ - const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM
+ - const: fsl,imx93
+
+ - description: Variscite VAR-SOM-MX93 based boards
+ items:
+ - const: variscite,var-som-mx93-symphony
+ - const: variscite,var-som-mx93
+ - const: fsl,imx93
+
+ - description: Kontron OSM-S i.MX93 SoM based boards
+ items:
+ - const: kontron,imx93-bl-osm-s # Kontron BL i.MX93 OSM-S board
+ - const: kontron,imx93-osm-s # Kontron OSM-S i.MX93 SoM
+ - const: fsl,imx93
+
+ - description:
+ TQMa95xxSA is a series of SOM featuring NXP i.MX95 SoC variants.
+ It has the SMARC form factor and is designed to be placed on
+ different carrier boards. MB-SMARC-2 is a carrier reference design.
+ items:
+ - enum:
+ - tq,imx95-tqma9596sa-mb-smarc-2 # TQ-Systems GmbH i.MX95 TQMa95xxSA SOM on MB-SMARC-2
+ - const: tq,imx95-tqma9596sa # TQ-Systems GmbH i.MX95 TQMa95xxSA SOM
+ - const: fsl,imx95
+
- description:
Freescale Vybrid Platform Device Tree Bindings
- For the Vybrid SoC familiy all variants with DDR controller are supported,
+ For the Vybrid SoC family all variants with DDR controller are supported,
which is the VF5xx and VF6xx series. Out of historical reasons, in most
- places the kernel uses vf610 to refer to the whole familiy.
+ places the kernel uses vf610 to refer to the whole family.
The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4
core support.
items:
@@ -1095,7 +1567,6 @@ properties:
- fsl,vf610-twr # VF610 Tower Board
- lwn,bk4 # Liebherr BK4 controller
- phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board
- - toradex,vf610-colibri_vf61 # Colibri VF61 Modules
- const: fsl,vf610
- description: Toradex Colibri VF61 Module on Colibri Evaluation Board
@@ -1127,6 +1598,12 @@ properties:
- fsl,ls1012a-qds
- const: fsl,ls1012a
+ - description: TQ Systems TQMLS12AL SoM on MBLS1012AL board
+ items:
+ - const: tq,ls1012a-tqmls1012al-mbls1012al
+ - const: tq,ls1012a-tqmls1012al
+ - const: fsl,ls1012a
+
- description: LS1021A based Boards
items:
- enum:
@@ -1137,6 +1614,16 @@ properties:
- fsl,ls1021a-twr
- const: fsl,ls1021a
+ - description:
+ TQ-Systems TQMLS102xA is a series of socketable SOM featuring
+ LS102x system-on-chip variants. MBLS102xA mainboard can be used as
+ starterkit.
+ items:
+ - enum:
+ - tq,ls1021a-tqmls1021a-mbls102xa
+ - const: tq,ls1021a-tqmls1021a
+ - const: fsl,ls1021a
+
- description: LS1028A based Boards
items:
- enum:
@@ -1192,6 +1679,13 @@ properties:
- fsl,ls1043a-qds
- const: fsl,ls1043a
+ - description: TQ-Systems LS1043A based Boards
+ items:
+ - enum:
+ - tq,ls1043a-tqmls1043a-mbls10xxa
+ - const: tq,ls1043a-tqmls1043a
+ - const: fsl,ls1043a
+
- description: LS1046A based Boards
items:
- enum:
@@ -1200,6 +1694,13 @@ properties:
- fsl,ls1046a-rdb
- const: fsl,ls1046a
+ - description: TQ-Systems LS1046A based Boards
+ items:
+ - enum:
+ - tq,ls1046a-tqmls1046a-mbls10xxa
+ - const: tq,ls1046a-tqmls1046a
+ - const: fsl,ls1046a
+
- description: LS1088A based Boards
items:
- enum:
@@ -1207,6 +1708,13 @@ properties:
- fsl,ls1088a-rdb
- const: fsl,ls1088a
+ - description: TQ-Systems LS1088A based Boards
+ items:
+ - enum:
+ - tq,ls1088a-tqmls1088a-mbls10xxa
+ - const: tq,ls1088a-tqmls1088a
+ - const: fsl,ls1088a
+
- description: LS2080A based Boards
items:
- enum:
@@ -1215,6 +1723,12 @@ properties:
- fsl,ls2080a-rdb
- const: fsl,ls2080a
+ - description: LS2081A based Boards
+ items:
+ - enum:
+ - fsl,ls2081a-rdb
+ - const: fsl,ls2081a
+
- description: LS2088A based Boards
items:
- enum:
@@ -1232,7 +1746,7 @@ properties:
- fsl,lx2162a-qds
- const: fsl,lx2160a
- - description: SolidRun LX2160A based Boards
+ - description: SolidRun LX2160A CEX-7 based Boards
items:
- enum:
- solidrun,clearfog-cx
@@ -1240,6 +1754,23 @@ properties:
- const: solidrun,lx2160a-cex7
- const: fsl,lx2160a
+ - description: SolidRun LX2162A SoM based Boards
+ items:
+ - enum:
+ - solidrun,lx2162a-clearfog
+ - const: solidrun,lx2162a-som
+ - const: fsl,lx2160a
+
+ - description:
+ TQ-Systems TQMLX2160A is a series of socketable SOM featuring
+ LX2160A system-on-chip variants. MBLX2160A mainboard can be used a
+ starterkit.
+ items:
+ - enum:
+ - tq,lx2160a-tqmlx2160a-mblx2160a
+ - const: tq,lx2160a-tqmlx2160a
+ - const: fsl,lx2160a
+
- description: S32G2 based Boards
items:
- enum:
@@ -1247,6 +1778,12 @@ properties:
- nxp,s32g274a-rdb2
- const: nxp,s32g2
+ - description: S32G3 based Boards
+ items:
+ - enum:
+ - nxp,s32g399a-rdb3
+ - const: nxp,s32g3
+
- description: S32V234 based Boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
new file mode 100644
index 000000000000..99961e5282e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/google.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor platforms
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+description: |
+ ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
+ devices.
+
+ Currently upstream this is devices using "gs101" SoC which is found in Pixel
+ 6, Pixel 6 Pro and Pixel 6a.
+
+ Google have a few different names for the SoC:
+ - Marketing name ("Tensor")
+ - Codename ("Whitechapel")
+ - SoC ID ("gs101")
+ - Die ID ("S5P9845")
+
+ Likewise there are a couple of names for the actual device
+ - Marketing name ("Pixel 6")
+ - Codename ("Oriole")
+
+ Devicetrees should use the lowercased SoC ID and lowercased board codename,
+ e.g. gs101 and gs101-oriole.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Google Pixel 6 or 6 Pro (Oriole or Raven)
+ items:
+ - enum:
+ - google,gs101-oriole
+ - google,gs101-raven
+ - const: google,gs101
+
+ # Bootloader requires empty ect node to be present
+ ect:
+ type: object
+ additionalProperties: false
+
+required:
+ - ect
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml b/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml
index 528dad4cde3c..4fc208d3995e 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml
+++ b/Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.yaml
@@ -29,6 +29,26 @@ properties:
ranges: true
+patternProperties:
+ "^clock@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: hisilicon,hix5hd2-clock
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ required:
+ - compatible
+ - reg
+ - "#clock-cells"
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.yaml b/Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.yaml
index 5a53d433b6f0..7a221e1c09df 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.yaml
+++ b/Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.yaml
@@ -82,6 +82,23 @@ properties:
ranges: true
+patternProperties:
+ '^clock@':
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - hisilicon,hi3620-clock
+ - hisilicon,hi3620-mmc-clock
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml
index b38458022946..540876322040 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/hisilicon/hisilicon.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Hisilicon Platforms Device Tree Bindings
+title: Hisilicon Platforms
maintainers:
- Wei Xu <xuwei5@hisilicon.com>
diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml
index 107e686ab207..53d2ce02b207 100644
--- a/Documentation/devicetree/bindings/arm/intel,keembay.yaml
+++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/intel,keembay.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Keem Bay platform device tree bindings
+title: Keem Bay platform
maintainers:
- Paul J. Murphy <paul.j.murphy@intel.com>
diff --git a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml
index 61a454a40e87..c918837bd41c 100644
--- a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml
+++ b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/intel,socfpga.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel SoCFPGA platform device tree bindings
+title: Intel SoCFPGA platform
maintainers:
- Dinh Nguyen <dinguyen@kernel.org>
@@ -21,6 +21,19 @@ properties:
- intel,socfpga-agilex-n6000
- intel,socfpga-agilex-socdk
- const: intel,socfpga-agilex
+ - description: Agilex3 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex3-socdk
+ - const: intel,socfpga-agilex3
+ - const: intel,socfpga-agilex5
+ - description: Agilex5 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex5-socdk
+ - intel,socfpga-agilex5-socdk-013b
+ - intel,socfpga-agilex5-socdk-nand
+ - const: intel,socfpga-agilex5
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml b/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml
index 230bffeec0e5..b7b430896596 100644
--- a/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml
+++ b/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/intel-ixp4xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel IXP4xx Device Tree Bindings
+title: Intel IXP4xx
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -16,12 +16,30 @@ properties:
oneOf:
- items:
- enum:
+ - actiontec,mi424wr-ac
+ - actiontec,mi424wr-d
+ - adieng,coyote
+ - arcom,vulcan
+ - dlink,dsm-g600-a
+ - freecom,fsg-3
+ - gateway,7001
+ - gateworks,gw2348
+ - goramo,multilink-router
+ - intel,ixdp425
+ - intel,ixdpg425
+ - iom,nas-100d
- linksys,nslu2
+ - netgear,wg302v1
+ - netgear,wg302v2
+ - usr,8200
- welltech,epbx100
+ - linksys,wrv54g
+ - gemtek,gtwx5715
- const: intel,ixp42x
- items:
- enum:
- gateworks,gw2358
+ - intel,kixrp435
- const: intel,ixp43x
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
deleted file mode 100644
index f310bad04483..000000000000
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-TI Keystone Platforms Device Tree Bindings
------------------------------------------------
-
-Boards with Keystone2 based devices (TCI66xxK2H) SOC shall have the
-following properties.
-
-Required properties:
- - compatible: All TI specific devices present in Keystone SOC should be in
- the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
- type UART should use the specified compatible for those devices.
-
-SoC families:
-
-- Keystone 2 generic SoC:
- compatible = "ti,keystone"
-
-SoCs:
-
-- Keystone 2 Hawking/Kepler
- compatible = "ti,k2hk", "ti,keystone"
-- Keystone 2 Lamarr
- compatible = "ti,k2l", "ti,keystone"
-- Keystone 2 Edison
- compatible = "ti,k2e", "ti,keystone"
-- K2G
- compatible = "ti,k2g", "ti,keystone"
-
-Boards:
-- Keystone 2 Hawking/Kepler EVM
- compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
-
-- Keystone 2 Lamarr EVM
- compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"
-
-- Keystone 2 Edison EVM
- compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
-
-- K2G EVM
- compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
-
-- K2G Industrial Communication Engine EVM
- compatible = "ti,k2g-ice", "ti,k2g", "ti-keystone"
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml
index 5cbcacaeb441..4a323e8c785d 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common K3 TI-SCI bindings
+title: Common K3 TI-SCI
maintainers:
- Nishanth Menon <nm@ti.com>
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
index 34f5f877d444..25a2b42105e5 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI-SCI controller device node bindings
+title: TI-SCI controller
maintainers:
- Nishanth Menon <nm@ti.com>
@@ -20,7 +20,7 @@ description: |
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
- See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
+ See https://software-dl.ti.com/tisci/esd/latest/index.html for protocol definition.
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
@@ -61,10 +61,6 @@ properties:
mboxes:
minItems: 2
- ti,system-reboot-controller:
- description: Determines If system reboot can be triggered by SoC reboot
- type: boolean
-
ti,host-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -94,10 +90,9 @@ examples:
- |
pmmc: system-controller@2921800 {
compatible = "ti,k2g-sci";
- ti,system-reboot-controller;
mbox-names = "rx", "tx";
- mboxes= <&msgmgr 5 2>,
- <&msgmgr 0 0>;
+ mboxes = <&msgmgr 5 2>,
+ <&msgmgr 0 0>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
@@ -107,8 +102,8 @@ examples:
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
- mboxes= <&secure_proxy_main 11>,
- <&secure_proxy_main 13>;
+ mboxes = <&secure_proxy_main 11>,
+ <&secure_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x44083000 0x1000>;
diff --git a/Documentation/devicetree/bindings/arm/lge.yaml b/Documentation/devicetree/bindings/arm/lge.yaml
new file mode 100644
index 000000000000..d983ef7fcbd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/lge.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/lge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LG Electronics SoC Platforms
+
+maintainers:
+ - Chanho Min <chanho.min@lge.com>
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - description: Boards with LG1312 Soc
+ items:
+ - const: lge,lg1312-ref
+ - const: lge,lg1312
+
+ - description: Boards with LG1313 SoC
+ items:
+ - const: lge,lg1313-ref
+ - const: lge,lg1313
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.yaml b/Documentation/devicetree/bindings/arm/marvell,berlin.yaml
new file mode 100644
index 000000000000..4e8442980dcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell,berlin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics/Marvell Berlin SoC
+
+maintainers:
+ - Jisheng Zhang <jszhang@kernel.org>
+
+description:
+ According to https://www.synaptics.com/company/news/conexant-marvell
+ Synaptics has acquired the Multimedia Solutions Business of Marvell, so
+ Berlin SoCs are now Synaptics' SoCs.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sony,nsz-gs7
+ - const: marvell,berlin2
+ - const: marvell,berlin
+ - items:
+ - enum:
+ - google,chromecast
+ - valve,steamlink
+ - const: marvell,berlin2cd
+ - const: marvell,berlin
+ - items:
+ - enum:
+ - marvell,berlin2q-dmp
+ - const: marvell,berlin2q
+ - const: marvell,berlin
+ - items:
+ - enum:
+ - marvell,berlin4ct-dmp
+ - marvell,berlin4ct-stb
+ - const: marvell,berlin4ct
+ - const: marvell,berlin
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
deleted file mode 100644
index 64e8c73fc5ab..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings
-----------------------------------------------------------------------
-
-Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families
-shall have the following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armadaxp-98dx3236"
-
-In addition, boards using the Marvell 98DX3336 SoC shall have the
-following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armadaxp-98dx3336"
-
-In addition, boards using the Marvell 98DX4251 SoC shall have the
-following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armadaxp-98dx4251"
diff --git a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt
deleted file mode 100644
index c83245065d44..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt
+++ /dev/null
@@ -1,185 +0,0 @@
-Marvell Armada AP80x System Controller
-======================================
-
-The AP806/AP807 is one of the two core HW blocks of the Marvell Armada
-7K/8K/931x SoCs. It contains system controllers, which provide several
-registers giving access to numerous features: clocks, pin-muxing and
-many other SoC configuration items. This DT binding allows to describe
-these system controllers.
-
-For the top level node:
- - compatible: must be: "syscon", "simple-mfd";
- - reg: register area of the AP80x system controller
-
-SYSTEM CONTROLLER 0
-===================
-
-Clocks:
--------
-
-
-The Device Tree node representing the AP806/AP807 system controller
-provides a number of clocks:
-
- - 0: reference clock of CPU cluster 0
- - 1: reference clock of CPU cluster 1
- - 2: fixed PLL at 1200 Mhz
- - 3: MSS clock, derived from the fixed PLL
-
-Required properties:
-
- - compatible: must be one of:
- * "marvell,ap806-clock"
- * "marvell,ap807-clock"
- - #clock-cells: must be set to 1
-
-Pinctrl:
---------
-
-For common binding part and usage, refer to
-Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
-
-Required properties:
-- compatible must be "marvell,ap806-pinctrl",
-
-Available mpp pins/groups and functions:
-Note: brackets (x) are not part of the mpp name for marvell,function and given
-only for more detailed description in this document.
-
-name pins functions
-================================================================================
-mpp0 0 gpio, sdio(clk), spi0(clk)
-mpp1 1 gpio, sdio(cmd), spi0(miso)
-mpp2 2 gpio, sdio(d0), spi0(mosi)
-mpp3 3 gpio, sdio(d1), spi0(cs0n)
-mpp4 4 gpio, sdio(d2), i2c0(sda)
-mpp5 5 gpio, sdio(d3), i2c0(sdk)
-mpp6 6 gpio, sdio(ds)
-mpp7 7 gpio, sdio(d4), uart1(rxd)
-mpp8 8 gpio, sdio(d5), uart1(txd)
-mpp9 9 gpio, sdio(d6), spi0(cs1n)
-mpp10 10 gpio, sdio(d7)
-mpp11 11 gpio, uart0(txd)
-mpp12 12 gpio, sdio(pw_off), sdio(hw_rst)
-mpp13 13 gpio
-mpp14 14 gpio
-mpp15 15 gpio
-mpp16 16 gpio
-mpp17 17 gpio
-mpp18 18 gpio
-mpp19 19 gpio, uart0(rxd), sdio(pw_off)
-
-GPIO:
------
-For common binding part and usage, refer to
-Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml.
-
-Required properties:
-
-- compatible: "marvell,armada-8k-gpio"
-
-- offset: offset address inside the syscon block
-
-Optional properties:
-
-- marvell,pwm-offset: offset address of PWM duration control registers inside
- the syscon block
-
-Example:
-ap_syscon: system-controller@6f4000 {
- compatible = "syscon", "simple-mfd";
- reg = <0x6f4000 0x1000>;
-
- ap_clk: clock {
- compatible = "marvell,ap806-clock";
- #clock-cells = <1>;
- };
-
- ap_pinctrl: pinctrl {
- compatible = "marvell,ap806-pinctrl";
- };
-
- ap_gpio: gpio {
- compatible = "marvell,armada-8k-gpio";
- offset = <0x1040>;
- ngpios = <19>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&ap_pinctrl 0 0 19>;
- marvell,pwm-offset = <0x10c0>;
- #pwm-cells = <2>;
- clocks = <&ap_clk 3>;
- };
-};
-
-SYSTEM CONTROLLER 1
-===================
-
-Thermal:
---------
-
-For common binding part and usage, refer to
-Documentation/devicetree/bindings/thermal/thermal*.yaml
-
-The thermal IP can probe the temperature all around the processor. It
-may feature several channels, each of them wired to one sensor.
-
-It is possible to setup an overheat interrupt by giving at least one
-critical point to any subnode of the thermal-zone node.
-
-Required properties:
-- compatible: must be one of:
- * marvell,armada-ap806-thermal
-- reg: register range associated with the thermal functions.
-
-Optional properties:
-- interrupts: overheat interrupt handle. Should point to line 18 of the
- SEI irqchip. See interrupt-controller/interrupts.txt
-- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
- to this IP and represents the channel ID. There is one sensor per
- channel. O refers to the thermal IP internal channel, while positive
- IDs refer to each CPU.
-
-Example:
-ap_syscon1: system-controller@6f8000 {
- compatible = "syscon", "simple-mfd";
- reg = <0x6f8000 0x1000>;
-
- ap_thermal: thermal-sensor@80 {
- compatible = "marvell,armada-ap806-thermal";
- reg = <0x80 0x10>;
- interrupt-parent = <&sei>;
- interrupts = <18>;
- #thermal-sensor-cells = <1>;
- };
-};
-
-Cluster clocks:
----------------
-
-Device Tree Clock bindings for cluster clock of Marvell
-AP806/AP807. Each cluster contain up to 2 CPUs running at the same
-frequency.
-
-Required properties:
- - compatible: must be one of:
- * "marvell,ap806-cpu-clock"
- * "marvell,ap807-cpu-clock"
-- #clock-cells : should be set to 1.
-
-- clocks : shall be the input parent clock(s) phandle for the clock
- (one per cluster)
-
-- reg: register range associated with the cluster clocks
-
-ap_syscon1: system-controller@6f8000 {
- compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd";
- reg = <0x6f8000 0x1000>;
-
- cpu_clk: clock-cpu@278 {
- compatible = "marvell,ap806-cpu-clock";
- clocks = <&ap_clk 0>, <&ap_clk 1>;
- #clock-cells = <1>;
- reg = <0x278 0xa30>;
- };
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
deleted file mode 100644
index c6ed90ea6e17..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Marvell Armada 370 and Armada XP Platforms Device Tree Bindings
----------------------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 370 and Armada XP families
-shall have the following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armada-370-xp"
-
-In addition, boards using the Marvell Armada 370 SoC shall have the
-following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armada370"
-
-In addition, boards using the Marvell Armada XP SoC shall have the
-following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armadaxp"
-
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-375.txt b/Documentation/devicetree/bindings/arm/marvell/armada-375.txt
deleted file mode 100644
index 867d0b80cb8f..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-375.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-Marvell Armada 375 Platforms Device Tree Bindings
--------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 375 family shall have the
-following property:
-
-Required root node property:
-
-compatible: must contain "marvell,armada375"
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
deleted file mode 100644
index 29fa93dad52b..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Power management
-----------------
-
-For power management (particularly DVFS and AVS), the North Bridge
-Power Management component is needed:
-
-Required properties:
-- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
-- reg : the register start and length for the North Bridge
- Power Management
-
-Example:
-
-nb_pm: syscon@14000 {
- compatible = "marvell,armada-3700-nb-pm", "syscon";
- reg = <0x14000 0x60>;
-}
-
-AVS
----
-
-For AVS an other component is needed:
-
-Required properties:
-- compatible : should contain "marvell,armada-3700-avs", "syscon";
-- reg : the register start and length for the AVS
-
-Example:
-avs: avs@11500 {
- compatible = "marvell,armada-3700-avs", "syscon";
- reg = <0x11500 0x40>;
-}
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml
index 6905d29f3108..b2f4fe81b97c 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml
@@ -18,10 +18,12 @@ properties:
items:
- enum:
- cznic,turris-mox
+ - glinet,gl-mv1000
- globalscale,espressobin
- marvell,armada-3720-db
- methode,edpu
- methode,udpu
+ - ripe,atlas-v5
- const: marvell,armada3720
- const: marvell,armada3710
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
deleted file mode 100644
index 202953f1887e..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Marvell Armada 38x Platforms Device Tree Bindings
--------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 38x family shall have the
-following property:
-
-Required root node property:
-
- - compatible: must contain "marvell,armada380"
-
-In addition, boards using the Marvell Armada 385 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada385"
-
-In addition, boards using the Marvell Armada 388 SoC shall have the
-following property before the previous one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada388"
-
-Example:
-
-compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
new file mode 100644
index 000000000000..cdf805b5db95
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x Platforms
+
+maintainers:
+ - Gregory CLEMENT <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description:
+ Netgear Armada 380 GS110EM Managed Switch.
+ items:
+ - const: netgear,gs110emx
+ - const: marvell,armada380
+
+ - description:
+ Marvell Armada 385 Development Boards.
+ items:
+ - enum:
+ - marvell,a385-db-amc
+ - marvell,a385-db-ap
+ - const: marvell,armada385
+ - const: marvell,armada380
+
+ - description:
+ SolidRun Armada 385 based single-board computers.
+ items:
+ - enum:
+ - solidrun,clearfog-gtr-l8
+ - solidrun,clearfog-gtr-s4
+ - const: marvell,armada385
+ - const: marvell,armada380
+
+ - description:
+ Kobol Armada 388 based Helios-4 NAS.
+ items:
+ - const: kobol,helios4
+ - const: marvell,armada388
+ - const: marvell,armada385
+ - const: marvell,armada380
+
+ - description:
+ Marvell Armada 388 Development Boards.
+ items:
+ - enum:
+ - marvell,a388-gp
+ - const: marvell,armada388
+ - const: marvell,armada385
+ - const: marvell,armada380
+
+ - description:
+ SolidRun Armada 388 clearfog family single-board computers.
+ items:
+ - enum:
+ - solidrun,clearfog-base-a1
+ - solidrun,clearfog-pro-a1
+ - const: solidrun,clearfog-a1
+ - const: marvell,armada388
+ - const: marvell,armada385
+ - const: marvell,armada380
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
deleted file mode 100644
index 89468664f6ea..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Marvell Armada 39x Platforms Device Tree Bindings
--------------------------------------------------
-
-Boards with a SoC of the Marvell Armada 39x family shall have the
-following property:
-
-Required root node property:
-
- - compatible: must contain "marvell,armada390"
-
-In addition, boards using the Marvell Armada 395 SoC shall have the
-following property before the common "marvell,armada390" one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada395"
-
-Example:
-
-compatible = "marvell,a395-gp", "marvell,armada395", "marvell,armada390";
-
-Boards using the Marvell Armada 398 SoC shall have the following
-property before the common "marvell,armada390" one:
-
-Required root node property:
-
-compatible: must contain "marvell,armada398"
-
-Example:
-
-compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada390";
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index e9bf3054529f..4bc7454a5d3a 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/marvell/armada-7k-8k.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell Armada 7K/8K Platforms Device Tree Bindings
+title: Marvell Armada 7K/8K Platforms
maintainers:
- Gregory CLEMENT <gregory.clement@bootlin.com>
@@ -23,6 +23,9 @@ properties:
- description: Armada 7040 SoC
items:
+ - enum:
+ - globalscale,mochabin
+ - marvell,armada7040-db
- const: marvell,armada7040
- const: marvell,armada-ap806-quad
- const: marvell,armada-ap806
@@ -35,10 +38,32 @@ properties:
- description: Armada 8040 SoC
items:
+ - enum:
+ - iei,puzzle-m801
+ - marvell,armada8040-db
+ - solidrun,clearfog-gt-8k
- const: marvell,armada8040
- const: marvell,armada-ap806-quad
- const: marvell,armada-ap806
+ - description: Armada 8040 SoC MACCHIATOBin Boards
+ items:
+ - enum:
+ - marvell,armada8040-mcbin-doubleshot
+ - marvell,armada8040-mcbin-singleshot
+ - const: marvell,armada8040-mcbin
+ - const: marvell,armada8040
+ - const: marvell,armada-ap806-quad
+ - const: marvell,armada-ap806
+
+ - description: Armada 8080 SoC
+ items:
+ - enum:
+ - marvell,armada-8080-db
+ - const: marvell,armada-8080
+ - const: marvell,armada-ap810-octa
+ - const: marvell,armada-ap810
+
- description: Armada CN9130 SoC with no external CP
items:
- const: marvell,cn9130
@@ -60,4 +85,44 @@ properties:
- const: marvell,armada-ap807-quad
- const: marvell,armada-ap807
+ - description:
+ Alleycat5X (98DX35xx) Reference Design as COM Express Carrier plus
+ Armada CN9130 COM Express CPU module
+ items:
+ - const: marvell,cn9130-ac5x-carrier
+ - const: marvell,rd-ac5x-carrier
+ - const: marvell,cn9130-cpu-module
+ - const: marvell,cn9130
+ - const: marvell,armada-ap807-quad
+ - const: marvell,armada-ap807
+
+ - description:
+ Alleycat5X (98DX35xx) Reference Design as COM Express Carrier plus
+ Armada CN9131 COM Express CPU module
+ items:
+ - const: marvell,cn9131-ac5x-carrier
+ - const: marvell,rd-ac5x-carrier
+ - const: marvell,cn9131-cpu-module
+ - const: marvell,cn9131
+ - const: marvell,armada-ap807-quad
+ - const: marvell,armada-ap807
+
+ - description:
+ SolidRun CN9130 SoM based single-board computers
+ items:
+ - enum:
+ - solidrun,cn9130-clearfog-base
+ - solidrun,cn9130-clearfog-pro
+ - solidrun,cn9131-solidwan
+ - const: solidrun,cn9130-sr-som
+ - const: marvell,cn9130
+
+ - description:
+ SolidRun CN9132 COM-Express Type 7 based single-board computers
+ items:
+ - enum:
+ - solidrun,cn9132-clearfog
+ - const: solidrun,cn9132-sr-cex7
+ - const: marvell,cn9130
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt
deleted file mode 100644
index f3e9624534c6..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Marvell Armada 8KPlus Platforms Device Tree Bindings
-----------------------------------------------------
-
-Boards using a SoC of the Marvell Armada 8KP families must carry
-the following root node property:
-
- - compatible, with one of the following values:
-
- - "marvell,armada-8080", "marvell,armada-ap810-octa", "marvell,armada-ap810"
- when the SoC being used is the Armada 8080
-
-Example:
-
-compatible = "marvell,armada-8080-db", "marvell,armada-8080",
- "marvell,armada-ap810-octa", "marvell,armada-ap810"
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
deleted file mode 100644
index d84105c7c935..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
+++ /dev/null
@@ -1,234 +0,0 @@
-Marvell Armada CP110 System Controller
-======================================
-
-The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
-SoCs. It contains system controllers, which provide several registers
-giving access to numerous features: clocks, pin-muxing and many other
-SoC configuration items. This DT binding allows to describe these
-system controllers.
-
-For the top level node:
- - compatible: must be: "syscon", "simple-mfd";
- - reg: register area of the CP110 system controller
-
-SYSTEM CONTROLLER 0
-===================
-
-Clocks:
--------
-
-The Device Tree node representing this System Controller 0 provides a
-number of clocks:
-
- - a set of core clocks
- - a set of gatable clocks
-
-Those clocks can be referenced by other Device Tree nodes using two
-cells:
- - The first cell must be 0 or 1. 0 for the core clocks and 1 for the
- gatable clocks.
- - The second cell identifies the particular core clock or gatable
- clocks.
-
-The following clocks are available:
- - Core clocks
- - 0 0 APLL
- - 0 1 PPv2 core
- - 0 2 EIP
- - 0 3 Core
- - 0 4 NAND core
- - 0 5 SDIO core
- - Gatable clocks
- - 1 0 Audio
- - 1 1 Comm Unit
- - 1 2 NAND
- - 1 3 PPv2
- - 1 4 SDIO
- - 1 5 MG Domain
- - 1 6 MG Core
- - 1 7 XOR1
- - 1 8 XOR0
- - 1 9 GOP DP
- - 1 11 PCIe x1 0
- - 1 12 PCIe x1 1
- - 1 13 PCIe x4
- - 1 14 PCIe / XOR
- - 1 15 SATA
- - 1 16 SATA USB
- - 1 17 Main
- - 1 18 SD/MMC/GOP
- - 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
- - 1 22 USB3H0
- - 1 23 USB3H1
- - 1 24 USB3 Device
- - 1 25 EIP150
- - 1 26 EIP197
-
-Required properties:
-
- - compatible: must be:
- "marvell,cp110-clock"
- - #clock-cells: must be set to 2
-
-Pinctrl:
---------
-
-For common binding part and usage, refer to the file
-Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
-
-Required properties:
-
-- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl",
- "marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl"
- depending on the specific variant of the SoC being used.
-
-Available mpp pins/groups and functions:
-Note: brackets (x) are not part of the mpp name for marvell,function and given
-only for more detailed description in this document.
-
-name pins functions
-================================================================================
-mpp0 0 gpio, dev(ale1), au(i2smclk), ge0(rxd3), tdm(pclk), ptp(pulse), mss_i2c(sda), uart0(rxd), sata0(present_act), ge(mdio)
-mpp1 1 gpio, dev(ale0), au(i2sdo_spdifo), ge0(rxd2), tdm(drx), ptp(clk), mss_i2c(sck), uart0(txd), sata1(present_act), ge(mdc)
-mpp2 2 gpio, dev(ad15), au(i2sextclk), ge0(rxd1), tdm(dtx), mss_uart(rxd), ptp(pclk_out), i2c1(sck), uart1(rxd), sata0(present_act), xg(mdc)
-mpp3 3 gpio, dev(ad14), au(i2slrclk), ge0(rxd0), tdm(fsync), mss_uart(txd), pcie(rstoutn), i2c1(sda), uart1(txd), sata1(present_act), xg(mdio)
-mpp4 4 gpio, dev(ad13), au(i2sbclk), ge0(rxctl), tdm(rstn), mss_uart(rxd), uart1(cts), pcie0(clkreq), uart3(rxd), ge(mdc)
-mpp5 5 gpio, dev(ad12), au(i2sdi), ge0(rxclk), tdm(intn), mss_uart(txd), uart1(rts), pcie1(clkreq), uart3(txd), ge(mdio)
-mpp6 6 gpio, dev(ad11), ge0(txd3), spi0(csn2), au(i2sextclk), sata1(present_act), pcie2(clkreq), uart0(rxd), ptp(pulse)
-mpp7 7 gpio, dev(ad10), ge0(txd2), spi0(csn1), spi1(csn1), sata0(present_act), led(data), uart0(txd), ptp(clk)
-mpp8 8 gpio, dev(ad9), ge0(txd1), spi0(csn0), spi1(csn0), uart0(cts), led(stb), uart2(rxd), ptp(pclk_out), synce1(clk)
-mpp9 9 gpio, dev(ad8), ge0(txd0), spi0(mosi), spi1(mosi), pcie(rstoutn), synce2(clk)
-mpp10 10 gpio, dev(readyn), ge0(txctl), spi0(miso), spi1(miso), uart0(cts), sata1(present_act)
-mpp11 11 gpio, dev(wen1), ge0(txclkout), spi0(clk), spi1(clk), uart0(rts), led(clk), uart2(txd), sata0(present_act)
-mpp12 12 gpio, dev(clk_out), nf(rbn1), spi1(csn1), ge0(rxclk)
-mpp13 13 gpio, dev(burstn), nf(rbn0), spi1(miso), ge0(rxctl), mss_spi(miso)
-mpp14 14 gpio, dev(bootcsn), dev(csn0), spi1(csn0), spi0(csn3), au(i2sextclk), spi0(miso), sata0(present_act), mss_spi(csn)
-mpp15 15 gpio, dev(ad7), spi1(mosi), spi0(mosi), mss_spi(mosi), ptp(pulse_cp2cp)
-mpp16 16 gpio, dev(ad6), spi1(clk), mss_spi(clk)
-mpp17 17 gpio, dev(ad5), ge0(txd3)
-mpp18 18 gpio, dev(ad4), ge0(txd2), ptp(clk_cp2cp)
-mpp19 19 gpio, dev(ad3), ge0(txd1), wakeup(out_cp2cp)
-mpp20 20 gpio, dev(ad2), ge0(txd0)
-mpp21 21 gpio, dev(ad1), ge0(txctl), sei(in_cp2cp)
-mpp22 22 gpio, dev(ad0), ge0(txclkout), wakeup(in_cp2cp)
-mpp23 23 gpio, dev(a1), au(i2smclk), link(rd_in_cp2cp)
-mpp24 24 gpio, dev(a0), au(i2slrclk)
-mpp25 25 gpio, dev(oen), au(i2sdo_spdifo)
-mpp26 26 gpio, dev(wen0), au(i2sbclk)
-mpp27 27 gpio, dev(csn0), spi1(miso), mss_gpio4, ge0(rxd3), spi0(csn4), ge(mdio), sata0(present_act), uart0(rts), rei(in_cp2cp)
-mpp28 28 gpio, dev(csn1), spi1(csn0), mss_gpio5, ge0(rxd2), spi0(csn5), pcie2(clkreq), ptp(pulse), ge(mdc), sata1(present_act), uart0(cts), led(data)
-mpp29 29 gpio, dev(csn2), spi1(mosi), mss_gpio6, ge0(rxd1), spi0(csn6), pcie1(clkreq), ptp(clk), mss_i2c(sda), sata0(present_act), uart0(rxd), led(stb)
-mpp30 30 gpio, dev(csn3), spi1(clk), mss_gpio7, ge0(rxd0), spi0(csn7), pcie0(clkreq), ptp(pclk_out), mss_i2c(sck), sata1(present_act), uart0(txd), led(clk)
-mpp31 31 gpio, dev(a2), mss_gpio4, pcie(rstoutn), ge(mdc)
-mpp32 32 gpio, mii(col), mii(txerr), mss_spi(miso), tdm(drx), au(i2sextclk), au(i2sdi), ge(mdio), sdio(v18_en), pcie1(clkreq), mss_gpio0
-mpp33 33 gpio, mii(txclk), sdio(pwr10), mss_spi(csn), tdm(fsync), au(i2smclk), sdio(bus_pwr), xg(mdio), pcie2(clkreq), mss_gpio1
-mpp34 34 gpio, mii(rxerr), sdio(pwr11), mss_spi(mosi), tdm(dtx), au(i2slrclk), sdio(wr_protect), ge(mdc), pcie0(clkreq), mss_gpio2
-mpp35 35 gpio, sata1(present_act), i2c1(sda), mss_spi(clk), tdm(pclk), au(i2sdo_spdifo), sdio(card_detect), xg(mdio), ge(mdio), pcie(rstoutn), mss_gpio3
-mpp36 36 gpio, synce2(clk), i2c1(sck), ptp(clk), synce1(clk), au(i2sbclk), sata0(present_act), xg(mdc), ge(mdc), pcie2(clkreq), mss_gpio5
-mpp37 37 gpio, uart2(rxd), i2c0(sck), ptp(pclk_out), tdm(intn), mss_i2c(sck), sata1(present_act), ge(mdc), xg(mdc), pcie1(clkreq), mss_gpio6, link(rd_out_cp2cp)
-mpp38 38 gpio, uart2(txd), i2c0(sda), ptp(pulse), tdm(rstn), mss_i2c(sda), sata0(present_act), ge(mdio), xg(mdio), au(i2sextclk), mss_gpio7, ptp(pulse_cp2cp)
-mpp39 39 gpio, sdio(wr_protect), au(i2sbclk), ptp(clk), spi0(csn1), sata1(present_act), mss_gpio0
-mpp40 40 gpio, sdio(pwr11), synce1(clk), mss_i2c(sda), au(i2sdo_spdifo), ptp(pclk_out), spi0(clk), uart1(txd), ge(mdio), sata0(present_act), mss_gpio1
-mpp41 41 gpio, sdio(pwr10), sdio(bus_pwr), mss_i2c(sck), au(i2slrclk), ptp(pulse), spi0(mosi), uart1(rxd), ge(mdc), sata1(present_act), mss_gpio2, rei(out_cp2cp)
-mpp42 42 gpio, sdio(v18_en), sdio(wr_protect), synce2(clk), au(i2smclk), mss_uart(txd), spi0(miso), uart1(cts), xg(mdc), sata0(present_act), mss_gpio4
-mpp43 43 gpio, sdio(card_detect), synce1(clk), au(i2sextclk), mss_uart(rxd), spi0(csn0), uart1(rts), xg(mdio), sata1(present_act), mss_gpio5, wakeup(out_cp2cp)
-mpp44 44 gpio, ge1(txd2), uart0(rts), ptp(clk_cp2cp)
-mpp45 45 gpio, ge1(txd3), uart0(txd), pcie(rstoutn)
-mpp46 46 gpio, ge1(txd1), uart1(rts)
-mpp47 47 gpio, ge1(txd0), spi1(clk), uart1(txd), ge(mdc)
-mpp48 48 gpio, ge1(txctl_txen), spi1(mosi), xg(mdc), wakeup(in_cp2cp)
-mpp49 49 gpio, ge1(txclkout), mii(crs), spi1(miso), uart1(rxd), ge(mdio), pcie0(clkreq), sdio(v18_en), sei(out_cp2cp)
-mpp50 50 gpio, ge1(rxclk), mss_i2c(sda), spi1(csn0), uart2(txd), uart0(rxd), xg(mdio), sdio(pwr11)
-mpp51 51 gpio, ge1(rxd0), mss_i2c(sck), spi1(csn1), uart2(rxd), uart0(cts), sdio(pwr10)
-mpp52 52 gpio, ge1(rxd1), synce1(clk), synce2(clk), spi1(csn2), uart1(cts), led(clk), pcie(rstoutn), pcie0(clkreq)
-mpp53 53 gpio, ge1(rxd2), ptp(clk), spi1(csn3), uart1(rxd), led(stb), sdio(led)
-mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio_wp(wr_protect)
-mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio_cd(card_detect)
-mpp56 56 gpio, tdm(drx), au(i2sdo_spdifo), spi0(clk), uart1(rxd), sata1(present_act), sdio(clk)
-mpp57 57 gpio, mss_i2c(sda), ptp(pclk_out), tdm(intn), au(i2sbclk), spi0(mosi), uart1(txd), sata0(present_act), sdio(cmd)
-mpp58 58 gpio, mss_i2c(sck), ptp(clk), tdm(rstn), au(i2sdi), spi0(miso), uart1(cts), led(clk), sdio(d0)
-mpp59 59 gpio, mss_gpio7, synce2(clk), tdm(fsync), au(i2slrclk), spi0(csn0), uart0(cts), led(stb), uart1(txd), sdio(d1)
-mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(rts), led(data), uart1(rxd), sdio(d2)
-mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
-mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
-
-GPIO:
------
-
-For common binding part and usage, refer to
-Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml.
-
-Required properties:
-
-- compatible: "marvell,armada-8k-gpio"
-
-- offset: offset address inside the syscon block
-
-Example:
-
-CP110_LABEL(syscon0): system-controller@440000 {
- compatible = "syscon", "simple-mfd";
- reg = <0x440000 0x1000>;
-
- CP110_LABEL(clk): clock {
- compatible = "marvell,cp110-clock";
- #clock-cells = <2>;
- };
-
- CP110_LABEL(pinctrl): pinctrl {
- compatible = "marvell,armada-8k-cpm-pinctrl";
- };
-
- CP110_LABEL(gpio1): gpio@100 {
- compatible = "marvell,armada-8k-gpio";
- offset = <0x100>;
- ngpios = <32>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&CP110_LABEL(pinctrl) 0 0 32>;
- };
-
-};
-
-SYSTEM CONTROLLER 1
-===================
-
-Thermal:
---------
-
-The thermal IP can probe the temperature all around the processor. It
-may feature several channels, each of them wired to one sensor.
-
-It is possible to setup an overheat interrupt by giving at least one
-critical point to any subnode of the thermal-zone node.
-
-For common binding part and usage, refer to
-Documentation/devicetree/bindings/thermal/thermal*.yaml
-
-Required properties:
-- compatible: must be one of:
- * marvell,armada-cp110-thermal
-- reg: register range associated with the thermal functions.
-
-Optional properties:
-- interrupts-extended: overheat interrupt handle. Should point to
- a line of the ICU-SEI irqchip (116 is what is usually used by the
- firmware). The ICU-SEI will redirect towards interrupt line #37 of the
- AP SEI which is shared across all CPs.
- See interrupt-controller/interrupts.txt
-- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
- to this IP and represents the channel ID. There is one sensor per
- channel. O refers to the thermal IP internal channel.
-
-Example:
-CP110_LABEL(syscon1): system-controller@6f8000 {
- compatible = "syscon", "simple-mfd";
- reg = <0x6f8000 0x1000>;
-
- CP110_LABEL(thermal): thermal-sensor@70 {
- compatible = "marvell,armada-cp110-thermal";
- reg = <0x70 0x10>;
- interrupts-extended = <&CP110_LABEL(icu_sei) 116 IRQ_TYPE_LEVEL_HIGH>;
- #thermal-sensor-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
deleted file mode 100644
index 98cce9a653eb..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Marvell Kirkwood Platforms Device Tree Bindings
------------------------------------------------
-
-Boards with a SoC of the Marvell Kirkwood
-shall have the following property:
-
-Required root node property:
-
-compatible: must contain "marvell,kirkwood";
-
-In order to support the kirkwood cpufreq driver, there must be a node
-cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave",
-where the "powersave" clock is a gating clock used to switch the CPU
-between the "cpu_clk" and the "ddrclk".
-
-Example:
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- device_type = "cpu";
- compatible = "marvell,sheeva-88SV131";
- clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>;
- clock-names = "cpu_clk", "ddrclk", "powersave";
- };
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,armada-370-xp.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,armada-370-xp.yaml
new file mode 100644
index 000000000000..e65eadfbd097
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,armada-370-xp.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+---
+$id: http://devicetree.org/schemas/arm/marvell/marvell,armada-370-xp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 370 and Armada XP platforms
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ctera,c200-v2
+ - dlink,dns327l
+ - globalscale,mirabox
+ - netgear,readynas-102
+ - netgear,readynas-104
+ - marvell,a370-db
+ - marvell,a370-rd
+ - seagate,dart-2
+ - seagate,dart-4
+ - seagate,cumulus-max
+ - seagate,cumulus
+ - synology,ds213j
+ - const: marvell,armada370
+ - const: marvell,armada-370-xp
+
+ - items:
+ - enum:
+ - mikrotik,crs305-1g-4s
+ - mikrotik,crs326-24g-2s
+ - mikrotik,crs328-4c-20s-4s
+ - const: marvell,armadaxp-98dx3236
+ - const: marvell,armada-370-xp
+
+ - items:
+ - const: marvell,db-xc3-24g4xg
+ - const: marvell,armadaxp-98dx3336
+ - const: marvell,armada-370-xp
+
+ - items:
+ - const: marvell,db-dxbc2
+ - const: marvell,armadaxp-98dx4251
+ - const: marvell,armada-370-xp
+
+ - items:
+ - enum:
+ - lenovo,ix4-300d
+ - linksys,mamba
+ - marvell,rd-axpwifiap
+ - netgear,readynas-2120
+ - synology,ds414
+ - const: marvell,armadaxp-mv78230
+ - const: marvell,armadaxp
+ - const: marvell,armada-370-xp
+
+ - items:
+ - const: plathome,openblocks-ax3-4
+ - const: marvell,armadaxp-mv78260
+ - const: marvell,armadaxp
+ - const: marvell,armada-370-xp
+
+ - items:
+ - enum:
+ - marvell,axp-db
+ - marvell,axp-gp
+ - marvell,axp-matrix
+ - const: marvell,armadaxp-mv78460
+ - const: marvell,armadaxp
+ - const: marvell,armada-370-xp
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,armada375.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,armada375.yaml
new file mode 100644
index 000000000000..81c33e46fecc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,armada375.yaml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/marvell,armada375.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 375 Platform
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ items:
+ - const: marvell,a375-db
+ - const: marvell,armada375
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,armada390.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,armada390.yaml
new file mode 100644
index 000000000000..5ff6a5439525
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,armada390.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/marvell,armada390.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 39x Platforms
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - const: marvell,a390-db
+ - const: marvell,armada390
+ - items:
+ - enum:
+ - marvell,a398-db
+ - const: marvell,armada398
+ - const: marvell,armada390
+ - items:
+ - enum:
+ - marvell,a395-gp
+ - const: marvell,armada395
+ - const: marvell,armada390
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
deleted file mode 100644
index aaaf64c56e44..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Marvell Dove Platforms Device Tree Bindings
------------------------------------------------
-
-Boards with a Marvell Dove SoC shall have the following properties:
-
-Required root node property:
-- compatible: must contain "marvell,dove";
-
-* Global Configuration registers
-
-Global Configuration registers of Dove SoC are shared by a syscon node.
-
-Required properties:
-- compatible: must contain "marvell,dove-global-config" and "syscon".
-- reg: base address and size of the Global Configuration registers.
-
-Example:
-
-gconf: global-config@e802c {
- compatible = "marvell,dove-global-config", "syscon";
- reg = <0xe802c 0x14>;
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,dove.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.yaml
new file mode 100644
index 000000000000..a37804fb30c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/marvell,dove.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Dove SoC
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - compulab,cm-a510
+ - solidrun,cubox
+ - globalscale,d2plug
+ - globalscale,d3plug
+ - marvell,dove-db
+ - const: marvell,dove
+ - items:
+ - const: solidrun,cubox-es
+ - const: solidrun,cubox
+ - const: marvell,dove
+ - items:
+ - const: compulab,sbc-a510
+ - const: compulab,cm-a510
+ - const: marvell,dove
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
deleted file mode 100644
index 7d28fe4bf654..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
+++ /dev/null
@@ -1,105 +0,0 @@
-Marvell Kirkwood SoC Family Device Tree Bindings
-------------------------------------------------
-
-Boards with a SoC of the Marvell Kirkwook family, eg 88f6281
-
-* Required root node properties:
-compatible: must contain "marvell,kirkwood"
-
-In addition, the above compatible shall be extended with the specific
-SoC. Currently known SoC compatibles are:
-
-"marvell,kirkwood-88f6192"
-"marvell,kirkwood-88f6281"
-"marvell,kirkwood-88f6282"
-"marvell,kirkwood-88f6283"
-"marvell,kirkwood-88f6702"
-"marvell,kirkwood-98DX4122"
-
-And in addition, the compatible shall be extended with the specific
-board. Currently known boards are:
-
-"buffalo,linkstation-lsqvl"
-"buffalo,linkstation-lsvl"
-"buffalo,linkstation-lswsxl"
-"buffalo,linkstation-lswxl"
-"buffalo,linkstation-lswvl"
-"buffalo,lschlv2"
-"buffalo,lsxhl"
-"buffalo,lsxl"
-"cloudengines,pogo02"
-"cloudengines,pogoplugv4"
-"dlink,dns-320"
-"dlink,dns-320-a1"
-"dlink,dns-325"
-"dlink,dns-325-a1"
-"dlink,dns-kirkwood"
-"excito,b3"
-"globalscale,dreamplug-003-ds2001"
-"globalscale,guruplug"
-"globalscale,guruplug-server-plus"
-"globalscale,sheevaplug"
-"globalscale,sheevaplug"
-"globalscale,sheevaplug-esata"
-"globalscale,sheevaplug-esata-rev13"
-"iom,iconnect"
-"iom,iconnect-1.1"
-"iom,ix2-200"
-"keymile,km_kirkwood"
-"lacie,cloudbox"
-"lacie,inetspace_v2"
-"lacie,laplug"
-"lacie,nas2big"
-"lacie,netspace_lite_v2"
-"lacie,netspace_max_v2"
-"lacie,netspace_mini_v2"
-"lacie,netspace_v2"
-"marvell,db-88f6281-bp"
-"marvell,db-88f6282-bp"
-"marvell,mv88f6281gtw-ge"
-"marvell,rd88f6281"
-"marvell,rd88f6281"
-"marvell,rd88f6281-a0"
-"marvell,rd88f6281-a1"
-"mpl,cec4"
-"mpl,cec4-10"
-"netgear,readynas"
-"netgear,readynas"
-"netgear,readynas-duo-v2"
-"netgear,readynas-nv+-v2"
-"plathome,openblocks-a6"
-"plathome,openblocks-a7"
-"raidsonic,ib-nas6210"
-"raidsonic,ib-nas6210-b"
-"raidsonic,ib-nas6220"
-"raidsonic,ib-nas6220-b"
-"raidsonic,ib-nas62x0"
-"seagate,dockstar"
-"seagate,goflexnet"
-"synology,ds109"
-"synology,ds110jv10"
-"synology,ds110jv20"
-"synology,ds110jv30"
-"synology,ds111"
-"synology,ds209"
-"synology,ds210jv10"
-"synology,ds210jv20"
-"synology,ds212"
-"synology,ds212jv10"
-"synology,ds212jv20"
-"synology,ds212pv10"
-"synology,ds409"
-"synology,ds409slim"
-"synology,ds410j"
-"synology,ds411"
-"synology,ds411j"
-"synology,ds411slim"
-"synology,ds413jv10"
-"synology,rs212"
-"synology,rs409"
-"synology,rs411"
-"synology,rs812"
-"usi,topkick"
-"usi,topkick-1281P2"
-"zyxel,nsa310"
-"zyxel,nsa310a"
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.yaml
new file mode 100644
index 000000000000..120784066833
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.yaml
@@ -0,0 +1,266 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/marvell,kirkwood.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Kirkwood SoC Family
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qnap,ts219
+ - qnap,ts419
+ - synology,ds110
+ - synology,ds111
+ - synology,ds209
+ - synology,ds409slim
+ - synology,ds411j
+ - synology,ds411slim
+ - synology,rs212
+ - synology,rs409
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds109
+ - const: synology,ds110jv20
+ - const: synology,ds110
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds110jv10
+ - const: synology,ds110jv30
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds210jv10
+ - const: synology,ds210jv20
+ - const: synology,ds210jv30
+ - const: synology,ds211j
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds212jv10
+ - const: synology,ds212jv20
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds212
+ - const: synology,ds212pv10
+ - const: synology,ds212pv10
+ - const: synology,ds212pv20
+ - const: synology,ds213airv10
+ - const: synology,ds213v10
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds409
+ - const: synology,ds410j
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,ds411
+ - const: synology,ds413jv10
+ - const: marvell,kirkwood
+
+ - items:
+ - const: synology,rs411
+ - const: synology,rs812
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - cloudengines,pogoplugv4
+ - lacie,laplug
+ - lacie,netspace_lite_v2
+ - lacie,netspace_mini_v2
+ - marvell,rd88f6192
+ - seagate,blackarmor-nas220
+ - enum:
+ - marvell,kirkwood-88f6192
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - buffalo,lswsxl
+ - buffalo,lswxl
+ - checkpoint,l-50
+ - cloudengines,pogoe02
+ - ctera,c200-v1
+ - dlink,dir-665
+ - endian,4i-edge-200
+ - excito,b3
+ - globalscale,sheevaplug
+ - hp,t5325
+ - iom,ix2-200
+ - lacie,inetspace_v2
+ - lacie,netspace_v2
+ - lacie,netspace_max_v2
+ - marvell,db-88f6281-bp
+ - marvell,mv88f6281gtw-ge
+ - seagate,dockstar
+ - seagate,goflexnet
+ - zyxel,nsa310
+ - zyxel,nsa320
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - buffalo,lschlv2
+ - buffalo,lsxhl
+ - const: buffalo,lsxl
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: dlink,dns-320-a1
+ - const: dlink,dns-320
+ - const: dlink,dns-kirkwood
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: dlink,dns-325-a1
+ - const: dlink,dns-325
+ - const: dlink,dns-kirkwood
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: globalscale,dreamplug-003-ds2001
+ - const: globalscale,dreamplug
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: globalscale,guruplug-server-plus
+ - const: globalscale,guruplug
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: globalscale,sheevaplug-esata-rev13
+ - const: globalscale,sheevaplug-esata
+ - const: globalscale,sheevaplug
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: iom,iconnect-1.1
+ - const: iom,iconnect
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: lacie,d2net_v2
+ - const: lacie,netxbig
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+ - items:
+ - enum:
+ - lacie,net2big_v2
+ - lacie,net5big_v2
+ - const: lacie,netxbig
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - marvell,openrd-base
+ - marvell,openrd-client
+ - marvell,openrd-ultimate
+ - const: marvell,openrd
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - marvell,rd88f6281-a
+ - marvell,rd88f6281-z0
+ - const: marvell,rd88f6281
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: mpl,cec4-10
+ - const: mpl,cec4
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: raidsonic,ib-nas6210-b
+ - const: raidsonic,ib-nas6220-b
+ - const: raidsonic,ib-nas6210
+ - const: raidsonic,ib-nas6220
+ - const: raidsonic,ib-nas62x0
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - const: zyxel,nsa310a
+ - const: zyxel,nsa310
+ - const: marvell,kirkwood-88f6281
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - buffalo,lsqvl
+ - buffalo,lsvl
+ - buffalo,lswvl
+ - linksys,viper
+ - marvell,db-88f6282-bp
+ - zyxel,nsa325
+ - const: marvell,kirkwood-88f6282
+ - const: marvell,kirkwood
+
+ - items:
+ - const: lacie,nas2big
+ - const: lacie,netxbig
+ - const: marvell,kirkwood-88f6282
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - netgear,readynas-duo-v2
+ - netgear,readynas-nv+-v2
+ - const: netgear,readynas
+ - const: marvell,kirkwood-88f6282
+ - const: marvell,kirkwood
+
+ - items:
+ - const: usi,topkick-1281P2
+ - const: usi,topkick
+ - const: marvell,kirkwood-88f6282
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - plathome,openblocks-a6
+ - plathome,openblocks-a7
+ - const: marvell,kirkwood-88f6283
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - lacie,cloudbox
+ - zyxel,nsa310s
+ - const: marvell,kirkwood-88f6702
+ - const: marvell,kirkwood
+
+ - items:
+ - enum:
+ - keymile,km_fixedeth
+ - keymile,km_kirkwood
+ - const: marvell,kirkwood-98DX4122
+ - const: marvell,kirkwood
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
deleted file mode 100644
index 748a8f287462..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Marvell Orion SoC Family Device Tree Bindings
----------------------------------------------
-
-Boards with a SoC of the Marvell Orion family, eg 88f5181
-
-* Required root node properties:
-compatible: must contain "marvell,orion5x"
-
-In addition, the above compatible shall be extended with the specific
-SoC. Currently known SoC compatibles are:
-
-"marvell,orion5x-88f5181"
-"marvell,orion5x-88f5182"
-
-And in addition, the compatible shall be extended with the specific
-board. Currently known boards are:
-
-"buffalo,lsgl"
-"buffalo,lswsgl"
-"buffalo,lswtgl"
-"lacie,ethernet-disk-mini-v2"
-"lacie,d2-network"
-"marvell,rd-88f5182-nas"
-"maxtor,shared-storage-2"
-"netgear,wnr854t"
diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.yaml b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.yaml
new file mode 100644
index 000000000000..c0417591b2be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/marvell,orion5x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Orion5x SoC Family
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - netgear,wnr854t
+ - const: marvell,orion5x-88f5181
+ - const: marvell,orion5x
+ - items:
+ - enum:
+ - buffalo,kurobox-pro
+ - buffalo,lschl
+ - buffalo,lsgl
+ - buffalo,lswsgl
+ - buffalo,lswtgl
+ - lacie,ethernet-disk-mini-v2
+ - lacie,d2-network
+ - marvell,rd-88f5182-nas
+ - maxtor,shared-storage-2
+ - const: marvell,orion5x-88f5182
+ - const: marvell,orion5x
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 07c0ea94e850..718d732174b9 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/mediatek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek SoC based Platforms Device Tree Bindings
+title: MediaTek SoC based Platforms
maintainers:
- Sean Wang <sean.wang@mediatek.com>
@@ -17,6 +17,7 @@ properties:
const: '/'
compatible:
oneOf:
+ # Sort by SoC (last) compatible, then board compatible
- items:
- enum:
- mediatek,mt2701-evb
@@ -28,10 +29,16 @@ properties:
- const: mediatek,mt2712
- items:
- enum:
+ - jty,d101
+ - lenovo,a369i
+ - const: mediatek,mt6572
+ - items:
+ - enum:
- mediatek,mt6580-evbp1
- const: mediatek,mt6580
- items:
- enum:
+ - alcatel,yarisxl
- prestigio,pmt5008-3g
- const: mediatek,mt6582
- items:
@@ -58,6 +65,7 @@ properties:
- items:
- enum:
- mediatek,mt6795-evb
+ - sony,xperia-m5
- const: mediatek,mt6795
- items:
- enum:
@@ -83,6 +91,15 @@ properties:
- const: mediatek,mt7629
- items:
- enum:
+ - cudy,wr3000-v1
+ - openwrt,one
+ - xiaomi,ax3000t
+ - const: mediatek,mt7981b
+ - items:
+ - enum:
+ - acelink,ew-7886cax
+ - bananapi,bpi-r3
+ - bananapi,bpi-r3mini
- mediatek,mt7986a-rfb
- const: mediatek,mt7986a
- items:
@@ -91,6 +108,20 @@ properties:
- const: mediatek,mt7986b
- items:
- enum:
+ - bananapi,bpi-r4
+ - const: mediatek,mt7988a
+ - items:
+ - const: bananapi,bpi-r4-2g5
+ - const: bananapi,bpi-r4
+ - const: mediatek,mt7988a
+ - items:
+ - enum:
+ - bananapi,bpi-r4-pro-4e
+ - bananapi,bpi-r4-pro-8x
+ - const: bananapi,bpi-r4-pro
+ - const: mediatek,mt7988a
+ - items:
+ - enum:
- mediatek,mt8127-moose
- const: mediatek,mt8127
- items:
@@ -127,60 +158,10 @@ properties:
- enum:
- mediatek,mt8173-evb
- const: mediatek,mt8173
- - items:
- - enum:
- - mediatek,mt8183-evb
- - const: mediatek,mt8183
- - description: Google Hayato
- items:
- - const: google,hayato-rev1
- - const: google,hayato
- - const: mediatek,mt8192
- - description: Google Spherion (Acer Chromebook 514)
- items:
- - const: google,spherion-rev3
- - const: google,spherion-rev2
- - const: google,spherion-rev1
- - const: google,spherion-rev0
- - const: google,spherion
- - const: mediatek,mt8192
- - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
- items:
- - enum:
- - google,tomato-rev2
- - google,tomato-rev1
- - const: google,tomato
- - const: mediatek,mt8195
- - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
- items:
- - const: google,tomato-rev4
- - const: google,tomato-rev3
- - const: google,tomato
- - const: mediatek,mt8195
- - items:
- - enum:
- - mediatek,mt8186-evb
- - const: mediatek,mt8186
- - items:
- - enum:
- - mediatek,mt8192-evb
- - const: mediatek,mt8192
- - items:
- - enum:
- - mediatek,mt8195-demo
- - mediatek,mt8195-evb
- - const: mediatek,mt8195
- description: Google Burnet (HP Chromebook x360 11MK G3 EE)
items:
- const: google,burnet
- const: mediatek,mt8183
- - description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
- items:
- - enum:
- - google,krane-sku0
- - google,krane-sku176
- - const: google,krane
- - const: mediatek,mt8183
- description: Google Cozmo (Acer Chromebook 314)
items:
- const: google,cozmo
@@ -222,6 +203,13 @@ properties:
items:
- const: google,kappa
- const: mediatek,mt8183
+ - description: Google Katsu (ASUS Chromebook Detachable CZ1)
+ items:
+ - enum:
+ - google,katsu-sku32
+ - google,katsu-sku38
+ - const: google,katsu
+ - const: mediatek,mt8183
- description: Google Kodama (Lenovo 10e Chromebook Tablet)
items:
- enum:
@@ -231,6 +219,27 @@ properties:
- google,kodama-sku32
- const: google,kodama
- const: mediatek,mt8183
+ - description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
+ items:
+ - enum:
+ - google,krane-sku0
+ - google,krane-sku176
+ - const: google,krane
+ - const: mediatek,mt8183
+ - description: Google Makomo (Lenovo 100e Chromebook 2nd Gen MTK 2)
+ items:
+ - enum:
+ - google,makomo-sku0
+ - google,makomo-sku1
+ - const: google,makomo
+ - const: mediatek,mt8183
+ - description: Google Pico (Acer Chromebook Spin 311)
+ items:
+ - enum:
+ - google,pico-sku1
+ - google,pico-sku2
+ - const: google,pico
+ - const: mediatek,mt8183
- description: Google Willow (Acer Chromebook 311 C722/C722T)
items:
- enum:
@@ -240,8 +249,213 @@ properties:
- const: mediatek,mt8183
- items:
- enum:
+ - mediatek,mt8183-evb
+ - const: mediatek,mt8183
+ - items:
+ - enum:
- mediatek,mt8183-pumpkin
- const: mediatek,mt8183
+ - description: Google Chinchou (Asus Chromebook CZ1104CM2A/CZ1204CM2A)
+ items:
+ - const: google,chinchou-sku0
+ - const: google,chinchou-sku2
+ - const: google,chinchou-sku4
+ - const: google,chinchou-sku5
+ - const: google,chinchou
+ - const: mediatek,mt8186
+ - description: Google Chinchou (Asus Chromebook CZ1104FM2A/CZ1204FM2A/CZ1104CM2A/CZ1204CM2A)
+ items:
+ - const: google,chinchou-sku1
+ - const: google,chinchou-sku3
+ - const: google,chinchou-sku6
+ - const: google,chinchou-sku7
+ - const: google,chinchou-sku17
+ - const: google,chinchou-sku20
+ - const: google,chinchou-sku22
+ - const: google,chinchou-sku23
+ - const: google,chinchou
+ - const: mediatek,mt8186
+ - description: Google Chinchou360 (Asus Chromebook CZ1104FM2A/CZ1204FM2A Flip)
+ items:
+ - const: google,chinchou-sku16
+ - const: google,chinchou-sku18
+ - const: google,chinchou-sku19
+ - const: google,chinchou-sku21
+ - const: google,chinchou
+ - const: mediatek,mt8186
+ - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+ items:
+ - const: google,steelix-sku393219
+ - const: google,steelix-sku393216
+ - const: google,steelix
+ - const: mediatek,mt8186
+ - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+ items:
+ - const: google,steelix-sku393220
+ - const: google,steelix-sku393217
+ - const: google,steelix
+ - const: mediatek,mt8186
+ - description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
+ items:
+ - const: google,steelix-sku393221
+ - const: google,steelix-sku393218
+ - const: google,steelix
+ - const: mediatek,mt8186
+ - description: Google Ponyta
+ items:
+ - enum:
+ - google,ponyta-sku0
+ - google,ponyta-sku1
+ - const: google,ponyta
+ - const: mediatek,mt8186
+ - description: Google Rusty (Lenovo 100e Chromebook Gen 4)
+ items:
+ - const: google,steelix-sku196609
+ - const: google,steelix-sku196608
+ - const: google,steelix
+ - const: mediatek,mt8186
+ - description: Google Squirtle (Acer Chromebook Spin 311 (R724T)
+ items:
+ - const: google,squirtle
+ - const: mediatek,mt8186
+ - description: Google Starmie (ASUS Chromebook Enterprise CM30 (CM3001))
+ items:
+ - const: google,starmie-sku0
+ - const: google,starmie-sku2
+ - const: google,starmie-sku3
+ - const: google,starmie
+ - const: mediatek,mt8186
+ - description: Google Starmie (ASUS Chromebook Enterprise CM30 (CM3001))
+ items:
+ - const: google,starmie-sku1
+ - const: google,starmie-sku4
+ - const: google,starmie
+ - const: mediatek,mt8186
+ - description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4)
+ items:
+ - enum:
+ - google,steelix-sku131072
+ - google,steelix-sku131073
+ - const: google,steelix
+ - const: mediatek,mt8186
+ - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
+ items:
+ - const: google,tentacruel-sku262147
+ - const: google,tentacruel-sku262146
+ - const: google,tentacruel-sku262145
+ - const: google,tentacruel-sku262144
+ - const: google,tentacruel
+ - const: mediatek,mt8186
+ - description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
+ items:
+ - const: google,tentacruel-sku262151
+ - const: google,tentacruel-sku262150
+ - const: google,tentacruel-sku262149
+ - const: google,tentacruel-sku262148
+ - const: google,tentacruel
+ - const: mediatek,mt8186
+ - description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
+ items:
+ - const: google,tentacruel-sku327681
+ - const: google,tentacruel
+ - const: mediatek,mt8186
+ - description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
+ items:
+ - const: google,tentacruel-sku327683
+ - const: google,tentacruel
+ - const: mediatek,mt8186
+ - description: Google Voltorb (Acer Chromebook 311 C723/C732T)
+ items:
+ - const: google,voltorb
+ - const: mediatek,mt8186
+ - items:
+ - enum:
+ - mediatek,mt8186-evb
+ - const: mediatek,mt8186
+ - description: Google Ciri (Lenovo Chromebook Duet (11", 9))
+ items:
+ - enum:
+ - google,ciri-sku0
+ - google,ciri-sku1
+ - google,ciri-sku2
+ - google,ciri-sku3
+ - google,ciri-sku4
+ - google,ciri-sku5
+ - google,ciri-sku6
+ - google,ciri-sku7
+ - const: google,ciri
+ - const: mediatek,mt8188
+ - items:
+ - enum:
+ - mediatek,mt8188-evb
+ - const: mediatek,mt8188
+ - description: Google Hayato
+ items:
+ - const: google,hayato-rev1
+ - const: google,hayato
+ - const: mediatek,mt8192
+ - description: Google Spherion (Acer Chromebook 514)
+ items:
+ - const: google,spherion-rev3
+ - const: google,spherion-rev2
+ - const: google,spherion-rev1
+ - const: google,spherion-rev0
+ - const: google,spherion
+ - const: mediatek,mt8192
+ - items:
+ - enum:
+ - mediatek,mt8192-evb
+ - const: mediatek,mt8192
+ - description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
+ items:
+ - enum:
+ - google,tomato-rev2
+ - google,tomato-rev1
+ - const: google,tomato
+ - const: mediatek,mt8195
+ - description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
+ items:
+ - const: google,tomato-rev4
+ - const: google,tomato-rev3
+ - const: google,tomato
+ - const: mediatek,mt8195
+ - description: HP Dojo sku1, 3, 5, 7 (HP Chromebook x360 13b-ca0002sa)
+ items:
+ - const: google,dojo-sku7
+ - const: google,dojo-sku5
+ - const: google,dojo-sku3
+ - const: google,dojo-sku1
+ - const: google,dojo
+ - const: mediatek,mt8195
+ - items:
+ - enum:
+ - mediatek,mt8195-demo
+ - mediatek,mt8195-evb
+ - const: mediatek,mt8195
+ - items:
+ - enum:
+ - mediatek,mt8365-evk
+ - const: mediatek,mt8365
+ - items:
+ - enum:
+ - grinn,genio-510-sbc
+ - mediatek,mt8370-evk
+ - const: mediatek,mt8370
+ - const: mediatek,mt8188
+ - items:
+ - enum:
+ - grinn,genio-700-sbc
+ - mediatek,mt8390-evk
+ - const: mediatek,mt8390
+ - const: mediatek,mt8188
+ - items:
+ - enum:
+ - kontron,3-5-sbc-i1200
+ - mediatek,mt8395-evk
+ - mediatek,mt8395-evk-ufs
+ - radxa,nio-12l
+ - const: mediatek,mt8395
+ - const: mediatek,mt8195
- items:
- enum:
- mediatek,mt8516-pumpkin
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
deleted file mode 100644
index 699776be1dd3..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-MediaTek AUDSYS controller
-============================
-
-The MediaTek AUDSYS controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2701-audsys", "syscon"
- - "mediatek,mt6765-audsys", "syscon"
- - "mediatek,mt6779-audio", "syscon"
- - "mediatek,mt7622-audsys", "syscon"
- - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
- - "mediatek,mt8167-audiosys", "syscon"
- - "mediatek,mt8183-audiosys", "syscon"
- - "mediatek,mt8192-audsys", "syscon"
- - "mediatek,mt8516-audsys", "syscon"
-- #clock-cells: Must be 1
-
-The AUDSYS controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Required sub-nodes:
--------
-For common binding part and usage, refer to
-../sonud/mt2701-afe-pcm.txt.
-
-Example:
-
- audsys: clock-controller@11220000 {
- compatible = "mediatek,mt7622-audsys", "syscon";
- reg = <0 0x11220000 0 0x2000>;
- #clock-cells = <1>;
-
- afe: audio-controller {
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml
new file mode 100644
index 000000000000..f3a761cbd0fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,audsys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AUDSYS controller
+
+maintainers:
+ - Eugen Hristev <eugen.hristev@collabora.com>
+
+description:
+ The MediaTek AUDSYS controller provides various clocks to the system.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt2701-audsys
+ - mediatek,mt6765-audsys
+ - mediatek,mt6779-audsys
+ - mediatek,mt7622-audsys
+ - mediatek,mt8167-audsys
+ - mediatek,mt8173-audsys
+ - mediatek,mt8183-audiosys
+ - mediatek,mt8183-audsys
+ - mediatek,mt8186-audsys
+ - mediatek,mt8192-audsys
+ - mediatek,mt8516-audsys
+ - const: syscon
+ - items:
+ # Special case for mt7623 for backward compatibility
+ - const: mediatek,mt7623-audsys
+ - const: mediatek,mt2701-audsys
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ audio-controller:
+ type: object
+
+required:
+ - compatible
+ - '#clock-cells'
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8183-audiosys
+then:
+ properties:
+ audio-controller:
+ $ref: /schemas/sound/mediatek,mt8183-audio.yaml#
+else:
+ properties:
+ audio-controller:
+ $ref: /schemas/sound/mediatek,mt2701-audio.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/mt2701-power.h>
+ #include <dt-bindings/clock/mt2701-clk.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ audsys: clock-controller@11220000 {
+ compatible = "mediatek,mt7622-audsys", "syscon";
+ reg = <0 0x11220000 0 0x2000>;
+ #clock-cells = <1>;
+
+ afe: audio-controller {
+ compatible = "mediatek,mt2701-audio";
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "afe", "asys";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+
+ clocks = <&infracfg CLK_INFRA_AUDIO>,
+ <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+ <&topckgen CLK_TOP_AUD_48K_TIMING>,
+ <&topckgen CLK_TOP_AUD_44K_TIMING>,
+ <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
+ <&audsys CLK_AUD_I2SO1>,
+ <&audsys CLK_AUD_I2SO2>,
+ <&audsys CLK_AUD_I2SO3>,
+ <&audsys CLK_AUD_I2SO4>,
+ <&audsys CLK_AUD_I2SIN1>,
+ <&audsys CLK_AUD_I2SIN2>,
+ <&audsys CLK_AUD_I2SIN3>,
+ <&audsys CLK_AUD_I2SIN4>,
+ <&audsys CLK_AUD_ASRCO1>,
+ <&audsys CLK_AUD_ASRCO2>,
+ <&audsys CLK_AUD_ASRCO3>,
+ <&audsys CLK_AUD_ASRCO4>,
+ <&audsys CLK_AUD_AFE>,
+ <&audsys CLK_AUD_AFE_CONN>,
+ <&audsys CLK_AUD_A1SYS>,
+ <&audsys CLK_AUD_A2SYS>,
+ <&audsys CLK_AUD_AFE_MRGIF>;
+
+ clock-names = "infra_sys_audio_clk",
+ "top_audio_mux1_sel",
+ "top_audio_mux2_sel",
+ "top_audio_a1sys_hp",
+ "top_audio_a2sys_hp",
+ "i2s0_src_sel",
+ "i2s1_src_sel",
+ "i2s2_src_sel",
+ "i2s3_src_sel",
+ "i2s0_src_div",
+ "i2s1_src_div",
+ "i2s2_src_div",
+ "i2s3_src_div",
+ "i2s0_mclk_en",
+ "i2s1_mclk_en",
+ "i2s2_mclk_en",
+ "i2s3_mclk_en",
+ "i2so0_hop_ck",
+ "i2so1_hop_ck",
+ "i2so2_hop_ck",
+ "i2so3_hop_ck",
+ "i2si0_hop_ck",
+ "i2si1_hop_ck",
+ "i2si2_hop_ck",
+ "i2si3_hop_ck",
+ "asrc0_out_ck",
+ "asrc1_out_ck",
+ "asrc2_out_ck",
+ "asrc3_out_ck",
+ "audio_afe_pd",
+ "audio_afe_conn_pd",
+ "audio_a1sys_pd",
+ "audio_a2sys_pd",
+ "audio_mrgif_pd";
+
+ assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX1_DIV>,
+ <&topckgen CLK_TOP_AUD_MUX2_DIV>;
+ assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
+ <&topckgen CLK_TOP_AUD2PLL_90M>;
+ assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
deleted file mode 100644
index 149567a38215..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Mediatek bdpsys controller
-============================
-
-The Mediatek bdpsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt2701-bdpsys", "syscon"
- - "mediatek,mt2712-bdpsys", "syscon"
- - "mediatek,mt7623-bdpsys", "mediatek,mt2701-bdpsys", "syscon"
-- #clock-cells: Must be 1
-
-The bdpsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-bdpsys: clock-controller@1c000000 {
- compatible = "mediatek,mt2701-bdpsys", "syscon";
- reg = <0 0x1c000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
deleted file mode 100644
index a0ce82085ad0..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-MediaTek CAMSYS controller
-============================
-
-The MediaTek camsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt6765-camsys", "syscon"
- - "mediatek,mt6779-camsys", "syscon"
- - "mediatek,mt8183-camsys", "syscon"
-- #clock-cells: Must be 1
-
-The camsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-camsys: camsys@1a000000 {
- compatible = "mediatek,mt8183-camsys", "syscon";
- reg = <0 0x1a000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
deleted file mode 100644
index 0502db73686b..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Mediatek ethsys controller
-============================
-
-The Mediatek ethsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt2701-ethsys", "syscon"
- - "mediatek,mt7622-ethsys", "syscon"
- - "mediatek,mt7623-ethsys", "mediatek,mt2701-ethsys", "syscon"
- - "mediatek,mt7629-ethsys", "syscon"
- - "mediatek,mt7986-ethsys", "syscon"
-- #clock-cells: Must be 1
-- #reset-cells: Must be 1
-
-The ethsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-ethsys: clock-controller@1b000000 {
- compatible = "mediatek,mt2701-ethsys", "syscon";
- reg = <0 0x1b000000 0 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
deleted file mode 100644
index 323905af82c3..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Mediatek hifsys controller
-============================
-
-The Mediatek hifsys controller provides various clocks and reset
-outputs to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt2701-hifsys", "syscon"
- - "mediatek,mt7622-hifsys", "syscon"
- - "mediatek,mt7623-hifsys", "mediatek,mt2701-hifsys", "syscon"
-- #clock-cells: Must be 1
-
-The hifsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-hifsys: clock-controller@1a000000 {
- compatible = "mediatek,mt2701-hifsys", "syscon";
- reg = <0 0x1a000000 0 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
deleted file mode 100644
index dce4c9241932..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Mediatek imgsys controller
-============================
-
-The Mediatek imgsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2701-imgsys", "syscon"
- - "mediatek,mt2712-imgsys", "syscon"
- - "mediatek,mt6765-imgsys", "syscon"
- - "mediatek,mt6779-imgsys", "syscon"
- - "mediatek,mt6797-imgsys", "syscon"
- - "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
- - "mediatek,mt8167-imgsys", "syscon"
- - "mediatek,mt8173-imgsys", "syscon"
- - "mediatek,mt8183-imgsys", "syscon"
-- #clock-cells: Must be 1
-
-The imgsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-imgsys: clock-controller@15000000 {
- compatible = "mediatek,mt8173-imgsys", "syscon";
- reg = <0 0x15000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt
deleted file mode 100644
index 2ce889b023d9..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipesys.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Mediatek ipesys controller
-============================
-
-The Mediatek ipesys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt6779-ipesys", "syscon"
-- #clock-cells: Must be 1
-
-The ipesys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-ipesys: clock-controller@1b000000 {
- compatible = "mediatek,mt6779-ipesys", "syscon";
- reg = <0 0x1b000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
deleted file mode 100644
index aabc8c5c8ed2..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Mediatek IPU controller
-============================
-
-The Mediatek ipu controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt8183-ipu_conn", "syscon"
- - "mediatek,mt8183-ipu_adl", "syscon"
- - "mediatek,mt8183-ipu_core0", "syscon"
- - "mediatek,mt8183-ipu_core1", "syscon"
-- #clock-cells: Must be 1
-
-The ipu controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-ipu_conn: syscon@19000000 {
- compatible = "mediatek,mt8183-ipu_conn", "syscon";
- reg = <0 0x19000000 0 0x1000>;
- #clock-cells = <1>;
-};
-
-ipu_adl: syscon@19010000 {
- compatible = "mediatek,mt8183-ipu_adl", "syscon";
- reg = <0 0x19010000 0 0x1000>;
- #clock-cells = <1>;
-};
-
-ipu_core0: syscon@19180000 {
- compatible = "mediatek,mt8183-ipu_core0", "syscon";
- reg = <0 0x19180000 0 0x1000>;
- #clock-cells = <1>;
-};
-
-ipu_core1: syscon@19280000 {
- compatible = "mediatek,mt8183-ipu_core1", "syscon";
- reg = <0 0x19280000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
deleted file mode 100644
index 2df799cd06a7..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,jpgdecsys.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Mediatek jpgdecsys controller
-============================
-
-The Mediatek jpgdecsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt2712-jpgdecsys", "syscon"
-- #clock-cells: Must be 1
-
-The jpgdecsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-jpgdecsys: syscon@19000000 {
- compatible = "mediatek,mt2712-jpgdecsys", "syscon";
- reg = <0 0x19000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
deleted file mode 100644
index 2b882b7ca72e..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mcucfg.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Mediatek mcucfg controller
-============================
-
-The Mediatek mcucfg controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2712-mcucfg", "syscon"
- - "mediatek,mt8183-mcucfg", "syscon"
-- #clock-cells: Must be 1
-
-The mcucfg controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-mcucfg: syscon@10220000 {
- compatible = "mediatek,mt2712-mcucfg", "syscon";
- reg = <0 0x10220000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt
deleted file mode 100644
index 054424fb64b4..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mfgcfg.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Mediatek mfgcfg controller
-============================
-
-The Mediatek mfgcfg controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2712-mfgcfg", "syscon"
- - "mediatek,mt6779-mfgcfg", "syscon"
- - "mediatek,mt8167-mfgcfg", "syscon"
- - "mediatek,mt8183-mfgcfg", "syscon"
-- #clock-cells: Must be 1
-
-The mfgcfg controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-mfgcfg: syscon@13000000 {
- compatible = "mediatek,mt2712-mfgcfg", "syscon";
- reg = <0 0x13000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
deleted file mode 100644
index 8be5978f388d..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Mediatek mipi0a (mipi_rx_ana_csi0a) controller
-============================
-
-The Mediatek mipi0a controller provides various clocks
-to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt6765-mipi0a", "syscon"
-- #clock-cells: Must be 1
-
-The mipi0a controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-The mipi0a controller also uses the common power domain from
-Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
-The available power doamins are defined in dt-bindings/power/mt*-power.h.
-
-Example:
-
-mipi0a: clock-controller@11c10000 {
- compatible = "mediatek,mt6765-mipi0a", "syscon";
- reg = <0 0x11c10000 0 0x1000>;
- power-domains = <&scpsys MT6765_POWER_DOMAIN_CAM>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index 6ad023eec193..3f4262e93c78 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek mmsys controller
@@ -25,20 +25,40 @@ properties:
- mediatek,mt2712-mmsys
- mediatek,mt6765-mmsys
- mediatek,mt6779-mmsys
+ - mediatek,mt6795-mmsys
- mediatek,mt6797-mmsys
- mediatek,mt8167-mmsys
- mediatek,mt8173-mmsys
- mediatek,mt8183-mmsys
- mediatek,mt8186-mmsys
+ - mediatek,mt8188-vdosys0
+ - mediatek,mt8188-vdosys1
+ - mediatek,mt8188-vppsys0
+ - mediatek,mt8188-vppsys1
- mediatek,mt8192-mmsys
- - mediatek,mt8195-mmsys
+ - mediatek,mt8195-vdosys1
+ - mediatek,mt8195-vppsys0
+ - mediatek,mt8195-vppsys1
- mediatek,mt8365-mmsys
- const: syscon
+
+ - description: vdosys0 and vdosys1 are 2 display HW pipelines,
+ so mt8195 binding should be deprecated.
+ deprecated: true
+ items:
+ - const: mediatek,mt8195-mmsys
+ - const: syscon
+
- items:
- const: mediatek,mt7623-mmsys
- const: mediatek,mt2701-mmsys
- const: syscon
+ - items:
+ - const: mediatek,mt8195-vdosys0
+ - const: mediatek,mt8195-mmsys
+ - const: syscon
+
reg:
maxItems: 1
@@ -52,7 +72,8 @@ properties:
description:
Using mailbox to communicate with GCE, it should have this
property and list of phandle, mailbox specifiers. See
- Documentation/devicetree/bindings/mailbox/mtk-gce.txt for details.
+ Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
+ for details.
$ref: /schemas/types.yaml#/definitions/phandle-array
mediatek,gce-client-reg:
@@ -72,6 +93,34 @@ properties:
'#reset-cells':
const: 1
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port node. This port connects the MMSYS/VDOSYS output to
+ the first component of one display pipeline, for example one of
+ the available OVL or RDMA blocks.
+ Some MediaTek SoCs support multiple display outputs per MMSYS.
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the primary display pipeline
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the secondary display pipeline
+
+ endpoint@2:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the tertiary display pipeline
+
+ anyOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+ - required:
+ - endpoint@2
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml
index 9fbeb626ab23..d89848a8f478 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek PCIE Mirror Controller for MT7622
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
index 84fb0a146b6e..e7720caf31b3 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Wireless Ethernet Dispatch Controller for MT7622
@@ -20,7 +20,9 @@ properties:
items:
- enum:
- mediatek,mt7622-wed
+ - mediatek,mt7981-wed
- mediatek,mt7986-wed
+ - mediatek,mt7988-wed
- const: syscon
reg:
@@ -29,6 +31,38 @@ properties:
interrupts:
maxItems: 1
+ memory-region:
+ items:
+ - description: firmware EMI region
+ - description: firmware ILM region
+ - description: firmware DLM region
+ - description: firmware CPU DATA region
+ - description: firmware BOOT region
+
+ memory-region-names:
+ items:
+ - const: wo-emi
+ - const: wo-ilm
+ - const: wo-dlm
+ - const: wo-data
+ - const: wo-boot
+
+ mediatek,wo-ccif:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: mediatek wed-wo controller interface.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7622-wed
+ then:
+ properties:
+ memory-region-names: false
+ memory-region: false
+ mediatek,wo-ccif: false
+
required:
- compatible
- reg
@@ -49,3 +83,23 @@ examples:
interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_LOW>;
};
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ wed@15010000 {
+ compatible = "mediatek,mt7986-wed", "syscon";
+ reg = <0 0x15010000 0 0x1000>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
+
+ memory-region = <&wo_emi>, <&wo_ilm>, <&wo_dlm>,
+ <&wo_data>, <&wo_boot>;
+ memory-region-names = "wo-emi", "wo-ilm", "wo-dlm",
+ "wo-data", "wo-boot";
+ mediatek,wo-ccif = <&wo_ccif0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml
index 96221f51c1c3..82f64469a601 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7986-wed-pcie.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7986-wed-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek PCIE WED Controller for MT7986
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
deleted file mode 100644
index d179a61536f4..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-MediaTek PCIESYS controller
-============================
-
-The MediaTek PCIESYS controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt7622-pciesys", "syscon"
- - "mediatek,mt7629-pciesys", "syscon"
-- #clock-cells: Must be 1
-- #reset-cells: Must be 1
-
-The PCIESYS controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-pciesys: pciesys@1a100800 {
- compatible = "mediatek,mt7622-pciesys", "syscon";
- reg = <0 0x1a100800 0 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
deleted file mode 100644
index 29ca7a10b315..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-MediaTek SGMIISYS controller
-============================
-
-The MediaTek SGMIISYS controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt7622-sgmiisys", "syscon"
- - "mediatek,mt7629-sgmiisys", "syscon"
- - "mediatek,mt7986-sgmiisys_0", "syscon"
- - "mediatek,mt7986-sgmiisys_1", "syscon"
-- #clock-cells: Must be 1
-
-The SGMIISYS controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-sgmiisys: sgmiisys@1b128000 {
- compatible = "mediatek,mt7622-sgmiisys", "syscon";
- reg = <0 0x1b128000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
deleted file mode 100644
index 7cb02c930613..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-MediaTek SSUSBSYS controller
-============================
-
-The MediaTek SSUSBSYS controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt7622-ssusbsys", "syscon"
- - "mediatek,mt7629-ssusbsys", "syscon"
-- #clock-cells: Must be 1
-- #reset-cells: Must be 1
-
-The SSUSBSYS controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-ssusbsys: ssusbsys@1a000000 {
- compatible = "mediatek,mt7622-ssusbsys", "syscon";
- reg = <0 0x1a000000 0 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
deleted file mode 100644
index c877bcc1a5c5..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Mediatek vcodecsys controller
-============================
-
-The Mediatek vcodecsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt6765-vcodecsys", "syscon"
-- #clock-cells: Must be 1
-
-The vcodecsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-The vcodecsys controller also uses the common power domain from
-Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
-The available power doamins are defined in dt-bindings/power/mt*-power.h.
-
-Example:
-
-venc_gcon: clock-controller@17000000 {
- compatible = "mediatek,mt6765-vcodecsys", "syscon";
- reg = <0 0x17000000 0 0x10000>;
- power-domains = <&scpsys MT6765_POWER_DOMAIN_VCODEC>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
deleted file mode 100644
index 98195169176a..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Mediatek vdecsys controller
-============================
-
-The Mediatek vdecsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2701-vdecsys", "syscon"
- - "mediatek,mt2712-vdecsys", "syscon"
- - "mediatek,mt6779-vdecsys", "syscon"
- - "mediatek,mt6797-vdecsys", "syscon"
- - "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", "syscon"
- - "mediatek,mt8167-vdecsys", "syscon"
- - "mediatek,mt8173-vdecsys", "syscon"
- - "mediatek,mt8183-vdecsys", "syscon"
-- #clock-cells: Must be 1
-
-The vdecsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-vdecsys: clock-controller@16000000 {
- compatible = "mediatek,mt8173-vdecsys", "syscon";
- reg = <0 0x16000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
deleted file mode 100644
index 3cc299fd7857..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Mediatek vencltsys controller
-============================
-
-The Mediatek vencltsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be:
- - "mediatek,mt8173-vencltsys", "syscon"
-- #clock-cells: Must be 1
-
-The vencltsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-vencltsys: clock-controller@19000000 {
- compatible = "mediatek,mt8173-vencltsys", "syscon";
- reg = <0 0x19000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
deleted file mode 100644
index 6a6a14e15cd7..000000000000
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Mediatek vencsys controller
-============================
-
-The Mediatek vencsys controller provides various clocks to the system.
-
-Required Properties:
-
-- compatible: Should be one of:
- - "mediatek,mt2712-vencsys", "syscon"
- - "mediatek,mt6779-vencsys", "syscon"
- - "mediatek,mt6797-vencsys", "syscon"
- - "mediatek,mt8173-vencsys", "syscon"
- - "mediatek,mt8183-vencsys", "syscon"
-- #clock-cells: Must be 1
-
-The vencsys controller uses the common clk binding from
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-The available clocks are defined in dt-bindings/clock/mt*-clk.h.
-
-Example:
-
-vencsys: clock-controller@18000000 {
- compatible = "mediatek,mt8173-vencsys", "syscon";
- reg = <0 0x18000000 0 0x1000>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
index 6193388c6318..9a0d54e9799c 100644
--- a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
+++ b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip Sparx5 Boards Device Tree Bindings
+title: Microchip Sparx5 Boards
maintainers:
- Lars Povlsen <lars.povlsen@microchip.com>
diff --git a/Documentation/devicetree/bindings/arm/moxart.yaml b/Documentation/devicetree/bindings/arm/moxart.yaml
index 670d24ce8ec5..42565280914c 100644
--- a/Documentation/devicetree/bindings/arm/moxart.yaml
+++ b/Documentation/devicetree/bindings/arm/moxart.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/moxart.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MOXA ART device tree bindings
+title: MOXA ART
maintainers:
- Jonas Jensen <jonas.jensen@gmail.com>
diff --git a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt
deleted file mode 100644
index 0d244b999d10..000000000000
--- a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* Marvell Feroceon Cache
-
-Required properties:
-- compatible : Should be either "marvell,feroceon-cache" or
- "marvell,kirkwood-cache".
-
-Optional properties:
-- reg : Address of the L2 cache control register. Mandatory for
- "marvell,kirkwood-cache", not used by "marvell,feroceon-cache"
-
-
-Example:
- l2: l2-cache@20128 {
- compatible = "marvell,kirkwood-cache";
- reg = <0x20128 0x4>;
- };
diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
index d58116136154..f73bb8ec3a1a 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/mrvl/mrvl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell Platforms Device Tree Bindings
+title: Marvell Platforms
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
@@ -35,6 +35,11 @@ properties:
- enum:
- dell,wyse-ariel
- const: marvell,mmp3
+ - description: PXA1908 based boards
+ items:
+ - enum:
+ - samsung,coreprimevelte
+ - const: marvell,pxa1908
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/mrvl/tauros2.txt b/Documentation/devicetree/bindings/arm/mrvl/tauros2.txt
deleted file mode 100644
index 31af1cbb60bd..000000000000
--- a/Documentation/devicetree/bindings/arm/mrvl/tauros2.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Marvell Tauros2 Cache
-
-Required properties:
-- compatible : Should be "marvell,tauros2-cache".
-- marvell,tauros2-cache-features : Specify the features supported for the
- tauros2 cache.
- The features including
- CACHE_TAUROS2_PREFETCH_ON (1 << 0)
- CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1)
- The definition can be found at
- arch/arm/include/asm/hardware/cache-tauros2.h
-
-Example:
- L2: l2-cache {
- compatible = "marvell,tauros2-cache";
- marvell,tauros2-cache-features = <0x3>;
- };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
deleted file mode 100644
index 606b4b1b709d..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-QCOM Idle States for cpuidle driver
-
-ARM provides idle-state node to define the cpuidle states, as defined in [1].
-cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle
-states. Idle states have different enter/exit latency and residency values.
-The idle states supported by the QCOM SoC are defined as -
-
- * Standby
- * Retention
- * Standalone Power Collapse (Standalone PC or SPC)
- * Power Collapse (PC)
-
-Standby: Standby does a little more in addition to architectural clock gating.
-When the WFI instruction is executed the ARM core would gate its internal
-clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
-trigger to execute the SPM state machine. The SPM state machine waits for the
-interrupt to trigger the core back in to active. This triggers the cache
-hierarchy to enter standby states, when all cpus are idle. An interrupt brings
-the SPM state machine out of its wait, the next step is to ensure that the
-cache hierarchy is also out of standby, and then the cpu is allowed to resume
-execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
-driver and is not defined in the DT. The SPM state machine should be
-configured to execute this state by default and after executing every other
-state below.
-
-Retention: Retention is a low power state where the core is clock gated and
-the memory and the registers associated with the core are retained. The
-voltage may be reduced to the minimum value needed to keep the processor
-registers active. The SPM should be configured to execute the retention
-sequence and would wait for interrupt, before restoring the cpu to execution
-state. Retention may have a slightly higher latency than Standby.
-
-Standalone PC: A cpu can power down and warmboot if there is a sufficient time
-between the time it enters idle and the next known wake up. SPC mode is used
-to indicate a core entering a power down state without consulting any other
-cpu or the system resources. This helps save power only on that core. The SPM
-sequence for this idle state is programmed to power down the supply to the
-core, wait for the interrupt, restore power to the core, and ensure the
-system state including cache hierarchy is ready before allowing core to
-resume. Applying power and resetting the core causes the core to warmboot
-back into Elevation Level (EL) which trampolines the control back to the
-kernel. Entering a power down state for the cpu, needs to be done by trapping
-into a EL. Failing to do so, would result in a crash enforced by the warm boot
-code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
-be flushed in s/w, before powering down the core.
-
-Power Collapse: This state is similar to the SPC mode, but distinguishes
-itself in that the cpu acknowledges and permits the SoC to enter deeper sleep
-modes. In a hierarchical power domain SoC, this means L2 and other caches can
-be flushed, system bus, clocks - lowered, and SoC main XO clock gated and
-voltages reduced, provided all cpus enter this state. Since the span of low
-power modes possible at this state is vast, the exit latency and the residency
-of this low power mode would be considered high even though at a cpu level,
-this essentially is cpu power down. The SPM in this state also may handshake
-with the Resource power manager (RPM) processor in the SoC to indicate a
-complete application processor subsystem shut down.
-
-The idle-state for QCOM SoCs are distinguished by the compatible property of
-the idle-states device node.
-
-The devicetree representation of the idle state should be -
-
-Required properties:
-
-- compatible: Must be one of -
- "qcom,idle-state-ret",
- "qcom,idle-state-spc",
- "qcom,idle-state-pc",
- and "arm,idle-state".
-
-Other required and optional properties are specified in [1].
-
-Example:
-
- idle-states {
- CPU_SPC: spc {
- compatible = "qcom,idle-state-spc", "arm,idle-state";
- entry-latency-us = <150>;
- exit-latency-us = <200>;
- min-residency-us = <2000>;
- };
- };
-
-[1]. Documentation/devicetree/bindings/cpu/idle-states.yaml
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
deleted file mode 100644
index 7f696362a4a1..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
-
-The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
-There is one ACC register region per CPU within the KPSS remapped region as
-well as an alias register region that remaps accesses to the ACC associated
-with the CPU accessing the region.
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: should be one of:
- "qcom,kpss-acc-v1"
- "qcom,kpss-acc-v2"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the first element specifies the base address and size of
- the register region. An optional second element specifies
- the base address and size of the alias register region.
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the pll parents.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "pll8_vote", "pxo".
-
-- clock-output-names:
- Usage: optional
- Value type: <string>
- Definition: Name of the output clock. Typically acpuX_aux where X is a
- CPU number starting at 0.
-
-Example:
-
- clock-controller@2088000 {
- compatible = "qcom,kpss-acc-v2";
- reg = <0x02088000 0x1000>,
- <0x02008000 0x1000>;
- clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
- clock-names = "pll8_vote", "pxo";
- clock-output-names = "acpu0_aux";
- };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
deleted file mode 100644
index e628758950e1..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: should be one of the following. The generic compatible
- "qcom,kpss-gcc" should also be included.
- "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"
- "qcom,kpss-gcc-apq8064", "qcom,kpss-gcc"
- "qcom,kpss-gcc-msm8974", "qcom,kpss-gcc"
- "qcom,kpss-gcc-msm8960", "qcom,kpss-gcc"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: base address and size of the register region
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the pll parents.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "pll8_vote", "pxo".
-
-- clock-output-names:
- Usage: required
- Value type: <string>
- Definition: Name of the output clock. Typically acpu_l2_aux indicating
- an L2 cache auxiliary clock.
-
-Example:
-
- l2cc: clock-controller@2011000 {
- compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc";
- reg = <0x2011000 0x1000>;
- clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
- clock-names = "pll8_vote", "pxo";
- clock-output-names = "acpu_l2_aux";
- };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
deleted file mode 100644
index 5ea506412b4e..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
+++ /dev/null
@@ -1,64 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/msm/qcom,llcc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Last Level Cache Controller
-
-maintainers:
- - Rishabh Bhatnagar <rishabhb@codeaurora.org>
- - Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
-
-description: |
- LLCC (Last Level Cache Controller) provides last level of cache memory in SoC,
- that can be shared by multiple clients. Clients here are different cores in the
- SoC, the idea is to minimize the local caches at the clients and migrate to
- common pool of memory. Cache memory is divided into partitions called slices
- which are assigned to clients. Clients can query the slice details, activate
- and deactivate them.
-
-properties:
- compatible:
- enum:
- - qcom,sc7180-llcc
- - qcom,sc7280-llcc
- - qcom,sc8180x-llcc
- - qcom,sc8280xp-llcc
- - qcom,sdm845-llcc
- - qcom,sm6350-llcc
- - qcom,sm8150-llcc
- - qcom,sm8250-llcc
- - qcom,sm8350-llcc
- - qcom,sm8450-llcc
-
- reg:
- items:
- - description: LLCC base register region
- - description: LLCC broadcast base register region
-
- reg-names:
- items:
- - const: llcc_base
- - const: llcc_broadcast_base
-
- interrupts:
- maxItems: 1
-
-required:
- - compatible
- - reg
- - reg-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- system-cache-controller@1100000 {
- compatible = "qcom,sdm845-llcc";
- reg = <0x1100000 0x200000>, <0x1300000 0x50000> ;
- reg-names = "llcc_base", "llcc_broadcast_base";
- interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
deleted file mode 100644
index c0e3c3a42bea..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-SPM AVS Wrapper 2 (SAW2)
-
-The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
-Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
-power-controller that transitions a piece of hardware (like a processor or
-subsystem) into and out of low power modes via a direct connection to
-the PMIC. It can also be wired up to interact with other processors in the
-system, notifying them when a low power state is entered or exited.
-
-Multiple revisions of the SAW hardware are supported using these Device Nodes.
-SAW2 revisions differ in the register offset and configuration data. Also, the
-same revision of the SAW in different SoCs may have different configuration
-data due the differences in hardware capabilities. Hence the SoC name, the
-version of the SAW hardware in that SoC and the distinction between cpu (big
-or Little) or cache, may be needed to uniquely identify the SAW register
-configuration and initialization data. The compatible string is used to
-indicate this parameter.
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Must have
- "qcom,saw2"
- A more specific value could be one of:
- "qcom,apq8064-saw2-v1.1-cpu"
- "qcom,msm8226-saw2-v2.1-cpu"
- "qcom,msm8974-saw2-v2.1-cpu"
- "qcom,apq8084-saw2-v2.1-cpu"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the first element specifies the base address and size of
- the register region. An optional second element specifies
- the base address and size of the alias register region.
-
-- regulator:
- Usage: optional
- Value type: boolean
- Definition: Indicates that this SPM device acts as a regulator device
- device for the core (CPU or Cache) the SPM is attached
- to.
-
-Example 1:
-
- power-controller@2099000 {
- compatible = "qcom,saw2";
- reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
- regulator;
- };
-
-Example 2:
- saw0: power-controller@f9089000 {
- compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2";
- reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/msm/ssbi.txt b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
deleted file mode 100644
index 54fd5ced3401..000000000000
--- a/Documentation/devicetree/bindings/arm/msm/ssbi.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Qualcomm SSBI
-
-Some Qualcomm MSM devices contain a point-to-point serial bus used to
-communicate with a limited range of devices (mostly power management
-chips).
-
-These require the following properties:
-
-- compatible: "qcom,ssbi"
-
-- qcom,controller-type
- indicates the SSBI bus variant the controller should use to talk
- with the slave device. This should be one of "ssbi", "ssbi2", or
- "pmic-arbiter". The type chosen is determined by the attached
- slave.
-
-The slave device should be the single child node of the ssbi device
-with a compatible field.
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml
index 6816bd68f9cf..a8ac4a2d672d 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 thingy.jp.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MStar/SigmaStar Armv7 SoC l3bridge
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
index 599c65980f5d..5739848000b1 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar,smpctrl.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 thingy.jp.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/mstar/mstar,smpctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MStar/SigmaStar Armv7 SoC SMP control registers
diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
index 8892eb6bd3ef..937059fcc7b3 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/mstar/mstar.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MStar platforms device tree bindings
+title: MStar platforms
maintainers:
- Daniel Palmer <daniel@thingy.jp>
diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
deleted file mode 100644
index 43409e5721d5..000000000000
--- a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/npcm/npcm.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: NPCM Platforms Device Tree Bindings
-
-maintainers:
- - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
- - Tomer Maimon <tmaimon77@gmail.com>
-
-properties:
- $nodename:
- const: '/'
- compatible:
- oneOf:
- - description: WPCM450 based boards
- items:
- - enum:
- - supermicro,x9sci-ln4f-bmc # Supermicro X9SCI-LN4F server's BMC
- - const: nuvoton,wpcm450
-
- - description: NPCM750 based boards
- items:
- - enum:
- - nuvoton,npcm750-evb # NPCM750 evaluation board
- - const: nuvoton,npcm750
-
- - description: NPCM845 based boards
- items:
- - enum:
- - nuvoton,npcm845-evb # NPCM845 evaluation board
- - const: nuvoton,npcm845
-
-additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
deleted file mode 100644
index 94e72f25b331..000000000000
--- a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/npcm/nuvoton,gcr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Global Control Registers block in Nuvoton SoCs
-
-maintainers:
- - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
- - Tomer Maimon <tmaimon77@gmail.com>
-
-description:
- The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs
- that expose misc functionality such as chip model and version information or
- pinmux settings.
-
-properties:
- compatible:
- items:
- - enum:
- - nuvoton,wpcm450-gcr
- - nuvoton,npcm750-gcr
- - nuvoton,npcm845-gcr
- - const: syscon
- - const: simple-mfd
-
- reg:
- maxItems: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties:
- type: object
-
-examples:
- - |
- gcr: syscon@800000 {
- compatible = "nuvoton,npcm750-gcr", "syscon", "simple-mfd";
- reg = <0x800000 0x1000>;
-
- mux-controller {
- compatible = "mmio-mux";
- #mux-control-cells = <1>;
- mux-reg-masks = <0x38 0x07>;
- idle-states = <2>;
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml
new file mode 100644
index 000000000000..fb190db61525
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,ma35d1.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/nuvoton/nuvoton,ma35d1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35 series SoC based platforms
+
+maintainers:
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+description: |
+ Boards with an ARMv8 based Nuvoton MA35 series SoC shall have
+ the following properties.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: MA35D1 based boards
+ items:
+ - enum:
+ - nuvoton,ma35d1-iot
+ - nuvoton,ma35d1-som
+ - const: nuvoton,ma35d1
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml
new file mode 100644
index 000000000000..d386744c8815
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nuvoton/nuvoton,npcm.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/nuvoton/nuvoton,npcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NPCM Platforms
+
+maintainers:
+ - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: WPCM450 based boards
+ items:
+ - enum:
+ - supermicro,x9sci-ln4f-bmc # Supermicro X9SCI-LN4F server's BMC
+ - const: nuvoton,wpcm450
+
+ - description: NPCM750 based boards
+ items:
+ - enum:
+ - nuvoton,npcm750-evb # NPCM750 evaluation board
+ - const: nuvoton,npcm750
+
+ - description: NPCM845 based boards
+ items:
+ - enum:
+ - nuvoton,npcm845-evb # NPCM845 evaluation board
+ - const: nuvoton,npcm845
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
index c9675c4cdc1b..84dc6b7512af 100644
--- a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
+++ b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra194 CPU Complex device tree bindings
+title: NVIDIA Tegra194 CPU Complex
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
@@ -25,7 +25,7 @@ properties:
- nvidia,tegra194-ccplex
nvidia,bpmp:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Specifies the bpmp node that needs to be queried to get
operating point data for all CPUs.
diff --git a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml
index 214c97bc3063..6b7f5e6f99cf 100644
--- a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml
+++ b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/arm/nxp/lpc32xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP LPC32xx Platforms Device Tree Bindings
+title: NXP LPC32xx Platforms
maintainers:
- - Roland Stigge <stigge@antcom.de>
+ - Vladimir Zapolskiy <vz@mleia.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/arm/omap/ctrl.txt b/Documentation/devicetree/bindings/arm/omap/ctrl.txt
index f35b77920786..0ce6665df4a2 100644
--- a/Documentation/devicetree/bindings/arm/omap/ctrl.txt
+++ b/Documentation/devicetree/bindings/arm/omap/ctrl.txt
@@ -8,7 +8,7 @@ control module driver itself.
See [2] for documentation about clock/clockdomain nodes.
-[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
[2] Documentation/devicetree/bindings/clock/ti/*
Required properties:
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index fa8b31660cad..c863ec07cbbb 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -41,14 +41,6 @@ SoC Type (optional):
SoC Families:
-- OMAP2 generic - defaults to OMAP2420
- compatible = "ti,omap2"
-- OMAP3 generic
- compatible = "ti,omap3"
-- OMAP4 generic - defaults to OMAP4430
- compatible = "ti,omap4"
-- OMAP5 generic - defaults to OMAP5430
- compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
- AM33x generic
@@ -58,32 +50,6 @@ SoC Families:
SoCs:
-- OMAP2420
- compatible = "ti,omap2420", "ti,omap2"
-- OMAP2430
- compatible = "ti,omap2430", "ti,omap2"
-
-- OMAP3430
- compatible = "ti,omap3430", "ti,omap3"
- legacy: "ti,omap34xx" - please do not use any more
-- AM3517
- compatible = "ti,am3517", "ti,omap3"
-- OMAP3630
- compatible = "ti,omap3630", "ti,omap3"
- legacy: "ti,omap36xx" - please do not use any more
-- AM335x
- compatible = "ti,am33xx"
-
-- OMAP4430
- compatible = "ti,omap4430", "ti,omap4"
-- OMAP4460
- compatible = "ti,omap4460", "ti,omap4"
-
-- OMAP5430
- compatible = "ti,omap5430", "ti,omap5"
-- OMAP5432
- compatible = "ti,omap5432", "ti,omap5"
-
- DRA762
compatible = "ti,dra762", "ti,dra7"
@@ -116,65 +82,6 @@ SoCs:
Boards (incomplete list of examples):
-- OMAP3 BeagleBoard : Low cost community board
- compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
-
-- OMAP3 BeagleBoard A to B4 : Early BeagleBoard revisions A to B4 with a timer quirk
- compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
-
-- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
- compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
-
-- OMAP4 SDP : Software Development Board
- compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4"
-
-- OMAP4 PandaBoard : Low cost community board
- compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4"
-
-- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
- compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
-
-- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN
- compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
-
-- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard, VAR-SOM-OM44 w/WLAN and LCD touchscreen
- compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
-
-- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
- compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3"
-
-- AM335X EVM : Software Development Board for AM335x
- compatible = "ti,am335x-evm", "ti,am33xx"
-
-- AM335X Bone : Low cost community board
- compatible = "ti,am335x-bone", "ti,am33xx"
-
-- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM.
- compatible = "ti,am3359-icev2", "ti,am33xx"
-
-- AM335X OrionLXm : Substation Automation Platform
- compatible = "novatech,am335x-lxm", "ti,am33xx"
-
-- AM335X phyBOARD-WEGA: Single Board Computer dev kit
- compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
-
-- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
- compatible = "compulab,cm-t335", "ti,am33xx"
-
-- AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4
- compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx"
-
-- AM335X phyCORE-AM335x: Development kit
- compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx"
-
-- AM335x phyBOARD-REGOR: Single Board Computer
- compatible = "phytec,am335x-regor", "phytec,am335x-phycore-som", "ti,am33xx"
-
-- AM335X UC-8100-ME-T: Communication-centric industrial computing platform
- compatible = "moxa,uc-8100-me-t", "ti,am33xx";
-
-- OMAP5 EVM : Evaluation Module
- compatible = "ti,omap5-evm", "ti,omap5"
- AM437x CM-T43
compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
@@ -217,9 +124,3 @@ Boards (incomplete list of examples):
- DRA718 EVM: Software Development Board for DRA718
compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
-
-- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3"
-
-- DM3730 Logic PD SOM-LV: Commercial System on Module with WiFi and Bluetooth
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3"
diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt
deleted file mode 100644
index ac64e60f99f1..000000000000
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Oxford Semiconductor OXNAS SoCs Family device tree bindings
--------------------------------------------
-
-Boards with the OX810SE SoC shall have the following properties:
- Required root node property:
- compatible: "oxsemi,ox810se"
-
-Boards with the OX820 SoC shall have the following properties:
- Required root node property:
- compatible: "oxsemi,ox820"
-
-Board compatible values:
- - "wd,mbwe" (OX810SE)
- - "cloudengines,pogoplugv3" (OX820)
diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml
index dbb6f3dc5ae5..f47baaefcdac 100644
--- a/Documentation/devicetree/bindings/arm/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/pmu.yaml
@@ -20,12 +20,18 @@ properties:
items:
- enum:
- apm,potenza-pmu
+ - apple,avalanche-pmu
+ - apple,blizzard-pmu
- apple,firestorm-pmu
- apple,icestorm-pmu
- arm,armv8-pmuv3 # Only for s/w models
- arm,arm1136-pmu
- arm,arm1176-pmu
- arm,arm11mpcore-pmu
+ - arm,c1-nano-pmu
+ - arm,c1-premium-pmu
+ - arm,c1-pro-pmu
+ - arm,c1-ultra-pmu
- arm,cortex-a5-pmu
- arm,cortex-a7-pmu
- arm,cortex-a8-pmu
@@ -46,14 +52,29 @@ properties:
- arm,cortex-a76-pmu
- arm,cortex-a77-pmu
- arm,cortex-a78-pmu
+ - arm,cortex-a320-pmu
- arm,cortex-a510-pmu
+ - arm,cortex-a520-pmu
+ - arm,cortex-a520ae-pmu
- arm,cortex-a710-pmu
+ - arm,cortex-a715-pmu
+ - arm,cortex-a720-pmu
+ - arm,cortex-a720ae-pmu
+ - arm,cortex-a725-pmu
- arm,cortex-x1-pmu
- arm,cortex-x2-pmu
+ - arm,cortex-x3-pmu
+ - arm,cortex-x4-pmu
+ - arm,cortex-x925-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- arm,neoverse-n2-pmu
+ - arm,neoverse-n3-pmu
- arm,neoverse-v1-pmu
+ - arm,neoverse-v2-pmu
+ - arm,neoverse-v3-pmu
+ - arm,neoverse-v3ae-pmu
+ - arm,rainier-pmu
- brcm,vulcan-pmu
- cavium,thunder-pmu
- nvidia,denver-pmu
@@ -61,6 +82,7 @@ properties:
- qcom,krait-pmu
- qcom,scorpion-pmu
- qcom,scorpion-mp-pmu
+ - samsung,mongoose-pmu
interrupts:
# Don't know how many CPUs, so no constraints to specify
diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml
index dd83ef278af0..6e2e0c551841 100644
--- a/Documentation/devicetree/bindings/arm/psci.yaml
+++ b/Documentation/devicetree/bindings/arm/psci.yaml
@@ -43,29 +43,24 @@ properties:
- description:
For implementations complying to PSCI 0.2.
- const: arm,psci-0.2
-
- - description:
- For implementations complying to PSCI 0.2.
Function IDs are not required and should be ignored by an OS with
PSCI 0.2 support, but are permitted to be present for compatibility
with existing software when "arm,psci" is later in the compatible
list.
+ minItems: 1
items:
- const: arm,psci-0.2
- const: arm,psci
- description:
For implementations complying to PSCI 1.0.
- const: arm,psci-1.0
-
- - description:
- For implementations complying to PSCI 1.0.
PSCI 1.0 is backward compatible with PSCI 0.2 with minor
specification updates, as defined in the PSCI specification[2].
+ minItems: 1
items:
- const: arm,psci-1.0
- const: arm,psci-0.2
+ - const: arm,psci
method:
description: The method of calling the PSCI firmware.
@@ -105,7 +100,8 @@ properties:
patternProperties:
"^power-domain-":
- $ref: "../power/power-domain.yaml#"
+ $ref: /schemas/power/power-domain.yaml#
+ unevaluatedProperties: false
type: object
description: |
@@ -167,7 +163,6 @@ examples:
method = "smc";
};
-
- |+
// Case 3: PSCI v0.2 and PSCI v0.1.
@@ -195,27 +190,27 @@ examples:
#size-cells = <0>;
#address-cells = <1>;
- CPU0: cpu@0 {
+ cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x0>;
enable-method = "psci";
- power-domains = <&CPU_PD0>;
+ power-domains = <&cpu_pd0>;
power-domain-names = "psci";
};
- CPU1: cpu@1 {
+ cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x100>;
enable-method = "psci";
- power-domains = <&CPU_PD1>;
+ power-domains = <&cpu_pd1>;
power-domain-names = "psci";
};
idle-states {
- CPU_PWRDN: cpu-power-down {
+ cpu_pwrdn: cpu-power-down {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0000001>;
entry-latency-us = <10>;
@@ -226,7 +221,7 @@ examples:
domain-idle-states {
- CLUSTER_RET: cluster-retention {
+ cluster_ret: cluster-retention {
compatible = "domain-idle-state";
arm,psci-suspend-param = <0x1000011>;
entry-latency-us = <500>;
@@ -234,7 +229,7 @@ examples:
min-residency-us = <2000>;
};
- CLUSTER_PWRDN: cluster-power-down {
+ cluster_pwrdn: cluster-power-down {
compatible = "domain-idle-state";
arm,psci-suspend-param = <0x1000031>;
entry-latency-us = <2000>;
@@ -248,21 +243,21 @@ examples:
compatible = "arm,psci-1.0";
method = "smc";
- CPU_PD0: power-domain-cpu0 {
+ cpu_pd0: power-domain-cpu0 {
#power-domain-cells = <0>;
- domain-idle-states = <&CPU_PWRDN>;
- power-domains = <&CLUSTER_PD>;
+ domain-idle-states = <&cpu_pwrdn>;
+ power-domains = <&cluster_pd>;
};
- CPU_PD1: power-domain-cpu1 {
+ cpu_pd1: power-domain-cpu1 {
#power-domain-cells = <0>;
- domain-idle-states = <&CPU_PWRDN>;
- power-domains = <&CLUSTER_PD>;
+ domain-idle-states = <&cpu_pwrdn>;
+ power-domains = <&cluster_pd>;
};
- CLUSTER_PD: power-domain-cluster {
+ cluster_pd: power-domain-cluster {
#power-domain-cells = <0>;
- domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWRDN>;
+ domain-idle-states = <&cluster_ret>, <&cluster_pwrdn>;
};
};
...
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
new file mode 100644
index 000000000000..c969c16c21ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-ctcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CoreSight TMC Control Unit
+
+maintainers:
+ - Yuanfang Zhang <quic_yuanfang@quicinc.com>
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Jie Gan <quic_jiegan@quicinc.com>
+
+description: |
+ The Trace Memory Controller(TMC) is used for Embedded Trace Buffer(ETB),
+ Embedded Trace FIFO(ETF) and Embedded Trace Router(ETR) configurations.
+ The configuration mode (ETB, ETF, ETR) is discovered at boot time when
+ the device is probed.
+
+ The Coresight TMC Control unit controls various Coresight behaviors.
+ It works as a helper device when connected to TMC ETR device.
+ It is responsible for controlling the data filter function based on
+ the source device's Trace ID for TMC ETR device. The trace data with
+ that Trace id can get into ETR's buffer while other trace data gets
+ ignored.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sa8775p-ctcu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb
+
+ label:
+ description:
+ Description of a coresight device.
+
+ in-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ '^port(@[0-1])?$':
+ description: Input connections from CoreSight Trace bus
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - in-ports
+
+additionalProperties: false
+
+examples:
+ - |
+ ctcu@1001000 {
+ compatible = "qcom,sa8775p-ctcu";
+ reg = <0x1001000 0x1000>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb";
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ctcu_in_port0: endpoint {
+ remote-endpoint = <&etr0_out_port>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ctcu_in_port1: endpoint {
+ remote-endpoint = <&etr1_out_port>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
new file mode 100644
index 000000000000..ffe613efeabe
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-remote-etm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Coresight Remote ETM(Embedded Trace Macrocell)
+
+maintainers:
+ - Jinlong Mao <quic_jinlmao@quicinc.com>
+ - Tao Zhang <quic_taozha@quicinc.com>
+
+description:
+ Support for ETM trace collection on remote processor using coresight
+ framework. Enabling this will allow turning on ETM tracing on remote
+ processor like modem processor via sysfs and collecting the trace
+ via coresight TMC sinks.
+
+properties:
+ compatible:
+ const: qcom,coresight-remote-etm
+
+ label:
+ description:
+ Description of a coresight device.
+
+ out-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ additionalProperties: false
+
+ properties:
+ port:
+ description: Output connection to the CoreSight Trace bus.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - out-ports
+
+additionalProperties: false
+
+examples:
+ - |
+ etm {
+ compatible = "qcom,coresight-remote-etm";
+
+ out-ports {
+ port {
+ modem_etm0_out_funnel_modem: endpoint {
+ remote-endpoint = <&funnel_modem_in_modem_etm0>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
new file mode 100644
index 000000000000..9d1c93a9ade3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-tnoc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Trace Network On Chip - TNOC
+
+maintainers:
+ - Yuanfang Zhang <quic_yuanfang@quicinc.com>
+
+description: >
+ The Trace Network On Chip (TNOC) is an integration hierarchy hardware
+ component that integrates the functionalities of TPDA and funnels.
+
+ It sits in the different subsystem of SOC and aggregates the trace and
+ transports it to Aggregation TNOC or to coresight trace sink eventually.
+ TNOC embeds bridges for all the interfaces APB, ATB, TPDA and NTS (Narrow
+ Time Stamp).
+
+ TNOC can take inputs from different trace sources i.e. ATB, TPDM.
+
+ Note this binding is specifically intended for Aggregator TNOC instances.
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,coresight-tnoc
+ required:
+ - compatible
+
+properties:
+ $nodename:
+ pattern: "^tn(@[0-9a-f]+)$"
+
+ compatible:
+ items:
+ - const: qcom,coresight-tnoc
+ - const: arm,primecell
+
+ reg:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb_pclk
+
+ clocks:
+ items:
+ - description: APB register access clock
+
+ in-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ '^port(@[0-9a-f]{1,2})?$':
+ description: Input connections from CoreSight Trace Bus
+ $ref: /schemas/graph.yaml#/properties/port
+
+ out-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ additionalProperties: false
+
+ properties:
+ port:
+ description:
+ Output connection to CoreSight Trace Bus
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - in-ports
+ - out-ports
+
+additionalProperties: false
+
+examples:
+ - |
+ tn@109ab000 {
+ compatible = "qcom,coresight-tnoc", "arm,primecell";
+ reg = <0x109ab000 0x4200>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tn_ag_in_tpdm_gcc: endpoint {
+ remote-endpoint = <&tpdm_gcc_out_tn_ag>;
+ };
+ };
+ };
+
+ out-ports {
+ port {
+ tn_ag_out_funnel_in1: endpoint {
+ remote-endpoint = <&funnel_in1_in_tn_ag>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
new file mode 100644
index 000000000000..a48c9ac3eaa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-tpda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trace, Profiling and Diagnostics Aggregator - TPDA
+
+description: |
+ TPDAs are responsible for packetization and timestamping of data sets
+ utilizing the MIPI STPv2 packet protocol. Pulling data sets from one or
+ more attached TPDM and pushing the resultant (packetized) data out a
+ master ATB interface. Performing an arbitrated ATB interleaving (funneling)
+ task for free-flowing data from TPDM (i.e. CMB and DSB data set flows).
+
+ There is no strict binding between TPDM and TPDA. TPDA can have multiple
+ TPDMs connect to it. But There must be only one TPDA in the path from the
+ TPDM source to TMC sink. TPDM can directly connect to TPDA's inport or
+ connect to funnel which will connect to TPDA's inport.
+
+ We can use the commands are similar to the below to validate TPDMs.
+ Enable coresight sink first.
+
+ echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
+ echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
+ echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test
+ echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test
+
+ The test data will be collected in the coresight sink which is enabled.
+ If rwp register of the sink is keeping updating when do integration_test
+ (by cat tmc_etf0/mgmt/rwp), it means there is data generated from TPDM
+ to sink.
+
+maintainers:
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Tao Zhang <quic_taozha@quicinc.com>
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,coresight-tpda
+ required:
+ - compatible
+
+properties:
+ $nodename:
+ pattern: "^tpda(@[0-9a-f]+)$"
+ compatible:
+ items:
+ - const: qcom,coresight-tpda
+ - const: arm,primecell
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb_pclk
+
+ label:
+ description:
+ Description of a coresight device.
+
+ in-ports:
+ description: |
+ Input connections from TPDM to TPDA
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ out-ports:
+ description: |
+ Output connections from the TPDA to legacy CoreSight trace bus.
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description:
+ Output connection from the TPDA to legacy CoreSight Trace bus.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - in-ports
+ - out-ports
+
+additionalProperties: false
+
+examples:
+ # minimum tpda definition.
+ - |
+ tpda@6004000 {
+ compatible = "qcom,coresight-tpda", "arm,primecell";
+ reg = <0x6004000 0x1000>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tpda_qdss_0_in_tpdm_dcc: endpoint {
+ remote-endpoint = <&tpdm_dcc_out_tpda_qdss_0>;
+ };
+ };
+ };
+
+ out-ports {
+ port {
+ tpda_qdss_out_funnel_in0: endpoint {
+ remote-endpoint = <&funnel_in0_in_tpda_qdss>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
new file mode 100644
index 000000000000..c349306f0d52
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-tpdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trace, Profiling and Diagnostics Monitor - TPDM
+
+description: |
+ The TPDM or Monitor serves as data collection component for various dataset
+ types specified in the QPMDA spec. It covers Implementation defined ((ImplDef),
+ Basic Counts (BC), Tenure Counts (TC), Continuous Multi-Bit (CMB), and Discrete
+ Single Bit (DSB). It performs data collection in the data producing clock
+ domain and transfers it to the data collection time domain, generally ATB
+ clock domain.
+
+ The primary use case of the TPDM is to collect data from different data
+ sources and send it to a TPDA for packetization, timestamping, and funneling.
+
+maintainers:
+ - Mao Jinlong <quic_jinlmao@quicinc.com>
+ - Tao Zhang <quic_taozha@quicinc.com>
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,coresight-tpdm
+ required:
+ - compatible
+
+properties:
+ $nodename:
+ pattern: "^tpdm(@[0-9a-f]+)$"
+ compatible:
+ oneOf:
+ - items:
+ - const: qcom,coresight-static-tpdm
+ - items:
+ - const: qcom,coresight-tpdm
+ - const: arm,primecell
+
+ reg:
+ maxItems: 1
+
+ qcom,dsb-element-bits:
+ description:
+ Specifies the DSB(Discrete Single Bit) element size supported by
+ the monitor. The associated aggregator will read this size before it
+ is enabled. DSB element size currently only supports 32-bit and 64-bit.
+ enum: [32, 64]
+
+ qcom,cmb-element-bits:
+ description:
+ Specifies the CMB(Continuous Multi-Bit) element size supported by
+ the monitor. The associated aggregator will read this size before it
+ is enabled. CMB element size currently only supports 8-bit, 32-bit
+ and 64-bit.
+ enum: [8, 32, 64]
+
+ qcom,dsb-msrs-num:
+ description:
+ Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
+ registers supported by the monitor. If this property is not configured
+ or set to 0, it means this DSB TPDM doesn't support MSR.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 32
+
+ qcom,cmb-msrs-num:
+ description:
+ Specifies the number of CMB MSR(mux select register) registers supported
+ by the monitor. If this property is not configured or set to 0, it means
+ this TPDM doesn't support CMB MSR.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 32
+
+ label:
+ description:
+ Description of a coresight device.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb_pclk
+
+ out-ports:
+ description: |
+ Output connections from the TPDM to coresight funnel/TPDA.
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ description: Output connection from the TPDM to coresight
+ funnel/TPDA.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ # minimum TPDM definition. TPDM connect to coresight TPDA.
+ - |
+ tpdm@684c000 {
+ compatible = "qcom,coresight-tpdm", "arm,primecell";
+ reg = <0x0684c000 0x1000>;
+
+ qcom,dsb-element-bits = <32>;
+ qcom,dsb-msrs-num = <16>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ out-ports {
+ port {
+ tpdm_prng_out_tpda_qdss: endpoint {
+ remote-endpoint =
+ <&tpda_qdss_in_tpdm_prng>;
+ };
+ };
+ };
+ };
+
+ tpdm@6c29000 {
+ compatible = "qcom,coresight-tpdm", "arm,primecell";
+ reg = <0x06c29000 0x1000>;
+
+ qcom,cmb-element-bits = <64>;
+ qcom,cmb-msrs-num = <32>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ out-ports {
+ port {
+ tpdm_ipcc_out_funnel_center: endpoint {
+ remote-endpoint = <&funnel_center_in_tpdm_ipcc>;
+ };
+ };
+ };
+ };
+
+ turing-llm-tpdm {
+ compatible = "qcom,coresight-static-tpdm";
+
+ qcom,cmb-element-bits = <32>;
+
+ out-ports {
+ port {
+ turing_llm_tpdm_out: endpoint {
+ remote-endpoint = <&turing0_funnel_in1>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
new file mode 100644
index 000000000000..27261039d56f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom-soc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoC compatibles naming convention
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Guidelines for new compatibles for SoC blocks/components.
+ When adding new compatibles in new bindings, use the format::
+ qcom,SoC-IP
+
+ For example::
+ qcom,sdm845-llcc-bwmon
+
+ When adding new compatibles to existing bindings, use the format in the
+ existing binding, even if it contradicts the above.
+
+select:
+ properties:
+ compatible:
+ oneOf:
+ - pattern: "^qcom,.*(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sar|sc|sd[amx]|sm|x1[ep])[0-9]+.*$"
+ - pattern: "^qcom,.*(glymur|milos).*$"
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ # Preferred naming style for compatibles of SoC components:
+ - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+(pro)?-.*$"
+ - pattern: "^qcom,sar[0-9]+[a-z]?-.*$"
+ - pattern: "^qcom,(sa|sc)8[0-9]+[a-z][a-z]?-.*$"
+ - pattern: "^qcom,(glymur|milos)-.*$"
+
+ # Legacy namings - variations of existing patterns/compatibles are OK,
+ # but do not add completely new entries to these:
+ - pattern: "^qcom,[ak]pss-wdt-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$"
+ - pattern: "^qcom,gcc-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$"
+ - pattern: "^qcom,mmcc-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$"
+ - pattern: "^qcom,pcie-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+.*$"
+ - pattern: "^qcom,rpm-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm)[0-9]+.*$"
+ - pattern: "^qcom,scm-(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+.*$"
+ - enum:
+ - qcom,dsi-ctrl-6g-qcm2290
+ - qcom,gpucc-sdm630
+ - qcom,gpucc-sdm660
+ - qcom,lcc-apq8064
+ - qcom,lcc-ipq8064
+ - qcom,lcc-mdm9615
+ - qcom,lcc-msm8960
+ - qcom,lpass-cpu-apq8016
+ - qcom,usb-ss-ipq4019-phy
+ - qcom,usb-hs-ipq4019-phy
+ - qcom,vqmmc-ipq4019-regulator
+
+ # Legacy compatibles with wild-cards - list cannot grow with new bindings:
+ - enum:
+ - qcom,ipq806x-gmac
+ - qcom,ipq806x-nand
+ - qcom,ipq806x-sata-phy
+ - qcom,ipq806x-usb-phy-ss
+ - qcom,ipq806x-usb-phy-hs
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index b6257683a700..d84bd3bca201 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -4,102 +4,16 @@
$id: http://devicetree.org/schemas/arm/qcom.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: QCOM device tree bindings
+title: QCOM
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
- Some qcom based bootloaders identify the dtb blob based on a set of
- device properties like SoC and platform and revisions of those components.
- To support this scheme, we encode this information into the board compatible
- string.
-
- Each board must specify a top-level board compatible string with the following
- format:
-
- compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
-
- The 'SoC' and 'board' elements are required. All other elements are optional.
-
- The 'SoC' element must be one of the following strings:
-
- apq8016
- apq8026
- apq8074
- apq8084
- apq8096
- ipq6018
- ipq8074
- mdm9615
- msm8226
- msm8916
- msm8974
- msm8992
- msm8994
- msm8996
- msm8998
- qcs404
- sa8155p
- sa8540p
- sc7180
- sc7280
- sc8180x
- sc8280xp
- sda660
- sdm630
- sdm632
- sdm636
- sdm660
- sdm845
- sdx55
- sdx65
- sm6125
- sm6350
- sm7225
- sm8150
- sm8250
- sm8350
- sm8450
-
- The 'board' element must be one of the following strings:
-
- adp
- cdp
- cp01-c1
- dragonboard
- hk01
- hk10-c1
- hk10-c2
- idp
- liquid
- mtp
- qrd
- sbc
-
- The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
- where the minor number may be omitted when it's zero, i.e. v1.0 is the same
- as v1. If all versions of the 'board_version' elements match, then a
- wildcard '*' should be used, e.g. 'v*'.
-
- The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
-
- Examples:
-
- "qcom,msm8916-v1-cdp-pm8916-v2.1"
-
- A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
- 2.1.
-
- "qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
-
- A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
- foundry 2.
-
There are many devices in the list below that run the standard ChromeOS
bootloader setup and use the open source depthcharge bootloader to boot the
- OS. These devices do not use the scheme described above. For details, see:
- https://docs.kernel.org/arm/google/chromebook-boot-flow.html
+ OS. These devices use the bootflow explained at
+ https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
properties:
$nodename:
@@ -109,12 +23,16 @@ properties:
- items:
- enum:
- qcom,apq8016-sbc
+ - schneider,apq8016-hmibsc
- const: qcom,apq8016
- items:
- enum:
- asus,sparrow
+ - huawei,sturgeon
- lg,lenok
+ - samsung,matisse-wifi
+ - samsung,milletwifi
- const: qcom,apq8026
- items:
@@ -145,53 +63,154 @@ properties:
- items:
- enum:
+ - microsoft,dempsey
+ - microsoft,makepeace
+ - microsoft,moneypenny
+ - motorola,falcon
+ - samsung,ms013g
- samsung,s3ve3g
- const: qcom,msm8226
- items:
- enum:
+ - htc,memul
+ - microsoft,superman-lte
+ - microsoft,tesla
+ - motorola,peregrine
+ - samsung,matisselte
+ - const: qcom,msm8926
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - wingtech,wt82918hd
+ - const: qcom,msm8929
+
+ - items:
+ - enum:
+ - asus,z00t
+ - huawei,kiwi
+ - longcheer,l9100
+ - samsung,a7
+ - sony,kanuti-tulip
+ - square,apq8039-t2
+ - wingtech,wt82918
+ - wingtech,wt82918hdhw39
+ - const: qcom,msm8939
+
+ - items:
+ - enum:
+ - sony,kugo-row
+ - sony,suzu-row
+ - const: qcom,msm8956
+
+ - items:
+ - enum:
- qcom,msm8960-cdp
+ - samsung,expressatt
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - sony,huashan
+ - const: qcom,msm8960t
- const: qcom,msm8960
- items:
- enum:
- - fairphone,fp2
- lge,hammerhead
- - samsung,klte
+ - samsung,hlte
- sony,xperia-amami
- - sony,xperia-castor
- sony,xperia-honami
+ - sony,xperia-togari
- const: qcom,msm8974
- items:
- - const: qcom,msm8916-mtp
- - const: qcom,msm8916-mtp/1
- - const: qcom,msm8916
+ - enum:
+ - fairphone,fp2
+ - htc,m8
+ - oneplus,bacon
+ - samsung,klte
+ - sony,xperia-aries
+ - sony,xperia-castor
+ - sony,xperia-leo
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
- items:
- enum:
+ - samsung,kltechn
+ - const: samsung,klte
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - longcheer,l9360
+ - const: qcom,msm8976
+
+ - items:
+ - enum:
+ - acer,a1-724
- alcatel,idol347
- asus,z00l
+ - gplus,fl8005a
- huawei,g7
+ - lg,c50
+ - lg,m216
- longcheer,l8910
+ - longcheer,l8150
+ - motorola,harpia
+ - motorola,osprey
+ - motorola,surnia
+ - qcom,msm8916-mtp
- samsung,a3u-eur
- samsung,a5u-eur
- samsung,e5
- samsung,e7
+ - samsung,fortuna3g
+ - samsung,gprimeltecan
- samsung,grandmax
+ - samsung,grandprimelte
+ - samsung,gt510
+ - samsung,gt58
+ - samsung,j3ltetw
- samsung,j5
+ - samsung,j5x
+ - samsung,rossa
- samsung,serranove
+ - thwc,uf896
+ - thwc,ufi001c
+ - wingtech,wt86518
+ - wingtech,wt86528
- wingtech,wt88047
+ - yiming,uz801-v3
- const: qcom,msm8916
- items:
- - const: longcheer,l8150
- - const: qcom,msm8916-v1-qrd/9-v1
- - const: qcom,msm8916
+ - enum:
+ - xiaomi,riva
+ - const: qcom,msm8917
+
+ - items:
+ - enum:
+ - xiaomi,land
+ - const: qcom,msm8937
+
+ - items:
+ - enum:
+ - flipkart,rimob
+ - motorola,potter
+ - xiaomi,daisy
+ - xiaomi,mido
+ - xiaomi,tissot
+ - xiaomi,vince
+ - const: qcom,msm8953
- items:
- enum:
- lg,bullhead
+ - lg,h815
- microsoft,talkman
- xiaomi,libra
- const: qcom,msm8992
@@ -221,13 +240,20 @@ properties:
- items:
- enum:
+ - oneplus,oneplus3
+ - oneplus,oneplus3t
- qcom,msm8996-mtp
- sony,dora-row
- sony,kagura-row
- sony,keyaki-row
- xiaomi,gemini
+ - const: qcom,msm8996
+
+ - items:
+ - enum:
- xiaomi,natrium
- xiaomi,scorpio
+ - const: qcom,msm8996pro
- const: qcom,msm8996
- items:
@@ -242,10 +268,17 @@ properties:
- sony,xperia-lilac
- sony,xperia-maple
- sony,xperia-poplar
+ - xiaomi,sagit
- const: qcom,msm8998
- items:
- enum:
+ - 8dev,jalapeno
+ - alfa-network,ap120c-ac
+ - const: qcom,ipq4018
+
+ - items:
+ - enum:
- qcom,ipq4019-ap-dk01.1-c1
- qcom,ipq4019-ap-dk04.1-c3
- qcom,ipq4019-ap-dk07.1-c1
@@ -255,6 +288,26 @@ properties:
- items:
- enum:
+ - qcom,ipq5018-rdp432-c2
+ - tplink,archer-ax55-v1
+ - const: qcom,ipq5018
+
+ - items:
+ - enum:
+ - qcom,ipq5332-ap-mi01.2
+ - qcom,ipq5332-ap-mi01.3
+ - qcom,ipq5332-ap-mi01.6
+ - qcom,ipq5332-ap-mi01.9
+ - const: qcom,ipq5332
+
+ - items:
+ - enum:
+ - qcom,ipq5424-rdp466
+ - const: qcom,ipq5424
+
+ - items:
+ - enum:
+ - mikrotik,rb3011
- qcom,ipq8064-ap148
- const: qcom,ipq8064
@@ -265,9 +318,60 @@ properties:
- qcom,ipq8074-hk10-c2
- const: qcom,ipq8074
- - description: Qualcomm Technologies, Inc. SC7180 IDP
+ - items:
+ - enum:
+ - qcom,ipq9574-ap-al02-c2
+ - qcom,ipq9574-ap-al02-c6
+ - qcom,ipq9574-ap-al02-c7
+ - qcom,ipq9574-ap-al02-c8
+ - qcom,ipq9574-ap-al02-c9
+ - const: qcom,ipq9574
+
+ - description: Sierra Wireless MangOH Green with WP8548 Module
+ items:
+ - const: swir,mangoh-green-wp8548
+ - const: swir,wp8548
+ - const: qcom,mdm9615
+
+ - description: Qualcomm Technologies, Inc. Robotics RB1
items:
- enum:
+ - qcom,qrb2210-rb1
+ - const: qcom,qrb2210
+ - const: qcom,qcm2290
+
+ - items:
+ - enum:
+ - fairphone,fp5
+ - particle,tachyon
+ - qcom,qcm6490-idp
+ - qcom,qcs6490-rb3gen2
+ - radxa,dragon-q6a
+ - shift,otter
+ - const: qcom,qcm6490
+
+ - description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform
+ items:
+ - enum:
+ - qcom,qdu1000-idp
+ - qcom,qdu1000-x100
+ - const: qcom,qdu1000
+
+ - description: Qualcomm Technologies, Inc. Radio Unit 1000 platform
+ items:
+ - enum:
+ - qcom,qru1000-idp
+ - const: qcom,qru1000
+
+ - description: Qualcomm AR2 Gen1 platform
+ items:
+ - enum:
+ - qcom,qar2130p
+ - const: qcom,sar2130p
+
+ - items:
+ - enum:
+ - acer,aspire1
- qcom,sc7180-idp
- const: qcom,sc7180
@@ -340,6 +444,11 @@ properties:
- const: google,lazor-rev8
- const: qcom,sc7180
+ - description: Acer Chromebook Spin 513 (rev9)
+ items:
+ - const: google,lazor-rev9
+ - const: qcom,sc7180
+
- description: Acer Chromebook Spin 513 (newest rev)
items:
- const: google,lazor
@@ -361,6 +470,11 @@ properties:
- const: google,lazor-rev8-sku2
- const: qcom,sc7180
+ - description: Acer Chromebook Spin 513 with KB Backlight (rev9)
+ items:
+ - const: google,lazor-rev9-sku2
+ - const: qcom,sc7180
+
- description: Acer Chromebook Spin 513 with KB Backlight (newest rev)
items:
- const: google,lazor-sku2
@@ -382,9 +496,16 @@ properties:
- const: google,lazor-rev8-sku0
- const: qcom,sc7180
+ - description: Acer Chromebook Spin 513 with LTE (rev9)
+ items:
+ - const: google,lazor-rev9-sku0
+ - const: google,lazor-rev9-sku10
+ - const: qcom,sc7180
+
- description: Acer Chromebook Spin 513 with LTE (newest rev)
items:
- const: google,lazor-sku0
+ - const: google,lazor-sku10
- const: qcom,sc7180
- description: Acer Chromebook 511 (rev4 - rev8)
@@ -396,9 +517,16 @@ properties:
- const: google,lazor-rev8-sku4
- const: qcom,sc7180
+ - description: Acer Chromebook 511 (rev9)
+ items:
+ - const: google,lazor-rev9-sku4
+ - const: google,lazor-rev9-sku15
+ - const: qcom,sc7180
+
- description: Acer Chromebook 511 (newest rev)
items:
- const: google,lazor-sku4
+ - const: google,lazor-sku15
- const: qcom,sc7180
- description: Acer Chromebook 511 without Touchscreen (rev4)
@@ -415,9 +543,16 @@ properties:
- const: google,lazor-rev8-sku6
- const: qcom,sc7180
+ - description: Acer Chromebook 511 without Touchscreen (rev9)
+ items:
+ - const: google,lazor-rev9-sku6
+ - const: google,lazor-rev9-sku18
+ - const: qcom,sc7180
+
- description: Acer Chromebook 511 without Touchscreen (newest rev)
items:
- const: google,lazor-sku6
+ - const: google,lazor-sku18
- const: qcom,sc7180
- description: Google Mrbland with AUO panel (rev0)
@@ -463,6 +598,17 @@ properties:
- const: google,pazquel-sku2
- const: qcom,sc7180
+ - description: Google Pazquel360 with LTE (newest rev)
+ items:
+ - const: google,pazquel-sku22
+ - const: google,pazquel-sku20
+ - const: qcom,sc7180
+
+ - description: Google Pazquel360 with WiFi (newest rev)
+ items:
+ - const: google,pazquel-sku21
+ - const: qcom,sc7180
+
- description: Sharp Dynabook Chromebook C1 (rev1)
items:
- const: google,pompom-rev1
@@ -558,6 +704,12 @@ properties:
- const: google,hoglin
- const: qcom,sc7280
+ - description: Qualcomm Technologies, Inc. sc7280 CRD Pro platform (newest rev)
+ items:
+ - const: google,zoglin-sku1536
+ - const: google,hoglin-sku1536
+ - const: qcom,sc7280
+
- description: Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform
items:
- const: qcom,sc7280-idp
@@ -575,6 +727,11 @@ properties:
- const: google,evoker
- const: qcom,sc7280
+ - description: Google Evoker with LTE (newest rev)
+ items:
+ - const: google,evoker-sku512
+ - const: qcom,sc7280
+
- description: Google Herobrine (newest rev)
items:
- const: google,herobrine
@@ -595,6 +752,28 @@ properties:
- const: google,villager-sku512
- const: qcom,sc7280
+ - description: Google Zombie (newest rev)
+ items:
+ - const: google,zombie
+ - const: qcom,sc7280
+
+ - description: Google Zombie with LTE (newest rev)
+ items:
+ - const: google,zombie-sku512
+ - const: qcom,sc7280
+
+ - description: Google Zombie with NVMe (newest rev)
+ items:
+ - const: google,zombie-sku2
+ - const: google,zombie-sku3
+ - const: google,zombie-sku515
+ - const: qcom,sc7280
+
+ - description: Google Zombie with LTE and NVMe (newest rev)
+ items:
+ - const: google,zombie-sku514
+ - const: qcom,sc7280
+
- items:
- enum:
- lenovo,flex-5g
@@ -604,13 +783,22 @@ properties:
- items:
- enum:
+ - huawei,gaokun3
- lenovo,thinkpad-x13s
+ - microsoft,arcata
+ - microsoft,blackrock
- qcom,sc8280xp-crd
- qcom,sc8280xp-qrd
- const: qcom,sc8280xp
- items:
- enum:
+ - lenovo,tbx605f
+ - motorola,ali
+ - const: qcom,sdm450
+
+ - items:
+ - enum:
- sony,discovery-row
- sony,kirin-row
- sony,pioneer-row
@@ -625,6 +813,7 @@ properties:
- items:
- enum:
- fairphone,fp3
+ - motorola,ocean
- const: qcom,sdm632
- items:
@@ -639,6 +828,11 @@ properties:
- items:
- enum:
+ - google,sargo
+ - const: qcom,sdm670
+
+ - items:
+ - enum:
- qcom,sdx55-mtp
- qcom,sdx55-telit-fn980-tlb
- qcom,sdx55-t55
@@ -651,6 +845,11 @@ properties:
- items:
- enum:
+ - qcom,sdx75-idp
+ - const: qcom,sdx75
+
+ - items:
+ - enum:
- qcom,ipq6018-cp01
- qcom,ipq6018-cp01-c1
- const: qcom,ipq6018
@@ -664,16 +863,44 @@ properties:
- items:
- enum:
+ - qcom,monaco-evk
+ - qcom,qcs8300-ride
+ - const: qcom,qcs8300
+
+ - items:
+ - enum:
+ - qcom,qcs615-ride
+ - const: qcom,qcs615
+ - const: qcom,sm6150
+
+ - items:
+ - enum:
- qcom,sa8155p-adp
- const: qcom,sa8155p
- items:
- enum:
- qcom,sa8295p-adp
+ - qcom,sa8540p-ride
- const: qcom,sa8540p
- items:
- enum:
+ - qcom,sa8775p-ride
+ - qcom,sa8775p-ride-r3
+ - const: qcom,sa8775p
+
+ - items:
+ - enum:
+ - qcom,lemans-evk
+ - qcom,qcs9100-ride
+ - qcom,qcs9100-ride-r3
+ - const: qcom,qcs9100
+ - const: qcom,sa8775p
+
+ - items:
+ - enum:
+ - huawei,planck
- lenovo,yoga-c630
- lg,judyln
- lg,judyp
@@ -681,18 +908,49 @@ properties:
- oneplus,fajita
- qcom,sdm845-mtp
- shift,axolotl
+ - samsung,starqltechn
- samsung,w737
- sony,akari-row
- sony,akatsuki-row
- sony,apollo-row
- thundercomm,db845c
- xiaomi,beryllium
+ - xiaomi,beryllium-ebbg
- xiaomi,polaris
- const: qcom,sdm845
- items:
- enum:
+ - oneplus,billie2
+ - const: qcom,sm4250
+
+ - items:
+ - enum:
+ - qcom,qrb4210-rb2
+ - const: qcom,qrb4210
+ - const: qcom,sm4250
+
+ - items:
+ - enum:
+ - qcom,sm4450-qrd
+ - const: qcom,sm4450
+
+ - items:
+ - enum:
+ - fxtec,pro1x
+ - const: qcom,sm6115
+
+ - items:
+ - enum:
+ - lenovo,j606f
+ - const: qcom,sm6115p
+ - const: qcom,sm6115
+
+ - items:
+ - enum:
- sony,pdx201
+ - xiaomi,ginkgo
+ - xiaomi,laurel-sprout
- const: qcom,sm6125
- items:
@@ -702,11 +960,32 @@ properties:
- items:
- enum:
+ - sony,pdx225
+ - const: qcom,sm6375
+
+ - items:
+ - enum:
+ - xiaomi,curtana
+ - xiaomi,joyeuse
+ - const: qcom,sm7125
+
+ - items:
+ - enum:
+ - google,sunfish
+ - const: qcom,sm7150
+
+ - items:
+ - enum:
- fairphone,fp4
- const: qcom,sm7225
- items:
- enum:
+ - nothing,spacewar
+ - const: qcom,sm7325
+
+ - items:
+ - enum:
- microsoft,surface-duo
- qcom,sm8150-hdk
- qcom,sm8150-mtp
@@ -719,8 +998,12 @@ properties:
- qcom,qrb5165-rb5
- qcom,sm8250-hdk
- qcom,sm8250-mtp
+ - samsung,r8q
+ - samsung,x1q
- sony,pdx203-generic
- sony,pdx206-generic
+ - xiaomi,elish
+ - xiaomi,pipa
- const: qcom,sm8250
- items:
@@ -736,9 +1019,223 @@ properties:
- enum:
- qcom,sm8450-hdk
- qcom,sm8450-qrd
+ - samsung,r0q
- sony,pdx223
+ - sony,pdx224
- const: qcom,sm8450
+ - items:
+ - enum:
+ - qcom,sm8550-hdk
+ - qcom,sm8550-mtp
+ - qcom,sm8550-qrd
+ - samsung,q5q
+ - sony,pdx234
+ - const: qcom,sm8550
+
+ - items:
+ - enum:
+ - qcom,qcs8550-aim300-aiot
+ - const: qcom,qcs8550-aim300
+ - const: qcom,qcs8550
+ - const: qcom,sm8550
+
+ - items:
+ - enum:
+ - qcom,sm8650-hdk
+ - qcom,sm8650-mtp
+ - qcom,sm8650-qrd
+ - const: qcom,sm8650
+
+ - items:
+ - enum:
+ - qcom,sm8750-mtp
+ - qcom,sm8750-qrd
+ - const: qcom,sm8750
+
+ - items:
+ - enum:
+ - qcom,x1e001de-devkit
+ - const: qcom,x1e001de
+ - const: qcom,x1e80100
+
+ - items:
+ - enum:
+ - lenovo,thinkpad-t14s-lcd
+ - lenovo,thinkpad-t14s-oled
+ - const: lenovo,thinkpad-t14s
+ - const: qcom,x1e78100
+ - const: qcom,x1e80100
+
+ - items:
+ - enum:
+ - asus,vivobook-s15
+ - asus,zenbook-a14-ux3407ra
+ - dell,inspiron-14-plus-7441
+ - dell,latitude-7455
+ - dell,xps13-9345
+ - hp,elitebook-ultra-g1q
+ - hp,omnibook-x14
+ - lenovo,yoga-slim7x
+ - microsoft,romulus13
+ - microsoft,romulus15
+ - qcom,x1e80100-crd
+ - qcom,x1e80100-qcp
+ - const: qcom,x1e80100
+
+ - items:
+ - enum:
+ - qcom,hamoa-iot-evk
+ - const: qcom,hamoa-iot-som
+ - const: qcom,x1e80100
+
+ - items:
+ - enum:
+ - asus,zenbook-a14-ux3407qa-lcd
+ - asus,zenbook-a14-ux3407qa-oled
+ - const: asus,zenbook-a14-ux3407qa
+ - const: qcom,x1p42100
+
+ - items:
+ - enum:
+ - hp,omnibook-x14-fe1
+ - lenovo,thinkbook-16
+ - qcom,x1p42100-crd
+ - const: qcom,x1p42100
+
+ # Board compatibles go above
+
+ qcom,msm-id:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 8
+ items:
+ items:
+ - description: |
+ MSM chipset ID - an exact match value consisting of two bitfields::
+ - bits 0-15 - The unique MSM chipset ID
+ - bits 16-31 - Reserved; should be 0
+ - description: |
+ Hardware revision ID - a chipset specific 32-bit ID representing
+ the version of the chipset. It is best a match value - the
+ bootloader will look for the closest possible match.
+ deprecated: true
+ description:
+ The MSM chipset and hardware revision used Qualcomm bootloaders. It
+ can optionally be an array of these to indicate multiple hardware that
+ use the same device tree. It is expected that the bootloader will use
+ this information at boot-up to decide which device tree to use when given
+ multiple device trees, some of which may not be compatible with the
+ actual hardware. It is the bootloader's responsibility to pass the
+ correct device tree to the kernel.
+ The property is deprecated.
+
+ qcom,board-id:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 8
+ oneOf:
+ - items:
+ - items:
+ - description: |
+ Board ID consisting of three bitfields::
+ - bits 31-24 - Unused
+ - bits 23-16 - Platform Version Major
+ - bits 15-8 - Platform Version Minor
+ - bits 7-0 - Platform Type
+ Platform Type field is an exact match value. The
+ Platform Major/Minor field is a best match. The bootloader will
+ look for the closest possible match.
+ - description: |
+ Subtype ID unique to a Platform Type/Chipset ID. For a given
+ Platform Type, there will typically only be a single board and the
+ subtype_id will be 0. However in some cases board variants may
+ need to be distinguished by different subtype_id values.
+ - items:
+ # OnePlus uses a variant of board-id with four elements:
+ - items:
+ - const: 8
+ - const: 0
+ - description: OnePlus board ID
+ - description: OnePlus subtype ID
+ deprecated: true
+ description:
+ The board type and revision information. It can optionally be an array
+ of these to indicate multiple boards that use the same device tree. It
+ is expected that the bootloader will use this information at boot-up to
+ decide which device tree to use when given multiple device trees, some of
+ which may not be compatible with the actual hardware. It is the
+ bootloader's responsibility to pass the correct device tree to the
+ kernel
+ The property is deprecated.
+
+allOf:
+ # Explicit allow-list for older SoCs. The legacy properties are not allowed
+ # on newer SoCs.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,apq8026
+ - qcom,apq8094
+ - qcom,apq8096
+ - qcom,msm8917
+ - qcom,msm8937
+ - qcom,msm8939
+ - qcom,msm8953
+ - qcom,msm8956
+ - qcom,msm8992
+ - qcom,msm8994
+ - qcom,msm8996
+ - qcom,msm8998
+ - qcom,sdm450
+ - qcom,sdm630
+ - qcom,sdm632
+ - qcom,sdm636
+ - qcom,sdm845
+ - qcom,sdx55
+ - qcom,sdx65
+ - qcom,sdx75
+ - qcom,sm4250
+ - qcom,sm6115
+ - qcom,sm6125
+ - qcom,sm6350
+ - qcom,sm7125
+ - qcom,sm7225
+ - qcom,sm8150
+ - qcom,sm8250
+ then:
+ properties:
+ qcom,board-id: true
+ qcom,msm-id: true
+ else:
+ properties:
+ qcom,board-id: false
+ qcom,msm-id: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - oneplus,cheeseburger
+ - oneplus,dumpling
+ - oneplus,enchilada
+ - oneplus,fajita
+ - oneplus,oneplus3
+ - oneplus,oneplus3t
+ then:
+ properties:
+ qcom,board-id:
+ items:
+ minItems: 4
+ else:
+ properties:
+ qcom,board-id:
+ items:
+ maxItems: 2
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/rda.yaml b/Documentation/devicetree/bindings/arm/rda.yaml
index a5c0444aa2b4..09241ea1d228 100644
--- a/Documentation/devicetree/bindings/arm/rda.yaml
+++ b/Documentation/devicetree/bindings/arm/rda.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/rda.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: RDA Micro platforms device tree bindings
+title: RDA Micro platforms
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
index 9fb0297fe1ce..ddd9a85099e9 100644
--- a/Documentation/devicetree/bindings/arm/realtek.yaml
+++ b/Documentation/devicetree/bindings/arm/realtek.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/realtek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Realtek platforms device tree bindings
+title: Realtek platforms
maintainers:
- Andreas Färber <afaerber@suse.de>
diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml
deleted file mode 100644
index 2fc81c776a06..000000000000
--- a/Documentation/devicetree/bindings/arm/renesas.yaml
+++ /dev/null
@@ -1,471 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/renesas.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
-
-maintainers:
- - Geert Uytterhoeven <geert+renesas@glider.be>
-
-properties:
- $nodename:
- const: '/'
- compatible:
- oneOf:
- - description: Emma Mobile EV2
- items:
- - enum:
- - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual
- - const: renesas,emev2
-
- - description: RZ/A1H (R7S72100)
- items:
- - enum:
- - renesas,genmai # Genmai (RTK772100BC00000BR)
- - renesas,gr-peach # GR-Peach (X28A-M01-E/F)
- - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE)
- - const: renesas,r7s72100
-
- - description: RZ/A2 (R7S9210)
- items:
- - enum:
- - renesas,rza2mevb # RZ/A2M Eval Board (RTK7921053S00000BE)
- - const: renesas,r7s9210
-
- - description: SH-Mobile AG5 (R8A73A00/SH73A0)
- items:
- - enum:
- - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT
- - const: renesas,sh73a0
-
- - description: R-Mobile APE6 (R8A73A40)
- items:
- - enum:
- - renesas,ape6evm
- - const: renesas,r8a73a4
-
- - description: R-Mobile A1 (R8A77400)
- items:
- - enum:
- - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA
- - const: renesas,r8a7740
-
- - description: RZ/G1H (R8A77420)
- items:
- - enum:
- # iWave Systems RZ/G1H Qseven System On Module (iW-RainboW-G21M-Qseven)
- - iwave,g21m
- - const: renesas,r8a7742
-
- - items:
- - enum:
- # iWave Systems RZ/G1H Qseven Development Platform (iW-RainboW-G21D-Qseven)
- - iwave,g21d
- - const: iwave,g21m
- - const: renesas,r8a7742
-
- - description: RZ/G1M (R8A77430)
- items:
- - enum:
- # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven)
- - iwave,g20d
- - const: iwave,g20m
- - const: renesas,r8a7743
-
- - items:
- - enum:
- # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
- - iwave,g20m
- - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE)
- - const: renesas,r8a7743
-
- - description: RZ/G1N (R8A77440)
- items:
- - enum:
- # iWave Systems RZ/G1N Qseven Development Platform (iW-RainboW-G20D-Qseven)
- - iwave,g20d
- - const: iwave,g20m
- - const: renesas,r8a7744
-
- - items:
- - enum:
- # iWave Systems RZ/G1N Qseven System On Module (iW-RainboW-G20M-Qseven)
- - iwave,g20m
- - const: renesas,r8a7744
-
- - description: RZ/G1E (R8A77450)
- items:
- - enum:
- - iwave,g22m # iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM)
- - renesas,sk-rzg1e # SK-RZG1E (YR8A77450S000BE)
- - const: renesas,r8a7745
-
- - description: iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D)
- items:
- - const: iwave,g22d
- - const: iwave,g22m
- - const: renesas,r8a7745
-
- - description: RZ/G1C (R8A77470)
- items:
- - enum:
- - iwave,g23s #iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
- - const: renesas,r8a77470
-
- - description: RZ/G2M (R8A774A1)
- items:
- - enum:
- - hoperun,hihope-rzg2m # HopeRun HiHope RZ/G2M platform
- - beacon,beacon-rzg2m # Beacon EmbeddedWorks RZ/G2M Kit
- - const: renesas,r8a774a1
-
- - items:
- - enum:
- - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
- - const: hoperun,hihope-rzg2m
- - const: renesas,r8a774a1
-
- - description: RZ/G2N (R8A774B1)
- items:
- - enum:
- - beacon,beacon-rzg2n # Beacon EmbeddedWorks RZ/G2N Kit
- - hoperun,hihope-rzg2n # HopeRun HiHope RZ/G2N platform
- - const: renesas,r8a774b1
-
- - items:
- - enum:
- - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
- - const: hoperun,hihope-rzg2n
- - const: renesas,r8a774b1
-
- - description: RZ/G2E (R8A774C0)
- items:
- - enum:
- - si-linux,cat874 # Silicon Linux RZ/G2E 96board platform (CAT874)
- - const: renesas,r8a774c0
-
- - items:
- - enum:
- - si-linux,cat875 # Silicon Linux sub board for CAT874 (CAT875)
- - const: si-linux,cat874
- - const: renesas,r8a774c0
-
- - description: RZ/G2H (R8A774E1)
- items:
- - enum:
- - beacon,beacon-rzg2h # Beacon EmbeddedWorks RZ/G2H Kit
- - hoperun,hihope-rzg2h # HopeRun HiHope RZ/G2H platform
- - const: renesas,r8a774e1
-
- - items:
- - enum:
- - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
- - const: hoperun,hihope-rzg2h
- - const: renesas,r8a774e1
-
- - description: R-Car M1A (R8A77781)
- items:
- - enum:
- - renesas,bockw
- - const: renesas,r8a7778
-
- - description: R-Car H1 (R8A77790)
- items:
- - enum:
- - renesas,marzen # Marzen (R0P7779A00010S)
- - const: renesas,r8a7779
-
- - description: R-Car H2 (R8A77900)
- items:
- - enum:
- - renesas,lager # Lager (RTP0RC7790SEB00010S)
- - renesas,stout # Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD)
- - const: renesas,r8a7790
-
- - description: R-Car M2-W (R8A77910)
- items:
- - enum:
- - renesas,henninger
- - renesas,koelsch # Koelsch (RTP0RC7791SEB00010S)
- - renesas,porter # Porter (M2-LCDP)
- - const: renesas,r8a7791
-
- - description: R-Car V2H (R8A77920)
- items:
- - enum:
- - renesas,blanche # Blanche (RTP0RC7792SEB00010S)
- - renesas,wheat # Wheat (RTP0RC7792ASKB0000JE)
- - const: renesas,r8a7792
-
- - description: R-Car M2-N (R8A77930)
- items:
- - enum:
- - renesas,gose # Gose (RTP0RC7793SEB00010S)
- - const: renesas,r8a7793
-
- - description: R-Car E2 (R8A77940)
- items:
- - enum:
- - renesas,alt # Alt (RTP0RC7794SEB00010S)
- - renesas,silk # SILK (RTP0RC7794LCB00011S)
- - const: renesas,r8a7794
-
- - description: R-Car H3 (R8A77950)
- items:
- - enum:
- # H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1))
- # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
- - renesas,h3ulcb
- - renesas,salvator-x # Salvator-X (RTP0RC7795SIPB0010S)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
- - const: renesas,r8a7795
-
- - description: R-Car M3-W (R8A77960)
- items:
- - enum:
- - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
- - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
- - const: renesas,r8a7796
-
- - description: R-Car M3-W+ (R8A77961)
- items:
- - enum:
- - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP8J77961ASKB0SK0SA05A (M3 ES3.0))
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012SA5A)
- - const: renesas,r8a77961
-
- - description: Kingfisher (SBEV-RCAR-KF-M03)
- oneOf:
- - items:
- - const: shimafuji,kingfisher
- - enum:
- - renesas,h3ulcb
- - renesas,m3ulcb
- - renesas,m3nulcb
- - enum:
- - renesas,r8a7795
- - renesas,r8a7796
- - renesas,r8a77961
- - renesas,r8a77965
- - items:
- - const: shimafuji,kingfisher
- - enum:
- - renesas,h3ulcb
- - renesas,m3ulcb
- - renesas,m3nulcb
- - enum:
- - renesas,r8a779m0
- - renesas,r8a779m1
- - renesas,r8a779m2
- - renesas,r8a779m3
- - renesas,r8a779m4
- - renesas,r8a779m5
- - renesas,r8a779m8
- - renesas,r8a779mb
- - enum:
- - renesas,r8a7795
- - renesas,r8a77961
- - renesas,r8a77965
-
- - description: R-Car M3-N (R8A77965)
- items:
- - enum:
- - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
- - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S (M3-N))
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S)
- - const: renesas,r8a77965
-
- - description: R-Car V3M (R8A77970)
- items:
- - enum:
- - renesas,eagle # Eagle (RTP0RC77970SEB0010S)
- - renesas,v3msk # V3MSK (Y-ASK-RCAR-V3M-WS10)
- - const: renesas,r8a77970
-
- - description: R-Car V3H (R8A77980)
- items:
- - enum:
- - renesas,condor # Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01)
- - renesas,v3hsk # V3HSK (Y-ASK-RCAR-V3H-WS10)
- - const: renesas,r8a77980
-
- - description: R-Car V3H2 (R8A77980A)
- items:
- - enum:
- - renesas,condor-i # Condor-I (RTP0RC77980SEBS012SA01)
- - const: renesas,r8a77980a
- - const: renesas,r8a77980
-
- - description: R-Car E3 (R8A77990)
- items:
- - enum:
- - renesas,ebisu # Ebisu (RTP0RC77990SEB0010S)
- - const: renesas,r8a77990
-
- - description: R-Car D3 (R8A77995)
- items:
- - enum:
- - renesas,draak # Draak (RTP0RC77995SEB0010S)
- - const: renesas,r8a77995
-
- - description: R-Car V3U (R8A779A0)
- items:
- - enum:
- - renesas,falcon-cpu # Falcon CPU board (RTP0RC779A0CPB0010S)
- - const: renesas,r8a779a0
-
- - items:
- - enum:
- - renesas,falcon-breakout # Falcon BreakOut board (RTP0RC779A0BOB0010S)
- - const: renesas,falcon-cpu
- - const: renesas,r8a779a0
-
- - description: R-Car S4-8 (R8A779F0)
- items:
- - enum:
- - renesas,spider-cpu # Spider CPU board (RTP8A779F0ASKB0SC2S)
- - const: renesas,r8a779f0
-
- - items:
- - enum:
- - renesas,spider-breakout # Spider BreakOut board (RTP8A779F0ASKB0SB0S)
- - const: renesas,spider-cpu
- - const: renesas,r8a779f0
-
- - description: R-Car V4H (R8A779G0)
- items:
- - enum:
- - renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000)
- - const: renesas,r8a779g0
-
- - items:
- - enum:
- - renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000)
- - const: renesas,white-hawk-cpu
- - const: renesas,r8a779g0
-
- - description: R-Car H3e (R8A779M0)
- items:
- - enum:
- - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m0
- - const: renesas,r8a7795
-
- - description: R-Car H3e-2G (R8A779M1)
- items:
- - enum:
- - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m1
- - const: renesas,r8a7795
-
- - description: R-Car M3e (R8A779M2)
- items:
- - enum:
- - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m2
- - const: renesas,r8a77961
-
- - description: R-Car M3e-2G (R8A779M3)
- items:
- - enum:
- - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m3
- - const: renesas,r8a77961
-
- - description: R-Car M3Ne (R8A779M4)
- items:
- - enum:
- - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m4
- - const: renesas,r8a77965
-
- - description: R-Car M3Ne-2G (R8A779M5)
- items:
- - enum:
- - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m5
- - const: renesas,r8a77965
-
- - description: R-Car E3e (R8A779M6)
- items:
- - enum:
- - renesas,ebisu # Ebisu
- - const: renesas,r8a779m6
- - const: renesas,r8a77990
-
- - description: R-Car D3e (R8A779M7)
- items:
- - enum:
- - renesas,draak # Draak
- - const: renesas,r8a779m7
- - const: renesas,r8a77995
-
- - description: R-Car H3Ne (R8A779M8)
- items:
- - enum:
- - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779m8
- - const: renesas,r8a7795
-
- - description: R-Car H3Ne-1.7G (R8A779MB)
- items:
- - enum:
- - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
- - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
- - const: renesas,r8a779mb
- - const: renesas,r8a7795
-
- - description: RZ/N1D (R9A06G032)
- items:
- - enum:
- - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package)
- - const: renesas,r9a06g032
-
- - description: RZ/G2UL (R9A07G043)
- items:
- - enum:
- - renesas,smarc-evk # SMARC EVK
- - enum:
- - renesas,r9a07g043u11 # RZ/G2UL Type-1
- - renesas,r9a07g043u12 # RZ/G2UL Type-2
- - const: renesas,r9a07g043
-
- - description: RZ/G2{L,LC} (R9A07G044)
- items:
- - enum:
- - renesas,smarc-evk # SMARC EVK
- - enum:
- - renesas,r9a07g044c1 # Single Cortex-A55 RZ/G2LC
- - renesas,r9a07g044c2 # Dual Cortex-A55 RZ/G2LC
- - renesas,r9a07g044l1 # Single Cortex-A55 RZ/G2L
- - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L
- - const: renesas,r9a07g044
-
- - description: RZ/V2L (R9A07G054)
- items:
- - enum:
- - renesas,smarc-evk # SMARC EVK
- - enum:
- - renesas,r9a07g054l1 # Single Cortex-A55 RZ/V2L
- - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L
- - const: renesas,r9a07g054
-
- - description: RZ/V2M (R9A09G011)
- items:
- - enum:
- - renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0
- - const: renesas,r9a09g011
-
-additionalProperties: true
-
-...
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4c64d9ff089c..d496421dbd87 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/rockchip.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip platforms device tree bindings
+title: Rockchip platforms
maintainers:
- Heiko Stuebner <heiko@sntech.de>
@@ -15,6 +15,11 @@ properties:
compatible:
oneOf:
+ - description: 100ASK DshanPi A1 board
+ items:
+ - const: 100ask,dshanpi-a1
+ - const: rockchip,rk3576
+
- description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
items:
- const: vamrs,ficus
@@ -25,36 +30,93 @@ properties:
- const: vamrs,rock960
- const: rockchip,rk3399
+ - description: 9Tripod X3568 series board
+ items:
+ - enum:
+ - 9tripod,x3568-v4
+ - const: rockchip,rk3568
+
- description: Amarula Vyasa RK3288
items:
- const: amarula,vyasa-rk3288
- const: rockchip,rk3288
- - description: Anbernic RG353P
+ - description: Anbernic RK3326 Handheld Gaming Console
items:
- - const: anbernic,rg353p
- - const: rockchip,rk3566
+ - enum:
+ - anbernic,rg351m
+ - anbernic,rg351v
+ - const: rockchip,rk3326
- - description: Anbernic RG503
+ - description: Anbernic RK3566 Handheld Gaming Console
items:
- - const: anbernic,rg503
+ - enum:
+ - anbernic,rg353p
+ - anbernic,rg353ps
+ - anbernic,rg353v
+ - anbernic,rg353vs
+ - anbernic,rg503
+ - anbernic,rg-arc-d
+ - anbernic,rg-arc-s
- const: rockchip,rk3566
+ - description: Ariaboard Photonicat
+ items:
+ - const: ariaboard,photonicat
+ - const: rockchip,rk3568
+
+ - description: ArmSoM Sige1 board
+ items:
+ - const: armsom,sige1
+ - const: rockchip,rk3528
+
+ - description: ArmSoM Sige5 board
+ items:
+ - const: armsom,sige5
+ - const: rockchip,rk3576
+
+ - description: ArmSoM Sige7 board
+ items:
+ - const: armsom,sige7
+ - const: rockchip,rk3588
+
+ - description: ArmSoM LM7 SoM
+ items:
+ - enum:
+ - armsom,w3
+ - const: armsom,lm7
+ - const: rockchip,rk3588
+
- description: Asus Tinker board
items:
- - const: asus,rk3288-tinker
+ - enum:
+ - asus,rk3288-tinker
+ - asus,rk3288-tinker-s
- const: rockchip,rk3288
- - description: Asus Tinker board S
+ - description: Asus Tinker Board 3/3S
items:
- - const: asus,rk3288-tinker-s
- - const: rockchip,rk3288
+ - enum:
+ - asus,rk3566-tinker-board-3
+ - asus,rk3566-tinker-board-3s
+ - const: rockchip,rk3566
- description: Beelink A1
items:
- const: azw,beelink-a1
- const: rockchip,rk3328
+ - description: BigTreeTech CB2 Manta M4/8P
+ items:
+ - const: bigtreetech,cb2-manta
+ - const: bigtreetech,cb2
+ - const: rockchip,rk3566
+
+ - description: BigTreeTech Pi 2
+ items:
+ - const: bigtreetech,pi2
+ - const: rockchip,rk3566
+
- description: bq Curie 2 tablet
items:
- const: mundoreader,bq-curie2
@@ -75,11 +137,54 @@ properties:
- const: chipspark,rayeager-px2
- const: rockchip,rk3066a
+ - description: Cool Pi Compute Module 5(CM5) EVB
+ items:
+ - enum:
+ - coolpi,pi-cm5-evb
+ - const: coolpi,pi-cm5
+ - const: rockchip,rk3588
+
+ - description: Cool Pi CM5 GenBook
+ items:
+ - enum:
+ - coolpi,pi-cm5-genbook
+ - const: coolpi,pi-cm5
+ - const: rockchip,rk3588
+
+ - description: Cool Pi 4 Model B
+ items:
+ - const: coolpi,pi-4b
+ - const: rockchip,rk3588s
+
+ - description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
+ items:
+ - const: edgeble,neural-compute-module-2-io # Edgeble Neural Compute Module 2 IO Board
+ - const: edgeble,neural-compute-module-2 # Edgeble Neural Compute Module 2 SoM
+ - const: rockchip,rv1126
+
+ - description: Edgeble Neural Compute Module 6(Neu6) SoM based boards
+ items:
+ - const: edgeble,neural-compute-module-6a-io # Edgeble NCM6A-IO Board
+ - enum:
+ - edgeble,neural-compute-module-6a # Edgeble Neural Compute Module 6A SoM
+ - edgeble,neural-compute-module-6b # Edgeble Neural Compute Module 6B SoM
+ - const: rockchip,rk3588
+
- description: Elgin RV1108 R1
items:
- const: elgin,rv1108-r1
- const: rockchip,rv1108
+ - description: EmbedFire LubanCat 1
+ items:
+ - const: embedfire,lubancat-1
+ - const: rockchip,rk3566
+
+ - description: EmbedFire LubanCat 2
+ items:
+ - const: embedfire,lubancat-2
+ - const: rockchip,rk3568
+
- description: Engicam PX30.Core C.TOUCH 2.0
items:
- const: engicam,px30-core-ctouch2
@@ -98,6 +203,26 @@ properties:
- const: engicam,px30-core
- const: rockchip,px30
+ - description: Firefly iCore-3588Q-based boards
+ items:
+ - enum:
+ - mntre,reform2-rcore
+ - const: firefly,icore-3588q
+ - const: rockchip,rk3588
+
+ - description: Firefly Core-3588J-based boards
+ items:
+ - enum:
+ - firefly,itx-3588j
+ - const: firefly,core-3588j
+ - const: rockchip,rk3588
+
+ - description: Firefly Core-PX30-JD4 on MB-JD4-PX30 baseboard
+ items:
+ - const: firefly,px30-jd4-core-mb
+ - const: firefly,px30-jd4-core
+ - const: rockchip,px30
+
- description: Firefly Firefly-RK3288
items:
- enum:
@@ -143,16 +268,52 @@ properties:
- firefly,roc-rk3399-pc-plus
- const: rockchip,rk3399
+ - description: Firefly ROC-RK3576-PC
+ items:
+ - const: firefly,roc-rk3576-pc
+ - const: rockchip,rk3576
+
+ - description: Firefly ROC-RK3588-RT
+ items:
+ - const: firefly,roc-rk3588-rt
+ - const: rockchip,rk3588
+
- description: Firefly Station M2
items:
- const: firefly,rk3566-roc-pc
- const: rockchip,rk3566
- - description: FriendlyElec NanoPi R2S
+ - description: Firefly Station M3
+ items:
+ - const: firefly,rk3588s-roc-pc
+ - const: rockchip,rk3588s
+
+ - description: Firefly Station P2
+ items:
+ - const: firefly,rk3568-roc-pc
+ - const: rockchip,rk3568
+
+ - description: Forlinx FET3588-C SoM
items:
- - const: friendlyarm,nanopi-r2s
+ - enum:
+ - forlinx,ok3588-c
+ - const: forlinx,fet3588-c
+ - const: rockchip,rk3588
+
+ - description: FriendlyElec NanoPi R2 series boards
+ items:
+ - enum:
+ - friendlyarm,nanopi-r2c
+ - friendlyarm,nanopi-r2c-plus
+ - friendlyarm,nanopi-r2s
+ - friendlyarm,nanopi-r2s-plus
- const: rockchip,rk3328
+ - description: FriendlyElec NanoPi R3S
+ items:
+ - const: friendlyarm,nanopi-r3s
+ - const: rockchip,rk3566
+
- description: FriendlyElec NanoPi4 series boards
items:
- enum:
@@ -164,11 +325,70 @@ properties:
- friendlyarm,nanopi-r4s-enterprise
- const: rockchip,rk3399
+ - description: FriendlyElec NanoPi M5 series boards
+ items:
+ - enum:
+ - friendlyarm,nanopi-m5
+ - const: rockchip,rk3576
+
+ - description: FriendlyElec NanoPi R5 series boards
+ items:
+ - enum:
+ - friendlyarm,nanopi-r5c
+ - friendlyarm,nanopi-r5s
+ - const: rockchip,rk3568
+
+ - description: FriendlyElec NanoPi R6 series boards
+ items:
+ - enum:
+ - friendlyarm,nanopi-r6c
+ - friendlyarm,nanopi-r6s
+ - const: rockchip,rk3588s
+
+ - description: FriendlyElec NanoPi R76S
+ items:
+ - const: friendlyarm,nanopi-r76s
+ - const: rockchip,rk3576
+
+ - description: FriendlyElec NanoPi Zero2
+ items:
+ - const: friendlyarm,nanopi-zero2
+ - const: rockchip,rk3528
+
+ - description: FriendlyElec NanoPC T6 series boards
+ items:
+ - enum:
+ - friendlyarm,nanopc-t6
+ - friendlyarm,nanopc-t6-lts
+ - const: rockchip,rk3588
+
+ - description: FriendlyElec CM3588-based boards
+ items:
+ - enum:
+ - friendlyarm,cm3588-nas
+ - const: friendlyarm,cm3588
+ - const: rockchip,rk3588
+
+ - description: GameForce Ace
+ items:
+ - const: gameforce,ace
+ - const: rockchip,rk3588s
+
+ - description: GameForce Chi
+ items:
+ - const: gameforce,chi
+ - const: rockchip,rk3326
+
- description: GeekBuying GeekBox
items:
- const: geekbuying,geekbox
- const: rockchip,rk3368
+ - description: Geniatech XPI-3128
+ items:
+ - const: geniatech,xpi-3128
+ - const: rockchip,rk3128
+
- description: Google Bob (Asus Chromebook Flip C101PA)
items:
- const: google,bob-rev13
@@ -458,6 +678,11 @@ properties:
- const: google,veyron
- const: rockchip,rk3288
+ - description: H96 Max V58 TV Box
+ items:
+ - const: haochuangyi,h96-max-v58
+ - const: rockchip,rk3588
+
- description: Haoyu MarsBoard RK3066
items:
- const: haoyu,marsboard-rk3066
@@ -468,11 +693,48 @@ properties:
- const: hardkernel,rk3326-odroid-go2
- const: rockchip,rk3326
+ - description: Hardkernel Odroid Go Advance Black Edition
+ items:
+ - const: hardkernel,rk3326-odroid-go2-v11
+ - const: rockchip,rk3326
+
+ - description: Hardkernel Odroid Go Super
+ items:
+ - const: hardkernel,rk3326-odroid-go3
+ - const: rockchip,rk3326
+
+ - description: Hardkernel Odroid M1
+ items:
+ - const: hardkernel,odroid-m1
+ - const: rockchip,rk3568
+
+ - description: Hardkernel Odroid M1S
+ items:
+ - const: hardkernel,odroid-m1s
+ - const: rockchip,rk3566
+
+ - description: Hardkernel Odroid M2
+ items:
+ - const: hardkernel,odroid-m2
+ - const: rockchip,rk3588s
+
+ - description: HINLINK H66K / H68K
+ items:
+ - enum:
+ - hinlink,h66k
+ - hinlink,h68k
+ - const: rockchip,rk3568
+
- description: Hugsun X99 TV Box
items:
- const: hugsun,x99
- const: rockchip,rk3399
+ - description: Indiedroid Nova SBC
+ items:
+ - const: indiedroid,nova
+ - const: rockchip,rk3588s
+
- description: Khadas Edge series boards
items:
- enum:
@@ -481,6 +743,11 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
+ - description: Khadas Edge2 series boards
+ items:
+ - const: khadas,edge2
+ - const: rockchip,rk3588s
+
- description: Kobol Helios64
items:
- const: kobol,helios64
@@ -496,11 +763,40 @@ properties:
- const: leez,p710
- const: rockchip,rk3399
+ - description: LCKFB Taishan Pi RK3566
+ items:
+ - const: lckfb,tspi-rk3566
+ - const: rockchip,rk3566
+
+ - description: LinkEase EasePi R1
+ items:
+ - const: linkease,easepi-r1
+ - const: rockchip,rk3568
+
+ - description: Luckfox Core3576 Module based boards
+ items:
+ - enum:
+ - luckfox,omni3576
+ - const: luckfox,core3576
+ - const: rockchip,rk3576
+
+ - description: Lunzn FastRhino R66S / R68S
+ items:
+ - enum:
+ - lunzn,fastrhino-r66s
+ - lunzn,fastrhino-r68s
+ - const: rockchip,rk3568
+
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
- const: rockchip,rk3288
+ - description: Neardi LBA3368
+ items:
+ - const: neardi,lba3368
+ - const: rockchip,rk3368
+
- description: Netxeon R89 board
items:
- const: netxeon,r89
@@ -511,9 +807,9 @@ properties:
- const: openailab,eaidk-610
- const: rockchip,rk3399
- - description: Orange Pi RK3399 board
+ - description: Xunlong Orange Pi RK3399 board
items:
- - const: rockchip,rk3399-orangepi
+ - const: xunlong,rk3399-orangepi
- const: rockchip,rk3399
- description: Phytec phyCORE-RK3288 Rapid Development Kit
@@ -522,7 +818,7 @@ properties:
- const: phytec,rk3288-phycore-som
- const: rockchip,rk3288
- - description: Pine64 PinebookPro
+ - description: Pine64 Pinebook Pro
items:
- const: pine64,pinebook-pro
- const: rockchip,rk3399
@@ -535,11 +831,19 @@ properties:
- const: pine64,pinenote
- const: rockchip,rk3566
- - description: Pine64 PinePhonePro
+ - description: Pine64 PinePhone Pro
items:
- const: pine64,pinephone-pro
- const: rockchip,rk3399
+ - description: Pine64 PineTab2
+ items:
+ - enum:
+ - pine64,pinetab2-v0.1
+ - pine64,pinetab2-v2.0
+ - const: pine64,pinetab2
+ - const: rockchip,rk3566
+
- description: Pine64 Rock64
items:
- const: pine64,rock64
@@ -560,18 +864,79 @@ properties:
- pine64,quartz64-b
- const: rockchip,rk3566
- - description: Pine64 SoQuartz SoM
+ - description: Pine64 QuartzPro64
+ items:
+ - const: pine64,quartzpro64
+ - const: rockchip,rk3588
+
+ - description: Pine64 SOQuartz
items:
- enum:
+ - pine64,soquartz-blade
- pine64,soquartz-cm4io
+ - pine64,soquartz-model-a
- const: pine64,soquartz
- const: rockchip,rk3566
+ - description: Powkiddy RK3566 Handheld Gaming Console
+ items:
+ - enum:
+ - powkiddy,rgb10max3
+ - powkiddy,rgb20sx
+ - powkiddy,rgb30
+ - powkiddy,rk2023
+ - powkiddy,x55
+ - const: rockchip,rk3566
+
+ - description: Protonic MECSBC board
+ items:
+ - const: prt,mecsbc
+ - const: rockchip,rk3568
+
+ - description: QNAP TS-x33 NAS devices
+ items:
+ - enum:
+ - qnap,ts233
+ - qnap,ts433
+ - const: rockchip,rk3568
+
+ - description: Radxa Compute Module 3 (CM3)
+ items:
+ - enum:
+ - radxa,cm3-io
+ - const: radxa,cm3
+ - const: rockchip,rk3566
+
+ - description: Radxa CM3 Industrial
+ items:
+ - enum:
+ - radxa,e25
+ - const: radxa,cm3i
+ - const: rockchip,rk3568
+
+ - description: Radxa E20C
+ items:
+ - const: radxa,e20c
+ - const: rockchip,rk3528
+
+ - description: Radxa E52C
+ items:
+ - const: radxa,e52c
+ - const: rockchip,rk3582
+ - const: rockchip,rk3588s
+
- description: Radxa Rock
items:
- const: radxa,rock
- const: rockchip,rk3188
+ - description: Radxa ROCK 2A/2F
+ items:
+ - enum:
+ - radxa,rock-2a
+ - radxa,rock-2f
+ - const: rockchip,rk3528
+
- description: Radxa ROCK Pi 4A/A+/B/B+/C
items:
- enum:
@@ -588,6 +953,16 @@ properties:
- const: radxa,rock-4c-plus
- const: rockchip,rk3399
+ - description: Radxa ROCK 4D
+ items:
+ - const: radxa,rock-4d
+ - const: rockchip,rk3576
+
+ - description: Radxa ROCK 4SE
+ items:
+ - const: radxa,rock-4se
+ - const: rockchip,rk3399
+
- description: Radxa ROCK Pi E
items:
- const: radxa,rockpi-e
@@ -610,16 +985,73 @@ properties:
- const: radxa,rockpis
- const: rockchip,rk3308
- - description: Radxa Rock2 Square
+ - description: Radxa Rock 2 Square
items:
- const: radxa,rock2-square
- const: rockchip,rk3288
- - description: Radxa ROCK3 Model A
+ - description: Radxa ROCK 3A
items:
- const: radxa,rock3a
- const: rockchip,rk3568
+ - description: Radxa ROCK 3B
+ items:
+ - const: radxa,rock-3b
+ - const: rockchip,rk3568
+
+ - description: Radxa ROCK 3C
+ items:
+ - const: radxa,rock-3c
+ - const: rockchip,rk3566
+
+ - description: Radxa ROCK 5 ITX
+ items:
+ - const: radxa,rock-5-itx
+ - const: rockchip,rk3588
+
+ - description: Radxa ROCK 5A
+ items:
+ - const: radxa,rock-5a
+ - const: rockchip,rk3588s
+
+ - description: Radxa ROCK 5B
+ items:
+ - const: radxa,rock-5b
+ - const: rockchip,rk3588
+
+ - description: Radxa ROCK 5B+
+ items:
+ - const: radxa,rock-5b-plus
+ - const: rockchip,rk3588
+
+ - description: Radxa ROCK 5C
+ items:
+ - const: radxa,rock-5c
+ - const: rockchip,rk3588s
+
+ - description: Radxa ROCK S0
+ items:
+ - const: radxa,rock-s0
+ - const: rockchip,rk3308
+
+ - description: Radxa ROCK 5T
+ items:
+ - const: radxa,rock-5t
+ - const: rockchip,rk3588
+
+ - description: Radxa ZERO 3W/3E
+ items:
+ - enum:
+ - radxa,zero-3e
+ - radxa,zero-3w
+ - const: rockchip,rk3566
+
+ - description: Relfor SAIB board
+ items:
+ - const: relfor,saib
+ - const: rockchip,rv1109
+
- description: Rikomagic MK808 v1
items:
- const: rikomagic,mk808
@@ -657,6 +1089,11 @@ properties:
- const: rockchip,rk3036-evb
- const: rockchip,rk3036
+ - description: Rockchip RK3128 Evaluation board
+ items:
+ - const: rockchip,rk3128-evb
+ - const: rockchip,rk3128
+
- description: Rockchip RK3228 Evaluation board
items:
- const: rockchip,rk3228-evb
@@ -694,6 +1131,11 @@ properties:
- const: rockchip,rk3399-evb
- const: rockchip,rk3399
+ - description: Rockchip RK3399 Industry Evaluation board
+ items:
+ - const: rockchip,rk3399-evb-ind
+ - const: rockchip,rk3399
+
- description: Rockchip RK3399 Sapphire standalone
items:
- const: rockchip,rk3399-sapphire
@@ -704,11 +1146,93 @@ properties:
- const: rockchip,rk3399-sapphire-excavator
- const: rockchip,rk3399
+ - description: Rockchip RK3562 Evaluation board 2
+ items:
+ - const: rockchip,rk3562-evb2-v10
+ - const: rockchip,rk3562
+
+ - description: Rockchip RK3566 BOX Evaluation Demo board
+ items:
+ - const: rockchip,rk3566-box-demo
+ - const: rockchip,rk3566
+
+ - description: Rockchip RK3568 Evaluation board
+ items:
+ - const: rockchip,rk3568-evb1-v10
+ - const: rockchip,rk3568
+
+ - description: Rockchip RK3576 Evaluation board
+ items:
+ - const: rockchip,rk3576-evb1-v10
+ - const: rockchip,rk3576
+
+ - description: Rockchip RK3588 Evaluation board
+ items:
+ - enum:
+ - rockchip,rk3588-evb1-v10
+ - rockchip,rk3588-evb2-v10
+ - const: rockchip,rk3588
+
+ - description: Rockchip RK3588S Evaluation board
+ items:
+ - const: rockchip,rk3588s-evb1-v10
+ - const: rockchip,rk3588s
+
- description: Rockchip RV1108 Evaluation board
items:
- const: rockchip,rv1108-evb
- const: rockchip,rv1108
+ - description: Rockchip Toybrick TB-RK3588X board
+ items:
+ - const: rockchip,rk3588-toybrick-x0
+ - const: rockchip,rk3588
+
+ - description: Sakura Pi RK3308B
+ items:
+ - const: sakurapi,rk3308-sakurapi-rk3308b
+ - const: rockchip,rk3308
+
+ - description: Sinovoip RK3308 Banana Pi P2 Pro
+ items:
+ - const: sinovoip,rk3308-bpi-p2pro
+ - const: rockchip,rk3308
+
+ - description: Sinovoip RK3568 Banana Pi R2 Pro
+ items:
+ - const: sinovoip,rk3568-bpi-r2pro
+ - const: rockchip,rk3568
+
+ - description: Sonoff iHost Smart Home Hub
+ items:
+ - const: itead,sonoff-ihost
+ - enum:
+ - rockchip,rv1126
+ - rockchip,rv1109
+
+ - description: Theobroma Systems PX30-Cobra
+ items:
+ - enum:
+ - tsd,px30-cobra-ltk050h3146w
+ - tsd,px30-cobra-ltk050h3146w-a2
+ - tsd,px30-cobra-ltk050h3148w
+ - tsd,px30-cobra-ltk500hd1829
+ - const: tsd,px30-cobra
+ - const: rockchip,px30
+
+ - description: Theobroma Systems PX30-PP1516
+ items:
+ - enum:
+ - tsd,px30-pp1516-ltk050h3146w-a2
+ - tsd,px30-pp1516-ltk050h3148w
+ - const: tsd,px30-pp1516
+ - const: rockchip,px30
+
+ - description: Theobroma Systems PX30-uQ7 with Haikou baseboard
+ items:
+ - const: tsd,px30-ringneck-haikou
+ - const: rockchip,px30
+
- description: Theobroma Systems RK3368-uQ7 with Haikou baseboard
items:
- const: tsd,rk3368-lion-haikou
@@ -719,25 +1243,66 @@ properties:
- const: tsd,rk3399-puma-haikou
- const: rockchip,rk3399
+ - description: Theobroma Systems RK3588-SBC Jaguar
+ items:
+ - const: tsd,rk3588-jaguar
+ - const: rockchip,rk3588
+
+ - description: Theobroma Systems RK3588-Q7 with Haikou baseboard
+ items:
+ - const: tsd,rk3588-tiger-haikou
+ - const: tsd,rk3588-tiger
+ - const: rockchip,rk3588
+
- description: Tronsmart Orion R68 Meta
items:
- const: tronsmart,orion-r68-meta
- const: rockchip,rk3368
- - description: Zkmagic A95X Z2
+ - description: Turing RK1
items:
- - const: zkmagic,a95x-z2
- - const: rockchip,rk3318
+ - const: turing,rk1
+ - const: rockchip,rk3588
- - description: Rockchip RK3568 Evaluation board
+ - description: WolfVision PF5 mainboard
items:
- - const: rockchip,rk3568-evb1-v10
+ - const: wolfvision,rk3568-pf5
- const: rockchip,rk3568
- - description: Rockchip RK3568 Banana Pi R2 Pro
+ - description: Xunlong Orange Pi 3B
items:
- - const: rockchip,rk3568-bpi-r2pro
- - const: rockchip,rk3568
+ - enum:
+ - xunlong,orangepi-3b-v1.1
+ - xunlong,orangepi-3b-v2.1
+ - const: xunlong,orangepi-3b
+ - const: rockchip,rk3566
+
+ - description: Xunlong Orange Pi 5 Max/Plus/Ultra
+ items:
+ - enum:
+ - xunlong,orangepi-5-max
+ - xunlong,orangepi-5-plus
+ - xunlong,orangepi-5-ultra
+ - const: rockchip,rk3588
+
+ - description: Xunlong Orange Pi R1 Plus / LTS
+ items:
+ - enum:
+ - xunlong,orangepi-r1-plus
+ - xunlong,orangepi-r1-plus-lts
+ - const: rockchip,rk3328
+
+ - description: Xunlong Orange Pi 5
+ items:
+ - enum:
+ - xunlong,orangepi-5
+ - xunlong,orangepi-5b
+ - const: rockchip,rk3588s
+
+ - description: Zkmagic A95X Z2
+ items:
+ - const: zkmagic,a95x-z2
+ - const: rockchip,rk3318
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
index 8c73bc7f4009..55b2200d6e75 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -25,8 +25,12 @@ select:
- rockchip,rk3288-pmu
- rockchip,rk3368-pmu
- rockchip,rk3399-pmu
+ - rockchip,rk3528-pmu
+ - rockchip,rk3562-pmu
- rockchip,rk3568-pmu
+ - rockchip,rk3576-pmu
- rockchip,rk3588-pmu
+ - rockchip,rv1126-pmu
required:
- compatible
@@ -41,19 +45,29 @@ properties:
- rockchip,rk3288-pmu
- rockchip,rk3368-pmu
- rockchip,rk3399-pmu
+ - rockchip,rk3528-pmu
+ - rockchip,rk3562-pmu
- rockchip,rk3568-pmu
+ - rockchip,rk3576-pmu
- rockchip,rk3588-pmu
+ - rockchip,rv1126-pmu
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
+ power-controller:
+ type: object
+
+ reboot-mode:
+ type: object
+
required:
- compatible
- reg
-additionalProperties: true
+additionalProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
deleted file mode 100644
index 3b8fbf3c00c5..000000000000
--- a/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-ARM Dual Cluster System Configuration Block
--------------------------------------------
-
-The Dual Cluster System Configuration Block (DCSCB) provides basic
-functionality for controlling clocks, resets and configuration pins in
-the Dual Cluster System implemented by the Real-Time System Model (RTSM).
-
-Required properties:
-
-- compatible : should be "arm,rtsm,dcscb"
-
-- reg : physical base address and the size of the registers window
-
-Example:
-
- dcscb@60000000 {
- compatible = "arm,rtsm,dcscb";
- reg = <0x60000000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index faea33e4f731..f8e20e602c20 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -14,12 +14,6 @@ properties:
const: '/'
compatible:
oneOf:
- - description: S3C2416 based boards
- items:
- - enum:
- - samsung,smdk2416 # Samsung SMDK2416
- - const: samsung,s3c2416
-
- description: S3C6410 based boards
items:
- enum:
@@ -45,6 +39,12 @@ properties:
- const: samsung,aries
- const: samsung,s5pv210
+ - description: Exynos2200 based boards
+ items:
+ - enum:
+ - samsung,g0s # Samsung Galaxy S22+ (SM-S906B)
+ - const: samsung,exynos2200
+
- description: Exynos3250 based boards
items:
- enum:
@@ -72,6 +72,16 @@ properties:
- const: samsung,exynos4210
- const: samsung,exynos4
+ - description: Samsung Galaxy Tab3 family boards
+ items:
+ - enum:
+ - samsung,t310 # Samsung Galaxy Tab 3 8.0 WiFi (SM-T310)
+ - samsung,t311 # Samsung Galaxy Tab 3 8.0 3G (SM-T311)
+ - samsung,t315 # Samsung Galaxy Tab 3 8.0 LTE (SM-T315)
+ - const: samsung,tab3
+ - const: samsung,exynos4212
+ - const: samsung,exynos4
+
- description: Exynos4412 based boards
items:
- enum:
@@ -171,6 +181,7 @@ properties:
- hardkernel,odroid-xu3-lite # Hardkernel Odroid XU3 Lite
- hardkernel,odroid-xu4 # Hardkernel Odroid XU4
- hardkernel,odroid-hc1 # Hardkernel Odroid HC1
+ - samsung,k3g # Samsung Galaxy S5 (SM-G900H)
- const: samsung,exynos5800
- const: samsung,exynos5
@@ -201,6 +212,14 @@ properties:
- samsung,exynos7-espresso # Samsung Exynos7 Espresso
- const: samsung,exynos7
+ - description: Exynos7870 based boards
+ items:
+ - enum:
+ - samsung,a2corelte # Samsung Galaxy A2 Core
+ - samsung,j6lte # Samsung Galaxy J6
+ - samsung,on7xelte # Samsung Galaxy J7 Prime
+ - const: samsung,exynos7870
+
- description: Exynos7885 based boards
items:
- enum:
@@ -213,12 +232,39 @@ properties:
- winlink,e850-96 # WinLink E850-96
- const: samsung,exynos850
+ - description: Exynos8895 based boards
+ items:
+ - enum:
+ - samsung,dreamlte # Samsung Galaxy S8 (SM-G950F)
+ - const: samsung,exynos8895
+
+ - description: Exynos9810 based boards
+ items:
+ - enum:
+ - samsung,starlte # Samsung Galaxy S9 (SM-G960F)
+ - const: samsung,exynos9810
+
+ - description: Exynos990 based boards
+ items:
+ - enum:
+ - samsung,c1s # Samsung Galaxy Note20 5G (SM-N981B)
+ - samsung,r8s # Samsung Galaxy S20 FE (SM-G780F)
+ - samsung,x1s # Samsung Galaxy S20 5G (SM-G981B)
+ - samsung,x1slte # Samsung Galaxy S20 (SM-G980F)
+ - const: samsung,exynos990
+
- description: Exynos Auto v9 based boards
items:
- enum:
- samsung,exynosautov9-sadk # Samsung Exynos Auto v9 SADK
- const: samsung,exynosautov9
+ - description: Exynos Auto v920 based boards
+ items:
+ - enum:
+ - samsung,exynosautov920-sadk # Samsung Exynos Auto v920 SADK
+ - const: samsung,exynosautov920
+
required:
- compatible
diff --git a/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml b/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml
index aa1d4afbc510..5a428a885760 100644
--- a/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml
+++ b/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/socionext/milbeaut.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Milbeaut platforms device tree bindings
+title: Milbeaut platforms
maintainers:
- Taichi Sugaya <sugaya.taichi@socionext.com>
diff --git a/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
new file mode 100644
index 000000000000..72554a4f1c92
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext/synquacer.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/socionext/synquacer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext Synquacer platform
+
+maintainers:
+ - Masahisa Kojima <masahisa.kojima@linaro.org>
+ - Jassi Brar <jaswinder.singh@linaro.org>
+
+description:
+ Socionext SC2A11B (Synquacer) SoC based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - socionext,developer-box
+ - const: socionext,synquacer
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
index 8c0e91658474..3e7f3d927ec7 100644
--- a/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
+++ b/Documentation/devicetree/bindings/arm/socionext/uniphier.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/socionext/uniphier.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Socionext UniPhier platform device tree bindings
+title: Socionext UniPhier platform
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
@@ -26,6 +26,12 @@ properties:
- socionext,uniphier-pro4-ref
- socionext,uniphier-pro4-sanji
- const: socionext,uniphier-pro4
+ - description: Pro5 SoC boards
+ items:
+ - enum:
+ - socionext,uniphier-pro5-epcore
+ - socionext,uniphier-pro5-proex
+ - const: socionext,uniphier-pro5
- description: sLD8 SoC boards
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/sp810.yaml b/Documentation/devicetree/bindings/arm/sp810.yaml
index bc8e524aa90a..c9094e5ec565 100644
--- a/Documentation/devicetree/bindings/arm/sp810.yaml
+++ b/Documentation/devicetree/bindings/arm/sp810.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/sp810.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Versatile Express SP810 System Controller bindings
+title: ARM Versatile Express SP810 System Controller
maintainers:
- Andre Przywara <andre.przywara@arm.com>
diff --git a/Documentation/devicetree/bindings/arm/spear-misc.txt b/Documentation/devicetree/bindings/arm/spear-misc.txt
deleted file mode 100644
index e404e2556b4a..000000000000
--- a/Documentation/devicetree/bindings/arm/spear-misc.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-SPEAr Misc configuration
-===========================
-SPEAr SOCs have some miscellaneous registers which are used to configure
-few properties of different peripheral controllers.
-
-misc node required properties:
-
-- compatible Should be "st,spear1340-misc", "syscon".
-- reg: Address range of misc space up to 8K
diff --git a/Documentation/devicetree/bindings/arm/spear.yaml b/Documentation/devicetree/bindings/arm/spear.yaml
index 605ad3f882ef..a465c9eca76e 100644
--- a/Documentation/devicetree/bindings/arm/spear.yaml
+++ b/Documentation/devicetree/bindings/arm/spear.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/spear.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ST SPEAr Platforms Device Tree Bindings
+title: ST SPEAr Platforms
maintainers:
- Viresh Kumar <vireshk@kernel.org>
diff --git a/Documentation/devicetree/bindings/arm/sprd/sprd.yaml b/Documentation/devicetree/bindings/arm/sprd/sprd.yaml
index 2c12e571394b..40fc3c8b9dce 100644
--- a/Documentation/devicetree/bindings/arm/sprd/sprd.yaml
+++ b/Documentation/devicetree/bindings/arm/sprd/sprd.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/arm/sprd/sprd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Unisoc platforms device tree bindings
+title: Unisoc platforms
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
@@ -35,6 +35,11 @@ properties:
- sprd,ums512-1h10
- const: sprd,ums512
+ - items:
+ - enum:
+ - sprd,ums9620-2h10
+ - const: sprd,ums9620
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/sti.yaml b/Documentation/devicetree/bindings/arm/sti.yaml
index a41cd8764885..177358895fe1 100644
--- a/Documentation/devicetree/bindings/arm/sti.yaml
+++ b/Documentation/devicetree/bindings/arm/sti.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sti.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ST STi Platforms Device Tree Bindings
+title: ST STi Platforms
maintainers:
- Patrice Chotard <patrice.chotard@foss.st.com>
@@ -13,13 +13,16 @@ properties:
$nodename:
const: '/'
compatible:
- items:
- - enum:
- - st,stih415
- - st,stih416
- - st,stih407
- - st,stih410
- - st,stih418
+ oneOf:
+ - items:
+ - enum:
+ - st,stih410-b2260
+ - const: st,stih410
+ - items:
+ - enum:
+ - st,stih418-b2199
+ - st,stih418-b2264
+ - const: st,stih418
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
index ecb28e90fd11..4970b9167d1c 100644
--- a/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 ML-AHB interconnect bindings
+title: STMicroelectronics STM32 ML-AHB interconnect
maintainers:
- Fabien Dessenne <fabien.dessenne@foss.st.com>
@@ -54,19 +54,18 @@ unevaluatedProperties: false
examples:
- |
- mlahb: ahb@38000000 {
- compatible = "st,mlahb", "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x10000000 0x40000>;
- ranges;
- dma-ranges = <0x00000000 0x38000000 0x10000>,
- <0x10000000 0x10000000 0x60000>,
- <0x30000000 0x30000000 0x60000>;
+ ahb {
+ compatible = "st,mlahb", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ dma-ranges = <0x00000000 0x38000000 0x10000>,
+ <0x10000000 0x10000000 0x60000>,
+ <0x30000000 0x30000000 0x60000>;
- m4_rproc: m4@10000000 {
- reg = <0x10000000 0x40000>;
- };
+ m4_rproc: m4@10000000 {
+ reg = <0x10000000 0x40000>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
index 6f846d69c5e1..95d2319afe23 100644
--- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Platforms System Controller bindings
+title: STMicroelectronics STM32 Platforms System Controller
maintainers:
- Alexandre Torgue <alexandre.torgue@foss.st.com>
@@ -15,11 +15,15 @@ properties:
oneOf:
- items:
- enum:
- - st,stm32mp157-syscfg
- - st,stm32mp151-pwr-mcu
- - st,stm32-syscfg
- st,stm32-power-config
+ - st,stm32-syscfg
- st,stm32-tamp
+ - st,stm32f4-gcan
+ - st,stm32mp151-pwr-mcu
+ - st,stm32mp157-syscfg
+ - st,stm32mp21-syscfg
+ - st,stm32mp23-syscfg
+ - st,stm32mp25-syscfg
- const: syscon
- items:
- const: st,stm32-tamp
@@ -32,19 +36,31 @@ properties:
clocks:
maxItems: 1
+ "#clock-cells":
+ const: 0
+
required:
- compatible
- reg
-if:
- properties:
- compatible:
- contains:
- enum:
- - st,stm32mp157-syscfg
-then:
- required:
- - clocks
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp157-syscfg
+ - st,stm32f4-gcan
+ then:
+ required:
+ - clocks
+ - if:
+ properties:
+ compatible:
+ const: st,stm32mp25-syscfg
+ then:
+ required:
+ - "#clock-cells"
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index 4c605bccc474..ad144c02eb7e 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/stm32/stm32.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Platforms Device Tree Bindings
+title: STMicroelectronics STM32 Platforms
maintainers:
- Alexandre Torgue <alexandre.torgue@foss.st.com>
@@ -44,6 +44,10 @@ properties:
- const: st,stm32h743
- items:
- enum:
+ - st,stm32h747i-disco
+ - const: st,stm32h747
+ - items:
+ - enum:
- st,stm32h750i-art-pi
- const: st,stm32h750
- items:
@@ -51,14 +55,41 @@ properties:
- st,stm32mp135f-dk
- const: st,stm32mp135
+ - description: ST STM32MP133 based Boards
+ items:
+ - enum:
+ - pri,prihmb # Priva E-Measuringbox board
+ - const: st,stm32mp133
+
- description: ST STM32MP151 based Boards
items:
- enum:
+ - ply,plyaqm # Plymovent AQM board
+ - prt,mecio1r0 # Protonic MECIO1r0
+ - prt,mect1s # Protonic MECT1S
- prt,prtt1a # Protonic PRTT1A
- prt,prtt1c # Protonic PRTT1C
- prt,prtt1s # Protonic PRTT1S
- const: st,stm32mp151
+ - description: DH STM32MP135 DHCOR SoM based Boards
+ items:
+ - const: dh,stm32mp135f-dhcor-dhsbc
+ - const: dh,stm32mp135f-dhcor-som
+ - const: st,stm32mp135
+
+ - description: DH STM32MP151 DHCOR SoM based Boards
+ items:
+ - const: dh,stm32mp151a-dhcor-testbench
+ - const: dh,stm32mp151a-dhcor-som
+ - const: st,stm32mp151
+
+ - description: ST STM32MP153 based Boards
+ items:
+ - enum:
+ - prt,mecio1r1 # Protonic MECIO1r1
+ - const: st,stm32mp153
+
- description: DH STM32MP153 DHCOM SoM based Boards
items:
- const: dh,stm32mp153c-dhcom-drc02
@@ -71,34 +102,34 @@ properties:
- const: dh,stm32mp153c-dhcor-som
- const: st,stm32mp153
+ - description: Octavo OSD32MP153 System-in-Package based boards
+ items:
+ - enum:
+ - lxa,stm32mp153c-fairytux2-gen1 # Linux Automation FairyTux 2 (Generation 1)
+ - lxa,stm32mp153c-fairytux2-gen2 # Linux Automation FairyTux 2 (Generation 2)
+ - lxa,stm32mp153c-tac-gen3 # Linux Automation TAC (Generation 3)
+ - const: oct,stm32mp153x-osd32
+ - const: st,stm32mp153
+
- items:
- enum:
- shiratech,stm32mp157a-iot-box # IoT Box
- shiratech,stm32mp157a-stinger96 # Stinger96
- st,stm32mp157c-ed1
+ - st,stm32mp157c-ed1-scmi
- st,stm32mp157a-dk1
+ - st,stm32mp157a-dk1-scmi
- st,stm32mp157c-dk2
+ - st,stm32mp157c-dk2-scmi
+ - st,stm32mp157f-dk2
- const: st,stm32mp157
- items:
- - const: st,stm32mp157a-dk1-scmi
- - const: st,stm32mp157a-dk1
- - const: st,stm32mp157
- - items:
- - const: st,stm32mp157c-dk2-scmi
- - const: st,stm32mp157c-dk2
- - const: st,stm32mp157
- - items:
- - const: st,stm32mp157c-ed1-scmi
- - const: st,stm32mp157c-ed1
- - const: st,stm32mp157
- - items:
- const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
- items:
- const: st,stm32mp157c-ev1-scmi
- - const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
@@ -137,7 +168,10 @@ properties:
- description: Octavo OSD32MP15x System-in-Package based boards
items:
- enum:
- - lxa,stm32mp157c-mc1 # Linux Automation MC-1
+ - lxa,stm32mp157c-mc1 # Linux Automation MC-1
+ - lxa,stm32mp157c-tac-gen1 # Linux Automation TAC (Generation 1)
+ - lxa,stm32mp157c-tac-gen2 # Linux Automation TAC (Generation 2)
+ - oct,stm32mp157c-osd32-red # Octavo OSD32MP1 RED board
- const: oct,stm32mp15xx-osd32
- enum:
- st,stm32mp157
@@ -149,6 +183,36 @@ properties:
- const: seeed,stm32mp157c-odyssey-som
- const: st,stm32mp157
+ - description: Phytec STM32MP1 SoM based Boards
+ items:
+ - const: phytec,phycore-stm32mp1-3
+ - const: phytec,phycore-stm32mp157c-som
+ - const: st,stm32mp157
+
+ - description: Ultratronik STM32MP1 SBC based Boards
+ items:
+ - const: ultratronik,stm32mp157c-ultra-fly-sbc
+ - const: st,stm32mp157
+
+ - description: ST STM32MP257 based Boards
+ items:
+ - enum:
+ - st,stm32mp257f-dk
+ - st,stm32mp257f-ev1
+ - const: st,stm32mp257
+
+ - description: ST STM32MP235 based Boards
+ items:
+ - enum:
+ - st,stm32mp235f-dk
+ - const: st,stm32mp235
+
+ - description: ST STM32MP215 based Boards
+ items:
+ - enum:
+ - st,stm32mp215f-dk
+ - const: st,stm32mp215
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 0c2356778208..9e4627f97d7e 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/sunxi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner platforms device tree bindings
+title: Allwinner platforms
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -51,6 +51,31 @@ properties:
- const: allwinner,parrot
- const: allwinner,sun8i-a33
+ - description: Anbernic RG-Nano
+ items:
+ - const: anbernic,rg-nano
+ - const: allwinner,sun8i-v3s
+
+ - description: Anbernic RG35XX (2024)
+ items:
+ - const: anbernic,rg35xx-2024
+ - const: allwinner,sun50i-h700
+
+ - description: Anbernic RG35XX H
+ items:
+ - const: anbernic,rg35xx-h
+ - const: allwinner,sun50i-h700
+
+ - description: Anbernic RG35XX Plus
+ items:
+ - const: anbernic,rg35xx-plus
+ - const: allwinner,sun50i-h700
+
+ - description: Anbernic RG35XX SP
+ items:
+ - const: anbernic,rg35xx-sp
+ - const: allwinner,sun50i-h700
+
- description: Amarula A64 Relic
items:
- const: amarula,a64-relic
@@ -151,6 +176,17 @@ properties:
- const: roofull,beelink-x2
- const: allwinner,sun8i-h3
+ - description: BigTreeTech Manta M4/8P
+ items:
+ - const: bigtreetech,cb1-manta
+ - const: bigtreetech,cb1
+ - const: allwinner,sun50i-h616
+
+ - description: BigTreeTech Pi
+ items:
+ - const: bigtreetech,pi
+ - const: allwinner,sun50i-h616
+
- description: Chuwi V7 CW0825
items:
- const: chuwi,v7-cw0825
@@ -305,9 +341,11 @@ properties:
- const: allwinner,i12-tvbox
- const: allwinner,sun7i-a20
- - description: ICNova A20 SWAC
+ - description: ICnova A20
items:
- - const: incircuit,icnova-a20-swac
+ - enum:
+ - incircuit,icnova-a20-adb4006
+ - incircuit,icnova-a20-swac
- const: incircuit,icnova-a20
- const: allwinner,sun7i-a20
@@ -366,6 +404,12 @@ properties:
- const: lamobo,lamobo-r1
- const: allwinner,sun7i-a20
+ - description: Lctech Pi F1C200s
+ items:
+ - const: lctech,pi-f1c200s
+ - const: allwinner,suniv-f1c200s
+ - const: allwinner,suniv-f1c100s
+
- description: Libre Computer Board ALL-H3-CC H2+
items:
- const: libretech,all-h3-cc-h2-plus
@@ -444,6 +488,11 @@ properties:
- const: lamobo,lamobo-r1
- const: allwinner,sun7i-a20
+ - description: Liontron H-A133L
+ items:
+ - const: liontron,h-a133l
+ - const: allwinner,sun50i-a100
+
- description: HAOYU Electronics Marsboard A10
items:
- const: haoyu,a10-marsboard
@@ -529,18 +578,31 @@ properties:
- const: msi,primo81
- const: allwinner,sun6i-a31s
- - description: Emlid Neutis N5 Developper Board
+ - description: Emlid Neutis N5 Developer Board
items:
- const: emlid,neutis-n5-devboard
- const: emlid,neutis-n5
- const: allwinner,sun50i-h5
- - description: Emlid Neutis N5H3 Developper Board
+ - description: Emlid Neutis N5H3 Developer Board
items:
- const: emlid,neutis-n5h3-devboard
- const: emlid,neutis-n5h3
- const: allwinner,sun8i-h3
+ - description: NetCube Systems Kumquat
+ items:
+ - const: netcube,kumquat
+ - const: allwinner,sun8i-v3s
+
+ - description: NetCube Systems Nagami SoM based boards
+ items:
+ - enum:
+ - netcube,nagami-basic-carrier
+ - netcube,nagami-keypad-carrier
+ - const: netcube,nagami
+ - const: allwinner,sun8i-t113s
+
- description: NextThing Co. CHIP
items:
- const: nextthing,chip
@@ -665,12 +727,12 @@ properties:
- const: olimex,a64-teres-i
- const: allwinner,sun50i-a64
- - description: Pine64
+ - description: Pine64 PINE A64
items:
- const: pine64,pine64
- const: allwinner,sun50i-a64
- - description: Pine64+
+ - description: Pine64 PINE A64+
items:
- const: pine64,pine64-plus
- const: allwinner,sun50i-a64
@@ -681,17 +743,17 @@ properties:
- const: sochip,s3
- const: allwinner,sun8i-v3
- - description: Pine64 PineH64 model A
+ - description: Pine64 PINE H64 Model A
items:
- const: pine64,pine-h64
- const: allwinner,sun50i-h6
- - description: Pine64 PineH64 model B
+ - description: Pine64 PINE H64 Model B
items:
- const: pine64,pine-h64-model-b
- const: allwinner,sun50i-h6
- - description: Pine64 LTS
+ - description: Pine64 PINE A64 LTS
items:
- const: pine64,pine64-lts
- const: allwinner,sun50i-r18
@@ -702,35 +764,26 @@ properties:
- const: pine64,pinebook
- const: allwinner,sun50i-a64
- - description: Pine64 PinePhone Developer Batch (1.0)
+ - description: Pine64 PinePhone
items:
- - const: pine64,pinephone-1.0
+ - enum:
+ - pine64,pinephone-1.0 # Developer Batch (1.0)
+ - pine64,pinephone-1.1 # Braveheart (1.1)
+ - pine64,pinephone-1.2
- const: pine64,pinephone
- const: allwinner,sun50i-a64
- - description: Pine64 PinePhone Braveheart (1.1)
- items:
- - const: pine64,pinephone-1.1
- - const: pine64,pinephone
- - const: allwinner,sun50i-a64
-
- - description: Pine64 PinePhone (1.2)
- items:
- - const: pine64,pinephone-1.2
- - const: pine64,pinephone
- - const: allwinner,sun50i-a64
-
- - description: Pine64 PineTab, Development Sample
+ - description: Pine64 PineTab Developer Sample
items:
- const: pine64,pinetab
- const: allwinner,sun50i-a64
- - description: Pine64 PineTab, Early Adopter's batch (and maybe later ones)
+ - description: Pine64 PineTab Early Adopter
items:
- const: pine64,pinetab-early-adopter
- const: allwinner,sun50i-a64
- - description: Pine64 SoPine Baseboard
+ - description: Pine64 SOPINE
items:
- const: pine64,sopine-baseboard
- const: pine64,sopine
@@ -746,6 +799,11 @@ properties:
- const: pocketbook,touch-lux-3
- const: allwinner,sun5i-a13
+ - description: PocketBook 614 Plus
+ items:
+ - const: pocketbook,614-plus
+ - const: allwinner,sun5i-a13
+
- description: Point of View Protab2-IPS9
items:
- const: pov,protab2-ips9
@@ -787,6 +845,23 @@ properties:
- const: allwinner,r7-tv-dongle
- const: allwinner,sun5i-a10s
+ - description: Radxa Cubie A5E
+ items:
+ - const: radxa,cubie-a5e
+ - const: allwinner,sun55i-a527
+
+ - description: Remix Mini PC
+ items:
+ - const: jide,remix-mini-pc
+ - const: allwinner,sun50i-h64
+ - const: allwinner,sun50i-a64
+
+ - description: RerVision A33-Vstar (with A33-Core1 SoM)
+ items:
+ - const: rervision,a33-vstar
+ - const: rervision,a33-core1
+ - const: allwinner,sun8i-a33
+
- description: RerVision H3-DVK
items:
- const: rervision,h3-dvk
@@ -807,12 +882,30 @@ properties:
- const: sinlinx,sina33
- const: allwinner,sun8i-a33
+ - description: Sipeed Longan Pi 3H board for the Sipeed Longan Module 3H
+ items:
+ - const: sipeed,longan-pi-3h
+ - const: sipeed,longan-module-3h
+ - const: allwinner,sun50i-h618
+
+ - description: SourceParts PopStick v1.1
+ items:
+ - const: sourceparts,popstick-v1.1
+ - const: sourceparts,popstick
+ - const: allwinner,suniv-f1c200s
+ - const: allwinner,suniv-f1c100s
+
- description: SL631 Action Camera with IMX179
items:
- const: allwinner,sl631-imx179
- const: allwinner,sl631
- const: allwinner,sun8i-v3
+ - description: Tanix TX1
+ items:
+ - const: oranth,tanix-tx1
+ - const: allwinner,sun50i-h616
+
- description: Tanix TX6
items:
- const: oranth,tanix-tx6
@@ -833,6 +926,11 @@ properties:
- const: topwise,a721
- const: allwinner,sun4i-a10
+ - description: Transpeed 8K618-T
+ items:
+ - const: transpeed,8k618-t
+ - const: allwinner,sun50i-h618
+
- description: Utoo P66
items:
- const: utoo,p66
@@ -843,6 +941,11 @@ properties:
- const: wexler,tab7200
- const: allwinner,sun7i-a20
+ - description: MangoPi MQ-R board
+ items:
+ - const: widora,mangopi-mq-r-t113
+ - const: allwinner,sun8i-t113s
+
- description: WITS A31 Colombus Evaluation Board
items:
- const: wits,colombus
@@ -868,6 +971,16 @@ properties:
- const: hechuang,x96-mate
- const: allwinner,sun50i-h616
+ - description: X96Q
+ items:
+ - const: amediatech,x96q
+ - const: allwinner,sun50i-h616
+
+ - description: X96Q Pro+
+ items:
+ - const: amediatech,x96q-pro-plus
+ - const: allwinner,sun55i-h728
+
- description: Xunlong OrangePi
items:
- const: xunlong,orangepi
@@ -883,6 +996,11 @@ properties:
- const: xunlong,orangepi-3
- const: allwinner,sun50i-h6
+ - description: Xunlong OrangePi 4A
+ items:
+ - const: xunlong,orangepi-4a
+ - const: allwinner,sun55i-t527
+
- description: Xunlong OrangePi Lite
items:
- const: xunlong,orangepi-lite
@@ -973,4 +1091,24 @@ properties:
- const: xunlong,orangepi-zero2
- const: allwinner,sun50i-h616
+ - description: Xunlong OrangePi Zero 2W
+ items:
+ - const: xunlong,orangepi-zero2w
+ - const: allwinner,sun50i-h618
+
+ - description: Xunlong OrangePi Zero 3
+ items:
+ - const: xunlong,orangepi-zero3
+ - const: allwinner,sun50i-h618
+
+ - description: YuzukiHD Avaota A1
+ items:
+ - const: yuzukihd,avaota-a1
+ - const: allwinner,sun55i-t527
+
+ - description: YuzukiHD Chameleon
+ items:
+ - const: yuzukihd,chameleon
+ - const: allwinner,sun50i-h618
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
index f3878e0b3cc4..d805c4508b4e 100644
--- a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner CPU Configuration Controller Device Tree Bindings
+title: Allwinner CPU Configuration Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
index 668aadbfe4c0..644f391afb32 100644
--- a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun9i-a80-prcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 PRCM Device Tree Bindings
+title: Allwinner A80 PRCM
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/arm/swir.txt b/Documentation/devicetree/bindings/arm/swir.txt
deleted file mode 100644
index 042be73a95d3..000000000000
--- a/Documentation/devicetree/bindings/arm/swir.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Sierra Wireless Modules device tree bindings
---------------------------------------------
-
-Supported Modules :
- - WP8548 : Includes MDM9615 and PM8018 in a module
-
-Sierra Wireless modules shall have the following properties :
- Required root node property
- - compatible: "swir,wp8548" for the WP8548 CF3 Module
-
-Board compatible values:
- - "swir,mangoh-green-wp8548" for the mangOH green board with the WP8548 module
diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt
deleted file mode 100644
index 851f48ead927..000000000000
--- a/Documentation/devicetree/bindings/arm/syna.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-Synaptics SoC Device Tree Bindings
-
-According to https://www.synaptics.com/company/news/conexant-marvell
-Synaptics has acquired the Multimedia Solutions Business of Marvell, so
-berlin SoCs are now Synaptics' SoCs now.
-
----------------------------------------------------------------
-
-Work in progress statement:
-
-Device tree files and bindings applying to Marvell Berlin SoCs and boards are
-considered "unstable". Any Marvell Berlin device tree binding may change at any
-time. Be sure to use a device tree binary and a kernel image generated from the
-same source tree.
-
-Please refer to Documentation/devicetree/bindings/ABI.rst for a definition of a
-stable binding/ABI.
-
----------------------------------------------------------------
-
-Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
-shall have the following properties:
-
-* Required root node properties:
-compatible: must contain "marvell,berlin"
-
-In addition, the above compatible shall be extended with the specific
-SoC and board used. Currently known SoC compatibles are:
- "marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100),
- "marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005)
- "marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????)
- "marvell,berlin2q" for Marvell Armada 1500-pro (BG2Q, 88DE3114)
- "marvell,berlin3" for Marvell Armada ? (BG3, 88DE????)
-
-* Example:
-
-/ {
- model = "Sony NSZ-GS7";
- compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
-
- ...
-}
-
-* Marvell Berlin CPU control bindings
-
-CPU control register allows various operations on CPUs, like resetting them
-independently.
-
-Required properties:
-- compatible: should be "marvell,berlin-cpu-ctrl"
-- reg: address and length of the register set
-
-Example:
-
-cpu-ctrl@f7dd0000 {
- compatible = "marvell,berlin-cpu-ctrl";
- reg = <0xf7dd0000 0x10000>;
-};
-
-* Marvell Berlin2 chip control binding
-
-Marvell Berlin SoCs have a chip control register set providing several
-individual registers dealing with pinmux, padmux, clock, reset, and secondary
-CPU boot address. Unfortunately, the individual registers are spread among the
-chip control registers, so there should be a single DT node only providing the
-different functions which are described below.
-
-Required properties:
-- compatible:
- * the first and second values must be:
- "simple-mfd", "syscon"
-- reg: address and length of following register sets for
- BG2/BG2CD: chip control register set
- BG2Q: chip control register set and cpu pll registers
-
-* Marvell Berlin2 system control binding
-
-Marvell Berlin SoCs have a system control register set providing several
-individual registers dealing with pinmux, padmux, and reset.
-
-Required properties:
-- compatible:
- * the first and second values must be:
- "simple-mfd", "syscon"
-- reg: address and length of the system control register set
-
-Example:
-
-chip: chip-control@ea0000 {
- compatible = "simple-mfd", "syscon";
- reg = <0xea0000 0x400>;
-
- /* sub-device nodes */
-};
-
-sysctrl: system-controller@d000 {
- compatible = "simple-mfd", "syscon";
- reg = <0xd000 0x100>;
-
- /* sub-device nodes */
-};
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 49841ca272ee..50a31dba7bec 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/tegra.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra device tree bindings
+title: NVIDIA Tegra
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
@@ -36,8 +36,12 @@ properties:
- toradex,colibri_t20-iris
- const: toradex,colibri_t20
- const: nvidia,tegra20
- - items:
- - const: asus,tf101
+ - description: ASUS Transformers T20 Device family
+ items:
+ - enum:
+ - asus,sl101
+ - asus,tf101
+ - asus,tf101g
- const: nvidia,tegra20
- items:
- const: acer,picasso
@@ -52,17 +56,30 @@ properties:
- nvidia,cardhu-a04
- const: nvidia,cardhu
- const: nvidia,tegra30
- - items:
- - const: asus,tf201
+ - description: ASUS Portable AiO P1801-T
+ items:
+ - const: asus,p1801-t
- const: nvidia,tegra30
- - items:
- - const: asus,tf300t
+ - description: ASUS Transformers Device family
+ items:
+ - enum:
+ - asus,tf201
+ - asus,tf300t
+ - asus,tf300tg
+ - asus,tf300tl
+ - asus,tf700t
- const: nvidia,tegra30
- - items:
- - const: asus,tf300tg
+ - description: Asus VivoTab RT
+ items:
+ - const: asus,tf600t
- const: nvidia,tegra30
- - items:
- - const: asus,tf700t
+ - description: LG Optimus 4X P880
+ items:
+ - const: lg,p880
+ - const: nvidia,tegra30
+ - description: LG Optimus Vu P895
+ items:
+ - const: lg,p895
- const: nvidia,tegra30
- items:
- const: toradex,apalis_t30-eval
@@ -120,12 +137,63 @@ properties:
- const: nvidia,tegra132
- const: nvidia,tegra124
- items:
+ - const: google,nyan-blaze-rev10
+ - const: google,nyan-blaze-rev9
+ - const: google,nyan-blaze-rev8
+ - const: google,nyan-blaze-rev7
+ - const: google,nyan-blaze-rev6
+ - const: google,nyan-blaze-rev5
+ - const: google,nyan-blaze-rev4
+ - const: google,nyan-blaze-rev3
+ - const: google,nyan-blaze-rev2
+ - const: google,nyan-blaze-rev1
+ - const: google,nyan-blaze-rev0
+ - const: google,nyan-blaze
+ - const: google,nyan
+ - const: nvidia,tegra124
+ - items:
+ - const: google,nyan-big-rev10
+ - const: google,nyan-big-rev9
+ - const: google,nyan-big-rev8
+ - const: google,nyan-big-rev7
+ - const: google,nyan-big-rev6
+ - const: google,nyan-big-rev5
+ - const: google,nyan-big-rev4
+ - const: google,nyan-big-rev3
+ - const: google,nyan-big-rev2
+ - const: google,nyan-big-rev1
+ - const: google,nyan-big-rev0
+ - const: google,nyan-big
+ - const: google,nyan
+ - const: nvidia,tegra124
+ - items:
+ - const: google,nyan-big-rev7
+ - const: google,nyan-big-rev6
+ - const: google,nyan-big-rev5
+ - const: google,nyan-big-rev4
+ - const: google,nyan-big-rev3
+ - const: google,nyan-big-rev2
+ - const: google,nyan-big-rev1
+ - const: google,nyan-big-rev0
+ - const: google,nyan-big
+ - const: google,nyan
+ - const: nvidia,tegra124
+ - description: Xiaomi Mi Pad (A0101)
+ items:
+ - const: xiaomi,mocha
+ - const: nvidia,tegra124
+ - items:
- enum:
- nvidia,darcy
- nvidia,p2371-0000
- nvidia,p2371-2180
- nvidia,p2571
- nvidia,p2894-0050-a08
+ - nvidia,p3450-0000
+ - const: nvidia,tegra210
+ - items:
+ - const: nvidia,p3541-0000
+ - const: nvidia,p3450-0000
- const: nvidia,tegra210
- description: Jetson TX2 Developer Kit
items:
@@ -167,5 +235,38 @@ properties:
- const: nvidia,p3737-0000+p3701-0000
- const: nvidia,p3701-0000
- const: nvidia,tegra234
+ - description: Jetson AGX Orin Developer Kit with Industrial Module
+ items:
+ - const: nvidia,p3737-0000+p3701-0008
+ - const: nvidia,p3701-0008
+ - const: nvidia,tegra234
+ - description: NVIDIA IGX Orin Development Kit
+ items:
+ - const: nvidia,p3740-0002+p3701-0008
+ - const: nvidia,p3701-0008
+ - const: nvidia,tegra234
+ - description: Jetson Orin NX
+ items:
+ - const: nvidia,p3767-0000
+ - const: nvidia,tegra234
+ - description: Jetson Orin NX Engineering Reference Developer Kit
+ items:
+ - const: nvidia,p3768-0000+p3767-0000
+ - const: nvidia,p3767-0000
+ - const: nvidia,tegra234
+ - description: Jetson Orin Nano
+ items:
+ - const: nvidia,p3767-0005
+ - const: nvidia,tegra234
+ - description: Jetson Orin Nano Developer Kit
+ items:
+ - const: nvidia,p3768-0000+p3767-0005
+ - const: nvidia,p3767-0005
+ - const: nvidia,tegra234
+ - description: NVIDIA P3971-0089+P3834-0008 Engineering Reference Platform
+ items:
+ - const: nvidia,p3971-0089+p3834-0008
+ - const: nvidia,p3834-0008
+ - const: nvidia,tegra264
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt
deleted file mode 100644
index 5ae601e7f51f..000000000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-NVIDIA compliant embedded controller
-
-Required properties:
-- compatible : should be "nvidia,nvec".
-- reg : the iomem of the i2c slave controller
-- interrupts : the interrupt line of the i2c slave controller
-- clock-frequency : the frequency of the i2c bus
-- gpios : the gpio used for ec request
-- slave-addr: the i2c address of the slave controller
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- Tegra20/Tegra30:
- - div-clk
- - fast-clk
- Tegra114:
- - div-clk
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - i2c
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
index 711bb4d08c60..36dbd0838f2d 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra CPU COMPLEX CLUSTER area device tree bindings
+title: NVIDIA Tegra CPU COMPLEX CLUSTER area
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
@@ -29,7 +29,7 @@ properties:
maxItems: 1
nvidia,bpmp:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Specifies the BPMP node that needs to be queried to get
operating point data for all CPUs.
@@ -47,5 +47,4 @@ examples:
compatible = "nvidia,tegra234-ccplex-cluster";
reg = <0x0e000000 0x5ffff>;
nvidia,bpmp = <&bpmp>;
- status = "okay";
};
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml
index 0faa403f68c8..be70819020c5 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml
@@ -16,6 +16,7 @@ properties:
- nvidia,tegra186-pmc
- nvidia,tegra194-pmc
- nvidia,tegra234-pmc
+ - nvidia,tegra264-pmc
reg:
minItems: 4
@@ -27,7 +28,7 @@ properties:
- const: pmc
- const: wake
- const: aotag
- - const: scratch
+ - enum: [ scratch, misc ]
- const: misc
interrupt-controller: true
@@ -41,25 +42,43 @@ properties:
description: If present, inverts the PMU interrupt signal.
$ref: /schemas/types.yaml#/definitions/flag
-if:
- properties:
- compatible:
- contains:
- const: nvidia,tegra186-pmc
-then:
- properties:
- reg:
- maxItems: 4
-
- reg-names:
- maxItems: 4
-else:
- properties:
- reg:
- minItems: 5
-
- reg-names:
- minItems: 5
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-pmc
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ reg-names:
+ maxItems: 4
+ contains:
+ const: scratch
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra194-pmc
+ then:
+ properties:
+ reg:
+ minItems: 5
+ reg-names:
+ minItems: 5
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra234-pmc
+ then:
+ properties:
+ reg-names:
+ contains:
+ const: misc
patternProperties:
"^[a-z0-9]+-[a-z0-9]+$":
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml
index 788a13f8aa93..5e0f1dc542b0 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra194 AXI2APB bridge
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml
index debb2b0c8013..d9c54c32c6b9 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra194 CBB 1.0 bindings
+title: NVIDIA Tegra194 CBB 1.0
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
@@ -64,13 +64,13 @@ properties:
- description: secure interrupt
nvidia,axi2apb:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Specifies the node having all axi2apb bridges which need to be checked
for any error logged in their status register.
nvidia,apbmisc:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Specifies the apbmisc node which need to be used for reading the ERD
register.
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
deleted file mode 100644
index 9a4295b54539..000000000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-NVIDIA Tegra AHB
-
-Required properties:
-- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For
- Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain
- '"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124,
- tegra132, or tegra210.
-- reg : Should contain 1 register ranges(address and length). For
- Tegra20, Tegra30, and Tegra114 chips, the value must be <0x6000c004
- 0x10c>. For Tegra124, Tegra132 and Tegra210 chips, the value should
- be be <0x6000c000 0x150>.
-
-Example (for a Tegra20 chip):
- ahb: ahb@6000c004 {
- compatible = "nvidia,tegra20-ahb";
- reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
- };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt
deleted file mode 100644
index a855c1bffc0f..000000000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-NVIDIA Tegra Flow Controller
-
-Required properties:
-- compatible: Should contain one of the following:
- - "nvidia,tegra20-flowctrl": for Tegra20
- - "nvidia,tegra30-flowctrl": for Tegra30
- - "nvidia,tegra114-flowctrl": for Tegra114
- - "nvidia,tegra124-flowctrl": for Tegra124
- - "nvidia,tegra132-flowctrl", "nvidia,tegra124-flowctrl": for Tegra132
- - "nvidia,tegra210-flowctrl": for Tegra210
-- reg: Should contain one register range (address and length)
-
-Example:
-
- flow-controller@60007000 {
- compatible = "nvidia,tegra20-flowctrl";
- reg = <0x60007000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
deleted file mode 100644
index 7fd8d47b1be4..000000000000
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
+++ /dev/null
@@ -1,389 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra20-pmc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Tegra Power Management Controller (PMC)
-
-maintainers:
- - Thierry Reding <thierry.reding@gmail.com>
- - Jonathan Hunter <jonathanh@nvidia.com>
-
-properties:
- compatible:
- enum:
- - nvidia,tegra20-pmc
- - nvidia,tegra30-pmc
- - nvidia,tegra114-pmc
- - nvidia,tegra124-pmc
- - nvidia,tegra210-pmc
-
- reg:
- maxItems: 1
- description:
- Offset and length of the register set for the device.
-
- clock-names:
- items:
- - const: pclk
- - const: clk32k_in
- description:
- Must includes entries pclk and clk32k_in.
- pclk is the Tegra clock of that name and clk32k_in is 32KHz clock
- input to Tegra.
-
- clocks:
- maxItems: 2
- description:
- Must contain an entry for each entry in clock-names.
- See ../clocks/clocks-bindings.txt for details.
-
- '#clock-cells':
- const: 1
- description:
- Tegra PMC has clk_out_1, clk_out_2, and clk_out_3.
- PMC also has blink control which allows 32Khz clock output to
- Tegra blink pad.
- Consumer of PMC clock should specify the desired clock by having
- the clock ID in its "clocks" phandle cell with pmc clock provider.
- See include/dt-bindings/soc/tegra-pmc.h for the list of Tegra PMC
- clock IDs.
-
- '#interrupt-cells':
- const: 2
- description:
- Specifies number of cells needed to encode an interrupt source.
- The value must be 2.
-
- interrupt-controller: true
-
- nvidia,invert-interrupt:
- $ref: /schemas/types.yaml#/definitions/flag
- description: Inverts the PMU interrupt signal.
- The PMU is an external Power Management Unit, whose interrupt output
- signal is fed into the PMC. This signal is optionally inverted, and
- then fed into the ARM GIC. The PMC is not involved in the detection
- or handling of this interrupt signal, merely its inversion.
-
- nvidia,core-power-req-active-high:
- $ref: /schemas/types.yaml#/definitions/flag
- description: Core power request active-high.
-
- nvidia,sys-clock-req-active-high:
- $ref: /schemas/types.yaml#/definitions/flag
- description: System clock request active-high.
-
- nvidia,combined-power-req:
- $ref: /schemas/types.yaml#/definitions/flag
- description: combined power request for CPU and Core.
-
- nvidia,cpu-pwr-good-en:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- CPU power good signal from external PMIC to PMC is enabled.
-
- nvidia,suspend-mode:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
- description:
- The suspend mode that the platform should use.
- Mode 0 is for LP0, CPU + Core voltage off and DRAM in self-refresh
- Mode 1 is for LP1, CPU voltage off and DRAM in self-refresh
- Mode 2 is for LP2, CPU voltage off
-
- nvidia,cpu-pwr-good-time:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: CPU power good time in uSec.
-
- nvidia,cpu-pwr-off-time:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: CPU power off time in uSec.
-
- nvidia,core-pwr-good-time:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description:
- <Oscillator-stable-time Power-stable-time>
- Core power good time in uSec.
-
- nvidia,core-pwr-off-time:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: Core power off time in uSec.
-
- nvidia,lp0-vec:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description:
- <start length> Starting address and length of LP0 vector.
- The LP0 vector contains the warm boot code that is executed
- by AVP when resuming from the LP0 state.
- The AVP (Audio-Video Processor) is an ARM7 processor and
- always being the first boot processor when chip is power on
- or resume from deep sleep mode. When the system is resumed
- from the deep sleep mode, the warm boot code will restore
- some PLLs, clocks and then brings up CPU0 for resuming the
- system.
-
- i2c-thermtrip:
- type: object
- description:
- On Tegra30, Tegra114 and Tegra124 if i2c-thermtrip subnode exists,
- hardware-triggered thermal reset will be enabled.
-
- properties:
- nvidia,i2c-controller-id:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- ID of I2C controller to send poweroff command to PMU.
- Valid values are described in section 9.2.148
- "APBDEV_PMC_SCRATCH53_0" of the Tegra K1 Technical Reference
- Manual.
-
- nvidia,bus-addr:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: Bus address of the PMU on the I2C bus.
-
- nvidia,reg-addr:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: PMU I2C register address to issue poweroff command.
-
- nvidia,reg-data:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: Poweroff command to write to PMU.
-
- nvidia,pinmux-id:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- Pinmux used by the hardware when issuing Poweroff command.
- Defaults to 0. Valid values are described in section 12.5.2
- "Pinmux Support" of the Tegra4 Technical Reference Manual.
-
- required:
- - nvidia,i2c-controller-id
- - nvidia,bus-addr
- - nvidia,reg-addr
- - nvidia,reg-data
-
- additionalProperties: false
-
- powergates:
- type: object
- description: |
- This node contains a hierarchy of power domain nodes, which should
- match the powergates on the Tegra SoC. Each powergate node
- represents a power-domain on the Tegra SoC that can be power-gated
- by the Tegra PMC.
- Hardware blocks belonging to a power domain should contain
- "power-domains" property that is a phandle pointing to corresponding
- powergate node.
- The name of the powergate node should be one of the below. Note that
- not every powergate is applicable to all Tegra devices and the following
- list shows which powergates are applicable to which devices.
- Please refer to Tegra TRM for mode details on the powergate nodes to
- use for each power-gate block inside Tegra.
- Name Description Devices Applicable
- 3d 3D Graphics Tegra20/114/124/210
- 3d0 3D Graphics 0 Tegra30
- 3d1 3D Graphics 1 Tegra30
- aud Audio Tegra210
- dfd Debug Tegra210
- dis Display A Tegra114/124/210
- disb Display B Tegra114/124/210
- heg 2D Graphics Tegra30/114/124/210
- iram Internal RAM Tegra124/210
- mpe MPEG Encode All
- nvdec NVIDIA Video Decode Engine Tegra210
- nvjpg NVIDIA JPEG Engine Tegra210
- pcie PCIE Tegra20/30/124/210
- sata SATA Tegra30/124/210
- sor Display interfaces Tegra124/210
- ve2 Video Encode Engine 2 Tegra210
- venc Video Encode Engine All
- vdec Video Decode Engine Tegra20/30/114/124
- vic Video Imaging Compositor Tegra124/210
- xusba USB Partition A Tegra114/124/210
- xusbb USB Partition B Tegra114/124/210
- xusbc USB Partition C Tegra114/124/210
-
- patternProperties:
- "^[a-z0-9]+$":
- type: object
-
- properties:
- clocks:
- minItems: 1
- maxItems: 8
- description:
- Must contain an entry for each clock required by the PMC
- for controlling a power-gate.
- See ../clocks/clock-bindings.txt document for more details.
-
- resets:
- minItems: 1
- maxItems: 8
- description:
- Must contain an entry for each reset required by the PMC
- for controlling a power-gate.
- See ../reset/reset.txt for more details.
-
- '#power-domain-cells':
- const: 0
- description: Must be 0.
-
- required:
- - clocks
- - resets
- - '#power-domain-cells'
-
- additionalProperties: false
-
-patternProperties:
- "^[a-f0-9]+-[a-f0-9]+$":
- type: object
- description:
- This is a Pad configuration node. On Tegra SOCs a pad is a set of
- pins which are configured as a group. The pin grouping is a fixed
- attribute of the hardware. The PMC can be used to set pad power state
- and signaling voltage. A pad can be either in active or power down mode.
- The support for power state and signaling voltage configuration varies
- depending on the pad in question. 3.3V and 1.8V signaling voltages
- are supported on pins where software controllable signaling voltage
- switching is available.
-
- The pad configuration state nodes are placed under the pmc node and they
- are referred to by the pinctrl client properties. For more information
- see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
- The pad name should be used as the value of the pins property in pin
- configuration nodes.
-
- The following pads are present on Tegra124 and Tegra132
- audio, bb, cam, comp, csia, csb, cse, dsi, dsib, dsic, dsid, hdmi, hsic,
- hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2, pex-cntrl,
- sdmmc1, sdmmc3, sdmmc4, sys_ddc, uart, usb0, usb1, usb2, usb_bias.
-
- The following pads are present on Tegra210
- audio, audio-hv, cam, csia, csib, csic, csid, csie, csif, dbg,
- debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2, gpio, hdmi,
- hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2, pex-cntrl, sdmmc1,
- sdmmc3, spi, spi-hv, uart, usb0, usb1, usb2, usb3, usb-bias.
-
- properties:
- pins:
- $ref: /schemas/types.yaml#/definitions/string
- description: Must contain name of the pad(s) to be configured.
-
- low-power-enable:
- $ref: /schemas/types.yaml#/definitions/flag
- description: Configure the pad into power down mode.
-
- low-power-disable:
- $ref: /schemas/types.yaml#/definitions/flag
- description: Configure the pad into active mode.
-
- power-source:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or
- TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages.
- The values are defined in
- include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h.
- Power state can be configured on all Tegra124 and Tegra132
- pads. None of the Tegra124 or Tegra132 pads support signaling
- voltage switching.
- All of the listed Tegra210 pads except pex-cntrl support power
- state configuration. Signaling voltage switching is supported
- on below Tegra210 pads.
- audio, audio-hv, cam, dbg, dmic, gpio, pex-cntrl, sdmmc1,
- sdmmc3, spi, spi-hv, and uart.
-
- required:
- - pins
-
- additionalProperties: false
-
- core-domain:
- type: object
- description: |
- The vast majority of hardware blocks of Tegra SoC belong to a
- Core power domain, which has a dedicated voltage rail that powers
- the blocks.
-
- properties:
- operating-points-v2:
- description:
- Should contain level, voltages and opp-supported-hw property.
- The supported-hw is a bitfield indicating SoC speedo or process
- ID mask.
-
- "#power-domain-cells":
- const: 0
-
- required:
- - operating-points-v2
- - "#power-domain-cells"
-
- additionalProperties: false
-
- core-supply:
- description:
- Phandle to voltage regulator connected to the SoC Core power rail.
-
-required:
- - compatible
- - reg
- - clock-names
- - clocks
- - '#clock-cells'
-
-additionalProperties: false
-
-dependencies:
- "nvidia,suspend-mode": ["nvidia,core-pwr-off-time", "nvidia,cpu-pwr-off-time"]
- "nvidia,core-pwr-off-time": ["nvidia,core-pwr-good-time"]
- "nvidia,cpu-pwr-off-time": ["nvidia,cpu-pwr-good-time"]
-
-examples:
- - |
-
- #include <dt-bindings/clock/tegra210-car.h>
- #include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h>
- #include <dt-bindings/soc/tegra-pmc.h>
-
- tegra_pmc: pmc@7000e400 {
- compatible = "nvidia,tegra210-pmc";
- reg = <0x7000e400 0x400>;
- core-supply = <&regulator>;
- clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
- clock-names = "pclk", "clk32k_in";
- #clock-cells = <1>;
-
- nvidia,invert-interrupt;
- nvidia,suspend-mode = <0>;
- nvidia,cpu-pwr-good-time = <0>;
- nvidia,cpu-pwr-off-time = <0>;
- nvidia,core-pwr-good-time = <4587 3876>;
- nvidia,core-pwr-off-time = <39065>;
- nvidia,core-power-req-active-high;
- nvidia,sys-clock-req-active-high;
-
- pd_core: core-domain {
- operating-points-v2 = <&core_opp_table>;
- #power-domain-cells = <0>;
- };
-
- powergates {
- pd_audio: aud {
- clocks = <&tegra_car TEGRA210_CLK_APE>,
- <&tegra_car TEGRA210_CLK_APB2APE>;
- resets = <&tegra_car 198>;
- power-domains = <&pd_core>;
- #power-domain-cells = <0>;
- };
-
- pd_xusbss: xusba {
- clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>;
- resets = <&tegra_car TEGRA210_CLK_XUSB_SS>;
- power-domains = <&pd_core>;
- #power-domain-cells = <0>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml
index 7b1fe50ffbe0..fcdf03131323 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra CBB 2.0 bindings
+title: NVIDIA Tegra CBB 2.0
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml b/Documentation/devicetree/bindings/arm/tesla.yaml
index 09856da657dc..d670a0d56222 100644
--- a/Documentation/devicetree/bindings/arm/tesla.yaml
+++ b/Documentation/devicetree/bindings/arm/tesla.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/tesla.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tesla Full Self Driving(FSD) platforms device tree bindings
+title: Tesla Full Self Driving(FSD) platforms
maintainers:
- Alim Akhtar <alim.akhtar@samsung.com>
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 28b8232e1c5b..85deda6d4292 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/ti/k3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments K3 Multicore SoC architecture device tree bindings
+title: Texas Instruments K3 Multicore SoC architecture
maintainers:
- Nishanth Menon <nm@ti.com>
@@ -25,12 +25,106 @@ properties:
- ti,am62a7-sk
- const: ti,am62a7
+ - description: K3 AM62D2 SoC and Boards
+ items:
+ - enum:
+ - ti,am62d2-evm
+ - const: ti,am62d2
+
+ - description: K3 AM62A7 SoC PHYTEC phyBOARD-Lyra
+ items:
+ - const: phytec,am62a7-phyboard-lyra-rdk
+ - const: phytec,am62a-phycore-som
+ - const: ti,am62a7
+
+ - description: K3 AM62L3 SoC and Boards
+ items:
+ - enum:
+ - ti,am62l3-evm
+ - const: ti,am62l3
+
+ - description: K3 AM62P5 SoC and Boards
+ items:
+ - enum:
+ - ti,am62p5-sk
+ - const: ti,am62p5
+
+ - description: K3 AM625 SoC PHYTEC phyBOARD-Lyra
+ items:
+ - const: phytec,am625-phyboard-lyra-rdk
+ - const: phytec,am62-phycore-som
+ - const: ti,am625
+
- description: K3 AM625 SoC
items:
- enum:
+ - beagle,am62-pocketbeagle2
+ - beagle,am625-beagleplay
- ti,am625-sk
+ - ti,am62-lp-sk
- const: ti,am625
+ - description: K3 AM6254atl SiP
+ items:
+ - enum:
+ - ti,am6254atl-sk
+ - const: ti,am6254atl
+ - const: ti,am625
+
+ - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards
+ items:
+ - enum:
+ - toradex,verdin-am62-nonwifi-dahlia # Verdin AM62 Module on Dahlia
+ - toradex,verdin-am62-nonwifi-dev # Verdin AM62 Module on Verdin Development Board
+ - toradex,verdin-am62-nonwifi-ivy # Verdin AM62 Module on Ivy
+ - toradex,verdin-am62-nonwifi-mallow # Verdin AM62 Module on Mallow
+ - toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia
+ - const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT
+ - const: toradex,verdin-am62 # Verdin AM62 Module
+ - const: ti,am625
+
+ - description: K3 AM62x SoC Toradex Verdin Modules and Carrier Boards with Wi-Fi / BT
+ items:
+ - enum:
+ - toradex,verdin-am62-wifi-dahlia # Verdin AM62 Wi-Fi / BT Module on Dahlia
+ - toradex,verdin-am62-wifi-dev # Verdin AM62 Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-am62-wifi-ivy # Verdin AM62 Wi-Fi / BT Module on Ivy
+ - toradex,verdin-am62-wifi-mallow # Verdin AM62 Wi-Fi / BT Module on Mallow
+ - toradex,verdin-am62-wifi-yavia # Verdin AM62 Wi-Fi / BT Module on Yavia
+ - const: toradex,verdin-am62-wifi # Verdin AM62 Wi-Fi / BT Module
+ - const: toradex,verdin-am62 # Verdin AM62 Module
+ - const: ti,am625
+
+ - description: K3 AM62P5 SoC Toradex Verdin Modules and Carrier Boards
+ items:
+ - enum:
+ - toradex,verdin-am62p-nonwifi-dahlia # Verdin AM62P Module on Dahlia
+ - toradex,verdin-am62p-nonwifi-dev # Verdin AM62P Module on Verdin Development Board
+ - toradex,verdin-am62p-nonwifi-ivy # Verdin AM62P Module on Ivy
+ - toradex,verdin-am62p-nonwifi-mallow # Verdin AM62P Module on Mallow
+ - toradex,verdin-am62p-nonwifi-yavia # Verdin AM62P Module on Yavia
+ - const: toradex,verdin-am62p-nonwifi # Verdin AM62P Module without Wi-Fi / BT
+ - const: toradex,verdin-am62p # Verdin AM62P Module
+ - const: ti,am62p5
+
+ - description: K3 AM62P5 SoC Toradex Verdin Modules and Carrier Boards with Wi-Fi / BT
+ items:
+ - enum:
+ - toradex,verdin-am62p-wifi-dahlia # Verdin AM62P Wi-Fi / BT Module on Dahlia
+ - toradex,verdin-am62p-wifi-dev # Verdin AM62P Wi-Fi / BT M. on Verdin Development B.
+ - toradex,verdin-am62p-wifi-ivy # Verdin AM62P Wi-Fi / BT Module on Ivy
+ - toradex,verdin-am62p-wifi-mallow # Verdin AM62P Wi-Fi / BT Module on Mallow
+ - toradex,verdin-am62p-wifi-yavia # Verdin AM62P Wi-Fi / BT Module on Yavia
+ - const: toradex,verdin-am62p-wifi # Verdin AM62P Wi-Fi / BT Module
+ - const: toradex,verdin-am62p # Verdin AM62P Module
+ - const: ti,am62p5
+
+ - description: K3 AM62P5 SoC Variscite SOM and Carrier Boards
+ items:
+ - const: variscite,var-som-am62p-symphony
+ - const: variscite,var-som-am62p
+ - const: ti,am62p5
+
- description: K3 AM642 SoC
items:
- enum:
@@ -38,16 +132,46 @@ properties:
- ti,am642-sk
- const: ti,am642
+ - description: K3 AM642 SoC PHYTEC phyBOARD-Electra
+ items:
+ - const: phytec,am642-phyboard-electra-rdk
+ - const: phytec,am64-phycore-som
+ - const: ti,am642
+
+ - description: K3 AM642 SoC on TQ-Systems TQMaX4XxL SoM
+ items:
+ - enum:
+ - tq,am642-tqma6442l-mbax4xxl # MBaX4XxL base board
+ - const: tq,am642-tqma6442l
+ - const: ti,am642
+
+ - description: K3 AM642 SoC SolidRun SoM based boards
+ items:
+ - enum:
+ - solidrun,am642-hummingboard-t
+ - const: solidrun,am642-sr-som
+ - const: ti,am642
+
- description: K3 AM654 SoC
items:
- enum:
- siemens,iot2050-advanced
+ - siemens,iot2050-advanced-m2
- siemens,iot2050-advanced-pg2
+ - siemens,iot2050-advanced-sm
- siemens,iot2050-basic
- siemens,iot2050-basic-pg2
- ti,am654-evm
- const: ti,am654
+ - description: K3 AM69 SoC Toradex Aquila Modules and Carrier Boards
+ items:
+ - enum:
+ - toradex,aquila-am69-clover # Aquila AM69 Module on Clover Board
+ - toradex,aquila-am69-dev # Aquila AM69 Module on Aquila Development Board
+ - const: toradex,aquila-am69 # Aquila AM69 Module
+ - const: ti,j784s4
+
- description: K3 J7200 SoC
oneOf:
- const: ti,j7200
@@ -61,6 +185,7 @@ properties:
- const: ti,j721e
- items:
- enum:
+ - beagle,j721e-beagleboneai64
- ti,j721e-evm
- ti,j721e-sk
- const: ti,j721e
@@ -68,9 +193,38 @@ properties:
- description: K3 J721s2 SoC
items:
- enum:
+ - ti,am68-sk
- ti,j721s2-evm
- const: ti,j721s2
+ - description: K3 J721s2 SoC Phytec SoM based boards
+ items:
+ - enum:
+ - phytec,am68-phyboard-izar
+ - const: phytec,am68-phycore-som
+ - const: ti,j721s2
+
+ - description: K3 J722S SoC and Boards
+ items:
+ - enum:
+ - beagle,am67a-beagley-ai
+ - kontron,sa67 # Kontron SMARC-sAM67 board
+ - ti,j722s-evm
+ - const: ti,j722s
+
+ - description: K3 J742S2 SoC
+ items:
+ - enum:
+ - ti,j742s2-evm
+ - const: ti,j742s2
+
+ - description: K3 J784s4 SoC
+ items:
+ - enum:
+ - ti,am69-sk
+ - ti,j784s4-evm
+ - const: ti,j784s4
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/arm/ti/omap.yaml b/Documentation/devicetree/bindings/arm/ti/omap.yaml
new file mode 100644
index 000000000000..14f1b9d8f59d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/omap.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/ti/omap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OMAP SoC architecture
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description: Platforms based on Texas Instruments OMAP SoC architecture.
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+
+ - description: TI OMAP2420 SoC based platforms
+ items:
+ - enum:
+ - nokia,n800
+ - nokia,n810
+ - nokia,n810-wimax
+ - ti,omap2420-h4
+ - const: ti,omap2420
+ - const: ti,omap2
+
+ - description: TI OMAP2430 SoC based platforms
+ items:
+ - enum:
+ - ti,omap2430-sdp # TI OMAP2430 SDP
+ - const: ti,omap2430
+ - const: ti,omap2
+
+ - description: TI OMAP3430 SoC based platforms
+ items:
+ - enum:
+ - compulab,omap3-cm-t3530
+ - logicpd,dm3730-som-lv-devkit # LogicPD Zoom OMAP35xx SOM-LV Development Kit
+ - logicpd,dm3730-torpedo-devkit # LogicPD Zoom OMAP35xx Torpedo Development Kit
+ - nokia,omap3-n900
+ - openpandora,omap3-pandora-600mhz
+ - ti,omap3430-sdp
+ - ti,omap3-beagle
+ - ti,omap3-evm # TI OMAP35XX EVM (TMDSEVM3530)
+ - ti,omap3-ldp # TI OMAP3430 LDP (Zoom1 Labrador)
+ - timll,omap3-devkit8000
+ - const: ti,omap3430
+ - const: ti,omap3
+
+ - description: Early BeagleBoard revisions A to B4 with a timer quirk
+ items:
+ - const: ti,omap3-beagle-ab4
+ - const: ti,omap3-beagle
+ - const: ti,omap3430
+ - const: ti,omap3
+
+ - description: Gumstix Overo TI OMAP 3430/3630 boards + expansion boards
+ items:
+ - enum:
+ - gumstix,omap3-overo-alto35
+ - gumstix,omap3-overo-chestnut43
+ - gumstix,omap3-overo-gallop43
+ - gumstix,omap3-overo-palo35
+ - gumstix,omap3-overo-palo43
+ - gumstix,omap3-overo-summit
+ - gumstix,omap3-overo-tobi
+ - gumstix,omap3-overo-tobiduo
+ - const: gumstix,omap3-overo
+ - enum:
+ - ti,omap3430
+ - ti,omap3630
+
+ - description: TI OMAP3630 SoC based platforms
+ items:
+ - enum:
+ - amazon,omap3-echo # Amazon Echo (first generation)
+ - compulab,omap3-cm-t3730
+ - goldelico,gta04
+ - lg,omap3-sniper # LG Optimus Black
+ - logicpd,dm3730-som-lv-devkit # LogicPD Zoom DM3730 SOM-LV Development Kit
+ - logicpd,dm3730-torpedo-devkit # LogicPD Zoom DM3730 Torpedo + Wireless Development Kit
+ - nokia,omap3-n9
+ - nokia,omap3-n950
+ - openpandora,omap3-pandora-1ghz
+ - ti,omap3-beagle-xm
+ - ti,omap3-evm-37xx # TI OMAP37XX EVM (TMDSEVM3730)
+ - ti,omap3-zoom3
+ - const: ti,omap3630
+ - const: ti,omap3
+
+ - description: TI AM35 SoC based platforms
+ items:
+ - enum:
+ - compulab,omap3-sbc-t3517 # CompuLab SBC-T3517 with CM-T3517
+ - teejet,mt_ventoux
+ - ti,am3517-craneboard # TI AM3517 CraneBoard (TMDSEVM3517)
+ - ti,am3517-evm # TI AM3517 EVM (AM3517/05 TMDSEVM3517)
+ - const: ti,am3517
+ - const: ti,omap3
+
+ - description: TI AM33 based platform
+ items:
+ - enum:
+ - compulab,cm-t335
+ - moxa,uc-8100-me-t
+ - novatech,am335x-lxm
+ - seeed,am335x-bone-green-eco
+ - ti,am335x-bone
+ - ti,am335x-evm
+ - ti,am3359-icev2
+ - const: ti,am33xx
+
+ - description: Compulab board variants based on TI AM33
+ items:
+ - enum:
+ - compulab,sbc-t335
+ - const: compulab,cm-t335
+ - const: ti,am33xx
+
+ - description: Phytec boards based on TI AM33
+ items:
+ - enum:
+ - phytec,am335x-wega
+ - phytec,am335x-pcm-953
+ - phytec,am335x-regor
+ - const: phytec,am335x-phycore-som
+ - const: ti,am33xx
+
+ - description: TQ-Systems TQMa335x[L] SoM
+ items:
+ - enum:
+ - tq,tqma3359-mba335x # MBa335x carrier board
+ - const: tq,tqma3359
+ - const: ti,am33xx
+
+ - description: TI OMAP4430 SoC based platforms
+ items:
+ - enum:
+ - amazon,omap4-kc1 # Amazon Kindle Fire (first generation)
+ - motorola,droid4 # Motorola Droid 4 XT894
+ - motorola,droid-bionic # Motorola Droid Bionic XT875
+ - motorola,xyboard-mz609
+ - motorola,xyboard-mz617
+ - ti,omap4-panda
+ - ti,omap4-sdp
+ - const: ti,omap4430
+ - const: ti,omap4
+
+ - description: OMAP4 PandaBoard Revision A4 and later
+ items:
+ - const: ti,omap4-panda-a4
+ - const: ti,omap4-panda
+ - const: ti,omap4430
+ - const: ti,omap4
+
+ - description: OMAP4 DuoVero with Parlor expansion board/daughter board
+ items:
+ - const: gumstix,omap4-duovero-parlor
+ - const: gumstix,omap4-duovero
+ - const: ti,omap4430
+ - const: ti,omap4
+
+ - description: TI OMAP4460 SoC based platforms
+ items:
+ - enum:
+ - epson,embt2ws # Epson Moverio BT-200
+ - ti,omap4-panda-es
+ - const: ti,omap4460
+ - const: ti,omap4
+
+ - description: VAR-OM44 boards
+ items:
+ - enum:
+ - variscite,var-dvk-om44
+ - variscite,var-stk-om44
+ - const: variscite,var-som-om44
+ - const: ti,omap4460
+ - const: ti,omap4
+
+ - description: TI OMAP5 SoC based platforms
+ items:
+ - enum:
+ - compulab,omap5-cm-t54
+ - isee,omap5-igep0050
+ - ti,omap5-uevm
+ - const: ti,omap5
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml b/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml
index c022d325fc08..1656d1a4476f 100644
--- a/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/ti/ti,davinci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments DaVinci Platforms Device Tree Bindings
+title: Texas Instruments DaVinci Platforms
maintainers:
- Sekhar Nori <nsekhar@ti.com>
diff --git a/Documentation/devicetree/bindings/arm/ti/ti,keystone.yaml b/Documentation/devicetree/bindings/arm/ti/ti,keystone.yaml
new file mode 100644
index 000000000000..20d4084f4506
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/ti,keystone.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/ti/ti,keystone.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Keystone Platforms
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+ - Santosh Shilimkar <ssantosh@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - description: K2G
+ items:
+ - enum:
+ - ti,k2g-evm
+ - ti,k2g-ice
+ - const: ti,k2g
+ - const: ti,keystone
+ - description: Keystone 2 Edison
+ items:
+ - enum:
+ - ti,k2e-evm
+ - const: ti,k2e
+ - const: ti,keystone
+ - description: Keystone 2 Lamarr
+ items:
+ - enum:
+ - ti,k2l-evm
+ - const: ti,k2l
+ - const: ti,keystone
+ - description: Keystone 2 Hawking/Kepler
+ items:
+ - enum:
+ - ti,k2hk-evm
+ - const: ti,k2hk
+ - const: ti,keystone
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/toshiba.yaml b/Documentation/devicetree/bindings/arm/toshiba.yaml
index 9c1cacbdc916..716ba4a3cab4 100644
--- a/Documentation/devicetree/bindings/arm/toshiba.yaml
+++ b/Documentation/devicetree/bindings/arm/toshiba.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/toshiba.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba Visconti Platform Device Tree Bindings
+title: Toshiba Visconti Platform
maintainers:
- Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
diff --git a/Documentation/devicetree/bindings/arm/ux500.yaml b/Documentation/devicetree/bindings/arm/ux500.yaml
index 17accb31bca0..b42d20fa4359 100644
--- a/Documentation/devicetree/bindings/arm/ux500.yaml
+++ b/Documentation/devicetree/bindings/arm/ux500.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/ux500.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ux500 platforms device tree bindings
+title: Ux500 platforms
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
diff --git a/Documentation/devicetree/bindings/arm/versatile-sysreg.txt b/Documentation/devicetree/bindings/arm/versatile-sysreg.txt
deleted file mode 100644
index a4f15262d717..000000000000
--- a/Documentation/devicetree/bindings/arm/versatile-sysreg.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-ARM Versatile system registers
---------------------------------------
-
-This is a system control registers block, providing multiple low level
-platform functions like board detection and identification, software
-interrupt generation, MMC and NOR Flash control etc.
-
-Required node properties:
-- compatible value : = "arm,versatile-sysreg", "syscon"
-- reg : physical base address and the size of the registers window
diff --git a/Documentation/devicetree/bindings/arm/vexpress-config.yaml b/Documentation/devicetree/bindings/arm/vexpress-config.yaml
index 09e1adf5ca7a..b74380da3198 100644
--- a/Documentation/devicetree/bindings/arm/vexpress-config.yaml
+++ b/Documentation/devicetree/bindings/arm/vexpress-config.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/vexpress-config.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Versatile Express configuration bus bindings
+title: ARM Versatile Express configuration bus
maintainers:
- Andre Przywara <andre.przywara@arm.com>
diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml b/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml
index f04db802a732..be6e3b542569 100644
--- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml
+++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/vexpress-sysreg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM Versatile Express system registers bindings
+title: ARM Versatile Express system registers
maintainers:
- Andre Przywara <andre.przywara@arm.com>
diff --git a/Documentation/devicetree/bindings/arm/vt8500.yaml b/Documentation/devicetree/bindings/arm/vt8500.yaml
index 7b762bfc11e7..fa47b8989bbf 100644
--- a/Documentation/devicetree/bindings/arm/vt8500.yaml
+++ b/Documentation/devicetree/bindings/arm/vt8500.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/arm/vt8500.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: VIA/Wondermedia VT8500 Platforms Device Tree Bindings
+title: VIA/Wondermedia VT8500 Platforms
maintainers:
- - Tony Prisk <linux@prisktech.co.nz>
-description: test
+ - Alexey Charkov <alchark@gmail.com>
properties:
$nodename:
const: '/'
compatible:
- items:
+ oneOf:
- enum:
- via,vt8500
- wm,wm8505
@@ -22,4 +21,9 @@ properties:
- wm,wm8750
- wm,wm8850
+ - description: VIA APC Rock and Paper boards
+ items:
+ - const: via,apc-rock
+ - const: wm,wm8950
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 61d77acbeb5e..f925290d4641 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -56,7 +56,7 @@ hypervisor {
};
The format and meaning of the "xen,uefi-*" parameters are similar to those in
-Documentation/arm/uefi.rst, which are provided by the regular UEFI stub. However
+Documentation/arch/arm/uefi.rst, which are provided by the regular UEFI stub. However
they differ because they are provided by the Xen hypervisor, together with a set
of UEFI runtime services implemented via hypercalls, see
http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml
deleted file mode 100644
index 4dc0e0195974..000000000000
--- a/Documentation/devicetree/bindings/arm/xilinx.yaml
+++ /dev/null
@@ -1,137 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/arm/xilinx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Xilinx Zynq Platforms Device Tree Bindings
-
-maintainers:
- - Michal Simek <michal.simek@xilinx.com>
-
-description: |
- Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC
-
-properties:
- $nodename:
- const: '/'
- compatible:
- oneOf:
- - items:
- - enum:
- - adapteva,parallella
- - digilent,zynq-zybo
- - digilent,zynq-zybo-z7
- - ebang,ebaz4205
- - myir,zynq-zturn-v5
- - myir,zynq-zturn
- - xlnx,zynq-cc108
- - xlnx,zynq-zc702
- - xlnx,zynq-zc706
- - xlnx,zynq-zc770-xm010
- - xlnx,zynq-zc770-xm011
- - xlnx,zynq-zc770-xm012
- - xlnx,zynq-zc770-xm013
- - const: xlnx,zynq-7000
-
- - items:
- - const: avnet,zynq-microzed
- - const: xlnx,zynq-microzed
- - const: xlnx,zynq-7000
-
- - items:
- - const: avnet,zynq-zed
- - const: xlnx,zynq-zed
- - const: xlnx,zynq-7000
-
- - items:
- - enum:
- - xlnx,zynqmp-zc1751
- - const: xlnx,zynqmp
-
- - description: Xilinx internal board zc1232
- items:
- - const: xlnx,zynqmp-zc1232-revA
- - const: xlnx,zynqmp-zc1232
- - const: xlnx,zynqmp
-
- - description: Xilinx internal board zc1254
- items:
- - const: xlnx,zynqmp-zc1254-revA
- - const: xlnx,zynqmp-zc1254
- - const: xlnx,zynqmp
-
- - description: Xilinx internal board zc1275
- items:
- - const: xlnx,zynqmp-zc1275-revA
- - const: xlnx,zynqmp-zc1275
- - const: xlnx,zynqmp
-
- - description: Xilinx 96boards compatible board zcu100
- items:
- - const: xlnx,zynqmp-zcu100-revC
- - const: xlnx,zynqmp-zcu100
- - const: xlnx,zynqmp
-
- - description: Xilinx 96boards compatible board Ultra96
- items:
- - const: avnet,ultra96-rev1
- - const: avnet,ultra96
- - const: xlnx,zynqmp-zcu100-revC
- - const: xlnx,zynqmp-zcu100
- - const: xlnx,zynqmp
-
- - description: Xilinx evaluation board zcu102
- items:
- - enum:
- - xlnx,zynqmp-zcu102-revA
- - xlnx,zynqmp-zcu102-revB
- - xlnx,zynqmp-zcu102-rev1.0
- - xlnx,zynqmp-zcu102-rev1.1
- - const: xlnx,zynqmp-zcu102
- - const: xlnx,zynqmp
-
- - description: Xilinx evaluation board zcu104
- items:
- - enum:
- - xlnx,zynqmp-zcu104-revA
- - xlnx,zynqmp-zcu104-revC
- - xlnx,zynqmp-zcu104-rev1.0
- - const: xlnx,zynqmp-zcu104
- - const: xlnx,zynqmp
-
- - description: Xilinx evaluation board zcu106
- items:
- - enum:
- - xlnx,zynqmp-zcu106-revA
- - xlnx,zynqmp-zcu106-rev1.0
- - const: xlnx,zynqmp-zcu106
- - const: xlnx,zynqmp
-
- - description: Xilinx evaluation board zcu111
- items:
- - enum:
- - xlnx,zynqmp-zcu111-revA
- - xlnx,zynqmp-zcu111-rev1.0
- - const: xlnx,zynqmp-zcu111
- - const: xlnx,zynqmp
-
- - description: Xilinx Kria SOMs
- items:
- - const: xlnx,zynqmp-sm-k26-rev1
- - const: xlnx,zynqmp-sm-k26-revB
- - const: xlnx,zynqmp-sm-k26-revA
- - const: xlnx,zynqmp-sm-k26
- - const: xlnx,zynqmp
-
- - description: Xilinx Kria SOMs (starter)
- items:
- - const: xlnx,zynqmp-smk-k26-rev1
- - const: xlnx,zynqmp-smk-k26-revB
- - const: xlnx,zynqmp-smk-k26-revA
- - const: xlnx,zynqmp-smk-k26
- - const: xlnx,zynqmp
-
-additionalProperties: true
-
-...
diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
index 94d72aeaad0f..38770c4c85fd 100644
--- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
@@ -8,7 +8,7 @@ title: Common Properties for Serial ATA AHCI controllers
maintainers:
- Hans de Goede <hdegoede@redhat.com>
- - Damien Le Moal <damien.lemoal@opensource.wdc.com>
+ - Damien Le Moal <dlemoal@kernel.org>
description:
This document defines device tree properties for a common AHCI SATA
@@ -59,7 +59,7 @@ properties:
const: sata-phy
hba-cap:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Bitfield of the HBA generic platform capabilities like Staggered
Spin-up or Mechanical Presence Switch support. It can be used to
@@ -67,7 +67,7 @@ properties:
in case if the system firmware hasn't done it.
ports-implemented:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Mask that indicates which ports the HBA supports. Useful if PI is not
programmed by the BIOS, which is true for some embedded SoC's.
@@ -110,7 +110,7 @@ $defs:
description: Power regulator for SATA port target device
hba-port-cap:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Bitfield of the HBA port-specific platform capabilities like Hot
plugging, eSATA, FIS-based Switching, etc (see AHCI specification
diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
deleted file mode 100644
index 5f8193417725..000000000000
--- a/Documentation/devicetree/bindings/ata/ahci-da850.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device tree binding for the TI DA850 AHCI SATA Controller
----------------------------------------------------------
-
-Required properties:
- - compatible: must be "ti,da850-ahci"
- - reg: physical base addresses and sizes of the two register regions
- used by the controller: the register map as defined by the
- AHCI 1.1 standard and the Power Down Control Register (PWRDN)
- for enabling/disabling the SATA clock receiver
- - interrupts: interrupt specifier (refer to the interrupt binding)
-
-Example:
-
- sata: sata@218000 {
- compatible = "ti,da850-ahci";
- reg = <0x218000 0x2000>, <0x22c018 0x4>;
- interrupts = <67>;
- };
diff --git a/Documentation/devicetree/bindings/ata/ahci-dm816.txt b/Documentation/devicetree/bindings/ata/ahci-dm816.txt
deleted file mode 100644
index f8c535f3541f..000000000000
--- a/Documentation/devicetree/bindings/ata/ahci-dm816.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Device tree binding for the TI DM816 AHCI SATA Controller
----------------------------------------------------------
-
-Required properties:
- - compatible: must be "ti,dm816-ahci"
- - reg: physical base address and size of the register region used by
- the controller (as defined by the AHCI 1.1 standard)
- - interrupts: interrupt specifier (refer to the interrupt binding)
- - clocks: list of phandle and clock specifier pairs (or only
- phandles for clock providers with '0' defined for
- #clock-cells); two clocks must be specified: the functional
- clock and an external reference clock
-
-Example:
-
- sata: sata@4a140000 {
- compatible = "ti,dm816-ahci";
- reg = <0x4a140000 0x10000>;
- interrupts = <16>;
- clocks = <&sysclk5_ck>, <&sata_refclk>;
- };
diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
deleted file mode 100644
index 7c3ca0e13de0..000000000000
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Binding for Freescale QorIQ AHCI SATA Controller
-
-Required properties:
- - reg: Physical base address and size of the controller's register area.
- - compatible: Compatibility string. Must be 'fsl,<chip>-ahci', where
- chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a etc.
- - clocks: Input clock specifier. Refer to common clock bindings.
- - interrupts: Interrupt specifier. Refer to interrupt binding.
-
-Optional properties:
- - dma-coherent: Enable AHCI coherent DMA operation.
- - reg-names: register area names when there are more than 1 register area.
-
-Examples:
- sata@3200000 {
- compatible = "fsl,ls1021a-ahci";
- reg = <0x0 0x3200000 0x0 0x10000>;
- interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&platform_clk 1>;
- dma-coherent;
- };
diff --git a/Documentation/devicetree/bindings/ata/ahci-mtk.txt b/Documentation/devicetree/bindings/ata/ahci-mtk.txt
deleted file mode 100644
index d2aa696b161b..000000000000
--- a/Documentation/devicetree/bindings/ata/ahci-mtk.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-MediaTek Serial ATA controller
-
-Required properties:
- - compatible : Must be "mediatek,<chip>-ahci", "mediatek,mtk-ahci".
- When using "mediatek,mtk-ahci" compatible strings, you
- need SoC specific ones in addition, one of:
- - "mediatek,mt7622-ahci"
- - reg : Physical base addresses and length of register sets.
- - interrupts : Interrupt associated with the SATA device.
- - interrupt-names : Associated name must be: "hostc".
- - clocks : A list of phandle and clock specifier pairs, one for each
- entry in clock-names.
- - clock-names : Associated names must be: "ahb", "axi", "asic", "rbc", "pm".
- - phys : A phandle and PHY specifier pair for the PHY port.
- - phy-names : Associated name must be: "sata-phy".
- - ports-implemented : See ./ahci-platform.txt for details.
-
-Optional properties:
- - power-domains : A phandle and power domain specifier pair to the power
- domain which is responsible for collapsing and restoring
- power to the peripheral.
- - resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names : Associated names must be: "axi", "sw", "reg".
- - mediatek,phy-mode : A phandle to the system controller, used to enable
- SATA function.
-
-Example:
-
- sata: sata@1a200000 {
- compatible = "mediatek,mt7622-ahci",
- "mediatek,mtk-ahci";
- reg = <0 0x1a200000 0 0x1100>;
- interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "hostc";
- clocks = <&pciesys CLK_SATA_AHB_EN>,
- <&pciesys CLK_SATA_AXI_EN>,
- <&pciesys CLK_SATA_ASIC_EN>,
- <&pciesys CLK_SATA_RBC_EN>,
- <&pciesys CLK_SATA_PM_EN>;
- clock-names = "ahb", "axi", "asic", "rbc", "pm";
- phys = <&u3port1 PHY_TYPE_SATA>;
- phy-names = "sata-phy";
- ports-implemented = <0x1>;
- power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
- resets = <&pciesys MT7622_SATA_AXI_BUS_RST>,
- <&pciesys MT7622_SATA_PHY_SW_RST>,
- <&pciesys MT7622_SATA_PHY_REG_RST>;
- reset-names = "axi", "sw", "reg";
- mediatek,phy-mode = <&pciesys>;
- };
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
index 7dc2a2e8f598..cc35cdc02840 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
@@ -30,12 +30,14 @@ select:
- marvell,armada-3700-ahci
- marvell,armada-8k-ahci
- marvell,berlin2q-ahci
+ - qcom,apq8064-ahci
+ - qcom,ipq806x-ahci
+ - socionext,uniphier-pro4-ahci
+ - socionext,uniphier-pxs2-ahci
+ - socionext,uniphier-pxs3-ahci
required:
- compatible
-allOf:
- - $ref: "ahci-common.yaml#"
-
properties:
compatible:
oneOf:
@@ -45,6 +47,11 @@ properties:
- marvell,armada-8k-ahci
- marvell,berlin2-ahci
- marvell,berlin2q-ahci
+ - qcom,apq8064-ahci
+ - qcom,ipq806x-ahci
+ - socionext,uniphier-pro4-ahci
+ - socionext,uniphier-pxs2-ahci
+ - socionext,uniphier-pxs3-ahci
- const: generic-ahci
- enum:
- cavium,octeon-7130-ahci
@@ -61,11 +68,11 @@ properties:
clocks:
minItems: 1
- maxItems: 3
+ maxItems: 5
clock-names:
minItems: 1
- maxItems: 3
+ maxItems: 5
interrupts:
maxItems: 1
@@ -74,6 +81,10 @@ properties:
maxItems: 1
resets:
+ minItems: 1
+ maxItems: 3
+
+ iommus:
maxItems: 1
patternProperties:
@@ -91,6 +102,68 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: ahci-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,apq8064-ahci
+ - qcom,ipq806x-ahci
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ clock-names:
+ items:
+ - const: slave_iface
+ - const: iface
+ - const: core
+ - const: rxoob
+ - const: pmalive
+ required:
+ - phys
+ - phy-names
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-pro4-ahci
+ then:
+ properties:
+ resets:
+ items:
+ - description: reset line for the parent
+ - description: reset line for the glue logic
+ - description: reset line for the controller
+ required:
+ - resets
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - socionext,uniphier-pxs2-ahci
+ - socionext,uniphier-pxs3-ahci
+ then:
+ properties:
+ resets:
+ items:
+ - description: reset for the glue logic
+ - description: reset for the controller
+ required:
+ - resets
+ else:
+ properties:
+ resets:
+ maxItems: 1
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt
deleted file mode 100644
index 909c9935360d..000000000000
--- a/Documentation/devicetree/bindings/ata/ahci-st.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-STMicroelectronics STi SATA controller
-
-This binding describes a SATA device.
-
-Required properties:
- - compatible : Must be "st,ahci"
- - reg : Physical base addresses and length of register sets
- - interrupts : Interrupt associated with the SATA device
- - interrupt-names : Associated name must be; "hostc"
- - clocks : The phandle for the clock
- - clock-names : Associated name must be; "ahci_clk"
- - phys : The phandle for the PHY port
- - phy-names : Associated name must be; "ahci_phy"
-
-Optional properties:
- - resets : The power-down, soft-reset and power-reset lines of SATA IP
- - reset-names : Associated names must be; "pwr-dwn", "sw-rst" and "pwr-rst"
-
-Example:
-
- /* Example for stih407 family silicon */
- sata0: sata@9b20000 {
- compatible = "st,ahci";
- reg = <0x9b20000 0x1000>;
- interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>;
- interrupt-names = "hostc";
- phys = <&phy_port0 PHY_TYPE_SATA>;
- phy-names = "ahci_phy";
- resets = <&powerdown STIH407_SATA0_POWERDOWN>,
- <&softreset STIH407_SATA0_SOFTRESET>,
- <&softreset STIH407_SATA0_PWR_SOFTRESET>;
- reset-names = "pwr-dwn", "sw-rst", "pwr-rst";
- clocks = <&clk_s_c0_flexgen CLK_ICN_REG>;
- clock-names = "ahci_clk";
- };
diff --git a/Documentation/devicetree/bindings/ata/allwinner,sun4i-a10-ahci.yaml b/Documentation/devicetree/bindings/ata/allwinner,sun4i-a10-ahci.yaml
index cb530b46beff..2011bd03cdcd 100644
--- a/Documentation/devicetree/bindings/ata/allwinner,sun4i-a10-ahci.yaml
+++ b/Documentation/devicetree/bindings/ata/allwinner,sun4i-a10-ahci.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ata/allwinner,sun4i-a10-ahci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 AHCI SATA Controller bindings
+title: Allwinner A10 AHCI SATA Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/ata/allwinner,sun8i-r40-ahci.yaml b/Documentation/devicetree/bindings/ata/allwinner,sun8i-r40-ahci.yaml
index e6b42a113ff1..a2afe2ad6063 100644
--- a/Documentation/devicetree/bindings/ata/allwinner,sun8i-r40-ahci.yaml
+++ b/Documentation/devicetree/bindings/ata/allwinner,sun8i-r40-ahci.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ata/allwinner,sun8i-r40-ahci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner R40 AHCI SATA Controller bindings
+title: Allwinner R40 AHCI SATA Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml b/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml
new file mode 100644
index 000000000000..dc631381f9e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/apm,xgene-ahci.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/apm,xgene-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene 6.0 Gb/s SATA host controller
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - apm,xgene-ahci
+ - apm,xgene-ahci-v2
+
+ reg:
+ minItems: 4
+ items:
+ - description: AHCI memory resource
+ - description: Host controller core
+ - description: Host controller diagnostic
+ - description: Host controller AXI
+ - description: Host controller MUX
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: ahci-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: apm,xgene-ahci
+ then:
+ required:
+ - clocks
+ - phys
+ - phy-names
+
+examples:
+ - |
+ sata@1a400000 {
+ compatible = "apm,xgene-ahci";
+ reg = <0x1a400000 0x1000>,
+ <0x1f220000 0x1000>,
+ <0x1f22d000 0x1000>,
+ <0x1f22e000 0x1000>,
+ <0x1f227000 0x1000>;
+ clocks = <&sataclk 0>;
+ dma-coherent;
+ interrupts = <0x0 0x87 0x4>;
+ phys = <&phy2 0>;
+ phy-names = "sata-phy";
+ };
diff --git a/Documentation/devicetree/bindings/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt
deleted file mode 100644
index 02e690a675db..000000000000
--- a/Documentation/devicetree/bindings/ata/apm-xgene.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-* APM X-Gene 6.0 Gb/s SATA host controller nodes
-
-SATA host controller nodes are defined to describe on-chip Serial ATA
-controllers. Each SATA controller (pair of ports) have its own node.
-
-Required properties:
-- compatible : Shall contain:
- * "apm,xgene-ahci"
-- reg : First memory resource shall be the AHCI memory
- resource.
- Second memory resource shall be the host controller
- core memory resource.
- Third memory resource shall be the host controller
- diagnostic memory resource.
- 4th memory resource shall be the host controller
- AXI memory resource.
- 5th optional memory resource shall be the host
- controller MUX memory resource if required.
-- interrupts : Interrupt-specifier for SATA host controller IRQ.
-- clocks : Reference to the clock entry.
-- phys : A list of phandles + phy-specifiers, one for each
- entry in phy-names.
-- phy-names : Should contain:
- * "sata-phy" for the SATA 6.0Gbps PHY
-
-Optional properties:
-- dma-coherent : Present if dma operations are coherent
-- status : Shall be "ok" if enabled or "disabled" if disabled.
- Default is "ok".
-
-Example:
- sataclk: sataclk {
- compatible = "fixed-clock";
- #clock-cells = <1>;
- clock-frequency = <100000000>;
- clock-output-names = "sataclk";
- };
-
- phy2: phy@1f22a000 {
- compatible = "apm,xgene-phy";
- reg = <0x0 0x1f22a000 0x0 0x100>;
- #phy-cells = <1>;
- };
-
- phy3: phy@1f23a000 {
- compatible = "apm,xgene-phy";
- reg = <0x0 0x1f23a000 0x0 0x100>;
- #phy-cells = <1>;
- };
-
- sata2: sata@1a400000 {
- compatible = "apm,xgene-ahci";
- reg = <0x0 0x1a400000 0x0 0x1000>,
- <0x0 0x1f220000 0x0 0x1000>,
- <0x0 0x1f22d000 0x0 0x1000>,
- <0x0 0x1f22e000 0x0 0x1000>,
- <0x0 0x1f227000 0x0 0x1000>;
- interrupts = <0x0 0x87 0x4>;
- dma-coherent;
- clocks = <&sataclk 0>;
- phys = <&phy2 0>;
- phy-names = "sata-phy";
- };
-
- sata3: sata@1a800000 {
- compatible = "apm,xgene-ahci-pcie";
- reg = <0x0 0x1a800000 0x0 0x1000>,
- <0x0 0x1f230000 0x0 0x1000>,
- <0x0 0x1f23d000 0x0 0x1000>,
- <0x0 0x1f23e000 0x0 0x1000>,
- <0x0 0x1f237000 0x0 0x1000>;
- interrupts = <0x0 0x88 0x4>;
- dma-coherent;
- clocks = <&sataclk 0>;
- phys = <&phy3 0>;
- phy-names = "sata-phy";
- };
diff --git a/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml b/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml
new file mode 100644
index 000000000000..4d7017452dda
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/arasan,cf-spear1340.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/arasan,cf-spear1340.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arasan PATA Compact Flash Controller
+
+maintainers:
+ - Viresh Kumar <viresh.kumar@linaro.org>
+
+properties:
+ compatible:
+ const: arasan,cf-spear1340
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ arasan,broken-udma:
+ description: UDMA mode is unusable
+ type: boolean
+
+ arasan,broken-mwdma:
+ description: MWDMA mode is unusable
+ type: boolean
+
+ arasan,broken-pio:
+ description: PIO mode is unusable
+ type: boolean
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: data
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+allOf:
+ - if:
+ not:
+ required:
+ - arasan,broken-udma
+ - arasan,broken-mwdma
+ then:
+ required:
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ cf@fc000000 {
+ compatible = "arasan,cf-spear1340";
+ reg = <0xfc000000 0x1000>;
+ interrupts = <12>;
+ dmas = <&dma 23>;
+ dma-names = "data";
+ };
diff --git a/Documentation/devicetree/bindings/ata/ata-generic.yaml b/Documentation/devicetree/bindings/ata/ata-generic.yaml
new file mode 100644
index 000000000000..0697927f3d7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ata-generic.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/ata-generic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Parallel ATA Controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ Generic Parallel ATA controllers supporting PIO modes only.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - arm,vexpress-cf
+ - fsl,mpc8349emitx-pata
+ - const: ata-generic
+
+ reg:
+ items:
+ - description: Command interface registers
+ - description: Control interface registers
+
+ reg-shift:
+ enum: [ 1, 2 ]
+
+ interrupts:
+ maxItems: 1
+
+ ata-generic,use16bit:
+ type: boolean
+ description: Use 16-bit accesses instead of 32-bit for data transfers
+
+ pio-mode:
+ description: Maximum ATA PIO transfer mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 6
+ default: 0
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ compact-flash@1a000 {
+ compatible = "arm,vexpress-cf", "ata-generic";
+ reg = <0x1a000 0x100>,
+ <0x1a100 0xf00>;
+ reg-shift = <2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
deleted file mode 100644
index c1d22b3ae134..000000000000
--- a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Atmel AT91RM9200 CompactFlash
-
-Required properties:
-- compatible : "atmel,at91rm9200-cf".
-- reg : should specify localbus address and size used.
-- gpios : specifies the gpio pins to control the CF device. Detect
- and reset gpio's are mandatory while irq and vcc gpio's are
- optional and may be set to 0 if not present.
-
-Example:
-compact-flash@50000000 {
- compatible = "atmel,at91rm9200-cf";
- reg = <0x50000000 0x30000000>;
- gpios = <&pioC 13 0 /* irq */
- &pioC 15 0 /* detect */
- 0 /* vcc */
- &pioC 5 0 /* reset */
- >;
-};
diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml
index fa8ebc8f243f..fe7f091e744f 100644
--- a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml
+++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml
@@ -30,7 +30,6 @@ properties:
- const: brcm,bcm-nsp-ahci
reg:
- minItems: 2
maxItems: 2
reg-names:
diff --git a/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml b/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml
new file mode 100644
index 000000000000..349f289b81e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/cavium,ebt3000-compact-flash.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/cavium,ebt3000-compact-flash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cavium Compact Flash
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+description:
+ The Cavium Compact Flash device is connected to the Octeon Boot Bus, and is
+ thus a child of the Boot Bus device. It can read and write industry standard
+ compact flash devices.
+
+properties:
+ compatible:
+ const: cavium,ebt3000-compact-flash
+
+ reg:
+ description: The base address of the CF chip select banks.
+ items:
+ - description: CF chip select bank 0
+ - description: CF chip select bank 1
+
+ cavium,bus-width:
+ description: The width of the connection to the CF devices.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16]
+
+ cavium,true-ide:
+ description: True IDE mode when present.
+ type: boolean
+
+ cavium,dma-engine-handle:
+ description: A phandle for the DMA Engine connected to this device.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ compact-flash@5,0 {
+ compatible = "cavium,ebt3000-compact-flash";
+ reg = <5 0 0x10000>, <6 0 0x10000>;
+ cavium,bus-width = <16>;
+ cavium,true-ide;
+ cavium,dma-engine-handle = <&dma0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt b/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt
deleted file mode 100644
index 3bacc8e0931e..000000000000
--- a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Compact Flash
-
-The Cavium Compact Flash device is connected to the Octeon Boot Bus,
-and is thus a child of the Boot Bus device. It can read and write
-industry standard compact flash devices.
-
-Properties:
-- compatible: "cavium,ebt3000-compact-flash";
-
- Compatibility with many Cavium evaluation boards.
-
-- reg: The base address of the CF chip select banks. Depending on
- the device configuration, there may be one or two banks.
-
-- cavium,bus-width: The width of the connection to the CF devices. Valid
- values are 8 and 16.
-
-- cavium,true-ide: Optional, if present the CF connection is in True IDE mode.
-
-- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected
- to this device.
-
-Example:
- compact-flash@5,0 {
- compatible = "cavium,ebt3000-compact-flash";
- reg = <5 0 0x10000>, <6 0 0x10000>;
- cavium,bus-width = <16>;
- cavium,true-ide;
- cavium,dma-engine-handle = <&dma0>;
- };
diff --git a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
index 9b31f864e071..c92341888a28 100644
--- a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
+++ b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ceva AHCI SATA Controller
maintainers:
- - Piyush Mehta <piyush.mehta@xilinx.com>
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
description: |
The Ceva SATA controller mostly conforms to the AHCI interface with some
@@ -32,7 +32,7 @@ properties:
maxItems: 1
iommus:
- maxItems: 1
+ maxItems: 4
power-domains:
maxItems: 1
@@ -162,11 +162,9 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/xlnx-zynqmp-power.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/phy/phy.h>
sata: ahci@fd0c0000 {
@@ -174,7 +172,7 @@ examples:
reg = <0xfd0c0000 0x200>;
interrupt-parent = <&gic>;
interrupts = <0 133 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&zynqmp_clk SATA_REF>;
+ clocks = <&zynqmp_clk 22>;
ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
diff --git a/Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml b/Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml
new file mode 100644
index 000000000000..8130923fdc72
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/cirrus,ep9312-pata.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/cirrus,ep9312-pata.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP9312 PATA controller
+
+maintainers:
+ - Damien Le Moal <dlemoal@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9312-pata
+ - items:
+ - const: cirrus,ep9315-pata
+ - const: cirrus,ep9312-pata
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ ide@800a0000 {
+ compatible = "cirrus,ep9312-pata";
+ reg = <0x800a0000 0x38>;
+ interrupt-parent = <&vic1>;
+ interrupts = <8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ide_default_pins>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml
index 21a90975593b..529093666508 100644
--- a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml
+++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml
@@ -22,7 +22,6 @@ properties:
maxItems: 1
resets:
- minItems: 2
maxItems: 2
description: phandles to the reset lines for both SATA bridges
@@ -32,7 +31,6 @@ properties:
- const: sata1
clocks:
- minItems: 2
maxItems: 2
description: phandles to the compulsory peripheral clocks
diff --git a/Documentation/devicetree/bindings/ata/eswin,eic7700-ahci.yaml b/Documentation/devicetree/bindings/ata/eswin,eic7700-ahci.yaml
new file mode 100644
index 000000000000..6554e30018b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/eswin,eic7700-ahci.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/eswin,eic7700-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Eswin EIC7700 SoC SATA Controller
+
+maintainers:
+ - Yulin Lu <luyulin@eswincomputing.com>
+ - Huan He <hehuan1@eswincomputing.com>
+
+description:
+ AHCI SATA controller embedded into the EIC7700 SoC is based on the DWC AHCI
+ SATA v5.00a IP core.
+
+select:
+ properties:
+ compatible:
+ const: eswin,eic7700-ahci
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwc-ahci-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: eswin,eic7700-ahci
+ - const: snps,dwc-ahci
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: aclk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: arst
+
+ ports-implemented:
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - ports-implemented
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sata@50420000 {
+ compatible = "eswin,eic7700-ahci", "snps,dwc-ahci";
+ reg = <0x50420000 0x10000>;
+ interrupt-parent = <&plic>;
+ interrupts = <58>;
+ clocks = <&clock 171>, <&clock 186>;
+ clock-names = "pclk", "aclk";
+ phys = <&sata_phy>;
+ phy-names = "sata-phy";
+ ports-implemented = <0x1>;
+ resets = <&reset 96>;
+ reset-names = "arst";
+ };
diff --git a/Documentation/devicetree/bindings/ata/fsl,ahci.yaml b/Documentation/devicetree/bindings/ata/fsl,ahci.yaml
new file mode 100644
index 000000000000..ea4428bc1742
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/fsl,ahci.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/fsl,ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QorIQ AHCI SATA Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - description: SATA controller for ls1012a
+ items:
+ - const: fsl,ls1012a-ahci
+ - const: fsl,ls1043a-ahci
+ - enum:
+ - fsl,ls1021a-ahci
+ - fsl,ls1028a-ahci
+ - fsl,ls1043a-ahci
+ - fsl,ls1046a-ahci
+ - fsl,ls1088a-ahci
+ - fsl,ls2080a-ahci
+ - fsl,lx2160a-ahci
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: ahci
+ - const: sata-ecc
+ minItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ sata@3200000 {
+ compatible = "fsl,ls1021a-ahci";
+ reg = <0x3200000 0x10000>;
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&platform_clk 1>;
+ dma-coherent;
+ };
diff --git a/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml b/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
new file mode 100644
index 000000000000..324e2413bba8
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/fsl,imx-pata.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX PATA Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx31-pata
+ - fsl,imx51-pata
+ - const: fsl,imx27-pata
+ - const: fsl,imx27-pata
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: PATA Controller interrupts
+
+ clocks:
+ items:
+ - description: PATA Controller clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pata: pata@83fe0000 {
+ compatible = "fsl,imx51-pata", "fsl,imx27-pata";
+ reg = <0x83fe0000 0x4000>;
+ interrupts = <70>;
+ clocks = <&clks 161>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml b/Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml
new file mode 100644
index 000000000000..1d19ee832f0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/fsl,pq-sata.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale 8xxx/3.0 Gb/s SATA nodes
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+description:
+ SATA nodes are defined to describe on-chip Serial ATA controllers.
+ Each SATA controller should have its own node.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,mpc8377-sata
+ - fsl,mpc8536-sata
+ - fsl,mpc8315-sata
+ - fsl,mpc8379-sata
+ - const: fsl,pq-sata
+ - const: fsl,pq-sata-v2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3, 4]
+ description: |
+ 1 for controller @ 0x18000
+ 2 for controller @ 0x19000
+ 3 for controller @ 0x1a000
+ 4 for controller @ 0x1b000
+
+required:
+ - compatible
+ - interrupts
+ - cell-index
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ sata@18000 {
+ compatible = "fsl,mpc8379-sata", "fsl,pq-sata";
+ reg = <0x18000 0x1000>;
+ cell-index = <1>;
+ interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/ata/fsl-sata.txt b/Documentation/devicetree/bindings/ata/fsl-sata.txt
deleted file mode 100644
index fd63bb3becc9..000000000000
--- a/Documentation/devicetree/bindings/ata/fsl-sata.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Freescale 8xxx/3.0 Gb/s SATA nodes
-
-SATA nodes are defined to describe on-chip Serial ATA controllers.
-Each SATA port should have its own node.
-
-Required properties:
-- compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-sata", where CHIP is the processor
- (mpc8315, mpc8379, etc.) and the second is
- "fsl,pq-sata"
-- interrupts : <interrupt mapping for SATA IRQ>
-- cell-index : controller index.
- 1 for controller @ 0x18000
- 2 for controller @ 0x19000
- 3 for controller @ 0x1a000
- 4 for controller @ 0x1b000
-
-Optional properties:
-- reg : <registers mapping>
-
-Example:
- sata@18000 {
- compatible = "fsl,mpc8379-sata", "fsl,pq-sata";
- reg = <0x18000 0x1000>;
- cell-index = <1>;
- interrupts = <2c 8>;
- interrupt-parent = < &ipic >;
- };
diff --git a/Documentation/devicetree/bindings/ata/imx-pata.txt b/Documentation/devicetree/bindings/ata/imx-pata.txt
deleted file mode 100644
index f1172f00188a..000000000000
--- a/Documentation/devicetree/bindings/ata/imx-pata.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* Freescale i.MX PATA Controller
-
-Required properties:
-- compatible: "fsl,imx27-pata"
-- reg: Address range of the PATA Controller
-- interrupts: The interrupt of the PATA Controller
-- clocks: the clocks for the PATA Controller
-
-Example:
-
- pata: pata@83fe0000 {
- compatible = "fsl,imx51-pata", "fsl,imx27-pata";
- reg = <0x83fe0000 0x4000>;
- interrupts = <70>;
- clocks = <&clks 161>;
- };
diff --git a/Documentation/devicetree/bindings/ata/imx-sata.yaml b/Documentation/devicetree/bindings/ata/imx-sata.yaml
index 68ffb97ddc9b..31c43374763a 100644
--- a/Documentation/devicetree/bindings/ata/imx-sata.yaml
+++ b/Documentation/devicetree/bindings/ata/imx-sata.yaml
@@ -19,6 +19,7 @@ properties:
- fsl,imx53-ahci
- fsl,imx6q-ahci
- fsl,imx6qp-ahci
+ - fsl,imx8qm-ahci
reg:
maxItems: 1
@@ -27,12 +28,14 @@ properties:
maxItems: 1
clocks:
+ minItems: 2
items:
- description: sata clock
- description: sata reference clock
- description: ahb clock
clock-names:
+ minItems: 2
items:
- const: sata
- const: sata_ref
@@ -58,6 +61,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/flag
description: if present, disable spread-spectrum clocking on the SATA link.
+ phys:
+ items:
+ - description: phandle to SATA PHY.
+ Since "REXT" pin is only present for first lane of i.MX8QM PHY, it's
+ calibration result will be stored, passed through second lane, and
+ shared with all three lanes PHY. The first two lanes PHY are used as
+ calibration PHYs, although only the third lane PHY is used by SATA.
+ - description: phandle to the first lane PHY of i.MX8QM.
+ - description: phandle to the second lane PHY of i.MX8QM.
+
+ phy-names:
+ items:
+ - const: sata-phy
+ - const: cali-phy0
+ - const: cali-phy1
+
+ power-domains:
+ maxItems: 1
+
+ target-supply:
+ description: Power regulator for the SATA target device.
+
required:
- compatible
- reg
@@ -65,6 +90,31 @@ required:
- clocks
- clock-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx53-ahci
+ - fsl,imx6q-ahci
+ - fsl,imx6qp-ahci
+ then:
+ properties:
+ clock-names:
+ minItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-ahci
+ then:
+ properties:
+ clock-names:
+ minItems: 2
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml
index 52e18600ecff..378692010c56 100644
--- a/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml
+++ b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml
@@ -35,6 +35,7 @@ required:
allOf:
- $ref: pata-common.yaml#
+ - $ref: /schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml b/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml
new file mode 100644
index 000000000000..f656ea9223d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/marvell,orion-sata.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/marvell,orion-sata.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Orion SATA
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+allOf:
+ - $ref: sata-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,orion-sata
+ - marvell,armada-370-sata
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 8
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: '0'
+ - const: '1'
+ - const: '2'
+ - const: '3'
+ - const: '4'
+ - const: '5'
+ - const: '6'
+ - const: '7'
+
+ interrupts:
+ maxItems: 1
+
+ nr-ports:
+ description:
+ Number of SATA ports in use.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 8
+
+ phys:
+ minItems: 1
+ maxItems: 8
+
+ phy-names:
+ minItems: 1
+ items:
+ - const: port0
+ - const: port1
+ - const: port2
+ - const: port3
+ - const: port4
+ - const: port5
+ - const: port6
+ - const: port7
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - nr-ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sata@80000 {
+ compatible = "marvell,orion-sata";
+ reg = <0x80000 0x5000>;
+ interrupts = <21>;
+ phys = <&sata_phy0>, <&sata_phy1>;
+ phy-names = "port0", "port1";
+ nr-ports = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/marvell.txt b/Documentation/devicetree/bindings/ata/marvell.txt
deleted file mode 100644
index b460edd12766..000000000000
--- a/Documentation/devicetree/bindings/ata/marvell.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Marvell Orion SATA
-
-Required Properties:
-- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata"
-- reg : Address range of controller
-- interrupts : Interrupt controller is using
-- nr-ports : Number of SATA ports in use.
-
-Optional Properties:
-- phys : List of phandles to sata phys
-- phy-names : Should be "0", "1", etc, one number per phandle
-
-Example:
-
- sata@80000 {
- compatible = "marvell,orion-sata";
- reg = <0x80000 0x5000>;
- interrupts = <21>;
- phys = <&sata_phy0>, <&sata_phy1>;
- phy-names = "0", "1";
- nr-ports = <2>;
- }
diff --git a/Documentation/devicetree/bindings/ata/mediatek,mtk-ahci.yaml b/Documentation/devicetree/bindings/ata/mediatek,mtk-ahci.yaml
new file mode 100644
index 000000000000..a34bd2e9c352
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/mediatek,mtk-ahci.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/mediatek,mtk-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Serial ATA controller
+
+maintainers:
+ - Ryder Lee <ryder.lee@mediatek.com>
+
+allOf:
+ - $ref: ahci-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt7622-ahci
+ - const: mediatek,mtk-ahci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: hostc
+
+ clocks:
+ maxItems: 5
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: axi
+ - const: asic
+ - const: rbc
+ - const: pm
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 3
+
+ reset-names:
+ items:
+ - const: axi
+ - const: sw
+ - const: reg
+
+ mediatek,phy-mode:
+ description: System controller phandle, used to enable SATA function
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phys
+ - phy-names
+ - ports-implemented
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt7622-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/power/mt7622-power.h>
+ #include <dt-bindings/reset/mt7622-reset.h>
+
+ sata@1a200000 {
+ compatible = "mediatek,mt7622-ahci", "mediatek,mtk-ahci";
+ reg = <0x1a200000 0x1100>;
+ interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hostc";
+ clocks = <&pciesys CLK_SATA_AHB_EN>,
+ <&pciesys CLK_SATA_AXI_EN>,
+ <&pciesys CLK_SATA_ASIC_EN>,
+ <&pciesys CLK_SATA_RBC_EN>,
+ <&pciesys CLK_SATA_PM_EN>;
+ clock-names = "ahb", "axi", "asic", "rbc", "pm";
+ phys = <&u3port1 PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ ports-implemented = <0x1>;
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ resets = <&pciesys MT7622_SATA_AXI_BUS_RST>,
+ <&pciesys MT7622_SATA_PHY_SW_RST>,
+ <&pciesys MT7622_SATA_PHY_REG_RST>;
+ reset-names = "axi", "sw", "reg";
+ mediatek,phy-mode = <&pciesys>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml
index 3c7a2425f3e6..a17297cbefcb 100644
--- a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml
+++ b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml
@@ -151,7 +151,7 @@ allOf:
- interconnects
- power-domains
-additionalProperties: true
+additionalProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/ata/pata-arasan.txt b/Documentation/devicetree/bindings/ata/pata-arasan.txt
deleted file mode 100644
index 872edc105680..000000000000
--- a/Documentation/devicetree/bindings/ata/pata-arasan.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-* ARASAN PATA COMPACT FLASH CONTROLLER
-
-Required properties:
-- compatible: "arasan,cf-spear1340"
-- reg: Address range of the CF registers
-- interrupt: Should contain the CF interrupt number
-- clock-frequency: Interface clock rate, in Hz, one of
- 25000000
- 33000000
- 40000000
- 50000000
- 66000000
- 75000000
- 100000000
- 125000000
- 150000000
- 166000000
- 200000000
-
-Optional properties:
-- arasan,broken-udma: if present, UDMA mode is unusable
-- arasan,broken-mwdma: if present, MWDMA mode is unusable
-- arasan,broken-pio: if present, PIO mode is unusable
-- dmas: one DMA channel, as described in bindings/dma/dma.txt
- required unless both UDMA and MWDMA mode are broken
-- dma-names: the corresponding channel name, must be "data"
-
-Example:
-
- cf@fc000000 {
- compatible = "arasan,cf-spear1340";
- reg = <0xfc000000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <12>;
- dmas = <&dma-controller 23>;
- dma-names = "data";
- };
diff --git a/Documentation/devicetree/bindings/ata/pata-common.yaml b/Documentation/devicetree/bindings/ata/pata-common.yaml
index 2412894a255d..4e867dd4d402 100644
--- a/Documentation/devicetree/bindings/ata/pata-common.yaml
+++ b/Documentation/devicetree/bindings/ata/pata-common.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
This document defines device tree properties common to most Parallel
ATA (PATA, also known as IDE) AT attachment storage devices.
- It doesn't constitue a device tree binding specification by itself but is
+ It doesn't constitute a device tree binding specification by itself but is
meant to be referenced by device tree bindings.
The PATA (IDE) controller-specific device tree bindings are responsible for
@@ -38,6 +38,7 @@ patternProperties:
ID number 0 and the slave drive will have ID number 1. The PATA port
nodes will be named "ide-port".
type: object
+ additionalProperties: false
properties:
reg:
diff --git a/Documentation/devicetree/bindings/ata/qcom-sata.txt b/Documentation/devicetree/bindings/ata/qcom-sata.txt
deleted file mode 100644
index 094de91cd9fd..000000000000
--- a/Documentation/devicetree/bindings/ata/qcom-sata.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-* Qualcomm AHCI SATA Controller
-
-SATA nodes are defined to describe on-chip Serial ATA controllers.
-Each SATA controller should have its own node.
-
-Required properties:
-- compatible : compatible list, must contain "generic-ahci"
-- interrupts : <interrupt mapping for SATA IRQ>
-- reg : <registers mapping>
-- phys : Must contain exactly one entry as specified
- in phy-bindings.txt
-- phy-names : Must be "sata-phy"
-
-Required properties for "qcom,ipq806x-ahci" compatible:
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names : Shall be:
- "slave_iface" - Fabric port AHB clock for SATA
- "iface" - AHB clock
- "core" - core clock
- "rxoob" - RX out-of-band clock
- "pmalive" - Power Module Alive clock
-- assigned-clocks : Shall be:
- SATA_RXOOB_CLK
- SATA_PMALIVE_CLK
-- assigned-clock-rates : Shall be:
- 100Mhz (100000000) for SATA_RXOOB_CLK
- 100Mhz (100000000) for SATA_PMALIVE_CLK
-
-Example:
- sata@29000000 {
- compatible = "qcom,ipq806x-ahci", "generic-ahci";
- reg = <0x29000000 0x180>;
-
- interrupts = <0 209 0x0>;
-
- clocks = <&gcc SFAB_SATA_S_H_CLK>,
- <&gcc SATA_H_CLK>,
- <&gcc SATA_A_CLK>,
- <&gcc SATA_RXOOB_CLK>,
- <&gcc SATA_PMALIVE_CLK>;
- clock-names = "slave_iface", "iface", "core",
- "rxoob", "pmalive";
- assigned-clocks = <&gcc SATA_RXOOB_CLK>, <&gcc SATA_PMALIVE_CLK>;
- assigned-clock-rates = <100000000>, <100000000>;
-
- phys = <&sata_phy>;
- phy-names = "sata-phy";
- };
diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
index c4e4a9eab658..fe0909554790 100644
--- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
+++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car Serial-ATA Interface
diff --git a/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
new file mode 100644
index 000000000000..b5ecaabfe2e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/rockchip,dwc-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DWC AHCI SATA controller for Rockchip devices
+
+maintainers:
+ - Serge Semin <fancer.lancer@gmail.com>
+
+description:
+ This document defines device tree bindings for the Synopsys DWC
+ implementation of the AHCI SATA controller found in Rockchip
+ devices.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-dwc-ahci
+ - rockchip,rk3576-dwc-ahci
+ - rockchip,rk3588-dwc-ahci
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - rockchip,rk3568-dwc-ahci
+ - rockchip,rk3576-dwc-ahci
+ - rockchip,rk3588-dwc-ahci
+ - const: snps,dwc-ahci
+
+ ports-implemented:
+ const: 1
+
+ power-domains:
+ maxItems: 1
+
+ sata-port@0:
+ $ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port
+
+ properties:
+ reg:
+ const: 0
+
+ unevaluatedProperties: false
+
+patternProperties:
+ "^sata-port@[1-9a-e]$": false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports-implemented
+
+allOf:
+ - $ref: snps,dwc-ahci-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3588-dwc-ahci
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ items:
+ - const: sata
+ - const: pmalive
+ - const: rxoob
+ - const: ref
+ - const: asic
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-dwc-ahci
+ - rockchip,rk3576-dwc-ahci
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: sata
+ - const: pmalive
+ - const: rxoob
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/ata/ahci.h>
+ #include <dt-bindings/phy/phy.h>
+
+ sata@fe210000 {
+ compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci";
+ reg = <0xfe210000 0x1000>;
+ clocks = <&cru ACLK_SATA0>, <&cru CLK_PMALIVE0>,
+ <&cru CLK_RXOOB0>, <&cru CLK_PIPEPHY0_REF>,
+ <&cru CLK_PIPEPHY0_PIPE_ASIC_G>;
+ clock-names = "sata", "pmalive", "rxoob", "ref", "asic";
+ interrupts = <GIC_SPI 273 IRQ_TYPE_LEVEL_HIGH 0>;
+ ports-implemented = <0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata-port@0 {
+ reg = <0>;
+ hba-port-cap = <HBA_PORT_FBSCP>;
+ phys = <&combphy0_ps PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ snps,rx-ts-max = <32>;
+ snps,tx-ts-max = <32>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml b/Documentation/devicetree/bindings/ata/sata_highbank.yaml
index 49679b58041c..48bdca0f5577 100644
--- a/Documentation/devicetree/bindings/ata/sata_highbank.yaml
+++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml
@@ -52,7 +52,6 @@ properties:
minItems: 1
maxItems: 8
items:
- minItems: 2
maxItems: 2
calxeda,tx-atten:
@@ -86,7 +85,7 @@ examples:
dma-coherent;
calxeda,port-phys = <&combophy5 0>, <&combophy0 0>, <&combophy0 1>,
<&combophy0 2>, <&combophy0 3>;
- calxeda,sgpio-gpio =<&gpioh 5 1>, <&gpioh 6 1>, <&gpioh 7 1>;
+ calxeda,sgpio-gpio = <&gpioh 5 1>, <&gpioh 6 1>, <&gpioh 7 1>;
calxeda,led-order = <4 0 1 2 3>;
calxeda,tx-atten = <0xff 22 0xff 0xff 23>;
calxeda,pre-clocks = <10>;
diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml
index c1457910520b..34c5bf65b02d 100644
--- a/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml
+++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci-common.yaml
@@ -31,11 +31,11 @@ properties:
PM-alive clock, RxOOB detection clock, embedded PHYs reference (Rx/Tx)
clock, etc.
minItems: 1
- maxItems: 4
+ maxItems: 6
clock-names:
minItems: 1
- maxItems: 4
+ maxItems: 6
items:
oneOf:
- description: Application APB/AHB/AXI BIU clock
@@ -48,6 +48,10 @@ properties:
const: pmalive
- description: RxOOB detection clock
const: rxoob
+ - description: PHY Transmit Clock
+ const: asic
+ - description: PHY Receive Clock
+ const: rbc
- description: SATA Ports reference clock
const: ref
diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
index 5afa4b57ce20..7707cbed2260 100644
--- a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
+++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
@@ -13,6 +13,15 @@ description:
This document defines device tree bindings for the generic Synopsys DWC
implementation of the AHCI SATA controller.
+select:
+ properties:
+ compatible:
+ enum:
+ - snps,dwc-ahci
+ - snps,spear-ahci
+ required:
+ - compatible
+
allOf:
- $ref: snps,dwc-ahci-common.yaml#
@@ -23,10 +32,10 @@ properties:
const: snps,dwc-ahci
- description: SPEAr1340 AHCI SATA device
const: snps,spear-ahci
- - description: Rockhip RK3568 AHCI controller
- items:
- - const: rockchip,rk3568-dwc-ahci
- - const: snps,dwc-ahci
+
+ iommus:
+ minItems: 1
+ maxItems: 3
patternProperties:
"^sata-port@[0-9a-e]$":
diff --git a/Documentation/devicetree/bindings/ata/st,ahci.yaml b/Documentation/devicetree/bindings/ata/st,ahci.yaml
new file mode 100644
index 000000000000..6e8e4b4f3d6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/st,ahci.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/st,ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi SATA controller
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: ahci-common.yaml#
+
+properties:
+ compatible:
+ const: st,ahci
+
+ interrupt-names:
+ items:
+ - const: hostc
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ahci_clk
+
+ resets:
+ items:
+ - description: Power-down line
+ - description: Soft-reset line
+ - description: Power-reset line
+
+ reset-names:
+ items:
+ - const: pwr-dwn
+ - const: sw-rst
+ - const: pwr-rst
+
+required:
+ - compatible
+ - interrupt-names
+ - phys
+ - phy-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/reset/stih407-resets.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+
+ sata@9b20000 {
+ compatible = "st,ahci";
+ reg = <0x9b20000 0x1000>;
+ interrupts = <GIC_SPI 159 IRQ_TYPE_NONE>;
+ interrupt-names = "hostc";
+ phys = <&phy_port0 PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ resets = <&powerdown STIH407_SATA0_POWERDOWN>,
+ <&softreset STIH407_SATA0_SOFTRESET>,
+ <&softreset STIH407_SATA0_PWR_SOFTRESET>;
+ reset-names = "pwr-dwn", "sw-rst", "pwr-rst";
+ clocks = <&clk_s_c0_flexgen CLK_ICN_REG>;
+ clock-names = "ahci_clk";
+ };
diff --git a/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
new file mode 100644
index 000000000000..ce13c76bdffb
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/ti,da850-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DA850 AHCI SATA Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: ti,da850-ahci
+
+ reg:
+ items:
+ - description: Address and size of the register map as defined by the AHCI 1.1 standard.
+ - description:
+ Address and size of Power Down Control Register (PWRDN) for enabling/disabling the SATA clock
+ receiver.
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ sata@218000 {
+ compatible = "ti,da850-ahci";
+ reg = <0x218000 0x2000>, <0x22c018 0x4>;
+ interrupts = <67>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml b/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml
new file mode 100644
index 000000000000..d0ff9e78afe6
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ti,dm816-ahci.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/ti,dm816-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DM816 AHCI SATA Controller
+
+maintainers:
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+
+allOf:
+ - $ref: ahci-common.yaml#
+
+properties:
+ compatible:
+ const: ti,dm816-ahci
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: functional clock
+ - description: external reference clock
+
+ ti,hwmods:
+ const: sata
+
+required:
+ - compatible
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sata@4a140000 {
+ compatible = "ti,dm816-ahci";
+ reg = <0x4a140000 0x10000>;
+ interrupts = <16>;
+ clocks = <&sysclk5_ck>, <&sata_refclk>;
+ };
diff --git a/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml b/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml
index 5d02bd032a85..439f7b811a94 100644
--- a/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml
@@ -39,6 +39,6 @@ additionalProperties: false
examples:
- |
lcd@10008000 {
- compatible = "arm,versatile-lcd";
- reg = <0x10008000 0x1000>;
+ compatible = "arm,versatile-lcd";
+ reg = <0x10008000 0x1000>;
};
diff --git a/Documentation/devicetree/bindings/auxdisplay/gpio-7-segment.yaml b/Documentation/devicetree/bindings/auxdisplay/gpio-7-segment.yaml
new file mode 100644
index 000000000000..328954893c64
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/gpio-7-segment.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/gpio-7-segment.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO based LED segment display
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+properties:
+ compatible:
+ const: gpio-7-segment
+
+ segment-gpios:
+ description: |
+ An array of GPIOs one per segment. The first GPIO corresponds to the A
+ segment, the seventh GPIO corresponds to the G segment. Some LED blocks
+ also have a decimal point which can be specified as an optional eighth
+ segment.
+
+ -a-
+ | |
+ f b
+ | |
+ -g-
+ | |
+ e c
+ | |
+ -d- dp
+
+ minItems: 7
+ maxItems: 8
+
+required:
+ - segment-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+
+ #include <dt-bindings/gpio/gpio.h>
+
+ led-7seg {
+ compatible = "gpio-7-segment";
+ segment-gpios = <&gpio 0 GPIO_ACTIVE_LOW>,
+ <&gpio 1 GPIO_ACTIVE_LOW>,
+ <&gpio 2 GPIO_ACTIVE_LOW>,
+ <&gpio 3 GPIO_ACTIVE_LOW>,
+ <&gpio 4 GPIO_ACTIVE_LOW>,
+ <&gpio 5 GPIO_ACTIVE_LOW>,
+ <&gpio 6 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
index fde07e4b119d..3ca0e9863d83 100644
--- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
@@ -84,42 +84,44 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- auxdisplay {
- compatible = "hit,hd44780";
-
- data-gpios = <&hc595 0 GPIO_ACTIVE_HIGH>,
- <&hc595 1 GPIO_ACTIVE_HIGH>,
- <&hc595 2 GPIO_ACTIVE_HIGH>,
- <&hc595 3 GPIO_ACTIVE_HIGH>;
- enable-gpios = <&hc595 4 GPIO_ACTIVE_HIGH>;
- rs-gpios = <&hc595 5 GPIO_ACTIVE_HIGH>;
-
- display-height-chars = <2>;
- display-width-chars = <16>;
+ display-controller {
+ compatible = "hit,hd44780";
+
+ data-gpios = <&hc595 0 GPIO_ACTIVE_HIGH>,
+ <&hc595 1 GPIO_ACTIVE_HIGH>,
+ <&hc595 2 GPIO_ACTIVE_HIGH>,
+ <&hc595 3 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&hc595 4 GPIO_ACTIVE_HIGH>;
+ rs-gpios = <&hc595 5 GPIO_ACTIVE_HIGH>;
+
+ display-height-chars = <2>;
+ display-width-chars = <16>;
};
+
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pcf8574: pcf8574@27 {
- compatible = "nxp,pcf8574";
- reg = <0x27>;
- gpio-controller;
- #gpio-cells = <2>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcf8574: gpio-expander@27 {
+ compatible = "nxp,pcf8574";
+ reg = <0x27>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
- hd44780 {
- compatible = "hit,hd44780";
- display-height-chars = <2>;
- display-width-chars = <16>;
- data-gpios = <&pcf8574 4 0>,
- <&pcf8574 5 0>,
- <&pcf8574 6 0>,
- <&pcf8574 7 0>;
- enable-gpios = <&pcf8574 2 0>;
- rs-gpios = <&pcf8574 0 0>;
- rw-gpios = <&pcf8574 1 0>;
- backlight-gpios = <&pcf8574 3 0>;
+
+ display-controller {
+ compatible = "hit,hd44780";
+ display-height-chars = <2>;
+ display-width-chars = <16>;
+ data-gpios = <&pcf8574 4 GPIO_ACTIVE_HIGH>,
+ <&pcf8574 5 GPIO_ACTIVE_HIGH>,
+ <&pcf8574 6 GPIO_ACTIVE_HIGH>,
+ <&pcf8574 7 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&pcf8574 2 GPIO_ACTIVE_HIGH>;
+ rs-gpios = <&pcf8574 0 GPIO_ACTIVE_HIGH>;
+ rw-gpios = <&pcf8574 1 GPIO_ACTIVE_HIGH>;
+ backlight-gpios = <&pcf8574 3 GPIO_ACTIVE_HIGH>;
};
diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
index fc4873deb76f..b90eec2077b4 100644
--- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
@@ -10,7 +10,7 @@ maintainers:
- Robin van der Gracht <robin@protonic.nl>
allOf:
- - $ref: "/schemas/input/matrix-keymap.yaml#"
+ - $ref: /schemas/input/matrix-keymap.yaml#
properties:
compatible:
@@ -40,6 +40,7 @@ properties:
linux,keymap: true
linux,no-autorepeat:
+ type: boolean
description: Disable keyrepeat
default-brightness-level:
@@ -72,32 +73,32 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
- i2c1 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ht16k33: ht16k33@70 {
- compatible = "holtek,ht16k33";
- reg = <0x70>;
- refresh-rate-hz = <20>;
- interrupt-parent = <&gpio4>;
- interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
- debounce-delay-ms = <50>;
- linux,keymap = <MATRIX_KEY(2, 0, KEY_F6)>,
- <MATRIX_KEY(3, 0, KEY_F8)>,
- <MATRIX_KEY(4, 0, KEY_F10)>,
- <MATRIX_KEY(5, 0, KEY_F4)>,
- <MATRIX_KEY(6, 0, KEY_F2)>,
- <MATRIX_KEY(2, 1, KEY_F5)>,
- <MATRIX_KEY(3, 1, KEY_F7)>,
- <MATRIX_KEY(4, 1, KEY_F9)>,
- <MATRIX_KEY(5, 1, KEY_F3)>,
- <MATRIX_KEY(6, 1, KEY_F1)>;
-
- led {
- color = <LED_COLOR_ID_RED>;
- function = LED_FUNCTION_BACKLIGHT;
- linux,default-trigger = "backlight";
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display-controller@70 {
+ compatible = "holtek,ht16k33";
+ reg = <0x70>;
+ refresh-rate-hz = <20>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+ debounce-delay-ms = <50>;
+ linux,keymap = <MATRIX_KEY(2, 0, KEY_F6)>,
+ <MATRIX_KEY(3, 0, KEY_F8)>,
+ <MATRIX_KEY(4, 0, KEY_F10)>,
+ <MATRIX_KEY(5, 0, KEY_F4)>,
+ <MATRIX_KEY(6, 0, KEY_F2)>,
+ <MATRIX_KEY(2, 1, KEY_F5)>,
+ <MATRIX_KEY(3, 1, KEY_F7)>,
+ <MATRIX_KEY(4, 1, KEY_F9)>,
+ <MATRIX_KEY(5, 1, KEY_F3)>,
+ <MATRIX_KEY(6, 1, KEY_F1)>;
+
+ led {
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_BACKLIGHT;
+ linux,default-trigger = "backlight";
};
- };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml b/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml
index 1899b23de7d1..55e9831b3f67 100644
--- a/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml
@@ -50,6 +50,6 @@ additionalProperties: false
examples:
- |
lcd: lcd@17fff000 {
- compatible = "img,boston-lcd";
- reg = <0x17fff000 0x8>;
+ compatible = "img,boston-lcd";
+ reg = <0x17fff000 0x8>;
};
diff --git a/Documentation/devicetree/bindings/auxdisplay/maxim,max6959.yaml b/Documentation/devicetree/bindings/auxdisplay/maxim,max6959.yaml
new file mode 100644
index 000000000000..20dd9e8c8190
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/maxim,max6959.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/maxim,max6959.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX6958/6959 7-segment LED display controller
+
+maintainers:
+ - Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+description:
+ The Maxim MAX6958/6959 7-segment LED display controller provides
+ an I2C interface to up to four 7-segment LED digits. The MAX6959,
+ in comparison to MAX6958, adds input support. Type of the chip can
+ be autodetected via specific register read, and hence the features
+ may be enabled in the driver at run-time, in case they are requested
+ via Device Tree. A given hardware is simple and does not provide
+ any additional pins, such as reset or power enable.
+
+properties:
+ compatible:
+ const: maxim,max6959
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display-controller@38 {
+ compatible = "maxim,max6959";
+ reg = <0x38>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/board/fsl,bcsr.yaml b/Documentation/devicetree/bindings/board/fsl,bcsr.yaml
new file mode 100644
index 000000000000..df3dd8399671
--- /dev/null
+++ b/Documentation/devicetree/bindings/board/fsl,bcsr.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/board/fsl,bcsr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Board Control and Status
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,mpc8360mds-bcsr
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ board@f8000000 {
+ compatible = "fsl,mpc8360mds-bcsr";
+ reg = <0xf8000000 0x8000>;
+ };
+
diff --git a/Documentation/devicetree/bindings/board/fsl,fpga-qixis-i2c.yaml b/Documentation/devicetree/bindings/board/fsl,fpga-qixis-i2c.yaml
new file mode 100644
index 000000000000..e889dac052e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/board/fsl,fpga-qixis-i2c.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/board/fsl,fpga-qixis-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale on-board FPGA connected on I2C bus
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,bsc9132qds-fpga
+ - const: fsl,fpga-qixis-i2c
+ - items:
+ - enum:
+ - fsl,ls1028aqds-fpga
+ - fsl,lx2160aqds-fpga
+ - const: fsl,fpga-qixis-i2c
+ - const: simple-mfd
+ - const: fsl,lx2160ardb-fpga
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ mux-controller:
+ $ref: /schemas/mux/reg-mux.yaml
+
+patternProperties:
+ "^gpio@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,lx2160ardb-fpga-gpio-sfp
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,lx2160ardb-fpga
+ then:
+ required:
+ - "#address-cells"
+ - "#size-cells"
+ else:
+ properties:
+ "#address-cells": false
+ "#size-cells": false
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ board-control@66 {
+ compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ };
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ board-control@66 {
+ compatible = "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c",
+ "simple-mfd";
+ reg = <0x66>;
+
+ mux-controller {
+ compatible = "reg-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x54 0xf0>; /* 0: reg 0x54, bits 7:4 */
+ };
+ };
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ board-control@66 {
+ compatible = "fsl,lx2160ardb-fpga";
+ reg = <0x66>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@19 {
+ compatible = "fsl,lx2160ardb-fpga-gpio-sfp";
+ reg = <0x19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "SFP2_TX_EN", "",
+ "", "",
+ "SFP2_RX_LOS", "SFP2_TX_FAULT",
+ "", "SFP2_MOD_ABS";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/board/fsl,fpga-qixis.yaml b/Documentation/devicetree/bindings/board/fsl,fpga-qixis.yaml
new file mode 100644
index 000000000000..2eacb581b9fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/board/fsl,fpga-qixis.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/board/fsl,fpga-qixis.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale on-board FPGA/CPLD
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,p1022ds-fpga
+ - const: fsl,fpga-ngpixis
+ - items:
+ - enum:
+ - fsl,ls1088aqds-fpga
+ - fsl,ls1088ardb-fpga
+ - fsl,ls2080aqds-fpga
+ - fsl,ls2080ardb-fpga
+ - const: fsl,fpga-qixis
+ - items:
+ - enum:
+ - fsl,ls1043aqds-fpga
+ - fsl,ls1043ardb-fpga
+ - fsl,ls1046aqds-fpga
+ - fsl,ls1046ardb-fpga
+ - fsl,ls208xaqds-fpga
+ - const: fsl,fpga-qixis
+ - const: simple-mfd
+ - enum:
+ - fsl,ls1043ardb-cpld
+ - fsl,ls1046ardb-cpld
+ - fsl,t1040rdb-cpld
+ - fsl,t1042rdb-cpld
+ - fsl,t1042rdb_pi-cpld
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges:
+ maxItems: 1
+
+patternProperties:
+ '^mdio-mux@[a-f0-9,]+$':
+ $ref: /schemas/net/mdio-mux-mmioreg.yaml
+
+ '^gpio@[0-9a-f]+$':
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,ls1046aqds-fpga-gpio-stat-pres2
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ board-control@3 {
+ compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
+ reg = <3 0x30>;
+ interrupt-parent = <&mpic>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW 0 0>;
+ };
+
+ - |
+ board-control@3 {
+ compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
+ reg = <0x3 0x10000>;
+ };
+
diff --git a/Documentation/devicetree/bindings/board/fsl-board.txt b/Documentation/devicetree/bindings/board/fsl-board.txt
deleted file mode 100644
index 9cde57015921..000000000000
--- a/Documentation/devicetree/bindings/board/fsl-board.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-Freescale Reference Board Bindings
-
-This document describes device tree bindings for various devices that
-exist on some Freescale reference boards.
-
-* Board Control and Status (BCSR)
-
-Required properties:
-
- - compatible : Should be "fsl,<board>-bcsr"
- - reg : Offset and length of the register set for the device
-
-Example:
-
- bcsr@f8000000 {
- compatible = "fsl,mpc8360mds-bcsr";
- reg = <f8000000 8000>;
- };
-
-* Freescale on-board FPGA
-
-This is the memory-mapped registers for on board FPGA.
-
-Required properties:
-- compatible: should be a board-specific string followed by a string
- indicating the type of FPGA. Example:
- "fsl,<board>-fpga", "fsl,fpga-pixis", or
- "fsl,<board>-fpga", "fsl,fpga-qixis"
-- reg: should contain the address and the length of the FPGA register set.
-
-Optional properties:
-- interrupts: should specify event (wakeup) IRQ.
-
-Example (P1022DS):
-
- board-control@3,0 {
- compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
- reg = <3 0 0x30>;
- interrupt-parent = <&mpic>;
- interrupts = <8 8 0 0>;
- };
-
-Example (LS2080A-RDB):
-
- cpld@3,0 {
- compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
- reg = <0x3 0 0x10000>;
- };
-
-* Freescale on-board FPGA connected on I2C bus
-
-Some Freescale boards like BSC9132QDS have on board FPGA connected on
-the i2c bus.
-
-Required properties:
-- compatible: Should be a board-specific string followed by a string
- indicating the type of FPGA. Example:
- "fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
-- reg: Should contain the address of the FPGA
-
-Example:
- fpga: fpga@66 {
- compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
- reg = <0x66>;
- };
-
-* Freescale on-board CPLD
-
-Some Freescale boards like T1040RDB have an on board CPLD connected.
-
-Required properties:
-- compatible: Should be a board-specific string like "fsl,<board>-cpld"
- Example:
- "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld"
-- reg: should describe CPLD registers
-
-Example:
- cpld@3,0 {
- compatible = "fsl,t1040rdb-cpld";
- reg = <3 0 0x300>;
- };
diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
index ad313ccaaaef..232252e8825e 100644
--- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
+++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/bus/allwinner,sun50i-a64-de2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A64 Display Engine Bus Device Tree Bindings
+title: Allwinner A64 Display Engine Bus
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -44,8 +44,9 @@ properties:
patternProperties:
# All other properties should be child nodes with unit-address and 'reg'
- "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$":
+ "@[0-9a-f]+$":
type: object
+ additionalProperties: true
properties:
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml
index 3d719f468a5b..cd5c2a532a92 100644
--- a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml
+++ b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/bus/allwinner,sun8i-a23-rsb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A23 RSB Device Tree Bindings
+title: Allwinner A23 RSB
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -43,8 +43,9 @@ properties:
maximum: 20000000
patternProperties:
- "^.*@[0-9a-fA-F]+$":
+ "@[0-9a-f]+$":
type: object
+ additionalProperties: true
properties:
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml b/Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml
new file mode 100644
index 000000000000..2894256c976d
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/aspeed,ast2600-ahbc.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/aspeed,ast2600-ahbc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED Advanced High-Performance Bus Controller (AHBC)
+
+maintainers:
+ - Neal Liu <neal_liu@aspeedtech.com>
+ - Chia-Wei Wang <chiawei_wang@aspeedtech.com>
+
+description: |
+ Advanced High-performance Bus Controller (AHBC) supports plenty of mechanisms
+ including a priority arbiter, an address decoder and a data multiplexer
+ to control the overall operations of Advanced High-performance Bus (AHB).
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-ahbc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ ahbc@1e600000 {
+ compatible = "aspeed,ast2600-ahbc";
+ reg = <0x1e600000 0x100>;
+ };
diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml
index b23c3001991e..9017c5a3f3d2 100644
--- a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml
+++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml
@@ -18,6 +18,7 @@ properties:
- const: brcm,gisb-arb
- items:
- enum:
+ - brcm,bcm74165-gisb-arb # for V7 new style 16nm chips
- brcm,bcm7278-gisb-arb # for V7 28nm chips
- brcm,bcm7435-gisb-arb # for newer 40nm chips
- brcm,bcm7400-gisb-arb # for older 40nm chips and all 65nm chips
@@ -43,7 +44,7 @@ properties:
brcm,gisb-arb-master-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: >
- String list of the litteral name of the GISB masters. Should match the
+ String list of the literal name of the GISB masters. Should match the
number of bits set in brcm,gisb-master-mask and the order in which they
appear from MSB to LSB.
diff --git a/Documentation/devicetree/bindings/bus/cznic,moxtet.yaml b/Documentation/devicetree/bindings/bus/cznic,moxtet.yaml
new file mode 100644
index 000000000000..d340899ca5f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/cznic,moxtet.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/cznic,moxtet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Turris Moxtet SPI bus
+
+maintainers:
+ - Marek Behún <kabel@kernel.org>
+
+description: >
+ Turris Mox module status and configuration bus (over SPI)
+
+ The driver finds the devices connected to the bus by itself, but it may be
+ needed to reference some of them from other parts of the device tree. In that
+ case the devices can be defined as subnodes of the moxtet node.
+
+properties:
+ compatible:
+ const: cznic,moxtet
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ spi-cpol: true
+
+ spi-cpha: true
+
+ spi-max-frequency: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - spi-cpol
+ - spi-cpha
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties:
+ type: object
+
+ required:
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ moxtet@1 {
+ compatible = "cznic,moxtet";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ spi-max-frequency = <10000000>;
+ spi-cpol;
+ spi-cpha;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gpiosb>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ gpio@0 {
+ compatible = "cznic,moxtet-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml b/Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
new file mode 100644
index 000000000000..993293ebc4d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/fsl,imx8mp-aipstz.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/fsl,imx8mp-aipstz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Secure AHB to IP Slave bus (AIPSTZ) bridge
+
+description:
+ The secure AIPS bridge (AIPSTZ) acts as a bridge for AHB masters issuing
+ transactions to IP Slave peripherals. Additionally, this module offers access
+ control configurations meant to restrict which peripherals a master can
+ access.
+
+maintainers:
+ - Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8mp-aipstz
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ "#access-controller-cells":
+ const: 3
+ description:
+ First cell - consumer ID
+ Second cell - consumer type (master or peripheral)
+ Third cell - configuration value
+
+ ranges: true
+
+# borrowed from simple-bus.yaml, no additional requirements for children
+patternProperties:
+ "@(0|[1-9a-f][0-9a-f]*)$":
+ type: object
+ additionalProperties: true
+ properties:
+ reg:
+ items:
+ minItems: 2
+ maxItems: 4
+ minItems: 1
+ maxItems: 1024
+ ranges:
+ oneOf:
+ - items:
+ minItems: 3
+ maxItems: 7
+ minItems: 1
+ maxItems: 1024
+ - $ref: /schemas/types.yaml#/definitions/flag
+ anyOf:
+ - required:
+ - reg
+ - required:
+ - ranges
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - "#access-controller-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus@30df0000 {
+ compatible = "fsl,imx8mp-aipstz";
+ reg = <0x30df0000 0x10000>;
+ ranges = <0x30c00000 0x30c00000 0x400000>;
+ power-domains = <&pgc_audio>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #access-controller-cells = <3>;
+
+ dma-controller@30e00000 {
+ compatible = "fsl,imx8mp-sdma", "fsl,imx8mq-sdma";
+ reg = <0x30e00000 0x10000>;
+ #dma-cells = <3>;
+ clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>,
+ <&clk IMX8MP_CLK_AUDIO_ROOT>;
+ clock-names = "ipg", "ahb";
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/fsl,imx8qxp-pixel-link-msi-bus.yaml b/Documentation/devicetree/bindings/bus/fsl,imx8qxp-pixel-link-msi-bus.yaml
new file mode 100644
index 000000000000..6645352c7f6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/fsl,imx8qxp-pixel-link-msi-bus.yaml
@@ -0,0 +1,232 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/fsl,imx8qxp-pixel-link-msi-bus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Pixel Link Medium Speed Interconnect (MSI) Bus
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+description: |
+ i.MX8qxp pixel link MSI bus is used to control settings of PHYs, I/Os
+ sitting together with the PHYs. It is not the same as the MSI bus coming
+ from i.MX8 System Controller Unit (SCU) which is used to control power,
+ clock and reset through the i.MX8 Distributed Slave System Controller (DSC).
+
+ i.MX8qxp pixel link MSI bus is a simple memory-mapped bus. Two input clocks,
+ that is, MSI clock and AHB clock, need to be enabled so that peripherals
+ connected to the bus can be accessed. Also, the bus is part of a power
+ domain. The power domain needs to be enabled before the peripherals can
+ be accessed.
+
+ Peripherals in i.MX8qm/qxp imaging, LVDS, MIPI DSI and HDMI TX subsystems,
+ like I2C controller, PWM controller, MIPI DSI controller and Control and
+ Status Registers (CSR) module, are accessed through the bus.
+
+ The i.MX System Controller Firmware (SCFW) owns and uses the i.MX8qm/qxp
+ pixel link MSI bus controller and does not allow SCFW user to control it.
+ So, the controller's registers cannot be accessed by SCFW user. Hence,
+ the interrupts generated by the controller don't make any sense from SCFW
+ user's point of view.
+
+allOf:
+ - $ref: simple-pm-bus.yaml#
+
+# We need a select here so we don't match all nodes with 'simple-pm-bus'.
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-display-pixel-link-msi-bus
+ - fsl,imx8qm-display-pixel-link-msi-bus
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,imx8qxp-display-pixel-link-msi-bus
+ - fsl,imx8qm-display-pixel-link-msi-bus
+ - const: simple-pm-bus
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: master gated clock from system
+ - description: AHB clock
+
+ clock-names:
+ items:
+ - const: msi
+ - const: ahb
+
+patternProperties:
+ "@[0-9a-f]+$":
+ description: Devices attached to the bus
+ type: object
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ bus@56200000 {
+ compatible = "fsl,imx8qxp-display-pixel-link-msi-bus", "simple-pm-bus";
+ reg = <0x56200000 0x20000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&dc0_irqsteer>;
+ interrupts = <320>;
+ ranges;
+ clocks = <&dc0_disp_ctrl_link_mst0_lpcg IMX_LPCG_CLK_4>,
+ <&dc0_disp_ctrl_link_mst0_lpcg IMX_LPCG_CLK_4>;
+ clock-names = "msi", "ahb";
+ power-domains = <&pd IMX_SC_R_DC_0>;
+
+ bus@56221000 {
+ compatible = "simple-pm-bus", "syscon";
+ reg = <0x56221000 0x1000>;
+ clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
+ clock-names = "ipg";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pxl2dpi {
+ compatible = "fsl,imx8qxp-pxl2dpi";
+ fsl,sc-resource = <IMX_SC_R_MIPI_0>;
+ power-domains = <&pd IMX_SC_R_MIPI_0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dc0_pixel_link0_mipi_lvds_0_pxl2dpi>;
+ };
+
+ mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dc0_pixel_link1_mipi_lvds_0_pxl2dpi>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+ };
+
+ mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+ };
+ };
+ };
+ };
+
+ ldb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8qxp-ldb";
+ clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+ clock-names = "pixel", "bypass";
+ power-domains = <&pd IMX_SC_R_LVDS_0>;
+
+ channel@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ phys = <&mipi_lvds_0_phy>;
+ phy-names = "lvds_phy";
+
+ port@0 {
+ reg = <0>;
+
+ mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
+ remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ /* ... */
+ };
+ };
+
+ channel@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ phys = <&mipi_lvds_0_phy>;
+ phy-names = "lvds_phy";
+
+ port@0 {
+ reg = <0>;
+
+ mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi: endpoint {
+ remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ /* ... */
+ };
+ };
+ };
+ };
+
+ clock-controller@56223004 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x56223004 0x4>;
+ #clock-cells = <1>;
+ clocks = <&mipi_lvds_0_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_4>;
+ clock-output-names = "mipi_lvds_0_di_mipi_lvds_regs_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_MIPI_0>;
+ };
+
+ phy@56228300 {
+ compatible = "fsl,imx8qxp-mipi-dphy";
+ reg = <0x56228300 0x100>;
+ clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_PHY>;
+ clock-names = "phy_ref";
+ #phy-cells = <0>;
+ fsl,syscon = <&mipi_lvds_0_csr>;
+ power-domains = <&pd IMX_SC_R_MIPI_0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
deleted file mode 100644
index e7f502070d77..000000000000
--- a/Documentation/devicetree/bindings/bus/imx-weim.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-Device tree bindings for i.MX Wireless External Interface Module (WEIM)
-
-The term "wireless" does not imply that the WEIM is literally an interface
-without wires. It simply means that this module was originally designed for
-wireless and mobile applications that use low-power technology.
-
-The actual devices are instantiated from the child nodes of a WEIM node.
-
-Required properties:
-
- - compatible: Should contain one of the following:
- "fsl,imx1-weim"
- "fsl,imx27-weim"
- "fsl,imx51-weim"
- "fsl,imx50-weim"
- "fsl,imx6q-weim"
- - reg: A resource specifier for the register space
- (see the example below)
- - clocks: the clock, see the example below.
- - #address-cells: Must be set to 2 to allow memory address translation
- - #size-cells: Must be set to 1 to allow CS address passing
- - ranges: Must be set up to reflect the memory layout with four
- integer values for each chip-select line in use:
-
- <cs-number> 0 <physical address of mapping> <size>
-
-Optional properties:
-
- - fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
- devices, it should be the phandle to the system General
- Purpose Register controller that contains WEIM CS GPR
- register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0]
- should be set up as one of the following 4 possible
- values depending on the CS space configuration.
-
- IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3
- ---------------------------------------------
- 05 128M 0M 0M 0M
- 033 64M 64M 0M 0M
- 0113 64M 32M 32M 0M
- 01111 32M 32M 32M 32M
-
- In case that the property is absent, the reset value or
- what bootloader sets up in IOMUXC_GPR1[11:0] will be
- used.
-
- - fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
- devices, the presence of this property indicates that
- the weim bus should operate in Burst Clock Mode.
-
- - fsl,continuous-burst-clk Make Burst Clock to output continuous clock.
- Without this option Burst Clock will output clock
- only when necessary. This takes effect only if
- "fsl,burst-clk-enable" is set.
-
-Timing property for child nodes. It is mandatory, not optional.
-
- - fsl,weim-cs-timing: The timing array, contains timing values for the
- child node. We get the CS indexes from the address
- ranges in the child node's "reg" property.
- The number of registers depends on the selected chip:
- For i.MX1, i.MX21 ("fsl,imx1-weim") there are two
- registers: CSxU, CSxL.
- For i.MX25, i.MX27, i.MX31 and i.MX35 ("fsl,imx27-weim")
- there are three registers: CSCRxU, CSCRxL, CSCRxA.
- For i.MX50, i.MX53 ("fsl,imx50-weim"),
- i.MX51 ("fsl,imx51-weim") and i.MX6Q ("fsl,imx6q-weim")
- there are six registers: CSxGCR1, CSxGCR2, CSxRCR1,
- CSxRCR2, CSxWCR1, CSxWCR2.
-
-Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
-
- weim: weim@21b8000 {
- compatible = "fsl,imx6q-weim";
- reg = <0x021b8000 0x4000>;
- clocks = <&clks 196>;
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0 0x08000000 0x08000000>;
- fsl,weim-cs-gpr = <&gpr>;
-
- nor@0,0 {
- compatible = "cfi-flash";
- reg = <0 0 0x02000000>;
- #address-cells = <1>;
- #size-cells = <1>;
- bank-width = <2>;
- fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
- 0x0000c000 0x1404a38e 0x00000000>;
- };
- };
-
-Example for an imx6q-based board, a multi-chipselect device connected to WEIM:
-
-In this case, both chip select 0 and 1 will be configured with the same timing
-array values.
-
- weim: weim@21b8000 {
- compatible = "fsl,imx6q-weim";
- reg = <0x021b8000 0x4000>;
- clocks = <&clks 196>;
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0 0x08000000 0x02000000
- 1 0 0x0a000000 0x02000000
- 2 0 0x0c000000 0x02000000
- 3 0 0x0e000000 0x02000000>;
- fsl,weim-cs-gpr = <&gpr>;
-
- acme@0 {
- compatible = "acme,whatever";
- reg = <0 0 0x100>, <0 0x400000 0x800>,
- <1 0x400000 0x800>;
- fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100
- 0x00000000 0xa0000240 0x00000000>;
- };
- };
diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
deleted file mode 100644
index 5fb4e7bfa4da..000000000000
--- a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
+++ /dev/null
@@ -1,168 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Intel IXP4xx Expansion Bus Controller
-
-description: |
- The IXP4xx expansion bus controller handles access to devices on the
- memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
- including IXP42x, IXP43x, IXP45x and IXP46x.
-
-maintainers:
- - Linus Walleij <linus.walleij@linaro.org>
-
-properties:
- $nodename:
- pattern: '^bus@[0-9a-f]+$'
-
- compatible:
- items:
- - enum:
- - intel,ixp42x-expansion-bus-controller
- - intel,ixp43x-expansion-bus-controller
- - intel,ixp45x-expansion-bus-controller
- - intel,ixp46x-expansion-bus-controller
- - const: syscon
-
- reg:
- description: Control registers for the expansion bus, these are not
- inside the memory range handled by the expansion bus.
- maxItems: 1
-
- native-endian:
- $ref: /schemas/types.yaml#/definitions/flag
- description: The IXP4xx has a peculiar MMIO access scheme, as it changes
- the access pattern for words (swizzling) on the bus depending on whether
- the SoC is running in big-endian or little-endian mode. Thus the
- registers must always be accessed using native endianness.
-
- "#address-cells":
- description: |
- The first cell is the chip select number.
- The second cell is the address offset within the bank.
- const: 2
-
- "#size-cells":
- const: 1
-
- ranges: true
- dma-ranges: true
-
-patternProperties:
- "^.*@[0-7],[0-9a-f]+$":
- description: Devices attached to chip selects are represented as
- subnodes.
- type: object
-
- properties:
- intel,ixp4xx-eb-t1:
- description: Address timing, extend address phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 3
-
- intel,ixp4xx-eb-t2:
- description: Setup chip select timing, extend setup phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 3
-
- intel,ixp4xx-eb-t3:
- description: Strobe timing, extend strobe phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 15
-
- intel,ixp4xx-eb-t4:
- description: Hold timing, extend hold phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 3
-
- intel,ixp4xx-eb-t5:
- description: Recovery timing, extend recovery phase with n cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 15
-
- intel,ixp4xx-eb-cycle-type:
- description: The type of cycles to use on the expansion bus for this
- chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
-
- intel,ixp4xx-eb-byte-access-on-halfword:
- description: Allow byte read access on half word devices.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-hpi-hrdy-pol-high:
- description: Set HPI HRDY polarity to active high when using HPI.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-mux-address-and-data:
- description: Multiplex address and data on the data bus.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-ahb-split-transfers:
- description: Enable AHB split transfers.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-write-enable:
- description: Enable write cycles.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
- intel,ixp4xx-eb-byte-access:
- description: Expansion bus uses only 8 bits. The default is to use
- 16 bits.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
-
-required:
- - compatible
- - reg
- - native-endian
- - "#address-cells"
- - "#size-cells"
- - ranges
- - dma-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
- bus@50000000 {
- compatible = "intel,ixp42x-expansion-bus-controller", "syscon";
- reg = <0xc4000000 0x28>;
- native-endian;
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0x0 0x50000000 0x01000000>,
- <1 0x0 0x51000000 0x01000000>;
- dma-ranges = <0 0x0 0x50000000 0x01000000>,
- <1 0x0 0x51000000 0x01000000>;
- flash@0,0 {
- compatible = "intel,ixp4xx-flash", "cfi-flash";
- bank-width = <2>;
- reg = <0 0x00000000 0x1000000>;
- intel,ixp4xx-eb-t3 = <3>;
- intel,ixp4xx-eb-cycle-type = <0>;
- intel,ixp4xx-eb-byte-access-on-halfword = <1>;
- intel,ixp4xx-eb-write-enable = <1>;
- intel,ixp4xx-eb-byte-access = <0>;
- };
- serial@1,0 {
- compatible = "exar,xr16l2551", "ns8250";
- reg = <1 0x00000000 0x10>;
- interrupt-parent = <&gpio0>;
- interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
- clock-frequency = <1843200>;
- intel,ixp4xx-eb-t3 = <3>;
- intel,ixp4xx-eb-cycle-type = <1>;
- intel,ixp4xx-eb-write-enable = <1>;
- intel,ixp4xx-eb-byte-access = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
new file mode 100644
index 000000000000..0bea4f5287ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/microsoft,vmbus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microsoft Hyper-V VMBus
+
+maintainers:
+ - Saurabh Sengar <ssengar@linux.microsoft.com>
+
+description:
+ VMBus is a software bus that implements the protocols for communication
+ between the root or host OS and guest OS'es (virtual machines).
+
+properties:
+ compatible:
+ const: microsoft,vmbus
+
+ ranges: true
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 1
+
+ dma-coherent: true
+
+ interrupts:
+ maxItems: 1
+ description: Interrupt is used to report a message from the host.
+
+required:
+ - compatible
+ - ranges
+ - interrupts
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ bus {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+
+ vmbus@ff0000000 {
+ compatible = "microsoft,vmbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>;
+ dma-coherent;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 2 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/moxtet.txt b/Documentation/devicetree/bindings/bus/moxtet.txt
deleted file mode 100644
index fb50fc865336..000000000000
--- a/Documentation/devicetree/bindings/bus/moxtet.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Turris Mox module status and configuration bus (over SPI)
-
-Required properties:
- - compatible : Should be "cznic,moxtet"
- - #address-cells : Has to be 1
- - #size-cells : Has to be 0
- - spi-cpol : Required inverted clock polarity
- - spi-cpha : Required shifted clock phase
- - interrupts : Must contain reference to the shared interrupt line
- - interrupt-controller : Required
- - #interrupt-cells : Has to be 1
-
-For other required and optional properties of SPI slave nodes please refer to
-../spi/spi-bus.txt.
-
-Required properties of subnodes:
- - reg : Should be position on the Moxtet bus (how many Moxtet
- modules are between this module and CPU module, so
- either 0 or a positive integer)
-
-The driver finds the devices connected to the bus by itself, but it may be
-needed to reference some of them from other parts of the device tree. In that
-case the devices can be defined as subnodes of the moxtet node.
-
-Example:
-
- moxtet@1 {
- compatible = "cznic,moxtet";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <1>;
- spi-max-frequency = <10000000>;
- spi-cpol;
- spi-cpha;
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupt-parent = <&gpiosb>;
- interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
-
- moxtet_sfp: gpio@0 {
- compatible = "cznic,moxtet-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <0>;
- }
- };
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
index d3ed048c9521..81a65e9f93f1 100644
--- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml
@@ -7,10 +7,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra ACONNECT Bus
description: |
- The Tegra ACONNECT bus is an AXI switch which is used to connnect various
+ The Tegra ACONNECT bus is an AXI switch which is used to connect various
components inside the Audio Processing Engine (APE). All CPU accesses to
the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All
- devices accessed via the ACONNNECT are described by child-nodes.
+ devices accessed via the ACONNECT are described by child-nodes.
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
@@ -21,6 +21,7 @@ properties:
- const: nvidia,tegra210-aconnect
- items:
- enum:
+ - nvidia,tegra264-aconnect
- nvidia,tegra234-aconnect
- nvidia,tegra186-aconnect
- nvidia,tegra194-aconnect
@@ -40,10 +41,10 @@ properties:
maxItems: 1
"#address-cells":
- const: 1
+ enum: [ 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
ranges: true
diff --git a/Documentation/devicetree/bindings/bus/palmbus.yaml b/Documentation/devicetree/bindings/bus/palmbus.yaml
index f5cbfaf52d53..c36c1e92a573 100644
--- a/Documentation/devicetree/bindings/bus/palmbus.yaml
+++ b/Documentation/devicetree/bindings/bus/palmbus.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/bus/palmbus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ralink PalmBus Device Tree Bindings
+title: Ralink PalmBus
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
@@ -36,6 +36,7 @@ patternProperties:
# All other properties should be child nodes with unit-address and 'reg'
"@[0-9a-f]+$":
type: object
+ additionalProperties: true
properties:
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt b/Documentation/devicetree/bindings/bus/qcom,ebi2.txt
deleted file mode 100644
index 5058aa2c63b2..000000000000
--- a/Documentation/devicetree/bindings/bus/qcom,ebi2.txt
+++ /dev/null
@@ -1,138 +0,0 @@
-Qualcomm External Bus Interface 2 (EBI2)
-
-The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any
-external memory (such as NAND or other memory-mapped peripherals) whereas
-LCDC handles LCD displays.
-
-As it says it connects devices to an external bus interface, meaning address
-lines (up to 9 address lines so can only address 1KiB external memory space),
-data lines (16 bits), OE (output enable), ADV (address valid, used on some
-NOR flash memories), WE (write enable). This on top of 6 different chip selects
-(CS0 thru CS5) so that in theory 6 different devices can be connected.
-
-Apparently this bus is clocked at 64MHz. It has dedicated pins on the package
-and the bus can only come out on these pins, however if some of the pins are
-unused they can be left unconnected or remuxed to be used as GPIO or in some
-cases other orthogonal functions as well.
-
-Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me.
-
-The chip selects have the following memory range assignments. This region of
-memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big.
-
-Chip Select Physical address base
-CS0 GPIO134 0x1a800000-0x1b000000 (8MB)
-CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB)
-CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB)
-CS3 GPIO133 0x1d000000-0x25000000 (128 MB)
-CS4 GPIO132 0x1c800000-0x1d000000 (8MB)
-CS5 GPIO131 0x1c000000-0x1c800000 (8MB)
-
-The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A,
-August 6, 2012 contains some incomplete documentation of the EBI2.
-
-FIXME: the manual mentions "write precharge cycles" and "precharge cycles".
-We have not been able to figure out which bit fields these correspond to
-in the hardware, or what valid values exist. The current hypothesis is that
-this is something just used on the FAST chip selects and that the SLOW
-chip selects are understood fully. There is also a "byte device enable"
-flag somewhere for 8bit memories.
-
-FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit
-unclear what this means, if they are mutually exclusive or can be used
-together, or if some chip selects are hardwired to be FAST and others are SLOW
-by design.
-
-The XMEM registers are totally undocumented but could be partially decoded
-because the Cypress AN49576 Antioch Westbridge apparently has suspiciously
-similar register layout, see: http://www.cypress.com/file/105771/download
-
-Required properties:
-- compatible: should be one of:
- "qcom,msm8660-ebi2"
- "qcom,apq8060-ebi2"
-- #address-cells: should be <2>: the first cell is the chipselect,
- the second cell is the offset inside the memory range
-- #size-cells: should be <1>
-- ranges: should be set to:
- ranges = <0 0x0 0x1a800000 0x00800000>,
- <1 0x0 0x1b000000 0x00800000>,
- <2 0x0 0x1b800000 0x00800000>,
- <3 0x0 0x1d000000 0x08000000>,
- <4 0x0 0x1c800000 0x00800000>,
- <5 0x0 0x1c000000 0x00800000>;
-- reg: two ranges of registers: EBI2 config and XMEM config areas
-- reg-names: should be "ebi2", "xmem"
-- clocks: two clocks, EBI_2X and EBI
-- clock-names: should be "ebi2x", "ebi2"
-
-Optional subnodes:
-- Nodes inside the EBI2 will be considered device nodes.
-
-The following optional properties are properties that can be tagged onto
-any device subnode. We are assuming that there can be only ONE device per
-chipselect subnode, else the properties will become ambiguous.
-
-Optional properties arrays for SLOW chip selects:
-- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to
- drive the data bus after OE is de-asserted, in order to avoid contention on
- the data bus. They are inserted when reading one CS and switching to another
- CS or read followed by write on the same CS. Valid values 0 thru 15. Minimum
- value is actually 1, so a value of 0 will still yield 1 recovery cycle.
-- qcom,xmem-write-hold-cycles: write hold cycles, these are extra cycles
- inserted after every write minimum 1. The data out is driven from the time
- WE is asserted until CS is asserted. With a hold of 1 (value = 0), the CS
- stays active for 1 extra cycle etc. Valid values 0 thru 15.
-- qcom,xmem-write-delta-cycles: initial latency for write cycles inserted for
- the first write to a page or burst memory. Valid values 0 thru 255.
-- qcom,xmem-read-delta-cycles: initial latency for read cycles inserted for the
- first read to a page or burst memory. Valid values 0 thru 255.
-- qcom,xmem-write-wait-cycles: number of wait cycles for every write access, 0=1
- cycle. Valid values 0 thru 15.
-- qcom,xmem-read-wait-cycles: number of wait cycles for every read access, 0=1
- cycle. Valid values 0 thru 15.
-
-Optional properties arrays for FAST chip selects:
-- qcom,xmem-address-hold-enable: this is a boolean property stating that we
- shall hold the address for an extra cycle to meet hold time requirements
- with ADV assertion.
-- qcom,xmem-adv-to-oe-recovery-cycles: the number of cycles elapsed before an OE
- assertion, with respect to the cycle where ADV (address valid) is asserted.
- 2 means 2 cycles between ADV and OE. Valid values 0, 1, 2 or 3.
-- qcom,xmem-read-hold-cycles: the length in cycles of the first segment of a
- read transfer. For a single read transfer this will be the time from CS
- assertion to OE assertion. Valid values 0 thru 15.
-
-
-Example:
-
-ebi2@1a100000 {
- compatible = "qcom,apq8060-ebi2";
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0x0 0x1a800000 0x00800000>,
- <1 0x0 0x1b000000 0x00800000>,
- <2 0x0 0x1b800000 0x00800000>,
- <3 0x0 0x1d000000 0x08000000>,
- <4 0x0 0x1c800000 0x00800000>,
- <5 0x0 0x1c000000 0x00800000>;
- reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>;
- reg-names = "ebi2", "xmem";
- clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>;
- clock-names = "ebi2x", "ebi2";
- /* Make sure to set up the pin control for the EBI2 */
- pinctrl-names = "default";
- pinctrl-0 = <&foo_ebi2_pins>;
-
- foo-ebi2@2,0 {
- compatible = "foo";
- reg = <2 0x0 0x100>;
- (...)
- qcom,xmem-recovery-cycles = <0>;
- qcom,xmem-write-hold-cycles = <3>;
- qcom,xmem-write-delta-cycles = <31>;
- qcom,xmem-read-delta-cycles = <28>;
- qcom,xmem-write-wait-cycles = <9>;
- qcom,xmem-read-wait-cycles = <9>;
- };
-};
diff --git a/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml b/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml
new file mode 100644
index 000000000000..693cfa9696b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/qcom,ssbi.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/qcom,ssbi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Single-wire Serial Bus Interface (SSBI)
+
+description:
+ Some Qualcomm MSM devices contain a point-to-point serial bus used to
+ communicate with a limited range of devices (mostly power management
+ chips).
+
+maintainers:
+ - Andy Gross <agross@kernel.org>
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ const: qcom,ssbi
+
+ reg:
+ maxItems: 1
+
+ qcom,controller-type:
+ description:
+ Indicates the SSBI bus variant the controller should use to talk
+ with the slave device. The type chosen is determined by the attached
+ slave.
+ enum:
+ - ssbi
+ - ssbi2
+ - pmic-arbiter
+
+ pmic:
+ $ref: /schemas/mfd/qcom-pm8xxx.yaml#
+
+required:
+ - compatible
+ - reg
+ - qcom,controller-type
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ ssbi@c00000 {
+ compatible = "qcom,ssbi";
+ reg = <0x00c00000 0x1000>;
+ qcom,controller-type = "pmic-arbiter";
+
+ pmic {
+ compatible = "qcom,pm8821";
+ interrupt-parent = <&msmgpio>;
+ interrupts = <76 IRQ_TYPE_LEVEL_LOW>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/bus/renesas,bsc.yaml b/Documentation/devicetree/bindings/bus/renesas,bsc.yaml
index f53a37785413..ff3c78317d28 100644
--- a/Documentation/devicetree/bindings/bus/renesas,bsc.yaml
+++ b/Documentation/devicetree/bindings/bus/renesas,bsc.yaml
@@ -41,6 +41,18 @@ properties:
interrupts:
maxItems: 1
+patternProperties:
+ # All other properties should be child nodes with unit-address and 'reg'
+ "@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
required:
- reg
diff --git a/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
new file mode 100644
index 000000000000..bf0af3424c9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Extended TrustZone protection controller
+
+description: |
+ The ETZPC configures TrustZone security in a SoC having bus masters and
+ devices with programmable-security attributes (securable resources).
+
+maintainers:
+ - Gatien Chevallier <gatien.chevallier@foss.st.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32-etzpc
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: st,stm32-etzpc
+ - const: simple-bus
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+ "#access-controller-cells":
+ const: 1
+ description:
+ Contains the firewall ID associated to the peripheral.
+
+patternProperties:
+ "@[0-9a-f]+$":
+ description: Peripherals
+ type: object
+
+ additionalProperties: true
+
+ required:
+ - access-controllers
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - "#access-controller-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ // In this example, the usart2 device refers to rifsc as its access
+ // controller.
+ // Access rights are verified before creating devices.
+
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp13-clks.h>
+ #include <dt-bindings/reset/stm32mp13-resets.h>
+
+ etzpc: bus@5c007000 {
+ compatible = "st,stm32-etzpc", "simple-bus";
+ reg = <0x5c007000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #access-controller-cells = <1>;
+ ranges;
+
+ usart2: serial@4c001000 {
+ compatible = "st,stm32h7-uart";
+ reg = <0x4c001000 0x400>;
+ interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc USART2_K>;
+ resets = <&rcc USART2_R>;
+ wakeup-source;
+ dmas = <&dmamux1 43 0x400 0x5>,
+ <&dmamux1 44 0x400 0x1>;
+ dma-names = "rx", "tx";
+ access-controllers = <&etzpc 17>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
new file mode 100644
index 000000000000..4d19917ad2c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Resource isolation framework security controller
+
+maintainers:
+ - Gatien Chevallier <gatien.chevallier@foss.st.com>
+
+description: |
+ Resource isolation framework (RIF) is a comprehensive set of hardware blocks
+ designed to enforce and manage isolation of STM32 hardware resources like
+ memory and peripherals.
+
+ The RIFSC (RIF security controller) is composed of three sets of registers,
+ each managing a specific set of hardware resources:
+ - RISC registers associated with RISUP logic (resource isolation device unit
+ for peripherals), assign all non-RIF aware peripherals to zero, one or
+ any security domains (secure, privilege, compartment).
+ - RIMC registers: associated with RIMU logic (resource isolation master
+ unit), assign all non RIF-aware bus master to one security domain by
+ setting secure, privileged and compartment information on the system bus.
+ Alternatively, the RISUP logic controlling the device port access to a
+ peripheral can assign target bus attributes to this peripheral master port
+ (supported attribute: CID).
+ - RISC registers associated with RISAL logic (resource isolation device unit
+ for address space - Lite version), assign address space subregions to one
+ security domains (secure, privilege, compartment).
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp21-rifsc
+ - st,stm32mp25-rifsc
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - st,stm32mp21-rifsc
+ - st,stm32mp25-rifsc
+ - const: simple-bus
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+ "#access-controller-cells":
+ const: 1
+ description:
+ Contains the firewall ID associated to the peripheral.
+
+patternProperties:
+ "@[0-9a-f]+$":
+ description: Peripherals
+ type: object
+
+ additionalProperties: true
+
+ required:
+ - access-controllers
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - "#access-controller-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ // In this example, the usart2 device refers to rifsc as its domain
+ // controller.
+ // Access rights are verified before creating devices.
+
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rifsc: bus@42080000 {
+ compatible = "st,stm32mp25-rifsc", "simple-bus";
+ reg = <0x42080000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #access-controller-cells = <1>;
+ ranges;
+
+ usart2: serial@400e0000 {
+ compatible = "st,stm32h7-uart";
+ reg = <0x400e0000 0x400>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ck_flexgen_08>;
+ access-controllers = <&rifsc 32>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/bus/ti-sysc.yaml b/Documentation/devicetree/bindings/bus/ti-sysc.yaml
index fced4082b047..6d7bca6c138e 100644
--- a/Documentation/devicetree/bindings/bus/ti-sysc.yaml
+++ b/Documentation/devicetree/bindings/bus/ti-sysc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/bus/ti-sysc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments interconnect target module binding
+title: Texas Instruments interconnect target module
maintainers:
- Tony Lindgren <tony@atomide.com>
@@ -97,7 +97,7 @@ properties:
- enum: [ ick, fck, sys_clk ]
- items:
- const: fck
- - enum: [ ick. dbclk, osc, sys_clk, dss_clk, ahclkx ]
+ - enum: [ ick, dbclk, osc, sys_clk, dss_clk, ahclkx ]
- items:
- const: fck
- const: phy-clk
diff --git a/Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml b/Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml
new file mode 100644
index 000000000000..7f62ffbdc245
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/xlnx,versal-net-cdx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD CDX bus controller
+
+description: |
+ CDX bus controller for AMD devices is implemented to dynamically
+ detect CDX bus and devices using the firmware.
+ The CDX bus manages multiple FPGA based hardware devices, which
+ can support network, crypto or any other specialized type of
+ devices. These FPGA based devices can be added/modified dynamically
+ on run-time.
+
+ All devices on the CDX bus will have a unique streamid (for IOMMU)
+ and a unique device ID (for MSI) corresponding to a requestor ID
+ (one to one associated with the device). The streamid and deviceid
+ are used to configure SMMU and GIC-ITS respectively.
+
+ iommu-map property is used to define the set of stream ids
+ corresponding to each device and the associated IOMMU.
+
+ The MSI writes are accompanied by sideband data (Device ID).
+ The msi-map property is used to associate the devices with the
+ device ID as well as the associated ITS controller.
+
+ rproc property (xlnx,rproc) is used to identify the remote processor
+ with which APU (Application Processor Unit) interacts to find out
+ the bus and device configuration.
+
+maintainers:
+ - Nipun Gupta <nipun.gupta@amd.com>
+ - Nikhil Agarwal <nikhil.agarwal@amd.com>
+
+properties:
+ compatible:
+ const: xlnx,versal-net-cdx
+
+ iommu-map: true
+
+ msi-map: true
+
+ xlnx,rproc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the remoteproc_r5 rproc node using which APU interacts
+ with remote processor.
+
+ ranges: true
+
+ "#address-cells":
+ enum: [1, 2]
+
+ "#size-cells":
+ enum: [1, 2]
+
+required:
+ - compatible
+ - iommu-map
+ - msi-map
+ - xlnx,rproc
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ cdx {
+ compatible = "xlnx,versal-net-cdx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* define map for RIDs 250-259 */
+ iommu-map = <250 &smmu 250 10>;
+ /* define msi map for RIDs 250-259 */
+ msi-map = <250 &its 250 10>;
+ xlnx,rproc = <&remoteproc_r5>;
+ ranges;
+ };
diff --git a/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml b/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml
new file mode 100644
index 000000000000..b135ffa4ab6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2023 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/andestech,ax45mp-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andestech AX45MP L2 Cache Controller
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ A level-2 cache (L2C) is used to improve the system performance by providing
+ a large amount of cache line entries and reasonable access delays. The L2C
+ is shared between cores, and a non-inclusive non-exclusive policy is used.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - andestech,ax45mp-cache
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - andestech,qilai-ax45mp-cache
+ - renesas,r9a07g043f-ax45mp-cache
+ - const: andestech,ax45mp-cache
+ - const: cache
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ cache-line-size:
+ const: 64
+
+ cache-level:
+ const: 2
+
+ cache-sets:
+ enum: [1024, 2048]
+
+ cache-size:
+ enum: [131072, 262144, 524288, 1048576, 2097152]
+
+ cache-unified: true
+
+ next-level-cache: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - cache-line-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: andestech,qilai-ax45mp-cache
+
+ then:
+ properties:
+ cache-sets:
+ const: 2048
+ cache-size:
+ const: 2097152
+ else:
+ properties:
+ cache-sets:
+ const: 1024
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ cache-controller@13400000 {
+ compatible = "renesas,r9a07g043f-ax45mp-cache", "andestech,ax45mp-cache",
+ "cache";
+ reg = <0x13400000 0x100000>;
+ interrupts = <508 IRQ_TYPE_LEVEL_HIGH>;
+ cache-line-size = <64>;
+ cache-level = <2>;
+ cache-sets = <1024>;
+ cache-size = <262144>;
+ cache-unified;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml b/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml
index 1fca282f64a2..ec4f367bc0b4 100644
--- a/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
+++ b/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml
@@ -2,7 +2,7 @@
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
-$id: http://devicetree.org/schemas/memory-controllers/baikal,bt1-l2-ctl.yaml#
+$id: http://devicetree.org/schemas/cache/baikal,bt1-l2-ctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 L2-cache Control Block
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt b/Documentation/devicetree/bindings/cache/freescale-l2cache.txt
index 22ad012660e9..22ad012660e9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt
+++ b/Documentation/devicetree/bindings/cache/freescale-l2cache.txt
diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.yaml b/Documentation/devicetree/bindings/cache/l2c2x0.yaml
index 6b8f4d4fa580..10c1a900202f 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.yaml
+++ b/Documentation/devicetree/bindings/cache/l2c2x0.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: http://devicetree.org/schemas/arm/l2c2x0.yaml#
+$id: http://devicetree.org/schemas/cache/l2c2x0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM L2 Cache Controller
@@ -100,9 +100,8 @@ properties:
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
$ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- minItems: 2
- maxItems: 2
+ minItems: 2
+ maxItems: 2
arm,io-coherent:
description: indicates that the system is operating in an hardware
diff --git a/Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml b/Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml
new file mode 100644
index 000000000000..2bfa3c29f6a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/marvell,kirkwood-cache.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/marvell,kirkwood-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Feroceon/Kirkwood Cache
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - marvell,feroceon-cache
+ - marvell,kirkwood-cache
+
+ reg:
+ maxItems: 1
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,kirkwood-cache
+ then:
+ required:
+ - reg
+ else:
+ properties:
+ reg: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ l2-cache@20128 {
+ compatible = "marvell,kirkwood-cache";
+ reg = <0x20128 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml
new file mode 100644
index 000000000000..9f7f0d031631
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/marvell,tauros2-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Tauros2 Cache
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ const: marvell,tauros2-cache
+
+ marvell,tauros2-cache-features:
+ description: >
+ Specify the features supported for the tauros2 cache. The features include:
+
+ - CACHE_TAUROS2_PREFETCH_ON (1 << 0)
+ - CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1)
+
+ The definition can be found at arch/arm/include/asm/hardware/cache-tauros2.h
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 0x3
+
+required:
+ - compatible
+ - marvell,tauros2-cache-features
+
+additionalProperties: false
+
+examples:
+ - |
+ l2-cache {
+ compatible = "marvell,tauros2-cache";
+ marvell,tauros2-cache-features = <0x3>;
+ };
diff --git a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml
new file mode 100644
index 000000000000..a620a2ff5c56
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml
@@ -0,0 +1,319 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/qcom,llcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Last Level Cache Controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ LLCC (Last Level Cache Controller) provides last level of cache memory in SoC,
+ that can be shared by multiple clients. Clients here are different cores in the
+ SoC, the idea is to minimize the local caches at the clients and migrate to
+ common pool of memory. Cache memory is divided into partitions called slices
+ which are assigned to clients. Clients can query the slice details, activate
+ and deactivate them.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5424-llcc
+ - qcom,kaanapali-llcc
+ - qcom,qcs615-llcc
+ - qcom,qcs8300-llcc
+ - qcom,qdu1000-llcc
+ - qcom,sa8775p-llcc
+ - qcom,sar1130p-llcc
+ - qcom,sar2130p-llcc
+ - qcom,sc7180-llcc
+ - qcom,sc7280-llcc
+ - qcom,sc8180x-llcc
+ - qcom,sc8280xp-llcc
+ - qcom,sdm845-llcc
+ - qcom,sm6350-llcc
+ - qcom,sm7150-llcc
+ - qcom,sm8150-llcc
+ - qcom,sm8250-llcc
+ - qcom,sm8350-llcc
+ - qcom,sm8450-llcc
+ - qcom,sm8550-llcc
+ - qcom,sm8650-llcc
+ - qcom,sm8750-llcc
+ - qcom,x1e80100-llcc
+
+ reg:
+ minItems: 1
+ maxItems: 10
+
+ reg-names:
+ minItems: 1
+ maxItems: 10
+
+ interrupts:
+ maxItems: 1
+
+ nvmem-cells:
+ items:
+ - description: Reference to an nvmem node for multi channel DDR
+
+ nvmem-cell-names:
+ items:
+ - const: multi-chan-ddr
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5424-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar1130p-llcc
+ - qcom,sar2130p-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC broadcast OR register region
+ - description: LLCC broadcast AND register region
+ - description: LLCC scratchpad broadcast OR register region
+ - description: LLCC scratchpad broadcast AND register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc_broadcast_base
+ - const: llcc_broadcast_and_base
+ - const: llcc_scratchpad_broadcast_base
+ - const: llcc_scratchpad_broadcast_and_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs615-llcc
+ - qcom,sc7180-llcc
+ - qcom,sm6350-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC broadcast base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc_broadcast_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC2 base register region
+ - description: LLCC3 base register region
+ - description: LLCC4 base register region
+ - description: LLCC5 base register region
+ - description: LLCC broadcast base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc2_base
+ - const: llcc3_base
+ - const: llcc4_base
+ - const: llcc5_base
+ - const: llcc_broadcast_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC broadcast base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc_broadcast_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qdu1000-llcc
+ - qcom,sc8180x-llcc
+ - qcom,sc8280xp-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC2 base register region
+ - description: LLCC3 base register region
+ - description: LLCC4 base register region
+ - description: LLCC5 base register region
+ - description: LLCC6 base register region
+ - description: LLCC7 base register region
+ - description: LLCC broadcast base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc2_base
+ - const: llcc3_base
+ - const: llcc4_base
+ - const: llcc5_base
+ - const: llcc6_base
+ - const: llcc7_base
+ - const: llcc_broadcast_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,x1e80100-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC2 base register region
+ - description: LLCC3 base register region
+ - description: LLCC4 base register region
+ - description: LLCC5 base register region
+ - description: LLCC6 base register region
+ - description: LLCC7 base register region
+ - description: LLCC broadcast base register region
+ - description: LLCC broadcast AND register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc2_base
+ - const: llcc3_base
+ - const: llcc4_base
+ - const: llcc5_base
+ - const: llcc6_base
+ - const: llcc7_base
+ - const: llcc_broadcast_base
+ - const: llcc_broadcast_and_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-llcc
+ - qcom,sdm845-llcc
+ - qcom,sm8150-llcc
+ - qcom,sm8250-llcc
+ - qcom,sm8350-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC2 base register region
+ - description: LLCC3 base register region
+ - description: LLCC broadcast base register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc2_base
+ - const: llcc3_base
+ - const: llcc_broadcast_base
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kaanapali-llcc
+ - qcom,sm8450-llcc
+ - qcom,sm8550-llcc
+ - qcom,sm8650-llcc
+ - qcom,sm8750-llcc
+ then:
+ properties:
+ reg:
+ items:
+ - description: LLCC0 base register region
+ - description: LLCC1 base register region
+ - description: LLCC2 base register region
+ - description: LLCC3 base register region
+ - description: LLCC broadcast OR register region
+ - description: LLCC broadcast AND register region
+ reg-names:
+ items:
+ - const: llcc0_base
+ - const: llcc1_base
+ - const: llcc2_base
+ - const: llcc3_base
+ - const: llcc_broadcast_base
+ - const: llcc_broadcast_and_base
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ system-cache-controller@1100000 {
+ compatible = "qcom,sdm845-llcc";
+ reg = <0 0x01100000 0 0x50000>, <0 0x01180000 0 0x50000>,
+ <0 0x01200000 0 0x50000>, <0 0x01280000 0 0x50000>,
+ <0 0x01300000 0 0x50000>;
+ reg-names = "llcc0_base", "llcc1_base", "llcc2_base",
+ "llcc3_base", "llcc_broadcast_base";
+ interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml
new file mode 100644
index 000000000000..c0e5ebb1fa4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml
@@ -0,0 +1,217 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/sifive,ccache0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive Composable Cache Controller
+
+maintainers:
+ - Paul Walmsley <paul.walmsley@sifive.com>
+
+description:
+ The SiFive Composable Cache Controller is used to provide access to fast copies
+ of memory for masters in a Core Complex. The Composable Cache Controller also
+ acts as directory-based coherency manager.
+ All the properties in ePAPR/DeviceTree specification applies for this platform.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sifive,ccache0
+ - sifive,fu540-c000-ccache
+ - sifive,fu740-c000-ccache
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sifive,ccache0
+ - sifive,fu540-c000-ccache
+ - sifive,fu740-c000-ccache
+ - const: cache
+ - items:
+ - enum:
+ - eswin,eic7700-l3-cache
+ - starfive,jh7100-ccache
+ - starfive,jh7110-ccache
+ - const: sifive,ccache0
+ - const: cache
+ - items:
+ - const: microchip,mpfs-ccache
+ - const: sifive,fu540-c000-ccache
+ - const: cache
+ - items:
+ - const: microchip,pic64gx-ccache
+ - const: microchip,mpfs-ccache
+ - const: sifive,fu540-c000-ccache
+ - const: cache
+
+ cache-block-size:
+ const: 64
+
+ cache-level:
+ enum: [2, 3]
+
+ cache-sets:
+ enum: [1024, 2048, 4096]
+
+ cache-size:
+ enum: [2097152, 4194304]
+
+ cache-unified: true
+
+ interrupts:
+ minItems: 3
+ items:
+ - description: DirError interrupt
+ - description: DataError interrupt
+ - description: DataFail interrupt
+ - description: DirFail interrupt
+
+ reg:
+ maxItems: 1
+
+ next-level-cache: true
+
+ memory-region:
+ maxItems: 1
+ description: |
+ The reference to the reserved-memory for the L2 Loosely Integrated Memory region.
+ The reserved memory node should be defined as per the bindings in reserved-memory.txt.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - eswin,eic7700-l3-cache
+ - sifive,fu740-c000-ccache
+ - starfive,jh7100-ccache
+ - starfive,jh7110-ccache
+ - microchip,mpfs-ccache
+
+ then:
+ properties:
+ interrupts:
+ description: |
+ Must contain entries for DirError, DataError, DataFail, DirFail signals.
+ minItems: 4
+
+ else:
+ properties:
+ interrupts:
+ description: |
+ Must contain entries for DirError, DataError and DataFail signals.
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: eswin,eic7700-l3-cache
+
+ then:
+ properties:
+ cache-size:
+ const: 4194304
+
+ else:
+ properties:
+ cache-size:
+ const: 2097152
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sifive,fu740-c000-ccache
+ - starfive,jh7100-ccache
+ - starfive,jh7110-ccache
+
+ then:
+ properties:
+ cache-sets:
+ const: 2048
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,mpfs-ccache
+ - sifive,fu540-c000-ccache
+
+ then:
+ properties:
+ cache-sets:
+ const: 1024
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - eswin,eic7700-l3-cache
+
+ then:
+ properties:
+ cache-sets:
+ const: 4096
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: sifive,ccache0
+
+ then:
+ properties:
+ cache-level:
+ enum: [2, 3]
+
+ else:
+ properties:
+ cache-level:
+ const: 2
+
+additionalProperties: false
+
+required:
+ - compatible
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+ - interrupts
+ - reg
+
+examples:
+ - |
+ cache-controller@2010000 {
+ compatible = "sifive,fu540-c000-ccache", "cache";
+ cache-block-size = <64>;
+ cache-level = <2>;
+ cache-sets = <1024>;
+ cache-size = <2097152>;
+ cache-unified;
+ reg = <0x2010000 0x1000>;
+ interrupt-parent = <&plic0>;
+ interrupts = <1>,
+ <2>,
+ <3>;
+ next-level-cache = <&L25>;
+ memory-region = <&l2_lim>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml b/Documentation/devicetree/bindings/cache/socionext,uniphier-system-cache.yaml
index 7ca5375f278f..3196263685a3 100644
--- a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml
+++ b/Documentation/devicetree/bindings/cache/socionext,uniphier-system-cache.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml#
+$id: http://devicetree.org/schemas/cache/socionext,uniphier-system-cache.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UniPhier outer cache controller
@@ -22,7 +22,6 @@ properties:
description: |
should contain 3 regions: control register, revision register,
operation register, in this order.
- minItems: 3
maxItems: 3
interrupts:
diff --git a/Documentation/devicetree/bindings/cache/starfive,jh8100-starlink-cache.yaml b/Documentation/devicetree/bindings/cache/starfive,jh8100-starlink-cache.yaml
new file mode 100644
index 000000000000..6d61098e388b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cache/starfive,jh8100-starlink-cache.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cache/starfive,jh8100-starlink-cache.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive StarLink Cache Controller
+
+maintainers:
+ - Joshua Yeong <joshua.yeong@starfivetech.com>
+
+description:
+ StarFive's StarLink Cache Controller manages the L3 cache shared between
+ clusters of CPU cores. The cache driver enables RISC-V non-standard cache
+ management as an alternative to instructions in the RISC-V Zicbom extension.
+
+allOf:
+ - $ref: /schemas/cache-controller.yaml#
+
+# We need a select here so we don't match all nodes with 'cache'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - starfive,jh8100-starlink-cache
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: starfive,jh8100-starlink-cache
+ - const: cache
+
+ reg:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - cache-block-size
+ - cache-level
+ - cache-sets
+ - cache-size
+ - cache-unified
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cache-controller@15000000 {
+ compatible = "starfive,jh8100-starlink-cache", "cache";
+ reg = <0x0 0x15000000 0x0 0x278>;
+ cache-block-size = <64>;
+ cache-level = <3>;
+ cache-sets = <8192>;
+ cache-size = <0x400000>;
+ cache-unified;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
index 50ebd8c57795..9f9816fbecbc 100644
--- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
+++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
@@ -29,10 +29,8 @@ properties:
patternProperties:
'^connector@[0-9a-f]+$':
$ref: /schemas/connector/usb-connector.yaml#
- unevaluatedProperties: false
- properties:
- reg:
- maxItems: 1
+ required:
+ - reg
required:
- compatible
@@ -41,13 +39,14 @@ additionalProperties: false
examples:
- |+
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
cros_ec: ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
+ interrupts = <35 0>;
typec {
compatible = "google,cros-ec-typec";
diff --git a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml b/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml
deleted file mode 100644
index 5b875af6a95a..000000000000
--- a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/chrome/google,cros-kbd-led-backlight.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: ChromeOS keyboard backlight LED driver.
-
-maintainers:
- - Tzung-Bi Shih <tzungbi@kernel.org>
-
-properties:
- compatible:
- const: google,cros-kbd-led-backlight
-
-required:
- - compatible
-
-additionalProperties: false
-
-examples:
- - |
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cros_ec: ec@0 {
- compatible = "google,cros-ec-spi";
- reg = <0>;
-
- kbd-led-backlight {
- compatible = "google,cros-kbd-led-backlight";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
deleted file mode 100644
index d19885b7c73f..000000000000
--- a/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* Actions Semi Owl Clock Management Unit (CMU)
-
-The Actions Semi Owl Clock Management Unit generates and supplies clock
-to various controllers within the SoC. The clock binding described here is
-applicable to S900, S700 and S500 SoC's.
-
-Required Properties:
-
-- compatible: should be one of the following,
- "actions,s900-cmu"
- "actions,s700-cmu"
- "actions,s500-cmu"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: Reference to the parent clocks ("hosc", "losc")
-- #clock-cells: should be 1.
-- #reset-cells: should be 1.
-
-Each clock is assigned an identifier, and client nodes can use this identifier
-to specify the clock which they consume.
-
-All available clocks are defined as preprocessor macros in corresponding
-dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h or
-actions,s500-cmu.h header and can be used in device tree sources.
-
-External clocks:
-
-The hosc clock used as input for the plls is generated outside the SoC. It is
-expected that it is defined using standard clock bindings as "hosc".
-
-Actions Semi S900 CMU also requires one more clock:
- - "losc" - internal low frequency oscillator
-
-Example: Clock Management Unit node:
-
- cmu: clock-controller@e0160000 {
- compatible = "actions,s900-cmu";
- reg = <0x0 0xe0160000 0x0 0x1000>;
- clocks = <&hosc>, <&losc>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
-
-Example: UART controller node that consumes clock generated by the clock
-management unit:
-
- uart: serial@e012a000 {
- compatible = "actions,s900-uart", "actions,owl-uart";
- reg = <0x0 0xe012a000 0x0 0x2000>;
- interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cmu CLK_UART5>;
- };
diff --git a/Documentation/devicetree/bindings/clock/actions,owl-cmu.yaml b/Documentation/devicetree/bindings/clock/actions,owl-cmu.yaml
new file mode 100644
index 000000000000..28396441bc98
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/actions,owl-cmu.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/actions,owl-cmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl Clock Management Unit (CMU)
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description: |
+ The Actions Semi Owl Clock Management Unit generates and supplies clock
+ to various controllers within the SoC.
+
+ See also:
+ include/dt-bindings/clock/actions,s500-cmu.h
+ include/dt-bindings/clock/actions,s700-cmu.h
+ include/dt-bindings/clock/actions,s900-cmu.h
+
+properties:
+ compatible:
+ enum:
+ - actions,s500-cmu
+ - actions,s700-cmu
+ - actions,s900-cmu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Host oscillator source
+ - description: Internal low frequency oscillator source
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@e0160000 {
+ compatible = "actions,s900-cmu";
+ reg = <0xe0160000 0x1000>;
+ clocks = <&hosc>, <&losc>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
index 983033fe5b17..6eea1a41150a 100644
--- a/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
+++ b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/adi,axi-clkgen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for Analog Devices AXI clkgen pcore clock generator
+title: Analog Devices AXI clkgen pcore clock generator
maintainers:
- Lars-Peter Clausen <lars@metafoo.de>
@@ -26,9 +26,24 @@ properties:
description:
Specifies the reference clock(s) from which the output frequency is
derived. This must either reference one clock if only the first clock
- input is connected or two if both clock inputs are connected.
- minItems: 1
- maxItems: 2
+ input is connected or two if both clock inputs are connected. The last
+ clock is the AXI bus clock that needs to be enabled so we can access the
+ core registers.
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: clkin1
+ - const: s_axi_aclk
+ - items:
+ - const: clkin1
+ - const: clkin2
+ - const: s_axi_aclk
+
+ clock-output-names:
+ maxItems: 1
'#clock-cells':
const: 0
@@ -40,6 +55,7 @@ required:
- compatible
- reg
- clocks
+ - clock-names
- '#clock-cells'
additionalProperties: false
@@ -50,5 +66,7 @@ examples:
compatible = "adi,axi-clkgen-2.00.a";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;
- clocks = <&osc 1>;
+ clocks = <&osc 1>, <&clkc 15>;
+ clock-names = "clkin1", "s_axi_aclk";
+ clock-output-names = "spi_sclk";
};
diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
index d60e74654809..a8471367175b 100644
--- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
+++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/airoha,en7523-scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: EN7523 Clock Device Tree Bindings
+title: EN7523 Clock
maintainers:
- Felix Fietkau <nbd@nbd.name>
@@ -29,10 +29,15 @@ description: |
properties:
compatible:
items:
- - const: airoha,en7523-scu
+ - enum:
+ - airoha,en7523-scu
+ - airoha,en7581-scu
reg:
- maxItems: 2
+ items:
+ - description: scu base address
+ - description: misc scu base address
+ minItems: 1
"#clock-cells":
description:
@@ -40,11 +45,34 @@ properties:
clocks.
const: 1
+ '#reset-cells':
+ description: ID of the controller reset line
+ const: 1
+
required:
- compatible
- reg
- '#clock-cells'
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: airoha,en7523-scu
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ const: airoha,en7581-scu
+ then:
+ properties:
+ reg:
+ maxItems: 1
+
additionalProperties: false
examples:
@@ -55,4 +83,18 @@ examples:
reg = <0x1fa20000 0x400>,
<0x1fb00000 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ scuclk: clock-controller@1fb00000 {
+ compatible = "airoha,en7581-scu";
+ reg = <0x0 0x1fb00000 0x0 0x970>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
};
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ahb-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ahb-clk.yaml
index 558db4b6ed17..93587b700476 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ahb-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ahb-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-ahb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 AHB Clock Device Tree Bindings
+title: Allwinner A10 AHB Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb0-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb0-clk.yaml
index b1e3d739beb2..e14e1aad9fd6 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb0-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb0-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-apb0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 APB0 Bus Clock Device Tree Bindings
+title: Allwinner A10 APB0 Bus Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb1-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb1-clk.yaml
index 51b7a6d4ea54..8a4747ebe0ba 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb1-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-apb1-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-apb1-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 APB1 Bus Clock Device Tree Bindings
+title: Allwinner A10 APB1 Bus Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-axi-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-axi-clk.yaml
index d801158e15de..aa08dd49dd61 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-axi-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-axi-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-axi-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 AXI Clock Device Tree Bindings
+title: Allwinner A10 AXI Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
index 15ed64d35261..1690b9d99c3d 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-ccu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner Clock Control Unit Device Tree Bindings
+title: Allwinner Clock Control Unit
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-cpu-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-cpu-clk.yaml
index 0dfafba1a168..08d073520cfa 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-cpu-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-cpu-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-cpu-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 CPU Clock Device Tree Bindings
+title: Allwinner A10 CPU Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-display-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-display-clk.yaml
index 7484a7ab7dea..e665e50c1785 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-display-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-display-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-display-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Display Clock Device Tree Bindings
+title: Allwinner A10 Display Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml
index 9a37a357cb4e..e588a7e8f260 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-gates-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-gates-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Bus Gates Clock Device Tree Bindings
+title: Allwinner A10 Bus Gates Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -132,7 +132,6 @@ examples:
"ahb_mp", "ahb_mali400";
};
-
- |
clk@1c20068 {
#clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mbus-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mbus-clk.yaml
index 18f131e262b4..e824e33489b6 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mbus-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mbus-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mbus-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 MBUS Clock Device Tree Bindings
+title: Allwinner A10 MBUS Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mmc-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mmc-clk.yaml
index 5199285a661a..c612f94befb9 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mmc-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mmc-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mmc-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Module 1 Clock Device Tree Bindings
+title: Allwinner A10 Module 1 Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod0-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod0-clk.yaml
index 3e2abe3e67c1..80ae3a7a588c 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod0-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod0-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mod0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Module 0 Clock Device Tree Bindings
+title: Allwinner A10 Module 0 Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod1-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod1-clk.yaml
index 7ddb55c75cff..4f9a8d44d42a 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod1-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-mod1-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mod1-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Module 1 Clock Device Tree Bindings
+title: Allwinner A10 Module 1 Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml
index c604822cda07..0052bf1e8a6b 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-osc-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-osc-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Gatable Oscillator Clock Device Tree Bindings
+title: Allwinner A10 Gateable Oscillator Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
index e5d9d45dab8a..b13a1f21d5da 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll1-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll1-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 CPU PLL Device Tree Bindings
+title: Allwinner A10 CPU PLL
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll3-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll3-clk.yaml
index 4b80a42fb3da..418d207d23b8 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll3-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll3-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll3-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Video PLL Device Tree Bindings
+title: Allwinner A10 Video PLL
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll5-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll5-clk.yaml
index 415bd77de53d..76ef3f0c7f2c 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll5-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll5-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll5-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 DRAM PLL Device Tree Bindings
+title: Allwinner A10 DRAM PLL
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll6-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll6-clk.yaml
index ec5652f76027..a94c93c90ece 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll6-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-pll6-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll6-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Peripheral PLL Device Tree Bindings
+title: Allwinner A10 Peripheral PLL
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml
index 0a335c615efd..6646b2a99fc1 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 TCON Channel 0 Clock Device Tree Bindings
+title: Allwinner A10 TCON Channel 0 Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-usb-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-usb-clk.yaml
index cd95d25bfe7c..5103b675e488 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-usb-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-usb-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-usb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 USB Clock Device Tree Bindings
+title: Allwinner A10 USB Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ve-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ve-clk.yaml
index 5dfd0c1c27b4..80337e38d6e5 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ve-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ve-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-ve-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Video Engine Clock Device Tree Bindings
+title: Allwinner A10 Video Engine Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml
new file mode 100644
index 000000000000..58be701a720e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/allwinner,sun55i-a523-ccu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A523 Clock Control Unit
+
+maintainers:
+ - Andre Przywara <andre.przywara@arm.com>
+
+properties:
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-ccu
+ - allwinner,sun55i-a523-mcu-ccu
+ - allwinner,sun55i-a523-r-ccu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ maxItems: 9
+
+ clock-names:
+ minItems: 4
+ maxItems: 9
+
+required:
+ - "#clock-cells"
+ - "#reset-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-ccu
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: High Frequency Oscillator (usually at 24MHz)
+ - description: Low Frequency Oscillator (usually at 32kHz)
+ - description: Internal Oscillator
+ - description: Low Frequency Oscillator fanout
+
+ clock-names:
+ items:
+ - const: hosc
+ - const: losc
+ - const: iosc
+ - const: losc-fanout
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-mcu-ccu
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: High Frequency Oscillator (usually at 24MHz)
+ - description: Low Frequency Oscillator (usually at 32kHz)
+ - description: Internal Oscillator
+ - description: Audio PLL (4x)
+ - description: Peripherals PLL 0 (300 MHz output)
+ - description: DSP module clock
+ - description: MBUS clock
+ - description: PRCM AHB clock
+ - description: PRCM APB0 clock
+
+ clock-names:
+ items:
+ - const: hosc
+ - const: losc
+ - const: iosc
+ - const: pll-audio0-4x
+ - const: pll-periph0-300m
+ - const: dsp
+ - const: mbus
+ - const: r-ahb
+ - const: r-apb0
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-r-ccu
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: High Frequency Oscillator (usually at 24MHz)
+ - description: Low Frequency Oscillator (usually at 32kHz)
+ - description: Internal Oscillator
+ - description: Peripherals PLL
+ - description: Audio PLL
+
+ clock-names:
+ items:
+ - const: hosc
+ - const: losc
+ - const: iosc
+ - const: pll-periph
+ - const: pll-audio
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@2001000 {
+ compatible = "allwinner,sun55i-a523-ccu";
+ reg = <0x02001000 0x1000>;
+ clocks = <&osc24M>, <&osc32k>, <&iosc>, <&r_ccu 1>;
+ clock-names = "hosc", "losc", "iosc", "losc-fanout";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun5i-a13-ahb-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun5i-a13-ahb-clk.yaml
index 99add7991c48..c6a6fbb6863b 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun5i-a13-ahb-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun5i-a13-ahb-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun5i-a13-ahb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A13 AHB Clock Device Tree Bindings
+title: Allwinner A13 AHB Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun6i-a31-pll6-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun6i-a31-pll6-clk.yaml
index 5f377205af71..7d6a6a34d20c 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun6i-a31-pll6-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun6i-a31-pll6-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun6i-a31-pll6-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 Peripheral PLL Device Tree Bindings
+title: Allwinner A31 Peripheral PLL
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-gmac-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-gmac-clk.yaml
index 59e5dce1b65a..b6202de35707 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-gmac-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-gmac-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun7i-a20-gmac-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A20 GMAC TX Clock Device Tree Bindings
+title: Allwinner A20 GMAC TX Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-out-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-out-clk.yaml
index c745733bcf04..fde7f7dc3d34 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-out-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun7i-a20-out-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun7i-a20-out-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A20 Output Clock Device Tree Bindings
+title: Allwinner A20 Output Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml
index 17caf78f0ccf..7fcd55d468d4 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun8i-a83t-de2-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83t Display Engine 2/3 Clock Controller Device Tree Bindings
+title: Allwinner A83t Display Engine 2/3 Clock Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -25,6 +25,7 @@ properties:
- const: allwinner,sun50i-a64-de2-clk
- const: allwinner,sun50i-h5-de2-clk
- const: allwinner,sun50i-h6-de3-clk
+ - const: allwinner,sun50i-h616-de33-clk
- items:
- const: allwinner,sun8i-r40-de2-clk
- const: allwinner,sun8i-h3-de2-clk
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun8i-h3-bus-gates-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun8i-h3-bus-gates-clk.yaml
index 3eb2bf65b230..45b9e2c7c1d1 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun8i-h3-bus-gates-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun8i-h3-bus-gates-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun8i-h3-bus-gates-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Bus Gates Clock Device Tree Bindings
+title: Allwinner A10 Bus Gates Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-ahb-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-ahb-clk.yaml
index d178da90aaec..f0f65af8ae22 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-ahb-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-ahb-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-ahb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 AHB Clock Device Tree Bindings
+title: Allwinner A80 AHB Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-apb0-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-apb0-clk.yaml
index 0351c79bd221..e9f9bc8f5794 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-apb0-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-apb0-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-apb0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 APB0 Bus Clock Device Tree Bindings
+title: Allwinner A80 APB0 Bus Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-cpus-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-cpus-clk.yaml
index 24d5b2f1a314..c48db2d49340 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-cpus-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-cpus-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-cpus-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 CPUS Clock Device Tree Bindings
+title: Allwinner A80 CPUS Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-de-clks.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-de-clks.yaml
index a82c7c7e942b..e9f81a343be1 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-de-clks.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-de-clks.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-de-clks.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 Display Engine Clock Controller Device Tree Bindings
+title: Allwinner A80 Display Engine Clock Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-gt-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-gt-clk.yaml
index 43963c3062c8..d3ce5eb18d4e 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-gt-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-gt-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-gt-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 GT Bus Clock Device Tree Bindings
+title: Allwinner A80 GT Bus Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-mmc-config-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-mmc-config-clk.yaml
index 20dc115fa211..65ee5afe83cc 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-mmc-config-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-mmc-config-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-mmc-config-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 MMC Configuration Clock Device Tree Bindings
+title: Allwinner A80 MMC Configuration Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-pll4-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-pll4-clk.yaml
index b76bab6a30e9..261264a8aef6 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-pll4-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-pll4-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-pll4-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 Peripheral PLL Device Tree Bindings
+title: Allwinner A80 Peripheral PLL
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clks.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clks.yaml
index 6532fb6821bc..515c15d5f661 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clks.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clks.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-clks.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 USB Clock Controller Device Tree Bindings
+title: Allwinner A80 USB Clock Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-mod-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-mod-clk.yaml
index 15218d10e78e..3f7b8d9511f1 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-mod-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-mod-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-mod-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 USB Module Clock Device Tree Bindings
+title: Allwinner A80 USB Module Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-phy-clk.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-phy-clk.yaml
index 2569041684e6..0d49072d47ca 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-phy-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-phy-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-phy-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 USB PHY Clock Device Tree Bindings
+title: Allwinner A80 USB PHY Clock
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/clock/alphascale,acc.txt b/Documentation/devicetree/bindings/clock/alphascale,acc.txt
deleted file mode 100644
index b3205b21c9d0..000000000000
--- a/Documentation/devicetree/bindings/clock/alphascale,acc.txt
+++ /dev/null
@@ -1,114 +0,0 @@
-Alphascale Clock Controller
-
-The ACC (Alphascale Clock Controller) is responsible of choising proper
-clock source, setting deviders and clock gates.
-
-Required properties for the ACC node:
- - compatible: must be "alphascale,asm9260-clock-controller"
- - reg: must contain the ACC register base and size
- - #clock-cells : shall be set to 1.
-
-Simple one-cell clock specifier format is used, where the only cell is used
-as an index of the clock inside the provider.
-It is encouraged to use dt-binding for clock index definitions. SoC specific
-dt-binding should be included to the device tree descriptor. For example
-Alphascale ASM9260:
-#include <dt-bindings/clock/alphascale,asm9260.h>
-
-This binding contains two types of clock providers:
- _AHB_ - AHB gate;
- _SYS_ - adjustable clock source. Not all peripheral have _SYS_ clock provider.
-All clock specific details can be found in the SoC documentation.
-CLKID_AHB_ROM 0
-CLKID_AHB_RAM 1
-CLKID_AHB_GPIO 2
-CLKID_AHB_MAC 3
-CLKID_AHB_EMI 4
-CLKID_AHB_USB0 5
-CLKID_AHB_USB1 6
-CLKID_AHB_DMA0 7
-CLKID_AHB_DMA1 8
-CLKID_AHB_UART0 9
-CLKID_AHB_UART1 10
-CLKID_AHB_UART2 11
-CLKID_AHB_UART3 12
-CLKID_AHB_UART4 13
-CLKID_AHB_UART5 14
-CLKID_AHB_UART6 15
-CLKID_AHB_UART7 16
-CLKID_AHB_UART8 17
-CLKID_AHB_UART9 18
-CLKID_AHB_I2S0 19
-CLKID_AHB_I2C0 20
-CLKID_AHB_I2C1 21
-CLKID_AHB_SSP0 22
-CLKID_AHB_IOCONFIG 23
-CLKID_AHB_WDT 24
-CLKID_AHB_CAN0 25
-CLKID_AHB_CAN1 26
-CLKID_AHB_MPWM 27
-CLKID_AHB_SPI0 28
-CLKID_AHB_SPI1 29
-CLKID_AHB_QEI 30
-CLKID_AHB_QUADSPI0 31
-CLKID_AHB_CAMIF 32
-CLKID_AHB_LCDIF 33
-CLKID_AHB_TIMER0 34
-CLKID_AHB_TIMER1 35
-CLKID_AHB_TIMER2 36
-CLKID_AHB_TIMER3 37
-CLKID_AHB_IRQ 38
-CLKID_AHB_RTC 39
-CLKID_AHB_NAND 40
-CLKID_AHB_ADC0 41
-CLKID_AHB_LED 42
-CLKID_AHB_DAC0 43
-CLKID_AHB_LCD 44
-CLKID_AHB_I2S1 45
-CLKID_AHB_MAC1 46
-
-CLKID_SYS_CPU 47
-CLKID_SYS_AHB 48
-CLKID_SYS_I2S0M 49
-CLKID_SYS_I2S0S 50
-CLKID_SYS_I2S1M 51
-CLKID_SYS_I2S1S 52
-CLKID_SYS_UART0 53
-CLKID_SYS_UART1 54
-CLKID_SYS_UART2 55
-CLKID_SYS_UART3 56
-CLKID_SYS_UART4 56
-CLKID_SYS_UART5 57
-CLKID_SYS_UART6 58
-CLKID_SYS_UART7 59
-CLKID_SYS_UART8 60
-CLKID_SYS_UART9 61
-CLKID_SYS_SPI0 62
-CLKID_SYS_SPI1 63
-CLKID_SYS_QUADSPI 64
-CLKID_SYS_SSP0 65
-CLKID_SYS_NAND 66
-CLKID_SYS_TRACE 67
-CLKID_SYS_CAMM 68
-CLKID_SYS_WDT 69
-CLKID_SYS_CLKOUT 70
-CLKID_SYS_MAC 71
-CLKID_SYS_LCD 72
-CLKID_SYS_ADCANA 73
-
-Example of clock consumer with _SYS_ and _AHB_ sinks.
-uart4: serial@80010000 {
- compatible = "alphascale,asm9260-uart";
- reg = <0x80010000 0x4000>;
- clocks = <&acc CLKID_SYS_UART4>, <&acc CLKID_AHB_UART4>;
- interrupts = <19>;
-};
-
-Clock consumer with only one, _AHB_ sink.
-timer0: timer@80088000 {
- compatible = "alphascale,asm9260-timer";
- reg = <0x80088000 0x4000>;
- clocks = <&acc CLKID_AHB_TIMER0>;
- interrupts = <29>;
-};
-
diff --git a/Documentation/devicetree/bindings/clock/alphascale,asm9260-clock-controller.yaml b/Documentation/devicetree/bindings/clock/alphascale,asm9260-clock-controller.yaml
new file mode 100644
index 000000000000..1caad419ce9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/alphascale,asm9260-clock-controller.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/alphascale,asm9260-clock-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Alphascale Clock Controller
+
+maintainers:
+ - Oleksij Rempel <linux@rempel-privat.de>
+
+description: |
+ The ACC (Alphascale Clock Controller) is responsible for choosing proper
+ clock source, setting dividers and clock gates.
+
+ Simple one-cell clock specifier format is used, where the only cell is used
+ as an index of the clock inside the provider.
+ It is encouraged to use dt-binding for clock index definitions. SoC specific
+ dt-binding should be included to the device tree descriptor. For example
+ Alphascale ASM9260:
+
+ #include <dt-bindings/clock/alphascale,asm9260.h>
+
+ This binding contains two types of clock providers:
+
+ _AHB_ - AHB gate;
+ _SYS_ - adjustable clock source. Not all peripheral have _SYS_ clock provider.
+
+ All clock specific details can be found in the SoC documentation.
+
+properties:
+ compatible:
+ const: alphascale,asm9260-clock-controller
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
deleted file mode 100644
index f72e80e0dade..000000000000
--- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Device Tree Clock bindings for Altera's SoCFPGA platform
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be one of the following:
- "altr,socfpga-pll-clock" - for a PLL clock
- "altr,socfpga-perip-clock" - The peripheral clock divided from the
- PLL clock.
- "altr,socfpga-gate-clk" - Clocks that directly feed peripherals and
- can get gated.
-
-- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
-- clocks : shall be the input parent clock phandle for the clock. This is
- either an oscillator or a pll output.
-- #clock-cells : from common clock binding, shall be set to 0.
-
-Optional properties:
-- fixed-divider : If clocks have a fixed divider value, use this property.
-- clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register
- and the bit index.
-- div-reg : For "socfpga-gate-clk" and "socfpga-periph-clock", div-reg contains
- the divider register, bit shift, and width.
-- clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls
- the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second
- value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct
- hold/delay times that is needed for the SD/MMC CIU clock. The values of both
- can be 0-315 degrees, in 45 degree increments.
diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
new file mode 100644
index 000000000000..2568ad7dd0ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,a1-peripherals-clkc.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,a1-peripherals-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A1 Peripherals Clock Control Unit
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Jian Hu <jian.hu@jian.hu.com>
+ - Dmitry Rokosov <ddrokosov@sberdevices.ru>
+
+properties:
+ compatible:
+ const: amlogic,a1-peripherals-clkc
+
+ '#clock-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: input fixed pll div2
+ - description: input fixed pll div3
+ - description: input fixed pll div5
+ - description: input fixed pll div7
+ - description: input hifi pll
+ - description: input oscillator (usually at 24MHz)
+ - description: input sys pll
+ minItems: 6 # sys_pll is optional
+
+ clock-names:
+ items:
+ - const: fclk_div2
+ - const: fclk_div3
+ - const: fclk_div5
+ - const: fclk_div7
+ - const: hifi_pll
+ - const: xtal
+ - const: sys_pll
+ minItems: 6 # sys_pll is optional
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,a1-pll-clkc.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@800 {
+ compatible = "amlogic,a1-peripherals-clkc";
+ reg = <0 0x800 0 0x104>;
+ #clock-cells = <1>;
+ clocks = <&clkc_pll CLKID_FCLK_DIV2>,
+ <&clkc_pll CLKID_FCLK_DIV3>,
+ <&clkc_pll CLKID_FCLK_DIV5>,
+ <&clkc_pll CLKID_FCLK_DIV7>,
+ <&clkc_pll CLKID_HIFI_PLL>,
+ <&xtal>,
+ <&clkc_pll CLKID_SYS_PLL>;
+ clock-names = "fclk_div2", "fclk_div3",
+ "fclk_div5", "fclk_div7",
+ "hifi_pll", "xtal", "sys_pll";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
new file mode 100644
index 000000000000..c99274d2a9bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,a1-pll-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A1 PLL Clock Control Unit
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Jian Hu <jian.hu@jian.hu.com>
+ - Dmitry Rokosov <ddrokosov@sberdevices.ru>
+
+properties:
+ compatible:
+ const: amlogic,a1-pll-clkc
+
+ '#clock-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: input fixpll_in
+ - description: input hifipll_in
+ - description: input syspll_in
+ minItems: 2 # syspll_in is optional
+
+ clock-names:
+ items:
+ - const: fixpll_in
+ - const: hifipll_in
+ - const: syspll_in
+ minItems: 2 # syspll_in is optional
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,a1-peripherals-clkc.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@7c80 {
+ compatible = "amlogic,a1-pll-clkc";
+ reg = <0 0x7c80 0 0x18c>;
+ #clock-cells = <1>;
+ clocks = <&clkc_periphs CLKID_FIXPLL_IN>,
+ <&clkc_periphs CLKID_HIFIPLL_IN>,
+ <&clkc_periphs CLKID_SYSPLL_IN>;
+ clock-names = "fixpll_in", "hifipll_in", "syspll_in";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
deleted file mode 100644
index 3a8948c04bc9..000000000000
--- a/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-* Amlogic AXG Audio Clock Controllers
-
-The Amlogic AXG audio clock controller generates and supplies clock to the
-other elements of the audio subsystem, such as fifos, i2s, spdif and pdm
-devices.
-
-Required Properties:
-
-- compatible : should be "amlogic,axg-audio-clkc" for the A113X and A113D,
- "amlogic,g12a-audio-clkc" for G12A,
- "amlogic,sm1-audio-clkc" for S905X3.
-- reg : physical base address of the clock controller and length of
- memory mapped region.
-- clocks : a list of phandle + clock-specifier pairs for the clocks listed
- in clock-names.
-- clock-names : must contain the following:
- * "pclk" - Main peripheral bus clock
- may contain the following:
- * "mst_in[0-7]" - 8 input plls to generate clock signals
- * "slv_sclk[0-9]" - 10 slave bit clocks provided by external
- components.
- * "slv_lrclk[0-9]" - 10 slave sample clocks provided by external
- components.
-- resets : phandle of the internal reset line
-- #clock-cells : should be 1.
-- #reset-cells : should be 1 on the g12a (and following) soc family
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/axg-audio-clkc.h header and can be
-used in device tree sources.
-
-Example:
-
-clkc_audio: clock-controller@0 {
- compatible = "amlogic,axg-audio-clkc";
- reg = <0x0 0x0 0x0 0xb4>;
- #clock-cells = <1>;
-
- clocks = <&clkc CLKID_AUDIO>,
- <&clkc CLKID_MPLL0>,
- <&clkc CLKID_MPLL1>,
- <&clkc CLKID_MPLL2>,
- <&clkc CLKID_MPLL3>,
- <&clkc CLKID_HIFI_PLL>,
- <&clkc CLKID_FCLK_DIV3>,
- <&clkc CLKID_FCLK_DIV4>,
- <&clkc CLKID_GP0_PLL>;
- clock-names = "pclk",
- "mst_in0",
- "mst_in1",
- "mst_in2",
- "mst_in3",
- "mst_in4",
- "mst_in5",
- "mst_in6",
- "mst_in7";
- resets = <&reset RESET_AUDIO>;
-};
diff --git a/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.yaml
new file mode 100644
index 000000000000..fd7982dd4cea
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.yaml
@@ -0,0 +1,201 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,axg-audio-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic AXG Audio Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+description:
+ The Amlogic AXG audio clock controller generates and supplies clock to the
+ other elements of the audio subsystem, such as fifos, i2s, spdif and pdm
+ devices.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,axg-audio-clkc
+ - amlogic,g12a-audio-clkc
+ - amlogic,sm1-audio-clkc
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: main peripheral bus clock
+ - description: input plls to generate clock signals N0
+ - description: input plls to generate clock signals N1
+ - description: input plls to generate clock signals N2
+ - description: input plls to generate clock signals N3
+ - description: input plls to generate clock signals N4
+ - description: input plls to generate clock signals N5
+ - description: input plls to generate clock signals N6
+ - description: input plls to generate clock signals N7
+ - description: slave bit clock N0 provided by external components
+ - description: slave bit clock N1 provided by external components
+ - description: slave bit clock N2 provided by external components
+ - description: slave bit clock N3 provided by external components
+ - description: slave bit clock N4 provided by external components
+ - description: slave bit clock N5 provided by external components
+ - description: slave bit clock N6 provided by external components
+ - description: slave bit clock N7 provided by external components
+ - description: slave bit clock N8 provided by external components
+ - description: slave bit clock N9 provided by external components
+ - description: slave sample clock N0 provided by external components
+ - description: slave sample clock N1 provided by external components
+ - description: slave sample clock N2 provided by external components
+ - description: slave sample clock N3 provided by external components
+ - description: slave sample clock N4 provided by external components
+ - description: slave sample clock N5 provided by external components
+ - description: slave sample clock N6 provided by external components
+ - description: slave sample clock N7 provided by external components
+ - description: slave sample clock N8 provided by external components
+ - description: slave sample clock N9 provided by external components
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: pclk
+ - const: mst_in0
+ - const: mst_in1
+ - const: mst_in2
+ - const: mst_in3
+ - const: mst_in4
+ - const: mst_in5
+ - const: mst_in6
+ - const: mst_in7
+ - const: slv_sclk0
+ - const: slv_sclk1
+ - const: slv_sclk2
+ - const: slv_sclk3
+ - const: slv_sclk4
+ - const: slv_sclk5
+ - const: slv_sclk6
+ - const: slv_sclk7
+ - const: slv_sclk8
+ - const: slv_sclk9
+ - const: slv_lrclk0
+ - const: slv_lrclk1
+ - const: slv_lrclk2
+ - const: slv_lrclk3
+ - const: slv_lrclk4
+ - const: slv_lrclk5
+ - const: slv_lrclk6
+ - const: slv_lrclk7
+ - const: slv_lrclk8
+ - const: slv_lrclk9
+
+ resets:
+ description: internal reset line
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-audio-clkc
+ - amlogic,sm1-audio-clkc
+ then:
+ required:
+ - '#reset-cells'
+ else:
+ properties:
+ '#reset-cells': false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-clkc.h>
+ #include <dt-bindings/reset/amlogic,meson-axg-reset.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clkc_audio: clock-controller@0 {
+ compatible = "amlogic,axg-audio-clkc";
+ reg = <0x0 0x0 0x0 0xb4>;
+ #clock-cells = <1>;
+
+ clocks = <&clkc CLKID_AUDIO>,
+ <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>,
+ <&clkc CLKID_MPLL3>,
+ <&clkc CLKID_HIFI_PLL>,
+ <&clkc CLKID_FCLK_DIV3>,
+ <&clkc CLKID_FCLK_DIV4>,
+ <&clkc CLKID_GP0_PLL>,
+ <&slv_sclk0>,
+ <&slv_sclk1>,
+ <&slv_sclk2>,
+ <&slv_sclk3>,
+ <&slv_sclk4>,
+ <&slv_sclk5>,
+ <&slv_sclk6>,
+ <&slv_sclk7>,
+ <&slv_sclk8>,
+ <&slv_sclk9>,
+ <&slv_lrclk0>,
+ <&slv_lrclk1>,
+ <&slv_lrclk2>,
+ <&slv_lrclk3>,
+ <&slv_lrclk4>,
+ <&slv_lrclk5>,
+ <&slv_lrclk6>,
+ <&slv_lrclk7>,
+ <&slv_lrclk8>,
+ <&slv_lrclk9>;
+ clock-names = "pclk",
+ "mst_in0",
+ "mst_in1",
+ "mst_in2",
+ "mst_in3",
+ "mst_in4",
+ "mst_in5",
+ "mst_in6",
+ "mst_in7",
+ "slv_sclk0",
+ "slv_sclk1",
+ "slv_sclk2",
+ "slv_sclk3",
+ "slv_sclk4",
+ "slv_sclk5",
+ "slv_sclk6",
+ "slv_sclk7",
+ "slv_sclk8",
+ "slv_sclk9",
+ "slv_lrclk0",
+ "slv_lrclk1",
+ "slv_lrclk2",
+ "slv_lrclk3",
+ "slv_lrclk4",
+ "slv_lrclk5",
+ "slv_lrclk6",
+ "slv_lrclk7",
+ "slv_lrclk8",
+ "slv_lrclk9";
+ resets = <&reset RESET_AUDIO>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,c3-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,c3-peripherals-clkc.yaml
new file mode 100644
index 000000000000..98e30b8c0529
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,c3-peripherals-clkc.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,c3-peripherals-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic C3 series Peripheral Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+ - Chuan Liu <chuan.liu@amlogic.com>
+
+properties:
+ compatible:
+ const: amlogic,c3-peripherals-clkc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 16
+ items:
+ - description: input oscillator (usually at 24MHz)
+ - description: input oscillators multiplexer
+ - description: input fix pll
+ - description: input fclk div 2
+ - description: input fclk div 2p5
+ - description: input fclk div 3
+ - description: input fclk div 4
+ - description: input fclk div 5
+ - description: input fclk div 7
+ - description: input gp0 pll
+ - description: input gp1 pll
+ - description: input hifi pll
+ - description: input sys clk
+ - description: input axi clk
+ - description: input sys pll div 16
+ - description: input cpu clk div 16
+ - description: input pad clock for rtc clk (optional)
+
+ clock-names:
+ minItems: 16
+ items:
+ - const: xtal_24m
+ - const: oscin
+ - const: fix
+ - const: fdiv2
+ - const: fdiv2p5
+ - const: fdiv3
+ - const: fdiv4
+ - const: fdiv5
+ - const: fdiv7
+ - const: gp0
+ - const: gp1
+ - const: hifi
+ - const: sysclk
+ - const: axiclk
+ - const: sysplldiv16
+ - const: cpudiv16
+ - const: pad_osc
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@0 {
+ compatible = "amlogic,c3-peripherals-clkc";
+ reg = <0x0 0x0 0x0 0x49c>;
+ #clock-cells = <1>;
+ clocks = <&xtal_24m>,
+ <&scmi_clk 8>,
+ <&scmi_clk 12>,
+ <&clkc_pll 3>,
+ <&clkc_pll 5>,
+ <&clkc_pll 7>,
+ <&clkc_pll 9>,
+ <&clkc_pll 11>,
+ <&clkc_pll 13>,
+ <&clkc_pll 15>,
+ <&scmi_clk 13>,
+ <&clkc_pll 17>,
+ <&scmi_clk 9>,
+ <&scmi_clk 10>,
+ <&scmi_clk 14>,
+ <&scmi_clk 15>;
+ clock-names = "xtal_24m",
+ "oscin",
+ "fix",
+ "fdiv2",
+ "fdiv2p5",
+ "fdiv3",
+ "fdiv4",
+ "fdiv5",
+ "fdiv7",
+ "gp0",
+ "gp1",
+ "hifi",
+ "sysclk",
+ "axiclk",
+ "sysplldiv16",
+ "cpudiv16";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,c3-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,c3-pll-clkc.yaml
new file mode 100644
index 000000000000..700865cc9792
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,c3-pll-clkc.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,c3-pll-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic C3 series PLL Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Jerome Brunet <jbrunet@baylibre.com>
+ - Chuan Liu <chuan.liu@amlogic.com>
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+
+properties:
+ compatible:
+ const: amlogic,c3-pll-clkc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: input top pll
+ - description: input mclk pll
+ - description: input fix pll
+
+ clock-names:
+ items:
+ - const: top
+ - const: mclk
+ - const: fix
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@8000 {
+ compatible = "amlogic,c3-pll-clkc";
+ reg = <0x0 0x8000 0x0 0x1a4>;
+ clocks = <&scmi_clk 2>,
+ <&scmi_clk 5>,
+ <&scmi_clk 12>;
+ clock-names = "top", "mclk", "fix";
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt
deleted file mode 100644
index c41f0be5d438..000000000000
--- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-* Amlogic GXBB AO Clock and Reset Unit
-
-The Amlogic GXBB AO clock controller generates and supplies clock to various
-controllers within the Always-On part of the SoC.
-
-Required Properties:
-
-- compatible: value should be different for each SoC family as :
- - GXBB (S905) : "amlogic,meson-gxbb-aoclkc"
- - GXL (S905X, S905D) : "amlogic,meson-gxl-aoclkc"
- - GXM (S912) : "amlogic,meson-gxm-aoclkc"
- - AXG (A113D, A113X) : "amlogic,meson-axg-aoclkc"
- - G12A (S905X2, S905D2, S905Y2) : "amlogic,meson-g12a-aoclkc"
- followed by the common "amlogic,meson-gx-aoclkc"
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "xtal" : the platform xtal
- * "mpeg-clk" : the main clock controller mother clock (aka clk81)
- * "ext-32k-0" : external 32kHz reference #0 if any (optional)
- * "ext-32k-1" : external 32kHz reference #1 if any (optional - gx only)
- * "ext-32k-2" : external 32kHz reference #2 if any (optional - gx only)
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/gxbb-aoclkc.h header and can be
-used in device tree sources.
-
-- #reset-cells: should be 1.
-
-Each reset is assigned an identifier and client nodes can use this identifier
-to specify the reset which they consume. All available resets are defined as
-preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be
-used in device tree sources.
-
-Parent node should have the following properties :
-- compatible: "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd"
-- reg: base address and size of the AO system control register space.
-
-Example: AO Clock controller node:
-
-ao_sysctrl: sys-ctrl@0 {
- compatible = "amlogic,meson-gx-ao-sysctrl", "syscon", "simple-mfd";
- reg = <0x0 0x0 0x0 0x100>;
-
- clkc_AO: clock-controller {
- compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
- #clock-cells = <1>;
- #reset-cells = <1>;
- clocks = <&xtal>, <&clkc CLKID_CLK81>;
- clock-names = "xtal", "mpeg-clk";
- };
-
-Example: UART controller node that consumes the clock and reset generated
- by the clock controller:
-
- uart_AO: serial@4c0 {
- compatible = "amlogic,meson-uart";
- reg = <0x4c0 0x14>;
- interrupts = <0 90 1>;
- clocks = <&clkc_AO CLKID_AO_UART1>;
- resets = <&clkc_AO RESET_AO_UART1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml
new file mode 100644
index 000000000000..628e5dd33dd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,gxbb-aoclkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Always-On Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-aoclkc
+ - amlogic,meson-gxl-aoclkc
+ - amlogic,meson-gxm-aoclkc
+ - amlogic,meson-axg-aoclkc
+ - const: amlogic,meson-gx-aoclkc
+ - enum:
+ - amlogic,meson-axg-aoclkc
+ - amlogic,meson-g12a-aoclkc
+
+ clocks:
+ minItems: 2
+ maxItems: 5
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: xtal
+ - const: mpeg-clk
+ - const: ext-32k-0
+ - const: ext-32k-1
+ - const: ext-32k-2
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-aoclkc
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxl-aoclkc
+ - amlogic,meson-gxm-aoclkc
+ - amlogic,meson-axg-aoclkc
+
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ maxItems: 2
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
deleted file mode 100644
index 7ccecd5c02c1..000000000000
--- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Amlogic GXBB Clock and Reset Unit
-
-The Amlogic GXBB clock controller generates and supplies clock to various
-controllers within the SoC.
-
-Required Properties:
-
-- compatible: should be:
- "amlogic,gxbb-clkc" for GXBB SoC,
- "amlogic,gxl-clkc" for GXL and GXM SoC,
- "amlogic,axg-clkc" for AXG SoC.
- "amlogic,g12a-clkc" for G12A SoC.
- "amlogic,g12b-clkc" for G12B SoC.
- "amlogic,sm1-clkc" for SM1 SoC.
-- clocks : list of clock phandle, one for each entry clock-names.
-- clock-names : should contain the following:
- * "xtal": the platform xtal
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/gxbb-clkc.h header and can be
-used in device tree sources.
-
-Parent node should have the following properties :
-- compatible: "syscon", "simple-mfd, and "amlogic,meson-gx-hhi-sysctrl" or
- "amlogic,meson-axg-hhi-sysctrl"
-- reg: base address and size of the HHI system control register space.
-
-Example: Clock controller node:
-
-sysctrl: system-controller@0 {
- compatible = "amlogic,meson-gx-hhi-sysctrl", "syscon", "simple-mfd";
- reg = <0 0 0 0x400>;
-
- clkc: clock-controller {
- #clock-cells = <1>;
- compatible = "amlogic,gxbb-clkc";
- clocks = <&xtal>;
- clock-names = "xtal";
- };
-};
-
-Example: UART controller node that consumes the clock generated by the clock
- controller:
-
- uart_AO: serial@c81004c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc81004c0 0x14>;
- interrupts = <0 90 1>;
- clocks = <&clkc CLKID_CLK81>;
- };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml
new file mode 100644
index 000000000000..63246f1cb539
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,gxbb-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Clock Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,gxbb-clkc
+ - amlogic,gxl-clkc
+ - amlogic,axg-clkc
+ - amlogic,g12a-clkc
+ - amlogic,g12b-clkc
+ - amlogic,sm1-clkc
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xtal
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/amlogic,meson8-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,meson8-clkc.yaml
new file mode 100644
index 000000000000..ab73d4654171
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,meson8-clkc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,meson8-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson8, Meson8b and Meson8m2 Clock and Reset Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson8-clkc
+ - amlogic,meson8b-clkc
+ - items:
+ - const: amlogic,meson8m2-clkc
+ - const: amlogic,meson8-clkc
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: xtal
+ - const: ddr_pll
+ - const: clk_32k
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#reset-cells'
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
index 4b8669f870ec..d98d95d8e8c9 100644
--- a/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
+++ b/Documentation/devicetree/bindings/clock/amlogic,meson8-ddr-clkc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/amlogic,meson8-ddr-clkc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Amlogic DDR Clock Controller Device Tree Bindings
+title: Amlogic DDR Clock Controller
maintainers:
- Martin Blumenstingl <martin.blumenstingl@googlemail.com>
diff --git a/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt
deleted file mode 100644
index cc51e4746b3b..000000000000
--- a/Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-* Amlogic Meson8, Meson8b and Meson8m2 Clock and Reset Unit
-
-The Amlogic Meson8 / Meson8b / Meson8m2 clock controller generates and
-supplies clock to various controllers within the SoC.
-
-Required Properties:
-
-- compatible: must be one of:
- - "amlogic,meson8-clkc" for Meson8 (S802) SoCs
- - "amlogic,meson8b-clkc" for Meson8 (S805) SoCs
- - "amlogic,meson8m2-clkc" for Meson8m2 (S812) SoCs
-- #clock-cells: should be 1.
-- #reset-cells: should be 1.
-- clocks: list of clock phandles, one for each entry in clock-names
-- clock-names: should contain the following:
- * "xtal": the 24MHz system oscillator
- * "ddr_pll": the DDR PLL clock
- * "clk_32k": (if present) the 32kHz clock signal from GPIOAO_6 (CLK_32K_IN)
-
-Parent node should have the following properties :
-- compatible: "amlogic,meson-hhi-sysctrl", "simple-mfd", "syscon"
-- reg: base address and size of the HHI system control register space.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/meson8b-clkc.h header and can be
-used in device tree sources.
-
-Similarly a preprocessor macro for each reset line is defined in
-dt-bindings/reset/amlogic,meson8b-clkc-reset.h (which can be used from the
-device tree sources).
-
-
-Example: Clock controller node:
-
- clkc: clock-controller {
- compatible = "amlogic,meson8b-clkc";
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
-
-
-Example: UART controller node that consumes the clock generated by the clock
- controller:
-
- uart_AO: serial@c81004c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc81004c0 0x14>;
- interrupts = <0 90 1>;
- clocks = <&clkc CLKID_CLK81>;
- };
diff --git a/Documentation/devicetree/bindings/clock/amlogic,s4-peripherals-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,s4-peripherals-clkc.yaml
new file mode 100644
index 000000000000..c229e4f0c1d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,s4-peripherals-clkc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,s4-peripherals-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic S4 Peripherals Clock Controller
+
+maintainers:
+ - Yu Tu <yu.tu@amlogic.com>
+
+properties:
+ compatible:
+ const: amlogic,s4-peripherals-clkc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 14
+ items:
+ - description: input fixed pll div2
+ - description: input fixed pll div2p5
+ - description: input fixed pll div3
+ - description: input fixed pll div4
+ - description: input fixed pll div5
+ - description: input fixed pll div7
+ - description: input hifi pll
+ - description: input gp0 pll
+ - description: input mpll0
+ - description: input mpll1
+ - description: input mpll2
+ - description: input mpll3
+ - description: input hdmi pll
+ - description: input oscillator (usually at 24MHz)
+ - description: input external 32kHz reference (optional)
+
+ clock-names:
+ minItems: 14
+ items:
+ - const: fclk_div2
+ - const: fclk_div2p5
+ - const: fclk_div3
+ - const: fclk_div4
+ - const: fclk_div5
+ - const: fclk_div7
+ - const: hifi_pll
+ - const: gp0_pll
+ - const: mpll0
+ - const: mpll1
+ - const: mpll2
+ - const: mpll3
+ - const: hdmi_pll
+ - const: xtal
+ - const: ext_32k
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,s4-peripherals-clkc.h>
+
+ clkc_periphs: clock-controller@fe000000 {
+ compatible = "amlogic,s4-peripherals-clkc";
+ reg = <0xfe000000 0x49c>;
+ clocks = <&clkc_pll 3>,
+ <&clkc_pll 13>,
+ <&clkc_pll 5>,
+ <&clkc_pll 7>,
+ <&clkc_pll 9>,
+ <&clkc_pll 11>,
+ <&clkc_pll 17>,
+ <&clkc_pll 15>,
+ <&clkc_pll 25>,
+ <&clkc_pll 27>,
+ <&clkc_pll 29>,
+ <&clkc_pll 31>,
+ <&clkc_pll 20>,
+ <&xtal>;
+ clock-names = "fclk_div2", "fclk_div2p5", "fclk_div3", "fclk_div4",
+ "fclk_div5", "fclk_div7", "hifi_pll", "gp0_pll",
+ "mpll0", "mpll1", "mpll2", "mpll3", "hdmi_pll", "xtal";
+ #clock-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml
new file mode 100644
index 000000000000..d8932ec26ca8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,s4-pll-clkc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/amlogic,s4-pll-clkc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic S4 PLL Clock Controller
+
+maintainers:
+ - Yu Tu <yu.tu@amlogic.com>
+
+properties:
+ compatible:
+ const: amlogic,s4-pll-clkc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xtal
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clkc_pll: clock-controller@fe008000 {
+ compatible = "amlogic,s4-pll-clkc";
+ reg = <0xfe008000 0x1e8>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/apm,xgene-device-clock.yaml b/Documentation/devicetree/bindings/clock/apm,xgene-device-clock.yaml
new file mode 100644
index 000000000000..b27bcb2a9ee0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/apm,xgene-device-clock.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/apm,xgene-device-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC device clocks
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+properties:
+ compatible:
+ const: apm,xgene-device-clock
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ items:
+ - enum: [ csr-reg, div-reg ]
+ - const: div-reg
+ minItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ csr-offset:
+ description: Offset to the CSR reset register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ csr-mask:
+ description: CSR reset mask bit
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0xf
+
+ enable-offset:
+ description: Offset to the enable register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 8
+
+ enable-mask:
+ description: CSR enable mask bit
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0xf
+
+ divider-offset:
+ description: Offset to the divider register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ divider-width:
+ description: Width of the divider register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ divider-shift:
+ description: Bit shift of the divider register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - clock-output-names
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/apm,xgene-socpll-clock.yaml b/Documentation/devicetree/bindings/clock/apm,xgene-socpll-clock.yaml
new file mode 100644
index 000000000000..bdd4a6b92bbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/apm,xgene-socpll-clock.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/apm,xgene-socpll-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC PLL, PCPPLL, and PMD clocks
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apm,xgene-pcppll-clock
+ - apm,xgene-pcppll-v2-clock
+ - apm,xgene-pmd-clock
+ - apm,xgene-socpll-clock
+ - apm,xgene-socpll-v2-clock
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - enum: [ csr-reg, div-reg ]
+ - const: div-reg
+ minItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ enum: [ pcppll, socpll ]
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - clock-output-names
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/apple,nco.yaml b/Documentation/devicetree/bindings/clock/apple,nco.yaml
index 74eab5c0d24a..080454f56721 100644
--- a/Documentation/devicetree/bindings/clock/apple,nco.yaml
+++ b/Documentation/devicetree/bindings/clock/apple,nco.yaml
@@ -19,11 +19,17 @@ description: |
properties:
compatible:
- items:
- - enum:
- - apple,t6000-nco
- - apple,t8103-nco
- - const: apple,nco
+ oneOf:
+ - items:
+ - const: apple,t6020-nco
+ - const: apple,t8103-nco
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,t6000-nco
+ - apple,t8103-nco
+ - apple,t8112-nco
+ - const: apple,nco
clocks:
description:
diff --git a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
index 90eadf6869b2..b5533f81307c 100644
--- a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
+++ b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
@@ -81,11 +81,11 @@ properties:
maxItems: 1
lock-offset:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: Offset to the unlocking register for the oscillator
vco-offset:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: Offset to the VCO register for the oscillator
deprecated: true
diff --git a/Documentation/devicetree/bindings/clock/armada3700-periph-clock.txt b/Documentation/devicetree/bindings/clock/armada3700-periph-clock.txt
deleted file mode 100644
index fbf58c443c04..000000000000
--- a/Documentation/devicetree/bindings/clock/armada3700-periph-clock.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Peripheral Clock bindings for Marvell Armada 37xx SoCs
-
-Marvell Armada 37xx SoCs provide peripheral clocks which are
-used as clock source for the peripheral of the SoC.
-
-There are two different blocks associated to north bridge and south
-bridge.
-
-The peripheral clock consumer should specify the desired clock by
-having the clock ID in its "clocks" phandle cell.
-
-The following is a list of provided IDs for Armada 3700 North bridge clocks:
-ID Clock name Description
------------------------------------
-0 mmc MMC controller
-1 sata_host Sata Host
-2 sec_at Security AT
-3 sac_dap Security DAP
-4 tsecm Security Engine
-5 setm_tmx Serial Embedded Trace Module
-6 avs Adaptive Voltage Scaling
-7 sqf SPI
-8 pwm PWM
-9 i2c_2 I2C 2
-10 i2c_1 I2C 1
-11 ddr_phy DDR PHY
-12 ddr_fclk DDR F clock
-13 trace Trace
-14 counter Counter
-15 eip97 EIP 97
-16 cpu CPU
-
-The following is a list of provided IDs for Armada 3700 South bridge clocks:
-ID Clock name Description
------------------------------------
-0 gbe-50 50 MHz parent clock for Gigabit Ethernet
-1 gbe-core parent clock for Gigabit Ethernet core
-2 gbe-125 125 MHz parent clock for Gigabit Ethernet
-3 gbe1-50 50 MHz clock for Gigabit Ethernet port 1
-4 gbe0-50 50 MHz clock for Gigabit Ethernet port 0
-5 gbe1-125 125 MHz clock for Gigabit Ethernet port 1
-6 gbe0-125 125 MHz clock for Gigabit Ethernet port 0
-7 gbe1-core Gigabit Ethernet core port 1
-8 gbe0-core Gigabit Ethernet core port 0
-9 gbe-bm Gigabit Ethernet Buffer Manager
-10 sdio SDIO
-11 usb32-sub2-sys USB 2 clock
-12 usb32-ss-sys USB 3 clock
-13 pcie PCIe controller
-
-Required properties:
-
-- compatible : shall be "marvell,armada-3700-periph-clock-nb" for the
- north bridge block, or
- "marvell,armada-3700-periph-clock-sb" for the south bridge block
-- reg : must be the register address of North/South Bridge Clock register
-- #clock-cells : from common clock binding; shall be set to 1
-
-- clocks : list of the parent clock phandle in the following order:
- TBG-A P, TBG-B P, TBG-A S, TBG-B S and finally the xtal clock.
-
-
-Example:
-
-nb_perih_clk: nb-periph-clk@13000{
- compatible = "marvell,armada-3700-periph-clock-nb";
- reg = <0x13000 0x1000>;
- clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>,
- <&tbg 3>, <&xtalclk>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/armada3700-tbg-clock.txt b/Documentation/devicetree/bindings/clock/armada3700-tbg-clock.txt
deleted file mode 100644
index ed1df32c577a..000000000000
--- a/Documentation/devicetree/bindings/clock/armada3700-tbg-clock.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Time Base Generator Clock bindings for Marvell Armada 37xx SoCs
-
-Marvell Armada 37xx SoCs provide Time Base Generator clocks which are
-used as parent clocks for the peripheral clocks.
-
-The TBG clock consumer should specify the desired clock by having the
-clock ID in its "clocks" phandle cell.
-
-The following is a list of provided IDs and clock names on Armada 3700:
- 0 = TBG A P
- 1 = TBG B P
- 2 = TBG A S
- 3 = TBG B S
-
-Required properties:
-- compatible : shall be "marvell,armada-3700-tbg-clock"
-- reg : must be the register address of North Bridge PLL register
-- #clock-cells : from common clock binding; shall be set to 1
-
-Example:
-
-tbg: tbg@13200 {
- compatible = "marvell,armada-3700-tbg-clock";
- reg = <0x13200 0x1000>;
- clocks = <&xtalclk>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt b/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
deleted file mode 100644
index 4c0807f28cfa..000000000000
--- a/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Xtal Clock bindings for Marvell Armada 37xx SoCs
-
-Marvell Armada 37xx SoCs allow to determine the xtal clock frequencies by
-reading the gpio latch register.
-
-This node must be a subnode of the node exposing the register address
-of the GPIO block where the gpio latch is located.
-See Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
-
-Required properties:
-- compatible : shall be one of the following:
- "marvell,armada-3700-xtal-clock"
-- #clock-cells : from common clock binding; shall be set to 0
-
-Optional properties:
-- clock-output-names : from common clock binding; allows overwrite default clock
- output names ("xtal")
-
-Example:
-pinctrl_nb: pinctrl-nb@13800 {
- compatible = "armada3710-nb-pinctrl", "syscon", "simple-mfd";
- reg = <0x13800 0x100>, <0x13C00 0x20>;
-
- xtalclk: xtal-clk {
- compatible = "marvell,armada-3700-xtal-clock";
- clock-output-names = "xtal";
- #clock-cells = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/artpec6.txt b/Documentation/devicetree/bindings/clock/artpec6.txt
deleted file mode 100644
index dff9cdf0009c..000000000000
--- a/Documentation/devicetree/bindings/clock/artpec6.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Clock bindings for Axis ARTPEC-6 chip
-
-The bindings are based on the clock provider binding in
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-External clocks:
-----------------
-
-There are two external inputs to the main clock controller which should be
-provided using the common clock bindings.
-- "sys_refclk": External 50 Mhz oscillator (required)
-- "i2s_refclk": Alternate audio reference clock (optional).
-
-Main clock controller
----------------------
-
-Required properties:
-- #clock-cells: Should be <1>
- See dt-bindings/clock/axis,artpec6-clkctrl.h for the list of valid identifiers.
-- compatible: Should be "axis,artpec6-clkctrl"
-- reg: Must contain the base address and length of the system controller
-- clocks: Must contain a phandle entry for each clock in clock-names
-- clock-names: Must include the external oscillator ("sys_refclk"). Optional
- ones are the audio reference clock ("i2s_refclk") and the audio fractional
- dividers ("frac_clk0" and "frac_clk1").
-
-Examples:
-
-ext_clk: ext_clk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <50000000>;
-};
-
-clkctrl: clkctrl@f8000000 {
- #clock-cells = <1>;
- compatible = "axis,artpec6-clkctrl";
- reg = <0xf8000000 0x48>;
- clocks = <&ext_clk>;
- clock-names = "sys_refclk";
-};
diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
deleted file mode 100644
index 13f45db3b66d..000000000000
--- a/Documentation/devicetree/bindings/clock/at91-clock.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-Device Tree Clock bindings for arch-at91
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Slow Clock controller:
-
-Required properties:
-- compatible : shall be one of the following:
- "atmel,at91sam9x5-sckc",
- "atmel,sama5d3-sckc",
- "atmel,sama5d4-sckc" or
- "microchip,sam9x60-sckc":
- at91 SCKC (Slow Clock Controller)
-- #clock-cells : shall be 1 for "microchip,sam9x60-sckc" otherwise shall be 0.
-- clocks : shall be the input parent clock phandle for the clock.
-
-Optional properties:
-- atmel,osc-bypass : boolean property. Set this when a clock signal is directly
- provided on XIN.
-
-For example:
- sckc@fffffe50 {
- compatible = "atmel,at91sam9x5-sckc";
- reg = <0xfffffe50 0x4>;
- clocks = <&slow_xtal>;
- #clock-cells = <0>;
- };
-
-Power Management Controller (PMC):
-
-Required properties:
-- compatible : shall be "atmel,<chip>-pmc", "syscon" or
- "microchip,sam9x60-pmc"
- <chip> can be: at91rm9200, at91sam9260, at91sam9261,
- at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9g15,
- at91sam9g25, at91sam9g35, at91sam9x25, at91sam9x35, at91sam9x5,
- sama5d2, sama5d3 or sama5d4.
-- #clock-cells : from common clock binding; shall be set to 2. The first entry
- is the type of the clock (core, system, peripheral or generated) and the
- second entry its index as provided by the datasheet
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names: Must include the following entries: "slow_clk", "main_xtal"
-
-Optional properties:
-- atmel,osc-bypass : boolean property. Set this when a clock signal is directly
- provided on XIN.
-
-For example:
- pmc: pmc@f0018000 {
- compatible = "atmel,sama5d4-pmc", "syscon";
- reg = <0xf0018000 0x120>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
- #clock-cells = <2>;
- clocks = <&clk32k>, <&main_xtal>;
- clock-names = "slow_clk", "main_xtal";
- };
diff --git a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml
new file mode 100644
index 000000000000..e803a1fc3681
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/atmel,at91rm9200-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Power Management Controller (PMC)
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description:
+ The power management controller optimizes power consumption by controlling all
+ system and user peripheral clocks. The PMC enables/disables the clock inputs
+ to many of the peripherals and to the processor.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: atmel,at91sam9g20-pmc
+ - const: atmel,at91sam9260-pmc
+ - const: syscon
+ - items:
+ - enum:
+ - atmel,at91sam9g15-pmc
+ - atmel,at91sam9g25-pmc
+ - atmel,at91sam9g35-pmc
+ - atmel,at91sam9x25-pmc
+ - atmel,at91sam9x35-pmc
+ - const: atmel,at91sam9x5-pmc
+ - const: syscon
+ - items:
+ - enum:
+ - atmel,at91rm9200-pmc
+ - atmel,at91sam9260-pmc
+ - atmel,at91sam9261-pmc
+ - atmel,at91sam9263-pmc
+ - atmel,at91sam9g45-pmc
+ - atmel,at91sam9n12-pmc
+ - atmel,at91sam9rl-pmc
+ - atmel,at91sam9x5-pmc
+ - atmel,sama5d2-pmc
+ - atmel,sama5d3-pmc
+ - atmel,sama5d4-pmc
+ - microchip,sam9x60-pmc
+ - microchip,sam9x7-pmc
+ - microchip,sama7d65-pmc
+ - microchip,sama7g5-pmc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#clock-cells":
+ description: |
+ - 1st cell is the clock type, one of PMC_TYPE_CORE, PMC_TYPE_SYSTEM,
+ PMC_TYPE_PERIPHERAL, PMC_TYPE_GCK, PMC_TYPE_PROGRAMMABLE (as defined
+ in <dt-bindings/clock/at91.h>)
+ - 2nd cell is the clock identifier as defined in <dt-bindings/clock/at91.h
+ (for core clocks) or as defined in datasheet (for system, peripheral,
+ gck and programmable clocks).
+ const: 2
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ atmel,osc-bypass:
+ description: set when a clock signal is directly provided on XIN
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#clock-cells"
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,sam9x60-pmc
+ - microchip,sam9x7-pmc
+ - microchip,sama7d65-pmc
+ - microchip,sama7g5-pmc
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: td_slck
+ - const: md_slck
+ - const: main_xtal
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,at91rm9200-pmc
+ - atmel,at91sam9260-pmc
+ - atmel,at91sam9261-pmc
+ - atmel,at91sam9263-pmc
+ - atmel,at91sam9g20-pmc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: slow_xtal
+ - const: main_xtal
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,sama5d2-pmc
+ - atmel,sama5d3-pmc
+ - atmel,sama5d4-pmc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: slow_clk
+ - const: main_xtal
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmc: clock-controller@f0018000 {
+ compatible = "atmel,sama5d4-pmc", "syscon";
+ reg = <0xf0018000 0x120>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ #clock-cells = <2>;
+ clocks = <&clk32k>, <&main_xtal>;
+ clock-names = "slow_clk", "main_xtal";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml
new file mode 100644
index 000000000000..d4cf8ae2961e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/atmel,at91sam9x5-sckc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/atmel,at91sam9x5-sckc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Slow Clock Controller (SCKC)
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91sam9x5-sckc
+ - atmel,sama5d3-sckc
+ - atmel,sama5d4-sckc
+ - microchip,sam9x60-sckc
+ - items:
+ - enum:
+ - microchip,sam9x7-sckc
+ - microchip,sama7d65-sckc
+ - microchip,sama7g5-sckc
+ - const: microchip,sam9x60-sckc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ enum: [0, 1]
+
+ atmel,osc-bypass:
+ type: boolean
+ description: set when a clock signal is directly provided on XIN
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,sam9x60-sckc
+ then:
+ properties:
+ "#clock-cells":
+ const: 1
+ else:
+ properties:
+ "#clock-cells":
+ const: 0
+
+additionalProperties: false
+
+examples:
+ - |
+ clk32k: clock-controller@fffffe50 {
+ compatible = "microchip,sam9x60-sckc";
+ reg = <0xfffffe50 0x4>;
+ clocks = <&slow_xtal>;
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/axis,artpec6-clkctrl.yaml b/Documentation/devicetree/bindings/clock/axis,artpec6-clkctrl.yaml
new file mode 100644
index 000000000000..a78269369df8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axis,artpec6-clkctrl.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/axis,artpec6-clkctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axis ARTPEC-6 clock controller
+
+maintainers:
+ - Lars Persson <lars.persson@axis.com>
+
+properties:
+ compatible:
+ const: axis,artpec6-clkctrl
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: external 50 MHz oscillator.
+ - description: optional audio reference clock.
+ - description: fractional audio clock divider 0.
+ - description: fractional audio clock divider 1.
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: sys_refclk
+ - const: i2s_refclk
+ - const: frac_clk0
+ - const: frac_clk1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@f8000000 {
+ compatible = "axis,artpec6-clkctrl";
+ reg = <0xf8000000 0x48>;
+ #clock-cells = <1>;
+ clocks = <&ext_clk>;
+ clock-names = "sys_refclk";
+ };
diff --git a/Documentation/devicetree/bindings/clock/axis,artpec8-clock.yaml b/Documentation/devicetree/bindings/clock/axis,artpec8-clock.yaml
new file mode 100644
index 000000000000..277af48ac841
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axis,artpec8-clock.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/axis,artpec8-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axis ARTPEC-8 SoC clock controller
+
+maintainers:
+ - Jesper Nilsson <jesper.nilsson@axis.com>
+
+description: |
+ ARTPEC-8 clock controller is comprised of several CMU (Clock Management Unit)
+ units, generating clocks for different domains. Those CMU units are modeled
+ as separate device tree nodes, and might depend on each other.
+ The root clock in that root tree is an external clock: OSCCLK (25 MHz).
+ This external clock must be defined as a fixed-rate clock in dts.
+
+ CMU_CMU is a top-level CMU, where all base clocks are prepared using PLLs and
+ dividers; all other clocks of function blocks (other CMUs) are usually
+ derived from CMU_CMU.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ 'include/dt-bindings/clock/axis,artpec8-clk.h' header.
+
+properties:
+ compatible:
+ enum:
+ - axis,artpec8-cmu-cmu
+ - axis,artpec8-cmu-bus
+ - axis,artpec8-cmu-core
+ - axis,artpec8-cmu-cpucl
+ - axis,artpec8-cmu-fsys
+ - axis,artpec8-cmu-imem
+ - axis,artpec8-cmu-peri
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+
+ clock-names:
+ minItems: 1
+ maxItems: 5
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-cmu
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+
+ clock-names:
+ items:
+ - const: fin_pll
+
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-bus
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+ - description: CMU_BUS BUS clock (from CMU_CMU)
+ - description: CMU_BUS DLP clock (from CMU_CMU)
+
+ clock-names:
+ items:
+ - const: fin_pll
+ - const: bus
+ - const: dlp
+
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-core
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+ - description: CMU_CORE main clock (from CMU_CMU)
+ - description: CMU_CORE DLP clock (from CMU_CMU)
+
+ clock-names:
+ items:
+ - const: fin_pll
+ - const: main
+ - const: dlp
+
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-cpucl
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+ - description: CMU_CPUCL switch clock (from CMU_CMU)
+
+ clock-names:
+ items:
+ - const: fin_pll
+ - const: switch
+
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-fsys
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+ - description: CMU_FSYS SCAN0 clock (from CMU_CMU)
+ - description: CMU_FSYS SCAN1 clock (from CMU_CMU)
+ - description: CMU_FSYS BUS clock (from CMU_CMU)
+ - description: CMU_FSYS IP clock (from CMU_CMU)
+
+ clock-names:
+ items:
+ - const: fin_pll
+ - const: scan0
+ - const: scan1
+ - const: bus
+ - const: ip
+
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-imem
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+ - description: CMU_IMEM ACLK clock (from CMU_CMU)
+ - description: CMU_IMEM JPEG clock (from CMU_CMU)
+
+ clock-names:
+ items:
+ - const: fin_pll
+ - const: aclk
+ - const: jpeg
+
+ - if:
+ properties:
+ compatible:
+ const: axis,artpec8-cmu-peri
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25 MHz)
+ - description: CMU_PERI IP clock (from CMU_CMU)
+ - description: CMU_PERI AUDIO clock (from CMU_CMU)
+ - description: CMU_PERI DISP clock (from CMU_CMU)
+
+ clock-names:
+ items:
+ - const: fin_pll
+ - const: ip
+ - const: audio
+ - const: disp
+
+additionalProperties: false
+
+examples:
+ # Clock controller node for CMU_FSYS
+ - |
+ #include <dt-bindings/clock/axis,artpec8-clk.h>
+
+ cmu_fsys: clock-controller@16c10000 {
+ compatible = "axis,artpec8-cmu-fsys";
+ reg = <0x16c10000 0x4000>;
+ #clock-cells = <1>;
+ clocks = <&fin_pll>,
+ <&cmu_cmu CLK_DOUT_CMU_FSYS_SCAN0>,
+ <&cmu_cmu CLK_DOUT_CMU_FSYS_SCAN1>,
+ <&cmu_cmu CLK_DOUT_CMU_FSYS_BUS>,
+ <&cmu_cmu CLK_DOUT_CMU_FSYS_IP>;
+ clock-names = "fin_pll", "scan0", "scan1", "bus", "ip";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
index bd4cefbb1244..30252c95700c 100644
--- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
+++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
@@ -134,9 +134,13 @@ properties:
"#reset-cells":
const: 1
- clocks: true
+ clocks:
+ minItems: 3
+ maxItems: 4
- clock-names: true
+ clock-names:
+ minItems: 3
+ maxItems: 4
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
index 624984d51c10..7f8d98226437 100644
--- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
+++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
@@ -125,7 +125,7 @@ examples:
clk25m: clock-oscillator-25m {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <25000000>;
+ clock-frequency = <25000000>;
clock-output-names = "clk25m";
};
...
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
index 08543ecbe35b..2d40df2d34df 100644
--- a/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/brcm,bcm2711-dvp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM2711 HDMI DVP Device Tree Bindings
+title: Broadcom BCM2711 HDMI DVP
maintainers:
- Maxime Ripard <mripard@kernel.org>
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
deleted file mode 100644
index 4acfc8f641b6..000000000000
--- a/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Broadcom BCM2835 auxiliary peripheral support
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-The auxiliary peripherals (UART, SPI1, and SPI2) have a small register
-area controlling clock gating to the peripherals, and providing an IRQ
-status register.
-
-Required properties:
-- compatible: Should be "brcm,bcm2835-aux"
-- #clock-cells: Should be <1>. The permitted clock-specifier values can be
- found in include/dt-bindings/clock/bcm2835-aux.h
-- reg: Specifies base physical address and size of the registers
-- clocks: The parent clock phandle
-
-Example:
-
- clocks: cprman@7e101000 {
- compatible = "brcm,bcm2835-cprman";
- #clock-cells = <1>;
- reg = <0x7e101000 0x2000>;
- clocks = <&clk_osc>;
- };
-
- aux: aux@7e215004 {
- compatible = "brcm,bcm2835-aux";
- #clock-cells = <1>;
- reg = <0x7e215000 0x8>;
- clocks = <&clocks BCM2835_CLOCK_VPU>;
- };
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.yaml
new file mode 100644
index 000000000000..0f4050ffa41c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,bcm2835-aux-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 auxiliary peripheral clock
+
+maintainers:
+ - Stefan Wahren <wahrenst@gmx.net>
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description:
+ The auxiliary peripherals (UART, SPI1, and SPI2) have a small register
+ area controlling clock gating to the peripherals, and providing an IRQ
+ status register.
+
+properties:
+ compatible:
+ const: brcm,bcm2835-aux
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+ clock@7e215000 {
+ compatible = "brcm,bcm2835-aux";
+ reg = <0x7e215000 0x8>;
+ #clock-cells = <1>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt
deleted file mode 100644
index 9e0b03a6519b..000000000000
--- a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Broadcom BCM2835 CPRMAN clocks
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-The CPRMAN clock controller generates clocks in the audio power domain
-of the BCM2835. There is a level of PLLs deriving from an external
-oscillator, a level of PLL dividers that produce channels off of the
-few PLLs, and a level of mostly-generic clock generators sourcing from
-the PLL channels. Most other hardware components source from the
-clock generators, but a few (like the ARM or HDMI) will source from
-the PLL dividers directly.
-
-Required properties:
-- compatible: should be one of the following,
- "brcm,bcm2711-cprman"
- "brcm,bcm2835-cprman"
-- #clock-cells: Should be <1>. The permitted clock-specifier values can be
- found in include/dt-bindings/clock/bcm2835.h
-- reg: Specifies base physical address and size of the registers
-- clocks: phandles to the parent clocks used as input to the module, in
- the following order:
-
- - External oscillator
- - DSI0 byte clock
- - DSI0 DDR2 clock
- - DSI0 DDR clock
- - DSI1 byte clock
- - DSI1 DDR2 clock
- - DSI1 DDR clock
-
- Only external oscillator is required. The DSI clocks may
- not be present, in which case their children will be
- unusable.
-
-Example:
-
- clk_osc: clock@3 {
- compatible = "fixed-clock";
- reg = <3>;
- #clock-cells = <0>;
- clock-output-names = "osc";
- clock-frequency = <19200000>;
- };
-
- clocks: cprman@7e101000 {
- compatible = "brcm,bcm2835-cprman";
- #clock-cells = <1>;
- reg = <0x7e101000 0x2000>;
- clocks = <&clk_osc>;
- };
-
- i2c0: i2c@7e205000 {
- compatible = "brcm,bcm2835-i2c";
- reg = <0x7e205000 0x1000>;
- interrupts = <2 21>;
- clocks = <&clocks BCM2835_CLOCK_VPU>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.yaml
new file mode 100644
index 000000000000..b0cf76c74bc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,bcm2835-cprman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 CPRMAN clocks
+
+maintainers:
+ - Stefan Wahren <wahrenst@gmx.net>
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description:
+ The CPRMAN clock controller generates clocks in the audio power domain of the
+ BCM2835. There is a level of PLLs deriving from an external oscillator, a
+ level of PLL dividers that produce channels off of the few PLLs, and a level
+ of mostly-generic clock generators sourcing from the PLL channels. Most other
+ hardware components source from the clock generators, but a few (like the ARM
+ or HDMI) will source from the PLL dividers directly.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2711-cprman
+ - brcm,bcm2835-cprman
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: External oscillator clock.
+ - description: DSI0 byte clock.
+ - description: DSI0 DDR2 clock.
+ - description: DSI0 DDR clock.
+ - description: DSI1 byte clock.
+ - description: DSI1 DDR2 clock.
+ - description: DSI1 DDR clock.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - clocks
+
+examples:
+ - |
+ clock-controller@7e101000 {
+ compatible = "brcm,bcm2835-cprman";
+ reg = <0x7e101000 0x2000>;
+ #clock-cells = <1>;
+ clocks = <&clk_osc>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.txt b/Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.txt
deleted file mode 100644
index 2ebb107331dd..000000000000
--- a/Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Broadcom BCM53573 ILP clock
-===========================
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-This binding is used for ILP clock (sometimes referred as "slow clock")
-on Broadcom BCM53573 devices using Cortex-A7 CPU.
-
-ILP's rate has to be calculated on runtime and it depends on ALP clock
-which has to be referenced.
-
-This clock is part of PMU (Power Management Unit), a Broadcom's device
-handing power-related aspects. Its node must be sub-node of the PMU
-device.
-
-Required properties:
-- compatible: "brcm,bcm53573-ilp"
-- clocks: has to reference an ALP clock
-- #clock-cells: should be <0>
-- clock-output-names: from common clock bindings, should contain clock
- name
-
-Example:
-
-pmu@18012000 {
- compatible = "simple-mfd", "syscon";
- reg = <0x18012000 0x00001000>;
-
- ilp {
- compatible = "brcm,bcm53573-ilp";
- clocks = <&alp>;
- #clock-cells = <0>;
- clock-output-names = "ilp";
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.yaml
new file mode 100644
index 000000000000..cd291f428a8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm53573-ilp.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,bcm53573-ilp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM53573 ILP clock
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+description: >
+ ILP clock (sometimes referred as "slow clock") on Broadcom BCM53573 devices
+ using Cortex-A7 CPU.
+
+ ILP's rate has to be calculated on runtime and it depends on ALP clock which
+ has to be referenced.
+
+ This clock is part of PMU (Power Management Unit), a Broadcom device handling
+ power-related aspects. Its node must be sub-node of the PMU device.
+
+properties:
+ compatible:
+ items:
+ - const: brcm,bcm53573-ilp
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ clock-output-names:
+ items:
+ - const: ilp
+
+additionalProperties: false
+
+examples:
+ - |
+ ilp {
+ compatible = "brcm,bcm53573-ilp";
+ clocks = <&alp>;
+ #clock-cells = <0>;
+ clock-output-names = "ilp";
+ };
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml
new file mode 100644
index 000000000000..cd0d763ce2f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,bcm63268-timer-clocks.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM63268 Timer Clock and Reset
+
+maintainers:
+ - Álvaro Fernández Rojas <noltari@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,bcm63268-timer-clocks
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ timer_clk: clock-controller@100000ac {
+ compatible = "brcm,bcm63268-timer-clocks";
+ reg = <0x100000ac 0x4>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt
deleted file mode 100644
index 3e7ca5530775..000000000000
--- a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Gated Clock Controller Bindings for MIPS based BCM63XX SoCs
-
-Required properties:
-- compatible: must be one of:
- "brcm,bcm3368-clocks"
- "brcm,bcm6318-clocks"
- "brcm,bcm6318-ubus-clocks"
- "brcm,bcm6328-clocks"
- "brcm,bcm6358-clocks"
- "brcm,bcm6362-clocks"
- "brcm,bcm6368-clocks"
- "brcm,bcm63268-clocks"
-
-- reg: Address and length of the register set
-- #clock-cells: must be <1>
-
-
-Example:
-
-clkctl: clock-controller@10000004 {
- compatible = "brcm,bcm6328-clocks";
- reg = <0x10000004 0x4>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.yaml
new file mode 100644
index 000000000000..56909ea499a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,bcm63xx-clocks.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS based BCM63XX SoCs Gated Clock Controller
+
+maintainers:
+ - Álvaro Fernández Rojas <noltari@gmail.com>
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm3368-clocks
+ - brcm,bcm6318-clocks
+ - brcm,bcm6318-ubus-clocks
+ - brcm,bcm6328-clocks
+ - brcm,bcm6358-clocks
+ - brcm,bcm6362-clocks
+ - brcm,bcm6368-clocks
+ - brcm,bcm63268-clocks
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@10000004 {
+ compatible = "brcm,bcm6328-clocks";
+ reg = <0x10000004 0x4>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/brcm,kona-ccu.txt b/Documentation/devicetree/bindings/clock/brcm,kona-ccu.txt
deleted file mode 100644
index 8e5a7d868557..000000000000
--- a/Documentation/devicetree/bindings/clock/brcm,kona-ccu.txt
+++ /dev/null
@@ -1,138 +0,0 @@
-Broadcom Kona Family Clocks
-
-This binding is associated with Broadcom SoCs having "Kona" style
-clock control units (CCUs). A CCU is a clock provider that manages
-a set of clock signals. Each CCU is represented by a node in the
-device tree.
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible
- Shall have a value of the form "brcm,<model>-<which>-ccu",
- where <model> is a Broadcom SoC model number and <which> is
- the name of a defined CCU. For example:
- "brcm,bcm11351-root-ccu"
- The compatible strings used for each supported SoC family
- are defined below.
-- reg
- Shall define the base and range of the address space
- containing clock control registers
-- #clock-cells
- Shall have value <1>. The permitted clock-specifier values
- are defined below.
-- clock-output-names
- Shall be an ordered list of strings defining the names of
- the clocks provided by the CCU.
-
-Device tree example:
-
- slave_ccu: slave_ccu {
- compatible = "brcm,bcm11351-slave-ccu";
- reg = <0x3e011000 0x0f00>;
- #clock-cells = <1>;
- clock-output-names = "uartb",
- "uartb2",
- "uartb3",
- "uartb4";
- };
-
- ref_crystal_clk: ref_crystal {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <26000000>;
- };
-
- uart@3e002000 {
- compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
- reg = <0x3e002000 0x1000>;
- clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
- interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
- reg-shift = <2>;
- reg-io-width = <4>;
- };
-
-BCM281XX family
----------------
-CCU compatible string values for SoCs in the BCM281XX family are:
- "brcm,bcm11351-root-ccu"
- "brcm,bcm11351-aon-ccu"
- "brcm,bcm11351-hub-ccu"
- "brcm,bcm11351-master-ccu"
- "brcm,bcm11351-slave-ccu"
-
-The following table defines the set of CCUs and clock specifiers for
-BCM281XX family clocks. When a clock consumer references a clocks,
-its symbolic specifier (rather than its numeric index value) should
-be used. These specifiers are defined in:
- "include/dt-bindings/clock/bcm281xx.h"
-
- CCU Clock Type Index Specifier
- --- ----- ---- ----- ---------
- root frac_1m peri 0 BCM281XX_ROOT_CCU_FRAC_1M
-
- aon hub_timer peri 0 BCM281XX_AON_CCU_HUB_TIMER
- aon pmu_bsc peri 1 BCM281XX_AON_CCU_PMU_BSC
- aon pmu_bsc_var peri 2 BCM281XX_AON_CCU_PMU_BSC_VAR
-
- hub tmon_1m peri 0 BCM281XX_HUB_CCU_TMON_1M
-
- master sdio1 peri 0 BCM281XX_MASTER_CCU_SDIO1
- master sdio2 peri 1 BCM281XX_MASTER_CCU_SDIO2
- master sdio3 peri 2 BCM281XX_MASTER_CCU_SDIO3
- master sdio4 peri 3 BCM281XX_MASTER_CCU_SDIO4
- master dmac peri 4 BCM281XX_MASTER_CCU_DMAC
- master usb_ic peri 5 BCM281XX_MASTER_CCU_USB_IC
- master hsic2_48m peri 6 BCM281XX_MASTER_CCU_HSIC_48M
- master hsic2_12m peri 7 BCM281XX_MASTER_CCU_HSIC_12M
-
- slave uartb peri 0 BCM281XX_SLAVE_CCU_UARTB
- slave uartb2 peri 1 BCM281XX_SLAVE_CCU_UARTB2
- slave uartb3 peri 2 BCM281XX_SLAVE_CCU_UARTB3
- slave uartb4 peri 3 BCM281XX_SLAVE_CCU_UARTB4
- slave ssp0 peri 4 BCM281XX_SLAVE_CCU_SSP0
- slave ssp2 peri 5 BCM281XX_SLAVE_CCU_SSP2
- slave bsc1 peri 6 BCM281XX_SLAVE_CCU_BSC1
- slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2
- slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3
- slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM
-
-
-BCM21664 family
----------------
-CCU compatible string values for SoCs in the BCM21664 family are:
- "brcm,bcm21664-root-ccu"
- "brcm,bcm21664-aon-ccu"
- "brcm,bcm21664-master-ccu"
- "brcm,bcm21664-slave-ccu"
-
-The following table defines the set of CCUs and clock specifiers for
-BCM21664 family clocks. When a clock consumer references a clocks,
-its symbolic specifier (rather than its numeric index value) should
-be used. These specifiers are defined in:
- "include/dt-bindings/clock/bcm21664.h"
-
- CCU Clock Type Index Specifier
- --- ----- ---- ----- ---------
- root frac_1m peri 0 BCM21664_ROOT_CCU_FRAC_1M
-
- aon hub_timer peri 0 BCM21664_AON_CCU_HUB_TIMER
-
- master sdio1 peri 0 BCM21664_MASTER_CCU_SDIO1
- master sdio2 peri 1 BCM21664_MASTER_CCU_SDIO2
- master sdio3 peri 2 BCM21664_MASTER_CCU_SDIO3
- master sdio4 peri 3 BCM21664_MASTER_CCU_SDIO4
- master sdio1_sleep peri 4 BCM21664_MASTER_CCU_SDIO1_SLEEP
- master sdio2_sleep peri 5 BCM21664_MASTER_CCU_SDIO2_SLEEP
- master sdio3_sleep peri 6 BCM21664_MASTER_CCU_SDIO3_SLEEP
- master sdio4_sleep peri 7 BCM21664_MASTER_CCU_SDIO4_SLEEP
-
- slave uartb peri 0 BCM21664_SLAVE_CCU_UARTB
- slave uartb2 peri 1 BCM21664_SLAVE_CCU_UARTB2
- slave uartb3 peri 2 BCM21664_SLAVE_CCU_UARTB3
- slave uartb4 peri 3 BCM21664_SLAVE_CCU_UARTB4
- slave bsc1 peri 4 BCM21664_SLAVE_CCU_BSC1
- slave bsc2 peri 5 BCM21664_SLAVE_CCU_BSC2
- slave bsc3 peri 6 BCM21664_SLAVE_CCU_BSC3
- slave bsc4 peri 7 BCM21664_SLAVE_CCU_BSC4
diff --git a/Documentation/devicetree/bindings/clock/brcm,kona-ccu.yaml b/Documentation/devicetree/bindings/clock/brcm,kona-ccu.yaml
new file mode 100644
index 000000000000..e5656950b3bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,kona-ccu.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,kona-ccu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family clock control units (CCU)
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+description: |
+ Broadcom "Kona" style clock control unit (CCU) is a clock provider that
+ manages a set of clock signals.
+
+ All available clock IDs are defined in
+ - include/dt-bindings/clock/bcm281xx.h for BCM281XX family
+ - include/dt-bindings/clock/bcm21664.h for BCM21664 family
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm11351-aon-ccu
+ - brcm,bcm11351-hub-ccu
+ - brcm,bcm11351-master-ccu
+ - brcm,bcm11351-root-ccu
+ - brcm,bcm11351-slave-ccu
+ - brcm,bcm21664-aon-ccu
+ - brcm,bcm21664-master-ccu
+ - brcm,bcm21664-root-ccu
+ - brcm,bcm21664-slave-ccu
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clock-output-names:
+ minItems: 1
+ maxItems: 10
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clock-output-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm11351-aon-ccu
+ then:
+ properties:
+ clock-output-names:
+ items:
+ - const: hub_timer
+ - const: pmu_bsc
+ - const: pmu_bsc_var
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm11351-hub-ccu
+ then:
+ properties:
+ clock-output-names:
+ const: tmon_1m
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm11351-master-ccu
+ then:
+ properties:
+ clock-output-names:
+ items:
+ - const: sdio1
+ - const: sdio2
+ - const: sdio3
+ - const: sdio4
+ - const: usb_ic
+ - const: hsic2_48m
+ - const: hsic2_12m
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm11351-root-ccu
+ - brcm,bcm21664-root-ccu
+ then:
+ properties:
+ clock-output-names:
+ const: frac_1m
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm11351-slave-ccu
+ then:
+ properties:
+ clock-output-names:
+ items:
+ - const: uartb
+ - const: uartb2
+ - const: uartb3
+ - const: uartb4
+ - const: ssp0
+ - const: ssp2
+ - const: bsc1
+ - const: bsc2
+ - const: bsc3
+ - const: pwm
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm21664-aon-ccu
+ then:
+ properties:
+ clock-output-names:
+ const: hub_timer
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm21664-master-ccu
+ then:
+ properties:
+ clock-output-names:
+ items:
+ - const: sdio1
+ - const: sdio2
+ - const: sdio3
+ - const: sdio4
+ - const: sdio1_sleep
+ - const: sdio2_sleep
+ - const: sdio3_sleep
+ - const: sdio4_sleep
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm21664-slave-ccu
+ then:
+ properties:
+ clock-output-names:
+ items:
+ - const: uartb
+ - const: uartb2
+ - const: uartb3
+ - const: bsc1
+ - const: bsc2
+ - const: bsc3
+ - const: bsc4
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@3e011000 {
+ compatible = "brcm,bcm11351-slave-ccu";
+ reg = <0x3e011000 0x0f00>;
+ #clock-cells = <1>;
+ clock-output-names = "uartb",
+ "uartb2",
+ "uartb3",
+ "uartb4",
+ "ssp0",
+ "ssp2",
+ "bsc1",
+ "bsc2",
+ "bsc3",
+ "pwm";
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/calxeda.yaml b/Documentation/devicetree/bindings/clock/calxeda.yaml
index a34cbf3c9aaf..a88fbe20fef1 100644
--- a/Documentation/devicetree/bindings/clock/calxeda.yaml
+++ b/Documentation/devicetree/bindings/clock/calxeda.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/calxeda.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device Tree Clock bindings for Calxeda highbank platform
+title: Calxeda highbank platform Clock Controller
description: |
This binding covers the Calxeda SoC internal peripheral and bus clocks
diff --git a/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml b/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml
index 7f5cf4001f76..380cb6d80025 100644
--- a/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/clock/canaan,k210-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Canaan Kendryte K210 Clock Device Tree Bindings
+title: Canaan Kendryte K210 Clock
maintainers:
- - Damien Le Moal <damien.lemoal@wdc.com>
+ - Damien Le Moal <dlemoal@kernel.org>
description: |
Canaan Kendryte K210 SoC clocks driver bindings. The clock
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index 0abd6ba82dfd..d416c374e853 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/cirrus,cs2000-cp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+title: CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
@@ -23,7 +23,6 @@ properties:
clocks:
description:
Common clock binding for CLK_IN, XTI/REF_CLK
- minItems: 2
maxItems: 2
clock-names:
diff --git a/Documentation/devicetree/bindings/clock/cirrus,ep7209-clk.yaml b/Documentation/devicetree/bindings/clock/cirrus,ep7209-clk.yaml
new file mode 100644
index 000000000000..fbd0d50d46a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cirrus,ep7209-clk.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/cirrus,ep7209-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CLPS711X Clock Controller
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+description:
+ See include/dt-bindings/clock/clps711x-clock.h for the full list of CLPS711X
+ clock IDs.
+
+properties:
+ compatible:
+ items:
+ - const: cirrus,ep7312-clk
+ - const: cirrus,ep7209-clk
+
+ reg:
+ maxItems: 1
+
+ startup-frequency:
+ description: Factory set CPU startup frequency in HZ.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - startup-frequency
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@80000000 {
+ compatible = "cirrus,ep7312-clk", "cirrus,ep7209-clk";
+ reg = <0x80000000 0xc000>;
+ #clock-cells = <1>;
+ startup-frequency = <73728000>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
index 59de125647ec..ccff74eda9fb 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
@@ -67,9 +67,9 @@ properties:
minItems: 1
maxItems: 19
- clocks: true
- assigned-clocks: true
- assigned-clock-parents: true
+ clocks:
+ minItems: 1
+ maxItems: 19
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/clps711x-clock.txt b/Documentation/devicetree/bindings/clock/clps711x-clock.txt
deleted file mode 100644
index f1bd53f79d91..000000000000
--- a/Documentation/devicetree/bindings/clock/clps711x-clock.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Clock bindings for the Cirrus Logic CLPS711X CPUs
-
-Required properties:
-- compatible : Shall contain "cirrus,ep7209-clk".
-- reg : Address of the internal register set.
-- startup-frequency: Factory set CPU startup frequency in HZ.
-- #clock-cells : Should be <1>.
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/clps711x-clock.h
-for the full list of CLPS711X clock IDs.
-
-Example:
- clks: clks@80000000 {
- #clock-cells = <1>;
- compatible = "cirrus,ep7312-clk", "cirrus,ep7209-clk";
- reg = <0x80000000 0xc000>;
- startup-frequency = <73728000>;
- };
diff --git a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
deleted file mode 100644
index 217871f483c0..000000000000
--- a/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-PLL divider based Dove clocks
-
-Marvell Dove has a 2GHz PLL, which feeds into a set of dividers to provide
-high speed clocks for a number of peripherals. These dividers are part of
-the PMU, and thus this node should be a child of the PMU node.
-
-The following clocks are provided:
-
-ID Clock
--------------
-0 AXI bus clock
-1 GPU clock
-2 VMeta clock
-3 LCD clock
-
-Required properties:
-- compatible : shall be "marvell,dove-divider-clock"
-- reg : shall be the register address of the Core PLL and Clock Divider
- Control 0 register. This will cover that register, as well as the
- Core PLL and Clock Divider Control 1 register. Thus, it will have
- a size of 8.
-- #clock-cells : from common clock binding; shall be set to 1
-
-divider_clk: core-clock@64 {
- compatible = "marvell,dove-divider-clock";
- reg = <0x0064 0x8>;
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-clock.yaml
index b657ecd0ef1c..90fb10660684 100644
--- a/Documentation/devicetree/bindings/clock/fixed-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/fixed-clock.yaml
@@ -4,13 +4,22 @@
$id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for simple fixed-rate clock sources
+title: Simple fixed-rate clock sources
maintainers:
- Michael Turquette <mturquette@baylibre.com>
- Stephen Boyd <sboyd@kernel.org>
properties:
+ $nodename:
+ anyOf:
+ - description:
+ Preferred name is 'clock-<freq>' with <freq> being the output
+ frequency as defined in the 'clock-frequency' property.
+ pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
+ - description: Any name allowed
+ deprecated: true
+
compatible:
const: fixed-clock
diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
index 0b02378a3a0c..4afdb1c98f5f 100644
--- a/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
@@ -4,13 +4,22 @@
$id: http://devicetree.org/schemas/clock/fixed-factor-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for simple fixed factor rate clock sources
+title: Simple fixed factor rate clock sources
maintainers:
- Michael Turquette <mturquette@baylibre.com>
- Stephen Boyd <sboyd@kernel.org>
properties:
+ $nodename:
+ anyOf:
+ - description:
+ If the frequency is fixed, the preferred name is 'clock-<freq>' with
+ <freq> being the output frequency.
+ pattern: "^clock-([0-9]+|[0-9a-z-]+)$"
+ - description: Any name allowed
+ deprecated: true
+
compatible:
enum:
- fixed-factor-clock
diff --git a/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml
index 1453ac849a65..e22fc272d023 100644
--- a/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/fixed-mmio-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/fixed-mmio-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for simple memory mapped IO fixed-rate clock sources
+title: Simple memory mapped IO fixed-rate clock sources
description:
This binding describes a fixed-rate clock for which the frequency can
diff --git a/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml b/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml
new file mode 100644
index 000000000000..07b9d21719c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,imx8-acm.yaml
@@ -0,0 +1,282 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,imx8-acm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8 Audio Clock Mux
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+description: |
+ NXP i.MX8 Audio Clock Mux is dedicated clock muxing IP
+ used to control Audio related clock on the SoC.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8dxl-acm
+ - fsl,imx8qm-acm
+ - fsl,imx8qxp-acm
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ minItems: 13
+ maxItems: 21
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8-clock.h
+ for the full list of i.MX8 ACM clock IDs.
+
+ clocks:
+ minItems: 13
+ maxItems: 27
+
+ clock-names:
+ minItems: 13
+ maxItems: 27
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-acm
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: power domain of IMX_SC_R_AUDIO_CLK_0
+ - description: power domain of IMX_SC_R_AUDIO_CLK_1
+ - description: power domain of IMX_SC_R_MCLK_OUT_0
+ - description: power domain of IMX_SC_R_MCLK_OUT_1
+ - description: power domain of IMX_SC_R_AUDIO_PLL_0
+ - description: power domain of IMX_SC_R_AUDIO_PLL_1
+ - description: power domain of IMX_SC_R_ASRC_0
+ - description: power domain of IMX_SC_R_ASRC_1
+ - description: power domain of IMX_SC_R_ESAI_0
+ - description: power domain of IMX_SC_R_SAI_0
+ - description: power domain of IMX_SC_R_SAI_1
+ - description: power domain of IMX_SC_R_SAI_2
+ - description: power domain of IMX_SC_R_SAI_3
+ - description: power domain of IMX_SC_R_SAI_4
+ - description: power domain of IMX_SC_R_SAI_5
+ - description: power domain of IMX_SC_R_SPDIF_0
+ - description: power domain of IMX_SC_R_MQS_0
+
+ clocks:
+ minItems: 18
+ maxItems: 18
+
+ clock-names:
+ items:
+ - const: aud_rec_clk0_lpcg_clk
+ - const: aud_rec_clk1_lpcg_clk
+ - const: aud_pll_div_clk0_lpcg_clk
+ - const: aud_pll_div_clk1_lpcg_clk
+ - const: ext_aud_mclk0
+ - const: ext_aud_mclk1
+ - const: esai0_rx_clk
+ - const: esai0_rx_hf_clk
+ - const: esai0_tx_clk
+ - const: esai0_tx_hf_clk
+ - const: spdif0_rx
+ - const: sai0_rx_bclk
+ - const: sai0_tx_bclk
+ - const: sai1_rx_bclk
+ - const: sai1_tx_bclk
+ - const: sai2_rx_bclk
+ - const: sai3_rx_bclk
+ - const: sai4_rx_bclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-acm
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: power domain of IMX_SC_R_AUDIO_CLK_0
+ - description: power domain of IMX_SC_R_AUDIO_CLK_1
+ - description: power domain of IMX_SC_R_MCLK_OUT_0
+ - description: power domain of IMX_SC_R_MCLK_OUT_1
+ - description: power domain of IMX_SC_R_AUDIO_PLL_0
+ - description: power domain of IMX_SC_R_AUDIO_PLL_1
+ - description: power domain of IMX_SC_R_ASRC_0
+ - description: power domain of IMX_SC_R_ASRC_1
+ - description: power domain of IMX_SC_R_ESAI_0
+ - description: power domain of IMX_SC_R_ESAI_1
+ - description: power domain of IMX_SC_R_SAI_0
+ - description: power domain of IMX_SC_R_SAI_1
+ - description: power domain of IMX_SC_R_SAI_2
+ - description: power domain of IMX_SC_R_SAI_3
+ - description: power domain of IMX_SC_R_SAI_4
+ - description: power domain of IMX_SC_R_SAI_5
+ - description: power domain of IMX_SC_R_SAI_6
+ - description: power domain of IMX_SC_R_SAI_7
+ - description: power domain of IMX_SC_R_SPDIF_0
+ - description: power domain of IMX_SC_R_SPDIF_1
+ - description: power domain of IMX_SC_R_MQS_0
+
+ clocks:
+ minItems: 27
+ maxItems: 27
+
+ clock-names:
+ items:
+ - const: aud_rec_clk0_lpcg_clk
+ - const: aud_rec_clk1_lpcg_clk
+ - const: aud_pll_div_clk0_lpcg_clk
+ - const: aud_pll_div_clk1_lpcg_clk
+ - const: mlb_clk
+ - const: hdmi_rx_mclk
+ - const: ext_aud_mclk0
+ - const: ext_aud_mclk1
+ - const: esai0_rx_clk
+ - const: esai0_rx_hf_clk
+ - const: esai0_tx_clk
+ - const: esai0_tx_hf_clk
+ - const: esai1_rx_clk
+ - const: esai1_rx_hf_clk
+ - const: esai1_tx_clk
+ - const: esai1_tx_hf_clk
+ - const: spdif0_rx
+ - const: spdif1_rx
+ - const: sai0_rx_bclk
+ - const: sai0_tx_bclk
+ - const: sai1_rx_bclk
+ - const: sai1_tx_bclk
+ - const: sai2_rx_bclk
+ - const: sai3_rx_bclk
+ - const: sai4_rx_bclk
+ - const: sai5_tx_bclk
+ - const: sai6_rx_bclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8dxl-acm
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: power domain of IMX_SC_R_AUDIO_CLK_0
+ - description: power domain of IMX_SC_R_AUDIO_CLK_1
+ - description: power domain of IMX_SC_R_MCLK_OUT_0
+ - description: power domain of IMX_SC_R_MCLK_OUT_1
+ - description: power domain of IMX_SC_R_AUDIO_PLL_0
+ - description: power domain of IMX_SC_R_AUDIO_PLL_1
+ - description: power domain of IMX_SC_R_ASRC_0
+ - description: power domain of IMX_SC_R_SAI_0
+ - description: power domain of IMX_SC_R_SAI_1
+ - description: power domain of IMX_SC_R_SAI_2
+ - description: power domain of IMX_SC_R_SAI_3
+ - description: power domain of IMX_SC_R_SPDIF_0
+ - description: power domain of IMX_SC_R_MQS_0
+
+ clocks:
+ minItems: 13
+ maxItems: 13
+
+ clock-names:
+ items:
+ - const: aud_rec_clk0_lpcg_clk
+ - const: aud_rec_clk1_lpcg_clk
+ - const: aud_pll_div_clk0_lpcg_clk
+ - const: aud_pll_div_clk1_lpcg_clk
+ - const: ext_aud_mclk0
+ - const: ext_aud_mclk1
+ - const: spdif0_rx
+ - const: sai0_rx_bclk
+ - const: sai0_tx_bclk
+ - const: sai1_rx_bclk
+ - const: sai1_tx_bclk
+ - const: sai2_rx_bclk
+ - const: sai3_rx_bclk
+
+additionalProperties: false
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ clock-controller@59e00000 {
+ compatible = "fsl,imx8qxp-acm";
+ reg = <0x59e00000 0x1d0000>;
+ #clock-cells = <1>;
+ power-domains = <&pd IMX_SC_R_AUDIO_CLK_0>,
+ <&pd IMX_SC_R_AUDIO_CLK_1>,
+ <&pd IMX_SC_R_MCLK_OUT_0>,
+ <&pd IMX_SC_R_MCLK_OUT_1>,
+ <&pd IMX_SC_R_AUDIO_PLL_0>,
+ <&pd IMX_SC_R_AUDIO_PLL_1>,
+ <&pd IMX_SC_R_ASRC_0>,
+ <&pd IMX_SC_R_ASRC_1>,
+ <&pd IMX_SC_R_ESAI_0>,
+ <&pd IMX_SC_R_SAI_0>,
+ <&pd IMX_SC_R_SAI_1>,
+ <&pd IMX_SC_R_SAI_2>,
+ <&pd IMX_SC_R_SAI_3>,
+ <&pd IMX_SC_R_SAI_4>,
+ <&pd IMX_SC_R_SAI_5>,
+ <&pd IMX_SC_R_SPDIF_0>,
+ <&pd IMX_SC_R_MQS_0>;
+ clocks = <&aud_rec0_lpcg IMX_LPCG_CLK_0>,
+ <&aud_rec1_lpcg IMX_LPCG_CLK_0>,
+ <&aud_pll_div0_lpcg IMX_LPCG_CLK_0>,
+ <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>,
+ <&clk_ext_aud_mclk0>,
+ <&clk_ext_aud_mclk1>,
+ <&clk_esai0_rx_clk>,
+ <&clk_esai0_rx_hf_clk>,
+ <&clk_esai0_tx_clk>,
+ <&clk_esai0_tx_hf_clk>,
+ <&clk_spdif0_rx>,
+ <&clk_sai0_rx_bclk>,
+ <&clk_sai0_tx_bclk>,
+ <&clk_sai1_rx_bclk>,
+ <&clk_sai1_tx_bclk>,
+ <&clk_sai2_rx_bclk>,
+ <&clk_sai3_rx_bclk>,
+ <&clk_sai4_rx_bclk>;
+ clock-names = "aud_rec_clk0_lpcg_clk",
+ "aud_rec_clk1_lpcg_clk",
+ "aud_pll_div_clk0_lpcg_clk",
+ "aud_pll_div_clk1_lpcg_clk",
+ "ext_aud_mclk0",
+ "ext_aud_mclk1",
+ "esai0_rx_clk",
+ "esai0_rx_hf_clk",
+ "esai0_tx_clk",
+ "esai0_tx_hf_clk",
+ "spdif0_rx",
+ "sai0_rx_bclk",
+ "sai0_tx_bclk",
+ "sai1_rx_bclk",
+ "sai1_tx_bclk",
+ "sai2_rx_bclk",
+ "sai3_rx_bclk",
+ "sai4_rx_bclk";
+ };
diff --git a/Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml b/Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml
new file mode 100644
index 000000000000..bbd22e95b319
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,imx8m-anatop.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,imx8m-anatop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8M Family Anatop Module
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description: |
+ NXP i.MX8M Family anatop PLL module which generates PLL to CCM root.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx8mm-anatop
+ - fsl,imx8mq-anatop
+ - items:
+ - enum:
+ - fsl,imx8mn-anatop
+ - fsl,imx8mp-anatop
+ - const: fsl,imx8mm-anatop
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ anatop: clock-controller@30360000 {
+ compatible = "fsl,imx8mn-anatop", "fsl,imx8mm-anatop";
+ reg = <0x30360000 0x10000>;
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/fsl,imx8ulp-sim-lpav.yaml b/Documentation/devicetree/bindings/clock/fsl,imx8ulp-sim-lpav.yaml
new file mode 100644
index 000000000000..662e07528d76
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,imx8ulp-sim-lpav.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,imx8ulp-sim-lpav.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8ULP LPAV System Integration Module (SIM)
+
+maintainers:
+ - Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
+
+description:
+ The i.MX8ULP LPAV subsystem contains a block control module known as
+ SIM LPAV, which offers functionalities such as clock gating or reset
+ line assertion/de-assertion.
+
+properties:
+ compatible:
+ const: fsl,imx8ulp-sim-lpav
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: bus
+ - const: core
+ - const: plat
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ mux-controller:
+ $ref: /schemas/mux/reg-mux.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+ - mux-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8ulp-clock.h>
+
+ clock-controller@2da50000 {
+ compatible = "fsl,imx8ulp-sim-lpav";
+ reg = <0x2da50000 0x10000>;
+ clocks = <&cgc2 IMX8ULP_CLK_LPAV_BUS_DIV>,
+ <&cgc2 IMX8ULP_CLK_HIFI_DIVCORE>,
+ <&cgc2 IMX8ULP_CLK_HIFI_DIVPLAT>;
+ clock-names = "bus", "core", "plat";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+
+ mux-controller {
+ compatible = "reg-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x8 0x00000200>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/fsl,imx93-anatop.yaml b/Documentation/devicetree/bindings/clock/fsl,imx93-anatop.yaml
new file mode 100644
index 000000000000..8a3b2476419a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,imx93-anatop.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,imx93-anatop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX93 ANATOP Clock Module
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description: |
+ NXP i.MX93 ANATOP module which contains PLL and OSC to Clock Controller
+ Module.
+
+properties:
+ compatible:
+ items:
+ - const: fsl,imx93-anatop
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@44480000 {
+ compatible = "fsl,imx93-anatop";
+ reg = <0x44480000 0x2000>;
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
index 9ac716dfa602..88dd9c18db92 100644
--- a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
+++ b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/fsl,plldig.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP QorIQ Layerscape LS1028A Display PIXEL Clock Binding
+title: NXP QorIQ Layerscape LS1028A Display PIXEL Clock
maintainers:
- Wen He <wen.he_1@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/fsl,qoriq-clock-legacy.yaml b/Documentation/devicetree/bindings/clock/fsl,qoriq-clock-legacy.yaml
new file mode 100644
index 000000000000..97b96a1a5825
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,qoriq-clock-legacy.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,qoriq-clock-legacy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Legacy Clock Block on Freescale QorIQ Platforms
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ These nodes are deprecated. Kernels should continue to support
+ device trees with these nodes, but new device trees should not use them.
+
+ Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+properties:
+ compatible:
+ enum:
+ - fsl,qoriq-core-pll-1.0
+ - fsl,qoriq-core-pll-2.0
+ - fsl,qoriq-core-mux-1.0
+ - fsl,qoriq-core-mux-2.0
+ - fsl,qoriq-sysclk-1.0
+ - fsl,qoriq-sysclk-2.0
+ - fsl,qoriq-platform-pll-1.0
+ - fsl,qoriq-platform-pll-2.0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ minItems: 1
+ maxItems: 4
+
+ clock-output-names:
+ minItems: 1
+ maxItems: 8
+
+ '#clock-cells':
+ minimum: 0
+ maximum: 1
+
+required:
+ - compatible
+ - '#clock-cells'
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,qoriq-sysclk-1.0
+ - fsl,qoriq-sysclk-2.0
+ then:
+ properties:
+ '#clock-cells':
+ const: 0
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,qoriq-core-pll-1.0
+ - fsl,qoriq-core-pll-2.0
+ then:
+ properties:
+ '#clock-cells':
+ const: 1
+ description: |
+ * 0 - equal to the PLL frequency
+ * 1 - equal to the PLL frequency divided by 2
+ * 2 - equal to the PLL frequency divided by 4
+
diff --git a/Documentation/devicetree/bindings/clock/fsl,qoriq-clock.yaml b/Documentation/devicetree/bindings/clock/fsl,qoriq-clock.yaml
new file mode 100644
index 000000000000..95a3e3b24267
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,qoriq-clock.yaml
@@ -0,0 +1,207 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,qoriq-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock Block on Freescale QorIQ Platforms
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ Freescale QorIQ chips take primary clocking input from the external
+ SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+ multiple phase locked loops (PLL) to create a variety of frequencies
+ which can then be passed to a variety of internal logic, including
+ cores and peripheral IP blocks.
+ Please refer to the Reference Manual for details.
+
+ All references to "1.0" and "2.0" refer to the QorIQ chassis version to
+ which the chip complies.
+
+ Chassis Version Example Chips
+ --------------- -------------
+ 1.0 p4080, p5020, p5040
+ 2.0 t4240
+
+ Clock Provider
+
+ The clockgen node should act as a clock provider, though in older device
+ trees the children of the clockgen node are the clock providers.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,p2041-clockgen
+ - fsl,p3041-clockgen
+ - fsl,p4080-clockgen
+ - fsl,p5020-clockgen
+ - fsl,p5040-clockgen
+ - const: fsl,qoriq-clockgen-1.0
+ - items:
+ - enum:
+ - fsl,t1023-clockgen
+ - fsl,t1024-clockgen
+ - fsl,t1040-clockgen
+ - fsl,t1042-clockgen
+ - fsl,t2080-clockgen
+ - fsl,t2081-clockgen
+ - fsl,t4240-clockgen
+ - const: fsl,qoriq-clockgen-2.0
+ - items:
+ - enum:
+ - fsl,b4420-clockgen
+ - fsl,b4860-clockgen
+ - const: fsl,b4-clockgen
+ - items:
+ - enum:
+ - fsl,ls1012a-clockgen
+ - fsl,ls1021a-clockgen
+ - fsl,ls1028a-clockgen
+ - fsl,ls1043a-clockgen
+ - fsl,ls1046a-clockgen
+ - fsl,ls1088a-clockgen
+ - fsl,ls2080a-clockgen
+ - fsl,lx2160a-clockgen
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ '#clock-cells':
+ const: 2
+ description: |
+ The first cell of the clock specifier is the clock type, and the
+ second cell is the clock index for the specified type.
+
+ Type# Name Index Cell
+ 0 sysclk must be 0
+ 1 cmux index (n in CLKCnCSR)
+ 2 hwaccel index (n in CLKCGnHWACSR)
+ 3 fman 0 for fm1, 1 for fm2
+ 4 platform pll n=pll/(n+1). For example, when n=1,
+ that means output_freq=PLL_freq/2.
+ 5 coreclk must be 0
+
+ clock-frequency:
+ description: Input system clock frequency (SYSCLK)
+
+ clocks:
+ items:
+ - description:
+ sysclk may be provided as an input clock. Either clock-frequency
+ or clocks must be provided.
+ - description:
+ A second input clock, called "coreclk", may be provided if
+ core PLLs are based on a different input clock from the
+ platform PLL.
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: sysclk
+ - const: coreclk
+
+patternProperties:
+ '^mux[0-9]@[a-f0-9]+$':
+ deprecated: true
+ $ref: fsl,qoriq-clock-legacy.yaml
+
+ '^sysclk(-[a-z0-9]+)?$':
+ deprecated: true
+ $ref: fsl,qoriq-clock-legacy.yaml
+
+ '^pll[0-9]@[a-f0-9]+$':
+ deprecated: true
+ $ref: fsl,qoriq-clock-legacy.yaml
+
+ '^platform\-pll@[a-f0-9]+$':
+ deprecated: true
+ $ref: fsl,qoriq-clock-legacy.yaml
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ /* clock provider example */
+ global-utilities@e1000 {
+ compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
+ reg = <0xe1000 0x1000>;
+ clock-frequency = <133333333>;
+ #clock-cells = <2>;
+ };
+
+ - |
+ /* Legacy example */
+ global-utilities@e1000 {
+ compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
+ reg = <0xe1000 0x1000>;
+ ranges = <0x0 0xe1000 0x1000>;
+ clock-frequency = <133333333>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #clock-cells = <2>;
+
+ sysclk: sysclk {
+ compatible = "fsl,qoriq-sysclk-1.0";
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+ };
+
+ pll0: pll0@800 {
+ compatible = "fsl,qoriq-core-pll-1.0";
+ reg = <0x800 0x4>;
+ #clock-cells = <1>;
+ clocks = <&sysclk>;
+ clock-output-names = "pll0", "pll0-div2";
+ };
+
+ pll1: pll1@820 {
+ compatible = "fsl,qoriq-core-pll-1.0";
+ reg = <0x820 0x4>;
+ #clock-cells = <1>;
+ clocks = <&sysclk>;
+ clock-output-names = "pll1", "pll1-div2";
+ };
+
+ mux0: mux0@0 {
+ compatible = "fsl,qoriq-core-mux-1.0";
+ reg = <0x0 0x4>;
+ #clock-cells = <0>;
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux0";
+ };
+
+ mux1: mux1@20 {
+ compatible = "fsl,qoriq-core-mux-1.0";
+ reg = <0x20 0x4>;
+ #clock-cells = <0>;
+ clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+ clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux1";
+ };
+
+ platform-pll@c00 {
+ #clock-cells = <1>;
+ reg = <0xc00 0x4>;
+ compatible = "fsl,qoriq-platform-pll-1.0";
+ clocks = <&sysclk>;
+ clock-output-names = "platform-pll", "platform-pll-div2";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml b/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
index fc3bdfdc091a..3bca9d11c148 100644
--- a/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/fsl,sai-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale SAI bitclock-as-a-clock binding
+title: Freescale SAI bitclock-as-a-clock
maintainers:
- Michael Walle <michael@walle.cc>
diff --git a/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml b/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml
index f2c48460a399..36d4cfc3c2f8 100644
--- a/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/fsl,scu-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - Clock bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - Clock Controller Based on SCU Message Protocol
maintainers:
- Abel Vesa <abel.vesa@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/fsl,vf610-ccm.yaml b/Documentation/devicetree/bindings/clock/fsl,vf610-ccm.yaml
new file mode 100644
index 000000000000..29ae5be51acf
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fsl,vf610-ccm.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/fsl,vf610-ccm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Clock for Freescale Vybrid VF610 SOC
+
+description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
+ for the full list of VF610 clock IDs
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,vf610-ccm
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: external crystal oscillator 32KHz, recommended
+ - description: external crystal oscillator 24MHz, recommended
+ - description: audio
+ - description: enet
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: sxosc
+ - const: fxosc
+ - const: enet_ext
+ - const: audio_ext
+ minItems: 2
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@4006b000 {
+ compatible = "fsl,vf610-ccm";
+ reg = <0x4006b000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&sxosc>, <&fxosc>;
+ clock-names = "sxosc", "fxosc";
+ };
+
diff --git a/Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt b/Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt
deleted file mode 100644
index 332396265689..000000000000
--- a/Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Fujitsu CRG11 clock driver bindings
------------------------------------
-
-Required properties :
-- compatible : Shall contain "fujitsu,mb86s70-crg11"
-- #clock-cells : Shall be 3 {cntrlr domain port}
-
-The consumer specifies the desired clock pointing to its phandle.
-
-Example:
-
- clock: crg11 {
- compatible = "fujitsu,mb86s70-crg11";
- #clock-cells = <3>;
- };
-
- mhu: mhu0@2b1f0000 {
- #mbox-cells = <1>;
- compatible = "arm,mhu";
- reg = <0 0x2B1F0000 0x1000>;
- interrupts = <0 36 4>, /* LP Non-Sec */
- <0 35 4>, /* HP Non-Sec */
- <0 37 4>; /* Secure */
- clocks = <&clock 0 2 1>; /* Cntrlr:0 Domain:2 Port:1 */
- clock-names = "clk";
- };
diff --git a/Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml b/Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml
new file mode 100644
index 000000000000..d3e0faf3c64d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/gated-fixed-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gated Fixed clock
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: gated-fixed-clock
+
+ "#clock-cells":
+ const: 0
+
+ clock-frequency: true
+
+ clock-output-names:
+ maxItems: 1
+
+ enable-gpios:
+ description:
+ Contains a single GPIO specifier for the GPIO that enables and disables
+ the oscillator.
+ maxItems: 1
+
+ vdd-supply:
+ description: handle of the regulator that provides the supply voltage
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clock-frequency
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-1000000000 {
+ compatible = "gated-fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1000000000>;
+ vdd-supply = <&reg_vdd>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
new file mode 100644
index 000000000000..31e106ef913d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google GS101 SoC clock controller
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+description: |
+ Google GS101 clock controller is comprised of several CMU units, generating
+ clocks for different domains. Those CMU units are modeled as separate device
+ tree nodes, and might depend on each other. The root clock in that clock tree
+ is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
+ clock in dts.
+
+ CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+ dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ 'dt-bindings/clock/gs101.h' header.
+
+properties:
+ compatible:
+ enum:
+ - google,gs101-cmu-top
+ - google,gs101-cmu-apm
+ - google,gs101-cmu-misc
+ - google,gs101-cmu-hsi0
+ - google,gs101-cmu-hsi2
+ - google,gs101-cmu-peric0
+ - google,gs101-cmu-peric1
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+
+ clock-names:
+ minItems: 1
+ maxItems: 5
+
+ "#clock-cells":
+ const: 1
+
+ power-domains:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - clock-names
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-cmu-top
+ - google,gs101-cmu-apm
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (24.576 MHz)
+
+ clock-names:
+ items:
+ - const: oscclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-cmu-hsi0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (24.576 MHz)
+ - description: HSI0 bus clock (from CMU_TOP)
+ - description: DPGTC (from CMU_TOP)
+ - description: USB DRD controller clock (from CMU_TOP)
+ - description: USB Display Port debug clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: dpgtc
+ - const: usb31drd
+ - const: usbdpdbg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-cmu-hsi2
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (24.576 MHz)
+ - description: High Speed Interface bus clock (from CMU_TOP)
+ - description: High Speed Interface pcie clock (from CMU_TOP)
+ - description: High Speed Interface ufs clock (from CMU_TOP)
+ - description: High Speed Interface mmc clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: pcie
+ - const: ufs
+ - const: mmc
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-cmu-misc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Misc bus clock (from CMU_TOP)
+ - description: Misc sss clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: bus
+ - const: sss
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-cmu-peric0
+ - google,gs101-cmu-peric1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (24.576 MHz)
+ - description: Connectivity Peripheral 0/1 bus clock (from CMU_TOP)
+ - description: Connectivity Peripheral 0/1 IP clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: ip
+
+additionalProperties: false
+
+examples:
+ # Clock controller node for CMU_TOP
+ - |
+ #include <dt-bindings/clock/google,gs101.h>
+
+ cmu_top: clock-controller@1e080000 {
+ compatible = "google,gs101-cmu-top";
+ reg = <0x1e080000 0x8000>;
+ #clock-cells = <1>;
+ clocks = <&ext_24_5m>;
+ clock-names = "oscclk";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
deleted file mode 100644
index d3379ff9b84b..000000000000
--- a/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Binding for simple gpio gated clock.
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "gpio-gate-clock".
-- #clock-cells : from common clock binding; shall be set to 0.
-- enable-gpios : GPIO reference for enabling and disabling the clock.
-
-Optional properties:
-- clocks: Maximum of one parent clock is supported.
-
-Example:
- clock {
- compatible = "gpio-gate-clock";
- clocks = <&parentclk>;
- #clock-cells = <0>;
- enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml
new file mode 100644
index 000000000000..d09d0e3f0c6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/gpio-gate-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple GPIO clock gate
+
+maintainers:
+ - Jyri Sarha <jsarha@ti.com>
+
+properties:
+ compatible:
+ const: gpio-gate-clock
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ enable-gpios:
+ description: GPIO reference for enabling and disabling the clock.
+ maxItems: 1
+
+required:
+ - compatible
+ - '#clock-cells'
+ - enable-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ clock {
+ compatible = "gpio-gate-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/hi3620-clock.txt b/Documentation/devicetree/bindings/clock/hi3620-clock.txt
deleted file mode 100644
index dad6269f52c5..000000000000
--- a/Documentation/devicetree/bindings/clock/hi3620-clock.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Hisilicon Hi3620 Clock Controller
-
-The Hi3620 clock controller generates and supplies clock to various
-controllers within the Hi3620 SoC.
-
-Required Properties:
-
-- compatible: should be one of the following.
- - "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC.
- - "hisilicon,hi3620-mmc-clock" - controller specific for Hi3620 mmc.
-
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes use this identifier
-to specify the clock which they consume.
-
-All these identifier could be found in <dt-bindings/clock/hi3620-clock.h>.
diff --git a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt
deleted file mode 100644
index 4733e58e491b..000000000000
--- a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Hisilicon Hix5hd2 Clock Controller
-
-The hix5hd2 clock controller generates and supplies clock to various
-controllers within the hix5hd2 SoC.
-
-Required Properties:
-
-- compatible: should be "hisilicon,hix5hd2-clock"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-Each clock is assigned an identifier and client nodes use this identifier
-to specify the clock which they consume.
-
-All these identifier could be found in <dt-bindings/clock/hix5hd2-clock.h>.
-
-Examples:
- clock: clock@f8a22000 {
- compatible = "hisilicon,hix5hd2-clock";
- reg = <0xf8a22000 0x1000>;
- #clock-cells = <1>;
- };
-
- uart0: uart@f8b00000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0xf8b00000 0x1000>;
- interrupts = <0 49 4>;
- clocks = <&clock HIX5HD2_FIXED_83M>;
- clock-names = "apb_pclk";
- };
diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
index 7c331bfbe370..8b400da05fbe 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/idt,versaclock5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for IDT VersaClock 5 and 6 programmable I2C clock generators
+title: IDT VersaClock 5 and 6 programmable I2C clock generators
description: |
The IDT VersaClock 5 and VersaClock 6 are programmable I2C
@@ -54,8 +54,10 @@ properties:
- idt,5p49v5925
- idt,5p49v5933
- idt,5p49v5935
+ - idt,5p49v60
- idt,5p49v6901
- idt,5p49v6965
+ - idt,5p49v6975
reg:
description: I2C device address
@@ -108,7 +110,7 @@ patternProperties:
properties:
idt,mode:
description:
- The output drive mode. Values defined in dt-bindings/clk/versaclock.h
+ The output drive mode. Values defined in dt-bindings/clock/versaclock.h
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 6
@@ -124,8 +126,6 @@ required:
- compatible
- reg
- '#clock-cells'
- - idt,shutdown
- - idt,output-enable-active
allOf:
- if:
@@ -134,6 +134,7 @@ allOf:
enum:
- idt,5p49v5933
- idt,5p49v5935
+ - idt,5p49v6975
then:
# Devices with builtin crystal + optional external input
properties:
@@ -151,7 +152,7 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clk/versaclock.h>
+ #include <dt-bindings/clock/versaclock.h>
/* 25MHz reference crystal */
ref25: ref25m {
diff --git a/Documentation/devicetree/bindings/clock/img,pistachio-clk.yaml b/Documentation/devicetree/bindings/clock/img,pistachio-clk.yaml
new file mode 100644
index 000000000000..e70feee8e894
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/img,pistachio-clk.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/img,pistachio-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Technologies Pistachio SoC clock controllers
+
+maintainers:
+ - Andrew Bresticker <abrestic@chromium.org>
+
+description: |
+ Pistachio has four clock controllers (core clock, peripheral clock, peripheral
+ general control, and top general control) which are instantiated individually
+ from the device-tree.
+
+ Core clock controller:
+
+ The core clock controller generates clocks for the CPU, RPU (WiFi + BT
+ co-processor), audio, and several peripherals.
+
+ Peripheral clock controller:
+
+ The peripheral clock controller generates clocks for the DDR, ROM, and other
+ peripherals. The peripheral system clock ("periph_sys") generated by the core
+ clock controller is the input clock to the peripheral clock controller.
+
+ Peripheral general control:
+
+ The peripheral general control block generates system interface clocks and
+ resets for various peripherals. It also contains miscellaneous peripheral
+ control registers.
+
+ Top-level general control:
+
+ The top-level general control block contains miscellaneous control registers
+ and gates for the external clocks "audio_clk_in" and "enet_clk_in".
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - img,pistachio-clk
+ - img,pistachio-clk-periph
+ - img,pistachio-cr-periph
+ - img,pistachio-cr-top
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: img,pistachio-clk
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External 52Mhz oscillator
+ - description: Alternate audio reference clock
+ - description: Alternate ethernet PHY clock
+
+ clock-names:
+ items:
+ - const: xtal
+ - const: audio_refclk_ext_gate
+ - const: ext_enet_in_gate
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: img,pistachio-clk-periph
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Peripheral system clock
+
+ clock-names:
+ items:
+ - const: periph_sys_core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: img,pistachio-cr-periph
+ then:
+ properties:
+ clocks:
+ items:
+ - description: System interface clock
+
+ clock-names:
+ items:
+ - const: sys
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: img,pistachio-cr-top
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External audio reference clock
+ - description: External ethernet PHY clock
+
+ clock-names:
+ items:
+ - const: audio_clk_in
+ - const: enet_clk_in
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.yaml b/Documentation/devicetree/bindings/clock/imx1-clock.yaml
index 56f524780b1a..7ade4c32aff3 100644
--- a/Documentation/devicetree/bindings/clock/imx1-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx1-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx1-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX1 CPUs
+title: Freescale i.MX1 CPUs Clock Controller
maintainers:
- Alexander Shiyan <shc_work@mail.ru>
diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.yaml b/Documentation/devicetree/bindings/clock/imx21-clock.yaml
index e2d50544700a..79cc843703ec 100644
--- a/Documentation/devicetree/bindings/clock/imx21-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx21-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx21-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX21
+title: Freescale i.MX21 Clock Controller
maintainers:
- Alexander Shiyan <shc_work@mail.ru>
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.yaml b/Documentation/devicetree/bindings/clock/imx23-clock.yaml
index 7e890ab9c77d..5e71c9219500 100644
--- a/Documentation/devicetree/bindings/clock/imx23-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx23-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx23-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX23
+title: Freescale i.MX23 Clock Controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.yaml b/Documentation/devicetree/bindings/clock/imx25-clock.yaml
index 1792e138984b..c626a158590e 100644
--- a/Documentation/devicetree/bindings/clock/imx25-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx25-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx25-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX25
+title: Freescale i.MX25 Clock Controller
maintainers:
- Sascha Hauer <s.hauer@pengutronix.de>
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.yaml b/Documentation/devicetree/bindings/clock/imx27-clock.yaml
index 99925aa22a4c..71d78a0b551f 100644
--- a/Documentation/devicetree/bindings/clock/imx27-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx27-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx27-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX27
+title: Freescale i.MX27 Clock Controller
maintainers:
- Fabio Estevam <festevam@gmail.com>
diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.yaml b/Documentation/devicetree/bindings/clock/imx28-clock.yaml
index a542d680b1ca..4aaad7b9c66e 100644
--- a/Documentation/devicetree/bindings/clock/imx28-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx28-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx28-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX28
+title: Freescale i.MX28 Clock Controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.yaml b/Documentation/devicetree/bindings/clock/imx31-clock.yaml
index 168c8ada5e81..50a8498eef8a 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx31-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX31
+title: Freescale i.MX31 Clock Controller
maintainers:
- Fabio Estevam <festevam@gmail.com>
diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
index 6415bb6a8d04..c063369de3ec 100644
--- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx35-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX35
+title: Freescale i.MX35 Clock Controller
maintainers:
- Steffen Trumtrar <s.trumtrar@pengutronix.de>
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.yaml b/Documentation/devicetree/bindings/clock/imx5-clock.yaml
index c0e19ff92c76..423c0142c1d3 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx5-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX5
+title: Freescale i.MX5 Clock Controller
maintainers:
- Fabio Estevam <festevam@gmail.com>
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml
index 4f4637eddb8b..cd3c04c883df 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml
@@ -4,10 +4,11 @@
$id: http://devicetree.org/schemas/clock/imx6q-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX6 Quad
+title: Freescale i.MX6 Quad Clock Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Abel Vesa <abelvesa@kernel.org>
+ - Peng Fan <peng.fan@nxp.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
index b83c8f43d664..6713bbb14f30 100644
--- a/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml
@@ -4,10 +4,11 @@
$id: http://devicetree.org/schemas/clock/imx6sl-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX6 SoloLite
+title: Freescale i.MX6 SoloLite Clock Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Abel Vesa <abelvesa@kernel.org>
+ - Peng Fan <peng.fan@nxp.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
index 484894a4b23f..6d64cf9463c9 100644
--- a/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml
@@ -4,10 +4,11 @@
$id: http://devicetree.org/schemas/clock/imx6sll-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX6 SLL
+title: Freescale i.MX6 SLL Clock Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Abel Vesa <abelvesa@kernel.org>
+ - Peng Fan <peng.fan@nxp.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
index e6c795657c24..77afa4b81cf7 100644
--- a/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml
@@ -4,10 +4,11 @@
$id: http://devicetree.org/schemas/clock/imx6sx-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX6 SoloX
+title: Freescale i.MX6 SoloX Clock Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Abel Vesa <abelvesa@kernel.org>
+ - Peng Fan <peng.fan@nxp.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
index 6a51a3f51cd9..d57e18a210cc 100644
--- a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml
@@ -4,10 +4,11 @@
$id: http://devicetree.org/schemas/clock/imx6ul-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX6 UltraLite
+title: Freescale i.MX6 UltraLite Clock Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Abel Vesa <abelvesa@kernel.org>
+ - Peng Fan <peng.fan@nxp.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/imx7d-clock.yaml b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
index cefb61db01a8..880d602d09f4 100644
--- a/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx7d-clock.yaml
@@ -4,11 +4,10 @@
$id: http://devicetree.org/schemas/clock/imx7d-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX7 Dual
+title: Freescale i.MX7 Dual Clock Controller
maintainers:
- Frank Li <Frank.Li@nxp.com>
- - Anson Huang <Anson.Huang@nxp.com>
description: |
The clock consumer should specify the desired clock by having the clock
diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml
index 739c3378f8c8..76842038f52e 100644
--- a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx7ulp-pcc-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX7ULP Peripheral Clock Control (PCC) modules
+title: Freescale i.MX7ULP Peripheral Clock Control (PCC) modules Clock Controller
maintainers:
- A.s. Dong <aisheng.dong@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml
index d06344d7e34f..5e25bc6d1372 100644
--- a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx7ulp-scg-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MX7ULP System Clock Generation (SCG) modules
+title: Freescale i.MX7ULP System Clock Generation (SCG) modules Clock Controller
maintainers:
- A.s. Dong <aisheng.dong@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
index 458c7645ee68..4fec55832702 100644
--- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
@@ -4,10 +4,11 @@
$id: http://devicetree.org/schemas/clock/imx8m-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8M Family Clock Control Module Binding
+title: NXP i.MX8M Family Clock Control Module
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Abel Vesa <abelvesa@kernel.org>
+ - Peng Fan <peng.fan@nxp.com>
description: |
NXP i.MX8M Mini/Nano/Plus/Quad clock control module is an integrated clock
@@ -24,6 +25,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 2
+
clocks:
minItems: 6
maxItems: 7
@@ -39,6 +43,13 @@ properties:
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h
for the full list of i.MX8M clock IDs.
+ fsl,operating-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [nominal, overdrive]
+ description:
+ The operating mode of the SoC. This affects the maximum clock rates that
+ can safely be configured by the clock controller.
+
required:
- compatible
- reg
@@ -105,10 +116,11 @@ examples:
<&clk_ext3>, <&clk_ext4>;
clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
"clk_ext3", "clk_ext4";
+ fsl,operating-mode = "nominal";
};
- |
- clock-controller@30390000 {
+ clock-controller@30380000 {
compatible = "fsl,imx8mq-ccm";
reg = <0x30380000 0x10000>;
#clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
new file mode 100644
index 000000000000..0272c9527037
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx8mp-audiomix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8MP AudioMIX Block Control
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+description: |
+ NXP i.MX8M Plus AudioMIX is dedicated clock muxing and gating IP
+ used to control Audio related clock on the SoC.
+
+properties:
+ compatible:
+ const: fsl,imx8mp-audio-blk-ctrl
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ minItems: 8
+ maxItems: 8
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: sai1
+ - const: sai2
+ - const: sai3
+ - const: sai5
+ - const: sai6
+ - const: sai7
+ - const: axi
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mp-clock.h
+ for the full list of i.MX8MP IMX8MP_CLK_AUDIOMIX_ clock IDs.
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ # Clock Control Module node:
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+
+ clock-controller@30e20000 {
+ compatible = "fsl,imx8mp-audio-blk-ctrl";
+ reg = <0x30e20000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&clk IMX8MP_CLK_AUDIO_ROOT>,
+ <&clk IMX8MP_CLK_SAI1>,
+ <&clk IMX8MP_CLK_SAI2>,
+ <&clk IMX8MP_CLK_SAI3>,
+ <&clk IMX8MP_CLK_SAI5>,
+ <&clk IMX8MP_CLK_SAI6>,
+ <&clk IMX8MP_CLK_SAI7>,
+ <&clk IMX8MP_CLK_AUDIO_AXI_ROOT>;
+ clock-names = "ahb",
+ "sai1", "sai2", "sai3",
+ "sai5", "sai6", "sai7", "axi";
+ power-domains = <&pgc_audio>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
index cb80105b3c70..b207f95361b2 100644
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx8qxp-lpcg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
+title: NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock
maintainers:
- Aisheng Dong <aisheng.dong@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml b/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml
index 71f7186b135b..68a60cdc19af 100644
--- a/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8ulp-cgc-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx8ulp-cgc-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8ULP Clock Generation & Control(CGC) Module Binding
+title: NXP i.MX8ULP Clock Generation & Control(CGC) Module
maintainers:
- Jacky Bai <ping.bai@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml
index 00612725bf8b..d0b0792fe7ba 100644
--- a/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8ulp-pcc-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx8ulp-pcc-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8ULP Peripheral Clock Controller(PCC) Module Binding
+title: NXP i.MX8ULP Peripheral Clock Controller(PCC) Module
maintainers:
- Jacky Bai <ping.bai@nxp.com>
diff --git a/Documentation/devicetree/bindings/clock/imx93-clock.yaml b/Documentation/devicetree/bindings/clock/imx93-clock.yaml
index 21a06194e4a3..98c0800732ef 100644
--- a/Documentation/devicetree/bindings/clock/imx93-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx93-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imx93-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX93 Clock Control Module Binding
+title: NXP i.MX93 Clock Control Module
maintainers:
- Peng Fan <peng.fan@nxp.com>
@@ -16,6 +16,7 @@ description: |
properties:
compatible:
enum:
+ - fsl,imx91-ccm
- fsl,imx93-ccm
reg:
diff --git a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml
index 03fc5c1a2939..777af4aad4b2 100644
--- a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/imxrt1050-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for Freescale i.MXRT
+title: Freescale i.MXRT Clock Controller
maintainers:
- Giulio Benetti <giulio.benetti@benettiengineering.com>
diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
index aa1df03ef4a6..509df06b9c9d 100644
--- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
+++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/ingenic,cgu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs CGU devicetree bindings
+title: Ingenic SoCs CGU
description: |
The CGU in an Ingenic SoC provides all the clocks generated on-chip. It
@@ -22,6 +22,7 @@ select:
enum:
- ingenic,jz4740-cgu
- ingenic,jz4725b-cgu
+ - ingenic,jz4755-cgu
- ingenic,jz4760-cgu
- ingenic,jz4760b-cgu
- ingenic,jz4770-cgu
@@ -51,6 +52,7 @@ properties:
- enum:
- ingenic,jz4740-cgu
- ingenic,jz4725b-cgu
+ - ingenic,jz4755-cgu
- ingenic,jz4760-cgu
- ingenic,jz4760b-cgu
- ingenic,jz4770-cgu
@@ -96,9 +98,9 @@ required:
patternProperties:
"^usb-phy@[a-f0-9]+$":
- allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ]
+ $ref: /schemas/phy/ingenic,phy-usb.yaml#
"^mac-phy-ctrl@[a-f0-9]+$":
- allOf: [ $ref: "../net/ingenic,mac.yaml#" ]
+ $ref: /schemas/net/ingenic,mac.yaml#
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/intel,agilex.yaml b/Documentation/devicetree/bindings/clock/intel,agilex.yaml
index cf5a9eb803e6..3745ba8dbd76 100644
--- a/Documentation/devicetree/bindings/clock/intel,agilex.yaml
+++ b/Documentation/devicetree/bindings/clock/intel,agilex.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/intel,agilex.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel SoCFPGA Agilex platform clock controller binding
+title: Intel SoCFPGA Agilex platform clock controller
maintainers:
- Dinh Nguyen <dinguyen@kernel.org>
diff --git a/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml b/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml
new file mode 100644
index 000000000000..d120b0da7f3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,agilex5-clkmgr.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/intel,agilex5-clkmgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel SoCFPGA Agilex5 clock manager
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+
+description:
+ The Intel Agilex5 Clock Manager is an integrated clock controller, which
+ generates and supplies clock to all the modules.
+
+properties:
+ compatible:
+ const: intel,agilex5-clkmgr
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clkmgr: clock-controller@10d10000 {
+ compatible = "intel,agilex5-clkmgr";
+ reg = <0x10d10000 0x1000>;
+ #clock-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml b/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml
index f3e1a700a2ca..76609a390429 100644
--- a/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml
+++ b/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/intel,cgu-lgm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Lightning Mountain SoC's Clock Controller(CGU) Binding
+title: Intel Lightning Mountain SoC's Clock Controller(CGU)
maintainers:
- Rahul Tanwar <rahul.tanwar@linux.intel.com>
diff --git a/Documentation/devicetree/bindings/clock/intel,easic-n5x.yaml b/Documentation/devicetree/bindings/clock/intel,easic-n5x.yaml
index 8f45976e946e..e000116a51a4 100644
--- a/Documentation/devicetree/bindings/clock/intel,easic-n5x.yaml
+++ b/Documentation/devicetree/bindings/clock/intel,easic-n5x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/intel,easic-n5x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel SoCFPGA eASIC N5X platform clock controller binding
+title: Intel SoCFPGA eASIC N5X platform clock controller
maintainers:
- Dinh Nguyen <dinguyen@kernel.org>
diff --git a/Documentation/devicetree/bindings/clock/intel,stratix10.yaml b/Documentation/devicetree/bindings/clock/intel,stratix10.yaml
index f506e3db9782..b4a8be213400 100644
--- a/Documentation/devicetree/bindings/clock/intel,stratix10.yaml
+++ b/Documentation/devicetree/bindings/clock/intel,stratix10.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/intel,stratix10.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel SoCFPGA Stratix10 platform clock controller binding
+title: Intel SoCFPGA Stratix10 platform clock controller
maintainers:
- Dinh Nguyen <dinguyen@kernel.org>
diff --git a/Documentation/devicetree/bindings/clock/keystone-gate.txt b/Documentation/devicetree/bindings/clock/keystone-gate.txt
index c5aa187026e3..43f6fb6c9392 100644
--- a/Documentation/devicetree/bindings/clock/keystone-gate.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-gate.txt
@@ -1,5 +1,3 @@
-Status: Unstable - ABI compatibility may be broken in the future
-
Binding for Keystone gate control driver which uses PSC controller IP.
This binding uses the common clock binding[1].
diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 47570d207215..69b0eb7c03c9 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -1,5 +1,3 @@
-Status: Unstable - ABI compatibility may be broken in the future
-
Binding for keystone PLLs. The main PLL IP typically has a multiplier,
a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL
and PAPLL are controlled by the memory mapped register where as the Main
@@ -14,7 +12,7 @@ Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
- clocks : parent clock phandle
-- reg - pll control0 and pll multipler registers
+- reg - pll control0 and pll multiplier registers
- reg-names : control, multiplier and post-divider. The multiplier and
post-divider registers are applicable only for main pll clock
- fixed-postdiv : fixed post divider value. If absent, use clkod register bits
diff --git a/Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml b/Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml
new file mode 100644
index 000000000000..01561a0f35d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/loongson,ls1x-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 Clock Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls1b-clk
+ - loongson,ls1c-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clkc: clock-controller@1fe78030 {
+ compatible = "loongson,ls1b-clk";
+ reg = <0x1fe78030 0x8>;
+
+ clocks = <&xtal>;
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml b/Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml
new file mode 100644
index 000000000000..c07ad1f85857
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/loongson,ls2k-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 SoC Clock Control Module
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+description: |
+ Loongson-2 SoC clock control module is an integrated clock controller, which
+ generates and supplies to all modules.
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k0300-clk
+ - loongson,ls2k0500-clk
+ - loongson,ls2k-clk # This is for Loongson-2K1000
+ - loongson,ls2k2000-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref_100m
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See include/dt-bindings/clock/loongson,ls2k-clk.h
+ for the full list of Loongson-2 SoC clock IDs.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: loongson,ls2k0300-clk
+ then:
+ properties:
+ clock-names: false
+ else:
+ required:
+ - clock-names
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ ref_100m: clock-ref-100m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "ref_100m";
+ };
+
+ clk: clock-controller@1fe00480 {
+ compatible = "loongson,ls2k-clk";
+ reg = <0x1fe00480 0x58>;
+ #clock-cells = <1>;
+ clocks = <&ref_100m>;
+ clock-names = "ref_100m";
+ };
diff --git a/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt b/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt
deleted file mode 100644
index fa97c12014ac..000000000000
--- a/Documentation/devicetree/bindings/clock/lpc1850-ccu.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-* NXP LPC1850 Clock Control Unit (CCU)
-
-Each CGU base clock has several clock branches which can be turned on
-or off independently by the Clock Control Units CCU1 or CCU2. The
-branch clocks are distributed between CCU1 and CCU2.
-
- - Above text taken from NXP LPC1850 User Manual.
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible:
- Should be "nxp,lpc1850-ccu"
-- reg:
- Shall define the base and range of the address space
- containing clock control registers
-- #clock-cells:
- Shall have value <1>. The permitted clock-specifier values
- are the branch clock names defined in table below.
-- clocks:
- Shall contain a list of phandles for the base clocks routed
- from the CGU to the specific CCU. See mapping of base clocks
- and CCU in table below.
-- clock-names:
- Shall contain a list of names for the base clock routed
- from the CGU to the specific CCU. Valid CCU clock names:
- "base_usb0_clk", "base_periph_clk", "base_usb1_clk",
- "base_cpu_clk", "base_spifi_clk", "base_spi_clk",
- "base_apb1_clk", "base_apb3_clk", "base_adchs_clk",
- "base_sdio_clk", "base_ssp0_clk", "base_ssp1_clk",
- "base_uart0_clk", "base_uart1_clk", "base_uart2_clk",
- "base_uart3_clk", "base_audio_clk"
-
-Which branch clocks that are available on the CCU depends on the
-specific LPC part. Check the user manual for your specific part.
-
-A list of CCU clocks can be found in dt-bindings/clock/lpc18xx-ccu.h.
-
-Example board file:
-
-soc {
- ccu1: clock-controller@40051000 {
- compatible = "nxp,lpc1850-ccu";
- reg = <0x40051000 0x1000>;
- #clock-cells = <1>;
- clocks = <&cgu BASE_APB3_CLK>, <&cgu BASE_APB1_CLK>,
- <&cgu BASE_SPIFI_CLK>, <&cgu BASE_CPU_CLK>,
- <&cgu BASE_PERIPH_CLK>, <&cgu BASE_USB0_CLK>,
- <&cgu BASE_USB1_CLK>, <&cgu BASE_SPI_CLK>;
- clock-names = "base_apb3_clk", "base_apb1_clk",
- "base_spifi_clk", "base_cpu_clk",
- "base_periph_clk", "base_usb0_clk",
- "base_usb1_clk", "base_spi_clk";
- };
-
- ccu2: clock-controller@40052000 {
- compatible = "nxp,lpc1850-ccu";
- reg = <0x40052000 0x1000>;
- #clock-cells = <1>;
- clocks = <&cgu BASE_AUDIO_CLK>, <&cgu BASE_UART3_CLK>,
- <&cgu BASE_UART2_CLK>, <&cgu BASE_UART1_CLK>,
- <&cgu BASE_UART0_CLK>, <&cgu BASE_SSP1_CLK>,
- <&cgu BASE_SSP0_CLK>, <&cgu BASE_SDIO_CLK>;
- clock-names = "base_audio_clk", "base_uart3_clk",
- "base_uart2_clk", "base_uart1_clk",
- "base_uart0_clk", "base_ssp1_clk",
- "base_ssp0_clk", "base_sdio_clk";
- };
-
- /* A user of CCU brach clocks */
- uart1: serial@40082000 {
- ...
- clocks = <&ccu2 CLK_APB0_UART1>, <&ccu1 CLK_CPU_UART1>;
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/lpc1850-cgu.txt b/Documentation/devicetree/bindings/clock/lpc1850-cgu.txt
deleted file mode 100644
index 2cc32a9a945a..000000000000
--- a/Documentation/devicetree/bindings/clock/lpc1850-cgu.txt
+++ /dev/null
@@ -1,131 +0,0 @@
-* NXP LPC1850 Clock Generation Unit (CGU)
-
-The CGU generates multiple independent clocks for the core and the
-peripheral blocks of the LPC18xx. Each independent clock is called
-a base clock and itself is one of the inputs to the two Clock
-Control Units (CCUs) which control the branch clocks to the
-individual peripherals.
-
-The CGU selects the inputs to the clock generators from multiple
-clock sources, controls the clock generation, and routes the outputs
-of the clock generators through the clock source bus to the output
-stages. Each output stage provides an independent clock source and
-corresponds to one of the base clocks for the LPC18xx.
-
- - Above text taken from NXP LPC1850 User Manual.
-
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible:
- Should be "nxp,lpc1850-cgu"
-- reg:
- Shall define the base and range of the address space
- containing clock control registers
-- #clock-cells:
- Shall have value <1>. The permitted clock-specifier values
- are the base clock numbers defined below.
-- clocks:
- Shall contain a list of phandles for the external input
- sources to the CGU. The list shall be in the following
- order: xtal, 32khz, enet_rx_clk, enet_tx_clk, gp_clkin.
-- clock-indices:
- Shall be an ordered list of numbers defining the base clock
- number provided by the CGU.
-- clock-output-names:
- Shall be an ordered list of strings defining the names of
- the clocks provided by the CGU.
-
-Which base clocks that are available on the CGU depends on the
-specific LPC part. Base clocks are numbered from 0 to 27.
-
-Number: Name: Description:
- 0 BASE_SAFE_CLK Base safe clock (always on) for WWDT
- 1 BASE_USB0_CLK Base clock for USB0
- 2 BASE_PERIPH_CLK Base clock for Cortex-M0SUB subsystem,
- SPI, and SGPIO
- 3 BASE_USB1_CLK Base clock for USB1
- 4 BASE_CPU_CLK System base clock for ARM Cortex-M core
- and APB peripheral blocks #0 and #2
- 5 BASE_SPIFI_CLK Base clock for SPIFI
- 6 BASE_SPI_CLK Base clock for SPI
- 7 BASE_PHY_RX_CLK Base clock for Ethernet PHY Receive clock
- 8 BASE_PHY_TX_CLK Base clock for Ethernet PHY Transmit clock
- 9 BASE_APB1_CLK Base clock for APB peripheral block # 1
-10 BASE_APB3_CLK Base clock for APB peripheral block # 3
-11 BASE_LCD_CLK Base clock for LCD
-12 BASE_ADCHS_CLK Base clock for ADCHS
-13 BASE_SDIO_CLK Base clock for SD/MMC
-14 BASE_SSP0_CLK Base clock for SSP0
-15 BASE_SSP1_CLK Base clock for SSP1
-16 BASE_UART0_CLK Base clock for UART0
-17 BASE_UART1_CLK Base clock for UART1
-18 BASE_UART2_CLK Base clock for UART2
-19 BASE_UART3_CLK Base clock for UART3
-20 BASE_OUT_CLK Base clock for CLKOUT pin
-24-21 - Reserved
-25 BASE_AUDIO_CLK Base clock for audio system (I2S)
-26 BASE_CGU_OUT0_CLK Base clock for CGU_OUT0 clock output
-27 BASE_CGU_OUT1_CLK Base clock for CGU_OUT1 clock output
-
-BASE_PERIPH_CLK and BASE_SPI_CLK is only available on LPC43xx.
-BASE_ADCHS_CLK is only available on LPC4370.
-
-
-Example board file:
-
-/ {
- clocks {
- xtal: xtal {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <12000000>;
- };
-
- xtal32: xtal32 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- };
-
- enet_rx_clk: enet_rx_clk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- clock-output-names = "enet_rx_clk";
- };
-
- enet_tx_clk: enet_tx_clk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- clock-output-names = "enet_tx_clk";
- };
-
- gp_clkin: gp_clkin {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- clock-output-names = "gp_clkin";
- };
- };
-
- soc {
- cgu: clock-controller@40050000 {
- compatible = "nxp,lpc1850-cgu";
- reg = <0x40050000 0x1000>;
- #clock-cells = <1>;
- clocks = <&xtal>, <&creg_clk 1>, <&enet_rx_clk>, <&enet_tx_clk>, <&gp_clkin>;
- };
-
- /* A CGU and CCU clock consumer */
- lcdc: lcdc@40008000 {
- ...
- clocks = <&cgu BASE_LCD_CLK>, <&ccu1 CLK_CPU_LCD>;
- clock-names = "clcdclk", "apb_pclk";
- ...
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt b/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
deleted file mode 100644
index 6f1c7b4e4d2c..000000000000
--- a/Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* NXP LPC1850 CREG clocks
-
-The NXP LPC18xx/43xx CREG (Configuration Registers) block contains
-control registers for two low speed clocks. One of the clocks is a
-32 kHz oscillator driver with power up/down and clock gating. Next
-is a fixed divider that creates a 1 kHz clock from the 32 kHz osc.
-
-These clocks are used by the RTC and the Event Router peripherials.
-The 32 kHz can also be routed to other peripherials to enable low
-power modes.
-
-This binding uses the common clock binding:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible:
- Should be "nxp,lpc1850-creg-clk"
-- #clock-cells:
- Shall have value <1>.
-- clocks:
- Shall contain a phandle to the fixed 32 kHz crystal.
-
-The creg-clk node must be a child of the creg syscon node.
-
-The following clocks are available from the clock node.
-
-Clock ID Name
- 0 1 kHz clock
- 1 32 kHz Oscillator
-
-Example:
-soc {
- creg: syscon@40043000 {
- compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
- reg = <0x40043000 0x1000>;
-
- creg_clk: clock-controller {
- compatible = "nxp,lpc1850-creg-clk";
- clocks = <&xtal32>;
- #clock-cells = <1>;
- };
-
- ...
- };
-
- rtc: rtc@40046000 {
- ...
- clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
- clock-names = "rtc", "reg";
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt
deleted file mode 100644
index 3ce97cfe999b..000000000000
--- a/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-AXM5516 clock driver bindings
------------------------------
-
-Required properties :
-- compatible : shall contain "lsi,axm5516-clks"
-- reg : shall contain base register location and length
-- #clock-cells : shall contain 1
-
-The consumer specifies the desired clock by having the clock ID in its "clocks"
-phandle cell. See <dt-bindings/clock/lsi,axxia-clock.h> for the list of
-supported clock IDs.
-
-Example:
-
- clks: clock-controller@2010020000 {
- compatible = "lsi,axm5516-clks";
- #clock-cells = <1>;
- reg = <0x20 0x10020000 0 0x20000>;
- };
-
- serial0: uart@2010080000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0x20 0x10080000 0 0x1000>;
- interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks AXXIA_CLK_PER>;
- clock-names = "apb_pclk";
- };
- };
-
diff --git a/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.yaml b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.yaml
new file mode 100644
index 000000000000..7a792dbeffb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 LSI
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/lsi,axm5516-clks.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LSI AXM5516 Clock Controller
+
+maintainers:
+ - Anders Berg <anders.berg@lsi.com>
+
+description:
+ See <dt-bindings/clock/lsi,axxia-clock.h> for the list of supported clock IDs.
+
+properties:
+ compatible:
+ const: lsi,axm5516-clks
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-controller@2010020000 {
+ compatible = "lsi,axm5516-clks";
+ #clock-cells = <1>;
+ reg = <0x20 0x10020000 0x20000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/lsi,nspire-cx-clock.yaml b/Documentation/devicetree/bindings/clock/lsi,nspire-cx-clock.yaml
new file mode 100644
index 000000000000..52c217d210d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/lsi,nspire-cx-clock.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/lsi,nspire-cx-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-NSPIRE Clocks
+
+maintainers:
+ - Daniel Tang <dt.tangr@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - lsi,nspire-cx-ahb-divider
+ - lsi,nspire-classic-ahb-divider
+ - lsi,nspire-cx-clock
+ - lsi,nspire-classic-clock
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
diff --git a/Documentation/devicetree/bindings/clock/marvell,ap80x-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,ap80x-clock.yaml
new file mode 100644
index 000000000000..43b0631ba167
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,ap80x-clock.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,ap80x-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada AP80x System Controller Clocks
+
+maintainers:
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: >
+ The AP806/AP807 is one of the two core HW blocks of the Marvell Armada
+ 7K/8K/931x SoCs. It contains system controllers, which provide several
+ registers giving access to numerous features: clocks, pin-muxing and many
+ other SoC configuration items.
+
+properties:
+ compatible:
+ enum:
+ - marvell,ap806-clock
+ - marvell,ap806-cpu-clock
+ - marvell,ap807-clock
+ - marvell,ap807-cpu-clock
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ items:
+ - description: cluster 0 parent clock phandle
+ - description: cluster 1 parent clock phandle
+
+required:
+ - compatible
+ - "#clock-cells"
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,ap806-cpu-clock
+ - marvell,ap807-cpu-clock
+ then:
+ required:
+ - clocks
diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-370-corediv-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-370-corediv-clock.yaml
new file mode 100644
index 000000000000..9d766558cdb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,armada-370-corediv-clock.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/marvell,armada-370-corediv-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MVEBU Core Divider Clock
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - marvell,armada-370-corediv-clock
+ - marvell,armada-375-corediv-clock
+ - marvell,armada-380-corediv-clock
+ - marvell,mv98dx3236-corediv-clock
+ - items:
+ - const: marvell,armada-390-corediv-clock
+ - const: marvell,armada-380-corediv-clock
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-output-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@18740 {
+ compatible = "marvell,armada-370-corediv-clock";
+ reg = <0x18740 0xc>;
+ #clock-cells = <1>;
+ clocks = <&pll>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-3700-periph-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-3700-periph-clock.yaml
new file mode 100644
index 000000000000..87e8e4ca111a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,armada-3700-periph-clock.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,armada-3700-periph-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 37xx SoCs Peripheral Clocks
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description: >
+ Marvell Armada 37xx SoCs provide peripheral clocks which are used as clock
+ source for the peripheral of the SoC.
+
+ There are two different blocks associated to north bridge and south bridge.
+
+ The following is a list of provided IDs for Armada 3700 North bridge clocks:
+
+ ID Clock name Description
+ -----------------------------------
+ 0 mmc MMC controller
+ 1 sata_host Sata Host
+ 2 sec_at Security AT
+ 3 sac_dap Security DAP
+ 4 tsecm Security Engine
+ 5 setm_tmx Serial Embedded Trace Module
+ 6 avs Adaptive Voltage Scaling
+ 7 sqf SPI
+ 8 pwm PWM
+ 9 i2c_2 I2C 2
+ 10 i2c_1 I2C 1
+ 11 ddr_phy DDR PHY
+ 12 ddr_fclk DDR F clock
+ 13 trace Trace
+ 14 counter Counter
+ 15 eip97 EIP 97
+ 16 cpu CPU
+
+ The following is a list of provided IDs for Armada 3700 South bridge clocks:
+
+ ID Clock name Description
+ -----------------------------------
+ 0 gbe-50 50 MHz parent clock for Gigabit Ethernet
+ 1 gbe-core parent clock for Gigabit Ethernet core
+ 2 gbe-125 125 MHz parent clock for Gigabit Ethernet
+ 3 gbe1-50 50 MHz clock for Gigabit Ethernet port 1
+ 4 gbe0-50 50 MHz clock for Gigabit Ethernet port 0
+ 5 gbe1-125 125 MHz clock for Gigabit Ethernet port 1
+ 6 gbe0-125 125 MHz clock for Gigabit Ethernet port 0
+ 7 gbe1-core Gigabit Ethernet core port 1
+ 8 gbe0-core Gigabit Ethernet core port 0
+ 9 gbe-bm Gigabit Ethernet Buffer Manager
+ 10 sdio SDIO
+ 11 usb32-sub2-sys USB 2 clock
+ 12 usb32-ss-sys USB 3 clock
+ 13 pcie PCIe controller
+
+properties:
+ compatible:
+ oneOf:
+ - const: marvell,armada-3700-periph-clock-sb
+ - items:
+ - const: marvell,armada-3700-periph-clock-nb
+ - const: syscon
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TBG-A P clock and specifier
+ - description: TBG-B P clock and specifier
+ - description: TBG-A S clock and specifier
+ - description: TBG-B S clock and specifier
+ - description: Xtal clock and specifier
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@13000{
+ compatible = "marvell,armada-3700-periph-clock-sb";
+ reg = <0x13000 0x1000>;
+ clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>, <&tbg 3>, <&xtalclk>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-3700-tbg-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-3700-tbg-clock.yaml
new file mode 100644
index 000000000000..7fd1d758f794
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,armada-3700-tbg-clock.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,armada-3700-tbg-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 3700 Time Base Generator Clock
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description: >
+ Marvell Armada 37xx SoCs provide Time Base Generator clocks which are used as
+ parent clocks for the peripheral clocks.
+
+ The TBG clock consumer should specify the desired clock by having the clock ID
+ in its "clocks" phandle cell.
+
+ The following is a list of provided IDs and clock names on Armada 3700:
+
+ 0 = TBG A P
+ 1 = TBG B P
+ 2 = TBG A S
+ 3 = TBG B S
+
+properties:
+ compatible:
+ const: marvell,armada-3700-tbg-clock
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@13200 {
+ compatible = "marvell,armada-3700-tbg-clock";
+ reg = <0x13200 0x1000>;
+ clocks = <&xtalclk>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-xp-cpu-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-xp-cpu-clock.yaml
new file mode 100644
index 000000000000..f2ac6741da9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,armada-xp-cpu-clock.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+---
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+$id: http://devicetree.org/schemas/clock/marvell,armada-xp-cpu-clock.yaml#
+
+title: Marvell EBU CPU Clock
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-xp-cpu-clock
+ - marvell,mv98dx3236-cpu-clock
+
+ reg:
+ items:
+ - description: Clock complex registers
+ - description: PMU DFS registers
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@d0018700 {
+ #clock-cells = <1>;
+ compatible = "marvell,armada-xp-cpu-clock";
+ reg = <0xd0018700 0xa0>, <0x1c054 0x10>;
+ clocks = <&coreclk 1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell,berlin.txt b/Documentation/devicetree/bindings/clock/marvell,berlin.txt
deleted file mode 100644
index c611c495f3ff..000000000000
--- a/Documentation/devicetree/bindings/clock/marvell,berlin.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Device Tree Clock bindings for Marvell Berlin
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Clock related registers are spread among the chip control registers. Berlin
-clock node should be a sub-node of the chip controller node. Marvell Berlin2
-(BG2, BG2CD, BG2Q) SoCs share the same IP for PLLs and clocks, with some
-minor differences in features and register layout.
-
-Required properties:
-- compatible: must be "marvell,berlin2-clk" or "marvell,berlin2q-clk"
-- #clock-cells: must be 1
-- clocks: must be the input parent clock phandle
-- clock-names: name of the input parent clock
- Allowed clock-names for the reference clocks are
- "refclk" for the SoCs oscillator input on all SoCs,
- and SoC-specific input clocks for
- BG2/BG2CD: "video_ext0" for the external video clock input
-
-
-Example:
-
-chip_clk: clock {
- compatible = "marvell,berlin2q-clk";
-
- #clock-cells = <1>;
- clocks = <&refclk>;
- clock-names = "refclk";
-};
diff --git a/Documentation/devicetree/bindings/clock/marvell,berlin2-clk.yaml b/Documentation/devicetree/bindings/clock/marvell,berlin2-clk.yaml
new file mode 100644
index 000000000000..8d48a2c7e381
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,berlin2-clk.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,berlin2-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Berlin Clock Controller
+
+maintainers:
+ - Jisheng Zhang <jszhang@kernel.org>
+
+description:
+ Clock related registers are spread among the chip control registers. Berlin
+ clock node should be a sub-node of the chip controller node. Marvell Berlin2
+ (BG2, BG2CD, BG2Q) SoCs share the same IP for PLLs and clocks, with some minor
+ differences in features and register layout.
+
+properties:
+ compatible:
+ enum:
+ - marvell,berlin2-clk
+ - marvell,berlin2q-clk
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - enum:
+ - refclk
+ - video_ext0
+
+required:
+ - compatible
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller {
+ compatible = "marvell,berlin2q-clk";
+ #clock-cells = <1>;
+ clocks = <&refclk>;
+ clock-names = "refclk";
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell,cp110-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,cp110-clock.yaml
new file mode 100644
index 000000000000..ad0bc79b24c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,cp110-clock.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,cp110-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada CP110 System Controller Clocks
+
+maintainers:
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: >
+ The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K/931x
+ SoCs. It contains system controllers, which provide several registers giving
+ access to numerous features: clocks, pin-muxing and many other SoC
+ configuration items.
+
+properties:
+ compatible:
+ const: marvell,cp110-clock
+
+ "#clock-cells":
+ const: 2
+ description: >
+ The first cell must be 0 or 1. 0 for the core clocks and 1 for the
+ gateable clocks. The second cell identifies the particular core clock or
+ gateable clocks.
+
+ The following clocks are available:
+
+ - Core clocks
+ - 0 0 APLL
+ - 0 1 PPv2 core
+ - 0 2 EIP
+ - 0 3 Core
+ - 0 4 NAND core
+ - 0 5 SDIO core
+
+ - Gateable clocks
+ - 1 0 Audio
+ - 1 1 Comm Unit
+ - 1 2 NAND
+ - 1 3 PPv2
+ - 1 4 SDIO
+ - 1 5 MG Domain
+ - 1 6 MG Core
+ - 1 7 XOR1
+ - 1 8 XOR0
+ - 1 9 GOP DP
+ - 1 11 PCIe x1 0
+ - 1 12 PCIe x1 1
+ - 1 13 PCIe x4
+ - 1 14 PCIe / XOR
+ - 1 15 SATA
+ - 1 16 SATA USB
+ - 1 17 Main
+ - 1 18 SD/MMC/GOP
+ - 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
+ - 1 22 USB3H0
+ - 1 23 USB3H1
+ - 1 24 USB3 Device
+ - 1 25 EIP150
+ - 1 26 EIP197
+
+required:
+ - compatible
+ - "#clock-cells"
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/marvell,dove-divider-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,dove-divider-clock.yaml
new file mode 100644
index 000000000000..7a8e0e281b63
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,dove-divider-clock.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/marvell,dove-divider-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Dove PLL Divider Clock
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description: >
+ Marvell Dove has a 2GHz PLL, which feeds into a set of dividers to provide
+ high speed clocks for a number of peripherals. These dividers are part of the
+ PMU, and thus this node should be a child of the PMU node.
+
+ The following clocks are provided:
+
+ ID Clock
+ -------------
+ 0 AXI bus clock
+ 1 GPU clock
+ 2 VMeta clock
+ 3 LCD clock
+
+properties:
+ compatible:
+ const: marvell,dove-divider-clock
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@64 {
+ compatible = "marvell,dove-divider-clock";
+ reg = <0x0064 0x8>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell,mvebu-core-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,mvebu-core-clock.yaml
new file mode 100644
index 000000000000..215bcd9080c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,mvebu-core-clock.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,mvebu-core-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MVEBU SoC core clock
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description: >
+ Marvell MVEBU SoCs usually allow to determine core clock frequencies by
+ reading the Sample-At-Reset (SAR) register. The core clock consumer should
+ specify the desired clock by having the clock ID in its "clocks" phandle cell.
+
+ The following is a list of provided IDs and clock names on Armada 370/XP:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU clock)
+ 2 = nbclk (L2 Cache clock)
+ 3 = hclk (DRAM control clock)
+ 4 = dramclk (DDR clock)
+
+ The following is a list of provided IDs and clock names on Armada 375:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU clock)
+ 2 = l2clk (L2 Cache clock)
+ 3 = ddrclk (DDR clock)
+
+ The following is a list of provided IDs and clock names on Armada 380/385:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU clock)
+ 2 = l2clk (L2 Cache clock)
+ 3 = ddrclk (DDR clock)
+
+ The following is a list of provided IDs and clock names on Armada 39x:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU clock)
+ 2 = nbclk (Coherent Fabric clock)
+ 3 = hclk (SDRAM Controller Internal Clock)
+ 4 = dclk (SDRAM Interface Clock)
+ 5 = refclk (Reference Clock)
+
+ The following is a list of provided IDs and clock names on 98dx3236:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU clock)
+ 2 = ddrclk (DDR clock)
+ 3 = mpll (MPLL Clock)
+
+ The following is a list of provided IDs and clock names on Kirkwood and Dove:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU0 clock)
+ 2 = l2clk (L2 Cache clock derived from CPU0 clock)
+ 3 = ddrclk (DDR controller clock derived from CPU0 clock)
+
+ The following is a list of provided IDs and clock names on Orion5x:
+ 0 = tclk (Internal Bus clock)
+ 1 = cpuclk (CPU0 clock)
+ 2 = ddrclk (DDR controller clock derived from CPU0 clock)
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-370-core-clock
+ - marvell,armada-375-core-clock
+ - marvell,armada-380-core-clock
+ - marvell,armada-390-core-clock
+ - marvell,armada-xp-core-clock
+ - marvell,dove-core-clock
+ - marvell,kirkwood-core-clock
+ - marvell,mv88f5181-core-clock
+ - marvell,mv88f5182-core-clock
+ - marvell,mv88f5281-core-clock
+ - marvell,mv88f6180-core-clock
+ - marvell,mv88f6183-core-clock
+ - marvell,mv98dx1135-core-clock
+ - marvell,mv98dx3236-core-clock
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clock-output-names:
+ description: Overwrite default clock output names.
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
new file mode 100644
index 000000000000..6f3a8578fe2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/marvell,pxa1908.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell PXA1908 Clock Controllers
+
+maintainers:
+ - Duje Mihanović <duje.mihanovic@skole.hr>
+
+description: |
+ The PXA1908 clock subsystem generates and supplies clock to various
+ controllers within the PXA1908 SoC. The PXA1908 contains numerous clock
+ controller blocks, with the ones currently supported being APBC, APBCP, MPMU
+ and APMU roughly corresponding to internal buses.
+
+ All these clock identifiers could be found in <include/dt-bindings/marvell,pxa1908.h>.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - marvell,pxa1908-apbc
+ - marvell,pxa1908-apbcp
+ - marvell,pxa1908-mpmu
+ - items:
+ - const: marvell,pxa1908-apmu
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: marvell,pxa1908-apmu
+
+then:
+ properties:
+ '#power-domain-cells': false
+
+examples:
+ # APMU block:
+ - |
+ clock-controller@d4282800 {
+ compatible = "marvell,pxa1908-apmu", "syscon";
+ reg = <0xd4282800 0x400>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/marvell-armada-370-gating-clock.yaml b/Documentation/devicetree/bindings/clock/marvell-armada-370-gating-clock.yaml
new file mode 100644
index 000000000000..0475360d2b6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell-armada-370-gating-clock.yaml
@@ -0,0 +1,227 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+---
+$id: http://devicetree.org/schemas/clock/marvell-armada-370-gating-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell EBU SoC gating-clock
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description: >
+ Marvell Armada 370/375/380/385/39x/XP, Dove and Kirkwood allow some peripheral
+ clocks to be gated to save some power. The clock ID is directly mapped to the
+ corresponding clock gating control bit in HW to ease manual clock lookup in
+ datasheet.
+
+ The following is a list of provided IDs for Armada 370:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 0 Audio AC97 Cntrl
+ 1 pex0_en PCIe 0 Clock out
+ 2 pex1_en PCIe 1 Clock out
+ 3 ge1 Gigabit Ethernet 1
+ 4 ge0 Gigabit Ethernet 0
+ 5 pex0 PCIe Cntrl 0
+ 9 pex1 PCIe Cntrl 1
+ 15 sata0 SATA Host 0
+ 17 sdio SDHCI Host
+ 23 crypto CESA (crypto engine)
+ 25 tdm Time Division Mplx
+ 28 ddr DDR Cntrl
+ 30 sata1 SATA Host 0
+
+ The following is a list of provided IDs for Armada 375:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 2 mu Management Unit
+ 3 pp Packet Processor
+ 4 ptp PTP
+ 5 pex0 PCIe 0 Clock out
+ 6 pex1 PCIe 1 Clock out
+ 8 audio Audio Cntrl
+ 11 nd_clk Nand Flash Cntrl
+ 14 sata0_link SATA 0 Link
+ 15 sata0_core SATA 0 Core
+ 16 usb3 USB3 Host
+ 17 sdio SDHCI Host
+ 18 usb USB Host
+ 19 gop Gigabit Ethernet MAC
+ 20 sata1_link SATA 1 Link
+ 21 sata1_core SATA 1 Core
+ 22 xor0 XOR DMA 0
+ 23 xor1 XOR DMA 0
+ 24 copro Coprocessor
+ 25 tdm Time Division Mplx
+ 28 crypto0_enc Cryptographic Unit Port 0 Encryption
+ 29 crypto0_core Cryptographic Unit Port 0 Core
+ 30 crypto1_enc Cryptographic Unit Port 1 Encryption
+ 31 crypto1_core Cryptographic Unit Port 1 Core
+
+ The following is a list of provided IDs for Armada 380/385:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 0 audio Audio
+ 2 ge2 Gigabit Ethernet 2
+ 3 ge1 Gigabit Ethernet 1
+ 4 ge0 Gigabit Ethernet 0
+ 5 pex1 PCIe 1
+ 6 pex2 PCIe 2
+ 7 pex3 PCIe 3
+ 8 pex0 PCIe 0
+ 9 usb3h0 USB3 Host 0
+ 10 usb3h1 USB3 Host 1
+ 11 usb3d USB3 Device
+ 13 bm Buffer Management
+ 14 crypto0z Cryptographic 0 Z
+ 15 sata0 SATA 0
+ 16 crypto1z Cryptographic 1 Z
+ 17 sdio SDIO
+ 18 usb2 USB 2
+ 21 crypto1 Cryptographic 1
+ 22 xor0 XOR 0
+ 23 crypto0 Cryptographic 0
+ 25 tdm Time Division Multiplexing
+ 28 xor1 XOR 1
+ 30 sata1 SATA 1
+
+ The following is a list of provided IDs for Armada 39x:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 5 pex1 PCIe 1
+ 6 pex2 PCIe 2
+ 7 pex3 PCIe 3
+ 8 pex0 PCIe 0
+ 9 usb3h0 USB3 Host 0
+ 10 usb3h1 USB3 Host 1
+ 15 sata0 SATA 0
+ 17 sdio SDIO
+ 22 xor0 XOR 0
+ 28 xor1 XOR 1
+
+ The following is a list of provided IDs for Armada XP:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 0 audio Audio Cntrl
+ 1 ge3 Gigabit Ethernet 3
+ 2 ge2 Gigabit Ethernet 2
+ 3 ge1 Gigabit Ethernet 1
+ 4 ge0 Gigabit Ethernet 0
+ 5 pex0 PCIe Cntrl 0
+ 6 pex1 PCIe Cntrl 1
+ 7 pex2 PCIe Cntrl 2
+ 8 pex3 PCIe Cntrl 3
+ 13 bp
+ 14 sata0lnk
+ 15 sata0 SATA Host 0
+ 16 lcd LCD Cntrl
+ 17 sdio SDHCI Host
+ 18 usb0 USB Host 0
+ 19 usb1 USB Host 1
+ 20 usb2 USB Host 2
+ 22 xor0 XOR DMA 0
+ 23 crypto CESA engine
+ 25 tdm Time Division Mplx
+ 28 xor1 XOR DMA 1
+ 29 sata1lnk
+ 30 sata1 SATA Host 1
+
+ The following is a list of provided IDs for 98dx3236:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 3 ge1 Gigabit Ethernet 1
+ 4 ge0 Gigabit Ethernet 0
+ 5 pex0 PCIe Cntrl 0
+ 17 sdio SDHCI Host
+ 18 usb0 USB Host 0
+ 22 xor0 XOR DMA 0
+
+ The following is a list of provided IDs for Dove:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 0 usb0 USB Host 0
+ 1 usb1 USB Host 1
+ 2 ge Gigabit Ethernet
+ 3 sata SATA Host
+ 4 pex0 PCIe Cntrl 0
+ 5 pex1 PCIe Cntrl 1
+ 8 sdio0 SDHCI Host 0
+ 9 sdio1 SDHCI Host 1
+ 10 nand NAND Cntrl
+ 11 camera Camera Cntrl
+ 12 i2s0 I2S Cntrl 0
+ 13 i2s1 I2S Cntrl 1
+ 15 crypto CESA engine
+ 21 ac97 AC97 Cntrl
+ 22 pdma Peripheral DMA
+ 23 xor0 XOR DMA 0
+ 24 xor1 XOR DMA 1
+ 30 gephy Gigabit Ethernet PHY
+ Note: gephy(30) is implemented as a parent clock of ge(2)
+
+ The following is a list of provided IDs for Kirkwood:
+
+ ID Clock Peripheral
+ -----------------------------------
+ 0 ge0 Gigabit Ethernet 0
+ 2 pex0 PCIe Cntrl 0
+ 3 usb0 USB Host 0
+ 4 sdio SDIO Cntrl
+ 5 tsu Transp. Stream Unit
+ 6 dunit SDRAM Cntrl
+ 7 runit Runit
+ 8 xor0 XOR DMA 0
+ 9 audio I2S Cntrl 0
+ 14 sata0 SATA Host 0
+ 15 sata1 SATA Host 1
+ 16 xor1 XOR DMA 1
+ 17 crypto CESA engine
+ 18 pex1 PCIe Cntrl 1
+ 19 ge1 Gigabit Ethernet 1
+ 20 tdm Time Division Mplx
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-370-gating-clock
+ - marvell,armada-375-gating-clock
+ - marvell,armada-380-gating-clock
+ - marvell,armada-390-gating-clock
+ - marvell,armada-xp-gating-clock
+ - marvell,mv98dx3236-gating-clock
+ - marvell,dove-gating-clock
+ - marvell,kirkwood-gating-clock
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@d0038 {
+ compatible = "marvell,dove-gating-clock";
+ reg = <0xd0038 0x4>;
+ /* default parent clock is tclk */
+ clocks = <&core_clk 0>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
deleted file mode 100644
index c10849efb444..000000000000
--- a/Documentation/devicetree/bindings/clock/maxim,max77686.txt
+++ /dev/null
@@ -1,114 +0,0 @@
-Binding for Maxim MAX77686/MAX77802/MAX77620 32k clock generator block
-
-This is a part of device tree bindings of MAX77686/MAX77802/MAX77620
-multi-function device. More information can be found in MFD DT binding
-doc as follows:
- bindings/mfd/max77686.txt for MAX77686 and
- bindings/mfd/max77802.txt for MAX77802 and
- bindings/mfd/max77620.txt for MAX77620.
-
-The MAX77686 contains three 32.768khz clock outputs that can be controlled
-(gated/ungated) over I2C. Clocks are defined as preprocessor macros in
-dt-bindings/clock/maxim,max77686.h.
-
-
-The MAX77802 contains two 32.768khz clock outputs that can be controlled
-(gated/ungated) over I2C. Clocks are defined as preprocessor macros in
-dt-bindings/clock/maxim,max77802.h.
-
-The MAX77686 contains one 32.768khz clock outputs that can be controlled
-(gated/ungated) over I2C. Clocks are defined as preprocessor macros in
-dt-bindings/clock/maxim,max77620.h.
-
-Following properties should be presend in main device node of the MFD chip.
-
-Required properties:
-
-- #clock-cells: from common clock binding; shall be set to 1.
-
-Optional properties:
-- clock-output-names: From common clock binding.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Following indices are allowed:
- - 0: 32khz_ap clock (max77686, max77802), 32khz_out0 (max77620)
- - 1: 32khz_cp clock (max77686, max77802),
- - 2: 32khz_pmic clock (max77686).
-
-Clocks are defined as preprocessor macros in above dt-binding header for
-respective chips.
-
-Example:
-
-1. With MAX77686:
-
-#include <dt-bindings/clock/maxim,max77686.h>
-/* ... */
-
- Node of the MFD chip
- max77686: max77686@9 {
- compatible = "maxim,max77686";
- interrupt-parent = <&wakeup_eint>;
- interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
- reg = <0x09>;
- #clock-cells = <1>;
-
- /* ... */
- };
-
- Clock consumer node
-
- foo@0 {
- compatible = "bar,foo";
- /* ... */
- clock-names = "my-clock";
- clocks = <&max77686 MAX77686_CLK_PMIC>;
- };
-
-2. With MAX77802:
-
-#include <dt-bindings/clock/maxim,max77802.h>
-/* ... */
-
- Node of the MFD chip
- max77802: max77802@9 {
- compatible = "maxim,max77802";
- interrupt-parent = <&wakeup_eint>;
- interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
- reg = <0x09>;
- #clock-cells = <1>;
-
- /* ... */
- };
-
- Clock consumer node
-
- foo@0 {
- compatible = "bar,foo";
- /* ... */
- clock-names = "my-clock";
- clocks = <&max77802 MAX77802_CLK_32K_AP>;
- };
-
-
-3. With MAX77620:
-
-#include <dt-bindings/clock/maxim,max77620.h>
-/* ... */
-
- Node of the MFD chip
- max77620: max77620@3c {
- compatible = "maxim,max77620";
- reg = <0x3c>;
- #clock-cells = <1>;
- /* ... */
- };
-
- Clock consumer node
-
- foo@0 {
- compatible = "bar,foo";
- /* ... */
- clock-names = "my-clock";
- clocks = <&max77620 MAX77620_CLK_32K_OUT0>;
- };
diff --git a/Documentation/devicetree/bindings/clock/maxim,max9485.txt b/Documentation/devicetree/bindings/clock/maxim,max9485.txt
deleted file mode 100644
index 61bec1100a94..000000000000
--- a/Documentation/devicetree/bindings/clock/maxim,max9485.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Devicetree bindings for Maxim MAX9485 Programmable Audio Clock Generator
-
-This device exposes 4 clocks in total:
-
-- MAX9485_MCLKOUT: A gated, buffered output of the input clock of 27 MHz
-- MAX9485_CLKOUT: A PLL that can be configured to 16 different discrete
- frequencies
-- MAX9485_CLKOUT[1,2]: Two gated outputs for MAX9485_CLKOUT
-
-MAX9485_CLKOUT[1,2] are children of MAX9485_CLKOUT which upchain all rate set
-requests.
-
-Required properties:
-- compatible: "maxim,max9485"
-- clocks: Input clock, must provice 27.000 MHz
-- clock-names: Must be set to "xclk"
-- #clock-cells: From common clock binding; shall be set to 1
-
-Optional properties:
-- reset-gpios: GPIO descriptor connected to the #RESET input pin
-- vdd-supply: A regulator node for Vdd
-- clock-output-names: Name of output clocks, as defined in common clock
- bindings
-
-If not explicitly set, the output names are "mclkout", "clkout", "clkout1"
-and "clkout2".
-
-Clocks are defined as preprocessor macros in the dt-binding header.
-
-Example:
-
- #include <dt-bindings/clock/maxim,max9485.h>
-
- xo-27mhz: xo-27mhz {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <27000000>;
- };
-
- &i2c0 {
- max9485: audio-clock@63 {
- reg = <0x63>;
- compatible = "maxim,max9485";
- clock-names = "xclk";
- clocks = <&xo-27mhz>;
- reset-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
- vdd-supply = <&3v3-reg>;
- #clock-cells = <1>;
- };
- };
-
- // Clock consumer node
-
- foo@0 {
- compatible = "bar,foo";
- /* ... */
- clock-names = "foo-input-clk";
- clocks = <&max9485 MAX9485_CLKOUT1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/maxim,max9485.yaml b/Documentation/devicetree/bindings/clock/maxim,max9485.yaml
new file mode 100644
index 000000000000..f9d8941c7235
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/maxim,max9485.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/maxim,max9485.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX9485 Programmable Audio Clock Generator
+
+maintainers:
+ - Daniel Mack <daniel@zonque.org>
+
+description: >
+ Maxim MAX9485 Programmable Audio Clock Generator exposes 4 clocks in total:
+
+ - MAX9485_MCLKOUT: A gated, buffered output of the input clock of 27 MHz
+ - MAX9485_CLKOUT: A PLL that can be configured to 16 different discrete
+ frequencies
+ - MAX9485_CLKOUT[1,2]: Two gated outputs for MAX9485_CLKOUT
+
+ MAX9485_CLKOUT[1,2] are children of MAX9485_CLKOUT which upchain all rate set
+ requests.
+
+properties:
+ compatible:
+ const: maxim,max9485
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Input clock. Must provide 27 MHz
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xclk
+
+ '#clock-cells':
+ const: 1
+
+ reset-gpios:
+ description: >
+ GPIO descriptor connected to the #RESET input pin
+
+ vdd-supply:
+ description: A regulator node for Vdd
+
+ clock-output-names:
+ description: Name of output clocks, as defined in common clock bindings
+ items:
+ - const: mclkout
+ - const: clkout
+ - const: clkout1
+ - const: clkout2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@63 {
+ compatible = "maxim,max9485";
+ reg = <0x63>;
+ #clock-cells = <1>;
+ clock-names = "xclk";
+ clocks = <&xo_27mhz>;
+ reset-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ vdd-supply = <&reg_3v3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
index 770546195fb5..591a9e862c7d 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek AP Mixedsys Controller
@@ -12,7 +12,8 @@ maintainers:
description:
The Mediatek apmixedsys controller provides PLLs to the system.
- The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+ The clock values can be found in <dt-bindings/clock/mt*-clk.h>
+ and <dt-bindings/clock/mediatek,mt*-apmixedsys.h>.
properties:
compatible:
@@ -20,7 +21,9 @@ properties:
- enum:
- mediatek,mt6797-apmixedsys
- mediatek,mt7622-apmixedsys
+ - mediatek,mt7981-apmixedsys
- mediatek,mt7986-apmixedsys
+ - mediatek,mt7988-apmixedsys
- mediatek,mt8135-apmixedsys
- mediatek,mt8173-apmixedsys
- mediatek,mt8516-apmixedsys
@@ -32,8 +35,10 @@ properties:
- enum:
- mediatek,mt2701-apmixedsys
- mediatek,mt2712-apmixedsys
+ - mediatek,mt6735-apmixedsys
- mediatek,mt6765-apmixedsys
- - mediatek,mt6779-apmixedsys
+ - mediatek,mt6779-apmixed
+ - mediatek,mt6795-apmixedsys
- mediatek,mt7629-apmixedsys
- mediatek,mt8167-apmixedsys
- mediatek,mt8183-apmixedsys
diff --git a/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
new file mode 100644
index 000000000000..f9cddacc2eae
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,ethsys.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,ethsys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek ethsys controller
+
+description:
+ The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+maintainers:
+ - James Liao <jamesjj.liao@mediatek.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt2701-ethsys
+ - mediatek,mt7622-ethsys
+ - mediatek,mt7629-ethsys
+ - mediatek,mt7981-ethsys
+ - mediatek,mt7986-ethsys
+ - mediatek,mt7988-ethsys
+ - const: syscon
+ - items:
+ - const: mediatek,mt7623-ethsys
+ - const: mediatek,mt2701-ethsys
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@1b000000 {
+ compatible = "mediatek,mt2701-ethsys", "syscon";
+ reg = <0x1b000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/clock/mediatek,infracfg.yaml
index 8681b785ed6d..d1d30700d9b0 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,infracfg.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,infracfg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Infrastructure System Configuration Controller
@@ -11,9 +11,10 @@ maintainers:
description:
The Mediatek infracfg controller provides various clocks and reset outputs
- to the system. The clock values can be found in <dt-bindings/clock/mt*-clk.h>,
- and reset values in <dt-bindings/reset/mt*-reset.h> and
- <dt-bindings/reset/mt*-resets.h>.
+ to the system. The clock values can be found in <dt-bindings/clock/mt*-clk.h>
+ and <dt-bindings/clock/mediatek,mt*-infracfg.h>, and reset values in
+ <dt-bindings/reset/mt*-reset.h>, <dt-bindings/reset/mt*-resets.h> and
+ <dt-bindings/reset/mediatek,mt*-infracfg.h>.
properties:
compatible:
@@ -22,12 +23,16 @@ properties:
- enum:
- mediatek,mt2701-infracfg
- mediatek,mt2712-infracfg
+ - mediatek,mt6735-infracfg
- mediatek,mt6765-infracfg
+ - mediatek,mt6795-infracfg
- mediatek,mt6779-infracfg_ao
- mediatek,mt6797-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7629-infracfg
+ - mediatek,mt7981-infracfg
- mediatek,mt7986-infracfg
+ - mediatek,mt7988-infracfg
- mediatek,mt8135-infracfg
- mediatek,mt8167-infracfg
- mediatek,mt8173-infracfg
@@ -60,6 +65,7 @@ if:
enum:
- mediatek,mt2701-infracfg
- mediatek,mt2712-infracfg
+ - mediatek,mt6795-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7986-infracfg
- mediatek,mt8135-infracfg
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt2701-hifsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt2701-hifsys.yaml
new file mode 100644
index 000000000000..9e7c725093aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt2701-hifsys.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt2701-hifsys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek HIFSYS clock and reset controller
+
+description:
+ The MediaTek HIFSYS controller provides various clocks and reset outputs to
+ the system.
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-hifsys
+ - mediatek,mt7622-hifsys
+ - items:
+ - enum:
+ - mediatek,mt7623-hifsys
+ - const: mediatek,mt2701-hifsys
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+ description: The available clocks are defined in dt-bindings/clock/mt*-clk.h
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - reg
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@1a000000 {
+ compatible = "mediatek,mt2701-hifsys";
+ reg = <0x1a000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt6795-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt6795-clock.yaml
new file mode 100644
index 000000000000..04469eabc8fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt6795-clock.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt6795-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Functional Clock Controller for MT6795
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - Chun-Jie Chen <chun-jie.chen@mediatek.com>
+
+description: |
+ The clock architecture in MediaTek like below
+ PLLs -->
+ dividers -->
+ muxes
+ -->
+ clock gate
+
+ The devices provide clock gate control in different IP blocks.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6795-mfgcfg
+ - mediatek,mt6795-vdecsys
+ - mediatek,mt6795-vencsys
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mfgcfg: clock-controller@13000000 {
+ compatible = "mediatek,mt6795-mfgcfg";
+ reg = <0 0x13000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: clock-controller@16000000 {
+ compatible = "mediatek,mt6795-vdecsys";
+ reg = <0 0x16000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vencsys: clock-controller@18000000 {
+ compatible = "mediatek,mt6795-vencsys";
+ reg = <0 0x18000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
index 0c0b0ae5e2ac..b42f0f5c11b7 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/mediatek,mt7621-sysc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MT7621 Clock Device Tree Bindings
+title: MT7621 Clock
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7622-pciesys.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7622-pciesys.yaml
new file mode 100644
index 000000000000..9c3913f9092c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7622-pciesys.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7622-pciesys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek PCIESYS clock and reset controller
+
+description:
+ The MediaTek PCIESYS controller provides various clocks to the system.
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: mediatek,mt7622-pciesys
+ - const: syscon
+ - const: mediatek,mt7629-pciesys
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+ description: The available clocks are defined in dt-bindings/clock/mt*-clk.h
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@1a100800 {
+ compatible = "mediatek,mt7622-pciesys", "syscon";
+ reg = <0x1a100800 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7622-ssusbsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7622-ssusbsys.yaml
new file mode 100644
index 000000000000..da93eccdcfc1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7622-ssusbsys.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7622-ssusbsys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SSUSBSYS clock and reset controller
+
+description:
+ The MediaTek SSUSBSYS controller provides various clocks to the system.
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7622-ssusbsys
+ - mediatek,mt7629-ssusbsys
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+ description: The available clocks are defined in dt-bindings/clock/mt*-clk.h
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@1a000000 {
+ compatible = "mediatek,mt7622-ssusbsys";
+ reg = <0x1a000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
new file mode 100644
index 000000000000..e32a0251ff6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-ethwarp.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7988-ethwarp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 ethwarp Controller
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ The Mediatek MT7988 ethwarp controller provides clocks and resets for the
+ Ethernet related subsystems found the MT7988 SoC.
+ The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+
+properties:
+ compatible:
+ items:
+ - const: mediatek,mt7988-ethwarp
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/ti-syscon.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@15031000 {
+ compatible = "mediatek,mt7988-ethwarp";
+ reg = <0 0x15031000 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
new file mode 100644
index 000000000000..192f1451f0af
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7988-xfi-pll.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7988-xfi-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI PLL Clock Controller
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ The MediaTek XFI PLL controller provides the 156.25MHz clock for the
+ Ethernet SerDes PHY from the 40MHz top_xtal clock.
+
+properties:
+ compatible:
+ const: mediatek,mt7988-xfi-pll
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - resets
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ clock-controller@11f40000 {
+ compatible = "mediatek,mt7988-xfi-pll";
+ reg = <0 0x11f40000 0 0x1000>;
+ resets = <&watchdog 16>;
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
index cf1002c3efa6..f4e58bfa504f 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,mt8186-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Functional Clock Controller for MT8186
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml
new file mode 100644
index 000000000000..d00327d12e1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8186-fhctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek frequency hopping and spread spectrum clocking control
+
+maintainers:
+ - Edward-JW Yang <edward-jw.yang@mediatek.com>
+
+description: |
+ Frequency hopping control (FHCTL) is a piece of hardware that control
+ some PLLs to adopt "hopping" mechanism to adjust their frequency.
+ Spread spectrum clocking (SSC) is another function provided by this hardware.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6795-fhctl
+ - mediatek,mt8173-fhctl
+ - mediatek,mt8186-fhctl
+ - mediatek,mt8192-fhctl
+ - mediatek,mt8195-fhctl
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Phandles of the PLL with FHCTL hardware capability.
+ minItems: 1
+ maxItems: 30
+
+ mediatek,hopping-ssc-percent:
+ description: The percentage of spread spectrum clocking for one PLL.
+ minItems: 1
+ maxItems: 30
+ items:
+ default: 0
+ minimum: 0
+ maximum: 8
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8186-clk.h>
+ fhctl: fhctl@1000ce00 {
+ compatible = "mediatek,mt8186-fhctl";
+ reg = <0x1000ce00 0x200>;
+ clocks = <&apmixedsys CLK_APMIXED_MSDCPLL>;
+ mediatek,hopping-ssc-percent = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
index 661047d26e11..1c446fbc5108 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,mt8186-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek System Clock Controller for MT8186
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml
new file mode 100644
index 000000000000..5403242545ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8188-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Functional Clock Controller for MT8188
+
+maintainers:
+ - Garmin Chang <garmin.chang@mediatek.com>
+
+description: |
+ The clock architecture in MediaTek like below
+ PLLs -->
+ dividers -->
+ muxes
+ -->
+ clock gate
+
+ The devices provide clock gate control in different IP blocks.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-adsp-audio26m
+ - mediatek,mt8188-camsys
+ - mediatek,mt8188-camsys-rawa
+ - mediatek,mt8188-camsys-rawb
+ - mediatek,mt8188-camsys-yuva
+ - mediatek,mt8188-camsys-yuvb
+ - mediatek,mt8188-ccusys
+ - mediatek,mt8188-imgsys
+ - mediatek,mt8188-imgsys-wpe1
+ - mediatek,mt8188-imgsys-wpe2
+ - mediatek,mt8188-imgsys-wpe3
+ - mediatek,mt8188-imgsys1-dip-nr
+ - mediatek,mt8188-imgsys1-dip-top
+ - mediatek,mt8188-imp-iic-wrap-c
+ - mediatek,mt8188-imp-iic-wrap-en
+ - mediatek,mt8188-imp-iic-wrap-w
+ - mediatek,mt8188-ipesys
+ - mediatek,mt8188-mfgcfg
+ - mediatek,mt8188-vdecsys
+ - mediatek,mt8188-vdecsys-soc
+ - mediatek,mt8188-vencsys
+ - mediatek,mt8188-wpesys
+ - mediatek,mt8188-wpesys-vpp0
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8188-camsys-rawa
+ - mediatek,mt8188-camsys-rawb
+ - mediatek,mt8188-camsys-yuva
+ - mediatek,mt8188-camsys-yuvb
+ - mediatek,mt8188-imgsys-wpe1
+ - mediatek,mt8188-imgsys-wpe2
+ - mediatek,mt8188-imgsys-wpe3
+ - mediatek,mt8188-imgsys1-dip-nr
+ - mediatek,mt8188-imgsys1-dip-top
+ - mediatek,mt8188-ipesys
+
+ then:
+ required:
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@11283000 {
+ compatible = "mediatek,mt8188-imp-iic-wrap-c";
+ reg = <0x11283000 0x1000>;
+ #clock-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml
new file mode 100644
index 000000000000..db13d51a4903
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8188-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek System Clock Controller for MT8188
+
+maintainers:
+ - Garmin Chang <garmin.chang@mediatek.com>
+
+description: |
+ The clock architecture in MediaTek like below
+ PLLs -->
+ dividers -->
+ muxes
+ -->
+ clock gate
+
+ The apmixedsys provides most of PLLs which generated from SoC 26m.
+ The topckgen provides dividers and muxes which provide the clock source to other IP blocks.
+ The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks.
+ The mcusys provides mux control to select the clock source in AP MCU.
+ The device nodes also provide the system control capacity for configuration.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8188-apmixedsys
+ - mediatek,mt8188-infracfg-ao
+ - mediatek,mt8188-pericfg-ao
+ - mediatek,mt8188-topckgen
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@10000000 {
+ compatible = "mediatek,mt8188-topckgen", "syscon";
+ reg = <0x10000000 0x1000>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
index b57cc2e69efb..b8d690e28bdc 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,mt8192-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Functional Clock Controller for MT8192
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
index 27f79175c678..bf8c9aacdf1e 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,mt8192-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek System Clock Controller for MT8192
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml
index 17fcbb45d121..fcc963aff087 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-clock.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,mt8195-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Functional Clock Controller for MT8195
@@ -28,11 +28,9 @@ properties:
- mediatek,mt8195-imp_iic_wrap_s
- mediatek,mt8195-imp_iic_wrap_w
- mediatek,mt8195-mfgcfg
- - mediatek,mt8195-vppsys0
- mediatek,mt8195-wpesys
- mediatek,mt8195-wpesys_vpp0
- mediatek,mt8195-wpesys_vpp1
- - mediatek,mt8195-vppsys1
- mediatek,mt8195-imgsys
- mediatek,mt8195-imgsys1_dip_top
- mediatek,mt8195-imgsys1_dip_nr
@@ -93,13 +91,6 @@ examples:
};
- |
- vppsys0: clock-controller@14000000 {
- compatible = "mediatek,mt8195-vppsys0";
- reg = <0x14000000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
wpesys: clock-controller@14e00000 {
compatible = "mediatek,mt8195-wpesys";
reg = <0x14e00000 0x1000>;
@@ -121,13 +112,6 @@ examples:
};
- |
- vppsys1: clock-controller@14f00000 {
- compatible = "mediatek,mt8195-vppsys1";
- reg = <0x14f00000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
imgsys: clock-controller@15000000 {
compatible = "mediatek,mt8195-imgsys";
reg = <0x15000000 0x1000>;
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml
index 95b6bdf99936..69f096eb168d 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,mt8195-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek System Clock Controller for MT8195
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
new file mode 100644
index 000000000000..bfdbd2e4a167
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8196-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Functional Clock Controller for MT8196
+
+maintainers:
+ - Guangjie Song <guangjie.song@mediatek.com>
+ - Laura Nao <laura.nao@collabora.com>
+
+description: |
+ The clock architecture in MediaTek SoCs is structured like below:
+ PLLs -->
+ dividers -->
+ muxes
+ -->
+ clock gate
+
+ The device nodes provide clock gate control in different IP blocks.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8196-imp-iic-wrap-c
+ - mediatek,mt8196-imp-iic-wrap-e
+ - mediatek,mt8196-imp-iic-wrap-n
+ - mediatek,mt8196-imp-iic-wrap-w
+ - mediatek,mt8196-mdpsys0
+ - mediatek,mt8196-mdpsys1
+ - mediatek,mt8196-pericfg-ao
+ - mediatek,mt8196-pextp0cfg-ao
+ - mediatek,mt8196-pextp1cfg-ao
+ - mediatek,mt8196-ufscfg-ao
+ - mediatek,mt8196-vencsys
+ - mediatek,mt8196-vencsys-c1
+ - mediatek,mt8196-vencsys-c2
+ - mediatek,mt8196-vdecsys
+ - mediatek,mt8196-vdecsys-soc
+ - mediatek,mt8196-vdisp-ao
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+ description:
+ Reset lines for PEXTP0/1 and UFS blocks.
+
+ mediatek,hardware-voter:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Phandle to the "Hardware Voter" (HWV), as named in the vendor
+ documentation for MT8196/MT6991.
+
+ The HWV is a SoC-internal fixed-function MCU used to collect votes from
+ both the Application Processor and other remote processors within the SoC.
+ It is intended to transparently enable or disable hardware resources (such
+ as power domains or clocks) based on internal vote aggregation handled by
+ the MCU's internal state machine.
+
+ However, in practice, this design is incomplete. While the HWV performs
+ some internal vote aggregation,software is still required to
+ - Manually enable power supplies externally, if present and if required
+ - Manually enable parent clocks via direct MMIO writes to clock controllers
+ - Enable the FENC after the clock has been ungated via direct MMIO
+ writes to clock controllers
+
+ As such, the HWV behaves more like a hardware-managed clock reference
+ counter than a true voter. Furthermore, it is not a separate
+ controller. It merely serves as an alternative interface to the same
+ underlying clock or power controller. Actual control still requires
+ direct access to the controller's own MMIO register space, in
+ addition to writing to the HWV's MMIO region.
+
+ For this reason, a custom phandle is used here - drivers need to directly
+ access the HWV MMIO region in a syscon-like fashion, due to how the
+ hardware is wired. This differs from true hardware voting systems, which
+ typically do not require custom phandles and rely instead on generic APIs
+ (clocks, power domains, interconnects).
+
+ The name "hardware-voter" is retained to match vendor documentation, but
+ this should not be reused or misunderstood as a proper voting mechanism.
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pericfg_ao: clock-controller@16640000 {
+ compatible = "mediatek,mt8196-pericfg-ao", "syscon";
+ reg = <0x16640000 0x1000>;
+ mediatek,hardware-voter = <&scp_hwv>;
+ #clock-cells = <1>;
+ };
+ - |
+ pextp0cfg_ao: clock-controller@169b0000 {
+ compatible = "mediatek,mt8196-pextp0cfg-ao", "syscon";
+ reg = <0x169b0000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml
new file mode 100644
index 000000000000..660ab64f390d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8196-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek System Clock Controller for MT8196
+
+maintainers:
+ - Guangjie Song <guangjie.song@mediatek.com>
+ - Laura Nao <laura.nao@collabora.com>
+
+description: |
+ The clock architecture in MediaTek SoCs is structured like below:
+ PLLs -->
+ dividers -->
+ muxes
+ -->
+ clock gate
+
+ The apmixedsys, apmixedsys_gp2, vlpckgen, armpll, ccipll, mfgpll and ptppll
+ provide most of the PLLs which are generated from the SoC's 26MHZ crystal oscillator.
+ The topckgen, topckgen_gp2 and vlpckgen provide dividers and muxes which
+ provide the clock source to other IP blocks.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8196-apmixedsys
+ - mediatek,mt8196-armpll-b-pll-ctrl
+ - mediatek,mt8196-armpll-bl-pll-ctrl
+ - mediatek,mt8196-armpll-ll-pll-ctrl
+ - mediatek,mt8196-apmixedsys-gp2
+ - mediatek,mt8196-ccipll-pll-ctrl
+ - mediatek,mt8196-mfgpll-pll-ctrl
+ - mediatek,mt8196-mfgpll-sc0-pll-ctrl
+ - mediatek,mt8196-mfgpll-sc1-pll-ctrl
+ - mediatek,mt8196-ptppll-pll-ctrl
+ - mediatek,mt8196-topckgen
+ - mediatek,mt8196-topckgen-gp2
+ - mediatek,mt8196-vlpckgen
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ mediatek,hardware-voter:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Phandle to the "Hardware Voter" (HWV), as named in the vendor
+ documentation for MT8196/MT6991.
+
+ The HWV is a SoC-internal fixed-function MCU used to collect votes from
+ both the Application Processor and other remote processors within the SoC.
+ It is intended to transparently enable or disable hardware resources (such
+ as power domains or clocks) based on internal vote aggregation handled by
+ the MCU's internal state machine.
+
+ However, in practice, this design is incomplete. While the HWV performs
+ some internal vote aggregation,software is still required to
+ - Manually enable power supplies externally, if present and if required
+ - Manually enable parent clocks via direct MMIO writes to clock controllers
+ - Enable the FENC after the clock has been ungated via direct MMIO
+ writes to clock controllers
+
+ As such, the HWV behaves more like a hardware-managed clock reference
+ counter than a true voter. Furthermore, it is not a separate
+ controller. It merely serves as an alternative interface to the same
+ underlying clock or power controller. Actual control still requires
+ direct access to the controller's own MMIO register space, in
+ addition to writing to the HWV's MMIO region.
+
+ For this reason, a custom phandle is used here - drivers need to directly
+ access the HWV MMIO region in a syscon-like fashion, due to how the
+ hardware is wired. This differs from true hardware voting systems, which
+ typically do not require custom phandles and rely instead on generic APIs
+ (clocks, power domains, interconnects).
+
+ The name "hardware-voter" is retained to match vendor documentation, but
+ this should not be reused or misunderstood as a proper voting mechanism.
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ apmixedsys_clk: syscon@10000800 {
+ compatible = "mediatek,mt8196-apmixedsys", "syscon";
+ reg = <0x10000800 0x1000>;
+ #clock-cells = <1>;
+ };
+ - |
+ topckgen: syscon@10000000 {
+ compatible = "mediatek,mt8196-topckgen", "syscon";
+ reg = <0x10000000 0x800>;
+ mediatek,hardware-voter = <&scp_hwv>;
+ #clock-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8365-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8365-clock.yaml
new file mode 100644
index 000000000000..b327ecb4e524
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8365-clock.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8365-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Functional Clock Controller for MT8365
+
+maintainers:
+ - Markus Schneider-Pargmann <msp@baylibre.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8365-apu
+ - mediatek,mt8365-imgsys
+ - mediatek,mt8365-mfgcfg
+ - mediatek,mt8365-vdecsys
+ - mediatek,mt8365-vencsys
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ apu: clock-controller@19020000 {
+ compatible = "mediatek,mt8365-apu", "syscon";
+ reg = <0x19020000 0x1000>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8365-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8365-sys-clock.yaml
new file mode 100644
index 000000000000..643f84660c8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8365-sys-clock.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8365-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek System Clock Controller for MT8365
+
+maintainers:
+ - Markus Schneider-Pargmann <msp@baylibre.com>
+
+description:
+ The apmixedsys module provides most of PLLs which generated from SoC 26m.
+ The topckgen provides dividers and muxes which provides the clock source to other IP blocks.
+ The infracfg_ao and pericfg_ao provides clock gate in peripheral and infrastructure IP blocks.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8365-topckgen
+ - mediatek,mt8365-infracfg
+ - mediatek,mt8365-apmixedsys
+ - mediatek,mt8365-pericfg
+ - mediatek,mt8365-mcucfg
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ topckgen: clock-controller@10000000 {
+ compatible = "mediatek,mt8365-topckgen", "syscon";
+ reg = <0x10000000 0x1000>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml
new file mode 100644
index 000000000000..56bbd69b16d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mtmips-sysc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTMIPS SoCs System Controller
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ MediaTek MIPS and Ralink SoCs provides a system controller to allow
+ to access to system control registers. These registers include clock
+ and reset related ones so this node is both clock and reset provider
+ for the rest of the world.
+
+ These SoCs have an XTAL from where the cpu clock is
+ provided as well as derived clocks for the bus and the peripherals.
+
+ Each clock is assigned an identifier and client nodes use this identifier
+ to specify the clock which they consume.
+
+ All these identifiers could be found in:
+ [1]: <include/dt-bindings/clock/mediatek,mtmips-sysc.h>.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ralink,mt7620-sysc
+ - ralink,mt7688-sysc
+ - ralink,rt2880-sysc
+ - ralink,rt3050-sysc
+ - ralink,rt3052-sysc
+ - ralink,rt3352-sysc
+ - ralink,rt3883-sysc
+ - ralink,rt5350-sysc
+ - const: syscon
+ - items:
+ - const: ralink,mt7628-sysc
+ - const: ralink,mt7688-sysc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ description:
+ The first cell indicates the clock number, see [1] for available
+ clocks.
+ const: 1
+
+ '#reset-cells':
+ description:
+ The first cell indicates the reset bit within the register.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mediatek,mtmips-sysc.h>
+
+ syscon@0 {
+ compatible = "ralink,rt5350-sysc", "syscon";
+ reg = <0x0 0x100>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/clock/mediatek,pericfg.yaml
index 8585f6f18f69..b98cf45efe2f 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,pericfg.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,pericfg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Peripheral Configuration Controller
@@ -20,13 +20,16 @@ properties:
- enum:
- mediatek,mt2701-pericfg
- mediatek,mt2712-pericfg
+ - mediatek,mt6735-pericfg
- mediatek,mt6765-pericfg
+ - mediatek,mt6795-pericfg
- mediatek,mt7622-pericfg
- mediatek,mt7629-pericfg
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
- mediatek,mt8186-pericfg
+ - mediatek,mt8188-pericfg
- mediatek,mt8195-pericfg
- mediatek,mt8516-pericfg
- const: syscon
diff --git a/Documentation/devicetree/bindings/clock/mediatek,syscon.yaml b/Documentation/devicetree/bindings/clock/mediatek,syscon.yaml
new file mode 100644
index 000000000000..a52f90bfc9f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,syscon.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Clock controller syscon's
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek clock controller syscon's provide various clocks to the system.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt2701-bdpsys
+ - mediatek,mt2701-imgsys
+ - mediatek,mt2701-vdecsys
+ - mediatek,mt2712-bdpsys
+ - mediatek,mt2712-imgsys
+ - mediatek,mt2712-jpgdecsys
+ - mediatek,mt2712-mcucfg
+ - mediatek,mt2712-mfgcfg
+ - mediatek,mt2712-vdecsys
+ - mediatek,mt2712-vencsys
+ - mediatek,mt6735-imgsys
+ - mediatek,mt6735-mfgcfg
+ - mediatek,mt6735-vdecsys
+ - mediatek,mt6735-vencsys
+ - mediatek,mt6765-camsys
+ - mediatek,mt6765-imgsys
+ - mediatek,mt6765-mipi0a
+ - mediatek,mt6765-vcodecsys
+ - mediatek,mt6779-camsys
+ - mediatek,mt6779-imgsys
+ - mediatek,mt6779-ipesys
+ - mediatek,mt6779-mfgcfg
+ - mediatek,mt6779-vdecsys
+ - mediatek,mt6779-vencsys
+ - mediatek,mt6797-imgsys
+ - mediatek,mt6797-vdecsys
+ - mediatek,mt6797-vencsys
+ - mediatek,mt8167-imgsys
+ - mediatek,mt8167-mfgcfg
+ - mediatek,mt8167-vdecsys
+ - mediatek,mt8173-imgsys
+ - mediatek,mt8173-vdecsys
+ - mediatek,mt8173-vencltsys
+ - mediatek,mt8173-vencsys
+ - mediatek,mt8183-camsys
+ - mediatek,mt8183-imgsys
+ - mediatek,mt8183-ipu_conn
+ - mediatek,mt8183-ipu_adl
+ - mediatek,mt8183-ipu_core0
+ - mediatek,mt8183-ipu_core1
+ - mediatek,mt8183-mcucfg
+ - mediatek,mt8183-mfgcfg
+ - mediatek,mt8183-vdecsys
+ - mediatek,mt8183-vencsys
+ - const: syscon
+ - items:
+ - const: mediatek,mt7623-bdpsys
+ - const: mediatek,mt2701-bdpsys
+ - const: syscon
+ - items:
+ - const: mediatek,mt7623-imgsys
+ - const: mediatek,mt2701-imgsys
+ - const: syscon
+ - items:
+ - const: mediatek,mt7623-vdecsys
+ - const: mediatek,mt2701-vdecsys
+ - const: syscon
+
+ power-domains:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#clock-cells'
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8183-mfgcfg
+then:
+ properties:
+ power-domains: true
+else:
+ properties:
+ power-domains: false
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@11220000 {
+ compatible = "mediatek,mt2701-bdpsys", "syscon";
+ reg = <0x11220000 0x2000>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
index 5b8b37a2e594..c080fb0a1618 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Top Clock Generator Controller
@@ -12,7 +12,8 @@ maintainers:
description:
The Mediatek topckgen controller provides various clocks to the system.
- The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
+ The clock values can be found in <dt-bindings/clock/mt*-clk.h> and
+ <dt-bindings/clock/mediatek,mt*-topckgen.h>.
properties:
compatible:
@@ -31,10 +32,15 @@ properties:
- enum:
- mediatek,mt2701-topckgen
- mediatek,mt2712-topckgen
+ - mediatek,mt6735-topckgen
- mediatek,mt6765-topckgen
- mediatek,mt6779-topckgen
+ - mediatek,mt6795-topckgen
- mediatek,mt7629-topckgen
+ - mediatek,mt7981-topckgen
- mediatek,mt7986-topckgen
+ - mediatek,mt7988-mcusys
+ - mediatek,mt7988-topckgen
- mediatek,mt8167-topckgen
- mediatek,mt8183-topckgen
- const: syscon
diff --git a/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml b/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml
index df2bec188706..16106e8b637f 100644
--- a/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml
+++ b/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml
@@ -16,7 +16,18 @@ description: |
properties:
compatible:
- const: microchip,lan966x-gck
+ oneOf:
+ - enum:
+ - microchip,lan966x-gck
+ - microchip,lan9691-gck
+ - items:
+ - enum:
+ - microchip,lan9698-gck
+ - microchip,lan9696-gck
+ - microchip,lan9694-gck
+ - microchip,lan9693-gck
+ - microchip,lan9692-gck
+ - const: microchip,lan9691-gck
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/clock/microchip,mpfs-ccc.yaml b/Documentation/devicetree/bindings/clock/microchip,mpfs-ccc.yaml
new file mode 100644
index 000000000000..f1770360798f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/microchip,mpfs-ccc.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/microchip,mpfs-ccc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC Fabric Clock Conditioning Circuitry
+
+maintainers:
+ - Conor Dooley <conor.dooley@microchip.com>
+
+description: |
+ Microchip PolarFire SoC has 4 Clock Conditioning Circuitry blocks. Each of
+ these blocks contains two PLLs and 2 DLLs & are located in the four corners of
+ the FPGA. For more information see "PolarFire SoC FPGA Clocking Resources" at:
+ https://onlinedocs.microchip.com/pr/GUID-8F0CC4C0-0317-4262-89CA-CE7773ED1931-en-US-1/index.html
+
+properties:
+ compatible:
+ const: microchip,mpfs-ccc
+
+ reg:
+ items:
+ - description: PLL0's control registers
+ - description: PLL1's control registers
+ - description: DLL0's control registers
+ - description: DLL1's control registers
+
+ clocks:
+ description:
+ The CCC PLL's have two input clocks. It is required that even if the input
+ clocks are identical that both are provided.
+ minItems: 2
+ items:
+ - description: PLL0's refclk0
+ - description: PLL0's refclk1
+ - description: PLL1's refclk0
+ - description: PLL1's refclk1
+ - description: DLL0's refclk
+ - description: DLL1's refclk
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: pll0_ref0
+ - const: pll0_ref1
+ - const: pll1_ref0
+ - const: pll1_ref1
+ - const: dll0_ref
+ - const: dll1_ref
+
+ '#clock-cells':
+ const: 1
+ description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell.
+ See include/dt-bindings/clock/microchip,mpfs-clock.h for the full list of
+ PolarFire clock IDs.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@38100000 {
+ compatible = "microchip,mpfs-ccc";
+ reg = <0x38010000 0x1000>, <0x38020000 0x1000>,
+ <0x39010000 0x1000>, <0x39020000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&refclk_ccc>, <&refclk_ccc>, <&refclk_ccc>, <&refclk_ccc>,
+ <&refclk_ccc>, <&refclk_ccc>;
+ clock-names = "pll0_ref0", "pll0_ref1", "pll1_ref0", "pll1_ref1",
+ "dll0_ref", "dll1_ref";
+ };
diff --git a/Documentation/devicetree/bindings/clock/microchip,mpfs-clkcfg.yaml b/Documentation/devicetree/bindings/clock/microchip,mpfs-clkcfg.yaml
new file mode 100644
index 000000000000..ee4f31596d97
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/microchip,mpfs-clkcfg.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/microchip,mpfs-clkcfg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire Clock Control Module
+
+maintainers:
+ - Daire McNamara <daire.mcnamara@microchip.com>
+
+description: |
+ Microchip PolarFire clock control (CLKCFG) is an integrated clock controller,
+ which gates and enables all peripheral clocks.
+
+ This device tree binding describes 33 gate clocks. Clocks are referenced by
+ user nodes by the CLKCFG node phandle and the clock index in the group, from
+ 0 to 32.
+
+properties:
+ compatible:
+ const: microchip,mpfs-clkcfg
+
+ reg:
+ oneOf:
+ - items:
+ - description: |
+ clock config registers:
+ These registers contain enable, reset & divider tables for the, cpu,
+ axi, ahb and rtc/mtimer reference clocks as well as enable and reset
+ for the peripheral clocks.
+ - description: |
+ mss pll dri registers:
+ Block of registers responsible for dynamic reconfiguration of the mss
+ pll
+ deprecated: true
+ - items:
+ - description: |
+ mss pll dri registers:
+ Block of registers responsible for dynamic reconfiguration of the mss
+ pll
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description: |
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell.
+ See include/dt-bindings/clock/microchip,mpfs-clock.h for the full list of
+ PolarFire clock IDs.
+
+ resets:
+ maxItems: 1
+
+ '#reset-cells':
+ description:
+ The AHB/AXI peripherals on the PolarFire SoC have reset support, so from
+ CLK_ENVM to CLK_CFM. The reset consumer should specify the desired
+ peripheral via the clock ID in its "resets" phandle cell.
+ See include/dt-bindings/clock/microchip,mpfs-clock.h for the full list of
+ PolarFire clock IDs.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ # Clock Config node:
+ - |
+ #include <dt-bindings/clock/microchip,mpfs-clock.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ clkcfg: clock-controller@3E001000 {
+ compatible = "microchip,mpfs-clkcfg";
+ reg = <0x3E001000 0x1000>;
+ clocks = <&ref>;
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml
deleted file mode 100644
index 016a4f378b9b..000000000000
--- a/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml
+++ /dev/null
@@ -1,67 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/microchip,mpfs.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip PolarFire Clock Control Module Binding
-
-maintainers:
- - Daire McNamara <daire.mcnamara@microchip.com>
-
-description: |
- Microchip PolarFire clock control (CLKCFG) is an integrated clock controller,
- which gates and enables all peripheral clocks.
-
- This device tree binding describes 33 gate clocks. Clocks are referenced by
- user nodes by the CLKCFG node phandle and the clock index in the group, from
- 0 to 32.
-
-properties:
- compatible:
- const: microchip,mpfs-clkcfg
-
- reg:
- items:
- - description: |
- clock config registers:
- These registers contain enable, reset & divider tables for the, cpu,
- axi, ahb and rtc/mtimer reference clocks as well as enable and reset
- for the peripheral clocks.
- - description: |
- mss pll dri registers:
- Block of registers responsible for dynamic reconfiguration of the mss
- pll
-
- clocks:
- maxItems: 1
-
- '#clock-cells':
- const: 1
- description: |
- The clock consumer should specify the desired clock by having the clock
- ID in its "clocks" phandle cell. See include/dt-bindings/clock/microchip,mpfs-clock.h
- for the full list of PolarFire clock IDs.
-
-required:
- - compatible
- - reg
- - clocks
- - '#clock-cells'
-
-additionalProperties: false
-
-examples:
- # Clock Config node:
- - |
- #include <dt-bindings/clock/microchip,mpfs-clock.h>
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
- clkcfg: clock-controller@20002000 {
- compatible = "microchip,mpfs-clkcfg";
- reg = <0x0 0x20002000 0x0 0x1000>, <0x0 0x3E001000 0x0 0x1000>;
- clocks = <&ref>;
- #clock-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/clock/microchip,pic32.txt b/Documentation/devicetree/bindings/clock/microchip,pic32.txt
deleted file mode 100644
index c93d88fdd858..000000000000
--- a/Documentation/devicetree/bindings/clock/microchip,pic32.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Microchip PIC32 Clock Controller Binding
-----------------------------------------
-Microchip clock controller is consists of few oscillators, PLL, multiplexer
-and few divider modules.
-
-This binding uses common clock bindings.
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible: shall be "microchip,pic32mzda-clk".
-- reg: shall contain base address and length of clock registers.
-- #clock-cells: shall be 1.
-
-Optional properties:
-- microchip,pic32mzda-sosc: shall be added only if platform has
- secondary oscillator connected.
-
-Example:
- rootclk: clock-controller@1f801200 {
- compatible = "microchip,pic32mzda-clk";
- reg = <0x1f801200 0x200>;
- #clock-cells = <1>;
- /* optional */
- microchip,pic32mzda-sosc;
- };
-
-
-The clock consumer shall specify the desired clock-output of the clock
-controller (as defined in [2]) by specifying output-id in its "clock"
-phandle cell.
-[2] include/dt-bindings/clock/microchip,pic32-clock.h
-
-For example for UART2:
-uart2: serial@2 {
- compatible = "microchip,pic32mzda-uart";
- reg = <>;
- interrupts = <>;
- clocks = <&rootclk PB2CLK>;
-};
diff --git a/Documentation/devicetree/bindings/clock/microchip,pic32mzda-clk.yaml b/Documentation/devicetree/bindings/clock/microchip,pic32mzda-clk.yaml
new file mode 100644
index 000000000000..a14a838140f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/microchip,pic32mzda-clk.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/microchip,pic32mzda-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Clock Controller
+
+maintainers:
+ - Purna Chandra Mandal <purna.mandal@microchip.com>
+
+description:
+ Microchip clock controller consists of a few oscillators, PLL, multiplexer
+ and divider modules.
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-clk
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ microchip,pic32mzda-sosc:
+ description: Presence of secondary oscillator.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@1f801200 {
+ compatible = "microchip,pic32mzda-clk";
+ reg = <0x1f801200 0x200>;
+ #clock-cells = <1>;
+ /* optional */
+ microchip,pic32mzda-sosc;
+ };
diff --git a/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml b/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
index 6d39344d2b70..d786f1e2d007 100644
--- a/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/milbeaut-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Milbeaut SoCs Clock Controller Binding
+title: Milbeaut SoCs Clock Controller
maintainers:
- Taichi Sugaya <sugaya.taichi@socionext.com>
@@ -40,38 +40,11 @@ required:
additionalProperties: false
examples:
- # Clock controller node:
- |
- m10v-clk-ctrl@1d021000 {
+ clock-controller@1d021000 {
compatible = "socionext,milbeaut-m10v-ccu";
reg = <0x1d021000 0x4000>;
#clock-cells = <1>;
clocks = <&clki40mhz>;
};
-
- # Required an external clock for Clock controller node:
- - |
- clocks {
- clki40mhz: clki40mhz {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <40000000>;
- };
- /* other clocks */
- };
-
- # The clock consumer shall specify the desired clock-output of the clock
- # controller as below by specifying output-id in its "clk" phandle cell.
- # 2: uart
- # 4: 32-bit timer
- # 7: UHS-I/II
- - |
- serial@1e700010 {
- compatible = "socionext,milbeaut-usio-uart";
- reg = <0x1e700010 0x10>;
- interrupts = <0 141 0x4>, <0 149 0x4>;
- interrupt-names = "rx", "tx";
- clocks = <&clk 2>;
- };
-
...
diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
deleted file mode 100644
index fedea84314a1..000000000000
--- a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Device Tree Clock bindings for arch-moxart
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-MOXA ART SoCs allow to determine PLL output and APB frequencies
-by reading registers holding multiplier and divisor information.
-
-
-PLL:
-
-Required properties:
-- compatible : Must be "moxa,moxart-pll-clock"
-- #clock-cells : Should be 0
-- reg : Should contain registers location and length
-- clocks : Should contain phandle + clock-specifier for the parent clock
-
-Optional properties:
-- clock-output-names : Should contain clock name
-
-
-APB:
-
-Required properties:
-- compatible : Must be "moxa,moxart-apb-clock"
-- #clock-cells : Should be 0
-- reg : Should contain registers location and length
-- clocks : Should contain phandle + clock-specifier for the parent clock
-
-Optional properties:
-- clock-output-names : Should contain clock name
-
-
-For example:
-
- clk_pll: clk_pll@98100000 {
- compatible = "moxa,moxart-pll-clock";
- #clock-cells = <0>;
- reg = <0x98100000 0x34>;
- };
-
- clk_apb: clk_apb@98100000 {
- compatible = "moxa,moxart-apb-clock";
- #clock-cells = <0>;
- reg = <0x98100000 0x34>;
- clocks = <&clk_pll>;
- };
diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.yaml b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.yaml
new file mode 100644
index 000000000000..bcf7cc240eba
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/moxa,moxart-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MOXA ART Clock Controllers
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ MOXA ART SoCs allow to determine PLL output and APB frequencies by reading
+ registers holding multiplier and divisor information.
+
+properties:
+ compatible:
+ enum:
+ - moxa,moxart-apb-clock
+ - moxa,moxart-pll-clock
+
+ "#clock-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-output-names: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#clock-cells"
+ - reg
diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
deleted file mode 100644
index d8f5c490f893..000000000000
--- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-* Core Clock bindings for Marvell MVEBU SoCs
-
-Marvell MVEBU SoCs usually allow to determine core clock frequencies by
-reading the Sample-At-Reset (SAR) register. The core clock consumer should
-specify the desired clock by having the clock ID in its "clocks" phandle cell.
-
-The following is a list of provided IDs and clock names on Armada 370/XP:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU clock)
- 2 = nbclk (L2 Cache clock)
- 3 = hclk (DRAM control clock)
- 4 = dramclk (DDR clock)
-
-The following is a list of provided IDs and clock names on Armada 375:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU clock)
- 2 = l2clk (L2 Cache clock)
- 3 = ddrclk (DDR clock)
-
-The following is a list of provided IDs and clock names on Armada 380/385:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU clock)
- 2 = l2clk (L2 Cache clock)
- 3 = ddrclk (DDR clock)
-
-The following is a list of provided IDs and clock names on Armada 39x:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU clock)
- 2 = nbclk (Coherent Fabric clock)
- 3 = hclk (SDRAM Controller Internal Clock)
- 4 = dclk (SDRAM Interface Clock)
- 5 = refclk (Reference Clock)
-
-The following is a list of provided IDs and clock names on 98dx3236:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU clock)
- 2 = ddrclk (DDR clock)
- 3 = mpll (MPLL Clock)
-
-The following is a list of provided IDs and clock names on Kirkwood and Dove:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU0 clock)
- 2 = l2clk (L2 Cache clock derived from CPU0 clock)
- 3 = ddrclk (DDR controller clock derived from CPU0 clock)
-
-The following is a list of provided IDs and clock names on Orion5x:
- 0 = tclk (Internal Bus clock)
- 1 = cpuclk (CPU0 clock)
- 2 = ddrclk (DDR controller clock derived from CPU0 clock)
-
-Required properties:
-- compatible : shall be one of the following:
- "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
- "marvell,armada-375-core-clock" - For Armada 375 SoC core clocks
- "marvell,armada-380-core-clock" - For Armada 380/385 SoC core clocks
- "marvell,armada-390-core-clock" - For Armada 39x SoC core clocks
- "marvell,armada-xp-core-clock" - For Armada XP SoC core clocks
- "marvell,mv98dx3236-core-clock" - For 98dx3236 family SoC core clocks
- "marvell,dove-core-clock" - for Dove SoC core clocks
- "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
- "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC
- "marvell,mv98dx1135-core-clock" - for Kirkwood 98dx1135 SoC
- "marvell,mv88f5181-core-clock" - for Orion MV88F5181 SoC
- "marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC
- "marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC
- "marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC
-- reg : shall be the register address of the Sample-At-Reset (SAR) register
-- #clock-cells : from common clock binding; shall be set to 1
-
-Optional properties:
-- clock-output-names : from common clock binding; allows overwrite default clock
- output names ("tclk", "cpuclk", "l2clk", "ddrclk")
-
-Example:
-
-core_clk: core-clocks@d0214 {
- compatible = "marvell,dove-core-clock";
- reg = <0xd0214 0x4>;
- #clock-cells = <1>;
-};
-
-spi0: spi@10600 {
- compatible = "marvell,orion-spi";
- /* ... */
- /* get tclk from core clock provider */
- clocks = <&core_clk 0>;
-};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
deleted file mode 100644
index c7b4e3a6b2c6..000000000000
--- a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Core Divider Clock bindings for Marvell MVEBU SoCs
-
-The following is a list of provided IDs and clock names on Armada 370/XP:
- 0 = nand (NAND clock)
-
-Required properties:
-- compatible : must be "marvell,armada-370-corediv-clock",
- "marvell,armada-375-corediv-clock",
- "marvell,armada-380-corediv-clock",
- "marvell,mv98dx3236-corediv-clock",
-
-- reg : must be the register address of Core Divider control register
-- #clock-cells : from common clock binding; shall be set to 1
-- clocks : must be set to the parent's phandle
-
-Example:
-
-corediv_clk: corediv-clocks@18740 {
- compatible = "marvell,armada-370-corediv-clock";
- reg = <0x18740 0xc>;
- #clock-cells = <1>;
- clocks = <&pll>;
-};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
deleted file mode 100644
index 7f28506eaee7..000000000000
--- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Device Tree Clock bindings for cpu clock of Marvell EBU platforms
-
-Required properties:
-- compatible : shall be one of the following:
- "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
- "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
-- reg : Address and length of the clock complex register set, followed
- by address and length of the PMU DFS registers
-- #clock-cells : should be set to 1.
-- clocks : shall be the input parent clock phandle for the clock.
-
-cpuclk: clock-complex@d0018700 {
- #clock-cells = <1>;
- compatible = "marvell,armada-xp-cpu-clock";
- reg = <0xd0018700 0xA0>, <0x1c054 0x10>;
- clocks = <&coreclk 1>;
-}
-
-cpu@0 {
- compatible = "marvell,sheeva-v7";
- reg = <0>;
- clocks = <&cpuclk 0>;
-};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
deleted file mode 100644
index de562da2ae77..000000000000
--- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
+++ /dev/null
@@ -1,205 +0,0 @@
-* Gated Clock bindings for Marvell EBU SoCs
-
-Marvell Armada 370/375/380/385/39x/XP, Dove and Kirkwood allow some
-peripheral clocks to be gated to save some power. The clock consumer
-should specify the desired clock by having the clock ID in its
-"clocks" phandle cell. The clock ID is directly mapped to the
-corresponding clock gating control bit in HW to ease manual clock
-lookup in datasheet.
-
-The following is a list of provided IDs for Armada 370:
-ID Clock Peripheral
------------------------------------
-0 Audio AC97 Cntrl
-1 pex0_en PCIe 0 Clock out
-2 pex1_en PCIe 1 Clock out
-3 ge1 Gigabit Ethernet 1
-4 ge0 Gigabit Ethernet 0
-5 pex0 PCIe Cntrl 0
-9 pex1 PCIe Cntrl 1
-15 sata0 SATA Host 0
-17 sdio SDHCI Host
-23 crypto CESA (crypto engine)
-25 tdm Time Division Mplx
-28 ddr DDR Cntrl
-30 sata1 SATA Host 0
-
-The following is a list of provided IDs for Armada 375:
-ID Clock Peripheral
------------------------------------
-2 mu Management Unit
-3 pp Packet Processor
-4 ptp PTP
-5 pex0 PCIe 0 Clock out
-6 pex1 PCIe 1 Clock out
-8 audio Audio Cntrl
-11 nd_clk Nand Flash Cntrl
-14 sata0_link SATA 0 Link
-15 sata0_core SATA 0 Core
-16 usb3 USB3 Host
-17 sdio SDHCI Host
-18 usb USB Host
-19 gop Gigabit Ethernet MAC
-20 sata1_link SATA 1 Link
-21 sata1_core SATA 1 Core
-22 xor0 XOR DMA 0
-23 xor1 XOR DMA 0
-24 copro Coprocessor
-25 tdm Time Division Mplx
-28 crypto0_enc Cryptographic Unit Port 0 Encryption
-29 crypto0_core Cryptographic Unit Port 0 Core
-30 crypto1_enc Cryptographic Unit Port 1 Encryption
-31 crypto1_core Cryptographic Unit Port 1 Core
-
-The following is a list of provided IDs for Armada 380/385:
-ID Clock Peripheral
------------------------------------
-0 audio Audio
-2 ge2 Gigabit Ethernet 2
-3 ge1 Gigabit Ethernet 1
-4 ge0 Gigabit Ethernet 0
-5 pex1 PCIe 1
-6 pex2 PCIe 2
-7 pex3 PCIe 3
-8 pex0 PCIe 0
-9 usb3h0 USB3 Host 0
-10 usb3h1 USB3 Host 1
-11 usb3d USB3 Device
-13 bm Buffer Management
-14 crypto0z Cryptographic 0 Z
-15 sata0 SATA 0
-16 crypto1z Cryptographic 1 Z
-17 sdio SDIO
-18 usb2 USB 2
-21 crypto1 Cryptographic 1
-22 xor0 XOR 0
-23 crypto0 Cryptographic 0
-25 tdm Time Division Multiplexing
-28 xor1 XOR 1
-30 sata1 SATA 1
-
-The following is a list of provided IDs for Armada 39x:
-ID Clock Peripheral
------------------------------------
-5 pex1 PCIe 1
-6 pex2 PCIe 2
-7 pex3 PCIe 3
-8 pex0 PCIe 0
-9 usb3h0 USB3 Host 0
-10 usb3h1 USB3 Host 1
-15 sata0 SATA 0
-17 sdio SDIO
-22 xor0 XOR 0
-28 xor1 XOR 1
-
-The following is a list of provided IDs for Armada XP:
-ID Clock Peripheral
------------------------------------
-0 audio Audio Cntrl
-1 ge3 Gigabit Ethernet 3
-2 ge2 Gigabit Ethernet 2
-3 ge1 Gigabit Ethernet 1
-4 ge0 Gigabit Ethernet 0
-5 pex0 PCIe Cntrl 0
-6 pex1 PCIe Cntrl 1
-7 pex2 PCIe Cntrl 2
-8 pex3 PCIe Cntrl 3
-13 bp
-14 sata0lnk
-15 sata0 SATA Host 0
-16 lcd LCD Cntrl
-17 sdio SDHCI Host
-18 usb0 USB Host 0
-19 usb1 USB Host 1
-20 usb2 USB Host 2
-22 xor0 XOR DMA 0
-23 crypto CESA engine
-25 tdm Time Division Mplx
-28 xor1 XOR DMA 1
-29 sata1lnk
-30 sata1 SATA Host 1
-
-The following is a list of provided IDs for 98dx3236:
-ID Clock Peripheral
------------------------------------
-3 ge1 Gigabit Ethernet 1
-4 ge0 Gigabit Ethernet 0
-5 pex0 PCIe Cntrl 0
-17 sdio SDHCI Host
-18 usb0 USB Host 0
-22 xor0 XOR DMA 0
-
-The following is a list of provided IDs for Dove:
-ID Clock Peripheral
------------------------------------
-0 usb0 USB Host 0
-1 usb1 USB Host 1
-2 ge Gigabit Ethernet
-3 sata SATA Host
-4 pex0 PCIe Cntrl 0
-5 pex1 PCIe Cntrl 1
-8 sdio0 SDHCI Host 0
-9 sdio1 SDHCI Host 1
-10 nand NAND Cntrl
-11 camera Camera Cntrl
-12 i2s0 I2S Cntrl 0
-13 i2s1 I2S Cntrl 1
-15 crypto CESA engine
-21 ac97 AC97 Cntrl
-22 pdma Peripheral DMA
-23 xor0 XOR DMA 0
-24 xor1 XOR DMA 1
-30 gephy Gigabit Ethernel PHY
-Note: gephy(30) is implemented as a parent clock of ge(2)
-
-The following is a list of provided IDs for Kirkwood:
-ID Clock Peripheral
------------------------------------
-0 ge0 Gigabit Ethernet 0
-2 pex0 PCIe Cntrl 0
-3 usb0 USB Host 0
-4 sdio SDIO Cntrl
-5 tsu Transp. Stream Unit
-6 dunit SDRAM Cntrl
-7 runit Runit
-8 xor0 XOR DMA 0
-9 audio I2S Cntrl 0
-14 sata0 SATA Host 0
-15 sata1 SATA Host 1
-16 xor1 XOR DMA 1
-17 crypto CESA engine
-18 pex1 PCIe Cntrl 1
-19 ge1 Gigabit Ethernet 1
-20 tdm Time Division Mplx
-
-Required properties:
-- compatible : shall be one of the following:
- "marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
- "marvell,armada-375-gating-clock" - for Armada 375 SoC clock gating
- "marvell,armada-380-gating-clock" - for Armada 380/385 SoC clock gating
- "marvell,armada-390-gating-clock" - for Armada 39x SoC clock gating
- "marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
- "marvell,mv98dx3236-gating-clock" - for 98dx3236 SoC clock gating
- "marvell,dove-gating-clock" - for Dove SoC clock gating
- "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
-- reg : shall be the register address of the Clock Gating Control register
-- #clock-cells : from common clock binding; shall be set to 1
-
-Optional properties:
-- clocks : default parent clock phandle (e.g. tclk)
-
-Example:
-
-gate_clk: clock-gating-control@d0038 {
- compatible = "marvell,dove-gating-clock";
- reg = <0xd0038 0x4>;
- /* default parent clock is tclk */
- clocks = <&core_clk 0>;
- #clock-cells = <1>;
-};
-
-sdio0: sdio@92000 {
- compatible = "marvell,dove-sdhci";
- /* get clk gate bit 8 (sdio0) */
- clocks = <&gate_clk 8>;
-};
diff --git a/Documentation/devicetree/bindings/clock/nspire-clock.txt b/Documentation/devicetree/bindings/clock/nspire-clock.txt
deleted file mode 100644
index 7c3bc8bb5b9f..000000000000
--- a/Documentation/devicetree/bindings/clock/nspire-clock.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-TI-NSPIRE Clocks
-
-Required properties:
-- compatible: Valid compatible properties include:
- "lsi,nspire-cx-ahb-divider" for the AHB divider in the CX model
- "lsi,nspire-classic-ahb-divider" for the AHB divider in the older model
- "lsi,nspire-cx-clock" for the base clock in the CX model
- "lsi,nspire-classic-clock" for the base clock in the older model
-
-- reg: Physical base address of the controller and length of memory mapped
- region.
-
-Optional:
-- clocks: For the "nspire-*-ahb-divider" compatible clocks, this is the parent
- clock where it divides the rate from.
-
-Example:
-
-ahb_clk {
- #clock-cells = <0>;
- compatible = "lsi,nspire-cx-clock";
- reg = <0x900B0000 0x4>;
- clocks = <&base_clk>;
-};
diff --git a/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml
new file mode 100644
index 000000000000..8f0c43683729
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nuvoton,ma35d1-clk.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nuvoton,ma35d1-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Clock Controller Module
+
+maintainers:
+ - Chi-Fang Li <cfli0@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+description: |
+ The MA35D1 clock controller generates clocks for the whole chip,
+ including system clocks and all peripheral clocks.
+
+ See also:
+ include/dt-bindings/clock/ma35d1-clk.h
+
+properties:
+ compatible:
+ items:
+ - const: nuvoton,ma35d1-clk
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ nuvoton,pll-mode:
+ description:
+ A list of PLL operation mode corresponding to CAPLL, DDRPLL, APLL,
+ EPLL, and VPLL in sequential.
+ maxItems: 5
+ items:
+ enum:
+ - integer
+ - fractional
+ - spread-spectrum
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+
+ clock-controller@40460200 {
+ compatible = "nuvoton,ma35d1-clk";
+ reg = <0x40460200 0x100>;
+ #clock-cells = <1>;
+ clocks = <&clk_hxt>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt b/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt
deleted file mode 100644
index f82064546d11..000000000000
--- a/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-* Nuvoton NPCM7XX Clock Controller
-
-Nuvoton Poleg BMC NPCM7XX contains an integrated clock controller, which
-generates and supplies clocks to all modules within the BMC.
-
-External clocks:
-
-There are six fixed clocks that are generated outside the BMC. All clocks are of
-a known fixed value that cannot be changed. clk_refclk, clk_mcbypck and
-clk_sysbypck are inputs to the clock controller.
-clk_rg1refck, clk_rg2refck and clk_xin are external clocks suppling the
-network. They are set on the device tree, but not used by the clock module. The
-network devices use them directly.
-Example can be found below.
-
-All available clocks are defined as preprocessor macros in:
-dt-bindings/clock/nuvoton,npcm7xx-clock.h
-and can be reused as DT sources.
-
-Required Properties of clock controller:
-
- - compatible: "nuvoton,npcm750-clk" : for clock controller of Nuvoton
- Poleg BMC NPCM750
-
- - reg: physical base address of the clock controller and length of
- memory mapped region.
-
- - #clock-cells: should be 1.
-
-Example: Clock controller node:
-
- clk: clock-controller@f0801000 {
- compatible = "nuvoton,npcm750-clk";
- #clock-cells = <1>;
- reg = <0xf0801000 0x1000>;
- clock-names = "refclk", "sysbypck", "mcbypck";
- clocks = <&clk_refclk>, <&clk_sysbypck>, <&clk_mcbypck>;
- };
-
-Example: Required external clocks for network:
-
- /* external reference clock */
- clk_refclk: clk-refclk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <25000000>;
- clock-output-names = "refclk";
- };
-
- /* external reference clock for cpu. float in normal operation */
- clk_sysbypck: clk-sysbypck {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <800000000>;
- clock-output-names = "sysbypck";
- };
-
- /* external reference clock for MC. float in normal operation */
- clk_mcbypck: clk-mcbypck {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <800000000>;
- clock-output-names = "mcbypck";
- };
-
- /* external clock signal rg1refck, supplied by the phy */
- clk_rg1refck: clk-rg1refck {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <125000000>;
- clock-output-names = "clk_rg1refck";
- };
-
- /* external clock signal rg2refck, supplied by the phy */
- clk_rg2refck: clk-rg2refck {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <125000000>;
- clock-output-names = "clk_rg2refck";
- };
-
- clk_xin: clk-xin {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <50000000>;
- clock-output-names = "clk_xin";
- };
-
-
-Example: GMAC controller node that consumes two clocks: a generated clk by the
-clock controller and a fixed clock from DT (clk_rg1refck).
-
- ethernet0: ethernet@f0802000 {
- compatible = "snps,dwmac";
- reg = <0xf0802000 0x2000>;
- interrupts = <0 14 4>;
- interrupt-names = "macirq";
- clocks = <&clk_rg1refck>, <&clk NPCM7XX_CLK_AHB>;
- clock-names = "stmmaceth", "clk_gmac";
- };
diff --git a/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.yaml
new file mode 100644
index 000000000000..694dac68619c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nuvoton,npcm750-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM7XX Clock Controller
+
+maintainers:
+ - Tali Perry <tali.perry1@gmail.com>
+
+description: >
+ Nuvoton Poleg BMC NPCM7XX contains an integrated clock controller, which
+ generates and supplies clocks to all modules within the BMC.
+
+ External clocks:
+
+ There are six fixed clocks that are generated outside the BMC. All clocks are of
+ a known fixed value that cannot be changed. clk_refclk, clk_mcbypck and
+ clk_sysbypck are inputs to the clock controller.
+ clk_rg1refck, clk_rg2refck and clk_xin are external clocks suppling the
+ network. They are set on the device tree, but not used by the clock module. The
+ network devices use them directly.
+
+ All available clocks are defined as preprocessor macros in:
+ dt-bindings/clock/nuvoton,npcm7xx-clock.h
+ and can be reused as DT sources.
+
+properties:
+ compatible:
+ const: nuvoton,npcm750-clk
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clock-names:
+ items:
+ - const: refclk
+ - const: sysbypck
+ - const: mcbypck
+
+ clocks:
+ items:
+ - description: refclk
+ - description: sysbypck
+ - description: mcbypck
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@f0801000 {
+ compatible = "nuvoton,npcm750-clk";
+ #clock-cells = <1>;
+ reg = <0xf0801000 0x1000>;
+ clock-names = "refclk", "sysbypck", "mcbypck";
+ clocks = <&clk_refclk>, <&clk_sysbypck>, <&clk_mcbypck>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml b/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml
index 771db2ddf026..b901ca13cd25 100644
--- a/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/nuvoton,npcm845-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Nuvoton NPCM8XX Clock Controller Binding
+title: Nuvoton NPCM8XX Clock Controller
maintainers:
- Tomer Maimon <tmaimon77@gmail.com>
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml
index 1b2181f6d440..13bb616249a1 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml
@@ -27,7 +27,9 @@ description: |
properties:
compatible:
- const: nvidia,tegra124-car
+ enum:
+ - nvidia,tegra124-car
+ - nvidia,tegra132-car
reg:
maxItems: 1
@@ -35,7 +37,7 @@ properties:
'#clock-cells':
const: 1
- "#reset-cells":
+ '#reset-cells':
const: 1
nvidia,external-memory-controller:
@@ -44,7 +46,7 @@ properties:
phandle of the external memory controller node
patternProperties:
- "^emc-timings-[0-9]+$":
+ '^emc-timings-[0-9]+$':
type: object
properties:
nvidia,ram-code:
@@ -54,7 +56,7 @@ patternProperties:
this timing set is used for
patternProperties:
- "^timing-[0-9]+$":
+ '^timing-[0-9]+$':
type: object
properties:
clock-frequency:
@@ -92,7 +94,7 @@ required:
- compatible
- reg
- '#clock-cells'
- - "#reset-cells"
+ - '#reset-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
index 958e0ad78c52..f7d347385b57 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
@@ -136,7 +136,7 @@ clock@70110000 {
};
/* pinmux nodes added for completeness. Binding doc can be found in:
- * Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt
+ * Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
*/
pinmux: pinmux@700008d4 {
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml
index bee2dd4b29bf..73cccc0df424 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml
@@ -39,11 +39,11 @@ properties:
'#clock-cells':
const: 1
- "#reset-cells":
+ '#reset-cells':
const: 1
patternProperties:
- "^(sclk)|(pll-[cem])$":
+ '^(sclk)|(pll-[cem])$':
type: object
properties:
compatible:
@@ -76,7 +76,7 @@ required:
- compatible
- reg
- '#clock-cells'
- - "#reset-cells"
+ - '#reset-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
new file mode 100644
index 000000000000..27403b4c52d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-blk-ctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 Block Control
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nxp,imx94-display-csr
+ - nxp,imx94-lvds-csr
+ - nxp,imx95-camera-csr
+ - nxp,imx95-display-csr
+ - nxp,imx95-hsio-blk-ctl
+ - nxp,imx95-lvds-csr
+ - nxp,imx95-netcmix-blk-ctrl
+ - nxp,imx95-vpu-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - power-domains
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-vpu-csr", "syscon";
+ reg = <0x4c410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 114>;
+ power-domains = <&scmi_devpd 21>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
new file mode 100644
index 000000000000..07f7412e7658
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-display-master-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 Display Master Block Control
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,imx95-display-master-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+ mux-controller:
+ type: object
+ $ref: /schemas/mux/reg-mux.yaml
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - mux-controller
+ - power-domains
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-display-master-csr", "syscon";
+ reg = <0x4c410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 62>;
+ power-domains = <&scmi_devpd 3>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x4 0x00000001>; /* Pixel_link_sel */
+ idle-states = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/nxp,lpc1850-ccu.yaml b/Documentation/devicetree/bindings/clock/nxp,lpc1850-ccu.yaml
new file mode 100644
index 000000000000..5459038cc954
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,lpc1850-ccu.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,lpc1850-ccu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1850 Clock Control Unit (CCU)
+
+description:
+ Each CGU base clock has several clock branches which can be turned on
+ or off independently by the Clock Control Units CCU1 or CCU2. The
+ branch clocks are distributed between CCU1 and CCU2.
+
+ Above text taken from NXP LPC1850 User Manual
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-ccu
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 8
+
+ clock-names:
+ minItems: 1
+ maxItems: 8
+ items:
+ enum:
+ - base_usb0_clk
+ - base_periph_clk
+ - base_usb1_clk
+ - base_cpu_clk
+ - base_spifi_clk
+ - base_spi_clk
+ - base_apb1_clk
+ - base_apb3_clk
+ - base_adchs_clk
+ - base_sdio_clk
+ - base_ssp0_clk
+ - base_ssp1_clk
+ - base_uart0_clk
+ - base_uart1_clk
+ - base_uart2_clk
+ - base_uart3_clk
+ - base_audio_clk
+ description:
+ Which branch clocks that are available on the CCU depends on the
+ specific LPC part. Check the user manual for your specific part.
+
+ A list of CCU clocks can be found in dt-bindings/clock/lpc18xx-ccu.h.
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-cgu.h>
+
+ clock-controller@40051000 {
+ compatible = "nxp,lpc1850-ccu";
+ reg = <0x40051000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&cgu BASE_APB3_CLK>, <&cgu BASE_APB1_CLK>,
+ <&cgu BASE_SPIFI_CLK>, <&cgu BASE_CPU_CLK>,
+ <&cgu BASE_PERIPH_CLK>, <&cgu BASE_USB0_CLK>,
+ <&cgu BASE_USB1_CLK>, <&cgu BASE_SPI_CLK>;
+ clock-names = "base_apb3_clk", "base_apb1_clk",
+ "base_spifi_clk", "base_cpu_clk",
+ "base_periph_clk", "base_usb0_clk",
+ "base_usb1_clk", "base_spi_clk";
+ };
+
+ - |
+ #include <dt-bindings/clock/lpc18xx-cgu.h>
+
+ clock-controller@40052000 {
+ compatible = "nxp,lpc1850-ccu";
+ reg = <0x40052000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&cgu BASE_AUDIO_CLK>, <&cgu BASE_UART3_CLK>,
+ <&cgu BASE_UART2_CLK>, <&cgu BASE_UART1_CLK>,
+ <&cgu BASE_UART0_CLK>, <&cgu BASE_SSP1_CLK>,
+ <&cgu BASE_SSP0_CLK>, <&cgu BASE_SDIO_CLK>;
+ clock-names = "base_audio_clk", "base_uart3_clk",
+ "base_uart2_clk", "base_uart1_clk",
+ "base_uart0_clk", "base_ssp1_clk",
+ "base_ssp0_clk", "base_sdio_clk";
+ };
+
diff --git a/Documentation/devicetree/bindings/clock/nxp,lpc1850-cgu.yaml b/Documentation/devicetree/bindings/clock/nxp,lpc1850-cgu.yaml
new file mode 100644
index 000000000000..ed178c7df00c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,lpc1850-cgu.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,lpc1850-cgu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1850 Clock Generation Unit (CGU)
+
+description: >
+ The CGU generates multiple independent clocks for the core and the
+ peripheral blocks of the LPC18xx. Each independent clock is called
+ a base clock and itself is one of the inputs to the two Clock
+ Control Units (CCUs) which control the branch clocks to the
+ individual peripherals.
+
+ The CGU selects the inputs to the clock generators from multiple
+ clock sources, controls the clock generation, and routes the outputs
+ of the clock generators through the clock source bus to the output
+ stages. Each output stage provides an independent clock source and
+ corresponds to one of the base clocks for the LPC18xx.
+
+ Above text taken from NXP LPC1850 User Manual.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-cgu
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description: |
+ Which base clocks that are available on the CGU depends on the
+ specific LPC part. Base clocks are numbered from 0 to 27.
+
+ Number: Name: Description:
+ 0 BASE_SAFE_CLK Base safe clock (always on) for WWDT
+ 1 BASE_USB0_CLK Base clock for USB0
+ 2 BASE_PERIPH_CLK Base clock for Cortex-M0SUB subsystem,
+ SPI, and SGPIO
+ 3 BASE_USB1_CLK Base clock for USB1
+ 4 BASE_CPU_CLK System base clock for ARM Cortex-M core
+ and APB peripheral blocks #0 and #2
+ 5 BASE_SPIFI_CLK Base clock for SPIFI
+ 6 BASE_SPI_CLK Base clock for SPI
+ 7 BASE_PHY_RX_CLK Base clock for Ethernet PHY Receive clock
+ 8 BASE_PHY_TX_CLK Base clock for Ethernet PHY Transmit clock
+ 9 BASE_APB1_CLK Base clock for APB peripheral block # 1
+ 10 BASE_APB3_CLK Base clock for APB peripheral block # 3
+ 11 BASE_LCD_CLK Base clock for LCD
+ 12 BASE_ADCHS_CLK Base clock for ADCHS
+ 13 BASE_SDIO_CLK Base clock for SD/MMC
+ 14 BASE_SSP0_CLK Base clock for SSP0
+ 15 BASE_SSP1_CLK Base clock for SSP1
+ 16 BASE_UART0_CLK Base clock for UART0
+ 17 BASE_UART1_CLK Base clock for UART1
+ 18 BASE_UART2_CLK Base clock for UART2
+ 19 BASE_UART3_CLK Base clock for UART3
+ 20 BASE_OUT_CLK Base clock for CLKOUT pin
+ 24-21 - Reserved
+ 25 BASE_AUDIO_CLK Base clock for audio system (I2S)
+ 26 BASE_CGU_OUT0_CLK Base clock for CGU_OUT0 clock output
+ 27 BASE_CGU_OUT1_CLK Base clock for CGU_OUT1 clock output
+
+ BASE_PERIPH_CLK and BASE_SPI_CLK is only available on LPC43xx.
+ BASE_ADCHS_CLK is only available on LPC4370.
+
+ clocks:
+ maxItems: 5
+
+ clock-indices:
+ minItems: 1
+ maxItems: 28
+
+ clock-output-names:
+ minItems: 1
+ maxItems: 28
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@40050000 {
+ compatible = "nxp,lpc1850-cgu";
+ reg = <0x40050000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&xtal>, <&creg_clk 1>, <&enet_rx_clk>, <&enet_tx_clk>, <&gp_clkin>;
+ };
+
diff --git a/Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.txt b/Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.txt
deleted file mode 100644
index 20cbca3f41d8..000000000000
--- a/Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-NXP LPC32xx Clock Controller
-
-Required properties:
-- compatible: should be "nxp,lpc3220-clk"
-- reg: should contain clock controller registers location and length
-- #clock-cells: must be 1, the cell holds id of a clock provided by the
- clock controller
-- clocks: phandles of external oscillators, the list must contain one
- 32768 Hz oscillator and may have one optional high frequency oscillator
-- clock-names: list of external oscillator clock names, must contain
- "xtal_32k" and may have optional "xtal"
-
-Examples:
-
- /* System Control Block */
- scb {
- compatible = "simple-bus";
- ranges = <0x0 0x040004000 0x00001000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- clk: clock-controller@0 {
- compatible = "nxp,lpc3220-clk";
- reg = <0x00 0x114>;
- #clock-cells = <1>;
-
- clocks = <&xtal_32k>, <&xtal>;
- clock-names = "xtal_32k", "xtal";
- };
- };
diff --git a/Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.yaml b/Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.yaml
new file mode 100644
index 000000000000..16f79616d18a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,lpc3220-clk.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,lpc3220-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx Clock Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: nxp,lpc3220-clk
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: External 32768 Hz oscillator.
+ - description: Optional high frequency oscillator.
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: xtal_32k
+ - const: xtal
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@0 {
+ compatible = "nxp,lpc3220-clk";
+ reg = <0x00 0x114>;
+ #clock-cells = <1>;
+ clocks = <&xtal_32k>, <&xtal>;
+ clock-names = "xtal_32k", "xtal";
+ };
diff --git a/Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.txt b/Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.txt
deleted file mode 100644
index 0aa249409b51..000000000000
--- a/Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-NXP LPC32xx USB Clock Controller
-
-Required properties:
-- compatible: should be "nxp,lpc3220-usb-clk"
-- reg: should contain clock controller registers location and length
-- #clock-cells: must be 1, the cell holds id of a clock provided by the
- USB clock controller
-
-Examples:
-
- usb {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "simple-bus";
- ranges = <0x0 0x31020000 0x00001000>;
-
- usbclk: clock-controller@f00 {
- compatible = "nxp,lpc3220-usb-clk";
- reg = <0xf00 0x100>;
- #clock-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.yaml b/Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.yaml
new file mode 100644
index 000000000000..10361d2292fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,lpc3220-usb-clk.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,lpc3220-usb-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx USB Clock Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: nxp,lpc3220-usb-clk
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@f00 {
+ compatible = "nxp,lpc3220-usb-clk";
+ reg = <0xf00 0x100>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt b/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
deleted file mode 100644
index b652f3fb7796..000000000000
--- a/Documentation/devicetree/bindings/clock/oxnas,stdclk.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Oxford Semiconductor OXNAS SoC Family Standard Clocks
-================================================
-
-Please also refer to clock-bindings.txt in this directory for common clock
-bindings usage.
-
-Required properties:
-- compatible: For OX810SE, should be "oxsemi,ox810se-stdclk"
- For OX820, should be "oxsemi,ox820-stdclk"
-- #clock-cells: 1, see below
-
-Parent node should have the following properties :
-- compatible: For OX810SE, should be
- "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
- For OX820, should be
- "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-
-example:
-
-sys: sys-ctrl@000000 {
- compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
- reg = <0x000000 0x100000>;
-
- stdclk: stdclk {
- compatible = "oxsemi,ox810se-stdclk";
- #clock-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/pistachio-clock.txt b/Documentation/devicetree/bindings/clock/pistachio-clock.txt
deleted file mode 100644
index 868db499eed2..000000000000
--- a/Documentation/devicetree/bindings/clock/pistachio-clock.txt
+++ /dev/null
@@ -1,123 +0,0 @@
-Imagination Technologies Pistachio SoC clock controllers
-========================================================
-
-Pistachio has four clock controllers (core clock, peripheral clock, peripheral
-general control, and top general control) which are instantiated individually
-from the device-tree.
-
-External clocks:
-----------------
-
-There are three external inputs to the clock controllers which should be
-defined with the following clock-output-names:
-- "xtal": External 52Mhz oscillator (required)
-- "audio_clk_in": Alternate audio reference clock (optional)
-- "enet_clk_in": Alternate ethernet PHY clock (optional)
-
-Core clock controller:
-----------------------
-
-The core clock controller generates clocks for the CPU, RPU (WiFi + BT
-co-processor), audio, and several peripherals.
-
-Required properties:
-- compatible: Must be "img,pistachio-clk".
-- reg: Must contain the base address and length of the core clock controller.
-- #clock-cells: Must be 1. The single cell is the clock identifier.
- See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
-- clocks: Must contain an entry for each clock in clock-names.
-- clock-names: Must include "xtal" (see "External clocks") and
- "audio_clk_in_gate", "enet_clk_in_gate" which are generated by the
- top-level general control.
-
-Example:
- clk_core: clock-controller@18144000 {
- compatible = "img,pistachio-clk";
- reg = <0x18144000 0x800>;
- clocks = <&xtal>, <&cr_top EXT_CLK_AUDIO_IN>,
- <&cr_top EXT_CLK_ENET_IN>;
- clock-names = "xtal", "audio_clk_in_gate", "enet_clk_in_gate";
-
- #clock-cells = <1>;
- };
-
-Peripheral clock controller:
-----------------------------
-
-The peripheral clock controller generates clocks for the DDR, ROM, and other
-peripherals. The peripheral system clock ("periph_sys") generated by the core
-clock controller is the input clock to the peripheral clock controller.
-
-Required properties:
-- compatible: Must be "img,pistachio-periph-clk".
-- reg: Must contain the base address and length of the peripheral clock
- controller.
-- #clock-cells: Must be 1. The single cell is the clock identifier.
- See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
-- clocks: Must contain an entry for each clock in clock-names.
-- clock-names: Must include "periph_sys", the peripheral system clock generated
- by the core clock controller.
-
-Example:
- clk_periph: clock-controller@18144800 {
- compatible = "img,pistachio-clk-periph";
- reg = <0x18144800 0x800>;
- clocks = <&clk_core CLK_PERIPH_SYS>;
- clock-names = "periph_sys";
-
- #clock-cells = <1>;
- };
-
-Peripheral general control:
----------------------------
-
-The peripheral general control block generates system interface clocks and
-resets for various peripherals. It also contains miscellaneous peripheral
-control registers. The system clock ("sys") generated by the peripheral clock
-controller is the input clock to the system clock controller.
-
-Required properties:
-- compatible: Must include "img,pistachio-periph-cr" and "syscon".
-- reg: Must contain the base address and length of the peripheral general
- control registers.
-- #clock-cells: Must be 1. The single cell is the clock identifier.
- See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
-- clocks: Must contain an entry for each clock in clock-names.
-- clock-names: Must include "sys", the system clock generated by the peripheral
- clock controller.
-
-Example:
- cr_periph: syscon@18144800 {
- compatible = "img,pistachio-cr-periph", "syscon";
- reg = <0x18148000 0x1000>;
- clocks = <&clock_periph PERIPH_CLK_PERIPH_SYS>;
- clock-names = "sys";
-
- #clock-cells = <1>;
- };
-
-Top-level general control:
---------------------------
-
-The top-level general control block contains miscellaneous control registers and
-gates for the external clocks "audio_clk_in" and "enet_clk_in".
-
-Required properties:
-- compatible: Must include "img,pistachio-cr-top" and "syscon".
-- reg: Must contain the base address and length of the top-level
- control registers.
-- clocks: Must contain an entry for each clock in clock-names.
-- clock-names: Two optional clocks, "audio_clk_in" and "enet_clk_in" (see
- "External clocks").
-- #clock-cells: Must be 1. The single cell is the clock identifier.
- See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
-
-Example:
- cr_top: syscon@18144800 {
- compatible = "img,pistachio-cr-top", "syscon";
- reg = <0x18149000 0x200>;
- clocks = <&audio_refclk>, <&ext_enet_in>;
- clock-names = "audio_clk_in", "enet_clk_in";
-
- #clock-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/pwm-clock.txt b/Documentation/devicetree/bindings/clock/pwm-clock.txt
deleted file mode 100644
index 83db876b3b90..000000000000
--- a/Documentation/devicetree/bindings/clock/pwm-clock.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Binding for an external clock signal driven by a PWM pin.
-
-This binding uses the common clock binding[1] and the common PWM binding[2].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/pwm/pwm.txt
-
-Required properties:
-- compatible : shall be "pwm-clock".
-- #clock-cells : from common clock binding; shall be set to 0.
-- pwms : from common PWM binding; this determines the clock frequency
- via the period given in the PWM specifier.
-
-Optional properties:
-- clock-output-names : From common clock binding.
-- clock-frequency : Exact output frequency, in case the PWM period
- is not exact but was rounded to nanoseconds.
-
-Example:
- clock {
- compatible = "pwm-clock";
- #clock-cells = <0>;
- clock-frequency = <25000000>;
- clock-output-names = "mipi_mclk";
- pwms = <&pwm2 0 40>; /* 1 / 40 ns = 25 MHz */
- };
diff --git a/Documentation/devicetree/bindings/clock/pwm-clock.yaml b/Documentation/devicetree/bindings/clock/pwm-clock.yaml
new file mode 100644
index 000000000000..f88ecb2995e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/pwm-clock.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/pwm-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: An external clock signal driven by a PWM pin.
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+properties:
+ compatible:
+ const: pwm-clock
+
+ '#clock-cells':
+ const: 0
+
+ clock-frequency:
+ description: Exact output frequency, in case the PWM period is not exact
+ but was rounded to nanoseconds.
+
+ clock-output-names:
+ maxItems: 1
+
+ pwms:
+ maxItems: 1
+
+required:
+ - compatible
+ - '#clock-cells'
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ clock {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ clock-output-names = "mipi_mclk";
+ pwms = <&pwm2 0 40>; /* 1 / 40 ns = 25 MHz */
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qca,ath79-pll.txt b/Documentation/devicetree/bindings/clock/qca,ath79-pll.txt
deleted file mode 100644
index 241fb0545b9e..000000000000
--- a/Documentation/devicetree/bindings/clock/qca,ath79-pll.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Binding for Qualcomm Atheros AR7xxx/AR9XXX PLL controller
-
-The PPL controller provides the 3 main clocks of the SoC: CPU, DDR and AHB.
-
-Required Properties:
-- compatible: has to be "qca,<soctype>-pll" and one of the following
- fallbacks:
- - "qca,ar7100-pll"
- - "qca,ar7240-pll"
- - "qca,ar9130-pll"
- - "qca,ar9330-pll"
- - "qca,ar9340-pll"
- - "qca,qca9550-pll"
-- reg: Base address and size of the controllers memory area
-- clock-names: Name of the input clock, has to be "ref"
-- clocks: phandle of the external reference clock
-- #clock-cells: has to be one
-
-Optional properties:
-- clock-output-names: should be "cpu", "ddr", "ahb"
-
-Example:
-
- pll-controller@18050000 {
- compatible = "qca,ar9132-pll", "qca,ar9130-pll";
- reg = <0x18050000 0x20>;
-
- clock-names = "ref";
- clocks = <&extosc>;
-
- #clock-cells = <1>;
- clock-output-names = "cpu", "ddr", "ahb";
- };
diff --git a/Documentation/devicetree/bindings/clock/qca,ath79-pll.yaml b/Documentation/devicetree/bindings/clock/qca,ath79-pll.yaml
new file mode 100644
index 000000000000..69863e8a4648
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qca,ath79-pll.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qca,ath79-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros ATH79 PLL controller
+
+maintainers:
+ - Alban Bedel <albeu@free.fr>
+ - Antony Pavlov <antonynpavlov@gmail.com>
+
+description: >
+ The PLL controller provides the 3 main clocks of the SoC: CPU, DDR and AHB.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qca,ar9132-pll
+ - const: qca,ar9130-pll
+ - items:
+ - enum:
+ - qca,ar7100-pll
+ - qca,ar7240-pll
+ - qca,ar9130-pll
+ - qca,ar9330-pll
+ - qca,ar9340-pll
+ - qca,qca9530-pll
+ - qca,qca9550-pll
+ - qca,qca9560-pll
+
+ reg:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clock-output-names:
+ items:
+ - const: cpu
+ - const: ddr
+ - const: ahb
+
+required:
+ - compatible
+ - reg
+ - clock-names
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@18050000 {
+ compatible = "qca,ar9132-pll", "qca,ar9130-pll";
+ reg = <0x18050000 0x20>;
+ clock-names = "ref";
+ clocks = <&extosc>;
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "ddr", "ahb";
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
index fbd758470b88..47ceab641a4c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/clock/qcom,a53pll.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm A53 PLL Binding
+title: Qualcomm A53 PLL clock
maintainers:
- - Sivaprakash Murugesan <sivaprak@codeaurora.org>
+ - Bjorn Andersson <andersson@kernel.org>
description:
The A53 PLL on few Qualcomm platforms is the main CPU PLL used used for
@@ -16,7 +16,12 @@ description:
properties:
compatible:
enum:
+ - qcom,ipq5018-a53pll
+ - qcom,ipq5332-a53pll
- qcom,ipq6018-a53pll
+ - qcom,ipq8074-a53pll
+ - qcom,ipq9574-a73pll
+ - qcom,msm8226-a7pll
- qcom,msm8916-a53pll
- qcom,msm8939-a53pll
@@ -36,6 +41,9 @@ properties:
operating-points-v2: true
+ opp-table:
+ type: object
+
required:
- compatible
- reg
@@ -44,14 +52,14 @@ required:
additionalProperties: false
examples:
- #Example 1 - A53 PLL found on MSM8916 devices
+ # Example 1 - A53 PLL found on MSM8916 devices
- |
a53pll: clock@b016000 {
compatible = "qcom,msm8916-a53pll";
reg = <0xb016000 0x40>;
#clock-cells = <0>;
};
- #Example 2 - A53 PLL found on IPQ6018 devices
+ # Example 2 - A53 PLL found on IPQ6018 devices
- |
a53pll_ipq: clock-controller@b116000 {
compatible = "qcom,ipq6018-a53pll";
diff --git a/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml
index 0e96f693b050..809c34eb7d5a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/qcom,a7pll.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm A7 PLL Binding
+title: Qualcomm A7 PLL clock
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
diff --git a/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml
index c40a74b5d672..8b8932bd5a92 100644
--- a/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/qcom,aoncc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for LPASS Always ON Clock Controller on SM8250 SoCs
+title: LPASS Always ON Clock Controller on SM8250 SoCs
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -17,7 +17,7 @@ description: |
properties:
compatible:
- const: qcom,sm8250-lpass-aon
+ const: qcom,sm8250-lpass-aoncc
reg:
maxItems: 1
@@ -28,11 +28,13 @@ properties:
clocks:
items:
- description: LPASS Core voting clock
+ - description: LPASS Audio codec voting clock
- description: Glitch Free Mux register clock
clock-names:
items:
- const: core
+ - const: audio
- const: bus
required:
@@ -50,9 +52,10 @@ examples:
#include <dt-bindings/sound/qcom,q6afe.h>
clock-controller@3800000 {
#clock-cells = <1>;
- compatible = "qcom,sm8250-lpass-aon";
+ compatible = "qcom,sm8250-lpass-aoncc";
reg = <0x03380000 0x40000>;
clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
<&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
- clock-names = "core", "bus";
+ clock-names = "core", "audio", "bus";
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml
index 915d76206ad0..cfca888f6014 100644
--- a/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/qcom,audiocc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for LPASS Audio Clock Controller on SM8250 SoCs
+title: LPASS Audio Clock Controller on SM8250 SoCs
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -28,11 +28,13 @@ properties:
clocks:
items:
- description: LPASS Core voting clock
+ - description: LPASS Audio codec voting clock
- description: Glitch Free Mux register clock
clock-names:
items:
- const: core
+ - const: audio
- const: bus
required:
@@ -53,6 +55,7 @@ examples:
compatible = "qcom,sm8250-lpass-audiocc";
reg = <0x03300000 0x30000>;
clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
<&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
- clock-names = "core", "bus";
+ clock-names = "core", "audio", "bus";
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
index 9f239c3960d1..5c3ff37ec0d7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
@@ -4,16 +4,19 @@
$id: http://devicetree.org/schemas/clock/qcom,camcc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Camera Clock & Reset Controller Binding for SM8250
+title: Qualcomm Camera Clock & Reset Controller on SM8250
maintainers:
- Jonathan Marek <jonathan@marek.ca>
description: |
- Qualcomm camera clock control module which supports the clocks, resets and
+ Qualcomm camera clock control module provides the clocks, resets and
power domains on SM8250.
- See also dt-bindings/clock/qcom,camcc-sm8250.h
+ See also: include/dt-bindings/clock/qcom,camcc-sm8250.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
@@ -21,46 +24,49 @@ properties:
clocks:
items:
+ - description: AHB
- description: Board XO source
+ - description: Board active XO source
- description: Sleep clock source
clock-names:
items:
+ - const: iface
- const: bi_tcxo
+ - const: bi_tcxo_ao
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
+ power-domains:
+ items:
+ - description: MMCX power domain
reg:
maxItems: 1
+ required-opps:
+ maxItems: 1
+ description:
+ OPP node describing required MMCX performance point.
+
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@ad00000 {
compatible = "qcom,sm8250-camcc";
reg = <0x0ad00000 0x10000>;
- clocks = <&rpmhcc RPMH_CXO_CLK>,
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- clock-names = "bi_tcxo", "sleep_clk";
+ clock-names = "iface", "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sc8280xp.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sc8280xp.yaml
new file mode 100644
index 000000000000..ffae037779a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sc8280xp.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,dispcc-sc8280xp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on SC8280XP
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Qualcomm display clock control module which supports the clocks, resets and
+ power domains for the two MDSS instances on SC8280XP.
+
+ See also:
+ include/dt-bindings/clock/qcom,dispcc-sc8280xp.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-dispcc0
+ - qcom,sc8280xp-dispcc1
+
+ clocks:
+ items:
+ - description: AHB interface clock,
+ - description: SoC CXO clock
+ - description: SoC sleep clock
+ - description: DisplayPort 0 link clock
+ - description: DisplayPort 0 VCO div clock
+ - description: DisplayPort 1 link clock
+ - description: DisplayPort 1 VCO div clock
+ - description: DisplayPort 2 link clock
+ - description: DisplayPort 2 VCO div clock
+ - description: DisplayPort 3 link clock
+ - description: DisplayPort 3 VCO div clock
+ - description: DSI 0 PLL byte clock
+ - description: DSI 0 PLL DSI clock
+ - description: DSI 1 PLL byte clock
+ - description: DSI 1 PLL DSI clock
+
+ power-domains:
+ items:
+ - description: MMCX power domain
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sc8280xp-dispcc0";
+ reg = <0x0af00000 0x20000>;
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&mdss0_dp_phy0 0>,
+ <&mdss0_dp_phy0 1>,
+ <&mdss0_dp_phy1 0>,
+ <&mdss0_dp_phy1 1>,
+ <&mdss0_dp_phy2 0>,
+ <&mdss0_dp_phy2 1>,
+ <&mdss0_dp_phy3 0>,
+ <&mdss0_dp_phy3 1>,
+ <&mdss0_dsi0_phy 0>,
+ <&mdss0_dsi0_phy 1>,
+ <&mdss0_dsi1_phy 0>,
+ <&mdss0_dsi1_phy 1>;
+ power-domains = <&rpmhpd SC8280XP_MMCX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
index 7a03ef19c947..ef2b1e204430 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm6125.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock Controller Binding for SM6125
+title: Qualcomm Display Clock Controller on SM6125
maintainers:
- Martin Botka <martin.botka@somainline.org>
description: |
- Qualcomm display clock control module which supports the clocks and
- power domains on SM6125.
+ Qualcomm display clock control module provides the clocks and power domains
+ on SM6125.
- See also:
- dt-bindings/clock/qcom,dispcc-sm6125.h
+ See also: include/dt-bindings/clock/qcom,dispcc-sm6125.h
properties:
compatible:
@@ -30,6 +29,7 @@ properties:
- description: Link clock from DP PHY
- description: VCO DIV clock from DP PHY
- description: AHB config clock from GCC
+ - description: GPLL0 div source from GCC
clock-names:
items:
@@ -40,6 +40,7 @@ properties:
- const: dp_phy_pll_link_clk
- const: dp_phy_pll_vco_div_clk
- const: cfg_ahb_clk
+ - const: gcc_disp_gpll0_div_clk_src
'#clock-cells':
const: 1
@@ -47,6 +48,16 @@ properties:
'#power-domain-cells':
const: 1
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the CX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing the power domain's performance point.
+ maxItems: 1
+
reg:
maxItems: 1
@@ -64,23 +75,31 @@ examples:
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/clock/qcom,gcc-sm6125.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
clock-controller@5f00000 {
compatible = "qcom,sm6125-dispcc";
reg = <0x5f00000 0x20000>;
+
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&dsi0_phy 0>,
<&dsi0_phy 1>,
<&dsi1_phy 1>,
<&dp_phy 0>,
<&dp_phy 1>,
- <&gcc GCC_DISP_AHB_CLK>;
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
clock-names = "bi_tcxo",
"dsi0_phy_pll_out_byteclk",
"dsi0_phy_pll_out_dsiclk",
"dsi1_phy_pll_out_dsiclk",
"dp_phy_pll_link_clk",
"dp_phy_pll_vco_div_clk",
- "cfg_ahb_clk";
+ "cfg_ahb_clk",
+ "gcc_disp_gpll0_div_clk_src";
+
+ required-opps = <&rpmhpd_opp_ret>;
+ power-domains = <&rpmpd SM6125_VDDCX>;
+
#clock-cells = <1>;
#power-domain-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml
index e706678b353a..a602e882e964 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml
@@ -4,16 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm6350.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock & Reset Controller Binding for SM6350
+title: Qualcomm Display Clock & Reset Controller on SM6350
maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
description: |
- Qualcomm display clock control module which supports the clocks, resets and
- power domains on SM6350.
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM6350.
- See also dt-bindings/clock/qcom,dispcc-sm6350.h.
+ See also: include/dt-bindings/clock/qcom,dispcc-sm6350.h
properties:
compatible:
@@ -37,28 +37,16 @@ properties:
- const: dp_phy_pll_link_clk
- const: dp_phy_pll_vco_div_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
index 7a8d375e055e..53a5ab319159 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
@@ -4,19 +4,19 @@
$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm8x50.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250/SM8350
+title: Qualcomm Display Clock & Reset Controller on SM8150/SM8250/SM8350
maintainers:
- Jonathan Marek <jonathan@marek.ca>
description: |
- Qualcomm display clock control module which supports the clocks, resets and
- power domains on SM8150/SM8250/SM8350.
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM8150/SM8250/SM8350.
- See also:
- dt-bindings/clock/qcom,dispcc-sm8150.h
- dt-bindings/clock/qcom,dispcc-sm8250.h
- dt-bindings/clock/qcom,dispcc-sm8350.h
+ See also::
+ include/dt-bindings/clock/qcom,dispcc-sm8150.h
+ include/dt-bindings/clock/qcom,dispcc-sm8250.h
+ include/dt-bindings/clock/qcom,dispcc-sm8350.h
properties:
compatible:
@@ -27,6 +27,7 @@ properties:
- qcom,sm8350-dispcc
clocks:
+ minItems: 7
items:
- description: Board XO source
- description: Byte clock from DSI PHY0
@@ -35,8 +36,15 @@ properties:
- description: Pixel clock from DSI PHY1
- description: Link clock from DP PHY
- description: VCO DIV clock from DP PHY
+ - description: Link clock from eDP PHY
+ - description: VCO DIV clock from eDP PHY
+ - description: Link clock from DP1 PHY
+ - description: VCO DIV clock from DP1 PHY
+ - description: Link clock from DP2 PHY
+ - description: VCO DIV clock from DP2 PHY
clock-names:
+ minItems: 7
items:
- const: bi_tcxo
- const: dsi0_phy_pll_out_byteclk
@@ -45,18 +53,12 @@ properties:
- const: dsi1_phy_pll_out_dsiclk
- const: dp_phy_pll_link_clk
- const: dp_phy_pll_vco_div_clk
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
+ - const: edp_phy_pll_link_clk
+ - const: edp_phy_pll_vco_div_clk
+ - const: dptx1_phy_pll_link_clk
+ - const: dptx1_phy_pll_vco_div_clk
+ - const: dptx2_phy_pll_link_clk
+ - const: dptx2_phy_pll_vco_div_clk
power-domains:
description:
@@ -70,19 +72,31 @@ properties:
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sc8180x-dispcc
+ then:
+ properties:
+ clocks:
+ maxItems: 7
+ clock-names:
+ maxItems: 7
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@af00000 {
compatible = "qcom,sm8250-dispcc";
reg = <0x0af00000 0x10000>;
@@ -103,7 +117,7 @@ examples:
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
index 3cf404c9325a..27df7e3e5bf3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
@@ -4,22 +4,22 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-apq8064.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for APQ8064/MSM8960
-
-allOf:
- - $ref: qcom,gcc.yaml#
+title: Qualcomm Global Clock & Reset Controller on APQ8064/MSM8960
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on APQ8064.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on APQ8064.
- See also:
- - dt-bindings/clock/qcom,gcc-msm8960.h
- - dt-bindings/reset/qcom,gcc-msm8960.h
+ See also::
+ include/dt-bindings/clock/qcom,gcc-msm8960.h
+ include/dt-bindings/reset/qcom,gcc-msm8960.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
@@ -38,6 +38,15 @@ properties:
description: child tsens device
$ref: /schemas/thermal/qcom-tsens.yaml#
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: cxo
+ - const: pxo
+ - const: pll4
+
nvmem-cells:
minItems: 1
maxItems: 2
@@ -60,6 +69,8 @@ properties:
const: 1
deprecated: true
+ '#power-domain-cells': false
+
required:
- compatible
@@ -72,7 +83,6 @@ examples:
reg = <0x00900000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
- #power-domain-cells = <1>;
thermal-sensor {
compatible = "qcom,msm8960-tsens";
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
index 397fb918e032..0a0a26d9beab 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
@@ -4,19 +4,19 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-apq8084.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for APQ8084
+title: Qualcomm Global Clock & Reset Controller on APQ8084
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on APQ8084.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on APQ8084.
See also::
- - dt-bindings/clock/qcom,gcc-apq8084.h
- - dt-bindings/reset/qcom,gcc-apq8084.h
+ include/dt-bindings/clock/qcom,gcc-apq8084.h
+ include/dt-bindings/reset/qcom,gcc-apq8084.h
allOf:
- $ref: qcom,gcc.yaml#
@@ -25,18 +25,63 @@ properties:
compatible:
const: qcom,gcc-apq8084
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+ - description: UFS RX symbol 0 clock
+ - description: UFS RX symbol 1 clock
+ - description: UFS TX symbol 0 clock
+ - description: UFS TX symbol 1 clock
+ - description: SATA ASIC0 clock
+ - description: SATA RX clock
+ - description: PCIe PIPE clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: ufs_rx_symbol_0_clk_src
+ - const: ufs_rx_symbol_1_clk_src
+ - const: ufs_tx_symbol_0_clk_src
+ - const: ufs_tx_symbol_1_clk_src
+ - const: sata_asic0_clk
+ - const: sata_rx_clk
+ - const: pcie_pipe
+
required:
- compatible
+ - '#power-domain-cells'
unevaluatedProperties: false
examples:
- |
+ /* UFS PHY on APQ8084 is not supported (yet), so these bindings just serve an example */
clock-controller@fc400000 {
compatible = "qcom,gcc-apq8084";
reg = <0xfc400000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
+
+ clocks = <&xo_board>,
+ <&sleep_clk>,
+ <&ufsphy 0>,
+ <&ufsphy 1>,
+ <&ufsphy 2>,
+ <&ufsphy 3>,
+ <&sata 0>,
+ <&sata 1>,
+ <&pcie_phy>;
+ clock-names = "xo",
+ "sleep_clk",
+ "ufs_rx_symbol_0_clk_src",
+ "ufs_rx_symbol_1_clk_src",
+ "ufs_tx_symbol_0_clk_src",
+ "ufs_tx_symbol_1_clk_src",
+ "sata_asic0_clk",
+ "sata_rx_clk",
+ "pcie_pipe";
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml
new file mode 100644
index 000000000000..c91039dc100e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq4019.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on IPQ4019
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Robert Marko <robert.markoo@sartura.hr>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ4019.
+
+ See also: include/dt-bindings/clock/qcom,gcc-ipq4019.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ const: qcom,gcc-ipq4019
+
+ clocks:
+ items:
+ - description: board XO clock
+ - description: sleep clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+
+ '#power-domain-cells': false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@1800000 {
+ compatible = "qcom,gcc-ipq4019";
+ reg = <0x1800000 0x60000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&xo>, <&sleep_clk>;
+ clock-names = "xo", "sleep_clk";
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
new file mode 100644
index 000000000000..4d2614d4f368
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq6018.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on IPQ6018
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Robert Marko <robimarko@gmail.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ6018.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-ipq6018.h
+ include/dt-bindings/reset/qcom,gcc-ipq6018.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ const: qcom,gcc-ipq6018
+
+ clocks:
+ items:
+ - description: board XO clock
+ - description: sleep clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+
+ '#power-domain-cells': false
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@1800000 {
+ compatible = "qcom,gcc-ipq6018";
+ reg = <0x01800000 0x80000>;
+ clocks = <&xo>, <&sleep_clk>;
+ clock-names = "xo", "sleep_clk";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
index 9eb91dd22557..a71557395c01 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
@@ -4,21 +4,21 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq8064.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for IPQ8064
-
-allOf:
- - $ref: qcom,gcc.yaml#
+title: Qualcomm Global Clock & Reset Controller on IPQ8064
maintainers:
- Ansuel Smith <ansuelsmth@gmail.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on IPQ8064.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ8064.
- See also:
- - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
- - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
+ See also::
+ include/dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
+ include/dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
@@ -27,14 +27,18 @@ properties:
- const: syscon
clocks:
+ minItems: 2
items:
- description: PXO source
- description: CXO source
+ - description: PLL4 from LCC
clock-names:
+ minItems: 2
items:
- const: pxo
- const: cxo
+ - const: pll4
thermal-sensor:
type: object
@@ -42,6 +46,8 @@ properties:
allOf:
- $ref: /schemas/thermal/qcom-tsens.yaml#
+ '#power-domain-cells': false
+
required:
- compatible
- clocks
@@ -51,16 +57,16 @@ unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/qcom,lcc-ipq806x.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
gcc: clock-controller@900000 {
compatible = "qcom,gcc-ipq8064", "syscon";
reg = <0x00900000 0x4000>;
- clocks = <&pxo_board>, <&cxo_board>;
- clock-names = "pxo", "cxo";
+ clocks = <&pxo_board>, <&cxo_board>, <&lcc PLL4>;
+ clock-names = "pxo", "cxo", "pll4";
#clock-cells = <1>;
#reset-cells = <1>;
- #power-domain-cells = <1>;
tsens: thermal-sensor {
compatible = "qcom,ipq8064-tsens";
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
index 21470f52ce36..00d7df75b3d6 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
@@ -4,47 +4,44 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq8074.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Bindingfor IPQ8074
+title: Qualcomm Global Clock & Reset Controller on IPQ8074
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on IPQ8074.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ8074.
- See also:
- - dt-bindings/clock/qcom,gcc-ipq8074.h
+ See also: include/dt-bindings/clock/qcom,gcc-ipq8074.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
const: qcom,gcc-ipq8074
- '#clock-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- reg:
- maxItems: 1
+ clocks:
+ items:
+ - description: board XO clock
+ - description: sleep clock
+ - description: Gen3 QMP PCIe PHY PIPE clock
+ - description: Gen2 QMP PCIe PHY PIPE clock
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: pcie0_pipe
+ - const: pcie1_pipe
required:
- compatible
- - reg
- - '#clock-cells'
- '#power-domain-cells'
- - '#reset-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
new file mode 100644
index 000000000000..d7da30b0e7ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-mdm9607.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-mdm9607.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-mdm9607
+
+required:
+ - compatible
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@900000 {
+ compatible = "qcom,gcc-mdm9607";
+ reg = <0x900000 0x4000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
new file mode 100644
index 000000000000..418dea31eb62
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-mdm9615.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-mdm9615.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-mdm9615
+
+ clocks:
+ items:
+ - description: CXO clock
+ - description: PLL4 from LLC
+
+ '#power-domain-cells': false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@900000 {
+ compatible = "qcom,gcc-mdm9615";
+ reg = <0x900000 0x4000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&cxo_board>,
+ <&lcc_pll4>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
new file mode 100644
index 000000000000..e03b6d0acdb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8660.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on MSM8660
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks and resets on
+ MSM8660
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-msm8660.h
+ include/dt-bindings/reset/qcom,gcc-msm8660.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-msm8660
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pxo
+ - const: cxo
+
+ '#power-domain-cells': false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ # Example for GCC for MSM8974:
+ - |
+ clock-controller@900000 {
+ compatible = "qcom,gcc-msm8660";
+ reg = <0x900000 0x4000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&pxo_board>, <&cxo_board>;
+ clock-names = "pxo", "cxo";
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
new file mode 100644
index 000000000000..ce1f5a60bd8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8909.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on MSM8909, MSM8917 and QM215
+
+maintainers:
+ - Stephan Gerhold <stephan@gerhold.net>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8909, MSM8917 or QM215.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-msm8909.h
+ include/dt-bindings/clock/qcom,gcc-msm8917.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-msm8909
+ - qcom,gcc-msm8917
+ - qcom,gcc-qm215
+
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: dsi0pll
+ - const: dsi0pllbyte
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gcc: clock-controller@1800000 {
+ compatible = "qcom,gcc-msm8909";
+ reg = <0x01800000 0x80000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ clocks = <&xo_board>, <&sleep_clk>, <&dsi0_phy 1>, <&dsi0_phy 0>;
+ clock-names = "xo", "sleep_clk", "dsi0pll", "dsi0pllbyte";
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
new file mode 100644
index 000000000000..258b6b93deca
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8916.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on MSM8916 and MSM8939
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8916 or MSM8939.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-msm8916.h
+ include/dt-bindings/clock/qcom,gcc-msm8939.h
+ include/dt-bindings/reset/qcom,gcc-msm8916.h
+ include/dt-bindings/reset/qcom,gcc-msm8939.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-msm8916
+ - qcom,gcc-msm8939
+
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: External MCLK clock
+ - description: External Primary I2S clock
+ - description: External Secondary I2S clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: ext_mclk
+ - const: ext_pri_i2s
+ - const: ext_sec_i2s
+
+required:
+ - compatible
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@300000 {
+ compatible = "qcom,gcc-msm8916";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ reg = <0x300000 0x90000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
new file mode 100644
index 000000000000..f2e37f439d28
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8953.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on MSM8953
+
+maintainers:
+ - Adam Skladowski <a_skl39@protonmail.com>
+ - Sireesh Kodali <sireeshkodali@protonmail.com>
+ - Barnabas Czeman <barnabas.czeman@mainlining.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8937 or MSM8953.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-msm8917.h
+ include/dt-bindings/clock/qcom,gcc-msm8953.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-msm8937
+ - qcom,gcc-msm8953
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: Byte clock from DSI PHY1
+ - description: Pixel clock from DSI PHY1
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ clock-controller@1800000 {
+ compatible = "qcom,gcc-msm8953";
+ reg = <0x01800000 0x80000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&sleep_clk>,
+ <&dsi0_phy 1>,
+ <&dsi0_phy 0>,
+ <&dsi1_phy 1>,
+ <&dsi1_phy 0>;
+ clock-names = "xo",
+ "sleep",
+ "dsi0pll",
+ "dsi0pllbyte",
+ "dsi1pll",
+ "dsi1pllbyte";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
new file mode 100644
index 000000000000..929fafc84c19
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8974.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on MSM8974 (including Pro) and MSM8226
+ Controller
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8974 (all variants) and MSM8226.
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
+ include/dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
+
+$ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-msm8226
+ - qcom,gcc-msm8974
+ - qcom,gcc-msm8974pro
+ - qcom,gcc-msm8974pro-ac
+
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+
+required:
+ - compatible
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@fc400000 {
+ compatible = "qcom,gcc-msm8974";
+ reg = <0x00100000 0x94000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+
+ clock-names = "xo", "sleep_clk";
+ clocks = <&xo_board>,
+ <&sleep_clk>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml
index f3430b159caa..92195091a919 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8976.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for MSM8976
+title: Qualcomm Global Clock & Reset Controller on MSM8976
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on MSM8976.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8976.
- See also:
- - dt-bindings/clock/qcom,gcc-msm8976.h
+ See also: include/dt-bindings/clock/qcom,gcc-msm8976.h
properties:
compatible:
@@ -45,29 +44,17 @@ properties:
description:
Phandle to voltage regulator providing power to the GX domain.
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- vdd_gfx-supply
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
index 22e67b238bb6..93bcd61461e7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8994.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for MSM8994
+title: Qualcomm Global Clock & Reset Controller on MSM8994
maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on MSM8994 and MSM8992.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8994 and MSM8992.
- See also:
- - dt-bindings/clock/qcom,gcc-msm8994.h
+ See also: include/dt-bindings/clock/qcom,gcc-msm8994.h
properties:
compatible:
@@ -32,28 +31,16 @@ properties:
- const: xo
- const: sleep
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
index 005e0edd4609..64796f45f294 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8996.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for MSM8996
+title: Qualcomm Global Clock & Reset Controller on MSM8996
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
+ Qualcomm global clock control module which provides the clocks, resets and
power domains on MSM8996.
- See also:
- - dt-bindings/clock/qcom,gcc-msm8996.h
+ See also: include/dt-bindings/clock/qcom,gcc-msm8996.h
properties:
compatible:
@@ -49,30 +48,14 @@ properties:
- const: ufs_rx_symbol_1_clk_src
- const: ufs_tx_symbol_0_clk_src
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
index 8151c0a05649..d882f2b6620e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8998.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for MSM8998
+title: Qualcomm Global Clock & Reset Controller on MSM8998
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on MSM8998.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on MSM8998.
- See also:
- - dt-bindings/clock/qcom,gcc-msm8998.h
+ See also: include/dt-bindings/clock/qcom,gcc-msm8998.h
properties:
compatible:
@@ -26,7 +25,6 @@ properties:
- description: Board XO source
- description: Sleep clock source
- description: Audio reference clock (Optional clock)
- - description: PLL test clock source (Optional clock)
minItems: 2
clock-names:
@@ -34,35 +32,18 @@ properties:
- const: xo
- const: sleep_clk
- const: aud_ref_clk # Optional clock
- - const: core_bi_pll_test_se # Optional clock
minItems: 2
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -75,11 +56,9 @@ examples:
reg = <0x00100000 0xb0000>;
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&sleep>,
- <0>,
<0>;
clock-names = "xo",
"sleep_clk",
- "aud_ref_clk",
- "core_bi_pll_test_se";
+ "aud_ref_clk";
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
deleted file mode 100644
index 6c78df0c46a9..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/qcom,gcc-other.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Global Clock & Reset Controller Binding
-
-maintainers:
- - Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
-
-description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains.
-
- See also:
- - dt-bindings/clock/qcom,gcc-ipq4019.h
- - dt-bindings/clock/qcom,gcc-ipq6018.h
- - dt-bindings/reset/qcom,gcc-ipq6018.h
- - dt-bindings/clock/qcom,gcc-msm8939.h
- - dt-bindings/clock/qcom,gcc-msm8953.h
- - dt-bindings/reset/qcom,gcc-msm8939.h
- - dt-bindings/clock/qcom,gcc-msm8660.h
- - dt-bindings/reset/qcom,gcc-msm8660.h
- - dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
- - dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
- - dt-bindings/clock/qcom,gcc-mdm9607.h
- - dt-bindings/clock/qcom,gcc-mdm9615.h
- - dt-bindings/reset/qcom,gcc-mdm9615.h
- - dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
-
-allOf:
- - $ref: "qcom,gcc.yaml#"
-
-properties:
- compatible:
- enum:
- - qcom,gcc-ipq4019
- - qcom,gcc-ipq6018
- - qcom,gcc-mdm9607
- - qcom,gcc-msm8226
- - qcom,gcc-msm8660
- - qcom,gcc-msm8916
- - qcom,gcc-msm8939
- - qcom,gcc-msm8953
- - qcom,gcc-msm8974
- - qcom,gcc-msm8974pro
- - qcom,gcc-msm8974pro-ac
- - qcom,gcc-mdm9615
- - qcom,gcc-sdm630
- - qcom,gcc-sdm660
-
-required:
- - compatible
-
-unevaluatedProperties: false
-
-examples:
- # Example for GCC for MSM8974:
- - |
- clock-controller@900000 {
- compatible = "qcom,gcc-msm8974";
- reg = <0x900000 0x4000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- #power-domain-cells = <1>;
- };
-...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml
index 5de9c8263138..b9194fa11e47 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-qcm2290.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-qcm2290.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for QCM2290
+title: Qualcomm Global Clock & Reset Controller on QCM2290
maintainers:
- Shawn Guo <shawn.guo@linaro.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets
- and power domains on QCM2290.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on QCM2290.
- See also:
- - dt-bindings/clock/qcom,gcc-qcm2290.h
+ See also: include/dt-bindings/clock/qcom,gcc-qcm2290.h
properties:
compatible:
@@ -30,32 +29,16 @@ properties:
- const: bi_tcxo
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
index ce06f3f8c3e3..6b35a3c080a2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml
@@ -4,43 +4,48 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-qcs404.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Bindingfor QCS404
+title: Qualcomm Global Clock & Reset Controller on QCS404
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on QCS404.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on QCS404.
- See also:
- - dt-bindings/clock/qcom,gcc-qcs404.h
+ See also: include/dt-bindings/clock/qcom,gcc-qcs404.h
properties:
compatible:
const: qcom,gcc-qcs404
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+ - description: PCIe 0 PIPE clock (optional)
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: HDMI phy PLL clock
+
+ clock-names:
+ items:
+ - const: cxo
+ - const: sleep_clk
+ - const: pcie_0_pipe_clk_src
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: hdmi_pll
required:
- compatible
- - reg
- - '#clock-cells'
- - '#reset-cells'
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -49,5 +54,6 @@ examples:
reg = <0x01800000 0x80000>;
#clock-cells = <1>;
#reset-cells = <1>;
+ #power-domain-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
index a404c8fbee67..e30d1df3eeb5 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc7180.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SC7180
+title: Qualcomm Global Clock & Reset Controller on SC7180
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SC7180.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SC7180.
- See also:
- - dt-bindings/clock/qcom,gcc-sc7180.h
+ See also: include/dt-bindings/clock/qcom,gcc-sc7180.h
properties:
compatible:
@@ -33,36 +32,26 @@ properties:
- const: bi_tcxo_ao
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
+ power-domains:
+ items:
+ - description: CX domain
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
clock-controller@100000 {
compatible = "qcom,gcc-sc7180";
reg = <0x00100000 0x1f0000>;
@@ -70,6 +59,7 @@ examples:
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
+ power-domains = <&rpmhpd SC7180_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
index 5693b8997570..5ddaf27bb1f4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc7280.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc7280.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SC7280
+title: Qualcomm Global Clock & Reset Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SC7280.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SC7280.
- See also:
- - dt-bindings/clock/qcom,gcc-sc7280.h
+ See also: include/dt-bindings/clock/qcom,gcc-sc7280.h
properties:
compatible:
@@ -44,32 +43,26 @@ properties:
- const: ufs_phy_tx_symbol_0_clk
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
+ power-domains:
+ items:
+ - description: CX domain
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
clock-controller@100000 {
compatible = "qcom,gcc-sc7280";
reg = <0x00100000 0x1f0000>;
@@ -85,6 +78,7 @@ examples:
"pcie_1_pipe_clk", "ufs_phy_rx_symbol_0_clk",
"ufs_phy_rx_symbol_1_clk", "ufs_phy_tx_symbol_0_clk",
"usb3_phy_wrapper_gcc_usb30_pipe_clk";
+ power-domains = <&rpmhpd SC7280_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
index f03ef96e57fa..82c2ef39934d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8180x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SC8180x
+title: Qualcomm Global Clock & Reset Controller on SC8180x
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SC8180x.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SC8180x.
- See also:
- - dt-bindings/clock/qcom,gcc-sc8180x.h
+ See also: include/dt-bindings/clock/qcom,gcc-sc8180x.h
properties:
compatible:
@@ -32,36 +31,26 @@ properties:
- const: bi_tcxo_ao
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
+ power-domains:
+ items:
+ - description: CX domain
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
+ - power-domains
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
clock-controller@100000 {
compatible = "qcom,gcc-sc8180x";
reg = <0x00100000 0x1f0000>;
@@ -69,6 +58,7 @@ examples:
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
+ power-domains = <&rpmhpd SC8180X_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml
index 0bcdc69c6f89..c1eeccef66b4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8280xp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SC8280xp
+title: Qualcomm Global Clock & Reset Controller on SC8280xp
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
+ Qualcomm global clock control module provides the clocks, resets and
power domains on SC8280xp.
- See also:
- - include/dt-bindings/clock/qcom,gcc-sc8280xp.h
+ See also: include/dt-bindings/clock/qcom,gcc-sc8280xp.h
properties:
compatible:
@@ -33,7 +32,7 @@ properties:
- description: Primary USB SuperSpeed pipe clock
- description: USB4 PHY pipegmux clock source
- description: USB4 PHY DP gmux clock source
- - description: USB4 PHY sys piegmux clock source
+ - description: USB4 PHY sys pipegmux clock source
- description: USB4 PHY PCIe pipe clock
- description: USB4 PHY router max pipe clock
- description: Primary USB4 RX0 clock
@@ -46,7 +45,7 @@ properties:
- description: Second USB4 PHY router max pipe clock
- description: Secondary USB4 RX0 clock
- description: Secondary USB4 RX1 clock
- - description: Multiport USB first SupserSpeed pipe clock
+ - description: Multiport USB first SuperSpeed pipe clock
- description: Multiport USB second SuperSpeed pipe clock
- description: PCIe 2a pipe clock
- description: PCIe 2b pipe clock
@@ -56,17 +55,9 @@ properties:
- description: First EMAC controller reference clock
- description: Second EMAC controller reference clock
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
+ power-domains:
+ items:
+ - description: CX domain
protected-clocks:
maxItems: 389
@@ -74,16 +65,18 @@ properties:
required:
- compatible
- clocks
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
clock-controller@100000 {
compatible = "qcom,gcc-sc8280xp";
reg = <0x00100000 0x1f0000>;
@@ -120,6 +113,7 @@ examples:
<&pcie4_lane>,
<&rxc0_ref_clk>,
<&rxc1_ref_clk>;
+ power-domains = <&rpmhpd SC8280XP_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
new file mode 100644
index 000000000000..724ce0491118
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-sdm660.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM660/SDM630/SDM636 Global Clock & Reset Controller
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SDM630, SDM636 and SDM660
+
+ See also::
+ include/dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
+
+$ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,gcc-sdm630
+ - qcom,gcc-sdm660
+
+ clocks:
+ items:
+ - description: XO source
+ - description: Sleep clock source
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ # Example for GCC for SDM660:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,gcc-sdm660";
+ reg = <0x00100000 0x94000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+
+ clock-names = "xo", "sleep_clk";
+ clocks = <&xo_board>,
+ <&sleep_clk>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
index daf7906ebc40..a7523a414341 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
@@ -4,66 +4,82 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sdm845.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding
+title: Qualcomm Global Clock & Reset Controller on SDM670 and SDM845
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SDM845
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SDM670 and SDM845
- See also:
- - dt-bindings/clock/qcom,gcc-sdm845.h
+ See also: include/dt-bindings/clock/qcom,gcc-sdm845.h
properties:
compatible:
- const: qcom,gcc-sdm845
+ enum:
+ - qcom,gcc-sdm670
+ - qcom,gcc-sdm845
clocks:
- items:
- - description: Board XO source
- - description: Board active XO source
- - description: Sleep clock source
- - description: PCIE 0 Pipe clock source
- - description: PCIE 1 Pipe clock source
+ minItems: 3
+ maxItems: 5
clock-names:
- items:
- - const: bi_tcxo
- - const: bi_tcxo_ao
- - const: sleep_clk
- - const: pcie_0_pipe_clk
- - const: pcie_1_pipe_clk
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
+ minItems: 3
+ maxItems: 5
power-domains:
maxItems: 1
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,gcc-sdm670
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+ - const: sleep_clk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,gcc-sdm845
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 1 Pipe clock source
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+ - const: sleep_clk
+ - const: pcie_0_pipe_clk
+ - const: pcie_1_pipe_clk
+
+unevaluatedProperties: false
examples:
# Example for GCC for SDM845:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
index b0d1c65aa354..320e4f5b2b18 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx55.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SDX55
+title: Qualcomm Global Clock & Reset Controller on SDX55
maintainers:
- Vinod Koul <vkoul@kernel.org>
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
+ Qualcomm global clock control module provides the clocks, resets and
power domains on SDX55
- See also:
- - dt-bindings/clock/qcom,gcc-sdx55.h
+ See also: include/dt-bindings/clock/qcom,gcc-sdx55.h
properties:
compatible:
@@ -25,38 +24,22 @@ properties:
items:
- description: Board XO source
- description: Sleep clock source
- - description: PLL test clock source (Optional clock)
- minItems: 2
clock-names:
items:
- const: bi_tcxo
- const: sleep_clk
- - const: core_bi_pll_test_se # Optional clock
- minItems: 2
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -65,8 +48,9 @@ examples:
compatible = "qcom,gcc-sdx55";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
- <&sleep_clk>, <&pll_test_clk>;
- clock-names = "bi_tcxo", "sleep_clk", "core_bi_pll_test_se";
+ <&sleep_clk>;
+ clock-names = "bi_tcxo",
+ "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml
index 16c4cdc7b4d6..9242e6e19139 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml
@@ -4,25 +4,21 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx65.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SDX65
+title: Qualcomm Global Clock & Reset Controller on SDX65
maintainers:
- Vamsi krishna Lanka <quic_vamslank@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SDX65
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SDX65
- See also:
- - dt-bindings/clock/qcom,gcc-sdx65.h
+ See also: include/dt-bindings/clock/qcom,gcc-sdx65.h
properties:
compatible:
const: qcom,gcc-sdx65
- reg:
- maxItems: 1
-
clocks:
items:
- description: Board XO source
@@ -30,8 +26,6 @@ properties:
- description: Sleep clock source
- description: PCIE Pipe clock source
- description: USB3 phy wrapper pipe clock source
- - description: PLL test clock source (Optional clock)
- minItems: 5
clock-names:
items:
@@ -40,28 +34,17 @@ properties:
- const: sleep_clk
- const: pcie_pipe_clk
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk
- - const: core_bi_pll_test_se # Optional clock
- minItems: 5
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -70,9 +53,9 @@ examples:
compatible = "qcom,gcc-sdx65";
reg = <0x100000 0x1f7400>;
clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>,
- <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>, <&pll_test_clk>;
+ <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk",
- "pcie_pipe_clk", "usb3_phy_wrapper_gcc_usb30_pipe_clk", "core_bi_pll_test_se";
+ "pcie_pipe_clk", "usb3_phy_wrapper_gcc_usb30_pipe_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml
index 26050da844d5..c926630907c5 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6115.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM6115 and SM4250
+title: Qualcomm Global Clock & Reset Controller on SM6115 and SM4250
maintainers:
- Iskren Chernev <iskren.chernev@gmail.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM4250/6115.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM4250/6115.
- See also:
- - dt-bindings/clock/qcom,gcc-sm6115.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm6115.h
properties:
compatible:
@@ -30,32 +29,16 @@ properties:
- const: bi_tcxo
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml
index ab12b391effc..5bd422e94a38 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6125.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM6125
+title: Qualcomm Global Clock & Reset Controller on SM6125
maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM6125.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM6125.
- See also:
- - dt-bindings/clock/qcom,gcc-sm6125.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm6125.h
properties:
compatible:
@@ -30,32 +29,16 @@ properties:
- const: bi_tcxo
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml
index 20926cd8293e..819e855eaf9a 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6350.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM6350
+title: Qualcomm Global Clock & Reset Controller on SM6350
maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM6350.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM6350.
- See also:
- - dt-bindings/clock/qcom,gcc-sm6350.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm6350.h
properties:
compatible:
@@ -32,32 +31,16 @@ properties:
- const: bi_tcxo_ao
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
index 12766a866625..5f3f69fe9ddb 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8150.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM8150
+title: Qualcomm Global Clock & Reset Controller on SM8150
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM8150.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8150.
- See also:
- - dt-bindings/clock/qcom,gcc-sm8150.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm8150.h
properties:
compatible:
@@ -31,32 +30,16 @@ properties:
- const: bi_tcxo
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
index 80bd6caf5bc9..f4cd5a509c60 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml
@@ -4,18 +4,17 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM8250
+title: Qualcomm Global Clock & Reset Controller on SM8250
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM8250.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8250.
- See also:
- - dt-bindings/clock/qcom,gcc-sm8250.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm8250.h
properties:
compatible:
@@ -24,39 +23,25 @@ properties:
clocks:
items:
- description: Board XO source
+ - description: Board active XO source
- description: Sleep clock source
clock-names:
items:
- const: bi_tcxo
+ - const: bi_tcxo_ao
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding.
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -65,8 +50,9 @@ examples:
compatible = "qcom,gcc-sm8250";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- clock-names = "bi_tcxo", "sleep_clk";
+ clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
index 1122700dcc2b..97ffae3b5522 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8350.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM8350
+title: Qualcomm Global Clock & Reset Controller on SM8350
maintainers:
- Vinod Koul <vkoul@kernel.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM8350.
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8350.
- See also:
- - dt-bindings/clock/qcom,gcc-sm8350.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm8350.h
properties:
compatible:
@@ -24,7 +23,6 @@ properties:
items:
- description: Board XO source
- description: Sleep clock source
- - description: PLL test clock source (Optional clock)
- description: PCIE 0 Pipe clock source (Optional clock)
- description: PCIE 1 Pipe clock source (Optional clock)
- description: UFS card Rx symbol 0 clock source (Optional clock)
@@ -41,7 +39,6 @@ properties:
items:
- const: bi_tcxo
- const: sleep_clk
- - const: core_bi_pll_test_se # Optional clock
- const: pcie_0_pipe_clk # Optional clock
- const: pcie_1_pipe_clk # Optional clock
- const: ufs_card_rx_symbol_0_clk # Optional clock
@@ -54,28 +51,16 @@ properties:
- const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock
minItems: 2
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- clocks
- clock-names
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
index 58d98a766de6..3169ac05e1d8 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
@@ -4,21 +4,22 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8450.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding for SM8450
+title: Qualcomm Global Clock & Reset Controller on SM8450
maintainers:
- Vinod Koul <vkoul@kernel.org>
description: |
- Qualcomm global clock control module which supports the clocks, resets and
- power domains on SM8450
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8450
- See also:
- - dt-bindings/clock/qcom,gcc-sm8450.h
+ See also: include/dt-bindings/clock/qcom,gcc-sm8450.h
properties:
compatible:
- const: qcom,gcc-sm8450
+ enum:
+ - qcom,gcc-sm8450
+ - qcom,sm8475-gcc
clocks:
items:
@@ -26,7 +27,7 @@ properties:
- description: Sleep clock source
- description: PCIE 0 Pipe clock source (Optional clock)
- description: PCIE 1 Pipe clock source (Optional clock)
- - description: PCIE 1 Phy Auxillary clock source (Optional clock)
+ - description: PCIE 1 Phy Auxiliary clock source (Optional clock)
- description: UFS Phy Rx symbol 0 clock source (Optional clock)
- description: UFS Phy Rx symbol 1 clock source (Optional clock)
- description: UFS Phy Tx symbol 0 clock source (Optional clock)
@@ -46,28 +47,16 @@ properties:
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock
minItems: 2
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
index 2ed27a2ef445..513d6fd89249 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml
@@ -4,15 +4,15 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Global Clock & Reset Controller Binding Common Bindings
+title: Qualcomm Global Clock & Reset Controller Common Properties
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Common bindings for Qualcomm global clock control module which supports
- the clocks, resets and power domains.
+ Common bindings for Qualcomm global clock control module providing the
+ clocks, resets and power domains.
properties:
'#clock-cells':
@@ -35,7 +35,6 @@ required:
- reg
- '#clock-cells'
- '#reset-cells'
- - '#power-domain-cells'
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml
new file mode 100644
index 000000000000..45f027c70e03
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,glymur-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on GLYMUR
+
+maintainers:
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+ Qualcomm display clock control module which supports the clocks, resets and
+ power domains for the MDSS instances on GLYMUR SoC.
+
+ See also:
+ include/dt-bindings/clock/qcom,dispcc-glymur.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,glymur-dispcc
+
+ clocks:
+ items:
+ - description: Board CXO clock
+ - description: Board sleep clock
+ - description: DisplayPort 0 link clock
+ - description: DisplayPort 0 VCO div clock
+ - description: DisplayPort 1 link clock
+ - description: DisplayPort 1 VCO div clock
+ - description: DisplayPort 2 link clock
+ - description: DisplayPort 2 VCO div clock
+ - description: DisplayPort 3 link clock
+ - description: DisplayPort 3 VCO div clock
+ - description: DSI 0 PLL byte clock
+ - description: DSI 0 PLL DSI clock
+ - description: DSI 1 PLL byte clock
+ - description: DSI 1 PLL DSI clock
+ - description: Standalone PHY 0 PLL link clock
+ - description: Standalone PHY 0 VCO div clock
+ - description: Standalone PHY 1 PLL link clock
+ - description: Standalone PHY 1 VCO div clock
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ clock-controller@af00000 {
+ compatible = "qcom,glymur-dispcc";
+ reg = <0x0af00000 0x20000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&mdss_dp_phy0 0>,
+ <&mdss_dp_phy0 1>,
+ <&mdss_dp_phy1 0>,
+ <&mdss_dp_phy1 1>,
+ <&mdss_dp_phy2 0>,
+ <&mdss_dp_phy2 1>,
+ <&mdss_dp_phy3 0>,
+ <&mdss_dp_phy3 1>,
+ <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>,
+ <&mdss_dsi1_phy 0>,
+ <&mdss_dsi1_phy 1>,
+ <&mdss_phy0_link 0>,
+ <&mdss_phy0_vco_div 0>,
+ <&mdss_phy1_link 1>,
+ <&mdss_phy1_vco_div 1>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-gcc.yaml
new file mode 100644
index 000000000000..b05b0e6c4483
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,glymur-gcc.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,glymur-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on Glymur SoC
+
+maintainers:
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on Glymur SoC.
+
+ See also: include/dt-bindings/clock/qcom,glymur-gcc.h
+
+properties:
+ compatible:
+ const: qcom,glymur-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board XO_A source
+ - description: Sleep clock source
+ - description: USB 0 Phy DP0 GMUX clock source
+ - description: USB 0 Phy DP1 GMUX clock source
+ - description: USB 0 Phy PCIE PIPEGMUX clock source
+ - description: USB 0 Phy PIPEGMUX clock source
+ - description: USB 0 Phy SYS PCIE PIPEGMUX clock source
+ - description: USB 1 Phy DP0 GMUX 2 clock source
+ - description: USB 1 Phy DP1 GMUX 2 clock source
+ - description: USB 1 Phy PCIE PIPEGMUX clock source
+ - description: USB 1 Phy PIPEGMUX clock source
+ - description: USB 1 Phy SYS PCIE PIPEGMUX clock source
+ - description: USB 2 Phy DP0 GMUX 2 clock source
+ - description: USB 2 Phy DP1 GMUX 2 clock source
+ - description: USB 2 Phy PCIE PIPEGMUX clock source
+ - description: USB 2 Phy PIPEGMUX clock source
+ - description: USB 2 Phy SYS PCIE PIPEGMUX clock source
+ - description: PCIe 3a pipe clock
+ - description: PCIe 3b pipe clock
+ - description: PCIe 4 pipe clock
+ - description: PCIe 5 pipe clock
+ - description: PCIe 6 pipe clock
+ - description: QUSB4 0 PHY RX 0 clock source
+ - description: QUSB4 0 PHY RX 1 clock source
+ - description: QUSB4 1 PHY RX 0 clock source
+ - description: QUSB4 1 PHY RX 1 clock source
+ - description: QUSB4 2 PHY RX 0 clock source
+ - description: QUSB4 2 PHY RX 1 clock source
+ - description: UFS PHY RX Symbol 0 clock source
+ - description: UFS PHY RX Symbol 1 clock source
+ - description: UFS PHY TX Symbol 0 clock source
+ - description: USB3 PHY 0 pipe clock source
+ - description: USB3 PHY 1 pipe clock source
+ - description: USB3 PHY 2 pipe clock source
+ - description: USB3 UNI PHY pipe 0 clock source
+ - description: USB3 UNI PHY pipe 1 clock source
+ - description: USB4 PHY 0 pcie pipe clock source
+ - description: USB4 PHY 0 Max pipe clock source
+ - description: USB4 PHY 1 pcie pipe clock source
+ - description: USB4 PHY 1 Max pipe clock source
+ - description: USB4 PHY 2 pcie pipe clock source
+ - description: USB4 PHY 2 Max pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,glymur-gcc";
+ reg = <0x100000 0x1f9000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>,
+ <&usb_0_phy_dp0_gmux>,
+ <&usb_0_phy_dp1_gmux>,
+ <&usb_0_phy_pcie_pipegmux>,
+ <&usb_0_phy_pipegmux>,
+ <&usb_0_phy_sys_pcie_pipegmux>,
+ <&usb_1_phy_dp0_gmux_2>,
+ <&usb_1_phy_dp1_gmux_2>,
+ <&usb_1_phy_pcie_pipegmux>,
+ <&usb_1_phy_pipegmux>,
+ <&usb_1_phy_sys_pcie_pipegmux>,
+ <&usb_2_phy_dp0_gmux 2>,
+ <&usb_2_phy_dp1_gmux 2>,
+ <&usb_2_phy_pcie_pipegmux>,
+ <&usb_2_phy_pipegmux>,
+ <&usb_2_phy_sys_pcie_pipegmux>,
+ <&pcie_3a_pipe>, <&pcie_3b_pipe>,
+ <&pcie_4_pipe>, <&pcie_5_pipe>,
+ <&pcie_6_pipe>,
+ <&qusb4_0_phy_rx_0>, <&qusb4_0_phy_rx_1>,
+ <&qusb4_1_phy_rx_0>, <&qusb4_1_phy_rx_1>,
+ <&qusb4_2_phy_rx_0>, <&qusb4_2_phy_rx_1>,
+ <&ufs_phy_rx_symbol_0>, <&ufs_phy_rx_symbol_1>,
+ <&ufs_phy_tx_symbol_0>,
+ <&usb3_phy_0_pipe>, <&usb3_phy_1_pipe>,
+ <&usb3_phy_2_pipe>,
+ <&usb3_uni_phy_pipe_0>, <&usb3_uni_phy_pipe_1>,
+ <&usb4_phy_0_pcie_pipe>, <&usb4_phy_0_max_pipe>,
+ <&usb4_phy_1_pcie_pipe>, <&usb4_phy_1_max_pipe>,
+ <&usb4_phy_2_pcie_pipe>, <&usb4_phy_2_max_pipe>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc-sdm660.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc-sdm660.yaml
index 3f70eb59aae3..79bb90dbe4c1 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc-sdm660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc-sdm660.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/clock/qcom,gpucc-sdm660.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Graphics Clock & Reset Controller Binding for SDM630 and SDM660
+title: Qualcomm Graphics Clock & Reset Controller on SDM630 and SDM660
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
description: |
- Qualcomm graphics clock control module which supports the clocks, resets and
+ Qualcomm graphics clock control module provides the clocks, resets and
power domains on SDM630 and SDM660.
See also dt-bindings/clock/qcom,gpucc-sdm660.h.
@@ -33,28 +33,16 @@ properties:
- const: gcc_gpu_gpll0_clk
- const: gcc_gpu_gpll0_div_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
deleted file mode 100644
index 0a0546c079a9..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml
+++ /dev/null
@@ -1,72 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/qcom,gpucc-sm8350.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Graphics Clock & Reset Controller Binding
-
-maintainers:
- - Robert Foss <robert.foss@linaro.org>
-
-description: |
- Qualcomm graphics clock control module which supports the clocks, resets and
- power domains on Qualcomm SoCs.
-
- See also:
- dt-bindings/clock/qcom,gpucc-sm8350.h
-
-properties:
- compatible:
- enum:
- - qcom,sm8350-gpucc
-
- clocks:
- items:
- - description: Board XO source
- - description: GPLL0 main branch source
- - description: GPLL0 div branch source
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
-required:
- - compatible
- - reg
- - clocks
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sm8350.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
-
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
-
- clock-controller@3d90000 {
- compatible = "qcom,sm8350-gpucc";
- reg = <0 0x03d90000 0 0x9000>;
- clocks = <&rpmhcc RPMH_CXO_CLK>,
- <&gcc GCC_GPU_GPLL0_CLK_SRC>,
- <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- #power-domain-cells = <1>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 9ebcb1943b0a..4cdff6161bf0 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -4,33 +4,42 @@
$id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Graphics Clock & Reset Controller Binding
+title: Qualcomm Graphics Clock & Reset Controller
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Imran Shaik <quic_imrashai@quicinc.com>
description: |
- Qualcomm graphics clock control module which supports the clocks, resets and
- power domains on Qualcomm SoCs.
+ Qualcomm graphics clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
- See also:
- dt-bindings/clock/qcom,gpucc-sdm845.h
- dt-bindings/clock/qcom,gpucc-sc7180.h
- dt-bindings/clock/qcom,gpucc-sc7280.h
- dt-bindings/clock/qcom,gpucc-sm6350.h
- dt-bindings/clock/qcom,gpucc-sm8150.h
- dt-bindings/clock/qcom,gpucc-sm8250.h
+ See also::
+ include/dt-bindings/clock/qcom,gpucc-sdm845.h
+ include/dt-bindings/clock/qcom,gpucc-sa8775p.h
+ include/dt-bindings/clock/qcom,gpucc-sc7180.h
+ include/dt-bindings/clock/qcom,gpucc-sc7280.h
+ include/dt-bindings/clock/qcom,gpucc-sc8280xp.h
+ include/dt-bindings/clock/qcom,gpucc-sm6350.h
+ include/dt-bindings/clock/qcom,gpucc-sm8150.h
+ include/dt-bindings/clock/qcom,gpucc-sm8250.h
+ include/dt-bindings/clock/qcom,gpucc-sm8350.h
+ include/dt-bindings/clock/qcom,qcs8300-gpucc.h
properties:
compatible:
enum:
+ - qcom,qcs8300-gpucc
- qcom,sdm845-gpucc
+ - qcom,sa8775p-gpucc
- qcom,sc7180-gpucc
- qcom,sc7280-gpucc
- qcom,sc8180x-gpucc
+ - qcom,sc8280xp-gpucc
- qcom,sm6350-gpucc
- qcom,sm8150-gpucc
- qcom,sm8250-gpucc
+ - qcom,sm8350-gpucc
clocks:
items:
@@ -44,28 +53,28 @@ properties:
- const: gcc_gpu_gpll0_clk_src
- const: gcc_gpu_gpll0_div_clk_src
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
+ power-domains:
maxItems: 1
+ vdd-gfx-supply:
+ description: Regulator supply for the VDD_GFX pads
+
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+# Require that power-domains and vdd-gfx-supply are not both present
+not:
+ required:
+ - power-domains
+ - vdd-gfx-supply
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
deleted file mode 100644
index ec02a024424c..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-High-Frequency PLL (HFPLL)
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>:
- shall contain only one of the following. The generic
- compatible "qcom,hfpll" should be also included.
-
- "qcom,hfpll-ipq8064", "qcom,hfpll"
- "qcom,hfpll-apq8064", "qcom,hfpll"
- "qcom,hfpll-msm8974", "qcom,hfpll"
- "qcom,hfpll-msm8960", "qcom,hfpll"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: address and size of HPLL registers. An optional second
- element specifies the address and size of the alias
- register region.
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the xo clock.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "xo".
-
-- clock-output-names:
- Usage: required
- Value type: <string>
- Definition: Name of the PLL. Typically hfpllX where X is a CPU number
- starting at 0. Otherwise hfpll_Y where Y is more specific
- such as "l2".
-
-Example:
-
-1) An HFPLL for the L2 cache.
-
- clock-controller@f9016000 {
- compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
- reg = <0xf9016000 0x30>;
- clocks = <&xo_board>;
- clock-names = "xo";
- clock-output-names = "hfpll_l2";
- };
-
-2) An HFPLL for CPU0. This HFPLL has the alias register region.
-
- clock-controller@f908a000 {
- compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
- reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
- clocks = <&xo_board>;
- clock-names = "xo";
- clock-output-names = "hfpll0";
- };
diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.yaml b/Documentation/devicetree/bindings/clock/qcom,hfpll.yaml
new file mode 100644
index 000000000000..8cb1c164f760
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,hfpll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm High-Frequency PLL
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ The HFPLL is used as CPU PLL on various Qualcomm SoCs.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,msm8974-hfpll
+ - qcom,msm8976-hfpll-a53
+ - qcom,msm8976-hfpll-a72
+ - qcom,msm8976-hfpll-cci
+ - qcom,qcs404-hfpll
+ - const: qcom,hfpll
+ deprecated: true
+
+ reg:
+ items:
+ - description: HFPLL registers
+ - description: Alias register region
+ minItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ clocks:
+ items:
+ - description: board XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ clock-output-names:
+ description:
+ Name of the PLL. Typically hfpllX where X is a CPU number starting at 0.
+ Otherwise hfpll_Y where Y is more specific such as "l2".
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+ - clock-output-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@f908a000 {
+ compatible = "qcom,msm8974-hfpll";
+ reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
+ #clock-cells = <0>;
+ clock-output-names = "hfpll0";
+ clocks = <&xo_board>;
+ clock-names = "xo";
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
new file mode 100644
index 000000000000..489d0fc5607c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq5018-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on IPQ5018
+
+maintainers:
+ - Sricharan Ramabadhran <quic_srichara@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ5018
+
+ See also::
+ include/dt-bindings/clock/qcom,ipq5018-gcc.h
+ include/dt-bindings/reset/qcom,ipq5018-gcc.h
+
+properties:
+ compatible:
+ const: qcom,gcc-ipq5018
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE20 PHY0 pipe clock source
+ - description: PCIE20 PHY1 pipe clock source
+ - description: USB3 PHY pipe clock source
+ - description: GEPHY RX clock source
+ - description: GEPHY TX clock source
+ - description: UNIPHY RX clock source
+ - description: UNIPHY TX clk source
+
+ '#power-domain-cells': false
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@1800000 {
+ compatible = "qcom,gcc-ipq5018";
+ reg = <0x01800000 0x80000>;
+ clocks = <&xo_board_clk>,
+ <&sleep_clk>,
+ <&pcie20_phy0_pipe_clk>,
+ <&pcie20_phy1_pipe_clk>,
+ <&usb3_phy0_pipe_clk>,
+ <&gephy_rx_clk>,
+ <&gephy_tx_clk>,
+ <&uniphy_rx_clk>,
+ <&uniphy_tx_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml
new file mode 100644
index 000000000000..1230183fc0a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq5332-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on IPQ5332 and IPQ5424
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ5332 and IPQ5424.
+
+ See also:
+ include/dt-bindings/clock/qcom,gcc-ipq5332.h
+ include/dt-bindings/clock/qcom,gcc-ipq5424.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5332-gcc
+ - qcom,ipq5424-gcc
+
+ clocks:
+ minItems: 5
+ items:
+ - description: Board XO clock source
+ - description: Sleep clock source
+ - description: PCIE 2lane PHY pipe clock source
+ - description: PCIE 2lane x1 PHY pipe clock source (For second lane)
+ - description: USB PCIE wrapper pipe clock source
+ - description: PCIE 2-lane PHY2 pipe clock source
+ - description: PCIE 2-lane PHY3 pipe clock source
+
+ '#power-domain-cells': false
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,ipq5332-gcc
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,ipq5424-gcc
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@1800000 {
+ compatible = "qcom,ipq5332-gcc";
+ reg = <0x01800000 0x80000>;
+ clocks = <&xo_board>,
+ <&sleep_clk>,
+ <&pcie_2lane_phy_pipe_clk>,
+ <&pcie_2lane_phy_pipe_clk_x1>,
+ <&usb_pcie_wrapper_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5424-apss-clk.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5424-apss-clk.yaml
new file mode 100644
index 000000000000..def739fa0a8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5424-apss-clk.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq5424-apss-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm APSS IPQ5424 Clock Controller
+
+maintainers:
+ - Varadarajan Narayanan <quic_varada@quicinc.com>
+
+description:
+ The CPU core in ipq5424 is clocked by a huayra PLL with RCG support.
+ The RCG and PLL have a separate register space from the GCC.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5424-apss-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Reference to the XO clock.
+ - description: Reference to the GPLL0 clock.
+
+ '#clock-cells':
+ const: 1
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#interconnect-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq5424-gcc.h>
+
+ apss_clk: clock-controller@fa80000 {
+ compatible = "qcom,ipq5424-apss-clk";
+ reg = <0x0fa80000 0x20000>;
+ clocks = <&xo_board>,
+ <&gcc GPLL0>;
+ #clock-cells = <1>;
+ #interconnect-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
new file mode 100644
index 000000000000..817d51135fbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq9574-cmn-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm CMN PLL Clock Controller on IPQ SoC
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Luo Jie <quic_luoj@quicinc.com>
+
+description:
+ The CMN (or common) PLL clock controller expects a reference
+ input clock. This reference clock is from the on-board Wi-Fi.
+ The CMN PLL supplies a number of fixed rate output clocks to
+ the devices providing networking functions and to GCC. These
+ networking hardware include PPE (packet process engine), PCS
+ and the externally connected switch or PHY devices. The CMN
+ PLL block also outputs fixed rate clocks to GCC. The PLL's
+ primary function is to enable fixed rate output clocks for
+ networking hardware functions used with the IPQ SoC.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5018-cmn-pll
+ - qcom,ipq5424-cmn-pll
+ - qcom,ipq9574-cmn-pll
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The reference clock. The supported clock rates include
+ 25000000, 31250000, 40000000, 48000000, 50000000 and 96000000 HZ.
+ - description: The AHB clock
+ - description: The SYS clock
+ description:
+ The reference clock is the source clock of CMN PLL, which is from the
+ Wi-Fi. The AHB and SYS clocks must be enabled to access CMN PLL
+ clock registers.
+
+ clock-names:
+ items:
+ - const: ref
+ - const: ahb
+ - const: sys
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq-cmn-pll.h>
+ #include <dt-bindings/clock/qcom,ipq9574-gcc.h>
+
+ cmn_pll: clock-controller@9b000 {
+ compatible = "qcom,ipq9574-cmn-pll";
+ reg = <0x0009b000 0x800>;
+ clocks = <&cmn_pll_ref_clk>,
+ <&gcc GCC_CMN_12GPLL_AHB_CLK>,
+ <&gcc GCC_CMN_12GPLL_SYS_CLK>;
+ clock-names = "ref", "ahb", "sys";
+ #clock-cells = <1>;
+ assigned-clocks = <&cmn_pll CMN_PLL_CLK>;
+ assigned-clock-rates-u64 = /bits/ 64 <12000000000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
new file mode 100644
index 000000000000..27ae9938febc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq9574-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on IPQ9574
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Anusha Rao <quic_anusha@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on IPQ9574
+
+ See also::
+ include/dt-bindings/clock/qcom,ipq9574-gcc.h
+ include/dt-bindings/reset/qcom,ipq9574-gcc.h
+
+properties:
+ compatible:
+ const: qcom,ipq9574-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: Bias PLL ubi clock source
+ - description: PCIE30 PHY0 pipe clock source
+ - description: PCIE30 PHY1 pipe clock source
+ - description: PCIE30 PHY2 pipe clock source
+ - description: PCIE30 PHY3 pipe clock source
+ - description: USB3 PHY pipe clock source
+
+ '#power-domain-cells': false
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-controller@1800000 {
+ compatible = "qcom,ipq9574-gcc";
+ reg = <0x01800000 0x80000>;
+ clocks = <&xo_board_clk>,
+ <&sleep_clk>,
+ <&bias_pll_ubi_nc_clk>,
+ <&pcie30_phy0_pipe_clk>,
+ <&pcie30_phy1_pipe_clk>,
+ <&pcie30_phy2_pipe_clk>,
+ <&pcie30_phy3_pipe_clk>,
+ <&usb3phy_0_cc_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
new file mode 100644
index 000000000000..7ff4ff3587ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,ipq9574-nsscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Networking Sub System Clock & Reset Controller on IPQ9574 and IPQ5424
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Anusha Rao <quic_anusha@quicinc.com>
+
+description: |
+ Qualcomm networking sub system clock control module provides the clocks,
+ resets on IPQ9574 and IPQ5424
+
+ See also:
+ include/dt-bindings/clock/qcom,ipq5424-nsscc.h
+ include/dt-bindings/clock/qcom,ipq9574-nsscc.h
+ include/dt-bindings/reset/qcom,ipq5424-nsscc.h
+ include/dt-bindings/reset/qcom,ipq9574-nsscc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5424-nsscc
+ - qcom,ipq9574-nsscc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: CMN_PLL NSS (Bias PLL cc) clock source. This clock rate
+ can vary for different IPQ SoCs. For example, it is 1200 MHz on the
+ IPQ9574 and 300 MHz on the IPQ5424.
+ - description: CMN_PLL PPE (Bias PLL ubi nc) clock source. The clock
+ rate can vary for different IPQ SoCs. For example, it is 353 MHz
+ on the IPQ9574 and 375 MHz on the IPQ5424.
+ - description: GCC GPLL0 OUT AUX clock source
+ - description: Uniphy0 NSS Rx clock source
+ - description: Uniphy0 NSS Tx clock source
+ - description: Uniphy1 NSS Rx clock source
+ - description: Uniphy1 NSS Tx clock source
+ - description: Uniphy2 NSS Rx clock source
+ - description: Uniphy2 NSS Tx clock source
+ - description: GCC NSSCC clock source
+
+ '#interconnect-cells':
+ const: 1
+
+ clock-names:
+ items:
+ - const: xo
+ - enum:
+ - nss_1200
+ - nss
+ - enum:
+ - ppe_353
+ - ppe
+ - const: gpll0_out
+ - const: uniphy0_rx
+ - const: uniphy0_tx
+ - const: uniphy1_rx
+ - const: uniphy1_tx
+ - const: uniphy2_rx
+ - const: uniphy2_tx
+ - const: bus
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ const: qcom,ipq9574-nsscc
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: xo
+ - const: nss_1200
+ - const: ppe_353
+ - const: gpll0_out
+ - const: uniphy0_rx
+ - const: uniphy0_tx
+ - const: uniphy1_rx
+ - const: uniphy1_tx
+ - const: uniphy2_rx
+ - const: uniphy2_tx
+ - const: bus
+ else:
+ properties:
+ clock-names:
+ items:
+ - const: xo
+ - const: nss
+ - const: ppe
+ - const: gpll0_out
+ - const: uniphy0_rx
+ - const: uniphy0_tx
+ - const: uniphy1_rx
+ - const: uniphy1_tx
+ - const: uniphy2_rx
+ - const: uniphy2_tx
+ - const: bus
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq9574-gcc.h>
+ #include <dt-bindings/clock/qcom,ipq-cmn-pll.h>
+ clock-controller@39b00000 {
+ compatible = "qcom,ipq9574-nsscc";
+ reg = <0x39b00000 0x80000>;
+ clocks = <&xo_board_clk>,
+ <&cmn_pll NSS_1200MHZ_CLK>,
+ <&cmn_pll PPE_353MHZ_CLK>,
+ <&gcc GPLL0_OUT_AUX>,
+ <&uniphy 0>,
+ <&uniphy 1>,
+ <&uniphy 2>,
+ <&uniphy 3>,
+ <&uniphy 4>,
+ <&uniphy 5>,
+ <&gcc GCC_NSSCC_CLK>;
+ clock-names = "xo",
+ "nss_1200",
+ "ppe_353",
+ "gpll0_out",
+ "uniphy0_rx",
+ "uniphy0_tx",
+ "uniphy1_rx",
+ "uniphy1_tx",
+ "uniphy2_rx",
+ "uniphy2_tx",
+ "bus";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #interconnect-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml
new file mode 100644
index 000000000000..57632757d4e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,kpss-acc-v1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) v1
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
+ There is one ACC register region per CPU within the KPSS remapped region as
+ well as an alias register region that remaps accesses to the ACC associated
+ with the CPU accessing the region. ACC v1 is currently used as a
+ clock-controller for enabling the cpu and handling the aux clocks.
+
+properties:
+ compatible:
+ const: qcom,kpss-acc-v1
+
+ reg:
+ items:
+ - description: Base address and size of the register region
+ - description: Optional base address and size of the alias register region
+ minItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pll8_vote
+ - const: pxo
+
+ clock-output-names:
+ description: Name of the aux clock. Krait can have at most 4 cpu.
+ enum:
+ - acpu0_aux
+ - acpu1_aux
+ - acpu2_aux
+ - acpu3_aux
+
+ '#clock-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-output-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+
+ clock-controller@2088000 {
+ compatible = "qcom,kpss-acc-v1";
+ reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
+ clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
+ clock-names = "pll8_vote", "pxo";
+ clock-output-names = "acpu0_aux";
+ #clock-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml
new file mode 100644
index 000000000000..88b7672123a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,kpss-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ Krait Processor Sub-system (KPSS) Global Clock Controller (GCC). Used
+ to control L2 mux (in the current implementation) and provide access
+ to the kpss-gcc registers.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,kpss-gcc-ipq8064
+ - qcom,kpss-gcc-apq8064
+ - qcom,kpss-gcc-msm8974
+ - qcom,kpss-gcc-msm8960
+ - qcom,kpss-gcc-msm8660
+ - qcom,kpss-gcc-mdm9615
+ - const: qcom,kpss-gcc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pll8_vote
+ - const: pxo
+
+ '#clock-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kpss-gcc-ipq8064
+ - qcom,kpss-gcc-apq8064
+ - qcom,kpss-gcc-msm8974
+ - qcom,kpss-gcc-msm8960
+then:
+ required:
+ - clocks
+ - clock-names
+ - '#clock-cells'
+else:
+ properties:
+ clock: false
+ clock-names: false
+ '#clock-cells': false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+
+ clock-controller@2011000 {
+ compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc", "syscon";
+ reg = <0x2011000 0x1000>;
+ clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
+ clock-names = "pll8_vote", "pxo";
+ #clock-cells = <0>;
+ };
+
+ - |
+ clock-controller@2011000 {
+ compatible = "qcom,kpss-gcc-mdm9615", "qcom,kpss-gcc", "syscon";
+ reg = <0x02011000 0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
deleted file mode 100644
index 030ba60dab08..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Krait Clock Controller
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,krait-cc-v1"
- "qcom,krait-cc-v2"
-
-- #clock-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 1
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the clock parents of hfpll, secondary muxes.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb".
-
-Example:
-
- kraitcc: clock-controller {
- compatible = "qcom,krait-cc-v1";
- clocks = <&hfpll0>, <&hfpll1>, <&acpu0_aux>, <&acpu1_aux>, <qsb>;
- clock-names = "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb";
- #clock-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/qcom,krait-cc.yaml b/Documentation/devicetree/bindings/clock/qcom,krait-cc.yaml
new file mode 100644
index 000000000000..d6a019371fcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,krait-cc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,krait-cc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Clock Controller
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,krait-cc-v1
+ - qcom,krait-cc-v2
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: Parent clock phandle for hfpll0
+ - description: Parent clock phandle for hfpll1
+ - description: Parent clock phandle for acpu0_aux
+ - description: Parent clock phandle for acpu1_aux
+ - description: Parent clock phandle for qsb
+
+ clock-names:
+ items:
+ - const: hfpll0
+ - const: hfpll1
+ - const: acpu0_aux
+ - const: acpu1_aux
+ - const: qsb
+
+required:
+ - compatible
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/qcom,lcc.txt b/Documentation/devicetree/bindings/clock/qcom,lcc.txt
deleted file mode 100644
index a3c78aa88038..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,lcc.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Qualcomm LPASS Clock & Reset Controller Binding
-------------------------------------------------
-
-Required properties :
-- compatible : shall contain only one of the following:
-
- "qcom,lcc-msm8960"
- "qcom,lcc-apq8064"
- "qcom,lcc-ipq8064"
- "qcom,lcc-mdm9615"
-
-- reg : shall contain base register location and length
-- #clock-cells : shall contain 1
-- #reset-cells : shall contain 1
-
-Example:
- clock-controller@28000000 {
- compatible = "qcom,lcc-ipq8064";
- reg = <0x28000000 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/qcom,lcc.yaml b/Documentation/devicetree/bindings/clock/qcom,lcc.yaml
new file mode 100644
index 000000000000..55985e562a34
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,lcc.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,lcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm LPASS Clock & Reset Controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,lcc-apq8064
+ - qcom,lcc-ipq8064
+ - qcom,lcc-mdm9615
+ - qcom,lcc-msm8960
+
+ clocks:
+ maxItems: 8
+
+ clock-names:
+ maxItems: 8
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,lcc-apq8064
+ - qcom,lcc-msm8960
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board PXO source
+ - description: PLL 4 Vote clock
+ - description: MI2S codec clock
+ - description: Mic I2S codec clock
+ - description: Mic I2S spare clock
+ - description: Speaker I2S codec clock
+ - description: Speaker I2S spare clock
+ - description: PCM codec clock
+
+ clock-names:
+ items:
+ - const: pxo
+ - const: pll4_vote
+ - const: mi2s_codec_clk
+ - const: codec_i2s_mic_codec_clk
+ - const: spare_i2s_mic_codec_clk
+ - const: codec_i2s_spkr_codec_clk
+ - const: spare_i2s_spkr_codec_clk
+ - const: pcm_codec_clk
+
+ required:
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,lcc-mdm9615
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board CXO source
+ - description: PLL 4 Vote clock
+ - description: MI2S codec clock
+ - description: Mic I2S codec clock
+ - description: Mic I2S spare clock
+ - description: Speaker I2S codec clock
+ - description: Speaker I2S spare clock
+ - description: PCM codec clock
+
+ clock-names:
+ items:
+ - const: cxo
+ - const: pll4_vote
+ - const: mi2s_codec_clk
+ - const: codec_i2s_mic_codec_clk
+ - const: spare_i2s_mic_codec_clk
+ - const: codec_i2s_spkr_codec_clk
+ - const: spare_i2s_spkr_codec_clk
+ - const: pcm_codec_clk
+
+ required:
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ clock-controller@28000000 {
+ compatible = "qcom,lcc-ipq8064";
+ reg = <0x28000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt b/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
deleted file mode 100644
index b9e9787045b9..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,lpasscc.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Qualcomm LPASS Clock Controller Binding
------------------------------------------------
-
-Required properties :
-- compatible : shall contain "qcom,sdm845-lpasscc"
-- #clock-cells : from common clock binding, shall contain 1.
-- reg : shall contain base register address and size,
- in the order
- Index-0 maps to LPASS_CC register region
- Index-1 maps to LPASS_QDSP6SS register region
-
-Optional properties :
-- reg-names : register names of LPASS domain
- "cc", "qdsp6ss".
-
-Example:
-
-The below node has to be defined in the cases where the LPASS peripheral loader
-would bring the subsystem out of reset.
-
- lpasscc: clock-controller@17014000 {
- compatible = "qcom,sdm845-lpasscc";
- reg = <0x17014000 0x1f004>, <0x17300000 0x200>;
- reg-names = "cc", "qdsp6ss";
- #clock-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml
new file mode 100644
index 000000000000..f63149ecf3e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,milos-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on Milos
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on Milos.
+
+ See also: include/dt-bindings/clock/qcom,milos-camcc.h
+
+properties:
+ compatible:
+ const: qcom,milos-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: Camera AHB clock from GCC
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,milos-gcc.h>
+ clock-controller@adb0000 {
+ compatible = "qcom,milos-camcc";
+ reg = <0x0adb0000 0x40000>;
+ clocks = <&bi_tcxo_div2>,
+ <&sleep_clk>,
+ <&gcc GCC_CAMERA_AHB_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-dispcc.yaml
new file mode 100644
index 000000000000..94908804756b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-dispcc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,milos-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on Milos
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on Milos.
+
+ See also: include/dt-bindings/clock/qcom,milos-dispcc.h
+
+properties:
+ compatible:
+ const: qcom,milos-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: Display's AHB clock
+ - description: GPLL0 source from GCC
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: Link clock from DP PHY0
+ - description: VCO DIV clock from DP PHY0
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,milos-gcc.h>
+ #include <dt-bindings/phy/phy-qcom-qmp.h>
+ clock-controller@af00000 {
+ compatible = "qcom,milos-dispcc";
+ reg = <0x0af00000 0x20000>;
+ clocks = <&bi_tcxo_div2>,
+ <&sleep_clk>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>,
+ <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml
new file mode 100644
index 000000000000..cf244c155f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,milos-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on Milos
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on Milos.
+
+ See also: include/dt-bindings/clock/qcom,milos-gcc.h
+
+properties:
+ compatible:
+ const: qcom,milos-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 1 Pipe clock source
+ - description: UFS Phy Rx symbol 0 clock source
+ - description: UFS Phy Rx symbol 1 clock source
+ - description: UFS Phy Tx symbol 0 clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,milos-gcc";
+ reg = <0x00100000 0x1f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&pcie0_phy>,
+ <&pcie1_phy>,
+ <&ufs_mem_phy 0>,
+ <&ufs_mem_phy 1>,
+ <&ufs_mem_phy 2>,
+ <&usb_1_qmpphy>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml
new file mode 100644
index 000000000000..14c31efe1308
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,milos-videocc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,milos-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Video Clock & Reset Controller on Milos
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on Milos.
+
+ See also: include/dt-bindings/clock/qcom,milos-videocc.h
+
+properties:
+ compatible:
+ const: qcom,milos-videocc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+ - description: Video AHB clock from GCC
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,milos-gcc.h>
+ clock-controller@aaf0000 {
+ compatible = "qcom,milos-videocc";
+ reg = <0x0aaf0000 0x10000>;
+ clocks = <&bi_tcxo_div2>,
+ <&bi_tcxo_ao_div2>,
+ <&sleep_clk>,
+ <&gcc GCC_VIDEO_AHB_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
index 32e87014bb55..53ceec9673a8 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/clock/qcom,mmcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Multimedia Clock & Reset Controller Binding
+title: Qualcomm Multimedia Clock & Reset Controller
maintainers:
- Jeffrey Hugo <quic_jhugo@quicinc.com>
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm multimedia clock control module which supports the clocks, resets and
+ Qualcomm multimedia clock control module provides the clocks, resets and
power domains.
properties:
@@ -31,46 +31,12 @@ properties:
- qcom,mmcc-sdm660
clocks:
- items:
- - description: Board XO source
- - description: Board sleep source
- - description: Global PLL 0 clock
- - description: DSI phy instance 0 dsi clock
- - description: DSI phy instance 0 byte clock
- - description: DSI phy instance 1 dsi clock
- - description: DSI phy instance 1 byte clock
- - description: HDMI phy PLL clock
- - description: DisplayPort phy PLL vco clock
- - description: DisplayPort phy PLL link clock
+ minItems: 7
+ maxItems: 13
clock-names:
- items:
- - const: xo
- - const: sleep
- - const: gpll0
- - const: dsi0dsi
- - const: dsi0byte
- - const: dsi1dsi
- - const: dsi1byte
- - const: hdmipll
- - const: dpvco
- - const: dplink
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
- protected-clocks:
- description:
- Protected clock specifier list as per common clock binding
+ minItems: 7
+ maxItems: 13
vdd-gfx-supply:
description:
@@ -78,23 +44,294 @@ properties:
required:
- compatible
- - reg
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,mmcc-apq8064
+ - qcom,mmcc-msm8960
+ then:
+ properties:
+ clocks:
+ minItems: 8
+ items:
+ - description: Board PXO source
+ - description: PLL 3 clock
+ - description: PLL 3 Vote clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: DSI phy instance 2 dsi clock
+ - description: DSI phy instance 2 byte clock
+ - description: HDMI phy PLL clock
+ - description: LVDS PLL clock
+
+ clock-names:
+ minItems: 8
+ items:
+ - const: pxo
+ - const: pll3
+ - const: pll8_vote
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: dsi2pll
+ - const: dsi2pllbyte
+ - const: hdmipll
+ - const: lvdspll
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,mmcc-msm8226
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: MMSS GPLL0 voted clock
+ - description: GPLL0 voted clock
+ - description: GPLL1 voted clock
+ - description: GFX3D clock source
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: mmss_gpll0_vote
+ - const: gpll0_vote
+ - const: gpll1_vote
+ - const: gfx3d_clk_src
+ - const: dsi0pll
+ - const: dsi0pllbyte
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,mmcc-msm8974
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: MMSS GPLL0 voted clock
+ - description: GPLL0 voted clock
+ - description: GPLL1 voted clock
+ - description: GFX3D clock source
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: HDMI phy PLL clock
+ - description: eDP phy PLL link clock
+ - description: eDP phy PLL vco clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: mmss_gpll0_vote
+ - const: gpll0_vote
+ - const: gpll1_vote
+ - const: gfx3d_clk_src
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: hdmipll
+ - const: edp_link_clk
+ - const: edp_vco_div
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,mmcc-apq8084
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board sleep source
+ - description: MMSS GPLL0 voted clock
+ - description: GPLL0 clock
+ - description: GPLL0 voted clock
+ - description: GPLL1 clock
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: HDMI phy PLL clock
+ - description: eDP phy PLL link clock
+ - description: eDP phy PLL vco clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: mmss_gpll0_vote
+ - const: gpll0
+ - const: gpll0_vote
+ - const: gpll1
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: hdmipll
+ - const: edp_link_clk
+ - const: edp_vco_div
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,mmcc-msm8994
+ - qcom,mmcc-msm8998
+ - qcom,mmcc-sdm630
+ - qcom,mmcc-sdm660
+ then:
+ required:
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,mmcc-msm8994
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Global PLL 0 clock
+ - description: MMSS NoC AHB clock
+ - description: GFX3D clock
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: HDMI phy PLL clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: gpll0
+ - const: mmssnoc_ahb
+ - const: oxili_gfx3d_clk_src
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: hdmipll
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,mmcc-msm8996
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Global PLL 0 clock
+ - description: MMSS NoC AHB clock
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: HDMI phy PLL clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: gpll0
+ - const: gcc_mmss_noc_cfg_ahb_clk
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: hdmipll
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,mmcc-msm8998
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Global PLL 0 clock
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: HDMI phy PLL clock
+ - description: DisplayPort phy PLL link clock
+ - description: DisplayPort phy PLL vco clock
+ - description: Global PLL 0 DIV clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: gpll0
+ - const: dsi0dsi
+ - const: dsi0byte
+ - const: dsi1dsi
+ - const: dsi1byte
+ - const: hdmipll
+ - const: dplink
+ - const: dpvco
+ - const: gpll0_div
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,mmcc-sdm630
+ - qcom,mmcc-sdm660
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board sleep source
+ - description: Global PLL 0 clock
+ - description: Global PLL 0 DIV clock
+ - description: DSI phy instance 0 dsi clock
+ - description: DSI phy instance 0 byte clock
+ - description: DSI phy instance 1 dsi clock
+ - description: DSI phy instance 1 byte clock
+ - description: DisplayPort phy PLL link clock
+ - description: DisplayPort phy PLL vco clock
-if:
- properties:
- compatible:
- contains:
- const: qcom,mmcc-msm8998
+ clock-names:
+ items:
+ - const: xo
+ - const: sleep_clk
+ - const: gpll0
+ - const: gpll0_div
+ - const: dsi0pll
+ - const: dsi0pllbyte
+ - const: dsi1pll
+ - const: dsi1pllbyte
+ - const: dp_link_2x_clk_divsel_five
+ - const: dp_vco_divided_clk_src_mux
-then:
- required:
- - clocks
- - clock-names
+unevaluatedProperties: false
examples:
# Example for MMCC for MSM8960:
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml
index a20cb10636dd..fcace96c72eb 100644
--- a/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml
@@ -26,22 +26,20 @@ properties:
clocks:
items:
- - description: Primary PLL clock for power cluster (little)
- - description: Primary PLL clock for perf cluster (big)
- - description: Alternate PLL clock for power cluster (little)
- - description: Alternate PLL clock for perf cluster (big)
+ - description: XO source
+ - description: SYS APCS AUX clock
clock-names:
items:
- - const: pwrcl_pll
- - const: perfcl_pll
- - const: pwrcl_alt_pll
- - const: perfcl_alt_pll
+ - const: xo
+ - const: sys_apcs_aux
required:
- compatible
- reg
- '#clock-cells'
+ - clocks
+ - clock-names
additionalProperties: false
@@ -51,4 +49,7 @@ examples:
compatible = "qcom,msm8996-apcc";
reg = <0x6400000 0x90000>;
#clock-cells = <1>;
+
+ clocks = <&xo_board>, <&apcs_glb>;
+ clock-names = "xo", "sys_apcs_aux";
};
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
new file mode 100644
index 000000000000..0dfbd8c4d465
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-cbf.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,msm8996-cbf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8996 Core Bus Fabric (CBF) clock controller
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description: >
+ The clock controller for the Qualcomm MSM8996 CBF clock, which drives the
+ interconnect between two CPU clusters.
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8996-cbf
+ - qcom,msm8996pro-cbf
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO source
+ - description: SYS APCS AUX clock
+
+ '#clock-cells':
+ const: 0
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#interconnect-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ clock-controller@9a11000 {
+ compatible = "qcom,msm8996-cbf";
+ reg = <0x09a11000 0x10000>;
+ clocks = <&rpmcc RPM_SMD_BB_CLK1>, <&apcs_glb>;
+ #clock-cells = <0>;
+ #interconnect-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml
index d747bb58f0a7..374de7a6f8d9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,msm8998-gpucc.yaml
@@ -4,16 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,msm8998-gpucc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Graphics Clock & Reset Controller Binding for MSM8998
+title: Qualcomm Graphics Clock & Reset Controller on MSM8998
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm graphics clock control module which supports the clocks, resets and
- power domains on MSM8998.
+ Qualcomm graphics clock control module provides the clocks, resets and power
+ domains on MSM8998.
- See also dt-bindings/clock/qcom,gpucc-msm8998.h.
+ See also: include/dt-bindings/clock/qcom,gpucc-msm8998.h
properties:
compatible:
@@ -29,28 +29,16 @@ properties:
- const: xo
- const: gpll0
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml b/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml
index bbaaf1e2a203..e0f4d692728c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml
@@ -7,11 +7,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Q6SSTOP clock Controller
maintainers:
- - Govind Singh <govinds@codeaurora.org>
+ - Bjorn Andersson <andersson@kernel.org>
properties:
compatible:
- const: "qcom,qcs404-q6sstopcc"
+ const: qcom,qcs404-q6sstopcc
reg:
items:
diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
new file mode 100644
index 000000000000..61473385da2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qca8k-nsscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm NSS Clock & Reset Controller on QCA8386/QCA8084
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Luo Jie <quic_luoj@quicinc.com>
+
+description: |
+ Qualcomm NSS clock control module provides the clocks and resets
+ on QCA8386(switch mode)/QCA8084(PHY mode)
+
+ See also::
+ include/dt-bindings/clock/qcom,qca8k-nsscc.h
+ include/dt-bindings/reset/qcom,qca8k-nsscc.h
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,qca8084-nsscc
+ - items:
+ - enum:
+ - qcom,qca8082-nsscc
+ - qcom,qca8085-nsscc
+ - qcom,qca8384-nsscc
+ - qcom,qca8385-nsscc
+ - qcom,qca8386-nsscc
+ - const: qcom,qca8084-nsscc
+
+ clocks:
+ items:
+ - description: Chip reference clock source
+ - description: UNIPHY0 RX 312P5M/125M clock source
+ - description: UNIPHY0 TX 312P5M/125M clock source
+ - description: UNIPHY1 RX 312P5M/125M clock source
+ - description: UNIPHY1 TX 312P5M/125M clock source
+ - description: UNIPHY1 RX 312P5M clock source
+ - description: UNIPHY1 TX 312P5M clock source
+
+ reg:
+ items:
+ - description: MDIO bus address for Clock & Reset Controller register
+
+ reset-gpios:
+ description: GPIO connected to the chip
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - reset-gpios
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@18 {
+ compatible = "qcom,qca8084-nsscc";
+ reg = <0x18>;
+ reset-gpios = <&tlmm 51 GPIO_ACTIVE_LOW>;
+ clocks = <&pcs0_pll>,
+ <&qca8k_uniphy0_rx>,
+ <&qca8k_uniphy0_tx>,
+ <&qca8k_uniphy1_rx>,
+ <&qca8k_uniphy1_tx>,
+ <&qca8k_uniphy1_rx312p5m>,
+ <&qca8k_uniphy1_tx312p5m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml
index 973e408c6268..4a533b45eec2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml
@@ -4,16 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,qcm2290-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock & Reset Controller Binding for qcm2290
+title: Qualcomm Display Clock & Reset Controller on QCM2290
maintainers:
- Loic Poulain <loic.poulain@linaro.org>
description: |
- Qualcomm display clock control module which supports the clocks, resets and
- power domains on qcm2290.
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on qcm2290.
- See also dt-bindings/clock/qcom,dispcc-qcm2290.h.
+ See also: include/dt-bindings/clock/qcom,dispcc-qcm2290.h
properties:
compatible:
@@ -37,28 +37,16 @@ properties:
- const: dsi0_phy_pll_out_byteclk
- const: dsi0_phy_pll_out_dsiclk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
new file mode 100644
index 000000000000..734880805c1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcm2290-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on QCM2290
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm graphics clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also::
+ include/dt-bindings/clock/qcom,qcm2290-gpucc.h
+
+properties:
+ compatible:
+ const: qcom,qcm2290-gpucc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: AHB interface clock,
+ - description: SoC CXO clock
+ - description: GPLL0 main branch source
+ - description: GPLL0 div branch source
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the CX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required CX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-qcm2290.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@5990000 {
+ compatible = "qcom,qcm2290-gpucc";
+ reg = <0x0 0x05990000 0x0 0x9000>;
+ clocks = <&gcc GCC_GPU_CFG_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+ power-domains = <&rpmpd QCM2290_VDDCX>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs404-turingcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs404-turingcc.yaml
new file mode 100644
index 000000000000..033e010754a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcs404-turingcc.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcs404-turingcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Turing Clock & Reset Controller on QCS404
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ const: qcom,qcs404-turingcc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-qcs404.h>
+ clock-controller@800000 {
+ compatible = "qcom,qcs404-turingcc";
+ reg = <0x00800000 0x30000>;
+ clocks = <&gcc GCC_CDSP_CFG_AHB_CLK>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs615-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs615-dispcc.yaml
new file mode 100644
index 000000000000..d566f19beb0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcs615-dispcc.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcs615-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on QCS615
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on QCS615.
+
+ See also: include/dt-bindings/clock/qcom,qcs615-dispcc.h
+
+properties:
+ compatible:
+ const: qcom,qcs615-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 clock source from GCC
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: Pixel clock from DSI PHY1
+ - description: Display port PLL link clock
+ - description: Display port PLL VCO DIV clock
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,qcs615-gcc.h>
+ clock-controller@af00000 {
+ compatible = "qcom,qcs615-dispcc";
+ reg = <0x0af00000 0x20000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>,
+ <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>,
+ <&mdss_dsi1_phy 0>,
+ <&mdss_dp_phy 0>,
+ <&mdss_dp_vco 0>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml
new file mode 100644
index 000000000000..4a828e102d25
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcs615-gcc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcs615-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on QCS615
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on QCS615.
+
+ See also: include/dt-bindings/clock/qcom,qcs615-gcc.h
+
+properties:
+ compatible:
+ const: qcom,qcs615-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+ - const: sleep_clk
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,qcs615-gcc";
+ reg = <0x00100000 0x1f0000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs615-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs615-gpucc.yaml
new file mode 100644
index 000000000000..5f7d83d1a7be
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcs615-gpucc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcs615-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on QCS615
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm graphics clock control module provides clocks, resets and power
+ domains on QCS615 Qualcomm SoCs.
+
+ See also: include/dt-bindings/clock/qcom,qcs615-gpucc.h
+
+properties:
+ compatible:
+ const: qcom,qcs615-gpucc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 main branch source
+ - description: GPLL0 GPUCC div branch source
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,qcs615-gcc.h>
+
+ clock-controller@5090000 {
+ compatible = "qcom,qcs615-gpucc";
+ reg = <0x5090000 0x9000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GPLL0>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs615-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs615-videocc.yaml
new file mode 100644
index 000000000000..f51b69de1047
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcs615-videocc.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcs615-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Video Clock & Reset Controller on QCS615
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm video clock control module provides clocks, resets and power
+ domains on QCS615 Qualcomm SoCs.
+
+ See also: include/dt-bindings/clock/qcom,qcs615-videocc.h
+
+properties:
+ compatible:
+ const: qcom,qcs615-videocc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,qcs615-gcc.h>
+
+ clock-controller@ab00000 {
+ compatible = "qcom,qcs615-videocc";
+ reg = <0xab00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcs8300-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcs8300-gcc.yaml
new file mode 100644
index 000000000000..081bc452081f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcs8300-gcc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcs8300-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Global Clock & Reset Controller on QCS8300
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Imran Shaik <quic_imrashai@quicinc.com>
+
+description: |
+ Qualcomm Technologies, Inc. Global clock control module provides the clocks, resets and
+ power domains on QCS8300
+
+ See also: include/dt-bindings/clock/qcom,qcs8300-gcc.h
+
+properties:
+ compatible:
+ const: qcom,qcs8300-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 1 Pipe clock source
+ - description: PCIE Phy Auxiliary clock source
+ - description: First EMAC controller reference clock
+ - description: UFS Phy Rx symbol 0 clock source
+ - description: UFS Phy Rx symbol 1 clock source
+ - description: UFS Phy Tx symbol 0 clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,qcs8300-gcc";
+ reg = <0x00100000 0xc7018>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&pcie_0_pipe_clk>,
+ <&pcie_1_pipe_clk>,
+ <&pcie_phy_aux_clk>,
+ <&rxc0_ref_clk>,
+ <&ufs_phy_rx_symbol_0_clk>,
+ <&ufs_phy_rx_symbol_1_clk>,
+ <&ufs_phy_tx_symbol_0_clk>,
+ <&usb3_phy_wrapper_gcc_usb30_prim_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,qdu1000-ecpricc.yaml b/Documentation/devicetree/bindings/clock/qcom,qdu1000-ecpricc.yaml
new file mode 100644
index 000000000000..3038307ff2c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qdu1000-ecpricc.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qdu1000-ecpricc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm ECPRI Clock & Reset Controller for QDU1000 and QRU1000
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Imran Shaik <quic_imrashai@quicinc.com>
+
+description: |
+ Qualcomm ECPRI Specification V2.0 Common Public Radio Interface clock control
+ module which supports the clocks, resets on QDU1000 and QRU1000
+
+ See also: include/dt-bindings/clock/qcom,qdu1000-ecpricc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,qdu1000-ecpricc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 source from GCC
+ - description: GPLL1 source from GCC
+ - description: GPLL2 source from GCC
+ - description: GPLL3 source from GCC
+ - description: GPLL4 source from GCC
+ - description: GPLL5 source from GCC
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,qdu1000-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@280000 {
+ compatible = "qcom,qdu1000-ecpricc";
+ reg = <0x00280000 0x31c00>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_ECPRI_CC_GPLL0_CLK_SRC>,
+ <&gcc GCC_ECPRI_CC_GPLL1_EVEN_CLK_SRC>,
+ <&gcc GCC_ECPRI_CC_GPLL2_EVEN_CLK_SRC>,
+ <&gcc GCC_ECPRI_CC_GPLL3_CLK_SRC>,
+ <&gcc GCC_ECPRI_CC_GPLL4_CLK_SRC>,
+ <&gcc GCC_ECPRI_CC_GPLL5_EVEN_CLK_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
new file mode 100644
index 000000000000..2c5a9ef4fe4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qdu1000-gcc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qdu1000-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller for QDU1000 and QRU1000
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Imran Shaik <quic_imrashai@quicinc.com>
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on QDU1000 and QRU1000
+
+ See also: include/dt-bindings/clock/qcom,qdu1000-gcc.h
+
+properties:
+ compatible:
+ const: qcom,qdu1000-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 0 Phy Auxiliary clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,qdu1000-gcc";
+ reg = <0x00100000 0x001f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>,
+ <&pcie_0_pipe_clk>, <&pcie_0_phy_aux_clk>,
+ <&usb3_phy_wrapper_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index d63b45ad06e8..ab97d4b7dba8 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -8,7 +8,7 @@ title: Qualcomm RPM Clock Controller
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
@@ -29,8 +29,12 @@ properties:
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8660
+ - qcom,rpmcc-msm8909
- qcom,rpmcc-msm8916
+ - qcom,rpmcc-msm8917
- qcom,rpmcc-msm8936
+ - qcom,rpmcc-msm8937
+ - qcom,rpmcc-msm8940
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
@@ -40,9 +44,11 @@ properties:
- qcom,rpmcc-msm8998
- qcom,rpmcc-qcm2290
- qcom,rpmcc-qcs404
+ - qcom,rpmcc-sdm429
- qcom,rpmcc-sdm660
- qcom,rpmcc-sm6115
- qcom,rpmcc-sm6125
+ - qcom,rpmcc-sm6375
- const: qcom,rpmcc
'#clock-cells':
@@ -105,7 +111,10 @@ allOf:
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8916
+ - qcom,rpmcc-msm8917
- qcom,rpmcc-msm8936
+ - qcom,rpmcc-msm8937
+ - qcom,rpmcc-msm8940
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
@@ -115,6 +124,7 @@ allOf:
- qcom,rpmcc-msm8998
- qcom,rpmcc-qcm2290
- qcom,rpmcc-qcs404
+ - qcom,rpmcc-sdm429
- qcom,rpmcc-sdm660
- qcom,rpmcc-sm6115
- qcom,rpmcc-sm6125
@@ -135,7 +145,7 @@ examples:
- |
rpm {
rpm-requests {
- compatible = "qcom,rpm-msm8916";
+ compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
clock-controller {
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
index 8fcaf418f84a..3f5f1336262e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/clock/qcom,rpmhcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. RPMh Clocks Bindings
+title: Qualcomm Technologies, Inc. RPMh Clocks
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
Resource Power Manager Hardened (RPMh) manages shared resources on
@@ -17,18 +17,32 @@ description: |
properties:
compatible:
enum:
+ - qcom,glymur-rpmh-clk
+ - qcom,kaanapali-rpmh-clk
+ - qcom,milos-rpmh-clk
+ - qcom,qcs615-rpmh-clk
+ - qcom,qdu1000-rpmh-clk
+ - qcom,sa8775p-rpmh-clk
+ - qcom,sar2130p-rpmh-clk
- qcom,sc7180-rpmh-clk
- qcom,sc7280-rpmh-clk
- qcom,sc8180x-rpmh-clk
- qcom,sc8280xp-rpmh-clk
+ - qcom,sdm670-rpmh-clk
- qcom,sdm845-rpmh-clk
- qcom,sdx55-rpmh-clk
- qcom,sdx65-rpmh-clk
+ - qcom,sdx75-rpmh-clk
+ - qcom,sm4450-rpmh-clk
- qcom,sm6350-rpmh-clk
- qcom,sm8150-rpmh-clk
- qcom,sm8250-rpmh-clk
- qcom,sm8350-rpmh-clk
- qcom,sm8450-rpmh-clk
+ - qcom,sm8550-rpmh-clk
+ - qcom,sm8650-rpmh-clk
+ - qcom,sm8750-rpmh-clk
+ - qcom,x1e80100-rpmh-clk
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml
new file mode 100644
index 000000000000..f42ccb6627a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sa8775p-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SA8775P
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+ - Imran Shaik <quic_imrashai@quicinc.com>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SA8775p.
+
+ See also:
+ include/dt-bindings/clock/qcom,qcs8300-camcc.h
+ include/dt-bindings/clock/qcom,sa8775p-camcc.h
+ include/dt-bindings/clock/qcom,sc8280xp-camcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs8300-camcc
+ - qcom,sa8775p-camcc
+ - qcom,sc8280xp-camcc
+
+ clocks:
+ items:
+ - description: Camera AHB clock from GCC
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+
+ power-domains:
+ maxItems: 1
+ description: MMCX power domain
+
+ required-opps:
+ description:
+ OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sc8280xp-camcc
+ then:
+ required:
+ - required-opps
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ clock-controller@ade0000 {
+ compatible = "qcom,sa8775p-camcc";
+ reg = <0x0ade0000 0x20000>;
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd SA8775P_MMCX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-dispcc.yaml
new file mode 100644
index 000000000000..ce61755e62d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-dispcc.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sa8775p-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on SA8775P
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SA8775P.
+
+ See also: include/dt-bindings/clock/qcom,sa8775p-dispcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sa8775p-dispcc0
+ - qcom,sa8775p-dispcc1
+
+ clocks:
+ items:
+ - description: GCC AHB clock source
+ - description: Board XO source
+ - description: Board XO_AO source
+ - description: Sleep clock source
+ - description: Link clock from DP0 PHY
+ - description: VCO DIV clock from DP0 PHY
+ - description: Link clock from DP1 PHY
+ - description: VCO DIV clock from DP1 PHY
+ - description: Byte clock from DSI0 PHY
+ - description: Pixel clock from DSI0 PHY
+ - description: Byte clock from DSI1 PHY
+ - description: Pixel clock from DSI1 PHY
+
+ power-domains:
+ maxItems: 1
+ description: MMCX power domain
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sa8775p-dispcc0";
+ reg = <0x0af00000 0x20000>;
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>,
+ <&dp_phy0 0>,
+ <&dp_phy0 1>,
+ <&dp_phy1 2>,
+ <&dp_phy1 3>,
+ <&dsi_phy0 0>,
+ <&dsi_phy0 1>,
+ <&dsi_phy1 2>,
+ <&dsi_phy1 3>;
+ power-domains = <&rpmhpd SA8775P_MMCX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml
new file mode 100644
index 000000000000..c641aac8c451
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-gcc.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sa8775p-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on sa8775p
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and
+ power domains on sa8775p.
+
+ See also: include/dt-bindings/clock/qcom,sa8775p-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sa8775p-gcc
+
+ clocks:
+ items:
+ - description: XO reference clock
+ - description: Sleep clock
+ - description: UFS memory first RX symbol clock
+ - description: UFS memory second RX symbol clock
+ - description: UFS memory first TX symbol clock
+ - description: UFS card first RX symbol clock
+ - description: UFS card second RX symbol clock
+ - description: UFS card first TX symbol clock
+ - description: Primary USB3 PHY wrapper pipe clock
+ - description: Secondary USB3 PHY wrapper pipe clock
+ - description: PCIe 0 pipe clock
+ - description: PCIe 1 pipe clock
+ - description: PCIe PHY clock
+ - description: First EMAC controller reference clock
+ - description: Second EMAC controller reference clock
+
+ protected-clocks:
+ maxItems: 240
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ gcc: clock-controller@100000 {
+ compatible = "qcom,sa8775p-gcc";
+ reg = <0x100000 0xc7018>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&ufs_phy_rx_symbol_0_clk>,
+ <&ufs_phy_rx_symbol_1_clk>,
+ <&ufs_phy_tx_symbol_0_clk>,
+ <&ufs_card_rx_symbol_0_clk>,
+ <&ufs_card_rx_symbol_1_clk>,
+ <&ufs_card_tx_symbol_0_clk>,
+ <&usb_0_ssphy>,
+ <&usb_1_ssphy>,
+ <&pcie_0_pipe_clk>,
+ <&pcie_1_pipe_clk>,
+ <&pcie_phy_pipe_clk>,
+ <&rxc0_ref_clk>,
+ <&rxc1_ref_clk>;
+ power-domains = <&rpmhpd SA8775P_CX>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml
new file mode 100644
index 000000000000..07e5d811d816
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sa8775p-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Video Clock & Reset Controller on SA8775P
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on SA8775P.
+
+ See also: include/dt-bindings/clock/qcom,sa8775p-videocc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs8300-videocc
+ - qcom,sa8775p-videocc
+
+ clocks:
+ items:
+ - description: Video AHB clock from GCC
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep Clock source
+
+ power-domains:
+ maxItems: 1
+ description: MMCX power domain
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ videocc: clock-controller@abf0000 {
+ compatible = "qcom,sa8775p-videocc";
+ reg = <0x0abf0000 0x10000>;
+ clocks = <&gcc GCC_VIDEO_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd SA8775P_MMCX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sar2130p-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sar2130p-gcc.yaml
new file mode 100644
index 000000000000..9a430bbd872a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sar2130p-gcc.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sar2130p-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on sar2130p
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and
+ power domains on sar2130p.
+
+ See also: include/dt-bindings/clock/qcom,sar2130p-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sar2130p-gcc
+
+ clocks:
+ items:
+ - description: XO reference clock
+ - description: Sleep clock
+ - description: PCIe 0 pipe clock
+ - description: PCIe 1 pipe clock
+ - description: Primary USB3 PHY wrapper pipe clock
+
+ protected-clocks:
+ maxItems: 240
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ gcc: clock-controller@100000 {
+ compatible = "qcom,sar2130p-gcc";
+ reg = <0x100000 0x1f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>,
+ <&pcie_0_pipe_clk>,
+ <&pcie_1_pipe_clk>,
+ <&usb_0_ssphy>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
index f49027edfc44..98ee9be84794 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
@@ -4,17 +4,19 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7180-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Camera Clock & Reset Controller Binding for SC7180
+title: Qualcomm Camera Clock & Reset Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm camera clock control module which supports the clocks, resets and
- power domains on SC7180.
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SC7180.
- See also:
- - dt-bindings/clock/qcom,camcc-sc7180.h
+ See also: include/dt-bindings/clock/qcom,camcc-sc7180.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
@@ -32,28 +34,15 @@ properties:
- const: iface
- const: xo
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
reg:
maxItems: 1
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
index e94847f92770..f147d06ad2ef 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-dispcc.yaml
@@ -4,16 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7180-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock & Reset Controller Binding for SC7180
+title: Qualcomm Display Clock & Reset Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm display clock control module which supports the clocks, resets and
- power domains on SC7180.
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SC7180.
- See also dt-bindings/clock/qcom,dispcc-sc7180.h.
+ See also: include/dt-bindings/clock/qcom,dispcc-sc7180.h
properties:
compatible:
@@ -37,28 +37,16 @@ properties:
- const: dp_phy_pll_link_clk
- const: dp_phy_pll_vco_div_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
index c54172fbf29f..ad360debef7c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7180-lpasscorecc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm LPASS Core Clock Controller Binding for SC7180
+title: Qualcomm LPASS Core Clock Controller on SC7180
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm LPASS core clock control module which supports the clocks and
- power domains on SC7180.
+ Qualcomm LPASS core clock control module provides the clocks and power
+ domains on SC7180.
- See also:
- - dt-bindings/clock/qcom,lpasscorecc-sc7180.h
+ See also: include/dt-bindings/clock/qcom,lpasscorecc-sc7180.h
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
deleted file mode 100644
index 970030986a86..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
+++ /dev/null
@@ -1,62 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/qcom,sc7180-mss.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Modem Clock Controller Binding for SC7180
-
-maintainers:
- - Taniya Das <tdas@codeaurora.org>
-
-description: |
- Qualcomm modem clock control module which supports the clocks on SC7180.
-
- See also:
- - dt-bindings/clock/qcom,mss-sc7180.h
-
-properties:
- compatible:
- const: qcom,sc7180-mss
-
- clocks:
- items:
- - description: gcc_mss_mfab_axi clock from GCC
- - description: gcc_mss_nav_axi clock from GCC
- - description: gcc_mss_cfg_ahb clock from GCC
-
- clock-names:
- items:
- - const: gcc_mss_mfab_axis
- - const: gcc_mss_nav_axi
- - const: cfg_ahb
-
- '#clock-cells':
- const: 1
-
- reg:
- maxItems: 1
-
-required:
- - compatible
- - reg
- - clocks
- - '#clock-cells'
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sc7180.h>
- clock-controller@41a8000 {
- compatible = "qcom,sc7180-mss";
- reg = <0x041a8000 0x8000>;
- clocks = <&gcc GCC_MSS_MFAB_AXIS_CLK>,
- <&gcc GCC_MSS_NAV_AXI_CLK>,
- <&gcc GCC_MSS_CFG_AHB_CLK>;
- clock-names = "gcc_mss_mfab_axis",
- "gcc_mss_nav_axi",
- "cfg_ahb";
- #clock-cells = <1>;
- };
-...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
index f27ca6f03ffa..2f28be58e82e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-camcc.yaml
@@ -4,16 +4,19 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7280-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Camera Clock & Reset Controller Binding for SC7280
+title: Qualcomm Camera Clock & Reset Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm camera clock control module which supports the clocks, resets and
+ Qualcomm camera clock control module provides the clocks, resets and
power domains on SC7280.
- See also dt-bindings/clock/qcom,camcc-sc7280.h
+ See also: include/dt-bindings/clock/qcom,camcc-sc7280.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
@@ -31,28 +34,15 @@ properties:
- const: bi_tcxo_ao
- const: sleep_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
reg:
maxItems: 1
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml
index 2178666fb697..95b1e4f48c4f 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml
@@ -4,16 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7280-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock & Reset Controller Binding for SC7280
+title: Qualcomm Display Clock & Reset Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm display clock control module which supports the clocks, resets and
- power domains on SC7280.
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SC7280.
- See also dt-bindings/clock/qcom,dispcc-sc7280.h.
+ See also: include/dt-bindings/clock/qcom,dispcc-sc7280.h
properties:
compatible:
@@ -41,28 +41,16 @@ properties:
- const: edp_phy_pll_link_clk
- const: edp_phy_pll_vco_div_clk
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml
index 633887dc2f8a..a90961d8656c 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7280-lpasscc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm LPASS Core Clock Controller Binding for SC7280
+title: Qualcomm LPASS Core Clock Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm LPASS core clock control module which supports the clocks and
- power domains on SC7280.
+ Qualcomm LPASS core clock control module provides the clocks and power
+ domains on SC7280.
- See also:
- - dt-bindings/clock/qcom,lpass-sc7280.h
+ See also: include/dt-bindings/clock/qcom,lpass-sc7280.h
properties:
compatible:
@@ -42,6 +41,12 @@ properties:
- const: qdsp6ss
- const: top_cc
+ qcom,adsp-pil-mode:
+ description:
+ Indicates if the LPASS would be brought out of reset using
+ remoteproc peripheral loader.
+ type: boolean
+
required:
- compatible
- reg
@@ -61,6 +66,7 @@ examples:
reg-names = "qdsp6ss", "top_cc";
clocks = <&gcc GCC_CFG_NOC_LPASS_CLK>;
clock-names = "iface";
+ qcom,adsp-pil-mode;
#clock-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
index f50e284e5f46..99ab9106009f 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -4,39 +4,46 @@
$id: http://devicetree.org/schemas/clock/qcom,sc7280-lpasscorecc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm LPASS Core & Audio Clock Controller Binding for SC7280
+title: Qualcomm LPASS Core & Audio Clock Controller on SC7280
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm LPASS core and audio clock control module which supports the
- clocks and power domains on SC7280.
+ Qualcomm LPASS core and audio clock control module provides the clocks and
+ power domains on SC7280.
- See also:
- - dt-bindings/clock/qcom,lpasscorecc-sc7280.h
- - dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
+ See also::
+ include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
+ include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
properties:
- clocks: true
-
- clock-names: true
-
- reg: true
-
compatible:
enum:
+ - qcom,qcm6490-lpassaudiocc
- qcom,sc7280-lpassaoncc
- qcom,sc7280-lpassaudiocc
- qcom,sc7280-lpasscorecc
- qcom,sc7280-lpasshm
- power-domains:
- maxItems: 1
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
'#clock-cells':
const: 1
+ power-domains:
+ maxItems: 1
+
'#power-domain-cells':
const: 1
@@ -57,14 +64,14 @@ required:
- '#clock-cells'
- '#power-domain-cells'
-additionalProperties: false
-
allOf:
- if:
properties:
compatible:
contains:
- const: qcom,sc7280-lpassaudiocc
+ enum:
+ - qcom,qcm6490-lpassaudiocc
+ - qcom,sc7280-lpassaudiocc
then:
properties:
@@ -125,6 +132,9 @@ allOf:
reg:
maxItems: 1
+
+additionalProperties: false
+
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8180x-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8180x-camcc.yaml
new file mode 100644
index 000000000000..477ee687520e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8180x-camcc.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sc8180x-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SC8180X
+
+maintainers:
+ - Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and
+ power domains on SC8180X.
+
+ See also: include/dt-bindings/clock/qcom,sc8180x-camcc.h
+
+properties:
+ compatible:
+ const: qcom,sc8180x-camcc
+
+ clocks:
+ items:
+ - description: Camera AHB clock from GCC
+ - description: Board XO source
+ - description: Sleep clock source
+
+ power-domains:
+ maxItems: 1
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+
+ required-opps:
+ maxItems: 1
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - required-opps
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8180x.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ clock-controller@ad00000 {
+ compatible = "qcom,sc8180x-camcc";
+ reg = <0x0ad00000 0x20000>;
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd SC8180X_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
new file mode 100644
index 000000000000..273d66e245c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sc8280xp-lpasscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm LPASS Core & Audio Clock Controller on SC8280XP
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Qualcomm LPASS core and audio clock control module provides the clocks,
+ and reset on SC8280XP.
+
+ See also::
+ include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,sc8280xp-lpassaudiocc
+ - qcom,sc8280xp-lpasscc
+ - items:
+ - const: qcom,x1e80100-lpassaudiocc
+ - const: qcom,sc8280xp-lpassaudiocc
+ - items:
+ - const: qcom,x1e80100-lpasscc
+ - const: qcom,sc8280xp-lpasscc
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sc8280xp-lpasscc.h>
+ lpass_audiocc: clock-controller@32a9000 {
+ compatible = "qcom,sc8280xp-lpassaudiocc";
+ reg = <0x032a9000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/clock/qcom,sc8280xp-lpasscc.h>
+ lpasscc: clock-controller@33e0000 {
+ compatible = "qcom,sc8280xp-lpasscc";
+ reg = <0x033e0000 0x12000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml
index d4239ccae917..6214e41eec1f 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml
@@ -4,20 +4,27 @@
$id: http://devicetree.org/schemas/clock/qcom,sdm845-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Camera Clock & Reset Controller Binding for SDM845
+title: Qualcomm Camera Clock & Reset Controller on SDM845
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
- Qualcomm camera clock control module which supports the clocks, resets and
- power domains on SDM845.
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SDM845.
- See also dt-bindings/clock/qcom,camcc-sm845.h
+ See also: include/dt-bindings/clock/qcom,camcc-sm845.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
properties:
compatible:
- const: qcom,sdm845-camcc
+ oneOf:
+ - items:
+ - const: qcom,sdm670-camcc
+ - const: qcom,sdm845-camcc
+ - const: qcom,sdm845-camcc
clocks:
items:
@@ -27,28 +34,15 @@ properties:
items:
- const: bi_tcxo
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
reg:
maxItems: 1
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
index 4a3be733d042..854c391c8307 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-dispcc.yaml
@@ -4,16 +4,16 @@
$id: http://devicetree.org/schemas/clock/qcom,sdm845-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Display Clock & Reset Controller Binding for SDM845
+title: Qualcomm Display Clock & Reset Controller on SDM845
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm display clock control module which supports the clocks, resets and
- power domains on SDM845.
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SDM845.
- See also dt-bindings/clock/qcom,dispcc-sdm845.h.
+ See also: include/dt-bindings/clock/qcom,dispcc-sdm845.h
properties:
compatible:
@@ -46,28 +46,16 @@ properties:
- const: dp_link_clk_divsel_ten
- const: dp_vco_divided_clk_src_mux
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-lpasscc.yaml
new file mode 100644
index 000000000000..f9feb7049b21
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-lpasscc.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sdm845-lpasscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM845 LPASS Clock Controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Qualcomm SDM845 LPASS (Low Power Audio SubSystem) Clock Controller.
+
+ See also: include/dt-bindings/clock/qcom,lpass-sdm845.h
+
+properties:
+ compatible:
+ const: qcom,sdm845-lpasscc
+
+ '#clock-cells':
+ const: 1
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cc
+ - const: qdsp6ss
+
+required:
+ - compatible
+ - '#clock-cells'
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@17014000 {
+ compatible = "qcom,sdm845-lpasscc";
+ reg = <0x17014000 0x1f004>, <0x17300000 0x200>;
+ reg-names = "cc", "qdsp6ss";
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml
new file mode 100644
index 000000000000..29a0b29bcb81
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sdx75-gcc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sdx75-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SDX75
+
+maintainers:
+ - Imran Shaik <quic_imrashai@quicinc.com>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SDX75
+
+ See also: include/dt-bindings/clock/qcom,sdx75-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sdx75-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: EMAC0 sgmiiphy mac rclk source
+ - description: EMAC0 sgmiiphy mac tclk source
+ - description: EMAC0 sgmiiphy rclk source
+ - description: EMAC0 sgmiiphy tclk source
+ - description: EMAC1 sgmiiphy mac rclk source
+ - description: EMAC1 sgmiiphy mac tclk source
+ - description: EMAC1 sgmiiphy rclk source
+ - description: EMAC1 sgmiiphy tclk source
+ - description: PCIE20 phy aux clock source
+ - description: PCIE_1 Pipe clock source
+ - description: PCIE_2 Pipe clock source
+ - description: PCIE Pipe clock source
+ - description: USB3 phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@80000 {
+ compatible = "qcom,sdx75-gcc";
+ reg = <0x80000 0x1f7400>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>, <&emac0_sgmiiphy_mac_rclk>,
+ <&emac0_sgmiiphy_mac_tclk>, <&emac0_sgmiiphy_rclk>, <&emac0_sgmiiphy_tclk>,
+ <&emac1_sgmiiphy_mac_rclk>, <&emac1_sgmiiphy_mac_tclk>, <&emac1_sgmiiphy_rclk>,
+ <&emac1_sgmiiphy_tclk>, <&pcie20_phy_aux_clk>, <&pcie_1_pipe_clk>,
+ <&pcie_2_pipe_clk>, <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm4450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm4450-camcc.yaml
new file mode 100644
index 000000000000..70f025b26736
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm4450-camcc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm4450-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SM4450
+
+maintainers:
+ - Ajit Pandey <quic_ajipan@quicinc.com>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SM4450
+
+ See also: include/dt-bindings/clock/qcom,sm4450-camcc.h
+
+properties:
+ compatible:
+ const: qcom,sm4450-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Camera AHB clock source from GCC
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm4450-gcc.h>
+ clock-controller@ade0000 {
+ compatible = "qcom,sm4450-camcc";
+ reg = <0x0ade0000 0x20000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_CAMERA_AHB_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm4450-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm4450-dispcc.yaml
new file mode 100644
index 000000000000..d977788bdc8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm4450-dispcc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm4450-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on SM4450
+
+maintainers:
+ - Ajit Pandey <quic_ajipan@quicinc.com>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM4450
+
+ See also: include/dt-bindings/clock/qcom,sm4450-dispcc.h
+
+properties:
+ compatible:
+ const: qcom,sm4450-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Display AHB clock source from GCC
+ - description: sleep clock source
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm4450-gcc.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sm4450-dispcc";
+ reg = <0x0af00000 0x20000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&sleep_clk>,
+ <&dsi0_phy_pll_out_byteclk>,
+ <&dsi0_phy_pll_out_dsiclk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm4450-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm4450-gcc.yaml
new file mode 100644
index 000000000000..9cfe859bacc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm4450-gcc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm4450-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SM4450
+
+maintainers:
+ - Ajit Pandey <quic_ajipan@quicinc.com>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM4450
+
+ See also: include/dt-bindings/clock/qcom,sm4450-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sm4450-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: UFS Phy Rx symbol 0 clock source
+ - description: UFS Phy Rx symbol 1 clock source
+ - description: UFS Phy Tx symbol 0 clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,sm4450-gcc";
+ reg = <0x00100000 0x001f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>,
+ <&ufs_mem_phy 0>, <&ufs_mem_phy 1>,
+ <&ufs_mem_phy 2>, <&usb_1_qmpphy>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-dispcc.yaml
new file mode 100644
index 000000000000..b31424306f49
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-dispcc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6115-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock Controller for SM6115
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Qualcomm display clock control module provides the clocks and power domains
+ on SM6115.
+
+ See also: include/dt-bindings/clock/qcom,sm6115-dispcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6115-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board sleep clock
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: GPLL0 DISP DIV clock from GCC
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6115.h>
+ clock-controller@5f00000 {
+ compatible = "qcom,sm6115-dispcc";
+ reg = <0x5f00000 0x20000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&sleep_clk>,
+ <&dsi0_phy 0>,
+ <&dsi0_phy 1>,
+ <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml
new file mode 100644
index 000000000000..104ba10ca573
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6115-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on SM6115
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm graphics clock control module provides clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also: include/dt-bindings/clock/qcom,sm6115-gpucc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6115-gpucc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 main branch source
+ - description: GPLL0 main div source
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm6115.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ clock-controller@5990000 {
+ compatible = "qcom,sm6115-gpucc";
+ reg = <0x05990000 0x9000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
new file mode 100644
index 000000000000..8cbab3fbb660
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6115-lpasscc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm LPASS Core & Audio Clock Controller on SM6115
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Qualcomm LPASS core and audio clock controllers provide audio-related resets
+ on SM6115 and its derivatives.
+
+ See also::
+ include/dt-bindings/clock/qcom,sm6115-lpasscc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6115-lpassaudiocc
+ - qcom,sm6115-lpasscc
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ lpass_audiocc: clock-controller@a6a9000 {
+ compatible = "qcom,sm6115-lpassaudiocc";
+ reg = <0x0a6a9000 0x1000>;
+ #reset-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml
new file mode 100644
index 000000000000..12d6f0cdbcd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6125-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on SM6125
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm graphics clock control module provides clocks and power domains on
+ Qualcomm SoCs.
+
+ See also: include/dt-bindings/clock/qcom,sm6125-gpucc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6125-gpucc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 main branch source
+
+ '#clock-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm6125.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ clock-controller@5990000 {
+ compatible = "qcom,sm6125-gpucc";
+ reg = <0x05990000 0x9000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml
new file mode 100644
index 000000000000..e31cd4300f7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6350-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SM6350
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SM6350 and QCS615 SoC.
+
+ See also:
+ include/dt-bindings/clock/qcom,qcs615-camcc.h
+ include/dt-bindings/clock/qcom,sm6350-camcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs615-camcc
+ - qcom,sm6350-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@ad00000 {
+ compatible = "qcom,sm6350-camcc";
+ reg = <0x0ad00000 0x16000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-dispcc.yaml
new file mode 100644
index 000000000000..519ea76cb052
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-dispcc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6375-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller on SM6375
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM6375.
+
+ See also: include/dt-bindings/clock/qcom,dispcc-sm6375.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6375-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 source from GCC
+ - description: Byte clock from DSI PHY
+ - description: Pixel clock from DSI PHY
+
+required:
+ - compatible
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm6375-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ clock-controller@5f00000 {
+ compatible = "qcom,sm6375-dispcc";
+ reg = <0x05f00000 0x20000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_DISP_GPLL0_CLK_SRC>,
+ <&dsi_phy 0>,
+ <&dsi_phy 1>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-gcc.yaml
new file mode 100644
index 000000000000..66dfa72fa975
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-gcc.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6375-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SM6375
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM6375
+
+ See also: include/dt-bindings/clock/qcom,sm6375-gcc.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6375-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board XO Active-Only source
+ - description: Sleep clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ clock-controller@1400000 {
+ compatible = "qcom,sm6375-gcc";
+ reg = <0x01400000 0x1f0000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&rpmcc RPM_SMD_XO_A_CLK_SRC>,
+ <&sleep_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml
new file mode 100644
index 000000000000..3aad6b5bb1c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm6375-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on SM6375
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm graphics clock control module provides clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also: include/dt-bindings/clock/qcom,sm6375-gpucc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6375-gpucc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 main branch source
+ - description: GPLL0 div branch source
+ - description: SNoC DVM GFX source
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the VDD_GX power rail
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required VDD_GX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - required-opps
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm6375-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@5990000 {
+ compatible = "qcom,sm6375-gpucc";
+ reg = <0 0x05990000 0 0x9000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>,
+ <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>;
+ power-domains = <&rpmpd SM6375_VDDGX>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm7150-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm7150-camcc.yaml
new file mode 100644
index 000000000000..b96091c28c5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm7150-camcc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm7150-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SM7150
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+ - David Wronek <david@mainlining.org>
+ - Jens Reidel <adrian@travitia.xyz>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SM7150.
+
+ See also: include/dt-bindings/clock/qcom,sm7150-camcc.h
+
+properties:
+ compatible:
+ const: qcom,sm7150-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board XO Active-Only source
+ - description: Sleep clock source
+
+ power-domains:
+ maxItems: 1
+ description:
+ CX power domain.
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ clock-controller@ad00000 {
+ compatible = "qcom,sm7150-camcc";
+ reg = <0xad00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm7150-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm7150-dispcc.yaml
new file mode 100644
index 000000000000..13ab3359b592
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm7150-dispcc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm7150-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller for SM7150
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+ - David Wronek <david@mainlining.org>
+ - Jens Reidel <adrian@travitia.xyz>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM7150.
+
+ See also: include/dt-bindings/clock/qcom,sm7150-dispcc.h
+
+properties:
+ compatible:
+ const: qcom,sm7150-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board Always On XO source
+ - description: GPLL0 source from GCC
+ - description: Sleep clock source
+ - description: Byte clock from MDSS DSI PHY0
+ - description: Pixel clock from MDSS DSI PHY0
+ - description: Byte clock from MDSS DSI PHY1
+ - description: Pixel clock from MDSS DSI PHY1
+ - description: Link clock from DP PHY
+ - description: VCO DIV clock from DP PHY
+
+ power-domains:
+ maxItems: 1
+ description:
+ CX power domain.
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm7150-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sm7150-dispcc";
+ reg = <0x0af00000 0x200000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&gcc GCC_DISP_GPLL0_CLK_SRC>,
+ <&sleep_clk>,
+ <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>,
+ <&mdss_dsi1_phy 0>,
+ <&mdss_dsi1_phy 1>,
+ <&dp_phy 0>,
+ <&dp_phy 1>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml
new file mode 100644
index 000000000000..3878808f811e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm7150-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SM7150
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Danila Tikhonov <danila@jiaxyga.com>
+ - David Wronek <davidwronek@gmail.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM7150
+
+ See also: include/dt-bindings/clock/qcom,sm7150-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sm7150-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board XO Active-Only source
+ - description: Sleep clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,sm7150-gcc";
+ reg = <0x00100000 0x001f0000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm7150-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm7150-videocc.yaml
new file mode 100644
index 000000000000..9f7928730386
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm7150-videocc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm7150-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Video Clock & Reset Controller on SM7150
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+ - David Wronek <david@mainlining.org>
+ - Jens Reidel <adrian@travitia.xyz>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on SM7150.
+
+ See also: include/dt-bindings/clock/qcom,videocc-sm7150.h
+
+properties:
+ compatible:
+ const: qcom,sm7150-videocc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board Always On XO source
+
+ power-domains:
+ maxItems: 1
+ description:
+ CX power domain.
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ videocc: clock-controller@ab00000 {
+ compatible = "qcom,sm7150-videocc";
+ reg = <0x0ab00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8150-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8150-camcc.yaml
new file mode 100644
index 000000000000..a55e30a4975e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8150-camcc.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8150-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on SM8150
+
+maintainers:
+ - Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and
+ power domains on SM8150.
+
+ See also: include/dt-bindings/clock/qcom,sm8150-camcc.h
+
+properties:
+ compatible:
+ const: qcom,sm8150-camcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Camera AHB clock from GCC
+
+ power-domains:
+ maxItems: 1
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+
+ required-opps:
+ maxItems: 1
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - required-opps
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ clock-controller@ad00000 {
+ compatible = "qcom,sm8150-camcc";
+ reg = <0x0ad00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_CAMERA_AHB_CLK>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
new file mode 100644
index 000000000000..5c2ecec0624e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8350-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 Video Clock & Reset Controller
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also::
+ include/dt-bindings/clock/qcom,videocc-sm8350.h
+ include/dt-bindings/reset/qcom,videocc-sm8350.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-videocc
+ - qcom,sm8350-videocc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Board sleep clock
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - required-opps
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ clock-controller@abf0000 {
+ compatible = "qcom,sm8350-videocc";
+ reg = <0x0abf0000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
index 268f4c6ae0ee..c1e06f39431e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
@@ -4,20 +4,28 @@
$id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Camera Clock & Reset Controller Binding for SM8450
+title: Qualcomm Camera Clock & Reset Controller on SM8450
maintainers:
- Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
+ - Jagadeesh Kona <quic_jkona@quicinc.com>
description: |
- Qualcomm camera clock control module which supports the clocks, resets and
- power domains on SM8450.
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on SM8450.
- See also include/dt-bindings/clock/qcom,sm8450-camcc.h
+ See also:
+ include/dt-bindings/clock/qcom,sm8450-camcc.h
+ include/dt-bindings/clock/qcom,sm8550-camcc.h
+ include/dt-bindings/clock/qcom,sm8650-camcc.h
properties:
compatible:
- const: qcom,sm8450-camcc
+ enum:
+ - qcom,sm8450-camcc
+ - qcom,sm8475-camcc
+ - qcom,sm8550-camcc
+ - qcom,sm8650-camcc
clocks:
items:
@@ -27,43 +35,48 @@ properties:
- description: Sleep clock source
power-domains:
- maxItems: 1
description:
- A phandle and PM domain specifier for the MMCX power domain.
+ Power domains required for the clock controller to operate
+ items:
+ - description: MMCX power domain
+ - description: MXC power domain
required-opps:
description:
- A phandle to an OPP node describing required MMCX performance point.
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
+ OPP nodes that describe required performance points on power domains
+ items:
+ - description: MMCX performance point
+ - description: MXC performance point
reg:
maxItems: 1
required:
- compatible
- - reg
- clocks
- power-domains
- - required-opps
- - '#clock-cells'
- - '#reset-cells'
- - '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-camcc
+ - qcom,sm8450-camcc
+ - qcom,sm8550-camcc
+ then:
+ required:
+ - required-opps
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@ade0000 {
compatible = "qcom,sm8450-camcc";
reg = <0xade0000 0x20000>;
@@ -71,8 +84,10 @@ examples:
<&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
- power-domains = <&rpmhpd SM8450_MMCX>;
- required-opps = <&rpmhpd_opp_low_svs>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml
new file mode 100644
index 000000000000..bd131a1ff165
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-dispcc.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8450-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller for SM8450
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM8450.
+
+ See also: include/dt-bindings/clock/qcom,sm8450-dispcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8450-dispcc
+ - qcom,sm8475-dispcc
+
+ clocks:
+ minItems: 3
+ items:
+ - description: Board XO source
+ - description: Board Always On XO source
+ - description: Display's AHB clock
+ - description: sleep clock
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: Byte clock from DSI PHY1
+ - description: Pixel clock from DSI PHY1
+ - description: Link clock from DP PHY0
+ - description: VCO DIV clock from DP PHY0
+ - description: Link clock from DP PHY1
+ - description: VCO DIV clock from DP PHY1
+ - description: Link clock from DP PHY2
+ - description: VCO DIV clock from DP PHY2
+ - description: Link clock from DP PHY3
+ - description: VCO DIV clock from DP PHY3
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sm8450-dispcc";
+ reg = <0x0af00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&sleep_clk>,
+ <&dsi0_phy 0>,
+ <&dsi0_phy 1>,
+ <&dsi1_phy 0>,
+ <&dsi1_phy 1>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
new file mode 100644
index 000000000000..44380f6f8136
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8450-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on SM8450
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm graphics clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also::
+ include/dt-bindings/clock/qcom,milos-gpucc.h
+ include/dt-bindings/clock/qcom,sar2130p-gpucc.h
+ include/dt-bindings/clock/qcom,sm4450-gpucc.h
+ include/dt-bindings/clock/qcom,sm8450-gpucc.h
+ include/dt-bindings/clock/qcom,sm8550-gpucc.h
+ include/dt-bindings/reset/qcom,sm8450-gpucc.h
+ include/dt-bindings/reset/qcom,sm8650-gpucc.h
+ include/dt-bindings/reset/qcom,x1e80100-gpucc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,milos-gpucc
+ - qcom,sar2130p-gpucc
+ - qcom,sm4450-gpucc
+ - qcom,sm8450-gpucc
+ - qcom,sm8475-gpucc
+ - qcom,sm8550-gpucc
+ - qcom,sm8650-gpucc
+ - qcom,x1e80100-gpucc
+ - qcom,x1p42100-gpucc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: GPLL0 main branch source
+ - description: GPLL0 div branch source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clock-controller@3d90000 {
+ compatible = "qcom,sm8450-gpucc";
+ reg = <0 0x03d90000 0 0xa000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
new file mode 100644
index 000000000000..b31bd8335529
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8450-videocc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Video Clock & Reset Controller on SM8450
+
+maintainers:
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+ - Jagadeesh Kona <quic_jkona@quicinc.com>
+
+description: |
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on SM8450.
+
+ See also:
+ include/dt-bindings/clock/qcom,sm8450-videocc.h
+ include/dt-bindings/clock/qcom,sm8650-videocc.h
+ include/dt-bindings/clock/qcom,sm8750-videocc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8450-videocc
+ - qcom,sm8475-videocc
+ - qcom,sm8550-videocc
+ - qcom,sm8650-videocc
+ - qcom,sm8750-videocc
+ - qcom,x1e80100-videocc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Video AHB clock from GCC
+
+ power-domains:
+ description:
+ Power domains required for the clock controller to operate
+ items:
+ - description: MMCX power domain
+ - description: MXC power domain
+
+ required-opps:
+ description:
+ OPP nodes that describe required performance points on power domains
+ items:
+ - description: MMCX performance point
+ - description: MXC performance point
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-videocc
+ - qcom,sm8550-videocc
+ - qcom,sm8750-videocc
+ then:
+ required:
+ - required-opps
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ videocc: clock-controller@aaf0000 {
+ compatible = "qcom,sm8450-videocc";
+ reg = <0x0aaf0000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_VIDEO_AHB_CLK>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
new file mode 100644
index 000000000000..30e4b4631575
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8550-dispcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display Clock & Reset Controller for SM8550
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ Qualcomm display clock control module provides the clocks, resets and power
+ domains on SM8550, SM8650, SM8750 and few other platforms.
+
+ See also:
+ - include/dt-bindings/clock/qcom,sm8550-dispcc.h
+ - include/dt-bindings/clock/qcom,sm8650-dispcc.h
+ - include/dt-bindings/clock/qcom,sm8750-dispcc.h
+ - include/dt-bindings/clock/qcom,x1e80100-dispcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sar2130p-dispcc
+ - qcom,sm8550-dispcc
+ - qcom,sm8650-dispcc
+ - qcom,sm8750-dispcc
+ - qcom,x1e80100-dispcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board Always On XO source
+ - description: Display's AHB clock
+ - description: sleep clock
+ - description: Byte clock from DSI PHY0
+ - description: Pixel clock from DSI PHY0
+ - description: Byte clock from DSI PHY1
+ - description: Pixel clock from DSI PHY1
+ - description: Link clock from DP PHY0
+ - description: VCO DIV clock from DP PHY0
+ - description: Link clock from DP PHY1
+ - description: VCO DIV clock from DP PHY1
+ - description: Link clock from DP PHY2
+ - description: VCO DIV clock from DP PHY2
+ - description: Link clock from DP PHY3
+ - description: VCO DIV clock from DP PHY3
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the MMCX power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing required MMCX performance point.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ clock-controller@af00000 {
+ compatible = "qcom,sm8550-dispcc";
+ reg = <0x0af00000 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&sleep_clk>,
+ <&dsi0_phy 0>,
+ <&dsi0_phy 1>,
+ <&dsi1_phy 0>,
+ <&dsi1_phy 1>,
+ <&dp0_phy 0>,
+ <&dp0_phy 1>,
+ <&dp1_phy 0>,
+ <&dp1_phy 1>,
+ <&dp2_phy 0>,
+ <&dp2_phy 1>,
+ <&dp3_phy 0>,
+ <&dp3_phy 1>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
new file mode 100644
index 000000000000..c4e9b9bb63f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8550-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SM8550
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8550
+
+ See also: include/dt-bindings/clock/qcom,sm8550-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sm8550-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 1 Pipe clock source
+ - description: PCIE 1 Phy Auxiliary clock source
+ - description: UFS Phy Rx symbol 0 clock source
+ - description: UFS Phy Rx symbol 1 clock source
+ - description: UFS Phy Tx symbol 0 clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,sm8550-gcc";
+ reg = <0x00100000 0x001f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>,
+ <&pcie0_phy>,
+ <&pcie1_phy>,
+ <&pcie_1_phy_aux_clk>,
+ <&ufs_mem_phy 0>,
+ <&ufs_mem_phy 1>,
+ <&ufs_mem_phy 2>,
+ <&usb_1_qmpphy>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
new file mode 100644
index 000000000000..784fef830681
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8550-tcsr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm TCSR Clock Controller on SM8550
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Taniya Das <taniya.das@oss.qualcomm.com>
+
+description: |
+ Qualcomm TCSR clock control module provides the clocks, resets and
+ power domains on SM8550
+
+ See also:
+ - include/dt-bindings/clock/qcom,glymur-tcsr.h
+ - include/dt-bindings/clock/qcom,sm8550-tcsr.h
+ - include/dt-bindings/clock/qcom,sm8650-tcsr.h
+ - include/dt-bindings/clock/qcom,sm8750-tcsr.h
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,glymur-tcsr
+ - qcom,kaanapali-tcsr
+ - qcom,milos-tcsr
+ - qcom,sar2130p-tcsr
+ - qcom,sm8550-tcsr
+ - qcom,sm8650-tcsr
+ - qcom,sm8750-tcsr
+ - qcom,x1e80100-tcsr
+ - const: syscon
+
+ clocks:
+ items:
+ - description: TCXO pad clock
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ clock-controller@1fc0000 {
+ compatible = "qcom,sm8550-tcsr", "syscon";
+ reg = <0x1fc0000 0x30000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
new file mode 100644
index 000000000000..c7143e2abc80
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8650-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SM8650
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8650
+
+ See also: include/dt-bindings/clock/qcom,sm8650-gcc.h
+
+properties:
+ compatible:
+ const: qcom,sm8650-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board Always On XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: PCIE 1 Pipe clock source
+ - description: PCIE 1 Phy Auxiliary clock source
+ - description: UFS Phy Rx symbol 0 clock source
+ - description: UFS Phy Rx symbol 1 clock source
+ - description: UFS Phy Tx symbol 0 clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,sm8650-gcc";
+ reg = <0x00100000 0x001f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>,
+ <&pcie0_phy>,
+ <&pcie1_phy>,
+ <&pcie_1_phy_aux_clk>,
+ <&ufs_mem_phy 0>,
+ <&ufs_mem_phy 1>,
+ <&ufs_mem_phy 2>,
+ <&usb_1_qmpphy>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml
new file mode 100644
index 000000000000..0114d347b26f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8750-gcc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sm8750-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on SM8750
+
+maintainers:
+ - Taniya Das <quic_tdas@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on SM8750
+
+ See also:
+ include/dt-bindings/clock/qcom,kaanapali-gcc.h
+ include/dt-bindings/clock/qcom,sm8750-gcc.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,kaanapali-gcc
+ - qcom,sm8750-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board Always On XO source
+ - description: Sleep clock source
+ - description: PCIE 0 Pipe clock source
+ - description: UFS Phy Rx symbol 0 clock source
+ - description: UFS Phy Rx symbol 1 clock source
+ - description: UFS Phy Tx symbol 0 clock source
+ - description: USB3 Phy wrapper pipe clock source
+
+required:
+ - compatible
+ - clocks
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ clock-controller@100000 {
+ compatible = "qcom,sm8750-gcc";
+ reg = <0x00100000 0x001f4200>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>,
+ <&pcie0_phy>,
+ <&ufs_mem_phy 0>,
+ <&ufs_mem_phy 1>,
+ <&ufs_mem_phy 2>,
+ <&usb_1_qmpphy>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt b/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt
deleted file mode 100644
index 7474aba36607..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
-
-clkdiv configures the clock frequency of a set of outputs on the PMIC.
-These clocks are typically wired through alternate functions on
-gpio pins.
-
-=======================
-Properties
-=======================
-
-- compatible
- Usage: required
- Value type: <string>
- Definition: must be "qcom,spmi-clkdiv".
-
-- reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: base address of CLKDIV peripherals.
-
-- qcom,num-clkdivs
- Usage: required
- Value type: <u32>
- Definition: number of CLKDIV peripherals.
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the xo clock.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "xo".
-
-- #clock-cells:
- Usage: required
- Value type: <u32>
- Definition: shall contain 1.
-
-=======
-Example
-=======
-
-pm8998_clk_divs: clock-controller@5b00 {
- compatible = "qcom,spmi-clkdiv";
- reg = <0x5b00>;
- #clock-cells = <1>;
- qcom,num-clkdivs = <3>;
- clocks = <&xo_board>;
- clock-names = "xo";
-
- assigned-clocks = <&pm8998_clk_divs 1>,
- <&pm8998_clk_divs 2>,
- <&pm8998_clk_divs 3>;
- assigned-clock-rates = <9600000>,
- <9600000>,
- <9600000>;
-};
diff --git a/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml b/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml
new file mode 100644
index 000000000000..16c95ad6c9d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,spmi-clkdiv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SPMI PMIC clock divider
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+ Qualcomm SPMI PMIC clock divider configures the clock frequency of a set of
+ outputs on the PMIC. These clocks are typically wired through alternate
+ functions on GPIO pins.
+
+properties:
+ compatible:
+ const: qcom,spmi-clkdiv
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Board XO source
+
+ clock-names:
+ items:
+ - const: xo
+
+ "#clock-cells":
+ const: 1
+
+ qcom,num-clkdivs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of CLKDIV peripherals.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+ - qcom,num-clkdivs
+
+additionalProperties: false
+
+examples:
+ - |
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@5b00 {
+ compatible = "qcom,spmi-clkdiv";
+ reg = <0x5b00>;
+ clocks = <&xo_board>;
+ clock-names = "xo";
+ #clock-cells = <1>;
+ qcom,num-clkdivs = <3>;
+
+ assigned-clocks = <&pm8998_clk_divs 1>,
+ <&pm8998_clk_divs 2>,
+ <&pm8998_clk_divs 3>;
+ assigned-clock-rates = <9600000>,
+ <9600000>,
+ <9600000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/qcom,turingcc.txt b/Documentation/devicetree/bindings/clock/qcom,turingcc.txt
deleted file mode 100644
index 126517de5f9a..000000000000
--- a/Documentation/devicetree/bindings/clock/qcom,turingcc.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Qualcomm Turing Clock & Reset Controller Binding
-------------------------------------------------
-
-Required properties :
-- compatible: shall contain "qcom,qcs404-turingcc".
-- reg: shall contain base register location and length.
-- clocks: ahb clock for the TuringCC
-- #clock-cells: from common clock binding, shall contain 1.
-- #reset-cells: from common reset binding, shall contain 1.
-
-Example:
- turingcc: clock-controller@800000 {
- compatible = "qcom,qcs404-turingcc";
- reg = <0x00800000 0x30000>;
- clocks = <&gcc GCC_CDSP_CFG_AHB_CLK>;
-
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index 3cdbcebdc1a1..f4ff9acef9d5 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -4,50 +4,44 @@
$id: http://devicetree.org/schemas/clock/qcom,videocc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Video Clock & Reset Controller Binding
+title: Qualcomm Video Clock & Reset Controller
maintainers:
- - Taniya Das <tdas@codeaurora.org>
+ - Taniya Das <quic_tdas@quicinc.com>
description: |
- Qualcomm video clock control module which supports the clocks, resets and
- power domains on Qualcomm SoCs.
+ Qualcomm video clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
- See also:
- dt-bindings/clock/qcom,videocc-sc7180.h
- dt-bindings/clock/qcom,videocc-sc7280.h
- dt-bindings/clock/qcom,videocc-sdm845.h
- dt-bindings/clock/qcom,videocc-sm8150.h
- dt-bindings/clock/qcom,videocc-sm8250.h
+ See also::
+ include/dt-bindings/clock/qcom,sm6350-videocc.h
+ include/dt-bindings/clock/qcom,videocc-sc7180.h
+ include/dt-bindings/clock/qcom,videocc-sc7280.h
+ include/dt-bindings/clock/qcom,videocc-sdm845.h
+ include/dt-bindings/clock/qcom,videocc-sm8150.h
+ include/dt-bindings/clock/qcom,videocc-sm8250.h
properties:
compatible:
- enum:
- - qcom,sc7180-videocc
- - qcom,sc7280-videocc
- - qcom,sdm845-videocc
- - qcom,sm8150-videocc
- - qcom,sm8250-videocc
+ oneOf:
+ - enum:
+ - qcom,sc7180-videocc
+ - qcom,sc7280-videocc
+ - qcom,sdm845-videocc
+ - qcom,sm6350-videocc
+ - qcom,sm8150-videocc
+ - qcom,sm8250-videocc
+ - items:
+ - const: qcom,sc8180x-videocc
+ - const: qcom,sm8150-videocc
clocks:
- items:
- - description: Board XO source
+ minItems: 1
+ maxItems: 3
clock-names:
- items:
- - const: bi_tcxo
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
- '#power-domain-cells':
- const: 1
-
- reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
power-domains:
description:
@@ -61,19 +55,103 @@ properties:
required:
- compatible
- - reg
- clocks
- clock-names
- - '#clock-cells'
- - '#reset-cells'
- '#power-domain-cells'
-additionalProperties: false
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-videocc
+ - qcom,sdm845-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ clock-names:
+ items:
+ - const: bi_tcxo
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board active XO source
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Video AHB clock from GCC
+ - description: Board XO source
+ - description: Sleep Clock source
+ clock-names:
+ items:
+ - const: iface
+ - const: bi_tcxo
+ - const: sleep_clk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8150-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: AHB
+ - description: Board XO source
+ clock-names:
+ items:
+ - const: iface
+ - const: bi_tcxo
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8250-videocc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: AHB
+ - description: Board XO source
+ - description: Board active XO source
+ clock-names:
+ items:
+ - const: iface
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@ab00000 {
compatible = "qcom,sdm845-videocc";
reg = <0x0ab00000 0x10000>;
@@ -82,7 +160,7 @@ examples:
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
- power-domains = <&rpmhpd SM8250_MMCX>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...
diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml
new file mode 100644
index 000000000000..938a2f1ff3fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,x1e80100-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller on x1e80100
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description: |
+ Qualcomm camera clock control module provides the clocks, resets and power
+ domains on x1e80100.
+
+ See also:
+ include/dt-bindings/clock/qcom,x1e80100-camcc.h
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,x1e80100-camcc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Camera AHB clock from GCC
+ - description: Board XO source
+ - description: Board active XO source
+ - description: Sleep clock source
+
+ power-domains:
+ items:
+ - description: A phandle to the MXC power-domain
+ - description: A phandle to the MMCX power-domain
+
+ required-opps:
+ items:
+ - description: A phandle to an OPP node describing MXC performance points
+ - description: A phandle to an OPP node describing MMCX performance points
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - required-opps
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ clock-controller@ade0000 {
+ compatible = "qcom,x1e80100-camcc";
+ reg = <0xade0000 0x20000>;
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>,
+ <&sleep_clk>;
+ power-domains = <&rpmhpd RPMHPD_MXC>,
+ <&rpmhpd RPMHPD_MMCX>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml
new file mode 100644
index 000000000000..1b15b5070954
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-gcc.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,x1e80100-gcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller on X1E80100
+
+maintainers:
+ - Rajendra Nayak <quic_rjendra@quicinc.com>
+
+description: |
+ Qualcomm global clock control module provides the clocks, resets and power
+ domains on X1E80100
+
+ See also: include/dt-bindings/clock/qcom,x1e80100-gcc.h
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qcom,x1p42100-gcc
+ - const: qcom,x1e80100-gcc
+ - const: qcom,x1e80100-gcc
+
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PCIe 3 pipe clock
+ - description: PCIe 4 pipe clock
+ - description: PCIe 5 pipe clock
+ - description: PCIe 6a pipe clock
+ - description: PCIe 6b pipe clock
+ - description: USB4_0 QMPPHY clock source
+ - description: USB4_1 QMPPHY clock source
+ - description: USB4_2 QMPPHY clock source
+ - description: USB4_0 PHY DP0 GMUX clock source
+ - description: USB4_0 PHY DP1 GMUX clock source
+ - description: USB4_0 PHY PCIE PIPEGMUX clock source
+ - description: USB4_0 PHY PIPEGMUX clock source
+ - description: USB4_0 PHY SYS PCIE PIPEGMUX clock source
+ - description: USB4_1 PHY DP0 GMUX 2 clock source
+ - description: USB4_1 PHY DP1 GMUX 2 clock source
+ - description: USB4_1 PHY PCIE PIPEGMUX clock source
+ - description: USB4_1 PHY PIPEGMUX clock source
+ - description: USB4_1 PHY SYS PCIE PIPEGMUX clock source
+ - description: USB4_2 PHY DP0 GMUX 2 clock source
+ - description: USB4_2 PHY DP1 GMUX 2 clock source
+ - description: USB4_2 PHY PCIE PIPEGMUX clock source
+ - description: USB4_2 PHY PIPEGMUX clock source
+ - description: USB4_2 PHY SYS PCIE PIPEGMUX clock source
+ - description: USB4_0 PHY RX 0 clock source
+ - description: USB4_0 PHY RX 1 clock source
+ - description: USB4_1 PHY RX 0 clock source
+ - description: USB4_1 PHY RX 1 clock source
+ - description: USB4_2 PHY RX 0 clock source
+ - description: USB4_2 PHY RX 1 clock source
+ - description: USB4_0 PHY PCIE PIPE clock source
+ - description: USB4_0 PHY max PIPE clock source
+ - description: USB4_1 PHY PCIE PIPE clock source
+ - description: USB4_1 PHY max PIPE clock source
+ - description: USB4_2 PHY PCIE PIPE clock source
+ - description: USB4_2 PHY max PIPE clock source
+
+ power-domains:
+ description:
+ A phandle and PM domain specifier for the CX power domain.
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - power-domains
+ - '#power-domain-cells'
+
+allOf:
+ - $ref: qcom,gcc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ clock-controller@100000 {
+ compatible = "qcom,x1e80100-gcc";
+ reg = <0x00100000 0x200000>;
+ clocks = <&bi_tcxo_div2>,
+ <&sleep_clk>,
+ <&pcie3_phy>,
+ <&pcie4_phy>,
+ <&pcie5_phy>,
+ <&pcie6a_phy>,
+ <&pcie6b_phy>,
+ <&usb_1_ss0_qmpphy 0>,
+ <&usb_1_ss1_qmpphy 1>,
+ <&usb_1_ss2_qmpphy 2>,
+ <&usb4_0_phy_dp0_gmux_clk>,
+ <&usb4_0_phy_dp1_gmux_clk>,
+ <&usb4_0_phy_pcie_pipegmux_clk>,
+ <&usb4_0_phy_pipegmux_clk>,
+ <&usb4_0_phy_sys_pcie_pipegmux_clk>,
+ <&usb4_1_phy_dp0_gmux_2_clk>,
+ <&usb4_1_phy_dp1_gmux_2_clk>,
+ <&usb4_1_phy_pcie_pipegmux_clk>,
+ <&usb4_1_phy_pipegmux_clk>,
+ <&usb4_1_phy_sys_pcie_pipegmux_clk>,
+ <&usb4_2_phy_dp0_gmux_2_clk>,
+ <&usb4_2_phy_dp1_gmux_2_clk>,
+ <&usb4_2_phy_pcie_pipegmux_clk>,
+ <&usb4_2_phy_pipegmux_clk>,
+ <&usb4_2_phy_sys_pcie_pipegmux_clk>,
+ <&usb4_0_phy_rx_0_clk>,
+ <&usb4_0_phy_rx_1_clk>,
+ <&usb4_1_phy_rx_0_clk>,
+ <&usb4_1_phy_rx_1_clk>,
+ <&usb4_2_phy_rx_0_clk>,
+ <&usb4_2_phy_rx_1_clk>,
+ <&usb4_0_phy_pcie_pipe_clk>,
+ <&usb4_0_phy_max_pipe_clk>,
+ <&usb4_1_phy_pcie_pipe_clk>,
+ <&usb4_1_phy_max_pipe_clk>,
+ <&usb4_2_phy_pcie_pipe_clk>,
+ <&usb4_2_phy_max_pipe_clk>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
deleted file mode 100644
index 10119d9ef4b1..000000000000
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ /dev/null
@@ -1,212 +0,0 @@
-* Clock Block on Freescale QorIQ Platforms
-
-Freescale QorIQ chips take primary clocking input from the external
-SYSCLK signal. The SYSCLK input (frequency) is multiplied using
-multiple phase locked loops (PLL) to create a variety of frequencies
-which can then be passed to a variety of internal logic, including
-cores and peripheral IP blocks.
-Please refer to the Reference Manual for details.
-
-All references to "1.0" and "2.0" refer to the QorIQ chassis version to
-which the chip complies.
-
-Chassis Version Example Chips
---------------- -------------
-1.0 p4080, p5020, p5040
-2.0 t4240, b4860
-
-1. Clock Block Binding
-
-Required properties:
-- compatible: Should contain a chip-specific clock block compatible
- string and (if applicable) may contain a chassis-version clock
- compatible string.
-
- Chip-specific strings are of the form "fsl,<chip>-clockgen", such as:
- * "fsl,p2041-clockgen"
- * "fsl,p3041-clockgen"
- * "fsl,p4080-clockgen"
- * "fsl,p5020-clockgen"
- * "fsl,p5040-clockgen"
- * "fsl,t1023-clockgen"
- * "fsl,t1024-clockgen"
- * "fsl,t1040-clockgen"
- * "fsl,t1042-clockgen"
- * "fsl,t2080-clockgen"
- * "fsl,t2081-clockgen"
- * "fsl,t4240-clockgen"
- * "fsl,b4420-clockgen"
- * "fsl,b4860-clockgen"
- * "fsl,ls1012a-clockgen"
- * "fsl,ls1021a-clockgen"
- * "fsl,ls1028a-clockgen"
- * "fsl,ls1043a-clockgen"
- * "fsl,ls1046a-clockgen"
- * "fsl,ls1088a-clockgen"
- * "fsl,ls2080a-clockgen"
- * "fsl,lx2160a-clockgen"
- Chassis-version clock strings include:
- * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
- * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
-- reg: Describes the address of the device's resources within the
- address space defined by its parent bus, and resource zero
- represents the clock register set
-
-Optional properties:
-- ranges: Allows valid translation between child's address space and
- parent's. Must be present if the device has sub-nodes.
-- #address-cells: Specifies the number of cells used to represent
- physical base addresses. Must be present if the device has
- sub-nodes and set to 1 if present
-- #size-cells: Specifies the number of cells used to represent
- the size of an address. Must be present if the device has
- sub-nodes and set to 1 if present
-- clock-frequency: Input system clock frequency (SYSCLK)
-- clocks: If clock-frequency is not specified, sysclk may be provided
- as an input clock. Either clock-frequency or clocks must be
- provided.
- A second input clock, called "coreclk", may be provided if
- core PLLs are based on a different input clock from the
- platform PLL.
-- clock-names: Required if a coreclk is present. Valid names are
- "sysclk" and "coreclk".
-
-2. Clock Provider
-
-The clockgen node should act as a clock provider, though in older device
-trees the children of the clockgen node are the clock providers.
-
-When the clockgen node is a clock provider, #clock-cells = <2>.
-The first cell of the clock specifier is the clock type, and the
-second cell is the clock index for the specified type.
-
- Type# Name Index Cell
- 0 sysclk must be 0
- 1 cmux index (n in CLKCnCSR)
- 2 hwaccel index (n in CLKCGnHWACSR)
- 3 fman 0 for fm1, 1 for fm2
- 4 platform pll n=pll/(n+1). For example, when n=1,
- that means output_freq=PLL_freq/2.
- 5 coreclk must be 0
-
-3. Example
-
- clockgen: global-utilities@e1000 {
- compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
- clock-frequency = <133333333>;
- reg = <0xe1000 0x1000>;
- #clock-cells = <2>;
- };
-
- fman@400000 {
- ...
- clocks = <&clockgen 3 0>;
- ...
- };
-}
-4. Legacy Child Nodes
-
-NOTE: These nodes are deprecated. Kernels should continue to support
-device trees with these nodes, but new device trees should not use them.
-
-Most of the bindings are from the common clock binding[1].
- [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : Should include one of the following:
- * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
- * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
- * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
- * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
- * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
- It takes parent's clock-frequency as its clock.
- * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
- It takes parent's clock-frequency as its clock.
- * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
- * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
-- #clock-cells: From common clock binding. The number of cells in a
- clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
- clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
- For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
- clock-specifier cell may take the following values:
- * 0 - equal to the PLL frequency
- * 1 - equal to the PLL frequency divided by 2
- * 2 - equal to the PLL frequency divided by 4
-
-Recommended properties:
-- clocks: Should be the phandle of input parent clock
-- clock-names: From common clock binding, indicates the clock name
-- clock-output-names: From common clock binding, indicates the names of
- output clocks
-- reg: Should be the offset and length of clock block base address.
- The length should be 4.
-
-Legacy Example:
-/ {
- clockgen: global-utilities@e1000 {
- compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
- ranges = <0x0 0xe1000 0x1000>;
- clock-frequency = <133333333>;
- reg = <0xe1000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- sysclk: sysclk {
- #clock-cells = <0>;
- compatible = "fsl,qoriq-sysclk-1.0";
- clock-output-names = "sysclk";
- };
-
- pll0: pll0@800 {
- #clock-cells = <1>;
- reg = <0x800 0x4>;
- compatible = "fsl,qoriq-core-pll-1.0";
- clocks = <&sysclk>;
- clock-output-names = "pll0", "pll0-div2";
- };
-
- pll1: pll1@820 {
- #clock-cells = <1>;
- reg = <0x820 0x4>;
- compatible = "fsl,qoriq-core-pll-1.0";
- clocks = <&sysclk>;
- clock-output-names = "pll1", "pll1-div2";
- };
-
- mux0: mux0@0 {
- #clock-cells = <0>;
- reg = <0x0 0x4>;
- compatible = "fsl,qoriq-core-mux-1.0";
- clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
- clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
- clock-output-names = "cmux0";
- };
-
- mux1: mux1@20 {
- #clock-cells = <0>;
- reg = <0x20 0x4>;
- compatible = "fsl,qoriq-core-mux-1.0";
- clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
- clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
- clock-output-names = "cmux1";
- };
-
- platform-pll: platform-pll@c00 {
- #clock-cells = <1>;
- reg = <0xc00 0x4>;
- compatible = "fsl,qoriq-platform-pll-1.0";
- clocks = <&sysclk>;
- clock-output-names = "platform-pll", "platform-pll-div2";
- };
- };
-};
-
-Example for legacy clock consumer:
-
-/ {
- cpu0: PowerPC,e5500@0 {
- ...
- clocks = <&mux0>;
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/raspberrypi,rp1-clocks.yaml b/Documentation/devicetree/bindings/clock/raspberrypi,rp1-clocks.yaml
new file mode 100644
index 000000000000..cc4491f7ee5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/raspberrypi,rp1-clocks.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/raspberrypi,rp1-clocks.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RaspberryPi RP1 clock generator
+
+maintainers:
+ - A. della Porta <andrea.porta@suse.com>
+
+description: |
+ The RP1 contains a clock generator designed as three PLLs (CORE, AUDIO,
+ VIDEO), and each PLL output can be programmed through dividers to generate
+ the clocks to drive the sub-peripherals embedded inside the chipset.
+
+ Link to datasheet:
+ https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf
+
+properties:
+ compatible:
+ const: raspberrypi,rp1-clocks
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The available clocks are defined in
+ include/dt-bindings/clock/raspberrypi,rp1-clocks.h.
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/raspberrypi,rp1-clocks.h>
+
+ rp1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clocks@c040018000 {
+ compatible = "raspberrypi,rp1-clocks";
+ reg = <0xc0 0x40018000 0x0 0x10038>;
+ #clock-cells = <1>;
+ clocks = <&clk_rp1_xosc>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml
new file mode 100644
index 000000000000..162d38035188
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,5p35023.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,5p35023.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas 5p35023 VersaClock 3 programmable I2C clock generator
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The 5P35023 is a VersaClock programmable clock generator and
+ is designed for low-power, consumer, and high-performance PCI
+ express applications. The 5P35023 device is a three PLL
+ architecture design, and each PLL is individually programmable
+ and allowing for up to 6 unique frequency outputs.
+
+ An internal OTP memory allows the user to store the configuration
+ in the device. After power up, the user can change the device register
+ settings through the I2C interface when I2C mode is selected.
+
+ The driver can read a full register map from the DT, and will use that
+ register map to initialize the attached part (via I2C) when the system
+ boots. Any configuration not supported by the common clock framework
+ must be done via the full register map, including optimized settings.
+
+ Link to datasheet:
+ https://www.renesas.com/us/en/products/clocks-timing/clock-generation/programmable-clocks/5p35023-versaclock-3s-programmable-clock-generator
+
+properties:
+ compatible:
+ enum:
+ - renesas,5l35023
+ - renesas,5p35023
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ description:
+ The index in the assigned-clocks is mapped to the output clock as below
+ 0 - REF, 1 - SE1, 2 - SE2, 3 - SE3, 4 - DIFF1, 5 - DIFF2.
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ renesas,settings:
+ description: Optional, complete register map of the device.
+ Optimized settings for the device must be provided in full
+ and are written during initialization.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ maxItems: 37
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ versa3: clock-generator@68 {
+ compatible = "renesas,5p35023";
+ reg = <0x68>;
+ #clock-cells = <1>;
+
+ clocks = <&x1>;
+
+ renesas,settings = [
+ 80 00 11 19 4c 02 23 7f 83 19 08 a9 5f 25 24 bf
+ 00 14 7a e1 00 00 00 00 01 55 59 bb 3f 30 90 b6
+ 80 b0 45 c4 95
+ ];
+
+ assigned-clocks = <&versa3 0>, <&versa3 1>,
+ <&versa3 2>, <&versa3 3>,
+ <&versa3 4>, <&versa3 5>;
+ assigned-clock-rates = <24000000>, <11289600>,
+ <11289600>, <12000000>,
+ <25000000>, <12288000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/renesas,9series.yaml b/Documentation/devicetree/bindings/clock/renesas,9series.yaml
index 102eb95cb3fc..af6319697b1c 100644
--- a/Documentation/devicetree/bindings/clock/renesas,9series.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,9series.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/renesas,9series.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for Renesas 9-series I2C PCIe clock generators
+title: Renesas 9-series I2C PCIe clock generators
description: |
The Renesas 9-series are I2C PCIe clock generators providing
@@ -16,6 +16,20 @@ description: |
- 9FGV0241:
0 -- DIF0
1 -- DIF1
+ - 9FGV0441:
+ 0 -- DIF0
+ 1 -- DIF1
+ 2 -- DIF2
+ 3 -- DIF3
+ - 9FGV0841:
+ 0 -- DIF0
+ 1 -- DIF1
+ 2 -- DIF2
+ 3 -- DIF3
+ 4 -- DIF4
+ 5 -- DIF5
+ 6 -- DIF6
+ 7 -- DIF7
maintainers:
- Marek Vasut <marex@denx.de>
@@ -24,6 +38,8 @@ properties:
compatible:
enum:
- renesas,9fgv0241
+ - renesas,9fgv0441
+ - renesas,9fgv0841
reg:
description: I2C device address
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
index 9185d101737e..a0e09b7002f0 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml
@@ -32,12 +32,16 @@ properties:
reg:
maxItems: 1
- clocks: true
+ clocks:
+ minItems: 1
+ maxItems: 3
'#clock-cells':
const: 1
- clock-output-names: true
+ clock-output-names:
+ minItems: 3
+ maxItems: 17
renesas,mode:
description: Board-specific settings of the MD_CK* bits on R-Mobile A1
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
index e57bc40d307a..655154534c0f 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Clock Pulse Generator / Module Standby and Software Reset
@@ -31,6 +31,7 @@ properties:
- renesas,r8a7745-cpg-mssr # RZ/G1E
- renesas,r8a77470-cpg-mssr # RZ/G1C
- renesas,r8a774a1-cpg-mssr # RZ/G2M
+ - renesas,r8a774a3-cpg-mssr # RZ/G2M v3.0
- renesas,r8a774b1-cpg-mssr # RZ/G2N
- renesas,r8a774c0-cpg-mssr # RZ/G2E
- renesas,r8a774e1-cpg-mssr # RZ/G2H
@@ -50,9 +51,17 @@ properties:
- renesas,r8a779a0-cpg-mssr # R-Car V3U
- renesas,r8a779f0-cpg-mssr # R-Car S4-8
- renesas,r8a779g0-cpg-mssr # R-Car V4H
+ - renesas,r8a779h0-cpg-mssr # R-Car V4M
+ - renesas,r9a09g077-cpg-mssr # RZ/T2H
+ - renesas,r9a09g087-cpg-mssr # RZ/N2H
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: base address of register block 0
+ - description: base address of register block 1
+ description: base addresses of clock controller. Some controllers
+ (like r9a09g077) use two blocks instead of a single one.
clocks:
minItems: 1
@@ -90,17 +99,6 @@ properties:
the datasheet.
const: 1
-if:
- not:
- properties:
- compatible:
- items:
- enum:
- - renesas,r7s9210-cpg-mssr
-then:
- required:
- - '#reset-cells'
-
required:
- compatible
- reg
@@ -109,6 +107,36 @@ required:
- '#clock-cells'
- '#power-domain-cells'
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g077-cpg-mssr
+ - renesas,r9a09g087-cpg-mssr
+ then:
+ properties:
+ reg:
+ minItems: 2
+ clock-names:
+ items:
+ - const: extal
+ else:
+ properties:
+ reg:
+ maxItems: 1
+ - if:
+ not:
+ properties:
+ compatible:
+ items:
+ enum:
+ - renesas,r7s9210-cpg-mssr
+ then:
+ required:
+ - '#reset-cells'
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
index 95bf485c6cec..26d94cedc871 100644
--- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1D (R9A06G032) System Controller
maintainers:
- - Gareth Williams <gareth.williams.jx@renesas.com>
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
@@ -48,7 +48,7 @@ properties:
patternProperties:
"^dma-router@[a-f0-9]+$":
type: object
- $ref: "../dma/renesas,rzn1-dmamux.yaml#"
+ $ref: /schemas/dma/renesas,rzn1-dmamux.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.yaml
new file mode 100644
index 000000000000..3707e4118949
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,r9a08g045-vbattb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Battery Backup Function (VBATTB)
+
+description:
+ Renesas VBATTB is an always on powered module (backed by battery) which
+ controls the RTC clock (VBATTCLK), tamper detection logic and a small
+ general usage memory (128B).
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+
+properties:
+ compatible:
+ const: renesas,r9a08g045-vbattb
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: tamper detector interrupt
+
+ clocks:
+ items:
+ - description: VBATTB module clock
+ - description: RTC input clock (crystal or external clock device)
+
+ clock-names:
+ items:
+ - const: bclk
+ - const: rtx
+
+ '#clock-cells':
+ const: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: VBATTB module reset
+
+ quartz-load-femtofarads:
+ description: load capacitance of the on board crystal
+ enum: [ 4000, 7000, 9000, 12500 ]
+ default: 4000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - power-domains
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a08g045-cpg.h>
+ #include <dt-bindings/clock/renesas,r9a08g045-vbattb.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ clock-controller@1005c000 {
+ compatible = "renesas,r9a08g045-vbattb";
+ reg = <0x1005c000 0x1000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G045_VBAT_BCLK>, <&vbattb_xtal>;
+ clock-names = "bclk", "rtx";
+ assigned-clocks = <&vbattb VBATTB_MUX>;
+ assigned-clock-parents = <&vbattb VBATTB_XC>;
+ #clock-cells = <1>;
+ power-domains = <&cpg>;
+ resets = <&cpg R9A08G045_VBAT_BRESETN>;
+ quartz-load-femtofarads = <12500>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
index 6eaabb4d82ec..c84f29f1810f 100644
--- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car USB 2.0 clock selector
@@ -47,7 +47,6 @@ properties:
maxItems: 1
clocks:
- minItems: 4
maxItems: 4
clock-names:
@@ -64,7 +63,6 @@ properties:
maxItems: 1
resets:
- minItems: 2
maxItems: 2
reset-names:
diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
index d036675e0779..8c18616e5c4d 100644
--- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/{G2L,V2L,V2M} Clock Pulse Generator / Module Standby Mode
@@ -24,9 +24,10 @@ description: |
properties:
compatible:
enum:
- - renesas,r9a07g043-cpg # RZ/G2UL{Type-1,Type-2}
+ - renesas,r9a07g043-cpg # RZ/G2UL{Type-1,Type-2} and RZ/Five
- renesas,r9a07g044-cpg # RZ/G2{L,LC}
- renesas,r9a07g054-cpg # RZ/V2L
+ - renesas,r9a08g045-cpg # RZ/G3S
- renesas,r9a09g011-cpg # RZ/V2M
reg:
@@ -60,7 +61,7 @@ properties:
'#reset-cells':
description:
- The single reset specifier cell must be the module number, as defined in
+ The single reset specifier cell must be the reset number, as defined in
<dt-bindings/clock/r9a0*-cpg.h>.
const: 1
diff --git a/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml
new file mode 100644
index 000000000000..f261445bf341
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,rzv2h-cpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/{G3E,V2H(P),V2N} Clock Pulse Generator (CPG)
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ On Renesas RZ/{G3E,V2H(P),V2N} SoCs, the CPG (Clock Pulse Generator) handles
+ generation and control of clock signals for the IP modules, generation and
+ control of resets, and control over booting, low power consumption and power
+ supply domains.
+
+properties:
+ compatible:
+ enum:
+ - renesas,r9a09g047-cpg # RZ/G3E
+ - renesas,r9a09g056-cpg # RZ/V2N
+ - renesas,r9a09g057-cpg # RZ/V2H
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: AUDIO_EXTAL clock input
+ - description: RTXIN clock input
+ - description: QEXTAL clock input
+
+ clock-names:
+ items:
+ - const: audio_extal
+ - const: rtxin
+ - const: qextal
+
+ '#clock-cells':
+ description: |
+ - For CPG core clocks, the two clock specifier cells must be "CPG_CORE"
+ and a core clock reference, as defined in
+ <dt-bindings/clock/renesas,r9a09g0*-cpg.h>,
+ - For module clocks, the two clock specifier cells must be "CPG_MOD" and
+ a module number. The module number is calculated as the CLKON register
+ offset index multiplied by 16, plus the actual bit in the register
+ used to turn the CLK ON. For example, for CGC_GIC_0_GICCLK, the
+ calculation is (1 * 16 + 3) = 0x13.
+ const: 2
+
+ '#power-domain-cells':
+ const: 0
+
+ '#reset-cells':
+ description:
+ The single reset specifier cell must be the reset number. The reset number
+ is calculated as the reset register offset index multiplied by 16, plus the
+ actual bit in the register used to reset the specific IP block. For example,
+ for SYS_0_PRESETN, the calculation is (3 * 16 + 0) = 0x30.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#power-domain-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@10420000 {
+ compatible = "renesas,r9a09g057-cpg";
+ reg = <0x10420000 0x10000>;
+ clocks = <&audio_extal_clk>, <&rtxin_clk>, <&qextal_clk>;
+ clock-names = "audio_extal", "rtxin", "qextal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml b/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
new file mode 100644
index 000000000000..b339f1f9f072
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,versaclock7.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Versaclock7 Programmable Clock
+
+maintainers:
+ - Alex Helms <alexander.helms.jy@renesas.com>
+
+description: |
+ Renesas Versaclock7 is a family of configurable clock generator and
+ jitter attenuator ICs with fractional and integer dividers.
+
+properties:
+ '#clock-cells':
+ const: 1
+
+ compatible:
+ enum:
+ - renesas,rc21008a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: External crystal or oscillator
+
+ clock-names:
+ items:
+ - const: xin
+
+required:
+ - '#clock-cells'
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ vc7_xin: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <49152000>;
+ };
+
+ i2c@0 {
+ reg = <0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vc7: clock-controller@9 {
+ compatible = "renesas,rc21008a";
+ reg = <0x9>;
+ #clock-cells = <1>;
+ clocks = <&vc7_xin>;
+ clock-names = "xin";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/riscv,rpmi-clock.yaml b/Documentation/devicetree/bindings/clock/riscv,rpmi-clock.yaml
new file mode 100644
index 000000000000..5d62bf8215c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/riscv,rpmi-clock.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/riscv,rpmi-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V RPMI clock service group based clock controller
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V Platform Management Interface (RPMI) [1] defines a
+ messaging protocol which is modular and extensible. The supervisor
+ software can send/receive RPMI messages via SBI MPXY extension [2]
+ or some dedicated supervisor-mode RPMI transport.
+
+ The RPMI specification [1] defines clock service group for accessing
+ system clocks managed by a platform microcontroller. The supervisor
+ software can access RPMI clock service group via SBI MPXY channel or
+ some dedicated supervisor-mode RPMI transport.
+
+ ===========================================
+ References
+ ===========================================
+
+ [1] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+ [2] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-sbi-doc/releases
+
+properties:
+ compatible:
+ description:
+ Intended for use by the supervisor software.
+ const: riscv,rpmi-clock
+
+ mboxes:
+ maxItems: 1
+ description:
+ Mailbox channel of the underlying RPMI transport or SBI message proxy channel.
+
+ "#clock-cells":
+ const: 1
+ description:
+ Platform specific CLOCK_ID as defined by the RISC-V Platform Management
+ Interface (RPMI) specification.
+
+required:
+ - compatible
+ - mboxes
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller {
+ compatible = "riscv,rpmi-clock";
+ mboxes = <&mpxy_mbox 0x1000 0x0>;
+ #clock-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/riscv,rpmi-mpxy-clock.yaml b/Documentation/devicetree/bindings/clock/riscv,rpmi-mpxy-clock.yaml
new file mode 100644
index 000000000000..76f2a1b3d30d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/riscv,rpmi-mpxy-clock.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/riscv,rpmi-mpxy-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V RPMI clock service group based message proxy
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V Platform Management Interface (RPMI) [1] defines a
+ messaging protocol which is modular and extensible. The supervisor
+ software can send/receive RPMI messages via SBI MPXY extension [2]
+ or some dedicated supervisor-mode RPMI transport.
+
+ The RPMI specification [1] defines clock service group for accessing
+ system clocks managed by a platform microcontroller. The SBI implementation
+ (machine mode firmware or hypervisor) can implement an SBI MPXY channel
+ to allow RPMI clock service group access to the supervisor software.
+
+ ===========================================
+ References
+ ===========================================
+
+ [1] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+ [2] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-sbi-doc/releases
+
+properties:
+ compatible:
+ description:
+ Intended for use by the SBI implementation.
+ const: riscv,rpmi-mpxy-clock
+
+ mboxes:
+ maxItems: 1
+ description:
+ Mailbox channel of the underlying RPMI transport.
+
+ riscv,sbi-mpxy-channel-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The SBI MPXY channel id to be used for providing RPMI access to
+ the supervisor software.
+
+required:
+ - compatible
+ - mboxes
+ - riscv,sbi-mpxy-channel-id
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-service {
+ compatible = "riscv,rpmi-mpxy-clock";
+ mboxes = <&rpmi_shmem_mbox 0x8>;
+ riscv,sbi-mpxy-channel-id = <0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml
index 3eec381c7cf5..0f0f64b6f8cb 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,px30-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml
index 1376230fede6..ba5b45464315 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3036-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.txt
deleted file mode 100644
index 6f8744fd301b..000000000000
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* Rockchip RK3126/RK3128 Clock and Reset Unit
-
-The RK3126/RK3128 clock controller generates and supplies clock to various
-controllers within the SoC and also implements a reset controller for SoC
-peripherals.
-
-Required Properties:
-
-- compatible: should be "rockchip,rk3126-cru" or "rockchip,rk3128-cru"
- "rockchip,rk3126-cru" - controller compatible with RK3126 SoC.
- "rockchip,rk3128-cru" - controller compatible with RK3128 SoC.
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-- #reset-cells: should be 1.
-
-Optional Properties:
-
-- rockchip,grf: phandle to the syscon managing the "general register files"
- If missing pll rates are not changeable, due to the missing pll lock status.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/rk3128-cru.h headers and can be
-used in device tree sources. Similar macros exist for the reset sources in
-these files.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "xin24m" - crystal input - required,
- - "ext_i2s" - external I2S clock - optional,
- - "gmac_clkin" - external GMAC clock - optional
-
-Example: Clock controller node:
-
- cru: cru@20000000 {
- compatible = "rockchip,rk3128-cru";
- reg = <0x20000000 0x1000>;
- rockchip,grf = <&grf>;
-
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller:
-
- uart2: serial@20068000 {
- compatible = "rockchip,serial";
- reg = <0x20068000 0x100>;
- interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
- clock-frequency = <24000000>;
- clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
- clock-names = "sclk_uart", "pclk_uart";
- };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.yaml
new file mode 100644
index 000000000000..b3d9c8eca989
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3128-cru.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3128-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3126/RK3128 Clock and Reset Unit (CRU)
+
+maintainers:
+ - Elaine Zhang <zhangqing@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description: |
+ The RK3126/RK3128 clock controller generates and supplies clock to various
+ controllers within the SoC and also implements a reset controller for SoC
+ peripherals.
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All available clocks are defined as
+ preprocessor macros in the dt-bindings/clock/rk3128-cru.h headers and can be
+ used in device tree sources. Similar macros exist for the reset sources in
+ these files.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3126-cru
+ - rockchip,rk3128-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: xin24m
+ - enum:
+ - ext_i2s
+ - gmac_clkin
+ - enum:
+ - ext_i2s
+ - gmac_clkin
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the "general register files" (GRF),
+ if missing pll rates are not changeable, due to the missing pll
+ lock status.
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ cru: clock-controller@20000000 {
+ compatible = "rockchip,rk3128-cru";
+ reg = <0x20000000 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml
index cf7dc01d9478..1050fff72ade 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3228-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml
index 96bc05749e1a..6655e97d52e4 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3288-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml
index 523ee578a586..fec37f5b80f6 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3308-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt
deleted file mode 100644
index 904ae682ea90..000000000000
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* Rockchip RK3328 Clock and Reset Unit
-
-The RK3328 clock controller generates and supplies clock to various
-controllers within the SoC and also implements a reset controller for SoC
-peripherals.
-
-Required Properties:
-
-- compatible: should be "rockchip,rk3328-cru"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-- #reset-cells: should be 1.
-
-Optional Properties:
-
-- rockchip,grf: phandle to the syscon managing the "general register files"
- If missing pll rates are not changeable, due to the missing pll lock status.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. All available clocks are defined as
-preprocessor macros in the dt-bindings/clock/rk3328-cru.h headers and can be
-used in device tree sources. Similar macros exist for the reset sources in
-these files.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "xin24m" - crystal input - required,
- - "clkin_i2s" - external I2S clock - optional,
- - "gmac_clkin" - external GMAC clock - optional
- - "phy_50m_out" - output clock of the pll in the mac phy
- - "hdmi_phy" - output clock of the hdmi phy pll - optional
-
-Example: Clock controller node:
-
- cru: clock-controller@ff440000 {
- compatible = "rockchip,rk3328-cru";
- reg = <0x0 0xff440000 0x0 0x1000>;
- rockchip,grf = <&grf>;
-
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller:
-
- uart0: serial@ff120000 {
- compatible = "snps,dw-apb-uart";
- reg = <0xff120000 0x100>;
- interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
- reg-shift = <2>;
- reg-io-width = <4>;
- clocks = <&cru SCLK_UART0>;
- };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.yaml
new file mode 100644
index 000000000000..f079c7a2559b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3328-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3328 Clock and Reset Unit (CRU)
+
+maintainers:
+ - Elaine Zhang <zhangqing@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description: |
+ The RK3328 clock controller generates and supplies clocks to various
+ controllers within the SoC and also implements a reset controller for SoC
+ peripherals.
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All available clocks are defined as
+ preprocessor macros in the dt-bindings/clock/rk3328-cru.h headers and can be
+ used in device tree sources. Similar macros exist for the reset sources in
+ these files.
+ There are several clocks that are generated outside the SoC. It is expected
+ that they are defined using standard clock bindings with following
+ clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "clkin_i2s" - external I2S clock - optional,
+ - "gmac_clkin" - external GMAC clock - optional
+ - "phy_50m_out" - output clock of the pll in the mac phy
+ - "hdmi_phy" - output clock of the hdmi phy pll - optional
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3328-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xin24m
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the "general register files" (GRF),
+ if missing pll rates are not changeable, due to the missing pll
+ lock status.
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ cru: clock-controller@ff440000 {
+ compatible = "rockchip,rk3328-cru";
+ reg = <0xff440000 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml
index adb67877720d..90af242b41c1 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3368-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml
index 54da1e31ea73..0b758e015ee3 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3399-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3506-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3506-cru.yaml
new file mode 100644
index 000000000000..ca940475336c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3506-cru.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3506-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3506 Clock and Reset Unit (CRU)
+
+maintainers:
+ - Finley Xiao <finley.xiao@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ The RK3506 CRU generates the clock and also implements reset for SoC
+ peripherals.
+
+properties:
+ compatible:
+ const: rockchip,rk3506-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xin
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@ff9a0000 {
+ compatible = "rockchip,rk3506-cru";
+ reg = <0xff9a0000 0x20000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&xin24m>;
+ clock-names = "xin";
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml
new file mode 100644
index 000000000000..5a3ec902351c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3528-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3528 Clock and Reset Controller
+
+maintainers:
+ - Yao Zi <ziyao@disroot.org>
+
+description: |
+ The RK3528 clock controller generates the clock and also implements a reset
+ controller for SoC peripherals. For example, it provides SCLK_UART0 and
+ PCLK_UART0 as well as SRST_P_UART0 and SRST_S_UART0 for the first UART
+ module.
+ Each clock is assigned an identifier, consumer nodes can use it to specify
+ the clock. All available clock and reset IDs are defined in dt-binding
+ headers.
+
+properties:
+ compatible:
+ const: rockchip,rk3528-cru
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: External 24MHz oscillator clock
+ - description: >
+ 50MHz clock generated by PHY module, for generating GMAC0 clocks only.
+
+ clock-names:
+ items:
+ - const: xin24m
+ - const: gmac0
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@ff4a0000 {
+ compatible = "rockchip,rk3528-cru";
+ reg = <0xff4a0000 0x30000>;
+ clocks = <&xin24m>, <&gmac0_clk>;
+ clock-names = "xin24m", "gmac0";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml
new file mode 100644
index 000000000000..36a353f5c42a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3562-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip rk3562 Clock and Reset Control Module
+
+maintainers:
+ - Elaine Zhang <zhangqing@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ The RK3562 clock controller generates the clock and also implements a reset
+ controller for SoC peripherals. For example it provides SCLK_UART2 and
+ PCLK_UART2, as well as SRST_P_UART2 and SRST_S_UART2 for the second UART
+ module.
+
+properties:
+ compatible:
+ const: rockchip,rk3562-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: xin24m
+ - const: xin32k
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@ff100000 {
+ compatible = "rockchip,rk3562-cru";
+ reg = <0xff100000 0x40000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml
index fc7546f521c5..f809c289445e 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/rockchip,rk3568-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ROCKCHIP rk3568 Family Clock Control Module Binding
+title: ROCKCHIP rk3568 Family Clock Control Module
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3576-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3576-cru.yaml
new file mode 100644
index 000000000000..9c9b36049c71
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3576-cru.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3576-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip rk3576 Family Clock and Reset Control Module
+
+maintainers:
+ - Elaine Zhang <zhangqing@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+ - Detlev Casanova <detlev.casanova@collabora.com>
+
+description:
+ The RK3576 clock controller generates the clock and also implements a reset
+ controller for SoC peripherals. For example it provides SCLK_UART2 and
+ PCLK_UART2, as well as SRST_P_UART2 and SRST_S_UART2 for the second UART
+ module.
+
+properties:
+ compatible:
+ const: rockchip,rk3576-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: xin24m
+ - const: xin32k
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@27200000 {
+ compatible = "rockchip,rk3576-cru";
+ reg = <0xfd7c0000 0x5c000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3588-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3588-cru.yaml
new file mode 100644
index 000000000000..4ff175c4992b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3588-cru.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rk3588-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip rk3588 Family Clock and Reset Control Module
+
+maintainers:
+ - Elaine Zhang <zhangqing@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description: |
+ The RK3588 clock controller generates the clock and also implements a reset
+ controller for SoC peripherals. For example it provides SCLK_UART2 and
+ PCLK_UART2, as well as SRST_P_UART2 and SRST_S_UART2 for the second UART
+ module.
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All available clock and reset IDs
+ are defined as preprocessor macros in dt-binding headers.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3588-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: xin24m
+ - const: xin32k
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: >
+ phandle to the syscon managing the "general register files". It is used
+ for GRF muxes, if missing any muxes present in the GRF will not be
+ available.
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ cru: clock-controller@fd7c0000 {
+ compatible = "rockchip,rk3588-cru";
+ reg = <0xfd7c0000 0x5c000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml
index 20421c22f184..4611d920b8df 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml
+++ b/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rv1108-cru.yaml#
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rv1126-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rv1126-cru.yaml
new file mode 100644
index 000000000000..0998f8b922bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rv1126-cru.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rv1126-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RV1126 Clock and Reset Unit
+
+maintainers:
+ - Jagan Teki <jagan@edgeble.ai>
+ - Finley Xiao <finley.xiao@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ The RV1126 clock controller generates the clock and also implements a
+ reset controller for SoC peripherals.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rv1126-cru
+ - rockchip,rv1126-pmucru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xin24m
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the "general register files" (GRF),
+ if missing pll rates are not changeable, due to the missing pll
+ lock status.
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ cru: clock-controller@ff490000 {
+ compatible = "rockchip,rv1126-cru";
+ reg = <0xff490000 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml
new file mode 100644
index 000000000000..04b0a5c51e4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/rockchip,rv1126b-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RV1126B Clock and Reset Unit
+
+maintainers:
+ - Elaine Zhang <zhangqing@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ The rv1126b clock controller generates the clock and also implements a
+ reset controller for SoC peripherals.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rv1126b-cru
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xin24m
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@20000000 {
+ compatible = "rockchip,rv1126b-cru";
+ reg = <0x20000000 0xc0000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml
index 0589a63e273a..a36781a455b6 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml
@@ -24,6 +24,7 @@ properties:
- samsung,exynos3250-cmu-dmc
- samsung,exynos3250-cmu-isp
- samsung,exynos4210-clock
+ - samsung,exynos4212-clock
- samsung,exynos4412-clock
- samsung,exynos5250-clock
- items:
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml
new file mode 100644
index 000000000000..89433e6d3518
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml
@@ -0,0 +1,247 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/samsung,exynos2200-cmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos2200 SoC clock controller
+
+maintainers:
+ - Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+ - Chanwoo Choi <cw00.choi@samsung.com>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ Exynos2200 clock controller is comprised of several CMU units, generating
+ clocks for different domains. Those CMU units are modeled as separate device
+ tree nodes, and might depend on each other. The root clocks in that root tree
+ are two external clocks: XTCXO (76.8 MHz) and RTCCLK (32768 Hz). XTCXO must be
+ defined as a fixed-rate clock in dts, whereas RTCCLK originates from PMIC.
+
+ CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+ dividers; all other clocks of function blocks (other CMUs) are usually
+ derived from CMU_TOP.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ 'include/dt-bindings/clock/samsung,exynos2200-cmu.h' header.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos2200-cmu-alive
+ - samsung,exynos2200-cmu-cmgp
+ - samsung,exynos2200-cmu-hsi0
+ - samsung,exynos2200-cmu-peric0
+ - samsung,exynos2200-cmu-peric1
+ - samsung,exynos2200-cmu-peric2
+ - samsung,exynos2200-cmu-peris
+ - samsung,exynos2200-cmu-top
+ - samsung,exynos2200-cmu-ufs
+ - samsung,exynos2200-cmu-vts
+
+ clocks:
+ minItems: 1
+ maxItems: 6
+
+ clock-names:
+ minItems: 1
+ maxItems: 6
+
+ "#clock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - "#clock-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-alive
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+ - description: CMU_ALIVE NOC clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-cmgp
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+ - description: CMU_CMGP NOC clock (from CMU_TOP)
+ - description: CMU_CMGP PERI clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: peri
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-hsi0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+ - description: External RTC clock (32768 Hz)
+ - description: CMU_HSI0 NOC clock (from CMU_TOP)
+ - description: CMU_HSI0 DPGTC clock (from CMU_TOP)
+ - description: CMU_HSI0 DPOSC clock (from CMU_TOP)
+ - description: CMU_HSI0 USB32DRD clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: rtcclk
+ - const: noc
+ - const: dpgtc
+ - const: dposc
+ - const: usb
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos2200-cmu-peric0
+ - samsung,exynos2200-cmu-peric1
+ - samsung,exynos2200-cmu-peric2
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+ - description: CMU_PERICn NOC clock (from CMU_TOP)
+ - description: CMU_PERICn IP0 clock (from CMU_TOP)
+ - description: CMU_PERICn IP1 clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: ip0
+ - const: ip1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-peris
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (25.6 MHz)
+ - description: CMU_PERIS NOC clock (from CMU_TOP)
+ - description: CMU_PERIS GIC clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: tcxo_div3
+ - const: noc
+ - const: gic
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-top
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+
+ clock-names:
+ items:
+ - const: oscclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-ufs
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+ - description: CMU_UFS NOC clock (from CMU_TOP)
+ - description: CMU_UFS MMC clock (from CMU_TOP)
+ - description: CMU_UFS UFS clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: mmc
+ - const: ufs
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-cmu-vts
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (76.8 MHz)
+ - description: CMU_VTS DMIC clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: dmic
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/samsung,exynos2200-cmu.h>
+
+ cmu_vts: clock-controller@15300000 {
+ compatible = "samsung,exynos2200-cmu-vts";
+ reg = <0x15300000 0x8000>;
+ #clock-cells = <1>;
+
+ clocks = <&oscclk>,
+ <&cmu_top CLK_DOUT_CMU_VTS_DMIC>;
+ clock-names = "oscclk", "dmic";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml
new file mode 100644
index 000000000000..3c58712f12b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml
@@ -0,0 +1,227 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/samsung,exynos7870-cmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos7870 SoC clock controller
+
+maintainers:
+ - Kaustabh Chakraborty <kauschluss@disroot.org>
+
+description: |
+ Exynos7870 clock controller is comprised of several CMU units, generating
+ clocks for different domains. Those CMU units are modeled as separate device
+ tree nodes, and might depend on each other. The root clock in that root tree
+ is an external clock: OSCCLK (26 MHz). This external clock must be defined
+ as a fixed-rate clock in dts.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ include/dt-bindings/clock/samsung,exynos7870-cmu.h header.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos7870-cmu-mif
+ - samsung,exynos7870-cmu-dispaud
+ - samsung,exynos7870-cmu-fsys
+ - samsung,exynos7870-cmu-g3d
+ - samsung,exynos7870-cmu-isp
+ - samsung,exynos7870-cmu-mfcmscl
+ - samsung,exynos7870-cmu-peri
+
+ clocks:
+ minItems: 1
+ maxItems: 10
+
+ clock-names:
+ minItems: 1
+ maxItems: 10
+
+ "#clock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - "#clock-cells"
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-mif
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+
+ clock-names:
+ items:
+ - const: oscclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-dispaud
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_DISPAUD bus clock (from CMU_MIF)
+ - description: DECON external clock (from CMU_MIF)
+ - description: DECON vertical clock (from CMU_MIF)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: decon_eclk
+ - const: decon_vclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-fsys
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_FSYS bus clock (from CMU_MIF)
+ - description: USB20DRD clock (from CMU_MIF)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: usb20drd
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-g3d
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: G3D switch clock (from CMU_MIF)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: switch
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-isp
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: ISP camera clock (from CMU_MIF)
+ - description: ISP clock (from CMU_MIF)
+ - description: ISP VRA clock (from CMU_MIF)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: cam
+ - const: isp
+ - const: vra
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-mfcmscl
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: MSCL clock (from CMU_MIF)
+ - description: MFC clock (from CMU_MIF)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: mfc
+ - const: mscl
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-cmu-peri
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_PERI bus clock (from CMU_MIF)
+ - description: SPI0 clock (from CMU_MIF)
+ - description: SPI1 clock (from CMU_MIF)
+ - description: SPI2 clock (from CMU_MIF)
+ - description: SPI3 clock (from CMU_MIF)
+ - description: SPI4 clock (from CMU_MIF)
+ - description: UART0 clock (from CMU_MIF)
+ - description: UART1 clock (from CMU_MIF)
+ - description: UART2 clock (from CMU_MIF)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: spi0
+ - const: spi1
+ - const: spi2
+ - const: spi3
+ - const: spi4
+ - const: uart0
+ - const: uart1
+ - const: uart2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/samsung,exynos7870-cmu.h>
+
+ cmu_peri: clock-controller@101f0000 {
+ compatible = "samsung,exynos7870-cmu-peri";
+ reg = <0x101f0000 0x1000>;
+ #clock-cells = <1>;
+
+ clock-names = "oscclk", "bus", "spi0", "spi1", "spi2",
+ "spi3", "spi4", "uart0", "uart1", "uart2";
+ clocks = <&oscclk>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_BUS>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI0>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI1>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI2>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI3>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI4>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_UART0>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_UART1>,
+ <&cmu_mif CLK_GOUT_MIF_CMU_PERI_UART2>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
index 141cf173f87d..cdc5ded59fe5 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
@@ -36,7 +36,10 @@ properties:
- samsung,exynos850-cmu-aud
- samsung,exynos850-cmu-cmgp
- samsung,exynos850-cmu-core
+ - samsung,exynos850-cmu-cpucl0
+ - samsung,exynos850-cmu-cpucl1
- samsung,exynos850-cmu-dpu
+ - samsung,exynos850-cmu-g3d
- samsung,exynos850-cmu-hsi
- samsung,exynos850-cmu-is
- samsung,exynos850-cmu-mfcmscl
@@ -155,6 +158,46 @@ allOf:
properties:
compatible:
contains:
+ const: samsung,exynos850-cmu-cpucl0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CPUCL0 switch clock (from CMU_TOP)
+ - description: CPUCL0 debug clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: dout_cpucl0_switch
+ - const: dout_cpucl0_dbg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos850-cmu-cpucl1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CPUCL1 switch clock (from CMU_TOP)
+ - description: CPUCL1 debug clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: dout_cpucl1_switch
+ - const: dout_cpucl1_dbg
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: samsung,exynos850-cmu-dpu
then:
@@ -173,6 +216,24 @@ allOf:
properties:
compatible:
contains:
+ const: samsung,exynos850-cmu-g3d
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: G3D clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: dout_g3d_switch
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: samsung,exynos850-cmu-hsi
then:
@@ -183,7 +244,7 @@ allOf:
- description: External RTC clock (32768 Hz)
- description: CMU_HSI bus clock (from CMU_TOP)
- description: SD card clock (from CMU_TOP)
- - description: "USB 2.0 DRD clock (from CMU_TOP)"
+ - description: USB 2.0 DRD clock (from CMU_TOP)
clock-names:
items:
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos8895-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos8895-clock.yaml
new file mode 100644
index 000000000000..111de33ce00b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos8895-clock.yaml
@@ -0,0 +1,239 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/samsung,exynos8895-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos8895 SoC clock controller
+
+maintainers:
+ - Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+ - Chanwoo Choi <cw00.choi@samsung.com>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ Exynos8895 clock controller is comprised of several CMU units, generating
+ clocks for different domains. Those CMU units are modeled as separate device
+ tree nodes, and might depend on each other. The root clock in that root tree
+ is an external clock: OSCCLK (26 MHz). This external clock must be defined
+ as a fixed-rate clock in dts.
+
+ CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+ dividers; all other clocks of function blocks (other CMUs) are usually
+ derived from CMU_TOP.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ 'include/dt-bindings/clock/samsung,exynos8895.h' header.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos8895-cmu-fsys0
+ - samsung,exynos8895-cmu-fsys1
+ - samsung,exynos8895-cmu-peric0
+ - samsung,exynos8895-cmu-peric1
+ - samsung,exynos8895-cmu-peris
+ - samsung,exynos8895-cmu-top
+
+ clocks:
+ minItems: 1
+ maxItems: 16
+
+ clock-names:
+ minItems: 1
+ maxItems: 16
+
+ "#clock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - "#clock-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos8895-cmu-fsys0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_FSYS0 BUS clock (from CMU_TOP)
+ - description: CMU_FSYS0 DPGTC clock (from CMU_TOP)
+ - description: CMU_FSYS0 MMC_EMBD clock (from CMU_TOP)
+ - description: CMU_FSYS0 UFS_EMBD clock (from CMU_TOP)
+ - description: CMU_FSYS0 USBDRD30 clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: dpgtc
+ - const: mmc
+ - const: ufs
+ - const: usbdrd30
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos8895-cmu-fsys1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_FSYS1 BUS clock (from CMU_TOP)
+ - description: CMU_FSYS1 PCIE clock (from CMU_TOP)
+ - description: CMU_FSYS1 UFS_CARD clock (from CMU_TOP)
+ - description: CMU_FSYS1 MMC_CARD clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: pcie
+ - const: ufs
+ - const: mmc
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos8895-cmu-peric0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_PERIC0 BUS clock (from CMU_TOP)
+ - description: CMU_PERIC0 UART_DBG clock (from CMU_TOP)
+ - description: CMU_PERIC0 USI00 clock (from CMU_TOP)
+ - description: CMU_PERIC0 USI01 clock (from CMU_TOP)
+ - description: CMU_PERIC0 USI02 clock (from CMU_TOP)
+ - description: CMU_PERIC0 USI03 clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: uart
+ - const: usi0
+ - const: usi1
+ - const: usi2
+ - const: usi3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos8895-cmu-peric1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_PERIC1 BUS clock (from CMU_TOP)
+ - description: CMU_PERIC1 SPEEDY2 clock (from CMU_TOP)
+ - description: CMU_PERIC1 SPI_CAM0 clock (from CMU_TOP)
+ - description: CMU_PERIC1 SPI_CAM1 clock (from CMU_TOP)
+ - description: CMU_PERIC1 UART_BT clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI04 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI05 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI06 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI07 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI08 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI09 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI10 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI11 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI12 clock (from CMU_TOP)
+ - description: CMU_PERIC1 USI13 clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: speedy
+ - const: cam0
+ - const: cam1
+ - const: uart
+ - const: usi4
+ - const: usi5
+ - const: usi6
+ - const: usi7
+ - const: usi8
+ - const: usi9
+ - const: usi10
+ - const: usi11
+ - const: usi12
+ - const: usi13
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos8895-cmu-peris
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_PERIS BUS clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos8895-cmu-top
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+
+ clock-names:
+ items:
+ - const: oscclk
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/samsung,exynos8895.h>
+
+ cmu_fsys1: clock-controller@11400000 {
+ compatible = "samsung,exynos8895-cmu-fsys1";
+ reg = <0x11400000 0x8000>;
+ #clock-cells = <1>;
+
+ clocks = <&oscclk>,
+ <&cmu_top CLK_DOUT_CMU_FSYS1_BUS>,
+ <&cmu_top CLK_DOUT_CMU_FSYS1_PCIE>,
+ <&cmu_top CLK_DOUT_CMU_FSYS1_UFS_CARD>,
+ <&cmu_top CLK_DOUT_CMU_FSYS1_MMC_CARD>;
+ clock-names = "oscclk", "bus", "pcie", "ufs", "mmc";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml
new file mode 100644
index 000000000000..5cd2d80b8ed6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/samsung,exynos990-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos990 SoC clock controller
+
+maintainers:
+ - Igor Belwon <igor.belwon@mentallysanemainliners.org>
+ - Chanwoo Choi <cw00.choi@samsung.com>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ Exynos990 clock controller is comprised of several CMU units, generating
+ clocks for different domains. Those CMU units are modeled as separate device
+ tree nodes, and might depend on each other. The root clock in that root tree
+ is an external clock: OSCCLK (26 MHz). This external clock must be defined
+ as a fixed-rate clock in dts.
+
+ CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+ dividers; all other clocks of function blocks (other CMUs) are usually
+ derived from CMU_TOP.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ 'include/dt-bindings/clock/samsung,exynos990.h' header.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos990-cmu-peric1
+ - samsung,exynos990-cmu-peric0
+ - samsung,exynos990-cmu-hsi0
+ - samsung,exynos990-cmu-peris
+ - samsung,exynos990-cmu-top
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+
+ clock-names:
+ minItems: 1
+ maxItems: 5
+
+ "#clock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - "#clock-cells"
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos990-cmu-peric1
+ - samsung,exynos990-cmu-peric0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: Connectivity Peripheral 0/1 bus clock (from CMU_TOP)
+ - description: Connectivity Peripheral 0/1 IP clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: ip
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos990-cmu-hsi0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_HSI0 BUS clock (from CMU_TOP)
+ - description: CMU_HSI0 USB31DRD clock (from CMU_TOP)
+ - description: CMU_HSI0 USBDP_DEBUG clock (from CMU_TOP)
+ - description: CMU_HSI0 DPGTC clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+ - const: usb31drd
+ - const: usbdp_debug
+ - const: dpgtc
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos990-cmu-peris
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: CMU_PERIS BUS clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos990-cmu-top
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+
+ clock-names:
+ items:
+ - const: oscclk
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/samsung,exynos990.h>
+
+ cmu_hsi0: clock-controller@10a00000 {
+ compatible = "samsung,exynos990-cmu-hsi0";
+ reg = <0x10a00000 0x8000>;
+ #clock-cells = <1>;
+
+ clocks = <&oscclk>,
+ <&cmu_top CLK_DOUT_CMU_HSI0_BUS>,
+ <&cmu_top CLK_DOUT_CMU_HSI0_USB31DRD>,
+ <&cmu_top CLK_DOUT_CMU_HSI0_USBDP_DEBUG>,
+ <&cmu_top CLK_DOUT_CMU_HSI0_DPGTC>;
+ clock-names = "oscclk",
+ "bus",
+ "usb31drd",
+ "usbdp_debug",
+ "dpgtc";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index 2ab4642679c0..32f39e543b36 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -35,6 +35,7 @@ properties:
- samsung,exynosautov9-cmu-top
- samsung,exynosautov9-cmu-busmc
- samsung,exynosautov9-cmu-core
+ - samsung,exynosautov9-cmu-dpum
- samsung,exynosautov9-cmu-fsys0
- samsung,exynosautov9-cmu-fsys1
- samsung,exynosautov9-cmu-fsys2
@@ -113,6 +114,24 @@ allOf:
properties:
compatible:
contains:
+ const: samsung,exynosautov9-cmu-dpum
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (26 MHz)
+ - description: DPU Main bus clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: bus
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: samsung,exynosautov9-cmu-fsys0
then:
@@ -148,7 +167,7 @@ allOf:
items:
- const: oscclk
- const: dout_clkcmu_fsys1_bus
- - const: dout_clkcmu_fsys1_mmc_card
+ - const: gout_clkcmu_fsys1_mmc_card
- const: dout_clkcmu_fsys1_usbdrd
- if:
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
new file mode 100644
index 000000000000..5bf905f88a1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
@@ -0,0 +1,298 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/samsung,exynosautov920-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung ExynosAuto v920 SoC clock controller
+
+maintainers:
+ - Sunyeal Hong <sunyeal.hong@samsung.com>
+ - Shin Son <shin.son@samsung.com>
+ - Chanwoo Choi <cw00.choi@samsung.com>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+description: |
+ ExynosAuto v920 clock controller is comprised of several CMU units, generating
+ clocks for different domains. Those CMU units are modeled as separate device
+ tree nodes, and might depend on each other. Root clocks in that clock tree are
+ two external clocks:: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ The external OSCCLK must be defined as fixed-rate clock in dts.
+
+ CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+ dividers; all other clocks of function blocks (other CMUs) are usually
+ derived from CMU_TOP.
+
+ Each clock is assigned an identifier and client nodes can use this identifier
+ to specify the clock which they consume. All clocks available for usage
+ in clock consumer nodes are defined as preprocessor macros in
+ 'include/dt-bindings/clock/samsung,exynosautov920.h' header.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynosautov920-cmu-cpucl0
+ - samsung,exynosautov920-cmu-cpucl1
+ - samsung,exynosautov920-cmu-cpucl2
+ - samsung,exynosautov920-cmu-hsi0
+ - samsung,exynosautov920-cmu-hsi1
+ - samsung,exynosautov920-cmu-hsi2
+ - samsung,exynosautov920-cmu-m2m
+ - samsung,exynosautov920-cmu-mfc
+ - samsung,exynosautov920-cmu-misc
+ - samsung,exynosautov920-cmu-peric0
+ - samsung,exynosautov920-cmu-peric1
+ - samsung,exynosautov920-cmu-top
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+
+ clock-names:
+ minItems: 1
+ maxItems: 5
+
+ "#clock-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynosautov920-cmu-top
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+
+ clock-names:
+ items:
+ - const: oscclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynosautov920-cmu-cpucl0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_CPUCL0 SWITCH clock (from CMU_TOP)
+ - description: CMU_CPUCL0 CLUSTER clock (from CMU_TOP)
+ - description: CMU_CPUCL0 DBG clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: switch
+ - const: cluster
+ - const: dbg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynosautov920-cmu-cpucl1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_CPUCL1 SWITCH clock (from CMU_TOP)
+ - description: CMU_CPUCL1 CLUSTER clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: switch
+ - const: cluster
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynosautov920-cmu-cpucl2
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_CPUCL2 SWITCH clock (from CMU_TOP)
+ - description: CMU_CPUCL2 CLUSTER clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: switch
+ - const: cluster
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynosautov920-cmu-peric0
+ - samsung,exynosautov920-cmu-peric1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_PERICn NOC clock (from CMU_TOP)
+ - description: CMU_PERICn IP clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: ip
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - samsung,exynosautov920-cmu-misc
+ - samsung,exynosautov920-cmu-hsi0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_MISC/CMU_HSI0 NOC clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynosautov920-cmu-hsi1
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_HSI1 NOC clock (from CMU_TOP)
+ - description: CMU_HSI1 USBDRD clock (from CMU_TOP)
+ - description: CMU_HSI1 MMC_CARD clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: usbdrd
+ - const: mmc_card
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynosautov920-cmu-hsi2
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_HSI2 NOC clock (from CMU_TOP)
+ - description: CMU_HSI2 NOC UFS clock (from CMU_TOP)
+ - description: CMU_HSI2 UFS EMBD clock (from CMU_TOP)
+ - description: CMU_HSI2 ETHERNET clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: ufs
+ - const: embd
+ - const: ethernet
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynosautov920-cmu-m2m
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_M2M NOC clock (from CMU_TOP)
+ - description: CMU_M2M JPEG clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: noc
+ - const: jpeg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynosautov920-cmu-mfc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (38.4 MHz)
+ - description: CMU_MFC MFC clock (from CMU_TOP)
+ - description: CMU_MFC WFD clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: mfc
+ - const: wfd
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - clock-names
+ - reg
+
+additionalProperties: false
+
+examples:
+ # Clock controller node for CMU_PERIC0
+ - |
+ #include <dt-bindings/clock/samsung,exynosautov920.h>
+
+ cmu_peric0: clock-controller@10800000 {
+ compatible = "samsung,exynosautov920-cmu-peric0";
+ reg = <0x10800000 0x8000>;
+ #clock-cells = <1>;
+
+ clocks = <&xtcxo>,
+ <&cmu_top DOUT_CLKCMU_PERIC0_NOC>,
+ <&cmu_top DOUT_CLKCMU_PERIC0_IP>;
+ clock-names = "oscclk",
+ "noc",
+ "ip";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml
index 9248bfc16d48..91d455155a60 100644
--- a/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml
@@ -25,6 +25,7 @@ description: |
properties:
compatible:
enum:
+ - samsung,s2mpg10-clk
- samsung,s2mps11-clk
- samsung,s2mps13-clk # S2MPS13 and S2MPS15
- samsung,s2mps14-clk
@@ -34,7 +35,6 @@ properties:
const: 1
clock-output-names:
- minItems: 3
maxItems: 3
description: Names for AP, CP and BT clocks.
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
deleted file mode 100644
index 2632d3f13004..000000000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Samsung S3C2410 Clock Controller
-
-The S3C2410 clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to the s3c2410,
-s3c2440 and s3c2442 SoCs in the s3c24x family.
-
-Required Properties:
-
-- compatible: should be one of the following.
- - "samsung,s3c2410-clock" - controller compatible with S3C2410 SoC.
- - "samsung,s3c2440-clock" - controller compatible with S3C2440 SoC.
- - "samsung,s3c2442-clock" - controller compatible with S3C2442 SoC.
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular SoC.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/s3c2410.h header and can be used in device
-tree sources.
-
-External clocks:
-
-The xti clock used as input for the plls is generated outside the SoC. It is
-expected that is are defined using standard clock bindings with a
-clock-output-names value of "xti".
-
-Example: Clock controller node:
-
- clocks: clock-controller@4c000000 {
- compatible = "samsung,s3c2410-clock";
- reg = <0x4c000000 0x20>;
- #clock-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- serial@50004000 {
- compatible = "samsung,s3c2440-uart";
- reg = <0x50004000 0x4000>;
- interrupts = <1 23 3 4>, <1 23 4 4>;
- clock-names = "uart", "clk_uart_baud2";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>;
- };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt
deleted file mode 100644
index 21a8c23e658f..000000000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Samsung S3C2412 Clock Controller
-
-The S3C2412 clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to the s3c2412
-and s3c2413 SoCs in the s3c24x family.
-
-Required Properties:
-
-- compatible: should be "samsung,s3c2412-clock"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular SoC.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/s3c2412.h header and can be used in device
-tree sources.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "xti" - crystal input - required,
- - "ext" - external clock source - optional,
-
-Example: Clock controller node:
-
- clocks: clock-controller@4c000000 {
- compatible = "samsung,s3c2412-clock";
- reg = <0x4c000000 0x20>;
- #clock-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- serial@50004000 {
- compatible = "samsung,s3c2412-uart";
- reg = <0x50004000 0x4000>;
- interrupts = <1 23 3 4>, <1 23 4 4>;
- clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
- <&clocks SCLK_UART>;
- };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
deleted file mode 100644
index 985c0f574e9a..000000000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-* Samsung S3C2443 Clock Controller
-
-The S3C2443 clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to all SoCs in
-the s3c24x family starting with the s3c2443.
-
-Required Properties:
-
-- compatible: should be one of the following.
- - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC.
- - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC.
- - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC.
-- reg: physical base address of the controller and length of memory mapped
- region.
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular SoC.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/s3c2443.h header and can be used in device
-tree sources.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "xti" - crystal input - required,
- - "ext" - external clock source - optional,
- - "ext_i2s" - external I2S clock - optional,
- - "ext_uart" - external uart clock - optional,
-
-Example: Clock controller node:
-
- clocks: clock-controller@4c000000 {
- compatible = "samsung,s3c2416-clock";
- reg = <0x4c000000 0x40>;
- #clock-cells = <1>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- serial@50004000 {
- compatible = "samsung,s3c2440-uart";
- reg = <0x50004000 0x4000>;
- interrupts = <1 23 3 4>, <1 23 4 4>;
- clock-names = "uart", "clk_uart_baud2",
- "clk_uart_baud3";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
- <&clocks SCLK_UART>;
- };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c6400-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s3c6400-clock.yaml
new file mode 100644
index 000000000000..0fcc0c963f8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c6400-clock.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/samsung,s3c6400-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S3C6400 SoC clock controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ There are several clocks that are generated outside the SoC. It is expected
+ that they are defined using standard clock bindings with following
+ clock-output-names and/or provided as clock inputs to this clock controller:
+ - "fin_pll" - PLL input clock (xtal/extclk) - required,
+ - "xusbxti" - USB xtal - required,
+ - "iiscdclk0" - I2S0 codec clock - optional,
+ - "iiscdclk1" - I2S1 codec clock - optional,
+ - "iiscdclk2" - I2S2 codec clock - optional,
+ - "pcmcdclk0" - PCM0 codec clock - optional,
+ - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
+
+ All available clocks are defined as preprocessor macros in
+ include/dt-bindings/clock/samsung,s3c64xx-clock.h header.
+
+properties:
+ compatible:
+ enum:
+ - samsung,s3c6400-clock
+ - samsung,s3c6410-clock
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@7e00f000 {
+ compatible = "samsung,s3c6410-clock";
+ reg = <0x7e00f000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&fin_pll>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
deleted file mode 100644
index 872ee8e0f041..000000000000
--- a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-* Samsung S3C64xx Clock Controller
-
-The S3C64xx clock controller generates and supplies clock to various controllers
-within the SoC. The clock binding described here is applicable to all SoCs in
-the S3C64xx family.
-
-Required Properties:
-
-- compatible: should be one of the following.
- - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
- - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
-
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-- #clock-cells: should be 1.
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Some of the clocks are available only
-on a particular S3C64xx SoC and this is specified where applicable.
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
-tree sources.
-
-External clocks:
-
-There are several clocks that are generated outside the SoC. It is expected
-that they are defined using standard clock bindings with following
-clock-output-names:
- - "fin_pll" - PLL input clock (xtal/extclk) - required,
- - "xusbxti" - USB xtal - required,
- - "iiscdclk0" - I2S0 codec clock - optional,
- - "iiscdclk1" - I2S1 codec clock - optional,
- - "iiscdclk2" - I2S2 codec clock - optional,
- - "pcmcdclk0" - PCM0 codec clock - optional,
- - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
-
-Example: Clock controller node:
-
- clock: clock-controller@7e00f000 {
- compatible = "samsung,s3c6410-clock";
- reg = <0x7e00f000 0x1000>;
- #clock-cells = <1>;
- };
-
-Example: Required external clocks:
-
- fin_pll: clock-fin-pll {
- compatible = "fixed-clock";
- clock-output-names = "fin_pll";
- clock-frequency = <12000000>;
- #clock-cells = <0>;
- };
-
- xusbxti: clock-xusbxti {
- compatible = "fixed-clock";
- clock-output-names = "xusbxti";
- clock-frequency = <48000000>;
- #clock-cells = <0>;
- };
-
-Example: UART controller node that consumes the clock generated by the clock
- controller (refer to the standard clock bindings for information about
- "clocks" and "clock-names" properties):
-
- uart0: serial@7f005000 {
- compatible = "samsung,s3c6400-uart";
- reg = <0x7f005000 0x100>;
- interrupt-parent = <&vic1>;
- interrupts = <5>;
- clock-names = "uart", "clk_uart_baud2",
- "clk_uart_baud3";
- clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
- <&clock SCLK_UART>;
- };
diff --git a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
index c3be1b600007..c79e752283aa 100644
--- a/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
+++ b/Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
@@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: SiFive FU540 Power Reset Clock Interrupt Controller (PRCI)
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
description:
diff --git a/Documentation/devicetree/bindings/clock/silabs,si514.txt b/Documentation/devicetree/bindings/clock/silabs,si514.txt
deleted file mode 100644
index a4f28ec86f35..000000000000
--- a/Documentation/devicetree/bindings/clock/silabs,si514.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Binding for Silicon Labs 514 programmable I2C clock generator.
-
-Reference
-This binding uses the common clock binding[1]. Details about the device can be
-found in the datasheet[2].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Si514 datasheet
- https://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf
-
-Required properties:
- - compatible: Shall be "silabs,si514"
- - reg: I2C device address.
- - #clock-cells: From common clock bindings: Shall be 0.
-
-Optional properties:
- - clock-output-names: From common clock bindings. Recommended to be "si514".
-
-Example:
- si514: clock-generator@55 {
- reg = <0x55>;
- #clock-cells = <0>;
- compatible = "silabs,si514";
- };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5341.txt b/Documentation/devicetree/bindings/clock/silabs,si5341.txt
deleted file mode 100644
index ce55aba0ce22..000000000000
--- a/Documentation/devicetree/bindings/clock/silabs,si5341.txt
+++ /dev/null
@@ -1,175 +0,0 @@
-Binding for Silicon Labs Si5340, Si5341 Si5342, Si5344 and Si5345 programmable
-i2c clock generator.
-
-Reference
-[1] Si5341 Data Sheet
- https://www.silabs.com/documents/public/data-sheets/Si5341-40-D-DataSheet.pdf
-[2] Si5341 Reference Manual
- https://www.silabs.com/documents/public/reference-manuals/Si5341-40-D-RM.pdf
-[3] Si5345 Reference Manual
- https://www.silabs.com/documents/public/reference-manuals/Si5345-44-42-D-RM.pdf
-
-The Si5341 and Si5340 are programmable i2c clock generators with up to 10 output
-clocks. The chip contains a PLL that sources 5 (or 4) multisynth clocks, which
-in turn can be directed to any of the 10 (or 4) outputs through a divider.
-The internal structure of the clock generators can be found in [2].
-The Si5345 is similar to the Si5341 with the addition of fractional input
-dividers and automatic input selection, as described in [3].
-The Si5342 and Si5344 are smaller versions of the Si5345, with 2 or 4 outputs.
-
-The driver can be used in "as is" mode, reading the current settings from the
-chip at boot, in case you have a (pre-)programmed device. If the PLL is not
-configured when the driver probes, it assumes the driver must fully initialize
-it.
-
-The device type, speed grade and revision are determined runtime by probing.
-
-The driver currently does not support any fancy input configurations. They can
-still be programmed into the chip and the driver will leave them "as is".
-
-==I2C device node==
-
-Required properties:
-- compatible: shall be one of the following:
- "silabs,si5340" - Si5340 A/B/C/D
- "silabs,si5341" - Si5341 A/B/C/D
- "silabs,si5342" - Si5342 A/B/C/D
- "silabs,si5344" - Si5344 A/B/C/D
- "silabs,si5345" - Si5345 A/B/C/D
-- reg: i2c device address, usually 0x74
-- #clock-cells: from common clock binding; shall be set to 2.
- The first value is "0" for outputs, "1" for synthesizers.
- The second value is the output or synthesizer index.
-- clocks: from common clock binding; list of parent clock handles,
- corresponding to inputs. Use a fixed clock for the "xtal" input.
- At least one must be present.
-- clock-names: One of: "xtal", "in0", "in1", "in2"
-
-Optional properties:
-- vdd-supply: Regulator node for VDD
-- vdda-supply: Regulator node for VDDA
-- vdds-supply: Regulator node for VDDS
-- silabs,pll-m-num, silabs,pll-m-den: Numerator and denominator for PLL
- feedback divider. Must be such that the PLL output is in the valid range. For
- example, to create 14GHz from a 48MHz xtal, use m-num=14000 and m-den=48. Only
- the fraction matters, using 3500 and 12 will deliver the exact same result.
- If these are not specified, and the PLL is not yet programmed when the driver
- probes, the PLL will be set to 14GHz.
-- silabs,reprogram: When present, the driver will always assume the device must
- be initialized, and always performs the soft-reset routine. Since this will
- temporarily stop all output clocks, don't do this if the chip is generating
- the CPU clock for example.
-- silabs,xaxb-ext-clk: When present, indicates that the XA/XB pins are used
- in EXTCLK (external reference clock) rather than XTAL (crystal) mode.
-- interrupts: Interrupt for INTRb pin.
-- silabs,iovdd-33: When present, indicates that the I2C lines are using 3.3V
- rather than 1.8V thresholds.
-- vddoX-supply (where X is an output index): Regulator node for VDDO for the
- specified output. The driver selects the output VDD_SEL setting based on this
- voltage.
-- #address-cells: shall be set to 1.
-- #size-cells: shall be set to 0.
-
-
-== Child nodes: Outputs ==
-
-The child nodes list the output clocks.
-
-Each of the clock outputs can be overwritten individually by using a child node.
-If a child node for a clock output is not set, the configuration remains
-unchanged.
-
-Required child node properties:
-- reg: number of clock output.
-
-Optional child node properties:
-- silabs,format: Output format, one of:
- 1 = differential (defaults to LVDS levels)
- 2 = low-power (defaults to HCSL levels)
- 4 = LVCMOS
-- silabs,common-mode: Manually override output common mode, see [2] for values
-- silabs,amplitude: Manually override output amplitude, see [2] for values
-- silabs,synth-master: boolean. If present, this output is allowed to change the
- multisynth frequency dynamically.
-- silabs,silabs,disable-high: boolean. If set, the clock output is driven HIGH
- when disabled, otherwise it's driven LOW.
-
-==Example==
-
-/* 48MHz reference crystal */
-ref48: ref48M {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <48000000>;
-};
-
-i2c-master-node {
- /* Programmable clock (for logic) */
- si5341: clock-generator@74 {
- reg = <0x74>;
- compatible = "silabs,si5341";
- #clock-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&ref48>;
- clock-names = "xtal";
-
- silabs,pll-m-num = <14000>; /* PLL at 14.0 GHz */
- silabs,pll-m-den = <48>;
- silabs,reprogram; /* Chips are not programmed, always reset */
-
- out@0 {
- reg = <0>;
- silabs,format = <1>; /* LVDS 3v3 */
- silabs,common-mode = <3>;
- silabs,amplitude = <3>;
- silabs,synth-master;
- };
-
- /*
- * Output 6 configuration:
- * LVDS 1v8
- */
- out@6 {
- reg = <6>;
- silabs,format = <1>; /* LVDS 1v8 */
- silabs,common-mode = <13>;
- silabs,amplitude = <3>;
- };
-
- /*
- * Output 8 configuration:
- * HCSL 3v3
- */
- out@8 {
- reg = <8>;
- silabs,format = <2>;
- silabs,common-mode = <11>;
- silabs,amplitude = <3>;
- };
- };
-};
-
-some-video-node {
- /* Standard clock bindings */
- clock-names = "pixel";
- clocks = <&si5341 0 7>; /* Output 7 */
-
- /* Set output 7 to use syntesizer 3 as its parent */
- assigned-clocks = <&si5341 0 7>, <&si5341 1 3>;
- assigned-clock-parents = <&si5341 1 3>;
- /* Set output 7 to 148.5 MHz using a synth frequency of 594 MHz */
- assigned-clock-rates = <148500000>, <594000000>;
-};
-
-some-audio-node {
- clock-names = "i2s-clk";
- clocks = <&si5341 0 0>;
- /*
- * since output 0 is a synth-master, the synth will be automatically set
- * to an appropriate frequency when the audio driver requests another
- * frequency. We give control over synth 2 to this output here.
- */
- assigned-clocks = <&si5341 0 0>;
- assigned-clock-parents = <&si5341 1 2>;
-};
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5341.yaml b/Documentation/devicetree/bindings/clock/silabs,si5341.yaml
new file mode 100644
index 000000000000..d6416bded3d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5341.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/silabs,si5341.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Labs Si5340/1/2/4/5 programmable i2c clock generator
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: >
+ Silicon Labs Si5340, Si5341 Si5342, Si5344 and Si5345 programmable i2c clock
+ generator.
+
+ Reference
+ [1] Si5341 Data Sheet
+ https://www.silabs.com/documents/public/data-sheets/Si5341-40-D-DataSheet.pdf
+ [2] Si5341 Reference Manual
+ https://www.silabs.com/documents/public/reference-manuals/Si5341-40-D-RM.pdf
+ [3] Si5345 Reference Manual
+ https://www.silabs.com/documents/public/reference-manuals/Si5345-44-42-D-RM.pdf
+
+ The Si5341 and Si5340 are programmable i2c clock generators with up to 10 output
+ clocks. The chip contains a PLL that sources 5 (or 4) multisynth clocks, which
+ in turn can be directed to any of the 10 (or 4) outputs through a divider.
+ The internal structure of the clock generators can be found in [2].
+ The Si5345 is similar to the Si5341 with the addition of fractional input
+ dividers and automatic input selection, as described in [3].
+ The Si5342 and Si5344 are smaller versions of the Si5345, with 2 or 4 outputs.
+
+ The driver can be used in "as is" mode, reading the current settings from the
+ chip at boot, in case you have a (pre-)programmed device. If the PLL is not
+ configured when the driver probes, it assumes the driver must fully initialize
+ it.
+
+ The device type, speed grade and revision are determined runtime by probing.
+
+properties:
+ compatible:
+ enum:
+ - silabs,si5340
+ - silabs,si5341
+ - silabs,si5342
+ - silabs,si5344
+ - silabs,si5345
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 2
+ description: >
+ The first value is "0" for outputs, "1" for synthesizers.
+
+ The second value is the output or synthesizer index.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: xtal
+ - const: in0
+ - const: in1
+ - const: in2
+
+ clock-output-names: true
+
+ interrupts:
+ maxItems: 1
+ description: Interrupt for INTRb pin
+
+ vdd-supply:
+ description: Regulator node for VDD
+
+ vdda-supply:
+ description: Regulator node for VDDA
+
+ vdds-supply:
+ description: Regulator node for VDDS
+
+ silabs,pll-m-num:
+ description:
+ Numerator for PLL feedback divider. Must be such that the PLL output is in
+ the valid range. For example, to create 14GHz from a 48MHz xtal, use
+ m-num=14000 and m-den=48. Only the fraction matters, using 3500 and 12
+ will deliver the exact same result. If these are not specified, and the
+ PLL is not yet programmed when the driver probes, the PLL will be set to
+ 14GHz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ silabs,pll-m-den:
+ description: Denominator for PLL feedback divider
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ silabs,reprogram:
+ description: Always perform soft-reset and reinitialize PLL
+ type: boolean
+
+ silabs,xaxb-ext-clk:
+ description: Use XA/XB pins as external reference clock
+ type: boolean
+
+ silabs,iovdd-33:
+ description: I2C lines use 3.3V thresholds
+ type: boolean
+
+patternProperties:
+ "^vddo[0-9]-supply$": true
+
+ "^out@[0-9]$":
+ description: >
+ Output-specific override nodes
+
+ Each of the clock outputs can be overwritten individually by using a child
+ node. If a child node for a clock output is not set, the configuration
+ remains unchanged.
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ description: Number of clock output
+ maximum: 9
+
+ always-on:
+ description: Set to keep the clock output always running
+ type: boolean
+
+ silabs,format:
+ description: Output format
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4]
+
+ silabs,common-mode:
+ description: Override output common mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ silabs,amplitude:
+ description: Override output amplitude
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ silabs,synth-master:
+ description: Allow dynamic multisynth rate control
+ type: boolean
+
+ silabs,disable-high:
+ description: Drive output HIGH when disabled
+ type: boolean
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#address-cells"
+ - "#size-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-generator@74 {
+ reg = <0x74>;
+ compatible = "silabs,si5341";
+ #clock-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&ref48>;
+ clock-names = "xtal";
+
+ silabs,pll-m-num = <14000>; /* PLL at 14.0 GHz */
+ silabs,pll-m-den = <48>;
+ silabs,reprogram; /* Chips are not programmed, always reset */
+
+ out@0 {
+ reg = <0>;
+ silabs,format = <1>; /* LVDS 3v3 */
+ silabs,common-mode = <3>;
+ silabs,amplitude = <3>;
+ silabs,synth-master;
+ };
+
+ /*
+ * Output 6 configuration:
+ * LVDS 1v8
+ */
+ out@6 {
+ reg = <6>;
+ silabs,format = <1>; /* LVDS 1v8 */
+ silabs,common-mode = <13>;
+ silabs,amplitude = <3>;
+ };
+
+ /*
+ * Output 8 configuration:
+ * HCSL 3v3
+ */
+ out@8 {
+ reg = <8>;
+ silabs,format = <2>;
+ silabs,common-mode = <11>;
+ silabs,amplitude = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
deleted file mode 100644
index bfda6af76bee..000000000000
--- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
-
-Reference
-[1] Si5351A/B/C Data Sheet
- https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/data-sheets/Si5351-B.pdf
-
-The Si5351a/b/c are programmable i2c clock generators with up to 8 output
-clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
-3 output clocks are accessible. The internal structure of the clock
-generators can be found in [1].
-
-==I2C device node==
-
-Required properties:
-- compatible: shall be one of the following:
- "silabs,si5351a" - Si5351a, QFN20 package
- "silabs,si5351a-msop" - Si5351a, MSOP10 package
- "silabs,si5351b" - Si5351b, QFN20 package
- "silabs,si5351c" - Si5351c, QFN20 package
-- reg: i2c device address, shall be 0x60 or 0x61.
-- #clock-cells: from common clock binding; shall be set to 1.
-- clocks: from common clock binding; list of parent clock
- handles, shall be xtal reference clock or xtal and clkin for
- si5351c only. Corresponding clock input names are "xtal" and
- "clkin" respectively.
-- #address-cells: shall be set to 1.
-- #size-cells: shall be set to 0.
-
-Optional properties:
-- silabs,pll-source: pair of (number, source) for each pll. Allows
- to overwrite clock source of pll A (number=0) or B (number=1).
-
-==Child nodes==
-
-Each of the clock outputs can be overwritten individually by
-using a child node to the I2C device node. If a child node for a clock
-output is not set, the eeprom configuration is not overwritten.
-
-Required child node properties:
-- reg: number of clock output.
-
-Optional child node properties:
-- silabs,clock-source: source clock of the output divider stage N, shall be
- 0 = multisynth N
- 1 = multisynth 0 for output clocks 0-3, else multisynth4
- 2 = xtal
- 3 = clkin (si5351c only)
-- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
-- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
- divider.
-- silabs,pll-master: boolean, multisynth can change pll frequency.
-- silabs,pll-reset: boolean, clock output can reset its pll.
-- silabs,disable-state : clock output disable state, shall be
- 0 = clock output is driven LOW when disabled
- 1 = clock output is driven HIGH when disabled
- 2 = clock output is FLOATING (HIGH-Z) when disabled
- 3 = clock output is NEVER disabled
-
-==Example==
-
-/* 25MHz reference crystal */
-ref25: ref25M {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <25000000>;
-};
-
-i2c-master-node {
-
- /* Si5351a msop10 i2c clock generator */
- si5351a: clock-generator@60 {
- compatible = "silabs,si5351a-msop";
- reg = <0x60>;
- #address-cells = <1>;
- #size-cells = <0>;
- #clock-cells = <1>;
-
- /* connect xtal input to 25MHz reference */
- clocks = <&ref25>;
- clock-names = "xtal";
-
- /* connect xtal input as source of pll0 and pll1 */
- silabs,pll-source = <0 0>, <1 0>;
-
- /*
- * overwrite clkout0 configuration with:
- * - 8mA output drive strength
- * - pll0 as clock source of multisynth0
- * - multisynth0 as clock source of output divider
- * - multisynth0 can change pll0
- * - set initial clock frequency of 74.25MHz
- */
- clkout0 {
- reg = <0>;
- silabs,drive-strength = <8>;
- silabs,multisynth-source = <0>;
- silabs,clock-source = <0>;
- silabs,pll-master;
- clock-frequency = <74250000>;
- };
-
- /*
- * overwrite clkout1 configuration with:
- * - 4mA output drive strength
- * - pll1 as clock source of multisynth1
- * - multisynth1 as clock source of output divider
- * - multisynth1 can change pll1
- */
- clkout1 {
- reg = <1>;
- silabs,drive-strength = <4>;
- silabs,multisynth-source = <1>;
- silabs,clock-source = <0>;
- pll-master;
- };
-
- /*
- * overwrite clkout2 configuration with:
- * - xtal as clock source of output divider
- */
- clkout2 {
- reg = <2>;
- silabs,clock-source = <2>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.yaml b/Documentation/devicetree/bindings/clock/silabs,si5351.yaml
new file mode 100644
index 000000000000..d3e0ec29993b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.yaml
@@ -0,0 +1,265 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/silabs,si5351.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Labs Si5351A/B/C programmable I2C clock generators
+
+description: |
+ The Silicon Labs Si5351A/B/C are programmable I2C clock generators with up to
+ 8 outputs. Si5351A also has a reduced pin-count package (10-MSOP) where only 3
+ output clocks are accessible. The internal structure of the clock generators
+ can be found in [1].
+
+ [1] Si5351A/B/C Data Sheet
+ https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/data-sheets/Si5351-B.pdf
+
+maintainers:
+ - Alvin Šipraga <alsi@bang-olufsen.dk>
+
+properties:
+ compatible:
+ enum:
+ - silabs,si5351a # Si5351A, 20-QFN package
+ - silabs,si5351a-msop # Si5351A, 10-MSOP package
+ - silabs,si5351b # Si5351B, 20-QFN package
+ - silabs,si5351c # Si5351C, 20-QFN package
+
+ reg:
+ enum:
+ - 0x60
+ - 0x61
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: xtal
+ - const: clkin
+
+ silabs,pll-source:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ A list of cell pairs containing a PLL index and its source. Allows to
+ overwrite clock source of the internal PLLs.
+ items:
+ items:
+ - description: PLL A (0) or PLL B (1)
+ enum: [ 0, 1 ]
+ - description: PLL source, XTAL (0) or CLKIN (1, Si5351C only).
+ enum: [ 0, 1 ]
+
+ silabs,pll-reset-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 2
+ description: A list of cell pairs containing a PLL index and its reset mode.
+ items:
+ items:
+ - description: PLL A (0) or PLL B (1)
+ enum: [ 0, 1 ]
+ - description: |
+ Reset mode for the PLL. Mode can be one of:
+
+ 0 - reset whenever PLL rate is adjusted (default mode)
+ 1 - do not reset when PLL rate is adjusted
+
+ In mode 1, the PLL is only reset if the silabs,pll-reset is
+ specified in one of the clock output child nodes that also sources
+ the PLL. This mode may be preferable if output clocks are expected
+ to be adjusted without glitches.
+ enum: [ 0, 1 ]
+
+patternProperties:
+ "^clkout@[0-7]$":
+ type: object
+
+ additionalProperties: false
+
+ properties:
+ reg:
+ description: Clock output number.
+
+ clock-frequency: true
+
+ silabs,clock-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Source clock of the this output's divider stage.
+
+ 0 - use multisynth N for this output, where N is the output number
+ 1 - use either multisynth 0 (if output number is 0-3) or multisynth 4
+ (otherwise) for this output
+ 2 - use XTAL for this output
+ 3 - use CLKIN for this output (Si5351C only)
+
+ silabs,drive-strength:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 2, 4, 6, 8 ]
+ description: Output drive strength in mA.
+
+ silabs,multisynth-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Source PLL A (0) or B (1) for the corresponding multisynth divider.
+
+ silabs,pll-master:
+ type: boolean
+ description: |
+ The frequency of the source PLL is allowed to be changed by the
+ multisynth when setting the rate of this clock output.
+
+ silabs,pll-reset:
+ type: boolean
+ description: Reset the source PLL when enabling this clock output.
+
+ silabs,disable-state:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ Clock output disable state. The state can be one of:
+
+ 0 - clock output is driven LOW when disabled
+ 1 - clock output is driven HIGH when disabled
+ 2 - clock output is FLOATING (HIGH-Z) when disabled
+ 3 - clock output is never disabled
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: silabs,si5351a-msop
+ then:
+ properties:
+ reg:
+ maximum: 2
+ else:
+ properties:
+ reg:
+ maximum: 7
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: silabs,si5351c
+ then:
+ properties:
+ silabs,clock-source:
+ enum: [ 0, 1, 2, 3 ]
+ else:
+ properties:
+ silabs,clock-source:
+ enum: [ 0, 1, 2 ]
+
+ required:
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - silabs,si5351a
+ - silabs,si5351a-msop
+ - silabs,si5351b
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
+required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - "#clock-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-generator@60 {
+ compatible = "silabs,si5351a-msop";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ /* Connect XTAL input to 25MHz reference */
+ clocks = <&ref25>;
+ clock-names = "xtal";
+
+ /* Use XTAL input as source of PLL0 and PLL1 */
+ silabs,pll-source = <0 0>, <1 0>;
+
+ /* Don't reset PLL1 on rate adjustment */
+ silabs,pll-reset-mode = <1 1>;
+
+ /*
+ * Overwrite CLK0 configuration with:
+ * - 8 mA output drive strength
+ * - PLL0 as clock source of multisynth 0
+ * - Multisynth 0 as clock source of output divider
+ * - Multisynth 0 can change PLL0
+ * - Set initial clock frequency of 74.25MHz
+ */
+ clkout@0 {
+ reg = <0>;
+ silabs,drive-strength = <8>;
+ silabs,multisynth-source = <0>;
+ silabs,clock-source = <0>;
+ silabs,pll-master;
+ clock-frequency = <74250000>;
+ };
+
+ /*
+ * Overwrite CLK1 configuration with:
+ * - 4 mA output drive strength
+ * - PLL1 as clock source of multisynth 1
+ * - Multisynth 1 as clock source of output divider
+ * - Multisynth 1 can change PLL1
+ * - Reset PLL1 when enabling this clock output
+ */
+ clkout@1 {
+ reg = <1>;
+ silabs,drive-strength = <4>;
+ silabs,multisynth-source = <1>;
+ silabs,clock-source = <0>;
+ silabs,pll-master;
+ silabs,pll-reset;
+ };
+
+ /*
+ * Overwrite CLK2 configuration with:
+ * - XTAL as clock source of output divider
+ */
+ clkout@2 {
+ reg = <2>;
+ silabs,clock-source = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si544.txt b/Documentation/devicetree/bindings/clock/silabs,si544.txt
deleted file mode 100644
index b86535b80920..000000000000
--- a/Documentation/devicetree/bindings/clock/silabs,si544.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Binding for Silicon Labs 544 programmable I2C clock generator.
-
-Reference
-This binding uses the common clock binding[1]. Details about the device can be
-found in the datasheet[2].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Si544 datasheet
- https://www.silabs.com/documents/public/data-sheets/si544-datasheet.pdf
-
-Required properties:
- - compatible: One of "silabs,si514a", "silabs,si514b" "silabs,si514c" according
- to the speed grade of the chip.
- - reg: I2C device address.
- - #clock-cells: From common clock bindings: Shall be 0.
-
-Optional properties:
- - clock-output-names: From common clock bindings. Recommended to be "si544".
-
-Example:
- si544: clock-controller@55 {
- reg = <0x55>;
- #clock-cells = <0>;
- compatible = "silabs,si544b";
- };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si544.yaml b/Documentation/devicetree/bindings/clock/silabs,si544.yaml
new file mode 100644
index 000000000000..f87e71867108
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si544.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/silabs,si544.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Labs SI514/SI544 clock generator
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: >
+ Silicon Labs 514/544 programmable I2C clock generator. Details about the device
+ can be found in the datasheet:
+
+ https://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf
+ https://www.silabs.com/documents/public/data-sheets/si544-datasheet.pdf
+
+properties:
+ compatible:
+ enum:
+ - silabs,si514
+ - silabs,si544a
+ - silabs,si544b
+ - silabs,si544c
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@55 {
+ reg = <0x55>;
+ #clock-cells = <0>;
+ compatible = "silabs,si544b";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.txt b/Documentation/devicetree/bindings/clock/silabs,si570.txt
deleted file mode 100644
index 5dda17df1ac5..000000000000
--- a/Documentation/devicetree/bindings/clock/silabs,si570.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Binding for Silicon Labs 570, 571, 598 and 599 programmable
-I2C clock generators.
-
-Reference
-This binding uses the common clock binding[1]. Details about the devices can be
-found in the data sheets[2][3].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Si570/571 Data Sheet
- https://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
-[3] Si598/599 Data Sheet
- https://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
-
-Required properties:
- - compatible: Shall be one of "silabs,si570", "silabs,si571",
- "silabs,si598", "silabs,si599"
- - reg: I2C device address.
- - #clock-cells: From common clock bindings: Shall be 0.
- - factory-fout: Factory set default frequency. This frequency is part specific.
- The correct frequency for the part used has to be provided in
- order to generate the correct output frequencies. For more
- details, please refer to the data sheet.
- - temperature-stability: Temperature stability of the device in PPM. Should be
- one of: 7, 20, 50 or 100.
-
-Optional properties:
- - clock-output-names: From common clock bindings. Recommended to be "si570".
- - clock-frequency: Output frequency to generate. This defines the output
- frequency set during boot. It can be reprogrammed during
- runtime through the common clock framework.
- - silabs,skip-recall: Do not perform NVM->RAM recall operation. It will rely
- on hardware loading of RAM from NVM at power on.
-
-Example:
- si570: clock-generator@5d {
- #clock-cells = <0>;
- compatible = "silabs,si570";
- temperature-stability = <50>;
- reg = <0x5d>;
- factory-fout = <156250000>;
- };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.yaml b/Documentation/devicetree/bindings/clock/silabs,si570.yaml
new file mode 100644
index 000000000000..90e2f79e2b2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si570.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/silabs,si570.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Labs Si570/Si571/Si598/Si599 programmable I2C clock generator
+
+maintainers:
+ - Soren Brinkmann <soren.brinkmann@xilinx.com>
+
+description: >
+ Silicon Labs 570, 571, 598 and 599 programmable I2C clock generators. Details
+ about the devices can be found in the data sheets[1][2].
+
+ [1] Si570/571 Data Sheet
+ https://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
+ [2] Si598/599 Data Sheet
+ https://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
+
+properties:
+ compatible:
+ enum:
+ - silabs,si570
+ - silabs,si571
+ - silabs,si598
+ - silabs,si599
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ factory-fout:
+ description: Factory-set default frequency in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ temperature-stability:
+ description: Temperature stability of the device in PPM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 7
+ - 20
+ - 50
+ - 100
+
+ clock-output-names:
+ maxItems: 1
+
+ clock-frequency:
+ description: Output frequency to generate at boot; can be reprogrammed at runtime.
+
+ silabs,skip-recall:
+ description: Skip the NVM-to-RAM recall operation during boot.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - factory-fout
+ - temperature-stability
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-generator@5d {
+ compatible = "silabs,si570";
+ reg = <0x5d>;
+ #clock-cells = <0>;
+ temperature-stability = <50>;
+ factory-fout = <156250000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml b/Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml
new file mode 100644
index 000000000000..9e35e0e51ce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/skyworks,si521xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Skyworks Si521xx I2C PCIe clock generators
+
+description: |
+ The Skyworks Si521xx are I2C PCIe clock generators providing
+ from 4 to 9 output clocks.
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+properties:
+ compatible:
+ enum:
+ - skyworks,si52144
+ - skyworks,si52146
+ - skyworks,si52147
+
+ reg:
+ const: 0x6b
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: XTal input clock
+
+ skyworks,out-amplitude-microvolt:
+ enum: [ 300000, 400000, 500000, 600000, 700000, 800000, 900000, 1000000 ]
+ description: Output clock signal amplitude
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-generator@6b {
+ compatible = "skyworks,si52144";
+ reg = <0x6b>;
+ #clock-cells = <1>;
+ clocks = <&ref25m>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
index 9a0cc7341630..4e82582fb2f3 100644
--- a/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
@@ -61,40 +61,7 @@ required:
examples:
- |
- sysctrl@61840000 {
- compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon";
- reg = <0x61840000 0x4000>;
-
- clock {
- compatible = "socionext,uniphier-ld11-clock";
- #clock-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- mioctrl@59810000 {
- compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon";
- reg = <0x59810000 0x800>;
-
- clock {
- compatible = "socionext,uniphier-ld11-mio-clock";
- #clock-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- perictrl@59820000 {
- compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon";
- reg = <0x59820000 0x200>;
-
- clock {
- compatible = "socionext,uniphier-ld11-peri-clock";
- #clock-cells = <1>;
- };
-
- // other nodes ...
+ clock-controller {
+ compatible = "socionext,uniphier-ld11-clock";
+ #clock-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/clock/sophgo,cv1800-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,cv1800-clk.yaml
new file mode 100644
index 000000000000..379ce3e9e391
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sophgo,cv1800-clk.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sophgo,cv1800-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800/SG2000 Series Clock Controller
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - sophgo,cv1800b-clk
+ - sophgo,cv1812h-clk
+ - sophgo,sg2000-clk
+ - items:
+ - const: sophgo,sg2002-clk
+ - const: sophgo,sg2000-clk
+ - const: sophgo,cv1800-clk
+ deprecated: true
+ - const: sophgo,cv1810-clk
+ deprecated: true
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+ description:
+ See <dt-bindings/clock/sophgo,cv1800.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@3002000 {
+ compatible = "sophgo,cv1800-clk";
+ reg = <0x03002000 0x1000>;
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2042-clkgen.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2042-clkgen.yaml
new file mode 100644
index 000000000000..e7a9255bcb58
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sophgo,sg2042-clkgen.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sophgo,sg2042-clkgen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 Clock Generator for divider/mux/gate
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+properties:
+ compatible:
+ const: sophgo,sg2042-clkgen
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Main PLL
+ - description: Fixed PLL
+ - description: DDR PLL 0
+ - description: DDR PLL 1
+
+ clock-names:
+ items:
+ - const: mpll
+ - const: fpll
+ - const: dpll0
+ - const: dpll1
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/sophgo,sg2042-clkgen.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@30012000 {
+ compatible = "sophgo,sg2042-clkgen";
+ reg = <0x30012000 0x1000>;
+ clocks = <&pllclk 0>,
+ <&pllclk 1>,
+ <&pllclk 2>,
+ <&pllclk 3>;
+ clock-names = "mpll",
+ "fpll",
+ "dpll0",
+ "dpll1";
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2042-pll.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2042-pll.yaml
new file mode 100644
index 000000000000..1a417a627dd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sophgo,sg2042-pll.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sophgo,sg2042-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 PLL Clock Generator
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+properties:
+ compatible:
+ const: sophgo,sg2042-pll
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Oscillator(Clock Generation IC) for Main/Fixed PLL (25 MHz)
+ - description: Oscillator(Clock Generation IC) for DDR PLL 0 (25 MHz)
+ - description: Oscillator(Clock Generation IC) for DDR PLL 1 (25 MHz)
+
+ clock-names:
+ items:
+ - const: cgi_main
+ - const: cgi_dpll0
+ - const: cgi_dpll1
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/sophgo,sg2042-pll.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@10000000 {
+ compatible = "sophgo,sg2042-pll";
+ reg = <0x10000000 0x10000>;
+ clocks = <&cgi_main>, <&cgi_dpll0>, <&cgi_dpll1>;
+ clock-names = "cgi_main", "cgi_dpll0", "cgi_dpll1";
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml
new file mode 100644
index 000000000000..1491fb8ef6a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sophgo,sg2042-rpgate.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sophgo,sg2042-rpgate.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 Gate Clock Generator for RP(riscv processors) subsystem
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+properties:
+ compatible:
+ const: sophgo,sg2042-rpgate
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Gate clock for RP subsystem
+
+ clock-names:
+ items:
+ - const: rpgate
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/sophgo,sg2042-rpgate.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@20000000 {
+ compatible = "sophgo,sg2042-rpgate";
+ reg = <0x20000000 0x10000>;
+ clocks = <&clkgen 85>;
+ clock-names = "rpgate";
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml
new file mode 100644
index 000000000000..272e58bdb62c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sophgo,sg2044-clk.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sophgo,sg2044-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2044 Clock Controller
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+description: |
+ The Sophgo SG2044 clock controller requires an external oscillator
+ as input clock.
+
+ All available clocks are defined as preprocessor macros in
+ include/dt-bindings/clock/sophgo,sg2044-clk.h
+
+properties:
+ compatible:
+ const: sophgo,sg2044-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: fpll0
+ - description: fpll1
+ - description: fpll2
+ - description: dpll0
+ - description: dpll1
+ - description: dpll2
+ - description: dpll3
+ - description: dpll4
+ - description: dpll5
+ - description: dpll6
+ - description: dpll7
+ - description: mpll0
+ - description: mpll1
+ - description: mpll2
+ - description: mpll3
+ - description: mpll4
+ - description: mpll5
+
+ clock-names:
+ items:
+ - const: fpll0
+ - const: fpll1
+ - const: fpll2
+ - const: dpll0
+ - const: dpll1
+ - const: dpll2
+ - const: dpll3
+ - const: dpll4
+ - const: dpll5
+ - const: dpll6
+ - const: dpll7
+ - const: mpll0
+ - const: mpll1
+ - const: mpll2
+ - const: mpll3
+ - const: mpll4
+ - const: mpll5
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sophgo,sg2044-pll.h>
+
+ clock-controller@50002000 {
+ compatible = "sophgo,sg2044-clk";
+ reg = <0x50002000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&syscon CLK_FPLL0>, <&syscon CLK_FPLL1>,
+ <&syscon CLK_FPLL2>, <&syscon CLK_DPLL0>,
+ <&syscon CLK_DPLL1>, <&syscon CLK_DPLL2>,
+ <&syscon CLK_DPLL3>, <&syscon CLK_DPLL4>,
+ <&syscon CLK_DPLL5>, <&syscon CLK_DPLL6>,
+ <&syscon CLK_DPLL7>, <&syscon CLK_MPLL0>,
+ <&syscon CLK_MPLL1>, <&syscon CLK_MPLL2>,
+ <&syscon CLK_MPLL3>, <&syscon CLK_MPLL4>,
+ <&syscon CLK_MPLL5>;
+ clock-names = "fpll0", "fpll1", "fpll2", "dpll0",
+ "dpll1", "dpll2", "dpll3", "dpll4",
+ "dpll5", "dpll6", "dpll7", "mpll0",
+ "mpll1", "mpll2", "mpll3", "mpll4",
+ "mpll5";
+ };
diff --git a/Documentation/devicetree/bindings/clock/spacemit,k1-pll.yaml b/Documentation/devicetree/bindings/clock/spacemit,k1-pll.yaml
new file mode 100644
index 000000000000..06bafd68c00a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/spacemit,k1-pll.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/spacemit,k1-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 PLL
+
+maintainers:
+ - Haylen Chu <heylenay@4d2.org>
+
+properties:
+ compatible:
+ const: spacemit,k1-pll
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: External 24MHz oscillator
+
+ spacemit,mpmu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the "Main PMU (MPMU)" syscon. It is used to check PLL
+ lock status.
+
+ "#clock-cells":
+ const: 1
+ description:
+ See <dt-bindings/clock/spacemit,k1-syscon.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - spacemit,mpmu
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@d4090000 {
+ compatible = "spacemit,k1-pll";
+ reg = <0xd4090000 0x1000>;
+ clocks = <&vctcxo_24m>;
+ spacemit,mpmu = <&sysctl_mpmu>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9860-clk.txt b/Documentation/devicetree/bindings/clock/sprd,sc9860-clk.txt
deleted file mode 100644
index aaaf02ca2a6a..000000000000
--- a/Documentation/devicetree/bindings/clock/sprd,sc9860-clk.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Spreadtrum SC9860 Clock Binding
-------------------------
-
-Required properties:
-- compatible: should contain the following compatible strings:
- - "sprd,sc9860-pmu-gate"
- - "sprd,sc9860-pll"
- - "sprd,sc9860-ap-clk"
- - "sprd,sc9860-aon-prediv"
- - "sprd,sc9860-apahb-gate"
- - "sprd,sc9860-aon-gate"
- - "sprd,sc9860-aonsecure-clk"
- - "sprd,sc9860-agcp-gate"
- - "sprd,sc9860-gpu-clk"
- - "sprd,sc9860-vsp-clk"
- - "sprd,sc9860-vsp-gate"
- - "sprd,sc9860-cam-clk"
- - "sprd,sc9860-cam-gate"
- - "sprd,sc9860-disp-clk"
- - "sprd,sc9860-disp-gate"
- - "sprd,sc9860-apapb-gate"
-
-- #clock-cells: must be 1
-
-- clocks : Should be the input parent clock(s) phandle for the clock, this
- property here just simply shows which clock group the clocks'
- parents are in, since each clk node would represent many clocks
- which are defined in the driver. The detailed dependency
- relationship (i.e. how many parents and which are the parents)
- are implemented in driver code.
-
-Optional properties:
-
-- reg: Contain the registers base address and length. It must be configured
- only if no 'sprd,syscon' under the node.
-
-- sprd,syscon: phandle to the syscon which is in the same address area with
- the clock, and so we can get regmap for the clocks from the
- syscon device.
-
-Example:
-
- pmu_gate: pmu-gate {
- compatible = "sprd,sc9860-pmu-gate";
- sprd,syscon = <&pmu_regs>;
- clocks = <&ext_26m>;
- #clock-cells = <1>;
- };
-
- pll: pll {
- compatible = "sprd,sc9860-pll";
- sprd,syscon = <&ana_regs>;
- clocks = <&pmu_gate 0>;
- #clock-cells = <1>;
- };
-
- ap_clk: clock-controller@20000000 {
- compatible = "sprd,sc9860-ap-clk";
- reg = <0 0x20000000 0 0x400>;
- clocks = <&ext_26m>, <&pll 0>,
- <&pmu_gate 0>;
- #clock-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9860-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9860-clk.yaml
new file mode 100644
index 000000000000..502cd723511f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sprd,sc9860-clk.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/sprd,sc9860-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC9860 clock
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - sprd,sc9860-agcp-gate
+ - sprd,sc9860-aonsecure-clk
+ - sprd,sc9860-aon-gate
+ - sprd,sc9860-aon-prediv
+ - sprd,sc9860-apahb-gate
+ - sprd,sc9860-apapb-gate
+ - sprd,sc9860-ap-clk
+ - sprd,sc9860-cam-clk
+ - sprd,sc9860-cam-gate
+ - sprd,sc9860-disp-clk
+ - sprd,sc9860-disp-gate
+ - sprd,sc9860-gpu-clk
+ - sprd,sc9860-pll
+ - sprd,sc9860-pmu-gate
+ - sprd,sc9860-vsp-clk
+ - sprd,sc9860-vsp-gate
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ '#clock-cells':
+ const: 1
+
+ sprd,syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the syscon which is in the same address area with the
+ clock, and so we can get regmap for the clocks from the syscon device
+
+required:
+ - compatible
+ - clocks
+ - '#clock-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sprd,sc9860-agcp-gate
+ - sprd,sc9860-aon-gate
+ - sprd,sc9860-apahb-gate
+ - sprd,sc9860-apapb-gate
+ - sprd,sc9860-cam-gate
+ - sprd,sc9860-disp-gate
+ - sprd,sc9860-gpu-clk
+ - sprd,sc9860-pll
+ - sprd,sc9860-pmu-gate
+ - sprd,sc9860-vsp-gate
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sprd,sc9860-aonsecure-clk
+ - sprd,sc9860-cam-clk
+ - sprd,sc9860-disp-clk
+ - sprd,sc9860-vsp-clk
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sprd,sc9860-aon-prediv
+ - sprd,sc9860-ap-clk
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sprd,sc9860-aonsecure-clk
+ - sprd,sc9860-aon-prediv
+ - sprd,sc9860-ap-clk
+ - sprd,sc9860-cam-clk
+ - sprd,sc9860-disp-clk
+ - sprd,sc9860-gpu-clk
+ - sprd,sc9860-vsp-clk
+ then:
+ required:
+ - reg
+ properties:
+ sprd,syscon: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sprd,sc9860-agcp-gate
+ - sprd,sc9860-aon-gate
+ - sprd,sc9860-apahb-gate
+ - sprd,sc9860-apapb-gate
+ - sprd,sc9860-cam-gate
+ - sprd,sc9860-disp-gate
+ - sprd,sc9860-pll
+ - sprd,sc9860-pmu-gate
+ - sprd,sc9860-vsp-gate
+ then:
+ required:
+ - sprd,syscon
+ properties:
+ reg: false
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pmu-gate {
+ compatible = "sprd,sc9860-pmu-gate";
+ clocks = <&ext_26m>;
+ #clock-cells = <1>;
+ sprd,syscon = <&pmu_regs>;
+ };
+
+ clock-controller@20000000 {
+ compatible = "sprd,sc9860-ap-clk";
+ reg = <0 0x20000000 0 0x400>;
+ clocks = <&ext_26m>, <&pll 0>, <&pmu_gate 0>;
+ #clock-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
index 47e1ab08c95d..a0658056c330 100644
--- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
@@ -2,10 +2,10 @@
# Copyright 2019 Unisoc Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SC9863A Clock Control Unit Device Tree Bindings
+title: SC9863A Clock Control Unit
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
@@ -66,7 +66,7 @@ then:
else:
description: |
Other SC9863a clock nodes should be the child of a syscon node in
- which compatible string shoule be:
+ which compatible string should be:
"sprd,sc9863a-glbregs", "syscon", "simple-mfd"
The 'reg' property for the clock node is also required if there is a sub
diff --git a/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml
index 5f747b0471cf..43d2b6c31357 100644
--- a/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml
@@ -2,8 +2,8 @@
# Copyright 2022 Unisoc Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UMS512 Soc clock controller
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
deleted file mode 100644
index cfa04b614d8a..000000000000
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ /dev/null
@@ -1,138 +0,0 @@
-STMicroelectronics STM32 Reset and Clock Controller
-===================================================
-
-The RCC IP is both a reset and a clock controller.
-
-Please refer to clock-bindings.txt for common clock controller binding usage.
-Please also refer to reset.txt for common reset controller binding usage.
-
-Required properties:
-- compatible: Should be:
- "st,stm32f42xx-rcc"
- "st,stm32f469-rcc"
- "st,stm32f746-rcc"
- "st,stm32f769-rcc"
-
-- reg: should be register base and length as documented in the
- datasheet
-- #reset-cells: 1, see below
-- #clock-cells: 2, device nodes should specify the clock in their "clocks"
- property, containing a phandle to the clock device node, an index selecting
- between gated clocks and other clocks and an index specifying the clock to
- use.
-- clocks: External oscillator clock phandle
- - high speed external clock signal (HSE)
- - external I2S clock (I2S_CKIN)
-
-Example:
-
- rcc: rcc@40023800 {
- #reset-cells = <1>;
- #clock-cells = <2>
- compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
- reg = <0x40023800 0x400>;
- clocks = <&clk_hse>, <&clk_i2s_ckin>;
- };
-
-Specifying gated clocks
-=======================
-
-The primary index must be set to 0.
-
-The secondary index is the bit number within the RCC register bank, starting
-from the first RCC clock enable register (RCC_AHB1ENR, address offset 0x30).
-
-It is calculated as: index = register_offset / 4 * 32 + bit_offset.
-Where bit_offset is the bit offset within the register (LSB is 0, MSB is 31).
-
-To simplify the usage and to share bit definition with the reset and clock
-drivers of the RCC IP, macros are available to generate the index in
-human-readble format.
-
-For STM32F4 series, the macro are available here:
- - include/dt-bindings/mfd/stm32f4-rcc.h
-
-Example:
-
- /* Gated clock, AHB1 bit 0 (GPIOA) */
- ... {
- clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>
- };
-
- /* Gated clock, AHB2 bit 4 (CRYP) */
- ... {
- clocks = <&rcc 0 STM32F4_AHB2_CLOCK(CRYP)>
- };
-
-Specifying other clocks
-=======================
-
-The primary index must be set to 1.
-
-The secondary index is bound with the following magic numbers:
-
- 0 SYSTICK
- 1 FCLK
- 2 CLK_LSI (low-power clock source)
- 3 CLK_LSE (generated from a 32.768 kHz low-speed external
- crystal or ceramic resonator)
- 4 CLK_HSE_RTC (HSE division factor for RTC clock)
- 5 CLK_RTC (real-time clock)
- 6 PLL_VCO_I2S (vco frequency of I2S pll)
- 7 PLL_VCO_SAI (vco frequency of SAI pll)
- 8 CLK_LCD (LCD-TFT)
- 9 CLK_I2S (I2S clocks)
- 10 CLK_SAI1 (audio clocks)
- 11 CLK_SAI2
- 12 CLK_I2SQ_PDIV (post divisor of pll i2s q divisor)
- 13 CLK_SAIQ_PDIV (post divisor of pll sai q divisor)
-
- 14 CLK_HSI (Internal ocscillator clock)
- 15 CLK_SYSCLK (System Clock)
- 16 CLK_HDMI_CEC (HDMI-CEC clock)
- 17 CLK_SPDIF (SPDIF-Rx clock)
- 18 CLK_USART1 (U(s)arts clocks)
- 19 CLK_USART2
- 20 CLK_USART3
- 21 CLK_UART4
- 22 CLK_UART5
- 23 CLK_USART6
- 24 CLK_UART7
- 25 CLK_UART8
- 26 CLK_I2C1 (I2S clocks)
- 27 CLK_I2C2
- 28 CLK_I2C3
- 29 CLK_I2C4
- 30 CLK_LPTIMER (LPTimer1 clock)
- 31 CLK_PLL_SRC
- 32 CLK_DFSDM1
- 33 CLK_ADFSDM1
- 34 CLK_F769_DSI
-)
-
-Example:
-
- /* Misc clock, FCLK */
- ... {
- clocks = <&rcc 1 STM32F4_APB1_CLOCK(TIM2)>
- };
-
-
-Specifying softreset control of devices
-=======================================
-
-Device nodes should specify the reset channel required in their "resets"
-property, containing a phandle to the reset device node and an index specifying
-which channel to use.
-The index is the bit number within the RCC registers bank, starting from RCC
-base address.
-It is calculated as: index = register_offset / 4 * 32 + bit_offset.
-Where bit_offset is the bit offset within the register.
-For example, for CRC reset:
- crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
-
-example:
-
- timer2 {
- resets = <&rcc STM32F4_APB1_RESET(TIM2)>;
- };
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml
new file mode 100644
index 000000000000..f83a6120d65a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/st,stm32-rcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 Reset Clock Controller
+
+maintainers:
+ - Dario Binacchi <dario.binacchi@amarulasolutions.com>
+
+description: |
+ The RCC IP is both a reset and a clock controller.
+ The reset phandle argument is the bit number within the RCC registers bank,
+ starting from RCC base address.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - st,stm32f42xx-rcc
+ - st,stm32f746-rcc
+ - st,stm32h743-rcc
+ - const: st,stm32-rcc
+ - items:
+ - enum:
+ - st,stm32f469-rcc
+ - const: st,stm32f42xx-rcc
+ - const: st,stm32-rcc
+ - items:
+ - enum:
+ - st,stm32f769-rcc
+ - const: st,stm32f746-rcc
+ - const: st,stm32-rcc
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+ '#clock-cells':
+ enum: [1, 2]
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ st,syscfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to system configuration controller. It can be used to control the
+ power domain circuitry.
+
+ st,ssc-modfreq-hz:
+ description:
+ The modulation frequency for main PLL (in Hz)
+
+ st,ssc-moddepth-permyriad:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The modulation rate for main PLL (in permyriad, i.e. 0.01%)
+ minimum: 25
+ maximum: 200
+
+ st,ssc-modmethod:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ The modulation techniques for main PLL.
+ items:
+ enum:
+ - center-spread
+ - down-spread
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+ - '#clock-cells'
+ - clocks
+ - st,syscfg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32h743-rcc
+ then:
+ properties:
+ '#clock-cells':
+ const: 1
+ description: |
+ The clock index for the specified type.
+ clocks:
+ items:
+ - description: high speed external (HSE) clock input
+ - description: low speed external (LSE) clock input
+ - description: Inter-IC sound (I2S) clock input
+ st,ssc-modfreq-hz: false
+ st,ssc-moddepth-permyriad: false
+ st,ssc-modmethod: false
+
+ else:
+ properties:
+ '#clock-cells':
+ const: 2
+ description: |
+ - The first cell is the clock type, possible values are 0 for
+ gated clocks and 1 otherwise.
+ - The second cell is the clock index for the specified type.
+ clocks:
+ items:
+ - description: high speed external (HSE) clock input
+ - description: Inter-IC sound (I2S) clock input
+
+additionalProperties: false
+
+examples:
+ # Reset and Clock Control Module node:
+ - |
+ clock-controller@40023800 {
+ compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
+ reg = <0x40023800 0x400>;
+ #clock-cells = <2>;
+ #reset-cells = <1>;
+ clocks = <&clk_hse>, <&clk_i2s_ckin>;
+ st,syscfg = <&pwrcfg>;
+ st,ssc-modfreq-hz = <10000>;
+ st,ssc-moddepth-permyriad = <200>;
+ st,ssc-modmethod = "center-spread";
+ };
+ - |
+ clock-controller@58024400 {
+ compatible = "st,stm32h743-rcc", "st,stm32-rcc";
+ reg = <0x58024400 0x400>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s>;
+ st,syscfg = <&pwrcfg>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
deleted file mode 100644
index cac24ee10b72..000000000000
--- a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-STMicroelectronics STM32H7 Reset and Clock Controller
-=====================================================
-
-The RCC IP is both a reset and a clock controller.
-
-Please refer to clock-bindings.txt for common clock controller binding usage.
-Please also refer to reset.txt for common reset controller binding usage.
-
-Required properties:
-- compatible: Should be:
- "st,stm32h743-rcc"
-
-- reg: should be register base and length as documented in the
- datasheet
-
-- #reset-cells: 1, see below
-
-- #clock-cells : from common clock binding; shall be set to 1
-
-- clocks: External oscillator clock phandle
- - high speed external clock signal (HSE)
- - low speed external clock signal (LSE)
- - external I2S clock (I2S_CKIN)
-
-Optional properties:
-- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup domain
- write protection (RTC clock).
-
-Example:
-
- rcc: reset-clock-controller@58024400 {
- compatible = "st,stm32h743-rcc", "st,stm32-rcc";
- reg = <0x58024400 0x400>;
- #reset-cells = <1>;
- #clock-cells = <1>;
- clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
-
- st,syscfg = <&pwrcfg>;
-};
-
-The peripheral clock consumer should specify the desired clock by
-having the clock ID in its "clocks" phandle cell.
-
-Example:
-
- timer5: timer@40000c00 {
- compatible = "st,stm32-timer";
- reg = <0x40000c00 0x400>;
- interrupts = <50>;
- clocks = <&rcc TIM5_CK>;
- };
-
-Specifying softreset control of devices
-=======================================
-
-Device nodes should specify the reset channel required in their "resets"
-property, containing a phandle to the reset device node and an index specifying
-which channel to use.
-The index is the bit number within the RCC registers bank, starting from RCC
-base address.
-It is calculated as: index = register_offset / 4 * 32 + bit_offset.
-Where bit_offset is the bit offset within the register.
-
-For example, for CRC reset:
- crc = AHB4RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x88 / 4 * 32 + 19 = 1107
-
-Example:
-
- timer2 {
- resets = <&rcc STM32H7_APB1L_RESET(TIM2)>;
- };
diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
index 242fe922b035..e72f46e79b90 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/st,stm32mp1-rcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Reset Clock Controller Binding
+title: STMicroelectronics STM32MP1 Reset Clock Controller
maintainers:
- Gabriel Fernandez <gabriel.fernandez@foss.st.com>
@@ -21,7 +21,7 @@ description: |
=================
All available clocks are defined as preprocessor macros in
- dt-bindings/clock/stm32mp1-clks.h header and can be used in device
+ include/dt-bindings/clock/stm32mp1-clks.h header and can be used in device
tree sources.
Specifying softreset control of devices
@@ -40,8 +40,8 @@ description: |
= 0x180 / 4 * 32 + 0 = 3072
The list of valid indices for STM32MP1 is available in:
- include/dt-bindings/reset-controller/stm32mp1-resets.h
- include/dt-bindings/reset-controller/stm32mp13-resets.h
+ include/dt-bindings/reset/stm32mp1-resets.h
+ include/dt-bindings/reset/stm32mp13-resets.h
This file implements defines like:
#define LTDC_R 3072
@@ -60,8 +60,14 @@ properties:
- st,stm32mp1-rcc
- st,stm32mp13-rcc
- const: syscon
- clocks: true
- clock-names: true
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+
+ clock-names:
+ minItems: 1
+ maxItems: 5
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp21-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp21-rcc.yaml
new file mode 100644
index 000000000000..4368063c6709
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp21-rcc.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/st,stm32mp21-rcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP21 Reset Clock Controller
+
+maintainers:
+ - Gabriel Fernandez <gabriel.fernandez@foss.st.com>
+
+description: |
+ The RCC hardware block is both a reset and a clock controller.
+ RCC makes also power management (resume/suspend).
+
+ See also:
+ include/dt-bindings/clock/st,stm32mp21-rcc.h
+ include/dt-bindings/reset/st,stm32mp21-rcc.h
+
+properties:
+ compatible:
+ enum:
+ - st,stm32mp21-rcc
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
+ - description: CK_SCMI_HSI High Speed Internal oscillator (~ 64 MHz)
+ - description: CK_SCMI_MSI Low Power Internal oscillator (~ 4 MHz or ~ 16 MHz)
+ - description: CK_SCMI_LSE Low Speed External oscillator (32 KHz)
+ - description: CK_SCMI_LSI Low Speed Internal oscillator (~ 32 KHz)
+ - description: CK_SCMI_HSE_DIV2 CK_SCMI_HSE divided by 2 (could be gated)
+ - description: CK_SCMI_ICN_HS_MCU High Speed interconnect bus clock
+ - description: CK_SCMI_ICN_LS_MCU Low Speed interconnect bus clock
+ - description: CK_SCMI_ICN_SDMMC SDMMC interconnect bus clock
+ - description: CK_SCMI_ICN_DDR DDR interconnect bus clock
+ - description: CK_SCMI_ICN_DISPLAY Display interconnect bus clock
+ - description: CK_SCMI_ICN_HSL HSL interconnect bus clock
+ - description: CK_SCMI_ICN_NIC NIC interconnect bus clock
+ - description: CK_SCMI_FLEXGEN_07 flexgen clock 7
+ - description: CK_SCMI_FLEXGEN_08 flexgen clock 8
+ - description: CK_SCMI_FLEXGEN_09 flexgen clock 9
+ - description: CK_SCMI_FLEXGEN_10 flexgen clock 10
+ - description: CK_SCMI_FLEXGEN_11 flexgen clock 11
+ - description: CK_SCMI_FLEXGEN_12 flexgen clock 12
+ - description: CK_SCMI_FLEXGEN_13 flexgen clock 13
+ - description: CK_SCMI_FLEXGEN_14 flexgen clock 14
+ - description: CK_SCMI_FLEXGEN_16 flexgen clock 16
+ - description: CK_SCMI_FLEXGEN_17 flexgen clock 17
+ - description: CK_SCMI_FLEXGEN_18 flexgen clock 18
+ - description: CK_SCMI_FLEXGEN_19 flexgen clock 19
+ - description: CK_SCMI_FLEXGEN_20 flexgen clock 20
+ - description: CK_SCMI_FLEXGEN_21 flexgen clock 21
+ - description: CK_SCMI_FLEXGEN_22 flexgen clock 22
+ - description: CK_SCMI_FLEXGEN_23 flexgen clock 23
+ - description: CK_SCMI_FLEXGEN_24 flexgen clock 24
+ - description: CK_SCMI_FLEXGEN_25 flexgen clock 25
+ - description: CK_SCMI_FLEXGEN_26 flexgen clock 26
+ - description: CK_SCMI_FLEXGEN_27 flexgen clock 27
+ - description: CK_SCMI_FLEXGEN_29 flexgen clock 29
+ - description: CK_SCMI_FLEXGEN_30 flexgen clock 30
+ - description: CK_SCMI_FLEXGEN_31 flexgen clock 31
+ - description: CK_SCMI_FLEXGEN_33 flexgen clock 33
+ - description: CK_SCMI_FLEXGEN_36 flexgen clock 36
+ - description: CK_SCMI_FLEXGEN_37 flexgen clock 37
+ - description: CK_SCMI_FLEXGEN_38 flexgen clock 38
+ - description: CK_SCMI_FLEXGEN_39 flexgen clock 39
+ - description: CK_SCMI_FLEXGEN_40 flexgen clock 40
+ - description: CK_SCMI_FLEXGEN_41 flexgen clock 41
+ - description: CK_SCMI_FLEXGEN_42 flexgen clock 42
+ - description: CK_SCMI_FLEXGEN_43 flexgen clock 43
+ - description: CK_SCMI_FLEXGEN_44 flexgen clock 44
+ - description: CK_SCMI_FLEXGEN_45 flexgen clock 45
+ - description: CK_SCMI_FLEXGEN_46 flexgen clock 46
+ - description: CK_SCMI_FLEXGEN_47 flexgen clock 47
+ - description: CK_SCMI_FLEXGEN_48 flexgen clock 48
+ - description: CK_SCMI_FLEXGEN_50 flexgen clock 50
+ - description: CK_SCMI_FLEXGEN_51 flexgen clock 51
+ - description: CK_SCMI_FLEXGEN_52 flexgen clock 52
+ - description: CK_SCMI_FLEXGEN_53 flexgen clock 53
+ - description: CK_SCMI_FLEXGEN_54 flexgen clock 54
+ - description: CK_SCMI_FLEXGEN_55 flexgen clock 55
+ - description: CK_SCMI_FLEXGEN_56 flexgen clock 56
+ - description: CK_SCMI_FLEXGEN_57 flexgen clock 57
+ - description: CK_SCMI_FLEXGEN_58 flexgen clock 58
+ - description: CK_SCMI_FLEXGEN_61 flexgen clock 61
+ - description: CK_SCMI_FLEXGEN_62 flexgen clock 62
+ - description: CK_SCMI_FLEXGEN_63 flexgen clock 63
+ - description: CK_SCMI_ICN_APB1 Peripheral bridge 1
+ - description: CK_SCMI_ICN_APB2 Peripheral bridge 2
+ - description: CK_SCMI_ICN_APB3 Peripheral bridge 3
+ - description: CK_SCMI_ICN_APB4 Peripheral bridge 4
+ - description: CK_SCMI_ICN_APB5 Peripheral bridge 5
+ - description: CK_SCMI_ICN_APBDBG Peripheral bridge for debug
+ - description: CK_SCMI_TIMG1 Peripheral bridge for timer1
+ - description: CK_SCMI_TIMG2 Peripheral bridge for timer2
+
+ access-controllers:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp21-rcc.h>
+
+ clock-controller@44200000 {
+ compatible = "st,stm32mp21-rcc";
+ reg = <0x44200000 0x10000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&scmi_clk CK_SCMI_HSE>,
+ <&scmi_clk CK_SCMI_HSI>,
+ <&scmi_clk CK_SCMI_MSI>,
+ <&scmi_clk CK_SCMI_LSE>,
+ <&scmi_clk CK_SCMI_LSI>,
+ <&scmi_clk CK_SCMI_HSE_DIV2>,
+ <&scmi_clk CK_SCMI_ICN_HS_MCU>,
+ <&scmi_clk CK_SCMI_ICN_LS_MCU>,
+ <&scmi_clk CK_SCMI_ICN_SDMMC>,
+ <&scmi_clk CK_SCMI_ICN_DDR>,
+ <&scmi_clk CK_SCMI_ICN_DISPLAY>,
+ <&scmi_clk CK_SCMI_ICN_HSL>,
+ <&scmi_clk CK_SCMI_ICN_NIC>,
+ <&scmi_clk CK_SCMI_FLEXGEN_07>,
+ <&scmi_clk CK_SCMI_FLEXGEN_08>,
+ <&scmi_clk CK_SCMI_FLEXGEN_09>,
+ <&scmi_clk CK_SCMI_FLEXGEN_10>,
+ <&scmi_clk CK_SCMI_FLEXGEN_11>,
+ <&scmi_clk CK_SCMI_FLEXGEN_12>,
+ <&scmi_clk CK_SCMI_FLEXGEN_13>,
+ <&scmi_clk CK_SCMI_FLEXGEN_14>,
+ <&scmi_clk CK_SCMI_FLEXGEN_16>,
+ <&scmi_clk CK_SCMI_FLEXGEN_17>,
+ <&scmi_clk CK_SCMI_FLEXGEN_18>,
+ <&scmi_clk CK_SCMI_FLEXGEN_19>,
+ <&scmi_clk CK_SCMI_FLEXGEN_20>,
+ <&scmi_clk CK_SCMI_FLEXGEN_21>,
+ <&scmi_clk CK_SCMI_FLEXGEN_22>,
+ <&scmi_clk CK_SCMI_FLEXGEN_23>,
+ <&scmi_clk CK_SCMI_FLEXGEN_24>,
+ <&scmi_clk CK_SCMI_FLEXGEN_25>,
+ <&scmi_clk CK_SCMI_FLEXGEN_26>,
+ <&scmi_clk CK_SCMI_FLEXGEN_27>,
+ <&scmi_clk CK_SCMI_FLEXGEN_29>,
+ <&scmi_clk CK_SCMI_FLEXGEN_30>,
+ <&scmi_clk CK_SCMI_FLEXGEN_31>,
+ <&scmi_clk CK_SCMI_FLEXGEN_33>,
+ <&scmi_clk CK_SCMI_FLEXGEN_36>,
+ <&scmi_clk CK_SCMI_FLEXGEN_37>,
+ <&scmi_clk CK_SCMI_FLEXGEN_38>,
+ <&scmi_clk CK_SCMI_FLEXGEN_39>,
+ <&scmi_clk CK_SCMI_FLEXGEN_40>,
+ <&scmi_clk CK_SCMI_FLEXGEN_41>,
+ <&scmi_clk CK_SCMI_FLEXGEN_42>,
+ <&scmi_clk CK_SCMI_FLEXGEN_43>,
+ <&scmi_clk CK_SCMI_FLEXGEN_44>,
+ <&scmi_clk CK_SCMI_FLEXGEN_45>,
+ <&scmi_clk CK_SCMI_FLEXGEN_46>,
+ <&scmi_clk CK_SCMI_FLEXGEN_47>,
+ <&scmi_clk CK_SCMI_FLEXGEN_48>,
+ <&scmi_clk CK_SCMI_FLEXGEN_50>,
+ <&scmi_clk CK_SCMI_FLEXGEN_51>,
+ <&scmi_clk CK_SCMI_FLEXGEN_52>,
+ <&scmi_clk CK_SCMI_FLEXGEN_53>,
+ <&scmi_clk CK_SCMI_FLEXGEN_54>,
+ <&scmi_clk CK_SCMI_FLEXGEN_55>,
+ <&scmi_clk CK_SCMI_FLEXGEN_56>,
+ <&scmi_clk CK_SCMI_FLEXGEN_57>,
+ <&scmi_clk CK_SCMI_FLEXGEN_58>,
+ <&scmi_clk CK_SCMI_FLEXGEN_61>,
+ <&scmi_clk CK_SCMI_FLEXGEN_62>,
+ <&scmi_clk CK_SCMI_FLEXGEN_63>,
+ <&scmi_clk CK_SCMI_ICN_APB1>,
+ <&scmi_clk CK_SCMI_ICN_APB2>,
+ <&scmi_clk CK_SCMI_ICN_APB3>,
+ <&scmi_clk CK_SCMI_ICN_APB4>,
+ <&scmi_clk CK_SCMI_ICN_APB5>,
+ <&scmi_clk CK_SCMI_ICN_APBDBG>,
+ <&scmi_clk CK_SCMI_TIMG1>,
+ <&scmi_clk CK_SCMI_TIMG2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
new file mode 100644
index 000000000000..1e3b5d218bb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
@@ -0,0 +1,219 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/st,stm32mp25-rcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP25 Reset Clock Controller
+
+maintainers:
+ - Gabriel Fernandez <gabriel.fernandez@foss.st.com>
+
+description: |
+ The RCC hardware block is both a reset and a clock controller.
+ RCC makes also power management (resume/suspend).
+
+ See also:
+ include/dt-bindings/clock/st,stm32mp25-rcc.h
+ include/dt-bindings/reset/st,stm32mp25-rcc.h
+
+properties:
+ compatible:
+ enum:
+ - st,stm32mp25-rcc
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#reset-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
+ - description: CK_SCMI_HSI High Speed Internal oscillator (~ 64 MHz)
+ - description: CK_SCMI_MSI Low Power Internal oscillator (~ 4 MHz or ~ 16 MHz)
+ - description: CK_SCMI_LSE Low Speed External oscillator (32 KHz)
+ - description: CK_SCMI_LSI Low Speed Internal oscillator (~ 32 KHz)
+ - description: CK_SCMI_HSE_DIV2 CK_SCMI_HSE divided by 2 (could be gated)
+ - description: CK_SCMI_ICN_HS_MCU High Speed interconnect bus clock
+ - description: CK_SCMI_ICN_LS_MCU Low Speed interconnect bus clock
+ - description: CK_SCMI_ICN_SDMMC SDMMC interconnect bus clock
+ - description: CK_SCMI_ICN_DDR DDR interconnect bus clock
+ - description: CK_SCMI_ICN_DISPLAY Display interconnect bus clock
+ - description: CK_SCMI_ICN_HSL HSL interconnect bus clock
+ - description: CK_SCMI_ICN_NIC NIC interconnect bus clock
+ - description: CK_SCMI_ICN_VID Video interconnect bus clock
+ - description: CK_SCMI_FLEXGEN_07 flexgen clock 7
+ - description: CK_SCMI_FLEXGEN_08 flexgen clock 8
+ - description: CK_SCMI_FLEXGEN_09 flexgen clock 9
+ - description: CK_SCMI_FLEXGEN_10 flexgen clock 10
+ - description: CK_SCMI_FLEXGEN_11 flexgen clock 11
+ - description: CK_SCMI_FLEXGEN_12 flexgen clock 12
+ - description: CK_SCMI_FLEXGEN_13 flexgen clock 13
+ - description: CK_SCMI_FLEXGEN_14 flexgen clock 14
+ - description: CK_SCMI_FLEXGEN_15 flexgen clock 15
+ - description: CK_SCMI_FLEXGEN_16 flexgen clock 16
+ - description: CK_SCMI_FLEXGEN_17 flexgen clock 17
+ - description: CK_SCMI_FLEXGEN_18 flexgen clock 18
+ - description: CK_SCMI_FLEXGEN_19 flexgen clock 19
+ - description: CK_SCMI_FLEXGEN_20 flexgen clock 20
+ - description: CK_SCMI_FLEXGEN_21 flexgen clock 21
+ - description: CK_SCMI_FLEXGEN_22 flexgen clock 22
+ - description: CK_SCMI_FLEXGEN_23 flexgen clock 23
+ - description: CK_SCMI_FLEXGEN_24 flexgen clock 24
+ - description: CK_SCMI_FLEXGEN_25 flexgen clock 25
+ - description: CK_SCMI_FLEXGEN_26 flexgen clock 26
+ - description: CK_SCMI_FLEXGEN_27 flexgen clock 27
+ - description: CK_SCMI_FLEXGEN_28 flexgen clock 28
+ - description: CK_SCMI_FLEXGEN_29 flexgen clock 29
+ - description: CK_SCMI_FLEXGEN_30 flexgen clock 30
+ - description: CK_SCMI_FLEXGEN_31 flexgen clock 31
+ - description: CK_SCMI_FLEXGEN_32 flexgen clock 32
+ - description: CK_SCMI_FLEXGEN_33 flexgen clock 33
+ - description: CK_SCMI_FLEXGEN_34 flexgen clock 34
+ - description: CK_SCMI_FLEXGEN_35 flexgen clock 35
+ - description: CK_SCMI_FLEXGEN_36 flexgen clock 36
+ - description: CK_SCMI_FLEXGEN_37 flexgen clock 37
+ - description: CK_SCMI_FLEXGEN_38 flexgen clock 38
+ - description: CK_SCMI_FLEXGEN_39 flexgen clock 39
+ - description: CK_SCMI_FLEXGEN_40 flexgen clock 40
+ - description: CK_SCMI_FLEXGEN_41 flexgen clock 41
+ - description: CK_SCMI_FLEXGEN_42 flexgen clock 42
+ - description: CK_SCMI_FLEXGEN_43 flexgen clock 43
+ - description: CK_SCMI_FLEXGEN_44 flexgen clock 44
+ - description: CK_SCMI_FLEXGEN_45 flexgen clock 45
+ - description: CK_SCMI_FLEXGEN_46 flexgen clock 46
+ - description: CK_SCMI_FLEXGEN_47 flexgen clock 47
+ - description: CK_SCMI_FLEXGEN_48 flexgen clock 48
+ - description: CK_SCMI_FLEXGEN_49 flexgen clock 49
+ - description: CK_SCMI_FLEXGEN_50 flexgen clock 50
+ - description: CK_SCMI_FLEXGEN_51 flexgen clock 51
+ - description: CK_SCMI_FLEXGEN_52 flexgen clock 52
+ - description: CK_SCMI_FLEXGEN_53 flexgen clock 53
+ - description: CK_SCMI_FLEXGEN_54 flexgen clock 54
+ - description: CK_SCMI_FLEXGEN_55 flexgen clock 55
+ - description: CK_SCMI_FLEXGEN_56 flexgen clock 56
+ - description: CK_SCMI_FLEXGEN_57 flexgen clock 57
+ - description: CK_SCMI_FLEXGEN_58 flexgen clock 58
+ - description: CK_SCMI_FLEXGEN_59 flexgen clock 59
+ - description: CK_SCMI_FLEXGEN_60 flexgen clock 60
+ - description: CK_SCMI_FLEXGEN_61 flexgen clock 61
+ - description: CK_SCMI_FLEXGEN_62 flexgen clock 62
+ - description: CK_SCMI_FLEXGEN_63 flexgen clock 63
+ - description: CK_SCMI_ICN_APB1 Peripheral bridge 1
+ - description: CK_SCMI_ICN_APB2 Peripheral bridge 2
+ - description: CK_SCMI_ICN_APB3 Peripheral bridge 3
+ - description: CK_SCMI_ICN_APB4 Peripheral bridge 4
+ - description: CK_SCMI_ICN_APBDBG Peripheral bridge for debug
+ - description: CK_SCMI_TIMG1 Peripheral bridge for timer1
+ - description: CK_SCMI_TIMG2 Peripheral bridge for timer2
+ - description: CK_SCMI_PLL3 PLL3 clock
+ - description: clk_dsi_txbyte DSI byte clock
+
+ access-controllers:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+
+ clock-controller@44200000 {
+ compatible = "st,stm32mp25-rcc";
+ reg = <0x44200000 0x10000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&scmi_clk CK_SCMI_HSE>,
+ <&scmi_clk CK_SCMI_HSI>,
+ <&scmi_clk CK_SCMI_MSI>,
+ <&scmi_clk CK_SCMI_LSE>,
+ <&scmi_clk CK_SCMI_LSI>,
+ <&scmi_clk CK_SCMI_HSE_DIV2>,
+ <&scmi_clk CK_SCMI_ICN_HS_MCU>,
+ <&scmi_clk CK_SCMI_ICN_LS_MCU>,
+ <&scmi_clk CK_SCMI_ICN_SDMMC>,
+ <&scmi_clk CK_SCMI_ICN_DDR>,
+ <&scmi_clk CK_SCMI_ICN_DISPLAY>,
+ <&scmi_clk CK_SCMI_ICN_HSL>,
+ <&scmi_clk CK_SCMI_ICN_NIC>,
+ <&scmi_clk CK_SCMI_ICN_VID>,
+ <&scmi_clk CK_SCMI_FLEXGEN_07>,
+ <&scmi_clk CK_SCMI_FLEXGEN_08>,
+ <&scmi_clk CK_SCMI_FLEXGEN_09>,
+ <&scmi_clk CK_SCMI_FLEXGEN_10>,
+ <&scmi_clk CK_SCMI_FLEXGEN_11>,
+ <&scmi_clk CK_SCMI_FLEXGEN_12>,
+ <&scmi_clk CK_SCMI_FLEXGEN_13>,
+ <&scmi_clk CK_SCMI_FLEXGEN_14>,
+ <&scmi_clk CK_SCMI_FLEXGEN_15>,
+ <&scmi_clk CK_SCMI_FLEXGEN_16>,
+ <&scmi_clk CK_SCMI_FLEXGEN_17>,
+ <&scmi_clk CK_SCMI_FLEXGEN_18>,
+ <&scmi_clk CK_SCMI_FLEXGEN_19>,
+ <&scmi_clk CK_SCMI_FLEXGEN_20>,
+ <&scmi_clk CK_SCMI_FLEXGEN_21>,
+ <&scmi_clk CK_SCMI_FLEXGEN_22>,
+ <&scmi_clk CK_SCMI_FLEXGEN_23>,
+ <&scmi_clk CK_SCMI_FLEXGEN_24>,
+ <&scmi_clk CK_SCMI_FLEXGEN_25>,
+ <&scmi_clk CK_SCMI_FLEXGEN_26>,
+ <&scmi_clk CK_SCMI_FLEXGEN_27>,
+ <&scmi_clk CK_SCMI_FLEXGEN_28>,
+ <&scmi_clk CK_SCMI_FLEXGEN_29>,
+ <&scmi_clk CK_SCMI_FLEXGEN_30>,
+ <&scmi_clk CK_SCMI_FLEXGEN_31>,
+ <&scmi_clk CK_SCMI_FLEXGEN_32>,
+ <&scmi_clk CK_SCMI_FLEXGEN_33>,
+ <&scmi_clk CK_SCMI_FLEXGEN_34>,
+ <&scmi_clk CK_SCMI_FLEXGEN_35>,
+ <&scmi_clk CK_SCMI_FLEXGEN_36>,
+ <&scmi_clk CK_SCMI_FLEXGEN_37>,
+ <&scmi_clk CK_SCMI_FLEXGEN_38>,
+ <&scmi_clk CK_SCMI_FLEXGEN_39>,
+ <&scmi_clk CK_SCMI_FLEXGEN_40>,
+ <&scmi_clk CK_SCMI_FLEXGEN_41>,
+ <&scmi_clk CK_SCMI_FLEXGEN_42>,
+ <&scmi_clk CK_SCMI_FLEXGEN_43>,
+ <&scmi_clk CK_SCMI_FLEXGEN_44>,
+ <&scmi_clk CK_SCMI_FLEXGEN_45>,
+ <&scmi_clk CK_SCMI_FLEXGEN_46>,
+ <&scmi_clk CK_SCMI_FLEXGEN_47>,
+ <&scmi_clk CK_SCMI_FLEXGEN_48>,
+ <&scmi_clk CK_SCMI_FLEXGEN_49>,
+ <&scmi_clk CK_SCMI_FLEXGEN_50>,
+ <&scmi_clk CK_SCMI_FLEXGEN_51>,
+ <&scmi_clk CK_SCMI_FLEXGEN_52>,
+ <&scmi_clk CK_SCMI_FLEXGEN_53>,
+ <&scmi_clk CK_SCMI_FLEXGEN_54>,
+ <&scmi_clk CK_SCMI_FLEXGEN_55>,
+ <&scmi_clk CK_SCMI_FLEXGEN_56>,
+ <&scmi_clk CK_SCMI_FLEXGEN_57>,
+ <&scmi_clk CK_SCMI_FLEXGEN_58>,
+ <&scmi_clk CK_SCMI_FLEXGEN_59>,
+ <&scmi_clk CK_SCMI_FLEXGEN_60>,
+ <&scmi_clk CK_SCMI_FLEXGEN_61>,
+ <&scmi_clk CK_SCMI_FLEXGEN_62>,
+ <&scmi_clk CK_SCMI_FLEXGEN_63>,
+ <&scmi_clk CK_SCMI_ICN_APB1>,
+ <&scmi_clk CK_SCMI_ICN_APB2>,
+ <&scmi_clk CK_SCMI_ICN_APB3>,
+ <&scmi_clk CK_SCMI_ICN_APB4>,
+ <&scmi_clk CK_SCMI_ICN_APBDBG>,
+ <&scmi_clk CK_SCMI_TIMG1>,
+ <&scmi_clk CK_SCMI_TIMG2>,
+ <&scmi_clk CK_SCMI_PLL3>,
+ <&clk_dsi_txbyte>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
index c918075405ba..a9d1c19f30a3 100644
--- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
+++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt
@@ -64,12 +64,9 @@ Required properties:
audio use case)
"st,flexgen-video", "st,flexgen" (enable clock propagation on parent
and activate synchronous mode)
- "st,flexgen-stih407-a0"
"st,flexgen-stih410-a0"
- "st,flexgen-stih407-c0"
"st,flexgen-stih410-c0"
"st,flexgen-stih418-c0"
- "st,flexgen-stih407-d0"
"st,flexgen-stih410-d0"
"st,flexgen-stih407-d2"
"st,flexgen-stih418-d2"
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml
new file mode 100644
index 000000000000..923680a44aef
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-aoncrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Always-On Clock and Reset Generator
+
+maintainers:
+ - Emil Renner Berthing <kernel@esmil.dk>
+
+properties:
+ compatible:
+ const: starfive,jh7110-aoncrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ oneOf:
+ - items:
+ - description: Main Oscillator (24 MHz)
+ - description: GMAC0 RMII reference or GMAC0 RGMII RX
+ - description: STG AXI/AHB
+ - description: APB Bus
+ - description: GMAC0 GTX
+
+ - items:
+ - description: Main Oscillator (24 MHz)
+ - description: GMAC0 RMII reference or GMAC0 RGMII RX
+ - description: STG AXI/AHB or GMAC0 RGMII RX
+ - description: APB Bus or STG AXI/AHB
+ - description: GMAC0 GTX or APB Bus
+ - description: RTC Oscillator (32.768 kHz) or GMAC0 GTX
+
+ - items:
+ - description: Main Oscillator (24 MHz)
+ - description: GMAC0 RMII reference
+ - description: GMAC0 RGMII RX
+ - description: STG AXI/AHB
+ - description: APB Bus
+ - description: GMAC0 GTX
+ - description: RTC Oscillator (32.768 kHz)
+
+ clock-names:
+ oneOf:
+ - minItems: 5
+ items:
+ - const: osc
+ - enum:
+ - gmac0_rmii_refin
+ - gmac0_rgmii_rxin
+ - const: stg_axiahb
+ - const: apb_bus
+ - const: gmac0_gtxclk
+ - const: rtc_osc
+
+ - minItems: 6
+ items:
+ - const: osc
+ - const: gmac0_rmii_refin
+ - const: gmac0_rgmii_rxin
+ - const: stg_axiahb
+ - const: apb_bus
+ - const: gmac0_gtxclk
+ - const: rtc_osc
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+
+ clock-controller@17000000 {
+ compatible = "starfive,jh7110-aoncrg";
+ reg = <0x17000000 0x10000>;
+ clocks = <&osc>, <&gmac0_rmii_refin>,
+ <&gmac0_rgmii_rxin>,
+ <&syscrg JH7110_SYSCLK_STG_AXIAHB>,
+ <&syscrg JH7110_SYSCLK_APB_BUS>,
+ <&syscrg JH7110_SYSCLK_GMAC0_GTXCLK>,
+ <&rtc_osc>;
+ clock-names = "osc", "gmac0_rmii_refin",
+ "gmac0_rgmii_rxin", "stg_axiahb",
+ "apb_bus", "gmac0_gtxclk",
+ "rtc_osc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml
new file mode 100644
index 000000000000..3b8b85be5cd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-ispcrg.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-ispcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Image-Signal-Process Clock and Reset Generator
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-ispcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ISP Top core
+ - description: ISP Top Axi
+ - description: NOC ISP Bus
+ - description: external DVP
+
+ clock-names:
+ items:
+ - const: isp_top_core
+ - const: isp_top_axi
+ - const: noc_bus_isp_axi
+ - const: dvp_clk
+
+ resets:
+ items:
+ - description: ISP Top core
+ - description: ISP Top Axi
+ - description: NOC ISP Bus
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+ power-domains:
+ maxItems: 1
+ description:
+ ISP domain power
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - '#clock-cells'
+ - '#reset-cells'
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+ #include <dt-bindings/power/starfive,jh7110-pmu.h>
+ #include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+ ispcrg: clock-controller@19810000 {
+ compatible = "starfive,jh7110-ispcrg";
+ reg = <0x19810000 0x10000>;
+ clocks = <&syscrg JH7110_SYSCLK_ISP_TOP_CORE>,
+ <&syscrg JH7110_SYSCLK_ISP_TOP_AXI>,
+ <&syscrg JH7110_SYSCLK_NOC_BUS_ISP_AXI>,
+ <&dvp_clk>;
+ clock-names = "isp_top_core", "isp_top_axi",
+ "noc_bus_isp_axi", "dvp_clk";
+ resets = <&syscrg JH7110_SYSRST_ISP_TOP>,
+ <&syscrg JH7110_SYSRST_ISP_TOP_AXI>,
+ <&syscrg JH7110_SYSRST_NOC_BUS_ISP_AXI>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ power-domains = <&pwrc JH7110_PD_ISP>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml
new file mode 100644
index 000000000000..be8300ce86d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-pll.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-pll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 PLL Clock Generator
+
+description:
+ These PLLs are high speed, low jitter frequency synthesizers in the JH7110.
+ Each PLL works in integer mode or fraction mode, with configuration
+ registers in the sys syscon. So the PLLs node should be a child of
+ SYS-SYSCON node.
+ The formula for calculating frequency is
+ Fvco = Fref * (NI + NF) / M / Q1
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-pll
+
+ clocks:
+ maxItems: 1
+ description: Main Oscillator (24 MHz)
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+required:
+ - compatible
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller {
+ compatible = "starfive,jh7110-pll";
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml
new file mode 100644
index 000000000000..b64ccd84200a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-stgcrg.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-stgcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 System-Top-Group Clock and Reset Generator
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-stgcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Main Oscillator (24 MHz)
+ - description: HIFI4 core
+ - description: STG AXI/AHB
+ - description: USB (125 MHz)
+ - description: CPU Bus
+ - description: HIFI4 Axi
+ - description: NOC STG Bus
+ - description: APB Bus
+
+ clock-names:
+ items:
+ - const: osc
+ - const: hifi4_core
+ - const: stg_axiahb
+ - const: usb_125m
+ - const: cpu_bus
+ - const: hifi4_axi
+ - const: nocstg_bus
+ - const: apb_bus
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+
+ stgcrg: clock-controller@10230000 {
+ compatible = "starfive,jh7110-stgcrg";
+ reg = <0x10230000 0x10000>;
+ clocks = <&osc>,
+ <&syscrg JH7110_SYSCLK_HIFI4_CORE>,
+ <&syscrg JH7110_SYSCLK_STG_AXIAHB>,
+ <&syscrg JH7110_SYSCLK_USB_125M>,
+ <&syscrg JH7110_SYSCLK_CPU_BUS>,
+ <&syscrg JH7110_SYSCLK_HIFI4_AXI>,
+ <&syscrg JH7110_SYSCLK_NOCSTG_BUS>,
+ <&syscrg JH7110_SYSCLK_APB_BUS>;
+ clock-names = "osc", "hifi4_core",
+ "stg_axiahb", "usb_125m",
+ "cpu_bus", "hifi4_axi",
+ "nocstg_bus", "apb_bus";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml
new file mode 100644
index 000000000000..5ba0a885aa80
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-syscrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 System Clock and Reset Generator
+
+maintainers:
+ - Emil Renner Berthing <kernel@esmil.dk>
+
+properties:
+ compatible:
+ const: starfive,jh7110-syscrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ oneOf:
+ - items:
+ - description: Main Oscillator (24 MHz)
+ - description: GMAC1 RMII reference or GMAC1 RGMII RX
+ - description: External I2S TX bit clock
+ - description: External I2S TX left/right channel clock
+ - description: External I2S RX bit clock
+ - description: External I2S RX left/right channel clock
+ - description: External TDM clock
+ - description: External audio master clock
+ - description: PLL0
+ - description: PLL1
+ - description: PLL2
+
+ - items:
+ - description: Main Oscillator (24 MHz)
+ - description: GMAC1 RMII reference
+ - description: GMAC1 RGMII RX
+ - description: External I2S TX bit clock
+ - description: External I2S TX left/right channel clock
+ - description: External I2S RX bit clock
+ - description: External I2S RX left/right channel clock
+ - description: External TDM clock
+ - description: External audio master clock
+ - description: PLL0
+ - description: PLL1
+ - description: PLL2
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: osc
+ - enum:
+ - gmac1_rmii_refin
+ - gmac1_rgmii_rxin
+ - const: i2stx_bclk_ext
+ - const: i2stx_lrck_ext
+ - const: i2srx_bclk_ext
+ - const: i2srx_lrck_ext
+ - const: tdm_ext
+ - const: mclk_ext
+ - const: pll0_out
+ - const: pll1_out
+ - const: pll2_out
+
+ - items:
+ - const: osc
+ - const: gmac1_rmii_refin
+ - const: gmac1_rgmii_rxin
+ - const: i2stx_bclk_ext
+ - const: i2stx_lrck_ext
+ - const: i2srx_bclk_ext
+ - const: i2srx_lrck_ext
+ - const: tdm_ext
+ - const: mclk_ext
+ - const: pll0_out
+ - const: pll1_out
+ - const: pll2_out
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@13020000 {
+ compatible = "starfive,jh7110-syscrg";
+ reg = <0x13020000 0x10000>;
+ clocks = <&osc>, <&gmac1_rmii_refin>,
+ <&gmac1_rgmii_rxin>,
+ <&i2stx_bclk_ext>, <&i2stx_lrck_ext>,
+ <&i2srx_bclk_ext>, <&i2srx_lrck_ext>,
+ <&tdm_ext>, <&mclk_ext>,
+ <&pllclk 0>, <&pllclk 1>, <&pllclk 2>;
+ clock-names = "osc", "gmac1_rmii_refin",
+ "gmac1_rgmii_rxin",
+ "i2stx_bclk_ext", "i2stx_lrck_ext",
+ "i2srx_bclk_ext", "i2srx_lrck_ext",
+ "tdm_ext", "mclk_ext",
+ "pll0_out", "pll1_out", "pll2_out";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml
new file mode 100644
index 000000000000..af77bd8c86b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-voutcrg.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jh7110-voutcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Video-Output Clock and Reset Generator
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-voutcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Vout Top core
+ - description: Vout Top Ahb
+ - description: Vout Top Axi
+ - description: Vout Top HDMI MCLK
+ - description: I2STX0 BCLK
+ - description: external HDMI pixel
+
+ clock-names:
+ items:
+ - const: vout_src
+ - const: vout_top_ahb
+ - const: vout_top_axi
+ - const: vout_top_hdmitx0_mclk
+ - const: i2stx0_bclk
+ - const: hdmitx0_pixelclk
+
+ resets:
+ maxItems: 1
+ description: Vout Top core
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices.
+
+ power-domains:
+ maxItems: 1
+ description:
+ Vout domain power
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - '#clock-cells'
+ - '#reset-cells'
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+ #include <dt-bindings/power/starfive,jh7110-pmu.h>
+ #include <dt-bindings/reset/starfive,jh7110-crg.h>
+
+ voutcrg: clock-controller@295C0000 {
+ compatible = "starfive,jh7110-voutcrg";
+ reg = <0x295C0000 0x10000>;
+ clocks = <&syscrg JH7110_SYSCLK_VOUT_SRC>,
+ <&syscrg JH7110_SYSCLK_VOUT_TOP_AHB>,
+ <&syscrg JH7110_SYSCLK_VOUT_TOP_AXI>,
+ <&syscrg JH7110_SYSCLK_VOUT_TOP_HDMITX0_MCLK>,
+ <&syscrg JH7110_SYSCLK_I2STX0_BCLK>,
+ <&hdmitx0_pixelclk>;
+ clock-names = "vout_src", "vout_top_ahb",
+ "vout_top_axi", "vout_top_hdmitx0_mclk",
+ "i2stx0_bclk", "hdmitx0_pixelclk";
+ resets = <&syscrg JH7110_SYSRST_VOUT_TOP_SRC>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ power-domains = <&pwrc JH7110_PD_VOUT>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/stericsson,abx500.txt b/Documentation/devicetree/bindings/clock/stericsson,abx500.txt
deleted file mode 100644
index dbaa886b223e..000000000000
--- a/Documentation/devicetree/bindings/clock/stericsson,abx500.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Clock bindings for ST-Ericsson ABx500 clocks
-
-Required properties :
-- compatible : shall contain the following:
- "stericsson,ab8500-clk"
-- #clock-cells should be <1>
-
-The ABx500 clocks need to be placed as a subnode of an AB8500
-device node, see mfd/ab8500.txt
-
-All available clocks are defined as preprocessor macros in
-dt-bindings/clock/ste-ab8500.h header and can be used in device
-tree sources.
-
-Example:
-
-clock-controller {
- compatible = "stericsson,ab8500-clk";
- #clock-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml
index dc808e2f8327..b370a10a23a6 100644
--- a/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
FSD clock controller consist of several clock management unit
- (CMU), which generates clocks for various inteernal SoC blocks.
+ (CMU), which generates clocks for various internal SoC blocks.
The root clock comes from external OSC clock (24 MHz).
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml
new file mode 100644
index 000000000000..9d058c00ab3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/thead,th1520-clk-ap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD TH1520 AP sub-system clock controller
+
+description: |
+ The T-HEAD TH1520 AP sub-system clock controller configures the
+ CPU, DPU, GMAC and TEE PLLs. Additionally the VO subsystem configures
+ the clock gates for the HDMI, MIPI and the GPU.
+
+ SoC reference manual
+ https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf
+
+maintainers:
+ - Jisheng Zhang <jszhang@kernel.org>
+ - Wei Fu <wefu@redhat.com>
+ - Drew Fustini <dfustini@tenstorrent.com>
+
+properties:
+ compatible:
+ enum:
+ - thead,th1520-clk-ap
+ - thead,th1520-clk-vo
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: |
+ One input clock:
+ - For "thead,th1520-clk-ap": the clock input must be the 24 MHz
+ main oscillator.
+ - For "thead,th1520-clk-vo": the clock input must be the VIDEO_PLL,
+ which is configured by the AP clock controller. According to the
+ TH1520 manual, VIDEO_PLL is a Silicon Creations Sigma-Delta PLL
+ (integer PLL) typically running at 792 MHz (FOUTPOSTDIV), with
+ a maximum FOUTVCO of 2376 MHz.
+
+ "#clock-cells":
+ const: 1
+ description:
+ See <dt-bindings/clock/thead,th1520-clk-ap.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/thead,th1520-clk-ap.h>
+ clock-controller@ef010000 {
+ compatible = "thead,th1520-clk-ap";
+ reg = <0xef010000 0x1000>;
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
new file mode 100644
index 000000000000..b2e40bd39a3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,am62-audio-refclk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Audio Reference Clock
+
+maintainers:
+ - Jai Luthra <j-luthra@ti.com>
+
+properties:
+ compatible:
+ items:
+ - const: ti,am62-audio-refclk
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ audio_refclk0: clock@82e0 {
+ compatible = "ti,am62-audio-refclk";
+ reg = <0x82e0 0x4>;
+ clocks = <&k3_clks 157 0>;
+ assigned-clocks = <&k3_clks 157 0>;
+ assigned-clock-parents = <&k3_clks 157 8>;
+ #clock-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
index 66765116aff5..64b8bce5962c 100644
--- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
@@ -16,7 +16,6 @@ properties:
- ti,am654-ehrpwm-tbclk
- ti,am64-epwm-tbclk
- ti,am62-epwm-tbclk
- - const: syscon
"#clock-cells":
const: 1
@@ -33,8 +32,8 @@ additionalProperties: false
examples:
- |
- ehrpwm_tbclk: syscon@4140 {
- compatible = "ti,am654-ehrpwm-tbclk", "syscon";
+ ehrpwm_tbclk: clock@4140 {
+ compatible = "ti,am654-ehrpwm-tbclk";
reg = <0x4140 0x18>;
#clock-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.txt b/Documentation/devicetree/bindings/clock/ti,cdce925.txt
deleted file mode 100644
index df42ab72718f..000000000000
--- a/Documentation/devicetree/bindings/clock/ti,cdce925.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Binding for TI CDCE913/925/937/949 programmable I2C clock synthesizers.
-
-Reference
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] https://www.ti.com/product/cdce913
-[3] https://www.ti.com/product/cdce925
-[4] https://www.ti.com/product/cdce937
-[5] https://www.ti.com/product/cdce949
-
-The driver provides clock sources for each output Y1 through Y5.
-
-Required properties:
- - compatible: Shall be one of the following:
- - "ti,cdce913": 1-PLL, 3 Outputs
- - "ti,cdce925": 2-PLL, 5 Outputs
- - "ti,cdce937": 3-PLL, 7 Outputs
- - "ti,cdce949": 4-PLL, 9 Outputs
- - reg: I2C device address.
- - clocks: Points to a fixed parent clock that provides the input frequency.
- - #clock-cells: From common clock bindings: Shall be 1.
-
-Optional properties:
- - xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
- board, or to compensate for external influences.
-- vdd-supply: A regulator node for Vdd
-- vddout-supply: A regulator node for Vddout
-
-For all PLL1, PLL2, ... an optional child node can be used to specify spread
-spectrum clocking parameters for a board.
- - spread-spectrum: SSC mode as defined in the data sheet.
- - spread-spectrum-center: Use "centered" mode instead of "max" mode. When
- present, the clock runs at the requested frequency on average. Otherwise
- the requested frequency is the maximum value of the SCC range.
-
-
-Example:
-
- clockgen: cdce925pw@64 {
- compatible = "cdce925";
- reg = <0x64>;
- clocks = <&xtal_27Mhz>;
- #clock-cells = <1>;
- xtal-load-pf = <5>;
- vdd-supply = <&1v8-reg>;
- vddout-supply = <&3v3-reg>;
- /* PLL options to get SSC 1% centered */
- PLL2 {
- spread-spectrum = <4>;
- spread-spectrum-center;
- };
- };
diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.yaml b/Documentation/devicetree/bindings/clock/ti,cdce925.yaml
new file mode 100644
index 000000000000..95c1c6f8b755
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,cdce925.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,cdce925.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI CDCE913/925/937/949 programmable I2C clock synthesizers
+
+maintainers:
+ - Alexander Stein <alexander.stein@ew.tq-group.com>
+
+description: |
+ Flexible Low Power LVCMOS Clock Generator with SSC Support for EMI Reduction
+
+ - CDCE(L)913: 1-PLL, 3 Outputs https://www.ti.com/product/cdce913
+ - CDCE(L)925: 2-PLL, 5 Outputs https://www.ti.com/product/cdce925
+ - CDCE(L)937: 3-PLL, 7 Outputs https://www.ti.com/product/cdce937
+ - CDCE(L)949: 4-PLL, 9 Outputs https://www.ti.com/product/cdce949
+
+properties:
+ compatible:
+ enum:
+ - ti,cdce913
+ - ti,cdce925
+ - ti,cdce937
+ - ti,cdce949
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: fixed parent clock
+
+ "#clock-cells":
+ const: 1
+
+ vdd-supply:
+ description: Regulator that provides 1.8V Vdd power supply
+
+ vddout-supply:
+ description: |
+ Regulator that provides Vddout power supply.
+ non-L variant: 2.5V or 3.3V for
+ L variant: 1.8V for
+
+ xtal-load-pf:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Crystal load-capacitor value to fine-tune performance on a
+ board, or to compensate for external influences.
+
+patternProperties:
+ "^PLL[1-4]$":
+ type: object
+ description: |
+ optional child node can be used to specify spread
+ spectrum clocking parameters for a board
+
+ additionalProperties: false
+
+ properties:
+ spread-spectrum:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: SSC mode as defined in the data sheet
+
+ spread-spectrum-center:
+ type: boolean
+ description: |
+ Use "centered" mode instead of "max" mode. When
+ present, the clock runs at the requested frequency on average.
+ Otherwise the requested frequency is the maximum value of the
+ SCC range.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cdce925: clock-controller@64 {
+ compatible = "ti,cdce925";
+ reg = <0x64>;
+ clocks = <&xtal_27Mhz>;
+ #clock-cells = <1>;
+ xtal-load-pf = <5>;
+ vdd-supply = <&reg_1v8>;
+ vddout-supply = <&reg_3v3>;
+ /* PLL options to get SSC 1% centered */
+ PLL2 {
+ spread-spectrum = <4>;
+ spread-spectrum-center;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti,clkctrl.yaml b/Documentation/devicetree/bindings/clock/ti,clkctrl.yaml
new file mode 100644
index 000000000000..49787550ce45
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clkctrl.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,clkctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments clkctrl clock
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+ - Andreas Kemnade <andreas@kemnade.info>
+
+description: |
+ Texas Instruments SoCs can have a clkctrl clock controller for each
+ interconnect target module. The clkctrl clock controller manages functional
+ and interface clocks for each module. Each clkctrl controller can also
+ gate one or more optional functional clocks for a module, and can have one
+ or more clock muxes. There is a clkctrl clock controller typically for each
+ interconnect target module on omap4 and later variants.
+
+ The clock consumers can specify the index of the clkctrl clock using
+ the hardware offset from the clkctrl instance register space. The optional
+ clocks can be specified by clkctrl hardware offset and the index of the
+ optional clock.
+
+properties:
+ compatible:
+ enum:
+ - ti,clkctrl
+ - ti,clkctrl-l4-cfg
+ - ti,clkctrl-l4-per
+ - ti,clkctrl-l4-secure
+ - ti,clkctrl-l4-wkup
+
+ "#clock-cells":
+ const: 2
+
+ clock-output-names:
+ maxItems: 1
+
+ reg:
+ minItems: 1
+ maxItems: 8 # arbitrary, should be enough
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clock-output-names
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ clock@20 {
+ compatible = "ti,clkctrl";
+ clock-output-names = "l4_per";
+ reg = <0x20 0x1b0>;
+ #clock-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml
index bd8173848253..13d7b3d03d84 100644
--- a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/ti,lmk04832.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Clock bindings for the Texas Instruments LMK04832
+title: Texas Instruments LMK04832 Clock Controller
maintainers:
- Liam Beguin <liambeguin@gmail.com>
@@ -160,7 +160,7 @@ examples:
};
};
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
index 0e370289a053..66e8e66ca175 100644
--- a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI-SCI clock controller node bindings
+title: TI-SCI clock controller
maintainers:
- Nishanth Menon <nm@ti.com>
@@ -36,7 +36,7 @@ properties:
The second cell should contain the clock ID.
- Please see http://processors.wiki.ti.com/index.php/TISCI for
+ Please see https://software-dl.ti.com/tisci/esd/latest/index.html for
protocol documentation for the values to be used for different devices.
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
deleted file mode 100644
index d20db7974a38..000000000000
--- a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Texas Instruments clkctrl clock binding
-
-Texas Instruments SoCs can have a clkctrl clock controller for each
-interconnect target module. The clkctrl clock controller manages functional
-and interface clocks for each module. Each clkctrl controller can also
-gate one or more optional functional clocks for a module, and can have one
-or more clock muxes. There is a clkctrl clock controller typically for each
-interconnect target module on omap4 and later variants.
-
-The clock consumers can specify the index of the clkctrl clock using
-the hardware offset from the clkctrl instance register space. The optional
-clocks can be specified by clkctrl hardware offset and the index of the
-optional clock.
-
-For more information, please see the Linux clock framework binding at
-Documentation/devicetree/bindings/clock/clock-bindings.txt.
-
-Required properties :
-- compatible : shall be "ti,clkctrl" or a clock domain specific name:
- "ti,clkctrl-l4-cfg"
- "ti,clkctrl-l4-per"
- "ti,clkctrl-l4-secure"
- "ti,clkctrl-l4-wkup"
-- clock-output-names : from common clock binding
-- #clock-cells : shall contain 2 with the first entry being the instance
- offset from the clock domain base and the second being the
- clock index
-- reg : clock registers
-
-Example: Clock controller node on omap 4430:
-
-&cm2 {
- l4per: cm@1400 {
- cm_l4per@0 {
- cm_l4per_clkctrl: clock@20 {
- compatible = "ti,clkctrl";
- clock-output-names = "l4_per";
- reg = <0x20 0x1b0>;
- #clock-cells = <2>;
- };
- };
- };
-};
-
-Example: Preprocessor helper macros in dt-bindings/clock/ti-clkctrl.h
-
-#define OMAP4_CLKCTRL_OFFSET 0x20
-#define OMAP4_CLKCTRL_INDEX(offset) ((offset) - OMAP4_CLKCTRL_OFFSET)
-#define MODULEMODE_HWCTRL 1
-#define MODULEMODE_SWCTRL 2
-
-#define OMAP4_GPTIMER10_CLKTRL OMAP4_CLKCTRL_INDEX(0x28)
-#define OMAP4_GPTIMER11_CLKTRL OMAP4_CLKCTRL_INDEX(0x30)
-#define OMAP4_GPTIMER2_CLKTRL OMAP4_CLKCTRL_INDEX(0x38)
-...
-#define OMAP4_GPIO2_CLKCTRL OMAP_CLKCTRL_INDEX(0x60)
-
-Example: Clock consumer node for GPIO2:
-
-&gpio2 {
- clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0
- &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 8>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
deleted file mode 100644
index c35cb6c4af4d..000000000000
--- a/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Device tree bindings for Texas Instruments keystone pll controller
-
-The main pll controller used to drive theC66x CorePacs, the switch fabric,
-and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and
-the NETCP modules) requires a PLL Controller to manage the various clock
-divisions, gating, and synchronization.
-
-Required properties:
-
-- compatible: "ti,keystone-pllctrl", "syscon"
-
-- reg: contains offset/length value for pll controller
- registers space.
-
-Example:
-
-pllctrl: pll-controller@02310000 {
- compatible = "ti,keystone-pllctrl", "syscon";
- reg = <0x02310000 0x200>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt b/Documentation/devicetree/bindings/clock/ti/adpll.txt
index 4c8a2ce2cd70..3122360adcf3 100644
--- a/Documentation/devicetree/bindings/clock/ti/adpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -1,7 +1,5 @@
Binding for Texas Instruments ADPLL clock.
-Binding status: Unstable - ABI compatibility may be broken in the future
-
This binding uses the common clock binding[1]. It assumes a
register-mapped ADPLL with two to three selectable input clocks
and three to four children.
diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt b/Documentation/devicetree/bindings/clock/ti/apll.txt
index ade4dd4c30f0..bbd505c1199d 100644
--- a/Documentation/devicetree/bindings/clock/ti/apll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/apll.txt
@@ -1,7 +1,5 @@
Binding for Texas Instruments APLL clock.
-Binding status: Unstable - ABI compatibility may be broken in the future
-
This binding uses the common clock binding[1]. It assumes a
register-mapped APLL with usually two selectable input clocks
(reference clock and bypass clock), with analog phase locked
diff --git a/Documentation/devicetree/bindings/clock/ti/autoidle.txt b/Documentation/devicetree/bindings/clock/ti/autoidle.txt
deleted file mode 100644
index 7c735dde9fe9..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/autoidle.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Binding for Texas Instruments autoidle clock.
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1]. It assumes a register mapped
-clock which can be put to idle automatically by hardware based on the usage
-and a configuration bit setting. Autoidle clock is never an individual
-clock, it is always a derivative of some basic clock like a gate, divider,
-or fixed-factor.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- reg : offset for the register controlling the autoidle
-- ti,autoidle-shift : bit shift of the autoidle enable bit
-- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0
-
-Examples:
- dpll_core_m4_ck: dpll_core_m4_ck {
- #clock-cells = <0>;
- compatible = "ti,divider-clock";
- clocks = <&dpll_core_x2_ck>;
- ti,max-div = <31>;
- ti,autoidle-shift = <8>;
- reg = <0x2d38>;
- ti,index-starts-at-one;
- ti,invert-autoidle-bit;
- };
-
- dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck {
- #clock-cells = <0>;
- compatible = "ti,fixed-factor-clock";
- clocks = <&dpll_usb_ck>;
- ti,clock-div = <1>;
- ti,autoidle-shift = <8>;
- reg = <0x01b4>;
- ti,clock-mult = <1>;
- ti,invert-autoidle-bit;
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
index 9c6199249ce5..edf0b5d42768 100644
--- a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
@@ -1,7 +1,5 @@
Binding for Texas Instruments clockdomain.
-Binding status: Unstable - ABI compatibility may be broken in the future
-
This binding uses the common clock binding[1] in consumer role.
Every clock on TI SoC belongs to one clockdomain, but software
only needs this information for specific clocks which require
diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt b/Documentation/devicetree/bindings/clock/ti/composite.txt
deleted file mode 100644
index 33ac7c9ad053..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/composite.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Binding for TI composite clock.
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1]. It assumes a
-register-mapped composite clock with multiple different sub-types;
-
-a multiplexer clock with multiple input clock signals or parents, one
-of which can be selected as output, this behaves exactly as [2]
-
-an adjustable clock rate divider, this behaves exactly as [3]
-
-a gating function which can be used to enable and disable the output
-clock, this behaves exactly as [4]
-
-The binding must provide a list of the component clocks that shall be
-merged to this clock. The component clocks shall be of one of the
-"ti,*composite*-clock" types.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/ti/mux.txt
-[3] Documentation/devicetree/bindings/clock/ti/divider.txt
-[4] Documentation/devicetree/bindings/clock/ti/gate.txt
-
-Required properties:
-- compatible : shall be: "ti,composite-clock"
-- clocks : link phandles of component clocks
-- #clock-cells : from common clock binding; shall be set to 0.
-
-Optional properties:
-- clock-output-names : from common clock binding.
-
-Examples:
-
-usb_l4_gate_ick: usb_l4_gate_ick {
- #clock-cells = <0>;
- compatible = "ti,composite-interface-clock";
- clocks = <&l4_ick>;
- ti,bit-shift = <5>;
- reg = <0x0a10>;
-};
-
-usb_l4_div_ick: usb_l4_div_ick {
- #clock-cells = <0>;
- compatible = "ti,composite-divider-clock";
- clocks = <&l4_ick>;
- ti,bit-shift = <4>;
- ti,max-div = <1>;
- reg = <0x0a40>;
- ti,index-starts-at-one;
-};
-
-usb_l4_ick: usb_l4_ick {
- #clock-cells = <0>;
- compatible = "ti,composite-clock";
- clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti/divider.txt b/Documentation/devicetree/bindings/clock/ti/divider.txt
deleted file mode 100644
index 9b13b32974f9..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/divider.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-Binding for TI divider clock
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1]. It assumes a
-register-mapped adjustable clock rate divider that does not gate and has
-only one input clock or parent. By default the value programmed into
-the register is one less than the actual divisor value. E.g:
-
-register value actual divisor value
-0 1
-1 2
-2 3
-
-This assumption may be modified by the following optional properties:
-
-ti,index-starts-at-one - valid divisor values start at 1, not the default
-of 0. E.g:
-register value actual divisor value
-1 1
-2 2
-3 3
-
-ti,index-power-of-two - valid divisor values are powers of two. E.g:
-register value actual divisor value
-0 1
-1 2
-2 4
-
-Additionally an array of valid dividers may be supplied like so:
-
- ti,dividers = <4>, <8>, <0>, <16>;
-
-Which will map the resulting values to a divisor table by their index:
-register value actual divisor value
-0 4
-1 8
-2 <invalid divisor, skipped>
-3 16
-
-Any zero value in this array means the corresponding bit-value is invalid
-and must not be used.
-
-The binding must also provide the register to control the divider and
-unless the divider array is provided, min and max dividers. Optionally
-the number of bits to shift that mask, if necessary. If the shift value
-is missing it is the same as supplying a zero shift.
-
-This binding can also optionally provide support to the hardware autoidle
-feature, see [2].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt
-
-Required properties:
-- compatible : shall be "ti,divider-clock" or "ti,composite-divider-clock".
-- #clock-cells : from common clock binding; shall be set to 0.
-- clocks : link to phandle of parent clock
-- reg : offset for register controlling adjustable divider
-
-Optional properties:
-- clock-output-names : from common clock binding.
-- ti,dividers : array of integers defining divisors
-- ti,bit-shift : number of bits to shift the divider value, defaults to 0
-- ti,min-div : min divisor for dividing the input clock rate, only
- needed if the first divisor is offset from the default value (1)
-- ti,max-div : max divisor for dividing the input clock rate, only needed
- if ti,dividers is not defined.
-- ti,index-starts-at-one : valid divisor programming starts at 1, not zero,
- only valid if ti,dividers is not defined.
-- ti,index-power-of-two : valid divisor programming must be a power of two,
- only valid if ti,dividers is not defined.
-- ti,autoidle-shift : bit shift of the autoidle enable bit for the clock,
- see [2]
-- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0,
- see [2]
-- ti,set-rate-parent : clk_set_rate is propagated to parent
-- ti,latch-bit : latch the divider value to HW, only needed if the register
- access requires this. As an example dra76x DPLL_GMAC H14 divider implements
- such behavior.
-
-Examples:
-dpll_usb_m2_ck: dpll_usb_m2_ck@4a008190 {
- #clock-cells = <0>;
- compatible = "ti,divider-clock";
- clocks = <&dpll_usb_ck>;
- ti,max-div = <127>;
- reg = <0x190>;
- ti,index-starts-at-one;
-};
-
-aess_fclk: aess_fclk@4a004528 {
- #clock-cells = <0>;
- compatible = "ti,divider-clock";
- clocks = <&abe_clk>;
- ti,bit-shift = <24>;
- reg = <0x528>;
- ti,max-div = <2>;
-};
-
-dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck {
- #clock-cells = <0>;
- compatible = "ti,composite-divider-clock";
- clocks = <&dpll_core_x2_ck>;
- ti,max-div = <31>;
- reg = <0x0134>;
- ti,index-starts-at-one;
-};
-
-ssi_ssr_div_fck_3430es2: ssi_ssr_div_fck_3430es2 {
- #clock-cells = <0>;
- compatible = "ti,composite-divider-clock";
- clocks = <&corex2_fck>;
- ti,bit-shift = <8>;
- reg = <0x0a40>;
- ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index 37a7cb6ad07d..14a1b72c2e71 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -1,7 +1,5 @@
Binding for Texas Instruments DPLL clock.
-Binding status: Unstable - ABI compatibility may be broken in the future
-
This binding uses the common clock binding[1]. It assumes a
register-mapped DPLL with usually two selectable input clocks
(reference clock and bypass clock), with digital phase locked
diff --git a/Documentation/devicetree/bindings/clock/ti/fapll.txt b/Documentation/devicetree/bindings/clock/ti/fapll.txt
index c19b3f253b8c..88986ef39ddd 100644
--- a/Documentation/devicetree/bindings/clock/ti/fapll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/fapll.txt
@@ -1,7 +1,5 @@
Binding for Texas Instruments FAPLL clock.
-Binding status: Unstable - ABI compatibility may be broken in the future
-
This binding uses the common clock binding[1]. It assumes a
register-mapped FAPLL with usually two selectable input clocks
(reference clock and bypass clock), and one or more child
diff --git a/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt
deleted file mode 100644
index 518e3c142276..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Binding for TI fixed factor rate clock sources.
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1], and also uses the autoidle
-support from TI autoidle clock [2].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt
-
-Required properties:
-- compatible : shall be "ti,fixed-factor-clock".
-- #clock-cells : from common clock binding; shall be set to 0.
-- ti,clock-div: fixed divider.
-- ti,clock-mult: fixed multiplier.
-- clocks: parent clock.
-
-Optional properties:
-- clock-output-names : from common clock binding.
-- ti,autoidle-shift: bit shift of the autoidle enable bit for the clock,
- see [2]
-- reg: offset for the autoidle register of this clock, see [2]
-- ti,invert-autoidle-bit: autoidle is enabled by setting the bit to 0, see [2]
-- ti,set-rate-parent: clk_set_rate is propagated to parent
-
-Example:
- clock {
- compatible = "ti,fixed-factor-clock";
- clocks = <&parentclk>;
- #clock-cells = <0>;
- ti,clock-div = <2>;
- ti,clock-mult = <1>;
- };
-
- dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck {
- #clock-cells = <0>;
- compatible = "ti,fixed-factor-clock";
- clocks = <&dpll_usb_ck>;
- ti,clock-div = <1>;
- ti,autoidle-shift = <8>;
- reg = <0x01b4>;
- ti,clock-mult = <1>;
- ti,invert-autoidle-bit;
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt
deleted file mode 100644
index b4820b1de4f0..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/gate.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-Binding for Texas Instruments gate clock.
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1]. This clock is
-quite much similar to the basic gate-clock [2], however,
-it supports a number of additional features. If no register
-is provided for this clock, the code assumes that a clockdomain
-will be controlled instead and the corresponding hw-ops for
-that is used.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
-[3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
-
-Required properties:
-- compatible : shall be one of:
- "ti,gate-clock" - basic gate clock
- "ti,wait-gate-clock" - gate clock which waits until clock is active before
- returning from clk_enable()
- "ti,dss-gate-clock" - gate clock with DSS specific hardware handling
- "ti,am35xx-gate-clock" - gate clock with AM35xx specific hardware handling
- "ti,clkdm-gate-clock" - clockdomain gate clock, which derives its functional
- clock directly from a clockdomain, see [3] how
- to map clockdomains properly
- "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling,
- required for a hardware errata
- "ti,composite-gate-clock" - composite gate clock, to be part of composite
- clock
- "ti,composite-no-wait-gate-clock" - composite gate clock that does not wait
- for clock to be active before returning
- from clk_enable()
-- #clock-cells : from common clock binding; shall be set to 0
-- clocks : link to phandle of parent clock
-- reg : offset for register controlling adjustable gate, not needed for
- ti,clkdm-gate-clock type
-
-Optional properties:
-- clock-output-names : from common clock binding.
-- ti,bit-shift : bit shift for programming the clock gate, invalid for
- ti,clkdm-gate-clock type
-- ti,set-bit-to-disable : inverts default gate programming. Setting the bit
- gates the clock and clearing the bit ungates the clock.
-
-Examples:
- mmchs2_fck: mmchs2_fck@48004a00 {
- #clock-cells = <0>;
- compatible = "ti,gate-clock";
- clocks = <&core_96m_fck>;
- reg = <0x0a00>;
- ti,bit-shift = <25>;
- };
-
- uart4_fck_am35xx: uart4_fck_am35xx {
- #clock-cells = <0>;
- compatible = "ti,wait-gate-clock";
- clocks = <&core_48m_fck>;
- reg = <0x0a00>;
- ti,bit-shift = <23>;
- };
-
- dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2@48004e00 {
- #clock-cells = <0>;
- compatible = "ti,dss-gate-clock";
- clocks = <&dpll4_m4x2_ck>;
- reg = <0x0e00>;
- ti,bit-shift = <0>;
- };
-
- emac_ick: emac_ick@4800259c {
- #clock-cells = <0>;
- compatible = "ti,am35xx-gate-clock";
- clocks = <&ipss_ick>;
- reg = <0x059c>;
- ti,bit-shift = <1>;
- };
-
- emu_src_ck: emu_src_ck {
- #clock-cells = <0>;
- compatible = "ti,clkdm-gate-clock";
- clocks = <&emu_src_mux_ck>;
- };
-
- dpll4_m2x2_ck: dpll4_m2x2_ck@48004d00 {
- #clock-cells = <0>;
- compatible = "ti,hsdiv-gate-clock";
- clocks = <&dpll4_m2x2_mul_ck>;
- ti,bit-shift = <0x1b>;
- reg = <0x0d00>;
- ti,set-bit-to-disable;
- };
-
- vlynq_gate_fck: vlynq_gate_fck {
- #clock-cells = <0>;
- compatible = "ti,composite-gate-clock";
- clocks = <&core_ck>;
- ti,bit-shift = <3>;
- reg = <0x0200>;
- };
-
- sys_clkout2_src_gate: sys_clkout2_src_gate {
- #clock-cells = <0>;
- compatible = "ti,composite-no-wait-gate-clock";
- clocks = <&core_ck>;
- ti,bit-shift = <15>;
- reg = <0x0070>;
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt
deleted file mode 100644
index 94ec77dc3c59..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/interface.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Binding for Texas Instruments interface clock.
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1]. This clock is
-quite much similar to the basic gate-clock [2], however,
-it supports a number of additional features, including
-companion clock finding (match corresponding functional gate
-clock) and hardware autoidle enable / disable.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
-
-Required properties:
-- compatible : shall be one of:
- "ti,omap3-interface-clock" - basic OMAP3 interface clock
- "ti,omap3-no-wait-interface-clock" - interface clock which has no hardware
- capability for waiting clock to be ready
- "ti,omap3-hsotgusb-interface-clock" - interface clock with USB specific HW
- handling
- "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling
- "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling
- "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling
- "ti,omap2430-interface-clock" - interface clock with OMAP2430 specific HW
- handling
-- #clock-cells : from common clock binding; shall be set to 0
-- clocks : link to phandle of parent clock
-- reg : base address for the control register
-
-Optional properties:
-- clock-output-names : from common clock binding.
-- ti,bit-shift : bit shift for the bit enabling/disabling the clock (default 0)
-
-Examples:
- aes1_ick: aes1_ick@48004a14 {
- #clock-cells = <0>;
- compatible = "ti,omap3-interface-clock";
- clocks = <&security_l4_ick2>;
- reg = <0x48004a14 0x4>;
- ti,bit-shift = <3>;
- };
-
- cam_ick: cam_ick@48004f10 {
- #clock-cells = <0>;
- compatible = "ti,omap3-no-wait-interface-clock";
- clocks = <&l4_ick>;
- reg = <0x48004f10 0x4>;
- ti,bit-shift = <0>;
- };
-
- ssi_ick_3430es2: ssi_ick_3430es2@48004a10 {
- #clock-cells = <0>;
- compatible = "ti,omap3-ssi-interface-clock";
- clocks = <&ssi_l4_ick>;
- reg = <0x48004a10 0x4>;
- ti,bit-shift = <0>;
- };
diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt
deleted file mode 100644
index e17425a58621..000000000000
--- a/Documentation/devicetree/bindings/clock/ti/mux.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-Binding for TI mux clock.
-
-Binding status: Unstable - ABI compatibility may be broken in the future
-
-This binding uses the common clock binding[1]. It assumes a
-register-mapped multiplexer with multiple input clock signals or
-parents, one of which can be selected as output. This clock does not
-gate or adjust the parent rate via a divider or multiplier.
-
-By default the "clocks" property lists the parents in the same order
-as they are programmed into the regster. E.g:
-
- clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
-
-results in programming the register as follows:
-
-register value selected parent clock
-0 foo_clock
-1 bar_clock
-2 baz_clock
-
-Some clock controller IPs do not allow a value of zero to be programmed
-into the register, instead indexing begins at 1. The optional property
-"index-starts-at-one" modified the scheme as follows:
-
-register value selected clock parent
-1 foo_clock
-2 bar_clock
-3 baz_clock
-
-The binding must provide the register to control the mux. Optionally
-the number of bits to shift the control field in the register can be
-supplied. If the shift value is missing it is the same as supplying
-a zero shift.
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "ti,mux-clock" or "ti,composite-mux-clock".
-- #clock-cells : from common clock binding; shall be set to 0.
-- clocks : link phandles of parent clocks
-- reg : register offset for register controlling adjustable mux
-
-Optional properties:
-- clock-output-names : from common clock binding.
-- ti,bit-shift : number of bits to shift the bit-mask, defaults to
- 0 if not present
-- ti,index-starts-at-one : valid input select programming starts at 1, not
- zero
-- ti,set-rate-parent : clk_set_rate is propagated to parent clock,
- not supported by the composite-mux-clock subtype
-- ti,latch-bit : latch the mux value to HW, only needed if the register
- access requires this. As an example, dra7x DPLL_GMAC H14 muxing
- implements such behavior.
-
-Examples:
-
-sys_clkin_ck: sys_clkin_ck@4a306110 {
- #clock-cells = <0>;
- compatible = "ti,mux-clock";
- clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>;
- reg = <0x0110>;
- ti,index-starts-at-one;
-};
-
-abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 {
- #clock-cells = <0>;
- compatible = "ti,mux-clock";
- clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
- ti,bit-shift = <24>;
- reg = <0x0108>;
-};
-
-mcbsp5_mux_fck: mcbsp5_mux_fck {
- #clock-cells = <0>;
- compatible = "ti,composite-mux-clock";
- clocks = <&core_96m_fck>, <&mcbsp_clks>;
- ti,bit-shift = <4>;
- reg = <0x02d8>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,autoidle.yaml b/Documentation/devicetree/bindings/clock/ti/ti,autoidle.yaml
new file mode 100644
index 000000000000..ed1bf182b64d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,autoidle.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,autoidle.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI autoidle clock
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+ - Sukrut Bellary <sbellary@baylibre.com>
+
+description:
+ Some clocks in TI SoC support the autoidle feature. These properties are
+ applicable only if the clock supports autoidle feature. It assumes a register
+ mapped clock which can be put to idle automatically by hardware based on
+ usage and configuration bit setting. Autoidle clock is never an individual
+ clock, it is always a derivative of some basic clock like a gate, divider, or
+ fixed-factor.
+
+properties:
+ ti,autoidle-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ bit shift of the autoidle enable bit for the clock
+ maximum: 31
+ default: 0
+
+ ti,invert-autoidle-bit:
+ type: boolean
+ description:
+ autoidle is enabled by setting the bit to 0
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml b/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml
index c56f911fff47..d525f96cf244 100644
--- a/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml
+++ b/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/ti/ti,clksel.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for TI clksel clock
+title: TI clksel clock
maintainers:
- Tony Lindgren <tony@atomide.com>
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml
new file mode 100644
index 000000000000..31a6794852c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,composite-clock.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,composite-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments composite clock
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description: |
+ *Deprecated design pattern: one node per clock*
+
+ This binding assumes a register-mapped composite clock with multiple
+ different sub-types:
+
+ a multiplexer clock with multiple input clock signals or parents, one
+ of which can be selected as output, this behaves exactly as [1].
+
+ an adjustable clock rate divider, this behaves exactly as [2].
+
+ a gating function which can be used to enable and disable the output
+ clock, this behaves exactly as [3].
+
+ The binding must provide a list of the component clocks that shall be
+ merged to this clock. The component clocks shall be of one of the
+ "ti,*composite*-clock" types.
+
+ [1] Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
+ [2] Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml
+ [3] Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
+
+properties:
+ compatible:
+ const: ti,composite-clock
+
+ "#clock-cells":
+ const: 0
+
+ clocks: true
+
+ clock-output-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb_l4_gate_ick: clock-controller@a10 {
+ #clock-cells = <0>;
+ compatible = "ti,composite-gate-clock";
+ clocks = <&l4_ick>;
+ ti,bit-shift = <5>;
+ reg = <0x0a10>;
+ };
+
+ usb_l4_div_ick: clock-controller@a40 {
+ #clock-cells = <0>;
+ compatible = "ti,composite-divider-clock";
+ clocks = <&l4_ick>;
+ ti,bit-shift = <4>;
+ ti,max-div = <1>;
+ reg = <0x0a40>;
+ ti,index-starts-at-one;
+ };
+ };
+
+ clock-controller {
+ #clock-cells = <0>;
+ compatible = "ti,composite-clock";
+ clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml
new file mode 100644
index 000000000000..6729fcb839d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml
@@ -0,0 +1,179 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,divider-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments divider clock
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description: |
+ This clock It assumes a register-mapped adjustable clock rate divider
+ that does not gate and has only one input clock or parent. By default the
+ value programmed into the register is one less than the actual divisor value.
+ E.g:
+
+ register value actual divisor value
+ 0 1
+ 1 2
+ 2 3
+
+ This assumption may be modified by the following optional properties:
+
+ ti,index-starts-at-one - valid divisor values start at 1, not the default
+ of 0. E.g:
+ register value actual divisor value
+ 1 1
+ 2 2
+ 3 3
+
+ ti,index-power-of-two - valid divisor values are powers of two. E.g:
+ register value actual divisor value
+ 0 1
+ 1 2
+ 2 4
+
+ Additionally an array of valid dividers may be supplied like so:
+
+ ti,dividers = <4>, <8>, <0>, <16>;
+
+ Which will map the resulting values to a divisor table by their index:
+ register value actual divisor value
+ 0 4
+ 1 8
+ 2 <invalid divisor, skipped>
+ 3 16
+
+ Any zero value in this array means the corresponding bit-value is invalid
+ and must not be used.
+
+ The binding must also provide the register to control the divider and
+ unless the divider array is provided, min and max dividers. Optionally
+ the number of bits to shift that mask, if necessary. If the shift value
+ is missing it is the same as supplying a zero shift.
+
+ This binding can also optionally provide support to the hardware autoidle
+ feature.
+
+allOf:
+ - $ref: ti,autoidle.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,divider-clock
+ - ti,composite-divider-clock
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-output-names:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ ti,dividers:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ array of integers defining divisors
+
+ ti,bit-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ number of bits to shift the divider value
+ maximum: 31
+ default: 0
+
+ ti,min-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ min divisor for dividing the input clock rate, only
+ needed if the first divisor is offset from the default value (1)
+ minimum: 1
+ default: 1
+
+ ti,max-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ max divisor for dividing the input clock rate, only needed
+ if ti,dividers is not defined.
+
+ ti,index-starts-at-one:
+ type: boolean
+ description:
+ valid divisor programming starts at 1, not zero,
+ only valid if ti,dividers is not defined
+
+ ti,index-power-of-two:
+ type: boolean
+ description:
+ valid divisor programming must be a power of two,
+ only valid if ti,dividers is not defined.
+
+ ti,set-rate-parent:
+ type: boolean
+ description:
+ clk_set_rate is propagated to parent |
+
+ ti,latch-bit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ latch the divider value to HW, only needed if the register
+ compatible access requires this. As an example dra76x DPLL_GMAC
+ H14 divider implements such behavior.
+
+dependentSchemas:
+ ti,dividers:
+ properties:
+ ti,min-div: false
+ ti,max-div: false
+ ti,index-power-of-two: false
+ ti,index-starts-at-one: false
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@190 {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&dpll_usb_ck>;
+ ti,max-div = <127>;
+ reg = <0x190>;
+ ti,index-starts-at-one;
+ };
+
+ clock-controller@528 {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&abe_clk>;
+ ti,bit-shift = <24>;
+ reg = <0x528>;
+ ti,max-div = <2>;
+ };
+
+ clock-controller@a40 {
+ #clock-cells = <0>;
+ compatible = "ti,composite-divider-clock";
+ clocks = <&corex2_fck>;
+ ti,bit-shift = <8>;
+ reg = <0x0a40>;
+ ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,fixed-factor-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,fixed-factor-clock.yaml
new file mode 100644
index 000000000000..7a63b0992976
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,fixed-factor-clock.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,fixed-factor-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI fixed factor rate clock sources
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+ - Sukrut Bellary <sbellary@baylibre.com>
+
+description:
+ This consists of a divider and a multiplier used to generate a fixed rate
+ clock. This also uses the autoidle support from TI autoidle clock.
+
+allOf:
+ - $ref: ti,autoidle.yaml#
+
+properties:
+ compatible:
+ const: ti,fixed-factor-clock
+
+ "#clock-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ ti,clock-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Fixed divider
+ minimum: 1
+
+ ti,clock-mult:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Fixed multiplier
+ minimum: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-output-names:
+ maxItems: 1
+
+ ti,set-rate-parent:
+ description:
+ Propagate to parent clock
+ type: boolean
+
+required:
+ - compatible
+ - clocks
+ - "#clock-cells"
+ - ti,clock-mult
+ - ti,clock-div
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus{
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock@1b4 {
+ compatible = "ti,fixed-factor-clock";
+ reg = <0x1b4>;
+ clocks = <&dpll_usb_ck>;
+ #clock-cells = <0>;
+ ti,clock-mult = <1>;
+ ti,clock-div = <1>;
+ ti,autoidle-shift = <8>;
+ ti,invert-autoidle-bit;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
new file mode 100644
index 000000000000..eaa727ab0d7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,gate-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments gate clock
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description: |
+ *Deprecated design pattern: one node per clock*
+
+ This clock is quite much similar to the basic gate-clock [1], however,
+ it supports a number of additional features. If no register
+ is provided for this clock, the code assumes that a clockdomain
+ will be controlled instead and the corresponding hw-ops for
+ that is used.
+
+ [1] Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml
+ [2] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+
+properties:
+ compatible:
+ enum:
+ - ti,gate-clock # basic gate clock
+ - ti,wait-gate-clock # gate clock which waits until clock is
+ # active before returning from clk_enable()
+ - ti,dss-gate-clock # gate clock with DSS specific hardware
+ # handling
+ - ti,am35xx-gate-clock # gate clock with AM35xx specific hardware
+ # handling
+ - ti,clkdm-gate-clock # clockdomain gate clock, which derives its
+ # functional clock directly from a
+ # clockdomain, see [2] how to map
+ # clockdomains properly
+ - ti,hsdiv-gate-clock # gate clock with OMAP36xx specific hardware
+ # handling, required for a hardware errata
+ - ti,composite-gate-clock # composite gate clock, to be part of
+ # composite clock
+ - ti,composite-no-wait-gate-clock # composite gate clock that does not
+ # wait for clock to be active before
+ # returning from clk_enable()
+ "#clock-cells":
+ const: 0
+
+ clocks: true
+
+ clock-output-names:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ ti,bit-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of bits to shift the bit-mask
+ maximum: 31
+ default: 0
+
+ ti,set-bit-to-disable:
+ type: boolean
+ description:
+ Inverts default gate programming. Setting the bit
+ gates the clock and clearing the bit ungates the clock.
+
+ ti,set-rate-parent:
+ type: boolean
+ description:
+ clk_set_rate is propagated to parent clock,
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: ti,clkdm-gate-clock
+then:
+ properties:
+ reg: false
+ required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+else:
+ required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@a00 {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&core_96m_fck>;
+ reg = <0x0a00>;
+ ti,bit-shift = <25>;
+ };
+
+ clock-controller@d00 {
+ compatible = "ti,hsdiv-gate-clock";
+ reg = <0x0d00>;
+ #clock-cells = <0>;
+ clocks = <&dpll4_m2x2_mul_ck>;
+ ti,bit-shift = <0x1b>;
+ ti,set-bit-to-disable;
+ };
+ };
+
+ - |
+ clock-controller {
+ #clock-cells = <0>;
+ compatible = "ti,clkdm-gate-clock";
+ clocks = <&emu_src_mux_ck>;
+ };
+
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,interface-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,interface-clock.yaml
new file mode 100644
index 000000000000..1eaf95d88e0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,interface-clock.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,interface-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments interface clock.
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description: |
+ This clock is quite much similar to the basic gate-clock[1], however,
+ it supports a number of additional features, including
+ companion clock finding (match corresponding functional gate
+ clock) and hardware autoidle enable / disable.
+
+ [1] Documentation/devicetree/bindings/clock/gpio-gate-clock.yaml
+
+properties:
+ compatible:
+ enum:
+ - ti,omap3-interface-clock # basic OMAP3 interface clock
+ - ti,omap3-no-wait-interface-clock # interface clock which has no hardware
+ # capability for waiting clock to be ready
+ - ti,omap3-hsotgusb-interface-clock # interface clock with USB specific HW handling
+ - ti,omap3-dss-interface-clock # interface clock with DSS specific HW handling
+ - ti,omap3-ssi-interface-clock # interface clock with SSI specific HW handling
+ - ti,am35xx-interface-clock # interface clock with AM35xx specific HW handling
+ - ti,omap2430-interface-clock # interface clock with OMAP2430 specific HW handling
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-output-names:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ ti,bit-shift:
+ description:
+ bit shift for the bit enabling/disabling the clock
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ maximum: 31
+
+required:
+ - compatible
+ - clocks
+ - '#clock-cells'
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ aes1_ick: clock-controller@3 {
+ #clock-cells = <0>;
+ compatible = "ti,omap3-interface-clock";
+ clocks = <&security_l4_ick2>;
+ reg = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
new file mode 100644
index 000000000000..485b6aae85d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti/ti,mux-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments mux clock
+
+maintainers:
+ - Tero Kristo <kristo@kernel.org>
+
+description: |
+ This clock assumes a register-mapped multiplexer with multiple inpt clock
+ signals or parents, one of which can be selected as output. This clock does
+ not gate or adjust the parent rate via a divider or multiplier.
+
+ By default the "clocks" property lists the parents in the same order
+ as they are programmed into the register. E.g:
+
+ clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
+
+ Results in programming the register as follows:
+
+ register value selected parent clock
+ 0 foo_clock
+ 1 bar_clock
+ 2 baz_clock
+
+ Some clock controller IPs do not allow a value of zero to be programmed
+ into the register, instead indexing begins at 1. The optional property
+ "index-starts-at-one" modified the scheme as follows:
+
+ register value selected clock parent
+ 1 foo_clock
+ 2 bar_clock
+ 3 baz_clock
+
+ The binding must provide the register to control the mux. Optionally
+ the number of bits to shift the control field in the register can be
+ supplied. If the shift value is missing it is the same as supplying
+ a zero shift.
+
+properties:
+ compatible:
+ enum:
+ - ti,mux-clock
+ - ti,composite-mux-clock
+
+ "#clock-cells":
+ const: 0
+
+ clocks: true
+
+ clock-output-names:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ ti,bit-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of bits to shift the bit-mask
+ maximum: 31
+ default: 0
+
+ ti,index-starts-at-one:
+ type: boolean
+ description:
+ Valid input select programming starts at 1, not zero
+
+ ti,set-rate-parent:
+ type: boolean
+ description:
+ clk_set_rate is propagated to parent clock,
+ not supported by the composite-mux-clock subtype.
+
+ ti,latch-bit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Latch the mux value to HW, only needed if the register
+ access requires this. As an example, dra7x DPLL_GMAC H14 muxing
+ implements such behavior.
+ maximum: 31
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: ti,composite-mux-clock
+then:
+ properties:
+ ti,set-rate-parent: false
+
+required:
+ - compatible
+ - "#clock-cells"
+ - clocks
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@110 {
+ compatible = "ti,mux-clock";
+ reg = <0x0110>;
+ #clock-cells = <0>;
+ clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>;
+ ti,index-starts-at-one;
+ ti,set-rate-parent;
+ };
+
+ clock-controller@120 {
+ compatible = "ti,composite-mux-clock";
+ reg = <0x0120>;
+ #clock-cells = <0>;
+ clocks = <&core_96m_fck>, <&mcbsp_clks>;
+ ti,bit-shift = <4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml
index 7b7300ce96d6..d36558aa39f3 100644
--- a/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml
+++ b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/toshiba,tmpv770x-pipllct.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba Visconti5 TMPV770X PLL Controller Device Tree Bindings
+title: Toshiba Visconti5 TMPV770X PLL Controller
maintainers:
- Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
diff --git a/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml
index ed79f16fe6bc..081f85b1eb88 100644
--- a/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml
+++ b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/toshiba,tmpv770x-pismu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba Visconti5 TMPV770x SMU controller Device Tree Bindings
+title: Toshiba Visconti5 TMPV770x SMU controller
maintainers:
- Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt
deleted file mode 100644
index 63f9f1ac3439..000000000000
--- a/Documentation/devicetree/bindings/clock/vf610-clock.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Clock bindings for Freescale Vybrid VF610 SOC
-
-Required properties:
-- compatible: Should be "fsl,vf610-ccm"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-Optional properties:
-- clocks: list of clock identifiers which are external input clocks to the
- given clock controller. Please refer the next section to find
- the input clocks for a given controller.
-- clock-names: list of names of clocks which are exteral input clocks to the
- given clock controller.
-
-Input clocks for top clock controller:
- - sxosc (external crystal oscillator 32KHz, recommended)
- - fxosc (external crystal oscillator 24MHz, recommended)
- - audio_ext
- - enet_ext
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
-for the full list of VF610 clock IDs.
-
-Examples:
-
-clks: ccm@4006b000 {
- compatible = "fsl,vf610-ccm";
- reg = <0x4006b000 0x1000>;
- #clock-cells = <1>;
- clocks = <&sxosc>, <&fxosc>;
- clock-names = "sxosc", "fxosc";
-};
-
-uart1: serial@40028000 {
- compatible = "fsl,vf610-uart";
- reg = <0x40028000 0x1000>;
- interrupts = <0 62 0x04>;
- clocks = <&clks VF610_CLK_UART1>;
- clock-names = "ipg";
-};
diff --git a/Documentation/devicetree/bindings/clock/xgene.txt b/Documentation/devicetree/bindings/clock/xgene.txt
deleted file mode 100644
index 8233e771711b..000000000000
--- a/Documentation/devicetree/bindings/clock/xgene.txt
+++ /dev/null
@@ -1,131 +0,0 @@
-Device Tree Clock bindings for APM X-Gene
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be one of the following:
- "apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
- "apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
- "apm,xgene-pmd-clock" - for a X-Gene PMD clock
- "apm,xgene-device-clock" - for a X-Gene device clock
- "apm,xgene-socpll-v2-clock" - for a X-Gene SoC PLL v2 clock
- "apm,xgene-pcppll-v2-clock" - for a X-Gene PCP PLL v2 clock
-
-Required properties for SoC or PCP PLL clocks:
-- reg : shall be the physical PLL register address for the pll clock.
-- clocks : shall be the input parent clock phandle for the clock. This should
- be the reference clock.
-- #clock-cells : shall be set to 1.
-- clock-output-names : shall be the name of the PLL referenced by derive
- clock.
-Optional properties for PLL clocks:
-- clock-names : shall be the name of the PLL. If missing, use the device name.
-
-Required properties for PMD clocks:
-- reg : shall be the physical register address for the pmd clock.
-- clocks : shall be the input parent clock phandle for the clock.
-- #clock-cells : shall be set to 1.
-- clock-output-names : shall be the name of the clock referenced by derive
- clock.
-Optional properties for PLL clocks:
-- clock-names : shall be the name of the clock. If missing, use the device name.
-
-Required properties for device clocks:
-- reg : shall be a list of address and length pairs describing the CSR
- reset and/or the divider. Either may be omitted, but at least
- one must be present.
- - reg-names : shall be a string list describing the reg resource. This
- may include "csr-reg" and/or "div-reg". If this property
- is not present, the reg property is assumed to describe
- only "csr-reg".
-- clocks : shall be the input parent clock phandle for the clock.
-- #clock-cells : shall be set to 1.
-- clock-output-names : shall be the name of the device referenced.
-Optional properties for device clocks:
-- clock-names : shall be the name of the device clock. If missing, use the
- device name.
-- csr-offset : Offset to the CSR reset register from the reset address base.
- Default is 0.
-- csr-mask : CSR reset mask bit. Default is 0xF.
-- enable-offset : Offset to the enable register from the reset address base.
- Default is 0x8.
-- enable-mask : CSR enable mask bit. Default is 0xF.
-- divider-offset : Offset to the divider CSR register from the divider base.
- Default is 0x0.
-- divider-width : Width of the divider register. Default is 0.
-- divider-shift : Bit shift of the divider register. Default is 0.
-
-For example:
-
- pcppll: pcppll@17000100 {
- compatible = "apm,xgene-pcppll-clock";
- #clock-cells = <1>;
- clocks = <&refclk 0>;
- clock-names = "pcppll";
- reg = <0x0 0x17000100 0x0 0x1000>;
- clock-output-names = "pcppll";
- type = <0>;
- };
-
- pmd0clk: pmd0clk@7e200200 {
- compatible = "apm,xgene-pmd-clock";
- #clock-cells = <1>;
- clocks = <&pmdpll 0>;
- reg = <0x0 0x7e200200 0x0 0x10>;
- clock-output-names = "pmd0clk";
- };
-
- socpll: socpll@17000120 {
- compatible = "apm,xgene-socpll-clock";
- #clock-cells = <1>;
- clocks = <&refclk 0>;
- clock-names = "socpll";
- reg = <0x0 0x17000120 0x0 0x1000>;
- clock-output-names = "socpll";
- type = <1>;
- };
-
- qmlclk: qmlclk {
- compatible = "apm,xgene-device-clock";
- #clock-cells = <1>;
- clocks = <&socplldiv2 0>;
- clock-names = "qmlclk";
- reg = <0x0 0x1703C000 0x0 0x1000>;
- reg-name = "csr-reg";
- clock-output-names = "qmlclk";
- };
-
- ethclk: ethclk {
- compatible = "apm,xgene-device-clock";
- #clock-cells = <1>;
- clocks = <&socplldiv2 0>;
- clock-names = "ethclk";
- reg = <0x0 0x17000000 0x0 0x1000>;
- reg-names = "div-reg";
- divider-offset = <0x238>;
- divider-width = <0x9>;
- divider-shift = <0x0>;
- clock-output-names = "ethclk";
- };
-
- apbclk: apbclk {
- compatible = "apm,xgene-device-clock";
- #clock-cells = <1>;
- clocks = <&ahbclk 0>;
- clock-names = "apbclk";
- reg = <0x0 0x1F2AC000 0x0 0x1000
- 0x0 0x1F2AC000 0x0 0x1000>;
- reg-names = "csr-reg", "div-reg";
- csr-offset = <0x0>;
- csr-mask = <0x200>;
- enable-offset = <0x8>;
- enable-mask = <0x200>;
- divider-offset = <0x10>;
- divider-width = <0x2>;
- divider-shift = <0x0>;
- flags = <0x8>;
- clock-output-names = "apbclk";
- };
-
diff --git a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
new file mode 100644
index 000000000000..b497c28e8094
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/xlnx,clocking-wizard.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx clocking wizard
+
+maintainers:
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+
+description:
+ The clocking wizard is a soft ip clocking block of Xilinx versal. It
+ reads required input clock frequencies from the devicetree and acts as clock
+ clock output.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,clocking-wizard
+ - xlnx,clocking-wizard-v5.2
+ - xlnx,clocking-wizard-v6.0
+ - xlnx,versal-clk-wizard
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ items:
+ - description: clock input
+ - description: axi clock
+
+ clock-names:
+ items:
+ - const: clk_in1
+ - const: s_axi_aclk
+
+ xlnx,static-config:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicate whether the core has been configured without support for dynamic
+ runtime reconfguration of the clocking primitive MMCM/PLL.
+
+ xlnx,speed-grade:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3]
+ description:
+ Speed grade of the device. Higher the speed grade faster is the FPGA device.
+
+ xlnx,nr-outputs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 8
+ description:
+ Number of outputs.
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+ - clock-names
+ - xlnx,speed-grade
+ - xlnx,nr-outputs
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@b0000000 {
+ compatible = "xlnx,clocking-wizard";
+ reg = <0xb0000000 0x10000>;
+ #clock-cells = <1>;
+ xlnx,static-config;
+ xlnx,speed-grade = <1>;
+ xlnx,nr-outputs = <6>;
+ clock-names = "clk_in1", "s_axi_aclk";
+ clocks = <&clkc 15>, <&clkc 15>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/clock/xlnx,vcu.yaml b/Documentation/devicetree/bindings/clock/xlnx,vcu.yaml
new file mode 100644
index 000000000000..19dc923e2ee9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/xlnx,vcu.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/xlnx,vcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: LogicoreIP designed compatible with Xilinx ZYNQ family.
+
+maintainers:
+ - Rohit Visavalia <rohit.visavalia@amd.com>
+
+description:
+ LogicoreIP design to provide the isolation between processing system
+ and programmable logic. Also provides the list of register set to configure
+ the frequency.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - xlnx,vcu
+ - xlnx,vcu-logicoreip-1.0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: pll ref clocksource
+ - description: aclk
+
+ clock-names:
+ items:
+ - const: pll_ref
+ - const: aclk
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ fpga {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ xlnx_vcu: vcu@a0040000 {
+ compatible = "xlnx,vcu-logicoreip-1.0";
+ reg = <0x0 0xa0040000 0x0 0x1000>;
+ reset-gpios = <&gpio 78 GPIO_ACTIVE_HIGH>;
+ clocks = <&si570_1>, <&clkc 71>;
+ clock-names = "pll_ref", "aclk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
index 229af98b1d30..bef109d163a8 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,versal-clk.yaml
@@ -7,20 +7,23 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx Versal clock controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
- - Jolly Shah <jolly.shah@xilinx.com>
- - Rajan Vaja <rajan.vaja@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
The clock controller is a hardware block of Xilinx versal clock tree. It
reads required input clock frequencies from the devicetree and acts as clock
provider for all clock consumers of PS clocks.
-select: false
-
properties:
compatible:
- const: xlnx,versal-clk
+ oneOf:
+ - enum:
+ - xlnx,versal-clk
+ - xlnx,zynqmp-clk
+ - items:
+ - enum:
+ - xlnx,versal-net-clk
+ - const: xlnx,versal-clk
"#clock-cells":
const: 1
@@ -28,16 +31,12 @@ properties:
clocks:
description: List of clock specifiers which are external input
clocks to the given clock controller.
- items:
- - description: reference clock
- - description: alternate reference clock
- - description: alternate reference clock for programmable logic
+ minItems: 2
+ maxItems: 8
clock-names:
- items:
- - const: ref
- - const: alt_ref
- - const: pl_alt_ref
+ minItems: 2
+ maxItems: 8
required:
- compatible
@@ -47,6 +46,80 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,versal-clk
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: reference clock
+ - description: alternate reference clock for programmable logic
+
+ clock-names:
+ items:
+ - const: ref
+ - const: pl_alt_ref
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,versal-net-clk
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: reference clock
+ - description: alternate reference clock for programmable logic
+ - description: alternate reference clock
+
+ clock-names:
+ items:
+ - const: ref
+ - const: pl_alt_ref
+ - const: alt_ref
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-clk
+
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ items:
+ - description: PS reference clock
+ - description: reference clock for video system
+ - description: alternative PS reference clock
+ - description: auxiliary reference clock
+ - description: transceiver reference clock
+ - description: (E)MIO clock source (Optional clock)
+ - description: GEM emio clock (Optional clock)
+ - description: Watchdog external clock (Optional clock)
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: pss_ref_clk
+ - const: video_clk
+ - const: pss_alt_ref_clk
+ - const: aux_ref_clk
+ - const: gt_crx_ref_clk
+ - pattern: "^mio_clk[00-77]+.*$"
+ - pattern: "gem[0-3]+_emio_clk.*$"
+ - pattern: "swdt[0-1]+_ext_clk.*$"
+
examples:
- |
firmware {
@@ -56,9 +129,18 @@ examples:
versal_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,versal-clk";
- clocks = <&ref>, <&alt_ref>, <&pl_alt_ref>;
- clock-names = "ref", "alt_ref", "pl_alt_ref";
+ clocks = <&ref>, <&pl_alt_ref>;
+ clock-names = "ref", "pl_alt_ref";
};
};
};
+
+ clock-controller {
+ #clock-cells = <1>;
+ compatible = "xlnx,zynqmp-clk";
+ clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>,
+ <&aux_ref_clk>, <&gt_crx_ref_clk>;
+ clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk",
+ "aux_ref_clk", "gt_crx_ref_clk";
+ };
...
diff --git a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt b/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
deleted file mode 100644
index 391ee1a60bed..000000000000
--- a/Documentation/devicetree/bindings/clock/xlnx,zynqmp-clk.txt
+++ /dev/null
@@ -1,63 +0,0 @@
---------------------------------------------------------------------------
-Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
-Zynq MPSoC firmware interface
---------------------------------------------------------------------------
-The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
-tree. It reads required input clock frequencies from the devicetree and acts
-as clock provider for all clock consumers of PS clocks.
-
-See clock_bindings.txt for more information on the generic clock bindings.
-
-Required properties:
- - #clock-cells: Must be 1
- - compatible: Must contain: "xlnx,zynqmp-clk"
- - clocks: List of clock specifiers which are external input
- clocks to the given clock controller. Please refer
- the next section to find the input clocks for a
- given controller.
- - clock-names: List of clock names which are exteral input clocks
- to the given clock controller. Please refer to the
- clock bindings for more details.
-
-Input clocks for zynqmp Ultrascale+ clock controller:
-
-The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
-inputs. These required clock inputs are:
- - pss_ref_clk (PS reference clock)
- - video_clk (reference clock for video system )
- - pss_alt_ref_clk (alternative PS reference clock)
- - aux_ref_clk
- - gt_crx_ref_clk (transceiver reference clock)
-
-The following strings are optional parameters to the 'clock-names' property in
-order to provide an optional (E)MIO clock source:
- - swdt0_ext_clk
- - swdt1_ext_clk
- - gem0_emio_clk
- - gem1_emio_clk
- - gem2_emio_clk
- - gem3_emio_clk
- - mio_clk_XX # with XX = 00..77
- - mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51
-
-
-Output clocks are registered based on clock information received
-from firmware. Output clocks indexes are mentioned in
-include/dt-bindings/clock/xlnx-zynqmp-clk.h.
-
--------
-Example
--------
-
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- compatible = "xlnx,zynqmp-firmware";
- method = "smc";
- zynqmp_clk: clock-controller {
- #clock-cells = <1>;
- compatible = "xlnx,zynqmp-clk";
- clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <&gt_crx_ref_clk>;
- clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml
new file mode 100644
index 000000000000..a16ae2762d16
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/connector/gocontroll,moduline-module-slot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GOcontroll Moduline Module slot
+
+maintainers:
+ - Maud Spierings <maudspierings@gocontroll.com>
+
+description:
+ The GOcontroll Moduline module slot represents a connector that fullfills the
+ Moduline slot specification, and can thus house any IO module that is also
+ built to this spec.
+
+properties:
+ compatible:
+ const: gocontroll,moduline-module-slot
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: indicates readiness, high means busy.
+ maxItems: 1
+ reset-gpios:
+ description: resets the module, active low.
+ maxItems: 1
+ sync-gpios:
+ description: sync line between all module slots.
+ maxItems: 1
+
+ vdd-supply:
+ description: low power 3v3 supply generally for the microcontroller.
+ vddp-supply:
+ description: medium power 5v0 supply for on module low power peripherals.
+ vddhpp-supply:
+ description: high power 6v-8v supply for on module high power peripherals.
+ power-supply:
+ description: high power 6v-30v supply for high power module circuits.
+
+ i2c-bus:
+ description: i2c bus shared between module slots and the SoC
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ slot-number:
+ description:
+ The number of the module slot representing the location of on the pcb.
+ This enables access to the modules based on slot location.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ spi-max-frequency: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - interrupts
+ - sync-gpios
+ - i2c-bus
+ - slot-number
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ reg = <0>;
+ compatible = "gocontroll,moduline-module-slot";
+ reset-gpios = <&gpio5 10 GPIO_ACTIVE_LOW>;
+ sync-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&reg_3v3_per>;
+ vddp-supply = <&reg_5v0>;
+ vddhpp-supply = <&reg_6v4>;
+ i2c-bus = <&i2c2>;
+ slot-number = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index ae515651fc6b..11e40d225b9f 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -30,6 +30,9 @@ properties:
- const: samsung,usb-connector-11pin
- const: usb-b-connector
+ reg:
+ maxItems: 1
+
label:
description: Symbolic name for the connector.
@@ -63,7 +66,6 @@ properties:
Particularly, if use an output GPIO to control a VBUS regulator, should
model it as a regulator. See bindings/regulator/fixed-regulator.yaml
- # The following are optional properties for "usb-c-connector".
power-role:
description: Determines the power role that the Type C connector will
support. "dual" refers to Dual Role Port (DRP).
@@ -116,30 +118,6 @@ properties:
# The following are optional properties for "usb-c-connector" with power
# delivery support.
- source-pdos:
- description: An array of u32 with each entry providing supported power
- source data object(PDO), the detailed bit definitions of PDO can be found
- in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
- Source_Capabilities Message, the order of each entry(PDO) should follow
- the PD spec chapter 6.4.1. Required for power source and power dual role.
- User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO()
- defined in dt-bindings/usb/pd.h.
- minItems: 1
- maxItems: 7
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
- sink-pdos:
- description: An array of u32 with each entry providing supported power sink
- data object(PDO), the detailed bit definitions of PDO can be found in
- "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
- Sink Capabilities Message, the order of each entry(PDO) should follow the
- PD spec chapter 6.4.1. Required for power sink and power dual role. User
- can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined
- in dt-bindings/usb/pd.h.
- minItems: 1
- maxItems: 7
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
sink-vdos:
description: An array of u32 with each entry, a Vendor Defined Message Object (VDO),
providing additional information corresponding to the product, the detailed bit
@@ -163,10 +141,50 @@ properties:
maxItems: 6
$ref: /schemas/types.yaml#/definitions/uint32-array
- op-sink-microwatt:
- description: Sink required operating power in microwatt, if source can't
- offer the power, Capability Mismatch is set. Required for power sink and
- power dual role.
+ accessory-mode-audio:
+ type: boolean
+ description: Whether the device supports Audio Adapter Accessory Mode. This
+ is only necessary if there are no other means to discover supported
+ alternative modes (e.g. through the UCSI firmware interface).
+
+ accessory-mode-debug:
+ type: boolean
+ description: Whether the device supports Debug Accessory Mode. This
+ is only necessary if there are no other means to discover supported
+ alternative modes (e.g. through the UCSI firmware interface).
+
+ altmodes:
+ type: object
+ description: List of Alternative Modes supported by the schematics on the
+ particular device. This is only necessary if there are no other means to
+ discover supported alternative modes (e.g. through the UCSI firmware
+ interface).
+
+ additionalProperties: false
+
+ patternProperties:
+ "^(displayport)$":
+ type: object
+ description:
+ A single USB-C Alternative Mode as supported by the USB-C connector logic.
+
+ additionalProperties: false
+
+ properties:
+ svid:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description: Unique value assigned by USB-IF to the Vendor / AltMode.
+ enum: [ 0xff01 ]
+ vdo:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: VDO returned by Discover Modes USB PD command.
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OF graph bindings modeling a data bus to the connector, e.g.
+ there is a single High Speed (HS) port present in this connector. If there
+ is more than one bus (several port, with 'reg' property), they can be grouped
+ under 'ports'.
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -217,18 +235,114 @@ properties:
state as defined in 7.4.2 Sink Electrical Parameters of USB Power Delivery Specification
Revision 3.0, Version 1.2. When the property is set, the port requests pSnkStby(2.5W -
5V@500mA) upon entering SNK_DISCOVERY(instead of 3A or the 1.5A, Rp current advertised, during
- SNK_DISCOVERY) and the actual currrent limit after reception of PS_Ready for PD link or during
+ SNK_DISCOVERY) and the actual current limit after reception of PS_Ready for PD link or during
SNK_READY for non-pd link.
type: boolean
+ capabilities:
+ description: A child node to contain all the selectable USB Power Delivery capabilities.
+ type: object
+
+ patternProperties:
+ "^caps-[0-9]+$":
+ description: Child nodes under "capabilities" node. Each node contains a selectable USB
+ Power Delivery capability.
+ type: object
+ $ref: "#/$defs/capabilities"
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+ sink-wait-cap-time-ms:
+ description: Represents the max time in ms that USB Type-C port (in sink
+ role) should wait for the port partner (source role) to send source caps.
+ SinkWaitCap timer starts when port in sink role attaches to the source.
+ This timer will stop when sink receives PD source cap advertisement before
+ timeout in which case it'll move to capability negotiation stage. A
+ timeout leads to a hard reset message by the port.
+ minimum: 310
+ maximum: 620
+ default: 310
+
+ ps-source-off-time-ms:
+ description: Represents the max time in ms that a DRP in source role should
+ take to turn off power after the PsSourceOff timer starts. PsSourceOff
+ timer starts when a sink's PHY layer receives EOP of the GoodCRC message
+ (corresponding to an Accept message sent in response to a PR_Swap or a
+ FR_Swap request). This timer stops when last bit of GoodCRC EOP
+ corresponding to the received PS_RDY message is transmitted by the PHY
+ layer. A timeout shall lead to error recovery in the type-c port.
+ minimum: 750
+ maximum: 920
+ default: 920
+
+ cc-debounce-time-ms:
+ description: Represents the max time in ms that a port shall wait to
+ determine if it's attached to a partner.
+ minimum: 100
+ maximum: 200
+ default: 200
+
+ sink-bc12-completion-time-ms:
+ description: Represents the max time in ms that a port in sink role takes
+ to complete Battery Charger (BC1.2) Detection. BC1.2 detection is a
+ hardware mechanism, which in some TCPC implementations, can run in
+ parallel once the Type-C connection state machine reaches the "potential
+ connect as sink" state. In TCPCs where this causes delays to respond to
+ the incoming PD messages, sink-bc12-completion-time-ms is used to delay
+ PD negotiation till BC1.2 detection completes.
+ default: 0
+
+ pd-revision:
+ description: Specifies the maximum USB PD revision and version supported by
+ the connector. This property is specified in the following order;
+ <revision_major, revision_minor, version_major, version_minor>.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ maxItems: 4
+
dependencies:
- sink-vdos-v1: [ 'sink-vdos' ]
- sink-vdos: [ 'sink-vdos-v1' ]
+ sink-vdos-v1: [ sink-vdos ]
+ sink-vdos: [ sink-vdos-v1 ]
required:
- compatible
+$defs:
+ capabilities:
+ type: object
+
+ properties:
+ source-pdos:
+ description: An array of u32 with each entry providing supported power
+ source data object(PDO), the detailed bit definitions of PDO can be found
+ in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
+ Source_Capabilities Message, the order of each entry(PDO) should follow
+ the PD spec chapter 6.4.1. Required for power source and power dual role.
+ User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO()
+ defined in dt-bindings/usb/pd.h.
+ minItems: 1
+ maxItems: 7
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ sink-pdos:
+ description: An array of u32 with each entry providing supported power sink
+ data object(PDO), the detailed bit definitions of PDO can be found in
+ "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
+ Sink Capabilities Message, the order of each entry(PDO) should follow the
+ PD spec chapter 6.4.1. Required for power sink and power dual role. User
+ can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined
+ in dt-bindings/usb/pd.h.
+ minItems: 1
+ maxItems: 7
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ op-sink-microwatt:
+ description: Sink required operating power in microwatt, if source can't
+ offer the power, Capability Mismatch is set. Required for power sink and
+ power dual role.
+
allOf:
+ - $ref: "#/$defs/capabilities"
- if:
properties:
compatible:
@@ -257,7 +371,7 @@ anyOf:
- typec-power-opmode
- new-source-frs-typec-current
-additionalProperties: true
+unevaluatedProperties: false
examples:
# Micro-USB connector with HS lines routed via controller (MUIC).
@@ -279,6 +393,13 @@ examples:
compatible = "usb-c-connector";
label = "USB-C";
+ altmodes {
+ displayport {
+ svid = /bits/ 16 <0xff01>;
+ vdo = <0x00001c46>;
+ };
+ };
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -306,7 +427,7 @@ examples:
};
# USB-C connector attached to a typec port controller(ptn5110), which has
- # power delivery support and enables drp.
+ # power delivery support, explicitly defines time properties and enables drp.
- |
#include <dt-bindings/usb/pd.h>
typec: ptn5110 {
@@ -319,6 +440,23 @@ examples:
sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
PDO_VAR(5000, 12000, 2000)>;
op-sink-microwatt = <10000000>;
+ sink-wait-cap-time-ms = <465>;
+ ps-source-off-time-ms = <835>;
+ cc-debounce-time-ms = <101>;
+ sink-bc12-completion-time-ms = <500>;
+ };
+ };
+
+ # USB-C connector attached to SoC with a single High-Speed controller
+ - |
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+
+ port {
+ high_speed_ep: endpoint {
+ remote-endpoint = <&usb_hs_ep>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/counter/fsl,ftm-quaddec.yaml b/Documentation/devicetree/bindings/counter/fsl,ftm-quaddec.yaml
new file mode 100644
index 000000000000..384ca63b64d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/counter/fsl,ftm-quaddec.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/counter/fsl,ftm-quaddec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FlexTimer Quadrature decoder counter
+
+description:
+ Exposes a simple counter for the quadrature decoder mode.
+
+maintainers:
+ - Frank Li <Frank.li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,ftm-quaddec
+
+ reg:
+ maxItems: 1
+
+ big-endian: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ counter@29d0000 {
+ compatible = "fsl,ftm-quaddec";
+ reg = <0x29d0000 0x10000>;
+ big-endian;
+ };
diff --git a/Documentation/devicetree/bindings/counter/ftm-quaddec.txt b/Documentation/devicetree/bindings/counter/ftm-quaddec.txt
deleted file mode 100644
index 4d18cd722074..000000000000
--- a/Documentation/devicetree/bindings/counter/ftm-quaddec.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-FlexTimer Quadrature decoder counter
-
-This driver exposes a simple counter for the quadrature decoder mode.
-
-Required properties:
-- compatible: Must be "fsl,ftm-quaddec".
-- reg: Must be set to the memory region of the flextimer.
-
-Optional property:
-- big-endian: Access the device registers in big-endian mode.
-
-Example:
- counter0: counter@29d0000 {
- compatible = "fsl,ftm-quaddec";
- reg = <0x0 0x29d0000 0x0 0x10000>;
- big-endian;
- status = "disabled";
- };
diff --git a/Documentation/devicetree/bindings/counter/ti,am62-ecap-capture.yaml b/Documentation/devicetree/bindings/counter/ti,am62-ecap-capture.yaml
new file mode 100644
index 000000000000..4e0b2d2b303e
--- /dev/null
+++ b/Documentation/devicetree/bindings/counter/ti,am62-ecap-capture.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/counter/ti,am62-ecap-capture.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments Enhanced Capture (eCAP) Module
+
+maintainers:
+ - Julien Panis <jpanis@baylibre.com>
+
+description: |
+ The eCAP module resources can be used to capture timestamps
+ on input signal events (falling/rising edges).
+
+properties:
+ compatible:
+ const: ti,am62-ecap-capture
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: fck
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ capture@23100000 { /* eCAP in capture mode on am62x */
+ compatible = "ti,am62-ecap-capture";
+ reg = <0x00 0x23100000 0x00 0x100>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_EDGE_RISING>;
+ power-domains = <&k3_pds 51 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 51 0>;
+ clock-names = "fck";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/counter/ti-eqep.yaml b/Documentation/devicetree/bindings/counter/ti-eqep.yaml
index 85f1ff83afe7..c882ab5fcf1f 100644
--- a/Documentation/devicetree/bindings/counter/ti-eqep.yaml
+++ b/Documentation/devicetree/bindings/counter/ti-eqep.yaml
@@ -11,7 +11,9 @@ maintainers:
properties:
compatible:
- const: ti,am3352-eqep
+ enum:
+ - ti,am3352-eqep
+ - ti,am62-eqep
reg:
maxItems: 1
@@ -21,19 +23,35 @@ properties:
maxItems: 1
clocks:
- description: The clock that determines the SYSCLKOUT rate for the eQEP
- peripheral.
+ description: The functional and interface clock that determines the clock
+ rate for the eQEP peripheral.
maxItems: 1
clock-names:
const: sysclkout
+ power-domains:
+ maxItems: 1
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,am62-eqep
+ then:
+ properties:
+ clock-names: false
+
+ required:
+ - power-domains
+
required:
- compatible
- reg
- interrupts
- clocks
- - clock-names
additionalProperties: false
@@ -43,7 +61,6 @@ examples:
compatible = "ti,am3352-eqep";
reg = <0x180 0x80>;
clocks = <&l4ls_gclk>;
- clock-names = "sysclkout";
interrupts = <79>;
};
diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt b/Documentation/devicetree/bindings/cpu/cpu-capacity.txt
index cc5e190390b7..f28e1adad428 100644
--- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt
+++ b/Documentation/devicetree/bindings/cpu/cpu-capacity.txt
@@ -1,12 +1,12 @@
==========================================
-ARM CPUs capacity bindings
+CPU capacity bindings
==========================================
==========================================
1 - Introduction
==========================================
-ARM systems may be configured to have cpus with different power/performance
+Some systems may be configured to have cpus with different power/performance
characteristics within the same chip. In this case, additional information has
to be made available to the kernel for it to be aware of such differences and
take decisions accordingly.
diff --git a/Documentation/devicetree/bindings/cpu/cpu-topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt
deleted file mode 100644
index 9bd530a35d14..000000000000
--- a/Documentation/devicetree/bindings/cpu/cpu-topology.txt
+++ /dev/null
@@ -1,553 +0,0 @@
-===========================================
-CPU topology binding description
-===========================================
-
-===========================================
-1 - Introduction
-===========================================
-
-In a SMP system, the hierarchy of CPUs is defined through three entities that
-are used to describe the layout of physical CPUs in the system:
-
-- socket
-- cluster
-- core
-- thread
-
-The bottom hierarchy level sits at core or thread level depending on whether
-symmetric multi-threading (SMT) is supported or not.
-
-For instance in a system where CPUs support SMT, "cpu" nodes represent all
-threads existing in the system and map to the hierarchy level "thread" above.
-In systems where SMT is not supported "cpu" nodes represent all cores present
-in the system and map to the hierarchy level "core" above.
-
-CPU topology bindings allow one to associate cpu nodes with hierarchical groups
-corresponding to the system hierarchy; syntactically they are defined as device
-tree nodes.
-
-Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be
-used for any other architecture as well.
-
-The cpu nodes, as per bindings defined in [4], represent the devices that
-correspond to physical CPUs and are to be mapped to the hierarchy levels.
-
-A topology description containing phandles to cpu nodes that are not compliant
-with bindings standardized in [4] is therefore considered invalid.
-
-===========================================
-2 - cpu-map node
-===========================================
-
-The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct
-child of the cpus node and provides a container where the actual topology
-nodes are listed.
-
-- cpu-map node
-
- Usage: Optional - On SMP systems provide CPUs topology to the OS.
- Uniprocessor systems do not require a topology
- description and therefore should not define a
- cpu-map node.
-
- Description: The cpu-map node is just a container node where its
- subnodes describe the CPU topology.
-
- Node name must be "cpu-map".
-
- The cpu-map node's parent node must be the cpus node.
-
- The cpu-map node's child nodes can be:
-
- - one or more cluster nodes or
- - one or more socket nodes in a multi-socket system
-
- Any other configuration is considered invalid.
-
-The cpu-map node can only contain 4 types of child nodes:
-
-- socket node
-- cluster node
-- core node
-- thread node
-
-whose bindings are described in paragraph 3.
-
-The nodes describing the CPU topology (socket/cluster/core/thread) can
-only be defined within the cpu-map node and every core/thread in the
-system must be defined within the topology. Any other configuration is
-invalid and therefore must be ignored.
-
-===========================================
-2.1 - cpu-map child nodes naming convention
-===========================================
-
-cpu-map child nodes must follow a naming convention where the node name
-must be "socketN", "clusterN", "coreN", "threadN" depending on the node type
-(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes
-which are siblings within a single common parent node must be given a unique and
-sequential N value, starting from 0).
-cpu-map child nodes which do not share a common parent node can have the same
-name (ie same number N as other cpu-map child nodes at different device tree
-levels) since name uniqueness will be guaranteed by the device tree hierarchy.
-
-===========================================
-3 - socket/cluster/core/thread node bindings
-===========================================
-
-Bindings for socket/cluster/cpu/thread nodes are defined as follows:
-
-- socket node
-
- Description: must be declared within a cpu-map node, one node
- per physical socket in the system. A system can
- contain single or multiple physical socket.
- The association of sockets and NUMA nodes is beyond
- the scope of this bindings, please refer [2] for
- NUMA bindings.
-
- This node is optional for a single socket system.
-
- The socket node name must be "socketN" as described in 2.1 above.
- A socket node can not be a leaf node.
-
- A socket node's child nodes must be one or more cluster nodes.
-
- Any other configuration is considered invalid.
-
-- cluster node
-
- Description: must be declared within a cpu-map node, one node
- per cluster. A system can contain several layers of
- clustering within a single physical socket and cluster
- nodes can be contained in parent cluster nodes.
-
- The cluster node name must be "clusterN" as described in 2.1 above.
- A cluster node can not be a leaf node.
-
- A cluster node's child nodes must be:
-
- - one or more cluster nodes; or
- - one or more core nodes
-
- Any other configuration is considered invalid.
-
-- core node
-
- Description: must be declared in a cluster node, one node per core in
- the cluster. If the system does not support SMT, core
- nodes are leaf nodes, otherwise they become containers of
- thread nodes.
-
- The core node name must be "coreN" as described in 2.1 above.
-
- A core node must be a leaf node if SMT is not supported.
-
- Properties for core nodes that are leaf nodes:
-
- - cpu
- Usage: required
- Value type: <phandle>
- Definition: a phandle to the cpu node that corresponds to the
- core node.
-
- If a core node is not a leaf node (CPUs supporting SMT) a core node's
- child nodes can be:
-
- - one or more thread nodes
-
- Any other configuration is considered invalid.
-
-- thread node
-
- Description: must be declared in a core node, one node per thread
- in the core if the system supports SMT. Thread nodes are
- always leaf nodes in the device tree.
-
- The thread node name must be "threadN" as described in 2.1 above.
-
- A thread node must be a leaf node.
-
- A thread node must contain the following property:
-
- - cpu
- Usage: required
- Value type: <phandle>
- Definition: a phandle to the cpu node that corresponds to
- the thread node.
-
-===========================================
-4 - Example dts
-===========================================
-
-Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters in a single
-physical socket):
-
-cpus {
- #size-cells = <0>;
- #address-cells = <2>;
-
- cpu-map {
- socket0 {
- cluster0 {
- cluster0 {
- core0 {
- thread0 {
- cpu = <&CPU0>;
- };
- thread1 {
- cpu = <&CPU1>;
- };
- };
-
- core1 {
- thread0 {
- cpu = <&CPU2>;
- };
- thread1 {
- cpu = <&CPU3>;
- };
- };
- };
-
- cluster1 {
- core0 {
- thread0 {
- cpu = <&CPU4>;
- };
- thread1 {
- cpu = <&CPU5>;
- };
- };
-
- core1 {
- thread0 {
- cpu = <&CPU6>;
- };
- thread1 {
- cpu = <&CPU7>;
- };
- };
- };
- };
-
- cluster1 {
- cluster0 {
- core0 {
- thread0 {
- cpu = <&CPU8>;
- };
- thread1 {
- cpu = <&CPU9>;
- };
- };
- core1 {
- thread0 {
- cpu = <&CPU10>;
- };
- thread1 {
- cpu = <&CPU11>;
- };
- };
- };
-
- cluster1 {
- core0 {
- thread0 {
- cpu = <&CPU12>;
- };
- thread1 {
- cpu = <&CPU13>;
- };
- };
- core1 {
- thread0 {
- cpu = <&CPU14>;
- };
- thread1 {
- cpu = <&CPU15>;
- };
- };
- };
- };
- };
- };
-
- CPU0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x0>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU1: cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x1>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU2: cpu@100 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x100>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU3: cpu@101 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x101>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU4: cpu@10000 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x10000>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU5: cpu@10001 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x10001>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU6: cpu@10100 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x10100>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU7: cpu@10101 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x0 0x10101>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU8: cpu@100000000 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x0>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU9: cpu@100000001 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x1>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU10: cpu@100000100 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x100>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU11: cpu@100000101 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x101>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU12: cpu@100010000 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x10000>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU13: cpu@100010001 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x10001>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU14: cpu@100010100 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x10100>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-
- CPU15: cpu@100010101 {
- device_type = "cpu";
- compatible = "arm,cortex-a57";
- reg = <0x1 0x10101>;
- enable-method = "spin-table";
- cpu-release-addr = <0 0x20000000>;
- };
-};
-
-Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
-
-cpus {
- #size-cells = <0>;
- #address-cells = <1>;
-
- cpu-map {
- cluster0 {
- core0 {
- cpu = <&CPU0>;
- };
- core1 {
- cpu = <&CPU1>;
- };
- core2 {
- cpu = <&CPU2>;
- };
- core3 {
- cpu = <&CPU3>;
- };
- };
-
- cluster1 {
- core0 {
- cpu = <&CPU4>;
- };
- core1 {
- cpu = <&CPU5>;
- };
- core2 {
- cpu = <&CPU6>;
- };
- core3 {
- cpu = <&CPU7>;
- };
- };
- };
-
- CPU0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0x0>;
- };
-
- CPU1: cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0x1>;
- };
-
- CPU2: cpu@2 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0x2>;
- };
-
- CPU3: cpu@3 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0x3>;
- };
-
- CPU4: cpu@100 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x100>;
- };
-
- CPU5: cpu@101 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x101>;
- };
-
- CPU6: cpu@102 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x102>;
- };
-
- CPU7: cpu@103 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x103>;
- };
-};
-
-Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
-
-{
- #address-cells = <2>;
- #size-cells = <2>;
- compatible = "sifive,fu540g", "sifive,fu500";
- model = "sifive,hifive-unleashed-a00";
-
- ...
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
- cpu-map {
- socket0 {
- cluster0 {
- core0 {
- cpu = <&CPU1>;
- };
- core1 {
- cpu = <&CPU2>;
- };
- core2 {
- cpu0 = <&CPU2>;
- };
- core3 {
- cpu0 = <&CPU3>;
- };
- };
- };
- };
-
- CPU1: cpu@1 {
- device_type = "cpu";
- compatible = "sifive,rocket0", "riscv";
- reg = <0x1>;
- }
-
- CPU2: cpu@2 {
- device_type = "cpu";
- compatible = "sifive,rocket0", "riscv";
- reg = <0x2>;
- }
- CPU3: cpu@3 {
- device_type = "cpu";
- compatible = "sifive,rocket0", "riscv";
- reg = <0x3>;
- }
- CPU4: cpu@4 {
- device_type = "cpu";
- compatible = "sifive,rocket0", "riscv";
- reg = <0x4>;
- }
- }
-};
-===============================================================================
-[1] ARM Linux kernel documentation
- Documentation/devicetree/bindings/arm/cpus.yaml
-[2] Devicetree NUMA binding description
- Documentation/devicetree/bindings/numa.txt
-[3] RISC-V Linux kernel documentation
- Documentation/devicetree/bindings/riscv/cpus.yaml
-[4] https://www.devicetree.org/specifications/
diff --git a/Documentation/devicetree/bindings/cpu/idle-states.yaml b/Documentation/devicetree/bindings/cpu/idle-states.yaml
index fa4d4142ac93..385b0a511652 100644
--- a/Documentation/devicetree/bindings/cpu/idle-states.yaml
+++ b/Documentation/devicetree/bindings/cpu/idle-states.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/cpu/idle-states.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Idle states binding description
+title: Idle states
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
@@ -243,7 +243,64 @@ description: |+
just supports idle_standby, an idle-states node is not required.
===========================================
- 6 - References
+ 6 - Qualcomm specific STATES
+ ===========================================
+
+ Idle states have different enter/exit latency and residency values.
+ The idle states supported by the QCOM SoC are defined as -
+
+ * Standby
+ * Retention
+ * Standalone Power Collapse (Standalone PC or SPC)
+ * Power Collapse (PC)
+
+ Standby: Standby does a little more in addition to architectural clock gating.
+ When the WFI instruction is executed the ARM core would gate its internal
+ clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
+ trigger to execute the SPM state machine. The SPM state machine waits for the
+ interrupt to trigger the core back in to active. This triggers the cache
+ hierarchy to enter standby states, when all cpus are idle. An interrupt brings
+ the SPM state machine out of its wait, the next step is to ensure that the
+ cache hierarchy is also out of standby, and then the cpu is allowed to resume
+ execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
+ driver and is not defined in the DT. The SPM state machine should be
+ configured to execute this state by default and after executing every other
+ state below.
+
+ Retention: Retention is a low power state where the core is clock gated and
+ the memory and the registers associated with the core are retained. The
+ voltage may be reduced to the minimum value needed to keep the processor
+ registers active. The SPM should be configured to execute the retention
+ sequence and would wait for interrupt, before restoring the cpu to execution
+ state. Retention may have a slightly higher latency than Standby.
+
+ Standalone PC: A cpu can power down and warmboot if there is a sufficient time
+ between the time it enters idle and the next known wake up. SPC mode is used
+ to indicate a core entering a power down state without consulting any other
+ cpu or the system resources. This helps save power only on that core. The SPM
+ sequence for this idle state is programmed to power down the supply to the
+ core, wait for the interrupt, restore power to the core, and ensure the
+ system state including cache hierarchy is ready before allowing core to
+ resume. Applying power and resetting the core causes the core to warmboot
+ back into Elevation Level (EL) which trampolines the control back to the
+ kernel. Entering a power down state for the cpu, needs to be done by trapping
+ into a EL. Failing to do so, would result in a crash enforced by the warm boot
+ code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
+ be flushed in s/w, before powering down the core.
+
+ Power Collapse: This state is similar to the SPC mode, but distinguishes
+ itself in that the cpu acknowledges and permits the SoC to enter deeper sleep
+ modes. In a hierarchical power domain SoC, this means L2 and other caches can
+ be flushed, system bus, clocks - lowered, and SoC main XO clock gated and
+ voltages reduced, provided all cpus enter this state. Since the span of low
+ power modes possible at this state is vast, the exit latency and the residency
+ of this low power mode would be considered high even though at a cpu level,
+ this essentially is cpu power down. The SPM in this state also may handshake
+ with the Resource power manager (RPM) processor in the SoC to indicate a
+ complete application processor subsystem shut down.
+
+ ===========================================
+ 7 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
@@ -259,7 +316,7 @@ description: |+
http://infocenter.arm.com/help/index.jsp
[5] ARM Linux Kernel documentation - Booting AArch64 Linux
- Documentation/arm64/booting.rst
+ Documentation/arch/arm64/booting.rst
[6] RISC-V Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -301,9 +358,16 @@ patternProperties:
properties:
compatible:
- enum:
- - arm,idle-state
- - riscv,idle-state
+ oneOf:
+ - items:
+ - enum:
+ - qcom,idle-state-ret
+ - qcom,idle-state-spc
+ - qcom,idle-state-pc
+ - const: arm,idle-state
+ - enum:
+ - arm,idle-state
+ - riscv,idle-state
arm,psci-suspend-param:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -321,7 +385,7 @@ patternProperties:
This property is required in idle state nodes of device tree meant
for RISC-V systems. For more details on the suspend_type parameter
- refer the SBI specifiation v0.3 (or higher) [7].
+ refer the SBI specification v0.3 (or higher) [7].
local-timer-stop:
description:
@@ -852,4 +916,13 @@ examples:
};
};
+ // Example 4 - Qualcomm SPC
+ idle-states {
+ cpu_spc: cpu-spc {
+ compatible = "qcom,idle-state-spc", "arm,idle-state";
+ entry-latency-us = <150>;
+ exit-latency-us = <200>;
+ min-residency-us = <2000>;
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml
new file mode 100644
index 000000000000..7d4510b3219c
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/airoha,en7581-cpufreq.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/airoha,en7581-cpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 CPUFreq
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |
+ On newer Airoha SoC, CPU Frequency is scaled indirectly with SMC commands
+ to ATF.
+
+ A virtual clock is exposed. This virtual clock is a get-only clock and
+ is used to expose the current global CPU clock. The frequency info comes
+ by the output of the SMC command that reports the clock in MHz.
+
+ The SMC sets the CPU clock by providing an index, this is modelled as
+ performance states in a power domain.
+
+ CPUs can't be individually scaled as the CPU frequency is shared across
+ all CPUs and is global.
+
+properties:
+ compatible:
+ const: airoha,en7581-cpufreq
+
+ '#clock-cells':
+ const: 0
+
+ '#power-domain-cells':
+ const: 0
+
+ operating-points-v2: true
+
+required:
+ - compatible
+ - '#clock-cells'
+ - '#power-domain-cells'
+ - operating-points-v2
+
+additionalProperties: false
+
+examples:
+ - |
+ performance-domain {
+ compatible = "airoha,en7581-cpufreq";
+
+ operating-points-v2 = <&cpu_smcc_opp_table>;
+
+ #power-domain-cells = <0>;
+ #clock-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml
new file mode 100644
index 000000000000..b51913a81791
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SoC cluster cpufreq device
+
+maintainers:
+ - Hector Martin <marcan@marcan.st>
+
+description: |
+ Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of
+ the cluster management register block. This binding uses the standard
+ operating-points-v2 table to define the CPU performance states, with the
+ opp-level property specifying the hardware p-state index for that level.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - apple,t8103-cluster-cpufreq
+ - apple,t8112-cluster-cpufreq
+ - const: apple,cluster-cpufreq
+ - items:
+ - enum:
+ - apple,s8000-cluster-cpufreq
+ - apple,t8010-cluster-cpufreq
+ - apple,t8015-cluster-cpufreq
+ - apple,t6000-cluster-cpufreq
+ - const: apple,t8103-cluster-cpufreq
+ - const: apple,cluster-cpufreq
+ - items:
+ - const: apple,t7000-cluster-cpufreq
+ - const: apple,s5l8960x-cluster-cpufreq
+ - const: apple,s5l8960x-cluster-cpufreq
+ - items:
+ - const: apple,t6020-cluster-cpufreq
+ - const: apple,t8112-cluster-cpufreq
+
+ reg:
+ maxItems: 1
+
+ '#performance-domain-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - '#performance-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ // This example shows a single CPU per domain and 2 domains,
+ // with two p-states per domain.
+ // Shipping hardware has 2-4 CPUs per domain and 2-6 domains.
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "apple,icestorm";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ operating-points-v2 = <&ecluster_opp>;
+ performance-domains = <&cpufreq_e>;
+ };
+
+ cpu@10100 {
+ compatible = "apple,firestorm";
+ device_type = "cpu";
+ reg = <0x0 0x10100>;
+ operating-points-v2 = <&pcluster_opp>;
+ performance-domains = <&cpufreq_p>;
+ };
+ };
+
+ ecluster_opp: opp-table-0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp01 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-level = <1>;
+ clock-latency-ns = <7500>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <972000000>;
+ opp-level = <2>;
+ clock-latency-ns = <22000>;
+ };
+ };
+
+ pcluster_opp: opp-table-1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp01 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-level = <1>;
+ clock-latency-ns = <8000>;
+ };
+ opp02 {
+ opp-hz = /bits/ 64 <828000000>;
+ opp-level = <2>;
+ clock-latency-ns = <19000>;
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpufreq_e: performance-controller@210e20000 {
+ compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq";
+ reg = <0x2 0x10e20000 0 0x1000>;
+ #performance-domain-cells = <0>;
+ };
+
+ cpufreq_p: performance-controller@211e20000 {
+ compatible = "apple,t8103-cluster-cpufreq", "apple,cluster-cpufreq";
+ reg = <0x2 0x11e20000 0 0x1000>;
+ #performance-domain-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
deleted file mode 100644
index 1d7e49167666..000000000000
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Generic cpufreq driver
-
-It is a generic DT based cpufreq driver for frequency management. It supports
-both uniprocessor (UP) and symmetric multiprocessor (SMP) systems which share
-clock and voltage across all CPUs.
-
-Both required and optional properties listed below must be defined
-under node /cpus/cpu@0.
-
-Required properties:
-- None
-
-Optional properties:
-- operating-points: Refer to Documentation/devicetree/bindings/opp/opp-v1.yaml for
- details. OPPs *must* be supplied either via DT, i.e. this property, or
- populated at runtime.
-- clock-latency: Specify the possible maximum transition latency for clock,
- in unit of nanoseconds.
-- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
-- #cooling-cells:
- Please refer to
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
-
-Examples:
-
-cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- compatible = "arm,cortex-a9";
- reg = <0>;
- next-level-cache = <&L2>;
- operating-points = <
- /* kHz uV */
- 792000 1100000
- 396000 950000
- 198000 850000
- >;
- clock-latency = <61036>; /* two CLK32 periods */
- #cooling-cells = <2>;
- };
-
- cpu@1 {
- compatible = "arm,cortex-a9";
- reg = <1>;
- next-level-cache = <&L2>;
- };
-
- cpu@2 {
- compatible = "arm,cortex-a9";
- reg = <2>;
- next-level-cache = <&L2>;
- };
-
- cpu@3 {
- compatible = "arm,cortex-a9";
- reg = <3>;
- next-level-cache = <&L2>;
- };
-};
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
index 9cd42a64b13e..d0aecde2b89b 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek's CPUFREQ Bindings
+title: MediaTek's CPUFREQ
maintainers:
- Hector Yuan <hector.yuan@mediatek.com>
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
deleted file mode 100644
index e0a4ba599abc..000000000000
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
+++ /dev/null
@@ -1,250 +0,0 @@
-Binding for MediaTek's CPUFreq driver
-=====================================
-
-Required properties:
-- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names.
-- clock-names: Should contain the following:
- "cpu" - The multiplexer for clock input of CPU cluster.
- "intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
- source (usually MAINPLL) when the original CPU PLL is under
- transition and not stable yet.
- Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
- generic clock consumer properties.
-- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
- for detail.
-- proc-supply: Regulator for Vproc of CPU cluster.
-
-Optional properties:
-- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver
- needs to do "voltage tracking" to step by step scale up/down Vproc and
- Vsram to fit SoC specific needs. When absent, the voltage scaling
- flow is handled by hardware, hence no software "voltage tracking" is
- needed.
-- mediatek,cci:
- Used to confirm the link status between cpufreq and mediatek cci. Because
- cpufreq and mediatek cci could share the same regulator in some MediaTek SoCs.
- To prevent the issue of high frequency and low voltage, we need to use this
- property to make sure mediatek cci is ready.
- For details of mediatek cci, please refer to
- Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml
-- #cooling-cells:
- For details, please refer to
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
-
-Example 1 (MT7623 SoC):
-
- cpu_opp_table: opp_table {
- compatible = "operating-points-v2";
- opp-shared;
-
- opp-598000000 {
- opp-hz = /bits/ 64 <598000000>;
- opp-microvolt = <1050000>;
- };
-
- opp-747500000 {
- opp-hz = /bits/ 64 <747500000>;
- opp-microvolt = <1050000>;
- };
-
- opp-1040000000 {
- opp-hz = /bits/ 64 <1040000000>;
- opp-microvolt = <1150000>;
- };
-
- opp-1196000000 {
- opp-hz = /bits/ 64 <1196000000>;
- opp-microvolt = <1200000>;
- };
-
- opp-1300000000 {
- opp-hz = /bits/ 64 <1300000000>;
- opp-microvolt = <1300000>;
- };
- };
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x0>;
- clocks = <&infracfg CLK_INFRA_CPUSEL>,
- <&apmixedsys CLK_APMIXED_MAINPLL>;
- clock-names = "cpu", "intermediate";
- operating-points-v2 = <&cpu_opp_table>;
- #cooling-cells = <2>;
- };
- cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x1>;
- operating-points-v2 = <&cpu_opp_table>;
- };
- cpu@2 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x2>;
- operating-points-v2 = <&cpu_opp_table>;
- };
- cpu@3 {
- device_type = "cpu";
- compatible = "arm,cortex-a7";
- reg = <0x3>;
- operating-points-v2 = <&cpu_opp_table>;
- };
-
-Example 2 (MT8173 SoC):
- cpu_opp_table_a: opp_table_a {
- compatible = "operating-points-v2";
- opp-shared;
-
- opp-507000000 {
- opp-hz = /bits/ 64 <507000000>;
- opp-microvolt = <859000>;
- };
-
- opp-702000000 {
- opp-hz = /bits/ 64 <702000000>;
- opp-microvolt = <908000>;
- };
-
- opp-1001000000 {
- opp-hz = /bits/ 64 <1001000000>;
- opp-microvolt = <983000>;
- };
-
- opp-1105000000 {
- opp-hz = /bits/ 64 <1105000000>;
- opp-microvolt = <1009000>;
- };
-
- opp-1183000000 {
- opp-hz = /bits/ 64 <1183000000>;
- opp-microvolt = <1028000>;
- };
-
- opp-1404000000 {
- opp-hz = /bits/ 64 <1404000000>;
- opp-microvolt = <1083000>;
- };
-
- opp-1508000000 {
- opp-hz = /bits/ 64 <1508000000>;
- opp-microvolt = <1109000>;
- };
-
- opp-1573000000 {
- opp-hz = /bits/ 64 <1573000000>;
- opp-microvolt = <1125000>;
- };
- };
-
- cpu_opp_table_b: opp_table_b {
- compatible = "operating-points-v2";
- opp-shared;
-
- opp-507000000 {
- opp-hz = /bits/ 64 <507000000>;
- opp-microvolt = <828000>;
- };
-
- opp-702000000 {
- opp-hz = /bits/ 64 <702000000>;
- opp-microvolt = <867000>;
- };
-
- opp-1001000000 {
- opp-hz = /bits/ 64 <1001000000>;
- opp-microvolt = <927000>;
- };
-
- opp-1209000000 {
- opp-hz = /bits/ 64 <1209000000>;
- opp-microvolt = <968000>;
- };
-
- opp-1404000000 {
- opp-hz = /bits/ 64 <1007000000>;
- opp-microvolt = <1028000>;
- };
-
- opp-1612000000 {
- opp-hz = /bits/ 64 <1612000000>;
- opp-microvolt = <1049000>;
- };
-
- opp-1807000000 {
- opp-hz = /bits/ 64 <1807000000>;
- opp-microvolt = <1089000>;
- };
-
- opp-1989000000 {
- opp-hz = /bits/ 64 <1989000000>;
- opp-microvolt = <1125000>;
- };
- };
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x000>;
- enable-method = "psci";
- cpu-idle-states = <&CPU_SLEEP_0>;
- clocks = <&infracfg CLK_INFRA_CA53SEL>,
- <&apmixedsys CLK_APMIXED_MAINPLL>;
- clock-names = "cpu", "intermediate";
- operating-points-v2 = <&cpu_opp_table_a>;
- };
-
- cpu1: cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a53";
- reg = <0x001>;
- enable-method = "psci";
- cpu-idle-states = <&CPU_SLEEP_0>;
- clocks = <&infracfg CLK_INFRA_CA53SEL>,
- <&apmixedsys CLK_APMIXED_MAINPLL>;
- clock-names = "cpu", "intermediate";
- operating-points-v2 = <&cpu_opp_table_a>;
- };
-
- cpu2: cpu@100 {
- device_type = "cpu";
- compatible = "arm,cortex-a72";
- reg = <0x100>;
- enable-method = "psci";
- cpu-idle-states = <&CPU_SLEEP_0>;
- clocks = <&infracfg CLK_INFRA_CA72SEL>,
- <&apmixedsys CLK_APMIXED_MAINPLL>;
- clock-names = "cpu", "intermediate";
- operating-points-v2 = <&cpu_opp_table_b>;
- };
-
- cpu3: cpu@101 {
- device_type = "cpu";
- compatible = "arm,cortex-a72";
- reg = <0x101>;
- enable-method = "psci";
- cpu-idle-states = <&CPU_SLEEP_0>;
- clocks = <&infracfg CLK_INFRA_CA72SEL>,
- <&apmixedsys CLK_APMIXED_MAINPLL>;
- clock-names = "cpu", "intermediate";
- operating-points-v2 = <&cpu_opp_table_b>;
- };
-
- &cpu0 {
- proc-supply = <&mt6397_vpca15_reg>;
- };
-
- &cpu1 {
- proc-supply = <&mt6397_vpca15_reg>;
- };
-
- &cpu2 {
- proc-supply = <&da9211_vcpu_reg>;
- sram-supply = <&mt6397_vsramca7_reg>;
- };
-
- &cpu3 {
- proc-supply = <&da9211_vcpu_reg>;
- sram-supply = <&mt6397_vsramca7_reg>;
- };
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
index 24fa3d87a40b..2d42fc3d8ef8 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
@@ -20,28 +20,53 @@ properties:
oneOf:
- description: v1 of CPUFREQ HW
items:
+ - enum:
+ - qcom,qcm2290-cpufreq-hw
+ - qcom,qcs615-cpufreq-hw
+ - qcom,sc7180-cpufreq-hw
+ - qcom,sc8180x-cpufreq-hw
+ - qcom,sdm670-cpufreq-hw
+ - qcom,sdm845-cpufreq-hw
+ - qcom,sm6115-cpufreq-hw
+ - qcom,sm6350-cpufreq-hw
+ - qcom,sm8150-cpufreq-hw
- const: qcom,cpufreq-hw
- description: v2 of CPUFREQ HW (EPSS)
items:
- enum:
+ - qcom,qcs8300-cpufreq-epss
+ - qcom,qdu1000-cpufreq-epss
+ - qcom,sa8255p-cpufreq-epss
+ - qcom,sa8775p-cpufreq-epss
+ - qcom,sar2130p-cpufreq-epss
+ - qcom,sc7280-cpufreq-epss
+ - qcom,sc8280xp-cpufreq-epss
+ - qcom,sdx75-cpufreq-epss
+ - qcom,sm4450-cpufreq-epss
- qcom,sm6375-cpufreq-epss
- qcom,sm8250-cpufreq-epss
+ - qcom,sm8350-cpufreq-epss
+ - qcom,sm8450-cpufreq-epss
+ - qcom,sm8550-cpufreq-epss
+ - qcom,sm8650-cpufreq-epss
- const: qcom,cpufreq-epss
reg:
- minItems: 2
+ minItems: 1
items:
- description: Frequency domain 0 register region
- description: Frequency domain 1 register region
- description: Frequency domain 2 register region
+ - description: Frequency domain 3 register region
reg-names:
- minItems: 2
+ minItems: 1
items:
- const: freq-domain0
- const: freq-domain1
- const: freq-domain2
+ - const: freq-domain3
clocks:
items:
@@ -53,9 +78,24 @@ properties:
- const: xo
- const: alternate
+ interrupts:
+ minItems: 1
+ maxItems: 4
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: dcvsh-irq-0
+ - const: dcvsh-irq-1
+ - const: dcvsh-irq-2
+ - const: dcvsh-irq-3
+
'#freq-domain-cells':
const: 1
+ '#clock-cells':
+ const: 1
+
required:
- compatible
- reg
@@ -65,6 +105,143 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcm2290-cpufreq-hw
+ - qcom,sar2130p-cpufreq-epss
+ - qcom,sdx75-cpufreq-epss
+ then:
+ properties:
+ reg:
+ maxItems: 1
+
+ reg-names:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs615-cpufreq-hw
+ - qcom,qdu1000-cpufreq-epss
+ - qcom,sa8255p-cpufreq-epss
+ - qcom,sa8775p-cpufreq-epss
+ - qcom,sc7180-cpufreq-hw
+ - qcom,sc8180x-cpufreq-hw
+ - qcom,sc8280xp-cpufreq-epss
+ - qcom,sdm670-cpufreq-hw
+ - qcom,sdm845-cpufreq-hw
+ - qcom,sm4450-cpufreq-epss
+ - qcom,sm6115-cpufreq-hw
+ - qcom,sm6350-cpufreq-hw
+ - qcom,sm6375-cpufreq-epss
+ then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ minItems: 2
+ maxItems: 2
+
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-cpufreq-epss
+ - qcom,sc7280-cpufreq-epss
+ - qcom,sm8250-cpufreq-epss
+ - qcom,sm8350-cpufreq-epss
+ - qcom,sm8450-cpufreq-epss
+ - qcom,sm8550-cpufreq-epss
+ then:
+ properties:
+ reg:
+ minItems: 3
+ maxItems: 3
+
+ reg-names:
+ minItems: 3
+ maxItems: 3
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 3
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8150-cpufreq-hw
+ then:
+ properties:
+ reg:
+ minItems: 3
+ maxItems: 3
+
+ reg-names:
+ minItems: 3
+ maxItems: 3
+
+ # On some SoCs the Prime core shares the LMH irq with Big cores
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8650-cpufreq-epss
+ then:
+ properties:
+ reg:
+ minItems: 4
+ maxItems: 4
+
+ reg-names:
+ minItems: 4
+ maxItems: 4
+
+ interrupts:
+ minItems: 4
+ maxItems: 4
+
+ interrupt-names:
+ minItems: 4
+ maxItems: 4
+
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
@@ -83,11 +260,16 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_0>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ clocks = <&cpufreq_hw 0>;
L2_0: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
L3_0: l3-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <3>;
};
};
};
@@ -99,8 +281,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_100>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ clocks = <&cpufreq_hw 0>;
L2_100: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -112,8 +297,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_200>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ clocks = <&cpufreq_hw 0>;
L2_200: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -125,8 +313,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_300>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ clocks = <&cpufreq_hw 0>;
L2_300: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -138,8 +329,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_400>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ clocks = <&cpufreq_hw 1>;
L2_400: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -151,8 +345,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_500>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ clocks = <&cpufreq_hw 1>;
L2_500: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -164,8 +361,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_600>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ clocks = <&cpufreq_hw 1>;
L2_600: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -177,8 +377,11 @@ examples:
enable-method = "psci";
next-level-cache = <&L2_700>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ clocks = <&cpufreq_hw 1>;
L2_700: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
};
};
@@ -189,7 +392,7 @@ examples:
#size-cells = <1>;
cpufreq@17d43000 {
- compatible = "qcom,cpufreq-hw";
+ compatible = "qcom,sdm845-cpufreq-hw", "qcom,cpufreq-hw";
reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>;
reg-names = "freq-domain0", "freq-domain1";
@@ -197,6 +400,7 @@ examples:
clock-names = "xo", "alternate";
#freq-domain-cells = <1>;
+ #clock-cells = <1>;
};
};
...
diff --git a/Documentation/devicetree/bindings/cpufreq/mediatek,mt8196-cpufreq-hw.yaml b/Documentation/devicetree/bindings/cpufreq/mediatek,mt8196-cpufreq-hw.yaml
new file mode 100644
index 000000000000..5f3c7db3f3aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/mediatek,mt8196-cpufreq-hw.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/mediatek,mt8196-cpufreq-hw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Hybrid CPUFreq for MT8196/MT6991 series SoCs
+
+maintainers:
+ - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+description:
+ MT8196 uses CPUFreq management hardware that supports dynamic voltage
+ frequency scaling (dvfs), and can support several performance domains.
+
+properties:
+ compatible:
+ const: mediatek,mt8196-cpufreq-hw
+
+ reg:
+ items:
+ - description: FDVFS control register region
+ - description: OPP tables and control for performance domain 0
+ - description: OPP tables and control for performance domain 1
+ - description: OPP tables and control for performance domain 2
+
+ "#performance-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#performance-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a720";
+ enable-method = "psci";
+ performance-domains = <&performance 0>;
+ reg = <0x000>;
+ };
+
+ /* ... */
+
+ cpu6: cpu@600 {
+ device_type = "cpu";
+ compatible = "arm,cortex-x4";
+ enable-method = "psci";
+ performance-domains = <&performance 1>;
+ reg = <0x600>;
+ };
+
+ cpu7: cpu@700 {
+ device_type = "cpu";
+ compatible = "arm,cortex-x925";
+ enable-method = "psci";
+ performance-domains = <&performance 2>;
+ reg = <0x700>;
+ };
+ };
+
+ /* ... */
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ performance: performance-controller@c2c2034 {
+ compatible = "mediatek,mt8196-cpufreq-hw";
+ reg = <0 0xc220400 0 0x20>, <0 0xc2c0f20 0 0x120>,
+ <0 0xc2c1040 0 0x120>, <0 0xc2c1160 0 0x120>;
+ #performance-domain-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
index a11e1b867379..547265b8b118 100644
--- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/cpufreq/qcom-cpufreq-nvmem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. NVMEM CPUFreq bindings
+title: Qualcomm Technologies, Inc. NVMEM CPUFreq
maintainers:
- Ilia Lin <ilia.lin@kernel.org>
@@ -17,6 +17,9 @@ description: |
on the CPU OPP in use. The CPUFreq driver sets the CPR power domain level
according to the required OPPs defined in the CPU OPP tables.
+ For old implementation efuses are parsed to select the correct opp table and
+ voltage and CPR is not supported/used.
+
select:
properties:
compatible:
@@ -24,7 +27,12 @@ select:
enum:
- qcom,apq8064
- qcom,apq8096
+ - qcom,ipq5332
+ - qcom,ipq6018
- qcom,ipq8064
+ - qcom,ipq8074
+ - qcom,ipq9574
+ - qcom,msm8909
- qcom,msm8939
- qcom,msm8960
- qcom,msm8974
@@ -33,37 +41,67 @@ select:
required:
- compatible
-properties:
- cpus:
- type: object
-
- patternProperties:
- 'cpu@[0-9a-f]+':
- type: object
-
- properties:
- power-domains:
- maxItems: 1
-
- power-domain-names:
- items:
- - const: cpr
-
- required:
- - power-domains
- - power-domain-names
-
patternProperties:
'^opp-table(-[a-z0-9]+)?$':
- if:
+ allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - operating-points-v2-krait-cpu
+ - operating-points-v2-kryo-cpu
+ then:
+ $ref: /schemas/opp/opp-v2-kryo-cpu.yaml#
+
+ - if:
+ properties:
+ compatible:
+ const: operating-points-v2-qcom-level
+ then:
+ $ref: /schemas/opp/opp-v2-qcom-level.yaml#
+
+ unevaluatedProperties: false
+
+allOf:
+ - if:
properties:
compatible:
- const: operating-points-v2-kryo-cpu
+ contains:
+ enum:
+ - qcom,qcs404
+
then:
+ properties:
+ cpus:
+ type: object
+
+ patternProperties:
+ '^cpu@[0-9a-f]+$':
+ type: object
+
+ properties:
+ power-domains:
+ maxItems: 1
+
+ power-domain-names:
+ items:
+ - const: cpr
+
+ required:
+ - power-domains
+ - power-domain-names
+
patternProperties:
- '^opp-?[0-9]+$':
- required:
- - required-opps
+ '^opp-table(-[a-z0-9]+)?$':
+ if:
+ properties:
+ compatible:
+ const: operating-points-v2-kryo-cpu
+ then:
+ patternProperties:
+ '^opp-?[0-9]+$':
+ required:
+ - required-opps
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml
new file mode 100644
index 000000000000..018d98bcdc82
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/qemu,virtual-cpufreq.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/qemu,virtual-cpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Virtual CPUFreq
+
+maintainers:
+ - David Dai <davidai@google.com>
+ - Saravana Kannan <saravanak@google.com>
+
+description:
+ Virtual CPUFreq is a virtualized driver in guest kernels that sends performance
+ selection of its vCPUs as a hint to the host through MMIO regions. Each vCPU
+ is associated with a performance domain which can be shared with other vCPUs.
+ Each performance domain has its own set of registers for performance controls.
+
+properties:
+ compatible:
+ const: qemu,virtual-cpufreq
+
+ reg:
+ maxItems: 1
+ description:
+ Address and size of region containing performance controls for each of the
+ performance domains. Regions for each performance domain is placed
+ contiguously and contain registers for controlling DVFS(Dynamic Frequency
+ and Voltage) characteristics. The size of the region is proportional to
+ total number of performance domains.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpufreq@1040000 {
+ compatible = "qemu,virtual-cpufreq";
+ reg = <0x1040000 0x2000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
deleted file mode 100644
index 1758051798fe..000000000000
--- a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-TI CPUFreq and OPP bindings
-================================
-
-Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
-families support different OPPs depending on the silicon variant in use.
-The ti-cpufreq driver can use revision and an efuse value from the SoC to
-provide the OPP framework with supported hardware information. This is
-used to determine which OPPs from the operating-points-v2 table get enabled
-when it is parsed by the OPP framework.
-
-Required properties:
---------------------
-In 'cpus' nodes:
-- operating-points-v2: Phandle to the operating-points-v2 table to use.
-
-In 'operating-points-v2' table:
-- compatible: Should be
- - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx,
- omap34xx, omap36xx and am3517 SoCs
-- syscon: A phandle pointing to a syscon node representing the control module
- register space of the SoC.
-
-Optional properties:
---------------------
-- "vdd-supply", "vbb-supply": to define two regulators for dra7xx
-- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx
-
-For each opp entry in 'operating-points-v2' table:
-- opp-supported-hw: Two bitfields indicating:
- 1. Which revision of the SoC the OPP is supported by
- 2. Which eFuse bits indicate this OPP is available
-
- A bitwise AND is performed against these values and if any bit
- matches, the OPP gets enabled.
-
-Example:
---------
-
-/* From arch/arm/boot/dts/am33xx.dtsi */
-cpus {
- #address-cells = <1>;
- #size-cells = <0>;
- cpu@0 {
- compatible = "arm,cortex-a8";
- device_type = "cpu";
- reg = <0>;
-
- operating-points-v2 = <&cpu0_opp_table>;
-
- clocks = <&dpll_mpu_ck>;
- clock-names = "cpu";
-
- clock-latency = <300000>; /* From omap-cpufreq driver */
- };
-};
-
-/*
- * cpu0 has different OPPs depending on SoC revision and some on revisions
- * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
- */
-cpu0_opp_table: opp-table {
- compatible = "operating-points-v2-ti-cpu";
- syscon = <&scm_conf>;
-
- /*
- * The three following nodes are marked with opp-suspend
- * because they can not be enabled simultaneously on a
- * single SoC.
- */
- opp50-300000000 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <950000 931000 969000>;
- opp-supported-hw = <0x06 0x0010>;
- opp-suspend;
- };
-
- opp100-275000000 {
- opp-hz = /bits/ 64 <275000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x01 0x00FF>;
- opp-suspend;
- };
-
- opp100-300000000 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x06 0x0020>;
- opp-suspend;
- };
-
- opp100-500000000 {
- opp-hz = /bits/ 64 <500000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- opp100-600000000 {
- opp-hz = /bits/ 64 <600000000>;
- opp-microvolt = <1100000 1078000 1122000>;
- opp-supported-hw = <0x06 0x0040>;
- };
-
- opp120-600000000 {
- opp-hz = /bits/ 64 <600000000>;
- opp-microvolt = <1200000 1176000 1224000>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- opp120-720000000 {
- opp-hz = /bits/ 64 <720000000>;
- opp-microvolt = <1200000 1176000 1224000>;
- opp-supported-hw = <0x06 0x0080>;
- };
-
- oppturbo-720000000 {
- opp-hz = /bits/ 64 <720000000>;
- opp-microvolt = <1260000 1234800 1285200>;
- opp-supported-hw = <0x01 0xFFFF>;
- };
-
- oppturbo-800000000 {
- opp-hz = /bits/ 64 <800000000>;
- opp-microvolt = <1260000 1234800 1285200>;
- opp-supported-hw = <0x06 0x0100>;
- };
-
- oppnitro-1000000000 {
- opp-hz = /bits/ 64 <1000000000>;
- opp-microvolt = <1325000 1298500 1351500>;
- opp-supported-hw = <0x04 0x0200>;
- };
-};
diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
index dedc99e34ebc..0401c11da8d9 100644
--- a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
+++ b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/allwinner,sun4i-a10-crypto.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Security System Device Tree Bindings
+title: Allwinner A10 Security System
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
index 026a9f9e1aeb..da47b601c165 100644
--- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
+++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
@@ -14,9 +14,11 @@ properties:
enum:
- allwinner,sun8i-h3-crypto
- allwinner,sun8i-r40-crypto
+ - allwinner,sun20i-d1-crypto
- allwinner,sun50i-a64-crypto
- allwinner,sun50i-h5-crypto
- allwinner,sun50i-h6-crypto
+ - allwinner,sun50i-h616-crypto
reg:
maxItems: 1
@@ -29,6 +31,7 @@ properties:
- description: Bus clock
- description: Module clock
- description: MBus clock
+ - description: TRNG clock (RC oscillator)
minItems: 2
clock-names:
@@ -36,6 +39,7 @@ properties:
- const: bus
- const: mod
- const: ram
+ - const: trng
minItems: 2
resets:
@@ -44,19 +48,34 @@ properties:
if:
properties:
compatible:
- const: allwinner,sun50i-h6-crypto
+ enum:
+ - allwinner,sun20i-d1-crypto
+ - allwinner,sun50i-h616-crypto
then:
properties:
clocks:
- minItems: 3
+ minItems: 4
clock-names:
- minItems: 3
+ minItems: 4
else:
- properties:
- clocks:
- maxItems: 2
- clock-names:
- maxItems: 2
+ if:
+ properties:
+ compatible:
+ const: allwinner,sun50i-h6-crypto
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ else:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
required:
- compatible
diff --git a/Documentation/devicetree/bindings/crypto/amd,ccp-seattle-v1a.yaml b/Documentation/devicetree/bindings/crypto/amd,ccp-seattle-v1a.yaml
new file mode 100644
index 000000000000..5fb708471059
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/amd,ccp-seattle-v1a.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/amd,ccp-seattle-v1a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Cryptographic Coprocessor (ccp)
+
+maintainers:
+ - Tom Lendacky <thomas.lendacky@amd.com>
+
+properties:
+ compatible:
+ const: amd,ccp-seattle-v1a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dma-coherent: true
+
+ iommus:
+ maxItems: 4
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ crypto@e0100000 {
+ compatible = "amd,ccp-seattle-v1a";
+ reg = <0xe0100000 0x10000>;
+ interrupts = <0 3 4>;
+ dma-coherent;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/amd-ccp.txt b/Documentation/devicetree/bindings/crypto/amd-ccp.txt
deleted file mode 100644
index d87579d63da6..000000000000
--- a/Documentation/devicetree/bindings/crypto/amd-ccp.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* AMD Cryptographic Coprocessor driver (ccp)
-
-Required properties:
-- compatible: Should be "amd,ccp-seattle-v1a"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the CCP interrupt
-
-Optional properties:
-- dma-coherent: Present if dma operations are coherent
-
-Example:
- ccp@e0100000 {
- compatible = "amd,ccp-seattle-v1a";
- reg = <0 0xe0100000 0 0x10000>;
- interrupt-parent = <&gic>;
- interrupts = <0 3 4>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
index ecf98a9e72b2..948e11ebe4ee 100644
--- a/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
+++ b/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
@@ -19,8 +19,8 @@ properties:
interrupts:
items:
- - description: "Interrupt for flow 0"
- - description: "Interrupt for flow 1"
+ - description: Interrupt for flow 0
+ - description: Interrupt for flow 1
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/artpec6-crypto.txt b/Documentation/devicetree/bindings/crypto/artpec6-crypto.txt
deleted file mode 100644
index d9cca4875bd6..000000000000
--- a/Documentation/devicetree/bindings/crypto/artpec6-crypto.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Axis crypto engine with PDMA interface.
-
-Required properties:
-- compatible : Should be one of the following strings:
- "axis,artpec6-crypto" for the version in the Axis ARTPEC-6 SoC
- "axis,artpec7-crypto" for the version in the Axis ARTPEC-7 SoC.
-- reg: Base address and size for the PDMA register area.
-- interrupts: Interrupt handle for the PDMA interrupt line.
-
-Example:
-
-crypto@f4264000 {
- compatible = "axis,artpec6-crypto";
- reg = <0xf4264000 0x1000>;
- interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/crypto/aspeed,ast2500-hace.yaml b/Documentation/devicetree/bindings/crypto/aspeed,ast2500-hace.yaml
new file mode 100644
index 000000000000..a772d232de09
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/aspeed,ast2500-hace.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/aspeed,ast2500-hace.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED HACE hash and crypto Hardware Accelerator Engines
+
+maintainers:
+ - Neal Liu <neal_liu@aspeedtech.com>
+
+description: |
+ The Hash and Crypto Engine (HACE) is designed to accelerate the throughput
+ of hash data digest, encryption, and decryption. Basically, HACE can be
+ divided into two independently engines - Hash Engine and Crypto Engine.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2500-hace
+ - aspeed,ast2600-hace
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ hace: crypto@1e6d0000 {
+ compatible = "aspeed,ast2600-hace";
+ reg = <0x1e6d0000 0x200>;
+ interrupts = <4>;
+ clocks = <&syscon ASPEED_CLK_GATE_YCLK>;
+ resets = <&syscon ASPEED_RESET_HACE>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml b/Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml
new file mode 100644
index 000000000000..b18f178aac06
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/aspeed,ast2600-acry.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/aspeed,ast2600-acry.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED ACRY ECDSA/RSA Hardware Accelerator Engines
+
+maintainers:
+ - Neal Liu <neal_liu@aspeedtech.com>
+
+description:
+ The ACRY ECDSA/RSA engines is designed to accelerate the throughput
+ of ECDSA/RSA signature and verification. Basically, ACRY can be
+ divided into two independent engines - ECC Engine and RSA Engine.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-acry
+
+ reg:
+ items:
+ - description: acry base address & size
+ - description: acry sram base address & size
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ acry: crypto@1e6fa000 {
+ compatible = "aspeed,ast2600-acry";
+ reg = <0x1e6fa000 0x400>, <0x1e710000 0x1800>;
+ interrupts = <160>;
+ clocks = <&syscon ASPEED_CLK_GATE_RSACLK>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml
index 0ccaab16dc61..19010f90198a 100644
--- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml
+++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml
@@ -8,11 +8,17 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel Advanced Encryption Standard (AES) HW cryptographic accelerator
maintainers:
- - Tudor Ambarus <tudor.ambarus@microchip.com>
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
properties:
compatible:
- const: atmel,at91sam9g46-aes
+ oneOf:
+ - const: atmel,at91sam9g46-aes
+ - items:
+ - enum:
+ - microchip,sam9x7-aes
+ - microchip,sama7d65-aes
+ - const: atmel,at91sam9g46-aes
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml
index 5163c51b4547..39e076b275b3 100644
--- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml
+++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml
@@ -8,11 +8,17 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel Secure Hash Algorithm (SHA) HW cryptographic accelerator
maintainers:
- - Tudor Ambarus <tudor.ambarus@microchip.com>
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
properties:
compatible:
- const: atmel,at91sam9g46-sha
+ oneOf:
+ - const: atmel,at91sam9g46-sha
+ - items:
+ - enum:
+ - microchip,sam9x7-sha
+ - microchip,sama7d65-sha
+ - const: atmel,at91sam9g46-sha
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
index fcc5adf03cad..6f16008c4251 100644
--- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
+++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
@@ -8,11 +8,17 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel Triple Data Encryption Standard (TDES) HW cryptographic accelerator
maintainers:
- - Tudor Ambarus <tudor.ambarus@microchip.com>
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
properties:
compatible:
- const: atmel,at91sam9g46-tdes
+ oneOf:
+ - const: atmel,at91sam9g46-tdes
+ - items:
+ - enum:
+ - microchip,sam9x7-tdes
+ - microchip,sama7d65-tdes
+ - const: atmel,at91sam9g46-tdes
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/axis,artpec6-crypto.yaml b/Documentation/devicetree/bindings/crypto/axis,artpec6-crypto.yaml
new file mode 100644
index 000000000000..c91f81e3c39e
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/axis,artpec6-crypto.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/axis,artpec6-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axis ARTPEC6 crypto engine with PDMA interface
+
+maintainers:
+ - Lars Persson <lars.persson@axis.com>
+
+properties:
+ compatible:
+ enum:
+ - axis,artpec6-crypto
+ - axis,artpec7-crypto
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ crypto@f4264000 {
+ compatible = "axis,artpec6-crypto";
+ reg = <0xf4264000 0x1000>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
deleted file mode 100644
index 29b6007568eb..000000000000
--- a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-The Broadcom Secure Processing Unit (SPU) hardware supports symmetric
-cryptographic offload for Broadcom SoCs. A SoC may have multiple SPU hardware
-blocks.
-
-Required properties:
-- compatible: Should be one of the following:
- brcm,spum-crypto - for devices with SPU-M hardware
- brcm,spu2-crypto - for devices with SPU2 hardware
- brcm,spu2-v2-crypto - for devices with enhanced SPU2 hardware features like SHA3
- and Rabin Fingerprint support
- brcm,spum-nsp-crypto - for the Northstar Plus variant of the SPU-M hardware
-
-- reg: Should contain SPU registers location and length.
-- mboxes: The mailbox channel to be used to communicate with the SPU.
- Mailbox channels correspond to DMA rings on the device.
-
-Example:
- crypto@612d0000 {
- compatible = "brcm,spum-crypto";
- reg = <0 0x612d0000 0 0x900>;
- mboxes = <&pdc0 0>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/brcm,spum-crypto.yaml b/Documentation/devicetree/bindings/crypto/brcm,spum-crypto.yaml
new file mode 100644
index 000000000000..9a5fb61727fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/brcm,spum-crypto.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/brcm,spum-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom SPU Crypto Offload
+
+maintainers:
+ - Rob Rice <rob.rice@broadcom.com>
+
+description:
+ The Broadcom Secure Processing Unit (SPU) hardware supports symmetric
+ cryptographic offload for Broadcom SoCs. A SoC may have multiple SPU hardware
+ blocks.
+
+properties:
+ compatible:
+ enum:
+ - brcm,spum-crypto
+ - brcm,spu2-crypto
+ - brcm,spu2-v2-crypto # enhanced SPU2 hardware features like SHA3 and Rabin Fingerprint support
+ - brcm,spum-nsp-crypto # Northstar Plus variant of the SPU-M hardware
+
+ reg:
+ maxItems: 1
+
+ mboxes:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mboxes
+
+additionalProperties: false
+
+examples:
+ - |
+ crypto@612d0000 {
+ compatible = "brcm,spum-crypto";
+ reg = <0x612d0000 0x900>;
+ mboxes = <&pdc0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml
new file mode 100644
index 000000000000..9f8e6689cd94
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2008-2011 Freescale Semiconductor Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/fsl,sec-v4.0-mon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Secure Non-Volatile Storage (SNVS)
+
+maintainers:
+ - '"Horia Geantă" <horia.geanta@nxp.com>'
+ - Pankaj Gupta <pankaj.gupta@nxp.com>
+ - Gaurav Jain <gaurav.jain@nxp.com>
+
+description:
+ Node defines address range and the associated interrupt for the SNVS function.
+ This function monitors security state information & reports security
+ violations. This also included rtc, system power off and ON/OFF key.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,sec-v4.0-mon
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - const: fsl,sec-v5.0-mon
+ - const: fsl,sec-v4.0-mon
+ - items:
+ - enum:
+ - fsl,sec-v5.3-mon
+ - fsl,sec-v5.4-mon
+ - const: fsl,sec-v5.0-mon
+ - const: fsl,sec-v4.0-mon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ snvs-rtc-lp:
+ type: object
+ additionalProperties: false
+ description:
+ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
+
+ properties:
+ compatible:
+ const: fsl,sec-v4.0-mon-rtc-lp
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: snvs-rtc
+
+ interrupts:
+ # VFxxx has only one. What is the 2nd one?
+ minItems: 1
+ maxItems: 2
+
+ regmap:
+ description: Parent node containing registers
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ offset:
+ description: LP register offset
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x34
+
+ required:
+ - compatible
+ - interrupts
+ - regmap
+
+ snvs-powerkey:
+ type: object
+ additionalProperties: false
+ description:
+ The snvs-pwrkey is designed to enable POWER key function which controlled
+ by SNVS ONOFF, the driver can report the status of POWER key and wakeup
+ system if pressed after system suspend.
+
+ $ref: /schemas/input/input.yaml
+
+ properties:
+ compatible:
+ const: fsl,sec-v4.0-pwrkey
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: snvs-pwrkey
+
+ interrupts:
+ maxItems: 1
+
+ regmap:
+ description: Parent node containing registers
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ wakeup-source: true
+
+ linux,keycode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 116
+ deprecated: true
+
+ linux,keycodes:
+ maxItems: 1
+ default: 116
+
+ power-off-time-sec:
+ enum: [0, 5, 10, 15]
+
+ required:
+ - compatible
+ - interrupts
+ - regmap
+
+ snvs-lpgpr:
+ $ref: /schemas/nvmem/snvs-lpgpr.yaml#
+
+ snvs-poweroff:
+ description:
+ The SNVS could drive signal to PMIC to turn off system power by setting
+ SNVS_LP LPCR register.
+ $ref: /schemas/power/reset/syscon-poweroff.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx7d-clock.h>
+
+ sec_mon: sec-mon@314000 {
+ compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd";
+ reg = <0x314000 0x1000>;
+
+ snvs-rtc-lp {
+ compatible = "fsl,sec-v4.0-mon-rtc-lp";
+ regmap = <&sec_mon>;
+ offset = <0x34>;
+ clocks = <&clks IMX7D_SNVS_CLK>;
+ clock-names = "snvs-rtc";
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ snvs-powerkey {
+ compatible = "fsl,sec-v4.0-pwrkey";
+ regmap = <&sec_mon>;
+ clocks = <&clks IMX7D_SNVS_CLK>;
+ clock-names = "snvs-pwrkey";
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ linux,keycode = <116>; /* KEY_POWER */
+ wakeup-source;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml
new file mode 100644
index 000000000000..dcc755d2709a
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml
@@ -0,0 +1,318 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2008-2011 Freescale Semiconductor Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/fsl,sec-v4.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale SEC 4
+
+maintainers:
+ - '"Horia Geantă" <horia.geanta@nxp.com>'
+ - Pankaj Gupta <pankaj.gupta@nxp.com>
+ - Gaurav Jain <gaurav.jain@nxp.com>
+
+description: |
+ NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
+ Accelerator and Assurance Module (CAAM).
+
+ SEC 4 h/w can process requests from 2 types of sources.
+ 1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4).
+ 2. Job Rings (HW interface between cores & SEC 4 registers).
+
+ High Speed Data Path Configuration:
+
+ HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts
+ such as the P4080. The number of simultaneous dequeues the QI can make is
+ equal to the number of Descriptor Controller (DECO) engines in a particular
+ SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
+ dequeue from 5 subportals simultaneously.
+
+ Job Ring Data Path Configuration:
+
+ Each JR is located on a separate 4k page, they may (or may not) be made visible
+ in the memory partition devoted to a particular core. The P4080 has 4 JRs, so
+ up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,sec-v5.4
+ - fsl,sec-v6.0
+ - const: fsl,sec-v5.0
+ - const: fsl,sec-v4.0
+ - items:
+ - enum:
+ - fsl,imx6ul-caam
+ - fsl,imx8qm-caam
+ - fsl,imx8qxp-caam
+ - fsl,sec-v5.0
+ - const: fsl,sec-v4.0
+ - const: fsl,sec-v4.0
+
+ reg:
+ maxItems: 1
+
+ ranges:
+ maxItems: 1
+
+ '#address-cells':
+ enum: [1, 2]
+
+ '#size-cells':
+ enum: [1, 2]
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [mem, aclk, ipg, emi_slow]
+
+ dma-coherent: true
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ fsl,sec-era:
+ description: Defines the 'ERA' of the SEC device.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+patternProperties:
+ '^jr@[0-9a-f]+$':
+ type: object
+ additionalProperties: false
+ description:
+ Job Ring (JR) Node. Defines data processing interface to SEC 4 across the
+ peripheral bus for purposes of processing cryptographic descriptors. The
+ specified address range can be made visible to one (or more) cores. The
+ interrupt defined for this node is controlled within the address range of
+ this node.
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,sec-v6.0-job-ring
+ - const: fsl,sec-v5.2-job-ring
+ - const: fsl,sec-v5.0-job-ring
+ - const: fsl,sec-v4.4-job-ring
+ - const: fsl,sec-v4.0-job-ring
+ - items:
+ - const: fsl,sec-v5.4-job-ring
+ - const: fsl,sec-v5.0-job-ring
+ - const: fsl,sec-v4.0-job-ring
+ - items:
+ - enum:
+ - fsl,imx8qm-job-ring
+ - fsl,imx8qxp-job-ring
+ - fsl,sec-v5.0-job-ring
+ - const: fsl,sec-v4.0-job-ring
+ - const: fsl,sec-v4.0-job-ring
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ fsl,liodn:
+ description:
+ Specifies the LIODN to be used in conjunction with the ppid-to-liodn
+ table that specifies the PPID to LIODN mapping. Needed if the PAMU is
+ used. Value is a 12 bit value where value is a LIODN ID for this JR.
+ This property is normally set by boot firmware.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - maximum: 0xfff
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-job-ring
+ - fsl,imx8qxp-job-ring
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
+ '^rtic@[0-9a-f]+$':
+ type: object
+ additionalProperties: false
+ description:
+ Run Time Integrity Check (RTIC) Node. Defines a register space that
+ contains up to 5 sets of addresses and their lengths (sizes) that will be
+ checked at run time. After an initial hash result is calculated, these
+ addresses are checked by HW to monitor any change. If any memory is
+ modified, a Security Violation is triggered (see SNVS definition).
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,sec-v5.4-rtic
+ - const: fsl,sec-v5.0-rtic
+ - const: fsl,sec-v4.0-rtic
+ - const: fsl,sec-v4.0-rtic
+
+ reg:
+ items:
+ - description: RTIC control and status register space.
+ - description: RTIC recoverable error indication register space.
+ minItems: 1
+
+ ranges:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ patternProperties:
+ '^rtic-[a-z]@[0-9a-f]+$':
+ type: object
+ additionalProperties: false
+ description:
+ Run Time Integrity Check (RTIC) Memory Node defines individual RTIC
+ memory regions that are used to perform run-time integrity check of
+ memory areas that should not modified. The node defines a register
+ that contains the memory address & length (combined) and a second
+ register that contains the hash result in big endian format.
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,sec-v5.4-rtic-memory
+ - const: fsl,sec-v5.0-rtic-memory
+ - const: fsl,sec-v4.0-rtic-memory
+ - const: fsl,sec-v4.0-rtic-memory
+
+ reg:
+ items:
+ - description: RTIC memory address
+ - description: RTIC hash result
+
+ fsl,liodn:
+ description:
+ Specifies the LIODN to be used in conjunction with the
+ ppid-to-liodn table that specifies the PPID to LIODN mapping.
+ Needed if the PAMU is used. Value is a 12 bit value where value
+ is a LIODN ID for this JR. This property is normally set by boot
+ firmware.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - maximum: 0xfff
+
+ fsl,rtic-region:
+ description:
+ Specifies the HW address (36 bit address) for this region
+ followed by the length of the HW partition to be checked;
+ the address is represented as a 64 bit quantity followed
+ by a 32 bit length.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+required:
+ - compatible
+ - reg
+ - ranges
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-caam
+ - fsl,imx8qxp-caam
+then:
+ required:
+ - power-domains
+else:
+ properties:
+ power-domains: false
+
+additionalProperties: false
+
+examples:
+ - |
+ crypto@300000 {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x300000 0x10000>;
+ ranges = <0 0x300000 0x10000>;
+ interrupts = <92 2>;
+
+ jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <88 2>;
+ };
+
+ jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <89 2>;
+ };
+
+ jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <90 2>;
+ };
+
+ jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <91 2>;
+ };
+
+ rtic@6000 {
+ compatible = "fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6000 0x100>;
+ ranges = <0x0 0x6100 0xe00>;
+
+ rtic-a@0 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20>, <0x100 0x80>;
+ };
+
+ rtic-b@20 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20>, <0x200 0x80>;
+ };
+
+ rtic-c@40 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x40 0x20>, <0x300 0x80>;
+ };
+
+ rtic-d@60 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x60 0x20>, <0x500 0x80>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml
new file mode 100644
index 000000000000..2091b89bb726
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/fsl,sec2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale SoC SEC Security Engines versions 1.x-2.x-3.x
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+properties:
+ compatible:
+ description:
+ Should contain entries for this and backward compatible SEC versions,
+ high to low. Warning - SEC1 and SEC2 are mutually exclusive.
+ oneOf:
+ - items:
+ - const: fsl,sec3.3
+ - const: fsl,sec3.1
+ - const: fsl,sec3.0
+ - const: fsl,sec2.4
+ - const: fsl,sec2.2
+ - const: fsl,sec2.1
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec3.1
+ - const: fsl,sec3.0
+ - const: fsl,sec2.4
+ - const: fsl,sec2.2
+ - const: fsl,sec2.1
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec3.0
+ - const: fsl,sec2.4
+ - const: fsl,sec2.2
+ - const: fsl,sec2.1
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec2.4
+ - const: fsl,sec2.2
+ - const: fsl,sec2.1
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec2.2
+ - const: fsl,sec2.1
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec2.1
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec2.0
+ - items:
+ - const: fsl,sec1.2
+ - const: fsl,sec1.0
+ - items:
+ - const: fsl,sec1.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,num-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1, 4 ]
+ description: An integer representing the number of channels available.
+
+ fsl,channel-fifo-len:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 100
+ description:
+ An integer representing the number of descriptor pointers each channel
+ fetch fifo can hold.
+
+ fsl,exec-units-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 0xfff
+ description: |
+ The bitmask representing what execution units (EUs) are available.
+ EU information should be encoded following the SEC's Descriptor Header
+ Dword EU_SEL0 field documentation, i.e. as follows:
+
+ bit 0 = reserved - should be 0
+ bit 1 = set if SEC has the ARC4 EU (AFEU)
+ bit 2 = set if SEC has the DES/3DES EU (DEU)
+ bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A)
+ bit 4 = set if SEC has the random number generator EU (RNG)
+ bit 5 = set if SEC has the public key EU (PKEU)
+ bit 6 = set if SEC has the AES EU (AESU)
+ bit 7 = set if SEC has the Kasumi EU (KEU)
+ bit 8 = set if SEC has the CRC EU (CRCU)
+ bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B)
+
+ remaining bits are reserved for future SEC EUs.
+
+ fsl,descriptor-types-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ The bitmask representing what descriptors are available. Descriptor type
+ information should be encoded following the SEC's Descriptor Header Dword
+ DESC_TYPE field documentation, i.e. as follows:
+
+ bit 0 = SEC supports descriptor type aesu_ctr_nonsnoop
+ bit 1 = SEC supports descriptor type ipsec_esp
+ bit 2 = SEC supports descriptor type common_nonsnoop
+ bit 3 = SEC supports descriptor type 802.11i AES ccmp
+ bit 4 = SEC supports descriptor type hmac_snoop_no_afeu
+ bit 5 = SEC supports descriptor type srtp
+ bit 6 = SEC supports descriptor type non_hmac_snoop_no_afeu
+ bit 7 = SEC supports descriptor type pkeu_assemble
+ bit 8 = SEC supports descriptor type aesu_key_expand_output
+ bit 9 = SEC supports descriptor type pkeu_ptmul
+ bit 10 = SEC supports descriptor type common_nonsnoop_afeu
+ bit 11 = SEC supports descriptor type pkeu_ptadd_dbl
+
+ ..and so on and so forth.
+
+required:
+ - compatible
+ - reg
+ - fsl,num-channels
+ - fsl,channel-fifo-len
+ - fsl,exec-units-mask
+ - fsl,descriptor-types-mask
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* MPC8548E */
+ crypto@30000 {
+ compatible = "fsl,sec2.1", "fsl,sec2.0";
+ reg = <0x30000 0x10000>;
+ interrupts = <29 2>;
+ interrupt-parent = <&mpic>;
+ fsl,num-channels = <4>;
+ fsl,channel-fifo-len = <24>;
+ fsl,exec-units-mask = <0xfe>;
+ fsl,descriptor-types-mask = <0x12b0ebf>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
index 99be01539fcd..8dd36c2f76fd 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
+++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
@@ -11,9 +11,15 @@ maintainers:
properties:
compatible:
- enum:
- - fsl,imx23-dcp
- - fsl,imx28-dcp
+ oneOf:
+ - enum:
+ - fsl,imx23-dcp
+ - fsl,imx28-dcp
+ - items:
+ - enum:
+ - fsl,imx6sl-dcp
+ - fsl,imx6ull-dcp
+ - const: fsl,imx28-dcp
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.yaml b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.yaml
index d531f3af3ea4..41df80bcdcd9 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.yaml
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/fsl-imx-sahara.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale SAHARA Cryptographic Accelerator included in some i.MX chips
+title: Freescale SAHARA Cryptographic Accelerator
maintainers:
- Steffen Trumtrar <s.trumtrar@pengutronix.de>
@@ -19,19 +19,56 @@ properties:
maxItems: 1
interrupts:
- maxItems: 1
+ items:
+ - description: SAHARA Interrupt for Host 0
+ - description: SAHARA Interrupt for Host 1
+ minItems: 1
+
+ clocks:
+ items:
+ - description: Sahara IPG clock
+ - description: Sahara AHB clock
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
required:
- compatible
- reg
- interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx53-sahara
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
additionalProperties: false
examples:
- |
+ #include <dt-bindings/clock/imx27-clock.h>
+
crypto@10025000 {
compatible = "fsl,imx27-sahara";
- reg = < 0x10025000 0x800>;
+ reg = <0x10025000 0x800>;
interrupts = <75>;
+ clocks = <&clks IMX27_CLK_SAHARA_IPG_GATE>,
+ <&clks IMX27_CLK_SAHARA_AHB_GATE>;
+ clock-names = "ipg", "ahb";
};
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
deleted file mode 100644
index 125f155d00d0..000000000000
--- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Freescale SoC SEC Security Engines versions 1.x-2.x-3.x
-
-Required properties:
-
-- compatible : Should contain entries for this and backward compatible
- SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" (SEC2/3)
- e.g., "fsl,sec1.2", "fsl,sec1.0" (SEC1)
- warning: SEC1 and SEC2 are mutually exclusive
-- reg : Offset and length of the register set for the device
-- interrupts : the SEC's interrupt number
-- fsl,num-channels : An integer representing the number of channels
- available.
-- fsl,channel-fifo-len : An integer representing the number of
- descriptor pointers each channel fetch fifo can hold.
-- fsl,exec-units-mask : The bitmask representing what execution units
- (EUs) are available. It's a single 32-bit cell. EU information
- should be encoded following the SEC's Descriptor Header Dword
- EU_SEL0 field documentation, i.e. as follows:
-
- bit 0 = reserved - should be 0
- bit 1 = set if SEC has the ARC4 EU (AFEU)
- bit 2 = set if SEC has the DES/3DES EU (DEU)
- bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A)
- bit 4 = set if SEC has the random number generator EU (RNG)
- bit 5 = set if SEC has the public key EU (PKEU)
- bit 6 = set if SEC has the AES EU (AESU)
- bit 7 = set if SEC has the Kasumi EU (KEU)
- bit 8 = set if SEC has the CRC EU (CRCU)
- bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B)
-
-remaining bits are reserved for future SEC EUs.
-
-- fsl,descriptor-types-mask : The bitmask representing what descriptors
- are available. It's a single 32-bit cell. Descriptor type information
- should be encoded following the SEC's Descriptor Header Dword DESC_TYPE
- field documentation, i.e. as follows:
-
- bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type
- bit 1 = set if SEC supports the ipsec_esp descriptor type
- bit 2 = set if SEC supports the common_nonsnoop desc. type
- bit 3 = set if SEC supports the 802.11i AES ccmp desc. type
- bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type
- bit 5 = set if SEC supports the srtp descriptor type
- bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type
- bit 7 = set if SEC supports the pkeu_assemble descriptor type
- bit 8 = set if SEC supports the aesu_key_expand_output desc.type
- bit 9 = set if SEC supports the pkeu_ptmul descriptor type
- bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type
- bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
-
- ..and so on and so forth.
-
-Example:
-
- /* MPC8548E */
- crypto@30000 {
- compatible = "fsl,sec2.1", "fsl,sec2.0";
- reg = <0x30000 0x10000>;
- interrupts = <29 2>;
- interrupt-parent = <&mpic>;
- fsl,num-channels = <4>;
- fsl,channel-fifo-len = <24>;
- fsl,exec-units-mask = <0xfe>;
- fsl,descriptor-types-mask = <0x12b0ebf>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
deleted file mode 100644
index 8f359f473ada..000000000000
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ /dev/null
@@ -1,553 +0,0 @@
-=====================================================================
-SEC 4 Device Tree Binding
-Copyright (C) 2008-2011 Freescale Semiconductor Inc.
-
- CONTENTS
- -Overview
- -SEC 4 Node
- -Job Ring Node
- -Run Time Integrity Check (RTIC) Node
- -Run Time Integrity Check (RTIC) Memory Node
- -Secure Non-Volatile Storage (SNVS) Node
- -Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
- -Full Example
-
-NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
-Accelerator and Assurance Module (CAAM).
-
-=====================================================================
-Overview
-
-DESCRIPTION
-
-SEC 4 h/w can process requests from 2 types of sources.
-1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4).
-2. Job Rings (HW interface between cores & SEC 4 registers).
-
-High Speed Data Path Configuration:
-
-HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts
-such as the P4080. The number of simultaneous dequeues the QI can make is
-equal to the number of Descriptor Controller (DECO) engines in a particular
-SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
-dequeue from 5 subportals simultaneously.
-
-Job Ring Data Path Configuration:
-
-Each JR is located on a separate 4k page, they may (or may not) be made visible
-in the memory partition devoted to a particular core. The P4080 has 4 JRs, so
-up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
-
-=====================================================================
-SEC 4 Node
-
-Description
-
- Node defines the base address of the SEC 4 block.
- This block specifies the address range of all global
- configuration registers for the SEC 4 block. It
- also receives interrupts from the Run Time Integrity Check
- (RTIC) function within the SEC 4 block.
-
-PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v4.0"
-
- - fsl,sec-era
- Usage: optional
- Value type: <u32>
- Definition: A standard property. Define the 'ERA' of the SEC
- device.
-
- - #address-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing physical addresses in child nodes.
-
- - #size-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing the size of physical addresses in
- child nodes.
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical
- address and length of the SEC4 configuration registers.
- registers
-
- - ranges
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical address
- range of the SEC 4.0 register space (-SNVS not included). A
- triplet that includes the child address, parent address, &
- length.
-
- - interrupts
- Usage: required
- Value type: <prop_encoded-array>
- Definition: Specifies the interrupts generated by this
- device. The value of the interrupts property
- consists of one interrupt specifier. The format
- of the specifier is defined by the binding document
- describing the node's interrupt parent.
-
- - clocks
- Usage: required if SEC 4.0 requires explicit enablement of clocks
- Value type: <prop_encoded-array>
- Definition: A list of phandle and clock specifier pairs describing
- the clocks required for enabling and disabling SEC 4.0.
-
- - clock-names
- Usage: required if SEC 4.0 requires explicit enablement of clocks
- Value type: <string>
- Definition: A list of clock name strings in the same order as the
- clocks property.
-
- Note: All other standard properties (see the Devicetree Specification)
- are allowed but are optional.
-
-
-EXAMPLE
-
-iMX6QDL/SX requires four clocks
-
- crypto@300000 {
- compatible = "fsl,sec-v4.0";
- fsl,sec-era = <2>;
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x300000 0x10000>;
- ranges = <0 0x300000 0x10000>;
- interrupt-parent = <&mpic>;
- interrupts = <92 2>;
- clocks = <&clks IMX6QDL_CLK_CAAM_MEM>,
- <&clks IMX6QDL_CLK_CAAM_ACLK>,
- <&clks IMX6QDL_CLK_CAAM_IPG>,
- <&clks IMX6QDL_CLK_EIM_SLOW>;
- clock-names = "mem", "aclk", "ipg", "emi_slow";
- };
-
-
-iMX6UL does only require three clocks
-
- crypto: crypto@2140000 {
- compatible = "fsl,sec-v4.0";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x2140000 0x3c000>;
- ranges = <0 0x2140000 0x3c000>;
- interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
-
- clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
- <&clks IMX6UL_CLK_CAAM_ACLK>,
- <&clks IMX6UL_CLK_CAAM_IPG>;
- clock-names = "mem", "aclk", "ipg";
- };
-
-=====================================================================
-Job Ring (JR) Node
-
- Child of the crypto node defines data processing interface to SEC 4
- across the peripheral bus for purposes of processing
- cryptographic descriptors. The specified address
- range can be made visible to one (or more) cores.
- The interrupt defined for this node is controlled within
- the address range of this node.
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v4.0-job-ring"
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Specifies a two JR parameters: an offset from
- the parent physical address and the length the JR registers.
-
- - fsl,liodn
- Usage: optional-but-recommended
- Value type: <prop-encoded-array>
- Definition:
- Specifies the LIODN to be used in conjunction with
- the ppid-to-liodn table that specifies the PPID to LIODN mapping.
- Needed if the PAMU is used. Value is a 12 bit value
- where value is a LIODN ID for this JR. This property is
- normally set by boot firmware.
-
- - interrupts
- Usage: required
- Value type: <prop_encoded-array>
- Definition: Specifies the interrupts generated by this
- device. The value of the interrupts property
- consists of one interrupt specifier. The format
- of the specifier is defined by the binding document
- describing the node's interrupt parent.
-
-EXAMPLE
- jr@1000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x1000 0x1000>;
- fsl,liodn = <0x081>;
- interrupt-parent = <&mpic>;
- interrupts = <88 2>;
- };
-
-
-=====================================================================
-Run Time Integrity Check (RTIC) Node
-
- Child node of the crypto node. Defines a register space that
- contains up to 5 sets of addresses and their lengths (sizes) that
- will be checked at run time. After an initial hash result is
- calculated, these addresses are checked by HW to monitor any
- change. If any memory is modified, a Security Violation is
- triggered (see SNVS definition).
-
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v4.0-rtic".
-
- - #address-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing physical addresses in child nodes. Must
- have a value of 1.
-
- - #size-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing the size of physical addresses in
- child nodes. Must have a value of 1.
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies a two parameters:
- an offset from the parent physical address and the length
- the SEC4 registers.
-
- - ranges
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical address
- range of the SEC 4 register space (-SNVS not included). A
- triplet that includes the child address, parent address, &
- length.
-
-EXAMPLE
- rtic@6000 {
- compatible = "fsl,sec-v4.0-rtic";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x6000 0x100>;
- ranges = <0x0 0x6100 0xe00>;
- };
-
-=====================================================================
-Run Time Integrity Check (RTIC) Memory Node
- A child node that defines individual RTIC memory regions that are used to
- perform run-time integrity check of memory areas that should not modified.
- The node defines a register that contains the memory address &
- length (combined) and a second register that contains the hash result
- in big endian format.
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v4.0-rtic-memory".
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies two parameters:
- an offset from the parent physical address and the length:
-
- 1. The location of the RTIC memory address & length registers.
- 2. The location RTIC hash result.
-
- - fsl,rtic-region
- Usage: optional-but-recommended
- Value type: <prop-encoded-array>
- Definition:
- Specifies the HW address (36 bit address) for this region
- followed by the length of the HW partition to be checked;
- the address is represented as a 64 bit quantity followed
- by a 32 bit length.
-
- - fsl,liodn
- Usage: optional-but-recommended
- Value type: <prop-encoded-array>
- Definition:
- Specifies the LIODN to be used in conjunction with
- the ppid-to-liodn table that specifies the PPID to LIODN
- mapping. Needed if the PAMU is used. Value is a 12 bit value
- where value is a LIODN ID for this RTIC memory region. This
- property is normally set by boot firmware.
-
-EXAMPLE
- rtic-a@0 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x00 0x20 0x100 0x80>;
- fsl,liodn = <0x03c>;
- fsl,rtic-region = <0x12345678 0x12345678 0x12345678>;
- };
-
-=====================================================================
-Secure Non-Volatile Storage (SNVS) Node
-
- Node defines address range and the associated
- interrupt for the SNVS function. This function
- monitors security state information & reports
- security violations. This also included rtc,
- system power off and ON/OFF key.
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical
- address and length of the SEC4 configuration
- registers.
-
- - #address-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing physical addresses in child nodes. Must
- have a value of 1.
-
- - #size-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing the size of physical addresses in
- child nodes. Must have a value of 1.
-
- - ranges
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical address
- range of the SNVS register space. A triplet that includes
- the child address, parent address, & length.
-
- - interrupts
- Usage: optional
- Value type: <prop_encoded-array>
- Definition: Specifies the interrupts generated by this
- device. The value of the interrupts property
- consists of one interrupt specifier. The format
- of the specifier is defined by the binding document
- describing the node's interrupt parent.
-
-EXAMPLE
- sec_mon@314000 {
- compatible = "fsl,sec-v4.0-mon", "syscon";
- reg = <0x314000 0x1000>;
- ranges = <0 0x314000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <93 2>;
- };
-
-=====================================================================
-Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
-
- A SNVS child node that defines SNVS LP RTC.
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
-
- - interrupts
- Usage: required
- Value type: <prop_encoded-array>
- Definition: Specifies the interrupts generated by this
- device. The value of the interrupts property
- consists of one interrupt specifier. The format
- of the specifier is defined by the binding document
- describing the node's interrupt parent.
-
- - regmap
- Usage: required
- Value type: <phandle>
- Definition: this is phandle to the register map node.
-
- - offset
- Usage: option
- value type: <u32>
- Definition: LP register offset. default it is 0x34.
-
- - clocks
- Usage: optional, required if SNVS LP RTC requires explicit
- enablement of clocks
- Value type: <prop_encoded-array>
- Definition: a clock specifier describing the clock required for
- enabling and disabling SNVS LP RTC.
-
- - clock-names
- Usage: optional, required if SNVS LP RTC requires explicit
- enablement of clocks
- Value type: <string>
- Definition: clock name string should be "snvs-rtc".
-
-EXAMPLE
- sec_mon_rtc_lp@1 {
- compatible = "fsl,sec-v4.0-mon-rtc-lp";
- interrupts = <93 2>;
- regmap = <&snvs>;
- offset = <0x34>;
- clocks = <&clks IMX7D_SNVS_CLK>;
- clock-names = "snvs-rtc";
- };
-
-=====================================================================
-System ON/OFF key driver
-
- The snvs-pwrkey is designed to enable POWER key function which controlled
- by SNVS ONOFF, the driver can report the status of POWER key and wakeup
- system if pressed after system suspend.
-
- - compatible:
- Usage: required
- Value type: <string>
- Definition: Mush include "fsl,sec-v4.0-pwrkey".
-
- - interrupts:
- Usage: required
- Value type: <prop_encoded-array>
- Definition: The SNVS ON/OFF interrupt number to the CPU(s).
-
- - linux,keycode:
- Usage: option
- Value type: <int>
- Definition: Keycode to emit, KEY_POWER by default.
-
- - wakeup-source:
- Usage: option
- Value type: <boo>
- Definition: Button can wake-up the system.
-
- - regmap:
- Usage: required:
- Value type: <phandle>
- Definition: this is phandle to the register map node.
-
-EXAMPLE:
- snvs-pwrkey@020cc000 {
- compatible = "fsl,sec-v4.0-pwrkey";
- regmap = <&snvs>;
- interrupts = <0 4 0x4>
- linux,keycode = <116>; /* KEY_POWER */
- wakeup-source;
- };
-
-=====================================================================
-FULL EXAMPLE
-
- crypto: crypto@300000 {
- compatible = "fsl,sec-v4.0";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x300000 0x10000>;
- ranges = <0 0x300000 0x10000>;
- interrupt-parent = <&mpic>;
- interrupts = <92 2>;
-
- sec_jr0: jr@1000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x1000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <88 2>;
- };
-
- sec_jr1: jr@2000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x2000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <89 2>;
- };
-
- sec_jr2: jr@3000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x3000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <90 2>;
- };
-
- sec_jr3: jr@4000 {
- compatible = "fsl,sec-v4.0-job-ring";
- reg = <0x4000 0x1000>;
- interrupt-parent = <&mpic>;
- interrupts = <91 2>;
- };
-
- rtic@6000 {
- compatible = "fsl,sec-v4.0-rtic";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x6000 0x100>;
- ranges = <0x0 0x6100 0xe00>;
-
- rtic_a: rtic-a@0 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x00 0x20 0x100 0x80>;
- };
-
- rtic_b: rtic-b@20 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x20 0x20 0x200 0x80>;
- };
-
- rtic_c: rtic-c@40 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x40 0x20 0x300 0x80>;
- };
-
- rtic_d: rtic-d@60 {
- compatible = "fsl,sec-v4.0-rtic-memory";
- reg = <0x60 0x20 0x500 0x80>;
- };
- };
- };
-
- sec_mon: sec_mon@314000 {
- compatible = "fsl,sec-v4.0-mon";
- reg = <0x314000 0x1000>;
- ranges = <0 0x314000 0x1000>;
-
- sec_mon_rtc_lp@34 {
- compatible = "fsl,sec-v4.0-mon-rtc-lp";
- regmap = <&sec_mon>;
- offset = <0x34>;
- interrupts = <93 2>;
- clocks = <&clks IMX7D_SNVS_CLK>;
- clock-names = "snvs-rtc";
- };
-
- snvs-pwrkey@020cc000 {
- compatible = "fsl,sec-v4.0-pwrkey";
- regmap = <&sec_mon>;
- interrupts = <0 4 0x4>;
- linux,keycode = <116>; /* KEY_POWER */
- wakeup-source;
- };
- };
-
-=====================================================================
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt
deleted file mode 100644
index 73b0eb950bb3..000000000000
--- a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM).
-Currently Freescale powerpc chip C29X is embedded with SEC 6.
-SEC 6 device tree binding include:
- -SEC 6 Node
- -Job Ring Node
- -Full Example
-
-=====================================================================
-SEC 6 Node
-
-Description
-
- Node defines the base address of the SEC 6 block.
- This block specifies the address range of all global
- configuration registers for the SEC 6 block.
- For example, In C293, we could see three SEC 6 node.
-
-PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v6.0".
-
- - fsl,sec-era
- Usage: optional
- Value type: <u32>
- Definition: A standard property. Define the 'ERA' of the SEC
- device.
-
- - #address-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing physical addresses in child nodes.
-
- - #size-cells
- Usage: required
- Value type: <u32>
- Definition: A standard property. Defines the number of cells
- for representing the size of physical addresses in
- child nodes.
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical
- address and length of the SEC 6 configuration registers.
-
- - ranges
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical address
- range of the SEC 6.0 register space (-SNVS not included). A
- triplet that includes the child address, parent address, &
- length.
-
- Note: All other standard properties (see the Devicetree Specification)
- are allowed but are optional.
-
-EXAMPLE
- crypto@a0000 {
- compatible = "fsl,sec-v6.0";
- fsl,sec-era = <6>;
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xa0000 0x20000>;
- ranges = <0 0xa0000 0x20000>;
- };
-
-=====================================================================
-Job Ring (JR) Node
-
- Child of the crypto node defines data processing interface to SEC 6
- across the peripheral bus for purposes of processing
- cryptographic descriptors. The specified address
- range can be made visible to one (or more) cores.
- The interrupt defined for this node is controlled within
- the address range of this node.
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Must include "fsl,sec-v6.0-job-ring".
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Specifies a two JR parameters: an offset from
- the parent physical address and the length the JR registers.
-
- - interrupts
- Usage: required
- Value type: <prop_encoded-array>
- Definition: Specifies the interrupts generated by this
- device. The value of the interrupts property
- consists of one interrupt specifier. The format
- of the specifier is defined by the binding document
- describing the node's interrupt parent.
-
-EXAMPLE
- jr@1000 {
- compatible = "fsl,sec-v6.0-job-ring";
- reg = <0x1000 0x1000>;
- interrupts = <49 2 0 0>;
- };
-
-===================================================================
-Full Example
-
-Since some chips may contain more than one SEC, the dtsi contains
-only the node contents, not the node itself. A chip using the SEC
-should include the dtsi inside each SEC node. Example:
-
-In qoriq-sec6.0.dtsi:
-
- compatible = "fsl,sec-v6.0";
- fsl,sec-era = <6>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- jr@1000 {
- compatible = "fsl,sec-v6.0-job-ring",
- "fsl,sec-v5.2-job-ring",
- "fsl,sec-v5.0-job-ring",
- "fsl,sec-v4.4-job-ring",
- "fsl,sec-v4.0-job-ring";
- reg = <0x1000 0x1000>;
- };
-
- jr@2000 {
- compatible = "fsl,sec-v6.0-job-ring",
- "fsl,sec-v5.2-job-ring",
- "fsl,sec-v5.0-job-ring",
- "fsl,sec-v4.4-job-ring",
- "fsl,sec-v4.0-job-ring";
- reg = <0x2000 0x1000>;
- };
-
-In the C293 device tree, we add the include of public property:
-
- crypto@a0000 {
- /include/ "qoriq-sec6.0.dtsi"
- }
-
- crypto@a0000 {
- reg = <0xa0000 0x20000>;
- ranges = <0 0xa0000 0x20000>;
-
- jr@1000 {
- interrupts = <49 2 0 0>;
- };
-
- jr@2000 {
- interrupts = <50 2 0 0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/crypto/hisilicon,hip06-sec.yaml b/Documentation/devicetree/bindings/crypto/hisilicon,hip06-sec.yaml
new file mode 100644
index 000000000000..2bfac9d1c020
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/hisilicon,hip06-sec.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/hisilicon,hip06-sec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon hip06/hip07 Security Accelerator
+
+maintainers:
+ - Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,hip06-sec
+ - hisilicon,hip07-sec
+
+ reg:
+ items:
+ - description: Registers for backend processing engines
+ - description: Registers for common functionality
+ - description: Registers for queue 0
+ - description: Registers for queue 1
+ - description: Registers for queue 2
+ - description: Registers for queue 3
+ - description: Registers for queue 4
+ - description: Registers for queue 5
+ - description: Registers for queue 6
+ - description: Registers for queue 7
+ - description: Registers for queue 8
+ - description: Registers for queue 9
+ - description: Registers for queue 10
+ - description: Registers for queue 11
+ - description: Registers for queue 12
+ - description: Registers for queue 13
+ - description: Registers for queue 14
+ - description: Registers for queue 15
+
+ interrupts:
+ items:
+ - description: SEC unit error queue interrupt
+ - description: Completion interrupt for queue 0
+ - description: Error interrupt for queue 0
+ - description: Completion interrupt for queue 1
+ - description: Error interrupt for queue 1
+ - description: Completion interrupt for queue 2
+ - description: Error interrupt for queue 2
+ - description: Completion interrupt for queue 3
+ - description: Error interrupt for queue 3
+ - description: Completion interrupt for queue 4
+ - description: Error interrupt for queue 4
+ - description: Completion interrupt for queue 5
+ - description: Error interrupt for queue 5
+ - description: Completion interrupt for queue 6
+ - description: Error interrupt for queue 6
+ - description: Completion interrupt for queue 7
+ - description: Error interrupt for queue 7
+ - description: Completion interrupt for queue 8
+ - description: Error interrupt for queue 8
+ - description: Completion interrupt for queue 9
+ - description: Error interrupt for queue 9
+ - description: Completion interrupt for queue 10
+ - description: Error interrupt for queue 10
+ - description: Completion interrupt for queue 11
+ - description: Error interrupt for queue 11
+ - description: Completion interrupt for queue 12
+ - description: Error interrupt for queue 12
+ - description: Completion interrupt for queue 13
+ - description: Error interrupt for queue 13
+ - description: Completion interrupt for queue 14
+ - description: Error interrupt for queue 14
+ - description: Completion interrupt for queue 15
+ - description: Error interrupt for queue 15
+
+ dma-coherent: true
+
+ iommus:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dma-coherent
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ crypto@400d2000000 {
+ compatible = "hisilicon,hip07-sec";
+ reg = <0x400 0xd0000000 0x0 0x10000
+ 0x400 0xd2000000 0x0 0x10000
+ 0x400 0xd2010000 0x0 0x10000
+ 0x400 0xd2020000 0x0 0x10000
+ 0x400 0xd2030000 0x0 0x10000
+ 0x400 0xd2040000 0x0 0x10000
+ 0x400 0xd2050000 0x0 0x10000
+ 0x400 0xd2060000 0x0 0x10000
+ 0x400 0xd2070000 0x0 0x10000
+ 0x400 0xd2080000 0x0 0x10000
+ 0x400 0xd2090000 0x0 0x10000
+ 0x400 0xd20a0000 0x0 0x10000
+ 0x400 0xd20b0000 0x0 0x10000
+ 0x400 0xd20c0000 0x0 0x10000
+ 0x400 0xd20d0000 0x0 0x10000
+ 0x400 0xd20e0000 0x0 0x10000
+ 0x400 0xd20f0000 0x0 0x10000
+ 0x400 0xd2100000 0x0 0x10000>;
+ interrupts = <576 4>,
+ <577 1>, <578 4>,
+ <579 1>, <580 4>,
+ <581 1>, <582 4>,
+ <583 1>, <584 4>,
+ <585 1>, <586 4>,
+ <587 1>, <588 4>,
+ <589 1>, <590 4>,
+ <591 1>, <592 4>,
+ <593 1>, <594 4>,
+ <595 1>, <596 4>,
+ <597 1>, <598 4>,
+ <599 1>, <600 4>,
+ <601 1>, <602 4>,
+ <603 1>, <604 4>,
+ <605 1>, <606 4>,
+ <607 1>, <608 4>;
+ dma-coherent;
+ iommus = <&p1_smmu_alg_a 0x600>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt b/Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt
deleted file mode 100644
index d28fd1af01b4..000000000000
--- a/Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Hisilicon hip07 Security Accelerator (SEC)
-
-Required properties:
-- compatible: Must contain one of
- - "hisilicon,hip06-sec"
- - "hisilicon,hip07-sec"
-- reg: Memory addresses and lengths of the memory regions through which
- this device is controlled.
- Region 0 has registers to control the backend processing engines.
- Region 1 has registers for functionality common to all queues.
- Regions 2-18 have registers for the 16 individual queues which are isolated
- both in hardware and within the driver.
-- interrupts: Interrupt specifiers.
- Refer to interrupt-controller/interrupts.txt for generic interrupt client node
- bindings.
- Interrupt 0 is for the SEC unit error queue.
- Interrupt 2N + 1 is the completion interrupt for queue N.
- Interrupt 2N + 2 is the error interrupt for queue N.
-- dma-coherent: The driver assumes coherent dma is possible.
-
-Optional properties:
-- iommus: The SEC units are behind smmu-v3 iommus.
- Refer to iommu/arm,smmu-v3.txt for more information.
-
-Example:
-
-p1_sec_a: crypto@400d2000000 {
- compatible = "hisilicon,hip07-sec";
- reg = <0x400 0xd0000000 0x0 0x10000
- 0x400 0xd2000000 0x0 0x10000
- 0x400 0xd2010000 0x0 0x10000
- 0x400 0xd2020000 0x0 0x10000
- 0x400 0xd2030000 0x0 0x10000
- 0x400 0xd2040000 0x0 0x10000
- 0x400 0xd2050000 0x0 0x10000
- 0x400 0xd2060000 0x0 0x10000
- 0x400 0xd2070000 0x0 0x10000
- 0x400 0xd2080000 0x0 0x10000
- 0x400 0xd2090000 0x0 0x10000
- 0x400 0xd20a0000 0x0 0x10000
- 0x400 0xd20b0000 0x0 0x10000
- 0x400 0xd20c0000 0x0 0x10000
- 0x400 0xd20d0000 0x0 0x10000
- 0x400 0xd20e0000 0x0 0x10000
- 0x400 0xd20f0000 0x0 0x10000
- 0x400 0xd2100000 0x0 0x10000>;
- interrupt-parent = <&p1_mbigen_sec_a>;
- iommus = <&p1_smmu_alg_a 0x600>;
- dma-coherent;
- interrupts = <576 4>,
- <577 1>, <578 4>,
- <579 1>, <580 4>,
- <581 1>, <582 4>,
- <583 1>, <584 4>,
- <585 1>, <586 4>,
- <587 1>, <588 4>,
- <589 1>, <590 4>,
- <591 1>, <592 4>,
- <593 1>, <594 4>,
- <595 1>, <596 4>,
- <597 1>, <598 4>,
- <599 1>, <600 4>,
- <601 1>, <602 4>,
- <603 1>, <604 4>,
- <605 1>, <606 4>,
- <607 1>, <608 4>;
-};
diff --git a/Documentation/devicetree/bindings/crypto/img,hash-accelerator.yaml b/Documentation/devicetree/bindings/crypto/img,hash-accelerator.yaml
new file mode 100644
index 000000000000..46617561ef94
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/img,hash-accelerator.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/img,hash-accelerator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Technologies hardware hash accelerator
+
+maintainers:
+ - James Hartley <james.hartley@imgtec.com>
+
+description:
+ The hash accelerator provides hardware hashing acceleration for
+ SHA1, SHA224, SHA256 and MD5 hashes.
+
+properties:
+ compatible:
+ const: img,hash-accelerator
+
+ reg:
+ items:
+ - description: Register base address and size
+ - description: DMA port specifier
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: tx
+
+ clocks:
+ items:
+ - description: System clock for hash block registers
+ - description: Hash clock for data path
+
+ clock-names:
+ items:
+ - const: sys
+ - const: hash
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/clock/pistachio-clk.h>
+
+ hash@18149600 {
+ compatible = "img,hash-accelerator";
+ reg = <0x18149600 0x100>, <0x18101100 0x4>;
+ interrupts = <GIC_SHARED 59 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma 8 0xffffffff 0>;
+ dma-names = "tx";
+ clocks = <&cr_periph SYS_CLK_HASH>, <&clk_periph PERIPH_CLK_ROM>;
+ clock-names = "sys", "hash";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/img-hash.txt b/Documentation/devicetree/bindings/crypto/img-hash.txt
deleted file mode 100644
index 91a3d757d641..000000000000
--- a/Documentation/devicetree/bindings/crypto/img-hash.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Imagination Technologies hardware hash accelerator
-
-The hash accelerator provides hardware hashing acceleration for
-SHA1, SHA224, SHA256 and MD5 hashes
-
-Required properties:
-
-- compatible : "img,hash-accelerator"
-- reg : Offset and length of the register set for the module, and the DMA port
-- interrupts : The designated IRQ line for the hashing module.
-- dmas : DMA specifier as per Documentation/devicetree/bindings/dma/dma.txt
-- dma-names : Should be "tx"
-- clocks : Clock specifiers
-- clock-names : "sys" Used to clock the hash block registers
- "hash" Used to clock data through the accelerator
-
-Example:
-
- hash: hash@18149600 {
- compatible = "img,hash-accelerator";
- reg = <0x18149600 0x100>, <0x18101100 0x4>;
- interrupts = <GIC_SHARED 59 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma 8 0xffffffff 0>;
- dma-names = "tx";
- clocks = <&cr_periph SYS_CLK_HASH>, <&clk_periph PERIPH_CLK_ROM>;
- clock-names = "sys", "hash";
- };
diff --git a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml
new file mode 100644
index 000000000000..997bf9717f9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel-eip93.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Inside Secure SafeXcel EIP-93 cryptographic engine
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |
+ The Inside Secure SafeXcel EIP-93 is a cryptographic engine IP block
+ integrated in varios devices with very different and generic name from
+ PKTE to simply vendor+EIP93. The real IP under the hood is actually
+ developed by Inside Secure and given to license to vendors.
+
+ The IP block is sold with different model based on what feature are
+ needed and are identified with the final letter. Each letter correspond
+ to a specific set of feature and multiple letter reflect the sum of the
+ feature set.
+
+ EIP-93 models:
+ - EIP-93i: (basic) DES/Triple DES, AES, PRNG, IPsec ESP, SRTP, SHA1
+ - EIP-93ie: i + SHA224/256, AES-192/256
+ - EIP-93is: i + SSL/DTLS/DTLS, MD5, ARC4
+ - EIP-93ies: i + e + s
+ - EIP-93iw: i + AES-XCB-MAC, AES-CCM
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: airoha,en7581-eip93
+ - const: inside-secure,safexcel-eip93ies
+ - items:
+ - not: {}
+ description: Need a SoC specific compatible
+ - enum:
+ - inside-secure,safexcel-eip93i
+ - inside-secure,safexcel-eip93ie
+ - inside-secure,safexcel-eip93is
+ - inside-secure,safexcel-eip93iw
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ crypto@1e004000 {
+ compatible = "airoha,en7581-eip93", "inside-secure,safexcel-eip93ies";
+ reg = <0x1fb70000 0x1000>;
+
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml
new file mode 100644
index 000000000000..343e2d04c797
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Inside Secure SafeXcel cryptographic engine
+
+maintainers:
+ - Antoine Tenart <atenart@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: inside-secure,safexcel-eip197b
+ - const: inside-secure,safexcel-eip197d
+ - const: inside-secure,safexcel-eip97ies
+ - const: inside-secure,safexcel-eip197
+ description: Equivalent of inside-secure,safexcel-eip197b
+ deprecated: true
+ - const: inside-secure,safexcel-eip97
+ description: Equivalent of inside-secure,safexcel-eip97ies
+ deprecated: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 6
+
+ interrupt-names:
+ items:
+ - const: ring0
+ - const: ring1
+ - const: ring2
+ - const: ring3
+ - const: eip
+ - const: mem
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: reg
+
+ dma-coherent: true
+
+required:
+ - reg
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - if:
+ properties:
+ clocks:
+ minItems: 2
+ then:
+ properties:
+ clock-names:
+ minItems: 2
+ required:
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ crypto@800000 {
+ compatible = "inside-secure,safexcel-eip197b";
+ reg = <0x800000 0x200000>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ring0", "ring1", "ring2", "ring3", "eip", "mem";
+ clocks = <&cpm_syscon0 1 26>;
+ clock-names = "core";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
deleted file mode 100644
index 3bbf144c9988..000000000000
--- a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Inside Secure SafeXcel cryptographic engine
-
-Required properties:
-- compatible: Should be "inside-secure,safexcel-eip197b",
- "inside-secure,safexcel-eip197d" or
- "inside-secure,safexcel-eip97ies".
-- reg: Base physical address of the engine and length of memory mapped region.
-- interrupts: Interrupt numbers for the rings and engine.
-- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".
-
-Optional properties:
-- clocks: Reference to the crypto engine clocks, the second clock is
- needed for the Armada 7K/8K SoCs.
-- clock-names: mandatory if there is a second clock, in this case the
- name must be "core" for the first clock and "reg" for
- the second one.
-
-Backward compatibility:
-Two compatibles are kept for backward compatibility, but shouldn't be used for
-new submissions:
-- "inside-secure,safexcel-eip197" is equivalent to
- "inside-secure,safexcel-eip197b".
-- "inside-secure,safexcel-eip97" is equivalent to
- "inside-secure,safexcel-eip97ies".
-
-Example:
-
- crypto: crypto@800000 {
- compatible = "inside-secure,safexcel-eip197b";
- reg = <0x800000 0x200000>;
- interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3",
- "eip";
- clocks = <&cpm_syscon0 1 26>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml
index e0fe63957888..a4006237aa89 100644
--- a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml
+++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml
@@ -2,8 +2,8 @@
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx cryptographic engine
@@ -21,7 +21,7 @@ properties:
const: intel,ixp4xx-crypto
intel,npe-handle:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the NPE this crypto engine
diff --git a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
index ee2c099981b2..fedd8be56ad6 100644
--- a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
+++ b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/intel,keembay-ocs-aes.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Keem Bay OCS AES Device Tree Bindings
+title: Intel Keem Bay OCS AES
maintainers:
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
diff --git a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml
index a3c16451b1ad..2bb95247b64f 100644
--- a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml
+++ b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-ecc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/intel,keembay-ocs-ecc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Keem Bay OCS ECC Device Tree Bindings
+title: Intel Keem Bay OCS ECC
maintainers:
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
diff --git a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-hcu.yaml b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-hcu.yaml
index acb92706d280..46e2853ab8f4 100644
--- a/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-hcu.yaml
+++ b/Documentation/devicetree/bindings/crypto/intel,keembay-ocs-hcu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/intel,keembay-ocs-hcu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Keem Bay OCS HCU Device Tree Bindings
+title: Intel Keem Bay OCS HCU
maintainers:
- Declan Murphy <declan.murphy@intel.com>
diff --git a/Documentation/devicetree/bindings/crypto/marvell,orion-crypto.yaml b/Documentation/devicetree/bindings/crypto/marvell,orion-crypto.yaml
new file mode 100644
index 000000000000..b44d36c50ec4
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/marvell,orion-crypto.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/marvell,orion-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Cryptographic Engines And Security Accelerator
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Boris Brezillon <bbrezillon@kernel.org>
+
+description: |
+ Marvell Cryptographic Engines And Security Accelerator
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-370-crypto
+ - marvell,armada-xp-crypto
+ - marvell,armada-375-crypto
+ - marvell,armada-38x-crypto
+ - marvell,dove-crypto
+ - marvell,kirkwood-crypto
+ - marvell,orion-crypto
+
+ reg:
+ minItems: 1
+ items:
+ - description: Registers region
+ - description: SRAM region
+ deprecated: true
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: regs
+ - const: sram
+ deprecated: true
+
+ interrupts:
+ description: One interrupt for each CESA engine
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ description: One or two clocks for each CESA engine
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: cesa0
+ - const: cesa1
+ - const: cesaz0
+ - const: cesaz1
+
+ marvell,crypto-srams:
+ description: Phandle(s) to crypto SRAM.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 2
+ items:
+ maxItems: 1
+
+ marvell,crypto-sram-size:
+ description: SRAM size reserved for crypto operations.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x800
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - marvell,crypto-srams
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - marvell,kirkwood-crypto
+ - marvell,orion-crypto
+ then:
+ required:
+ - clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,armada-370-crypto
+ - marvell,armada-375-crypto
+ - marvell,armada-38x-crypto
+ - marvell,armada-xp-crypto
+ then:
+ required:
+ - clock-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,armada-375-crypto
+ - marvell,armada-38x-crypto
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+ else:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ crypto@30000 {
+ compatible = "marvell,orion-crypto";
+ reg = <0x30000 0x10000>;
+ reg-names = "regs";
+ interrupts = <22>;
+ marvell,crypto-srams = <&crypto_sram>;
+ marvell,crypto-sram-size = <0x600>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
deleted file mode 100644
index 28d3f2496b89..000000000000
--- a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Marvell Cryptographic Engines And Security Accelerator
-
-Required properties:
-- compatible: should be one of the following string
- "marvell,orion-crypto"
- "marvell,kirkwood-crypto"
- "marvell,dove-crypto"
- "marvell,armada-370-crypto"
- "marvell,armada-xp-crypto"
- "marvell,armada-375-crypto"
- "marvell,armada-38x-crypto"
-- reg: base physical address of the engine and length of memory mapped
- region. Can also contain an entry for the SRAM attached to the CESA,
- but this representation is deprecated and marvell,crypto-srams should
- be used instead
-- reg-names: "regs". Can contain an "sram" entry, but this representation
- is deprecated and marvell,crypto-srams should be used instead
-- interrupts: interrupt number
-- clocks: reference to the crypto engines clocks. This property is not
- required for orion and kirkwood platforms
-- clock-names: "cesaX" and "cesazX", X should be replaced by the crypto engine
- id.
- This property is not required for the orion and kirkwoord
- platforms.
- "cesazX" clocks are not required on armada-370 platforms
-- marvell,crypto-srams: phandle to crypto SRAM definitions
-
-Optional properties:
-- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
- specified the whole SRAM is used (2KB)
-
-
-Examples:
-
- crypto@90000 {
- compatible = "marvell,armada-xp-crypto";
- reg = <0x90000 0x10000>;
- reg-names = "regs";
- interrupts = <48>, <49>;
- clocks = <&gateclk 23>, <&gateclk 23>;
- clock-names = "cesa0", "cesa1";
- marvell,crypto-srams = <&crypto_sram0>, <&crypto_sram1>;
- marvell,crypto-sram-size = <0x600>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
deleted file mode 100644
index 450da3661cad..000000000000
--- a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-MediaTek cryptographic accelerators
-
-Required properties:
-- compatible: Should be "mediatek,eip97-crypto"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the five crypto engines interrupts in numeric
- order. These are global system and four descriptor rings.
-- clocks: the clock used by the core
-- clock-names: Must contain "cryp".
-- power-domains: Must contain a reference to the PM domain.
-
-
-Example:
- crypto: crypto@1b240000 {
- compatible = "mediatek,eip97-crypto";
- reg = <0 0x1b240000 0 0x20000>;
- interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&ethsys CLK_ETHSYS_CRYPTO>;
- clock-names = "cryp";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt
deleted file mode 100644
index d9b92e2f3138..000000000000
--- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Marvell Cryptographic Engines And Security Accelerator
-
-Required properties:
-- compatible: should be one of the following string
- "marvell,orion-crypto"
- "marvell,kirkwood-crypto"
- "marvell,dove-crypto"
-- reg: base physical address of the engine and length of memory mapped
- region. Can also contain an entry for the SRAM attached to the CESA,
- but this representation is deprecated and marvell,crypto-srams should
- be used instead
-- reg-names: "regs". Can contain an "sram" entry, but this representation
- is deprecated and marvell,crypto-srams should be used instead
-- interrupts: interrupt number
-- clocks: reference to the crypto engines clocks. This property is only
- required for Dove platforms
-- marvell,crypto-srams: phandle to crypto SRAM definitions
-
-Optional properties:
-- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
- specified the whole SRAM is used (2KB)
-
-Examples:
-
- crypto@30000 {
- compatible = "marvell,orion-crypto";
- reg = <0x30000 0x10000>;
- reg-names = "regs";
- interrupts = <22>;
- marvell,crypto-srams = <&crypto_sram>;
- marvell,crypto-sram-size = <0x600>;
- };
diff --git a/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml
new file mode 100644
index 000000000000..cb47ae2889b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-aes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Security Engine for AES algorithms
+
+description:
+ The Tegra Security Engine accelerates the following AES encryption/decryption
+ algorithms - AES-ECB, AES-CBC, AES-OFB, AES-XTS, AES-CTR, AES-GCM, AES-CCM,
+ AES-CMAC
+
+maintainers:
+ - Akhil R <akhilrajeev@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra234-se-aes
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - iommus
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/clock/tegra234-clock.h>
+
+ crypto@15820000 {
+ compatible = "nvidia,tegra234-se-aes";
+ reg = <0x15820000 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_SE>;
+ iommus = <&smmu TEGRA234_SID_SES_SE1>;
+ dma-coherent;
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml
new file mode 100644
index 000000000000..f57ef10645e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-hash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Security Engine for HASH algorithms
+
+description:
+ The Tegra Security HASH Engine accelerates the following HASH functions -
+ SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512
+ HMAC(SHA224), HMAC(SHA256), HMAC(SHA384), HMAC(SHA512)
+
+maintainers:
+ - Akhil R <akhilrajeev@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra234-se-hash
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - iommus
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/clock/tegra234-clock.h>
+
+ crypto@15840000 {
+ compatible = "nvidia,tegra234-se-hash";
+ reg = <0x15840000 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_SE>;
+ iommus = <&smmu TEGRA234_SID_SES_SE2>;
+ dma-coherent;
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/omap-aes.txt b/Documentation/devicetree/bindings/crypto/omap-aes.txt
deleted file mode 100644
index fd9717653cbb..000000000000
--- a/Documentation/devicetree/bindings/crypto/omap-aes.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OMAP SoC AES crypto Module
-
-Required properties:
-
-- compatible : Should contain entries for this and backward compatible
- AES versions:
- - "ti,omap2-aes" for OMAP2.
- - "ti,omap3-aes" for OMAP3.
- - "ti,omap4-aes" for OMAP4 and AM33XX.
- Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
- more algorithms) but they are incompatible with OMAP4.
-- ti,hwmods: Name of the hwmod associated with the AES module
-- reg : Offset and length of the register set for the module
-- interrupts : the interrupt-specifier for the AES module.
-
-Optional properties:
-- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
- Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: DMA request names should include "tx" and "rx" if present.
-
-Example:
- /* AM335x */
- aes: aes@53500000 {
- compatible = "ti,omap4-aes";
- ti,hwmods = "aes";
- reg = <0x53500000 0xa0>;
- interrupts = <102>;
- dmas = <&edma 6>,
- <&edma 5>;
- dma-names = "tx", "rx";
- };
diff --git a/Documentation/devicetree/bindings/crypto/omap-des.txt b/Documentation/devicetree/bindings/crypto/omap-des.txt
deleted file mode 100644
index e8c63bf2e16d..000000000000
--- a/Documentation/devicetree/bindings/crypto/omap-des.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-OMAP SoC DES crypto Module
-
-Required properties:
-
-- compatible : Should contain "ti,omap4-des"
-- ti,hwmods: Name of the hwmod associated with the DES module
-- reg : Offset and length of the register set for the module
-- interrupts : the interrupt-specifier for the DES module
-- clocks : A phandle to the functional clock node of the DES module
- corresponding to each entry in clock-names
-- clock-names : Name of the functional clock, should be "fck"
-
-Optional properties:
-- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
- Documentation/devicetree/bindings/dma/dma.txt
- Each entry corresponds to an entry in dma-names
-- dma-names: DMA request names should include "tx" and "rx" if present
-
-Example:
- /* DRA7xx SoC */
- des: des@480a5000 {
- compatible = "ti,omap4-des";
- ti,hwmods = "des";
- reg = <0x480a5000 0xa0>;
- interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&sdma 117>, <&sdma 116>;
- dma-names = "tx", "rx";
- clocks = <&l3_iclk_div>;
- clock-names = "fck";
- };
diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
deleted file mode 100644
index ad9115569611..000000000000
--- a/Documentation/devicetree/bindings/crypto/omap-sham.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-OMAP SoC SHA crypto Module
-
-Required properties:
-
-- compatible : Should contain entries for this and backward compatible
- SHAM versions:
- - "ti,omap2-sham" for OMAP2 & OMAP3.
- - "ti,omap4-sham" for OMAP4 and AM33XX.
- - "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
-- ti,hwmods: Name of the hwmod associated with the SHAM module
-- reg : Offset and length of the register set for the module
-- interrupts : the interrupt-specifier for the SHAM module.
-
-Optional properties:
-- dmas: DMA specifiers for the rx dma. See the DMA client binding,
- Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: DMA request name. Should be "rx" if a dma is present.
-
-Example:
- /* AM335x */
- sham: sham@53100000 {
- compatible = "ti,omap4-sham";
- ti,hwmods = "sham";
- reg = <0x53100000 0x200>;
- interrupts = <109>;
- dmas = <&edma 36>;
- dma-names = "rx";
- };
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
new file mode 100644
index 000000000000..c3408dcf5d20
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/qcom,inline-crypto-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. (QTI) Inline Crypto Engine
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,kaanapali-inline-crypto-engine
+ - qcom,qcs8300-inline-crypto-engine
+ - qcom,sa8775p-inline-crypto-engine
+ - qcom,sc7180-inline-crypto-engine
+ - qcom,sc7280-inline-crypto-engine
+ - qcom,sm8450-inline-crypto-engine
+ - qcom,sm8550-inline-crypto-engine
+ - qcom,sm8650-inline-crypto-engine
+ - qcom,sm8750-inline-crypto-engine
+ - const: qcom,inline-crypto-engine
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+
+ crypto@1d88000 {
+ compatible = "qcom,sm8550-inline-crypto-engine",
+ "qcom,inline-crypto-engine";
+ reg = <0x01d88000 0x8000>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index bb42f4588b40..597441d94cf1 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -11,9 +11,26 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,prng # 8916 etc.
- - qcom,prng-ee # 8996 and later using EE
+ oneOf:
+ - enum:
+ - qcom,prng # 8916 etc.
+ - qcom,prng-ee # 8996 and later using EE
+ - items:
+ - enum:
+ - qcom,ipq5332-trng
+ - qcom,ipq5424-trng
+ - qcom,ipq9574-trng
+ - qcom,kaanapali-trng
+ - qcom,qcs615-trng
+ - qcom,qcs8300-trng
+ - qcom,sa8255p-trng
+ - qcom,sa8775p-trng
+ - qcom,sc7280-trng
+ - qcom,sm8450-trng
+ - qcom,sm8550-trng
+ - qcom,sm8650-trng
+ - qcom,sm8750-trng
+ - const: qcom,trng
reg:
maxItems: 1
@@ -28,8 +45,18 @@ properties:
required:
- compatible
- reg
- - clocks
- - clock-names
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: qcom,trng
+ then:
+ required:
+ - clocks
+ - clock-names
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.txt b/Documentation/devicetree/bindings/crypto/qcom-qce.txt
deleted file mode 100644
index fdd53b184ba8..000000000000
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Qualcomm crypto engine driver
-
-Required properties:
-
-- compatible : should be "qcom,crypto-v5.1"
-- reg : specifies base physical address and size of the registers map
-- clocks : phandle to clock-controller plus clock-specifier pair
-- clock-names : "iface" clocks register interface
- "bus" clocks data transfer interface
- "core" clocks rest of the crypto block
-- dmas : DMA specifiers for tx and rx dma channels. For more see
- Documentation/devicetree/bindings/dma/dma.txt
-- dma-names : DMA request names should be "rx" and "tx"
-
-Example:
- crypto@fd45a000 {
- compatible = "qcom,crypto-v5.1";
- reg = <0xfd45a000 0x6000>;
- clocks = <&gcc GCC_CE2_AHB_CLK>,
- <&gcc GCC_CE2_AXI_CLK>,
- <&gcc GCC_CE2_CLK>;
- clock-names = "iface", "bus", "core";
- dmas = <&cryptobam 2>, <&cryptobam 3>;
- dma-names = "rx", "tx";
- };
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
new file mode 100644
index 000000000000..79d5be2548bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/qcom-qce.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm crypto engine driver
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ This document defines the binding for the QCE crypto
+ controller found on Qualcomm parts.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,crypto-v5.1
+ deprecated: true
+ description: Kept only for ABI backward compatibility
+
+ - const: qcom,crypto-v5.4
+ deprecated: true
+ description: Kept only for ABI backward compatibility
+
+ - items:
+ - enum:
+ - qcom,ipq4019-qce
+ - qcom,sm8150-qce
+ - const: qcom,qce
+
+ - items:
+ - enum:
+ - qcom,ipq6018-qce
+ - qcom,ipq8074-qce
+ - qcom,ipq9574-qce
+ - qcom,msm8996-qce
+ - qcom,qcm2290-qce
+ - qcom,sdm845-qce
+ - qcom,sm6115-qce
+ - const: qcom,ipq4019-qce
+ - const: qcom,qce
+
+ - items:
+ - enum:
+ - qcom,kaanapali-qce
+ - qcom,qcs615-qce
+ - qcom,qcs8300-qce
+ - qcom,sa8775p-qce
+ - qcom,sc7280-qce
+ - qcom,sm6350-qce
+ - qcom,sm8250-qce
+ - qcom,sm8350-qce
+ - qcom,sm8450-qce
+ - qcom,sm8550-qce
+ - qcom,sm8650-qce
+ - qcom,sm8750-qce
+ - qcom,x1e80100-qce
+ - const: qcom,sm8150-qce
+ - const: qcom,qce
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ iommus:
+ minItems: 1
+ maxItems: 8
+ description:
+ phandle to apps_smmu node with sid mask.
+
+ interconnects:
+ maxItems: 1
+ description:
+ Interconnect path between qce crypto and main memory.
+
+ interconnect-names:
+ const: memory
+
+ dmas:
+ items:
+ - description: DMA specifiers for rx dma channel.
+ - description: DMA specifiers for tx dma channel.
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,crypto-v5.1
+ - qcom,crypto-v5.4
+ - qcom,ipq6018-qce
+ - qcom,ipq8074-qce
+ - qcom,ipq9574-qce
+ - qcom,msm8996-qce
+ - qcom,sdm845-qce
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ required:
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcm2290-qce
+ - qcom,sm6115-qce
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: core
+ required:
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8150-qce
+ then:
+ properties:
+ clocks: false
+ clock-names: false
+
+required:
+ - compatible
+ - reg
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-apq8084.h>
+ crypto-engine@fd45a000 {
+ compatible = "qcom,ipq6018-qce", "qcom,ipq4019-qce", "qcom,qce";
+ reg = <0xfd45a000 0x6000>;
+ clocks = <&gcc GCC_CE2_AHB_CLK>,
+ <&gcc GCC_CE2_AXI_CLK>,
+ <&gcc GCC_CE2_CLK>;
+ clock-names = "iface", "bus", "core";
+ dmas = <&cryptobam 2>, <&cryptobam 3>;
+ dma-names = "rx", "tx";
+ iommus = <&apps_smmu 0x584 0x0011>,
+ <&apps_smmu 0x586 0x0011>,
+ <&apps_smmu 0x594 0x0011>,
+ <&apps_smmu 0x596 0x0011>;
+ };
diff --git a/Documentation/devicetree/bindings/crypto/rockchip,rk3288-crypto.yaml b/Documentation/devicetree/bindings/crypto/rockchip,rk3288-crypto.yaml
new file mode 100644
index 000000000000..f1a9da8bff7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip,rk3288-crypto.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/rockchip,rk3288-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Electronics Security Accelerator
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3288-crypto
+ - rockchip,rk3328-crypto
+ - rockchip,rk3399-crypto
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 4
+
+ clock-names:
+ minItems: 3
+ maxItems: 4
+
+ resets:
+ minItems: 1
+ maxItems: 3
+
+ reset-names:
+ minItems: 1
+ maxItems: 3
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3288-crypto
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ items:
+ - const: aclk
+ - const: hclk
+ - const: sclk
+ - const: apb_pclk
+ resets:
+ maxItems: 1
+ reset-names:
+ items:
+ - const: crypto-rst
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3328-crypto
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: hclk_master
+ - const: hclk_slave
+ - const: sclk
+ resets:
+ maxItems: 1
+ reset-names:
+ items:
+ - const: crypto-rst
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3399-crypto
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: hclk_master
+ - const: hclk_slave
+ - const: sclk
+ resets:
+ minItems: 3
+ reset-names:
+ items:
+ - const: master
+ - const: slave
+ - const: crypto-rst
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/rk3288-cru.h>
+ crypto@ff8a0000 {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a0000 0x4000>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+ <&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+ clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+ resets = <&cru SRST_CRYPTO>;
+ reset-names = "crypto-rst";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
deleted file mode 100644
index 5e2ba385b8c9..000000000000
--- a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Rockchip Electronics And Security Accelerator
-
-Required properties:
-- compatible: Should be "rockchip,rk3288-crypto"
-- reg: Base physical address of the engine and length of memory mapped
- region
-- interrupts: Interrupt number
-- clocks: Reference to the clocks about crypto
-- clock-names: "aclk" used to clock data
- "hclk" used to clock data
- "sclk" used to clock crypto accelerator
- "apb_pclk" used to clock dma
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the name "crypto-rst".
-
-Examples:
-
- crypto: cypto-controller@ff8a0000 {
- compatible = "rockchip,rk3288-crypto";
- reg = <0xff8a0000 0x4000>;
- interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
- <&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
- clock-names = "aclk", "hclk", "sclk", "apb_pclk";
- resets = <&cru SRST_CRYPTO>;
- reset-names = "crypto-rst";
- };
diff --git a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml
index 676950bb7b37..5b31891c97fe 100644
--- a/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml
+++ b/Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml
@@ -24,7 +24,6 @@ properties:
maxItems: 1
clocks:
- minItems: 2
maxItems: 2
clock-names:
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml
index b72e4858f9aa..50b2c2e0c3cd 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/st,stm32-crc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 CRC bindings
+title: STMicroelectronics STM32 CRC
maintainers:
- Lionel Debieve <lionel.debieve@foss.st.com>
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
index ed23bf94a8e0..27354658d054 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
@@ -4,7 +4,11 @@
$id: http://devicetree.org/schemas/crypto/st,stm32-cryp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 CRYP bindings
+title: STMicroelectronics STM32 CRYP
+
+description: The STM32 CRYP block is built on the CRYP block found in
+ the STn8820 SoC introduced in 2007, and subsequently used in the U8500
+ SoC in 2010.
maintainers:
- Lionel Debieve <lionel.debieve@foss.st.com>
@@ -12,6 +16,8 @@ maintainers:
properties:
compatible:
enum:
+ - st,stn8820-cryp
+ - stericsson,ux500-cryp
- st,stm32f756-cryp
- st,stm32mp1-cryp
@@ -27,6 +33,23 @@ properties:
resets:
maxItems: 1
+ dmas:
+ items:
+ - description: mem2cryp DMA channel
+ - description: cryp2mem DMA channel
+
+ dma-names:
+ items:
+ - const: mem2cryp
+ - const: cryp2mem
+
+ power-domains:
+ maxItems: 1
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
index 10ba94792d95..822318414095 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -4,7 +4,11 @@
$id: http://devicetree.org/schemas/crypto/st,stm32-hash.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 HASH bindings
+title: STMicroelectronics STM32 HASH
+
+description: The STM32 HASH block is built on the HASH block found in
+ the STn8820 SoC introduced in 2007, and subsequently used in the U8500
+ SoC in 2010.
maintainers:
- Lionel Debieve <lionel.debieve@foss.st.com>
@@ -12,8 +16,11 @@ maintainers:
properties:
compatible:
enum:
+ - st,stn8820-hash
+ - stericsson,ux500-hash
- st,stm32f456-hash
- st,stm32f756-hash
+ - st,stm32mp13-hash
reg:
maxItems: 1
@@ -41,11 +48,30 @@ properties:
maximum: 2
default: 0
+ power-domains:
+ maxItems: 1
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
- clocks
- - interrupts
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ items:
+ const: stericsson,ux500-hash
+ then:
+ properties:
+ interrupts: false
+ else:
+ required:
+ - interrupts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml
new file mode 100644
index 000000000000..7ccb6e1641d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/starfive,jh7110-crypto.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/starfive,jh7110-crypto.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive Cryptographic Module
+
+maintainers:
+ - Jia Jie Ho <jiajie.ho@starfivetech.com>
+ - William Qiu <william.qiu@starfivetech.com>
+
+properties:
+ compatible:
+ enum:
+ - starfive,jh7110-crypto
+ - starfive,jh8100-crypto
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Hardware reference clock
+ - description: AHB reference clock
+
+ clock-names:
+ items:
+ - const: hclk
+ - const: ahb
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: SHA2 module irq
+ - description: SM3 module irq
+
+ resets:
+ maxItems: 1
+
+ dmas:
+ items:
+ - description: TX DMA channel
+ - description: RX DMA channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: starfive,jh7110-crypto
+
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ const: starfive,jh8100-crypto
+
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+
+examples:
+ - |
+ crypto: crypto@16000000 {
+ compatible = "starfive,jh7110-crypto";
+ reg = <0x16000000 0x4000>;
+ clocks = <&clk 15>, <&clk 16>;
+ clock-names = "hclk", "ahb";
+ interrupts = <28>;
+ resets = <&reset 3>;
+ dmas = <&dma 1 2>,
+ <&dma 0 2>;
+ dma-names = "tx", "rx";
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/ti,am62l-dthev2.yaml b/Documentation/devicetree/bindings/crypto/ti,am62l-dthev2.yaml
new file mode 100644
index 000000000000..5486bfeb2fe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ti,am62l-dthev2.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/ti,am62l-dthev2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: K3 SoC DTHE V2 crypto module
+
+maintainers:
+ - T Pratham <t-pratham@ti.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,am62l-dthev2
+
+ reg:
+ maxItems: 1
+
+ dmas:
+ items:
+ - description: AES Engine RX DMA Channel
+ - description: AES Engine TX DMA Channel
+ - description: SHA Engine TX DMA Channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx1
+ - const: tx2
+
+required:
+ - compatible
+ - reg
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ crypto@40800000 {
+ compatible = "ti,am62l-dthev2";
+ reg = <0x40800000 0x10000>;
+
+ dmas = <&main_bcdma 0 0 0x4700 0>,
+ <&main_bcdma 0 0 0xc701 0>,
+ <&main_bcdma 0 0 0xc700 0>;
+ dma-names = "rx", "tx1", "tx2";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
new file mode 100644
index 000000000000..d69b50228009
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/ti,omap-sham.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP SoC SHA crypto Module
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2-sham
+ - ti,omap4-sham
+ - ti,omap5-sham
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+ ti,hwmods:
+ description: Name of the hwmod associated with the SHAM module
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [sham]
+
+dependencies:
+ dmas: [dma-names]
+
+additionalProperties: false
+
+required:
+ - compatible
+ - ti,hwmods
+ - reg
+ - interrupts
+
+examples:
+ - |
+ sham@53100000 {
+ compatible = "ti,omap4-sham";
+ ti,hwmods = "sham";
+ reg = <0x53100000 0x200>;
+ interrupts = <109>;
+ dmas = <&edma 36>;
+ dma-names = "rx";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/ti,omap2-aes.yaml b/Documentation/devicetree/bindings/crypto/ti,omap2-aes.yaml
new file mode 100644
index 000000000000..90e92050ad2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ti,omap2-aes.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ti,omap2-aes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP SoC AES crypto Module
+
+maintainers:
+ - Aaro Koskinen <aaro.koskinen@iki.fi>
+ - Andreas Kemnade <andreas@kemnade.info>
+ - Kevin Hilman <khilman@baylibre.com>
+ - Roger Quadros <rogerq@kernel.org>
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2-aes
+ - ti,omap3-aes
+ - ti,omap4-aes
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ ti,hwmods:
+ description: Name of the hwmod associated with the AES module
+ const: aes
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ aes@53500000 {
+ compatible = "ti,omap4-aes";
+ reg = <0x53500000 0xa0>;
+ interrupts = <102>;
+ dmas = <&edma 6>,
+ <&edma 5>;
+ dma-names = "tx", "rx";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/ti,omap4-des.yaml b/Documentation/devicetree/bindings/crypto/ti,omap4-des.yaml
new file mode 100644
index 000000000000..f02f1e141218
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ti,omap4-des.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ti,omap4-des.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP4 DES crypto Module
+
+maintainers:
+ - Aaro Koskinen <aaro.koskinen@iki.fi>
+ - Andreas Kemnade <andreas@kemnade.info>
+ - Kevin Hilman <khilman@baylibre.com>
+ - Roger Quadros <rogerq@kernel.org>
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ const: ti,omap4-des
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: fck
+
+dependencies:
+ dmas: [ dma-names ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ des@480a5000 {
+ compatible = "ti,omap4-des";
+ reg = <0x480a5000 0xa0>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&l3_iclk_div>;
+ clock-names = "fck";
+ dmas = <&sdma 117>, <&sdma 116>;
+ dma-names = "tx", "rx";
+ };
diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
index 02f47c2e7998..ff10a0838ad6 100644
--- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
+++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/ti,sa2ul.yaml#
@@ -26,8 +26,8 @@ properties:
dmas:
items:
- description: TX DMA Channel
- - description: RX DMA Channel #1
- - description: RX DMA Channel #2
+ - description: 'RX DMA Channel #1'
+ - description: 'RX DMA Channel #2'
dma-names:
items:
@@ -35,8 +35,6 @@ properties:
- const: rx1
- const: rx2
- dma-coherent: true
-
"#address-cells":
const: 2
@@ -68,19 +66,21 @@ patternProperties:
required:
- compatible
- reg
- - power-domains
- dmas
- dma-names
-if:
- properties:
- compatible:
- enum:
- - ti,j721e-sa2ul
- - ti,am654-sa2ul
-then:
- required:
- - dma-coherent
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am62-sa3ul
+ then:
+ properties:
+ power-domains: false
+ else:
+ required:
+ - power-domains
additionalProperties: false
@@ -95,5 +95,4 @@ examples:
dmas = <&main_udmap 0xc000>, <&main_udmap 0x4000>,
<&main_udmap 0x4001>;
dma-names = "tx", "rx1", "rx2";
- dma-coherent;
};
diff --git a/Documentation/devicetree/bindings/crypto/xlnx,versal-trng.yaml b/Documentation/devicetree/bindings/crypto/xlnx,versal-trng.yaml
new file mode 100644
index 000000000000..9dfb0b0ab5c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/xlnx,versal-trng.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/xlnx,versal-trng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal True Random Number Generator Hardware Accelerator
+
+maintainers:
+ - Harsh Jain <h.jain@amd.com>
+ - Mounika Botcha <mounika.botcha@amd.com>
+
+description:
+ The Versal True Random Number Generator consists of Ring Oscillators as
+ entropy source and a deterministic CTR_DRBG random bit generator (DRBG).
+
+properties:
+ compatible:
+ const: xlnx,versal-trng
+
+ reg:
+ maxItems: 1
+
+required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rng@f1230000 {
+ compatible = "xlnx,versal-trng";
+ reg = <0xf1230000 0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml
index 55dd6e3d270d..8aead97a585b 100644
--- a/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml
+++ b/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/crypto/xlnx,zynqmp-aes.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx ZynqMP AES-GCM Hardware Accelerator Device Tree Bindings
+title: Xilinx ZynqMP AES-GCM Hardware Accelerator
maintainers:
- - Kalyani Akula <kalyani.akula@xilinx.com>
- - Michal Simek <michal.simek@xilinx.com>
+ - Kalyani Akula <kalyani.akula@amd.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
The ZynqMP AES-GCM hardened cryptographic accelerator is used to
diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip,dfi.yaml b/Documentation/devicetree/bindings/devfreq/event/rockchip,dfi.yaml
new file mode 100644
index 000000000000..50d3fabe958d
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip,dfi.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/devfreq/event/rockchip,dfi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DFI
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3399-dfi
+ - rockchip,rk3568-dfi
+ - rockchip,rk3588-dfi
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pclk_ddr_mon
+
+ interrupts:
+ minItems: 1
+ maxItems: 4
+
+ reg:
+ maxItems: 1
+
+ rockchip,pmu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the "PMU general register files".
+
+required:
+ - compatible
+ - interrupts
+ - reg
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3399-dfi
+
+then:
+ required:
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/rk3308-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dfi: dfi@ff630000 {
+ compatible = "rockchip,rk3399-dfi";
+ reg = <0x00 0xff630000 0x00 0x4000>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH 0>;
+ rockchip,pmu = <&pmugrf>;
+ clocks = <&cru PCLK_DDR_MON>;
+ clock-names = "pclk_ddr_mon";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
deleted file mode 100644
index 148191b0fc15..000000000000
--- a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-
-* Rockchip rk3399 DFI device
-
-Required properties:
-- compatible: Must be "rockchip,rk3399-dfi".
-- reg: physical base address of each DFI and length of memory mapped region
-- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
-- clocks: phandles for clock specified in "clock-names" property
-- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
-
-Example:
- dfi: dfi@ff630000 {
- compatible = "rockchip,rk3399-dfi";
- reg = <0x00 0xff630000 0x00 0x4000>;
- rockchip,pmu = <&pmugrf>;
- clocks = <&cru PCLK_DDR_MON>;
- clock-names = "pclk_ddr_mon";
- };
diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml
index e300df4b47f3..d27dcb2fef12 100644
--- a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml
+++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml
@@ -18,7 +18,7 @@ description: |
each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC). The
Exynos PPMU driver uses the devfreq-event class to provide event data to
various devfreq devices. The devfreq devices would use the event data when
- derterming the current state of each IP.
+ determining the current state of each IP.
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml
index e3379d106728..ea1dc86bc31f 100644
--- a/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml
+++ b/Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml
@@ -19,11 +19,14 @@ description: |
properties:
compatible:
- enum:
- - nvidia,tegra30-actmon
- - nvidia,tegra114-actmon
- - nvidia,tegra124-actmon
- - nvidia,tegra210-actmon
+ oneOf:
+ - enum:
+ - nvidia,tegra30-actmon
+ - nvidia,tegra114-actmon
+ - nvidia,tegra124-actmon
+ - items:
+ - const: nvidia,tegra210-actmon
+ - const: nvidia,tegra124-actmon
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
index 3d8ea3c2d8dd..ba06d1857b7d 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-backend.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Display Engine Backend Device Tree Bindings
+title: Allwinner A10 Display Engine Backend
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
index c9c346e6228e..e6088f379f70 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-engine.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Display Engine Pipeline Device Tree Bindings
+title: Allwinner A10 Display Engine Pipeline
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml
index 055157fbf3bf..995b3ef408b7 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-frontend.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Display Engine Frontend Device Tree Bindings
+title: Allwinner A10 Display Engine Frontend
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -121,5 +121,4 @@ examples:
};
};
-
...
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
index 7f11452539f4..55703caacb9c 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 HDMI Controller Device Tree Bindings
+title: Allwinner A10 HDMI Controller
description: |
The HDMI Encoder supports the HDMI video and audio outputs, and does
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
index f8168986a0a9..724d93b9193b 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-tcon.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Timings Controller (TCON) Device Tree Bindings
+title: Allwinner A10 Timings Controller (TCON)
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml
index afc0ed799e0e..c39e90a5945f 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun4i-a10-tv-encoder.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 TV Encoder Device Tree Bindings
+title: Allwinner A10 TV Encoder
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml
index 71cce5687580..85a6086cc10e 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun6i-a31-drc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 Dynamic Range Controller Device Tree Bindings
+title: Allwinner A31 Dynamic Range Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -121,5 +121,4 @@ examples:
};
};
-
...
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
index bf0bdf54e5f9..c731fbdc2fe0 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun6i-a31-mipi-dsi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 MIPI-DSI Controller Device Tree Bindings
+title: Allwinner A31 MIPI-DSI Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -12,9 +12,14 @@ maintainers:
properties:
compatible:
- enum:
- - allwinner,sun6i-a31-mipi-dsi
- - allwinner,sun50i-a64-mipi-dsi
+ oneOf:
+ - enum:
+ - allwinner,sun6i-a31-mipi-dsi
+ - allwinner,sun50i-a64-mipi-dsi
+ - allwinner,sun50i-a100-mipi-dsi
+ - items:
+ - const: allwinner,sun20i-d1-mipi-dsi
+ - const: allwinner,sun50i-a100-mipi-dsi
reg:
maxItems: 1
@@ -59,7 +64,6 @@ required:
- phys
- phy-names
- resets
- - vcc-dsi-supply
- port
allOf:
@@ -68,7 +72,9 @@ allOf:
properties:
compatible:
contains:
- const: allwinner,sun6i-a31-mipi-dsi
+ enum:
+ - allwinner,sun6i-a31-mipi-dsi
+ - allwinner,sun50i-a100-mipi-dsi
then:
properties:
@@ -78,16 +84,22 @@ allOf:
required:
- clock-names
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+
- if:
properties:
compatible:
contains:
- const: allwinner,sun50i-a64-mipi-dsi
+ enum:
+ - allwinner,sun6i-a31-mipi-dsi
+ - allwinner,sun50i-a64-mipi-dsi
then:
- properties:
- clocks:
- minItems: 1
+ required:
+ - vcc-dsi-supply
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
index cb243bc58ef7..cbd18fd83e52 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun8i-a83t-de2-mixer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner Display Engine 2.0 Mixer Device Tree Bindings
+title: Allwinner Display Engine 2.0 Mixer
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -24,9 +24,11 @@ properties:
- allwinner,sun50i-a64-de2-mixer-0
- allwinner,sun50i-a64-de2-mixer-1
- allwinner,sun50i-h6-de3-mixer-0
+ - allwinner,sun50i-h616-de33-mixer-0
- reg:
- maxItems: 1
+ reg: true
+
+ reg-names: true
clocks:
items:
@@ -61,6 +63,34 @@ properties:
required:
- port@1
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun50i-h616-de33-mixer-0
+ then:
+ properties:
+ reg:
+ description: |
+ Registers for controlling individual layers of the display
+ engine (layers), global control (top), and display blending
+ control (display). Names are from Allwinner BSP kernel.
+ maxItems: 3
+ reg-names:
+ items:
+ - const: layers
+ - const: top
+ - const: display
+ required:
+ - reg-names
+
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
index 4951b5ef5c6a..c43b02ec884f 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun8i-a83t-dw-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83t DWC HDMI TX Encoder Device Tree Bindings
+title: Allwinner A83t DWC HDMI TX Encoder
description: |
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller
@@ -142,7 +142,6 @@ then:
reset-names:
minItems: 2
-
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
index a97366aaf924..1b47f3d99a78 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun8i-a83t-hdmi-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83t HDMI PHY Device Tree Bindings
+title: Allwinner A83t HDMI PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
index 845e226d7aff..7d849c4095a3 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun8i-r40-tcon-top.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner R40 TCON TOP Device Tree Bindings
+title: Allwinner R40 TCON TOP
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml b/Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml
index 637372ec4614..193afee2c3c1 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/allwinner,sun9i-a80-deu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 Detail Enhancement Unit Device Tree Bindings
+title: Allwinner A80 Detail Enhancement Unit
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
index 7cdffdb131ac..416fe263ac92 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
@@ -11,7 +11,7 @@ maintainers:
- Neil Armstrong <neil.armstrong@linaro.org>
allOf:
- - $ref: /schemas/sound/name-prefix.yaml#
+ - $ref: /schemas/sound/dai-common.yaml#
description: |
The Amlogic Meson Synopsys Designware Integration is composed of
@@ -71,6 +71,10 @@ properties:
- const: iahb
- const: venci
+ power-domains:
+ maxItems: 1
+ description: phandle to the associated power domain
+
resets:
minItems: 3
@@ -129,6 +133,7 @@ examples:
reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
clocks = <&clk_isfr>, <&clk_iahb>, <&clk_venci>;
clock-names = "isfr", "iahb", "venci";
+ power-domains = <&pd_vpu>;
#address-cells = <1>;
#size-cells = <0>;
@@ -143,10 +148,10 @@ examples:
/* TMDS Output */
hdmi_tx_tmds_port: port@1 {
- reg = <1>;
+ reg = <1>;
- hdmi_tx_tmds_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml
new file mode 100644
index 000000000000..a3428f012005
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-g12a-dw-mipi-dsi.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/amlogic,meson-g12a-dw-mipi-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ The Amlogic Meson Synopsys Designware Integration is composed of
+ - A Synopsys DesignWare MIPI DSI Host Controller IP
+ - A TOP control block controlling the Clocks & Resets of the IP
+
+allOf:
+ - $ref: dsi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-dw-mipi-dsi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 4
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: pclk
+ - const: bit
+ - const: px
+ - const: meas
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: top
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: dphy
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input node to receive pixel data.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI output node to panel.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dsi@6000 {
+ compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+ reg = <0x6000 0x400>;
+ resets = <&reset_top>;
+ reset-names = "top";
+ clocks = <&clk_pclk>, <&bit_clk>, <&clk_px>;
+ clock-names = "pclk", "bit", "px";
+ phys = <&mipi_dphy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ /* DSI Output */
+ mipi_dsi_panel_port: port@1 {
+ reg = <1>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
index 6655a93b1874..3ae45db85ea7 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson Display Controller
@@ -25,7 +25,6 @@ description: |
M |-------|______|----|____________| |________________| | |
___|__________________________________________________________|_______________|
-
VIU: Video Input Unit
---------------------
@@ -96,6 +95,11 @@ properties:
description:
A port node pointing to the HDMI-TX port node.
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node pointing to the DPI port node (e.g. DSI or LVDS transceiver).
+
"#address-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
new file mode 100644
index 000000000000..5e6da66499a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/apple,h7-display-pipe-mipi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple pre-DCP display controller MIPI interface
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+description:
+ The MIPI controller part of the pre-DCP Apple display controller
+
+allOf:
+ - $ref: dsi-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,t8112-display-pipe-mipi
+ - apple,t8103-display-pipe-mipi
+ - const: apple,h7-display-pipe-mipi
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port. Always connected to the primary controller
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output MIPI DSI port to the panel
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dsi@28200000 {
+ compatible = "apple,t8103-display-pipe-mipi", "apple,h7-display-pipe-mipi";
+ reg = <0x28200000 0xc000>;
+ power-domains = <&ps_dispdfr_mipi>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dfr_adp_out_mipi: endpoint {
+ remote-endpoint = <&dfr_adp_out_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dfr_panel_in: endpoint {
+ remote-endpoint = <&dfr_mipi_out_panel>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
new file mode 100644
index 000000000000..102fb1804c0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/apple,h7-display-pipe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple pre-DCP display controller
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+description:
+ A secondary display controller used to drive the "touchbar" on
+ certain Apple laptops.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,t8112-display-pipe
+ - apple,t8103-display-pipe
+ - const: apple,h7-display-pipe
+
+ reg:
+ items:
+ - description: Primary register block, controls planes and blending
+ - description:
+ Contains other configuration registers like interrupt
+ and FIFO control
+
+ reg-names:
+ items:
+ - const: be
+ - const: fe
+
+ power-domains:
+ description:
+ Phandles to pmgr entries that are needed for this controller to turn on.
+ Aside from that, their specific functions are unknown
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: Unknown function
+ - description: Primary interrupt. Vsync events are reported via it
+
+ interrupt-names:
+ items:
+ - const: be
+ - const: fe
+
+ iommus:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output port. Always connected to apple,h7-display-pipe-mipi
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/apple-aic.h>
+ display-pipe@28200000 {
+ compatible = "apple,t8103-display-pipe", "apple,h7-display-pipe";
+ reg = <0x28200000 0xc000>,
+ <0x28400000 0x4000>;
+ reg-names = "be", "fe";
+ power-domains = <&ps_dispdfr_fe>, <&ps_dispdfr_be>;
+ interrupt-parent = <&aic>;
+ interrupts = <AIC_IRQ 502 IRQ_TYPE_LEVEL_HIGH>,
+ <AIC_IRQ 506 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "be", "fe";
+ iommus = <&displaydfr_dart 0>;
+
+ port {
+ dfr_adp_out_mipi: endpoint {
+ remote-endpoint = <&dfr_mipi_in_adp>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.yaml b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
index a2670258c48d..9a30e9005e8a 100644
--- a/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
+++ b/Documentation/devicetree/bindings/display/arm,hdlcd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/arm,hdlcd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Arm HDLCD display controller binding
+title: Arm HDLCD display controller
maintainers:
- Liviu Dudau <Liviu.Dudau@arm.com>
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.yaml b/Documentation/devicetree/bindings/display/arm,komeda.yaml
index 9f4aade97f10..3ad3eef89ca8 100644
--- a/Documentation/devicetree/bindings/display/arm,komeda.yaml
+++ b/Documentation/devicetree/bindings/display/arm,komeda.yaml
@@ -58,6 +58,7 @@ properties:
patternProperties:
'^pipeline@[01]$':
type: object
+ additionalProperties: false
description:
clocks
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.yaml b/Documentation/devicetree/bindings/display/arm,malidp.yaml
index 2a17ec6fc97c..91812573fd08 100644
--- a/Documentation/devicetree/bindings/display/arm,malidp.yaml
+++ b/Documentation/devicetree/bindings/display/arm,malidp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/arm,malidp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Arm Mali Display Processor (Mali-DP) binding
+title: Arm Mali Display Processor (Mali-DP)
maintainers:
- Liviu Dudau <Liviu.Dudau@arm.com>
diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.yaml b/Documentation/devicetree/bindings/display/arm,pl11x.yaml
index 6cc9045e5c68..a43c1c9d9113 100644
--- a/Documentation/devicetree/bindings/display/arm,pl11x.yaml
+++ b/Documentation/devicetree/bindings/display/arm,pl11x.yaml
@@ -78,6 +78,9 @@ properties:
If not present, the memory interface is fast enough to handle all
possible video modes.
+ resets:
+ maxItems: 1
+
port:
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
new file mode 100644
index 000000000000..a5cf040ab4ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip's LCDC Display
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Dharma Balasubiramani <dharma.b@microchip.com>
+
+description:
+ The LCD Controller (LCDC) consists of logic for transferring LCD image data
+ from an external display buffer to a TFT LCD panel. The LCDC has one display
+ input buffer per layer that fetches pixels through the single bus host
+ interface and a look-up table to allow palletized display configurations. The
+ LCDC is programmable on a per layer basis, and supports different LCD
+ resolutions, window sizes, image formats and pixel depths.
+
+# We need a select here since this schema is applicable only for nodes with the
+# following properties
+
+select:
+ anyOf:
+ - required: [ 'atmel,dmacon' ]
+ - required: [ 'atmel,lcdcon2' ]
+ - required: [ 'atmel,guard-time' ]
+
+properties:
+ atmel,dmacon:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: dma controller configuration
+
+ atmel,lcdcon2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: lcd controller configuration
+
+ atmel,guard-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: lcd guard time (Delay in frame periods)
+ maximum: 127
+
+ bits-per-pixel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: lcd panel bit-depth.
+ enum: [1, 2, 4, 8, 16, 24, 32]
+
+ atmel,lcdcon-backlight:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: enable backlight
+
+ atmel,lcdcon-backlight-inverted:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: invert backlight PWM polarity
+
+ atmel,lcd-wiring-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: lcd wiring mode "RGB" or "BRG"
+ enum:
+ - RGB
+ - BRG
+
+ atmel,power-control-gpio:
+ description: gpio to power on or off the LCD (as many as needed)
+ maxItems: 1
+
+ display-timings:
+ $ref: panel/display-timings.yaml#
+
+required:
+ - atmel,dmacon
+ - atmel,lcdcon2
+ - atmel,guard-time
+ - bits-per-pixel
+
+additionalProperties: false
+
+examples:
+ - |
+ display: panel {
+ bits-per-pixel = <32>;
+ atmel,lcdcon-backlight;
+ atmel,dmacon = <0x1>;
+ atmel,lcdcon2 = <0x80008002>;
+ atmel,guard-time = <9>;
+ atmel,lcd-wiring-mode = "RGB";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing0 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <1>;
+ hfront-porch = <1>;
+ vback-porch = <40>;
+ vfront-porch = <1>;
+ hsync-len = <45>;
+ vsync-len = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.txt b/Documentation/devicetree/bindings/display/atmel,lcdc.txt
deleted file mode 100644
index b5e355ada2fa..000000000000
--- a/Documentation/devicetree/bindings/display/atmel,lcdc.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Atmel LCDC Framebuffer
------------------------------------------------------
-
-Required properties:
-- compatible :
- "atmel,at91sam9261-lcdc" ,
- "atmel,at91sam9263-lcdc" ,
- "atmel,at91sam9g10-lcdc" ,
- "atmel,at91sam9g45-lcdc" ,
- "atmel,at91sam9g45es-lcdc" ,
- "atmel,at91sam9rl-lcdc" ,
-- reg : Should contain 1 register ranges(address and length).
- Can contain an additional register range(address and length)
- for fixed framebuffer memory. Useful for dedicated memories.
-- interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
-
-Required nodes:
-- display: a display node is required to initialize the lcd panel
- This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
- as specified below.
-
-Optional properties:
-- lcd-supply: Regulator for LCD supply voltage.
-
-Example:
-
- fb0: fb@00500000 {
- compatible = "atmel,at91sam9g45-lcdc";
- reg = <0x00500000 0x1000>;
- interrupts = <23 3 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fb>;
- display = <&display0>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- };
-
-Example for fixed framebuffer memory:
-
- fb0: fb@00500000 {
- compatible = "atmel,at91sam9263-lcdc";
- reg = <0x00700000 0x1000 0x70000000 0x200000>;
- [...]
- };
-
-Atmel LCDC Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - atmel,dmacon: dma controller configuration
- - atmel,lcdcon2: lcd controller configuration
- - atmel,guard-time: lcd guard time (Delay in frame periods)
- - bits-per-pixel: lcd panel bit-depth.
-
-Optional properties (as per of_videomode_helper):
- - atmel,lcdcon-backlight: enable backlight
- - atmel,lcdcon-backlight-inverted: invert backlight PWM polarity
- - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
- - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
-
-Example:
- display0: display {
- bits-per-pixel = <32>;
- atmel,lcdcon-backlight;
- atmel,dmacon = <0x1>;
- atmel,lcdcon2 = <0x80008002>;
- atmel,guard-time = <9>;
- atmel,lcd-wiring-mode = <1>;
-
- display-timings {
- native-mode = <&timing0>;
- timing0: timing0 {
- clock-frequency = <9000000>;
- hactive = <480>;
- vactive = <272>;
- hback-porch = <1>;
- hfront-porch = <1>;
- vback-porch = <40>;
- vfront-porch = <1>;
- hsync-len = <45>;
- vsync-len = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.yaml b/Documentation/devicetree/bindings/display/atmel,lcdc.yaml
new file mode 100644
index 000000000000..1b6f7e395006
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/atmel,lcdc.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/atmel,lcdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip's LCDC Framebuffer
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Dharma Balasubiramani <dharma.b@microchip.com>
+
+description:
+ The LCDC works with a framebuffer, which is a section of memory that contains
+ a complete frame of data representing pixel values for the display. The LCDC
+ reads the pixel data from the framebuffer and sends it to the LCD panel to
+ render the image.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91sam9261-lcdc
+ - atmel,at91sam9263-lcdc
+ - atmel,at91sam9g10-lcdc
+ - atmel,at91sam9g45-lcdc
+ - atmel,at91sam9g45es-lcdc
+ - atmel,at91sam9rl-lcdc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: hclk
+ - const: lcdc_clk
+
+ display:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle pointing to the display node.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - display
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ fb@500000 {
+ compatible = "atmel,at91sam9g45-lcdc";
+ reg = <0x00500000 0x1000>;
+ interrupts = <23 IRQ_TYPE_LEVEL_HIGH 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fb>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 23>, <&pmc PMC_TYPE_PERIPHERAL 23>;
+ clock-names = "hclk", "lcdc_clk";
+ display = <&display>;
+ };
diff --git a/Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml b/Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml
new file mode 100644
index 000000000000..29ed42485de3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/atmel/atmel,hlcdc-display-controller.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/atmel/atmel,hlcdc-display-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel's High LCD Controller (HLCDC)
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+ - Claudiu Beznea <claudiu.beznea@tuxon.dev>
+
+description:
+ The LCD Controller (LCDC) consists of logic for transferring LCD image
+ data from an external display buffer to a TFT LCD panel. The LCDC has one
+ display input buffer per layer that fetches pixels through the single bus
+ host interface and a look-up table to allow palletized display
+ configurations.
+
+properties:
+ compatible:
+ const: atmel,hlcdc-display-controller
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Output endpoint of the controller, connecting the LCD panel signals.
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint connecting the LCD panel signals.
+
+ properties:
+ bus-width:
+ enum: [ 12, 16, 18, 24 ]
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - compatible
+ - port@0
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
deleted file mode 100644
index 0398aec488ac..000000000000
--- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
-
-The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
-See ../../mfd/atmel-hlcdc.txt for more details.
-
-Required properties:
- - compatible: value should be "atmel,hlcdc-display-controller"
- - pinctrl-names: the pin control state names. Should contain "default".
- - pinctrl-0: should contain the default pinctrl states.
- - #address-cells: should be set to 1.
- - #size-cells: should be set to 0.
-
-Required children nodes:
- Children nodes are encoding available output ports and their connections
- to external devices using the OF graph reprensentation (see ../graph.txt).
- At least one port node is required.
-
-Optional properties in grandchild nodes:
- Any endpoint grandchild node may specify a desired video interface
- according to ../../media/video-interfaces.txt, specifically
- - bus-width: recognized values are <12>, <16>, <18> and <24>, and
- override any output mode selection heuristic, forcing "rgb444",
- "rgb565", "rgb666" and "rgb888" respectively.
-
-Example:
-
- hlcdc: hlcdc@f0030000 {
- compatible = "atmel,sama5d3-hlcdc";
- reg = <0xf0030000 0x2000>;
- interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
- clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
- clock-names = "periph_clk","sys_clk", "slow_clk";
-
- hlcdc-display-controller {
- compatible = "atmel,hlcdc-display-controller";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- hlcdc_panel_output: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&panel_input>;
- };
- };
- };
-
- hlcdc_pwm: hlcdc-pwm {
- compatible = "atmel,hlcdc-pwm";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcd_pwm>;
- #pwm-cells = <3>;
- };
- };
-
-Example 2: With a video interface override to force rgb565; as above
-but with these changes/additions:
-
- &hlcdc {
- hlcdc-display-controller {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
-
- port@0 {
- hlcdc_panel_output: endpoint@0 {
- bus-width = <16>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index a9d34dd7bbc5..c1cefd547391 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
+title: Broadcom BCM2711 HDMI Controller
maintainers:
- Eric Anholt <eric@anholt.net>
@@ -14,6 +14,8 @@ properties:
enum:
- brcm,bcm2711-hdmi0
- brcm,bcm2711-hdmi1
+ - brcm,bcm2712-hdmi0
+ - brcm,bcm2712-hdmi1
reg:
items:
@@ -54,22 +56,12 @@ properties:
- const: cec
interrupts:
- items:
- - description: CEC TX interrupt
- - description: CEC RX interrupt
- - description: CEC stuck at low interrupt
- - description: Wake-up interrupt
- - description: Hotplug connected interrupt
- - description: Hotplug removed interrupt
+ minItems: 5
+ maxItems: 6
interrupt-names:
- items:
- - const: cec-tx
- - const: cec-rx
- - const: cec-low
- - const: wakeup
- - const: hpd-connected
- - const: hpd-removed
+ minItems: 5
+ maxItems: 6
ddc:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -110,6 +102,61 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm2711-hdmi0
+ - brcm,bcm2711-hdmi1
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: CEC TX interrupt
+ - description: CEC RX interrupt
+ - description: CEC stuck at low interrupt
+ - description: Wake-up interrupt
+ - description: Hotplug connected interrupt
+ - description: Hotplug removed interrupt
+ interrupt-names:
+ items:
+ - const: cec-tx
+ - const: cec-rx
+ - const: cec-low
+ - const: wakeup
+ - const: hpd-connected
+ - const: hpd-removed
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm2712-hdmi0
+ - brcm,bcm2712-hdmi1
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: CEC TX interrupt
+ - description: CEC RX interrupt
+ - description: CEC stuck at low interrupt
+ - description: Hotplug connected interrupt
+ - description: Hotplug removed interrupt
+ interrupts-names:
+ items:
+ - const: cec-tx
+ - const: cec-rx
+ - const: cec-low
+ - const: hpd-connected
+ - const: hpd-removed
+
+ required:
+ - interrupts
+ - interrupt-names
+
examples:
- |
hdmi0: hdmi@7ef00700 {
@@ -134,6 +181,9 @@ examples:
"hd";
clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>, <&clk_27MHz>;
clock-names = "hdmi", "bvb", "audio", "cec";
+ interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
+ interrupt-names = "cec-tx", "cec-rx", "cec-low", "wakeup",
+ "hpd-connected", "hpd-removed";
resets = <&dvp 0>;
ddc = <&ddc0>;
};
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
index 2e8566f47e63..9aca38a58a16 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
@@ -13,17 +13,27 @@ properties:
compatible:
enum:
- brcm,bcm2711-hvs
+ - brcm,bcm2712-hvs
- brcm,bcm2835-hvs
reg:
maxItems: 1
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 3
clocks:
- maxItems: 1
- description: Core Clock
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
required:
- compatible
@@ -32,15 +42,68 @@ required:
additionalProperties: false
-if:
- properties:
- compatible:
- contains:
- const: brcm,bcm2711-hvs
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm2711-hvs
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Core Clock
+ interrupts:
+ maxItems: 1
+ clock-names: false
+ interrupt-names: false
+
+ required:
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm2712-hvs
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: core
+ - const: disp
+ interrupts:
+ items:
+ - description: Channel 0 End of frame
+ - description: Channel 1 End of frame
+ - description: Channel 2 End of frame
+ interrupt-names:
+ items:
+ - const: ch0-eof
+ - const: ch1-eof
+ - const: ch2-eof
+ required:
+ - clocks
+ - clock-names
+ - interrupt-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm2835-hvs
-then:
- required:
- - clocks
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ clock-names: false
+ interrupt-names: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
index 4e1ba03f6477..6b5b1d3fbc0b 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
@@ -20,6 +20,9 @@ properties:
- brcm,bcm2711-pixelvalve2
- brcm,bcm2711-pixelvalve3
- brcm,bcm2711-pixelvalve4
+ - brcm,bcm2712-pixelvalve0
+ - brcm,bcm2712-pixelvalve1
+ - brcm,bcm2712-pixelvalve2
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
index bb186197e471..16f45afd2bad 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
@@ -11,7 +11,10 @@ maintainers:
properties:
compatible:
- const: brcm,bcm2835-txp
+ enum:
+ - brcm,bcm2712-mop
+ - brcm,bcm2712-moplet
+ - brcm,bcm2835-txp
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
index 49a5e041aa49..2aa9d5d2afff 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- brcm,bcm2711-vc5
+ - brcm,bcm2712-vc6
- brcm,bcm2835-vc4
- brcm,cygnus-vc4
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
index f08a01dfedf3..d29a0d06187e 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
@@ -117,23 +117,21 @@ properties:
ports:
description:
- The ADV7511(W)/13 has two video ports and one audio port. This node
- models their connections as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
- Documentation/devicetree/bindings/graph.txt
- type: object
+ The ADV7511(W)/13 has two video ports and one audio port.
+ $ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
description: Video port for the RGB or YUV input.
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
port@1:
description: Video port for the HDMI output.
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
port@2:
description: Audio port for the HDMI output.
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
# adi,input-colorspace and adi,input-clock are required except in
# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
@@ -158,7 +156,6 @@ else:
adi,input-style: false
adi,input-justification: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
index f36209137c8a..ec89115c74e4 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
@@ -9,6 +9,9 @@ title: Analog Devices ADV7533/35 HDMI Encoders
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
description: |
The ADV7533 and ADV7535 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They support color space
@@ -87,29 +90,30 @@ properties:
adi,dsi-lanes:
description: Number of DSI data lanes connected to the DSI host.
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 1, 2, 3, 4 ]
+ enum: [ 2, 3, 4 ]
+
+ "#sound-dai-cells":
+ const: 0
ports:
description:
- The ADV7533/35 has two video ports and one audio port. This node
- models their connections as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
- Documentation/devicetree/bindings/graph.txt
- type: object
+ The ADV7533/35 has two video ports and one audio port.
+ $ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
description:
Video port for the DSI input. The remote endpoint phandle
should be a reference to a valid mipi_dsi_host_device.
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
port@1:
description: Video port for the HDMI output.
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
port@2:
description: Audio port for the HDMI output.
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 4590186c4a0b..a1ed1004651b 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Analogix Semiconductor, Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
@@ -16,8 +16,7 @@ description: |
properties:
compatible:
- items:
- - const: analogix,anx7625
+ const: analogix,anx7625
reg:
maxItems: 1
@@ -134,7 +133,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
index 4a5e5d9d6f90..4509c496731b 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
@@ -17,6 +17,7 @@ properties:
- analogix,anx7808
- analogix,anx7812
- analogix,anx7814
+ - analogix,anx7816
- analogix,anx7818
reg:
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
new file mode 100644
index 000000000000..62f0521b0924
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/analogix,dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analogix Display Port bridge
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+properties:
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks: true
+
+ clock-names: true
+
+ phys: true
+
+ phy-names:
+ const: dp
+
+ force-hpd:
+ type: boolean
+ description:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don not have a hpd signal.
+
+ hpd-gpios:
+ description:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input node to receive pixel data.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port node with one endpoint connected to a dp-connector node.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - reg
+ - interrupts
+ - clock-names
+ - clocks
+ - ports
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
deleted file mode 100644
index 027d76c27a41..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Analogix Display Port bridge bindings
-
-Required properties for dp-controller:
- -compatible:
- platform specific such as:
- * "samsung,exynos5-dp"
- * "rockchip,rk3288-dp"
- * "rockchip,rk3399-edp"
- -reg:
- physical base address of the controller and length
- of memory mapped region.
- -interrupts:
- interrupt combiner values.
- -clocks:
- from common clock binding: handle to dp clock.
- -clock-names:
- from common clock binding: Shall be "dp".
- -phys:
- from general PHY binding: the phandle for the PHY device.
- -phy-names:
- from general PHY binding: Should be "dp".
-
-Optional properties for dp-controller:
- -force-hpd:
- Indicate driver need force hpd when hpd detect failed, this
- is used for some eDP screen which don't have hpd signal.
- -hpd-gpios:
- Hotplug detect GPIO.
- Indicates which GPIO should be used for hotplug detection
- -port@[X]: SoC specific port nodes with endpoint definitions as defined
- in Documentation/devicetree/bindings/media/video-interfaces.txt,
- please refer to the SoC specific binding document:
- * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
- * Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
--------------------------------------------------------------------------------
-
-Example:
-
- dp-controller {
- compatible = "samsung,exynos5-dp";
- reg = <0x145b0000 0x10000>;
- interrupts = <10 3>;
- interrupt-parent = <&combiner>;
- clocks = <&clock 342>;
- clock-names = "dp";
-
- phys = <&dp_phy>;
- phy-names = "dp";
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
index 1c0406c38fe5..514f58852990 100644
--- a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/bridge/anx6345.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analogix ANX6345 eDP Transmitter Device Tree Bindings
+title: Analogix ANX6345 eDP Transmitter
maintainers:
- Torsten Duwe <duwe@lst.de>
@@ -61,7 +61,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
deleted file mode 100644
index 525a4bfd8634..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-Cadence DSI bridge
-==================
-
-The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
-
-Required properties:
-- compatible: should be set to "cdns,dsi".
-- reg: physical base address and length of the controller's registers.
-- interrupts: interrupt line connected to the DSI bridge.
-- clocks: DSI bridge clocks.
-- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
-- phys: phandle link to the MIPI D-PHY controller.
-- phy-names: must contain "dphy".
-- #address-cells: must be set to 1.
-- #size-cells: must be set to 0.
-
-Optional properties:
-- resets: DSI reset lines.
-- reset-names: can contain "dsi_p_rst".
-
-Required subnodes:
-- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
- 2 ports are available:
- * port 0: this port is only needed if some of your DSI devices are
- controlled through an external bus like I2C or SPI. Can have at
- most 4 endpoints. The endpoint number is directly encoding the
- DSI virtual channel used by this device.
- * port 1: represents the DPI input.
- Other ports will be added later to support the new kind of inputs.
-
-- one subnode per DSI device connected on the DSI bus. Each DSI device should
- contain a reg property encoding its virtual channel.
-
-Example:
- dsi0: dsi@fd0c0000 {
- compatible = "cdns,dsi";
- reg = <0x0 0xfd0c0000 0x0 0x1000>;
- clocks = <&pclk>, <&sysclk>;
- clock-names = "dsi_p_clk", "dsi_sys_clk";
- interrupts = <1>;
- phys = <&dphy0>;
- phy-names = "dphy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
- dsi0_dpi_input: endpoint {
- remote-endpoint = <&xxx_dpi_output>;
- };
- };
- };
-
- panel: dsi-dev@0 {
- compatible = "<vendor,panel>";
- reg = <0>;
- };
- };
-
-or
-
- dsi0: dsi@fd0c0000 {
- compatible = "cdns,dsi";
- reg = <0x0 0xfd0c0000 0x0 0x1000>;
- clocks = <&pclk>, <&sysclk>;
- clock-names = "dsi_p_clk", "dsi_sys_clk";
- interrupts = <1>;
- phys = <&dphy1>;
- phy-names = "dphy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- dsi0_output: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&dsi_panel_input>;
- };
- };
-
- port@1 {
- reg = <1>;
- dsi0_dpi_input: endpoint {
- remote-endpoint = <&xxx_dpi_output>;
- };
- };
- };
- };
-
- i2c@xxx {
- panel: panel@59 {
- compatible = "<vendor,panel>";
- reg = <0x59>;
-
- port {
- dsi_panel_input: endpoint {
- remote-endpoint = <&dsi0_output>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
new file mode 100644
index 000000000000..23060324d16e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DSI bridge
+
+maintainers:
+ - Boris Brezillon <boris.brezillon@bootlin.com>
+
+description: |
+ CDNS DSI is a bridge device which converts DPI to DSI
+
+properties:
+ compatible:
+ enum:
+ - cdns,dsi
+ - ti,j721e-dsi
+
+ reg:
+ minItems: 1
+ items:
+ - description:
+ Register block for controller's registers.
+ - description:
+ Register block for wrapper settings registers in case of TI J7 SoCs.
+
+ clocks:
+ items:
+ - description: PSM clock, used by the IP
+ - description: sys clock, used by the IP
+
+ clock-names:
+ items:
+ - const: dsi_p_clk
+ - const: dsi_sys_clk
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: dphy
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: dsi_p_rst
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port representing the DSI output. It can have
+ at most 4 endpoints. The endpoint number is directly encoding
+ the DSI virtual channel used by this device.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input port representing the DPI input.
+
+ required:
+ - port@1
+
+allOf:
+ - $ref: ../dsi-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,j721e-dsi
+ then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+ power-domains:
+ maxItems: 1
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - phys
+ - phy-names
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dsi@fd0c0000 {
+ compatible = "cdns,dsi";
+ reg = <0x0 0xfd0c0000 0x0 0x1000>;
+ clocks = <&pclk>, <&sysclk>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ interrupts = <1>;
+ phys = <&dphy0>;
+ phy-names = "dphy";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "panasonic,vvx10f034n00";
+ reg = <0>;
+ power-supply = <&vcc_lcd_reg>;
+ };
+ };
+ };
+
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dsi@fd0c0000 {
+ compatible = "cdns,dsi";
+ reg = <0x0 0xfd0c0000 0x0 0x1000>;
+ clocks = <&pclk>, <&sysclk>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ interrupts = <1>;
+ phys = <&dphy1>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsi_panel_input>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
index b2e8bc6da9d0..c2b369456e4e 100644
--- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence MHDP8546 bridge
diff --git a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
index bb6289c7d375..b0589fa16736 100644
--- a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/display/bridge/chrontel,ch7033.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Chrontel CH7033 Video Encoder Device Tree Bindings
+title: Chrontel CH7033 Video Encoder
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
new file mode 100644
index 000000000000..6211ab8bbb0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP DWC HDMI TX Encoder
+
+maintainers:
+ - Lucas Stach <l.stach@pengutronix.de>
+
+description:
+ The i.MX8MP HDMI transmitter is a Synopsys DesignWare
+ HDMI 2.0a TX controller IP.
+
+allOf:
+ - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8mp-hdmi-tx
+
+ reg-io-width:
+ const: 1
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: iahb
+ - const: isfr
+ - const: cec
+ - const: pix
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Parallel RGB input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: HDMI output port
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Parallel audio input port
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/imx8mp-power.h>
+
+ hdmi@32fd8000 {
+ compatible = "fsl,imx8mp-hdmi-tx";
+ reg = <0x32fd8000 0x7eff>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+ <&clk IMX8MP_CLK_HDMI_REF_266M>,
+ <&clk IMX8MP_CLK_32K>,
+ <&hdmi_tx_phy>;
+ clock-names = "iahb", "isfr", "cec", "pix";
+ power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
+ reg-io-width = <1>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&pvi_to_hdmi_tx>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&hdmi0_con>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&pai_to_hdmi_tx>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx93-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx93-mipi-dsi.yaml
new file mode 100644
index 000000000000..d6e51d0cf546
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx93-mipi-dsi.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx93-mipi-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX93 specific extensions to Synopsys Designware MIPI DSI
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+description: |
+ There is a Synopsys Designware MIPI DSI Host Controller and a Synopsys
+ Designware MIPI DPHY embedded in Freescale i.MX93 SoC. Some configurations
+ and extensions to them are controlled by i.MX93 media blk-ctrl.
+
+allOf:
+ - $ref: snps,dw-mipi-dsi.yaml#
+
+properties:
+ compatible:
+ const: fsl,imx93-mipi-dsi
+
+ clocks:
+ items:
+ - description: apb clock
+ - description: pixel clock
+ - description: PHY configuration clock
+ - description: PHY reference clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: pix
+ - const: phy_cfg
+ - const: phy_ref
+
+ interrupts:
+ maxItems: 1
+
+ fsl,media-blk-ctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ i.MX93 media blk-ctrl, as a syscon, controls pixel component bit map
+ configurations from LCDIF display controller to the MIPI DSI host
+ controller and MIPI DPHY PLL related configurations through PLL SoC
+ interface.
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+ - fsl,media-blk-ctrl
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx93-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/fsl,imx93-power.h>
+
+ dsi@4ae10000 {
+ compatible = "fsl,imx93-mipi-dsi";
+ reg = <0x4ae10000 0x10000>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_MIPI_DSI_GATE>,
+ <&clk IMX93_CLK_MEDIA_DISP_PIX>,
+ <&clk IMX93_CLK_MIPI_PHY_CFG>,
+ <&clk IMX93_CLK_24M>;
+ clock-names = "pclk", "pix", "phy_cfg", "phy_ref";
+ fsl,media-blk-ctrl = <&media_blk_ctrl>;
+ power-domains = <&media_blk_ctrl IMX93_MEDIABLK_PD_MIPI_DSI>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "raydium,rm67191";
+ reg = <0>;
+ reset-gpios = <&adp5585gpio 6 GPIO_ACTIVE_LOW>;
+ dsi-lanes = <4>;
+ video-mode = <2>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_to_lcdif: endpoint {
+ remote-endpoint = <&lcdif_to_dsi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
index 2ebaa43eb62e..07388bf2b90d 100644
--- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -16,7 +16,10 @@ description: |
properties:
compatible:
- const: fsl,imx8mp-ldb
+ enum:
+ - fsl,imx6sx-ldb
+ - fsl,imx8mp-ldb
+ - fsl,imx93-ldb
clocks:
maxItems: 1
@@ -25,7 +28,6 @@ properties:
const: ldb
reg:
- minItems: 2
maxItems: 2
reg-names:
@@ -58,6 +60,20 @@ required:
- clocks
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sx-ldb
+ - fsl,imx93-ldb
+ then:
+ properties:
+ ports:
+ properties:
+ port@2: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
index 89490fdffeb0..84df3cf239d5 100644
--- a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for Ingenic JZ4780 HDMI Transmitter
+title: Ingenic JZ4780 HDMI Transmitter
maintainers:
- H. Nikolaus Schaller <hns@goldelico.com>
@@ -26,6 +26,9 @@ properties:
clocks:
maxItems: 2
+ clock-names:
+ maxItems: 2
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
diff --git a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
index dcb1336ee2a5..958a073f4ff7 100644
--- a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/bridge/intel,keembay-dsi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Devicetree bindings for Intel Keem Bay mipi dsi controller
+title: Intel Keem Bay mipi dsi controller
maintainers:
- Anitha Chrisanthus <anitha.chrisanthus@intel.com>
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
new file mode 100644
index 000000000000..b98d942bbe19
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
@@ -0,0 +1,251 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE IT6263 LVDS to HDMI converter
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+description: |
+ The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
+ to HDMI converter. Combined with LVDS receiver and HDMI 1.4a transmitter,
+ the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
+ The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
+ and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
+ 1.2 and backward compatible with DVI 1.0 specification.
+
+ The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
+ with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
+ an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
+
+ The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
+ provided by the IT6263 in two interfaces: the four I2S input ports or the
+ S/PDIF input port. With both interfaces the highest possible HBR frame rate
+ is supported at up to 768KHz.
+
+allOf:
+ - $ref: /schemas/display/lvds-dual-ports.yaml#
+ - $ref: /schemas/sound/dai-common.yaml#
+
+properties:
+ compatible:
+ const: ite,it6263
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: audio master clock
+
+ clock-names:
+ const: mclk
+
+ data-mapping:
+ enum:
+ - jeida-18
+ - jeida-24
+ - jeida-30
+ - vesa-24
+ - vesa-30
+
+ reset-gpios:
+ maxItems: 1
+
+ ivdd-supply:
+ description: 1.8V digital logic power
+
+ ovdd-supply:
+ description: 3.3V I/O pin power
+
+ txavcc18-supply:
+ description: 1.8V HDMI analog frontend power
+
+ txavcc33-supply:
+ description: 3.3V HDMI analog frontend power
+
+ pvcc1-supply:
+ description: 1.8V HDMI frontend core PLL power
+
+ pvcc2-supply:
+ description: 1.8V HDMI frontend filter PLL power
+
+ avcc-supply:
+ description: 3.3V LVDS frontend power
+
+ anvdd-supply:
+ description: 1.8V LVDS frontend analog power
+
+ apvdd-supply:
+ description: 1.8V LVDS frontend PLL power
+
+ "#sound-dai-cells":
+ const: 0
+
+ ite,i2s-audio-fifo-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [0, 1, 2, 3]
+ description:
+ Each array element indicates the pin number of an I2S serial data input
+ line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
+
+ ite,rl-channel-swap-audio-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ uniqueItems: true
+ items:
+ enum: [0, 1, 2, 3]
+ description:
+ Each array element indicates an audio source whose right channel and left
+ channel are swapped by this converter. For I2S, the element is the pin
+ number of an I2S serial data input line. For S/PDIF, the element is always
+ 0.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0: true
+
+ port@1:
+ oneOf:
+ - required: [dual-lvds-odd-pixels]
+ - required: [dual-lvds-even-pixels]
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: video port for the HDMI output
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: sound input port
+
+ required:
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - data-mapping
+ - ivdd-supply
+ - ovdd-supply
+ - txavcc18-supply
+ - txavcc33-supply
+ - pvcc1-supply
+ - pvcc2-supply
+ - avcc-supply
+ - anvdd-supply
+ - apvdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* single-link LVDS input */
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi@4c {
+ compatible = "ite,it6263";
+ reg = <0x4c>;
+ data-mapping = "jeida-24";
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ ivdd-supply = <&reg_buck5>;
+ ovdd-supply = <&reg_vext_3v3>;
+ txavcc18-supply = <&reg_buck5>;
+ txavcc33-supply = <&reg_vext_3v3>;
+ pvcc1-supply = <&reg_buck5>;
+ pvcc2-supply = <&reg_buck5>;
+ avcc-supply = <&reg_vext_3v3>;
+ anvdd-supply = <&reg_buck5>;
+ apvdd-supply = <&reg_buck5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ it6263_lvds_link1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ it6263_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
+ };
+
+ - |
+ /* dual-link LVDS input */
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi@4c {
+ compatible = "ite,it6263";
+ reg = <0x4c>;
+ data-mapping = "jeida-24";
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ ivdd-supply = <&reg_buck5>;
+ ovdd-supply = <&reg_vext_3v3>;
+ txavcc18-supply = <&reg_buck5>;
+ txavcc33-supply = <&reg_vext_3v3>;
+ pvcc1-supply = <&reg_buck5>;
+ pvcc2-supply = <&reg_buck5>;
+ avcc-supply = <&reg_vext_3v3>;
+ anvdd-supply = <&reg_buck5>;
+ apvdd-supply = <&reg_buck5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+
+ it6263_lvds_link1_dual: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+
+ it6263_lvds_link2_dual: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ it6263_out_dual: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
index 833d11b2303a..c4469f463978 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/display/bridge/ite,it6505.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ITE it6505 Device Tree Bindings
+title: ITE it6505
maintainers:
- Allen Chen <allen.chen@ite.com.tw>
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
description: |
The IT6505 is a high-performance DisplayPort 1.1a transmitter,
fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications.
@@ -52,9 +55,52 @@ properties:
maxItems: 1
description: extcon specifier for the Power Delivery
- port:
- $ref: /schemas/graph.yaml#/properties/port
- description: A port node pointing to DPI host port node
+ "#sound-dai-cells":
+ const: 0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: A port node pointing to DPI host port node
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ link-frequencies:
+ minItems: 1
+ maxItems: 1
+ description: Allowed max link frequencies in Hz
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Video port for DP output
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ uniqueItems: true
+ items:
+ - enum: [ 0, 1 ]
+ - const: 1
+ - const: 2
+ - const: 3
+
+ required:
+ - port@0
+ - port@1
required:
- compatible
@@ -63,8 +109,9 @@ required:
- interrupts
- reset-gpios
- extcon
+ - ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -85,9 +132,24 @@ examples:
reset-gpios = <&pio 179 1>;
extcon = <&usbc_extcon>;
- port {
- it6505_in: endpoint {
- remote-endpoint = <&dpi_out>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ it6505_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ link-frequencies = /bits/ 64 <150000000>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ it6505_out: endpoint {
+ remote-endpoint = <&dp_in>;
+ data-lanes = <0 1>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
index 1b2185be92cd..17d1f97ce8c2 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ITE it66121 HDMI bridge Device Tree Bindings
+title: ITE it66121 HDMI bridge
maintainers:
- Phong LE <ple@baylibre.com>
@@ -17,7 +17,10 @@ description: |
properties:
compatible:
- const: ite,it66121
+ enum:
+ - ite,it66121
+ - ite,it66122
+ - ite,it6610
reg:
maxItems: 1
@@ -82,7 +85,10 @@ required:
- interrupts
- ports
-additionalProperties: false
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
index 674891ee2f8e..2cef25215798 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
@@ -55,6 +55,27 @@ properties:
- port@0
- port@1
+ vcchdmipll-supply:
+ description: A 1.8V supply that powers the HDMI PLL.
+
+ vcchdmitx-supply:
+ description: A 1.8V supply that powers the HDMI TX part.
+
+ vcclvdspll-supply:
+ description: A 1.8V supply that powers the LVDS PLL.
+
+ vcclvdstx-supply:
+ description: A 1.8V supply that powers the LVDS TX part.
+
+ vccmipirx-supply:
+ description: A 1.8V supply that powers the MIPI RX part.
+
+ vccsysclk-supply:
+ description: A 1.8V supply that powers the SYSCLK.
+
+ vdd-supply:
+ description: A 1.8V supply that powers the digital part.
+
required:
- compatible
- reg
@@ -67,7 +88,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c4 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
index 5b9d36f7af30..655db8cfdc25 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -69,7 +69,10 @@ required:
- vcc-supply
- ports
-additionalProperties: false
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 3a8614e0f627..4f7d3e9cf0c2 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -41,6 +41,8 @@ properties:
- enum:
- ti,ds90cf364a # For the DS90CF364A FPD-Link LVDS Receiver
- ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver
+ - ti,sn65lvds822 # For the SN65LVDS822 FlatLink LVDS Receiver
+ - ti,sn65lvds94 # For the SN65DS94 LVDS serdes
- const: lvds-decoder # Generic LVDS decoders compatible fallback
- enum:
- thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer
@@ -51,6 +53,7 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: |
For LVDS encoders, port 0 is the parallel input
For LVDS decoders, port 0 is the LVDS input
@@ -128,7 +131,6 @@ required:
additionalProperties: false
-
examples:
- |
lvds-encoder {
diff --git a/Documentation/devicetree/bindings/display/bridge/megachips,stdp2690-ge-b850v3-fw.yaml b/Documentation/devicetree/bindings/display/bridge/megachips,stdp2690-ge-b850v3-fw.yaml
new file mode 100644
index 000000000000..dfa6ff6f115e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/megachips,stdp2690-ge-b850v3-fw.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/megachips,stdp2690-ge-b850v3-fw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GE B850v3 video bridge
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ STDP4028-ge-b850v3-fw bridges (LVDS-DP)
+ STDP2690-ge-b850v3-fw bridges (DP-DP++)
+
+ The video processing pipeline on the second output on the GE B850v3:
+
+ Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
+
+ Each bridge has a dedicated flash containing firmware for supporting the custom
+ design. The result is that, in this design, neither the STDP4028 nor the
+ STDP2690 behave as the stock bridges would. The compatible strings include the
+ suffix "-ge-b850v3-fw" to make it clear that the driver is for the bridges with
+ the firmware specific for the GE B850v3.
+
+ The hardware do not provide control over the video processing pipeline, as the
+ two bridges behaves as a single one. The only interfaces exposed by the
+ hardware are EDID, HPD, and interrupts.
+
+properties:
+ compatible:
+ enum:
+ - megachips,stdp4028-ge-b850v3-fw
+ - megachips,stdp2690-ge-b850v3-fw
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ description: sink port
+ $ref: /schemas/graph.yaml#/properties/port
+
+ port@1:
+ description: source port
+ $ref: /schemas/graph.yaml#/properties/port
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: megachips,stdp4028-ge-b850v3-fw
+ then:
+ required:
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@73 {
+ compatible = "megachips,stdp4028-ge-b850v3-fw";
+ reg = <0x73>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&stdp2690_in>;
+ };
+ };
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt b/Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
deleted file mode 100644
index 09e0a21f705e..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/megachips-stdpxxxx-ge-b850v3-fw.txt
+++ /dev/null
@@ -1,91 +0,0 @@
-Drivers for the second video output of the GE B850v3:
- STDP4028-ge-b850v3-fw bridges (LVDS-DP)
- STDP2690-ge-b850v3-fw bridges (DP-DP++)
-
-The video processing pipeline on the second output on the GE B850v3:
-
- Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
-
-Each bridge has a dedicated flash containing firmware for supporting the custom
-design. The result is that, in this design, neither the STDP4028 nor the
-STDP2690 behave as the stock bridges would. The compatible strings include the
-suffix "-ge-b850v3-fw" to make it clear that the driver is for the bridges with
-the firmware specific for the GE B850v3.
-
-The hardware do not provide control over the video processing pipeline, as the
-two bridges behaves as a single one. The only interfaces exposed by the
-hardware are EDID, HPD, and interrupts.
-
-stdp4028-ge-b850v3-fw required properties:
- - compatible : "megachips,stdp4028-ge-b850v3-fw"
- - reg : I2C bus address
- - interrupts : one interrupt should be described here, as in
- <0 IRQ_TYPE_LEVEL_HIGH>
- - ports : One input port(reg = <0>) and one output port(reg = <1>)
-
-stdp2690-ge-b850v3-fw required properties:
- compatible : "megachips,stdp2690-ge-b850v3-fw"
- - reg : I2C bus address
- - ports : One input port(reg = <0>) and one output port(reg = <1>)
-
-Example:
-
-&mux2_i2c2 {
- clock-frequency = <100000>;
-
- stdp4028@73 {
- compatible = "megachips,stdp4028-ge-b850v3-fw";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg = <0x73>;
-
- interrupt-parent = <&gpio2>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- stdp4028_in: endpoint {
- remote-endpoint = <&lvds0_out>;
- };
- };
- port@1 {
- reg = <1>;
- stdp4028_out: endpoint {
- remote-endpoint = <&stdp2690_in>;
- };
- };
- };
- };
-
- stdp2690@72 {
- compatible = "megachips,stdp2690-ge-b850v3-fw";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg = <0x72>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- stdp2690_in: endpoint {
- remote-endpoint = <&stdp4028_out>;
- };
- };
-
- port@1 {
- reg = <1>;
- stdp2690_out: endpoint {
- /* Connector for external display */
- };
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
new file mode 100644
index 000000000000..862ef441ac9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/microchip,sam9x75-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip SAM9X75 LVDS Controller
+
+maintainers:
+ - Dharma Balasubiramani <dharma.b@microchip.com>
+
+description:
+ The Low Voltage Differential Signaling Controller (LVDSC) manages data
+ format conversion from the LCD Controller internal DPI bus to OpenLDI
+ LVDS output signals. LVDSC functions include bit mapping, balanced mode
+ management, and serializer.
+
+properties:
+ compatible:
+ const: microchip,sam9x75-lvds
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+
+ clock-names:
+ items:
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/at91.h>
+ lvds-controller@f8060000 {
+ compatible = "microchip,sam9x75-lvds";
+ reg = <0xf8060000 0x100>;
+ interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+ clock-names = "pclk";
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
index 350fb8f400f0..5952e6448ed4 100644
--- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -111,11 +111,27 @@ properties:
unevaluatedProperties: false
port@1:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
DSI output port node to the panel or the next bridge
in the chain
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
required:
- port@0
- port@1
diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml
index 107dd138e6c6..70ec70922c13 100644
--- a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml
@@ -18,7 +18,7 @@ properties:
maxItems: 1
edid-emulation:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
The EDID emulation entry to use
Value Resolution Description
@@ -71,7 +71,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
new file mode 100644
index 000000000000..3fce9e698ea1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nxp,tda998x.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nxp,tda998x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP TDA998x HDMI transmitter
+
+maintainers:
+ - Russell King <linux@armlinux.org.uk>
+
+properties:
+ compatible:
+ const: nxp,tda998x
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ video-ports:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x230145
+ maximum: 0xffffff
+ description:
+ 24 bits value which defines how the video controller output is wired to
+ the TDA998x input.
+
+ audio-ports:
+ description:
+ Array of 2 values per DAI (Documentation/sound/soc/dai.rst).
+ The implementation allows one or two DAIs.
+ If two DAIs are defined, they must be of different type.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 2
+ items:
+ items:
+ - description: |
+ The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S
+ (see include/dt-bindings/display/tda998x.h).
+ enum: [ 1, 2 ]
+ - description:
+ The second value defines the tda998x AP_ENA reg content when the
+ DAI in question is used.
+ maximum: 0xff
+
+ '#sound-dai-cells':
+ enum: [ 0, 1 ]
+
+ nxp,calib-gpios:
+ maxItems: 1
+ description:
+ Calibration GPIO, which must correspond with the gpio used for the
+ TDA998x interrupt pin.
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Parallel input port
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ type: object
+ description: Parallel input port
+
+ port@1:
+ type: object
+ description: HDMI output port
+
+required:
+ - compatible
+ - reg
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/display/tda998x.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tda998x: hdmi-encoder@70 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ video-ports = <0x230145>;
+
+ #sound-dai-cells = <1>;
+ /* DAI-format / AP_ENA reg value */
+ audio-ports = <TDA998x_SPDIF 0x04>,
+ <TDA998x_I2S 0x03>;
+
+ port {
+ tda998x_in: endpoint {
+ remote-endpoint = <&lcdc_0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml b/Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml
new file mode 100644
index 000000000000..235018a81e85
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/parade,ps8622.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parade PS8622/PS8625 DisplayPort to LVDS Converter
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - parade,ps8622
+ - parade,ps8625
+
+ reg:
+ maxItems: 1
+
+ lane-count:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: Number of DP lanes to use.
+
+ use-external-pwm:
+ type: boolean
+ description: Backlight will be controlled by an external PWM.
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO connected to RST_ pin.
+
+ sleep-gpios:
+ maxItems: 1
+ description: GPIO connected to PD_ pin.
+
+ vdd12-supply: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Video port for LVDS output.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Video port for DisplayPort input.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - sleep-gpios
+ - ports
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: parade,ps8622
+ then:
+ properties:
+ lane-count:
+ const: 1
+ else:
+ properties:
+ lane-count:
+ const: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds-bridge@48 {
+ compatible = "parade,ps8625";
+ reg = <0x48>;
+ sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpy7 7 GPIO_ACTIVE_HIGH>;
+ lane-count = <2>;
+ use-external-pwm;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ bridge_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ bridge_in: endpoint {
+ remote-endpoint = <&dp_out>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8622.txt b/Documentation/devicetree/bindings/display/bridge/ps8622.txt
deleted file mode 100644
index c989c3807f2b..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/ps8622.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-ps8622-bridge bindings
-
-Required properties:
- - compatible: "parade,ps8622" or "parade,ps8625"
- - reg: first i2c address of the bridge
- - sleep-gpios: OF device-tree gpio specification for PD_ pin.
- - reset-gpios: OF device-tree gpio specification for RST_ pin.
-
-Optional properties:
- - lane-count: number of DP lanes to use
- - use-external-pwm: backlight will be controlled by an external PWM
- - video interfaces: Device node can contain video interface port
- nodes for panel according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
- lvds-bridge@48 {
- compatible = "parade,ps8622";
- reg = <0x48>;
- sleep-gpios = <&gpc3 6 1 0 0>;
- reset-gpios = <&gpc3 1 1 0 0>;
- lane-count = <1>;
- ports {
- port@0 {
- bridge_out: endpoint {
- remote-endpoint = <&panel_in>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
index 8ab156e0a8cf..5856450c5da7 100644
--- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/bridge/ps8640.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MIPI DSI to eDP Video Format Converter Device Tree Bindings
+title: MIPI DSI to eDP Video Format Converter
maintainers:
- Nicolas Boichat <drinkcat@chromium.org>
@@ -73,7 +73,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
index afeeb967393d..b95f10edd3a2 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
@@ -11,13 +11,18 @@ maintainers:
description: |
This binding describes the MIPI DSI/CSI-2 encoder embedded in the Renesas
- R-Car V3U SoC. The encoder can operate in either DSI or CSI-2 mode, with up
+ R-Car Gen4 SoCs. The encoder can operate in either DSI or CSI-2 mode, with up
to four data lanes.
+allOf:
+ - $ref: /schemas/display/dsi-controller.yaml#
+
properties:
compatible:
enum:
- renesas,r8a779a0-dsi-csi2-tx # for V3U
+ - renesas,r8a779g0-dsi-csi2-tx # for V4H
+ - renesas,r8a779h0-dsi-csi2-tx # for V4M
reg:
maxItems: 1
@@ -78,14 +83,14 @@ required:
- resets
- ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/r8a779a0-cpg-mssr.h>
#include <dt-bindings/power/r8a779a0-sysc.h>
- dsi0: dsi-encoder@fed80000 {
+ dsi@fed80000 {
compatible = "renesas,r8a779a0-dsi-csi2-tx";
reg = <0xfed80000 0x10000>;
power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>;
@@ -115,4 +120,51 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
+ #include <dt-bindings/power/r8a779g0-sysc.h>
+
+ dsi@fed80000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,r8a779g0-dsi-csi2-tx";
+ reg = <0xfed80000 0x10000>;
+ clocks = <&cpg CPG_MOD 415>,
+ <&cpg CPG_CORE R8A779G0_CLK_DSIEXT>,
+ <&cpg CPG_CORE R8A779G0_CLK_DSIREF>;
+ clock-names = "fck", "dsi", "pll";
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 415>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dsi0port1_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+
+ panel@0 {
+ reg = <0>;
+ compatible = "raspberrypi,dsi-7inch", "ilitek,ili9881c";
+ power-supply = <&vcc_lcd_reg>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0port1_out>;
+ };
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
new file mode 100644
index 000000000000..5a99d9b9635e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
@@ -0,0 +1,248 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/renesas,dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L MIPI DSI Encoder
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ This binding describes the MIPI DSI encoder embedded in the Renesas
+ RZ/G2L alike family of SoC's. The encoder can operate in DSI mode, with
+ up to four data lanes.
+
+allOf:
+ - $ref: /schemas/display/dsi-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a07g044-mipi-dsi # RZ/G2{L,LC}
+ - renesas,r9a07g054-mipi-dsi # RZ/V2L
+ - const: renesas,rzg2l-mipi-dsi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Sequence operation channel 0 interrupt
+ - description: Sequence operation channel 1 interrupt
+ - description: Video-Input operation channel 1 interrupt
+ - description: DSI Packet Receive interrupt
+ - description: DSI Fatal Error interrupt
+ - description: DSI D-PHY PPI interrupt
+ - description: Debug interrupt
+
+ interrupt-names:
+ items:
+ - const: seq0
+ - const: seq1
+ - const: vin1
+ - const: rcv
+ - const: ferr
+ - const: ppi
+ - const: debug
+
+ clocks:
+ items:
+ - description: DSI D-PHY PLL multiplied clock
+ - description: DSI D-PHY system clock
+ - description: DSI AXI bus clock
+ - description: DSI Register access clock
+ - description: DSI Video clock
+ - description: DSI D-PHY Escape mode transmit clock
+
+ clock-names:
+ items:
+ - const: pllclk
+ - const: sysclk
+ - const: aclk
+ - const: pclk
+ - const: vclk
+ - const: lpclk
+
+ resets:
+ items:
+ - description: MIPI_DSI_CMN_RSTB
+ - description: MIPI_DSI_ARESET_N
+ - description: MIPI_DSI_PRESET_N
+
+ reset-names:
+ items:
+ - const: rst
+ - const: arst
+ - const: prst
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Parallel input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: DSI output port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ dsi0: dsi@10850000 {
+ compatible = "renesas,r9a07g044-mipi-dsi", "renesas,rzg2l-mipi-dsi";
+ reg = <0x10850000 0x20000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "seq0", "seq1", "vin1", "rcv",
+ "ferr", "ppi", "debug";
+ clocks = <&cpg CPG_MOD R9A07G044_MIPI_DSI_PLLCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_SYSCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_ACLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_PCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_VCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_LPCLK>;
+ clock-names = "pllclk", "sysclk", "aclk", "pclk", "vclk", "lpclk";
+ resets = <&cpg R9A07G044_MIPI_DSI_CMN_RSTB>,
+ <&cpg R9A07G044_MIPI_DSI_ARESET_N>,
+ <&cpg R9A07G044_MIPI_DSI_PRESET_N>;
+ reset-names = "rst", "arst", "prst";
+ power-domains = <&cpg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&du_out_dsi0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&adv7535_in>;
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi1: dsi@10860000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,r9a07g044-mipi-dsi", "renesas,rzg2l-mipi-dsi";
+ reg = <0x10860000 0x20000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "seq0", "seq1", "vin1", "rcv",
+ "ferr", "ppi", "debug";
+ clocks = <&cpg CPG_MOD R9A07G044_MIPI_DSI_PLLCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_SYSCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_ACLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_PCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_VCLK>,
+ <&cpg CPG_MOD R9A07G044_MIPI_DSI_LPCLK>;
+ clock-names = "pllclk", "sysclk", "aclk", "pclk", "vclk", "lpclk";
+ resets = <&cpg R9A07G044_MIPI_DSI_CMN_RSTB>,
+ <&cpg R9A07G044_MIPI_DSI_ARESET_N>,
+ <&cpg R9A07G044_MIPI_DSI_PRESET_N>;
+ reset-names = "rst", "arst", "prst";
+ power-domains = <&cpg>;
+
+ panel@0 {
+ compatible = "rocktech,jh057n00900";
+ reg = <0>;
+ vcc-supply = <&reg_2v8_p>;
+ iovcc-supply = <&reg_1v8_p>;
+ reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&du_out_dsi1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
new file mode 100644
index 000000000000..ad279f0993fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml
@@ -0,0 +1,309 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung MIPI DSIM bridge controller
+
+maintainers:
+ - Inki Dae <inki.dae@samsung.com>
+ - Jagan Teki <jagan@amarulasolutions.com>
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+
+description: |
+ Samsung MIPI DSIM bridge controller can be found it on Exynos
+ and i.MX8M Mini/Nano/Plus SoC's.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - samsung,exynos3250-mipi-dsi
+ - samsung,exynos4210-mipi-dsi
+ - samsung,exynos5410-mipi-dsi
+ - samsung,exynos5422-mipi-dsi
+ - samsung,exynos5433-mipi-dsi
+ - samsung,exynos7870-mipi-dsi
+ - fsl,imx8mm-mipi-dsim
+ - fsl,imx8mp-mipi-dsim
+ - items:
+ - enum:
+ - fsl,imx7d-mipi-dsim
+ - fsl,imx8mn-mipi-dsim
+ - const: fsl,imx8mm-mipi-dsim
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ clocks:
+ minItems: 2
+ maxItems: 5
+
+ clock-names:
+ minItems: 2
+ maxItems: 5
+
+ samsung,phy-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: phandle to the samsung phy-type
+
+ power-domains:
+ maxItems: 1
+
+ samsung,power-domain:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the associated samsung power domain
+
+ vddcore-supply:
+ description: MIPI DSIM Core voltage supply (e.g. 1.1V)
+
+ vddio-supply:
+ description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
+
+ samsung,burst-clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ DSIM high speed burst mode frequency. If absent,
+ the pixel clock from the attached device or bridge
+ will be used instead.
+
+ samsung,esc-clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ DSIM escape mode frequency.
+
+ samsung,pll-clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ DSIM oscillator clock frequency. If absent, the clock frequency
+ of sclk_mipi will be used instead.
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: dsim
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input port node to receive pixel data from the
+ display controller. Exactly one endpoint must be
+ specified.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ DSI output port node to the panel or the next bridge
+ in the chain.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ uniqueItems: true
+ items:
+ enum: [ 1, 2, 3, 4 ]
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 5
+ description:
+ The Samsung MIPI DSI IP requires that all the data lanes have
+ the same polarity.
+
+ dependencies:
+ lane-polarities: [data-lanes]
+
+required:
+ - clock-names
+ - clocks
+ - compatible
+ - interrupts
+ - reg
+ - samsung,esc-clock-frequency
+
+allOf:
+ - $ref: ../dsi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: bus
+ - const: pll
+ - const: byte
+ - const: esc
+
+ ports:
+ required:
+ - port@0
+
+ required:
+ - ports
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos5433-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 5
+
+ clock-names:
+ items:
+ - const: bus_clk
+ - const: phyclk_mipidphy0_bitclkdiv8
+ - const: phyclk_mipidphy0_rxclkesc0
+ - const: sclk_rgb_vclk_to_dsim0
+ - const: sclk_mipi
+
+ ports:
+ required:
+ - port@0
+
+ required:
+ - ports
+ - vddcore-supply
+ - vddio-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos5410-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: bus_clk
+ - const: pll_clk
+
+ required:
+ - vddcore-supply
+ - vddio-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos4210-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: bus_clk
+ - const: sclk_mipi
+
+ required:
+ - vddcore-supply
+ - vddio-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos3250-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: bus_clk
+ - const: pll_clk
+
+ required:
+ - vddcore-supply
+ - vddio-supply
+ - samsung,phy-type
+
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos5433.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ dsi@13900000 {
+ compatible = "samsung,exynos5433-mipi-dsi";
+ reg = <0x13900000 0xC0>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&mipi_phy 1>;
+ phy-names = "dsim";
+ clocks = <&cmu_disp CLK_PCLK_DSIM0>,
+ <&cmu_disp CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8>,
+ <&cmu_disp CLK_PHYCLK_MIPIDPHY0_RXCLKESC0>,
+ <&cmu_disp CLK_SCLK_RGB_VCLK_TO_DSIM0>,
+ <&cmu_disp CLK_SCLK_DSIM0>;
+ clock-names = "bus_clk",
+ "phyclk_mipidphy0_bitclkdiv8",
+ "phyclk_mipidphy0_rxclkesc0",
+ "sclk_rgb_vclk_to_dsim0",
+ "sclk_mipi";
+ power-domains = <&pd_disp>;
+ vddcore-supply = <&ldo6_reg>;
+ vddio-supply = <&ldo7_reg>;
+ samsung,burst-clock-frequency = <512000000>;
+ samsung,esc-clock-frequency = <16000000>;
+ samsung,pll-clock-frequency = <24000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&te_irq>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_to_mic: endpoint {
+ remote-endpoint = <&mic_to_dsi>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
new file mode 100644
index 000000000000..a5fe46de3535
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/sil,sii8620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Image SiI8620 HDMI/MHL bridge
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ const: sil,sii8620
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xtal
+
+ cvcc10-supply:
+ description: Digital Core Supply Voltage (1.0V)
+
+ interrupts:
+ maxItems: 1
+
+ iovcc18-supply:
+ description: I/O Supply Voltage (1.8V)
+
+ reset-gpios:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ unevaluatedProperties: false
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port for HDMI (encoder) input
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MHL to connector port
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - cvcc10-supply
+ - interrupts
+ - iovcc18-supply
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@39 {
+ reg = <0x39>;
+ compatible = "sil,sii8620";
+ cvcc10-supply = <&ldo36_reg>;
+ iovcc18-supply = <&ldo34_reg>;
+ interrupt-parent = <&gpf0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ reset-gpios = <&gpv7 0 GPIO_ACTIVE_LOW>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "xtal";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mhl_to_musb_con: endpoint {
+ remote-endpoint = <&musb_con_to_mhl>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
index 5a69547ad3d7..17ea06719b56 100644
--- a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml
@@ -81,9 +81,22 @@ properties:
properties:
port@0:
- $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
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:
$ref: /schemas/graph.yaml#/properties/port
description: HDMI output port
@@ -96,7 +109,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml
index f88ddfe4818b..176181d25530 100644
--- a/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml
@@ -71,7 +71,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
deleted file mode 100644
index b05052f7d62f..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Silicon Image SiI8620 HDMI/MHL bridge bindings
-
-Required properties:
- - compatible: "sil,sii8620"
- - reg: i2c address of the bridge
- - cvcc10-supply: Digital Core Supply Voltage (1.0V)
- - iovcc18-supply: I/O Supply Voltage (1.8V)
- - interrupts: interrupt specifier of INT pin
- - reset-gpios: gpio specifier of RESET pin
- - clocks, clock-names: specification and name of "xtal" clock
- - video interfaces: Device node can contain video interface port
- node for HDMI encoder according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
- sii8620@39 {
- reg = <0x39>;
- compatible = "sil,sii8620";
- cvcc10-supply = <&ldo36_reg>;
- iovcc18-supply = <&ldo34_reg>;
- interrupt-parent = <&gpf0>;
- interrupts = <2 0>;
- reset-gpio = <&gpv7 0 0>;
- clocks = <&pmu_system_controller 0>;
- clock-names = "xtal";
-
- port {
- mhl_to_hdmi: endpoint {
- remote-endpoint = <&hdmi_to_mhl>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index 43cf4df9811a..20c7e0a77802 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -27,7 +27,11 @@ properties:
- const: adi,adv7123
- enum:
- adi,adv7123
+ - asl-tek,cs5263
- dumb-vga-dac
+ - parade,ps185hdm
+ - radxa,ra620
+ - realtek,rtd2171
- ti,opa362
- ti,ths8134
- ti,ths8135
diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
index 11fd68a70dca..8747b95ec20d 100644
--- a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
This document defines device tree properties for the Synopsys DesignWare MIPI
- DSI host controller. It doesn't constitue a device tree binding specification
+ DSI host controller. It doesn't constitute a device tree binding specification
by itself but is meant to be referenced by platform-specific device tree
bindings.
@@ -26,19 +26,9 @@ properties:
reg:
maxItems: 1
- clocks:
- items:
- - description: Module clock
- - description: DSI bus clock for either AHB and APB
- - description: Pixel clock for the DPI/RGB input
- minItems: 2
-
- clock-names:
- items:
- - const: ref
- - const: pclk
- - const: px_clk
- minItems: 2
+ clocks: true
+
+ clock-names: true
resets:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml b/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
new file mode 100644
index 000000000000..e2d293d623b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/solomon,ssd2825.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/solomon,ssd2825.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD2825 RGB to MIPI-DSI bridge
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: solomon,ssd2825
+
+ reg:
+ maxItems: 1
+
+ reset-gpios: true
+
+ dvdd-supply:
+ description: Regulator for 1.2V digital power supply.
+
+ avdd-supply:
+ description: Regulator for 1.2V analog power supply.
+
+ vddio-supply:
+ description: Regulator for 1.8V IO power supply.
+
+ spi-max-frequency:
+ maximum: 1000000
+
+ spi-cpha: true
+ spi-cpol: true
+
+ clocks:
+ maxItems: 1
+ description: Reference TX_CLK used before PLL is locked.
+
+ solomon,hs-zero-delay-ns:
+ description:
+ HS zero delay period
+ minimum: 0
+ maximum: 1700
+ default: 133
+
+ solomon,hs-prep-delay-ns:
+ description:
+ HS prep delay period
+ minimum: 0
+ maximum: 1728
+ default: 40
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Video port for RGB input
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ bus-width:
+ enum: [ 16, 18, 24 ]
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port for DSI output (panel or connector)
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi@2 {
+ compatible = "solomon,ssd2825";
+ reg = <2>;
+
+ spi-max-frequency = <1000000>;
+
+ spi-cpha;
+ spi-cpol;
+
+ reset-gpios = <&gpio 114 GPIO_ACTIVE_LOW>;
+
+ dvdd-supply = <&vdd_1v2>;
+ avdd-supply = <&vdd_1v2>;
+ vddio-supply = <&vdd_1v8_io>;
+
+ solomon,hs-zero-delay-ns = <300>;
+ solomon,hs-prep-delay-ns = <65>;
+
+ clocks = <&ssd2825_tx_clk>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ bridge_input: endpoint {
+ remote-endpoint = <&dpi_output>;
+ bus-width = <24>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ bridge_output: endpoint {
+ remote-endpoint = <&panel_input>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
index b00246faea57..33481381cccc 100644
--- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
@@ -26,7 +26,6 @@ properties:
reg-io-width:
description:
Width (in bytes) of the registers specified by the reg property.
- $ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 4]
default: 1
@@ -46,6 +45,19 @@ properties:
- const: isfr
additionalItems: true
+ ddc-i2c-bus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
+ description:
+ The HDMI DDC bus can be connected to either a system I2C master or the
+ functionally-reduced I2C master contained in the DWC HDMI. When connected
+ to a system I2C master this property contains a phandle to that I2C
+ master controller.
+
+ This property is deprecated, the system I2C master controller should
+ be referenced through the ddc-i2c-bus property of the HDMI connector
+ node.
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
deleted file mode 100644
index f5a02f61dd36..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Device-Tree bindings for the NXP TDA998x HDMI transmitter
-
-Required properties;
- - compatible: must be "nxp,tda998x"
-
- - reg: I2C address
-
-Required node:
- - port: Input port node with endpoint definition, as described
- in Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
- - interrupts: interrupt number and trigger type
- default: polling
-
- - pinctrl-0: pin control group to be used for
- screen plug/unplug interrupt.
-
- - pinctrl-names: must contain a "default" entry.
-
- - video-ports: 24 bits value which defines how the video controller
- output is wired to the TDA998x input - default: <0x230145>
-
- - audio-ports: array of 8-bit values, 2 values per one DAI[1].
- The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2].
- The second value defines the tda998x AP_ENA reg content when the DAI
- in question is used. The implementation allows one or two DAIs. If two
- DAIs are defined, they must be of different type.
-
- - nxp,calib-gpios: calibration GPIO, which must correspond with the
- gpio used for the TDA998x interrupt pin.
-
-[1] Documentation/sound/soc/dai.rst
-[2] include/dt-bindings/display/tda998x.h
-
-Example:
-
-#include <dt-bindings/display/tda998x.h>
-
- tda998x: hdmi-encoder {
- compatible = "nxp,tda998x";
- reg = <0x70>;
- interrupt-parent = <&gpio0>;
- interrupts = <27 2>; /* falling edge */
- pinctrl-0 = <&pmx_camera>;
- pinctrl-names = "default";
- video-ports = <0x230145>;
-
- #sound-dai-cells = <2>;
- /* DAI-format AP_ENA reg value */
- audio-ports = < TDA998x_SPDIF 0x04
- TDA998x_I2S 0x03>;
-
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml b/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml
index 542193d77cdf..d3f84d220723 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml
@@ -83,7 +83,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
index 48a97bb3e2e0..e69b6343a8eb 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -35,6 +35,9 @@ properties:
vcc-supply:
description: A 1.8V power supply (see regulator/regulator.yaml).
+ interrupts:
+ maxItems: 1
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -80,12 +83,12 @@ properties:
- const: 4
port@2:
- $ref: /schemas/graph.yaml#/properties/port
description: Video port for LVDS Channel-A output (panel or bridge).
+ $ref: '#/$defs/lvds-port'
port@3:
- $ref: /schemas/graph.yaml#/properties/port
description: Video port for LVDS Channel-B output (panel or bridge).
+ $ref: '#/$defs/lvds-port'
required:
- port@0
@@ -96,6 +99,32 @@ required:
- reg
- ports
+$defs:
+ lvds-port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ ti,lvds-termination-ohms:
+ description: The value of near end differential termination in ohms.
+ enum: [100, 200]
+ default: 200
+
+ ti,lvds-vod-swing-clock-microvolt:
+ description: LVDS diferential output voltage <min max> for clock
+ lanes in microvolts.
+ maxItems: 2
+
+ ti,lvds-vod-swing-data-microvolt:
+ description: LVDS diferential output voltage <min max> for data
+ lanes in microvolts.
+ maxItems: 2
+
allOf:
- if:
properties:
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 911564468c5e..c93878b6d718 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: SN65DSI86 DSI to eDP bridge chip
maintainers:
- - Sandeep Panda <spanda@codeaurora.org>
+ - Douglas Anderson <dianders@chromium.org>
description: |
The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP.
@@ -90,7 +90,7 @@ properties:
properties:
endpoint:
- $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ $ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
@@ -106,7 +106,6 @@ properties:
description:
If you have 1 logical lane the bridge supports routing
to either port 0 or port 1. Port 0 is suggested.
- See ../../media/video-interface.txt for details.
- minItems: 2
maxItems: 2
@@ -118,7 +117,6 @@ properties:
description:
If you have 2 logical lanes the bridge supports
reordering but only on physical ports 0 and 1.
- See ../../media/video-interface.txt for details.
- minItems: 4
maxItems: 4
@@ -132,7 +130,6 @@ properties:
description:
If you have 4 logical lanes the bridge supports
reordering in any way.
- See ../../media/video-interface.txt for details.
lane-polarities:
minItems: 1
@@ -141,7 +138,6 @@ properties:
enum:
- 0
- 1
- description: See ../../media/video-interface.txt
dependencies:
lane-polarities: [data-lanes]
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml
new file mode 100644
index 000000000000..721da44054e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml
@@ -0,0 +1,58 @@
+# 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:
+ maxItems: 1
+ 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
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
index a412a1da950f..6c1de0b21722 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
@@ -21,6 +21,9 @@ properties:
maxItems: 1
description: virtual channel number of a DSI peripheral
+ reset-gpios:
+ maxItems: 1
+
vddc-supply:
description: Regulator for 1.2V internal core power.
@@ -51,7 +54,7 @@ additionalProperties: false
examples:
- |
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
deleted file mode 100644
index 8f9abf28a8fa..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-TC358764 MIPI-DSI to LVDS panel bridge
-
-Required properties:
- - compatible: "toshiba,tc358764"
- - reg: the virtual channel number of a DSI peripheral
- - vddc-supply: core voltage supply, 1.2V
- - vddio-supply: I/O voltage supply, 1.8V or 3.3V
- - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
- - reset-gpios: a GPIO spec for the reset pin
-
-The device node can contain following 'port' child nodes,
-according to the OF graph bindings defined in [1]:
- 0: DSI Input, not required, if the bridge is DSI controlled
- 1: LVDS Output, mandatory
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
-
- bridge@0 {
- reg = <0>;
- compatible = "toshiba,tc358764";
- vddc-supply = <&vcc_1v2_reg>;
- vddio-supply = <&vcc_1v8_reg>;
- vddlvds-supply = <&vcc_3v3_reg>;
- reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
- #address-cells = <1>;
- #size-cells = <0>;
- port@1 {
- reg = <1>;
- lvds_ep: endpoint {
- remote-endpoint = <&panel_ep>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml
new file mode 100644
index 000000000000..866607400514
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358764.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC358764 MIPI-DSI to LVDS bridge
+
+maintainers:
+ - Andrzej Hajda <andrzej.hajda@intel.com>
+
+properties:
+ compatible:
+ const: toshiba,tc358764
+
+ reg:
+ description: Virtual channel number of a DSI peripheral
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vddc-supply:
+ description: Core voltage supply, 1.2V
+
+ vddio-supply:
+ description: I/O voltage supply, 1.8V or 3.3V
+
+ vddlvds-supply:
+ description: LVDS1/2 voltage supply, 3.3V
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port for MIPI DSI input, if the bridge DSI controlled
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port for LVDS output (panel or connector).
+
+ required:
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vddc-supply
+ - vddio-supply
+ - vddlvds-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@0 {
+ compatible = "toshiba,tc358764";
+ reg = <0>;
+
+ reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
+ vddc-supply = <&vcc_1v2_reg>;
+ vddio-supply = <&vcc_1v8_reg>;
+ vddlvds-supply = <&vcc_3v3_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ lvds_ep: endpoint {
+ remote-endpoint = <&panel_ep>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index ed280053ec62..70f229dc4e0c 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -4,26 +4,34 @@
$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358767.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba TC358767 eDP bridge bindings
+title: Toshiba TC358767/TC358867/TC9595 DSI/DPI/eDP bridge
maintainers:
- Andrey Gusakov <andrey.gusakov@cogentembedded.com>
-description: The TC358767 is bridge device which converts DSI/DPI to eDP/DP
+description: |
+ The TC358767/TC358867/TC9595 is bridge device which
+ converts DSI/DPI to eDP/DP .
properties:
compatible:
- const: toshiba,tc358767
+ oneOf:
+ - items:
+ - enum:
+ - toshiba,tc358867
+ - toshiba,tc9595
+ - const: toshiba,tc358767
+ - const: toshiba,tc358767
reg:
enum:
- - 0x68
- 0x0f
+ - 0x68
description: |
i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
clock-names:
- const: "ref"
+ const: ref
clocks:
maxItems: 1
@@ -41,6 +49,9 @@ properties:
description: |
OF device-tree gpio specification for RSTX pin(active low system reset)
+ interrupts:
+ maxItems: 1
+
toshiba,hpd-pin:
$ref: /schemas/types.yaml#/definitions/uint32
enum:
@@ -81,19 +92,37 @@ properties:
reference to a valid DPI output or input endpoint node.
port@2:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: |
eDP/DP output port. The remote endpoint phandle should be a
reference to a valid eDP panel input endpoint node. This port is
optional, treated as DP panel if not defined
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ toshiba,pre-emphasis:
+ description:
+ Display port output Pre-Emphasis settings for both DP lanes.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 2
+ maxItems: 2
+ items:
+ enum:
+ - 0 # No pre-emphasis
+ - 1 # 3.5dB pre-emphasis
+ - 2 # 6dB pre-emphasis
+
oneOf:
- required:
- port@0
- required:
- port@1
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
index 0b6f5bef120f..bb5d3b543800 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -60,6 +60,10 @@ properties:
data-lines:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 16, 18, 24 ]
+ deprecated: true
+
+ bus-width:
+ enum: [ 16, 18, 24 ]
port@1:
$ref: /schemas/graph.yaml#/properties/port
@@ -87,7 +91,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
index 10471c6c1ff9..258dd9cfd770 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba TC358775 DSI to LVDS bridge bindings
+title: Toshiba TC358775 DSI to LVDS bridge
maintainers:
- Vinay Simha BN <simhavcs@gmail.com>
description: |
- This binding supports DSI to LVDS bridge TC358775
+ This binding supports DSI to LVDS bridges TC358765 and TC358775
MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane.
Video frame size:
@@ -21,7 +21,9 @@ description: |
properties:
compatible:
- const: toshiba,tc358775
+ enum:
+ - toshiba,tc358765
+ - toshiba,tc358775
reg:
maxItems: 1
@@ -46,11 +48,27 @@ properties:
properties:
port@0:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: |
DSI Input. The remote endpoint phandle should be a
reference to a valid mipi_dsi_host device node.
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
@@ -70,10 +88,19 @@ required:
- reg
- vdd-supply
- vddio-supply
- - stby-gpios
- reset-gpios
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: toshiba,tc358765
+ then:
+ properties:
+ stby-gpios: false
+
additionalProperties: false
examples:
@@ -108,6 +135,7 @@ examples:
reg = <0>;
d2l_in_test: endpoint {
remote-endpoint = <&dsi0_out>;
+ data-lanes = <1 2 3 4>;
};
};
@@ -132,7 +160,6 @@ examples:
reg = <1>;
dsi0_out: endpoint {
remote-endpoint = <&d2l_in_test>;
- data-lanes = <0 1 2 3>;
};
};
};
@@ -167,6 +194,7 @@ examples:
reg = <0>;
d2l_in_dual: endpoint {
remote-endpoint = <&dsi0_out_dual>;
+ data-lanes = <1 2 3 4>;
};
};
@@ -198,7 +226,6 @@ examples:
reg = <1>;
dsi0_out_dual: endpoint {
remote-endpoint = <&d2l_in_dual>;
- data-lanes = <0 1 2 3>;
};
};
};
diff --git a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml
new file mode 100644
index 000000000000..5e8498c8303d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/waveshare,dsi2dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Waveshare MIPI-DSI to DPI Converter bridge
+
+maintainers:
+ - Joseph Guo <qijian.guo@nxp.com>
+
+description:
+ Waveshare bridge board is part of Waveshare panel which converts DSI to DPI.
+
+properties:
+ compatible:
+ const: waveshare,dsi2dpi
+
+ reg:
+ maxItems: 1
+ description: base I2C address of the device
+
+ power-supply: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Video port for MIPI DSI input
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ items:
+ - const: 1
+ - const: 2
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port for MIPI DPI output panel.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+ - power-supply
+
+additionalProperties: false
+
+examples:
+ - |
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@45 {
+ compatible = "waveshare,dsi2dpi";
+ reg = <0x45>;
+ power-supply = <&reg_3p3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ waveshare_from_dsim: endpoint {
+ data-lanes = <1 2>;
+ remote-endpoint = <&dsim_to_waveshare>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ waveshare_to_panel: endpoint {
+ remote-endpoint = <&panel_to_waveshare>;
+ };
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
index 0ab5f0663611..84c75f849891 100644
--- a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
+++ b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
@@ -1,4 +1,4 @@
-* Currus Logic CLPS711X Framebuffer
+* Cirrus Logic CLPS711X Framebuffer
Required properties:
- compatible: Shall contain "cirrus,ep7209-fb".
diff --git a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
index 22792a79e7ce..1f2b449dc910 100644
--- a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
+++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
@@ -31,10 +31,32 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Connection to controller providing DP signals
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: OF graph representation of signales routed to DP connector
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to controller providing DP signals
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to controller providing AUX signals
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- type
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
additionalProperties: false
@@ -52,4 +74,32 @@ examples:
};
};
+ - |
+ /* DP connecttor being driven by the USB+DP combo PHY */
+ connector {
+ compatible = "dp-connector";
+ label = "dp0";
+ type = "full-size";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&phy_ss_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&phy_sbu_out>;
+ };
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
index 83c0d008265b..3ee8f9225984 100644
--- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
+++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml
@@ -36,6 +36,9 @@ properties:
description: GPIO signal to enable DDC bus
maxItems: 1
+ hdmi-pwr-supply:
+ description: Power supply for the HDMI +5V Power pin
+
port:
$ref: /schemas/graph.yaml#/properties/port
description: Connection to controller providing HDMI signals
diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml
index 5e4afe9f98fb..0ece7b01790b 100644
--- a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml
+++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml
@@ -26,7 +26,7 @@ description:
properties:
$nodename:
- const: "aux-bus"
+ const: aux-bus
panel:
$ref: panel/panel-common.yaml#
diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml
index ca21671f6bdd..bb4d6e9e7d0c 100644
--- a/Documentation/devicetree/bindings/display/dsi-controller.yaml
+++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml
@@ -30,6 +30,15 @@ properties:
$nodename:
pattern: "^dsi(@.*)?$"
+ clock-master:
+ type: boolean
+ description:
+ Should be enabled if the host is being used in conjunction with
+ another DSI host to drive the same peripheral. Hardware supporting
+ such a configuration generally requires the data on both the busses
+ to be driven by the same clock. Only the DSI host instance
+ controlling this clock should contain this property.
+
"#address-cells":
const: 1
@@ -37,7 +46,7 @@ properties:
const: 0
patternProperties:
- "^panel@[0-3]$":
+ "^(panel|bridge)@[0-3]$":
description: Panels connected to the DSI link
type: object
@@ -52,15 +61,6 @@ patternProperties:
case the reg property can take multiple entries, one for each virtual
channel that the peripheral responds to.
- clock-master:
- type: boolean
- description:
- Should be enabled if the host is being used in conjunction with
- another DSI host to drive the same peripheral. Hardware supporting
- such a configuration generally requires the data on both the busses
- to be driven by the same clock. Only the DSI host instance
- controlling this clock should contain this property.
-
enforce-video-mode:
type: boolean
description:
diff --git a/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml b/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml
new file mode 100644
index 000000000000..faca0cb3f154
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml
@@ -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;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
deleted file mode 100644
index 9b6cba3f82af..000000000000
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-The Exynos display port interface should be configured based on
-the type of panel connected to it.
-
-We use two nodes:
- -dp-controller node
- -dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy: deprecated, use phys and phy-names
- -reg: deprecated
- Base address of DP PHY register.
- -samsung,enable-mask: deprecated
- The bit-mask used to enable/disable DP PHY.
-
-For the Panel initialization, we read data from dp-controller node.
-Required properties for dp-controller:
- -compatible:
- should be "samsung,exynos5-dp".
- -reg:
- physical base address of the controller and length
- of memory mapped region.
- -interrupts:
- interrupt combiner values.
- -clocks:
- from common clock binding: handle to dp clock.
- -clock-names:
- from common clock binding: Shall be "dp".
- -phys:
- from general PHY binding: the phandle for the PHY device.
- -phy-names:
- from general PHY binding: Should be "dp".
-
-Optional properties for dp-controller:
- -interlaced:
- interlace scan mode.
- Progressive if defined, Interlaced if not defined
- -vsync-active-high:
- VSYNC polarity configuration.
- High if defined, Low if not defined
- -hsync-active-high:
- HSYNC polarity configuration.
- High if defined, Low if not defined
- -samsung,hpd-gpio:
- Hotplug detect GPIO.
- Indicates which GPIO should be used for hotplug
- detection
- -video interfaces: Device node can contain video interface port
- nodes according to [1].
- - display-timings: timings for the connected panel as described by
- Documentation/devicetree/bindings/display/panel/display-timing.txt
-
-For the below properties, please refer to Analogix DP binding document:
- * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
- -phys (required)
- -phy-names (required)
- -hpd-gpios (optional)
- force-hpd (optional)
-
-Deprecated properties for DisplayPort:
--interlaced: deprecated prop that can parsed from drm_display_mode.
--vsync-active-high: deprecated prop that can parsed from drm_display_mode.
--hsync-active-high: deprecated prop that can parsed from drm_display_mode.
--samsung,ycbcr-coeff: deprecated prop that can parsed from drm_display_mode.
--samsung,dynamic-range: deprecated prop that can parsed from drm_display_mode.
--samsung,color-space: deprecated prop that can parsed from drm_display_info.
--samsung,color-depth: deprecated prop that can parsed from drm_display_info.
--samsung,link-rate: deprecated prop that can reading from monitor by dpcd method.
--samsung,lane-count: deprecated prop that can reading from monitor by dpcd method.
--samsung,hpd-gpio: deprecated name for hpd-gpios.
-
--------------------------------------------------------------------------------
-
-Example:
-
-SOC specific portion:
- dp-controller {
- compatible = "samsung,exynos5-dp";
- reg = <0x145b0000 0x10000>;
- interrupts = <10 3>;
- interrupt-parent = <&combiner>;
- clocks = <&clock 342>;
- clock-names = "dp";
-
- phys = <&dp_phy>;
- phy-names = "dp";
- };
-
-Board Specific portion:
- dp-controller {
- display-timings {
- native-mode = <&lcd_timing>;
- lcd_timing: 1366x768 {
- clock-frequency = <70589280>;
- hactive = <1366>;
- vactive = <768>;
- hfront-porch = <40>;
- hback-porch = <40>;
- hsync-len = <32>;
- vback-porch = <10>;
- vfront-porch = <12>;
- vsync-len = <6>;
- };
- };
-
- ports {
- port@0 {
- dp_out: endpoint {
- remote-endpoint = <&bridge_in>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
deleted file mode 100644
index be377786e8cd..000000000000
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Exynos MIPI DSI Master
-
-Required properties:
- - compatible: value should be one of the following
- "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */
- "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
- "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
- "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
- "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
- - reg: physical base address and length of the registers set for the device
- - interrupts: should contain DSI interrupt
- - clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names
- - clock-names: should include "bus_clk"and "sclk_mipi" entries
- the use of "pll_clk" is deprecated
- - phys: list of phy specifiers, must contain an entry for each required
- entry in phy-names
- - phy-names: should include "dsim" entry
- - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
- - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
- - samsung,pll-clock-frequency: specifies frequency of the oscillator clock
- - #address-cells, #size-cells: should be set respectively to <1> and <0>
- according to DSI host bindings (see MIPI DSI bindings [1])
- - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst
- mode
- - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
-
-Optional properties:
- - power-domains: a phandle to DSIM power domain node
-
-Child nodes:
- Should contain DSI peripheral nodes (see MIPI DSI bindings [1]).
-
-Video interfaces:
- Device node can contain following video interface port nodes according to [2]:
- 0: RGB input,
- 1: DSI output
-
-[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
-[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
-
- dsi@11c80000 {
- compatible = "samsung,exynos4210-mipi-dsi";
- reg = <0x11C80000 0x10000>;
- interrupts = <0 79 0>;
- clocks = <&clock 286>, <&clock 143>;
- clock-names = "bus_clk", "sclk_mipi";
- phys = <&mipi_phy 1>;
- phy-names = "dsim";
- vddcore-supply = <&vusb_reg>;
- vddio-supply = <&vmipi_reg>;
- power-domains = <&pd_lcd0>;
- #address-cells = <1>;
- #size-cells = <0>;
- samsung,pll-clock-frequency = <24000000>;
-
- panel@1 {
- reg = <0>;
- ...
- port {
- panel_ep: endpoint {
- remote-endpoint = <&dsi_ep>;
- };
- };
- };
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- decon_to_mic: endpoint {
- remote-endpoint = <&mic_to_decon>;
- };
- };
-
- port@1 {
- reg = <1>;
- dsi_ep: endpoint {
- reg = <0>;
- samsung,burst-clock-frequency = <500000000>;
- samsung,esc-clock-frequency = <20000000>;
- remote-endpoint = <&panel_ep>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt b/Documentation/devicetree/bindings/display/fsl,dcu.txt
deleted file mode 100644
index 63ec2a624aa9..000000000000
--- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Device Tree bindings for Freescale DCU DRM Driver
-
-Required properties:
-- compatible: Should be one of
- * "fsl,ls1021a-dcu".
- * "fsl,vf610-dcu".
-
-- reg: Address and length of the register set for dcu.
-- clocks: Handle to "dcu" and "pix" clock (in the order below)
- This can be the same clock (e.g. LS1021a)
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Should be "dcu" and "pix"
- See ../clocks/clock-bindings.txt for details.
-- big-endian Boolean property, LS1021A DCU registers are big-endian.
-- port Video port for the panel output
-
-Optional properties:
-- fsl,tcon: The phandle to the timing controller node.
-
-Examples:
-dcu: dcu@2ce0000 {
- compatible = "fsl,ls1021a-dcu";
- reg = <0x0 0x2ce0000 0x0 0x10000>;
- clocks = <&platform_clk 0>, <&platform_clk 0>;
- clock-names = "dcu", "pix";
- big-endian;
- fsl,tcon = <&tcon>;
-
- port {
- dcu_out: endpoint {
- remote-endpoint = <&panel_out>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 876015a44a1e..2dd0411ec651 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -21,6 +21,7 @@ properties:
- fsl,imx28-lcdif
- fsl,imx6sx-lcdif
- fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
- items:
- enum:
- fsl,imx6sl-lcdif
@@ -49,19 +50,44 @@ properties:
- const: disp_axi
minItems: 1
+ dmas:
+ items:
+ - description: DMA specifier for the RX DMA channel.
+
+ dma-names:
+ items:
+ - const: rx
+
interrupts:
+ items:
+ - description: LCDIF DMA interrupt
+ - description: LCDIF Error interrupt
+ minItems: 1
+
+ power-domains:
maxItems: 1
port:
$ref: /schemas/graph.yaml#/properties/port
description: The LCDIF output port
+ display:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to display panel
+ deprecated: true
+
+ display0:
+ $ref: panel/panel-common.yaml#
+ deprecated: true
+
+ lcd-supply:
+ deprecated: true
+
required:
- compatible
- reg
- clocks
- interrupts
- - port
additionalProperties: false
@@ -81,12 +107,91 @@ allOf:
maxItems: 3
required:
- clock-names
- else:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ required:
+ - clock-names
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sx-lcdif
+ - fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
+ then:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
+ - if:
+ properties:
+ compatible:
+ const: fsl,imx6sx-lcdif
+ then:
+ required:
+ - power-domains
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sl-lcdif
+ - fsl,imx8mm-lcdif
+ - fsl,imx8mn-lcdif
+ - fsl,imx8mp-lcdif
+ - fsl,imx93-lcdif
+ then:
+ required:
+ - power-domains
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx23-lcdif
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx28-lcdif
+ then:
+ properties:
+ dmas: false
+ dma-names: false
+ display: false
+ display0: false
+ lcd-supply: false
+
+ required:
+ - port
examples:
- |
@@ -101,6 +206,7 @@ examples:
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
clock-names = "pix", "axi", "disp_axi";
+ power-domains = <&pd_disp>;
port {
endpoint {
diff --git a/Documentation/devicetree/bindings/display/fsl,ls1021a-dcu.yaml b/Documentation/devicetree/bindings/display/fsl,ls1021a-dcu.yaml
new file mode 100644
index 000000000000..72d14babe993
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/fsl,ls1021a-dcu.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/fsl,ls1021a-dcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale DCU DRM Driver
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls1021a-dcu
+ - fsl,vf610-dcu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: dcu
+ - const: pix
+
+ big-endian: true
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Video port for the panel output
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ fsl,tcon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the timing controller node.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ display-controller@2ce0000 {
+ compatible = "fsl,ls1021a-dcu";
+ reg = <0x2ce0000 0x10000>;
+ clocks = <&platform_clk 0>, <&platform_clk 0>;
+ clock-names = "dcu", "pix";
+ big-endian;
+ fsl,tcon = <&tcon>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&panel_out>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/fsl,tcon.txt b/Documentation/devicetree/bindings/display/fsl,tcon.txt
deleted file mode 100644
index 475008747801..000000000000
--- a/Documentation/devicetree/bindings/display/fsl,tcon.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Device Tree bindings for Freescale TCON Driver
-
-Required properties:
-- compatible: Should be one of
- * "fsl,vf610-tcon".
-
-- reg: Address and length of the register set for tcon.
-- clocks: From common clock binding: handle to tcon ipg clock.
-- clock-names: From common clock binding: Shall be "ipg".
-
-Examples:
-timing-controller@4003d000 {
- compatible = "fsl,vf610-tcon";
- reg = <0x4003d000 0x1000>;
- clocks = <&clks VF610_CLK_TCON0>;
- clock-names = "ipg";
-};
diff --git a/Documentation/devicetree/bindings/display/fsl,vf610-tcon.yaml b/Documentation/devicetree/bindings/display/fsl,vf610-tcon.yaml
new file mode 100644
index 000000000000..06bd680524a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/fsl,vf610-tcon.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/fsl,vf610-tcon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale TCON
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,vf610-tcon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ipg
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/vf610-clock.h>
+
+ timing-controller@4003d000 {
+ compatible = "fsl,vf610-tcon";
+ reg = <0x4003d000 0x1000>;
+ clocks = <&clks VF610_CLK_TCON0>;
+ clock-names = "ipg";
+ };
diff --git a/Documentation/devicetree/bindings/display/himax,hx8357.yaml b/Documentation/devicetree/bindings/display/himax,hx8357.yaml
new file mode 100644
index 000000000000..34c3b89bf003
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/himax,hx8357.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/himax,hx8357.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX8357D display panel
+
+description:
+ Display panels using a Himax HX8357D controller in SPI
+ mode, such as the Adafruit 3.5" TFT for Raspberry Pi.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - adafruit,yx350hv15
+ - himax,hx8357b
+ - const: himax,hx8357
+ - items:
+ - enum:
+ - himax,hx8369a
+ - const: himax,hx8369
+
+ reg:
+ maxItems: 1
+
+ dc-gpios:
+ maxItems: 1
+ description: D/C pin
+
+ rotation:
+ enum: [0, 90, 180, 270]
+
+ backlight:
+ description:
+ phandle of the backlight device attached to the panel
+
+ im-gpios:
+ maxItems: 3
+
+ reset-gpios:
+ maxItems: 1
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display@0 {
+ compatible = "adafruit,yx350hv15", "himax,hx8357";
+ reg = <0>;
+ spi-max-frequency = <32000000>;
+ dc-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
+ rotation = <90>;
+ backlight = <&backlight>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/himax,hx8357d.txt b/Documentation/devicetree/bindings/display/himax,hx8357d.txt
deleted file mode 100644
index e641f664763d..000000000000
--- a/Documentation/devicetree/bindings/display/himax,hx8357d.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Himax HX8357D display panels
-
-This binding is for display panels using a Himax HX8357D controller in SPI
-mode, such as the Adafruit 3.5" TFT for Raspberry Pi.
-
-Required properties:
-- compatible: "adafruit,yx350hv15", "himax,hx8357d"
-- dc-gpios: D/C pin
-- reg: address of the panel on the SPI bus
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in ../spi/spi-bus.txt must be specified.
-
-Optional properties:
-- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
-- backlight: phandle of the backlight device attached to the panel
-
-Example:
- display@0{
- compatible = "adafruit,yx350hv15", "himax,hx8357d";
- reg = <0>;
- spi-max-frequency = <32000000>;
- dc-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
- rotation = <90>;
- backlight = <&backlight>;
- };
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9486.yaml b/Documentation/devicetree/bindings/display/ilitek,ili9486.yaml
index aecff34f505d..7d78edc403dc 100644
--- a/Documentation/devicetree/bindings/display/ilitek,ili9486.yaml
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9486.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/ilitek,ili9486.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ilitek ILI9486 display panels device tree bindings
+title: Ilitek ILI9486 display panels
maintainers:
- Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
@@ -50,15 +50,10 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
- };
spi {
#address-cells = <1>;
#size-cells = <0>;
-
display@0{
compatible = "waveshare,rpi-lcd-35", "ilitek,ili9486";
reg = <0>;
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-display-subsystem.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-display-subsystem.yaml
new file mode 100644
index 000000000000..92a0a797d099
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-display-subsystem.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx-display-subsystem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX DRM master device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The freescale i.MX DRM master device is a virtual device needed to list all
+ IPU or other display interface nodes that comprise the graphics subsystem.
+
+properties:
+ compatible:
+ const: fsl,imx-display-subsystem
+
+ ports:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Should contain a list of phandles pointing to camera
+ sensor interface ports of IPU devices.
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ display-subsystem {
+ compatible = "fsl,imx-display-subsystem";
+ ports = <&ipu_di0>;
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
deleted file mode 100644
index f4df9e83bcd2..000000000000
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Freescale imx21 Framebuffer
-
-This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
-
-Required properties:
-- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : One interrupt of the fb dev
-
-Required nodes:
-- display: Phandle to a display node as described in
- Documentation/devicetree/bindings/display/panel/display-timing.txt
- Additional, the display node has to define properties:
- - bits-per-pixel: Bits per pixel
- - fsl,pcr: LCDC PCR value
- A display node may optionally define
- - fsl,aus-mode: boolean to enable AUS mode (only for imx21)
-
-Optional properties:
-- lcd-supply: Regulator for LCD supply voltage.
-- fsl,dmacr: DMA Control Register value. This is optional. By default, the
- register is not modified as recommended by the datasheet.
-- fsl,lpccr: Contrast Control Register value. This property provides the
- default value for the contrast control register.
- If that property is omitted, the register is zeroed.
-- fsl,lscr1: LCDC Sharp Configuration Register value.
-
-Example:
-
- imxfb: fb@10021000 {
- compatible = "fsl,imx21-fb";
- interrupts = <61>;
- reg = <0x10021000 0x1000>;
- display = <&display0>;
- };
-
- ...
-
- display0: display0 {
- model = "Primeview-PD050VL1";
- bits-per-pixel = <16>;
- fsl,pcr = <0xf0c88080>; /* non-standard but required */
- display-timings {
- native-mode = <&timing_disp0>;
- timing_disp0: 640x480 {
- hactive = <640>;
- vactive = <480>;
- hback-porch = <112>;
- hfront-porch = <36>;
- hsync-len = <32>;
- vback-porch = <33>;
- vfront-porch = <33>;
- vsync-len = <2>;
- clock-frequency = <25000000>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml
new file mode 100644
index 000000000000..c2b29622bceb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx-lcdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX LCD Controller, found on i.MX1, i.MX21, i.MX25 and i.MX27
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Pengutronix Kernel Team <kernel@pengutronix.de>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx1-fb
+ - fsl,imx21-fb
+ - items:
+ - enum:
+ - fsl,imx25-fb
+ - fsl,imx27-fb
+ - const: fsl,imx21-fb
+ - items:
+ - const: fsl,imx25-lcdc
+ - const: fsl,imx21-lcdc
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
+ - const: per
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
+ display:
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ lcd-supply:
+ description:
+ Regulator for LCD supply voltage.
+
+ fsl,dmacr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Override value for DMA Control Register
+
+ fsl,lpccr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Contrast Control Register value.
+
+ fsl,lscr1:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ LCDC Sharp Configuration Register value.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx1-lcdc
+ - fsl,imx21-lcdc
+ then:
+ properties:
+ display: false
+ fsl,dmacr: false
+ fsl,lpccr: false
+ fsl,lscr1: false
+
+ required:
+ - port
+
+ else:
+ properties:
+ port: false
+
+ required:
+ - display
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - interrupts
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ lcdc@53fbc000 {
+ compatible = "fsl,imx25-lcdc", "fsl,imx21-lcdc";
+ reg = <0x53fbc000 0x4000>;
+ interrupts = <39>;
+ clocks = <&clks 103>, <&clks 66>, <&clks 49>;
+ clock-names = "ipg", "ahb", "per";
+
+ port {
+ parallel_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ - |
+ imxfb: fb@10021000 {
+ compatible = "fsl,imx21-fb";
+ interrupts = <61>;
+ reg = <0x10021000 0x1000>;
+ display = <&display0>;
+ clocks = <&clks 103>, <&clks 49>, <&clks 66>;
+ clock-names = "ipg", "ahb", "per";
+ };
+
+ display0: display0 {
+ model = "Primeview-PD050VL1";
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xf0c88080>; /* non-standard but required */
+
+ display-timings {
+ native-mode = <&timing_disp0>;
+ timing_disp0: timing0 {
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <112>;
+ hfront-porch = <36>;
+ hsync-len = <32>;
+ vback-porch = <33>;
+ vfront-porch = <33>;
+ vsync-len = <2>;
+ clock-frequency = <25000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
new file mode 100644
index 000000000000..bbcfe7e2958b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx-parallel-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parallel display support
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx-parallel-display
+
+ interface-pix-fmt:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - rgb24
+ - rgb565
+ - bgr666
+ - lvds666
+
+ ddc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle describing the i2c bus handling the display data channel
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: input port connected to the IPU display interface
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: output port connected to a panel
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ display {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb24";
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&ipu_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
index af7fe9c4d196..180c4b510fb1 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
@@ -31,14 +31,6 @@ properties:
clock-names:
maxItems: 2
- ddc-i2c-bus:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- The HDMI DDC bus can be connected to either a system I2C master or the
- functionally-reduced I2C master contained in the DWC HDMI. When connected
- to a system I2C master this property contains a phandle to that I2C
- master controller.
-
gpr:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -87,7 +79,7 @@ required:
- interrupts
- ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6q-ipu.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx6q-ipu.yaml
new file mode 100644
index 000000000000..ec78645d4de0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6q-ipu.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx6q-ipu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX IPUv3
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx51-ipu
+ - fsl,imx53-ipu
+ - fsl,imx6q-ipu
+ - items:
+ - const: fsl,imx6qp-ipu
+ - const: fsl,imx6q-ipu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: bus
+ - const: di0
+ - const: di1
+
+ resets:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ fsl,prg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to prg node associated with this IPU instance
+
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI0
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI1
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: DI0
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: DI1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ display-controller@18000000 {
+ compatible = "fsl,imx53-ipu";
+ reg = <0x18000000 0x080000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <11 10>;
+ resets = <&src 2>;
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&display_in>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6q-ldb.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx6q-ldb.yaml
new file mode 100644
index 000000000000..1646f41d8f72
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6q-ldb.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx6q-ldb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale LVDS Display Bridge (ldb)
+
+description:
+ The LVDS Display Bridge device tree node contains up to two lvds-channel
+ nodes describing each of the two LVDS encoder channels of the bridge.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx53-ldb
+ - items:
+ - enum:
+ - fsl,imx6q-ldb
+ - const: fsl,imx53-ldb
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle points to the iomuxc-gpr region containing the LVDS
+ control register.
+
+ clocks:
+ minItems: 6
+ maxItems: 8
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: di0_pll
+ - const: di1_pll
+ - const: di0_sel
+ - const: di1_sel
+ - const: di0
+ - const: di1
+ - items:
+ - const: di0_pll
+ - const: di1_pll
+ - const: di0_sel
+ - const: di1_sel
+ - const: di2_sel
+ - const: di3_sel
+ - const: di0
+ - const: di1
+
+ fsl,dual-channel:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ if it exists, only LVDS channel 0 should
+ be configured - one input will be distributed on both outputs in dual
+ channel mode
+
+patternProperties:
+ '^lvds-channel@[0-1]$':
+ type: object
+ description:
+ Each LVDS Channel has to contain either an of graph link to a panel device node
+ or a display-timings node that describes the video timings for the connected
+ LVDS display as well as the fsl,data-mapping and fsl,data-width properties.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ display-timings:
+ $ref: /schemas/display/panel/display-timings.yaml#
+
+ fsl,data-mapping:
+ enum:
+ - spwg
+ - jeida
+
+ fsl,data-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: should be <18> or <24>
+ enum:
+ - 18
+ - 24
+
+ fsl,panel:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to lcd panel
+
+ patternProperties:
+ '^port@[0-4]$':
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ On i.MX5, the internal two-input-multiplexer is used. Due to hardware
+ limitations, only one input port (port@[0,1]) can be used for each channel
+ (lvds-channel@[0,1], respectively).
+ On i.MX6, there should be four input ports (port@[0-3]) that correspond
+ to the four LVDS multiplexer inputs.
+ A single output port (port@2 on i.MX5, port@4 on i.MX6) must be connected
+ to a panel input port. Optionally, the output port can be left out if
+ display-timings are used instead.
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - gpr
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx5-clock.h>
+
+ ldb@53fa8008 {
+ compatible = "fsl,imx53-ldb";
+ reg = <0x53fa8008 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpr = <&gpr>;
+ clocks = <&clks IMX5_CLK_LDB_DI0_SEL>,
+ <&clks IMX5_CLK_LDB_DI1_SEL>,
+ <&clks IMX5_CLK_IPU_DI0_SEL>,
+ <&clks IMX5_CLK_IPU_DI1_SEL>,
+ <&clks IMX5_CLK_LDB_DI0_GATE>,
+ <&clks IMX5_CLK_LDB_DI1_GATE>;
+ clock-names = "di0_pll", "di1_pll",
+ "di0_sel", "di1_sel",
+ "di0", "di1";
+
+ /* Using an of-graph endpoint link to connect the panel */
+ lvds-channel@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&ipu_di0_lvds0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ /* Using display-timings and fsl,data-mapping/width instead */
+ lvds-channel@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+
+ display-timings {/* ... */
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&ipu_di1_lvds1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6qp-pre.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx6qp-pre.yaml
new file mode 100644
index 000000000000..73bc73ff6e69
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6qp-pre.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx6qp-pre.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX PRE (Prefetch Resolve Engine)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6qp-pre
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: axi
+ fsl,iram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle pointing to the mmio-sram device node, that should be
+ used for the PRE SRAM double buffer.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pre@21c8000 {
+ compatible = "fsl,imx6qp-pre";
+ reg = <0x021c8000 0x1000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clks IMX6QDL_CLK_PRE0>;
+ clock-names = "axi";
+ fsl,iram = <&ocram2>;
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6qp-prg.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx6qp-prg.yaml
new file mode 100644
index 000000000000..582da8c489f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6qp-prg.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx6qp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX PRG (Prefetch Resolve Gasket)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6qp-prg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: axi
+
+ fsl,pres:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
+ description:
+ phandles to the PRE units attached to this PRG, with the fixed
+ PRE as the first entry and the muxable PREs following.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+
+ prg@21cc000 {
+ compatible = "fsl,imx6qp-prg";
+ reg = <0x021cc000 0x1000>;
+ clocks = <&clks IMX6QDL_CLK_PRG0_APB>, <&clks IMX6QDL_CLK_PRG0_AXI>;
+ clock-names = "ipg", "axi";
+ fsl,pres = <&pre1>, <&pre2>, <&pre3>;
+ };
+
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml
new file mode 100644
index 000000000000..4f99682a308d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pai.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Audio Interface
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+description:
+ The HDMI TX Parallel Audio Interface (HTX_PAI) is a bridge between the
+ Audio Subsystem to the HDMI TX Controller.
+
+properties:
+ compatible:
+ const: fsl,imx8mp-hdmi-pai
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: apb
+
+ power-domains:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output to the HDMI TX controller.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/power/imx8mp-power.h>
+
+ audio-bridge@32fc4800 {
+ compatible = "fsl,imx8mp-hdmi-pai";
+ reg = <0x32fc4800 0x800>;
+ interrupt-parent = <&irqsteer_hdmi>;
+ interrupts = <14>;
+ clocks = <&clk IMX8MP_CLK_HDMI_APB>;
+ clock-names = "apb";
+ power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PAI>;
+
+ port {
+ pai_to_hdmi_tx: endpoint {
+ remote-endpoint = <&hdmi_tx_from_pai>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index 000000000000..56da1636014c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+ - Lucas Stach <l.stach@pengutronix.de>
+
+description:
+ The HDMI parallel video interface is a timing and sync generator block in the
+ i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+ compatible:
+ const: fsl,imx8mp-hdmi-pvi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input from the LCDIF controller.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output to the HDMI TX controller.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/imx8mp-power.h>
+
+ display-bridge@32fc4000 {
+ compatible = "fsl,imx8mp-hdmi-pvi";
+ reg = <0x32fc4000 0x44>;
+ interrupt-parent = <&irqsteer_hdmi>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ pvi_from_lcdif3: endpoint {
+ remote-endpoint = <&lcdif3_to_pvi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ pvi_to_hdmi_tx: endpoint {
+ remote-endpoint = <&hdmi_tx_from_pvi>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-axi-performance-counter.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-axi-performance-counter.yaml
new file mode 100644
index 000000000000..1d6501afc7f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-axi-performance-counter.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-axi-performance-counter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller AXI Performance Counter
+
+description: |
+ Performance counters are provided to allow measurement of average bandwidth
+ and latency during operation. The following features are supported:
+
+ * Manual and timer controlled measurement mode.
+
+ * Measurement counters:
+ - GLOBAL_COUNTER for overall measurement time
+ - BUSY_COUNTER for number of data bus busy cycles
+ - DATA_COUNTER for number of data transfer cycles
+ - TRANSFER_COUNTER for number of transfers
+ - ADDRBUSY_COUNTER for number of address bus busy cycles
+ - LATENCY_COUNTER for average latency
+
+ * Counter overflow detection.
+
+ * Outstanding Transfer Counters (OTC) which are used for latency measurement
+ have to run immediately after reset, but can be disabled by software when
+ there is no need for latency measurement.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-axi-performance-counter
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+
+ pmu@5618f000 {
+ compatible = "fsl,imx8qxp-dc-axi-performance-counter";
+ reg = <0x5618f000 0x90>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blit-engine.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blit-engine.yaml
new file mode 100644
index 000000000000..45db6da39e20
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blit-engine.yaml
@@ -0,0 +1,204 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-blit-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Blit Engine
+
+description: |
+ A blit operation (block based image transfer) reads up to 3 source images
+ from memory and computes one destination image from it, which is written
+ back to memory. The following basic operations are supported:
+
+ * Buffer Fill
+ Fills a buffer with constant color
+
+ * Buffer Copy
+ Copies one source to a destination buffer.
+
+ * Image Blend
+ Combines two source images by a blending equation and writes result to
+ destination (which can be one of the sources).
+
+ * Image Rop2/3
+ Combines up to three source images by a logical equation (raster operation)
+ and writes result to destination (which can be one of the sources).
+
+ * Image Flip
+ Mirrors the source image in horizontal and/or vertical direction.
+
+ * Format Convert
+ Convert between the supported color and buffer formats.
+
+ * Color Transform
+ Modify colors by linear or non-linear transformations.
+
+ * Image Scale
+ Changes size of the source image.
+
+ * Image Rotate
+ Rotates the source image by any angle.
+
+ * Image Filter
+ Performs an FIR filter operation on the source image.
+
+ * Image Warp
+ Performs a re-sampling of the source image with any pattern. The sample
+ point positions are read from a compressed coordinate buffer.
+
+ * Buffer Pack
+ Writes an image with color components stored in up to three different
+ buffers (planar formats) into a single buffer (packed format).
+
+ * Chroma Resample
+ Converts between different YUV formats that differ in chroma sampling rate
+ (4:4:4, 4:2:2, 4:2:0).
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-blit-engine
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^blitblend@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-blitblend
+
+ "^clut@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-clut
+
+ "^fetchdecode@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetchdecode
+
+ "^fetcheco@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetcheco
+
+ "^fetchwarp@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetchwarp
+
+ "^filter@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-filter
+
+ "^hscaler@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-hscaler
+
+ "^matrix@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-matrix
+
+ "^rop@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-rop
+
+ "^store@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-store
+
+ "^vscaler@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-vscaler
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ blit-engine@56180820 {
+ compatible = "fsl,imx8qxp-dc-blit-engine";
+ reg = <0x56180820 0x13c>, <0x56181000 0x3400>;
+ reg-names = "pec", "cfg";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fetchdecode@56180820 {
+ compatible = "fsl,imx8qxp-dc-fetchdecode";
+ reg = <0x56180820 0x10>, <0x56181000 0x404>;
+ reg-names = "pec", "cfg";
+ };
+
+ store@56180940 {
+ compatible = "fsl,imx8qxp-dc-store";
+ reg = <0x56180940 0x1c>, <0x56184000 0x5c>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <0>, <1>, <2>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml
new file mode 100644
index 000000000000..095e65939fba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-blitblend.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-blitblend.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Blit Blend Unit
+
+description:
+ Combines two input frames to a single output frame, all frames having the
+ same dimension.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-blitblend
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ blitblend@56180920 {
+ compatible = "fsl,imx8qxp-dc-blitblend";
+ reg = <0x56180920 0x10>, <0x56183c00 0x3c>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-clut.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-clut.yaml
new file mode 100644
index 000000000000..21d42aa11b52
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-clut.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-clut.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Color Lookup Table
+
+description: |
+ The unit implements 3 look-up tables with 256 x 10 bit entries each. These
+ can be used for different kinds of applications. From 10-bit input values
+ only upper 8 bits are used.
+
+ The unit supports color lookup, index lookup, dithering and alpha masking.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-clut
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ clut@56180880 {
+ compatible = "fsl,imx8qxp-dc-clut";
+ reg = <0x56180880 0x10>, <0x56182400 0x404>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
new file mode 100644
index 000000000000..27118f4c0d28
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-command-sequencer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Command Sequencer
+
+description: |
+ The Command Sequencer is designed to autonomously process command lists.
+ By that it can load setups into the DC configuration and synchronize to
+ hardware events. This releases a system's CPU from workload, because it
+ does not need to wait for certain events. Also it simplifies SW architecture,
+ because no interrupt handlers are required. Setups are read via AXI bus,
+ while write access to configuration registers occurs directly via an internal
+ bus. This saves bandwidth for the AXI interconnect and improves the system
+ architecture in terms of safety aspects.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-command-sequencer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 5
+
+ interrupt-names:
+ items:
+ - const: error
+ - const: sw0
+ - const: sw1
+ - const: sw2
+ - const: sw3
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle pointing to the mmio-sram device node
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+
+ command-sequencer@56180400 {
+ compatible = "fsl,imx8qxp-dc-command-sequencer";
+ reg = <0x56180400 0x1a4>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <36>, <37>, <38>, <39>, <40>;
+ interrupt-names = "error", "sw0", "sw1", "sw2", "sw3";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-constframe.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-constframe.yaml
new file mode 100644
index 000000000000..94f678563608
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-constframe.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-constframe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Constant Frame
+
+description: |
+ The Constant Frame unit is used instead of a Fetch unit where generation of
+ constant color frames only is sufficient. This is the case for the background
+ planes of content and safety streams in a Display Controller.
+
+ The color can be setup to any RGBA value.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-constframe
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ constframe@56180960 {
+ compatible = "fsl,imx8qxp-dc-constframe";
+ reg = <0x56180960 0xc>, <0x56184400 0x20>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-display-engine.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-display-engine.yaml
new file mode 100644
index 000000000000..91f3bb77d8d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-display-engine.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-display-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Display Engine
+
+description:
+ All Processing Units that operate in a display clock domain. Pixel pipeline
+ is driven by a video timing and cannot be stalled. Implements all display
+ specific processing.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-display-engine
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: top
+ - const: cfg
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: shdload
+ - const: framecomplete
+ - const: seqcomplete
+
+ power-domains:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^dither@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-dither
+
+ "^framegen@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-framegen
+
+ "^gammacor@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-gammacor
+
+ "^matrix@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-matrix
+
+ "^signature@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-signature
+
+ "^tcon@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-tcon
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ display-engine@5618b400 {
+ compatible = "fsl,imx8qxp-dc-display-engine";
+ reg = <0x5618b400 0x14>, <0x5618b800 0x1c00>;
+ reg-names = "top", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <15>, <16>, <17>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ power-domains = <&pd IMX_SC_R_DC_0_PLL_0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ framegen@5618b800 {
+ compatible = "fsl,imx8qxp-dc-framegen";
+ reg = <0x5618b800 0x98>;
+ clocks = <&dc0_disp_lpcg IMX_LPCG_CLK_0>;
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <18>, <19>, <20>, <21>, <41>, <42>, <43>, <44>;
+ interrupt-names = "int0", "int1", "int2", "int3",
+ "primsync_on", "primsync_off",
+ "secsync_on", "secsync_off";
+ };
+
+ tcon@5618c800 {
+ compatible = "fsl,imx8qxp-dc-tcon";
+ reg = <0x5618c800 0x588>;
+
+ port {
+ dc0_disp0_dc0_pixel_combiner_ch0: endpoint {
+ remote-endpoint = <&dc0_pixel_combiner_ch0_dc0_disp0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-dither.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-dither.yaml
new file mode 100644
index 000000000000..8e4468d91836
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-dither.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-dither.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Dither Unit
+
+description: |
+ The unit can increase the physical color resolution of a display from 5, 6, 7
+ or 8 bits per RGB channel to a virtual resolution of 10 bits. The physical
+ resolution can be set individually for each channel.
+
+ The resolution is increased by mixing the two physical colors that are nearest
+ to the virtual color code in a variable ratio either by time (temporal
+ dithering) or by position (spatial dithering).
+
+ An optimized algorithm for temporal dithering minimizes noise artifacts on the
+ output image.
+
+ The dither operation can be individually enabled or disabled for each pixel
+ using the alpha input bit.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-dither
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ dither@5618c400 {
+ compatible = "fsl,imx8qxp-dc-dither";
+ reg = <0x5618c400 0x14>;
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-extdst.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-extdst.yaml
new file mode 100644
index 000000000000..dfc2d4f94f8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-extdst.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-extdst.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller External Destination Interface
+
+description: |
+ The External Destination unit is the interface between the internal pixel
+ processing pipeline of the Pixel Engine, which is 30-bit RGB plus 8-bit Alpha,
+ and a Display Engine.
+
+ It comprises the following built-in Gamma apply function.
+
+ +------X-----------------------+
+ | | ExtDst Unit |
+ | V |
+ | +-------+ |
+ | | Gamma | |
+ | +-------+ |
+ | | |
+ | V +
+ +------X-----------------------+
+
+ The output format is 24-bit RGB plus 1-bit Alpha. Conversion from 10 to 8
+ bits is done by LSBit truncation. Alpha output bit is 1 for input 255, 0
+ otherwise.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-extdst
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: shdload
+ - const: framecomplete
+ - const: seqcomplete
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ extdst@56180980 {
+ compatible = "fsl,imx8qxp-dc-extdst";
+ reg = <0x56180980 0x1c>, <0x56184800 0x28>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <3>, <4>, <5>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-fetchunit.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-fetchunit.yaml
new file mode 100644
index 000000000000..97fb6a4598d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-fetchunit.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-fetchunit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Fetch Unit
+
+description: |
+ The Fetch Unit is the interface between the AXI bus for source buffer access
+ and the internal pixel processing pipeline, which is 30-bit RGB plus 8-bit
+ Alpha.
+
+ It is used to generate foreground planes in Display Controllers and source
+ planes in Blit Engines, and comprises the following built-in functions to
+ convert a wide range of frame buffer types.
+
+ +---------X-----------------------------------------+
+ | | Fetch Unit |
+ | V |
+ | +---------+ |
+ | | | |
+ | | Decode | Decompression [Decode] |
+ | | | |
+ | +---------+ |
+ | | |
+ | V |
+ | +---------+ |
+ | | Clip & | Clip Window [All] |
+ | | Overlay | Plane composition [Layer, Warp] |
+ | | | |
+ | +---------+ |
+ | | |
+ | V |
+ | +---------+ |
+ | | Re- | Flip/Rotate/Repl./Drop [All] |
+ X--> | sample | Perspective/Affine warping [Persp] |
+ | | | | Arbitrary warping [Warp, Persp] |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | | |
+ | | | Palette | Color Palette [Layer, Decode] |
+ | | | | |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | Extract | Raw to RGBA/YUV [All] |
+ | | | & | Bit width expansion [All] |
+ | | | Expand | |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | | Planar to packed |
+ | |->| Combine | [Decode, Warp, Persp] |
+ | | | | |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | | YUV422 to YUV444 |
+ | | | Chroma | [Decode, Persp] |
+ | | | | |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | | YUV to RGB |
+ | | | Color | [Warp, Persp, Decode, Layer] |
+ | | | | |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | | Gamma removal |
+ | | | Gamma | [Warp, Persp, Decode, Layer] |
+ | | | | |
+ | | +---------+ |
+ | | | |
+ | | V |
+ | | +---------+ |
+ | | | | Alpla multiply, RGB pre-multiply |
+ | ->| Multiply| [Warp, Persp, Decode, Layer] |
+ | | | |
+ | --------- |
+ | | |
+ | V |
+ | +---------+ |
+ | | | Bilinear filter |
+ | | Filter | [Warp, Persp] |
+ | | | |
+ | +---------+ |
+ | | |
+ | V |
+ +---------X-----------------------------------------+
+
+ Note that different derivatives of the Fetch Unit exist. Each implements a
+ specific subset only of the pipeline stages shown above. Restrictions for the
+ units are specified in [square brackets].
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-dc-fetchdecode
+ - fsl,imx8qxp-dc-fetcheco
+ - fsl,imx8qxp-dc-fetchlayer
+ - fsl,imx8qxp-dc-fetchwarp
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+ fsl,prg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Optional Prefetch Resolve Gasket associated with the Fetch Unit.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ fetchlayer@56180ac0 {
+ compatible = "fsl,imx8qxp-dc-fetchlayer";
+ reg = <0x56180ac0 0xc>, <0x56188400 0x404>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-filter.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-filter.yaml
new file mode 100644
index 000000000000..5c54d5179ee3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-filter.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-filter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Filter Unit
+
+description: |
+ 5x5 FIR filter with 25 programmable coefficients.
+
+ Typical applications are image blurring, sharpening or support for edge
+ detection algorithms.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-filter
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ filter@56180900 {
+ compatible = "fsl,imx8qxp-dc-filter";
+ reg = <0x56180900 0x10>, <0x56183800 0x30>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-framegen.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-framegen.yaml
new file mode 100644
index 000000000000..9d1dc3a9de90
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-framegen.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-framegen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Frame Generator
+
+description:
+ The Frame Generator (FrameGen) module generates a programmable video timing
+ and optionally allows to synchronize the generated video timing to external
+ synchronization signals.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-framegen
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 8
+
+ interrupt-names:
+ items:
+ - const: int0
+ - const: int1
+ - const: int2
+ - const: int3
+ - const: primsync_on
+ - const: primsync_off
+ - const: secsync_on
+ - const: secsync_off
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ framegen@5618b800 {
+ compatible = "fsl,imx8qxp-dc-framegen";
+ reg = <0x5618b800 0x98>;
+ clocks = <&dc0_disp_lpcg IMX_LPCG_CLK_0>;
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <18>, <19>, <20>, <21>, <41>, <42>, <43>, <44>;
+ interrupt-names = "int0", "int1", "int2", "int3",
+ "primsync_on", "primsync_off",
+ "secsync_on", "secsync_off";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-gammacor.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-gammacor.yaml
new file mode 100644
index 000000000000..25ad85742912
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-gammacor.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-gammacor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Gamma Correction Unit
+
+description: The unit supports non-linear color transformation.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-gammacor
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ gammacor@5618c000 {
+ compatible = "fsl,imx8qxp-dc-gammacor";
+ reg = <0x5618c000 0x20>;
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-layerblend.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-layerblend.yaml
new file mode 100644
index 000000000000..2a6ab8a0ed7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-layerblend.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-layerblend.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Layer Blend Unit
+
+description: Combines two input frames to a single output frame.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-layerblend
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ layerblend@56180ba0 {
+ compatible = "fsl,imx8qxp-dc-layerblend";
+ reg = <0x56180ba0 0x10>, <0x5618a400 0x20>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-matrix.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-matrix.yaml
new file mode 100644
index 000000000000..d773389dd0dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-matrix.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-matrix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Color Matrix
+
+description:
+ The unit supports linear color transformation, alpha pre-multiply and
+ alpha masking.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-matrix
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ oneOf:
+ - const: cfg # matrix in display engine
+ - items: # matrix in pixel engine
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ matrix@5618bc00 {
+ compatible = "fsl,imx8qxp-dc-matrix";
+ reg = <0x5618bc00 0x3c>;
+ reg-names = "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-pixel-engine.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-pixel-engine.yaml
new file mode 100644
index 000000000000..633443a6cc38
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-pixel-engine.yaml
@@ -0,0 +1,250 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-pixel-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Pixel Engine
+
+description:
+ All Processing Units that operate in the AXI bus clock domain. Pixel
+ pipelines have the ability to stall when a destination is busy. Implements
+ all communication to memory resources and most of the image processing
+ functions. Interconnection of Processing Units is re-configurable.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-pixel-engine
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^blit-engine@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-blit-engine
+
+ "^constframe@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-constframe
+
+ "^extdst@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-extdst
+
+ "^fetchdecode@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetchdecode
+
+ "^fetcheco@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetcheco
+
+ "^fetchlayer@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetchlayer
+
+ "^fetchwarp@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-fetchwarp
+
+ "^hscaler@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-hscaler
+
+ "^layerblend@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-layerblend
+
+ "^matrix@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-matrix
+
+ "^safety@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-safety
+
+ "^vscaler@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-vscaler
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+
+ pixel-engine@56180800 {
+ compatible = "fsl,imx8qxp-dc-pixel-engine";
+ reg = <0x56180800 0xac00>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ constframe@56180960 {
+ compatible = "fsl,imx8qxp-dc-constframe";
+ reg = <0x56180960 0xc>, <0x56184400 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ extdst@56180980 {
+ compatible = "fsl,imx8qxp-dc-extdst";
+ reg = <0x56180980 0x1c>, <0x56184800 0x28>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <3>, <4>, <5>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
+
+ constframe@561809a0 {
+ compatible = "fsl,imx8qxp-dc-constframe";
+ reg = <0x561809a0 0xc>, <0x56184c00 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ extdst@561809c0 {
+ compatible = "fsl,imx8qxp-dc-extdst";
+ reg = <0x561809c0 0x1c>, <0x56185000 0x28>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <6>, <7>, <8>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
+
+ constframe@561809e0 {
+ compatible = "fsl,imx8qxp-dc-constframe";
+ reg = <0x561809e0 0xc>, <0x56185400 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ extdst@56180a00 {
+ compatible = "fsl,imx8qxp-dc-extdst";
+ reg = <0x56180a00 0x1c>, <0x56185800 0x28>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <9>, <10>, <11>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
+
+ constframe@56180a20 {
+ compatible = "fsl,imx8qxp-dc-constframe";
+ reg = <0x56180a20 0xc>, <0x56185c00 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ extdst@56180a40 {
+ compatible = "fsl,imx8qxp-dc-extdst";
+ reg = <0x56180a40 0x1c>, <0x56186000 0x28>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <12>, <13>, <14>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
+
+ fetchwarp@56180a60 {
+ compatible = "fsl,imx8qxp-dc-fetchwarp";
+ reg = <0x56180a60 0x10>, <0x56186400 0x190>;
+ reg-names = "pec", "cfg";
+ };
+
+ fetchlayer@56180ac0 {
+ compatible = "fsl,imx8qxp-dc-fetchlayer";
+ reg = <0x56180ac0 0xc>, <0x56188400 0x404>;
+ reg-names = "pec", "cfg";
+ };
+
+ layerblend@56180ba0 {
+ compatible = "fsl,imx8qxp-dc-layerblend";
+ reg = <0x56180ba0 0x10>, <0x5618a400 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ layerblend@56180bc0 {
+ compatible = "fsl,imx8qxp-dc-layerblend";
+ reg = <0x56180bc0 0x10>, <0x5618a800 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ layerblend@56180be0 {
+ compatible = "fsl,imx8qxp-dc-layerblend";
+ reg = <0x56180be0 0x10>, <0x5618ac00 0x20>;
+ reg-names = "pec", "cfg";
+ };
+
+ layerblend@56180c00 {
+ compatible = "fsl,imx8qxp-dc-layerblend";
+ reg = <0x56180c00 0x10>, <0x5618b000 0x20>;
+ reg-names = "pec", "cfg";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-rop.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-rop.yaml
new file mode 100644
index 000000000000..7115950ecae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-rop.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-rop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Raster Operation Unit
+
+description: |
+ The unit can combine up to three input frames to a single output frame, all
+ having the same dimension.
+
+ The unit supports logic operations, arithmetic operations and packing.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-rop
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ rop@56180860 {
+ compatible = "fsl,imx8qxp-dc-rop";
+ reg = <0x56180860 0x10>, <0x56182000 0x20>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-safety.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-safety.yaml
new file mode 100644
index 000000000000..66c12948ab09
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-safety.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-safety.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Safety Unit
+
+description:
+ The unit allows corresponding processing units to be configured in a path
+ leading to multiple endpoints.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-safety
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ safety@56180800 {
+ compatible = "fsl,imx8qxp-dc-safety";
+ reg = <0x56180800 0x1c>;
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml
new file mode 100644
index 000000000000..76cbe11a6364
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-scaling-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Scaling Engine
+
+description: |
+ The unit can change the dimension of the input frame by nearest or linear
+ re-sampling with 1/32 sub pixel precision.
+
+ Internally it consist of two independent blocks for horizontal and vertical
+ scaling. The sequence of both operations is arbitrary.
+
+ Any frame dimensions between 1 and 16384 pixels in width and height are
+ supported, except that the vertical scaler has a frame width maximum
+ depending of the system's functional limitations.
+
+ In general all scale factors are supported inside the supported frame
+ dimensions. In range of scale factors 1/16..16 the filtered output colors
+ are LSBit precise (e.g. DC ripple free).
+
+ +-----------+
+ | Line |
+ | Buffer |
+ +-----------+
+ ^
+ |
+ V
+ |\ +-----------+
+ ------+ | | |
+ | | +-->| Vertical |----
+ | ----+ | | Scaler | |
+ | | |/ +-----------+ |
+ | | |
+ | | |
+ | | | |\
+ | ------------- -------------+-----+ |
+ Input --+ X | +--> Output
+ | ------------- -------------+-----+ |
+ | | | |/
+ | | |
+ | | |\ +-----------+ |
+ | ----+ | | | |
+ | | +-->| Horizontal|----
+ ------+ | | Scaler |
+ |/ +-----------+
+
+ The unit supports downscaling, upscaling, sub pixel translation and bob
+ de-interlacing.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-dc-hscaler
+ - fsl,imx8qxp-dc-vscaler
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ hscaler@561808c0 {
+ compatible = "fsl,imx8qxp-dc-hscaler";
+ reg = <0x561808c0 0x10>, <0x56183000 0x18>;
+ reg-names = "pec", "cfg";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-signature.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-signature.yaml
new file mode 100644
index 000000000000..c495822fdc80
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-signature.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-signature.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Signature Unit
+
+description: |
+ In order to control the correctness of display output, signature values can
+ be computed for each frame and compared against reference values. In case of
+ a mismatch (signature violation) a HW event can be triggered, for example a
+ SW interrupt.
+
+ This unit supports signature computation, reference check, evaluation windows,
+ alpha masking and panic modes.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-signature
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: shdload
+ - const: valid
+ - const: error
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ signature@5618d000 {
+ compatible = "fsl,imx8qxp-dc-signature";
+ reg = <0x5618d000 0x140>;
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <22>, <23>, <24>;
+ interrupt-names = "shdload", "valid", "error";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml
new file mode 100644
index 000000000000..42d1b10906be
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-store.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Store Unit
+
+description: |
+ The Store unit is the interface between the internal pixel processing
+ pipeline, which is 30-bit RGB plus 8-bit Alpha, and the AXI bus for
+ destination buffer access. It is used for the destination of Blit Engines.
+ It comprises a set of built-in functions to generate a wide range of buffer
+ formats. Note, that these are exactly inverse to corresponding functions in
+ the Fetch Unit.
+
+ +------X-------------------------+
+ | | Store Unit |
+ | V |
+ | +-------+ |
+ | | Gamma | Gamma apply |
+ | +-------+ |
+ | | |
+ | V |
+ | +-------+ |
+ | | Color | RGB to YUV |
+ | +-------+ |
+ | | |
+ | V |
+ | +-------+ |
+ | | Chroma| YUV444 to 422 |
+ | +-------+ |
+ | | |
+ | V |
+ | +-------+ |
+ | | Reduce| Bit width reduction |
+ | | | dithering |
+ | +-------+ |
+ | | |
+ | V |
+ | +-------+ |
+ | | Pack | RGBA/YUV to RAW |
+ | | Encode| or Compression |
+ | +-------+ |
+ | | |
+ | V |
+ +------X-------------------------+
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-store
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pec
+ - const: cfg
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: shdload
+ - const: framecomplete
+ - const: seqcomplete
+
+ fsl,lts:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Optional Linear Tile Store associated with the Store Unit.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ store@56180940 {
+ compatible = "fsl,imx8qxp-dc-store";
+ reg = <0x56180940 0x1c>, <0x56184000 0x5c>;
+ reg-names = "pec", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <0>, <1>, <2>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-tcon.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-tcon.yaml
new file mode 100644
index 000000000000..7a3b77ea92c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-tcon.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc-tcon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller Timing Controller
+
+description:
+ The TCon can generate a wide range of customized synchronization signals and
+ does the mapping of the color bits to the output.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-tcon
+
+ reg:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: video output
+
+required:
+ - compatible
+ - reg
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ tcon@5618c800 {
+ compatible = "fsl,imx8qxp-dc-tcon";
+ reg = <0x5618c800 0x588>;
+
+ port {
+ dc0_disp0_dc0_pixel_combiner_ch0: endpoint {
+ remote-endpoint = <&dc0_pixel_combiner_ch0_dc0_disp0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc.yaml
new file mode 100644
index 000000000000..0a72f9f0b5fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc.yaml
@@ -0,0 +1,236 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller
+
+description: |
+ The Freescale i.MX8qxp Display Controller(DC) is comprised of three main
+ components that include a blit engine for 2D graphics accelerations, display
+ controller for display output processing, as well as a command sequencer.
+
+ Display buffers Source buffers
+ (AXI read master) (AXI read master)
+ | .......... | | | |
+ +---------------------------+------------+------------------+-+-+------+
+ | Display Controller (DC) | .......... | | | | |
+ | | | | | | |
+ | @@@@@@@@@@@ +----------+------------+------------+ | | | |
+ A | | Command | | V V | | | | |
+ X <-+->| Sequencer | | @@@@@@@@@@@@@@@@@@@@@@@@@@@@ | V V V |
+ I | | (AXI CLK) | | | | | @@@@@@@@@@ |
+ | @@@@@@@@@@@ | | Pixel Engine | | | | |
+ | | | | (AXI CLK) | | | | |
+ | V | @@@@@@@@@@@@@@@@@@@@@@@@@@@@ | | | |
+ A | *********** | | | | | | | Blit | |
+ H <-+->| Configure | | V V V V | | Engine | |
+ B | | (CFG CLK) | | 00000000000 11111111111 | | (AXI CLK)| |
+ | *********** | | Display | | Display | | | | |
+ | | | Engine | | Engine | | | | |
+ | | | (Disp CLK)| | (Disp CLK)| | | | |
+ | @@@@@@@@@@@ | 00000000000 11111111111 | @@@@@@@@@@ |
+ I | | Common | | | | | | |
+ R <-+--| Control | | | Display | | | |
+ Q | | (AXI CLK) | | | Controller | | | |
+ | @@@@@@@@@@@ +------------------------------------+ | |
+ | | | ^ | |
+ +--------------------------+----------------+-------+---------+--------+
+ ^ | | | |
+ | V V | V
+ Clocks & Resets Display Display Panic Destination
+ Output0 Output1 Control buffer
+ (AXI write master)
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: axi
+ - const: cfg
+
+ power-domains:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^command-sequencer@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-command-sequencer
+
+ "^display-engine@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-display-engine
+
+ "^interrupt-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-intc
+
+ "^pixel-engine@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-pixel-engine
+
+ "^pmu@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: fsl,imx8qxp-dc-axi-performance-counter
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ display-controller@56180000 {
+ compatible = "fsl,imx8qxp-dc";
+ reg = <0x56180000 0x40000>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_4>;
+ power-domains = <&pd IMX_SC_R_DC_0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ interrupt-controller@56180040 {
+ compatible = "fsl,imx8qxp-dc-intc";
+ reg = <0x56180040 0x60>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
+ interrupt-controller;
+ interrupt-parent = <&dc0_irqsteer>;
+ #interrupt-cells = <1>;
+ interrupts = <448>, <449>, <450>, <64>,
+ <65>, <66>, <67>, <68>,
+ <69>, <70>, <193>, <194>,
+ <195>, <196>, <197>, <72>,
+ <73>, <74>, <75>, <76>,
+ <77>, <78>, <79>, <80>,
+ <81>, <199>, <200>, <201>,
+ <202>, <203>, <204>, <205>,
+ <206>, <207>, <208>, <5>,
+ <0>, <1>, <2>, <3>,
+ <4>, <82>, <83>, <84>,
+ <85>, <209>, <210>, <211>,
+ <212>;
+ interrupt-names = "store9_shdload",
+ "store9_framecomplete",
+ "store9_seqcomplete",
+ "extdst0_shdload",
+ "extdst0_framecomplete",
+ "extdst0_seqcomplete",
+ "extdst4_shdload",
+ "extdst4_framecomplete",
+ "extdst4_seqcomplete",
+ "extdst1_shdload",
+ "extdst1_framecomplete",
+ "extdst1_seqcomplete",
+ "extdst5_shdload",
+ "extdst5_framecomplete",
+ "extdst5_seqcomplete",
+ "disengcfg_shdload0",
+ "disengcfg_framecomplete0",
+ "disengcfg_seqcomplete0",
+ "framegen0_int0",
+ "framegen0_int1",
+ "framegen0_int2",
+ "framegen0_int3",
+ "sig0_shdload",
+ "sig0_valid",
+ "sig0_error",
+ "disengcfg_shdload1",
+ "disengcfg_framecomplete1",
+ "disengcfg_seqcomplete1",
+ "framegen1_int0",
+ "framegen1_int1",
+ "framegen1_int2",
+ "framegen1_int3",
+ "sig1_shdload",
+ "sig1_valid",
+ "sig1_error",
+ "reserved",
+ "cmdseq_error",
+ "comctrl_sw0",
+ "comctrl_sw1",
+ "comctrl_sw2",
+ "comctrl_sw3",
+ "framegen0_primsync_on",
+ "framegen0_primsync_off",
+ "framegen0_secsync_on",
+ "framegen0_secsync_off",
+ "framegen1_primsync_on",
+ "framegen1_primsync_off",
+ "framegen1_secsync_on",
+ "framegen1_secsync_off";
+ };
+
+ pixel-engine@56180800 {
+ compatible = "fsl,imx8qxp-dc-pixel-engine";
+ reg = <0x56180800 0xac00>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
+ display-engine@5618b400 {
+ compatible = "fsl,imx8qxp-dc-display-engine";
+ reg = <0x5618b400 0x14>, <0x5618b800 0x1c00>;
+ reg-names = "top", "cfg";
+ interrupt-parent = <&dc0_intc>;
+ interrupts = <15>, <16>, <17>;
+ interrupt-names = "shdload", "framecomplete", "seqcomplete";
+ power-domains = <&pd IMX_SC_R_DC_0_PLL_0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
deleted file mode 100644
index 3c35338a2867..000000000000
--- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-Freescale i.MX DRM master device
-================================
-
-The freescale i.MX DRM master device is a virtual device needed to list all
-IPU or other display interface nodes that comprise the graphics subsystem.
-
-Required properties:
-- compatible: Should be "fsl,imx-display-subsystem"
-- ports: Should contain a list of phandles pointing to display interface ports
- of IPU devices
-
-example:
-
-display-subsystem {
- compatible = "fsl,imx-display-subsystem";
- ports = <&ipu_di0>;
-};
-
-
-Freescale i.MX IPUv3
-====================
-
-Required properties:
-- compatible: Should be "fsl,<chip>-ipu" where <chip> is one of
- - imx51
- - imx53
- - imx6q
- - imx6qp
-- reg: should be register base and length as documented in the
- datasheet
-- interrupts: Should contain sync interrupt and error interrupt,
- in this order.
-- resets: phandle pointing to the system reset controller and
- reset line index, see reset/fsl,imx-src.txt for details
-Additional required properties for fsl,imx6qp-ipu:
-- fsl,prg: phandle to prg node associated with this IPU instance
-Optional properties:
-- port@[0-3]: Port nodes with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
- Ports 0 and 1 should correspond to CSI0 and CSI1,
- ports 2 and 3 should correspond to DI0 and DI1, respectively.
-
-example:
-
-ipu: ipu@18000000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx53-ipu";
- reg = <0x18000000 0x080000000>;
- interrupts = <11 10>;
- resets = <&src 2>;
-
- ipu_di0: port@2 {
- reg = <2>;
-
- ipu_di0_disp0: endpoint {
- remote-endpoint = <&display_in>;
- };
- };
-};
-
-Freescale i.MX PRE (Prefetch Resolve Engine)
-============================================
-
-Required properties:
-- compatible: should be "fsl,imx6qp-pre"
-- reg: should be register base and length as documented in the
- datasheet
-- clocks : phandle to the PRE axi clock input, as described
- in Documentation/devicetree/bindings/clock/clock-bindings.txt and
- Documentation/devicetree/bindings/clock/imx6q-clock.yaml.
-- clock-names: should be "axi"
-- interrupts: should contain the PRE interrupt
-- fsl,iram: phandle pointing to the mmio-sram device node, that should be
- used for the PRE SRAM double buffer.
-
-example:
-
-pre@21c8000 {
- compatible = "fsl,imx6qp-pre";
- reg = <0x021c8000 0x1000>;
- interrupts = <GIC_SPI 90 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clks IMX6QDL_CLK_PRE0>;
- clock-names = "axi";
- fsl,iram = <&ocram2>;
-};
-
-Freescale i.MX PRG (Prefetch Resolve Gasket)
-============================================
-
-Required properties:
-- compatible: should be "fsl,imx6qp-prg"
-- reg: should be register base and length as documented in the
- datasheet
-- clocks : phandles to the PRG ipg and axi clock inputs, as described
- in Documentation/devicetree/bindings/clock/clock-bindings.txt and
- Documentation/devicetree/bindings/clock/imx6q-clock.yaml.
-- clock-names: should be "ipg" and "axi"
-- fsl,pres: phandles to the PRE units attached to this PRG, with the fixed
- PRE as the first entry and the muxable PREs following.
-
-example:
-
-prg@21cc000 {
- compatible = "fsl,imx6qp-prg";
- reg = <0x021cc000 0x1000>;
- clocks = <&clks IMX6QDL_CLK_PRG0_APB>,
- <&clks IMX6QDL_CLK_PRG0_AXI>;
- clock-names = "ipg", "axi";
- fsl,pres = <&pre1>, <&pre2>, <&pre3>;
-};
-
-Parallel display support
-========================
-
-Required properties:
-- compatible: Should be "fsl,imx-parallel-display"
-Optional properties:
-- interface-pix-fmt: How this display is connected to the
- display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
- and "lvds666".
-- edid: verbatim EDID data block describing attached display.
-- ddc: phandle describing the i2c bus handling the display data
- channel
-- port@[0-1]: Port nodes with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
- Port 0 is the input port connected to the IPU display interface,
- port 1 is the output port connected to a panel.
-
-example:
-
-disp0 {
- compatible = "fsl,imx-parallel-display";
- edid = [edid-data];
- interface-pix-fmt = "rgb24";
-
- port@0 {
- reg = <0>;
-
- display_in: endpoint {
- remote-endpoint = <&ipu_di0_disp0>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- display_out: endpoint {
- remote-endpoint = <&panel_in>;
- };
- };
-};
-
-panel {
- ...
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&display_out>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt b/Documentation/devicetree/bindings/display/imx/ldb.txt
deleted file mode 100644
index 8e6e7d797943..000000000000
--- a/Documentation/devicetree/bindings/display/imx/ldb.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-Device-Tree bindings for LVDS Display Bridge (ldb)
-
-LVDS Display Bridge
-===================
-
-The LVDS Display Bridge device tree node contains up to two lvds-channel
-nodes describing each of the two LVDS encoder channels of the bridge.
-
-Required properties:
- - #address-cells : should be <1>
- - #size-cells : should be <0>
- - compatible : should be "fsl,imx53-ldb" or "fsl,imx6q-ldb".
- Both LDB versions are similar, but i.MX6 has an additional
- multiplexer in the front to select any of the four IPU display
- interfaces as input for each LVDS channel.
- - gpr : should be <&gpr> on i.MX53 and i.MX6q.
- The phandle points to the iomuxc-gpr region containing the LVDS
- control register.
-- clocks, clock-names : phandles to the LDB divider and selector clocks and to
- the display interface selector clocks, as described in
- Documentation/devicetree/bindings/clock/clock-bindings.txt
- The following clocks are expected on i.MX53:
- "di0_pll" - LDB LVDS channel 0 mux
- "di1_pll" - LDB LVDS channel 1 mux
- "di0" - LDB LVDS channel 0 gate
- "di1" - LDB LVDS channel 1 gate
- "di0_sel" - IPU1 DI0 mux
- "di1_sel" - IPU1 DI1 mux
- On i.MX6q the following additional clocks are needed:
- "di2_sel" - IPU2 DI0 mux
- "di3_sel" - IPU2 DI1 mux
- The needed clock numbers for each are documented in
- Documentation/devicetree/bindings/clock/imx5-clock.yaml, and in
- Documentation/devicetree/bindings/clock/imx6q-clock.yaml.
-
-Optional properties:
- - pinctrl-names : should be "default" on i.MX53, not used on i.MX6q
- - pinctrl-0 : a phandle pointing to LVDS pin settings on i.MX53,
- not used on i.MX6q
- - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should
- be configured - one input will be distributed on both outputs in dual
- channel mode
-
-LVDS Channel
-============
-
-Each LVDS Channel has to contain either an of graph link to a panel device node
-or a display-timings node that describes the video timings for the connected
-LVDS display as well as the fsl,data-mapping and fsl,data-width properties.
-
-Required properties:
- - reg : should be <0> or <1>
- - port: Input and output port nodes with endpoint definitions as defined in
- Documentation/devicetree/bindings/graph.txt.
- On i.MX5, the internal two-input-multiplexer is used. Due to hardware
- limitations, only one input port (port@[0,1]) can be used for each channel
- (lvds-channel@[0,1], respectively).
- On i.MX6, there should be four input ports (port@[0-3]) that correspond
- to the four LVDS multiplexer inputs.
- A single output port (port@2 on i.MX5, port@4 on i.MX6) must be connected
- to a panel input port. Optionally, the output port can be left out if
- display-timings are used instead.
-
-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
- Documentation/devicetree/bindings/display/panel/display-timing.txt.
- - fsl,data-mapping : should be "spwg" or "jeida"
- This describes how the color bits are laid out in the
- serialized LVDS signal.
- - fsl,data-width : should be <18> or <24>
-
-example:
-
-gpr: iomuxc-gpr@53fa8000 {
- /* ... */
-};
-
-ldb: ldb@53fa8008 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx53-ldb";
- gpr = <&gpr>;
- clocks = <&clks IMX5_CLK_LDB_DI0_SEL>,
- <&clks IMX5_CLK_LDB_DI1_SEL>,
- <&clks IMX5_CLK_IPU_DI0_SEL>,
- <&clks IMX5_CLK_IPU_DI1_SEL>,
- <&clks IMX5_CLK_LDB_DI0_GATE>,
- <&clks IMX5_CLK_LDB_DI1_GATE>;
- clock-names = "di0_pll", "di1_pll",
- "di0_sel", "di1_sel",
- "di0", "di1";
-
- /* Using an of-graph endpoint link to connect the panel */
- lvds-channel@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- port@0 {
- reg = <0>;
-
- lvds0_in: endpoint {
- remote-endpoint = <&ipu_di0_lvds0>;
- };
- };
-
- port@2 {
- reg = <2>;
-
- lvds0_out: endpoint {
- remote-endpoint = <&panel_in>;
- };
- };
- };
-
- /* Using display-timings and fsl,data-mapping/width instead */
- lvds-channel@1 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <1>;
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
-
- display-timings {
- /* ... */
- };
-
- port@1 {
- reg = <1>;
-
- lvds1_in: endpoint {
- remote-endpoint = <&ipu_di1_lvds1>;
- };
- };
- };
-};
-
-panel: lvds-panel {
- /* ... */
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&lvds0_out>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
index 989ab312c1f4..4ae6328cde64 100644
--- a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
+++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 NXP
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: iMX8MQ Display Controller Subsystem (DCSS)
diff --git a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
index 3f93def2c5a2..319bd7c88fe3 100644
--- a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
+++ b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/ingenic,ipu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs Image Processing Unit (IPU) devicetree bindings
+title: Ingenic SoCs Image Processing Unit (IPU)
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
index c0bb02fb49f4..6d4c00f3fcc8 100644
--- a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
+++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs LCD controller devicetree bindings
+title: Ingenic SoCs LCD controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
index bc6622b010ca..2cf54ecc707a 100644
--- a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
+++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Devicetree bindings for Intel Keem Bay display controller
+title: Intel Keem Bay display controller
maintainers:
- Anitha Chrisanthus <anitha.chrisanthus@intel.com>
diff --git a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
index a222b52d8b8f..cc7e1f318fe4 100644
--- a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
+++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/intel,keembay-msscam.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Devicetree bindings for Intel Keem Bay MSSCAM
+title: Intel Keem Bay MSSCAM
maintainers:
- Anitha Chrisanthus <anitha.chrisanthus@intel.com>
diff --git a/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml b/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml
new file mode 100644
index 000000000000..ab842594feb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/lvds-data-mapping.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LVDS Data Mapping
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+
+description: |
+ LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+ incompatible data link layers have been used over time to transmit image data
+ to LVDS devices. This bindings supports devices compatible with the following
+ specifications.
+
+ [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+ 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+ [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+ Semiconductor
+ [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+ Electronics Standards Association (VESA)
+
+ Device compatible with those specifications have been marketed under the
+ FPD-Link and FlatLink brands.
+
+ This bindings also supports 30-bit data mapping compatible with JEIDA and
+ VESA.
+
+properties:
+ data-mapping:
+ enum:
+ - jeida-18
+ - jeida-24
+ - jeida-30
+ - vesa-24
+ - vesa-30
+ description: |
+ The color signals mapping order.
+
+ LVDS data mappings are defined as follows.
+
+ - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
+ [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
+
+ Slot 0 1 2 3 4 5 6
+ ________________ _________________
+ Clock \_______________________/
+ ______ ______ ______ ______ ______ ______ ______
+ DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+ DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+ DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+
+ - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
+ specifications. Data are transferred as follows on 4 LVDS lanes.
+
+ Slot 0 1 2 3 4 5 6
+ ________________ _________________
+ Clock \_______________________/
+ ______ ______ ______ ______ ______ ______ ______
+ DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
+ DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
+ DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
+ DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
+
+ - "jeida-30" - 30-bit data mapping compatible with JEIDA and VESA. Data
+ are transferred as follows on 5 LVDS lanes.
+
+ Slot 0 1 2 3 4 5 6
+ ________________ _________________
+ Clock \_______________________/
+ ______ ______ ______ ______ ______ ______ ______
+ DATA0 ><__G4__><__R9__><__R8__><__R7__><__R6__><__R5__><__R4__><
+ DATA1 ><__B5__><__B4__><__G9__><__G8__><__G7__><__G6__><__G5__><
+ DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B9__><__B8__><__B7__><__B6__><
+ DATA3 ><_CTL3_><__B3__><__B2__><__G3__><__G2__><__R3__><__R2__><
+ DATA4 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
+
+ - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
+ Data are transferred as follows on 4 LVDS lanes.
+
+ Slot 0 1 2 3 4 5 6
+ ________________ _________________
+ Clock \_______________________/
+ ______ ______ ______ ______ ______ ______ ______
+ DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+ DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+ DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+ DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
+
+ - "vesa-30" - 30-bit data mapping compatible with VESA. Data are
+ transferred as follows on 5 LVDS lanes.
+
+ Slot 0 1 2 3 4 5 6
+ ________________ _________________
+ Clock \_______________________/
+ ______ ______ ______ ______ ______ ______ ______
+ DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+ DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+ DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+ DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
+ DATA4 ><_CTL3_><__B9__><__B8__><__G9__><__G8__><__R9__><__R8__><
+
+ Control signals are mapped as follows.
+
+ CTL0: HSync
+ CTL1: VSync
+ CTL2: Data Enable
+ CTL3: 0
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
new file mode 100644
index 000000000000..785701fe1590
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dual-link LVDS Display Common Properties
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+description: |
+ Common properties for LVDS displays with dual LVDS links. Extend LVDS display
+ common properties defined in lvds.yaml.
+
+ Dual-link LVDS displays receive odd pixels and even pixels separately from
+ the dual LVDS links. One link receives odd pixels and the other receives
+ even pixels. Some of those displays may also use only one LVDS link to
+ receive all pixels, being odd and even agnostic.
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ '^port@[01]$':
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: |
+ port@0 represents the first LVDS input link.
+ port@1 represents the second LVDS input link.
+
+ properties:
+ dual-lvds-odd-pixels:
+ type: boolean
+ description: LVDS input link for odd pixels
+
+ dual-lvds-even-pixels:
+ type: boolean
+ description: LVDS input link for even pixels
+
+ oneOf:
+ - required: [dual-lvds-odd-pixels]
+ - required: [dual-lvds-even-pixels]
+ - properties:
+ dual-lvds-odd-pixels: false
+ dual-lvds-even-pixels: false
+
+ anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+
+required:
+ - ports
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/display/lvds.yaml b/Documentation/devicetree/bindings/display/lvds.yaml
index 7cd2ce7e9c33..b74efbea3be2 100644
--- a/Documentation/devicetree/bindings/display/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/lvds.yaml
@@ -6,83 +6,24 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: LVDS Display Common Properties
+allOf:
+ - $ref: lvds-data-mapping.yaml#
+
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
-description: |+
- LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
- incompatible data link layers have been used over time to transmit image data
- to LVDS devices. This bindings supports devices compatible with the following
- specifications.
-
- [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
- 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
- [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
- Semiconductor
- [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
- Electronics Standards Association (VESA)
-
- Device compatible with those specifications have been marketed under the
- FPD-Link and FlatLink brands.
+description:
+ This binding extends the data mapping defined in lvds-data-mapping.yaml.
+ It supports reversing the bit order on the formats defined there in order
+ to accommodate for even more specialized data formats, since a variety of
+ data formats and layouts is used to drive LVDS displays.
properties:
- data-mapping:
- enum:
- - jeida-18
- - jeida-24
- - vesa-24
- description: |
- The color signals mapping order.
-
- LVDS data mappings are defined as follows.
-
- - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
- [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
-
- Slot 0 1 2 3 4 5 6
- ________________ _________________
- Clock \_______________________/
- ______ ______ ______ ______ ______ ______ ______
- DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
- DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
- DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
-
- - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
- specifications. Data are transferred as follows on 4 LVDS lanes.
-
- Slot 0 1 2 3 4 5 6
- ________________ _________________
- Clock \_______________________/
- ______ ______ ______ ______ ______ ______ ______
- DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
- DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
- DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
- DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
-
- - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
- Data are transferred as follows on 4 LVDS lanes.
-
- Slot 0 1 2 3 4 5 6
- ________________ _________________
- Clock \_______________________/
- ______ ______ ______ ______ ______ ______ ______
- DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
- DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
- DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
- DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
-
- Control signals are mapped as follows.
-
- CTL0: HSync
- CTL1: VSync
- CTL2: Data Enable
- CTL3: 0
-
data-mirror:
type: boolean
description:
- If set, reverse the bit order described in the data mappings below on all
+ If set, reverse the bit order described in the data mappings on all
data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/mayqueen,pixpaper.yaml b/Documentation/devicetree/bindings/display/mayqueen,pixpaper.yaml
new file mode 100644
index 000000000000..cd27f8ba5ae1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mayqueen,pixpaper.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mayqueen,pixpaper.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mayqueen Pixpaper e-ink display panel
+
+maintainers:
+ - LiangCheng Wang <zaq14760@gmail.com>
+
+description:
+ The Pixpaper is an e-ink display panel controlled via an SPI interface.
+ The panel has a resolution of 122x250 pixels and requires GPIO pins for
+ reset, busy, and data/command control.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: mayqueen,pixpaper
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 1000000
+ default: 1000000
+
+ reset-gpios:
+ maxItems: 1
+
+ busy-gpios:
+ maxItems: 1
+
+ dc-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - busy-gpios
+ - dc-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ display@0 {
+ compatible = "mayqueen,pixpaper";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+ busy-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ dc-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index d4d585485e7b..daf90ebb39bf 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -24,15 +24,23 @@ properties:
- enum:
- mediatek,mt8173-disp-aal
- mediatek,mt8183-disp-aal
+ - mediatek,mt8195-mdp3-aal
+ - items:
+ - enum:
+ - mediatek,mt8188-mdp3-aal
+ - const: mediatek,mt8195-mdp3-aal
- items:
- enum:
- mediatek,mt2712-disp-aal
+ - mediatek,mt6795-disp-aal
- const: mediatek,mt8173-disp-aal
- items:
- enum:
- mediatek,mt8186-disp-aal
+ - mediatek,mt8188-disp-aal
- mediatek,mt8192-disp-aal
- mediatek,mt8195-disp-aal
+ - mediatek,mt8365-disp-aal
- const: mediatek,mt8183-disp-aal
reg:
@@ -58,6 +66,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: AAL input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -79,11 +108,30 @@ examples:
#size-cells = <2>;
aal@14015000 {
- compatible = "mediatek,mt8173-disp-aal";
- reg = <0 0x14015000 0 0x1000>;
- interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- clocks = <&mmsys CLK_MM_DISP_AAL>;
- mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
- };
+ compatible = "mediatek,mt8173-disp-aal";
+ reg = <0 0x14015000 0 0x1000>;
+ interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ clocks = <&mmsys CLK_MM_DISP_AAL>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 63fb02014a56..fca8e7bb0cbc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -21,18 +21,18 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8183-disp-ccorr
+ - mediatek,mt8192-disp-ccorr
- items:
+ - const: mediatek,mt8365-disp-ccorr
- const: mediatek,mt8183-disp-ccorr
- items:
- - const: mediatek,mt8192-disp-ccorr
- - items:
- enum:
+ - mediatek,mt8186-disp-ccorr
+ - mediatek,mt8188-disp-ccorr
- mediatek,mt8195-disp-ccorr
- const: mediatek,mt8192-disp-ccorr
- - items:
- - enum:
- - mediatek,mt8186-disp-ccorr
- - const: mediatek,mt8183-disp-ccorr
reg:
maxItems: 1
@@ -57,6 +57,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CCORR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index 66288b9f0aa6..080cf321209e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek HDMI CEC Controller Device Tree Bindings
+title: Mediatek HDMI CEC Controller
maintainers:
- CK Hu <ck.hu@mediatek.com>
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index d2f89ee7996f..5564f4063317 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -22,12 +22,15 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt2701-disp-color
+ - mediatek,mt8167-disp-color
+ - mediatek,mt8173-disp-color
+ - mediatek,mt8195-mdp3-color
- items:
- - const: mediatek,mt2701-disp-color
- - items:
- - const: mediatek,mt8167-disp-color
- - items:
- - const: mediatek,mt8173-disp-color
+ - enum:
+ - mediatek,mt8188-mdp3-color
+ - const: mediatek,mt8195-mdp3-color
- items:
- enum:
- mediatek,mt7623-disp-color
@@ -35,10 +38,13 @@ properties:
- const: mediatek,mt2701-disp-color
- items:
- enum:
+ - mediatek,mt6795-disp-color
- mediatek,mt8183-disp-color
- mediatek,mt8186-disp-color
+ - mediatek,mt8188-disp-color
- mediatek,mt8192-disp-color
- mediatek,mt8195-disp-color
+ - mediatek,mt8365-disp-color
- const: mediatek,mt8173-disp-color
reg:
maxItems: 1
@@ -63,6 +69,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: COLOR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ COLOR output to the input of the next desired component in the
+ display pipeline, for example one of the available CCORR or AAL
+ blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 8ad8187c02d1..abaf27916d13 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -22,13 +22,15 @@ description: |
properties:
compatible:
oneOf:
- - items:
- - const: mediatek,mt8183-disp-dither
+ - enum:
+ - mediatek,mt8183-disp-dither
- items:
- enum:
- mediatek,mt8186-disp-dither
+ - mediatek,mt8188-disp-dither
- mediatek,mt8192-disp-dither
- mediatek,mt8195-disp-dither
+ - mediatek,mt8365-disp-dither
- const: mediatek,mt8183-disp-dither
reg:
@@ -54,6 +56,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DITHER input, usually from a POSTMASK or GAMMA block.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DITHER output to the input of the next desired component in the
+ display pipeline, for example one of the available DSC compressors,
+ DP_INTF, DSI, LVDS or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
index ff781f2174a0..274f590807ca 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
@@ -21,6 +21,8 @@ description: |
properties:
compatible:
enum:
+ - mediatek,mt8188-dp-tx
+ - mediatek,mt8188-edp-tx
- mediatek,mt8195-dp-tx
- mediatek,mt8195-edp-tx
@@ -40,6 +42,12 @@ properties:
interrupts:
maxItems: 1
+ '#sound-dai-cells':
+ const: 0
+
+ aux-bus:
+ $ref: /schemas/display/dp-aux-bus.yaml#
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
@@ -83,7 +91,21 @@ required:
- ports
- max-linkrate-mhz
-additionalProperties: false
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8188-dp-tx
+ - mediatek,mt8195-dp-tx
+ then:
+ properties:
+ '#sound-dai-cells': false
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 5bb23e97cf33..eb4f276e8dc4 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -17,14 +17,29 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt2701-dpi
- - mediatek,mt7623-dpi
- - mediatek,mt8173-dpi
- - mediatek,mt8183-dpi
- - mediatek,mt8186-dpi
- - mediatek,mt8192-dpi
- - mediatek,mt8195-dp-intf
+ oneOf:
+ - enum:
+ - mediatek,mt2701-dpi
+ - mediatek,mt7623-dpi
+ - mediatek,mt8173-dpi
+ - mediatek,mt8183-dpi
+ - mediatek,mt8186-dpi
+ - mediatek,mt8188-dp-intf
+ - mediatek,mt8192-dpi
+ - mediatek,mt8195-dp-intf
+ - mediatek,mt8195-dpi
+ - items:
+ - enum:
+ - mediatek,mt6795-dpi
+ - const: mediatek,mt8183-dpi
+ - items:
+ - enum:
+ - mediatek,mt8365-dpi
+ - const: mediatek,mt8192-dpi
+ - items:
+ - enum:
+ - mediatek,mt8188-dpi
+ - const: mediatek,mt8195-dpi
reg:
maxItems: 1
@@ -52,19 +67,60 @@ properties:
- const: default
- const: sleep
+ 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
+
port:
$ref: /schemas/graph.yaml#/properties/port
description:
Output port node. This port should be connected to the input port of an
attached HDMI, LVDS or DisplayPort encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI output to an HDMI, LVDS or DisplayPort encoder input
+
+ required:
+ - port@0
+ - port@1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: dpi
+
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
additionalProperties: false
@@ -72,11 +128,13 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/power/mt8173-power.h>
- dpi0: dpi@1401d000 {
+ dpi: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0x1401d000 0x1000>;
interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DPI_PIXEL>,
<&mmsys CLK_MM_DPI_ENGINE>,
<&apmixedsys CLK_APMIXED_TVDPLL>;
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
index 49248864514b..a5b88eb97e3b 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
@@ -20,7 +20,10 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8195-disp-dsc
- items:
+ - const: mediatek,mt8188-disp-dsc
- const: mediatek,mt8195-disp-dsc
reg:
@@ -49,6 +52,30 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression input, usually from one of the DITHER
+ or MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression output to the input of the next desired
+ component in the display pipeline, for example to MERGE, DP_INTF,
+ DPI or DSI.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index b18d6a57c6e1..27ffbccc2a08 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -4,13 +4,12 @@
$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek DSI Controller Device Tree Bindings
+title: MediaTek DSI Controller
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
- Philipp Zabel <p.zabel@pengutronix.de>
- Jitao Shi <jitao.shi@mediatek.com>
- - Xinlei Lee <xinlei.lee@mediatek.com>
description: |
The MediaTek DSI function block is a sink of the display subsystem and can
@@ -22,13 +21,24 @@ allOf:
properties:
compatible:
- enum:
- - mediatek,mt2701-dsi
- - mediatek,mt7623-dsi
- - mediatek,mt8167-dsi
- - mediatek,mt8173-dsi
- - mediatek,mt8183-dsi
- - mediatek,mt8186-dsi
+ oneOf:
+ - enum:
+ - mediatek,mt2701-dsi
+ - mediatek,mt7623-dsi
+ - mediatek,mt8167-dsi
+ - mediatek,mt8173-dsi
+ - mediatek,mt8183-dsi
+ - mediatek,mt8186-dsi
+ - mediatek,mt8188-dsi
+ - items:
+ - enum:
+ - mediatek,mt6795-dsi
+ - const: mediatek,mt8173-dsi
+ - items:
+ - enum:
+ - mediatek,mt8195-dsi
+ - mediatek,mt8365-dsi
+ - const: mediatek,mt8183-dsi
reg:
maxItems: 1
@@ -67,6 +77,26 @@ properties:
Output port node. This port should be connected to the input
port of an attached DSI panel or DSI-to-eDP encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input ports can have multiple endpoints, each of those connects
+ to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI input port, usually from DITHER, DSC or MERGE
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DSI output to an attached DSI panel, or a DSI-to-X encoder chip
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -76,7 +106,12 @@ required:
- clock-names
- phys
- phy-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
new file mode 100644
index 000000000000..98db47894eeb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -0,0 +1,208 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Ethdr Device
+
+maintainers:
+ - Chun-Kuang Hu <chunkuang.hu@kernel.org>
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+description:
+ ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and is
+ designed for HDR video and graphics conversion in the external display path.
+ It handles multiple HDR input types and performs tone mapping, color
+ space/color format conversion, and then combine different layers,
+ output the required HDR or SDR signal to the subsequent display path.
+ This engine is composed of two video frontends, two graphic frontends,
+ one video backend and a mixer. ETHDR has two DMA function blocks, DS and ADL.
+ These two function blocks read the pre-programmed registers from DRAM and
+ set them to HW in the v-blanking period.
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt8195-disp-ethdr
+ - items:
+ - const: mediatek,mt8188-disp-ethdr
+ - const: mediatek,mt8195-disp-ethdr
+
+ reg:
+ maxItems: 7
+
+ reg-names:
+ items:
+ - const: mixer
+ - const: vdo_fe0
+ - const: vdo_fe1
+ - const: gfx_fe0
+ - const: gfx_fe1
+ - const: vdo_be
+ - const: adl_ds
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ items:
+ - description: mixer clock
+ - description: video frontend 0 clock
+ - description: video frontend 1 clock
+ - description: graphic frontend 0 clock
+ - description: graphic frontend 1 clock
+ - description: video backend clock
+ - description: autodownload and menuload clock
+ - description: video frontend 0 async clock
+ - description: video frontend 1 async clock
+ - description: graphic frontend 0 async clock
+ - description: graphic frontend 1 async clock
+ - description: video backend async clock
+ - description: ethdr top clock
+
+ clock-names:
+ items:
+ - const: mixer
+ - const: vdo_fe0
+ - const: vdo_fe1
+ - const: gfx_fe0
+ - const: gfx_fe1
+ - const: vdo_be
+ - const: adl_ds
+ - const: vdo_fe0_async
+ - const: vdo_fe1_async
+ - const: gfx_fe0_async
+ - const: gfx_fe1_async
+ - const: vdo_be_async
+ - const: ethdr_top
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: video frontend 0 async reset
+ - description: video frontend 1 async reset
+ - description: graphic frontend 0 async reset
+ - description: graphic frontend 1 async reset
+ - description: video backend async reset
+
+ reset-names:
+ items:
+ - const: vdo_fe0_async
+ - const: vdo_fe1_async
+ - const: gfx_fe0_async
+ - const: gfx_fe1_async
+ - const: vdo_be_async
+
+ mediatek,gce-client-reg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 7
+ description: The register of display function block to be set by gce.
+ There are 4 arguments in this property, gce node, subsys id, offset and
+ register size. The subsys id is defined in the gce header of each chips
+ include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display
+ function block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: ETHDR input, usually from one of the MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ ETHDR output to the input of the next desired component in the
+ display pipeline, for example one of the available MERGE blocks,
+ or others.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - resets
+ - mediatek,gce-client-reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+ #include <dt-bindings/memory/mt8195-memory-port.h>
+ #include <dt-bindings/power/mt8195-power.h>
+ #include <dt-bindings/reset/mt8195-resets.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ hdr-engine@1c114000 {
+ compatible = "mediatek,mt8195-disp-ethdr";
+ reg = <0 0x1c114000 0 0x1000>,
+ <0 0x1c115000 0 0x1000>,
+ <0 0x1c117000 0 0x1000>,
+ <0 0x1c119000 0 0x1000>,
+ <0 0x1c11a000 0 0x1000>,
+ <0 0x1c11b000 0 0x1000>,
+ <0 0x1c11c000 0 0x1000>;
+ reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1",
+ "vdo_be", "adl_ds";
+ mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>,
+ <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>,
+ <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>,
+ <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>,
+ <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>,
+ <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>,
+ <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>;
+ clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>,
+ <&vdosys1 CLK_VDO1_HDR_VDO_FE0>,
+ <&vdosys1 CLK_VDO1_HDR_VDO_FE1>,
+ <&vdosys1 CLK_VDO1_HDR_GFX_FE0>,
+ <&vdosys1 CLK_VDO1_HDR_GFX_FE1>,
+ <&vdosys1 CLK_VDO1_HDR_VDO_BE>,
+ <&vdosys1 CLK_VDO1_26M_SLOW>,
+ <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>,
+ <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>,
+ <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>,
+ <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>,
+ <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>,
+ <&topckgen CLK_TOP_ETHDR>;
+ clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1",
+ "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async",
+ "gfx_fe0_async", "gfx_fe1_async","vdo_be_async",
+ "ethdr_top";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
+ iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>,
+ <&iommu_vpp M4U_PORT_L3_HDR_ADL>;
+ interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */
+ resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>,
+ <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>,
+ <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>,
+ <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>,
+ <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>;
+ reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async",
+ "gfx_fe1_async", "vdo_be_async";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index a89ea0ea7542..48542dc7e784 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -21,16 +21,26 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8173-disp-gamma
+ - mediatek,mt8183-disp-gamma
+ - mediatek,mt8195-disp-gamma
- items:
+ - enum:
+ - mediatek,mt6795-disp-gamma
- const: mediatek,mt8173-disp-gamma
- items:
- - const: mediatek,mt8183-disp-gamma
- - items:
- enum:
- mediatek,mt8186-disp-gamma
+ - mediatek,mt8188-disp-gamma
- mediatek,mt8192-disp-gamma
- mediatek,mt8195-disp-gamma
+ - mediatek,mt8365-disp-gamma
- const: mediatek,mt8183-disp-gamma
+ - items:
+ - enum:
+ - mediatek,mt8188-disp-gamma
+ - const: mediatek,mt8195-disp-gamma
reg:
maxItems: 1
@@ -55,6 +65,25 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GAMMA input, usually from one of the AAL blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ GAMMA output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER or
+ POSTMASK blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index b6fcdfb99ab2..bd8f7b8ae0ff 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek HDMI DDC Device Tree Bindings
+title: Mediatek HDMI DDC
maintainers:
- CK Hu <ck.hu@mediatek.com>
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index bdaf0b51e68c..b90b6d18a828 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek HDMI Encoder Device Tree Bindings
+title: Mediatek HDMI Encoder
maintainers:
- CK Hu <ck.hu@mediatek.com>
@@ -50,7 +50,7 @@ properties:
- const: hdmi
mediatek,syscon-hdmi:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to system configuration registers
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
deleted file mode 100644
index dd12e2ff685c..000000000000
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml
+++ /dev/null
@@ -1,88 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek MDP RDMA
-
-maintainers:
- - Chun-Kuang Hu <chunkuang.hu@kernel.org>
- - Philipp Zabel <p.zabel@pengutronix.de>
-
-description:
- The MediaTek MDP RDMA stands for Read Direct Memory Access.
- It provides real time data to the back-end panel driver, such as DSI,
- DPI and DP_INTF.
- It contains one line buffer to store the sufficient pixel data.
- RDMA device node must be siblings to the central MMSYS_CONFIG node.
- For a description of the MMSYS_CONFIG binding, see
- Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for details.
-
-properties:
- compatible:
- const: mediatek,mt8195-vdo1-rdma
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- clocks:
- items:
- - description: RDMA Clock
-
- iommus:
- maxItems: 1
-
- mediatek,gce-client-reg:
- description:
- The register of display function block to be set by gce. There are 4 arguments,
- such as gce node, subsys id, offset and register size. The subsys id that is
- mapping to the register of display function blocks is defined in the gce header
- include/dt-bindings/gce/<chip>-gce.h of each chips.
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- items:
- - description: phandle of GCE
- - description: GCE subsys id
- - description: register offset
- - description: register size
- maxItems: 1
-
-required:
- - compatible
- - reg
- - power-domains
- - clocks
- - iommus
- - mediatek,gce-client-reg
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/mt8195-clk.h>
- #include <dt-bindings/power/mt8195-power.h>
- #include <dt-bindings/gce/mt8195-gce.h>
- #include <dt-bindings/memory/mt8195-memory-port.h>
-
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
-
- rdma@1c104000 {
- compatible = "mediatek,mt8195-vdo1-rdma";
- reg = <0 0x1c104000 0 0x1000>;
- interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>;
- clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
- power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
- iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
- mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>;
- };
- };
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index 69ba75777dac..3798a25402d3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -21,9 +21,19 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8173-disp-merge
+ - mediatek,mt8195-disp-merge
+ - mediatek,mt8195-mdp3-merge
- items:
+ - enum:
+ - mediatek,mt8188-mdp3-merge
+ - const: mediatek,mt8195-mdp3-merge
+ - items:
+ - const: mediatek,mt6795-disp-merge
- const: mediatek,mt8173-disp-merge
- items:
+ - const: mediatek,mt8188-disp-merge
- const: mediatek,mt8195-disp-merge
reg:
@@ -71,6 +81,29 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE input port, usually from DITHER, DPI, DSC, DSI, MDP_RDMA,
+ ETHDR or even from a different MERGE block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE output to a DSC, DPI, DP_INTF, DSI, ETHDR, Write DMA, or
+ a different MERGE block, or others.
+
+ required:
+ - port@0
+ - port@1
+
resets:
description: reset controller
See Documentation/devicetree/bindings/reset/reset.txt for details.
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
new file mode 100644
index 000000000000..bde4dc556d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek HDMI MT8195 series HDMI Display Data Channel (DDC)
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - CK Hu <ck.hu@mediatek.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt8195-hdmi-ddc
+ - items:
+ - const: mediatek,mt8188-hdmi-ddc
+ - const: mediatek,mt8195-hdmi-ddc
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ hdmi {
+ hdmi_ddc: i2c {
+ compatible = "mediatek,mt8195-hdmi-ddc";
+ clocks = <&clk26m>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.yaml
new file mode 100644
index 000000000000..1b382f99d3ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8195 series HDMI-TX Encoder
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - CK Hu <ck.hu@mediatek.com>
+
+description:
+ The MediaTek HDMI-TX v2 encoder can generate HDMI format data based on
+ the HDMI Specification 2.0b.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-hdmi-tx
+ - mediatek,mt8195-hdmi-tx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: HDMI Peripheral Bus (APB) clock
+ - description: HDCP and HDMI_TOP clock
+ - description: HDCP, HDMI_TOP and HDMI Audio reference clock
+ - description: VPP HDMI Split clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: hdcp
+ - const: hdcp24m
+ - const: hdmi-split
+
+ i2c:
+ type: object
+ $ref: /schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
+ unevaluatedProperties: false
+ description: HDMI DDC I2C controller
+
+ phys:
+ maxItems: 1
+ description: PHY providing clocking TMDS and pixel to controller
+
+ phy-names:
+ items:
+ - const: hdmi
+
+ power-domains:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input port, usually connected to the output port of a DPI
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port that must be connected either to the input port of
+ a HDMI connector node containing a ddc-i2c-bus, or to the input
+ port of an attached bridge chip, such as a SlimPort transmitter.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - phys
+ - phy-names
+ - ports
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/mt8195-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ hdmi@1c300000 {
+ compatible = "mediatek,mt8195-hdmi-tx";
+ reg = <0 0x1c300000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_HDMI_APB>,
+ <&topckgen CLK_TOP_HDCP>,
+ <&topckgen CLK_TOP_HDCP_24M>,
+ <&vppsys1 CLK_VPP1_VPP_SPLIT_HDMI>;
+ clock-names = "bus", "hdcp", "hdcp24m", "hdmi-split";
+ interrupts = <GIC_SPI 677 IRQ_TYPE_LEVEL_HIGH 0>;
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi";
+ power-domains = <&spm MT8195_POWER_DOMAIN_HDMI_TX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins>;
+ #sound-dai-cells = <1>;
+
+ hdmitx_ddc: i2c {
+ compatible = "mediatek,mt8195-hdmi-ddc";
+ clocks = <&clk26m>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hdmi_in: endpoint {
+ remote-endpoint = <&dpi1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
index 853fcb9db2be..930c088a722a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
@@ -21,9 +21,11 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt2712-disp-od
+ - mediatek,mt8173-disp-od
- items:
- - const: mediatek,mt2712-disp-od
- - items:
+ - const: mediatek,mt6795-disp-od
- const: mediatek,mt8173-disp-od
reg:
@@ -36,6 +38,40 @@ properties:
items:
- description: OD Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OD input port, usually from an AAL block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OD output to the input of the next desired component in the
+ display pipeline, for example one of the available RDMA or
+ other blocks.
+
+ required:
+ - port@0
+ - port@1
+
+ mediatek,gce-client-reg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: describes how to locate the GCE client register
+ items:
+ - items:
+ - description: Phandle reference to a Mediatek GCE Mailbox
+ - description:
+ GCE subsys id mapping to a client defined in header
+ include/dt-bindings/gce/<chip>-gce.h.
+ - description: offset for the GCE register offset
+ - description: size of the GCE register offset
+
required:
- compatible
- reg
@@ -46,6 +82,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/gce/mt8173-gce.h>
soc {
#address-cells = <2>;
@@ -55,5 +92,6 @@ examples:
compatible = "mediatek,mt8173-disp-od";
reg = <0 0x14023000 0 0x1000>;
clocks = <&mmsys CLK_MM_DISP_OD>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1402XXXX 0x3000 0x1000>;
};
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
index 4e94f4e947ad..bacdfe7d08a6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
@@ -21,10 +21,9 @@ description: |
properties:
compatible:
oneOf:
- - items:
- - const: mediatek,mt8183-disp-ovl-2l
- - items:
- - const: mediatek,mt8192-disp-ovl-2l
+ - enum:
+ - mediatek,mt8183-disp-ovl-2l
+ - mediatek,mt8192-disp-ovl-2l
- items:
- enum:
- mediatek,mt8186-disp-ovl-2l
@@ -58,6 +57,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS, VDOSYS or other OVLs
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index a2a27d0ca038..4f110635afb6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -21,14 +21,13 @@ description: |
properties:
compatible:
oneOf:
- - items:
- - const: mediatek,mt2701-disp-ovl
- - items:
- - const: mediatek,mt8173-disp-ovl
- - items:
- - const: mediatek,mt8183-disp-ovl
- - items:
- - const: mediatek,mt8192-disp-ovl
+ - enum:
+ - mediatek,mt2701-disp-ovl
+ - mediatek,mt8173-disp-ovl
+ - mediatek,mt8183-disp-ovl
+ - mediatek,mt8192-disp-ovl
+ - mediatek,mt8195-disp-ovl
+ - mediatek,mt8195-mdp3-ovl
- items:
- enum:
- mediatek,mt7623-disp-ovl
@@ -36,12 +35,19 @@ properties:
- const: mediatek,mt2701-disp-ovl
- items:
- enum:
- - mediatek,mt8195-disp-ovl
- - const: mediatek,mt8183-disp-ovl
+ - mediatek,mt6795-disp-ovl
+ - const: mediatek,mt8173-disp-ovl
- items:
- enum:
- mediatek,mt8186-disp-ovl
+ - mediatek,mt8365-disp-ovl
- const: mediatek,mt8192-disp-ovl
+ - items:
+ - const: mediatek,mt8188-disp-ovl
+ - const: mediatek,mt8195-disp-ovl
+ - items:
+ - const: mediatek,mt8188-mdp3-ovl
+ - const: mediatek,mt8195-mdp3-ovl
reg:
maxItems: 1
@@ -71,6 +77,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS or one of multiple VDOSYS
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
new file mode 100644
index 000000000000..86787866ced0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,padding.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Display Padding
+
+maintainers:
+ - Chun-Kuang Hu <chunkuang.hu@kernel.org>
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+description:
+ Padding provides ability to add pixels to width and height of a layer with
+ specified colors. Due to hardware design, Mixer in VDOSYS1 requires
+ width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled,
+ we need Padding to deal with odd width.
+ Please notice that even if the Padding is in bypass mode, settings in
+ register must be cleared to 0, or undefined behaviors could happen.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8188-disp-padding
+ - mediatek,mt8195-mdp3-padding
+ - items:
+ - const: mediatek,mt8188-mdp3-padding
+ - const: mediatek,mt8195-mdp3-padding
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Padding's clocks
+
+ mediatek,gce-client-reg:
+ description:
+ GCE (Global Command Engine) is a multi-core micro processor that helps
+ its clients to execute commands without interrupting CPU. This property
+ describes GCE client's information that is composed by 4 fields.
+ 1. Phandle of the GCE (there may be several GCE processors)
+ 2. Sub-system ID defined in the dt-binding like a user ID
+ (Please refer to include/dt-bindings/gce/<chip>-gce.h)
+ 3. Offset from base address of the subsys you are at
+ 4. Size of the register the client needs
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: Phandle of the GCE
+ - description: Subsys ID defined in the dt-binding
+ - description: Offset from base address of the subsys
+ - description: Size of register
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - clocks
+ - mediatek,gce-client-reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mediatek,mt8188-clk.h>
+ #include <dt-bindings/power/mediatek,mt8188-power.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ padding0: padding@1c11d000 {
+ compatible = "mediatek,mt8188-disp-padding";
+ reg = <0 0x1c11d000 0 0x1000>;
+ clocks = <&vdosys1 CLK_VDO1_PADDING0>;
+ power-domains = <&spm MT8188_POWER_DOMAIN_VDOSYS1>;
+ mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0xd000 0x1000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 654080bfbdfb..fb6fe4742624 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -21,11 +21,12 @@ description: |
properties:
compatible:
oneOf:
- - items:
- - const: mediatek,mt8192-disp-postmask
+ - enum:
+ - mediatek,mt8192-disp-postmask
- items:
- enum:
- mediatek,mt8186-disp-postmask
+ - mediatek,mt8188-disp-postmask
- const: mediatek,mt8192-disp-postmask
reg:
@@ -51,6 +52,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: POSTMASK input port, usually from GAMMA
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ POSTMASK output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 0882ae86e6c4..878f676b581f 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -23,13 +23,14 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt2701-disp-rdma
+ - mediatek,mt8173-disp-rdma
+ - mediatek,mt8183-disp-rdma
+ - mediatek,mt8195-disp-rdma
- items:
- - const: mediatek,mt2701-disp-rdma
- - items:
- - const: mediatek,mt8173-disp-rdma
- - items:
- - const: mediatek,mt8183-disp-rdma
- - items:
+ - enum:
+ - mediatek,mt8188-disp-rdma
- const: mediatek,mt8195-disp-rdma
- items:
- enum:
@@ -38,8 +39,13 @@ properties:
- const: mediatek,mt2701-disp-rdma
- items:
- enum:
+ - mediatek,mt6795-disp-rdma
+ - const: mediatek,mt8173-disp-rdma
+ - items:
+ - enum:
- mediatek,mt8186-disp-rdma
- mediatek,mt8192-disp-rdma
+ - mediatek,mt8365-disp-rdma
- const: mediatek,mt8183-disp-rdma
reg:
@@ -81,6 +87,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: RDMA input port, usually from MMSYS, OD or OVL
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ RDMA output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, DPI,
+ DSI, MERGE or UFOE blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
index 35ace1f322e8..4b6ff546757e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml
@@ -21,7 +21,11 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8173-disp-split
+ - mediatek,mt8195-mdp3-split
- items:
+ - const: mediatek,mt6795-disp-split
- const: mediatek,mt8173-disp-split
reg:
@@ -34,10 +38,29 @@ properties:
description: A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle. See
Documentation/devicetree/bindings/power/power-domain.yaml for details.
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description:
+ The register of display function block to be set by gce. There are 4 arguments,
+ such as gce node, subsys id, offset and register size. The subsys id that is
+ mapping to the register of display function blocks is defined in the gce header
+ include/dt-bindings/gce/<chip>-gce.h of each chips.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of GCE
+ - description: GCE subsys id
+ - description: register offset
+ - description: register size
+ maxItems: 1
clocks:
items:
- description: SPLIT Clock
+ - description: Used for interfacing with the HDMI RX signal source.
+ - description: Paired with receiving HDMI RX metadata.
+ minItems: 1
required:
- compatible
@@ -45,6 +68,32 @@ required:
- power-domains
- clocks
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8195-mdp3-split
+
+ then:
+ properties:
+ clocks:
+ minItems: 3
+
+ required:
+ - mediatek,gce-client-reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8173-disp-split
+
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
index b8bb135fe96b..036a66ed42e7 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
@@ -22,7 +22,10 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8173-disp-ufoe
- items:
+ - const: mediatek,mt6795-disp-ufoe
- const: mediatek,mt8173-disp-ufoe
reg:
@@ -40,6 +43,39 @@ properties:
items:
- description: UFOe Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UFOE input, usually from one of the RDMA blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ UFOE output to the input of the next desired component in the
+ display pipeline, usually one of the available DSI blocks.
+
+ required:
+ - port@0
+ - port@1
+
+ mediatek,gce-client-reg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: describes how to locate the GCE client register
+ items:
+ - items:
+ - description: Phandle reference to a Mediatek GCE Mailbox
+ - description:
+ GCE subsys id mapping to a client defined in header
+ include/dt-bindings/gce/<chip>-gce.h.
+ - description: offset for the GCE register offset
+ - description: size of the GCE register offset
+
required:
- compatible
- reg
@@ -53,7 +89,9 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/gce/mt8173-gce.h>
#include <dt-bindings/power/mt8173-power.h>
+
soc {
#address-cells = <2>;
#size-cells = <2>;
@@ -64,5 +102,6 @@ examples:
interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_UFOE>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xa000 0x1000>;
};
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
index 7d7cc1ab526b..a3a2b71a4523 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
@@ -21,7 +21,10 @@ description: |
properties:
compatible:
oneOf:
+ - enum:
+ - mediatek,mt8173-disp-wdma
- items:
+ - const: mediatek,mt6795-disp-wdma
- const: mediatek,mt8173-disp-wdma
reg:
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af8256f..ebda78db87a6 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -8,6 +8,7 @@ title: MSM Display Port Controller
maintainers:
- Kuogee Hsieh <quic_khsieh@quicinc.com>
+ - Abhinav Kumar <quic_abhinavk@quicinc.com>
description: |
Device tree bindings for DisplayPort host controller for MSM targets
@@ -15,13 +16,59 @@ description: |
properties:
compatible:
- enum:
- - qcom,sc7180-dp
- - qcom,sc7280-dp
- - qcom,sc7280-edp
- - qcom,sc8180x-dp
- - qcom,sc8180x-edp
- - qcom,sm8350-dp
+ oneOf:
+ - enum:
+ - qcom,glymur-dp
+ - qcom,sa8775p-dp
+ - qcom,sc7180-dp
+ - qcom,sc7280-dp
+ - qcom,sc7280-edp
+ - qcom,sc8180x-dp
+ - qcom,sc8180x-edp
+ - qcom,sc8280xp-dp
+ - qcom,sc8280xp-edp
+ - qcom,sdm845-dp
+ - qcom,sm8350-dp
+ - qcom,sm8650-dp
+ - qcom,x1e80100-dp
+
+ - items:
+ - enum:
+ - qcom,qcs8300-dp
+ - const: qcom,sa8775p-dp
+
+ - items:
+ - enum:
+ - qcom,sm6350-dp
+ - const: qcom,sc7180-dp
+
+ # deprecated entry for compatibility with old DT
+ - items:
+ - enum:
+ - qcom,sm6350-dp
+ - const: qcom,sm8350-dp
+ deprecated: true
+
+ - items:
+ - enum:
+ - qcom,sar2130p-dp
+ - qcom,sm7150-dp
+ - qcom,sm8150-dp
+ - qcom,sm8250-dp
+ - qcom,sm8450-dp
+ - qcom,sm8550-dp
+ - const: qcom,sm8350-dp
+
+ - items:
+ - enum:
+ - qcom,sm6150-dp
+ - const: qcom,sm8150-dp
+ - const: qcom,sm8350-dp
+
+ - items:
+ - enum:
+ - qcom,sm8750-dp
+ - const: qcom,sm8650-dp
reg:
minItems: 4
@@ -31,35 +78,37 @@ properties:
- description: link register block
- description: p0 register block
- description: p1 register block
+ - description: p2 register block
+ - description: p3 register block
+ - description: mst2link register block
+ - description: mst3link register block
interrupts:
maxItems: 1
clocks:
+ minItems: 5
items:
- description: AHB clock to enable register access
- description: Display Port AUX clock
- description: Display Port Link clock
- description: Link interface clock between DP and PHY
- - description: Display Port Pixel clock
+ - description: Display Port stream 0 Pixel clock
+ - description: Display Port stream 1 Pixel clock
+ - description: Display Port stream 2 Pixel clock
+ - description: Display Port stream 3 Pixel clock
clock-names:
+ minItems: 5
items:
- const: core_iface
- const: core_aux
- const: ctrl_link
- const: ctrl_link_iface
- const: stream_pixel
-
- assigned-clocks:
- items:
- - description: link clock source
- - description: pixel clock source
-
- assigned-clock-parents:
- items:
- - description: phy 0 parent
- - description: phy 1 parent
+ - const: stream_1_pixel
+ - const: stream_2_pixel
+ - const: stream_3_pixel
phys:
maxItems: 1
@@ -68,10 +117,10 @@ properties:
items:
- const: dp
- operating-points-v2:
- maxItems: 1
+ operating-points-v2: true
- opp-table: true
+ opp-table:
+ type: object
power-domains:
maxItems: 1
@@ -81,6 +130,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -102,8 +152,29 @@ properties:
description: Input endpoint of the controller
port@1:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ 0, 1, 2, 3 ]
+
+ link-frequencies:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ 1620000000, 2700000000, 5400000000, 8100000000 ]
+
+ required:
+ - port@0
+ - port@1
required:
- compatible
@@ -119,7 +190,6 @@ required:
allOf:
# AUX BUS does not exist on DP controllers
# Audio output also is present only on DP output
- # p1 regions is present on DP, but not on eDP
- if:
properties:
compatible:
@@ -127,20 +197,120 @@ allOf:
enum:
- qcom,sc7280-edp
- qcom,sc8180x-edp
+ - qcom,sc8280xp-edp
then:
properties:
"#sound-dai-cells": false
- reg:
- maxItems: 4
else:
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-dp
+ - qcom,sa8775p-dp
+ - qcom,x1e80100-dp
+ then:
+ $ref: /schemas/sound/dai-common.yaml#
+ oneOf:
+ - required:
+ - aux-bus
+ - required:
+ - "#sound-dai-cells"
+ else:
+ properties:
+ aux-bus: false
+ required:
+ - "#sound-dai-cells"
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ # these platforms support SST only
+ - qcom,sc7180-dp
+ - qcom,sc7280-dp
+ - qcom,sc7280-edp
+ - qcom,sc8180x-edp
+ - qcom,sc8280xp-edp
+ then:
+ properties:
+ reg:
+ minItems: 5
+ maxItems: 5
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clocks-names:
+ minItems: 5
+ maxItems: 5
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ # these platforms support 2 streams MST on some interfaces,
+ # others are SST only
+ - qcom,glymur-dp
+ - qcom,sc8280xp-dp
+ - qcom,x1e80100-dp
+ then:
properties:
- aux-bus: false
reg:
minItems: 5
- required:
- - "#sound-dai-cells"
+ maxItems: 5
+ clocks:
+ minItems: 5
+ maxItems: 6
+ clocks-names:
+ minItems: 5
+ maxItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ # 2 streams MST
+ enum:
+ - qcom,sc8180x-dp
+ - qcom,sdm845-dp
+ - qcom,sm8350-dp
+ - qcom,sm8650-dp
+ then:
+ properties:
+ reg:
+ minItems: 5
+ maxItems: 5
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clocks-names:
+ minItems: 6
+ maxItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ # these platforms support 4 stream MST on first DP,
+ # 2 streams MST on the second one.
+ - qcom,sa8775p-dp
+ then:
+ properties:
+ reg:
+ minItems: 9
+ maxItems: 9
+ clocks:
+ minItems: 6
+ maxItems: 8
+ clocks-names:
+ minItems: 6
+ maxItems: 8
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -193,6 +363,8 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <&typec>;
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
};
};
};
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
new file mode 100644
index 000000000000..3f953aa5e694
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
@@ -0,0 +1,56 @@
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU common properties
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Rob Clark <robdclark@gmail.com>
+
+description: |
+ Common properties for QCom DPU display controller.
+
+# Do not select this by default, otherwise it is also selected for all
+# display-controller@ nodes
+select:
+ false
+
+properties:
+ $nodename:
+ pattern: '^display-controller@[0-9a-f]+$'
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: |
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI, DP etc.
+
+ patternProperties:
+ "^port@[0-9a-f]+$":
+ $ref: /schemas/graph.yaml#/properties/port
+
+ # at least one port is required
+ required:
+ - port@0
+
+required:
+ - interrupts
+ - power-domains
+ - operating-points-v2
+ - ports
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
deleted file mode 100644
index 253665c693e6..000000000000
--- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
+++ /dev/null
@@ -1,223 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/msm/dpu-msm8998.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Display DPU dt properties for MSM8998 target
-
-maintainers:
- - AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
-
-description: |
- Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
- sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
- bindings of MDSS and DPU are mentioned for MSM8998 target.
-
-properties:
- compatible:
- items:
- - const: qcom,msm8998-mdss
-
- reg:
- maxItems: 1
-
- reg-names:
- const: mdss
-
- power-domains:
- maxItems: 1
-
- clocks:
- items:
- - description: Display AHB clock
- - description: Display AXI clock
- - description: Display core clock
-
- clock-names:
- items:
- - const: iface
- - const: bus
- - const: core
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- "#address-cells": true
-
- "#size-cells": true
-
- "#interrupt-cells":
- const: 1
-
- iommus:
- items:
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
-
- ranges: true
-
-patternProperties:
- "^display-controller@[0-9a-f]+$":
- type: object
- description: Node containing the properties of DPU.
- additionalProperties: false
-
- properties:
- compatible:
- items:
- - const: qcom,msm8998-dpu
-
- reg:
- items:
- - description: Address offset and size for mdp register set
- - description: Address offset and size for regdma register set
- - description: Address offset and size for vbif register set
- - description: Address offset and size for non-realtime vbif register set
-
- reg-names:
- items:
- - const: mdp
- - const: regdma
- - const: vbif
- - const: vbif_nrt
-
- clocks:
- items:
- - description: Display ahb clock
- - description: Display axi clock
- - description: Display mem-noc clock
- - description: Display core clock
- - description: Display vsync clock
-
- clock-names:
- items:
- - const: iface
- - const: bus
- - const: mnoc
- - const: core
- - const: vsync
-
- interrupts:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- operating-points-v2: true
- opp-table:
- type: object
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- description: |
- Contains the list of output ports from DPU device. These ports
- connect to interfaces that are external to the DPU hardware,
- such as DSI, DP etc. Each output port contains an endpoint that
- describes how it is connected to an external interface.
-
- properties:
- port@0:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF1 (DSI1)
-
- port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF2 (DSI2)
-
- required:
- - port@0
- - port@1
-
- required:
- - compatible
- - reg
- - reg-names
- - clocks
- - interrupts
- - power-domains
- - operating-points-v2
- - ports
-
-required:
- - compatible
- - reg
- - reg-names
- - power-domains
- - clocks
- - interrupts
- - interrupt-controller
- - iommus
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,mmcc-msm8998.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- mdss: display-subsystem@c900000 {
- compatible = "qcom,msm8998-mdss";
- reg = <0x0c900000 0x1000>;
- reg-names = "mdss";
-
- clocks = <&mmcc MDSS_AHB_CLK>,
- <&mmcc MDSS_AXI_CLK>,
- <&mmcc MDSS_MDP_CLK>;
- clock-names = "iface", "bus", "core";
-
- #address-cells = <1>;
- #interrupt-cells = <1>;
- #size-cells = <1>;
-
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- iommus = <&mmss_smmu 0>;
-
- power-domains = <&mmcc MDSS_GDSC>;
- ranges;
-
- display-controller@c901000 {
- compatible = "qcom,msm8998-dpu";
- reg = <0x0c901000 0x8f000>,
- <0x0c9a8e00 0xf0>,
- <0x0c9b0000 0x2008>,
- <0x0c9b8000 0x1040>;
- reg-names = "mdp", "regdma", "vbif", "vbif_nrt";
-
- clocks = <&mmcc MDSS_AHB_CLK>,
- <&mmcc MDSS_AXI_CLK>,
- <&mmcc MNOC_AHB_CLK>,
- <&mmcc MDSS_MDP_CLK>,
- <&mmcc MDSS_VSYNC_CLK>;
- clock-names = "iface", "bus", "mnoc", "core", "vsync";
-
- interrupt-parent = <&mdss>;
- interrupts = <0>;
- operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmpd MSM8998_VDDMX>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- dpu_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
-
- port@1 {
- reg = <1>;
- dpu_intf2_out: endpoint {
- remote-endpoint = <&dsi1_in>;
- };
- };
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
deleted file mode 100644
index c5824e1d2382..000000000000
--- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
+++ /dev/null
@@ -1,222 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/msm/dpu-qcm2290.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Display DPU dt properties for QCM2290 target
-
-maintainers:
- - Loic Poulain <loic.poulain@linaro.org>
-
-description: |
- Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
- sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
- and DPU are mentioned for QCM2290 target.
-
-properties:
- compatible:
- items:
- - const: qcom,qcm2290-mdss
-
- reg:
- maxItems: 1
-
- reg-names:
- const: mdss
-
- power-domains:
- maxItems: 1
-
- clocks:
- items:
- - description: Display AHB clock from gcc
- - description: Display AXI clock
- - description: Display core clock
-
- clock-names:
- items:
- - const: iface
- - const: bus
- - const: core
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- "#address-cells": true
-
- "#size-cells": true
-
- "#interrupt-cells":
- const: 1
-
- iommus:
- items:
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1
-
- ranges: true
-
- interconnects:
- items:
- - description: Interconnect path specifying the port ids for data bus
-
- interconnect-names:
- const: mdp0-mem
-
- resets:
- items:
- - description: MDSS_CORE reset
-
-patternProperties:
- "^display-controller@[0-9a-f]+$":
- type: object
- description: Node containing the properties of DPU.
- additionalProperties: false
-
- properties:
- compatible:
- items:
- - const: qcom,qcm2290-dpu
-
- reg:
- items:
- - description: Address offset and size for mdp register set
- - description: Address offset and size for vbif register set
-
- reg-names:
- items:
- - const: mdp
- - const: vbif
-
- clocks:
- items:
- - description: Display AXI clock from gcc
- - description: Display AHB clock from dispcc
- - description: Display core clock from dispcc
- - description: Display lut clock from dispcc
- - description: Display vsync clock from dispcc
-
- clock-names:
- items:
- - const: bus
- - const: iface
- - const: core
- - const: lut
- - const: vsync
-
- interrupts:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- operating-points-v2: true
- opp-table:
- type: object
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- description: |
- Contains the list of output ports from DPU device. These ports
- connect to interfaces that are external to the DPU hardware,
- such as DSI. Each output port contains an endpoint that
- describes how it is connected to an external interface.
-
- properties:
- port@0:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF1 (DSI1)
-
- required:
- - port@0
-
- required:
- - compatible
- - reg
- - reg-names
- - clocks
- - interrupts
- - power-domains
- - operating-points-v2
- - ports
-
-required:
- - compatible
- - reg
- - reg-names
- - power-domains
- - clocks
- - interrupts
- - interrupt-controller
- - iommus
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,dispcc-qcm2290.h>
- #include <dt-bindings/clock/qcom,gcc-qcm2290.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interconnect/qcom,qcm2290.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- mdss: mdss@5e00000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,qcm2290-mdss";
- reg = <0x05e00000 0x1000>;
- reg-names = "mdss";
- power-domains = <&dispcc MDSS_GDSC>;
- clocks = <&gcc GCC_DISP_AHB_CLK>,
- <&gcc GCC_DISP_HF_AXI_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface", "bus", "core";
-
- interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interconnects = <&mmrt_virt MASTER_MDP0 &bimc SLAVE_EBI1>;
- interconnect-names = "mdp0-mem";
-
- iommus = <&apps_smmu 0x420 0x2>,
- <&apps_smmu 0x421 0x0>;
- ranges;
-
- mdss_mdp: display-controller@5e01000 {
- compatible = "qcom,qcm2290-dpu";
- reg = <0x05e01000 0x8f000>,
- <0x05eb0000 0x2008>;
- reg-names = "mdp", "vbif";
-
- clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
- <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
- <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
- clock-names = "bus", "iface", "core", "lut", "vsync";
-
- operating-points-v2 = <&mdp_opp_table>;
- power-domains = <&rpmpd QCM2290_VDDCX>;
-
- interrupt-parent = <&mdss>;
- interrupts = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- dpu_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
deleted file mode 100644
index 4890bc25f3fd..000000000000
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
+++ /dev/null
@@ -1,235 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Display DPU dt properties for SC7180 target
-
-maintainers:
- - Krishna Manikandan <quic_mkrishn@quicinc.com>
-
-description: |
- Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
- sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
- bindings of MDSS and DPU are mentioned for SC7180 target.
-
-properties:
- compatible:
- items:
- - const: qcom,sc7180-mdss
-
- reg:
- maxItems: 1
-
- reg-names:
- const: mdss
-
- power-domains:
- maxItems: 1
-
- clocks:
- items:
- - description: Display AHB clock from gcc
- - description: Display AHB clock from dispcc
- - description: Display core clock
-
- clock-names:
- items:
- - const: iface
- - const: ahb
- - const: core
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- "#address-cells": true
-
- "#size-cells": true
-
- "#interrupt-cells":
- const: 1
-
- iommus:
- items:
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
-
- ranges: true
-
- interconnects:
- items:
- - description: Interconnect path specifying the port ids for data bus
-
- interconnect-names:
- const: mdp0-mem
-
- resets:
- items:
- - description: MDSS_CORE reset
-
-patternProperties:
- "^display-controller@[0-9a-f]+$":
- type: object
- description: Node containing the properties of DPU.
- additionalProperties: false
-
- properties:
- compatible:
- items:
- - const: qcom,sc7180-dpu
-
- reg:
- items:
- - description: Address offset and size for mdp register set
- - description: Address offset and size for vbif register set
-
- reg-names:
- items:
- - const: mdp
- - const: vbif
-
- clocks:
- items:
- - description: Display hf axi clock
- - description: Display ahb clock
- - description: Display rotator clock
- - description: Display lut clock
- - description: Display core clock
- - description: Display vsync clock
-
- clock-names:
- items:
- - const: bus
- - const: iface
- - const: rot
- - const: lut
- - const: core
- - const: vsync
-
- interrupts:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- operating-points-v2: true
- opp-table:
- type: object
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- description: |
- Contains the list of output ports from DPU device. These ports
- connect to interfaces that are external to the DPU hardware,
- such as DSI, DP etc. Each output port contains an endpoint that
- describes how it is connected to an external interface.
-
- properties:
- port@0:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF1 (DSI1)
-
- port@2:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF0 (DP)
-
- required:
- - port@0
-
- required:
- - compatible
- - reg
- - reg-names
- - clocks
- - interrupts
- - power-domains
- - operating-points-v2
- - ports
-
-required:
- - compatible
- - reg
- - reg-names
- - power-domains
- - clocks
- - interrupts
- - interrupt-controller
- - iommus
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,dispcc-sc7180.h>
- #include <dt-bindings/clock/qcom,gcc-sc7180.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interconnect/qcom,sdm845.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- display-subsystem@ae00000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,sc7180-mdss";
- reg = <0xae00000 0x1000>;
- reg-names = "mdss";
- power-domains = <&dispcc MDSS_GDSC>;
- clocks = <&gcc GCC_DISP_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface", "ahb", "core";
-
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>;
- interconnect-names = "mdp0-mem";
-
- iommus = <&apps_smmu 0x800 0x2>;
- ranges;
-
- display-controller@ae01000 {
- compatible = "qcom,sc7180-dpu";
- reg = <0x0ae01000 0x8f000>,
- <0x0aeb0000 0x2008>;
-
- reg-names = "mdp", "vbif";
-
- clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
- <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_ROT_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>,
- <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
- clock-names = "bus", "iface", "rot", "lut", "core",
- "vsync";
-
- interrupt-parent = <&mdss>;
- interrupts = <0>;
- power-domains = <&rpmhpd SC7180_CX>;
- operating-points-v2 = <&mdp_opp_table>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- dpu_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
-
- port@2 {
- reg = <2>;
- dpu_intf0_out: endpoint {
- remote-endpoint = <&dp_in>;
- };
- };
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
deleted file mode 100644
index 584d646021d5..000000000000
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
+++ /dev/null
@@ -1,239 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/msm/dpu-sc7280.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Display DPU dt properties for SC7280
-
-maintainers:
- - Krishna Manikandan <quic_mkrishn@quicinc.com>
-
-description: |
- Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates
- sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
- bindings of MDSS and DPU are mentioned for SC7280.
-
-properties:
- compatible:
- const: qcom,sc7280-mdss
-
- reg:
- maxItems: 1
-
- reg-names:
- const: mdss
-
- power-domains:
- maxItems: 1
-
- clocks:
- items:
- - description: Display AHB clock from gcc
- - description: Display AHB clock from dispcc
- - description: Display core clock
-
- clock-names:
- items:
- - const: iface
- - const: ahb
- - const: core
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- "#address-cells": true
-
- "#size-cells": true
-
- "#interrupt-cells":
- const: 1
-
- iommus:
- items:
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
-
- ranges: true
-
- interconnects:
- items:
- - description: Interconnect path specifying the port ids for data bus
-
- interconnect-names:
- const: mdp0-mem
-
- resets:
- items:
- - description: MDSS_CORE reset
-
-patternProperties:
- "^display-controller@[0-9a-f]+$":
- type: object
- description: Node containing the properties of DPU.
- additionalProperties: false
-
- properties:
- compatible:
- const: qcom,sc7280-dpu
-
- reg:
- items:
- - description: Address offset and size for mdp register set
- - description: Address offset and size for vbif register set
-
- reg-names:
- items:
- - const: mdp
- - const: vbif
-
- clocks:
- items:
- - description: Display hf axi clock
- - description: Display sf axi clock
- - description: Display ahb clock
- - description: Display lut clock
- - description: Display core clock
- - description: Display vsync clock
-
- clock-names:
- items:
- - const: bus
- - const: nrt_bus
- - const: iface
- - const: lut
- - const: core
- - const: vsync
-
- interrupts:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- operating-points-v2: true
- opp-table:
- type: object
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- description: |
- Contains the list of output ports from DPU device. These ports
- connect to interfaces that are external to the DPU hardware,
- such as DSI, DP etc. Each output port contains an endpoint that
- describes how it is connected to an external interface.
-
- properties:
- port@0:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF1 (DSI)
-
- port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF5 (EDP)
-
- required:
- - port@0
-
- required:
- - compatible
- - reg
- - reg-names
- - clocks
- - interrupts
- - power-domains
- - operating-points-v2
- - ports
-
-required:
- - compatible
- - reg
- - reg-names
- - power-domains
- - clocks
- - interrupts
- - interrupt-controller
- - iommus
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,dispcc-sc7280.h>
- #include <dt-bindings/clock/qcom,gcc-sc7280.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interconnect/qcom,sc7280.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- display-subsystem@ae00000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,sc7280-mdss";
- reg = <0xae00000 0x1000>;
- reg-names = "mdss";
- power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
- clocks = <&gcc GCC_DISP_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface",
- "ahb",
- "core";
-
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>;
- interconnect-names = "mdp0-mem";
-
- iommus = <&apps_smmu 0x900 0x402>;
- ranges;
-
- display-controller@ae01000 {
- compatible = "qcom,sc7280-dpu";
- reg = <0x0ae01000 0x8f000>,
- <0x0aeb0000 0x2008>;
-
- reg-names = "mdp", "vbif";
-
- clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
- <&gcc GCC_DISP_SF_AXI_CLK>,
- <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>,
- <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
- clock-names = "bus",
- "nrt_bus",
- "iface",
- "lut",
- "core",
- "vsync";
-
- interrupt-parent = <&mdss>;
- interrupts = <0>;
- power-domains = <&rpmhpd SC7280_CX>;
- operating-points-v2 = <&mdp_opp_table>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- dpu_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
-
- port@1 {
- reg = <1>;
- dpu_intf5_out: endpoint {
- remote-endpoint = <&edp_in>;
- };
- };
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
deleted file mode 100644
index 7d1037373175..000000000000
--- a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
+++ /dev/null
@@ -1,217 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/msm/dpu-sdm845.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Display DPU dt properties for SDM845 target
-
-maintainers:
- - Krishna Manikandan <quic_mkrishn@quicinc.com>
-
-description: |
- Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
- sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
- bindings of MDSS and DPU are mentioned for SDM845 target.
-
-properties:
- compatible:
- items:
- - const: qcom,sdm845-mdss
-
- reg:
- maxItems: 1
-
- reg-names:
- const: mdss
-
- power-domains:
- maxItems: 1
-
- clocks:
- items:
- - description: Display AHB clock from gcc
- - description: Display core clock
-
- clock-names:
- items:
- - const: iface
- - const: core
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- "#address-cells": true
-
- "#size-cells": true
-
- "#interrupt-cells":
- const: 1
-
- iommus:
- items:
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
- - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1
-
- ranges: true
-
- resets:
- items:
- - description: MDSS_CORE reset
-
-patternProperties:
- "^display-controller@[0-9a-f]+$":
- type: object
- description: Node containing the properties of DPU.
- additionalProperties: false
-
- properties:
- compatible:
- items:
- - const: qcom,sdm845-dpu
-
- reg:
- items:
- - description: Address offset and size for mdp register set
- - description: Address offset and size for vbif register set
-
- reg-names:
- items:
- - const: mdp
- - const: vbif
-
- clocks:
- items:
- - description: Display ahb clock
- - description: Display axi clock
- - description: Display core clock
- - description: Display vsync clock
-
- clock-names:
- items:
- - const: iface
- - const: bus
- - const: core
- - const: vsync
-
- interrupts:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- operating-points-v2: true
- opp-table:
- type: object
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- description: |
- Contains the list of output ports from DPU device. These ports
- connect to interfaces that are external to the DPU hardware,
- such as DSI, DP etc. Each output port contains an endpoint that
- describes how it is connected to an external interface.
-
- properties:
- port@0:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF1 (DSI1)
-
- port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description: DPU_INTF2 (DSI2)
-
- required:
- - port@0
- - port@1
-
- required:
- - compatible
- - reg
- - reg-names
- - clocks
- - interrupts
- - power-domains
- - operating-points-v2
- - ports
-
-required:
- - compatible
- - reg
- - reg-names
- - power-domains
- - clocks
- - interrupts
- - interrupt-controller
- - iommus
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
- #include <dt-bindings/clock/qcom,gcc-sdm845.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- display-subsystem@ae00000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,sdm845-mdss";
- reg = <0x0ae00000 0x1000>;
- reg-names = "mdss";
- power-domains = <&dispcc MDSS_GDSC>;
-
- clocks = <&gcc GCC_DISP_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface", "core";
-
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- iommus = <&apps_smmu 0x880 0x8>,
- <&apps_smmu 0xc80 0x8>;
- ranges;
-
- display-controller@ae01000 {
- compatible = "qcom,sdm845-dpu";
- reg = <0x0ae01000 0x8f000>,
- <0x0aeb0000 0x2008>;
- reg-names = "mdp", "vbif";
-
- clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_AXI_CLK>,
- <&dispcc DISP_CC_MDSS_MDP_CLK>,
- <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
- clock-names = "iface", "bus", "core", "vsync";
-
- interrupt-parent = <&mdss>;
- interrupts = <0>;
- power-domains = <&rpmhpd SDM845_CX>;
- operating-points-v2 = <&mdp_opp_table>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- dpu_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
-
- port@1 {
- reg = <1>;
- dpu_intf2_out: endpoint {
- remote-endpoint = <&dsi1_in>;
- };
- };
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 880bfe930830..4400d4cce072 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml#
@@ -9,14 +9,46 @@ title: Qualcomm Display DSI controller
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
-allOf:
- - $ref: "../dsi-controller.yaml#"
-
properties:
compatible:
- enum:
- - qcom,mdss-dsi-ctrl
- - qcom,dsi-ctrl-6g-qcm2290
+ oneOf:
+ - items:
+ - enum:
+ - qcom,apq8064-dsi-ctrl
+ - qcom,msm8226-dsi-ctrl
+ - qcom,msm8916-dsi-ctrl
+ - qcom,msm8953-dsi-ctrl
+ - qcom,msm8974-dsi-ctrl
+ - qcom,msm8976-dsi-ctrl
+ - qcom,msm8996-dsi-ctrl
+ - qcom,msm8998-dsi-ctrl
+ - qcom,qcm2290-dsi-ctrl
+ - qcom,sa8775p-dsi-ctrl
+ - qcom,sar2130p-dsi-ctrl
+ - qcom,sc7180-dsi-ctrl
+ - qcom,sc7280-dsi-ctrl
+ - qcom,sc8180x-dsi-ctrl
+ - qcom,sdm660-dsi-ctrl
+ - qcom,sdm670-dsi-ctrl
+ - qcom,sdm845-dsi-ctrl
+ - qcom,sm6115-dsi-ctrl
+ - qcom,sm6125-dsi-ctrl
+ - qcom,sm6150-dsi-ctrl
+ - qcom,sm6350-dsi-ctrl
+ - qcom,sm6375-dsi-ctrl
+ - qcom,sm7150-dsi-ctrl
+ - qcom,sm8150-dsi-ctrl
+ - qcom,sm8250-dsi-ctrl
+ - qcom,sm8350-dsi-ctrl
+ - qcom,sm8450-dsi-ctrl
+ - qcom,sm8550-dsi-ctrl
+ - qcom,sm8650-dsi-ctrl
+ - qcom,sm8750-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+ - enum:
+ - qcom,dsi-ctrl-6g-qcm2290
+ - qcom,mdss-dsi-ctrl # This should always come with an SoC-specific compatible
+ deprecated: true
reg:
maxItems: 1
@@ -28,36 +60,34 @@ properties:
maxItems: 1
clocks:
- items:
- - description: Display byte clock
- - description: Display byte interface clock
- - description: Display pixel clock
- - description: Display escape clock
- - description: Display AHB clock
- - description: Display AXI clock
+ description: |
+ Several clocks are used, depending on the variant. Typical ones are::
+ - bus:: Display AHB clock.
+ - byte:: Display byte clock.
+ - byte_intf:: Display byte interface clock.
+ - core:: Display core clock.
+ - core_mss:: Core MultiMedia SubSystem clock.
+ - iface:: Display AXI clock.
+ - mdp_core:: MDP Core clock.
+ - mnoc:: MNOC clock
+ - pixel:: Display pixel clock.
+ minItems: 3
+ maxItems: 12
clock-names:
- items:
- - const: byte
- - const: byte_intf
- - const: pixel
- - const: core
- - const: iface
- - const: bus
+ minItems: 3
+ maxItems: 12
phys:
maxItems: 1
phy-names:
+ deprecated: true
const: dsi
- "#address-cells": true
-
- "#size-cells": true
-
syscon-sfpb:
description: A phandle to mmss_sfpb syscon node (only for DSIv2).
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
qcom,dual-dsi-mode:
type: boolean
@@ -65,15 +95,30 @@ properties:
Indicates if the DSI controller is driving a panel which needs
2 DSI links.
+ qcom,master-dsi:
+ type: boolean
+ description: |
+ Indicates if the DSI controller is the master DSI controller when
+ qcom,dual-dsi-mode enabled.
+
+ qcom,sync-dual-dsi:
+ type: boolean
+ description: |
+ Indicates if the DSI controller needs to sync the other DSI controller
+ with MIPI DCS commands when qcom,dual-dsi-mode enabled.
+
assigned-clocks:
minItems: 2
- maxItems: 2
+ maxItems: 4
description: |
- Parents of "byte" and "pixel" for the given platform.
+ For DSI on SM8650 and older: parents of "byte" and "pixel" for the given
+ platform.
+ For DSIv2 platforms this should contain "byte", "esc", "src" and
+ "pixel_src" clocks.
assigned-clock-parents:
minItems: 2
- maxItems: 2
+ maxItems: 4
description: |
The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block.
@@ -82,15 +127,18 @@ properties:
operating-points-v2: true
+ opp-table:
+ type: object
+
ports:
- $ref: "/schemas/graph.yaml#/properties/ports"
+ $ref: /schemas/graph.yaml#/properties/ports
description: |
Contains DSI controller input and output ports as children, each
containing one endpoint subnode.
properties:
port@0:
- $ref: "/schemas/graph.yaml#/$defs/port-base"
+ $ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: |
Input endpoints of the controller.
@@ -101,12 +149,12 @@ properties:
properties:
data-lanes:
maxItems: 4
- minItems: 4
+ minItems: 1
items:
enum: [ 0, 1, 2, 3 ]
port@1:
- $ref: "/schemas/graph.yaml#/$defs/port-base"
+ $ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: |
Output endpoints of the controller.
@@ -117,14 +165,54 @@ properties:
properties:
data-lanes:
maxItems: 4
- minItems: 4
+ minItems: 1
items:
enum: [ 0, 1, 2, 3 ]
+ qcom,te-source:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Specifies the source of vsync signal from the panel used for
+ tearing elimination.
+ default: mdp_vsync_p
+ enum:
+ - mdp_vsync_p
+ - mdp_vsync_s
+ - mdp_vsync_e
+ - timer0
+ - timer1
+ - timer2
+ - timer3
+ - timer4
+
required:
- port@0
- port@1
+ avdd-supply:
+ description:
+ Phandle to vdd regulator device node
+
+ refgen-supply:
+ description:
+ Phandle to REFGEN regulator device node
+
+ vcca-supply:
+ description:
+ Phandle to vdd regulator device node
+
+ vdd-supply:
+ description:
+ VDD regulator
+
+ vddio-supply:
+ description:
+ VDD-IO regulator
+
+ vdda-supply:
+ description:
+ VDDA regulator
+
required:
- compatible
- reg
@@ -133,73 +221,262 @@ required:
- clocks
- clock-names
- phys
- - phy-names
- - assigned-clocks
- - assigned-clock-parents
- - power-domains
- - operating-points-v2
- ports
-additionalProperties: false
+allOf:
+ - $ref: ../dsi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,apq8064-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core_mmss
+ - const: src
+ - const: byte
+ - const: pixel
+ - const: core
+ required:
+ - assigned-clocks
+ - assigned-clock-parents
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8916-dsi-ctrl
+ - qcom,msm8953-dsi-ctrl
+ - qcom,msm8976-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: iface
+ - const: bus
+ - const: byte
+ - const: pixel
+ - const: core
+ required:
+ - assigned-clocks
+ - assigned-clock-parents
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8226-dsi-ctrl
+ - qcom,msm8974-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: iface
+ - const: bus
+ - const: byte
+ - const: pixel
+ - const: core
+ - const: core_mmss
+ required:
+ - assigned-clocks
+ - assigned-clock-parents
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: byte
+ - const: iface
+ - const: bus
+ - const: core_mmss
+ - const: pixel
+ - const: core
+ required:
+ - assigned-clocks
+ - assigned-clock-parents
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-dsi-ctrl
+ - qcom,sa8775p-dsi-ctrl
+ - qcom,sar2130p-dsi-ctrl
+ - qcom,sc7180-dsi-ctrl
+ - qcom,sc7280-dsi-ctrl
+ - qcom,sc8180x-dsi-ctrl
+ - qcom,sdm845-dsi-ctrl
+ - qcom,sm6115-dsi-ctrl
+ - qcom,sm6125-dsi-ctrl
+ - qcom,sm6350-dsi-ctrl
+ - qcom,sm6375-dsi-ctrl
+ - qcom,sm6150-dsi-ctrl
+ - qcom,sm7150-dsi-ctrl
+ - qcom,sm8150-dsi-ctrl
+ - qcom,sm8250-dsi-ctrl
+ - qcom,sm8350-dsi-ctrl
+ - qcom,sm8450-dsi-ctrl
+ - qcom,sm8550-dsi-ctrl
+ - qcom,sm8650-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clock-names:
+ items:
+ - const: byte
+ - const: byte_intf
+ - const: pixel
+ - const: core
+ - const: iface
+ - const: bus
+ required:
+ - assigned-clocks
+ - assigned-clock-parents
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 12
+ maxItems: 12
+ clock-names:
+ items:
+ - const: byte
+ - const: byte_intf
+ - const: pixel
+ - const: core
+ - const: iface
+ - const: bus
+ - const: dsi_pll_pixel
+ - const: dsi_pll_byte
+ - const: esync
+ - const: osc
+ - const: byte_src
+ - const: pixel_src
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdm660-dsi-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 9
+ maxItems: 9
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: byte
+ - const: byte_intf
+ - const: mnoc
+ - const: iface
+ - const: bus
+ - const: core_mmss
+ - const: pixel
+ - const: core
+ required:
+ - assigned-clocks
+ - assigned-clock-parents
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
- #include <dt-bindings/clock/qcom,gcc-sdm845.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- dsi@ae94000 {
- compatible = "qcom,mdss-dsi-ctrl";
- reg = <0x0ae94000 0x400>;
- reg-names = "dsi_ctrl";
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- interrupt-parent = <&mdss>;
- interrupts = <4>;
-
- clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
- <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
- <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
- <&dispcc DISP_CC_MDSS_ESC0_CLK>,
- <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&dispcc DISP_CC_MDSS_AXI_CLK>;
- clock-names = "byte",
- "byte_intf",
- "pixel",
- "core",
- "iface",
- "bus";
-
- phys = <&dsi0_phy>;
- phy-names = "dsi";
-
- assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
- assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>;
-
- power-domains = <&rpmhpd SC7180_CX>;
- operating-points-v2 = <&dsi_opp_table>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- dsi0_in: endpoint {
- remote-endpoint = <&dpu_intf1_out>;
- };
- };
-
- port@1 {
- reg = <1>;
- dsi0_out: endpoint {
- remote-endpoint = <&sn65dsi86_in>;
- data-lanes = <0 1 2 3>;
- };
- };
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ dsi@ae94000 {
+ compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>;
+
+ power-domains = <&rpmhpd SC7180_CX>;
+ operating-points-v2 = <&dsi_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&sn65dsi86_in>;
+ data-lanes = <0 1 2 3>;
+ qcom,te-source = "mdp_vsync_e";
+ };
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
index 716f921e3532..fc9abf090f0d 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml#
@@ -37,7 +37,6 @@ properties:
qcom,phy-rescode-offset-top:
$ref: /schemas/types.yaml#/definitions/int8-array
- minItems: 5
maxItems: 5
description:
Integer array of offset for pull-up legs rescode for all five lanes.
@@ -49,7 +48,6 @@ properties:
qcom,phy-rescode-offset-bot:
$ref: /schemas/types.yaml#/definitions/int8-array
- minItems: 5
maxItems: 5
description:
Integer array of offset for pull-down legs rescode for all five lanes.
@@ -60,7 +58,7 @@ properties:
maximum: 31
qcom,phy-drive-ldo-level:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
The PHY LDO has an amplitude tuning feature to adjust the LDO output
for the HSTX drive. Use supported levels (mV) to offset the drive level
@@ -71,34 +69,33 @@ required:
- compatible
- reg
- reg-names
- - vdds-supply
unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
-
- dsi-phy@ae94400 {
- compatible = "qcom,dsi-phy-10nm";
- reg = <0x0ae94400 0x200>,
- <0x0ae94600 0x280>,
- <0x0ae94a00 0x1e0>;
- reg-names = "dsi_phy",
- "dsi_phy_lane",
- "dsi_pll";
-
- #clock-cells = <1>;
- #phy-cells = <0>;
-
- vdds-supply = <&vdda_mipi_dsi0_pll>;
- clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&rpmhcc RPMH_CXO_CLK>;
- clock-names = "iface", "ref";
-
- qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>;
- qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>;
- qcom,phy-drive-ldo-level = <400>;
- };
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ dsi-phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ vdds-supply = <&vdda_mipi_dsi0_pll>;
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+
+ qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>;
+ qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>;
+ qcom,phy-drive-ldo-level = <400>;
+ };
...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
index 1342d74ecfe0..206a9a4b3845 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml#
@@ -16,8 +16,11 @@ properties:
compatible:
enum:
- qcom,dsi-phy-14nm
+ - qcom,dsi-phy-14nm-2290
- qcom,dsi-phy-14nm-660
- qcom,dsi-phy-14nm-8953
+ - qcom,sm6125-dsi-phy-14nm
+ - qcom,sm6150-dsi-phy-14nm
reg:
items:
@@ -34,34 +37,43 @@ properties:
vcca-supply:
description: Phandle to vcca regulator device node.
+ power-domains:
+ description:
+ A phandle and PM domain specifier for an optional power domain.
+ maxItems: 1
+
+ required-opps:
+ description:
+ A phandle to an OPP node describing the power domain's performance point.
+ maxItems: 1
+
required:
- compatible
- reg
- reg-names
- - vcca-supply
unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
- dsi-phy@ae94400 {
- compatible = "qcom,dsi-phy-14nm";
- reg = <0x0ae94400 0x200>,
- <0x0ae94600 0x280>,
- <0x0ae94a00 0x1e0>;
- reg-names = "dsi_phy",
- "dsi_phy_lane",
- "dsi_pll";
+ dsi-phy@ae94400 {
+ compatible = "qcom,dsi-phy-14nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
- #clock-cells = <1>;
- #phy-cells = <0>;
+ #clock-cells = <1>;
+ #phy-cells = <0>;
- vcca-supply = <&vcca_reg>;
- clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&rpmhcc RPMH_CXO_CLK>;
- clock-names = "iface", "ref";
- };
+ vcca-supply = <&vcca_reg>;
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
index 9c1f9140c731..93570052992a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml#
@@ -45,26 +45,26 @@ unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
- dsi-phy@fd922a00 {
- compatible = "qcom,dsi-phy-20nm";
- reg = <0xfd922a00 0xd4>,
- <0xfd922b00 0x2b0>,
- <0xfd922d80 0x7b>;
- reg-names = "dsi_pll",
- "dsi_phy",
- "dsi_phy_regulator";
+ dsi-phy@fd922a00 {
+ compatible = "qcom,dsi-phy-20nm";
+ reg = <0xfd922a00 0xd4>,
+ <0xfd922b00 0x2b0>,
+ <0xfd922d80 0x7b>;
+ reg-names = "dsi_pll",
+ "dsi_phy",
+ "dsi_phy_regulator";
- #clock-cells = <1>;
- #phy-cells = <0>;
+ #clock-cells = <1>;
+ #phy-cells = <0>;
- vcca-supply = <&vcca_reg>;
- vddio-supply = <&vddio_reg>;
+ vcca-supply = <&vcca_reg>;
+ vddio-supply = <&vddio_reg>;
- clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&rpmhcc RPMH_CXO_CLK>;
- clock-names = "iface", "ref";
- };
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
index 3d8540a06fe2..371befa9f9d2 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml#
@@ -15,9 +15,12 @@ allOf:
properties:
compatible:
enum:
+ - qcom,dsi-phy-28nm-8226
+ - qcom,dsi-phy-28nm-8937
+ - qcom,dsi-phy-28nm-8960
- qcom,dsi-phy-28nm-hpm
+ - qcom,dsi-phy-28nm-hpm-fam-b
- qcom,dsi-phy-28nm-lp
- - qcom,dsi-phy-28nm-8960
reg:
items:
@@ -34,6 +37,10 @@ properties:
vddio-supply:
description: Phandle to vdd-io regulator device node.
+ qcom,dsi-phy-regulator-ldo-mode:
+ type: boolean
+ description: Indicates if the LDO mode PHY regulator is wanted.
+
required:
- compatible
- reg
@@ -44,25 +51,25 @@ unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
- dsi-phy@fd922a00 {
- compatible = "qcom,dsi-phy-28nm-lp";
- reg = <0xfd922a00 0xd4>,
- <0xfd922b00 0x2b0>,
- <0xfd922d80 0x7b>;
- reg-names = "dsi_pll",
- "dsi_phy",
- "dsi_phy_regulator";
+ dsi-phy@fd922a00 {
+ compatible = "qcom,dsi-phy-28nm-lp";
+ reg = <0xfd922a00 0xd4>,
+ <0xfd922b00 0x2b0>,
+ <0xfd922d80 0x7b>;
+ reg-names = "dsi_pll",
+ "dsi_phy",
+ "dsi_phy_regulator";
- #clock-cells = <1>;
- #phy-cells = <0>;
+ #clock-cells = <1>;
+ #phy-cells = <0>;
- vddio-supply = <&vddio_reg>;
+ vddio-supply = <&vddio_reg>;
- clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&rpmhcc RPMH_CXO_CLK>;
- clock-names = "iface", "ref";
- };
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
...
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
index c851770bbdf2..1ca820a500b7 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-7nm.yaml#
@@ -17,7 +17,15 @@ properties:
enum:
- qcom,dsi-phy-7nm
- qcom,dsi-phy-7nm-8150
+ - qcom,sa8775p-dsi-phy-5nm
+ - qcom,sar2130p-dsi-phy-5nm
- qcom,sc7280-dsi-phy-7nm
+ - qcom,sm6375-dsi-phy-7nm
+ - qcom,sm8350-dsi-phy-5nm
+ - qcom,sm8450-dsi-phy-5nm
+ - qcom,sm8550-dsi-phy-4nm
+ - qcom,sm8650-dsi-phy-4nm
+ - qcom,sm8750-dsi-phy-3nm
reg:
items:
@@ -44,29 +52,28 @@ required:
- compatible
- reg
- reg-names
- - vdds-supply
unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,dispcc-sm8250.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,dispcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
- dsi-phy@ae94400 {
- compatible = "qcom,dsi-phy-7nm";
- reg = <0x0ae94400 0x200>,
- <0x0ae94600 0x280>,
- <0x0ae94900 0x260>;
- reg-names = "dsi_phy",
- "dsi_phy_lane",
- "dsi_pll";
+ dsi-phy@ae94400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
- #clock-cells = <1>;
- #phy-cells = <0>;
+ #clock-cells = <1>;
+ #phy-cells = <0>;
- vdds-supply = <&vreg_l5a_0p88>;
- clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
- <&rpmhcc RPMH_CXO_CLK>;
- clock-names = "iface", "ref";
- };
+ vdds-supply = <&vreg_l5a_0p88>;
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
index 76d40f7933dd..d0ce85a08b6d 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
@@ -1,21 +1,22 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Description of Qualcomm Display DSI PHY common dt properties
+title: Qualcomm Display DSI PHY Common Properties
maintainers:
- Krishna Manikandan <quic_mkrishn@quicinc.com>
-description: |
- This defines the DSI PHY dt properties which are common for all
- dsi phy versions.
+description:
+ Common properties for Qualcomm Display DSI PHY.
properties:
"#clock-cells":
const: 1
+ description:
+ See include/dt-bindings/clock/qcom,dsi-phy-28nm.h for clock IDs.
"#phy-cells":
const: 0
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
index 67fdeeabae0c..e32056ae0f5d 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
@@ -3,10 +3,10 @@
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/msm/gmu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/msm/gmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Devicetree bindings for the GMU attached to certain Adreno GPUs
+title: GMU attached to certain Adreno GPUs
maintainers:
- Rob Clark <robdclark@gmail.com>
@@ -19,16 +19,21 @@ description: |
properties:
compatible:
- items:
- - pattern: '^qcom,adreno-gmu-6[0-9][0-9]\.[0-9]$'
- - const: qcom,adreno-gmu
+ oneOf:
+ - items:
+ - pattern: '^qcom,adreno-gmu-[6-8][0-9][0-9]\.[0-9]$'
+ - const: qcom,adreno-gmu
+ - items:
+ - pattern: '^qcom,adreno-gmu-x[1-9][0-9][0-9]\.[0-9]$'
+ - const: qcom,adreno-gmu
+ - const: qcom,adreno-gmu-wrapper
reg:
- minItems: 3
+ minItems: 1
maxItems: 4
reg-names:
- minItems: 3
+ minItems: 1
maxItems: 4
clocks:
@@ -44,7 +49,6 @@ properties:
- description: GMU HFI interrupt
- description: GMU interrupt
-
interrupt-names:
items:
- const: hfi
@@ -63,6 +67,10 @@ properties:
iommus:
maxItems: 1
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM
+
operating-points-v2: true
opp-table:
@@ -72,14 +80,8 @@ required:
- compatible
- reg
- reg-names
- - clocks
- - clock-names
- - interrupts
- - interrupt-names
- power-domains
- power-domain-names
- - iommus
- - operating-points-v2
additionalProperties: false
@@ -121,7 +123,44 @@ allOf:
compatible:
contains:
enum:
+ - qcom,adreno-gmu-623.0
+ then:
+ properties:
+ reg:
+ items:
+ - description: Core GMU registers
+ - description: Resource controller registers
+ - description: GMU PDC registers
+ reg-names:
+ items:
+ - const: gmu
+ - const: rscc
+ - const: gmu_pdc
+ clocks:
+ items:
+ - description: GMU clock
+ - description: GPU CX clock
+ - description: GPU AXI clock
+ - description: GPU MEMNOC clock
+ - description: GPU AHB clock
+ - description: GPU HUB CX clock
+ clock-names:
+ items:
+ - const: gmu
+ - const: cxo
+ - const: axi
+ - const: memnoc
+ - const: ahb
+ - const: hub
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,adreno-gmu-635.0
+ - qcom,adreno-gmu-660.1
+ - qcom,adreno-gmu-663.0
then:
properties:
reg:
@@ -217,6 +256,129 @@ allOf:
- const: axi
- const: memnoc
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-gmu-730.1
+ - qcom,adreno-gmu-740.1
+ - qcom,adreno-gmu-750.1
+ - qcom,adreno-gmu-x185.1
+ then:
+ properties:
+ reg:
+ items:
+ - description: Core GMU registers
+ - description: Resource controller registers
+ - description: GMU PDC registers
+ reg-names:
+ items:
+ - const: gmu
+ - const: rscc
+ - const: gmu_pdc
+ clocks:
+ items:
+ - description: GPU AHB clock
+ - description: GMU clock
+ - description: GPU CX clock
+ - description: GPU AXI clock
+ - description: GPU MEMNOC clock
+ - description: GMU HUB clock
+ - description: GPUSS DEMET clock
+ clock-names:
+ items:
+ - const: ahb
+ - const: gmu
+ - const: cxo
+ - const: axi
+ - const: memnoc
+ - const: hub
+ - const: demet
+
+ required:
+ - qcom,qmp
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,adreno-gmu-840.1
+ then:
+ properties:
+ reg:
+ items:
+ - description: Core GMU registers
+ reg-names:
+ items:
+ - const: gmu
+ clocks:
+ items:
+ - description: GPU AHB clock
+ - description: GMU clock
+ - description: GPU CX clock
+ - description: GPU MEMNOC clock
+ - description: GMU HUB clock
+ clock-names:
+ items:
+ - const: ahb
+ - const: gmu
+ - const: cxo
+ - const: memnoc
+ - const: hub
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,adreno-gmu-x285.1
+ then:
+ properties:
+ reg:
+ items:
+ - description: Core GMU registers
+ reg-names:
+ items:
+ - const: gmu
+ clocks:
+ items:
+ - description: GPU AHB clock
+ - description: GMU clock
+ - description: GPU CX clock
+ - description: GPU MEMNOC clock
+ - description: GMU HUB clock
+ - description: GMU RSCC HUB clock
+ clock-names:
+ items:
+ - const: ahb
+ - const: gmu
+ - const: cxo
+ - const: memnoc
+ - const: hub
+ - const: rscc
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,adreno-gmu-wrapper
+ then:
+ properties:
+ reg:
+ items:
+ - description: GMU wrapper register space
+ reg-names:
+ items:
+ - const: gmu
+ else:
+ required:
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - operating-points-v2
+
examples:
- |
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
@@ -225,7 +387,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
gmu: gmu@506a000 {
- compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
+ compatible = "qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
reg = <0x506a000 0x30000>,
<0xb280000 0x10000>,
@@ -249,3 +411,12 @@ examples:
iommus = <&adreno_smmu 5>;
operating-points-v2 = <&gmu_opp_table>;
};
+
+ gmu_wrapper: gmu@596a000 {
+ compatible = "qcom,adreno-gmu-wrapper";
+ reg = <0x0596a000 0x30000>;
+ reg-names = "gmu";
+ power-domains = <&gpucc GPU_CX_GDSC>,
+ <&gpucc GPU_GX_GDSC>;
+ power-domain-names = "cx", "gx";
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index 346aabdccf7b..826aafdcc20b 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -2,22 +2,40 @@
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/msm/gpu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/msm/gpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Devicetree bindings for the Adreno or Snapdragon GPUs
+title: Adreno or Snapdragon GPUs
maintainers:
- Rob Clark <robdclark@gmail.com>
+# dtschema does not select nodes based on pattern+const, so add custom select
+# as a work-around:
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno
+ - amd,imageon
+ required:
+ - compatible
+
properties:
compatible:
oneOf:
- description: |
The driver is parsing the compat string for Adreno to
+ figure out the chip-id.
+ items:
+ - pattern: '^qcom,adreno-[0-9a-f]{8}$'
+ - const: qcom,adreno
+ - description: |
+ The driver is parsing the compat string for Adreno to
figure out the gpu-id and patch level.
items:
- - pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$'
+ - pattern: '^qcom,adreno-[3-7][0-9][0-9]\.[0-9]+$'
- const: qcom,adreno
- description: |
The driver is parsing the compat string for Imageon to
@@ -26,9 +44,13 @@ properties:
- pattern: '^amd,imageon-200\.[0-1]$'
- const: amd,imageon
- clocks: true
+ clocks:
+ minItems: 2
+ maxItems: 7
- clock-names: true
+ clock-names:
+ minItems: 2
+ maxItems: 7
reg:
minItems: 1
@@ -82,13 +104,14 @@ properties:
zap-shader:
type: object
+ additionalProperties: false
description: |
For a5xx and a6xx devices this node contains a memory-region that
points to reserved memory to store the zap shader that can be used to
help bring the GPU out of secure mode.
properties:
memory-region:
- $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
firmware-name:
description: |
@@ -110,7 +133,6 @@ properties:
For GMU attached devices a phandle to the GMU device that will
control the power for the GPU.
-
required:
- compatible
- reg
@@ -123,47 +145,268 @@ allOf:
properties:
compatible:
contains:
- pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]$'
+ oneOf:
+ - pattern: '^qcom,adreno-305\.[0-9]+$'
+ - pattern: '^qcom,adreno-330\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - if:
+ properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-306\.[0-9]+$'
then:
properties:
clocks:
- minItems: 2
- maxItems: 7
+ minItems: 5
+ maxItems: 6
+ clock-names:
+ oneOf:
+ - items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: gfx3d
+ description: GPU 3D engine clock
+ - items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem
+ description: GPU Memory clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: gfx3d
+ description: GPU 3D engine clock
+ - if:
+ properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-320\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
clock-names:
items:
- anyOf:
- - const: core
- description: GPU Core clock
- - const: iface
- description: GPU Interface clock
- - const: mem
- description: GPU Memory clock
- - const: mem_iface
- description: GPU Memory Interface clock
- - const: alt_mem_iface
- description: GPU Alternative Memory Interface clock
- - const: gfx3d
- description: GPU 3D engine clock
- - const: rbbmtimer
- description: GPU RBBM Timer for Adreno 5xx series
- minItems: 2
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem
+ description: GPU Memory clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-405\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 7
maxItems: 7
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem
+ description: GPU Memory clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: gfx3d
+ description: GPU 3D engine clock
+ - const: rbbmtimer
+ description: GPU RBBM Timer for Adreno 5xx series
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-50[56]\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: rbbmtimer
+ description: GPU RBBM Timer for Adreno 5xx series
+ - const: alwayson
+ description: GPU AON clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ oneOf:
+ - pattern: '^qcom,adreno-508\.[0-9]+$'
+ - pattern: '^qcom,adreno-509\.[0-9]+$'
+ - pattern: '^qcom,adreno-512\.[0-9]+$'
+ - pattern: '^qcom,adreno-540\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clock-names:
+ items:
+ - const: iface
+ description: GPU Interface clock
+ - const: rbbmtimer
+ description: GPU RBBM Timer for Adreno 5xx series
+ - const: mem
+ description: GPU Memory clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: rbcpr
+ description: GPU RB Core Power Reduction clock
+ - const: core
+ description: GPU Core clock
- required:
- - clocks
- - clock-names
- if:
properties:
compatible:
contains:
- pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$'
+ pattern: '^qcom,adreno-510\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem
+ description: GPU Memory clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: rbbmtimer
+ description: GPU RBBM Timer for Adreno 5xx series
+ - const: alwayson
+ description: GPU AON clock
- then: # Since Adreno 6xx series clocks should be defined in GMU
+ - if:
properties:
- clocks: false
- clock-names: false
+ compatible:
+ contains:
+ pattern: '^qcom,adreno-530\.[0-9]+$'
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: rbbmtimer
+ description: GPU RBBM Timer for Adreno 5xx series
+ - const: mem
+ description: GPU Memory clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,adreno-610.0
+ - qcom,adreno-619.1
+ - qcom,adreno-07000200
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: core
+ description: GPU Core clock
+ - const: iface
+ description: GPU Interface clock
+ - const: mem_iface
+ description: GPU Memory Interface clock
+ - const: alt_mem_iface
+ description: GPU Alternative Memory Interface clock
+ - const: gmu
+ description: CX GMU clock
+ - const: xo
+ description: GPUCC clocksource clock
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: kgsl_3d0_reg_memory
+ - const: cx_dbgc
+
+ required:
+ - clocks
+ - clock-names
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ oneOf:
+ - pattern: '^qcom,adreno-[67][0-9][0-9]\.[0-9]+$'
+ - pattern: '^qcom,adreno-[0-9a-f]{8}$'
+
+ then: # Starting with A6xx, the clocks are usually defined in the GMU node
+ properties:
+ clocks: false
+ clock-names: false
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: kgsl_3d0_reg_memory
+ - const: cx_mem
+ - const: cx_dbgc
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.yaml b/Documentation/devicetree/bindings/display/msm/hdmi.yaml
index 47e97669821c..dfec6c3480f3 100644
--- a/Documentation/devicetree/bindings/display/msm/hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/msm/hdmi.yaml
@@ -19,14 +19,15 @@ properties:
- qcom,hdmi-tx-8974
- qcom,hdmi-tx-8994
- qcom,hdmi-tx-8996
+ - qcom,hdmi-tx-8998
clocks:
minItems: 1
- maxItems: 5
+ maxItems: 8
clock-names:
minItems: 1
- maxItems: 5
+ maxItems: 8
reg:
minItems: 1
@@ -65,21 +66,6 @@ properties:
maxItems: 1
description: hpd pin
- qcom,hdmi-tx-mux-en-gpios:
- maxItems: 1
- deprecated: true
- description: HDMI mux enable pin
-
- qcom,hdmi-tx-mux-sel-gpios:
- maxItems: 1
- deprecated: true
- description: HDMI mux select pin
-
- qcom,hdmi-tx-mux-lpm-gpios:
- maxItems: 1
- deprecated: true
- description: HDMI mux lpm pin
-
'#sound-dai-cells':
const: 1
@@ -88,12 +74,12 @@ properties:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- $ref: /schemas/graph.yaml#/$defs/port-base
+ $ref: /schemas/graph.yaml#/properties/port
description: |
Input endpoints of the controller.
port@1:
- $ref: /schemas/graph.yaml#/$defs/port-base
+ $ref: /schemas/graph.yaml#/properties/port
description: |
Output endpoints of the controller.
@@ -142,6 +128,7 @@ allOf:
properties:
clocks:
minItems: 5
+ maxItems: 5
clock-names:
items:
- const: mdp_core
@@ -151,6 +138,28 @@ allOf:
- const: extp
hdmi-mux-supplies: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,hdmi-tx-8998
+ then:
+ properties:
+ clocks:
+ minItems: 8
+ maxItems: 8
+ clock-names:
+ items:
+ - const: mdp_core
+ - const: iface
+ - const: core
+ - const: alt_iface
+ - const: extp
+ - const: bus
+ - const: mnoc
+ - const: iface_mmss
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.yaml b/Documentation/devicetree/bindings/display/msm/mdp4.yaml
index 58c13f5277b6..03ee09faa335 100644
--- a/Documentation/devicetree/bindings/display/msm/mdp4.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdp4.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/msm/mdp4.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/msm/mdp4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Adreno/Snapdragon MDP4 display controller
@@ -18,9 +18,10 @@ properties:
clocks:
minItems: 6
- maxItems: 6
+ maxItems: 8
clock-names:
+ minItems: 6
items:
- const: core_clk
- const: iface_clk
@@ -28,6 +29,12 @@ properties:
- const: lut_clk
- const: hdmi_clk
- const: tv_clk
+ - const: lcdc_clk
+ - const: pxo
+ description: XO used to drive the internal LVDS PLL
+
+ '#clock-cells':
+ const: 0
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt b/Documentation/devicetree/bindings/display/msm/mdp5.txt
deleted file mode 100644
index 43d11279c925..000000000000
--- a/Documentation/devicetree/bindings/display/msm/mdp5.txt
+++ /dev/null
@@ -1,160 +0,0 @@
-Qualcomm adreno/snapdragon MDP5 display controller
-
-Description:
-
-This is the bindings documentation for the Mobile Display Subsytem(MDSS) that
-encapsulates sub-blocks like MDP5, DSI, HDMI, eDP etc, and the MDP5 display
-controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994 and MSM8996.
-
-MDSS:
-Required properties:
-- compatible:
- * "qcom,mdss" - MDSS
-- reg: Physical base address and length of the controller's registers.
-- reg-names: The names of register regions. The following regions are required:
- * "mdss_phys"
- * "vbif_phys"
-- interrupts: The interrupt signal from MDSS.
-- interrupt-controller: identifies the node as an interrupt controller.
-- #interrupt-cells: specifies the number of cells needed to encode an interrupt
- source, should be 1.
-- power-domains: a power domain consumer specifier according to
- Documentation/devicetree/bindings/power/power_domain.txt
-- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required.
- * "iface"
- * "bus"
- * "vsync"
-- #address-cells: number of address cells for the MDSS children. Should be 1.
-- #size-cells: Should be 1.
-- ranges: parent bus address space is the same as the child bus address space.
-
-Optional properties:
-- clock-names: the following clocks are optional:
- * "lut"
-
-MDP5:
-Required properties:
-- compatible:
- * "qcom,mdp5" - MDP5
-- reg: Physical base address and length of the controller's registers.
-- reg-names: The names of register regions. The following regions are required:
- * "mdp_phys"
-- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
-- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required.
-- * "bus"
-- * "iface"
-- * "core"
-- * "vsync"
-- ports: contains the list of output ports from MDP. These connect to interfaces
- that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
- special case since it is a part of the MDP block itself).
-
- Each output port contains an endpoint that describes how it is connected to an
- external interface. These are described by the standard properties documented
- here:
- Documentation/devicetree/bindings/graph.txt
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
- The availability of output ports can vary across SoC revisions:
-
- For MSM8974 and APQ8084:
- Port 0 -> MDP_INTF0 (eDP)
- Port 1 -> MDP_INTF1 (DSI1)
- Port 2 -> MDP_INTF2 (DSI2)
- Port 3 -> MDP_INTF3 (HDMI)
-
- For MSM8916:
- Port 0 -> MDP_INTF1 (DSI1)
-
- For MSM8994 and MSM8996:
- Port 0 -> MDP_INTF1 (DSI1)
- Port 1 -> MDP_INTF2 (DSI2)
- Port 2 -> MDP_INTF3 (HDMI)
-
-Optional properties:
-- clock-names: the following clocks are optional:
- * "lut"
- * "tbu"
- * "tbu_rt"
-
-Example:
-
-/ {
- ...
-
- mdss: mdss@1a00000 {
- compatible = "qcom,mdss";
- reg = <0x1a00000 0x1000>,
- <0x1ac8000 0x3000>;
- reg-names = "mdss_phys", "vbif_phys";
-
- power-domains = <&gcc MDSS_GDSC>;
-
- clocks = <&gcc GCC_MDSS_AHB_CLK>,
- <&gcc GCC_MDSS_AXI_CLK>,
- <&gcc GCC_MDSS_VSYNC_CLK>;
- clock-names = "iface",
- "bus",
- "vsync"
-
- interrupts = <0 72 0>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- mdp: mdp@1a01000 {
- compatible = "qcom,mdp5";
- reg = <0x1a01000 0x90000>;
- reg-names = "mdp_phys";
-
- interrupt-parent = <&mdss>;
- interrupts = <0 0>;
-
- clocks = <&gcc GCC_MDSS_AHB_CLK>,
- <&gcc GCC_MDSS_AXI_CLK>,
- <&gcc GCC_MDSS_MDP_CLK>,
- <&gcc GCC_MDSS_VSYNC_CLK>;
- clock-names = "iface",
- "bus",
- "core",
- "vsync";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- mdp5_intf1_out: endpoint {
- remote-endpoint = <&dsi0_in>;
- };
- };
- };
- };
-
- dsi0: dsi@1a98000 {
- ...
- ports {
- ...
- port@0 {
- reg = <0>;
- dsi0_in: endpoint {
- remote-endpoint = <&mdp5_intf1_out>;
- };
- };
- ...
- };
- ...
- };
-
- dsi_phy0: dsi-phy@1a98300 {
- ...
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
new file mode 100644
index 000000000000..c6305a6e0334
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/mdss-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display MDSS common properties
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc.
+
+# Do not select this by default, otherwise it is also selected for qcom,mdss
+# devices.
+select:
+ false
+
+properties:
+ $nodename:
+ pattern: "^display-subsystem@[0-9a-f]+$"
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ const: mdss
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 4
+
+ clock-names:
+ minItems: 2
+ maxItems: 4
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ "#interrupt-cells":
+ const: 1
+
+ iommus:
+ minItems: 1
+ items:
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1
+
+ ranges: true
+
+ # This is not a perfect description, but it's impossible to discern and match
+ # the entries like we do with interconnect-names
+ interconnects:
+ minItems: 1
+ items:
+ - description: Interconnect path from mdp0 (or a single mdp) port to the data bus
+ - description: Interconnect path from mdp1 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ oneOf:
+ - minItems: 1
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+ - minItems: 2
+ items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+ - const: cpu-cfg
+
+ resets:
+ items:
+ - description: MDSS_CORE reset
+
+ memory-region:
+ maxItems: 1
+ description:
+ Phandle to a node describing a reserved framebuffer memory region.
+ For example, the splash memory region set up by the bootloader.
+
+required:
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - iommus
+ - ranges
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
new file mode 100644
index 000000000000..2329ed96e6cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml
@@ -0,0 +1,264 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,glymur-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Glymur Display MDSS
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ Glymur MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DP interfaces, etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,glymur-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,glymur-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,glymur-dp
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,glymur-dp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,glymur-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy-qcom-qmp.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,glymur-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&dispcc_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdp_clk>;
+ clock-names = "bus", "nrt_bus", "core";
+
+ interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem",
+ "cpu-cfg";
+
+ resets = <&disp_cc_mdss_core_bcr>;
+
+ power-domains = <&mdss_gdsc>;
+
+ iommus = <&apps_smmu 0x1c00 0x2>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,glymur-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_axi_clk>,
+ <&dispcc_ahb_clk>,
+ <&dispcc_mdp_lut_clk>,
+ <&dispcc_mdp_clk>,
+ <&dispcc_mdp_vsync_clk>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_mdp_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-514000000 {
+ opp-hz = /bits/ 64 <514000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ displayport-controller@ae90000 {
+ compatible = "qcom,glymur-dp";
+ reg = <0xae90000 0x200>,
+ <0xae90200 0x200>,
+ <0xae90400 0x600>,
+ <0xae91000 0x400>,
+ <0xae91400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&dispcc_dptx0_aux_clk>,
+ <&dispcc_dptx0_link_clk>,
+ <&dispcc_dptx0_link_intf_clk>,
+ <&dispcc_dptx0_pixel0_clk>,
+ <&dispcc_dptx0_pixel1_clk>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel";
+
+ assigned-clocks = <&dispcc_mdss_dptx0_link_clk_src>,
+ <&dispcc_mdss_dptx0_pixel0_clk_src>,
+ <&dispcc_mdss_dptx0_pixel1_clk_src>;
+ assigned-clock-parents = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+ <&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ operating-points-v2 = <&mdss_dp0_opp_table>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp0_in: endpoint {
+ remote-endpoint = <&mdss_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp0_out: endpoint {
+ };
+ };
+ };
+
+ mdss_dp0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
new file mode 100644
index 000000000000..2735c78b0b67
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,mdp5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno/Snapdragon Mobile Display controller (MDP5)
+
+description:
+ MDP5 display controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994
+ and MSM8996.
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Rob Clark <robdclark@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,mdp5
+ deprecated: true
+ - items:
+ - enum:
+ - qcom,apq8084-mdp5
+ - qcom,msm8226-mdp5
+ - qcom,msm8916-mdp5
+ - qcom,msm8917-mdp5
+ - qcom,msm8937-mdp5
+ - qcom,msm8953-mdp5
+ - qcom,msm8974-mdp5
+ - qcom,msm8976-mdp5
+ - qcom,msm8994-mdp5
+ - qcom,msm8996-mdp5
+ - qcom,sdm630-mdp5
+ - qcom,sdm660-mdp5
+ - const: qcom,mdp5
+
+ $nodename:
+ pattern: '^display-controller@[0-9a-f]+$'
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: mdp_phys
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ maxItems: 7
+
+ clock-names:
+ oneOf:
+ - minItems: 4
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+ - const: tbu
+ - const: tbu_rt
+ # MSM8996 has additional iommu clock
+ - items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: iommu
+ - const: vsync
+
+ interconnects:
+ minItems: 1
+ items:
+ - description: Interconnect path from mdp0 (or a single mdp) port to the data bus
+ - description: Interconnect path from mdp1 port to the data bus
+ - description: Interconnect path from rotator port to the data bus
+
+ interconnect-names:
+ minItems: 1
+ items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+ - const: rotator-mem
+
+ iommus:
+ items:
+ - description: apps SMMU with the Stream-ID mask for Hard-Fail port0
+
+ power-domains:
+ maxItems: 1
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: >
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI, DP etc. MDP5 devices support up to 4 ports:
+ one or two DSI ports, HDMI and eDP.
+
+ patternProperties:
+ "^port@[0-3]+$":
+ $ref: /schemas/graph.yaml#/properties/port
+
+ # at least one port is required
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ display-controller@1a01000 {
+ compatible = "qcom,mdp5";
+ reg = <0x1a01000 0x90000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_MDP_CLK>,
+ <&gcc GCC_MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
new file mode 100644
index 000000000000..db9c43b20e2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml
@@ -0,0 +1,226 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Mobile Display SubSystem (MDSS)
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Rob Clark <robdclark@gmail.com>
+
+description:
+ This is the bindings documentation for the Mobile Display Subsystem(MDSS) that
+ encapsulates sub-blocks like MDP5, DSI, HDMI, eDP, etc.
+
+properties:
+ $nodename:
+ pattern: "^display-subsystem@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - qcom,mdss
+
+ reg:
+ minItems: 2
+ maxItems: 3
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: mdss_phys
+ - const: vbif_phys
+ - const: vbif_nrt_phys
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ power-domains:
+ maxItems: 1
+ description: |
+ The MDSS power domain provided by GCC
+
+ clocks:
+ oneOf:
+ - minItems: 3
+ items:
+ - description: Display abh clock
+ - description: Display axi clock
+ - description: Display vsync clock
+ - description: Display core clock
+ - minItems: 1
+ items:
+ - description: Display abh clock
+ - description: Display core clock
+
+ clock-names:
+ oneOf:
+ - minItems: 3
+ items:
+ - const: iface
+ - const: bus
+ - const: vsync
+ - const: core
+ - minItems: 1
+ items:
+ - const: iface
+ - const: core
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+ resets:
+ items:
+ - description: MDSS_CORE reset
+
+ interconnects:
+ minItems: 1
+ items:
+ - description: Interconnect path from mdp0 (or a single mdp) port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ minItems: 1
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - power-domains
+ - clocks
+ - clock-names
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+patternProperties:
+ "^display-controller@[1-9a-f][0-9a-f]*$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,mdp5
+
+ "^dsi@[1-9a-f][0-9a-f]*$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,mdss-dsi-ctrl
+
+ "^phy@[1-9a-f][0-9a-f]*$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ enum:
+ - qcom,dsi-phy-14nm
+ - qcom,dsi-phy-14nm-660
+ - qcom,dsi-phy-14nm-8953
+ - qcom,dsi-phy-20nm
+ - qcom,dsi-phy-28nm-8226
+ - qcom,dsi-phy-28nm-8937
+ - qcom,dsi-phy-28nm-hpm
+ - qcom,dsi-phy-28nm-hpm-fam-b
+ - qcom,dsi-phy-28nm-lp
+ - qcom,hdmi-phy-8084
+ - qcom,hdmi-phy-8660
+ - qcom,hdmi-phy-8960
+ - qcom,hdmi-phy-8974
+ - qcom,hdmi-phy-8996
+
+ "^hdmi-tx@[1-9a-f][0-9a-f]*$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ enum:
+ - qcom,hdmi-tx-8084
+ - qcom,hdmi-tx-8660
+ - qcom,hdmi-tx-8960
+ - qcom,hdmi-tx-8974
+ - qcom,hdmi-tx-8994
+ - qcom,hdmi-tx-8996
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ display-subsystem@1a00000 {
+ compatible = "qcom,mdss";
+ reg = <0x1a00000 0x1000>,
+ <0x1ac8000 0x3000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = <&gcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync";
+
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@1a01000 {
+ compatible = "qcom,msm8916-mdp5", "qcom,mdp5";
+ reg = <0x01a01000 0x89000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+ <&gcc GCC_MDSS_AXI_CLK>,
+ <&gcc GCC_MDSS_MDP_CLK>,
+ <&gcc GCC_MDSS_VSYNC_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync";
+
+ iommus = <&apps_iommu 4>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdp5_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
new file mode 100644
index 000000000000..d5a64c8a921f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,msm8998-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU on MSM8998
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,msm8998-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for regdma register set
+ - description: Address offset and size for vbif register set
+ - description: Address offset and size for non-realtime vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: regdma
+ - const: vbif
+ - const: vbif_nrt
+
+ clocks:
+ items:
+ - description: Display ahb clock
+ - description: Display axi clock
+ - description: Display mem-noc clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mnoc
+ - const: core
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,mmcc-msm8998.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@c901000 {
+ compatible = "qcom,msm8998-dpu";
+ reg = <0x0c901000 0x8f000>,
+ <0x0c9a8e00 0xf0>,
+ <0x0c9b0000 0x2008>,
+ <0x0c9b8000 0x1040>;
+ reg-names = "mdp", "regdma", "vbif", "vbif_nrt";
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>,
+ <&mmcc MNOC_AHB_CLK>,
+ <&mmcc MDSS_MDP_CLK>,
+ <&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "mnoc", "core", "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd MSM8998_VDDMX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
new file mode 100644
index 000000000000..2d9edab5a30d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml
@@ -0,0 +1,278 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,msm8998-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8998 Display MDSS
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for MSM8998 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,msm8998-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock
+ - description: Display AXI clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,msm8998-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,msm8998-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm-8998
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,mmcc-msm8998.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@c900000 {
+ compatible = "qcom,msm8998-mdss";
+ reg = <0x0c900000 0x1000>;
+ reg-names = "mdss";
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>,
+ <&mmcc MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ #address-cells = <1>;
+ #interrupt-cells = <1>;
+ #size-cells = <1>;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ iommus = <&mmss_smmu 0>;
+
+ power-domains = <&mmcc MDSS_GDSC>;
+ ranges;
+
+ display-controller@c901000 {
+ compatible = "qcom,msm8998-dpu";
+ reg = <0x0c901000 0x8f000>,
+ <0x0c9a8e00 0xf0>,
+ <0x0c9b0000 0x2008>,
+ <0x0c9b8000 0x1040>;
+ reg-names = "mdp", "regdma", "vbif", "vbif_nrt";
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>,
+ <&mmcc MNOC_AHB_CLK>,
+ <&mmcc MDSS_MDP_CLK>,
+ <&mmcc MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "mnoc", "core", "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd MSM8998_VDDMX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+
+ dsi@c994000 {
+ compatible = "qcom,msm8998-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0c994000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&mmcc MDSS_BYTE0_CLK>,
+ <&mmcc MDSS_BYTE0_INTF_CLK>,
+ <&mmcc MDSS_PCLK0_CLK>,
+ <&mmcc MDSS_ESC0_CLK>,
+ <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&mmcc BYTE0_CLK_SRC>, <&mmcc PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd MSM8998_VDDCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi0_phy: phy@c994400 {
+ compatible = "qcom,dsi-phy-10nm-8998";
+ reg = <0x0c994400 0x200>,
+ <0x0c994600 0x280>,
+ <0x0c994a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+
+ vdds-supply = <&pm8998_l1>;
+ };
+
+ dsi@c996000 {
+ compatible = "qcom,msm8998-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0c996000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&mmcc MDSS_BYTE1_CLK>,
+ <&mmcc MDSS_BYTE1_INTF_CLK>,
+ <&mmcc MDSS_PCLK1_CLK>,
+ <&mmcc MDSS_ESC1_CLK>,
+ <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&mmcc BYTE1_CLK_SRC>, <&mmcc PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd MSM8998_VDDCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@c996400 {
+ compatible = "qcom,dsi-phy-10nm-8998";
+ reg = <0x0c996400 0x200>,
+ <0x0c996600 0x280>,
+ <0x0c996a00 0x10e>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&mmcc MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+
+ vdds-supply = <&pm8998_l1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
new file mode 100644
index 000000000000..be6cd8adb3b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU on QCM2290
+
+maintainers:
+ - Loic Poulain <loic.poulain@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qcm2290-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display AXI clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock from dispcc
+ - description: Display lut clock from dispcc
+ - description: Display vsync clock from dispcc
+
+ clock-names:
+ items:
+ - const: bus
+ - const: iface
+ - const: core
+ - const: lut
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-qcm2290.h>
+ #include <dt-bindings/clock/qcom,gcc-qcm2290.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@5e01000 {
+ compatible = "qcom,qcm2290-dpu";
+ reg = <0x05e01000 0x8f000>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "core", "lut", "vsync";
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd QCM2290_VDDCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
new file mode 100644
index 000000000000..f0cdb5422688
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -0,0 +1,215 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCM220 Display MDSS
+
+maintainers:
+ - Loic Poulain <loic.poulain@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
+ are mentioned for QCM2290 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qcm2290-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ iommus:
+ maxItems: 2
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,qcm2290-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,qcm2290-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-14nm-2290
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-qcm2290.h>
+ #include <dt-bindings/clock/qcom,gcc-qcm2290.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,qcm2290.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@5e00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "qcom,qcm2290-mdss";
+ reg = <0x05e00000 0x1000>;
+ reg-names = "mdss";
+ power-domains = <&dispcc MDSS_GDSC>;
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmrt_virt MASTER_MDP0 &bimc SLAVE_EBI1>,
+ <&bimc MASTER_APPSS_PROC &config_noc SLAVE_DISPLAY_CFG>;
+ interconnect-names = "mdp0-mem",
+ "cpu-cfg";
+
+ iommus = <&apps_smmu 0x420 0x2>,
+ <&apps_smmu 0x421 0x0>;
+ ranges;
+
+ display-controller@5e01000 {
+ compatible = "qcom,qcm2290-dpu";
+ reg = <0x05e01000 0x8f000>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "core", "lut", "vsync";
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd QCM2290_VDDCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi@5e94000 {
+ compatible = "qcom,qcm2290-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x05e94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd QCM2290_VDDCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi0_phy: phy@5e94400 {
+ compatible = "qcom,dsi-phy-14nm-2290";
+ reg = <0x05e94400 0x100>,
+ <0x05e94500 0x300>,
+ <0x05e94800 0x188>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+ vcca-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml
new file mode 100644
index 000000000000..e96baaae9ba9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml
@@ -0,0 +1,286 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,qcs8300-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QCS8300 Display MDSS
+
+maintainers:
+ - Yongxing Mou <yongxing.mou@oss.qualcomm.com>
+
+description:
+ QCS8300 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DP interfaces and EDP etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qcs8300-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: qcom,qcs8300-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: qcom,qcs8300-dp
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,qcs8300-edp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,qcs8300-gcc.h>
+ #include <dt-bindings/clock/qcom,sa8775p-dispcc.h>
+ #include <dt-bindings/interconnect/qcom,qcs8300-rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ mdss: display-subsystem@ae00000 {
+ compatible = "qcom,qcs8300-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_MDP1 QCOM_ICC_TAG_ACTIVE_ONLY
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem",
+ "mdp1-mem",
+ "cpu-cfg";
+
+ resets = <&dispcc_core_bcr>;
+ power-domains = <&dispcc_gdsc>;
+
+ clocks = <&dispcc_ahb_clk>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc_mdp_clk>;
+
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x1000 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,qcs8300-dpu", "qcom,sa8775p-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc0 MDSS_DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&mdss_dp0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-575000000 {
+ opp-hz = /bits/ 64 <575000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ };
+
+ opp-650000000 {
+ opp-hz = /bits/ 64 <650000000>;
+ required-opps = <&rpmhpd_opp_turbo_l1>;
+ };
+ };
+ };
+
+ mdss_dp0_phy: phy@aec2a00 {
+ compatible = "qcom,qcs8300-edp-phy", "qcom,sa8775p-edp-phy";
+
+ reg = <0x0aec2a00 0x200>,
+ <0x0aec2200 0xd0>,
+ <0x0aec2600 0xd0>,
+ <0x0aec2000 0x1c8>;
+
+ clocks = <&dispcc MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>,
+ <&dispcc MDSS_DISP_CC_MDSS_AHB_CLK>;
+ clock-names = "aux",
+ "cfg_ahb";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ vdda-phy-supply = <&vreg_l1c>;
+ vdda-pll-supply = <&vreg_l4a>;
+ };
+
+ displayport-controller@af54000 {
+ compatible = "qcom,qcs8300-dp", "qcom,sa8775p-dp";
+
+ pinctrl-0 = <&dp_hot_plug_det>;
+ pinctrl-names = "default";
+
+ reg = <0xaf54000 0x104>,
+ <0xaf54200 0x0c0>,
+ <0xaf55000 0x770>,
+ <0xaf56000 0x09c>,
+ <0xaf57000 0x09c>,
+ <0xaf58000 0x09c>,
+ <0xaf59000 0x09c>,
+ <0xaf5a000 0x23c>,
+ <0xaf5b000 0x23c>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+ clocks = <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL0_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL1_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL2_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL3_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel",
+ "stream_2_pixel",
+ "stream_3_pixel";
+ assigned-clocks = <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL1_CLK_SRC>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL2_CLK_SRC>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL3_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dp0_phy 0>,
+ <&mdss_dp0_phy 1>,
+ <&mdss_dp0_phy 1>,
+ <&mdss_dp0_phy 1>;
+ phys = <&mdss_dp0_phy>;
+ phy-names = "dp";
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp0_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp_out: endpoint { };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml
new file mode 100644
index 000000000000..e2730a2f25cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml
@@ -0,0 +1,464 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sa8775p-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SA87755P Display MDSS
+
+maintainers:
+ - Mahadevan <quic_mahap@quicinc.com>
+
+description:
+ SA8775P MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DP interfaces and EDP etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sa8775p-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sa8775p-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sa8775p-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sa8775p-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-dsi-phy-5nm
+ - qcom,sa8775p-edp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,sa8775p-dispcc.h>
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ #include <dt-bindings/interconnect/qcom,sa8775p-rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sa8775p-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>,
+ <&mmss_noc MASTER_MDP1 &mc_virt SLAVE_EBI1>,
+ <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_DISPLAY_CFG>;
+ interconnect-names = "mdp0-mem",
+ "mdp1-mem",
+ "cpu-cfg";
+
+ resets = <&dispcc_core_bcr>;
+ power-domains = <&dispcc_gdsc>;
+
+ clocks = <&dispcc_ahb_clk>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc_mdp_clk>;
+
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x1000 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sa8775p-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc_ahb_clk>,
+ <&dispcc_mdp_lut_clk>,
+ <&dispcc_mdp_clk>,
+ <&dispcc_mdp_vsync_clk>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_mdp_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdss0_mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss0>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&mdss0_dp0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss0_dsi0_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss0_dsi1_in>;
+ };
+ };
+ };
+
+ mdss0_mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-575000000 {
+ opp-hz = /bits/ 64 <575000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ };
+
+ opp-650000000 {
+ opp-hz = /bits/ 64 <650000000>;
+ required-opps = <&rpmhpd_opp_turbo_l1>;
+ };
+ };
+ };
+
+ mdss0_dp0_phy: phy@aec2a00 {
+ compatible = "qcom,sa8775p-edp-phy";
+
+ reg = <0x0aec2a00 0x200>,
+ <0x0aec2200 0xd0>,
+ <0x0aec2600 0xd0>,
+ <0x0aec2000 0x1c8>;
+
+ clocks = <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>,
+ <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>;
+ clock-names = "aux",
+ "cfg_ahb";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ vdda-phy-supply = <&vreg_l1c>;
+ vdda-pll-supply = <&vreg_l4a>;
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sa8775p-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispc_byte_clk>,
+ <&dispcc_intf_clk>,
+ <&dispcc_pclk>,
+ <&dispcc_esc_clk>,
+ <&dispcc_ahb_clk>,
+ <&gcc_bus_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc_byte_clk>,
+ <&dispcc_pclk>;
+ assigned-clock-parents = <&mdss0_dsi0_phy 0>, <&mdss0_dsi0_phy 1>;
+ phys = <&mdss0_dsi0_phy>;
+
+ operating-points-v2 = <&dsi0_opp_table>;
+ power-domains = <&rpmhpd SA8775P_MMCX>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss0_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss0_dsi0_out: endpoint { };
+ };
+ };
+
+ dsi0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss0_dsi0_phy: phy@ae94400 {
+ compatible = "qcom,sa8775p-dsi-phy-5nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x27c>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_iface_clk>,
+ <&rpmhcc_ref_clk>;
+ clock-names = "iface", "ref";
+
+ vdds-supply = <&vreg_dsi_supply>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sa8775p-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispc_byte_clk>,
+ <&dispcc_intf_clk>,
+ <&dispcc_pclk>,
+ <&dispcc_esc_clk>,
+ <&dispcc_ahb_clk>,
+ <&gcc_bus_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc_byte_clk>,
+ <&dispcc_pclk>;
+ assigned-clock-parents = <&mdss0_dsi1_phy 0>, <&mdss0_dsi1_phy 1>;
+ phys = <&mdss0_dsi1_phy>;
+
+ operating-points-v2 = <&dsi1_opp_table>;
+ power-domains = <&rpmhpd SA8775P_MMCX>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss0_dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss0_dsi1_out: endpoint { };
+ };
+ };
+
+ dsi1_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss0_dsi1_phy: phy@ae96400 {
+ compatible = "qcom,sa8775p-dsi-phy-5nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x27c>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_iface_clk>,
+ <&rpmhcc_ref_clk>;
+ clock-names = "iface", "ref";
+
+ vdds-supply = <&vreg_dsi_supply>;
+ };
+
+ displayport-controller@af54000 {
+ compatible = "qcom,sa8775p-dp";
+
+ pinctrl-0 = <&dp_hot_plug_det>;
+ pinctrl-names = "default";
+
+ reg = <0xaf54000 0x104>,
+ <0xaf54200 0x0c0>,
+ <0xaf55000 0x770>,
+ <0xaf56000 0x09c>,
+ <0xaf57000 0x09c>,
+ <0xaf58000 0x09c>,
+ <0xaf59000 0x09c>,
+ <0xaf5a000 0x23c>,
+ <0xaf5b000 0x23c>;
+
+ interrupt-parent = <&mdss0>;
+ interrupts = <12>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&dispcc_dptx0_aux_clk>,
+ <&dispcc_dptx0_link_clk>,
+ <&dispcc_dptx0_link_intf_clk>,
+ <&dispcc_dptx0_pixel0_clk>,
+ <&dispcc_dptx0_pixel1_clk>,
+ <&dispcc_dptx0_pixel2_clk>,
+ <&dispcc_dptx0_pixel3_clk>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel",
+ "stream_2_pixel",
+ "stream_3_pixel";
+
+ assigned-clocks = <&dispcc_mdss_dptx0_link_clk_src>,
+ <&dispcc_mdss_dptx0_pixel0_clk_src>,
+ <&dispcc_mdss_dptx0_pixel1_clk_src>,
+ <&dispcc_mdss_dptx0_pixel2_clk_src>,
+ <&dispcc_mdss_dptx0_pixel3_clk_src>;
+ assigned-clock-parents = <&mdss0_dp0_phy 0>,
+ <&mdss0_dp0_phy 1>,
+ <&mdss0_dp0_phy 1>,
+ <&mdss0_dp0_phy 1>;
+
+ phys = <&mdss0_dp0_phy>;
+ phy-names = "dp";
+
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd SA8775P_MMCX>;
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss0_dp0_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss0_dp_out: endpoint { };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sar2130p-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sar2130p-mdss.yaml
new file mode 100644
index 000000000000..44c1bb9e4109
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sar2130p-mdss.yaml
@@ -0,0 +1,443 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sar2130p-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SAR2130P Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <lumag@kernel.org>
+
+description:
+ SAR2310P MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sar2130p-mdss
+
+ clocks:
+ items:
+ - description: Display MDSS AHB
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sar2130p-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sar2130p-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sar2130p-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sar2130p-dsi-phy-5nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ #include <dt-bindings/phy/phy-qcom-qmp.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sar2130p-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc_master_mdp &mc_virt_slave_ebi1>,
+ <&gem_noc_master_appss_proc &config_noc_slave_display_cfg>;
+ interconnect-names = "mdp0-mem", "cpu-cfg";
+
+ resets = <&dispcc_disp_cc_mdss_core_bcr>;
+
+ power-domains = <&dispcc_mdss_gdsc>;
+
+ clocks = <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&gcc_gcc_disp_ahb_clk>,
+ <&gcc_gcc_disp_hf_axi_clk>,
+ <&dispcc_disp_cc_mdss_mdp_clk>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x1c00 0x2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sar2130p-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_gcc_disp_ahb_clk>,
+ <&gcc_gcc_disp_hf_axi_clk>,
+ <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&dispcc_disp_cc_mdss_mdp_lut_clk>,
+ <&dispcc_disp_cc_mdss_mdp_clk>,
+ <&dispcc_disp_cc_mdss_vsync_clk>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_disp_cc_mdss_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&mdss_dp0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-514000000 {
+ opp-hz = /bits/ 64 <514000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ displayport-controller@ae90000 {
+ compatible = "qcom,sar2130p-dp",
+ "qcom,sm8350-dp";
+ reg = <0xae90000 0x200>,
+ <0xae90200 0x200>,
+ <0xae90400 0xc00>,
+ <0xae91000 0x400>,
+ <0xae91400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+ clocks = <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&dispcc_disp_cc_mdss_dptx0_aux_clk>,
+ <&dispcc_disp_cc_mdss_dptx0_link_clk>,
+ <&dispcc_disp_cc_mdss_dptx0_link_intf_clk>,
+ <&dispcc_disp_cc_mdss_dptx0_pixel0_clk>,
+ <&dispcc_disp_cc_mdss_dptx0_pixel1_clk>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel";
+
+ assigned-clocks = <&dispcc_disp_cc_mdss_dptx0_link_clk_src>,
+ <&dispcc_disp_cc_mdss_dptx0_pixel0_clk_src>,
+ <&dispcc_disp_cc_mdss_dptx0_pixel1_clk_src>;
+ assigned-clock-parents = <&usb_dp_qmpphy_QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_dp_qmpphy_QMP_USB43DP_DP_VCO_DIV_CLK>,
+ <&usb_dp_qmpphy_QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dp0_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dp0_out: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+ };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-162000000 {
+ opp-hz = /bits/ 64 <162000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sar2130p-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc_disp_cc_mdss_byte0_clk>,
+ <&dispcc_disp_cc_mdss_byte0_intf_clk>,
+ <&dispcc_disp_cc_mdss_pclk0_clk>,
+ <&dispcc_disp_cc_mdss_esc0_clk>,
+ <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&gcc_gcc_disp_hf_axi_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_disp_cc_mdss_byte0_clk_src>,
+ <&dispcc_disp_cc_mdss_pclk0_clk_src>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@ae94400 {
+ compatible = "qcom,sar2130p-dsi-phy-5nm";
+ reg = <0x0ae95000 0x200>,
+ <0x0ae95200 0x280>,
+ <0x0ae95500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&rpmhcc_rpmh_cxo_clk>;
+ clock-names = "iface", "ref";
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sar2130p-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc_disp_cc_mdss_byte1_clk>,
+ <&dispcc_disp_cc_mdss_byte1_intf_clk>,
+ <&dispcc_disp_cc_mdss_pclk1_clk>,
+ <&dispcc_disp_cc_mdss_esc1_clk>,
+ <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&gcc_gcc_disp_hf_axi_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_disp_cc_mdss_byte1_clk_src>,
+ <&dispcc_disp_cc_mdss_pclk1_clk_src>;
+ assigned-clock-parents = <&mdss_dsi1_phy 0>, <&mdss_dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&mdss_dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi1_phy: phy@ae97000 {
+ compatible = "qcom,sar2130p-dsi-phy-5nm";
+ reg = <0x0ae97000 0x200>,
+ <0x0ae97200 0x280>,
+ <0x0ae97500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_disp_cc_mdss_ahb_clk>,
+ <&rpmhcc_rpmh_cxo_clk>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
new file mode 100644
index 000000000000..8137618237ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU on SC7180
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7180-dpu
+ - qcom,sm6125-dpu
+ - qcom,sm6350-dpu
+ - qcom,sm6375-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ minItems: 6
+ items:
+ - description: Display hf axi clock
+ - description: Display ahb clock
+ - description: Display rotator clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+ - description: Display core throttle clock
+
+ clock-names:
+ minItems: 6
+ items:
+ - const: bus
+ - const: iface
+ - const: rot
+ - const: lut
+ - const: core
+ - const: vsync
+ - const: throttle
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6375-dpu
+ - qcom,sm6125-dpu
+
+ then:
+ properties:
+ clocks:
+ minItems: 7
+
+ clock-names:
+ minItems: 7
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc7180.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7180.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc7180-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "rot", "lut", "core",
+ "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SC7180_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ endpoint {
+ remote-endpoint = <&dp_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
new file mode 100644
index 000000000000..7a0555b15ddf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
@@ -0,0 +1,322 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7180 Display MDSS
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SC7180 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc7180-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc7180-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc7180-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sc7180-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc7180.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7180.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sdm845.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "qcom,sc7180-mdss";
+ reg = <0xae00000 0x1000>;
+ reg-names = "mdss";
+ power-domains = <&dispcc MDSS_GDSC>;
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "ahb", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>,
+ <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_DISPLAY_CFG>;
+ interconnect-names = "mdp0-mem",
+ "cpu-cfg";
+
+ iommus = <&apps_smmu 0x800 0x2>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc7180-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "rot", "lut", "core",
+ "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SC7180_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&dp_in>;
+ };
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sc7180-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SC7180_CX>;
+
+ phys = <&dsi_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ displayport-controller@ae90000 {
+ compatible = "qcom,sc7180-dp";
+
+ reg = <0xae90000 0x200>,
+ <0xae90200 0x200>,
+ <0xae90400 0xc00>,
+ <0xae91000 0x400>,
+ <0xae91400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+ clock-names = "core_iface", "core_aux", "ctrl_link",
+ "ctrl_link_iface", "stream_pixel";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <&dp_phy 0>, <&dp_phy 1>;
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd SC7180_CX>;
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ dp_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_out: endpoint { };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
new file mode 100644
index 000000000000..df9ec15ad6c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-dpu.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc7280-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU on SC7280
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sar2130p-dpu
+ - qcom,sc7280-dpu
+ - qcom,sc8280xp-dpu
+ - qcom,sm8350-dpu
+ - qcom,sm8450-dpu
+ - qcom,sm8550-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display ahb clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc7280-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SC7280_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&edp_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
new file mode 100644
index 000000000000..b643d3adf669
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7280-mdss.yaml
@@ -0,0 +1,444 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc7280-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7280 Display MDSS
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SC7280.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc7280-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc7280-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc7280-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sc7280-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^edp@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc7280-edp
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-dsi-phy-7nm
+ - qcom,sc7280-edp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sc7280.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "qcom,sc7280-mdss";
+ reg = <0xae00000 0x1000>;
+ reg-names = "mdss";
+ power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>;
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>,
+ <&gem_noc MASTER_APPSS_PROC &cnoc2 SLAVE_DISPLAY_CFG>;
+ interconnect-names = "mdp0-mem",
+ "cpu-cfg";
+
+ iommus = <&apps_smmu 0x900 0x402>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc7280-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SC7280_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf5_out: endpoint {
+ remote-endpoint = <&edp_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&dp_in>;
+ };
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sc7280-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi_phy 0>, <&mdss_dsi_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SC7280_CX>;
+
+ phys = <&mdss_dsi_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss_dsi_phy: phy@ae94400 {
+ compatible = "qcom,sc7280-dsi-phy-7nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x280>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+
+ vdds-supply = <&vreg_dsi_supply>;
+ };
+
+ edp@aea0000 {
+ compatible = "qcom,sc7280-edp";
+ pinctrl-names = "default";
+ pinctrl-0 = <&edp_hot_plug_det>;
+
+ reg = <0xaea0000 0x200>,
+ <0xaea0200 0x200>,
+ <0xaea0400 0xc00>,
+ <0xaea1000 0x400>,
+ <0xaea1400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <14>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_EDP_AUX_CLK>,
+ <&dispcc DISP_CC_MDSS_EDP_LINK_CLK>,
+ <&dispcc DISP_CC_MDSS_EDP_LINK_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_EDP_PIXEL_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_EDP_LINK_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_EDP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <&mdss_edp_phy 0>, <&mdss_edp_phy 1>;
+
+ phys = <&mdss_edp_phy>;
+ phy-names = "dp";
+
+ operating-points-v2 = <&edp_opp_table>;
+ power-domains = <&rpmhpd SC7280_CX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ edp_in: endpoint {
+ remote-endpoint = <&dpu_intf5_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_edp_out: endpoint { };
+ };
+ };
+
+ edp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ mdss_edp_phy: phy@aec2a00 {
+ compatible = "qcom,sc7280-edp-phy";
+
+ reg = <0xaec2a00 0x19c>,
+ <0xaec2200 0xa0>,
+ <0xaec2600 0xa0>,
+ <0xaec2000 0x1c0>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_EDP_CLKREF_EN>;
+ clock-names = "aux",
+ "cfg_ahb";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+ };
+
+ displayport-controller@ae90000 {
+ compatible = "qcom,sc7280-dp";
+
+ reg = <0xae90000 0x200>,
+ <0xae90200 0x200>,
+ <0xae90400 0xc00>,
+ <0xae91000 0x400>,
+ <0xae91400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <&dp_phy 0>, <&dp_phy 1>;
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd SC7280_CX>;
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_out: endpoint { };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8180x-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8180x-dpu.yaml
new file mode 100644
index 000000000000..a411126708b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8180x-dpu.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc8180x-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8180X Display DPU
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc8180x-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display AHB clock
+ - description: Display HF AXI clock
+ - description: Display core clock
+ - description: Display vsync clock
+ - description: Display rotator clock
+ - description: Display LUT clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+ - const: rot
+ - const: lut
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sc8180x.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sc8180x.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc8180x-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "rot",
+ "lut";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SC8180X_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8180x-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8180x-mdss.yaml
new file mode 100644
index 000000000000..00e82bdbbcc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8180x-mdss.yaml
@@ -0,0 +1,359 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc8180x-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8180X Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SC8180X target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sc8180x-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc8180x-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-dp
+ - qcom,sc8180x-edp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: qcom,sc8180x-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-7nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sc8180x.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sc8180x.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sc8180x-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP_PORT0 &mc_virt SLAVE_EBI_CH0>,
+ <&mmss_noc MASTER_MDP_PORT1 &mc_virt SLAVE_EBI_CH0>,
+ <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_DISPLAY_CFG>;
+ interconnect-names = "mdp0-mem",
+ "mdp1-mem",
+ "cpu-cfg";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x420>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc8180x-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "rot",
+ "lut";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SC8180X_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-171428571 {
+ opp-hz = /bits/ 64 <171428571>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sc8180x-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SC8180X_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sc8180x-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SC8180X_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
new file mode 100644
index 000000000000..af79406e1604
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sc8280xp-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP Mobile Display Subsystem
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem (MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc8280xp-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock from dispcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sc8280xp-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-dp
+ - qcom,sc8280xp-edp
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sc8280xp.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sc8280xp-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc0 MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ resets = <&dispcc0 DISP_CC_MDSS_CORE_BCR>;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_MDP1 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ iommus = <&apps_smmu 0x1000 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sc8280xp-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc0 DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc0 DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc0 DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdss0_mdp_opp_table>;
+ power-domains = <&rpmhpd SC8280XP_MMCX>;
+
+ interrupt-parent = <&mdss0>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp0_in>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp1_in>;
+ };
+ };
+
+ port@5 {
+ reg = <5>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp3_in>;
+ };
+ };
+
+ port@6 {
+ reg = <6>;
+ endpoint {
+ remote-endpoint = <&mdss0_dp2_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
new file mode 100644
index 000000000000..7dc269322b8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
@@ -0,0 +1,292 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sdm670-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM670 Display MDSS
+
+maintainers:
+ - Richard Acayan <mailingradian@gmail.com>
+
+description:
+ SDM670 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sdm670-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: core
+
+ iommus:
+ maxItems: 2
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sdm670-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sdm670-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: qcom,sdm670-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,sdm670-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sdm670-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP_PORT0 0 &mem_noc SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_MDP_PORT1 0 &mem_noc SLAVE_EBI_CH0 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ iommus = <&apps_smmu 0x880 0x8>,
+ <&apps_smmu 0xc80 0x8>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sdm670-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "gcc-bus", "iface", "bus", "core", "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SDM670_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sdm670-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SDM670_CX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sdm670-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SDM670_CX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96a00 0x10e>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
new file mode 100644
index 000000000000..dc11fd421a27
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-dpu.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sdm845-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU on SDM845
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdm670-dpu
+ - qcom,sdm845-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display GCC bus clock
+ - description: Display ahb clock
+ - description: Display axi clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: gcc-bus
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sdm845-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "gcc-bus", "iface", "bus", "core", "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
new file mode 100644
index 000000000000..6e8b69e5ec62
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sdm845-mdss.yaml
@@ -0,0 +1,288 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sdm845-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM845 Display MDSS
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SDM845 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sdm845-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: core
+
+ iommus:
+ maxItems: 2
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sdm845-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sdm845-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sdm845-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "qcom,sdm845-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x880 0x8>,
+ <&apps_smmu 0xc80 0x8>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sdm845-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "gcc-bus", "iface", "bus", "core", "vsync";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ power-domains = <&rpmhpd SDM845_CX>;
+ operating-points-v2 = <&mdp_opp_table>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sdm845-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SDM845_CX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sdm845-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SDM845_CX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96a00 0x10e>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
new file mode 100644
index 000000000000..510eb6c19364
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-dpu.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6115-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU on SM6115
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6115-dpu
+
+ reg:
+ items:
+ - description: MDP register set
+ - description: VBIF register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display AXI
+ - description: Display AHB
+ - description: Display core
+ - description: Display lut
+ - description: Display rotator
+ - description: Display vsync
+
+ clock-names:
+ items:
+ - const: bus
+ - const: iface
+ - const: core
+ - const: lut
+ - const: rot
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm6115-dispcc.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6115.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@5e01000 {
+ compatible = "qcom,sm6115-dpu";
+ reg = <0x05e01000 0x8f000>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "core", "lut", "rot", "vsync";
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd SM6115_VDDCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
new file mode 100644
index 000000000000..309de1953c88
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml
@@ -0,0 +1,203 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6115-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6115 Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
+ are mentioned for SM6115 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6115-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock
+ - description: Display core clock
+
+ iommus:
+ maxItems: 2
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm6115-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qcom,sm6115-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+ - description: Old binding, please don't use
+ deprecated: true
+ const: qcom,dsi-ctrl-6g-qcm2290
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-14nm-2290
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm6115-dispcc.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6115.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@5e00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "qcom,sm6115-mdss";
+ reg = <0x05e00000 0x1000>;
+ reg-names = "mdss";
+ power-domains = <&dispcc MDSS_GDSC>;
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x420 0x2>,
+ <&apps_smmu 0x421 0x0>;
+ ranges;
+
+ display-controller@5e01000 {
+ compatible = "qcom,sm6115-dpu";
+ reg = <0x05e01000 0x8f000>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "core", "lut", "rot", "vsync";
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd SM6115_VDDCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi@5e94000 {
+ compatible = "qcom,sm6115-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x05e94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd SM6115_VDDCX>;
+ phys = <&dsi0_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi0_phy: phy@5e94400 {
+ compatible = "qcom,dsi-phy-14nm-2290";
+ reg = <0x05e94400 0x100>,
+ <0x05e94500 0x300>,
+ <0x05e94800 0x188>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
new file mode 100644
index 000000000000..3deb9dc81c9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6125-mdss.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6125-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6125 Display MDSS
+
+maintainers:
+ - Marijn Suijten <marijn.suijten@somainline.org>
+
+description:
+ SM6125 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6125-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm6125-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6125-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm6125-dsi-phy-14nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm6125.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6125.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@5e00000 {
+ compatible = "qcom,sm6125-mdss";
+ reg = <0x05e00000 0x1000>;
+ reg-names = "mdss";
+
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "ahb",
+ "core";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ iommus = <&apps_smmu 0x400 0x0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@5e01000 {
+ compatible = "qcom,sm6125-dpu";
+ reg = <0x05e01000 0x83208>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&gcc GCC_DISP_THROTTLE_CORE_CLK>;
+ clock-names = "bus",
+ "iface",
+ "rot",
+ "lut",
+ "core",
+ "vsync",
+ "throttle";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd SM6125_VDDCX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi@5e94000 {
+ compatible = "qcom,sm6125-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x05e94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd SM6125_VDDCX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ phy@5e94400 {
+ compatible = "qcom,sm6125-dsi-phy-14nm";
+ reg = <0x05e94400 0x100>,
+ <0x05e94500 0x300>,
+ <0x05e94800 0x188>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface",
+ "ref";
+
+ required-opps = <&rpmpd_opp_nom>;
+ power-domains = <&rpmpd SM6125_VDDMX>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml
new file mode 100644
index 000000000000..b4f437172218
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-dpu.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6150-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6150 Display DPU
+
+maintainers:
+ - Abhinav Kumar <quic_abhinavk@quicinc.com>
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6150-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display ahb clock
+ - description: Display hf axi clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm6150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdss_mdp_clk>,
+ <&dispcc_mdss_vsync_clk>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc_mdss_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf0_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-19200000 {
+ opp-hz = /bits/ 64 <19200000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-25600000 {
+ opp-hz = /bits/ 64 <25600000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml
new file mode 100644
index 000000000000..46e9335f849f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml
@@ -0,0 +1,255 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6150-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6150 Display MDSS
+
+maintainers:
+ - Abhinav Kumar <quic_abhinavk@quicinc.com>
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SM6150 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sm6150-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm6150-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm6150-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6150-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm6150-dsi-phy-14nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,qcs615-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "qcom,sm6150-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem", "cpu-cfg";
+
+ power-domains = <&dispcc_mdss_gdsc>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdss_mdp_clk>;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x0>;
+
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm6150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdss_mdp_clk>,
+ <&dispcc_mdss_vsync_clk>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc_mdss_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpu_intf0_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-192000000 {
+ opp-hz = /bits/ 64 <192000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-256000000 {
+ opp-hz = /bits/ 64 <256000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm6150-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc_mdss_byte0_clk>,
+ <&dispcc_mdss_byte0_intf_clk>,
+ <&dispcc_mdss_pclk0_clk>,
+ <&dispcc_mdss_esc0_clk>,
+ <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_mdss_byte0_clk_src>,
+ <&dispcc_mdss_pclk0_clk_src>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi0_opp_table>;
+
+ phys = <&mdss_dsi0_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-164000000 {
+ opp-hz = /bits/ 64 <164000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@ae94400 {
+ compatible = "qcom,sm6150-dsi-phy-14nm";
+ reg = <0x0ae94400 0x100>,
+ <0x0ae94500 0x300>,
+ <0x0ae94800 0x188>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
new file mode 100644
index 000000000000..bba666bdffe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
@@ -0,0 +1,225 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6350 Display MDSS
+
+maintainers:
+ - Krishna Manikandan <quic_mkrishn@quicinc.com>
+
+description:
+ SM6350 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6350-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AXI clock from gcc
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm6350-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm6350-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6350-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm6350.h>
+ #include <dt-bindings/clock/qcom,gcc-sm6350.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm6350-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm6350-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "iface", "rot", "lut", "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>;
+ assigned-clock-rates = <300000000>,
+ <19200000>,
+ <19200000>,
+ <19200000>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM6350_CX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm6350-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM6350_MX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
new file mode 100644
index 000000000000..e22b4c433fd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
@@ -0,0 +1,218 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm6375-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6375 Display MDSS
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
+ like DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6375-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display AHB clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: ahb
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm6375-dpu
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm6375-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm6375-dsi-phy-7nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/clock/qcom,sm6375-gcc.h>
+ #include <dt-bindings/clock/qcom,sm6375-dispcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@5e00000 {
+ compatible = "qcom,sm6375-mdss";
+ reg = <0x05e00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "ahb", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x820 0x2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@5e01000 {
+ compatible = "qcom,sm6375-dpu";
+ reg = <0x05e01000 0x8e030>,
+ <0x05eb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_ROT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
+ <&gcc GCC_DISP_THROTTLE_CORE_CLK>;
+ clock-names = "bus",
+ "iface",
+ "rot",
+ "lut",
+ "core",
+ "vsync",
+ "throttle";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmpd SM6375_VDDCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+ };
+
+ dsi@5e94000 {
+ compatible = "qcom,sm6375-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x05e94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmpd SM6375_VDDMX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@5e94400 {
+ compatible = "qcom,sm6375-dsi-phy-7nm";
+ reg = <0x05e94400 0x200>,
+ <0x05e94600 0x280>,
+ <0x05e94900 0x264>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
new file mode 100644
index 000000000000..c79b2d442800
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm7150-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM7150 Display Processing Unit (DPU)
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm7150-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display hf axi clock
+ - description: Display ahb clock
+ - description: Display rotator clock
+ - description: Display lut clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: iface
+ - const: rot
+ - const: lut
+ - const: core
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm7150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdss_ahb_clk>,
+ <&dispcc_mdss_rot_clk>,
+ <&dispcc_mdss_mdp_lut_clk>,
+ <&dispcc_mdss_mdp_clk>,
+ <&dispcc_mdss_vsync_clk>;
+ clock-names = "bus",
+ "iface",
+ "rot",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_mdss_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&dp_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-19200000 {
+ opp-hz = /bits/ 64 <19200000>;
+ required-opps = <&rpmhpd_opp_min_svs>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-344000000 {
+ opp-hz = /bits/ 64 <344000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-430000000 {
+ opp-hz = /bits/ 64 <430000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
new file mode 100644
index 000000000000..9b0621d88d50
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
@@ -0,0 +1,464 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm7150-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM7150 Display MDSS
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+
+description:
+ SM7150 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm7150-mdss
+
+ clocks:
+ items:
+ - description: Display ahb clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from mdp1 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm7150-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm7150-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm7150-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,dsi-phy-10nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm7150-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm7150-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc_mdss_gdsc>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&gcc_disp_sf_axi_clk>,
+ <&dispcc_mdss_mdp_clk>;
+ clock-names = "iface",
+ "bus",
+ "nrt_bus",
+ "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP_PORT0 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_MDP_PORT1 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem",
+ "mdp1-mem",
+ "cpu-cfg";
+
+ iommus = <&apps_smmu 0x800 0x440>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm7150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdss_ahb_clk>,
+ <&dispcc_mdss_rot_clk>,
+ <&dispcc_mdss_mdp_lut_clk>,
+ <&dispcc_mdss_mdp_clk>,
+ <&dispcc_mdss_vsync_clk>;
+ clock-names = "bus",
+ "iface",
+ "rot",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_mdss_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&dp_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-19200000 {
+ opp-hz = /bits/ 64 <19200000>;
+ required-opps = <&rpmhpd_opp_min_svs>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-344000000 {
+ opp-hz = /bits/ 64 <344000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-430000000 {
+ opp-hz = /bits/ 64 <430000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm7150-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc_mdss_byte0_clk>,
+ <&dispcc_mdss_byte0_intf_clk>,
+ <&dispcc_mdss_pclk0_clk>,
+ <&dispcc_mdss_esc0_clk>,
+ <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_mdss_byte0_clk_src>,
+ <&dispcc_mdss_pclk0_clk_src>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-180000000 {
+ opp-hz = /bits/ 64 <180000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-275000000 {
+ opp-hz = /bits/ 64 <275000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vdda_mipi_dsi0_pll>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm7150-dsi-ctrl",
+ "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc_mdss_byte1_clk>,
+ <&dispcc_mdss_byte1_intf_clk>,
+ <&dispcc_mdss_pclk1_clk>,
+ <&dispcc_mdss_esc1_clk>,
+ <&dispcc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_mdss_byte1_clk_src>,
+ <&dispcc_mdss_pclk1_clk_src>;
+ assigned-clock-parents = <&mdss_dsi1_phy 0>,
+ <&mdss_dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ phys = <&mdss_dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mdss_dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-10nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96a00 0x1e0>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vdda_mipi_dsi1_pll>;
+ };
+
+ displayport-controller@ae90000 {
+ compatible = "qcom,sm7150-dp",
+ "qcom,sm8350-dp";
+ reg = <0xae90000 0x200>,
+ <0xae90200 0x200>,
+ <0xae90400 0xc00>,
+ <0xae91000 0x400>,
+ <0xae91400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&dispcc_mdss_dp_aux_clk>,
+ <&dispcc_mdss_dp_link_clk>,
+ <&dispcc_mdss_dp_link_intf_clk>,
+ <&dispcc_mdss_dp_pixel_clk>,
+ <&dispcc_mdss_dp_pixel1_clk>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel";
+
+ assigned-clocks = <&dispcc_mdss_dp_link_clk_src>,
+ <&dispcc_mdss_dp_pixel_clk_src>,
+ <&dispcc_mdss_dp_pixel1_clk_src>;
+ assigned-clock-parents = <&dp_phy 0>,
+ <&dp_phy 1>,
+ <&dp_phy 1>;
+
+ operating-points-v2 = <&dp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_out: endpoint {
+ };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
new file mode 100644
index 000000000000..a88d22f30a60
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-dpu.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8150-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150 Display DPU
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8150-dpu
+ - qcom,sm8250-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display ahb clock
+ - description: Display hf axi clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: core
+ - const: vsync
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8150.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
new file mode 100644
index 000000000000..e6dc5494baee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
@@ -0,0 +1,347 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8150-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150 Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SM8150 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sm8150-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8150-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm8150-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8150-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-7nm-8150
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8150.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8150-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP_PORT0 &mc_virt SLAVE_EBI_CH0>,
+ <&mmss_noc MASTER_MDP_PORT1 &mc_virt SLAVE_EBI_CH0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x420>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8150-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-171428571 {
+ opp-hz = /bits/ 64 <171428571>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8150-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-7nm-8150";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8150-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd SM8150_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-7nm-8150";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
new file mode 100644
index 000000000000..51368cda7b2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
@@ -0,0 +1,350 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8250-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8250 Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
+ bindings of MDSS are mentioned for SM8250 target.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8250-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ maxItems: 2
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8250-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8250-dp
+ - const: qcom,sm8350-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8250-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,dsi-phy-7nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8250-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP_PORT0 &mc_virt SLAVE_EBI_CH0>,
+ <&mmss_noc MASTER_MDP_PORT1 &mc_virt SLAVE_EBI_CH0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x820 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8250-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8250-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8250-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,dsi-phy-7nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
new file mode 100644
index 000000000000..68176de854b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8350-mdss.yaml
@@ -0,0 +1,244 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8350-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 Display MDSS
+
+maintainers:
+ - Robert Foss <robert.foss@linaro.org>
+
+description:
+ MSM Mobile Display Subsystem(MDSS) that encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: qcom,sm8350-mdss
+
+ clocks:
+ items:
+ - description: Display AHB clock from gcc
+ - description: Display hf axi clock
+ - description: Display sf axi clock
+ - description: Display core clock
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: nrt_bus
+ - const: core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from the MDP0 port to the data bus
+ - description: Interconnect path from the MDP1 port to the data bus
+ - description: Interconnect path from the CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: mdp1-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8350-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8350-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8350-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8350-dsi-phy-5nm
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,dispcc-sm8350.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8350.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8350.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8350-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_MDP1 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem", "mdp1-mem", "cpu-cfg";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ iommus = <&apps_smmu 0x820 0x402>;
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8350-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-345000000 {
+ opp-hz = /bits/ 64 <345000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-460000000 {
+ opp-hz = /bits/ 64 <460000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi0: dsi@ae94000 {
+ compatible = "qcom,sm8350-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&mdss_dsi0_phy 0>,
+ <&mdss_dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&mdss_dsi0_phy>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
new file mode 100644
index 000000000000..747a2e9665f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml
@@ -0,0 +1,364 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8450-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8450 Display MDSS
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ SM8450 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8450-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display sf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8450-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8450-dp
+ - const: qcom,sm8350-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8450-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8450-dsi-phy-5nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8450-dispcc.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8450.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8450-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP_DISP &mc_virt SLAVE_EBI1_DISP>,
+ <&mmss_noc MASTER_MDP_DISP &mc_virt SLAVE_EBI1_DISP>,
+ <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_DISPLAY_CFG>;
+ interconnect-names = "mdp0-mem",
+ "mdp1-mem",
+ "cpu-cfg";
+
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x2800 0x402>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8450-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-172000000{
+ opp-hz = /bits/ 64 <172000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8450-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160310000{
+ opp-hz = /bits/ 64 <160310000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,sm8450-dsi-phy-5nm";
+ reg = <0x0ae94400 0x200>,
+ <0x0ae94600 0x280>,
+ <0x0ae94900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8450-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,sm8450-dsi-phy-5nm";
+ reg = <0x0ae96400 0x200>,
+ <0x0ae96600 0x280>,
+ <0x0ae96900 0x260>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ vdds-supply = <&vreg_dsi_phy>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml
new file mode 100644
index 000000000000..59192c59ddb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml
@@ -0,0 +1,353 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 Display MDSS
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ SM8550 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8550-mdss
+
+ clocks:
+ items:
+ - description: Display MDSS AHB
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8550-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8550-dp
+ - const: qcom,sm8350-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8550-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sm8550-dsi-phy-4nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-dispcc.h>
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8550-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_DISPLAY_CFG 0>;
+ interconnect-names = "mdp0-mem", "cpu-cfg";
+
+ resets = <&dispcc DISP_CC_MDSS_CORE_BCR>;
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x1c00 0x2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8550-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus",
+ "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-514000000 {
+ opp-hz = /bits/ 64 <514000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8550-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC0_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,sm8550-dsi-phy-4nm";
+ reg = <0x0ae95000 0x200>,
+ <0x0ae95200 0x280>,
+ <0x0ae95500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8550-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>,
+ <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK>,
+ <&dispcc DISP_CC_MDSS_ESC1_CLK>,
+ <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&gcc GCC_DISP_HF_AXI_CLK>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
+ <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,sm8550-dsi-phy-4nm";
+ reg = <0x0ae97000 0x200>,
+ <0x0ae97200 0x280>,
+ <0x0ae97500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml
new file mode 100644
index 000000000000..fe296e3186d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8650-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8650 Display DPU
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+$ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,glymur-dpu
+ - qcom,sa8775p-dpu
+ - qcom,sm8650-dpu
+ - qcom,sm8750-dpu
+ - qcom,x1e80100-dpu
+ - items:
+ - enum:
+ - qcom,qcs8300-dpu
+ - const: qcom,sa8775p-dpu
+
+ reg:
+ items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for vbif register set
+
+ reg-names:
+ items:
+ - const: mdp
+ - const: vbif
+
+ clocks:
+ items:
+ - description: Display hf axi
+ - description: Display MDSS ahb
+ - description: Display lut
+ - description: Display core
+ - description: Display vsync
+
+ clock-names:
+ items:
+ - const: nrt_bus
+ - const: iface
+ - const: lut
+ - const: core
+ - const: vsync
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8650-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_axi_clk>,
+ <&dispcc_ahb_clk>,
+ <&dispcc_mdp_lut_clk>,
+ <&dispcc_mdp_clk>,
+ <&dispcc_vsync_clk>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-514000000 {
+ opp-hz = /bits/ 64 <514000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml
new file mode 100644
index 000000000000..a1c53e191033
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml
@@ -0,0 +1,341 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8650-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8650 Display MDSS
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ SM8650 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8650-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm8650-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm8650-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8650-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm8650-dsi-phy-4nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+ #include <dt-bindings/interconnect/qcom,sm8650-rpmh.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8650-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_DISPLAY_CFG 0>;
+ interconnect-names = "mdp0-mem", "cpu-cfg";
+
+ resets = <&dispcc_core_bcr>;
+
+ power-domains = <&dispcc_gdsc>;
+
+ clocks = <&gcc_ahb_clk>,
+ <&gcc_axi_clk>,
+ <&dispcc_mdp_clk>;
+ clock-names = "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x1c00 0x2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8650-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_axi_clk>,
+ <&dispcc_ahb_clk>,
+ <&dispcc_mdp_lut_clk>,
+ <&dispcc_mdp_clk>,
+ <&dispcc_mdp_vsync_clk>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_mdp_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-514000000 {
+ opp-hz = /bits/ 64 <514000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8650-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4>;
+
+ clocks = <&dispc_byte_clk>,
+ <&dispcc_intf_clk>,
+ <&dispcc_pclk>,
+ <&dispcc_esc_clk>,
+ <&dispcc_ahb_clk>,
+ <&gcc_bus_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_byte_clk>,
+ <&dispcc_pclk>;
+ assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi0_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ };
+ };
+ };
+
+ dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ dsi0_phy: phy@ae94400 {
+ compatible = "qcom,sm8650-dsi-phy-4nm";
+ reg = <0x0ae95000 0x200>,
+ <0x0ae95200 0x280>,
+ <0x0ae95500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_iface_clk>,
+ <&rpmhcc_ref_clk>;
+ clock-names = "iface", "ref";
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8650-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <5>;
+
+ clocks = <&dispc_byte_clk>,
+ <&dispcc_intf_clk>,
+ <&dispcc_pclk>,
+ <&dispcc_esc_clk>,
+ <&dispcc_ahb_clk>,
+ <&gcc_bus_clk>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus";
+
+ assigned-clocks = <&dispcc_byte_clk>,
+ <&dispcc_pclk>;
+ assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>;
+
+ operating-points-v2 = <&dsi_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ dsi1_phy: phy@ae96400 {
+ compatible = "qcom,sm8650-dsi-phy-4nm";
+ reg = <0x0ae97000 0x200>,
+ <0x0ae97200 0x280>,
+ <0x0ae97500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ clocks = <&dispcc_iface_clk>,
+ <&rpmhcc_ref_clk>;
+ clock-names = "iface", "ref";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
new file mode 100644
index 000000000000..d55fda9a523e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8750-mdss.yaml
@@ -0,0 +1,474 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,sm8750-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8750 Display MDSS
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ SM8650 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DSI and DP interfaces etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8750-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ items:
+ - description: Interconnect path from mdp0 port to the data bus
+ - description: Interconnect path from CPU to the reg bus
+
+ interconnect-names:
+ items:
+ - const: mdp0-mem
+ - const: cpu-cfg
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm8750-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm8750-dp
+
+ "^dsi@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm8750-dsi-ctrl
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,sm8750-dsi-phy-3nm
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8750-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy-qcom-qmp.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,sm8750-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&disp_cc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&disp_cc_mdss_mdp_clk>;
+
+ interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "mdp0-mem",
+ "cpu-cfg";
+
+ resets = <&disp_cc_mdss_core_bcr>;
+
+ power-domains = <&mdss_gdsc>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,sm8750-dpu";
+ reg = <0x0ae01000 0x93000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp",
+ "vbif";
+
+ interrupts-extended = <&mdss 0>;
+
+ clocks = <&gcc_disp_hf_axi_clk>,
+ <&disp_cc_mdss_ahb_clk>,
+ <&disp_cc_mdss_mdp_lut_clk>,
+ <&disp_cc_mdss_mdp_clk>,
+ <&disp_cc_mdss_vsync_clk>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&disp_cc_mdss_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&mdss_dsi1_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dpu_intf0_out: endpoint {
+ remote-endpoint = <&mdss_dp0_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-207000000 {
+ opp-hz = /bits/ 64 <207000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-337000000 {
+ opp-hz = /bits/ 64 <337000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-417000000 {
+ opp-hz = /bits/ 64 <417000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-532000000 {
+ opp-hz = /bits/ 64 <532000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+
+ opp-575000000 {
+ opp-hz = /bits/ 64 <575000000>;
+ required-opps = <&rpmhpd_opp_nom_l1>;
+ };
+ };
+ };
+
+ dsi@ae94000 {
+ compatible = "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupts-extended = <&mdss 4>;
+
+ clocks = <&disp_cc_mdss_byte0_clk>,
+ <&disp_cc_mdss_byte0_intf_clk>,
+ <&disp_cc_mdss_pclk0_clk>,
+ <&disp_cc_mdss_esc0_clk>,
+ <&disp_cc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&mdss_dsi0_phy 1>,
+ <&mdss_dsi0_phy 0>,
+ <&disp_cc_esync0_clk>,
+ <&disp_cc_osc_clk>,
+ <&disp_cc_mdss_byte0_clk_src>,
+ <&disp_cc_mdss_pclk0_clk_src>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus",
+ "dsi_pll_pixel",
+ "dsi_pll_byte",
+ "esync",
+ "osc",
+ "byte_src",
+ "pixel_src";
+
+ operating-points-v2 = <&mdss_dsi_opp_table>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&mdss_dsi0_phy>;
+ phy-names = "dsi";
+
+ vdda-supply = <&vreg_l3g_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi0_in: endpoint {
+ remote-endpoint = <&dpu_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi0_out: endpoint {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ mdss_dsi_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-187500000 {
+ opp-hz = /bits/ 64 <187500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-358000000 {
+ opp-hz = /bits/ 64 <358000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+ };
+ };
+
+ mdss_dsi0_phy: phy@ae95000 {
+ compatible = "qcom,sm8750-dsi-phy-3nm";
+ reg = <0x0ae95000 0x200>,
+ <0x0ae95200 0x280>,
+ <0x0ae95500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ clocks = <&disp_cc_mdss_ahb_clk>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface",
+ "ref";
+
+ vdds-supply = <&vreg_l3i_0p88>;
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+ };
+
+ dsi@ae96000 {
+ compatible = "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl";
+ reg = <0x0ae96000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupts-extended = <&mdss 5>;
+
+ clocks = <&disp_cc_mdss_byte1_clk>,
+ <&disp_cc_mdss_byte1_intf_clk>,
+ <&disp_cc_mdss_pclk1_clk>,
+ <&disp_cc_mdss_esc1_clk>,
+ <&disp_cc_mdss_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&mdss_dsi1_phy 1>,
+ <&mdss_dsi1_phy 0>,
+ <&disp_cc_esync1_clk>,
+ <&disp_cc_osc_clk>,
+ <&disp_cc_mdss_byte1_clk_src>,
+ <&disp_cc_mdss_pclk1_clk_src>;
+ clock-names = "byte",
+ "byte_intf",
+ "pixel",
+ "core",
+ "iface",
+ "bus",
+ "dsi_pll_pixel",
+ "dsi_pll_byte",
+ "esync",
+ "osc",
+ "byte_src",
+ "pixel_src";
+
+ operating-points-v2 = <&mdss_dsi_opp_table>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&mdss_dsi1_phy>;
+ phy-names = "dsi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dsi1_in: endpoint {
+ remote-endpoint = <&dpu_intf2_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dsi1_out: endpoint {
+ };
+ };
+ };
+ };
+
+ mdss_dsi1_phy: phy@ae97000 {
+ compatible = "qcom,sm8750-dsi-phy-3nm";
+ reg = <0x0ae97000 0x200>,
+ <0x0ae97200 0x280>,
+ <0x0ae97500 0x400>;
+ reg-names = "dsi_phy",
+ "dsi_phy_lane",
+ "dsi_pll";
+
+ clocks = <&disp_cc_mdss_ahb_clk>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface",
+ "ref";
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+ };
+
+ displayport-controller@af54000 {
+ compatible = "qcom,sm8750-dp", "qcom,sm8650-dp";
+ reg = <0xaf54000 0x104>,
+ <0xaf54200 0xc0>,
+ <0xaf55000 0x770>,
+ <0xaf56000 0x9c>,
+ <0xaf57000 0x9c>;
+
+ interrupts-extended = <&mdss 12>;
+
+ clocks = <&disp_cc_mdss_ahb_clk>,
+ <&disp_cc_mdss_dptx0_aux_clk>,
+ <&disp_cc_mdss_dptx0_link_clk>,
+ <&disp_cc_mdss_dptx0_link_intf_clk>,
+ <&disp_cc_mdss_dptx0_pixel0_clk>,
+ <&disp_cc_mdss_dptx0_pixel1_clk>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel";
+
+ assigned-clocks = <&disp_cc_mdss_dptx0_link_clk_src>,
+ <&disp_cc_mdss_dptx0_pixel0_clk_src>,
+ <&disp_cc_mdss_dptx0_pixel1_clk_src>;
+ assigned-clock-parents = <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+ <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ operating-points-v2 = <&dp_opp_table>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-192000000 {
+ opp-hz = /bits/ 64 <192000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp0_in: endpoint {
+ remote-endpoint = <&dpu_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp0_out: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_dp_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
new file mode 100644
index 000000000000..8d698a2e055a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
@@ -0,0 +1,255 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,x1e80100-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 Display MDSS
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ X1E80100 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like
+ DPU display controller, DP interfaces, etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,x1e80100-mdss
+
+ clocks:
+ items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,x1e80100-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,x1e80100-dp
+
+ "^phy@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: qcom,x1e80100-dp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h>
+ #include <dt-bindings/phy/phy-qcom-qmp.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ display-subsystem@ae00000 {
+ compatible = "qcom,x1e80100-mdss";
+ reg = <0x0ae00000 0x1000>;
+ reg-names = "mdss";
+
+ interconnects = <&mmss_noc MASTER_MDP 0 &gem_noc SLAVE_LLCC 0>,
+ <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_DISPLAY_CFG 0>;
+ interconnect-names = "mdp0-mem", "mdp1-mem", "cpu-cfg";
+
+ resets = <&dispcc_core_bcr>;
+
+ power-domains = <&dispcc_gdsc>;
+
+ clocks = <&dispcc_ahb_clk>,
+ <&gcc_disp_hf_axi_clk>,
+ <&dispcc_mdp_clk>;
+ clock-names = "bus", "nrt_bus", "core";
+
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x1c00 0x2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ display-controller@ae01000 {
+ compatible = "qcom,x1e80100-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb0000 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc_axi_clk>,
+ <&dispcc_ahb_clk>,
+ <&dispcc_mdp_lut_clk>,
+ <&dispcc_mdp_clk>,
+ <&dispcc_mdp_vsync_clk>;
+ clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+ assigned-clocks = <&dispcc_mdp_vsync_clk>;
+ assigned-clock-rates = <19200000>;
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-325000000 {
+ opp-hz = /bits/ 64 <325000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-375000000 {
+ opp-hz = /bits/ 64 <375000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-514000000 {
+ opp-hz = /bits/ 64 <514000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
+ displayport-controller@ae90000 {
+ compatible = "qcom,x1e80100-dp";
+ reg = <0xae90000 0x200>,
+ <0xae90200 0x200>,
+ <0xae90400 0x600>,
+ <0xae91000 0x400>,
+ <0xae91400 0x400>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <12>;
+
+ clocks = <&dispcc_mdss_ahb_clk>,
+ <&dispcc_dptx0_aux_clk>,
+ <&dispcc_dptx0_link_clk>,
+ <&dispcc_dptx0_link_intf_clk>,
+ <&dispcc_dptx0_pixel0_clk>,
+ <&dispcc_dptx0_pixel1_clk>;
+ clock-names = "core_iface", "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel",
+ "stream_1_pixel";
+
+ assigned-clocks = <&dispcc_mdss_dptx0_link_clk_src>,
+ <&dispcc_mdss_dptx0_pixel0_clk_src>,
+ <&dispcc_mdss_dptx0_pixel1_clk_src>;
+ assigned-clock-parents = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
+ <&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ operating-points-v2 = <&mdss_dp0_opp_table>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+
+ phys = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_dp0_in: endpoint {
+ remote-endpoint = <&mdss_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp0_out: endpoint {
+ };
+ };
+ };
+
+ mdss_dp0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-270000000 {
+ opp-hz = /bits/ 64 <270000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-540000000 {
+ opp-hz = /bits/ 64 <540000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-810000000 {
+ opp-hz = /bits/ 64 <810000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
index acd2f3faa6b9..0aa2d3fbadaa 100644
--- a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
+++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
@@ -17,10 +17,12 @@ properties:
compatible:
const: abt,y030xx067a
+ reg:
+ maxItems: 1
+
backlight: true
port: true
power-supply: true
- reg: true
reset-gpios: true
required:
diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
index 3a8c2c11f9bd..f6fea9085aab 100644
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
@@ -12,7 +12,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- - $ref: /schemas/display/lvds.yaml/#
+ - $ref: /schemas/display/lvds.yaml#
select:
properties:
diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
index 67682fe77f10..05ca3b2385f8 100644
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -19,6 +19,10 @@ description: |
second port, therefore the ports must be marked accordingly (with either
dual-lvds-odd-pixels or dual-lvds-even-pixels).
+allOf:
+ - $ref: /schemas/display/lvds-dual-ports.yaml#
+ - $ref: panel-common.yaml#
+
properties:
compatible:
items:
@@ -41,22 +45,10 @@ properties:
properties:
port@0:
- $ref: /schemas/graph.yaml#/$defs/port-base
- unevaluatedProperties: false
- description: The sink for odd pixels.
- properties:
- dual-lvds-odd-pixels: true
-
required:
- dual-lvds-odd-pixels
port@1:
- $ref: /schemas/graph.yaml#/$defs/port-base
- unevaluatedProperties: false
- description: The sink for even pixels.
- properties:
- dual-lvds-even-pixels: true
-
required:
- dual-lvds-even-pixels
@@ -72,7 +64,6 @@ required:
- height-mm
- data-mapping
- panel-timing
- - ports
examples:
- |+
diff --git a/Documentation/devicetree/bindings/display/panel/anbernic,rg35xx-plus-panel.yaml b/Documentation/devicetree/bindings/display/panel/anbernic,rg35xx-plus-panel.yaml
new file mode 100644
index 000000000000..1d67492ebd3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/anbernic,rg35xx-plus-panel.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/anbernic,rg35xx-plus-panel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Anbernic RG35XX series (WL-355608-A8) 3.5" 640x480 24-bit IPS LCD panel
+
+maintainers:
+ - Ryan Walklin <ryan@testtoast.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: anbernic,rg35xx-plus-panel
+ - items:
+ - enum:
+ - anbernic,rg35xx-2024-panel
+ - anbernic,rg35xx-h-panel
+ - anbernic,rg35xx-sp-panel
+ - const: anbernic,rg35xx-plus-panel
+
+ reg:
+ maxItems: 1
+
+ spi-3wire: true
+
+required:
+ - compatible
+ - reg
+ - port
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "anbernic,rg35xx-plus-panel";
+ reg = <0>;
+
+ spi-3wire;
+ spi-max-frequency = <3125000>;
+
+ reset-gpios = <&pio 8 14 GPIO_ACTIVE_LOW>; // PI14
+
+ backlight = <&backlight>;
+ power-supply = <&reg_lcd>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&tcon_lcd0_out_lcd>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/apple,summit.yaml b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
new file mode 100644
index 000000000000..f081755325e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/apple,summit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple "Summit" display panel
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+description:
+ An OLED panel used as a touchbar on certain Apple laptops.
+ Contains a backlight device, which controls brightness of the panel itself.
+ The backlight common properties are included for this reason
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/leds/backlight/common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,j293-summit
+ - apple,j493-summit
+ - const: apple,summit
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - max-brightness
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "apple,j293-summit", "apple,summit";
+ reg = <0>;
+ max-brightness = <255>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&dfr_bridge_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
index be69e0cc50fc..c9958f824d9a 100644
--- a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
+++ b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.yaml
@@ -37,9 +37,6 @@ examples:
compatible = "arm,versatile-sysreg", "syscon", "simple-mfd";
reg = <0x00000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
-
panel {
compatible = "arm,versatile-tft-panel";
diff --git a/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml b/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml
index 75a09df68ba0..dd614e077bbf 100644
--- a/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml
+++ b/Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
maintainers:
- - Konrad Dybcio <konradybcio@gmail.com>
+ - Konrad Dybcio <konradybcio@kernel.org>
description: |+
This panel seems to only be found in the Asus Z00T
@@ -21,7 +21,10 @@ allOf:
properties:
compatible:
const: asus,z00t-tm5p5-n35596
- reg: true
+
+ reg:
+ maxItems: 1
+
reset-gpios: true
vdd-supply:
description: core voltage supply
diff --git a/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml b/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
new file mode 100644
index 000000000000..86c834eb4d98
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,a030jtn01.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,a030jtn01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO A030JTN01 3.0" (320x480 pixels) 24-bit TFT LCD panel
+
+description: |
+ Delta RGB 8-bit panel found in some Retrogame handhelds
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+ - Christophe Branchereau <cbranchereau@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: auo,a030jtn01
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "auo,a030jtn01";
+ reg = <0>;
+
+ spi-max-frequency = <10000000>;
+
+ reset-gpios = <&gpe 4 GPIO_ACTIVE_LOW>;
+ power-supply = <&lcd_power>;
+
+ backlight = <&backlight>;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&panel_output>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml b/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
index a8f3afa922c8..8b7448ad9138 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
@@ -26,6 +26,9 @@ properties:
compatible:
const: boe,bf060y8m-aj0
+ reg:
+ maxItems: 1
+
elvdd-supply:
description: EL Driving positive (VDD) supply (4.40-4.80V)
elvss-supply:
@@ -38,7 +41,6 @@ properties:
description: I/O voltage supply (1.62-1.98V)
port: true
- reg: true
reset-gpios: true
required:
diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
index 272a3a018a33..f2496cdd9260 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
@@ -18,9 +18,11 @@ properties:
- const: boe,himax8279d8p
- const: boe,himax8279d10p
+ reg:
+ maxItems: 1
+
backlight: true
enable-gpios: true
- reg: true
pp33-gpios:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/panel/boe,td4320.yaml b/Documentation/devicetree/bindings/display/panel/boe,td4320.yaml
new file mode 100644
index 000000000000..c6bff0ece360
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,td4320.yaml
@@ -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/boe,td4320.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TD4320 MIPI-DSI panels
+
+maintainers:
+ - Barnabas Czeman <barnabas.czeman@mainlining.org>
+
+description:
+ BOE TD4320 6.3" 1080x2340 panel found in Xiaomi Redmi Note 7 smartphone.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: boe,td4320
+
+ reg:
+ maxItems: 1
+
+ iovcc-supply:
+ description: I/O voltage rail
+
+ vsn-supply:
+ description: Negative source voltage rail
+
+ vsp-supply:
+ description: Positive source voltage rail
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "boe,td4320";
+ reg = <0>;
+ backlight = <&backlight>;
+ reset-gpios = <&tlmm 45 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
new file mode 100644
index 000000000000..6a82bd1ec763
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
@@ -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/boe,th101mb31ig002-28a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TH101MB31IG002-28A WXGA DSI Display Panel
+
+maintainers:
+ - Manuel Traut <manut@mecka.net>
+
+properties:
+ compatible:
+ enum:
+ # BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
+ - boe,th101mb31ig002-28a
+ # The Starry-er88577 is a 10.1" WXGA TFT-LCD panel
+ - starry,er88577
+
+ reg:
+ maxItems: 1
+
+ backlight: true
+ enable-gpios: true
+ reset-gpios: true
+ power-supply: true
+ port: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - power-supply
+
+allOf:
+ - $ref: panel-common.yaml#
+ - if:
+ properties:
+ compatible:
+ # The Starry-er88577 is a 10.1" WXGA TFT-LCD panel
+ const: starry,er88577
+ then:
+ properties:
+ reset-gpios: false
+ else:
+ required:
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "boe,th101mb31ig002-28a";
+ reg = <0>;
+ backlight = <&backlight_lcd0>;
+ enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 55 GPIO_ACTIVE_LOW>;
+ rotation = <90>;
+ power-supply = <&vcc_3v3>;
+ port {
+ panel_in_dsi: endpoint {
+ remote-endpoint = <&dsi_out_con>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-ll2.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-ll2.yaml
new file mode 100644
index 000000000000..dced98e1c69a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-ll2.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-ll2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-LL2 DSI Display Panel
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: boe,tv101wum-ll2
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ backlight: true
+ reset-gpios: true
+ vsp-supply: true
+ vsn-supply: true
+ port: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vsp-supply
+ - vsn-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "boe,tv101wum-ll2";
+ reg = <0>;
+
+ vsn-supply = <&vsn_lcd>;
+ vsp-supply = <&vsp_lcd>;
+
+ reset-gpios = <&pio 45 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
index a2384bd74cf2..7a9f49e40e75 100644
--- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -30,9 +30,13 @@ properties:
- boe,tv110c9m-ll3
# INX HJ110IZ-01A 10.95" WUXGA TFT LCD panel
- innolux,hj110iz-01a
+ # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
+ - starry,2081101qfh032011-53g
+ # STARRY ili9882t 10.51" WUXGA TFT LCD panel
+ - starry,ili9882t
reg:
- description: the virtual channel number of a DSI peripheral
+ maxItems: 1
enable-gpios:
description: a GPIO spec for the enable pin
@@ -53,6 +57,7 @@ properties:
description: phandle of the backlight device attached to the panel
port: true
+ rotation: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/panel/display-timings.yaml b/Documentation/devicetree/bindings/display/panel/display-timings.yaml
index 6d30575819d3..dc5f7e36e30b 100644
--- a/Documentation/devicetree/bindings/display/panel/display-timings.yaml
+++ b/Documentation/devicetree/bindings/display/panel/display-timings.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/panel/display-timings.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: display timings bindings
+title: display timings
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
diff --git a/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml b/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml
index 7adb83e2e8d9..f4cb825d1e96 100644
--- a/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml
+++ b/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml
@@ -15,9 +15,14 @@ allOf:
properties:
compatible:
const: elida,kd35t133
- reg: true
+
+ reg:
+ maxItems: 1
+
backlight: true
+ port: true
reset-gpios: true
+ rotation: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
vdd-supply:
@@ -27,6 +32,7 @@ required:
- compatible
- reg
- backlight
+ - port
- iovcc-supply
- vdd-supply
@@ -43,6 +49,12 @@ examples:
backlight = <&backlight>;
iovcc-supply = <&vcc_1v8>;
vdd-supply = <&vcc3v3_lcd>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml b/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml
new file mode 100644
index 000000000000..9847da784cc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/fascontek,fs035vg158.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fascontek FS035VG158 3.5" (640x480 pixels) 24-bit IPS LCD panel
+
+maintainers:
+ - John Watts <contact@jookia.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: fascontek,fs035vg158
+
+ reg:
+ maxItems: 1
+
+ spi-3wire: true
+
+required:
+ - compatible
+ - reg
+ - port
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "fascontek,fs035vg158";
+ reg = <0>;
+
+ spi-3wire;
+ spi-max-frequency = <3125000>;
+
+ reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+ backlight = <&backlight>;
+ power-supply = <&vcc>;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&panel_output>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
index 81adb82f061d..0d8707a5844d 100644
--- a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -15,7 +15,10 @@ allOf:
properties:
compatible:
const: feixin,k101-im2ba02
- reg: true
+
+ reg:
+ maxItems: 1
+
backlight: true
reset-gpios: true
avdd-supply:
diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
index 1cf84c8dd85e..92df69e80a82 100644
--- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
+++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
@@ -26,6 +26,7 @@ properties:
dvdd-supply:
description: 3v3 digital regulator
+ port: true
reset-gpios: true
backlight: true
@@ -35,6 +36,7 @@ required:
- reg
- avdd-supply
- dvdd-supply
+ - port
additionalProperties: false
@@ -53,5 +55,11 @@ examples:
dvdd-supply = <&reg_dldo2>;
reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
backlight = <&backlight>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
new file mode 100644
index 000000000000..d54e96b2a9e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/focaltech,gpt3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Focaltech GPT3 3.0" (640x480 pixels) IPS LCD panel
+
+maintainers:
+ - Christophe Branchereau <cbranchereau@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: focaltech,gpt3
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "focaltech,gpt3";
+ reg = <0>;
+
+ spi-max-frequency = <3125000>;
+
+ reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+ backlight = <&backlight>;
+ power-supply = <&vcc>;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&panel_output>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8279.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8279.yaml
new file mode 100644
index 000000000000..f619aea82bdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx8279.yaml
@@ -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/himax,hx8279.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX8279/HX8279-D based MIPI-DSI panels
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The Himax HX8279 is a 1803 channel outputs source driver with MIPI
+ TCON, which generates the horizontal and vertical control timing to
+ the source and gate drivers.
+ This DriverIC is most suitable for 1200x1920, 1080x1920, 1200x1600,
+ and 600x1024 panels and outputs full RGB888 over two or four lanes,
+ single or dual, MIPI-DSI video interface.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - aoly,sl101pm1794fog-v15
+ - startek,kd070fhfid078
+ - const: himax,hx8279
+
+ reg:
+ maxItems: 1
+
+ iovcc-supply:
+ description: I/O voltage supply
+
+ vdd-supply:
+ description: Panel power supply
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - reset-gpios
+ - iovcc-supply
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "startek,kd070fhfid078", "himax,hx8279";
+ reg = <0>;
+ backlight = <&backlight>;
+ enable-gpios = <&pio 25 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+ iovcc-supply = <&vreg_lcm_vio>;
+ vdd-supply = <&vreg_lcm_vdd>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
new file mode 100644
index 000000000000..e4c1aa5deab9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83102.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83102 MIPI-DSI LCD panel controller
+
+maintainers:
+ - Cong Yang <yangcong5@huaqin.corp-partner.google.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel
+ - boe,nv110wum-l60
+ # CSOT pna957qt1-1 10.95" WUXGA TFT LCD panel
+ - csot,pna957qt1-1
+ # IVO t109nw41 11.0" WUXGA TFT LCD panel
+ - ivo,t109nw41
+ # KINGDISPLAY KD110N11-51IE 10.95" WUXGA TFT LCD panel
+ - kingdisplay,kd110n11-51ie
+ # STARRY 2082109QFH040022-50E 10.95" WUXGA TFT LCD panel
+ - starry,2082109qfh040022-50e
+ # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel
+ - starry,himax83102-j02
+ - const: himax,hx83102
+
+ reg:
+ description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+ description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+ description: core voltage supply
+
+ avdd-supply:
+ description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+ description: phandle of the regulator that provides negative voltage
+
+ backlight: true
+ port: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "starry,himax83102-j02", "himax,hx83102";
+ reg = <0>;
+ enable-gpios = <&pio 45 0>;
+ avdd-supply = <&ppvarn_lcd>;
+ avee-supply = <&ppvarp_lcd>;
+ pp1800-supply = <&pp1800_lcd>;
+ backlight = <&backlight_lcd0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
new file mode 100644
index 000000000000..56bcd152f43c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83112a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83112A-based DSI display panels
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description:
+ The Himax HX83112A is a generic DSI Panel IC used to control
+ LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ contains:
+ const: djn,9a-3r063-1102b
+
+ reg:
+ maxItems: 1
+
+ vdd1-supply:
+ description: Digital voltage rail
+
+ vsn-supply:
+ description: Positive source voltage rail
+
+ vsp-supply:
+ description: Negative source voltage rail
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd1-supply
+ - vsn-supply
+ - vsp-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "djn,9a-3r063-1102b";
+ reg = <0>;
+
+ backlight = <&pm6150l_wled>;
+ reset-gpios = <&pm6150l_gpios 9 GPIO_ACTIVE_LOW>;
+
+ vdd1-supply = <&vreg_l1e>;
+ vsn-supply = <&pm6150l_lcdb_ncp>;
+ vsp-supply = <&pm6150l_lcdb_ldo>;
+
+ port {
+ panel_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml
new file mode 100644
index 000000000000..e58bb3d45331
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112b.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx83112b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX83112B-based DSI display panels
+
+maintainers:
+ - Luca Weiss <luca@lucaweiss.eu>
+
+description:
+ The Himax HX83112B is a generic DSI Panel IC used to control
+ LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ contains:
+ const: djn,98-03057-6598b-i
+
+ reg:
+ maxItems: 1
+
+ iovcc-supply:
+ description: I/O voltage rail
+
+ vsn-supply:
+ description: Positive source voltage rail
+
+ vsp-supply:
+ description: Negative source voltage rail
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - iovcc-supply
+ - vsn-supply
+ - vsp-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "djn,98-03057-6598b-i";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 61 GPIO_ACTIVE_LOW>;
+
+ iovcc-supply = <&pm8953_l6>;
+ vsn-supply = <&pmi632_lcdb_ncp>;
+ vsp-supply = <&pmi632_lcdb_ldo>;
+
+ port {
+ panel_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
new file mode 100644
index 000000000000..5725a587e35c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/himax,hx8394.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX8394 MIPI-DSI LCD panel controller
+
+maintainers:
+ - Ondrej Jirman <megi@xff.cz>
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+description:
+ Device tree bindings for panels based on the Himax HX8394 controller,
+ such as the HannStar HSD060BHW4 720x1440 TFT LCD panel connected with
+ a MIPI-DSI video interface.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - hannstar,hsd060bhw4
+ - microchip,ac40t08a-mipi-panel
+ - powkiddy,x55-panel
+ - const: himax,hx8394
+ - items:
+ - enum:
+ - huiling,hl055fhav028c
+ - const: himax,hx8399c
+
+ reg:
+ maxItems: 1
+
+ reset-gpios: true
+
+ backlight: true
+
+ rotation: true
+
+ port: true
+
+ vcc-supply:
+ description: Panel power supply
+
+ iovcc-supply:
+ description: I/O voltage supply
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - port
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+allOf:
+ - $ref: panel-common.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - microchip,ac40t08a-mipi-panel
+ then:
+ required:
+ - reset-gpios
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "hannstar,hsd060bhw4", "himax,hx8394";
+ reg = <0>;
+ vcc-supply = <&reg_2v8_p>;
+ iovcc-supply = <&reg_1v8_p>;
+ reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/hydis,hv101hd1.yaml b/Documentation/devicetree/bindings/display/panel/hydis,hv101hd1.yaml
new file mode 100644
index 000000000000..f429e84ee65d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/hydis,hv101hd1.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/hydis,hv101hd1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hydis HV101HD1 DSI Display Panel
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: hydis,hv101hd1
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vio-supply: true
+
+ backlight: true
+ port: true
+
+required:
+ - compatible
+ - vdd-supply
+ - vio-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "hydis,hv101hd1";
+ reg = <0>;
+
+ vdd-supply = <&vdd_lcd>;
+ vio-supply = <&vddio_lcd>;
+
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml
new file mode 100644
index 000000000000..02f7fb1f16dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,il79900a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek IL79900a based MIPI-DSI panels
+
+maintainers:
+ - Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - tianma,tl121bvms07-00
+ - const: ilitek,il79900a
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel used by the panel
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO specifier for the enable pin
+
+ avdd-supply:
+ description: Positive analog voltage supply (AVDD)
+
+ avee-supply:
+ description: Negative analog voltage supply (AVEE)
+
+ pp1800-supply:
+ description: 1.8V logic voltage supply
+
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - avdd-supply
+ - avee-supply
+ - pp1800-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "tianma,tl121bvms07-00", "ilitek,il79900a";
+ reg = <0>;
+ enable-gpios = <&pio 25 0>;
+ avdd-supply = <&reg_avdd>;
+ avee-supply = <&reg_avee>;
+ pp1800-supply = <&reg_pp1800>;
+ backlight = <&backlight>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
index 7e7a8362b951..ef5a2240b684 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/panel/ilitek,ili9163.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ilitek ILI9163 display panels device tree bindings
+title: Ilitek ILI9163 display panels
maintainers:
- Daniel Mack <daniel@zonque.org>
@@ -15,6 +15,7 @@ description:
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
@@ -23,6 +24,9 @@ properties:
- newhaven,1.8-128160EF
- const: ilitek,ili9163
+ reg:
+ maxItems: 1
+
spi-max-frequency:
maximum: 32000000
@@ -31,7 +35,6 @@ properties:
description: Display data/command selection (D/CX)
backlight: true
- reg: true
reset-gpios: true
rotation: true
@@ -41,16 +44,12 @@ required:
- dc-gpios
- reset-gpios
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
- };
spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
index 7d221ef35443..44423465f6e3 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
@@ -26,6 +26,9 @@ properties:
- dlink,dir-685-panel
- const: ilitek,ili9322
+ reg:
+ maxItems: 1
+
reset-gpios: true
port: true
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
index 99e0cb9440cf..5f41758c96d5 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
@@ -16,6 +16,7 @@ description: |
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
@@ -27,7 +28,8 @@ properties:
- canaan,kd233-tft
- const: ilitek,ili9341
- reg: true
+ reg:
+ maxItems: 1
dc-gpios:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
new file mode 100644
index 000000000000..ff67129c9466
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,ili9805.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9805 based MIPI-DSI panels
+
+maintainers:
+ - Michael Trimarchi <michael@amarulasolutions.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - giantplus,gpm1790a0
+ - tianma,tm041xdhg01
+ - const: ilitek,ili9805
+
+ reg:
+ maxItems: 1
+
+ avdd-supply: true
+ dvdd-supply: true
+
+required:
+ - compatible
+ - avdd-supply
+ - dvdd-supply
+ - reg
+ - reset-gpios
+ - port
+ - backlight
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "giantplus,gpm1790a0", "ilitek,ili9805";
+ reg = <0>;
+ avdd-supply = <&avdd_display>;
+ dvdd-supply = <&dvdd_display>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mipi_dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml
new file mode 100644
index 000000000000..f80307579485
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,ili9806e.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9806E based MIPI-DSI panels
+
+maintainers:
+ - Michael Walle <mwalle@kernel.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - densitron,dmt028vghmcmi-1d
+ - ortustech,com35h3p70ulc
+ - const: ilitek,ili9806e
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vccio-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vccio-supply
+ - reset-gpios
+ - backlight
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "ortustech,com35h3p70ulc", "ilitek,ili9806e";
+ reg = <0>;
+ vdd-supply = <&reg_vdd_panel>;
+ vccio-supply = <&reg_vccio_panel>;
+ reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
index c5d1df680858..d979701a00a8 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
@@ -16,14 +16,24 @@ properties:
compatible:
items:
- enum:
+ - ampire,am8001280g
- bananapi,lhr050h41
+ - bestar,bsd1218-a101kl68
- feixin,k101-im2byl02
+ - raspberrypi,dsi-5inch
+ - raspberrypi,dsi-7inch
+ - startek,kd050hdfia020
+ - tdo,tl050hdv35
+ - wanchanglong,w552946aaa
- wanchanglong,w552946aba
- const: ilitek,ili9881c
+ reg:
+ maxItems: 1
+
backlight: true
+ port: true
power-supply: true
- reg: true
reset-gpios: true
rotation: true
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
index 566e11f6bfc0..ab6b7be88341 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
+++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
@@ -12,7 +12,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- - $ref: /schemas/display/lvds.yaml/#
+ - $ref: /schemas/display/lvds.yaml#
select:
properties:
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml
index 72788e3e6c59..c7df9a7f6589 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml
+++ b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml
@@ -17,10 +17,12 @@ properties:
compatible:
const: innolux,ej030na
+ reg:
+ maxItems: 1
+
backlight: true
port: true
power-supply: true
- reg: true
reset-gpios: true
required:
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml
index 5a5f071627fb..4164e3f7061d 100644
--- a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml
@@ -16,9 +16,11 @@ properties:
compatible:
const: innolux,p097pfg
+ reg:
+ maxItems: 1
+
backlight: true
enable-gpios: true
- reg: true
avdd-supply:
description: The regulator that provides positive voltage
diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml
deleted file mode 100644
index 243dac2416f3..000000000000
--- a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml
+++ /dev/null
@@ -1,43 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/panel/innolux,p120zdg-bf1.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
-
-maintainers:
- - Sandeep Panda <spanda@codeaurora.org>
- - Douglas Anderson <dianders@chromium.org>
-
-allOf:
- - $ref: panel-common.yaml#
-
-properties:
- compatible:
- const: innolux,p120zdg-bf1
-
- enable-gpios: true
- power-supply: true
- backlight: true
- no-hpd: true
-
-required:
- - compatible
- - power-supply
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
-
- panel_edp: panel-edp {
- compatible = "innolux,p120zdg-bf1";
- enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>;
- power-supply = <&pm8916_l2>;
- backlight = <&backlight>;
- no-hpd;
- };
-
-...
diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
new file mode 100644
index 000000000000..b8783eba3ddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
@@ -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/jadard,jd9365da-h3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Jadard JD9365DA-HE WXGA DSI panel
+
+maintainers:
+ - Jagan Teki <jagan@edgeble.ai>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - chongzhou,cz101b4001
+ - kingdisplay,kd101ne3-40ti
+ - melfas,lmfbx101117480
+ - radxa,display-10hd-ad001
+ - radxa,display-8hd-ad002
+ - const: jadard,jd9365da-h3
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: supply regulator for VDD, usually 3.3V
+
+ vccio-supply:
+ description: supply regulator for VCCIO, usually 1.8V
+
+ reset-gpios: true
+
+ backlight: true
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vccio-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "chongzhou,cz101b4001", "jadard,jd9365da-h3";
+ reg = <0>;
+ vdd-supply = <&lcd_3v3>;
+ vccio-supply = <&vcca_1v8>;
+ reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_HIGH>;
+ backlight = <&backlight>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml b/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
new file mode 100644
index 000000000000..a8621459005b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lpm102a188a.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/jdi,lpm102a188a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: JDI LPM102A188A 2560x1800 10.2" DSI Panel
+
+maintainers:
+ - Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
+
+description: |
+ This panel requires a dual-channel DSI host to operate. It supports two modes:
+ - left-right: each channel drives the left or right half of the screen
+ - even-odd: each channel drives the even or odd lines of the screen
+
+ Each of the DSI channels controls a separate DSI peripheral. The peripheral
+ driven by the first link (DSI-LINK1) is considered the primary peripheral
+ and controls the device. The 'link2' property contains a phandle to the
+ peripheral driven by the second link (DSI-LINK2).
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: jdi,lpm102a188a
+
+ reg:
+ maxItems: 1
+
+ enable-gpios: true
+ reset-gpios: true
+ power-supply: true
+ backlight: true
+
+ ddi-supply:
+ description: The regulator that provides IOVCC (1.8V).
+
+ link2:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ phandle to the DSI peripheral on the secondary link. Note that the
+ presence of this property marks the containing node as DSI-LINK1.
+
+required:
+ - compatible
+ - reg
+
+if:
+ required:
+ - link2
+then:
+ required:
+ - power-supply
+ - ddi-supply
+ - enable-gpios
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+
+ dsia: dsi@54300000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x54300000 0x0 0x00040000>;
+
+ link2: panel@0 {
+ compatible = "jdi,lpm102a188a";
+ reg = <0>;
+ };
+ };
+
+ dsib: dsi@54400000{
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x54400000 0x0 0x00040000>;
+ nvidia,ganged-mode = <&dsia>;
+
+ link1: panel@0 {
+ compatible = "jdi,lpm102a188a";
+ reg = <0>;
+ power-supply = <&pplcd_vdd>;
+ ddi-supply = <&pp1800_lcdio>;
+ enable-gpios = <&gpio TEGRA_GPIO(V, 1) GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
+ link2 = <&link2>;
+ backlight = <&backlight>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
index 63c82a4378ff..0c8b5cb78bfe 100644
--- a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
@@ -16,8 +16,10 @@ properties:
compatible:
const: jdi,lt070me05000
+ reg:
+ maxItems: 1
+
enable-gpios: true
- reg: true
reset-gpios: true
vddp-supply:
diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
index b4be9bd8ddde..d86c916f7b55 100644
--- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
+++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml
@@ -17,10 +17,12 @@ properties:
compatible:
const: kingdisplay,kd035g6-54nt
+ reg:
+ maxItems: 1
+
backlight: true
port: true
power-supply: true
- reg: true
reset-gpios: true
spi-3wire: true
diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
index ebdca5f5a001..b5dc02b27200 100644
--- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml
@@ -18,16 +18,15 @@ properties:
compatible:
const: leadtek,ltk035c5444t
- backlight: true
- port: true
- power-supply: true
- reg: true
- reset-gpios: true
+ reg:
+ maxItems: 1
spi-3wire: true
required:
- compatible
+ - reg
+ - port
- power-supply
- reset-gpios
diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
index 3f6efbb942da..5fcea62fd58f 100644
--- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -17,8 +17,13 @@ properties:
enum:
- leadtek,ltk050h3146w
- leadtek,ltk050h3146w-a2
- reg: true
+ - leadtek,ltk050h3148w
+
+ reg:
+ maxItems: 1
+
backlight: true
+ port: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
index c5944b4d636c..b0e2c82232d3 100644
--- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml
@@ -14,9 +14,15 @@ allOf:
properties:
compatible:
- const: leadtek,ltk500hd1829
- reg: true
+ enum:
+ - leadtek,ltk101b4029w
+ - leadtek,ltk500hd1829
+
+ reg:
+ maxItems: 1
+
backlight: true
+ port: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
diff --git a/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml
new file mode 100644
index 000000000000..0f0b9079f199
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/lg,ld070wx3-sl01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LG Corporation 7" WXGA TFT LCD panel
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: lg,ld070wx3-sl01
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vcc-supply: true
+
+ backlight: true
+ port: true
+
+required:
+ - compatible
+ - vdd-supply
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "lg,ld070wx3-sl01";
+ reg = <0>;
+
+ vdd-supply = <&vdd_3v3_lcd>;
+ vcc-supply = <&vcc_1v8_lcd>;
+
+ backlight = <&backlight>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml b/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml
index ee357e139ac0..590ccc27d104 100644
--- a/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml
@@ -21,7 +21,8 @@ properties:
compatible:
const: lg,lg4573
- reg: true
+ reg:
+ maxItems: 1
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
new file mode 100644
index 000000000000..2219d3d4ac43
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/lg,sw43408.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LG SW43408 1080x2160 DSI panel
+
+maintainers:
+ - Casey Connolly <casey.connolly@linaro.org>
+
+description:
+ This panel is used on the Pixel 3, it is a 60hz OLED panel which
+ required DSC (Display Stream Compression) and has rounded corners.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: lg,sw43408
+
+ reg:
+ maxItems: 1
+
+ port: true
+ vddi-supply: true
+ vpnl-supply: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - vddi-supply
+ - vpnl-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "lg,sw43408";
+ reg = <0>;
+
+ vddi-supply = <&vreg_l14a_1p88>;
+ vpnl-supply = <&vreg_l28a_3p0>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
index 628c4b898111..3de17fd8513b 100644
--- a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
const: lgphilips,lb035q02
+ reg:
+ maxItems: 1
+
label: true
enable-gpios: true
port: true
diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
index a4b8569ab81c..74ff772973d6 100644
--- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
index 5cf3c588f46d..96621b89ae9e 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
@@ -12,7 +12,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- - $ref: /schemas/display/lvds.yaml/#
+ - $ref: /schemas/display/lvds.yaml#
select:
properties:
@@ -33,7 +33,9 @@ properties:
description: Reference to the regulator powering the panel VCC pins.
data-mapping:
- const: jeida-24
+ enum:
+ - jeida-18
+ - jeida-24
width-mm:
const: 210
@@ -41,6 +43,7 @@ properties:
height-mm:
const: 158
+ backlight: true
panel-timing: true
port: true
@@ -48,7 +51,6 @@ additionalProperties: false
required:
- compatible
- - vcc-supply
- data-mapping
- width-mm
- height-mm
diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
index 54750cc5440d..37f01d847aac 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
@@ -12,7 +12,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- - $ref: /schemas/display/lvds.yaml/#
+ - $ref: /schemas/display/lvds.yaml#
select:
properties:
diff --git a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
index aa788eaa2f71..1cffe4d6d498 100644
--- a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
+++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
@@ -15,14 +15,17 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
const: nec,nl8048hl11
+ reg:
+ maxItems: 1
+
label: true
port: true
- reg: true
reset-gpios: true
spi-max-frequency:
@@ -34,13 +37,13 @@ required:
- reset-gpios
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
new file mode 100644
index 000000000000..d3a25a8fd7e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/newvision,nv3051d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NewVision NV3051D based LCD panel
+
+description: |
+ The NewVision NV3051D is a driver chip used to drive DSI panels.
+
+maintainers:
+ - Chris Morgan <macromorgan@hotmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - anbernic,rg351v-panel
+ - anbernic,rg353p-panel
+ - powkiddy,rk2023-panel
+ - const: newvision,nv3051d
+
+ reg:
+ maxItems: 1
+
+ backlight: true
+ port: true
+ reset-gpios:
+ description: Active low reset GPIO
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "anbernic,rg353p-panel", "newvision,nv3051d";
+ reg = <0>;
+ backlight = <&backlight>;
+ reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&vcc3v3_lcd>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
index bc92928c805b..bb50fd5506c3 100644
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
@@ -15,20 +15,26 @@ allOf:
properties:
compatible:
items:
- - const: hydis,hva40wv1
+ - enum:
+ - frida,frd400b25025
+ - hydis,hva40wv1
- const: novatek,nt35510
description: This indicates the panel manufacturer of the panel
that is in turn using the NT35510 panel driver. The compatible
string determines how the NT35510 panel driver shall be configured
to work with the indicated panel. The novatek,nt35510 compatible shall
always be provided as a fallback.
- reg: true
+
+ reg:
+ maxItems: 1
+
reset-gpios: true
vdd-supply:
description: regulator that supplies the vdd voltage
vddi-supply:
description: regulator that supplies the vddi voltage
backlight: true
+ port: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
index 377a05d48a02..a9e40493986b 100644
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
@@ -19,7 +19,7 @@ description: |
either bilinear interpolation or pixel duplication.
allOf:
- - $ref: panel-common.yaml#
+ - $ref: panel-common-dual.yaml#
properties:
compatible:
@@ -33,6 +33,9 @@ properties:
to work with the indicated panel. The novatek,nt35950 compatible shall
always be provided as a fallback.
+ reg:
+ maxItems: 1
+
reset-gpios:
maxItems: 1
description: phandle of gpio for reset line - This should be 8mA, gpio
@@ -49,7 +52,6 @@ properties:
backlight: true
ports: true
- reg: true
required:
- compatible
@@ -59,6 +61,7 @@ required:
- avee-supply
- dvdd-supply
- vddio-supply
+ - ports
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
new file mode 100644
index 000000000000..c4bae4f77085
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36523.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36523 based DSI display Panels
+
+maintainers:
+ - Jianhua Lu <lujianhua000@gmail.com>
+
+description: |
+ The Novatek NT36523 is a generic DSI Panel IC used to drive dsi
+ panels. Support video mode panels from China Star Optoelectronics
+ Technology (CSOT) and BOE Technology.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - xiaomi,elish-boe-nt36523
+ - xiaomi,elish-csot-nt36523
+ - const: novatek,nt36523
+ - items:
+ - enum:
+ - lenovo,j606f-boe-nt36523w
+ - const: novatek,nt36523w
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description: phandle of gpio for reset line - This should be 8mA
+
+ vddio-supply:
+ description: regulator that supplies the I/O voltage
+
+ rotation: true
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - reset-gpios
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - novatek,nt36523w
+ then:
+ properties:
+ ports:
+ properties:
+ port@1: false
+ else:
+ properties:
+ port: false
+ ports:
+ required:
+ - port@1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "xiaomi,elish-csot-nt36523", "novatek,nt36523";
+ reg = <0>;
+
+ vddio-supply = <&vreg_l14a_1p88>;
+ reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ panel_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1{
+ reg = <1>;
+ panel_in_1: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
index 41ee3157a1cd..800a2f0a4dad 100644
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -29,12 +29,15 @@ properties:
determines how the NT36672A panel driver is configured for the indicated
panel. The novatek,nt36672a compatible shall always be provided as a fallback.
+ reg:
+ maxItems: 1
+
reset-gpios:
maxItems: 1
description: phandle of gpio for reset line - This should be 8mA, gpio
can be configured using mux, pinctrl, pinctrl-names (active high)
- vddi0-supply:
+ vddio-supply:
description: phandle of the regulator that provides the supply voltage
Power IC supply
@@ -44,14 +47,13 @@ properties:
vddneg-supply:
description: phandle of the negative boost supply regulator
- reg: true
port: true
backlight: true
required:
- compatible
- reg
- - vddi0-supply
+ - vddio-supply
- vddpos-supply
- vddneg-supply
- reset-gpios
@@ -70,7 +72,7 @@ examples:
panel@0 {
compatible = "tianma,fhd-video", "novatek,nt36672a";
reg = <0>;
- vddi0-supply = <&vreg_l14a_1p88>;
+ vddio-supply = <&vreg_l14a_1p88>;
vddpos-supply = <&lab>;
vddneg-supply = <&ibb>;
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml
new file mode 100644
index 000000000000..dc4672f3d01d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672e.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672E LCD DSI Panel
+
+maintainers:
+ - Ritesh Kumar <quic_riteshk@quicinc.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: novatek,nt36672e
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vddi-supply: true
+ avdd-supply: true
+ avee-supply: true
+ port: true
+ reset-gpios: true
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - vddi-supply
+ - avdd-supply
+ - avee-supply
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "novatek,nt36672e";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 44 GPIO_ACTIVE_HIGH>;
+
+ vddi-supply = <&vreg_l8c_1p8>;
+ avdd-supply = <&disp_avdd>;
+ avee-supply = <&disp_avee>;
+
+ backlight = <&pwm_backlight>;
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt37801.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt37801.yaml
new file mode 100644
index 000000000000..1b38c1d0af68
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt37801.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt37801.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT37801 AMOLED DSI Panel
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Naming is inconclusive and different sources claim this is either Novatek
+ NT37801 or NT37810 AMOLED DSI Panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: novatek,nt37801
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vci-supply: true
+ vdd-supply: true
+ vddio-supply: true
+ port: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - reg
+ - vci-supply
+ - vdd-supply
+ - vddio-supply
+ - port
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "novatek,nt37801";
+ reg = <0>;
+
+ vci-supply = <&vreg_l13b_3p0>;
+ vdd-supply = <&vreg_l11b_1p2>;
+ vddio-supply = <&vreg_l12b_1p8>;
+
+ reset-gpios = <&tlmm 98 GPIO_ACTIVE_LOW>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
index 2329d9610f83..e5d8785fdf90 100644
--- a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
+++ b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/panel/olimex,lcd-olinuxino.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for Olimex Ltd. LCD-OLinuXino bridge panel.
+title: Olimex Ltd. LCD-OLinuXino bridge panel.
maintainers:
- Stefan Mavrodiev <stefan@olimex.com>
@@ -20,7 +20,7 @@ description: |
The panel itself contains:
- AT24C16C EEPROM holding panel identification and timing requirements
- AR1021 resistive touch screen controller (optional)
- - FT5x6 capacitive touch screnn controller (optional)
+ - FT5x6 capacitive touch screen controller (optional)
- GT911/GT928 capacitive touch screen controller (optional)
The above chips share same I2C bus. The EEPROM is factory preprogrammed with
@@ -38,10 +38,12 @@ properties:
compatible:
const: olimex,lcd-olinuxino
+ reg:
+ maxItems: 1
+
backlight: true
enable-gpios: true
power-supply: true
- reg: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
index ad7d3575190e..1e4f140f48b8 100644
--- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
+++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/orisetech,otm8009a.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml b/Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml
new file mode 100644
index 000000000000..cc7ea3c35c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-common-dual.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-common-dual.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Properties for Dual-Link Display Panels
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+description:
+ Properties common for Panel IC supporting dual link panels. Devices might
+ support also single link.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ additionalProperties: false
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: First link
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Second link
+
+ "#address-cells": true
+ "#size-cells": true
+
+ required:
+ - port@0
+
+# Single-panel setups are still allowed.
+oneOf:
+ - required:
+ - ports
+ - required:
+ - port
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index 5b38dc89cb21..087415753d60 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
This document defines device tree properties common to several classes of
- display panels. It doesn't constitue a device tree binding specification by
+ display panels. It doesn't constitute a device tree binding specification by
itself but is meant to be referenced by device tree bindings.
When referenced from panel device tree bindings the properties defined in this
@@ -51,6 +51,14 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
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
panel-timing:
description:
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
index 4a36aa64c716..f8dc9929e833 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml
new file mode 100644
index 000000000000..b308047c1edf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-edp-legacy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Legacy eDP panels from before the "edp-panel" compatible
+
+maintainers:
+ - Douglas Anderson <dianders@chromium.org>
+
+description: |
+ This binding file is a collection of eDP panels from before the generic
+ "edp-panel" compatible was introduced. It is kept around to support old
+ dts files. The only reason one might add a new panel here instead of using
+ the generic "edp-panel" is if it needed to be used on an eDP controller
+ that doesn't support the generic "edp-panel" compatible, but it should be
+ a strong preference to add the generic "edp-panel" compatible instead.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ # compatible must be listed in alphabetical order, ordered by compatible.
+ # The description in the comment is mandatory for each compatible.
+
+ # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+ - auo,b101ean01
+ # AUO B116XAK01 eDP TFT LCD panel
+ - auo,b116xa01
+ # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
+ - auo,b133htn01
+ # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
+ - auo,b133xtn01
+ # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+ - boe,nv101wxmn51
+ # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel
+ - boe,nv110wtm-n61
+ # BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel
+ - boe,nv133fhm-n61
+ # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel
+ - boe,nv133fhm-n62
+ # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
+ - boe,nv140fhmn49
+ # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
+ - innolux,n116bca-ea1
+ # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
+ - innolux,n116bge
+ # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
+ - innolux,n125hce-gn1
+ # Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel
+ - innolux,p120zdg-bf1
+ # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
+ - kingdisplay,kd116n21-30nv-a010
+ # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
+ - lg,lp079qx1-sp0v
+ # LG 9.7" (2048x1536 pixels) TFT LCD panel
+ - lg,lp097qx1-spa1
+ # LG 12.0" (1920x1280 pixels) TFT LCD panel
+ - lg,lp120up1
+ # LG 12.9" (2560x1700 pixels) TFT LCD panel
+ - lg,lp129qe
+ # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
+ - neweast,wjfh116008a
+ # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
+ - samsung,lsn122dl01-c01
+ # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
+ - samsung,ltn140at29-301
+ # Sharp LD-D5116Z01B 12.3" WUXGA+ eDP panel
+ - sharp,ld-d5116z01b
+ # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
+ - sharp,lq123p1jx31
+
+ backlight: true
+ ddc-i2c-bus: true
+ enable-gpios: true
+ panel-timing: true
+ port: true
+ power-supply: true
+ no-hpd: true
+ hpd-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - power-supply
+
+examples:
+ - |
+ panel: panel {
+ compatible = "innolux,n116bge";
+ power-supply = <&panel_regulator>;
+ backlight = <&backlight>;
+
+ panel-timing {
+ clock-frequency = <74250000>;
+ hactive = <1366>;
+ hfront-porch = <136>;
+ hback-porch = <60>;
+ hsync-len = <30>;
+ hsync-active = <0>;
+ vactive = <768>;
+ vfront-porch = <8>;
+ vback-porch = <12>;
+ vsync-len = <12>;
+ vsync-active = <0>;
+ };
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&edp_out_panel>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index fcc50db6a812..dbc01e640895 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/panel/panel-lvds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic LVDS Display Panel Device Tree Bindings
+title: Generic LVDS Display Panel
maintainers:
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
@@ -12,7 +12,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- - $ref: /schemas/display/lvds.yaml/#
+ - $ref: /schemas/display/lvds.yaml#
select:
properties:
@@ -39,8 +39,28 @@ properties:
compatible:
items:
- enum:
+ # Admatec 9904379 10.1" 1024x600 LVDS panel
+ - admatec,9904379
+ # Ampire AMP19201200B5TZQW-T03 10.1" WUXGA (1920x1200) color TFT LCD panel
+ - ampire,amp19201200b5tzqw-t03
- auo,b101ew05
+ # AUO G084SN05 V9 8.4" 800x600 LVDS panel
+ - auo,g084sn05
+ # Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel
+ - chunghwa,claa070wp03xg
+ # EDT ETML0700Z8DHA 7.0" Full HD (1920x1080) color TFT LCD LVDS panel
+ - edt,etml0700z8dha
+ # EDT ETML0700Z9NDHA 7.0" WSVGA (1024x600) color TFT LCD LVDS panel
+ - edt,etml0700z9ndha
+ # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel
+ - hannstar,hsd101pww2
+ # Hydis Technologies 7" WXGA (800x1280) TFT LCD LVDS panel
+ - hydis,hv070wx2-1e0
+ # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
+ - jenson,bl-jt60050-01a
- tbs,a711-panel
+ # Winstar WF70A8SYJHLNGA 7" WSVGA (1024x600) color TFT LCD LVDS panel
+ - winstar,wf70a8syjhlnga
- const: panel-lvds
diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
index c2df8d28aaf5..6f0290c4e291 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
@@ -22,8 +22,9 @@ description: |
The standard defines the following interface signals for type C:
- Power:
- Vdd: Power supply for display module
+ Called power-supply in this binding.
- Vddi: Logic level supply for interface signals
- Combined into one in this binding called: power-supply
+ Called io-supply in this binding.
- Interface:
- CSx: Chip select
- SCL: Serial clock
@@ -49,6 +50,12 @@ description: |
| Command or data |
|<D7><D6><D5><D4><D3><D2><D1><D0>|
+ The standard defines one pixel format for type C: RGB111. The industry
+ however has decided to provide the type A/B interface pixel formats also on
+ the Type C interface and most common among these are RGB565 and RGB666.
+ The MIPI DCS command set_address_mode (36h) has one bit that controls RGB/BGR
+ order. This gives each supported RGB format a BGR variant.
+
The panel resolution is specified using the panel-timing node properties
hactive (width) and vactive (height). The other mandatory panel-timing
properties should be set to zero except clock-frequency which can be
@@ -65,9 +72,14 @@ properties:
compatible:
items:
- enum:
+ - saef,sftc154b
- sainsmart18
+ - shineworld,lh133k
- const: panel-mipi-dbi-spi
+ reg:
+ maxItems: 1
+
write-only:
type: boolean
description:
@@ -80,6 +92,35 @@ properties:
Controller data/command selection (D/CX) in 4-line SPI mode.
If not set, the controller is in 3-line SPI mode.
+ io-supply:
+ description: |
+ Logic level supply for interface signals (Vddi).
+ No need to set if this is the same as power-supply.
+
+ spi-3wire: true
+
+ format:
+ description: >
+ Pixel format in bit order as going on the wire:
+ * `x2r1g1b1r1g1b1` - RGB111, 2 pixels per byte
+ * `x2b1g1r1b1g1r1` - BGR111, 2 pixels per byte
+ * `x1r1g1b1x1r1g1b1` - RGB111, 2 pixels per byte
+ * `x1b1g1r1x1b1g1r1` - BGR111, 2 pixels per byte
+ * `r5g6b5` - RGB565, 2 bytes
+ * `b5g6r5` - BGR565, 2 bytes
+ * `r6x2g6x2b6x2` - RGB666, 3 bytes
+ * `b6x2g6x2r6x2` - BGR666, 3 bytes
+ enum:
+ - x2r1g1b1r1g1b1
+ - x2b1g1r1b1g1r1
+ - x1r1g1b1x1r1g1b1
+ - x1b1g1r1x1b1g1r1
+ - r5g6b5
+ - b5g6r5
+ - r6x2g6x2b6x2
+ - b6x2g6x2r6x2
+ default: r5g6b5
+
required:
- compatible
- reg
@@ -106,6 +147,8 @@ examples:
reset-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>;
write-only;
+ format = "r5g6b5";
+
backlight = <&backlight>;
width-mm = <35>;
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
index 2c00813f5d20..8d668979b62d 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-simple-dsi.yaml#
@@ -39,22 +39,24 @@ properties:
- jdi,fhd-r63452
# Khadas TS050 5" 1080x1920 LCD panel
- khadas,ts050
+ # Khadas TS050 V2 5" 1080x1920 LCD panel
+ - khadas,ts050v2
# Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
- kingdisplay,kd097d04
# LG ACX467AKM-7 4.95" 1080×1920 LCD Panel
- lg,acx467akm-7
- # LG Corporation 7" WXGA TFT LCD panel
- - lg,ld070wx3-sl01
+ # LG Corporation 5" HD TFT LCD panel
+ - lg,lh500wx1-sd03
+ # Lincoln LCD197 5" 1080x1920 LCD panel
+ - lincolntech,lcd197
# One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel
- osddisplays,osd101t2587-53ts
# Panasonic 10" WUXGA TFT LCD panel
- panasonic,vvx10f004b00
# Panasonic 10" WUXGA TFT LCD panel
- panasonic,vvx10f034n00
- # Samsung s6e3fc2x01 1080x2340 AMOLED panel
- - samsung,s6e3fc2x01
- # Samsung sofef00 1080x2280 AMOLED panel
- - samsung,sofef00
+ # Samsung s6e3fa7 1080x2220 based AMS559NK06 AMOLED panel
+ - samsung,s6e3fa7-ams559nk06
# Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel
- tdo,tl070wsh30
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
new file mode 100644
index 000000000000..548f5ac14500
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple LVDS panels with one power supply and dual LVDS ports
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Sam Ravnborg <sam@ravnborg.org>
+
+description: |
+ This binding file is a collection of the LVDS panels that
+ has dual LVDS ports and requires only a single power-supply.
+ The first port receives odd pixels, and the second port receives even pixels.
+ There are optionally a backlight and an enable GPIO.
+ The panel may use an OF graph binding for the association to the display,
+ or it may be a direct child node of the display.
+
+ If the panel is more advanced a dedicated binding file is required.
+
+allOf:
+ - $ref: /schemas/display/lvds-dual-ports.yaml#
+ - $ref: panel-common.yaml#
+
+properties:
+
+ compatible:
+ enum:
+ # compatible must be listed in alphabetical order, ordered by compatible.
+ # The description in the comment is mandatory for each compatible.
+
+ # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
+ - auo,g133han01
+ # AU Optronics Corporation 15.6" FHD (1920x1080) TFT LCD panel
+ - auo,g156han04
+ # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
+ - auo,g185han01
+ # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
+ - auo,g190ean01
+ # BOE AV123Z7M-N17 12.3" (1920x720) LVDS TFT LCD panel
+ - boe,av123z7m-n17
+ # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
+ - koe,tx26d202vm0bwa
+ # Lincoln Technology Solutions, LCD185-101CT 10.1" TFT 1920x1200
+ - lincolntech,lcd185-101ct
+ # Microtips Technology MF-101HIEBCAF0 10.1" WUXGA (1920x1200) TFT LCD panel
+ - microtips,mf-101hiebcaf0
+ # Microtips Technology MF-103HIEB0GA0 10.25" 1920x720 TFT LCD panel
+ - microtips,mf-103hieb0ga0
+ # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
+ - nlt,nl192108ac18-02d
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ required:
+ - dual-lvds-odd-pixels
+
+ port@1:
+ required:
+ - dual-lvds-even-pixels
+
+ required:
+ - port@0
+ - port@1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - power-supply
+
+examples:
+ - |
+ panel: panel-lvds {
+ compatible = "koe,tx26d202vm0bwa";
+ power-supply = <&vdd_lcd_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ dual-lvds-odd-pixels;
+ reg = <0>;
+
+ panel_lvds0_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ dual-lvds-even-pixels;
+ reg = <1>;
+
+ panel_lvds1_in: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 18241f4051d2..24e277b19094 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -21,9 +21,9 @@ description: |
allOf:
- $ref: panel-common.yaml#
+ - $ref: ../lvds-data-mapping.yaml#
properties:
-
compatible:
enum:
# compatible must be listed in alphabetical order, ordered by compatible.
@@ -33,62 +33,50 @@ properties:
- ampire,am-1280800n3tzqw-t00h
# Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
- ampire,am-480272h3tmqw-t01h
+ # Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel
+ - ampire,am-800480l1tmqw-t00h
# Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
- ampire,am800480r3tmqwa1h
# Ampire AM-800600P5TMQW-TB8H 8.0" SVGA TFT LCD panel
- ampire,am800600p5tmqw-tb8h
# AU Optronics Corporation 10.1" WSVGA TFT LCD panel
- auo,b101aw03
- # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
- - auo,b101ean01
# AU Optronics Corporation 10.1" WXGA TFT LCD panel
- auo,b101xtn01
- # AUO B116XAK01 eDP TFT LCD panel
- - auo,b116xa01
# AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
- auo,b116xw03
- # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
- - auo,b133han05
- # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel
- - auo,b133htn01
- # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
- - auo,b133xtn01
- # AU Optronics Corporation 14.0" FHD (1920x1080) color TFT-LCD panel
- - auo,b140han06
# AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
- auo,g070vvn01
# AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel
- auo,g101evn010
# AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
- auo,g104sn02
+ # AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
+ - auo,g104stn01
# AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
- auo,g121ean01
- # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
- - auo,g133han01
# AU Optronics Corporation 15.6" (1366x768) TFT LCD panel
- auo,g156xtn01
- # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
- - auo,g185han01
- # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
- - auo,g190ean01
+ # AU Optronics Corporation 23.8" FHD (1920x1080) TFT LCD panel
+ - auo,p238han01
# AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
- auo,p320hvn03
# AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
- auo,t215hvn01
# Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel
- avic,tm070ddh03
+ # BOE AV101HDT-a10 10.1" 1280x720 LVDS panel
+ - boe,av101hdt-a10
+ # BOE BP082WX1-100 8.2" WXGA (1280x800) LVDS panel
+ - boe,bp082wx1-100
+ # BOE BP101WX1-100 10.1" WXGA (1280x800) LVDS panel
+ - boe,bp101wx1-100
+ # BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel
+ - boe,ev121wxm-n10-1850
# BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
- boe,hv070wsa-100
- # BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
- - boe,nv101wxmn51
- # BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel
- - boe,nv110wtm-n61
- # BOE NV110WTM-N61 11.0" 2160x1440 TFT LCD Panel
- - boe,nv133fhm-n61
- # BOE NV133FHM-N62 13.3" FHD (1920x1080) TFT LCD Panel
- - boe,nv133fhm-n62
- # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
- - boe,nv140fhmn49
+ # Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel
+ - cct,cmt430b19n00
# CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
- cdtech,s043wq26h-ct7
# CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel
@@ -99,8 +87,6 @@ properties:
- cdtech,s070wv95-ct16
# Chefree CH101OLHLWH-002 10.1" (1280x800) color TFT LCD panel
- chefree,ch101olhlwh-002
- # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
- - chunghwa,claa070wp03xg
# Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
- chunghwa,claa101wa01a
# Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
@@ -143,11 +129,15 @@ properties:
- edt,etm0700g0edh6
# Emerging Display Technology Corp. LVDS WSVGA TFT Display with capacitive touch
- edt,etml0700y5dha
+ # Emerging Display Technology Corp. 10.1" LVDS WXGA TFT Display with capacitive touch
+ - edt,etml1010g3dra
# Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with
# capacitive touch
- edt,etmv570g2dhu
# E Ink VB3300-KCA
- eink,vb3300-kca
+ # Evervision Electronics Co. Ltd. VGG644804 5.7" VGA TFT LCD Panel
+ - evervision,vgg644804
# Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
- evervision,vgg804821
# Foxlink Group 5" WVGA TFT LCD panel
@@ -164,16 +154,16 @@ properties:
- hannstar,hsd070pww1
# HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
- hannstar,hsd100pxn1
- # HannStar Display Corp. HSD101PWW2 10.1" WXGA (1280x800) LVDS panel
- - hannstar,hsd101pww2
# Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
- hit,tx23d38vm0caa
- # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
- - ivo,m133nwf4-r0
# Innolux AT043TN24 4.3" WQVGA TFT LCD panel
- innolux,at043tn24
# Innolux AT070TN92 7.0" WQVGA TFT LCD panel
- innolux,at070tn92
+ # Innolux G070ACE-L01 7" WVGA (800x480) TFT LCD panel
+ - innolux,g070ace-l01
+ # Innolux G070ACE-LH3 7" WVGA (800x480) TFT LCD panel with WLED backlight
+ - innolux,g070ace-lh3
# Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
- innolux,g070y2-l01
# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel
@@ -184,22 +174,20 @@ properties:
- innolux,g121i1-l01
# Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
- innolux,g121x1-l03
- # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- - innolux,n116bca-ea1
- # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- - innolux,n116bge
- # InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
- - innolux,n125hce-gn1
+ # Innolux Corporation 12.1" G121XCE-L01 XGA (1024x768) TFT LCD panel
+ - innolux,g121xce-l01
+ # InnoLux 15.6" FHD (1920x1080) TFT LCD panel
+ - innolux,g156hce-l01
+ # InnoLux 13.3" FHD (1920x1080) TFT LCD panel
+ - innolux,n133hse-ea1
# InnoLux 15.6" WXGA TFT LCD panel
- innolux,n156bge-l21
# Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
- innolux,zj070na-01p
- # King & Display KD116N21-30NV-A010 eDP TFT LCD panel
- - kingdisplay,kd116n21-30nv-a010
+ # JuTouch Technology Co.. 10" JT101TM023 WXGA (1280 x 800) LVDS panel
+ - jutouch,jt101tm023
# Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
- koe,tx14d24vm1bpa
- # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
- - koe,tx26d202vm0bwa
# Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
- koe,tx31d200vm0baa
# Kyocera Corporation 7" WVGA (800x480) transmissive color TFT
@@ -210,16 +198,6 @@ properties:
- lemaker,bl035-rgb-002
# LG 7" (800x480 pixels) TFT LCD panel
- lg,lb070wv8
- # LG Corporation 5" HD TFT LCD panel
- - lg,lh500wx1-sd03
- # LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
- - lg,lp079qx1-sp0v
- # LG 9.7" (2048x1536 pixels) TFT LCD panel
- - lg,lp097qx1-spa1
- # LG 12.0" (1920x1280 pixels) TFT LCD panel
- - lg,lp120up1
- # LG 12.9" (2560x1700 pixels) TFT LCD panel
- - lg,lp129qe
# Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module
- logictechno,lt161010-2nhc
# Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
@@ -230,32 +208,44 @@ properties:
- logictechno,lttd800480070-l2rt
# Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module
- 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-ca1
+ # Mitsubishi AA084XE01 8.4" XGA TFT LCD panel
+ - mitsubishi,aa084xe01
+ # Multi-Inno Technology Co.,Ltd MI0700A2T-30 7" 800x480 TFT Resistive Touch Module
+ - multi-inno,mi0700a2t-30
# Multi-Inno Technology Co.,Ltd MI0700S4T-6 7" 800x480 TFT Resistive Touch Module
- multi-inno,mi0700s4t-6
# Multi-Inno Technology Co.,Ltd MI0800FT-9 8" 800x600 TFT Resistive Touch Module
- multi-inno,mi0800ft-9
# Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod.
- multi-inno,mi1010ait-1cp
+ # Multi-Inno Technology Co.,Ltd MI1010Z1T-1CP11 10.1" 1024x600 TFT Resistive Touch Module
+ - multi-inno,mi1010z1t-1cp11
# NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel
- nec,nl12880bc20-05
# NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
- nec,nl4827hc19-05b
# Netron-DY E231732 7.0" WSVGA TFT LCD panel
- netron-dy,e231732
- # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
- - neweast,wjfh116008a
# Newhaven Display International 480 x 272 TFT LCD panel
- newhaven,nhd-4.3-480272ef-atxl
- # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
- - nlt,nl192108ac18-02d
+ # NLT Technologies, Ltd. 12.1" WXGA (1280 x 800) LVDS TFT LCD panel
+ - nlt,nl12880bc20-spwg-24
+ # NLT Technologies, Ltd. 15.6" WXGA (1366×768) LVDS TFT LCD panel
+ - nlt,nl13676bc25-03f
# New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
- nvd,9128
# OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
- okaya,rs800480t-7x0gp
# Olimex 4.3" TFT LCD panel
- olimex,lcd-olinuxino-43-ts
+ # Olimex 5.0" TFT LCD panel
+ - olimex,lcd-olinuxino-5-cts
+ # On Tat Industrial Company 5" DPI TFT panel.
+ - ontat,kd50g21-40nt-a1
# On Tat Industrial Company 7" DPI TFT panel.
- ontat,yx700wv03
# OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
@@ -268,26 +258,32 @@ properties:
- osddisplays,osd070t1718-19ts
# One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
- osddisplays,osd101t2045-53ts
+ # POWERTIP PH128800T004-ZZA01 10.1" WXGA TFT LCD panel
+ - powertip,ph128800t004-zza01
+ # POWERTIP PH128800T006-ZHC01 10.1" WXGA TFT LCD panel
+ - powertip,ph128800t006-zhc01
# POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel
- powertip,ph800480t013-idf02
+ # PrimeView PM070WL4 7.0" 800x480 TFT LCD panel
+ - primeview,pm070wl4
# QiaoDian XianShi Corporation 4"3 TFT LCD panel
- qiaodian,qd43003c0-40
# Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel
- qishenglong,gopher2b-lcd
+ # Raystar Optronics, Inc. RFF500F-AWH-DNN 5.0" TFT 840x480
+ - raystar,rff500f-awh-dnn
# Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
- rocktech,rk101ii01d-ct
# Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
- rocktech,rk070er9427
- # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
- - samsung,atna33xc20
- # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
- - samsung,lsn122dl01-c01
+ # Rocktech Display Ltd. RK043FN48H 4.3" 480x272 LCD-TFT panel
+ - rocktech,rk043fn48h
# Samsung Electronics 10.1" WXGA (1280x800) TFT LCD panel
- samsung,ltl101al01
+ # Samsung Electronics 10.6" FWXGA (1366x768) TFT LCD panel
+ - samsung,ltl106al01
# Samsung Electronics 10.1" WSVGA TFT LCD panel
- samsung,ltn101nt05
- # Samsung Electronics 14" WXGA (1366x768) TFT LCD panel
- - samsung,ltn140at29-301
# Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
- satoz,sat050at40h12r2
# Sharp LQ035Q7DB03 3.5" QVGA TFT LCD panel
@@ -296,28 +292,28 @@ properties:
- sharp,lq070y3dg3b
# Sharp Display Corp. LQ101K1LY04 10.07" WXGA TFT LCD panel
- sharp,lq101k1ly04
- # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
- - sharp,lq123p1jx31
- # Sharp 14" (1920x1080 pixels) TFT LCD panel
- - sharp,lq140m1jw46
# Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
- sharp,ls020b1dd01d
# Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
- shelly,sca07010-bfn-lnn
# Starry KR070PE2T 7" WVGA TFT LCD panel
- starry,kr070pe2t
- # Starry 12.2" (1920x1200 pixels) TFT LCD panel
- - starry,kr122ea0sra
# Startek KD070WVFPA043-C069A 7" TFT LCD panel
- startek,kd070wvfpa
# Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel
- team-source-display,tst043015cmhx
+ # Tianma Micro-electronics P0700WXF1MBAA 7.0" WXGA (1280x800) LVDS TFT LCD panel
+ - tianma,p0700wxf1mbaa
# Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
- tianma,tm070jdhg30
+ # Tianma Micro-electronics TM070JDHG34-00 7.0" WXGA (1280x800) LVDS TFT LCD panel
+ - tianma,tm070jdhg34-00
# Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel
- tianma,tm070jvhg33
# Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
- tianma,tm070rvhg71
+ # Topland TIAN-G07017-01 7.0" WSVGA TFT-LCD panel with capacitive touch
+ - topland,tian-g07017-01
# Toshiba 8.9" WXGA (1280x768) TFT LCD panel
- toshiba,lt089ac29000
# TPK U.S.A. LLC Fusion 7" 800 x 480 (WVGA) LCD panel with capacitive touch
@@ -337,20 +333,26 @@ properties:
- vivax,tpc9150-panel
# VXT 800x480 color TFT LCD panel
- vxt,vl050-8048nt-c01
+ # Waveshare 13.3" FHD (1920x1080) LCD panel
+ - waveshare,13.3inch-panel
+ # Waveshare 7.0" WSVGA (1024x600) LCD panel
+ - waveshare,7.0inch-c-panel
# Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
- winstar,wf35ltiacd
# Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
- yes-optoelectronics,ytc700tlag-05-201c
- backlight: true
- ddc-i2c-bus: true
- enable-gpios: true
- port: true
- power-supply: true
- no-hpd: true
- hpd-gpios: true
+if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: innolux,g101ice-l01
+then:
+ properties:
+ data-mapping: false
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
@@ -368,3 +370,16 @@ examples:
};
};
};
+ - |
+ panel_lvds: panel-lvds {
+ compatible = "innolux,g101ice-l01";
+ power-supply = <&vcc_lcd_reg>;
+
+ data-mapping = "jeida-24";
+
+ port {
+ panel_in_lvds: endpoint {
+ remote-endpoint = <&ltdc_out_lvds>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
index 229e3b36ee29..8c9774458777 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/panel/panel-timing.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: panel timing bindings
+title: panel timing
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
@@ -17,30 +17,29 @@ description: |
The parameters are defined as seen in the following illustration.
- +----------+-------------------------------------+----------+-------+
- | | ^ | | |
- | | |vback_porch | | |
- | | v | | |
- +----------#######################################----------+-------+
- | # ^ # | |
- | # | # | |
- | hback # | # hfront | hsync |
- | porch # | hactive # porch | len |
- |<-------->#<-------+--------------------------->#<-------->|<----->|
- | # | # | |
- | # |vactive # | |
- | # | # | |
- | # v # | |
- +----------#######################################----------+-------+
- | | ^ | | |
- | | |vfront_porch | | |
- | | v | | |
- +----------+-------------------------------------+----------+-------+
- | | ^ | | |
- | | |vsync_len | | |
- | | v | | |
- +----------+-------------------------------------+----------+-------+
-
+ +-------+----------+-------------------------------------+----------+
+ | | | ^ | |
+ | | | |vsync_len | |
+ | | | v | |
+ +-------+----------+-------------------------------------+----------+
+ | | | ^ | |
+ | | | |vback_porch | |
+ | | | v | |
+ +-------+----------#######################################----------+
+ | | # ^ # |
+ | | # | # |
+ | hsync | hback # | # hfront |
+ | len | porch # | hactive # porch |
+ |<----->|<-------->#<-------+--------------------------->#<-------->|
+ | | # | # |
+ | | # |vactive # |
+ | | # | # |
+ | | # v # |
+ +-------+----------#######################################----------+
+ | | | ^ | |
+ | | | |vfront_porch | |
+ | | | v | |
+ +-------+----------+-------------------------------------+----------+
The following is the panel timings shown with time on the x-axis.
This matches the timing diagrams often found in data sheets.
diff --git a/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml b/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml
new file mode 100644
index 000000000000..b7d74faeb5d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/powertip,hx8238a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Powertip Electronic Technology Co. 320 x 240 LCD panel
+
+maintainers:
+ - Lukasz Majewski <lukma@denx.de>
+
+allOf:
+ - $ref: panel-dpi.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: powertip,hx8238a
+ - {} # panel-dpi, but not listed here to avoid false select
+
+ height-mm: true
+ panel-timing: true
+ port: true
+ power-supply: true
+ width-mm: true
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml b/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml
new file mode 100644
index 000000000000..f3622800f13f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/powertip,st7272.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Powertip Electronic Technology Co. 320 x 240 LCD panel
+
+maintainers:
+ - Lukasz Majewski <lukma@denx.de>
+
+allOf:
+ - $ref: panel-dpi.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: powertip,st7272
+ - {} # panel-dpi, but not listed here to avoid false select
+
+ height-mm: true
+ panel-timing: true
+ port: true
+ power-supply: true
+ width-mm: true
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
index d62fd692bf10..4825792bf712 100644
--- a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
@@ -16,7 +16,9 @@ properties:
compatible:
const: raydium,rm67191
- reg: true
+ reg:
+ maxItems: 1
+
port: true
reset-gpios: true
width-mm: true
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml
new file mode 100644
index 000000000000..97b7fbe05c07
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/raydium,rm67200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raydium RM67200 based MIPI-DSI panels
+
+maintainers:
+ - Sebastian Reichel <sebastian.reichel@collabora.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - wanchanglong,w552793baa
+ - const: raydium,rm67200
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: 2.8V Logic voltage
+
+ iovcc-supply:
+ description: 1.8V IO voltage
+
+ vsp-supply:
+ description: positive 5.5V voltage
+
+ vsn-supply:
+ description: negative 5.5V voltage
+
+ backlight: true
+ port: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - port
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "wanchanglong,w552793baa", "raydium,rm67200";
+ reg = <0>;
+
+ vdd-supply = <&regulator1>;
+ iovcc-supply = <&regulator2>;
+ vsp-supply = <&regulator3>;
+ vsn-supply = <&regulator4>;
+ reset-gpios = <&gpiobank 42 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
index e8ce2315631a..46fe1014ebc4 100644
--- a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/raydium,rm68200.yaml#
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml
new file mode 100644
index 000000000000..7ad223f98253
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml
@@ -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/raydium,rm692e5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raydium RM692E5 based DSI display panels
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The Raydium RM692E5 is a generic DSI Panel IC used to control
+ AMOLED panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: fairphone,fp5-rm692e5-boe
+ - const: raydium,rm692e5
+
+ reg:
+ maxItems: 1
+
+ dvdd-supply:
+ description: Digital voltage rail
+
+ vci-supply:
+ description: Analog voltage rail
+
+ vddio-supply:
+ description: I/O voltage rail
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - dvdd-supply
+ - vci-supply
+ - vddio-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "fairphone,fp5-rm692e5-boe", "raydium,rm692e5";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 44 GPIO_ACTIVE_LOW>;
+ dvdd-supply = <&vreg_oled_vci>;
+ vci-supply = <&vreg_l12c>;
+ vddio-supply = <&vreg_oled_dvdd>;
+
+ port {
+ panel_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
new file mode 100644
index 000000000000..ec445ff5631c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raydium RM69380-based DSI display panels
+
+maintainers:
+ - David Wronek <david@mainlining.org>
+
+description:
+ The Raydium RM69380 is a generic DSI panel IC used to control
+ OLED panels.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - lenovo,j716f-edo-rm69380
+ - const: raydium,rm69380
+ description: This indicates the panel manufacturer of the panel
+ that is in turn using the RM69380 panel driver. The compatible
+ string determines how the RM69380 panel driver shall be configured
+ to work with the indicated panel. The raydium,rm69380 compatible shall
+ always be provided as a fallback.
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog voltage rail
+
+ vddio-supply:
+ description: I/O voltage rail
+
+ reset-gpios:
+ maxItems: 1
+ description: phandle of gpio for reset line - This should be active low
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - vddio-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380";
+ reg = <0>;
+
+ avdd-supply = <&panel_avdd_regulator>;
+ vddio-supply = <&vreg_l14a>;
+ reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ panel_in_0: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel_in_1: endpoint {
+ remote-endpoint = <&mdss_dsi1_out>;
+ };
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml b/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml
new file mode 100644
index 000000000000..90cce221c0d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/renesas,r61307.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R61307 based DSI Display Panel
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ The Renesas R61307 is a generic DSI Panel IC used to control LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # KOE/HITACHI TX13D100VM0EAA 5.0" XGA TFT LCD panel
+ - hit,tx13d100vm0eaa
+ - koe,tx13d100vm0eaa
+ - const: renesas,r61307
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: Regulator for main power supply.
+
+ iovcc-supply:
+ description: Regulator for 1.8V IO power supply.
+
+ backlight: true
+
+ renesas,gamma:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ 0 - disabled
+ 1-3 - gamma setting A presets
+ enum: [0, 1, 2, 3]
+
+ renesas,column-inversion:
+ type: boolean
+ description: switch between line and column inversion. The line
+ inversion is set by default.
+
+ renesas,contrast:
+ type: boolean
+ description: digital contrast adjustment
+
+ reset-gpios: true
+ port: true
+
+required:
+ - compatible
+ - port
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@1 {
+ compatible = "koe,tx13d100vm0eaa", "renesas,r61307";
+ reg = <1>;
+
+ reset-gpios = <&gpio 176 GPIO_ACTIVE_LOW>;
+
+ renesas,gamma = <3>;
+ renesas,column-inversion;
+ renesas,contrast;
+
+ vcc-supply = <&vcc_3v0_lcd>;
+ iovcc-supply = <&iovcc_1v8_lcd>;
+
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml b/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml
new file mode 100644
index 000000000000..1cd219b510ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/renesas,r69328.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R69328 based DSI Display Panel
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ The Renesas R69328 is a generic DSI Panel IC used to control LCD panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # JDI DX12D100VM0EAA 4.7" WXGA TFT LCD panel
+ - jdi,dx12d100vm0eaa
+ - const: renesas,r69328
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator for main power supply.
+
+ vddio-supply:
+ description: Regulator for 1.8V IO power supply.
+
+ backlight: true
+
+ reset-gpios: true
+ port: true
+
+required:
+ - compatible
+ - port
+ - backlight
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@1 {
+ compatible = "jdi,dx12d100vm0eaa", "renesas,r69328";
+ reg = <1>;
+
+ reset-gpios = <&gpio 176 GPIO_ACTIVE_LOW>;
+
+ vdd-supply = <&vdd_3v0_lcd>;
+ vddio-supply = <&vdd_1v8_io>;
+
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
index 09b5eb7542f8..4ae152cc55e0 100644
--- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml#
@@ -20,6 +20,14 @@ allOf:
properties:
compatible:
enum:
+ # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel
+ - anbernic,rg353v-panel-v2
+ # GameForce Chi 3.5" 640x480 TFT LCD panel
+ - gameforce,chi-panel
+ # Powkiddy RGB10MAX3 5.0" 720x1280 TFT LCD panel
+ - powkiddy,rgb10max3-panel
+ # Powkiddy RGB30 3.0" 720x720 TFT LCD panel
+ - powkiddy,rgb30-panel
# Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
- rocktech,jh057n00900
# Xingbangda XBD599 5.99" 720x1440 TFT LCD panel
@@ -39,6 +47,7 @@ properties:
reset-gpios: true
backlight: true
+ rotation: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
index d67617f6f74a..694037301583 100644
--- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
@@ -9,21 +9,20 @@ title: Ronbo RB070D30 DSI Display Panel
maintainers:
- Maxime Ripard <mripard@kernel.org>
+allOf:
+ - $ref: panel-common.yaml#
+
properties:
compatible:
const: ronbo,rb070d30
reg:
- description: MIPI-DSI virtual channel
+ maxItems: 1
power-gpios:
description: GPIO used for the power pin
maxItems: 1
- reset-gpios:
- description: GPIO used for the reset pin
- maxItems: 1
-
shlr-gpios:
description: GPIO used for the shlr pin (horizontal flip)
maxItems: 1
@@ -35,10 +34,6 @@ properties:
vcc-lcd-supply:
description: Power regulator
- backlight:
- description: Backlight used by the panel
- $ref: "/schemas/types.yaml#/definitions/phandle"
-
required:
- compatible
- power-gpios
@@ -47,5 +42,6 @@ required:
- shlr-gpios
- updn-gpios
- vcc-lcd-supply
+ - port
-additionalProperties: false
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml
index ccc482570d6a..e8f9e9d06a29 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml
@@ -33,7 +33,9 @@ properties:
# Samsung S6E3HF2 5.65" 1600x2560 AMOLED panel
- samsung,s6e3hf2
- reg: true
+ reg:
+ maxItems: 1
+
reset-gpios: true
enable-gpios: true
te-gpios: true
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
new file mode 100644
index 000000000000..e081c84a932b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,ams495qa01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung AMS495QA01 panel with Magnachip D53E6EA8966 controller
+
+maintainers:
+ - Chris Morgan <macromorgan@hotmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: samsung,ams495qa01
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description: reset gpio, must be GPIO_ACTIVE_LOW
+ elvdd-supply:
+ description: regulator that supplies voltage to the panel display
+ enable-gpios: true
+ port: true
+ vdd-supply:
+ description: regulator that supplies voltage to panel logic
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "samsung,ams495qa01";
+ reg = <0>;
+ reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&vcc_3v3>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ams581vf01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ams581vf01.yaml
new file mode 100644
index 000000000000..70dff9c0ef2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ams581vf01.yaml
@@ -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>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml
new file mode 100644
index 000000000000..f5b6ecb96f99
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml
@@ -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>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml
new file mode 100644
index 000000000000..f1723e910252
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,atna33xc20.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
+
+maintainers:
+ - Douglas Anderson <dianders@chromium.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
+ - const: samsung,atna33xc20
+ - items:
+ - enum:
+ # Samsung 13" 3K (2880×1920 pixels) eDP AMOLED panel
+ - samsung,atna30dw01
+ # Samsung 14" FHD+ (1920x1200 pixels) eDP AMOLED panel
+ - samsung,atna40ct06
+ # Samsung 14" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
+ - samsung,atna40cu11
+ # Samsung 14" WQXGA+ (2880×1800 pixels) eDP AMOLED panel
+ - samsung,atna40yk20
+ # Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
+ - samsung,atna45af01
+ # Samsung 14.5" 3K (2944x1840 pixels) eDP AMOLED panel
+ - samsung,atna45dc02
+ # Samsung 15.6" 3K (2880x1620 pixels) eDP AMOLED panel
+ - samsung,atna56ac03
+ # Samsung 16.0" 3K (2880x1800 pixels) eDP AMOLED panel
+ - samsung,atna60cl08
+ - const: samsung,atna33xc20
+
+ enable-gpios: true
+ port: true
+ power-supply: true
+ no-hpd: true
+ hpd-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - enable-gpios
+ - power-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2d {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2d>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+
+ enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
+
+ vpll-supply = <&src_pp1800_s4a>;
+ vccio-supply = <&src_pp1800_s4a>;
+ vcca-supply = <&src_pp1200_l2a>;
+ vcc-supply = <&src_pp1200_l2a>;
+
+ clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
+ clock-names = "refclk";
+
+ no-hpd;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ sn65dsi86_out: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+
+ aux-bus {
+ panel {
+ compatible = "samsung,atna33xc20";
+ enable-gpios = <&tlmm 12 GPIO_ACTIVE_HIGH>;
+ power-supply = <&pp3300_dx_edp>;
+ hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&sn65dsi86_out>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
index c0fabeb38628..bc92b16c95b9 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
@@ -17,9 +17,11 @@ properties:
compatible:
const: samsung,ld9040
+ reg:
+ maxItems: 1
+
display-timings: true
port: true
- reg: true
reset-gpios: true
vdd3-supply:
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml
index 251f0c7115aa..7ce8540551f9 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml
@@ -9,20 +9,20 @@ title: Samsung LMS380KF01 display panel
description: The LMS380KF01 is a 480x800 DPI display panel from Samsung Mobile
Displays (SMD) utilizing the WideChips WS2401 display controller. It can be
used with internal or external backlight control.
- The panel must obey the rules for a SPI slave device as specified in
- spi/spi-controller.yaml
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
const: samsung,lms380kf01
- reg: true
+ reg:
+ maxItems: 1
interrupts:
description: provides an optional ESD (electrostatic discharge)
@@ -59,7 +59,7 @@ required:
- spi-cpol
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
index cd62968426fb..9363032883de 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
@@ -14,12 +14,14 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
const: samsung,lms397kf04
- reg: true
+ reg:
+ maxItems: 1
reset-gpios: true
@@ -51,7 +53,7 @@ required:
- spi-cpol
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml
index 66d147496bc3..2af5bc47323f 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d16d0.yaml
@@ -16,8 +16,10 @@ properties:
compatible:
const: samsung,s6d16d0
+ reg:
+ maxItems: 1
+
port: true
- reg: true
reset-gpios: true
vdd1-supply:
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
index 26e3c820a2f7..d74904164719 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml
@@ -7,20 +7,21 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S6D27A1 display panel
description: The S6D27A1 is a 480x800 DPI display panel from Samsung Mobile
- Displays (SMD). The panel must obey the rules for a SPI slave device
- as specified in spi/spi-controller.yaml
+ Displays (SMD).
maintainers:
- Markuss Broks <markuss.broks@gmail.com>
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
const: samsung,s6d27a1
- reg: true
+ reg:
+ maxItems: 1
interrupts:
description: provides an optional ESD (electrostatic discharge)
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
new file mode 100644
index 000000000000..939da65114bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,s6d7aa0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S6D7AA0 MIPI-DSI LCD panel controller
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # 1280x800 LSL080AL02 panel
+ - samsung,lsl080al02
+ # 1024x768 LSL080AL03 panel
+ - samsung,lsl080al03
+ # 1024x768 LTL101AT01 panel
+ - samsung,ltl101at01
+ - const: samsung,s6d7aa0
+
+ reg:
+ maxItems: 1
+
+ backlight:
+ description:
+ Backlight to use for the panel. If this property is set on panels
+ that have DSI-based backlight control (LSL080AL03 and LTL101AT01),
+ it overrides the DSI-based backlight.
+
+ reset-gpios:
+ description: Reset GPIO pin, usually GPIO_ACTIVE_LOW.
+
+ power-supply:
+ description:
+ Main power supply for the panel; the exact voltage differs between
+ panels, and is usually somewhere around 3.3-5v.
+
+ vmipi-supply:
+ description: VMIPI supply, usually 1.8v.
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "samsung,lsl080al02", "samsung,s6d7aa0";
+ reg = <0>;
+ power-supply = <&display_3v3_supply>;
+ reset-gpios = <&gpf0 4 GPIO_ACTIVE_LOW>;
+ backlight = <&backlight>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml
new file mode 100644
index 000000000000..d48354fb52ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,s6e3fc2x01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S6E3FC2X01 AMOLED DDIC
+
+description: The S6E3FC2X01 is display driver IC with connected panel.
+
+maintainers:
+ - David Heidelberg <david@ixit.cz>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # Samsung 6.41 inch, 1080x2340 pixels, 19.5:9 ratio
+ - samsung,s6e3fc2x01-ams641rw
+ - const: samsung,s6e3fc2x01
+
+ reg:
+ maxItems: 1
+
+ reset-gpios: true
+
+ port: true
+
+ vddio-supply:
+ description: VDD regulator
+
+ vci-supply:
+ description: VCI regulator
+
+ poc-supply:
+ description: POC regulator
+
+required:
+ - compatible
+ - reset-gpios
+ - vddio-supply
+ - vci-supply
+ - poc-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "samsung,s6e3fc2x01-ams641rw", "samsung,s6e3fc2x01";
+ reg = <0>;
+
+ vddio-supply = <&vreg_l14a_1p88>;
+ vci-supply = <&s2dos05_buck1>;
+ poc-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>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml
new file mode 100644
index 000000000000..05a78429aaea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml
@@ -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>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml
index 6f1fc7469f07..c47e2a1a30e5 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml
@@ -18,7 +18,9 @@ properties:
compatible:
const: samsung,s6e63m0
- reg: true
+ reg:
+ maxItems: 1
+
reset-gpios: true
port: true
default-brightness: true
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams427ap24.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams427ap24.yaml
new file mode 100644
index 000000000000..db284ba5be20
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams427ap24.yaml
@@ -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>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
index 44ce98f68705..42634fc3b5b2 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
@@ -15,7 +15,11 @@ allOf:
properties:
compatible:
const: samsung,s6e88a0-ams452ef01
- reg: true
+
+ reg:
+ maxItems: 1
+
+ port: true
reset-gpios: true
vdd3-supply:
description: core voltage supply
@@ -25,6 +29,7 @@ properties:
required:
- compatible
- reg
+ - port
- vdd3-supply
- vci-supply
- reset-gpios
@@ -46,5 +51,11 @@ examples:
vdd3-supply = <&pm8916_l17>;
vci-supply = <&reg_vlcd_vci>;
reset-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
index 1cdc91b3439f..19c8cc83db97 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
@@ -16,9 +16,13 @@ properties:
compatible:
const: samsung,s6e8aa0
- reg: true
+ reg:
+ maxItems: 1
+
reset-gpios: true
display-timings: true
+ flip-horizontal: true
+ flip-vertical: true
vdd3-supply:
description: core voltage supply
@@ -44,14 +48,6 @@ properties:
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:
- compatible
- reg
@@ -74,7 +70,7 @@ examples:
vdd3-supply = <&vcclcd_reg>;
vci-supply = <&vlcd_reg>;
reset-gpios = <&gpy4 5 0>;
- power-on-delay= <50>;
+ power-on-delay = <50>;
reset-delay = <100>;
init-delay = <100>;
panel-width-mm = <58>;
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml
new file mode 100644
index 000000000000..eccfc66d7fe2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung AMS561RA01 panel with S6E8AA5X01 controller
+
+maintainers:
+ - Kaustabh Chakraborty <kauschluss@disroot.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: samsung,s6e8aa5x01-ams561ra01
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: core voltage supply
+
+ vci-supply:
+ description: voltage supply for analog circuits
+
+ reset-gpios: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "samsung,s6e8aa5x01-ams561ra01";
+ reg = <0>;
+
+ vdd-supply = <&panel_vdd_reg>;
+ vci-supply = <&panel_vci_reg>;
+
+ reset-gpios = <&gpd3 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml b/Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml
new file mode 100644
index 000000000000..eeee3cac72e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml
@@ -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,sofef00.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SOFEF00 AMOLED DDIC
+
+description: The SOFEF00 is display driver IC with connected panel.
+
+maintainers:
+ - David Heidelberg <david@ixit.cz>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ # Samsung 6.01 inch, 1080x2160 pixels, 18:9 ratio
+ - samsung,sofef00-ams601nt22
+ # Samsung 6.28 inch, 1080x2280 pixels, 19:9 ratio
+ - samsung,sofef00-ams628nw01
+ - const: samsung,sofef00
+
+ reg:
+ maxItems: 1
+
+ poc-supply:
+ description: POC regulator
+
+ vci-supply:
+ description: VCI regulator
+
+ vddio-supply:
+ description: VDD regulator
+
+required:
+ - compatible
+ - reset-gpios
+ - poc-supply
+ - vci-supply
+ - vddio-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "samsung,sofef00-ams628nw01", "samsung,sofef00";
+ reg = <0>;
+
+ vddio-supply = <&vreg_l14a_1p88>;
+ vci-supply = <&s2dos05_buck1>;
+ poc-supply = <&s2dos05_ldo1>;
+
+ te-gpios = <&tlmm 10 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&panel_active>;
+ pinctrl-1 = <&panel_suspend>;
+ pinctrl-names = "default", "sleep";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
index cfaa50cf5f5d..1df3cbb51ff9 100644
--- a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
+++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
maintainers:
- - Marco Franchi <marco.franchi@nxp.com>
+ - Fabio Estevam <festevam@gmail.com>
allOf:
- $ref: panel-common.yaml#
@@ -25,6 +25,8 @@ properties:
avdd-supply:
description: 5v analog regulator
+ enable-gpios: true
+
required:
- compatible
- dvdd-supply
diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
index 2e75e3738ff0..e32d9188a3e0 100644
--- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
@@ -12,7 +12,7 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- - $ref: /schemas/display/lvds.yaml/#
+ - $ref: /schemas/display/lvds.yaml#
select:
properties:
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.yaml b/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.yaml
deleted file mode 100644
index fbb647eb33c9..000000000000
--- a/Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.yaml
+++ /dev/null
@@ -1,30 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/display/panel/sharp,ld-d5116z01b.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Sharp LD-D5116Z01B 12.3" WUXGA+ eDP panel
-
-maintainers:
- - Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
-
-allOf:
- - $ref: panel-common.yaml#
-
-properties:
- compatible:
- const: sharp,ld-d5116z01b
-
- power-supply: true
- backlight: true
- port: true
- no-hpd: true
-
-additionalProperties: false
-
-required:
- - compatible
- - power-supply
-
-...
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml
new file mode 100644
index 000000000000..08a35ebbbb3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sharp,lq079l1sx01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sharp Microelectronics 7.9" WQXGA TFT LCD panel
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description: >
+ This panel requires a dual-channel DSI host to operate and it supports
+ only left-right split mode, where each channel drives the left or right
+ half of the screen and only video mode.
+
+ Each of the DSI channels controls a separate DSI peripheral.
+ The peripheral driven by the first link (DSI-LINK1), left one, is
+ considered the primary peripheral and controls the device.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+ const: sharp,lq079l1sx01
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: regulator that supplies the analog voltage
+
+ vddio-supply:
+ description: regulator that supplies the I/O voltage
+
+ vsp-supply:
+ description: positive boost supply regulator
+
+ vsn-supply:
+ description: negative boost supply regulator
+
+ reset-gpios:
+ maxItems: 1
+
+ backlight: true
+ ports: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - vddio-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "sharp,lq079l1sx01";
+ reg = <0>;
+
+ reset-gpios = <&gpio 59 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&avdd_lcd>;
+ vddio-supply = <&vdd_lcd_io>;
+ vsp-supply = <&vsp_5v5_lcd>;
+ vsn-supply = <&vsn_5v5_lcd>;
+
+ backlight = <&backlight>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ panel_in0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel_in1: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml
index 9ec0e8aae4c6..ce820b96a7e2 100644
--- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml
@@ -34,10 +34,12 @@ properties:
- items:
- const: sharp,lq101r1sx03
- const: sharp,lq101r1sx01
- - items:
- - const: sharp,lq101r1sx01
+ - enum:
+ - sharp,lq101r1sx01
+
+ reg:
+ maxItems: 1
- reg: true
power-supply: true
backlight: true
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml
index a90d0d8bf7c9..b6ea246430ce 100644
--- a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.yaml
@@ -16,7 +16,9 @@ properties:
compatible:
const: sharp,ls043t1le01-qhd
- reg: true
+ reg:
+ maxItems: 1
+
backlight: true
reset-gpios: true
port: true
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml
index 271c097cc9a4..77a4fce129e7 100644
--- a/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml
@@ -16,7 +16,9 @@ properties:
compatible:
const: sharp,ls060t1sx01
- reg: true
+ reg:
+ maxItems: 1
+
backlight: true
reset-gpios: true
port: true
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
index 34d5e20c6cb3..1e434240ea3f 100644
--- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
@@ -20,19 +20,20 @@ description: |
Densitron DMT028VGHMCMI-1A is 480x640, 2-lane MIPI DSI LCD panel
which has built-in ST7701 chip.
-allOf:
- - $ref: panel-common.yaml#
-
properties:
compatible:
items:
- enum:
+ - anbernic,rg-arc-panel
+ - anbernic,rg28xx-panel
- densitron,dmt028vghmcmi-1a
+ - elida,kd50t048a
- techstar,ts8550b
+ - winstar,wf40eswaa6mnn0
- const: sitronix,st7701
reg:
- description: DSI virtual channel used by that screen
+ description: DSI / SPI channel used by that screen
maxItems: 1
VCC-supply:
@@ -41,7 +42,16 @@ properties:
IOVCC-supply:
description: I/O system regulator
+ dc-gpios:
+ maxItems: 1
+ description:
+ Controller data/command selection (D/CX) in 4-line SPI mode.
+ If not set, the controller is in 3-line SPI mode.
+ Disallowed for DSI.
+
+ port: true
reset-gpios: true
+ rotation: true
backlight: true
@@ -50,9 +60,41 @@ required:
- reg
- VCC-supply
- IOVCC-supply
+ - port
- reset-gpios
-additionalProperties: false
+allOf:
+ - $ref: panel-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ # SPI connected panels
+ enum:
+ - anbernic,rg28xx-panel
+ then:
+ $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ # DSI or SPI without D/CX pin
+ enum:
+ - anbernic,rg-arc-panel
+ - anbernic,rg28xx-panel
+ - densitron,dmt028vghmcmi-1a
+ - elida,kd50t048a
+ - techstar,ts8550b
+ then:
+ required:
+ - dc-gpios
+ else:
+ properties:
+ dc-gpios: false
+
+unevaluatedProperties: false
examples:
- |
@@ -69,5 +111,34 @@ examples:
IOVCC-supply = <&reg_dldo2>;
reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
backlight = <&backlight>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "anbernic,rg28xx-panel", "sitronix,st7701";
+ reg = <0>;
+ spi-max-frequency = <3125000>;
+ VCC-supply = <&reg_lcd>;
+ IOVCC-supply = <&reg_lcd>;
+ reset-gpios = <&pio 8 14 GPIO_ACTIVE_HIGH>; /* LCD-RST: PI14 */
+ backlight = <&backlight>;
+
+ port {
+ panel_in_rgb: endpoint {
+ remote-endpoint = <&tcon_lcd0_out_lcd>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
index d984b59daa4a..0ce2ea13583d 100644
--- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
@@ -15,21 +15,35 @@ allOf:
properties:
compatible:
- const: sitronix,st7789v
+ enum:
+ - edt,et028013dma
+ - inanbo,t28cp45tn89-v17
+ - jasonic,jt240mhqs-hwt-ek-e3
+ - sitronix,st7789v
+
+ reg:
+ maxItems: 1
- reg: true
reset-gpios: true
power-supply: true
backlight: true
port: true
+ rotation: true
spi-cpha: true
spi-cpol: true
+ spi-rx-bus-width:
+ minimum: 0
+ maximum: 1
+
+ dc-gpios:
+ maxItems: 1
+ description: DCX pin, Display data/command selection pin in parallel interface
+
required:
- compatible
- reg
- - reset-gpios
- power-supply
unevaluatedProperties: false
@@ -48,6 +62,7 @@ examples:
reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>;
backlight = <&pwm_bl>;
power-supply = <&power>;
+ rotation = <180>;
spi-max-frequency = <100000>;
spi-cpol;
spi-cpha;
diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
index 059cc6dbcfca..fd778a20f760 100644
--- a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
@@ -22,7 +22,10 @@ properties:
enum:
- sony,acx424akp
- sony,acx424akm
- reg: true
+
+ reg:
+ maxItems: 1
+
reset-gpios: true
vddi-supply:
description: regulator that supplies the vddi voltage
diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml
index 98abdf4ddeac..5a8260224b74 100644
--- a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
const: sony,acx565akm
+ reg:
+ maxItems: 1
+
label: true
reset-gpios: true
port: true
diff --git a/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml
new file mode 100644
index 000000000000..032a989184ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sony,td4353-jdi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony TD4353 JDI 5 / 5.7" 2160x1080 MIPI-DSI Panel
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ The Sony TD4353 JDI is a 5 (XZ2c) / 5.7 (XZ2) inch 2160x1080
+ MIPI-DSI panel, used in Xperia XZ2 and XZ2 Compact smartphones.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: sony,td4353-jdi-tama
+
+ reg:
+ maxItems: 1
+
+ backlight: true
+ width-mm: true
+ height-mm: true
+
+ vddio-supply:
+ description: VDDIO 1.8V supply
+
+ vsp-supply:
+ description: Positive 5.5V supply
+
+ vsn-supply:
+ description: Negative 5.5V supply
+
+ panel-reset-gpios:
+ description: Display panel reset pin
+
+ touch-reset-gpios:
+ description: Touch panel reset pin
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - vsp-supply
+ - vsn-supply
+ - panel-reset-gpios
+ - touch-reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel: panel@0 {
+ compatible = "sony,td4353-jdi-tama";
+ reg = <0>;
+
+ backlight = <&pmi8998_wled>;
+ vddio-supply = <&vreg_l14a_1p8>;
+ vsp-supply = <&lab>;
+ vsn-supply = <&ibb>;
+ panel-reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+ touch-reset-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml b/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml
index 967972939598..a58a31349757 100644
--- a/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml
+++ b/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml
@@ -21,7 +21,8 @@ properties:
compatible:
const: sony,tulip-truly-nt35521
- reg: true
+ reg:
+ maxItems: 1
positive5-supply:
description: Positive 5V supply
diff --git a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
new file mode 100644
index 000000000000..d817f998cddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/startek,kd070fhfid015.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Startek Electronic Technology Co. kd070fhfid015 7 inch TFT LCD panel
+
+maintainers:
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: startek,kd070fhfid015
+
+ enable-gpios: true
+
+ iovcc-supply:
+ description: Reference to the regulator powering the panel IO pins.
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ reset-gpios: true
+
+ port: true
+
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - enable-gpios
+ - iovcc-supply
+ - reg
+ - reset-gpios
+ - port
+ - power-supply
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "startek,kd070fhfid015";
+ reg = <0>;
+ enable-gpios = <&pio 67 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 20 GPIO_ACTIVE_HIGH>;
+ iovcc-supply = <&mt6357_vsim1_reg>;
+ power-supply = <&vsys_lcm_reg>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
new file mode 100644
index 000000000000..2fd6e0ec3682
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/synaptics,r63353.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics R63353 based MIPI-DSI panels
+
+maintainers:
+ - Michael Trimarchi <michael@amarulasolutions.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - sharp,ls068b3sx02
+ - const: syna,r63353
+
+ reg:
+ maxItems: 1
+
+ avdd-supply: true
+ dvdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - reset-gpios
+ - port
+ - backlight
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "sharp,ls068b3sx02", "syna,r63353";
+ reg = <0>;
+ avdd-supply = <&avdd_display>;
+ dvdd-supply = <&dvdd_display>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+ backlight = <&backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mipi_dsi_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml
new file mode 100644
index 000000000000..152d94367130
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/synaptics,td4300-panel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics TDDI Display Panel Controller
+
+maintainers:
+ - Kaustabh Chakraborty <kauschluss@disroot.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - syna,td4101-panel
+ - syna,td4300-panel
+
+ reg:
+ maxItems: 1
+
+ vio-supply:
+ description: core I/O voltage supply
+
+ vsn-supply:
+ description: negative voltage supply for analog circuits
+
+ vsp-supply:
+ description: positive voltage supply for analog circuits
+
+ backlight-gpios:
+ maxItems: 1
+ description: backlight enable GPIO
+
+ reset-gpios: true
+ width-mm: true
+ height-mm: true
+ panel-timing: true
+
+required:
+ - compatible
+ - reg
+ - width-mm
+ - height-mm
+ - panel-timing
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "syna,td4300-panel";
+ reg = <0>;
+
+ vio-supply = <&panel_vio_reg>;
+ vsn-supply = <&panel_vsn_reg>;
+ vsp-supply = <&panel_vsp_reg>;
+
+ backlight-gpios = <&gpd3 5 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpd3 4 GPIO_ACTIVE_LOW>;
+
+ width-mm = <68>;
+ height-mm = <121>;
+
+ panel-timing {
+ clock-frequency = <144389520>;
+
+ hactive = <1080>;
+ hsync-len = <4>;
+ hfront-porch = <120>;
+ hback-porch = <32>;
+
+ vactive = <1920>;
+ vsync-len = <2>;
+ vfront-porch = <21>;
+ vback-porch = <4>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
index e8c8ee8d7c88..7edd29df4bbb 100644
--- a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
@@ -22,7 +22,9 @@ properties:
# Toppoly TD043MTEA1 Panel
- tpo,td043mtea1
- reg: true
+ reg:
+ maxItems: 1
+
label: true
reset-gpios: true
backlight: true
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
index 6f1f02044b4b..99db268eb9b3 100644
--- a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
+++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
@@ -38,9 +38,9 @@ description: |+
The serial protocol has line names that resemble I2C but the
protocol is not I2C but 3WIRE SPI.
-
allOf:
- $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
@@ -51,7 +51,8 @@ properties:
- const: tpo,tpg110
- const: tpo,tpg110
- reg: true
+ reg:
+ maxItems: 1
grestb-gpios:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/panel/truly,nt35597-2K-display.yaml b/Documentation/devicetree/bindings/display/panel/truly,nt35597-2K-display.yaml
new file mode 100644
index 000000000000..36be09c900f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/truly,nt35597-2K-display.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/truly,nt35597-2K-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Truly NT35597 DSI 2K display
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ Truly NT35597 DSI 2K display is used on the Qualcomm SDM845 MTP board.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+ const: truly,nt35597-2K-display
+
+ reg:
+ maxItems: 1
+
+ vdda-supply:
+ description: regulator that provides the supply voltage Power IC supply
+
+ vdispp-supply:
+ description: regulator that provides the supply voltage for positive LCD bias
+
+ vdispn-supply:
+ description: regulator that provides the supply voltage for negative LCD bias
+
+ reset-gpios: true
+
+ mode-gpios:
+ description:
+ Gpio for choosing the mode of the display for single DSI or Dual DSI.
+ This should be low for dual DSI and high for single DSI mode.
+
+ ports:
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - vdda-supply
+ - reset-gpios
+ - mode-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "truly,nt35597-2K-display";
+ reg = <0>;
+
+ vdda-supply = <&pm8998_l14>;
+ vdispp-supply = <&lab_regulator>;
+ vdispn-supply = <&ibb_regulator>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+ mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ panel1_in: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,g2647fb105.yaml b/Documentation/devicetree/bindings/display/panel/visionox,g2647fb105.yaml
new file mode 100644
index 000000000000..49dcd9b8f670
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,g2647fb105.yaml
@@ -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/visionox,g2647fb105.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox G2647FB105 6.47" 1080x2340 MIPI-DSI Panel
+
+maintainers:
+ - Alexander Baransky <sanyapilot496@gmail.com>
+
+description:
+ The Visionox G2647FB105 is a 6.47 inch 1080x2340 MIPI-DSI CMD mode OLED panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: visionox,g2647fb105
+
+ 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 = "visionox,g2647fb105";
+ 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>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml
new file mode 100644
index 000000000000..187840bb76c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,r66451.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox R66451 AMOLED DSI Panel
+
+maintainers:
+ - Jessica Zhang <quic_jesszhan@quicinc.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: visionox,r66451
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vddio-supply: true
+ vdd-supply: true
+ port: true
+ reset-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - vdd-supply
+ - reset-gpios
+ - port
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "visionox,r66451";
+ reg = <0>;
+ vddio-supply = <&vreg_l12c_1p8>;
+ vdd-supply = <&vreg_l13c_3p0>;
+
+ reset-gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
index 076b057b4af5..f0a82f0ff790 100644
--- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
+++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml
@@ -1,13 +1,14 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/visionox,rm69299.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Visionox model RM69299 Panels Device Tree Bindings.
+title: Visionox model RM69299 Panels
maintainers:
- - Harigovindan P <harigovi@codeaurora.org>
+ - Abhinav Kumar <quic_abhinavk@quicinc.com>
+ - Jessica Zhang <quic_jesszhan@quicinc.com>
description: |
This binding is for display panels using a Visionox RM692999 panel.
@@ -17,7 +18,12 @@ allOf:
properties:
compatible:
- const: visionox,rm69299-1080p-display
+ enum:
+ - visionox,rm69299-1080p-display
+ - visionox,rm69299-shift
+
+ reg:
+ maxItems: 1
vdda-supply:
description: |
@@ -34,6 +40,7 @@ additionalProperties: false
required:
- compatible
+ - reg
- vdda-supply
- vdd3p3-supply
- reset-gpios
@@ -41,16 +48,22 @@ required:
examples:
- |
- panel {
- compatible = "visionox,rm69299-1080p-display";
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "visionox,rm69299-1080p-display";
+ reg = <0>;
- vdda-supply = <&src_pp1800_l8c>;
- vdd3p3-supply = <&src_pp2800_l18a>;
+ vdda-supply = <&src_pp1800_l8c>;
+ vdd3p3-supply = <&src_pp2800_l18a>;
- reset-gpios = <&pm6150l_gpio 3 0>;
- port {
- panel0_in: endpoint {
- remote-endpoint = <&dsi0_out>;
+ reset-gpios = <&pm6150l_gpio 3 0>;
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml
new file mode 100644
index 000000000000..d4b4672815fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,rm692e5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox RM692E5 6.55" 2400x1080 120Hz MIPI-DSI Panel
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+
+description:
+ The Visionox RM692E5 is a generic DSI Panel IC used to control
+ AMOLED panels.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - visionox,rm692e5
+ - items:
+ - enum:
+ - nothing,rm692e5-spacewar
+ - const: visionox,rm692e5
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: 3.3V source voltage rail
+
+ vddio-supply:
+ description: 1.8V I/O source voltage rail
+
+ reset-gpios: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd-supply
+ - vddio-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "nothing,rm692e5-spacewar",
+ "visionox,rm692e5";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 44 GPIO_ACTIVE_LOW>;
+
+ vdd-supply = <&vdd_oled>;
+ vddio-supply = <&vdd_io_oled>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
new file mode 100644
index 000000000000..d5a8295106c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,vtdr6130.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox VTDR6130 AMOLED DSI Panel
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ const: visionox,vtdr6130
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vddio-supply: true
+ vci-supply: true
+ vdd-supply: true
+ port: true
+ reset-gpios: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - vci-supply
+ - vdd-supply
+ - reset-gpios
+ - port
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+ compatible = "visionox,vtdr6130";
+ reg = <0>;
+
+ vddio-supply = <&vreg_l12b_1p8>;
+ vci-supply = <&vreg_l13b_3p0>;
+ vdd-supply = <&vreg_l11b_1p2>;
+
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
index d5c46a3cc2b0..9c9743a23500 100644
--- a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
+++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml
@@ -15,8 +15,12 @@ allOf:
properties:
compatible:
const: xinpeng,xpp055c272
- reg: true
+
+ reg:
+ maxItems: 1
+
backlight: true
+ port: true
reset-gpios: true
iovcc-supply:
description: regulator that supplies the iovcc voltage
@@ -27,6 +31,7 @@ required:
- compatible
- reg
- backlight
+ - port
- iovcc-supply
- vci-supply
@@ -44,6 +49,12 @@ examples:
backlight = <&backlight>;
iovcc-supply = <&vcc_1v8>;
vci-supply = <&vcc3v3_lcd>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/renesas,cmm.yaml b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
index 561efaaa5a91..fc4933c343cd 100644
--- a/Documentation/devicetree/bindings/display/renesas,cmm.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,cmm.yaml
@@ -58,10 +58,10 @@ examples:
#include <dt-bindings/power/r8a7796-sysc.h>
cmm0: cmm@fea40000 {
- compatible = "renesas,r8a7796-cmm",
- "renesas,rcar-gen3-cmm";
- reg = <0xfea40000 0x1000>;
- power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
- clocks = <&cpg CPG_MOD 711>;
- resets = <&cpg 711>;
+ compatible = "renesas,r8a7796-cmm",
+ "renesas,rcar-gen3-cmm";
+ reg = <0xfea40000 0x1000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 711>;
+ resets = <&cpg 711>;
};
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
index b3e588022082..c27dfea7fc62 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -40,17 +40,33 @@ properties:
- renesas,du-r8a77990 # for R-Car E3 compatible DU
- renesas,du-r8a77995 # for R-Car D3 compatible DU
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
+ - renesas,du-r8a779g0 # for R-Car V4H compatible DU
+ - renesas,du-r8a779h0 # for R-Car V4M compatible DU
reg:
maxItems: 1
# See compatible-specific constraints below.
- clocks: true
- clock-names: true
+ clocks:
+ minItems: 1
+ maxItems: 8
+
+ clock-names:
+ minItems: 1
+ maxItems: 8
+
interrupts:
+ minItems: 1
+ maxItems: 4
description: Interrupt specifiers, one per DU channel
- resets: true
- reset-names: true
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
power-domains:
maxItems: 1
@@ -68,14 +84,12 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
- required:
- - port@0
- - port@1
-
unevaluatedProperties: false
renesas,cmms:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 2
+ maxItems: 4
items:
maxItems: 1
description:
@@ -83,7 +97,9 @@ properties:
available DU channel.
renesas,vsps:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 4
items:
items:
- description: phandle to VSP instance that serves the DU channel
@@ -172,6 +188,7 @@ allOf:
- pattern: '^dclkin\.[01]$'
interrupts:
+ minItems: 2
maxItems: 2
resets:
@@ -227,6 +244,7 @@ allOf:
- pattern: '^dclkin\.[01]$'
interrupts:
+ minItems: 2
maxItems: 2
resets:
@@ -280,6 +298,7 @@ allOf:
- pattern: '^dclkin\.[01]$'
interrupts:
+ minItems: 2
maxItems: 2
resets:
@@ -334,6 +353,7 @@ allOf:
- pattern: '^dclkin\.[01]$'
interrupts:
+ minItems: 2
maxItems: 2
resets:
@@ -395,6 +415,7 @@ allOf:
- pattern: '^dclkin\.[012]$'
interrupts:
+ minItems: 3
maxItems: 3
resets:
@@ -459,9 +480,11 @@ allOf:
- pattern: '^dclkin\.[0123]$'
interrupts:
+ minItems: 4
maxItems: 4
resets:
+ minItems: 2
maxItems: 2
reset-names:
@@ -488,9 +511,11 @@ allOf:
renesas,cmms:
minItems: 4
+ maxItems: 4
renesas,vsps:
minItems: 4
+ maxItems: 4
required:
- clock-names
@@ -530,9 +555,11 @@ allOf:
- pattern: '^dclkin\.[012]$'
interrupts:
+ minItems: 3
maxItems: 3
resets:
+ minItems: 2
maxItems: 2
reset-names:
@@ -557,9 +584,11 @@ allOf:
renesas,cmms:
minItems: 3
+ maxItems: 3
renesas,vsps:
minItems: 3
+ maxItems: 3
required:
- clock-names
@@ -599,9 +628,11 @@ allOf:
- pattern: '^dclkin\.[013]$'
interrupts:
+ minItems: 3
maxItems: 3
resets:
+ minItems: 2
maxItems: 2
reset-names:
@@ -626,9 +657,11 @@ allOf:
renesas,cmms:
minItems: 3
+ maxItems: 3
renesas,vsps:
minItems: 3
+ maxItems: 3
required:
- clock-names
@@ -682,7 +715,7 @@ allOf:
- port@1
renesas,vsps:
- minItems: 1
+ maxItems: 1
required:
- clock-names
@@ -718,6 +751,7 @@ allOf:
- pattern: '^dclkin\.[01]$'
interrupts:
+ minItems: 2
maxItems: 2
resets:
@@ -745,9 +779,11 @@ allOf:
renesas,cmms:
minItems: 2
+ maxItems: 2
renesas,vsps:
minItems: 2
+ maxItems: 2
required:
- clock-names
@@ -762,6 +798,7 @@ allOf:
contains:
enum:
- renesas,du-r8a779a0
+ - renesas,du-r8a779g0
then:
properties:
clocks:
@@ -797,6 +834,54 @@ allOf:
renesas,vsps:
minItems: 2
+ maxItems: 2
+
+ required:
+ - clock-names
+ - interrupts
+ - resets
+ - reset-names
+ - renesas,vsps
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,du-r8a779h0
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Functional clock
+
+ clock-names:
+ items:
+ - const: du.0
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: du.0
+
+ ports:
+ properties:
+ port@0:
+ description: DSI 0
+ port@1: false
+ port@2: false
+ port@3: false
+
+ required:
+ - port@0
+
+ renesas,vsps:
+ maxItems: 1
required:
- clock-names
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
new file mode 100644
index 000000000000..2cc66dcef870
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Display Unit (DU)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+ - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+description: |
+ These DT bindings describe the Display Unit embedded in the Renesas RZ/G2L
+ and RZ/V2L SoCs.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - renesas,r9a07g043u-du # RZ/G2UL
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+ - renesas,r9a09g057-du # RZ/V2H(P)
+ - items:
+ - enum:
+ - renesas,r9a07g054-du # RZ/V2L
+ - const: renesas,r9a07g044-du # RZ/G2L fallback
+ - items:
+ - const: renesas,r9a09g056-du # RZ/V2N
+ - const: renesas,r9a09g057-du # RZ/V2H(P) fallback
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Main clock
+ - description: Register access clock
+ - description: Video clock
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: pclk
+ - const: vclk
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: |
+ The connections to the DU output video ports are modeled using the OF
+ graph bindings. The number of ports and their assignment are
+ model-dependent. Each port shall have a single endpoint.
+
+ patternProperties:
+ "^port@[0-1]$":
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+
+ unevaluatedProperties: false
+
+ renesas,vsps:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle to VSP instance that serves the DU channel
+ - description: Channel index identifying the LIF instance in that VSP
+ description:
+ A list of phandle and channel index tuples to the VSPs that handle the
+ memory interfaces for the DU channels.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - ports
+ - renesas,vsps
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a07g043u-du
+ then:
+ properties:
+ ports:
+ properties:
+ port@0:
+ description: DPI
+
+ required:
+ - port@0
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a07g044-du
+ then:
+ properties:
+ ports:
+ properties:
+ port@0:
+ description: DSI
+ port@1:
+ description: DPI
+
+ required:
+ - port@0
+ - port@1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g057-du
+ then:
+ properties:
+ ports:
+ properties:
+ port@0:
+ description: DSI
+ port@1: false
+
+ required:
+ - port@0
+
+examples:
+ # RZ/G2L DU
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ display@10890000 {
+ compatible = "renesas,r9a07g044-du";
+ reg = <0x10890000 0x10000>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A07G044_LCDC_CLK_A>,
+ <&cpg CPG_MOD R9A07G044_LCDC_CLK_P>,
+ <&cpg CPG_MOD R9A07G044_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ resets = <&cpg R9A07G044_LCDC_RESET_N>;
+ power-domains = <&cpg>;
+
+ renesas,vsps = <&vspd0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&dsi0_in>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/renesas,shmobile-lcdc.yaml b/Documentation/devicetree/bindings/display/renesas,shmobile-lcdc.yaml
new file mode 100644
index 000000000000..9816c4cacc7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,shmobile-lcdc.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,shmobile-lcdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH-Mobile LCD Controller (LCDC)
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+properties:
+ compatible:
+ enum:
+ - renesas,r8a7740-lcdc # R-Mobile A1
+ - renesas,sh73a0-lcdc # SH-Mobile AG5
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+ description:
+ Only the functional clock is mandatory.
+ Some of the optional clocks are model-dependent (e.g. "video" (a.k.a.
+ "vou" or "dv_clk") is available on R-Mobile A1 only).
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: fck
+ - enum: [ media, lclk, hdmi, video ]
+ - enum: [ media, lclk, hdmi, video ]
+ - enum: [ media, lclk, hdmi, video ]
+ - enum: [ media, lclk, hdmi, video ]
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: LCD port (R-Mobile A1 and SH-Mobile AG5)
+ unevaluatedProperties: false
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: HDMI port (R-Mobile A1 LCDC1 and SH-Mobile AG5)
+ unevaluatedProperties: false
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: MIPI-DSI port (SH-Mobile AG5)
+ unevaluatedProperties: false
+
+ required:
+ - port@0
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r8a7740-lcdc
+ then:
+ properties:
+ ports:
+ properties:
+ port@2: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,sh73a0-lcdc
+ then:
+ properties:
+ ports:
+ required:
+ - port@1
+ - port@2
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7740-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ lcd-controller@fe940000 {
+ compatible = "renesas,r8a7740-lcdc";
+ reg = <0xfe940000 0x4000>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp1_clks R8A7740_CLK_LCDC0>,
+ <&cpg_clocks R8A7740_CLK_M3>, <&lcdlclk0_clk>,
+ <&vou_clk>;
+ clock-names = "fck", "media", "lclk", "video";
+ power-domains = <&pd_a4lc>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lcdc0_rgb: endpoint {
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
deleted file mode 100644
index 43561584c13a..000000000000
--- a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-Rockchip RK3288 specific extensions to the Analogix Display Port
-================================
-
-Required properties:
-- compatible: "rockchip,rk3288-dp",
- "rockchip,rk3399-edp";
-
-- reg: physical base address of the controller and length
-
-- clocks: from common clock binding: handle to dp clock.
- of memory mapped region.
-
-- clock-names: from common clock binding:
- Required elements: "dp" "pclk"
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-
-- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
-- pinctrl-0: pin-control mode. should be <&edp_hpd>
-
-- reset-names: Must include the name "dp"
-
-- rockchip,grf: this soc should set GRF regs, so need get grf here.
-
-- ports: there are 2 port nodes with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
- Port 0: contained 2 endpoints, connecting to the output of vop.
- Port 1: contained 1 endpoint, connecting to the input of panel.
-
-Optional property for different chips:
-- clocks: from common clock binding: handle to grf_vio clock.
-
-- clock-names: from common clock binding:
- Required elements: "grf"
-
-For the below properties, please refer to Analogix DP binding document:
- * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
-- phys (required)
-- phy-names (required)
-- hpd-gpios (optional)
-- force-hpd (optional)
--------------------------------------------------------------------------------
-
-Example:
- dp-controller: dp@ff970000 {
- compatible = "rockchip,rk3288-dp";
- reg = <0xff970000 0x4000>;
- interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
- clock-names = "dp", "pclk";
- phys = <&dp_phy>;
- phy-names = "dp";
-
- rockchip,grf = <&grf>;
- resets = <&cru 111>;
- reset-names = "dp";
-
- pinctrl-names = "default";
- pinctrl-0 = <&edp_hpd>;
-
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- edp_in: port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
- edp_in_vopb: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&vopb_out_edp>;
- };
- edp_in_vopl: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&vopl_out_edp>;
- };
- };
-
- edp_out: port@1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
- edp_out_panel: endpoint {
- reg = <0>;
- remote-endpoint = <&panel_in_edp>
- };
- };
- };
- };
-
- pinctrl {
- edp {
- edp_hpd: edp-hpd {
- rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_none>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
deleted file mode 100644
index 8df7d2e393d6..000000000000
--- a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Rockchip RK3399 specific extensions to the cdn Display Port
-================================
-
-Required properties:
-- compatible: must be "rockchip,rk3399-cdn-dp"
-
-- reg: physical base address of the controller and length
-
-- clocks: from common clock binding: handle to dp clock.
-
-- clock-names: from common clock binding:
- Required elements: "core-clk" "pclk" "spdif" "grf"
-
-- resets : a list of phandle + reset specifier pairs
-- reset-names : string of reset names
- Required elements: "apb", "core", "dptx", "spdif"
-- power-domains : power-domain property defined with a phandle
- to respective power domain.
-- assigned-clocks: main clock, should be <&cru SCLK_DP_CORE>
-- assigned-clock-rates : the DP core clk frequency, shall be: 100000000
-
-- rockchip,grf: this soc should set GRF regs, so need get grf here.
-
-- ports: contain a port nodes with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
- contained 2 endpoints, connecting to the output of vop.
-
-- phys: from general PHY binding: the phandle for the PHY device.
-
-- extcon: extcon specifier for the Power Delivery
-
-- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
-
--------------------------------------------------------------------------------
-
-Example:
- cdn_dp: dp@fec00000 {
- compatible = "rockchip,rk3399-cdn-dp";
- reg = <0x0 0xfec00000 0x0 0x100000>;
- interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>,
- <&cru SCLK_SPDIF_REC_DPTX>, <&cru PCLK_VIO_GRF>;
- clock-names = "core-clk", "pclk", "spdif", "grf";
- assigned-clocks = <&cru SCLK_DP_CORE>;
- assigned-clock-rates = <100000000>;
- power-domains = <&power RK3399_PD_HDCP>;
- phys = <&tcphy0_dp>, <&tcphy1_dp>;
- resets = <&cru SRST_DPTX_SPDIF_REC>;
- reset-names = "spdif";
- extcon = <&fusb0>, <&fusb1>;
- rockchip,grf = <&grf>;
- #address-cells = <1>;
- #size-cells = <0>;
- #sound-dai-cells = <1>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- dp_in: port {
- #address-cells = <1>;
- #size-cells = <0>;
- dp_in_vopb: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&vopb_out_dp>;
- };
-
- dp_in_vopl: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&vopl_out_dp>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
deleted file mode 100644
index 9a223df8530c..000000000000
--- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Rockchip specific extensions to the Synopsys Designware MIPI DSI
-================================
-
-Required properties:
-- #address-cells: Should be <1>.
-- #size-cells: Should be <0>.
-- compatible: one of
- "rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi"
- "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"
- "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi"
- "rockchip,rk3568-mipi-dsi", "snps,dw-mipi-dsi"
-- reg: Represent the physical address range of the controller.
-- interrupts: Represent the controller's interrupt to the CPU(s).
-- clocks, clock-names: Phandles to the controller's pll reference
- clock(ref) when using an internal dphy and APB clock(pclk).
- For RK3399, a phy config clock (phy_cfg) and a grf clock(grf)
- are required. As described in [1].
-- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
-- ports: contain a port node with endpoint definitions as defined in [2].
- For vopb,set the reg = <0> and set the reg = <1> for vopl.
-- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
-- video port 1 for either a panel or subsequent encoder
-
-Optional properties:
-- phys: from general PHY binding: the phandle for the PHY device.
-- phy-names: Should be "dphy" if phys references an external phy.
-- #phy-cells: Defined when used as ISP phy, should be 0.
-- power-domains: a phandle to mipi dsi power domain node.
-- resets: list of phandle + reset specifier pairs, as described in [3].
-- reset-names: string reset name, must be "apb".
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/media/video-interfaces.txt
-[3] Documentation/devicetree/bindings/reset/reset.txt
-
-Example:
- mipi_dsi: mipi@ff960000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
- reg = <0xff960000 0x4000>;
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;
- clock-names = "ref", "pclk";
- resets = <&cru SRST_MIPIDSI0>;
- reset-names = "apb";
- rockchip,grf = <&grf>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- mipi_in: port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- mipi_in_vopb: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&vopb_out_mipi>;
- };
- mipi_in_vopl: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&vopl_out_mipi>;
- };
- };
-
- mipi_out: port@1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- mipi_out_panel: endpoint {
- remote-endpoint = <&panel_in_mipi>;
- };
- };
- };
-
- panel {
- compatible ="boe,tv080wum-nl0";
- reg = <0>;
-
- enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&lcd_en>;
- backlight = <&backlight>;
-
- port {
- panel_in_mipi: endpoint {
- remote-endpoint = <&mipi_out_panel>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
deleted file mode 100644
index cec21714f0e0..000000000000
--- a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Rockchip specific extensions to the Innosilicon HDMI
-================================
-
-Required properties:
-- compatible:
- "rockchip,rk3036-inno-hdmi";
-- reg:
- Physical base address and length of the controller's registers.
-- clocks, clock-names:
- Phandle to hdmi controller clock, name should be "pclk"
-- interrupts:
- HDMI interrupt number
-- ports:
- Contain one port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/graph.txt.
-- pinctrl-0, pinctrl-name:
- Switch the iomux of HPD/CEC pins to HDMI function.
-
-Example:
-hdmi: hdmi@20034000 {
- compatible = "rockchip,rk3036-inno-hdmi";
- reg = <0x20034000 0x4000>;
- interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru PCLK_HDMI>;
- clock-names = "pclk";
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_ctl>;
-
- hdmi_in: port {
- #address-cells = <1>;
- #size-cells = <0>;
- hdmi_in_lcdc: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&lcdc_out_hdmi>;
- };
- };
-};
-
-&pinctrl {
- hdmi {
- hdmi_ctl: hdmi-ctl {
- rockchip,pins = <1 8 RK_FUNC_1 &pcfg_pull_none>,
- <1 9 RK_FUNC_1 &pcfg_pull_none>,
- <1 10 RK_FUNC_1 &pcfg_pull_none>,
- <1 11 RK_FUNC_1 &pcfg_pull_none>;
- };
- };
-
-};
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
new file mode 100644
index 000000000000..d99b23b88cc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip specific extensions to the Analogix Display Port
+
+maintainers:
+ - Sandy Huang <hjc@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3288-dp
+ - rockchip,rk3399-edp
+ - rockchip,rk3588-edp
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: dp
+ - const: pclk
+ - const: grf
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: dp
+ - const: apb
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ This SoC makes use of GRF regs.
+
+ aux-bus:
+ $ref: /schemas/display/dp-aux-bus.yaml#
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - rockchip,grf
+
+allOf:
+ - $ref: /schemas/display/bridge/analogix,dp.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3588-edp
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3288-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ dp@ff970000 {
+ compatible = "rockchip,rk3288-dp";
+ reg = <0xff970000 0x4000>;
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+ clock-names = "dp", "pclk";
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ resets = <&cru 111>;
+ reset-names = "dp";
+ rockchip,grf = <&grf>;
+ pinctrl-0 = <&edp_hpd>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_edp>;
+ };
+ edp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_edp>;
+ };
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+
+ edp_out_panel: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
new file mode 100644
index 000000000000..6345f0132d43
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip DW DisplayPort Transmitter
+
+maintainers:
+ - Andy Yan <andy.yan@rock-chips.com>
+
+description: |
+ The Rockchip RK3588 SoC integrates the Synopsys DesignWare DPTX controller
+ which is compliant with the DisplayPort Specification Version 1.4 with the
+ following features:
+
+ * DisplayPort 1.4a
+ * Main Link: 1/2/4 lanes
+ * Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps
+ * AUX channel 1Mbps
+ * Single Stream Transport(SST)
+ * Multistream Transport (MST)
+ * Type-C support (alternate mode)
+ * HDCP 2.2, HDCP 1.3
+ * Supports up to 8/10 bits per color component
+ * Supports RBG, YCbCr4:4:4, YCbCr4:2:2, YCbCr4:2:0
+ * Pixel clock up to 594MHz
+ * I2S, SPDIF audio interface
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3588-dp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral/APB bus clock
+ - description: DisplayPort AUX clock
+ - description: HDCP clock
+ - description: I2S interface clock
+ - description: SPDIF interfce clock
+
+ clock-names:
+ items:
+ - const: apb
+ - const: aux
+ - const: hdcp
+ - const: i2s
+ - const: spdif
+
+ phys:
+ maxItems: 1
+
+ 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 DP output.
+
+ required:
+ - port@0
+ - port@1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - phys
+ - ports
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/phy/phy.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>;
+
+ dp@fde50000 {
+ compatible = "rockchip,rk3588-dp";
+ reg = <0x0 0xfde50000 0x0 0x4000>;
+ interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru PCLK_DP0>, <&cru CLK_AUX16M_0>,
+ <&cru CLK_DP0>, <&cru MCLK_I2S4_8CH_TX>,
+ <&cru MCLK_SPDIF2_DP0>;
+ clock-names = "apb", "aux", "hdcp", "i2s", "spdif";
+ assigned-clocks = <&cru CLK_AUX16M_0>;
+ assigned-clock-rates = <16000000>;
+ resets = <&cru SRST_DP0>;
+ phys = <&usbdp_phy0 PHY_TYPE_DP>;
+ power-domains = <&power RK3588_PD_VO0>;
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dp0_in_vp2: endpoint {
+ remote-endpoint = <&vp2_out_dp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dp0_out_con0: endpoint {
+ remote-endpoint = <&dp_con0_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 7e59dee15a5f..9d096856a79a 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -15,6 +15,7 @@ description: |
allOf:
- $ref: ../bridge/synopsys,dw-hdmi.yaml#
+ - $ref: /schemas/sound/dai-common.yaml#
properties:
compatible:
@@ -69,14 +70,6 @@ properties:
- vpll
- ref
- ddc-i2c-bus:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- The HDMI DDC bus can be connected to either a system I2C master or the
- functionally-reduced I2C master contained in the DWC HDMI. When connected
- to a system I2C master this property contains a phandle to that I2C
- master controller.
-
phys:
maxItems: 1
description: The HDMI PHY
@@ -94,11 +87,14 @@ properties:
- const: default
- const: unwedge
+ power-domains:
+ maxItems: 1
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
- patternProperties:
- "^port(@0)?$":
+ properties:
+ port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Input of the DWC HDMI TX
properties:
@@ -108,16 +104,22 @@ properties:
description: Connection to the VOPB
endpoint@1:
description: Connection to the VOPL
- properties:
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Output of the DWC HDMI TX
+ required:
+ - port@0
+ - port@1
+
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the GRF to mux vopl/vopb.
+ "#sound-dai-cells":
+ const: 0
+
required:
- compatible
- reg
@@ -135,19 +137,26 @@ examples:
#include <dt-bindings/clock/rk3288-cru.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/rk3288-power.h>
hdmi: hdmi@ff980000 {
compatible = "rockchip,rk3288-dw-hdmi";
reg = <0xff980000 0x20000>;
reg-io-width = <4>;
- ddc-i2c-bus = <&i2c5>;
- rockchip,grf = <&grf>;
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
clock-names = "iahb", "isfr";
+ ddc-i2c-bus = <&i2c5>;
+ power-domains = <&power RK3288_PD_VIO>;
+ rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
ports {
- port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
@@ -155,11 +164,20 @@ examples:
reg = <0>;
remote-endpoint = <&vopb_out_hdmi>;
};
+
hdmi_in_vopl: endpoint@1 {
reg = <1>;
remote-endpoint = <&vopl_out_hdmi>;
};
};
+
+ port@1 {
+ reg = <1>;
+
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml
new file mode 100644
index 000000000000..632b48bfabb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-mipi-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip specific extensions to the Synopsys Designware MIPI DSI
+
+maintainers:
+ - Sandy Huang <hjc@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - rockchip,px30-mipi-dsi
+ - rockchip,rk3128-mipi-dsi
+ - rockchip,rk3288-mipi-dsi
+ - rockchip,rk3368-mipi-dsi
+ - rockchip,rk3399-mipi-dsi
+ - rockchip,rk3568-mipi-dsi
+ - rockchip,rv1126-mipi-dsi
+ - const: snps,dw-mipi-dsi
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ oneOf:
+ - minItems: 2
+ items:
+ - const: ref
+ - const: pclk
+ - const: phy_cfg
+ - const: grf
+ - const: pclk
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ This SoC uses GRF regs to switch between vopl/vopb.
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: dphy
+
+ "#phy-cells":
+ const: 0
+ description:
+ Defined when in use as ISP phy.
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - rockchip,grf
+
+allOf:
+ - $ref: /schemas/display/bridge/snps,dw-mipi-dsi.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-mipi-dsi
+ - rockchip,rk3128-mipi-dsi
+ - rockchip,rk3368-mipi-dsi
+ - rockchip,rk3568-mipi-dsi
+ - rockchip,rv1126-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ required:
+ - phys
+ - phy-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3288-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3399-mipi-dsi
+
+ then:
+ properties:
+ clocks:
+ minItems: 4
+
+ clock-names:
+ minItems: 4
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3288-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mipi_dsi: dsi@ff960000 {
+ compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0xff960000 0x4000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>;
+ clock-names = "ref", "pclk";
+ resets = <&cru SRST_MIPIDSI0>;
+ reset-names = "apb";
+ rockchip,grf = <&grf>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_mipi>;
+ };
+ mipi_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_mipi>;
+ };
+ };
+
+ mipi_out: port@1 {
+ reg = <1>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&panel_in_mipi>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
new file mode 100644
index 000000000000..290376bec079
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,inno-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Innosilicon HDMI controller
+
+maintainers:
+ - Sandy Huang <hjc@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3036-inno-hdmi
+ - rockchip,rk3128-inno-hdmi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The HDMI controller main clock
+ - description: The HDMI PHY reference clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: ref
+
+ power-domains:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port node with one endpoint connected to a vop node.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port node with one endpoint connected to a hdmi-connector node.
+
+ required:
+ - port@0
+ - port@1
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to GRF used for control the polarity of hsync/vsync of rk3036
+ HDMI.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - pinctrl-0
+ - pinctrl-names
+ - ports
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3036-inno-hdmi
+
+ then:
+ required:
+ - rockchip,grf
+ properties:
+ power-domains: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3128-inno-hdmi
+
+ then:
+ required:
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3036-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+ hdmi: hdmi@20034000 {
+ compatible = "rockchip,rk3036-inno-hdmi";
+ reg = <0x20034000 0x4000>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru PCLK_HDMI>, <&cru SCLK_LCDC>;
+ clock-names = "pclk", "ref";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_ctl>;
+ rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+ hdmi_in_vop: endpoint {
+ remote-endpoint = <&vop_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port@1 {
+ reg = <1>;
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ hdmi {
+ hdmi_ctl: hdmi-ctl {
+ rockchip,pins = <1 RK_PB0 1 &pcfg_pull_none>,
+ <1 RK_PB1 1 &pcfg_pull_none>,
+ <1 RK_PB2 1 &pcfg_pull_none>,
+ <1 RK_PB3 1 &pcfg_pull_none>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
new file mode 100644
index 000000000000..03b002a05c47
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip low-voltage differential signal (LVDS) transmitter
+
+maintainers:
+ - Sandy Huang <hjc@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,px30-lvds
+ - rockchip,rk3288-lvds
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pclk_lvds
+
+ avdd1v0-supply:
+ description: 1.0V analog power.
+
+ avdd1v8-supply:
+ description: 1.8V analog power.
+
+ avdd3v3-supply:
+ description: 3.3V analog power.
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the general register files syscon.
+
+ rockchip,output:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [rgb, lvds, duallvds]
+ description: This describes the output interface.
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: dphy
+
+ pinctrl-names:
+ const: lcdc
+
+ pinctrl-0: true
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port 0 for the VOP input.
+ The remote endpoint maybe vopb or vopl.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Video port 1 for either a panel or subsequent encoder.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - rockchip,grf
+ - rockchip,output
+ - ports
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,px30-lvds
+
+ then:
+ properties:
+ reg: false
+ clocks: false
+ clock-names: false
+ avdd1v0-supply: false
+ avdd1v8-supply: false
+ avdd3v3-supply: false
+
+ required:
+ - phys
+ - phy-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3288-lvds
+
+ then:
+ properties:
+ phys: false
+ phy-names: false
+
+ required:
+ - reg
+ - clocks
+ - clock-names
+ - avdd1v0-supply
+ - avdd1v8-supply
+ - avdd3v3-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3288-cru.h>
+
+ lvds: lvds@ff96c000 {
+ compatible = "rockchip,rk3288-lvds";
+ reg = <0xff96c000 0x4000>;
+ clocks = <&cru PCLK_LVDS_PHY>;
+ clock-names = "pclk_lvds";
+ avdd1v0-supply = <&vdd10_lcd>;
+ avdd1v8-supply = <&vcc18_lcd>;
+ avdd3v3-supply = <&vcca_33>;
+ pinctrl-names = "lcdc";
+ pinctrl-0 = <&lcdc_ctl>;
+ rockchip,grf = <&grf>;
+ rockchip,output = "rgb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_lvds>;
+ };
+ lvds_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_lvds>;
+ };
+ };
+
+ lvds_out: port@1 {
+ reg = <1>;
+
+ lvds_out_panel: endpoint {
+ remote-endpoint = <&panel_in_lvds>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
index 1a68a940d165..6d4b78a36576 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -10,6 +10,9 @@ maintainers:
- Sandy Huang <hjc@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
properties:
compatible:
const: rockchip,rk3066-hdmi
@@ -34,6 +37,9 @@ properties:
description:
This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1.
+ "#sound-dai-cells":
+ const: 0
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -83,6 +89,7 @@ examples:
pinctrl-names = "default";
power-domains = <&power RK3066_PD_VIO>;
rockchip,grf = <&grf>;
+ #sound-dai-cells = <0>;
ports {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
new file mode 100644
index 000000000000..1a33128e77f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3399-cdn-dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3399 specific extensions to the CDN Display Port
+
+maintainers:
+ - Andy Yan <andy.yan@rock-chip.com>
+ - Heiko Stuebner <heiko@sntech.de>
+ - Sandy Huang <hjc@rock-chips.com>
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: rockchip,rk3399-cdn-dp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: DP core work clock
+ - description: APB clock
+ - description: SPDIF interface clock
+ - description: GRF clock
+
+ clock-names:
+ items:
+ - const: core-clk
+ - const: pclk
+ - const: spdif
+ - const: grf
+
+ extcon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ items:
+ - description: Extcon device providing the cable state for DP PHY device 0
+ - description: Extcon device providing the cable state for DP PHY device 1
+ description:
+ List of phandle to the extcon device providing the cable state for the DP PHY.
+
+ interrupts:
+ maxItems: 1
+
+ phys:
+ minItems: 1
+ items:
+ - description: DP output to the DP PHY device 0
+ - description: DP output to the DP PHY device 1
+ description:
+ RK3399 have two DP-USB PHY, specifying one PHY which want to use, or
+ specify two PHYs here to let the driver determine which PHY to use.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input of the CDN DP
+
+ properties:
+ endpoint@0:
+ description: Connection to the VOPB
+
+ endpoint@1:
+ description: Connection to the VOPL
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output of the CDN DP
+
+ required:
+ - port@0
+ - port@1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: spdif
+ - const: dptx
+ - const: apb
+ - const: core
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to GRF register to control HPD.
+
+ "#sound-dai-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - phys
+ - ports
+ - resets
+ - reset-names
+ - rockchip,grf
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/rk3399-power.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dp@fec00000 {
+ compatible = "rockchip,rk3399-cdn-dp";
+ reg = <0x0 0xfec00000 0x0 0x100000>;
+ assigned-clocks = <&cru SCLK_DP_CORE>;
+ assigned-clock-rates = <100000000>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>, <&cru SCLK_SPDIF_REC_DPTX>,
+ <&cru PCLK_VIO_GRF>;
+ clock-names = "core-clk", "pclk", "spdif", "grf";
+ power-domains = <&power RK3399_PD_HDCP>;
+ phys = <&tcphy0_dp>, <&tcphy1_dp>;
+ resets = <&cru SRST_DPTX_SPDIF_REC>, <&cru SRST_P_UPHY0_DPTX>,
+ <&cru SRST_P_UPHY0_APB>, <&cru SRST_DP_CORE>;
+ reset-names = "spdif", "dptx", "apb", "core";
+ rockchip,grf = <&grf>;
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dp_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dp_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_dp>;
+ };
+
+ dp_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_dp>;
+ };
+ };
+
+ dp_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml
new file mode 100644
index 000000000000..d649808c59da
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml
@@ -0,0 +1,200 @@
+# 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,rk3576-dw-hdmi-qp
+ - 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.
+
+ frl-enable-gpios:
+ description:
+ Optional GPIO line to be asserted when operating in HDMI 2.1 FRL mode and
+ deasserted for HDMI 1.4/2.0 TMDS. It can be used to control external
+ voltage bias for HDMI data lines. When not present the HDMI encoder will
+ operate in TMDS mode only.
+ maxItems: 1
+
+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/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/pinctrl/rockchip.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 = <&hdptxphy0>;
+ 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>;
+ frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
+
+ 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>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml
new file mode 100644
index 000000000000..75cd1c13fa52
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip specific extensions to the Synopsys Designware MIPI DSI2
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3576-mipi-dsi2
+ - rockchip,rk3588-mipi-dsi2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: sys
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ This SoC uses GRF regs to switch between vopl/vopb.
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: dcphy
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: apb
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input node to receive pixel data.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI output node to panel.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - rockchip,grf
+ - phys
+ - phy-names
+ - ports
+ - reg
+
+allOf:
+ - $ref: /schemas/display/dsi-controller.yaml#
+
+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/phy/phy.h>
+ #include <dt-bindings/power/rk3588-power.h>
+ #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dsi@fde20000 {
+ compatible = "rockchip,rk3588-mipi-dsi2";
+ reg = <0x0 0xfde20000 0x0 0x10000>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru PCLK_DSIHOST0>, <&cru CLK_DSIHOST0>;
+ clock-names = "pclk", "sys";
+ resets = <&cru SRST_P_DSIHOST0>;
+ reset-names = "apb";
+ power-domains = <&power RK3588_PD_VOP>;
+ phys = <&mipidcphy0 PHY_TYPE_DPHY>;
+ phy-names = "dcphy";
+ rockchip,grf = <&vop_grf>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dsi0_in: port@0 {
+ reg = <0>;
+ };
+
+ dsi0_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
deleted file mode 100644
index aaf8c44cf90f..000000000000
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Rockchip RK3288 LVDS interface
-================================
-
-Required properties:
-- compatible: matching the soc type, one of
- - "rockchip,rk3288-lvds";
- - "rockchip,px30-lvds";
-
-- reg: physical base address of the controller and length
- of memory mapped region.
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-- clock-names: must contain "pclk_lvds"
-
-- avdd1v0-supply: regulator phandle for 1.0V analog power
-- avdd1v8-supply: regulator phandle for 1.8V analog power
-- avdd3v3-supply: regulator phandle for 3.3V analog power
-
-- rockchip,grf: phandle to the general register files syscon
-- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output interface
-
-- phys: LVDS/DSI DPHY (px30 only)
-- phy-names: name of the PHY, must be "dphy" (px30 only)
-
-Optional properties:
-- pinctrl-names: must contain a "lcdc" entry.
-- pinctrl-0: pin control group to be used for this controller.
-
-Required nodes:
-
-The lvds has two video ports as described by
- Documentation/devicetree/bindings/media/video-interfaces.txt
-Their connections are modeled using the OF graph bindings specified in
- Documentation/devicetree/bindings/graph.txt.
-
-- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
-- video port 1 for either a panel or subsequent encoder
-
-Example:
-
-lvds_panel: lvds-panel {
- compatible = "auo,b101ean01";
- enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
- data-mapping = "jeida-24";
-
- ports {
- panel_in_lvds: endpoint {
- remote-endpoint = <&lvds_out_panel>;
- };
- };
-};
-
-For Rockchip RK3288:
-
- lvds: lvds@ff96c000 {
- compatible = "rockchip,rk3288-lvds";
- rockchip,grf = <&grf>;
- reg = <0xff96c000 0x4000>;
- clocks = <&cru PCLK_LVDS_PHY>;
- clock-names = "pclk_lvds";
- pinctrl-names = "lcdc";
- pinctrl-0 = <&lcdc_ctl>;
- avdd1v0-supply = <&vdd10_lcd>;
- avdd1v8-supply = <&vcc18_lcd>;
- avdd3v3-supply = <&vcca_33>;
- rockchip,output = "rgb";
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- lvds_in: port@0 {
- reg = <0>;
-
- lvds_in_vopb: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&vopb_out_lvds>;
- };
- lvds_in_vopl: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&vopl_out_lvds>;
- };
- };
-
- lvds_out: port@1 {
- reg = <1>;
-
- lvds_out_panel: endpoint {
- remote-endpoint = <&panel_in_lvds>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
index 6f43d885c9b3..8b5f58103dda 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -31,6 +31,7 @@ properties:
- rockchip,rk3368-vop
- rockchip,rk3399-vop-big
- rockchip,rk3399-vop-lit
+ - rockchip,rv1126-vop
reg:
minItems: 1
@@ -72,12 +73,6 @@ properties:
port:
$ref: /schemas/graph.yaml#/properties/port
- assigned-clocks:
- maxItems: 2
-
- assigned-clock-rates:
- maxItems: 2
-
iommus:
maxItems: 1
@@ -121,11 +116,11 @@ examples:
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
- remote-endpoint=<&edp_in_vopb>;
+ remote-endpoint = <&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
- remote-endpoint=<&hdmi_in_vopb>;
+ remote-endpoint = <&hdmi_in_vopb>;
};
};
};
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
index fba45091d909..93da1fb9adc4 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#
@@ -8,18 +8,21 @@ title: Rockchip SoC display controller (VOP2)
description:
VOP2 (Video Output Processor v2) is the display controller for the Rockchip
- series of SoCs which transfers the image data from a video memory
- buffer to an external LCD interface.
+ series of SoCs which transfers the image data from a video memory buffer to
+ an external LCD interface.
maintainers:
- Sandy Huang <hjc@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
+ - Andy Yan <andyshrk@163.com>
properties:
compatible:
enum:
- rockchip,rk3566-vop
- rockchip,rk3568-vop
+ - rockchip,rk3576-vop
+ - rockchip,rk3588-vop
reg:
items:
@@ -27,8 +30,8 @@ properties:
Must contain one entry corresponding to the base address and length
of the register space.
- description:
- Can optionally contain a second entry corresponding to
- the CRTC gamma LUT address.
+ Can optionally contain a second entry corresponding to the CRTC gamma
+ LUT address.
reg-names:
items:
@@ -36,50 +39,83 @@ properties:
- const: gamma-lut
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
description:
- The VOP interrupt is shared by several interrupt sources, such as
- frame start (VSYNC), line flag and other status interrupts.
+ For VOP version under rk3576, the interrupt is shared by several interrupt
+ sources, such as frame start (VSYNC), line flag and other interrupt status.
+ For VOP version from rk3576 there is a system interrupt for bus error, and
+ every video port has it's independent interrupts for vsync and other video
+ port related error interrupts.
+
+ interrupt-names:
+ items:
+ - const: sys
+ - const: vp0
+ - const: vp1
+ - const: vp2
+ # See compatible-specific constraints below.
clocks:
+ minItems: 5
items:
- - description: Clock for ddr buffer transfer.
- - description: Clock for the ahb bus to R/W the phy regs.
+ - description: Clock for ddr buffer transfer via axi.
+ - description: Clock for the ahb bus to R/W the regs.
- description: Pixel clock for video port 0.
- description: Pixel clock for video port 1.
- description: Pixel clock for video port 2.
+ - {}
+ - {}
+ - {}
+ - {}
clock-names:
+ minItems: 5
items:
- const: aclk
- const: hclk
- const: dclk_vp0
- const: dclk_vp1
- const: dclk_vp2
+ - {}
+ - {}
+ - {}
+ - {}
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
- Phandle to GRF regs used for misc control
+ Phandle to GRF regs used for control the polarity of dclk/hsync/vsync of DPI,
+ also used for query vop memory bisr enable status, etc.
+
+ rockchip,vo1-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to VO GRF regs used for control the polarity of dclk/hsync/vsync of hdmi
+ on rk3588.
+
+ rockchip,vop-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to VOP GRF regs used for control data path between vopr and hdmi/edp.
+
+ rockchip,pmu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to PMU GRF used for query vop memory bisr status on rk3588.
ports:
$ref: /schemas/graph.yaml#/properties/ports
- properties:
- port@0:
+ patternProperties:
+ "^port@[0-3]$":
$ref: /schemas/graph.yaml#/properties/port
- description:
- Output endpoint of VP0
+ description: Output endpoint of VP0/1/2/3.
- port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description:
- Output endpoint of VP1
+ required:
+ - port@0
- port@2:
- $ref: /schemas/graph.yaml#/properties/port
- description:
- Output endpoint of VP2
+ unevaluatedProperties: false
iommus:
maxItems: 1
@@ -96,6 +132,138 @@ required:
- clock-names
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3566-vop
+ - rockchip,rk3568-vop
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+
+ clock-names:
+ maxItems: 5
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names: false
+
+ ports:
+ required:
+ - port@0
+ - port@1
+ - port@2
+
+ rockchip,vo1-grf: false
+ rockchip,vop-grf: false
+ rockchip,pmu: false
+
+ required:
+ - rockchip,grf
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-vop
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ items:
+ - {}
+ - {}
+ - {}
+ - {}
+ - {}
+ - description: Alternative pixel clock provided by HDMI PHY PLL.
+
+ clock-names:
+ minItems: 5
+ items:
+ - {}
+ - {}
+ - {}
+ - {}
+ - {}
+ - const: pll_hdmiphy0
+
+ interrupts:
+ minItems: 4
+
+ interrupt-names:
+ minItems: 4
+
+ ports:
+ required:
+ - port@0
+ - port@1
+ - port@2
+
+ rockchip,vo1-grf: false
+ rockchip,vop-grf: false
+
+ required:
+ - rockchip,grf
+ - rockchip,pmu
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-vop
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ items:
+ - {}
+ - {}
+ - {}
+ - {}
+ - {}
+ - description: Pixel clock for video port 3.
+ - description: Peripheral(vop grf/dsi) clock.
+ - description: Alternative pixel clock provided by HDMI0 PHY PLL.
+ - description: Alternative pixel clock provided by HDMI1 PHY PLL.
+
+ clock-names:
+ minItems: 7
+ items:
+ - {}
+ - {}
+ - {}
+ - {}
+ - {}
+ - const: dclk_vp3
+ - const: pclk_vop
+ - const: pll_hdmiphy0
+ - const: pll_hdmiphy1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names: false
+
+ ports:
+ required:
+ - port@0
+ - port@1
+ - port@2
+ - port@3
+
+ required:
+ - rockchip,grf
+ - rockchip,vo1-grf
+ - rockchip,vop-grf
+ - rockchip,pmu
+
additionalProperties: false
examples:
@@ -122,6 +290,7 @@ examples:
"dclk_vp1",
"dclk_vp2";
power-domains = <&power RK3568_PD_VO>;
+ rockchip,grf = <&grf>;
iommus = <&vop_mmu>;
vop_out: ports {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
index 25d53fde92e1..597c9cc6a312 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml
@@ -85,7 +85,7 @@ allOf:
clocks:
minItems: 6
maxItems: 6
- regs:
+ reg:
minItems: 2
maxItems: 2
@@ -99,7 +99,7 @@ allOf:
clocks:
minItems: 4
maxItems: 4
- regs:
+ reg:
minItems: 2
maxItems: 2
@@ -116,7 +116,7 @@ allOf:
clocks:
minItems: 3
maxItems: 3
- regs:
+ reg:
minItems: 1
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml
new file mode 100644
index 000000000000..dda9097a7911
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml
@@ -0,0 +1,163 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/samsung/samsung,exynos5-dp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos5250/Exynos5420 SoC Display Port
+
+maintainers:
+ - Inki Dae <inki.dae@samsung.com>
+ - Seung-Woo Kim <sw0312.kim@samsung.com>
+ - Kyungmin Park <kyungmin.park@samsung.com>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ const: samsung,exynos5-dp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: dp
+
+ display-timings:
+ $ref: /schemas/display/panel/display-timings.yaml#
+
+ interrupts:
+ maxItems: 1
+
+ hpd-gpios:
+ description:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: dp
+
+ power-domains:
+ maxItems: 1
+
+ interlaced:
+ type: boolean
+ deprecated: true
+ description:
+ Interlace scan mode. Progressive if defined, interlaced if not defined.
+
+ vsync-active-high:
+ type: boolean
+ deprecated: true
+ description:
+ VSYNC polarity configuration. High if defined, low if not defined
+
+ hsync-active-high:
+ type: boolean
+ deprecated: true
+ description:
+ HSYNC polarity configuration. High if defined, low if not defined
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port node with one endpoint connected to a dp-connector node.
+
+ required:
+ - port
+
+ samsung,hpd-gpios:
+ maxItems: 1
+ deprecated: true
+
+ samsung,ycbcr-coeff:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Deprecated prop that can parsed from drm_display_mode.
+
+ samsung,dynamic-range:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Deprecated prop that can parsed from drm_display_mode.
+
+ samsung,color-space:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Deprecated prop that can parsed from drm_display_info.
+
+ samsung,color-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Deprecated prop that can parsed from drm_display_info.
+
+ samsung,link-rate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Deprecated prop that can reading from monitor by dpcd method.
+
+ samsung,lane-count:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Deprecated prop that can reading from monitor by dpcd method.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - phys
+ - phy-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos5250.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ dp-controller@145b0000 {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b0000 0x1000>;
+ clocks = <&clock CLK_DP>;
+ clock-names = "dp";
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ pinctrl-0 = <&dp_hpd>;
+ pinctrl-names = "default";
+ power-domains = <&pd_disp1>;
+
+ samsung,color-space = <0>;
+ samsung,color-depth = <1>;
+ samsung,link-rate = <0x0a>;
+ samsung,lane-count = <2>;
+ hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ port {
+ dp_out: endpoint {
+ remote-endpoint = <&bridge_in>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml
index 921bfe925cd6..6380eeebb073 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml
@@ -24,7 +24,6 @@ properties:
- samsung,exynos5433-decon-tv
clocks:
- minItems: 11
maxItems: 11
clock-names:
@@ -59,7 +58,6 @@ properties:
- const: te
iommus:
- minItems: 2
maxItems: 2
iommu-names:
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml
index 7d405f2febcd..26e5017737a3 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml
@@ -24,7 +24,6 @@ properties:
const: samsung,exynos5433-mic
clocks:
- minItems: 2
maxItems: 2
clock-names:
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
index 969bd8c563a5..14b954718008 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
@@ -19,10 +19,11 @@ description: |
properties:
compatible:
- const: samsung,exynos7-decon
+ enum:
+ - samsung,exynos7-decon
+ - samsung,exynos7870-decon
clocks:
- minItems: 4
maxItems: 4
clock-names:
@@ -37,6 +38,7 @@ properties:
i80-if-timings:
type: object
+ additionalProperties: false
description: timing configuration for lcd i80 interface support
properties:
cs-setup:
@@ -78,6 +80,21 @@ properties:
- const: vsync
- const: lcd_sys
+ iommus:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+ description:
+ A phandle to a node describing a reserved framebuffer memory region.
+ For example, the splash memory region set up by the bootloader.
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port which is connected to either a Mobile Image Compressor
+ (MIC) or a DSI Master device.
+
power-domains:
maxItems: 1
@@ -90,6 +107,7 @@ required:
- clock-names
- interrupts
- interrupt-names
+ - port
- reg
additionalProperties: false
@@ -116,4 +134,9 @@ examples:
"decon0_vclk";
pinctrl-0 = <&lcd_clk &pwm1_out>;
pinctrl-names = "default";
+ port {
+ decon_to_dsi: endpoint {
+ remote-endpoint = <&dsi_to_decon>;
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
index 5d5cc220f78a..ff685031bb2c 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
@@ -15,7 +15,6 @@ maintainers:
properties:
compatible:
enum:
- - samsung,s3c2443-fimd
- samsung,s3c6400-fimd
- samsung,s5pv210-fimd
- samsung,exynos3250-fimd
@@ -27,7 +26,6 @@ properties:
const: 1
clocks:
- minItems: 2
maxItems: 2
clock-names:
@@ -40,6 +38,7 @@ properties:
i80-if-timings:
type: object
+ additionalProperties: false
description: |
Timing configuration for lcd i80 interface support.
The parameters are defined as::
diff --git a/Documentation/devicetree/bindings/display/sharp,ls010b7dh04.yaml b/Documentation/devicetree/bindings/display/sharp,ls010b7dh04.yaml
new file mode 100644
index 000000000000..8097f091c2a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sharp,ls010b7dh04.yaml
@@ -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";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
index 1f905d85dd9c..45ffdebc9d86 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/simple-framebuffer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Simple Framebuffer Device Tree Bindings
+title: Simple Framebuffer
maintainers:
- Hans de Goede <hdegoede@redhat.com>
@@ -26,6 +26,11 @@ description: |+
over control to a driver for the real hardware. The bindings for the
hw nodes must specify which node is considered the primary node.
+ If a panel node is given, then the driver uses this to configure the
+ physical width and height of the display. If no panel node is given,
+ then the driver uses the width and height properties of the simplefb
+ node to estimate it.
+
It is advised to add display# aliases to help the OS determine how
to number things. If display# aliases are used, then if the simplefb
node contains a display property then the /aliases/display# path
@@ -63,6 +68,11 @@ properties:
reg:
description: Location and size of the framebuffer memory
+ memory-region:
+ maxItems: 1
+ description: Phandle to a node describing the memory to be used for the
+ framebuffer. If present, overrides the "reg" property (if one exists).
+
clocks:
description: List of clocks used by the framebuffer.
@@ -94,6 +104,7 @@ properties:
* `x1r5g5b5` - 16-bit pixels, d[14:10]=r, d[9:5]=g, d[4:0]=b
* `x2r10g10b10` - 32-bit pixels, d[29:20]=r, d[19:10]=g, d[9:0]=b
* `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
+ * `x8b8g8r8` - 32-bit pixels, d[23:16]=b, d[15:8]=g, d[7:0]=r
enum:
- a1r5g5b5
- a2r10g10b10
@@ -105,11 +116,16 @@ properties:
- x1r5g5b5
- x2r10g10b10
- x8r8g8b8
+ - x8b8g8r8
display:
$ref: /schemas/types.yaml#/definitions/phandle
description: Primary display hardware node
+ panel:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Display panel node
+
allwinner,pipeline:
description: Pipeline used by the framebuffer on Allwinner SoCs
enum:
@@ -165,7 +181,6 @@ allOf:
required:
- amlogic,pipeline
-
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7567.yaml b/Documentation/devicetree/bindings/display/sitronix,st7567.yaml
new file mode 100644
index 000000000000..2eb6d00b5a25
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7567.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sitronix,st7567.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7567 Display Controller
+
+maintainers:
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+description:
+ Sitronix ST7567 is a driver and controller for monochrome
+ dot matrix LCD panels.
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+
+properties:
+ compatible:
+ const: sitronix,st7567
+
+ reg:
+ maxItems: 1
+
+ sitronix,inverted:
+ type: boolean
+ description:
+ Display pixels are inverted, i.e. 0 is white and 1 is black.
+
+ width-mm: true
+ height-mm: true
+ panel-timing: true
+
+required:
+ - compatible
+ - reg
+ - width-mm
+ - height-mm
+ - panel-timing
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display@3f {
+ compatible = "sitronix,st7567";
+ reg = <0x3f>;
+ width-mm = <37>;
+ height-mm = <27>;
+
+ panel-timing {
+ hactive = <128>;
+ vactive = <64>;
+ hback-porch = <0>;
+ vback-porch = <0>;
+ clock-frequency = <0>;
+ hfront-porch = <0>;
+ hsync-len = <0>;
+ vfront-porch = <0>;
+ vsync-len = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7571.yaml b/Documentation/devicetree/bindings/display/sitronix,st7571.yaml
new file mode 100644
index 000000000000..b83721eb4b7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7571.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sitronix,st7571.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7571 Display Controller
+
+maintainers:
+ - Marcus Folkesson <marcus.folkesson@gmail.com>
+
+description:
+ Sitronix ST7571 is a driver and controller for 4-level gray
+ scale and monochrome dot matrix LCD panels.
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+
+properties:
+ compatible:
+ const: sitronix,st7571
+
+ reg:
+ maxItems: 1
+
+ sitronix,grayscale:
+ type: boolean
+ description:
+ Display supports 4-level grayscale.
+
+ sitronix,inverted:
+ type: boolean
+ description:
+ Display pixels are inverted, i.e. 0 is white and 1 is black.
+
+ reset-gpios: true
+ width-mm: true
+ height-mm: true
+ panel-timing: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - width-mm
+ - height-mm
+ - panel-timing
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display@3f {
+ compatible = "sitronix,st7571";
+ reg = <0x3f>;
+ reset-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+ width-mm = <37>;
+ height-mm = <27>;
+
+ panel-timing {
+ hactive = <128>;
+ vactive = <96>;
+ hback-porch = <0>;
+ vback-porch = <0>;
+ clock-frequency = <0>;
+ hfront-porch = <0>;
+ hsync-len = <0>;
+ vfront-porch = <0>;
+ vsync-len = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7586.txt b/Documentation/devicetree/bindings/display/sitronix,st7586.txt
deleted file mode 100644
index 1d0dad1210d3..000000000000
--- a/Documentation/devicetree/bindings/display/sitronix,st7586.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Sitronix ST7586 display panel
-
-Required properties:
-- compatible: "lego,ev3-lcd".
-- a0-gpios: The A0 signal (since this binding is for serial mode, this is
- the pin labeled D1 on the controller, not the pin labeled A0)
-- reset-gpios: Reset pin
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in ../spi/spi-bus.txt must be specified.
-
-Optional properties:
-- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
-
-Example:
- display@0{
- compatible = "lego,ev3-lcd";
- reg = <0>;
- spi-max-frequency = <10000000>;
- a0-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7586.yaml b/Documentation/devicetree/bindings/display/sitronix,st7586.yaml
new file mode 100644
index 000000000000..566aaf1aeac8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7586.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sitronix,st7586.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7586 Display Controller
+
+maintainers:
+ - David Lechner <david@lechnology.com>
+
+description:
+ Sitronix ST7586 is a driver and controller for 4-level gray
+ scale and monochrome dot matrix LCD panels.
+ https://topwaydisplay.com/sites/default/files/2020-04/ST7586S.pdf
+
+$ref: panel/panel-common.yaml#
+
+additionalProperties: false
+
+properties:
+ compatible:
+ const: lego,ev3-lcd
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 50000000
+
+ a0-gpios:
+ description:
+ The A0 signal (for serial mode, this is the pin labeled D1 on the
+ controller, not the pin labeled A0)
+ maxItems: 1
+
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - a0-gpios
+ - reset-gpios
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display@0 {
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ a0-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
index 53f181ef3670..3b0ebc0db8e0 100644
--- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/display/sitronix,st7735r.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Sitronix ST7735R Display Panels Device Tree Bindings
+title: Sitronix ST7735R Display Panels
maintainers:
- David Lechner <david@lechnology.com>
@@ -54,11 +54,6 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- backlight: backlight {
- compatible = "gpio-backlight";
- gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
- };
-
spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml b/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
new file mode 100644
index 000000000000..3e6998481a75
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for Solomon OLED Display Controllers
+
+maintainers:
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+properties:
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ # Only required for SPI
+ dc-gpios:
+ description:
+ GPIO connected to the controller's D/C# (Data/Command) pin,
+ that is needed for 4-wire SPI to tell the controller if the
+ data sent is for a command register or the display data RAM
+ maxItems: 1
+
+ solomon,height:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Height in pixel of the screen driven by the controller.
+ The default value is controller-dependent.
+
+ solomon,width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Width in pixel of the screen driven by the controller.
+ The default value is controller-dependent.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index 669f70b1b4c4..153ff86fb405 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -14,53 +14,25 @@ properties:
compatible:
oneOf:
# Deprecated compatible strings
- - items:
- - enum:
- - solomon,ssd1305fb-i2c
- - solomon,ssd1306fb-i2c
- - solomon,ssd1307fb-i2c
- - solomon,ssd1309fb-i2c
+ - enum:
+ - solomon,ssd1305fb-i2c
+ - solomon,ssd1306fb-i2c
+ - solomon,ssd1307fb-i2c
+ - solomon,ssd1309fb-i2c
deprecated: true
- - items:
- - enum:
- - sinowealth,sh1106
- - solomon,ssd1305
- - solomon,ssd1306
- - solomon,ssd1307
- - solomon,ssd1309
-
- reg:
- maxItems: 1
+ - enum:
+ - sinowealth,sh1106
+ - solomon,ssd1305
+ - solomon,ssd1306
+ - solomon,ssd1307
+ - solomon,ssd1309
pwms:
maxItems: 1
- reset-gpios:
- maxItems: 1
-
- # Only required for SPI
- dc-gpios:
- description:
- GPIO connected to the controller's D/C# (Data/Command) pin,
- that is needed for 4-wire SPI to tell the controller if the
- data sent is for a command register or the display data RAM
- maxItems: 1
-
vbat-supply:
description: The supply for VBAT
- solomon,height:
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 16
- description:
- Height in pixel of the screen driven by the controller
-
- solomon,width:
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 96
- description:
- Width in pixel of the screen driven by the controller
-
solomon,page-offset:
$ref: /schemas/types.yaml#/definitions/uint32
default: 1
@@ -150,7 +122,7 @@ required:
- reg
allOf:
- - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: solomon,ssd-common.yaml#
- if:
properties:
@@ -159,6 +131,10 @@ allOf:
const: sinowealth,sh1106
then:
properties:
+ solomon,width:
+ default: 132
+ solomon,height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -173,6 +149,10 @@ allOf:
- solomon,ssd1305
then:
properties:
+ solomon,width:
+ default: 132
+ solomon,height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -187,6 +167,10 @@ allOf:
- solomon,ssd1306
then:
properties:
+ solomon,width:
+ default: 128
+ solomon,height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -201,6 +185,10 @@ allOf:
- solomon,ssd1307
then:
properties:
+ solomon,width:
+ default: 128
+ solomon,height:
+ default: 39
solomon,dclk-div:
default: 2
solomon,dclk-frq:
@@ -217,6 +205,10 @@ allOf:
- solomon,ssd1309
then:
properties:
+ solomon,width:
+ default: 128
+ solomon,height:
+ default: 64
solomon,dclk-div:
default: 1
solomon,dclk-frq:
@@ -226,7 +218,7 @@ unevaluatedProperties: false
examples:
- |
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -239,7 +231,7 @@ examples:
ssd1306_i2c: oled@3d {
compatible = "solomon,ssd1306";
- reg = <0x3c>;
+ reg = <0x3d>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7>;
solomon,com-lrremap;
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
new file mode 100644
index 000000000000..dd7939989cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd132x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD132x OLED Display Controllers
+
+maintainers:
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+properties:
+ compatible:
+ enum:
+ - solomon,ssd1322
+ - solomon,ssd1325
+ - solomon,ssd1327
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: solomon,ssd-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: solomon,ssd1322
+ then:
+ properties:
+ solomon,width:
+ default: 480
+ solomon,height:
+ default: 128
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: solomon,ssd1325
+ then:
+ properties:
+ solomon,width:
+ default: 128
+ solomon,height:
+ default: 80
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: solomon,ssd1327
+ then:
+ properties:
+ solomon,width:
+ default: 128
+ solomon,height:
+ default: 128
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ oled@3c {
+ compatible = "solomon,ssd1327";
+ reg = <0x3c>;
+ reset-gpios = <&gpio2 7>;
+ };
+
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ oled@0 {
+ compatible = "solomon,ssd1327";
+ reg = <0x0>;
+ reset-gpios = <&gpio2 7>;
+ dc-gpios = <&gpio2 8>;
+ spi-max-frequency = <10000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
new file mode 100644
index 000000000000..b7780038a34b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd133x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD133x OLED Display Controllers
+
+maintainers:
+ - Javier Martinez Canillas <javierm@redhat.com>
+
+allOf:
+ - $ref: solomon,ssd-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - solomon,ssd1331
+
+ solomon,width:
+ default: 96
+
+ solomon,height:
+ default: 64
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ oled@0 {
+ compatible = "solomon,ssd1331";
+ reg = <0x0>;
+ reset-gpios = <&gpio2 7>;
+ dc-gpios = <&gpio2 8>;
+ spi-max-frequency = <10000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
index 4ebea60b8c5b..8c52fa0ea5f8 100644
--- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
@@ -25,7 +25,7 @@ properties:
maxItems: 1
clocks:
- minItems: 2
+ maxItems: 2
clock-names:
items:
diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
index bc5594d18643..300bf2252c3e 100644
--- a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
@@ -20,7 +20,7 @@ properties:
maxItems: 2
clocks:
- minItems: 1
+ maxItems: 1
clock-names:
items:
diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
index 54f67cb51040..53560052aaf0 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
@@ -58,13 +58,22 @@ properties:
DSI input port node, connected to the ltdc rgb output port.
port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description:
- DSI output port node, connected to a panel or a bridge input port"
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: |
+ DSI output port node, connected to a panel or a bridge input port.
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ properties:
+ data-lanes:
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
required:
- - "#address-cells"
- - "#size-cells"
- compatible
- reg
- clocks
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
index d6ea4d62a2cf..77058a5ccf68 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
@@ -12,7 +12,10 @@ maintainers:
properties:
compatible:
- const: st,stm32-ltdc
+ enum:
+ - st,stm32-ltdc
+ - st,stm32mp251-ltdc
+ - st,stm32mp255-ltdc
reg:
maxItems: 1
@@ -24,15 +27,23 @@ properties:
minItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
clock-names:
items:
- const: lcd
+ - const: bus
+ - const: ref
+ - const: lvds
+ minItems: 1
resets:
maxItems: 1
+ access-controllers:
+ maxItems: 1
+
port:
$ref: /schemas/graph.yaml#/properties/port
description: |
@@ -51,6 +62,46 @@ required:
- resets
- port
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32-ltdc
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp251-ltdc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp255-ltdc
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml b/Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
new file mode 100644
index 000000000000..14e042156179
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/st,stm32mp25-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 LVDS Display Interface Transmitter
+
+maintainers:
+ - Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
+ - Yannick Fertre <yannick.fertre@foss.st.com>
+
+description: |
+ The STMicroelectronics STM32 LVDS Display Interface Transmitter handles the
+ LVDS protocol: it maps the pixels received from the upstream Pixel-DMA (LTDC)
+ onto the LVDS PHY.
+
+ It is composed of three sub blocks:
+ - LVDS host: handles the LVDS protocol (FPD / OpenLDI) and maps its input
+ pixels onto the data lanes of the PHY
+ - LVDS PHY: parallelize the data and drives the LVDS data lanes
+ - LVDS wrapper: handles top-level settings
+
+ The LVDS controller driver supports the following high-level features:
+ - FDP-Link-I and OpenLDI (v0.95) protocols
+ - Single-Link or Dual-Link operation
+ - Single-Display or Double-Display (with the same content duplicated on both)
+ - Flexible Bit-Mapping, including JEIDA and VESA
+ - RGB888 or RGB666 output
+ - Synchronous design, with one input pixel per clock cycle
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - st,stm32mp255-lvds
+ - const: st,stm32mp25-lvds
+ - const: st,stm32mp25-lvds
+
+ "#clock-cells":
+ const: 0
+ description:
+ Provides the internal LVDS PHY clock to the framework.
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: APB peripheral clock
+ - description: Reference clock for the internal PLL
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: ref
+
+ resets:
+ maxItems: 1
+
+ access-controllers:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ LVDS input port node, connected to the LTDC RGB output port.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ LVDS output port node, connected to a panel or bridge input port.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+ lvds: lvds@48060000 {
+ compatible = "st,stm32mp25-lvds";
+ reg = <0x48060000 0x2000>;
+ #clock-cells = <0>;
+ clocks = <&rcc CK_BUS_LVDS>, <&rcc CK_KER_LVDSPHY>;
+ clock-names = "pclk", "ref";
+ resets = <&rcc LVDS_R>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_in: endpoint {
+ remote-endpoint = <&ltdc_ep1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds_out0: endpoint {
+ remote-endpoint = <&lvds_panel_in>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml
index d5ca8cf86e8e..193ddb105283 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
enum:
- nvidia,tegra114-mipi
+ - nvidia,tegra124-mipi
- nvidia,tegra210-mipi
- nvidia,tegra186-mipi
@@ -38,7 +39,7 @@ properties:
description: The number of cells in a MIPI calibration specifier.
Should be 1. The single cell specifies a bitmask of the pads that
need to be calibrated for a given device.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
const: 1
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-tsec.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-tsec.yaml
new file mode 100644
index 000000000000..2c4d519a1bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-tsec.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra114-tsec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Security co-processor
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+
+description: Tegra Security co-processor, an embedded security processor used
+ mainly to manage the HDCP encryption and keys on the HDMI link.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra114-tsec
+ - nvidia,tegra124-tsec
+ - nvidia,tegra210-tsec
+
+ - items:
+ - const: nvidia,tegra132-tsec
+ - const: nvidia,tegra124-tsec
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ operating-points-v2: true
+
+ power-domains:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra114-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tsec@54500000 {
+ compatible = "nvidia,tegra114-tsec";
+ reg = <0x54500000 0x00040000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA114_CLK_TSEC>;
+ resets = <&tegra_car TEGRA114_CLK_TSEC>;
+ };
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
index 9ab123cd2325..5cdbc527a560 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
@@ -128,7 +128,6 @@ examples:
resets = <&tegra_car 181>;
reset-names = "dpaux";
power-domains = <&pd_sor>;
- status = "disabled";
state_dpaux_aux: pinmux-aux {
groups = "dpaux-io";
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
index 907fb0baccae..6f2e22471965 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml
@@ -69,12 +69,12 @@ properties:
# Tegra186 and later
nvidia,interface:
description: index of the SOR interface
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,ddc-i2c-bus:
description: phandle of an I2C controller used for DDC EDID
probing
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
nvidia,hpd-gpio:
description: specifies a GPIO used for hotplug detection
@@ -82,23 +82,23 @@ properties:
nvidia,edid:
description: supplies a binary EDID blob
- $ref: "/schemas/types.yaml#/definitions/uint8-array"
+ $ref: /schemas/types.yaml#/definitions/uint8-array
nvidia,panel:
description: phandle of a display panel, required for eDP
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
nvidia,xbar-cfg:
description: 5 cells containing the crossbar configuration.
Each lane of the SOR, identified by the cell's index, is
mapped via the crossbar to the pad specified by the cell's
value.
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
# optional when driving an eDP output
nvidia,dpaux:
- description: phandle to a DispayPort AUX interface
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ description: phandle to a DisplayPort AUX interface
+ $ref: /schemas/types.yaml#/definitions/phandle
allOf:
- if:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml
index 265a60d79d89..ce4589466a18 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml
@@ -60,13 +60,13 @@ properties:
nvidia,outputs:
description: A list of phandles of outputs that this display
controller can drive.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
nvidia,head:
description: The number of the display controller head. This
is used to setup the various types of output to receive
video data from the given head.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
index 8c0231345529..117c371ce24b 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
@@ -20,10 +20,10 @@ properties:
- nvidia,tegra194-display
'#address-cells':
- const: 1
+ enum: [ 1, 2 ]
'#size-cells':
- const: 1
+ enum: [ 1, 2 ]
reg:
maxItems: 1
@@ -138,7 +138,6 @@ examples:
<&bpmp TEGRA186_CLK_NVDISPLAY_DSC>,
<&bpmp TEGRA186_CLK_NVDISPLAYHUB>;
clock-names = "disp", "dsc", "hub";
- status = "disabled";
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
@@ -227,7 +226,6 @@ examples:
clocks = <&bpmp TEGRA194_CLK_NVDISPLAY_DISP>,
<&bpmp TEGRA194_CLK_NVDISPLAYHUB>;
clock-names = "disp", "hub";
- status = "disabled";
power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISP>;
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml
index e5a6145c8c53..da75b71e8ece 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml
@@ -29,7 +29,7 @@ properties:
- const: dsi
allOf:
- - $ref: "/schemas/reset/reset.yaml"
+ - $ref: /schemas/reset/reset.yaml
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-csi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-csi.yaml
new file mode 100644
index 000000000000..a1aea9590769
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-csi.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-csi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 CSI controller
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-csi
+ - nvidia,tegra30-csi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: module clock
+ - description: PAD A clock
+ - description: PAD B clock
+
+ clock-names:
+ items:
+ - const: csi
+ - const: csia-pad
+ - const: csib-pad
+
+ avdd-dsi-csi-supply:
+ description: DSI/CSI power supply. Must supply 1.2 V.
+
+ power-domains:
+ maxItems: 1
+
+ "#nvidia,mipi-calibrate-cells":
+ description:
+ The number of cells in a MIPI calibration specifier. Should be 1.
+ The single cell specifies an id of the pad that need to be
+ calibrated for a given device. Valid pad ids for receiver would be
+ 0 for CSI-A; 1 for CSI-B; 2 for DSI-A and 3 for DSI-B.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ const: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@[0-1]$":
+ type: object
+ description: channel 0 represents CSI-A and 1 represents CSI-B
+ additionalProperties: false
+
+ properties:
+ reg:
+ maximum: 1
+
+ nvidia,mipi-calibrate:
+ description: Should contain a phandle and a specifier specifying
+ which pad is used by this CSI channel and needs to be calibrated.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: port receiving the video stream from the sensor
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: port sending the video stream to the VI
+
+ required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-csi
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra30-csi
+ then:
+ properties:
+ clocks:
+ minItems: 3
+
+ clock-names:
+ minItems: 3
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+
+# see nvidia,tegra20-vi.yaml for an example
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
index 6eedee503aa0..69be95afd562 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml
@@ -59,8 +59,7 @@ properties:
iommus:
maxItems: 1
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
index 75546f250ad7..59e1dc0813e7 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml
@@ -47,8 +47,7 @@ properties:
items:
- const: dsi
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
maxItems: 1
@@ -60,12 +59,12 @@ properties:
description: Should contain a phandle and a specifier specifying
which pads are used by this DSI output and need to be
calibrated. See nvidia,tegra114-mipi.yaml for details.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
nvidia,ddc-i2c-bus:
description: phandle of an I2C controller used for DDC EDID
probing
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
nvidia,hpd-gpio:
description: specifies a GPIO used for hotplug detection
@@ -73,19 +72,19 @@ properties:
nvidia,edid:
description: supplies a binary EDID blob
- $ref: "/schemas/types.yaml#/definitions/uint8-array"
+ $ref: /schemas/types.yaml#/definitions/uint8-array
nvidia,panel:
description: phandle of a display panel
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
nvidia,ganged-mode:
description: contains a phandle to a second DSI controller to
gang up with in order to support up to 8 data lanes
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
allOf:
- - $ref: "../dsi-controller.yaml#"
+ - $ref: ../dsi-controller.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
index 0d55e6206b5e..334f5531b243 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-epp.yaml
@@ -15,10 +15,16 @@ properties:
pattern: "^epp@[0-9a-f]+$"
compatible:
- enum:
- - nvidia,tegra20-epp
- - nvidia,tegra30-epp
- - nvidia,tegra114-epp
+ oneOf:
+ - enum:
+ - nvidia,tegra20-epp
+ - nvidia,tegra30-epp
+ - nvidia,tegra114-epp
+ - nvidia,tegra124-epp
+
+ - items:
+ - const: nvidia,tegra132-epp
+ - const: nvidia,tegra124-epp
reg:
maxItems: 1
@@ -46,8 +52,7 @@ properties:
interconnect-names:
maxItems: 4
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
index bf38accd98eb..1026b0bc3dc8 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr2d.yaml
@@ -49,8 +49,7 @@ properties:
interconnect-names:
maxItems: 4
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
index dbdf0229d9f6..59a52e732ca3 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-gr3d.yaml
@@ -51,15 +51,13 @@ properties:
minItems: 4
maxItems: 10
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
minItems: 1
maxItems: 2
power-domain-names:
- minItems: 2
maxItems: 2
allOf:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
index 035b9f1f2eb5..f77197e4869f 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml
@@ -50,8 +50,7 @@ properties:
items:
- const: hdmi
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
@@ -69,7 +68,7 @@ properties:
nvidia,ddc-i2c-bus:
description: phandle of an I2C controller used for DDC EDID
probing
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
nvidia,hpd-gpio:
description: specifies a GPIO used for hotplug detection
@@ -77,11 +76,11 @@ properties:
nvidia,edid:
description: supplies a binary EDID blob
- $ref: "/schemas/types.yaml#/definitions/uint8-array"
+ $ref: /schemas/types.yaml#/definitions/uint8-array
nvidia,panel:
description: phandle of a display panel
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
"#sound-dai-cells":
const: 0
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 913ca104c871..3563378a01af 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -90,8 +90,7 @@ properties:
items:
- const: dma-mem # read
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
@@ -183,6 +182,15 @@ allOf:
compatible:
contains:
enum:
+ - nvidia,tegra194-host1x
+ then:
+ properties:
+ dma-coherent: true
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- nvidia,tegra234-host1x
then:
properties:
@@ -227,6 +235,8 @@ allOf:
use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to
usable stream IDs.
+ dma-coherent: true
+
required:
- reg-names
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml
index 3bc3b22e98e1..ee25b5e6f1a2 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-isp.yaml
@@ -12,10 +12,17 @@ maintainers:
properties:
compatible:
- enum:
- - nvidia,tegra20-isp
- - nvidia,tegra30-isp
- - nvidia,tegra210-isp
+ oneOf:
+ - enum:
+ - nvidia,tegra20-isp
+ - nvidia,tegra30-isp
+ - nvidia,tegra114-isp
+ - nvidia,tegra124-isp
+ - nvidia,tegra210-isp
+
+ - items:
+ - const: nvidia,tegra132-isp
+ - const: nvidia,tegra124-isp
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
index 4154ae01ad13..36b76fa8f525 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-mpe.yaml
@@ -12,13 +12,21 @@ maintainers:
properties:
$nodename:
- pattern: "^mpe@[0-9a-f]+$"
+ oneOf:
+ - pattern: "^mpe@[0-9a-f]+$"
+ - pattern: "^msenc@[0-9a-f]+$"
compatible:
- enum:
- - nvidia,tegra20-mpe
- - nvidia,tegra30-mpe
- - nvidia,tegra114-mpe
+ oneOf:
+ - enum:
+ - nvidia,tegra20-mpe
+ - nvidia,tegra30-mpe
+ - nvidia,tegra114-msenc
+ - nvidia,tegra124-msenc
+
+ - items:
+ - const: nvidia,tegra132-msenc
+ - const: nvidia,tegra124-msenc
reg:
maxItems: 1
@@ -42,15 +50,12 @@ properties:
maxItems: 1
interconnects:
- minItems: 6
maxItems: 6
interconnect-names:
- minItems: 6
maxItems: 6
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
index 467b015e5700..6c84d8b7eb7b 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-tvo.yaml
@@ -30,8 +30,7 @@ properties:
items:
- description: module clock
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
index 782a4b10150a..644f42b942ad 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vi.yaml
@@ -55,8 +55,7 @@ properties:
minItems: 4
maxItems: 5
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
@@ -71,8 +70,17 @@ properties:
ranges:
maxItems: 1
- avdd-dsi-csi-supply:
- description: DSI/CSI power supply. Must supply 1.2 V.
+ vip:
+ $ref: /schemas/display/tegra/nvidia,tegra20-vip.yaml
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input from the VIP (parallel input capture) module
patternProperties:
"^csi@[0-9a-f]+$":
@@ -109,6 +117,22 @@ examples:
#include <dt-bindings/clock/tegra20-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ camera@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+ clocks = <&camera_clk>;
+
+ port {
+ mt9v111_out: endpoint {
+ remote-endpoint = <&vi_vip_in>;
+ };
+ };
+ };
+ };
+
vi@54080000 {
compatible = "nvidia,tegra20-vi";
reg = <0x54080000 0x00040000>;
@@ -116,6 +140,37 @@ examples:
clocks = <&tegra_car TEGRA20_CLK_VI>;
resets = <&tegra_car 100>;
reset-names = "vi";
+
+ vip {
+ compatible = "nvidia,tegra20-vip";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ vi_vip_in: endpoint {
+ remote-endpoint = <&mt9v111_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ vi_vip_out: endpoint {
+ remote-endpoint = <&vi_in>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ vi_in: endpoint {
+ remote-endpoint = <&vi_vip_out>;
+ };
+ };
+ };
};
- |
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml
new file mode 100644
index 000000000000..14294edb8d8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-vip.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-vip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra VIP (parallel video capture) controller
+
+maintainers:
+ - Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-vip
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port receiving the video stream from the sensor
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port sending the video stream to the VI
+
+ required:
+ - port@0
+ - port@1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - ports
+
+# see nvidia,tegra20-vi.yaml for an example
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml
index fa07a40d1004..37f6129c9c92 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra210-csi.yaml
@@ -37,6 +37,9 @@ properties:
- const: cile
- const: csi_tpg
+ avdd-dsi-csi-supply:
+ description: DSI/CSI power supply. Must supply 1.2 V.
+
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
new file mode 100644
index 000000000000..8203ec5e5bb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM625 OLDI Transmitter
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+ - Aradhya Bhatia <aradhya.bhatia@linux.dev>
+
+description:
+ The AM625 TI Keystone OpenLDI transmitter (OLDI TX) supports serialized RGB
+ pixel data transmission between host and flat panel display over LVDS (Low
+ Voltage Differential Sampling) interface. The OLDI TX consists of 7-to-1 data
+ serializers, and 4-data and 1-clock LVDS outputs. It supports the LVDS output
+ formats "jeida-18", "jeida-24" and "vesa-18", and can accept 24-bit RGB or
+ padded and un-padded 18-bit RGB bus formats as input.
+
+properties:
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: serial clock input for the OLDI transmitters
+
+ clock-names:
+ const: serial
+
+ ti,companion-oldi:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to companion OLDI transmitter. This property is required for both
+ the OLDI TXes if they are expected to work either in dual-lvds mode or in
+ clone mode. This property should point to the other OLDI TX's phandle.
+
+ ti,secondary-oldi:
+ type: boolean
+ description:
+ Boolean property to mark the OLDI transmitter as the secondary one, when the
+ OLDI hardware is expected to run as a companion HW, in cases of dual-lvds
+ mode or clone mode. The primary OLDI hardware is responsible for all the
+ hardware configuration.
+
+ ti,oldi-io-ctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to syscon device node mapping OLDI IO_CTRL registers found in the
+ control MMR region. These registers are required to toggle the I/O lane
+ power, and control its electrical characteristics.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Parallel RGB input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: LVDS output port
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - reg
+ - clocks
+ - clock-names
+ - ti,oldi-io-ctrl
+ - ports
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 5c7d2cbc4aac..361e9cae6896 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments AM65x Display Subsystem
@@ -12,14 +12,26 @@ maintainers:
- Tomi Valkeinen <tomi.valkeinen@ti.com>
description: |
- The AM65x TI Keystone Display SubSystem with two output ports and
- two video planes. The first video port supports OLDI and the second
- supports DPI format. The fist plane is full video plane with all
- features and the second is a "lite plane" without scaling support.
+ The AM625 and AM65x TI Keystone Display SubSystem has two output
+ ports and two video planes. In AM65x DSS, the first video port
+ supports 1 OLDI TX and in AM625 DSS, the first video port output is
+ internally routed to 2 OLDI TXes. The second video port supports DPI
+ format. The first plane is full video plane with all features and the
+ second is a "lite plane" without scaling support.
+ The AM62L display subsystem has a single output port which supports DPI
+ format but it only supports single video "lite plane" which does not support
+ scaling. The output port is routed to SoC boundary via DPI interface and same
+ DPI signals are also routed internally to DSI Tx controller present within the
+ SoC. Due to clocking limitations only one of the interface i.e. either DSI or
+ DPI can be used at once.
properties:
compatible:
- const: ti,am65x-dss
+ enum:
+ - ti,am625-dss
+ - ti,am62a7-dss
+ - ti,am62l-dss
+ - ti,am65x-dss
reg:
description:
@@ -32,6 +44,7 @@ properties:
- description: OVR2 overlay manager for vp2
- description: VP1 video port 1
- description: VP2 video port 2
+ - description: common1 DSS register area
reg-names:
items:
@@ -42,6 +55,7 @@ properties:
- const: ovr2
- const: vp1
- const: vp2
+ - const: common1
clocks:
items:
@@ -80,7 +94,30 @@ properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
- The DSS OLDI output port node form video port 1
+ For AM65x DSS, the OLDI output port node from video port 1.
+ For AM625 DSS, the internal DPI output port node from video
+ port 1.
+ For AM62A7 DSS, the port is tied off inside the SoC.
+ For AM62L DSS, the DSS DPI output port node from video port 1
+ or DSI Tx controller node connected to video port 1.
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description:
+ For AM625 DSS, VP Connection to OLDI0.
+ For AM65X DSS, OLDI output from the SoC.
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description:
+ For AM625 DSS, VP Connection to OLDI1.
+
+ anyOf:
+ - required:
+ - endpoint
+ - required:
+ - endpoint@0
+ - endpoint@1
port@1:
$ref: /schemas/graph.yaml#/properties/port
@@ -88,7 +125,7 @@ properties:
The DSS DPI output port node from video port 2
ti,am65x-oldi-io-ctrl:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to syscon device node mapping OLDI IO_CTRL registers.
The mapped range should point to OLDI_DAT0_IO_CTRL, map it and
@@ -102,6 +139,64 @@ properties:
Input memory (from main memory to dispc) bandwidth limit in
bytes per second
+ oldi-transmitters:
+ description:
+ Child node under the DSS, to describe all the OLDI transmitters connected
+ to the DSS videoports.
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ '^oldi@[0-1]$':
+ $ref: ti,am625-oldi.yaml#
+ description: OLDI transmitters connected to the DSS VPs
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am62a7-dss
+ then:
+ properties:
+ oldi-transmitters: false
+ ports:
+ properties:
+ port@0: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am62l-dss
+ then:
+ properties:
+ ports:
+ properties:
+ port@1: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,am62l-dss
+ - ti,am65x-dss
+ then:
+ properties:
+ oldi-transmitters: false
+ ports:
+ properties:
+ port@0:
+ properties:
+ endpoint@1: false
+
required:
- compatible
- reg
@@ -120,31 +215,135 @@ examples:
#include <dt-bindings/soc/ti,sci_pm_domain.h>
dss: dss@4a00000 {
- compatible = "ti,am65x-dss";
- reg = <0x04a00000 0x1000>, /* common */
- <0x04a02000 0x1000>, /* vidl1 */
- <0x04a06000 0x1000>, /* vid */
- <0x04a07000 0x1000>, /* ovr1 */
- <0x04a08000 0x1000>, /* ovr2 */
- <0x04a0a000 0x1000>, /* vp1 */
- <0x04a0b000 0x1000>; /* vp2 */
+ compatible = "ti,am65x-dss";
+ reg = <0x04a00000 0x1000>, /* common */
+ <0x04a02000 0x1000>, /* vidl1 */
+ <0x04a06000 0x1000>, /* vid */
+ <0x04a07000 0x1000>, /* ovr1 */
+ <0x04a08000 0x1000>, /* ovr2 */
+ <0x04a0a000 0x1000>, /* vp1 */
+ <0x04a0b000 0x1000>, /* vp2 */
+ <0x04a01000 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "vid",
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
+ ti,am65x-oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ power-domains = <&k3_pds 67 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 67 1>,
+ <&k3_clks 216 1>,
+ <&k3_clks 67 2>;
+ clock-names = "fck", "vp1", "vp2";
+ interrupts = <GIC_SPI 166 IRQ_TYPE_EDGE_RISING>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ oldi_out0: endpoint {
+ remote-endpoint = <&lcd_in0>;
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dss1: dss@30200000 {
+ compatible = "ti,am625-dss";
+ reg = <0x00 0x30200000 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30206000 0x00 0x1000>, /* vid */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1 */
+ <0x00 0x3020b000 0x00 0x1000>, /* vp2 */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
reg-names = "common", "vidl1", "vid",
- "ovr1", "ovr2", "vp1", "vp2";
- ti,am65x-oldi-io-ctrl = <&dss_oldi_io_ctrl>;
- power-domains = <&k3_pds 67 TI_SCI_PD_EXCLUSIVE>;
- clocks = <&k3_clks 67 1>,
- <&k3_clks 216 1>,
- <&k3_clks 67 2>;
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
+ power-domains = <&k3_pds 186 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 186 6>,
+ <&vp1_clock>,
+ <&k3_clks 186 2>;
clock-names = "fck", "vp1", "vp2";
- interrupts = <GIC_SPI 166 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ oldi-transmitters {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ oldi0: oldi@0 {
+ reg = <0>;
+ clocks = <&k3_clks 186 0>;
+ clock-names = "serial";
+ ti,companion-oldi = <&oldi1>;
+ ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ oldi0_in: endpoint {
+ remote-endpoint = <&dpi0_out0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ oldi0_out: endpoint {
+ remote-endpoint = <&panel_in0>;
+ };
+ };
+ };
+ };
+ oldi1: oldi@1 {
+ reg = <1>;
+ clocks = <&k3_clks 186 0>;
+ clock-names = "serial";
+ ti,secondary-oldi;
+ ti,companion-oldi = <&oldi0>;
+ ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ oldi1_in: endpoint {
+ remote-endpoint = <&dpi0_out1>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ oldi1_out: endpoint {
+ remote-endpoint = <&panel_in1>;
+ };
+ };
+ };
+ };
+ };
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
#address-cells = <1>;
#size-cells = <0>;
- port@0 {
- reg = <0>;
- oldi_out0: endpoint {
- remote-endpoint = <&lcd_in0>;
- };
+ reg = <0>;
+ dpi0_out0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&oldi0_in>;
+ };
+ dpi0_out1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&oldi1_in>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ dpi1_out: endpoint {
+ remote-endpoint = <&hdmi_bridge>;
};
+ };
};
+ };
};
diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
index 2986f9acc9f0..fad7cba58d39 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments J721E Display Subsystem
diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
index 7ce7bbad5780..96b1439f88e3 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K2G Display Subsystem
diff --git a/Documentation/devicetree/bindings/display/ti/ti,opa362.txt b/Documentation/devicetree/bindings/display/ti/ti,opa362.txt
deleted file mode 100644
index f96083c0bd17..000000000000
--- a/Documentation/devicetree/bindings/display/ti/ti,opa362.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-OPA362 analog video amplifier
-
-Required properties:
-- compatible: "ti,opa362"
-- enable-gpios: enable/disable output gpio
-
-Required node:
-- Video port 0 for opa362 input
-- Video port 1 for opa362 output
-
-Example:
-
-tv_amp: opa362 {
- compatible = "ti,opa362";
- enable-gpios = <&gpio1 23 0>; /* GPIO to enable video out amplifier */
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- opa_in: endpoint@0 {
- remote-endpoint = <&venc_out>;
- };
- };
-
- port@1 {
- reg = <1>;
- opa_out: endpoint@0 {
- remote-endpoint = <&tv_connector_in>;
- };
- };
- };
-};
-
-
-
diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt b/Documentation/devicetree/bindings/display/truly,nt35597.txt
deleted file mode 100644
index f39c77ee36ea..000000000000
--- a/Documentation/devicetree/bindings/display/truly,nt35597.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Truly model NT35597 DSI display driver
-
-The Truly NT35597 is a generic display driver, currently only configured
-for use in the 2K display on the Qualcomm SDM845 MTP board.
-
-Required properties:
-- compatible: should be "truly,nt35597-2K-display"
-- vdda-supply: phandle of the regulator that provides the supply voltage
- Power IC supply
-- vdispp-supply: phandle of the regulator that provides the supply voltage
- for positive LCD bias
-- vdispn-supply: phandle of the regulator that provides the supply voltage
- for negative LCD bias
-- reset-gpios: phandle of gpio for reset line
- This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
- (active low)
-- mode-gpios: phandle of the gpio for choosing the mode of the display
- for single DSI or Dual DSI
- This should be low for dual DSI and high for single DSI mode
-- ports: This device has two video ports driven by two DSIs. Their connections
- are modeled using the OF graph bindings specified in
- Documentation/devicetree/bindings/graph.txt.
- - port@0: DSI input port driven by master DSI
- - port@1: DSI input port driven by secondary DSI
-
-Example:
-
- dsi@ae94000 {
- panel@0 {
- compatible = "truly,nt35597-2K-display";
- reg = <0>;
- vdda-supply = <&pm8998_l14>;
- vdispp-supply = <&lab_regulator>;
- vdispn-supply = <&ibb_regulator>;
- pinctrl-names = "default", "suspend";
- pinctrl-0 = <&dpu_dsi_active>;
- pinctrl-1 = <&dpu_dsi_suspend>;
-
- reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
- mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- panel0_in: endpoint {
- remote-endpoint = <&dsi0_out>;
- };
- };
-
- port@1 {
- reg = <1>;
- panel1_in: endpoint {
- remote-endpoint = <&dsi1_out>;
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
index 10ec78ca1c65..6b754d4f260e 100644
--- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
@@ -100,12 +100,16 @@ properties:
- description: Video layer, plane 1 (U/V or U)
- description: Video layer, plane 2 (V)
- description: Graphics layer
+ - description: Audio channel 0
+ - description: Audio channel 1
dma-names:
items:
- const: vid0
- const: vid1
- const: vid2
- const: gfx0
+ - const: aud0
+ - const: aud1
phys:
description: PHYs for the DP data lanes
@@ -117,6 +121,45 @@ properties:
- const: dp-phy0
- const: dp-phy1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: |
+ Connections to the programmable logic and the DisplayPort PHYs. Each port
+ shall have a single endpoint.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The live video input from the programmable logic
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The live graphics input from the programmable logic
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The live audio input from the programmable logic
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The blended video output to the programmable logic
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The mixed audio output to the programmable logic
+
+ port@5:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The DisplayPort output
+
+ required:
+ - port@0
+ - port@1
+ - port@2
+ - port@3
+ - port@4
+ - port@5
+
required:
- compatible
- reg
@@ -130,6 +173,7 @@ required:
- dma-names
- phys
- phy-names
+ - ports
additionalProperties: false
@@ -154,16 +198,45 @@ examples:
power-domains = <&pd_dp>;
resets = <&reset ZYNQMP_RESET_DP>;
- dma-names = "vid0", "vid1", "vid2", "gfx0";
+ dma-names = "vid0", "vid1", "vid2", "gfx0", "aud0", "aud1";
dmas = <&xlnx_dpdma 0>,
<&xlnx_dpdma 1>,
<&xlnx_dpdma 2>,
- <&xlnx_dpdma 3>;
+ <&xlnx_dpdma 3>,
+ <&xlnx_dpdma 4>,
+ <&xlnx_dpdma 5>;
phys = <&psgtr 1 PHY_TYPE_DP 0 3>,
<&psgtr 0 PHY_TYPE_DP 1 3>;
phy-names = "dp-phy0", "dp-phy1";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ port@2 {
+ reg = <2>;
+ };
+ port@3 {
+ reg = <3>;
+ };
+ port@4 {
+ reg = <4>;
+ };
+ port@5 {
+ reg = <5>;
+ dpsub_dp_out: endpoint {
+ remote-endpoint = <&dp_connector>;
+ };
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
index fc02c5d50ce4..76b804b7c880 100644
--- a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
+++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Bootlin
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xylon LogiCVC display controller
@@ -89,25 +89,25 @@ properties:
description: Display output colorspace (C_DISPLAY_COLOR_SPACE).
xylon,display-depth:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: Display output depth (C_PIXEL_DATA_WIDTH).
xylon,row-stride:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE).
xylon,dithering:
- $ref: "/schemas/types.yaml#/definitions/flag"
+ $ref: /schemas/types.yaml#/definitions/flag
description: Dithering module is enabled (C_XCOLOR)
xylon,background-layer:
- $ref: "/schemas/types.yaml#/definitions/flag"
+ $ref: /schemas/types.yaml#/definitions/flag
description: |
The last layer is used to display a black background (C_USE_BACKGROUND).
The layer must still be registered.
xylon,layers-configurable:
- $ref: "/schemas/types.yaml#/definitions/flag"
+ $ref: /schemas/types.yaml#/definitions/flag
description: |
Configuration of layers' size, position and offset is enabled
(C_USE_SIZE_POSITION).
@@ -131,7 +131,7 @@ properties:
maxItems: 1
xylon,layer-depth:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: Layer depth (C_LAYER_X_DATA_WIDTH).
xylon,layer-colorspace:
@@ -151,19 +151,19 @@ properties:
description: Alpha mode for the layer (C_LAYER_X_ALPHA_MODE).
xylon,layer-base-offset:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Offset in number of lines (C_LAYER_X_OFFSET) starting from the
video RAM base (C_VMEM_BASEADDR), only for version 3.
xylon,layer-buffer-offset:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Offset in number of lines (C_BUFFER_*_OFFSET) starting from the
layer base offset for the second buffer used in double-buffering.
xylon,layer-primary:
- $ref: "/schemas/types.yaml#/definitions/flag"
+ $ref: /schemas/types.yaml#/definitions/flag
description: |
Layer should be registered as a primary plane (exactly one is
required).
diff --git a/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt b/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt
deleted file mode 100644
index cd17684aaab5..000000000000
--- a/Documentation/devicetree/bindings/dma/adi,axi-dmac.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Analog Devices AXI-DMAC DMA controller
-
-Required properties:
- - compatible: Must be "adi,axi-dmac-1.00.a".
- - reg: Specification for the controllers memory mapped register map.
- - interrupts: Specification for the controllers interrupt.
- - clocks: Phandle and specifier to the controllers AXI interface clock
- - #dma-cells: Must be 1.
-
-Required sub-nodes:
- - adi,channels: This sub-node must contain a sub-node for each DMA channel. For
- the channel sub-nodes the following bindings apply. They must match the
- configuration options of the peripheral as it was instantiated.
-
-Required properties for adi,channels sub-node:
- - #size-cells: Must be 0
- - #address-cells: Must be 1
-
-Required channel sub-node properties:
- - reg: Which channel this node refers to.
- - adi,source-bus-width,
- adi,destination-bus-width: Width of the source or destination bus in bits.
- - adi,source-bus-type,
- adi,destination-bus-type: Type of the source or destination bus. Must be one
- of the following:
- 0 (AXI_DMAC_TYPE_AXI_MM): Memory mapped AXI interface
- 1 (AXI_DMAC_TYPE_AXI_STREAM): Streaming AXI interface
- 2 (AXI_DMAC_TYPE_AXI_FIFO): FIFO interface
-
-Deprecated optional channel properties:
- - adi,length-width: Width of the DMA transfer length register.
- - adi,cyclic: Must be set if the channel supports hardware cyclic DMA
- transfers.
- - adi,2d: Must be set if the channel supports hardware 2D DMA transfers.
-
-DMA clients connected to the AXI-DMAC DMA controller must use the format
-described in the dma.txt file using a one-cell specifier. The value of the
-specifier refers to the DMA channel index.
-
-Example:
-
-dma: dma@7c420000 {
- compatible = "adi,axi-dmac-1.00.a";
- reg = <0x7c420000 0x10000>;
- interrupts = <0 57 0>;
- clocks = <&clkc 16>;
- #dma-cells = <1>;
-
- adi,channels {
- #size-cells = <0>;
- #address-cells = <1>;
-
- dma-channel@0 {
- reg = <0>;
- adi,source-bus-width = <32>;
- adi,source-bus-type = <ADI_AXI_DMAC_TYPE_MM_AXI>;
- adi,destination-bus-width = <64>;
- adi,destination-bus-type = <ADI_AXI_DMAC_TYPE_FIFO>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml b/Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml
new file mode 100644
index 000000000000..63b6fb0423c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/adi,axi-dmac.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/adi,axi-dmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AXI-DMAC DMA controller
+
+description: |
+ FPGA-based DMA controller designed for use with high-speed converter hardware.
+
+ http://analogdevicesinc.github.io/hdl/library/axi_dmac/index.html
+
+maintainers:
+ - Nuno Sa <nuno.sa@analog.com>
+
+additionalProperties: false
+
+properties:
+ compatible:
+ const: adi,axi-dmac-1.00.a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#dma-cells":
+ const: 1
+
+ adi,channels:
+ deprecated: true
+ type: object
+ description:
+ This sub-node must contain a sub-node for each DMA channel. This node is
+ only required for IP versions older than 4.3.a and should otherwise be
+ omitted.
+ additionalProperties: false
+
+ properties:
+ "#size-cells":
+ const: 0
+ "#address-cells":
+ const: 1
+
+ patternProperties:
+ "^dma-channel@[0-9a-f]+$":
+ type: object
+ description:
+ DMA channel properties based on HDL compile-time configuration.
+ additionalProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ adi,source-bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Width of the source bus in bits.
+ enum: [8, 16, 32, 64, 128]
+
+ adi,destination-bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Width of the destination bus in bits.
+ enum: [8, 16, 32, 64, 128]
+
+ adi,source-bus-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Type of the source bus.
+
+ 0: Memory mapped AXI interface
+ 1: Streaming AXI interface
+ 2: FIFO interface
+ enum: [0, 1, 2]
+
+ adi,destination-bus-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Type of the destination bus (see adi,source-bus-type).
+ enum: [0, 1, 2]
+
+ adi,length-width:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Width of the DMA transfer length register.
+
+ adi,cyclic:
+ deprecated: true
+ type: boolean
+ description:
+ Must be set if the channel supports hardware cyclic DMA transfers.
+
+ adi,2d:
+ deprecated: true
+ type: boolean
+ description:
+ Must be set if the channel supports hardware 2D DMA transfers.
+
+ required:
+ - reg
+ - adi,source-bus-width
+ - adi,destination-bus-width
+ - adi,source-bus-type
+ - adi,destination-bus-type
+
+ required:
+ - "#size-cells"
+ - "#address-cells"
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - "#dma-cells"
+
+examples:
+ - |
+ dma-controller@7c420000 {
+ compatible = "adi,axi-dmac-1.00.a";
+ reg = <0x7c420000 0x10000>;
+ interrupts = <0 57 0>;
+ clocks = <&clkc 16>;
+ #dma-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
index 83808199657b..9b5180c0a7c4 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/dma/allwinner,sun4i-a10-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 DMA Controller Device Tree Bindings
+title: Allwinner A10 DMA Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
@@ -22,7 +22,9 @@ properties:
number.
compatible:
- const: allwinner,sun4i-a10-dma
+ enum:
+ - allwinner,sun4i-a10-dma
+ - allwinner,suniv-f1c100s-dma
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
index e712444abff1..c3e14eb6cfff 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/dma/allwinner,sun50i-a64-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A64 DMA Controller Device Tree Bindings
+title: Allwinner A64 DMA Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
@@ -28,6 +28,12 @@ properties:
- items:
- const: allwinner,sun8i-r40-dma
- const: allwinner,sun50i-a64-dma
+ - items:
+ - enum:
+ - allwinner,sun50i-h616-dma
+ - allwinner,sun55i-a523-dma
+ - allwinner,sun55i-a523-mcu-dma
+ - const: allwinner,sun50i-a100-dma
reg:
maxItems: 1
@@ -59,10 +65,11 @@ required:
if:
properties:
compatible:
- enum:
- - allwinner,sun20i-d1-dma
- - allwinner,sun50i-a100-dma
- - allwinner,sun50i-h6-dma
+ contains:
+ enum:
+ - allwinner,sun20i-d1-dma
+ - allwinner,sun50i-a100-dma
+ - allwinner,sun50i-h6-dma
then:
properties:
diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
index a6df6f8b54db..5d554bcfab3d 100644
--- a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/dma/allwinner,sun6i-a31-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 DMA Controller Device Tree Bindings
+title: Allwinner A31 DMA Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml
index b53ac7631a76..391bf5838602 100644
--- a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml
+++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml
@@ -14,7 +14,7 @@ description: |
intellectual property (IP)
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/apm,xgene-storm-dma.yaml b/Documentation/devicetree/bindings/dma/apm,xgene-storm-dma.yaml
new file mode 100644
index 000000000000..9ca5f7848785
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/apm,xgene-storm-dma.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/apm,xgene-storm-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene Storm SoC DMA
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+properties:
+ compatible:
+ const: apm,xgene-storm-dma
+
+ reg:
+ items:
+ - description: DMA control and status registers
+ - description: Descriptor ring control and status registers
+ - description: Descriptor ring command registers
+ - description: SoC efuse registers
+
+ interrupts:
+ items:
+ - description: DMA error reporting interrupt
+ - description: DMA channel 0 completion interrupt
+ - description: DMA channel 1 completion interrupt
+ - description: DMA channel 2 completion interrupt
+ - description: DMA channel 3 completion interrupt
+
+ clocks:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ dma@1f270000 {
+ compatible = "apm,xgene-storm-dma";
+ reg = <0x1f270000 0x10000>,
+ <0x1f200000 0x10000>,
+ <0x1b000000 0x400000>,
+ <0x1054a000 0x100>;
+ interrupts = <0x0 0x82 0x4>,
+ <0x0 0xb8 0x4>,
+ <0x0 0xb9 0x4>,
+ <0x0 0xba 0x4>,
+ <0x0 0xbb 0x4>;
+ dma-coherent;
+ clocks = <&dmaclk 0>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
deleted file mode 100644
index c53e0b08032f..000000000000
--- a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Applied Micro X-Gene SoC DMA nodes
-
-DMA nodes are defined to describe on-chip DMA interfaces in
-APM X-Gene SoC.
-
-Required properties for DMA interfaces:
-- compatible: Should be "apm,xgene-dma".
-- device_type: set to "dma".
-- reg: Address and length of the register set for the device.
- It contains the information of registers in the following order:
- 1st - DMA control and status register address space.
- 2nd - Descriptor ring control and status register address space.
- 3rd - Descriptor ring command register address space.
- 4th - Soc efuse register address space.
-- interrupts: DMA has 5 interrupts sources. 1st interrupt is
- DMA error reporting interrupt. 2nd, 3rd, 4th and 5th interrupts
- are completion interrupts for each DMA channels.
-- clocks: Reference to the clock entry.
-
-Optional properties:
-- dma-coherent : Present if dma operations are coherent
-
-Example:
- dmaclk: dmaclk@1f27c000 {
- compatible = "apm,xgene-device-clock";
- #clock-cells = <1>;
- clocks = <&socplldiv2 0>;
- reg = <0x0 0x1f27c000 0x0 0x1000>;
- reg-names = "csr-reg";
- clock-output-names = "dmaclk";
- };
-
- dma: dma@1f270000 {
- compatible = "apm,xgene-storm-dma";
- device_type = "dma";
- reg = <0x0 0x1f270000 0x0 0x10000>,
- <0x0 0x1f200000 0x0 0x10000>,
- <0x0 0x1b000000 0x0 0x400000>,
- <0x0 0x1054a000 0x0 0x100>;
- interrupts = <0x0 0x82 0x4>,
- <0x0 0xb8 0x4>,
- <0x0 0xb9 0x4>,
- <0x0 0xba 0x4>,
- <0x0 0xbb 0x4>;
- dma-coherent;
- clocks = <&dmaclk 0>;
- };
diff --git a/Documentation/devicetree/bindings/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml
index bdc8c129c4f5..6a200cbd7d02 100644
--- a/Documentation/devicetree/bindings/dma/apple,admac.yaml
+++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml
@@ -18,15 +18,21 @@ maintainers:
- Martin Povišer <povik+lin@cutebit.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
- items:
- - enum:
- - apple,t6000-admac
- - apple,t8103-admac
- - const: apple,admac
+ oneOf:
+ - items:
+ - const: apple,t6020-admac
+ - const: apple,t8103-admac
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,t6000-admac
+ - apple,t8103-admac
+ - apple,t8112-admac
+ - const: apple,admac
reg:
maxItems: 1
@@ -49,6 +55,16 @@ properties:
in an interrupts-extended list the disconnected positions will contain
an empty phandle reference <0>.
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
new file mode 100644
index 000000000000..429f682f15d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/arm,dma-350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm CoreLink DMA-350 Controller
+
+maintainers:
+ - Robin Murphy <robin.murphy@arm.com>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ const: arm,dma-350
+
+ reg:
+ items:
+ - description: Base and size of the full register map
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Channel 0 interrupt
+ - description: Channel 1 interrupt
+ - description: Channel 2 interrupt
+ - description: Channel 3 interrupt
+ - description: Channel 4 interrupt
+ - description: Channel 5 interrupt
+ - description: Channel 6 interrupt
+ - description: Channel 7 interrupt
+
+ "#dma-cells":
+ const: 1
+ description: The cell is the trigger input number
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/dma/arm,pl330.yaml b/Documentation/devicetree/bindings/dma/arm,pl330.yaml
index 2bec69b308f8..4a3dd6f5309b 100644
--- a/Documentation/devicetree/bindings/dma/arm,pl330.yaml
+++ b/Documentation/devicetree/bindings/dma/arm,pl330.yaml
@@ -55,6 +55,12 @@ properties:
dma-coherent: true
+ iommus:
+ minItems: 1
+ maxItems: 9
+ description: Up to 1 IOMMU entry per DMA channel for writes and 1
+ IOMMU entry for reads.
+
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml
index 9193b18fb75f..ab25ae63d2c3 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml
+++ b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml
@@ -11,7 +11,7 @@ maintainers:
allOf:
- $ref: /schemas/arm/primecell.yaml#
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
diff --git a/Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml b/Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml
new file mode 100644
index 000000000000..a58dc407311b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/atmel,at91sam9g45-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Direct Memory Access Controller (DMA)
+
+maintainers:
+ - Ludovic Desroches <ludovic.desroches@microchip.com>
+
+description:
+ The Atmel Direct Memory Access Controller (DMAC) transfers data from a source
+ peripheral to a destination peripheral over one or more AMBA buses. One channel
+ is required for each source/destination pair. In the most basic configuration,
+ the DMAC has one master interface and one channel. The master interface reads
+ the data from a source and writes it to a destination. Two AMBA transfers are
+ required for each DMAC data transfer. This is also known as a dual-access transfer.
+ The DMAC is programmed via the APB interface.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91sam9g45-dma
+ - atmel,at91sam9rl-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#dma-cells":
+ description:
+ Must be <2>, used to represent the number of integer cells in the dma
+ property of client devices. The two cells in order are
+ 1. The first cell represents the channel number.
+ 2. The second cell is 0 for RX and 1 for TX transfers.
+ const: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: dma_clk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ dma-controller@ffffec00 {
+ compatible = "atmel,at91sam9g45-dma";
+ reg = <0xffffec00 0x200>;
+ interrupts = <21>;
+ #dma-cells = <2>;
+ clocks = <&pmc 2 20>;
+ clock-names = "dma_clk";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml b/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml
new file mode 100644
index 000000000000..73fc13b902b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/atmel,sama5d4-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 Extensible Direct Memory Access Controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Charan Pedumuru <charan.pedumuru@microchip.com>
+
+description:
+ The DMA Controller (XDMAC) is a AHB-protocol central direct memory access
+ controller. It performs peripheral data transfer and memory move operations
+ over one or two bus ports through the unidirectional communication
+ channel. Each channel is fully programmable and provides both peripheral
+ or memory-to-memory transfers. The channel features are configurable at
+ implementation.
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,sama5d4-dma
+ - microchip,sama7g5-dma
+ - items:
+ - enum:
+ - microchip,sam9x60-dma
+ - microchip,sam9x7-dma
+ - const: atmel,sama5d4-dma
+ - items:
+ - const: microchip,sama7d65-dma
+ - const: microchip,sama7g5-dma
+
+ "#dma-cells":
+ description: |
+ Represents the number of integer cells in the `dmas` property of client
+ devices. The single cell specifies the channel configuration register:
+ - bit 13: SIF (Source Interface Identifier) for memory interface.
+ - bit 14: DIF (Destination Interface Identifier) for peripheral interface.
+ - bit 30-24: PERID (Peripheral Identifier).
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: dma_clk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - "#dma-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ dma-controller@f0008000 {
+ compatible = "atmel,sama5d4-dma";
+ reg = <0xf0008000 0x1000>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
+ #dma-cells = <1>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 20>;
+ clock-names = "dma_clk";
+ };
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
deleted file mode 100644
index f69bcf5a6343..000000000000
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* Atmel Direct Memory Access Controller (DMA)
-
-Required properties:
-- compatible: Should be "atmel,<chip>-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain DMA interrupt.
-- #dma-cells: Must be <2>, used to represent the number of integer cells in
-the dmas property of client devices.
-
-Example:
-
-dma0: dma@ffffec00 {
- compatible = "atmel,at91sam9g45-dma";
- reg = <0xffffec00 0x200>;
- interrupts = <21>;
- #dma-cells = <2>;
-};
-
-DMA clients connected to the Atmel DMA controller must use the format
-described in the dma.txt file, using a three-cell specifier for each channel:
-a phandle plus two integer cells.
-The three cells in order are:
-
-1. A phandle pointing to the DMA controller.
-2. The memory interface (16 most significant bits), the peripheral interface
-(16 less significant bits).
-3. Parameters for the at91 DMA configuration register which are device
-dependent:
- - bit 7-0: peripheral identifier for the hardware handshaking interface. The
- identifier can be different for tx and rx.
- - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.
-
-Example:
-
-i2c0@i2c@f8010000 {
- compatible = "atmel,at91sam9x5-i2c";
- reg = <0xf8010000 0x100>;
- interrupts = <9 4 6>;
- dmas = <&dma0 1 7>,
- <&dma0 1 8>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt
deleted file mode 100644
index 510b7f25ba24..000000000000
--- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Atmel Extensible Direct Memory Access Controller (XDMAC)
-
-* XDMA Controller
-Required properties:
-- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or
- "microchip,sama7g5-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain DMA interrupt.
-- #dma-cells: Must be <1>, used to represent the number of integer cells in
-the dmas property of client devices.
- - The 1st cell specifies the channel configuration register:
- - bit 13: SIF, source interface identifier, used to get the memory
- interface identifier,
- - bit 14: DIF, destination interface identifier, used to get the peripheral
- interface identifier,
- - bit 30-24: PERID, peripheral identifier.
-
-Example:
-
-dma1: dma-controller@f0004000 {
- compatible = "atmel,sama5d4-dma";
- reg = <0xf0004000 0x200>;
- interrupts = <50 4 0>;
- #dma-cells = <1>;
-};
-
-
-* DMA clients
-DMA clients connected to the Atmel XDMA controller must use the format
-described in the dma.txt file, using a one-cell specifier for each channel.
-The two cells in order are:
-1. A phandle pointing to the DMA controller.
-2. Channel configuration register. Configurable fields are:
- - bit 13: SIF, source interface identifier, used to get the memory
- interface identifier,
- - bit 14: DIF, destination interface identifier, used to get the peripheral
- interface identifier,
- - bit 30-24: PERID, peripheral identifier.
-
-Example:
-
-i2c2: i2c@f8024000 {
- compatible = "atmel,at91sam9x5-i2c";
- reg = <0xf8024000 0x4000>;
- interrupts = <34 4 6>;
- dmas = <&dma1
- (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
- | AT91_XDMAC_DT_PERID(6))>,
- <&dma1
- (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
- | AT91_XDMAC_DT_PERID(7))>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
deleted file mode 100644
index b6a8cc0978cd..000000000000
--- a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-* BCM2835 DMA controller
-
-The BCM2835 DMA controller has 16 channels in total.
-Only the lower 13 channels have an associated IRQ.
-Some arbitrary channels are used by the firmware
-(1,3,6,7 in the current firmware version).
-The channels 0,2 and 3 have special functionality
-and should not be used by the driver.
-
-Required properties:
-- compatible: Should be "brcm,bcm2835-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain the DMA interrupts associated
- to the DMA channels in ascending order.
-- interrupt-names: Should contain the names of the interrupt
- in the form "dmaXX".
- Use "dma-shared-all" for the common interrupt line
- that is shared by all dma channels.
-- #dma-cells: Must be <1>, the cell in the dmas property of the
- client device represents the DREQ number.
-- brcm,dma-channel-mask: Bit mask representing the channels
- not used by the firmware in ascending order,
- i.e. first channel corresponds to LSB.
-
-Example:
-
-dma: dma@7e007000 {
- compatible = "brcm,bcm2835-dma";
- reg = <0x7e007000 0xf00>;
- interrupts = <1 16>,
- <1 17>,
- <1 18>,
- <1 19>,
- <1 20>,
- <1 21>,
- <1 22>,
- <1 23>,
- <1 24>,
- <1 25>,
- <1 26>,
- /* dma channel 11-14 share one irq */
- <1 27>,
- <1 27>,
- <1 27>,
- <1 27>,
- /* unused shared irq for all channels */
- <1 28>;
- interrupt-names = "dma0",
- "dma1",
- "dma2",
- "dma3",
- "dma4",
- "dma5",
- "dma6",
- "dma7",
- "dma8",
- "dma9",
- "dma10",
- "dma11",
- "dma12",
- "dma13",
- "dma14",
- "dma-shared-all";
-
- #dma-cells = <1>;
- brcm,dma-channel-mask = <0x7f35>;
-};
-
-
-DMA clients connected to the BCM2835 DMA controller must use the format
-described in the dma.txt file, using a two-cell specifier for each channel.
-
-Example:
-
-bcm2835_i2s: i2s@7e203000 {
- compatible = "brcm,bcm2835-i2s";
- reg = < 0x7e203000 0x24>;
- clocks = <&clocks BCM2835_CLOCK_PCM>;
-
- dmas = <&dma 2>,
- <&dma 3>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml
new file mode 100644
index 000000000000..c9b9a5490826
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/brcm,bcm2835-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 DMA controller
+
+maintainers:
+ - Nicolas Saenz Julienne <nsaenz@kernel.org>
+
+description:
+ The BCM2835 DMA controller has 16 channels in total. Only the lower
+ 13 channels have an associated IRQ. Some arbitrary channels are used by the
+ VideoCore firmware (1,3,6,7 in the current firmware version). The channels
+ 0, 2 and 3 have special functionality and should not be used by the driver.
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm2835-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Should contain the DMA interrupts associated to the DMA channels in
+ ascending order.
+ minItems: 1
+ maxItems: 16
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 16
+
+ '#dma-cells':
+ description: The single cell represents the DREQ number.
+ const: 1
+
+ brcm,dma-channel-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bitmask of available DMA channels in ascending order that are
+ not reserved by firmware and are available to the
+ kernel. i.e. first channel corresponds to LSB.
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - brcm,dma-channel-mask
+
+examples:
+ - |
+ dma-controller@7e007000 {
+ compatible = "brcm,bcm2835-dma";
+ reg = <0x7e007000 0xf00>;
+ interrupts = <1 16>,
+ <1 17>,
+ <1 18>,
+ <1 19>,
+ <1 20>,
+ <1 21>,
+ <1 22>,
+ <1 23>,
+ <1 24>,
+ <1 25>,
+ <1 26>,
+ /* dma channel 11-14 share one irq */
+ <1 27>,
+ <1 27>,
+ <1 27>,
+ <1 27>,
+ /* unused shared irq for all channels */
+ <1 28>;
+ interrupt-names = "dma0",
+ "dma1",
+ "dma2",
+ "dma3",
+ "dma4",
+ "dma5",
+ "dma6",
+ "dma7",
+ "dma8",
+ "dma9",
+ "dma10",
+ "dma11",
+ "dma12",
+ "dma13",
+ "dma14",
+ "dma-shared-all";
+ #dma-cells = <1>;
+ brcm,dma-channel-mask = <0x7f35>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
deleted file mode 100644
index 092913a28457..000000000000
--- a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Broadcom SBA RAID engine
-
-Required properties:
-- compatible: Should be one of the following
- "brcm,iproc-sba"
- "brcm,iproc-sba-v2"
- The "brcm,iproc-sba" has support for only 6 PQ coefficients
- The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
-- mboxes: List of phandle and mailbox channel specifiers
-
-Example:
-
-raid_mbox: mbox@67400000 {
- ...
- #mbox-cells = <3>;
- ...
-};
-
-raid0 {
- compatible = "brcm,iproc-sba-v2";
- mboxes = <&raid_mbox 0 0x1 0xffff>,
- <&raid_mbox 1 0x1 0xffff>,
- <&raid_mbox 2 0x1 0xffff>,
- <&raid_mbox 3 0x1 0xffff>,
- <&raid_mbox 4 0x1 0xffff>,
- <&raid_mbox 5 0x1 0xffff>,
- <&raid_mbox 6 0x1 0xffff>,
- <&raid_mbox 7 0x1 0xffff>;
-};
diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.yaml b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.yaml
new file mode 100644
index 000000000000..f3fed576cacf
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/brcm,iproc-sba.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom SBA RAID engine
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+properties:
+ compatible:
+ enum:
+ - brcm,iproc-sba
+ - brcm,iproc-sba-v2
+
+ mboxes:
+ minItems: 1
+ maxItems: 8
+
+required:
+ - compatible
+ - mboxes
+
+additionalProperties: false
+
+examples:
+ - |
+ raid0 {
+ compatible = "brcm,iproc-sba-v2";
+ mboxes = <&raid_mbox 0 0x1 0xffff>,
+ <&raid_mbox 1 0x1 0xffff>,
+ <&raid_mbox 2 0x1 0xffff>,
+ <&raid_mbox 3 0x1 0xffff>,
+ <&raid_mbox 4 0x1 0xffff>,
+ <&raid_mbox 5 0x1 0xffff>,
+ <&raid_mbox 6 0x1 0xffff>,
+ <&raid_mbox 7 0x1 0xffff>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml
new file mode 100644
index 000000000000..871b76ddf90f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2m.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/cirrus,ep9301-dma-m2m.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic ep93xx SoC DMA controller
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-dma-m2m
+ - items:
+ - enum:
+ - cirrus,ep9302-dma-m2m
+ - cirrus,ep9307-dma-m2m
+ - cirrus,ep9312-dma-m2m
+ - cirrus,ep9315-dma-m2m
+ - const: cirrus,ep9301-dma-m2m
+
+ reg:
+ items:
+ - description: m2m0 channel registers
+ - description: m2m1 channel registers
+
+ clocks:
+ items:
+ - description: m2m0 channel gate clock
+ - description: m2m1 channel gate clock
+
+ clock-names:
+ items:
+ - const: m2m0
+ - const: m2m1
+
+ interrupts:
+ items:
+ - description: m2m0 channel interrupt
+ - description: m2m1 channel interrupt
+
+ '#dma-cells':
+ const: 2
+ description: |
+ The first cell is the unique device channel number as indicated by this
+ table for ep93xx:
+
+ 10: SPI controller
+ 11: IDE controller
+
+ The second cell is the DMA direction line number:
+
+ 1: Memory to device
+ 2: Device to memory
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/cirrus,ep9301-syscon.h>
+ dma-controller@80000100 {
+ compatible = "cirrus,ep9301-dma-m2m";
+ reg = <0x80000100 0x0040>,
+ <0x80000140 0x0040>;
+ clocks = <&syscon EP93XX_CLK_M2M0>,
+ <&syscon EP93XX_CLK_M2M1>;
+ clock-names = "m2m0", "m2m1";
+ interrupt-parent = <&vic0>;
+ interrupts = <17>, <18>;
+ #dma-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml
new file mode 100644
index 000000000000..d14c31553543
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/cirrus,ep9301-dma-m2p.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/cirrus,ep9301-dma-m2p.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic ep93xx SoC M2P DMA controller
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-dma-m2p
+ - items:
+ - enum:
+ - cirrus,ep9302-dma-m2p
+ - cirrus,ep9307-dma-m2p
+ - cirrus,ep9312-dma-m2p
+ - cirrus,ep9315-dma-m2p
+ - const: cirrus,ep9301-dma-m2p
+
+ reg:
+ items:
+ - description: m2p0 channel registers
+ - description: m2p1 channel registers
+ - description: m2p2 channel registers
+ - description: m2p3 channel registers
+ - description: m2p4 channel registers
+ - description: m2p5 channel registers
+ - description: m2p6 channel registers
+ - description: m2p7 channel registers
+ - description: m2p8 channel registers
+ - description: m2p9 channel registers
+
+ clocks:
+ items:
+ - description: m2p0 channel gate clock
+ - description: m2p1 channel gate clock
+ - description: m2p2 channel gate clock
+ - description: m2p3 channel gate clock
+ - description: m2p4 channel gate clock
+ - description: m2p5 channel gate clock
+ - description: m2p6 channel gate clock
+ - description: m2p7 channel gate clock
+ - description: m2p8 channel gate clock
+ - description: m2p9 channel gate clock
+
+ clock-names:
+ items:
+ - const: m2p0
+ - const: m2p1
+ - const: m2p2
+ - const: m2p3
+ - const: m2p4
+ - const: m2p5
+ - const: m2p6
+ - const: m2p7
+ - const: m2p8
+ - const: m2p9
+
+ interrupts:
+ items:
+ - description: m2p0 channel interrupt
+ - description: m2p1 channel interrupt
+ - description: m2p2 channel interrupt
+ - description: m2p3 channel interrupt
+ - description: m2p4 channel interrupt
+ - description: m2p5 channel interrupt
+ - description: m2p6 channel interrupt
+ - description: m2p7 channel interrupt
+ - description: m2p8 channel interrupt
+ - description: m2p9 channel interrupt
+
+ '#dma-cells':
+ const: 2
+ description: |
+ The first cell is the unique device channel number as indicated by this
+ table for ep93xx:
+
+ 0: I2S channel 1
+ 1: I2S channel 2 (unused)
+ 2: AC97 channel 1 (unused)
+ 3: AC97 channel 2 (unused)
+ 4: AC97 channel 3 (unused)
+ 5: I2S channel 3 (unused)
+ 6: UART1 (unused)
+ 7: UART2 (unused)
+ 8: UART3 (unused)
+ 9: IRDA (unused)
+
+ The second cell is the DMA direction line number:
+
+ 1: Memory to device
+ 2: Device to memory
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/cirrus,ep9301-syscon.h>
+ dma-controller@80000000 {
+ compatible = "cirrus,ep9301-dma-m2p";
+ reg = <0x80000000 0x0040>,
+ <0x80000040 0x0040>,
+ <0x80000080 0x0040>,
+ <0x800000c0 0x0040>,
+ <0x80000240 0x0040>,
+ <0x80000200 0x0040>,
+ <0x800002c0 0x0040>,
+ <0x80000280 0x0040>,
+ <0x80000340 0x0040>,
+ <0x80000300 0x0040>;
+ clocks = <&syscon EP93XX_CLK_M2P0>,
+ <&syscon EP93XX_CLK_M2P1>,
+ <&syscon EP93XX_CLK_M2P2>,
+ <&syscon EP93XX_CLK_M2P3>,
+ <&syscon EP93XX_CLK_M2P4>,
+ <&syscon EP93XX_CLK_M2P5>,
+ <&syscon EP93XX_CLK_M2P6>,
+ <&syscon EP93XX_CLK_M2P7>,
+ <&syscon EP93XX_CLK_M2P8>,
+ <&syscon EP93XX_CLK_M2P9>;
+ clock-names = "m2p0", "m2p1",
+ "m2p2", "m2p3",
+ "m2p4", "m2p5",
+ "m2p6", "m2p7",
+ "m2p8", "m2p9";
+ interrupt-parent = <&vic0>;
+ interrupts = <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>, <15>, <16>;
+ #dma-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/dma-common.yaml b/Documentation/devicetree/bindings/dma/dma-common.yaml
index ad06d36af208..fde5160b5d29 100644
--- a/Documentation/devicetree/bindings/dma/dma-common.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-common.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/dma/dma-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DMA Engine Generic Binding
+title: DMA Engine Common Properties
maintainers:
- Vinod Koul <vkoul@kernel.org>
@@ -32,10 +32,9 @@ properties:
The first item in the array is for channels 0-31, the second is for
channels 32-63, etc.
$ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- minItems: 1
- # Should be enough
- maxItems: 255
+ minItems: 1
+ # Should be enough
+ maxItems: 255
dma-channels:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/dma/dma-controller.yaml b/Documentation/devicetree/bindings/dma/dma-controller.yaml
index 6d3727267fa8..e6afca558c2d 100644
--- a/Documentation/devicetree/bindings/dma/dma-controller.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-controller.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/dma/dma-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DMA Controller Generic Binding
+title: DMA Controller Common Properties
maintainers:
- Vinod Koul <vkoul@kernel.org>
allOf:
- - $ref: "dma-common.yaml#"
+ - $ref: dma-common.yaml#
# Everything else is described in the common file
properties:
@@ -19,19 +19,4 @@ properties:
additionalProperties: true
-examples:
- - |
- dma: dma-controller@48000000 {
- compatible = "ti,omap-sdma";
- reg = <0x48000000 0x1000>;
- interrupts = <0 12 0x4>,
- <0 13 0x4>,
- <0 14 0x4>,
- <0 15 0x4>;
- #dma-cells = <1>;
- dma-channels = <32>;
- dma-requests = <127>;
- dma-channel-mask = <0xfffe>;
- };
-
...
diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml
index 4b817f5dc30e..5ad2febc581e 100644
--- a/Documentation/devicetree/bindings/dma/dma-router.yaml
+++ b/Documentation/devicetree/bindings/dma/dma-router.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/dma/dma-router.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DMA Router Generic Binding
+title: DMA Router Common Properties
maintainers:
- Vinod Koul <vkoul@kernel.org>
allOf:
- - $ref: "dma-common.yaml#"
+ - $ref: dma-common.yaml#
description:
DMA routers are transparent IP blocks used to route DMA request
@@ -40,15 +40,4 @@ required:
additionalProperties: true
-examples:
- - |
- sdma_xbar: dma-router@4a002b78 {
- compatible = "ti,dra7-dma-crossbar";
- reg = <0x4a002b78 0xfc>;
- #dma-cells = <1>;
- dma-requests = <205>;
- ti,dma-safe-map = <0>;
- dma-masters = <&sdma>;
- };
-
...
diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
index 050e6cd57727..fa4248e2f1b9 100644
--- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
+++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
@@ -21,33 +21,73 @@ properties:
- enum:
- fsl,vf610-edma
- fsl,imx7ulp-edma
+ - fsl,imx8qm-edma
+ - fsl,imx8ulp-edma
+ - fsl,imx93-edma3
+ - fsl,imx93-edma4
+ - fsl,imx95-edma5
+ - nxp,s32g2-edma
+ - items:
+ - enum:
+ - fsl,imx94-edma3
+ - const: fsl,imx93-edma3
+ - items:
+ - enum:
+ - fsl,imx94-edma5
+ - const: fsl,imx95-edma5
- items:
- const: fsl,ls1028a-edma
- const: fsl,vf610-edma
+ - items:
+ - const: nxp,s32g3-edma
+ - const: nxp,s32g2-edma
reg:
- minItems: 2
+ minItems: 1
maxItems: 3
interrupts:
- minItems: 2
- maxItems: 17
+ minItems: 1
+ maxItems: 65
interrupt-names:
- minItems: 2
- maxItems: 17
+ minItems: 1
+ maxItems: 65
"#dma-cells":
- const: 2
+ description: |
+ Specifies the number of cells needed to encode an DMA channel.
+
+ Encode for cells number 2:
+ cell 0: index of dma channel mux instance.
+ cell 1: peripheral dma request id.
+
+ Encode for cells number 3:
+ cell 0: peripheral dma request id.
+ cell 1: dma channel priority.
+ cell 2: bitmask, defined at include/dt-bindings/dma/fsl-edma.h
+ enum:
+ - 2
+ - 3
dma-channels:
- const: 32
+ minimum: 1
+ maximum: 64
clocks:
- maxItems: 2
+ minItems: 1
+ maxItems: 33
clock-names:
- maxItems: 2
+ minItems: 1
+ maxItems: 33
+
+ power-domains:
+ description:
+ The number of power domains matches the number of channels, arranged
+ in ascending order according to their associated DMA channels.
+ minItems: 1
+ maxItems: 64
big-endian:
description: |
@@ -60,11 +100,33 @@ required:
- compatible
- reg
- interrupts
- - clocks
- dma-channels
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-edma
+ - fsl,imx93-edma3
+ - fsl,imx93-edma4
+ - fsl,imx95-edma5
+ then:
+ properties:
+ "#dma-cells":
+ const: 3
+ # It is not necessary to write the interrupt name for each channel.
+ # instead, you can simply maintain the sequential IRQ numbers as
+ # defined for the DMA channels.
+ interrupt-names: false
+ clock-names:
+ items:
+ - const: dma
+ clocks:
+ maxItems: 1
+
- if:
properties:
compatible:
@@ -72,18 +134,27 @@ allOf:
const: fsl,vf610-edma
then:
properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
clock-names:
items:
- const: dmamux0
- const: dmamux1
interrupts:
+ minItems: 2
maxItems: 2
interrupt-names:
items:
- const: edma-tx
- const: edma-err
reg:
+ minItems: 2
maxItems: 3
+ "#dma-cells":
+ const: 2
+ dma-channels:
+ const: 32
- if:
properties:
@@ -92,14 +163,105 @@ allOf:
const: fsl,imx7ulp-edma
then:
properties:
+ clock:
+ minItems: 2
+ maxItems: 2
clock-names:
items:
- const: dma
- const: dmamux0
interrupts:
+ minItems: 2
maxItems: 17
reg:
+ minItems: 2
+ maxItems: 2
+ "#dma-cells":
+ const: 2
+ dma-channels:
+ const: 32
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8ulp-edma
+ then:
+ properties:
+ clocks:
+ minItems: 33
+ clock-names:
+ minItems: 33
+ items:
+ oneOf:
+ - const: dma
+ - pattern: "^ch(0[0-9]|[1-2][0-9]|3[01])$"
+
+ interrupt-names: false
+ interrupts:
+ minItems: 32
+ "#dma-cells":
+ const: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,vf610-edma
+ - fsl,imx7ulp-edma
+ - fsl,imx93-edma3
+ - fsl,imx93-edma4
+ - fsl,imx95-edma5
+ - fsl,imx8ulp-edma
+ - fsl,ls1028a-edma
+ then:
+ required:
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-adma
+ - fsl,imx8qm-edma
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,s32g2-edma
+ then:
+ properties:
+ clocks:
+ minItems: 2
maxItems: 2
+ clock-names:
+ items:
+ - const: dmamux0
+ - const: dmamux1
+ interrupts:
+ minItems: 3
+ maxItems: 3
+ interrupt-names:
+ items:
+ - const: tx-0-15
+ - const: tx-16-31
+ - const: err
+ reg:
+ minItems: 3
+ maxItems: 3
+ "#dma-cells":
+ const: 2
+ dma-channels:
+ const: 32
unevaluatedProperties: false
@@ -153,3 +315,30 @@ examples:
clock-names = "dma", "dmamux0";
clocks = <&pcc2 IMX7ULP_CLK_DMA1>, <&pcc2 IMX7ULP_CLK_DMA_MUX1>;
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ dma-controller@5a9f0000 {
+ compatible = "fsl,imx8qm-edma";
+ reg = <0x5a9f0000 0x90000>;
+ #dma-cells = <3>;
+ dma-channels = <8>;
+ interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&pd IMX_SC_R_DMA_3_CH0>,
+ <&pd IMX_SC_R_DMA_3_CH1>,
+ <&pd IMX_SC_R_DMA_3_CH2>,
+ <&pd IMX_SC_R_DMA_3_CH3>,
+ <&pd IMX_SC_R_DMA_3_CH4>,
+ <&pd IMX_SC_R_DMA_3_CH5>,
+ <&pd IMX_SC_R_DMA_3_CH6>,
+ <&pd IMX_SC_R_DMA_3_CH7>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml
new file mode 100644
index 000000000000..92288d76d51b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,elo-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Elo DMA Controller
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+description:
+ This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
+ series chips such as mpc8315, mpc8349, mpc8379 etc.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc8313-dma
+ - fsl,mpc8315-dma
+ - fsl,mpc8323-dma
+ - fsl,mpc8347-dma
+ - fsl,mpc8349-dma
+ - fsl,mpc8360-dma
+ - fsl,mpc8377-dma
+ - fsl,mpc8378-dma
+ - fsl,mpc8379-dma
+ - const: fsl,elo-dma
+
+ reg:
+ items:
+ - description:
+ DMA General Status Register, i.e. DGSR which contains status for
+ all the 4 DMA channels.
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Controller index. 0 for controller @ 0x8100.
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ interrupts:
+ maxItems: 1
+ description: Controller interrupt.
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^dma-channel@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ oneOf:
+ # native DMA channel
+ - items:
+ - enum:
+ - fsl,mpc8315-dma-channel
+ - fsl,mpc8323-dma-channel
+ - fsl,mpc8347-dma-channel
+ - fsl,mpc8349-dma-channel
+ - fsl,mpc8360-dma-channel
+ - fsl,mpc8377-dma-channel
+ - fsl,mpc8378-dma-channel
+ - fsl,mpc8379-dma-channel
+ - const: fsl,elo-dma-channel
+
+ # audio DMA channel, see fsl,ssi.yaml
+ - const: fsl,ssi-dma-channel
+
+ reg:
+ maxItems: 1
+
+ cell-index:
+ description: DMA channel index starts at 0.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Per-channel interrupt. Only necessary if no controller interrupt has
+ been provided.
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ dma@82a8 {
+ compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
+ reg = <0x82a8 4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x8100 0x1a4>;
+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;
+ cell-index = <0>;
+
+ dma-channel@0 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ reg = <0 0x80>;
+ cell-index = <0>;
+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ dma-channel@80 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ dma-channel@100 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ dma-channel@180 {
+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml
new file mode 100644
index 000000000000..0f5e475657a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,elo3-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Elo3 DMA Controller
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+description:
+ DMA controller which has same function as EloPlus except that Elo3 has 8
+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+properties:
+ compatible:
+ const: fsl,elo3-dma
+
+ reg:
+ items:
+ - description:
+ DMA General Status Registers starting from DGSR0, for channel 1~4
+ - description:
+ DMA General Status Registers starting from DGSR1, for channel 5~8
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ "^dma-channel@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ # native DMA channel
+ - fsl,eloplus-dma-channel
+
+ # audio DMA channel, see fsl,ssi.yaml
+ - fsl,ssi-dma-channel
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description:
+ Per-channel interrupt. Only necessary if no controller interrupt has
+ been provided.
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ dma@100300 {
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x100100 0x500>;
+
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml
new file mode 100644
index 000000000000..8992f244c4db
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,eloplus-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale EloPlus DMA Controller
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+description:
+ This is a 4-channel DMA controller with extended addresses and chaining,
+ mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as
+ mpc8540, mpc8641 p4080, bsc9131 etc.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,mpc8540-dma
+ - fsl,mpc8541-dma
+ - fsl,mpc8548-dma
+ - fsl,mpc8555-dma
+ - fsl,mpc8560-dma
+ - fsl,mpc8572-dma
+ - fsl,mpc8641-dma
+ - const: fsl,eloplus-dma
+ - const: fsl,eloplus-dma
+
+ reg:
+ items:
+ - description:
+ DMA General Status Register, i.e. DGSR which contains
+ status for all the 4 DMA channels
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ controller index. 0 for controller @ 0x21000, 1 for controller @ 0xc000
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ interrupts:
+ maxItems: 1
+ description: Controller interrupt.
+
+patternProperties:
+ "^dma-channel@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ oneOf:
+ # native DMA channel
+ - items:
+ - enum:
+ - fsl,mpc8540-dma-channel
+ - fsl,mpc8541-dma-channel
+ - fsl,mpc8548-dma-channel
+ - fsl,mpc8555-dma-channel
+ - fsl,mpc8560-dma-channel
+ - fsl,mpc8572-dma-channel
+ - const: fsl,eloplus-dma-channel
+
+ # audio DMA channel, see fsl,ssi.yaml
+ - const: fsl,ssi-dma-channel
+
+ reg:
+ maxItems: 1
+
+ cell-index:
+ description: DMA channel index starts at 0.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Per-channel interrupt. Only necessary if no controller interrupt has
+ been provided.
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ dma@21300 {
+ compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
+ reg = <0x21300 4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x21100 0x200>;
+ cell-index = <0>;
+
+ dma-channel@0 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <0 0x80>;
+ cell-index = <0>;
+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ dma-channel@80 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ dma-channel@100 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ dma-channel@180 {
+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl,imx-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,imx-dma.yaml
new file mode 100644
index 000000000000..75957f9fb58b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,imx-dma.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,imx-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Direct Memory Access (DMA) Controller for i.MX
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx1-dma
+ - fsl,imx21-dma
+ - fsl,imx27-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: DMA complete interrupt
+ - description: DMA Error interrupt
+ minItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
+
+ "#dma-cells":
+ const: 1
+
+ dma-channels:
+ const: 16
+
+ dma-requests:
+ description: Number of DMA requests supported.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx27-clock.h>
+
+ dma-controller@10001000 {
+ compatible = "fsl,imx27-dma";
+ reg = <0x10001000 0x1000>;
+ interrupts = <32 33>;
+ #dma-cells = <1>;
+ dma-channels = <16>;
+ clocks = <&clks IMX27_CLK_DMA_IPG_GATE>, <&clks IMX27_CLK_DMA_AHB_GATE>;
+ clock-names = "ipg", "ahb";
+ };
diff --git a/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml b/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
new file mode 100644
index 000000000000..738b25b88b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,imx-sdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Smart Direct Memory Access (SDMA) Controller for i.MX
+
+maintainers:
+ - Joy Zou <joy.zou@nxp.com>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx50-sdma
+ - fsl,imx51-sdma
+ - fsl,imx53-sdma
+ - fsl,imx6q-sdma
+ - fsl,imx7d-sdma
+ - const: fsl,imx35-sdma
+ - items:
+ - enum:
+ - fsl,imx6sx-sdma
+ - fsl,imx6sl-sdma
+ - const: fsl,imx6q-sdma
+ - items:
+ - const: fsl,imx6ul-sdma
+ - const: fsl,imx6q-sdma
+ - const: fsl,imx35-sdma
+ - items:
+ - const: fsl,imx6sll-sdma
+ - const: fsl,imx6ul-sdma
+ - items:
+ - const: fsl,imx8mq-sdma
+ - const: fsl,imx7d-sdma
+ - items:
+ - enum:
+ - fsl,imx8mp-sdma
+ - fsl,imx8mn-sdma
+ - fsl,imx8mm-sdma
+ - const: fsl,imx8mq-sdma
+ - items:
+ - enum:
+ - fsl,imx25-sdma
+ - fsl,imx31-sdma
+ - fsl,imx35-sdma
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,sdma-ram-script-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Should contain the full path of SDMA RAM scripts firmware.
+
+ "#dma-cells":
+ const: 3
+ description: |
+ The first cell: request/event ID
+
+ The second cell: peripheral types ID
+ enum:
+ - MCU domain SSI: 0
+ - Shared SSI: 1
+ - MMC: 2
+ - SDHC: 3
+ - MCU domain UART: 4
+ - Shared UART: 5
+ - FIRI: 6
+ - MCU domain CSPI: 7
+ - Shared CSPI: 8
+ - SIM: 9
+ - ATA: 10
+ - CCM: 11
+ - External peripheral: 12
+ - Memory Stick Host Controller: 13
+ - Shared Memory Stick Host Controller: 14
+ - DSP: 15
+ - Memory: 16
+ - FIFO type Memory: 17
+ - SPDIF: 18
+ - IPU Memory: 19
+ - ASRC: 20
+ - ESAI: 21
+ - SSI Dual FIFO: 22
+ description: needs firmware more than ver 2
+ - Shared ASRC: 23
+ - SAI: 24
+ - Multi SAI: 25
+ - HDMI Audio: 26
+ - I2C: 27
+
+ The third cell: transfer priority ID
+ enum:
+ - High: 0
+ - Medium: 1
+ - Low: 2
+
+ gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the General Purpose Register (GPR) node
+
+ fsl,sdma-event-remap:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ maxItems: 2
+ items:
+ items:
+ - description: GPR register offset
+ - description: GPR register shift
+ - description: GPR register value
+ description: |
+ Register bits of sdma event remap, the format is <reg shift val>.
+ The order is <RX>, <TX>.
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
+
+ iram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the On-chip RAM (OCRAM) node.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,sdma-ram-script-name
+
+additionalProperties: false
+
+examples:
+ - |
+ sdma: dma-controller@83fb0000 {
+ compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
+ reg = <0x83fb0000 0x4000>;
+ interrupts = <6>;
+ #dma-cells = <3>;
+ fsl,sdma-ram-script-name = "sdma-imx51.bin";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml
new file mode 100644
index 000000000000..9102b615dbd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Direct Memory Access (DMA) Controller from i.MX23/i.MX28
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+allOf:
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8qxp-dma-apbh
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx23-dma-apbx
+ then:
+ properties:
+ interrupt-names:
+ items:
+ - const: audio-adc
+ - const: audio-dac
+ - const: spdif-tx
+ - const: i2c
+ - const: saif0
+ - const: empty0
+ - const: auart0-rx
+ - const: auart0-tx
+ - const: auart1-rx
+ - const: auart1-tx
+ - const: saif1
+ - const: empty1
+ - const: empty2
+ - const: empty3
+ - const: empty4
+ - const: empty5
+ else:
+ properties:
+ interrupt-names: false
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx6q-dma-apbh
+ - fsl,imx6sx-dma-apbh
+ - fsl,imx7d-dma-apbh
+ - fsl,imx8dxl-dma-apbh
+ - fsl,imx8mm-dma-apbh
+ - fsl,imx8mn-dma-apbh
+ - fsl,imx8mp-dma-apbh
+ - fsl,imx8mq-dma-apbh
+ - fsl,imx8qm-dma-apbh
+ - fsl,imx8qxp-dma-apbh
+ - const: fsl,imx28-dma-apbh
+ - enum:
+ - fsl,imx23-dma-apbh
+ - fsl,imx23-dma-apbx
+ - fsl,imx28-dma-apbh
+ - fsl,imx28-dma-apbx
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ minItems: 4
+ maxItems: 16
+
+ interrupt-names:
+ minItems: 4
+ maxItems: 16
+
+ "#dma-cells":
+ const: 1
+
+ dma-channels:
+ enum: [4, 8, 16]
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#dma-cells"
+ - dma-channels
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-parent = <&irqc>;
+
+ dma-controller@80004000 {
+ compatible = "fsl,imx28-dma-apbh";
+ reg = <0x80004000 0x2000>;
+ interrupts = <82 83 84 85
+ 88 88 88 88
+ 88 88 88 88
+ 87 86 0 0>;
+ #dma-cells = <1>;
+ dma-channels = <16>;
+ };
+
+ dma-controller@80024000 {
+ compatible = "fsl,imx28-dma-apbx";
+ reg = <0x80024000 0x2000>;
+ interrupts = <78 79 66 0
+ 80 81 68 69
+ 70 71 72 73
+ 74 75 76 77>;
+ #dma-cells = <1>;
+ dma-channels = <16>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
deleted file mode 100644
index 1c9929d53727..000000000000
--- a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Freescale Direct Memory Access (DMA) Controller for i.MX
-
-This document will only describe differences to the generic DMA Controller and
-DMA request bindings as described in dma/dma.txt .
-
-* DMA controller
-
-Required properties:
-- compatible : Should be "fsl,<chip>-dma". chip can be imx1, imx21 or imx27
-- reg : Should contain DMA registers location and length
-- interrupts : First item should be DMA interrupt, second one is optional and
- should contain DMA Error interrupt
-- #dma-cells : Has to be 1. imx-dma does not support anything else.
-
-Optional properties:
-- dma-channels : Number of DMA channels supported. Should be 16.
-- #dma-channels : deprecated
-- dma-requests : Number of DMA requests supported.
-- #dma-requests : deprecated
-
-Example:
-
- dma: dma@10001000 {
- compatible = "fsl,imx27-dma";
- reg = <0x10001000 0x1000>;
- interrupts = <32 33>;
- #dma-cells = <1>;
- dma-channels = <16>;
- };
-
-
-* DMA client
-
-Clients have to specify the DMA requests with phandles in a list.
-
-Required properties:
-- dmas: List of one or more DMA request specifiers. One DMA request specifier
- consists of a phandle to the DMA controller followed by the integer
- specifying the request line.
-- dma-names: List of string identifiers for the DMA requests. For the correct
- names, have a look at the specific client driver.
-
-Example:
-
- sdhci1: sdhci@10013000 {
- ...
- dmas = <&dma 7>;
- dma-names = "rx-tx";
- ...
- };
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
deleted file mode 100644
index 12c316ff4834..000000000000
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ /dev/null
@@ -1,118 +0,0 @@
-* Freescale Smart Direct Memory Access (SDMA) Controller for i.MX
-
-Required properties:
-- compatible : Should be one of
- "fsl,imx25-sdma"
- "fsl,imx31-sdma", "fsl,imx31-to1-sdma", "fsl,imx31-to2-sdma"
- "fsl,imx35-sdma", "fsl,imx35-to1-sdma", "fsl,imx35-to2-sdma"
- "fsl,imx51-sdma"
- "fsl,imx53-sdma"
- "fsl,imx6q-sdma"
- "fsl,imx7d-sdma"
- "fsl,imx6ul-sdma"
- "fsl,imx8mq-sdma"
- "fsl,imx8mm-sdma"
- "fsl,imx8mn-sdma"
- "fsl,imx8mp-sdma"
- The -to variants should be preferred since they allow to determine the
- correct ROM script addresses needed for the driver to work without additional
- firmware.
-- reg : Should contain SDMA registers location and length
-- interrupts : Should contain SDMA interrupt
-- #dma-cells : Must be <3>.
- The first cell specifies the DMA request/event ID. See details below
- about the second and third cell.
-- fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
- scripts firmware
-
-The second cell of dma phandle specifies the peripheral type of DMA transfer.
-The full ID of peripheral types can be found below.
-
- ID transfer type
- ---------------------
- 0 MCU domain SSI
- 1 Shared SSI
- 2 MMC
- 3 SDHC
- 4 MCU domain UART
- 5 Shared UART
- 6 FIRI
- 7 MCU domain CSPI
- 8 Shared CSPI
- 9 SIM
- 10 ATA
- 11 CCM
- 12 External peripheral
- 13 Memory Stick Host Controller
- 14 Shared Memory Stick Host Controller
- 15 DSP
- 16 Memory
- 17 FIFO type Memory
- 18 SPDIF
- 19 IPU Memory
- 20 ASRC
- 21 ESAI
- 22 SSI Dual FIFO (needs firmware ver >= 2)
- 23 Shared ASRC
- 24 SAI
-
-The third cell specifies the transfer priority as below.
-
- ID transfer priority
- -------------------------
- 0 High
- 1 Medium
- 2 Low
-
-Optional properties:
-
-- gpr : The phandle to the General Purpose Register (GPR) node.
-- fsl,sdma-event-remap : Register bits of sdma event remap, the format is
- <reg shift val>.
- reg is the GPR register offset.
- shift is the bit position inside the GPR register.
- val is the value of the bit (0 or 1).
-
-Examples:
-
-sdma@83fb0000 {
- compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
- reg = <0x83fb0000 0x4000>;
- interrupts = <6>;
- #dma-cells = <3>;
- fsl,sdma-ram-script-name = "sdma-imx51.bin";
-};
-
-DMA clients connected to the i.MX SDMA controller must use the format
-described in the dma.txt file.
-
-Examples:
-
-ssi2: ssi@70014000 {
- compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
- reg = <0x70014000 0x4000>;
- interrupts = <30>;
- clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
- dma-names = "rx", "tx";
- fsl,fifo-depth = <15>;
-};
-
-Using the fsl,sdma-event-remap property:
-
-If we want to use SDMA on the SAI1 port on a MX6SX:
-
-&sdma {
- gpr = <&gpr>;
- /* SDMA events remap for SAI1_RX and SAI1_TX */
- fsl,sdma-event-remap = <0 15 1>, <0 16 1>;
-};
-
-The fsl,sdma-event-remap property in this case has two values:
-- <0 15 1> means that the offset is 0, so GPR0 is the register of the
-SDMA remap. Bit 15 of GPR0 selects between UART4_RX and SAI1_RX.
-Setting bit 15 to 1 selects SAI1_RX.
-- <0 16 1> means that the offset is 0, so GPR0 is the register of the
-SDMA remap. Bit 16 of GPR0 selects between UART4_TX and SAI1_TX.
-Setting bit 16 to 1 selects SAI1_TX.
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
deleted file mode 100644
index e30e184f50c7..000000000000
--- a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-* Freescale MXS DMA
-
-Required properties:
-- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
-- reg : Should contain registers location and length
-- interrupts : Should contain the interrupt numbers of DMA channels.
- If a channel is empty/reserved, 0 should be filled in place.
-- #dma-cells : Must be <1>. The number cell specifies the channel ID.
-- dma-channels : Number of channels supported by the DMA controller
-
-Optional properties:
-- interrupt-names : Name of DMA channel interrupts
-
-Supported chips:
-imx23, imx28.
-
-Examples:
-
-dma_apbh: dma-apbh@80004000 {
- compatible = "fsl,imx28-dma-apbh";
- reg = <0x80004000 0x2000>;
- interrupts = <82 83 84 85
- 88 88 88 88
- 88 88 88 88
- 87 86 0 0>;
- interrupt-names = "ssp0", "ssp1", "ssp2", "ssp3",
- "gpmi0", "gmpi1", "gpmi2", "gmpi3",
- "gpmi4", "gmpi5", "gpmi6", "gmpi7",
- "hsadc", "lcdif", "empty", "empty";
- #dma-cells = <1>;
- dma-channels = <16>;
-};
-
-dma_apbx: dma-apbx@80024000 {
- compatible = "fsl,imx28-dma-apbx";
- reg = <0x80024000 0x2000>;
- interrupts = <78 79 66 0
- 80 81 68 69
- 70 71 72 73
- 74 75 76 77>;
- interrupt-names = "auart4-rx", "auart4-tx", "spdif-tx", "empty",
- "saif0", "saif1", "i2c0", "i2c1",
- "auart0-rx", "auart0-tx", "auart1-rx", "auart1-tx",
- "auart2-rx", "auart2-tx", "auart3-rx", "auart3-tx";
- #dma-cells = <1>;
- dma-channels = <16>;
-};
-
-DMA clients connected to the MXS DMA controller must use the format
-described in the dma.txt file.
-
-Examples:
-
-auart0: serial@8006a000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
- reg = <0x8006a000 0x2000>;
- interrupts = <112>;
- dmas = <&dma_apbx 8>, <&dma_apbx 9>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
deleted file mode 100644
index da371c4d406c..000000000000
--- a/Documentation/devicetree/bindings/dma/fsl-qdma.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-NXP Layerscape SoC qDMA Controller
-==================================
-
-This device follows the generic DMA bindings defined in dma/dma.txt.
-
-Required properties:
-
-- compatible: Must be one of
- "fsl,ls1021a-qdma": for LS1021A Board
- "fsl,ls1028a-qdma": for LS1028A Board
- "fsl,ls1043a-qdma": for ls1043A Board
- "fsl,ls1046a-qdma": for ls1046A Board
-- reg: Should contain the register's base address and length.
-- interrupts: Should contain a reference to the interrupt used by this
- device.
-- interrupt-names: Should contain interrupt names:
- "qdma-queue0": the block0 interrupt
- "qdma-queue1": the block1 interrupt
- "qdma-queue2": the block2 interrupt
- "qdma-queue3": the block3 interrupt
- "qdma-error": the error interrupt
-- fsl,dma-queues: Should contain number of queues supported.
-- dma-channels: Number of DMA channels supported
-- block-number: the virtual block number
-- block-offset: the offset of different virtual block
-- status-sizes: status queue size of per virtual block
-- queue-sizes: command queue size of per virtual block, the size number
- based on queues
-
-Optional properties:
-
-- dma-channels: Number of DMA channels supported by the controller.
-- big-endian: If present registers and hardware scatter/gather descriptors
- of the qDMA are implemented in big endian mode, otherwise in little
- mode.
-
-Examples:
-
- qdma: dma-controller@8390000 {
- compatible = "fsl,ls1021a-qdma";
- reg = <0x0 0x8388000 0x0 0x1000>, /* Controller regs */
- <0x0 0x8389000 0x0 0x1000>, /* Status regs */
- <0x0 0x838a000 0x0 0x2000>; /* Block regs */
- interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "qdma-error",
- "qdma-queue0", "qdma-queue1";
- dma-channels = <8>;
- block-number = <2>;
- block-offset = <0x1000>;
- fsl,dma-queues = <2>;
- status-sizes = <64>;
- queue-sizes = <64 64>;
- big-endian;
- };
-
-DMA clients must use the format described in dma/dma.txt file.
diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.yaml b/Documentation/devicetree/bindings/dma/fsl-qdma.yaml
new file mode 100644
index 000000000000..9401b1f6300d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-qdma.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/fsl-qdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Layerscape SoC qDMA Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,ls1021a-qdma
+ - items:
+ - enum:
+ - fsl,ls1028a-qdma
+ - fsl,ls1043a-qdma
+ - fsl,ls1046a-qdma
+ - const: fsl,ls1021a-qdma
+
+ reg:
+ items:
+ - description: Controller regs
+ - description: Status regs
+ - description: Block regs
+
+ interrupts:
+ minItems: 2
+ maxItems: 5
+
+ interrupt-names:
+ minItems: 2
+ items:
+ - const: qdma-error
+ - const: qdma-queue0
+ - const: qdma-queue1
+ - const: qdma-queue2
+ - const: qdma-queue3
+
+ dma-channels:
+ minimum: 1
+ maximum: 64
+
+ fsl,dma-queues:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Should contain number of queues supported.
+ minimum: 1
+ maximum: 4
+
+ block-number:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: the virtual block number
+
+ block-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: the offset of different virtual block
+
+ status-sizes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: status queue size of per virtual block
+
+ queue-sizes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ command queue size of per virtual block, the size number
+ based on queues
+
+ big-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If present registers and hardware scatter/gather descriptors
+ of the qDMA are implemented in big endian mode, otherwise in little
+ mode.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - fsl,dma-queues
+ - block-number
+ - block-offset
+ - status-sizes
+ - queue-sizes
+
+allOf:
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,ls1028a-qdma
+ - fsl,ls1043a-qdma
+ - fsl,ls1046a-qdma
+ then:
+ properties:
+ interrupts:
+ minItems: 5
+ interrupt-names:
+ minItems: 5
+ else:
+ properties:
+ interrupts:
+ maxItems: 3
+ interrupt-names:
+ maxItems: 3
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ dma-controller@8390000 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x8388000 0x1000>, /* Controller regs */
+ <0x8389000 0x1000>, /* Status regs */
+ <0x838a000 0x2000>; /* Block regs */
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "qdma-error", "qdma-queue0", "qdma-queue1";
+ #dma-cells = <1>;
+ dma-channels = <8>;
+ block-number = <2>;
+ block-offset = <0x1000>;
+ status-sizes = <64>;
+ queue-sizes = <64 64>;
+ big-endian;
+ fsl,dma-queues = <2>;
+ };
+
diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
index 3b0b3b919af8..d9cca3006e73 100644
--- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
+++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/dma/ingenic,dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs DMA Controller DT bindings
+title: Ingenic SoCs DMA Controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -18,6 +18,7 @@ properties:
- enum:
- ingenic,jz4740-dma
- ingenic,jz4725b-dma
+ - ingenic,jz4755-dma
- ingenic,jz4760-dma
- ingenic,jz4760-bdma
- ingenic,jz4760-mdma
@@ -67,7 +68,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description: >
Bitmask of channels to reserve for devices that need a specific
- channel. These channels will only be assigned when explicitely
+ channel. These channels will only be assigned when explicitly
requested by a client. The primary use for this is channels 0 and
1, which can be configured to have special behaviour for NAND/BCH
when using programmable firmware.
diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
index a5c4be783593..d6bb553a2c6f 100644
--- a/Documentation/devicetree/bindings/dma/intel,ldma.yaml
+++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
@@ -11,7 +11,7 @@ maintainers:
- mallikarjunax.reddy@intel.com
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/loongson,ls1b-apbdma.yaml b/Documentation/devicetree/bindings/dma/loongson,ls1b-apbdma.yaml
new file mode 100644
index 000000000000..4c7d2fb7b292
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/loongson,ls1b-apbdma.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/loongson,ls1b-apbdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 APB DMA Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ Loongson-1 APB DMA controller provides 3 independent channels for
+ peripherals such as NAND, audio playback and capture.
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls1b-apbdma
+ - items:
+ - enum:
+ - loongson,ls1a-apbdma
+ - loongson,ls1c-apbdma
+ - const: loongson,ls1b-apbdma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: NAND interrupt
+ - description: Audio playback interrupt
+ - description: Audio capture interrupt
+
+ interrupt-names:
+ items:
+ - const: ch0
+ - const: ch1
+ - const: ch2
+
+ '#dma-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - '#dma-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ dma-controller@1fd01160 {
+ compatible = "loongson,ls1b-apbdma";
+ reg = <0x1fd01160 0x4>;
+ interrupt-parent = <&intc0>;
+ interrupts = <13 IRQ_TYPE_EDGE_RISING>,
+ <14 IRQ_TYPE_EDGE_RISING>,
+ <15 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ch0", "ch1", "ch2";
+ #dma-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/loongson,ls2x-apbdma.yaml b/Documentation/devicetree/bindings/dma/loongson,ls2x-apbdma.yaml
new file mode 100644
index 000000000000..6a1b49a49a64
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/loongson,ls2x-apbdma.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/loongson,ls2x-apbdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS2X APB DMA controller
+
+description:
+ The Loongson LS2X APB DMA controller is used for transferring data
+ between system memory and the peripherals on the APB bus.
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls2k1000-apbdma
+ - items:
+ - const: loongson,ls2k0500-apbdma
+ - const: loongson,ls2k1000-apbdma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#dma-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - '#dma-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/loongson,ls2k-clk.h>
+
+ dma-controller@1fe00c00 {
+ compatible = "loongson,ls2k1000-apbdma";
+ reg = <0x1fe00c00 0x8>;
+ interrupt-parent = <&liointc1>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LOONGSON2_APB_CLK>;
+ #dma-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/lpc1850-dmamux.txt b/Documentation/devicetree/bindings/dma/lpc1850-dmamux.txt
deleted file mode 100644
index 87740adb2995..000000000000
--- a/Documentation/devicetree/bindings/dma/lpc1850-dmamux.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-NXP LPC18xx/43xx DMA MUX (DMA request router)
-
-Required properties:
-- compatible: "nxp,lpc1850-dmamux"
-- reg: Memory map for accessing module
-- #dma-cells: Should be set to <3>.
- * 1st cell contain the master dma request signal
- * 2nd cell contain the mux value (0-3) for the peripheral
- * 3rd cell contain either 1 or 2 depending on the AHB
- master used.
-- dma-requests: Number of DMA requests for the mux
-- dma-masters: phandle pointing to the DMA controller
-
-The DMA controller node need to have the following poroperties:
-- dma-requests: Number of DMA requests the controller can handle
-
-Example:
-
-dmac: dma@40002000 {
- compatible = "nxp,lpc1850-gpdma", "arm,pl080", "arm,primecell";
- arm,primecell-periphid = <0x00041080>;
- reg = <0x40002000 0x1000>;
- interrupts = <2>;
- clocks = <&ccu1 CLK_CPU_DMA>;
- clock-names = "apb_pclk";
- #dma-cells = <2>;
- dma-channels = <8>;
- dma-requests = <16>;
- lli-bus-interface-ahb1;
- lli-bus-interface-ahb2;
- mem-bus-interface-ahb1;
- mem-bus-interface-ahb2;
- memcpy-burst-size = <256>;
- memcpy-bus-width = <32>;
-};
-
-dmamux: dma-mux {
- compatible = "nxp,lpc1850-dmamux";
- #dma-cells = <3>;
- dma-requests = <64>;
- dma-masters = <&dmac>;
-};
-
-uart0: serial@40081000 {
- compatible = "nxp,lpc1850-uart", "ns16550a";
- reg = <0x40081000 0x1000>;
- reg-shift = <2>;
- interrupts = <24>;
- clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>;
- clock-names = "uartclk", "reg";
- dmas = <&dmamux 1 1 2
- &dmamux 2 1 2>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
new file mode 100644
index 000000000000..d447d5207be0
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/marvell,mmp-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MMP DMA controller
+
+maintainers:
+ - Duje Mihanović <duje.mihanovic@skole.hr>
+
+description:
+ Marvell MMP SoCs may have two types of DMA controllers, peripheral and audio.
+
+properties:
+ compatible:
+ enum:
+ - marvell,pdma-1.0
+ - marvell,adma-1.0
+ - marvell,pxa910-squ
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Interrupt lines for the controller, may be shared or one per DMA channel
+ minItems: 1
+
+ asram:
+ description:
+ A phandle to the SRAM pool
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ '#dma-channels':
+ deprecated: true
+
+ '#dma-requests':
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#dma-cells'
+
+allOf:
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,pdma-1.0
+ then:
+ properties:
+ asram: false
+ else:
+ required:
+ - asram
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dma-controller@d4000000 {
+ compatible = "marvell,pdma-1.0";
+ reg = <0xd4000000 0x10000>;
+ interrupts = <47>;
+ #dma-cells = <2>;
+ dma-channels = <16>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/marvell,orion-xor.yaml b/Documentation/devicetree/bindings/dma/marvell,orion-xor.yaml
new file mode 100644
index 000000000000..add08257ec59
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/marvell,orion-xor.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/marvell,orion-xor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell XOR engine
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: marvell,armada-380-xor
+ - const: marvell,orion-xor
+ - enum:
+ - marvell,armada-3700-xor
+ - marvell,orion-xor
+
+ reg:
+ items:
+ - description: Low registers for the XOR engine
+ - description: High registers for the XOR engine
+
+ clocks:
+ maxItems: 1
+
+patternProperties:
+ "^(channel|xor)[0-9]+$":
+ description: XOR channel sub-node
+ type: object
+ additionalProperties: false
+
+ properties:
+ interrupts:
+ description: Interrupt specifier for the XOR channel
+ items:
+ - description: Interrupt for this channel
+
+ dmacap,memcpy:
+ type: boolean
+ deprecated: true
+ description:
+ Indicates that the XOR channel is capable of memcpy operations
+
+ dmacap,memset:
+ type: boolean
+ deprecated: true
+ description:
+ Indicates that the XOR channel is capable of memset operations
+
+ dmacap,xor:
+ type: boolean
+ deprecated: true
+ description:
+ Indicates that the XOR channel is capable of xor operations
+
+ required:
+ - interrupts
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ xor@d0060900 {
+ compatible = "marvell,orion-xor";
+ reg = <0xd0060900 0x100>,
+ <0xd0060b00 0x100>;
+ clocks = <&coreclk 0>;
+
+ xor00 {
+ interrupts = <51>;
+ };
+ xor01 {
+ interrupts = <52>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/dma/marvell,xor-v2.yaml b/Documentation/devicetree/bindings/dma/marvell,xor-v2.yaml
new file mode 100644
index 000000000000..646b4e779d8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/marvell,xor-v2.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/marvell,xor-v2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell XOR v2 engines
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+
+properties:
+ compatible:
+ oneOf:
+ - const: marvell,xor-v2
+ - items:
+ - enum:
+ - marvell,armada-7k-xor
+ - const: marvell,xor-v2
+
+ reg:
+ items:
+ - description: DMA registers
+ - description: global registers
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: reg
+
+ msi-parent:
+ description:
+ Phandle to the MSI-capable interrupt controller used for
+ interrupts.
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - msi-parent
+ - dma-coherent
+
+additionalProperties: false
+
+examples:
+ - |
+ xor0@6a0000 {
+ compatible = "marvell,armada-7k-xor", "marvell,xor-v2";
+ reg = <0x6a0000 0x1000>, <0x6b0000 0x1000>;
+ clocks = <&ap_clk 0>, <&ap_clk 1>;
+ clock-names = "core", "reg";
+ msi-parent = <&gic_v2m0>;
+ dma-coherent;
+ };
diff --git a/Documentation/devicetree/bindings/dma/mediatek,mt7622-hsdma.yaml b/Documentation/devicetree/bindings/dma/mediatek,mt7622-hsdma.yaml
new file mode 100644
index 000000000000..3f1e120e40a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mediatek,mt7622-hsdma.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/mediatek,mt7622-hsdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek High-Speed DMA Controller
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7622-hsdma
+ - mediatek,mt7623-hsdma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: hsdma
+
+ power-domains:
+ maxItems: 1
+
+ "#dma-cells":
+ description: Channel number
+ const: 1
+
+required:
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/mt2701-power.h>
+
+ dma-controller@1b007000 {
+ compatible = "mediatek,mt7623-hsdma";
+ reg = <0x1b007000 0x1000>;
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&ethsys CLK_ETHSYS_HSDMA>;
+ clock-names = "hsdma";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+ #dma-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
index 19ea8dcbcbce..dab468a88942 100644
--- a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
@@ -14,7 +14,7 @@ description: |
for the UART peripheral bus.
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -22,6 +22,7 @@ properties:
- items:
- enum:
- mediatek,mt2712-uart-dma
+ - mediatek,mt6795-uart-dma
- mediatek,mt8365-uart-dma
- mediatek,mt8516-uart-dma
- const: mediatek,mt6577-uart-dma
diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt
deleted file mode 100644
index ec18bf0a802a..000000000000
--- a/Documentation/devicetree/bindings/dma/mmp-dma.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-* MARVELL MMP DMA controller
-
-Marvell Peripheral DMA Controller
-Used platforms: pxa688, pxa910, pxa3xx, etc
-
-Required properties:
-- compatible: Should be "marvell,pdma-1.0"
-- reg: Should contain DMA registers location and length.
-- interrupts: Either contain all of the per-channel DMA interrupts
- or one irq for pdma device
-
-Optional properties:
-- dma-channels: Number of DMA channels supported by the controller (defaults
- to 32 when not specified)
-- #dma-channels: deprecated
-- dma-requests: Number of DMA requestor lines supported by the controller
- (defaults to 32 when not specified)
-- #dma-requests: deprecated
-
-"marvell,pdma-1.0"
-Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
-
-Examples:
-
-/*
- * Each channel has specific irq
- * ICU parse out irq channel from ICU register,
- * while DMA controller may not able to distinguish the irq channel
- * Using this method, interrupt-parent is required as demuxer
- * For example, pxa688 icu register 0x128, bit 0~15 is PDMA channel irq,
- * 18~21 is ADMA irq
- */
-pdma: dma-controller@d4000000 {
- compatible = "marvell,pdma-1.0";
- reg = <0xd4000000 0x10000>;
- interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>;
- interrupt-parent = <&intcmux32>;
- dma-channels = <16>;
- };
-
-/*
- * One irq for all channels
- * Dmaengine driver (DMA controller) distinguish irq channel via
- * parsing internal register
- */
-pdma: dma-controller@d4000000 {
- compatible = "marvell,pdma-1.0";
- reg = <0xd4000000 0x10000>;
- interrupts = <47>;
- dma-channels = <16>;
- };
-
-
-Marvell Two Channel DMA Controller used specifically for audio
-Used platforms: pxa688, pxa910
-
-Required properties:
-- compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ"
-- reg: Should contain DMA registers location and length.
-- interrupts: Either contain all of the per-channel DMA interrupts
- or one irq for dma device
-
-"marvell,adma-1.0" used on pxa688
-"marvell,pxa910-squ" used on pxa910
-
-Examples:
-
-/* each channel has specific irq */
-adma0: dma-controller@d42a0800 {
- compatible = "marvell,adma-1.0";
- reg = <0xd42a0800 0x100>;
- interrupts = <18 19>;
- interrupt-parent = <&intcmux32>;
- };
-
-/* One irq for all channels */
-squ: dma-controller@d42a0800 {
- compatible = "marvell,pxa910-squ";
- reg = <0xd42a0800 0x100>;
- interrupts = <46>;
- };
diff --git a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
deleted file mode 100644
index 4bb317359dc6..000000000000
--- a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-MediaTek High-Speed DMA Controller
-==================================
-
-This device follows the generic DMA bindings defined in dma/dma.txt.
-
-Required properties:
-
-- compatible: Must be one of
- "mediatek,mt7622-hsdma": for MT7622 SoC
- "mediatek,mt7623-hsdma": for MT7623 SoC
-- reg: Should contain the register's base address and length.
-- interrupts: Should contain a reference to the interrupt used by this
- device.
-- clocks: Should be the clock specifiers corresponding to the entry in
- clock-names property.
-- clock-names: Should contain "hsdma" entries.
-- power-domains: Phandle to the power domain that the device is part of
-- #dma-cells: The length of the DMA specifier, must be <1>. This one cell
- in dmas property of a client device represents the channel
- number.
-Example:
-
- hsdma: dma-controller@1b007000 {
- compatible = "mediatek,mt7623-hsdma";
- reg = <0 0x1b007000 0 0x1000>;
- interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&ethsys CLK_ETHSYS_HSDMA>;
- clock-names = "hsdma";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
- #dma-cells = <1>;
- };
-
-DMA clients must use the format described in dma/dma.txt file.
diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
deleted file mode 100644
index 9c38bbe7e6d7..000000000000
--- a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Marvell XOR v2 engines
-
-Required properties:
-- compatible: one of the following values:
- "marvell,armada-7k-xor"
- "marvell,xor-v2"
-- reg: Should contain registers location and length (two sets)
- the first set is the DMA registers
- the second set is the global registers
-- msi-parent: Phandle to the MSI-capable interrupt controller used for
- interrupts.
-
-Optional properties:
-- clocks: Optional reference to the clocks used by the XOR engine.
-- clock-names: mandatory if there is a second clock, in this case the
- name must be "core" for the first clock and "reg" for the second
- one
-
-
-Example:
-
- xor0@400000 {
- compatible = "marvell,xor-v2";
- reg = <0x400000 0x1000>,
- <0x410000 0x1000>;
- msi-parent = <&gic_v2m0>;
- dma-coherent;
- };
diff --git a/Documentation/devicetree/bindings/dma/mv-xor.txt b/Documentation/devicetree/bindings/dma/mv-xor.txt
deleted file mode 100644
index 0ffb4d8766a8..000000000000
--- a/Documentation/devicetree/bindings/dma/mv-xor.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-* Marvell XOR engines
-
-Required properties:
-- compatible: Should be one of the following:
- - "marvell,orion-xor"
- - "marvell,armada-380-xor"
- - "marvell,armada-3700-xor".
-- reg: Should contain registers location and length (two sets)
- the first set is the low registers, the second set the high
- registers for the XOR engine.
-- clocks: pointer to the reference clock
-
-The DT node must also contains sub-nodes for each XOR channel that the
-XOR engine has. Those sub-nodes have the following required
-properties:
-- interrupts: interrupt of the XOR channel
-
-The sub-nodes used to contain one or several of the following
-properties, but they are now deprecated:
-- dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
-- dmacap,memset to indicate that the XOR channel is capable of memset operations
-- dmacap,xor to indicate that the XOR channel is capable of xor operations
-- dmacap,interrupt to indicate that the XOR channel is capable of
- generating interrupts
-
-Example:
-
-xor@d0060900 {
- compatible = "marvell,orion-xor";
- reg = <0xd0060900 0x100
- 0xd0060b00 0x100>;
- clocks = <&coreclk 0>;
-
- xor00 {
- interrupts = <51>;
- };
- xor01 {
- interrupts = <52>;
- };
-};
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index 7e575296df0c..0dabe9bbb219 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/dma/nvidia,tegra186-gpc-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra GPC DMA Controller Device Tree Bindings
+title: NVIDIA Tegra GPC DMA Controller
description: |
The Tegra General Purpose Central (GPC) DMA controller is used for faster
@@ -16,7 +16,7 @@ maintainers:
- Rajesh Gumasta <rgumasta@nvidia.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -24,6 +24,7 @@ properties:
- const: nvidia,tegra186-gpcdma
- items:
- enum:
+ - nvidia,tegra264-gpcdma
- nvidia,tegra234-gpcdma
- nvidia,tegra194-gpcdma
- const: nvidia,tegra186-gpcdma
@@ -39,7 +40,7 @@ properties:
Should contain all of the per-channel DMA interrupts in
ascending order with respect to the DMA channel index.
minItems: 1
- maxItems: 31
+ maxItems: 32
resets:
maxItems: 1
@@ -52,6 +53,9 @@ properties:
dma-coherent: true
+ dma-channel-mask:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -60,6 +64,7 @@ required:
- reset-names
- "#dma-cells"
- iommus
+ - dma-channel-mask
additionalProperties: false
@@ -108,5 +113,6 @@ examples:
#dma-cells = <1>;
iommus = <&smmu TEGRA186_SID_GPCDMA_0>;
dma-coherent;
+ dma-channel-mask = <0xfffffffe>;
};
...
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt
deleted file mode 100644
index c6908e7c42cc..000000000000
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-* NVIDIA Tegra APB DMA controller
-
-Required properties:
-- compatible: Should be "nvidia,<chip>-apbdma"
-- reg: Should contain DMA registers location and length. This shuld include
- all of the per-channel registers.
-- interrupts: Should contain all of the per-channel DMA interrupts.
-- clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - dma
-- #dma-cells : Must be <1>. This dictates the length of DMA specifiers in
- client nodes' dmas properties. The specifier represents the DMA request
- select value for the peripheral. For more details, consult the Tegra TRM's
- documentation of the APB DMA channel control register REQ_SEL field.
-
-Examples:
-
-apbdma: dma@6000a000 {
- compatible = "nvidia,tegra20-apbdma";
- reg = <0x6000a000 0x1200>;
- interrupts = < 0 136 0x04
- 0 137 0x04
- 0 138 0x04
- 0 139 0x04
- 0 140 0x04
- 0 141 0x04
- 0 142 0x04
- 0 143 0x04
- 0 144 0x04
- 0 145 0x04
- 0 146 0x04
- 0 147 0x04
- 0 148 0x04
- 0 149 0x04
- 0 150 0x04
- 0 151 0x04 >;
- clocks = <&tegra_car 34>;
- resets = <&tegra_car 34>;
- reset-names = "dma";
- #dma-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml
new file mode 100644
index 000000000000..ea40c4e27a97
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/nvidia,tegra20-apbdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra APB DMA Controller
+
+description:
+ The NVIDIA Tegra APB DMA controller is a hardware component that
+ enables direct memory access (DMA) on Tegra systems. It facilitates
+ data transfer between I/O devices and main memory without constant
+ CPU intervention.
+
+maintainers:
+ - Jonathan Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra114-apbdma
+ - nvidia,tegra20-apbdma
+ - items:
+ - const: nvidia,tegra30-apbdma
+ - const: nvidia,tegra20-apbdma
+ - items:
+ - enum:
+ - nvidia,tegra124-apbdma
+ - nvidia,tegra210-apbdma
+ - const: nvidia,tegra148-apbdma
+
+ reg:
+ maxItems: 1
+
+ "#dma-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: dma
+
+ interrupts:
+ description:
+ Should contain all of the per-channel DMA interrupts in
+ ascending order with respect to the DMA channel index.
+ minItems: 1
+ maxItems: 32
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: dma
+
+required:
+ - compatible
+ - reg
+ - "#dma-cells"
+ - clocks
+ - interrupts
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+ dma-controller@6000a000 {
+ compatible = "nvidia,tegra30-apbdma", "nvidia,tegra20-apbdma";
+ reg = <0x6000a000 0x1200>;
+ interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car 34>;
+ resets = <&tegra_car 34>;
+ reset-names = "dma";
+ #dma-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
index fef804565b88..da0235e451d6 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml
@@ -13,15 +13,13 @@ description: |
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
-allOf:
- - $ref: "dma-controller.yaml#"
-
properties:
compatible:
oneOf:
- enum:
- nvidia,tegra210-adma
- nvidia,tegra186-adma
+ - nvidia,tegra264-adma
- items:
- enum:
- nvidia,tegra234-adma
@@ -29,7 +27,19 @@ properties:
- const: nvidia,tegra186-adma
reg:
- maxItems: 1
+ description:
+ The 'page' region describes the address space of the page
+ used for accessing the DMA channel registers. The 'global'
+ region describes the address space of the global DMA registers.
+ In the absence of the 'reg-names' property, there must be a
+ single entry that covers the address space of the global DMA
+ registers and the DMA channel registers.
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
interrupts:
description: |
@@ -53,6 +63,9 @@ properties:
ADMA_CHn_CTRL register.
const: 1
+ dma-channel-mask:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -60,6 +73,50 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra210-adma
+ then:
+ properties:
+ reg:
+ items:
+ - description: Full address space range of DMA registers.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-adma
+ - nvidia,tegra264-adma
+ then:
+ anyOf:
+ - properties:
+ reg:
+ items:
+ - description: Full address space range of DMA registers.
+ - properties:
+ reg:
+ items:
+ - description: Channel Page address space range of DMA registers.
+ reg-names:
+ items:
+ - const: page
+ - properties:
+ reg:
+ items:
+ - description: Channel Page address space range of DMA registers.
+ - description: Global Page address space range of DMA registers.
+ reg-names:
+ items:
+ - const: page
+ - const: global
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/dma/nxp,lpc3220-dmamux.yaml b/Documentation/devicetree/bindings/dma/nxp,lpc3220-dmamux.yaml
new file mode 100644
index 000000000000..32f208744154
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nxp,lpc3220-dmamux.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/nxp,lpc3220-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DMA multiplexer for LPC32XX SoC (DMA request router)
+
+maintainers:
+ - J.M.B. Downing <jonathan.downing@nautel.com>
+ - Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
+
+allOf:
+ - $ref: dma-router.yaml#
+
+properties:
+ compatible:
+ const: nxp,lpc3220-dmamux
+
+ reg:
+ maxItems: 1
+
+ dma-masters:
+ description: phandle to a dma node compatible with arm,pl080
+ maxItems: 1
+
+ "#dma-cells":
+ const: 3
+ description: |
+ First two cells same as for device pointed in dma-masters.
+ Third cell represents mux value for the request.
+
+required:
+ - compatible
+ - reg
+ - dma-masters
+
+additionalProperties: false
+
+examples:
+ - |
+ dma-router@7c {
+ compatible = "nxp,lpc3220-dmamux";
+ reg = <0x7c 0x8>;
+ dma-masters = <&dma>;
+ #dma-cells = <3>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
index 93b4847554fb..ec8b3dc37ca4 100644
--- a/Documentation/devicetree/bindings/dma/owl-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
@@ -15,7 +15,7 @@ maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/qcom,adm.yaml b/Documentation/devicetree/bindings/dma/qcom,adm.yaml
new file mode 100644
index 000000000000..6a9d7bc74aff
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom,adm.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/qcom,adm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm ADM DMA Controller
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ QCOM ADM DMA controller provides DMA capabilities for
+ peripheral buses such as NAND and SPI.
+
+properties:
+ compatible:
+ const: qcom,adm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#dma-cells":
+ const: 1
+
+ clocks:
+ items:
+ - description: phandle to the core clock
+ - description: phandle to the iface clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+
+ resets:
+ items:
+ - description: phandle to the clk reset
+ - description: phandle to the pbus reset
+ - description: phandle to the c0 reset
+ - description: phandle to the c1 reset
+ - description: phandle to the c2 reset
+
+ reset-names:
+ items:
+ - const: clk
+ - const: pbus
+ - const: c0
+ - const: c1
+ - const: c2
+
+ qcom,ee:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: indicates the security domain identifier used in the secure world.
+ minimum: 0
+ maximum: 255
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - qcom,ee
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+ #include <dt-bindings/reset/qcom,gcc-ipq806x.h>
+
+ adm_dma: dma-controller@18300000 {
+ compatible = "qcom,adm";
+ reg = <0x18300000 0x100000>;
+ interrupts = <0 170 0>;
+ #dma-cells = <1>;
+
+ clocks = <&gcc ADM0_CLK>,
+ <&gcc ADM0_PBUS_CLK>;
+ clock-names = "core", "iface";
+
+ resets = <&gcc ADM0_RESET>,
+ <&gcc ADM0_PBUS_RESET>,
+ <&gcc ADM0_C0_RESET>,
+ <&gcc ADM0_C1_RESET>,
+ <&gcc ADM0_C2_RESET>;
+ reset-names = "clk", "pbus", "c0", "c1", "c2";
+ qcom,ee = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
index 9bf3a1b164f1..6493a6968bb4 100644
--- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
@@ -8,20 +8,26 @@ title: Qualcomm Technologies Inc BAM DMA controller
maintainers:
- Andy Gross <agross@kernel.org>
- - Bjorn Andersson <bjorn.andersson@linaro.org>
+ - Bjorn Andersson <andersson@kernel.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
- enum:
- # APQ8064, IPQ8064 and MSM8960
- - qcom,bam-v1.3.0
- # MSM8974, APQ8074 and APQ8084
- - qcom,bam-v1.4.0
- # MSM8916
- - qcom,bam-v1.7.0
+ oneOf:
+ - enum:
+ # APQ8064, IPQ8064 and MSM8960
+ - qcom,bam-v1.3.0
+ # MSM8974, APQ8074 and APQ8084
+ - qcom,bam-v1.4.0
+ # MSM8916, SDM630
+ - qcom,bam-v1.7.0
+ - items:
+ - enum:
+ # SDM845, SM6115, SM8150, SM8250 and QCM2290
+ - qcom,bam-v1.7.4
+ - const: qcom,bam-v1.7.0
clocks:
maxItems: 1
@@ -36,9 +42,11 @@ properties:
interrupts:
maxItems: 1
+ dma-coherent: true
+
iommus:
minItems: 1
- maxItems: 4
+ maxItems: 6
num-channels:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -48,7 +56,7 @@ properties:
qcom,controlled-remotely:
type: boolean
description:
- Indicates that the bam is controlled by remote proccessor i.e. execution
+ Indicates that the bam is controlled by remote processor i.e. execution
environment.
qcom,ee:
@@ -81,6 +89,19 @@ required:
- qcom,ee
- reg
+anyOf:
+ - required:
+ - qcom,powered-remotely
+ - num-channels
+ - qcom,num-ees
+ - required:
+ - qcom,controlled-remotely
+ - num-channels
+ - qcom,num-ees
+ - required:
+ - clocks
+ - clock-names
+
additionalProperties: false
examples:
@@ -90,8 +111,8 @@ examples:
dma-controller@f9944000 {
compatible = "qcom,bam-v1.4.0";
- reg = <0xf9944000 0x15000>;
- interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9944000 0x19000>;
+ interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP2_AHB_CLK>;
clock-names = "bam_clk";
#dma-cells = <1>;
diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
index 7d2fc4eb5530..bbe4da2a1105 100644
--- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
@@ -14,17 +14,42 @@ description: |
peripheral buses such as I2C, UART, and SPI.
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
- enum:
- - qcom,sc7280-gpi-dma
- - qcom,sdm845-gpi-dma
- - qcom,sm8150-gpi-dma
- - qcom,sm8250-gpi-dma
- - qcom,sm8350-gpi-dma
- - qcom,sm8450-gpi-dma
+ oneOf:
+ - enum:
+ - qcom,sdm845-gpi-dma
+ - qcom,sm6350-gpi-dma
+ - items:
+ - enum:
+ - qcom,milos-gpi-dma
+ - qcom,qcm2290-gpi-dma
+ - qcom,qcs8300-gpi-dma
+ - qcom,qdu1000-gpi-dma
+ - qcom,sa8775p-gpi-dma
+ - qcom,sar2130p-gpi-dma
+ - qcom,sc7280-gpi-dma
+ - qcom,sc8280xp-gpi-dma
+ - qcom,sdx75-gpi-dma
+ - qcom,sm6115-gpi-dma
+ - qcom,sm6375-gpi-dma
+ - qcom,sm8350-gpi-dma
+ - qcom,sm8450-gpi-dma
+ - qcom,sm8550-gpi-dma
+ - qcom,sm8650-gpi-dma
+ - qcom,sm8750-gpi-dma
+ - qcom,x1e80100-gpi-dma
+ - const: qcom,sm6350-gpi-dma
+ - items:
+ - enum:
+ - qcom,qcs615-gpi-dma
+ - qcom,sdm670-gpi-dma
+ - qcom,sm6125-gpi-dma
+ - qcom,sm8150-gpi-dma
+ - qcom,sm8250-gpi-dma
+ - const: qcom,sdm845-gpi-dma
reg:
maxItems: 1
@@ -54,6 +79,8 @@ properties:
dma-channel-mask:
maxItems: 1
+ dma-coherent: true
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/dma/qcom_adm.txt b/Documentation/devicetree/bindings/dma/qcom_adm.txt
deleted file mode 100644
index 9d3b2f917b7b..000000000000
--- a/Documentation/devicetree/bindings/dma/qcom_adm.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-QCOM ADM DMA Controller
-
-Required properties:
-- compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960
-- reg: Address range for DMA registers
-- interrupts: Should contain one interrupt shared by all channels
-- #dma-cells: must be <2>. First cell denotes the channel number. Second cell
- denotes CRCI (client rate control interface) flow control assignment.
-- clocks: Should contain the core clock and interface clock.
-- clock-names: Must contain "core" for the core clock and "iface" for the
- interface clock.
-- resets: Must contain an entry for each entry in reset names.
-- reset-names: Must include the following entries:
- - clk
- - c0
- - c1
- - c2
-- qcom,ee: indicates the security domain identifier used in the secure world.
-
-Example:
- adm_dma: dma@18300000 {
- compatible = "qcom,adm";
- reg = <0x18300000 0x100000>;
- interrupts = <0 170 0>;
- #dma-cells = <2>;
-
- clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>;
- clock-names = "core", "iface";
-
- resets = <&gcc ADM0_RESET>,
- <&gcc ADM0_C0_RESET>,
- <&gcc ADM0_C1_RESET>,
- <&gcc ADM0_C2_RESET>;
- reset-names = "clk", "c0", "c1", "c2";
- qcom,ee = <0>;
- };
-
-DMA clients must use the format descripted in the dma.txt file, using a three
-cell specifier for each channel.
-
-Each dmas request consists of 3 cells:
- 1. phandle pointing to the DMA controller
- 2. channel number
- 3. CRCI assignment, if applicable. If no CRCI flow control is required, use 0.
- The CRCI is used for flow control. It identifies the peripheral device that
- is the source/destination for the transferred data.
-
-Example:
-
- spi4: spi@1a280000 {
- spi-max-frequency = <50000000>;
-
- pinctrl-0 = <&spi_pins>;
- pinctrl-names = "default";
-
- cs-gpios = <&qcom_pinmux 20 0>;
-
- dmas = <&adm_dma 6 9>,
- <&adm_dma 5 10>;
- dma-names = "rx", "tx";
- };
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
deleted file mode 100644
index 1ae4748730a8..000000000000
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-Qualcomm Technologies HIDMA Management interface
-
-Qualcomm Technologies HIDMA is a high speed DMA device. It only supports
-memcpy and memset capabilities. It has been designed for virtualized
-environments.
-
-Each HIDMA HW instance consists of multiple DMA channels. These channels
-share the same bandwidth. The bandwidth utilization can be partitioned
-among channels based on the priority and weight assignments.
-
-There are only two priority levels and 15 weigh assignments possible.
-
-Other parameters here determine how much of the system bus this HIDMA
-instance can use like maximum read/write request and number of bytes to
-read/write in a single burst.
-
-Main node required properties:
-- compatible: "qcom,hidma-mgmt-1.0";
-- reg: Address range for DMA device
-- dma-channels: Number of channels supported by this DMA controller.
-- max-write-burst-bytes: Maximum write burst in bytes that HIDMA can
- occupy the bus for in a single transaction. A memcpy requested is
- fragmented to multiples of this amount. This parameter is used while
- writing into destination memory. Setting this value incorrectly can
- starve other peripherals in the system.
-- max-read-burst-bytes: Maximum read burst in bytes that HIDMA can
- occupy the bus for in a single transaction. A memcpy request is
- fragmented to multiples of this amount. This parameter is used while
- reading the source memory. Setting this value incorrectly can starve
- other peripherals in the system.
-- max-write-transactions: This value is how many times a write burst is
- applied back to back while writing to the destination before yielding
- the bus.
-- max-read-transactions: This value is how many times a read burst is
- applied back to back while reading the source before yielding the bus.
-- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
- Once a reset is applied to the HW, HW starts a timer for reset operation
- to confirm. If reset is not completed within this time, HW reports reset
- failure.
-
-Sub-nodes:
-
-HIDMA has one or more DMA channels that are used to move data from one
-memory location to another.
-
-When the OS is not in control of the management interface (i.e. it's a guest),
-the channel nodes appear on their own, not under a management node.
-
-Required properties:
-- compatible: must contain "qcom,hidma-1.0" for initial HW or
- "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
-- reg: Addresses for the transfer and event channel
-- interrupts: Should contain the event interrupt
-- desc-count: Number of asynchronous requests this channel can handle
-- iommus: required a iommu node
-
-Optional properties for MSI:
-- msi-parent : See the generic MSI binding described in
- devicetree/bindings/interrupt-controller/msi.txt for a description of the
- msi-parent property.
-
-Example:
-
-Hypervisor OS configuration:
-
- hidma-mgmt@f9984000 = {
- compatible = "qcom,hidma-mgmt-1.0";
- reg = <0xf9984000 0x15000>;
- dma-channels = <6>;
- max-write-burst-bytes = <1024>;
- max-read-burst-bytes = <1024>;
- max-write-transactions = <31>;
- max-read-transactions = <31>;
- channel-reset-timeout-cycles = <0x500>;
-
- hidma_24: dma-controller@5c050000 {
- compatible = "qcom,hidma-1.0";
- reg = <0 0x5c050000 0x0 0x1000>,
- <0 0x5c0b0000 0x0 0x1000>;
- interrupts = <0 389 0>;
- desc-count = <10>;
- iommus = <&system_mmu>;
- };
- };
-
-Guest OS configuration:
-
- hidma_24: dma-controller@5c050000 {
- compatible = "qcom,hidma-1.0";
- reg = <0 0x5c050000 0x0 0x1000>,
- <0 0x5c0b0000 0x0 0x1000>;
- interrupts = <0 389 0>;
- desc-count = <10>;
- iommus = <&system_mmu>;
- };
diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
index 7202cd68e759..04fc4a99a7cb 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
@@ -10,7 +10,7 @@ maintainers:
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -45,6 +45,8 @@ properties:
- enum:
- renesas,dmac-r8a779a0 # R-Car V3U
- renesas,dmac-r8a779f0 # R-Car S4-8
+ - renesas,dmac-r8a779g0 # R-Car V4H
+ - renesas,dmac-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-dmac # R-Car Gen4
reg: true
diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
index 1e25c5b0fb4d..f891cfcc48c7 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
@@ -4,27 +4,35 @@
$id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas RZ/{G2L,G2UL,V2L} DMA Controller
+title: Renesas RZ DMA Controller
maintainers:
- Biju Das <biju.das.jz@bp.renesas.com>
-allOf:
- - $ref: "dma-controller.yaml#"
-
properties:
compatible:
- items:
- - enum:
- - renesas,r9a07g043-dmac # RZ/G2UL
- - renesas,r9a07g044-dmac # RZ/G2{L,LC}
- - renesas,r9a07g054-dmac # RZ/V2L
- - const: renesas,rz-dmac
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r7s72100-dmac # RZ/A1H
+ - renesas,r9a07g043-dmac # RZ/G2UL and RZ/Five
+ - renesas,r9a07g044-dmac # RZ/G2{L,LC}
+ - renesas,r9a07g054-dmac # RZ/V2L
+ - renesas,r9a08g045-dmac # RZ/G3S
+ - const: renesas,rz-dmac
+
+ - items:
+ - enum:
+ - renesas,r9a09g047-dmac # RZ/G3E
+ - const: renesas,r9a09g057-dmac
+
+ - const: renesas,r9a09g057-dmac # RZ/V2H(P)
reg:
items:
- description: Control and channel register block
- description: DMA extended resource selector block
+ minItems: 1
interrupts:
maxItems: 17
@@ -53,14 +61,20 @@ properties:
items:
- description: DMA main clock
- description: DMA register access clock
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: main
+ - const: register
'#dma-cells':
const: 1
description:
- The cell specifies the encoded MID/RID values of the DMAC port
- connected to the DMA client and the slave channel configuration
- parameters.
- bits[0:9] - Specifies MID/RID value
+ The cell specifies the encoded MID/RID or the REQ No values of
+ the DMAC port connected to the DMA client and the slave channel
+ configuration parameters.
+ bits[0:9] - Specifies the MID/RID or the REQ No value
bit[10] - Specifies DMA request high enable (HIEN)
bit[11] - Specifies DMA request detection type (LVL)
bits[12:14] - Specifies DMAACK output mode (AM)
@@ -76,17 +90,103 @@ properties:
items:
- description: Reset for DMA ARESETN reset terminal
- description: Reset for DMA RST_ASYNC reset terminal
+ minItems: 1
+
+ reset-names:
+ items:
+ - const: arst
+ - const: rst_async
+
+ renesas,icu:
+ description:
+ It must contain the phandle to the ICU and the index of the DMAC as seen
+ from the ICU.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to the ICU node.
+ - description:
+ The number of the DMAC as seen from the ICU, i.e. parameter k from
+ register ICU_DMkSELy. This may differ from the actual DMAC instance
+ number.
required:
- compatible
- reg
- interrupts
- interrupt-names
- - clocks
- '#dma-cells'
- dma-channels
- - power-domains
- - resets
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a07g043-dmac
+ - renesas,r9a07g044-dmac
+ - renesas,r9a07g054-dmac
+ - renesas,r9a08g045-dmac
+ then:
+ properties:
+ reg:
+ minItems: 2
+ clocks:
+ minItems: 2
+ resets:
+ minItems: 2
+
+ renesas,icu: false
+
+ required:
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r7s72100-dmac
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+ clocks: false
+ clock-names: false
+ power-domains: false
+ resets: false
+ reset-names: false
+ renesas,icu: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g057-dmac
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ clocks:
+ maxItems: 1
+ resets:
+ maxItems: 1
+
+ clock-names: false
+ reset-names: false
+
+ required:
+ - clocks
+ - power-domains
+ - renesas,icu
+ - resets
additionalProperties: false
@@ -124,9 +224,11 @@ examples:
"ch12", "ch13", "ch14", "ch15";
clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>,
<&cpg CPG_MOD R9A07G044_DMAC_PCLK>;
+ clock-names = "main", "register";
power-domains = <&cpg>;
resets = <&cpg R9A07G044_DMAC_ARESETN>,
<&cpg R9A07G044_DMAC_RST_ASYNC>;
+ reset-names = "arst", "rst_async";
#dma-cells = <1>;
dma-channels = <16>;
};
diff --git a/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
index d83013b0dd74..ee9833dcc36c 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml
@@ -10,7 +10,7 @@ maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- - $ref: "dma-router.yaml#"
+ - $ref: dma-router.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
index ab287c652b2c..17813599fccb 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml
@@ -10,7 +10,7 @@ maintainers:
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
index 3271755787b4..609e38901434 100644
--- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
+++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
@@ -23,14 +23,20 @@ description: |
https://static.dev.sifive.com/FU540-C000-v1.0.pdf
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
- items:
- - enum:
- - sifive,fu540-c000-pdma
- - const: sifive,pdma0
+ oneOf:
+ - items:
+ - const: microchip,pic64gx-pdma
+ - const: microchip,mpfs-pdma
+ - const: sifive,pdma0
+ - items:
+ - enum:
+ - microchip,mpfs-pdma
+ - sifive,fu540-c000-pdma
+ - const: sifive,pdma0
description:
Should be "sifive,<chip>-pdma" and "sifive,pdma<version>".
Supported compatible strings are -
diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
index c13649bf7f19..18c0a7c18bc8 100644
--- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
@@ -11,7 +11,7 @@ maintainers:
- Andy Shevchenko <andriy.shevchenko@linux.intel.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
@@ -22,7 +22,6 @@ properties:
- renesas,r9a06g032-dma
- const: renesas,rzn1-dma
-
"#dma-cells":
minimum: 3
maximum: 4
@@ -93,10 +92,10 @@ properties:
data-width:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: Data bus width per each DMA master in bytes.
+ minItems: 1
+ maxItems: 4
items:
- maxItems: 4
- items:
- enum: [4, 8, 16, 32]
+ enum: [4, 8, 16, 32]
data_width:
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -106,28 +105,28 @@ properties:
deprecated. It' usage is discouraged in favor of data-width one. Moreover
the property incorrectly permits to define data-bus width of 8 and 16
bits, which is impossible in accordance with DW DMAC IP-core data book.
+ minItems: 1
+ maxItems: 4
items:
- maxItems: 4
- items:
- enum:
- - 0 # 8 bits
- - 1 # 16 bits
- - 2 # 32 bits
- - 3 # 64 bits
- - 4 # 128 bits
- - 5 # 256 bits
- default: 0
+ enum:
+ - 0 # 8 bits
+ - 1 # 16 bits
+ - 2 # 32 bits
+ - 3 # 64 bits
+ - 4 # 128 bits
+ - 5 # 256 bits
+ default: 0
multi-block:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
LLP-based multi-block transfer supported by hardware per
each DMA channel.
+ minItems: 1
+ maxItems: 8
items:
- maxItems: 8
- items:
- enum: [0, 1]
- default: 1
+ enum: [0, 1]
+ default: 1
snps,max-burst-len:
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -138,11 +137,11 @@ properties:
will be from 1 to max-burst-len words. It's an array property with one
cell per channel in the units determined by the value set in the
CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width).
+ minItems: 1
+ maxItems: 8
items:
- maxItems: 8
- items:
- enum: [4, 8, 16, 32, 64, 128, 256]
- default: 256
+ enum: [4, 8, 16, 32, 64, 128, 256]
+ default: 256
snps,dma-protection-control:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
index 67aa7bb6d36a..a393a33c8908 100644
--- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
@@ -8,19 +8,20 @@ title: Synopsys DesignWare AXI DMA Controller
maintainers:
- Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
- - Jee Heng Sia <jee.heng.sia@intel.com>
description:
Synopsys DesignWare AXI DMA Controller DT Binding
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
enum:
- snps,axi-dma-1.01a
- intel,kmb-axi-dma
+ - starfive,jh7110-axi-dma
+ - starfive,jh8100-axi-dma
reg:
minItems: 1
@@ -41,6 +42,9 @@ properties:
minItems: 1
maxItems: 8
+ iommus:
+ maxItems: 1
+
clocks:
items:
- description: Bus Clock
@@ -58,8 +62,11 @@ properties:
minimum: 1
maximum: 8
+ dma-noncoherent: true
+
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
snps,dma-masters:
description: |
@@ -110,25 +117,44 @@ required:
- snps,priority
- snps,block-size
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - starfive,jh7110-axi-dma
+then:
+ properties:
+ resets:
+ minItems: 2
+ items:
+ - description: AXI reset line
+ - description: AHB reset line
+ - description: module reset
+else:
+ properties:
+ resets:
+ maxItems: 1
+
additionalProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- /* example with snps,dw-axi-dmac */
- dmac: dma-controller@80000 {
- compatible = "snps,axi-dma-1.01a";
- reg = <0x80000 0x400>;
- clocks = <&core_clk>, <&cfgr_clk>;
- clock-names = "core-clk", "cfgr-clk";
- interrupt-parent = <&intc>;
- interrupts = <27>;
- #dma-cells = <1>;
- dma-channels = <4>;
- snps,dma-masters = <2>;
- snps,data-width = <3>;
- snps,block-size = <4096 4096 4096 4096>;
- snps,priority = <0 1 2 3>;
- snps,axi-max-burst-len = <16>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ /* example with snps,dw-axi-dmac */
+ dma-controller@80000 {
+ compatible = "snps,axi-dma-1.01a";
+ reg = <0x80000 0x400>;
+ clocks = <&core_clk>, <&cfgr_clk>;
+ clock-names = "core-clk", "cfgr-clk";
+ interrupt-parent = <&intc>;
+ interrupts = <27>;
+ #dma-cells = <1>;
+ dma-channels = <4>;
+ snps,dma-masters = <2>;
+ snps,data-width = <3>;
+ snps,block-size = <4096 4096 4096 4096>;
+ snps,priority = <0 1 2 3>;
+ snps,axi-max-burst-len = <16>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml b/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml
index e7bf6dd7da29..23c8a7bf24de 100644
--- a/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/socionext,uniphier-mio-dmac.yaml
@@ -14,7 +14,7 @@ maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml b/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
index 371f18773198..da61d1ddc9c3 100644
--- a/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
+++ b/Documentation/devicetree/bindings/dma/socionext,uniphier-xdmac.yaml
@@ -15,7 +15,7 @@ maintainers:
- Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800b-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800b-dmamux.yaml
new file mode 100644
index 000000000000..011002942235
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800b-dmamux.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/sophgo,cv1800b-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800/SG200 Series DMA multiplexer
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+description:
+ The DMA multiplexer of CV1800 is a subdevice of the system
+ controller. It support mapping 8 channels, but each channel
+ can be mapped only once.
+
+allOf:
+ - $ref: dma-router.yaml#
+
+properties:
+ compatible:
+ const: sophgo,cv1800b-dmamux
+
+ reg:
+ items:
+ - description: DMA channal remapping register
+ - description: DMA channel interrupt mapping register
+
+ '#dma-cells':
+ const: 2
+ description:
+ The first cells is device id. The second one is the cpu id.
+
+ dma-masters:
+ maxItems: 1
+
+required:
+ - reg
+ - '#dma-cells'
+ - dma-masters
+
+additionalProperties: false
+
+examples:
+ - |
+ dma-router@154 {
+ compatible = "sophgo,cv1800b-dmamux";
+ reg = <0x154 0x8>, <0x298 0x4>;
+ #dma-cells = <2>;
+ dma-masters = <&dmac>;
+ };
diff --git a/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml b/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml
new file mode 100644
index 000000000000..ec06235baf5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/spacemit,k1-pdma.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/spacemit,k1-pdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 PDMA Controller
+
+maintainers:
+ - Guodong Xu <guodong@riscstar.com>
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-pdma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Shared interrupt for all DMA channels
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ dma-channels:
+ maximum: 16
+
+ '#dma-cells':
+ const: 1
+ description:
+ The DMA request number for the peripheral device.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - dma-channels
+ - '#dma-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dma-controller@d4000000 {
+ compatible = "spacemit,k1-pdma";
+ reg = <0x0 0xd4000000 0x0 0x4000>;
+ interrupts = <72>;
+ clocks = <&syscon_apmu CLK_DMA>;
+ resets = <&syscon_apmu RESET_DMA>;
+ dma-channels = <16>;
+ #dma-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/dma/sprd,sc9860-dma.yaml b/Documentation/devicetree/bindings/dma/sprd,sc9860-dma.yaml
new file mode 100644
index 000000000000..94647219c021
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sprd,sc9860-dma.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/sprd,sc9860-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC9860 DMA controller
+
+description: |
+ There are three DMA controllers: AP DMA, AON DMA and AGCP DMA. For AGCP
+ DMA controller, it can or do not request the IRQ, which will save
+ system power without resuming system by DMA interrupts if AGCP DMA
+ does not request the IRQ.
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,sc9860-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: DMA enable clock
+ - description: optional ashb_eb clock, only for the AGCP DMA controller
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: enable
+ - const: ashb_eb
+
+ '#dma-cells':
+ const: 1
+
+ dma-channels:
+ const: 32
+
+ '#dma-channels':
+ const: 32
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#dma-cells'
+ - dma-channels
+
+allOf:
+ - $ref: dma-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sprd,sc9860-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ /* AP DMA controller */
+ dma-controller@20100000 {
+ compatible = "sprd,sc9860-dma";
+ reg = <0x20100000 0x4000>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&apahb_gate CLK_DMA_EB>;
+ clock-names = "enable";
+ #dma-cells = <1>;
+ dma-channels = <32>;
+ };
+
+ /* AGCP DMA controller */
+ dma-controller@41580000 {
+ compatible = "sprd,sc9860-dma";
+ reg = <0x41580000 0x4000>;
+ clocks = <&agcp_gate CLK_AGCP_DMAAP_EB>,
+ <&agcp_gate CLK_AGCP_AP_ASHB_EB>;
+ clock-names = "enable", "ashb_eb";
+ #dma-cells = <1>;
+ dma-channels = <32>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/dma/sprd-dma.txt b/Documentation/devicetree/bindings/dma/sprd-dma.txt
deleted file mode 100644
index c7e9b5fd50e7..000000000000
--- a/Documentation/devicetree/bindings/dma/sprd-dma.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-* Spreadtrum DMA controller
-
-This binding follows the generic DMA bindings defined in dma.txt.
-
-Required properties:
-- compatible: Should be "sprd,sc9860-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain one interrupt shared by all channel.
-- #dma-cells: must be <1>. Used to represent the number of integer
- cells in the dmas property of client device.
-- dma-channels : Number of DMA channels supported. Should be 32.
-- clock-names: Should contain the clock of the DMA controller.
-- clocks: Should contain a clock specifier for each entry in clock-names.
-
-Deprecated properties:
-- #dma-channels : Number of DMA channels supported. Should be 32.
-
-Example:
-
-Controller:
-apdma: dma-controller@20100000 {
- compatible = "sprd,sc9860-dma";
- reg = <0x20100000 0x4000>;
- interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
- #dma-cells = <1>;
- dma-channels = <32>;
- clock-names = "enable";
- clocks = <&clk_ap_ahb_gates 5>;
-};
-
-
-Client:
-DMA clients connected to the Spreadtrum DMA controller must use the format
-described in the dma.txt file, using a two-cell specifier for each channel.
-The two cells in order are:
-1. A phandle pointing to the DMA controller.
-2. The slave id.
-
-spi0: spi@70a00000{
- ...
- dma-names = "rx_chn", "tx_chn";
- dmas = <&apdma 11>, <&apdma 12>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
deleted file mode 100644
index 1e1d8549b7ef..000000000000
--- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
+++ /dev/null
@@ -1,53 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/dma/st,stm32-dmamux.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: STMicroelectronics STM32 DMA MUX (DMA request router) bindings
-
-maintainers:
- - Amelie Delaunay <amelie.delaunay@foss.st.com>
-
-allOf:
- - $ref: "dma-router.yaml#"
-
-properties:
- "#dma-cells":
- const: 3
-
- compatible:
- const: st,stm32h7-dmamux
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- resets:
- maxItems: 1
-
-required:
- - compatible
- - reg
- - dma-masters
-
-unevaluatedProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/stm32mp1-clks.h>
- #include <dt-bindings/reset/stm32mp1-resets.h>
- dma-router@40020800 {
- compatible = "st,stm32h7-dmamux";
- reg = <0x40020800 0x3c>;
- #dma-cells = <3>;
- dma-requests = <128>;
- dma-channels = <16>;
- dma-masters = <&dma1>, <&dma2>;
- clocks = <&timer_clk>;
- };
-
-...
diff --git a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
index 8bddfb3b6fa0..8b42d9880400 100644
--- a/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
+++ b/Documentation/devicetree/bindings/dma/stericsson,dma40.yaml
@@ -10,7 +10,7 @@ maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: dma-controller.yaml#
properties:
"#dma-cells":
@@ -112,14 +112,22 @@ properties:
- const: stericsson,dma40
reg:
- items:
- - description: DMA40 memory base
- - description: LCPA memory base
+ oneOf:
+ - items:
+ - description: DMA40 memory base
+ - items:
+ - description: DMA40 memory base
+ - description: LCPA memory base, deprecated, use eSRAM pool instead
+ deprecated: true
reg-names:
- items:
- - const: base
- - const: lcpa
+ oneOf:
+ - items:
+ - const: base
+ - items:
+ - const: base
+ - const: lcpa
+ deprecated: true
interrupts:
maxItems: 1
@@ -127,10 +135,19 @@ properties:
clocks:
maxItems: 1
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A phandle array with inner size 1 (no arg cells).
+ First phandle is the LCPA (Logical Channel Parameter Address) memory.
+ Second phandle is the LCLA (Logical Channel Link base Address) memory.
+ maxItems: 2
+ items:
+ maxItems: 1
+
memcpy-channels:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: Array of u32 elements indicating which channels on the DMA
- engine are elegible for memcpy transfers
+ engine are eligible for memcpy transfers
required:
- "#dma-cells"
@@ -138,6 +155,7 @@ required:
- reg
- interrupts
- clocks
+ - sram
- memcpy-channels
additionalProperties: false
@@ -147,13 +165,14 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mfd/dbx500-prcmu.h>
- dma-controller@801C0000 {
- compatible = "stericsson,db8500-dma40", "stericsson,dma40";
- reg = <0x801C0000 0x1000>, <0x40010000 0x800>;
- reg-names = "base", "lcpa";
- interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
- #dma-cells = <3>;
- memcpy-channels = <56 57 58 59 60>;
- clocks = <&prcmu_clk PRCMU_DMACLK>;
+ dma-controller@801c0000 {
+ compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+ reg = <0x801c0000 0x1000>;
+ reg-names = "base";
+ sram = <&lcpa>, <&lcla>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <3>;
+ memcpy-channels = <56 57 58 59 60>;
+ clocks = <&prcmu_clk PRCMU_DMACLK>;
};
...
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma.yaml
index 55faab6a468e..598903354196 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/dma/st,stm32-dma.yaml#
+$id: http://devicetree.org/schemas/dma/stm32/st,stm32-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 DMA Controller bindings
+title: STMicroelectronics STM32 DMA Controller
description: |
The STM32 DMA is a general-purpose direct memory access controller capable of
@@ -48,12 +48,11 @@ description: |
by transfer completion. This must only be used on channels
managing transfers for STM32 USART/UART.
-
maintainers:
- Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: /schemas/dma/dma-controller.yaml#
properties:
"#dma-cells":
@@ -82,6 +81,10 @@ properties:
description: if defined, it indicates that the controller
supports memory-to-memory transfer
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
new file mode 100644
index 000000000000..36f9fe860eb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/stm32/st,stm32-dma3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 DMA3 Controller
+
+description: |
+ The STM32 DMA3 is a direct memory access controller with different features
+ depending on its hardware configuration.
+ It is either called LPDMA (Low Power), GPDMA (General Purpose) or HPDMA (High
+ Performance).
+ Its hardware configuration registers allow to dynamically expose its features.
+
+ GPDMA and HPDMA support 16 independent DMA channels, while only 4 for LPDMA.
+ GPDMA and HPDMA support 256 DMA requests from peripherals, 8 for LPDMA.
+
+ Bindings are generic for these 3 STM32 DMA3 configurations.
+
+ DMA clients connected to the STM32 DMA3 controller must use the format
+ described in "#dma-cells" property description below, using a three-cell
+ specifier for each channel.
+
+maintainers:
+ - Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ compatible:
+ const: st,stm32mp25-dma3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 4
+ maxItems: 16
+ description:
+ Should contain all of the per-channel DMA interrupts in ascending order
+ with respect to the DMA channel index.
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ "#dma-cells":
+ const: 3
+ description: |
+ Specifies the number of cells needed to provide DMA controller specific
+ information.
+ The first cell is the request line number.
+ The second cell is a 32-bit mask specifying the DMA channel requirements:
+ -bit 0-1: The priority level
+ 0x0: low priority, low weight
+ 0x1: low priority, mid weight
+ 0x2: low priority, high weight
+ 0x3: high priority
+ -bit 4-7: The FIFO requirement for queuing source/destination transfers
+ 0x0: no FIFO requirement/any channel can fit
+ 0x2: FIFO of 8 bytes (2^2+1)
+ 0x4: FIFO of 32 bytes (2^4+1)
+ 0x6: FIFO of 128 bytes (2^6+1)
+ 0x7: FIFO of 256 bytes (2^7+1)
+ The third cell is a 32-bit mask specifying the DMA transfer requirements:
+ -bit 0: The source incrementing burst
+ 0x0: fixed burst
+ 0x1: contiguously incremented burst
+ -bit 1: The source allocated port
+ 0x0: port 0 is allocated to the source transfer
+ 0x1: port 1 is allocated to the source transfer
+ -bit 4: The destination incrementing burst
+ 0x0: fixed burst
+ 0x1: contiguously incremented burst
+ -bit 5: The destination allocated port
+ 0x0: port 0 is allocated to the destination transfer
+ 0x1: port 1 is allocated to the destination transfer
+ -bit 8: The type of hardware request
+ 0x0: burst
+ 0x1: block
+ -bit 9: The control mode
+ 0x0: DMA controller control mode
+ 0x1: peripheral control mode
+ -bit 12-13: The transfer complete event mode
+ 0x0: at block level, transfer complete event is generated at the end
+ of a block
+ 0x2: at LLI level, the transfer complete event is generated at the end
+ of the LLI transfer
+ including the update of the LLI if any
+ 0x3: at channel level, the transfer complete event is generated at the
+ end of the last LLI
+ -bit 16: Prevent packing/unpacking mode
+ 0x0: pack/unpack enabled when source data width/burst != destination data width/burst
+ 0x1: memory data width/burst forced to peripheral data width/burst to prevent pack/unpack
+ -bit 17: Prevent additional transfers due to linked-list refactoring
+ 0x0: don't prevent additional transfers for optimal performance
+ 0x1: prevent additional transfer to accommodate user constraints such as single transfer
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - "#dma-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ dma-controller@40400000 {
+ compatible = "st,stm32mp25-dma3";
+ reg = <0x40400000 0x1000>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc CK_BUS_HPDMA1>;
+ #dma-cells = <3>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml
new file mode 100644
index 000000000000..b7bca1a83769
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dmamux.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/stm32/st,stm32-dmamux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 DMA MUX (DMA request router)
+
+maintainers:
+ - Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+allOf:
+ - $ref: /schemas/dma/dma-router.yaml#
+
+properties:
+ "#dma-cells":
+ const: 3
+ description: |
+ Each cell represents the following:
+ 1. The mux input number/line for the request
+ 2. Bitfield representing DMA channel configuration that is passed
+ to the real DMA controller
+ 3. Bitfield representing device dependent DMA features passed to
+ the real DMA controller
+
+ For bitfield definitions of cells 2 and 3, see the associated
+ bindings doc for the actual DMA controller in st,stm32-dma.yaml.
+
+ compatible:
+ const: st,stm32h7-dmamux
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - dma-masters
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+ #include <dt-bindings/reset/stm32mp1-resets.h>
+ dma-router@40020800 {
+ compatible = "st,stm32h7-dmamux";
+ reg = <0x40020800 0x3c>;
+ #dma-cells = <3>;
+ dma-requests = <128>;
+ dma-channels = <16>;
+ dma-masters = <&dma1>, <&dma2>;
+ clocks = <&timer_clk>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-mdma.yaml
index 00cfa3913652..45fe91db11db 100644
--- a/Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml
+++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-mdma.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/dma/st,stm32-mdma.yaml#
+$id: http://devicetree.org/schemas/dma/stm32/st,stm32-mdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 MDMA Controller bindings
+title: STMicroelectronics STM32 MDMA Controller
description: |
The STM32 MDMA is a general-purpose direct memory access controller capable of
@@ -53,7 +53,7 @@ maintainers:
- Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf:
- - $ref: "dma-controller.yaml#"
+ - $ref: /schemas/dma/dma-controller.yaml#
properties:
"#dma-cells":
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index b849a1ed389d..1f9831540c97 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible: "ti,dra7-dma-crossbar" for DRA7xx DMA crossbar
"ti,am335x-edma-crossbar" for AM335x and AM437x
- reg: Memory map for accessing module
-- #dma-cells: Should be set to to match with the DMA controller's dma-cells
+- #dma-cells: Should be set to match with the DMA controller's dma-cells
for ti,dra7-dma-crossbar and <3> for ti,am335x-edma-crossbar.
- dma-requests: Number of DMA requests the crossbar can receive
- dma-masters: phandle pointing to the DMA controller
@@ -20,7 +20,7 @@ Optional properties:
memcpy channels in eDMA.
Notes:
-When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
+When requesting channel via ti,dra7-dma-crossbar, the DMA client must request
the DMA event number as crossbar ID (input to the DMA crossbar).
For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients:
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
index 08627d91e607..b5bc842c5a0e 100644
--- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -6,7 +6,7 @@
$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
+title: Texas Instruments K3 DMSS BCDMA
maintainers:
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
@@ -28,13 +28,21 @@ description: |
PDMAs can be configured via BCDMA split channel's peer registers to match with
the configuration of the legacy peripheral.
-allOf:
- - $ref: /schemas/dma/dma-controller.yaml#
- - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
-
properties:
compatible:
- const: ti,am64-dmss-bcdma
+ enum:
+ - ti,am62a-dmss-bcdma-csirx
+ - ti,am64-dmss-bcdma
+ - ti,j721s2-dmss-bcdma-csi
+ - ti,j722s-dmss-bcdma-csi
+
+ reg:
+ minItems: 3
+ maxItems: 9
+
+ reg-names:
+ minItems: 3
+ maxItems: 9
"#dma-cells":
const: 3
@@ -65,19 +73,13 @@ properties:
cell 3: ASEL value for the channel
- reg:
- maxItems: 5
-
- reg-names:
- items:
- - const: gcfg
- - const: bchanrt
- - const: rchanrt
- - const: tchanrt
- - const: ringrt
-
msi-parent: true
+ power-domains:
+ description:
+ Power domain if available
+ maxItems: 1
+
ti,asel:
$ref: /schemas/types.yaml#/definitions/uint32
description: ASEL value for non slave channels
@@ -123,10 +125,102 @@ required:
- msi-parent
- ti,sci
- ti,sci-dev-id
- - ti,sci-rm-range-bchan
- - ti,sci-rm-range-tchan
- ti,sci-rm-range-rchan
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am62a-dmss-bcdma-csirx
+ then:
+ properties:
+ ti,sci-rm-range-bchan: false
+ ti,sci-rm-range-tchan: false
+
+ reg:
+ items:
+ - description: BCDMA Control /Status Registers region
+ - description: RX Channel Realtime Registers region
+ - description: Ring Realtime Registers region
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: rchanrt
+ - const: ringrt
+
+ required:
+ - power-domains
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am64-dmss-bcdma
+ then:
+ properties:
+ reg:
+ minItems: 5
+ items:
+ - description: BCDMA Control /Status Registers region
+ - description: Block Copy Channel Realtime Registers region
+ - description: RX Channel Realtime Registers region
+ - description: TX Channel Realtime Registers region
+ - description: Ring Realtime Registers region
+ - description: Ring Configuration Registers region
+ - description: TX Channel Configuration Registers region
+ - description: RX Channel Configuration Registers region
+ - description: Block Copy Channel Configuration Registers region
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: gcfg
+ - const: bchanrt
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+ - const: ring
+ - const: tchan
+ - const: rchan
+ - const: bchan
+
+ required:
+ - ti,sci-rm-range-bchan
+ - ti,sci-rm-range-tchan
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,j721s2-dmss-bcdma-csi
+ - ti,j722s-dmss-bcdma-csi
+ then:
+ properties:
+ ti,sci-rm-range-bchan: false
+
+ reg:
+ items:
+ - description: BCDMA Control /Status Registers region
+ - description: RX Channel Realtime Registers region
+ - description: TX Channel Realtime Registers region
+ - description: Ring Realtime Registers region
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ required:
+ - ti,sci-rm-range-tchan
+
unevaluatedProperties: false
examples:
@@ -151,8 +245,13 @@ examples:
<0x0 0x4c000000 0x0 0x20000>,
<0x0 0x4a820000 0x0 0x20000>,
<0x0 0x4aa40000 0x0 0x20000>,
- <0x0 0x4bc00000 0x0 0x100000>;
- reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
+ <0x0 0x4bc00000 0x0 0x100000>,
+ <0x0 0x48600000 0x0 0x8000>,
+ <0x0 0x484a4000 0x0 0x2000>,
+ <0x0 0x484c2000 0x0 0x2000>,
+ <0x0 0x48420000 0x0 0x2000>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "bchan";
msi-parent = <&inta_main_dmss>;
#dma-cells = <3>;
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
index 507d16d84ade..11e064c02994 100644
--- a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
+++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
@@ -6,7 +6,7 @@
$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
+title: Texas Instruments K3 DMSS PKTDMA
maintainers:
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
@@ -45,14 +45,28 @@ properties:
The second cell is the ASEL value for the channel
reg:
- maxItems: 4
+ minItems: 4
+ items:
+ - description: Packet DMA Control /Status Registers region
+ - description: RX Channel Realtime Registers region
+ - description: TX Channel Realtime Registers region
+ - description: Ring Realtime Registers region
+ - description: Ring Configuration Registers region
+ - description: TX Configuration Registers region
+ - description: RX Configuration Registers region
+ - description: RX Flow Configuration Registers region
reg-names:
+ minItems: 4
items:
- const: gcfg
- const: rchanrt
- const: tchanrt
- const: ringrt
+ - const: ring
+ - const: tchan
+ - const: rchan
+ - const: rflow
msi-parent: true
@@ -136,8 +150,14 @@ examples:
reg = <0x0 0x485c0000 0x0 0x100>,
<0x0 0x4a800000 0x0 0x20000>,
<0x0 0x4aa00000 0x0 0x40000>,
- <0x0 0x4b800000 0x0 0x400000>;
- reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x0 0x4b800000 0x0 0x400000>,
+ <0x0 0x485e0000 0x0 0x20000>,
+ <0x0 0x484a0000 0x0 0x4000>,
+ <0x0 0x484c0000 0x0 0x2000>,
+ <0x0 0x48430000 0x0 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+ "ring", "tchan", "rchan", "rflow";
+
msi-parent = <&inta_main_dmss>;
#dma-cells = <2>;
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
index 6a09bbf83d46..b18cf2bfdb5b 100644
--- a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
+++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
@@ -6,7 +6,7 @@
$id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments K3 NAVSS Unified DMA Device Tree Bindings
+title: Texas Instruments K3 NAVSS Unified DMA
maintainers:
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
@@ -43,7 +43,8 @@ description: |
configuration of the legacy peripheral.
allOf:
- - $ref: "../dma-controller.yaml#"
+ - $ref: ../dma-controller.yaml#
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
properties:
"#dma-cells":
@@ -68,24 +69,27 @@ properties:
- ti,j721e-navss-mcu-udmap
reg:
- maxItems: 3
+ minItems: 3
+ items:
+ - description: UDMA-P Control /Status Registers region
+ - description: RX Channel Realtime Registers region
+ - description: TX Channel Realtime Registers region
+ - description: TX Configuration Registers region
+ - description: RX Configuration Registers region
+ - description: RX Flow Configuration Registers region
reg-names:
+ minItems: 3
items:
- const: gcfg
- const: rchanrt
- const: tchanrt
+ - const: tchan
+ - const: rchan
+ - const: rflow
msi-parent: true
- ti,sci:
- description: phandle to TI-SCI compatible System controller node
- $ref: /schemas/types.yaml#/definitions/phandle
-
- ti,sci-dev-id:
- description: TI-SCI device id of UDMAP
- $ref: /schemas/types.yaml#/definitions/uint32
-
ti,ringacc:
description: phandle to the ring accelerator node
$ref: /schemas/types.yaml#/definitions/phandle
@@ -165,8 +169,11 @@ examples:
compatible = "ti,am654-navss-main-udmap";
reg = <0x0 0x31150000 0x0 0x100>,
<0x0 0x34000000 0x0 0x100000>,
- <0x0 0x35000000 0x0 0x100000>;
- reg-names = "gcfg", "rchanrt", "tchanrt";
+ <0x0 0x35000000 0x0 0x100000>,
+ <0x0 0x30b00000 0x0 0x20000>,
+ <0x0 0x30c00000 0x0 0x8000>,
+ <0x0 0x30d00000 0x0 0x4000>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "tchan", "rchan", "rflow";
#dma-cells = <1>;
ti,ringacc = <&ringacc>;
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index d1700a5c36bf..b567107270cb 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -49,6 +49,12 @@ Optional properties for AXI DMA and MCDMA:
register as configured in h/w. Takes values {8...26}. If the property
is missing or invalid then the default value 23 is used. This is the
maximum value that is supported by all IP versions.
+
+Optional properties for AXI DMA:
+- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP.
+- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from
+ 0-255. Setting this value to zero disables the delay timer interrupt.
+ 1 timeout interval = 125 * clock period of SG clock.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
@@ -103,26 +109,3 @@ axi_vdma_0: axivdma@40030000 {
xlnx,datawidth = <0x40>;
} ;
} ;
-
-
-* DMA client
-
-Required properties:
-- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
- where Channel ID is '0' for write/tx and '1' for read/rx
- channel. For MCMDA, MM2S channel(write/tx) ID start from
- '0' and is in [0-15] range. S2MM channel(read/rx) ID start
- from '16' and is in [16-31] range. These channels ID are
- fixed irrespective of IP configuration.
-
-- dma-names: a list of DMA channel names, one per "dmas" entry
-
-Example:
-++++++++
-
-vdmatest_0: vdmatest@0 {
- compatible ="xlnx,axi-vdma-test-1.00.a";
- dmas = <&axi_vdma_0 0
- &axi_vdma_0 1>;
- dma-names = "vdma0", "vdma1";
-} ;
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
index c0a1408b12ec..2da86037ad79 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
+++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
@@ -13,16 +13,20 @@ description: |
maintainers:
- Michael Tretter <m.tretter@pengutronix.de>
+ - Harini Katakam <harini.katakam@amd.com>
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
allOf:
- - $ref: "../dma-controller.yaml#"
+ - $ref: ../dma-controller.yaml#
properties:
"#dma-cells":
const: 1
compatible:
- const: xlnx,zynqmp-dma-1.0
+ enum:
+ - amd,versal2-dma-1.0
+ - xlnx,zynqmp-dma-1.0
reg:
description: memory map for gdma/adma module access
@@ -55,8 +59,7 @@ properties:
power-domains:
maxItems: 1
- dma-coherent:
- description: present if dma operations are coherent
+ dma-coherent: true
required:
- "#dma-cells"
@@ -65,12 +68,12 @@ required:
- interrupts
- clocks
- clock-names
+ - xlnx,bus-width
additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
fpd_dma_chan1: dma-controller@fd500000 {
compatible = "xlnx,zynqmp-dma-1.0";
@@ -79,7 +82,7 @@ examples:
interrupts = <0 117 0x4>;
#dma-cells = <1>;
clock-names = "clk_main", "clk_apb";
- clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
+ clocks = <&zynqmp_clk 19>, <&zynqmp_clk 31>;
xlnx,bus-width = <128>;
dma-coherent;
};
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
index 2a595b18ff6c..2128f4645c98 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
+++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dpdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx ZynqMP DisplayPort DMA Controller Device Tree Bindings
+title: Xilinx ZynqMP DisplayPort DMA Controller
description: |
These bindings describe the DMA engine included in the Xilinx ZynqMP
@@ -16,7 +16,7 @@ maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
allOf:
- - $ref: "../dma-controller.yaml#"
+ - $ref: ../dma-controller.yaml#
properties:
"#dma-cells":
@@ -41,6 +41,9 @@ properties:
clock-names:
const: axi_clk
+ power-domains:
+ maxItems: 1
+
required:
- "#dma-cells"
- compatible
@@ -48,12 +51,14 @@ required:
- interrupts
- clocks
- clock-names
+ - power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
dma: dma-controller@fd4c0000 {
compatible = "xlnx,zynqmp-dpdma";
@@ -63,6 +68,7 @@ examples:
clocks = <&dpdma_clk>;
clock-names = "axi_clk";
#dma-cells = <1>;
+ power-domains = <&zynqmp_firmware PD_DP>;
};
...
diff --git a/Documentation/devicetree/bindings/dpll/dpll-device.yaml b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
new file mode 100644
index 000000000000..fb8d7a9a3693
--- /dev/null
+++ b/Documentation/devicetree/bindings/dpll/dpll-device.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dpll/dpll-device.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Digital Phase-Locked Loop (DPLL) Device
+
+maintainers:
+ - Ivan Vecera <ivecera@redhat.com>
+
+description:
+ Digital Phase-Locked Loop (DPLL) device is used for precise clock
+ synchronization in networking and telecom hardware. The device can
+ have one or more channels (DPLLs) and one or more physical input and
+ output pins. Each DPLL channel can either produce pulse-per-clock signal
+ or drive ethernet equipment clock. The type of each channel can be
+ indicated by dpll-types property.
+
+properties:
+ $nodename:
+ pattern: "^dpll(@.*)?$"
+
+ "#address-cells":
+ const: 0
+
+ "#size-cells":
+ const: 0
+
+ dpll-types:
+ description: List of DPLL channel types, one per DPLL instance.
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ items:
+ enum: [pps, eec]
+
+ input-pins:
+ type: object
+ description: DPLL input pins
+ unevaluatedProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^pin@[0-9a-f]+$":
+ $ref: /schemas/dpll/dpll-pin.yaml
+ unevaluatedProperties: false
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ output-pins:
+ type: object
+ description: DPLL output pins
+ unevaluatedProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^pin@[0-9]+$":
+ $ref: /schemas/dpll/dpll-pin.yaml
+ unevaluatedProperties: false
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
new file mode 100644
index 000000000000..51db93b77306
--- /dev/null
+++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dpll/dpll-pin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DPLL Pin
+
+maintainers:
+ - Ivan Vecera <ivecera@redhat.com>
+
+description: |
+ The DPLL pin is either a physical input or output pin that is provided
+ by a DPLL( Digital Phase-Locked Loop) device. The pin is identified by
+ its physical order number that is stored in reg property and can have
+ an additional set of properties like supported (allowed) frequencies,
+ label, type and may support embedded sync.
+
+ Note that the pin in this context has nothing to do with pinctrl.
+
+properties:
+ reg:
+ description: Hardware index of the DPLL pin.
+ maxItems: 1
+
+ connection-type:
+ description: Connection type of the pin
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ext, gnss, int, mux, synce]
+
+ esync-control:
+ description: Indicates whether the pin supports embedded sync functionality.
+ type: boolean
+
+ label:
+ description: String exposed as the pin board label
+ $ref: /schemas/types.yaml#/definitions/string
+
+ supported-frequencies-hz:
+ description: List of supported frequencies for this pin, expressed in Hz.
+
+required:
+ - reg
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
new file mode 100644
index 000000000000..17747f754b84
--- /dev/null
+++ b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dpll/microchip,zl30731.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Azurite DPLL device
+
+maintainers:
+ - Ivan Vecera <ivecera@redhat.com>
+
+description:
+ Microchip Azurite DPLL (ZL3073x) is a family of DPLL devices that
+ provides up to 5 independent DPLL channels, up to 10 differential or
+ single-ended inputs and 10 differential or 20 single-ended outputs.
+ These devices support both I2C and SPI interfaces.
+
+properties:
+ compatible:
+ enum:
+ - microchip,zl30731
+ - microchip,zl30732
+ - microchip,zl30733
+ - microchip,zl30734
+ - microchip,zl30735
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/dpll/dpll-device.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpll@70 {
+ compatible = "microchip,zl30732";
+ reg = <0x70>;
+ dpll-types = "pps", "eec";
+
+ input-pins {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pin@0 { /* REF0P */
+ reg = <0>;
+ connection-type = "ext";
+ label = "Input 0";
+ supported-frequencies-hz = /bits/ 64 <1 1000>;
+ };
+ };
+
+ output-pins {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pin@3 { /* OUT1N */
+ reg = <3>;
+ connection-type = "gnss";
+ esync-control;
+ label = "Output 1";
+ supported-frequencies-hz = /bits/ 64 <1 10000>;
+ };
+ };
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpll@70 {
+ compatible = "microchip,zl30731";
+ reg = <0x70>;
+ spi-max-frequency = <12500000>;
+
+ dpll-types = "pps";
+
+ input-pins {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pin@0 { /* REF0P */
+ reg = <0>;
+ connection-type = "ext";
+ label = "Input 0";
+ supported-frequencies-hz = /bits/ 64 <1 1000>;
+ };
+ };
+
+ output-pins {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pin@3 { /* OUT1N */
+ reg = <3>;
+ connection-type = "gnss";
+ esync-control;
+ label = "Output 1";
+ supported-frequencies-hz = /bits/ 64 <1 10000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index 9af40da5688e..e610b7636a08 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -82,6 +82,18 @@ properties:
description:
Phandle to syscon block which provide access for processor enablement
+ resets:
+ minItems: 1
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: runstall
+ - const: softreset
+
+ access-controllers:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -99,14 +111,35 @@ allOf:
contains:
enum:
- fsl,imx8qxp-dsp
- - fsl,imx8qm-dsp
- fsl,imx8qxp-hifi4
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-dsp
- fsl,imx8qm-hifi4
then:
properties:
power-domains:
minItems: 4
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mp-dsp
+ - fsl,imx8mp-hifi4
+ - fsl,imx8ulp-dsp
+ - fsl,imx8ulp-hifi4
+ then:
properties:
power-domains:
maxItems: 1
@@ -143,6 +176,17 @@ allOf:
- const: txdb1
- const: rxdb0
- const: rxdb1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mp-dsp
+ - fsl,imx8mp-hifi4
+ then:
+ required:
+ - resets
+ - reset-names
additionalProperties: false
@@ -157,16 +201,15 @@ examples:
<&adma_lpcg IMX_ADMA_LPCG_OCRAM_IPG_CLK>,
<&adma_lpcg IMX_ADMA_LPCG_DSP_CORE_CLK>;
clock-names = "ipg", "ocram", "core";
- power-domains = <&pd IMX_SC_R_MU_13A>,
- <&pd IMX_SC_R_MU_13B>,
- <&pd IMX_SC_R_DSP>,
- <&pd IMX_SC_R_DSP_RAM>;
+ power-domains = <&pd IMX_SC_R_MU_13B>,
+ <&pd IMX_SC_R_MU_2A>;
mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
memory-region = <&dsp_reserved>;
};
- |
#include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/reset/imx8mp-reset-audiomix.h>
dsp_reserved: dsp@92400000 {
reg = <0x92400000 0x1000000>;
no-map;
@@ -201,5 +244,6 @@ examples:
<&mu2 3 0>;
memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
<&dsp_vdev0vring1>, <&dsp_reserved>;
- fsl,dsp-ctrl = <&audio_blk_ctrl>;
+ resets = <&audio_blk_ctrl IMX8MP_AUDIOMIX_DSP_RUNSTALL>;
+ reset-names = "runstall";
};
diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml
index 3e63f79890b4..88575da1e6d5 100644
--- a/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8186-dsp.yaml
@@ -15,7 +15,9 @@ description: |
properties:
compatible:
- const: mediatek,mt8186-dsp
+ enum:
+ - mediatek,mt8186-dsp
+ - mediatek,mt8188-dsp
reg:
items:
diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
index ca8d8661f872..abc52978be7a 100644
--- a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
@@ -81,25 +81,25 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
dsp@10803000 {
- compatible = "mediatek,mt8195-dsp";
- reg = <0x10803000 0x1000>,
- <0x10840000 0x40000>;
- reg-names = "cfg", "sram";
- clocks = <&topckgen 10>, //CLK_TOP_ADSP
- <&clk26m>,
- <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS
- <&topckgen 136>, //CLK_TOP_MAINPLL_D7_D2
- <&scp_adsp 0>, //CLK_SCP_ADSP_AUDIODSP
- <&topckgen 34>; //CLK_TOP_AUDIO_H
- clock-names = "adsp_sel",
- "clk26m_ck",
- "audio_local_bus",
- "mainpll_d7_d2",
- "scp_adsp_audiodsp",
- "audio_h";
- memory-region = <&adsp_dma_mem_reserved>,
- <&adsp_mem_reserved>;
- power-domains = <&spm 6>; //MT8195_POWER_DOMAIN_ADSP
- mbox-names = "rx", "tx";
- mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>;
+ compatible = "mediatek,mt8195-dsp";
+ reg = <0x10803000 0x1000>,
+ <0x10840000 0x40000>;
+ reg-names = "cfg", "sram";
+ clocks = <&topckgen 10>, //CLK_TOP_ADSP
+ <&clk26m>,
+ <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS
+ <&topckgen 136>, //CLK_TOP_MAINPLL_D7_D2
+ <&scp_adsp 0>, //CLK_SCP_ADSP_AUDIODSP
+ <&topckgen 34>; //CLK_TOP_AUDIO_H
+ clock-names = "adsp_sel",
+ "clk26m_ck",
+ "audio_local_bus",
+ "mainpll_d7_d2",
+ "scp_adsp_audiodsp",
+ "audio_h";
+ memory-region = <&adsp_dma_mem_reserved>,
+ <&adsp_mem_reserved>;
+ power-domains = <&spm 6>; //MT8195_POWER_DOMAIN_ADSP
+ mbox-names = "rx", "tx";
+ mboxes = <&adsp_mailbox0>, <&adsp_mailbox1>;
};
diff --git a/Documentation/devicetree/bindings/dts-coding-style.rst b/Documentation/devicetree/bindings/dts-coding-style.rst
new file mode 100644
index 000000000000..4a02ea60cbbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/dts-coding-style.rst
@@ -0,0 +1,213 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Devicetree Sources (DTS) Coding Style
+=====================================
+
+When writing Devicetree Sources (DTS) please observe below guidelines. They
+should be considered complementary to any rules expressed already in
+the Devicetree Specification and the dtc compiler (including W=1 and W=2
+builds).
+
+Individual architectures and subarchitectures can define additional rules,
+making the coding style stricter.
+
+Naming and Valid Characters
+---------------------------
+
+The Devicetree Specification allows a broad range of characters in node
+and property names, but this coding style narrows the range down to achieve
+better code readability.
+
+1. Node and property names can use only the following characters:
+
+ * Lowercase characters: [a-z]
+ * Digits: [0-9]
+ * Dash: -
+
+2. Labels can use only the following characters:
+
+ * Lowercase characters: [a-z]
+ * Digits: [0-9]
+ * Underscore: _
+
+3. Unless a bus defines differently, unit addresses shall use lowercase
+ hexadecimal digits, without leading zeros (padding).
+
+4. Hex values in properties, e.g. "reg", shall use lowercase hex. The address
+ part can be padded with leading zeros.
+
+Example::
+
+ gpi_dma2: dma-controller@a00000 {
+ compatible = "qcom,sm8550-gpi-dma", "qcom,sm6350-gpi-dma";
+ reg = <0x0 0x00a00000 0x0 0x60000>;
+ }
+
+Order of Nodes
+--------------
+
+1. Nodes on any bus, thus using unit addresses for children, shall be
+ ordered by unit address in ascending order.
+ Alternatively for some subarchitectures, nodes of the same type can be
+ grouped together, e.g. all I2C controllers one after another even if this
+ breaks unit address ordering.
+
+2. Nodes without unit addresses shall be ordered alpha-numerically by the node
+ name. For a few node types, they can be ordered by the main property, e.g.
+ pin configuration states ordered by value of "pins" property.
+
+3. When extending nodes in the board DTS via &label, the entries shall be
+ ordered either alpha-numerically or by keeping the order from DTSI, where
+ the choice depends on the subarchitecture.
+
+The above-described ordering rules are easy to enforce during review, reduce
+chances of conflicts for simultaneous additions of new nodes to a file and help
+in navigating through the DTS source.
+
+Example::
+
+ /* SoC DTSI */
+
+ / {
+ cpus {
+ /* ... */
+ };
+
+ psci {
+ /* ... */
+ };
+
+ soc@0 {
+ dma: dma-controller@10000 {
+ /* ... */
+ };
+
+ clk: clock-controller@80000 {
+ /* ... */
+ };
+ };
+ };
+
+ /* Board DTS - alphabetical order */
+
+ &clk {
+ /* ... */
+ };
+
+ &dma {
+ /* ... */
+ };
+
+ /* Board DTS - alternative order, keep as DTSI */
+
+ &dma {
+ /* ... */
+ };
+
+ &clk {
+ /* ... */
+ };
+
+Order of Properties in Device Node
+----------------------------------
+
+The following order of properties in device nodes is preferred:
+
+1. "compatible"
+2. "reg"
+3. "ranges"
+4. Standard/common properties (defined by common bindings, e.g. without
+ vendor-prefixes)
+5. Vendor-specific properties
+6. "status" (if applicable), preceded by a blank line if there is content
+ before the property
+7. Child nodes, where each node is preceded with a blank line
+
+The "status" property is by default "okay", thus it can be omitted.
+
+The above-described ordering follows this approach:
+
+1. Most important properties start the node: compatible then bus addressing to
+ match unit address.
+2. Each node will have common properties in similar place.
+3. Status is the last information to annotate that device node is or is not
+ finished (board resources are needed).
+
+The individual properties inside each group shall use natural sort order by
+the property name.
+
+Example::
+
+ /* SoC DTSI */
+
+ device_node: device-class@6789abc {
+ compatible = "vendor,device";
+ reg = <0x0 0x06789abc 0x0 0xa123>;
+ ranges = <0x0 0x0 0x06789abc 0x1000>;
+ #dma-cells = <1>;
+ clocks = <&clock_controller 0>, <&clock_controller 1>;
+ clock-names = "bus", "host";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ vendor,custom-property = <2>;
+
+ status = "disabled";
+
+ child_node: child-class@100 {
+ reg = <0x100 0x200>;
+ /* ... */
+ };
+ };
+
+ /* Board DTS */
+
+ &device_node {
+ vdd-0v9-supply = <&board_vreg1>;
+ vdd-1v8-supply = <&board_vreg4>;
+ vdd-3v3-supply = <&board_vreg2>;
+ vdd-12v-supply = <&board_vreg3>;
+
+ status = "okay";
+ }
+
+Indentation and wrapping
+------------------------
+
+1. Use indentation and wrap lines according to
+ Documentation/process/coding-style.rst.
+2. Each entry in arrays with multiple cells, e.g. "reg" with two IO addresses,
+ shall be enclosed in <>.
+3. For arrays spanning across lines, it is preferred to split on item boundary
+ and align the continued entries with opening < from the first line.
+ Usually avoid splitting individual items unless they significantly exceed
+ line wrap limit.
+
+Example::
+
+ thermal-sensor@c271000 {
+ compatible = "qcom,sm8550-tsens", "qcom,tsens-v2";
+ reg = <0x0 0x0c271000 0x0 0x1000>,
+ <0x0 0x0c222000 0x0 0x1000>;
+ /* Lines exceeding coding style line wrap limit: */
+ interconnects = <&aggre1_noc MASTER_USB3_0 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_USB3_0 0>;
+ };
+
+Organizing DTSI and DTS
+-----------------------
+
+The DTSI and DTS files shall be organized in a way representing the common,
+reusable parts of hardware. Typically, this means organizing DTSI and DTS files
+into several files:
+
+1. DTSI with contents of the entire SoC, without nodes for hardware not present
+ on the SoC.
+2. If applicable: DTSI with common or re-usable parts of the hardware, e.g.
+ entire System-on-Module.
+3. DTS representing the board.
+
+Hardware components that are present on the board shall be placed in the
+board DTS, not in the SoC or SoM DTSI. A partial exception is a common
+external reference SoC input clock, which could be coded as a fixed-clock in
+the SoC DTSI with its frequency provided by each board DTS.
diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
index 1dcb85a02a76..cc930660b794 100644
--- a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
+++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml
@@ -42,7 +42,7 @@ properties:
enum: [ 0, 1 ]
performance-domains:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description:
A phandle and performance domain specifier as defined by bindings of the
performance controller/provider specified by phandle.
diff --git a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
new file mode 100644
index 000000000000..136e8fccd429
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
@@ -0,0 +1,324 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2025 Altera Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/edac/altr,socfpga-ecc-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera SoCFPGA ECC Manager
+
+maintainers:
+ - Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
+
+description:
+ This binding describes the device tree nodes required for the Altera SoCFPGA
+ ECC Manager for the Cyclone5, Arria5, Arria10, Stratix10, and Agilex chip
+ families.
+
+properties:
+
+ compatible:
+ oneOf:
+ - items:
+ - const: altr,socfpga-s10-ecc-manager
+ - const: altr,socfpga-a10-ecc-manager
+ - const: altr,socfpga-a10-ecc-manager
+ - const: altr,socfpga-ecc-manager
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ ranges: true
+
+ altr,sysmgr-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to Stratix10 System Manager Block with the ECC manager registers
+
+ sdramedac:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - altr,sdram-edac
+ - altr,sdram-edac-a10
+ - altr,sdram-edac-s10
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ altr,sdr-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to SDRAM parent
+
+ required:
+ - compatible
+ - interrupts
+ - altr,sdr-syscon
+
+patternProperties:
+ "^ocram-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: altr,socfpga-s10-ocram-ecc
+ - const: altr,socfpga-a10-ocram-ecc
+ - const: altr,socfpga-a10-ocram-ecc
+ - const: altr,socfpga-ocram-ecc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ iram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to OCRAM parent
+
+ altr,ecc-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to OCRAM parent
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+
+ "^usb[0-9]-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: altr,socfpga-s10-usb-ecc
+ - const: altr,socfpga-usb-ecc
+ - const: altr,socfpga-usb-ecc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ altr,ecc-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to USB parent
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+ - altr,ecc-parent
+
+ "^emac[0-9]-[t,r]x-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: altr,socfpga-s10-eth-mac-ecc
+ - const: altr,socfpga-eth-mac-ecc
+ - const: altr,socfpga-eth-mac-ecc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ altr,ecc-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to ethernet parent
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+ - altr,ecc-parent
+
+ "^sdmmc[a-f]-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: altr,socfpga-s10-sdmmc-ecc
+ - const: altr,socfpga-sdmmc-ecc
+ - const: altr,socfpga-sdmmc-ecc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 2
+ maxItems: 4
+
+ altr,ecc-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to SD/MMC parent
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+ - altr,ecc-parent
+
+ "^l2-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - altr,socfpga-a10-l2-ecc
+ - altr,socfpga-l2-ecc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+
+ "^dma-ecc@[a-f0-9]+$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: altr,socfpga-dma-ecc
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ altr,ecc-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to SD/MMC parent
+
+ required:
+ - compatible
+ - reg
+ - interrupts
+ - altr,ecc-parent
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: altr,socfpga-ecc-manager
+then:
+ required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+else:
+ required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - ranges
+ - altr,sysmgr-syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ eccmgr {
+ compatible = "altr,socfpga-s10-ecc-manager",
+ "altr,socfpga-a10-ecc-manager";
+ altr,sysmgr-syscon = <&sysmgr>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ranges;
+
+ sdramedac {
+ compatible = "altr,sdram-edac-s10";
+ altr,sdr-syscon = <&sdr>;
+ interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ ocram-ecc@ff8cc000 {
+ compatible = "altr,socfpga-s10-ocram-ecc",
+ "altr,socfpga-a10-ocram-ecc";
+ reg = <0xff8cc000 0x100>;
+ altr,ecc-parent = <&ocram>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ usb0-ecc@ff8c4000 {
+ compatible = "altr,socfpga-s10-usb-ecc",
+ "altr,socfpga-usb-ecc";
+ reg = <0xff8c4000 0x100>;
+ altr,ecc-parent = <&usb0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ emac0-rx-ecc@ff8c0000 {
+ compatible = "altr,socfpga-s10-eth-mac-ecc",
+ "altr,socfpga-eth-mac-ecc";
+ reg = <0xff8c0000 0x100>;
+ altr,ecc-parent = <&gmac0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ emac0-tx-ecc@ff8c0400 {
+ compatible = "altr,socfpga-s10-eth-mac-ecc",
+ "altr,socfpga-eth-mac-ecc";
+ reg = <0xff8c0400 0x100>;
+ altr,ecc-parent = <&gmac0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sdmmca-ecc@ff8c8c00 {
+ compatible = "altr,socfpga-s10-sdmmc-ecc",
+ "altr,socfpga-sdmmc-ecc";
+ reg = <0xff8c8c00 0x100>;
+ altr,ecc-parent = <&mmc>;
+ interrupts = <14 IRQ_TYPE_LEVEL_HIGH>,
+ <15 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/edac/apm,xgene-edac.yaml b/Documentation/devicetree/bindings/edac/apm,xgene-edac.yaml
new file mode 100644
index 000000000000..9637df7af3c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/apm,xgene-edac.yaml
@@ -0,0 +1,202 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/edac/apm,xgene-edac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC EDAC
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+description: >
+ EDAC node is defined to describe on-chip error detection and correction.
+
+ The following error types are supported:
+
+ memory controller - Memory controller
+ PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache
+ L3 - L3 cache controller
+ SoC - SoC IPs such as Ethernet, SATA, etc
+
+properties:
+ compatible:
+ const: apm,xgene-edac
+
+ reg:
+ items:
+ - description: CPU bus (PCP) resource
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ ranges: true
+
+ interrupts:
+ description: Interrupt-specifier for MCU, PMD, L3, or SoC error IRQ(s).
+ items:
+ - description: MCU error IRQ
+ - description: PMD error IRQ
+ - description: L3 error IRQ
+ - description: SoC error IRQ
+ minItems: 1
+
+ regmap-csw:
+ description: Regmap of the CPU switch fabric (CSW) resource.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ regmap-mcba:
+ description: Regmap of the MCB-A (memory bridge) resource.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ regmap-mcbb:
+ description: Regmap of the MCB-B (memory bridge) resource.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ regmap-efuse:
+ description: Regmap of the PMD efuse resource.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ regmap-rb:
+ description: Regmap of the register bus resource (optional for compatibility).
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - regmap-csw
+ - regmap-mcba
+ - regmap-mcbb
+ - regmap-efuse
+ - reg
+ - interrupts
+
+# Child-node bindings
+patternProperties:
+ '^edacmc@':
+ description: Memory controller subnode
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: apm,xgene-edac-mc
+
+ reg:
+ maxItems: 1
+
+ memory-controller:
+ description: Instance number of the memory controller.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ required:
+ - compatible
+ - reg
+ - memory-controller
+
+ '^edacpmd@':
+ description: PMD subnode
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: apm,xgene-edac-pmd
+
+ reg:
+ maxItems: 1
+
+ pmd-controller:
+ description: Instance number of the PMD controller.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ required:
+ - compatible
+ - reg
+ - pmd-controller
+
+ '^edacl3@':
+ description: L3 subnode
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - apm,xgene-edac-l3
+ - apm,xgene-edac-l3-v2
+
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+ '^edacsoc@':
+ description: SoC subnode
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - apm,xgene-edac-soc
+ - apm,xgene-edac-soc-v1
+
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ edac@78800000 {
+ compatible = "apm,xgene-edac";
+ reg = <0x0 0x78800000 0x0 0x100>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ interrupts = <0x0 0x20 0x4>, <0x0 0x21 0x4>, <0x0 0x27 0x4>;
+
+ regmap-csw = <&csw>;
+ regmap-mcba = <&mcba>;
+ regmap-mcbb = <&mcbb>;
+ regmap-efuse = <&efuse>;
+ regmap-rb = <&rb>;
+
+ edacmc@7e800000 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e800000 0x0 0x1000>;
+ memory-controller = <0>;
+ };
+
+ edacpmd@7c000000 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c000000 0x0 0x200000>;
+ pmd-controller = <0>;
+ };
+
+ edacl3@7e600000 {
+ compatible = "apm,xgene-edac-l3";
+ reg = <0x0 0x7e600000 0x0 0x1000>;
+ };
+
+ edacsoc@7e930000 {
+ compatible = "apm,xgene-edac-soc-v1";
+ reg = <0x0 0x7e930000 0x0 0x1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
deleted file mode 100644
index 1006b0489464..000000000000
--- a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-* APM X-Gene SoC EDAC node
-
-EDAC node is defined to describe on-chip error detection and correction.
-The follow error types are supported:
-
- memory controller - Memory controller
- PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache
- L3 - L3 cache controller
- SoC - SoC IP's such as Ethernet, SATA, and etc
-
-The following section describes the EDAC DT node binding.
-
-Required properties:
-- compatible : Shall be "apm,xgene-edac".
-- regmap-csw : Regmap of the CPU switch fabric (CSW) resource.
-- regmap-mcba : Regmap of the MCB-A (memory bridge) resource.
-- regmap-mcbb : Regmap of the MCB-B (memory bridge) resource.
-- regmap-efuse : Regmap of the PMD efuse resource.
-- regmap-rb : Regmap of the register bus resource. This property
- is optional only for compatibility. If the RB
- error conditions are not cleared, it will
- continuously generate interrupt.
-- reg : First resource shall be the CPU bus (PCP) resource.
-- interrupts : Interrupt-specifier for MCU, PMD, L3, or SoC error
- IRQ(s).
-
-Required properties for memory controller subnode:
-- compatible : Shall be "apm,xgene-edac-mc".
-- reg : First resource shall be the memory controller unit
- (MCU) resource.
-- memory-controller : Instance number of the memory controller.
-
-Required properties for PMD subnode:
-- compatible : Shall be "apm,xgene-edac-pmd" or
- "apm,xgene-edac-pmd-v2".
-- reg : First resource shall be the PMD resource.
-- pmd-controller : Instance number of the PMD controller.
-
-Required properties for L3 subnode:
-- compatible : Shall be "apm,xgene-edac-l3" or
- "apm,xgene-edac-l3-v2".
-- reg : First resource shall be the L3 EDAC resource.
-
-Required properties for SoC subnode:
-- compatible : Shall be "apm,xgene-edac-soc-v1" for revision 1 or
- "apm,xgene-edac-l3-soc" for general value reporting
- only.
-- reg : First resource shall be the SoC EDAC resource.
-
-Example:
- csw: csw@7e200000 {
- compatible = "apm,xgene-csw", "syscon";
- reg = <0x0 0x7e200000 0x0 0x1000>;
- };
-
- mcba: mcba@7e700000 {
- compatible = "apm,xgene-mcb", "syscon";
- reg = <0x0 0x7e700000 0x0 0x1000>;
- };
-
- mcbb: mcbb@7e720000 {
- compatible = "apm,xgene-mcb", "syscon";
- reg = <0x0 0x7e720000 0x0 0x1000>;
- };
-
- efuse: efuse@1054a000 {
- compatible = "apm,xgene-efuse", "syscon";
- reg = <0x0 0x1054a000 0x0 0x20>;
- };
-
- rb: rb@7e000000 {
- compatible = "apm,xgene-rb", "syscon";
- reg = <0x0 0x7e000000 0x0 0x10>;
- };
-
- edac@78800000 {
- compatible = "apm,xgene-edac";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- regmap-csw = <&csw>;
- regmap-mcba = <&mcba>;
- regmap-mcbb = <&mcbb>;
- regmap-efuse = <&efuse>;
- regmap-rb = <&rb>;
- reg = <0x0 0x78800000 0x0 0x100>;
- interrupts = <0x0 0x20 0x4>,
- <0x0 0x21 0x4>,
- <0x0 0x27 0x4>;
-
- edacmc@7e800000 {
- compatible = "apm,xgene-edac-mc";
- reg = <0x0 0x7e800000 0x0 0x1000>;
- memory-controller = <0>;
- };
-
- edacpmd@7c000000 {
- compatible = "apm,xgene-edac-pmd";
- reg = <0x0 0x7c000000 0x0 0x200000>;
- pmd-controller = <0>;
- };
-
- edacl3@7e600000 {
- compatible = "apm,xgene-edac-l3";
- reg = <0x0 0x7e600000 0x0 0x1000>;
- };
-
- edacsoc@7e930000 {
- compatible = "apm,xgene-edac-soc-v1";
- reg = <0x0 0x7e930000 0x0 0x1000>;
- };
- };
diff --git a/Documentation/devicetree/bindings/edac/aspeed,ast2400-sdram-edac.yaml b/Documentation/devicetree/bindings/edac/aspeed,ast2400-sdram-edac.yaml
new file mode 100644
index 000000000000..09735826d707
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/aspeed,ast2400-sdram-edac.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/edac/aspeed,ast2400-sdram-edac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed BMC SoC SDRAM EDAC controller
+
+maintainers:
+ - Stefan Schaeckeler <sschaeck@cisco.com>
+
+description: >
+ The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error
+ correction check).
+
+ The memory controller supports SECDED (single bit error correction, double bit
+ error detection) and single bit error auto scrubbing by reserving 8 bits for
+ every 64 bit word (effectively reducing available memory to 8/9).
+
+ Note, the bootloader must configure ECC mode in the memory controller.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-sdram-edac
+ - aspeed,ast2500-sdram-edac
+ - aspeed,ast2600-sdram-edac
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ sdram@1e6e0000 {
+ compatible = "aspeed,ast2500-sdram-edac";
+ reg = <0x1e6e0000 0x174>;
+ interrupts = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
deleted file mode 100644
index 8ca9e0a049d8..000000000000
--- a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Aspeed BMC SoC EDAC node
-
-The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error
-correction check).
-
-The memory controller supports SECDED (single bit error correction, double bit
-error detection) and single bit error auto scrubbing by reserving 8 bits for
-every 64 bit word (effectively reducing available memory to 8/9).
-
-Note, the bootloader must configure ECC mode in the memory controller.
-
-
-Required properties:
-- compatible: should be one of
- - "aspeed,ast2400-sdram-edac"
- - "aspeed,ast2500-sdram-edac"
- - "aspeed,ast2600-sdram-edac"
-- reg: sdram controller register set should be <0x1e6e0000 0x174>
-- interrupts: should be AVIC interrupt #0
-
-
-Example:
-
- edac: sdram@1e6e0000 {
- compatible = "aspeed,ast2500-sdram-edac";
- reg = <0x1e6e0000 0x174>;
- interrupts = <0>;
- };
diff --git a/Documentation/devicetree/bindings/edac/dmc-520.yaml b/Documentation/devicetree/bindings/edac/dmc-520.yaml
index 3b6842e92d1b..84db3966662a 100644
--- a/Documentation/devicetree/bindings/edac/dmc-520.yaml
+++ b/Documentation/devicetree/bindings/edac/dmc-520.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/edac/dmc-520.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ARM DMC-520 EDAC bindings
+title: ARM DMC-520 EDAC
maintainers:
- Lei Wang <lewan@microsoft.com>
diff --git a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
deleted file mode 100644
index 8f52206cfd2a..000000000000
--- a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt
+++ /dev/null
@@ -1,383 +0,0 @@
-Altera SoCFPGA ECC Manager
-This driver uses the EDAC framework to implement the SOCFPGA ECC Manager.
-The ECC Manager counts and corrects single bit errors and counts/handles
-double bit errors which are uncorrectable.
-
-Cyclone5 and Arria5 ECC Manager
-Required Properties:
-- compatible : Should be "altr,socfpga-ecc-manager"
-- #address-cells: must be 1
-- #size-cells: must be 1
-- ranges : standard definition, should translate from local addresses
-
-Subcomponents:
-
-L2 Cache ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-l2-ecc"
-- reg : Address and size for ECC error interrupt clear registers.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt. Note the rising edge type.
-
-On Chip RAM ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-ocram-ecc"
-- reg : Address and size for ECC error interrupt clear registers.
-- iram : phandle to On-Chip RAM definition.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt. Note the rising edge type.
-
-Example:
-
- eccmgr: eccmgr@ffd08140 {
- compatible = "altr,socfpga-ecc-manager";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- l2-ecc@ffd08140 {
- compatible = "altr,socfpga-l2-ecc";
- reg = <0xffd08140 0x4>;
- interrupts = <0 36 1>, <0 37 1>;
- };
-
- ocram-ecc@ffd08144 {
- compatible = "altr,socfpga-ocram-ecc";
- reg = <0xffd08144 0x4>;
- iram = <&ocram>;
- interrupts = <0 178 1>, <0 179 1>;
- };
- };
-
-Arria10 SoCFPGA ECC Manager
-The Arria10 SoC ECC Manager handles the IRQs for each peripheral
-in a shared register instead of individual IRQs like the Cyclone5
-and Arria5. Therefore the device tree is different as well.
-
-Required Properties:
-- compatible : Should be "altr,socfpga-a10-ecc-manager"
-- altr,sysgr-syscon : phandle to Arria10 System Manager Block
- containing the ECC manager registers.
-- #address-cells: must be 1
-- #size-cells: must be 1
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt.
-- interrupt-controller : boolean indicator that ECC Manager is an interrupt controller
-- #interrupt-cells : must be set to 2.
-- ranges : standard definition, should translate from local addresses
-
-Subcomponents:
-
-L2 Cache ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-a10-l2-ecc"
-- reg : Address and size for ECC error interrupt clear registers.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-On-Chip RAM ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-a10-ocram-ecc"
-- reg : Address and size for ECC block registers.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-Ethernet FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-eth-mac-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent Ethernet node.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-NAND FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-nand-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent NAND node.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-DMA FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-dma-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent DMA node.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-USB FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-usb-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent USB node.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-QSPI FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-qspi-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent QSPI node.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order.
-
-SDMMC FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-sdmmc-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent SD/MMC node.
-- interrupts : Should be single bit error interrupt, then double bit error
- interrupt, in this order for port A, and then single bit error interrupt,
- then double bit error interrupt in this order for port B.
-
-Example:
-
- eccmgr: eccmgr@ffd06000 {
- compatible = "altr,socfpga-a10-ecc-manager";
- altr,sysmgr-syscon = <&sysmgr>;
- #address-cells = <1>;
- #size-cells = <1>;
- interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- ranges;
-
- l2-ecc@ffd06010 {
- compatible = "altr,socfpga-a10-l2-ecc";
- reg = <0xffd06010 0x4>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>,
- <32 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- ocram-ecc@ff8c3000 {
- compatible = "altr,socfpga-a10-ocram-ecc";
- reg = <0xff8c3000 0x90>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH>,
- <33 IRQ_TYPE_LEVEL_HIGH> ;
- };
-
- emac0-rx-ecc@ff8c0800 {
- compatible = "altr,socfpga-eth-mac-ecc";
- reg = <0xff8c0800 0x400>;
- altr,ecc-parent = <&gmac0>;
- interrupts = <4 IRQ_TYPE_LEVEL_HIGH>,
- <36 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- emac0-tx-ecc@ff8c0c00 {
- compatible = "altr,socfpga-eth-mac-ecc";
- reg = <0xff8c0c00 0x400>;
- altr,ecc-parent = <&gmac0>;
- interrupts = <5 IRQ_TYPE_LEVEL_HIGH>,
- <37 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- nand-buf-ecc@ff8c2000 {
- compatible = "altr,socfpga-nand-ecc";
- reg = <0xff8c2000 0x400>;
- altr,ecc-parent = <&nand>;
- interrupts = <11 IRQ_TYPE_LEVEL_HIGH>,
- <43 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- nand-rd-ecc@ff8c2400 {
- compatible = "altr,socfpga-nand-ecc";
- reg = <0xff8c2400 0x400>;
- altr,ecc-parent = <&nand>;
- interrupts = <13 IRQ_TYPE_LEVEL_HIGH>,
- <45 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- nand-wr-ecc@ff8c2800 {
- compatible = "altr,socfpga-nand-ecc";
- reg = <0xff8c2800 0x400>;
- altr,ecc-parent = <&nand>;
- interrupts = <12 IRQ_TYPE_LEVEL_HIGH>,
- <44 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- dma-ecc@ff8c8000 {
- compatible = "altr,socfpga-dma-ecc";
- reg = <0xff8c8000 0x400>;
- altr,ecc-parent = <&pdma>;
- interrupts = <10 IRQ_TYPE_LEVEL_HIGH>,
- <42 IRQ_TYPE_LEVEL_HIGH>;
-
- usb0-ecc@ff8c8800 {
- compatible = "altr,socfpga-usb-ecc";
- reg = <0xff8c8800 0x400>;
- altr,ecc-parent = <&usb0>;
- interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
- <34 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- qspi-ecc@ff8c8400 {
- compatible = "altr,socfpga-qspi-ecc";
- reg = <0xff8c8400 0x400>;
- altr,ecc-parent = <&qspi>;
- interrupts = <14 IRQ_TYPE_LEVEL_HIGH>,
- <46 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- sdmmc-ecc@ff8c2c00 {
- compatible = "altr,socfpga-sdmmc-ecc";
- reg = <0xff8c2c00 0x400>;
- altr,ecc-parent = <&mmc>;
- interrupts = <15 IRQ_TYPE_LEVEL_HIGH>,
- <47 IRQ_TYPE_LEVEL_HIGH>,
- <16 IRQ_TYPE_LEVEL_HIGH>,
- <48 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
-
-Stratix10 SoCFPGA ECC Manager (ARM64)
-The Stratix10 SoC ECC Manager handles the IRQs for each peripheral
-in a shared register similar to the Arria10. However, Stratix10 ECC
-requires access to registers that can only be read from Secure Monitor
-with SMC calls. Therefore the device tree is slightly different. Note
-that only 1 interrupt is sent in Stratix10 because the double bit errors
-are treated as SErrors in ARM64 instead of IRQs in ARM32.
-
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-ecc-manager"
-- altr,sysgr-syscon : phandle to Stratix10 System Manager Block
- containing the ECC manager registers.
-- interrupts : Should be single bit error interrupt.
-- interrupt-controller : boolean indicator that ECC Manager is an interrupt controller
-- #interrupt-cells : must be set to 2.
-- #address-cells: must be 1
-- #size-cells: must be 1
-- ranges : standard definition, should translate from local addresses
-
-Subcomponents:
-
-SDRAM ECC
-Required Properties:
-- compatible : Should be "altr,sdram-edac-s10"
-- interrupts : Should be single bit error interrupt.
-
-On-Chip RAM ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-ocram-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent OCRAM node.
-- interrupts : Should be single bit error interrupt.
-
-Ethernet FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-eth-mac-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent Ethernet node.
-- interrupts : Should be single bit error interrupt.
-
-NAND FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-nand-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent NAND node.
-- interrupts : Should be single bit error interrupt.
-
-DMA FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-dma-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent DMA node.
-- interrupts : Should be single bit error interrupt.
-
-USB FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-usb-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent USB node.
-- interrupts : Should be single bit error interrupt.
-
-SDMMC FIFO ECC
-Required Properties:
-- compatible : Should be "altr,socfpga-s10-sdmmc-ecc"
-- reg : Address and size for ECC block registers.
-- altr,ecc-parent : phandle to parent SD/MMC node.
-- interrupts : Should be single bit error interrupt for port A
- and then single bit error interrupt for port B.
-
-Example:
-
- eccmgr {
- compatible = "altr,socfpga-s10-ecc-manager";
- altr,sysmgr-syscon = <&sysmgr>;
- #address-cells = <1>;
- #size-cells = <1>;
- interrupts = <0 15 4>;
- interrupt-controller;
- #interrupt-cells = <2>;
- ranges;
-
- sdramedac {
- compatible = "altr,sdram-edac-s10";
- interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- ocram-ecc@ff8cc000 {
- compatible = "altr,socfpga-s10-ocram-ecc";
- reg = <ff8cc000 0x100>;
- altr,ecc-parent = <&ocram>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- emac0-rx-ecc@ff8c0000 {
- compatible = "altr,socfpga-s10-eth-mac-ecc";
- reg = <0xff8c0000 0x100>;
- altr,ecc-parent = <&gmac0>;
- interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- emac0-tx-ecc@ff8c0400 {
- compatible = "altr,socfpga-s10-eth-mac-ecc";
- reg = <0xff8c0400 0x100>;
- altr,ecc-parent = <&gmac0>;
- interrupts = <5 IRQ_TYPE_LEVEL_HIGH>'
- };
-
- nand-buf-ecc@ff8c8000 {
- compatible = "altr,socfpga-s10-nand-ecc";
- reg = <0xff8c8000 0x100>;
- altr,ecc-parent = <&nand>;
- interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- nand-rd-ecc@ff8c8400 {
- compatible = "altr,socfpga-s10-nand-ecc";
- reg = <0xff8c8400 0x100>;
- altr,ecc-parent = <&nand>;
- interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- nand-wr-ecc@ff8c8800 {
- compatible = "altr,socfpga-s10-nand-ecc";
- reg = <0xff8c8800 0x100>;
- altr,ecc-parent = <&nand>;
- interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- dma-ecc@ff8c9000 {
- compatible = "altr,socfpga-s10-dma-ecc";
- reg = <0xff8c9000 0x100>;
- altr,ecc-parent = <&pdma>;
- interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
-
- usb0-ecc@ff8c4000 {
- compatible = "altr,socfpga-s10-usb-ecc";
- reg = <0xff8c4000 0x100>;
- altr,ecc-parent = <&usb0>;
- interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- sdmmc-ecc@ff8c8c00 {
- compatible = "altr,socfpga-s10-sdmmc-ecc";
- reg = <0xff8c8c00 0x100>;
- altr,ecc-parent = <&mmc>;
- interrupts = <14 IRQ_TYPE_LEVEL_HIGH>,
- <15 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml
index d14e0accbda8..c21282634780 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
@@ -2,19 +2,25 @@
# Copyright 2019 BayLibre SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/eeprom/at24.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/eeprom/at24.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I2C EEPROMs compatible with Atmel's AT24
maintainers:
- Bartosz Golaszewski <bgolaszewski@baylibre.com>
+allOf:
+ - $ref: /schemas/nvmem/nvmem.yaml
+ - $ref: /schemas/nvmem/nvmem-deprecated-cells.yaml
+
select:
properties:
compatible:
contains:
- pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$"
+ anyOf:
+ - pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$"
+ - enum: ["microchip,24aa025e48", "microchip,24aa025e64"]
required:
- compatible
@@ -110,20 +116,44 @@ properties:
- const: atmel,24c02
- items:
- enum:
+ - giantec,gt24c04a
- onnn,cat24c04
- onnn,cat24c05
+ - rohm,br24g04
- const: atmel,24c04
- items:
- - const: renesas,r1ex24016
+ - enum:
+ - belling,bl24c16a
+ - renesas,r1ex24016
- const: atmel,24c16
- items:
- const: giantec,gt24c32a
- const: atmel,24c32
- items:
- enum:
+ - belling,bl24s64
+ - onnn,n24s64b
+ - puya,p24c64f
+ - const: atmel,24c64
+ - items:
+ - enum:
+ - giantec,gt24p128e
+ - giantec,gt24p128f
- renesas,r1ex24128
- samsung,s524ad0xd1
- const: atmel,24c128
+ - items:
+ - enum:
+ - giantec,gt24c256c
+ - puya,p24c256c
+ - const: atmel,24c256
+ - items:
+ - const: microchip,24aa025e48
+ - items:
+ - const: microchip,24aa025e64
+ - items:
+ - const: st,24256e-wl
+ - pattern: '^atmel,24c(32|64)d-wl$' # Actual vendor is st
label:
description: Descriptive name of the EEPROM.
@@ -183,7 +213,7 @@ required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml
index 8b1c997caac1..e1599ce10916 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.yaml
+++ b/Documentation/devicetree/bindings/eeprom/at25.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/eeprom/at25.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/eeprom/at25.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SPI EEPROMs or FRAMs compatible with Atmel's AT25
@@ -25,14 +25,17 @@ properties:
oneOf:
- items:
- enum:
+ - anvo,anv32c81w
- anvo,anv32e61w
- atmel,at25256B
- fujitsu,mb85rs1mt
+ - fujitsu,mb85rs256
- fujitsu,mb85rs64
- microchip,at25160bn
- microchip,25lc040
- st,m95m02
- st,m95256
+ - st,m95640
- cypress,fm25
- const: atmel,at25
@@ -54,6 +57,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Total eeprom size in bytes.
+ Also used for FRAMs without device ID where the size cannot be detected.
address-width:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -104,6 +108,7 @@ required:
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: /schemas/nvmem/nvmem.yaml
- if:
properties:
compatible:
@@ -121,7 +126,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -143,4 +148,11 @@ examples:
reg = <1>;
spi-max-frequency = <40000000>;
};
+
+ fram@2 {
+ compatible = "cypress,fm25", "atmel,at25";
+ reg = <2>;
+ spi-max-frequency = <20000000>;
+ size = <2048>;
+ };
};
diff --git a/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml b/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml
index 0c2f5ddb79c5..144e86ce5c0a 100644
--- a/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml
+++ b/Documentation/devicetree/bindings/eeprom/microchip,93lc46b.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/eeprom/microchip,93lc46b.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip 93xx46 SPI compatible EEPROM family dt bindings
+title: Microchip 93xx46 SPI compatible EEPROM family
maintainers:
- Cory Tusar <cory.tusar@pid1solutions.com>
@@ -47,6 +47,7 @@ required:
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: /schemas/nvmem/nvmem.yaml
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/eeprom/st,m24lr.yaml b/Documentation/devicetree/bindings/eeprom/st,m24lr.yaml
new file mode 100644
index 000000000000..0a0820e9d11f
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/st,m24lr.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/eeprom/st,m24lr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics M24LR NFC/RFID EEPROM
+
+maintainers:
+ - Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
+
+description:
+ STMicroelectronics M24LR series are dual-interface (RF + I2C)
+ EEPROM chips. These devices support I2C-based access to both
+ memory and a system area that controls authentication and configuration.
+ They expose two I2C addresses, one for the system parameter sector and
+ one for the EEPROM.
+
+allOf:
+ - $ref: /schemas/nvmem/nvmem.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,m24lr04e-r
+ - st,m24lr16e-r
+ - st,m24lr64e-r
+
+ reg:
+ items:
+ - description: I2C address used for control/system registers
+ - description: I2C address used for EEPROM memory access
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@57 {
+ compatible = "st,m24lr04e-r";
+ reg = <0x57>, /* primary-device */
+ <0x53>; /* secondary-device */
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/embedded-controller/acer,aspire1-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/acer,aspire1-ec.yaml
new file mode 100644
index 000000000000..01ee61768527
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/acer,aspire1-ec.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/acer,aspire1-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Acer Aspire 1 Embedded Controller
+
+maintainers:
+ - Nikita Travkin <nikita@trvn.ru>
+
+description:
+ The Acer Aspire 1 laptop uses an embedded controller to control battery
+ and charging as well as to provide a set of misc features such as the
+ laptop lid status and HPD events for the USB Type-C DP alt mode.
+
+properties:
+ compatible:
+ const: acer,aspire1-ec
+
+ reg:
+ const: 0x76
+
+ interrupts:
+ maxItems: 1
+
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@76 {
+ compatible = "acer,aspire1-ec";
+ reg = <0x76>;
+
+ interrupts-extended = <&tlmm 30 IRQ_TYPE_LEVEL_LOW>;
+
+ connector {
+ compatible = "usb-c-connector";
+
+ port {
+ ec_dp_in: endpoint {
+ remote-endpoint = <&mdss_dp_out>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/embedded-controller/google,cros-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/google,cros-ec.yaml
new file mode 100644
index 000000000000..3ab5737c9a8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/google,cros-ec.yaml
@@ -0,0 +1,326 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/google,cros-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS Embedded Controller
+
+maintainers:
+ - Benson Leung <bleung@chromium.org>
+ - Guenter Roeck <groeck@chromium.org>
+
+description:
+ Google's ChromeOS EC is a microcontroller which talks to the AP and
+ implements various functions such as keyboard and battery charging.
+ The EC can be connected through various interfaces (I2C, SPI, and others)
+ and the compatible string specifies which interface is being used.
+
+properties:
+ compatible:
+ oneOf:
+ - description:
+ For implementations of the EC connected through I2C.
+ const: google,cros-ec-i2c
+ - description:
+ For implementations of the EC connected through SPI.
+ const: google,cros-ec-spi
+ - description:
+ For implementations of the FPMCU connected through SPI.
+ items:
+ - const: google,cros-ec-fp
+ - const: google,cros-ec-spi
+ - description:
+ For implementations of the EC connected through RPMSG.
+ const: google,cros-ec-rpmsg
+ - description:
+ For implementations of the EC connected through UART.
+ const: google,cros-ec-uart
+
+ controller-data: true
+
+ google,cros-ec-spi-pre-delay:
+ description:
+ This property specifies the delay in usecs between the
+ assertion of the CS and the first clock pulse.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ google,cros-ec-spi-msg-delay:
+ description:
+ This property specifies the delay in usecs between messages.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ google,has-vbc-nvram:
+ description:
+ Some implementations of the EC include a small nvram space used to
+ store verified boot context data. This boolean flag is used to specify
+ whether this nvram is present or not.
+ type: boolean
+
+ mediatek,rpmsg-name:
+ description:
+ Must be defined if the cros-ec is a rpmsg device for a Mediatek
+ ARM Cortex M4 Co-processor. Contains the name of the rpmsg
+ device. Used to match the subnode to the rpmsg device announced by
+ the SCP.
+ $ref: /schemas/types.yaml#/definitions/string
+
+ spi-max-frequency: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ boot0-gpios:
+ maxItems: 1
+ description: Assert for bootloader mode.
+
+ vdd-supply: true
+
+ wakeup-source:
+ description: Button can wake-up the system.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ typec:
+ $ref: /schemas/chrome/google,cros-ec-typec.yaml#
+
+ ec-pwm:
+ $ref: /schemas/pwm/google,cros-ec-pwm.yaml#
+ deprecated: true
+
+ pwm:
+ $ref: /schemas/pwm/google,cros-ec-pwm.yaml#
+
+ keyboard-controller:
+ $ref: /schemas/input/google,cros-ec-keyb.yaml#
+
+ proximity:
+ $ref: /schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
+
+ codecs:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 1
+
+ patternProperties:
+ "^ec-codec@[a-f0-9]+$":
+ type: object
+ $ref: /schemas/sound/google,cros-ec-codec.yaml#
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ cbas:
+ type: object
+
+ description:
+ This device is used to signal when a detachable base is attached
+ to a Chrome OS tablet. This device cannot be detected at runtime.
+
+ properties:
+ compatible:
+ const: google,cros-cbas
+
+ required:
+ - compatible
+
+ additionalProperties: false
+
+patternProperties:
+ "^i2c-tunnel[0-9]*$":
+ type: object
+ $ref: /schemas/i2c/google,cros-ec-i2c-tunnel.yaml#
+
+ "^regulator@[0-9]+$":
+ type: object
+ $ref: /schemas/regulator/google,cros-ec-regulator.yaml#
+
+ "^extcon[0-9]*$":
+ type: object
+ $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
+
+required:
+ - compatible
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: google,cros-ec-spi
+ then:
+ properties:
+ controller-data: false
+ google,cros-ec-spi-pre-delay: false
+ google,cros-ec-spi-msg-delay: false
+ spi-max-frequency: false
+ else:
+ $ref: /schemas/spi/spi-peripheral-props.yaml
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: google,cros-ec-rpmsg
+ then:
+ properties:
+ mediatek,rpmsg-name: false
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - google,cros-ec-rpmsg
+ - google,cros-ec-uart
+ then:
+ required:
+ - reg
+ - interrupts
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,cros-ec-fp
+ then:
+ properties:
+ '#address-cells': false
+ '#size-cells': false
+ typec: false
+ ec-pwm: false
+ kbd-led-backlight: false
+ keyboard-controller: false
+ proximity: false
+ codecs: false
+ cbas: false
+
+ patternProperties:
+ "^i2c-tunnel[0-9]*$": false
+ "^regulator@[0-9]+$": false
+ "^extcon[0-9]*$": false
+
+ # Using additionalProperties: false here and
+ # listing true properties doesn't work
+
+ required:
+ - reset-gpios
+ - boot0-gpios
+ - vdd-supply
+ else:
+ properties:
+ reset-gpios: false
+ boot0-gpios: false
+ vdd-supply: false
+
+additionalProperties: false
+
+examples:
+ # Example for I2C
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cros-ec@1e {
+ compatible = "google,cros-ec-i2c";
+ reg = <0x1e>;
+ interrupts = <6 0>;
+ interrupt-parent = <&gpio0>;
+ };
+ };
+
+ # Example for SPI
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cros-ec@0 {
+ compatible = "google,cros-ec-spi";
+ reg = <0x0>;
+ google,cros-ec-spi-msg-delay = <30>;
+ google,cros-ec-spi-pre-delay = <10>;
+ interrupts = <99 0>;
+ interrupt-parent = <&gpio7>;
+ spi-max-frequency = <5000000>;
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ proximity {
+ compatible = "google,cros-ec-mkbp-proximity";
+ };
+
+ cbas {
+ compatible = "google,cros-cbas";
+ };
+ };
+ };
+
+ # Example for RPMSG
+ - |
+ scp0 {
+ cros-ec {
+ compatible = "google,cros-ec-rpmsg";
+ };
+ };
+
+ # Example for FPMCU
+ - |
+ spi {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ ec@0 {
+ compatible = "google,cros-ec-fp", "google,cros-ec-spi";
+ reg = <0x0>;
+ interrupt-parent = <&gpio_controller>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <3000000>;
+ reset-gpios = <&gpio_controller 5 GPIO_ACTIVE_LOW>;
+ boot0-gpios = <&gpio_controller 10 GPIO_ACTIVE_HIGH>;
+ vdd-supply = <&pp3300_fp_mcu>;
+ };
+ };
+
+ # Example for UART
+ - |
+ serial {
+ cros-ec {
+ compatible = "google,cros-ec-uart";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/embedded-controller/gw,gsc.yaml b/Documentation/devicetree/bindings/embedded-controller/gw,gsc.yaml
new file mode 100644
index 000000000000..82d4b2dadbae
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/gw,gsc.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/gw,gsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gateworks System Controller
+
+description: |
+ The Gateworks System Controller (GSC) is a device present across various
+ Gateworks product families that provides a set of system related features
+ such as the following (refer to the board hardware user manuals to see what
+ features are present)
+ - Watchdog Timer
+ - GPIO
+ - Pushbutton controller
+ - Hardware monitor with ADC's for temperature and voltage rails and
+ fan controller
+
+maintainers:
+ - Tim Harvey <tharvey@gateworks.com>
+
+properties:
+ $nodename:
+ pattern: "gsc@[0-9a-f]{1,2}"
+ compatible:
+ const: gw,gsc
+
+ reg:
+ description: I2C device address
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ adc:
+ type: object
+ additionalProperties: false
+ description: Optional hardware monitoring module
+
+ properties:
+ compatible:
+ const: gw,gsc-adc
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^channel@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+ description: |
+ Properties for a single ADC which can report cooked values
+ (i.e. temperature sensor based on thermister), raw values
+ (i.e. voltage rail with a pre-scaling resistor divider).
+
+ properties:
+ reg:
+ description: Register of the ADC
+ maxItems: 1
+
+ label:
+ description: Name of the ADC input
+
+ gw,mode:
+ description: |
+ conversion mode:
+ 0 - temperature, in C*10
+ 1 - pre-scaled 24-bit voltage value
+ 2 - scaled voltage based on an optional resistor divider
+ and optional offset
+ 3 - pre-scaled 16-bit voltage value
+ 4 - fan tach input to report RPM's
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4]
+
+ gw,voltage-divider-ohms:
+ description: Values of resistors for divider on raw ADC input
+ maxItems: 2
+ items:
+ minimum: 1000
+ maximum: 1000000
+
+ gw,voltage-offset-microvolt:
+ description: |
+ A positive voltage offset to apply to a raw ADC
+ (i.e. to compensate for a diode drop).
+ minimum: 0
+ maximum: 1000000
+
+ required:
+ - gw,mode
+ - reg
+ - label
+
+ required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+patternProperties:
+ "^fan-controller@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+ description: Optional fan controller
+
+ properties:
+ compatible:
+ const: gw,gsc-fan
+
+ reg:
+ description: The fan controller base address
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 { /* A0: Board Temperature */
+ reg = <0x00>;
+ label = "temp";
+ gw,mode = <0>;
+ };
+
+ channel@2 { /* A1: Input Voltage (raw ADC) */
+ reg = <0x02>;
+ label = "vdd_vin";
+ gw,mode = <1>;
+ gw,voltage-divider-ohms = <22100 1000>;
+ gw,voltage-offset-microvolt = <800000>;
+ };
+
+ channel@b { /* A2: Battery voltage */
+ reg = <0x0b>;
+ label = "vdd_bat";
+ gw,mode = <1>;
+ };
+ };
+
+ fan-controller@2c {
+ compatible = "gw,gsc-fan";
+ reg = <0x2c>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/embedded-controller/huawei,gaokun3-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/huawei,gaokun3-ec.yaml
new file mode 100644
index 000000000000..cd9e65b6c2ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/huawei,gaokun3-ec.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/huawei,gaokun3-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Huawei Matebook E Go Embedded Controller
+
+maintainers:
+ - Pengyu Luo <mitltlatltl@gmail.com>
+
+description:
+ Different from other Qualcomm Snapdragon sc8180x and sc8280xp-based
+ machines, the Huawei Matebook E Go tablets use embedded controllers
+ while others use a system called PMIC GLink which handles battery,
+ UCSI, USB Type-C DP Alt Mode. In addition, Huawei's implementation
+ also handles additional features, such as charging thresholds, FN
+ lock, smart charging, tablet lid status, thermal sensors, and more.
+
+properties:
+ compatible:
+ enum:
+ - huawei,gaokun3-ec
+
+ reg:
+ const: 0x38
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ '^connector@[01]$':
+ $ref: /schemas/connector/usb-connector.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@38 {
+ compatible = "huawei,gaokun3-ec";
+ reg = <0x38>;
+
+ interrupts-extended = <&tlmm 107 IRQ_TYPE_LEVEL_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ ucsi0_ss_in: endpoint {
+ remote-endpoint = <&usb_0_qmpphy_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ucsi0_sbu: endpoint {
+ remote-endpoint = <&usb0_sbu_mux>;
+ };
+ };
+ };
+ };
+
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ ucsi1_ss_in: endpoint {
+ remote-endpoint = <&usb_1_qmpphy_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ucsi1_sbu: endpoint {
+ remote-endpoint = <&usb1_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml b/Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml
index eb3b43547cb6..a77e67f6cb82 100644
--- a/Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml
+++ b/Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/mfd/kontron,sl28cpld.yaml#
+$id: http://devicetree.org/schemas/embedded-controller/kontron,sl28cpld.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Kontron's sl28cpld board management controller
@@ -16,7 +16,12 @@ description: |
properties:
compatible:
- const: kontron,sl28cpld
+ oneOf:
+ - items:
+ - enum:
+ - kontron,sa67mcu
+ - const: kontron,sl28cpld
+ - const: kontron,sl28cpld
reg:
description:
@@ -39,19 +44,19 @@ properties:
patternProperties:
"^gpio(@[0-9a-f]+)?$":
- $ref: ../gpio/kontron,sl28cpld-gpio.yaml
+ $ref: /schemas/gpio/kontron,sl28cpld-gpio.yaml
"^hwmon(@[0-9a-f]+)?$":
- $ref: ../hwmon/kontron,sl28cpld-hwmon.yaml
+ $ref: /schemas/hwmon/kontron,sl28cpld-hwmon.yaml
"^interrupt-controller(@[0-9a-f]+)?$":
- $ref: ../interrupt-controller/kontron,sl28cpld-intc.yaml
+ $ref: /schemas/interrupt-controller/kontron,sl28cpld-intc.yaml
"^pwm(@[0-9a-f]+)?$":
- $ref: ../pwm/kontron,sl28cpld-pwm.yaml
+ $ref: /schemas/pwm/kontron,sl28cpld-pwm.yaml
"^watchdog(@[0-9a-f]+)?$":
- $ref: ../watchdog/kontron,sl28cpld-wdt.yaml
+ $ref: /schemas/watchdog/kontron,sl28cpld-wdt.yaml
required:
- "#address-cells"
diff --git a/Documentation/devicetree/bindings/embedded-controller/lenovo,thinkpad-t14s-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/lenovo,thinkpad-t14s-ec.yaml
new file mode 100644
index 000000000000..c87ccb5b3086
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/lenovo,thinkpad-t14s-ec.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/lenovo,thinkpad-t14s-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lenovo Thinkpad T14s Embedded Controller
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description:
+ The Qualcomm Snapdragon-based Lenovo Thinkpad T14s has an Embedded Controller
+ (EC) which handles things such as keyboard backlight, LEDs or non-standard
+ keys.
+
+properties:
+ compatible:
+ const: lenovo,thinkpad-t14s-ec
+
+ reg:
+ const: 0x28
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |+
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@28 {
+ compatible = "lenovo,thinkpad-t14s-ec";
+ reg = <0x28>;
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/embedded-controller/lenovo,yoga-c630-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/lenovo,yoga-c630-ec.yaml
new file mode 100644
index 000000000000..a029b38e8dc0
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/lenovo,yoga-c630-ec.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/lenovo,yoga-c630-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lenovo Yoga C630 Embedded Controller.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ The Qualcomm Snapdragon-based Lenovo Yoga C630 has an Embedded Controller
+ (EC) which handles things such as battery and USB Type-C. This binding
+ describes the interface, on an I2C bus, to this EC.
+
+properties:
+ compatible:
+ const: lenovo,yoga-c630-ec
+
+ reg:
+ const: 0x70
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ '^connector@[01]$':
+ $ref: /schemas/connector/usb-connector.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |+
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c1 {
+ clock-frequency = <400000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@70 {
+ compatible = "lenovo,yoga-c630-ec";
+ reg = <0x70>;
+
+ interrupts-extended = <&tlmm 20 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "source";
+ data-role = "host";
+ };
+
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ power-role = "source";
+ data-role = "host";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/embedded-controller/microsoft,surface-sam.yaml b/Documentation/devicetree/bindings/embedded-controller/microsoft,surface-sam.yaml
new file mode 100644
index 000000000000..9202cfca0b35
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/microsoft,surface-sam.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/microsoft,surface-sam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Surface System Aggregator Module (SAM, SSAM)
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Surface devices use a standardized embedded controller to let the
+ operating system interface with various hardware functions. The
+ specific functionalities are modeled as subdevices and matched on
+ five levels: domain, category, target, instance and function.
+
+properties:
+ compatible:
+ const: microsoft,surface-sam
+
+ interrupts:
+ maxItems: 1
+
+ current-speed: true
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ uart {
+ embedded-controller {
+ compatible = "microsoft,surface-sam";
+
+ interrupts-extended = <&tlmm 91 IRQ_TYPE_EDGE_RISING>;
+
+ pinctrl-0 = <&ssam_state>;
+ pinctrl-names = "default";
+
+ current-speed = <4000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/embedded-controller/traverse,ten64-controller.yaml b/Documentation/devicetree/bindings/embedded-controller/traverse,ten64-controller.yaml
new file mode 100644
index 000000000000..08d02c4df873
--- /dev/null
+++ b/Documentation/devicetree/bindings/embedded-controller/traverse,ten64-controller.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/embedded-controller/traverse,ten64-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Traverse Ten64 board microcontroller
+
+maintainers:
+ - Mathew McBride <matt@traverse.com.au>
+
+description: |
+ The board microcontroller on the Ten64 board family is responsible for
+ management of power sources on the board, as well as signalling the SoC
+ to power on and reset.
+
+properties:
+ compatible:
+ const: traverse,ten64-controller
+
+ reg:
+ const: 0x7e
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ board-controller@7e {
+ compatible = "traverse,ten64-controller";
+ reg = <0x7e>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml
index 8e1a8b19d429..b04f3cc4312c 100644
--- a/Documentation/devicetree/bindings/example-schema.yaml
+++ b/Documentation/devicetree/bindings/example-schema.yaml
@@ -11,7 +11,7 @@ $id: http://devicetree.org/schemas/example-schema.yaml#
# $schema is the meta-schema this schema should be validated with.
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: An example schema annotated with jsonschema details
+title: An Example Device
maintainers:
- Rob Herring <robh@kernel.org>
@@ -52,8 +52,7 @@ properties:
- vendor,soc4-ip
- vendor,soc3-ip
- vendor,soc2-ip
- - enum:
- - vendor,soc1-ip
+ - const: vendor,soc1-ip
# additionalItems being false is implied
# minItems/maxItems equal to 2 is implied
- items:
@@ -85,6 +84,9 @@ properties:
discouraged.
clock-names:
+ # For single-entry lists in clocks, resets etc., the xxx-names often do not
+ # bring any value, especially if they copy the IP block name. In such case
+ # just skip the xxx-names.
items:
- const: bus
@@ -176,6 +178,10 @@ properties:
description: Child nodes are just another property from a json-schema
perspective.
type: object # DT nodes are json objects
+ # Child nodes also need additionalProperties or unevaluatedProperties, where
+ # 'false' should be used in most cases (see 'child-node-with-own-schema'
+ # below).
+ additionalProperties: false
properties:
vendor,a-child-node-property:
description: Child node properties have all the same schema
@@ -185,6 +191,17 @@ properties:
required:
- vendor,a-child-node-property
+ child-node-with-own-schema:
+ description: |
+ Child node with their own compatible and device schema which ends in
+ 'additionalProperties: false' or 'unevaluatedProperties: false' can
+ mention only the compatible and use here 'additionalProperties: true'.
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ const: vendor,sub-device
+
# Describe the relationship between different properties
dependencies:
# 'vendor,bool-property' is only allowed when 'vendor,string-array-property'
@@ -206,7 +223,7 @@ required:
#
# For multiple 'if' schema, group them under an 'allOf'.
#
-# If the conditionals become too unweldy, then it may be better to just split
+# If the conditionals become too unwieldy, then it may be better to just split
# the binding into separate schema documents.
allOf:
- if:
@@ -258,4 +275,5 @@ examples:
reg-names = "core", "aux";
interrupts = <10>;
interrupt-controller;
+ #interrupt-cells = <2>;
};
diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
index d5cfa32ea52d..072b3c0c5fd0 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
@@ -37,6 +37,11 @@ properties:
GPIO pin (output) used to control VBUS. If skipped, no such control
takes place.
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the usb controller for the dual role switch.
+
required:
- compatible
- interrupts
@@ -58,5 +63,11 @@ examples:
interrupt-parent = <&msmgpio>;
interrupts = <78 IRQ_TYPE_LEVEL_HIGH>;
vbus-gpios = <&msmgpio 148 GPIO_ACTIVE_HIGH>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/extcon/extcon-rt8973a.txt b/Documentation/devicetree/bindings/extcon/extcon-rt8973a.txt
deleted file mode 100644
index cfcf455ad4de..000000000000
--- a/Documentation/devicetree/bindings/extcon/extcon-rt8973a.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-
-* Richtek RT8973A - Micro USB Switch device
-
-The Richtek RT8973A is Micro USB Switch with OVP and I2C interface. The RT8973A
-is a USB port accessory detector and switch that is optimized to protect low
-voltage system from abnormal high input voltage (up to 28V) and supports high
-speed USB operation. Also, RT8973A support 'auto-configuration' mode.
-If auto-configuration mode is enabled, RT8973A would control internal h/w patch
-for USB D-/D+ switching.
-
-Required properties:
-- compatible: Should be "richtek,rt8973a-muic"
-- reg: Specifies the I2C slave address of the MUIC block. It should be 0x14
-- interrupts: Interrupt specifiers for detection interrupt sources.
-
-Example:
-
- rt8973a@14 {
- compatible = "richtek,rt8973a-muic";
- interrupt-parent = <&gpx1>;
- interrupts = <5 0>;
- reg = <0x14>;
- };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
deleted file mode 100644
index dfc14f71e81f..000000000000
--- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-USB GPIO Extcon device
-
-This is a virtual device used to generate USB cable states from the USB ID pin
-connected to a GPIO pin.
-
-Required properties:
-- compatible: Should be "linux,extcon-usb-gpio"
-
-Either one of id-gpio or vbus-gpio must be present. Both can be present as well.
-- id-gpio: gpio for USB ID pin. See gpio binding.
-- vbus-gpio: gpio for USB VBUS pin.
-
-Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
- extcon_usb1 {
- compatible = "linux,extcon-usb-gpio";
- id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
- }
-
- &omap_dwc3_1 {
- extcon = <&extcon_usb1>;
- };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
index 2d82b44268db..e00c8072bae9 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
@@ -34,12 +34,13 @@ additionalProperties: false
examples:
- |
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
cros-ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
+ interrupts = <44 0>;
usbc_extcon0: extcon0 {
compatible = "google,extcon-usbc-cros-ec";
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml
index 71a9f2e5d0dc..126107dd57b1 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml
@@ -30,7 +30,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
tusb320@61 {
diff --git a/Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml b/Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml
new file mode 100644
index 000000000000..8f29d333602b
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/linux,extcon-usb-gpio.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/linux,extcon-usb-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB GPIO Extcon device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ This is a virtual device used to generate USB cable states from the USB ID pin
+ connected to a GPIO pin.
+
+properties:
+ compatible:
+ const: linux,extcon-usb-gpio
+
+ id-gpios:
+ description: gpio for USB ID pin. See gpio binding.
+ vbus-gpios:
+ description: gpio for USB VBUS pin.
+
+required:
+ - compatible
+
+anyOf:
+ - required:
+ - id-gpios
+ - required:
+ - vbus-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpios = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/extcon/maxim,max14526.yaml b/Documentation/devicetree/bindings/extcon/maxim,max14526.yaml
new file mode 100644
index 000000000000..7eb5918df1c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/maxim,max14526.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/maxim,max14526.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX14526 MicroUSB Integrated Circuit (MUIC)
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ const: maxim,max14526
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - connector
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ muic@44 {
+ compatible = "maxim,max14526";
+ reg = <0x44>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <72 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ };
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ muic_to_charger: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&charger_input>;
+ };
+
+ muic_to_usb: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usb_input>;
+ };
+
+ muic_to_mhl: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&mhl_input>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml
index 128960545640..55800fb0221d 100644
--- a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml
+++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml
@@ -23,6 +23,7 @@ properties:
connector:
$ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
ports:
$ref: /schemas/graph.yaml#/properties/ports
diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
index 6a9c96f0352a..6b80518cbf62 100644
--- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
+++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. PM8941 USB ID Extcon device
maintainers:
- - Guru Das Srinagesh <gurus@codeaurora.org>
+ - Guru Das Srinagesh <quic_gurus@quicinc.com>
description: |
Some Qualcomm PMICs have a "misc" module that can be used to detect when
@@ -27,10 +27,14 @@ properties:
interrupt-names:
minItems: 1
- items:
- - const: usb_id
- - const: usb_vbus
-
+ anyOf:
+ - items:
+ - const: usb_id
+ - const: usb_vbus
+ - items:
+ - const: usb_id
+ - items:
+ - const: usb_vbus
required:
- compatible
- reg
@@ -49,7 +53,7 @@ examples:
interrupt-controller;
#interrupt-cells = <4>;
- usb_id: misc@900 {
+ usb_id: usb-detect@900 {
compatible = "qcom,pm8941-misc";
reg = <0x900>;
interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>;
diff --git a/Documentation/devicetree/bindings/extcon/richtek,rt8973a-muic.yaml b/Documentation/devicetree/bindings/extcon/richtek,rt8973a-muic.yaml
new file mode 100644
index 000000000000..f9e0d816c025
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/richtek,rt8973a-muic.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/richtek,rt8973a-muic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT8973A MUIC
+
+maintainers:
+ - Chanwoo Choi <cw00.choi@samsung.com>
+
+description:
+ The Richtek RT8973A is Micro USB Switch with OVP and I2C interface. The RT8973A
+ is a USB port accessory detector and switch that is optimized to protect low
+ voltage system from abnormal high input voltage (up to 28V) and supports high
+ speed USB operation. Also, RT8973A support 'auto-configuration' mode.
+ If auto-configuration mode is enabled, RT8973A would control internal h/w patch
+ for USB D-/D+ switching.
+
+properties:
+ compatible:
+ const: richtek,rt8973a-muic
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ usb-switch@14 {
+ compatible = "richtek,rt8973a-muic";
+ reg = <0x14>;
+ interrupt-parent = <&gpio>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
index 7a224b2f0977..7ef2d9bef72d 100644
--- a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
+++ b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml
@@ -27,6 +27,10 @@ properties:
description: I2C slave address of the device. Usually 0x25 for SM5502
and SM5703, 0x14 for SM5504.
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
index efdf59abb2e1..351b202d0e10 100644
--- a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
+++ b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
@@ -23,7 +23,7 @@ properties:
headphone detect mode to HPDETL, ARIZONA_ACCDET_MODE_HPR/2 sets it
to HPDETR. If this node is not included or if the value is unknown,
then headphone detection mode is set to HPDETL.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 2
@@ -51,7 +51,7 @@ properties:
description:
Additional software microphone detection debounce specified in
milliseconds.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
wlf,micd-pol-gpio:
description:
@@ -63,7 +63,7 @@ properties:
description:
Time allowed for MICBIAS to startup prior to performing microphone
detection, specified as per the ARIZONA_MICD_TIME_XXX defines.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 12
@@ -71,7 +71,7 @@ properties:
description:
Delay between successive microphone detection measurements, specified
as per the ARIZONA_MICD_TIME_XXX defines.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 12
@@ -79,7 +79,7 @@ properties:
description:
Microphone detection hardware debounces specified as the number of
measurements to take.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 4]
wlf,micd-timeout-ms:
@@ -97,7 +97,7 @@ properties:
CTIA / OMTP headsets), the field can be of variable length but
should always be a multiple of 3 cells long, each three cell group
represents one polarity configuration.
- $ref: "/schemas/types.yaml#/definitions/uint32-matrix"
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description:
@@ -119,7 +119,7 @@ properties:
description:
Settings for the general purpose switch, set as one of the
ARIZONA_GPSW_XXX defines.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
diff --git a/Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml b/Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml
new file mode 100644
index 000000000000..8f50e698760e
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/amlogic,meson-gxbb-sm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Secure Monitor (SM)
+
+description:
+ In the Amlogic SoCs the Secure Monitor code is used to provide access to the
+ NVMEM, enable JTAG, set USB boot, etc...
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-gxbb-sm
+ - items:
+ - const: amlogic,meson-gx-sm
+ - const: amlogic,meson-gxbb-sm
+
+ power-controller:
+ type: object
+ $ref: /schemas/power/amlogic,meson-sec-pwrc.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ firmware {
+ secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index 1c0388da6721..be817fd9cc34 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: System Control and Management Interface (SCMI) Message Protocol bindings
+title: System Control and Management Interface (SCMI) Message Protocol
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
@@ -22,9 +22,12 @@ description: |
[0] https://developer.arm.com/documentation/den0056/latest
+anyOf:
+ - $ref: /schemas/firmware/nxp,imx95-scmi.yaml
+
properties:
$nodename:
- const: scmi
+ pattern: '^scmi(-[0-9]+)?$'
compatible:
oneOf:
@@ -34,6 +37,13 @@ properties:
- description: SCMI compliant firmware with ARM SMC/HVC transport
items:
- const: arm,scmi-smc
+ - description: SCMI compliant firmware with ARM SMC/HVC transport
+ with shmem address(4KB-page, offset) as parameters
+ items:
+ - const: arm,scmi-smc-param
+ - description: SCMI compliant firmware with Qualcomm SMC/HVC transport
+ items:
+ - const: qcom,scmi-smc
- description: SCMI compliant firmware with SCMI Virtio transport.
The virtio transport only supports a single device.
items:
@@ -56,17 +66,42 @@ properties:
description:
Specifies the mailboxes used to communicate with SCMI compliant
firmware.
- items:
- - const: tx
- - const: rx
+ oneOf:
+ - items:
+ - const: tx
+ - const: rx
+ minItems: 1
+ - items:
+ - const: tx
+ - const: tx_reply
+ - const: rx
+ - const: rx_reply
+ minItems: 2
mboxes:
description:
List of phandle and mailbox channel specifiers. It should contain
- exactly one or two mailboxes, one for transmitting messages("tx")
- and another optional for receiving the notifications("rx") if supported.
+ exactly one, two, three or four mailboxes; the first one or two for
+ transmitting messages ("tx") and another optional ("rx") for receiving
+ notifications and delayed responses, if supported by the platform.
+ The optional ("rx_reply") is for notifications completion interrupt,
+ if supported by the platform.
+ The number of mailboxes needed for transmitting messages depends on the
+ type of channels exposed by the specific underlying mailbox controller;
+ one single channel descriptor is enough if such channel is bidirectional,
+ while two channel descriptors are needed to represent the SCMI ("tx")
+ channel if the underlying mailbox channels are of unidirectional type.
+ The effective combination in numbers of mboxes and shmem descriptors let
+ the SCMI subsystem determine unambiguosly which type of SCMI channels are
+ made available by the underlying mailbox controller and how to use them.
+ 1 mbox / 1 shmem => SCMI TX over 1 mailbox bidirectional channel
+ 2 mbox / 2 shmem => SCMI TX and RX over 2 mailbox bidirectional channels
+ 2 mbox / 1 shmem => SCMI TX over 2 mailbox unidirectional channels
+ 3 mbox / 2 shmem => SCMI TX and RX over 3 mailbox unidirectional channels
+ 4 mbox / 2 shmem => SCMI TX and RX over 4 mailbox unidirectional channels
+ Any other combination of mboxes and shmem is invalid.
minItems: 1
- maxItems: 2
+ maxItems: 4
shmem:
description:
@@ -89,6 +124,28 @@ properties:
atomic mode of operation, even if requested.
default: 0
+ arm,max-rx-timeout-ms:
+ description:
+ An optional time value, expressed in milliseconds, representing the
+ transport maximum timeout value for the receive channel. The value should
+ be a non-zero value if set.
+ minimum: 1
+
+ arm,max-msg-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ An optional value, expressed in bytes, representing the maximum size
+ allowed for the payload of messages transmitted on this transport.
+
+ arm,max-msg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ An optional value representing the maximum number of concurrent in-flight
+ messages allowed by this transport; this number represents the maximum
+ number of concurrently outstanding messages that the server can handle on
+ this platform. If set, the value should be non-zero.
+ minimum: 1
+
arm,smc-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -100,7 +157,9 @@ properties:
Channel specifier required when using OP-TEE transport.
protocol@11:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x11
@@ -111,8 +170,18 @@ properties:
required:
- '#power-domain-cells'
+ protocol@12:
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x12
+
protocol@13:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x13
@@ -120,11 +189,20 @@ properties:
'#clock-cells':
const: 1
- required:
- - '#clock-cells'
+ '#power-domain-cells':
+ const: 1
+
+ oneOf:
+ - required:
+ - '#clock-cells'
+
+ - required:
+ - '#power-domain-cells'
protocol@14:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x14
@@ -136,7 +214,9 @@ properties:
- '#clock-cells'
protocol@15:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x15
@@ -148,7 +228,9 @@ properties:
- '#thermal-sensor-cells'
protocol@16:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x16
@@ -160,20 +242,31 @@ properties:
- '#reset-cells'
protocol@17:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x17
regulators:
type: object
+ additionalProperties: false
description:
The list of all regulators provided by this SCMI controller.
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
patternProperties:
- '^regulators@[0-9a-f]+$':
+ '^regulator@[0-9a-f]+$':
type: object
- $ref: "../regulator/regulator.yaml#"
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -184,15 +277,50 @@ properties:
- reg
protocol@18:
- type: object
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
properties:
reg:
const: 0x18
-additionalProperties: false
+ protocol@19:
+ type: object
+ allOf:
+ - $ref: '#/$defs/protocol-node'
+ - anyOf:
+ - $ref: /schemas/pinctrl/pinctrl.yaml
+ - $ref: /schemas/firmware/nxp,imx95-scmi-pinctrl.yaml
+
+ unevaluatedProperties: false
-patternProperties:
- '^protocol@[0-9a-f]+$':
+ properties:
+ reg:
+ const: 0x19
+
+ patternProperties:
+ '-pins$':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ unevaluatedProperties: false
+
+ description:
+ A pin multiplexing sub-node describes how to configure a
+ set of pins in some desired function.
+ A single sub-node may define several pin configurations.
+ This sub-node is using the default pinctrl bindings to configure
+ pin multiplexing and using SCMI protocol to apply a specified
+ configuration.
+
+ required:
+ - reg
+
+unevaluatedProperties: false
+
+$defs:
+ protocol-node:
type: object
description:
Each sub-node represents a protocol supported. If the platform
@@ -205,13 +333,20 @@ patternProperties:
maxItems: 1
mbox-names:
- items:
- - const: tx
- - const: rx
+ oneOf:
+ - items:
+ - const: tx
+ - const: rx
+ minItems: 1
+ - items:
+ - const: tx
+ - const: tx_reply
+ - const: rx
+ minItems: 2
mboxes:
minItems: 1
- maxItems: 2
+ maxItems: 3
shmem:
minItems: 1
@@ -248,7 +383,10 @@ else:
properties:
compatible:
contains:
- const: arm,scmi-smc
+ enum:
+ - arm,scmi-smc
+ - arm,scmi-smc-param
+ - qcom,scmi-smc
then:
required:
- arm,smc-id
@@ -287,7 +425,7 @@ examples:
scmi_dvfs: protocol@13 {
reg = <0x13>;
- #clock-cells = <1>;
+ #power-domain-cells = <1>;
mboxes = <&mhuB 1 0>,
<&mhuB 1 1>;
@@ -333,6 +471,25 @@ examples:
scmi_powercap: protocol@18 {
reg = <0x18>;
};
+
+ scmi_pinctrl: protocol@19 {
+ reg = <0x19>;
+
+ i2c2-pins {
+ groups = "g_i2c2_a", "g_i2c2_b";
+ function = "f_i2c2";
+ };
+
+ mdio-pins {
+ groups = "g_avb_mdio";
+ drive-strength = <24>;
+ };
+
+ keys_pins: keys-pins {
+ pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";
+ bias-pull-up;
+ };
+ };
};
};
@@ -400,7 +557,7 @@ examples:
reg = <0x13>;
linaro,optee-channel-id = <1>;
shmem = <&cpu_optee_lpri0>;
- #clock-cells = <1>;
+ #power-domain-cells = <1>;
};
scmi_clk0: protocol@14 {
diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
index 1f9322925e7c..241317239ffc 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: System Control and Power Interface (SCPI) Message Protocol bindings
+title: System Control and Power Interface (SCPI) Message Protocol
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
diff --git a/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml b/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml
new file mode 100644
index 000000000000..684b15ba9ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/brcm,kona-smc.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/brcm,kona-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family Secure Monitor bounce buffer
+
+description:
+ A bounce buffer used for non-secure to secure communications.
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm11351-smc
+ - brcm,bcm21664-smc
+ - brcm,bcm23550-smc
+ - const: brcm,kona-smc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ smc@3404c000 {
+ compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
+ reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */
+ };
+...
diff --git a/Documentation/devicetree/bindings/firmware/cznic,turris-omnia-mcu.yaml b/Documentation/devicetree/bindings/firmware/cznic,turris-omnia-mcu.yaml
new file mode 100644
index 000000000000..af9249695ef5
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/cznic,turris-omnia-mcu.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/cznic,turris-omnia-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CZ.NIC's Turris Omnia MCU
+
+maintainers:
+ - Marek Behún <kabel@kernel.org>
+
+description:
+ The MCU on Turris Omnia acts as a system controller providing additional
+ GPIOs, interrupts, watchdog, system power off and wakeup configuration.
+
+properties:
+ compatible:
+ const: cznic,turris-omnia-mcu
+
+ reg:
+ description: MCU I2C slave address
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description: |
+ The first cell specifies the interrupt number (0 to 63), the second cell
+ specifies interrupt type (which can be one of IRQ_TYPE_EDGE_RISING,
+ IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_BOTH).
+ The interrupt numbers correspond sequentially to GPIO numbers, taking the
+ GPIO banks into account:
+ IRQ number GPIO bank GPIO pin within bank
+ 0 - 15 0 0 - 15
+ 16 - 47 1 0 - 31
+ 48 - 63 2 0 - 15
+ There are several exceptions:
+ IRQ number meaning
+ 11 LED panel brightness changed by button press
+ 13 TRNG entropy ready
+ 14 ECDSA message signature computation done
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 3
+ description:
+ The first cell is bank number (0, 1 or 2), the second cell is pin number
+ within the bank (0 to 15 for banks 0 and 2, 0 to 31 for bank 1), and the
+ third cell specifies consumer flags.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ system-controller@2a {
+ compatible = "cznic,turris-omnia-mcu";
+ reg = <0x2a>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <11 IRQ_TYPE_NONE>;
+
+ gpio-controller;
+ #gpio-cells = <3>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/firmware/fsl,scu.yaml b/Documentation/devicetree/bindings/firmware/fsl,scu.yaml
index b40b0ef56978..f9ba18f06369 100644
--- a/Documentation/devicetree/bindings/firmware/fsl,scu.yaml
+++ b/Documentation/devicetree/bindings/firmware/fsl,scu.yaml
@@ -30,6 +30,11 @@ properties:
Clock controller node that provides the clocks controlled by the SCU
$ref: /schemas/clock/fsl,scu-clk.yaml
+ gpio:
+ description:
+ Control the GPIO PINs on SCU domain over the firmware APIs
+ $ref: /schemas/gpio/fsl,imx8qxp-sc-gpio.yaml
+
ocotp:
description:
OCOTP controller node provided by the SCU
@@ -40,6 +45,18 @@ properties:
Keys provided by the SCU
$ref: /schemas/input/fsl,scu-key.yaml
+ reset-controller:
+ type: object
+ properties:
+ compatible:
+ const: fsl,imx-scu-reset
+ '#reset-cells':
+ const: 1
+ required:
+ - compatible
+ - '#reset-cells'
+ additionalProperties: false
+
mboxes:
description:
A list of phandles of TX MU channels followed by a list of phandles of
diff --git a/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml
new file mode 100644
index 000000000000..d3bca6088d12
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2024 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/google,gs101-acpm-ipc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos ACPM mailbox protocol
+
+maintainers:
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
+
+description: |
+ ACPM (Alive Clock and Power Manager) is a firmware that operates on the
+ APM (Active Power Management) module that handles overall power management
+ activities. ACPM and masters regard each other as independent hardware
+ component and communicate with each other using mailbox messages and
+ shared memory.
+
+ This binding is intended to define the interface the firmware implementing
+ ACPM provides for OSPM in the device tree.
+
+properties:
+ compatible:
+ const: google,gs101-acpm-ipc
+
+ "#clock-cells":
+ const: 1
+ description:
+ Clocks that are variable and index based. These clocks don't provide
+ an entire range of values between the limits but only discrete points
+ within the range. The firmware also manages the voltage scaling
+ appropriately with the clock scaling. The argument is the ID of the
+ clock contained by the firmware messages.
+
+ mboxes:
+ maxItems: 1
+
+ pmic:
+ description: Child node describing the main PMIC.
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: samsung,s2mpg10-pmic
+
+ shmem:
+ description:
+ List of phandle pointing to the shared memory (SHM) area. The memory
+ contains channels configuration data and the TX/RX ring buffers that
+ are used for passing messages to/from the ACPM firmware.
+ maxItems: 1
+
+required:
+ - compatible
+ - "#clock-cells"
+ - mboxes
+ - shmem
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ power-management {
+ compatible = "google,gs101-acpm-ipc";
+ #clock-cells = <1>;
+ mboxes = <&ap2apm_mailbox>;
+ shmem = <&apm_sram>;
+
+ pmic {
+ compatible = "samsung,s2mpg10-pmic";
+ interrupts-extended = <&gpa0 6 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ LDO1 {
+ regulator-name = "vdd_ldo1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ };
+
+ // ...
+
+ BUCK1 {
+ regulator-name = "vdd_mif";
+ regulator-min-microvolt = <450000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
index 9a785bbaafb7..50f1f08744a1 100644
--- a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
+++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx Network Processing Engine
@@ -62,33 +62,33 @@ examples:
#include <dt-bindings/gpio/gpio.h>
npe: npe@c8006000 {
- compatible = "intel,ixp4xx-network-processing-engine";
- reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "intel,ixp4xx-network-processing-engine";
+ reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- hss@0 {
- compatible = "intel,ixp4xx-hss";
- reg = <0>;
- intel,npe-handle = <&npe 0>;
- intel,queue-chl-rxtrig = <&qmgr 12>;
- intel,queue-chl-txready = <&qmgr 34>;
- intel,queue-pkt-rx = <&qmgr 13>;
- intel,queue-pkt-tx = <&qmgr 14>, <&qmgr 15>, <&qmgr 16>, <&qmgr 17>;
- intel,queue-pkt-rxfree = <&qmgr 18>, <&qmgr 19>, <&qmgr 20>, <&qmgr 21>;
- intel,queue-pkt-txdone = <&qmgr 22>;
- cts-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
- rts-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
- dtr-gpios = <&gpio_74 2 GPIO_ACTIVE_LOW>;
- clk-internal-gpios = <&gpio_74 0 GPIO_ACTIVE_HIGH>;
- };
+ hss@0 {
+ compatible = "intel,ixp4xx-hss";
+ reg = <0>;
+ intel,npe-handle = <&npe 0>;
+ intel,queue-chl-rxtrig = <&qmgr 12>;
+ intel,queue-chl-txready = <&qmgr 34>;
+ intel,queue-pkt-rx = <&qmgr 13>;
+ intel,queue-pkt-tx = <&qmgr 14>, <&qmgr 15>, <&qmgr 16>, <&qmgr 17>;
+ intel,queue-pkt-rxfree = <&qmgr 18>, <&qmgr 19>, <&qmgr 20>, <&qmgr 21>;
+ intel,queue-pkt-txdone = <&qmgr 22>;
+ cts-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+ rts-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
+ dcd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+ dtr-gpios = <&gpio_74 2 GPIO_ACTIVE_LOW>;
+ clk-internal-gpios = <&gpio_74 0 GPIO_ACTIVE_HIGH>;
+ };
- crypto {
- compatible = "intel,ixp4xx-crypto";
- intel,npe-handle = <&npe 2>;
- queue-rx = <&qmgr 30>;
- queue-txready = <&qmgr 29>;
- };
+ crypto {
+ compatible = "intel,ixp4xx-crypto";
+ intel,npe-handle = <&npe 2>;
+ queue-rx = <&qmgr 30>;
+ queue-txready = <&qmgr 29>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt
deleted file mode 100644
index 6eff1afd8daf..000000000000
--- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Intel Service Layer Driver for Stratix10 SoC
-============================================
-Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard
-processor system (HPS) and Secure Device Manager (SDM). When the FPGA is
-configured from HPS, there needs to be a way for HPS to notify SDM the
-location and size of the configuration data. Then SDM will get the
-configuration data from that location and perform the FPGA configuration.
-
-To meet the whole system security needs and support virtual machine requesting
-communication with SDM, only the secure world of software (EL3, Exception
-Layer 3) can interface with SDM. All software entities running on other
-exception layers must channel through the EL3 software whenever it needs
-service from SDM.
-
-Intel Stratix10 service layer driver, running at privileged exception level
-(EL1, Exception Layer 1), interfaces with the service providers and provides
-the services for FPGA configuration, QSPI, Crypto and warm reset. Service layer
-driver also manages secure monitor call (SMC) to communicate with secure monitor
-code running in EL3.
-
-Required properties:
--------------------
-The svc node has the following mandatory properties, must be located under
-the firmware node.
-
-- compatible: "intel,stratix10-svc" or "intel,agilex-svc"
-- method: smc or hvc
- smc - Secure Monitor Call
- hvc - Hypervisor Call
-- memory-region:
- phandle to the reserved memory node. See
- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
- for details
-
-Example:
--------
-
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- service_reserved: svcbuffer@0 {
- compatible = "shared-dma-pool";
- reg = <0x0 0x0 0x0 0x1000000>;
- alignment = <0x1000>;
- no-map;
- };
- };
-
- firmware {
- svc {
- compatible = "intel,stratix10-svc";
- method = "smc";
- memory-region = <&service_reserved>;
- };
- };
diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
new file mode 100644
index 000000000000..b42cfa78b28b
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/intel,stratix10-svc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Service Layer Driver for Stratix10 SoC
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+ - Mahesh Rao <mahesh.rao@altera.com>
+
+description: >
+ Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard
+ processor system (HPS) and Secure Device Manager (SDM). When the FPGA is
+ configured from HPS, there needs to be a way for HPS to notify SDM the
+ location and size of the configuration data. Then SDM will get the
+ configuration data from that location and perform the FPGA configuration.
+
+ To meet the whole system security needs and support virtual machine requesting
+ communication with SDM, only the secure world of software (EL3, Exception
+ Layer 3) can interface with SDM. All software entities running on other
+ exception layers must channel through the EL3 software whenever it needs
+ service from SDM.
+
+ Intel Stratix10 service layer driver, running at privileged exception level
+ (EL1, Exception Layer 1), interfaces with the service providers and provides
+ the services for FPGA configuration, QSPI, Crypto and warm reset. Service layer
+ driver also manages secure monitor call (SMC) to communicate with secure monitor
+ code running in EL3.
+
+properties:
+ compatible:
+ enum:
+ - intel,stratix10-svc
+ - intel,agilex-svc
+ - intel,agilex5-svc
+
+ method:
+ description: |
+ Supervisory call method to be used to communicate with the
+ secure service layer.
+ Permitted values are:
+ - "smc" : SMC #0, following the SMCCC
+ - "hvc" : HVC #0, following the SMCCC
+
+ $ref: /schemas/types.yaml#/definitions/string-array
+ enum:
+ - smc
+ - hvc
+
+ memory-region:
+ maxItems: 1
+ description:
+ reserved memory region for the service layer driver to
+ communicate with the secure device manager.
+
+ iommus:
+ maxItems: 1
+
+ fpga-mgr:
+ $ref: /schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml
+ description: Optional child node for fpga manager to perform fabric configuration.
+
+required:
+ - compatible
+ - method
+ - memory-region
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - intel,agilex5-svc
+ then:
+ required:
+ - iommus
+
+additionalProperties: false
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ service_reserved: svcbuffer@0 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x0 0x0 0x1000000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ firmware {
+ svc {
+ compatible = "intel,stratix10-svc";
+ method = "smc";
+ memory-region = <&service_reserved>;
+
+ fpga-mgr {
+ compatible = "intel,stratix10-soc-fpga-mgr";
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt b/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt
deleted file mode 100644
index c248cd44f727..000000000000
--- a/Documentation/devicetree/bindings/firmware/meson/meson_sm.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* Amlogic Secure Monitor
-
-In the Amlogic SoCs the Secure Monitor code is used to provide access to the
-NVMEM, enable JTAG, set USB boot, etc...
-
-Required properties for the secure monitor node:
-- compatible: Should be "amlogic,meson-gxbb-sm"
-
-Example:
-
- firmware {
- sm: secure-monitor {
- compatible = "amlogic,meson-gxbb-sm";
- };
- };
diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
index 833c07f1685c..3c44fe607e12 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
@@ -57,8 +57,11 @@ description: |
"#address-cells" or "#size-cells" property.
The shared memory area for the IPC TX and RX between CPU and BPMP are
- predefined and work on top of sysram, which is an SRAM inside the
- chip. See ".../sram/sram.yaml" for the bindings.
+ predefined and work on top of either sysram, which is an SRAM inside the
+ chip, or in normal SDRAM.
+ See ".../sram/sram.yaml" for the bindings for the SRAM case.
+ See "../reserved-memory/nvidia,tegra264-bpmp-shmem.yaml" for bindings for
+ the SDRAM case.
properties:
compatible:
@@ -67,6 +70,7 @@ properties:
- enum:
- nvidia,tegra194-bpmp
- nvidia,tegra234-bpmp
+ - nvidia,tegra264-bpmp
- const: nvidia,tegra186-bpmp
- const: nvidia,tegra186-bpmp
@@ -81,6 +85,11 @@ properties:
minItems: 2
maxItems: 2
+ memory-region:
+ description: phandle to reserved memory region used for IPC between
+ CPU-NS and BPMP.
+ maxItems: 1
+
"#clock-cells":
const: 1
@@ -115,10 +124,15 @@ properties:
additionalProperties: false
+oneOf:
+ - required:
+ - memory-region
+ - required:
+ - shmem
+
required:
- compatible
- mboxes
- - shmem
- "#clock-cells"
- "#power-domain-cells"
- "#reset-cells"
@@ -165,8 +179,7 @@ examples:
<&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
interconnect-names = "read", "write", "dma-mem", "dma-write";
iommus = <&smmu TEGRA186_SID_BPMP>;
- mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB
- TEGRA_HSP_DB_MASTER_BPMP>;
+ mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
shmem = <&cpu_bpmp_tx>, <&cpu_bpmp_rx>;
#clock-cells = <1>;
#power-domain-cells = <1>;
@@ -184,3 +197,20 @@ examples:
#thermal-sensor-cells = <1>;
};
};
+
+ - |
+ #include <dt-bindings/mailbox/tegra186-hsp.h>
+
+ bpmp {
+ compatible = "nvidia,tegra186-bpmp";
+ interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
+ interconnect-names = "read", "write", "dma-mem", "dma-write";
+ mboxes = <&hsp_top1 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
+ memory-region = <&dram_cpu_bpmp_mail>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi-pinctrl.yaml b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi-pinctrl.yaml
new file mode 100644
index 000000000000..a96fc6cce502
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi-pinctrl.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2024 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/nxp,imx95-scmi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX System Control and Management Interface (SCMI) Pinctrl Protocol
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+allOf:
+ - $ref: /schemas/pinctrl/pinctrl.yaml
+
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ unevaluatedProperties: false
+
+ properties:
+ fsl,pins:
+ description:
+ each entry consists of 6 integers and represents the mux and config
+ setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+ mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+ be found in <arch/arm64/boot/dts/freescale/imx95-pinfunc.h>. The last
+ integer CONFIG is the pad setting value like pull-up on this pin.
+ Please refer to i.MX95 Reference Manual for detailed CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_reg" indicates the offset of mux register.
+ - description: |
+ "conf_reg" indicates the offset of pad configuration register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_val" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ "pad_setting" indicates the pad configuration value to be applied.
+
+ required:
+ - fsl,pins
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml
new file mode 100644
index 000000000000..7a5a02da2719
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/nxp,imx95-scmi.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2024 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/nxp,imx95-scmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX95 System Control and Management Interface(SCMI) Vendor Protocols Extension
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+properties:
+ protocol@80:
+ description:
+ SCMI LMM protocol which is for boot, shutdown, and reset of other logical
+ machines (LM). It is usually used to allow one LM to manage another used
+ as an offload or accelerator engine.
+ $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x80
+
+ protocol@81:
+ type: object
+ allOf:
+ - $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'
+ - $ref: /schemas/input/input.yaml#
+ additionalProperties: false
+
+ properties:
+ reg:
+ const: 0x81
+
+ linux,code:
+ default: 116 # KEY_POWER
+
+ protocol@82:
+ description:
+ SCMI CPU Protocol which allows an agent to start or stop a CPU. It is
+ used to manage auxiliary CPUs in a LM.
+ $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x82
+
+ protocol@84:
+ $ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x84
+
+ nxp,ctrl-ids:
+ description:
+ Each entry consists of 2 integers, represents the ctrl id and the value
+ items:
+ items:
+ - description: the ctrl id index
+ enum: [0, 1, 2, 3, 4, 5, 6, 7, 0x8000, 0x8001, 0x8002, 0x8003,
+ 0x8004, 0x8005, 0x8006, 0x8007]
+ - description: the value assigned to the ctrl id
+ minItems: 1
+ maxItems: 16
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index c5b76c9f7ad0..d66459f1d84e 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -23,14 +23,22 @@ properties:
- enum:
- qcom,scm-apq8064
- qcom,scm-apq8084
+ - qcom,scm-glymur
- qcom,scm-ipq4019
+ - qcom,scm-ipq5018
+ - qcom,scm-ipq5332
+ - qcom,scm-ipq5424
- qcom,scm-ipq6018
- qcom,scm-ipq806x
- qcom,scm-ipq8074
+ - qcom,scm-ipq9574
+ - qcom,scm-kaanapali
- qcom,scm-mdm9607
+ - qcom,scm-milos
- qcom,scm-msm8226
- qcom,scm-msm8660
- qcom,scm-msm8916
+ - qcom,scm-msm8937
- qcom,scm-msm8953
- qcom,scm-msm8960
- qcom,scm-msm8974
@@ -38,20 +46,36 @@ properties:
- qcom,scm-msm8994
- qcom,scm-msm8996
- qcom,scm-msm8998
+ - qcom,scm-qcm2290
+ - qcom,scm-qcs615
+ - qcom,scm-qcs8300
+ - qcom,scm-qdu1000
+ - qcom,scm-sa8255p
+ - qcom,scm-sa8775p
+ - qcom,scm-sar2130p
- qcom,scm-sc7180
- qcom,scm-sc7280
+ - qcom,scm-sc8180x
- qcom,scm-sc8280xp
+ - qcom,scm-sdm670
- qcom,scm-sdm845
- qcom,scm-sdx55
- qcom,scm-sdx65
+ - qcom,scm-sdx75
- qcom,scm-sm6115
- qcom,scm-sm6125
- qcom,scm-sm6350
+ - qcom,scm-sm6375
+ - qcom,scm-sm7150
- qcom,scm-sm8150
- qcom,scm-sm8250
- qcom,scm-sm8350
- qcom,scm-sm8450
+ - qcom,scm-sm8550
+ - qcom,scm-sm8650
+ - qcom,scm-sm8750
- qcom,scm-qcs404
+ - qcom,scm-x1e80100
- const: qcom,scm
clocks:
@@ -62,6 +86,8 @@ properties:
minItems: 1
maxItems: 3
+ dma-coherent: true
+
interconnects:
maxItems: 1
@@ -71,6 +97,25 @@ properties:
'#reset-cells':
const: 1
+ interrupts:
+ description:
+ The wait-queue interrupt that firmware raises as part of handshake
+ protocol to handle sleeping SCM calls.
+ maxItems: 1
+
+ memory-region:
+ description:
+ Phandle to the memory region reserved for the shared memory bridge to TZ.
+ maxItems: 1
+
+ qcom,sdi-enabled:
+ description:
+ Indicates that the SDI (Secure Debug Image) has been enabled by TZ
+ by default and it needs to be disabled.
+ If not disabled WDT assertion or reboot will cause the board to hang
+ in the debug mode.
+ type: boolean
+
qcom,dload-mode:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
@@ -80,14 +125,44 @@ properties:
description: TCSR hardware block
allOf:
+ # Clocks
- if:
properties:
compatible:
contains:
enum:
- qcom,scm-apq8064
+ - qcom,scm-apq8084
+ - qcom,scm-mdm9607
+ - qcom,scm-msm8226
- qcom,scm-msm8660
+ - qcom,scm-msm8916
+ - qcom,scm-msm8937
+ - qcom,scm-msm8953
- qcom,scm-msm8960
+ - qcom,scm-msm8974
+ - qcom,scm-msm8976
+ - qcom,scm-qcm2290
+ - qcom,scm-sm6375
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clock-names: false
+ clocks: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,scm-apq8064
+ - qcom,scm-msm8660
+ - qcom,scm-msm8960
+ - qcom,scm-qcm2290
+ - qcom,scm-sm6375
then:
properties:
clock-names:
@@ -97,10 +172,6 @@ allOf:
clocks:
maxItems: 1
- required:
- - clocks
- - clock-names
-
- if:
properties:
compatible:
@@ -108,7 +179,9 @@ allOf:
enum:
- qcom,scm-apq8084
- qcom,scm-mdm9607
+ - qcom,scm-msm8226
- qcom,scm-msm8916
+ - qcom,scm-msm8937
- qcom,scm-msm8953
- qcom,scm-msm8974
- qcom,scm-msm8976
@@ -124,9 +197,33 @@ allOf:
minItems: 3
maxItems: 3
- required:
- - clocks
- - clock-names
+ # Interrupts
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,scm-kaanapali
+ - qcom,scm-milos
+ - qcom,scm-sm8450
+ - qcom,scm-sm8550
+ - qcom,scm-sm8650
+ - qcom,scm-sm8750
+ then:
+ properties:
+ interrupts: false
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,scm-sa8255p
+ - qcom,scm-sa8775p
+ then:
+ properties:
+ memory-region: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml b/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml
index fcf0011b8e6d..c6fc1d6e25da 100644
--- a/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml
+++ b/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/firmware/qemu,fw-cfg-mmio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: QEMU Firmware Configuration bindings
+title: QEMU Firmware Configuration
maintainers:
- Rob Herring <robh@kernel.org>
@@ -23,7 +23,6 @@ description: |
The authoritative guest-side hardware interface documentation to the fw_cfg
device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree.
-
properties:
compatible:
const: qemu,fw-cfg-mmio
diff --git a/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml
new file mode 100644
index 000000000000..3365124c7fd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/thead,th1520-aon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD TH1520 AON (Always-On) Firmware
+
+description: |
+ The Always-On (AON) subsystem in the TH1520 SoC is responsible for managing
+ low-power states, system wakeup events, and power management tasks. It is
+ designed to operate independently in a dedicated power domain, allowing it to
+ remain functional even during the SoC's deep sleep states.
+
+ At the heart of the AON subsystem is the E902, a low-power core that executes
+ firmware responsible for coordinating tasks such as power domain control,
+ clock management, and system wakeup signaling. Communication between the main
+ SoC and the AON subsystem is handled through a mailbox interface, which
+ enables message-based interactions with the AON firmware.
+
+maintainers:
+ - Michal Wilczynski <m.wilczynski@samsung.com>
+
+properties:
+ compatible:
+ const: thead,th1520-aon
+
+ mboxes:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: aon
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: gpu-clkgen
+
+ "#power-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - mboxes
+ - mbox-names
+ - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ aon: aon {
+ compatible = "thead,th1520-aon";
+ mboxes = <&mbox_910t 1>;
+ mbox-names = "aon";
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
index f14f7b454f07..ab8f32c440df 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx firmware driver
maintainers:
- - Nava kishore Manne <nava.manne@xilinx.com>
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
description: The zynqmp-firmware node describes the interface to platform
firmware. ZynqMP has an interface to communicate with secure firmware.
@@ -26,6 +26,12 @@ properties:
- description: For implementations complying for Versal.
const: xlnx,versal-firmware
+ - description: For implementations complying for Versal NET.
+ items:
+ - enum:
+ - xlnx,versal-net-firmware
+ - const: xlnx,versal-firmware
+
method:
description: |
The method of calling the PM-API firmware layer.
@@ -38,7 +44,56 @@ properties:
- smc
- hvc
- versal_fpga:
+ "#power-domain-cells":
+ const: 1
+
+ clock-controller:
+ $ref: /schemas/clock/xlnx,versal-clk.yaml#
+ description: The clock controller is a hardware block of Xilinx versal
+ clock tree. It reads required input clock frequencies from the devicetree
+ and acts as clock provider for all clock consumers of PS clocks.list of
+ clock specifiers which are external input clocks to the given clock
+ controller.
+ type: object
+
+ gpio:
+ $ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+ description: The gpio node describes connect to PS_MODE pins via firmware
+ interface.
+ type: object
+
+ soc-nvmem:
+ $ref: /schemas/nvmem/xlnx,zynqmp-nvmem.yaml#
+ description: The ZynqMP MPSoC provides access to the hardware related data
+ like SOC revision, IDCODE and specific purpose efuses.
+ type: object
+
+ pcap:
+ $ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
+ description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
+ configure the Programmable Logic (PL). The configuration uses the
+ firmware interface.
+ type: object
+
+ pinctrl:
+ $ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+ description: The pinctrl node provides access to pinconfig and pincontrol
+ functionality available in firmware.
+ type: object
+
+ power-management:
+ $ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
+ description: The zynqmp-power node describes the power management
+ configurations. It will control remote suspend/shutdown interfaces.
+ type: object
+
+ reset-controller:
+ $ref: /schemas/reset/xlnx,zynqmp-reset.yaml#
+ description: The reset-controller node describes connection to the reset
+ functionality via firmware interface.
+ type: object
+
+ versal-fpga:
$ref: /schemas/fpga/xlnx,versal-fpga.yaml#
description: Compatible of the FPGA device.
type: object
@@ -50,15 +105,6 @@ properties:
vector.
type: object
- clock-controller:
- $ref: /schemas/clock/xlnx,versal-clk.yaml#
- description: The clock controller is a hardware block of Xilinx versal
- clock tree. It reads required input clock frequencies from the devicetree
- and acts as clock provider for all clock consumers of PS clocks.list of
- clock specifiers which are external input clocks to the given clock
- controller.
- type: object
-
required:
- compatible
@@ -66,11 +112,53 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+ firmware {
+ zynqmp_firmware: zynqmp-firmware {
+ #power-domain-cells = <1>;
+ soc-nvmem {
+ compatible = "xlnx,zynqmp-nvmem-fw";
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ soc_revision: soc-revision@0 {
+ reg = <0x0 0x4>;
+ };
+ };
+ };
+ gpio {
+ compatible = "xlnx,zynqmp-gpio-modepin";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ pcap {
+ compatible = "xlnx,zynqmp-pcap-fpga";
+ };
+ pinctrl {
+ compatible = "xlnx,zynqmp-pinctrl";
+ };
+ power-management {
+ compatible = "xlnx,zynqmp-power";
+ interrupts = <0 35 4>;
+ };
+ reset-controller {
+ compatible = "xlnx,zynqmp-reset";
+ #reset-cells = <1>;
+ };
+ };
+ };
+
+ sata {
+ power-domains = <&zynqmp_firmware PD_SATA>;
+ };
+
versal-firmware {
compatible = "xlnx,versal-firmware";
method = "smc";
- versal_fpga: versal_fpga {
+ versal_fpga: versal-fpga {
compatible = "xlnx,versal-fpga";
};
@@ -81,8 +169,8 @@ examples:
versal_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,versal-clk";
- clocks = <&ref>, <&alt_ref>, <&pl_alt_ref>;
- clock-names = "ref", "alt_ref", "pl_alt_ref";
+ clocks = <&ref>, <&pl_alt_ref>;
+ clock-names = "ref", "pl_alt_ref";
};
};
diff --git a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
deleted file mode 100644
index 5dd0ff0f7b4e..000000000000
--- a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-Altera FPGA To SDRAM Bridge Driver
-
-Required properties:
-- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
-
-See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
-
-Example:
- fpga_bridge3: fpga-bridge@ffc25080 {
- compatible = "altr,socfpga-fpga2sdram-bridge";
- reg = <0xffc25080 0x4>;
- bridge-enable = <0>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt
deleted file mode 100644
index 8b26fbcff3c6..000000000000
--- a/Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Altera Freeze Bridge Controller Driver
-
-The Altera Freeze Bridge Controller manages one or more freeze bridges.
-The controller can freeze/disable the bridges which prevents signal
-changes from passing through the bridge. The controller can also
-unfreeze/enable the bridges which allows traffic to pass through the
-bridge normally.
-
-Required properties:
-- compatible : Should contain "altr,freeze-bridge-controller"
-- regs : base address and size for freeze bridge module
-
-See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
-
-Example:
- freeze-controller@100000450 {
- compatible = "altr,freeze-bridge-controller";
- regs = <0x1000 0x10>;
- bridge-enable = <0>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
deleted file mode 100644
index 68cce3945b10..000000000000
--- a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Altera FPGA/HPS Bridge Driver
-
-Required properties:
-- regs : base address and size for AXI bridge module
-- compatible : Should contain one of:
- "altr,socfpga-lwhps2fpga-bridge",
- "altr,socfpga-hps2fpga-bridge", or
- "altr,socfpga-fpga2hps-bridge"
-- resets : Phandle and reset specifier for this bridge's reset
-- clocks : Clocks used by this module.
-
-See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
-
-Example:
- fpga_bridge0: fpga-bridge@ff400000 {
- compatible = "altr,socfpga-lwhps2fpga-bridge";
- reg = <0xff400000 0x100000>;
- resets = <&rst LWHPS2FPGA_RESET>;
- clocks = <&l4_main_clk>;
- bridge-enable = <0>;
- };
-
- fpga_bridge1: fpga-bridge@ff500000 {
- compatible = "altr,socfpga-hps2fpga-bridge";
- reg = <0xff500000 0x10000>;
- resets = <&rst HPS2FPGA_RESET>;
- clocks = <&l4_main_clk>;
- bridge-enable = <1>;
- };
-
- fpga_bridge2: fpga-bridge@ff600000 {
- compatible = "altr,socfpga-fpga2hps-bridge";
- reg = <0xff600000 0x100000>;
- resets = <&rst FPGA2HPS_RESET>;
- clocks = <&l4_main_clk>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/altera-passive-serial.txt b/Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
deleted file mode 100644
index 48478bc07e29..000000000000
--- a/Documentation/devicetree/bindings/fpga/altera-passive-serial.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Altera Passive Serial SPI FPGA Manager
-
-Altera FPGAs support a method of loading the bitstream over what is
-referred to as "passive serial".
-The passive serial link is not technically SPI, and might require extra
-circuits in order to play nicely with other SPI slaves on the same bus.
-
-See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
-
-Required properties:
-- compatible: Must be one of the following:
- "altr,fpga-passive-serial",
- "altr,fpga-arria10-passive-serial"
-- reg: SPI chip select of the FPGA
-- nconfig-gpios: config pin (referred to as nCONFIG in the manual)
-- nstat-gpios: status pin (referred to as nSTATUS in the manual)
-
-Optional properties:
-- confd-gpios: confd pin (referred to as CONF_DONE in the manual)
-
-Example:
- fpga: fpga@0 {
- compatible = "altr,fpga-passive-serial";
- spi-max-frequency = <20000000>;
- reg = <0>;
- nconfig-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
- nstat-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
- confd-gpios = <&gpio4 12 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/altr,fpga-passive-serial.yaml b/Documentation/devicetree/bindings/fpga/altr,fpga-passive-serial.yaml
new file mode 100644
index 000000000000..ffb7cc54556f
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altr,fpga-passive-serial.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/altr,fpga-passive-serial.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera Passive Serial SPI FPGA Manager
+
+maintainers:
+ - Fabio Estevam <festevam@denx.de>
+
+description: |
+ Altera FPGAs support a method of loading the bitstream over what is
+ referred to as "passive serial".
+ The passive serial link is not technically SPI, and might require extra
+ circuits in order to play nicely with other SPI slaves on the same bus.
+
+ See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - altr,fpga-passive-serial
+ - altr,fpga-arria10-passive-serial
+
+ spi-max-frequency:
+ maximum: 20000000
+
+ reg:
+ maxItems: 1
+
+ nconfig-gpios:
+ description:
+ Config pin (referred to as nCONFIG in the manual).
+ maxItems: 1
+
+ nstat-gpios:
+ description:
+ Status pin (referred to as nSTATUS in the manual).
+ maxItems: 1
+
+ confd-gpios:
+ description:
+ confd pin (referred to as CONF_DONE in the manual)
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - nconfig-gpios
+ - nstat-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fpga@0 {
+ compatible = "altr,fpga-passive-serial";
+ reg = <0>;
+ nconfig-gpios = <&gpio4 18 GPIO_ACTIVE_LOW>;
+ nstat-gpios = <&gpio4 19 GPIO_ACTIVE_LOW>;
+ confd-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/fpga/altr,freeze-bridge-controller.yaml b/Documentation/devicetree/bindings/fpga/altr,freeze-bridge-controller.yaml
new file mode 100644
index 000000000000..fccffeebb256
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altr,freeze-bridge-controller.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/altr,freeze-bridge-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera Freeze Bridge Controller
+
+description:
+ The Altera Freeze Bridge Controller manages one or more freeze bridges.
+ The controller can freeze/disable the bridges which prevents signal
+ changes from passing through the bridge. The controller can also
+ unfreeze/enable the bridges which allows traffic to pass through the bridge
+ normally.
+
+maintainers:
+ - Xu Yilun <yilun.xu@intel.com>
+
+allOf:
+ - $ref: fpga-bridge.yaml#
+
+properties:
+ compatible:
+ const: altr,freeze-bridge-controller
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fpga-bridge@100000450 {
+ compatible = "altr,freeze-bridge-controller";
+ reg = <0x1000 0x10>;
+ bridge-enable = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/altr,socfpga-fpga2sdram-bridge.yaml b/Documentation/devicetree/bindings/fpga/altr,socfpga-fpga2sdram-bridge.yaml
new file mode 100644
index 000000000000..22b58453c5ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altr,socfpga-fpga2sdram-bridge.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/altr,socfpga-fpga2sdram-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera FPGA To SDRAM Bridge
+
+maintainers:
+ - Xu Yilun <yilun.xu@intel.com>
+
+allOf:
+ - $ref: fpga-bridge.yaml#
+
+properties:
+ compatible:
+ const: altr,socfpga-fpga2sdram-bridge
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fpga-bridge@ffc25080 {
+ compatible = "altr,socfpga-fpga2sdram-bridge";
+ reg = <0xffc25080 0x4>;
+ bridge-enable = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/altr,socfpga-hps2fpga-bridge.yaml b/Documentation/devicetree/bindings/fpga/altr,socfpga-hps2fpga-bridge.yaml
new file mode 100644
index 000000000000..d19c6660d6c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altr,socfpga-hps2fpga-bridge.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/altr,socfpga-hps2fpga-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera FPGA/HPS Bridge
+
+maintainers:
+ - Xu Yilun <yilun.xu@intel.com>
+
+allOf:
+ - $ref: fpga-bridge.yaml#
+
+properties:
+ compatible:
+ enum:
+ - altr,socfpga-lwhps2fpga-bridge
+ - altr,socfpga-hps2fpga-bridge
+ - altr,socfpga-fpga2hps-bridge
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/altr,rst-mgr.h>
+
+ fpga-bridge@ff400000 {
+ compatible = "altr,socfpga-lwhps2fpga-bridge";
+ reg = <0xff400000 0x100000>;
+ bridge-enable = <0>;
+ clocks = <&l4_main_clk>;
+ resets = <&rst LWHPS2FPGA_RESET>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/fpga-bridge.txt
deleted file mode 100644
index 72e06917288a..000000000000
--- a/Documentation/devicetree/bindings/fpga/fpga-bridge.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-FPGA Bridge Device Tree Binding
-
-Optional properties:
-- bridge-enable : 0 if driver should disable bridge at startup
- 1 if driver should enable bridge at startup
- Default is to leave bridge in current state.
-
-Example:
- fpga_bridge3: fpga-bridge@ffc25080 {
- compatible = "altr,socfpga-fpga2sdram-bridge";
- reg = <0xffc25080 0x4>;
- bridge-enable = <0>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/fpga-bridge.yaml b/Documentation/devicetree/bindings/fpga/fpga-bridge.yaml
new file mode 100644
index 000000000000..1ccb2aa18726
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-bridge.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/fpga-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FPGA Bridge
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+
+properties:
+ $nodename:
+ pattern: "^fpga-bridge(@.*|-([0-9]|[1-9][0-9]+))?$"
+
+ bridge-enable:
+ description: |
+ 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ Default is to leave bridge in current state.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+
+additionalProperties: true
+
+examples:
+ - |
+ fpga-bridge {
+ bridge-enable = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
deleted file mode 100644
index 6694ef29a267..000000000000
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ /dev/null
@@ -1,479 +0,0 @@
-FPGA Region Device Tree Binding
-
-Alan Tull 2016
-
- CONTENTS
- - Introduction
- - Terminology
- - Sequence
- - FPGA Region
- - Supported Use Models
- - Device Tree Examples
- - Constraints
-
-
-Introduction
-============
-
-FPGA Regions represent FPGA's and partial reconfiguration regions of FPGA's in
-the Device Tree. FPGA Regions provide a way to program FPGAs under device tree
-control.
-
-This device tree binding document hits some of the high points of FPGA usage and
-attempts to include terminology used by both major FPGA manufacturers. This
-document isn't a replacement for any manufacturers specifications for FPGA
-usage.
-
-
-Terminology
-===========
-
-Full Reconfiguration
- * The entire FPGA is programmed.
-
-Partial Reconfiguration (PR)
- * A section of an FPGA is reprogrammed while the rest of the FPGA is not
- affected.
- * Not all FPGA's support PR.
-
-Partial Reconfiguration Region (PRR)
- * Also called a "reconfigurable partition"
- * A PRR is a specific section of an FPGA reserved for reconfiguration.
- * A base (or static) FPGA image may create a set of PRR's that later may
- be independently reprogrammed many times.
- * The size and specific location of each PRR is fixed.
- * The connections at the edge of each PRR are fixed. The image that is loaded
- into a PRR must fit and must use a subset of the region's connections.
- * The busses within the FPGA are split such that each region gets its own
- branch that may be gated independently.
-
-Persona
- * Also called a "partial bit stream"
- * An FPGA image that is designed to be loaded into a PRR. There may be
- any number of personas designed to fit into a PRR, but only one at at time
- may be loaded.
- * A persona may create more regions.
-
-FPGA Bridge
- * FPGA Bridges gate bus signals between a host and FPGA.
- * FPGA Bridges should be disabled while the FPGA is being programmed to
- prevent spurious signals on the cpu bus and to the soft logic.
- * FPGA bridges may be actual hardware or soft logic on an FPGA.
- * During Full Reconfiguration, hardware bridges between the host and FPGA
- will be disabled.
- * During Partial Reconfiguration of a specific region, that region's bridge
- will be used to gate the busses. Traffic to other regions is not affected.
- * In some implementations, the FPGA Manager transparantly handles gating the
- buses, eliminating the need to show the hardware FPGA bridges in the
- device tree.
- * An FPGA image may create a set of reprogrammable regions, each having its
- own bridge and its own split of the busses in the FPGA.
-
-FPGA Manager
- * An FPGA Manager is a hardware block that programs an FPGA under the control
- of a host processor.
-
-Base Image
- * Also called the "static image"
- * An FPGA image that is designed to do full reconfiguration of the FPGA.
- * A base image may set up a set of partial reconfiguration regions that may
- later be reprogrammed.
-
- ---------------- ----------------------------------
- | Host CPU | | FPGA |
- | | | |
- | ----| | ----------- -------- |
- | | H | | |==>| Bridge0 |<==>| PRR0 | |
- | | W | | | ----------- -------- |
- | | | | | |
- | | B |<=====>|<==| ----------- -------- |
- | | R | | |==>| Bridge1 |<==>| PRR1 | |
- | | I | | | ----------- -------- |
- | | D | | | |
- | | G | | | ----------- -------- |
- | | E | | |==>| Bridge2 |<==>| PRR2 | |
- | ----| | ----------- -------- |
- | | | |
- ---------------- ----------------------------------
-
-Figure 1: An FPGA set up with a base image that created three regions. Each
-region (PRR0-2) gets its own split of the busses that is independently gated by
-a soft logic bridge (Bridge0-2) in the FPGA. The contents of each PRR can be
-reprogrammed independently while the rest of the system continues to function.
-
-
-Sequence
-========
-
-When a DT overlay that targets an FPGA Region is applied, the FPGA Region will
-do the following:
-
- 1. Disable appropriate FPGA bridges.
- 2. Program the FPGA using the FPGA manager.
- 3. Enable the FPGA bridges.
- 4. The Device Tree overlay is accepted into the live tree.
- 5. Child devices are populated.
-
-When the overlay is removed, the child nodes will be removed and the FPGA Region
-will disable the bridges.
-
-
-FPGA Region
-===========
-
-FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA
-Region brings together the elements needed to program on a running system and
-add the child devices:
-
- * FPGA Manager
- * FPGA Bridges
- * image-specific information needed to to the programming.
- * child nodes
-
-The intended use is that a Device Tree overlay (DTO) can be used to reprogram an
-FPGA while an operating system is running.
-
-An FPGA Region that exists in the live Device Tree reflects the current state.
-If the live tree shows a "firmware-name" property or child nodes under an FPGA
-Region, the FPGA already has been programmed. A DTO that targets an FPGA Region
-and adds the "firmware-name" property is taken as a request to reprogram the
-FPGA. After reprogramming is successful, the overlay is accepted into the live
-tree.
-
-The base FPGA Region in the device tree represents the FPGA and supports full
-reconfiguration. It must include a phandle to an FPGA Manager. The base
-FPGA region will be the child of one of the hardware bridges (the bridge that
-allows register access) between the cpu and the FPGA. If there are more than
-one bridge to control during FPGA programming, the region will also contain a
-list of phandles to the additional hardware FPGA Bridges.
-
-For partial reconfiguration (PR), each PR region will have an FPGA Region.
-These FPGA regions are children of FPGA bridges which are then children of the
-base FPGA region. The "Full Reconfiguration to add PRR's" example below shows
-this.
-
-If an FPGA Region does not specify an FPGA Manager, it will inherit the FPGA
-Manager specified by its ancestor FPGA Region. This supports both the case
-where the same FPGA Manager is used for all of an FPGA as well the case where
-a different FPGA Manager is used for each region.
-
-FPGA Regions do not inherit their ancestor FPGA regions' bridges. This prevents
-shutting down bridges that are upstream from the other active regions while one
-region is getting reconfigured (see Figure 1 above). During PR, the FPGA's
-hardware bridges remain enabled. The PR regions' bridges will be FPGA bridges
-within the static image of the FPGA.
-
-Required properties:
-- compatible : should contain "fpga-region"
-- fpga-mgr : should contain a phandle to an FPGA Manager. Child FPGA Regions
- inherit this property from their ancestor regions. An fpga-mgr property
- in a region will override any inherited FPGA manager.
-- #address-cells, #size-cells, ranges : must be present to handle address space
- mapping for child nodes.
-
-Optional properties:
-- firmware-name : should contain the name of an FPGA image file located on the
- firmware search path. If this property shows up in a live device tree
- it indicates that the FPGA has already been programmed with this image.
- If this property is in an overlay targeting an FPGA region, it is a
- request to program the FPGA with that image.
-- fpga-bridges : should contain a list of phandles to FPGA Bridges that must be
- controlled during FPGA programming along with the parent FPGA bridge.
- This property is optional if the FPGA Manager handles the bridges.
- If the fpga-region is the child of an fpga-bridge, the list should not
- contain the parent bridge.
-- partial-fpga-config : boolean, set if partial reconfiguration is to be done,
- otherwise full reconfiguration is done.
-- external-fpga-config : boolean, set if the FPGA has already been configured
- prior to OS boot up.
-- encrypted-fpga-config : boolean, set if the bitstream is encrypted
-- region-unfreeze-timeout-us : The maximum time in microseconds to wait for
- bridges to successfully become enabled after the region has been
- programmed.
-- region-freeze-timeout-us : The maximum time in microseconds to wait for
- bridges to successfully become disabled before the region has been
- programmed.
-- config-complete-timeout-us : The maximum time in microseconds time for the
- FPGA to go to operating mode after the region has been programmed.
-- child nodes : devices in the FPGA after programming.
-
-In the example below, when an overlay is applied targeting fpga-region0,
-fpga_mgr is used to program the FPGA. Two bridges are controlled during
-programming: the parent fpga_bridge0 and fpga_bridge1. Because the region is
-the child of fpga_bridge0, only fpga_bridge1 needs to be specified in the
-fpga-bridges property. During programming, these bridges are disabled, the
-firmware specified in the overlay is loaded to the FPGA using the FPGA manager
-specified in the region. If FPGA programming succeeds, the bridges are
-reenabled and the overlay makes it into the live device tree. The child devices
-are then populated. If FPGA programming fails, the bridges are left disabled
-and the overlay is rejected. The overlay's ranges property maps the lwhps
-bridge's region (0xff200000) and the hps bridge's region (0xc0000000) for use by
-the two child devices.
-
-Example:
-Base tree contains:
-
- fpga_mgr: fpga-mgr@ff706000 {
- compatible = "altr,socfpga-fpga-mgr";
- reg = <0xff706000 0x1000
- 0xffb90000 0x20>;
- interrupts = <0 175 4>;
- };
-
- fpga_bridge0: fpga-bridge@ff400000 {
- compatible = "altr,socfpga-lwhps2fpga-bridge";
- reg = <0xff400000 0x100000>;
- resets = <&rst LWHPS2FPGA_RESET>;
- clocks = <&l4_main_clk>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- fpga_region0: fpga-region0 {
- compatible = "fpga-region";
- fpga-mgr = <&fpga_mgr>;
- };
- };
-
- fpga_bridge1: fpga-bridge@ff500000 {
- compatible = "altr,socfpga-hps2fpga-bridge";
- reg = <0xff500000 0x10000>;
- resets = <&rst HPS2FPGA_RESET>;
- clocks = <&l4_main_clk>;
- };
-
-Overlay contains:
-
-/dts-v1/;
-/plugin/;
-
-&fpga_region0 {
- #address-cells = <1>;
- #size-cells = <1>;
-
- firmware-name = "soc_system.rbf";
- fpga-bridges = <&fpga_bridge1>;
- ranges = <0x20000 0xff200000 0x100000>,
- <0x0 0xc0000000 0x20000000>;
-
- gpio@10040 {
- compatible = "altr,pio-1.0";
- reg = <0x10040 0x20>;
- altr,ngpio = <4>;
- #gpio-cells = <2>;
- clocks = <2>;
- gpio-controller;
- };
-
- onchip-memory {
- device_type = "memory";
- compatible = "altr,onchipmem-15.1";
- reg = <0x0 0x10000>;
- };
-};
-
-
-Supported Use Models
-====================
-
-In all cases the live DT must have the FPGA Manager, FPGA Bridges (if any), and
-a FPGA Region. The target of the Device Tree Overlay is the FPGA Region. Some
-uses are specific to an FPGA device.
-
- * No FPGA Bridges
- In this case, the FPGA Manager which programs the FPGA also handles the
- bridges behind the scenes. No FPGA Bridge devices are needed for full
- reconfiguration.
-
- * Full reconfiguration with hardware bridges
- In this case, there are hardware bridges between the processor and FPGA that
- need to be controlled during full reconfiguration. Before the overlay is
- applied, the live DT must include the FPGA Manager, FPGA Bridges, and a
- FPGA Region. The FPGA Region is the child of the bridge that allows
- register access to the FPGA. Additional bridges may be listed in a
- fpga-bridges property in the FPGA region or in the device tree overlay.
-
- * Partial reconfiguration with bridges in the FPGA
- In this case, the FPGA will have one or more PRR's that may be programmed
- separately while the rest of the FPGA can remain active. To manage this,
- bridges need to exist in the FPGA that can gate the buses going to each FPGA
- region while the buses are enabled for other sections. Before any partial
- reconfiguration can be done, a base FPGA image must be loaded which includes
- PRR's with FPGA bridges. The device tree should have an FPGA region for each
- PRR.
-
-Device Tree Examples
-====================
-
-The intention of this section is to give some simple examples, focusing on
-the placement of the elements detailed above, especially:
- * FPGA Manager
- * FPGA Bridges
- * FPGA Region
- * ranges
- * target-path or target
-
-For the purposes of this section, I'm dividing the Device Tree into two parts,
-each with its own requirements. The two parts are:
- * The live DT prior to the overlay being added
- * The DT overlay
-
-The live Device Tree must contain an FPGA Region, an FPGA Manager, and any FPGA
-Bridges. The FPGA Region's "fpga-mgr" property specifies the manager by phandle
-to handle programming the FPGA. If the FPGA Region is the child of another FPGA
-Region, the parent's FPGA Manager is used. If FPGA Bridges need to be involved,
-they are specified in the FPGA Region by the "fpga-bridges" property. During
-FPGA programming, the FPGA Region will disable the bridges that are in its
-"fpga-bridges" list and will re-enable them after FPGA programming has
-succeeded.
-
-The Device Tree Overlay will contain:
- * "target-path" or "target"
- The insertion point where the contents of the overlay will go into the
- live tree. target-path is a full path, while target is a phandle.
- * "ranges"
- The address space mapping from processor to FPGA bus(ses).
- * "firmware-name"
- Specifies the name of the FPGA image file on the firmware search
- path. The search path is described in the firmware class documentation.
- * "partial-fpga-config"
- This binding is a boolean and should be present if partial reconfiguration
- is to be done.
- * child nodes corresponding to hardware that will be loaded in this region of
- the FPGA.
-
-Device Tree Example: Full Reconfiguration without Bridges
-=========================================================
-
-Live Device Tree contains:
- fpga_mgr0: fpga-mgr@f8007000 {
- compatible = "xlnx,zynq-devcfg-1.0";
- reg = <0xf8007000 0x100>;
- interrupt-parent = <&intc>;
- interrupts = <0 8 4>;
- clocks = <&clkc 12>;
- clock-names = "ref_clk";
- syscon = <&slcr>;
- };
-
- fpga_region0: fpga-region0 {
- compatible = "fpga-region";
- fpga-mgr = <&fpga_mgr0>;
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges;
- };
-
-DT Overlay contains:
-
-/dts-v1/;
-/plugin/;
-
-&fpga_region0 {
- #address-cells = <1>;
- #size-cells = <1>;
-
- firmware-name = "zynq-gpio.bin";
-
- gpio1: gpio@40000000 {
- compatible = "xlnx,xps-gpio-1.00.a";
- reg = <0x40000000 0x10000>;
- gpio-controller;
- #gpio-cells = <0x2>;
- xlnx,gpio-width= <0x6>;
- };
-};
-
-Device Tree Example: Full Reconfiguration to add PRR's
-======================================================
-
-The base FPGA Region is specified similar to the first example above.
-
-This example programs the FPGA to have two regions that can later be partially
-configured. Each region has its own bridge in the FPGA fabric.
-
-DT Overlay contains:
-
-/dts-v1/;
-/plugin/;
-
-&fpga_region0 {
- #address-cells = <1>;
- #size-cells = <1>;
-
- firmware-name = "base.rbf";
-
- fpga-bridge@4400 {
- compatible = "altr,freeze-bridge-controller";
- reg = <0x4400 0x10>;
-
- fpga_region1: fpga-region1 {
- compatible = "fpga-region";
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges;
- };
- };
-
- fpga-bridge@4420 {
- compatible = "altr,freeze-bridge-controller";
- reg = <0x4420 0x10>;
-
- fpga_region2: fpga-region2 {
- compatible = "fpga-region";
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges;
- };
- };
-};
-
-Device Tree Example: Partial Reconfiguration
-============================================
-
-This example reprograms one of the PRR's set up in the previous example.
-
-The sequence that occurs when this overlay is similar to the above, the only
-differences are that the FPGA is partially reconfigured due to the
-"partial-fpga-config" boolean and the only bridge that is controlled during
-programming is the FPGA based bridge of fpga_region1.
-
-/dts-v1/;
-/plugin/;
-
-&fpga_region1 {
- #address-cells = <1>;
- #size-cells = <1>;
-
- firmware-name = "soc_image2.rbf";
- partial-fpga-config;
-
- gpio@10040 {
- compatible = "altr,pio-1.0";
- reg = <0x10040 0x20>;
- clocks = <0x2>;
- altr,ngpio = <0x4>;
- #gpio-cells = <0x2>;
- gpio-controller;
- };
-};
-
-Constraints
-===========
-
-It is beyond the scope of this document to fully describe all the FPGA design
-constraints required to make partial reconfiguration work[1] [2] [3], but a few
-deserve quick mention.
-
-A persona must have boundary connections that line up with those of the partion
-or region it is designed to go into.
-
-During programming, transactions through those connections must be stopped and
-the connections must be held at a fixed logic level. This can be achieved by
-FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration.
-
---
-[1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf
-[2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf
-[3] https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf
diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.yaml b/Documentation/devicetree/bindings/fpga/fpga-region.yaml
new file mode 100644
index 000000000000..55acf0ecfa3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.yaml
@@ -0,0 +1,354 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/fpga-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FPGA Region
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+
+description: |
+ CONTENTS
+ - Introduction
+ - Terminology
+ - Sequence
+ - FPGA Region
+ - Supported Use Models
+ - Constraints
+
+ Introduction
+ ============
+
+ FPGA Regions represent FPGA's and partial reconfiguration regions of FPGA's in
+ the Device Tree. FPGA Regions provide a way to program FPGAs under device tree
+ control.
+
+ The documentation hits some of the high points of FPGA usage and
+ attempts to include terminology used by both major FPGA manufacturers. This
+ document isn't a replacement for any manufacturers specifications for FPGA
+ usage.
+
+ Terminology
+ ===========
+
+ Full Reconfiguration
+ * The entire FPGA is programmed.
+
+ Partial Reconfiguration (PR)
+ * A section of an FPGA is reprogrammed while the rest of the FPGA is not
+ affected.
+ * Not all FPGA's support PR.
+
+ Partial Reconfiguration Region (PRR)
+ * Also called a "reconfigurable partition"
+ * A PRR is a specific section of an FPGA reserved for reconfiguration.
+ * A base (or static) FPGA image may create a set of PRR's that later may
+ be independently reprogrammed many times.
+ * The size and specific location of each PRR is fixed.
+ * The connections at the edge of each PRR are fixed. The image that is loaded
+ into a PRR must fit and must use a subset of the region's connections.
+ * The busses within the FPGA are split such that each region gets its own
+ branch that may be gated independently.
+
+ Persona
+ * Also called a "partial bit stream"
+ * An FPGA image that is designed to be loaded into a PRR. There may be
+ any number of personas designed to fit into a PRR, but only one at a time
+ may be loaded.
+ * A persona may create more regions.
+
+ FPGA Bridge
+ * FPGA Bridges gate bus signals between a host and FPGA.
+ * FPGA Bridges should be disabled while the FPGA is being programmed to
+ prevent spurious signals on the cpu bus and to the soft logic.
+ * FPGA bridges may be actual hardware or soft logic on an FPGA.
+ * During Full Reconfiguration, hardware bridges between the host and FPGA
+ will be disabled.
+ * During Partial Reconfiguration of a specific region, that region's bridge
+ will be used to gate the busses. Traffic to other regions is not affected.
+ * In some implementations, the FPGA Manager transparently handles gating the
+ buses, eliminating the need to show the hardware FPGA bridges in the
+ device tree.
+ * An FPGA image may create a set of reprogrammable regions, each having its
+ own bridge and its own split of the busses in the FPGA.
+
+ FPGA Manager
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+ of a host processor.
+
+ Base Image
+ * Also called the "static image"
+ * An FPGA image that is designed to do full reconfiguration of the FPGA.
+ * A base image may set up a set of partial reconfiguration regions that may
+ later be reprogrammed.
+
+ ---------------- ----------------------------------
+ | Host CPU | | FPGA |
+ | | | |
+ | ----| | ----------- -------- |
+ | | H | | |==>| Bridge0 |<==>| PRR0 | |
+ | | W | | | ----------- -------- |
+ | | | | | |
+ | | B |<=====>|<==| ----------- -------- |
+ | | R | | |==>| Bridge1 |<==>| PRR1 | |
+ | | I | | | ----------- -------- |
+ | | D | | | |
+ | | G | | | ----------- -------- |
+ | | E | | |==>| Bridge2 |<==>| PRR2 | |
+ | ----| | ----------- -------- |
+ | | | |
+ ---------------- ----------------------------------
+
+ Figure 1: An FPGA set up with a base image that created three regions. Each
+ region (PRR0-2) gets its own split of the busses that is independently gated by
+ a soft logic bridge (Bridge0-2) in the FPGA. The contents of each PRR can be
+ reprogrammed independently while the rest of the system continues to function.
+
+ Sequence
+ ========
+
+ When a DT overlay that targets an FPGA Region is applied, the FPGA Region will
+ do the following:
+
+ 1. Disable appropriate FPGA bridges.
+ 2. Program the FPGA using the FPGA manager.
+ 3. Enable the FPGA bridges.
+ 4. The Device Tree overlay is accepted into the live tree.
+ 5. Child devices are populated.
+
+ When the overlay is removed, the child nodes will be removed and the FPGA Region
+ will disable the bridges.
+
+ FPGA Region
+ ===========
+
+ FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA
+ Region brings together the elements needed to program on a running system and
+ add the child devices:
+
+ * FPGA Manager
+ * FPGA Bridges
+ * image-specific information needed to the programming.
+ * child nodes
+
+ The intended use is that a Device Tree overlay (DTO) can be used to reprogram an
+ FPGA while an operating system is running.
+
+ An FPGA Region that exists in the live Device Tree reflects the current state.
+ If the live tree shows a "firmware-name" property or child nodes under an FPGA
+ Region, the FPGA already has been programmed. A DTO that targets an FPGA Region
+ and adds the "firmware-name" property is taken as a request to reprogram the
+ FPGA. After reprogramming is successful, the overlay is accepted into the live
+ tree.
+
+ The base FPGA Region in the device tree represents the FPGA and supports full
+ reconfiguration. It must include a phandle to an FPGA Manager. The base
+ FPGA region will be the child of one of the hardware bridges (the bridge that
+ allows register access) between the cpu and the FPGA. If there are more than
+ one bridge to control during FPGA programming, the region will also contain a
+ list of phandles to the additional hardware FPGA Bridges.
+
+ For partial reconfiguration (PR), each PR region will have an FPGA Region.
+ These FPGA regions are children of FPGA bridges which are then children of the
+ base FPGA region. The "Full Reconfiguration to add PRR's" example below shows
+ this.
+
+ If an FPGA Region does not specify an FPGA Manager, it will inherit the FPGA
+ Manager specified by its ancestor FPGA Region. This supports both the case
+ where the same FPGA Manager is used for all of an FPGA as well the case where
+ a different FPGA Manager is used for each region.
+
+ FPGA Regions do not inherit their ancestor FPGA regions' bridges. This prevents
+ shutting down bridges that are upstream from the other active regions while one
+ region is getting reconfigured (see Figure 1 above). During PR, the FPGA's
+ hardware bridges remain enabled. The PR regions' bridges will be FPGA bridges
+ within the static image of the FPGA.
+
+ Supported Use Models
+ ====================
+
+ In all cases the live DT must have the FPGA Manager, FPGA Bridges (if any), and
+ a FPGA Region. The target of the Device Tree Overlay is the FPGA Region. Some
+ uses are specific to an FPGA device.
+
+ * No FPGA Bridges
+ In this case, the FPGA Manager which programs the FPGA also handles the
+ bridges behind the scenes. No FPGA Bridge devices are needed for full
+ reconfiguration.
+
+ * Full reconfiguration with hardware bridges
+ In this case, there are hardware bridges between the processor and FPGA that
+ need to be controlled during full reconfiguration. Before the overlay is
+ applied, the live DT must include the FPGA Manager, FPGA Bridges, and a
+ FPGA Region. The FPGA Region is the child of the bridge that allows
+ register access to the FPGA. Additional bridges may be listed in a
+ fpga-bridges property in the FPGA region or in the device tree overlay.
+
+ * Partial reconfiguration with bridges in the FPGA
+ In this case, the FPGA will have one or more PRR's that may be programmed
+ separately while the rest of the FPGA can remain active. To manage this,
+ bridges need to exist in the FPGA that can gate the buses going to each FPGA
+ region while the buses are enabled for other sections. Before any partial
+ reconfiguration can be done, a base FPGA image must be loaded which includes
+ PRR's with FPGA bridges. The device tree should have an FPGA region for each
+ PRR.
+
+ Constraints
+ ===========
+
+ It is beyond the scope of this document to fully describe all the FPGA design
+ constraints required to make partial reconfiguration work[1] [2] [3], but a few
+ deserve quick mention.
+
+ A persona must have boundary connections that line up with those of the partition
+ or region it is designed to go into.
+
+ During programming, transactions through those connections must be stopped and
+ the connections must be held at a fixed logic level. This can be achieved by
+ FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration.
+
+ --
+ [1] https://www.intel.com/programmable/technical-pdfs/683404.pdf
+ [2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf
+ [3] https://docs.amd.com/v/u/en-US/ug702
+
+properties:
+ $nodename:
+ pattern: "^fpga-region(@.*|-([0-9]|[1-9][0-9]+))?$"
+
+ compatible:
+ const: fpga-region
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+ "#address-cells": true
+ "#size-cells": true
+
+ config-complete-timeout-us:
+ description:
+ The maximum time in microseconds time for the FPGA to go to operating
+ mode after the region has been programmed.
+
+ encrypted-fpga-config:
+ type: boolean
+ description:
+ Set if the bitstream is encrypted.
+
+ external-fpga-config:
+ type: boolean
+ description:
+ Set if the FPGA has already been configured prior to OS boot up.
+
+ firmware-name:
+ maxItems: 1
+ description:
+ Should contain the name of an FPGA image file located on the firmware
+ search path. If this property shows up in a live device tree it indicates
+ that the FPGA has already been programmed with this image.
+ If this property is in an overlay targeting an FPGA region, it is
+ a request to program the FPGA with that image.
+
+ fpga-bridges:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Should contain a list of phandles to FPGA Bridges that must be
+ controlled during FPGA programming along with the parent FPGA bridge.
+ This property is optional if the FPGA Manager handles the bridges.
+ If the fpga-region is the child of an fpga-bridge, the list should not
+ contain the parent bridge.
+
+ fpga-mgr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Should contain a phandle to an FPGA Manager. Child FPGA Regions
+ inherit this property from their ancestor regions. An fpga-mgr property
+ in a region will override any inherited FPGA manager.
+
+ partial-fpga-config:
+ type: boolean
+ description:
+ Set if partial reconfiguration is to be done, otherwise full
+ reconfiguration is done.
+
+ region-freeze-timeout-us:
+ description:
+ The maximum time in microseconds to wait for bridges to successfully
+ become disabled before the region has been programmed.
+
+ region-unfreeze-timeout-us:
+ description:
+ The maximum time in microseconds to wait for bridges to successfully
+ become enabled after the region has been programmed.
+
+required:
+ - compatible
+ - fpga-mgr
+
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ /*
+ * Full Reconfiguration without Bridges with DT overlay
+ */
+ fpga_region0: fpga-region@0 {
+ compatible = "fpga-region";
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fpga-mgr = <&fpga_mgr0>;
+ ranges = <0x10000000 0x20000000 0x10000000>;
+
+ /* DT Overlay contains: &fpga_region0 */
+ firmware-name = "zynq-gpio.bin";
+ gpio@40000000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = <0x40000000 0x10000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ clocks = <&clk>;
+ };
+ };
+
+ - |
+ /*
+ * Partial reconfiguration with bridge
+ */
+ fpga_region1: fpga-region@0 {
+ compatible = "fpga-region";
+ reg = <0 0>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fpga-mgr = <&fpga_mgr1>;
+ fpga-bridges = <&fpga_bridge1>;
+ partial-fpga-config;
+
+ /* DT Overlay contains: &fpga_region1 */
+ firmware-name = "zynq-gpio-partial.bin";
+ clk: clock {
+ compatible = "fixed-factor-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ axi {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ gpio@40000000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = <0x40000000 0x10000>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ clocks = <&clk>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml
new file mode 100644
index 000000000000..6e536d6b28a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/intel,stratix10-soc-fpga-mgr.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Stratix10 SoC FPGA Manager
+
+maintainers:
+ - Mahesh Rao <mahesh.rao@altera.com>
+ - Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+ - Niravkumar L Rabara <nirav.rabara@altera.com>
+
+description:
+ The Intel Stratix10 SoC consists of a 64-bit quad-core ARM Cortex A53 hard
+ processor system (HPS) and a Secure Device Manager (SDM). The Stratix10
+ SoC FPGA Manager driver is used to configure/reconfigure the FPGA fabric
+ on the die.The driver communicates with SDM/ATF via the stratix10-svc
+ platform driver for performing its operations.
+
+properties:
+ compatible:
+ enum:
+ - intel,stratix10-soc-fpga-mgr
+ - intel,agilex-soc-fpga-mgr
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ fpga-mgr {
+ compatible = "intel,stratix10-soc-fpga-mgr";
+ };
diff --git a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt
deleted file mode 100644
index 0f874137ca46..000000000000
--- a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Intel Stratix10 SoC FPGA Manager
-
-Required properties:
-The fpga_mgr node has the following mandatory property, must be located under
-firmware/svc node.
-
-- compatible : should contain "intel,stratix10-soc-fpga-mgr" or
- "intel,agilex-soc-fpga-mgr"
-
-Example:
-
- firmware {
- svc {
- fpga_mgr: fpga-mgr {
- compatible = "intel,stratix10-soc-fpga-mgr";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/fpga/lattice,ice40-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/lattice,ice40-fpga-mgr.yaml
new file mode 100644
index 000000000000..5121c6120785
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice,ice40-fpga-mgr.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/lattice,ice40-fpga-mgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lattice iCE40 FPGA Manager
+
+maintainers:
+ - Joel Holdsworth <joel@airwebreathe.org.uk>
+
+properties:
+ compatible:
+ const: lattice,ice40-fpga-mgr
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ minimum: 1000000
+ maximum: 25000000
+
+ cdone-gpios:
+ maxItems: 1
+ description: GPIO input connected to CDONE pin
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ Active-low GPIO output connected to CRESET_B pin. Note that unless the
+ GPIO is held low during startup, the FPGA will enter Master SPI mode and
+ drive SCK with a clock signal potentially jamming other devices on the bus
+ until the firmware is loaded.
+
+required:
+ - compatible
+ - reg
+ - spi-max-frequency
+ - cdone-gpios
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fpga@0 {
+ compatible = "lattice,ice40-fpga-mgr";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fpga/lattice,sysconfig.yaml b/Documentation/devicetree/bindings/fpga/lattice,sysconfig.yaml
new file mode 100644
index 000000000000..164331eb6275
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice,sysconfig.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/lattice,sysconfig.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lattice Slave SPI sysCONFIG FPGA manager
+
+maintainers:
+ - Vladimir Georgiev <v.georgiev@metrotek.ru>
+
+description: |
+ Lattice sysCONFIG port, which is used for FPGA configuration, among others,
+ have Slave Serial Peripheral Interface. Only full reconfiguration is
+ supported.
+
+ Programming of ECP5 is done by writing uncompressed bitstream image in .bit
+ format into FPGA's SRAM configuration memory.
+
+properties:
+ compatible:
+ enum:
+ - lattice,sysconfig-ecp5
+
+ reg:
+ maxItems: 1
+
+ program-gpios:
+ description:
+ A GPIO line connected to PROGRAMN (active low) pin of the device.
+ Initiates configuration sequence.
+ maxItems: 1
+
+ init-gpios:
+ description:
+ A GPIO line connected to INITN (active low) pin of the device.
+ Indicates that the FPGA is ready to be configured.
+ maxItems: 1
+
+ done-gpios:
+ description:
+ A GPIO line connected to DONE (active high) pin of the device.
+ Indicates that the configuration sequence is complete.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: lattice,sysconfig-ecp5
+ then:
+ properties:
+ spi-max-frequency:
+ maximum: 60000000
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fpga-mgr@0 {
+ compatible = "lattice,sysconfig-ecp5";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ program-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
+ init-gpios = <&gpio3 3 GPIO_ACTIVE_LOW>;
+ done-gpios = <&gpio3 2 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
deleted file mode 100644
index 4dc412437b08..000000000000
--- a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Lattice iCE40 FPGA Manager
-
-Required properties:
-- compatible: Should contain "lattice,ice40-fpga-mgr"
-- reg: SPI chip select
-- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
-- cdone-gpios: GPIO input connected to CDONE pin
-- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
- that unless the GPIO is held low during startup, the
- FPGA will enter Master SPI mode and drive SCK with a
- clock signal potentially jamming other devices on the
- bus until the firmware is loaded.
-
-Example:
- fpga: fpga@0 {
- compatible = "lattice,ice40-fpga-mgr";
- reg = <0>;
- spi-max-frequency = <1000000>;
- cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
index aee45cb15592..a157eecfb5fc 100644
--- a/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
+++ b/Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip Polarfire FPGA manager.
maintainers:
- - Ivan Bornyakov <i.bornyakov@metrotek.ru>
+ - Vladimir Georgiev <v.georgiev@metrotek.ru>
description:
Device Tree Bindings for Microchip Polarfire FPGA Manager using slave SPI to
@@ -22,13 +22,14 @@ properties:
description: SPI chip select
maxItems: 1
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
deleted file mode 100644
index 0acdfa6d62a4..000000000000
--- a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Xilinx LogiCORE Partial Reconfig Decoupler Softcore
-
-The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
-decouplers / fpga bridges.
-The controller can decouple/disable the bridges which prevents signal
-changes from passing through the bridge. The controller can also
-couple / enable the bridges which allows traffic to pass through the
-bridge normally.
-
-Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown manager
-Softcore is compatible with the Xilinx LogiCORE pr-decoupler.
-
-The Dynamic Function eXchange AXI shutdown manager prevents AXI traffic
-from passing through the bridge. The controller safely handles AXI4MM
-and AXI4-Lite interfaces on a Reconfigurable Partition when it is
-undergoing dynamic reconfiguration, preventing the system deadlock
-that can occur if AXI transactions are interrupted by DFX
-
-The Driver supports only MMIO handling. A PR region can have multiple
-PR Decouplers which can be handled independently or chained via decouple/
-decouple_status signals.
-
-Required properties:
-- compatible : Should contain "xlnx,pr-decoupler-1.00" followed by
- "xlnx,pr-decoupler" or
- "xlnx,dfx-axi-shutdown-manager-1.00" followed by
- "xlnx,dfx-axi-shutdown-manager"
-- regs : base address and size for decoupler module
-- clocks : input clock to IP
-- clock-names : should contain "aclk"
-
-See Documentation/devicetree/bindings/fpga/fpga-region.txt and
-Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
-
-Example:
-Partial Reconfig Decoupler:
- fpga-bridge@100000450 {
- compatible = "xlnx,pr-decoupler-1.00",
- "xlnx-pr-decoupler";
- regs = <0x10000045 0x10>;
- clocks = <&clkc 15>;
- clock-names = "aclk";
- bridge-enable = <0>;
- };
-
-Dynamic Function eXchange AXI shutdown manager:
- fpga-bridge@100000450 {
- compatible = "xlnx,dfx-axi-shutdown-manager-1.00",
- "xlnx,dfx-axi-shutdown-manager";
- regs = <0x10000045 0x10>;
- clocks = <&clkc 15>;
- clock-names = "aclk";
- bridge-enable = <0>;
- };
diff --git a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt
deleted file mode 100644
index 5ef659c1394d..000000000000
--- a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Xilinx Slave Serial SPI FPGA Manager
-
-Xilinx Spartan-6 and 7 Series FPGAs support a method of loading the
-bitstream over what is referred to as "slave serial" interface.
-The slave serial link is not technically SPI, and might require extra
-circuits in order to play nicely with other SPI slaves on the same bus.
-
-See:
-- https://www.xilinx.com/support/documentation/user_guides/ug380.pdf
-- https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
-- https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf
-
-Required properties:
-- compatible: should contain "xlnx,fpga-slave-serial"
-- reg: spi chip select of the FPGA
-- prog_b-gpios: config pin (referred to as PROGRAM_B in the manual)
-- done-gpios: config status pin (referred to as DONE in the manual)
-
-Optional properties:
-- init-b-gpios: initialization status and configuration error pin
- (referred to as INIT_B in the manual)
-
-Example for full FPGA configuration:
-
- fpga-region0 {
- compatible = "fpga-region";
- fpga-mgr = <&fpga_mgr_spi>;
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- };
-
- spi1: spi@10680 {
- compatible = "marvell,armada-xp-spi", "marvell,orion-spi";
- pinctrl-0 = <&spi0_pins>;
- pinctrl-names = "default";
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <1>;
- interrupts = <92>;
- clocks = <&coreclk 0>;
-
- fpga_mgr_spi: fpga-mgr@0 {
- compatible = "xlnx,fpga-slave-serial";
- spi-max-frequency = <60000000>;
- spi-cpha;
- reg = <0>;
- prog_b-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
- init-b-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>;
- done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
- };
- };
diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml
index 29daca4be47f..04dcadc2c20e 100644
--- a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml
+++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/fpga/xilinx-zynq-fpga-mgr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx Zynq FPGA Manager Device Tree Bindings
+title: Xilinx Zynq FPGA Manager
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,fpga-selectmap.yaml b/Documentation/devicetree/bindings/fpga/xlnx,fpga-selectmap.yaml
new file mode 100644
index 000000000000..05775746fd70
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,fpga-selectmap.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/xlnx,fpga-selectmap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx SelectMAP FPGA interface
+
+maintainers:
+ - Charles Perry <charles.perry@savoirfairelinux.com>
+
+description: |
+ Xilinx 7 Series FPGAs support a method of loading the bitstream over a
+ parallel port named the SelectMAP interface in the documentation. Only
+ the x8 mode is supported where data is loaded at one byte per rising edge of
+ the clock, with the MSB of each byte presented to the D0 pin.
+
+ Datasheets:
+ https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
+
+allOf:
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,fpga-xc7s-selectmap
+ - xlnx,fpga-xc7a-selectmap
+ - xlnx,fpga-xc7k-selectmap
+ - xlnx,fpga-xc7v-selectmap
+
+ reg:
+ description:
+ At least 1 byte of memory mapped IO
+ maxItems: 1
+
+ prog-gpios:
+ description:
+ config pin (referred to as PROGRAM_B in the manual)
+ maxItems: 1
+
+ done-gpios:
+ description:
+ config status pin (referred to as DONE in the manual)
+ maxItems: 1
+
+ init-gpios:
+ description:
+ initialization status and configuration error pin
+ (referred to as INIT_B in the manual)
+ maxItems: 1
+
+ csi-gpios:
+ description:
+ chip select pin (referred to as CSI_B in the manual)
+ Optional gpio for if the bus controller does not provide a chip select.
+ maxItems: 1
+
+ rdwr-gpios:
+ description:
+ read/write select pin (referred to as RDWR_B in the manual)
+ Optional gpio for if the bus controller does not provide this pin.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - prog-gpios
+ - done-gpios
+ - init-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ fpga-mgr@8000000 {
+ compatible = "xlnx,fpga-xc7s-selectmap";
+ reg = <0x8000000 0x4>;
+ prog-gpios = <&gpio5 5 GPIO_ACTIVE_LOW>;
+ init-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ done-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+ csi-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ rdwr-gpios = <&gpio3 10 GPIO_ACTIVE_LOW>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml b/Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml
new file mode 100644
index 000000000000..614d86ad825f
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/xlnx,fpga-slave-serial.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Slave Serial SPI FPGA
+
+maintainers:
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
+
+description: |
+ Xilinx Spartan-6 and 7 Series FPGAs support a method of loading the bitstream
+ over what is referred to as slave serial interface.The slave serial link is
+ not technically SPI, and might require extra circuits in order to play nicely
+ with other SPI slaves on the same bus.
+
+ Datasheets:
+ https://www.xilinx.com/support/documentation/user_guides/ug380.pdf
+ https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf
+ https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,fpga-slave-serial
+
+ spi-cpha: true
+
+ spi-max-frequency:
+ maximum: 60000000
+
+ reg:
+ maxItems: 1
+
+ prog_b-gpios:
+ description:
+ config pin (referred to as PROGRAM_B in the manual)
+ maxItems: 1
+
+ done-gpios:
+ description:
+ config status pin (referred to as DONE in the manual)
+ maxItems: 1
+
+ init-b-gpios:
+ description:
+ initialization status and configuration error pin
+ (referred to as INIT_B in the manual)
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - prog_b-gpios
+ - done-gpios
+ - init-b-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fpga_mgr_spi: fpga-mgr@0 {
+ compatible = "xlnx,fpga-slave-serial";
+ spi-max-frequency = <60000000>;
+ spi-cpha;
+ reg = <0>;
+ prog_b-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
+ init-b-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>;
+ done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml b/Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml
new file mode 100644
index 000000000000..5bf731f9d99a
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/xlnx,pr-decoupler.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx LogiCORE Partial Reconfig Decoupler/AXI shutdown manager Softcore
+
+maintainers:
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
+
+allOf:
+ - $ref: fpga-bridge.yaml#
+
+description: |
+ The Xilinx LogiCORE Partial Reconfig(PR) Decoupler manages one or more
+ decouplers/fpga bridges. The controller can decouple/disable the bridges
+ which prevents signal changes from passing through the bridge. The controller
+ can also couple / enable the bridges which allows traffic to pass through the
+ bridge normally.
+ Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown manager Softcore
+ is compatible with the Xilinx LogiCORE pr-decoupler. The Dynamic Function
+ eXchange AXI shutdown manager prevents AXI traffic from passing through the
+ bridge. The controller safely handles AXI4MM and AXI4-Lite interfaces on a
+ Reconfigurable Partition when it is undergoing dynamic reconfiguration,
+ preventing the system deadlock that can occur if AXI transactions are
+ interrupted by DFX.
+ Please refer to fpga-region.txt and fpga-bridge.txt in this directory for
+ common binding part and usage.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: xlnx,pr-decoupler-1.00
+ - const: xlnx,pr-decoupler
+ - items:
+ - const: xlnx,dfx-axi-shutdown-manager-1.00
+ - const: xlnx,dfx-axi-shutdown-manager
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: aclk
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fpga-bridge@100000450 {
+ compatible = "xlnx,pr-decoupler-1.00", "xlnx,pr-decoupler";
+ reg = <0x10000045 0x10>;
+ clocks = <&clkc 15>;
+ clock-names = "aclk";
+ };
+...
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
index ac6a207278d5..41b368d54557 100644
--- a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
+++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx Versal FPGA driver.
maintainers:
- - Nava kishore Manne <nava.manne@xilinx.com>
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
description: |
Device Tree Versal FPGA bindings for the Versal SoC, controlled
@@ -26,8 +26,8 @@ additionalProperties: false
examples:
- |
- versal_fpga: versal_fpga {
- compatible = "xlnx,versal-fpga";
+ versal_fpga: versal-fpga {
+ compatible = "xlnx,versal-fpga";
};
...
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml
index 6cd2bdc06b5f..1390ae103b0b 100644
--- a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml
+++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx Zynq Ultrascale MPSoC FPGA Manager Device Tree Bindings
+title: Xilinx Zynq Ultrascale MPSoC FPGA Manager
maintainers:
- - Nava kishore Manne <navam@xilinx.com>
+ - Nava kishore Manne <nava.kishore.manne@amd.com>
description: |
Device Tree Bindings for Zynq Ultrascale MPSoC FPGA Manager.
diff --git a/Documentation/devicetree/bindings/fsi/aspeed,ast2400-cf-fsi-master.yaml b/Documentation/devicetree/bindings/fsi/aspeed,ast2400-cf-fsi-master.yaml
new file mode 100644
index 000000000000..690b6c936f18
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/aspeed,ast2400-cf-fsi-master.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/aspeed,ast2400-cf-fsi-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASpeed ColdFire offloaded GPIO-based FSI master
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+allOf:
+ - $ref: /schemas/fsi/fsi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-cf-fsi-master
+ - aspeed,ast2500-cf-fsi-master
+
+ clock-gpios:
+ maxItems: 1
+ description: GPIO for FSI clock
+
+ data-gpios:
+ maxItems: 1
+ description: GPIO for FSI data signal
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO for enable signal
+
+ trans-gpios:
+ maxItems: 1
+ description: GPIO for voltage translator enable
+
+ mux-gpios:
+ maxItems: 1
+ description:
+ GPIO for pin multiplexing with other functions (eg, external FSI masters)
+
+ memory-region:
+ maxItems: 1
+ description:
+ Reference to the reserved memory for the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500.
+
+ aspeed,cvic:
+ description: Reference to the CVIC node.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ aspeed,sram:
+ description: Reference to the SRAM node.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - clock-gpios
+ - data-gpios
+ - enable-gpios
+ - trans-gpios
+ - mux-gpios
+ - memory-region
+ - aspeed,cvic
+ - aspeed,sram
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fsi-master {
+ compatible = "aspeed,ast2500-cf-fsi-master";
+ clock-gpios = <&gpio 0>;
+ data-gpios = <&gpio 1>;
+ enable-gpios = <&gpio 2>;
+ trans-gpios = <&gpio 3>;
+ mux-gpios = <&gpio 4>;
+ memory-region = <&coldfire_memory>;
+ aspeed,cvic = <&cvic>;
+ aspeed,sram = <&sram>;
+ };
diff --git a/Documentation/devicetree/bindings/fsi/aspeed,ast2600-fsi-master.yaml b/Documentation/devicetree/bindings/fsi/aspeed,ast2600-fsi-master.yaml
new file mode 100644
index 000000000000..dfcc2fafa68d
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/aspeed,ast2600-fsi-master.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/aspeed,ast2600-fsi-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed FSI master
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The AST2600 and later contain two identical FSI masters. They share a
+ clock and have a separate interrupt line and output pins.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2600-fsi-master
+ - aspeed,ast2700-fsi-master
+
+ clocks:
+ maxItems: 1
+
+ cfam-reset-gpios:
+ maxItems: 1
+ description:
+ Output GPIO pin for CFAM reset
+
+ fsi-routing-gpios:
+ maxItems: 1
+ description:
+ Output GPIO pin for setting the FSI mux (internal or cabled)
+
+ fsi-mux-gpios:
+ maxItems: 1
+ description:
+ Input GPIO pin for detecting the desired FSI mux state
+
+ interrupts:
+ maxItems: 1
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - aspeed,ast2600-fsi-master
+then:
+ properties:
+ reg:
+ maxItems: 1
+else:
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: OPB control registers
+ - description: FSI controller registers
+ - description: FSI link address space
+ reg-names:
+ items:
+ - const: opb
+ - const: ctrl
+ - const: fsi
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+allOf:
+ - $ref: fsi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ #include <dt-bindings/gpio/aspeed-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ fsi-master@1e79b000 {
+ compatible = "aspeed,ast2600-fsi-master";
+ reg = <0x1e79b000 0x94>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fsi1_default>;
+ clocks = <&syscon ASPEED_CLK_GATE_FSICLK>;
+ fsi-routing-gpios = <&gpio0 ASPEED_GPIO(Q, 7) GPIO_ACTIVE_HIGH>;
+ fsi-mux-gpios = <&gpio0 ASPEED_GPIO(B, 0) GPIO_ACTIVE_HIGH>;
+ cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+ };
+ };
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ fsi-master@21800000 {
+ compatible = "aspeed,ast2700-fsi-master";
+ reg = <0x0 0x21800000 0x0 0x100>,
+ <0x0 0x21000000 0x0 0x1000>,
+ <0x0 0x20000000 0x0 0x1000000>;
+ reg-names = "opb", "ctrl", "fsi";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupts-extended = <&intc 6>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fsi0_default>;
+ clocks = <&syscon 40>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fsi/fsi-controller.yaml b/Documentation/devicetree/bindings/fsi/fsi-controller.yaml
new file mode 100644
index 000000000000..ffe191921b26
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-controller.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/fsi-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FSI Controller Common Properties
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ FSI (FRU (Field Replaceable Unit) Service Interface) is a two wire bus. The
+ FSI bus is connected to a CFAM (Common FRU Access Macro) which contains
+ various engines such as I2C controllers, SPI controllers, etc.
+
+properties:
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 0
+
+ '#interrupt-cells':
+ const: 1
+
+ bus-frequency:
+ minimum: 1
+ maximum: 200000000
+
+ interrupt-controller: true
+
+ no-scan-on-init:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The FSI controller cannot scan the bus during initialization.
+
+patternProperties:
+ "cfam@[0-9a-f],[0-9a-f]":
+ type: object
+ properties:
+ chip-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Processor index, a global unique chip ID which is used to identify
+ the physical location of the chip in a system specific way.
+
+ bus-frequency:
+ minimum: 1
+ maximum: 100000000
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ required:
+ - reg
+
+ additionalProperties: true
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt b/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt
deleted file mode 100644
index 9853fefff5d8..000000000000
--- a/Documentation/devicetree/bindings/fsi/fsi-master-aspeed.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Device-tree bindings for AST2600 FSI master
--------------------------------------------
-
-The AST2600 contains two identical FSI masters. They share a clock and have a
-separate interrupt line and output pins.
-
-Required properties:
- - compatible: "aspeed,ast2600-fsi-master"
- - reg: base address and length
- - clocks: phandle and clock number
- - interrupts: platform dependent interrupt description
- - pinctrl-0: phandle to pinctrl node
- - pinctrl-names: pinctrl state
-
-Optional properties:
- - cfam-reset-gpios: GPIO for CFAM reset
-
- - fsi-routing-gpios: GPIO for setting the FSI mux (internal or cabled)
- - fsi-mux-gpios: GPIO for detecting the desired FSI mux state
-
-
-Examples:
-
- fsi-master {
- compatible = "aspeed,ast2600-fsi-master", "fsi-master";
- reg = <0x1e79b000 0x94>;
- interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fsi1_default>;
- clocks = <&syscon ASPEED_CLK_GATE_FSICLK>;
-
- fsi-routing-gpios = <&gpio0 ASPEED_GPIO(Q, 7) GPIO_ACTIVE_HIGH>;
- fsi-mux-gpios = <&gpio0 ASPEED_GPIO(B, 0) GPIO_ACTIVE_HIGH>;
-
- cfam-reset-gpios = <&gpio0 ASPEED_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
deleted file mode 100644
index 3dc752db748b..000000000000
--- a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
-------------------------------------------------------------------------
-
-Required properties:
- - compatible =
- "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
- or
- "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
-
- - clock-gpios = <gpio-descriptor>; : GPIO for FSI clock
- - data-gpios = <gpio-descriptor>; : GPIO for FSI data signal
- - enable-gpios = <gpio-descriptor>; : GPIO for enable signal
- - trans-gpios = <gpio-descriptor>; : GPIO for voltage translator enable
- - mux-gpios = <gpio-descriptor>; : GPIO for pin multiplexing with other
- functions (eg, external FSI masters)
- - memory-region = <phandle>; : Reference to the reserved memory for
- the ColdFire. Must be 2M aligned on
- AST2400 and 1M aligned on AST2500
- - aspeed,sram = <phandle>; : Reference to the SRAM node.
- - aspeed,cvic = <phandle>; : Reference to the CVIC node.
-
-Examples:
-
- fsi-master {
- compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
-
- clock-gpios = <&gpio 0>;
- data-gpios = <&gpio 1>;
- enable-gpios = <&gpio 2>;
- trans-gpios = <&gpio 3>;
- mux-gpios = <&gpio 4>;
-
- memory-region = <&coldfire_memory>;
- aspeed,sram = <&sram>;
- aspeed,cvic = <&cvic>;
- }
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
deleted file mode 100644
index 1e442450747f..000000000000
--- a/Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Device-tree bindings for gpio-based FSI master driver
------------------------------------------------------
-
-Required properties:
- - compatible = "fsi-master-gpio";
- - clock-gpios = <gpio-descriptor>; : GPIO for FSI clock
- - data-gpios = <gpio-descriptor>; : GPIO for FSI data signal
-
-Optional properties:
- - enable-gpios = <gpio-descriptor>; : GPIO for enable signal
- - trans-gpios = <gpio-descriptor>; : GPIO for voltage translator enable
- - mux-gpios = <gpio-descriptor>; : GPIO for pin multiplexing with other
- functions (eg, external FSI masters)
- - no-gpio-delays; : Don't add extra delays between GPIO
- accesses. This is useful when the HW
- GPIO block is running at a low enough
- frequency.
-
-Examples:
-
- fsi-master {
- compatible = "fsi-master-gpio", "fsi-master";
- clock-gpios = <&gpio 0>;
- data-gpios = <&gpio 1>;
- enable-gpios = <&gpio 2>;
- trans-gpios = <&gpio 3>;
- mux-gpios = <&gpio 4>;
- }
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-gpio.yaml b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.yaml
new file mode 100644
index 000000000000..21bfbad595b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-gpio.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/fsi-master-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: fsi-master-gpio
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+allOf:
+ - $ref: /schemas/fsi/fsi-controller.yaml
+
+properties:
+ compatible:
+ items:
+ - const: fsi-master-gpio
+
+ clock-gpios:
+ description: GPIO for FSI clock
+ maxItems: 1
+
+ data-gpios:
+ description: GPIO for FSI data signal
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO for enable signal
+ maxItems: 1
+
+ trans-gpios:
+ description: GPIO for voltage translator enable
+ maxItems: 1
+
+ mux-gpios:
+ description: GPIO for pin multiplexing with other functions (eg, external
+ FSI masters)
+ maxItems: 1
+
+ no-gpio-delays:
+ description:
+ Don't add extra delays between GPIO accesses. This is useful when the HW
+ GPIO block is running at a low enough frequency.
+ type: boolean
+
+required:
+ - compatible
+ - clock-gpios
+ - data-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fsi-master {
+ compatible = "fsi-master-gpio";
+ clock-gpios = <&gpio 0>;
+ data-gpios = <&gpio 1>;
+ enable-gpios = <&gpio 2>;
+ trans-gpios = <&gpio 3>;
+ mux-gpios = <&gpio 4>;
+ };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml
index e2ca0b000471..ad5c83f48425 100644
--- a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml
+++ b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml
@@ -9,11 +9,10 @@ title: IBM FSI-attached SPI controllers
maintainers:
- Eddie James <eajames@linux.ibm.com>
-description: |
+description:
This binding describes an FSI CFAM engine called the FSI2SPI. Therefore this
- node will always be a child of an FSI CFAM node; see fsi.txt for details on
- FSI slave and CFAM nodes. This FSI2SPI engine provides access to a number of
- SPI controllers.
+ node will always be a child of an FSI CFAM node. This FSI2SPI engine provides
+ access to a number of SPI controllers.
properties:
compatible:
@@ -24,6 +23,17 @@ properties:
items:
- description: FSI slave address
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^spi@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/spi/ibm,spi-fsi.yaml
+
required:
- compatible
- reg
@@ -35,4 +45,22 @@ examples:
fsi2spi@1c00 {
compatible = "ibm,fsi2spi";
reg = <0x1c00 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi@0 {
+ compatible = "ibm,spi-fsi";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ compatible = "atmel,at25";
+ reg = <0>;
+ address-width = <24>;
+ pagesize = <256>;
+ size = <0x80000>;
+ spi-max-frequency = <1000000>;
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml b/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml
new file mode 100644
index 000000000000..e49ace3ca339
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,i2cr-fsi-master.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/ibm,i2cr-fsi-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM I2C Responder virtual FSI master
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description: |
+ The I2C Responder (I2CR) is a an I2C device that's connected to an FSI CFAM
+ (see fsi.txt). The I2CR translates I2C bus operations to FSI CFAM reads and
+ writes or SCOM operations, thereby acting as an FSI master.
+
+properties:
+ compatible:
+ enum:
+ - ibm,i2cr-fsi-master
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: fsi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2cr@20 {
+ compatible = "ibm,i2cr-fsi-master";
+ reg = <0x20>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-fsi-controller.yaml b/Documentation/devicetree/bindings/fsi/ibm,p9-fsi-controller.yaml
new file mode 100644
index 000000000000..29ea80ff915e
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-fsi-controller.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/ibm,p9-fsi-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM FSI-attached FSI Hub Controller
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The FSI Hub Controller is an FSI controller, providing a number of FSI links,
+ located on a CFAM. Therefore this node will always be a child of an FSI CFAM
+ node.
+
+properties:
+ compatible:
+ enum:
+ - ibm,p9-fsi-controller
+
+ reg:
+ items:
+ - description: FSI slave address
+
+allOf:
+ - $ref: fsi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fsi@3400 {
+ compatible = "ibm,p9-fsi-controller";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cfam@0,0 {
+ reg = <0 0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ chip-id = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
deleted file mode 100644
index e73358075a90..000000000000
--- a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Device-tree bindings for FSI-attached POWER9/POWER10 On-Chip Controller (OCC)
------------------------------------------------------------------------------
-
-This is the binding for the P9 or P10 On-Chip Controller accessed over FSI from
-a service processor. See fsi.txt for details on bindings for FSI slave and CFAM
-nodes. The OCC is not an FSI slave device itself, rather it is accessed
-through the SBE FIFO.
-
-Required properties:
- - compatible = "ibm,p9-occ" or "ibm,p10-occ"
-
-Examples:
-
- occ {
- compatible = "ibm,p9-occ";
- };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml
new file mode 100644
index 000000000000..537eac70447c
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/ibm,p9-occ.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM FSI-attached On-Chip Controller (OCC)
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The POWER processor On-Chip Controller (OCC) helps manage power and
+ thermals for the system, accessed through the FSI-attached SBEFIFO
+ from a service processor.
+
+properties:
+ compatible:
+ enum:
+ - ibm,p9-occ
+ - ibm,p10-occ
+
+ hwmon:
+ type: object
+ $ref: /schemas/hwmon/ibm,occ-hwmon.yaml
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ occ {
+ compatible = "ibm,p9-occ";
+
+ hwmon {
+ compatible = "ibm,p9-occ-hwmon";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.yaml b/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.yaml
new file mode 100644
index 000000000000..3cd966fb3c0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/ibm,p9-sbefifo.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM FSI-attached SBEFIFO engine
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The SBEFIFO is an FSI CFAM engine that provides an interface to the
+ POWER processor Self Boot Engine (SBE). This node will always be a child
+ of an FSI CFAM node.
+
+properties:
+ compatible:
+ enum:
+ - ibm,p9-sbefifo
+ - ibm,odyssey-sbefifo
+
+ reg:
+ items:
+ - description: FSI slave address
+
+ occ:
+ type: object
+ $ref: ibm,p9-occ.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ fsi-slave-engine@2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+
+ occ {
+ compatible = "ibm,p9-occ";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml b/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml
new file mode 100644
index 000000000000..b106f5212ea9
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fsi/ibm,p9-scom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM FSI-attached SCOM engine
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The SCOM engine is an interface to the POWER processor PIB (Pervasive
+ Interconnect Bus). This node will always be a child of an FSI CFAM node.
+
+properties:
+ compatible:
+ enum:
+ - ibm,fsi2pib
+ - ibm,p9-scom
+ - ibm,i2cr-scom
+
+ reg:
+ items:
+ - description: FSI slave address
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ scom@1000 {
+ compatible = "ibm,p9-scom";
+ reg = <0x1000 0x400>;
+ };
diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml
index 481901269872..02f0b0462377 100644
--- a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml
+++ b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml
@@ -44,8 +44,7 @@ properties:
items:
- const: fuse
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
diff --git a/Documentation/devicetree/bindings/gnss/brcm,bcm4751.yaml b/Documentation/devicetree/bindings/gnss/brcm,bcm4751.yaml
index e62b30386ac2..089166089498 100644
--- a/Documentation/devicetree/bindings/gnss/brcm,bcm4751.yaml
+++ b/Documentation/devicetree/bindings/gnss/brcm,bcm4751.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gnss/brcm,bcm4751.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM4751 family GNSS Receiver Device Tree Bindings
+title: Broadcom BCM4751 family GNSS Receiver
maintainers:
- Johan Hovold <johan@kernel.org>
@@ -18,6 +18,7 @@ description:
allOf:
- $ref: gnss-common.yaml#
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gnss/gnss-common.yaml b/Documentation/devicetree/bindings/gnss/gnss-common.yaml
index 963b926e30a7..354c0524089c 100644
--- a/Documentation/devicetree/bindings/gnss/gnss-common.yaml
+++ b/Documentation/devicetree/bindings/gnss/gnss-common.yaml
@@ -31,15 +31,9 @@ properties:
maxItems: 1
timepulse-gpios:
- description: When a timepulse is provided to the GNSS device using a
- GPIO line, this is used.
+ description: Timepulse signal
maxItems: 1
- current-speed:
- description: The baudrate in bits per second of the device as it comes
- online, current active speed.
- $ref: /schemas/types.yaml#/definitions/uint32
-
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/gnss/mediatek.yaml b/Documentation/devicetree/bindings/gnss/mediatek.yaml
index 45cf01b27700..2b9e5be4ebf3 100644
--- a/Documentation/devicetree/bindings/gnss/mediatek.yaml
+++ b/Documentation/devicetree/bindings/gnss/mediatek.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gnss/mediatek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek GNSS Receiver Device Tree Bindings
+title: Mediatek GNSS Receiver
maintainers:
- Johan Hovold <johan@kernel.org>
@@ -15,6 +15,7 @@ description:
allOf:
- $ref: gnss-common.yaml#
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.yaml b/Documentation/devicetree/bindings/gnss/sirfstar.yaml
index 991599cdaa6b..7e5da89a5ad7 100644
--- a/Documentation/devicetree/bindings/gnss/sirfstar.yaml
+++ b/Documentation/devicetree/bindings/gnss/sirfstar.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gnss/sirfstar.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SiRFstar GNSS Receiver Device Tree Bindings
+title: SiRFstar GNSS Receiver
maintainers:
- Johan Hovold <johan@kernel.org>
@@ -21,6 +21,7 @@ description:
allOf:
- $ref: gnss-common.yaml#
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
index 35a760cfd343..b349b7bc0412 100644
--- a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
+++ b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
@@ -4,23 +4,28 @@
$id: http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: U-blox GNSS Receiver Device Tree Bindings
+title: u-blox GNSS receiver
allOf:
- $ref: gnss-common.yaml#
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
maintainers:
- Johan Hovold <johan@kernel.org>
description: >
- The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
+ The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
properties:
compatible:
- enum:
- - u-blox,neo-6m
- - u-blox,neo-8
- - u-blox,neo-m8
+ oneOf:
+ - enum:
+ - u-blox,neo-6m
+ - u-blox,neo-8
+ - u-blox,neo-m8
+ - items:
+ - const: u-blox,neo-m9
+ - const: u-blox,neo-m8
reg:
description: >
@@ -28,6 +33,12 @@ properties:
port or the USB host-controller port to which this device is attached,
depending on the bus used. Required for the DDC, SPI or USB busses.
+ reset-gpios:
+ maxItems: 1
+
+ safeboot-gpios:
+ maxItems: 1
+
vcc-supply:
description: >
Main voltage regulator
@@ -49,10 +60,14 @@ unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
+
serial {
gnss {
compatible = "u-blox,neo-8";
v-bckp-supply = <&gnss_v_bckp_reg>;
vcc-supply = <&gnss_vcc_reg>;
+ reset-gpios = <&gpio 1 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+ safeboot-gpios = <&gpio 2 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
};
};
diff --git a/Documentation/devicetree/bindings/goldfish/pipe.txt b/Documentation/devicetree/bindings/goldfish/pipe.txt
index e417a31a1ee3..5637ce701788 100644
--- a/Documentation/devicetree/bindings/goldfish/pipe.txt
+++ b/Documentation/devicetree/bindings/goldfish/pipe.txt
@@ -1,6 +1,6 @@
Android Goldfish QEMU Pipe
-Andorid pipe virtual device generated by android emulator.
+Android pipe virtual device generated by android emulator.
Required properties:
diff --git a/Documentation/devicetree/bindings/gpio/8xxx_gpio.txt b/Documentation/devicetree/bindings/gpio/8xxx_gpio.txt
deleted file mode 100644
index 973362eb3f1e..000000000000
--- a/Documentation/devicetree/bindings/gpio/8xxx_gpio.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-GPIO controllers on MPC8xxx SoCs
-
-This is for the non-QE/CPM/GUTs GPIO controllers as found on
-8349, 8572, 8610 and compatible.
-
-Every GPIO controller node must have #gpio-cells property defined,
-this information will be used to translate gpio-specifiers.
-See bindings/gpio/gpio.txt for details of how to specify GPIO
-information for devices.
-
-The GPIO module usually is connected to the SoC's internal interrupt
-controller, see bindings/interrupt-controller/interrupts.txt (the
-interrupt client nodes section) for details how to specify this GPIO
-module's interrupt.
-
-The GPIO module may serve as another interrupt controller (cascaded to
-the SoC's internal interrupt controller). See the interrupt controller
-nodes section in bindings/interrupt-controller/interrupts.txt for
-details.
-
-Required properties:
-- compatible: "fsl,<chip>-gpio" followed by "fsl,mpc8349-gpio"
- for 83xx, "fsl,mpc8572-gpio" for 85xx, or
- "fsl,mpc8610-gpio" for 86xx.
-- #gpio-cells: Should be two. The first cell is the pin number
- and the second cell is used to specify optional
- parameters (currently unused).
-- interrupts: Interrupt mapping for GPIO IRQ.
-- gpio-controller: Marks the port as GPIO controller.
-
-Optional properties:
-- interrupt-controller: Empty boolean property which marks the GPIO
- module as an IRQ controller.
-- #interrupt-cells: Should be two. Defines the number of integer
- cells required to specify an interrupt within
- this interrupt controller. The first cell
- defines the pin number, the second cell
- defines additional flags (trigger type,
- trigger polarity). Note that the available
- set of trigger conditions supported by the
- GPIO module depends on the actual SoC.
-
-Example of gpio-controller nodes for a MPC8347 SoC:
-
- gpio1: gpio-controller@c00 {
- #gpio-cells = <2>;
- compatible = "fsl,mpc8347-gpio", "fsl,mpc8349-gpio";
- reg = <0xc00 0x100>;
- interrupt-parent = <&ipic>;
- interrupts = <74 0x8>;
- gpio-controller;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpio2: gpio-controller@d00 {
- #gpio-cells = <2>;
- compatible = "fsl,mpc8347-gpio", "fsl,mpc8349-gpio";
- reg = <0xd00 0x100>;
- interrupt-parent = <&ipic>;
- interrupts = <75 0x8>;
- gpio-controller;
- };
-
-Example of a peripheral using the GPIO module as an IRQ controller:
-
- funkyfpga@0 {
- compatible = "funky-fpga";
- ...
- interrupt-parent = <&gpio1>;
- interrupts = <4 3>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt
deleted file mode 100644
index ce19c5660aca..000000000000
--- a/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* Abilis TB10x GPIO controller
-
-Required Properties:
-- compatible: Should be "abilis,tb10x-gpio"
-- reg: Address and length of the register set for the device
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be <2>. The first cell is the pin number and the
- second cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted).
-- abilis,ngpio: the number of GPIO pins this driver controls.
-
-Optional Properties:
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be <1>. Interrupts are triggered on both edges.
-- interrupts: Defines the interrupt line connecting this GPIO controller to
- its parent interrupt controller.
-
-GPIO ranges are specified as described in
-Documentation/devicetree/bindings/gpio/gpio.txt
-
-Example:
-
- gpioa: gpio@ff140000 {
- compatible = "abilis,tb10x-gpio";
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupt-parent = <&tb10x_ictl>;
- interrupts = <27 2>;
- reg = <0xFF140000 0x1000>;
- gpio-controller;
- #gpio-cells = <2>;
- abilis,ngpio = <3>;
- gpio-ranges = <&iomux 0 0 0>;
- gpio-ranges-group-names = "gpioa_pins";
- };
diff --git a/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.yaml b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.yaml
new file mode 100644
index 000000000000..c93ec0f16bcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/abilis,tb10x-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Abilis TB10x GPIO controller
+
+maintainers:
+ - Christian Ruppert <christian.ruppert@abilis.com>
+
+properties:
+ compatible:
+ const: abilis,tb10x-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-ranges: true
+
+ gpio-ranges-group-names: true
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+ description: Interrupts are triggered on both edges
+
+ interrupts:
+ maxItems: 1
+
+ abilis,ngpio:
+ description: Number of GPIO pins this driver controls
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - abilis,ngpio
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@ff140000 {
+ compatible = "abilis,tb10x-gpio";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <27 2>;
+ reg = <0xff140000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ abilis,ngpio = <3>;
+ gpio-ranges = <&iomux 0 0 0>;
+ gpio-ranges-group-names = "gpioa_pins";
+ };
diff --git a/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml b/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml
new file mode 100644
index 000000000000..25b3198c4d3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/adi,ds4520-gpio.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/adi,ds4520-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DS4520 I2C GPIO expander
+
+maintainers:
+ - Okan Sahin <okan.sahin@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - adi,ds4520-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ ngpios:
+ minimum: 1
+ maximum: 9
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - ngpios
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@50 {
+ compatible = "adi,ds4520-gpio";
+ reg = <0x50>;
+ ngpios = <9>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/altr-pio-1.0.yaml b/Documentation/devicetree/bindings/gpio/altr-pio-1.0.yaml
new file mode 100644
index 000000000000..18afed324198
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/altr-pio-1.0.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/altr-pio-1.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera GPIO controller
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+ - Marek Vasut <marex@denx.de>
+ - Mathieu Malaterre <malat@debian.org>
+ - Tien Hock Loh <thloh@altera.com>
+
+properties:
+ compatible:
+ const: altr,pio-1.0
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ First cell is the GPIO offset number. Second cell is reserved and
+ currently unused.
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ altr,ngpio:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Width of the GPIO bank.
+ default: 32
+
+ altr,interrupt-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ Specifies the interrupt trigger type synthesized by hardware.
+ Values defined in <dt-bindings/interrupt-controller/irq.h>.
+ enum: [1, 2, 3, 4]
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio@ff200000 {
+ compatible = "altr,pio-1.0";
+ reg = <0xff200000 0x10>;
+ interrupts = <45 4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ altr,ngpio = <32>;
+ altr,interrupt-type = <IRQ_TYPE_EDGE_RISING>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/apm,xgene-gpio-sb.yaml b/Documentation/devicetree/bindings/gpio/apm,xgene-gpio-sb.yaml
new file mode 100644
index 000000000000..d205dd7b492c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/apm,xgene-gpio-sb.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/apm,xgene-gpio-sb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene Standby GPIO controller
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+description: |
+ This is a gpio controller in the standby domain. It also supports interrupt in
+ some particular pins which are sourced to its parent interrupt controller
+ as diagram below:
+ +-----------------+
+ | X-Gene standby |
+ | GPIO controller +------ GPIO_0
+ +------------+ | | ...
+ | Parent IRQ | EXT_INT_0 | +------ GPIO_8/EXT_INT_0
+ | controller | (SPI40) | | ...
+ | (GICv2) +--------------+ +------ GPIO_[N+8]/EXT_INT_N
+ | | ... | |
+ | | EXT_INT_N | +------ GPIO_[N+9]
+ | | (SPI[40 + N])| | ...
+ | +--------------+ +------ GPIO_MAX
+ +------------+ +-----------------+
+
+properties:
+ compatible:
+ const: apm,xgene-gpio-sb
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ interrupts:
+ description:
+ List of interrupt specifiers for EXT_INT_0 through EXT_INT_N. The first
+ entry must correspond to EXT_INT_0.
+
+ '#interrupt-cells':
+ const: 2
+ description:
+ First cell selects EXT_INT_N (0-N), second cell specifies flags
+
+ interrupt-controller: true
+
+ apm,nr-gpios:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of GPIO pins
+
+ apm,nr-irqs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of interrupt pins
+
+ apm,irq-start:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Lowest GPIO pin supporting interrupts
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+ - interrupts
+ - '#interrupt-cells'
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@17001000 {
+ compatible = "apm,xgene-gpio-sb";
+ reg = <0x17001000 0x400>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupts = <0x0 0x28 0x1>,
+ <0x0 0x29 0x1>,
+ <0x0 0x2a 0x1>,
+ <0x0 0x2b 0x1>,
+ <0x0 0x2c 0x1>,
+ <0x0 0x2d 0x1>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ apm,nr-gpios = <22>;
+ apm,nr-irqs = <6>;
+ apm,irq-start = <8>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml
new file mode 100644
index 000000000000..42b1bc0a10c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/apple,smc-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple Mac System Management Controller GPIO
+
+maintainers:
+ - Sven Peter <sven@kernel.org>
+
+description:
+ Apple Mac System Management Controller GPIO block.
+
+properties:
+ compatible:
+ const: apple,smc-gpio
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+required:
+ - compatible
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml
new file mode 100644
index 000000000000..b16273e69dfe
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/aspeed,ast2400-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed GPIO controller
+
+maintainers:
+ - Andrew Jeffery <andrew@codeconstruct.com.au>
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-gpio
+ - aspeed,ast2500-gpio
+ - aspeed,ast2600-gpio
+ - aspeed,ast2700-gpio
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: The clock to use for debounce timings
+
+ gpio-controller: true
+ gpio-line-names:
+ minItems: 12
+ maxItems: 232
+
+ gpio-ranges: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ ngpios:
+ minimum: 12
+ maximum: 232
+
+patternProperties:
+ "-hog(-[0-9]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - gpio-controller
+ - "#gpio-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: aspeed,ast2400-gpio
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 220
+ maxItems: 220
+ ngpios:
+ const: 220
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: aspeed,ast2500-gpio
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 232
+ maxItems: 232
+ ngpios:
+ const: 232
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: aspeed,ast2600-gpio
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 36
+ maxItems: 208
+ ngpios:
+ enum: [ 36, 208 ]
+ required:
+ - ngpios
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: aspeed,ast2700-gpio
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 12
+ maxItems: 216
+ ngpios:
+ enum: [ 12, 216 ]
+ required:
+ - ngpios
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@1e780000 {
+ compatible = "aspeed,ast2400-gpio";
+ reg = <0x1e780000 0x1000>;
+ interrupts = <20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ - |
+ gpio: gpio@1e780000 {
+ compatible = "aspeed,ast2500-gpio";
+ reg = <0x1e780000 0x200>;
+ interrupts = <20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 0 232>;
+ };
+ - |
+ #include <dt-bindings/clock/ast2600-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ gpio0: gpio@1e780000 {
+ compatible = "aspeed,ast2600-gpio";
+ reg = <0x1e780000 0x400>;
+ clocks = <&syscon ASPEED_CLK_APB2>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 208>;
+ ngpios = <208>;
+ };
+ gpio1: gpio@1e780800 {
+ compatible = "aspeed,ast2600-gpio";
+ reg = <0x1e780800 0x800>;
+ clocks = <&syscon ASPEED_CLK_APB1>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 208 36>;
+ ngpios = <36>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
index 46bb121360dc..1046f0331c09 100644
--- a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
@@ -33,6 +33,11 @@ properties:
gpio-controller: true
+ # Each SGPIO is represented as a pair of input and output GPIOs
+ gpio-line-names:
+ minItems: 160
+ maxItems: 256
+
'#gpio-cells':
const: 2
@@ -41,6 +46,9 @@ properties:
interrupt-controller: true
+ '#interrupt-cells':
+ const: 2
+
clocks:
maxItems: 1
@@ -55,6 +63,7 @@ required:
- '#gpio-cells'
- interrupts
- interrupt-controller
+ - '#interrupt-cells'
- ngpios
- clocks
- bus-frequency
@@ -72,6 +81,7 @@ examples:
reg = <0x1e780200 0x0100>;
clocks = <&syscon ASPEED_CLK_APB>;
interrupt-controller;
+ #interrupt-cells = <2>;
ngpios = <80>;
bus-frequency = <12000000>;
};
diff --git a/Documentation/devicetree/bindings/gpio/atmel,at91rm9200-gpio.yaml b/Documentation/devicetree/bindings/gpio/atmel,at91rm9200-gpio.yaml
new file mode 100644
index 000000000000..d810043b56b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/atmel,at91rm9200-gpio.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/atmel,at91rm9200-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip GPIO controller (PIO)
+
+maintainers:
+ - Manikandan Muralidharan <manikandan.m@microchip.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at91sam9x5-gpio
+ - microchip,sam9x60-gpio
+ - const: atmel,at91rm9200-gpio
+ - items:
+ - enum:
+ - microchip,sam9x7-gpio
+ - const: microchip,sam9x60-gpio
+ - const: atmel,at91rm9200-gpio
+ - items:
+ - const: atmel,at91rm9200-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+ gpio-line-names: true
+
+ "#gpio-cells":
+ const: 2
+
+ clocks:
+ maxItems: 1
+
+ "#gpio-lines":
+ description:
+ Number of gpio, 32 by default if absent
+ maxItems: 1
+ default: 32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - gpio-controller
+ - "#gpio-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio@fffff400 {
+ compatible = "atmel,at91rm9200-gpio";
+ reg = <0xfffff400 0x200>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/blaize,blzp1600-gpio.yaml b/Documentation/devicetree/bindings/gpio/blaize,blzp1600-gpio.yaml
new file mode 100644
index 000000000000..a05f6ea619c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/blaize,blzp1600-gpio.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/blaize,blzp1600-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Blaize BLZP1600 GPIO controller
+
+description:
+ Blaize BLZP1600 GPIO controller is an implementation of the VeriSilicon
+ APB GPIO v0.2 IP block. It has 32 ports each of which are intended to be
+ represented as child nodes with the generic GPIO-controller properties
+ as described in this binding's file.
+
+maintainers:
+ - Nikolaos Pasaloukos <nikolaos.pasaloukos@blaize.com>
+ - James Cowgill <james.cowgill@blaize.com>
+ - Matt Redfearn <matt.redfearn@blaize.com>
+ - Neil Jones <neil.jones@blaize.com>
+
+properties:
+ $nodename:
+ pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - blaize,blzp1600-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ ngpios:
+ default: 32
+ minimum: 1
+ maximum: 32
+
+ interrupts:
+ maxItems: 1
+
+ gpio-line-names: true
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+dependencies:
+ interrupt-controller: [ interrupts ]
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpio: gpio@4c0000 {
+ compatible = "blaize,blzp1600-gpio";
+ reg = <0x004c0000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <32>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
deleted file mode 100644
index 4d69f79df859..000000000000
--- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
+++ /dev/null
@@ -1,86 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Broadcom BCM6345 GPIO controller
-
-maintainers:
- - Álvaro Fernández Rojas <noltari@gmail.com>
- - Jonas Gorski <jonas.gorski@gmail.com>
-
-description: |+
- Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
-
- These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
- are the only ones which don't need a pinctrl driver.
-
- BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
- and/or written, and the direction changed from input to output.
- BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
- and/or written, and the direction changed from input to output.
- BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
- and dirout registers, where GPIO state can be read and/or written, and the
- direction changed from input to output.
-
-properties:
- compatible:
- enum:
- - brcm,bcm6318-gpio
- - brcm,bcm6328-gpio
- - brcm,bcm6345-gpio
- - brcm,bcm6358-gpio
- - brcm,bcm6362-gpio
- - brcm,bcm6368-gpio
- - brcm,bcm63268-gpio
-
- gpio-controller: true
-
- "#gpio-cells":
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- native-endian: true
-
- reg:
- maxItems: 2
-
- reg-names:
- items:
- - const: dirout
- - const: dat
-
-required:
- - compatible
- - reg
- - reg-names
- - gpio-controller
- - '#gpio-cells'
-
-additionalProperties: false
-
-examples:
- - |
- gpio@fffe0406 {
- compatible = "brcm,bcm6345-gpio";
- reg-names = "dirout", "dat";
- reg = <0xfffe0406 2>, <0xfffe040a 2>;
- native-endian;
-
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- - |
- gpio@0 {
- compatible = "brcm,bcm63268-gpio";
- reg-names = "dirout", "dat";
- reg = <0x0 0x8>, <0x8 0x8>;
-
- gpio-controller;
- gpio-ranges = <&pinctrl 0 0 52>;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
new file mode 100644
index 000000000000..62fcc2bd5d80
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/brcm,bcm63xx-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM63xx GPIO controller
+
+maintainers:
+ - Álvaro Fernández Rojas <noltari@gmail.com>
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+description: |+
+ Bindings for Broadcom's BCM63xx memory-mapped GPIO controllers.
+
+ These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345
+ are the only ones which don't need a pinctrl driver.
+
+ BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
+ and/or written, and the direction changed from input to output.
+ BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
+ and dirout registers, where GPIO state can be read and/or written, and the
+ direction changed from input to output.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm6318-gpio
+ - brcm,bcm6328-gpio
+ - brcm,bcm6358-gpio
+ - brcm,bcm6362-gpio
+ - brcm,bcm6368-gpio
+ - brcm,bcm63268-gpio
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ native-endian: true
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: dirout
+ - const: dat
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@0 {
+ compatible = "brcm,bcm63268-gpio";
+ reg-names = "dirout", "dat";
+ reg = <0x0 0x8>, <0x8 0x8>;
+
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 52>;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml
index 4a896ff7edc5..fbd69b4cecc7 100644
--- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml
@@ -62,6 +62,12 @@ properties:
interrupt-controller: true
+ gpio-ranges: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 128
+
wakeup-source:
type: boolean
description: >
@@ -72,7 +78,7 @@ required:
- reg
- gpio-controller
- "#gpio-cells"
- - "brcm,gpio-bank-widths"
+ - brcm,gpio-bank-widths
additionalProperties: false
@@ -88,6 +94,7 @@ examples:
interrupt-parent = <&irq0_intc>;
interrupts = <0x6>;
brcm,gpio-bank-widths = <32 32 32 24>;
+ gpio-ranges = <&pinctrl 0 0 120>;
};
upg_gio_aon: gpio@f04172c0 {
diff --git a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt
deleted file mode 100644
index 4a63bc96b687..000000000000
--- a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Broadcom Kona Family GPIO
-=========================
-
-This GPIO driver is used in the following Broadcom SoCs:
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
-
-The Broadcom GPIO Controller IP can be configured prior to synthesis to
-support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
-GPIO controller only supports edge, not level, triggering of interrupts.
-
-Required properties
--------------------
-
-- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio"
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The interrupt outputs from the controller. There is one GPIO
- interrupt per GPIO bank. The number of interrupts listed depends on the
- number of GPIO banks on the SoC. The interrupts must be ordered by bank,
- starting with bank 0. There is always a 1:1 mapping between banks and
- IRQs.
-- #gpio-cells: Should be <2>. The first cell is the pin number, the second
- cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted)
- See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
-- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The
- second cell is used to specify flags. The following subset of flags is
- supported:
- - trigger type (bits[1:0]):
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 3 = low-to-high or high-to-low edge triggered
- Valid values are 1, 2, 3
- See also .../devicetree/bindings/interrupt-controller/interrupts.txt.
-- gpio-controller: Marks the device node as a GPIO controller.
-- interrupt-controller: Marks the device node as an interrupt controller.
-
-Example:
- gpio: gpio@35003000 {
- compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
- reg = <0x35003000 0x800>;
- interrupts =
- <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
- #gpio-cells = <2>;
- #interrupt-cells = <2>;
- gpio-controller;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml
new file mode 100644
index 000000000000..296fdd6b8f38
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,kona-gpio.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/brcm,kona-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family GPIO controller
+
+description:
+ The Broadcom GPIO Controller IP can be configured prior to synthesis to
+ support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
+ GPIO controller only supports edge, not level, triggering of interrupts.
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm11351-gpio
+ - brcm,bcm21664-gpio
+ - brcm,bcm23550-gpio
+ - const: brcm,kona-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 4
+ maxItems: 6
+ description:
+ The interrupt outputs from the controller. There is one GPIO interrupt
+ per GPIO bank. The number of interrupts listed depends on the number of
+ GPIO banks on the SoC. The interrupts must be ordered by bank, starting
+ with bank 0. There is always a 1:1 mapping between banks and IRQs.
+
+ '#gpio-cells':
+ const: 2
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#gpio-cells'
+ - '#interrupt-cells'
+ - gpio-controller
+ - interrupt-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm11351-gpio
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm21664-gpio
+ - brcm,bcm23550-gpio
+ then:
+ properties:
+ interrupts:
+ maxItems: 4
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio@35003000 {
+ compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
+ reg = <0x35003000 0x800>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml
index c213cb9ddb9f..5cfefbbea6ca 100644
--- a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml
@@ -66,5 +66,4 @@ examples:
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
};
-
...
diff --git a/Documentation/devicetree/bindings/gpio/cavium,octeon-3860-gpio.yaml b/Documentation/devicetree/bindings/gpio/cavium,octeon-3860-gpio.yaml
new file mode 100644
index 000000000000..35155b900655
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/cavium,octeon-3860-gpio.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cavium,octeon-3860-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cavium Octeon 3860 GPIO controller
+
+maintainers:
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+
+properties:
+ compatible:
+ const: cavium,octeon-3860-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 16
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ gpio@1070000000800 {
+ compatible = "cavium,octeon-3860-gpio";
+ reg = <0x10700 0x00000800 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ /* The GPIO pin connect to 16 consecutive CUI bits */
+ interrupts = <0 16>, <0 17>, <0 18>, <0 19>,
+ <0 20>, <0 21>, <0 22>, <0 23>,
+ <0 24>, <0 25>, <0 26>, <0 27>,
+ <0 28>, <0 29>, <0 30>, <0 31>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt b/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt
deleted file mode 100644
index 9d6dcd3fe7f9..000000000000
--- a/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* General Purpose Input Output (GPIO) bus.
-
-Properties:
-- compatible: "cavium,octeon-3860-gpio"
-
- Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
-
-- reg: The base address of the GPIO unit's register bank.
-
-- gpio-controller: This is a GPIO controller.
-
-- #gpio-cells: Must be <2>. The first cell is the GPIO pin.
-
-- interrupt-controller: The GPIO controller is also an interrupt
- controller, many of its pins may be configured as an interrupt
- source.
-
-- #interrupt-cells: Must be <2>. The first cell is the GPIO pin
- connected to the interrupt source. The second cell is the interrupt
- triggering protocol and may have one of four values:
- 1 - edge triggered on the rising edge.
- 2 - edge triggered on the falling edge
- 4 - level triggered active high.
- 8 - level triggered active low.
-
-- interrupts: Interrupt routing for each pin.
-
-Example:
-
- gpio-controller@1070000000800 {
- #gpio-cells = <2>;
- compatible = "cavium,octeon-3860-gpio";
- reg = <0x10700 0x00000800 0x0 0x100>;
- gpio-controller;
- /* Interrupts are specified by two parts:
- * 1) GPIO pin number (0..15)
- * 2) Triggering (1 - edge rising
- * 2 - edge falling
- * 4 - level active high
- * 8 - level active low)
- */
- interrupt-controller;
- #interrupt-cells = <2>;
- /* The GPIO pin connect to 16 consecutive CUI bits */
- interrupts = <0 16>, <0 17>, <0 18>, <0 19>,
- <0 20>, <0 21>, <0 22>, <0 23>,
- <0 24>, <0 25>, <0 26>, <0 27>,
- <0 28>, <0 29>, <0 30>, <0 31>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/cdns,gpio.txt b/Documentation/devicetree/bindings/gpio/cdns,gpio.txt
deleted file mode 100644
index 706ef00f5c64..000000000000
--- a/Documentation/devicetree/bindings/gpio/cdns,gpio.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Cadence GPIO controller bindings
-
-Required properties:
-- compatible: should be "cdns,gpio-r1p02".
-- reg: the register base address and size.
-- #gpio-cells: should be 2.
- * first cell is the GPIO number.
- * second cell specifies the GPIO flags, as defined in
- <dt-bindings/gpio/gpio.h>. Only the GPIO_ACTIVE_HIGH
- and GPIO_ACTIVE_LOW flags are supported.
-- gpio-controller: marks the device as a GPIO controller.
-- clocks: should contain one entry referencing the peripheral clock driving
- the GPIO controller.
-
-Optional properties:
-- ngpios: integer number of gpio lines supported by this controller, up to 32.
-- interrupts: interrupt specifier for the controllers interrupt.
-- interrupt-controller: marks the device as an interrupt controller. When
- defined, interrupts, interrupt-parent and #interrupt-cells
- are required.
-- interrupt-cells: should be 2.
- * first cell is the GPIO number you want to use as an IRQ source.
- * second cell specifies the IRQ type, as defined in
- <dt-bindings/interrupt-controller/irq.h>.
- Currently only level sensitive IRQs are supported.
-
-
-Example:
- gpio0: gpio-controller@fd060000 {
- compatible = "cdns,gpio-r1p02";
- reg =<0xfd060000 0x1000>;
-
- clocks = <&gpio_clk>;
-
- interrupt-parent = <&gic>;
- interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/cdns,gpio.yaml b/Documentation/devicetree/bindings/gpio/cdns,gpio.yaml
new file mode 100644
index 000000000000..a84d60b39459
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/cdns,gpio.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/cdns,gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence GPIO Controller
+
+maintainers:
+ - Jan Kotas <jank@cadence.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: cdns,gpio-r1p02
+ - items:
+ - enum:
+ - axiado,ax3000-gpio
+ - const: cdns,gpio-r1p02
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ ngpios:
+ minimum: 1
+ maximum: 32
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ - First cell is the GPIO line number.
+ - Second cell is flags as defined in <dt-bindings/gpio/gpio.h>,
+ only GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW supported.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+ description: |
+ - First cell is the GPIO line number used as IRQ.
+ - Second cell is the trigger type, as defined in
+ <dt-bindings/interrupt-controller/irq.h>.
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - gpio-controller
+ - "#gpio-cells"
+
+if:
+ required: [interrupt-controller]
+then:
+ required:
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ gpio0: gpio-controller@fd060000 {
+ compatible = "cdns,gpio-r1p02";
+ reg = <0xfd060000 0x1000>;
+ clocks = <&gpio_clk>;
+
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt
deleted file mode 100644
index fd42e7280f72..000000000000
--- a/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* ARM Cirrus Logic CLPS711X SYSFLG1 MCTRL GPIOs
-
-Required properties:
-- compatible: Should contain "cirrus,ep7209-mctrl-gpio".
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = Active high,
- 1 = Active low.
-
-Example:
- sysgpio: sysgpio {
- compatible = "cirrus,ep7312-mctrl-gpio",
- "cirrus,ep7209-mctrl-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.yaml b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.yaml
new file mode 100644
index 000000000000..bdffca817f1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/cirrus,clps711x-mctrl-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Cirrus Logic CLPS711X SYSFLG1 MCTRL GPIOs
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: cirrus,ep7312-mctrl-gpio
+ - const: cirrus,ep7209-mctrl-gpio
+ - const: cirrus,ep7209-mctrl-gpio
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio,syscon-dev:
+ description:
+ Phandle and offset of device's specific registers within the syscon state
+ control registers
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscon
+ - description: register offset within state control registers
+
+required:
+ - compatible
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ sysgpio: sysgpio {
+ compatible = "cirrus,ep7312-mctrl-gpio",
+ "cirrus,ep7209-mctrl-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/exar,xra1403.yaml b/Documentation/devicetree/bindings/gpio/exar,xra1403.yaml
new file mode 100644
index 000000000000..053134faf475
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/exar,xra1403.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/exar,xra1403.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: XRA1403 16-bit GPIO Expander with Reset Input
+
+maintainers:
+ - Nandor Han <nandor.han@ge.com>
+
+description: >
+ The XRA1403 is an 16-bit GPIO expander with an SPI interface. Features
+ available:
+
+ - Individually programmable inputs:
+ - Internal pull-up resistors
+ - Polarity inversion
+ - Individual interrupt enable
+ - Rising edge and/or Falling edge interrupt
+ - Input filter
+ - Individually programmable outputs:
+ - Output Level Control
+ - Output Three-State Control
+
+properties:
+ compatible:
+ const: exar,xra1403
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ reset-gpios:
+ description: Control line for the device reset.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@2 {
+ compatible = "exar,xra1403";
+ reg = <2>;
+ spi-max-frequency = <1000000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
index a99e7842ca17..23410aeca300 100644
--- a/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
+++ b/Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml
@@ -6,6 +6,22 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic 8-bit shift register
+description: |
+ NOTE: These chips nominally don't have a chip select pin. They do however
+ have a rising-edge triggered latch clock (or storage register clock) pin,
+ which behaves like an active-low chip select.
+
+ After the bits are shifted into the shift register, CS# is driven high, which
+ the 74HC595 sees as a rising edge on the latch clock that results in a
+ transfer of the bits from the shift register to the storage register and thus
+ to the output pins.
+ _ _ _ _
+ shift clock ____| |_| |_..._| |_| |_________
+
+ latch clock * trigger
+ ___ ________
+ chip select# |___________________|
+
maintainers:
- Maxime Ripard <mripard@kernel.org>
@@ -33,24 +49,11 @@ properties:
description: GPIO connected to the OE (Output Enable) pin.
maxItems: 1
- spi-max-frequency: true
-
patternProperties:
"^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
type: object
-
- properties:
- gpio-hog: true
- gpios: true
- output-high: true
- output-low: true
- line-name: true
-
required:
- gpio-hog
- - gpios
-
- additionalProperties: false
required:
- compatible
@@ -59,20 +62,23 @@ required:
- '#gpio-cells'
- registers-number
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
-
- gpio5: gpio5@0 {
- compatible = "fairchild,74hc595";
- reg = <0>;
- gpio-controller;
- #gpio-cells = <2>;
- registers-number = <4>;
- spi-max-frequency = <100000>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio5@0 {
+ compatible = "fairchild,74hc595";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ registers-number = <4>;
+ spi-max-frequency = <100000>;
+ };
};
diff --git a/Documentation/devicetree/bindings/gpio/fsl,imx8qxp-sc-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl,imx8qxp-sc-gpio.yaml
new file mode 100644
index 000000000000..b7b32220935d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/fsl,imx8qxp-sc-gpio.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/fsl,imx8qxp-sc-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO driver over IMX SCU firmware API
+
+maintainers:
+ - Shenwei Wang <shenwei.wang@nxp.com>
+
+description: |
+ This module provides the standard interface to control the
+ resource pins in SCU domain on i.MX8 platforms.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-sc-gpio
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio0: gpio {
+ compatible = "fsl,imx8qxp-sc-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml
new file mode 100644
index 000000000000..4cb2a6b9fabf
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/fsl,qoriq-gpio.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/fsl,qoriq-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MPC512x/MPC8xxx/QorIQ/Layerscape GPIO controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,mpc5121-gpio
+ - fsl,mpc5125-gpio
+ - fsl,mpc8314-gpio
+ - fsl,mpc8349-gpio
+ - fsl,mpc8572-gpio
+ - fsl,mpc8610-gpio
+ - fsl,pq3-gpio
+ - items:
+ - enum:
+ - fsl,ls1021a-gpio
+ - fsl,ls1028a-gpio
+ - fsl,ls1043a-gpio
+ - fsl,ls1046a-gpio
+ - fsl,ls1088a-gpio
+ - fsl,ls2080a-gpio
+ - const: fsl,qoriq-gpio
+ - items:
+ - enum:
+ - fsl,mpc8308-gpio
+ - fsl,mpc8377-gpio
+ - fsl,mpc8378-gpio
+ - fsl,mpc8379-gpio
+ - const: fsl,mpc8349-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 32
+
+ little-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ GPIO registers are used as little endian. If not
+ present registers are used as big endian by default.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@1100 {
+ compatible = "fsl,mpc5125-gpio";
+ reg = <0x1100 0x080>;
+ interrupts = <78 0x8>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ gpio@2300000 {
+ compatible = "fsl,ls2080a-gpio", "fsl,qoriq-gpio";
+ reg = <0x2300000 0x10000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ little-endian;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
index ae18603697d7..6b06609c649e 100644
--- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
@@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX/MXC GPIO controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
properties:
compatible:
@@ -19,10 +21,18 @@ properties:
- fsl,imx35-gpio
- fsl,imx7d-gpio
- items:
+ - enum:
+ - fsl,imx27-gpio
+ - const: fsl,imx21-gpio
+ - items:
- const: fsl,imx35-gpio
- const: fsl,imx31-gpio
- items:
- enum:
+ - fsl,imx25-gpio
+ - const: fsl,imx35-gpio
+ - items:
+ - enum:
- fsl,imx50-gpio
- fsl,imx51-gpio
- fsl,imx53-gpio
@@ -32,10 +42,12 @@ properties:
- fsl,imx6sx-gpio
- fsl,imx6ul-gpio
- fsl,imx7d-gpio
+ - fsl,imx8dxl-gpio
- fsl,imx8mm-gpio
- fsl,imx8mn-gpio
- fsl,imx8mp-gpio
- fsl,imx8mq-gpio
+ - fsl,imx8qm-gpio
- fsl,imx8qxp-gpio
- fsl,imxrt1050-gpio
- fsl,imxrt1170-gpio
@@ -73,19 +85,8 @@ properties:
patternProperties:
"^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
type: object
- properties:
- gpio-hog: true
- gpios: true
- input: true
- output-high: true
- output-low: true
- line-name: true
-
required:
- gpio-hog
- - gpios
-
- additionalProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt b/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt
deleted file mode 100644
index bef353f370d8..000000000000
--- a/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Fujitsu MB86S7x GPIO Controller
--------------------------------
-
-Required properties:
-- compatible: Should be "fujitsu,mb86s70-gpio"
-- reg: Base address and length of register space
-- clocks: Specify the clock
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be <2>. The first cell is the pin number and the
- second cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted).
-
-Examples:
- gpio0: gpio@31000000 {
- compatible = "fujitsu,mb86s70-gpio";
- reg = <0 0x31000000 0x10000>;
- gpio-controller;
- #gpio-cells = <2>;
- clocks = <&clk 0 2 1>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml b/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml
new file mode 100644
index 000000000000..d18d95285465
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/fujitsu,mb86s70-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fujitsu MB86S7x GPIO Controller
+
+maintainers:
+ - Jassi Brar <jaswinder.singh@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: socionext,synquacer-gpio
+ - const: fujitsu,mb86s70-gpio
+ - const: fujitsu,mb86s70-gpio
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+ gpio-line-names: true
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@31000000 {
+ compatible = "fujitsu,mb86s70-gpio";
+ reg = <0x31000000 0x10000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ clocks = <&clk 0 2 1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/gateworks,pld-gpio.txt b/Documentation/devicetree/bindings/gpio/gateworks,pld-gpio.txt
deleted file mode 100644
index 6e81f8b755c5..000000000000
--- a/Documentation/devicetree/bindings/gpio/gateworks,pld-gpio.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Gateworks PLD GPIO controller bindings
-
-The GPIO controller should be a child node on an I2C bus,
-see: i2c/i2c.txt for details.
-
-Required properties:
-- compatible: Should be "gateworks,pld-gpio"
-- reg: I2C slave address
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be <2>. The first cell is the gpio number and
- the second cell is used to specify optional parameters.
-
-Example:
-
-pld@56 {
- compatible = "gateworks,pld-gpio";
- reg = <0x56>;
- gpio-controller;
- #gpio-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-74xx-mmio.txt b/Documentation/devicetree/bindings/gpio/gpio-74xx-mmio.txt
deleted file mode 100644
index 7bb1a9d60133..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-74xx-mmio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* 74XX MMIO GPIO driver
-
-Required properties:
-- compatible: Should contain one of the following:
- "ti,741g125": for 741G125 (1-bit Input),
- "ti,741g174": for 741G74 (1-bit Output),
- "ti,742g125": for 742G125 (2-bit Input),
- "ti,7474" : for 7474 (2-bit Output),
- "ti,74125" : for 74125 (4-bit Input),
- "ti,74175" : for 74175 (4-bit Output),
- "ti,74365" : for 74365 (6-bit Input),
- "ti,74174" : for 74174 (6-bit Output),
- "ti,74244" : for 74244 (8-bit Input),
- "ti,74273" : for 74273 (8-bit Output),
- "ti,741624" : for 741624 (16-bit Input),
- "ti,7416374": for 7416374 (16-bit Output).
-- reg: Physical base address and length where IC resides.
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify the GPIO polarity:
- 0 = Active High,
- 1 = Active Low.
-
-Example:
- ctrl: gpio@30008004 {
- compatible = "ti,74174";
- reg = <0x30008004 0x1>;
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-altera.txt b/Documentation/devicetree/bindings/gpio/gpio-altera.txt
deleted file mode 100644
index 2a80e272cd66..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-altera.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Altera GPIO controller bindings
-
-Required properties:
-- compatible:
- - "altr,pio-1.0"
-- reg: Physical base address and length of the controller's registers.
-- #gpio-cells : Should be 2
- - The first cell is the gpio offset number.
- - The second cell is reserved and is currently unused.
-- gpio-controller : Marks the device node as a GPIO controller.
-- interrupt-controller: Mark the device node as an interrupt controller
-- #interrupt-cells : Should be 2. The interrupt type is fixed in the hardware.
- - The first cell is the GPIO offset number within the GPIO controller.
- - The second cell is the interrupt trigger type and level flags.
-- interrupts: Specify the interrupt.
-- altr,interrupt-type: Specifies the interrupt trigger type the GPIO
- hardware is synthesized. This field is required if the Altera GPIO controller
- used has IRQ enabled as the interrupt type is not software controlled,
- but hardware synthesized. Required if GPIO is used as an interrupt
- controller. The value is defined in <dt-bindings/interrupt-controller/irq.h>
- Only the following flags are supported:
- IRQ_TYPE_EDGE_RISING
- IRQ_TYPE_EDGE_FALLING
- IRQ_TYPE_EDGE_BOTH
- IRQ_TYPE_LEVEL_HIGH
-
-Optional properties:
-- altr,ngpio: Width of the GPIO bank. This defines how many pins the
- GPIO device has. Ranges between 1-32. Optional and defaults to 32 if not
- specified.
-
-Example:
-
-gpio_altr: gpio@ff200000 {
- compatible = "altr,pio-1.0";
- reg = <0xff200000 0x10>;
- interrupts = <0 45 4>;
- altr,ngpio = <32>;
- altr,interrupt-type = <IRQ_TYPE_EDGE_RISING>;
- #gpio-cells = <2>;
- gpio-controller;
- #interrupt-cells = <2>;
- interrupt-controller;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
deleted file mode 100644
index b2033fc3a71a..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Aspeed GPIO controller Device Tree Bindings
--------------------------------------------
-
-Required properties:
-- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
- or "aspeed,ast2600-gpio".
-
-- #gpio-cells : Should be two
- - First cell is the GPIO line number
- - Second cell is used to specify optional
- parameters (unused)
-
-- reg : Address and length of the register set for the device
-- gpio-controller : Marks the device node as a GPIO controller.
-- interrupts : Interrupt specifier (see interrupt bindings for
- details)
-- interrupt-controller : Mark the GPIO controller as an interrupt-controller
-
-Optional properties:
-
-- clocks : A phandle to the clock to use for debounce timings
-- ngpios : Number of GPIOs controlled by this controller. Should be set
- when there are multiple GPIO controllers on a SoC (ast2600).
-
-The gpio and interrupt properties are further described in their respective
-bindings documentation:
-
-- Documentation/devicetree/bindings/gpio/gpio.txt
-- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
- Example:
- gpio@1e780000 {
- #gpio-cells = <2>;
- compatible = "aspeed,ast2400-gpio";
- gpio-controller;
- interrupts = <20>;
- reg = <0x1e780000 0x1000>;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-ath79.txt b/Documentation/devicetree/bindings/gpio/gpio-ath79.txt
deleted file mode 100644
index cf71f3ec969d..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-ath79.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-Binding for Qualcomm Atheros AR7xxx/AR9xxx GPIO controller
-
-Required properties:
-- compatible: has to be "qca,<soctype>-gpio" and one of the following
- fallbacks:
- - "qca,ar7100-gpio"
- - "qca,ar9340-gpio"
-- reg: Base address and size of the controllers memory area
-- gpio-controller : Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters.
-- ngpios: Should be set to the number of GPIOs available on the SoC.
-
-Optional properties:
-- interrupts: Interrupt specifier for the controllers interrupt.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode interrupt
- source, should be 2
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-Example:
-
- gpio@18040000 {
- compatible = "qca,ar9132-gpio", "qca,ar7100-gpio";
- reg = <0x18040000 0x30>;
- interrupts = <2>;
-
- ngpios = <22>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
deleted file mode 100644
index 0a304ad29d81..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Cirrus Logic CLPS711X GPIO controller
-
-Required properties:
-- compatible: Should be "cirrus,ep7209-gpio"
-- reg: Physical base GPIO controller registers location and length.
- There should be two registers, first is DATA register, the second
- is DIRECTION.
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-
-Note: Each GPIO port should have an alias correctly numbered in "aliases"
-node.
-
-Example:
-
-aliases {
- gpio0 = &porta;
-};
-
-porta: gpio@80000000 {
- compatible = "cirrus,ep7312-gpio","cirrus,ep7209-gpio";
- reg = <0x80000000 0x1>, <0x80000040 0x1>;
- gpio-controller;
- #gpio-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml
index f32e09ef937c..1434d08f8b74 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml
@@ -32,10 +32,12 @@ properties:
gpio-ranges: true
+ gpio-reserved-ranges: true
+
gpio-line-names:
description: strings describing the names of each gpio line.
minItems: 1
- maxItems: 100
+ maxItems: 144
"#gpio-cells":
const: 2
diff --git a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
new file mode 100644
index 000000000000..1cebc4058e27
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-delay.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO delay controller
+
+maintainers:
+ - Alexander Stein <linux@ew.tq-group.com>
+
+description: |
+ This binding describes an electrical setup where setting an GPIO output
+ is delayed by some external setup, e.g. RC circuit.
+
+ +----------+ +-----------+
+ | | VCC_B | |
+ | | | | |
+ | | VCC_A _ | |
+ | GPIO | | | R | Consumer |
+ |controller| ___ |_| | |
+ | | | | | | |
+ | [IOx|-------| |--+-----|-----+ |
+ | | |___| | | input |
+ | | | | |
+ +----------+ --- C +-----------+
+ ---
+ |
+ -
+ GND
+
+ If the input on the consumer is controlled by an open-drain signal
+ attached to an RC circuit the ramp-up delay is not under control
+ of the GPIO controller.
+
+properties:
+ compatible:
+ const: gpio-delay
+
+ "#gpio-cells":
+ description: |
+ Specifies the pin, ramp-up and ramp-down delays. The
+ delays are specified in microseconds.
+ const: 3
+
+ gpios:
+ description: Array of GPIOs which output signal change is delayed
+ minItems: 1
+ maxItems: 32
+
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 32
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - gpio-controller
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ enable_delay: enable-delay {
+ compatible = "gpio-delay";
+ #gpio-cells = <3>;
+ gpio-controller;
+ gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
+ <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ consumer {
+ enable-gpios = <&enable_delay 0 130000 30000>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt b/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt
deleted file mode 100644
index 0423699d74c7..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Keystone 2 DSP GPIO controller bindings
-
-HOST OS userland running on ARM can send interrupts to DSP cores using
-the DSP GPIO controller IP. It provides 28 IRQ signals per each DSP core.
-This is one of the component used by the IPC mechanism used on Keystone SOCs.
-
-For example TCI6638K2K SoC has 8 DSP GPIO controllers:
- - 8 for C66x CorePacx CPUs 0-7
-
-Keystone 2 DSP GPIO controller has specific features:
-- each GPIO can be configured only as output pin;
-- setting GPIO value to 1 causes IRQ generation on target DSP core;
-- reading pin value returns 0 - if IRQ was handled or 1 - IRQ is still
- pending.
-
-Required Properties:
-- compatible: should be "ti,keystone-dsp-gpio"
-- ti,syscon-dev: phandle/offset pair. The phandle to syscon used to
- access device state control registers and the offset of device's specific
- registers within device state control registers range.
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be 2.
-
-Please refer to gpio.txt in this directory for details of the common GPIO
-bindings used by client devices.
-
-Example:
- dspgpio0: keystone_dsp_gpio@2620240 {
- compatible = "ti,keystone-dsp-gpio";
- ti,syscon-dev = <&devctrl 0x240>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- dsp0: dsp0 {
- compatible = "linux,rproc-user";
- ...
- kick-gpio = <&dspgpio0 27>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt b/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
deleted file mode 100644
index 54040a2bfe3a..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Spreadtrum EIC controller bindings
-
-The EIC is the abbreviation of external interrupt controller, which can
-be used only in input mode. The Spreadtrum platform has 2 EIC controllers,
-one is in digital chip, and another one is in PMIC. The digital chip EIC
-controller contains 4 sub-modules: EIC-debounce, EIC-latch, EIC-async and
-EIC-sync. But the PMIC EIC controller contains only one EIC-debounce sub-
-module.
-
-The EIC-debounce sub-module provides up to 8 source input signal
-connections. A debounce mechanism is used to capture the input signals'
-stable status (millisecond resolution) and a single-trigger mechanism
-is introduced into this sub-module to enhance the input event detection
-reliability. In addition, this sub-module's clock can be shut off
-automatically to reduce power dissipation. Moreover the debounce range
-is from 1ms to 4s with a step size of 1ms. The input signal will be
-ignored if it is asserted for less than 1 ms.
-
-The EIC-latch sub-module is used to latch some special power down signals
-and generate interrupts, since the EIC-latch does not depend on the APB
-clock to capture signals.
-
-The EIC-async sub-module uses a 32kHz clock to capture the short signals
-(microsecond resolution) to generate interrupts by level or edge trigger.
-
-The EIC-sync is similar with GPIO's input function, which is a synchronized
-signal input register. It can generate interrupts by level or edge trigger
-when detecting input signals.
-
-Required properties:
-- compatible: Should be one of the following:
- "sprd,sc9860-eic-debounce",
- "sprd,sc9860-eic-latch",
- "sprd,sc9860-eic-async",
- "sprd,sc9860-eic-sync",
- "sprd,sc2731-eic".
-- reg: Define the base and range of the I/O address space containing
- the GPIO controller registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be <2>. The first cell is the gpio number and
- the second cell is used to specify optional parameters.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be <2>. Specifies the number of cells needed
- to encode interrupt source.
-- interrupts: Should be the port interrupt shared by all the gpios.
-
-Example:
- eic_debounce: gpio@40210000 {
- compatible = "sprd,sc9860-eic-debounce";
- reg = <0 0x40210000 0 0x80>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- eic_latch: gpio@40210080 {
- compatible = "sprd,sc9860-eic-latch";
- reg = <0 0x40210080 0 0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- eic_async: gpio@402100a0 {
- compatible = "sprd,sc9860-eic-async";
- reg = <0 0x402100a0 0 0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- eic_sync: gpio@402100c0 {
- compatible = "sprd,sc9860-eic-sync";
- reg = <0 0x402100c0 0 0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- pmic_eic: gpio@300 {
- compatible = "sprd,sc2731-eic";
- reg = <0x300>;
- interrupt-parent = <&sc2731_pmic>;
- interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml
new file mode 100644
index 000000000000..3a1079d6ee20
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-ep9301.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-ep9301.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EP93xx GPIO controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-gpio
+ - items:
+ - enum:
+ - cirrus,ep9302-gpio
+ - cirrus,ep9307-gpio
+ - cirrus,ep9312-gpio
+ - cirrus,ep9315-gpio
+ - const: cirrus,ep9301-gpio
+
+ reg:
+ minItems: 2
+ items:
+ - description: data register
+ - description: direction register
+ - description: interrupt registers base
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: data
+ - const: dir
+ - const: intr
+
+ gpio-controller: true
+
+ gpio-ranges: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ oneOf:
+ - maxItems: 1
+ - description: port F has dedicated irq line for each gpio line
+ maxItems: 8
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@80840000 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840000 0x04>,
+ <0x80840010 0x04>,
+ <0x80840090 0x1c>;
+ reg-names = "data", "dir", "intr";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&vic1>;
+ interrupts = <27>;
+ };
+
+ gpio@80840004 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840004 0x04>,
+ <0x80840014 0x04>,
+ <0x808400ac 0x1c>;
+ reg-names = "data", "dir", "intr";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&vic1>;
+ interrupts = <27>;
+ };
+
+ gpio@80840008 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840008 0x04>,
+ <0x80840018 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@8084000c {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x8084000c 0x04>,
+ <0x8084001c 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@80840020 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840020 0x04>,
+ <0x80840024 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@80840030 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840030 0x04>,
+ <0x80840034 0x04>,
+ <0x8084004c 0x1c>;
+ reg-names = "data", "dir", "intr";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts-extended = <&vic0 19>, <&vic0 20>,
+ <&vic0 21>, <&vic0 22>,
+ <&vic1 15>, <&vic1 16>,
+ <&vic1 17>, <&vic1 18>;
+ };
+
+ gpio@80840038 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840038 0x04>,
+ <0x8084003c 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@80840040 {
+ compatible = "cirrus,ep9301-gpio";
+ reg = <0x80840040 0x04>,
+ <0x80840044 0x04>;
+ reg-names = "data", "dir";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/gpio/gpio-latch.yaml b/Documentation/devicetree/bindings/gpio/gpio-latch.yaml
new file mode 100644
index 000000000000..1ed82a2cebda
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-latch.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-latch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO latch controller
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+description: |
+ This binding describes a GPIO multiplexer based on latches connected to
+ other GPIOs, like this:
+
+ CLK0 ----------------------. ,--------.
+ CLK1 -------------------. `--------|> #0 |
+ | | |
+ OUT0 ----------------+--|-----------|D0 Q0|-----|<
+ OUT1 --------------+-|--|-----------|D1 Q1|-----|<
+ OUT2 ------------+-|-|--|-----------|D2 Q2|-----|<
+ OUT3 ----------+-|-|-|--|-----------|D3 Q3|-----|<
+ OUT4 --------+-|-|-|-|--|-----------|D4 Q4|-----|<
+ OUT5 ------+-|-|-|-|-|--|-----------|D5 Q5|-----|<
+ OUT6 ----+-|-|-|-|-|-|--|-----------|D6 Q6|-----|<
+ OUT7 --+-|-|-|-|-|-|-|--|-----------|D7 Q7|-----|<
+ | | | | | | | | | `--------'
+ | | | | | | | | |
+ | | | | | | | | | ,--------.
+ | | | | | | | | `-----------|> #1 |
+ | | | | | | | | | |
+ | | | | | | | `--------------|D0 Q0|-----|<
+ | | | | | | `----------------|D1 Q1|-----|<
+ | | | | | `------------------|D2 Q2|-----|<
+ | | | | `--------------------|D3 Q3|-----|<
+ | | | `----------------------|D4 Q4|-----|<
+ | | `------------------------|D5 Q5|-----|<
+ | `--------------------------|D6 Q6|-----|<
+ `----------------------------|D7 Q7|-----|<
+ `--------'
+
+ The number of clk-gpios and latched-gpios is not fixed. The actual number
+ of number of latches and the number of inputs per latch is derived from
+ the number of GPIOs given in the corresponding device tree properties.
+
+properties:
+ compatible:
+ const: gpio-latch
+ "#gpio-cells":
+ const: 2
+
+ clk-gpios:
+ description: Array of GPIOs to be used to clock a latch
+
+ latched-gpios:
+ description: Array of GPIOs to be used as inputs per latch
+
+ setup-duration-ns:
+ description: Delay in nanoseconds to wait after the latch inputs have been
+ set up
+
+ clock-duration-ns:
+ description: Delay in nanoseconds to wait between clock output changes
+
+ gpio-controller: true
+
+ gpio-line-names: true
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - gpio-controller
+ - clk-gpios
+ - latched-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio-latch {
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_di_do_leds>;
+ compatible = "gpio-latch";
+ gpio-controller;
+ setup-duration-ns = <100>;
+ clock-duration-ns = <100>;
+
+ clk-gpios = <&gpio3 7 0>, <&gpio3 8 0>;
+ latched-gpios = <&gpio3 21 0>, <&gpio3 22 0>,
+ <&gpio3 23 0>, <&gpio3 24 0>,
+ <&gpio3 25 0>, <&gpio3 26 0>,
+ <&gpio3 27 0>, <&gpio3 28 0>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
deleted file mode 100644
index 80fcb7d70e13..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-TI/National Semiconductor LP3943 GPIO controller
-
-Required properties:
- - compatible: "ti,lp3943-gpio"
- - gpio-controller: Marks the device node as a GPIO controller.
- - #gpio-cells: Should be 2. See gpio.txt in this directory for a
- description of the cells format.
-
-Example:
-Simple LED controls with LP3943 GPIO controller
-
-&i2c4 {
- lp3943@60 {
- compatible = "ti,lp3943";
- reg = <0x60>;
-
- gpioex: gpio {
- compatible = "ti,lp3943-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
- };
-};
-
-leds {
- compatible = "gpio-leds";
- indicator1 {
- label = "indi1";
- gpios = <&gpioex 9 GPIO_ACTIVE_LOW>;
- };
-
- indicator2 {
- label = "indi2";
- gpios = <&gpioex 10 GPIO_ACTIVE_LOW>;
- default-state = "off";
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-max3191x.txt b/Documentation/devicetree/bindings/gpio/gpio-max3191x.txt
deleted file mode 100644
index b3a6444b8f45..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-max3191x.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-GPIO driver for Maxim MAX3191x industrial serializer
-
-Required properties:
- - compatible: Must be one of:
- "maxim,max31910"
- "maxim,max31911"
- "maxim,max31912"
- "maxim,max31913"
- "maxim,max31953"
- "maxim,max31963"
- - reg: Chip select number.
- - gpio-controller: Marks the device node as a GPIO controller.
- - #gpio-cells: Should be two. For consumer use see gpio.txt.
-
-Optional properties:
- - #daisy-chained-devices:
- Number of chips in the daisy-chain (default is 1).
- - maxim,modesel-gpios: GPIO pins to configure modesel of each chip.
- The number of GPIOs must equal "#daisy-chained-devices"
- (if each chip is driven by a separate pin) or 1
- (if all chips are wired to the same pin).
- - maxim,fault-gpios: GPIO pins to read fault of each chip.
- The number of GPIOs must equal "#daisy-chained-devices"
- or 1.
- - maxim,db0-gpios: GPIO pins to configure debounce of each chip.
- The number of GPIOs must equal "#daisy-chained-devices"
- or 1.
- - maxim,db1-gpios: GPIO pins to configure debounce of each chip.
- The number of GPIOs must equal "maxim,db0-gpios".
- - maxim,modesel-8bit: Boolean whether the modesel pin of the chips is
- pulled high (8-bit mode). Use this if the modesel pin
- is hardwired and consequently "maxim,modesel-gpios"
- cannot be specified. By default if neither this nor
- "maxim,modesel-gpios" is given, the driver assumes
- that modesel is pulled low (16-bit mode).
- - maxim,ignore-undervoltage:
- Boolean whether to ignore undervoltage alarms signaled
- by the "maxim,fault-gpios" or by the status byte
- (in 16-bit mode). Use this if the chips are powered
- through 5VOUT instead of VCC24V, in which case they
- will constantly signal undervoltage.
-
-For other required and optional properties of SPI slave nodes please refer to
-../spi/spi-bus.txt.
-
-Example:
- gpio@0 {
- compatible = "maxim,max31913";
- reg = <0>;
- gpio-controller;
- #gpio-cells = <2>;
-
- maxim,modesel-gpios = <&gpio2 23>;
- maxim,fault-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
- maxim,db0-gpios = <&gpio2 25>;
- maxim,db1-gpios = <&gpio2 26>;
-
- spi-max-frequency = <25000000>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-max77620.txt b/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
deleted file mode 100644
index 410e716fd3d2..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-GPIO driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has 8 GPIO pins which can be configured as GPIO as well as the
-special IO functions.
-
-Required properties:
--------------------
-- gpio-controller : Marks the device node as a gpio controller.
-- #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-For more details, please refer generic GPIO DT binding document
-<devicetree/bindings/gpio/gpio.txt>.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
- compatible = "maxim,max77620";
-
- gpio-controller;
- #gpio-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt b/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt
deleted file mode 100644
index f93d51478d5a..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Lantiq SoC External Bus memory mapped GPIO controller
-
-By attaching hardware latches to the EBU it is possible to create output
-only gpios. This driver configures a special memory address, which when
-written to outputs 16 bit to the latches.
-
-The node describing the memory mapped GPIOs needs to be a child of the node
-describing the "lantiq,localbus".
-
-Required properties:
-- compatible : Should be "lantiq,gpio-mm-lantiq"
-- reg : Address and length of the register set for the device
-- #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify optional parameters (currently
- unused).
-- gpio-controller : Marks the device node as a gpio controller.
-
-Optional properties:
-- lantiq,shadow : The default value that we shall assume as already set on the
- shift register cascade.
-
-Example:
-
-localbus@0 {
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0 0x0 0x3ffffff /* addrsel0 */
- 1 0 0x4000000 0x4000010>; /* addsel1 */
- compatible = "lantiq,localbus", "simple-bus";
-
- gpio_mm0: gpio@4000000 {
- compatible = "lantiq,gpio-mm";
- reg = <1 0x0 0x10>;
- gpio-controller;
- #gpio-cells = <2>;
- lantiq,shadow = <0x77f>
- };
-}
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
new file mode 100644
index 000000000000..b4d55bf6a285
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MMIO GPIO
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+
+description:
+ Some simple GPIO controllers may consist of a single data register or a pair
+ of set/clear-bit registers. Such controllers are common for glue logic in
+ FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped
+ NAND-style parallel busses.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm6345-gpio
+ - ni,169445-nand-gpio
+ - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+ - intel,ixp4xx-expansion-bus-mmio-gpio
+
+ big-endian: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ little-endian: true
+
+ reg:
+ minItems: 1
+ description:
+ A list of registers in the controller. The width of each register is
+ determined by its size. All registers must have the same width. The number
+ of GPIOs is set by the width, with bit 0 corresponding to GPIO 0, unless
+ the ngpios property further restricts the number of used lines.
+ items:
+ - description:
+ Register to READ the value of the GPIO lines. If GPIO line is high,
+ the bit will be set. If the GPIO line is low, the bit will be cleared.
+ This register may also be used to drive GPIOs if the SET register is
+ omitted.
+ - description:
+ Register to SET the value of the GPIO lines. Setting a bit in this
+ register will drive the GPIO line high.
+ - description:
+ Register to CLEAR the value of the GPIO lines. Setting a bit in this
+ register will drive the GPIO line low. If this register is omitted,
+ the SET register will be used to clear the GPIO lines as well, by
+ actively writing the line with 0.
+ - description:
+ Register to set the line as OUTPUT. Setting a bit in this register
+ will turn that line into an output line. Conversely, clearing a bit
+ will turn that line into an input.
+ - description:
+ Register to set this line as INPUT. Setting a bit in this register
+ will turn that line into an input line. Conversely, clearing a bit
+ will turn that line into an output.
+
+ reg-names:
+ minItems: 1
+ maxItems: 5
+ items:
+ enum:
+ - dat
+ - set
+ - clr
+ - dirout
+ - dirin
+
+ native-endian: true
+
+ ngpios:
+ minimum: 1
+ maximum: 63
+ description:
+ If this property is present the number of usable GPIO lines are restricted
+ to the first 0 .. ngpios lines. This is useful when the GPIO MMIO register
+ has 32 bits for GPIO but only the first 12 are actually connected to
+ real electronics, and then we set ngpios to 12.
+
+ no-output:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If this property is present, the controller cannot drive the GPIO lines.
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: intel,ixp4xx-expansion-bus-mmio-gpio
+then:
+ $ref: /schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
+
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#gpio-cells'
+ - gpio-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gpio@1f300010 {
+ compatible = "ni,169445-nand-gpio";
+ reg = <0x1f300010 0x4>;
+ reg-names = "dat";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@e0100000 {
+ compatible = "wd,mbl-gpio";
+ reg-names = "dat";
+ reg = <0xe0100000 0x1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ no-output;
+ };
+
+ gpio@fffe0406 {
+ compatible = "brcm,bcm6345-gpio";
+ reg-names = "dirout", "dat";
+ reg = <0xfffe0406 2>, <0xfffe040a 2>;
+ ngpios = <15>;
+ native-endian;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ bus@c4000000 {
+ compatible = "intel,ixp42x-expansion-bus-controller", "syscon";
+ reg = <0xc4000000 0x30>;
+ native-endian;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x50000000 0x01000000>;
+ dma-ranges = <0 0x0 0x50000000 0x01000000>;
+ gpio@1,0 {
+ compatible = "intel,ixp4xx-expansion-bus-mmio-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ big-endian;
+ reg = <1 0x00000000 0x2>;
+ reg-names = "dat";
+ intel,ixp4xx-eb-write-enable = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt b/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
deleted file mode 100644
index 410759de9f09..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-moxtet.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Turris Mox Moxtet GPIO expander via Moxtet bus
-
-Required properties:
- - compatible : Should be "cznic,moxtet-gpio".
- - gpio-controller : Marks the device node as a GPIO controller.
- - #gpio-cells : Should be two. For consumer use see gpio.txt.
-
-Other properties are required for a Moxtet bus device, please refer to
-Documentation/devicetree/bindings/bus/moxtet.txt.
-
-Example:
-
- moxtet_sfp: gpio@0 {
- compatible = "cznic,moxtet-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <0>;
- }
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
deleted file mode 100644
index cd28e932bf50..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Freescale MPC512x/MPC8xxx/QorIQ/Layerscape GPIO controller
-
-Required properties:
-- compatible : Should be "fsl,<soc>-gpio"
- The following <soc>s are known to be supported:
- mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a, ls1028a, ls1088a.
-- reg : Address and length of the register set for the device
-- interrupts : Should be the port interrupt shared by all 32 pins.
-- #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-
-Optional properties:
-- little-endian : GPIO registers are used as little endian. If not
- present registers are used as big endian by default.
-
-Example of gpio-controller node for a mpc5125 SoC:
-
-gpio0: gpio@1100 {
- compatible = "fsl,mpc5125-gpio";
- #gpio-cells = <2>;
- reg = <0x1100 0x080>;
- interrupts = <78 0x8>;
-};
-
-Example of gpio-controller node for a ls2080a SoC:
-
-gpio0: gpio@2300000 {
- compatible = "fsl,ls2080a-gpio", "fsl,qoriq-gpio";
- reg = <0x0 0x2300000 0x0 0x10000>;
- interrupts = <0 36 0x4>; /* Level high type */
- gpio-controller;
- little-endian;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
-
-
-Example of gpio-controller node for a ls1028a/ls1088a SoC:
-
-gpio1: gpio@2300000 {
- compatible = "fsl,ls1028a-gpio", "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
- reg = <0x0 0x2300000 0x0 0x10000>;
- interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- little-endian;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
index f1bd1e6b2e1f..7ed5f9c4dde9 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
@@ -72,6 +72,9 @@ properties:
"#gpio-cells":
const: 2
+ gpio-ranges:
+ maxItems: 1
+
marvell,pwm-offset:
$ref: /schemas/types.yaml#/definitions/uint32
description: Offset in the register map for the pwm registers (in bytes)
@@ -96,6 +99,13 @@ properties:
- const: axi
minItems: 1
+patternProperties:
+ "^(.+-hog(-[0-9]+)?)$":
+ type: object
+
+ required:
+ - gpio-hog
+
required:
- compatible
- gpio-controller
@@ -115,7 +125,7 @@ allOf:
required:
- reg
-unevaluatedProperties: true
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml b/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
index dfa1133f8c5e..fed1b06495ad 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
@@ -8,7 +8,6 @@ title: Freescale MXS GPIO controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Anson Huang <Anson.Huang@nxp.com>
description: |
The Freescale MXS GPIO controller is part of MXS PIN controller.
@@ -19,12 +18,17 @@ description: |
properties:
compatible:
- enum:
- - fsl,imx23-pinctrl
- - fsl,imx28-pinctrl
+ items:
+ - enum:
+ - fsl,imx23-pinctrl
+ - fsl,imx28-pinctrl
+ # Over 10 years old devices, driver use simple-bus to probe child gpio
+ # Devices. Keep it as it to be compatible existed dts files.
+ - const: simple-bus
'#address-cells':
const: 1
+
'#size-cells':
const: 0
@@ -32,7 +36,65 @@ properties:
maxItems: 1
patternProperties:
- "gpio@[0-9]+$":
+ '^(?!gpio@)[^@]+@[0-9]+$':
+ type: object
+ properties:
+ fsl,pinmux-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An integer array. Each integer in the array specify a pin
+ with given mux function, with bank, pin and mux packed as below.
+
+ [15..12] : bank number
+ [11..4] : pin number
+ [3..0] : mux selection
+
+ This integer with mux selection packed is used as an entity by both group
+ and config nodes to identify a pin. The mux selection in the integer takes
+ effects only on group node, and will get ignored by driver with config node,
+ since config node is only meant to set up pin configurations.
+
+ Valid values for these integers are listed below.
+
+ reg:
+ items:
+ - description: |
+ pin group index. NOTE: it is supposed wrong use reg property
+ here. But it is over 10 years devices. Just keep it as it.
+
+ fsl,drive-strength:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ description: |
+ 0: MXS_DRIVE_4mA
+ 1: MXS_DRIVE_8mA
+ 2: MXS_DRIVE_12mA
+ 3: MXS_DRIVE_16mA
+
+ fsl,voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ 0: MXS_VOLTAGE_LOW - 1.8 V
+ 1: MXS_VOLTAGE_HIGH - 3.3 V
+
+ fsl,pull-up:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ 0: MXS_PULL_DISABLE - Disable the internal pull-up
+ 1: MXS_PULL_ENABLE - Enable the internal pull-up
+
+ Note that when enabling the pull-up, the internal pad keeper gets disabled.
+ Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
+ will only disable the internal pad keeper.
+
+ required:
+ - fsl,pinmux-ids
+
+ additionalProperties: false
+
+ '^gpio@[0-9]+$':
type: object
properties:
compatible:
@@ -49,10 +111,10 @@ patternProperties:
interrupt-controller: true
- "#interrupt-cells":
+ '#interrupt-cells':
const: 2
- "#gpio-cells":
+ '#gpio-cells':
const: 2
gpio-controller: true
@@ -62,8 +124,8 @@ patternProperties:
- reg
- interrupts
- interrupt-controller
- - "#interrupt-cells"
- - "#gpio-cells"
+ - '#interrupt-cells'
+ - '#gpio-cells'
- gpio-controller
additionalProperties: false
@@ -81,56 +143,64 @@ examples:
pinctrl@80018000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,imx28-pinctrl";
+ compatible = "fsl,imx28-pinctrl", "simple-bus";
reg = <0x80018000 0x2000>;
gpio@0 {
- compatible = "fsl,imx28-gpio";
- reg = <0>;
- interrupts = <127>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "fsl,imx28-gpio";
+ reg = <0>;
+ interrupts = <127>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
gpio@1 {
- compatible = "fsl,imx28-gpio";
- reg = <1>;
- interrupts = <126>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "fsl,imx28-gpio";
+ reg = <1>;
+ interrupts = <126>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
gpio@2 {
- compatible = "fsl,imx28-gpio";
- reg = <2>;
- interrupts = <125>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "fsl,imx28-gpio";
+ reg = <2>;
+ interrupts = <125>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
gpio@3 {
- compatible = "fsl,imx28-gpio";
- reg = <3>;
- interrupts = <124>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "fsl,imx28-gpio";
+ reg = <3>;
+ interrupts = <124>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
gpio@4 {
- compatible = "fsl,imx28-gpio";
- reg = <4>;
- interrupts = <123>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "fsl,imx28-gpio";
+ reg = <4>;
+ interrupts = <123>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ lcdif-apx4@5 {
+ reg = <5>;
+ fsl,pinmux-ids = <0x1181 0x1191>;
+ fsl,drive-strength = <0>;
+ fsl,voltage = <0>;
+ fsl,pull-up = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
deleted file mode 100644
index 8315ac7780ef..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Nomadik GPIO controller
-
-Required properties:
-- compatible : Should be "st,nomadik-gpio".
-- reg : Physical base address and length of the controller's registers.
-- interrupts : The interrupt outputs from the controller.
-- #gpio-cells : Should be two:
- The first cell is the pin number.
- The second cell is used to specify optional parameters:
- - bits[3:0] trigger type and level flags:
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 4 = active high level-sensitive.
- 8 = active low level-sensitive.
-- gpio-controller : Marks the device node as a GPIO controller.
-- interrupt-controller : Marks the device node as an interrupt controller.
-- gpio-bank : Specifies which bank a controller owns.
-- st,supports-sleepmode : Specifies whether controller can sleep or not
-
-Example:
-
- gpio1: gpio@8012e080 {
- compatible = "st,nomadik-gpio";
- reg = <0x8012e080 0x80>;
- interrupts = <0 120 0x4>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupt-controller;
- st,supports-sleepmode;
- gpio-bank = <1>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-palmas.txt b/Documentation/devicetree/bindings/gpio/gpio-palmas.txt
deleted file mode 100644
index 08b5b52a3ae0..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-palmas.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Palmas GPIO controller bindings
-
-Required properties:
-- compatible:
- - "ti,palams-gpio" for palma series of the GPIO controller
- - "ti,tps80036-gpio" for Palma series device TPS80036.
- - "ti,tps65913-gpio" for palma series device TPS65913.
- - "ti,tps65914-gpio" for palma series device TPS65914.
-- #gpio-cells : Should be two.
- - first cell is the gpio pin number
- - second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-- gpio-controller : Marks the device node as a GPIO controller.
-
-Note: This gpio node will be sub node of palmas node.
-
-Example:
- palmas: tps65913@58 {
- :::::::::::
- palmas_gpio: palmas_gpio {
- compatible = "ti,palmas-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
- :::::::::::
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml
deleted file mode 100644
index 1acaa0a3d35a..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml
+++ /dev/null
@@ -1,48 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/gpio/gpio-pca9570.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: PCA9570 I2C GPO expander
-
-maintainers:
- - Sungbo Eo <mans0n@gorani.run>
-
-properties:
- compatible:
- enum:
- - nxp,pca9570
- - nxp,pca9571
-
- reg:
- maxItems: 1
-
- gpio-controller: true
-
- '#gpio-cells':
- const: 2
-
-required:
- - compatible
- - reg
- - gpio-controller
- - "#gpio-cells"
-
-additionalProperties: false
-
-examples:
- - |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- gpio@24 {
- compatible = "nxp,pca9570";
- reg = <0x24>;
- gpio-controller;
- #gpio-cells = <2>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
index 977b14db09b0..12134c737ad8 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml
@@ -15,52 +15,65 @@ description: |+
properties:
compatible:
- enum:
- - exar,xra1202
- - maxim,max7310
- - maxim,max7312
- - maxim,max7313
- - maxim,max7315
- - maxim,max7319
- - maxim,max7320
- - maxim,max7321
- - maxim,max7322
- - maxim,max7323
- - maxim,max7324
- - maxim,max7325
- - maxim,max7326
- - maxim,max7327
- - nxp,pca6408
- - nxp,pca6416
- - nxp,pca9505
- - nxp,pca9506
- - nxp,pca9534
- - nxp,pca9535
- - nxp,pca9536
- - nxp,pca9537
- - nxp,pca9538
- - nxp,pca9539
- - nxp,pca9554
- - nxp,pca9555
- - nxp,pca9556
- - nxp,pca9557
- - nxp,pca9574
- - nxp,pca9575
- - nxp,pca9698
- - nxp,pcal6416
- - nxp,pcal6524
- - nxp,pcal9535
- - nxp,pcal9554b
- - nxp,pcal9555a
- - onnn,cat9554
- - onnn,pca9654
- - ti,pca6107
- - ti,pca9536
- - ti,tca6408
- - ti,tca6416
- - ti,tca6424
- - ti,tca9539
- - ti,tca9554
+ oneOf:
+ - items:
+ - const: toradex,ecgpiol16
+ - const: nxp,pcal6416
+ - items:
+ - const: diodes,pi4ioe5v6534q
+ - const: nxp,pcal6534
+ - items:
+ - enum:
+ - exar,xra1202
+ - maxim,max7310
+ - maxim,max7312
+ - maxim,max7313
+ - maxim,max7315
+ - maxim,max7319
+ - maxim,max7320
+ - maxim,max7321
+ - maxim,max7322
+ - maxim,max7323
+ - maxim,max7324
+ - maxim,max7325
+ - maxim,max7326
+ - maxim,max7327
+ - nxp,pca6408
+ - nxp,pca6416
+ - nxp,pca9505
+ - nxp,pca9506
+ - nxp,pca9534
+ - nxp,pca9535
+ - nxp,pca9536
+ - nxp,pca9537
+ - nxp,pca9538
+ - nxp,pca9539
+ - nxp,pca9554
+ - nxp,pca9555
+ - nxp,pca9556
+ - nxp,pca9557
+ - nxp,pca9574
+ - nxp,pca9575
+ - nxp,pca9698
+ - nxp,pcal6408
+ - nxp,pcal6416
+ - nxp,pcal6524
+ - nxp,pcal6534
+ - nxp,pcal9535
+ - nxp,pcal9554b
+ - nxp,pcal9555a
+ - onnn,cat9554
+ - onnn,pca9654
+ - ti,pca6107
+ - ti,pca9536
+ - ti,tca6408
+ - ti,tca6416
+ - ti,tca6418
+ - ti,tca6424
+ - ti,tca9535
+ - ti,tca9538
+ - ti,tca9539
+ - ti,tca9554
reg:
maxItems: 1
@@ -98,19 +111,8 @@ properties:
patternProperties:
"^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
type: object
- properties:
- gpio-hog: true
- gpios: true
- input: true
- output-high: true
- output-low: true
- line-name: true
-
required:
- gpio-hog
- - gpios
-
- additionalProperties: false
required:
- compatible
@@ -134,6 +136,7 @@ allOf:
- maxim,max7325
- maxim,max7326
- maxim,max7327
+ - toradex,ecgpiol16
then:
properties:
reset-gpios: false
@@ -144,7 +147,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -170,7 +173,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -196,7 +199,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c2 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -214,7 +217,7 @@ examples:
};
- |
- i2c3 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
deleted file mode 100644
index fba3c61f6a5b..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Generic Parallel-in/Serial-out Shift Register GPIO Driver
-
-This binding describes generic parallel-in/serial-out shift register
-devices that can be used for GPI (General Purpose Input). This includes
-SN74165 serial-out shift registers and the SN65HVS88x series of
-industrial serializers.
-
-Required properties:
- - compatible : Should be "pisosr-gpio".
- - gpio-controller : Marks the device node as a GPIO controller.
- - #gpio-cells : Should be two. For consumer use see gpio.txt.
-
-Optional properties:
- - ngpios : Number of used GPIO lines (0..n-1), default is 8.
- - load-gpios : GPIO pin specifier attached to load enable, this
- pin is pulsed before reading from the device to
- load input pin values into the device.
-
-For other required and optional properties of SPI slave
-nodes please refer to ../spi/spi-bus.txt.
-
-Example:
-
- gpio@0 {
- compatible = "ti,sn65hvs882", "pisosr-gpio";
- gpio-controller;
- #gpio-cells = <2>;
-
- load-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
-
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpol;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-sprd.txt b/Documentation/devicetree/bindings/gpio/gpio-sprd.txt
deleted file mode 100644
index eca97d45388f..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-sprd.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Spreadtrum GPIO controller bindings
-
-The controller's registers are organized as sets of sixteen 16-bit
-registers with each set controlling a bank of up to 16 pins. A single
-interrupt is shared for all of the banks handled by the controller.
-
-Required properties:
-- compatible: Should be "sprd,sc9860-gpio".
-- reg: Define the base and range of the I/O address space containing
-the GPIO controller registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be <2>. The first cell is the gpio number and
-the second cell is used to specify optional parameters.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be <2>. Specifies the number of cells needed
-to encode interrupt source.
-- interrupts: Should be the port interrupt shared by all the gpios.
-
-Example:
- ap_gpio: gpio@40280000 {
- compatible = "sprd,sc9860-gpio";
- reg = <0 0x40280000 0 0x1000>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt b/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt
deleted file mode 100644
index a0e4cf885213..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-STMPE gpio
-----------
-
-Required properties:
- - compatible: "st,stmpe-gpio"
-
-Optional properties:
- - st,norequest-mask: bitmask specifying which GPIOs should _not_ be requestable
- due to different usage (e.g. touch, keypad)
-
-Node name must be stmpe_gpio and should be child node of stmpe node to which it
-belongs.
-
-Example:
- stmpe_gpio {
- compatible = "st,stmpe-gpio";
- st,norequest-mask = <0x20>; //gpio 5 can't be used
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml b/Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml
deleted file mode 100644
index cb8a5c376e1e..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-tpic2810.yaml
+++ /dev/null
@@ -1,51 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/gpio/gpio-tpic2810.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: TPIC2810 GPIO controller bindings
-
-maintainers:
- - Aswath Govindraju <a-govindraju@ti.com>
-
-properties:
- compatible:
- enum:
- - ti,tpic2810
-
- reg:
- maxItems: 1
-
- gpio-controller: true
-
- "#gpio-cells":
- const: 2
-
- gpio-line-names:
- minItems: 1
- maxItems: 32
-
-required:
- - compatible
- - reg
- - gpio-controller
- - "#gpio-cells"
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- gpio@60 {
- compatible = "ti,tpic2810";
- reg = <0x60>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-line-names = "LED A", "LED B", "LED C";
- };
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-ts4800.txt b/Documentation/devicetree/bindings/gpio/gpio-ts4800.txt
deleted file mode 100644
index 92ea9c8f6399..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-ts4800.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* TS-4800 FPGA's GPIO controller bindings
-
-Required properties:
-- compatible: Must be "technologic,ts4800-gpio".
-- #gpio-cells: Should be two. The first cell is the pin number.
-- reg: Physical base address of the controller and length
- of memory mapped region.
-
-Optional property:
-- ngpios: See "gpio.txt"
-
-Example:
-
-gpio1: gpio {
- compatible = "technologic,ts4800-gpio";
- reg = <0x10020 0x6>;
- ngpios = <8>;
- gpio-controller;
- #gpio-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-ts4900.txt b/Documentation/devicetree/bindings/gpio/gpio-ts4900.txt
deleted file mode 100644
index 3f8e71b1ab2a..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-ts4900.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Technologic Systems I2C-FPGA's GPIO controller bindings
-
-This bindings describes the GPIO controller for Technologic's FPGA core.
-TS-4900's FPGA encodes the GPIO state on 3 bits, whereas the TS-7970's FPGA
-uses 2 bits: it doesn't use a dedicated input bit.
-
-Required properties:
-- compatible: Should be one of the following
- "technologic,ts4900-gpio"
- "technologic,ts7970-gpio"
-- reg: Physical base address of the controller and length
- of memory mapped region.
-- #gpio-cells: Should be two. The first cell is the pin number.
-- gpio-controller: Marks the device node as a gpio controller.
-
-Optional property:
-- ngpios: Number of GPIOs this controller is instantiated with,
- the default is 32. See gpio.txt for more details.
-
-Example:
-
-&i2c2 {
- gpio8: gpio@28 {
- compatible = "technologic,ts4900-gpio";
- reg = <0x28>;
- #gpio-cells = <2>;
- gpio-controller;
- ngpios = <32>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt b/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
deleted file mode 100644
index 66788fda1db3..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-twl4030 GPIO controller bindings
-
-Required properties:
-- compatible:
- - "ti,twl4030-gpio" for twl4030 GPIO controller
-- #gpio-cells : Should be two.
- - first cell is the pin number
- - second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
-- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
- The first cell is the GPIO number.
- The second cell is not used.
-- ti,use-leds : Enables LEDA and LEDB outputs if set
-- ti,debounce : if n-th bit is set, debounces GPIO-n
-- ti,mmc-cd : if n-th bit is set, GPIO-n controls VMMC(n+1)
-- ti,pullups : if n-th bit is set, set a pullup on GPIO-n
-- ti,pulldowns : if n-th bit is set, set a pulldown on GPIO-n
-
-Example:
-
-twl_gpio: gpio {
- compatible = "ti,twl4030-gpio";
- #gpio-cells = <2>;
- gpio-controller;
- #interrupt-cells = <2>;
- interrupt-controller;
- ti,use-leds;
-};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
index d2c39dba56ad..a31f64b6d40b 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
@@ -20,6 +20,7 @@ description: |
properties:
compatible:
oneOf:
+ - const: fsl,imx8ulp-gpio
- const: fsl,vf610-gpio
- items:
- const: fsl,imx7ulp-gpio
@@ -27,16 +28,19 @@ properties:
- items:
- enum:
- fsl,imx93-gpio
- - fsl,imx8ulp-gpio
- - const: fsl,imx7ulp-gpio
+ - fsl,imx94-gpio
+ - fsl,imx95-gpio
+ - const: fsl,imx8ulp-gpio
reg:
- description: The first reg tuple represents the PORT module, the second tuple
- represents the GPIO module.
+ minItems: 1
maxItems: 2
interrupts:
- maxItems: 1
+ items:
+ - description: GPIO Trustzone non-secure interrupt number
+ - description: GPIO Trustzone secure interrupt number
+ minItems: 1
interrupt-controller: true
@@ -48,6 +52,10 @@ properties:
gpio-controller: true
+ gpio-line-names:
+ minItems: 1
+ maxItems: 32
+
clocks:
items:
- description: SoC GPIO clock
@@ -59,7 +67,22 @@ properties:
- const: port
gpio-ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
+
+ gpio-reserved-ranges: true
+
+ ngpios:
+ minimum: 1
+ maximum: 32
+ default: 32
+
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
required:
- compatible
@@ -70,6 +93,30 @@ required:
- "#gpio-cells"
- gpio-controller
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,vf610-gpio
+ - fsl,imx7ulp-gpio
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ reg:
+ items:
+ - description: PORT register base address
+ - description: GPIO register base address
+ else:
+ properties:
+ interrupts:
+ minItems: 2
+ reg:
+ items:
+ - description: GPIO register base address
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
deleted file mode 100644
index e90fb987e25f..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-APM X-Gene Standby GPIO controller bindings
-
-This is a gpio controller in the standby domain. It also supports interrupt in
-some particular pins which are sourced to its parent interrupt controller
-as diagram below:
- +-----------------+
- | X-Gene standby |
- | GPIO controller +------ GPIO_0
-+------------+ | | ...
-| Parent IRQ | EXT_INT_0 | +------ GPIO_8/EXT_INT_0
-| controller | (SPI40) | | ...
-| (GICv2) +--------------+ +------ GPIO_[N+8]/EXT_INT_N
-| | ... | |
-| | EXT_INT_N | +------ GPIO_[N+9]
-| | (SPI[40 + N])| | ...
-| +--------------+ +------ GPIO_MAX
-+------------+ +-----------------+
-
-Required properties:
-- compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
-- reg: Physical base address and size of the controller's registers
-- #gpio-cells: Should be two.
- - first cell is the pin number
- - second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-- gpio-controller: Marks the device node as a GPIO controller.
-- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
-- interrupt-cells: Should be two.
- - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
- - second cell is used to specify flags.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- apm,nr-gpios: Optional, specify number of gpios pin.
-- apm,nr-irqs: Optional, specify number of interrupt pins.
-- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
-
-Example:
- sbgpio: gpio@17001000{
- compatible = "apm,xgene-gpio-sb";
- reg = <0x0 0x17001000 0x0 0x400>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupts = <0x0 0x28 0x1>,
- <0x0 0x29 0x1>,
- <0x0 0x2a 0x1>,
- <0x0 0x2b 0x1>,
- <0x0 0x2c 0x1>,
- <0x0 0x2d 0x1>;
- interrupt-parent = <&gic>;
- #interrupt-cells = <2>;
- interrupt-controller;
- apm,nr-gpios = <22>;
- apm,nr-irqs = <6>;
- apm,irq-start = <8>;
- };
-
- testuser {
- compatible = "example,testuser";
- /* Use the GPIO_13/EXT_INT_5 line as an active high triggered
- * level interrupt
- */
- interrupts = <5 4>;
- interrupt-parent = <&sbgpio>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene.txt
deleted file mode 100644
index 86dbb05e7758..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-xgene.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-APM X-Gene SoC GPIO controller bindings
-
-This is a gpio controller that is part of the flash controller.
-This gpio controller controls a total of 48 gpios.
-
-Required properties:
-- compatible: "apm,xgene-gpio" for X-Gene GPIO controller
-- reg: Physical base address and size of the controller's registers
-- #gpio-cells: Should be two.
- - first cell is the pin number
- - second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-- gpio-controller: Marks the device node as a GPIO controller.
-
-Example:
- gpio0: gpio0@1701c000 {
- compatible = "apm,xgene-gpio";
- reg = <0x0 0x1701c000 0x0 0x40>;
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
deleted file mode 100644
index e506f30e1a95..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Xilinx plb/axi GPIO controller
-
-Dual channel GPIO controller with configurable number of pins
-(from 1 to 32 per channel). Every pin can be configured as
-input/output/tristate. Both channels share the same global IRQ but
-local interrupts can be enabled on channel basis.
-
-Required properties:
-- compatible : Should be "xlnx,xps-gpio-1.00.a"
-- reg : Address and length of the register set for the device
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters (currently unused).
-- gpio-controller : Marks the device node as a GPIO controller.
-
-Optional properties:
-- clocks : Input clock specifier. Refer to common clock bindings.
-- interrupts : Interrupt mapping for GPIO IRQ.
-- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
-- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
-- xlnx,gpio-width : gpio width
-- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode
-- xlnx,is-dual : if 1, controller also uses the second channel
-- xlnx,all-inputs-2 : as above but for the second channel
-- xlnx,dout-default-2 : as above but the second channel
-- xlnx,gpio2-width : as above but for the second channel
-- xlnx,tri-default-2 : as above but for the second channel
-
-
-Example:
-gpio: gpio@40000000 {
- #gpio-cells = <2>;
- compatible = "xlnx,xps-gpio-1.00.a";
- clocks = <&clkc25>;
- gpio-controller ;
- interrupt-parent = <&microblaze_0_intc>;
- interrupts = < 6 2 >;
- reg = < 0x40000000 0x10000 >;
- xlnx,all-inputs = <0x0>;
- xlnx,all-inputs-2 = <0x0>;
- xlnx,dout-default = <0x0>;
- xlnx,dout-default-2 = <0x0>;
- xlnx,gpio-width = <0x2>;
- xlnx,gpio2-width = <0x2>;
- xlnx,interrupt-present = <0x1>;
- xlnx,is-dual = <0x1>;
- xlnx,tri-default = <0xffffffff>;
- xlnx,tri-default-2 = <0xffffffff>;
-} ;
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xra1403.txt b/Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
deleted file mode 100644
index e13cc399b363..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-GPIO Driver for XRA1403 16-BIT GPIO Expander With Reset Input from EXAR
-
-The XRA1403 is an 16-bit GPIO expander with an SPI interface. Features available:
- - Individually programmable inputs:
- - Internal pull-up resistors
- - Polarity inversion
- - Individual interrupt enable
- - Rising edge and/or Falling edge interrupt
- - Input filter
- - Individually programmable outputs
- - Output Level Control
- - Output Three-State Control
-
-Properties
-----------
-Check documentation for SPI and GPIO controllers regarding properties needed to configure the node.
-
- - compatible = "exar,xra1403".
- - reg - SPI id of the device.
- - gpio-controller - marks the node as gpio.
- - #gpio-cells - should be two where the first cell is the pin number
- and the second one is used for optional parameters.
-
-Optional properties:
--------------------
- - reset-gpios: in case available used to control the device reset line.
- - interrupt-controller - marks the node as interrupt controller.
- - #interrupt-cells - should be two and represents the number of cells
- needed to encode interrupt source.
-
-Example
---------
-
- gpioxra0: gpio@2 {
- compatible = "exar,xra1403";
- reg = <2>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
- spi-max-frequency = <1000000>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
deleted file mode 100644
index a37bd9ae2730..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Zevio GPIO controller
-
-Required properties:
-- compatible: Should be "lsi,zevio-gpio"
-- reg: Address and length of the register set for the device
-- #gpio-cells: Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters (currently unused).
-- gpio-controller: Marks the device node as a GPIO controller.
-
-Example:
- gpio: gpio@90000000 {
- compatible = "lsi,zevio-gpio";
- reg = <0x90000000 0x1000>;
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
index 29c27eadbac8..5e2496379a3c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/gpio/gpio-zynq.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx Zynq GPIO controller Device Tree Bindings
+title: Xilinx Zynq GPIO controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 5663e71b751f..b37dbb1edc62 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -35,8 +35,8 @@ and bit-banged data signals:
<&gpio1 15 0>;
In the above example, &gpio1 uses 2 cells to specify a gpio. The first cell is
-a local offset to the GPIO line and the second cell represent consumer flags,
-such as if the consumer desire the line to be active low (inverted) or open
+a local offset to the GPIO line and the second cell represents consumer flags,
+such as if the consumer desires the line to be active low (inverted) or open
drain. This is the recommended practice.
The exact meaning of each specifier cell is controller specific, and must be
@@ -59,7 +59,7 @@ GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
Optional standard bitfield specifiers for the last cell:
- Bit 0: 0 means active high, 1 means active low
-- Bit 1: 0 mean push-pull wiring, see:
+- Bit 1: 0 means push-pull wiring, see:
https://en.wikipedia.org/wiki/Push-pull_output
1 means single-ended wiring, see:
https://en.wikipedia.org/wiki/Single-ended_triode
@@ -154,18 +154,35 @@ of the GPIOs that can't be used.
Optionally, a GPIO controller may have a "gpio-line-names" property. This is
an array of strings defining the names of the GPIO lines going out of the
-GPIO controller. This name should be the most meaningful producer name
-for the system, such as a rail name indicating the usage. Package names
-such as pin name are discouraged: such lines have opaque names (since they
-are by definition generic purpose) and such names are usually not very
-helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are
-reasonable line names as they describe what the line is used for. "GPIO0"
-is not a good name to give to a GPIO line. Placeholders are discouraged:
-rather use the "" (blank string) if the use of the GPIO line is undefined
-in your design. The names are assigned starting from line offset 0 from
-left to right from the passed array. An incomplete array (where the number
-of passed named are less than ngpios) will still be used up until the last
-provided valid line index.
+GPIO controller.
+
+For lines which are routed to on-board devices, this name should be
+the most meaningful producer name for the system, such as a rail name
+indicating the usage. Package names, such as a pin name, are discouraged:
+such lines have opaque names (since they are by definition general-purpose)
+and such names are usually not very helpful. For example "MMC-CD", "Red LED
+Vdd" and "ethernet reset" are reasonable line names as they describe what
+the line is used for. "GPIO0" is not a good name to give to a GPIO line
+that is hard-wired to a specific device.
+
+However, in the case of lines that are routed to a general purpose header
+(e.g. the Raspberry Pi 40-pin header), and therefore are not hard-wired to
+specific devices, using a pin number or the names on the header is fine
+provided these are real (preferably unique) names. Using an SoC's pad name
+or package name, or names made up from kernel-internal software constructs,
+are strongly discouraged. For example "pin8 [gpio14/uart0_txd]" is fine
+if the board's documentation labels pin 8 as such. However "PortB_24" (an
+example of a name from an SoC's reference manual) would not be desirable.
+
+In either case placeholders are discouraged: rather use the "" (blank
+string) if the use of the GPIO line is undefined in your design. Ideally,
+try to add comments to the dts file describing the naming convention
+you have chosen, and specifying from where the names are derived.
+
+The names are assigned starting from line offset 0, from left to right,
+from the passed array. An incomplete array (where the number of passed
+names is less than ngpios) will be used up until the last provided valid
+line index.
Example:
@@ -287,7 +304,7 @@ pins 50..69.
It is also possible to use pin groups for gpio ranges when pin groups are the
easiest and most convenient mapping.
-Both both <pinctrl-base> and <count> must set to 0 when using named pin groups
+Both <pinctrl-base> and <count> must be set to 0 when using named pin groups
names.
The property gpio-ranges-group-names must contain exactly one string for each
@@ -296,7 +313,7 @@ range.
Elements of gpio-ranges-group-names must contain the name of a pin group
defined in the respective pin controller. The number of pins/GPIO lines in the
range is the number of pins in that pin group. The number of pins of that
-group is defined int the implementation and not in the device tree.
+group is defined in the implementation and not in the device tree.
If numerical and named pin groups are mixed, the string corresponding to a
numerical pin range in gpio-ranges-group-names must be empty.
diff --git a/Documentation/devicetree/bindings/gpio/gpio_atmel.txt b/Documentation/devicetree/bindings/gpio/gpio_atmel.txt
deleted file mode 100644
index 29416f9c3220..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio_atmel.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* Atmel GPIO controller (PIO)
-
-Required properties:
-- compatible: "atmel,<chip>-gpio", where <chip> is at91rm9200 or at91sam9x5.
-- reg: Should contain GPIO controller registers location and length
-- interrupts: Should be the port interrupt shared by all the pins.
-- #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify optional parameters to declare if the GPIO
- is active high or low. See gpio.txt.
-- gpio-controller: Marks the device node as a GPIO controller.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two. The first cell is the pin number and the
- second cell is used to specify irq type flags, see the two cell description
- in interrupt-controller/interrupts.txt for details.
-
-optional properties:
-- #gpio-lines: Number of gpio if absent 32.
-
-
-Example:
- pioA: gpio@fffff200 {
- compatible = "atmel,at91rm9200-gpio";
- reg = <0xfffff200 0x100>;
- interrupts = <2 4>;
- #gpio-cells = <2>;
- gpio-controller;
- #gpio-lines = <19>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
diff --git a/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt b/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt
deleted file mode 100644
index 49819367a011..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-NXP LPC32xx SoC GPIO controller
-
-Required properties:
-- compatible: must be "nxp,lpc3220-gpio"
-- reg: Physical base address and length of the controller's registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be 3:
- 1) bank:
- 0: GPIO P0
- 1: GPIO P1
- 2: GPIO P2
- 3: GPIO P3
- 4: GPI P3
- 5: GPO P3
- 2) pin number
- 3) optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted)
-- reg: Index of the GPIO group
-
-Example:
-
- gpio: gpio@40028000 {
- compatible = "nxp,lpc3220-gpio";
- reg = <0x40028000 0x1000>;
- gpio-controller;
- #gpio-cells = <3>; /* bank, pin, flags */
- };
-
- leds {
- compatible = "gpio-leds";
-
- led0 {
- gpios = <&gpio 5 1 1>; /* GPO_P3 1, active low */
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
-
- led1 {
- gpios = <&gpio 5 14 1>; /* GPO_P3 14, active low */
- linux,default-trigger = "timer";
- default-state = "off";
- };
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt b/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
deleted file mode 100644
index 966514744df4..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio_oxnas.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Oxford Semiconductor OXNAS SoC GPIO Controller
-
-Please refer to gpio.txt for generic information regarding GPIO bindings.
-
-Required properties:
- - compatible: "oxsemi,ox810se-gpio" or "oxsemi,ox820-gpio"
- - reg: Base address and length for the device.
- - interrupts: The port interrupt shared by all pins.
- - gpio-controller: Marks the port as GPIO controller.
- - #gpio-cells: Two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity as defined in
- defined in <dt-bindings/gpio/gpio.h>:
- 0 = GPIO_ACTIVE_HIGH
- 1 = GPIO_ACTIVE_LOW
- - interrupt-controller: Marks the device node as an interrupt controller.
- - #interrupt-cells: Two. The first cell is the GPIO number and second cell
- is used to specify the trigger type as defined in
- <dt-bindings/interrupt-controller/irq.h>:
- IRQ_TYPE_EDGE_RISING
- IRQ_TYPE_EDGE_FALLING
- IRQ_TYPE_EDGE_BOTH
- - gpio-ranges: Interaction with the PINCTRL subsystem, it also specifies the
- gpio base and count, should be in the format of numeric-gpio-range as
- specified in the gpio.txt file.
-
-Example:
-
-gpio0: gpio@0 {
- compatible = "oxsemi,ox810se-gpio";
- reg = <0x000000 0x100000>;
- interrupts = <21>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&pinctrl 0 0 32>;
-};
-
-keys {
- ...
-
- button-esc {
- label = "ESC";
- linux,code = <1>;
- gpios = <&gpio0 12 0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/hisilicon,ascend910-gpio.yaml b/Documentation/devicetree/bindings/gpio/hisilicon,ascend910-gpio.yaml
new file mode 100644
index 000000000000..735d97d645a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/hisilicon,ascend910-gpio.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/hisilicon,ascend910-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon common GPIO controller
+
+maintainers:
+ - Jay Fang <f.fangjian@huawei.com>
+
+description:
+ The HiSilicon common GPIO controller can be used for many different
+ types of SoC such as Huawei Ascend AI series chips.
+
+properties:
+ compatible:
+ const: hisilicon,ascend910-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ ngpios:
+ minimum: 1
+ maximum: 32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - gpio-controller
+ - "#gpio-cells"
+ - ngpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpio@840d0000 {
+ compatible = "hisilicon,ascend910-gpio";
+ reg = <0x840d0000 0x1000>;
+ ngpios = <32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/ibm,ppc4xx-gpio.txt b/Documentation/devicetree/bindings/gpio/ibm,ppc4xx-gpio.txt
deleted file mode 100644
index d58b3958f3ea..000000000000
--- a/Documentation/devicetree/bindings/gpio/ibm,ppc4xx-gpio.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* IBM/AMCC/APM GPIO Controller for PowerPC 4XX series and compatible SoCs
-
-All GPIOs are pin-shared with other functions. DCRs control whether a
-particular pin that has GPIO capabilities acts as a GPIO or is used for
-another purpose. GPIO outputs are separately programmable to emulate
-an open-drain driver.
-
-Required properties:
- - compatible: must be "ibm,ppc4xx-gpio"
- - reg: address and length of the register set for the device
- - #gpio-cells: must be set to 2. The first cell is the pin number
- and the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
- - gpio-controller: marks the device node as a gpio controller.
-
-Example:
-
-GPIO0: gpio@ef600b00 {
- compatible = "ibm,ppc4xx-gpio";
- reg = <0xef600b00 0x00000048>;
- #gpio-cells = <2>;
- gpio-controller;
-};
diff --git a/Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt b/Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt
deleted file mode 100644
index 8dc41ed99685..000000000000
--- a/Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Intel IXP4xx XScale Networking Processors GPIO
-
-This GPIO controller is found in the Intel IXP4xx processors.
-It supports 16 GPIO lines.
-
-The interrupt portions of the GPIO controller is hierarchical:
-the synchronous edge detector is part of the GPIO block, but the
-actual enabling/disabling of the interrupt line is done in the
-main IXP4xx interrupt controller which has a 1:1 mapping for
-the first 12 GPIO lines to 12 system interrupts.
-
-The remaining 4 GPIO lines can not be used for receiving
-interrupts.
-
-The interrupt parent of this GPIO controller must be the
-IXP4xx interrupt controller.
-
-Required properties:
-
-- compatible : Should be
- "intel,ixp4xx-gpio"
-- reg : Should contain registers location and length
-- gpio-controller : marks this as a GPIO controller
-- #gpio-cells : Should be 2, see gpio/gpio.txt
-- interrupt-controller : marks this as an interrupt controller
-- #interrupt-cells : a standard two-cell interrupt, see
- interrupt-controller/interrupts.txt
-
-Example:
-
-gpio0: gpio@c8004000 {
- compatible = "intel,ixp4xx-gpio";
- reg = <0xc8004000 0x1000>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.yaml b/Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.yaml
new file mode 100644
index 000000000000..bfcb1f364c3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/intel,ixp4xx-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel IXP4xx XScale Networking Processors GPIO Controller
+
+description: |
+ This GPIO controller is found in the Intel IXP4xx
+ processors. It supports 16 GPIO lines.
+ The interrupt portions of the GPIO controller is hierarchical.
+ The synchronous edge detector is part of the GPIO block, but the
+ actual enabling/disabling of the interrupt line is done in the
+ main IXP4xx interrupt controller which has a 1-to-1 mapping for
+ the first 12 GPIO lines to 12 system interrupts.
+ The remaining 4 GPIO lines can not be used for receiving
+ interrupts.
+ The interrupt parent of this GPIO controller must be the
+ IXP4xx interrupt controller.
+ GPIO 14 and 15 can be used as clock outputs rather than GPIO,
+ and this can be enabled by a special flag.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ const: intel,ixp4xx-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ intel,ixp4xx-gpio14-clkout:
+ description: If defined, enables clock output on GPIO 14
+ instead of GPIO.
+ type: boolean
+
+ intel,ixp4xx-gpio15-clkout:
+ description: If defined, enables clock output on GPIO 15
+ instead of GPIO.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ gpio@c8004000 {
+ compatible = "intel,ixp4xx-gpio";
+ reg = <0xc8004000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
index b032471831e7..02663d67eac7 100644
--- a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
This module is part of the sl28cpld multi-function device. For more
- details see ../mfd/kontron,sl28cpld.yaml.
+ details see ../embedded-controller/kontron,sl28cpld.yaml.
There are three flavors of the GPIO controller, one full featured
input/output with interrupt support (kontron,sl28cpld-gpio), one
diff --git a/Documentation/devicetree/bindings/gpio/lacie,netxbig-gpio-ext.yaml b/Documentation/devicetree/bindings/gpio/lacie,netxbig-gpio-ext.yaml
new file mode 100644
index 000000000000..42021ee14125
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/lacie,netxbig-gpio-ext.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/lacie,netxbig-gpio-ext.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NetxBig GPIO extension bus
+
+maintainers:
+ - Simon Guinot <simon.guinot@sequanux.org>
+
+description: >
+ GPIO extension bus found on some LaCie/Seagate boards
+ (Example: 2Big/5Big Network v2, 2Big NAS).
+
+properties:
+ compatible:
+ items:
+ - const: lacie,netxbig-gpio-ext
+
+ addr-gpios:
+ description: GPIOs representing the address register (LSB->MSB).
+ items:
+ - description: bit 0 (LSB)
+ - description: bit 1
+ - description: bit 2 (MSB)
+
+ data-gpios:
+ description: GPIOs representing the data register (LSB->MSB).
+ items:
+ - description: bit 0 (LSB)
+ - description: bit 1
+ - description: bit 2 (MSB)
+
+ enable-gpio:
+ description: Latches the new configuration (address, data) on raising edge.
+ maxItems: 1
+
+required:
+ - compatible
+ - addr-gpios
+ - data-gpios
+ - enable-gpio
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ gpio {
+ compatible = "lacie,netxbig-gpio-ext";
+ addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH
+ &gpio1 16 GPIO_ACTIVE_HIGH
+ &gpio1 17 GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH
+ &gpio1 13 GPIO_ACTIVE_HIGH
+ &gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/lantiq,gpio-mm-lantiq.yaml b/Documentation/devicetree/bindings/gpio/lantiq,gpio-mm-lantiq.yaml
new file mode 100644
index 000000000000..eaf53a89542a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/lantiq,gpio-mm-lantiq.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/lantiq,gpio-mm-lantiq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq SoC External Bus memory mapped GPIO controller
+
+maintainers:
+ - John Crispin <john@phrozen.org>
+
+description: |
+ By attaching hardware latches to the EBU it is possible to create output
+ only gpios. This driver configures a special memory address, which when
+ written to outputs 16 bit to the latches.
+
+ The node describing the memory mapped GPIOs needs to be a child of the node
+ describing the "lantiq,localbus".
+
+properties:
+ compatible:
+ enum:
+ - lantiq,gpio-mm-lantiq
+ - lantiq,gpio-mm
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ lantiq,shadow:
+ description: The default value that we shall assume as already set on the shift register cascade.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@4000000 {
+ compatible = "lantiq,gpio-mm-lantiq";
+ reg = <0x4000000 0x10>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ lantiq,shadow = <0x77f>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
new file mode 100644
index 000000000000..69852444df23
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/loongson,ls-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson GPIO controller.
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls2k-gpio
+ - loongson,ls2k0300-gpio
+ - loongson,ls2k0500-gpio0
+ - loongson,ls2k0500-gpio1
+ - loongson,ls2k2000-gpio0
+ - loongson,ls2k2000-gpio1
+ - loongson,ls2k2000-gpio2
+ - loongson,ls3a5000-gpio
+ - loongson,ls3a6000-gpio # Loongson-3A6000 node GPIO
+ - loongson,ls7a-gpio
+ - loongson,ls7a2000-gpio1 # LS7A2000 chipset GPIO
+ - loongson,ls7a2000-gpio2 # LS7A2000 ACPI GPIO
+ - items:
+ - const: loongson,ls2k1000-gpio
+ - const: loongson,ls2k-gpio
+ - items:
+ - const: loongson,ls7a1000-gpio
+ - const: loongson,ls7a-gpio
+
+ reg:
+ maxItems: 1
+
+ ngpios:
+ minimum: 1
+ maximum: 128
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ gpio-ranges: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 64
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - ngpios
+ - "#gpio-cells"
+ - gpio-controller
+ - gpio-ranges
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: loongson,ls2k0300-gpio
+ then:
+ required:
+ - "#interrupt-cells"
+ - interrupt-controller
+ - resets
+ else:
+ properties:
+ "#interrupts-cells": false
+ interrupt-controller: false
+ resets: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio0: gpio@1fe00500 {
+ compatible = "loongson,ls2k1000-gpio", "loongson,ls2k-gpio";
+ reg = <0x1fe00500 0x38>;
+ ngpios = <64>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&pctrl 0 0 15>,
+ <&pctrl 16 16 15>,
+ <&pctrl 32 32 10>,
+ <&pctrl 44 44 20>;
+ interrupt-parent = <&liointc1>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>,
+ <29 IRQ_TYPE_LEVEL_LOW>,
+ <30 IRQ_TYPE_LEVEL_LOW>,
+ <30 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <26 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <>,
+ <>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>,
+ <27 IRQ_TYPE_LEVEL_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/lsi,zevio-gpio.yaml b/Documentation/devicetree/bindings/gpio/lsi,zevio-gpio.yaml
new file mode 100644
index 000000000000..e9e201a489e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/lsi,zevio-gpio.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/lsi,zevio-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zevio GPIO controller
+
+maintainers:
+ - Pratik Farkase <pratikfarkase94@gmail.com>
+
+properties:
+ compatible:
+ items:
+ - const: lsi,zevio-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gpio@90000000 {
+ compatible = "lsi,zevio-gpio";
+ reg = <0x90000000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/maxim,max31910.yaml b/Documentation/devicetree/bindings/gpio/maxim,max31910.yaml
new file mode 100644
index 000000000000..4d200f9dffd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/maxim,max31910.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/maxim,max31910.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX3191x GPIO serializer
+
+maintainers:
+ - Lukas Wunner <lukas@wunner.de>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max31910
+ - maxim,max31911
+ - maxim,max31912
+ - maxim,max31913
+ - maxim,max31953
+ - maxim,max31963
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ '#daisy-chained-devices':
+ description: Number of chips in the daisy-chain.
+ default: 1
+
+ maxim,modesel-gpios:
+ description:
+ GPIO pins to configure modesel of each chip. The number of GPIOs must
+ equal "#daisy-chained-devices" (if each chip is driven by a separate pin)
+ or 1 (if all chips are wired to the same pin).
+
+ maxim,fault-gpios:
+ description:
+ GPIO pins to read fault of each chip. The number of GPIOs must equal
+ "#daisy-chained-devices" or 1.
+
+ maxim,db0-gpios:
+ description:
+ GPIO pins to configure debounce of each chip. The number of GPIOs must
+ equal "#daisy-chained-devices" or 1.
+
+ maxim,db1-gpios:
+ description:
+ GPIO pins to configure debounce of each chip. The number of GPIOs must
+ equal "maxim,db0-gpios".
+
+ maxim,modesel-8bit:
+ description:
+ Boolean whether the modesel pin of the chips is pulled high (8-bit mode).
+ Use this if the modesel pin is hardwired and consequently
+ "maxim,modesel-gpios" cannot be specified. By default if neither this nor
+ "maxim,modesel-gpios" is given, the driver assumes that modesel is pulled
+ low (16-bit mode).
+ type: boolean
+
+ maxim,ignore-undervoltage:
+ description:
+ Boolean whether to ignore undervoltage alarms signaled by the
+ "maxim,fault-gpios" or by the status byte (in 16-bit mode). Use this if
+ the chips are powered through 5VOUT instead of VCC24V, in which case they
+ will constantly signal undervoltage.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@0 {
+ compatible = "maxim,max31913";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ maxim,modesel-gpios = <&gpio2 23>;
+ maxim,fault-gpios = <&gpio2 24 GPIO_ACTIVE_LOW>;
+ maxim,db0-gpios = <&gpio2 25>;
+ maxim,db1-gpios = <&gpio2 26>;
+
+ spi-max-frequency = <25000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/maxim,max7360-gpio.yaml b/Documentation/devicetree/bindings/gpio/maxim,max7360-gpio.yaml
new file mode 100644
index 000000000000..c5c3fc4c816f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/maxim,max7360-gpio.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/maxim,max7360-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX7360 GPIO controller
+
+maintainers:
+ - Kamel Bouhara <kamel.bouhara@bootlin.com>
+ - Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
+
+description: |
+ Maxim MAX7360 GPIO controller, in MAX7360 chipset
+ https://www.analog.com/en/products/max7360.html
+
+ The device provides two series of GPIOs, referred here as GPIOs and GPOs.
+
+ PORT0 to PORT7 pins can be used as GPIOs, with support for interrupts and
+ constant-current mode. These pins will also be used by the rotary encoder and
+ PWM functionalities.
+
+ COL2 to COL7 pins can be used as GPOs, there is no input capability. COL pins
+ will be partitioned, with the first pins being affected to the keypad
+ functionality and the last ones as GPOs.
+
+properties:
+ compatible:
+ enum:
+ - maxim,max7360-gpio
+ - maxim,max7360-gpo
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ maxim,constant-current-disable:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bit field, each bit disables constant-current output of the associated
+ GPIO, starting from the least significant bit for the first GPIO.
+ maximum: 0xff
+
+required:
+ - compatible
+ - gpio-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max7360-gpio
+ ngpios: false
+ then:
+ required:
+ - interrupt-controller
+ else:
+ properties:
+ interrupt-controller: false
+ maxim,constant-current-disable: false
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio {
+ compatible = "maxim,max7360-gpio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ maxim,constant-current-disable = <0x06>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml b/Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml
new file mode 100644
index 000000000000..55734190d5eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/maxim,max77759-gpio.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/maxim,max77759-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX77759 GPIO
+
+maintainers:
+ - André Draszik <andre.draszik@linaro.org>
+
+description: |
+ This module is part of the MAX77759 PMIC. For additional information, see
+ Documentation/devicetree/bindings/mfd/maxim,max77759.yaml.
+
+ The MAX77759 is a PMIC integrating, amongst others, a GPIO controller
+ including interrupt support for 2 GPIO lines.
+
+properties:
+ compatible:
+ const: maxim,max77759-gpio
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 2
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - gpio-controller
+ - "#interrupt-cells"
+ - interrupt-controller
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
index 110651eafa70..184432d24ea1 100644
--- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
@@ -4,16 +4,20 @@
$id: http://devicetree.org/schemas/gpio/microchip,mpfs-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip MPFS GPIO Controller Device Tree Bindings
+title: Microchip MPFS GPIO Controller
maintainers:
- Conor Dooley <conor.dooley@microchip.com>
properties:
compatible:
- items:
+ oneOf:
+ - items:
+ - const: microchip,pic64gx-gpio
+ - const: microchip,mpfs-gpio
- enum:
- microchip,mpfs-gpio
+ - microchip,coregpio-rtl-v3
reg:
maxItems: 1
@@ -43,13 +47,29 @@ properties:
default: 32
gpio-controller: true
+ gpio-line-names: true
+
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,mpfs-gpio
+ then:
+ required:
+ - interrupts
+ - "#interrupt-cells"
+ - interrupt-controller
required:
- compatible
- reg
- - interrupts
- - "#interrupt-cells"
- - interrupt-controller
- "#gpio-cells"
- gpio-controller
- clocks
diff --git a/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt b/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
deleted file mode 100644
index dd031fc93b55..000000000000
--- a/Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Microchip PIC32 GPIO devices (PIO).
-
-Required properties:
- - compatible: "microchip,pic32mzda-gpio"
- - reg: Base address and length for the device.
- - interrupts: The port interrupt shared by all pins.
- - gpio-controller: Marks the port as GPIO controller.
- - #gpio-cells: Two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity as defined in
- defined in <dt-bindings/gpio/gpio.h>:
- 0 = GPIO_ACTIVE_HIGH
- 1 = GPIO_ACTIVE_LOW
- 2 = GPIO_OPEN_DRAIN
- - interrupt-controller: Marks the device node as an interrupt controller.
- - #interrupt-cells: Two. The first cell is the GPIO number and second cell
- is used to specify the trigger type as defined in
- <dt-bindings/interrupt-controller/irq.h>:
- IRQ_TYPE_EDGE_RISING
- IRQ_TYPE_EDGE_FALLING
- IRQ_TYPE_EDGE_BOTH
- - clocks: Clock specifier (see clock bindings for details).
- - microchip,gpio-bank: Specifies which bank a controller owns.
- - gpio-ranges: Interaction with the PINCTRL subsystem.
-
-Example:
-
-/* PORTA */
-gpio0: gpio0@1f860000 {
- compatible = "microchip,pic32mzda-gpio";
- reg = <0x1f860000 0x100>;
- interrupts = <118 IRQ_TYPE_LEVEL_HIGH>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupt-controller;
- #interrupt-cells = <2>;
- clocks = <&rootclk PB4CLK>;
- microchip,gpio-bank = <0>;
- gpio-ranges = <&pic32_pinctrl 0 0 16>;
-};
-
-keys {
- ...
-
- button@sw1 {
- label = "ESC";
- linux,code = <1>;
- gpios = <&gpio0 12 0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/microchip,pic32mzda-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,pic32mzda-gpio.yaml
new file mode 100644
index 000000000000..d8d932c86697
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/microchip,pic32mzda-gpio.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/microchip,pic32mzda-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 GPIO controller
+
+maintainers:
+ - Joshua Henderson <joshua.henderson@microchip.com>
+ - Purna Chandra Mandal <purna.mandal@microchip.com>
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ gpio-ranges: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ clocks:
+ maxItems: 1
+
+ microchip,gpio-bank:
+ description: Bank index owned by the controller
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - gpio-ranges
+ - "#gpio-cells"
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - clocks
+ - microchip,gpio-bank
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio@1f860000 {
+ compatible = "microchip,pic32mzda-gpio";
+ reg = <0x1f860000 0x100>;
+ interrupts = <118 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&rootclk 11>;
+ microchip,gpio-bank = <0>;
+ gpio-ranges = <&pic32_pinctrl 0 0 16>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml
index 9cf6137dd524..65155bb701a9 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml
@@ -9,7 +9,7 @@ title: Marvell PXA GPIO controller
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
- Bartosz Golaszewski <bgolaszewski@baylibre.com>
- - Rob Herring <robh+dt@kernel.org>
+ - Rob Herring <robh@kernel.org>
allOf:
- if:
diff --git a/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
deleted file mode 100644
index 50ec2e690701..000000000000
--- a/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Binding for the GPIO extension bus found on some LaCie/Seagate boards
-(Example: 2Big/5Big Network v2, 2Big NAS).
-
-Required properties:
-- compatible: "lacie,netxbig-gpio-ext".
-- addr-gpios: GPIOs representing the address register (LSB -> MSB).
-- data-gpios: GPIOs representing the data register (LSB -> MSB).
-- enable-gpio: latches the new configuration (address, data) on raising edge.
-
-Example:
-
-netxbig_gpio_ext: netxbig-gpio-ext {
- compatible = "lacie,netxbig-gpio-ext";
-
- addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH
- &gpio1 16 GPIO_ACTIVE_HIGH
- &gpio1 17 GPIO_ACTIVE_HIGH>;
- data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH
- &gpio1 13 GPIO_ACTIVE_HIGH
- &gpio1 14 GPIO_ACTIVE_HIGH>;
- enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt b/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
deleted file mode 100644
index ca2f8c745a27..000000000000
--- a/Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Bindings for the National Instruments 169445 GPIO NAND controller
-
-The 169445 GPIO NAND controller has two memory mapped GPIO registers, one
-for input (the ready signal) and one for output (control signals). It is
-intended to be used with the GPIO NAND driver.
-
-Required properties:
- - compatible: should be "ni,169445-nand-gpio"
- - reg-names: must contain
- "dat" - data register
- - reg: address + size pairs describing the GPIO register sets;
- order must correspond with the order of entries in reg-names
- - #gpio-cells: must be set to 2. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
- - gpio-controller: Marks the device node as a gpio controller.
-
-Optional properties:
- - no-output: disables driving output on the pins
-
-Examples:
- gpio1: nand-gpio-out@1f300010 {
- compatible = "ni,169445-nand-gpio";
- reg = <0x1f300010 0x4>;
- reg-names = "dat";
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpio2: nand-gpio-in@1f300014 {
- compatible = "ni,169445-nand-gpio";
- reg = <0x1f300014 0x4>;
- reg-names = "dat";
- gpio-controller;
- #gpio-cells = <2>;
- no-output;
- };
diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
deleted file mode 100644
index df63da46309c..000000000000
--- a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Nintendo Wii (Hollywood) GPIO controller
-
-Required properties:
-- compatible: "nintendo,hollywood-gpio"
-- reg: Physical base address and length of the controller's registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be <2>. The first cell is the pin number and the
- second cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted).
-
-Optional properties:
-- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two.
-- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
- interrupt.
-
-Example:
-
- GPIO: gpio@d8000c0 {
- #gpio-cells = <2>;
- compatible = "nintendo,hollywood-gpio";
- reg = <0x0d8000c0 0x40>;
- gpio-controller;
- ngpios = <24>;
- }
diff --git a/Documentation/devicetree/bindings/gpio/nuvoton,sgpio.yaml b/Documentation/devicetree/bindings/gpio/nuvoton,sgpio.yaml
new file mode 100644
index 000000000000..9e32e54aeb24
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nuvoton,sgpio.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/nuvoton,sgpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton SGPIO controller
+
+maintainers:
+ - Jim LIU <JJLIU0@nuvoton.com>
+
+description: |
+ This SGPIO controller is for NUVOTON NPCM7xx and NPCM8xx SoC and detailed
+ information is in the NPCM7XX/8XX SERIAL I/O EXPANSION INTERFACE section.
+ Nuvoton NPCM7xx SGPIO module is combines a serial to parallel IC (HC595)
+ and a parallel to serial IC (HC165).
+ Clock is a division of the APB3 clock.
+ This interface has 4 pins (D_out , D_in, S_CLK, LDSH).
+ NPCM7xx/NPCM8xx have two sgpio modules. Each module can support up
+ to 64 output pins, and up to 64 input pins, the pin is only for GPI or GPO.
+ GPIO pins can be programmed to support the following options
+ - Support interrupt option for each input port and various interrupt
+ sensitivity options (level-high, level-low, edge-high, edge-low)
+ - ngpios is number of nuvoton,input-ngpios GPIO lines and nuvoton,output-ngpios GPIO lines.
+ nuvoton,input-ngpios GPIO lines is only for GPI.
+ nuvoton,output-ngpios GPIO lines is only for GPO.
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-sgpio
+ - nuvoton,npcm845-sgpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ nuvoton,input-ngpios:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The numbers of GPIO's exposed. GPIO lines are only for GPI.
+ minimum: 0
+ maximum: 64
+
+ nuvoton,output-ngpios:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The numbers of GPIO's exposed. GPIO lines are only for GPO.
+ minimum: 0
+ maximum: 64
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - interrupts
+ - nuvoton,input-ngpios
+ - nuvoton,output-ngpios
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ gpio8: gpio@101000 {
+ compatible = "nuvoton,npcm750-sgpio";
+ reg = <0x101000 0x200>;
+ clocks = <&clk NPCM7XX_CLK_APB3>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ nuvoton,input-ngpios = <64>;
+ nuvoton,output-ngpios = <64>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
index 4ef06b2ff1ff..2bd620a1099b 100644
--- a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
@@ -85,6 +85,7 @@ properties:
- nvidia,tegra194-gpio-aon
- nvidia,tegra234-gpio
- nvidia,tegra234-gpio-aon
+ - nvidia,tegra256-gpio
reg-names:
items:
@@ -111,6 +112,9 @@ properties:
gpio-controller: true
+ gpio-ranges:
+ maxItems: 1
+
"#gpio-cells":
description: |
Indicates how many cells are used in a consumer's GPIO specifier. In the
@@ -152,6 +156,7 @@ allOf:
- nvidia,tegra186-gpio
- nvidia,tegra194-gpio
- nvidia,tegra234-gpio
+ - nvidia,tegra256-gpio
then:
properties:
interrupts:
diff --git a/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt b/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt
deleted file mode 100644
index 627efc78ecf2..000000000000
--- a/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-NXP LPC18xx/43xx GPIO controller Device Tree Bindings
------------------------------------------------------
-
-Required properties:
-- compatible : Should be "nxp,lpc1850-gpio"
-- reg : List of addresses and lengths of the GPIO controller
- register sets
-- reg-names : Should be "gpio", "gpio-pin-ic", "gpio-group0-ic" and
- "gpio-gpoup1-ic"
-- clocks : Phandle and clock specifier pair for GPIO controller
-- resets : Phandle and reset specifier pair for GPIO controller
-- gpio-controller : Marks the device node as a GPIO controller
-- #gpio-cells : Should be two:
- - The first cell is the GPIO line number
- - The second cell is used to specify polarity
-- interrupt-controller : Marks the device node as an interrupt controller
-- #interrupt-cells : Should be two:
- - The first cell is an interrupt number within
- 0..9 range, for GPIO pin interrupts it is equal
- to 'nxp,gpio-pin-interrupt' property value of
- GPIO pin configuration, 8 is for GPIO GROUP0
- interrupt, 9 is for GPIO GROUP1 interrupt
- - The second cell is used to specify interrupt type
-
-Optional properties:
-- gpio-ranges : Mapping between GPIO and pinctrl
-
-Example:
-#define LPC_GPIO(port, pin) (port * 32 + pin)
-#define LPC_PIN(port, pin) (0x##port * 32 + pin)
-
-gpio: gpio@400f4000 {
- compatible = "nxp,lpc1850-gpio";
- reg = <0x400f4000 0x4000>, <0x40087000 0x1000>,
- <0x40088000 0x1000>, <0x40089000 0x1000>;
- reg-names = "gpio", "gpio-pin-ic",
- "gpio-group0-ic", "gpio-gpoup1-ic";
- clocks = <&ccu1 CLK_CPU_GPIO>;
- resets = <&rgu 28>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&pinctrl LPC_GPIO(0,0) LPC_PIN(0,0) 2>,
- ...
- <&pinctrl LPC_GPIO(7,19) LPC_PIN(f,5) 7>;
-};
-
-gpio_joystick {
- compatible = "gpio-keys";
- ...
-
- button0 {
- ...
- interrupt-parent = <&gpio>;
- interrupts = <1 IRQ_TYPE_EDGE_BOTH>;
- gpios = <&gpio LPC_GPIO(4,8) GPIO_ACTIVE_LOW>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.yaml b/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.yaml
new file mode 100644
index 000000000000..0ef5f90f69ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/nxp,lpc1850-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC18xx/43xx GPIO controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-gpio
+
+ reg:
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: gpio
+ - const: gpio-pin-ic
+ - const: gpio-group0-ic
+ - const: gpio-gpoup1-ic
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description: |
+ - The first cell is an interrupt number within
+ 0..9 range, for GPIO pin interrupts it is equal
+ to 'nxp,gpio-pin-interrupt' property value of
+ GPIO pin configuration, 8 is for GPIO GROUP0
+ interrupt, 9 is for GPIO GROUP1 interrupt
+ - The second cell is used to specify interrupt type
+
+ gpio-ranges: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ gpio@400f4000 {
+ compatible = "nxp,lpc1850-gpio";
+ reg = <0x400f4000 0x4000>, <0x40087000 0x1000>,
+ <0x40088000 0x1000>, <0x40089000 0x1000>;
+ reg-names = "gpio", "gpio-pin-ic", "gpio-group0-ic", "gpio-gpoup1-ic";
+ clocks = <&ccu1 CLK_CPU_GPIO>;
+ resets = <&rgu 28>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
diff --git a/Documentation/devicetree/bindings/gpio/nxp,lpc3220-gpio.yaml b/Documentation/devicetree/bindings/gpio/nxp,lpc3220-gpio.yaml
new file mode 100644
index 000000000000..25b5494393cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nxp,lpc3220-gpio.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/nxp,lpc3220-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC3220 SoC GPIO controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: nxp,lpc3220-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 3
+ description: |
+ 1) bank:
+ 0: GPIO P0
+ 1: GPIO P1
+ 2: GPIO P2
+ 3: GPIO P3
+ 4: GPI P3
+ 5: GPO P3
+ 2) pin number
+ 3) flags:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted)
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@40028000 {
+ compatible = "nxp,lpc3220-gpio";
+ reg = <0x40028000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <3>; /* bank, pin, flags */
+ };
diff --git a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
index f0ff66c4c74e..5a6ecaa7b44b 100644
--- a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
+++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
@@ -39,6 +39,10 @@ properties:
reg:
maxItems: 1
+ gpio-line-names:
+ minItems: 1
+ maxItems: 16
+
gpio-controller: true
'#gpio-cells':
@@ -69,6 +73,43 @@ properties:
wakeup-source: true
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the (reset active LOW) RESET# pin.
+
+ The active polarity of the GPIO must translate to the low state of the
+ RESET# pin on the IC, i.e. if a GPIO is directly routed to the RESET# pin
+ without any inverter, GPIO_ACTIVE_LOW is expected.
+
+ Performing a reset makes all lines initialized to their input (pulled-up)
+ state.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - nxp,pca9670
+ - nxp,pca9671
+ - nxp,pca9672
+ - nxp,pca9673
+ then:
+ properties:
+ reset-gpios: false
+
+ # lines-initial-states XOR reset-gpios
+ # Performing a reset reinitializes all lines to a known state which
+ # may not match passed lines-initial-states
+ - if:
+ required:
+ - lines-initial-states
+ then:
+ properties:
+ reset-gpios: false
+
patternProperties:
"^(.+-hog(-[0-9]+)?)$":
type: object
@@ -87,17 +128,17 @@ additionalProperties: false
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pcf8575: gpio@20 {
- compatible = "nxp,pcf8575";
- reg = <0x20>;
- interrupt-parent = <&irqpin2>;
- interrupts = <3 0>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@20 {
+ compatible = "nxp,pcf8575";
+ reg = <0x20>;
+ interrupt-parent = <&irqpin2>;
+ interrupts = <3 0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
};
diff --git a/Documentation/devicetree/bindings/gpio/pisosr-gpio.yaml b/Documentation/devicetree/bindings/gpio/pisosr-gpio.yaml
new file mode 100644
index 000000000000..db98ba413fb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/pisosr-gpio.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/pisosr-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Parallel-in/Serial-out Shift Register GPIO Driver
+
+description:
+ This binding describes generic parallel-in/serial-out shift register
+ devices that can be used for GPI (General Purpose Input). This includes
+ SN74165 serial-out shift registers and the SN65HVS88x series of
+ industrial serializers.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - pisosr-gpio
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ ngpios:
+ maximum: 32
+ default: 8
+
+ load-gpios:
+ description:
+ GPIO pin specifier attached to load enable, this
+ pin is pulsed before reading from the device to
+ load input pin values into the device.
+
+ spi-cpol: true
+
+required:
+ - compatible
+ - gpio-controller
+ - '#gpio-cells'
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@0 {
+ compatible = "pisosr-gpio";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ load-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml b/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml
index bd35cbf7fa09..c51e10680c0a 100644
--- a/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml
@@ -60,9 +60,6 @@ properties:
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
- - "#interrupt-cells"
- clocks
- "#gpio-cells"
- gpio-controller
diff --git a/Documentation/devicetree/bindings/gpio/qca,ar7100-gpio.yaml b/Documentation/devicetree/bindings/gpio/qca,ar7100-gpio.yaml
new file mode 100644
index 000000000000..519c4c2158f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qca,ar7100-gpio.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/qca,ar7100-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros AR7xxx/AR9xxx GPIO controller
+
+maintainers:
+ - Alban Bedel <albeu@free.fr>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qca,ar9132-gpio
+ - const: qca,ar7100-gpio
+ - enum:
+ - qca,ar7100-gpio
+ - qca,ar9340-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ ngpios: true
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - ngpios
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@18040000 {
+ compatible = "qca,ar9132-gpio", "qca,ar7100-gpio";
+ reg = <0x18040000 0x30>;
+ interrupts = <2>;
+ ngpios = <22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
deleted file mode 100644
index ce97265e23ba..000000000000
--- a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Raspberry Pi GPIO expander
-
-The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The
-firmware exposes a mailbox interface that allows the ARM core to control the
-GPIO lines on the expander.
-
-The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi
-firmware node.
-
-Required properties:
-
-- compatible : Should be "raspberrypi,firmware-gpio"
-- gpio-controller : Marks the device node as a gpio controller
-- #gpio-cells : Should be two. The first cell is the pin number, and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-
-Example:
-
-firmware: firmware-rpi {
- compatible = "raspberrypi,bcm2835-firmware";
- mboxes = <&mailbox>;
-
- expgpio: gpio {
- compatible = "raspberrypi,firmware-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
-};
diff --git a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml
index 39fd959c45d2..728099c65824 100644
--- a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml
@@ -81,7 +81,7 @@ dependencies:
examples:
- |
- gpio@3500 {
+ gpio@3500 {
compatible = "realtek,rtl8380-gpio", "realtek,otto-gpio";
reg = <0x3500 0x1c>;
gpio-controller;
@@ -91,9 +91,9 @@ examples:
#interrupt-cells = <2>;
interrupt-parent = <&rtlintc>;
interrupts = <23>;
- };
+ };
- |
- gpio@3300 {
+ gpio@3300 {
compatible = "realtek,rtl9300-gpio", "realtek,otto-gpio";
reg = <0x3300 0x1c>, <0x3338 0x8>;
gpio-controller;
@@ -103,6 +103,6 @@ examples:
#interrupt-cells = <2>;
interrupt-parent = <&rtlintc>;
interrupts = <13>;
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd-gpio.yaml
new file mode 100644
index 000000000000..dd768db37a98
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/realtek,rtd-gpio.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/realtek,rtd-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC GPIO controller
+
+maintainers:
+ - Tzuyi Chang <tychang@realtek.com>
+
+description:
+ The GPIO controller is designed for the Realtek DHC (Digital Home Center)
+ RTD series SoC family, which are high-definition media processor SoCs.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1295-misc-gpio
+ - realtek,rtd1295-iso-gpio
+ - realtek,rtd1315e-iso-gpio
+ - realtek,rtd1319-iso-gpio
+ - realtek,rtd1319d-iso-gpio
+ - realtek,rtd1395-iso-gpio
+ - realtek,rtd1619-iso-gpio
+ - realtek,rtd1619b-iso-gpio
+
+ reg:
+ items:
+ - description: GPIO controller registers
+ - description: GPIO interrupt registers
+
+ interrupts:
+ items:
+ - description: Interrupt number of the assert GPIO interrupt, which is
+ triggered when there is a rising edge.
+ - description: Interrupt number of the deassert GPIO interrupt, which is
+ triggered when there is a falling edge.
+
+ gpio-ranges: true
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - gpio-ranges
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@100 {
+ compatible = "realtek,rtd1319d-iso-gpio";
+ reg = <0x100 0x100>,
+ <0x0 0xb0>;
+ interrupt-parent = <&iso_irq_mux>;
+ interrupts = <19>, <20>;
+ gpio-ranges = <&pinctrl 0 0 82>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml b/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
index 8bdef812c87c..49fb8f613ead 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
+++ b/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
@@ -57,14 +57,14 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
gpio0: gpio@e0050000 {
- compatible = "renesas,em-gio";
- reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
- interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pfc 0 0 32>;
- ngpios = <32>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "renesas,em-gio";
+ reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pfc 0 0 32>;
+ ngpios = <32>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml
index 75e5da6a7cc0..d32e103a64aa 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml
@@ -52,6 +52,8 @@ properties:
- enum:
- renesas,gpio-r8a779a0 # R-Car V3U
- renesas,gpio-r8a779f0 # R-Car S4-8
+ - renesas,gpio-r8a779g0 # R-Car V4H
+ - renesas,gpio-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-gpio # R-Car Gen4
reg:
@@ -136,16 +138,16 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a77470-sysc.h>
gpio3: gpio@e6053000 {
- compatible = "renesas,gpio-r8a77470", "renesas,rcar-gen2-gpio";
- reg = <0xe6053000 0x50>;
- interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 909>;
- power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
- resets = <&cpg 909>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pfc 0 96 30>;
- gpio-reserved-ranges = <17 10>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ compatible = "renesas,gpio-r8a77470", "renesas,rcar-gen2-gpio";
+ reg = <0xe6053000 0x50>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 909>;
+ power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
+ resets = <&cpg 909>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pfc 0 96 30>;
+ gpio-reserved-ranges = <17 10>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
index affd823c881d..bdd83f42615c 100644
--- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
@@ -41,6 +41,16 @@ properties:
"#interrupt-cells":
const: 2
+ power-domains:
+ maxItems: 1
+
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml
deleted file mode 100644
index d8cce73ea0ae..000000000000
--- a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/gpio/rockchip,rk3328-grf-gpio.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Rockchip RK3328 General Register Files GPIO controller
-
-description:
- The Rockchip RK3328 General Register File (GRF) outputs only the
- GPIO_MUTE pin, originally for codec mute control, but it can also be used
- for general purpose. It is manipulated by the GRF_SOC_CON10 register.
- If needed in the future support for the HDMI pins can also be added.
- The GPIO node should be declared as the child of the GRF node.
-
- The GPIO_MUTE pin is referred to in the format
-
- <&grf_gpio 0 GPIO_ACTIVE_LOW>
-
- The first cell is the pin number and
- the second cell is used to specify the GPIO polarity
- 0 = Active high
- 1 = Active low
-
-maintainers:
- - Heiko Stuebner <heiko@sntech.de>
-
-properties:
- compatible:
- const: rockchip,rk3328-grf-gpio
-
- gpio-controller: true
-
- "#gpio-cells":
- const: 2
-
-required:
- - compatible
- - gpio-controller
- - "#gpio-cells"
-
-additionalProperties: false
-
-examples:
- - |
- grf_gpio: gpio {
- compatible = "rockchip,rk3328-grf-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
index fc095646adea..4bdc201b719e 100644
--- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
@@ -76,8 +76,8 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/sifive-fu540-prci.h>
- gpio@10060000 {
+ #include <dt-bindings/clock/sifive-fu540-prci.h>
+ gpio@10060000 {
compatible = "sifive,fu540-c000-gpio", "sifive,gpio0";
interrupt-parent = <&plic>;
interrupts = <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>, <15>, <16>,
@@ -88,6 +88,6 @@ examples:
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
deleted file mode 100644
index 1b30812b015b..000000000000
--- a/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Synopsys GPIO via CREG (Control REGisters) driver
-
-Required properties:
-- compatible : "snps,creg-gpio-hsdk" or "snps,creg-gpio-axs10x".
-- reg : Exactly one register range with length 0x4.
-- #gpio-cells : Since the generic GPIO binding is used, the
- amount of cells must be specified as 2. The first cell is the
- pin number, the second cell is used to specify optional parameters:
- See "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
-- gpio-controller : Marks the device node as a GPIO controller.
-- ngpios: Number of GPIO pins.
-
-Example:
-
-gpio: gpio@f00014b0 {
- compatible = "snps,creg-gpio-hsdk";
- reg = <0xf00014b0 0x4>;
- gpio-controller;
- #gpio-cells = <2>;
- ngpios = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
index b391cc1b4590..bba6f5b6606f 100644
--- a/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
@@ -9,7 +9,7 @@ title: Synopsys DesignWare APB GPIO controller
description: |
Synopsys DesignWare GPIO controllers have a configurable number of ports,
each of which are intended to be represented as child nodes with the generic
- GPIO-controller properties as desribed in this bindings file.
+ GPIO-controller properties as described in this bindings file.
maintainers:
- Hoan Tran <hoan@os.amperecomputing.com>
@@ -61,6 +61,12 @@ patternProperties:
'#gpio-cells':
const: 2
+ gpio-line-names:
+ minItems: 1
+ maxItems: 32
+
+ gpio-ranges: true
+
ngpios:
default: 32
minimum: 1
@@ -105,8 +111,8 @@ additionalProperties: false
required:
- compatible
- reg
- - "#address-cells"
- - "#size-cells"
+ - '#address-cells'
+ - '#size-cells'
examples:
- |
diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
index 228fa27ffdc3..36f5a0610471 100644
--- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
@@ -55,19 +55,8 @@ properties:
patternProperties:
"^.+-hog(-[0-9]+)?$":
type: object
- properties:
- gpio-hog: true
- gpios: true
- input: true
- output-high: true
- output-low: true
- line-name: true
-
required:
- gpio-hog
- - gpios
-
- additionalProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml b/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml
new file mode 100644
index 000000000000..83e0b2d14c9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/spacemit,k1-gpio.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/spacemit,k1-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 GPIO controller
+
+maintainers:
+ - Yixun Lan <dlan@gentoo.org>
+
+description:
+ The controller's registers are organized as sets of eight 32-bit
+ registers with each set of port controlling 32 pins. A single
+ interrupt line is shared for all of the pins by the controller.
+
+properties:
+ $nodename:
+ pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+ const: spacemit,k1-gpio
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: GPIO Core Clock
+ - description: GPIO Bus Clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+
+ resets:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 3
+ description:
+ The first two cells are the GPIO bank index and offset inside the bank,
+ the third cell should specify GPIO flag.
+
+ gpio-ranges: true
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 3
+ description:
+ The first two cells are the GPIO bank index and offset inside the bank,
+ the third cell should specify interrupt flag. The controller does not
+ support level interrupts, so flags of IRQ_TYPE_LEVEL_HIGH,
+ IRQ_TYPE_LEVEL_LOW should not be used.
+ Refer <dt-bindings/interrupt-controller/irq.h> for valid flags.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@d4019000 {
+ compatible = "spacemit,k1-gpio";
+ reg = <0xd4019000 0x800>;
+ clocks = <&ccu 9>, <&ccu 61>;
+ clock-names = "core", "bus";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupts = <58>;
+ interrupt-controller;
+ interrupt-parent = <&plic>;
+ #interrupt-cells = <3>;
+ gpio-ranges = <&pinctrl 0 0 0 32>,
+ <&pinctrl 1 0 32 32>,
+ <&pinctrl 2 0 64 32>,
+ <&pinctrl 3 0 96 32>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/spear_spics.txt b/Documentation/devicetree/bindings/gpio/spear_spics.txt
deleted file mode 100644
index dd04d96e6ff1..000000000000
--- a/Documentation/devicetree/bindings/gpio/spear_spics.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-=== ST Microelectronics SPEAr SPI CS Driver ===
-
-SPEAr platform provides a provision to control chipselects of ARM PL022 Prime
-Cell spi controller through its system registers, which otherwise remains under
-PL022 control. If chipselect remain under PL022 control then they would be
-released as soon as transfer is over and TxFIFO becomes empty. This is not
-desired by some of the device protocols above spi which expect (multiple)
-transfers without releasing their chipselects.
-
-Chipselects can be controlled by software by turning them as GPIOs. SPEAr
-provides another interface through system registers through which software can
-directly control each PL022 chipselect. Hence, it is natural for SPEAr to export
-the control of this interface as gpio.
-
-Required properties:
-
- * compatible: should be defined as "st,spear-spics-gpio"
- * reg: mentioning address range of spics controller
- * st-spics,peripcfg-reg: peripheral configuration register offset
- * st-spics,sw-enable-bit: bit offset to enable sw control
- * st-spics,cs-value-bit: bit offset to drive chipselect low or high
- * st-spics,cs-enable-mask: chip select number bit mask
- * st-spics,cs-enable-shift: chip select number program offset
- * gpio-controller: Marks the device node as gpio controller
- * #gpio-cells: should be 1 and will mention chip select number
-
-All the above bit offsets are within peripcfg register.
-
-Example:
--------
-spics: spics@e0700000{
- compatible = "st,spear-spics-gpio";
- reg = <0xe0700000 0x1000>;
- st-spics,peripcfg-reg = <0x3b0>;
- st-spics,sw-enable-bit = <12>;
- st-spics,cs-value-bit = <11>;
- st-spics,cs-enable-mask = <3>;
- st-spics,cs-enable-shift = <8>;
- gpio-controller;
- #gpio-cells = <2>;
-};
-
-
-spi0: spi@e0100000 {
- num-cs = <3>;
- cs-gpios = <&gpio1 7 0>, <&spics 0>,
- <&spics 1>;
- ...
-}
diff --git a/Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml b/Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml
new file mode 100644
index 000000000000..99fcf970773a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/sprd,gpio-eic.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2022 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/sprd,gpio-eic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc EIC controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ The EIC is the abbreviation of external interrupt controller, which can
+ be used only in input mode. The Spreadtrum platform has 2 EIC controllers,
+ one is in digital chip, and another one is in PMIC. The digital chip EIC
+ controller contains 4 sub-modules, i.e. EIC-debounce, EIC-latch, EIC-async and
+ EIC-sync. But the PMIC EIC controller contains only one EIC-debounce sub-
+ module.
+
+ The EIC-debounce sub-module provides up to 8 source input signal
+ connections. A debounce mechanism is used to capture the input signals'
+ stable status (millisecond resolution) and a single-trigger mechanism
+ is introduced into this sub-module to enhance the input event detection
+ reliability. In addition, this sub-module's clock can be shut off
+ automatically to reduce power dissipation. Moreover the debounce range
+ is from 1ms to 4s with a step size of 1ms. The input signal will be
+ ignored if it is asserted for less than 1 ms.
+
+ The EIC-latch sub-module is used to latch some special power down signals
+ and generate interrupts, since the EIC-latch does not depend on the APB
+ clock to capture signals.
+
+ The EIC-async sub-module uses a 32kHz clock to capture the short signals
+ (microsecond resolution) to generate interrupts by level or edge trigger.
+
+ The EIC-sync is similar with GPIO's input function, which is a synchronized
+ signal input register. It can generate interrupts by level or edge trigger
+ when detecting input signals.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - sprd,sc9860-eic-debounce
+ - sprd,sc9860-eic-latch
+ - sprd,sc9860-eic-async
+ - sprd,sc9860-eic-sync
+ - sprd,sc2731-eic
+ - items:
+ - enum:
+ - sprd,ums512-eic-debounce
+ - const: sprd,sc9860-eic-debounce
+ - items:
+ - enum:
+ - sprd,ums512-eic-latch
+ - const: sprd,sc9860-eic-latch
+ - items:
+ - enum:
+ - sprd,ums512-eic-async
+ - const: sprd,sc9860-eic-async
+ - items:
+ - enum:
+ - sprd,ums512-eic-sync
+ - const: sprd,sc9860-eic-sync
+ - items:
+ - enum:
+ - sprd,sc2730-eic
+ - const: sprd,sc2731-eic
+
+ reg:
+ minItems: 1
+ maxItems: 3
+ description:
+ EIC controller can support maximum 3 banks which has its own
+ address base.
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+ description:
+ The interrupt shared by all GPIO lines for this controller.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ eic_debounce: gpio@40210000 {
+ compatible = "sprd,sc9860-eic-debounce";
+ reg = <0 0x40210000 0 0x80>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/sprd,gpio.yaml b/Documentation/devicetree/bindings/gpio/sprd,gpio.yaml
new file mode 100644
index 000000000000..483168838128
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/sprd,gpio.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2022 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/sprd,gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc GPIO controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ The controller's registers are organized as sets of sixteen 16-bit
+ registers with each set controlling a bank of up to 16 pins. A single
+ interrupt is shared for all of the banks handled by the controller.
+
+properties:
+ compatible:
+ oneOf:
+ - const: sprd,sc9860-gpio
+ - items:
+ - enum:
+ - sprd,ums512-gpio
+ - const: sprd,sc9860-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+ description: The interrupt shared by all GPIO lines for this controller.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ap_gpio: gpio@40280000 {
+ compatible = "sprd,sc9860-gpio";
+ reg = <0 0x40280000 0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpio/st,nomadik-gpio.yaml b/Documentation/devicetree/bindings/gpio/st,nomadik-gpio.yaml
new file mode 100644
index 000000000000..b3e8951959b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/st,nomadik-gpio.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/st,nomadik-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nomadik GPIO controller
+
+description:
+ The Nomadik GPIO driver handles Nomadik SoC GPIO blocks. This block has also
+ been called ST STA2X11. On the Nomadik platform, this driver is intertwined
+ with pinctrl-nomadik.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ $nodename:
+ pattern: "^gpio@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - st,nomadik-gpio
+ - mobileye,eyeq5-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-bank:
+ description: System-wide GPIO bank index.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st,supports-sleepmode:
+ description: Whether the controller can sleep or not.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ clocks:
+ maxItems: 1
+
+ gpio-ranges:
+ maxItems: 1
+
+ ngpios:
+ minimum: 0
+ maximum: 32
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#gpio-cells"
+ - gpio-controller
+ - interrupt-controller
+ - gpio-bank
+
+unevaluatedProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mobileye,eyeq5-gpio
+ then:
+ properties:
+ st,supports-sleepmode: false
+
+examples:
+ - |
+ gpio@8012e080 {
+ compatible = "st,nomadik-gpio";
+ reg = <0x8012e080 0x80>;
+ interrupts = <0 120 0x4>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ st,supports-sleepmode;
+ gpio-bank = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/st,spear-spics-gpio.yaml b/Documentation/devicetree/bindings/gpio/st,spear-spics-gpio.yaml
new file mode 100644
index 000000000000..3b0d2112da79
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/st,spear-spics-gpio.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/st,spear-spics-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST Microelectronics SPEAr SPI CS GPIO Controller
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+
+description: >
+ SPEAr platform provides a provision to control chipselects of ARM PL022 Prime
+ Cell spi controller through its system registers, which otherwise remains
+ under PL022 control. If chipselect remain under PL022 control then they would
+ be released as soon as transfer is over and TxFIFO becomes empty. This is not
+ desired by some of the device protocols above spi which expect (multiple)
+ transfers without releasing their chipselects.
+
+ Chipselects can be controlled by software by turning them as GPIOs. SPEAr
+ provides another interface through system registers through which software can
+ directly control each PL022 chipselect. Hence, it is natural for SPEAr to
+ export the control of this interface as gpio.
+
+properties:
+ compatible:
+ const: st,spear-spics-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ st-spics,peripcfg-reg:
+ description: Offset of the peripcfg register.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st-spics,sw-enable-bit:
+ description: Bit offset to enable software chipselect control.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st-spics,cs-value-bit:
+ description: Bit offset to drive chipselect low or high.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st-spics,cs-enable-mask:
+ description: Bitmask selecting which chipselects to enable.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st-spics,cs-enable-shift:
+ description: Bit shift for programming chipselect number.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - st-spics,peripcfg-reg
+ - st-spics,sw-enable-bit
+ - st-spics,cs-value-bit
+ - st-spics,cs-enable-mask
+ - st-spics,cs-enable-shift
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@e0700000 {
+ compatible = "st,spear-spics-gpio";
+ reg = <0xe0700000 0x1000>;
+ st-spics,peripcfg-reg = <0x3b0>;
+ st-spics,sw-enable-bit = <12>;
+ st-spics,cs-value-bit = <11>;
+ st-spics,cs-enable-mask = <3>;
+ st-spics,cs-enable-shift = <8>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
new file mode 100644
index 000000000000..4555f1644a4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/st,stmpe-gpio.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/st,stmpe-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectonics Port Expander (STMPE) GPIO Block
+
+description:
+ STMicroelectronics Port Expander (STMPE) is a series of slow
+ bus controllers for various expanded peripherals such as GPIO, keypad,
+ touchscreen, ADC, PWM or rotator. It can contain one or several different
+ peripherals connected to SPI or I2C. These bindings pertain to the
+ GPIO portions of these expanders.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ const: st,stmpe-gpio
+
+ "#gpio-cells":
+ const: 2
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 24
+
+ interrupt-controller: true
+
+ st,norequest-mask:
+ description:
+ A bitmask of GPIO lines that cannot be requested because for
+ for example not being connected to anything on the system
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#gpio-cells"
+ - "#interrupt-cells"
+ - gpio-controller
+ - interrupt-controller
diff --git a/Documentation/devicetree/bindings/gpio/ti,keystone-dsp-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,keystone-dsp-gpio.yaml
new file mode 100644
index 000000000000..59f81621408b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/ti,keystone-dsp-gpio.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/ti,keystone-dsp-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Keystone 2 DSP GPIO controller
+
+maintainers:
+ - Grygorii Strashko <grygorii.strashko@ti.com>
+
+description: |
+ HOST OS userland running on ARM can send interrupts to DSP cores using
+ the DSP GPIO controller IP. It provides 28 IRQ signals per each DSP core.
+ This is one of the component used by the IPC mechanism used on Keystone SOCs.
+
+ For example TCI6638K2K SoC has 8 DSP GPIO controllers:
+ - 8 for C66x CorePacx CPUs 0-7
+
+ Keystone 2 DSP GPIO controller has specific features:
+ - each GPIO can be configured only as output pin;
+ - setting GPIO value to 1 causes IRQ generation on target DSP core;
+ - reading pin value returns 0 - if IRQ was handled or 1 - IRQ is still
+ pending.
+
+properties:
+ compatible:
+ const: ti,keystone-dsp-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio,syscon-dev:
+ description:
+ Phandle and offset of device's specific registers within the syscon state
+ control registers
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscon
+ - description: register offset within state control registers
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio,syscon-dev
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@240 {
+ compatible = "ti,keystone-dsp-gpio";
+ reg = <0x240 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <&devctrl 0x240>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml
index 7087e4a5013f..7b75d2f92f1b 100644
--- a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gpio/ti,omap-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: OMAP GPIO controller bindings
+title: OMAP GPIO controller
maintainers:
- Grygorii Strashko <grygorii.strashko@ti.com>
@@ -58,14 +58,14 @@ properties:
deprecated: true
description:
Name of the hwmod associated with the GPIO. Needed on some legacy OMAP
- SoCs which have not been converted to the ti,sysc interconnect hierarachy.
+ SoCs which have not been converted to the ti,sysc interconnect hierarchy.
ti,no-reset-on-init:
$ref: /schemas/types.yaml#/definitions/flag
deprecated: true
description:
Do not reset on init. Used with ti,hwmods on some legacy OMAP SoCs which
- have not been converted to the ti,sysc interconnect hierarachy.
+ have not been converted to the ti,sysc interconnect hierarchy.
patternProperties:
"^(.+-hog(-[0-9]+)?)$":
diff --git a/Documentation/devicetree/bindings/gpio/ti,twl4030-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,twl4030-gpio.yaml
new file mode 100644
index 000000000000..96d50d14c071
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/ti,twl4030-gpio.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/ti,twl4030-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TWL4030 GPIO controller
+
+maintainers:
+ - Aaro Koskinen <aaro.koskinen@iki.fi>
+ - Andreas Kemnade <andreas@kemnade.info>
+ - Kevin Hilman <khilman@baylibre.com>
+ - Roger Quadros <rogerq@kernel.org>
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ const: ti,twl4030-gpio
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+ ti,debounce:
+ description: Debounce control bits. Each bit corresponds to a GPIO pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,mmc-cd:
+ description: MMC card detect control bits. Each bit corresponds to a GPIO pin for VMMC(n+1).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,pullups:
+ description: Pull-up control bits. Each bit corresponds to a GPIO pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,pulldowns:
+ description: Pull-down control bits. Each bit corresponds to a GPIO pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,use-leds:
+ type: boolean
+ description: Enables LEDA and LEDB outputs if set
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio {
+ compatible = "ti,twl4030-gpio";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ ti,use-leds;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml b/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
index b085450b527f..712063417bc8 100644
--- a/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
+++ b/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
@@ -48,22 +48,22 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
- soc {
+ soc {
#address-cells = <2>;
#size-cells = <2>;
gpio: gpio@28020000 {
- compatible = "toshiba,gpio-tmpv7708";
- reg = <0 0x28020000 0 0x1000>;
- #gpio-cells = <0x2>;
- gpio-ranges = <&pmux 0 0 32>;
- gpio-controller;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <&gic>;
+ compatible = "toshiba,gpio-tmpv7708";
+ reg = <0 0x28020000 0 0x1000>;
+ #gpio-cells = <0x2>;
+ gpio-ranges = <&pmux 0 0 32>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
};
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
new file mode 100644
index 000000000000..3f4bbd57fc52
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/trivial-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trivial 2-cell GPIO controllers
+
+maintainers:
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - cirrus,ep7312-gpio
+ - const: cirrus,ep7209-gpio
+ - enum:
+ - apm,xgene-gpio
+ - cirrus,ep7209-gpio
+ - cznic,moxtet-gpio
+ - dlg,slg7xl45106
+ - fcs,fxl6408
+ - fsl,ls1046aqds-fpga-gpio-stat-pres2
+ - fsl,lx2160ardb-fpga-gpio-sfp
+ - gateworks,pld-gpio
+ - ibm,ppc4xx-gpio
+ - loongson,ls1x-gpio
+ - maxim,max77620
+ - nintendo,hollywood-gpio
+ - nxp,pca9570
+ - nxp,pca9571
+ - rockchip,rk3328-grf-gpio
+ - snps,creg-gpio-hsdk
+ - technologic,ts4800-gpio
+ - technologic,ts4900-gpio
+ - technologic,ts7970-gpio
+ - ti,741g125 # for 741G125 (1-bit Input),
+ - ti,741g174 # for 741G74 (1-bit Output),
+ - ti,742g125 # for 742G125 (2-bit Input),
+ - ti,7474 # for 7474 (2-bit Output),
+ - ti,74125 # for 74125 (4-bit Input),
+ - ti,74175 # for 74175 (4-bit Output),
+ - ti,74365 # for 74365 (6-bit Input),
+ - ti,74174 # for 74174 (6-bit Output),
+ - ti,74244 # for 74244 (8-bit Input),
+ - ti,74273 # for 74273 (8-bit Output),
+ - ti,741624 # for 741624 (16-bit Input),
+ - ti,7416374 # for 7416374 (16-bit Output).
+ - ti,lp3943-gpio
+ - ti,palmas-gpio
+ - ti,tpic2810
+ - ti,tps80036-gpio
+ - ti,tps65913-gpio
+ - ti,tps65914-gpio
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ gpio-line-names: true
+
+ ngpios: true
+
+ # Don't add more properties
+
+patternProperties:
+ "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
+ type: object
+ required:
+ - gpio-hog
+
+required:
+ - compatible
+ - '#gpio-cells'
+ - gpio-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max77620
+ - rockchip,rk3328-grf-gpio
+ - ti,lp3943-gpio
+ - ti,palmas-gpio
+ - ti,tps80036-gpio
+ - ti,tps65913-gpio
+ - ti,tps65914-gpio
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@1701c000 {
+ compatible = "apm,xgene-gpio";
+ reg = <0x1701c000 0x40>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt b/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
deleted file mode 100644
index 038c3a6a1f4d..000000000000
--- a/Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Bindings for the Western Digital's MyBook Live memory-mapped GPIO controllers.
-
-The Western Digital MyBook Live has two memory-mapped GPIO controllers.
-Both GPIO controller only have a single 8-bit data register, where GPIO
-state can be read and/or written.
-
-Required properties:
- - compatible: should be "wd,mbl-gpio"
- - reg-names: must contain
- "dat" - data register
- - reg: address + size pairs describing the GPIO register sets;
- order must correspond with the order of entries in reg-names
- - #gpio-cells: must be set to 2. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
- - gpio-controller: Marks the device node as a gpio controller.
-
-Optional properties:
- - no-output: GPIOs are read-only.
-
-Examples:
- gpio0: gpio0@e0000000 {
- compatible = "wd,mbl-gpio";
- reg-names = "dat";
- reg = <0xe0000000 0x1>;
- #gpio-cells = <2>;
- gpio-controller;
- };
-
- gpio1: gpio1@e0100000 {
- compatible = "wd,mbl-gpio";
- reg-names = "dat";
- reg = <0xe0100000 0x1>;
- #gpio-cells = <2>;
- gpio-controller;
- no-output;
- };
diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
index 14486aee97b4..5eeb29bcdd21 100644
--- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: X-Powers AXP209 GPIO Device Tree Bindings
+title: X-Powers AXP209 GPIO
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -35,6 +35,7 @@ properties:
patternProperties:
"^.*-pins?$":
$ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
properties:
pins:
@@ -43,6 +44,7 @@ patternProperties:
- GPIO0
- GPIO1
- GPIO2
+ - GPIO3
function:
enum:
diff --git a/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml b/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml
new file mode 100644
index 000000000000..7af4eb2d1858
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/xlnx,gpio-xilinx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx AXI GPIO controller
+
+maintainers:
+ - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+ The AXI GPIO design provides a general purpose input/output interface
+ to an AXI4-Lite interface. The AXI GPIO can be configured as either
+ a single or a dual-channel device. The width of each channel is
+ independently configurable. The channels can be configured to
+ generate an interrupt when a transition on any of their inputs occurs.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,xps-gpio-1.00.a
+
+ reg:
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ gpio-line-names:
+ description: strings describing the names of each gpio line
+ minItems: 1
+ maxItems: 64
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ clocks:
+ maxItems: 1
+
+ interrupt-names: true
+
+ xlnx,all-inputs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This option sets this GPIO channel1 bits in input mode.
+
+ xlnx,all-inputs-2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This option sets this GPIO channel2 bits in input mode.
+
+ xlnx,all-outputs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This option sets this GPIO channel1 bits in output mode.
+
+ xlnx,all-outputs-2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This option sets this GPIO channel2 bits in output mode.
+
+ xlnx,dout-default:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Sets the default value of all the enabled bits of
+ channel1.
+ default: 0
+
+ xlnx,dout-default-2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Sets the default value of all the enabled bits of
+ channel2.
+ default: 0
+
+ xlnx,gpio-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The value defines the bit width of the GPIO channel1.
+ minimum: 1
+ maximum: 32
+ default: 32
+
+ xlnx,gpio2-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The value defines the bit width of the GPIO channel2.
+ minimum: 1
+ maximum: 32
+ default: 32
+
+ xlnx,interrupt-present:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This parameter enables interrupt control logic
+ and interrupt registers in GPIO module.
+ minimum: 0
+ maximum: 1
+ default: 0
+
+ xlnx,is-dual:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This parameter enables a second GPIO channel (GPIO2).
+ minimum: 0
+ maximum: 1
+ default: 0
+
+ xlnx,tri-default:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This value configures the input or output mode
+ of each bit of GPIO channel1.
+
+ xlnx,tri-default-2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This value configures the input or output mode
+ of each bit of GPIO channel2.
+
+required:
+ - reg
+ - compatible
+ - clocks
+ - gpio-controller
+ - "#gpio-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpio@a0020000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = <0xa0020000 0x10000>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <0x2>;
+ clocks = <&zynqmp_clk 71>;
+ gpio-controller;
+ interrupt-controller;
+ interrupt-names = "ip2intc_irpt";
+ interrupt-parent = <&gic>;
+ interrupts = <0 89 4>;
+ xlnx,all-inputs = <0x0>;
+ xlnx,all-inputs-2 = <0x0>;
+ xlnx,all-outputs = <0x0>;
+ xlnx,all-outputs-2 = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,dout-default-2 = <0x0>;
+ xlnx,gpio-width = <0x20>;
+ xlnx,gpio2-width = <0x20>;
+ xlnx,interrupt-present = <0x1>;
+ xlnx,is-dual = <0x1>;
+ xlnx,tri-default = <0xFFFFFFFF>;
+ xlnx,tri-default-2 = <0xFFFFFFFF>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
index 31c0fc345903..e13e9d6dd148 100644
--- a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
+++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ZynqMP Mode Pin GPIO controller
@@ -12,7 +12,7 @@ description:
PS_MODE). Every pin can be configured as input/output.
maintainers:
- - Piyush Mehta <piyush.mehta@xilinx.com>
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
compatible:
@@ -23,6 +23,8 @@ properties:
"#gpio-cells":
const: 2
+ label: true
+
required:
- compatible
- gpio-controller
@@ -37,6 +39,7 @@ examples:
compatible = "xlnx,zynqmp-gpio-modepin";
gpio-controller;
#gpio-cells = <2>;
+ label = "modepin";
};
};
diff --git a/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml b/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml
index a36aec27069c..59c79a6943ec 100644
--- a/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Bootlin
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpio/xylon,logicvc-gpio.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpio/xylon,logicvc-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xylon LogiCVC GPIO controller
diff --git a/Documentation/devicetree/bindings/gpu/apple,agx.yaml b/Documentation/devicetree/bindings/gpu/apple,agx.yaml
new file mode 100644
index 000000000000..05af942ad174
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/apple,agx.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/apple,agx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SoC GPU
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - apple,agx-g13g
+ - apple,agx-g13s
+ - apple,agx-g14g
+ - apple,agx-g14s
+ - items:
+ - enum:
+ - apple,agx-g13c
+ - apple,agx-g13d
+ - const: apple,agx-g13s
+ - items:
+ - enum:
+ - apple,agx-g14c
+ - apple,agx-g14d
+ - const: apple,agx-g14s
+
+ reg:
+ items:
+ - description: GPU coprocessor control registers
+ - description: GPU block MMIO registers
+
+ reg-names:
+ items:
+ - const: asc
+ - const: sgx
+
+ power-domains:
+ maxItems: 1
+
+ mboxes:
+ maxItems: 1
+
+ memory-region:
+ items:
+ - description: Region containing GPU MMU TTBs
+ - description: Region containing GPU MMU page tables
+ - description:
+ Region containing a shared handoff structure for VM
+ management coordination
+ - description: Calibration blob. Mostly power-related configuration
+ - description: Calibration blob. Mostly GPU-related configuration
+ - description: Shared global variables with GPU firmware
+
+ memory-region-names:
+ items:
+ - const: ttbs
+ - const: pagetables
+ - const: handoff
+ - const: hw-cal-a
+ - const: hw-cal-b
+ - const: globals
+
+ apple,firmware-abi:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ description:
+ macOS version the current firmware is paired with, used to pick
+ the version of firmware ABI to be used.
+ Bootloader will overwrite this
+
+required:
+ - compatible
+ - reg
+ - mboxes
+ - memory-region
+ - apple,firmware-abi
+
+additionalProperties: false
+
+examples:
+ - |
+ gpu@6400000 {
+ compatible = "apple,agx-g13g";
+ reg = <0x6400000 0x40000>,
+ <0x4000000 0x1000000>;
+ reg-names = "asc", "sgx";
+ mboxes = <&agx_mbox>;
+ power-domains = <&ps_gfx>;
+ memory-region = <&uat_ttbs>, <&uat_pagetables>, <&uat_handoff>,
+ <&gpu_hw_cal_a>, <&gpu_hw_cal_b>, <&gpu_globals>;
+ memory-region-names = "ttbs", "pagetables", "handoff",
+ "hw-cal-a", "hw-cal-b", "globals";
+
+ apple,firmware-abi = <0 0 0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 78964c140b46..db49b8ff8c74 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -17,17 +17,34 @@ properties:
oneOf:
- items:
- enum:
+ - allwinner,sun50i-h616-mali
- amlogic,meson-g12a-mali
- mediatek,mt8183-mali
+ - mediatek,mt8183b-mali
+ - mediatek,mt8186-mali
+ - mediatek,mt8365-mali
- realtek,rtd1619-mali
- renesas,r9a07g044-mali
- renesas,r9a07g054-mali
+ - renesas,r9a09g047-mali
+ - renesas,r9a09g056-mali
+ - renesas,r9a09g057-mali
- rockchip,px30-mali
+ - rockchip,rk3562-mali
- rockchip,rk3568-mali
+ - rockchip,rk3576-mali
- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
- items:
- enum:
+ - mediatek,mt8195-mali
+ - const: mediatek,mt8192-mali
+ - const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable
+ - items:
+ - enum:
+ - allwinner,sun55i-a523-mali
+ - mediatek,mt8188-mali
- mediatek,mt8192-mali
+ - mediatek,mt8370-mali
- const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable
reg:
@@ -63,7 +80,11 @@ properties:
power-domains:
minItems: 1
- maxItems: 3
+ maxItems: 5
+
+ power-domain-names:
+ minItems: 2
+ maxItems: 5
resets:
minItems: 1
@@ -75,7 +96,7 @@ properties:
const: 2
dynamic-power-coefficient:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
A u32 value that represents the running time dynamic
power coefficient in units of uW/MHz/V^2. The
@@ -93,6 +114,13 @@ properties:
dma-coherent: true
+ nvmem-cell-names:
+ items:
+ - const: speed-bin
+
+ nvmem-cells:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -109,6 +137,10 @@ allOf:
contains:
const: amlogic,meson-g12a-mali
then:
+ properties:
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
required:
- resets
- if:
@@ -118,6 +150,9 @@ allOf:
enum:
- renesas,r9a07g044-mali
- renesas,r9a07g054-mali
+ - renesas,r9a09g047-mali
+ - renesas,r9a09g056-mali
+ - renesas,r9a09g057-mali
then:
properties:
interrupts:
@@ -131,6 +166,9 @@ allOf:
- const: gpu
- const: bus
- const: bus_ace
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
resets:
minItems: 3
reset-names:
@@ -152,6 +190,7 @@ allOf:
properties:
power-domains:
minItems: 3
+ maxItems: 3
power-domain-names:
items:
- const: core0
@@ -164,13 +203,69 @@ allOf:
- power-domain-names
else:
properties:
- power-domains:
- maxItems: 1
sram-supply: false
- if:
properties:
compatible:
contains:
+ enum:
+ - mediatek,mt8183b-mali
+ - mediatek,mt8188-mali
+ then:
+ properties:
+ power-domains:
+ minItems: 3
+ maxItems: 3
+ power-domain-names:
+ items:
+ - const: core0
+ - const: core1
+ - const: core2
+ required:
+ - power-domains
+ - power-domain-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8186-mali
+ - mediatek,mt8370-mali
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+ maxItems: 2
+ power-domain-names:
+ items:
+ - const: core0
+ - const: core1
+ required:
+ - power-domains
+ - power-domain-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8192-mali
+ then:
+ properties:
+ power-domains:
+ minItems: 5
+ power-domain-names:
+ items:
+ - const: core0
+ - const: core1
+ - const: core2
+ - const: core3
+ - const: core4
+ required:
+ - power-domains
+ - power-domain-names
+ - if:
+ properties:
+ compatible:
+ contains:
const: rockchip,rk3568-mali
then:
properties:
@@ -180,6 +275,9 @@ allOf:
items:
- const: gpu
- const: bus
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
required:
- clock-names
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index d209f272625d..a7192622e120 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -42,11 +42,21 @@ properties:
- const: arm,mali-t760
- items:
- enum:
+ - samsung,exynos7-mali
+ - const: samsung,exynos5433-mali
+ - const: arm,mali-t760
+ - items:
+ - enum:
+ - samsung,exynos7870-mali
+ - const: arm,mali-t830
+ - items:
+ - enum:
- rockchip,rk3399-mali
- const: arm,mali-t860
-
- # "arm,mali-t830"
- # "arm,mali-t880"
+ - items:
+ - enum:
+ - samsung,exynos8890-mali
+ - const: arm,mali-t880
reg:
maxItems: 1
@@ -74,7 +84,8 @@ properties:
- const: bus
mali-supply: true
- opp-table: true
+ opp-table:
+ type: object
power-domains:
maxItems: 1
@@ -91,7 +102,7 @@ properties:
dma-coherent: true
dynamic-power-coefficient:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
A u32 value that represents the running time dynamic
power coefficient in units of uW/MHz/V^2. The
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index eceaa176bd57..c8d0d9192d92 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -29,10 +29,13 @@ properties:
- allwinner,sun50i-a64-mali
- rockchip,rk3036-mali
- rockchip,rk3066-mali
+ - rockchip,rk3128-mali
- rockchip,rk3188-mali
- rockchip,rk3228-mali
- samsung,exynos4210-mali
+ - st,stih410-mali
- stericsson,db8500-mali
+ - xlnx,zynqmp-mali
- const: arm,mali-400
- items:
- enum:
@@ -44,6 +47,7 @@ properties:
- hisilicon,hi6220-mali
- mediatek,mt7623-mali
- rockchip,rk3328-mali
+ - rockchip,rk3528-mali
- const: arm,mali-450
# "arm,mali-300"
@@ -101,7 +105,8 @@ properties:
mali-supply: true
- opp-table: true
+ opp-table:
+ type: object
power-domains:
maxItems: 1
@@ -144,6 +149,7 @@ allOf:
- rockchip,rk3188-mali
- rockchip,rk3228-mali
- rockchip,rk3328-mali
+ - rockchip,rk3528-mali
then:
required:
- resets
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
new file mode 100644
index 000000000000..bee9faf1d3f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -0,0 +1,185 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/arm,mali-valhall-csf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Mali Valhall GPU
+
+maintainers:
+ - Liviu Dudau <liviu.dudau@arm.com>
+ - Boris Brezillon <boris.brezillon@collabora.com>
+
+properties:
+ $nodename:
+ pattern: '^gpu@[a-f0-9]+$'
+
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt8196-mali
+ - nxp,imx95-mali # G310
+ - rockchip,rk3588-mali
+ - const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Job interrupt
+ - description: MMU interrupt
+ - description: GPU interrupt
+
+ interrupt-names:
+ items:
+ - const: job
+ - const: mmu
+ - const: gpu
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - enum:
+ - coregroup
+ - stacks
+ - const: stacks
+
+ mali-supply: true
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ power-domains:
+ minItems: 1
+ maxItems: 5
+
+ power-domain-names:
+ minItems: 1
+ maxItems: 5
+
+ sram-supply: true
+
+ "#cooling-cells":
+ const: 2
+
+ dynamic-power-coefficient:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ A u32 value that represents the running time dynamic
+ power coefficient in units of uW/MHz/V^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the GPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn = dynamic-power-coefficient * V^2 * f
+
+ where voltage is in V, frequency is in MHz.
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-mali
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
+ required:
+ - mali-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8196-mali
+ then:
+ properties:
+ mali-supply: false
+ sram-supply: false
+ operating-points-v2: false
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
+ clocks:
+ maxItems: 2
+ clock-names:
+ items:
+ - const: core
+ - const: stacks
+ required:
+ - power-domains
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/rk3588-power.h>
+
+ gpu: gpu@fb000000 {
+ compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
+ reg = <0xfb000000 0x200000>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
+ clock-names = "core", "coregroup", "stacks";
+ clocks = <&cru CLK_GPU>, <&cru CLK_GPU_COREGROUP>,
+ <&cru CLK_GPU_STACKS>;
+ power-domains = <&power RK3588_PD_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ mali-supply = <&vdd_gpu_s0>;
+ sram-supply = <&vdd_gpu_mem_s0>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ };
+ };
+ - |
+ gpu@48000000 {
+ compatible = "mediatek,mt8196-mali", "arm,mali-valhall-csf";
+ reg = <0x48000000 0x480000>;
+ clocks = <&gpufreq 0>, <&gpufreq 1>;
+ clock-names = "core", "stacks";
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
+ power-domains = <&gpufreq>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/gpu/aspeed,ast2400-gfx.yaml b/Documentation/devicetree/bindings/gpu/aspeed,ast2400-gfx.yaml
new file mode 100644
index 000000000000..20a4e00086ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/aspeed,ast2400-gfx.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/aspeed,ast2400-gfx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED GFX Display Controller
+
+maintainers:
+ - Joel Stanley <joel@jms.id.au>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - aspeed,ast2400-gfx
+ - aspeed,ast2500-gfx
+ - aspeed,ast2600-gfx
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+ description:
+ a reserved-memory region to use for the framebuffer.
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to SCU
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+
+ display@1e6e6000 {
+ compatible = "aspeed,ast2500-gfx", "syscon";
+ reg = <0x1e6e6000 0x1000>;
+ clocks = <&syscon ASPEED_CLK_GATE_D1CLK>;
+ resets = <&syscon ASPEED_RESET_CRT1>;
+ interrupts = <0x19>;
+ memory-region = <&gfx_memory>;
+ };
diff --git a/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt b/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
deleted file mode 100644
index 958bdf962339..000000000000
--- a/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Device tree configuration for the GFX display device on the ASPEED SoCs
-
-Required properties:
- - compatible
- * Must be one of the following:
- + aspeed,ast2500-gfx
- + aspeed,ast2400-gfx
- * In addition, the ASPEED pinctrl bindings require the 'syscon' property to
- be present
-
- - reg: Physical base address and length of the GFX registers
-
- - interrupts: interrupt number for the GFX device
-
- - clocks: clock number used to generate the pixel clock
-
- - resets: reset line that must be released to use the GFX device
-
- - memory-region:
- Phandle to a memory region to allocate from, as defined in
- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
-
-
-Example:
-
-gfx: display@1e6e6000 {
- compatible = "aspeed,ast2500-gfx", "syscon";
- reg = <0x1e6e6000 0x1000>;
- reg-io-width = <4>;
- clocks = <&syscon ASPEED_CLK_GATE_D1CLK>;
- resets = <&syscon ASPEED_RESET_CRT1>;
- interrupts = <0x19>;
- memory-region = <&gfx_memory>;
-};
-
-gfx_memory: framebuffer {
- size = <0x01000000>;
- alignment = <0x01000000>;
- compatible = "shared-dma-pool";
- reusable;
-};
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
index 217c42874f41..43c6d2d72456 100644
--- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/gpu/brcm,bcm-v3d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom V3D GPU Bindings
+title: Broadcom V3D GPU
maintainers:
- - Eric Anholt <eric@anholt.net>
+ - Maíra Canal <mcanal@igalia.com>
- Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
properties:
@@ -17,24 +17,17 @@ properties:
compatible:
enum:
- brcm,2711-v3d
+ - brcm,2712-v3d
- brcm,7268-v3d
- brcm,7278-v3d
reg:
- items:
- - description: hub register (required)
- - description: core0 register (required)
- - description: GCA cache controller register (if GCA controller present)
- - description: bridge register (if no external reset controller)
minItems: 2
+ maxItems: 4
reg-names:
- items:
- - const: hub
- - const: core0
- - enum: [ bridge, gca ]
- - enum: [ bridge, gca ]
minItems: 2
+ maxItems: 4
interrupts:
items:
@@ -57,6 +50,76 @@ required:
- reg-names
- interrupts
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,2711-v3d
+ then:
+ properties:
+ reg:
+ items:
+ - description: hub register
+ - description: core0 register
+ reg-names:
+ items:
+ - const: hub
+ - const: core0
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,2712-v3d
+ then:
+ properties:
+ reg:
+ items:
+ - description: hub register
+ - description: core0 register
+ - description: SMS state manager register
+ reg-names:
+ items:
+ - const: hub
+ - const: core0
+ - const: sms
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,7268-v3d
+ then:
+ properties:
+ reg:
+ items:
+ - description: hub register
+ - description: core0 register
+ - description: GCA cache controller register
+ - description: bridge register
+ reg-names:
+ items:
+ - const: hub
+ - const: core0
+ - const: gca
+ - const: bridge
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,7278-v3d
+ then:
+ properties:
+ reg:
+ items:
+ - description: hub register
+ - description: core0 register
+ - description: bridge register
+ reg-names:
+ items:
+ - const: hub
+ - const: core0
+ - const: bridge
+
additionalProperties: false
examples:
@@ -65,9 +128,9 @@ examples:
compatible = "brcm,7268-v3d";
reg = <0xf1200000 0x4000>,
<0xf1208000 0x4000>,
- <0xf1204000 0x100>,
- <0xf1204100 0x100>;
- reg-names = "hub", "core0", "bridge", "gca";
+ <0xf1204100 0x100>,
+ <0xf1204000 0x100>;
+ reg-names = "hub", "core0", "gca", "bridge";
interrupts = <0 78 4>,
<0 77 4>;
};
diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
index 3cf862976448..ba4c6473ff92 100644
--- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device tree binding for NVIDIA Tegra NVDEC
+title: NVIDIA Tegra NVDEC
description: |
NVDEC is the hardware video decoder present on NVIDIA Tegra210
diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml
index e63ae1a00818..c23dae713eb8 100644
--- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvenc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvenc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device tree binding for NVIDIA Tegra NVENC
+title: NVIDIA Tegra NVENC
description: |
NVENC is the hardware video encoder present on NVIDIA Tegra210
diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml
index 8647404d67e4..99a33a5eac3f 100644
--- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvjpg.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvjpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device tree binding for NVIDIA Tegra NVJPG
+title: NVIDIA Tegra NVJPG
description: |
NVJPG is the hardware JPEG decoder and encoder present on NVIDIA Tegra210
diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml
new file mode 100644
index 000000000000..0b7561c8b9bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 NVDEC
+
+description: |
+ NVDEC is the hardware video decoder present on NVIDIA Tegra210
+ and newer chips. It is located on the Host1x bus and typically
+ programmed through Host1x channels.
+
+maintainers:
+ - Thierry Reding <treding@gmail.com>
+ - Mikko Perttunen <mperttunen@nvidia.com>
+
+properties:
+ $nodename:
+ pattern: "^nvdec@[0-9a-f]*$"
+
+ compatible:
+ enum:
+ - nvidia,tegra234-nvdec
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: nvdec
+ - const: fuse
+ - const: tsec_pka
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: nvdec
+
+ power-domains:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+ interconnects:
+ items:
+ - description: DMA read memory client
+ - description: DMA write memory client
+
+ interconnect-names:
+ items:
+ - const: dma-mem
+ - const: write
+
+ nvidia,memory-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the memory controller for determining information for the NVDEC
+ firmware secure carveout. This carveout is configured by the bootloader and
+ not accessible to CPU.
+
+ nvidia,bl-manifest-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset to bootloader manifest from beginning of firmware that was configured by
+ the bootloader.
+
+ nvidia,bl-code-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset to bootloader code section from beginning of firmware that was configured by
+ the bootloader.
+
+ nvidia,bl-data-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset to bootloader data section from beginning of firmware that was configured by
+ the bootloader.
+
+ nvidia,os-manifest-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset to operating system manifest from beginning of firmware that was configured by
+ the bootloader.
+
+ nvidia,os-code-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset to operating system code section from beginning of firmware that was configured by
+ the bootloader.
+
+ nvidia,os-data-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset to operating system data section from beginning of firmware that was configured
+ by the bootloader.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+ - nvidia,memory-controller
+ - nvidia,bl-manifest-offset
+ - nvidia,bl-code-offset
+ - nvidia,bl-data-offset
+ - nvidia,os-manifest-offset
+ - nvidia,os-code-offset
+ - nvidia,os-data-offset
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra234-clock.h>
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/power/tegra234-powergate.h>
+ #include <dt-bindings/reset/tegra234-reset.h>
+
+ nvdec@15480000 {
+ compatible = "nvidia,tegra234-nvdec";
+ reg = <0x15480000 0x00040000>;
+ clocks = <&bpmp TEGRA234_CLK_NVDEC>,
+ <&bpmp TEGRA234_CLK_FUSE>,
+ <&bpmp TEGRA234_CLK_TSEC_PKA>;
+ clock-names = "nvdec", "fuse", "tsec_pka";
+ resets = <&bpmp TEGRA234_RESET_NVDEC>;
+ reset-names = "nvdec";
+ power-domains = <&bpmp TEGRA234_POWER_DOMAIN_NVDEC>;
+ interconnects = <&mc TEGRA234_MEMORY_CLIENT_NVDECSRD &emc>,
+ <&mc TEGRA234_MEMORY_CLIENT_NVDECSWR &emc>;
+ interconnect-names = "dma-mem", "write";
+ iommus = <&smmu_niso1 TEGRA234_SID_NVDEC>;
+ dma-coherent;
+
+ nvidia,memory-controller = <&mc>;
+
+ /* Placeholder values, to be replaced with values from overlay */
+ nvidia,bl-manifest-offset = <0>;
+ nvidia,bl-data-offset = <0>;
+ nvidia,bl-code-offset = <0>;
+ nvidia,os-manifest-offset = <0>;
+ nvidia,os-data-offset = <0>;
+ nvidia,os-code-offset = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
new file mode 100644
index 000000000000..225a6e1b7fcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -0,0 +1,185 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Imagination Technologies Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/img,powervr-rogue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Technologies PowerVR and IMG Rogue GPUs
+
+maintainers:
+ - Frank Binns <frank.binns@imgtec.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r8a7796-gpu
+ - renesas,r8a77961-gpu
+ - const: img,img-gx6250
+ - const: img,img-rogue
+ - items:
+ - const: renesas,r8a77965-gpu
+ - const: img,img-ge7800
+ - const: img,img-rogue
+ - items:
+ - enum:
+ - ti,am62-gpu
+ - const: img,img-axe-1-16m
+ # This deprecated element must be kept around to allow old kernels to
+ # work with newer dts.
+ - const: img,img-axe
+ - const: img,img-rogue
+ - items:
+ - enum:
+ - thead,th1520-gpu
+ - const: img,img-bxm-4-64
+ - const: img,img-rogue
+ - items:
+ - enum:
+ - ti,j721s2-gpu
+ - const: img,img-bxs-4-64
+ - const: img,img-rogue
+
+ # This legacy combination of compatible strings was introduced early on
+ # before the more specific GPU identifiers were used.
+ - items:
+ - enum:
+ - ti,am62-gpu
+ - const: img,img-axe
+ deprecated: true
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: core
+ - const: mem
+ - const: sys
+ minItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ minItems: 1
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: a
+ - const: b
+ minItems: 1
+
+ dma-coherent: true
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,am62-gpu
+ - ti,j721s2-gpu
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - img,img-ge7800
+ - img,img-gx6250
+ - thead,th1520-gpu
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: img,img-axe-1-16m
+ then:
+ properties:
+ power-domains:
+ maxItems: 1
+ power-domain-names:
+ maxItems: 1
+ required:
+ - power-domains
+ - power-domain-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - img,img-bxs-4-64
+ - img,img-ge7800
+ - img,img-gx6250
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+ power-domain-names:
+ minItems: 2
+ required:
+ - power-domains
+ - power-domain-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: thead,th1520-gpu
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: The single, unified power domain for the GPU on the
+ TH1520 SoC, integrating all internal IP power domains.
+ power-domain-names: false
+ required:
+ - power-domains
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ gpu@fd00000 {
+ compatible = "ti,am62-gpu", "img,img-axe-1-16m", "img,img-axe",
+ "img,img-rogue";
+ reg = <0x0fd00000 0x20000>;
+ clocks = <&k3_clks 187 0>;
+ clock-names = "core";
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
+ power-domain-names = "a";
+ };
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
new file mode 100644
index 000000000000..f5898b04381c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Imagination Technologies Ltd.
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/img,powervr-sgx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Technologies PowerVR SGX GPUs
+
+maintainers:
+ - Frank Binns <frank.binns@imgtec.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,omap3430-gpu # Rev 121
+ - ti,omap3630-gpu # Rev 125
+ - const: img,powervr-sgx530
+ - items:
+ - enum:
+ - ingenic,jz4780-gpu # Rev 130
+ - ti,omap4430-gpu # Rev 120
+ - const: img,powervr-sgx540
+ - items:
+ - enum:
+ - allwinner,sun6i-a31-gpu # MP2 Rev 115
+ - ti,omap4470-gpu # MP1 Rev 112
+ - ti,omap5432-gpu # MP2 Rev 105
+ - ti,am5728-gpu # MP2 Rev 116
+ - ti,am6548-gpu # MP1 Rev 117
+ - const: img,powervr-sgx544
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: mem
+ - const: sys
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am6548-gpu
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun6i-a31-gpu
+ - ingenic,jz4780-gpu
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: allwinner,sun6i-a31-gpu
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ingenic,jz4780-gpu
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ gpu@7000000 {
+ compatible = "ti,am6548-gpu", "img,powervr-sgx544";
+ reg = <0x7000000 0x10000>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 65 TI_SCI_PD_EXCLUSIVE>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpu: gpu@1c40000 {
+ compatible = "allwinner,sun6i-a31-gpu", "img,powervr-sgx544";
+ reg = <0x01c40000 0x10000>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu 1>, <&ccu 2>;
+ clock-names = "core", "mem";
+ };
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
deleted file mode 100644
index cc6ce5221a38..000000000000
--- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-NVIDIA Tegra Graphics Processing Units
-
-Required properties:
-- compatible: "nvidia,<gpu>"
- Currently recognized values:
- - nvidia,gk20a
- - nvidia,gm20b
- - nvidia,gp10b
- - nvidia,gv11b
-- reg: Physical base address and length of the controller's registers.
- Must contain two entries:
- - first entry for bar0
- - second entry for bar1
-- interrupts: Must contain an entry for each entry in interrupt-names.
- See ../interrupt-controller/interrupts.txt for details.
-- interrupt-names: Must include the following entries:
- - stall
- - nonstall
-- vdd-supply: regulator for supply voltage. Only required for GPUs not using
- power domains.
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - gpu
- - pwr
-If the compatible string is "nvidia,gm20b", then the following clock
-is also required:
- - ref
-If the compatible string is "nvidia,gv11b", then the following clock is also
-required:
- - fuse
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - gpu
-- power-domains: GPUs that make use of power domains can define this property
- instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
-
-Optional properties:
-- iommus: A reference to the IOMMU. See ../iommu/iommu.txt for details.
-
-Example for GK20A:
-
- gpu@57000000 {
- compatible = "nvidia,gk20a";
- reg = <0x0 0x57000000 0x0 0x01000000>,
- <0x0 0x58000000 0x0 0x01000000>;
- interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- vdd-supply = <&vdd_gpu>;
- clocks = <&tegra_car TEGRA124_CLK_GPU>,
- <&tegra_car TEGRA124_CLK_PLL_P_OUT5>;
- clock-names = "gpu", "pwr";
- resets = <&tegra_car 184>;
- reset-names = "gpu";
- iommus = <&mc TEGRA_SWGROUP_GPU>;
- };
-
-Example for GM20B:
-
- gpu@57000000 {
- compatible = "nvidia,gm20b";
- reg = <0x0 0x57000000 0x0 0x01000000>,
- <0x0 0x58000000 0x0 0x01000000>;
- interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- clocks = <&tegra_car TEGRA210_CLK_GPU>,
- <&tegra_car TEGRA210_CLK_PLL_P_OUT5>,
- <&tegra_car TEGRA210_CLK_PLL_G_REF>;
- clock-names = "gpu", "pwr", "ref";
- resets = <&tegra_car 184>;
- reset-names = "gpu";
- iommus = <&mc TEGRA_SWGROUP_GPU>;
- };
-
-Example for GP10B:
-
- gpu@17000000 {
- compatible = "nvidia,gp10b";
- reg = <0x0 0x17000000 0x0 0x1000000>,
- <0x0 0x18000000 0x0 0x1000000>;
- interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- clocks = <&bpmp TEGRA186_CLK_GPCCLK>,
- <&bpmp TEGRA186_CLK_GPU>;
- clock-names = "gpu", "pwr";
- resets = <&bpmp TEGRA186_RESET_GPU>;
- reset-names = "gpu";
- power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>;
- iommus = <&smmu TEGRA186_SID_GPU>;
- };
-
-Example for GV11B:
-
- gpu@17000000 {
- compatible = "nvidia,gv11b";
- reg = <0x17000000 0x1000000>,
- <0x18000000 0x1000000>;
- interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- clocks = <&bpmp TEGRA194_CLK_GPCCLK>,
- <&bpmp TEGRA194_CLK_GPU_PWR>,
- <&bpmp TEGRA194_CLK_FUSE>;
- clock-names = "gpu", "pwr", "fuse";
- resets = <&bpmp TEGRA194_RESET_GPU>;
- reset-names = "gpu";
- dma-coherent;
-
- power-domains = <&bpmp TEGRA194_POWER_DOMAIN_GPU>;
- iommus = <&smmu TEGRA194_SID_GPU>;
- };
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
new file mode 100644
index 000000000000..4d856a8b674c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/nvidia,gk20a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Graphics Processing Units
+
+maintainers:
+ - Alexandre Courbot <acourbot@nvidia.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+ - Thierry Reding <treding@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,gk20a
+ - nvidia,gm20b
+ - nvidia,gp10b
+ - nvidia,gv11b
+
+ reg:
+ items:
+ - description: Bar0 register window
+ - description: Bar1 register window
+
+ interrupts:
+ items:
+ - description: Stall interrupt
+ - description: Nonstall interrupt
+
+ interrupt-names:
+ items:
+ - const: stall
+ - const: nonstall
+
+ vdd-supply:
+ description:
+ Regulator for GPU supply voltage
+
+ clocks:
+ minItems: 2
+ items:
+ - description: GPU clock
+ - description: Power clock
+ - description: Reference or fuse clock
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: gpu
+ - const: pwr
+ - enum: [ ref, fuse ]
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: gpu
+
+ power-domains:
+ maxItems: 1
+
+ interconnects:
+ minItems: 4
+ maxItems: 12
+
+ interconnect-names:
+ minItems: 4
+ maxItems: 12
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,gp10b
+ - nvidia,gv11b
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ interconnects: false
+ interconnect-names: false
+
+ required:
+ - vdd-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,gp10b
+ then:
+ properties:
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: dma-mem
+ - const: write-0
+ - const: read-1
+ - const: write-1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,gv11b
+ then:
+ properties:
+ interconnects:
+ minItems: 12
+
+ interconnect-names:
+ items:
+ - const: dma-mem
+ - const: read-0-hp
+ - const: write-0
+ - const: read-1
+ - const: read-1-hp
+ - const: write-1
+ - const: read-2
+ - const: read-2-hp
+ - const: write-2
+ - const: read-3
+ - const: read-3-hp
+ - const: write-3
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/tegra124-car-common.h>
+ #include <dt-bindings/memory/tegra124-mc.h>
+
+ gpu@57000000 {
+ compatible = "nvidia,gk20a";
+ reg = <0x57000000 0x01000000>,
+ <0x58000000 0x01000000>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "stall", "nonstall";
+ vdd-supply = <&vdd_gpu>;
+ clocks = <&tegra_car TEGRA124_CLK_GPU>,
+ <&tegra_car TEGRA124_CLK_PLL_P_OUT5>;
+ clock-names = "gpu", "pwr";
+ resets = <&tegra_car 184>;
+ reset-names = "gpu";
+ iommus = <&mc TEGRA_SWGROUP_GPU>;
+ };
diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml b/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml
index e7daae862578..132aaa49597b 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml
@@ -22,36 +22,20 @@ properties:
interrupts:
maxItems: 1
- clocks: {}
- clock-names: {}
- iommus: {}
- power-domains: {}
-
-if:
- properties:
- compatible:
- contains:
- const: samsung,exynos5250-g2d
-
-then:
- properties:
- clocks:
- items:
- - description: fimg2d clock
- clock-names:
- items:
- - const: fimg2d
-
-else:
- properties:
- clocks:
- items:
- - description: sclk_fimg2d clock
- - description: fimg2d clock
- clock-names:
- items:
- - const: sclk_fimg2d
- - const: fimg2d
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
required:
- compatible
@@ -60,6 +44,33 @@ required:
- clocks
- clock-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos5250-g2d
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: fimg2d clock
+ clock-names:
+ items:
+ - const: fimg2d
+
+ else:
+ properties:
+ clocks:
+ items:
+ - description: sclk_fimg2d clock
+ - description: fimg2d clock
+ clock-names:
+ items:
+ - const: sclk_fimg2d
+ - const: fimg2d
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
index d60626ffb28e..18bf44e06e8f 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
+++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
@@ -12,10 +12,11 @@ maintainers:
properties:
compatible:
enum:
- - "samsung,s5pv210-rotator"
- - "samsung,exynos4210-rotator"
- - "samsung,exynos4212-rotator"
- - "samsung,exynos5250-rotator"
+ - samsung,s5pv210-rotator
+ - samsung,exynos4210-rotator
+ - samsung,exynos4212-rotator
+ - samsung,exynos5250-rotator
+
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/gpu/samsung-scaler.yaml b/Documentation/devicetree/bindings/gpu/samsung-scaler.yaml
index 5317ac64426a..9fb530e65d0e 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-scaler.yaml
+++ b/Documentation/devicetree/bindings/gpu/samsung-scaler.yaml
@@ -21,40 +21,20 @@ properties:
interrupts:
maxItems: 1
- clocks: {}
- clock-names: {}
- iommus: {}
- power-domains: {}
-
-if:
- properties:
- compatible:
- contains:
- const: samsung,exynos5420-scaler
-
-then:
- properties:
- clocks:
- items:
- - description: mscl clock
-
- clock-names:
- items:
- - const: mscl
-
-else:
- properties:
- clocks:
- items:
- - description: pclk clock
- - description: aclk clock
- - description: aclk_xiu clock
-
- clock-names:
- items:
- - const: pclk
- - const: aclk
- - const: aclk_xiu
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
required:
- compatible
@@ -63,6 +43,39 @@ required:
- clocks
- clock-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos5420-scaler
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: mscl clock
+ clock-names:
+ items:
+ - const: mscl
+ iommus:
+ minItems: 2
+
+ else:
+ properties:
+ clocks:
+ items:
+ - description: pclk clock
+ - description: aclk clock
+ - description: aclk_xiu clock
+ clock-names:
+ items:
+ - const: pclk
+ - const: aclk
+ - const: aclk_xiu
+ iommus:
+ maxItems: 1
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml
index 93e7244cdc0e..b1b10ea70ad9 100644
--- a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml
+++ b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gpu/vivante,gc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Vivante GPU Bindings
+title: Vivante GPU
description: Vivante GPU core devices
diff --git a/Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml b/Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml
new file mode 100644
index 000000000000..9d0c36ec1982
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwinfo/loongson,ls2k-chipid.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwinfo/loongson,ls2k-chipid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 SoC ChipID
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+description: |
+ Loongson-2 SoC contains many groups of global utilities register
+ blocks, of which the ChipID group registers record SoC version,
+ feature, vendor and id information.
+
+properties:
+ compatible:
+ const: loongson,ls2k-chipid
+
+ reg:
+ maxItems: 1
+
+ little-endian: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ chipid: chipid@1fe00000 {
+ compatible = "loongson,ls2k-chipid";
+ reg = <0x1fe00000 0x3ffc>;
+ little-endian;
+ };
diff --git a/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml
index 95cbdcb56efe..b9cdfe52b62f 100644
--- a/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml
+++ b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml
@@ -11,9 +11,28 @@ maintainers:
properties:
compatible:
- enum:
- - samsung,exynos4210-chipid
- - samsung,exynos850-chipid
+ oneOf:
+ - enum:
+ - samsung,exynos4210-chipid
+ - samsung,exynos850-chipid
+ - items:
+ - enum:
+ - samsung,exynos5433-chipid
+ - samsung,exynos7-chipid
+ - samsung,exynos7870-chipid
+ - samsung,exynos8890-chipid
+ - const: samsung,exynos4210-chipid
+ - items:
+ - enum:
+ - samsung,exynos2200-chipid
+ - samsung,exynos7885-chipid
+ - samsung,exynos8895-chipid
+ - samsung,exynos9610-chipid
+ - samsung,exynos9810-chipid
+ - samsung,exynos990-chipid
+ - samsung,exynosautov9-chipid
+ - samsung,exynosautov920-chipid
+ - const: samsung,exynos850-chipid
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml b/Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml
new file mode 100644
index 000000000000..b0f425a4a882
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwinfo/via,vt8500-scc-id.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwinfo/via,vt8500-scc-id.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/WonderMedia SoC system configuration information
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+description:
+ The system configuration controller on VIA/WonderMedia SoC's contains a chip
+ identifier and revision used to differentiate between different hardware
+ versions of on-chip IP blocks having their own peculiarities which may or
+ may not be captured by their respective DT compatible strings
+
+properties:
+ compatible:
+ items:
+ - const: via,vt8500-scc-id
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ chipid@d8120000 {
+ compatible = "via,vt8500-scc-id";
+ reg = <0xd8120000 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
index 10e5a53e447b..584cce3211c0 100644
--- a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-a31-hwspinlock.yaml#
@@ -26,11 +26,15 @@ properties:
resets:
maxItems: 1
+ '#hwlock-cells':
+ const: 1
+
required:
- compatible
- reg
- clocks
- resets
+ - "#hwlock-cells"
additionalProperties: false
@@ -44,5 +48,6 @@ examples:
reg = <0x01c18000 0x1000>;
clocks = <&ccu CLK_BUS_SPINLOCK>;
resets = <&ccu RST_BUS_SPINLOCK>;
+ #hwlock-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
index 1c7149f7d171..ee2726149cf3 100644
--- a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
@@ -15,9 +15,22 @@ description:
properties:
compatible:
- enum:
- - qcom,sfpb-mutex
- - qcom,tcsr-mutex
+ oneOf:
+ - enum:
+ - qcom,sfpb-mutex
+ - qcom,tcsr-mutex
+ - items:
+ - enum:
+ - qcom,apq8084-tcsr-mutex
+ - qcom,ipq6018-tcsr-mutex
+ - qcom,msm8226-tcsr-mutex
+ - qcom,msm8994-tcsr-mutex
+ - const: qcom,tcsr-mutex
+ - items:
+ - enum:
+ - qcom,msm8974-tcsr-mutex
+ - const: qcom,tcsr-mutex
+ - const: syscon
reg:
maxItems: 1
@@ -34,9 +47,9 @@ additionalProperties: false
examples:
- |
- tcsr_mutex: hwlock@1f40000 {
- compatible = "qcom,tcsr-mutex";
- reg = <0x01f40000 0x40000>;
- #hwlock-cells = <1>;
- };
+ hwlock@1f40000 {
+ compatible = "qcom,tcsr-mutex";
+ reg = <0x01f40000 0x40000>;
+ #hwlock-cells = <1>;
+ };
...
diff --git a/Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml b/Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml
new file mode 100644
index 000000000000..abe11df25761
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/sprd,hwspinlock-r3p0.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/sprd,hwspinlock-r3p0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum hardware spinlock
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,hwspinlock-r3p0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: enable
+
+ '#hwlock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#hwlock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sprd,sc9860-clk.h>
+
+ hwlock@40500000 {
+ compatible = "sprd,hwspinlock-r3p0";
+ reg = <0x40500000 0x1000>;
+ clocks = <&aon_gate CLK_SPLK_EB>;
+ clock-names = "enable";
+ #hwlock-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt
deleted file mode 100644
index 581db9d941ba..000000000000
--- a/Documentation/devicetree/bindings/hwlock/sprd-hwspinlock.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-SPRD Hardware Spinlock Device Binding
--------------------------------------
-
-Required properties :
-- compatible : should be "sprd,hwspinlock-r3p0".
-- reg : the register address of hwspinlock.
-- #hwlock-cells : hwlock users only use the hwlock id to represent a specific
- hwlock, so the number of cells should be <1> here.
-- clock-names : Must contain "enable".
-- clocks : Must contain a phandle entry for the clock in clock-names, see the
- common clock bindings.
-
-Please look at the generic hwlock binding for usage information for consumers,
-"Documentation/devicetree/bindings/hwlock/hwlock.txt"
-
-Example of hwlock provider:
- hwspinlock@40500000 {
- compatible = "sprd,hwspinlock-r3p0";
- reg = <0 0x40500000 0 0x1000>;
- #hwlock-cells = <1>;
- clock-names = "enable";
- clocks = <&clk_aon_apb_gates0 22>;
- };
diff --git a/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml
index b18c616035a8..829d1fdf4c67 100644
--- a/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/hwlock/st,stm32-hwspinlock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Hardware Spinlock bindings
+title: STMicroelectronics STM32 Hardware Spinlock
maintainers:
- Fabien Dessenne <fabien.dessenne@foss.st.com>
diff --git a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
index 0a955c7b9706..5ba60d532fcd 100644
--- a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
+++ b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwlock/ti,omap-hwspinlock.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/adc128d818.txt b/Documentation/devicetree/bindings/hwmon/adc128d818.txt
deleted file mode 100644
index d0ae46d7bac3..000000000000
--- a/Documentation/devicetree/bindings/hwmon/adc128d818.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-TI ADC128D818 ADC System Monitor With Temperature Sensor
---------------------------------------------------------
-
-Operation modes:
-
- - Mode 0: 7 single-ended voltage readings (IN0-IN6),
- 1 temperature reading (internal)
- - Mode 1: 8 single-ended voltage readings (IN0-IN7),
- no temperature
- - Mode 2: 4 pseudo-differential voltage readings
- (IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6),
- 1 temperature reading (internal)
- - Mode 3: 4 single-ended voltage readings (IN0-IN3),
- 2 pseudo-differential voltage readings
- (IN4-IN5, IN7-IN6),
- 1 temperature reading (internal)
-
-If no operation mode is configured via device tree, the driver keeps the
-currently active chip operation mode (default is mode 0).
-
-
-Required node properties:
-
- - compatible: must be set to "ti,adc128d818"
- - reg: I2C address of the device
-
-Optional node properties:
-
- - ti,mode: Operation mode (u8) (see above).
-
-
-Example (operation mode 2):
-
- adc128d818@1d {
- compatible = "ti,adc128d818";
- reg = <0x1d>;
- ti,mode = /bits/ 8 <2>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml
index ce7f8ce9da0a..236d8b52ef85 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/adi,ad741x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
index d794deb08bb7..be7e9e91a3a8 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
@@ -27,7 +27,7 @@ properties:
shunt-resistor-micro-ohms:
description:
- The value of curent sense resistor in microohms. If not provided,
+ The value of current sense resistor in microohms. If not provided,
the current reading and overcurrent alert is disabled.
adi,shutdown-threshold-microamp:
@@ -46,22 +46,25 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: hwmon-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
pwmon@5a {
- compatible = "adi,adm1177";
- reg = <0x5a>;
- shunt-resistor-micro-ohms = <50000>; /* 50 mOhm */
- adi,shutdown-threshold-microamp = <1059000>; /* 1.059 A */
- adi,vrange-high-enable;
+ compatible = "adi,adm1177";
+ reg = <0x5a>;
+ shunt-resistor-micro-ohms = <50000>; /* 50 mOhm */
+ adi,shutdown-threshold-microamp = <1059000>; /* 1.059 A */
+ adi,vrange-high-enable;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
index 43b4f4f57b49..fe87a592de45 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
@@ -8,7 +8,7 @@ title: Analog Devices ADM1266 Cascadable Super Sequencer with Margin
Control and Fault Recording
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Cedric Encarnacion <cedricjustine.encarnacion@analog.com>
description: |
Analog Devices ADM1266 Cascadable Super Sequencer with Margin
@@ -39,13 +39,13 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
adm1266@40 {
- compatible = "adi,adm1266";
- reg = <0x40>;
+ compatible = "adi,adm1266";
+ reg = <0x40>;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
index ab87f51c5aef..d6a7517f2a50 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/adi,adm1275.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices ADM1075/ADM127x/ADM129x digital power monitors
+title: Analog Devices ADM1075/ADM127x/ADM1281/ADM129x digital power monitors
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
@@ -19,24 +18,30 @@ description: |
Datasheets:
https://www.analog.com/en/products/adm1294.html
+ The SQ24905C is also a Hot-swap controller compatibility to the ADM1278,
+ the PMBUS_MFR_MODEL is MC09C
+
+ Datasheets:
+ https://www.silergy.com/
+ download/downloadFile?id=5669&type=product&ftype=note
+
properties:
compatible:
enum:
- adi,adm1075
- adi,adm1272
+ - adi,adm1273
- adi,adm1275
- adi,adm1276
- adi,adm1278
+ - adi,adm1281
- adi,adm1293
- adi,adm1294
+ - silergy,mc09c
reg:
maxItems: 1
- shunt-resistor-micro-ohms:
- description:
- Shunt resistor value in micro-Ohm.
-
adi,volt-curr-sample-average:
description: |
Number of samples to be used to report voltage and current values.
@@ -50,6 +55,7 @@ properties:
enum: [1, 2, 4, 8, 16, 32, 64, 128]
allOf:
+ - $ref: hwmon-common.yaml#
- if:
properties:
compatible:
@@ -81,6 +87,7 @@ allOf:
contains:
enum:
- adi,adm1272
+ - adi,adm1273
then:
properties:
adi,volt-curr-sample-average:
@@ -94,8 +101,10 @@ allOf:
contains:
enum:
- adi,adm1278
+ - adi,adm1281
- adi,adm1293
- adi,adm1294
+ - silergy,mc09c
then:
properties:
adi,volt-curr-sample-average:
@@ -107,7 +116,7 @@ required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
index 6747b870f297..6751f9b643b4 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
@@ -5,13 +5,13 @@
$id: http://devicetree.org/schemas/hwmon/adi,axi-fan-control.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices AXI FAN Control Device Tree Bindings
+title: Analog Devices AXI FAN Control
maintainers:
- Nuno Sá <nuno.sa@analog.com>
description: |+
- Bindings for the Analog Devices AXI FAN Control driver. Spefications of the
+ Bindings for the Analog Devices AXI FAN Control driver. Specifications of the
core can be found in:
https://wiki.analog.com/resources/fpga/docs/axi_fan_control
@@ -49,15 +49,15 @@ additionalProperties: false
examples:
- |
fpga_axi: fpga-axi {
- #address-cells = <0x2>;
- #size-cells = <0x1>;
-
- axi_fan_control: axi-fan-control@80000000 {
- compatible = "adi,axi-fan-control-1.00.a";
- reg = <0x0 0x80000000 0x10000>;
- clocks = <&clk 71>;
- interrupts = <0 110 0>;
- pulses-per-revolution = <2>;
- };
+ #address-cells = <0x2>;
+ #size-cells = <0x1>;
+
+ axi_fan_control: axi-fan-control@80000000 {
+ compatible = "adi,axi-fan-control-1.00.a";
+ reg = <0x0 0x80000000 0x10000>;
+ clocks = <&clk 71>;
+ interrupts = <0 110 0>;
+ pulses-per-revolution = <2>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml
new file mode 100644
index 000000000000..6401b0a9aff4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2945.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc2945.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2945 wide range i2c power monitor
+
+maintainers:
+ - Guenter Roeck <linux@roeck-us.net>
+
+description: |
+ Analog Devices LTC2945 wide range i2c power monitor over I2C.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/LTC2945.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc2945
+
+ reg:
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description:
+ Shunt resistor value in micro-Ohms
+ default: 1000
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: hwmon-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-monitor@6e {
+ compatible = "adi,ltc2945";
+ reg = <0x6e>;
+ /* 10 milli-Ohm shunt resistor */
+ shunt-resistor-micro-ohms = <10000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
index bf04151b63d2..3e3f49cf2f52 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
@@ -81,21 +81,20 @@ required:
- compatible
- reg
-
additionalProperties: false
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ltc2947_spi: ltc2947@0 {
- compatible = "adi,ltc2947";
- reg = <0>;
- /* accumulation takes place always for energ1/charge1. */
- /* accumulation only on positive current for energy2/charge2. */
- adi,accumulator-ctl-pol = <0 1>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ltc2947_spi: ltc2947@0 {
+ compatible = "adi,ltc2947";
+ reg = <0>;
+ /* accumulation takes place always for energ1/charge1. */
+ /* accumulation only on positive current for energy2/charge2. */
+ adi,accumulator-ctl-pol = <0 1>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml
new file mode 100644
index 000000000000..1ff44cb22ef4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc2991.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2991 Octal I2C Voltage, Current and Temperature Monitor
+
+maintainers:
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description: |
+ The LTC2991 is used to monitor system temperatures, voltages and currents.
+ Through the I2C serial interface, the eight monitors can individually measure
+ supply voltages and can be paired for differential measurements of current
+ sense resistors or temperature sensing transistors.
+
+ Datasheet:
+ https://www.analog.com/en/products/ltc2991.html
+
+properties:
+ compatible:
+ const: adi,ltc2991
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ vcc-supply: true
+
+patternProperties:
+ "^channel@[0-3]$":
+ type: object
+ description:
+ Represents the differential/temperature channels.
+
+ properties:
+ reg:
+ description:
+ The channel number. LTC2991 can monitor 4 currents/temperatures.
+ items:
+ minimum: 0
+ maximum: 3
+
+ shunt-resistor-micro-ohms:
+ description:
+ The value of curent sense resistor in micro ohms. Pin configuration is
+ set for differential input pair.
+
+ adi,temperature-enable:
+ description:
+ Enables temperature readings. Pin configuration is set for remote
+ diode temperature measurement.
+ type: boolean
+
+ required:
+ - reg
+
+ allOf:
+ - if:
+ required:
+ - shunt-resistor-micro-ohms
+ then:
+ properties:
+ adi,temperature-enable: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@48 {
+ compatible = "adi,ltc2991";
+ reg = <0x48>;
+ vcc-supply = <&vcc>;
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@48 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "adi,ltc2991";
+ reg = <0x48>;
+ vcc-supply = <&vcc>;
+
+ channel@0 {
+ reg = <0x0>;
+ shunt-resistor-micro-ohms = <100000>;
+ };
+
+ channel@1 {
+ reg = <0x1>;
+ shunt-resistor-micro-ohms = <100000>;
+ };
+
+ channel@2 {
+ reg = <0x2>;
+ adi,temperature-enable;
+ };
+
+ channel@3 {
+ reg = <0x3>;
+ adi,temperature-enable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
index 64a8fcb7bc46..38a8f3a14c02 100644
--- a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Linear Technology 2992 Power Monitor
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Cedric Encarnacion <cedricjustine.encarnacion@analog.com>
description: |
Linear Technology 2992 Dual Wide Range Power Monitor
@@ -32,6 +32,7 @@ properties:
patternProperties:
"^channel@([0-1])$":
type: object
+ additionalProperties: false
description: |
Represents the two supplies to be monitored.
@@ -45,7 +46,7 @@ patternProperties:
shunt-resistor-micro-ohms:
description:
- The value of curent sense resistor in microohms.
+ The value of current sense resistor in microohms.
required:
- compatible
@@ -55,26 +56,26 @@ additionalProperties: false
examples:
- |
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
- ltc2992@6F {
- #address-cells = <1>;
- #size-cells = <0>;
+ ltc2992@6f {
+ #address-cells = <1>;
+ #size-cells = <0>;
- compatible = "adi,ltc2992";
- reg = <0x6F>;
+ compatible = "adi,ltc2992";
+ reg = <0x6f>;
- channel@0 {
- reg = <0x0>;
- shunt-resistor-micro-ohms = <10000>;
- };
+ channel@0 {
+ reg = <0x0>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
- channel@1 {
- reg = <0x1>;
- shunt-resistor-micro-ohms = <10000>;
- };
+ channel@1 {
+ reg = <0x1>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml
new file mode 100644
index 000000000000..4854b95a93e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc4282.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC4282 I2C High Current Hot Swap Controller over I2C
+
+maintainers:
+ - Nuno Sa <nuno.sa@analog.com>
+
+description: |
+ Analog Devices LTC4282 I2C High Current Hot Swap Controller over I2C.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4282.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc4282
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ adi,rsense-nano-ohms:
+ description: Value of the sense resistor.
+
+ adi,vin-mode-microvolt:
+ description:
+ Selects operating range for the Undervoltage, Overvoltage and Foldback
+ pins. Also for the ADC. Should be set to the nominal input voltage.
+ enum: [3300000, 5000000, 12000000, 24000000]
+ default: 12000000
+
+ adi,fet-bad-timeout-ms:
+ description:
+ From the moment a FET bad conditions is present, this property selects the
+ wait time/timeout for a FET-bad fault to be signaled. Setting this to 0,
+ disables FET bad faults to be reported.
+ default: 255
+ maximum: 255
+
+ adi,overvoltage-dividers:
+ description: |
+ Select which dividers to use for VDD Overvoltage detection. Note that
+ when the internal dividers are used the threshold is referenced to VDD.
+ The percentages in the datasheet are misleading since the actual values
+ to look for are in the "Absolute Maximum Ratings" table in the
+ "Comparator Inputs" section. In there there's a line for each of the 5%,
+ 10% and 15% settings with the actual min, typical and max tolerances.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [external, vdd_5_percent, vdd_10_percent, vdd_15_percent]
+ default: external
+
+ adi,undervoltage-dividers:
+ description: |
+ Select which dividers to use for VDD Overvoltage detection. Note that
+ when the internal dividers are used the threshold is referenced to VDD.
+ The percentages in the datasheet are misleading since the actual values
+ to look for are in the "Absolute Maximum Ratings" table in the
+ "Comparator Inputs" section. In there there's a line for each of the 5%,
+ 10% and 15% settings with the actual min, typical and max tolerances.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [external, vdd_5_percent, vdd_10_percent, vdd_15_percent]
+ default: external
+
+ adi,current-limit-sense-microvolt:
+ description:
+ The current limit sense voltage of the chip is adjustable between
+ 12.5mV and 34.4mV in 3.1mV steps. This effectively limits the current
+ on the load.
+ enum: [12500, 15625, 18750, 21875, 25000, 28125, 31250, 34375]
+ default: 25000
+
+ adi,overcurrent-retry:
+ description:
+ If set, enables the chip to auto-retry 256 timer cycles after an
+ Overcurrent fault.
+ type: boolean
+
+ adi,overvoltage-retry-disable:
+ description:
+ If set, disables the chip to auto-retry 50ms after an Overvoltage fault.
+ It's enabled by default.
+ type: boolean
+
+ adi,undervoltage-retry-disable:
+ description:
+ If set, disables the chip to auto-retry 50ms after an Undervoltage fault.
+ It's enabled by default.
+ type: boolean
+
+ adi,fault-log-enable:
+ description:
+ If set, enables the FAULT_LOG and ADC_ALERT_LOG registers to be written
+ to the EEPROM when a fault bit transitions high and hence, will be
+ available after a power cycle (the chip loads the contents of
+ the EE_FAULT_LOG register - the one in EEPROM - into FAULT_LOG at boot).
+ type: boolean
+
+ adi,gpio1-mode:
+ description: Defines the function of the Pin. It can indicate that power is
+ good (PULL the pin low when power is not good) or that power is bad (Go
+ into high-z when power is not good).
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [power_bad, power_good]
+ default: power_good
+
+ adi,gpio2-mode:
+ description: Defines the function of the Pin. It can be set as the input for
+ the ADC or indicating that the MOSFET is in stress (dissipating power).
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [adc_input, stress_fet]
+ default: adc_input
+
+ adi,gpio3-monitor-enable:
+ description: If set, gpio3 is set as input for the ADC instead of gpio2.
+ type: boolean
+
+allOf:
+ - if:
+ required:
+ - adi,gpio3-monitor-enable
+ then:
+ properties:
+ adi,gpio2-mode:
+ const: stress_fet
+
+required:
+ - compatible
+ - reg
+ - adi,rsense-nano-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@50 {
+ compatible = "adi,ltc4282";
+ reg = <0x50>;
+ adi,rsense-nano-ohms = <500>;
+
+ adi,gpio1-mode = "power_good";
+ adi,gpio2-mode = "adc_input";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml b/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml
new file mode 100644
index 000000000000..c2f7c6ee1a37
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,max31827.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,max31827.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX31827, MAX31828, MAX31829 Low-Power Temperature Switch
+
+maintainers:
+ - Daniel Matyas <daniel.matyas@analog.com>
+
+description: |
+ Analog Devices MAX31827, MAX31828, MAX31829 Low-Power Temperature Switch with
+ I2C Interface
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31827-MAX31829.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - const: adi,max31827
+ - items:
+ - enum:
+ - adi,max31828
+ - adi,max31829
+ - const: adi,max31827
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Must have values in the interval (1.6V; 3.6V) in order for the device to
+ function correctly.
+
+ adi,comp-int:
+ description:
+ If present interrupt mode is used. If not present comparator mode is used
+ (default).
+ type: boolean
+
+ adi,alarm-pol:
+ description:
+ Sets the alarms active state.
+ - 0 = active low
+ - 1 = active high
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ adi,fault-q:
+ description:
+ Select how many consecutive temperature faults must occur before
+ overtemperature or undertemperature faults are indicated in the
+ corresponding status bits.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4, 8]
+
+ adi,timeout-enable:
+ description:
+ Enables timeout. Bus timeout resets the I2C-compatible interface when SCL
+ is low for more than 30ms (nominal).
+ type: boolean
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,max31829
+
+ then:
+ properties:
+ adi,alarm-pol:
+ default: 1
+
+ else:
+ properties:
+ adi,alarm-pol:
+ default: 0
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,max31827
+
+ then:
+ properties:
+ adi,fault-q:
+ default: 1
+
+ else:
+ properties:
+ adi,fault-q:
+ default: 4
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@42 {
+ compatible = "adi,max31827";
+ reg = <0x42>;
+ vref-supply = <&reg_vdd>;
+ adi,comp-int;
+ adi,alarm-pol = <0>;
+ adi,fault-q = <1>;
+ adi,timeout-enable;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml
index ea595102a86e..43e9fe225870 100644
--- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml
+++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml
@@ -45,12 +45,34 @@ properties:
the pwm uses a logic low output for 100% duty cycle. If set to 1 the pwm
uses a logic high output for 100% duty cycle.
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 3
maxItems: 3
items:
enum: [0, 1]
default: 1
+ "#pwm-cells":
+ oneOf:
+ - const: 3
+ - const: 4
+ deprecated: true
+ description: |
+ Number of cells in a PWM specifier.
+ - 0: The PWM channel
+ - 1: The PWM period in nanoseconds
+ - 90909091 (11 Hz)
+ - 71428571 (14 Hz)
+ - 45454545 (22 Hz)
+ - 34482759 (29 Hz)
+ - 28571429 (35 Hz)
+ - 22727273 (44 Hz)
+ - 17241379 (58 Hz)
+ - 11363636 (88 Hz)
+ - 44444 (22 kHz)
+ - 2: PWM flags 0 or PWM_POLARITY_INVERTED
+ - 3: The default PWM duty cycle in nanoseconds, defaults to period.
+
patternProperties:
"^adi,bypass-attenuator-in[0-4]$":
description: |
@@ -61,7 +83,7 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
- "adi,pin(5|10)-function":
+ "^adi,pin(5|10)-function$":
description: |
Configures the function for pin 5 on the adi,adt7473 and adi,adt7475. Or
pin 10 on the adi,adt7476 and adi,adt7490.
@@ -70,7 +92,7 @@ patternProperties:
- pwm2
- smbalert#
- "adi,pin(9|14)-function":
+ "^adi,pin(9|14)-function$":
description: |
Configures the function for pin 9 on the adi,adt7473 and adi,adt7475. Or
pin 14 on the adi,adt7476 and adi,adt7490
@@ -81,6 +103,10 @@ patternProperties:
- smbalert#
- gpio
+ "^fan-[0-9]+$":
+ $ref: fan-common.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -89,17 +115,27 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/pwm/pwm.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
- hwmon@2e {
+ pwm: hwmon@2e {
compatible = "adi,adt7476";
reg = <0x2e>;
adi,bypass-attenuator-in0 = <1>;
adi,bypass-attenuator-in1 = <0>;
- adi,pwm-active-state = <1 0 1>;
adi,pin10-function = "smbalert#";
adi,pin14-function = "tach4";
+ #pwm-cells = <3>;
+
+ /* PWMs at 22.5 kHz frequency */
+ fan-0 {
+ pwms = <&pwm 0 44444 0>;
+ };
+
+ fan-1 {
+ pwms = <&pwm 2 44444 0>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
index 7598b083979c..353d81d89bf5 100644
--- a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
@@ -41,13 +41,13 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
sbrmi@3c {
- compatible = "amd,sbrmi";
- reg = <0x3c>;
+ compatible = "amd,sbrmi";
+ reg = <0x3c>;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
index 446b09f1ce94..75088244a274 100644
--- a/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
@@ -42,13 +42,13 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
sbtsi@4c {
- compatible = "amd,sbtsi";
- reg = <0x4c>;
+ compatible = "amd,sbtsi";
+ reg = <0x4c>;
};
};
...
diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
new file mode 100644
index 000000000000..17351fdbefce
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChipCap 2 humidity and temperature iio sensor
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description: |
+ Relative humidity and temperature sensor on I2C bus.
+
+ Datasheets:
+ https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+
+properties:
+ compatible:
+ oneOf:
+ - const: amphenol,cc2d23
+ - items:
+ - enum:
+ - amphenol,cc2d23s
+ - amphenol,cc2d25
+ - amphenol,cc2d25s
+ - amphenol,cc2d33
+ - amphenol,cc2d33s
+ - amphenol,cc2d35
+ - amphenol,cc2d35s
+ - const: amphenol,cc2d23
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: measurement ready indicator
+ - description: low humidity alarm
+ - description: high humidity alarm
+
+ interrupt-names:
+ items:
+ - const: ready
+ - const: low
+ - const: high
+
+ vdd-supply:
+ description:
+ Dedicated, controllable supply-regulator to reset the device and
+ enter in command mode.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ humidity@28 {
+ compatible = "amphenol,cc2d23s", "amphenol,cc2d23";
+ reg = <0x28>;
+ interrupt-parent = <&gpio>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>,
+ <5 IRQ_TYPE_EDGE_RISING>,
+ <6 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ready", "low", "high";
+ vdd-supply = <&reg_vdd>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/apm,xgene-slimpro-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/apm,xgene-slimpro-hwmon.yaml
new file mode 100644
index 000000000000..58c51626a9ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/apm,xgene-slimpro-hwmon.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/apm,xgene-slimpro-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SLIMpro hwmon
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+properties:
+ compatible:
+ const: apm,xgene-slimpro-hwmon
+
+ mboxes:
+ maxItems: 1
+
+required:
+ - compatible
+ - mboxes
+
+additionalProperties: false
+
+examples:
+ - |
+ hwmon {
+ compatible = "apm,xgene-slimpro-hwmon";
+ mboxes = <&mailbox 7>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
deleted file mode 100644
index 59b38557f1bb..000000000000
--- a/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-APM X-Gene hwmon driver
-
-APM X-Gene SOC sensors are accessed over the "SLIMpro" mailbox.
-
-Required properties :
- - compatible : should be "apm,xgene-slimpro-hwmon"
- - mboxes : use the label reference for the mailbox as the first parameter.
- The second parameter is the channel number.
-
-Example :
- hwmonslimpro {
- compatible = "apm,xgene-slimpro-hwmon";
- mboxes = <&mailbox 7>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/as370.txt b/Documentation/devicetree/bindings/hwmon/as370.txt
deleted file mode 100644
index d102fe765124..000000000000
--- a/Documentation/devicetree/bindings/hwmon/as370.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-Bindings for Synaptics AS370 PVT sensors
-
-Required properties:
-- compatible : "syna,as370-hwmon"
-- reg : address and length of the register set.
-
-Example:
- hwmon@ea0810 {
- compatible = "syna,as370-hwmon";
- reg = <0xea0810 0xc>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
new file mode 100644
index 000000000000..851fb16ec7fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed,g6-pwm-tach.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2023 Aspeed, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/aspeed,g6-pwm-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED G6 PWM and Fan Tach controller
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description: |
+ The ASPEED PWM controller can support up to 16 PWM outputs.
+ The ASPEED Fan Tacho controller can support up to 16 fan tach input.
+ They are independent hardware blocks, which are different from the
+ previous version of the ASPEED chip.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: aspeed,ast2700-pwm-tach
+ - const: aspeed,ast2600-pwm-tach
+ - const: aspeed,ast2600-pwm-tach
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+patternProperties:
+ "^fan-[0-9]+$":
+ $ref: fan-common.yaml#
+ unevaluatedProperties: false
+ required:
+ - tach-ch
+
+required:
+ - reg
+ - clocks
+ - resets
+ - "#pwm-cells"
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+ pwm_tach: pwm-tach-controller@1e610000 {
+ compatible = "aspeed,ast2600-pwm-tach";
+ reg = <0x1e610000 0x100>;
+ clocks = <&syscon ASPEED_CLK_AHB>;
+ resets = <&syscon ASPEED_RESET_PWM>;
+ #pwm-cells = <3>;
+
+ fan-0 {
+ tach-ch = /bits/ 8 <0x0>;
+ pwms = <&pwm_tach 0 40000 0>;
+ };
+
+ fan-1 {
+ tach-ch = /bits/ 8 <0x1 0x2>;
+ pwms = <&pwm_tach 1 40000 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
index 3ac02988a1a5..8645cd3b867a 100644
--- a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -45,7 +45,7 @@ Required properties for each child node:
- aspeed,fan-tach-ch : should specify the Fan tach input channel.
integer value in the range 0 through 15, with 0 indicating
Fan tach channel 0 and 15 indicating Fan tach channel 15.
- Atleast one Fan tach input channel is required.
+ At least one Fan tach input channel is required.
Examples:
diff --git a/Documentation/devicetree/bindings/hwmon/fan-common.yaml b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
new file mode 100644
index 000000000000..0fb738081699
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/fan-common.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/fan-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Fan Properties
+
+maintainers:
+ - Naresh Solanki <naresh.solanki@9elements.com>
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+properties:
+ max-rpm:
+ description:
+ Max RPM supported by fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 100000
+
+ min-rpm:
+ description:
+ Min RPM supported by fan.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 1000
+
+ pulses-per-revolution:
+ description:
+ The number of pulse from fan sensor per revolution.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 4
+
+ tach-div:
+ description:
+ Divisor for the tach sampling clock, which determines the sensitivity of the tach pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ target-rpm:
+ description:
+ The default desired fan speed in RPM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ fan-driving-mode:
+ description:
+ Select the driving mode of the fan.(DC, PWM and so on)
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ dc, pwm ]
+
+ pwms:
+ description:
+ PWM provider.
+ maxItems: 1
+
+ "#cooling-cells":
+ const: 2
+
+ cooling-levels:
+ description:
+ The control value which correspond to thermal cooling states.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ tach-ch:
+ description:
+ The tach channel used for the fan.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+
+ label:
+ description:
+ Optional fan label
+
+ fan-supply:
+ description:
+ Power supply for fan.
+
+ reg:
+ maxItems: 1
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/hwmon/g762.txt b/Documentation/devicetree/bindings/hwmon/g762.txt
deleted file mode 100644
index 6d154c4923de..000000000000
--- a/Documentation/devicetree/bindings/hwmon/g762.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-GMT G762/G763 PWM Fan controller
-
-Required node properties:
-
- - "compatible": must be either "gmt,g762" or "gmt,g763"
- - "reg": I2C bus address of the device
- - "clocks": a fixed clock providing input clock frequency
- on CLK pin of the chip.
-
-Optional properties:
-
- - "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
- The higher the more.
-
- - "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
- and 1 (negative duty).
-
- - "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
-
-If an optional property is not set in .dts file, then current value is kept
-unmodified (e.g. u-boot installed value).
-
-Additional information on operational parameters for the device is available
-in Documentation/hwmon/g762.rst. A detailed datasheet for the device is available
-at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
-
-Example g762 node:
-
- clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
- g762_clk: fixedclk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <8192>;
- }
- }
-
- g762: g762@3e {
- compatible = "gmt,g762";
- reg = <0x3e>;
- clocks = <&g762_clk>
- fan_gear_mode = <0>; /* chip default */
- fan_startv = <1>; /* chip default */
- pwm_polarity = <0>; /* chip default */
- };
diff --git a/Documentation/devicetree/bindings/hwmon/gmt,g762.yaml b/Documentation/devicetree/bindings/hwmon/gmt,g762.yaml
new file mode 100644
index 000000000000..8e1bffd252e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/gmt,g762.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/gmt,g762.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GMT G761/G762/G763 PWM Fan controller
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |
+ GMT G761/G762/G763 PWM Fan controller.
+
+ G761 supports an internal-clock hence the clocks property is optional.
+ If not defined, internal-clock will be used. (31KHz is the clock of
+ the internal crystal oscillator)
+
+ If an optional property is not set in DT, then current value is kept
+ unmodified (e.g. bootloader installed value).
+
+ Additional information on operational parameters for the device is available
+ in Documentation/hwmon/g762.rst. A detailed datasheet for the device is available
+ at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
+
+properties:
+ compatible:
+ enum:
+ - gmt,g761
+ - gmt,g762
+ - gmt,g763
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: a fixed clock providing input clock frequency on CLK
+ pin of the chip.
+ maxItems: 1
+
+ fan_startv:
+ description: Fan startup voltage step
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ pwm_polarity:
+ description: PWM polarity (positive or negative duty)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ fan_gear_mode:
+ description: FAN gear mode. Configure High speed fan setting factor
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+required:
+ - compatible
+ - reg
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - gmt,g762
+ - gmt,g763
+then:
+ required:
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ g762@3e {
+ compatible = "gmt,g762";
+ reg = <0x3e>;
+ clocks = <&g762_clk>;
+ fan_gear_mode = <0>;
+ fan_startv = <1>;
+ pwm_polarity = <0>;
+ };
+
+ g761@1e {
+ compatible = "gmt,g761";
+ reg = <0x1e>;
+ fan_gear_mode = <0>;
+ fan_startv = <1>;
+ pwm_polarity = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
deleted file mode 100644
index f4cfa350f6a1..000000000000
--- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Bindings for fan connected to GPIO lines
-
-Required properties:
-- compatible : "gpio-fan"
-
-Optional properties:
-- gpios: Specifies the pins that map to bits in the control value,
- ordered MSB-->LSB.
-- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
- control value that should be set to achieve them. This array
- must have the RPM values in ascending order.
-- alarm-gpios: This pin going active indicates something is wrong with
- the fan, and a udev event will be fired.
-- #cooling-cells: If used as a cooling device, must be <2>
- Also see:
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
- min and max states are derived from the speed-map of the fan.
-
-Note: At least one the "gpios" or "alarm-gpios" properties must be set.
-
-Examples:
-
- gpio_fan {
- compatible = "gpio-fan";
- gpios = <&gpio1 14 1
- &gpio1 13 1>;
- gpio-fan,speed-map = <0 0
- 3000 1
- 6000 2>;
- alarm-gpios = <&gpio1 15 1>;
- };
- gpio_fan_cool: gpio_fan {
- compatible = "gpio-fan";
- gpios = <&gpio2 14 1
- &gpio2 13 1>;
- gpio-fan,speed-map = <0 0>,
- <3000 1>,
- <6000 2>;
- alarm-gpios = <&gpio2 15 1>;
- #cooling-cells = <2>; /* min followed by max */
- };
diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
new file mode 100644
index 000000000000..4faebbb4c7ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/gpio-fan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fan connected to GPIO lines
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+properties:
+ compatible:
+ const: gpio-fan
+
+ gpios:
+ description: |
+ Specifies the pins that map to bits in the control value,
+ ordered MSB-->LSB.
+ minItems: 1
+ maxItems: 7
+
+ alarm-gpios:
+ maxItems: 1
+
+ fan-supply:
+ description: Power supply for fan
+
+ gpio-fan,speed-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 127
+ items:
+ items:
+ - description: fan speed in RPMs
+ - description: control value
+ description: |
+ A mapping of possible fan RPM speeds and the
+ control value that should be set to achieve them. This array
+ must have the RPM values in ascending order.
+
+ '#cooling-cells':
+ const: 2
+
+required:
+ - compatible
+ - gpios
+ - gpio-fan,speed-map
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio-fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio2 14 1
+ &gpio2 13 1>;
+ gpio-fan,speed-map = < 0 0>,
+ <3000 1>,
+ <6000 2>;
+ alarm-gpios = <&gpio2 15 1>;
+ #cooling-cells = <2>; /* min followed by max */
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml b/Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml
new file mode 100644
index 000000000000..4a52aac6be72
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/hpe,gxp-fan-ctrl.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/hpe,gxp-fan-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE GXP Fan Controller
+
+maintainers:
+ - Nick Hawkins <nick.hawkins@hpe.com>
+
+description: |
+ The HPE GXP fan controller controls the fans through an external CPLD
+ device that connects to the fans.
+
+properties:
+ compatible:
+ const: hpe,gxp-fan-ctrl
+
+ reg:
+ items:
+ - description: Fan controller PWM
+ - description: Programmable logic
+ - description: Function 2
+
+ reg-names:
+ items:
+ - const: base
+ - const: pl
+ - const: fn2
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ fan-controller@1000c00 {
+ compatible = "hpe,gxp-fan-ctrl";
+ reg = <0x1000c00 0x200>, <0xd1000000 0xff>, <0x80200000 0x100000>;
+ reg-names = "base", "pl", "fn2";
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/hwmon-common.yaml b/Documentation/devicetree/bindings/hwmon/hwmon-common.yaml
new file mode 100644
index 000000000000..dc86b5c72cf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/hwmon-common.yaml
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/hwmon-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hardware Monitoring Devices Common Properties
+
+maintainers:
+ - Guenter Roeck <linux@roeck-us.net>
+
+properties:
+ label:
+ description: A descriptive name for this device.
+
+ shunt-resistor-micro-ohms:
+ description: The value of current sense resistor.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,occ-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/ibm,occ-hwmon.yaml
new file mode 100644
index 000000000000..3dbdc5af2804
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibm,occ-hwmon.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ibm,occ-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM On-Chip Controller (OCC) accessed from a service processor
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description: |
+ The POWER processor On-Chip Controller (OCC) helps manage power and
+ thermals for the system. A service processor or baseboard management
+ controller can query the OCC for it's power and thermal data to report
+ through hwmon.
+
+properties:
+ compatible:
+ enum:
+ - ibm,p9-occ-hwmon
+ - ibm,p10-occ-hwmon
+
+ ibm,no-poll-on-init:
+ description: This property describes whether or not the OCC should
+ be polled during driver initialization.
+ type: boolean
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ hwmon {
+ compatible = "ibm,p10-occ-hwmon";
+ ibm,no-poll-on-init;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml b/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
new file mode 100644
index 000000000000..376ee7f1cdb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ibm,opal-sensor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM POWERNV platform sensors
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ibm,opal-sensor-cooling-fan
+ - ibm,opal-sensor-amb-temp
+ - ibm,opal-sensor-power-supply
+ - ibm,opal-sensor-power
+
+ sensor-id:
+ description:
+ An opaque id provided by the firmware to the kernel, identifies a
+ given sensor and its attribute data.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - sensor-id
+
+additionalProperties: false
+
+examples:
+ - |
+ sensor {
+ compatible = "ibm,opal-sensor-cooling-fan";
+ sensor-id = <0x7052107>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt b/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
deleted file mode 100644
index 5dc5d2e2573d..000000000000
--- a/Documentation/devicetree/bindings/hwmon/ibm,p8-occ-hwmon.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Device-tree bindings for I2C-based On-Chip Controller hwmon device
-------------------------------------------------------------------
-
-Required properties:
- - compatible = "ibm,p8-occ-hwmon";
- - reg = <I2C address>; : I2C bus address
-
-Examples:
-
- i2c-bus@100 {
- #address-cells = <1>;
- #size-cells = <0>;
- clock-frequency = <100000>;
- < more properties >
-
- occ-hwmon@1 {
- compatible = "ibm,p8-occ-hwmon";
- reg = <0x50>;
- };
-
- occ-hwmon@2 {
- compatible = "ibm,p8-occ-hwmon";
- reg = <0x51>;
- };
- };
diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
deleted file mode 100644
index f93242be60a1..000000000000
--- a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-IBM POWERNV platform sensors
-----------------------------
-
-Required node properties:
-- compatible: must be one of
- "ibm,opal-sensor-cooling-fan"
- "ibm,opal-sensor-amb-temp"
- "ibm,opal-sensor-power-supply"
- "ibm,opal-sensor-power"
-- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
- given sensor and its attribute data
-
-Example sensors node:
-
-cooling-fan#8-data {
- sensor-id = <0x7052107>;
- compatible = "ibm,opal-sensor-cooling-fan";
-};
-
-amb-temp#1-thrs {
- sensor-id = <0x5096000>;
- compatible = "ibm,opal-sensor-amb-temp";
-};
diff --git a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
index f5a6cc3efd33..be5c7d4579bb 100644
--- a/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
+++ b/Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ADC-attached Hardware Sensor Device Tree Bindings
+title: ADC-attached Hardware Sensor
maintainers:
- Jonathan Cameron <jic23@kernel.org>
@@ -19,7 +19,7 @@ properties:
io-channels:
minItems: 1
- maxItems: 8 # Should be enough
+ maxItems: 51 # Should be enough
description: >
List of phandles to ADC channels to read the monitoring values
@@ -31,7 +31,7 @@ additionalProperties: false
examples:
- |
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = <&adc 1>, <&adc 2>;
- };
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc 1>, <&adc 2>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ina3221.txt b/Documentation/devicetree/bindings/hwmon/ina3221.txt
deleted file mode 100644
index fa63b6171407..000000000000
--- a/Documentation/devicetree/bindings/hwmon/ina3221.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Texas Instruments INA3221 Device Tree Bindings
-
-1) ina3221 node
- Required properties:
- - compatible: Must be "ti,ina3221"
- - reg: I2C address
-
- Optional properties:
- - ti,single-shot: This chip has two power modes: single-shot (chip takes one
- measurement and then shuts itself down) and continuous (
- chip takes continuous measurements). The continuous mode is
- more reliable and suitable for hardware monitor type device,
- but the single-shot mode is more power-friendly and useful
- for battery-powered device which cares power consumptions
- while still needs some measurements occasionally.
- If this property is present, the single-shot mode will be
- used, instead of the default continuous one for monitoring.
-
- = The node contains optional child nodes for three channels =
- = Each child node describes the information of input source =
-
- - #address-cells: Required only if a child node is present. Must be 1.
- - #size-cells: Required only if a child node is present. Must be 0.
-
-2) child nodes
- Required properties:
- - reg: Must be 0, 1 or 2, corresponding to IN1, IN2 or IN3 port of INA3221
-
- Optional properties:
- - label: Name of the input source
- - shunt-resistor-micro-ohms: Shunt resistor value in micro-Ohm
-
-Example:
-
-ina3221@40 {
- compatible = "ti,ina3221";
- reg = <0x40>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- input@0 {
- reg = <0x0>;
- status = "disabled";
- };
- input@1 {
- reg = <0x1>;
- shunt-resistor-micro-ohms = <5000>;
- };
- input@2 {
- reg = <0x2>;
- label = "VDD_5V";
- shunt-resistor-micro-ohms = <5000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml
index 0e49b3901161..bf3332153ad8 100644
--- a/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml
+++ b/Documentation/devicetree/bindings/hwmon/jedec,jc42.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/jedec,jc42.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
index 010333cb25c0..966b221b6caa 100644
--- a/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
+++ b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml
@@ -11,11 +11,12 @@ maintainers:
description: |
This module is part of the sl28cpld multi-function device. For more
- details see ../mfd/kontron,sl28cpld.yaml.
+ details see ../embedded-controller/kontron,sl28cpld.yaml.
properties:
compatible:
enum:
+ - kontron,sa67mcu-hwmon
- kontron,sl28cpld-fan
reg:
diff --git a/Documentation/devicetree/bindings/hwmon/lantiq,cputemp.yaml b/Documentation/devicetree/bindings/hwmon/lantiq,cputemp.yaml
new file mode 100644
index 000000000000..9419b481ff35
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lantiq,cputemp.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/lantiq,cputemp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq cpu temperature sensor
+
+maintainers:
+ - Florian Eckert <fe@dev.tdt.de>
+
+properties:
+ compatible:
+ const: lantiq,cputemp
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ cputemp@103040 {
+ compatible = "lantiq,cputemp";
+ reg = <0x103040 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml
new file mode 100644
index 000000000000..ea8b1553a3e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/lltc,ltc2978.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Octal Digital Power-supply monitor/supervisor/sequencer/margin controller.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - lltc,lt7170
+ - lltc,lt7171
+ - lltc,ltc2972
+ - lltc,ltc2974
+ - lltc,ltc2975
+ - lltc,ltc2977
+ - lltc,ltc2978
+ - lltc,ltc2979
+ - lltc,ltc2980
+ - lltc,ltc3880
+ - lltc,ltc3882
+ - lltc,ltc3883
+ - lltc,ltc3884
+ - lltc,ltc3886
+ - lltc,ltc3887
+ - lltc,ltc3889
+ - lltc,ltc7132
+ - lltc,ltc7841
+ - lltc,ltc7880
+ - lltc,ltm2987
+ - lltc,ltm4664
+ - lltc,ltm4673
+ - lltc,ltm4675
+ - lltc,ltm4676
+ - lltc,ltm4677
+ - lltc,ltm4678
+ - lltc,ltm4680
+ - lltc,ltm4686
+ - lltc,ltm4700
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: |
+ list of regulators provided by this controller.
+ Valid names of regulators depend on number of supplies supported per device:
+ * lt7170, lt7171 : vout0
+ * ltc2972 vout0 - vout1
+ * ltc2974, ltc2975 : vout0 - vout3
+ * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7
+ * ltc2978 : vout0 - vout7
+ * ltc3880, ltc3882, ltc3884, ltc3886, ltc3887, ltc3889 : vout0 - vout1
+ * ltc7132 : vout0 - vout1
+ * ltc7841 : vout0
+ * ltc7880 : vout0 - vout1
+ * ltc3883 : vout0
+ * ltm4664 : vout0 - vout1
+ * ltm4673 : vout0 - vout3
+ * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1
+ * ltm4680, ltm4686 : vout0 - vout1
+ * ltm4700 : vout0 - vout1
+
+ patternProperties:
+ "^vout[0-7]$":
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@5e {
+ compatible = "lltc,ltc2978";
+ reg = <0x5e>;
+
+ regulators {
+ vout0 {
+ regulator-name = "FPGA-2.5V";
+ };
+ vout2 {
+ regulator-name = "FPGA-1.5V";
+ };
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml
index b1a4c235376e..8f0095bb7f6e 100644
--- a/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4151.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/lltc,ltc4151.yaml#
@@ -25,7 +25,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: hwmon-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml
new file mode 100644
index 000000000000..853df9fef6c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/lltc,ltc4286.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LTC4286 power monitors
+
+maintainers:
+ - Delphine CC Chiu <Delphine_CC_Chiu@Wiwynn.com>
+
+properties:
+ compatible:
+ enum:
+ - lltc,ltc4286
+ - lltc,ltc4287
+
+ reg:
+ maxItems: 1
+
+ adi,vrange-low-enable:
+ description:
+ This property is a bool parameter to represent the
+ voltage range is 25.6 volts or 102.4 volts for this chip.
+ The default is 102.4 volts.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: hwmon-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-monitor@40 {
+ compatible = "lltc,ltc4286";
+ reg = <0x40>;
+ adi,vrange-low-enable;
+ shunt-resistor-micro-ohms = <300>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index 8226e3b5d028..0b9fda81e3ec 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/lm75.yaml#
@@ -14,6 +14,7 @@ properties:
compatible:
enum:
- adi,adt75
+ - ams,as6200
- atmel,at30ts74
- dallas,ds1775
- dallas,ds75
@@ -27,6 +28,8 @@ properties:
- maxim,max31725
- maxim,max31726
- maxim,mcp980x
+ - nxp,p3t1750
+ - nxp,p3t1755
- nxp,pct2075
- st,stds75
- st,stlm75
@@ -48,11 +51,31 @@ properties:
vs-supply:
description: phandle to the regulator that provides the +VS supply
+ interrupts:
+ maxItems: 1
+
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: hwmon-common.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ams,as6200
+ - ti,tmp100
+ - ti,tmp101
+ - ti,tmp112
+ - ti,tmp75
+ then:
+ properties:
+ interrupts: false
+
+unevaluatedProperties: false
examples:
- |
@@ -66,3 +89,17 @@ examples:
vs-supply = <&vs>;
};
};
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@48 {
+ compatible = "ams,as6200";
+ reg = <0x48>;
+ vs-supply = <&vs>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <17 IRQ_TYPE_EDGE_BOTH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt
deleted file mode 100644
index e1b79903f204..000000000000
--- a/Documentation/devicetree/bindings/hwmon/lm87.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-*LM87 hwmon sensor.
-
-Required properties:
-- compatible: Should be
- "ti,lm87"
-
-- reg: I2C address
-
-optional properties:
-- has-temp3: This configures pins 18 and 19 to be used as a second
- remote temperature sensing channel. By default the pins
- are configured as voltage input pins in0 and in5.
-
-- has-in6: When set, pin 5 is configured to be used as voltage input
- in6. Otherwise the pin is set as FAN1 input.
-
-- has-in7: When set, pin 6 is configured to be used as voltage input
- in7. Otherwise the pin is set as FAN2 input.
-
-- vcc-supply: a Phandle for the regulator supplying power, can be
- cofigured to measure 5.0V power supply. Default is 3.3V.
-
-Example:
-
-lm87@2e {
- compatible = "ti,lm87";
- reg = <0x2e>;
- has-temp3;
- vcc-supply = <&reg_5v0>;
-};
diff --git a/Documentation/devicetree/bindings/hwmon/ltc2978.txt b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
deleted file mode 100644
index 4e7f6215a453..000000000000
--- a/Documentation/devicetree/bindings/hwmon/ltc2978.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-ltc2978
-
-Required properties:
-- compatible: should contain one of:
- * "lltc,ltc2972"
- * "lltc,ltc2974"
- * "lltc,ltc2975"
- * "lltc,ltc2977"
- * "lltc,ltc2978"
- * "lltc,ltc2979"
- * "lltc,ltc2980"
- * "lltc,ltc3880"
- * "lltc,ltc3882"
- * "lltc,ltc3883"
- * "lltc,ltc3884"
- * "lltc,ltc3886"
- * "lltc,ltc3887"
- * "lltc,ltc3889"
- * "lltc,ltc7880"
- * "lltc,ltm2987"
- * "lltc,ltm4664"
- * "lltc,ltm4675"
- * "lltc,ltm4676"
- * "lltc,ltm4677"
- * "lltc,ltm4678"
- * "lltc,ltm4680"
- * "lltc,ltm4686"
- * "lltc,ltm4700"
-- reg: I2C slave address
-
-Optional properties:
-- regulators: A node that houses a sub-node for each regulator controlled by
- the device. Each sub-node is identified using the node's name, with valid
- values listed below. The content of each sub-node is defined by the
- standard binding for regulators; see regulator.txt.
-
-Valid names of regulators depend on number of supplies supported per device:
- * ltc2972 vout0 - vout1
- * ltc2974, ltc2975 : vout0 - vout3
- * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7
- * ltc2978 : vout0 - vout7
- * ltc3880, ltc3882, ltc3884, ltc3886, ltc3887, ltc3889 : vout0 - vout1
- * ltc7880 : vout0 - vout1
- * ltc3883 : vout0
- * ltm4664 : vout0 - vout1
- * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1
- * ltm4680, ltm4686 : vout0 - vout1
- * ltm4700 : vout0 - vout1
-
-Example:
-ltc2978@5e {
- compatible = "lltc,ltc2978";
- reg = <0x5e>;
- regulators {
- vout0 {
- regulator-name = "FPGA-2.5V";
- };
- vout2 {
- regulator-name = "FPGA-1.5V";
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
deleted file mode 100644
index 33fd00a987c7..000000000000
--- a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Lantiq cpu temperatur sensor
-
-Requires node properties:
-- compatible value :
- "lantiq,cputemp"
-
-Example:
- cputemp@0 {
- compatible = "lantiq,cputemp";
- };
diff --git a/Documentation/devicetree/bindings/hwmon/max31785.txt b/Documentation/devicetree/bindings/hwmon/max31785.txt
deleted file mode 100644
index 106e08c56aaa..000000000000
--- a/Documentation/devicetree/bindings/hwmon/max31785.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Bindings for the Maxim MAX31785 Intelligent Fan Controller
-==========================================================
-
-Reference:
-
-https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
-
-The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
-management with temperature and remote voltage sensing. Various fan control
-features are provided, including PWM frequency control, temperature hysteresis,
-dual tachometer measurements, and fan health monitoring.
-
-Required properties:
-- compatible : One of "maxim,max31785" or "maxim,max31785a"
-- reg : I2C address, one of 0x52, 0x53, 0x54, 0x55.
-
-Example:
-
- fans@52 {
- compatible = "maxim,max31785";
- reg = <0x52>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/max6650.txt b/Documentation/devicetree/bindings/hwmon/max6650.txt
deleted file mode 100644
index f6bd87d8e284..000000000000
--- a/Documentation/devicetree/bindings/hwmon/max6650.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Bindings for MAX6651 and MAX6650 I2C fan controllers
-
-Reference:
-[1] https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf
-
-Required properties:
-- compatible : One of "maxim,max6650" or "maxim,max6651"
-- reg : I2C address, one of 0x1b, 0x1f, 0x4b, 0x48.
-
-Optional properties, default is to retain the chip's current setting:
-- maxim,fan-microvolt : The supply voltage of the fan, either 5000000 uV or
- 12000000 uV.
-- maxim,fan-prescale : Pre-scaling value, as per datasheet [1]. Lower values
- allow more fine-grained control of slower fans.
- Valid: 1, 2, 4, 8, 16.
-- maxim,fan-target-rpm: Initial requested fan rotation speed. If specified, the
- driver selects closed-loop mode and the requested speed.
- This ensures the fan is already running before userspace
- takes over.
-
-Example:
- fan-max6650: max6650@1b {
- reg = <0x1b>;
- compatible = "maxim,max6650";
- maxim,fan-microvolt = <12000000>;
- maxim,fan-prescale = <4>;
- maxim,fan-target-rpm = <1200>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml
index 93e86e3b4602..8588d97ba6ec 100644
--- a/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/maxim,max20730.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
@@ -26,6 +25,7 @@ description: |
properties:
compatible:
enum:
+ - maxim,max20710
- maxim,max20730
- maxim,max20734
- maxim,max20743
diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
new file mode 100644
index 000000000000..558cbd251b0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max31790.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/maxim,max31790.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Maxim MAX31790 Fan Controller
+
+maintainers:
+ - Guenter Roeck <linux@roeck-us.net>
+ - Chanh Nguyen <chanh@os.amperecomputing.com>
+
+description: >
+ The MAX31790 controls the speeds of up to six fans using six
+ independent PWM outputs. The desired fan speeds (or PWM duty cycles)
+ are written through the I2C interface.
+
+ Datasheets:
+ https://datasheets.maximintegrated.com/en/ds/MAX31790.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,max31785
+ - maxim,max31785a
+ - maxim,max31785b
+ - maxim,max31790
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ "#pwm-cells":
+ const: 1
+
+patternProperties:
+ "^fan@[0-9]+$":
+ $ref: fan-common.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pwm_provider: fan-controller@20 {
+ compatible = "maxim,max31790";
+ reg = <0x20>;
+ clocks = <&sys_clk>;
+ resets = <&reset 0>;
+ #address-cells = <1>;
+ #pwm-cells = <1>;
+ #size-cells = <0>;
+
+ fan@0 {
+ reg = <0x0>;
+ pwms = <&pwm_provider 1>;
+ };
+
+ fan@1 {
+ reg = <0x1>;
+ pwms = <&pwm_provider 2>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
new file mode 100644
index 000000000000..139a95e00fe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/maxim,max6639.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim max6639
+
+maintainers:
+ - Naresh Solanki <naresh.solanki@9elements.com>
+
+description: |
+ The MAX6639 is a 2-channel temperature monitor with dual, automatic, PWM
+ fan-speed controller. It monitors its own temperature and one external
+ diode-connected transistor or the temperatures of two external diode-connected
+ transistors, typically available in CPUs, FPGAs, or GPUs.
+
+ Datasheets:
+ https://datasheets.maximintegrated.com/en/ds/MAX6639-MAX6639F.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,max6639
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#pwm-cells':
+ const: 3
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^fan@[0-1]$":
+ type: object
+ description:
+ Represents the two fans and their specific configuration.
+
+ $ref: fan-common.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ The fan number.
+
+ required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fan1: fan-controller@10 {
+ compatible = "maxim,max6639";
+ reg = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pwm-cells = <3>;
+
+ fan@0 {
+ reg = <0x0>;
+ pulses-per-revolution = <2>;
+ max-rpm = <4000>;
+ target-rpm = <1000>;
+ pwms = <&fan1 0 25000 0>;
+ };
+
+ fan@1 {
+ reg = <0x1>;
+ pulses-per-revolution = <2>;
+ max-rpm = <8000>;
+ pwms = <&fan1 1 25000 0>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml
new file mode 100644
index 000000000000..24c7697fdc1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/maxim,max6650.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX6650 and MAX6651 I2C Fan Controllers
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description: |
+ The MAX6650 and MAX6651 regulate and monitor the speed
+ of 5VDC/12VDC burshless fans with built-in tachometers.
+
+ Datasheets:
+ https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,max6650
+ - maxim,max6651
+
+ reg:
+ maxItems: 1
+
+ maxim,fan-microvolt:
+ description:
+ The supply voltage of the fan, either 5000000 uV or
+ 12000000 uV.
+ enum: [5000000, 12000000]
+
+ maxim,fan-prescale:
+ description:
+ Pre-scaling value, as per datasheet. Lower values
+ allow more fine-grained control of slower fans.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4, 8, 16]
+
+ maxim,fan-target-rpm:
+ description:
+ Initial requested fan rotation speed. If specified, the
+ driver selects closed-loop mode and the requested speed.
+ This ensures the fan is already running before userspace
+ takes over.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 30000
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fan-controller@1b {
+ compatible = "maxim,max6650";
+ reg = <0x1b>;
+ maxim,fan-microvolt = <12000000>;
+ maxim,fan-prescale = <4>;
+ maxim,fan-target-rpm = <1200>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
new file mode 100644
index 000000000000..d3f06ebc19fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/microchip,emc2305.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip EMC2305 SMBus compliant PWM fan controller
+
+maintainers:
+ - Michael Shych <michaelsh@nvidia.com>
+
+description:
+ Microchip EMC2301/2/3/5 pwm controller which supports up to five programmable
+ fan control circuits.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - microchip,emc2305
+ - items:
+ - enum:
+ - microchip,emc2303
+ - microchip,emc2302
+ - microchip,emc2301
+ - const: microchip,emc2305
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#pwm-cells':
+ const: 3
+ description: |
+ Number of cells in a PWM specifier.
+ - cell 0: The PWM frequency
+ - cell 1: The PWM polarity: 0 or PWM_POLARITY_INVERTED
+ - cell 2: The PWM output config:
+ - 0 (Open-Drain)
+ - 1 (Push-Pull)
+
+patternProperties:
+ '^fan@[0-4]$':
+ $ref: fan-common.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ description:
+ The fan number used to determine the associated PWM channel.
+ maxItems: 1
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pwm/pwm.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fan_controller: fan-controller@2f {
+ compatible = "microchip,emc2305";
+ reg = <0x2f>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pwm-cells = <3>;
+
+ fan@0 {
+ reg = <0x0>;
+ pwms = <&fan_controller 26000 PWM_POLARITY_INVERTED 1>;
+ #cooling-cells = <2>;
+ };
+
+ fan@1 {
+ reg = <0x1>;
+ pwms = <&fan_controller 26000 0 1>;
+ #cooling-cells = <2>;
+ };
+
+ fan@2 {
+ reg = <0x2>;
+ pwms = <&fan_controller 26000 0 1>;
+ #cooling-cells = <2>;
+ };
+
+ fan@3 {
+ reg = <0x3>;
+ pwms = <&fan_controller 26000 0 1>;
+ #cooling-cells = <2>;
+ };
+
+ fan@4 {
+ reg = <0x4>;
+ pwms = <&fan_controller 26000 0 1>;
+ #cooling-cells = <2>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml
index 028d6e570131..f5e104c1b0d0 100644
--- a/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml
+++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp3021.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/microchip,mcp3021.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
index d0d549749208..56db2292f062 100644
--- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
+++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/hwmon/moortec,mr75203.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Moortec Semiconductor MR75203 PVT Controller bindings
+title: Moortec Semiconductor MR75203 PVT Controller
maintainers:
- Rahul Tanwar <rtanwar@maxlinear.com>
@@ -42,7 +42,7 @@ properties:
reg:
items:
- description: PVT common registers
- - description: PVT temprature sensor registers
+ - description: PVT temperature sensor registers
- description: PVT process detector registers
- description: PVT voltage monitor registers
@@ -105,7 +105,7 @@ properties:
G coefficient for temperature equation.
Default for series 5 = 60000
Default for series 6 = 57400
- multipleOf: 1000
+ multipleOf: 100
minimum: 1000
$ref: /schemas/types.yaml#/definitions/uint32
@@ -114,7 +114,7 @@ properties:
H coefficient for temperature equation.
Default for series 5 = 200000
Default for series 6 = 249400
- multipleOf: 1000
+ multipleOf: 100
minimum: 1000
$ref: /schemas/types.yaml#/definitions/uint32
@@ -131,7 +131,7 @@ properties:
J coefficient for temperature equation.
Default for series 5 = -100
Default for series 6 = 0
- multipleOf: 1000
+ multipleOf: 100
maximum: 0
$ref: /schemas/types.yaml#/definitions/int32
diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
index e1719839faf0..164068ba069d 100644
--- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
+++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/national,lm90.yaml#
@@ -20,6 +20,7 @@ properties:
- dallas,max6646
- dallas,max6647
- dallas,max6649
+ - dallas,max6654
- dallas,max6657
- dallas,max6658
- dallas,max6659
@@ -32,13 +33,18 @@ properties:
- national,lm89
- national,lm90
- national,lm99
+ - nuvoton,nct7716
+ - nuvoton,nct7717
+ - nuvoton,nct7718
- nxp,sa56004
+ - onnn,nct72
+ - onnn,nct214
+ - onnn,nct218
- onnn,nct1008
- ti,tmp451
- ti,tmp461
- winbond,w83l771
-
interrupts:
items:
- description: |
@@ -115,11 +121,14 @@ allOf:
- dallas,max6646
- dallas,max6647
- dallas,max6649
+ - dallas,max6654
- dallas,max6657
- dallas,max6658
- dallas,max6659
- dallas,max6695
- dallas,max6696
+ - nuvoton,nct7716
+ - nuvoton,nct7717
then:
patternProperties:
"^channel@([0-2])$":
@@ -134,6 +143,9 @@ allOf:
- adi,adt7461
- adi,adt7461a
- adi,adt7481
+ - onnn,nct72
+ - onnn,nct214
+ - onnn,nct218
- onnn,nct1008
then:
patternProperties:
@@ -155,6 +167,7 @@ allOf:
- national,lm89
- national,lm90
- national,lm99
+ - nuvoton,nct7718
- nxp,sa56004
- winbond,w83l771
then:
@@ -198,30 +211,30 @@ examples:
};
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sensor@4c {
- compatible = "adi,adt7481";
- reg = <0x4c>;
#address-cells = <1>;
#size-cells = <0>;
- channel@0 {
- reg = <0x0>;
- label = "local";
- };
-
- channel@1 {
- reg = <0x1>;
- label = "front";
- temperature-offset-millicelsius = <4000>;
- };
-
- channel@2 {
- reg = <0x2>;
- label = "back";
- temperature-offset-millicelsius = <750>;
+ sensor@4c {
+ compatible = "adi,adt7481";
+ reg = <0x4c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0x0>;
+ label = "local";
+ };
+
+ channel@1 {
+ reg = <0x1>;
+ label = "front";
+ temperature-offset-millicelsius = <4000>;
+ };
+
+ channel@2 {
+ reg = <0x2>;
+ label = "back";
+ temperature-offset-millicelsius = <750>;
+ };
};
- };
};
diff --git a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
index 28f43e929f6d..18095ba87a5a 100644
--- a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
@@ -1,12 +1,16 @@
-Nuvoton NPCM7xx PWM and Fan Tacho controller device
+Nuvoton NPCM PWM and Fan Tacho controller device
The Nuvoton BMC NPCM7XX supports 8 Pulse-width modulation (PWM)
controller outputs and 16 Fan tachometer controller inputs.
+The Nuvoton BMC NPCM8XX supports 12 Pulse-width modulation (PWM)
+controller outputs and 16 Fan tachometer controller inputs.
+
Required properties for pwm-fan node
- #address-cells : should be 1.
- #size-cells : should be 0.
- compatible : "nuvoton,npcm750-pwm-fan" for Poleg NPCM7XX.
+ : "nuvoton,npcm845-pwm-fan" for Arbel NPCM8XX.
- reg : specifies physical base address and size of the registers.
- reg-names : must contain:
* "pwm" for the PWM registers.
@@ -23,7 +27,7 @@ Required properties for pwm-fan node
fan subnode format:
===================
Under fan subnode can be upto 8 child nodes, each child node representing a fan.
-Each fan subnode must have one PWM channel and atleast one Fan tach channel.
+Each fan subnode must have one PWM channel and at least one Fan tach channel.
For PWM channel can be configured cooling-levels to create cooling device.
Cooling device could be bound to a thermal zone for the thermal control.
diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
index 3d3b139a91a2..dc8bc4c6df34 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
@@ -6,7 +6,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: NTC thermistor temperature sensors
maintainers:
- - Naveen Krishna Chatradhi <ch.naveen@samsung.com>
- Linus Walleij <linus.walleij@linaro.org>
description: |
@@ -76,8 +75,9 @@ properties:
- const: murata,ncp15wl333
- const: murata,ncp03wf104
- const: murata,ncp15xh103
+ - const: murata,ncp18wm474
- const: samsung,1404-001221
- # Deprecated "ntp," compatible strings
+ # Deprecated "ntc," compatible strings
- const: ntc,ncp15wb473
deprecated: true
- const: ntc,ncp18wb473
@@ -132,7 +132,7 @@ additionalProperties: false
examples:
- |
- thermistor0 {
+ thermistor {
compatible = "murata,ncp18wb473";
io-channels = <&gpadc 0x06>;
pullup-uv = <1800000>;
diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml
index 358b262431fc..244470282890 100644
--- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml
+++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/nuvoton,nct6775.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
@@ -25,6 +24,7 @@ properties:
- nuvoton,nct6796
- nuvoton,nct6797
- nuvoton,nct6798
+ - nuvoton,nct6799
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml
new file mode 100644
index 000000000000..625fcf5d3b54
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/nuvoton,nct7363.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NCT7363Y Hardware Monitoring IC
+
+maintainers:
+ - Ban Feng <kcfeng0@nuvoton.com>
+
+description: |
+ The NCT7363Y is a fan controller which provides up to 16 independent
+ FAN input monitors, and up to 16 independent PWM outputs with SMBus interface.
+
+ Datasheets: Available from Nuvoton upon request
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nct7363
+ - nuvoton,nct7362
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+patternProperties:
+ "^fan-[0-9]+$":
+ $ref: fan-common.yaml#
+ unevaluatedProperties: false
+ required:
+ - pwms
+ - tach-ch
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon: hwmon@22 {
+ compatible = "nuvoton,nct7363";
+ reg = <0x22>;
+ #pwm-cells = <2>;
+
+ fan-0 {
+ pwms = <&hwmon 0 50000>;
+ tach-ch = /bits/ 8 <0x00>;
+ };
+ fan-1 {
+ pwms = <&hwmon 1 50000>;
+ tach-ch = /bits/ 8 <0x01>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml
index 2f0620ecccc9..c16a33227e94 100644
--- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml
+++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/nuvoton,nct7802.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
@@ -123,23 +122,23 @@ examples:
#size-cells = <0>;
channel@0 { /* LTD */
- reg = <0>;
+ reg = <0>;
};
channel@1 { /* RTD1 */
- reg = <1>;
- sensor-type = "voltage";
+ reg = <1>;
+ sensor-type = "voltage";
};
channel@2 { /* RTD2 */
- reg = <2>;
- sensor-type = "temperature";
- temperature-mode = "thermal-diode";
+ reg = <2>;
+ sensor-type = "temperature";
+ temperature-mode = "thermal-diode";
};
channel@3 { /* RTD3 */
- reg = <3>;
- sensor-type = "temperature";
+ reg = <3>;
+ sensor-type = "temperature";
};
};
};
diff --git a/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
new file mode 100644
index 000000000000..48d654e52114
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nxp,mc34vr500.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/nxp,mc34vr500.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP MC34VR500 hwmon sensor
+
+maintainers:
+ - Mario Kicherer <dev@kicherer.org>
+
+properties:
+ compatible:
+ enum:
+ - nxp,mc34vr500
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "nxp,mc34vr500";
+ reg = <0x08>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml
new file mode 100644
index 000000000000..af7530093942
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,adp1050.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/adi,adp1050.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADP1050 digital controller with PMBus interface
+
+maintainers:
+ - Radu Sabau <radu.sabau@analog.com>
+
+description: |
+ The ADP1050 and similar devices are used to monitor system voltages,
+ currents, power, and temperatures.
+
+ Through the PMBus interface, the ADP1050 targets isolated power supplies
+ and has four individual monitors for input/output voltage, input current
+ and temperature.
+ Datasheet:
+ https://www.analog.com/en/products/adp1050.html
+ https://www.analog.com/en/products/adp1051.html
+ https://www.analog.com/en/products/adp1055.html
+ https://www.analog.com/en/products/ltp8800-1a.html
+ https://www.analog.com/en/products/ltp8800-2.html
+ https://www.analog.com/en/products/ltp8800-4a.html
+
+properties:
+ compatible:
+ enum:
+ - adi,adp1050
+ - adi,adp1051
+ - adi,adp1055
+ - adi,ltp8800
+
+ reg:
+ maxItems: 1
+
+ vcc-supply: true
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+
+ hwmon@70 {
+ compatible = "adi,adp1050";
+ reg = <0x70>;
+ vcc-supply = <&vcc>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml
new file mode 100644
index 000000000000..bf028a8718f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,lt3074.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/adi,lt3074.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LT3074 voltage regulator
+
+maintainers:
+ - Cedric Encarnacion <cedricjustine.encarnacion@analog.com>
+
+description: |
+ The LT3074 is a low voltage, ultra-low noise and ultra-fast transient
+ response linear regulator. It allows telemetry for input/output voltage,
+ output current and temperature through the PMBus serial interface.
+
+ Datasheet:
+ https://www.analog.com/en/products/lt3074.html
+
+allOf:
+ - $ref: /schemas/regulator/regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,lt3074
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@6d {
+ compatible = "adi,lt3074";
+ reg = <0x6d>;
+ regulator-name = "vout";
+ regulator-max-microvolt = <1250000>;
+ regulator-min-microvolt = <1150000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max17616.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max17616.yaml
new file mode 100644
index 000000000000..fa48af81e083
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max17616.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/adi,max17616.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX17616/MAX17616A Current-Limiter with PMBus Interface
+
+maintainers:
+ - Kim Seer Paller <kimseer.paller@analog.com>
+
+description: |
+ The MAX17616/MAX17616A is a 3V to 80V, 7A current-limiter with overvoltage,
+ surge, undervoltage, reverse polarity, and loss of ground protection. It allows
+ monitoring of input/output voltage, output current and temperature through the
+ PMBus serial interface.
+ Datasheet:
+ https://www.analog.com/en/products/max17616.html
+
+properties:
+ compatible:
+ const: adi,max17616
+
+ reg:
+ maxItems: 1
+
+ vcc-supply: true
+
+ interrupts:
+ description: Fault condition signal provided on SMBALERT pin.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@16 {
+ compatible = "adi,max17616";
+ reg = <0x16>;
+ vcc-supply = <&vcc>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml
new file mode 100644
index 000000000000..5c4e52b472ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,tda38640.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,tda38640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon TDA38640 Synchronous Buck Regulator with SVID and I2C
+
+maintainers:
+ - Naresh Solanki <naresh.solanki@9elements.com>
+
+description: |
+ The Infineon TDA38640 is a 40A Single-voltage Synchronous Buck
+ Regulator with SVID and I2C designed for Industrial use.
+
+ Datasheet: https://www.infineon.com/dgdl/Infineon-TDA38640-0000-DataSheet-v02_04-EN.pdf?fileId=8ac78c8c80027ecd018042f2337f00c9
+
+properties:
+ compatible:
+ enum:
+ - infineon,tda38640
+
+ reg:
+ maxItems: 1
+
+ infineon,en-pin-fixed-level:
+ description:
+ Indicates that the chip EN pin is at fixed level or left
+ unconnected(has internal pull-down).
+ type: boolean
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description:
+ list of regulators provided by this controller.
+
+ properties:
+ vout:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tda38640@40 {
+ compatible = "infineon,tda38640";
+ reg = <0x40>;
+
+ interrupt-parent = <&smb_pex_cpu0_event>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ pvnn_main_cpu0: vout {
+ regulator-name = "pvnn_main_cpu0";
+ regulator-enable-ramp-delay = <200>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
new file mode 100644
index 000000000000..ae23a05375cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/isil,isl68137.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Digital Multiphase Voltage Regulators with PMBus
+
+maintainers:
+ - Grant Peltier <grant.peltier.jg@renesas.com>
+
+description: |
+ Renesas digital multiphase voltage regulators with PMBus.
+ https://www.renesas.com/en/products/power-management/multiphase-power/multiphase-dcdc-switching-controllers
+
+properties:
+ compatible:
+ enum:
+ - isil,isl68137
+ - renesas,isl68220
+ - renesas,isl68221
+ - renesas,isl68222
+ - renesas,isl68223
+ - renesas,isl68224
+ - renesas,isl68225
+ - renesas,isl68226
+ - renesas,isl68227
+ - renesas,isl68229
+ - renesas,isl68233
+ - renesas,isl68239
+ - renesas,isl69222
+ - renesas,isl69223
+ - renesas,isl69224
+ - renesas,isl69225
+ - renesas,isl69227
+ - renesas,isl69228
+ - renesas,isl69234
+ - renesas,isl69236
+ - renesas,isl69239
+ - renesas,isl69242
+ - renesas,isl69243
+ - renesas,isl69247
+ - renesas,isl69248
+ - renesas,isl69254
+ - renesas,isl69255
+ - renesas,isl69256
+ - renesas,isl69259
+ - isil,isl69260
+ - renesas,isl69268
+ - isil,isl69269
+ - renesas,isl69298
+ - renesas,raa228000
+ - renesas,raa228004
+ - renesas,raa228006
+ - renesas,raa228228
+ - renesas,raa228244
+ - renesas,raa228246
+ - renesas,raa229001
+ - renesas,raa229004
+ - renesas,raa229621
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^channel@([0-3])$":
+ type: object
+ description:
+ Container for properties specific to a particular channel (rail).
+
+ properties:
+ reg:
+ description: The channel (rail) index.
+ items:
+ minimum: 0
+ maximum: 3
+
+ vout-voltage-divider:
+ description: |
+ Resistances of a voltage divider placed between Vout and the voltage
+ sense (Vsense) pin for the given channel (rail). It has two numbers
+ representing the resistances of the voltage divider provided as
+ <Rout Rtotal> which yields an adjusted Vout as
+ Vout_adj = Vout * Rtotal / Rout given the original Vout as reported
+ by the Vsense pin. Given a circuit configuration similar to the one
+ below, Rtotal = R1 + Rout.
+
+ Vout ----.
+ |
+ .-----.
+ | R1 |
+ '-----'
+ |
+ +---- Vsense
+ |
+ .-----.
+ | Rout|
+ '-----'
+ |
+ GND
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ isl68239@60 {
+ compatible = "isil,isl68137";
+ reg = <0x60>;
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ isl68239@60 {
+ compatible = "renesas,isl68239";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ vout-voltage-divider = <1000 2000>; // Reported Vout/Pout would be scaled by 2
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/mps,mp2975.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mp2975.yaml
new file mode 100644
index 000000000000..f7bc4f077929
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mp2975.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/mps,mp2975.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MPS MP2975 Synchronous Buck Regulator
+
+maintainers:
+ - Naresh Solanki <naresh.solanki@9elements.com>
+
+description:
+ The MPS MP2971, MP2973 & MP2975 is a multi-phase voltage regulator
+ designed for use in high-performance computing and server
+ applications. It supports I2C/PMBus for control and monitoring.
+
+properties:
+ compatible:
+ enum:
+ - mps,mp2971
+ - mps,mp2973
+ - mps,mp2975
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description:
+ List of regulators provided by this controller.
+
+ patternProperties:
+ "^vout[0-1]$":
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@58 {
+ compatible = "mps,mp2973";
+ reg = <0x58>;
+
+ interrupt-parent = <&smb_pex_cpu1_event>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ vout0 {
+ regulator-name = "pvccin_cpu1";
+ regulator-enable-ramp-delay = <200>;
+ };
+ vout1 {
+ regulator-name = "pvccfa_ehv_fivra_cpu1";
+ regulator-enable-ramp-delay = <200>;
+ };
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml
new file mode 100644
index 000000000000..90970a0433e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/mps,mpq8785.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Monolithic Power Systems Multiphase Voltage Regulators with PMBus
+
+maintainers:
+ - Charles Hsu <ythsu0511@gmail.com>
+
+description:
+ Monolithic Power Systems digital multiphase voltage regulators with PMBus.
+
+properties:
+ compatible:
+ enum:
+ - mps,mpm3695
+ - mps,mpm3695-25
+ - mps,mpm82504
+ - mps,mpq8785
+
+ reg:
+ maxItems: 1
+
+ mps,vout-fb-divider-ratio-permille:
+ description:
+ The feedback resistor divider ratio, expressed in permille
+ (Vfb / Vout * 1000). This value is written to the PMBUS_VOUT_SCALE_LOOP
+ register and is required for correct output voltage presentation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 4095
+ default: 706
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mps,mpm3695
+ - mps,mpm82504
+ then:
+ properties:
+ mps,vout-fb-divider-ratio-permille:
+ maximum: 1023
+
+ - if:
+ properties:
+ compatible:
+ const: mps,mpq8785
+ then:
+ properties:
+ mps,vout-fb-divider-ratio-permille:
+ maximum: 2047
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@30 {
+ compatible = "mps,mpm82504";
+ reg = <0x30>;
+ mps,vout-fb-divider-ratio-permille = <600>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
index da8292bc32f5..a20f140dc79a 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
@@ -34,11 +34,26 @@ properties:
Shunt (sense) resistor value in micro-Ohms
default: 1000
+ regulators:
+ type: object
+
+ properties:
+ vout:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/hwmon/hwmon-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml
new file mode 100644
index 000000000000..f4115870e450
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/ti,tps25990.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TPS25990 Stackable eFuse
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+description:
+ The TI TPS25990 is an integrated, high-current circuit
+ protection and power management device with PMBUS interface
+
+properties:
+ compatible:
+ const: ti,tps25990
+
+ reg:
+ maxItems: 1
+
+ ti,rimon-micro-ohms:
+ description:
+ micro Ohms value of the resistance installed between the Imon pin
+ and the ground reference.
+
+ interrupts:
+ description: PMBUS SMB Alert Interrupt.
+ maxItems: 1
+
+ regulators:
+ type: object
+ description:
+ list of regulators provided by this controller.
+
+ properties:
+ vout:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ gpdac1:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ gpdac2:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ti,rimon-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hw-monitor@46 {
+ compatible = "ti,tps25990";
+ reg = <0x46>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
+ ti,rimon-micro-ohms = <1370000000>;
+
+ regulators {
+ cpu0_vout: vout {
+ regulator-name = "main_cpu0";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml
index e8feee38c76c..8f9ce00079df 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml
@@ -23,11 +23,26 @@ description: |
properties:
compatible:
enum:
+ - ti,ucd9000
+ - ti,ucd9090
+ - ti,ucd90120
+ - ti,ucd90124
+ - ti,ucd90160
- ti,ucd90320
+ - ti,ucd90910
reg:
maxItems: 1
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 84
+ maxItems: 84
+
+ '#gpio-cells':
+ const: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/vicor,pli1209bc.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/vicor,pli1209bc.yaml
new file mode 100644
index 000000000000..4aa62d67e1a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/vicor,pli1209bc.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/vicor,pli1209bc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Vicor PLI1209BC Power Regulator
+
+maintainers:
+ - Marcello Sylvester Bauer <sylv@sylv.io>
+ - Naresh Solanki <naresh.solanki@9elements.com>
+
+description:
+ The Vicor PLI1209BC is a Digital Supervisor with Isolation for use
+ with BCM Bus Converter Modules.
+
+properties:
+ compatible:
+ enum:
+ - vicor,pli1209bc
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description:
+ List of regulators provided by this controller.
+
+ properties:
+ vout2:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@5f {
+ compatible = "vicor,pli1209bc";
+ reg = <0x5f>;
+
+ regulators {
+ p12v_d: vout2 {
+ regulator-name = "bcm3";
+ regulator-boot-on;
+ };
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
deleted file mode 100644
index 4509e688623a..000000000000
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-Bindings for a fan connected to the PWM lines
-
-Required properties:
-- compatible : "pwm-fan"
-- pwms : the PWM that is used to control the PWM fan
-- cooling-levels : PWM duty cycle values in a range from 0 to 255
- which correspond to thermal cooling states
-
-Optional properties:
-- fan-supply : phandle to the regulator that provides power to the fan
-- interrupts : This contains an interrupt specifier for each fan
- tachometer output connected to an interrupt source.
- The output signal must generate a defined number of
- interrupts per fan revolution, which require that
- it must be self resetting edge interrupts. See
- interrupt-controller/interrupts.txt for the format.
-- pulses-per-revolution : define the number of pulses per fan revolution for
- each tachometer input as an integer (default is 2
- interrupts per revolution). The value must be
- greater than zero.
-
-Example:
- fan0: pwm-fan {
- compatible = "pwm-fan";
- #cooling-cells = <2>;
- pwms = <&pwm 0 10000 0>;
- cooling-levels = <0 102 170 230>;
- };
-
- thermal-zones {
- cpu_thermal: cpu-thermal {
- thermal-sensors = <&tmu 0>;
- polling-delay-passive = <0>;
- polling-delay = <0>;
- trips {
- cpu_alert1: cpu-alert1 {
- temperature = <100000>; /* millicelsius */
- hysteresis = <2000>; /* millicelsius */
- type = "passive";
- };
- };
- cooling-maps {
- map0 {
- trip = <&cpu_alert1>;
- cooling-device = <&fan0 0 1>;
- };
- };
- };
-
-Example 2:
- fan0: pwm-fan {
- compatible = "pwm-fan";
- pwms = <&pwm 0 40000 0>;
- fan-supply = <&reg_fan>;
- interrupt-parent = <&gpio5>;
- interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
- pulses-per-revolution = <2>;
- };
-
-Example 3:
- fan0: pwm-fan {
- compatible = "pwm-fan";
- pwms = <&pwm1 0 25000 0>;
- interrupts-extended = <&gpio1 1 IRQ_TYPE_EDGE_FALLING>,
- <&gpio2 5 IRQ_TYPE_EDGE_FALLING>;
- pulses-per-revolution = <2>, <1>;
- };
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml b/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml
new file mode 100644
index 000000000000..a84cc3a4cfdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fan connected to PWM lines
+
+maintainers:
+ - Jean Delvare <jdelvare@suse.com>
+ - Guenter Roeck <linux@roeck-us.net>
+
+properties:
+ compatible:
+ const: pwm-fan
+
+ cooling-levels:
+ description: PWM duty cycle values corresponding to thermal cooling states.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ maximum: 255
+
+ fan-supply:
+ description: Phandle to the regulator that provides power to the fan.
+
+ interrupts:
+ description:
+ This contains an interrupt specifier for each fan tachometer output
+ connected to an interrupt source. The output signal must generate a
+ defined number of interrupts per fan revolution, which require that
+ it must be self resetting edge interrupts.
+ maxItems: 1
+
+ fan-shutdown-percent:
+ description:
+ Fan RPM in percent set during shutdown. This is used to keep the fan
+ running at fixed RPM after the kernel shut down, which is useful on
+ hardware that does keep heating itself even after the kernel did shut
+ down, for example from some sort of management core.
+ minimum: 0
+ maximum: 100
+
+ fan-stop-to-start-percent:
+ description:
+ Minimum fan RPM in percent to start when stopped.
+ minimum: 0
+ maximum: 100
+
+ fan-stop-to-start-us:
+ description:
+ Time to wait in microseconds after start when stopped.
+
+ pulses-per-revolution:
+ description:
+ Define the number of pulses per fan revolution for each tachometer
+ input as an integer.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 4
+ default: 2
+
+ pwms:
+ description: The PWM that is used to control the fan.
+ maxItems: 1
+
+ "#cooling-cells": true
+
+required:
+ - compatible
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 102 170 230>;
+ pwms = <&pwm 0 10000 0>;
+ #cooling-cells = <2>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ thermal-sensors = <&tmu 0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = <100000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&fan0 0 1>;
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pwm-fan {
+ compatible = "pwm-fan";
+ pwms = <&pwm 0 40000 0>;
+ fan-supply = <&reg_fan>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ pulses-per-revolution = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/renesas,isl28022.yaml b/Documentation/devicetree/bindings/hwmon/renesas,isl28022.yaml
new file mode 100644
index 000000000000..dd82a80e4115
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/renesas,isl28022.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/renesas,isl28022.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas ISL28022 power monitor
+
+maintainers:
+ - Carsten Spieß <mail@carsten-spiess.de>
+
+description: |
+ The ISL28022 is a power monitor with I2C interface. The device monitors
+ voltage, current via shunt resistor and calculated power.
+
+ Datasheets:
+ https://www.renesas.com/us/en/www/doc/datasheet/isl28022.pdf
+
+properties:
+ compatible:
+ const: renesas,isl28022
+
+ reg:
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description:
+ Shunt resistor value in micro-Ohm
+ minimum: 800
+ default: 10000
+
+ renesas,shunt-range-microvolt:
+ description:
+ Maximal shunt voltage range of +/- 40 mV, 80 mV, 160 mV or 320 mV
+ default: 320000
+ enum: [40000, 80000, 160000, 320000]
+
+ renesas,average-samples:
+ description:
+ Number of samples to be used to report voltage, current and power values.
+ default: 1
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4, 8, 16, 32, 64, 128]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-monitor@40 {
+ compatible = "renesas,isl28022";
+ reg = <0x40>;
+ shunt-resistor-micro-ohms = <8000>;
+ renesas,shunt-range-microvolt = <40000>;
+ renesas,average-samples = <128>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml
index 80df7182ea28..14ac783c9a5f 100644
--- a/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,sht15.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/sensirion,sht15.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
index 159238efa9ed..3d14d5fc96c5 100644
--- a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -13,7 +13,7 @@ description: |
The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensors
designed especially for battery-driven high-volume consumer electronics
applications.
- For further information refere to Documentation/hwmon/shtc1.rst
+ For further information refer to Documentation/hwmon/shtc1.rst
This binding document describes the binding for the hardware monitor
portion of the driver.
diff --git a/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml b/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml
new file mode 100644
index 000000000000..b76805d39427
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/sophgo,sg2042-hwmon-mcu.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/sophgo,sg2042-hwmon-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 onboard MCU support
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: sophgo,sg2044-hwmon-mcu
+ - const: sophgo,sg2042-hwmon-mcu
+ - const: sophgo,sg2042-hwmon-mcu
+
+ reg:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#thermal-sensor-cells"
+
+allOf:
+ - $ref: /schemas/thermal/thermal-sensor.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@17 {
+ compatible = "sophgo,sg2042-hwmon-mcu";
+ reg = <0x17>;
+ #thermal-sensor-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/st,stts751.yaml b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
new file mode 100644
index 000000000000..9c825adbed58
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/st,stts751.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/st,stts751.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STTS751 Thermometer
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+properties:
+ compatible:
+ const: st,stts751
+
+ reg:
+ maxItems: 1
+
+ smbus-timeout-disable:
+ description:
+ When set, the smbus timeout function will be disabled.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ thermometer@48 {
+ compatible = "st,stts751";
+ reg = <0x48>;
+ smbus-timeout-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml b/Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml
new file mode 100644
index 000000000000..aaf244790663
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/st,tsc1641.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST Microelectronics TSC1641 I2C power monitor
+
+maintainers:
+ - Igor Reznichenko <igor@reznichenko.net>
+
+description: |
+ TSC1641 is a 60 V, 16-bit high-precision power monitor with I2C and
+ MIPI I3C interface
+
+ Datasheets:
+ https://www.st.com/resource/en/datasheet/tsc1641.pdf
+
+properties:
+ compatible:
+ const: st,tsc1641
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Optional alert interrupt.
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description: Shunt resistor value in micro-ohms. Since device has internal
+ 16-bit RSHUNT register with 10 uOhm LSB, the maximum value is capped at
+ 655.35 mOhm.
+ minimum: 100
+ default: 1000
+ maximum: 655350
+
+ st,alert-polarity-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Default value is 0 which configures the normal polarity of the
+ ALERT pin, being active low open-drain. Setting this to 1 configures the
+ polarity of the ALERT pin to be inverted and active high open-drain.
+ Specify this property to set the alert polarity to active-high.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-sensor@40 {
+ compatible = "st,tsc1641";
+ reg = <0x40>;
+ shunt-resistor-micro-ohms = <1000>;
+ st,alert-polarity-active-high;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml
new file mode 100644
index 000000000000..733cba780186
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/starfive,jh71x0-temp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH71x0 Temperature Sensor
+
+maintainers:
+ - Emil Renner Berthing <kernel@esmil.dk>
+
+description: |
+ StarFive Technology Co. JH71x0 embedded temperature sensor
+
+properties:
+ compatible:
+ enum:
+ - starfive,jh7100-temp
+ - starfive,jh7110-temp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: sense
+ - const: bus
+
+ '#thermal-sensor-cells':
+ const: 0
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: sense
+ - const: bus
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive-jh7100.h>
+ #include <dt-bindings/reset/starfive-jh7100.h>
+
+ temperature-sensor@124a0000 {
+ compatible = "starfive,jh7100-temp";
+ reg = <0x124a0000 0x10000>;
+ clocks = <&clkgen JH7100_CLK_TEMP_SENSE>,
+ <&clkgen JH7100_CLK_TEMP_APB>;
+ clock-names = "sense", "bus";
+ #thermal-sensor-cells = <0>;
+ resets = <&rstgen JH7100_RSTN_TEMP_SENSE>,
+ <&rstgen JH7100_RSTN_TEMP_APB>;
+ reset-names = "sense", "bus";
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/stts751.txt b/Documentation/devicetree/bindings/hwmon/stts751.txt
deleted file mode 100644
index 3ee1dc30e72f..000000000000
--- a/Documentation/devicetree/bindings/hwmon/stts751.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* STTS751 thermometer.
-
-Required node properties:
-- compatible: "stts751"
-- reg: I2C bus address of the device
-
-Optional properties:
-- smbus-timeout-disable: when set, the smbus timeout function will be disabled
-
-Example stts751 node:
-
-temp-sensor {
- compatible = "stts751";
- reg = <0x48>;
-}
diff --git a/Documentation/devicetree/bindings/hwmon/syna,as370.yaml b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
new file mode 100644
index 000000000000..1f7005f55247
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/syna,as370.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/syna,as370.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics AS370 PVT sensors
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+properties:
+ compatible:
+ const: syna,as370-hwmon
+
+ reg:
+ description:
+ Address and length of the register set.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ sensor@ea0810 {
+ compatible = "syna,as370-hwmon";
+ reg = <0xea0810 0xc>;
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml
new file mode 100644
index 000000000000..78e3d97e2ae5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ti,adc128d818.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ADC128D818 ADC System Monitor With Temperature Sensor
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description: |
+ The ADC128D818 is a 12-Bit, 8-Channel Analog to Digital Converter (ADC)
+ with a temperature sensor and an I2C interface.
+
+ Datasheets:
+ https://www.ti.com/product/ADC128D818
+
+properties:
+ compatible:
+ const: ti,adc128d818
+
+ reg:
+ maxItems: 1
+
+ ti,mode:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: |
+ Operation mode.
+ Mode 0 - 7 single-ended voltage readings (IN0-IN6), 1 temperature
+ reading (internal).
+ Mode 1 - 8 single-ended voltage readings (IN0-IN7), no temperature.
+ Mode 2 - 4 pseudo-differential voltage readings
+ (IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6), 1 temperature reading (internal).
+ Mode 3 - 4 single-ended voltage readings (IN0-IN3), 2 pseudo-differential
+ voltage readings (IN4-IN5, IN7-IN6), 1 temperature reading (internal).
+ default: 0
+
+ vref-supply:
+ description:
+ The regulator to use as an external reference. If it does not exist, the
+ internal reference will be used.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@1d {
+ compatible = "ti,adc128d818";
+ reg = <0x1d>;
+ vref-supply = <&vref>;
+ ti,mode = /bits/ 8 <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml
index 926be9a29044..fb80456120e1 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/ti,ads7828.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
diff --git a/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml b/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml
new file mode 100644
index 000000000000..eb00756988be
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,amc6821.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ti,amc6821.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMC6821 Intelligent Temperature Monitor and PWM Fan Controller
+
+maintainers:
+ - Farouk Bouabid <farouk.bouabid@cherry.de>
+ - Quentin Schulz <quentin.schulz@cherry.de>
+
+description:
+ Intelligent temperature monitor and pulse-width modulation (PWM) fan
+ controller.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: tsd,mule
+ - const: ti,amc6821
+ - const: ti,amc6821
+
+ reg:
+ maxItems: 1
+
+ i2c-mux:
+ type: object
+
+ fan:
+ $ref: fan-common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ cooling-levels:
+ description: PWM duty cycle values corresponding to thermal cooling states.
+ items:
+ maximum: 255
+
+ "#pwm-cells":
+ const: 2
+ description: |
+ Number of cells in a PWM specifier.
+ - cell 0: PWM period in nanoseconds
+ - cell 1: PWM polarity: 0 or PWM_POLARITY_INVERTED
+
+required:
+ - compatible
+ - reg
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: tsd,mule
+
+then:
+ required:
+ - i2c-mux
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ pwms = <&fan_controller 40000 0>;
+ };
+ };
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fan@18 {
+ compatible = "tsd,mule", "ti,amc6821";
+ reg = <0x18>;
+
+ i2c-mux {
+ compatible = "tsd,mule-i2c-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6f {
+ compatible = "isil,isl1208";
+ reg = <0x6f>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
index 47af97bb4ced..d3cde8936686 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/ti,ina2xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
@@ -20,17 +19,28 @@ description: |
properties:
compatible:
enum:
+ - silergy,sq52206
+ - silergy,sy24655
- ti,ina209
- ti,ina219
- ti,ina220
- ti,ina226
+ - ti,ina228
- ti,ina230
- ti,ina231
+ - ti,ina233
+ - ti,ina237
- ti,ina238
+ - ti,ina260
+ - ti,ina700
+ - ti,ina780
reg:
maxItems: 1
+ "#io-channel-cells":
+ const: 1
+
shunt-resistor:
description:
Shunt resistor value in micro-Ohm.
@@ -52,16 +62,97 @@ properties:
shunt voltage, and a value of 4 maps to ADCRANGE=0 such that a wider
voltage range is used.
+ For SQ52206,the shunt-gain value 1 mapps to ADCRANGE=10/11, the value 2
+ mapps to ADCRANGE=01, and the value 4 mapps to ADCRANGE=00.
+
The default value is device dependent, and is defined by the reset value
of PGA/ADCRANGE in the respective configuration registers.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2, 4, 8]
+ vs-supply:
+ description: phandle to the regulator that provides the VS supply typically
+ in range from 2.7 V to 5.5 V.
+
+ ti,alert-polarity-active-high:
+ description: Alert pin is asserted based on the value of Alert polarity Bit
+ of Mask/Enable register. Default value is Normal (0 which maps to
+ active-low open collector). The other value is Inverted
+ (1 which maps to active-high open collector). Specify this property to set
+ the alert polarity to active-high.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ ti,maximum-expected-current-microamp:
+ description: |
+ This value indicates the maximum current in microamps that you can
+ expect to measure with ina233 in your circuit.
+
+ This value will be used to calculate the Current_LSB and current/power
+ coefficient for the pmbus and to calibrate the IC.
+ minimum: 32768
+ maximum: 4294967295
+ default: 32768000
+
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: hwmon-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - silergy,sq52206
+ - silergy,sy24655
+ - ti,ina209
+ - ti,ina219
+ - ti,ina220
+ - ti,ina226
+ - ti,ina228
+ - ti,ina230
+ - ti,ina231
+ - ti,ina237
+ - ti,ina238
+ - ti,ina260
+ - ti,ina700
+ - ti,ina780
+ then:
+ properties:
+ ti,maximum-expected-current-microamp: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - silergy,sy24655
+ - ti,ina209
+ - ti,ina219
+ - ti,ina220
+ - ti,ina226
+ - ti,ina230
+ - ti,ina231
+ - ti,ina260
+ - ti,ina700
+ - ti,ina780
+ then:
+ properties:
+ ti,shunt-gain: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,ina700
+ - ti,ina780
+ then:
+ properties:
+ shunt-resistor: false
+
+unevaluatedProperties: false
examples:
- |
@@ -72,6 +163,10 @@ examples:
power-sensor@44 {
compatible = "ti,ina220";
reg = <0x44>;
+ #io-channel-cells = <1>;
+ label = "vdd_3v0";
shunt-resistor = <1000>;
+ vs-supply = <&vdd_3v0>;
+ ti,alert-polarity-active-high;
};
};
diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina3221.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina3221.yaml
new file mode 100644
index 000000000000..5f10f1207d69
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,ina3221.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ti,ina3221.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments INA3221 Current and Voltage Monitor
+
+maintainers:
+ - Jean Delvare <jdelvare@suse.com>
+ - Guenter Roeck <linux@roeck-us.net>
+
+properties:
+ compatible:
+ const: ti,ina3221
+
+ reg:
+ maxItems: 1
+
+ ti,single-shot:
+ description: |
+ This chip has two power modes: single-shot (chip takes one measurement
+ and then shuts itself down) and continuous (chip takes continuous
+ measurements). The continuous mode is more reliable and suitable for
+ hardware monitor type device, but the single-shot mode is more power-
+ friendly and useful for battery-powered device which cares power
+ consumptions while still needs some measurements occasionally.
+
+ If this property is present, the single-shot mode will be used, instead
+ of the default continuous one for monitoring.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ "#address-cells":
+ description: Required only if a child node is present.
+ const: 1
+
+ "#size-cells":
+ description: Required only if a child node is present.
+ const: 0
+
+patternProperties:
+ "^input@[0-2]$":
+ description: The node contains optional child nodes for three channels.
+ Each child node describes the information of input source. Input channels
+ default to enabled in the chip. Unless channels are explicitly disabled
+ in device-tree, input channels will be enabled.
+ type: object
+ additionalProperties: false
+ properties:
+ reg:
+ description: Must be 0, 1 and 2, corresponding to the IN1, IN2 or IN3
+ ports of the INA3221, respectively.
+ enum: [ 0, 1, 2 ]
+
+ label:
+ description: name of the input source
+
+ shunt-resistor-micro-ohms:
+ description: shunt resistor value in micro-Ohm
+
+ ti,summation-disable:
+ description: |
+ The INA3221 has a critical alert pin that can be controlled by the
+ summation control function. This function adds the single
+ shunt-voltage conversions for the desired channels in order to
+ compare the combined sum to the programmed limit. The Shunt-Voltage
+ Sum Limit register contains the programmed value that is compared
+ to the value in the Shunt-Voltage Sum register in order to
+ determine if the total summed limit is exceeded. If the
+ shunt-voltage sum limit value is exceeded, the critical alert pin
+ is asserted.
+
+ For the summation limit to have a meaningful value, it is necessary
+ to use the same shunt-resistor value on all enabled channels. If
+ this is not the case or if a channel should not be used for
+ triggering the critical alert pin, then this property can be used
+ exclude specific channels from the summation control function.
+ type: boolean
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-sensor@40 {
+ compatible = "ti,ina3221";
+ reg = <0x40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ input@0 {
+ reg = <0x0>;
+ /*
+ * Input channels are enabled by default in the device and so
+ * to disable, must be explicitly disabled in device-tree.
+ */
+ status = "disabled";
+ };
+
+ input@1 {
+ reg = <0x1>;
+ shunt-resistor-micro-ohms = <5000>;
+ };
+
+ input@2 {
+ reg = <0x2>;
+ label = "VDD_5V";
+ shunt-resistor-micro-ohms = <5000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml
new file mode 100644
index 000000000000..5c0cdc0091b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ti,lm87.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LM87 Hardware Monitor
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description: |
+ The LM87 is a serial interface system hardware monitor
+ with remote diode temperature sensing.
+
+ Datasheets:
+ https://www.ti.com/product/LM87
+
+properties:
+ compatible:
+ enum:
+ - adi,adm1024
+ - ti,lm87
+
+ reg:
+ maxItems: 1
+
+ has-temp3:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ This configures pins 18 and 19 to be used as a second
+ remote temperature sensing channel. By default the pins
+ are configured as voltage input pins in0 and in5.
+
+ has-in6:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ When set, pin 5 is configured to be used as voltage input
+ in6. Otherwise the pin is set as FAN1 input.
+
+ has-in7:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ When set, pin 6 is configured to be used as voltage input
+ in7. Otherwise the pin is set as FAN2 input.
+
+ vcc-supply:
+ description:
+ Regulator supplying power, can be configured to measure
+ 5.0V power supply. Default is 3.3V.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@2e {
+ compatible = "ti,lm87";
+ reg = <0x2e>;
+ has-temp3;
+ vcc-supply = <&reg_5v0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
index c5a889e3e27b..96b2e4969f78 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp102.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/ti,tmp102.yaml#
@@ -20,9 +20,16 @@ properties:
reg:
maxItems: 1
+ label:
+ description:
+ A descriptive name for this channel, like "ambient" or "psu".
+
"#thermal-sensor-cells":
const: 1
+ vcc-supply:
+ description: Power supply for tmp102
+
required:
- compatible
- reg
@@ -42,6 +49,8 @@ examples:
reg = <0x48>;
interrupt-parent = <&gpio7>;
interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+ label = "somelabel";
+ vcc-supply = <&supply>;
#thermal-sensor-cells = <1>;
};
};
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml
index dcbc6fbc3b48..a6f9319e068d 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp108.yaml
@@ -1,17 +1,29 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/ti,tmp108.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TMP108 temperature sensor
+title: TMP108/P3T1085(NXP) temperature sensor
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
+description: |
+ The TMP108/P3T1085(NXP) is a digital-output temperature sensor with a
+ dynamically-programmable limit window, and under- and overtemperature
+ alert functions.
+
+ P3T1085(NXP) support I3C.
+
+ Datasheets:
+ https://www.ti.com/product/TMP108
+ https://www.nxp.com/docs/en/data-sheet/P3T1085UK.pdf
+
properties:
compatible:
enum:
+ - nxp,p3t1085
- ti,tmp108
interrupts:
@@ -24,6 +36,9 @@ properties:
"#thermal-sensor-cells":
const: 0
+ vcc-supply:
+ description: phandle to the regulator that provides the V+ supply
+
required:
- compatible
- reg
@@ -45,6 +60,7 @@ examples:
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&tmp_alrt>;
+ vcc-supply = <&supply>;
#thermal-sensor-cells = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml
index e7493e25a7d2..f9c00cbb2806 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: TMP464 and TMP468 temperature sensors
maintainers:
- - Agathe Porte <agathe.porte@nokia.com>
+ - Guenter Roeck <linux@roeck-us.net>
description: |
±0.0625°C Remote and Local temperature sensor
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
index 1502b22c77cc..0fe6ea190f60 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/ti,tmp513.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
@@ -21,7 +20,6 @@ description: |
https://www.ti.com/lit/gpn/tmp513
https://www.ti.com/lit/gpn/tmp512
-
properties:
compatible:
enum:
@@ -33,7 +31,7 @@ properties:
shunt-resistor-micro-ohms:
description: |
- If 0, the calibration process will be skiped and the current and power
+ If 0, the calibration process will be skipped and the current and power
measurement engine will not work. Temperature and voltage measurement
will continue to work. The shunt value also need to respect:
rshunt <= pga-gain * 40 * 1000 * 1000.
@@ -72,20 +70,23 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: hwmon-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- tmp513@5c {
- compatible = "ti,tmp513";
- reg = <0x5C>;
- shunt-resistor-micro-ohms = <330000>;
- ti,bus-range-microvolt = <32000000>;
- ti,pga-gain = <8>;
- ti,nfactor = <0x1 0xF3 0x00>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tmp513@5c {
+ compatible = "ti,tmp513";
+ reg = <0x5c>;
+ shunt-resistor-micro-ohms = <330000>;
+ ti,bus-range-microvolt = <32000000>;
+ ti,pga-gain = <8>;
+ ti,nfactor = <0x1 0xf3 0x00>;
+ };
};
diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
index 3bc8e73dfbf0..d57e4bf8f65f 100644
--- a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
+++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/ti,tps23861.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
@@ -16,7 +15,6 @@ description: |
Datasheets:
https://www.ti.com/lit/gpn/tps23861
-
properties:
compatible:
enum:
@@ -26,7 +24,7 @@ properties:
maxItems: 1
shunt-resistor-micro-ohms:
- description: The value of curent sense resistor in microohms.
+ description: The value of current sense resistor in microohms.
default: 255000
minimum: 250000
maximum: 255000
@@ -35,17 +33,20 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: hwmon-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- tps23861@30 {
- compatible = "ti,tps23861";
- reg = <0x30>;
- shunt-resistor-micro-ohms = <255000>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tps23861@30 {
+ compatible = "ti,tps23861";
+ reg = <0x30>;
+ shunt-resistor-micro-ohms = <255000>;
+ };
};
diff --git a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml
index 31ce77a4b087..6971ecb314eb 100644
--- a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml
+++ b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/hwmon/winbond,w83781d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
diff --git a/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml b/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
index 1b03810d4b4d..5a799246a373 100644
--- a/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
+++ b/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/allwinner,sun6i-a31-p2wi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 P2WI (Push/Pull 2 Wires Interface) Device Tree Bindings
+title: Allwinner A31 P2WI (Push/Pull 2 Wires Interface)
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index 199a354ccb97..c4cc8af18280 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/i2c/amlogic,meson6-i2c.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/i2c/amlogic,meson6-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson I2C Controller
@@ -30,6 +30,9 @@ properties:
clocks:
minItems: 1
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/apm,xgene-slimpro-i2c.yaml b/Documentation/devicetree/bindings/i2c/apm,xgene-slimpro-i2c.yaml
new file mode 100644
index 000000000000..9460c64071f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/apm,xgene-slimpro-i2c.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/apm,xgene-slimpro-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SLIMpro Mailbox I2C
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+description:
+ An I2C controller accessed over the "SLIMpro" mailbox.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: apm,xgene-slimpro-i2c
+
+ mboxes:
+ maxItems: 1
+
+required:
+ - compatible
+ - mboxes
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ compatible = "apm,xgene-slimpro-i2c";
+ mboxes = <&mailbox 0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml
index 4ac61fec90e2..500a965bdb7a 100644
--- a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/i2c/apple,i2c.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/i2c/apple,i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple/PASemi I2C controller
@@ -20,11 +20,22 @@ allOf:
properties:
compatible:
- items:
- - enum:
- - apple,t8103-i2c
- - apple,t6000-i2c
- - const: apple,i2c
+ oneOf:
+ - items:
+ - const: apple,t6020-i2c
+ - const: apple,t8103-i2c
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,s5l8960x-i2c
+ - apple,t7000-i2c
+ - apple,s8000-i2c
+ - apple,t8010-i2c
+ - apple,t8015-i2c
+ - apple,t8103-i2c
+ - apple,t8112-i2c
+ - apple,t6000-i2c
+ - const: apple,i2c
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
index f597f73ccd87..5b9bd2feda3b 100644
--- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/aspeed,i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ASPEED I2C on the AST24XX, AST25XX, and AST26XX SoCs Device Tree Bindings
+title: ASPEED I2C on the AST24XX, AST25XX, and AST26XX SoCs
maintainers:
- Rayn Chen <rayn_chen@aspeedtech.com>
@@ -44,11 +44,6 @@ properties:
description: frequency of the bus clock in Hz defaults to 100 kHz when not
specified
- multi-master:
- type: boolean
- description:
- states that there is another master active on this bus
-
required:
- reg
- compatible
@@ -60,7 +55,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/aspeed-clock.h>
- i2c0: i2c-bus@40 {
+ i2c@40 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2500-i2c-bus";
diff --git a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml
index ea2303c0e143..e61cdb5b16ef 100644
--- a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml
@@ -25,7 +25,10 @@ properties:
- atmel,sama5d2-i2c
- microchip,sam9x60-i2c
- items:
- - const: microchip,sama7g5-i2c
+ - enum:
+ - microchip,sama7d65-i2c
+ - microchip,sama7g5-i2c
+ - microchip,sam9x7-i2c
- const: microchip,sam9x60-i2c
reg:
@@ -34,12 +37,6 @@ properties:
interrupts:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
clocks:
maxItems: 1
@@ -70,12 +67,10 @@ required:
- compatible
- reg
- interrupts
- - "#address-cells"
- - "#size-cells"
- clocks
allOf:
- - $ref: "i2c-controller.yaml"
+ - $ref: /schemas/i2c/i2c-controller.yaml#
- if:
properties:
compatible:
@@ -84,6 +79,7 @@ allOf:
- atmel,sama5d4-i2c
- atmel,sama5d2-i2c
- microchip,sam9x60-i2c
+ - microchip,sama7d65-i2c
- microchip,sama7g5-i2c
then:
properties:
diff --git a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml
index 7070c04469ed..ac9ddf228c82 100644
--- a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml
@@ -76,21 +76,21 @@ else:
examples:
- |
- bsca: i2c@f0406200 {
- clock-frequency = <390000>;
- compatible = "brcm,brcmstb-i2c";
- interrupt-parent = <&irq0_intc>;
- reg = <0xf0406200 0x58>;
- interrupts = <0x18>;
- interrupt-names = "upg_bsca";
- };
+ bsca: i2c@f0406200 {
+ compatible = "brcm,brcmstb-i2c";
+ reg = <0xf0406200 0x58>;
+ clock-frequency = <390000>;
+ interrupt-parent = <&irq0_intc>;
+ interrupts = <0x18>;
+ interrupt-names = "upg_bsca";
+ };
- |
- ddc0: i2c@7ef04500 {
- compatible = "brcm,bcm2711-hdmi-i2c";
- reg = <0x7ef04500 0x100>, <0x7ef00b00 0x300>;
- reg-names = "bsc", "auto-i2c";
- clock-frequency = <390000>;
- };
+ ddc0: i2c@7ef04500 {
+ compatible = "brcm,bcm2711-hdmi-i2c";
+ reg = <0x7ef04500 0x100>, <0x7ef00b00 0x300>;
+ reg-names = "bsc", "auto-i2c";
+ clock-frequency = <390000>;
+ };
...
diff --git a/Documentation/devicetree/bindings/i2c/brcm,kona-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,kona-i2c.txt
deleted file mode 100644
index 1b87b741fa8e..000000000000
--- a/Documentation/devicetree/bindings/i2c/brcm,kona-i2c.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Broadcom Kona Family I2C
-=========================
-
-This I2C controller is used in the following Broadcom SoCs:
-
- BCM11130
- BCM11140
- BCM11351
- BCM28145
- BCM28155
-
-Required Properties
--------------------
-- compatible: "brcm,bcm11351-i2c", "brcm,kona-i2c"
-- reg: Physical base address and length of controller registers
-- interrupts: The interrupt number used by the controller
-- clocks: clock specifier for the kona i2c external clock
-- clock-frequency: The I2C bus frequency in Hz
-- #address-cells: Should be <1>
-- #size-cells: Should be <0>
-
-Refer to clocks/clock-bindings.txt for generic clock consumer
-properties.
-
-Example:
-
-i2c@3e016000 {
- compatible = "brcm,bcm11351-i2c","brcm,kona-i2c";
- reg = <0x3e016000 0x80>;
- interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&bsc1_clk>;
- clock-frequency = <400000>;
- #address-cells = <1>;
- #size-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/brcm,kona-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,kona-i2c.yaml
new file mode 100644
index 000000000000..7a694af90fc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,kona-i2c.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/brcm,kona-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family I2C controller
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm11351-i2c
+ - brcm,bcm21664-i2c
+ - brcm,bcm23550-i2c
+ - const: brcm,kona-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ enum: [ 100000, 400000, 1000000, 3400000 ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-frequency
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c@3e016000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e016000 0x80>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bsc1_clk>;
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
index 1ca1cd19bd1d..9f1d35ce1fe8 100644
--- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
+++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
@@ -1,13 +1,13 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/i2c/cdns,i2c-r1p10.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/i2c/cdns,i2c-r1p10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence I2C controller Device Tree Bindings
+title: Cadence I2C controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
@@ -24,6 +24,9 @@ properties:
clocks:
minItems: 1
+ resets:
+ maxItems: 1
+
interrupts:
maxItems: 1
@@ -38,6 +41,16 @@ properties:
description: |
Input clock name.
+ fifo-depth:
+ description:
+ Size of the data FIFO in bytes.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 16
+ enum: [2, 4, 8, 16, 32, 64, 128, 256]
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -52,9 +65,11 @@ examples:
i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
clocks = <&clkc 38>;
+ resets = <&rstc 288>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
reg = <0xe0004000 0x1000>;
clock-frequency = <400000>;
#address-cells = <1>;
#size-cells = <0>;
+ fifo-depth = <8>;
};
diff --git a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
index 6e1c70e9275e..580003cdfff5 100644
--- a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
+++ b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
@@ -21,7 +21,7 @@ description: |
google,cros-ec-spi or google,cros-ec-i2c.
allOf:
- - $ref: i2c-controller.yaml#
+ - $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
@@ -39,7 +39,7 @@ unevaluatedProperties: false
examples:
- |
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -47,6 +47,7 @@ examples:
compatible = "google,cros-ec-spi";
reg = <0>;
spi-max-frequency = <5000000>;
+ interrupts = <99 0>;
i2c-tunnel {
compatible = "google,cros-ec-i2c-tunnel";
diff --git a/Documentation/devicetree/bindings/i2c/hisilicon,ascend910-i2c.yaml b/Documentation/devicetree/bindings/i2c/hisilicon,ascend910-i2c.yaml
new file mode 100644
index 000000000000..7d7a8de7bcd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/hisilicon,ascend910-i2c.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/hisilicon,ascend910-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon common I2C controller
+
+maintainers:
+ - Yicong Yang <yangyicong@hisilicon.com>
+
+description:
+ The HiSilicon common I2C controller can be used for many different
+ types of SoC such as Huawei Ascend AI series chips.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: hisilicon,ascend910-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ default: 400000
+
+ i2c-sda-falling-time-ns:
+ default: 343
+
+ i2c-scl-falling-time-ns:
+ default: 203
+
+ i2c-sda-hold-time-ns:
+ default: 830
+
+ i2c-scl-rising-time-ns:
+ default: 365
+
+ i2c-digital-filter-width-ns:
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c@38b0000 {
+ compatible = "hisilicon,ascend910-i2c";
+ reg = <0x38b0000 0x10000>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+ i2c-sda-falling-time-ns = <56>;
+ i2c-scl-falling-time-ns = <56>;
+ i2c-sda-hold-time-ns = <56>;
+ i2c-scl-rising-time-ns = <56>;
+ i2c-digital-filter;
+ i2c-digital-filter-width-ns = <0x0>;
+ clocks = <&alg_clk>;
+ clock-frequency = <400000>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/hisilicon,hix5hd2-i2c.yaml b/Documentation/devicetree/bindings/i2c/hisilicon,hix5hd2-i2c.yaml
new file mode 100644
index 000000000000..3faa7954e411
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/hisilicon,hix5hd2-i2c.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/hisilicon,hix5hd2-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: I2C for HiSilicon hix5hd2 chipset platform
+
+maintainers:
+ - Wei Yan <sledge.yanwei@huawei.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,hix5hd2-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ description: Desired I2C bus frequency in Hz
+ default: 100000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/hix5hd2-clock.h>
+
+ i2c@f8b10000 {
+ compatible = "hisilicon,hix5hd2-i2c";
+ reg = <0xf8b10000 0x1000>;
+ interrupts = <0 38 4>;
+ clocks = <&clock HIX5HD2_I2C0_RST>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml b/Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml
new file mode 100644
index 000000000000..6604dcd47251
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/hpe,gxp-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE GXP SoC I2C Controller
+
+maintainers:
+ - Nick Hawkins <nick.hawkins@hpe.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: hpe,gxp-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ default: 100000
+
+ hpe,sysreg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the global status and enable interrupt registers shared
+ between each I2C engine controller instance. It enables the I2C
+ engine controller to act as both a master or slave by being able to
+ arm and respond to interrupts from its engine. Each bit in the
+ registers represent the respective bit position.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@2600 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0x2500 0x70>;
+ interrupts = <9>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hpe,sysreg = <&sysreg_system_controller>;
+ clock-frequency = <10000>;
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
deleted file mode 100644
index 548a73cde796..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
-=================================================================
-This uses GPIO lines and a challenge & response mechanism to arbitrate who is
-the master of an I2C bus in a multimaster situation.
-
-In many cases using GPIOs to arbitrate is not needed and a design can use
-the standard I2C multi-master rules. Using GPIOs is generally useful in
-the case where there is a device on the bus that has errata and/or bugs
-that makes standard multimaster mode not feasible.
-
-Note that this scheme works well enough but has some downsides:
-* It is nonstandard (not using standard I2C multimaster)
-* Having two masters on a bus in general makes it relatively hard to debug
- problems (hard to tell if i2c issues were caused by one master, another, or
- some device on the bus).
-
-
-Algorithm:
-
-All masters on the bus have a 'bus claim' line which is an output that the
-others can see. These are all active low with pull-ups enabled. We'll
-describe these lines as:
-
-- OUR_CLAIM: output from us signaling to other hosts that we want the bus
-- THEIR_CLAIMS: output from others signaling that they want the bus
-
-The basic algorithm is to assert your line when you want the bus, then make
-sure that the other side doesn't want it also. A detailed explanation is best
-done with an example.
-
-Let's say we want to claim the bus. We:
-1. Assert OUR_CLAIM.
-2. Waits a little bit for the other sides to notice (slew time, say 10
- microseconds).
-3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are
- done.
-4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
-5. If not, back off, release the claim and wait for a few more milliseconds.
-6. Go back to 1 (until retry time has expired).
-
-
-Required properties:
-- compatible: i2c-arb-gpio-challenge
-- our-claim-gpio: The GPIO that we use to claim the bus.
-- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
- Note that some implementations may only support a single other master.
-- I2C arbitration bus node. See i2c-arb.txt in this directory.
-
-Optional properties:
-- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
-- wait-retry-us: we'll attempt another claim after this many microseconds.
- Default is 3000 us.
-- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
-
-
-Example:
- i2c@12ca0000 {
- compatible = "acme,some-i2c-device";
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
- i2c-arbitrator {
- compatible = "i2c-arb-gpio-challenge";
-
- i2c-parent = <&{/i2c@12CA0000}>;
-
- our-claim-gpio = <&gpf0 3 1>;
- their-claim-gpios = <&gpe0 4 1>;
- slew-delay-us = <10>;
- wait-retry-us = <3000>;
- wait-free-us = <50000>;
-
- i2c-arb {
- #address-cells = <1>;
- #size-cells = <0>;
-
- i2c@52 {
- // Normal I2C device
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml
new file mode 100644
index 000000000000..b618b5a3433a
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-arb-gpio-challenge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+
+maintainers:
+ - Doug Anderson <dianders@chromium.org>
+ - Peter Rosin <peda@axentia.se>
+
+description: |
+ This uses GPIO lines and a challenge & response mechanism to arbitrate who is
+ the master of an I2C bus in a multimaster situation.
+
+ In many cases using GPIOs to arbitrate is not needed and a design can use the
+ standard I2C multi-master rules. Using GPIOs is generally useful in the case
+ where there is a device on the bus that has errata and/or bugs that makes
+ standard multimaster mode not feasible.
+
+ Note that this scheme works well enough but has some downsides:
+ * It is nonstandard (not using standard I2C multimaster)
+ * Having two masters on a bus in general makes it relatively hard to debug
+ problems (hard to tell if i2c issues were caused by one master, another,
+ or some device on the bus).
+
+ Algorithm:
+ All masters on the bus have a 'bus claim' line which is an output that the
+ others can see. These are all active low with pull-ups enabled. We'll
+ describe these lines as:
+ * OUR_CLAIM: output from us signaling to other hosts that we want the bus
+ * THEIR_CLAIMS: output from others signaling that they want the bus
+
+ The basic algorithm is to assert your line when you want the bus, then make
+ sure that the other side doesn't want it also. A detailed explanation is
+ best done with an example.
+
+ Let's say we want to claim the bus. We:
+ 1. Assert OUR_CLAIM.
+ 2. Waits a little bit for the other sides to notice (slew time, say 10
+ microseconds).
+ 3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we
+ are done.
+ 4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+ 5. If not, back off, release the claim and wait for a few more milliseconds.
+ 6. Go back to 1 (until retry time has expired).
+
+properties:
+ compatible:
+ const: i2c-arb-gpio-challenge
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The I2C bus that this multiplexer's master-side port is connected to.
+
+ our-claim-gpios:
+ maxItems: 1
+ description:
+ The GPIO that we use to claim the bus.
+
+ slew-delay-us:
+ default: 10
+ description:
+ Time to wait for a GPIO to go high.
+
+ their-claim-gpios:
+ minItems: 1
+ maxItems: 8
+ description:
+ The GPIOs that the other sides use to claim the bus. Note that some
+ implementations may only support a single other master.
+
+ wait-free-us:
+ default: 50000
+ description:
+ We'll give up after this many microseconds.
+
+ wait-retry-us:
+ default: 3000
+ description:
+ We'll attempt another claim after this many microseconds.
+
+ i2c-arb:
+ type: object
+ $ref: /schemas/i2c/i2c-controller.yaml
+ unevaluatedProperties: false
+ description:
+ I2C arbitration bus node.
+
+required:
+ - compatible
+ - i2c-arb
+ - our-claim-gpios
+ - their-claim-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c-arbitrator {
+ compatible = "i2c-arb-gpio-challenge";
+ i2c-parent = <&i2c_4>;
+
+ our-claim-gpios = <&gpf0 3 GPIO_ACTIVE_LOW>;
+ their-claim-gpios = <&gpe0 4 GPIO_ACTIVE_LOW>;
+ slew-delay-us = <10>;
+ wait-retry-us = <3000>;
+ wait-free-us = <50000>;
+
+ i2c-arb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sbs-battery@b {
+ compatible = "sbs,sbs-battery";
+ reg = <0xb>;
+ sbs,poll-retry-count = <1>;
+ };
+
+ embedded-controller@1e {
+ compatible = "google,cros-ec-i2c";
+ reg = <0x1e>;
+ interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gpx1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ec_irq>;
+ wakeup-source;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb.txt b/Documentation/devicetree/bindings/i2c/i2c-arb.txt
deleted file mode 100644
index 59abf9277bdc..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-arb.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Common i2c arbitration bus properties.
-
-- i2c-arb child node
-
-Required properties for the i2c-arb child node:
-- #address-cells = <1>;
-- #size-cells = <0>;
-
-Optional properties for i2c-arb child node:
-- Child nodes conforming to i2c bus binding
-
-
-Example :
-
- /*
- An NXP pca9541 I2C bus master selector at address 0x74
- with a NXP pca8574 GPIO expander attached.
- */
-
- arb@74 {
- compatible = "nxp,pca9541";
- reg = <0x74>;
-
- i2c-arb {
- #address-cells = <1>;
- #size-cells = <0>;
-
- gpio@38 {
- compatible = "nxp,pca8574";
- reg = <0x38>;
- #gpio-cells = <2>;
- gpio-controller;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-atr.yaml b/Documentation/devicetree/bindings/i2c/i2c-atr.yaml
new file mode 100644
index 000000000000..1939ab339bfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-atr.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-atr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common i2c address translator properties
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ An I2C Address Translator (ATR) is a device with an I2C slave parent
+ ("upstream") port and N I2C master child ("downstream") ports, and
+ forwards transactions from upstream to the appropriate downstream port
+ with a modified slave address. The address used on the parent bus is
+ called the "alias" and is (potentially) different from the physical
+ slave address of the child bus. Address translation is done by the
+ hardware.
+
+properties:
+ i2c-alias-pool:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ I2C alias pool is a pool of I2C addresses on the main I2C bus that can be
+ used to access the remote peripherals on the serializer's I2C bus. The
+ addresses must be available, not used by any other peripheral. Each
+ remote peripheral is assigned an alias from the pool, and transactions to
+ that address will be forwarded to the remote peripheral, with the address
+ translated to the remote peripheral's real address. This property is not
+ needed if there are no I2C addressable remote peripherals.
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
deleted file mode 100644
index 86b2e433a969..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
+++ /dev/null
@@ -1,135 +0,0 @@
-Pinctrl-based I2C Bus DeMux
-
-This binding describes an I2C bus demultiplexer that uses pin multiplexing to
-route the I2C signals, and represents the pin multiplexing configuration using
-the pinctrl device tree bindings. This may be used to select one I2C IP core at
-runtime which may have a better feature set for a given task than another I2C
-IP core on the SoC. The most simple example is to fall back to GPIO bitbanging
-if your current runtime configuration hits an errata of the internal IP core.
-
- +-------------------------------+
- | SoC |
- | | +-----+ +-----+
- | +------------+ | | dev | | dev |
- | |I2C IP Core1|--\ | +-----+ +-----+
- | +------------+ \-------+ | | |
- | |Pinctrl|--|------+--------+
- | +------------+ +-------+ |
- | |I2C IP Core2|--/ |
- | +------------+ |
- | |
- +-------------------------------+
-
-Required properties:
-- compatible: "i2c-demux-pinctrl"
-- i2c-parent: List of phandles of I2C masters available for selection. The first
- one will be used as default.
-- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
- parents.
-
-Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this
-directory.
-
-Example:
-
-Here is a snipplet for a bus to be demuxed. It contains various i2c clients for
-HDMI, so the bus is named "i2c-hdmi":
-
- i2chdmi: i2c@8 {
-
- compatible = "i2c-demux-pinctrl";
- i2c-parent = <&gpioi2c>, <&iic2>, <&i2c2>;
- i2c-bus-name = "i2c-hdmi";
- #address-cells = <1>;
- #size-cells = <0>;
-
- ak4643: sound-codec@12 {
- compatible = "asahi-kasei,ak4643";
-
- #sound-dai-cells = <0>;
- reg = <0x12>;
- };
-
- composite-in@20 {
- compatible = "adi,adv7180";
- reg = <0x20>;
- remote = <&vin1>;
-
- port {
- adv7180: endpoint {
- bus-width = <8>;
- remote-endpoint = <&vin1ep0>;
- };
- };
- };
-
- hdmi@39 {
- compatible = "adi,adv7511w";
- reg = <0x39>;
- interrupt-parent = <&gpio1>;
- interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
-
- adi,input-depth = <8>;
- adi,input-colorspace = "rgb";
- adi,input-clock = "1x";
- adi,input-style = <1>;
- adi,input-justification = "evenly";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- adv7511_in: endpoint {
- remote-endpoint = <&du_out_lvds0>;
- };
- };
-
- port@1 {
- reg = <1>;
- adv7511_out: endpoint {
- remote-endpoint = <&hdmi_con>;
- };
- };
- };
- };
- };
-
-And for clarification, here are the snipplets for the i2c-parents:
-
- gpioi2c: i2c@9 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "i2c-gpio";
- gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */
- &gpio5 5 GPIO_ACTIVE_HIGH /* scl */
- >;
- i2c-gpio,delay-us = <5>;
- };
-
-...
-
-&i2c2 {
- pinctrl-0 = <&i2c2_pins>;
- pinctrl-names = "i2c-hdmi";
-
- clock-frequency = <100000>;
-};
-
-...
-
-&iic2 {
- pinctrl-0 = <&iic2_pins>;
- pinctrl-names = "i2c-hdmi";
-
- clock-frequency = <100000>;
-};
-
-Please note:
-
-- pinctrl properties for the parent I2C controllers need a pinctrl state
- with the same name as i2c-bus-name, not "default"!
-
-- the i2c masters must have their status "disabled". This driver will
- enable them at runtime when needed.
diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
new file mode 100644
index 000000000000..1eaf00b90a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Pinctrl-based I2C Bus Demultiplexer
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+description: |
+ This binding describes an I2C bus demultiplexer that uses pin multiplexing to
+ route the I2C signals, and represents the pin multiplexing configuration
+ using the pinctrl device tree bindings. This may be used to select one I2C
+ IP core at runtime which may have a better feature set for a given task than
+ another I2C IP core on the SoC. The most simple example is to fall back to
+ GPIO bitbanging if your current runtime configuration hits an errata of the
+ internal IP core.
+
+ +-------------------------------+
+ | SoC |
+ | | +-----+ +-----+
+ | +------------+ | | dev | | dev |
+ | |I2C IP Core1|--\ | +-----+ +-----+
+ | +------------+ \-------+ | | |
+ | |Pinctrl|--|------+--------+
+ | +------------+ +-------+ |
+ | |I2C IP Core2|--/ |
+ | +------------+ |
+ | |
+ +-------------------------------+
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: i2c-demux-pinctrl
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
+ description:
+ List of phandles of I2C masters available for selection. The first one
+ will be used as default.
+
+ i2c-bus-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ The name of this bus. Also needed as pinctrl-name for the I2C parents.
+
+required:
+ - compatible
+ - i2c-parent
+ - i2c-bus-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpioi2c2: i2c-9 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "i2c-gpio";
+ scl-gpios = <&gpio5 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <5>;
+
+ // The I2C controller must have its status "disabled". The I2C bus
+ // demultiplexer will enable it at runtime when needed.
+ status = "disabled";
+ };
+
+ iic2: i2c@e6520000 {
+ reg = <0xe6520000 0x425>;
+ pinctrl-0 = <&iic2_pins>;
+ // The pinctrl property for the parent I2C controller needs a pinctrl
+ // state with the same name as i2c-bus-name in the I2C bus demultiplexer
+ // node, not "default"!
+ pinctrl-names = "i2c-hdmi";
+
+ clock-frequency = <100000>;
+
+ // The I2C controller must have its status "disabled". The I2C bus
+ // demultiplexer will enable it at runtime when needed.
+ status = "disabled";
+ };
+
+ i2c2: i2c@e6530000 {
+ reg = <0 0xe6530000 0 0x40>;
+ pinctrl-0 = <&i2c2_pins>;
+ // The pinctrl property for the parent I2C controller needs a pinctrl
+ // state with the same name as i2c-bus-name in the I2C bus demultiplexer
+ // node, not "default"!
+ pinctrl-names = "i2c-hdmi";
+
+ clock-frequency = <100000>;
+
+ // The I2C controller must have its status "disabled". The I2C bus
+ // demultiplexer will enable it at runtime when needed.
+ status = "disabled";
+ };
+
+ // Example for a bus to be demuxed. It contains various I2C clients for
+ // HDMI, so the bus is named "i2c-hdmi":
+ i2chdmi: i2c-mux3 {
+ compatible = "i2c-demux-pinctrl";
+ i2c-parent = <&iic2>, <&i2c2>, <&gpioi2c2>;
+ i2c-bus-name = "i2c-hdmi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ak4643: codec@12 {
+ compatible = "asahi-kasei,ak4643";
+ #sound-dai-cells = <0>;
+ reg = <0x12>;
+ };
+
+ composite-in@20 {
+ compatible = "adi,adv7180";
+ reg = <0x20>;
+
+ port {
+ adv7180: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&vin1ep0>;
+ };
+ };
+ };
+
+ hdmi@39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&cec_clock>;
+ clock-names = "cec";
+
+ avdd-supply = <&fixedregulator1v8>;
+ dvdd-supply = <&fixedregulator1v8>;
+ pvdd-supply = <&fixedregulator1v8>;
+ dvdd-3v-supply = <&fixedregulator3v3>;
+ bgvdd-supply = <&fixedregulator1v8>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con_out>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index 3e52a0db6c41..32269239bae4 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -25,7 +25,25 @@ properties:
- samsung,exynos5250-hsi2c # Exynos5250 and Exynos5420
- samsung,exynos5260-hsi2c # Exynos5260
- samsung,exynos7-hsi2c # Exynos7
- - samsung,exynosautov9-hsi2c # ExynosAutoV9 and Exynos850
+ - samsung,exynos8895-hsi2c
+ - samsung,exynosautov9-hsi2c
+ - items:
+ - enum:
+ - samsung,exynos5433-hsi2c
+ - samsung,exynos7870-hsi2c
+ - tesla,fsd-hsi2c
+ - const: samsung,exynos7-hsi2c
+ - items:
+ - enum:
+ - samsung,exynos8890-hsi2c
+ - const: samsung,exynos8895-hsi2c
+ - items:
+ - enum:
+ - google,gs101-hsi2c
+ - samsung,exynos2200-hsi2c
+ - samsung,exynos850-hsi2c
+ - samsung,exynos990-hsi2c
+ - const: samsung,exynosautov9-hsi2c
- const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420
deprecated: true
diff --git a/Documentation/devicetree/bindings/i2c/i2c-fsi.txt b/Documentation/devicetree/bindings/i2c/i2c-fsi.txt
deleted file mode 100644
index b1be2ceb7e69..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-fsi.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Device-tree bindings for FSI-attached I2C master and busses
------------------------------------------------------------
-
-Required properties:
- - compatible = "ibm,i2c-fsi";
- - reg = < address size >; : The FSI CFAM address and address
- space size.
- - #address-cells = <1>; : Number of address cells in child
- nodes.
- - #size-cells = <0>; : Number of size cells in child nodes.
- - child nodes : Nodes to describe busses off the I2C
- master.
-
-Child node required properties:
- - reg = < port number > : The port number on the I2C master.
-
-Child node optional properties:
- - child nodes : Nodes to describe devices on the I2C
- bus.
-
-Examples:
-
- i2c@1800 {
- compatible = "ibm,i2c-fsi";
- reg = < 0x1800 0x400 >;
- #address-cells = <1>;
- #size-cells = <0>;
-
- i2c-bus@0 {
- reg = <0>;
- };
-
- i2c-bus@1 {
- reg = <1>;
-
- eeprom@50 {
- compatible = "vendor,dev-name";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
index fd040284561f..afd4925c2a7d 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for GPIO bitbanged I2C
+title: GPIO bitbanged I2C
maintainers:
- Wolfram Sang <wsa@kernel.org>
@@ -33,6 +33,10 @@ properties:
open drain.
maxItems: 1
+ i2c-gpio,sda-output-only:
+ description: sda as output only
+ type: boolean
+
i2c-gpio,scl-output-only:
description: scl as output only
type: boolean
@@ -63,6 +67,28 @@ properties:
GPIO line used for SCL into open drain mode, and that something is not
the GPIO chip. It is essentially an inconsistency flag.
+ i2c-gpio,sda-has-no-pullup:
+ type: boolean
+ description: sda is used in a non-compliant way and has no pull-up.
+ Therefore disable open-drain. This property is mutually-exclusive
+ with i2c-gpio,sda-open-drain.
+
+ i2c-gpio,scl-has-no-pullup:
+ type: boolean
+ description: scl is used in a non-compliant way and has no pull-up.
+ Therefore disable open-drain. This property is mutually-exclusive
+ with i2c-gpio,scl-open-drain.
+
+dependencies:
+ i2c-gpio,sda-has-no-pullup:
+ not:
+ required:
+ - i2c-gpio,sda-open-drain
+ i2c-gpio,scl-has-no-pullup:
+ not:
+ required:
+ - i2c-gpio,scl-open-drain
+
required:
- compatible
- sda-gpios
diff --git a/Documentation/devicetree/bindings/i2c/i2c-hix5hd2.txt b/Documentation/devicetree/bindings/i2c/i2c-hix5hd2.txt
deleted file mode 100644
index f98b37401e6e..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-hix5hd2.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-I2C for Hisilicon hix5hd2 chipset platform
-
-Required properties:
-- compatible: Must be "hisilicon,hix5hd2-i2c"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: interrupt number to the cpu.
-- #address-cells = <1>;
-- #size-cells = <0>;
-- clocks: phandles to input clocks.
-
-Optional properties:
-- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000
-- Child nodes conforming to i2c bus binding
-
-Examples:
-I2C0@f8b10000 {
- compatible = "hisilicon,hix5hd2-i2c";
- reg = <0xf8b10000 0x1000>;
- interrupts = <0 38 4>;
- clocks = <&clock HIX5HD2_I2C0_RST>;
- #address-cells = <1>;
- #size-cells = <0>;
-}
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
index 4656f5112b84..969030a6f82a 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
@@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Low Power Inter IC (LPI2C) for i.MX
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
@@ -24,6 +26,8 @@ properties:
- fsl,imx8qm-lpi2c
- fsl,imx8ulp-lpi2c
- fsl,imx93-lpi2c
+ - fsl,imx94-lpi2c
+ - fsl,imx95-lpi2c
- const: fsl,imx7ulp-lpi2c
reg:
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
index 85ee1282d6d2..0682a5a10d41 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
@@ -18,6 +18,7 @@ properties:
- const: fsl,imx1-i2c
- const: fsl,imx21-i2c
- const: fsl,vf610-i2c
+ - const: nxp,s32g2-i2c
- items:
- enum:
- fsl,ls1012a-i2c
@@ -54,6 +55,9 @@ properties:
- fsl,imx8mn-i2c
- fsl,imx8mp-i2c
- const: fsl,imx21-i2c
+ - items:
+ - const: nxp,s32g3-i2c
+ - const: nxp,s32g2-i2c
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt b/Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
deleted file mode 100644
index 4101aa621ad4..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-NXP I2C controller for LPC2xxx/178x/18xx/43xx
-
-Required properties:
- - compatible: must be "nxp,lpc1788-i2c"
- - reg: physical address and length of the device registers
- - interrupts: a single interrupt specifier
- - clocks: clock for the device
- - #address-cells: should be <1>
- - #size-cells: should be <0>
-
-Optional properties:
-- clock-frequency: the desired I2C bus clock frequency in Hz; in
- absence of this property the default value is used (100 kHz).
-
-Example:
-i2c0: i2c@400a1000 {
- compatible = "nxp,lpc1788-i2c";
- reg = <0x400a1000 0x1000>;
- interrupts = <18>;
- clocks = <&ccu1 CLK_APB1_I2C0>;
- #address-cells = <1>;
- #size-cells = <0>;
-};
-
-&i2c0 {
- clock-frequency = <400000>;
-
- lm75@48 {
- compatible = "nxp,lm75";
- reg = <0x48>;
- };
-};
-
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
index 018e1b944424..b1d7d14c0be4 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
@@ -43,6 +43,7 @@ properties:
fsl,timeout:
$ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
description: |
I2C bus timeout in microseconds
@@ -95,6 +96,6 @@ examples:
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
- fsl,timeout = <10000>;
+ i2c-transfer-timeout-us = <10000>;
};
...
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml
index 4e730fb7be56..3562ce0c0f7e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml
@@ -23,6 +23,8 @@ properties:
- const: mediatek,mt6577-i2c
- const: mediatek,mt6589-i2c
- const: mediatek,mt7622-i2c
+ - const: mediatek,mt7981-i2c
+ - const: mediatek,mt7986-i2c
- const: mediatek,mt8168-i2c
- const: mediatek,mt8173-i2c
- const: mediatek,mt8183-i2c
@@ -42,6 +44,21 @@ properties:
- const: mediatek,mt6577-i2c
- items:
- enum:
+ - mediatek,mt8365-i2c
+ - const: mediatek,mt8168-i2c
+ - items:
+ - enum:
+ - mediatek,mt6795-i2c
+ - const: mediatek,mt8173-i2c
+ - items:
+ - enum:
+ - mediatek,mt6878-i2c
+ - mediatek,mt6991-i2c
+ - mediatek,mt8196-i2c
+ - const: mediatek,mt8188-i2c
+ - items:
+ - enum:
+ - mediatek,mt6893-i2c
- mediatek,mt8195-i2c
- const: mediatek,mt8192-i2c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt7621.txt b/Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
deleted file mode 100644
index bc36f0eb94cd..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-mt7621.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-MediaTek MT7621/MT7628 I2C master controller
-
-Required properties:
-
-- compatible: Should be one of the following:
- - "mediatek,mt7621-i2c": for MT7621/MT7628/MT7688 platforms
-- #address-cells: should be 1.
-- #size-cells: should be 0.
-- reg: Address and length of the register set for the device
-- resets: phandle to the reset controller asserting this device in
- reset
- See ../reset/reset.txt for details.
-
-Optional properties :
-
-Example:
-
-i2c: i2c@900 {
- compatible = "mediatek,mt7621-i2c";
- reg = <0x900 0x100>;
- #address-cells = <1>;
- #size-cells = <0>;
- resets = <&rstctrl 16>;
- reset-names = "i2c";
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml
index 6e0a5686af04..4a93d1f78f93 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml
@@ -45,7 +45,7 @@ properties:
i2c-parent:
description: phandle of the I2C bus that this multiplexer's master-side port is connected to
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
mux-gpios:
description: list of GPIOs used to control the muxer
@@ -55,7 +55,10 @@ properties:
idle-state:
description: Value to set the muxer to when idle. When no value is given, it defaults to the
last value used.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ settle-time-us:
+ description: Delay to wait before doing any transfer when a new bus gets selected.
allOf:
- $ref: i2c-mux.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml
index b6af924dee2e..d8610daa10cd 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml
@@ -27,7 +27,6 @@ description: |+
| '------' | | dev | | dev | | dev |
'------------' '-----' '-----' '-----'
-
allOf:
- $ref: /schemas/i2c/i2c-mux.yaml#
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
index 9f1726d0356b..9aa0585200c9 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
@@ -4,21 +4,29 @@
$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP PCA954x I2C bus switch
+title: NXP PCA954x I2C and compatible bus switches
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description:
- The binding supports NXP PCA954x and PCA984x I2C mux/switch devices.
-
-allOf:
- - $ref: /schemas/i2c/i2c-mux.yaml#
+ The NXP PCA954x and compatible devices are I2C bus
+ multiplexer/switches that share the same functionality
+ and register layout.
+ The devices usually have 4 or 8 child buses, which are
+ attached to the parent bus by using the SMBus "Send Byte"
+ command.
properties:
compatible:
oneOf:
- enum:
+ - maxim,max7356
+ - maxim,max7357
+ - maxim,max7358
+ - maxim,max7367
+ - maxim,max7368
+ - maxim,max7369
- nxp,pca9540
- nxp,pca9542
- nxp,pca9543
@@ -59,10 +67,64 @@ properties:
description: if present, overrides i2c-mux-idle-disconnect
$ref: /schemas/mux/mux-controller.yaml#/properties/idle-state
+ vdd-supply:
+ description: A voltage regulator supplying power to the chip. On PCA9846
+ the regulator supplies power to VDD2 (core logic) and optionally to VDD1.
+
+ maxim,isolate-stuck-channel:
+ type: boolean
+ description: Allows to use non faulty channels while a stuck channel is
+ isolated from the upstream bus. If not set all channels are isolated from
+ the upstream bus until the fault is cleared.
+
+ maxim,send-flush-out-sequence:
+ type: boolean
+ description: Send a flush-out sequence to stuck auxiliary buses
+ automatically after a stuck channel is being detected.
+
+ maxim,preconnection-wiggle-test-enable:
+ type: boolean
+ description: Send a STOP condition to the auxiliary buses when the switch
+ register activates a channel to detect a stuck high fault. On fault the
+ channel is isolated from the upstream bus.
+
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/i2c/i2c-mux.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max7367
+ - maxim,max7369
+ - nxp,pca9542
+ - nxp,pca9543
+ - nxp,pca9544
+ - nxp,pca9545
+ then:
+ properties:
+ interrupts: false
+ "#interrupt-cells": false
+ interrupt-controller: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max7357
+ then:
+ properties:
+ maxim,isolate-stuck-channel: false
+ maxim,send-flush-out-sequence: false
+ maxim,preconnection-wiggle-test-enable: false
+
unevaluatedProperties: false
examples:
@@ -74,11 +136,13 @@ examples:
#size-cells = <0>;
i2c-mux@74 {
- compatible = "nxp,pca9548";
+ compatible = "nxp,pca9545";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
+ vdd-supply = <&p3v3>;
+
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
index 21ae7bce038e..171a41407241 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
@@ -9,6 +9,9 @@ title: Freescale MXS Inter IC (I2C) Controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
properties:
compatible:
enum:
@@ -37,7 +40,7 @@ required:
- dmas
- dma-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pnx.txt b/Documentation/devicetree/bindings/i2c/i2c-pnx.txt
deleted file mode 100644
index 2a59006cf79e..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-pnx.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* NXP PNX I2C Controller
-
-Required properties:
-
- - reg: Offset and length of the register set for the device
- - compatible: should be "nxp,pnx-i2c"
- - interrupts: configure one interrupt line
- - #address-cells: always 1 (for i2c addresses)
- - #size-cells: always 0
-
-Optional properties:
-
- - clock-frequency: desired I2C bus clock frequency in Hz, Default: 100000 Hz
-
-Examples:
-
- i2c1: i2c@400a0000 {
- compatible = "nxp,pnx-i2c";
- reg = <0x400a0000 0x100>;
- interrupt-parent = <&mic>;
- interrupts = <51 0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
- i2c2: i2c@400a8000 {
- compatible = "nxp,pnx-i2c";
- reg = <0x400a8000 0x100>;
- interrupt-parent = <&mic>;
- interrupts = <50 0>;
- #address-cells = <1>;
- #size-cells = <0>;
- clock-frequency = <100000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml
index 015885dd02d3..e89ee361741e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/i2c/i2c-pxa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell MMP I2C controller bindings
+title: Marvell MMP I2C controller
maintainers:
- - Rob Herring <robh+dt@kernel.org>
+ - Rob Herring <robh@kernel.org>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
index 82b9d6682297..91805fe8f393 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
@@ -37,7 +37,11 @@ properties:
- rockchip,px30-i2c
- rockchip,rk3308-i2c
- rockchip,rk3328-i2c
+ - rockchip,rk3506-i2c
+ - rockchip,rk3528-i2c
+ - rockchip,rk3562-i2c
- rockchip,rk3568-i2c
+ - rockchip,rk3576-i2c
- rockchip,rk3588-i2c
- rockchip,rv1126-i2c
- const: rockchip,rk3399-i2c
@@ -102,6 +106,9 @@ properties:
(t(f) in the I2C specification). If not specified we will use the SCL
value since they are the same in nearly all cases.
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
deleted file mode 100644
index 60b7cda15dd2..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-I2C for Spreadtrum platforms
-
-Required properties:
-- compatible: Should be "sprd,sc9860-i2c".
-- reg: Specify the physical base address of the controller and length
- of memory mapped region.
-- interrupts: Should contain I2C interrupt.
-- clock-names: Should contain following entries:
- "i2c" for I2C clock,
- "source" for I2C source (parent) clock,
- "enable" for I2C module enable clock.
-- clocks: Should contain a clock specifier for each entry in clock-names.
-- clock-frequency: Constains desired I2C bus clock frequency in Hz.
-- #address-cells: Should be 1 to describe address cells for I2C device address.
-- #size-cells: Should be 0 means no size cell for I2C device address.
-
-Optional properties:
-- Child nodes conforming to I2C bus binding
-
-Examples:
-i2c0: i2c@70500000 {
- compatible = "sprd,sc9860-i2c";
- reg = <0 0x70500000 0 0x1000>;
- interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "i2c", "source", "enable";
- clocks = <&clk_i2c3>, <&ext_26m>, <&clk_ap_apb_gates 11>;
- clock-frequency = <400000>;
- #address-cells = <1>;
- #size-cells = <0>;
-};
-
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt b/Documentation/devicetree/bindings/i2c/i2c-st.txt
deleted file mode 100644
index 4c26fda3844a..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-st.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-ST SSC binding, for I2C mode operation
-
-Required properties :
-- compatible : Must be "st,comms-ssc-i2c" or "st,comms-ssc4-i2c"
-- reg : Offset and length of the register set for the device
-- interrupts : the interrupt specifier
-- clock-names: Must contain "ssc".
-- clocks: Must contain an entry for each name in clock-names. See the common
- clock bindings.
-- A pinctrl state named "default" must be defined to set pins in mode of
- operation for I2C transfer.
-
-Optional properties :
-- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
- the default 100 kHz frequency will be used. As only Normal and Fast modes
- are supported, possible values are 100000 and 400000.
-- st,i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
- allowed through the deglitch circuit. In units of us.
-- st,i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
- allowed through the deglitch circuit. In units of us.
-- A pinctrl state named "idle" could be defined to set pins in idle state
- when I2C instance is not performing a transfer.
-- A pinctrl state named "sleep" could be defined to set pins in sleep state
- when driver enters in suspend.
-
-
-
-Example :
-
-i2c0: i2c@fed40000 {
- compatible = "st,comms-ssc4-i2c";
- reg = <0xfed40000 0x110>;
- interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_s_a0_ls CLK_ICN_REG>;
- clock-names = "ssc";
- clock-frequency = <400000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c0_default>;
- st,i2c-min-scl-pulse-width-us = <0>;
- st,i2c-min-sda-pulse-width-us = <5>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-synquacer.txt b/Documentation/devicetree/bindings/i2c/i2c-synquacer.txt
deleted file mode 100644
index 72f4a2f0fedc..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-synquacer.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Socionext SynQuacer I2C
-
-Required properties:
-- compatible : Must be "socionext,synquacer-i2c"
-- reg : Offset and length of the register set for the device
-- interrupts : A single interrupt specifier
-- #address-cells : Must be <1>;
-- #size-cells : Must be <0>;
-- clock-names : Must contain "pclk".
-- clocks : Must contain an entry for each name in clock-names.
- (See the common clock bindings.)
-
-Optional properties:
-- clock-frequency : Desired I2C bus clock frequency in Hz. As only Normal and
- Fast modes are supported, possible values are 100000 and
- 400000.
-
-Example :
-
- i2c@51210000 {
- compatible = "socionext,synquacer-i2c";
- reg = <0x51210000 0x1000>;
- interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- clock-names = "pclk";
- clocks = <&clk_i2c>;
- clock-frequency = <400000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-wmt.txt b/Documentation/devicetree/bindings/i2c/i2c-wmt.txt
deleted file mode 100644
index 94a425eaa6c7..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-wmt.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Wondermedia I2C Controller
-
-Required properties :
-
- - compatible : should be "wm,wm8505-i2c"
- - reg : Offset and length of the register set for the device
- - interrupts : <IRQ> where IRQ is the interrupt number
- - clocks : phandle to the I2C clock source
-
-Optional properties :
-
- - clock-frequency : desired I2C bus clock frequency in Hz.
- Valid values are 100000 and 400000.
- Default to 100000 if not specified, or invalid value.
-
-Example :
-
- i2c_0: i2c@d8280000 {
- compatible = "wm,wm8505-i2c";
- reg = <0xd8280000 0x1000>;
- interrupts = <19>;
- clocks = <&clki2c0>;
- clock-frequency = <400000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt b/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
deleted file mode 100644
index f6b2c20cfbf6..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-xgene-slimpro.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-APM X-Gene SLIMpro Mailbox I2C Driver
-
-An I2C controller accessed over the "SLIMpro" mailbox.
-
-Required properties :
-
- - compatible : should be "apm,xgene-slimpro-i2c"
- - mboxes : use the label reference for the mailbox as the first parameter.
- The second parameter is the channel number.
-
-Example :
- i2cslimpro {
- compatible = "apm,xgene-slimpro-i2c";
- mboxes = <&mailbox 0>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
deleted file mode 100644
index fc3dd7ec0445..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ /dev/null
@@ -1,151 +0,0 @@
-Generic device tree bindings for I2C busses
-===========================================
-
-This document describes generic bindings which can be used to describe I2C
-busses and their child devices in a device tree.
-
-Required properties (per bus)
------------------------------
-
-- #address-cells - should be <1>. Read more about addresses below.
-- #size-cells - should be <0>.
-- compatible - name of I2C bus controller
-
-For other required properties e.g. to describe register sets,
-clocks, etc. check the binding documentation of the specific driver.
-
-The cells properties above define that an address of children of an I2C bus
-are described by a single value.
-
-Optional properties (per bus)
------------------------------
-
-These properties may not be supported by all drivers. However, if a driver
-wants to support one of the below features, it should adapt these bindings.
-
-- clock-frequency
- frequency of bus clock in Hz.
-
-- i2c-bus
- For I2C adapters that have child nodes that are a mixture of both I2C
- devices and non-I2C devices, the 'i2c-bus' subnode can be used for
- populating I2C devices. If the 'i2c-bus' subnode is present, only
- subnodes of this will be considered as I2C slaves. The properties,
- '#address-cells' and '#size-cells' must be defined under this subnode
- if present.
-
-- i2c-scl-falling-time-ns
- Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C
- specification.
-
-- i2c-scl-internal-delay-ns
- Number of nanoseconds the IP core additionally needs to setup SCL.
-
-- i2c-scl-rising-time-ns
- Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C
- specification.
-
-- i2c-sda-falling-time-ns
- Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
- specification.
-
-- i2c-analog-filter
- Enable analog filter for i2c lines.
-
-- i2c-digital-filter
- Enable digital filter for i2c lines.
-
-- i2c-digital-filter-width-ns
- Width of spikes which can be filtered by digital filter
- (i2c-digital-filter). This width is specified in nanoseconds.
-
-- i2c-analog-filter-cutoff-frequency
- Frequency that the analog filter (i2c-analog-filter) uses to distinguish
- which signal to filter. Signal with higher frequency than specified will
- be filtered out. Only lower frequency will pass (this is applicable to
- a low-pass analog filter). Typical value should be above the normal
- i2c bus clock frequency (clock-frequency).
- Specified in Hz.
-
-- multi-master
- states that there is another master active on this bus. The OS can use
- this information to adapt power management to keep the arbitration awake
- all the time, for example. Can not be combined with 'single-master'.
-
-- pinctrl
- add extra pinctrl to configure SCL/SDA pins to GPIO function for bus
- recovery, call it "gpio" or "recovery" (deprecated) state
-
-- scl-gpios
- specify the gpio related to SCL pin. Used for GPIO bus recovery.
-
-- sda-gpios
- specify the gpio related to SDA pin. Optional for GPIO bus recovery.
-
-- single-master
- states that there is no other master active on this bus. The OS can use
- this information to detect a stalled bus more reliably, for example.
- Can not be combined with 'multi-master'.
-
-- smbus
- states that additional SMBus restrictions and features apply to this bus.
- An example of feature is SMBusHostNotify. Examples of restrictions are
- more reserved addresses and timeout definitions.
-
-- smbus-alert
- states that the optional SMBus-Alert feature apply to this bus.
-
-- mctp-controller
- indicates that the system is accessible via this bus as an endpoint for
- MCTP over I2C transport.
-
-Required properties (per child device)
---------------------------------------
-
-- compatible
- name of I2C slave device
-
-- reg
- One or many I2C slave addresses. These are usually a 7 bit addresses.
- However, flags can be attached to an address. I2C_TEN_BIT_ADDRESS is
- used to mark a 10 bit address. It is needed to avoid the ambiguity
- between e.g. a 7 bit address of 0x50 and a 10 bit address of 0x050
- which, in theory, can be on the same bus.
- Another flag is I2C_OWN_SLAVE_ADDRESS to mark addresses on which we
- listen to be devices ourselves.
-
-Optional properties (per child device)
---------------------------------------
-
-These properties may not be supported by all drivers. However, if a driver
-wants to support one of the below features, it should adapt these bindings.
-
-- host-notify
- device uses SMBus host notify protocol instead of interrupt line.
-
-- interrupts
- interrupts used by the device.
-
-- interrupt-names
- "irq", "wakeup" and "smbus_alert" names are recognized by I2C core,
- other names are left to individual drivers.
-
-- reg-names
- Names of map programmable addresses.
- It can contain any map needing another address than default one.
-
-- wakeup-source
- device can be used as a wakeup source.
-
-Binding may contain optional "interrupts" property, describing interrupts
-used by the device. I2C core will assign "irq" interrupt (or the very first
-interrupt if not using interrupt names) as primary interrupt for the slave.
-
-Alternatively, devices supporting SMBus Host Notify, and connected to
-adapters that support this feature, may use "host-notify" property. I2C
-core will create a virtual interrupt for Host Notify and assign it as
-primary interrupt for the slave.
-
-Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
-interrupt for the device. If "wakeup" interrupt name is not present in the
-binding, then primary interrupt will be used as wakeup interrupt.
diff --git a/Documentation/devicetree/bindings/i2c/ibm,i2c-fsi.yaml b/Documentation/devicetree/bindings/i2c/ibm,i2c-fsi.yaml
new file mode 100644
index 000000000000..40ea82942e4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ibm,i2c-fsi.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/ibm,i2c-fsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM FSI-attached I2C controller
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ This I2C controller is an FSI CFAM engine, providing access to a number of
+ I2C busses. Therefore this node will always be a child of an FSI CFAM node.
+
+properties:
+ compatible:
+ enum:
+ - ibm,i2c-fsi
+
+ reg:
+ items:
+ - description: FSI slave address
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^i2c-bus@[0-9a-f]+$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c@1800 {
+ compatible = "ibm,i2c-fsi";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-bus@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c-bus@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml
index af6d64a6da6e..b61fdc9548d8 100644
--- a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/ingenic,i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs I2C controller devicetree bindings
+title: Ingenic SoCs I2C controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml b/Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml
new file mode 100644
index 000000000000..67882ec6e06a
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/loongson,ls2x-i2c.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/loongson,ls2x-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS2X I2C Controller
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k-i2c
+ - loongson,ls7a-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c0: i2c@1fe21000 {
+ compatible = "loongson,ls2k-i2c";
+ reg = <0x1fe21000 0x8>;
+ interrupt-parent = <&extioiic>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@57 {
+ compatible = "atmel,24c16";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
index 63d665a4f9bb..c4efcef59133 100644
--- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/marvell,mv64xxx-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell MV64XXX I2C Controller Device Tree Bindings
+title: Marvell MV64XXX I2C Controller
maintainers:
- Gregory CLEMENT <gregory.clement@bootlin.com>
@@ -19,6 +19,7 @@ properties:
- const: allwinner,sun6i-a31-i2c
- items:
- enum:
+ - allwinner,suniv-f1c100s-i2c
- allwinner,sun8i-a23-i2c
- allwinner,sun8i-a83t-i2c
- allwinner,sun8i-v536-i2c
@@ -32,6 +33,7 @@ properties:
- allwinner,sun50i-a100-i2c
- allwinner,sun50i-h616-i2c
- allwinner,sun50i-r329-i2c
+ - allwinner,sun55i-a523-i2c
- const: allwinner,sun8i-v536-i2c
- const: allwinner,sun6i-a31-i2c
- const: marvell,mv64xxx-i2c
diff --git a/Documentation/devicetree/bindings/i2c/mediatek,mt7621-i2c.yaml b/Documentation/devicetree/bindings/i2c/mediatek,mt7621-i2c.yaml
new file mode 100644
index 000000000000..118ec00fc190
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/mediatek,mt7621-i2c.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/mediatek,mt7621-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+maintainers:
+ - Stefan Roese <sr@denx.de>
+
+title: Mediatek MT7621/MT7628 I2C master controller
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt7621-i2c
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: i2c
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: i2c
+
+required:
+ - compatible
+ - reg
+ - resets
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt7621-clk.h>
+ #include <dt-bindings/reset/mt7621-reset.h>
+
+ i2c: i2c@900 {
+ compatible = "mediatek,mt7621-i2c";
+ reg = <0x900 0x100>;
+ clocks = <&sysc MT7621_CLK_I2C>;
+ clock-names = "i2c";
+ resets = <&sysc MT7621_RST_I2C>;
+ reset-names = "i2c";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml
index 7bad4b946a34..6ff58b64d496 100644
--- a/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/microchip,corei2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip MPFS I2C Controller Device Tree Bindings
+title: Microchip MPFS I2C Controller
maintainers:
- Daire McNamara <daire.mcnamara@microchip.com>
@@ -16,7 +16,9 @@ properties:
compatible:
oneOf:
- items:
- - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs
+ - enum:
+ - microchip,pic64gx-i2c
+ - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs
- const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core
- const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core
diff --git a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
index 09d2591e1fa3..00eb6ff6f5b1 100644
--- a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/nuvoton,npcm7xx-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: nuvoton NPCM7XX I2C Controller Device Tree Bindings
+title: nuvoton NPCM7XX I2C Controller
description: |
I2C bus controllers of the NPCM series support both master and
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml
index b8319dcf3d8a..8676335e9e94 100644
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml
@@ -21,8 +21,7 @@ description: |
See ../firmware/nvidia,tegra186-bpmp.yaml for details of the BPMP
binding.
- This node represents an I2C controller. See ../i2c/i2c.txt for details
- of the core I2C binding.
+ This node represents an I2C controller.
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
index 424a4fc218b6..51241c1293e3 100644
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
@@ -80,6 +80,17 @@ properties:
support for 64 KiB transactions whereas earlier chips supported no
more than 4 KiB per transactions.
const: nvidia,tegra194-i2c
+ - description: |
+ Tegra256 has 8 generic I2C controllers. The controllers are similar to
+ the previous generations, but have a different parent clock and hence
+ the timing parameters are configured differently.
+ const: nvidia,tegra256-i2c
+ - description:
+ Tegra264 has 17 generic I2C controllers, two of which are in the AON
+ (always-on) partition of the SoC. In addition to the features from
+ Tegra194, a SW mutex register is added to support use of the same I2C
+ instance across multiple firmwares.
+ const: nvidia,tegra264-i2c
reg:
maxItems: 1
@@ -87,12 +98,6 @@ properties:
interrupts:
maxItems: 1
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
clocks:
minItems: 1
maxItems: 2
@@ -103,12 +108,18 @@ properties:
resets:
items:
- - description: module reset
+ - description:
+ Module reset. This property is optional for controllers in Tegra194,
+ Tegra234 etc where an internal software reset is available as an
+ alternative.
reset-names:
items:
- const: i2c
+ power-domains:
+ maxItems: 1
+
dmas:
items:
- description: DMA channel for the reception FIFO
@@ -119,6 +130,13 @@ properties:
- const: rx
- const: tx
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml
- if:
@@ -130,6 +148,8 @@ allOf:
- nvidia,tegra30-i2c
then:
properties:
+ clocks:
+ minItems: 2
clock-names:
items:
- const: div-clk
@@ -139,20 +159,13 @@ allOf:
properties:
compatible:
contains:
- const: nvidia,tegra114-i2c
- then:
- properties:
- clock-names:
- items:
- - const: div-clk
-
- - if:
- properties:
- compatible:
- contains:
- const: nvidia,tegra210-i2c
+ enum:
+ - nvidia,tegra114-i2c
+ - nvidia,tegra210-i2c
then:
properties:
+ clocks:
+ maxItems: 1
clock-names:
items:
- const: div-clk
@@ -164,6 +177,8 @@ allOf:
const: nvidia,tegra210-i2c-vi
then:
properties:
+ clocks:
+ minItems: 2
clock-names:
items:
- const: div-clk
@@ -171,6 +186,23 @@ allOf:
power-domains:
items:
- description: phandle to the VENC power domain
+ else:
+ properties:
+ power-domains: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-i2c
+ - nvidia,tegra256-i2c
+ - nvidia,tegra264-i2c
+ then:
+ required:
+ - resets
+ - reset-names
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/i2c/nxp,lpc1788-i2c.yaml b/Documentation/devicetree/bindings/i2c/nxp,lpc1788-i2c.yaml
new file mode 100644
index 000000000000..9a1b95c2d03c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nxp,lpc1788-i2c.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nxp,lpc1788-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP I2C controller for LPC2xxx/178x/18xx/43xx
+
+maintainers:
+ - Vladimir Zapolskiy <vz@mleia.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: nxp,lpc1788-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ description: the desired I2C bus clock frequency in Hz
+ default: 100000
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include "dt-bindings/clock/lpc18xx-ccu.h"
+
+ i2c@400a1000 {
+ compatible = "nxp,lpc1788-i2c";
+ reg = <0x400a1000 0x1000>;
+ interrupts = <18>;
+ clocks = <&ccu1 CLK_APB1_I2C0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt b/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
deleted file mode 100644
index 42bfc09c8918..000000000000
--- a/Documentation/devicetree/bindings/i2c/nxp,pca9541.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* NXP PCA9541 I2C bus master selector
-
-Required Properties:
-
- - compatible: Must be "nxp,pca9541"
-
- - reg: The I2C address of the device.
-
- The following required properties are defined externally:
-
- - I2C arbitration bus node. See i2c-arb.txt in this directory.
-
-
-Example:
-
- i2c-arbitrator@74 {
- compatible = "nxp,pca9541";
- reg = <0x74>;
-
- i2c-arb {
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@54 {
- compatible = "atmel,24c08";
- reg = <0x54>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml b/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml
new file mode 100644
index 000000000000..b65c25c1a435
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nxp,pca9541.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nxp,pca9541.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA9541 I2C bus master selector
+
+maintainers:
+ - Peter Rosin <peda@axentia.se>
+
+properties:
+ compatible:
+ const: nxp,pca9541
+
+ reg:
+ maxItems: 1
+
+ i2c-arb:
+ type: object
+ $ref: /schemas/i2c/i2c-controller.yaml
+ unevaluatedProperties: false
+ description:
+ I2C arbitration bus node.
+
+required:
+ - compatible
+ - reg
+ - i2c-arb
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-arbitrator@74 {
+ compatible = "nxp,pca9541";
+ reg = <0x74>;
+
+ i2c-arb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@54 {
+ compatible = "atmel,24c08";
+ reg = <0x54>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml b/Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml
new file mode 100644
index 000000000000..e645784b77d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nxp,pnx-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PNX I2C Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: nxp,pnx-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ default: 100000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@400a0000 {
+ compatible = "nxp,pnx-i2c";
+ reg = <0x400a0000 0x100>;
+ interrupt-parent = <&mic>;
+ interrupts = <51 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml b/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml
index 85d9efb743ee..d9ef86729011 100644
--- a/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml
+++ b/Documentation/devicetree/bindings/i2c/opencores,i2c-ocores.yaml
@@ -60,6 +60,7 @@ properties:
default: 0
regstep:
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
deprecated, use reg-shift above
deprecated: true
diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
index e51a85848d6e..33852a5ffca8 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
@@ -12,13 +12,34 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,msm8916-cci
- - qcom,msm8974-cci
- - qcom,msm8996-cci
- - qcom,sdm845-cci
- - qcom,sm8250-cci
- - qcom,sm8450-cci
+ oneOf:
+ - enum:
+ - qcom,msm8226-cci
+ - qcom,msm8953-cci
+ - qcom,msm8974-cci
+ - qcom,msm8996-cci
+
+ - items:
+ - enum:
+ - qcom,msm8916-cci
+ - const: qcom,msm8226-cci # CCI v1
+
+ - items:
+ - enum:
+ - qcom,kaanapali-cci
+ - qcom,qcm2290-cci
+ - qcom,sa8775p-cci
+ - qcom,sc7280-cci
+ - qcom,sc8280xp-cci
+ - qcom,sdm670-cci
+ - qcom,sdm845-cci
+ - qcom,sm6350-cci
+ - qcom,sm8250-cci
+ - qcom,sm8450-cci
+ - qcom,sm8550-cci
+ - qcom,sm8650-cci
+ - qcom,x1e80100-cci
+ - const: qcom,msm8996-cci # CCI v2
"#address-cells":
const: 1
@@ -27,11 +48,11 @@ properties:
const: 0
clocks:
- minItems: 4
+ minItems: 2
maxItems: 6
clock-names:
- minItems: 4
+ minItems: 2
maxItems: 6
interrupts:
@@ -78,6 +99,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,msm8226-cci
- qcom,msm8916-cci
then:
properties:
@@ -86,13 +108,54 @@ allOf:
- if:
properties:
compatible:
+ oneOf:
+ - contains:
+ enum:
+ - qcom,msm8974-cci
+
+ - const: qcom,msm8226-cci
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: camss_top_ahb
+ - const: cci_ahb
+ - const: cci
+
+ - if:
+ properties:
+ compatible:
contains:
enum:
- - qcom,msm8916-cci
- - qcom,msm8996-cci
+ - qcom,kaanapali-cci
+ - qcom,qcm2290-cci
then:
properties:
clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: ahb
+ - const: cci
+
+ - if:
+ properties:
+ compatible:
+ oneOf:
+ - contains:
+ enum:
+ - qcom,msm8916-cci
+ - qcom,msm8953-cci
+
+ - const: qcom,msm8996-cci
+ then:
+ properties:
+ clocks:
+ minItems: 4
maxItems: 4
clock-names:
items:
@@ -106,7 +169,26 @@ allOf:
compatible:
contains:
enum:
+ - qcom,sdm670-cci
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: soc_ahb
+ - const: cpas_ahb
+ - const: cci
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,sdm845-cci
+ - qcom,sm6350-cci
then:
properties:
clocks:
@@ -125,6 +207,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,sc7280-cci
- qcom,sm8250-cci
- qcom,sm8450-cci
then:
@@ -140,6 +223,44 @@ allOf:
- const: cci
- const: cci_src
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-cci
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: slow_ahb_src
+ - const: cpas_ahb
+ - const: cci
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-cci
+ - qcom,sm8550-cci
+ - qcom,sm8650-cci
+ - qcom,x1e80100-cci
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: cci
+
additionalProperties: false
examples:
@@ -150,7 +271,7 @@ examples:
cci@ac4a000 {
reg = <0x0ac4a000 0x4000>;
- compatible = "qcom,sdm845-cci";
+ compatible = "qcom,sdm845-cci", "qcom,msm8996-cci";
#address-cells = <1>;
#size-cells = <0>;
@@ -195,7 +316,8 @@ examples:
clocks = <&clock_camcc CAM_CC_MCLK0_CLK>;
clock-names = "xvclk";
- clock-frequency = <19200000>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK0_CLK>;
+ assigned-clock-rates = <19200000>;
dovdd-supply = <&vreg_lvs1a_1p8>;
avdd-supply = <&cam0_avdd_2v8>;
@@ -227,14 +349,16 @@ examples:
clocks = <&clock_camcc CAM_CC_MCLK3_CLK>;
clock-names = "xclk";
- clock-frequency = <24000000>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <24000000>;
vdddo-supply = <&vreg_lvs1a_1p8>;
vdda-supply = <&cam3_avdd_2v8>;
port {
ov7251_ep: endpoint {
- data-lanes = <0 1>;
+ data-lanes = <0>;
+ link-frequencies = /bits/ 64 <240000000 319200000>;
remote-endpoint = <&csiphy3_ep>;
};
};
diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
index 0e7ed00562e2..51534953a69c 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/i2c/qcom,i2c-geni-qcom.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/i2c/qcom,i2c-geni-qcom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Geni based QUP I2C Controller
@@ -10,18 +10,19 @@ maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
-allOf:
- - $ref: /schemas/i2c/i2c-controller.yaml#
-
properties:
compatible:
- const: qcom,geni-i2c
+ enum:
+ - qcom,geni-i2c
+ - qcom,geni-i2c-master-hub
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
clock-names:
- const: se
+ minItems: 1
+ maxItems: 2
clock-frequency:
default: 100000
@@ -35,17 +36,18 @@ properties:
- const: rx
interconnects:
+ minItems: 2
maxItems: 3
interconnect-names:
- items:
- - const: qup-core
- - const: qup-config
- - const: qup-memory
+ minItems: 2
+ maxItems: 3
interrupts:
maxItems: 1
+ operating-points-v2: true
+
pinctrl-0: true
pinctrl-1: true
@@ -71,6 +73,51 @@ required:
- clock-names
- reg
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+ - $ref: /schemas/soc/qcom/qcom,se-common-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,geni-i2c-master-hub
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: se
+ - const: core
+
+ dmas: false
+ dma-names: false
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: qup-core
+ - const: qup-config
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: se
+
+ interconnects:
+ minItems: 3
+
+ interconnect-names:
+ items:
+ - const: qup-core
+ - const: qup-config
+ - const: qup-memory
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
index f43947514d48..06a04db3eda2 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml
@@ -9,7 +9,7 @@ title: Qualcomm Universal Peripheral (QUP) I2C controller
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
@@ -40,6 +40,9 @@ properties:
- const: tx
- const: rx
+ interconnects:
+ maxItems: 1
+
interrupts:
maxItems: 1
@@ -52,9 +55,15 @@ properties:
- const: default
- const: sleep
+ power-domains:
+ maxItems: 1
+
reg:
maxItems: 1
+ required-opps:
+ maxItems: 1
+
required:
- compatible
- clock-names
@@ -67,7 +76,9 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8998.h>
+ #include <dt-bindings/interconnect/qcom,msm8996.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
i2c@c175000 {
compatible = "qcom,i2c-qup-v2.2.1";
@@ -82,6 +93,9 @@ examples:
pinctrl-names = "default", "sleep";
pinctrl-0 = <&blsp1_i2c1_default>;
pinctrl-1 = <&blsp1_i2c1_sleep>;
+ power-domains = <&rpmpd MSM8909_VDDCX>;
+ required-opps = <&rpmpd_opp_svs_krait>;
+ interconnects = <&pnoc MASTER_BLSP_1 &bimc SLAVE_EBI_CH0>;
clock-frequency = <400000>;
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
new file mode 100644
index 000000000000..f9a449fee2b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/realtek,rtl9301-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTL I2C Controller
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+description:
+ RTL9300 SoCs have two I2C controllers. Each of these has an SCL line (which
+ if not-used for SCL can be a GPIO). There are 8 common SDA lines that can be
+ assigned to either I2C controller.
+ RTL9310 SoCs have equal capabilities but support 12 common SDA lines which
+ can be assigned to either I2C controller.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - realtek,rtl9302b-i2c
+ - realtek,rtl9302c-i2c
+ - realtek,rtl9303-i2c
+ - const: realtek,rtl9301-i2c
+ - items:
+ - enum:
+ - realtek,rtl9311-i2c
+ - realtek,rtl9312-i2c
+ - realtek,rtl9313-i2c
+ - const: realtek,rtl9310-i2c
+ - enum:
+ - realtek,rtl9301-i2c
+ - realtek,rtl9310-i2c
+
+ reg:
+ items:
+ - description: Register offset and size of this I2C controller.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ realtek,scl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The SCL line number of this I2C controller.
+ enum: [ 0, 1 ]
+
+patternProperties:
+ '^i2c@[0-9ab]$':
+ $ref: /schemas/i2c/i2c-controller.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: The SDA line number associated with the I2C bus.
+ maxItems: 1
+
+ required:
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: realtek,rtl9310-i2c
+ then:
+ required:
+ - realtek,scl
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: realtek,rtl9301-i2c
+ then:
+ patternProperties:
+ '^i2c@[89ab]$': false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c@36c {
+ compatible = "realtek,rtl9301-i2c";
+ reg = <0x36c 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
index 17c1102562be..551cfa6f885a 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
+++ b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
@@ -44,11 +44,11 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
iic0: i2c@e0070000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "renesas,iic-emev2";
- reg = <0xe0070000 0x28>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>;
- clocks = <&iic0_sclk>;
- clock-names = "sclk";
+ compatible = "renesas,iic-emev2";
+ reg = <0xe0070000 0x28>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&iic0_sclk>;
+ clock-names = "sclk";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml
index c4ace5585e1e..6cc60c3f61cd 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml
@@ -53,6 +53,7 @@ properties:
- renesas,i2c-r8a779a0 # R-Car V3U
- renesas,i2c-r8a779f0 # R-Car S4-8
- renesas,i2c-r8a779g0 # R-Car V4H
+ - renesas,i2c-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-i2c # R-Car Gen4
reg:
@@ -152,14 +153,14 @@ examples:
#include <dt-bindings/power/r8a7791-sysc.h>
i2c0: i2c@e6508000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
- reg = <0xe6508000 0x40>;
- interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
- clock-frequency = <400000>;
- clocks = <&cpg CPG_MOD 931>;
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
- resets = <&cpg 931>;
- i2c-scl-internal-delay-ns = <6>;
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
+ reg = <0xe6508000 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 931>;
+ i2c-scl-internal-delay-ns = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml
index d3c0d5c427ac..6876eade431b 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml
+++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml
@@ -10,44 +10,69 @@ maintainers:
- Chris Brandt <chris.brandt@renesas.com>
- Wolfram Sang <wsa+renesas@sang-engineering.com>
-allOf:
- - $ref: /schemas/i2c/i2c-controller.yaml#
-
properties:
compatible:
- items:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,riic-r7s72100 # RZ/A1H
+ - renesas,riic-r7s9210 # RZ/A2M
+ - renesas,riic-r9a07g043 # RZ/G2UL and RZ/Five
+ - renesas,riic-r9a07g044 # RZ/G2{L,LC}
+ - renesas,riic-r9a07g054 # RZ/V2L
+ - const: renesas,riic-rz # RZ/A or RZ/G2L
+
+ - items:
+ - enum:
+ - renesas,riic-r9a08g045 # RZ/G3S
+ - renesas,riic-r9a09g047 # RZ/G3E
+ - renesas,riic-r9a09g056 # RZ/V2N
+ - const: renesas,riic-r9a09g057 # RZ/V2H(P)
+
- enum:
- - renesas,riic-r7s72100 # RZ/A1H
- - renesas,riic-r7s9210 # RZ/A2M
- - renesas,riic-r9a07g043 # RZ/G2UL
- - renesas,riic-r9a07g044 # RZ/G2{L,LC}
- - renesas,riic-r9a07g054 # RZ/V2L
- - const: renesas,riic-rz # RZ/A or RZ/G2L
+ - renesas,riic-r9a09g057 # RZ/V2H(P)
+ - renesas,riic-r9a09g077 # RZ/T2H
+
+ - items:
+ - const: renesas,riic-r9a09g087 # RZ/N2H
+ - const: renesas,riic-r9a09g077 # RZ/T2H
reg:
maxItems: 1
interrupts:
- items:
- - description: Transmit End Interrupt
- - description: Receive Data Full Interrupt
- - description: Transmit Data Empty Interrupt
- - description: Stop Condition Detection Interrupt
- - description: Start Condition Detection Interrupt
- - description: NACK Reception Interrupt
- - description: Arbitration-Lost Interrupt
- - description: Timeout Interrupt
+ oneOf:
+ - items:
+ - description: Transmit End Interrupt
+ - description: Receive Data Full Interrupt
+ - description: Transmit Data Empty Interrupt
+ - description: Stop Condition Detection Interrupt
+ - description: Start Condition Detection Interrupt
+ - description: NACK Reception Interrupt
+ - description: Arbitration-Lost Interrupt
+ - description: Timeout Interrupt
+ - items:
+ - description: Transfer Error Or Event Generation
+ - description: Receive Data Full Interrupt
+ - description: Transmit Data Empty Interrupt
+ - description: Transmit End Interrupt
interrupt-names:
- items:
- - const: tei
- - const: ri
- - const: ti
- - const: spi
- - const: sti
- - const: naki
- - const: ali
- - const: tmoi
+ oneOf:
+ - items:
+ - const: tei
+ - const: ri
+ - const: ti
+ - const: spi
+ - const: sti
+ - const: naki
+ - const: ali
+ - const: tmoi
+ - items:
+ - const: eei
+ - const: rxi
+ - const: txi
+ - const: tei
clock-frequency:
description:
@@ -74,17 +99,40 @@ required:
- '#address-cells'
- '#size-cells'
-if:
- properties:
- compatible:
- contains:
- enum:
- - renesas,riic-r9a07g043
- - renesas,riic-r9a07g044
- - renesas,riic-r9a07g054
-then:
- required:
- - resets
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,riic-r9a09g077
+ then:
+ properties:
+ interrupts:
+ maxItems: 4
+ interrupt-names:
+ maxItems: 4
+ resets: false
+ else:
+ properties:
+ interrupts:
+ minItems: 8
+ interrupt-names:
+ minItems: 8
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,riic-r9a07g043
+ - renesas,riic-r9a07g044
+ - renesas,riic-r9a07g054
+ - renesas,riic-r9a09g057
+ then:
+ required:
+ - resets
unevaluatedProperties: false
@@ -94,21 +142,21 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c0: i2c@fcfee000 {
- compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
- reg = <0xfcfee000 0x44>;
- interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 158 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 159 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "tei", "ri", "ti", "spi", "sti", "naki", "ali",
- "tmoi";
- clocks = <&mstp9_clks R7S72100_CLK_I2C0>;
- clock-frequency = <100000>;
- power-domains = <&cpg_clocks>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
+ reg = <0xfcfee000 0x44>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 159 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tei", "ri", "ti", "spi", "sti", "naki", "ali",
+ "tmoi";
+ clocks = <&mstp9_clks R7S72100_CLK_I2C0>;
+ clock-frequency = <100000>;
+ power-domains = <&cpg_clocks>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
index 04e4ffd80bc0..ec5222a1224f 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
+++ b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
@@ -134,16 +134,16 @@ examples:
#include <dt-bindings/power/r8a7790-sysc.h>
iic0: i2c@e6500000 {
- compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
- "renesas,rmobile-iic";
- reg = <0xe6500000 0x425>;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 318>;
- clock-frequency = <400000>;
- dmas = <&dmac0 0x61>, <&dmac0 0x62>, <&dmac1 0x61>, <&dmac1 0x62>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 318>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
+ reg = <0xe6500000 0x425>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 318>;
+ clock-frequency = <400000>;
+ dmas = <&dmac0 0x61>, <&dmac0 0x62>, <&dmac1 0x61>, <&dmac1 0x62>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 318>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml b/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
index c46378efc123..5d1e7885b64a 100644
--- a/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
+++ b/Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/V2M I2C Bus Interface
maintainers:
- - Phil Edworthy <phil.edworthy@renesas.com>
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
@@ -16,7 +16,7 @@ properties:
compatible:
items:
- enum:
- - renesas,i2c-r9a09g011 # RZ/V2M
+ - renesas,r9a09g011-i2c # RZ/V2M
- const: renesas,rzv2m-i2c
reg:
@@ -66,7 +66,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c0: i2c@a4030000 {
- compatible = "renesas,i2c-r9a09g011", "renesas,rzv2m-i2c";
+ compatible = "renesas,r9a09g011-i2c", "renesas,rzv2m-i2c";
reg = <0xa4030000 0x80>;
interrupts = <GIC_SPI 232 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 236 IRQ_TYPE_EDGE_RISING>;
diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
index 3d5782deb97d..a2ddc6803617 100644
--- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
@@ -11,17 +11,20 @@ maintainers:
properties:
compatible:
- enum:
- - samsung,s3c2410-i2c
- - samsung,s3c2440-i2c
- # For s3c2440-like I2C used inside HDMIPHY block found on several SoCs:
- - samsung,s3c2440-hdmiphy-i2c
- # For s3c2440-like I2C used as a host to SATA PHY controller on an
- # internal bus:
- - samsung,exynos5-sata-phy-i2c
-
- '#address-cells':
- const: 1
+ oneOf:
+ - enum:
+ - samsung,s3c2440-i2c
+ # For s3c2440-like I2C used inside HDMIPHY block found on several SoCs:
+ - samsung,s3c2440-hdmiphy-i2c
+ # For s3c2440-like I2C used as a host to SATA PHY controller on an
+ # internal bus:
+ - samsung,exynos5-sata-phy-i2c
+ - items:
+ - enum:
+ - samsung,exynos7870-i2c
+ - samsung,exynos7885-i2c
+ - samsung,exynos850-i2c
+ - const: samsung,s3c2440-i2c
clocks:
maxItems: 1
@@ -37,7 +40,7 @@ properties:
for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
permanently wired to the respective client.
This property is deprecated. Use "pinctrl-0" and "pinctrl-names" instead.
- deprecated: yes
+ deprecated: true
interrupts:
maxItems: 1
@@ -67,9 +70,6 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description: Pandle to syscon used to control the system registers.
- '#size-cells':
- const: 0
-
required:
- compatible
- reg
@@ -92,7 +92,6 @@ allOf:
compatible:
contains:
enum:
- - samsung,s3c2410-i2c
- samsung,s3c2440-i2c
- samsung,s3c2440-hdmiphy-i2c
then:
diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
index d9293c57f573..d904191bb0c6 100644
--- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
@@ -27,12 +27,19 @@ properties:
oneOf:
- description: Generic Synopsys DesignWare I2C controller
const: snps,designware-i2c
- - description: Microsemi Ocelot SoCs I2C controller
+ - description: Renesas RZ/N1D I2C controller
items:
- - const: mscc,ocelot-i2c
+ - const: renesas,r9a06g032-i2c # RZ/N1D
+ - const: renesas,rzn1-i2c # RZ/N1
- const: snps,designware-i2c
- description: Baikal-T1 SoC System I2C controller
const: baikal,bt1-sys-i2c
+ - items:
+ - enum:
+ - mscc,ocelot-i2c
+ - sophgo,sg2044-i2c
+ - thead,th1520-i2c
+ - const: snps,designware-i2c
reg:
minItems: 1
@@ -93,6 +100,22 @@ properties:
- const: tx
- const: rx
+ snps,bus-capacitance-pf:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This property indicates the bus capacitance in picofarads (pF).
+ This value is used to compute the tHIGH and tLOW periods for high speed
+ mode.
+ enum: [100, 400]
+ default: 100
+
+ snps,clk-freq-optimized:
+ description:
+ This property indicates whether the hardware reduce its clock frequency
+ by reducing the internal latency required to generate the high period and
+ low period of SCL line.
+ type: boolean
+
unevaluatedProperties: false
required:
@@ -117,6 +140,8 @@ examples:
i2c-sda-hold-time-ns = <300>;
i2c-sda-falling-time-ns = <300>;
i2c-scl-falling-time-ns = <300>;
+ snps,bus-capacitance-pf = <400>;
+ snps,clk-freq-optimized;
};
- |
i2c@2000 {
diff --git a/Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml b/Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml
new file mode 100644
index 000000000000..f9d6e2038bb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/socionext,synquacer-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext SynQuacer I2C Controller
+
+maintainers:
+ - Ard Biesheuvel <ardb@kernel.org>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: socionext,synquacer-i2c
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pclk
+
+ clock-frequency:
+ minimum: 100000
+ maximum: 400000
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c@51210000 {
+ compatible = "socionext,synquacer-i2c";
+ reg = <0x51210000 0x1000>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "pclk";
+ clocks = <&clk_i2c>;
+ clock-frequency = <400000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml b/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml
index c76131902b77..4bbe9e775da1 100644
--- a/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml
@@ -29,6 +29,9 @@ properties:
minimum: 100000
maximum: 400000
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml b/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml
index ddde08636ab0..5abf496edb59 100644
--- a/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/socionext,uniphier-i2c.yaml
@@ -29,6 +29,9 @@ properties:
minimum: 100000
maximum: 400000
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml b/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml
new file mode 100644
index 000000000000..b7220fff2235
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/spacemit,k1-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C controller embedded in SpacemiT's K1 SoC
+
+maintainers:
+ - Troy Mitchell <troymitchell988@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: I2C Functional Clock
+ - description: APB Bus Clock
+
+ clock-names:
+ items:
+ - const: func
+ - const: bus
+
+ clock-frequency:
+ description: |
+ K1 support three different modes which running different frequencies
+ standard speed mode: up to 100000 (100Hz)
+ fast speed mode : up to 400000 (400Hz)
+ high speed mode : up to 3300000 (3.3Mhz)
+ default: 400000
+ maximum: 3300000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@d4010800 {
+ compatible = "spacemit,k1-i2c";
+ reg = <0xd4010800 0x38>;
+ interrupt-parent = <&plic>;
+ interrupts = <36>;
+ clocks = <&ccu 32>, <&ccu 84>;
+ clock-names = "func", "bus";
+ clock-frequency = <100000>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/i2c/sprd,sc9860-i2c.yaml b/Documentation/devicetree/bindings/i2c/sprd,sc9860-i2c.yaml
new file mode 100644
index 000000000000..ec0d39e73d26
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/sprd,sc9860-i2c.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/sprd,sc9860-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC9860 I2C controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: sprd,sc9860-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: I2C clock
+ - description: I2C source (parent) clock
+ - description: I2C module enable clock
+
+ clock-names:
+ items:
+ - const: i2c
+ - const: source
+ - const: enable
+
+ clock-frequency: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - clock-frequency
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c@70500000 {
+ compatible = "sprd,sc9860-i2c";
+ reg = <0x70500000 0x1000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_i2c3>, <&ext_26m>, <&clk_ap_apb_gates 11>;
+ clock-names = "i2c", "source", "enable";
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml
index 42c5974ec7b0..012402debfeb 100644
--- a/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/st,nomadik-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ST Microelectronics Nomadik I2C Bindings
+title: ST Microelectronics Nomadik I2C
description: The Nomadik I2C host controller began its life in the ST
Microelectronics STn8800 SoC, and was then inherited into STn8810 and
@@ -14,9 +14,6 @@ description: The Nomadik I2C host controller began its life in the ST
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
-allOf:
- - $ref: /schemas/i2c/i2c-controller.yaml#
-
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
@@ -24,17 +21,20 @@ select:
contains:
enum:
- st,nomadik-i2c
+ - mobileye,eyeq5-i2c
+ - mobileye,eyeq6h-i2c
required:
- compatible
properties:
compatible:
oneOf:
- # The variant found in STn8815
- items:
- - const: st,nomadik-i2c
+ - enum:
+ - st,nomadik-i2c
+ - mobileye,eyeq5-i2c
+ - mobileye,eyeq6h-i2c
- const: arm,primecell
- # The variant found in DB8500
- items:
- const: stericsson,db8500-i2c
- const: st,nomadik-i2c
@@ -55,7 +55,7 @@ properties:
- items:
- const: mclk
- const: apb_pclk
- # Clock name in DB8500
+ # Clock name in DB8500 or EyeQ
- items:
- const: i2cclk
- const: apb_pclk
@@ -68,7 +68,17 @@ properties:
clock-frequency:
minimum: 1
- maximum: 400000
+ maximum: 3400000
+
+ mobileye,olb:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to OLB system controller node.
+ - description: Platform-wide controller ID (integer starting from zero).
+ description:
+ The phandle pointing to OLB system controller node, with the I2C
+ controller index.
required:
- compatible
@@ -79,6 +89,20 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mobileye,eyeq5-i2c
+ then:
+ required:
+ - mobileye,olb
+ else:
+ properties:
+ mobileye,olb: false
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
@@ -111,5 +135,19 @@ examples:
clocks = <&i2c0clk>, <&pclki2c0>;
clock-names = "mclk", "apb_pclk";
};
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ i2c@300000 {
+ compatible = "mobileye,eyeq5-i2c", "arm,primecell";
+ reg = <0x300000 0x1000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SHARED 1 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&i2c_ser_clk>, <&i2c_clk>;
+ clock-names = "i2cclk", "apb_pclk";
+ mobileye,olb = <&olb 0>;
+ };
...
diff --git a/Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml
new file mode 100644
index 000000000000..08f9c1e446fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/st,sti-i2c.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/st,sti-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C controller embedded in STMicroelectronics STi platform
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,comms-ssc-i2c
+ - st,comms-ssc4-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ clock-frequency:
+ enum: [ 100000, 400000 ]
+ default: 100000
+
+ st,i2c-min-scl-pulse-width-us:
+ description:
+ The minimum valid SCL pulse width that is allowed through the
+ deglitch circuit. In units of us.
+
+ st,i2c-min-sda-pulse-width-us:
+ description:
+ The minimum valid SDA pulse width that is allowed through the
+ deglitch circuit. In units of us.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ i2c@fed40000 {
+ compatible = "st,comms-ssc4-i2c";
+ reg = <0xfed40000 0x110>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_s_a0_ls CLK_ICN_REG>;
+ clock-names = "ssc";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c0_default>;
+ st,i2c-min-scl-pulse-width-us = <0>;
+ st,i2c-min-sda-pulse-width-us = <5>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
index bf396e9466aa..457bb0702ed9 100644
--- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -19,6 +19,7 @@ allOf:
- st,stm32f7-i2c
- st,stm32mp13-i2c
- st,stm32mp15-i2c
+ - st,stm32mp25-i2c
then:
properties:
i2c-scl-rising-time-ns:
@@ -41,6 +42,30 @@ allOf:
clock-frequency:
enum: [100000, 400000]
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32f4-i2c
+ - st,stm32f7-i2c
+ - st,stm32mp13-i2c
+ - st,stm32mp15-i2c
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+
+ interrupt-names:
+ minItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ maxItems: 1
+
properties:
compatible:
enum:
@@ -48,6 +73,7 @@ properties:
- st,stm32f7-i2c
- st,stm32mp13-i2c
- st,stm32mp15-i2c
+ - st,stm32mp25-i2c
reg:
maxItems: 1
@@ -56,11 +82,13 @@ properties:
items:
- description: interrupt ID for I2C event
- description: interrupt ID for I2C error
+ minItems: 1
interrupt-names:
items:
- const: event
- const: error
+ minItems: 1
resets:
maxItems: 1
@@ -90,7 +118,7 @@ properties:
st,syscfg-fmp:
description: Use to set Fast Mode Plus bit within SYSCFG when Fast Mode
Plus speed is selected by slave.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to syscfg
@@ -99,6 +127,10 @@ properties:
wakeup-source: true
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
@@ -113,31 +145,31 @@ examples:
#include <dt-bindings/mfd/stm32f7-rcc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
//Example 1 (with st,stm32f4-i2c compatible)
- i2c@40005400 {
- compatible = "st,stm32f4-i2c";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x40005400 0x400>;
- interrupts = <31>,
- <32>;
- resets = <&rcc 277>;
- clocks = <&rcc 0 149>;
- };
+ i2c@40005400 {
+ compatible = "st,stm32f4-i2c";
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+ <32>;
+ resets = <&rcc 277>;
+ clocks = <&rcc 0 149>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
- |
#include <dt-bindings/mfd/stm32f7-rcc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
//Example 2 (with st,stm32f7-i2c compatible)
- i2c@40005800 {
- compatible = "st,stm32f7-i2c";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x40005800 0x400>;
- interrupts = <31>,
- <32>;
- resets = <&rcc STM32F7_APB1_RESET(I2C1)>;
- clocks = <&rcc 1 CLK_I2C1>;
- };
+ i2c@40005800 {
+ compatible = "st,stm32f7-i2c";
+ reg = <0x40005800 0x400>;
+ interrupts = <31>,
+ <32>;
+ resets = <&rcc STM32F7_APB1_RESET(I2C1)>;
+ clocks = <&rcc 1 CLK_I2C1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
- |
#include <dt-bindings/mfd/stm32f7-rcc.h>
@@ -146,16 +178,16 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
- i2c@40013000 {
- compatible = "st,stm32mp15-i2c";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x40013000 0x400>;
- interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&rcc I2C2_K>;
- resets = <&rcc I2C2_R>;
- i2c-scl-rising-time-ns = <185>;
- i2c-scl-falling-time-ns = <20>;
- st,syscfg-fmp = <&syscfg 0x4 0x2>;
- };
+ i2c@40013000 {
+ compatible = "st,stm32mp15-i2c";
+ reg = <0x40013000 0x400>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc I2C2_K>;
+ resets = <&rcc I2C2_R>;
+ i2c-scl-rising-time-ns = <185>;
+ i2c-scl-falling-time-ns = <20>;
+ st,syscfg-fmp = <&syscfg 0x4 0x2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
index db0843be91c5..58d32ceeacfc 100644
--- a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i2c/ti,omap4-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for I2C controllers on TI's OMAP and K3 SoCs
+title: I2C controllers on TI's OMAP and K3 SoCs
maintainers:
- Vignesh Raghavendra <vigneshr@ti.com>
@@ -37,16 +37,8 @@ properties:
clock-names:
const: fck
- clock-frequency: true
-
power-domains: true
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
ti,hwmods:
description:
Must be "i2c<n>", n being the instance number (1-based).
@@ -55,38 +47,39 @@ properties:
$ref: /schemas/types.yaml#/definitions/string
deprecated: true
-# subnode's properties
-patternProperties:
- "@[0-9a-f]+$":
- type: object
+ mux-states:
description:
- Flash device uses the below defined properties in the subnode.
+ mux controller node to route the I2C signals from SoC to clients.
+ maxItems: 1
required:
- compatible
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,omap2420-i2c
+ - ti,omap2430-i2c
+ - ti,omap3-i2c
+ - ti,omap4-i2c
-if:
- properties:
- compatible:
- enum:
- - ti,omap2420-i2c
- - ti,omap2430-i2c
- - ti,omap3-i2c
- - ti,omap4-i2c
+ then:
+ properties:
+ ti,hwmods:
+ items:
+ - pattern: "^i2c([1-9])$"
-then:
- properties:
- ti,hwmods:
- items:
- - pattern: "^i2c([1-9])$"
+ else:
+ properties:
+ ti,hwmods: false
-else:
- properties:
- ti,hwmods: false
+unevaluatedProperties: false
examples:
- |
@@ -94,9 +87,10 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
main_i2c0: i2c@2000000 {
- compatible = "ti,j721e-i2c", "ti,omap4-i2c";
- reg = <0x2000000 0x100>;
- interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
+ compatible = "ti,j721e-i2c", "ti,omap4-i2c";
+ reg = <0x2000000 0x100>;
+ interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mux-states = <&i2c_mux 1>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml b/Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml
new file mode 100644
index 000000000000..19cfffb39296
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/tsd,mule-i2c-mux.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/tsd,mule-i2c-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Theobroma Systems Mule I2C multiplexer
+
+maintainers:
+ - Farouk Bouabid <farouk.bouabid@cherry.de>
+ - Quentin Schulz <quentin.schulz@cherry.de>
+
+description: |
+ Theobroma Systems Mule is an MCU that emulates a set of I2C devices, among
+ which devices that are reachable through an I2C-mux. The devices on the mux
+ can be selected by writing the appropriate device number to an I2C config
+ register.
+
+ +--------------------------------------------------+
+ | Mule |
+ 0x18| +---------------+ |
+ -------->|Config register|----+ |
+ | +---------------+ | |
+ | V_ |
+ | | \ +--------+ |
+ | | \-------->| dev #0 | |
+ | | | +--------+ |
+ 0x6f| | M |-------->| dev #1 | |
+ ---------------------------->| U | +--------+ |
+ | | X |-------->| dev #2 | |
+ | | | +--------+ |
+ | | /-------->| dev #3 | |
+ | |__/ +--------+ |
+ +--------------------------------------------------+
+
+allOf:
+ - $ref: /schemas/i2c/i2c-mux.yaml#
+
+properties:
+ compatible:
+ const: tsd,mule-i2c-mux
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c-mux {
+ compatible = "tsd,mule-i2c-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6f {
+ compatible = "isil,isl1208";
+ reg = <0x6f>;
+ };
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml b/Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml
new file mode 100644
index 000000000000..e498ce47b885
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/wm,wm8505-i2c.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/wm,wm8505-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C Controller on WonderMedia WM8505 and related SoCs
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: wm,wm8505-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ enum: [100000, 400000]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c_0: i2c@d8280000 {
+ compatible = "wm,wm8505-i2c";
+ reg = <0xd8280000 0x1000>;
+ interrupts = <19>;
+ clocks = <&clki2c0>;
+ clock-frequency = <400000>;
+ };
diff --git a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
index 715dcfa5a922..658ae92fa86d 100644
--- a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+++ b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/i2c/xlnx,xps-iic-2.00.a.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/i2c/xlnx,xps-iic-2.00.a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx IIC controller Device Tree Bindings
+title: Xilinx IIC controller
maintainers:
- info@mocean-labs.com
@@ -14,7 +14,9 @@ allOf:
properties:
compatible:
- const: xlnx,xps-iic-2.00.a
+ enum:
+ - xlnx,axi-iic-2.1
+ - xlnx,xps-iic-2.00.a
reg:
maxItems: 1
@@ -30,6 +32,13 @@ properties:
description: |
Input clock name.
+ clock-frequency:
+ description:
+ Optional I2C SCL clock frequency. If not specified, do not configure
+ in software, rely only on hardware design value.
+ default: 100000
+ enum: [ 100000, 400000, 1000000 ]
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/i3c/adi,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/adi,i3c-master.yaml
new file mode 100644
index 000000000000..2498672d2654
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/adi,i3c-master.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/adi,i3c-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices I3C Controller
+
+description:
+ FPGA-based I3C controller designed to interface with I3C and I2C peripherals,
+ implementing a subset of the I3C-basic specification. The IP core is tested
+ on arm, microblaze, and arm64 architectures.
+
+ https://analogdevicesinc.github.io/hdl/library/i3c_controller
+
+maintainers:
+ - Jorge Marques <jorge.marques@analog.com>
+
+properties:
+ compatible:
+ const: adi,i3c-master-v1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: The AXI interconnect clock, drives the register map.
+ - description:
+ The secondary clock, drives the internal logic asynchronously to the
+ register map. The presence of this entry states that the IP Core was
+ synthesized with a second clock input, and the absence of this entry
+ indicates a topology where a single clock input drives all the
+ internal logic.
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: axi
+ - const: i3c
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+allOf:
+ - $ref: i3c.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i3c@44a00000 {
+ compatible = "adi,i3c-master-v1";
+ reg = <0x44a00000 0x1000>;
+ interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc 15>, <&clkc 15>;
+ clock-names = "axi", "i3c";
+ #address-cells = <3>;
+ #size-cells = <0>;
+
+ /* I3C and I2C devices */
+ };
diff --git a/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml
new file mode 100644
index 000000000000..47be5d9a32d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/aspeed,ast2600-i3c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 i3c controller
+
+maintainers:
+ - Jeremy Kerr <jk@codeconstruct.com.au>
+
+allOf:
+ - $ref: i3c.yaml#
+
+properties:
+ compatible:
+ const: aspeed,ast2600-i3c
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ sda-pullup-ohms:
+ enum: [545, 750, 2000]
+ default: 2000
+ description: |
+ Value to configure SDA pullup resistor, in Ohms.
+
+ aspeed,global-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to i3c global register syscon node
+ - description: index of this i3c controller in the global register set
+ description: |
+ A (phandle, controller index) reference to the i3c global register set
+ used for this device.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - aspeed,global-regs
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i3c@2000 {
+ compatible = "aspeed,ast2600-i3c";
+ reg = <0x2000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ clocks = <&syscon 0>;
+ resets = <&syscon 0>;
+ aspeed,global-regs = <&i3c_global 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c1_default>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml
index cc40d25358ec..6fa3078074d0 100644
--- a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml
@@ -14,7 +14,12 @@ allOf:
properties:
compatible:
- const: cdns,i3c-master
+ oneOf:
+ - const: cdns,i3c-master
+ - items:
+ - enum:
+ - axiado,ax3000-i3c
+ - const: cdns,i3c-master
reg:
maxItems: 1
@@ -41,7 +46,7 @@ unevaluatedProperties: false
examples:
- |
- i3c-master@d040000 {
+ i3c@d040000 {
compatible = "cdns,i3c-master";
clocks = <&coreclock>, <&i3csysclock>;
clock-names = "pclk", "sysclk";
diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
index 1f82fc923799..e25fa72fd785 100644
--- a/Documentation/devicetree/bindings/i3c/i3c.yaml
+++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/i3c/i3c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: I3C bus binding
+title: I3C bus
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
@@ -17,7 +17,7 @@ description: |
properties:
$nodename:
- pattern: "^i3c-master@[0-9a-f]+$"
+ pattern: "^i3c@[0-9a-f]+$"
"#address-cells":
const: 3
@@ -55,6 +55,12 @@ properties:
May not be supported by all controllers.
+ mctp-controller:
+ type: boolean
+ description: |
+ Indicates that the system is accessible via this bus as an endpoint for
+ MCTP over I3C transport.
+
required:
- "#address-cells"
- "#size-cells"
@@ -65,7 +71,7 @@ patternProperties:
description: |
I2C child, should be named: <device-type>@<i2c-address>
- All properties described in Documentation/devicetree/bindings/i2c/i2c.txt
+ All properties described in dtschema schemas/i2c/i2c-controller.yaml
are valid here, except the reg property whose content is changed.
properties:
@@ -85,6 +91,7 @@ patternProperties:
- const: 0
- description: |
Shall encode the I3C LVR (Legacy Virtual Register):
+ See include/dt-bindings/i3c/i3c.h
bit[31:8]: unused/ignored
bit[7:5]: I2C device index. Possible values:
* 0: I2C device has a 50 ns spike filter
@@ -119,12 +126,12 @@ patternProperties:
minimum: 0
maximum: 0x7f
- description: |
- First half of the Provisional ID (following the PID
+ First half of the Provisioned ID (following the PID
definition provided by the I3C specification).
Contains the manufacturer ID left-shifted by 1.
- description: |
- Second half of the Provisional ID (following the PID
+ Second half of the Provisioned ID (following the PID
definition provided by the I3C specification).
Contains the ORing of the part ID left-shifted by 16,
@@ -135,9 +142,10 @@ patternProperties:
minimum: 0x1
maximum: 0xff
description: |
- Dynamic address to be assigned to this device. This property is only
- valid if the I3C device has a static address (first cell of the reg
- property != 0).
+ Dynamic address to be assigned to this device. In case static address is
+ present (first cell of the reg property != 0), this address is assigned
+ through SETDASA. If static address is not present, this address is assigned
+ through SETNEWDA after assigning a temporary address via ENTDAA.
required:
- reg
@@ -146,7 +154,9 @@ additionalProperties: true
examples:
- |
- i3c-master@d040000 {
+ #include <dt-bindings/i3c/i3c.h>
+
+ i3c@d040000 {
compatible = "cdns,i3c-master";
clocks = <&coreclock>, <&i3csysclock>;
clock-names = "pclk", "sysclk";
@@ -159,16 +169,22 @@ examples:
/* I2C device. */
eeprom@57 {
compatible = "atmel,24c01";
- reg = <0x57 0x0 0x10>;
+ reg = <0x57 0x0 (I2C_FM | I2C_FILTER)>;
pagesize = <0x8>;
};
- /* I3C device with a static I2C address. */
+ /* I3C device with a static I2C address and assigned address. */
thermal_sensor: sensor@68,39200144004 {
reg = <0x68 0x392 0x144004>;
assigned-address = <0xa>;
};
+ /* I3C device with only assigned address. */
+ pressure_sensor: sensor@0,39200124004 {
+ reg = <0x0 0x392 0x124000>;
+ assigned-address = <0xc>;
+ };
+
/*
* I3C device without a static I2C address but requiring
* resources described in the DT.
diff --git a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
index 04da001fc6ec..39bb1a1784c9 100644
--- a/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
+++ b/Documentation/devicetree/bindings/i3c/mipi-i3c-hci.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/i3c/mipi-i3c-hci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MIPI I3C HCI Device Tree Bindings
+title: MIPI I3C HCI
maintainers:
- Nicolas Pitre <npitre@baylibre.com>
@@ -43,7 +43,7 @@ unevaluatedProperties: false
examples:
- |
- i3c-master@a0000000 {
+ i3c@a0000000 {
compatible = "mipi-i3c-hci";
reg = <0xa0000000 0x2000>;
interrupts = <89>;
diff --git a/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml b/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml
new file mode 100644
index 000000000000..a20d875086d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml
@@ -0,0 +1,185 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/renesas,i3c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas I3C Bus Interface
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+ - Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a08g045-i3c # RZ/G3S
+ - renesas,r9a09g047-i3c # RZ/G3E
+ - items:
+ - enum:
+ - renesas,r9a09g056-i3c # RZ/V2N
+ - renesas,r9a09g057-i3c # RZ/V2H(P)
+ - const: renesas,r9a09g047-i3c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Non-recoverable internal error interrupt
+ - description: Normal transfer error interrupt
+ - description: Normal transfer abort interrupt
+ - description: Normal response status buffer full interrupt
+ - description: Normal command buffer empty interrupt
+ - description: Normal IBI status buffer full interrupt
+ - description: Normal Rx data buffer full interrupt
+ - description: Normal Tx data buffer empty interrupt
+ - description: Normal receive status buffer full interrupt
+ - description: START condition detection interrupt
+ - description: STOP condition detection interrupt
+ - description: Transmit end interrupt
+ - description: NACK detection interrupt
+ - description: Arbitration lost interrupt
+ - description: Timeout detection interrupt
+ - description: Wake-up condition detection interrupt
+ - description: HDR Exit Pattern detection interrupt
+ minItems: 16
+
+ interrupt-names:
+ items:
+ - const: ierr
+ - const: terr
+ - const: abort
+ - const: resp
+ - const: cmd
+ - const: ibi
+ - const: rx
+ - const: tx
+ - const: rcv
+ - const: st
+ - const: sp
+ - const: tend
+ - const: nack
+ - const: al
+ - const: tmo
+ - const: wu
+ - const: exit
+ minItems: 16
+
+ clocks:
+ items:
+ - description: APB bus clock
+ - description: transfer clock
+ - description: SFRs clock
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: tclk
+ - const: pclkrw
+ minItems: 2
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: Reset signal
+ - description: APB interface reset signal/SCAN reset signal
+
+ reset-names:
+ items:
+ - const: presetn
+ - const: tresetn
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clock-names
+ - clocks
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: i3c.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a08g045-i3c
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+ interrupts:
+ minItems: 17
+ interrupt-names:
+ minItems: 17
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g047-i3c
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
+ interrupts:
+ maxItems: 16
+ interrupt-names:
+ maxItems: 16
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a08g045-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i3c@1005b000 {
+ compatible = "renesas,r9a08g045-i3c";
+ reg = <0x1005b000 0x1000>;
+ clocks = <&cpg CPG_MOD R9A08G045_I3C_PCLK>,
+ <&cpg CPG_MOD R9A08G045_I3C_TCLK>;
+ clock-names = "pclk", "tclk";
+ interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 293 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 294 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 295 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 296 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 297 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 298 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 299 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "ierr", "terr", "abort", "resp",
+ "cmd", "ibi", "rx", "tx", "rcv",
+ "st", "sp", "tend", "nack",
+ "al", "tmo", "wu", "exit";
+ resets = <&cpg R9A08G045_I3C_PRESETN>,
+ <&cpg R9A08G045_I3C_TRESETN>;
+ reset-names = "presetn", "tresetn";
+ power-domains = <&cpg>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
index 62f3ca66274f..853092f7522d 100644
--- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
+++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml
@@ -9,12 +9,17 @@ title: Silvaco I3C master
maintainers:
- Conor Culhane <conor.culhane@silvaco.com>
-allOf:
- - $ref: "i3c.yaml#"
-
properties:
compatible:
- const: silvaco,i3c-master-v1
+ oneOf:
+ - enum:
+ - nuvoton,npcm845-i3c
+ - silvaco,i3c-master-v1
+ - items:
+ - enum:
+ - nxp,imx94-i3c
+ - nxp,imx95-i3c
+ - const: silvaco,i3c-master-v1
reg:
maxItems: 1
@@ -23,12 +28,14 @@ properties:
maxItems: 1
clocks:
+ minItems: 2
items:
- description: system clock
- description: bus clock
- description: other (slower) events clock
clock-names:
+ minItems: 2
items:
- const: pclk
- const: fast_clk
@@ -44,11 +51,39 @@ required:
- clock-names
- clocks
-additionalProperties: true
+allOf:
+ - $ref: i3c.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - nuvoton,npcm845-i3c
+ - silvaco,i3c-master-v1
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,imx94-i3c
+ - nxp,imx95-i3c
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+
+unevaluatedProperties: false
examples:
- |
- i3c-master@a0000000 {
+ i3c@a0000000 {
compatible = "silvaco,i3c-master-v1";
clocks = <&zynqmp_clk 71>, <&fclk>, <&sclk>;
clock-names = "pclk", "fast_clk", "slow_clk";
diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
index 7a76fd32962a..e803457d3f55 100644
--- a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
+++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
@@ -14,17 +14,33 @@ allOf:
properties:
compatible:
- const: snps,dw-i3c-master-1.00a
+ oneOf:
+ - const: snps,dw-i3c-master-1.00a
+ - items:
+ - const: altr,agilex5-dw-i3c-master
+ - const: snps,dw-i3c-master-1.00a
reg:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Core clock
+ - description: APB clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: apb
interrupts:
maxItems: 1
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -35,7 +51,7 @@ unevaluatedProperties: false
examples:
- |
- i3c-master@2000 {
+ i3c@2000 {
compatible = "snps,dw-i3c-master-1.00a";
#address-cells = <3>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml
index 6f8f8a6258fe..b6ba7ad1a8d5 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml
@@ -27,20 +27,21 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
-
vdd-supply: true
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
index 8d829ef878bc..a92e153705f3 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADIS16240 Programmable Impact Sensor and Recorder driver
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description: |
ADIS16240 Programmable Impact Sensor and Recorder driver that supports
@@ -25,20 +26,20 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
-
required:
- compatible
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml
index d6afc1b8c272..3a8c69eecfde 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl313.yaml
@@ -4,28 +4,30 @@
$id: http://devicetree.org/schemas/iio/accel/adi,adxl313.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices ADXL313 3-Axis Digital Accelerometer
+title: Analog Devices ADXL312, ADXL313, and ADXL314 3-Axis Digital Accelerometers
maintainers:
- Lucas Stankus <lucas.p.stankus@gmail.com>
description: |
- Analog Devices ADXL313 3-Axis Digital Accelerometer that supports
- both I2C & SPI interfaces.
+ Analog Devices ADXL312, ADXL313, and ADXL314 3-Axis Digital Accelerometer that
+ support both I2C & SPI interfaces.
+ https://www.analog.com/en/products/adxl312.html
https://www.analog.com/en/products/adxl313.html
+ https://www.analog.com/en/products/adxl314.html
properties:
compatible:
enum:
+ - adi,adxl312
- adi,adxl313
+ - adi,adxl314
reg:
maxItems: 1
spi-3wire: true
- spi-max-frequency: true
-
vs-supply:
description: Regulator that supplies power to the accelerometer
@@ -48,13 +50,15 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -68,7 +72,6 @@ examples:
};
};
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
index 9bb039e2f533..61d7ba89adc2 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
@@ -32,23 +32,34 @@ properties:
spi-cpol: true
- spi-max-frequency: true
+ spi-3wire: true
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - enum: [INT1, INT2]
+ - const: INT2
+
+dependencies:
+ interrupts: [ interrupt-names ]
required:
- compatible
- reg
- - interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -58,12 +69,12 @@ examples:
reg = <0x2a>;
interrupt-parent = <&gpio0>;
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "INT1";
};
};
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -75,6 +86,8 @@ examples:
spi-cpol;
spi-cpha;
interrupt-parent = <&gpio0>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>,
+ <1 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "INT1", "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml
index ba54d6998f2e..f39e2912731f 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl355.yaml
@@ -4,20 +4,22 @@
$id: http://devicetree.org/schemas/iio/accel/adi,adxl355.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices ADXL355 3-Axis, Low noise MEMS Accelerometer
+title: Analog Devices ADXL355 and ADXL359 3-Axis, Low noise MEMS Accelerometers
maintainers:
- Puranjay Mohan <puranjay12@gmail.com>
description: |
- Analog Devices ADXL355 3-Axis, Low noise MEMS Accelerometer that supports
- both I2C & SPI interfaces
+ Analog Devices ADXL355 and ADXL359 3-Axis, Low noise MEMS Accelerometers that
+ support both I2C & SPI interfaces
https://www.analog.com/en/products/adxl355.html
+ https://www.analog.com/en/products/adxl359.html
properties:
compatible:
enum:
- adi,adxl355
+ - adi,adxl359
reg:
maxItems: 1
@@ -45,44 +47,43 @@ properties:
vddio-supply:
description: Regulator that provides power to the bus
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
- /* Example for a I2C device node */
- accelerometer@1d {
- compatible = "adi,adxl355";
- reg = <0x1d>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "DRDY";
- };
+ /* Example for a I2C device node */
+ accelerometer@1d {
+ compatible = "adi,adxl355";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "DRDY";
};
+ };
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- accelerometer@0 {
- compatible = "adi,adxl355";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "DRDY";
- };
+ accelerometer@0 {
+ compatible = "adi,adxl355";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "DRDY";
};
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml
index d259e796c1d6..f10d98d34cb8 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml
@@ -35,8 +35,6 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
-
vdd-supply: true
vddio-supply: true
@@ -45,7 +43,10 @@ required:
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
index 38b59b6454ce..0ba0df46c3a9 100644
--- a/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
maintainers:
- - Stefan Popa <stefan.popa@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description: |
Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer that supports
@@ -25,43 +26,42 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
-
required:
- compatible
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
- /* Example for a I2C device node */
- accelerometer@53 {
- compatible = "adi,adxl372";
- reg = <0x53>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- };
+ /* Example for a I2C device node */
+ accelerometer@53 {
+ compatible = "adi,adxl372";
+ reg = <0x53>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
};
+ };
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- accelerometer@0 {
- compatible = "adi,adxl372";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- };
+ accelerometer@0 {
+ compatible = "adi,adxl372";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
};
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml
new file mode 100644
index 000000000000..ab517720a6a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl380.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/adi,adxl380.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADXL380/382 3-Axis Digital Accelerometer
+
+maintainers:
+ - Ramona Gradinariu <ramona.gradinariu@analog.com>
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description: |
+ The ADXL380/ADXL382 and ADXL318/ADXL319 are low noise density,
+ low power, 3-axis accelerometers with selectable measurement ranges.
+ The ADXL380 and ADXL318 support the ±4 g, ±8 g, and ±16 g ranges,
+ while the ADXL382 and ADXL319 support ±15 g, ±30 g, and ±60 g ranges.
+
+ https://www.analog.com/en/products/adxl318.html
+ https://www.analog.com/en/products/adxl380.html
+
+properties:
+ compatible:
+ enum:
+ - adi,adxl318
+ - adi,adxl319
+ - adi,adxl380
+ - adi,adxl382
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - enum: [INT0, INT1]
+ - const: INT1
+
+ vddio-supply: true
+
+ vsupply-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - vddio-supply
+ - vsupply-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@54 {
+ compatible = "adi,adxl380";
+ reg = <0x54>;
+ vddio-supply = <&vddio>;
+ vsupply-supply = <&vsupply>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "INT0";
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@0 {
+ compatible = "adi,adxl380";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+ vddio-supply = <&vddio>;
+ vsupply-supply = <&vsupply>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "INT0";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml
index 942b23ad0712..8c820c27f781 100644
--- a/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/accel/bosch,bma220.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bosch BMA220 Trixial Acceleration Sensor
+title: Bosch BMA220 Triaxial Acceleration Sensor
maintainers:
- Jonathan Cameron <Jonathan.Cameron@huawei.com>
@@ -20,7 +20,8 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
+ spi-cpha: true
+ spi-cpol: true
vdda-supply: true
vddd-supply: true
@@ -30,12 +31,15 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -43,8 +47,10 @@ examples:
compatible = "bosch,bma220";
reg = <0>;
spi-max-frequency = <2500000>;
+ spi-cpol;
+ spi-cpha;
interrupt-parent = <&gpio0>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml
index 478e75ae0885..85c9537f1f02 100644
--- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml
@@ -72,7 +72,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -104,7 +107,6 @@ examples:
};
};
- |
- # include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml
index 8723a336229e..c5fedcf998f2 100644
--- a/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml
@@ -40,7 +40,6 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml
index 272eb48eef5a..3cb82576d758 100644
--- a/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml
@@ -24,8 +24,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vdd-supply: true
vddio-supply: true
@@ -50,7 +48,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml
index 9c7c66feeffc..cb31e75ba680 100644
--- a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml
@@ -36,16 +36,17 @@ properties:
maxItems: 2
items:
enum:
- - "INT1"
- - "INT2"
-
- spi-max-frequency: true
+ - INT1
+ - INT2
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
new file mode 100644
index 000000000000..f07c70e51c45
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/kionix,kx022a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM/Kionix KX022A, KX132/134-1211 and KX132/134ACR-LBZ Accelerometers
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ KX022A, KX132ACR-LBZ and KX132-1211 are 3-axis accelerometers supporting
+ +/- 2G, 4G, 8G and 16G ranges. The KX134ACR-LBZ and KX134-1211 support
+ +/- 8G, 16G, 32G and 64G. All the sensors also have variable output
+ data-rates and a hardware-fifo buffering. These accelerometers can be
+ accessed either via I2C or SPI.
+
+properties:
+ compatible:
+ enum:
+ - kionix,kx022a
+ - kionix,kx132-1211
+ - kionix,kx134-1211
+ - rohm,kx132acr-lbz
+ - rohm,kx134acr-lbz
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - enum: [INT1, INT2]
+ - const: INT2
+
+ vdd-supply: true
+ io-vdd-supply: true
+
+ mount-matrix:
+ description: |
+ an optional 3x3 mounting rotation matrix.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ accel@1f {
+ compatible = "kionix,kx022a";
+ reg = <0x1f>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "INT1";
+
+ io-vdd-supply = <&iovdd>;
+ vdd-supply = <&vdd>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
index 714e48e613de..951a3a2ba8fc 100644
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml
@@ -16,6 +16,7 @@ properties:
- kionix,kxcj91008
- kionix,kxtj21009
- kionix,kxtf9
+ - kionix,kx022-1020
- kionix,kx023-1025
reg:
@@ -44,7 +45,7 @@ examples:
accel@f {
compatible = "kionix,kxtf9";
- reg = <0x0F>;
+ reg = <0xf>;
mount-matrix = "0", "1", "0",
"1", "0", "0",
"0", "0", "1";
diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml
index 390b87242fcb..53de921768ac 100644
--- a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml
@@ -29,13 +29,14 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix.
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -56,7 +57,6 @@ examples:
};
};
- |
- # include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt
index 764e28ec1a0a..457539647f36 100644
--- a/Documentation/devicetree/bindings/iio/accel/lis302.txt
+++ b/Documentation/devicetree/bindings/iio/accel/lis302.txt
@@ -36,7 +36,7 @@ Optional properties for all bus drivers:
- st,irq{1,2}-disable: disable IRQ 1/2
- st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
- st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
- - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
+ - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready condition
- st,irq{1,2}-click: raise IRQ 1/2 on click condition
- st,irq-open-drain: consider IRQ lines open-drain
- st,irq-active-low: make IRQ lines active low
diff --git a/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml b/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
new file mode 100644
index 000000000000..d530ec041fe7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/memsensing,msa311.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MEMSensing digital 3-Axis accelerometer
+
+maintainers:
+ - Dmitry Rokosov <ddrokosov@sberdevices.ru>
+
+description: |
+ MSA311 is a tri-axial, low-g accelerometer with I2C digital output for
+ sensitivity consumer applications. It has dynamical user selectable full
+ scales range of +-2g/+-4g/+-8g/+-16g and allows acceleration measurements
+ with output data rates from 1Hz to 1000Hz.
+ Datasheet can be found at following URL
+ https://cdn-shop.adafruit.com/product-files/5309/MSA311-V1.1-ENG.pdf
+
+properties:
+ compatible:
+ const: memsensing,msa311
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@62 {
+ compatible = "memsensing,msa311";
+ reg = <0x62>;
+ interrupt-parent = <&gpio_intc>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <&vcc_5v>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml
index f6e2a16a710b..00c990caa1e4 100644
--- a/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml
@@ -29,7 +29,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml
index ad529ab2c6e2..c175f4c4cbdb 100644
--- a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml
+++ b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml
@@ -14,12 +14,20 @@ description: |
SPI and I2C interface.
https://www.nxp.com/docs/en/data-sheet/FXLS8962AF.pdf
https://www.nxp.com/docs/en/data-sheet/FXLS8964AF.pdf
+ https://www.nxp.com/docs/en/data-sheet/FXLS8967AF.pdf
+ https://www.nxp.com/docs/en/data-sheet/FXLS8974CF.pdf
properties:
compatible:
- enum:
- - nxp,fxls8962af
- - nxp,fxls8964af
+ oneOf:
+ - enum:
+ - nxp,fxls8962af
+ - nxp,fxls8964af
+ - items:
+ - enum:
+ - nxp,fxls8967af
+ - nxp,fxls8974cf
+ - const: nxp,fxls8962af
reg:
maxItems: 1
@@ -27,8 +35,6 @@ properties:
vdd-supply:
description: phandle to the regulator that provides power to the accelerometer
- spi-max-frequency: true
-
interrupts:
maxItems: 1
@@ -40,16 +46,24 @@ properties:
drive-open-drain:
type: boolean
+ wakeup-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable wake on accelerometer event
+
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -60,11 +74,12 @@ examples:
interrupt-parent = <&gpio0>;
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "INT1";
+ wakeup-source;
};
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index db348fcbb52c..b9bc02b5b07a 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic IIO bindings for ADC channels
+title: IIO Common Properties for ADC Channels
maintainers:
- Jonathan Cameron <jic23@kernel.org>
@@ -22,7 +22,6 @@ properties:
maxItems: 1
label:
- $ref: /schemas/types.yaml#/definitions/string
description: Unique name to identify which channel this is.
bipolar:
@@ -38,6 +37,29 @@ properties:
to both the positive and negative inputs of a differential ADC.
The first value specifies the positive input pin, the second
specifies the negative input pin.
+ There are also some ADCs, where the differential channel has dedicated
+ positive and negative inputs which can be used to measure differential
+ voltage levels. For those setups, this property can be configured with
+ the 'reg' property for both inputs (i.e. diff-channels = <reg reg>).
+
+ single-channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When devices combine single-ended and differential channels, allow the
+ channel for a single element to be specified, independent of reg (as for
+ differential channels). If this and diff-channels are not present reg
+ shall be used instead.
+
+ common-mode-channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Some ADCs have differential input pins that can be used to measure
+ single-ended or pseudo-differential inputs. This property can be used
+ in addition to single-channel to signal software that this channel is
+ not differential but still specify two inputs.
+
+ The input pair is specified by setting single-channel to the positive
+ input pin and common-mode-channel to the negative pin.
settling-time-us:
description:
@@ -51,4 +73,15 @@ properties:
device design and can interact with other characteristics such as
settling time.
+anyOf:
+ - oneOf:
+ - required:
+ - reg
+ - diff-channels
+ - required:
+ - reg
+ - single-channel
+ - required:
+ - reg
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml
new file mode 100644
index 000000000000..96e01a97dd95
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml
@@ -0,0 +1,246 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD4000 and similar Analog to Digital Converters
+
+maintainers:
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+
+description: |
+ Analog Devices AD4000 family of Analog to Digital Converters with SPI support.
+ Specifications can be found at:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4000-4004-4008.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4001-4005.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4002-4006-4010.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4003-4007-4011.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4020-4021-4022.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4001.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/adaq4003.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7685.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7686.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7687.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7688.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7690.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7691.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7693.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7942.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7946.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7980.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7982.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7983.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7984.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7988-1_7988-5.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - adi,ad4000
+ - adi,ad4001
+ - adi,ad4002
+ - adi,ad4003
+ - adi,ad4020
+ - adi,adaq4001
+ - adi,adaq4003
+ - adi,ad7687
+ - adi,ad7691
+ - adi,ad7942
+ - adi,ad7946
+ - adi,ad7983
+ - items:
+ - enum:
+ - adi,ad4004
+ - adi,ad4008
+ - const: adi,ad4000
+ - items:
+ - enum:
+ - adi,ad4005
+ - const: adi,ad4001
+ - items:
+ - enum:
+ - adi,ad4006
+ - adi,ad4010
+ - const: adi,ad4002
+ - items:
+ - enum:
+ - adi,ad4007
+ - adi,ad4011
+ - const: adi,ad4003
+ - items:
+ - enum:
+ - adi,ad4021
+ - adi,ad4022
+ - const: adi,ad4020
+ - items:
+ - enum:
+ - adi,ad7685
+ - adi,ad7686
+ - adi,ad7980
+ - adi,ad7988-1
+ - adi,ad7988-5
+ - const: adi,ad7983
+ - items:
+ - enum:
+ - adi,ad7688
+ - adi,ad7693
+ - const: adi,ad7687
+ - items:
+ - enum:
+ - adi,ad7690
+ - adi,ad7982
+ - adi,ad7984
+ - const: adi,ad7691
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 102040816 # for VIO > 2.7 V, 81300813 for VIO > 1.7 V
+
+ adi,sdi-pin:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ high, low, cs, sdi ]
+ default: sdi
+ description:
+ Describes how the ADC SDI pin is wired. A value of "sdi" indicates that
+ the ADC SDI is connected to host SDO. "high" indicates that the ADC SDI
+ pin is hard-wired to logic high (VIO). "low" indicates that it is
+ hard-wired low (GND). "cs" indicates that the ADC SDI pin is connected to
+ the host CS line.
+
+ '#daisy-chained-devices': true
+
+ vdd-supply:
+ description: A 1.8V supply that powers the chip (VDD).
+
+ vio-supply:
+ description:
+ A 1.8V to 5.5V supply for the digital inputs and outputs (VIO).
+
+ ref-supply:
+ description:
+ A 2.5 to 5V supply for the external reference voltage (REF).
+
+ cnv-gpios:
+ description:
+ When provided, this property indicates the GPIO that is connected to the
+ CNV pin.
+ maxItems: 1
+
+ adi,high-z-input:
+ type: boolean
+ description:
+ High-Z mode allows the amplifier and RC filter in front of the ADC to be
+ chosen based on the signal bandwidth of interest, rather than the settling
+ requirements of the switched capacitor SAR ADC inputs.
+
+ adi,gain-milli:
+ description: |
+ The hardware gain applied to the ADC input (in milli units).
+ The gain provided by the ADC input scaler is defined by the hardware
+ connections between chip pins OUT+, R1K-, R1K1-, R1K+, R1K1+, and OUT-.
+ If not present, default to 1000 (no actual gain applied).
+ $ref: /schemas/types.yaml#/definitions/uint16
+ enum: [454, 909, 1000, 1900]
+ default: 1000
+
+ interrupts:
+ description:
+ The SDO pin can also function as a busy indicator. This node should be
+ connected to an interrupt that is triggered when the SDO line goes low
+ while the SDI line is high and the CNV line is low ("3-wire" mode) or the
+ SDI line is low and the CNV line is high ("4-wire" mode); or when the SDO
+ line goes high while the SDI and CNV lines are high (chain mode),
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vio-supply
+ - ref-supply
+
+allOf:
+ # Single-channel PulSAR devices have SDI either tied to VIO, GND, or host CS.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7687
+ - adi,ad7691
+ - adi,ad7942
+ - adi,ad7946
+ - adi,ad7983
+ then:
+ properties:
+ adi,sdi-pin:
+ enum: [ high, low, cs ]
+ default: cs
+ # The configuration register can only be accessed if SDI is connected to MOSI
+ - if:
+ required:
+ - adi,sdi-pin
+ then:
+ properties:
+ adi,high-z-input: false
+ # chain mode has lower SCLK max rate
+ - if:
+ required:
+ - '#daisy-chained-devices'
+ then:
+ properties:
+ spi-max-frequency:
+ maximum: 50000000 # for VIO > 2.7 V, 40000000 for VIO > 1.7 V
+ # Gain property only applies to ADAQ devices
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - adi,adaq4001
+ - adi,adaq4003
+ then:
+ properties:
+ adi,gain-milli: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc@0 {
+ compatible = "adi,ad4020";
+ reg = <0>;
+ spi-max-frequency = <71000000>;
+ vdd-supply = <&supply_1_8V>;
+ vio-supply = <&supply_1_8V>;
+ ref-supply = <&supply_5V>;
+ adi,sdi-pin = "cs";
+ cnv-gpios = <&gpio0 88 GPIO_ACTIVE_HIGH>;
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc@0 {
+ compatible = "adi,adaq4003";
+ reg = <0>;
+ spi-max-frequency = <80000000>;
+ vdd-supply = <&supply_1_8V>;
+ vio-supply = <&supply_1_8V>;
+ ref-supply = <&supply_5V>;
+ adi,high-z-input;
+ adi,gain-milli = /bits/ 16 <454>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
new file mode 100644
index 000000000000..54e7349317b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2024 Analog Devices Inc.
+# Copyright 2024 BayLibre, SAS.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD4030 and AD4630 ADC families
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+ - Nuno Sa <nuno.sa@analog.com>
+
+description: |
+ Analog Devices AD4030 single channel and AD4630/AD4632 dual channel precision
+ SAR ADC families
+
+ * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4030-24-4032-24.pdf
+ * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-24_ad4632-24.pdf
+ * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-16-4632-16.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4030-24
+ - adi,ad4032-24
+ - adi,ad4630-16
+ - adi,ad4630-24
+ - adi,ad4632-16
+ - adi,ad4632-24
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 102040816
+
+ spi-rx-bus-width:
+ enum: [1, 2, 4]
+
+ vdd-5v-supply: true
+ vdd-1v8-supply: true
+ vio-supply: true
+
+ ref-supply:
+ description:
+ Optional External unbuffered reference. Used when refin-supply is not
+ connected.
+
+ refin-supply:
+ description:
+ Internal buffered Reference. Used when ref-supply is not connected.
+
+ cnv-gpios:
+ description:
+ The Convert Input (CNV). It initiates the sampling conversions.
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ The Reset Input (/RST). Used for asynchronous device reset.
+ maxItems: 1
+
+ interrupts:
+ description:
+ The BUSY pin is used to signal that the conversions results are available
+ to be transferred when in SPI Clocking Mode. This nodes should be
+ connected to an interrupt that is triggered when the BUSY line goes low.
+ maxItems: 1
+
+ interrupt-names:
+ const: busy
+
+required:
+ - compatible
+ - reg
+ - vdd-5v-supply
+ - vdd-1v8-supply
+ - vio-supply
+ - cnv-gpios
+
+oneOf:
+ - required:
+ - ref-supply
+ - required:
+ - refin-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4030-24";
+ reg = <0>;
+ spi-max-frequency = <80000000>;
+ vdd-5v-supply = <&supply_5V>;
+ vdd-1v8-supply = <&supply_1_8V>;
+ vio-supply = <&supply_1_8V>;
+ ref-supply = <&supply_5V>;
+ cnv-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
new file mode 100644
index 000000000000..ccd6a0ac1539
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4080.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD4080 20-Bit, 40 MSPS, Differential SAR ADC
+
+maintainers:
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description: |
+ The AD4080 is a high speed, low noise, low distortion, 20-bit, Easy Drive,
+ successive approximation register (SAR) analog-to-digital converter (ADC).
+ Maintaining high performance (signal-to-noise and distortion (SINAD) ratio
+ > 90 dBFS) at signal frequencies in excess of 1 MHz enables the AD4080 to
+ service a wide variety of precision, wide bandwidth data acquisition
+ applications.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4080.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4080
+ - adi,ad4081
+ - adi,ad4083
+ - adi,ad4084
+ - adi,ad4086
+ - adi,ad4087
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ description: Configuration of the SPI bus.
+ maximum: 50000000
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cnv
+
+ vdd33-supply: true
+
+ vdd11-supply: true
+
+ vddldo-supply: true
+
+ iovdd-supply: true
+
+ vrefin-supply: true
+
+ io-backends:
+ maxItems: 1
+
+ adi,lvds-cnv-enable:
+ description: Enable the LVDS signal type on the CNV pin. Default is CMOS.
+ type: boolean
+
+ adi,num-lanes:
+ description:
+ Number of lanes on which the data is sent on the output (DA, DB pins).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ default: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - vdd33-supply
+ - vrefin-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4080";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ vdd33-supply = <&vdd33>;
+ vddldo-supply = <&vddldo>;
+ vrefin-supply = <&vrefin>;
+ clocks = <&cnv>;
+ clock-names = "cnv";
+ io-backends = <&iio_backend>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml
new file mode 100644
index 000000000000..d00690a8d3fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml
@@ -0,0 +1,262 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2022 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4130.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD4130 ADC device driver
+
+maintainers:
+ - Cosmin Tanislav <cosmin.tanislav@analog.com>
+
+description: |
+ Bindings for the Analog Devices AD4130 ADC. Datasheet can be found here:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD4130-8.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4130
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: phandle to the master clock (mclk)
+
+ clock-names:
+ items:
+ - const: mclk
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ description: |
+ Specify which interrupt pin should be configured as Data Ready / FIFO
+ interrupt.
+ Default if not supplied is int.
+ enum:
+ - int
+ - clk
+ - p2
+ - dout
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#clock-cells':
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ refin1-supply:
+ description: refin1 supply. Can be used as reference for conversion.
+
+ refin2-supply:
+ description: refin2 supply. Can be used as reference for conversion.
+
+ avdd-supply:
+ description: AVDD voltage supply. Can be used as reference for conversion.
+
+ iovdd-supply:
+ description: IOVDD voltage supply. Used for the chip interface.
+
+ spi-max-frequency:
+ maximum: 5000000
+
+ adi,ext-clk-freq-hz:
+ description: Specify the frequency of the external clock.
+ enum: [76800, 153600]
+ default: 76800
+
+ adi,bipolar:
+ description: Specify if the device should be used in bipolar mode.
+ type: boolean
+
+ adi,vbias-pins:
+ description: Analog inputs to apply a voltage bias of (AVDD − AVSS) / 2 to.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 16
+ items:
+ minimum: 0
+ maximum: 15
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+patternProperties:
+ "^channel@([0-9a-f])$":
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: The channel number.
+ minimum: 0
+ maximum: 15
+
+ diff-channels:
+ description: |
+ Besides the analog inputs available, internal inputs can be used.
+ 16: Internal temperature sensor.
+ 17: AVSS
+ 18: Internal reference
+ 19: DGND
+ 20: (AVDD − AVSS)/6+
+ 21: (AVDD − AVSS)/6-
+ 22: (IOVDD − DGND)/6+
+ 23: (IOVDD − DGND)/6-
+ 24: (ALDO − AVSS)/6+
+ 25: (ALDO − AVSS)/6-
+ 26: (DLDO − DGND)/6+
+ 27: (DLDO − DGND)/6-
+ 28: V_MV_P
+ 29: V_MV_M
+ items:
+ minimum: 0
+ maximum: 29
+
+ adi,reference-select:
+ description: |
+ Select the reference source to use when converting on the
+ specific channel. Valid values are:
+ 0: REFIN1(+)/REFIN1(−)
+ 1: REFIN2(+)/REFIN2(−)
+ 2: REFOUT/AVSS (Internal reference)
+ 3: AVDD/AVSS
+ If not specified, REFIN1 is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ default: 0
+
+ adi,excitation-pin-0:
+ description: |
+ Analog input to apply excitation current to while the channel
+ is active.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ adi,excitation-pin-1:
+ description: |
+ Analog input to apply excitation current to while this channel
+ is active.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ adi,excitation-current-0-nanoamp:
+ description: |
+ Excitation current in nanoamps to be applied to pin specified in
+ adi,excitation-pin-0 while this channel is active.
+ enum: [0, 100, 10000, 20000, 50000, 100000, 150000, 200000]
+ default: 0
+
+ adi,excitation-current-1-nanoamp:
+ description: |
+ Excitation current in nanoamps to be applied to pin specified in
+ adi,excitation-pin-1 while this channel is active.
+ enum: [0, 100, 10000, 20000, 50000, 100000, 150000, 200000]
+ default: 0
+
+ adi,burnout-current-nanoamp:
+ description: |
+ Burnout current in nanoamps to be applied for this channel.
+ enum: [0, 500, 2000, 4000]
+ default: 0
+
+ adi,buffered-positive:
+ description: Enable buffered mode for positive input.
+ type: boolean
+
+ adi,buffered-negative:
+ description: Enable buffered mode for negative input.
+ type: boolean
+
+ required:
+ - reg
+ - diff-channels
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4130";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi-max-frequency = <5000000>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+
+ channel@0 {
+ reg = <0>;
+
+ adi,reference-select = <2>;
+
+ /* AIN8, AIN9 */
+ diff-channels = <8 9>;
+ };
+
+ channel@1 {
+ reg = <1>;
+
+ adi,reference-select = <2>;
+
+ /* AIN10, AIN11 */
+ diff-channels = <10 11>;
+ };
+
+ channel@2 {
+ reg = <2>;
+
+ adi,reference-select = <2>;
+
+ /* Temperature Sensor, DGND */
+ diff-channels = <16 19>;
+ };
+
+ channel@3 {
+ reg = <3>;
+
+ adi,reference-select = <2>;
+
+ /* Internal reference, DGND */
+ diff-channels = <18 19>;
+ };
+
+ channel@4 {
+ reg = <4>;
+
+ adi,reference-select = <2>;
+
+ /* DGND, DGND */
+ diff-channels = <19 19>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4170-4.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4170-4.yaml
new file mode 100644
index 000000000000..da93213d12d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4170-4.yaml
@@ -0,0 +1,554 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4170-4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD4170-4 and similar Analog to Digital Converters
+
+maintainers:
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+
+description: |
+ Analog Devices AD4170-4 series of Sigma-delta Analog to Digital Converters.
+ Specifications can be found at:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4170-4.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4190-4.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4195-4.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+$defs:
+ reference-buffer:
+ description: |
+ Enable precharge buffer, full buffer, or skip reference buffering of
+ the positive/negative voltage reference. Because the output impedance
+ of the source driving the voltage reference inputs may be dynamic,
+ resistive/capacitive combinations of those inputs can cause DC gain
+ errors if the reference inputs go unbuffered into the ADC. Enable
+ reference buffering if the provided reference source has dynamic high
+ impedance output. Note the absolute voltage allowed on REFINn+ and REFINn-
+ inputs is from AVSS - 50 mV to AVDD + 50 mV when the reference buffers are
+ disabled but narrows to AVSS to AVDD when reference buffering is enabled
+ or in precharge mode.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ precharge, full, disabled ]
+ default: full
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4170-4
+ - adi,ad4190-4
+ - adi,ad4195-4
+
+ avss-supply:
+ description:
+ Reference voltage supply for AVSS. A −2.625V minimum and 0V maximum supply
+ that powers the chip. If not provided, AVSS is assumed to be at system
+ ground (0V).
+
+ avdd-supply:
+ description:
+ A supply of 4.75V to 5.25V relative to AVSS that powers the chip (AVDD).
+
+ iovdd-supply:
+ description: 1.7V to 5.25V reference supply to the serial interface (IOVDD).
+
+ refin1p-supply:
+ description: REFIN+ supply that can be used as reference for conversion.
+
+ refin1n-supply:
+ description: REFIN- supply that can be used as reference for conversion.
+
+ refin2p-supply:
+ description: REFIN2+ supply that can be used as reference for conversion.
+
+ refin2n-supply:
+ description: REFIN2- supply that can be used as reference for conversion.
+
+ spi-cpol: true
+
+ spi-cpha: true
+
+ interrupts:
+ description:
+ Interrupt for signaling the completion of conversion results. The data
+ ready signal (RDY) used as interrupt is by default provided on the SDO
+ pin. Alternatively, it can be provided on the DIG_AUX1 pin in which case
+ the chip disables the RDY function on SDO. Thus, there can be only one
+ data ready interrupt enabled at a time.
+
+ interrupt-names:
+ description:
+ Specify which pin should be configured as Data Ready interrupt.
+ enum:
+ - sdo
+ - dig_aux1
+
+ clocks:
+ maxItems: 1
+ description:
+ Optional external clock source. Can specify either an external clock or
+ external crystal.
+
+ clock-names:
+ enum:
+ - ext-clk
+ - xtal
+ default: ext-clk
+
+ '#clock-cells':
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ The first cell is for the GPIO number: 0 to 3.
+ The second cell takes standard GPIO flags.
+
+ ldac-gpios:
+ description:
+ GPIO connected to DIG_AUX2 pin to be used as LDAC toggle to control the
+ transfer of data from the DAC_INPUT_A register to the DAC.
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ adi,vbias-pins:
+ description: Analog inputs to apply a voltage bias of (AVDD − AVSS) / 2 to.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 9
+ items:
+ minimum: 0
+ maximum: 8
+
+allOf:
+ # Some devices don't have integrated DAC
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad4190-4
+ - adi,ad4195-4
+ then:
+ properties:
+ ldac-gpios: false
+
+ # Require to specify the interrupt pin when using interrupts
+ - if:
+ required:
+ - interrupts
+ then:
+ required:
+ - interrupt-names
+
+ # If an external clock is set, the internal clock cannot go out and vice versa
+ - oneOf:
+ - required: [clocks]
+ properties:
+ '#clock-cells': false
+ - required: ['#clock-cells']
+ properties:
+ clocks: false
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - iovdd-supply
+ - spi-cpol
+ - spi-cpha
+
+unevaluatedProperties: false
+
+patternProperties:
+ "^channel@[0-9a-f]$":
+ $ref: /schemas/iio/adc/adc.yaml#
+ unevaluatedProperties: false
+ description:
+ Represents the external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description:
+ The channel number.
+ minimum: 0
+ maximum: 15
+
+ diff-channels:
+ description: |
+ This property is used for defining the inputs of a differential
+ voltage channel. The first value is the positive input and the second
+ value is the negative input of the channel.
+
+ Besides the analog input pins AIN0 to AIN8, there are special inputs
+ that can be selected with the following values:
+ 17: Internal temperature sensor
+ 18: (AVDD-AVSS)/5
+ 19: (IOVDD-DGND)/5
+ 20: DAC output
+ 21: ALDO
+ 22: DLDO
+ 23: AVSS
+ 24: DGND
+ 25: REFIN+
+ 26: REFIN-
+ 27: REFIN2+
+ 28: REFIN2-
+ 29: REFOUT
+ For the internal temperature sensor, use the input number for both
+ inputs (i.e. diff-channels = <17 17>).
+ items:
+ enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 17, 18, 19, 20, 21, 22, 23, 24, 25,
+ 26, 27, 28, 29]
+
+ adi,reference-select:
+ description: |
+ Select the reference source to use when converting on the
+ specific channel. Valid values are:
+ 0: REFIN+/REFIN-
+ 1: REFIN2+/REFIN2−
+ 2: REFOUT/AVSS (internal reference)
+ 3: AVDD/AVSS
+ If not specified, REFOUT/AVSS is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ default: 1
+
+ adi,positive-reference-buffer:
+ $ref: '#/$defs/reference-buffer'
+
+ adi,negative-reference-buffer:
+ $ref: '#/$defs/reference-buffer'
+
+ adi,sensor-type:
+ description:
+ The AD4170-4 and similar designs have features to aid interfacing with
+ load cell weigh scale, RTD, and thermocouple sensors. Each of those
+ sensor types requires either distinct wiring configuration or
+ external circuitry for proper sensor operation and can use different
+ ADC chip functionality on their setups. A key characteristic of those
+ external sensors is that they must be excited either by voltage supply
+ or by ADC chip excitation signals. The sensor can then be read through
+ a pair of analog inputs. This property specifies which particular
+ sensor type is connected to the ADC so it can be properly setup and
+ handled. Omit this property for conventional (not weigh scale, RTD, or
+ thermocouple) ADC channel setups.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ weighscale, rtd, thermocouple ]
+
+ adi,excitation-pin-0:
+ description:
+ Analog input to apply excitation current to while the channel
+ is active.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 20
+ default: 0
+
+ adi,excitation-pin-1:
+ description:
+ Analog input to apply excitation current to while the channel
+ is active.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 20
+ default: 0
+
+ adi,excitation-pin-2:
+ description:
+ Analog input to apply excitation current to while the channel
+ is active.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 20
+ default: 0
+
+ adi,excitation-pin-3:
+ description:
+ Analog input to apply excitation current to while the channel
+ is active.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 20
+ default: 0
+
+ adi,excitation-current-0-microamp:
+ description:
+ Excitation current in microamperes to be applied to pin specified in
+ adi,excitation-pin-0 while this channel is active.
+ enum: [0, 10, 50, 100, 250, 500, 1000, 1500]
+ default: 0
+
+ adi,excitation-current-1-microamp:
+ description:
+ Excitation current in microamperes to be applied to pin specified in
+ adi,excitation-pin-1 while this channel is active.
+ enum: [0, 10, 50, 100, 250, 500, 1000, 1500]
+ default: 0
+
+ adi,excitation-current-2-microamp:
+ description:
+ Excitation current in microamperes to be applied to pin specified in
+ adi,excitation-pin-2 while this channel is active.
+ enum: [0, 10, 50, 100, 250, 500, 1000, 1500]
+ default: 0
+
+ adi,excitation-current-3-microamp:
+ description:
+ Excitation current in microamperes to be applied to pin specified in
+ adi,excitation-pin-3 while this channel is active.
+ enum: [0, 10, 50, 100, 250, 500, 1000, 1500]
+ default: 0
+
+ adi,excitation-ac:
+ type: boolean
+ description:
+ Whether the external sensor has to be AC or DC excited. When omitted,
+ it is DC excited.
+
+ allOf:
+ - oneOf:
+ - required: [single-channel, common-mode-channel]
+ properties:
+ diff-channels: false
+ - required: [diff-channels]
+ properties:
+ single-channel: false
+ common-mode-channel: false
+ # Usual ADC channels don't need external circuitry excitation.
+ - if:
+ not:
+ required:
+ - adi,sensor-type
+ then:
+ properties:
+ adi,excitation-pin-0: false
+ adi,excitation-pin-1: false
+ adi,excitation-pin-2: false
+ adi,excitation-pin-3: false
+ adi,excitation-current-0-microamp: false
+ adi,excitation-current-1-microamp: false
+ adi,excitation-current-2-microamp: false
+ adi,excitation-current-3-microamp: false
+ adi,excitation-ac: false
+ # Weigh scale bridge AC excited with one pair of predefined signals.
+ - if:
+ allOf:
+ - properties:
+ adi,sensor-type:
+ contains:
+ const: weighscale
+ - required:
+ - adi,excitation-ac
+ - adi,excitation-pin-2
+ - adi,excitation-pin-3
+ - not:
+ required:
+ - adi,excitation-current-2-microamp
+ - adi,excitation-current-3-microamp
+ then:
+ properties:
+ adi,excitation-pin-2:
+ const: 19
+ adi,excitation-pin-3:
+ const: 20
+ # Weigh scale bridge AC excited with two pairs of predefined signals.
+ - if:
+ allOf:
+ - properties:
+ adi,sensor-type:
+ contains:
+ const: weighscale
+ - required:
+ - adi,excitation-ac
+ - adi,excitation-pin-0
+ - adi,excitation-pin-1
+ - adi,excitation-pin-2
+ - adi,excitation-pin-3
+ - not:
+ required:
+ - adi,excitation-current-0-microamp
+ - adi,excitation-current-1-microamp
+ - adi,excitation-current-2-microamp
+ - adi,excitation-current-3-microamp
+ then:
+ properties:
+ adi,excitation-pin-0:
+ const: 17
+ adi,excitation-pin-1:
+ const: 18
+ adi,excitation-pin-2:
+ const: 19
+ adi,excitation-pin-3:
+ const: 20
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4170-4";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ spi-cpol;
+ spi-cpha;
+ avdd-supply = <&avdd>;
+ iovdd-supply = <&iovdd>;
+ clocks = <&clk>;
+ clock-names = "xtal";
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "dig_aux1";
+ adi,vbias-pins = <8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ // Sample AIN0 with respect to DGND throughout AVDD/DGND input range
+ // Pseudo-differential unipolar
+ channel@0 {
+ reg = <0>;
+ single-channel = <0>;
+ common-mode-channel = <24>;
+ adi,reference-select = <3>;
+ };
+ // Weigh scale sensor
+ channel@1 {
+ reg = <1>;
+ bipolar;
+ diff-channels = <1 2>;
+ adi,reference-select = <0>;
+ adi,positive-reference-buffer = "precharge";
+ adi,negative-reference-buffer = "precharge";
+ adi,sensor-type = "weighscale";
+ adi,excitation-pin-2 = <19>;
+ adi,excitation-pin-3 = <20>;
+ adi,excitation-ac;
+ };
+ // RTD sensor
+ channel@2 {
+ reg = <2>;
+ bipolar;
+ diff-channels = <3 4>;
+ adi,reference-select = <0>;
+ adi,sensor-type = "rtd";
+ adi,excitation-pin-0 = <5>;
+ adi,excitation-pin-1 = <6>;
+ adi,excitation-current-0-microamp = <500>;
+ adi,excitation-current-1-microamp = <500>;
+ adi,excitation-ac;
+ };
+ // Thermocouple sensor
+ channel@3 {
+ reg = <3>;
+ bipolar;
+ diff-channels = <7 8>;
+ adi,reference-select = <0>;
+ adi,sensor-type = "thermocouple";
+ adi,excitation-pin-0 = <18>;
+ adi,excitation-current-0-microamp = <500>;
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4170-4";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ spi-cpol;
+ spi-cpha;
+ avdd-supply = <&avdd>;
+ iovdd-supply = <&iovdd>;
+ #clock-cells = <0>;
+ clock-output-names = "ad4170-clk16mhz";
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "dig_aux1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ // Sample AIN0 with respect to AIN1 throughout AVDD/AVSS input range
+ // Differential bipolar. If AVSS < 0V, differential true bipolar
+ channel@0 {
+ reg = <0>;
+ bipolar;
+ diff-channels = <0 1>;
+ adi,reference-select = <3>;
+ };
+ // Sample AIN2 with respect to DGND throughout AVDD/DGND input range
+ // Pseudo-differential unipolar
+ channel@1 {
+ reg = <1>;
+ single-channel = <2>;
+ common-mode-channel = <24>;
+ adi,reference-select = <3>;
+ };
+ // Sample AIN3 with respect to 2.5V throughout AVDD/AVSS input range
+ // Pseudo-differential bipolar
+ channel@2 {
+ reg = <2>;
+ bipolar;
+ single-channel = <3>;
+ common-mode-channel = <29>;
+ adi,reference-select = <3>;
+ };
+ // Sample AIN4 with respect to DGND throughout AVDD/AVSS input range
+ // Pseudo-differential bipolar
+ channel@3 {
+ reg = <3>;
+ bipolar;
+ single-channel = <4>;
+ common-mode-channel = <24>;
+ adi,reference-select = <3>;
+ };
+ // Sample AIN5 with respect to 2.5V throughout AVDD/AVSS input range
+ // Pseudo-differential unipolar (AD4170-4 datasheet page 46 example)
+ channel@4 {
+ reg = <4>;
+ single-channel = <5>;
+ common-mode-channel = <29>;
+ adi,reference-select = <3>;
+ };
+ // Sample AIN6 with respect to 2.5V throughout REFIN+/REFIN- input range
+ // Pseudo-differential bipolar
+ channel@5 {
+ reg = <5>;
+ bipolar;
+ single-channel = <6>;
+ common-mode-channel = <29>;
+ adi,reference-select = <0>;
+ };
+ // Weigh scale sensor
+ channel@6 {
+ reg = <6>;
+ bipolar;
+ diff-channels = <7 8>;
+ adi,reference-select = <0>;
+ adi,sensor-type = "weighscale";
+ adi,excitation-pin-0 = <17>;
+ adi,excitation-pin-1 = <18>;
+ adi,excitation-pin-2 = <19>;
+ adi,excitation-pin-3 = <20>;
+ adi,excitation-ac;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml
new file mode 100644
index 000000000000..cbde7a0505d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml
@@ -0,0 +1,268 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4695.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices Easy Drive Multiplexed SAR Analog to Digital Converters
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ A family of similar multi-channel analog to digital converters with SPI bus.
+
+ * https://www.analog.com/en/products/ad4695.html
+ * https://www.analog.com/en/products/ad4696.html
+ * https://www.analog.com/en/products/ad4697.html
+ * https://www.analog.com/en/products/ad4698.html
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4695
+ - adi,ad4696
+ - adi,ad4697
+ - adi,ad4698
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 80000000
+
+ spi-cpol: true
+ spi-cpha: true
+
+ spi-rx-bus-width:
+ minimum: 1
+ maximum: 4
+
+ avdd-supply:
+ description: Analog power supply.
+
+ vio-supply:
+ description: I/O pin power supply.
+
+ ldo-in-supply:
+ description: Internal LDO Input. Mutually exclusive with vdd-supply.
+
+ vdd-supply:
+ description: Core power supply. Mutually exclusive with ldo-in-supply.
+
+ ref-supply:
+ description:
+ External reference voltage. Mutually exclusive with refin-supply.
+
+ refin-supply:
+ description:
+ Internal reference buffer input. Mutually exclusive with ref-supply.
+
+ com-supply:
+ description: Common voltage supply for pseudo-differential analog inputs.
+
+ adi,no-ref-current-limit:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ When this flag is present, the REF Overvoltage Reduced Current protection
+ is disabled.
+
+ adi,no-ref-high-z:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable this flag if the ref-supply requires Reference Input High-Z Mode
+ to be disabled for proper operation.
+
+ cnv-gpios:
+ description: The Convert Input (CNV). If omitted, CNV is tied to SPI CS.
+ maxItems: 1
+
+ reset-gpios:
+ description: The Reset Input (RESET). Should be configured GPIO_ACTIVE_LOW.
+ maxItems: 1
+
+ pwms:
+ description: PWM signal connected to the CNV pin.
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Signal coming from the BSY_ALT_GP0 pin (ALERT or BUSY).
+ - description: Signal coming from the GP2 pin (ALERT).
+ - description: Signal coming from the GP3 pin (BUSY).
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: gp0
+ - const: gp2
+ - const: gp3
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ The first cell is the GPn number: 0 to 3.
+ The second cell takes standard GPIO flags.
+
+ '#trigger-source-cells':
+ description: |
+ First cell indicates the output signal: 0 = BUSY, 1 = ALERT.
+ Second cell indicates which GPn pin is used: 0, 2 or 3.
+
+ For convenience, macros for these values are available in
+ dt-bindings/iio/adc/adi,ad4695.h.
+ const: 2
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^in(?:[13579]|1[135])-supply$":
+ description:
+ Optional voltage supply for odd numbered channels when they are used as
+ the negative input for a pseudo-differential channel.
+
+ "^channel@[0-9a-f]$":
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+ description:
+ Describes each individual channel. In addition the properties defined
+ below, bipolar from adc.yaml is also supported.
+
+ properties:
+ reg:
+ maximum: 15
+
+ common-mode-channel:
+ description:
+ Describes the common mode channel for single channels. 0xFF is REFGND
+ and OxFE is COM. Macros are available for these values in
+ dt-bindings/iio/adc/adi,ad4695.h. Values 1 to 15 correspond to INx
+ inputs. Only odd numbered INx inputs can be used as common mode
+ channels.
+ enum: [1, 3, 5, 7, 9, 11, 13, 15, 0xFE, 0xFF]
+ default: 0xFF
+
+ adi,no-high-z:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable this flag if the input pin requires the Analog Input High-Z
+ Mode to be disabled for proper operation.
+
+ required:
+ - reg
+
+ allOf:
+ # bipolar mode can't be used with REFGND
+ - if:
+ properties:
+ common-mode-channel:
+ const: 0xFF
+ then:
+ properties:
+ bipolar: false
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - vio-supply
+
+allOf:
+ - oneOf:
+ - required:
+ - ldo-in-supply
+ - required:
+ - vdd-supply
+
+ - oneOf:
+ - required:
+ - ref-supply
+ - required:
+ - refin-supply
+
+ # the internal reference buffer always requires high-z mode
+ - if:
+ required:
+ - refin-supply
+ then:
+ properties:
+ adi,no-ref-high-z: false
+
+ # limit channels for 8-channel chips
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad4697
+ - adi,ad4698
+ then:
+ patternProperties:
+ "^in(?:9|1[135])-supply$": false
+ "^channel@[0-7]$":
+ properties:
+ reg:
+ maximum: 7
+ common-mode-channel:
+ enum: [1, 3, 5, 7, 0xFE, 0xFF]
+ "^channel@[8-9a-f]$": false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/iio/adc/adi,ad4695.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4695";
+ reg = <0>;
+ spi-cpol;
+ spi-cpha;
+ spi-max-frequency = <80000000>;
+ avdd-supply = <&power_supply>;
+ ldo-in-supply = <&power_supply>;
+ vio-supply = <&io_supply>;
+ refin-supply = <&supply_5V>;
+ com-supply = <&supply_2V5>;
+ in3-supply = <&supply_2V5>;
+ reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Pseudo-differential channel between IN0 and REFGND. */
+ channel@0 {
+ reg = <0>;
+ };
+
+ /* Pseudo-differential channel between IN1 and COM. */
+ channel@1 {
+ reg = <1>;
+ common-mode-channel = <AD4695_COMMON_MODE_COM>;
+ bipolar;
+ };
+
+ /* Pseudo-differential channel between IN2 and IN3. */
+ channel@2 {
+ reg = <2>;
+ common-mode-channel = <3>;
+ bipolar;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml
new file mode 100644
index 000000000000..b107322e0ea3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2024 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad4851.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD485X family
+
+maintainers:
+ - Sergiu Cuciurean <sergiu.cuciurean@analog.com>
+ - Dragos Bogdan <dragos.bogdan@analog.com>
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description: |
+ Analog Devices AD485X fully buffered, 8-channel simultaneous sampling,
+ 16/20-bit, 1 MSPS data acquisition system (DAS) with differential, wide
+ common-mode range inputs.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4855.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4856.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4857.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4858.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4851
+ - adi,ad4852
+ - adi,ad4853
+ - adi,ad4854
+ - adi,ad4855
+ - adi,ad4856
+ - adi,ad4857
+ - adi,ad4858
+ - adi,ad4858i
+
+ reg:
+ maxItems: 1
+
+ vcc-supply: true
+
+ vee-supply: true
+
+ vdd-supply: true
+
+ vddh-supply: true
+
+ vddl-supply: true
+
+ vio-supply: true
+
+ vrefbuf-supply: true
+
+ vrefio-supply: true
+
+ pwms:
+ description: PWM connected to the CNV pin.
+ maxItems: 1
+
+ io-backends:
+ maxItems: 1
+
+ pd-gpios:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 25000000
+
+ spi-3wire: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^channel(@[0-7])?$":
+ $ref: adc.yaml
+ type: object
+ description: Represents the channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description:
+ The channel number, as specified in the datasheet (from 0 to 7).
+ minimum: 0
+ maximum: 7
+
+ diff-channels:
+ description:
+ Each channel can be configured as a bipolar differential channel.
+ The ADC uses the same positive and negative inputs for this.
+ This property must be specified as 'reg' (or the channel number) for
+ both positive and negative inputs (i.e. diff-channels = <reg reg>).
+ Since the configuration is bipolar differential, the 'bipolar'
+ property is required.
+ items:
+ minimum: 0
+ maximum: 7
+
+ bipolar: true
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+ - vee-supply
+ - vdd-supply
+ - vio-supply
+ - pwms
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0{
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "adi,ad4858";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ vcc-supply = <&vcc>;
+ vdd-supply = <&vdd>;
+ vee-supply = <&vee>;
+ vddh-supply = <&vddh>;
+ vddl-supply = <&vddl>;
+ vio-supply = <&vio>;
+ pwms = <&pwm_gen 0 0>;
+ io-backends = <&iio_backend>;
+
+ channel@0 {
+ reg = <0>;
+ diff-channels = <0 0>;
+ bipolar;
+ };
+
+ channel@1 {
+ reg = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
index b97559f23b3a..705adbe88def 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
@@ -4,51 +4,124 @@
$id: http://devicetree.org/schemas/iio/adc/adi,ad7091r5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices AD7091R5 4-Channel 12-Bit ADC
+title: Analog Devices AD7091R-2/-4/-5/-8 Multi-Channel 12-Bit ADCs
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
description: |
- Analog Devices AD7091R5 4-Channel 12-Bit ADC
+ Analog Devices AD7091R5 4-Channel 12-Bit ADC supporting I2C interface
https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
+ Analog Devices AD7091R-2/AD7091R-4/AD7091R-8 2-/4-/8-Channel 12-Bit ADCs
+ supporting SPI interface
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7091R-2_7091R-4_7091R-8.pdf
properties:
compatible:
enum:
+ - adi,ad7091r2
+ - adi,ad7091r4
- adi,ad7091r5
+ - adi,ad7091r8
reg:
maxItems: 1
+ vdd-supply:
+ description:
+ Provide VDD power to the sensor (VDD range is from 2.7V to 5.25V).
+
+ vdrive-supply:
+ description:
+ Determines the voltage level at which the interface logic will operate.
+ The V_drive voltage range is from 1.8V to 5.25V and must not exceed VDD by
+ more than 0.3V.
+
vref-supply:
description:
Phandle to the vref power supply
- interrupts:
+ convst-gpios:
+ description:
+ GPIO connected to the CONVST pin.
+ This logic input is used to initiate conversions on the analog
+ input channels.
maxItems: 1
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Interrupt for signaling when conversion results exceed the high limit for
+ ADC readings or fall below the low limit for them. Interrupt source must
+ be attached to ALERT/BUSY/GPO0 pin.
+ maxItems: 1
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ # AD7091R-2 does not have ALERT/BUSY/GPO pin
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7091r2
+ then:
+ properties:
+ interrupts: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7091r2
+ - adi,ad7091r4
+ - adi,ad7091r8
+ then:
+ required:
+ - convst-gpios
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
adc@2f {
- compatible = "adi,ad7091r5";
- reg = <0x2f>;
+ compatible = "adi,ad7091r5";
+ reg = <0x2f>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- interrupt-parent = <&gpio>;
+ adc@0 {
+ compatible = "adi,ad7091r8";
+ reg = <0x0>;
+ spi-max-frequency = <1000000>;
+ vref-supply = <&adc_vref>;
+ convst-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+ interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
index fb3d0dae9bae..2e3f84db6193 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
@@ -8,7 +8,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD7124 ADC device driver
maintainers:
- - Stefan Popa <stefan.popa@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description: |
Bindings for the Analog Devices AD7124 ADC device. Datasheet can be
@@ -27,16 +28,36 @@ properties:
clocks:
maxItems: 1
- description: phandle to the master clock (mclk)
+ description: Optional external clock connected to the CLK pin.
clock-names:
+ deprecated: true
+ description:
+ MCLK is an internal counter in the ADC. Do not use this property.
items:
- const: mclk
+ '#clock-cells':
+ description:
+ The CLK pin can be used as an output. When that is the case, include
+ this property.
+ const: 0
+
interrupts:
description: IRQ line for the ADC
maxItems: 1
+ rdy-gpios:
+ description:
+ GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but
+ highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its
+ DOUT aka MISO role) and so usually triggers a spurious interrupt. The
+ distinction between such a spurious event and a real one can only be done
+ by reading such a GPIO. (There is a register telling the same
+ information, but accessing that one needs a SPI transfer which then
+ triggers another interrupt event.)
+ maxItems: 1
+
'#address-cells':
const: 1
@@ -52,18 +73,20 @@ properties:
avdd-supply:
description: avdd supply can be used as reference for conversion.
- spi-max-frequency: true
-
required:
- compatible
- reg
- - clocks
- - clock-names
- interrupts
+# Can't have both clock input and output at the same time.
+not:
+ required:
+ - '#clock-cells'
+ - clocks
+
patternProperties:
"^channel@([0-9]|1[0-5])$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
@@ -106,10 +129,14 @@ patternProperties:
additionalProperties: false
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -120,9 +147,8 @@ examples:
spi-max-frequency = <5000000>;
interrupts = <25 2>;
interrupt-parent = <&gpio>;
+ rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
refin1-supply = <&adc_vref>;
- clocks = <&ad7124_mclk>;
- clock-names = "mclk";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
new file mode 100644
index 000000000000..62d906e24997
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
@@ -0,0 +1,483 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7173.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7173 ADC
+
+maintainers:
+ - Ceclan Dumitru <dumitru.ceclan@analog.com>
+
+description: |
+ Analog Devices AD717x ADC's:
+ The AD717x family offer a complete integrated Sigma-Delta ADC solution which
+ can be used in high precision, low noise single channel applications
+ (Life Science measurements) or higher speed multiplexed applications
+ (Factory Automation PLC Input modules). The Sigma-Delta ADC is intended
+ primarily for measurement of signals close to DC but also delivers
+ outstanding performance with input bandwidths out to ~10kHz.
+
+ Analog Devices AD411x ADC's:
+ The AD411X family encompasses a series of low power, low noise, 24-bit,
+ sigma-delta analog-to-digital converters that offer a versatile range of
+ specifications. They integrate an analog front end suitable for processing
+ fully differential/single-ended and bipolar voltage inputs.
+
+ Datasheets for supported chips:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD4111.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD4112.pdf
+ <AD4113: not released yet>
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD4114.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD4115.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD4116.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7172-2.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7172-4.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7173-8.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7175-2.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7175-8.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7176-2.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7177-2.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad4111
+ - adi,ad4112
+ - adi,ad4113
+ - adi,ad4114
+ - adi,ad4115
+ - adi,ad4116
+ - adi,ad7172-2
+ - adi,ad7172-4
+ - adi,ad7173-8
+ - adi,ad7175-2
+ - adi,ad7175-8
+ - adi,ad7176-2
+ - adi,ad7177-2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: |
+ Ready: multiplexed with SPI data out. While SPI CS is low,
+ can be used to indicate the completion of a conversion.
+
+ - description: |
+ Error: The three error bits in the status register (ADC_ERROR, CRC_ERROR,
+ and REG_ERROR) are OR'ed, inverted, and mapped to the ERROR pin.
+ Therefore, the ERROR pin indicates that an error has occurred.
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: rdy
+ - const: err
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ spi-max-frequency:
+ maximum: 20000000
+
+ gpio-controller:
+ description: Marks the device node as a GPIO controller.
+
+ '#gpio-cells':
+ const: 2
+ description:
+ The first cell is the GPIO number and the second cell specifies
+ GPIO flags, as defined in <dt-bindings/gpio/gpio.h>.
+
+ vref-supply:
+ description: |
+ Differential external reference supply used for conversion. The reference
+ voltage (Vref) specified here must be the voltage difference between the
+ REF+ and REF- pins: Vref = (REF+) - (REF-).
+
+ vref2-supply:
+ description: |
+ Differential external reference supply used for conversion. The reference
+ voltage (Vref2) specified here must be the voltage difference between the
+ REF2+ and REF2- pins: Vref2 = (REF2+) - (REF2-).
+
+ avdd-supply:
+ description: Avdd supply, can be used as reference for conversion.
+ This supply is referenced to AVSS, voltage specified here
+ represents (AVDD1 - AVSS).
+
+ avdd2-supply:
+ description: Avdd2 supply, used as the input to the internal voltage regulator.
+ This supply is referenced to AVSS, voltage specified here
+ represents (AVDD2 - AVSS).
+
+ iovdd-supply:
+ description: iovdd supply, used for the chip digital interface.
+
+ clocks:
+ maxItems: 1
+ description: |
+ Optional external clock source. Can include one clock source: external
+ clock or external crystal.
+
+ clock-names:
+ enum:
+ - ext-clk
+ - xtal
+
+ '#clock-cells':
+ const: 0
+
+ rdy-gpios:
+ description:
+ GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but
+ highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its
+ DOUT aka MISO role) and so usually triggers a spurious interrupt. The
+ distinction between such a spurious event and a real one can only be done
+ by reading such a GPIO. (There is a register telling the same
+ information, but accessing that one needs a SPI transfer which then
+ triggers another interrupt event.)
+ maxItems: 1
+
+patternProperties:
+ "^channel@[0-9a-f]$":
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 15
+
+ diff-channels:
+ description: |
+ This property is used for defining the inputs of a differential
+ voltage channel. The first value is the positive input and the second
+ value is the negative input of the channel.
+
+ Family AD411x supports a dedicated VINCOM voltage input.
+ To select it set the second channel to 16.
+ (VIN2, VINCOM) -> diff-channels = <2 16>
+
+ There are special values that can be selected besides the voltage
+ analog inputs:
+ 21: REF+
+ 22: REF−
+
+ Supported only by AD7172-2, AD7172-4, AD7175-2, AD7175-8, AD7177-2,
+ must be paired together and can be used to monitor the power supply
+ of the ADC:
+ 19: ((AVDD1 − AVSS)/5)+
+ 20: ((AVDD1 − AVSS)/5)−
+
+ items:
+ minimum: 0
+ maximum: 31
+
+ single-channel:
+ description: |
+ This property is used for defining a current channel or the positive
+ input of a voltage channel (single-ended or pseudo-differential).
+
+ Models AD4111 and AD4112 support current channels.
+ Example: (IIN2+, IIN2−) -> single-channel = <2>
+ To correctly configure a current channel set the "adi,current-channel"
+ property to true.
+
+ To configure a single-ended/pseudo-differential channel set the
+ "common-mode-channel" property to the desired negative voltage input.
+
+ When used as a voltage channel, special inputs are valid as well.
+ minimum: 0
+ maximum: 31
+
+ common-mode-channel:
+ description:
+ This property is used for defining the negative input of a
+ single-ended or pseudo-differential voltage channel.
+
+ Special inputs are valid as well.
+ minimum: 0
+ maximum: 31
+
+ adi,reference-select:
+ description: |
+ Select the reference source to use when converting on
+ the specific channel. Valid values are:
+ vref : REF+ /REF−
+ vref2 : REF2+ /REF2−
+ refout-avss: REFOUT/AVSS (Internal reference)
+ avdd : AVDD /AVSS
+
+ External reference ref2 only available on ad7173-8 and ad7172-4.
+ Internal reference refout-avss not available on ad7172-4.
+
+ If not specified, internal reference used (if available).
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - vref
+ - vref2
+ - refout-avss
+ - avdd
+ default: refout-avss
+
+ adi,current-channel:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Signal that the selected inputs are current channels.
+ Only available on AD4111 and AD4112.
+
+ required:
+ - reg
+
+ allOf:
+ - oneOf:
+ - required: [single-channel]
+ properties:
+ diff-channels: false
+ - required: [diff-channels]
+ properties:
+ single-channel: false
+ adi,current-channel: false
+ common-mode-channel: false
+
+ - if:
+ required: [common-mode-channel]
+ then:
+ properties:
+ adi,current-channel: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ # Only ad7172-4, ad7173-8 and ad7175-8 support vref2
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - adi,ad7172-4
+ - adi,ad7173-8
+ - adi,ad7175-8
+ then:
+ properties:
+ vref2-supply: false
+ patternProperties:
+ "^channel@[0-9a-f]$":
+ properties:
+ adi,reference-select:
+ enum:
+ - vref
+ - refout-avss
+ - avdd
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad4114
+ - adi,ad4115
+ - adi,ad4116
+ - adi,ad7173-8
+ - adi,ad7175-8
+ then:
+ patternProperties:
+ "^channel@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 15
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7172-2
+ - adi,ad7175-2
+ - adi,ad7176-2
+ - adi,ad7177-2
+ then:
+ patternProperties:
+ "^channel@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 3
+
+ # Model ad7172-4 does not support internal reference
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,ad7172-4
+ then:
+ patternProperties:
+ "^channel@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 7
+ adi,reference-select:
+ enum:
+ - vref
+ - vref2
+ - avdd
+ required:
+ - adi,reference-select
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad4111
+ - adi,ad4112
+ - adi,ad4113
+ - adi,ad4114
+ - adi,ad4115
+ - adi,ad4116
+ then:
+ properties:
+ avdd2-supply: false
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - adi,ad4111
+ - adi,ad4112
+ then:
+ patternProperties:
+ "^channel@[0-9a-f]$":
+ properties:
+ adi,current-channel: false
+
+ - if:
+ anyOf:
+ - required: [clock-names]
+ - required: [clocks]
+ then:
+ properties:
+ '#clock-cells': false
+
+unevaluatedProperties: false
+
+examples:
+ # Example AD7173-8 with external reference connected to REF+/REF-:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7173-8";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "rdy";
+ interrupt-parent = <&gpio>;
+ spi-max-frequency = <5000000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #clock-cells = <0>;
+
+ vref-supply = <&dummy_regulator>;
+
+ channel@0 {
+ reg = <0>;
+ bipolar;
+ diff-channels = <0 1>;
+ adi,reference-select = "vref";
+ };
+
+ channel@1 {
+ reg = <1>;
+ diff-channels = <2 3>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ bipolar;
+ diff-channels = <4 5>;
+ };
+
+ channel@3 {
+ reg = <3>;
+ bipolar;
+ diff-channels = <6 7>;
+ };
+
+ channel@4 {
+ reg = <4>;
+ diff-channels = <8 9>;
+ adi,reference-select = "avdd";
+ };
+ };
+ };
+
+ # Example AD4111 with current channel and single-ended channel:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad4111";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "rdy";
+ interrupt-parent = <&gpio>;
+ rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <5000000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #clock-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ bipolar;
+ diff-channels = <4 5>;
+ };
+
+ // Single ended channel VIN2/VINCOM
+ channel@1 {
+ reg = <1>;
+ bipolar;
+ single-channel = <2>;
+ common-mode-channel = <16>;
+ };
+
+ // Current channel IN2+/IN2-
+ channel@2 {
+ reg = <2>;
+ single-channel = <2>;
+ adi,current-channel;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml
new file mode 100644
index 000000000000..801ed319ee82
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2025 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7191.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7191 ADC
+
+maintainers:
+ - Alisa-Dariana Roman <alisa.roman@analog.com>
+
+description: |
+ Bindings for the Analog Devices AD7191 ADC device. Datasheet can be
+ found here:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7191.pdf
+ The device's PDOWN pin must be connected to the SPI controller's chip select
+ pin.
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7191
+
+ reg:
+ maxItems: 1
+
+ spi-cpol: true
+
+ spi-cpha: true
+
+ clocks:
+ maxItems: 1
+ description:
+ Must be present when CLKSEL pin is tied HIGH to select external clock
+ source (either a crystal between MCLK1 and MCLK2 pins, or a
+ CMOS-compatible clock driving MCLK2 pin). Must be absent when CLKSEL pin
+ is tied LOW to use the internal 4.92MHz clock.
+
+ interrupts:
+ maxItems: 1
+
+ avdd-supply:
+ description: AVdd voltage supply
+
+ dvdd-supply:
+ description: DVdd voltage supply
+
+ vref-supply:
+ description: Vref voltage supply
+
+ odr-gpios:
+ description:
+ ODR1 and ODR2 pins for output data rate selection. Should be defined if
+ adi,odr-value is absent.
+ minItems: 2
+ maxItems: 2
+
+ adi,odr-value:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Should be present if ODR pins are pin-strapped. Possible values:
+ 120 Hz (ODR1=0, ODR2=0)
+ 60 Hz (ODR1=0, ODR2=1)
+ 50 Hz (ODR1=1, ODR2=0)
+ 10 Hz (ODR1=1, ODR2=1)
+ If defined, odr-gpios must be absent.
+ enum: [120, 60, 50, 10]
+
+ pga-gpios:
+ description:
+ PGA1 and PGA2 pins for gain selection. Should be defined if adi,pga-value
+ is absent.
+ minItems: 2
+ maxItems: 2
+
+ adi,pga-value:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Should be present if PGA pins are pin-strapped. Possible values:
+ Gain 1 (PGA1=0, PGA2=0)
+ Gain 8 (PGA1=0, PGA2=1)
+ Gain 64 (PGA1=1, PGA2=0)
+ Gain 128 (PGA1=1, PGA2=1)
+ If defined, pga-gpios must be absent.
+ enum: [1, 8, 64, 128]
+
+ temp-gpios:
+ description: TEMP pin for temperature sensor enable.
+ maxItems: 1
+
+ chan-gpios:
+ description: CHAN pin for input channel selection.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - avdd-supply
+ - dvdd-supply
+ - vref-supply
+ - spi-cpol
+ - spi-cpha
+ - temp-gpios
+ - chan-gpios
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - oneOf:
+ - required:
+ - adi,odr-value
+ - required:
+ - odr-gpios
+ - oneOf:
+ - required:
+ - adi,pga-value
+ - required:
+ - pga-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7191";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+ spi-cpha;
+ clocks = <&ad7191_mclk>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ avdd-supply = <&avdd>;
+ dvdd-supply = <&dvdd>;
+ vref-supply = <&vref>;
+ adi,pga-value = <1>;
+ odr-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>, <&gpio 24 GPIO_ACTIVE_HIGH>;
+ temp-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ chan-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
index 22b7ed3723f6..0bd2c6906c83 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
@@ -21,8 +21,15 @@ properties:
- adi,ad7190
- adi,ad7192
- adi,ad7193
+ - adi,ad7194
- adi,ad7195
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
reg:
maxItems: 1
@@ -30,25 +37,41 @@ properties:
spi-cpha: true
- spi-max-frequency: true
-
clocks:
maxItems: 1
- description: phandle to the master clock (mclk)
+ description:
+ Optionally, either a crystal can be attached externally between MCLK1 and
+ MCLK2 pins, or an external CMOS-compatible clock can drive the MCLK2
+ pin. If absent, internal 4.92MHz clock is used, which can be made
+ available on MCLK2 pin.
clock-names:
- items:
- - const: mclk
+ enum:
+ - xtal
+ - mclk
+
+ "#clock-cells":
+ const: 0
+ description:
+ If present when internal clock is used, configured as clock provider.
interrupts:
maxItems: 1
+ aincom-supply:
+ description: |
+ AINCOM voltage supply. Analog inputs AINx are referenced to this input
+ when configured for pseudo-differential operation.
+
dvdd-supply:
description: DVdd voltage supply
avdd-supply:
description: AVdd voltage supply
+ vref-supply:
+ description: VRef voltage supply
+
adi,rejection-60-Hz-enable:
description: |
This bit enables a notch at 60 Hz when the first notch of the sinc
@@ -83,41 +106,152 @@ properties:
description: see Documentation/devicetree/bindings/iio/adc/adc.yaml
type: boolean
+ rdy-gpios:
+ description:
+ GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but
+ highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its
+ DOUT aka MISO role) and so usually triggers a spurious interrupt. The
+ distinction between such a spurious event and a real one can only be done
+ by reading such a GPIO. (There is a register telling the same
+ information, but accessing that one needs a SPI transfer which then
+ triggers another interrupt event.)
+ maxItems: 1
+
+patternProperties:
+ "^channel@[0-9a-f]+$":
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: The channel index.
+ minimum: 0
+ maximum: 271
+
+ diff-channels:
+ description:
+ Both inputs can be connected to pins AIN1 to AIN16 by choosing the
+ appropriate value from 1 to 16.
+ items:
+ minimum: 1
+ maximum: 16
+
+ single-channel:
+ description:
+ Positive input can be connected to pins AIN1 to AIN16 by choosing the
+ appropriate value from 1 to 16. Negative input is connected to AINCOM.
+ minimum: 1
+ maximum: 16
+
+ oneOf:
+ - required:
+ - reg
+ - diff-channels
+ - required:
+ - reg
+ - single-channel
+
required:
- compatible
- reg
- - clocks
- - clock-names
- interrupts
- dvdd-supply
- avdd-supply
+ - vref-supply
- spi-cpol
- spi-cpha
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - adi,ad7190
+ - adi,ad7192
+ - adi,ad7193
+ - adi,ad7195
+ then:
+ patternProperties:
+ "^channel@[0-9a-f]+$": false
+ - if:
+ anyOf:
+ - required:
+ - clocks
+ - required:
+ - clock-names
+ then:
+ properties:
+ "#clock-cells": false
+ required:
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
examples:
- |
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- adc@0 {
- compatible = "adi,ad7192";
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpol;
- spi-cpha;
- clocks = <&ad7192_mclk>;
- clock-names = "mclk";
- interrupts = <25 0x2>;
- interrupt-parent = <&gpio>;
- dvdd-supply = <&dvdd>;
- avdd-supply = <&avdd>;
-
- adi,refin2-pins-enable;
- adi,rejection-60-Hz-enable;
- adi,buffer-enable;
- adi,burnout-currents-enable;
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7192";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+ spi-cpha;
+ clocks = <&ad7192_mclk>;
+ clock-names = "mclk";
+ interrupts = <25 0x2>;
+ interrupt-parent = <&gpio>;
+ rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
+ aincom-supply = <&aincom>;
+ dvdd-supply = <&dvdd>;
+ avdd-supply = <&avdd>;
+ vref-supply = <&vref>;
+
+ adi,refin2-pins-enable;
+ adi,rejection-60-Hz-enable;
+ adi,buffer-enable;
+ adi,burnout-currents-enable;
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7194";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+ spi-cpha;
+ #clock-cells = <0>;
+ interrupts = <25 0x2>;
+ interrupt-parent = <&gpio>;
+ rdy-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
+ aincom-supply = <&aincom>;
+ dvdd-supply = <&dvdd>;
+ avdd-supply = <&avdd>;
+ vref-supply = <&vref>;
+
+ channel@0 {
+ reg = <0>;
+ diff-channels = <1 6>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ single-channel = <1>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
index a694d5794d4a..dfb8f305e2f0 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
@@ -28,8 +28,6 @@ properties:
description: IRQ line for the ADC
maxItems: 1
- spi-max-frequency: true
-
adi,voltage-alert-last-chan:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -55,7 +53,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
index a3e39a40c9b3..2aa1f4b063eb 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml
@@ -30,8 +30,6 @@ properties:
spi-cpha: true
- spi-max-frequency: true
-
'#address-cells':
const: 1
@@ -45,7 +43,7 @@ required:
patternProperties:
"^channel@[0-7]$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
@@ -63,9 +61,12 @@ patternProperties:
required:
- reg
- additionalProperties: true
+ additionalProperties: false
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml
index ca414bb396c5..cd8ac5162d27 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml
@@ -24,13 +24,15 @@ properties:
vref-supply: true
vdd-supply: true
- spi-max-frequency: true
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
new file mode 100644
index 000000000000..b91bfb16ed6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
@@ -0,0 +1,316 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7380.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices Simultaneous Sampling Analog to Digital Converters
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ * https://www.analog.com/en/products/ad7380.html
+ * https://www.analog.com/en/products/ad7381.html
+ * https://www.analog.com/en/products/ad7383.html
+ * https://www.analog.com/en/products/ad7384.html
+ * https://www.analog.com/en/products/ad7386.html
+ * https://www.analog.com/en/products/ad7387.html
+ * https://www.analog.com/en/products/ad7388.html
+ * https://www.analog.com/en/products/ad7380-4.html
+ * https://www.analog.com/en/products/ad7381-4.html
+ * https://www.analog.com/en/products/ad7383-4.html
+ * https://www.analog.com/en/products/ad7384-4.html
+ * https://www.analog.com/en/products/ad7386-4.html
+ * https://www.analog.com/en/products/ad7387-4.html
+ * https://www.analog.com/en/products/ad7388-4.html
+ * https://www.analog.com/en/products/ad7389-4.html
+ * https://www.analog.com/en/products/adaq4370-4.html
+ * https://www.analog.com/en/products/adaq4380-4.html
+ * https://www.analog.com/en/products/adaq4381-4.html
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7380
+ - adi,ad7381
+ - adi,ad7383
+ - adi,ad7384
+ - adi,ad7386
+ - adi,ad7387
+ - adi,ad7388
+ - adi,ad7380-4
+ - adi,ad7381-4
+ - adi,ad7383-4
+ - adi,ad7384-4
+ - adi,ad7386-4
+ - adi,ad7387-4
+ - adi,ad7388-4
+ - adi,ad7389-4
+ - adi,adaq4370-4
+ - adi,adaq4380-4
+ - adi,adaq4381-4
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 80000000
+ spi-cpol: true
+ spi-cpha: true
+
+ vcc-supply:
+ description: A 3V to 3.6V supply that powers the chip.
+
+ vlogic-supply:
+ description:
+ A 1.65V to 3.6V supply for the logic pins.
+
+ refio-supply:
+ description:
+ A 2.5V to 3.3V supply for the external reference voltage. When omitted,
+ 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.
+ For adaq devices, a 5V supply voltage. A 3.3V internal reference is
+ derived from it. Connect to vs-p-supply for normal operation.
+
+ vs-p-supply:
+ description:
+ Amplifiers positive supply.
+
+ vs-n-supply:
+ description:
+ Amplifiers negative supply.
+
+ ldo-supply:
+ description:
+ LDO supply. Connect to vs-p-supply or a 3.6 to 5.5 V supply.
+
+ aina-supply:
+ description:
+ The common mode voltage supply for the AINA- pin on pseudo-differential
+ chips.
+
+ ainb-supply:
+ description:
+ The common mode voltage supply for the AINB- pin on pseudo-differential
+ chips.
+
+ ainc-supply:
+ description:
+ The common mode voltage supply for the AINC- pin on pseudo-differential
+ chips.
+
+ aind-supply:
+ description:
+ The common mode voltage supply for the AIND- pin on pseudo-differential
+ chips.
+
+ interrupts:
+ description:
+ When the device is using 1-wire mode, this property is used to optionally
+ specify the ALERT interrupt.
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+ - vlogic-supply
+
+patternProperties:
+ "^channel@[0-3]$":
+ $ref: adc.yaml
+ type: object
+
+ properties:
+ reg:
+ description:
+ The channel number. From 0 to 3 corresponding to channels A,B,C,D
+ minimum: 0
+ maximum: 3
+
+ adi,gain-milli:
+ description:
+ The hardware gain applied to the ADC input (in milli units).
+ If not present, default to 1000 (no actual gain applied).
+ Refer to the typical connection diagrams section of the datasheet for
+ pin wiring.
+ $ref: /schemas/types.yaml#/definitions/uint16
+ enum: [300, 600, 1000, 1600]
+ default: 1000
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+unevaluatedProperties: false
+
+allOf:
+ # pseudo-differential chips require common mode voltage supplies,
+ # true differential chips don't use them
+ - if:
+ properties:
+ compatible:
+ enum:
+ - adi,ad7383
+ - adi,ad7384
+ - adi,ad7383-4
+ - adi,ad7384-4
+ then:
+ required:
+ - aina-supply
+ - ainb-supply
+ else:
+ properties:
+ aina-supply: false
+ ainb-supply: false
+ - if:
+ properties:
+ compatible:
+ enum:
+ - adi,ad7383-4
+ - adi,ad7384-4
+ then:
+ required:
+ - ainc-supply
+ - aind-supply
+ else:
+ properties:
+ ainc-supply: false
+ aind-supply: false
+
+ # ad7380-4 uses refin-supply as external reference.
+ # adaq devices use internal reference only, derived from refin-supply
+ # 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
+ - adi,adaq4370-4
+ - adi,adaq4380-4
+ - adi,adaq4381-4
+ then:
+ properties:
+ refio-supply: false
+ required:
+ - refin-supply
+ else:
+ properties:
+ refin-supply: false
+
+ # adi,ad7389-4 is internal reference only
+ - if:
+ properties:
+ compatible:
+ const: adi,ad7389-4
+ then:
+ properties:
+ refio-supply: false
+
+ # adaq devices need more supplies and using channel to declare gain property
+ # only applies to adaq devices
+ - if:
+ properties:
+ compatible:
+ enum:
+ - adi,adaq4370-4
+ - adi,adaq4380-4
+ - adi,adaq4381-4
+ then:
+ required:
+ - vs-p-supply
+ - vs-n-supply
+ - ldo-supply
+ else:
+ properties:
+ vs-p-supply: false
+ vs-n-supply: false
+ ldo-supply: false
+ patternProperties:
+ "^channel@[0-3]$": false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7380";
+ reg = <0>;
+
+ spi-cpol;
+ spi-cpha;
+ spi-max-frequency = <80000000>;
+
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio0>;
+
+ vcc-supply = <&supply_3_3V>;
+ vlogic-supply = <&supply_3_3V>;
+ refio-supply = <&supply_2_5V>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,adaq4380-4";
+ reg = <0>;
+
+ spi-cpol;
+ spi-cpha;
+ spi-max-frequency = <80000000>;
+
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio0>;
+
+ vcc-supply = <&supply_3_3V>;
+ vlogic-supply = <&supply_3_3V>;
+ refin-supply = <&supply_5V>;
+ vs-p-supply = <&supply_5V>;
+ vs-n-supply = <&supply_0V>;
+ ldo-supply = <&supply_5V>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ adi,gain-milli = /bits/ 16 <300>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ adi,gain-milli = /bits/ 16 <600>;
+ };
+
+ channel@3 {
+ reg = <3>;
+ adi,gain-milli = /bits/ 16 <1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7405.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7405.yaml
new file mode 100644
index 000000000000..57f097025705
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7405.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7405.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7405 family
+
+maintainers:
+ - Dragos Bogdan <dragos.bogdan@analog.com>
+ - Pop Ioan Daniel <pop.ioan-daniel@analog.com>
+
+description: |
+ Analog Devices AD7405 is a high performance isolated ADC, 1-channel,
+ 16-bit with a second-order Σ-Δ modulator that converts an analog input signal
+ into a high speed, single-bit data stream.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7405.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/adum7701.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/adum7702.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADuM7703.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7405
+ - adi,adum7701
+ - adi,adum7702
+ - adi,adum7703
+
+ clocks:
+ maxItems: 1
+
+ vdd1-supply: true
+
+ vdd2-supply: true
+
+ io-backends:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - vdd1-supply
+ - vdd2-supply
+ - io-backends
+
+additionalProperties: false
+
+examples:
+ - |
+ adc {
+ compatible = "adi,ad7405";
+ clocks = <&axi_clk_gen 0>;
+ vdd1-supply = <&vdd1>;
+ vdd2-supply = <&vdd2>;
+ io-backends = <&axi_adc>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml
index 666414a9c0de..55880191c511 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml
@@ -17,39 +17,50 @@ description: |
properties:
compatible:
- enum:
- - adi,ad7091
- - adi,ad7091r
- - adi,ad7273
- - adi,ad7274
- - adi,ad7276
- - adi,ad7277
- - adi,ad7278
- - adi,ad7466
- - adi,ad7467
- - adi,ad7468
- - adi,ad7475
- - adi,ad7476
- - adi,ad7476a
- - adi,ad7477
- - adi,ad7477a
- - adi,ad7478
- - adi,ad7478a
- - adi,ad7495
- - adi,ad7910
- - adi,ad7920
- - adi,ad7940
- - ti,adc081s
- - ti,adc101s
- - ti,adc121s
- - ti,ads7866
- - ti,ads7867
- - ti,ads7868
- - lltc,ltc2314-14
+ oneOf:
+ - items:
+ - enum:
+ - adi,ad7091
+ - adi,ad7091r
+ - adi,ad7273
+ - adi,ad7274
+ - adi,ad7276
+ - adi,ad7277
+ - adi,ad7278
+ - adi,ad7466
+ - adi,ad7467
+ - adi,ad7468
+ - adi,ad7475
+ - adi,ad7476
+ - adi,ad7476a
+ - adi,ad7477
+ - adi,ad7477a
+ - adi,ad7478
+ - adi,ad7478a
+ - adi,ad7495
+ - adi,ad7910
+ - adi,ad7920
+ - adi,ad7940
+ - rohm,bd79105
+ - ti,adc081s
+ - ti,adc101s
+ - ti,adc121s
+ - ti,ads7866
+ - ti,ads7867
+ - ti,ads7868
+ - lltc,ltc2314-14
+ - items:
+ - const: rohm,bu79100g
+ - const: ti,ads7866
reg:
maxItems: 1
+ interrupts:
+ description:
+ The data-ready interrupt. Provided via DOUT pin.
+ maxItems: 1
+
vcc-supply:
description:
Main powersupply voltage for the chips, sometimes referred to as VDD on
@@ -66,19 +77,35 @@ properties:
to the other supplies. Needed to be able to establish channel scaling
unless there is also an internal reference available (e.g. ad7091r)
- spi-max-frequency: true
-
adi,conversion-start-gpios:
description: A GPIO used to trigger the start of a conversion
maxItems: 1
+ rdy-gpios:
+ description: A GPIO for detecting the data-ready.
+ maxItems: 1
+
required:
- compatible
- reg
-additionalProperties: false
-
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+# Devices with an IRQ
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rohm,bd79105
+ then:
+ properties:
+ interrupts: true
+ else:
+ properties:
+ interrupts: false
+
# Devices where reference is vcc
- if:
properties:
@@ -103,20 +130,19 @@ allOf:
- vcc-supply
# Devices with a vref
- if:
- properties:
- compatible:
- contains:
- enum:
- - adi,ad7091r
- - adi,ad7273
- - adi,ad7274
- - adi,ad7475
- - lltc,ltc2314-14
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7091r
+ - adi,ad7273
+ - adi,ad7274
+ - adi,ad7475
+ - lltc,ltc2314-14
+ - rohm,bd79105
then:
properties:
- vref-supply: true
- else:
- properties:
vref-supply: false
# Devices with a vref where it is not optional
- if:
@@ -128,35 +154,60 @@ allOf:
- adi,ad7274
- adi,ad7475
- lltc,ltc2314-14
+ - rohm,bd79105
then:
required:
- vref-supply
- if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7475
+ - adi,ad7495
+ - rohm,bd79105
+ then:
properties:
- compatible:
- contains:
- enum:
- - adi,ad7475
- - adi,ad7495
+ vdrive-supply: false
+
+ # Devices which support polling the data-ready via GPIO
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rohm,bd79105
then:
properties:
- vdrive-supply: true
- else:
+ rdy-gpios: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7091
+ - adi,ad7091r
+ - rohm,bd79105
+ then:
properties:
- vdrive-supply: false
+ adi,conversion-start-gpios: false
+
+ # Devices with a convstart GPIO where it is not optional
- if:
properties:
compatible:
contains:
enum:
- - adi,ad7091
- - adi,ad7091r
+ - rohm,bd79105
then:
- properties:
- adi,conversion-start-gpios: true
- else:
- properties:
- adi,conversion-start-gpios: false
+ required:
+ - adi,conversion-start-gpios
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
index 516fc24d3346..73c8e9c532f3 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
@@ -11,130 +11,417 @@ maintainers:
description: |
Analog Devices AD7606 Simultaneous Sampling ADC
+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7605-4.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ad7606_7606-6_7606-4.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7606B.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7606c-16.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7606c-18.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7607.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7608.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7609.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7616.pdf
properties:
compatible:
enum:
- adi,ad7605-4
- - adi,ad7606-8
- - adi,ad7606-6
- adi,ad7606-4
+ - adi,ad7606-6
+ - adi,ad7606-8 # Referred to as AD7606 (without -8) in the datasheet
- adi,ad7606b
+ - adi,ad7606c-16
+ - adi,ad7606c-18
+ - adi,ad7607
+ - adi,ad7608
+ - adi,ad7609
- adi,ad7616
reg:
maxItems: 1
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ '#trigger-source-cells':
+ description: |
+ Cell indicates the output signal: 0 = BUSY, 1 = FIRSTDATA.
+
+ For convenience, macros for these values are available in
+ dt-bindings/iio/adc/adi,ad7606.h.
+ const: 1
+
+ # According to the datasheet, "Data is clocked in from SDI on the falling
+ # edge of SCLK, while data is clocked out on DOUTA on the rising edge of
+ # SCLK". Also, even if not stated textually in the datasheet, it is made
+ # clear on the diagrams that sclk idles at high. Subsequently, in case SPI
+ # interface is used, the correct way is to only set spi-cpol.
spi-cpha: true
spi-cpol: true
- spi-max-frequency: true
-
avcc-supply: true
+ vdrive-supply:
+ description:
+ Determines the voltage level at which the interface logic pins will
+ operate.
+
+ refin-supply:
+ description:
+ The voltage supply for optional external reference voltage.
+
interrupts:
+ description:
+ The BUSY pin falling edge indicates that the conversion is over, and thus
+ new data is available.
maxItems: 1
adi,conversion-start-gpios:
description:
- Must be the device tree identifier of the CONVST pin.
- This logic input is used to initiate conversions on the analog
- input channels. As the line is active high, it should be marked
- GPIO_ACTIVE_HIGH.
- maxItems: 1
+ Must be the device tree identifier of the CONVST pin(s). This logic input
+ is used to initiate conversions on the analog input channels. As the line
+ is active high, it should be marked GPIO_ACTIVE_HIGH.
+ minItems: 1
+ maxItems: 2
reset-gpios:
description:
- Must be the device tree identifier of the RESET pin. If specified,
- it will be asserted during driver probe. As the line is active high,
- it should be marked GPIO_ACTIVE_HIGH.
+ Must be the device tree identifier of the RESET pin. If specified, it will
+ be asserted during driver probe. On the AD7606x, as the line is active
+ high, it should be marked GPIO_ACTIVE_HIGH. On the AD7616, as the line is
+ active low, it should be marked GPIO_ACTIVE_LOW.
maxItems: 1
standby-gpios:
description:
- Must be the device tree identifier of the STBY pin. This pin is used
- to place the AD7606 into one of two power-down modes, Standby mode or
+ Must be the device tree identifier of the STBY pin. This pin is used to
+ place the AD7606 into one of two power-down modes, Standby mode or
Shutdown mode. As the line is active low, it should be marked
GPIO_ACTIVE_LOW.
maxItems: 1
adi,first-data-gpios:
description:
- Must be the device tree identifier of the FRSTDATA pin.
- The FRSTDATA output indicates when the first channel, V1, is
- being read back on either the parallel, byte or serial interface.
- As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
+ Must be the device tree identifier of the FRSTDATA pin. The FRSTDATA
+ output indicates when the first channel, V1, is being read back on either
+ the parallel, byte or serial interface. As the line is active high, it
+ should be marked GPIO_ACTIVE_HIGH.
maxItems: 1
adi,range-gpios:
description:
- Must be the device tree identifier of the RANGE pin. The polarity on
- this pin determines the input range of the analog input channels. If
- this pin is tied to a logic high, the analog input range is ±10V for
- all channels. If this pin is tied to a logic low, the analog input range
+ Must be the device tree identifier of the RANGE pin. The state on this
+ pin determines the input range of the analog input channels. If this pin
+ is tied to a logic high, the analog input range is ±10V for all channels.
+ On the AD760X, if this pin is tied to a logic low, the analog input range
is ±5V for all channels. As the line is active high, it should be marked
- GPIO_ACTIVE_HIGH.
- maxItems: 1
+ GPIO_ACTIVE_HIGH. On the AD7616, there are 2 pins, and if the 2 pins are
+ tied to a logic high, software mode is enabled, otherwise one of the 3
+ possible range values is selected.
+ minItems: 1
+ maxItems: 2
adi,oversampling-ratio-gpios:
description:
- Must be the device tree identifier of the over-sampling
- mode pins. As the line is active high, it should be marked
- GPIO_ACTIVE_HIGH.
+ Must be the device tree identifier of the over-sampling mode pins. As the
+ line is active high, it should be marked GPIO_ACTIVE_HIGH. On the AD7606X
+ parts that support it, if all 3 pins are tied to a logic high, software
+ mode is enabled.
maxItems: 3
adi,sw-mode:
description:
- Software mode of operation, so far available only for ad7616 and ad7606b.
- It is enabled when all three oversampling mode pins are connected to
- high level. The device is configured by the corresponding registers. If the
- adi,oversampling-ratio-gpios property is defined, then the driver will set the
- oversampling gpios to high. Otherwise, it is assumed that the pins are hardwired
- to VDD.
+ Software mode of operation, so far available only for AD7616 and AD7606B.
+ It is enabled when all three oversampling mode pins are connected to high
+ level for the AD7606B, or both the range selection are connected to high
+ level for the AD7616. The device is configured by the corresponding
+ registers. If the adi,oversampling-ratio-gpios property is defined, then
+ the driver will set the oversampling gpios to high. Otherwise, it is
+ assumed that the pins are hardwired to VDD.
type: boolean
+ pwms:
+ description:
+ In case the conversion is triggered by a PWM instead of a GPIO plugged to
+ the CONVST pin, the PWM must be referenced.
+ The first is the PWM connected to CONVST or CONVST1 for the chips with the
+ 2nd PWM connected to CONVST2, if CONVST2 is available and not shorted to
+ CONVST1.
+ minItems: 1
+ maxItems: 2
+
+ pwm-names:
+ minItems: 1
+ items:
+ - const: convst1
+ - const: convst2
+
+ io-backends:
+ description:
+ A reference to the iio-backend, which is responsible handling the BUSY
+ pin's falling edge and communication.
+ An example of backend can be found at
+ http://analogdevicesinc.github.io/hdl/library/axi_ad7606x/index.html
+
+patternProperties:
+ "^channel@[1-8]$":
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ The channel number, as specified in the datasheet (from 1 to 8).
+ minimum: 1
+ maximum: 8
+
+ diff-channels:
+ description:
+ Each channel can be configured as a bipolar differential channel.
+ The ADC uses the same positive and negative inputs for this.
+ This property must be specified as 'reg' (or the channel number) for
+ both positive and negative inputs (i.e. diff-channels = <reg reg>).
+ Since the configuration is bipolar differential, the 'bipolar'
+ property is required.
+ items:
+ minimum: 1
+ maximum: 8
+
+ bipolar:
+ description:
+ The ADC channels can be configured as
+ * Bipolar single-ended
+ * Unipolar single-ended
+ * Bipolar differential
+ Therefore in the DT, if no channel node is specified, it is considered
+ 'unipolar single-ended'. So for the other configurations the 'bipolar'
+ property must be specified. If 'diff-channels' is specified, it is
+ considered a bipolar differential channel. Otherwise it is bipolar
+ single-ended.
+
+ adi,rfilter-ohms:
+ description:
+ For ADCs that supports gain calibration, this property must be set to
+ the value of the external RFilter resistor. Proper gain error
+ correction is applied based on this value.
+ default: 0
+ minimum: 0
+ maximum: 64512
+
+ required:
+ - reg
+ - bipolar
+
required:
- compatible
- reg
- - spi-cpha
- avcc-supply
- - interrupts
- - adi,conversion-start-gpios
+ - vdrive-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ - oneOf:
+ - required:
+ - adi,conversion-start-gpios
+ - required:
+ - pwms
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,ad7616
+ then:
+ properties:
+ adi,first-data-gpios: false
+ standby-gpios: false
+ adi,range-gpios:
+ maxItems: 2
+ else:
+ properties:
+ adi,range-gpios:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7605-4
+ - adi,ad7616
+ then:
+ properties:
+ adi,oversampling-ratio-gpios: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7605-4
+ - adi,ad7606-4
+ - adi,ad7606-6
+ - adi,ad7606-8
+ - adi,ad7607
+ - adi,ad7608
+ - adi,ad7609
+ - adi,ad7616
+ then:
+ patternProperties:
+ "^channel@[0-9a-f]+$":
+ properties:
+ adi,rfilter-ohms: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7605-4
+ - adi,ad7606-4
+ - adi,ad7606-6
+ - adi,ad7606-8
+ - adi,ad7607
+ - adi,ad7608
+ - adi,ad7609
+ then:
+ properties:
+ adi,sw-mode: false
+ else:
+ properties:
+ pwms:
+ maxItems: 1
+ pwm-names:
+ maxItems: 1
+ adi,conversion-start-gpios:
+ maxItems: 1
+
+ - if:
+ not:
+ required:
+ - adi,sw-mode
+ then:
+ patternProperties:
+ "^channel@[1-8]$": false
-additionalProperties: false
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - adi,ad7606c-16
+ - adi,ad7606c-18
+ then:
+ patternProperties:
+ "^channel@[1-8]$": false
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ iio-backend {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adi_adc@0 {
+ compatible = "adi,ad7606b";
+ reg = <0>;
+ pwms = <&axi_pwm_gen 0 0>;
+
+ avcc-supply = <&adc_vref>;
+ vdrive-supply = <&vdd_supply>;
+
+ reset-gpios = <&gpio0 91 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;
+ adi,range-gpios = <&gpio0 89 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio0 88 GPIO_ACTIVE_HIGH
+ &gpio0 87 GPIO_ACTIVE_HIGH
+ &gpio0 86 GPIO_ACTIVE_HIGH>;
+ io-backends = <&iio_backend>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7606-8";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+
+ avcc-supply = <&adc_vref>;
+ vdrive-supply = <&vdd_supply>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+
+ adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
+ adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
+ <&gpio 23 GPIO_ACTIVE_HIGH>,
+ <&gpio 26 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
- compatible = "adi,ad7606-8";
- reg = <0>;
- spi-max-frequency = <1000000>;
- spi-cpol;
- spi-cpha;
-
- avcc-supply = <&adc_vref>;
-
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- interrupt-parent = <&gpio>;
-
- adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
- adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
- adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
- <&gpio 23 GPIO_ACTIVE_HIGH>,
- <&gpio 26 GPIO_ACTIVE_HIGH>;
- standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
- adi,sw-mode;
+ compatible = "adi,ad7606c-18";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi-max-frequency = <1000000>;
+ spi-cpol;
+
+ avcc-supply = <&adc_vref>;
+ vdrive-supply = <&vdd_supply>;
+
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+
+ adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
+ adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+
+ adi,sw-mode;
+
+ channel@1 {
+ reg = <1>;
+ diff-channels = <1 1>;
+ bipolar;
+ };
+
+ channel@3 {
+ reg = <3>;
+ bipolar;
+ };
+
+ channel@8 {
+ reg = <8>;
+ diff-channels = <8 8>;
+ bipolar;
+ adi,rfilter-ohms = <2048>;
+ };
+
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7625.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7625.yaml
new file mode 100644
index 000000000000..8848562af28f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7625.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7625.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices Fast PulSAR Analog to Digital Converters
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ A family of single channel differential analog to digital converters.
+
+ * https://www.analog.com/en/products/ad7625.html
+ * https://www.analog.com/en/products/ad7626.html
+ * https://www.analog.com/en/products/ad7960.html
+ * https://www.analog.com/en/products/ad7961.html
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7625
+ - adi,ad7626
+ - adi,ad7960
+ - adi,ad7961
+
+ vdd1-supply: true
+ vdd2-supply: true
+ vio-supply: true
+
+ ref-supply:
+ description:
+ Voltage regulator for the external reference voltage (REF).
+
+ refin-supply:
+ description:
+ Voltage regulator for the reference buffer input (REFIN).
+
+ clocks:
+ description:
+ The clock connected to the CLK pins, gated by the clk_gate PWM.
+ maxItems: 1
+
+ pwms:
+ items:
+ - description: PWM connected to the CNV input on the ADC.
+ - description: PWM that gates the clock connected to the ADC's CLK input.
+
+ pwm-names:
+ items:
+ - const: cnv
+ - const: clk_gate
+
+ io-backends:
+ description:
+ The AXI ADC IP block connected to the D+/- and DCO+/- lines of the
+ ADC. An example backend can be found at
+ http://analogdevicesinc.github.io/hdl/projects/pulsar_lvds/index.html.
+ maxItems: 1
+
+ adi,no-dco:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates the wiring of the DCO+/- lines. If true, then they are
+ grounded and the device is in self-clocked mode. If this is not
+ present, then the device is in echoed clock mode.
+
+ adi,en0-always-on:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates if EN0 is hard-wired to the high state. If neither this
+ nor en0-gpios are present, then EN0 is hard-wired low.
+
+ adi,en1-always-on:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates if EN1 is hard-wired to the high state. If neither this
+ nor en1-gpios are present, then EN1 is hard-wired low.
+
+ adi,en2-always-on:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates if EN2 is hard-wired to the high state. If neither this
+ nor en2-gpios are present, then EN2 is hard-wired low.
+
+ adi,en3-always-on:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates if EN3 is hard-wired to the high state. If neither this
+ nor en3-gpios are present, then EN3 is hard-wired low.
+
+ en0-gpios:
+ description:
+ Configurable EN0 pin.
+
+ en1-gpios:
+ description:
+ Configurable EN1 pin.
+
+ en2-gpios:
+ description:
+ Configurable EN2 pin.
+
+ en3-gpios:
+ description:
+ Configurable EN3 pin.
+
+required:
+ - compatible
+ - vdd1-supply
+ - vdd2-supply
+ - vio-supply
+ - clocks
+ - pwms
+ - pwm-names
+ - io-backends
+
+allOf:
+ - if:
+ required:
+ - ref-supply
+ then:
+ properties:
+ refin-supply: false
+ - if:
+ required:
+ - refin-supply
+ then:
+ properties:
+ ref-supply: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7625
+ - adi,ad7626
+ then:
+ properties:
+ en2-gpios: false
+ en3-gpios: false
+ adi,en2-always-on: false
+ adi,en3-always-on: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad7960
+ - adi,ad7961
+ then:
+ # ad796x parts must have one of the two supplies
+ oneOf:
+ - required: [ref-supply]
+ - required: [refin-supply]
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ adc {
+ compatible = "adi,ad7625";
+ vdd1-supply = <&supply_5V>;
+ vdd2-supply = <&supply_2_5V>;
+ vio-supply = <&supply_2_5V>;
+ io-backends = <&axi_adc>;
+ clocks = <&ref_clk>;
+ pwms = <&axi_pwm_gen 0 0>, <&axi_pwm_gen 1 0>;
+ pwm-names = "cnv", "clk_gate";
+ en0-gpios = <&gpio0 86 GPIO_ACTIVE_HIGH>;
+ en1-gpios = <&gpio0 87 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
index a85a28145ef6..c06d0fc791d3 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
@@ -26,7 +26,26 @@ properties:
clock-names:
const: mclk
+ trigger-sources:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 2
+ description: |
+ A list of phandles referencing trigger source providers. Each entry
+ represents a trigger source for the ADC:
+
+ - First entry specifies the device responsible for driving the
+ synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios.
+ This can be a `gpio-trigger` or another `ad7768-1` device. If the
+ device's own SYNC_OUT pin is internally connected to its SYNC_IN pin,
+ reference the device itself or omit this property.
+ - Second entry optionally defines a GPIO3 pin used as a START signal trigger.
+
+ Use the accompanying trigger source cell to identify the type of each entry.
+
interrupts:
+ description:
+ DRDY (Data Ready) pin, which signals conversion results are available.
maxItems: 1
'#address-cells':
@@ -47,11 +66,22 @@ properties:
in any way, for example if the filter decimation rate changes.
As the line is active low, it should be marked GPIO_ACTIVE_LOW.
+ regulators:
+ type: object
+ description:
+ list of regulators provided by this controller.
+
+ properties:
+ vcm-output:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
reset-gpios:
maxItems: 1
- spi-max-frequency: true
-
spi-cpol: true
spi-cpha: true
@@ -59,6 +89,23 @@ properties:
"#io-channel-cells":
const: 1
+ "#trigger-source-cells":
+ description: |
+ Cell indicates the trigger output signal: 0 = SYNC_OUT, 1 = GPIO3,
+ 2 = DRDY.
+
+ For better readability, macros for these values are available in
+ dt-bindings/iio/adc/adi,ad7768-1.h.
+ const: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ The first cell is for the GPIO number: 0 to 3.
+ The second cell takes standard GPIO flags.
+
required:
- compatible
- reg
@@ -67,7 +114,16 @@ required:
- vref-supply
- spi-cpol
- spi-cpha
- - adi,sync-in-gpios
+
+dependencies:
+ adi,sync-in-gpios:
+ not:
+ required:
+ - trigger-sources
+ trigger-sources:
+ not:
+ required:
+ - adi,sync-in-gpios
patternProperties:
"^channel@([0-9]|1[0-5])$":
@@ -88,7 +144,10 @@ patternProperties:
- reg
additionalProperties: false
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -104,6 +163,8 @@ examples:
spi-max-frequency = <2000000>;
spi-cpol;
spi-cpha;
+ gpio-controller;
+ #gpio-cells = <2>;
vref-supply = <&adc_vref>;
interrupts = <25 IRQ_TYPE_EDGE_RISING>;
interrupt-parent = <&gpio>;
@@ -119,6 +180,12 @@ examples:
reg = <0>;
label = "channel_0";
};
+
+ regulators {
+ vcm_reg: vcm-output {
+ regulator-name = "ad7768-1-vcm";
+ };
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7779.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7779.yaml
new file mode 100644
index 000000000000..ba3f7b2bd6cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7779.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7779.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD777X family 8-Channel, 24-Bit, Simultaneous Sampling ADCs
+
+maintainers:
+ - Ramona Nechita <ramona.nechita@analog.com>
+
+description: |
+ The AD777X family consist of 8-channel, simultaneous sampling analog-to-
+ digital converter (ADC). Eight full Σ-Δ ADCs are on-chip. The
+ AD7771 provides an ultralow input current to allow direct sensor
+ connection. Each input channel has a programmable gain stage
+ allowing gains of 1, 2, 4, and 8 to map lower amplitude sensor
+ outputs into the full-scale ADC input range, maximizing the
+ dynamic range of the signal chain.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7770.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7771.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad7779.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7770
+ - adi,ad7771
+ - adi,ad7779
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ avdd1-supply:
+ description: Front-End analog supply AVDD1. Can be used as conversion ref.
+
+ avdd2-supply:
+ description: AVDD2 Analog Supply from 2.2 V to 3.6 V.
+
+ avdd4-supply:
+ description: AVDD4 SAR Analog Supply and Reference Source.
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: |
+ adc_rdy: Interrupt line for DRDY signal which indicates the end of
+ conversion independently of the interface selected to read back the
+ Σ-∆ conversion.
+ - description: |
+ Alert: The chip includes self diagnostic features to guarantee the
+ correct operation. If an error is detected, the ALERT pin is pulled
+ high to generate an external interruption to the controller.
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - adc_rdy
+ - alert
+
+ start-gpios:
+ description:
+ Pin that controls start synchronization pulse.
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ io-backends:
+ maxItems: 1
+
+ adi,num-lanes:
+ description:
+ Number of lanes on which the data is sent on the output when the data
+ output interface is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4]
+ default: 4
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ not:
+ required:
+ - io-backends
+ then:
+ properties:
+ adi,num-lanes: false
+
+oneOf:
+ - required:
+ - interrupts
+ - required:
+ - io-backends
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7779";
+ reg = <0>;
+ start-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio0 93 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "adc_rdy";
+ clocks = <&adc_clk>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ad7779";
+ reg = <0>;
+ start-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio0 93 GPIO_ACTIVE_LOW>;
+ clocks = <&adc_clk>;
+ io-backends = <&iio_backend>;
+ adi,num-lanes = <4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
index a67ba67dab51..5c8df45bfab0 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
@@ -63,6 +63,17 @@ properties:
marked GPIO_ACTIVE_LOW.
maxItems: 1
+ rdy-gpios:
+ description:
+ GPIO reading the R̅D̅Y̅ line. Having such a GPIO is technically optional but
+ highly recommended because DOUT/R̅D̅Y̅ toggles during SPI transfers (in its
+ DOUT aka MISO role) and so usually triggers a spurious interrupt. The
+ distinction between such a spurious event and a real one can only be done
+ by reading such a GPIO. (There is a register telling the same
+ information, but accessing that one needs a SPI transfer which then
+ triggers another interrupt event.)
+ maxItems: 1
+
required:
- compatible
- reg
@@ -72,7 +83,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -80,9 +91,9 @@ examples:
compatible = "adi,ad7780";
reg = <0>;
- avdd-supply = <&vdd_supply>;
- powerdown-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
- adi,gain-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&vdd_supply>;
+ powerdown-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+ adi,gain-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
adi,filter-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml
index e82194974eea..85148338c597 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml
@@ -8,11 +8,10 @@ title: Analog Devices AD7923 and similars with 4 and 8 Channel ADCs.
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
- - Patrick Vasseur <patrick.vasseur@c-s.fr>
description: |
Analog Devices AD7904, AD7914, AD7923, AD7924 4 Channel ADCs, and AD7908,
- AD7918, AD7928 8 Channels ADCs.
+ AD7918, AD7927, AD7928 8 Channels ADCs.
Specifications about the part can be found at:
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7923.pdf
@@ -21,14 +20,22 @@ description: |
properties:
compatible:
- enum:
- - adi,ad7904
- - adi,ad7914
- - adi,ad7923
- - adi,ad7924
- - adi,ad7908
- - adi,ad7918
- - adi,ad7928
+ oneOf:
+ - enum:
+ - adi,ad7904
+ - adi,ad7908
+ - adi,ad7914
+ - adi,ad7918
+ - adi,ad7923
+ - adi,ad7928
+ - const: adi,ad7924
+ deprecated: true
+ - items:
+ - const: adi,ad7924
+ - const: adi,ad7923
+ - items:
+ - const: adi,ad7927
+ - const: adi,ad7928
reg:
maxItems: 1
@@ -37,19 +44,24 @@ properties:
description: |
The regulator supply for ADC reference voltage.
+ adi,range-double:
+ description: Sets the analog input range from 0 to 2xVREF.
+ type: boolean
+
'#address-cells':
const: 1
'#size-cells':
const: 0
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
new file mode 100644
index 000000000000..d17d184842d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7944.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7944.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices PulSAR LFCSP Analog to Digital Converters
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ A family of pin-compatible single channel differential analog to digital
+ converters with SPI support in a LFCSP package.
+
+ * https://www.analog.com/en/products/ad7944.html
+ * https://www.analog.com/en/products/ad7985.html
+ * https://www.analog.com/en/products/ad7986.html
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ad7944
+ - adi,ad7985
+ - adi,ad7986
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 111111111
+
+ spi-cpol: true
+ spi-cpha: true
+
+ adi,spi-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ single, chain ]
+ description: |
+ This property indicates the SPI wiring configuration.
+
+ When this property is omitted, it is assumed that the device is using what
+ the datasheet calls "4-wire mode". This is the conventional SPI mode used
+ when there are multiple devices on the same bus. In this mode, the CNV
+ line is used to initiate the conversion and the SDI line is connected to
+ CS on the SPI controller.
+
+ When this property is present, it indicates that the device is using one
+ of the following alternative wiring configurations:
+
+ * single: The datasheet calls this "3-wire mode". (NOTE: The datasheet's
+ definition of 3-wire mode is NOT at all related to the standard
+ spi-3wire property!) This mode is often used when the ADC is the only
+ device on the bus. In this mode, SDI is tied to VIO, and the CNV line
+ can be connected to the CS line of the SPI controller or to a GPIO, in
+ which case the CS line of the controller is unused.
+ * chain: The datasheet calls this "chain mode". This mode is used to save
+ on wiring when multiple ADCs are used. In this mode, the SDI line of
+ one chip is tied to the SDO of the next chip in the chain and the SDI of
+ the last chip in the chain is tied to GND. Only the first chip in the
+ chain is connected to the SPI bus. The CNV line of all chips are tied
+ together. The CS line of the SPI controller can be used as the CNV line
+ only if it is active high.
+
+ '#daisy-chained-devices': true
+
+ avdd-supply:
+ description: A 2.5V supply that powers the analog circuitry.
+
+ dvdd-supply:
+ description: A 2.5V supply that powers the digital circuitry.
+
+ vio-supply:
+ description:
+ A 1.8V to 2.7V supply for the digital inputs and outputs.
+
+ bvdd-supply:
+ description:
+ A voltage supply for the buffered power. When using an external reference
+ without an internal buffer (PDREF high, REFIN low), this should be
+ connected to the same supply as ref-supply. Otherwise, when using an
+ internal reference or an external reference with an internal buffer, this
+ is connected to a 5V supply.
+
+ ref-supply:
+ description:
+ Voltage regulator for the external reference voltage (REF). This property
+ is omitted when using an internal reference.
+
+ refin-supply:
+ description:
+ Voltage regulator for the reference buffer input (REFIN). When using an
+ external buffer with internal reference, this should be connected to a
+ 1.2V external reference voltage supply. Otherwise, this property is
+ omitted.
+
+ cnv-gpios:
+ description:
+ The Convert Input (CNV). This input has multiple functions. It initiates
+ the conversions and selects the SPI mode of the device (chain or CS). In
+ 'single' mode, this property is omitted if the CNV pin is connected to the
+ CS line of the SPI controller.
+ maxItems: 1
+
+ turbo-gpios:
+ description:
+ GPIO connected to the TURBO line. If omitted, it is assumed that the TURBO
+ line is hard-wired and the state is determined by the adi,always-turbo
+ property.
+ maxItems: 1
+
+ adi,always-turbo:
+ type: boolean
+ description:
+ When present, this property indicates that the TURBO line is hard-wired
+ and the state is always high. If neither this property nor turbo-gpios is
+ present, the TURBO line is assumed to be hard-wired and the state is
+ always low.
+
+ interrupts:
+ description:
+ The SDO pin can also function as a busy indicator. This node should be
+ connected to an interrupt that is triggered when the SDO line goes low
+ while the SDI line is high and the CNV line is low ('single' mode) or the
+ SDI line is low and the CNV line is high ('multi' mode); or when the SDO
+ line goes high while the SDI and CNV lines are high (chain mode),
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - vio-supply
+ - bvdd-supply
+
+allOf:
+ # ref-supply and refin-supply are mutually exclusive (neither is also valid)
+ - if:
+ required:
+ - ref-supply
+ then:
+ properties:
+ refin-supply: false
+ - if:
+ required:
+ - refin-supply
+ then:
+ properties:
+ ref-supply: false
+ # in '4-wire' mode, cnv-gpios is required, for other modes it is optional
+ - if:
+ not:
+ required:
+ - adi,spi-mode
+ then:
+ required:
+ - cnv-gpios
+ # chain mode has lower SCLK max rate and doesn't work when TURBO is enabled
+ - if:
+ required:
+ - adi,spi-mode
+ properties:
+ adi,spi-mode:
+ const: chain
+ then:
+ properties:
+ spi-max-frequency:
+ maximum: 90909090
+ adi,always-turbo: false
+ required:
+ - '#daisy-chained-devices'
+ else:
+ properties:
+ '#daisy-chained-devices': false
+ # turbo-gpios and adi,always-turbo are mutually exclusive
+ - if:
+ required:
+ - turbo-gpios
+ then:
+ properties:
+ adi,always-turbo: false
+ - if:
+ required:
+ - adi,always-turbo
+ then:
+ properties:
+ turbo-gpios: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc@0 {
+ compatible = "adi,ad7944";
+ reg = <0>;
+ spi-cpha;
+ spi-max-frequency = <111111111>;
+ avdd-supply = <&supply_2_5V>;
+ dvdd-supply = <&supply_2_5V>;
+ vio-supply = <&supply_1_8V>;
+ bvdd-supply = <&supply_5V>;
+ cnv-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
+ turbo-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml
index 0b10ed5f74ae..238a8c9c4143 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7949.yaml
@@ -48,9 +48,6 @@ properties:
enum: [2500000, 4096000]
default: 4096000
-
- spi-max-frequency: true
-
'#io-channel-cells':
const: 1
@@ -64,7 +61,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml
index 29641ce7175b..433ed2c9295f 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad799x.yaml
@@ -57,17 +57,17 @@ additionalProperties: false
examples:
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- adc1: adc@28 {
- reg = <0x28>;
- compatible = "adi,ad7991";
- interrupts = <13 2>;
- interrupt-parent = <&gpio6>;
+ adc1: adc@28 {
+ reg = <0x28>;
+ compatible = "adi,ad7991";
+ interrupts = <13 2>;
+ interrupt-parent = <&gpio6>;
- vcc-supply = <&vcc_3v3>;
- vref-supply = <&adc_vref>;
+ vcc-supply = <&vcc_3v3>;
+ vref-supply = <&adc_vref>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
index 2d72ff6bcbc0..2606c0c5dfc6 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad9467.yaml
@@ -28,6 +28,9 @@ properties:
- adi,ad9265
- adi,ad9434
- adi,ad9467
+ - adi,ad9643
+ - adi,ad9649
+ - adi,ad9652
reg:
maxItems: 1
@@ -44,6 +47,9 @@ properties:
Pin that controls the powerdown mode of the device.
maxItems: 1
+ io-backends:
+ maxItems: 1
+
reset-gpios:
description:
Reset pin for the device.
@@ -64,10 +70,11 @@ examples:
#size-cells = <0>;
adc@0 {
- compatible = "adi,ad9467";
- reg = <0>;
- clocks = <&adc_clk>;
- clock-names = "adc-clk";
+ compatible = "adi,ad9467";
+ reg = <0>;
+ clocks = <&adc_clk>;
+ clock-names = "adc-clk";
+ io-backends = <&iio_backend>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
new file mode 100644
index 000000000000..f22eba0250ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2025 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ade9000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADE9000 High Performance, Polyphase Energy Metering
+
+maintainers:
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description: |
+ The ADE9000 is a highly accurate, fully integrated, multiphase energy and power
+ quality monitoring device. Superior analog performance and a digital signal
+ processing (DSP) core enable accurate energy monitoring over a wide dynamic
+ range. An integrated high end reference ensures low drift over temperature
+ with a combined drift of less than ±25 ppm/°C maximum for the entire channel
+ including a programmable gain amplifier (PGA) and an analog-to-digital
+ converter (ADC).
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9000.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,ade9000
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 20000000
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ enum: [irq0, irq1, dready]
+ minItems: 1
+ maxItems: 3
+
+ reset-gpios:
+ description:
+ Must be the device tree identifier of the RESET pin. As the line is
+ active low, it should be marked GPIO_ACTIVE_LOW.
+ maxItems: 1
+
+ vdd-supply: true
+
+ vref-supply: true
+
+ clocks:
+ description: External clock source when not using crystal
+ maxItems: 1
+
+ "#clock-cells":
+ description:
+ ADE9000 can provide clock output via CLKOUT pin with external buffer.
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,ade9000";
+ reg = <0>;
+ spi-max-frequency = <7000000>;
+
+ #clock-cells = <0>;
+ reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>, <3 IRQ_TYPE_EDGE_FALLING>, <4 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "irq0", "irq1", "dready";
+ interrupt-parent = <&gpio>;
+ clocks = <&ext_clock_24576khz>;
+ vdd-supply = <&vdd_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
index 8e25773d69be..e91e421a3d6b 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
@@ -17,17 +17,34 @@ description: |
interface for the actual ADC, while this IP core will interface
to the data-lines of the ADC and handle the streaming of data into
memory via DMA.
+ In some cases, the AXI ADC interface is used to perform specialized
+ operation to a particular ADC, e.g access the physical bus through
+ specific registers to write ADC registers.
+ In this case, we use a different compatible which indicates the target
+ IP core's name.
+ The following IP is currently supported:
+ - AXI AD7606x: specialized version of the IP core for all the chips from
+ the ad7606 family.
https://wiki.analog.com/resources/fpga/docs/axi_adc_ip
+ https://analogdevicesinc.github.io/hdl/library/axi_ad408x/index.html
+ https://analogdevicesinc.github.io/hdl/library/axi_ad485x/index.html
+ http://analogdevicesinc.github.io/hdl/library/axi_ad7606x/index.html
properties:
compatible:
enum:
- adi,axi-adc-10.0.a
+ - adi,axi-ad408x
+ - adi,axi-ad7606x
+ - adi,axi-ad485x
reg:
maxItems: 1
+ clocks:
+ maxItems: 1
+
dmas:
maxItems: 1
@@ -39,23 +56,85 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description:
A reference to a the actual ADC to which this FPGA ADC interfaces to.
+ deprecated: true
+
+ '#io-backend-cells':
+ const: 0
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^adc@[0-9a-f]+$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+ additionalProperties: true
+ required:
+ - compatible
+ - reg
required:
- compatible
- dmas
- reg
- - adi,adc-dev
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: adi,axi-ad7606x
+ then:
+ properties:
+ '#address-cells': false
+ '#size-cells': false
+ patternProperties:
+ "^adc@[0-9a-f]+$": false
additionalProperties: false
examples:
- |
- axi-adc@44a00000 {
- compatible = "adi,axi-adc-10.0.a";
- reg = <0x44a00000 0x10000>;
- dmas = <&rx_dma 0>;
- dma-names = "rx";
+ adc@44a00000 {
+ compatible = "adi,axi-adc-10.0.a";
+ reg = <0x44a00000 0x10000>;
+ dmas = <&rx_dma 0>;
+ dma-names = "rx";
+ clocks = <&axi_clk>;
+ #io-backend-cells = <0>;
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ parallel_bus_controller@44a00000 {
+ compatible = "adi,axi-ad7606x";
+ reg = <0x44a00000 0x10000>;
+ dmas = <&rx_dma 0>;
+ dma-names = "rx";
+ clocks = <&ext_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- adi,adc-dev = <&spi_adc>;
+ adc@0 {
+ compatible = "adi,ad7606b";
+ reg = <0>;
+ pwms = <&axi_pwm_gen 0 0>;
+ pwm-names = "convst1";
+ avcc-supply = <&adc_vref>;
+ vdrive-supply = <&vdd_supply>;
+ reset-gpios = <&gpio0 91 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;
+ adi,range-gpios = <&gpio0 89 GPIO_ACTIVE_HIGH>;
+ adi,oversampling-ratio-gpios = <&gpio0 88 GPIO_ACTIVE_HIGH
+ &gpio0 87 GPIO_ACTIVE_HIGH
+ &gpio0 86 GPIO_ACTIVE_HIGH>;
+ io-backends = <&parallel_bus_controller>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,max11410.yaml b/Documentation/devicetree/bindings/iio/adc/adi,max11410.yaml
new file mode 100644
index 000000000000..53f9feff137b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,max11410.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2022 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,max11410.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX11410 ADC device driver
+
+maintainers:
+ - Ibrahim Tilki <Ibrahim.Tilki@analog.com>
+
+description: |
+ Bindings for the Analog Devices MAX11410 ADC device. Datasheet can be
+ found here:
+ https://datasheets.maximintegrated.com/en/ds/MAX11410.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,max11410
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ description: Name of the gpio pin of max11410 used for IRQ
+ minItems: 1
+ items:
+ - enum: [gpio0, gpio1]
+ - const: gpio1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ avdd-supply:
+ description: Optional avdd supply. Used as reference when no explicit reference supplied.
+
+ vref0p-supply:
+ description: vref0p supply can be used as reference for conversion.
+
+ vref1p-supply:
+ description: vref1p supply can be used as reference for conversion.
+
+ vref2p-supply:
+ description: vref2p supply can be used as reference for conversion.
+
+ vref0n-supply:
+ description: vref0n supply can be used as reference for conversion.
+
+ vref1n-supply:
+ description: vref1n supply can be used as reference for conversion.
+
+ vref2n-supply:
+ description: vref2n supply can be used as reference for conversion.
+
+ spi-max-frequency:
+ maximum: 8000000
+
+patternProperties:
+ "^channel(@[0-9])?$":
+ $ref: adc.yaml
+ type: object
+ description: Represents the external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description: The channel number in single-ended mode.
+ minimum: 0
+ maximum: 9
+
+ adi,reference:
+ description: |
+ Select the reference source to use when converting on
+ the specific channel. Valid values are:
+ 0: VREF0P/VREF0N
+ 1: VREF1P/VREF1N
+ 2: VREF2P/VREF2N
+ 3: AVDD/AGND
+ 4: VREF0P/AGND
+ 5: VREF1P/AGND
+ 6: VREF2P/AGND
+ If this field is left empty, AVDD/AGND is selected.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6]
+ default: 3
+
+ adi,input-mode:
+ description: |
+ Select signal path of input channels. Valid values are:
+ 0: Buffered, low-power, unity-gain path (default)
+ 1: Bypass path
+ 2: PGA path
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ default: 0
+
+ diff-channels: true
+
+ bipolar: true
+
+ settling-time-us: true
+
+ adi,buffered-vrefp:
+ description: Enable buffered mode for positive reference.
+ type: boolean
+
+ adi,buffered-vrefn:
+ description: Enable buffered mode for negative reference.
+ type: boolean
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ reg = <0>;
+ compatible = "adi,max11410";
+ spi-max-frequency = <8000000>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "gpio1";
+
+ avdd-supply = <&adc_avdd>;
+
+ vref1p-supply = <&adc_vref1p>;
+ vref1n-supply = <&adc_vref1n>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ diff-channels = <2 3>;
+ adi,reference = <1>;
+ bipolar;
+ settling-time-us = <100000>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ diff-channels = <7 9>;
+ adi,reference = <5>;
+ adi,input-mode = <2>;
+ settling-time-us = <50000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,max14001.yaml b/Documentation/devicetree/bindings/iio/adc/adi,max14001.yaml
new file mode 100644
index 000000000000..a2dc59c9dcd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,max14001.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023-2025 Analog Devices Inc.
+# Copyright 2023 Kim Seer Paller
+# Copyright 2025 Marilene Andrade Garcia
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,max14001.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX14001-MAX14002 ADC
+
+maintainers:
+ - Kim Seer Paller <kimseer.paller@analog.com>
+ - Marilene Andrade Garcia <marilene.agarcia@gmail.com>
+
+description: |
+ Single channel 10 bit ADC with SPI interface.
+ Datasheet can be found here
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf
+
+$ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: adi,max14002
+ - items:
+ - const: adi,max14001
+ - const: adi,max14002
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 5000000
+
+ vdd-supply:
+ description:
+ Isolated DC-DC power supply input voltage.
+
+ vddl-supply:
+ description:
+ Logic power supply.
+
+ refin-supply:
+ description:
+ ADC voltage reference supply.
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: |
+ cout: comparator output signal that asserts high on the COUT pin
+ when ADC readings exceed the upper threshold and low when readings
+ fall below the lower threshold.
+ - description: |
+ fault: when fault reporting is enabled, the FAULT pin is asserted
+ low whenever one of the monitored fault conditions occurs.
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: cout
+ - const: fault
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddl-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "adi,max14001", "adi,max14002";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-lsb-first;
+ vdd-supply = <&vdd>;
+ vddl-supply = <&vddl>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
new file mode 100644
index 000000000000..da605a051b94
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/allwinner,sun20i-d1-gpadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1 General Purpose ADC
+
+maintainers:
+ - Maksim Kiselev <bigunclemax@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - allwinner,sun20i-d1-gpadc
+ - items:
+ - enum:
+ - allwinner,sun50i-h616-gpadc
+ - const: allwinner,sun20i-d1-gpadc
+
+ "#io-channel-cells":
+ const: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ "^channel@[0-9a-f]+$":
+ $ref: adc.yaml
+ type: object
+ description:
+ Represents the internal channels of the ADC.
+
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 15
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+required:
+ - "#io-channel-cells"
+ - clocks
+ - compatible
+ - interrupts
+ - reg
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sun20i-d1-ccu.h>
+ #include <dt-bindings/reset/sun20i-d1-ccu.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpadc: adc@2009000 {
+ compatible = "allwinner,sun20i-d1-gpadc";
+ reg = <0x2009000 0x400>;
+ clocks = <&ccu CLK_BUS_GPADC>;
+ resets = <&ccu RST_BUS_GPADC>;
+ interrupts = <73 IRQ_TYPE_LEVEL_HIGH>;
+ #io-channel-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml b/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
index 15c514b83583..a73a355fc665 100644
--- a/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/allwinner,sun8i-a33-ths.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/allwinner,sun8i-a33-ths.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A33 Thermal Sensor Device Tree Bindings
+title: Allwinner A33 Thermal Sensor
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
index 7e8328e9ce13..bb9825e7346d 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
@@ -23,6 +23,7 @@ properties:
- amlogic,meson8m2-saradc
- amlogic,meson-gxbb-saradc
- amlogic,meson-gxl-saradc
+ - amlogic,meson-gxlx-saradc
- amlogic,meson-gxm-saradc
- amlogic,meson-axg-saradc
- amlogic,meson-g12a-saradc
@@ -66,6 +67,9 @@ properties:
nvmem-cell-names:
const: temperature_calib
+ power-domains:
+ maxItems: 1
+
allOf:
- if:
properties:
@@ -95,6 +99,7 @@ allOf:
compatible:
contains:
enum:
+ - amlogic,meson8-saradc
- amlogic,meson8b-saradc
- amlogic,meson8m2-saradc
then:
diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml b/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml
index b283c8ca2bbf..509bfb1007c4 100644
--- a/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/aspeed,ast2600-adc.yaml
@@ -29,6 +29,8 @@ properties:
enum:
- aspeed,ast2600-adc0
- aspeed,ast2600-adc1
+ - aspeed,ast2700-adc0
+ - aspeed,ast2700-adc1
description:
Their trimming data, which is used to calibrate internal reference volage,
locates in different address of OTP.
@@ -62,13 +64,6 @@ properties:
description:
Inform the driver that last channel will be used to sensor battery.
- aspeed,trim-data-valid:
- type: boolean
- description: |
- The ADC reference voltage can be calibrated to obtain the trimming
- data which will be stored in otp. This property informs the driver that
- the data store in the otp is valid.
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
index 31f840d59303..4817b840977a 100644
--- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
@@ -41,7 +41,7 @@ properties:
description: Startup time expressed in ms, it depends on SoC.
atmel,trigger-edge-type:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
One of possible edge types for the ADTRG hardware trigger pin.
When the specific edge type is detected, the conversion will
diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
index e6a1f915b542..1f30a8569187 100644
--- a/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml
@@ -56,8 +56,8 @@ properties:
String corresponding to an identifier from atmel,adc-res-names property.
If not specified, the highest resolution will be used.
enum:
- - "lowres"
- - "highres"
+ - lowres
+ - highres
atmel,adc-sleep-mode:
$ref: /schemas/types.yaml#/definitions/flag
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
index 77605f17901c..9c57eb13f892 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: AVIA HX711 ADC chip for weight cells
diff --git a/Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml b/Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml
new file mode 100644
index 000000000000..6d4fb3e1d2a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/cirrus,ep9301-adc.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/cirrus,ep9301-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP930x internal ADC
+
+description: |
+ Cirrus Logic EP9301/EP9302 SoCs' internal ADC block.
+
+ User's manual:
+ https://cdn.embeddedts.com/resource-attachments/ts-7000_ep9301-ug.pdf
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+properties:
+ compatible:
+ const: cirrus,ep9301-adc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ adc: adc@80900000 {
+ compatible = "cirrus,ep9301-adc";
+ reg = <0x80900000 0x28>;
+ clocks = <&syscon 24>;
+ interrupt-parent = <&vic1>;
+ interrupts = <30>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/cosmic,10001-adc.yaml b/Documentation/devicetree/bindings/iio/adc/cosmic,10001-adc.yaml
index 4e695b97d015..9ea44ce63f25 100644
--- a/Documentation/devicetree/bindings/iio/adc/cosmic,10001-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/cosmic,10001-adc.yaml
@@ -36,7 +36,6 @@ properties:
"#io-channel-cells":
const: 1
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/iio/adc/gehc,pmc-adc.yaml b/Documentation/devicetree/bindings/iio/adc/gehc,pmc-adc.yaml
new file mode 100644
index 000000000000..2cea7c104a26
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/gehc,pmc-adc.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/gehc,pmc-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GE HealthCare PMC Analog to Digital Converter (ADC)
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The GE HealthCare PMC ADC is a 16-Channel (voltage and current), 16-Bit ADC
+ with an I2C Interface.
+
+properties:
+ compatible:
+ const: gehc,pmc-adc
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Regulator for the VDD power supply.
+
+ vdda-supply:
+ description:
+ Regulator for the VDD analog (VDDA) power supply.
+
+ vddio-supply:
+ description:
+ Regulator for the VDD IO (VDDIO) power supply.
+
+ vref-supply:
+ description:
+ Regulator for the voltage reference power supply.
+
+ clocks:
+ maxItems: 1
+ description:
+ The component uses an external oscillator (osc) if an external oscillator
+ is connected to its clock pins. Otherwise, it uses an internal reference
+ clock.
+
+ clock-names:
+ items:
+ - const: osc
+
+ "#io-channel-cells":
+ const: 2
+ description: |
+ The first cell is the channel type (dt-bindings/iio/adc/gehc,pmc-adc.h
+ defines these values):
+ - 0: voltage
+ - 1: current
+ The second cell is the channel number from 0 to 15.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vdda-supply
+ - vddio-supply
+ - vref-supply
+ - '#io-channel-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@14 {
+ compatible = "gehc,pmc-adc";
+ reg = <0x14>;
+ vdd-supply = <&reg_vdd>;
+ vdda-supply = <&reg_vdda>;
+ vddio-supply = <&reg_vddio>;
+ vref-supply = <&reg_vref>;
+ #io-channel-cells = <2>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/holt,hi8435.yaml b/Documentation/devicetree/bindings/iio/adc/holt,hi8435.yaml
index 52490cbb0af0..56bcbe5dcd79 100644
--- a/Documentation/devicetree/bindings/iio/adc/holt,hi8435.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/holt,hi8435.yaml
@@ -24,8 +24,6 @@ properties:
GPIO used for controlling the reset pin
maxItems: 1
- spi-max-frequency: true
-
"#io-channel-cells":
const: 1
@@ -33,7 +31,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
index 698beb896f76..9cd0fd539782 100644
--- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
@@ -2,10 +2,10 @@
# Copyright 2019-2020 Artur Rojek
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/ingenic,adc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/ingenic,adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic JZ47xx ADC controller IIO bindings
+title: Ingenic JZ47xx ADC controller IIO
maintainers:
- Artur Rojek <contact@artur-rojek.eu>
@@ -78,14 +78,14 @@ examples:
#include <dt-bindings/iio/adc/ingenic,adc.h>
adc@10070000 {
- compatible = "ingenic,jz4740-adc";
- #io-channel-cells = <1>;
+ compatible = "ingenic,jz4740-adc";
+ #io-channel-cells = <1>;
- reg = <0x10070000 0x30>;
+ reg = <0x10070000 0x30>;
- clocks = <&cgu JZ4740_CLK_ADC>;
- clock-names = "adc";
+ clocks = <&cgu JZ4740_CLK_ADC>;
+ clock-names = "adc";
- interrupt-parent = <&intc>;
- interrupts = <18>;
+ interrupt-parent = <&intc>;
+ interrupts = <18>;
};
diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
index 0bd2fc0356c8..eac48166fe72 100644
--- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
@@ -9,7 +9,6 @@ title: Linear Technology / Analog Devices LTC2496 ADC
maintainers:
- Lars-Peter Clausen <lars@metafoo.de>
- Michael Hennerich <Michael.Hennerich@analog.com>
- - Stefan Popa <stefan.popa@analog.com>
properties:
compatible:
@@ -22,15 +21,15 @@ properties:
reg:
maxItems: 1
- spi-max-frequency:
- description: maximal spi bus frequency supported
-
required:
- compatible
- vref-supply
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
index c1772b568cd1..5cc6a9684077 100644
--- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
@@ -4,19 +4,33 @@
$id: http://devicetree.org/schemas/iio/adc/lltc,ltc2497.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Linear Technology / Analog Devices LTC2497 ADC
+title: Linear Technology / Analog Devices LTC2497 and LTC2309 ADC
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
+ - Liam Beguin <liambeguin@gmail.com>
description: |
- 16bit ADC supporting up to 16 single ended or 8 differential inputs.
- I2C interface.
+ LTC2309:
+ low noise, low power, 8-channel, 12-bit successive approximation ADC with an
+ I2C compatible serial interface.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/2309fd.pdf
+
+ LTC2497:
+ LTC2499:
+ 16bit ADC supporting up to 16 single ended or 8 differential inputs.
+ I2C interface.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
properties:
compatible:
- const:
- lltc,ltc2497
+ enum:
+ - lltc,ltc2309
+ - lltc,ltc2497
+ - lltc,ltc2499
reg: true
vref-supply: true
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
index 46b7747076b9..e4b362113509 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1027.yaml
@@ -45,14 +45,17 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
maxadc: adc@0 {
compatible = "maxim,max1027";
reg = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max11100.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max11100.yaml
index 0cf87556ef82..4f74cb33383a 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max11100.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max11100.yaml
@@ -26,13 +26,16 @@ properties:
minimum: 100000
maximum: 4800000
-additionalProperties: false
-
required:
- compatible
- reg
- vref-supply
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1118.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1118.yaml
index e948b3e37b0c..bb336e33ebe2 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1118.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1118.yaml
@@ -28,23 +28,25 @@ properties:
vref-supply:
description: External reference, needed to establish input scaling
-if:
- properties:
- compatible:
- contains:
- const: maxim,max1118
-then:
- required:
- - vref-supply
-else:
- properties:
- vref-supply: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max1118
+ then:
+ required:
+ - vref-supply
+ else:
+ properties:
+ vref-supply: false
required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max11205.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max11205.yaml
new file mode 100644
index 000000000000..5f9e043cf5cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max11205.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/maxim,max11205.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX11205 ADC
+
+maintainers:
+ - Ramona Bolboaca <ramona.bolboaca@analog.com>
+
+description: |
+ The MAX11205 is an ultra-low-power (< 300FA max active current),
+ high-resolution, serial-output ADC.
+
+ https://datasheets.maximintegrated.com/en/ds/MAX11205.pdf
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max11205a
+ - maxim,max11205b
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 5000000
+
+ spi-cpha: true
+
+ vref-supply:
+ description:
+ The regulator supply for the ADC reference voltage. This is a differential
+ reference. It is equal to the V_REFP - V_REFN. The maximum value is 3.6V.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - spi-max-frequency
+ - spi-cpha
+ - vref-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc@0 {
+ compatible = "maxim,max11205a";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-cpha;
+ interrupt-parent = <&gpio>;
+ interrupts = <19 IRQ_TYPE_EDGE_FALLING>;
+ vref-supply = <&max11205_vref>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml
index 50bcd72ac9d6..ae3c89393f1a 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml
@@ -10,7 +10,7 @@ maintainers:
- Jonathan Cameron <jic23@kernel.org>
description: |
- Family of simple ADCs with i2c inteface and internal references.
+ Family of simple ADCs with i2c interface and internal references.
properties:
compatible:
@@ -53,6 +53,9 @@ properties:
reg:
maxItems: 1
+ "#io-channel-cells":
+ const: 1
+
vcc-supply: true
vref-supply:
description: Optional external reference. If not supplied, internal
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
index 4c7e0d94bff1..592854766583 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml
@@ -39,22 +39,23 @@ properties:
thus enabling power-down mode.
maxItems: 1
- spi-max-frequency: true
-
required:
- compatible
- reg
- vdd-supply
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
adc@0 {
compatible = "maxim,max1241";
@@ -62,6 +63,6 @@ examples:
vdd-supply = <&adc_vdd>;
vref-supply = <&adc_vref>;
spi-max-frequency = <1000000>;
- shutdown-gpios = <&gpio 26 1>;
+ shutdown-gpios = <&gpio 26 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml
index e04f09f35601..96f3f535fe34 100644
--- a/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml
@@ -10,7 +10,7 @@ maintainers:
- Jonathan Cameron <jic23@kernel.org>
description: |
- Family of ADCs with i2c inteface, internal references and threshold
+ Family of ADCs with i2c interface, internal references and threshold
monitoring.
properties:
diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max34408.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max34408.yaml
new file mode 100644
index 000000000000..4cba856e8d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/maxim,max34408.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/maxim,max34408.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX34408/MAX34409 current monitors with overcurrent control
+
+maintainers:
+ - Ivan Mikhaylov <fr0st61te@gmail.com>
+
+description: |
+ The MAX34408/MAX34409 are two- and four-channel current monitors that are
+ configured and monitored with a standard I2C/SMBus serial interface. Each
+ unidirectional current sensor offers precision high-side operation with a
+ low full-scale sense voltage. The devices automatically sequence through
+ two or four channels and collect the current-sense samples and average them
+ to reduce the effect of impulse noise. The raw ADC samples are compared to
+ user-programmable digital thresholds to indicate overcurrent conditions.
+ Overcurrent conditions trigger a hardware output to provide an immediate
+ indication to shut down any necessary external circuitry.
+
+ Specifications about the devices can be found at:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX34408-MAX34409.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,max34408
+ - maxim,max34409
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ powerdown-gpios:
+ description:
+ Shutdown Output. Open-drain output. This output transitions to high impedance
+ when any of the digital comparator thresholds are exceeded as long as the ENA
+ pin is high.
+ maxItems: 1
+
+ powerdown-status-gpios:
+ description:
+ SHTDN Enable Input. CMOS digital input. Connect to GND to clear the latch and
+ unconditionally deassert (force low) the SHTDN output and reset the shutdown
+ delay. Connect to VDD to enable normal latch operation of the SHTDN output.
+ maxItems: 1
+
+ vdd-supply: true
+
+patternProperties:
+ "^channel@[0-3]$":
+ $ref: adc.yaml
+ type: object
+ description:
+ Represents the internal channels of the ADC.
+
+ properties:
+ reg:
+ items:
+ - minimum: 0
+ maximum: 3
+
+ maxim,rsense-val-micro-ohms:
+ description:
+ Adjust the Rsense value to monitor higher or lower current levels for
+ input.
+ enum: [250, 500, 1000, 5000, 10000, 50000, 100000, 200000, 500000]
+ default: 1000
+
+ required:
+ - reg
+ - maxim,rsense-val-micro-ohms
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max34408
+ then:
+ patternProperties:
+ "^channel@[2-3]$": false
+ "^channel@[0-1]$":
+ properties:
+ reg:
+ maximum: 1
+ else:
+ patternProperties:
+ "^channel@[0-3]$":
+ properties:
+ reg:
+ maximum: 3
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@1e {
+ compatible = "maxim,max34409";
+ reg = <0x1e>;
+ powerdown-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+ powerdown-status-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0x0>;
+ maxim,rsense-val-micro-ohms = <5000>;
+ };
+
+ channel@1 {
+ reg = <0x1>;
+ maxim,rsense-val-micro-ohms = <10000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
index 7f79a06e76f5..d9e825e5054f 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml
@@ -26,6 +26,7 @@ properties:
- mediatek,mt2712-auxadc
- mediatek,mt6765-auxadc
- mediatek,mt7622-auxadc
+ - mediatek,mt7986-auxadc
- mediatek,mt8173-auxadc
- items:
- enum:
@@ -33,9 +34,15 @@ properties:
- const: mediatek,mt2701-auxadc
- items:
- enum:
+ - mediatek,mt7981-auxadc
+ - const: mediatek,mt7986-auxadc
+ - items:
+ - enum:
+ - mediatek,mt6893-auxadc
- mediatek,mt8183-auxadc
- mediatek,mt8186-auxadc
- mediatek,mt8188-auxadc
+ - mediatek,mt8189-auxadc
- mediatek,mt8195-auxadc
- mediatek,mt8516-auxadc
- const: mediatek,mt8173-auxadc
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
new file mode 100644
index 000000000000..5d4ab701f51a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6350 series PMIC AUXADC
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
+ in some MediaTek PMICs, performing various PMIC related measurements
+ such as battery and PMIC internal voltage regulators temperatures,
+ accessory detection resistance (usually, for a 3.5mm audio jack)
+ other than voltages for various PMIC internal components.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6357-auxadc
+ - mediatek,mt6358-auxadc
+ - mediatek,mt6359-auxadc
+ - mediatek,mt6363-auxadc
+ - mediatek,mt6373-auxadc
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - "#io-channel-cells"
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml
index fcc1ba53b20d..18108f0f3731 100644
--- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml
@@ -32,7 +32,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
spi-cpha: true
spi-cpol: true
@@ -51,7 +50,10 @@ required:
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
new file mode 100644
index 000000000000..675319276197
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
@@ -0,0 +1,205 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/microchip,mcp3564.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP346X and MCP356X ADC Family
+
+maintainers:
+ - Marius Cristea <marius.cristea@microchip.com>
+
+description: |
+ Bindings for the Microchip family of 153.6 ksps, Low-Noise 16/24-Bit
+ Delta-Sigma ADCs with an SPI interface. Datasheet can be found here:
+ Datasheet for MCP3561, MCP3562, MCP3564 can be found here:
+ https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP3561-2-4-Family-Data-Sheet-DS20006181C.pdf
+ Datasheet for MCP3561R, MCP3562R, MCP3564R can be found here:
+ https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3561_2_4R-Data-Sheet-DS200006391C.pdf
+ Datasheet for MCP3461, MCP3462, MCP3464 can be found here:
+ https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3461-2-4-Two-Four-Eight-Channel-153.6-ksps-Low-Noise-16-Bit-Delta-Sigma-ADC-Data-Sheet-20006180D.pdf
+ Datasheet for MCP3461R, MCP3462R, MCP3464R can be found here:
+ https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3461-2-4R-Family-Data-Sheet-DS20006404C.pdf
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp3461
+ - microchip,mcp3462
+ - microchip,mcp3464
+ - microchip,mcp3461r
+ - microchip,mcp3462r
+ - microchip,mcp3464r
+ - microchip,mcp3561
+ - microchip,mcp3562
+ - microchip,mcp3564
+ - microchip,mcp3561r
+ - microchip,mcp3562r
+ - microchip,mcp3564r
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 20000000
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ vdd-supply: true
+
+ avdd-supply: true
+
+ clocks:
+ description:
+ Phandle and clock identifier for external sampling clock.
+ If not specified, the internal crystal oscillator will be used.
+ maxItems: 1
+
+ interrupts:
+ description: IRQ line of the ADC
+ maxItems: 1
+
+ drive-open-drain:
+ description:
+ Whether to drive the IRQ signal as push-pull (default) or open-drain. Note
+ that the device requires this pin to become "high", otherwise it will stop
+ converting.
+ type: boolean
+
+ vref-supply:
+ description:
+ Some devices have a specific reference voltage supplied on a different
+ pin to the other supplies. Needed to be able to establish channel scaling
+ unless there is also an internal reference available (e.g. mcp3564r). In
+ case of "r" devices (e. g. mcp3564r), if it does not exists the internal
+ reference will be used.
+
+ microchip,hw-device-address:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ description:
+ The address is set on a per-device basis by fuses in the factory,
+ configured on request. If not requested, the fuses are set for 0x1.
+ The device address is part of the device markings to avoid
+ potential confusion. This address is coded on two bits, so four possible
+ addresses are available when multiple devices are present on the same
+ SPI bus with only one Chip Select line for all devices.
+ Each device communication starts by a CS falling edge, followed by the
+ clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
+ which is first one on the wire).
+
+ "#io-channel-cells":
+ const: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@([0-9]|([1-7][0-9]))$":
+ $ref: adc.yaml
+ type: object
+ unevaluatedProperties: false
+ description: Represents the external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description: The channel number in single-ended and differential mode.
+ minimum: 0
+ maximum: 79
+
+ required:
+ - reg
+
+dependencies:
+ spi-cpol: [ spi-cpha ]
+ spi-cpha: [ spi-cpol ]
+
+required:
+ - compatible
+ - reg
+ - microchip,hw-device-address
+ - spi-max-frequency
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - # External vref, no internal reference
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,mcp3461
+ - microchip,mcp3462
+ - microchip,mcp3464
+ - microchip,mcp3561
+ - microchip,mcp3562
+ - microchip,mcp3564
+ then:
+ required:
+ - vref-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "microchip,mcp3564r";
+ reg = <0>;
+ vref-supply = <&vref_reg>;
+ spi-cpha;
+ spi-cpol;
+ spi-max-frequency = <10000000>;
+ microchip,hw-device-address = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ /* CH0 to AGND */
+ reg = <0>;
+ label = "CH0";
+ };
+
+ channel@1 {
+ /* CH1 to AGND */
+ reg = <1>;
+ label = "CH1";
+ };
+
+ /* diff-channels */
+ channel@11 {
+ reg = <11>;
+
+ /* CN0, CN1 */
+ diff-channels = <0 1>;
+ label = "CH0_CH1";
+ };
+
+ channel@22 {
+ reg = <0x22>;
+
+ /* CN1, CN2 */
+ diff-channels = <1 2>;
+ label = "CH1_CH3";
+ };
+
+ channel@23 {
+ reg = <0x23>;
+
+ /* CN1, CN3 */
+ diff-channels = <1 3>;
+ label = "CH1_CH3";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
index 95ab285f4eba..3a69ec60edb9 100644
--- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Marcus Folkesson <marcus.folkesson@gmail.com>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/microchip,mcp3911.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/microchip,mcp3911.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip MCP3911 Dual channel analog front end (ADC)
@@ -18,7 +18,13 @@ description: |
properties:
compatible:
enum:
+ - microchip,mcp3910
- microchip,mcp3911
+ - microchip,mcp3912
+ - microchip,mcp3913
+ - microchip,mcp3914
+ - microchip,mcp3918
+ - microchip,mcp3919
reg:
maxItems: 1
@@ -26,6 +32,9 @@ properties:
spi-max-frequency:
maximum: 20000000
+ reset-gpios:
+ maxItems: 1
+
clocks:
description: |
Phandle and clock identifier for external sampling clock.
@@ -36,6 +45,13 @@ properties:
description: IRQ line of the ADC
maxItems: 1
+ microchip,data-ready-hiz:
+ description:
+ Data Ready Pin Inactive State Control
+ true = The DR pin state is high-impedance
+ false = The DR pin state is logic high
+ type: boolean
+
microchip,device-addr:
description: Device address when multiple MCP3911 chips are present on the same SPI bus.
$ref: /schemas/types.yaml#/definitions/uint32
@@ -51,10 +67,14 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -64,6 +84,7 @@ examples:
reg = <0>;
interrupt-parent = <&gpio5>;
interrupts = <15 2>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
spi-max-frequency = <20000000>;
microchip,device-addr = <0>;
vref-supply = <&vref_reg>;
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml
new file mode 100644
index 000000000000..12e56b1b3d3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,pac1921.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/microchip,pac1921.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PAC1921 High-Side Power/Current Monitor with Anaog Output
+
+maintainers:
+ - Matteo Martelli <matteomartelli3@gmail.com>
+
+description: |
+ The PAC1921 is a power/current monitoring device with an analog output
+ and I2C/SMBus interface.
+
+ Datasheet can be found here:
+ https://ww1.microchip.com/downloads/en/DeviceDoc/PAC1921-Data-Sheet-DS20005293E.pdf
+
+properties:
+ compatible:
+ const: microchip,pac1921
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ "#io-channel-cells":
+ const: 1
+
+ shunt-resistor-micro-ohms:
+ description:
+ Value in micro Ohms of the shunt resistor connected between
+ the SENSE+ and SENSE- inputs, across which the current is measured.
+ Value is needed to compute the scaling of the measured current.
+
+ label:
+ description: Unique name to identify which device this is.
+
+ read-integrate-gpios:
+ description:
+ READ/INT input pin to control the current state of the device, either in
+ the INTEGRATE state when driven high, or in the READ state when driven low.
+ When not connected the pin is floating and it can be overridden by the
+ INT_EN register bit after asserting the READ/INT_OVR register bit.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - shunt-resistor-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@4c {
+ compatible = "microchip,pac1921";
+ reg = <0x4c>;
+ vdd-supply = <&vdd>;
+ #io-channel-cells = <1>;
+ label = "vbat";
+ shunt-resistor-micro-ohms = <10000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml
new file mode 100644
index 000000000000..47a11a9ac95e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/microchip,pac1934.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PAC1934 Power Monitors with Accumulator
+
+maintainers:
+ - Marius Cristea <marius.cristea@microchip.com>
+
+description: |
+ This device is part of the Microchip family of Power Monitors with
+ Accumulator.
+ The datasheet for PAC1931, PAC1932, PAC1933 and PAC1934 can be found here:
+ https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/PAC1931-Family-Data-Sheet-DS20005850E.pdf
+
+properties:
+ compatible:
+ enum:
+ - microchip,pac1931
+ - microchip,pac1932
+ - microchip,pac1933
+ - microchip,pac1934
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ slow-io-gpios:
+ description:
+ A GPIO used to trigger a change is sampling rate (lowering the chip power
+ consumption). If configured in SLOW mode, if this pin is forced high,
+ sampling rate is forced to eight samples/second. When it is forced low,
+ the sampling rate is 1024 samples/second unless a different sample rate
+ has been programmed.
+
+patternProperties:
+ "^channel@[1-4]+$":
+ type: object
+ $ref: adc.yaml
+ description:
+ Represents the external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ items:
+ minimum: 1
+ maximum: 4
+
+ shunt-resistor-micro-ohms:
+ description:
+ Value in micro Ohms of the shunt resistor connected between
+ the SENSE+ and SENSE- inputs, across which the current is measured.
+ Value is needed to compute the scaling of the measured current.
+
+ required:
+ - reg
+ - shunt-resistor-micro-ohms
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-monitor@10 {
+ compatible = "microchip,pac1934";
+ reg = <0x10>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@1 {
+ reg = <0x1>;
+ shunt-resistor-micro-ohms = <24900000>;
+ label = "CPU";
+ };
+
+ channel@2 {
+ reg = <0x2>;
+ shunt-resistor-micro-ohms = <49900000>;
+ label = "GPU";
+ };
+
+ channel@3 {
+ reg = <0x3>;
+ shunt-resistor-micro-ohms = <75000000>;
+ label = "MEM";
+ bipolar;
+ };
+
+ channel@4 {
+ reg = <0x4>;
+ shunt-resistor-micro-ohms = <100000000>;
+ label = "NET";
+ bipolar;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml b/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
index a6cb857a232d..9ceb6f18c854 100644
--- a/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/motorola,cpcap-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Motorola CPCAP PMIC ADC binding
+title: Motorola CPCAP PMIC ADC
maintainers:
- Tony Lindgren <tony@atomide.com>
diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,nct7201.yaml b/Documentation/devicetree/bindings/iio/adc/nuvoton,nct7201.yaml
new file mode 100644
index 000000000000..8ce7d415d956
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,nct7201.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/nuvoton,nct7201.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton nct7201 and similar ADCs
+
+maintainers:
+ - Eason Yang <j2anfernee@gmail.com>
+
+description: |
+ The NCT7201/NCT7202 is a Nuvoton Hardware Monitor IC, contains up to 12
+ voltage monitoring channels, with SMBus interface, and up to 4 sets SMBus
+ address selection by ADDR connection. It also provides ALERT# signal for
+ event notification and reset input RSTIN# to recover it from a fault
+ condition.
+
+ NCT7201 contains 8 voltage monitor inputs (VIN1~VIN8).
+ NCT7202 contains 12 voltage monitor inputs (VIN1~VIN12).
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nct7201
+ - nuvoton,nct7202
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ A 3.3V to supply that powers the chip.
+
+ vref-supply:
+ description:
+ The regulator supply for the ADC reference voltage.
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@1d {
+ compatible = "nuvoton,nct7202";
+ reg = <0x1d>;
+ vdd-supply = <&vdd>;
+ vref-supply = <&vref>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
index 9c59a20a6032..0a192ca192c5 100644
--- a/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/nxp,imx8qxp-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP IMX8QXP ADC bindings
+title: NXP IMX8QXP ADC
maintainers:
- Cai Huoqing <caihuoqing@baidu.com>
@@ -39,6 +39,12 @@ properties:
power-domains:
maxItems: 1
+ vref-supply:
+ description: |
+ External ADC reference voltage supply on VREFH pad. If VERID[MVI] is
+ set, there are additional, internal reference voltages selectable.
+ VREFH1 is always from VREFH pad.
+
"#io-channel-cells":
const: 1
@@ -72,6 +78,7 @@ examples:
assigned-clocks = <&clk IMX_SC_R_ADC_0>;
assigned-clock-rates = <24000000>;
power-domains = <&pd IMX_SC_R_ADC_0>;
+ vref-supply = <&reg_1v8>;
#io-channel-cells = <1>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
new file mode 100644
index 000000000000..c2e5ff418920
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/nxp,imx93-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP iMX93 ADC
+
+maintainers:
+ - Haibo Chen <haibo.chen@nxp.com>
+
+description:
+ The ADC on iMX93 is a 8-channel 12-bit 1MS/s ADC with 4 channels
+ connected to pins. it support normal and inject mode, include
+ One-Shot and Scan (continuous) conversions. Programmable DMA
+ enables for each channel Also this ADC contain alternate analog
+ watchdog thresholds, select threshold through input ports. And
+ also has Self-test logic and Software-initiated calibration.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nxp,imx93-adc
+ - items:
+ - enum:
+ - nxp,imx94-adc
+ - nxp,imx95-adc
+ - const: nxp,imx93-adc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: WDGnL, watchdog threshold interrupt requests.
+ - description: WDGnH, watchdog threshold interrupt requests.
+ - description: normal conversion, include EOC (End of Conversion),
+ ECH (End of Chain), JEOC (End of Injected Conversion) and
+ JECH (End of injected Chain).
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ipg
+
+ vref-supply:
+ description:
+ The reference voltage which used to establish channel scaling.
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - vref-supply
+ - "#io-channel-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/imx93-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ adc@44530000 {
+ compatible = "nxp,imx93-adc";
+ reg = <0x44530000 0x10000>;
+ interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_ADC1_GATE>;
+ clock-names = "ipg";
+ vref-supply = <&reg_vref_1v8>;
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml
index 43abb300fa3d..70b38038a080 100644
--- a/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/nxp,lpc1850-adc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/nxp,lpc1850-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP LPC1850 ADC bindings
+title: NXP LPC1850 ADC
maintainers:
- Jonathan Cameron <jic23@kernel.org>
diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,lpc3220-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,lpc3220-adc.yaml
index 2c5032be83bd..fd815ab30df1 100644
--- a/Documentation/devicetree/bindings/iio/adc/nxp,lpc3220-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/nxp,lpc3220-adc.yaml
@@ -22,6 +22,9 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 1
+
vref-supply: true
"#io-channel-cells":
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
index d186b713d6a7..58ea1ca4a5ee 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.yaml
@@ -160,7 +160,7 @@ examples:
};
ref_muxoff: adc-channel@f {
reg = <0x00 0x0f>;
- };
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
index 2a94db688830..5ed893ef5c18 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
@@ -18,10 +18,14 @@ description: |
properties:
compatible:
- const: qcom,spmi-iadc
+ items:
+ - enum:
+ - qcom,pm8226-iadc
+ - qcom,pm8941-iadc
+ - const: qcom,spmi-iadc
reg:
- description: IADC base address and length in the SPMI PMIC register map
+ description: IADC base address in the SPMI PMIC register map
maxItems: 1
qcom,external-resistor-micro-ohms:
@@ -46,15 +50,17 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spmi_bus {
+
+ pmic {
#address-cells = <1>;
#size-cells = <0>;
- pmic_iadc: adc@3600 {
- compatible = "qcom,spmi-iadc";
+
+ adc@3600 {
+ compatible = "qcom,pm8941-iadc", "qcom,spmi-iadc";
reg = <0x3600>;
interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
qcom,external-resistor-micro-ohms = <10000>;
- #io-channel-cells = <1>;
+ #io-channel-cells = <1>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
index c8cbfd3444be..862e450da214 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm's SPMI PMIC Round Robin ADC
maintainers:
- - Caleb Connolly <caleb.connolly@linaro.org>
+ - Casey Connolly <casey.connolly@linaro.org>
description: |
The Qualcomm SPMI Round Robin ADC (RRADC) provides interface to clients to
@@ -40,12 +40,12 @@ additionalProperties: false
examples:
- |
pmic {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pmic_rradc: adc@4500 {
- compatible = "qcom,pmi8998-rradc";
- reg = <0x4500>;
- #io-channel-cells = <1>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@4500 {
+ compatible = "qcom,pmi8998-rradc";
+ reg = <0x4500>;
+ #io-channel-cells = <1>;
+ };
};
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
index 74a4a9d95798..b9dc04b0d307 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml
@@ -22,13 +22,11 @@ properties:
- items:
- const: qcom,pms405-adc
- const: qcom,spmi-adc-rev2
-
- - items:
- - enum:
- - qcom,spmi-vadc
- - qcom,spmi-adc5
- - qcom,spmi-adc-rev2
- - qcom,spmi-adc7
+ - enum:
+ - qcom,spmi-vadc
+ - qcom,spmi-adc5
+ - qcom,spmi-adc-rev2
+ - qcom,spmi-adc7
reg:
description: VADC base address in the SPMI PMIC register map
@@ -56,8 +54,9 @@ required:
- '#io-channel-cells'
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
type: object
+ additionalProperties: false
description: |
Represents the external channels which are connected to the ADC.
For compatible property "qcom,spmi-vadc" following channels, also known as
@@ -76,7 +75,6 @@ patternProperties:
in the PMIC-specific files in include/dt-bindings/iio/.
label:
- $ref: /schemas/types.yaml#/definitions/string
description: |
ADC input of the platform as seen in the schematics.
For thermistor inputs connected to generic AMUX or GPIO inputs
@@ -102,7 +100,7 @@ patternProperties:
oneOf:
- items:
- const: 1
- - enum: [ 1, 3, 4, 6, 20, 8, 10 ]
+ - enum: [ 1, 3, 4, 6, 20, 8, 10, 16 ]
- items:
- const: 10
- const: 81
@@ -149,7 +147,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 512, 1024, 2048, 4096 ]
@@ -172,7 +170,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 256, 512, 1024 ]
@@ -195,7 +193,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 250, 420, 840 ]
@@ -218,7 +216,7 @@ allOf:
then:
patternProperties:
- "^.*@[0-9a-f]+$":
+ "^channel@[0-9a-f]+$":
properties:
qcom,decimation:
enum: [ 85, 340, 1360 ]
@@ -237,42 +235,74 @@ additionalProperties: false
examples:
- |
- spmi_bus {
- #address-cells = <1>;
- #size-cells = <0>;
- /* VADC node */
- pmic_vadc: adc@3100 {
- compatible = "qcom,spmi-vadc";
- reg = <0x3100>;
- interrupts = <0x0 0x31 0x0 0x1>;
+ pmic {
#address-cells = <1>;
#size-cells = <0>;
- #io-channel-cells = <1>;
-
- /* Channel node */
- adc-chan@39 {
- reg = <0x39>;
- qcom,decimation = <512>;
- qcom,ratiometric;
- qcom,hw-settle-time = <200>;
- qcom,avg-samples = <1>;
- qcom,pre-scaling = <1 3>;
- };
- adc-chan@9 {
- reg = <0x9>;
+ adc@3100 {
+ compatible = "qcom,spmi-vadc";
+ reg = <0x3100>;
+ interrupts = <0x0 0x31 0x0 0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ /* Channel node */
+ channel@39 {
+ reg = <0x39>;
+ qcom,decimation = <512>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,avg-samples = <1>;
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@9 {
+ reg = <0x9>;
+ };
+
+ channel@a {
+ reg = <0xa>;
+ };
+
+ channel@e {
+ reg = <0xe>;
+ };
+
+ channel@f {
+ reg = <0xf>;
+ };
};
+ };
- adc-chan@a {
- reg = <0xa>;
- };
+ - |
+ #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+ #include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h>
- adc-chan@e {
- reg = <0xe>;
- };
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
- adc-chan@f {
- reg = <0xf>;
+ adc@3100 {
+ reg = <0x3100>;
+ compatible = "qcom,spmi-adc7";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ /* Other properties are omitted */
+ channel@44 {
+ reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ label = "xo_therm";
+ };
+
+ channel@47 {
+ reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ label = "conn_therm";
+ };
};
- };
};
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml
new file mode 100644
index 000000000000..dc0206b28231
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/renesas,r9a09g077-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/T2H / RZ/N2H ADC12
+
+maintainers:
+ - Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
+
+description: |
+ A/D Converter block is a successive approximation analog-to-digital converter
+ with a 12-bit accuracy. Up to 16 analog input channels can be selected.
+ Conversions can be performed in single or continuous mode. Result of the ADC
+ is stored in a 16-bit data register corresponding to each channel.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: renesas,r9a09g087-adc # RZ/N2H
+ - const: renesas,r9a09g077-adc # RZ/T2H
+ - items:
+ - const: renesas,r9a09g077-adc # RZ/T2H
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: A/D scan end interrupt
+ - description: A/D scan end interrupt for Group B
+ - description: A/D scan end interrupt for Group C
+ - description: Window A compare match
+ - description: Window B compare match
+ - description: Compare match
+ - description: Compare mismatch
+
+ interrupt-names:
+ items:
+ - const: adi
+ - const: gbadi
+ - const: gcadi
+ - const: cmpai
+ - const: cmpbi
+ - const: wcmpm
+ - const: wcmpum
+
+ clocks:
+ items:
+ - description: Converter clock
+ - description: Peripheral clock
+
+ clock-names:
+ items:
+ - const: adclk
+ - const: pclk
+
+ power-domains:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ "#io-channel-cells":
+ const: 1
+
+patternProperties:
+ "^channel@[0-9a-f]$":
+ $ref: adc.yaml
+ type: object
+ description: The external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description: The channel number.
+ maximum: 15
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ adc@80008000 {
+ compatible = "renesas,r9a09g077-adc";
+ reg = <0x80008000 0x400>;
+ interrupts = <GIC_SPI 708 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 709 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 710 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 711 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 712 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 855 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 856 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "adi", "gbadi", "gcadi",
+ "cmpai", "cmpbi", "wcmpm", "wcmpum";
+ clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKL>,
+ <&cpg CPG_MOD 225>;
+ clock-names = "adclk", "pclk";
+ power-domains = <&cpg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ channel@0 {
+ reg = <0x0>;
+ };
+ channel@1 {
+ reg = <0x1>;
+ };
+ channel@2 {
+ reg = <0x2>;
+ };
+ channel@3 {
+ reg = <0x3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
index c115e2e99bd9..36dff3250ea7 100644
--- a/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
@@ -34,9 +34,11 @@ properties:
clock-names:
const: fck
- power-domains: true
+ power-domains:
+ maxItems: 1
- resets: true
+ resets:
+ maxItems: 1
"#address-cells":
const: 1
@@ -51,6 +53,8 @@ required:
- reg
- clocks
- clock-names
+ - power-domains
+ - resets
- "#address-cells"
- "#size-cells"
@@ -86,7 +90,7 @@ patternProperties:
of the MAX chips to the GyroADC, while MISO line of each Maxim
ADC connects to a shared input pin of the GyroADC.
enum:
- - adi,7476
+ - adi,ad7476
- fujitsu,mb88101a
- maxim,max1162
- maxim,max11100
@@ -108,36 +112,30 @@ patternProperties:
examples:
- |
- #include <dt-bindings/clock/r8a7791-clock.h>
+ #include <dt-bindings/clock/r8a7791-cpg-mssr.h>
#include <dt-bindings/power/r8a7791-sysc.h>
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
-
- adc@e6e54000 {
- compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
- reg = <0 0xe6e54000 0 64>;
- clocks = <&mstp9_clks R8A7791_CLK_GYROADC>;
- clock-names = "fck";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
-
- pinctrl-0 = <&adc_pins>;
- pinctrl-names = "default";
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- adc@0 {
- reg = <0>;
- compatible = "maxim,max1162";
- vref-supply = <&vref_max1162>;
- };
-
- adc@1 {
- reg = <1>;
- compatible = "maxim,max1162";
- vref-supply = <&vref_max1162>;
- };
+
+ adc@e6e54000 {
+ compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
+ reg = <0xe6e54000 64>;
+ clocks = <&cpg CPG_MOD 901>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 901>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ reg = <0>;
+ compatible = "maxim,max1162";
+ vref-supply = <&vref_max1162>;
+ };
+
+ adc@1 {
+ reg = <1>;
+ compatible = "maxim,max1162";
+ vref-supply = <&vref_max1162>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
index 61c6157cf5a9..40341d541726 100644
--- a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml
@@ -17,12 +17,15 @@ description: |
properties:
compatible:
- items:
- - enum:
- - renesas,r9a07g043-adc # RZ/G2UL
- - renesas,r9a07g044-adc # RZ/G2L
- - renesas,r9a07g054-adc # RZ/V2L
- - const: renesas,rzg2l-adc
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043-adc # RZ/G2UL and RZ/Five
+ - renesas,r9a07g044-adc # RZ/G2L
+ - renesas,r9a07g054-adc # RZ/V2L
+ - const: renesas,rzg2l-adc
+ - items:
+ - const: renesas,r9a08g045-adc # RZ/G3S
reg:
maxItems: 1
@@ -57,6 +60,9 @@ properties:
'#size-cells':
const: 0
+ "#io-channel-cells":
+ const: 1
+
required:
- compatible
- reg
@@ -68,8 +74,8 @@ required:
- reset-names
patternProperties:
- "^channel@[0-7]$":
- $ref: "adc.yaml"
+ "^channel@[0-8]$":
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
@@ -78,6 +84,8 @@ patternProperties:
reg:
description: |
The channel number.
+ minimum: 0
+ maximum: 8
required:
- reg
@@ -92,18 +100,25 @@ allOf:
const: renesas,r9a07g043-adc
then:
patternProperties:
- "^channel@[2-7]$": false
+ "^channel@[2-8]$": false
"^channel@[0-1]$":
properties:
reg:
- minimum: 0
maximum: 1
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a07g044-adc
+ - renesas,r9a07g054-adc
+ then:
patternProperties:
+ "^channel@[8]$": false
"^channel@[0-7]$":
properties:
reg:
- minimum: 0
maximum: 7
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzn1-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzn1-adc.yaml
new file mode 100644
index 000000000000..1a40352165fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzn1-adc.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/renesas,rzn1-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/N1 Analog to Digital Converter (ADC)
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The Renesas RZ/N1 ADC controller available in the Renesas RZ/N1 SoCs family
+ can use up to two internal ADC cores (ADC1 and ADC2) those internal cores are
+ handled through ADC controller virtual channels.
+
+properties:
+ compatible:
+ items:
+ - const: renesas,r9a06g032-adc # RZ/N1D
+ - const: renesas,rzn1-adc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: APB internal bus clock
+ - description: ADC clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: adc
+
+ power-domains:
+ maxItems: 1
+
+ adc1-avdd-supply:
+ description:
+ ADC1 analog power supply.
+
+ adc1-vref-supply:
+ description:
+ ADC1 reference voltage supply.
+
+ adc2-avdd-supply:
+ description:
+ ADC2 analog power supply.
+
+ adc2-vref-supply:
+ description:
+ ADC2 reference voltage supply.
+
+ '#io-channel-cells':
+ const: 1
+ description: |
+ Channels numbers available:
+ if ADC1 is used (i.e. adc1-{avdd,vref}-supply present):
+ - 0: ADC1 IN0
+ - 1: ADC1 IN1
+ - 2: ADC1 IN2
+ - 3: ADC1 IN3
+ - 4: ADC1 IN4
+ - 5: ADC1 IN6
+ - 6: ADC1 IN7
+ - 7: ADC1 IN8
+ if ADC2 is used (i.e. adc2-{avdd,vref}-supply present):
+ - 8: ADC2 IN0
+ - 9: ADC2 IN1
+ - 10: ADC2 IN2
+ - 11: ADC2 IN3
+ - 12: ADC2 IN4
+ - 13: ADC2 IN6
+ - 14: ADC2 IN7
+ - 15: ADC2 IN8
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - '#io-channel-cells'
+
+# At least one of avvd/vref supplies
+anyOf:
+ - required:
+ - adc1-vref-supply
+ - adc1-avdd-supply
+ - required:
+ - adc2-vref-supply
+ - adc2-avdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+
+ adc: adc@40065000 {
+ compatible = "renesas,r9a06g032-adc", "renesas,rzn1-adc";
+ reg = <0x40065000 0x200>;
+ clocks = <&sysctrl R9A06G032_HCLK_ADC>, <&sysctrl R9A06G032_CLK_ADC>;
+ clock-names = "pclk", "adc";
+ power-domains = <&sysctrl>;
+ adc1-avdd-supply = <&adc1_avdd>;
+ adc1-vref-supply = <&adc1_vref>;
+ #io-channel-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml b/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml
new file mode 100644
index 000000000000..af2c3a67f888
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/richtek,rtq6056.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/richtek,rtq6056.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RTQ6056 Bi-Directional Current and Power Monitor with 16-bit ADC
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ The RTQ6056 is a high accuracy current-sense monitor with I2C and SMBus
+ interface, and the device provides full information for system by reading
+ out the loading current and power.
+
+ The device monitors both of the drops across sense resistor and the BUS
+ voltage, converts into the current in amperes, and power in watts through
+ internal analog-to-digital converter ADC. The programmable calibration,
+ adjustable conversion time, and averaging function are also built in for
+ more design flexibility.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RTQ6056/DSQ6056-00.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - richtek,rtq6056
+ - richtek,rtq6059
+ - items:
+ - enum:
+ - richtek,rtq6053
+ - const: richtek,rtq6056
+
+ reg:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 1
+
+ shunt-resistor-micro-ohms:
+ description: Shunt IN+/IN- sensing node resistor
+
+required:
+ - compatible
+ - reg
+ - "#io-channel-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc@40 {
+ compatible = "richtek,rtq6056";
+ reg = <0x40>;
+ #io-channel-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
index e512a14e41b4..6769d679c907 100644
--- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml
@@ -15,6 +15,15 @@ properties:
- const: rockchip,saradc
- const: rockchip,rk3066-tsadc
- const: rockchip,rk3399-saradc
+ - const: rockchip,rk3528-saradc
+ - items:
+ - const: rockchip,rk3506-saradc
+ - const: rockchip,rk3528-saradc
+ - const: rockchip,rk3562-saradc
+ - const: rockchip,rk3588-saradc
+ - items:
+ - const: rockchip,rk3576-saradc
+ - const: rockchip,rk3588-saradc
- items:
- enum:
- rockchip,px30-saradc
@@ -22,6 +31,7 @@ properties:
- rockchip,rk3328-saradc
- rockchip,rk3568-saradc
- rockchip,rv1108-saradc
+ - rockchip,rv1126-saradc
- const: rockchip,rk3399-saradc
reg:
@@ -40,6 +50,9 @@ properties:
- const: saradc
- const: apb_pclk
+ power-domains:
+ maxItems: 1
+
resets:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/adc/rohm,bd79104.yaml b/Documentation/devicetree/bindings/iio/adc/rohm,bd79104.yaml
new file mode 100644
index 000000000000..d5192ec58f59
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/rohm,bd79104.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/rohm,bd79104.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM Semiconductor BD79104 ADC
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ 12 bit SPI ADC with 8 channels.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - rohm,bd79100
+ - rohm,bd79101
+ - rohm,bd79102
+ - rohm,bd79104
+ - items:
+ - const: rohm,bd79103
+ - const: rohm,bd79104
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ iovdd-supply: true
+
+# The component data-sheet says the frequency is 20M. I, however, found
+# that the ROHM evaluation board BD79104FV-EVK-001 had problems with 20M.
+# I have successfully used it with 4M. My _assumption_ is that this is not
+# the limitation of the component itself, but a limitation of the EVK.
+ spi-max-frequency:
+ maximum: 20000000
+
+ "#io-channel-cells":
+ const: 1
+
+ spi-cpha: true
+ spi-cpol: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - iovdd-supply
+ - spi-cpha
+ - spi-cpol
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "rohm,bd79104";
+ reg = <0>;
+ vdd-supply = <&vdd_supply>;
+ iovdd-supply = <&iovdd_supply>;
+ spi-max-frequency = <4000000>;
+ spi-cpha;
+ spi-cpol;
+ #io-channel-cells = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/rohm,bd79112.yaml b/Documentation/devicetree/bindings/iio/adc/rohm,bd79112.yaml
new file mode 100644
index 000000000000..aa8b07c3fac1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/rohm,bd79112.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/rohm,bd79112.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD79112 ADC/GPO
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ The ROHM BD79112 is a 12-bit, 32-channel, SAR ADC. ADC input pins can be
+ also configured as general purpose inputs/outputs. SPI should use MODE 3.
+
+properties:
+ compatible:
+ const: rohm,bd79112
+
+ reg:
+ maxItems: 1
+
+ spi-cpha: true
+ spi-cpol: true
+
+ gpio-controller: true
+ "#gpio-cells":
+ const: 2
+
+ vdd-supply: true
+
+ iovdd-supply: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@([0-9]|[12][0-9]|3[01])$":
+ type: object
+ $ref: /schemas/iio/adc/adc.yaml#
+ description: Represents ADC channel. Omitted channels' inputs are GPIOs.
+
+ properties:
+ reg:
+ description: AIN pin number
+ minimum: 0
+ maximum: 31
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - iovdd-supply
+ - vdd-supply
+ - spi-cpha
+ - spi-cpol
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc: adc@0 {
+ compatible = "rohm,bd79112";
+ reg = <0x0>;
+
+ spi-cpha;
+ spi-cpol;
+
+ vdd-supply = <&dummyreg>;
+ iovdd-supply = <&dummyreg>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ channel@0 {
+ reg = <0>;
+ };
+ channel@1 {
+ reg = <1>;
+ };
+ channel@2 {
+ reg = <2>;
+ };
+ channel@16 {
+ reg = <16>;
+ };
+ channel@20 {
+ reg = <20>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml b/Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml
new file mode 100644
index 000000000000..4a8f127de7e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/rohm,bd79124.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/rohm,bd79124.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD79124 ADC/GPO
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
+ an automatic measurement mode, with an alarm interrupt for out-of-window
+ measurements. ADC input pins can be also configured as general purpose
+ outputs.
+
+properties:
+ compatible:
+ const: rohm,bd79124
+
+ reg:
+ description:
+ I2C slave address.
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 1
+ description:
+ The pin number.
+
+ vdd-supply: true
+
+ iovdd-supply: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@[0-7]+$":
+ type: object
+ $ref: /schemas/iio/adc/adc.yaml#
+ description: Represents ADC channel.
+
+ properties:
+ reg:
+ description: AIN pin number
+ minimum: 0
+ maximum: 7
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - iovdd-supply
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adc: adc@10 {
+ compatible = "rohm,bd79124";
+ reg = <0x10>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+ vdd-supply = <&dummyreg>;
+ iovdd-supply = <&dummyreg>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+ channel@1 {
+ reg = <1>;
+ };
+ channel@2 {
+ reg = <2>;
+ };
+ channel@3 {
+ reg = <3>;
+ };
+ channel@4 {
+ reg = <4>;
+ };
+ channel@5 {
+ reg = <5>;
+ };
+ channel@6 {
+ reg = <6>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
index 81c87295912c..def879f6ed20 100644
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
@@ -11,18 +11,19 @@ maintainers:
properties:
compatible:
- enum:
- - samsung,exynos-adc-v1 # Exynos5250
- - samsung,exynos-adc-v2
- - samsung,exynos3250-adc
- - samsung,exynos4212-adc # Exynos4212 and Exynos4412
- - samsung,exynos7-adc
- - samsung,s3c2410-adc
- - samsung,s3c2416-adc
- - samsung,s3c2440-adc
- - samsung,s3c2443-adc
- - samsung,s3c6410-adc
- - samsung,s5pv210-adc
+ oneOf:
+ - enum:
+ - samsung,exynos-adc-v1 # Exynos5250
+ - samsung,exynos-adc-v2
+ - samsung,exynos3250-adc
+ - samsung,exynos4212-adc # Exynos4212 and Exynos4412
+ - samsung,exynos7-adc
+ - samsung,s3c6410-adc
+ - samsung,s5pv210-adc
+ - items:
+ - enum:
+ - samsung,exynos5433-adc
+ - const: samsung,exynos7-adc
reg:
maxItems: 1
@@ -41,8 +42,6 @@ properties:
maxItems: 2
interrupts:
- description:
- ADC interrupt followed by optional touchscreen interrupt.
minItems: 1
maxItems: 2
@@ -52,16 +51,11 @@ properties:
vdd-supply: true
samsung,syscon-phandle:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the PMU system controller node (to access the ADC_PHY
register on Exynos3250/4x12/5250/5420/5800).
- has-touchscreen:
- description:
- If present, indicates that a touchscreen is connected and usable.
- type: boolean
-
required:
- compatible
- reg
@@ -113,20 +107,29 @@ allOf:
- const: adc
- if:
- required:
- - has-touchscreen
+ properties:
+ compatible:
+ contains:
+ const: samsung,s5pv210-adc
then:
properties:
interrupts:
- minItems: 2
- maxItems: 2
+ items:
+ - description: main (ADC)
+ - description: pending (PENDN)
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
adc: adc@12d10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12d10000 0x100>;
- interrupts = <0 106 0>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
#io-channel-cells = <1>;
clocks = <&clock 303>;
@@ -142,16 +145,17 @@ examples:
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 4>;
- };
+ };
};
- |
#include <dt-bindings/clock/exynos3250.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
adc@126c0000 {
compatible = "samsung,exynos3250-adc";
- reg = <0x126C0000 0x100>;
- interrupts = <0 137 0>;
+ reg = <0x126c0000 0x100>;
+ interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
#io-channel-cells = <1>;
clocks = <&cmu CLK_TSADC>,
diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml
index 2287697f1f61..c3a116427dc3 100644
--- a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/sigma-delta-modulator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device-Tree bindings for sigma delta modulator
+title: Sigma delta modulator
maintainers:
- Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
@@ -18,18 +18,39 @@ properties:
- sd-modulator
- ads1201
+ '#io-backend-cells':
+ const: 0
+
'#io-channel-cells':
const: 0
+ vref-supply:
+ description: Phandle to the vref input analog reference voltage.
+
+dependencies:
+ vref-supply: [ '#io-backend-cells' ]
+
required:
- compatible
- - '#io-channel-cells'
+
+anyOf:
+ - required: ['#io-backend-cells']
+ - required: ['#io-channel-cells']
additionalProperties: false
examples:
- |
- ads1202: adc {
+ // Backend binding example. SD modulator configured as an IIO backend device
+ ads1201_0: adc {
+ compatible = "sd-modulator";
+ vref-supply = <&vdd_adc>;
+ #io-backend-cells = <0>;
+ };
+
+ - |
+ // Legacy binding example. SD modulator configured as an IIO channel provider
+ ads1201_1: adc {
compatible = "sd-modulator";
#io-channel-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml
new file mode 100644
index 000000000000..f652b98615f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/sophgo,cv1800b-saradc.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/sophgo,cv1800b-saradc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Sophgo CV1800B SoC 3 channels Successive Approximation Analog to
+ Digital Converters
+
+maintainers:
+ - Thomas Bonnefille <thomas.bonnefille@bootlin.com>
+
+description:
+ Datasheet at https://github.com/sophgo/sophgo-doc/releases
+
+properties:
+ compatible:
+ const: sophgo,cv1800b-saradc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^channel@[0-2]$":
+ $ref: adc.yaml
+
+ properties:
+ reg:
+ items:
+ - minimum: 0
+ maximum: 2
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sophgo,cv1800.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ adc@30f0000 {
+ compatible = "sophgo,cv1800b-saradc";
+ reg = <0x030f0000 0x1000>;
+ clocks = <&clk CLK_SARADC>;
+ interrupts = <100 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml b/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml
index 44aa28b59197..a678323d78e3 100644
--- a/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/sprd,sc2720-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Spreadtrum SC27XX series PMICs ADC binding
+title: Spreadtrum SC27XX series PMICs ADC
maintainers:
- Baolin Wang <baolin.wang7@gmail.com>
@@ -85,23 +85,6 @@ examples:
pmic {
#address-cells = <1>;
#size-cells = <0>;
- adc@480 {
- compatible = "sprd,sc2731-adc";
- reg = <0x480>;
- interrupt-parent = <&sc2731_pmic>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
- #io-channel-cells = <1>;
- hwlocks = <&hwlock 4>;
- nvmem-cells = <&adc_big_scale>, <&adc_small_scale>;
- nvmem-cell-names = "big_scale_calib", "small_scale_calib";
- };
- };
-
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
- pmic {
- #address-cells = <1>;
- #size-cells = <0>;
adc@504 {
compatible = "sprd,ump9620-adc";
reg = <0x504>;
diff --git a/Documentation/devicetree/bindings/iio/adc/st,spear600-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,spear600-adc.yaml
new file mode 100644
index 000000000000..dd9ec3038703
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/st,spear600-adc.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/st,spear600-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST SPEAr ADC device driver
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Integrated ADC inside the ST SPEAr SoC, SPEAr600, supporting
+ 10-bit resolution. Datasheet can be found here:
+ https://www.st.com/resource/en/datasheet/spear600.pdf
+
+properties:
+ compatible:
+ enum:
+ - st,spear600-adc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ sampling-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2500000
+ maximum: 20000000
+ description:
+ Default sampling frequency of the ADC in Hz.
+
+ vref-external:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1000
+ maximum: 2800
+ description:
+ External voltage reference in milli-volts. If omitted the internal voltage
+ reference will be used.
+
+ average-samples:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 0
+ description:
+ Number of samples to generate an average value. If omitted, single data
+ conversion will be used.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - sampling-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ adc@d8200000 {
+ compatible = "st,spear600-adc";
+ reg = <0xd8200000 0x1000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <6>;
+ sampling-frequency = <5000000>;
+ vref-external = <2500>; /* 2.5V VRef */
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
index fa8da42cb1e6..c4c4575d3fa9 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/adc/st,stm32-adc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/adc/st,stm32-adc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 ADC bindings
+title: STMicroelectronics STM32 ADC
description: |
STM32 ADC is a successive approximation analog-to-digital converter.
@@ -27,6 +27,7 @@ properties:
- st,stm32f4-adc-core
- st,stm32h7-adc-core
- st,stm32mp1-adc-core
+ - st,stm32mp13-adc-core
reg:
maxItems: 1
@@ -37,6 +38,7 @@ properties:
- stm32f4 and stm32h7 share a common ADC interrupt line.
- stm32mp1 has two separate interrupt lines, one for each ADC within
ADC block.
+ - stm32mp13 has an interrupt line per ADC block.
minItems: 1
maxItems: 2
@@ -52,7 +54,9 @@ properties:
It's not present on stm32f4.
It's required on stm32h7 and stm32mp1.
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 2
st,max-clk-rate-hz:
description:
@@ -78,7 +82,7 @@ properties:
description:
Phandle to system configuration controller. It can be used to control the
analog circuitry on stm32mp1.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
interrupt-controller: true
@@ -91,6 +95,10 @@ properties:
'#size-cells':
const: 0
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
allOf:
- if:
properties:
@@ -180,6 +188,33 @@ allOf:
maximum: 36000000
default: 36000000
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp13-adc-core
+
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: bus
+ - const: adc
+ minItems: 1
+
+ interrupts:
+ items:
+ - description: ADC interrupt line
+
+ st,max-clk-rate-hz:
+ minimum: 150000
+ maximum: 75000000
+ default: 75000000
+
additionalProperties: false
required:
@@ -208,6 +243,7 @@ patternProperties:
- st,stm32f4-adc
- st,stm32h7-adc
- st,stm32mp1-adc
+ - st,stm32mp13-adc
reg:
description: |
@@ -229,7 +265,7 @@ patternProperties:
interrupts:
description: |
IRQ Line for the ADC instance. Valid values are:
- - 0 for adc@0
+ - 0 for adc@0 (single adc for stm32mp13)
- 1 for adc@100
- 2 for adc@200 (stm32f4 only)
maxItems: 1
@@ -250,13 +286,14 @@ patternProperties:
assigned-resolution-bits:
description: |
Resolution (bits) to use for conversions:
- - can be 6, 8, 10 or 12 on stm32f4
+ - can be 6, 8, 10 or 12 on stm32f4 and stm32mp13
- can be 8, 10, 12, 14 or 16 on stm32h7 and stm32mp1
st,adc-channels:
description: |
List of single-ended channels muxed for this ADC. It can have up to:
- 16 channels, numbered from 0 to 15 (for in0..in15) on stm32f4
+ - 19 channels, numbered from 0 to 18 (for in0..in18) on stm32mp13.
- 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and
stm32mp1.
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -310,7 +347,7 @@ patternProperties:
patternProperties:
"^channel@([0-9]|1[0-9])$":
type: object
- $ref: "adc.yaml"
+ $ref: adc.yaml
description: Represents the external channels which are connected to the ADC.
properties:
@@ -322,7 +359,7 @@ patternProperties:
label:
description: |
Unique name to identify which channel this is.
- Reserved label names "vddcore", "vrefint" and "vbat"
+ Reserved label names "vddcore", "vddcpu", "vddq_ddr", "vrefint" and "vbat"
are used to identify internal channels with matching names.
diff-channels:
@@ -419,6 +456,36 @@ patternProperties:
items:
minimum: 40
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp13-adc
+
+ then:
+ properties:
+ reg:
+ const: 0x0
+
+ interrupts:
+ const: 0
+
+ assigned-resolution-bits:
+ enum: [6, 8, 10, 12]
+ default: 12
+
+ st,adc-channels:
+ minItems: 1
+ maxItems: 19
+ items:
+ minimum: 0
+ maximum: 18
+
+ st,min-sample-time-nsecs:
+ minItems: 1
+ maxItems: 19
+ items:
+ minimum: 40
additionalProperties: false
required:
@@ -430,7 +497,7 @@ patternProperties:
examples:
- |
// Example 1: with stm32f429, ADC1, single-ended channel 8
- adc123: adc@40012000 {
+ adc123: adc@40012000 {
compatible = "st,stm32f4-adc-core";
reg = <0x40012000 0x400>;
interrupts = <18>;
@@ -444,28 +511,28 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
- compatible = "st,stm32f4-adc";
- #io-channel-cells = <1>;
- reg = <0x0>;
- clocks = <&rcc 0 168>;
- interrupt-parent = <&adc123>;
- interrupts = <0>;
- st,adc-channels = <8>;
- dmas = <&dma2 0 0 0x400 0x0>;
- dma-names = "rx";
- assigned-resolution-bits = <8>;
+ compatible = "st,stm32f4-adc";
+ #io-channel-cells = <1>;
+ reg = <0x0>;
+ clocks = <&rcc 0 168>;
+ interrupt-parent = <&adc123>;
+ interrupts = <0>;
+ st,adc-channels = <8>;
+ dmas = <&dma2 0 0 0x400 0x0>;
+ dma-names = "rx";
+ assigned-resolution-bits = <8>;
};
// ...
// other adc child nodes follow...
- };
+ };
- |
// Example 2: with stm32mp157c to setup ADC1 with:
// - channels 0 & 1 as single-ended
// - channels 2 & 3 as differential (with resp. 6 & 7 negative inputs)
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/stm32mp1-clks.h>
- adc12: adc@48003000 {
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+ adc12: adc@48003000 {
compatible = "st,stm32mp1-adc-core";
reg = <0x48003000 0x400>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
@@ -482,27 +549,27 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
- compatible = "st,stm32mp1-adc";
- #io-channel-cells = <1>;
- reg = <0x0>;
- interrupt-parent = <&adc12>;
- interrupts = <0>;
- st,adc-channels = <0 1>;
- st,adc-diff-channels = <2 6>, <3 7>;
- st,min-sample-time-nsecs = <5000>;
- dmas = <&dmamux1 9 0x400 0x05>;
- dma-names = "rx";
+ compatible = "st,stm32mp1-adc";
+ #io-channel-cells = <1>;
+ reg = <0x0>;
+ interrupt-parent = <&adc12>;
+ interrupts = <0>;
+ st,adc-channels = <0 1>;
+ st,adc-diff-channels = <2 6>, <3 7>;
+ st,min-sample-time-nsecs = <5000>;
+ dmas = <&dmamux1 9 0x400 0x05>;
+ dma-names = "rx";
};
// ...
// other adc child node follow...
- };
+ };
- |
// Example 3: with stm32mp157c to setup ADC2 with:
// - internal channels 13, 14, 15.
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/stm32mp1-clks.h>
- adc122: adc@48003000 {
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+ adc122: adc@48003000 {
compatible = "st,stm32mp1-adc-core";
reg = <0x48003000 0x400>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
@@ -519,28 +586,28 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
adc@100 {
- compatible = "st,stm32mp1-adc";
- #io-channel-cells = <1>;
- reg = <0x100>;
- interrupts = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
- channel@13 {
- reg = <13>;
- label = "vrefint";
- st,min-sample-time-ns = <9000>;
- };
- channel@14 {
- reg = <14>;
- label = "vddcore";
- st,min-sample-time-ns = <9000>;
- };
- channel@15 {
- reg = <15>;
- label = "vbat";
- st,min-sample-time-ns = <9000>;
- };
+ compatible = "st,stm32mp1-adc";
+ #io-channel-cells = <1>;
+ reg = <0x100>;
+ interrupts = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@13 {
+ reg = <13>;
+ label = "vrefint";
+ st,min-sample-time-ns = <9000>;
+ };
+ channel@14 {
+ reg = <14>;
+ label = "vddcore";
+ st,min-sample-time-ns = <9000>;
+ };
+ channel@15 {
+ reg = <15>;
+ label = "vbat";
+ st,min-sample-time-ns = <9000>;
+ };
};
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
index 92f9472a77ae..c24ac98bbb3d 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
@@ -59,6 +59,10 @@ properties:
If not, SPI CLKOUT frequency will not be accurate.
maximum: 20000000
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
@@ -72,6 +76,7 @@ additionalProperties: false
patternProperties:
"^filter@[0-9]+$":
type: object
+ unevaluatedProperties: false
description: child node
properties:
@@ -97,9 +102,11 @@ patternProperties:
items:
minimum: 0
maximum: 7
+ deprecated: true
st,adc-channel-names:
description: List of single-ended channel names.
+ deprecated: true
st,filter-order:
description: |
@@ -113,6 +120,12 @@ patternProperties:
"#io-channel-cells":
const: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
st,adc-channel-types:
description: |
Single-ended channel input type.
@@ -123,6 +136,7 @@ patternProperties:
items:
enum: [ SPI_R, SPI_F, MANCH_R, MANCH_F ]
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ deprecated: true
st,adc-channel-clk-src:
description: |
@@ -134,6 +148,7 @@ patternProperties:
items:
enum: [ CLKIN, CLKOUT, CLKOUT_F, CLKOUT_R ]
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ deprecated: true
st,adc-alt-channel:
description:
@@ -142,6 +157,7 @@ patternProperties:
If not set, channel n is connected to SPI input n.
If set, channel n is connected to SPI input n + 1.
type: boolean
+ deprecated: true
st,filter0-sync:
description:
@@ -160,11 +176,60 @@ patternProperties:
- compatible
- reg
- interrupts
- - st,adc-channels
- - st,adc-channel-names
- st,filter-order
- "#io-channel-cells"
+ patternProperties:
+ "^channel@[0-7]$":
+ type: object
+ $ref: adc.yaml
+ unevaluatedProperties: false
+ description: Represents the external channels which are connected to the DFSDM.
+
+ properties:
+ reg:
+ maximum: 7
+
+ label:
+ description:
+ Unique name to identify which channel this is.
+
+ st,adc-channel-type:
+ description: |
+ Single-ended channel input type.
+ - "SPI_R": SPI with data on rising edge (default)
+ - "SPI_F": SPI with data on falling edge
+ - "MANCH_R": manchester codec, rising edge = logic 0, falling edge = logic 1
+ - "MANCH_F": manchester codec, rising edge = logic 1, falling edge = logic 0
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ SPI_R, SPI_F, MANCH_R, MANCH_F ]
+
+ st,adc-channel-clk-src:
+ description: |
+ Conversion clock source.
+ - "CLKIN": external SPI clock (CLKIN x)
+ - "CLKOUT": internal SPI clock (CLKOUT) (default)
+ - "CLKOUT_F": internal SPI clock divided by 2 (falling edge).
+ - "CLKOUT_R": internal SPI clock divided by 2 (rising edge).
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ CLKIN, CLKOUT, CLKOUT_F, CLKOUT_R ]
+
+ st,adc-alt-channel:
+ description:
+ Must be defined if two sigma delta modulators are
+ connected on same SPI input.
+ If not set, channel n is connected to SPI input n.
+ If set, channel n is connected to SPI input n + 1.
+ type: boolean
+
+ io-backends:
+ description:
+ Used to pipe external sigma delta modulator or internal ADC backend to DFSDM channel.
+ maxItems: 1
+
+ required:
+ - reg
+
allOf:
- if:
properties:
@@ -194,9 +259,19 @@ patternProperties:
description:
From common IIO binding. Used to pipe external sigma delta
modulator or internal ADC output to DFSDM channel.
+ deprecated: true
- required:
- - io-channels
+ if:
+ required:
+ - st,adc-channels
+ then:
+ required:
+ - io-channels
+
+ patternProperties:
+ "^channel@[0-7]$":
+ required:
+ - io-backends
- if:
properties:
@@ -225,6 +300,7 @@ patternProperties:
patternProperties:
"^dfsdm-dai+$":
type: object
+ additionalProperties: false
description: child node
properties:
@@ -240,6 +316,10 @@ patternProperties:
From common IIO binding. Used to pipe external sigma delta
modulator or internal ADC output to DFSDM channel.
+ port:
+ $ref: /schemas/sound/audio-graph-port.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- "#sound-dai-cells"
@@ -288,6 +368,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
+ // Example 1: Audio use case with generic binding
dfsdm0: filter@0 {
compatible = "st,stm32-dfsdm-dmic";
reg = <0>;
@@ -295,12 +376,18 @@ examples:
dmas = <&dmamux1 101 0x400 0x01>;
dma-names = "rx";
#io-channel-cells = <1>;
- st,adc-channels = <1>;
- st,adc-channel-names = "dmic0";
- st,adc-channel-types = "SPI_R";
- st,adc-channel-clk-src = "CLKOUT";
+ #address-cells = <1>;
+ #size-cells = <0>;
st,filter-order = <5>;
+ channel@1 {
+ reg = <1>;
+ label = "dmic0";
+ st,adc-channel-type = "SPI_R";
+ st,adc-channel-clk-src = "CLKOUT";
+ st,adc-alt-channel;
+ };
+
asoc_pdm0: dfsdm-dai {
compatible = "st,stm32h7-dfsdm-dai";
#sound-dai-cells = <0>;
@@ -308,19 +395,34 @@ examples:
};
};
- dfsdm_pdm1: filter@1 {
+ // Example 2: Analog use case with generic binding
+ dfsdm1: filter@1 {
compatible = "st,stm32-dfsdm-adc";
reg = <1>;
interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&dmamux1 102 0x400 0x01>;
dma-names = "rx";
- #io-channel-cells = <1>;
- st,adc-channels = <2 3>;
- st,adc-channel-names = "in2", "in3";
- st,adc-channel-types = "SPI_R", "SPI_R";
- st,adc-channel-clk-src = "CLKOUT_F", "CLKOUT_F";
- io-channels = <&sd_adc2 &sd_adc3>;
st,filter-order = <1>;
+ #io-channel-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@2 {
+ reg = <2>;
+ label = "in2";
+ st,adc-channel-type = "SPI_F";
+ st,adc-channel-clk-src = "CLKOUT";
+ st,adc-alt-channel;
+ io-backends = <&sd_adc2>;
+ };
+
+ channel@3 {
+ reg = <3>;
+ label = "in3";
+ st,adc-channel-type = "SPI_R";
+ st,adc-channel-clk-src = "CLKOUT";
+ io-backends = <&sd_adc3>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml
index 9049c699152f..474e35c49348 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/st,stmpe-adc.yaml
@@ -13,8 +13,7 @@ description:
This ADC forms part of an ST microelectronics STMPE multifunction device .
The ADC is shared with the STMPE touchscreen. As a result some ADC related
settings are specified in the parent node.
- The node name myst be stmpe_adc and should be a child node of the stmpe node
- to which it belongs.
+ The node should be a child node of the stmpe node to which it belongs.
properties:
compatible:
@@ -36,10 +35,8 @@ additionalProperties: false
examples:
- |
- stmpe {
- stmpe_adc {
- compatible = "st,stmpe-adc";
- st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
- };
+ adc {
+ compatible = "st,stmpe-adc";
+ st,norequest-mask = <0x0f>; /* dont use ADC CH3-0 */
};
...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml
new file mode 100644
index 000000000000..caaad777580c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc081c.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,adc081c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Single-channel I2C ADCs
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+description: |
+ Single-channel ADC supporting 8, 10, or 12-bit samples and high/low alerts.
+
+properties:
+ compatible:
+ enum:
+ - ti,adc081c
+ - ti,adc101c
+ - ti,adc121c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ Regulator for the combined power supply and voltage reference
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@52 {
+ compatible = "ti,adc081c";
+ reg = <0x52>;
+ vref-supply = <&reg_2p5v>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc0832.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc0832.yaml
index f5a923cc847f..686721176a58 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc0832.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc0832.yaml
@@ -24,8 +24,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply:
description: External reference, needed to establish input scaling
@@ -37,7 +35,10 @@ required:
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml
index 1a113b30a414..726d2cbfa368 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml
@@ -19,8 +19,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply:
description: External reference, needed to establish input scaling
@@ -37,7 +35,10 @@ required:
- spi-cpol
- spi-cpha
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml
index ae5ce60987fe..a60b1e100ee4 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc108s102.yaml
@@ -19,7 +19,6 @@ properties:
reg: true
vref-supply: true
- spi-max-frequency: true
"#io-channel-cells":
const: 1
@@ -28,12 +27,15 @@ required:
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
spi {
- #address-cells= <1>;
+ #address-cells = <1>;
#size-cells = <0>;
adc@0 {
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc12138.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc12138.yaml
index ec3b2edf1fb7..076088a328c3 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc12138.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc12138.yaml
@@ -31,8 +31,6 @@ properties:
maxItems: 1
description: Conversion clock input.
- spi-max-frequency: true
-
vref-p-supply:
description: The regulator supply for positive analog voltage reference
@@ -62,7 +60,10 @@ required:
- clocks
- vref-p-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc128s052.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc128s052.yaml
index d54a0183f024..044b66a3b00c 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc128s052.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc128s052.yaml
@@ -27,8 +27,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply: true
"#io-channel-cells":
@@ -39,11 +37,13 @@ required:
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc161s626.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc161s626.yaml
index 3f4f334d6f73..afe782522904 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,adc161s626.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,adc161s626.yaml
@@ -21,8 +21,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vdda-supply: true
"#io-channel-cells":
@@ -32,7 +30,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
index a3b79438a13a..718f633c6e04 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
@@ -18,11 +18,15 @@ properties:
enum:
- ti,ads1015
- ti,ads1115
+ - ti,tla2021
- ti,tla2024
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
"#address-cells":
const: 1
@@ -43,6 +47,7 @@ additionalProperties: false
patternProperties:
"^channel@[0-7]+$":
type: object
+ additionalProperties: false
description:
Child nodes needed for each channel that the platform uses.
@@ -77,9 +82,9 @@ patternProperties:
ti,datarate:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
- maximum: 6
+ maximum: 7
description: |
- Data acquisition rate in samples per second
+ Data acquisition rate in samples per second for ADS1015, TLA2024
0: 128
1: 250
2: 490
@@ -87,6 +92,17 @@ patternProperties:
4: 1600 (default)
5: 2400
6: 3300
+ 7: 3300
+
+ Data acquisition rate in samples per second for ADS1115
+ 0: 8
+ 1: 16
+ 2: 32
+ 3: 64
+ 4: 128 (default)
+ 5: 250
+ 6: 475
+ 7: 860
required:
- reg
@@ -103,12 +119,12 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
- reg = <0>;
+ reg = <0>;
};
channel@4 {
- reg = <4>;
- ti,gain = <3>;
- ti,datarate = <5>;
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <5>;
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
new file mode 100644
index 000000000000..970ccab15e1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI ADS1100/ADS1000 single channel I2C analog to digital converter
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: |
+ Datasheet at: https://www.ti.com/lit/gpn/ads1100
+
+properties:
+ compatible:
+ enum:
+ - ti,ads1100
+ - ti,ads1000
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ "#io-channel-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@49 {
+ compatible = "ti,ads1100";
+ reg = <0x49>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml
new file mode 100644
index 000000000000..ba6850ab1f90
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads1119.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ADS1119 ADC
+
+maintainers:
+ - João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
+
+description:
+ The TI ADS1119 is a precision 16-bit ADC over I2C that offers single-ended and
+ differential measurements using a multiplexed input. It features a programmable
+ gain, a programmable sample rate, an internal oscillator and voltage reference,
+ and a 50/60Hz rejection filter.
+
+properties:
+ compatible:
+ const: ti,ads1119
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ avdd-supply: true
+ dvdd-supply: true
+
+ vref-supply:
+ description:
+ ADC external reference voltage (VREF).
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - avdd-supply
+ - dvdd-supply
+
+patternProperties:
+ "^channel@([0-6])$":
+ $ref: adc.yaml
+ type: object
+ properties:
+ reg:
+ minimum: 0
+ maximum: 6
+
+ diff-channels:
+ description:
+ Differential input channels AIN0-AIN1, AIN2-AIN3 and AIN1-AIN2.
+ oneOf:
+ - items:
+ - const: 0
+ - const: 1
+ - items:
+ - const: 2
+ - const: 3
+ - items:
+ - const: 1
+ - const: 2
+
+ single-channel:
+ description:
+ Single-ended input channels AIN0, AIN1, AIN2 and AIN3.
+ minimum: 0
+ maximum: 3
+
+ oneOf:
+ - required:
+ - diff-channels
+ - required:
+ - single-channel
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@40 {
+ compatible = "ti,ads1119";
+ reg = <0x40>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&reg_avdd_ads1119>;
+ dvdd-supply = <&reg_dvdd_ads1119>;
+ vref-supply = <&reg_vref_ads1119>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ channel@0 {
+ reg = <0>;
+ single-channel = <0>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ diff-channels = <0 1>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ single-channel = <3>;
+ };
+
+ channel@3 {
+ reg = <3>;
+ single-channel = <1>;
+ };
+
+ channel@4 {
+ reg = <4>;
+ single-channel = <2>;
+ };
+
+ channel@5 {
+ reg = <5>;
+ diff-channels = <1 2>;
+ };
+
+ channel@6 {
+ reg = <6>;
+ diff-channels = <2 3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml
index 2e6abc9d746a..56a3f1766aab 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads124s08.yaml
@@ -18,8 +18,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
spi-cpha: true
reset-gpios:
@@ -32,7 +30,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1298.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1298.yaml
new file mode 100644
index 000000000000..71f9f9b745cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1298.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads1298.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' ads1298 medical ADC chips
+
+description: |
+ Datasheet at: https://www.ti.com/product/ADS1298
+ Bindings for this chip aren't complete.
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+properties:
+ compatible:
+ enum:
+ - ti,ads1298
+
+ reg:
+ maxItems: 1
+
+ spi-cpha: true
+
+ reset-gpios:
+ maxItems: 1
+
+ avdd-supply:
+ description:
+ Analog power supply, voltage between AVDD and AVSS. When providing a
+ symmetric +/- 2.5V, the regulator should report 5V.
+
+ vref-supply:
+ description:
+ Optional reference voltage. If omitted, internal reference is used,
+ which is 2.4V when analog supply is below 4.4V, 4V otherwise.
+
+ clocks:
+ description: Optional 2.048 MHz external source clock on CLK pin
+ maxItems: 1
+
+ interrupts:
+ description: Interrupt on DRDY pin, triggers on falling edge
+ maxItems: 1
+
+ label: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - interrupts
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@1 {
+ reg = <1>;
+ compatible = "ti,ads1298";
+ label = "ads1298-1-ecg";
+ avdd-supply = <&reg_iso_5v_a>;
+ clocks = <&clk_ads1298>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <78 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <20000000>;
+ spi-cpha;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml
index e0670e3fbb72..890f125d422c 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads131e08.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments ADS131E0x 4-, 6- and 8-Channel ADCs
maintainers:
- - Tomislav Denis <tomislav.denis@avl.com>
+ - Jonathan Cameron <jic23@kernel.org>
description: |
The ADS131E0x are a family of multichannel, simultaneous sampling,
@@ -28,8 +28,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
spi-cpha: true
clocks:
@@ -79,7 +77,7 @@ required:
patternProperties:
"^channel@([0-7])$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
description: |
Represents the external channels which are connected to the ADC.
@@ -120,7 +118,10 @@ patternProperties:
additionalProperties: false
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml
new file mode 100644
index 000000000000..a51893e207d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads7138.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ADS7128/ADS7138 analog-to-digital converter (ADC)
+
+maintainers:
+ - Tobias Sperling <tobias.sperling@softing.com>
+
+description: |
+ The ADS7128 and ADS7138 chips are 12-bit, 8 channel analog-to-digital
+ converters (ADC) with build-in digital window comparator (DWC), using the
+ I2C interface.
+ ADS7128 differs in the addition of further hardware features, like a
+ root-mean-square (RMS) and a zero-crossing-detect (ZCD) module.
+
+ Datasheets:
+ https://www.ti.com/product/ADS7128
+ https://www.ti.com/product/ADS7138
+
+properties:
+ compatible:
+ enum:
+ - ti,ads7128
+ - ti,ads7138
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description:
+ The regulator used as analog supply voltage as well as reference voltage.
+
+ interrupts:
+ description:
+ Interrupt on ALERT pin, triggers on low level.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@10 {
+ compatible = "ti,ads7138";
+ reg = <0x10>;
+ avdd-supply = <&reg_stb_3v3>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml
new file mode 100644
index 000000000000..0d8d06afed8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads7924.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,ads7924.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI ADS7924 4 channels 12 bits I2C analog to digital converter
+
+maintainers:
+ - Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+description: |
+ Texas Instruments ADS7924 4 channels 12 bits I2C analog to digital converter
+
+ Specifications:
+ https://www.ti.com/lit/gpn/ads7924
+
+properties:
+ compatible:
+ const: ti,ads7924
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description:
+ The regulator supply for the ADC reference voltage (AVDD)
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ "#io-channel-cells":
+ const: 1
+
+patternProperties:
+ "^channel@[0-3]+$":
+ $ref: adc.yaml
+
+ description: |
+ Represents the external channels which are connected to the ADC.
+
+ properties:
+ reg:
+ description: |
+ The channel number. It can have up to 4 channels numbered from 0 to 3.
+ items:
+ - minimum: 0
+ maximum: 3
+
+ label: true
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@48 {
+ compatible = "ti,ads7924";
+ reg = <0x48>;
+ vref-supply = <&ads7924_reg>;
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ label = "CH0";
+ };
+ channel@1 {
+ reg = <1>;
+ label = "CH1";
+ };
+ channel@2 {
+ reg = <2>;
+ label = "CH2";
+ };
+ channel@3 {
+ reg = <3>;
+ label = "CH3";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads8344.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads8344.yaml
index b8c398187d5c..f75b2c702986 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads8344.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads8344.yaml
@@ -19,8 +19,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply:
description: Supply the 2.5V or 5V reference voltage
@@ -32,7 +30,10 @@ required:
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml
index a0af4b24877f..f26fdbc15f84 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml
@@ -25,13 +25,14 @@ properties:
description: Optional external reference. If not supplied, assume
REFSEL input tied low to enable the internal reference.
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml
index d6f21d5cccd7..b32be24a9f98 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml
@@ -11,9 +11,14 @@ maintainers:
properties:
compatible:
- enum:
- - ti,am3359-adc
- - ti,am4372-adc
+ oneOf:
+ - enum:
+ - ti,am3359-adc
+ - ti,am4372-adc
+ - items:
+ - enum:
+ - ti,am654-adc
+ - const: ti,am3359-adc
'#io-channel-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml b/Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml
new file mode 100644
index 000000000000..5fb65bf7749d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,lmp92064.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LMP92064 Precision Current and Voltage Sensor.
+
+maintainers:
+ - Leonard Göhrs <l.goehrs@pengutronix.de>
+
+description: |
+ The LMP92064 is a two channel ADC intended for combined voltage and current
+ measurements.
+
+ The device contains two ADCs to allow simultaneous sampling of voltage and
+ current and thus of instantaneous power consumption.
+
+properties:
+ compatible:
+ enum:
+ - ti,lmp92064
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the main part of the chip
+
+ vdig-supply:
+ description: |
+ Regulator that provides power to the digital I/O part of the chip
+
+ shunt-resistor-micro-ohms:
+ description: |
+ Value of the shunt resistor (in µΩ) connected between INCP and INCN,
+ across which current is measured. Used to provide correct scaling of the
+ raw ADC measurement.
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - shunt-resistor-micro-ohms
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@0 {
+ compatible = "ti,lmp92064";
+ reg = <0>;
+ vdd-supply = <&vdd>;
+ vdig-supply = <&vdd>;
+ spi-max-frequency = <20000000>;
+ shunt-resistor-micro-ohms = <15000>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml
index 57a31356082e..f94057d8f605 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/ti,palmas-gpadc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Palmas general purpose ADC IP block devicetree bindings
+title: Palmas general purpose ADC IP block
maintainers:
- Tony Lindgren <tony@atomide.com>
@@ -67,19 +67,4 @@ required:
- compatible
- "#io-channel-cells"
-examples:
- - |
- #include <dt-bindings/clock/mt8183-clk.h>
- pmic {
- compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
- adc {
- compatible = "ti,palmas-gpadc";
- interrupts = <18 0>,
- <16 0>,
- <17 0>;
- #io-channel-cells = <1>;
- ti,channel0-current-microamp = <5>;
- ti,channel3-current-microamp = <10>;
- };
- };
...
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tlc4541.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tlc4541.yaml
index 6c2539b3d707..314d1d99bf73 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,tlc4541.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,tlc4541.yaml
@@ -21,8 +21,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply: true
"#io-channel-cells":
@@ -33,7 +31,10 @@ required:
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
index 601d69971d84..866a05c9db36 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
@@ -23,7 +23,8 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
+ vref-supply:
+ description: Optional supply of the reference voltage
"#io-channel-cells":
const: 1
@@ -40,7 +41,7 @@ required:
patternProperties:
"^channel@[0-7]$":
- $ref: "adc.yaml"
+ $ref: adc.yaml
type: object
properties:
@@ -59,7 +60,10 @@ patternProperties:
additionalProperties: false
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -79,36 +83,36 @@ examples:
#size-cells = <0>;
channel@0 {
- reg = <0>;
+ reg = <0>;
};
channel@1 {
- reg = <1>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <1>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@2 {
- reg = <2>;
+ reg = <2>;
};
channel@3 {
- reg = <3>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <3>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@4 {
- reg = <4>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <4>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@5 {
- reg = <5>;
- settling-time-us = <700>;
- oversampling-ratio = <5>;
+ reg = <5>;
+ settling-time-us = <700>;
+ oversampling-ratio = <5>;
};
channel@6 {
- reg = <6>;
+ reg = <6>;
};
channel@7 {
- reg = <7>;
+ reg = <7>;
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,twl6030-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,twl6030-gpadc.yaml
new file mode 100644
index 000000000000..e779a8986e0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,twl6030-gpadc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,twl6030-gpadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPADC subsystem in the TWL6030 power module
+
+maintainers:
+ - Andreas Kemnade <andreas@kemnade.info>
+
+description:
+ The GPADC subsystem in the TWL603X consists of a 10-bit ADC
+ combined with a 15-input analog multiplexer in the TWL6030 resp. a
+ 19-input analog muliplexer in the TWL6032.
+
+properties:
+ compatible:
+ enum:
+ - ti,twl6030-gpadc
+ - ti,twl6032-gpadc
+
+ interrupts:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - interrupts
+ - "#io-channel-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpadc {
+ compatible = "ti,twl6030-gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml
index d6d3d8590171..de91cb03fdc6 100644
--- a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/x-powers,axp209-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: X-Powers AXP ADC bindings
+title: X-Powers AXP ADC
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -37,6 +37,17 @@ description: |
3 | batt_dischrg_i
4 | ts_v
+ AXP717
+ ------
+ 0 | batt_v
+ 1 | ts_v
+ 2 | vbus_v
+ 3 | vsys_v
+ 4 | pmic_temp
+ 5 | batt_chrg_i
+ 6 | vmid_v
+ 7 | bkup_batt_v
+
AXP813
------
0 | pmic_temp
@@ -46,12 +57,12 @@ description: |
4 | batt_dischrg_i
5 | ts_v
-
properties:
compatible:
oneOf:
- const: x-powers,axp209-adc
- const: x-powers,axp221-adc
+ - const: x-powers,axp717-adc
- const: x-powers,axp813-adc
- items:
diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml
index 3698b4b0900f..3ae1a0bab38f 100644
--- a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx Zynq Ultrascale AMS controller
maintainers:
- - Anand Ashok Dumbre <anand.ashok.dumbre@xilinx.com>
+ - Salih Erim <salih.erim@amd.com>
+ - Conall O'Griofa <conall.ogriofa@amd.com>
description: |
The AMS (Analog Monitoring System) includes an ADC as well as on-chip sensors
@@ -57,7 +58,7 @@ description: |
|27 |FPD Internal voltage measurement, VCC_PSINTFP (supply5). |Voltage
|28 |PS Auxiliary voltage measurement (supply6). |Voltage
|29 |PL VCCADC voltage measurement (vccams). |Voltage
- |30 |Differential analog input signal voltage measurment. |Voltage
+ |30 |Differential analog input signal voltage measurement. |Voltage
|31 |VUser0 voltage measurement (supply7). |Voltage
|32 |VUser1 voltage measurement (supply8). |Voltage
|33 |VUser2 voltage measurement (supply9). |Voltage
@@ -134,6 +135,7 @@ properties:
ams-pl@400:
type: object
+ additionalProperties: false
description:
PL-SYSMON is capable of monitoring off chip voltage and temperature.
PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring
@@ -192,7 +194,6 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
bus {
#address-cells = <2>;
@@ -203,7 +204,7 @@ examples:
interrupt-parent = <&gic>;
interrupts = <0 56 4>;
reg = <0x0 0xffa50000 0x0 0x800>;
- clocks = <&zynqmp_clk AMS_REF>;
+ clocks = <&zynqmp_clk 70>;
#address-cells = <1>;
#size-cells = <1>;
#io-channel-cells = <1>;
diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
new file mode 100644
index 000000000000..2a04906531fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74115.yaml
@@ -0,0 +1,371 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/addac/adi,ad74115.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD74115H device
+
+maintainers:
+ - Cosmin Tanislav <cosmin.tanislav@analog.com>
+
+description: |
+ The AD74115H is a single-channel software configurable input/output
+ device for industrial control applications. It contains functionality for
+ analog output, analog input, digital output, digital input, resistance
+ temperature detector, and thermocouple measurements integrated into a single
+ chip solution with an SPI interface. The device features a 16-bit ADC and a
+ 14-bit DAC.
+
+ https://www.analog.com/en/products/ad74115h.html
+
+properties:
+ compatible:
+ enum:
+ - adi,ad74115h
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 24000000
+
+ spi-cpol: true
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - adc_rdy
+ - alert
+
+ avdd-supply: true
+ avcc-supply: true
+ dvcc-supply: true
+ dovdd-supply: true
+ refin-supply: true
+
+ adi,ch-func:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Channel function.
+ 0 - High impedance
+ 1 - Voltage output
+ 2 - Current output
+ 3 - Voltage input
+ 4 - Current input, externally-powered
+ 5 - Current input, loop-powered
+ 6 - Resistance input
+ 7 - RTD measure
+ 8 - Digital input logic
+ 9 - Digital input, loop-powered
+ 10 - Current output with HART
+ 11 - Current input, externally-powered, with HART
+ 12 - Current input, loop-powered, with HART
+ minimum: 0
+ maximum: 12
+ default: 0
+
+ adi,conv2-mux:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Input node for ADC conversion 2.
+ 0 - SENSE_EXT1 to AGND_SENSE
+ 1 - SENSE_EXT2 to AGND_SENSE
+ 2 - SENSE_EXT2 to SENSE_EXT1
+ 3 - AGND to AGND
+ minimum: 0
+ maximum: 3
+ default: 0
+
+ adi,conv2-range-microvolt:
+ description: Conversion range for ADC conversion 2.
+ oneOf:
+ - items:
+ - enum: [-2500000, 0]
+ - const: 2500000
+ - items:
+ - enum: [-12000000, 0]
+ - const: 12000000
+ - items:
+ - const: -2500000
+ - const: 0
+ - items:
+ - const: -104000
+ - const: 104000
+ - items:
+ - const: 0
+ - const: 625000
+
+ adi,sense-agnd-buffer-low-power:
+ type: boolean
+ description:
+ Whether to enable low-power buffered mode for the AGND sense pin.
+
+ adi,lf-buffer-low-power:
+ type: boolean
+ description:
+ Whether to enable low-power buffered mode for the low-side filtered
+ sense pin.
+
+ adi,hf-buffer-low-power:
+ type: boolean
+ description:
+ Whether to enable low-power buffered mode for the high-side filtered
+ sense pin.
+
+ adi,ext2-buffer-low-power:
+ type: boolean
+ description: Whether to enable low-power buffered mode for the EXT2 pin.
+
+ adi,ext1-buffer-low-power:
+ type: boolean
+ description: Whether to enable low-power buffered mode for the EXT1 pin.
+
+ adi,comparator-invert:
+ type: boolean
+ description: Whether to invert the comparator output.
+
+ adi,digital-input-sink-range-high:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ When not present, the digital input range is from 0 to 3700uA in steps
+ of 120uA, with a ~2k series resistance.
+ When present, the digital input range is from 0 to 7400uA in steps
+ of 240uA, with a ~1k series resistance.
+
+ adi,digital-input-sink-microamp:
+ description: Sink current in digital input mode.
+ minimum: 0
+ maximum: 3700
+ default: 0
+
+ adi,digital-input-debounce-mode-counter-reset:
+ type: boolean
+ description: |
+ When not present, a counter increments when the signal is asserted
+ and decrements when the signal is de-asserted.
+ When present, a counter increments while the signal is asserted and
+ resets when the signal de-asserts
+
+ adi,digital-input-unbuffered:
+ type: boolean
+ description: Whether to buffer digital input signals.
+
+ adi,digital-input-short-circuit-detection:
+ type: boolean
+ description: Whether to detect digital input short circuits.
+
+ adi,digital-input-open-circuit-detection:
+ type: boolean
+ description: Whether to detect digital input open circuits.
+
+ adi,digital-input-threshold-mode-fixed:
+ type: boolean
+ description: |
+ When not present, the digital input threshold range is -0.96 * AVDD
+ to AVDD.
+ When present, the threshold range is fixed from -19V to 30V.
+
+ adi,dac-bipolar:
+ type: boolean
+ description: |
+ When not present, the DAC operates in the 0V to 12V range.
+ When present, the DAC operates in the -12V to 12V range.
+
+ adi,charge-pump:
+ type: boolean
+ description: Whether to enable the internal charge pump.
+
+ adi,dac-hart-slew:
+ type: boolean
+ description: Whether to use a HART-compatible slew rate.
+
+ adi,dac-current-limit-low:
+ type: boolean
+ description: |
+ When not present, the DAC short-circuit current limit is 32mA in
+ either source or sink for VOUT and 4mA sink for IOUT.
+ When present, the limit is 16mA in either source or sink for VOUT,
+ 1mA sink for IOUT.
+
+ adi,4-wire-rtd:
+ type: boolean
+ description: |
+ When not present, the ADC should be used for measuring 3-wire RTDs.
+ When present, the ADC should be used for measuring 4-wire RTDs.
+
+ adi,3-wire-rtd-excitation-swap:
+ type: boolean
+ description: Whether to swap the excitation for 3-wire RTD.
+
+ adi,rtd-excitation-current-microamp:
+ description: Excitation current to apply to RTD.
+ enum: [250, 500, 750, 1000]
+ default: 250
+
+ adi,ext1-burnout:
+ type: boolean
+ description: Whether to enable burnout current for EXT1.
+
+ adi,ext1-burnout-current-nanoamp:
+ description:
+ Burnout current in nanoamps to be applied to EXT1.
+ enum: [0, 50, 500, 1000, 10000]
+ default: 0
+
+ adi,ext1-burnout-current-polarity-sourcing:
+ type: boolean
+ description: |
+ When not present, the burnout current polarity for EXT1 is sinking.
+ When present, the burnout current polarity for EXT1 is sourcing.
+
+ adi,ext2-burnout:
+ type: boolean
+ description: Whether to enable burnout current for EXT2.
+
+ adi,ext2-burnout-current-nanoamp:
+ description: Burnout current in nanoamps to be applied to EXT2.
+ enum: [0, 50, 500, 1000, 10000]
+ default: 0
+
+ adi,ext2-burnout-current-polarity-sourcing:
+ type: boolean
+ description: |
+ When not present, the burnout current polarity for EXT2 is sinking.
+ When present, the burnout current polarity for EXT2 is sourcing.
+
+ adi,viout-burnout:
+ type: boolean
+ description: Whether to enable burnout current for VIOUT.
+
+ adi,viout-burnout-current-nanoamp:
+ description: Burnout current in nanoamps to be applied to VIOUT.
+ enum: [0, 1000, 10000]
+ default: 0
+
+ adi,viout-burnout-current-polarity-sourcing:
+ type: boolean
+ description: |
+ When not present, the burnout current polarity for VIOUT is sinking.
+ When present, the burnout current polarity for VIOUT is sourcing.
+
+ adi,gpio0-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ GPIO functions.
+ 0 - Disabled
+ 1 - Logic I/O
+ 2 - Comparator output
+ 3 - Control HART CD
+ 4 - Monitor HART CD
+ 5 - Monitor HART EOM status
+ minimum: 0
+ maximum: 5
+ default: 0
+
+ adi,gpio1-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ GPIO functions.
+ 0 - Disabled
+ 1 - Logic I/O
+ 2 - Drive external digital output FET
+ 3 - Control HART RXD
+ 4 - Monitor HART RXD
+ 5 - Monitor HART SOM status
+ minimum: 0
+ maximum: 5
+ default: 0
+
+ adi,gpio2-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ GPIO functions.
+ 0 - Disabled
+ 1 - Logic I/O
+ 2 - Drive internal digital output FET
+ 3 - Control HART TXD
+ 4 - Monitor HART TXD
+ 5 - Monitor HART TX complete status
+ minimum: 0
+ maximum: 5
+ default: 0
+
+ adi,gpio3-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ GPIO functions.
+ 0 - Disabled
+ 1 - Logic I/O
+ 2 - High impedance
+ 3 - Control HART RTS
+ 4 - Monitor HART RTS
+ 5 - Monitor HART CD complete status
+ minimum: 0
+ maximum: 5
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - spi-cpol
+ - avdd-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ required:
+ - adi,digital-input-sink-range-high
+ then:
+ properties:
+ adi,digital-input-sink-microamp:
+ maximum: 7400
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ addac@0 {
+ compatible = "adi,ad74115h";
+ reg = <0>;
+
+ spi-max-frequency = <12000000>;
+ spi-cpol;
+
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "adc_rdy";
+
+ avdd-supply = <&ad74115_avdd>;
+
+ adi,ch-func = <1>;
+ adi,conv2-mux = <2>;
+ adi,conv2-range-microvolt = <(-12000000) 12000000>;
+
+ adi,gpio0-mode = <1>;
+ adi,gpio1-mode = <1>;
+ adi,gpio2-mode = <1>;
+ adi,gpio3-mode = <1>;
+
+ adi,dac-bipolar;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml
index baa65a521bad..590ea7936ad7 100644
--- a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml
+++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml
@@ -51,6 +51,9 @@ properties:
Shunt (sense) resistor value in micro-Ohms.
default: 100000000
+ reset-gpios:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -58,11 +61,10 @@ required:
- spi-cpol
- refin-supply
-additionalProperties: false
-
patternProperties:
"^channel@[0-3]$":
type: object
+ additionalProperties: false
description: Represents the external channels which are connected to the device.
properties:
@@ -99,9 +101,23 @@ patternProperties:
When not configured as a comparator, the GPO will be treated as an
output-only GPIO.
+ drive-strength-microamp:
+ description: |
+ For channels configured as digital input, this configures the sink
+ current.
+ minimum: 0
+ maximum: 1800
+ default: 0
+ multipleOf: 120
+
required:
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/gpio/gpio.h>
@@ -112,10 +128,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- cs-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
- status = "okay";
-
- ad74413r@0 {
+ addac@0 {
compatible = "adi,ad74413r";
reg = <0>;
spi-max-frequency = <1000000>;
@@ -128,6 +141,7 @@ examples:
interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
refin-supply = <&ad74413r_refin>;
+ reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
channel@0 {
reg = <0>;
diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
index 527501c1d695..bcf4ddcfd13b 100644
--- a/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
+++ b/Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
@@ -24,6 +24,9 @@ properties:
description: |
Channel node of a voltage io-channel.
+ "#io-channel-cells":
+ const: 0
+
sense-resistor-micro-ohms:
description: The sense resistance.
@@ -46,6 +49,7 @@ examples:
- |
sysi {
compatible = "current-sense-amplifier";
+ #io-channel-cells = <0>;
io-channels = <&tiadc 0>;
sense-resistor-micro-ohms = <20000>;
diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
index df2589f214e1..9752d1450064 100644
--- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
+++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
@@ -13,7 +13,7 @@ description: |
When an io-channel measures the midpoint of a voltage divider, the
interesting voltage is often the voltage over the full resistance
of the divider. This binding describes the voltage divider in such
- a curcuit.
+ a circuit.
Vin ----.
|
@@ -29,7 +29,6 @@ description: |
|
GND
-
properties:
compatible:
const: voltage-divider
@@ -39,6 +38,17 @@ properties:
description: |
Channel node of a voltage io-channel.
+ '#io-channel-cells':
+ description:
+ In addition to consuming the measurement services of a voltage
+ output channel, the voltage divider can act as a provider of
+ measurement services to other devices. This is particularly
+ useful in scenarios wherein an ADC has an analog frontend,
+ such as a voltage divider, and then consuming its raw value
+ isn't interesting. In this case, the voltage before the divider
+ is desired.
+ const: 1
+
output-ohms:
description:
Resistance Rout over which the output voltage is measured. See full-ohms.
diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml
index 5277479be382..c15da155d300 100644
--- a/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml
+++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml
@@ -27,14 +27,15 @@ properties:
Enable internal buffer to drive the reference pin.
type: boolean
- spi-max-frequency: true
-
required:
- compatible
- reg
- avdd-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml
index 9fda56fa49c3..3a470459b965 100644
--- a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml
+++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml
@@ -4,30 +4,81 @@
$id: http://devicetree.org/schemas/iio/amplifiers/adi,hmc425a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: HMC425A 6-bit Digital Step Attenuator
+title: Analog Devices HMC425A and similar Digital Step Attenuators
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
description: |
- Digital Step Attenuator IIO device with gpio interface.
+ Digital Step Attenuator IIO devices with gpio interface.
+ Offer various frequency and attenuation ranges.
+ ADRF5750 2 dB LSB, 4-Bit, Silicon Digital Attenuator, 10 MHz to 60 GHz
+ https://www.analog.com/media/en/technical-documentation/data-sheets/adrf5740.pdf
+
HMC425A 0.5 dB LSB GaAs MMIC 6-BIT DIGITAL POSITIVE CONTROL ATTENUATOR, 2.2 - 8.0 GHz
- https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
+
+ HMC540S 1 dB LSB Silicon MMIC 4-Bit Digital Positive Control Attenuator, 0.1 - 8 GHz
+ https://www.analog.com/media/en/technical-documentation/data-sheets/hmc540s.pdf
+
+ LTC6373 is a 3-Bit precision instrumentation amplifier with fully differential outputs
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc6373.pdf
properties:
compatible:
enum:
+ - adi,adrf5740
- adi,hmc425a
+ - adi,hmc540s
+ - adi,ltc6373
vcc-supply: true
ctrl-gpios:
description:
- Must contain an array of 6 GPIO specifiers, referring to the GPIO pins
- connected to the control pins V1-V6.
- minItems: 6
+ Must contain an array of GPIO specifiers, referring to the GPIO pins
+ connected to the control pins.
+ ADRF5740 - 4 GPIO connected to D2-D5
+ HMC540S - 4 GPIO connected to V1-V4
+ HMC425A - 6 GPIO connected to V1-V6
+ LTC6373 - 3 GPIO connected to A0-A2
+ minItems: 1
maxItems: 6
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,hmc425a
+ then:
+ properties:
+ ctrl-gpios:
+ minItems: 6
+ maxItems: 6
+ - if:
+ properties:
+ compatible:
+ contains:
+ anyOf:
+ - const: adi,adrf5740
+ - const: adi,hmc540s
+ then:
+ properties:
+ ctrl-gpios:
+ minItems: 4
+ maxItems: 4
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,ltc6373
+ then:
+ properties:
+ ctrl-gpios:
+ minItems: 3
+ maxItems: 3
+
required:
- compatible
- ctrl-gpios
diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml b/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml
index 2155d3f5666c..3d7074fd17be 100644
--- a/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml
+++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7150.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/cdc/adi,ad7150.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog device AD7150 and similar capacitance to digital convertors.
+title: Analog device AD7150 and similar capacitance to digital converters.
maintainers:
- Jonathan Cameron <jic23@kernel.org>
diff --git a/Documentation/devicetree/bindings/iio/chemical/aosong,ags02ma.yaml b/Documentation/devicetree/bindings/iio/chemical/aosong,ags02ma.yaml
new file mode 100644
index 000000000000..35e7b094e878
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/aosong,ags02ma.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/chemical/aosong,ags02ma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aosong AGS02MA VOC Sensor
+
+description: |
+ AGS02MA is an TVOC (Total Volatile Organic Compounds) i2c sensor with default
+ address of 0x1a.
+
+ Datasheet:
+ https://asairsensors.com/wp-content/uploads/2021/09/AGS02MA.pdf
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - aosong,ags02ma
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ voc-sensor@1a {
+ compatible = "aosong,ags02ma";
+ reg = <0x1a>;
+ vdd-supply = <&vdd_regulator>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml b/Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml
new file mode 100644
index 000000000000..fe98ec44f081
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/bosch,bme680.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/chemical/bosch,bme680.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BME680 Gas sensor
+
+maintainers:
+ - Vasileios Amoiridis <vassilisamir@gmail.com>
+
+description: >
+ BME680 is a gas sensor which combines relative humidity, barometric pressure,
+ ambient temperature and gas (VOC - Volatile Organic Compounds) measurements.
+
+ https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme680-ds001.pdf
+
+properties:
+ compatible:
+ const: bosch,bme680
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ co2-sensor@77 {
+ compatible = "bosch,bme680";
+ reg = <0x77>;
+ vddio-supply = <&vddio>;
+ vdd-supply = <&vdd>;
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ co2-sensor@0 {
+ compatible = "bosch,bme680";
+ reg = <0>;
+ spi-max-frequency = <500000>;
+ vddio-supply = <&vddio>;
+ vdd-supply = <&vdd>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/chemical/sciosense,ens160.yaml b/Documentation/devicetree/bindings/iio/chemical/sciosense,ens160.yaml
new file mode 100644
index 000000000000..267033a68abb
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/sciosense,ens160.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/chemical/sciosense,ens160.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ScioSense ENS160 multi-gas sensor
+
+maintainers:
+ - Gustavo Silva <gustavograzs@gmail.com>
+
+description: |
+ Digital Multi-Gas Sensor for Monitoring Indoor Air Quality.
+
+ Datasheet:
+ https://www.sciosense.com/wp-content/uploads/2023/12/ENS160-Datasheet.pdf
+
+properties:
+ compatible:
+ enum:
+ - sciosense,ens160
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gas-sensor@52 {
+ compatible = "sciosense,ens160";
+ reg = <0x52>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <19 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gas-sensor@0 {
+ compatible = "sciosense,ens160";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <19 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/chemical/winsen,mhz19b.yaml b/Documentation/devicetree/bindings/iio/chemical/winsen,mhz19b.yaml
new file mode 100644
index 000000000000..2a6ddb33f163
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/winsen,mhz19b.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/chemical/winsen,mhz19b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MHZ19B CO2 sensor
+
+maintainers:
+ - Gyeyoung Baek <gye976@gmail.com>
+
+properties:
+ compatible:
+ const: winsen,mhz19b
+
+ vin-supply:
+ description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - vin-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ serial {
+ co2-sensor {
+ compatible = "winsen,mhz19b";
+ vin-supply = <&vdd>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/common.yaml b/Documentation/devicetree/bindings/iio/common.yaml
index f845b41d74c4..b3a10af86d76 100644
--- a/Documentation/devicetree/bindings/iio/common.yaml
+++ b/Documentation/devicetree/bindings/iio/common.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
This document defines device tree properties common to several iio
- sensors. It doesn't constitue a device tree binding specification by itself but
+ sensors. It doesn't constitute a device tree binding specification by itself but
is meant to be referenced by device tree bindings.
When referenced from sensor tree bindings the properties defined in this
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
new file mode 100644
index 000000000000..a355d52a9d64
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad3530r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD3530R and Similar DACs
+
+maintainers:
+ - Kim Seer Paller <kimseer.paller@analog.com>
+
+description: |
+ The AD3530/AD3530R (8-channel) and AD3531/AD3531R (4-channel) are low-power,
+ 16-bit, buffered voltage output digital-to-analog converters (DACs) with
+ software-programmable gain controls, providing full-scale output spans of 2.5V
+ or 5V for reference voltages of 2.5V. These devices operate from a single 2.7V
+ to 5.5V supply and are guaranteed monotonic by design. The "R" variants
+ include a 2.5V, 5ppm/°C internal reference, which is disabled by default.
+ Datasheet can be found here:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad3530_ad530r.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad3531-ad3531r.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad3530
+ - adi,ad3530r
+ - adi,ad3531
+ - adi,ad3531r
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 50000000
+
+ vdd-supply:
+ description: Power Supply Input.
+
+ iovdd-supply:
+ description: Digital Power Supply Input.
+
+ io-channels:
+ description:
+ ADC channel used to monitor internal die temperature, output voltages, and
+ current of a selected channel via the MUXOUT pin.
+ maxItems: 1
+
+ ref-supply:
+ description:
+ Reference Input/Output. The voltage at the REF pin sets the full-scale
+ range of all channels. If not provided the internal reference is used and
+ also provided on the VREF pin.
+
+ reset-gpios:
+ description:
+ Active low signal that is falling edge sensitive. When it is deasserted,
+ the digital core initialization is performed and all DAC registers except
+ the Interface Configuration A register are reset to their default values.
+ maxItems: 1
+
+ ldac-gpios:
+ description:
+ LDAC pin to be used as a hardware trigger to update the DAC channels. If
+ not present, the DAC channels are updated by Software LDAC.
+ maxItems: 1
+
+ adi,range-double:
+ description:
+ Configure the output range for all channels. If the property is present,
+ the output will range from 0V to 2Vref. If the property is not present,
+ the output will range from 0V to Vref.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - iovdd-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dac@0 {
+ compatible = "adi,ad3530r";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+
+ vdd-supply = <&vdd>;
+ iovdd-supply = <&iovdd>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
index 9c48c76993fe..547044b8e246 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml
@@ -13,20 +13,24 @@ maintainers:
description: |
Bindings for the Analog Devices AD3552R DAC device and similar.
Datasheet can be found here:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad3541r.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3542r.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad3551r.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf
properties:
compatible:
enum:
+ - adi,ad3541r
- adi,ad3542r
+ - adi,ad3551r
- adi,ad3552r
reg:
maxItems: 1
spi-max-frequency:
- maximum: 30000000
+ maximum: 66000000
reset-gpios:
maxItems: 1
@@ -56,6 +60,12 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
+ io-backends:
+ description: The iio backend reference.
+ Device can be optionally connected to the "axi-ad3552r IP" fpga-based
+ QSPI + DDR (Double Data Rate) controller to reach high speed transfers.
+ maxItems: 1
+
'#address-cells':
const: 1
@@ -78,6 +88,7 @@ patternProperties:
custom-output-range-config:
type: object
+ additionalProperties: false
description: Configuration of custom range when
adi,output-range-microvolt is not present.
The formulas for calculation the output voltages are
@@ -91,13 +102,13 @@ patternProperties:
maximum: 511
minimum: -511
- adi,gain-scaling-p-inv-log2:
- description: GainP = 1 / ( 2 ^ adi,gain-scaling-p-inv-log2)
+ adi,gain-scaling-p:
+ description: GainP = 1 / ( 2 ^ adi,gain-scaling-p)
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
- adi,gain-scaling-n-inv-log2:
- description: GainN = 1 / ( 2 ^ adi,gain-scaling-n-inv-log2)
+ adi,gain-scaling-n:
+ description: GainN = 1 / ( 2 ^ adi,gain-scaling-n)
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
@@ -106,8 +117,8 @@ patternProperties:
required:
- adi,gain-offset
- - adi,gain-scaling-p-inv-log2
- - adi,gain-scaling-n-inv-log2
+ - adi,gain-scaling-p
+ - adi,gain-scaling-n
- adi,rfb-ohms
required:
@@ -123,11 +134,14 @@ patternProperties:
- custom-output-range-config
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
contains:
- const: adi,ad3542r
+ enum:
+ - adi,ad3541r
+ - adi,ad3542r
then:
patternProperties:
"^channel@([0-1])$":
@@ -138,7 +152,7 @@ allOf:
Voltage output range of the channel as <minimum, maximum>
Required connections:
Rfb1x for: 0 to 2.5 V; 0 to 3V; 0 to 5 V;
- Rfb2x for: 0 to 10 V; 2.5 to 7.5V; -5 to 5 V;
+ Rfb2x for: 0 to 10 V; -2.5 to 7.5V; -5 to 5 V;
oneOf:
- items:
- const: 0
@@ -157,7 +171,9 @@ allOf:
properties:
compatible:
contains:
- const: adi,ad3552r
+ enum:
+ - adi,ad3551r
+ - adi,ad3552r
then:
patternProperties:
"^channel@([0-1])$":
@@ -181,36 +197,51 @@ allOf:
- const: -10000000
- const: 10000000
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad3541r
+ - adi,ad3551r
+ then:
+ properties:
+ channel@1: false
+ channel@0:
+ properties:
+ reg:
+ const: 0
+
required:
- compatible
- reg
- spi-max-frequency
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
- ad3552r@0 {
- compatible = "adi,ad3552r";
- reg = <0>;
- spi-max-frequency = <20000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- channel@0 {
- reg = <0>;
- adi,output-range-microvolt = <0 10000000>;
- };
- channel@1 {
- reg = <1>;
- custom-output-range-config {
- adi,gain-offset = <5>;
- adi,gain-scaling-p-inv-log2 = <1>;
- adi,gain-scaling-n-inv-log2 = <2>;
- adi,rfb-ohms = <1>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ad3552r@0 {
+ compatible = "adi,ad3552r";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ adi,output-range-microvolt = <0 10000000>;
+ };
+ channel@1 {
+ reg = <1>;
+ custom-output-range-config {
+ adi,gain-offset = <5>;
+ adi,gain-scaling-p = <1>;
+ adi,gain-scaling-n = <2>;
+ adi,rfb-ohms = <1>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml
index 05ed4e0ec364..c04165fa9259 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml
@@ -95,15 +95,12 @@ properties:
vrefD-supply: true
vref-supply: true
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- # Shared external vref, no internal reference
if:
properties:
@@ -232,6 +229,8 @@ allOf:
- vrefA-supply
- vrefB-supply
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml
index 65f86f26947c..86e2884cdfb1 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml
@@ -28,10 +28,6 @@ properties:
vref1-supply: true
vref2-supply: true
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
@@ -39,6 +35,7 @@ required:
- vref1-supply
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@@ -63,6 +60,8 @@ allOf:
required:
- vref2-supply
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
index d599b418a020..3e323f1a5458 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml
@@ -12,6 +12,7 @@ maintainers:
description: |
DAC devices supporting both SPI and I2C interfaces.
+
properties:
compatible:
enum:
@@ -39,32 +40,33 @@ properties:
description:
If not supplied devices will use internal regulators.
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
dac@0 {
- reg = <0>;
- compatible = "adi,ad5390-5";
- vref-supply = <&dacvref>;
+ reg = <0>;
+ compatible = "adi,ad5390-5";
+ vref-supply = <&dacvref>;
};
};
- |
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- dac@42 {
- reg = <0x42>;
- compatible = "adi,ad5380-3";
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dac@42 {
+ reg = <0x42>;
+ compatible = "adi,ad5380-3";
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml
index 188f656617e3..52d089ebde95 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml
@@ -26,13 +26,14 @@ properties:
maxItems: 1
description: Fault signal.
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5446.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5446.yaml
new file mode 100644
index 000000000000..2669d2c4948b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5446.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5446.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5446 and similar DACs
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+description:
+ Digital to Analog Converter devices supporting both SPI and I2C interfaces.
+ These devices feature a range of resolutions from 8-bit to 16-bit.
+
+properties:
+ compatible:
+ oneOf:
+ - description: SPI DACs
+ enum:
+ - adi,ad5300
+ - adi,ad5310
+ - adi,ad5320
+ - adi,ad5444
+ - adi,ad5446
+ - adi,ad5450
+ - adi,ad5451
+ - adi,ad5452
+ - adi,ad5453
+ - adi,ad5512a
+ - adi,ad5541a
+ - adi,ad5542
+ - adi,ad5542a
+ - adi,ad5543
+ - adi,ad5553
+ - adi,ad5600
+ - adi,ad5601
+ - adi,ad5611
+ - adi,ad5621
+ - adi,ad5641
+ - adi,ad5620-2500
+ - adi,ad5620-1250
+ - adi,ad5640-2500
+ - adi,ad5640-1250
+ - adi,ad5660-2500
+ - adi,ad5660-1250
+ - adi,ad5662
+ - ti,dac081s101
+ - ti,dac101s101
+ - ti,dac121s101
+ - description: I2C DACs
+ enum:
+ - adi,ad5301
+ - adi,ad5311
+ - adi,ad5321
+ - adi,ad5602
+ - adi,ad5612
+ - adi,ad5622
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description:
+ Reference voltage supply. If not supplied, devices with internal
+ voltage reference will use that.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ad5300
+ - adi,ad5310
+ - adi,ad5320
+ - adi,ad5444
+ - adi,ad5446
+ - adi,ad5450
+ - adi,ad5451
+ - adi,ad5452
+ - adi,ad5453
+ - adi,ad5512a
+ - adi,ad5541a
+ - adi,ad5542
+ - adi,ad5542a
+ - adi,ad5543
+ - adi,ad5553
+ - adi,ad5600
+ - adi,ad5601
+ - adi,ad5611
+ - adi,ad5621
+ - adi,ad5641
+ - adi,ad5620-2500
+ - adi,ad5620-1250
+ - adi,ad5640-2500
+ - adi,ad5640-1250
+ - adi,ad5660-2500
+ - adi,ad5660-1250
+ - adi,ad5662
+ - ti,dac081s101
+ - ti,dac101s101
+ - ti,dac121s101
+ then:
+ allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad5446";
+ reg = <0>;
+ vcc-supply = <&dac_vref>;
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@42 {
+ compatible = "adi,ad5622";
+ reg = <0x42>;
+ vcc-supply = <&dac_vref>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml
index 044332c97743..d2af2d491986 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml
@@ -27,19 +27,16 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
VREF-supply: true
VREFA-supply: true
VREFB-supply: true
-additionalProperties: false
-
required:
- compatible
- reg
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@@ -72,6 +69,8 @@ allOf:
- VREFA-supply
- VREFB-supply
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml
index 330383b85eeb..4d5111a5f9bd 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml
@@ -22,17 +22,18 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply:
description: If not present, internal reference will be used.
-additionalProperties: false
-
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
index 5c26441eae9f..713f535bb33a 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.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:
- Michael Hennerich <michael.hennerich@analog.com>
@@ -12,40 +12,22 @@ maintainers:
properties:
compatible:
- oneOf:
- - description: SPI devices
- enum:
- - adi,ad5310r
- - adi,ad5672r
- - adi,ad5674r
- - adi,ad5676
- - adi,ad5676r
- - adi,ad5679r
- - adi,ad5681r
- - adi,ad5682r
- - adi,ad5683
- - adi,ad5683r
- - adi,ad5684
- - adi,ad5684r
- - adi,ad5685r
- - adi,ad5686
- - adi,ad5686r
- - description: I2C devices
- enum:
- - adi,ad5311r
- - adi,ad5338r
- - adi,ad5671r
- - adi,ad5675r
- - adi,ad5691r
- - adi,ad5692r
- - adi,ad5693
- - adi,ad5693r
- - adi,ad5694
- - adi,ad5694r
- - adi,ad5695r
- - adi,ad5696
- - adi,ad5696r
-
+ enum:
+ - adi,ad5310r
+ - adi,ad5672r
+ - adi,ad5674r
+ - adi,ad5676
+ - adi,ad5676r
+ - adi,ad5679r
+ - adi,ad5681r
+ - adi,ad5682r
+ - adi,ad5683
+ - adi,ad5683r
+ - adi,ad5684
+ - adi,ad5684r
+ - adi,ad5685r
+ - adi,ad5686
+ - adi,ad5686r
reg:
maxItems: 1
@@ -53,14 +35,15 @@ properties:
vcc-supply:
description: If not supplied the internal reference is used.
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
index 56b0cda0f30a..b5a88b03dc2f 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/dac/adi,ad5696.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:
- Michael Auchter <michael.auchter@ni.com>
@@ -16,6 +16,7 @@ properties:
compatible:
enum:
- adi,ad5311r
+ - adi,ad5337r
- adi,ad5338r
- adi,ad5671r
- adi,ad5675r
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml
index f866b88e1440..9a3c2926bf85 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml
@@ -25,8 +25,6 @@ properties:
description: Either this or spi-cpol but not both.
spi-cpol: true
- spi-max-frequency: true
-
adi,ext-dc-dc-compenstation-resistor:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -67,8 +65,6 @@ required:
- compatible
- reg
-additionalProperties: false
-
patternProperties:
"^channel@[0-7]$":
type: object
@@ -123,6 +119,11 @@ oneOf:
- required:
- spi-cpol
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
index fd4edca34a28..5121685337b5 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
@@ -16,7 +16,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
spi-cpha: true
adi,dc-dc-mode:
@@ -79,7 +78,8 @@ properties:
- const: -1000
- const: 22000
- reset-gpios: true
+ reset-gpios:
+ maxItems: 1
adi,dc-dc-ilim-microamp:
enum: [150000, 200000, 250000, 300000, 350000, 400000]
@@ -99,11 +99,11 @@ required:
- adi,dc-dc-mode
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
adi,dc-dc-mode:
- contains:
- enum: [1, 3]
+ enum: [1, 3]
then:
properties:
adi,range-microvolt: false
@@ -115,7 +115,7 @@ allOf:
required:
- adi,range-microvolt
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml
index 7f95a9ed55fe..df550b5af2f7 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml
@@ -22,18 +22,15 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply:
description: If not supplied, internal reference will be used.
-additionalProperties: false
-
required:
- compatible
- reg
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@@ -45,6 +42,8 @@ allOf:
required:
- vref-supply
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml
index 8e893d52bfb1..0b409a727a43 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml
@@ -22,18 +22,15 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vrefAB-supply: true
vrefCD-supply: true
-additionalProperties: false
-
required:
- compatible
- reg
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@@ -46,6 +43,8 @@ allOf:
- vrefAB-supply
- vrefCD-supply
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml
index 29bd16dab546..212c936bab8d 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5766.yaml
@@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD5766 DAC device driver
maintainers:
- - Cristian Pop <cristian.pop@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description: |
Bindings for the Analog Devices AD5766 current DAC device. Datasheet can be
@@ -51,15 +51,15 @@ additionalProperties: false
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- ad5766@0 {
- compatible = "adi,ad5766";
- output-range-microvolts = <(-5000000) 5000000>;
- reg = <0>;
- spi-cpol;
- spi-max-frequency = <1000000>;
- reset-gpios = <&gpio 22 0>;
- };
- };
+ ad5766@0 {
+ compatible = "adi,ad5766";
+ output-range-microvolts = <(-5000000) 5000000>;
+ reg = <0>;
+ spi-cpol;
+ spi-max-frequency = <1000000>;
+ reset-gpios = <&gpio 22 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml
index 24ac40180ac1..091cc93f1f90 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml
@@ -8,7 +8,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD5770R DAC device driver
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description: |
Bindings for the Analog Devices AD5770R current DAC device. Datasheet can be
@@ -49,8 +50,6 @@ properties:
asserted during driver probe.
maxItems: 1
- spi-max-frequency: true
-
'#address-cells':
const: 1
@@ -62,6 +61,7 @@ properties:
connected to the DAC. Channel 0 can act both as a current
source and sink.
type: object
+ additionalProperties: false
properties:
reg:
@@ -85,6 +85,7 @@ properties:
description: Represents an external channel which are
connected to the DAC.
type: object
+ additionalProperties: false
properties:
reg:
@@ -101,6 +102,7 @@ properties:
description: Represents an external channel which are
connected to the DAC.
type: object
+ additionalProperties: false
properties:
reg:
@@ -116,6 +118,7 @@ properties:
patternProperties:
"^channel@([3-5])$":
type: object
+ additionalProperties: false
description: Represents the external channels which are connected to the DAC.
properties:
reg:
@@ -138,53 +141,56 @@ required:
- channel@4
- channel@5
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- spi {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ad5770r@0 {
- compatible = "adi,ad5770r";
- reg = <0>;
- spi-max-frequency = <1000000>;
- vref-supply = <&vref>;
- adi,external-resistor;
- reset-gpios = <&gpio 22 0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- channel@0 {
- reg = <0>;
- adi,range-microamp = <0 300000>;
- };
-
- channel@1 {
- reg = <1>;
- adi,range-microamp = <0 140000>;
- };
-
- channel@2 {
- reg = <2>;
- adi,range-microamp = <0 55000>;
- };
-
- channel@3 {
- reg = <3>;
- adi,range-microamp = <0 45000>;
- };
-
- channel@4 {
- reg = <4>;
- adi,range-microamp = <0 45000>;
- };
-
- channel@5 {
- reg = <5>;
- adi,range-microamp = <0 45000>;
- };
- };
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ad5770r@0 {
+ compatible = "adi,ad5770r";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ vref-supply = <&vref>;
+ adi,external-resistor;
+ reset-gpios = <&gpio 22 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ adi,range-microamp = <0 300000>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ adi,range-microamp = <0 140000>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ adi,range-microamp = <0 55000>;
+ };
+
+ channel@3 {
+ reg = <3>;
+ adi,range-microamp = <0 45000>;
+ };
+
+ channel@4 {
+ reg = <4>;
+ adi,range-microamp = <0 45000>;
+ };
+
+ channel@5 {
+ reg = <5>;
+ adi,range-microamp = <0 45000>;
+ };
};
+ };
...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
index 650d1ebdcec3..2bd89e0aa46b 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
@@ -23,21 +23,59 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vdd-supply: true
vss-supply: true
-additionalProperties: false
+ vcc-supply:
+ description:
+ Supply that powers the chip.
+
+ iovcc-supply:
+ description:
+ Supply for the digital interface.
+
+ vrefp-supply:
+ description:
+ Positive referance input voltage range. From 5v to (vdd - 2.5)
+
+ vrefn-supply:
+ description:
+ Negative referance input voltage range. From (vss + 2.5) to 0.
+
+ adi,rbuf-gain2-en:
+ description: Specify to allow an external amplifier to be connected in a
+ gain of two configuration.
+ type: boolean
+
+ reset-gpios:
+ maxItems: 1
+
+ clear-gpios:
+ maxItems: 1
+
+ ldac-gpios:
+ description:
+ LDAC pin to be used as a hardware trigger to update the DAC channels.
+ maxItems: 1
required:
- compatible
- reg
- vdd-supply
- vss-supply
+ - vcc-supply
+ - iovcc-supply
+ - vrefp-supply
+ - vrefn-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -47,6 +85,13 @@ examples:
reg = <0>;
vss-supply = <&dac_vss>;
vdd-supply = <&dac_vdd>;
+ vcc-supply = <&dac_vcc>;
+ iovcc-supply = <&dac_iovcc>;
+ vrefp-supply = <&dac_vrefp>;
+ vrefn-supply = <&dac_vrefn>;
+ reset-gpios = <&gpio_bd 16 GPIO_ACTIVE_LOW>;
+ clear-gpios = <&gpio_bd 17 GPIO_ACTIVE_LOW>;
+ ldac-gpios = <&gpio_bd 18 GPIO_ACTIVE_LOW>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml
index 5ee80bf6aa11..f994c1ef6d41 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml
@@ -27,6 +27,8 @@ properties:
vdrive-supply: true
+ vrefin-supply: true
+
reset-gpios:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad8460.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad8460.yaml
new file mode 100644
index 000000000000..b65928024e12
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad8460.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2024 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad8460.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD8460 DAC
+
+maintainers:
+ - Mariel Tinaco <mariel.tinaco@analog.com>
+
+description: |
+ Analog Devices AD8460 110 V High Voltage, 1 A High Current,
+ Arbitrary Waveform Generator with Integrated 14-Bit High Speed DAC
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad8460.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad8460
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: tx
+
+ spi-max-frequency:
+ maximum: 20000000
+
+ hvcc-supply:
+ description: Positive high voltage power supply line
+
+ hvee-supply:
+ description: Negative high voltage power supply line
+
+ vcc-5v-supply:
+ description: Low voltage power supply
+
+ vref-5v-supply:
+ description: Reference voltage for analog low voltage
+
+ dvdd-3p3v-supply:
+ description: Digital supply bypass
+
+ avdd-3p3v-supply:
+ description: Analog supply bypass
+
+ refio-1p2v-supply:
+ description: Drive voltage in the range of 1.2V maximum to as low as
+ low as 0.12V through the REF_IO pin to adjust full scale output span
+
+ adi,external-resistor-ohms:
+ description: Specify value of external resistor connected to FS_ADJ pin
+ to establish internal HVDAC's reference current I_REF
+ minimum: 2000
+ maximum: 20000
+ default: 2000
+
+ adi,range-microvolt:
+ description: Voltage output range specified as <minimum, maximum>
+ items:
+ - minimum: -55000000
+ maximum: 0
+ default: 0
+ - minimum: 0
+ maximum: 55000000
+ default: 0
+
+ adi,range-microamp:
+ description: Current output range specified as <minimum, maximum>
+ items:
+ - minimum: -1000000
+ maximum: 0
+ default: 0
+ - minimum: 0
+ maximum: 1000000
+ default: 0
+
+ adi,max-millicelsius:
+ description: Overtemperature threshold
+ minimum: 0
+ maximum: 150000
+ default: 0
+
+ shutdown-reset-gpios:
+ description: Corresponds to SDN_RESET pin. To exit shutdown
+ or sleep mode, pulse SDN_RESET HIGH, then leave LOW.
+ maxItems: 1
+
+ reset-gpios:
+ description: Manual Power On Reset (POR). Pull this GPIO pin
+ LOW and then HIGH to reset all digital registers to default
+ maxItems: 1
+
+ shutdown-gpios:
+ description: Corresponds to SDN_IO pin. Shutdown may be
+ initiated by the user, by pulsing SDN_IO high. To exit shutdown,
+ pulse SDN_IO low, then float.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - hvcc-supply
+ - hvee-supply
+ - vcc-5v-supply
+ - vref-5v-supply
+ - dvdd-3p3v-supply
+ - avdd-3p3v-supply
+ - refio-1p2v-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad8460";
+ reg = <0>;
+ spi-max-frequency = <8000000>;
+
+ dmas = <&tx_dma 0>;
+ dma-names = "tx";
+
+ shutdown-reset-gpios = <&gpio 86 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 91 GPIO_ACTIVE_LOW>;
+ shutdown-gpios = <&gpio 88 GPIO_ACTIVE_HIGH>;
+
+ clocks = <&sync_ext_clk>;
+
+ hvcc-supply = <&hvcc>;
+ hvee-supply = <&hvee>;
+ vcc-5v-supply = <&vcc_5>;
+ vref-5v-supply = <&vref_5>;
+ dvdd-3p3v-supply = <&dvdd_3_3>;
+ avdd-3p3v-supply = <&avdd_3_3>;
+ refio-1p2v-supply = <&refio_1_2>;
+
+ adi,external-resistor-ohms = <2000>;
+ adi,range-microvolt = <(-40000000) 40000000>;
+ adi,range-microamp = <0 50000>;
+ adi,max-millicelsius = <50000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml
index 6a3990a8d0ad..1849a2ff05c7 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml
@@ -19,19 +19,16 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vrefh-supply: true
vrefl-supply: true
-additionalProperties: false
-
required:
- compatible
- reg
- vrefh-supply
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@@ -44,6 +41,8 @@ allOf:
properties:
vrefl-supply: false
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad9739a.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad9739a.yaml
new file mode 100644
index 000000000000..c0b36476113a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad9739a.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad9739a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD9739A RF DAC
+
+maintainers:
+ - Dragos Bogdan <dragos.bogdan@analog.com>
+ - Nuno Sa <nuno.sa@analog.com>
+
+description: |
+ The AD9739A is a 14-bit, 2.5 GSPS high performance RF DACs that are capable
+ of synthesizing wideband signals from dc up to 3 GHz.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad9737a_9739a.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad9739a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-3p3-supply:
+ description: 3.3V Digital input supply.
+
+ vdd-supply:
+ description: 1.8V Digital input supply.
+
+ vdda-supply:
+ description: 3.3V Analog input supply.
+
+ vddc-supply:
+ description: 1.8V Clock input supply.
+
+ vref-supply:
+ description: Input/Output reference supply.
+
+ io-backends:
+ maxItems: 1
+
+ adi,full-scale-microamp:
+ description: This property represents the DAC full scale current.
+ minimum: 8580
+ maximum: 31700
+ default: 20000
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - io-backends
+ - vdd-3p3-supply
+ - vdd-supply
+ - vdda-supply
+ - vddc-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad9739a";
+ reg = <0>;
+
+ clocks = <&dac_clk>;
+
+ io-backends = <&iio_backend>;
+
+ vdd-3p3-supply = <&vdd_3_3>;
+ vdd-supply = <&vdd>;
+ vdda-supply = <&vdd_3_3>;
+ vddc-supply = <&vdd>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
new file mode 100644
index 000000000000..1adba9aceeb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,axi-dac.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,axi-dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AXI DAC IP core
+
+maintainers:
+ - Nuno Sa <nuno.sa@analog.com>
+
+description: |
+ Analog Devices Generic AXI DAC IP core for interfacing a DAC device
+ with a high speed serial (JESD204B/C) or source synchronous parallel
+ interface (LVDS/CMOS).
+ Usually, some other interface type (i.e SPI) is used as a control
+ interface for the actual DAC, while this IP core will interface
+ to the data-lines of the DAC and handle the streaming of data from
+ memory via DMA into the DAC.
+
+ https://wiki.analog.com/resources/fpga/docs/axi_dac_ip
+ https://analogdevicesinc.github.io/hdl/library/axi_ad3552r/index.html
+
+properties:
+ compatible:
+ enum:
+ - adi,axi-dac-9.1.b
+ - adi,axi-ad3552r
+
+ reg:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: tx
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: s_axi_aclk
+ - const: dac_clk
+ minItems: 1
+
+ '#io-backend-cells':
+ const: 0
+
+required:
+ - compatible
+ - dmas
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,axi-ad3552r
+ then:
+ $ref: /schemas/spi/spi-controller.yaml#
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ required:
+ - clock-names
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dac@44a00000 {
+ compatible = "adi,axi-dac-9.1.b";
+ reg = <0x44a00000 0x10000>;
+ dmas = <&tx_dma 0>;
+ dma-names = "tx";
+ #io-backend-cells = <0>;
+ clocks = <&clkc 15>;
+ clock-names = "s_axi_aclk";
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ axi_dac: spi@44a70000 {
+ compatible = "adi,axi-ad3552r";
+ reg = <0x44a70000 0x1000>;
+ dmas = <&dac_tx_dma 0>;
+ dma-names = "tx";
+ #io-backend-cells = <0>;
+ clocks = <&clkc 15>, <&ref_clk>;
+ clock-names = "s_axi_aclk", "dac_clk";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad3552r";
+ reg = <0>;
+ reset-gpios = <&gpio0 92 GPIO_ACTIVE_HIGH>;
+ io-backends = <&axi_dac>;
+ spi-max-frequency = <20000000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ adi,output-range-microvolt = <(-10000000) (10000000)>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml
new file mode 100644
index 000000000000..4688eccfeb89
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2664.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ltc2664.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2664 DAC
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+ - Kim Seer Paller <kimseer.paller@analog.com>
+
+description: |
+ Analog Devices LTC2664 4 channel, 12-/16-Bit, +-10V DAC
+ https://www.analog.com/media/en/technical-documentation/data-sheets/2664fa.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc2664
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 50000000
+
+ vcc-supply:
+ description: Analog Supply Voltage Input.
+
+ v-pos-supply:
+ description: Positive Supply Voltage Input.
+
+ v-neg-supply:
+ description: Negative Supply Voltage Input.
+
+ iovcc-supply:
+ description: Digital Input/Output Supply Voltage.
+
+ ref-supply:
+ description:
+ Reference Input/Output. The voltage at the REF pin sets the full-scale
+ range of all channels. If not provided the internal reference is used and
+ also provided on the VREF pin.
+
+ reset-gpios:
+ description:
+ Active-low Asynchronous Clear Input. A logic low at this level-triggered
+ input clears the part to the reset code and range determined by the
+ hardwired option chosen using the MSPAN pins. The control registers are
+ cleared to zero.
+ maxItems: 1
+
+ adi,manual-span-operation-config:
+ description:
+ This property must mimic the MSPAN pin configurations. By tying the MSPAN
+ pins (MSP2, MSP1 and MSP0) to GND and/or VCC, any output range can be
+ hardware-configured with different mid-scale or zero-scale reset options.
+ The hardware configuration is latched during power on reset for proper
+ operation.
+ 0 - MPS2=GND, MPS1=GND, MSP0=GND (+-10V, reset to 0V)
+ 1 - MPS2=GND, MPS1=GND, MSP0=VCC (+-5V, reset to 0V)
+ 2 - MPS2=GND, MPS1=VCC, MSP0=GND (+-2.5V, reset to 0V)
+ 3 - MPS2=GND, MPS1=VCC, MSP0=VCC (0V to 10, reset to 0V)
+ 4 - MPS2=VCC, MPS1=GND, MSP0=GND (0V to 10V, reset to 5V)
+ 5 - MPS2=VCC, MPS1=GND, MSP0=VCC (0V to 5V, reset to 0V)
+ 6 - MPS2=VCC, MPS1=VCC, MSP0=GND (0V to 5V, reset to 2.5V)
+ 7 - MPS2=VCC, MPS1=VCC, MSP0=VCC (0V to 5V, reset to 0V, enables SoftSpan)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ default: 7
+
+ io-channels:
+ description:
+ ADC channel to monitor voltages and temperature at the MUXOUT pin.
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^channel@[0-3]$":
+ $ref: dac.yaml
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ description: The channel number representing the DAC output channel.
+ maximum: 3
+
+ adi,toggle-mode:
+ description:
+ Set the channel as a toggle enabled channel. Toggle operation enables
+ fast switching of a DAC output between two different DAC codes without
+ any SPI transaction.
+ type: boolean
+
+ output-range-microvolt:
+ description:
+ This property is only allowed when SoftSpan is enabled. If not present,
+ [0, 5000000] is the default output range.
+ oneOf:
+ - items:
+ - const: 0
+ - enum: [5000000, 10000000]
+ - items:
+ - const: -5000000
+ - const: 5000000
+ - items:
+ - const: -10000000
+ - const: 10000000
+ - items:
+ - const: -2500000
+ - const: 2500000
+
+ required:
+ - reg
+
+ allOf:
+ - if:
+ not:
+ properties:
+ adi,manual-span-operation-config:
+ const: 7
+ then:
+ patternProperties:
+ "^channel@[0-3]$":
+ properties:
+ output-range-microvolt: false
+
+required:
+ - compatible
+ - reg
+ - spi-max-frequency
+ - vcc-supply
+ - iovcc-supply
+ - v-pos-supply
+ - v-neg-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dac@0 {
+ compatible = "adi,ltc2664";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+
+ vcc-supply = <&vcc>;
+ iovcc-supply = <&vcc>;
+ ref-supply = <&vref>;
+ v-pos-supply = <&vpos>;
+ v-neg-supply = <&vneg>;
+
+ io-channels = <&adc 0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ adi,toggle-mode;
+ output-range-microvolt = <(-10000000) 10000000>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ output-range-microvolt = <0 10000000>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml
new file mode 100644
index 000000000000..3c8e5781e42c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2672.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ltc2672.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2672 DAC
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+ - Kim Seer Paller <kimseer.paller@analog.com>
+
+description: |
+ Analog Devices LTC2672 5 channel, 12-/16-Bit, 300mA DAC
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2672.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc2672
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 50000000
+
+ vcc-supply:
+ description: Analog Supply Voltage Input.
+
+ v-neg-supply:
+ description: Negative Supply Voltage Input.
+
+ vdd0-supply:
+ description: Positive Supply Voltage Input for DAC OUT0.
+
+ vdd1-supply:
+ description: Positive Supply Voltage Input for DAC OUT1.
+
+ vdd2-supply:
+ description: Positive Supply Voltage Input for DAC OUT2.
+
+ vdd3-supply:
+ description: Positive Supply Voltage Input for DAC OUT3.
+
+ vdd4-supply:
+ description: Positive Supply Voltage Input for DAC OUT4.
+
+ iovcc-supply:
+ description: Digital Input/Output Supply Voltage.
+
+ ref-supply:
+ description:
+ Reference Input/Output. The voltage at the REF pin sets the full-scale
+ range of all channels. If not provided the internal reference is used and
+ also provided on the VREF pin.
+
+ reset-gpios:
+ description:
+ Active Low Asynchronous Clear Input. A logic low at this level triggered
+ input clears the device to the default reset code and output range, which
+ is zero-scale with the outputs off. The control registers are cleared to
+ zero.
+ maxItems: 1
+
+ adi,rfsadj-ohms:
+ description:
+ If FSADJ is tied to VCC, an internal RFSADJ (20 kΩ) is selected, which
+ results in nominal output ranges. When an external resistor of 19 kΩ to
+ 41 kΩ can be used instead by connecting the resistor between FSADJ and GND
+ it controls the scaling of the ranges, and the internal resistor is
+ automatically disconnected.
+ minimum: 19000
+ maximum: 41000
+ default: 20000
+
+ io-channels:
+ description:
+ ADC channel to monitor voltages and currents at the MUX pin.
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^channel@[0-4]$":
+ $ref: dac.yaml
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ description: The channel number representing the DAC output channel.
+ maximum: 4
+
+ adi,toggle-mode:
+ description:
+ Set the channel as a toggle enabled channel. Toggle operation enables
+ fast switching of a DAC output between two different DAC codes without
+ any SPI transaction.
+ type: boolean
+
+ output-range-microamp:
+ items:
+ - const: 0
+ - enum: [3125000, 6250000, 12500000, 25000000, 50000000, 100000000,
+ 200000000, 300000000]
+
+ required:
+ - reg
+ - output-range-microamp
+
+required:
+ - compatible
+ - reg
+ - spi-max-frequency
+ - vcc-supply
+ - iovcc-supply
+ - v-neg-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dac@0 {
+ compatible = "adi,ltc2672";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+
+ vcc-supply = <&vcc>;
+ iovcc-supply = <&vcc>;
+ ref-supply = <&vref>;
+ v-neg-supply = <&vneg>;
+
+ io-channels = <&adc 0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ adi,toggle-mode;
+ output-range-microamp = <0 3125000>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ output-range-microamp = <0 6250000>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml
index 48f9e7d29423..f22ef710ecde 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml
@@ -48,6 +48,7 @@ properties:
patternProperties:
"^channel@([0-9]|1[0-5])$":
type: object
+ additionalProperties: false
properties:
reg:
@@ -115,32 +116,32 @@ examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
- ltc2688: ltc2688@0 {
- compatible = "adi,ltc2688";
- reg = <0>;
-
- vcc-supply = <&vcc>;
- iovcc-supply = <&vcc>;
- vref-supply = <&vref>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- channel@0 {
- reg = <0>;
- adi,toggle-mode;
- adi,overrange;
- };
-
- channel@1 {
- reg = <1>;
- adi,output-range-microvolt = <0 10000000>;
-
- clocks = <&clock_tgp3>;
- adi,toggle-dither-input = <2>;
- };
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ltc2688: ltc2688@0 {
+ compatible = "adi,ltc2688";
+ reg = <0>;
+
+ vcc-supply = <&vcc>;
+ iovcc-supply = <&vcc>;
+ vref-supply = <&vref>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ adi,toggle-mode;
+ adi,overrange;
+ };
+
+ channel@1 {
+ reg = <1>;
+ adi,output-range-microvolt = <0 10000000>;
+
+ clocks = <&clock_tgp3>;
+ adi,toggle-dither-input = <2>;
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/dac/dac.yaml b/Documentation/devicetree/bindings/iio/dac/dac.yaml
new file mode 100644
index 000000000000..daa40724e1cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/dac.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IIO Common Properties for DAC Channels
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description:
+ A few properties are defined in a common way for DAC channels.
+
+properties:
+ $nodename:
+ pattern: "^channel(@[0-9a-f]+)?$"
+ description:
+ A channel index should match reg.
+
+ reg:
+ maxItems: 1
+
+ label:
+ description: Unique name to identify which channel this is.
+
+ output-range-microamp:
+ maxItems: 2
+ minItems: 2
+ description:
+ Specify the channel output full scale range in microamperes.
+
+ output-range-microvolt:
+ maxItems: 2
+ minItems: 2
+ description:
+ Specify the channel output full scale range in microvolts.
+
+anyOf:
+ - oneOf:
+ - required:
+ - reg
+ - output-range-microamp
+ - required:
+ - reg
+ - output-range-microvolt
+ - required:
+ - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml b/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
index 133b0f867992..c9f51d00fa8f 100644
--- a/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Marcus Folkesson <marcus.folkesson@gmail.com>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/dac/lltc,ltc1660.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/dac/lltc,ltc1660.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Linear Technology Micropower octal 8-Bit and 10-Bit DACs
diff --git a/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml b/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml
index b1eb77335d05..733edc7d6d17 100644
--- a/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/lltc,ltc2632.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/dac/lltc,ltc2632.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/dac/lltc,ltc2632.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Linear Technology LTC263x 12-/10-/8-Bit Rail-to-Rail DAC
@@ -64,14 +64,14 @@ examples:
};
spi {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- dac@0 {
- compatible = "lltc,ltc2632-l12";
- reg = <0>; /* CS0 */
- spi-max-frequency = <1000000>;
- vref-supply = <&vref>;
- };
+ dac@0 {
+ compatible = "lltc,ltc2632-l12";
+ reg = <0>; /* CS0 */
+ spi-max-frequency = <1000000>;
+ vref-supply = <&vref>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml b/Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml
new file mode 100644
index 000000000000..24830f56c501
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/maxim,max5522.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/maxim,max5522.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX5522 Dual 10-bit Voltage-Output SPI DACs
+
+maintainers:
+ - Angelo Dureghello <angelo.dureghello@timesys.com>
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Datasheet available at:
+ https://www.analog.com/en/products/max5522.html
+
+properties:
+ compatible:
+ const: maxim,max5522
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vrefin-supply: true
+
+required:
+ - compatible
+ - reg
+ - vrefin-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "maxim,max5522";
+ reg = <0>;
+ vrefin-supply = <&vref>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml
new file mode 100644
index 000000000000..99831d7f1c16
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4728.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4728.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP4728 DAC
+
+maintainers:
+ - Andrea Collamati <andrea.collamati@gmail.com>
+
+description: |
+ MCP4728 is a quad channel, 12-bit voltage output
+ Digital-to-Analog Converter with non-volatile
+ memory and I2C compatible Serial Interface.
+ https://www.microchip.com/en-us/product/mcp4728
+
+properties:
+ compatible:
+ const: microchip,mcp4728
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: |
+ Provides both power and acts as the reference supply on the MCP4728
+ when Internal Vref is not selected.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@60 {
+ compatible = "microchip,mcp4728";
+ reg = <0x60>;
+ vdd-supply = <&vdac_vdd>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4821.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4821.yaml
new file mode 100644
index 000000000000..26011b5639d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4821.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4821.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP4821 and similar DACs
+
+description: |
+ Supports MCP48x1 (single channel) and MCP48x2 (dual channel) series of DACs.
+ Device supports simplex communication over SPI in Mode 0 and Mode 3.
+
+ +---------+--------------+-------------+
+ | Device | Resolution | Channels |
+ |---------|--------------|-------------|
+ | MCP4801 | 8-bit | 1 |
+ | MCP4802 | 8-bit | 2 |
+ | MCP4811 | 10-bit | 1 |
+ | MCP4812 | 10-bit | 2 |
+ | MCP4821 | 12-bit | 1 |
+ | MCP4822 | 12-bit | 2 |
+ +---------+--------------+-------------+
+
+ Datasheet:
+ MCP48x1: https://ww1.microchip.com/downloads/en/DeviceDoc/22244B.pdf
+ MCP48x2: https://ww1.microchip.com/downloads/en/DeviceDoc/20002249B.pdf
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp4801
+ - microchip,mcp4802
+ - microchip,mcp4811
+ - microchip,mcp4812
+ - microchip,mcp4821
+ - microchip,mcp4822
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ ldac-gpios:
+ description: |
+ Active Low LDAC (Latch DAC Input) pin used to update the DAC output.
+ maxItems: 1
+
+ powerdown-gpios:
+ description: |
+ Active Low SHDN pin used to enter the shutdown mode.
+ maxItems: 1
+
+ spi-cpha: true
+ spi-cpol: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "microchip,mcp4821";
+ reg = <0>;
+ vdd-supply = <&vdd_regulator>;
+ ldac-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+ spi-cpha;
+ spi-cpol;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml
index 4c430abcdbf9..19374401e509 100644
--- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml
@@ -21,17 +21,18 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
vref-supply: true
-additionalProperties: false
-
required:
- compatible
- reg
- vref-supply
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml b/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml
index 595f481c548e..9c8afe3f1b69 100644
--- a/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/nxp,lpc1850-dac.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/dac/nxp,lpc1850-dac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP LPC1850 DAC bindings
+title: NXP LPC1850 DAC
maintainers:
- Jonathan Cameron <jic23@kernel.org>
diff --git a/Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml b/Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml
new file mode 100644
index 000000000000..c00fa50e42e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/rohm,bd79703.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2024 ROHM Semiconductor.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/rohm,bd79703.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD79700, BD79701, BD79702 and BD79703 DACs
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ The ROHM BD7970[0,1,2,3] are 8-bit DACs. The BD79700 has 2 channels,
+ BD79701 3 channels, BD79702 4 channels and BD79703 has 6 channels.
+ Datasheets for BD79702 and BD79703 can be found from
+ https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bd79702fv-lb_bd79703fv-lb-e.pdf
+ and for the BD79700 and the BD79701 from
+ https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bd79700fvm-lb_bd79701fvm-lb-e.pdf
+
+properties:
+ compatible:
+ enum:
+ - rohm,bd79700
+ - rohm,bd79701
+ - rohm,bd79702
+ - rohm,bd79703
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 30000000
+
+ vfs-supply:
+ description:
+ The regulator to use as a full scale voltage. The voltage should be
+ between 2.7V .. VCC. Not present on BD79700 and BD79701.
+
+ vcc-supply:
+ description:
+ The regulator supplying the operating voltage. Should be between
+ 2.7V ... 5.5V. Is used also as a Vfs on BD79700 and BD79701.
+
+required:
+ - compatible
+ - reg
+ - spi-max-frequency
+ - vcc-supply
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rohm,bd79702
+ - rohm,bd79703
+then:
+ required:
+ - vfs-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "rohm,bd79703";
+ reg = <0>;
+ spi-max-frequency = <30000000>;
+ vcc-supply = <&vcc>;
+ vfs-supply = <&vref>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
index 6adeda4087fc..b15de4eb209c 100644
--- a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/dac/st,stm32-dac.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/dac/st,stm32-dac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 DAC bindings
+title: STMicroelectronics STM32 DAC
description: |
The STM32 DAC is a 12-bit voltage output digital-to-analog converter. The DAC
@@ -45,6 +45,10 @@ properties:
'#size-cells':
const: 0
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml
index b0157050f1ee..201b04af2b22 100644
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml
@@ -33,21 +33,22 @@ properties:
vref-supply:
description: Needed to provide output scaling.
- spi-max-frequency: true
-
required:
- compatible
- reg
- vref-supply
-additionalProperties: false
-
oneOf:
- required:
- spi-cpha
- required:
- spi-cpol
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
vref_2v5_reg: regulator-vref {
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
index 88298bc43b81..e59db861e2eb 100644
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
@@ -21,6 +21,7 @@ properties:
- ti,dac5573
- ti,dac6573
- ti,dac7573
+ - ti,dac081c081
- ti,dac121c081
reg:
@@ -46,7 +47,7 @@ examples:
dac@4c {
compatible = "ti,dac5571";
- reg = <0x4C>;
+ reg = <0x4c>;
vref-supply = <&vdd_supply>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml
index 10be98d1f19c..a6814587dbc4 100644
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7311.yaml
@@ -24,14 +24,15 @@ properties:
Reference voltage must be supplied to establish the scaling of the
output voltage.
- spi-max-frequency: true
-
required:
- compatible
- reg
- vref-supply
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
index d172b142f6ed..20dd1370660d 100644
--- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
@@ -29,13 +29,14 @@ properties:
DACs are loaded when the pin connected to this GPIO is pulled low.
maxItems: 1
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml b/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml
index b77e855bd594..ff0cb553e871 100644
--- a/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml
+++ b/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml
@@ -44,6 +44,24 @@ properties:
'#clock-cells':
const: 0
+ adi,lpf-margin-mhz:
+ description:
+ Sets the minimum distance between the fundamental frequency of `rf_in`
+ and the corner frequency of the low-pass, output filter when operated in
+ 'auto' mode. The selected low-pass corner frequency will be greater than,
+ or equal to, `rf_in` + `lpf-margin-hz`. If not setting is found that
+ satisfies this relationship the filter will be put into 'bypass'.
+ default: 0
+
+ adi,hpf-margin-mhz:
+ description:
+ Sets the minimum distance between the fundamental frequency of `rf_in`
+ and the corner frequency of the high-pass, input filter when operated in
+ 'auto' mode. The selected high-pass corner frequency will be less than,
+ or equal to, `rf_in` - `hpf-margin-hz`. If not setting is found that
+ satisfies this relationship the filter will be put into 'bypass'.
+ default: 0
+
required:
- compatible
- reg
@@ -61,6 +79,8 @@ examples:
spi-max-frequency = <10000000>;
clocks = <&admv8818_rfin>;
clock-names = "rf_in";
+ adi,lpf-margin-mhz = <300>;
+ adi,hpf-margin-mhz = <300>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml b/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
index 6b3a611e1cf1..2e1ff77fd1de 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADF4371/ADF4372 Wideband Synthesizers
maintainers:
- - Popa Stefan <stefan.popa@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description: |
Analog Devices ADF4371/ADF4372 SPI Wideband Synthesizers
@@ -30,8 +31,9 @@ properties:
clock-names:
description:
- Must be "clkin"
- maxItems: 1
+ Must be "clkin" if the input reference is single ended or "clkin-diff"
+ if the input reference is differential.
+ enum: [clkin, clkin-diff]
adi,mute-till-lock-en:
type: boolean
@@ -40,28 +42,29 @@ properties:
output stage will shut down until the ADF4371/ADF4372 achieves lock as
measured by the digital lock detect circuitry.
- spi-max-frequency: true
-
required:
- compatible
- reg
- clocks
- clock-names
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
frequency@0 {
- compatible = "adi,adf4371";
- reg = <0>;
- spi-max-frequency = <1000000>;
- clocks = <&adf4371_clkin>;
- clock-names = "clkin";
+ compatible = "adi,adf4371";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ clocks = <&adf4371_clkin>;
+ clock-names = "clkin";
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml
index d7f20b8518e0..d1d1311332f8 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,adf4350.yaml
@@ -28,6 +28,12 @@ properties:
clock-names:
const: clkin
+ '#clock-cells':
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
gpios:
maxItems: 1
description: Lock detect GPIO.
@@ -160,13 +166,16 @@ properties:
2: +2dBm
3: +5dBm
-additionalProperties: false
-
required:
- compatible
- reg
- clocks
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml
new file mode 100644
index 000000000000..5f950ee9aec7
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/frequency/adi,adf4377.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADF4377 Microwave Wideband Synthesizer with Integrated VCO
+
+maintainers:
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+ - Dragos Bogdan <dragos.bogdan@analog.com>
+
+description: |
+ The ADF4377 is a high performance, ultralow jitter, dual output integer-N
+ phased locked loop (PLL) with integrated voltage controlled oscillator (VCO)
+ ideally suited for data converter and mixed signal front end (MxFE) clock
+ applications.
+
+ https://www.analog.com/en/products/adf4377.html
+ https://www.analog.com/en/products/adf4378.html
+
+properties:
+ compatible:
+ enum:
+ - adi,adf4377
+ - adi,adf4378
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 10000000
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description:
+ External clock that provides reference input frequency.
+ items:
+ - const: ref_in
+
+ chip-enable-gpios:
+ description:
+ GPIO that controls the Chip Enable Pin.
+ maxItems: 1
+
+ clk1-enable-gpios:
+ description:
+ GPIO that controls the Enable Clock 1 Output Buffer Pin.
+ maxItems: 1
+
+ clk2-enable-gpios:
+ description:
+ GPIO that controls the Enable Clock 2 Output Buffer Pin.
+ maxItems: 1
+
+ adi,muxout-select:
+ description:
+ On chip multiplexer output selection.
+ high_z - MUXOUT Pin set to high-Z.
+ lock_detect - MUXOUT Pin set to lock detector output.
+ muxout_low - MUXOUT Pin set to low.
+ f_div_rclk_2 - MUXOUT Pin set to fDIV_RCLK/2.
+ f_div_nclk_2 - MUXOUT Pin set to fDIV_NCLK/2.
+ muxout_high - MUXOUT Pin set to high.
+ enum: [high_z, lock_detect, muxout_low, f_div_rclk_2, f_div_nclk_2, muxout_high]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,adf4378
+ then:
+ properties:
+ clk2-enable-gpios: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ frequency@0 {
+ compatible = "adi,adf4377";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ clocks = <&adf4377_ref_in>;
+ clock-names = "ref_in";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml
new file mode 100644
index 000000000000..2bcf4bbc12e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2024 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/frequency/adi,admfm2000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADMFM2000 Dual Microwave Down Converter
+
+maintainers:
+ - Kim Seer Paller <kimseer.paller@analog.com>
+
+description:
+ Dual microwave down converter module with input RF and LO frequency ranges
+ from 0.5 to 32 GHz and an output IF frequency range from 0.1 to 8 GHz.
+ It consists of a LNA, mixer, IF filter, DSA, and IF amplifier for each down
+ conversion path.
+
+properties:
+ compatible:
+ enum:
+ - adi,admfm2000
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^channel@[0-1]$":
+ type: object
+ description: Represents a channel of the device.
+
+ additionalProperties: false
+
+ properties:
+ reg:
+ description:
+ The channel number.
+ minimum: 0
+ maximum: 1
+
+ adi,mixer-mode:
+ description:
+ Enable mixer mode for the channel. It downconverts RF between 5 GHz
+ and 32 GHz to IF between 0.5 GHz and 8 GHz. If not present, the channel
+ is in direct IF mode which bypasses the mixer and downconverts RF
+ between 2 GHz and 8 GHz to IF between 0.5 GHz and 8 GHz.
+ type: boolean
+
+ switch-gpios:
+ description: |
+ GPIOs to select the RF path for the channel. The same state of CTRL-A
+ and CTRL-B GPIOs is not permitted.
+ CTRL-A CTRL-B CH1 Status CH2 Status
+ 1 0 Direct IF mode Mixer mode
+ 0 1 Mixer mode Direct IF mode
+
+ items:
+ - description: CTRL-A GPIO
+ - description: CTRL-B GPIO
+
+ attenuation-gpios:
+ description: |
+ Choice of attenuation:
+ DSA-V4 DSA-V3 DSA-V2 DSA-V1 DSA-V0
+ 1 1 1 1 1 0 dB
+ 1 1 1 1 0 -1 dB
+ 1 1 1 0 1 -2 dB
+ 1 1 0 1 1 -4 dB
+ 1 0 1 1 1 -8 dB
+ 0 1 1 1 1 -16 dB
+ 0 0 0 0 0 -31 dB
+
+ items:
+ - description: DSA-V0 GPIO
+ - description: DSA-V1 GPIO
+ - description: DSA-V2 GPIO
+ - description: DSA-V3 GPIO
+ - description: DSA-V4 GPIO
+
+ required:
+ - reg
+ - switch-gpios
+ - attenuation-gpios
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ converter {
+ compatible = "adi,admfm2000";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ switch-gpios = <&gpio 1 GPIO_ACTIVE_LOW>,
+ <&gpio 2 GPIO_ACTIVE_HIGH>;
+
+ attenuation-gpios = <&gpio 17 GPIO_ACTIVE_LOW>,
+ <&gpio 22 GPIO_ACTIVE_LOW>,
+ <&gpio 23 GPIO_ACTIVE_LOW>,
+ <&gpio 24 GPIO_ACTIVE_LOW>,
+ <&gpio 25 GPIO_ACTIVE_LOW>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ adi,mixer-mode;
+ switch-gpios = <&gpio 3 GPIO_ACTIVE_LOW>,
+ <&gpio 4 GPIO_ACTIVE_HIGH>;
+
+ attenuation-gpios = <&gpio 0 GPIO_ACTIVE_LOW>,
+ <&gpio 5 GPIO_ACTIVE_LOW>,
+ <&gpio 6 GPIO_ACTIVE_LOW>,
+ <&gpio 16 GPIO_ACTIVE_LOW>,
+ <&gpio 26 GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
index 23f1f3b55abb..f2eb2287ed9e 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
@@ -39,6 +39,46 @@ properties:
description:
Analog voltage regulator.
+ vcc-drv-supply:
+ description:
+ RF Driver voltage regulator.
+
+ vcc2-drv-supply:
+ description:
+ RF predriver voltage regulator.
+
+ vcc-vva-supply:
+ description:
+ VVA Control Circuit voltage regulator.
+
+ vcc-amp1-supply:
+ description:
+ RF Amplifier 1 voltage regulator.
+
+ vcc-amp2-supply:
+ description:
+ RF Amplifier 2 voltage regulator.
+
+ vcc-env-supply:
+ description:
+ Envelope Detector voltage regulator.
+
+ vcc-bg-supply:
+ description:
+ Mixer Chip Band Gap Circuit voltage regulator.
+
+ vcc-bg2-supply:
+ description:
+ VGA Chip Band Gap Circuit voltage regulator.
+
+ vcc-mixer-supply:
+ description:
+ Mixer voltage regulator.
+
+ vcc-quad-supply:
+ description:
+ Quadruppler voltage regulator.
+
adi,detector-enable:
description:
Enable the Envelope Detector available at output pins VENV_P and
@@ -69,8 +109,21 @@ required:
- clocks
- clock-names
- vcm-supply
-
-additionalProperties: false
+ - vcc-drv-supply
+ - vcc2-drv-supply
+ - vcc-vva-supply
+ - vcc-amp1-supply
+ - vcc-amp2-supply
+ - vcc-env-supply
+ - vcc-bg-supply
+ - vcc-bg2-supply
+ - vcc-mixer-supply
+ - vcc-quad-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -84,6 +137,16 @@ examples:
clocks = <&admv1013_lo>;
clock-names = "lo_in";
vcm-supply = <&vcm>;
+ vcc-drv-supply = <&vcc_drv>;
+ vcc2-drv-supply = <&vcc2_drv>;
+ vcc-vva-supply = <&vcc_vva>;
+ vcc-amp1-supply = <&vcc_amp1>;
+ vcc-amp2-supply = <&vcc_amp2>;
+ vcc-env-supply = <&vcc_env>;
+ vcc-bg-supply = <&vcc_bg>;
+ vcc-bg2-supply = <&vcc_bg2>;
+ vcc-mixer-supply = <&vcc_mixer>;
+ vcc-quad-supply = <&vcc_quad>;
adi,quad-se-mode = "diff";
adi,detector-enable;
};
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
index 2716c1e8fe31..39cc63a11762 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
@@ -33,7 +33,7 @@ properties:
items:
- const: lo_in
description:
- External clock that provides the Local Oscilator input.
+ External clock that provides the Local Oscillator input.
vcm-supply:
description:
@@ -103,8 +103,19 @@ required:
- clocks
- clock-names
- vcm-supply
-
-additionalProperties: false
+ - vcc-if-bb-supply
+ - vcc-vga-supply
+ - vcc-vva-supply
+ - vcc-lna-3p3-supply
+ - vcc-lna-1p5-supply
+ - vcc-bg-supply
+ - vcc-quad-supply
+ - vcc-mixer-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml
index da7fe85ec92e..ca40359a3944 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADMV4420 K Band Downconverter
maintainers:
- - Cristian Pop <cristian.pop@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
description:
The ADMV4420 is a highly integrated, double balanced, active
@@ -37,7 +37,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml
index 3a8ea93f4e0c..f11391ab4b62 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,adrf6780.yaml
@@ -113,7 +113,10 @@ required:
- clocks
- clock-names
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml b/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml
index 662ec59ca0af..3d94dd4612c4 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/adi,adxrs290.yaml
@@ -38,7 +38,10 @@ required:
- spi-cpol
- spi-cpha
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -47,13 +50,13 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
gyro@0 {
- compatible = "adi,adxrs290";
- reg = <0>;
- spi-max-frequency = <5000000>;
- spi-cpol;
- spi-cpha;
- interrupt-parent = <&gpio>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ compatible = "adi,adxrs290";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ spi-cpol;
+ spi-cpha;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
index 1414ba9977c1..3c6fe74af0b8 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
@@ -22,6 +22,9 @@ properties:
vdd-supply: true
vddio-supply: true
+ spi-max-frequency:
+ maximum: 10000000
+
interrupts:
minItems: 1
maxItems: 2
@@ -33,7 +36,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/invensense,itg3200.yaml b/Documentation/devicetree/bindings/iio/gyroscope/invensense,itg3200.yaml
new file mode 100644
index 000000000000..4d8abf8ac2c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyroscope/invensense,itg3200.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/gyroscope/invensense,itg3200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Invensense ITG-3200 Gyroscope
+
+maintainers:
+ - Jonathan Cameron <jic23@kernel.org>
+
+description: |
+ Triple-axis, digital output gyroscope with a three 16-bit analog-to-digital
+ converters (ADCs) for digitizing the gyro outputs, a user-selectable internal
+ low-pass filter bandwidth, and a Fast-Mode I2C.
+
+properties:
+ compatible:
+ const: invensense,itg3200
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ vlogic-supply: true
+
+ interrupts:
+ maxItems: 1
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ext_clock
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gyroscope@68 {
+ compatible = "invensense,itg3200";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml b/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml
index d1a6103fc37a..f3242dc0e7e6 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml
@@ -21,7 +21,7 @@ properties:
vlogic-supply: true
interrupts:
- minItems: 1
+ maxItems: 1
description:
Interrupt mapping for the trigger interrupt from the internal oscillator.
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
index 3f57a1b813e6..297d519d68f2 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml
@@ -56,40 +56,43 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
gyroscope@20 {
- compatible = "nxp,fxas21002c";
- reg = <0x20>;
+ compatible = "nxp,fxas21002c";
+ reg = <0x20>;
- vdd-supply = <&reg_peri_3p15v>;
- vddio-supply = <&reg_peri_3p15v>;
+ vdd-supply = <&reg_peri_3p15v>;
+ vddio-supply = <&reg_peri_3p15v>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT1";
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
};
};
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
gyroscope@0 {
- compatible = "nxp,fxas21002c";
- reg = <0x0>;
+ compatible = "nxp,fxas21002c";
+ reg = <0x0>;
- spi-max-frequency = <2000000>;
+ spi-max-frequency = <2000000>;
- interrupt-parent = <&gpio2>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT2";
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml b/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml
index 967778fb0ce8..d4753c85ecc3 100644
--- a/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml
+++ b/Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml
@@ -27,6 +27,14 @@ properties:
LED current whilst the engine is running. First indexed value is
the configuration for the RED LED, and second value is for the IR LED.
+ maxim,pulse-width-us:
+ description: |
+ LED pulse width in microseconds. Appropriate pulse width depends on
+ factors such as optical window absorption, LED-to-sensor distance,
+ and expected reflectivity of the skin or contact surface.
+ enum: [200, 400, 800, 1600]
+ default: 1600
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
index c13c10c8d65d..205d352ab467 100644
--- a/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
+++ b/Documentation/devicetree/bindings/iio/health/maxim,max30102.yaml
@@ -4,16 +4,20 @@
$id: http://devicetree.org/schemas/iio/health/maxim,max30102.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Maxim MAX30102 heart rate and pulse oximeter and MAX30105 particle-sensor
+title: Maxim MAX30101/2 heart rate and pulse oximeter and MAX30105 particle-sensor
maintainers:
- Matt Ranostay <matt.ranostay@konsulko.com>
properties:
compatible:
- enum:
- - maxim,max30102
- - maxim,max30105
+ oneOf:
+ - enum:
+ - maxim,max30102
+ - maxim,max30105
+ - items:
+ - const: maxim,max30101
+ - const: maxim,max30105
reg:
maxItems: 1
@@ -42,7 +46,7 @@ allOf:
properties:
compatible:
contains:
- const: maxim,max30100
+ const: maxim,max30102
then:
properties:
maxim,green-led-current-microamp: false
diff --git a/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml b/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
index d861526c5c42..5b6cde86b5a5 100644
--- a/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
+++ b/Documentation/devicetree/bindings/iio/health/ti,afe4403.yaml
@@ -23,16 +23,18 @@ properties:
maxItems: 1
description: Connected to ADC_RDY pin.
- reset-gpios: true
-
- spi-max-frequency: true
-
-additionalProperties: false
+ reset-gpios:
+ maxItems: 1
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/gpio/gpio.h>
@@ -41,7 +43,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- heart_mon@0 {
+ heart-mon@0 {
compatible = "ti,afe4403";
reg = <0>;
spi-max-frequency = <10000000>;
diff --git a/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml b/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
index c0e815d9999e..167d10bd60af 100644
--- a/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
+++ b/Documentation/devicetree/bindings/iio/health/ti,afe4404.yaml
@@ -23,7 +23,8 @@ properties:
maxItems: 1
description: Connected to ADC_RDY pin.
- reset-gpios: true
+ reset-gpios:
+ maxItems: 1
additionalProperties: false
@@ -39,7 +40,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- heart_mon@58 {
+ heart-mon@58 {
compatible = "ti,afe4404";
reg = <0x58>;
tx-supply = <&vbat>;
diff --git a/Documentation/devicetree/bindings/iio/humidity/dht11.yaml b/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
index 2247481d0203..0103f4238942 100644
--- a/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
+++ b/Documentation/devicetree/bindings/iio/humidity/dht11.yaml
@@ -34,7 +34,7 @@ additionalProperties: false
examples:
- |
- humidity_sensor {
+ humidity-sensor {
compatible = "dht11";
gpios = <&gpio0 6 0>;
};
diff --git a/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml b/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml
new file mode 100644
index 000000000000..1e25cf781cf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/humidity/sciosense,ens210.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ScioSense ENS210 temperature and humidity sensor
+
+maintainers:
+ - Joshua Felmeden <jfelmeden@thegoodpenguin.co.uk>
+
+description: |
+ Temperature and Humidity sensor.
+
+ Datasheet:
+ https://www.sciosense.com/wp-content/uploads/2024/04/ENS21x-Datasheet.pdf
+ https://www.sciosense.com/wp-content/uploads/2023/12/ENS210-Datasheet.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sciosense,ens210a
+ - sciosense,ens211
+ - sciosense,ens212
+ - sciosense,ens213a
+ - sciosense,ens215
+ - const: sciosense,ens210
+ - const: sciosense,ens210
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@43 {
+ compatible = "sciosense,ens210";
+ reg = <0x43>;
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
index 88384b69f917..e3eca8917517 100644
--- a/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
+++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
@@ -10,7 +10,7 @@ maintainers:
- Eugene Zaikonnikov <ez@norophonic.com>
description: |
- Relative humidity and tempereature sensors on I2C bus
+ Relative humidity and temperature sensors on I2C bus
Datasheets are available at:
http://www.ti.com/product/HDC2010/datasheet
@@ -27,6 +27,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -35,12 +38,12 @@ additionalProperties: false
examples:
- |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- humidity@40 {
- compatible = "ti,hdc2010";
- reg = <0x40>;
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ humidity@40 {
+ compatible = "ti,hdc2010";
+ reg = <0x40>;
+ };
};
diff --git a/Documentation/devicetree/bindings/iio/humidity/ti,hdc3020.yaml b/Documentation/devicetree/bindings/iio/humidity/ti,hdc3020.yaml
new file mode 100644
index 000000000000..b375d307513f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/humidity/ti,hdc3020.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/humidity/ti,hdc3020.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HDC3020/HDC3021/HDC3022 humidity and temperature iio sensors
+
+maintainers:
+ - Li peiyu <579lpy@gmail.com>
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description:
+ https://www.ti.com/lit/ds/symlink/hdc3020.pdf
+
+ The HDC302x is an integrated capacitive based relative humidity (RH)
+ and temperature sensor.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,hdc3021
+ - ti,hdc3022
+ - const: ti,hdc3020
+ - const: ti,hdc3020
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ humidity-sensor@47 {
+ compatible = "ti,hdc3021", "ti,hdc3020";
+ reg = <0x47>;
+ vdd-supply = <&vcc_3v3>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <23 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio3 27 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
index 340be256f283..3a725ece7ec4 100644
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml
@@ -25,7 +25,9 @@ properties:
spi-cpol: true
- spi-max-frequency: true
+ spi-cs-inactive-delay-ns:
+ minimum: 16000
+ default: 16000
interrupts:
maxItems: 1
@@ -35,13 +37,15 @@ required:
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
index a7574210175a..9d185f7bfdcb 100644
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml
@@ -30,12 +30,19 @@ properties:
- adi,adis16467-2
- adi,adis16467-3
- adi,adis16500
+ - adi,adis16501
- adi,adis16505-1
- adi,adis16505-2
- adi,adis16505-3
- adi,adis16507-1
- adi,adis16507-2
- adi,adis16507-3
+ - adi,adis16575-2
+ - adi,adis16575-3
+ - adi,adis16576-2
+ - adi,adis16576-3
+ - adi,adis16577-2
+ - adi,adis16577-3
reg:
maxItems: 1
@@ -47,6 +54,10 @@ properties:
spi-max-frequency:
maximum: 2000000
+ spi-cs-inactive-delay-ns:
+ minimum: 16000
+ default: 16000
+
interrupts:
maxItems: 1
@@ -79,18 +90,26 @@ required:
- spi-cpol
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
contains:
enum:
- adi,adis16500
+ - adi,adis16501
- adi,adis16505-1
- adi,adis16505-2
- adi,adis16505-3
- adi,adis16507-1
- adi,adis16507-2
- adi,adis16507-3
+ - adi,adis16575-2
+ - adi,adis16575-3
+ - adi,adis16576-2
+ - adi,adis16576-3
+ - adi,adis16577-2
+ - adi,adis16577-3
then:
properties:
@@ -107,23 +126,40 @@ allOf:
dependencies:
adi,sync-mode: [ clocks ]
-additionalProperties: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,adis16575-2
+ - adi,adis16575-3
+ - adi,adis16576-2
+ - adi,adis16576-3
+ - adi,adis16577-2
+ - adi,adis16577-3
+
+ then:
+ properties:
+ spi-max-frequency:
+ maximum: 15000000
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
spi {
- #address-cells = <1>;
- #size-cells = <0>;
-
- adis16475: adis16475-3@0 {
- compatible = "adi,adis16475-3";
- reg = <0>;
- spi-cpha;
- spi-cpol;
- spi-max-frequency = <2000000>;
- interrupts = <4 IRQ_TYPE_EDGE_RISING>;
- interrupt-parent = <&gpio>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adis16475: adis16475-3@0 {
+ compatible = "adi,adis16475-3";
+ reg = <0>;
+ spi-cpha;
+ spi-cpol;
+ spi-max-frequency = <2000000>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ interrupt-parent = <&gpio>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml
index dd29dc6c4c19..43ecf46e9c20 100644
--- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.yaml
@@ -7,22 +7,35 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADIS16480 and similar IMUs
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
properties:
compatible:
- enum:
- - adi,adis16375
- - adi,adis16480
- - adi,adis16485
- - adi,adis16488
- - adi,adis16490
- - adi,adis16495-1
- - adi,adis16495-2
- - adi,adis16495-3
- - adi,adis16497-1
- - adi,adis16497-2
- - adi,adis16497-3
+ oneOf:
+ - enum:
+ - adi,adis16375
+ - adi,adis16480
+ - adi,adis16485
+ - adi,adis16486
+ - adi,adis16488
+ - adi,adis16489
+ - adi,adis16490
+ - adi,adis16495-1
+ - adi,adis16495-2
+ - adi,adis16495-3
+ - adi,adis16497-1
+ - adi,adis16497-2
+ - adi,adis16497-3
+ - adi,adis16545-1
+ - adi,adis16545-2
+ - adi,adis16545-3
+ - adi,adis16547-1
+ - adi,adis16547-2
+ - adi,adis16547-3
+ - items:
+ - const: adi,adis16487
+ - const: adi,adis16485
reg:
maxItems: 1
@@ -47,8 +60,6 @@ properties:
- DIO3
- DIO4
- spi-max-frequency: true
-
spi-cpha: true
spi-cpol: true
@@ -96,8 +107,6 @@ properties:
- DIO3
- DIO4
-additionalProperties: false
-
required:
- compatible
- reg
@@ -106,6 +115,11 @@ required:
- spi-cpol
- spi-max-frequency
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml
new file mode 100644
index 000000000000..cf5324de4fd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/adi,adis16550.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADIS16550 and similar IMUs
+
+maintainers:
+ - Nuno Sa <nuno.sa@analog.com>
+ - Ramona Gradinariu <ramona.gradinariu@analog.com>
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+ - Robert Budai <robert.budai@analog.com>
+
+properties:
+ compatible:
+ enum:
+ - adi,adis16550
+
+ reg:
+ maxItems: 1
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ spi-max-frequency:
+ maximum: 15000000
+
+ vdd-supply: true
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Active low RESET pin.
+ maxItems: 1
+
+ clocks:
+ description: If not provided, then the internal clock is used.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - spi-cpha
+ - spi-cpol
+ - spi-max-frequency
+ - vdd-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ imu@0 {
+ compatible = "adi,adis16550";
+ reg = <0>;
+ spi-max-frequency = <15000000>;
+ spi-cpol;
+ spi-cpha;
+ vdd-supply = <&vdd>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
index 6e73cd889b5c..2cf8a0c7eb4c 100644
--- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
@@ -16,7 +16,11 @@ description: |
properties:
compatible:
- const: bosch,bmi160
+ oneOf:
+ - const: bosch,bmi160
+ - items:
+ - const: bosch,bmi120
+ - const: bosch,bmi160
reg:
maxItems: 1
@@ -33,6 +37,7 @@ properties:
to "INT2" if INT2 pin should be used instead
drive-open-drain:
+ type: boolean
description: |
set if the specified interrupt pin should be configured as
open drain. If not set, defaults to push-pull.
@@ -46,13 +51,14 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -63,16 +69,16 @@ examples:
#size-cells = <0>;
bmi160@68 {
- compatible = "bosch,bmi160";
- reg = <0x68>;
- vdd-supply = <&pm8916_l17>;
- vddio-supply = <&pm8916_l6>;
- interrupt-parent = <&gpio4>;
- interrupts = <12 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT1";
- mount-matrix = "0", "1", "0",
- "-1", "0", "0",
- "0", "0", "1";
+ compatible = "bosch,bmi160";
+ reg = <0x68>;
+ vdd-supply = <&pm8916_l17>;
+ vddio-supply = <&pm8916_l6>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ mount-matrix = "0", "1", "0",
+ "-1", "0", "0",
+ "0", "0", "1";
};
};
- |
@@ -83,11 +89,11 @@ examples:
#size-cells = <0>;
bmi160@0 {
- compatible = "bosch,bmi160";
- reg = <0>;
- spi-max-frequency = <10000000>;
- interrupt-parent = <&gpio2>;
- interrupts = <12 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT2";
+ compatible = "bosch,bmi160";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml
new file mode 100644
index 000000000000..860a6c1fea3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi270.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/bosch,bmi270.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMI270 6-Axis IMU
+
+maintainers:
+ - Alex Lanzano <lanzano.alex@gmail.com>
+
+description: |
+ BMI270 is a 6-axis inertial measurement unit that can measure acceleration and
+ angular velocity. The sensor also supports configurable interrupt events such
+ as motion, step counter, and wrist motion gestures. The sensor can communicate
+ I2C or SPI.
+ https://www.bosch-sensortec.com/products/motion-sensors/imus/bmi270/
+
+properties:
+ compatible:
+ enum:
+ - bosch,bmi260
+ - bosch,bmi270
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - INT1
+ - INT2
+
+ drive-open-drain:
+ type: boolean
+ description:
+ set if the specified interrupt pins should be configured as
+ open drain. If not set, defaults to push-pull.
+
+ mount-matrix:
+ description:
+ an optional 3x3 mounting rotation matrix.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@68 {
+ compatible = "bosch,bmi270";
+ reg = <0x68>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml
new file mode 100644
index 000000000000..7bf8294a8f2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi323.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/bosch,bmi323.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BMI323 6-Axis IMU
+
+maintainers:
+ - Jagath Jog J <jagathjog1996@gmail.com>
+
+description:
+ BMI323 is a 6-axis inertial measurement unit that supports acceleration and
+ gyroscopic measurements with hardware fifo buffering. Sensor also provides
+ events information such as motion, steps, orientation, single and double
+ tap detection.
+
+properties:
+ compatible:
+ const: bosch,bmi323
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - INT1
+ - INT2
+
+ drive-open-drain:
+ type: boolean
+ description:
+ set if the specified interrupt pin should be configured as
+ open drain. If not set, defaults to push-pull.
+
+ mount-matrix:
+ description:
+ an optional 3x3 mounting rotation matrix.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example for I2C
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@68 {
+ compatible = "bosch,bmi323";
+ reg = <0x68>;
+ vddio-supply = <&vddio>;
+ vdd-supply = <&vdd>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bno055.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bno055.yaml
new file mode 100644
index 000000000000..e0d06db161a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,bno055.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/bosch,bno055.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch BNO055
+
+maintainers:
+ - Andrea Merello <andrea.merello@iit.it>
+
+description: |
+ Inertial Measurement Unit with Accelerometer, Gyroscope, Magnetometer and
+ internal MCU for sensor fusion
+ https://www.bosch-sensortec.com/products/smart-sensors/bno055/
+
+properties:
+ compatible:
+ enum:
+ - bosch,bno055
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ serial {
+ imu {
+ compatible = "bosch,bno055";
+ reset-gpios = <&gpio0 54 GPIO_ACTIVE_LOW>;
+ clocks = <&imu_clk>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@28 {
+ compatible = "bosch,bno055";
+ reg = <0x28>;
+ reset-gpios = <&gpio0 54 GPIO_ACTIVE_LOW>;
+ clocks = <&imu_clk>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,smi240.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,smi240.yaml
new file mode 100644
index 000000000000..58f1411728f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,smi240.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/bosch,smi240.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch smi240 imu
+
+maintainers:
+ - Jianping Shen <Jianping.Shen@de.bosch.com>
+
+description:
+ Inertial Measurement Unit with Accelerometer and Gyroscope
+ with a measurement range of +/-300°/s and up to 16g.
+ https://www.bosch-semiconductors.com/mems-sensors/highly-automated-driving/smi240/
+
+properties:
+ compatible:
+ const: bosch,smi240
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@0 {
+ compatible = "bosch,smi240";
+ reg = <0>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
+ spi-max-frequency = <10000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,smi330.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,smi330.yaml
new file mode 100644
index 000000000000..0270ca456d2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/bosch,smi330.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/bosch,smi330.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bosch SMI330 6-Axis IMU
+
+maintainers:
+ - Stefan Gutmann <stefam.gutmann@de.bosch.com>
+
+description:
+ SMI330 is a 6-axis inertial measurement unit that supports acceleration and
+ gyroscopic measurements with hardware fifo buffering. Sensor also provides
+ events information such as motion, no-motion and tilt detection.
+
+properties:
+ compatible:
+ const: bosch,smi330
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: provide VDD power to the sensor.
+
+ vddio-supply:
+ description: provide VDD IO power to the sensor.
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - INT1
+ - INT2
+
+ drive-open-drain:
+ type: boolean
+ description:
+ set if the interrupt pin(s) should be configured as
+ open drain. If not set, defaults to push-pull.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example for I2C
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@68 {
+ compatible = "bosch,smi330";
+ reg = <0x68>;
+ vddio-supply = <&vddio>;
+ vdd-supply = <&vdd>;
+ interrupt-parent = <&gpio>;
+ interrupts = <26 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ };
+ };
+
+ // Example for SPI
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@0 {
+ compatible = "bosch,smi330";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <26 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
index 4c1c083d0e92..119e28a833fd 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: InvenSense ICM-426xx Inertial Measurement Unit
maintainers:
- - Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
+ - Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
description: |
6-axis MotionTracking device that combines a 3-axis gyroscope and a 3-axis
@@ -31,12 +31,24 @@ properties:
- invensense,icm42602
- invensense,icm42605
- invensense,icm42622
+ - invensense,icm42631
+ - invensense,icm42686
+ - invensense,icm42688
reg:
maxItems: 1
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - INT1
+ - INT2
drive-open-drain:
type: boolean
@@ -47,7 +59,6 @@ properties:
vddio-supply:
description: Regulator that provides power to the bus
- spi-max-frequency: true
spi-cpha: true
spi-cpol: true
@@ -56,41 +67,44 @@ required:
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
icm42605@68 {
- compatible = "invensense,icm42605";
- reg = <0x68>;
- interrupt-parent = <&gpio2>;
- interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
- vdd-supply = <&vdd>;
- vddio-supply = <&vddio>;
+ compatible = "invensense,icm42605";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "INT1";
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
};
};
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
icm42602@0 {
- compatible = "invensense,icm42602";
- reg = <0>;
- spi-max-frequency = <24000000>;
- spi-cpha;
- spi-cpol;
- interrupt-parent = <&gpio1>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
- vdd-supply = <&vdd>;
- vddio-supply = <&vddio>;
+ compatible = "invensense,icm42602";
+ reg = <0>;
+ spi-max-frequency = <24000000>;
+ spi-cpha;
+ spi-cpol;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "INT1";
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm45600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm45600.yaml
new file mode 100644
index 000000000000..e0b78d14420f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm45600.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/imu/invensense,icm45600.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: InvenSense ICM-45600 Inertial Measurement Unit
+
+maintainers:
+ - Remi Buisson <remi.buisson@tdk.com>
+
+description: |
+ 6-axis MotionTracking device that combines a 3-axis gyroscope and a 3-axis
+ accelerometer.
+
+ It has a configurable host interface that supports I3C, I2C and SPI serial
+ communication, features up to 8kB FIFO and 2 programmable interrupts with
+ ultra-low-power wake-on-motion support to minimize system power consumption.
+
+ Other industry-leading features include InvenSense on-chip APEX Motion
+ Processing engine for gesture recognition, activity classification, and
+ pedometer, along with programmable digital filters, and an embedded
+ temperature sensor.
+
+ https://invensense.tdk.com/wp-content/uploads/documentation/DS-000576_ICM-45605.pdf
+
+properties:
+ compatible:
+ enum:
+ - invensense,icm45605
+ - invensense,icm45606
+ - invensense,icm45608
+ - invensense,icm45634
+ - invensense,icm45686
+ - invensense,icm45687
+ - invensense,icm45688p
+ - invensense,icm45689
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - enum: [int1, int2]
+ - const: int2
+ description: Choose chip interrupt pin to be used as interrupt input.
+
+ drive-open-drain:
+ type: boolean
+
+ vdd-supply: true
+
+ vddio-supply: true
+
+ mount-matrix: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imu@68 {
+ compatible = "invensense,icm45605";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupt-names = "int1";
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
+ mount-matrix = "0", "-1", "0",
+ "1", "0", "0",
+ "0", "0", "1";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
index 3ebc6526d82d..1af0855c33e6 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS MotionTracking Device
maintainers:
- - Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
+ - Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
description: |
These devices support both I2C and SPI bus interfaces.
@@ -16,6 +16,7 @@ properties:
compatible:
oneOf:
- enum:
+ - invensense,iam20380
- invensense,iam20680
- invensense,icm20608
- invensense,icm20609
@@ -31,8 +32,16 @@ properties:
- invensense,mpu9250
- invensense,mpu9255
- items:
+ - const: invensense,icm20600
+ - const: invensense,icm20602
+ - items:
- const: invensense,icm20608d
- const: invensense,icm20608
+ - items:
+ - enum:
+ - invensense,iam20680hp
+ - invensense,iam20680ht
+ - const: invensense,iam20680
reg:
maxItems: 1
@@ -40,13 +49,16 @@ properties:
interrupts:
maxItems: 1
- spi-max-frequency: true
-
vdd-supply: true
vddio-supply: true
mount-matrix: true
+ invensense,level-shifter:
+ type: boolean
+ description: |
+ From ancient platform data struct: false: VLogic, true: VDD
+
i2c-gate:
$ref: /schemas/i2c/i2c-controller.yaml
unevaluatedProperties: false
@@ -54,25 +66,26 @@ properties:
These devices also support an auxiliary i2c bus via an i2c-gate.
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
- not:
- properties:
- compatible:
- contains:
- enum:
- - invensense,mpu9150
- - invensense,mpu9250
- - invensense,mpu9255
+ properties:
+ compatible:
+ contains:
+ enum:
+ - invensense,iam20680
+ - invensense,icm20602
+ - invensense,icm20608
+ - invensense,icm20609
+ - invensense,icm20689
then:
properties:
i2c-gate: false
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
- reg
- - interrupts
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml
index 0203b83b8587..2930b3386703 100644
--- a/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml
@@ -36,45 +36,44 @@ properties:
drive-open-drain:
type: boolean
- spi-max-frequency: true
-
required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
fxos8700@1e {
- compatible = "nxp,fxos8700";
- reg = <0x1e>;
+ compatible = "nxp,fxos8700";
+ reg = <0x1e>;
- interrupt-parent = <&gpio2>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT1";
+ interrupt-parent = <&gpio2>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT1";
};
};
- |
- #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
fxos8700@0 {
- compatible = "nxp,fxos8700";
- reg = <0>;
+ compatible = "nxp,fxos8700";
+ reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "INT2";
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
};
};
diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
index 5d4839f00898..c48a96d17f51 100644
--- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
@@ -32,9 +32,25 @@ properties:
- st,lsm6dsrx
- st,lsm6dst
- st,lsm6dsop
+ - st,lsm6dsv
+ - st,lsm6dso16is
- items:
- - const: st,asm330lhhx
+ - enum:
+ - st,asm330lhhx
+ - st,asm330lhhxg1
- const: st,lsm6dsr
+ - items:
+ - const: st,lsm6dstx
+ - const: st,lsm6dst
+ - items:
+ - const: st,lsm6dsv16x
+ - const: st,lsm6dsv
+ - items:
+ - const: st,ism330is
+ - const: st,lsm6dso16is
+ - items:
+ - const: st,asm330lhb
+ - const: st,asm330lhh
reg:
maxItems: 1
@@ -45,8 +61,6 @@ properties:
description:
Supports up to 2 interrupt lines via the INT1 and INT2 pins.
- spi-max-frequency: true
-
vdd-supply:
description: if defined provides VDD power to the sensor.
@@ -54,7 +68,7 @@ properties:
description: if defined provides VDD IO power to the sensor.
st,drdy-int-pin:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
The pin on the package that will be used to signal data ready
enum:
@@ -81,12 +95,19 @@ properties:
wakeup-source:
$ref: /schemas/types.yaml#/definitions/flag
-additionalProperties: false
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/iio/iio.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
diff --git a/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml b/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml
index 0e8cd02759b3..062a038aa0ff 100644
--- a/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml
+++ b/Documentation/devicetree/bindings/iio/light/ams,as73211.yaml
@@ -4,19 +4,22 @@
$id: http://devicetree.org/schemas/iio/light/ams,as73211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: AMS AS73211 JENCOLOR(R) Digital XYZ Sensor
+title: AMS AS73211 JENCOLOR(R) Digital XYZ Sensor and AMS AS7331 UV Sensor
maintainers:
- Christian Eggers <ceggers@arri.de>
description: |
- XYZ True Color Sensor with I2C Interface
+ AMS AS73211 XYZ True Color Sensor with I2C Interface
https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0-b302-c2fd-e30a-c98df87616df
+ AMS AS7331 UVA, UVB and UVC Sensor with I2C Interface
+ https://ams.com/documents/20143/9106314/AS7331_DS001047_4-00.pdf
properties:
compatible:
enum:
- ams,as73211
+ - ams,as7331
reg:
description:
diff --git a/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml b/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml
index 206af44f2c43..b750096530bc 100644
--- a/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml
+++ b/Documentation/devicetree/bindings/iio/light/avago,apds9300.yaml
@@ -4,17 +4,22 @@
$id: http://devicetree.org/schemas/iio/light/avago,apds9300.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Avago APDS9300 ambient light sensor
+title: Avago Gesture/RGB/ALS/Proximity sensors
maintainers:
- - Jonathan Cameron <jic23@kernel.org>
+ - Subhajit Ghosh <subhajit.ghosh@tweaklogic.com>
description: |
- Datasheet at https://www.avagotech.com/docs/AV02-1077EN
+ Datasheet: https://www.avagotech.com/docs/AV02-1077EN
+ Datasheet: https://www.avagotech.com/docs/AV02-4191EN
+ Datasheet: https://www.avagotech.com/docs/AV02-4755EN
properties:
compatible:
- const: avago,apds9300
+ enum:
+ - avago,apds9300
+ - avago,apds9306
+ - avago,apds9960
reg:
maxItems: 1
@@ -22,6 +27,8 @@ properties:
interrupts:
maxItems: 1
+ vdd-supply: true
+
additionalProperties: false
required:
@@ -30,6 +37,8 @@ required:
examples:
- |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -38,7 +47,8 @@ examples:
compatible = "avago,apds9300";
reg = <0x39>;
interrupt-parent = <&gpio2>;
- interrupts = <29 8>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ vdd-supply = <&regulator_3v3>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml b/Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml
deleted file mode 100644
index f06e0fda5629..000000000000
--- a/Documentation/devicetree/bindings/iio/light/avago,apds9960.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/iio/light/avago,apds9960.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Avago APDS9960 gesture/RGB/ALS/proximity sensor
-
-maintainers:
- - Matt Ranostay <matt.ranostay@konsulko.com>
-
-description: |
- Datasheet at https://www.avagotech.com/docs/AV02-4191EN
-
-properties:
- compatible:
- const: avago,apds9960
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- light-sensor@39 {
- compatible = "avago,apds9960";
- reg = <0x39>;
- interrupt-parent = <&gpio1>;
- interrupts = <16 1>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/iio/light/bh1750.yaml b/Documentation/devicetree/bindings/iio/light/bh1750.yaml
index 1a88b3c253d5..9df81c271411 100644
--- a/Documentation/devicetree/bindings/iio/light/bh1750.yaml
+++ b/Documentation/devicetree/bindings/iio/light/bh1750.yaml
@@ -24,6 +24,10 @@ properties:
reg:
maxItems: 1
+ reset-gpios:
+ description: GPIO connected to the DVI reset pin (active low)
+ maxItems: 1
+
required:
- compatible
- reg
@@ -32,6 +36,7 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -39,6 +44,7 @@ examples:
light-sensor@23 {
compatible = "rohm,bh1750";
reg = <0x23>;
+ reset-gpios = <&gpio2 17 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml b/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml
new file mode 100644
index 000000000000..bb1cc4404a55
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/brcm,apds9160.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Combined Proximity & Ambient light sensor
+
+maintainers:
+ - Mikael Gonella-Bolduc <m.gonella.bolduc@gmail.com>
+
+description: |
+ Datasheet: https://docs.broadcom.com/docs/APDS-9160-003-DS
+
+properties:
+ compatible:
+ enum:
+ - brcm,apds9160
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ ps-cancellation-duration:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Proximity sensor cancellation pulse duration in half clock cycles.
+ This parameter determines a cancellation pulse duration.
+ The cancellation is applied in the integration phase to cancel out
+ unwanted reflected light from very near objects such as tempered glass
+ in front of the sensor.
+ default: 0
+ maximum: 63
+
+ ps-cancellation-current-picoamp:
+ description:
+ Proximity sensor crosstalk cancellation current in picoampere.
+ This parameter adjusts the current in steps of 2400 pA up to 276000 pA.
+ The provided value must be a multiple of 2400 and in one of these ranges
+ [60000 - 96000]
+ [120000 - 156000]
+ [180000 - 216000]
+ [240000 - 276000]
+ This parameter is used in conjunction with the cancellation duration.
+ minimum: 60000
+ maximum: 276000
+ multipleOf: 2400
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@53 {
+ compatible = "brcm,apds9160";
+ reg = <0x53>;
+ vdd-supply = <&vdd_reg>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&pinctrl>;
+ ps-cancellation-duration = <10>;
+ ps-cancellation-current-picoamp = <62400>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml b/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml
index a3a979553e32..1472c997c16f 100644
--- a/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml
+++ b/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml
@@ -4,14 +4,16 @@
$id: http://devicetree.org/schemas/iio/light/dynaimage,al3010.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dyna-Image AL3010 sensor
+title: Dyna-Image AL3000a/AL3010 sensor
maintainers:
- David Heidelberg <david@ixit.cz>
properties:
compatible:
- const: dynaimage,al3010
+ enum:
+ - dynaimage,al3000a
+ - dynaimage,al3010
reg:
maxItems: 1
@@ -40,6 +42,6 @@ examples:
compatible = "dynaimage,al3010";
reg = <0x1c>;
vdd-supply = <&vdd_reg>;
- interrupts = <0 99 4>;
+ interrupts = <99 IRQ_TYPE_LEVEL_HIGH>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml b/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml
index 8249be99cff9..d06db737cd9e 100644
--- a/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml
+++ b/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml
@@ -40,6 +40,6 @@ examples:
compatible = "dynaimage,al3320a";
reg = <0x1c>;
vdd-supply = <&vdd_reg>;
- interrupts = <0 99 4>;
+ interrupts = <99 IRQ_TYPE_LEVEL_HIGH>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr390.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr390.yaml
new file mode 100644
index 000000000000..5d98ef2af74d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr390.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/liteon,ltr390.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lite-On LTR390 ALS and UV Sensor
+
+description: |
+ The Lite-On LTR390 is an ALS (Ambient Light Sensor) and a UV sensor in a
+ single package with i2c address of 0x53.
+
+ Datasheet:
+ https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - liteon,ltr390
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: |
+ Level interrupt pin with open drain output.
+ The sensor pulls this pin low when the measured reading is greater than
+ some configured threshold.
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@53 {
+ compatible = "liteon,ltr390";
+ reg = <0x53>;
+ interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&vdd_regulator>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml
new file mode 100644
index 000000000000..877e955d4ebd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltrf216a.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/liteon,ltrf216a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LTRF216A Ambient Light Sensor
+
+maintainers:
+ - Shreeya Patel <shreeya.patel@collabora.com>
+
+description:
+ Ambient light sensing with an i2c interface.
+
+properties:
+ compatible:
+ enum:
+ - liteon,ltr308
+ - liteon,ltrf216a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the sensor.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@53 {
+ compatible = "liteon,ltrf216a";
+ reg = <0x53>;
+ vdd-supply = <&vdd_regulator>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml
new file mode 100644
index 000000000000..44896795c67e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/rohm,bh1745.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/rohm,bh1745.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BH1745 colour sensor
+
+maintainers:
+ - Mudit Sharma <muditsharma.info@gmail.com>
+
+description:
+ BH1745 is an I2C colour sensor with red, green, blue and clear
+ channels. It has a programmable active low interrupt pin.
+ Interrupt occurs when the signal from the selected interrupt
+ source channel crosses set interrupt threshold high/low level.
+
+properties:
+ compatible:
+ const: rohm,bh1745
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ colour-sensor@38 {
+ compatible = "rohm,bh1745";
+ reg = <0x38>;
+ interrupt-parent = <&gpio>;
+ interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
+ vdd-supply = <&vdd>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27034anuc.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27034anuc.yaml
new file mode 100644
index 000000000000..29c90ca5b258
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27034anuc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/rohm,bu27034anuc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BU27034ANUC ambient light sensor
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description: |
+ ROHM BU27034ANUC is an ambient light sensor with 2 channels and 2 photo diodes
+ capable of detecting a very wide range of illuminance. Typical application
+ is adjusting LCD and backlight power of TVs and mobile phones.
+
+properties:
+ compatible:
+ const: rohm,bu27034anuc
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@38 {
+ compatible = "rohm,bu27034anuc";
+ reg = <0x38>;
+ vdd-supply = <&vdd>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml b/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml
index 27c36ab7990d..8598fb631aac 100644
--- a/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml
+++ b/Documentation/devicetree/bindings/iio/light/st,vl6180.yaml
@@ -32,7 +32,6 @@ required:
examples:
- |
- #include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml
index f6e22dc9814a..e4341fdced98 100644
--- a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml
+++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml
@@ -18,10 +18,15 @@ allOf:
properties:
compatible:
- enum:
- - sensortek,stk3310
- - sensortek,stk3311
- - sensortek,stk3335
+ oneOf:
+ - enum:
+ - sensortek,stk3310
+ - sensortek,stk3311
+ - sensortek,stk3335
+ - items:
+ - enum:
+ - sensortek,stk3013
+ - const: sensortek,stk3310
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml
index 441e9343fc97..67ca8d08256a 100644
--- a/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml
+++ b/Documentation/devicetree/bindings/iio/light/ti,opt3001.yaml
@@ -15,7 +15,9 @@ description: |
properties:
compatible:
- const: ti,opt3001
+ enum:
+ - ti,opt3001
+ - ti,opt3002
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml
new file mode 100644
index 000000000000..12b0c7ed5d72
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ti,opt4001.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/ti,opt4001.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OPT4001 Ambient Light Sensor
+
+maintainers:
+ - Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com>
+
+description:
+ Ambient light sensor with an i2c interface.
+ Last part of compatible is for the packaging used.
+ Picostar is a 4 pinned SMT and sot-5x3 is a 8 pinned SOT.
+ https://www.ti.com/lit/gpn/opt4001
+
+properties:
+ compatible:
+ enum:
+ - ti,opt4001-picostar
+ - ti,opt4001-sot-5x3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,opt4001-sot-5x3
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ else:
+ properties:
+ interrupts: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@44 {
+ compatible = "ti,opt4001-sot-5x3";
+ reg = <0x44>;
+ vdd-supply = <&vdd_reg>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml b/Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml
new file mode 100644
index 000000000000..568fb2a9b7a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/ti,opt4060.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/ti,opt4060.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OPT4060 RGBW Color Sensor
+
+maintainers:
+ - Per-Daniel Olsson <perdaniel.olsson@axis.com>
+
+description:
+ Texas Instrument RGBW high resolution color sensor over I2C.
+ https://www.ti.com/lit/gpn/opt4060
+
+properties:
+ compatible:
+ enum:
+ - ti,opt4060
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@44 {
+ compatible = "ti,opt4060";
+ reg = <0x44>;
+ vdd-supply = <&vdd_reg>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/veml6030.yaml b/Documentation/devicetree/bindings/iio/light/veml6030.yaml
deleted file mode 100644
index fb19a2d7a849..000000000000
--- a/Documentation/devicetree/bindings/iio/light/veml6030.yaml
+++ /dev/null
@@ -1,64 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/iio/light/veml6030.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: VEML6030 Ambient Light Sensor (ALS)
-
-maintainers:
- - Rishi Gupta <gupt21@gmail.com>
-
-description: |
- Bindings for the ambient light sensor veml6030 from Vishay
- Semiconductors over an i2c interface.
-
- Irrespective of whether interrupt is used or not, application
- can get the ALS and White channel reading from IIO raw interface.
-
- If the interrupts are used, application will receive an IIO event
- whenever configured threshold is crossed.
-
- Specifications about the sensor can be found at:
- https://www.vishay.com/docs/84366/veml6030.pdf
-
-properties:
- compatible:
- enum:
- - vishay,veml6030
-
- reg:
- description:
- I2C address of the device.
- enum:
- - 0x10 # ADDR pin pulled down
- - 0x48 # ADDR pin pulled up
-
- interrupts:
- description:
- interrupt mapping for IRQ. Configure with IRQ_TYPE_LEVEL_LOW.
- Refer to interrupt-controller/interrupts.txt for generic
- interrupt client node bindings.
- maxItems: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- light-sensor@10 {
- compatible = "vishay,veml6030";
- reg = <0x10>;
- interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/iio/light/vishay,veml6030.yaml b/Documentation/devicetree/bindings/iio/light/vishay,veml6030.yaml
new file mode 100644
index 000000000000..4ea69f1fdd63
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/vishay,veml6030.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/vishay,veml6030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VEML3235, VEML6030, VEML6035 and VEML7700 Ambient Light Sensors (ALS)
+
+maintainers:
+ - Rishi Gupta <gupt21@gmail.com>
+
+description: |
+ Bindings for the ambient light sensors veml6030 and veml6035 from
+ Vishay Semiconductors over an i2c interface.
+
+ Irrespective of whether interrupt is used or not, application
+ can get the ALS and White channel reading from IIO raw interface.
+
+ If the interrupts are used, application will receive an IIO event
+ whenever configured threshold is crossed.
+
+ Specifications about the sensors can be found at:
+ https://www.vishay.com/docs/80131/veml3235.pdf
+ https://www.vishay.com/docs/84366/veml6030.pdf
+ https://www.vishay.com/docs/84889/veml6035.pdf
+ https://www.vishay.com/docs/84286/veml7700.pdf
+
+properties:
+ compatible:
+ enum:
+ - vishay,veml3235
+ - vishay,veml6030
+ - vishay,veml6035
+ - vishay,veml7700
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ interrupt mapping for IRQ. Configure with IRQ_TYPE_LEVEL_LOW.
+ Refer to interrupt-controller/interrupts.txt for generic
+ interrupt client node bindings.
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - vishay,veml6030
+ then:
+ properties:
+ reg:
+ enum:
+ - 0x10 # ADDR pin pulled down
+ - 0x48 # ADDR pin pulled up
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - vishay,veml6035
+ then:
+ properties:
+ reg:
+ enum:
+ - 0x29
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - vishay,veml3235
+ - vishay,veml7700
+ then:
+ properties:
+ reg:
+ enum:
+ - 0x10
+ interrupts: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ light-sensor@10 {
+ compatible = "vishay,veml6030";
+ reg = <0x10>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+ vdd-supply = <&vdd>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/vishay,veml6046x00.yaml b/Documentation/devicetree/bindings/iio/light/vishay,veml6046x00.yaml
new file mode 100644
index 000000000000..112d448ff0bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/vishay,veml6046x00.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/vishay,veml6046x00.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Vishay VEML6046X00 High accuracy RGBIR color sensor
+
+maintainers:
+ - Andreas Klinger <ak@it-klinger.de>
+
+description:
+ VEML6046X00 datasheet at https://www.vishay.com/docs/80173/veml6046x00.pdf
+
+properties:
+ compatible:
+ enum:
+ - vishay,veml6046x00
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ color-sensor@29 {
+ compatible = "vishay,veml6046x00";
+ reg = <0x29>;
+ vdd-supply = <&vdd_reg>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/light/vishay,veml6075.yaml b/Documentation/devicetree/bindings/iio/light/vishay,veml6075.yaml
new file mode 100644
index 000000000000..d2effccbfb56
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/vishay,veml6075.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/vishay,veml6075.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Vishay VEML6070 UVA, VEML6075 UVA/B and VEML6040 RGBW sensors
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+description:
+ VEML6040 datasheet at https://www.vishay.com/docs/84276/veml6040.pdf
+
+properties:
+ compatible:
+ enum:
+ - vishay,veml6040
+ - vishay,veml6070
+ - vishay,veml6075
+
+ reg:
+ maxItems: 1
+
+ vishay,rset-ohms:
+ description:
+ Resistor used to select the integration time.
+ default: 270000
+ minimum: 75000
+ maximum: 1200000
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - vishay,veml6040
+ - vishay,veml6075
+ then:
+ properties:
+ vishay,rset-ohms: false
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ uv-sensor@10 {
+ compatible = "vishay,veml6075";
+ reg = <0x10>;
+ vdd-supply = <&vdd_reg>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/allegromicro,als31300.yaml b/Documentation/devicetree/bindings/iio/magnetometer/allegromicro,als31300.yaml
new file mode 100644
index 000000000000..52e3781834ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/allegromicro,als31300.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/allegromicro,als31300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allegro MicroSystems ALS31300 3-D Linear Hall Effect sensor
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ $nodename:
+ pattern: '^magnetometer@[0-9a-f]+$'
+
+ compatible:
+ enum:
+ - allegromicro,als31300-500 # Factory configured at 500 Gauss input range
+ - allegromicro,als31300-1000 # Factory configured at 1000 Gauss input range
+ - allegromicro,als31300-2000 # Factory configured at 2000 Gauss input range
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: 5.5V supply
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ magnetometer@61 {
+ compatible = "allegromicro,als31300-500";
+ reg = <0x61>;
+ vcc-supply = <&hall_vcc>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
index 9790f75fc669..e8ca9a234027 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
@@ -18,12 +18,15 @@ properties:
- asahi-kasei,ak09911
- asahi-kasei,ak09912
- asahi-kasei,ak09916
+ - items:
+ # ak09918 is register compatible with ak09912.
+ - const: asahi-kasei,ak09918
+ - const: asahi-kasei,ak09912
- enum:
- ak8975
- ak8963
- ak09911
- ak09912
- - ak09916
deprecated: true
reg:
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml b/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml
index 2867ab6bf9b0..a3838ab0c524 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/bosch,bmc150_magn.yaml
@@ -36,6 +36,9 @@ properties:
interrupts:
maxItems: 1
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml b/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml
index 6b54d32323fc..fbe8c2eb0857 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/fsl,mag3110.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale MAG3110 magnetometer sensor
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Jonathan Cameron <jic23@kernel.org>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/infineon,tlv493d-a1b6.yaml b/Documentation/devicetree/bindings/iio/magnetometer/infineon,tlv493d-a1b6.yaml
new file mode 100644
index 000000000000..dd23a9370a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/infineon,tlv493d-a1b6.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/infineon,tlv493d-a1b6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon Technologies TLV493D Low-Power 3D Magnetic Sensor
+
+maintainers:
+ - Dixit Parmar <dixitparmar19@gmail.com>
+
+properties:
+ $nodename:
+ pattern: '^magnetometer@[0-9a-f]+$'
+
+ compatible:
+ const: infineon,tlv493d-a1b6
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: 2.8V to 3.5V VDD supply
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ magnetometer@5e {
+ compatible = "infineon,tlv493d-a1b6";
+ reg = <0x5e>;
+ vdd-supply = <&hall_vcc>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml b/Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml
new file mode 100644
index 000000000000..d4a3f7981c36
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/silabs,si7210.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Si7210 magnetic position and temperature sensor
+
+maintainers:
+ - Antoni Pokusinski <apokusinski01@gmail.com>
+
+description: |
+ Silabs Si7210 I2C Hall effect magnetic position and temperature sensor.
+ https://www.silabs.com/documents/public/data-sheets/si7210-datasheet.pdf
+
+properties:
+ compatible:
+ const: silabs,si7210
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides power to the sensor
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ magnetometer@30 {
+ compatible = "silabs,si7210";
+ reg = <0x30>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&vdd_3v3_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml
new file mode 100644
index 000000000000..121d540b7b6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ti,tmag5273.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/ti,tmag5273.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TMAG5273 Low-Power Linear 3D Hall-Effect Sensor
+
+maintainers:
+ - Gerald Loacker <gerald.loacker@wolfvision.net>
+
+description:
+ The TI TMAG5273 is a low-power linear 3D Hall-effect sensor. This device
+ integrates three independent Hall-effect sensors in the X, Y, and Z axes.
+ The device has an integrated temperature sensor available. The TMAG5273
+ can be configured through the I2C interface to enable any combination of
+ magnetic axes and temperature measurements. An integrated angle calculation
+ engine (CORDIC) provides full 360° angular position information for both
+ on-axis and off-axis angle measurement topologies. The angle calculation is
+ performed using two user-selected magnetic axes.
+
+properties:
+ compatible:
+ const: ti,tmag5273
+
+ reg:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 1
+
+ ti,angle-measurement:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Enables angle measurement in the selected plane.
+ If not specified, "x-y" will be anables as default.
+ enum:
+ - off
+ - x-y
+ - y-z
+ - x-z
+
+ vcc-supply:
+ description:
+ A regulator providing 1.7 V to 3.6 V supply voltage on the VCC pin,
+ typically 3.3 V.
+
+ interrupts:
+ description:
+ The low active interrupt can be configured to be fixed width or latched.
+ Interrupt events can be configured to be generated from magnetic
+ thresholds or when a conversion is completed.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@35 {
+ compatible = "ti,tmag5273";
+ reg = <0x35>;
+ #io-channel-cells = <1>;
+ ti,angle-measurement = "x-z";
+ vcc-supply = <&vcc3v3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/voltafield,af8133j.yaml b/Documentation/devicetree/bindings/iio/magnetometer/voltafield,af8133j.yaml
new file mode 100644
index 000000000000..ed42dc5afb99
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/voltafield,af8133j.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/voltafield,af8133j.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Voltafield AF8133J magnetometer sensor
+
+maintainers:
+ - Ondřej Jirman <megi@xff.cz>
+
+properties:
+ compatible:
+ const: voltafield,af8133j
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ A signal for active low reset input of the sensor. (optional; if not
+ used, software reset over I2C will be used instead)
+
+ avdd-supply:
+ description:
+ A regulator that provides AVDD power (Working power, usually 3.3V) to
+ the sensor.
+
+ dvdd-supply:
+ description:
+ A regulator that provides DVDD power (Digital IO power, 1.8V - AVDD)
+ to the sensor.
+
+ mount-matrix:
+ description: An optional 3x3 mounting rotation matrix.
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@1c {
+ compatible = "voltafield,af8133j";
+ reg = <0x1c>;
+ avdd-supply = <&reg_dldo1>;
+ dvdd-supply = <&reg_dldo1>;
+ reset-gpios = <&pio 1 1 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml b/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml
index 9438fffaf0ba..877226e9219b 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml
@@ -91,12 +91,12 @@ examples:
#size-cells = <0>;
magnetometer@2e {
- compatible = "yamaha,yas530";
- reg = <0x2e>;
- vdd-supply = <&ldo1_reg>;
- iovdd-supply = <&ldo2_reg>;
- reset-gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
- interrupts = <13 IRQ_TYPE_EDGE_RISING>;
+ compatible = "yamaha,yas530";
+ reg = <0x2e>;
+ vdd-supply = <&ldo1_reg>;
+ iovdd-supply = <&ldo2_reg>;
+ reset-gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+ interrupts = <13 IRQ_TYPE_EDGE_RISING>;
};
};
@@ -105,8 +105,8 @@ examples:
#size-cells = <0>;
magnetometer@2e {
- compatible = "yamaha,yas539";
- reg = <0x2e>;
- vdd-supply = <&ldo1_reg>;
+ compatible = "yamaha,yas539";
+ reg = <0x2e>;
+ vdd-supply = <&ldo1_reg>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml
index 611ad4444cf0..c55831b60ee6 100644
--- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml
+++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/multiplexer/io-channel-mux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: I/O channel multiplexer bindings
+title: I/O channel multiplexer
maintainers:
- Peter Rosin <peda@axentia.se>
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml b/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
index 0ebb6725a1af..b8d7083c97f8 100644
--- a/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
+++ b/Documentation/devicetree/bindings/iio/potentiometer/adi,ad5272.yaml
@@ -44,7 +44,7 @@ examples:
potentiometer@2f {
compatible = "adi,ad5272-020";
- reg = <0x2F>;
+ reg = <0x2f>;
reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml
index 567697d996ec..87e88f2a9908 100644
--- a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml
+++ b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp41010.yaml
@@ -25,14 +25,15 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml
index 32e92bced81f..896fe0b5edcc 100644
--- a/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml
+++ b/Documentation/devicetree/bindings/iio/potentiometer/microchip,mcp4131.yaml
@@ -80,14 +80,15 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml b/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml
new file mode 100644
index 000000000000..ab5c09c00ff4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/renesas,x9250.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/potentiometer/renesas,x9250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas X9250 quad potentiometers
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The Renesas X9250 integrates four digitally controlled potentiometers.
+ On each potentiometer, the X9250T has a 100 kOhms total resistance and the
+ X9250U has a 50 kOhms total resistance.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+properties:
+ compatible:
+ enum:
+ - renesas,x9250t
+ - renesas,x9250u
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description:
+ Regulator for the VCC power supply.
+
+ avp-supply:
+ description:
+ Regulator for the analog V+ power supply.
+
+ avn-supply:
+ description:
+ Regulator for the analog V- power supply.
+
+ '#io-channel-cells':
+ const: 1
+
+ spi-max-frequency:
+ maximum: 2000000
+
+ wp-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the write-protect pin.
+
+required:
+ - compatible
+ - reg
+ - vcc-supply
+ - avp-supply
+ - avn-supply
+ - '#io-channel-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ potentiometer@0 {
+ compatible = "renesas,x9250t";
+ reg = <0>;
+ vcc-supply = <&vcc_regulator>;
+ avp-supply = <&avp_regulator>;
+ avn-supply = <&avp_regulator>;
+ wp-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <2000000>;
+ #io-channel-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/aosong,adp810.yaml b/Documentation/devicetree/bindings/iio/pressure/aosong,adp810.yaml
new file mode 100644
index 000000000000..ad5f26ce5043
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/aosong,adp810.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/aosong,adp810.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: aosong adp810 differential pressure sensor
+
+maintainers:
+ - Akhilesh Patil <akhilesh@ee.iitb.ac.in>
+
+description:
+ ADP810 is differential pressure and temperature sensor. It has I2C bus
+ interface with fixed address of 0x25. This sensor supports 8 bit CRC for
+ reliable data transfer. It can measure differential pressure in the
+ range -500 to 500Pa and temperate in the range -40 to +85 degree celsius.
+
+properties:
+ compatible:
+ enum:
+ - aosong,adp810
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure-sensor@25 {
+ compatible = "aosong,adp810";
+ reg = <0x25>;
+ vdd-supply = <&vdd_regulator>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
index be2be4b556db..9fb8d773efa3 100644
--- a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: All Sensors DLH series low voltage digital pressure sensors
maintainers:
- - Tomislav Denis <tomislav.denis@avl.com>
+ - Jonathan Cameron <jic23@kernel.org>
description: |
Bindings for the All Sensors DLH series pressure sensors.
@@ -39,7 +39,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
index 49257f9251e8..b9ea37317b53 100644
--- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/pressure/bmp085.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: BMP085/BMP180/BMP280/BME280 pressure iio sensors
+title: BMP085/BMP180/BMP280/BME280/BMP380 pressure iio sensors
maintainers:
- Andreas Klinger <ak@it-klinger.de>
@@ -16,6 +16,8 @@ description: |
https://www.bosch-sensortec.com/bst/products/all_products/bmp180
https://www.bosch-sensortec.com/bst/products/all_products/bmp280
https://www.bosch-sensortec.com/bst/products/all_products/bme280
+ https://www.bosch-sensortec.com/bst/products/all_products/bmp380
+ https://www.bosch-sensortec.com/bst/products/all_products/bmp580
properties:
compatible:
@@ -24,6 +26,8 @@ properties:
- bosch,bmp180
- bosch,bmp280
- bosch,bme280
+ - bosch,bmp380
+ - bosch,bmp580
reg:
maxItems: 1
@@ -43,31 +47,77 @@ properties:
maxItems: 1
interrupts:
- description:
- interrupt mapping for IRQ (BMP085 only)
maxItems: 1
+ drive-open-drain:
+ description:
+ set if the interrupt pin should be configured as open drain.
+ If not set, defaults to push-pull configuration.
+ type: boolean
+
+ spi-max-frequency:
+ maximum: 10000000
+
required:
- compatible
- vddd-supply
- vdda-supply
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - bosch,bmp085
+ - bosch,bmp380
+ - bosch,bmp580
+ then:
+ properties:
+ interrupts: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - bosch,bmp085
+ - bosch,bmp180
+ then:
+ properties:
+ spi-max-frequency: false
+
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- pressure@77 {
- compatible = "bosch,bmp085";
- reg = <0x77>;
- interrupt-parent = <&gpio0>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
- vddd-supply = <&foo>;
- vdda-supply = <&bar>;
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@77 {
+ compatible = "bosch,bmp085";
+ reg = <0x77>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
+ vddd-supply = <&foo>;
+ vdda-supply = <&bar>;
+ };
+ };
+ - |
+ # include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@0 {
+ compatible = "bosch,bmp280";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ reset-gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
+ vddd-supply = <&foo>;
+ vdda-supply = <&bar>;
+ };
};
diff --git a/Documentation/devicetree/bindings/iio/pressure/fsl,mpl3115.yaml b/Documentation/devicetree/bindings/iio/pressure/fsl,mpl3115.yaml
new file mode 100644
index 000000000000..2933c2e10695
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/fsl,mpl3115.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/fsl,mpl3115.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MPL3115 precision pressure sensor with altimetry
+
+maintainers:
+ - Antoni Pokusinski <apokusinski01@gmail.com>
+
+description: |
+ MPL3115 is a pressure/altitude and temperature sensor with I2C interface.
+ It features two programmable interrupt lines which indicate events such as
+ data ready or pressure/temperature threshold reached.
+ https://www.nxp.com/docs/en/data-sheet/MPL3115A2.pdf
+
+properties:
+ compatible:
+ const: fsl,mpl3115
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+ vddio-supply: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - INT1
+ - INT2
+
+ drive-open-drain:
+ type: boolean
+ description:
+ set if the specified interrupt pins should be configured as
+ open drain. If not set, defaults to push-pull.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@60 {
+ compatible = "fsl,mpl3115";
+ reg = <0x60>;
+ vdd-supply = <&vdd>;
+ vddio-supply = <&vddio>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "INT2";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,hsc030pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,hsc030pa.yaml
new file mode 100644
index 000000000000..412c7bcc310f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,hsc030pa.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/honeywell,hsc030pa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Honeywell TruStability HSC and SSC pressure sensor series
+
+description: |
+ support for Honeywell TruStability HSC and SSC digital pressure sensor
+ series.
+
+ These sensors have either an I2C, an SPI or an analog interface. Only the
+ digital versions are supported by this driver.
+
+ There are 118 models with different pressure ranges available in each family.
+ The vendor calls them "HSC series" and "SSC series". All of them have an
+ identical programming model but differ in pressure range, unit and transfer
+ function.
+
+ To support different models one needs to specify the pressure range as well
+ as the transfer function. Pressure range can either be provided via
+ pressure-triplet (directly extracted from the part number) or in case it's
+ a custom chip via numerical range limits converted to pascals.
+
+ The transfer function defines the ranges of raw conversion values delivered
+ by the sensor. pmin-pascal and pmax-pascal corespond to the minimum and
+ maximum pressure that can be measured.
+
+ Please note that in case of an SPI-based sensor, the clock signal should not
+ exceed 800kHz and the MOSI signal is not required.
+
+ Specifications about the devices can be found at:
+ https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-hsc-series/documents/sps-siot-trustability-hsc-series-high-accuracy-board-mount-pressure-sensors-50099148-a-en-ciid-151133.pdf
+ https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-ssc-series/documents/sps-siot-trustability-ssc-series-standard-accuracy-board-mount-pressure-sensors-50099533-a-en-ciid-151134.pdf
+
+maintainers:
+ - Petre Rodan <petre.rodan@subdimension.ro>
+
+properties:
+ compatible:
+ const: honeywell,hsc030pa
+
+ reg:
+ maxItems: 1
+
+ honeywell,transfer-function:
+ description: |
+ Transfer function which defines the range of valid values delivered by
+ the sensor.
+ 0 - A, 10% to 90% of 2^14
+ 1 - B, 5% to 95% of 2^14
+ 2 - C, 5% to 85% of 2^14
+ 3 - F, 4% to 94% of 2^14
+ enum: [0, 1, 2, 3]
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ honeywell,pressure-triplet:
+ description: |
+ Case-sensitive five character string that defines pressure range, unit
+ and type as part of the device nomenclature. In the unlikely case of a
+ custom chip, set to "NA" and provide pmin-pascal and pmax-pascal.
+ enum: [001BA, 1.6BA, 2.5BA, 004BA, 006BA, 010BA, 1.6MD, 2.5MD, 004MD,
+ 006MD, 010MD, 016MD, 025MD, 040MD, 060MD, 100MD, 160MD, 250MD,
+ 400MD, 600MD, 001BD, 1.6BD, 2.5BD, 004BD, 2.5MG, 004MG, 006MG,
+ 010MG, 016MG, 025MG, 040MG, 060MG, 100MG, 160MG, 250MG, 400MG,
+ 600MG, 001BG, 1.6BG, 2.5BG, 004BG, 006BG, 010BG, 100KA, 160KA,
+ 250KA, 400KA, 600KA, 001GA, 160LD, 250LD, 400LD, 600LD, 001KD,
+ 1.6KD, 2.5KD, 004KD, 006KD, 010KD, 016KD, 025KD, 040KD, 060KD,
+ 100KD, 160KD, 250KD, 400KD, 250LG, 400LG, 600LG, 001KG, 1.6KG,
+ 2.5KG, 004KG, 006KG, 010KG, 016KG, 025KG, 040KG, 060KG, 100KG,
+ 160KG, 250KG, 400KG, 600KG, 001GG, 015PA, 030PA, 060PA, 100PA,
+ 150PA, 0.5ND, 001ND, 002ND, 004ND, 005ND, 010ND, 020ND, 030ND,
+ 001PD, 005PD, 015PD, 030PD, 060PD, 001NG, 002NG, 004NG, 005NG,
+ 010NG, 020NG, 030NG, 001PG, 005PG, 015PG, 030PG, 060PG, 100PG,
+ 150PG, NA]
+ $ref: /schemas/types.yaml#/definitions/string
+
+ honeywell,pmin-pascal:
+ description: |
+ Minimum pressure value the sensor can measure in pascal.
+ To be specified only if honeywell,pressure-triplet is set to "NA".
+
+ honeywell,pmax-pascal:
+ description: |
+ Maximum pressure value the sensor can measure in pascal.
+ To be specified only if honeywell,pressure-triplet is set to "NA".
+
+ vdd-supply:
+ description:
+ Provide VDD power to the sensor (either 3.3V or 5V depending on the chip)
+
+ spi-max-frequency:
+ maximum: 800000
+
+required:
+ - compatible
+ - reg
+ - honeywell,transfer-function
+ - honeywell,pressure-triplet
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+unevaluatedProperties: false
+
+dependentSchemas:
+ honeywell,pmin-pascal:
+ properties:
+ honeywell,pressure-triplet:
+ const: NA
+ honeywell,pmax-pascal:
+ properties:
+ honeywell,pressure-triplet:
+ const: NA
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@28 {
+ compatible = "honeywell,hsc030pa";
+ reg = <0x28>;
+ honeywell,transfer-function = <0>;
+ honeywell,pressure-triplet = "030PA";
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@0 {
+ compatible = "honeywell,hsc030pa";
+ reg = <0>;
+ spi-max-frequency = <800000>;
+ honeywell,transfer-function = <0>;
+ honeywell,pressure-triplet = "NA";
+ honeywell,pmin-pascal = <0>;
+ honeywell,pmax-pascal = <200000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
new file mode 100644
index 000000000000..c756aa863103
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/honeywell,mprls0025pa.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/honeywell,mprls0025pa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Honeywell mprls0025pa pressure sensor
+
+maintainers:
+ - Andreas Klinger <ak@it-klinger.de>
+ - Petre Rodan <petre.rodan@subdimension.ro>
+
+description: |
+ Honeywell pressure sensor of model mprls0025pa.
+
+ This sensor has an I2C and SPI interface.
+
+ There are many models with different pressure ranges available. The vendor
+ calls them "mpr series". All of them have the identical programming model and
+ differ in the pressure range, unit and transfer function.
+
+ To support different models one need to specify its pressure triplet as well
+ as the transfer function.
+
+ For custom silicon chips not covered by the Honeywell MPR series datasheet,
+ the pressure values can be specified manually via honeywell,pmin-pascal and
+ honeywell,pmax-pascal.
+ The minimal range value stands for the minimum pressure and the maximum value
+ also for the maximum pressure with linear relation inside the range.
+
+ The transfer function defines the ranges of numerical values delivered by the
+ sensor.
+
+ Specifications about the devices can be found at:
+ https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/
+ products/sensors/pressure-sensors/board-mount-pressure-sensors/
+ micropressure-mpr-series/documents/
+ sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf
+
+properties:
+ compatible:
+ const: honeywell,mprls0025pa
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Optional interrupt for indicating End-of-conversion.
+ If not present, the driver loops for a while until the received status
+ byte indicates correct measurement.
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Optional GPIO for resetting the device.
+ If not present the device is not reset during the probe.
+ maxItems: 1
+
+ honeywell,transfer-function:
+ description: |
+ Transfer function which defines the range of valid values delivered by the
+ sensor.
+ 1 - A, 10% to 90% of 2^24 (1677722 .. 15099494)
+ 2 - B, 2.5% to 22.5% of 2^24 (419430 .. 3774874)
+ 3 - C, 20% to 80% of 2^24 (3355443 .. 13421773)
+ enum: [1, 2, 3]
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ honeywell,pressure-triplet:
+ description: |
+ Case-sensitive five character string that defines pressure range, unit
+ and type as part of the device nomenclature. In the unlikely case of a
+ custom chip, unset and provide pmin-pascal and pmax-pascal instead.
+ enum: [0001BA, 01.6BA, 02.5BA, 0060MG, 0100MG, 0160MG, 0250MG, 0400MG,
+ 0600MG, 0001BG, 01.6BG, 02.5BG, 0100KA, 0160KA, 0250KA, 0006KG,
+ 0010KG, 0016KG, 0025KG, 0040KG, 0060KG, 0100KG, 0160KG, 0250KG,
+ 0015PA, 0025PA, 0030PA, 0001PG, 0005PG, 0015PG, 0030PG, 0300YG]
+ $ref: /schemas/types.yaml#/definitions/string
+
+ honeywell,pmin-pascal:
+ description:
+ Minimum pressure value the sensor can measure in pascal.
+
+ honeywell,pmax-pascal:
+ description:
+ Maximum pressure value the sensor can measure in pascal.
+
+ spi-max-frequency:
+ maximum: 800000
+
+ vdd-supply:
+ description: provide VDD power to the sensor.
+
+required:
+ - compatible
+ - reg
+ - honeywell,transfer-function
+ - vdd-supply
+
+oneOf:
+ - required:
+ - honeywell,pressure-triplet
+ - required:
+ - honeywell,pmin-pascal
+ - honeywell,pmax-pascal
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+ - if:
+ required:
+ - honeywell,pressure-triplet
+ then:
+ properties:
+ honeywell,pmin-pascal: false
+ honeywell,pmax-pascal: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@18 {
+ compatible = "honeywell,mprls0025pa";
+ reg = <0x18>;
+ reset-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <21 IRQ_TYPE_EDGE_RISING>;
+
+ honeywell,pressure-triplet = "0025PA";
+ honeywell,transfer-function = <1>;
+ vdd-supply = <&vcc_3v3>;
+ };
+ };
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pressure@0 {
+ compatible = "honeywell,mprls0025pa";
+ reg = <0>;
+ spi-max-frequency = <800000>;
+ reset-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <30 IRQ_TYPE_EDGE_RISING>;
+
+ honeywell,pressure-triplet = "0015PA";
+ honeywell,transfer-function = <1>;
+ vdd-supply = <&vcc_3v3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/infineon,dps310.yaml b/Documentation/devicetree/bindings/iio/pressure/infineon,dps310.yaml
new file mode 100644
index 000000000000..e5d1e6c48939
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/infineon,dps310.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/infineon,dps310.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon DPS310 barometric pressure and temperature sensor
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The DPS310 is a barometric pressure and temperature sensor with an I2C
+ interface.
+
+properties:
+ compatible:
+ enum:
+ - infineon,dps310
+
+ reg:
+ maxItems: 1
+
+ "#io-channel-cells":
+ const: 0
+
+ vdd-supply:
+ description:
+ Voltage supply for the chip's analog blocks.
+
+ vddio-supply:
+ description:
+ Digital voltage supply for the chip's digital blocks and I/O interface.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dps: pressure-sensor@76 {
+ compatible = "infineon,dps310";
+ reg = <0x76>;
+ #io-channel-cells = <0>;
+ vdd-supply = <&vref1>;
+ vddio-supply = <&vref2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/invensense,icp10100.yaml b/Documentation/devicetree/bindings/iio/pressure/invensense,icp10100.yaml
new file mode 100644
index 000000000000..5d980aa04bb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/invensense,icp10100.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/invensense,icp10100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: InvenSense ICP-101xx Barometric Pressure Sensors
+
+maintainers:
+ - Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
+
+description: |
+ Support for ICP-101xx family: ICP-10100, ICP-10101, ICP-10110, ICP-10111.
+ Those devices uses a simple I2C communication bus, measuring the pressure
+ in a ultra-low noise at the lowest power.
+ Datasheet: https://product.tdk.com/system/files/dam/doc/product/sensor/pressure/capacitive-pressure/data_sheet/ds-000186-icp-101xx.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - invensense,icp10101
+ - invensense,icp10110
+ - invensense,icp10111
+ - const: invensense,icp10100
+ - const: invensense,icp10100
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@63 {
+ compatible = "invensense,icp10101", "invensense,icp10100";
+ reg = <0x63>;
+ vdd-supply = <&vdd_1v8>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml b/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml
index 4f06707450bf..21e6ddb7f41e 100644
--- a/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/meas,ms5611.yaml
@@ -30,7 +30,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -52,6 +55,7 @@ examples:
compatible = "meas,ms5611";
reg = <0>;
vdd-supply = <&ldo_3v3_gnss>;
+ spi-max-frequency = <20000000>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml b/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml
index d6103be03460..886f4129c301 100644
--- a/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml
+++ b/Documentation/devicetree/bindings/iio/pressure/murata,zpa2326.yaml
@@ -12,7 +12,6 @@ maintainers:
description: |
Pressure sensor from Murata with SPI and I2C bus interfaces.
-
properties:
compatible:
const: murata,zpa2326
@@ -33,7 +32,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/pressure/rohm,bm1390.yaml b/Documentation/devicetree/bindings/iio/pressure/rohm,bm1390.yaml
new file mode 100644
index 000000000000..7c4ca6322bf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/rohm,bm1390.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/rohm,bm1390.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BM1390 pressure sensor
+
+maintainers:
+ - Matti Vaittinen <mazziesaccount@gmail.com>
+
+description:
+ BM1390GLV-Z is a pressure sensor which performs internal temperature
+ compensation for the MEMS. Pressure range is from 300 hPa to 1300 hPa
+ and sample averaging and IIR filtering is built in. Temperature
+ measurement is also supported.
+
+properties:
+ compatible:
+ const: rohm,bm1390glv-z
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure-sensor@5d {
+ compatible = "rohm,bm1390glv-z";
+ reg = <0x5d>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+ vdd-supply = <&vdd>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml b/Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml
new file mode 100644
index 000000000000..813239f6879a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/sensirion,sdp500.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/sensirion,sdp500.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: sdp500/sdp510 pressure sensor with I2C bus interface
+
+maintainers:
+ - Petar Stoykov <petar.stoykov@prodrive-technologies.com>
+
+description: |
+ Pressure sensor from Sensirion with I2C bus interface.
+ There is no software difference between sdp500 and sdp510.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: sensirion,sdp510
+ - const: sensirion,sdp500
+ - const: sensirion,sdp500
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@40 {
+ compatible = "sensirion,sdp500";
+ reg = <0x40>;
+ vdd-supply = <&foo>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
index 7fcba5d6d508..9567993ce480 100644
--- a/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/ams,as3935.yaml
@@ -10,7 +10,7 @@ maintainers:
- Matt Ranostay <matt.ranostay@konsulko.com>
description:
- This lightening distance sensor uses an I2C or SPI interface. The
+ This lightning distance sensor uses an I2C or SPI interface. The
binding currently only covers the SPI option.
properties:
@@ -49,7 +49,10 @@ required:
- spi-cpha
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
@@ -57,7 +60,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- lightning@0 {
+ lightning@0 {
compatible = "ams,as3935";
reg = <0>;
spi-max-frequency = <400000>;
diff --git a/Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml b/Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml
new file mode 100644
index 000000000000..7a83ceced11c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/awinic,aw96103.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/awinic,aw96103.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic's AW96103 capacitive proximity sensor and similar
+
+maintainers:
+ - Wang Shuaijie <wangshuaijie@awinic.com>
+
+description: |
+ Awinic's AW96103/AW96105 proximity sensor.
+ The specific absorption rate (SAR) is a metric that measures
+ the degree of absorption of electromagnetic radiation emitted by
+ wireless devices, such as mobile phones and tablets, by human tissue.
+ In mobile phone applications, the proximity sensor is primarily
+ used to detect the proximity of the human body to the phone. When the
+ phone approaches the human body, it will actively reduce the transmit
+ power of the antenna to keep the SAR within a safe range. Therefore,
+ we also refer to the proximity sensor as a SAR sensor.
+
+properties:
+ compatible:
+ enum:
+ - awinic,aw96103
+ - awinic,aw96105
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Generated by the device to announce that a close/far
+ proximity event has happened.
+ maxItems: 1
+
+ vcc-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ proximity@12 {
+ compatible = "awinic,aw96103";
+ reg = <0x12>;
+ interrupt-parent = <&gpio>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ vcc-supply = <&pp1800_prox>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
index 00e3b59641d2..d4e09d2dcd21 100644
--- a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
diff --git a/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml b/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml
new file mode 100644
index 000000000000..67f5389ece67
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/murata,irsd200.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/murata,irsd200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Murata IRS-D200 PIR sensor
+
+maintainers:
+ - Waqar Hameed <waqar.hameed@axis.com>
+
+description:
+ PIR sensor for human detection.
+
+properties:
+ compatible:
+ const: murata,irsd200
+
+ reg:
+ items:
+ - enum:
+ - 0x48
+ - 0x49
+ description: |
+ When the AD pin is connected to GND, the slave address is 0x48.
+ When the AD pin is connected to VDD, the slave address is 0x49.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Type should be IRQ_TYPE_EDGE_RISING.
+
+ vdd-supply:
+ description:
+ 3.3 V supply voltage.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ proximity@48 {
+ compatible = "murata,irsd200";
+ reg = <0x48>;
+ interrupts = <24 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <&regulator_3v3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/nicera,d3323aa.yaml b/Documentation/devicetree/bindings/iio/proximity/nicera,d3323aa.yaml
new file mode 100644
index 000000000000..65d9b44fcd5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/nicera,d3323aa.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/nicera,d3323aa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nicera D3-323-AA PIR sensor
+
+maintainers:
+ - Waqar Hameed <waqar.hameed@axis.com>
+
+description: |
+ PIR sensor for human detection.
+ Datasheet: https://www.endrich.com/Datenbl%C3%A4tter/Sensoren/D3-323-AA_e.pdf
+
+properties:
+ compatible:
+ const: nicera,d3323aa
+
+ vdd-supply:
+ description:
+ Supply voltage (1.8 to 5.5 V).
+
+ vout-clk-gpios:
+ maxItems: 1
+ description:
+ GPIO for clock and detection.
+ After reset, the device signals with two falling edges on this pin that it
+ is ready for configuration (within 1.2 s).
+ During configuration, it is used as clock for data reading and writing (on
+ data-gpios).
+ After all this, when device is in operational mode, it signals on this pin
+ for any detections.
+
+ data-gpios:
+ maxItems: 1
+ description:
+ GPIO for data reading and writing. This is denoted "DO (SI)" in datasheet.
+ During configuration, this pin is used for writing and reading
+ configuration data (together with vout-clk-gpios as clock).
+ After this, during operational mode, the device will output serial data on
+ this GPIO.
+
+required:
+ - compatible
+ - vdd-supply
+ - vout-clk-gpios
+ - data-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ proximity {
+ compatible = "nicera,d3323aa";
+ vdd-supply = <&regulator_3v3>;
+ vout-clk-gpios = <&gpio 78 GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio 76 GPIO_ACTIVE_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
index 5de0bb2180e6..775555d147bf 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
@@ -15,6 +15,9 @@ description: |
Specifications about the devices can be found at:
https://www.semtech.com/products/smart-sensing/sar-sensors/sx9310
+allOf:
+ - $ref: /schemas/iio/iio.yaml#
+
properties:
compatible:
enum:
@@ -102,7 +105,7 @@ required:
- reg
- "#io-channel-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
index b3aa2ebf9661..8fed45ee557b 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml
@@ -13,6 +13,9 @@ maintainers:
description: |
Semtech's SX9324 proximity sensor.
+allOf:
+ - $ref: /schemas/iio/iio.yaml#
+
properties:
compatible:
const: semtech,sx9324
@@ -75,7 +78,6 @@ properties:
minItems: 3
maxItems: 3
-
semtech,ph01-resolution:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [8, 16, 32, 64, 128, 256, 512, 1024]
@@ -167,7 +169,7 @@ required:
- reg
- "#io-channel-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
index f088c5d2be99..ad0bb44f41b6 100644
--- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
@@ -36,7 +36,7 @@ properties:
const: 1
semtech,resolution:
- $ref: /schemas/types.yaml#/definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [8, 16, 32, 64, 128, 256, 512, 1024]
description:
Capacitance measurement resolution. For both phases, "reference" and
diff --git a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
new file mode 100644
index 000000000000..64ce8bc8bd36
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/tyhx,hx9023s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TYHX HX9023S capacitive proximity sensor
+
+maintainers:
+ - Yasin Lee <yasin.lee.x@gmail.com>
+
+description: |
+ TYHX HX9023S proximity sensor. Datasheet can be found here:
+ http://www.tianyihexin.com/ueditor/php/upload/file/20240614/1718336303992081.pdf
+
+properties:
+ compatible:
+ const: tyhx,hx9023s
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Generated by device to announce preceding read request has finished
+ and data is available or that a close/far proximity event has happened.
+ maxItems: 1
+
+ vdd-supply: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@[0-4]$":
+ $ref: /schemas/iio/adc/adc.yaml
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 4
+ description: The channel number.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ proximity@2a {
+ compatible = "tyhx,hx9023s";
+ reg = <0x2a>;
+ interrupt-parent = <&pio>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&pp1800_prox>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ single-channel = <0>;
+ };
+ channel@1 {
+ reg = <1>;
+ single-channel = <1>;
+ };
+ channel@2 {
+ reg = <2>;
+ single-channel = <2>;
+ };
+ channel@3 {
+ reg = <3>;
+ diff-channels = <1 0>;
+ };
+ channel@4 {
+ reg = <4>;
+ diff-channels = <2 0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml b/Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml
new file mode 100644
index 000000000000..8980b3cd8337
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/resolver/adi,ad2s1210.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD2S1210 Resolver-to-Digital Converter
+
+maintainers:
+ - Michael Hennerich <michael.hennerich@analog.com>
+
+description: |
+ The AD2S1210 is a complete 10-bit to 16-bit resolution tracking
+ resolver-to-digital converter, integrating an on-board programmable
+ sinusoidal oscillator that provides sine wave excitation for
+ resolvers.
+
+ The AD2S1210 allows the user to read the angular position or the
+ angular velocity data directly from the parallel outputs or through
+ the serial interface.
+
+ The mode of operation of the communication channel (parallel or serial) is
+ selected by the A0 and A1 input pins. In normal mode, data is latched by
+ toggling the SAMPLE line and can then be read directly. In configuration mode,
+ data is read or written using a register access scheme (address byte with
+ read/write flag and data byte).
+
+ A1 A0 Result
+ 0 0 Normal mode - position output
+ 0 1 Normal mode - velocity output
+ 1 0 Reserved
+ 1 1 Configuration mode
+
+ In normal mode, the resolution of the digital output is selected using
+ the RES0 and RES1 input pins. In configuration mode, the resolution is
+ selected by setting the RES0 and RES1 bits in the control register.
+
+ RES1 RES0 Resolution (Bits)
+ 0 0 10
+ 0 1 12
+ 1 0 14
+ 1 1 16
+
+ Note on SPI connections: The CS line on the AD2S1210 should hard-wired to
+ logic low and the WR/FSYNC line on the AD2S1210 should be connected to the
+ SPI CSn output of the SPI controller.
+
+ Datasheet:
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad2s1210.pdf
+
+properties:
+ compatible:
+ const: adi,ad2s1210
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 25000000
+
+ spi-cpha: true
+
+ avdd-supply:
+ description:
+ A 4.75 to 5.25 V regulator that powers the Analog Supply Voltage (AVDD)
+ pin.
+
+ dvdd-supply:
+ description:
+ A 4.75 to 5.25 V regulator that powers the Digital Supply Voltage (DVDD)
+ pin.
+
+ vdrive-supply:
+ description:
+ A 2.3 to 5.25 V regulator that powers the Logic Power Supply Input
+ (VDrive) pin.
+
+ clocks:
+ maxItems: 1
+ description: External oscillator clock (CLKIN).
+
+ reset-gpios:
+ description:
+ GPIO connected to the /RESET pin. As the line needs to be low for the
+ reset to be active, it should be configured as GPIO_ACTIVE_LOW.
+ maxItems: 1
+
+ sample-gpios:
+ description:
+ GPIO connected to the /SAMPLE pin. As the line needs to be low to trigger
+ a sample, it should be configured as GPIO_ACTIVE_LOW.
+ maxItems: 1
+
+ mode-gpios:
+ description:
+ GPIO lines connected to the A0 and A1 pins. These pins select the data
+ transfer mode.
+ minItems: 2
+ maxItems: 2
+
+ resolution-gpios:
+ description:
+ GPIO lines connected to the RES0 and RES1 pins. These pins select the
+ resolution of the digital output. If omitted, it is assumed that the
+ RES0 and RES1 pins are hard-wired to match the assigned-resolution-bits
+ property.
+ minItems: 2
+ maxItems: 2
+
+ fault-gpios:
+ description:
+ GPIO lines connected to the LOT and DOS pins. These pins combined indicate
+ the type of fault present, if any. As these pins a pulled low to indicate
+ a fault condition, they should be configured as GPIO_ACTIVE_LOW.
+ minItems: 2
+ maxItems: 2
+
+ adi,fixed-mode:
+ description:
+ This is used to indicate the selected mode if A0 and A1 are hard-wired
+ instead of connected to GPIOS (i.e. mode-gpios is omitted).
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [config, velocity, position]
+
+ assigned-resolution-bits:
+ description:
+ Resolution of the digital output required by the application. This
+ determines the precision of the angle and/or the maximum speed that can
+ be measured. If resolution-gpios is omitted, it is assumed that RES0 and
+ RES1 are hard-wired to match this value.
+ enum: [10, 12, 14, 16]
+
+required:
+ - compatible
+ - reg
+ - spi-cpha
+ - avdd-supply
+ - dvdd-supply
+ - vdrive-supply
+ - clocks
+ - sample-gpios
+ - assigned-resolution-bits
+
+oneOf:
+ - required:
+ - mode-gpios
+ - required:
+ - adi,fixed-mode
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ resolver@0 {
+ compatible = "adi,ad2s1210";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ spi-cpha;
+ avdd-supply = <&avdd_regulator>;
+ dvdd-supply = <&dvdd_regulator>;
+ vdrive-supply = <&vdrive_regulator>;
+ clocks = <&ext_osc>;
+ sample-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;
+ mode-gpios = <&gpio0 86 0>, <&gpio0 87 0>;
+ resolution-gpios = <&gpio0 88 0>, <&gpio0 89 0>;
+ assigned-resolution-bits = <16>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml b/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml
index 81e4bdfc17c4..b24e5a202a48 100644
--- a/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml
+++ b/Documentation/devicetree/bindings/iio/resolver/adi,ad2s90.yaml
@@ -33,8 +33,6 @@ properties:
spi-cpha: true
-additionalProperties: false
-
required:
- compatible
- reg
@@ -43,6 +41,11 @@ dependencies:
spi-cpol: [ spi-cpha ]
spi-cpha: [ spi-cpol ]
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml b/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml
index a88b3b14d6bd..dd2ae2bd1ad7 100644
--- a/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml
+++ b/Documentation/devicetree/bindings/iio/samsung,sensorhub-rinato.yaml
@@ -40,10 +40,6 @@ properties:
description:
Reset the sensorhub.
- spi-max-frequency: true
-
-additionalProperties: false
-
required:
- compatible
- reg
@@ -52,6 +48,11 @@ required:
- mcu-ap-gpios
- mcu-reset-gpios
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
examples:
- |
spi {
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
index fcb2902683c7..e955eb8e8797 100644
--- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -11,9 +11,6 @@ description: The STMicroelectronics sensor devices are pretty straight-forward
what type of sensor it is.
Note that whilst this covers many STMicro MEMs sensors, some more complex
IMUs need their own bindings.
- The STMicroelectronics sensor devices are pretty straight-forward I2C or
- SPI devices, all sharing the same device tree descriptions no matter what
- type of sensor it is.
maintainers:
- Denis Ciocca <denis.ciocca@st.com>
@@ -29,6 +26,7 @@ properties:
- st,lis2dw12
- st,lis2hh12
- st,lis2dh12-accel
+ - st,lis2ds12
- st,lis302dl
- st,lis331dl-accel
- st,lis331dlh-accel
@@ -39,6 +37,7 @@ properties:
- st,lis3lv02dl-accel
- st,lng2dm-accel
- st,lsm303agr-accel
+ - st,lsm303c-accel
- st,lsm303dl-accel
- st,lsm303dlh-accel
- st,lsm303dlhc-accel
@@ -47,6 +46,9 @@ properties:
- st,lsm330d-accel
- st,lsm330dl-accel
- st,lsm330dlc-accel
+ - items:
+ - const: st,iis328dq
+ - const: st,h3lis331dl-accel
- description: Silan Accelerometers
enum:
- silan,sc7a20
@@ -63,9 +65,11 @@ properties:
- st,lsm9ds0-gyro
- description: STMicroelectronics Magnetometers
enum:
+ - st,iis2mdc
- st,lis2mdl
- st,lis3mdl-magn
- st,lsm303agr-magn
+ - st,lsm303c-magn
- st,lsm303dlh-magn
- st,lsm303dlhc-magn
- st,lsm303dlm-magn
@@ -73,6 +77,7 @@ properties:
- description: STMicroelectronics Pressure Sensors
enum:
- st,lps001wp-press
+ - st,lps22df
- st,lps22hb-press
- st,lps22hh
- st,lps25h-press
@@ -81,6 +86,7 @@ properties:
- st,lps35hw
- description: IMUs
enum:
+ - st,lsm303d-imu
- st,lsm9ds0-imu
- description: Deprecated bindings
enum:
@@ -93,7 +99,7 @@ properties:
interrupts:
description: interrupt line(s) connected to the DRDY line(s) and/or the
- Intertial interrupt lines INT1 and INT2 if these exist. This means up to
+ Inertial interrupt lines INT1 and INT2 if these exist. This means up to
three interrupts, and the DRDY must be the first one if it exists on
the package. The trigger edge of the interrupts is sometimes software
configurable in the hardware so the operating system should parse this
@@ -141,6 +147,7 @@ allOf:
- st,lis2mdl
- st,lis3l02dq
- st,lis3lv02dl-accel
+ - st,lps22df
- st,lps22hb-press
- st,lps22hh
- st,lps25h-press
diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
index 722781aa4697..a22725f7619b 100644
--- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
@@ -4,19 +4,51 @@
$id: http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices LTC2983 Multi-sensor Temperature system
+title: Analog Devices LTC2983, LTC2986, LTM2985 Multi-sensor Temperature system
maintainers:
- Nuno Sá <nuno.sa@analog.com>
description: |
- Analog Devices LTC2983 Multi-Sensor Digital Temperature Measurement System
+ Analog Devices LTC2983, LTC2984, LTC2986, LTM2985 Multi-Sensor Digital
+ Temperature Measurement Systems
+
https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/2984fb.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/29861fa.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltm2985.pdf
+
+$defs:
+ sensor-node:
+ type: object
+ description: Sensor node common constraints
+
+ properties:
+ reg:
+ description:
+ Channel number. Connects the sensor to the channel with this number
+ of the device.
+ minimum: 1
+ maximum: 20
+
+ adi,sensor-type:
+ description: Type of sensor connected to the device.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - reg
+ - adi,sensor-type
properties:
compatible:
- enum:
- - adi,ltc2983
+ oneOf:
+ - enum:
+ - adi,ltc2983
+ - adi,ltc2986
+ - adi,ltm2985
+ - items:
+ - const: adi,ltc2984
+ - const: adi,ltc2983
reg:
maxItems: 1
@@ -24,27 +56,29 @@ properties:
interrupts:
maxItems: 1
+ vdd-supply: true
+
adi,mux-delay-config-us:
- description:
- The LTC2983 performs 2 or 3 internal conversion cycles per temperature
- result. Each conversion cycle is performed with different excitation and
- input multiplexer configurations. Prior to each conversion, these
- excitation circuits and input switch configurations are changed and an
- internal 1ms delay ensures settling prior to the conversion cycle in most
- cases. An extra delay can be configured using this property. The value is
- rounded to nearest 100us.
+ description: |
+ Extra delay prior to each conversion, in addition to the internal 1ms
+ delay, for the multiplexer to switch input configurations and
+ excitation values.
+
+ This property is supposed to be in microseconds, but to maintain
+ compatibility, this value will be multiplied by 100 before usage.
maximum: 255
+ default: 0
adi,filter-notch-freq:
description:
- Set's the default setting of the digital filter. The default is
- simultaneous 50/60Hz rejection.
+ Notch frequency of the digital filter.
0 - 50/60Hz rejection
1 - 60Hz rejection
2 - 50Hz rejection
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 2
+ default: 0
'#address-cells':
const: 1
@@ -53,30 +87,11 @@ properties:
const: 0
patternProperties:
- "@([1-9]|1[0-9]|20)$":
- type: object
-
- properties:
- reg:
- description:
- The channel number. It can be connected to one of the 20 channels of
- the device.
- minimum: 1
- maximum: 20
-
- adi,sensor-type:
- description: Identifies the type of sensor connected to the device.
- $ref: /schemas/types.yaml#/definitions/uint32
-
- required:
- - reg
- - adi,sensor-type
+ '^thermocouple@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
- "^thermocouple@":
- type: object
- description:
- Represents a thermocouple sensor which is connected to one of the device
- channels.
+ description: Thermocouple sensor.
properties:
adi,sensor-type:
@@ -95,86 +110,90 @@ patternProperties:
maximum: 9
adi,single-ended:
- description:
- Boolean property which set's the thermocouple as single-ended.
+ description: Whether the sensor is single-ended.
type: boolean
adi,sensor-oc-current-microamp:
- description:
- This property set's the pulsed current value applied during
- open-circuit detect.
+ description: Pulsed current value applied during open-circuit detect.
enum: [10, 100, 500, 1000]
+ default: 10
adi,cold-junction-handle:
description:
- Phandle which points to a sensor object responsible for measuring
- the thermocouple cold junction temperature.
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ Sensor responsible for measuring the thermocouple cold junction
+ temperature.
+ $ref: /schemas/types.yaml#/definitions/phandle
adi,custom-thermocouple:
description:
- This is a table, where each entry should be a pair of
- voltage(mv)-temperature(K). The entries must be given in nv and uK
- so that, the original values must be multiplied by 1000000. For
- more details look at table 69 and 70.
- Note should be signed, but dtc doesn't currently maintain the
- sign.
- $ref: /schemas/types.yaml#/definitions/uint64-matrix
+ Used for digitizing custom thermocouples.
+ See Page 59 of the datasheet.
+ $ref: /schemas/types.yaml#/definitions/int64-matrix
minItems: 3
maxItems: 64
items:
- minItems: 2
- maxItems: 2
+ items:
+ - description: Voltage point in nV, signed.
+ - description: Temperature point in uK.
- "^diode@":
- type: object
- description:
- Represents a diode sensor which is connected to one of the device
- channels.
+ allOf:
+ - if:
+ properties:
+ adi,sensor-type:
+ const: 9
+ then:
+ required:
+ - adi,custom-thermocouple
+
+ '^diode@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+
+ description: Diode sensor.
properties:
adi,sensor-type:
- description: Identifies the sensor as a diode.
+ description: Sensor type for diodes.
$ref: /schemas/types.yaml#/definitions/uint32
const: 28
adi,single-ended:
- description: Boolean property which set's the diode as single-ended.
+ description: Whether the sensor is single-ended.
type: boolean
adi,three-conversion-cycles:
description:
- Boolean property which set's three conversion cycles removing
- parasitic resistance effects between the LTC2983 and the diode.
+ Whether to use three conversion cycles to remove parasitic
+ resistance between the device and the diode.
type: boolean
adi,average-on:
description:
- Boolean property which enables a running average of the diode
- temperature reading. This reduces the noise when the diode is used
- as a cold junction temperature element on an isothermal block
- where temperatures change slowly.
+ Whether to use a running average of the diode temperature
+ reading to reduce the noise when the diode is used as a cold
+ junction temperature element on an isothermal block where
+ temperatures change slowly.
type: boolean
adi,excitation-current-microamp:
description:
- This property controls the magnitude of the excitation current
- applied to the diode. Depending on the number of conversions
- cycles, this property will assume different predefined values on
- each cycle. Just set the value of the first cycle (1l).
+ Magnitude of the 1l excitation current applied to the diode.
+ 4l excitation current will be 4 times this value, and 8l
+ excitation current will be 8 times value.
enum: [10, 20, 40, 80]
+ default: 10
adi,ideal-factor-value:
description:
- This property sets the diode ideality factor. The real value must
- be multiplied by 1000000 to remove the fractional part. For more
- information look at table 20 of the datasheet.
+ Diode ideality factor.
+ Set this property to 1000000 times the real value.
$ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
- "^rtd@":
- type: object
- description:
- Represents a rtd sensor which is connected to one of the device channels.
+ '^rtd@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: RTD sensor.
properties:
reg:
@@ -197,68 +216,83 @@ patternProperties:
maximum: 18
adi,rsense-handle:
- description:
- Phandle pointing to a rsense object associated with this RTD.
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ description: Associated sense resistor sensor.
+ $ref: /schemas/types.yaml#/definitions/phandle
adi,number-of-wires:
description:
- Identifies the number of wires used by the RTD. Setting this
- property to 5 means 4 wires with Kelvin Rsense.
+ Number of wires used by the RTD.
+ 5 means 4 wires with Kelvin sense resistor.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [2, 3, 4, 5]
+ default: 2
adi,rsense-share:
description:
- Boolean property which enables Rsense sharing, where one sense
- resistor is used for multiple 2-, 3-, and/or 4-wire RTDs.
- type: boolean
-
- adi,current-rotate:
- description:
- Boolean property which enables excitation current rotation to
- automatically remove parasitic thermocouple effects. Note that
- this property is not allowed for 2- and 3-wire RTDs.
+ Whether to enable sense resistor sharing, where one sense
+ resistor is used by multiple sensors.
type: boolean
adi,excitation-current-microamp:
- description:
- This property controls the magnitude of the excitation current
- applied to the RTD.
+ description: Excitation current applied to the RTD.
enum: [5, 10, 25, 50, 100, 250, 500, 1000]
+ default: 5
adi,rtd-curve:
- description:
- This property set the RTD curve used and the corresponding
- Callendar-VanDusen constants. Look at table 30 of the datasheet.
+ description: |
+ RTD curve and the corresponding Callendar-VanDusen constants.
+ 0 - European
+ 1 - American
+ 2 - Japanese
+ 3 - ITS-90
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
+ default: 0
adi,custom-rtd:
description:
- This is a table, where each entry should be a pair of
- resistance(ohm)-temperature(K). The entries added here are in uohm
- and uK. For more details values look at table 74 and 75.
+ Used for digitizing custom RTDs.
+ See Page 62 of the datasheet.
$ref: /schemas/types.yaml#/definitions/uint64-matrix
+ minItems: 3
+ maxItems: 64
items:
- minItems: 3
- maxItems: 64
items:
- minItems: 2
- maxItems: 2
+ - description: Resistance point in uOhms.
+ - description: Temperature point in uK.
required:
- adi,rsense-handle
- dependencies:
- adi,current-rotate: [ "adi,rsense-share" ]
-
- "^thermistor@":
- type: object
- description:
- Represents a thermistor sensor which is connected to one of the device
- channels.
+ allOf:
+ - if:
+ properties:
+ adi,number-of-wires:
+ const: 4
+ then:
+ properties:
+ adi,current-rotate:
+ description:
+ Whether to enable excitation current rotation to automatically
+ remove parasitic thermocouple effects.
+ type: boolean
+
+ dependencies:
+ adi,current-rotate: [ 'adi,rsense-share' ]
+
+ - if:
+ properties:
+ adi,sensor-type:
+ const: 18
+ then:
+ required:
+ - adi,custom-rtd
+
+ '^thermistor@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: Thermistor sensor.
properties:
adi,sensor-type:
@@ -277,87 +311,135 @@ patternProperties:
maximum: 27
adi,rsense-handle:
- description:
- Phandle pointing to a rsense object associated with this
- thermistor.
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ description: Associated sense resistor sensor.
+ $ref: /schemas/types.yaml#/definitions/phandle
adi,single-ended:
- description:
- Boolean property which set's the thermistor as single-ended.
+ description: Whether the sensor is single-ended.
type: boolean
adi,rsense-share:
description:
- Boolean property which enables Rsense sharing, where one sense
- resistor is used for multiple thermistors. Note that this property
- is ignored if adi,single-ended is set.
+ Whether to enable sense resistor sharing, where one sense
+ resistor is used by multiple sensors.
type: boolean
adi,current-rotate:
description:
- Boolean property which enables excitation current rotation to
- automatically remove parasitic thermocouple effects.
+ Whether to enable excitation current rotation to automatically
+ remove parasitic thermocouple effects.
type: boolean
adi,excitation-current-nanoamp:
description:
- This property controls the magnitude of the excitation current
- applied to the thermistor. Value 0 set's the sensor in auto-range
- mode.
- $ref: /schemas/types.yaml#/definitions/uint32
+ Excitation current applied to the thermistor.
+ 0 sets the sensor in auto-range mode.
enum: [0, 250, 500, 1000, 5000, 10000, 25000, 50000, 100000, 250000,
500000, 1000000]
+ default: 0
adi,custom-thermistor:
description:
- This is a table, where each entry should be a pair of
- resistance(ohm)-temperature(K). The entries added here are in uohm
- and uK only for custom thermistors. For more details look at table
- 78 and 79.
+ Used for digitizing custom thermistors.
+ See Page 65 of the datasheet.
$ref: /schemas/types.yaml#/definitions/uint64-matrix
minItems: 3
maxItems: 64
items:
- minItems: 2
- maxItems: 2
+ items:
+ - description: Resistance point in uOhms.
+ - description: Temperature point in uK.
adi,custom-steinhart:
description:
- Steinhart-Hart coefficients are also supported and can
- be programmed into the device memory using this property. For
- Steinhart sensors the coefficients are given in the raw
- format. Look at table 82 for more information.
+ Steinhart-Hart coefficients in raw format, used for digitizing
+ custom thermistors.
+ See Page 68 of the datasheet.
$ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- minItems: 6
- maxItems: 6
+ minItems: 6
+ maxItems: 6
required:
- adi,rsense-handle
dependencies:
- adi,current-rotate: [ "adi,rsense-share" ]
-
- "^adc@":
- type: object
- description: Represents a channel which is being used as a direct adc.
+ adi,current-rotate: [ 'adi,rsense-share' ]
+
+ allOf:
+ - if:
+ properties:
+ adi,sensor-type:
+ const: 26
+ then:
+ properties:
+ adi,excitation-current-nanoamp:
+ enum: [250, 500, 1000, 5000, 10000, 25000, 50000, 100000,
+ 250000, 500000, 1000000]
+ default: 1000
+ required:
+ - adi,custom-steinhart
+ - if:
+ properties:
+ adi,sensor-type:
+ const: 27
+ then:
+ properties:
+ adi,excitation-current-nanoamp:
+ enum: [250, 500, 1000, 5000, 10000, 25000, 50000, 100000,
+ 250000, 500000, 1000000]
+ default: 1000
+ required:
+ - adi,custom-thermistor
+
+ '^adc@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: Direct ADC sensor.
properties:
adi,sensor-type:
- description: Identifies the sensor as a direct adc.
+ description: Sensor type for direct ADC sensors.
$ref: /schemas/types.yaml#/definitions/uint32
const: 30
adi,single-ended:
- description: Boolean property which set's the adc as single-ended.
+ description: Whether the sensor is single-ended.
type: boolean
- "^rsense@":
- type: object
- description:
- Represents a rsense which is connected to one of the device channels.
- Rsense are used by thermistors and RTD's.
+ '^temp@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: Active analog temperature sensor.
+
+ properties:
+ adi,sensor-type:
+ description: Sensor type for active analog temperature sensors.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ const: 31
+
+ adi,single-ended:
+ description: Whether the sensor is single-ended.
+ type: boolean
+
+ adi,custom-temp:
+ description:
+ Used for digitizing active analog temperature sensors.
+ See Page 67 of the LTM2985 datasheet.
+ $ref: /schemas/types.yaml#/definitions/uint64-matrix
+ minItems: 3
+ maxItems: 64
+ items:
+ items:
+ - description: Voltage point in nV, signed.
+ - description: Temperature point in uK.
+
+ required:
+ - adi,custom-temp
+
+ '^rsense@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: Sense resistor sensor.
properties:
reg:
@@ -365,14 +447,12 @@ patternProperties:
maximum: 20
adi,sensor-type:
- description: Identifies the sensor as a rsense.
+ description: Sensor type sense resistor sensors.
$ref: /schemas/types.yaml#/definitions/uint32
const: 29
adi,rsense-val-milli-ohms:
- description:
- Sets the value of the sense resistor. Look at table 20 of the
- datasheet for information.
+ description: Value of the sense resistor.
required:
- adi,rsense-val-milli-ohms
@@ -381,9 +461,22 @@ required:
- compatible
- reg
- interrupts
+ - vdd-supply
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,ltc2983
+ - adi,ltc2984
+ then:
+ patternProperties:
+ '^temp@': false
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
@@ -391,76 +484,76 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- sensor_ltc2983: ltc2983@0 {
- compatible = "adi,ltc2983";
- reg = <0>;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- interrupts = <20 IRQ_TYPE_EDGE_RISING>;
- interrupt-parent = <&gpio>;
-
- thermocouple@18 {
- reg = <18>;
- adi,sensor-type = <8>; //Type B
- adi,sensor-oc-current-microamp = <10>;
- adi,cold-junction-handle = <&diode5>;
- };
-
- diode5: diode@5 {
- reg = <5>;
- adi,sensor-type = <28>;
- };
-
- rsense2: rsense@2 {
- reg = <2>;
- adi,sensor-type = <29>;
- adi,rsense-val-milli-ohms = <1200000>; //1.2Kohms
- };
-
- rtd@14 {
- reg = <14>;
- adi,sensor-type = <15>; //PT1000
- /*2-wire, internal gnd, no current rotation*/
- adi,number-of-wires = <2>;
- adi,rsense-share;
- adi,excitation-current-microamp = <500>;
- adi,rsense-handle = <&rsense2>;
- };
-
- adc@10 {
- reg = <10>;
- adi,sensor-type = <30>;
- adi,single-ended;
- };
-
- thermistor@12 {
- reg = <12>;
- adi,sensor-type = <26>; //Steinhart
- adi,rsense-handle = <&rsense2>;
- adi,custom-steinhart = <0x00F371EC 0x12345678
- 0x2C0F8733 0x10018C66 0xA0FEACCD
- 0x90021D99>; //6 entries
- };
-
- thermocouple@20 {
- reg = <20>;
- adi,sensor-type = <9>; //custom thermocouple
- adi,single-ended;
- adi,custom-thermocouple =
- /bits/ 64 <(-50220000) 0>,
- /bits/ 64 <(-30200000) 99100000>,
- /bits/ 64 <(-5300000) 135400000>,
- /bits/ 64 <0 273150000>,
- /bits/ 64 <40200000 361200000>,
- /bits/ 64 <55300000 522100000>,
- /bits/ 64 <88300000 720300000>,
- /bits/ 64 <132200000 811200000>,
- /bits/ 64 <188700000 922500000>,
- /bits/ 64 <460400000 1000000000>; //10 pairs
- };
-
+ temperature-sensor@0 {
+ compatible = "adi,ltc2983";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdd-supply = <&supply>;
+ interrupts = <20 IRQ_TYPE_EDGE_RISING>;
+ interrupt-parent = <&gpio>;
+
+ thermocouple@18 {
+ reg = <18>;
+ adi,sensor-type = <8>; //Type B
+ adi,sensor-oc-current-microamp = <10>;
+ adi,cold-junction-handle = <&diode5>;
+ };
+
+ diode5: diode@5 {
+ reg = <5>;
+ adi,sensor-type = <28>;
+ };
+
+ rsense2: rsense@2 {
+ reg = <2>;
+ adi,sensor-type = <29>;
+ adi,rsense-val-milli-ohms = <1200000>; //1.2Kohms
+ };
+
+ rtd@14 {
+ reg = <14>;
+ adi,sensor-type = <15>; //PT1000
+ /*2-wire, internal gnd, no current rotation*/
+ adi,number-of-wires = <2>;
+ adi,rsense-share;
+ adi,excitation-current-microamp = <500>;
+ adi,rsense-handle = <&rsense2>;
+ };
+
+ adc@10 {
+ reg = <10>;
+ adi,sensor-type = <30>;
+ adi,single-ended;
+ };
+
+ thermistor@12 {
+ reg = <12>;
+ adi,sensor-type = <26>; //Steinhart
+ adi,rsense-handle = <&rsense2>;
+ adi,custom-steinhart = <0x00f371ec 0x12345678
+ 0x2c0f8733 0x10018c66 0xa0feaccd
+ 0x90021d99>; //6 entries
+ };
+
+ thermocouple@20 {
+ reg = <20>;
+ adi,sensor-type = <9>; //custom thermocouple
+ adi,single-ended;
+ adi,custom-thermocouple =
+ /bits/ 64 <(-50220000) 0>,
+ /bits/ 64 <(-30200000) 99100000>,
+ /bits/ 64 <(-5300000) 135400000>,
+ /bits/ 64 <0 273150000>,
+ /bits/ 64 <40200000 361200000>,
+ /bits/ 64 <55300000 522100000>,
+ /bits/ 64 <88300000 720300000>,
+ /bits/ 64 <132200000 811200000>,
+ /bits/ 64 <188700000 922500000>,
+ /bits/ 64 <460400000 1000000000>; //10 pairs
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml
index 9969bac66aa1..0805ed7e2113 100644
--- a/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31855k.yaml
@@ -32,7 +32,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
spi-cpha: true
required:
@@ -40,6 +39,7 @@ required:
- reg
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@@ -53,7 +53,7 @@ allOf:
properties:
spi-cpha: false
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml
index 873b34766676..228a94165487 100644
--- a/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31856.yaml
@@ -19,7 +19,6 @@ properties:
reg:
maxItems: 1
- spi-max-frequency: true
spi-cpha: true
thermocouple-type:
@@ -34,7 +33,10 @@ required:
- reg
- spi-cpha
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml
index aafb33b16549..7c0c6ab6fc69 100644
--- a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml
@@ -25,7 +25,6 @@ properties:
enables 3-wire RTD connection. Else 2-wire or 4-wire RTD connection.
type: boolean
- spi-max-frequency: true
spi-cpha: true
required:
@@ -33,20 +32,23 @@ required:
- reg
- spi-cpha
-additionalProperties: false
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
-
- temp_sensor@0 {
- compatible = "maxim,max31865";
- reg = <0>;
- spi-max-frequency = <400000>;
- spi-cpha;
- maxim,3-wire;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@0 {
+ compatible = "maxim,max31865";
+ reg = <0>;
+ spi-max-frequency = <400000>;
+ spi-cpha;
+ maxim,3-wire;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
index d6965a0c1cf3..654d31f65d36 100644
--- a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90614.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90614.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Melexis MLX90614 contactless IR temperature sensor
+title: Melexis MLX90614/MLX90615 contactless IR temperature sensor
maintainers:
- Peter Meerwald <pmeerw@pmeerw.net>
@@ -15,7 +15,9 @@ description: |
properties:
compatible:
- const: melexis,mlx90614
+ enum:
+ - melexis,mlx90614
+ - melexis,mlx90615
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml
index b547ddcd544a..03bb5d4fa8b5 100644
--- a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90632.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90632.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Melexis MLX90632 contactless Infra Red temperature sensor
+title: Melexis MLX90632 and MLX90635 contactless Infra Red temperature sensor
maintainers:
- Crt Mori <cmo@melexis.com>
@@ -27,14 +27,32 @@ description: |
Since measured object emissivity effects Infra Red energy emitted,
emissivity should be set before requesting the object temperature.
+ https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90635
+
+ MLX90635 is most suitable for consumer applications where
+ measured object temperature is in range between -20 to 100 degrees
+ Celsius with relative error of measurement 2 degree Celsius in
+ object temperature range for industrial applications, while just 0.2
+ degree Celsius for human body measurement applications. Since it can
+ operate and measure ambient temperature in range of -20 to 85 degrees
+ Celsius it is suitable also for outdoor use.
+
+ Since measured object emissivity effects Infra Red energy emitted,
+ emissivity should be set before requesting the object temperature.
+
properties:
compatible:
- const: melexis,mlx90632
+ enum:
+ - melexis,mlx90632
+ - melexis,mlx90635
reg:
maxItems: 1
description: Default is 0x3a, but can be reprogrammed.
+ vdd-supply:
+ description: provide VDD power to the sensor.
+
required:
- compatible
- reg
@@ -50,6 +68,7 @@ examples:
temp-sensor@3a {
compatible = "melexis,mlx90632";
reg = <0x3a>;
+ vdd-supply = <&ldo4_reg>;
};
};
...
diff --git a/Documentation/devicetree/bindings/iio/temperature/microchip,mcp9600.yaml b/Documentation/devicetree/bindings/iio/temperature/microchip,mcp9600.yaml
new file mode 100644
index 000000000000..effe3bee495d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/microchip,mcp9600.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/microchip,mcp9600.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP9600 and similar thermocouple EMF converters
+
+maintainers:
+ - Andrew Hepp <andrew.hepp@ahepp.dev>
+
+description:
+ https://ww1.microchip.com/downloads/en/DeviceDoc/MCP960X-Data-Sheet-20005426.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,mcp9600
+ - items:
+ - const: microchip,mcp9601
+ - const: microchip,mcp9600
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 6
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 6
+ items:
+ enum:
+ - open-circuit
+ - short-circuit
+ - alert1
+ - alert2
+ - alert3
+ - alert4
+
+ thermocouple-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 3
+ description:
+ Type of thermocouple (THERMOCOUPLE_TYPE_K if omitted).
+ Use defines in dt-bindings/iio/temperature/thermocouple.h.
+ Supported types are B, E, J, K, N, R, S, T.
+
+ microchip,vsense:
+ type: boolean
+ description:
+ This flag indicates that the chip has been wired with VSENSE to
+ enable open and short circuit detect.
+
+ vdd-supply: true
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: microchip,mcp9601
+ then:
+ properties:
+ interrupts:
+ minItems: 1
+ maxItems: 4
+ interrupt-names:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum:
+ - alert1
+ - alert2
+ - alert3
+ - alert4
+ microchip,vsense: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/iio/temperature/thermocouple.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@60 {
+ compatible = "microchip,mcp9600";
+ reg = <0x60>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "alert1";
+ thermocouple-type = <THERMOCOUPLE_TYPE_K>;
+ vdd-supply = <&vdd>;
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@62 {
+ compatible = "microchip,mcp9601", "microchip,mcp9600";
+ reg = <0x62>;
+ interrupt-parent = <&gpio>;
+ interrupts = <22 IRQ_TYPE_EDGE_RISING>, <23 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "open-circuit", "short-circuit";
+ vdd-supply = <&vdd>;
+ microchip,vsense;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml
new file mode 100644
index 000000000000..590f50ba3a31
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp006.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/ti,tmp006.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TMP006 IR thermopile sensor
+
+maintainers:
+ - Peter Meerwald <pmeerw@pmeerw.net>
+
+description: |
+ TI TMP006 - Infrared Thermopile Sensor in Chip-Scale Package.
+ https://cdn.sparkfun.com/datasheets/Sensors/Temp/tmp006.pdf
+
+properties:
+ compatible:
+ const: ti,tmp006
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: provide VDD power to the sensor.
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ temperature-sensor@40 {
+ compatible = "ti,tmp006";
+ reg = <0x40>;
+ vdd-supply = <&ldo4_reg>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml
index 347bc16a4671..fbba5e934861 100644
--- a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml
@@ -1,15 +1,16 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/iio/temperature/ti,tmp117.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/iio/temperature/ti,tmp117.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: "TI TMP117 - Digital temperature sensor with integrated NV memory"
+title: TI TMP117 - Digital temperature sensor with integrated NV memory
description: |
- TI TMP117 - Digital temperature sensor with integrated NV memory that supports
- I2C interface.
- https://www.ti.com/lit/gpn/tmp1
+ TI TMP116/117 - Digital temperature sensor with integrated NV memory that
+ supports I2C interface.
+ https://www.ti.com/lit/gpn/tmp116
+ https://www.ti.com/lit/gpn/tmp117
maintainers:
- Puranjay Mohan <puranjay12@gmail.com>
@@ -17,14 +18,22 @@ maintainers:
properties:
compatible:
enum:
+ - ti,tmp116
- ti,tmp117
reg:
maxItems: 1
+ vcc-supply:
+ description: provide VCC power to the sensor.
+
+ label:
+ description: Unique name to identify which device this is.
+
required:
- compatible
- reg
+ - vcc-supply
additionalProperties: false
@@ -35,7 +44,8 @@ examples:
#size-cells = <0>;
tmp117@48 {
- compatible = "ti,tmp117";
- reg = <0x48>;
+ compatible = "ti,tmp117";
+ reg = <0x48>;
+ vcc-supply = <&pmic_reg_3v3>;
};
};
diff --git a/Documentation/devicetree/bindings/incomplete-devices.yaml b/Documentation/devicetree/bindings/incomplete-devices.yaml
new file mode 100644
index 000000000000..4bb6c0141e9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/incomplete-devices.yaml
@@ -0,0 +1,285 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/incomplete-devices.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rejected, Legacy or Incomplete Devices
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+description:
+ Some devices will not or should not get a proper Devicetree bindings, but
+ their compatibles are present in Linux drivers for various reasons.
+
+ Examples are devices using ACPI PRP0001 with non-updatable firmware/ACPI
+ tables or old PowerPC platforms without in-tree DTS.
+
+ Following list of devices is an incomplete schema with a goal to pass DT schema
+ checks on undocumented compatibles but also reject any DTS file using such
+ un-approved compatible.
+
+ Usage of any of following compatibles is not allowed in Devicetree sources,
+ even if they come from immutable firmware.
+
+properties:
+ compatible:
+ oneOf:
+ - description:
+ Rejected compatibles in Devicetree, but used in ACPI-based devices
+ with non-updatable firmware/ACPI tables (via ACPI PRP0001)
+ enum:
+ - broadcom,bcm5241
+ - ltr,ltrf216a
+
+ - description: Legacy compatibles used on Macintosh devices
+ enum:
+ - AAPL,3500
+ - AAPL,7500
+ - AAPL,8500
+ - AAPL,9500
+ - AAPL,accelerometer_1
+ - AAPL,e411
+ - AAPL,Gossamer
+ - AAPL,PowerBook1998
+ - AAPL,ShinerESB
+ - adm1030
+ - amd-0137
+ - B5221
+ - bmac+
+ - burgundy
+ - cobalt
+ - cy28508
+ - daca
+ - fcu
+ - gatwick
+ - gmac
+ - heathrow
+ - heathrow-ata
+ - heathrow-media-bay
+ - i2sbus
+ - i2s-modem
+ - iMac
+ - K2-GMAC
+ - k2-i2c
+ - K2-Keylargo
+ - K2-UATA
+ - kauai-ata
+ - Keylargo
+ - keylargo-ata
+ - keylargo-media-bay
+ - lm87cimt
+ - MAC,adm1030
+ - MAC,ds1775
+ - MacRISC
+ - MacRISC2
+ - MacRISC3
+ - MacRISC4
+ - max6690
+ - ohare
+ - ohare-media-bay
+ - ohare-swim3
+ - PowerBook1,1
+ - PowerBook2,1
+ - PowerBook2,2
+ - PowerBook3,1
+ - PowerBook3,2
+ - PowerBook3,3
+ - PowerBook3,4
+ - PowerBook3,5
+ - PowerBook4,1
+ - PowerBook4,2
+ - PowerBook4,3
+ - PowerBook5,1
+ - PowerBook5,2
+ - PowerBook5,3
+ - PowerBook5,4
+ - PowerBook5,5
+ - PowerBook5,6
+ - PowerBook5,7
+ - PowerBook5,8
+ - PowerBook5,9
+ - PowerBook6,3
+ - PowerBook6,5
+ - PowerBook6,7
+ - PowerMac10,1
+ - PowerMac10,2
+ - PowerMac1,1
+ - PowerMac11,2
+ - PowerMac12,1
+ - PowerMac2,1
+ - PowerMac2,2
+ - PowerMac3,1
+ - PowerMac3,4
+ - PowerMac3,5
+ - PowerMac3,6
+ - PowerMac4,1
+ - PowerMac4,2
+ - PowerMac4,4
+ - PowerMac4,5
+ - PowerMac7,2
+ - PowerMac7,3
+ - PowerMac8,1
+ - PowerMac8,2
+ - PowerMac9,1
+ - paddington
+ - RackMac1,1
+ - RackMac1,2
+ - RackMac3,1
+ - screamer
+ - shasta-ata
+ - sms
+ - smu-rpm-fans
+ - smu-sat
+ - smu-sensors
+ - snapper
+ - swim3
+ - tumbler
+ - u3-agp
+ - u3-dart
+ - u3-ht
+ - u4-dart
+ - u4-pcie
+ - U4-pcie
+ - uni-n-i2c
+ - uni-north
+
+ - description: Legacy compatibles used on other PowerPC devices
+ enum:
+ - 1682m-gizmo
+ - 1682m-gpio
+ - 1682m-rng
+ - 1682m-sdc
+ - amcc,ppc440epx-rng
+ - amcc,ppc460ex-bcsr
+ - amcc,ppc460ex-crypto
+ - amcc,ppc460ex-rng
+ - amcc,ppc460sx-crypto
+ - amcc,ppc4xx-crypto
+ - amcc,sata-460ex
+ - CBEA,platform-open-pic
+ - CBEA,platform-spider-pic
+ - direct-mapped
+ - display
+ - gpio-mdio
+ - hawk-bridge
+ - hawk-pci
+ - IBM,CBEA
+ - IBM,lhca
+ - IBM,lhea
+ - IBM,lhea-ethernet
+ - ibm,axon-msic
+ - Momentum,Apache
+ - Momentum,Maple
+ - mai-logic,articia-s
+ - mpc10x-pci
+ - mpc5200b-fec-phy
+ - mpc5200-serial
+ - mpc5200-sram
+ - nintendo,flipper
+ - nintendo,flipper-exi
+ - nintendo,flipper-pi
+ - nintendo,flipper-pic
+ - nintendo,hollywood
+ - nintendo,hollywood-pic
+ - nintendo,latte-exi
+ - nintendo,latte-srnprot
+ - ohci-be
+ - ohci-bigendian
+ - ohci-le
+ - PA6T-1682M
+ - pasemi,1682m-iob
+ - pasemi,localbus
+ - pasemi,localbus-nand
+ - pasemi,nemo
+ - pasemi,pwrficient
+ - pasemi,pwrficient-rng
+ - pasemi,rootbus
+ - pasemi,sdc
+ - soc
+ - sony,ps3
+ - sti,platform-spider-pic
+
+ - description: Legacy compatibles used on SPARC devices
+ enum:
+ - bq4802
+ - ds1287
+ - i2cpcf,8584
+ - isa-m5819p
+ - isa-m5823p
+ - m5819
+ - qcn
+ - sab82532
+ - su
+ - sun4v
+ - SUNW,bbc-beep
+ - SUNW,bbc-i2c
+ - SUNW,CS4231
+ - SUNW,ebus-pic16f747-env
+ - SUNW,kt-cwq
+ - SUNW,kt-mau
+ - SUNW,n2-cwq
+ - SUNW,n2-mau
+ - SUNW,niusl
+ - SUNW,smbus-beep
+ - SUNW,sun4v-console
+ - SUNW,sun4v-pci
+ - SUNW,vf-cwq
+ - SUNW,vf-mau
+
+ - description: Incomplete and/or legacy compatibles for unknown devices
+ enum:
+ - electra-cf
+ - i2cpcf,8584
+ - virtio,uml
+
+ - description: Linux kernel unit tests and sample code
+ enum:
+ - audio-graph-card2-custom-sample
+ - compat1
+ - compat2
+ - compat3
+ - gpio-mockup
+ - gpio-simulator
+ - gpio-virtuser
+ - linux,spi-loopback-test
+ - mailbox-test
+ - regulator-virtual-consumer
+ - test-device
+
+ - description:
+ Devices on MIPS platform, without any DTS users. These are
+ unlikely to get converted to DT schema.
+ enum:
+ - mti,ranchu
+
+ - description:
+ Devices on PowerPC platform, without any DTS users. These are
+ unlikely to get converted to DT schema.
+ enum:
+ - fujitsu,coral
+ - fujitsu,lime
+ - fujitsu,MB86276
+ - fujitsu,MB86277
+ - fujitsu,MB86293
+ - fujitsu,MB86294
+ - fujitsu,mint
+ - ibm,axon-msic
+ - ibm,pmemory
+ - ibm,pmemory-v2
+ - ibm,power-rng
+ - ibm,ppc4xx-spi
+ - ibm,sdram-4xx-ddr2
+ - ibm,secureboot
+ - ibm,secureboot-v1
+ - ibm,secureboot-v2
+ - ibm,secvar-backend
+ - sgy,gpio-halt
+ - wrs,epld-localbus
+
+required:
+ - compatible
+ - broken-usage-of-incorrect-compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/index.rst b/Documentation/devicetree/bindings/index.rst
index d9002a3a0abb..cc1fbdc05657 100644
--- a/Documentation/devicetree/bindings/index.rst
+++ b/Documentation/devicetree/bindings/index.rst
@@ -4,6 +4,7 @@
:maxdepth: 1
ABI
+ dts-coding-style
writing-bindings
writing-schema
submitting-patches
diff --git a/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
new file mode 100644
index 000000000000..5e86f6de6978
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/adafruit,seesaw-gamepad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Adafruit Mini I2C Gamepad with seesaw
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+description: |
+ Adafruit Mini I2C Gamepad
+
+ +-----------------------------+
+ | ___ |
+ | / \ (X) |
+ | | S | __ __ (Y) (A) |
+ | \___/ |ST| |SE| (B) |
+ | |
+ +-----------------------------+
+
+ S -> 10-bit precision bidirectional analog joystick
+ ST -> Start
+ SE -> Select
+ X, A, B, Y -> Digital action buttons
+
+ Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
+ Product page: https://www.adafruit.com/product/5743
+ Arduino Driver: https://github.com/adafruit/Adafruit_Seesaw
+
+properties:
+ compatible:
+ const: adafruit,seesaw-gamepad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description:
+ The gamepad's IRQ pin triggers a rising edge if interrupts are enabled.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ joystick@50 {
+ compatible = "adafruit,seesaw-gamepad";
+ interrupts = <18 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x50>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml b/Documentation/devicetree/bindings/input/adc-joystick.yaml
index 64d961458ac7..6c244d66f8ce 100644
--- a/Documentation/devicetree/bindings/input/adc-joystick.yaml
+++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml
@@ -2,8 +2,8 @@
# Copyright 2019-2020 Artur Rojek
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/input/adc-joystick.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/input/adc-joystick.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADC attached joystick
@@ -14,6 +14,9 @@ description: >
Bindings for joystick devices connected to ADC controllers supporting
the Industrial I/O subsystem.
+allOf:
+ - $ref: input.yaml#
+
properties:
compatible:
const: adc-joystick
@@ -28,6 +31,8 @@ properties:
https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml
for details.
+ poll-interval: true
+
'#address-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/input/adi,adp5588.yaml b/Documentation/devicetree/bindings/input/adi,adp5588.yaml
new file mode 100644
index 000000000000..336bc352579a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adi,adp5588.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/adi,adp5588.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADP5588 Keypad Controller
+
+maintainers:
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ Analog Devices Mobile I/O Expander and QWERTY Keypad Controller
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADP5588.pdf
+
+allOf:
+ - $ref: matrix-keymap.yaml#
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,adp5587
+ - adi,adp5588
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: Supply Voltage Input
+
+ reset-gpios:
+ description:
+ If specified, it will be asserted during driver probe. As the line is
+ active low, it should be marked GPIO_ACTIVE_LOW.
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller:
+ description:
+ This property applies if either keypad,num-rows lower than 8 or
+ keypad,num-columns lower than 10.
+
+ '#gpio-cells':
+ const: 2
+
+ interrupt-controller:
+ description:
+ This property applies if either keypad,num-rows lower than 8 or
+ keypad,num-columns lower than 10. This property is optional if
+ keypad,num-rows or keypad,num-columns are not specified as the
+ device is then configured to be used purely for gpio during which
+ interrupts may or may not be utilized.
+
+ '#interrupt-cells':
+ const: 2
+
+ adi,unlock-keys:
+ description:
+ Specifies a maximum of 2 keys that can be used to unlock the keypad.
+ If this property is set, the keyboard will be locked and only unlocked
+ after these keys are pressed. If only one key is set, a double click is
+ needed to unlock the keypad. The value of this property cannot be bigger
+ or equal than keypad,num-rows * keypad,num-columns.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+
+dependencies:
+ keypad,num-rows:
+ - linux,keymap
+ - keypad,num-columns
+ keypad,num-columns:
+ - linux,keymap
+ - keypad,num-rows
+ linux,keymap:
+ - keypad,num-rows
+ - keypad,num-columns
+ - interrupts
+ interrupt-controller:
+ - interrupts
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ keys@34 {
+ compatible = "adi,adp5588";
+ reg = <0x34>;
+
+ vcc-supply = <&vcc>;
+ interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+
+ keypad,num-rows = <1>;
+ keypad,num-columns = <9>;
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x00, KEY_1)
+ MATRIX_KEY(0x00, 0x01, KEY_2)
+ MATRIX_KEY(0x00, 0x02, KEY_3)
+ MATRIX_KEY(0x00, 0x03, KEY_4)
+ MATRIX_KEY(0x00, 0x04, KEY_5)
+ MATRIX_KEY(0x00, 0x05, KEY_6)
+ MATRIX_KEY(0x00, 0x06, KEY_7)
+ MATRIX_KEY(0x00, 0x07, KEY_8)
+ MATRIX_KEY(0x00, 0x08, KEY_9)
+ >;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio@34 {
+ compatible = "adi,adp5588";
+ reg = <0x34>;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
index 9700dc468b25..6bdb8040be65 100644
--- a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
+++ b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/allwinner,sun4i-a10-lradc-keys.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 LRADC Device Tree Bindings
+title: Allwinner A10 LRADC
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -16,11 +16,15 @@ properties:
- const: allwinner,sun4i-a10-lradc-keys
- const: allwinner,sun8i-a83t-r-lradc
- items:
- - const: allwinner,sun50i-a64-lradc
+ - enum:
+ - allwinner,suniv-f1c100s-lradc
+ - allwinner,sun50i-a64-lradc
- const: allwinner,sun8i-a83t-r-lradc
- const: allwinner,sun50i-r329-lradc
- items:
- - const: allwinner,sun20i-d1-lradc
+ - enum:
+ - allwinner,sun50i-h616-lradc
+ - allwinner,sun20i-d1-lradc
- const: allwinner,sun50i-r329-lradc
reg:
@@ -47,7 +51,6 @@ patternProperties:
$ref: input.yaml#
properties:
label:
- $ref: /schemas/types.yaml#/definitions/string
description: Descriptive name of the key
linux,code: true
diff --git a/Documentation/devicetree/bindings/input/atmel,captouch.txt b/Documentation/devicetree/bindings/input/atmel,captouch.txt
deleted file mode 100644
index fe9ee5c53bcc..000000000000
--- a/Documentation/devicetree/bindings/input/atmel,captouch.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Device tree bindings for Atmel capacitive touch device, typically
-an Atmel touch sensor connected to AtmegaXX MCU running firmware
-based on Qtouch library.
-
-The node for this device must be a child of a I2C controller node, as the
-device communicates via I2C.
-
-Required properties:
-
- compatible: Must be "atmel,captouch".
- reg: The I2C slave address of the device.
- interrupts: Property describing the interrupt line the device
- is connected to. The device only has one interrupt
- source.
- linux,keycodes: Specifies an array of numeric keycode values to
- be used for reporting button presses. The array can
- contain up to 8 entries.
-
-Optional properties:
-
- autorepeat: Enables the Linux input system's autorepeat
- feature on the input device.
-
-Example:
-
- atmel-captouch@51 {
- compatible = "atmel,captouch";
- reg = <0x51>;
- interrupt-parent = <&tlmm>;
- interrupts = <67 IRQ_TYPE_EDGE_FALLING>;
- linux,keycodes = <BTN_0>, <BTN_1>,
- <BTN_2>, <BTN_3>,
- <BTN_4>, <BTN_5>,
- <BTN_6>, <BTN_7>;
- autorepeat;
- };
diff --git a/Documentation/devicetree/bindings/input/atmel,captouch.yaml b/Documentation/devicetree/bindings/input/atmel,captouch.yaml
new file mode 100644
index 000000000000..f7477091d5a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/atmel,captouch.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/atmel,captouch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel capacitive touch device
+
+maintainers:
+ - Dharma balasubiramani <dharma.b@microchip.com>
+
+description:
+ Atmel capacitive touch device, typically an Atmel touch sensor connected to
+ AtmegaXX MCU running firmware based on Qtouch library.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+ const: atmel,captouch
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ linux,keycodes:
+ minItems: 1
+ maxItems: 8
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - linux,keycodes
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touch@51 {
+ compatible = "atmel,captouch";
+ reg = <0x51>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <67 IRQ_TYPE_EDGE_FALLING>;
+ linux,keycodes = <BTN_0>, <BTN_1>,
+ <BTN_2>, <BTN_3>,
+ <BTN_4>, <BTN_5>,
+ <BTN_6>, <BTN_7>;
+ autorepeat;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index 3ec579d63570..d79b254f1cde 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -14,6 +14,10 @@ description: |
Atmel maXTouch touchscreen or touchpads such as the mXT244
and similar devices.
+allOf:
+ - $ref: input.yaml#
+ - $ref: touchscreen/touchscreen.yaml#
+
properties:
compatible:
const: atmel,maxtouch
@@ -60,6 +64,10 @@ properties:
or experiment to determine which bit corresponds to which input. Use
KEY_RESERVED for unused padding values.
+ linux,keycodes:
+ minItems: 1
+ maxItems: 8
+
atmel,wakeup-method:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -88,7 +96,7 @@ required:
- reg
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/input/awinic,aw86927.yaml b/Documentation/devicetree/bindings/input/awinic,aw86927.yaml
new file mode 100644
index 000000000000..b7252916bd72
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/awinic,aw86927.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/awinic,aw86927.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW86927 LRA Haptic IC
+
+maintainers:
+ - Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
+
+properties:
+ compatible:
+ const: awinic,aw86927
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vibrator@5a {
+ compatible = "awinic,aw86927";
+ reg = <0x5a>;
+ interrupts-extended = <&tlmm 101 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tlmm 100 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
index 02e605fac408..418c168b223b 100644
--- a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
+++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/input/azoteq,iqs7222.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Azoteq IQS7222A/B/C Capacitive Touch Controller
+title: Azoteq IQS7222A/B/C/D Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
- The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch
- controllers that feature additional sensing capabilities.
+ The Azoteq IQS7222A, IQS7222B, IQS7222C and IQS7222D are multichannel
+ capacitive touch controllers that feature additional sensing capabilities.
Link to datasheets: https://www.azoteq.com/
@@ -21,6 +21,7 @@ properties:
- azoteq,iqs7222a
- azoteq,iqs7222b
- azoteq,iqs7222c
+ - azoteq,iqs7222d
reg:
maxItems: 1
@@ -173,6 +174,152 @@ properties:
maximum: 3000
description: Specifies the report rate (in ms) during ultra-low-power mode.
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+ trackpad:
+ type: object
+ description: Represents all channels associated with the trackpad.
+
+ properties:
+ azoteq,channel-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 12
+ items:
+ minimum: 0
+ maximum: 13
+ description:
+ Specifies the order of the channels that participate in the trackpad.
+ Specify 255 to omit a given channel for the purpose of mapping a non-
+ rectangular trackpad.
+
+ azoteq,num-rows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 12
+ description: Specifies the number of rows that comprise the trackpad.
+
+ azoteq,num-cols:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 12
+ description: Specifies the number of columns that comprise the trackpad.
+
+ azoteq,top-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ multipleOf: 4
+ minimum: 0
+ maximum: 1020
+ description:
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is no longer applied.
+
+ azoteq,bottom-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description:
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is linearly reduced.
+
+ azoteq,use-prox:
+ type: boolean
+ description:
+ Directs the trackpad to respond to the proximity states of the
+ selected channels instead of their corresponding touch states.
+ Note the trackpad cannot report granular coordinates during a
+ state of proximity.
+
+ patternProperties:
+ "^azoteq,lower-cal-(x|y)$":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's lower starting points.
+
+ "^azoteq,upper-cal-(x|y)$":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's upper starting points.
+
+ "^event-(press|tap|(swipe|flick)-(x|y)-(pos|neg))$":
+ type: object
+ $ref: input.yaml#
+ description:
+ Represents a press or gesture event reported by the trackpad. Specify
+ 'linux,code' under the press event to report absolute coordinates.
+
+ properties:
+ linux,code: true
+
+ azoteq,gesture-angle-tighten:
+ type: boolean
+ description:
+ Limits the tangent of the gesture angle to 0.5 (axial gestures
+ only). If specified in one direction, the effect is applied in
+ either direction.
+
+ azoteq,gesture-max-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ description:
+ Specifies the length of time (in ms) within which a tap, swipe
+ or flick gesture must be completed in order to be acknowledged
+ by the device. The number specified for any one swipe or flick
+ gesture applies to all other swipe or flick gestures.
+
+ azoteq,gesture-min-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ description:
+ Specifies the length of time (in ms) for which a tap gesture must
+ be held in order to be acknowledged by the device.
+
+ azoteq,gesture-dist:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the distance (in coordinates) across which a swipe or
+ flick gesture must travel in order to be acknowledged by the
+ device. The number specified for any one swipe or flick gesture
+ applies to all remaining swipe or flick gestures.
+
+ For tap gestures, this property specifies the distance from the
+ original point of contact across which the contact is permitted
+ to travel before the gesture is rejected by the device.
+
+ azoteq,gpio-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 2
+ description: |
+ Specifies one or more GPIO mapped to the event as follows:
+ 0: GPIO0
+ 1: GPIO3
+ 2: GPIO4
+
+ Note that although multiple events can be mapped to a single
+ GPIO, they must all be of the same type (proximity, touch or
+ trackpad gesture).
+
+ additionalProperties: false
+
+ required:
+ - azoteq,channel-select
+
+ additionalProperties: false
+
patternProperties:
"^cycle-[0-9]$":
type: object
@@ -288,6 +435,10 @@ patternProperties:
Activates the reference channel in response to proximity events
instead of touch events.
+ azoteq,counts-filt-enable:
+ type: boolean
+ description: Applies counts filtering to the channel.
+
azoteq,ati-band:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
@@ -432,12 +583,12 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
- 1: GPIO3 (IQS7222C only)
- 2: GPIO4 (IQS7222C only)
+ 1: GPIO3
+ 2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
- slider gesture).
+ slider/trackpad gesture).
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -473,9 +624,6 @@ patternProperties:
Specifies whether the event is to be interpreted as a key (1)
or a switch (5).
- required:
- - linux,code
-
additionalProperties: false
dependencies:
@@ -501,7 +649,7 @@ patternProperties:
azoteq,slider-size:
$ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
+ minimum: 1
maximum: 65535
description:
Specifies the slider's one-dimensional resolution, equal to the
@@ -524,16 +672,16 @@ patternProperties:
minimum: 0
maximum: 65535
description:
- Specifies the speed of movement after which coordinate filtering is
- no longer applied.
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is no longer applied.
azoteq,bottom-speed:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
description:
- Specifies the speed of movement after which coordinate filtering is
- linearly reduced.
+ Specifies the speed (in coordinates traveled per conversion) after
+ which coordinate filtering is linearly reduced.
azoteq,bottom-beta:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -575,9 +723,9 @@ patternProperties:
linux,code: true
azoteq,gesture-max-ms:
- multipleOf: 4
+ multipleOf: 16
minimum: 0
- maximum: 1020
+ maximum: 4080
description:
Specifies the length of time (in ms) within which a tap, swipe
or flick gesture must be completed in order to be acknowledged
@@ -585,9 +733,9 @@ patternProperties:
gesture applies to all remaining swipe or flick gestures.
azoteq,gesture-min-ms:
- multipleOf: 4
+ multipleOf: 16
minimum: 0
- maximum: 124
+ maximum: 496
description:
Specifies the length of time (in ms) for which a tap gesture must
be held in order to be acknowledged by the device.
@@ -598,10 +746,10 @@ patternProperties:
minimum: 0
maximum: 4080
description:
- Specifies the distance across which a swipe or flick gesture must
- travel in order to be acknowledged by the device. The number spec-
- ified for any one swipe or flick gesture applies to all remaining
- swipe or flick gestures.
+ Specifies the distance (in coordinates) across which a swipe or
+ flick gesture must travel in order to be acknowledged by the
+ device. The number specified for any one swipe or flick gesture
+ applies to all remaining swipe or flick gestures.
azoteq,gpio-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -613,16 +761,13 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
- 1: GPIO3 (IQS7222C only)
- 2: GPIO4 (IQS7222C only)
+ 1: GPIO3
+ 2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
slider gesture).
- required:
- - linux,code
-
additionalProperties: false
required:
@@ -635,11 +780,11 @@ patternProperties:
description: |
Represents a GPIO mapped to one or more events as follows:
gpio-0: GPIO0
- gpio-1: GPIO3 (IQS7222C only)
- gpio-2: GPIO4 (IQS7222C only)
+ gpio-1: GPIO3
+ gpio-2: GPIO4
allOf:
- - $ref: ../pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
properties:
drive-open-drain: true
@@ -647,11 +792,53 @@ patternProperties:
additionalProperties: false
allOf:
+ - $ref: touchscreen/touchscreen.yaml#
+
- if:
properties:
compatible:
contains:
- const: azoteq,iqs7222b
+ enum:
+ - azoteq,iqs7222a
+ - azoteq,iqs7222b
+ - azoteq,iqs7222c
+
+ then:
+ properties:
+ touchscreen-size-x: false
+ touchscreen-size-y: false
+ touchscreen-inverted-x: false
+ touchscreen-inverted-y: false
+ touchscreen-swapped-x-y: false
+
+ trackpad: false
+
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
+ properties:
+ azoteq,counts-filt-enable: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - azoteq,iqs7222b
+ - azoteq,iqs7222c
+
+ then:
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
+ properties:
+ azoteq,ulp-allow: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - azoteq,iqs7222b
+ - azoteq,iqs7222d
then:
patternProperties:
@@ -663,13 +850,22 @@ allOf:
properties:
azoteq,ref-select: false
+ "^slider-[0-1]$": false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: azoteq,iqs7222b
+
+ then:
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
patternProperties:
"^event-(prox|touch)$":
properties:
azoteq,gpio-select: false
- "^slider-[0-1]$": false
-
"^gpio-[0-2]$": false
- if:
@@ -693,6 +889,7 @@ allOf:
properties:
azoteq,slider-size:
multipleOf: 16
+ minimum: 16
maximum: 4080
azoteq,top-speed:
@@ -709,10 +906,6 @@ allOf:
else:
patternProperties:
- "^channel-([0-9]|1[0-9])$":
- properties:
- azoteq,ulp-allow: false
-
"^slider-[0-1]$":
patternProperties:
"^event-(press|tap|(swipe|flick)-(pos|neg))$":
@@ -935,14 +1128,14 @@ examples:
event-tap {
linux,code = <KEY_PLAYPAUSE>;
- azoteq,gesture-max-ms = <600>;
- azoteq,gesture-min-ms = <24>;
+ azoteq,gesture-max-ms = <400>;
+ azoteq,gesture-min-ms = <32>;
};
event-flick-pos {
linux,code = <KEY_NEXTSONG>;
- azoteq,gesture-max-ms = <600>;
- azoteq,gesture-dist = <816>;
+ azoteq,gesture-max-ms = <800>;
+ azoteq,gesture-dist = <800>;
};
event-flick-neg {
diff --git a/Documentation/devicetree/bindings/input/cirrus,cs40l50.yaml b/Documentation/devicetree/bindings/input/cirrus,cs40l50.yaml
new file mode 100644
index 000000000000..89bd06864bd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cirrus,cs40l50.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cirrus,cs40l50.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS40L50 Advanced Haptic Driver
+
+maintainers:
+ - James Ogletree <jogletre@opensource.cirrus.com>
+
+description:
+ CS40L50 is a haptic driver with waveform memory,
+ integrated DSP, and closed-loop algorithms.
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs40l50
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vdd-a-supply:
+ description: Power supply for internal analog circuits.
+
+ vdd-p-supply:
+ description: Power supply for always-on circuits.
+
+ vdd-io-supply:
+ description: Power supply for digital input/output.
+
+ vdd-b-supply:
+ description: Power supply for the boost converter.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+ - vdd-io-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ haptic-driver@34 {
+ compatible = "cirrus,cs40l50";
+ reg = <0x34>;
+ interrupt-parent = <&gpio>;
+ interrupts = <113 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio 112 GPIO_ACTIVE_LOW>;
+ vdd-io-supply = <&vreg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml b/Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml
new file mode 100644
index 000000000000..a0d2460c55ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cirrus,ep9307-keypad.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cirrus,ep9307-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus ep93xx keypad
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+allOf:
+ - $ref: /schemas/input/matrix-keymap.yaml#
+
+description:
+ The KPP is designed to interface with a keypad matrix with 2-point contact
+ or 3-point contact keys. The KPP is designed to simplify the software task
+ of scanning a keypad matrix. The KPP is capable of detecting, debouncing,
+ and decoding one or multiple keys pressed simultaneously on a keypad.
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9307-keypad
+ - items:
+ - enum:
+ - cirrus,ep9312-keypad
+ - cirrus,ep9315-keypad
+ - const: cirrus,ep9307-keypad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ debounce-delay-ms:
+ description: |
+ Time in microseconds that key must be pressed or
+ released for state change interrupt to trigger.
+
+ cirrus,prescale:
+ description: row/column counter pre-scaler load value
+ $ref: /schemas/types.yaml#/definitions/uint16
+ maximum: 1023
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - linux,keymap
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/clock/cirrus,ep9301-syscon.h>
+ keypad@800f0000 {
+ compatible = "cirrus,ep9307-keypad";
+ reg = <0x800f0000 0x0c>;
+ interrupt-parent = <&vic0>;
+ interrupts = <29>;
+ clocks = <&eclk EP93XX_CLK_KEYPAD>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&keypad_default_pins>;
+ linux,keymap = <KEY_UP>,
+ <KEY_DOWN>,
+ <KEY_VOLUMEDOWN>,
+ <KEY_HOME>,
+ <KEY_RIGHT>,
+ <KEY_LEFT>,
+ <KEY_ENTER>,
+ <KEY_VOLUMEUP>,
+ <KEY_F6>,
+ <KEY_F8>,
+ <KEY_F9>,
+ <KEY_F10>,
+ <KEY_F1>,
+ <KEY_F2>,
+ <KEY_F3>,
+ <KEY_POWER>;
+ };
diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
deleted file mode 100644
index d3db65916a36..000000000000
--- a/Documentation/devicetree/bindings/input/cypress,cyapa.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Cypress I2C Touchpad
-
-Required properties:
-- compatible: must be "cypress,cyapa".
-- reg: I2C address of the chip.
-- interrupts: interrupt to which the chip is connected (see interrupt
- binding[0]).
-
-Optional properties:
-- wakeup-source: touchpad can be used as a wakeup source.
-- pinctrl-names: should be "default" (see pinctrl binding [1]).
-- pinctrl-0: a phandle pointing to the pin settings for the device (see
- pinctrl binding [1]).
-- vcc-supply: a phandle for the regulator supplying 3.3V power.
-
-[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-Example:
- &i2c0 {
- /* ... */
-
- /* Cypress Gen3 touchpad */
- touchpad@67 {
- compatible = "cypress,cyapa";
- reg = <0x67>;
- interrupt-parent = <&gpio>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
- wakeup-source;
- };
-
- /* Cypress Gen5 and later touchpad */
- touchpad@24 {
- compatible = "cypress,cyapa";
- reg = <0x24>;
- interrupt-parent = <&gpio>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
- wakeup-source;
- };
-
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.yaml b/Documentation/devicetree/bindings/input/cypress,cyapa.yaml
new file mode 100644
index 000000000000..da629d511da1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cyapa.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/cypress,cyapa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress All Points Addressable (APA) I2C Touchpad / Trackpad
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ const: cypress,cyapa
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ vcc-supply:
+ description: 3.3V power
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ trackpad@67 {
+ reg = <0x67>;
+ compatible = "cypress,cyapa";
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpx1>;
+ wakeup-source;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt
deleted file mode 100644
index e5eef59a93dc..000000000000
--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Dialog DA9061/62/63 OnKey Module
-
-This module is part of the DA9061/DA9062/DA9063. For more details about entire
-DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
-For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
-
-This module provides the KEY_POWER event.
-
-Required properties:
-
-- compatible: should be one of the following valid compatible string lines:
- "dlg,da9061-onkey", "dlg,da9062-onkey"
- "dlg,da9062-onkey"
- "dlg,da9063-onkey"
-
-Optional properties:
-
-- dlg,disable-key-power : Disable power-down using a long key-press. If this
- entry exists the OnKey driver will remove support for the KEY_POWER key
- press when triggered using a long press of the OnKey.
-
-Example: DA9063
-
- pmic0: da9063@58 {
- onkey {
- compatible = "dlg,da9063-onkey";
- dlg,disable-key-power;
- };
- };
-
-Example: DA9062
-
- pmic0: da9062@58 {
- onkey {
- compatible = "dlg,da9062-onkey";
- dlg,disable-key-power;
- };
- };
-
-Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
-
- pmic0: da9061@58 {
- onkey {
- compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
- dlg,disable-key-power;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt b/Documentation/devicetree/bindings/input/dlg,da7280.txt
deleted file mode 100644
index 96ee5d50e111..000000000000
--- a/Documentation/devicetree/bindings/input/dlg,da7280.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-Dialog Semiconductor DA7280 Haptics bindings
-
-Required properties:
-- compatible: Should be "dlg,da7280".
-- reg: Specifies the I2C slave address.
-
-- interrupt-parent : Specifies the phandle of the interrupt controller to
- which the IRQs from DA7280 are delivered to.
-
-- dlg,actuator-type: Set Actuator type. it should be one of:
- "LRA" - Linear Resonance Actuator type.
- "ERM-bar" - Bar type Eccentric Rotating Mass.
- "ERM-coin" - Coin type Eccentric Rotating Mass.
-
-- dlg,const-op-mode: Haptic operation mode for FF_CONSTANT.
- Possible values:
- 1 - Direct register override(DRO) mode triggered by i2c(default),
- 2 - PWM data source mode controlled by PWM duty,
-- dlg,periodic-op-mode: Haptic operation mode for FF_PERIODIC.
- Possible values:
- 1 - Register triggered waveform memory(RTWM) mode, the pattern
- assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP,
- 2 - Edge triggered waveform memory(ETWM) mode, external GPI(N)
- control are required to enable/disable and it needs to keep
- device enabled by sending magnitude (X > 0),
- the pattern is assigned to the GPI(N)_SEQUENCE_ID below.
- The default value is 1 for both of the operation modes.
- For more details, please see the datasheet.
-
-- dlg,nom-microvolt: Nominal actuator voltage rating.
- Valid values: 0 - 6000000.
-- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating.
- Valid values: 0 - 6000000.
-- dlg,imax-microamp: Actuator max current rating.
- Valid values: 0 - 252000.
- Default: 130000.
-- dlg,impd-micro-ohms: the impedance of the actuator in micro ohms.
- Valid values: 0 - 1500000000.
-
-Optional properties:
-- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
- PWM properties should be named "pwms". And number of cell is different
- for each pwm device.
- (See Documentation/devicetree/bindings/pwm/pwm.txt
- for further information relating to pwm properties)
-
-- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip)
- to play back when RTWM-MODE is enabled.
- Valid range: 0 - 15.
-- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence
- pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated.
- Valid range: 0 - 15.
-- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play
- when gpi0 is triggered, 'N' must be 0 - 2.
- Valid range: 0 - 15.
-- dlg,gpiN-mode: the pattern mode which can select either
- "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2.
-- dlg,gpiN-polarity: gpiN polarity which can be chosen among
- "Rising-edge", "Falling-edge" and "Both-edge",
- 'N' must be 0 - 2
- Haptic will work by this edge option in case of ETWM mode.
-
-- dlg,resonant-freq-hz: use in case of LRA.
- the frequency range: 50 - 300.
- Default: 205.
-
-- dlg,bemf-sens-enable: Enable for internal loop computations.
-- dlg,freq-track-enable: Enable for resonant frequency tracking.
-- dlg,acc-enable: Enable for active acceleration.
-- dlg,rapid-stop-enable: Enable for rapid stop.
-- dlg,amp-pid-enable: Enable for the amplitude PID.
-- dlg,mem-array: Customized waveform memory(patterns) data downloaded to
- the device during initialization. This is an array of 100 values(u8).
-
-For further information, see device datasheet.
-
-======
-
-Example:
-
- haptics: da7280-haptics@4a {
- compatible = "dlg,da7280";
- reg = <0x4a>;
- interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- dlg,actuator-type = "LRA";
- dlg,dlg,const-op-mode = <1>;
- dlg,dlg,periodic-op-mode = <1>;
- dlg,nom-microvolt = <2000000>;
- dlg,abs-max-microvolt = <2000000>;
- dlg,imax-microamp = <170000>;
- dlg,resonant-freq-hz = <180>;
- dlg,impd-micro-ohms = <10500000>;
- dlg,freq-track-enable;
- dlg,rapid-stop-enable;
- dlg,mem-array = <
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- >;
- };
diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.yaml b/Documentation/devicetree/bindings/input/dlg,da7280.yaml
new file mode 100644
index 000000000000..0d06755aaaa8
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da7280.yaml
@@ -0,0 +1,248 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/dlg,da7280.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA7280 Low Power High-Definition Haptic Driver
+
+maintainers:
+ - Roy Im <roy.im.opensource@diasemi.com>
+
+properties:
+ compatible:
+ const: dlg,da7280
+
+ reg:
+ maxItems: 1
+ description: I2C address of the device.
+
+ interrupts:
+ maxItems: 1
+
+ dlg,actuator-type:
+ enum:
+ - LRA # Linear Resonance Actuator type
+ - ERM-bar # Bar type Eccentric Rotating Mass
+ - ERM-coin # Coin type Eccentric Rotating Mass
+
+ dlg,const-op-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 1 # Direct register override (DRO) mode triggered by i2c (default)
+ - 2 # PWM data source mode controlled by PWM duty
+ description:
+ Haptic operation mode for FF_CONSTANT
+
+ dlg,periodic-op-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 1 # Register triggered waveform memory(RTWM) mode, the pattern
+ # assigned to the PS_SEQ_ID played as much times as PS_SEQ_LOOP
+ - 2 # Edge triggered waveform memory(ETWM) mode, external GPI(N)
+ # control are required to enable/disable and it needs to keep
+ # device enabled by sending magnitude (X > 0),
+ # the pattern is assigned to the GPI(N)_SEQUENCE_ID below
+ default: 1
+ description:
+ Haptic operation mode for FF_PERIODIC.
+ The default value is 1 for both of the operation modes.
+ For more details, please see the datasheet
+
+ dlg,nom-microvolt:
+ minimum: 0
+ maximum: 6000000
+ description:
+ Nominal actuator voltage rating
+
+ dlg,abs-max-microvolt:
+ minimum: 0
+ maximum: 6000000
+ description:
+ Absolute actuator maximum voltage rating
+
+ dlg,imax-microamp:
+ minimum: 0
+ maximum: 252000
+ default: 130000
+ description:
+ Actuator max current rating
+
+ dlg,impd-micro-ohms:
+ minimum: 0
+ maximum: 1500000000
+ description:
+ Impedance of the actuator
+
+ pwms:
+ maxItems: 1
+
+ dlg,ps-seq-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description:
+ The PS_SEQ_ID(pattern ID in waveform memory inside chip)
+ to play back when RTWM-MODE is enabled
+
+ dlg,ps-seq-loop:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description:
+ The PS_SEQ_LOOP, Number of times the pre-stored sequence pointed to by
+ PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated
+
+ dlg,gpi0-seq-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description:
+ the GPI0_SEQUENCE_ID, pattern to play when gpi0 is triggered
+
+ dlg,gpi1-seq-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description:
+ the GPI1_SEQUENCE_ID, pattern to play when gpi1 is triggered
+
+ dlg,gpi2-seq-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description:
+ the GPI2_SEQUENCE_ID, pattern to play when gpi2 is triggered
+
+ dlg,gpi0-mode:
+ enum:
+ - Single-pattern
+ - Multi-pattern
+ description:
+ Pattern mode for gpi0
+
+ dlg,gpi1-mode:
+ enum:
+ - Single-pattern
+ - Multi-pattern
+ description:
+ Pattern mode for gpi1
+
+ dlg,gpi2-mode:
+ enum:
+ - Single-pattern
+ - Multi-pattern
+ description:
+ Pattern mode for gpi2
+
+ dlg,gpi0-polarity:
+ enum:
+ - Rising-edge
+ - Falling-edge
+ - Both-edge
+ description:
+ gpi0 polarity, Haptic will work by this edge option in case of ETWM mode
+
+ dlg,gpi1-polarity:
+ enum:
+ - Rising-edge
+ - Falling-edge
+ - Both-edge
+ description:
+ gpi1 polarity, Haptic will work by this edge option in case of ETWM mode
+
+ dlg,gpi2-polarity:
+ enum:
+ - Rising-edge
+ - Falling-edge
+ - Both-edge
+ description:
+ gpi2 polarity, Haptic will work by this edge option in case of ETWM mode
+
+ dlg,resonant-freq-hz:
+ minimum: 50
+ maximum: 300
+ default: 205
+
+ dlg,bemf-sens-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable for internal loop computations
+
+ dlg,freq-track-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable for resonant frequency tracking
+
+ dlg,acc-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable for active acceleration
+
+ dlg,rapid-stop-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable for rapid stop
+
+ dlg,amp-pid-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable for the amplitude PID
+
+ dlg,mem-array:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 100
+ description:
+ Customized waveform memory (patterns) data downloaded to the device during initialization.
+ Each entry value must be included between 0 and 255.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dlg,actuator-type
+ - dlg,const-op-mode
+ - dlg,periodic-op-mode
+ - dlg,nom-microvolt
+ - dlg,abs-max-microvolt
+ - dlg,imax-microamp
+ - dlg,impd-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ haptics@4a {
+ compatible = "dlg,da7280";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ dlg,actuator-type = "LRA";
+ dlg,const-op-mode = <1>;
+ dlg,periodic-op-mode = <1>;
+ dlg,nom-microvolt = <2000000>;
+ dlg,abs-max-microvolt = <2000000>;
+ dlg,imax-microamp = <170000>;
+ dlg,resonant-freq-hz = <180>;
+ dlg,impd-micro-ohms = <10500000>;
+ dlg,freq-track-enable;
+ dlg,rapid-stop-enable;
+ dlg,mem-array = <0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
new file mode 100644
index 000000000000..1480d95421e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/dlg,da9062-onkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog DA9061/62/63 OnKey Module
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ This module is part of the DA9061/DA9062/DA9063. For more details about entire
+ DA906{1,2,3} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+
+ This module provides the KEY_POWER event.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - dlg,da9062-onkey
+ - dlg,da9063-onkey
+ - items:
+ - const: dlg,da9061-onkey
+ - const: dlg,da9062-onkey
+
+ dlg,disable-key-power:
+ type: boolean
+ description:
+ Disable power-down using a long key-press. If this entry exists
+ the OnKey driver will remove support for the KEY_POWER key press
+ when triggered using a long press of the OnKey.
+
+required:
+ - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml
index 2a9bb6ace021..24dc2d69613f 100644
--- a/Documentation/devicetree/bindings/input/elan,ekth3000.yaml
+++ b/Documentation/devicetree/bindings/input/elan,ekth3000.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/elan,ekth3000.yaml#
diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
index 05e6f2df604c..0840e4ab28b7 100644
--- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
+++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
@@ -4,29 +4,48 @@
$id: http://devicetree.org/schemas/input/elan,ekth6915.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Elan eKTH6915 touchscreen controller
+title: Elan I2C-HID touchscreen controllers
maintainers:
- Douglas Anderson <dianders@chromium.org>
description:
- Supports the Elan eKTH6915 touchscreen controller.
- This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+ Supports the Elan eKTH6915 and other I2C-HID touchscreen controllers.
+ These touchscreen controller use the i2c-hid protocol with a reset GPIO.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
properties:
compatible:
- items:
- - const: elan,ekth6915
-
- reg:
- const: 0x10
+ oneOf:
+ - items:
+ - enum:
+ - elan,ekth5015m
+ - const: elan,ekth6915
+ - items:
+ - const: elan,ekth8d18
+ - const: elan,ekth6a12nay
+ - enum:
+ - elan,ekth6915
+ - elan,ekth6a12nay
+
+ reg: true
interrupts:
maxItems: 1
+ panel: true
+
reset-gpios:
description: Reset GPIO; not all touchscreens using eKTH6915 hook this up.
+ no-reset-on-power-off:
+ type: boolean
+ description:
+ Reset line is wired so that it can (and should) be left deasserted when
+ the power supply is off.
+
vcc33-supply:
description: The 3.3V supply to the touchscreen.
@@ -52,8 +71,8 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- ap_ts: touchscreen@10 {
- compatible = "elan,ekth6915";
+ touchscreen@10 {
+ compatible = "elan,ekth5015m", "elan,ekth6915";
reg = <0x10>;
interrupt-parent = <&tlmm>;
diff --git a/Documentation/devicetree/bindings/input/fsl,scu-key.yaml b/Documentation/devicetree/bindings/input/fsl,scu-key.yaml
index e6266d188266..29921aab9d97 100644
--- a/Documentation/devicetree/bindings/input/fsl,scu-key.yaml
+++ b/Documentation/devicetree/bindings/input/fsl,scu-key.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/fsl,scu-key.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - SCU key bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - SCU Key Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
@@ -24,6 +24,8 @@ properties:
linux,keycodes:
maxItems: 1
+ wakeup-source: true
+
required:
- compatible
- linux,keycodes
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
index fe1c5016f7f3..358cb8275bf1 100644
--- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
+++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
@@ -14,10 +14,16 @@ description:
This touchscreen uses the i2c-hid protocol but has some non-standard
power sequencing required.
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
properties:
compatible:
- items:
+ oneOf:
- const: goodix,gt7375p
+ - items:
+ - const: goodix,gt7986u
+ - const: goodix,gt7375p
reg:
enum:
@@ -27,12 +33,30 @@ properties:
interrupts:
maxItems: 1
+ panel: true
+
reset-gpios:
true
vdd-supply:
description: The 3.3V supply to the touchscreen.
+ mainboard-vddio-supply:
+ description:
+ The supply on the main board needed to power up IO signals going
+ to the touchscreen. This supply need not go to the touchscreen
+ itself as long as it allows the main board to make signals compatible
+ with what the touchscreen is expecting for its IO rails.
+
+ goodix,no-reset-during-suspend:
+ description:
+ Set this to true to enforce the driver to not assert the reset GPIO
+ during suspend.
+ Due to potential touchscreen hardware flaw, back-powering could happen in
+ suspend if the power supply is on and with active-low reset GPIO asserted.
+ This property is used to avoid the back-powering issue.
+ type: boolean
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7986u-spifw.yaml b/Documentation/devicetree/bindings/input/goodix,gt7986u-spifw.yaml
new file mode 100644
index 000000000000..92bd0041feba
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/goodix,gt7986u-spifw.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/goodix,gt7986u-spifw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Goodix GT7986U SPI HID Touchscreen
+
+maintainers:
+ - Charles Wang <charles.goodix@gmail.com>
+
+description: |
+ Supports the Goodix GT7986U touchscreen.
+ This touch controller reports data packaged according to the HID protocol
+ over the SPI bus, but it is incompatible with Microsoft's HID-over-SPI protocol.
+
+ NOTE: these bindings are distinct from the bindings used with the
+ GT7986U when the chip is running I2C firmware. This is because there's
+ not a single device that talks over both I2C and SPI but rather
+ distinct touchscreens that happen to be built with the same ASIC but
+ that are distinct products running distinct firmware.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - goodix,gt7986u-spifw
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ spi-max-frequency: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@0 {
+ compatible = "goodix,gt7986u-spifw";
+ reg = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <10000000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
index e05690b3e963..fefaaf46a240 100644
--- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
+++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
@@ -45,7 +45,7 @@ properties:
when the keyboard has a custom design for the top row keys.
dependencies:
- function-row-phsymap: [ 'linux,keymap' ]
+ function-row-physmap: [ 'linux,keymap' ]
google,needs-ghost-filter: [ 'linux,keymap' ]
required:
@@ -57,7 +57,7 @@ if:
contains:
const: google,cros-ec-keyb
then:
- $ref: "/schemas/input/matrix-keymap.yaml#"
+ $ref: /schemas/input/matrix-keymap.yaml#
required:
- keypad,num-rows
- keypad,num-columns
diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
deleted file mode 100644
index a5086e37fce6..000000000000
--- a/Documentation/devicetree/bindings/input/gpio-beeper.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* GPIO beeper device tree bindings
-
-Register a beeper connected to GPIO pin.
-
-Required properties:
-- compatible: Should be "gpio-beeper".
-- gpios: From common gpio binding; gpio connection to beeper enable pin.
-
-Example:
- beeper: beeper {
- compatible = "gpio-beeper";
- gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.yaml b/Documentation/devicetree/bindings/input/gpio-beeper.yaml
new file mode 100644
index 000000000000..290372add3d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-beeper.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/gpio-beeper.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO controlled beeper
+
+maintainers:
+ - Fabio Estevam <festevam@denx.de>
+
+properties:
+ compatible:
+ const: gpio-beeper
+
+ gpios:
+ maxItems: 1
+ description:
+ GPIO that drives the beeper.
+
+required:
+ - compatible
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ beeper {
+ compatible = "gpio-beeper";
+ gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml
index 17ac9dff7972..cc78c2152921 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys.yaml
+++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/gpio-keys.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device-Tree bindings for GPIO attached keys
+title: GPIO attached keys
maintainers:
- Rob Herring <robh@kernel.org>
@@ -31,7 +31,23 @@ patternProperties:
maxItems: 1
interrupts:
- maxItems: 1
+ oneOf:
+ - items:
+ - description: Optional key interrupt or wakeup interrupt
+ - items:
+ - description: Key interrupt
+ - description: Wakeup interrupt
+
+ interrupt-names:
+ description:
+ Optional interrupt names, can be used to specify a separate dedicated
+ wake-up interrupt in addition to the gpio irq
+ oneOf:
+ - items:
+ - enum: [ irq, wakeup ]
+ - items:
+ - const: irq
+ - const: wakeup
label:
description: Descriptive name of the key.
@@ -97,6 +113,20 @@ patternProperties:
- required:
- gpios
+ allOf:
+ - if:
+ properties:
+ interrupts:
+ minItems: 2
+ required:
+ - interrupts
+ then:
+ properties:
+ interrupt-names:
+ minItems: 2
+ required:
+ - interrupt-names
+
dependencies:
wakeup-event-action: [ wakeup-source ]
linux,input-value: [ gpios ]
@@ -137,6 +167,15 @@ examples:
linux,code = <108>;
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
};
+
+ key-wakeup {
+ label = "GPIO Key WAKEUP";
+ linux,code = <143>;
+ interrupts-extended = <&intc 2 IRQ_TYPE_EDGE_FALLING>,
+ <&intc_wakeup 0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "irq", "wakeup";
+ wakeup-source;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
deleted file mode 100644
index 570dc10f0cd7..000000000000
--- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* GPIO driven matrix keypad device tree bindings
-
-GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
-The matrix keypad supports multiple row and column lines, a key can be
-placed at each intersection of a unique row and a unique column. The matrix
-keypad can sense a key-press and key-release by means of GPIO lines and
-report the event using GPIO interrupts to the cpu.
-
-Required Properties:
-- compatible: Should be "gpio-matrix-keypad"
-- row-gpios: List of gpios used as row lines. The gpio specifier
- for this property depends on the gpio controller to
- which these row lines are connected.
-- col-gpios: List of gpios used as column lines. The gpio specifier
- for this property depends on the gpio controller to
- which these column lines are connected.
-- linux,keymap: The definition can be found at
- bindings/input/matrix-keymap.txt
-
-Optional Properties:
-- linux,no-autorepeat: do no enable autorepeat feature.
-- wakeup-source: use any event on keypad as wakeup event.
- (Legacy property supported: "linux,wakeup")
-- debounce-delay-ms: debounce interval in milliseconds
-- col-scan-delay-us: delay, measured in microseconds, that is needed
- before we can scan keypad after activating column gpio
-- drive-inactive-cols: drive inactive columns during scan,
- default is to turn inactive columns into inputs.
-
-Example:
- matrix-keypad {
- compatible = "gpio-matrix-keypad";
- debounce-delay-ms = <5>;
- col-scan-delay-us = <2>;
-
- row-gpios = <&gpio2 25 0
- &gpio2 26 0
- &gpio2 27 0>;
-
- col-gpios = <&gpio2 21 0
- &gpio2 22 0>;
-
- linux,keymap = <0x0000008B
- 0x0100009E
- 0x02000069
- 0x0001006A
- 0x0101001C
- 0x0201006C>;
- };
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
new file mode 100644
index 000000000000..ebfff9e42a36
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/input/gpio-matrix-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO matrix keypad
+
+maintainers:
+ - Marek Vasut <marek.vasut@gmail.com>
+
+description:
+ GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
+ The matrix keypad supports multiple row and column lines, a key can be
+ placed at each intersection of a unique row and a unique column. The matrix
+ keypad can sense a key-press and key-release by means of GPIO lines and
+ report the event using GPIO interrupts to the cpu.
+
+allOf:
+ - $ref: /schemas/input/matrix-keymap.yaml#
+
+properties:
+ compatible:
+ const: gpio-matrix-keypad
+
+ row-gpios:
+ description:
+ List of GPIOs used as row lines. The gpio specifier for this property
+ depends on the gpio controller to which these row lines are connected.
+
+ col-gpios:
+ description:
+ List of GPIOs used as column lines. The gpio specifier for this property
+ depends on the gpio controller to which these column lines are connected.
+
+ linux,keymap: true
+
+ linux,no-autorepeat:
+ type: boolean
+ description: Do not enable autorepeat feature.
+
+ gpio-activelow:
+ type: boolean
+ description:
+ Force GPIO polarity to active low.
+ In the absence of this property GPIOs are treated as active high.
+
+ debounce-delay-ms:
+ description: Debounce interval in milliseconds.
+ default: 0
+
+ col-scan-delay-us:
+ description:
+ Delay, measured in microseconds, that is needed
+ before we can scan keypad after activating column gpio.
+ default: 0
+
+ all-cols-on-delay-us:
+ description:
+ Delay, measured in microseconds, that is needed
+ after activating all column gpios.
+ default: 0
+
+ drive-inactive-cols:
+ type: boolean
+ description:
+ Drive inactive columns during scan,
+ default is to turn inactive columns into inputs.
+
+ wakeup-source: true
+
+required:
+ - compatible
+ - row-gpios
+ - col-gpios
+ - linux,keymap
+
+additionalProperties: false
+
+examples:
+ - |
+ matrix-keypad {
+ compatible = "gpio-matrix-keypad";
+ debounce-delay-ms = <5>;
+ col-scan-delay-us = <2>;
+
+ row-gpios = <&gpio2 25 0
+ &gpio2 26 0
+ &gpio2 27 0>;
+
+ col-gpios = <&gpio2 21 0
+ &gpio2 22 0>;
+
+ linux,keymap = <0x0000008B
+ 0x0100009E
+ 0x02000069
+ 0x0001006A
+ 0x0101001C
+ 0x0201006C>;
+
+ wakeup-source;
+ };
diff --git a/Documentation/devicetree/bindings/input/gpio-mouse.txt b/Documentation/devicetree/bindings/input/gpio-mouse.txt
deleted file mode 100644
index 519510a11af9..000000000000
--- a/Documentation/devicetree/bindings/input/gpio-mouse.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Device-Tree bindings for GPIO attached mice
-
-This simply uses standard GPIO handles to define a simple mouse connected
-to 5-7 GPIO lines.
-
-Required properties:
- - compatible: must be "gpio-mouse"
- - scan-interval-ms: The scanning interval in milliseconds
- - up-gpios: GPIO line phandle to the line indicating "up"
- - down-gpios: GPIO line phandle to the line indicating "down"
- - left-gpios: GPIO line phandle to the line indicating "left"
- - right-gpios: GPIO line phandle to the line indicating "right"
-
-Optional properties:
- - button-left-gpios: GPIO line handle to the left mouse button
- - button-middle-gpios: GPIO line handle to the middle mouse button
- - button-right-gpios: GPIO line handle to the right mouse button
-Example:
-
-#include <dt-bindings/gpio/gpio.h>
-
-gpio-mouse {
- compatible = "gpio-mouse";
- scan-interval-ms = <50>;
- up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
- down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
- left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
- right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
- button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
- button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
- button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/input/gpio-mouse.yaml b/Documentation/devicetree/bindings/input/gpio-mouse.yaml
new file mode 100644
index 000000000000..3928ec6aff1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-mouse.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/gpio-mouse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO attached mouse
+
+description: |
+ This simply uses standard GPIO handles to define a simple mouse connected
+ to 5-7 GPIO lines.
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+properties:
+ compatible:
+ const: gpio-mouse
+
+ scan-interval-ms:
+ maxItems: 1
+
+ up-gpios:
+ maxItems: 1
+
+ down-gpios:
+ maxItems: 1
+
+ left-gpios:
+ maxItems: 1
+
+ right-gpios:
+ maxItems: 1
+
+ button-left-gpios:
+ maxItems: 1
+
+ button-middle-gpios:
+ maxItems: 1
+
+ button-right-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - scan-interval-ms
+ - up-gpios
+ - down-gpios
+ - left-gpios
+ - right-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ gpio-mouse {
+ compatible = "gpio-mouse";
+ scan-interval-ms = <50>;
+ up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+ down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+ left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+ right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+ button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+ button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+ button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
deleted file mode 100644
index 34c43d3bddfd..000000000000
--- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* HID over I2C Device-Tree bindings
-
-HID over I2C provides support for various Human Interface Devices over the
-I2C bus. These devices can be for example touchpads, keyboards, touch screens
-or sensors.
-
-The specification has been written by Microsoft and is currently available here:
-http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
-
-If this binding is used, the kernel module i2c-hid will handle the communication
-with the device and the generic hid core layer will handle the protocol.
-
-Required properties:
-- compatible: must be "hid-over-i2c"
-- reg: i2c slave address
-- hid-descr-addr: HID descriptor address
-- interrupts: interrupt line
-
-Additional optional properties:
-
-Some devices may support additional optional properties to help with, e.g.,
-power sequencing. The following properties can be supported by one or more
-device-specific compatible properties, which should be used in addition to the
-"hid-over-i2c" string.
-
-- compatible:
- * "wacom,w9013" (Wacom W9013 digitizer). Supports:
- - vdd-supply (3.3V)
- - vddl-supply (1.8V)
- - post-power-on-delay-ms
-
-- vdd-supply: phandle of the regulator that provides the supply voltage.
-- post-power-on-delay-ms: time required by the device after enabling its regulators
- or powering it on, before it is ready for communication.
-- touchscreen-inverted-x: See touchscreen.txt
-- touchscreen-inverted-y: See touchscreen.txt
-
-Example:
-
- i2c-hid-dev@2c {
- compatible = "hid-over-i2c";
- reg = <0x2c>;
- hid-descr-addr = <0x0020>;
- interrupt-parent = <&gpx3>;
- interrupts = <3 2>;
- };
diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.yaml b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
new file mode 100644
index 000000000000..138caad96a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/hid-over-i2c.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/hid-over-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HID over I2C Devices
+
+maintainers:
+ - Benjamin Tissoires <benjamin.tissoires@redhat.com>
+ - Jiri Kosina <jkosina@suse.cz>
+
+description: |+
+ HID over I2C provides support for various Human Interface Devices over the
+ I2C bus. These devices can be for example touchpads, keyboards, touch screens
+ or sensors.
+
+ The specification has been written by Microsoft and is currently available here:
+ https://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
+
+ If this binding is used, the kernel module i2c-hid will handle the communication
+ with the device and the generic hid core layer will handle the protocol.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - wacom,w9013
+ - const: hid-over-i2c
+ - description: Just "hid-over-i2c" alone is allowed, but not recommended.
+ const: hid-over-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ hid-descr-addr:
+ description: HID descriptor address
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ panel: true
+
+ post-power-on-delay-ms:
+ description: Time required by the device after enabling its regulators
+ or powering it on, before it is ready for communication.
+
+ touchscreen-inverted-x: true
+
+ touchscreen-inverted-y: true
+
+ vdd-supply:
+ description: 3.3V supply
+
+ vddl-supply:
+ description: 1.8V supply
+
+ wakeup-source: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hid@2c {
+ compatible = "hid-over-i2c";
+ reg = <0x2c>;
+ hid-descr-addr = <0x0020>;
+ interrupts = <3 2>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/input/ibm,op-panel.yaml b/Documentation/devicetree/bindings/input/ibm,op-panel.yaml
new file mode 100644
index 000000000000..29a1879e356d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ibm,op-panel.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ibm,op-panel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM Operation Panel
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+allOf:
+ - $ref: input.yaml#
+
+description: |
+ The IBM Operation Panel provides a simple interface to control the connected
+ server. It has a display and three buttons: two directional arrows and one
+ 'Enter' button.
+
+properties:
+ compatible:
+ const: ibm,op-panel
+
+ reg:
+ maxItems: 1
+
+ linux,keycodes:
+ minItems: 1
+ maxItems: 3
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/i2c/i2c.h>
+ #include <dt-bindings/input/input.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ibm-op-panel@62 {
+ compatible = "ibm,op-panel";
+ reg = <(0x62 | I2C_OWN_SLAVE_ADDRESS)>;
+ linux,keycodes = <KEY_UP>, <KEY_DOWN>, <KEY_ENTER>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/ilitek,ili2901.yaml b/Documentation/devicetree/bindings/input/ilitek,ili2901.yaml
new file mode 100644
index 000000000000..1abeec768d79
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ilitek,ili2901.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ilitek,ili2901.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI2901 touchscreen controller
+
+maintainers:
+ - Jiri Kosina <jkosina@suse.com>
+
+description:
+ Supports the Ilitek ILI2901 touchscreen controller.
+ This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ilitek,ili2901
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ panel: true
+
+ reset-gpios:
+ maxItems: 1
+
+ vcc33-supply: true
+
+ vccio-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vcc33-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2901";
+ reg = <0x41>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>;
+ vcc33-supply = <&pp3300_ts>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
new file mode 100644
index 000000000000..c5d9e0e919f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ilitek,ili9882t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ili9882t touchscreen controller
+
+maintainers:
+ - Cong Yang <yangcong5@huaqin.corp-partner.google.com>
+
+description:
+ Supports the Ilitek ili9882t touchscreen controller.
+ This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+properties:
+ compatible:
+ const: ilitek,ili9882t
+
+ reg:
+ const: 0x41
+
+ interrupts:
+ maxItems: 1
+
+ panel: true
+
+ reset-gpios:
+ maxItems: 1
+ description: Reset GPIO.
+
+ vccio-supply:
+ description: The 1.8V supply to the touchscreen.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - panel
+ - vccio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen: touchscreen@41 {
+ compatible = "ilitek,ili9882t";
+ reg = <0x41>;
+
+ interrupt-parent = <&pio>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+
+ panel = <&panel>;
+ reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
+ vccio-supply = <&mt6366_vio18_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/imx-keypad.yaml b/Documentation/devicetree/bindings/input/imx-keypad.yaml
index f21db81206b4..b110eb1f3358 100644
--- a/Documentation/devicetree/bindings/input/imx-keypad.yaml
+++ b/Documentation/devicetree/bindings/input/imx-keypad.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/input/imx-keypad.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX Keypad Port(KPP) device tree bindings
+title: Freescale i.MX Keypad Port(KPP)
maintainers:
- Liu Ying <gnuiyl@gmail.com>
allOf:
- - $ref: "/schemas/input/matrix-keymap.yaml#"
+ - $ref: /schemas/input/matrix-keymap.yaml#
description: |
The KPP is designed to interface with a keypad matrix with 2-point contact
diff --git a/Documentation/devicetree/bindings/input/input.yaml b/Documentation/devicetree/bindings/input/input.yaml
index 17512f4347fd..94f7942189e8 100644
--- a/Documentation/devicetree/bindings/input/input.yaml
+++ b/Documentation/devicetree/bindings/input/input.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/input.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common input schema binding
+title: Input Devices Common Properties
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff --git a/Documentation/devicetree/bindings/input/iqs269a.yaml b/Documentation/devicetree/bindings/input/iqs269a.yaml
index 3c430d38594f..2c3f693b8982 100644
--- a/Documentation/devicetree/bindings/input/iqs269a.yaml
+++ b/Documentation/devicetree/bindings/input/iqs269a.yaml
@@ -9,6 +9,9 @@ title: Azoteq IQS269A Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
+allOf:
+ - $ref: input.yaml#
+
description: |
The Azoteq IQS269A is an 8-channel capacitive touch controller that features
additional Hall-effect and inductive sensing capabilities.
@@ -17,7 +20,10 @@ description: |
properties:
compatible:
- const: azoteq,iqs269a
+ enum:
+ - azoteq,iqs269a
+ - azoteq,iqs269a-00
+ - azoteq,iqs269a-d0
reg:
maxItems: 1
@@ -204,6 +210,73 @@ properties:
default: 1
description: Specifies the slider coordinate filter strength.
+ azoteq,touch-hold-ms:
+ multipleOf: 256
+ minimum: 256
+ maximum: 65280
+ default: 5120
+ description:
+ Specifies the length of time (in ms) for which the channel selected by
+ 'azoteq,gpio3-select' must be held in a state of touch in order for an
+ approximately 60-ms pulse to be asserted on the GPIO4 pin.
+
+ linux,keycodes:
+ minItems: 1
+ maxItems: 8
+ description: |
+ Specifies the numeric keycodes associated with each available gesture in
+ the following order (enter 0 for unused gestures):
+ 0: Slider 0 tap
+ 1: Slider 0 hold
+ 2: Slider 0 positive flick or swipe
+ 3: Slider 0 negative flick or swipe
+ 4: Slider 1 tap
+ 5: Slider 1 hold
+ 6: Slider 1 positive flick or swipe
+ 7: Slider 1 negative flick or swipe
+
+ azoteq,gesture-swipe:
+ type: boolean
+ description:
+ Directs the device to interpret axial gestures as a swipe (finger remains
+ on slider) instead of a flick (finger leaves slider).
+
+ azoteq,timeout-tap-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ default: 400
+ description:
+ Specifies the length of time (in ms) within which a slider touch must be
+ released in order to be interpreted as a tap. Default and maximum values
+ as well as step size are reduced by a factor of 4 with device version 2.
+
+ azoteq,timeout-swipe-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ default: 2000
+ description:
+ Specifies the length of time (in ms) within which an axial gesture must be
+ completed in order to be interpreted as a flick or swipe. Default and max-
+ imum values as well as step size are reduced by a factor of 4 with device
+ version 2.
+
+ azoteq,thresh-swipe:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ default: 128
+ description:
+ Specifies the number of points across which an axial gesture must travel
+ in order to be interpreted as a flick or swipe.
+
+dependencies:
+ azoteq,gesture-swipe: ["linux,keycodes"]
+ azoteq,timeout-tap-ms: ["linux,keycodes"]
+ azoteq,timeout-swipe-ms: ["linux,keycodes"]
+ azoteq,thresh-swipe: ["linux,keycodes"]
+
patternProperties:
"^channel@[0-7]$":
type: object
@@ -454,6 +527,21 @@ patternProperties:
additionalProperties: false
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - azoteq,iqs269a-d0
+then:
+ patternProperties:
+ "^channel@[0-7]$":
+ properties:
+ azoteq,slider1-select: false
+else:
+ properties:
+ azoteq,touch-hold-ms: false
+
required:
- compatible
- reg
@@ -484,6 +572,14 @@ examples:
azoteq,hall-enable;
azoteq,suspend-mode = <2>;
+ linux,keycodes = <KEY_PLAYPAUSE>,
+ <KEY_STOPCD>,
+ <KEY_NEXTSONG>,
+ <KEY_PREVIOUSSONG>;
+
+ azoteq,timeout-tap-ms = <400>;
+ azoteq,timeout-swipe-ms = <800>;
+
channel@0 {
reg = <0x0>;
diff --git a/Documentation/devicetree/bindings/input/iqs626a.yaml b/Documentation/devicetree/bindings/input/iqs626a.yaml
index 7a27502095f3..e424d67b0542 100644
--- a/Documentation/devicetree/bindings/input/iqs626a.yaml
+++ b/Documentation/devicetree/bindings/input/iqs626a.yaml
@@ -564,16 +564,6 @@ patternProperties:
2: Partial
3: Full
- azoteq,ati-base:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 6
- maxItems: 9
- items:
- minimum: 45
- maximum: 300
- default: [45, 45, 45, 45, 45, 45, 45, 45, 45]
- description: Specifies each individual trackpad channel's ATI base.
-
azoteq,ati-target:
$ref: /schemas/types.yaml#/definitions/uint32
multipleOf: 32
@@ -620,17 +610,6 @@ patternProperties:
description:
Tightens the ATI band from 1/8 to 1/16 of the desired target.
- azoteq,thresh:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 6
- maxItems: 9
- items:
- minimum: 0
- maximum: 255
- default: [0, 0, 0, 0, 0, 0, 0, 0, 0]
- description:
- Specifies each individual trackpad channel's touch threshold.
-
azoteq,hyst:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
@@ -720,6 +699,28 @@ patternProperties:
Specifies the number of points across which an axial gesture must
travel in order to be interpreted as a flick or swipe.
+ patternProperties:
+ "^channel-[0-8]$":
+ type: object
+ description: Represents a single trackpad channel.
+
+ properties:
+ azoteq,thresh:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ default: 0
+ description: Specifies the threshold for the channel.
+
+ azoteq,ati-base:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 45
+ maximum: 300
+ default: 45
+ description: Specifies the channel's ATI base.
+
+ additionalProperties: false
+
dependencies:
azoteq,gesture-swipe: ["linux,keycodes"]
azoteq,timeout-tap-ms: ["linux,keycodes"]
@@ -780,14 +781,8 @@ examples:
azoteq,filt-str-lp-cnt = <1>;
azoteq,hyst = <4>;
- azoteq,thresh = <35>, <40>, <40>,
- <38>, <33>, <38>,
- <35>, <35>, <35>;
azoteq,ati-mode = <3>;
- azoteq,ati-base = <195>, <195>, <195>,
- <195>, <195>, <195>,
- <195>, <195>, <195>;
azoteq,ati-target = <512>;
azoteq,proj-bias = <1>;
@@ -804,6 +799,51 @@ examples:
azoteq,timeout-swipe-ms = <800>;
azoteq,timeout-tap-ms = <400>;
azoteq,thresh-swipe = <40>;
+
+ channel-0 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-1 {
+ azoteq,thresh = <40>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-2 {
+ azoteq,thresh = <40>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-3 {
+ azoteq,thresh = <38>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-4 {
+ azoteq,thresh = <33>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-5 {
+ azoteq,thresh = <38>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-6 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-7 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
+
+ channel-8 {
+ azoteq,thresh = <35>;
+ azoteq,ati-base = <195>;
+ };
};
/*
diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
deleted file mode 100644
index 2b075a080d30..000000000000
--- a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-NXP LPC32xx Key Scan Interface
-
-This binding is based on the matrix-keymap binding with the following
-changes:
-
-Required Properties:
-- compatible: Should be "nxp,lpc3220-key"
-- reg: Physical base address of the controller and length of memory mapped
- region.
-- interrupts: The interrupt number to the cpu.
-- clocks: phandle to clock controller plus clock-specifier pair
-- nxp,debounce-delay-ms: Debounce delay in ms
-- nxp,scan-delay-ms: Repeated scan period in ms
-- linux,keymap: the key-code to be reported when the key is pressed
- and released, see also
- Documentation/devicetree/bindings/input/matrix-keymap.txt
-
-Note: keypad,num-rows and keypad,num-columns are required, and must be equal
-since LPC32xx only supports square matrices
-
-Example:
-
- key@40050000 {
- compatible = "nxp,lpc3220-key";
- reg = <0x40050000 0x1000>;
- clocks = <&clk LPC32XX_CLK_KEY>;
- interrupt-parent = <&sic1>;
- interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
- keypad,num-rows = <1>;
- keypad,num-columns = <1>;
- nxp,debounce-delay-ms = <3>;
- nxp,scan-delay-ms = <34>;
- linux,keymap = <0x00000002>;
- };
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.yaml b/Documentation/devicetree/bindings/input/matrix-keymap.yaml
index 6699d5e32dca..a715c2a773fe 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.yaml
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/matrix-keymap.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common key matrices binding for matrix-connected key boards
+title: Common Key Matrices on Matrix-connected Key Boards
maintainers:
- Olof Johansson <olof@lixom.net>
@@ -21,7 +21,7 @@ description: |
properties:
linux,keymap:
- $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: |
An array of packed 1-cell entries containing the equivalent of row,
column and linux key-code. The 32-bit big endian cell is packed as:
diff --git a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
index 03ebd2665d07..e365413732e7 100644
--- a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
+++ b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/input/mediatek,mt6779-keypad.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek's Keypad Controller device tree bindings
+title: Mediatek's Keypad Controller
maintainers:
- - Mattijs Korpershoek <mkorpershoek@baylibre.com>
+ - Mattijs Korpershoek <mkorpershoek@kernel.org>
allOf:
- - $ref: "/schemas/input/matrix-keymap.yaml#"
+ - $ref: /schemas/input/matrix-keymap.yaml#
description: |
Mediatek's Keypad controller is used to interface a SoC with a matrix-type
@@ -26,6 +26,9 @@ properties:
- items:
- enum:
- mediatek,mt6873-keypad
+ - mediatek,mt8183-keypad
+ - mediatek,mt8365-keypad
+ - mediatek,mt8516-keypad
- const: mediatek,mt6779-keypad
reg:
@@ -49,6 +52,12 @@ properties:
maximum: 256
default: 16
+ mediatek,keys-per-group:
+ description: each (row, column) group has multiple keys
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ maximum: 2
+
required:
- compatible
- reg
@@ -56,7 +65,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
new file mode 100644
index 000000000000..b95435bd6a9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/mediatek,pmic-keys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek PMIC Keys
+
+maintainers:
+ - Chen Zhong <chen.zhong@mediatek.com>
+
+allOf:
+ - $ref: input.yaml#
+
+description: |
+ There are two key functions provided by MT6397, MT6323 and other MediaTek
+ PMICs: pwrkey and homekey.
+ The key functions are defined as the subnode of the function node provided
+ by the PMIC that is defined as a Multi-Function Device (MFD).
+
+ For MediaTek MT6323/MT6397 PMIC bindings see
+ Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6323-keys
+ - mediatek,mt6328-keys
+ - mediatek,mt6331-keys
+ - mediatek,mt6357-keys
+ - mediatek,mt6358-keys
+ - mediatek,mt6359-keys
+ - mediatek,mt6397-keys
+
+ power-off-time-sec: true
+
+ mediatek,long-press-mode:
+ description: |
+ Key long-press force shutdown setting
+ 0 - disabled
+ 1 - pwrkey
+ 2 - pwrkey+homekey
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ maximum: 2
+
+patternProperties:
+ "^((power|home)|(key-[a-z0-9-]+|[a-z0-9-]+-key))$":
+ $ref: input.yaml#
+
+ properties:
+ interrupts:
+ minItems: 1
+ items:
+ - description: Key press interrupt
+ - description: Key release interrupt
+
+ interrupt-names: true
+
+ linux,keycodes:
+ maxItems: 1
+
+ wakeup-source: true
+
+ required:
+ - linux,keycodes
+
+ if:
+ properties:
+ interrupt-names:
+ contains:
+ const: powerkey
+ then:
+ properties:
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: powerkey
+ - const: powerkey_r
+ else:
+ properties:
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: homekey
+ - const: homekey_r
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 96358b12f9b2..7ade03f1b32b 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/input/microchip,cap11xx.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/input/microchip,cap11xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device tree bindings for Microchip CAP11xx based capacitive touch sensors
+title: Microchip CAP11xx based capacitive touch sensors
description: |
The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive
@@ -19,7 +19,10 @@ properties:
- microchip,cap1106
- microchip,cap1126
- microchip,cap1188
+ - microchip,cap1203
- microchip,cap1206
+ - microchip,cap1293
+ - microchip,cap1298
reg:
maxItems: 1
@@ -42,13 +45,13 @@ properties:
Enables the Linux input system's autorepeat feature on the input device.
linux,keycodes:
- minItems: 6
- maxItems: 6
+ minItems: 3
+ maxItems: 8
description: |
Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as defaults.
- The array must have exactly six entries.
+ The number of entries must correspond to the number of channels.
microchip,sensor-gain:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -67,6 +70,59 @@ properties:
open drain. This property allows using the active
high push-pull output.
+ microchip,sensitivity-delta-sense:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 32
+ enum: [1, 2, 4, 8, 16, 32, 64, 128]
+ description:
+ Controls the sensitivity multiplier of a touch detection.
+ Higher value means more sensitive settings.
+ At the more sensitive settings, touches are detected for a smaller delta
+ capacitance corresponding to a "lighter" touch.
+
+ microchip,signal-guard:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 8
+ items:
+ enum: [0, 1]
+ description: |
+ 0 - off
+ 1 - on
+ The signal guard isolates the signal from virtual grounds.
+ If enabled then the behavior of the channel is changed to signal guard.
+ The number of entries must correspond to the number of channels.
+
+ microchip,input-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 127
+ description:
+ Specifies the delta threshold that is used to determine if a touch has
+ been detected. A higher value means a larger difference in capacitance
+ is required for a touch to be registered, making the touch sensor less
+ sensitive.
+ The number of entries must correspond to the number of channels.
+
+ microchip,calib-sensitivity:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 8
+ items:
+ enum: [1, 2, 4]
+ description: |
+ Specifies an array of numeric values that controls the gain
+ used by the calibration routine to enable sensor inputs
+ to be more sensitive for proximity detection.
+ Gain is based on touch pad capacitance range
+ 1 - 5-50pF
+ 2 - 0-25pF
+ 4 - 0-12.5pF
+ The number of entries must correspond to the number of channels.
+
patternProperties:
"^led@[0-7]$":
type: object
@@ -96,10 +152,29 @@ allOf:
contains:
enum:
- microchip,cap1106
+ - microchip,cap1203
+ - microchip,cap1206
+ - microchip,cap1293
+ - microchip,cap1298
then:
patternProperties:
"^led@[0-7]$": false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1106
+ - microchip,cap1126
+ - microchip,cap1188
+ - microchip,cap1203
+ - microchip,cap1206
+ then:
+ properties:
+ microchip,signal-guard: false
+ microchip,calib-sensitivity: false
+
required:
- compatible
- interrupts
@@ -119,6 +194,8 @@ examples:
reg = <0x28>;
autorepeat;
microchip,sensor-gain = <2>;
+ microchip,sensitivity-delta-sense = <16>;
+ microchip,input-threshold = <21>, <18>, <46>, <46>, <46>, <21>;
linux,keycodes = <103>, /* KEY_UP */
<106>, /* KEY_RIGHT */
diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
deleted file mode 100644
index 9d00f2a8e13a..000000000000
--- a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-MediaTek MT6397/MT6323 PMIC Keys Device Driver
-
-There are two key functions provided by MT6397/MT6323 PMIC, pwrkey
-and homekey. The key functions are defined as the subnode of the function
-node provided by MT6397/MT6323 PMIC that is being defined as one kind
-of Muti-Function Device (MFD)
-
-For MT6397/MT6323 MFD bindings see:
-Documentation/devicetree/bindings/mfd/mt6397.txt
-
-Required properties:
-- compatible: Should be one of:
- - "mediatek,mt6397-keys"
- - "mediatek,mt6323-keys"
- - "mediatek,mt6358-keys"
-- linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml
-
-Optional Properties:
-- wakeup-source: See Documentation/devicetree/bindings/power/wakeup-source.txt
-- mediatek,long-press-mode: Long press key shutdown setting, 1 for
- pwrkey only, 2 for pwrkey/homekey together, others for disabled.
-- power-off-time-sec: See Documentation/devicetree/bindings/input/input.yaml
-
-Example:
-
- pmic: mt6397 {
- compatible = "mediatek,mt6397";
-
- ...
-
- mt6397keys: mt6397keys {
- compatible = "mediatek,mt6397-keys";
- mediatek,long-press-mode = <1>;
- power-off-time-sec = <0>;
-
- power {
- linux,keycodes = <116>;
- wakeup-source;
- };
-
- home {
- linux,keycodes = <114>;
- };
- };
-
- };
diff --git a/Documentation/devicetree/bindings/input/nxp,lpc3220-key.yaml b/Documentation/devicetree/bindings/input/nxp,lpc3220-key.yaml
new file mode 100644
index 000000000000..9e0d977bdf5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/nxp,lpc3220-key.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/nxp,lpc3220-key.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx Key Scan Interface
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc3220-key
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ nxp,debounce-delay-ms:
+ description: Debounce delay in ms
+
+ nxp,scan-delay-ms:
+ description: Repeated scan period in ms
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - nxp,debounce-delay-ms
+ - nxp,scan-delay-ms
+ - linux,keymap
+
+allOf:
+ - $ref: matrix-keymap.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/lpc32xx-clock.h>
+
+ key@40050000 {
+ compatible = "nxp,lpc3220-key";
+ reg = <0x40050000 0x1000>;
+ clocks = <&clk LPC32XX_CLK_KEY>;
+ interrupt-parent = <&sic1>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ keypad,num-rows = <1>;
+ keypad,num-columns = <1>;
+ nxp,debounce-delay-ms = <3>;
+ nxp,scan-delay-ms = <34>;
+ linux,keymap = <0x00000002>;
+ };
diff --git a/Documentation/devicetree/bindings/input/pine64,pinephone-keyboard.yaml b/Documentation/devicetree/bindings/input/pine64,pinephone-keyboard.yaml
new file mode 100644
index 000000000000..490f6c3d9e4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pine64,pinephone-keyboard.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/pine64,pinephone-keyboard.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Pine64 PinePhone keyboard
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ A keyboard accessory is available for the Pine64 PinePhone and PinePhone Pro.
+ It connects via I2C, providing a raw scan matrix, a flashing interface, and a
+ subordinate I2C bus for communication with a battery charger IC.
+
+properties:
+ compatible:
+ const: pine64,pinephone-keyboard
+
+ reg:
+ const: 0x15
+
+ interrupts:
+ maxItems: 1
+
+ vbat-supply:
+ description: Supply for the keyboard MCU
+
+ wakeup-source: true
+
+ i2c:
+ $ref: /schemas/i2c/i2c-controller.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ keyboard@15 {
+ compatible = "pine64,pinephone-keyboard";
+ reg = <0x15>;
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 12 IRQ_TYPE_EDGE_FALLING>; /* PL12 */
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@75 {
+ reg = <0x75>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt
deleted file mode 100644
index 8fc0e48c20db..000000000000
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* PWM beeper device tree bindings
-
-Registers a PWM device as beeper.
-
-Required properties:
-- compatible: should be "pwm-beeper"
-- pwms: phandle to the physical PWM device
-
-Optional properties:
-- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
-- beeper-hz: bell frequency in Hz
-
-Example:
-
-beeper_amp: amplifier {
- compatible = "fixed-regulator";
- gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-};
-
-beeper {
- compatible = "pwm-beeper";
- pwms = <&pwm0>;
- amp-supply = <&beeper_amp>;
-};
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
new file mode 100644
index 000000000000..a7611c206989
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/pwm-beeper.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM beeper
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ const: pwm-beeper
+
+ pwms:
+ maxItems: 1
+
+ amp-supply:
+ description: an amplifier for the beeper
+
+ beeper-hz:
+ description: bell frequency in Hz
+ minimum: 10
+ maximum: 10000
+
+required:
+ - compatible
+ - pwms
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm0>;
+ amp-supply = <&beeper_amp>;
+ beeper-hz = <1000>;
+ };
diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
index a70a636ee112..6398534b43c3 100644
--- a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
+++ b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/input/pwm-vibrator.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/input/pwm-vibrator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: PWM vibrator
@@ -32,6 +32,8 @@ properties:
minItems: 1
maxItems: 2
+ enable-gpios: true
+
vcc-supply: true
direction-duty-cycle-ns:
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml b/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml
new file mode 100644
index 000000000000..e03611eef93d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/qcom,pm8921-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8921 PMIC KeyPad
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+allOf:
+ - $ref: input.yaml#
+ - $ref: matrix-keymap.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,pm8058-keypad
+ - qcom,pm8921-keypad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: key sense
+ - description: key stuck
+
+ wakeup-source:
+ type: boolean
+ description: use any event on keypad as wakeup event
+
+ linux,keypad-wakeup:
+ type: boolean
+ deprecated: true
+ description: legacy version of the wakeup-source property
+
+ debounce:
+ description:
+ Time in microseconds that key must be pressed or
+ released for state change interrupt to trigger.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ scan-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: time in microseconds to pause between successive scans of the
+ matrix array
+
+ row-hold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: time in nanoseconds to pause between scans of each row in the
+ matrix array.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - linux,keymap
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ keypad@148 {
+ compatible = "qcom,pm8921-keypad";
+ reg = <0x148>;
+ interrupt-parent = <&pmicintc>;
+ interrupts = <74 IRQ_TYPE_EDGE_RISING>, <75 IRQ_TYPE_EDGE_RISING>;
+ linux,keymap = <
+ MATRIX_KEY(0, 0, KEY_VOLUMEUP)
+ MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
+ MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
+ MATRIX_KEY(0, 3, KEY_CAMERA)
+ >;
+ keypad,num-rows = <1>;
+ keypad,num-columns = <5>;
+ debounce = <15>;
+ scan-delay = <32>;
+ row-hold = <91500>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml b/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml
new file mode 100644
index 000000000000..64590894857a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/qcom,pm8921-pwrkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8921 PMIC Power Key
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,pm8921-pwrkey
+ - qcom,pm8058-pwrkey
+ - items:
+ - enum:
+ - qcom,pm8018-pwrkey
+ - const: qcom,pm8921-pwrkey
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: key release
+ - description: key press
+
+ debounce:
+ description:
+ Time in microseconds that key must be pressed or
+ released for state change interrupt to trigger.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pull-up:
+ description:
+ Presence of this property indicates that the KPDPWR_N
+ pin should be configured for pull up.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ ssbi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pwrkey@1c {
+ compatible = "qcom,pm8921-pwrkey";
+ reg = <0x1c>;
+ interrupt-parent = <&pmicint>;
+ interrupts = <50 IRQ_TYPE_EDGE_RISING>, <51 IRQ_TYPE_EDGE_RISING>;
+ debounce = <15625>;
+ pull-up;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
index 62314a5fdce5..f978cf965a4d 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
@@ -10,9 +10,6 @@ maintainers:
- Courtney Cavin <courtney.cavin@sonymobile.com>
- Vinod Koul <vkoul@kernel.org>
-allOf:
- - $ref: input.yaml#
-
properties:
compatible:
enum:
@@ -25,23 +22,40 @@ properties:
maxItems: 1
debounce:
- description: |
- Time in microseconds that key must be pressed or
- released for state change interrupt to trigger.
+ description:
+ Time in microseconds that key must be pressed or released for state
+ change interrupt to trigger.
$ref: /schemas/types.yaml#/definitions/uint32
bias-pull-up:
- description: |
- Presence of this property indicates that the KPDPWR_N
- pin should be configured for pull up.
+ description:
+ Presence of this property indicates that the KPDPWR_N pin should be
+ configured for pull up.
$ref: /schemas/types.yaml#/definitions/flag
+ wakeup-source:
+ description:
+ Button can wake-up the system. Only applicable for 'resin', 'pwrkey'
+ always wakes the system by default.
+
linux,code:
- description: |
- The input key-code associated with the power key.
- Use the linux event codes defined in
- include/dt-bindings/input/linux-event-codes.h
- When property is omitted KEY_POWER is assumed.
+ description:
+ The input key-code associated with the power key. Use the linux event
+ codes defined in include/dt-bindings/input/linux-event-codes.h.
+ When property is omitted KEY_POWER is assumed.
+
+allOf:
+ - $ref: input.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pm8941-pwrkey
+ - qcom,pmk8350-pwrkey
+ then:
+ properties:
+ wakeup-source: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
deleted file mode 100644
index 4a9dc6ba96b1..000000000000
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Qualcomm PM8xxx PMIC Keypad
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,pm8058-keypad"
- "qcom,pm8921-keypad"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: address of keypad control register
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the first interrupt specifies the key sense interrupt
- and the second interrupt specifies the key stuck interrupt.
- The format of the specifier is defined by the binding
- document describing the node's interrupt parent.
-
-- linux,keymap:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the linux keymap. More information can be found in
- input/matrix-keymap.txt.
-
-- linux,keypad-no-autorepeat:
- Usage: optional
- Value type: <bool>
- Definition: don't enable autorepeat feature.
-
-- wakeup-source:
- Usage: optional
- Value type: <bool>
- Definition: use any event on keypad as wakeup event.
- (Legacy property supported: "linux,keypad-wakeup")
-
-- keypad,num-rows:
- Usage: required
- Value type: <u32>
- Definition: number of rows in the keymap. More information can be found
- in input/matrix-keymap.txt.
-
-- keypad,num-columns:
- Usage: required
- Value type: <u32>
- Definition: number of columns in the keymap. More information can be
- found in input/matrix-keymap.txt.
-
-- debounce:
- Usage: optional
- Value type: <u32>
- Definition: time in microseconds that key must be pressed or release
- for key sense interrupt to trigger.
-
-- scan-delay:
- Usage: optional
- Value type: <u32>
- Definition: time in microseconds to pause between successive scans
- of the matrix array.
-
-- row-hold:
- Usage: optional
- Value type: <u32>
- Definition: time in nanoseconds to pause between scans of each row in
- the matrix array.
-
-EXAMPLE
-
- keypad@148 {
- compatible = "qcom,pm8921-keypad";
- reg = <0x148>;
- interrupt-parent = <&pmicintc>;
- interrupts = <74 1>, <75 1>;
- linux,keymap = <
- MATRIX_KEY(0, 0, KEY_VOLUMEUP)
- MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
- MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
- MATRIX_KEY(0, 3, KEY_CAMERA)
- >;
- keypad,num-rows = <1>;
- keypad,num-columns = <5>;
- debounce = <15>;
- scan-delay = <32>;
- row-hold = <91500>;
- };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
deleted file mode 100644
index 588536cc96ed..000000000000
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Qualcomm PM8xxx PMIC Power Key
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,pm8058-pwrkey"
- "qcom,pm8921-pwrkey"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: address of power key control register
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the first interrupt specifies the key release interrupt
- and the second interrupt specifies the key press interrupt.
- The format of the specifier is defined by the binding
- document describing the node's interrupt parent.
-
-- debounce:
- Usage: optional
- Value type: <u32>
- Definition: time in microseconds that key must be pressed or release
- for state change interrupt to trigger.
-
-- pull-up:
- Usage: optional
- Value type: <empty>
- Definition: presence of this property indicates that the KPDPWR_N pin
- should be configured for pull up.
-
-EXAMPLE
-
- pwrkey@1c {
- compatible = "qcom,pm8921-pwrkey";
- reg = <0x1c>;
- interrupt-parent = <&pmicintc>;
- interrupts = <50 1>, <51 1>;
- debounce = <15625>;
- pull-up;
- };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
deleted file mode 100644
index 64bb990075c3..000000000000
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Qualcomm PM8xxx PMIC Vibrator
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,pm8058-vib"
- "qcom,pm8916-vib"
- "qcom,pm8921-vib"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: address of vibration control register
-
-EXAMPLE
-
- vibrator@4a {
- compatible = "qcom,pm8058-vib";
- reg = <0x4a>;
- };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
new file mode 100644
index 000000000000..76a286ec5959
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/qcom,pm8xxx-vib.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8xxx PMIC Vibrator
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,pm8058-vib
+ - qcom,pm8916-vib
+ - qcom,pm8921-vib
+ - qcom,pmi632-vib
+ - items:
+ - enum:
+ - qcom,pm6150-vib
+ - qcom,pm7250b-vib
+ - qcom,pm7325b-vib
+ - qcom,pm7550ba-vib
+ - const: qcom,pmi632-vib
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vibrator@4a {
+ compatible = "qcom,pm8058-vib";
+ reg = <0x4a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.yaml b/Documentation/devicetree/bindings/input/regulator-haptic.yaml
index b1ae72f9cd2d..cf63f834dd7d 100644
--- a/Documentation/devicetree/bindings/input/regulator-haptic.yaml
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/input/regulator-haptic.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/input/regulator-haptic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Regulator Haptic Device Tree Bindings
+title: Regulator Haptic
maintainers:
- Jaewon Kim <jaewon02.kim@samsung.com>
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
deleted file mode 100644
index 9afffbdf6e28..000000000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Synaptics RMI4 2D Sensor Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices which contain 2D sensors using Function 11 or
-Function 12. Complete documentation for transports and other functions
-can be found in:
-Documentation/devicetree/bindings/input/rmi4.
-
-RMI4 Function 11 and Function 12 are for 2D touch position sensing.
-Additional documentation for F11 can be found at:
-http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
-
-Optional Touch Properties:
-Description in Documentation/devicetree/bindings/input/touchscreen
-- touchscreen-inverted-x
-- touchscreen-inverted-y
-- touchscreen-swapped-x-y
-- touchscreen-x-mm
-- touchscreen-y-mm
-
-Optional Properties:
-- syna,clip-x-low: Sets a minimum value for X.
-- syna,clip-y-low: Sets a minimum value for Y.
-- syna,clip-x-high: Sets a maximum value for X.
-- syna,clip-y-high: Sets a maximum value for Y.
-- syna,offset-x: Add an offset to X.
-- syna,offset-y: Add an offset to Y.
-- syna,delta-x-threshold: Set the minimum distance on the X axis required
- to generate an interrupt in reduced reporting
- mode.
-- syna,delta-y-threshold: Set the minimum distance on the Y axis required
- to generate an interrupt in reduced reporting
- mode.
-- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad.
-- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to
- disable reporing absolute position data.
-- syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero
- command.
-
-
-Example of a RMI4 I2C device with F11:
-Example:
- &i2c1 {
- rmi4-i2c-dev@2c {
- compatible = "syna,rmi4-i2c";
-
- ...
-
- rmi4-f11@11 {
- reg = <0x11>;
- touchscreen-inverted-y;
- syna,sensor-type = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
deleted file mode 100644
index 079cad2b6843..000000000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Synaptics RMI4 F01 Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices which contain Function 1. Complete documentation
-for transports and other functions can be found in:
-Documentation/devicetree/bindings/input/rmi4.
-
-Additional documentation for F01 can be found at:
-http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
-
-Optional Properties:
-- syna,nosleep-mode: If set the device will run at full power without sleeping.
- nosleep has 3 modes, 0 will not change the default
- setting, 1 will disable nosleep (allow sleeping),
- and 2 will enable nosleep (disabling sleep).
-- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
- background capacitance that will cause the
- device to wake from dozing.
-- syna,doze-holdoff-ms: The delay to wait after the last finger lift and the
- first doze cycle.
-- syna,doze-interval-ms: The time period that the device sleeps between finger
- activity.
-
-
-Example of a RMI4 I2C device with F01:
- Example:
- &i2c1 {
- rmi4-i2c-dev@2c {
- compatible = "syna,rmi4-i2c";
-
- ...
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
deleted file mode 100644
index dcb012f5b3ee..000000000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Synaptics RMI4 I2C Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices using the I2C transport driver. Complete documentation
-for other transports and functions can be found in
-Documentation/devicetree/bindings/input/rmi4.
-
-Required Properties:
-- compatible: syna,rmi4-i2c
-- reg: I2C address
-- #address-cells: Set to 1 to indicate that the function child nodes
- consist of only on uint32 value.
-- #size-cells: Set to 0 to indicate that the function child nodes do not
- have a size property.
-
-Optional Properties:
-- interrupts: interrupt which the rmi device is connected to.
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
-- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
- device.
-
-- syna,startup-delay-ms: The number of milliseconds to wait after powering on
- the device.
-
-- vdd-supply: VDD power supply.
-See ../regulator/regulator.txt
-
-- vio-supply: VIO power supply
-See ../regulator/regulator.txt
-
-Function Parameters:
-Parameters specific to RMI functions are contained in child nodes of the rmi device
- node. Documentation for the parameters of each function can be found in:
-Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
-
-
-
-Example:
- &i2c1 {
- rmi4-i2c-dev@2c {
- compatible = "syna,rmi4-i2c";
- reg = <0x2c>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <&gpio>;
- interrupts = <4 2>;
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
-
- rmi4-f11@11 {
- reg = <0x11>;
- touchscreen-inverted-y;
- syna,sensor-type = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
deleted file mode 100644
index 632f473db65b..000000000000
--- a/Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Synaptics RMI4 SPI Device Binding
-
-The Synaptics RMI4 core is able to support RMI4 devices using different
-transports and different functions. This file describes the device tree
-bindings for devices using the SPI transport driver. Complete documentation
-for other transports and functions can be found in
-Documentation/devicetree/bindings/input/rmi4.
-
-Required Properties:
-- compatible: syna,rmi4-spi
-- reg: Chip select address for the device
-- #address-cells: Set to 1 to indicate that the function child nodes
- consist of only on uint32 value.
-- #size-cells: Set to 0 to indicate that the function child nodes do not
- have a size property.
-
-Optional Properties:
-- interrupts: interrupt which the rmi device is connected to.
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
-- spi-rx-delay-us: microsecond delay after a read transfer.
-- spi-tx-delay-us: microsecond delay after a write transfer.
-
-Function Parameters:
-Parameters specific to RMI functions are contained in child nodes of the rmi device
- node. Documentation for the parameters of each function can be found in:
-Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
-
-
-
-Example:
- spi@7000d800 {
- rmi4-spi-dev@0 {
- compatible = "syna,rmi4-spi";
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
- spi-max-frequency = <4000000>;
- spi-cpha;
- spi-cpol;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(K, 2) 0x2>;
- spi-rx-delay-us = <30>;
-
- rmi4-f01@1 {
- reg = <0x1>;
- syna,nosleep-mode = <1>;
- };
-
- rmi4-f11@11 {
- reg = <0x11>;
- touchscreen-inverted-y;
- syna,sensor-type = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
deleted file mode 100644
index a644408b33b8..000000000000
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Rotary encoder DT bindings
-
-Required properties:
-- gpios: a spec for at least two GPIOs to be used, most significant first
-
-Optional properties:
-- linux,axis: the input subsystem axis to map to this rotary encoder.
- Defaults to 0 (ABS_X / REL_X)
-- rotary-encoder,steps: Number of steps in a full turnaround of the
- encoder. Only relevant for absolute axis. Defaults to 24 which is a
- typical value for such devices.
-- rotary-encoder,relative-axis: register a relative axis rather than an
- absolute one. Relative axis will only generate +1/-1 events on the input
- device, hence no steps need to be passed.
-- rotary-encoder,rollover: Automatic rollover when the rotary value becomes
- greater than the specified steps or smaller than 0. For absolute axis only.
-- rotary-encoder,steps-per-period: Number of steps (stable states) per period.
- The values have the following meaning:
- 1: Full-period mode (default)
- 2: Half-period mode
- 4: Quarter-period mode
-- wakeup-source: Boolean, rotary encoder can wake up the system.
-- rotary-encoder,encoding: String, the method used to encode steps.
- Supported are "gray" (the default and more common) and "binary".
-
-Deprecated properties:
-- rotary-encoder,half-period: Makes the driver work on half-period mode.
- This property is deprecated. Instead, a 'steps-per-period ' value should
- be used, such as "rotary-encoder,steps-per-period = <2>".
-
-See Documentation/input/devices/rotary-encoder.rst for more information.
-
-Example:
-
- rotary@0 {
- compatible = "rotary-encoder";
- gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */
- linux,axis = <0>; /* REL_X */
- rotary-encoder,encoding = "gray";
- rotary-encoder,relative-axis;
- };
-
- rotary@1 {
- compatible = "rotary-encoder";
- gpios = <&gpio 21 0>, <&gpio 22 0>;
- linux,axis = <1>; /* ABS_Y */
- rotary-encoder,steps = <24>;
- rotary-encoder,encoding = "binary";
- rotary-encoder,rollover;
- };
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.yaml b/Documentation/devicetree/bindings/input/rotary-encoder.yaml
new file mode 100644
index 000000000000..f9332bb2343f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/rotary-encoder.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rotary encoder
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ See Documentation/input/devices/rotary-encoder.rst for more information.
+
+properties:
+ compatible:
+ const: rotary-encoder
+
+ gpios:
+ minItems: 2
+
+ linux,axis:
+ default: 0
+ description:
+ the input subsystem axis to map to this rotary encoder.
+ Defaults to 0 (ABS_X / REL_X)
+
+ rotary-encoder,steps:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 24
+ description:
+ Number of steps in a full turnaround of the
+ encoder. Only relevant for absolute axis. Defaults to 24 which is a
+ typical value for such devices.
+
+ rotary-encoder,relative-axis:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ register a relative axis rather than an
+ absolute one. Relative axis will only generate +1/-1 events on the input
+ device, hence no steps need to be passed.
+
+ rotary-encoder,rollover:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Automatic rollover when the rotary value becomes
+ greater than the specified steps or smaller than 0. For absolute axis only.
+
+ rotary-encoder,steps-per-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ enum: [1, 2, 4]
+ description: |
+ Number of steps (stable states) per period.
+ The values have the following meaning:
+ 1: Full-period mode (default)
+ 2: Half-period mode
+ 4: Quarter-period mode
+
+ wakeup-source: true
+
+ rotary-encoder,encoding:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: the method used to encode steps.
+ enum: [gray, binary]
+
+ rotary-encoder,half-period:
+ $ref: /schemas/types.yaml#/definitions/flag
+ deprecated: true
+ description:
+ Makes the driver work on half-period mode.
+ This property is deprecated. Instead, a 'steps-per-period ' value should
+ be used, such as "rotary-encoder,steps-per-period = <2>".
+
+required:
+ - compatible
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ rotary {
+ compatible = "rotary-encoder";
+ gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */
+ linux,axis = <0>; /* REL_X */
+ rotary-encoder,encoding = "gray";
+ rotary-encoder,relative-axis;
+ };
+
diff --git a/Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml b/Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
new file mode 100644
index 000000000000..a53569aa0ee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/samsung,s3c6410-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series Keypad Controller
+
+description:
+ Samsung SoC Keypad controller is used to interface a SoC with a matrix-type
+ keypad device. The keypad controller supports multiple row and column lines.
+ A key can be placed at each intersection of a unique row and a unique column.
+ The keypad controller can sense a key-press and key-release and report the
+ event using a interrupt to the cpu.
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - samsung,s3c6410-keypad
+ - samsung,s5pv210-keypad
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: keypad
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ linux,input-no-autorepeat:
+ type: boolean
+ description:
+ Do no enable autorepeat feature.
+
+ linux,input-wakeup:
+ type: boolean
+ deprecated: true
+
+ samsung,keypad-num-columns:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of column lines connected to the keypad controller.
+
+ samsung,keypad-num-rows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of row lines connected to the keypad controller.
+
+patternProperties:
+ '^key-[0-9a-z]+$':
+ type: object
+ $ref: input.yaml#
+ additionalProperties: false
+ description:
+ Each key connected to the keypad controller is represented as a child
+ node to the keypad controller device node.
+
+ properties:
+ keypad,column:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The column number to which the key is connected.
+
+ keypad,row:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The row number to which the key is connected.
+
+ linux,code: true
+
+ required:
+ - keypad,column
+ - keypad,row
+ - linux,code
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - samsung,keypad-num-columns
+ - samsung,keypad-num-rows
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ keypad@100a0000 {
+ compatible = "samsung,s5pv210-keypad";
+ reg = <0x100a0000 0x100>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_KEYIF>;
+ clock-names = "keypad";
+
+ samsung,keypad-num-rows = <2>;
+ samsung,keypad-num-columns = <8>;
+ linux,input-no-autorepeat;
+ wakeup-source;
+
+ key-1 {
+ keypad,row = <0>;
+ keypad,column = <3>;
+ linux,code = <2>;
+ };
+
+ key-2 {
+ keypad,row = <0>;
+ keypad,column = <4>;
+ linux,code = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt
deleted file mode 100644
index 4c5c0a82586d..000000000000
--- a/Documentation/devicetree/bindings/input/samsung-keypad.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-* Samsung's Keypad Controller device tree bindings
-
-Samsung's Keypad controller is used to interface a SoC with a matrix-type
-keypad device. The keypad controller supports multiple row and column lines.
-A key can be placed at each intersection of a unique row and a unique column.
-The keypad controller can sense a key-press and key-release and report the
-event using a interrupt to the cpu.
-
-Required SoC Specific Properties:
-- compatible: should be one of the following
- - "samsung,s3c6410-keypad": For controllers compatible with s3c6410 keypad
- controller.
- - "samsung,s5pv210-keypad": For controllers compatible with s5pv210 keypad
- controller.
-
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-- interrupts: The interrupt number to the cpu.
-
-Required Board Specific Properties:
-- samsung,keypad-num-rows: Number of row lines connected to the keypad
- controller.
-
-- samsung,keypad-num-columns: Number of column lines connected to the
- keypad controller.
-
-- Keys represented as child nodes: Each key connected to the keypad
- controller is represented as a child node to the keypad controller
- device node and should include the following properties.
- - keypad,row: the row number to which the key is connected.
- - keypad,column: the column number to which the key is connected.
- - linux,code: the key-code to be reported when the key is pressed
- and released.
-
-- pinctrl-0: Should specify pin control groups used for this controller.
-- pinctrl-names: Should contain only one value - "default".
-
-Optional Properties:
-- wakeup-source: use any event on keypad as wakeup event.
- (Legacy property supported: "linux,input-wakeup")
-
-Optional Properties specific to linux:
-- linux,keypad-no-autorepeat: do no enable autorepeat feature.
-
-
-Example:
- keypad@100a0000 {
- compatible = "samsung,s5pv210-keypad";
- reg = <0x100A0000 0x100>;
- interrupts = <173>;
- samsung,keypad-num-rows = <2>;
- samsung,keypad-num-columns = <8>;
- linux,input-no-autorepeat;
- wakeup-source;
-
- pinctrl-names = "default";
- pinctrl-0 = <&keypad_rows &keypad_columns>;
-
- key_1 {
- keypad,row = <0>;
- keypad,column = <3>;
- linux,code = <2>;
- };
-
- key_2 {
- keypad,row = <0>;
- keypad,column = <4>;
- linux,code = <3>;
- };
-
- key_3 {
- keypad,row = <0>;
- keypad,column = <5>;
- linux,code = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/snvs-pwrkey.txt b/Documentation/devicetree/bindings/input/snvs-pwrkey.txt
deleted file mode 100644
index 70c14250323b..000000000000
--- a/Documentation/devicetree/bindings/input/snvs-pwrkey.txt
+++ /dev/null
@@ -1 +0,0 @@
-See Documentation/devicetree/bindings/crypto/fsl-sec4.txt
diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml
index 5d67fc8ebc18..4c8d303ff93c 100644
--- a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml
+++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/input/sprd,sc27xx-vibrator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Spreadtrum SC27xx PMIC Vibrator Device Tree Bindings
+title: Spreadtrum SC27xx PMIC Vibrator
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
@@ -28,21 +28,4 @@ required:
additionalProperties: false
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- sc2731_pmic: pmic@0 {
- compatible = "sprd,sc2731";
- reg = <0 0>;
- spi-max-frequency = <26000000>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- vibrator@eb4 {
- compatible = "sprd,sc2731-vibrator";
- reg = <0xeb4>;
- };
- };
+...
diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
deleted file mode 100644
index 12bb771d66d4..000000000000
--- a/Documentation/devicetree/bindings/input/stmpe-keypad.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* STMPE Keypad
-
-Required properties:
- - compatible : "st,stmpe-keypad"
- - linux,keymap : See ./matrix-keymap.txt
-
-Optional properties:
- - debounce-interval : Debouncing interval time in milliseconds
- - st,scan-count : Scanning cycles elapsed before key data is updated
- - st,no-autorepeat : If specified device will not autorepeat
- - keypad,num-rows : See ./matrix-keymap.txt
- - keypad,num-columns : See ./matrix-keymap.txt
-
-Example:
-
- stmpe_keypad {
- compatible = "st,stmpe-keypad";
-
- debounce-interval = <64>;
- st,scan-count = <8>;
- st,no-autorepeat;
-
- linux,keymap = <0x205006b
- 0x4010074
- 0x3050072
- 0x1030004
- 0x502006a
- 0x500000a
- 0x5008b
- 0x706001c
- 0x405000b
- 0x6070003
- 0x3040067
- 0x303006c
- 0x60400e7
- 0x602009e
- 0x4020073
- 0x5050002
- 0x4030069
- 0x3020008>;
- };
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
new file mode 100644
index 000000000000..f369385ffaf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -0,0 +1,293 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/syna,rmi4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics RMI4 compliant devices
+
+maintainers:
+ - Jason A. Donenfeld <Jason@zx2c4.com>
+ - Matthias Schiffer <matthias.schiffer@ew.tq-group.com
+ - Vincent Huang <vincent.huang@tw.synaptics.com>
+
+description: |
+ The Synaptics RMI4 (Register Mapped Interface 4) core is able to support RMI4
+ devices using different transports (I2C, SPI) and different functions (e.g.
+ Function 1, 2D sensors using Function 11 or 12).
+
+properties:
+ compatible:
+ enum:
+ - syna,rmi4-i2c
+ - syna,rmi4-spi
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description: Active low signal
+
+ spi-cpha: true
+ spi-cpol: true
+
+ syna,reset-delay-ms:
+ description:
+ Delay to wait after resetting the device.
+
+ syna,startup-delay-ms:
+ description:
+ Delay to wait after powering on the device.
+
+ vdd-supply: true
+ vio-supply: true
+
+ rmi4-f01@1:
+ type: object
+ additionalProperties: false
+ description:
+ Function 1
+
+ properties:
+ reg:
+ maxItems: 1
+
+ syna,nosleep-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ description:
+ If set the device will run at full power without sleeping. nosleep
+ has 3 modes, 0 will not change the default setting, 1 will disable
+ nosleep (allow sleeping), and 2 will enable nosleep (disabling
+ sleep).
+
+ syna,wakeup-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the amplitude of the disturbance to the background
+ capacitance that will cause the device to wake from dozing.
+
+ syna,doze-holdoff-ms:
+ description:
+ The delay to wait after the last finger lift and the first doze
+ cycle.
+
+ syna,doze-interval-ms:
+ description:
+ The time period that the device sleeps between finger activity.
+
+ required:
+ - reg
+
+ rmi4-f1a@1a:
+ type: object
+ additionalProperties: false
+ $ref: input.yaml#
+ description:
+ RMI4 Function 1A is for capacitive keys.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ linux,keycodes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - reg
+
+patternProperties:
+ "^rmi4-f1[12]@1[12]$":
+ type: object
+ unevaluatedProperties: false
+ $ref: /schemas/input/touchscreen/touchscreen.yaml#
+ description:
+ RMI4 Function 11 and Function 12 are for 2D touch position sensing.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ syna,clip-x-low:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum value for X.
+
+ syna,clip-y-low:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum value for Y.
+
+ syna,clip-x-high:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum value for X.
+
+ syna,clip-y-high:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum value for Y.
+
+ syna,offset-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Add an offset to X.
+
+ syna,offset-y:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Add an offset to Y.
+
+ syna,delta-x-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum distance on the X axis required to generate an interrupt in
+ reduced reporting mode.
+
+ syna,delta-y-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Minimum distance on the Y axis required to generate an interrupt in
+ reduced reporting mode.
+
+ syna,sensor-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: |
+ Sensor type: 1 for touchscreen 2 for touchpad.
+
+ syna,disable-report-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Mask for disabling posiiton reporting. Used to disable reporing
+ absolute position data.
+
+ syna,rezero-wait-ms:
+ description:
+ Time to wait after issuing a rezero command.
+
+ required:
+ - reg
+
+ "^rmi4-f[0-9a-f]+@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ description:
+ Other functions, not documented yet.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: syna,rmi4-i2c
+ then:
+ properties:
+ spi-rx-delay-us: false
+ spi-tx-delay-us: false
+ else:
+ properties:
+ syna,reset-delay-ms: false
+ syna,startup-delay-ms: false
+
+examples:
+ - |
+ #include <dt-bindings/input/linux-event-codes.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@20 {
+ compatible = "syna,rmi4-i2c";
+ reg = <0x20>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+
+ syna,startup-delay-ms = <100>;
+ vdd-supply = <&tsp_vdd>;
+ vio-supply = <&ldo32_reg>;
+
+ pinctrl-0 = <&touch_irq>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f12@12 {
+ reg = <0x12>;
+ syna,sensor-type = <1>;
+ };
+
+ rmi4-f1a@1a {
+ reg = <0x1a>;
+ linux,keycodes = <KEY_BACK KEY_HOME KEY_MENU>;
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@0 {
+ compatible = "syna,rmi4-spi";
+ reg = <0x0>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+
+ spi-max-frequency = <4000000>;
+ spi-rx-delay-us = <30>;
+ spi-cpha;
+ spi-cpol;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f11@11 {
+ reg = <0x11>;
+ touchscreen-inverted-y;
+ syna,sensor-type = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
deleted file mode 100644
index 255185009167..000000000000
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-This binding is based on the matrix-keymap binding with the following
-changes:
-
-keypad,num-rows and keypad,num-columns are required.
-
-Required properties:
-- compatible: "ti,tca8418"
-- reg: the I2C address
-- interrupts: IRQ line number, should trigger on falling edge
-- linux,keymap: Keys definitions, see keypad-matrix.
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt
deleted file mode 100644
index 4c5312eaaa85..000000000000
--- a/Documentation/devicetree/bindings/input/ti,drv260x.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Texas Instruments - drv260x Haptics driver family
-
-Required properties:
- - compatible - One of:
- "ti,drv2604" - DRV2604
- "ti,drv2605" - DRV2605
- "ti,drv2605l" - DRV2605L
- - reg - I2C slave address
- - vbat-supply - Required supply regulator
- - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h)
- DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric)
- DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no calibration
- sequence during init. And the device is configured for real
- time playback mode (RTP mode).
- DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator)
- - library-sel - These are ROM based waveforms pre-programmed into the IC.
- This should be set to set the library to use at power up.
- (defined in include/dt-bindings/input/ti-drv260x.h)
- DRV260X_LIB_EMPTY - Do not use a pre-programmed library
- DRV260X_ERM_LIB_A - Pre-programmed Library
- DRV260X_ERM_LIB_B - Pre-programmed Library
- DRV260X_ERM_LIB_C - Pre-programmed Library
- DRV260X_ERM_LIB_D - Pre-programmed Library
- DRV260X_ERM_LIB_E - Pre-programmed Library
- DRV260X_ERM_LIB_F - Pre-programmed Library
- DRV260X_LIB_LRA - Pre-programmed LRA Library
-
-Optional properties:
- - enable-gpio - gpio pin to enable/disable the device.
- - vib-rated-mv - The rated voltage of the actuator in millivolts.
- If this is not set then the value will be defaulted to
- 3.2 v.
- - vib-overdrive-mv - The overdrive voltage of the actuator in millivolts.
- If this is not set then the value will be defaulted to
- 3.2 v.
-Example:
-
-haptics: haptics@5a {
- compatible = "ti,drv2605l";
- reg = <0x5a>;
- vbat-supply = <&vbat>;
- enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
- mode = <DRV260X_LRA_MODE>;
- library-sel = <DRV260X_LIB_LRA>;
- vib-rated-mv = <3200>;
- vib-overdrive-mv = <3200>;
-}
-
-For more product information please see the link below:
-http://www.ti.com/product/drv2605
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.yaml b/Documentation/devicetree/bindings/input/ti,drv260x.yaml
new file mode 100644
index 000000000000..c6245c5b9e2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,drv260x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - drv260x Haptics driver family
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,drv2604
+ - ti,drv2605
+ - ti,drv2605l
+
+ reg:
+ maxItems: 1
+
+ vbat-supply:
+ description: Power supply to the haptic motor
+
+ # TODO: Deprecate 'mode' in favor of differently named property
+ mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Power up mode of the chip
+ (defined in include/dt-bindings/input/ti-drv260x.h)
+
+ DRV260X_LRA_MODE
+ Linear Resonance Actuator mode (Piezoelectric)
+
+ DRV260X_LRA_NO_CAL_MODE
+ This is a LRA Mode but there is no calibration sequence during init.
+ And the device is configured for real time playback mode (RTP mode).
+
+ DRV260X_ERM_MODE
+ Eccentric Rotating Mass mode (Rotary vibrator)
+ enum: [ 0, 1, 2 ]
+
+ library-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ These are ROM based waveforms pre-programmed into the IC.
+ This should be set to set the library to use at power up.
+ (defined in include/dt-bindings/input/ti-drv260x.h)
+
+ DRV260X_LIB_EMPTY - Do not use a pre-programmed library
+ DRV260X_ERM_LIB_A - Pre-programmed Library
+ DRV260X_ERM_LIB_B - Pre-programmed Library
+ DRV260X_ERM_LIB_C - Pre-programmed Library
+ DRV260X_ERM_LIB_D - Pre-programmed Library
+ DRV260X_ERM_LIB_E - Pre-programmed Library
+ DRV260X_ERM_LIB_F - Pre-programmed Library
+ DRV260X_LIB_LRA - Pre-programmed LRA Library
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ enable-gpio:
+ maxItems: 1
+ deprecated: true
+
+ enable-gpios:
+ maxItems: 1
+
+ vib-rated-mv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ The rated voltage of the actuator in millivolts.
+ If this is not set then the value will be defaulted to 3200 mV.
+ default: 3200
+
+ vib-overdrive-mv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ The overdrive voltage of the actuator in millivolts.
+ If this is not set then the value will be defaulted to 3200 mV.
+ default: 3200
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - mode
+ - library-sel
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/ti-drv260x.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ haptics@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ vbat-supply = <&vbat>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ mode = <DRV260X_LRA_MODE>;
+ library-sel = <DRV260X_LIB_LRA>;
+ vib-rated-mv = <3200>;
+ vib-overdrive-mv = <3200>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/ti,drv2665.txt b/Documentation/devicetree/bindings/input/ti,drv2665.txt
deleted file mode 100644
index 1ba97ac04305..000000000000
--- a/Documentation/devicetree/bindings/input/ti,drv2665.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Texas Instruments - drv2665 Haptics driver
-
-Required properties:
- - compatible - "ti,drv2665" - DRV2665
- - reg - I2C slave address
- - vbat-supply - Required supply regulator
-
-Example:
-
-haptics: haptics@59 {
- compatible = "ti,drv2665";
- reg = <0x59>;
- vbat-supply = <&vbat>;
-};
-
-For more product information please see the link below:
-http://www.ti.com/product/drv2665
diff --git a/Documentation/devicetree/bindings/input/ti,drv2667.txt b/Documentation/devicetree/bindings/input/ti,drv2667.txt
deleted file mode 100644
index 996382cf994a..000000000000
--- a/Documentation/devicetree/bindings/input/ti,drv2667.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Texas Instruments - drv2667 Haptics driver
-
-Required properties:
- - compatible - "ti,drv2667" - DRV2667
- - reg - I2C slave address
- - vbat-supply - Required supply regulator
-
-Example:
-
-haptics: haptics@59 {
- compatible = "ti,drv2667";
- reg = <0x59>;
- vbat-supply = <&vbat>;
-};
-
-For more product information please see the link below:
-http://www.ti.com/product/drv2667
diff --git a/Documentation/devicetree/bindings/input/ti,drv266x.yaml b/Documentation/devicetree/bindings/input/ti,drv266x.yaml
new file mode 100644
index 000000000000..1bce389d0e5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv266x.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,drv266x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - drv266x Haptics driver
+
+description: |
+ Product Page:
+ http://www.ti.com/product/drv2665
+ http://www.ti.com/product/drv2667
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,drv2665
+ - ti,drv2667
+
+ reg:
+ maxItems: 1
+
+ vbat-supply:
+ description: Required supply regulator
+
+required:
+ - compatible
+ - reg
+ - vbat-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ haptics@59 {
+ compatible = "ti,drv2667";
+ reg = <0x59>;
+ vbat-supply = <&vbat>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt
deleted file mode 100644
index 513d94d6e899..000000000000
--- a/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-TI-NSPIRE Keypad
-
-Required properties:
-- compatible: Compatible property value should be "ti,nspire-keypad".
-
-- reg: Physical base address of the peripheral and length of memory mapped
- region.
-
-- interrupts: The interrupt number for the peripheral.
-
-- scan-interval: How often to scan in us. Based on a APB speed of 33MHz, the
- maximum and minimum delay time is ~2000us and ~500us respectively
-
-- row-delay: How long to wait before scanning each row.
-
-- clocks: The clock this peripheral is attached to.
-
-- linux,keymap: The keymap to use
- (see Documentation/devicetree/bindings/input/matrix-keymap.txt)
-
-Optional properties:
-- active-low: Specify that the keypad is active low (i.e. logical low signifies
- a key press).
-
-Example:
-
-input {
- compatible = "ti,nspire-keypad";
- reg = <0x900E0000 0x1000>;
- interrupts = <16>;
-
- scan-interval = <1000>;
- row-delay = <200>;
-
- clocks = <&apb_pclk>;
-
- linux,keymap = <
- 0x0000001c 0x0001001c 0x00040039
- 0x0005002c 0x00060015 0x0007000b
- 0x0008000f 0x0100002d 0x01010011
- 0x0102002f 0x01030004 0x01040016
- 0x01050014 0x0106001f 0x01070002
- 0x010a006a 0x02000013 0x02010010
- 0x02020019 0x02030007 0x02040018
- 0x02050031 0x02060032 0x02070005
- 0x02080028 0x0209006c 0x03000026
- 0x03010025 0x03020024 0x0303000a
- 0x03040017 0x03050023 0x03060022
- 0x03070008 0x03080035 0x03090069
- 0x04000021 0x04010012 0x04020020
- 0x0404002e 0x04050030 0x0406001e
- 0x0407000d 0x04080037 0x04090067
- 0x05010038 0x0502000c 0x0503001b
- 0x05040034 0x0505001a 0x05060006
- 0x05080027 0x0509000e 0x050a006f
- 0x0600002b 0x0602004e 0x06030068
- 0x06040003 0x0605006d 0x06060009
- 0x06070001 0x0609000f 0x0708002a
- 0x0709001d 0x070a0033 >;
-};
diff --git a/Documentation/devicetree/bindings/input/ti,nspire-keypad.yaml b/Documentation/devicetree/bindings/input/ti,nspire-keypad.yaml
new file mode 100644
index 000000000000..ed3cfff13add
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,nspire-keypad.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,nspire-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-NSPIRE Keypad
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+
+allOf:
+ - $ref: input.yaml#
+ - $ref: matrix-keymap.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,nspire-keypad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ scan-interval:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: How often to scan in us. Based on a APB speed of 33MHz, the
+ maximum and minimum delay time is ~2000us and ~500us respectively
+
+ row-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: How long to wait between scanning each row in us.
+
+ active-low:
+ description: Specify that the keypad is active low.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - scan-interval
+ - row-delay
+ - linux,keymap
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ keypad@900e0000 {
+ compatible = "ti,nspire-keypad";
+ reg = <0x900e0000 0x1000>;
+ interrupts = <16>;
+
+ clocks = <&apb_pclk>;
+
+ scan-interval = <1000>;
+ row-delay = <200>;
+
+ linux,keymap = <
+ MATRIX_KEY(0, 0, KEY_ENTER)
+ MATRIX_KEY(0, 1, KEY_ENTER)
+ MATRIX_KEY(0, 4, KEY_SPACE)
+ MATRIX_KEY(0, 5, KEY_Z)
+ MATRIX_KEY(0, 6, KEY_Y)
+ MATRIX_KEY(0, 7, KEY_0)
+ >;
+ };
diff --git a/Documentation/devicetree/bindings/input/ti,tca8418.yaml b/Documentation/devicetree/bindings/input/ti,tca8418.yaml
new file mode 100644
index 000000000000..624a1830d0b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,tca8418.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,tca8418.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TCA8418 I2C/SMBus keypad scanner
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,tca8418
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: matrix-keymap.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ keypad@34 {
+ compatible = "ti,tca8418";
+ reg = <0x34>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ keypad,num-rows = <4>;
+ keypad,num-columns = <4>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x01, BTN_0)
+ MATRIX_KEY(0x00, 0x00, BTN_1)
+ MATRIX_KEY(0x01, 0x01, BTN_2)
+ MATRIX_KEY(0x01, 0x00, BTN_3)
+ MATRIX_KEY(0x02, 0x00, BTN_4)
+ MATRIX_KEY(0x00, 0x03, BTN_5)
+ MATRIX_KEY(0x00, 0x02, BTN_6)
+ MATRIX_KEY(0x01, 0x03, BTN_7)
+ MATRIX_KEY(0x01, 0x02, BTN_8)
+ MATRIX_KEY(0x02, 0x02, BTN_9)
+ >;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt b/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
deleted file mode 100644
index afa38dc069f0..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Analog Devices AD7879(-1)/AD7889(-1) touchscreen interface (SPI/I2C)
-
-Required properties:
-- compatible : for SPI slave, use "adi,ad7879"
- for I2C slave, use "adi,ad7879-1"
-- reg : SPI chipselect/I2C slave address
- See spi-bus.txt for more SPI slave properties
-- interrupts : touch controller interrupt
-- touchscreen-max-pressure : maximum reported pressure
-- adi,resistance-plate-x : total resistance of X-plate (for pressure
- calculation)
-Optional properties:
-- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
-- adi,first-conversion-delay : 0-12: In 128us steps (starting with 128us)
- 13 : 2.560ms
- 14 : 3.584ms
- 15 : 4.096ms
- This property has to be a '/bits/ 8' value
-- adi,acquisition-time : 0: 2us
- 1: 4us
- 2: 8us
- 3: 16us
- This property has to be a '/bits/ 8' value
-- adi,median-filter-size : 0: disabled
- 1: 4 measurements
- 2: 8 measurements
- 3: 16 measurements
- This property has to be a '/bits/ 8' value
-- adi,averaging : 0: 2 middle values (1 if median disabled)
- 1: 4 middle values
- 2: 8 middle values
- 3: 16 values
- This property has to be a '/bits/ 8' value
-- adi,conversion-interval: : 0 : convert one time only
- 1-255: 515us + val * 35us (up to 9.440ms)
- This property has to be a '/bits/ 8' value
-- gpio-controller : Switch AUX/VBAT/GPIO pin to GPIO mode
-
-Example:
-
- touchscreen0@2c {
- compatible = "adi,ad7879-1";
- reg = <0x2c>;
- interrupt-parent = <&gpio1>;
- interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
- touchscreen-max-pressure = <4096>;
- adi,resistance-plate-x = <120>;
- adi,first-conversion-delay = /bits/ 8 <3>;
- adi,acquisition-time = /bits/ 8 <1>;
- adi,median-filter-size = /bits/ 8 <2>;
- adi,averaging = /bits/ 8 <1>;
- adi,conversion-interval = /bits/ 8 <255>;
- };
-
- touchscreen1@1 {
- compatible = "adi,ad7879";
- spi-max-frequency = <5000000>;
- reg = <1>;
- spi-cpol;
- spi-cpha;
- gpio-controller;
- interrupt-parent = <&gpio1>;
- interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
- touchscreen-max-pressure = <4096>;
- adi,resistance-plate-x = <120>;
- adi,first-conversion-delay = /bits/ 8 <3>;
- adi,acquisition-time = /bits/ 8 <1>;
- adi,median-filter-size = /bits/ 8 <2>;
- adi,averaging = /bits/ 8 <1>;
- adi,conversion-interval = /bits/ 8 <255>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml b/Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml
new file mode 100644
index 000000000000..caa5fa3cc3f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/adi,ad7879.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/adi,ad7879.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7879(-1)/AD7889(-1) touchscreen interface (SPI/I2C)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ description: |
+ for SPI slave, use "adi,ad7879"
+ for I2C slave, use "adi,ad7879-1"
+ enum:
+ - adi,ad7879
+ - adi,ad7879-1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ touchscreen-max-pressure:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: maximum reported pressure
+
+ adi,resistance-plate-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: total resistance of X-plate (for pressure calculation)
+
+ touchscreen-swapped-x-y:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: X and Y axis are swapped (boolean)
+
+ adi,first-conversion-delay:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ default: 0
+ minimum: 0
+ maximum: 15
+ description: |
+ 0-12: In 128us steps (starting with 128us)
+ 13 : 2.560ms
+ 14 : 3.584ms
+ 15 : 4.096ms
+ This property has to be a '/bits/ 8' value
+
+ adi,acquisition-time:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ default: 0
+ enum: [0, 1, 2, 3]
+ description: |
+ 0: 2us
+ 1: 4us
+ 2: 8us
+ 3: 16us
+ This property has to be a '/bits/ 8' value
+
+ adi,median-filter-size:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ default: 0
+ enum: [0, 1, 2, 3]
+ description: |
+ 0: disabled
+ 1: 4 measurements
+ 2: 8 measurements
+ 3: 16 measurements
+ This property has to be a '/bits/ 8' value
+
+ adi,averaging:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ default: 0
+ enum: [0, 1, 2, 3]
+ description: |
+ 0: 2 middle values (1 if median disabled)
+ 1: 4 middle values
+ 2: 8 middle values
+ 3: 16 values
+ This property has to be a '/bits/ 8' value
+
+ adi,conversion-interval:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ default: 0
+ description: |
+ 0 : convert one time only
+ 1-255: 515us + val * 35us (up to 9.440ms)
+ This property has to be a '/bits/ 8' value
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen0@2c {
+ compatible = "adi,ad7879-1";
+ reg = <0x2c>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-max-pressure = <4096>;
+ adi,resistance-plate-x = <120>;
+ adi,first-conversion-delay = /bits/ 8 <3>;
+ adi,acquisition-time = /bits/ 8 <1>;
+ adi,median-filter-size = /bits/ 8 <2>;
+ adi,averaging = /bits/ 8 <1>;
+ adi,conversion-interval = /bits/ 8 <255>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen1@1 {
+ compatible = "adi,ad7879";
+ reg = <1>;
+ spi-max-frequency = <5000000>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-max-pressure = <4096>;
+ adi,resistance-plate-x = <120>;
+ adi,first-conversion-delay = /bits/ 8 <3>;
+ adi,acquisition-time = /bits/ 8 <1>;
+ adi,median-filter-size = /bits/ 8 <2>;
+ adi,averaging = /bits/ 8 <1>;
+ adi,conversion-interval = /bits/ 8 <255>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
deleted file mode 100644
index 81f6bda97d3c..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
+++ /dev/null
@@ -1,106 +0,0 @@
-Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046
-SPI driven touch screen controllers.
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in
-
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-must be specified.
-
-Additional required properties:
-
- compatible Must be one of the following, depending on the
- model:
- "ti,tsc2046"
- "ti,ads7843"
- "ti,ads7845"
- "ti,ads7846"
- "ti,ads7873"
-
- interrupts An interrupt node describing the IRQ line the chip's
- !PENIRQ pin is connected to.
- vcc-supply A regulator node for the supply voltage.
-
-
-Optional properties:
-
- ti,vref-delay-usecs vref supply delay in usecs, 0 for
- external vref (u16).
- ti,vref-mv The VREF voltage, in millivolts (u16).
- Set to 0 to use internal references
- (ADS7846).
- ti,keep-vref-on set to keep vref on for differential
- measurements as well
- ti,settle-delay-usec Settling time of the analog signals;
- a function of Vcc and the capacitance
- on the X/Y drivers. If set to non-zero,
- two samples are taken with settle_delay
- us apart, and the second one is used.
- ~150 uSec with 0.01uF caps (u16).
- ti,penirq-recheck-delay-usecs If set to non-zero, after samples are
- taken this delay is applied and penirq
- is rechecked, to help avoid false
- events. This value is affected by the
- material used to build the touch layer
- (u16).
- ti,x-plate-ohms Resistance of the X-plate,
- in Ohms (u16).
- ti,y-plate-ohms Resistance of the Y-plate,
- in Ohms (u16).
- ti,x-min Minimum value on the X axis (u16).
- ti,y-min Minimum value on the Y axis (u16).
- ti,debounce-tol Tolerance used for filtering (u16).
- ti,debounce-rep Additional consecutive good readings
- required after the first two (u16).
- ti,pendown-gpio-debounce Platform specific debounce time for the
- pendown-gpio (u32).
- pendown-gpio GPIO handle describing the pin the !PENIRQ
- line is connected to.
- wakeup-source use any event on touchscreen as wakeup event.
- (Legacy property support: "linux,wakeup")
- touchscreen-size-x General touchscreen binding, see [1].
- touchscreen-size-y General touchscreen binding, see [1].
- touchscreen-max-pressure General touchscreen binding, see [1].
- touchscreen-min-pressure General touchscreen binding, see [1].
- touchscreen-average-samples General touchscreen binding, see [1].
- touchscreen-inverted-x General touchscreen binding, see [1].
- touchscreen-inverted-y General touchscreen binding, see [1].
- touchscreen-swapped-x-y General touchscreen binding, see [1].
-
-[1] All general touchscreen properties are described in
- Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt.
-
-Deprecated properties:
-
- ti,swap-xy swap x and y axis
- ti,x-max Maximum value on the X axis (u16).
- ti,y-max Maximum value on the Y axis (u16).
- ti,pressure-min Minimum reported pressure value
- (threshold) - u16.
- ti,pressure-max Maximum reported pressure value (u16).
- ti,debounce-max Max number of additional readings per
- sample (u16).
-
-Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
-
- spi_controller {
- tsc2046@0 {
- reg = <0>; /* CS0 */
- compatible = "ti,tsc2046";
- interrupt-parent = <&gpio1>;
- interrupts = <8 0>; /* BOOT6 / GPIO 8 */
- spi-max-frequency = <1000000>;
- pendown-gpio = <&gpio1 8 0>;
- vcc-supply = <&reg_vcc3>;
-
- ti,x-min = /bits/ 16 <0>;
- ti,x-max = /bits/ 16 <8000>;
- ti,y-min = /bits/ 16 <0>;
- ti,y-max = /bits/ 16 <4800>;
- ti,x-plate-ohms = /bits/ 16 <40>;
- ti,pressure-max = /bits/ 16 <255>;
-
- wakeup-source;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
new file mode 100644
index 000000000000..402ca6bffd34
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/apple,z2-multitouch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple touchscreens attached using the Z2 protocol
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+description: A series of touschscreen controllers used in Apple products
+
+allOf:
+ - $ref: touchscreen.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - apple,j293-touchbar
+ - apple,j493-touchbar
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ firmware-name:
+ maxItems: 1
+
+ apple,z2-cal-blob:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ maxItems: 4096
+ description:
+ Calibration blob supplied by the bootloader
+
+required:
+ - compatible
+ - interrupts
+ - reset-gpios
+ - firmware-name
+ - touchscreen-size-x
+ - touchscreen-size-y
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@0 {
+ compatible = "apple,j293-touchbar";
+ reg = <0>;
+ spi-max-frequency = <11500000>;
+ reset-gpios = <&pinctrl_ap 139 GPIO_ACTIVE_LOW>;
+ interrupts-extended = <&pinctrl_ap 194 IRQ_TYPE_EDGE_FALLING>;
+ firmware-name = "apple/dfrmtfw-j293.bin";
+ touchscreen-size-x = <23045>;
+ touchscreen-size-y = <640>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
index f40f21c642b9..b8db975e9f77 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
@@ -17,10 +17,10 @@ Example:
auo_pixcir_ts@5c {
compatible = "auo,auo_pixcir_ts";
reg = <0x5c>;
- interrupts = <2 0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
- gpios = <&gpf 2 0 2>, /* INT */
- <&gpf 5 1 0>; /* RST */
+ gpios = <&gpf 2 0 GPIO_LEVEL_HIGH>, /* INT */
+ <&gpf 5 1 GPIO_LEVEL_LOW>; /* RST */
x-size = <800>;
y-size = <600>;
diff --git a/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml
new file mode 100644
index 000000000000..e4dbbafb3779
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/azoteq,iqs7211.yaml
@@ -0,0 +1,769 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/azoteq,iqs7211.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Azoteq IQS7210A/7211A/E Trackpad/Touchscreen Controller
+
+maintainers:
+ - Jeff LaBundy <jeff@labundy.com>
+
+description: |
+ The Azoteq IQS7210A, IQS7211A and IQS7211E trackpad and touchscreen control-
+ lers employ projected-capacitance sensing and can track two contacts.
+
+ Link to datasheets: https://www.azoteq.com/
+
+properties:
+ compatible:
+ enum:
+ - azoteq,iqs7210a
+ - azoteq,iqs7211a
+ - azoteq,iqs7211e
+
+ reg:
+ maxItems: 1
+
+ irq-gpios:
+ maxItems: 1
+ description:
+ Specifies the GPIO connected to the device's active-low RDY output. The
+ pin doubles as the IQS7211E's active-low MCLR input, in which case this
+ GPIO must be configured as open-drain.
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ Specifies the GPIO connected to the device's active-low MCLR input. The
+ device is temporarily held in hardware reset prior to initialization if
+ this property is present.
+
+ azoteq,forced-comms:
+ type: boolean
+ description:
+ Enables forced communication; to be used with host adapters that cannot
+ tolerate clock stretching.
+
+ azoteq,forced-comms-default:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description:
+ Indicates if the device's OTP memory enables (1) or disables (0) forced
+ communication by default. Specifying this property can expedite startup
+ time if the default value is known.
+
+ If this property is not specified, communication is not initiated until
+ the device asserts its RDY pin shortly after exiting hardware reset. At
+ that point, forced communication is either enabled or disabled based on
+ the presence or absence of the 'azoteq,forced-comms' property.
+
+ azoteq,rate-active-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the report rate (in ms) during active mode.
+
+ azoteq,rate-touch-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the report rate (in ms) during idle-touch mode.
+
+ azoteq,rate-idle-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the report rate (in ms) during idle mode.
+
+ azoteq,rate-lp1-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the report rate (in ms) during low-power mode 1.
+
+ azoteq,rate-lp2-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the report rate (in ms) during low-power mode 2.
+
+ azoteq,timeout-active-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 65535000
+ description:
+ Specifies the length of time (in ms) to wait for an event before moving
+ from active mode to idle or idle-touch modes.
+
+ azoteq,timeout-touch-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 65535000
+ description:
+ Specifies the length of time (in ms) to wait for an event before moving
+ from idle-touch mode to idle mode.
+
+ azoteq,timeout-idle-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 65535000
+ description:
+ Specifies the length of time (in ms) to wait for an event before moving
+ from idle mode to low-power mode 1.
+
+ azoteq,timeout-lp1-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 65535000
+ description:
+ Specifies the length of time (in ms) to wait for an event before moving
+ from low-power mode 1 to low-power mode 2.
+
+ azoteq,timeout-lp2-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 60000
+ description:
+ Specifies the rate (in ms) at which the trackpad reference values
+ are updated during low-power modes 1 and 2.
+
+ azoteq,timeout-ati-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 60000
+ description:
+ Specifies the delay (in ms) before the automatic tuning implementation
+ (ATI) is retried in the event it fails to complete.
+
+ azoteq,timeout-comms-ms:
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the delay (in ms) before a communication window is closed.
+
+ azoteq,timeout-press-ms:
+ multipleOf: 1000
+ minimum: 0
+ maximum: 60000
+ description:
+ Specifies the length of time (in ms) to wait before automatically
+ releasing a press event. Specify zero to allow the press state to
+ persist indefinitely.
+
+ azoteq,fosc-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ Specifies the device's core clock frequency as follows:
+ 0: 14 MHz
+ 1: 18 MHz
+
+ azoteq,fosc-trim:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description: Specifies the device's core clock frequency trim.
+
+ azoteq,num-contacts:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 2
+ default: 0
+ description: Specifies the number of contacts reported by the device.
+
+ azoteq,contact-split:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the contact (finger) split factor.
+
+ azoteq,trim-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the horizontal trim width.
+
+ azoteq,trim-y:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the vertical trim height.
+
+ trackpad:
+ type: object
+ description: Represents all channels associated with the trackpad.
+
+ properties:
+ azoteq,rx-enable:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 7
+ description:
+ Specifies the order of the CRx pin(s) associated with the trackpad.
+
+ azoteq,tx-enable:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 12
+ items:
+ minimum: 0
+ maximum: 11
+ description:
+ Specifies the order of the CTx pin(s) associated with the trackpad.
+
+ azoteq,channel-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 36
+ items:
+ minimum: 0
+ maximum: 255
+ description: |
+ Specifies the channels mapped to each cycle in the following order:
+ Cycle 0, slot 0
+ Cycle 0, slot 1
+ Cycle 1, slot 0
+ Cycle 1, slot 1
+ ...and so on. Specify 255 to disable a given slot.
+
+ azoteq,ati-frac-div-fine:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the trackpad's ATI fine fractional divider.
+
+ azoteq,ati-frac-mult-coarse:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description: Specifies the trackpad's ATI coarse fractional multiplier.
+
+ azoteq,ati-frac-div-coarse:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the trackpad's ATI coarse fractional divider.
+
+ azoteq,ati-comp-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the trackpad's ATI compensation divider.
+
+ azoteq,ati-target:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description: Specifies the trackpad's ATI target.
+
+ azoteq,touch-enter:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's touch entrance factor.
+
+ azoteq,touch-exit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's touch exit factor.
+
+ azoteq,thresh:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's stationary touch threshold.
+
+ azoteq,conv-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's conversion period.
+
+ azoteq,conv-frac:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's conversion frequency fraction.
+
+ patternProperties:
+ "^event-(tap(-double|-triple)?|hold|palm|swipe-(x|y)-(pos|neg)(-hold)?)$":
+ type: object
+ $ref: ../input.yaml#
+ description:
+ Represents a gesture event reported by the trackpad. In the case of
+ axial gestures, the duration or distance specified in one direction
+ applies to both directions along the same axis.
+
+ properties:
+ linux,code: true
+
+ azoteq,gesture-max-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the maximum duration of tap/swipe gestures.
+
+ azoteq,gesture-mid-ms:
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the maximum duration between subsequent tap gestures
+ (IQS7211E only).
+
+ azoteq,gesture-min-ms:
+ minimum: 0
+ maximum: 65535
+ description: Specifies the minimum duration of hold gestures.
+
+ azoteq,gesture-dist:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the minimum (swipe) or maximum (tap and hold) distance
+ a finger may travel to be considered a gesture.
+
+ azoteq,gesture-dist-rep:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the minimum distance a finger must travel to elicit a
+ repeated swipe gesture (IQS7211E only).
+
+ azoteq,gesture-angle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 75
+ description:
+ Specifies the maximum angle (in degrees) a finger may travel to
+ be considered a swipe gesture.
+
+ azoteq,thresh:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 42
+ description: Specifies the palm gesture threshold (IQS7211E only).
+
+ additionalProperties: false
+
+ dependencies:
+ azoteq,rx-enable: ["azoteq,tx-enable"]
+ azoteq,tx-enable: ["azoteq,rx-enable"]
+ azoteq,channel-select: ["azoteq,rx-enable"]
+
+ additionalProperties: false
+
+ alp:
+ type: object
+ $ref: ../input.yaml#
+ description: Represents the alternate low-power channel (ALP).
+
+ properties:
+ azoteq,rx-enable:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 7
+ description:
+ Specifies the CRx pin(s) associated with the ALP in no particular
+ order.
+
+ azoteq,tx-enable:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 12
+ items:
+ minimum: 0
+ maximum: 11
+ description:
+ Specifies the CTx pin(s) associated with the ALP in no particular
+ order.
+
+ azoteq,ati-frac-div-fine:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the ALP's ATI fine fractional divider.
+
+ azoteq,ati-frac-mult-coarse:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description: Specifies the ALP's ATI coarse fractional multiplier.
+
+ azoteq,ati-frac-div-coarse:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the ALP's ATI coarse fractional divider.
+
+ azoteq,ati-comp-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the ALP's ATI compensation divider.
+
+ azoteq,ati-target:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description: Specifies the ALP's ATI target.
+
+ azoteq,ati-base:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ multipleOf: 8
+ minimum: 0
+ maximum: 255
+ description: Specifies the ALP's ATI base.
+
+ azoteq,ati-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ Specifies the ALP's ATI mode as follows:
+ 0: Partial
+ 1: Full
+
+ azoteq,sense-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ Specifies the ALP's sensing mode as follows:
+ 0: Self capacitive
+ 1: Mutual capacitive
+
+ azoteq,debounce-enter:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the ALP's debounce entrance factor.
+
+ azoteq,debounce-exit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the ALP's debounce exit factor.
+
+ azoteq,thresh:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description: Specifies the ALP's proximity or touch threshold.
+
+ azoteq,conv-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the ALP's conversion period.
+
+ azoteq,conv-frac:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the ALP's conversion frequency fraction.
+
+ linux,code: true
+
+ additionalProperties: false
+
+ button:
+ type: object
+ description: Represents the inductive or capacitive button.
+
+ properties:
+ azoteq,ati-frac-div-fine:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the button's ATI fine fractional divider.
+
+ azoteq,ati-frac-mult-coarse:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description: Specifies the button's ATI coarse fractional multiplier.
+
+ azoteq,ati-frac-div-coarse:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the button's ATI coarse fractional divider.
+
+ azoteq,ati-comp-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 31
+ description: Specifies the button's ATI compensation divider.
+
+ azoteq,ati-target:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description: Specifies the button's ATI target.
+
+ azoteq,ati-base:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ multipleOf: 8
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's ATI base.
+
+ azoteq,ati-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ Specifies the button's ATI mode as follows:
+ 0: Partial
+ 1: Full
+
+ azoteq,sense-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ description: |
+ Specifies the button's sensing mode as follows:
+ 0: Self capacitive
+ 1: Mutual capacitive
+ 2: Inductive
+
+ azoteq,touch-enter:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's touch entrance factor.
+
+ azoteq,touch-exit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's touch exit factor.
+
+ azoteq,debounce-enter:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's debounce entrance factor.
+
+ azoteq,debounce-exit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's debounce exit factor.
+
+ azoteq,thresh:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description: Specifies the button's proximity threshold.
+
+ azoteq,conv-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's conversion period.
+
+ azoteq,conv-frac:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the button's conversion frequency fraction.
+
+ patternProperties:
+ "^event-(prox|touch)$":
+ type: object
+ $ref: ../input.yaml#
+ description:
+ Represents a proximity or touch event reported by the button.
+
+ properties:
+ linux,code: true
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ wakeup-source: true
+
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+dependencies:
+ touchscreen-size-x: ["azoteq,num-contacts"]
+ touchscreen-size-y: ["azoteq,num-contacts"]
+ touchscreen-inverted-x: ["azoteq,num-contacts"]
+ touchscreen-inverted-y: ["azoteq,num-contacts"]
+ touchscreen-swapped-x-y: ["azoteq,num-contacts"]
+
+required:
+ - compatible
+ - reg
+ - irq-gpios
+
+additionalProperties: false
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: azoteq,iqs7210a
+
+ then:
+ properties:
+ alp:
+ properties:
+ azoteq,rx-enable:
+ maxItems: 4
+ items:
+ minimum: 4
+
+ else:
+ properties:
+ azoteq,timeout-press-ms: false
+
+ alp:
+ properties:
+ azoteq,ati-mode: false
+
+ button: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: azoteq,iqs7211e
+
+ then:
+ properties:
+ reset-gpios: false
+
+ trackpad:
+ properties:
+ azoteq,tx-enable:
+ maxItems: 13
+ items:
+ maximum: 12
+
+ alp:
+ properties:
+ azoteq,tx-enable:
+ maxItems: 13
+ items:
+ maximum: 12
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/input.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@56 {
+ compatible = "azoteq,iqs7210a";
+ reg = <0x56>;
+ irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio 17 (GPIO_ACTIVE_LOW |
+ GPIO_PUSH_PULL)>;
+ azoteq,num-contacts = <2>;
+
+ trackpad {
+ azoteq,rx-enable = <6>, <5>, <4>, <3>, <2>;
+ azoteq,tx-enable = <1>, <7>, <8>, <9>, <10>;
+ };
+
+ button {
+ azoteq,sense-mode = <2>;
+ azoteq,touch-enter = <40>;
+ azoteq,touch-exit = <36>;
+
+ event-touch {
+ linux,code = <KEY_HOME>;
+ };
+ };
+
+ alp {
+ azoteq,sense-mode = <1>;
+ linux,code = <KEY_POWER>;
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/input.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@56 {
+ compatible = "azoteq,iqs7211e";
+ reg = <0x56>;
+ irq-gpios = <&gpio 4 (GPIO_ACTIVE_LOW |
+ GPIO_OPEN_DRAIN)>;
+
+ trackpad {
+ event-tap {
+ linux,code = <KEY_PLAYPAUSE>;
+ };
+
+ event-tap-double {
+ linux,code = <KEY_SHUFFLE>;
+ };
+
+ event-tap-triple {
+ linux,code = <KEY_AGAIN>;
+ };
+
+ event-hold {
+ linux,code = <KEY_STOP>;
+ };
+
+ event-palm {
+ linux,code = <KEY_EXIT>;
+ };
+
+ event-swipe-x-pos {
+ linux,code = <KEY_REWIND>;
+ };
+
+ event-swipe-x-pos-hold {
+ linux,code = <KEY_PREVIOUS>;
+ };
+
+ event-swipe-x-neg {
+ linux,code = <KEY_FASTFORWARD>;
+ };
+
+ event-swipe-x-neg-hold {
+ linux,code = <KEY_NEXT>;
+ };
+
+ event-swipe-y-pos {
+ linux,code = <KEY_VOLUMEUP>;
+ };
+
+ event-swipe-y-pos-hold {
+ linux,code = <KEY_MUTE>;
+ };
+
+ event-swipe-y-neg {
+ linux,code = <KEY_VOLUMEDOWN>;
+ };
+
+ event-swipe-y-neg-hold {
+ linux,code = <KEY_MUTE>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt b/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt
deleted file mode 100644
index da4c9d8b99b1..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/bu21013.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-* Rohm BU21013 Touch Screen
-
-Required properties:
- - compatible : "rohm,bu21013_tp"
- - reg : I2C device address
- - reset-gpios : GPIO pin enabling (selecting) chip (CS)
- - interrupt-parent : the phandle for the gpio controller
- - interrupts : (gpio) interrupt to which the chip is connected
-
-Optional properties:
- - touch-gpios : GPIO pin registering a touch event
- - <supply_name>-supply : Phandle to a regulator supply
- - touchscreen-size-x : General touchscreen binding, see [1].
- - touchscreen-size-y : General touchscreen binding, see [1].
- - touchscreen-inverted-x : General touchscreen binding, see [1].
- - touchscreen-inverted-y : General touchscreen binding, see [1].
- - touchscreen-swapped-x-y : General touchscreen binding, see [1].
-
-[1] All general touchscreen properties are described in
- Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt.
-
-Deprecated properties:
- - rohm,touch-max-x : Maximum outward permitted limit in the X axis
- - rohm,touch-max-y : Maximum outward permitted limit in the Y axis
- - rohm,flip-x : Flip touch coordinates on the X axis
- - rohm,flip-y : Flip touch coordinates on the Y axis
-
-Example:
-
- i2c@80110000 {
- bu21013_tp@5c {
- compatible = "rohm,bu21013_tp";
- reg = <0x5c>;
- interrupt-parent = <&gpio2>;
- interrupts <&20 IRQ_TYPE_LEVEL_LOW>;
- touch-gpio = <&gpio2 20 GPIO_ACTIVE_LOW>;
- avdd-supply = <&ab8500_ldo_aux1_reg>;
-
- touchscreen-size-x = <384>;
- touchscreen-size-y = <704>;
- touchscreen-inverted-y;
- };
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml b/Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml
index 9df685bdc5db..74a8a01e0745 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/chipone,icn8318.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ChipOne ICN8318 Touchscreen Controller Device Tree Bindings
+title: ChipOne ICN8318 Touchscreen Controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff --git a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
deleted file mode 100644
index 2e1490a8fe74..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* Toradex Colibri VF50 Touchscreen driver
-
-Required Properties:
-- compatible must be toradex,vf50-touchscreen
-- io-channels: adc channels being used by the Colibri VF50 module
-- xp-gpios: FET gate driver for input of X+
-- xm-gpios: FET gate driver for input of X-
-- yp-gpios: FET gate driver for input of Y+
-- ym-gpios: FET gate driver for input of Y-
-- interrupts: pen irq interrupt for touch detection
-- pinctrl-names: "idle", "default", "gpios"
-- pinctrl-0: pinctrl node for pen/touch detection state pinmux
-- pinctrl-1: pinctrl node for X/Y and pressure measurement (ADC) state pinmux
-- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
-- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y values
-
-Example:
-
- touchctrl: vf50_touchctrl {
- compatible = "toradex,vf50-touchscreen";
- io-channels = <&adc1 0>,<&adc0 0>,
- <&adc0 1>,<&adc1 2>;
- xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
- xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
- yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
- ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
- interrupt-parent = <&gpio0>;
- interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "idle","default","gpios";
- pinctrl-0 = <&pinctrl_touchctrl_idle>;
- pinctrl-1 = <&pinctrl_touchctrl_default>;
- pinctrl-2 = <&pinctrl_touchctrl_gpios>;
- vf50-ts-min-pressure = <200>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml
index 3225c8d1fdaf..86a6d18f952a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma140.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/cypress,cy8ctma140.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cypress CY8CTMA140 series touchscreen controller bindings
+title: Cypress CY8CTMA140 series touchscreen controller
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml
index 762e56ee90cd..4dfbb93678b5 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/cypress,cy8ctma340.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cypress CY8CTMA340 series touchscreen controller bindings
+title: Cypress CY8CTMA340 series touchscreen controller
description: The Cypress CY8CTMA340 series (also known as "CYTTSP" after
the marketing name Cypress TrueTouch Standard Product) touchscreens can
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
new file mode 100644
index 000000000000..037e5d3c447f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/cypress,tt21000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress TT21000 touchscreen controller
+
+description: The Cypress TT21000 series (also known as "CYTTSP5" after
+ the marketing name Cypress TrueTouch Standard Product series 5).
+
+maintainers:
+ - Alistair Francis <alistair@alistair23.me>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ const: cypress,tt21000
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator for voltage.
+
+ vddio-supply:
+ description: Optional Regulator for I/O voltage.
+
+ reset-gpios:
+ maxItems: 1
+
+ linux,keycodes:
+ description: EV_ABS specific event code generated by the axis.
+
+ wakeup-source: true
+
+patternProperties:
+ "^button@[0-9]+$":
+ type: object
+ $ref: ../input.yaml#
+ properties:
+ reg:
+ maxItems: 1
+ linux,keycodes:
+ description: Keycode to emit
+
+ required:
+ - reg
+ - linux,keycodes
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@24 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "cypress,tt21000";
+ reg = <0x24>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&tp_reset_ds203>;
+ interrupt-parent = <&pio>;
+ interrupts = <1 5 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&reg_touch>;
+
+ button@0 {
+ reg = <0>;
+ linux,keycodes = <KEY_HOMEPAGE>;
+ };
+
+ button@1 {
+ reg = <1>;
+ linux,keycodes = <KEY_MENU>;
+ };
+
+ button@2 {
+ reg = <2>;
+ linux,keycodes = <KEY_BACK>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
index 46bc8c028fe6..7d3edb58f72d 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/edt-ft5x06.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: FocalTech EDT-FT5x06 Polytouch Bindings
+title: FocalTech EDT-FT5x06 Polytouch
description: |
There are 5 variants of the chip for various touch panel sizes
@@ -39,7 +39,12 @@ properties:
- edt,edt-ft5406
- edt,edt-ft5506
- evervision,ev-ft5726
+ - focaltech,ft5426
+ - focaltech,ft5452
- focaltech,ft6236
+ - focaltech,ft8201
+ - focaltech,ft8716
+ - focaltech,ft8719
reg:
maxItems: 1
@@ -93,16 +98,15 @@ properties:
minimum: 1
maximum: 255
- touchscreen-size-x: true
- touchscreen-size-y: true
- touchscreen-fuzz-x: true
- touchscreen-fuzz-y: true
- touchscreen-inverted-x: true
- touchscreen-inverted-y: true
- touchscreen-swapped-x-y: true
+ threshold:
+ description: Allows setting the "click"-threshold in the range from 0 to 255.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
interrupt-controller: true
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
@@ -116,7 +120,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
- edt-ft5x06@38 {
+ touchscreen@38 {
compatible = "edt,edt-ft5406";
reg = <0x38>;
interrupt-parent = <&gpio2>;
diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
index 007adbc89c14..930c70104b3f 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
@@ -9,21 +9,35 @@ title: EETI EXC3000 series touchscreen controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
-allOf:
- - $ref: touchscreen.yaml#
-
properties:
compatible:
- enum:
- - eeti,exc3000
- - eeti,exc80h60
- - eeti,exc80h84
+ oneOf:
+ - const: eeti,exc3000
+ - const: eeti,exc80h60
+ - const: eeti,exc80h84
+ - const: eeti,egalax_ts # Do NOT use for new binding
+ - const: eeti,exc3000-i2c
+ deprecated: true
+ - items:
+ - enum:
+ - eeti,exc81w32
+ - const: eeti,exc80h84
reg:
- const: 0x2a
+ enum: [0x4, 0xa, 0x2a]
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
+ wakeup-gpios:
+ maxItems: 1
+ vdd-supply:
+ description: Power supply regulator for the chip
+ attn-gpios:
+ deprecated: true
+ maxItems: 1
+ description: Phandle to a GPIO to check whether interrupt is still
+ latched. This is necessary for platforms that lack
+ support for level-triggered IRQs.
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-inverted-x: true
@@ -34,11 +48,33 @@ required:
- compatible
- reg
- interrupts
- - touchscreen-size-x
- - touchscreen-size-y
additionalProperties: false
+allOf:
+ - $ref: touchscreen.yaml#
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - eeti,egalax_ts
+ - eeti,exc3000-i2c
+ then:
+ properties:
+ reg:
+ const: 0x2a
+
+ wakeup-gpios: false
+
+ attn-gpios: false
+
+ required:
+ - touchscreen-size-x
+ - touchscreen-size-y
+
examples:
- |
#include "dt-bindings/interrupt-controller/irq.h"
diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti.txt b/Documentation/devicetree/bindings/input/touchscreen/eeti.txt
deleted file mode 100644
index 32b3712c916e..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/eeti.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Bindings for EETI touchscreen controller
-
-Required properties:
-- compatible: should be "eeti,exc3000-i2c"
-- reg: I2C address of the chip. Should be set to <0xa>
-- interrupts: interrupt to which the chip is connected
-
-Optional properties:
-- attn-gpios: A handle to a GPIO to check whether interrupt is still
- latched. This is necessary for platforms that lack
- support for level-triggered IRQs.
-
-The following optional properties described in touchscreen.txt are
-also supported:
-
-- touchscreen-inverted-x
-- touchscreen-inverted-y
-- touchscreen-swapped-x-y
-
-Example:
-
-i2c-master {
- touchscreen@a {
- compatible = "eeti,exc3000-i2c";
- reg = <0xa>;
- interrupt-parent = <&gpio>;
- interrupts = <123 IRQ_TYPE_EDGE_RISING>;
- attn-gpios = <&gpio 123 GPIO_ACTIVE_HIGH>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
deleted file mode 100644
index 92fb2620f5e2..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* EETI eGalax Multiple Touch Controller
-
-Required properties:
-- compatible: must be "eeti,egalax_ts"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-- wakeup-gpios: the gpio pin to be used for waking up the controller
- and also used as irq pin
-
-Example:
-
- touchscreen@4 {
- compatible = "eeti,egalax_ts";
- reg = <0x04>;
- interrupt-parent = <&gpio1>;
- interrupts = <9 2>;
- wakeup-gpios = <&gpio1 9 0>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
deleted file mode 100644
index c9f2c9f578e3..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Elan eKTF2127 I2C touchscreen controller
-
-Required properties:
- - compatible : "elan,ektf2127" or "elan,ektf2132"
- - reg : I2C slave address of the chip (0x40)
- - interrupts : interrupt specification for the ektf2127 interrupt
- - power-gpios : GPIO specification for the pin connected to the
- ektf2127's wake input. This needs to be driven high
- to take ektf2127 out of its low power state
-
-For additional optional properties see: touchscreen.txt
-
-Example:
-
-i2c@00000000 {
- ektf2127: touchscreen@15 {
- compatible = "elan,ektf2127";
- reg = <0x15>;
- interrupt-parent = <&pio>;
- interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>
- power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
- touchscreen-inverted-x;
- touchscreen-swapped-x-y;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml b/Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
new file mode 100644
index 000000000000..ff0ec3fd24c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/elan,ektf2127.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/elan,ektf2127.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Elan eKTF2127 I2C touchscreen controller
+
+maintainers:
+ - Siebren Vroegindeweij <siebren.vroegindeweij@hotmail.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - elan,ektf2127
+ - elan,ektf2132
+ - elan,ektf2232
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@15 {
+ compatible = "elan,ektf2127";
+ reg = <0x15>;
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
+ power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
+ touchscreen-inverted-x;
+ touchscreen-swapped-x-y;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml b/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml
index a9b53c2e6f0a..3255c2c8951a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/input/touchscreen/elan,elants_i2c.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/input/touchscreen/elan,elants_i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Elantech I2C Touchscreen
@@ -14,9 +14,13 @@ allOf:
properties:
compatible:
- enum:
- - elan,ektf3624
- - elan,ekth3500
+ oneOf:
+ - enum:
+ - elan,ektf3624
+ - elan,ekth3500
+ - items:
+ - const: elan,ekth3915
+ - const: elan,ekth3500
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
new file mode 100644
index 000000000000..a99280aefcbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx6ul-tsc.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/fsl,imx6ul-tsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX6UL Touch Controller
+
+maintainers:
+ - Haibo Chen <haibo.chen@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ const: fsl,imx6ul-tsc
+
+ reg:
+ items:
+ - description: touch controller address
+ - description: ADC2 address
+
+ interrupts:
+ items:
+ - description: touch controller address
+ - description: ADC2 address
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: tsc
+ - const: adc
+
+ xnur-gpios:
+ maxItems: 1
+ description:
+ The X- gpio this controller connect to. This xnur-gpio returns to
+ low once the finger leave the touch screen (The last touch event
+ the touch controller capture).
+
+ measure-delay-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The value of measure delay time. Before X-axis or Y-axis measurement,
+ the screen need some time before even potential distribution ready.
+ default: 0xffff
+ minimum: 0
+ maximum: 0xffffff
+
+ pre-charge-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The touch screen need some time to precharge.
+ default: 0xfff
+ minimum: 0
+ maximum: 0xffffffff
+
+ touchscreen-average-samples:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of data samples which are averaged for each read.
+ enum: [ 1, 4, 8, 16, 32 ]
+
+ debounce-delay-us:
+ description: |
+ Minimum duration in microseconds a signal must remain stable
+ to be considered valid.
+
+ Drivers must convert this value to IPG clock cycles and map
+ it to one of the four discrete thresholds exposed by the
+ TSC_DEBUG_MODE2 register:
+
+ 0: 8191 IPG cycles
+ 1: 4095 IPG cycles
+ 2: 2047 IPG cycles
+ 3: 1023 IPG cycles
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - xnur-gpios
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx6ul-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
+ touchscreen@2040000 {
+ compatible = "fsl,imx6ul-tsc";
+ reg = <0x02040000 0x4000>, <0x0219c000 0x4000>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6UL_CLK_IPG>,
+ <&clks IMX6UL_CLK_ADC2>;
+ clock-names = "tsc", "adc";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc>;
+ xnur-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ measure-delay-time = <0xfff>;
+ pre-charge-time = <0xffff>;
+ touchscreen-average-samples = <32>;
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml
new file mode 100644
index 000000000000..c40d92b7f4af
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/goodix,gt9916.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Goodix Berlin series touchscreen controller
+
+description: The Goodix Berlin series of touchscreen controllers
+ be connected to either I2C or SPI buses.
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: touchscreen.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - goodix,gt9897
+ - goodix,gt9916
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog power supply regulator on AVDD pin
+
+ vddio-supply:
+ description: power supply regulator on VDDIO pin
+
+ spi-max-frequency: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-swapped-x-y: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - avdd-supply
+ - touchscreen-size-x
+ - touchscreen-size-y
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@5d {
+ compatible = "goodix,gt9916";
+ reg = <0x5d>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&ts_avdd>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <768>;
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ num-cs = <1>;
+ cs-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+ touchscreen@0 {
+ compatible = "goodix,gt9916";
+ reg = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&ts_avdd>;
+ spi-max-frequency = <1000000>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <768>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
index 19ac9da421df..a96137c6f063 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/goodix.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Goodix GT9xx series touchscreen controller Bindings
+title: Goodix GT9xx series touchscreen controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
@@ -37,8 +37,9 @@ properties:
maxItems: 1
irq-gpios:
- description: GPIO pin used for IRQ. The driver uses the interrupt gpio pin
- as output to reset the device.
+ description: GPIO pin used for IRQ input. Additionally, this line is
+ sampled by the device on reset deassertion to select the I2C client
+ address, thus it can be driven by the host during the reset sequence.
maxItems: 1
reset-gpios:
@@ -61,14 +62,13 @@ additionalProperties: false
required:
- compatible
- reg
- - interrupts
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
- gt928@5d {
+ touchscreen@5d {
compatible = "goodix,gt928";
reg = <0x5d>;
interrupt-parent = <&gpio>;
diff --git a/Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml
new file mode 100644
index 000000000000..f5cfacb5e966
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/himax,hx83112b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax hx83112b touchscreen controller
+
+maintainers:
+ - Job Noorman <job@noorman.info>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - himax,hx83100a
+ - himax,hx83112b
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-swapped-x-y: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+ - touchscreen-size-x
+ - touchscreen-size-y
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@48 {
+ compatible = "himax,hx83112b";
+ reg = <0x48>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <65 IRQ_TYPE_LEVEL_LOW>;
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <2160>;
+ reset-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/himax,hx852es.yaml b/Documentation/devicetree/bindings/input/touchscreen/himax,hx852es.yaml
new file mode 100644
index 000000000000..40a60880111d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/himax,hx852es.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/himax,hx852es.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Himax HX852x(ES) touch panel controller
+
+maintainers:
+ - Stephan Gerhold <stephan@gerhold.net>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - himax,hx8525e
+ - himax,hx8526e
+ - himax,hx8527e
+ - const: himax,hx852es
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: Touch Screen Interrupt (TSIX), active low
+
+ reset-gpios:
+ maxItems: 1
+ description: External Reset (XRES), active low
+
+ vcca-supply:
+ description: Analog power supply (VCCA)
+
+ vccd-supply:
+ description: Digital power supply (VCCD)
+
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-swapped-x-y: true
+
+ linux,keycodes:
+ minItems: 1
+ maxItems: 4
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "himax,hx8527e", "himax,hx852es";
+ reg = <0x48>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&tlmm 12 GPIO_ACTIVE_LOW>;
+ vcca-supply = <&reg_ts_vcca>;
+ vccd-supply = <&pm8916_l6>;
+ linux,keycodes = <KEY_BACK KEY_HOMEPAGE KEY_APPSELECT>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml b/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
index 942562f1e45b..874c0781c476 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/hycon,hy46xx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/hycon,hy46xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Hycon HY46XX series touchscreen controller bindings
+title: Hycon HY46XX series touchscreen controller
description: |
There are 6 variants of the chip for various touch panel sizes and cover lens material
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816x.yaml b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816x.yaml
new file mode 100644
index 000000000000..72d4da636881
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cst816x.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/hynitron,cst816x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hynitron CST816x Series Capacitive Touch controller
+
+maintainers:
+ - Oleh Kuzhylnyi <kuzhylol@gmail.com>
+
+description: |
+ Bindings for CST816x high performance self-capacitance touch chip series
+ with single point gesture and real two-point operation.
+
+properties:
+ compatible:
+ enum:
+ - hynitron,cst816s
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ linux,keycodes:
+ minItems: 1
+ items:
+ - description: Slide up gesture
+ - description: Slide down gesture
+ - description: Slide left gesture
+ - description: Slide right gesture
+ - description: Long press gesture
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@15 {
+ compatible = "hynitron,cst816s";
+ reg = <0x15>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ linux,keycodes = <KEY_UP>, <KEY_DOWN>, <KEY_LEFT>, <KEY_RIGHT>,
+ <BTN_TOOL_TRIPLETAP>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml
new file mode 100644
index 000000000000..9cb5d4af00f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/hynitron,cstxxx.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/hynitron,cstxxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hynitron cstxxx series touchscreen controller
+
+description: |
+ Bindings for Hynitron cstxxx series multi-touch touchscreen
+ controllers.
+
+maintainers:
+ - Chris Morgan <macromorgan@hotmail.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - hynitron,cst340
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@1a {
+ compatible = "hynitron,cst340";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <640>;
+ touchscreen-size-y = <480>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
index e3a2b871e50c..0ef79343bf9a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
@@ -4,21 +4,22 @@
$id: http://devicetree.org/schemas/input/touchscreen/imagis,ist3038c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Imagis IST30XXC family touchscreen controller bindings
+title: Imagis IST30XXC family touchscreen controller
maintainers:
- Markuss Broks <markuss.broks@gmail.com>
-allOf:
- - $ref: touchscreen.yaml#
-
properties:
$nodename:
pattern: "^touchscreen@[0-9a-f]+$"
compatible:
enum:
+ - imagis,ist3032c
+ - imagis,ist3038
+ - imagis,ist3038b
- imagis,ist3038c
+ - imagis,ist3038h
reg:
maxItems: 1
@@ -32,6 +33,11 @@ properties:
vddio-supply:
description: Power supply regulator for the I2C bus
+ linux,keycodes:
+ description: Keycodes for the touch keys
+ minItems: 2
+ maxItems: 5
+
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-fuzz-x: true
@@ -42,6 +48,18 @@ properties:
additionalProperties: false
+allOf:
+ - $ref: touchscreen.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: imagis,ist3032c
+ then:
+ properties:
+ linux,keycodes: false
+
required:
- compatible
- reg
@@ -70,5 +88,22 @@ examples:
touchscreen-inverted-y;
};
};
+ - |
+ #include <dt-bindings/input/linux-event-codes.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@50 {
+ compatible = "imagis,ist3032c";
+ reg = <0x50>;
+ interrupt-parent = <&gpio>;
+ interrupts = <72 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&ldo2>;
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <800>;
+ linux,keycodes = <KEY_APPSELECT>, <KEY_BACK>;
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
deleted file mode 100644
index 164915004424..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-* Freescale i.MX6UL Touch Controller
-
-Required properties:
-- compatible: must be "fsl,imx6ul-tsc".
-- reg: this touch controller address and the ADC2 address.
-- interrupts: the interrupt of this touch controller and ADC2.
-- clocks: the root clock of touch controller and ADC2.
-- clock-names; must be "tsc" and "adc".
-- xnur-gpio: the X- gpio this controller connect to.
- This xnur-gpio returns to low once the finger leave the touch screen (The
- last touch event the touch controller capture).
-
-Optional properties:
-- measure-delay-time: the value of measure delay time.
- Before X-axis or Y-axis measurement, the screen need some time before
- even potential distribution ready.
- This value depends on the touch screen.
-- pre-charge-time: the touch screen need some time to precharge.
- This value depends on the touch screen.
-- touchscreen-average-samples: Number of data samples which are averaged for
- each read. Valid values are 1, 4, 8, 16 and 32.
-
-Example:
- tsc: tsc@2040000 {
- compatible = "fsl,imx6ul-tsc";
- reg = <0x02040000 0x4000>, <0x0219c000 0x4000>;
- interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6UL_CLK_IPG>,
- <&clks IMX6UL_CLK_ADC2>;
- clock-names = "tsc", "adc";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_tsc>;
- xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
- measure-delay-time = <0xfff>;
- pre-charge-time = <0xffff>;
- touchscreen-average-samples = <32>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt
deleted file mode 100644
index 41cbf4b7a670..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* NXP LPC32xx SoC Touchscreen Controller (TSC)
-
-Required properties:
-- compatible: must be "nxp,lpc3220-tsc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The TSC/ADC interrupt
-
-Example:
-
- tsc@40048000 {
- compatible = "nxp,lpc3220-tsc";
- reg = <0x40048000 0x1000>;
- interrupt-parent = <&mic>;
- interrupts = <39 0>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
deleted file mode 100644
index 05e982c3454e..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* MAXI MAX11801 Resistive touch screen controller with i2c interface
-
-Required properties:
-- compatible: must be "maxim,max11801"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-
-Example:
-
-&i2c1 {
- max11801: touchscreen@48 {
- compatible = "maxim,max11801";
- reg = <0x48>;
- interrupt-parent = <&gpio3>;
- interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml b/Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml
new file mode 100644
index 000000000000..4f528d220199
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/maxim,max11801.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/maxim,max11801.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAXI MAX11801 Resistive touch screen controller with i2c interface
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: maxim,max11801
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+allOf:
+ - $ref: touchscreen.yaml
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "maxim,max11801";
+ reg = <0x48>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml b/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml
index 62366886fb3e..90ebd4f8354c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/melfas,mms114.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/melfas,mms114.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Melfas MMS114 family touchscreen controller bindings
+title: Melfas MMS114 family touchscreen controller
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -17,13 +17,17 @@ properties:
pattern: "^touchscreen(@.*)?$"
compatible:
- items:
+ oneOf:
- enum:
- melfas,mms114
- melfas,mms134s
- melfas,mms136
- melfas,mms152
- melfas,mms345l
+ - items:
+ - enum:
+ - melfas,mms252
+ - const: melfas,mms114
reg:
description: I2C address
@@ -52,6 +56,11 @@ properties:
touchscreen-swapped-x-y: true
touchscreen-max-pressure: true
+ linux,keycodes:
+ description: Keycodes for the touch keys
+ minItems: 1
+ maxItems: 15
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/input/touchscreen/mstar,msg2638.yaml b/Documentation/devicetree/bindings/input/touchscreen/mstar,msg2638.yaml
index 3a42c23faf6f..ddbbc820c7e5 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/mstar,msg2638.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/mstar,msg2638.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/mstar,msg2638.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MStar msg2638 touchscreen controller Bindings
+title: MStar msg2638 touchscreen controller
maintainers:
- Vincent Knecht <vincent.knecht@mailoo.org>
@@ -14,7 +14,9 @@ allOf:
properties:
compatible:
- const: mstar,msg2638
+ enum:
+ - mstar,msg2138
+ - mstar,msg2638
reg:
const: 0x26
@@ -34,6 +36,10 @@ properties:
touchscreen-size-x: true
touchscreen-size-y: true
+ linux,keycodes:
+ minItems: 1
+ maxItems: 4
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
new file mode 100644
index 000000000000..c2ee89b76ea1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/neonode,zforce.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/neonode,zforce.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Neonode infrared touchscreen controller
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ const: neonode,zforce
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ irq-gpios:
+ maxItems: 1
+
+ x-size:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-size:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@50 {
+ compatible = "neonode,zforce";
+ reg = <0x50>;
+ interrupts = <2 0>;
+ vdd-supply = <&reg_zforce_vdd>;
+
+ reset-gpios = <&gpio5 9 0>; /* RST */
+ irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
+
+ touchscreen-min-x = <0>;
+ touchscreen-size-x = <800>;
+ touchscreen-min-y = <0>;
+ touchscreen-size-y = <600>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
new file mode 100644
index 000000000000..bd6a60486d1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/novatek,nvt-ts.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/novatek,nvt-ts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NVT Touchscreen Controller
+
+maintainers:
+ - Hans de Goede <hdegoede@redhat.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - novatek,nt11205-ts
+ - novatek,nt36672a-ts
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vcc-supply: true
+ iovcc-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@1 {
+ compatible = "novatek,nt36672a-ts";
+ reg = <0x01>;
+ interrupts-extended = <&tlmm 31 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l22a_2p85>;
+ iovcc-supply = <&vreg_l14a_1p8>;
+ pinctrl-0 = <&ts_int_default &ts_reset_default>;
+ pinctrl-1 = <&ts_int_sleep &ts_reset_sleep>;
+ pinctrl-names = "default", "sleep";
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <2246>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/input/touchscreen/nxp,lpc3220-tsc.yaml b/Documentation/devicetree/bindings/input/touchscreen/nxp,lpc3220-tsc.yaml
new file mode 100644
index 000000000000..b6feda127c7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/nxp,lpc3220-tsc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/nxp,lpc3220-tsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx SoC Touchscreen Controller (TSC)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc3220-tsc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc32xx-clock.h>
+
+ touchscreen@40048000 {
+ compatible = "nxp,lpc3220-tsc";
+ reg = <0x40048000 0x1000>;
+ interrupt-parent = <&mic>;
+ interrupts = <39 0>;
+ clocks = <&clk LPC32XX_CLK_ADC>;
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml
index f9998edbff70..3305eda5ed88 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/pixcir,pixcir_ts.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Pixcir Touchscreen Controller Device Tree Bindings
+title: Pixcir Touchscreen Controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff --git a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
deleted file mode 100644
index 2a1af240ccc3..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Raspberry Pi firmware based 7" touchscreen
-=====================================
-
-Required properties:
- - compatible: "raspberrypi,firmware-ts"
-
-Optional properties:
- - firmware: Reference to RPi's firmware device node
- - touchscreen-size-x: See touchscreen.txt
- - touchscreen-size-y: See touchscreen.txt
- - touchscreen-inverted-x: See touchscreen.txt
- - touchscreen-inverted-y: See touchscreen.txt
- - touchscreen-swapped-x-y: See touchscreen.txt
-
-Example:
-
-firmware: firmware-rpi {
- compatible = "raspberrypi,bcm2835-firmware";
- mboxes = <&mailbox>;
-
- ts: touchscreen {
- compatible = "raspberrypi,firmware-ts";
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml
index 7fc22a403d48..059d419f6c1c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml
@@ -55,7 +55,7 @@ properties:
touchscreen-min-pressure: true
touchscreen-x-plate-ohms: true
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/input/touchscreen/rohm,bu21013.yaml b/Documentation/devicetree/bindings/input/touchscreen/rohm,bu21013.yaml
new file mode 100644
index 000000000000..adea2c4edf1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/rohm,bu21013.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/rohm,bu21013.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rohm BU21013 touchscreen
+
+description:
+ Rohm BU21013 I2C driven touchscreen controller.
+
+maintainers:
+ - Dario Binacchi <dario.binacchi@amarulasolutions.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - rohm,bu21013_tp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ touch-gpios:
+ maxItems: 1
+ description: GPIO registering a touch event.
+
+ avdd-supply:
+ description: Analogic power supply
+
+ rohm,touch-max-x:
+ deprecated: true
+ description: Maximum value on the X axis.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ rohm,touch-max-y:
+ deprecated: true
+ description: Maximum value on the Y axis.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ rohm,flip-x:
+ deprecated: true
+ description: Flip touch coordinates on the X axis
+ type: boolean
+
+ rohm,flip-y:
+ deprecated: true
+ description: Flip touch coordinates on the Y axis
+ type: boolean
+
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-swapped-x-y: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@5c {
+ compatible = "rohm,bu21013_tp";
+ reg = <0x5c>;
+
+ interrupt-parent = <&gpio2>;
+ interrupts = <0x20 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio2 19 GPIO_ACTIVE_LOW>;
+ touch-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&ab8500_ldo_aux1_reg>;
+
+ touchscreen-size-x = <384>;
+ touchscreen-size-y = <704>;
+ touchscreen-inverted-y;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
deleted file mode 100644
index 6805d10d226d..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* Samsung S6SY761 touchscreen controller
-
-Required properties:
-- compatible : must be "samsung,s6sy761"
-- reg : I2C slave address, (e.g. 0x48)
-- interrupts : interrupt specification
-- avdd-supply : analogic power supply
-- vdd-supply : power supply
-
-Optional properties:
-- touchscreen-size-x : see touchscreen.txt. This property is embedded in the
- device. If defined it forces a different x resolution.
-- touchscreen-size-y : see touchscreen.txt. This property is embedded in the
- device. If defined it forces a different y resolution.
-
-Example:
-
-i2c@00000000 {
-
- /* ... */
-
- touchscreen@48 {
- compatible = "samsung,s6sy761";
- reg = <0x48>;
- interrupt-parent = <&gpa1>;
- interrupts = <1 IRQ_TYPE_NONE>;
- avdd-supply = <&ldo30_reg>;
- vdd-supply = <&ldo31_reg>;
- touchscreen-size-x = <4096>;
- touchscreen-size-y = <4096>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.yaml b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.yaml
new file mode 100644
index 000000000000..1ffd17af3c53
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/samsung,s6sy761.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S6SY761 touchscreen controller
+
+maintainers:
+ - Andi Shyti <andi.shyti@kernel.org>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ const: samsung,s6sy761
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ avdd-supply: true
+ vdd-supply: true
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - avdd-supply
+ - vdd-supply
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "samsung,s6sy761";
+ reg = <0x48>;
+ interrupt-parent = <&gpa1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+ avdd-supply = <&ldo30_reg>;
+ vdd-supply = <&ldo31_reg>;
+ touchscreen-size-x = <4096>;
+ touchscreen-size-y = <4096>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
new file mode 100644
index 000000000000..b2554064b688
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/semtech,sx8654.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/semtech,sx8654.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech SX8654 I2C Touchscreen Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - semtech,sx8650
+ - semtech,sx8654
+ - semtech,sx8655
+ - semtech,sx8656
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@48 {
+ compatible = "semtech,sx8654";
+ reg = <0x48>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
index eec6f7f6f0a3..5381a96f4949 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Silead GSL1680 Touchscreen Controller Device Tree Bindings
+title: Silead GSL1680 Touchscreen Controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
@@ -31,7 +31,7 @@ properties:
maxItems: 1
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
description: >
File basename for board specific firmware
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
index 1d8ca19fd37a..e7ee7a0d74c4 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml
@@ -37,6 +37,7 @@ unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/input/linux-event-codes.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -46,5 +47,33 @@ examples:
reg = <0x55>;
interrupts = <2 0>;
gpios = <&gpio1 166 0>;
+
+ touch-overlay {
+ segment-0 {
+ label = "Touchscreen";
+ x-origin = <0>;
+ x-size = <240>;
+ y-origin = <40>;
+ y-size = <280>;
+ };
+
+ segment-1a {
+ label = "Camera light";
+ linux,code = <KEY_LIGHTS_TOGGLE>;
+ x-origin = <40>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+
+ segment-2a {
+ label = "Power";
+ linux,code = <KEY_POWER>;
+ x-origin = <160>;
+ x-size = <40>;
+ y-origin = <0>;
+ y-size = <40>;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
deleted file mode 100644
index 0a5d0cb4a280..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* ST-Microelectronics FingerTip touchscreen controller
-
-The ST-Microelectronics FingerTip device provides a basic touchscreen
-functionality. Along with it the user can enable the touchkey which can work as
-a basic HOME and BACK key for phones.
-
-The driver supports also hovering as an absolute single touch event with x, y, z
-coordinates.
-
-Required properties:
-- compatible : must be "st,stmfts"
-- reg : I2C slave address, (e.g. 0x49)
-- interrupts : interrupt specification
-- avdd-supply : analogic power supply
-- vdd-supply : power supply
-- touchscreen-size-x : see touchscreen.txt
-- touchscreen-size-y : see touchscreen.txt
-
-Optional properties:
-- touch-key-connected : specifies whether the touchkey feature is connected
-- ledvdd-supply : power supply to the touch key leds
-
-Example:
-
-i2c@00000000 {
-
- /* ... */
-
- touchscreen@49 {
- compatible = "st,stmfts";
- reg = <0x49>;
- interrupt-parent = <&gpa1>;
- interrupts = <1 IRQ_TYPE_NONE>;
- touchscreen-size-x = <1599>;
- touchscreen-size-y = <2559>;
- touch-key-connected;
- avdd-supply = <&ldo30_reg>;
- vdd-supply = <&ldo31_reg>;
- ledvdd-supply = <&ldo33_reg>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
new file mode 100644
index 000000000000..12256ae7df90
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/st,stmfts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST-Microelectronics FingerTip touchscreen controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ The ST-Microelectronics FingerTip device provides a basic touchscreen
+ functionality. Along with it the user can enable the touchkey which can work
+ as a basic HOME and BACK key for phones.
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ const: st,stmfts
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogic power supply
+
+ interrupts:
+ maxItems: 1
+
+ ledvdd-supply:
+ description: Power supply to the touch key leds
+
+ touch-key-connected:
+ type: boolean
+ description: The touchkey feature is connected
+
+ vdd-supply:
+ description: Power supply
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - interrupts
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@49 {
+ compatible = "st,stmfts";
+ reg = <0x49>;
+ interrupt-parent = <&gpa1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ touchscreen-size-x = <1599>;
+ touchscreen-size-y = <2559>;
+ touch-key-connected;
+ avdd-supply = <&ldo30_reg>;
+ vdd-supply = <&ldo31_reg>;
+ ledvdd-supply = <&ldo33_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
deleted file mode 100644
index c549924603d2..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
+++ /dev/null
@@ -1,109 +0,0 @@
-STMPE Touchscreen
-----------------
-
-Required properties:
- - compatible: "st,stmpe-ts"
-
-Optional properties:
-- st,ave-ctrl : Sample average control
- 0 -> 1 sample
- 1 -> 2 samples
- 2 -> 4 samples
- 3 -> 8 samples
-- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
- 0 -> 10 us
- 1 -> 50 us
- 2 -> 100 us
- 3 -> 500 us
- 4 -> 1 ms
- 5 -> 5 ms
- 6 -> 10 ms
- 7 -> 50 ms
-- st,settling : Panel driver settling time (recommended is 2)
- 0 -> 10 us
- 1 -> 100 us
- 2 -> 500 us
- 3 -> 1 ms
- 4 -> 5 ms
- 5 -> 10 ms
- 6 -> 50 ms
- 7 -> 100 ms
-- st,fraction-z : Length of the fractional part in z (recommended is 7)
- (fraction-z ([0..7]) = Count of the fractional part)
-- st,i-drive : current limit value of the touchscreen drivers
- 0 -> 20 mA (typical 35mA max)
- 1 -> 50 mA (typical 80 mA max)
-
-Optional properties common with MFD (deprecated):
- - st,sample-time : ADC conversion time in number of clock.
- 0 -> 36 clocks
- 1 -> 44 clocks
- 2 -> 56 clocks
- 3 -> 64 clocks
- 4 -> 80 clocks (recommended)
- 5 -> 96 clocks
- 6 -> 124 clocks
- - st,mod-12b : ADC Bit mode
- 0 -> 10bit ADC
- 1 -> 12bit ADC
- - st,ref-sel : ADC reference source
- 0 -> internal
- 1 -> external
- - st,adc-freq : ADC Clock speed
- 0 -> 1.625 MHz
- 1 -> 3.25 MHz
- 2 || 3 -> 6.5 MHz
-
-Node name must be stmpe_touchscreen and should be child node of stmpe node to
-which it belongs.
-
-Note that common ADC settings of stmpe_touchscreen (child) will take precedence
-over the settings done in MFD.
-
-Example:
-
-stmpe811@41 {
- compatible = "st,stmpe811";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_touch_int>;
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x41>;
- interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
- interrupt-parent = <&gpio4>;
- interrupt-controller;
- id = <0>;
- blocks = <0x5>;
- irq-trigger = <0x1>;
- /* Common ADC settings */
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
-
- stmpe_touchscreen {
- compatible = "st,stmpe-ts";
- reg = <0>;
- /* 8 sample average control */
- st,ave-ctrl = <3>;
- /* 5 ms touch detect interrupt delay */
- st,touch-det-delay = <5>;
- /* 1 ms panel driver settling time */
- st,settling = <3>;
- /* 7 length fractional part in z */
- st,fraction-z = <7>;
- /*
- * 50 mA typical 80 mA max touchscreen drivers
- * current limit value
- */
- st,i-drive = <1>;
- };
- stmpe_adc {
- compatible = "st,stmpe-adc";
- st,norequest-mask = <0x0F>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
deleted file mode 100644
index 0ebe6dd043c7..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Semtech SX8654 I2C Touchscreen Controller
-
-Required properties:
-- compatible: must be one of the following, depending on the model:
- "semtech,sx8650"
- "semtech,sx8654"
- "semtech,sx8655"
- "semtech,sx8656"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-
-Optional properties:
- - reset-gpios: GPIO specification for the NRST input
-
-Example:
-
- sx8654@48 {
- compatible = "semtech,sx8654";
- reg = <0x48>;
- interrupt-parent = <&gpio6>;
- interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml
new file mode 100644
index 000000000000..8f6335d7da1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/ti,ads7843.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI's SPI driven touch screen controllers
+
+maintainers:
+ - Alexander Stein <alexander.stein@ew.tq-group.com>
+ - Dmitry Torokhov <dmitry.torokhov@gmail.com>
+ - Marek Vasut <marex@denx.de>
+
+description:
+ TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046 SPI driven touch screen
+ controllers.
+
+properties:
+ compatible:
+ enum:
+ - ti,ads7843
+ - ti,ads7845
+ - ti,ads7846
+ - ti,ads7873
+ - ti,tsc2046
+
+ interrupts:
+ maxItems: 1
+
+ pendown-gpio:
+ maxItems: 1
+ description:
+ GPIO handle describing the pin the !PENIRQ line is connected to.
+
+ vcc-supply:
+ description:
+ A regulator node for the supply voltage.
+
+ wakeup-source: true
+
+ ti,debounce-max:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Max number of additional readings per sample.
+
+ ti,debounce-rep:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Additional consecutive good readings required after the first two.
+
+ ti,debounce-tol:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Tolerance used for filtering.
+
+ ti,hsync-gpios:
+ maxItems: 1
+ description:
+ GPIO line to poll for hsync.
+
+ ti,keep-vref-on:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Set to keep Vref on for differential measurements as well.
+
+ ti,pendown-gpio-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Platform specific debounce time for the pendown-gpio.
+
+ ti,penirq-recheck-delay-usecs:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ If set to non-zero, after samples are taken this delay is applied and
+ penirq is rechecked, to help avoid false events. This value is
+ affected by the material used to build the touch layer.
+
+ ti,pressure-max:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Maximum reported pressure value.
+
+ ti,pressure-min:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Minimum reported pressure value (threshold).
+
+ ti,settle-delay-usec:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Settling time of the analog signals; a function of Vcc and the
+ capacitance on the X/Y drivers. If set to non-zero, two samples are
+ taken with settle_delay us apart, and the second one is used. ~150
+ uSec with 0.01uF caps.
+
+ ti,swap-xy:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Swap x and y axis.
+
+ ti,vref-delay-usecs:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Vref supply delay in usecs, 0 for external Vref.
+
+ ti,vref-mv:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ The VREF voltage, in millivolts.
+ Set to 0 to use internal references (ADS7846).
+
+ ti,x-plate-ohms:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Resistance of the X-plate, in Ohms.
+
+ ti,x-max:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Maximum value on the X axis.
+
+ ti,x-min:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Minimum value on the X axis.
+
+ ti,y-plate-ohms:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Resistance of the Y-plate, in Ohms.
+
+ ti,y-max:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Maximum value on the Y axis.
+
+ ti,y-min:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Minimum value on the Y axis.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: touchscreen.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi{
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@0 {
+ compatible = "ti,tsc2046";
+ reg = <0>; /* CS0 */
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 0>; /* BOOT6 / GPIO 8 */
+ pendown-gpio = <&gpio1 8 0>;
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&reg_vcc3>;
+ wakeup-source;
+
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,y-min = /bits/ 16 <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
index 938aab016cc2..7187c390b2f5 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/ti,tsc2005.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments TSC2004 and TSC2005 touchscreen controller bindings
+title: Texas Instruments TSC2004 and TSC2005 touchscreen controller
maintainers:
- Marek Vasut <marex@denx.de>
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2007.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2007.yaml
new file mode 100644
index 000000000000..a595df3ea802
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2007.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/ti,tsc2007.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments tsc2007 touchscreen controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: ti,tsc2007
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ti,x-plate-ohms:
+ description: X-plate resistance in ohms.
+
+ gpios: true
+
+ pendown-gpio: true
+
+ wakeup-source: true
+
+ ti,max-rt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: maximum pressure.
+
+ ti,fuzzx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ specifies the absolute input fuzz x value.
+ If set, it will permit noise in the data up to +- the value given to the fuzz
+ parameter, that is used to filter noise from the event stream.
+
+ ti,fuzzy:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: specifies the absolute input fuzz y value.
+
+ ti,fuzzz:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: specifies the absolute input fuzz z value.
+
+ ti,poll-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ how much time to wait (in milliseconds) before reading again the
+ values from the tsc2007.
+
+required:
+ - compatible
+ - reg
+ - ti,x-plate-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touch@49 {
+ compatible = "ti,tsc2007";
+ reg = <0x49>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0x0 0x8>;
+ gpios = <&gpio4 0 0>;
+ ti,x-plate-ohms = <180>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml
new file mode 100644
index 000000000000..5094c5183c74
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/toradex,vf50-touchscreen.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/toradex,vf50-touchscreen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toradex Colibri VF50 Touchscreen
+
+maintainers:
+ - Dmitry Torokhov <dmitry.torokhov@gmail.com>
+ - Sanchayan Maity <maitysanchayan@gmail.com>
+
+properties:
+ compatible:
+ const: toradex,vf50-touchscreen
+
+ interrupts:
+ maxItems: 1
+
+ io-channels:
+ maxItems: 4
+ description:
+ adc channels being used by the Colibri VF50 module
+ IIO ADC for Y-, X-, Y+, X+ connections
+
+ xp-gpios:
+ description: FET gate driver for input of X+
+
+ xm-gpios:
+ description: FET gate driver for input of X-
+
+ yp-gpios:
+ description: FET gate driver for input of Y+
+
+ ym-gpios:
+ description: FET gate driver for input of Y-
+
+ vf50-ts-min-pressure:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 50
+ maximum: 2000
+ description: pressure level at which to stop measuring X/Y values
+
+required:
+ - compatible
+ - io-channels
+ - xp-gpios
+ - xm-gpios
+ - yp-gpios
+ - ym-gpios
+ - interrupts
+ - vf50-ts-min-pressure
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ touchscreen {
+ compatible = "toradex,vf50-touchscreen";
+ interrupt-parent = <&gpio0>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ io-channels = <&adc1 0>, <&adc0 0>, <&adc0 1>, <&adc1 2>;
+ xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+ xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
+ yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+ ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "idle", "default";
+ pinctrl-0 = <&pinctrl_touchctrl_idle>, <&pinctrl_touchctrl_gpios>;
+ pinctrl-1 = <&pinctrl_touchctrl_default>, <&pinctrl_touchctrl_gpios>;
+ vf50-ts-min-pressure = <200>;
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
deleted file mode 100644
index e1adb902d503..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+++ /dev/null
@@ -1 +0,0 @@
-See touchscreen.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
index 4b5b212c772c..7023e8c73a7b 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
@@ -4,12 +4,19 @@
$id: http://devicetree.org/schemas/input/touchscreen/touchscreen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common touchscreen Bindings
+title: Common touchscreen
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
properties:
+ panel:
+ description: If this touchscreen is integrally connected to a panel, this
+ is a reference to that panel. The presence of this reference indicates
+ that the touchscreen should be power sequenced together with the panel
+ and that they may share power and/or reset signals.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
touchscreen-min-x:
description: minimum x coordinate reported
$ref: /schemas/types.yaml#/definitions/uint32
@@ -80,6 +87,129 @@ properties:
touchscreen-y-plate-ohms:
description: Resistance of the Y-plate in Ohms
+ touch-overlay:
+ description: |
+ List of nodes defining segments (touch areas) on the touchscreen.
+
+ This object can be used to describe a series of segments to restrict
+ the region within touch events are reported or buttons with a specific
+ functionality.
+
+ This is of special interest if the touchscreen is shipped with a physical
+ overlay on top of it with a frame that hides some part of the original
+ touchscreen area. Printed buttons on that overlay are also a typical
+ use case.
+
+ A new touchscreen area is defined as a sub-node without a key code. If a
+ key code is defined in the sub-node, it will be interpreted as a button.
+
+ The x-origin and y-origin properties of a touchscreen area define the
+ offset of a new origin from where the touchscreen events are referenced.
+ This offset is applied to the events accordingly. The x-size and y-size
+ properties define the size of the touchscreen effective area.
+
+ The following example shows a new touchscreen area with the new origin
+ (0',0') for the touch events generated by the device.
+
+ Touchscreen (full area)
+ ┌────────────────────────────────────────┐
+ │ ┌───────────────────────────────┐ │
+ │ │ │ │
+ │ ├ y-size │ │
+ │ │ │ │
+ │ │ touchscreen area │ │
+ │ │ (no key code) │ │
+ │ │ │ │
+ │ │ x-size │ │
+ │ ┌└──────────────┴────────────────┘ │
+ │(0',0') │
+ ┌└────────────────────────────────────────┘
+ (0,0)
+
+ where (0',0') = (0+x-origin,0+y-origin)
+
+ Sub-nodes with key codes report the touch events on their surface as key
+ events instead.
+
+ The following example shows a touchscreen with a single button on it.
+
+ Touchscreen (full area)
+ ┌───────────────────────────────────┐
+ │ │
+ │ │
+ │ ┌─────────┐ │
+ │ │button 0 │ │
+ │ │KEY_POWER│ │
+ │ └─────────┘ │
+ │ │
+ │ │
+ ┌└───────────────────────────────────┘
+ (0,0)
+
+ Segments defining buttons and clipped toushcreen areas can be combined
+ as shown in the following example.
+ In that case only the events within the touchscreen area are reported
+ as touch events. Events within the button areas report their associated
+ key code. Any events outside the defined areas are ignored.
+
+ Touchscreen (full area)
+ ┌─────────┬──────────────────────────────┐
+ │ │ │
+ │ │ ┌───────────────────────┐ │
+ │ button 0│ │ │ │
+ │KEY_POWER│ │ │ │
+ │ │ │ │ │
+ ├─────────┤ │ touchscreen area │ │
+ │ │ │ (no key code) │ │
+ │ │ │ │ │
+ │ button 1│ │ │ │
+ │ KEY_INFO│ ┌└───────────────────────┘ │
+ │ │(0',0') │
+ ┌└─────────┴──────────────────────────────┘
+ (0,0)
+
+ type: object
+
+ patternProperties:
+ '^segment-':
+ type: object
+ description:
+ Each segment is represented as a sub-node.
+ properties:
+ x-origin:
+ description: horizontal origin of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-origin:
+ description: vertical origin of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ x-size:
+ description: horizontal resolution of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-size:
+ description: vertical resolution of the node area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ label:
+ description: descriptive name of the segment
+ $ref: /schemas/types.yaml#/definitions/string
+
+ linux,code: true
+
+ required:
+ - x-origin
+ - y-origin
+ - x-size
+ - y-size
+
+ unevaluatedProperties: false
+
+ debounce-delay-us:
+ description: Minimum duration in microseconds a signal must remain stable
+ to be considered valid.
+
dependencies:
touchscreen-size-x: [ touchscreen-size-y ]
touchscreen-size-y: [ touchscreen-size-x ]
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
deleted file mode 100644
index ed00f61b8c08..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-* Texas Instruments tsc2007 touchscreen controller
-
-Required properties:
-- compatible: must be "ti,tsc2007".
-- reg: I2C address of the chip.
-- ti,x-plate-ohms: X-plate resistance in ohms.
-
-Optional properties:
-- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
- The penirq pin goes to low when the panel is touched.
- (see GPIO binding[1] for more details).
-- interrupts: (gpio) interrupt to which the chip is connected
- (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
- If set, it will permit noise in the data up to +- the value given to the fuzz
- parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
-- ti,poll-period: how much time to wait (in milliseconds) before reading again the
- values from the tsc2007.
-
-[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-[1]: Documentation/devicetree/bindings/gpio/gpio.txt
-
-Example:
- &i2c1 {
- /* ... */
- tsc2007@49 {
- compatible = "ti,tsc2007";
- reg = <0x49>;
- interrupt-parent = <&gpio4>;
- interrupts = <0x0 0x8>;
- gpios = <&gpio4 0 0>;
- ti,x-plate-ohms = <180>;
- };
-
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zeitec,zet6223.yaml b/Documentation/devicetree/bindings/input/touchscreen/zeitec,zet6223.yaml
new file mode 100644
index 000000000000..d5e132ec0273
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/zeitec,zet6223.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/zeitec,zet6223.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zeitec ZET6223 touchscreen controller
+
+description:
+ Zeitec ZET6223 I2C driven touchscreen controller.
+
+maintainers:
+ - Dario Binacchi <dario.binacchi@amarulasolutions.com>
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ enum:
+ - zeitec,zet6223
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vio-supply:
+ description: 1.8V or 3.3V VIO supply.
+
+ vcc-supply:
+ description: 3.3V VCC supply.
+
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-swapped-x-y: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@76 {
+ compatible = "zeitec,zet6223";
+ reg = <0x76>;
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zet6223.txt b/Documentation/devicetree/bindings/input/touchscreen/zet6223.txt
deleted file mode 100644
index 27d55a506f18..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/zet6223.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Zeitec ZET6223 I2C touchscreen controller
-
-Required properties:
-- compatible : "zeitec,zet6223"
-- reg : I2C slave address of the chip (0x76)
-- interrupts : interrupt specification for the zet6223 interrupt
-
-Optional properties:
-
-- vio-supply : Specification for VIO supply (1.8V or 3.3V,
- depending on system interface needs).
-- vcc-supply : Specification for 3.3V VCC supply.
-- touchscreen-size-x : See touchscreen.txt
-- touchscreen-size-y : See touchscreen.txt
-- touchscreen-inverted-x : See touchscreen.txt
-- touchscreen-inverted-y : See touchscreen.txt
-- touchscreen-swapped-x-y : See touchscreen.txt
-
-Example:
-
-i2c@00000000 {
-
- zet6223: touchscreen@76 {
- compatible = "zeitec,zet6223";
- reg = <0x76>;
- interrupt-parent = <&pio>;
- interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>
- };
-
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
deleted file mode 100644
index e3c27c4fd9c8..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* Neonode infrared touchscreen controller
-
-Required properties:
-- compatible: must be "neonode,zforce"
-- reg: I2C address of the chip
-- interrupts: interrupt to which the chip is connected
-- reset-gpios: reset gpio the chip is connected to
-- x-size: horizontal resolution of touchscreen
-- y-size: vertical resolution of touchscreen
-
-Optional properties:
-- irq-gpios : interrupt gpio the chip is connected to
-- vdd-supply: Regulator controlling the controller supply
-
-Example:
-
- i2c@00000000 {
- /* ... */
-
- zforce_ts@50 {
- compatible = "neonode,zforce";
- reg = <0x50>;
- interrupts = <2 0>;
- vdd-supply = <&reg_zforce_vdd>;
-
- reset-gpios = <&gpio5 9 0>; /* RST */
- irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
-
- x-size = <800>;
- y-size = <600>;
- };
-
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml b/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml
index b4e5ba7c0b49..3f663ce3e44e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/input/touchscreen/zinitix,bt400.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Zinitix BT4xx and BT5xx series touchscreen controller bindings
+title: Zinitix BT4xx and BT5xx series touchscreen controller
description: The Zinitix BT4xx and BT5xx series of touchscreen controllers
are Korea-produced touchscreens with embedded microcontrollers. The
@@ -16,6 +16,7 @@ maintainers:
allOf:
- $ref: touchscreen.yaml#
+ - $ref: ../input.yaml#
properties:
$nodename:
@@ -79,6 +80,15 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2]
+ linux,keycodes:
+ description:
+ This property specifies an array of keycodes assigned to the
+ touch-keys that can be present in some touchscreen configurations.
+ If the touch-keys are enabled, controller firmware will assign some
+ touch sense lines to those keys.
+ minItems: 1
+ maxItems: 8
+
touchscreen-size-x: true
touchscreen-size-y: true
touchscreen-fuzz-x: true
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
deleted file mode 100644
index f5021214edec..000000000000
--- a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Texas Instruments TWL family (twl4030) pwrbutton module
-
-This module is part of the TWL4030. For more details about the whole
-chip see Documentation/devicetree/bindings/mfd/twl-family.txt.
-
-This module provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be one of the following
- - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
-- interrupts: should be one of the following
- - <8>: For controllers compatible with twl4030
-
-Example:
-
-&twl {
- twl_pwrbutton: pwrbutton {
- compatible = "ti,twl4030-pwrbutton";
- interrupts = <8>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt b/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
deleted file mode 100644
index 43ef770dfeb9..000000000000
--- a/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Zodiac Inflight Innovations RAVE Supervisory Processor Power Button Bindings
-
-RAVE SP input device is a "MFD cell" device corresponding to power
-button functionality of RAVE Supervisory Processor. It is expected
-that its Device Tree node is specified as a child of the node
-corresponding to the parent RAVE SP device (as documented in
-Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
-
-Required properties:
-
-- compatible: Should be "zii,rave-sp-pwrbutton"
-
-Example:
-
- rave-sp {
- compatible = "zii,rave-sp-rdu1";
- current-speed = <38400>;
-
- pwrbutton {
- compatible = "zii,rave-sp-pwrbutton";
- };
- }
diff --git a/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.yaml b/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.yaml
new file mode 100644
index 000000000000..b26e6fe174f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/zii,rave-sp-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zodiac Inflight Innovations RAVE Supervisory Processor Power Button
+
+maintainers:
+ - Frank Li <Frank.li@nxp.com>
+
+description:
+ RAVE SP input device is a "MFD cell" device corresponding to power
+ button functionality of RAVE Supervisory Processor. It is expected
+ that its Device Tree node is specified as a child of the node
+ corresponding to the parent RAVE SP device (as documented in
+ Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml)
+
+properties:
+ compatible:
+ const: zii,rave-sp-pwrbutton
+
+required:
+ - compatible
+
+allOf:
+ - $ref: input.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwrbutton {
+ compatible = "zii,rave-sp-pwrbutton";
+ };
+
diff --git a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
index fa4f7685ab2b..fc21fe3e7b37 100644
--- a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
+++ b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
@@ -47,10 +47,11 @@ properties:
maxItems: 1
operating-points-v2: true
- opp-table: true
+ opp-table:
+ type: object
fsl,ddrc:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to DDR Controller.
diff --git a/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml b/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml
index 449c7c988229..4d72525f407e 100644
--- a/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml
+++ b/Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml
@@ -17,9 +17,14 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt8183-cci
- - mediatek,mt8186-cci
+ oneOf:
+ - enum:
+ - mediatek,mt8183-cci
+ - mediatek,mt8186-cci
+ - items:
+ - enum:
+ - mediatek,mt7988-cci
+ - const: mediatek,mt8183-cci
clocks:
items:
@@ -36,7 +41,8 @@ properties:
- const: intermediate
operating-points-v2: true
- opp-table: true
+ opp-table:
+ type: object
proc-supply:
description:
diff --git a/Documentation/devicetree/bindings/interconnect/mediatek,mt8183-emi.yaml b/Documentation/devicetree/bindings/interconnect/mediatek,mt8183-emi.yaml
new file mode 100644
index 000000000000..017c8478b2a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/mediatek,mt8183-emi.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/mediatek,mt8183-emi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek External Memory Interface (EMI) Interconnect
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description: |
+ EMI interconnect providers support system bandwidth requirements through
+ Dynamic Voltage Frequency Scaling Resource Collector (DVFSRC) hardware.
+ The provider is able to communicate with the DVFSRC through Secure Monitor
+ Call (SMC).
+
+ ICC provider ICC Nodes
+ ---- ----
+ _________ |CPU | |--- |VPU |
+ _____ | |----- ---- | ----
+ | |->| DRAM | ---- | ----
+ |DRAM |->|scheduler|----- |GPU | |--- |DISP|
+ | |->| (EMI) | ---- | ----
+ |_____|->|_________|---. ----- | ----
+ /|\ `-|MMSYS|--|--- |VDEC|
+ | ----- | ----
+ | | ----
+ | change DRAM freq |--- |VENC|
+ -------- | ----
+ SMC --> | DVFSRC | | ----
+ -------- |--- |IMG |
+ | ----
+ | ----
+ |--- |CAM |
+ ----
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-emi
+ - mediatek,mt8195-emi
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#interconnect-cells'
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,glymur-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,glymur-rpmh.yaml
new file mode 100644
index 000000000000..d55a7bcf5591
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,glymur-rpmh.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,glymur-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on GLYMUR
+
+maintainers:
+ - Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,glymur-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,glymur-aggre1-noc
+ - qcom,glymur-aggre2-noc
+ - qcom,glymur-aggre3-noc
+ - qcom,glymur-aggre4-noc
+ - qcom,glymur-clk-virt
+ - qcom,glymur-cnoc-cfg
+ - qcom,glymur-cnoc-main
+ - qcom,glymur-hscnoc
+ - qcom,glymur-lpass-ag-noc
+ - qcom,glymur-lpass-lpiaon-noc
+ - qcom,glymur-lpass-lpicx-noc
+ - qcom,glymur-mc-virt
+ - qcom,glymur-mmss-noc
+ - qcom,glymur-nsinoc
+ - qcom,glymur-nsp-noc
+ - qcom,glymur-oobm-ss-noc
+ - qcom,glymur-pcie-east-anoc
+ - qcom,glymur-pcie-east-slv-noc
+ - qcom,glymur-pcie-west-anoc
+ - qcom,glymur-pcie-west-slv-noc
+ - qcom,glymur-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-clk-virt
+ - qcom,glymur-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-pcie-west-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre PCIE_3A WEST AXI clock
+ - description: aggre PCIE_3B WEST AXI clock
+ - description: aggre PCIE_4 WEST AXI clock
+ - description: aggre PCIE_6 WEST AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-pcie-east-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre PCIE_5 EAST AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre USB3 TERT AXI clock
+ - description: aggre USB4_2 AXI clock
+ - description: aggre UFS PHY AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-aggre4-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre USB3 PRIM AXI clock
+ - description: aggre USB3 SEC AXI clock
+ - description: aggre USB4_0 AXI clock
+ - description: aggre USB4_1 AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-pcie-west-anoc
+ - qcom,glymur-pcie-east-anoc
+ - qcom,glymur-aggre2-noc
+ - qcom,glymur-aggre4-noc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,glymur-gcc.h>
+ clk_virt: interconnect-0 {
+ compatible = "qcom,glymur-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e0000 {
+ compatible = "qcom,glymur-aggre1-noc";
+ reg = <0x016e0000 0x14400>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre4_noc: interconnect@1740000 {
+ compatible = "qcom,glymur-aggre4-noc";
+ reg = <0x01740000 0x14400>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB3_SEC_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB4_0_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB4_1_AXI_CLK>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,kaanapali-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,kaanapali-rpmh.yaml
new file mode 100644
index 000000000000..2c3b2fd81a74
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,kaanapali-rpmh.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,kaanapali-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on Kaanapali
+
+maintainers:
+ - Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,kaanapali-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,kaanapali-aggre-noc
+ - qcom,kaanapali-clk-virt
+ - qcom,kaanapali-cnoc-main
+ - qcom,kaanapali-cnoc-cfg
+ - qcom,kaanapali-gem-noc
+ - qcom,kaanapali-lpass-ag-noc
+ - qcom,kaanapali-lpass-lpiaon-noc
+ - qcom,kaanapali-lpass-lpicx-noc
+ - qcom,kaanapali-mc-virt
+ - qcom,kaanapali-mmss-noc
+ - qcom,kaanapali-nsp-noc
+ - qcom,kaanapali-pcie-anoc
+ - qcom,kaanapali-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kaanapali-clk-virt
+ - qcom,kaanapali-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kaanapali-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kaanapali-aggre-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kaanapali-aggre-noc
+ - qcom,kaanapali-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clk_virt: interconnect-0 {
+ compatible = "qcom,kaanapali-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre_noc: interconnect@16e0000 {
+ compatible = "qcom,kaanapali-aggre-noc";
+ reg = <0x016e0000 0x42400>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc_aggre_ufs_phy_axi_clk>,
+ <&gcc_aggre_usb3_prim_axi_clk>,
+ <&rpmhcc_ipa_clk>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,milos-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,milos-rpmh.yaml
new file mode 100644
index 000000000000..00b7a4108d45
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,milos-rpmh.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,milos-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on Milos SoC
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,milos-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,milos-aggre1-noc
+ - qcom,milos-aggre2-noc
+ - qcom,milos-clk-virt
+ - qcom,milos-cnoc-cfg
+ - qcom,milos-cnoc-main
+ - qcom,milos-gem-noc
+ - qcom,milos-lpass-ag-noc
+ - qcom,milos-mc-virt
+ - qcom,milos-mmss-noc
+ - qcom,milos-nsp-noc
+ - qcom,milos-pcie-anoc
+ - qcom,milos-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-clk-virt
+ - qcom,milos-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre USB3 PRIM AXI clock
+ - description: aggre UFS PHY AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-aggre1-noc
+ - qcom,milos-aggre2-noc
+ - qcom,milos-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,milos-gcc.h>
+
+ interconnect-0 {
+ compatible = "qcom,milos-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ interconnect@16e0000 {
+ compatible = "qcom,milos-aggre1-noc";
+ reg = <0x016e0000 0x16400>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml
new file mode 100644
index 000000000000..534644cccdcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,msm8939.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8937/MSM8939/MSM8976 Network-On-Chip interconnect
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The Qualcomm MSM8937/MSM8939/MSM8976 interconnect providers support
+ adjusting the bandwidth requirements between the various NoC fabrics.
+
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8937-bimc
+ - qcom,msm8937-pcnoc
+ - qcom,msm8937-snoc
+ - qcom,msm8939-bimc
+ - qcom,msm8939-pcnoc
+ - qcom,msm8939-snoc
+ - qcom,msm8976-bimc
+ - qcom,msm8976-pcnoc
+ - qcom,msm8976-snoc
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '^interconnect-[a-z0-9\-]+$':
+ type: object
+ $ref: qcom,rpm-common.yaml#
+ description:
+ The interconnect providers do not have a separate QoS register space,
+ but share parent's space.
+
+ allOf:
+ - $ref: qcom,rpm-common.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - qcom,msm8937-snoc-mm
+ - qcom,msm8939-snoc-mm
+ - qcom,msm8976-snoc-mm
+
+ required:
+ - compatible
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ snoc: interconnect@580000 {
+ compatible = "qcom,msm8939-snoc";
+ reg = <0x00580000 0x14000>;
+ #interconnect-cells = <1>;
+
+ snoc_mm: interconnect-snoc {
+ compatible = "qcom,msm8939-snoc-mm";
+ #interconnect-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml
new file mode 100644
index 000000000000..56cdb77b369a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8953.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,msm8953.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8953 Network-On-Chip interconnect
+
+maintainers:
+ - Barnabas Czeman <barnabas.czeman@mainlining.org>
+
+description: |
+ The Qualcomm MSM8953 interconnect providers support adjusting the
+ bandwidth requirements between the various NoC fabrics.
+
+ See also: include/dt-bindings/interconnect/qcom,msm8953.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8953-bimc
+ - qcom,msm8953-pcnoc
+ - qcom,msm8953-snoc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ '#interconnect-cells':
+ const: 2
+
+patternProperties:
+ '^interconnect-[a-z0-9\-]+$':
+ type: object
+ $ref: qcom,rpm-common.yaml#
+ unevaluatedProperties: false
+ description:
+ The interconnect providers do not have a separate QoS register space,
+ but share parent's space.
+
+ properties:
+ compatible:
+ const: qcom,msm8953-snoc-mm
+
+ required:
+ - compatible
+ - '#interconnect-cells'
+
+required:
+ - compatible
+ - reg
+ - '#interconnect-cells'
+
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8953-pcnoc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: PCNOC USB3 AXI Clock.
+
+ clock-names:
+ const: pcnoc_usb3_axi
+
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8953.h>
+
+ interconnect@580000 {
+ compatible = "qcom,msm8953-snoc";
+ reg = <0x580000 0x16080>;
+
+ #interconnect-cells = <2>;
+
+ interconnect-snoc {
+ compatible = "qcom,msm8953-snoc-mm";
+
+ #interconnect-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
index 8004c4baf397..95ce25ce1f7d 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
@@ -50,13 +50,13 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,rpmcc.h>
-
- bimc: interconnect@fc380000 {
- reg = <0xfc380000 0x6a000>;
- compatible = "qcom,msm8974-bimc";
- #interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
- <&rpmcc RPM_SMD_BIMC_A_CLK>;
- };
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ interconnect@fc380000 {
+ reg = <0xfc380000 0x6a000>;
+ compatible = "qcom,msm8974-bimc";
+ #interconnect-cells = <1>;
+ clock-names = "bus", "bus_a";
+ clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
+ <&rpmcc RPM_SMD_BIMC_A_CLK>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml
new file mode 100644
index 000000000000..e3f964aaad1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,msm8996.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8996 Network-On-Chip interconnect
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ The Qualcomm MSM8996 interconnect providers support adjusting the
+ bandwidth requirements between the various NoC fabrics.
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8996-a0noc
+ - qcom,msm8996-a1noc
+ - qcom,msm8996-a2noc
+ - qcom,msm8996-bimc
+ - qcom,msm8996-cnoc
+ - qcom,msm8996-mnoc
+ - qcom,msm8996-pnoc
+ - qcom,msm8996-snoc
+
+ reg:
+ maxItems: 1
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8996-a0noc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Aggregate0 System NoC AXI Clock.
+ - description: Aggregate0 Config NoC AHB Clock.
+ - description: Aggregate0 NoC MPU Clock.
+
+ clock-names:
+ items:
+ - const: aggre0_snoc_axi
+ - const: aggre0_cnoc_ahb
+ - const: aggre0_noc_mpu_cfg
+
+ required:
+ - power-domains
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8996-mnoc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: CPU-NoC High-performance Bus Clock.
+
+ clock-names:
+ const: iface
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8996-a2noc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Aggregate2 NoC UFS AXI Clock
+ - description: UFS AXI Clock
+
+ clock-names:
+ items:
+ - const: aggre2_ufs_axi
+ - const: ufs_axi
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8996.h>
+ #include <dt-bindings/clock/qcom,mmcc-msm8996.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ bimc: interconnect@408000 {
+ compatible = "qcom,msm8996-bimc";
+ reg = <0x00408000 0x5a000>;
+ #interconnect-cells = <1>;
+ };
+
+ a0noc: interconnect@543000 {
+ compatible = "qcom,msm8996-a0noc";
+ reg = <0x00543000 0x6000>;
+ #interconnect-cells = <1>;
+ clocks = <&gcc GCC_AGGRE0_SNOC_AXI_CLK>,
+ <&gcc GCC_AGGRE0_CNOC_AHB_CLK>,
+ <&gcc GCC_AGGRE0_NOC_MPU_CFG_AHB_CLK>;
+ clock-names = "aggre0_snoc_axi",
+ "aggre0_cnoc_ahb",
+ "aggre0_noc_mpu_cfg";
+ power-domains = <&gcc AGGRE0_NOC_GDSC>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
index 0ac5256876a8..17b09292000e 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Interconnect Bandwidth Monitor
maintainers:
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description: |
Bandwidth Monitor measures current throughput on buses between various NoC
@@ -22,12 +22,39 @@ description: |
properties:
compatible:
oneOf:
+ - const: qcom,msm8998-bwmon # BWMON v4
- items:
- enum:
- - qcom,sc7280-bwmon
- - qcom,sdm845-bwmon
- - const: qcom,msm8998-bwmon
- - const: qcom,msm8998-bwmon # BWMON v4
+ - qcom,kaanapali-cpu-bwmon
+ - qcom,qcm2290-cpu-bwmon
+ - qcom,qcs615-cpu-bwmon
+ - qcom,qcs8300-cpu-bwmon
+ - qcom,sa8775p-cpu-bwmon
+ - qcom,sc7180-cpu-bwmon
+ - qcom,sc7280-cpu-bwmon
+ - qcom,sc8280xp-cpu-bwmon
+ - qcom,sdm845-cpu-bwmon
+ - qcom,sm6115-cpu-bwmon
+ - qcom,sm6350-llcc-bwmon
+ - qcom,sm8250-cpu-bwmon
+ - qcom,sm8550-cpu-bwmon
+ - qcom,sm8650-cpu-bwmon
+ - qcom,sm8750-cpu-bwmon
+ - qcom,x1e80100-cpu-bwmon
+ - const: qcom,sdm845-bwmon # BWMON v4, unified register space
+ - items:
+ - enum:
+ - qcom,qcs615-llcc-bwmon
+ - qcom,qcs8300-llcc-bwmon
+ - qcom,sa8775p-llcc-bwmon
+ - qcom,sc7180-llcc-bwmon
+ - qcom,sc8280xp-llcc-bwmon
+ - qcom,sm6350-cpu-bwmon
+ - qcom,sm8250-llcc-bwmon
+ - qcom,sm8550-llcc-bwmon
+ - qcom,sm8650-llcc-bwmon
+ - qcom,x1e80100-llcc-bwmon
+ - const: qcom,sc7280-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon # BWMON v5
- const: qcom,sdm845-llcc-bwmon # BWMON v5
@@ -38,30 +65,59 @@ properties:
maxItems: 1
operating-points-v2: true
- opp-table: true
+ opp-table:
+ type: object
reg:
- # BWMON v4 (currently described) and BWMON v5 use one register address
- # space. BWMON v2 uses two register spaces - not yet described.
- maxItems: 1
+ # BWMON v5 uses one register address space, v1-v4 use one or two.
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
+
+ nonposted-mmio: true
required:
- compatible
- interconnects
- interrupts
- operating-points-v2
- - opp-table
- reg
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8998-bwmon
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: monitor
+ - const: global
+
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ reg-names:
+ maxItems: 1
+
examples:
- |
#include <dt-bindings/interconnect/qcom,sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pmu@1436400 {
- compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
+ compatible = "qcom,sdm845-cpu-bwmon", "qcom,sdm845-bwmon";
reg = <0x01436400 0x600>;
interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>;
interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_LLCC 3>;
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
index bf538c0c5a81..4b9b98fbe8f2 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
@@ -16,13 +16,36 @@ description:
properties:
compatible:
- enum:
- - qcom,sc7180-osm-l3
- - qcom,sc7280-epss-l3
- - qcom,sc8180x-osm-l3
- - qcom,sdm845-osm-l3
- - qcom,sm8150-osm-l3
- - qcom,sm8250-epss-l3
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sc7180-osm-l3
+ - qcom,sc8180x-osm-l3
+ - qcom,sdm670-osm-l3
+ - qcom,sdm845-osm-l3
+ - qcom,sm6350-osm-l3
+ - qcom,sm8150-osm-l3
+ - const: qcom,osm-l3
+ - items:
+ - enum:
+ - qcom,sa8775p-epss-l3
+ - qcom,sc7280-epss-l3
+ - qcom,sc8280xp-epss-l3
+ - qcom,sm6375-cpucp-l3
+ - qcom,sm8250-epss-l3
+ - qcom,sm8350-epss-l3
+ - qcom,sm8650-epss-l3
+ - const: qcom,epss-l3
+ - items:
+ - enum:
+ - qcom,qcs8300-epss-l3
+ - const: qcom,sa8775p-epss-l3
+ - const: qcom,epss-l3
+ - items:
+ - enum:
+ - qcom,qcs615-osm-l3
+ - const: qcom,sm8150-osm-l3
+ - const: qcom,osm-l3
reg:
maxItems: 1
@@ -56,7 +79,7 @@ examples:
#define RPMH_CXO_CLK 0
osm_l3: interconnect@17d41000 {
- compatible = "qcom,sdm845-osm-l3";
+ compatible = "qcom,sdm845-osm-l3", "qcom,osm-l3";
reg = <0x17d41000 0x1400>;
clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
index f65a2fe846de..b6c15314c5c5 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
@@ -13,6 +13,9 @@ description: |
The Qualcomm QCM2290 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+
properties:
reg:
maxItems: 1
@@ -23,19 +26,6 @@ properties:
- qcom,qcm2290-cnoc
- qcom,qcm2290-snoc
- '#interconnect-cells':
- const: 1
-
- clock-names:
- items:
- - const: bus
- - const: bus_a
-
- clocks:
- items:
- - description: Bus Clock
- - description: Bus A Clock
-
# Child node's properties
patternProperties:
'^interconnect-[a-z0-9]+$':
@@ -44,6 +34,9 @@ patternProperties:
The interconnect providers do not have a separate QoS register space,
but share parent's space.
+ allOf:
+ - $ref: qcom,rpm-common.yaml#
+
properties:
compatible:
enum:
@@ -51,35 +44,16 @@ patternProperties:
- qcom,qcm2290-mmrt-virt
- qcom,qcm2290-mmnrt-virt
- '#interconnect-cells':
- const: 1
-
- clock-names:
- items:
- - const: bus
- - const: bus_a
-
- clocks:
- items:
- - description: Bus Clock
- - description: Bus A Clock
-
required:
- compatible
- - '#interconnect-cells'
- - clock-names
- - clocks
- additionalProperties: false
+ unevaluatedProperties: false
required:
- compatible
- reg
- - '#interconnect-cells'
- - clock-names
- - clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -89,32 +63,20 @@ examples:
compatible = "qcom,qcm2290-snoc";
reg = <0x01880000 0x60200>;
#interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
- <&rpmcc RPM_SMD_SNOC_A_CLK>;
qup_virt: interconnect-qup {
compatible = "qcom,qcm2290-qup-virt";
#interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_QUP_CLK>,
- <&rpmcc RPM_SMD_QUP_A_CLK>;
};
mmnrt_virt: interconnect-mmnrt {
compatible = "qcom,qcm2290-mmnrt-virt";
#interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_MMNRT_CLK>,
- <&rpmcc RPM_SMD_MMNRT_A_CLK>;
};
mmrt_virt: interconnect-mmrt {
compatible = "qcom,qcm2290-mmrt-virt";
#interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_MMRT_CLK>,
- <&rpmcc RPM_SMD_MMRT_A_CLK>;
};
};
@@ -122,16 +84,10 @@ examples:
compatible = "qcom,qcm2290-cnoc";
reg = <0x01900000 0x8200>;
#interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_CNOC_CLK>,
- <&rpmcc RPM_SMD_CNOC_A_CLK>;
};
bimc: interconnect@4480000 {
compatible = "qcom,qcm2290-bimc";
reg = <0x04480000 0x80000>;
#interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
- <&rpmcc RPM_SMD_BIMC_A_CLK>;
};
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs615-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcs615-rpmh.yaml
new file mode 100644
index 000000000000..9d762b2a1fcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs615-rpmh.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,qcs615-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on QCS615
+
+maintainers:
+ - Raviteja Laggyshetty <quic_rlaggysh@quicinc.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,qcs615-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs615-aggre1-noc
+ - qcom,qcs615-camnoc-virt
+ - qcom,qcs615-config-noc
+ - qcom,qcs615-dc-noc
+ - qcom,qcs615-gem-noc
+ - qcom,qcs615-ipa-virt
+ - qcom,qcs615-mc-virt
+ - qcom,qcs615-mmss-noc
+ - qcom,qcs615-system-noc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs615-camnoc-virt
+ - qcom,qcs615-ipa-virt
+ - qcom,qcs615-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gem_noc: interconnect@9680000 {
+ compatible = "qcom,qcs615-gem-noc";
+ reg = <0x9680000 0x3e200>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ mc_virt: interconnect-2 {
+ compatible = "qcom,qcs615-mc-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
new file mode 100644
index 000000000000..e9f528d6d9a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,qcs8300-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on QCS8300
+
+maintainers:
+ - Raviteja Laggyshetty <quic_rlaggysh@quicinc.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also: include/dt-bindings/interconnect/qcom,qcs8300-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs8300-aggre1-noc
+ - qcom,qcs8300-aggre2-noc
+ - qcom,qcs8300-clk-virt
+ - qcom,qcs8300-config-noc
+ - qcom,qcs8300-dc-noc
+ - qcom,qcs8300-gem-noc
+ - qcom,qcs8300-gpdsp-anoc
+ - qcom,qcs8300-lpass-ag-noc
+ - qcom,qcs8300-mc-virt
+ - qcom,qcs8300-mmss-noc
+ - qcom,qcs8300-nspa-noc
+ - qcom,qcs8300-pcie-anoc
+ - qcom,qcs8300-system-noc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-clk-virt
+ - qcom,qcs8300-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gem_noc: interconnect@9100000 {
+ compatible = "qcom,qcs8300-gem-noc";
+ reg = <0x9100000 0xf7080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ clk_virt: interconnect-0 {
+ compatible = "qcom,qcs8300-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml
new file mode 100644
index 000000000000..0070b0396e31
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,qdu1000-rpmh.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,qdu1000-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on QDU1000
+
+maintainers:
+ - Georgi Djakov <djakov@kernel.org>
+ - Odelu Kukatla <quic_okukatla@quicinc.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+properties:
+ compatible:
+ enum:
+ - qcom,qdu1000-clk-virt
+ - qcom,qdu1000-gem-noc
+ - qcom,qdu1000-mc-virt
+ - qcom,qdu1000-system-noc
+
+ '#interconnect-cells': true
+
+ reg:
+ maxItems: 1
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qdu1000-clk-virt
+ - qcom,qdu1000-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/qcom,qdu1000-rpmh.h>
+
+ system_noc: interconnect@1640000 {
+ compatible = "qcom,qdu1000-system-noc";
+ reg = <0x1640000 0x45080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ clk_virt: interconnect-0 {
+ compatible = "qcom,qdu1000-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml
new file mode 100644
index 000000000000..1ea52b091609
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,rpm-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ RPM interconnect providers support for managing system bandwidth requirements
+ through manual requests based on either predefined values or as indicated by
+ the bus monitor hardware. Each provider node represents a NoC bus master,
+ driven by a dedicated clock source.
+
+properties:
+ '#interconnect-cells':
+ oneOf:
+ - const: 2
+ - const: 1
+ deprecated: true
+
+required:
+ - '#interconnect-cells'
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
index 4b37aa88a375..01d436d4a553 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
@@ -7,241 +7,44 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPM Network-On-Chip Interconnect
maintainers:
- - Georgi Djakov <georgi.djakov@linaro.org>
+ - Georgi Djakov <djakov@kernel.org>
description: |
RPM interconnect providers support system bandwidth requirements through
RPM processor. The provider is able to communicate with the RPM through
the RPM shared memory device.
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+
properties:
reg:
maxItems: 1
compatible:
enum:
+ - qcom,msm8909-bimc
+ - qcom,msm8909-pcnoc
+ - qcom,msm8909-snoc
- qcom,msm8916-bimc
- qcom,msm8916-pcnoc
- qcom,msm8916-snoc
- - qcom,msm8939-bimc
- - qcom,msm8939-pcnoc
- - qcom,msm8939-snoc
- - qcom,msm8996-a0noc
- - qcom,msm8996-a1noc
- - qcom,msm8996-a2noc
- - qcom,msm8996-bimc
- - qcom,msm8996-cnoc
- - qcom,msm8996-mnoc
- - qcom,msm8996-pnoc
- - qcom,msm8996-snoc
- qcom,qcs404-bimc
- qcom,qcs404-pcnoc
- qcom,qcs404-snoc
- - qcom,sdm660-a2noc
- - qcom,sdm660-bimc
- - qcom,sdm660-cnoc
- - qcom,sdm660-gnoc
- - qcom,sdm660-mnoc
- - qcom,sdm660-snoc
-
- '#interconnect-cells':
- description: |
- Value: <1> is one cell in an interconnect specifier for the
- interconnect node id, <2> requires the interconnect node id and an
- extra path tag.
- enum: [ 1, 2 ]
-
- clocks:
- minItems: 2
- maxItems: 7
-
- clock-names:
- minItems: 2
- maxItems: 7
-
- power-domains:
- maxItems: 1
required:
- compatible
- reg
- - '#interconnect-cells'
- - clock-names
- - clocks
-
-additionalProperties: false
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8916-bimc
- - qcom,msm8916-pcnoc
- - qcom,msm8916-snoc
- - qcom,msm8939-bimc
- - qcom,msm8939-pcnoc
- - qcom,msm8939-snoc
- - qcom,msm8996-a1noc
- - qcom,msm8996-a2noc
- - qcom,msm8996-bimc
- - qcom,msm8996-cnoc
- - qcom,msm8996-pnoc
- - qcom,msm8996-snoc
- - qcom,qcs404-bimc
- - qcom,qcs404-pcnoc
- - qcom,qcs404-snoc
- - qcom,sdm660-bimc
- - qcom,sdm660-cnoc
- - qcom,sdm660-gnoc
- - qcom,sdm660-snoc
-
- then:
- properties:
- clock-names:
- items:
- - const: bus
- - const: bus_a
-
- clocks:
- items:
- - description: Bus Clock
- - description: Bus A Clock
-
- # Child node's properties
- patternProperties:
- '^interconnect-[a-z0-9]+$':
- type: object
- description:
- snoc-mm is a child of snoc, sharing snoc's register address space.
-
- properties:
- compatible:
- enum:
- - qcom,msm8939-snoc-mm
-
- '#interconnect-cells':
- const: 1
- clock-names:
- items:
- - const: bus
- - const: bus_a
-
- clocks:
- items:
- - description: Bus Clock
- - description: Bus A Clock
-
- required:
- - compatible
- - '#interconnect-cells'
- - clock-names
- - clocks
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8996-mnoc
- - qcom,sdm660-mnoc
-
- then:
- properties:
- clock-names:
- items:
- - const: bus
- - const: bus_a
- - const: iface
-
- clocks:
- items:
- - description: Bus Clock.
- - description: Bus A Clock.
- - description: CPU-NoC High-performance Bus Clock.
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8996-a0noc
-
- then:
- properties:
- clock-names:
- items:
- - const: aggre0_snoc_axi
- - const: aggre0_cnoc_ahb
- - const: aggre0_noc_mpu_cfg
-
- clocks:
- items:
- - description: Aggregate0 System NoC AXI Clock.
- - description: Aggregate0 Config NoC AHB Clock.
- - description: Aggregate0 NoC MPU Clock.
-
- required:
- - power-domains
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sdm660-a2noc
-
- then:
- properties:
- clock-names:
- items:
- - const: bus
- - const: bus_a
- - const: ipa
- - const: ufs_axi
- - const: aggre2_ufs_axi
- - const: aggre2_usb3_axi
- - const: cfg_noc_usb2_axi
-
- clocks:
- items:
- - description: Bus Clock.
- - description: Bus A Clock.
- - description: IPA Clock.
- - description: UFS AXI Clock.
- - description: Aggregate2 UFS AXI Clock.
- - description: Aggregate2 USB3 AXI Clock.
- - description: Config NoC USB2 AXI Clock.
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,rpmcc.h>
-
- bimc: interconnect@400000 {
- compatible = "qcom,msm8916-bimc";
- reg = <0x00400000 0x62000>;
- #interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
- <&rpmcc RPM_SMD_BIMC_A_CLK>;
- };
-
- pcnoc: interconnect@500000 {
- compatible = "qcom,msm8916-pcnoc";
- reg = <0x00500000 0x11000>;
- #interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_PCNOC_CLK>,
- <&rpmcc RPM_SMD_PCNOC_A_CLK>;
- };
+ #include <dt-bindings/clock/qcom,rpmcc.h>
- snoc: interconnect@580000 {
- compatible = "qcom,msm8916-snoc";
- reg = <0x00580000 0x14000>;
- #interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
- <&rpmcc RPM_SMD_SNOC_A_CLK>;
- };
+ interconnect@400000 {
+ compatible = "qcom,msm8916-bimc";
+ reg = <0x00400000 0x62000>;
+ #interconnect-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
index a429a1ed1006..da16d8e9bdc5 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
@@ -8,7 +8,7 @@ title: Qualcomm RPMh Network-On-Chip Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
- - Odelu Kukatla <okukatla@codeaurora.org>
+ - Odelu Kukatla <quic_okukatla@quicinc.com>
description: |
RPMh interconnect providers support system bandwidth requirements through
@@ -18,9 +18,6 @@ description: |
least one RPMh device child node pertaining to their RSC and each provider
can map to multiple RPMh resources.
-allOf:
- - $ref: qcom,rpmh-common.yaml#
-
properties:
reg:
maxItems: 1
@@ -39,18 +36,6 @@ properties:
- qcom,sc7180-npu-noc
- qcom,sc7180-qup-virt
- qcom,sc7180-system-noc
- - qcom,sc7280-aggre1-noc
- - qcom,sc7280-aggre2-noc
- - qcom,sc7280-clk-virt
- - qcom,sc7280-cnoc2
- - qcom,sc7280-cnoc3
- - qcom,sc7280-dc-noc
- - qcom,sc7280-gem-noc
- - qcom,sc7280-lpass-ag-noc
- - qcom,sc7280-mc-virt
- - qcom,sc7280-mmss-noc
- - qcom,sc7280-nsp-noc
- - qcom,sc7280-system-noc
- qcom,sc8180x-aggre1-noc
- qcom,sc8180x-aggre2-noc
- qcom,sc8180x-camnoc-virt
@@ -58,23 +43,18 @@ properties:
- qcom,sc8180x-config-noc
- qcom,sc8180x-dc-noc
- qcom,sc8180x-gem-noc
- - qcom,sc8180x-ipa-virt
- qcom,sc8180x-mc-virt
- qcom,sc8180x-mmss-noc
- qcom,sc8180x-qup-virt
- qcom,sc8180x-system-noc
- - qcom,sc8280xp-aggre1-noc
- - qcom,sc8280xp-aggre2-noc
- - qcom,sc8280xp-clk-virt
- - qcom,sc8280xp-config-noc
- - qcom,sc8280xp-dc-noc
- - qcom,sc8280xp-gem-noc
- - qcom,sc8280xp-lpass-ag-noc
- - qcom,sc8280xp-mc-virt
- - qcom,sc8280xp-mmss-noc
- - qcom,sc8280xp-nspa-noc
- - qcom,sc8280xp-nspb-noc
- - qcom,sc8280xp-system-noc
+ - qcom,sdm670-aggre1-noc
+ - qcom,sdm670-aggre2-noc
+ - qcom,sdm670-config-noc
+ - qcom,sdm670-dc-noc
+ - qcom,sdm670-gladiator-noc
+ - qcom,sdm670-mem-noc
+ - qcom,sdm670-mmss-noc
+ - qcom,sdm670-system-noc
- qcom,sdm845-aggre1-noc
- qcom,sdm845-aggre2-noc
- qcom,sdm845-config-noc
@@ -91,12 +71,11 @@ properties:
- qcom,sdx65-system-noc
- qcom,sm8150-aggre1-noc
- qcom,sm8150-aggre2-noc
- - qcom,sm8150-camnoc-noc
+ - qcom,sm8150-camnoc-virt
- qcom,sm8150-compute-noc
- qcom,sm8150-config-noc
- qcom,sm8150-dc-noc
- qcom,sm8150-gem-noc
- - qcom,sm8150-ipa-virt
- qcom,sm8150-mc-virt
- qcom,sm8150-mmss-noc
- qcom,sm8150-system-noc
@@ -106,10 +85,10 @@ properties:
- qcom,sm8250-config-noc
- qcom,sm8250-dc-noc
- qcom,sm8250-gem-noc
- - qcom,sm8250-ipa-virt
- qcom,sm8250-mc-virt
- qcom,sm8250-mmss-noc
- qcom,sm8250-npu-noc
+ - qcom,sm8250-qup-virt
- qcom,sm8250-system-noc
- qcom,sm8350-aggre1-noc
- qcom,sm8350-aggre2-noc
@@ -121,41 +100,45 @@ properties:
- qcom,sm8350-mmss-noc
- qcom,sm8350-compute-noc
- qcom,sm8350-system-noc
- - qcom,sm8450-aggre1-noc
- - qcom,sm8450-aggre2-noc
- - qcom,sm8450-clk-virt
- - qcom,sm8450-config-noc
- - qcom,sm8450-gem-noc
- - qcom,sm8450-lpass-ag-noc
- - qcom,sm8450-mc-virt
- - qcom,sm8450-mmss-noc
- - qcom,sm8450-nsp-noc
- - qcom,sm8450-pcie-anoc
- - qcom,sm8450-system-noc
'#interconnect-cells': true
required:
- compatible
- - reg
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-camnoc-virt
+ - qcom,sc8180x-mc-virt
+ - qcom,sc8180x-qup-virt
+ - qcom,sdx65-mc-virt
+ - qcom,sm8250-qup-virt
+ then:
+ required:
+ - reg
unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interconnect/qcom,sdm845.h>
+ #include <dt-bindings/interconnect/qcom,sdm845.h>
- mem_noc: interconnect@1380000 {
- compatible = "qcom,sdm845-mem-noc";
- reg = <0x01380000 0x27200>;
- #interconnect-cells = <1>;
- qcom,bcm-voters = <&apps_bcm_voter>;
- };
+ interconnect@1380000 {
+ compatible = "qcom,sdm845-mem-noc";
+ reg = <0x01380000 0x27200>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
- mmss_noc: interconnect@1740000 {
- compatible = "qcom,sdm845-mmss-noc";
- reg = <0x01740000 0x1c1000>;
- #interconnect-cells = <1>;
- qcom,bcm-voter-names = "apps", "disp";
- qcom,bcm-voters = <&apps_bcm_voter>, <&disp_bcm_voter>;
- };
+ interconnect@1740000 {
+ compatible = "qcom,sdm845-mmss-noc";
+ reg = <0x01740000 0x1c1000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voter-names = "apps", "disp";
+ qcom,bcm-voters = <&apps_bcm_voter>, <&disp_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml
new file mode 100644
index 000000000000..71428d2cce18
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sa8775p-rpmh.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sa8775p-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SA8775P
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also: include/dt-bindings/interconnect/qcom,sa8775p.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sa8775p-aggre1-noc
+ - qcom,sa8775p-aggre2-noc
+ - qcom,sa8775p-clk-virt
+ - qcom,sa8775p-config-noc
+ - qcom,sa8775p-dc-noc
+ - qcom,sa8775p-gem-noc
+ - qcom,sa8775p-gpdsp-anoc
+ - qcom,sa8775p-lpass-ag-noc
+ - qcom,sa8775p-mc-virt
+ - qcom,sa8775p-mmss-noc
+ - qcom,sa8775p-nspa-noc
+ - qcom,sa8775p-nspb-noc
+ - qcom,sa8775p-pcie-anoc
+ - qcom,sa8775p-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 5
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre QUP PRIM AXI clock
+ - description: aggre USB2 PRIM AXI clock
+ - description: aggre USB3 PRIM AXI clock
+ - description: aggre USB3 SEC AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS CARD AXI clock
+ - description: RPMH CC IPA clock
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ clk_virt: interconnect-clk-virt {
+ compatible = "qcom,sa8775p-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16c0000 {
+ compatible = "qcom,sa8775p-aggre1-noc";
+ reg = <0x016c0000 0x18080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_QUPV3_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB2_PRIM_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB3_SEC_AXI_CLK>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sar2130p-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sar2130p-rpmh.yaml
new file mode 100644
index 000000000000..f5d3d0c5df73
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sar2130p-rpmh.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sar2130p-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SAR2130P
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+ - Georgi Djakov <djakov@kernel.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,sar2130p-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sar2130p-clk-virt
+ - qcom,sar2130p-config-noc
+ - qcom,sar2130p-gem-noc
+ - qcom,sar2130p-lpass-ag-noc
+ - qcom,sar2130p-mc-virt
+ - qcom,sar2130p-mmss-noc
+ - qcom,sar2130p-nsp-noc
+ - qcom,sar2130p-pcie-anoc
+ - qcom,sar2130p-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-clk-virt
+ - qcom,sar2130p-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-system-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-system-noc
+ - qcom,sar2130p-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clk_virt: interconnect-0 {
+ compatible = "qcom,sar2130p-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@1680000 {
+ compatible = "qcom,sar2130p-system-noc";
+ reg = <0x01680000 0x29080>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc_prim_axi_clk>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
new file mode 100644
index 000000000000..81c3dff53992
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sc7280-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SC7280
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also: include/dt-bindings/interconnect/qcom,sc7280.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7280-aggre1-noc
+ - qcom,sc7280-aggre2-noc
+ - qcom,sc7280-clk-virt
+ - qcom,sc7280-cnoc2
+ - qcom,sc7280-cnoc3
+ - qcom,sc7280-dc-noc
+ - qcom,sc7280-gem-noc
+ - qcom,sc7280-lpass-ag-noc
+ - qcom,sc7280-mc-virt
+ - qcom,sc7280-mmss-noc
+ - qcom,sc7280-nsp-noc
+ - qcom,sc7280-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-clk-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-aggre1-noc
+ - qcom,sc7280-aggre2-noc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ interconnect {
+ compatible = "qcom,sc7280-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ interconnect@9100000 {
+ reg = <0x9100000 0xe2200>;
+ compatible = "qcom,sc7280-gem-noc";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ interconnect@16e0000 {
+ reg = <0x016e0000 0x1c080>;
+ compatible = "qcom,sc7280-aggre1-noc";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml
new file mode 100644
index 000000000000..2a5a7594bafd
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sc8280xp-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SC8280XP
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also: include/dt-bindings/interconnect/qcom,sc8280xp.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-aggre1-noc
+ - qcom,sc8280xp-aggre2-noc
+ - qcom,sc8280xp-clk-virt
+ - qcom,sc8280xp-config-noc
+ - qcom,sc8280xp-dc-noc
+ - qcom,sc8280xp-gem-noc
+ - qcom,sc8280xp-lpass-ag-noc
+ - qcom,sc8280xp-mc-virt
+ - qcom,sc8280xp-mmss-noc
+ - qcom,sc8280xp-nspa-noc
+ - qcom,sc8280xp-nspb-noc
+ - qcom,sc8280xp-system-noc
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interconnect-0 {
+ compatible = "qcom,sc8280xp-aggre1-noc";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
new file mode 100644
index 000000000000..8f6bc6399626
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sdm660.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM660 Network-On-Chip interconnect
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ The Qualcomm SDM660 interconnect providers support adjusting the
+ bandwidth requirements between the various NoC fabrics.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdm660-a2noc
+ - qcom,sdm660-bimc
+ - qcom,sdm660-cnoc
+ - qcom,sdm660-gnoc
+ - qcom,sdm660-mnoc
+ - qcom,sdm660-snoc
+
+ reg:
+ maxItems: 1
+
+ clock-names:
+ minItems: 1
+ maxItems: 5
+
+ clocks:
+ minItems: 1
+ maxItems: 5
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+ - if:
+ properties:
+ compatible:
+ const: qcom,sdm660-mnoc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: CPU-NoC High-performance Bus Clock.
+
+ clock-names:
+ const: iface
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,sdm660-a2noc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: IPA Clock.
+ - description: UFS AXI Clock.
+ - description: Aggregate2 UFS AXI Clock.
+ - description: Aggregate2 USB3 AXI Clock.
+ - description: Config NoC USB2 AXI Clock.
+
+ clock-names:
+ items:
+ - const: ipa
+ - const: ufs_axi
+ - const: aggre2_ufs_axi
+ - const: aggre2_usb3_axi
+ - const: cfg_noc_usb2_axi
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm660.h>
+ #include <dt-bindings/clock/qcom,mmcc-sdm660.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ bimc: interconnect@1008000 {
+ compatible = "qcom,sdm660-bimc";
+ reg = <0x01008000 0x78000>;
+ #interconnect-cells = <1>;
+ };
+
+ a2noc: interconnect@1704000 {
+ compatible = "qcom,sdm660-a2noc";
+ reg = <0x01704000 0xc100>;
+ #interconnect-cells = <1>;
+ clocks = <&rpmcc RPM_SMD_IPA_CLK>,
+ <&gcc GCC_UFS_AXI_CLK>,
+ <&gcc GCC_AGGRE2_UFS_AXI_CLK>,
+ <&gcc GCC_AGGRE2_USB3_AXI_CLK>,
+ <&gcc GCC_CFG_NOC_USB2_AXI_CLK>;
+ clock-names = "ipa",
+ "ufs_axi",
+ "aggre2_ufs_axi",
+ "aggre2_usb3_axi",
+ "cfg_noc_usb2_axi";
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdx75-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sdx75-rpmh.yaml
new file mode 100644
index 000000000000..4b5e9f9b07ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sdx75-rpmh.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sdx75-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SDX75
+
+maintainers:
+ - Rohit Agarwal <quic_rohiagar@quicinc.com>
+
+description:
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdx75-clk-virt
+ - qcom,sdx75-dc-noc
+ - qcom,sdx75-gem-noc
+ - qcom,sdx75-mc-virt
+ - qcom,sdx75-pcie-anoc
+ - qcom,sdx75-system-noc
+
+ '#interconnect-cells': true
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdx75-clk-virt
+ - qcom,sdx75-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdx75-clk-virt
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC QPIC Clock
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ clk_virt: interconnect-0 {
+ compatible = "qcom,sdx75-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&rpmhcc RPMH_QPIC_CLK>;
+ };
+
+ system_noc: interconnect@1640000 {
+ compatible = "qcom,sdx75-system-noc";
+ reg = <0x1640000 0x4b400>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm6115.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm6115.yaml
new file mode 100644
index 000000000000..14b1a0b08e73
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm6115.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm6115.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6115 Network-On-Chip interconnect
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The Qualcomm SM6115 interconnect providers support adjusting the
+ bandwidth requirements between the various NoC fabrics.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6115-bimc
+ - qcom,sm6115-cnoc
+ - qcom,sm6115-snoc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ minItems: 1
+ maxItems: 4
+
+# Child node's properties
+patternProperties:
+ '^interconnect-[a-z0-9]+$':
+ type: object
+ description:
+ The interconnect providers do not have a separate QoS register space,
+ but share parent's space.
+
+ $ref: qcom,rpm-common.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-clk-virt
+ - qcom,sm6115-mmrt-virt
+ - qcom,sm6115-mmnrt-virt
+
+ required:
+ - compatible
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: qcom,rpm-common.yaml#
+ - if:
+ properties:
+ compatible:
+ const: qcom,sm6115-cnoc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: USB-NoC AXI clock
+
+ clock-names:
+ items:
+ - const: usb_axi
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,sm6115-snoc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: CPU-NoC AXI clock.
+ - description: UFS-NoC AXI clock.
+ - description: USB-NoC AXI clock.
+ - description: IPA clock.
+
+ clock-names:
+ items:
+ - const: cpu_axi
+ - const: ufs_axi
+ - const: usb_axi
+ - const: ipa
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-bimc
+ - qcom,sm6115-clk-virt
+ - qcom,sm6115-mmrt-virt
+ - qcom,sm6115-mmnrt-virt
+
+ then:
+ properties:
+ clocks: false
+ clock-names: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm6115.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+
+ snoc: interconnect@1880000 {
+ compatible = "qcom,sm6115-snoc";
+ reg = <0x01880000 0x60200>;
+ clocks = <&gcc GCC_SYS_NOC_CPUSS_AHB_CLK>,
+ <&gcc GCC_SYS_NOC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_SYS_NOC_USB3_PRIM_AXI_CLK>,
+ <&rpmcc RPM_SMD_IPA_CLK>;
+ clock-names = "cpu_axi",
+ "ufs_axi",
+ "usb_axi",
+ "ipa";
+ #interconnect-cells = <1>;
+
+ qup_virt: interconnect-clk {
+ compatible = "qcom,sm6115-clk-virt";
+ #interconnect-cells = <1>;
+ };
+
+ mmnrt_virt: interconnect-mmnrt {
+ compatible = "qcom,sm6115-mmnrt-virt";
+ #interconnect-cells = <1>;
+ };
+
+ mmrt_virt: interconnect-mmrt {
+ compatible = "qcom,sm6115-mmrt-virt";
+ #interconnect-cells = <1>;
+ };
+ };
+
+ cnoc: interconnect@1900000 {
+ compatible = "qcom,sm6115-cnoc";
+ reg = <0x01900000 0x8200>;
+ #interconnect-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml
index 49eb156b08e0..2dc16e4293a9 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm6350-rpmh.yaml
@@ -12,9 +12,6 @@ maintainers:
description:
Qualcomm RPMh-based interconnect provider on SM6350.
-allOf:
- - $ref: qcom,rpmh-common.yaml#
-
properties:
compatible:
enum:
@@ -30,7 +27,9 @@ properties:
reg:
maxItems: 1
- '#interconnect-cells': true
+ clocks:
+ minItems: 1
+ maxItems: 2
patternProperties:
'^interconnect-[a-z0-9\-]+$':
@@ -46,8 +45,6 @@ patternProperties:
- qcom,sm6350-clk-virt
- qcom,sm6350-compute-noc
- '#interconnect-cells': true
-
required:
- compatible
@@ -57,10 +54,54 @@ required:
- compatible
- reg
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6350-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6350-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre USB3 PRIM AXI clock
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6350-aggre1-noc
+ - qcom,sm6350-aggre2-noc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/qcom,gcc-sm6350.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
config_noc: interconnect@1500000 {
compatible = "qcom,sm6350-config-noc";
reg = <0x01500000 0x28000>;
@@ -68,14 +109,16 @@ examples:
qcom,bcm-voters = <&apps_bcm_voter>;
};
- system_noc: interconnect@1620000 {
- compatible = "qcom,sm6350-system-noc";
- reg = <0x01620000 0x17080>;
+ aggre2_noc: interconnect@1700000 {
+ compatible = "qcom,sm6350-aggre2-noc";
+ reg = <0x01700000 0x1f880>;
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&rpmhcc RPMH_IPA_CLK>;
- clk_virt: interconnect-clk-virt {
- compatible = "qcom,sm6350-clk-virt";
+ compute_noc: interconnect-compute-noc {
+ compatible = "qcom,sm6350-compute-noc";
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm7150-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm7150-rpmh.yaml
new file mode 100644
index 000000000000..978930324bbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm7150-rpmh.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm7150-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM7150
+
+maintainers:
+ - Danila Tikhonov <danila@jiaxyga.com>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also: include/dt-bindings/interconnect/qcom,sm7150-rpmh.h
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm7150-aggre1-noc
+ - qcom,sm7150-aggre2-noc
+ - qcom,sm7150-compute-noc
+ - qcom,sm7150-config-noc
+ - qcom,sm7150-dc-noc
+ - qcom,sm7150-gem-noc
+ - qcom,sm7150-mc-virt
+ - qcom,sm7150-mmss-noc
+ - qcom,sm7150-system-noc
+
+ reg:
+ maxItems: 1
+
+# Child node's properties
+patternProperties:
+ '^interconnect-[0-9]+$':
+ type: object
+ description:
+ The interconnect providers do not have a separate QoS register space,
+ but share parent's space.
+
+ allOf:
+ - $ref: qcom,rpmh-common.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - qcom,sm7150-camnoc-virt
+
+ required:
+ - compatible
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mc_virt: interconnect@1380000 {
+ compatible = "qcom,sm7150-mc-virt";
+ reg = <0x01380000 0x40000>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ system_noc: interconnect@1620000 {
+ compatible = "qcom,sm7150-system-noc";
+ reg = <0x01620000 0x40000>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+
+ camnoc_virt: interconnect-0 {
+ compatible = "qcom,sm7150-camnoc-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml
new file mode 100644
index 000000000000..6a46dc7d473e
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm8450-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM8450
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM).
+
+ See also: include/dt-bindings/interconnect/qcom,sm8450.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8450-aggre1-noc
+ - qcom,sm8450-aggre2-noc
+ - qcom,sm8450-clk-virt
+ - qcom,sm8450-config-noc
+ - qcom,sm8450-gem-noc
+ - qcom,sm8450-lpass-ag-noc
+ - qcom,sm8450-mc-virt
+ - qcom,sm8450-mmss-noc
+ - qcom,sm8450-nsp-noc
+ - qcom,sm8450-pcie-anoc
+ - qcom,sm8450-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-clk-virt
+ - qcom,sm8450-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe 0 AXI clock
+ - description: aggre-NOC PCIe 1 AXI clock
+ - description: aggre UFS PHY AXI clock
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-aggre1-noc
+ - qcom,sm8450-aggre2-noc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ interconnect-0 {
+ compatible = "qcom,sm8450-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ interconnect@1700000 {
+ compatible = "qcom,sm8450-aggre2-noc";
+ reg = <0x01700000 0x31080>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ clocks = <&gcc GCC_AGGRE_NOC_PCIE_0_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_1_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&rpmhcc RPMH_IPA_CLK>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml
new file mode 100644
index 000000000000..5325ebe23c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8550-rpmh.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm8550-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM8550
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,sm8550-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8550-aggre1-noc
+ - qcom,sm8550-aggre2-noc
+ - qcom,sm8550-clk-virt
+ - qcom,sm8550-cnoc-main
+ - qcom,sm8550-config-noc
+ - qcom,sm8550-gem-noc
+ - qcom,sm8550-lpass-ag-noc
+ - qcom,sm8550-lpass-lpiaon-noc
+ - qcom,sm8550-lpass-lpicx-noc
+ - qcom,sm8550-mc-virt
+ - qcom,sm8550-mmss-noc
+ - qcom,sm8550-nsp-noc
+ - qcom,sm8550-pcie-anoc
+ - qcom,sm8550-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-clk-virt
+ - qcom,sm8550-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-aggre1-noc
+ - qcom,sm8550-aggre2-noc
+ - qcom,sm8550-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+
+ clk_virt: interconnect-0 {
+ compatible = "qcom,sm8550-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e0000 {
+ compatible = "qcom,sm8550-aggre1-noc";
+ reg = <0x016e0000 0x14400>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8650-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8650-rpmh.yaml
new file mode 100644
index 000000000000..199fe7b232af
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8650-rpmh.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm8650-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM8650
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,sm8650-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8650-aggre1-noc
+ - qcom,sm8650-aggre2-noc
+ - qcom,sm8650-clk-virt
+ - qcom,sm8650-cnoc-main
+ - qcom,sm8650-config-noc
+ - qcom,sm8650-gem-noc
+ - qcom,sm8650-lpass-ag-noc
+ - qcom,sm8650-lpass-lpiaon-noc
+ - qcom,sm8650-lpass-lpicx-noc
+ - qcom,sm8650-mc-virt
+ - qcom,sm8650-mmss-noc
+ - qcom,sm8650-nsp-noc
+ - qcom,sm8650-pcie-anoc
+ - qcom,sm8650-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8650-clk-virt
+ - qcom,sm8650-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8650-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8650-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8650-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8650-aggre1-noc
+ - qcom,sm8650-aggre2-noc
+ - qcom,sm8650-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clk_virt: interconnect-0 {
+ compatible = "qcom,sm8650-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e0000 {
+ compatible = "qcom,sm8650-aggre1-noc";
+ reg = <0x016e0000 0x14400>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc_phy_axi_clk>, <&gcc_prim_axi_clk>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml
new file mode 100644
index 000000000000..366f40d980c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sm8750-rpmh.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,sm8750-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on SM8750
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,sm8750-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8750-aggre1-noc
+ - qcom,sm8750-aggre2-noc
+ - qcom,sm8750-clk-virt
+ - qcom,sm8750-cnoc-main
+ - qcom,sm8750-config-noc
+ - qcom,sm8750-gem-noc
+ - qcom,sm8750-lpass-ag-noc
+ - qcom,sm8750-lpass-lpiaon-noc
+ - qcom,sm8750-lpass-lpicx-noc
+ - qcom,sm8750-mc-virt
+ - qcom,sm8750-mmss-noc
+ - qcom,sm8750-nsp-noc
+ - qcom,sm8750-pcie-anoc
+ - qcom,sm8750-system-noc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-clk-virt
+ - qcom,sm8750-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-pcie-anoc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre-NOC PCIe AXI clock
+ - description: cfg-NOC PCIe a-NOC AHB clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-aggre1-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: aggre UFS PHY AXI clock
+ - description: aggre USB3 PRIM AXI clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-aggre2-noc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: RPMH CC IPA clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-aggre1-noc
+ - qcom,sm8750-aggre2-noc
+ - qcom,sm8750-pcie-anoc
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clk_virt: interconnect-0 {
+ compatible = "qcom,sm8750-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e0000 {
+ compatible = "qcom,sm8750-aggre1-noc";
+ reg = <0x016e0000 0x16400>;
+ #interconnect-cells = <2>;
+ clocks = <&gcc_phy_axi_clk>, <&gcc_prim_axi_clk>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,x1e80100-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,x1e80100-rpmh.yaml
new file mode 100644
index 000000000000..0840b0ec6e27
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,x1e80100-rpmh.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,x1e80100-rpmh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPMh Network-On-Chip Interconnect on X1E80100
+
+maintainers:
+ - Rajendra Nayak <quic_rjendra@quicinc.com>
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description: |
+ RPMh interconnect providers support system bandwidth requirements through
+ RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
+ able to communicate with the BCM through the Resource State Coordinator (RSC)
+ associated with each execution environment. Provider nodes must point to at
+ least one RPMh device child node pertaining to their RSC and each provider
+ can map to multiple RPMh resources.
+
+ See also: include/dt-bindings/interconnect/qcom,x1e80100-rpmh.h
+
+properties:
+ compatible:
+ enum:
+ - qcom,x1e80100-aggre1-noc
+ - qcom,x1e80100-aggre2-noc
+ - qcom,x1e80100-clk-virt
+ - qcom,x1e80100-cnoc-cfg
+ - qcom,x1e80100-cnoc-main
+ - qcom,x1e80100-gem-noc
+ - qcom,x1e80100-lpass-ag-noc
+ - qcom,x1e80100-lpass-lpiaon-noc
+ - qcom,x1e80100-lpass-lpicx-noc
+ - qcom,x1e80100-mc-virt
+ - qcom,x1e80100-mmss-noc
+ - qcom,x1e80100-nsp-noc
+ - qcom,x1e80100-pcie-center-anoc
+ - qcom,x1e80100-pcie-north-anoc
+ - qcom,x1e80100-pcie-south-anoc
+ - qcom,x1e80100-system-noc
+ - qcom,x1e80100-usb-center-anoc
+ - qcom,x1e80100-usb-north-anoc
+ - qcom,x1e80100-usb-south-anoc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+
+allOf:
+ - $ref: qcom,rpmh-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,x1e80100-clk-virt
+ - qcom,x1e80100-mc-virt
+ then:
+ properties:
+ reg: false
+ else:
+ required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clk_virt: interconnect-0 {
+ compatible = "qcom,x1e80100-clk-virt";
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e0000 {
+ compatible = "qcom,x1e80100-aggre1-noc";
+ reg = <0x016e0000 0x14400>;
+ #interconnect-cells = <2>;
+ qcom,bcm-voters = <&apps_bcm_voter>;
+ };
diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
index ad9ed596dfef..5e26e48c7217 100644
--- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
+++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
@@ -196,6 +196,8 @@ properties:
maxItems: 2
operating-points-v2: true
+ opp-table:
+ type: object
samsung,data-clock-ratio:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -227,6 +229,31 @@ examples:
operating-points-v2 = <&bus_dmc_opp_table>;
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>;
+
+ bus_dmc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-50000000 {
+ opp-hz = /bits/ 64 <50000000>;
+ opp-microvolt = <800000>;
+ };
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <800000>;
+ };
+ opp-134000000 {
+ opp-hz = /bits/ 64 <134000000>;
+ opp-microvolt = <800000>;
+ };
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <825000>;
+ };
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <875000>;
+ };
+ };
};
ppmu_dmc0: ppmu@106a0000 {
diff --git a/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt
deleted file mode 100644
index 5a4dd263fc12..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-TB10x Top Level Interrupt Controller
-====================================
-
-The Abilis TB10x SOC contains a custom interrupt controller. It performs
-one-to-one mapping of external interrupt sources to CPU interrupts and
-provides support for reconfigurable trigger modes.
-
-Required properties
--------------------
-
-- compatible: Should be "abilis,tb10x-ictl"
-- reg: specifies physical base address and size of register range.
-- interrupt-congroller: Identifies the node as an interrupt controller.
-- #interrupt cells: Specifies the number of cells used to encode an interrupt
- source connected to this controller. The value shall be 2.
-- interrupts: Specifies the list of interrupt lines which are handled by
- the interrupt controller in the parent controller's notation. Interrupts
- are mapped one-to-one to parent interrupts.
-
-Example
--------
-
-intc: interrupt-controller { /* Parent interrupt controller */
- interrupt-controller;
- #interrupt-cells = <1>; /* For example below */
- /* ... */
-};
-
-tb10x_ictl: pic@2000 { /* TB10x interrupt controller */
- compatible = "abilis,tb10x-ictl";
- reg = <0x2000 0x20>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <&intc>;
- interrupts = <5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
- 20 21 22 23 24 25 26 27 28 29 30 31>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.yaml b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.yaml
new file mode 100644
index 000000000000..cd2c49670e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/abilis,tb10x-ictl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TB10x Top Level Interrupt Controller
+
+maintainers:
+ - Christian Ruppert <christian.ruppert@abilis.com>
+
+description:
+ The Abilis TB10x SOC contains a custom interrupt controller. It performs
+ one-to-one mapping of external interrupt sources to CPU interrupts and
+ provides support for reconfigurable trigger modes.
+
+properties:
+ compatible:
+ const: abilis,tb10x-ictl
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description: A one-to-one mapping of external interrupt sources to parent
+ interrupts.
+ minItems: 1
+ maxItems: 32
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@2000 {
+ compatible = "abilis,tb10x-ictl";
+ reg = <0x2000 0x20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <5>, <6>, <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>,
+ <15>, <16>, <17>, <18>, <19>, <20>, <21>, <22>, <23>,
+ <24>, <25>, <26>, <27>, <28>, <29>, <30>, <31>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml
index 5da333c644c9..27756d0c5419 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml
@@ -32,7 +32,7 @@ properties:
The first cell is the input IRQ number, between 0 and 2, while the second
cell is the trigger type as defined in interrupt.txt in this directory.
- 'interrupts':
+ interrupts:
description: |
Contains the GIC SPI IRQs mapped to the external interrupt lines.
They shall be specified sequentially from output 0 to 2.
@@ -44,7 +44,7 @@ required:
- reg
- interrupt-controller
- '#interrupt-cells'
- - 'interrupts'
+ - interrupts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
deleted file mode 100644
index 5669764f9cc9..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Alpine MSIX controller
-
-See arm,gic-v3.txt for SPI and MSI definitions.
-
-Required properties:
-
-- compatible: should be "al,alpine-msix"
-- reg: physical base address and size of the registers
-- interrupt-controller: identifies the node as an interrupt controller
-- msi-controller: identifies the node as an PCI Message Signaled Interrupt
- controller
-- al,msi-base-spi: SPI base of the MSI frame
-- al,msi-num-spis: number of SPIs assigned to the MSI frame, relative to SPI0
-
-Example:
-
-msix: msix {
- compatible = "al,alpine-msix";
- reg = <0x0 0xfbe00000 0x0 0x100000>;
- interrupt-parent = <&gic>;
- interrupt-controller;
- msi-controller;
- al,msi-base-spi = <160>;
- al,msi-num-spis = <160>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.yaml b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.yaml
new file mode 100644
index 000000000000..9f1ff8ec686f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/al,alpine-msix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Alpine MSIX controller
+
+maintainers:
+ - Antoine Tenart <atenart@kernel.org>
+
+properties:
+ compatible:
+ const: al,alpine-msix
+
+ reg:
+ maxItems: 1
+
+ interrupt-parent: true
+
+ msi-controller: true
+
+ al,msi-base-spi:
+ description: SPI base of the MSI frame
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ al,msi-num-spis:
+ description: number of SPIs assigned to the MSI frame, relative to SPI0
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - msi-controller
+ - al,msi-base-spi
+ - al,msi-num-spis
+
+additionalProperties: false
+
+examples:
+ - |
+ msi-controller@fbe00000 {
+ compatible = "al,alpine-msix";
+ reg = <0xfbe00000 0x100000>;
+ interrupt-parent = <&gic>;
+ msi-controller;
+ al,msi-base-spi = <160>;
+ al,msi-num-spis = <160>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
index 953d875b5e74..a713633be733 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun4i-a10-ic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Interrupt Controller Device Tree Bindings
+title: Allwinner A10 Interrupt Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun6i-a31-r-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun6i-a31-r-intc.yaml
index 4db24b8a9ffe..4fa6fd400eef 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun6i-a31-r-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun6i-a31-r-intc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun6i-a31-r-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 NMI/Wakeup Interrupt Controller Device Tree Bindings
+title: Allwinner A31 NMI/Wakeup Interrupt Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
index 7fc9ad5ef38c..06e3621a8c06 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings
+title: Allwinner A20 Non-Maskable Interrupt Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -25,12 +25,13 @@ properties:
- const: allwinner,sun6i-a31-sc-nmi
deprecated: true
- const: allwinner,sun7i-a20-sc-nmi
- - items:
- - const: allwinner,sun8i-v3s-nmi
- - const: allwinner,sun9i-a80-nmi
- const: allwinner,sun9i-a80-nmi
+ - const: allwinner,sun55i-a523-nmi
- items:
- - const: allwinner,sun50i-a100-nmi
+ - enum:
+ - allwinner,sun8i-v3s-nmi
+ - allwinner,sun50i-a100-nmi
+ - allwinner,sun50i-h616-nmi
- const: allwinner,sun9i-a80-nmi
reg:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/altr,msi-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/altr,msi-controller.yaml
new file mode 100644
index 000000000000..d046954b8a27
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/altr,msi-controller.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2015, 2024, Intel Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/altr,msi-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera PCIe MSI controller
+
+maintainers:
+ - Matthew Gerlach <matthew.gerlach@linux.intel.com>
+
+properties:
+ compatible:
+ enum:
+ - altr,msi-1.0
+
+ reg:
+ items:
+ - description: CSR registers
+ - description: Vectors slave port region
+
+ reg-names:
+ items:
+ - const: csr
+ - const: vector_slave
+
+ interrupts:
+ maxItems: 1
+
+ msi-controller: true
+
+ num-vectors:
+ description: number of vectors
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 32
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - msi-controller
+ - num-vectors
+
+allOf:
+ - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ msi@ff200000 {
+ compatible = "altr,msi-1.0";
+ reg = <0xff200000 0x00000010>,
+ <0xff200010 0x00000080>;
+ reg-names = "csr", "vector_slave";
+ interrupt-parent = <&hps_0_arm_gic_0>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ msi-controller;
+ num-vectors = <32>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
deleted file mode 100644
index c676b03c752e..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Amazon's Annapurna Labs Fabric Interrupt Controller
-
-Required properties:
-
-- compatible: should be "amazon,al-fic"
-- reg: physical base address and size of the registers
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells : must be 2. Specifies the number of cells needed to encode
- an interrupt source. Supported trigger types are low-to-high edge
- triggered and active high level-sensitive.
-- interrupts: describes which input line in the interrupt parent, this
- fic's output is connected to. This field property depends on the parent's
- binding
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-Example:
-
-amazon_fic: interrupt-controller@fd8a8500 {
- compatible = "amazon,al-fic";
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x0 0xfd8a8500 0x0 0x1000>;
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 0x0 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.yaml b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.yaml
new file mode 100644
index 000000000000..26bc05dee0bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/amazon,al-fic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amazon Annapurna Labs Fabric Interrupt Controller
+
+maintainers:
+ - Talel Shenhar <talel@amazon.com>
+
+properties:
+ compatible:
+ const: amazon,al-fic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@fd8a8500 {
+ compatible = "amazon,al-fic";
+ reg = <0xfd8a8500 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 0x0 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
deleted file mode 100644
index bde63f8f090e..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Amlogic meson GPIO interrupt controller
-
-Meson SoCs contains an interrupt controller which is able to watch the SoC
-pads and generate an interrupt on edge or level. The controller is essentially
-a 256 pads to 8 GIC interrupt multiplexer, with a filter block to select edge
-or level and polarity. It does not expose all 256 mux inputs because the
-documentation shows that the upper part is not mapped to any pad. The actual
-number of interrupt exposed depends on the SoC.
-
-Required properties:
-
-- compatible : must have "amlogic,meson8-gpio-intc" and either
- "amlogic,meson8-gpio-intc" for meson8 SoCs (S802) or
- "amlogic,meson8b-gpio-intc" for meson8b SoCs (S805) or
- "amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or
- "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912)
- "amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X)
- "amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2)
- "amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3)
- "amlogic,meson-a1-gpio-intc" for A1 SoCs (A113L)
- "amlogic,meson-s4-gpio-intc" for S4 SoCs (S802X2, S905Y4, S805X2G, S905W2)
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 2.
-- meson,channel-interrupts: Array with the 8 upstream hwirq numbers. These
- are the hwirqs used on the parent interrupt controller.
-
-Example:
-
-gpio_interrupt: interrupt-controller@9880 {
- compatible = "amlogic,meson-gxbb-gpio-intc",
- "amlogic,meson-gpio-intc";
- reg = <0x0 0x9880 0x0 0x10>;
- interrupt-controller;
- #interrupt-cells = <2>;
- meson,channel-interrupts = <64 65 66 67 68 69 70 71>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
new file mode 100644
index 000000000000..d0fad930de9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/amlogic,meson-gpio-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson GPIO interrupt controller
+
+maintainers:
+ - Heiner Kallweit <hkallweit1@gmail.com>
+
+description: |
+ Meson SoCs contains an interrupt controller which is able to watch the SoC
+ pads and generate an interrupt on edge or level. The controller is essentially
+ a 256 pads to 8 or 12 GIC interrupt multiplexer, with a filter block to select
+ edge or level and polarity. It does not expose all 256 mux inputs because the
+ documentation shows that the upper part is not mapped to any pad. The actual
+ number of interrupts exposed depends on the SoC.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-gpio-intc
+ - items:
+ - enum:
+ - amlogic,meson8-gpio-intc
+ - amlogic,meson8b-gpio-intc
+ - amlogic,meson-gxbb-gpio-intc
+ - amlogic,meson-gxl-gpio-intc
+ - amlogic,meson-axg-gpio-intc
+ - amlogic,meson-g12a-gpio-intc
+ - amlogic,meson-sm1-gpio-intc
+ - amlogic,meson-a1-gpio-intc
+ - amlogic,meson-s4-gpio-intc
+ - amlogic,a4-gpio-intc
+ - amlogic,a4-gpio-ao-intc
+ - amlogic,a5-gpio-intc
+ - amlogic,c3-gpio-intc
+ - amlogic,s6-gpio-intc
+ - amlogic,s7-gpio-intc
+ - amlogic,s7d-gpio-intc
+ - amlogic,t7-gpio-intc
+ - const: amlogic,meson-gpio-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ amlogic,channel-interrupts:
+ description: Array with the upstream hwirq numbers
+ minItems: 2
+ maxItems: 12
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+ - amlogic,channel-interrupts
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,a4-gpio-ao-intc
+then:
+ properties:
+ amlogic,channel-interrupts:
+ maxItems: 2
+else:
+ properties:
+ amlogic,channel-interrupts:
+ minItems: 8
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@9880 {
+ compatible = "amlogic,meson-gxbb-gpio-intc",
+ "amlogic,meson-gpio-intc";
+ reg = <0x9880 0x10>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ amlogic,channel-interrupts = <64 65 66 67 68 69 70 71>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/andestech,plicsw.yaml b/Documentation/devicetree/bindings/interrupt-controller/andestech,plicsw.yaml
new file mode 100644
index 000000000000..eb2eb611ac09
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/andestech,plicsw.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/andestech,plicsw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes machine-level software interrupt controller
+
+description:
+ In the Andes platform such as QiLai SoC, the PLIC module is instantiated a
+ second time with all interrupt sources tied to zero as the software interrupt
+ controller (PLIC_SW). PLIC_SW directly connects to the machine-mode
+ inter-processor interrupt lines of CPUs, so RISC-V per-CPU local interrupt
+ controller is the parent interrupt controller for PLIC_SW. PLIC_SW can
+ generate machine-mode inter-processor interrupts through programming its
+ registers.
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - andestech,qilai-plicsw
+ - const: andestech,plicsw
+
+ reg:
+ maxItems: 1
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 15872
+ description:
+ Specifies which harts are connected to the PLIC_SW. Each item must points
+ to a riscv,cpu-intc node, which has a riscv cpu node as parent.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts-extended
+
+examples:
+ - |
+ interrupt-controller@400000 {
+ compatible = "andestech,qilai-plicsw", "andestech,plicsw";
+ reg = <0x400000 0x400000>;
+ interrupts-extended = <&cpu0intc 3>,
+ <&cpu1intc 3>,
+ <&cpu2intc 3>,
+ <&cpu3intc 3>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/apm,xgene1-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/apm,xgene1-msi.yaml
new file mode 100644
index 000000000000..49db952697f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/apm,xgene1-msi.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/apm,xgene1-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AppliedMicro X-Gene v1 PCIe MSI controller
+
+maintainers:
+ - Toan Le <toan@os.amperecomputing.com>
+
+properties:
+ compatible:
+ const: apm,xgene1-msi
+
+ msi-controller: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 16
+
+required:
+ - compatible
+ - msi-controller
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ msi@79000000 {
+ compatible = "apm,xgene1-msi";
+ msi-controller;
+ reg = <0x79000000 0x900000>;
+ interrupts = <0x0 0x10 0x4>,
+ <0x0 0x11 0x4>,
+ <0x0 0x12 0x4>,
+ <0x0 0x13 0x4>,
+ <0x0 0x14 0x4>,
+ <0x0 0x15 0x4>,
+ <0x0 0x16 0x4>,
+ <0x0 0x17 0x4>,
+ <0x0 0x18 0x4>,
+ <0x0 0x19 0x4>,
+ <0x0 0x1a 0x4>,
+ <0x0 0x1b 0x4>,
+ <0x0 0x1c 0x4>,
+ <0x0 0x1d 0x4>,
+ <0x0 0x1e 0x4>,
+ <0x0 0x1f 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
index e18107eafe7c..4be9b596a790 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
@@ -31,13 +31,25 @@ description: |
This device also represents the FIQ interrupt sources on platforms using AIC,
which do not go through a discrete interrupt controller.
+ IPIs may be performed via MMIO registers on all variants of AIC. Starting
+ from A11, system registers may also be used for "fast" IPIs. Starting from
+ M1, even faster IPIs within the same cluster may be achieved by writing to
+ a "local" fast IPI register as opposed to using the "global" fast IPI
+ register.
+
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
items:
- - const: apple,t8103-aic
+ - enum:
+ - apple,s5l8960x-aic
+ - apple,t7000-aic
+ - apple,s8000-aic
+ - apple,t8010-aic
+ - apple,t8015-aic
+ - apple,t8103-aic
- const: apple,aic
interrupt-controller: true
@@ -90,7 +102,6 @@ properties:
maximum: 5
cpus:
- $ref: /schemas/types.yaml#/definitions/phandle-array
description:
Should be a list of phandles to CPU nodes (as described in
Documentation/devicetree/bindings/arm/cpus.yaml).
diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml
index 47a78a167aba..ee5a0dfff437 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml
@@ -31,19 +31,23 @@ description: |
properties:
compatible:
items:
- - const: apple,t6000-aic
+ - enum:
+ - apple,t8112-aic
+ - apple,t6000-aic
+ - apple,t6020-aic
- const: apple,aic2
interrupt-controller: true
'#interrupt-cells':
- const: 4
+ minimum: 3
+ maximum: 4
description: |
The 1st cell contains the interrupt type:
- 0: Hardware IRQ
- 1: FIQ
- The 2nd cell contains the die ID.
+ The 2nd cell contains the die ID (only present on apple,t6000-aic).
The next cell contains the interrupt number.
- HW IRQs: interrupt number
@@ -69,6 +73,35 @@ properties:
power-domains:
maxItems: 1
+ affinities:
+ type: object
+ additionalProperties: false
+ description:
+ FIQ affinity can be expressed as a single "affinities" node,
+ containing a set of sub-nodes, one per FIQ with a non-default
+ affinity.
+ patternProperties:
+ "^.+-affinity$":
+ type: object
+ additionalProperties: false
+ properties:
+ apple,fiq-index:
+ description:
+ The interrupt number specified as a FIQ, and for which
+ the affinity is not the default.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 5
+
+ cpus:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Should be a list of phandles to CPU nodes (as described in
+ Documentation/devicetree/bindings/arm/cpus.yaml).
+
+ required:
+ - apple,fiq-index
+ - cpus
+
required:
- compatible
- '#interrupt-cells'
@@ -80,6 +113,19 @@ additionalProperties: false
allOf:
- $ref: /schemas/interrupt-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: apple,t8112-aic
+ then:
+ properties:
+ '#interrupt-cells':
+ const: 3
+ else:
+ properties:
+ '#interrupt-cells':
+ const: 4
examples:
- |
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
index 3912a89162f0..bfd30aae682b 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -49,7 +49,7 @@ properties:
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
- range [0-15]. Extented SPI interrupts are in the range [0-1023].
+ range [0-15]. Extended SPI interrupts are in the range [0-1023].
Extended PPI interrupts are in the range [0-127].
The 3rd cell is the flags, encoded as follows:
@@ -60,7 +60,7 @@ properties:
The 4th cell is a phandle to a node describing a set of CPUs this
interrupt is affine to. The interrupt must be a PPI, and the node
pointed must be a subnode of the "ppi-partitions" subnode. For
- interrupt types other than PPI or PPIs that are not partitionned,
+ interrupt types other than PPI or PPIs that are not partitioned,
this cell must be zero. See the "ppi-partitions" node description
below.
@@ -106,9 +106,15 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 4096
+ dma-noncoherent:
+ description:
+ Present if the GIC redistributors permit programming shareability
+ and cacheability attributes but are connected to a non-coherent
+ downstream interconnect.
+
msi-controller:
description:
- Only present if the Message Based Interrupt functionnality is
+ Only present if the Message Based Interrupt functionality is
being exposed by the HW, and the mbi-ranges property present.
mbi-ranges:
@@ -126,19 +132,20 @@ properties:
Address property. Base address of an alias of the GICD region containing
only the {SET,CLR}SPI registers to be used if isolation is required,
and if supported by the HW.
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- minItems: 1
- maxItems: 2
+ oneOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - $ref: /schemas/types.yaml#/definitions/uint64
ppi-partitions:
type: object
+ additionalProperties: false
description:
PPI affinity can be expressed as a single "ppi-partitions" node,
containing a set of sub-nodes.
patternProperties:
"^interrupt-partition-[0-9]+$":
type: object
+ additionalProperties: false
properties:
affinity:
$ref: /schemas/types.yaml#/definitions/phandle-array
@@ -164,13 +171,18 @@ properties:
resets:
maxItems: 1
+ mediatek,broken-save-restore-fw:
+ type: boolean
+ description:
+ Asserts that the firmware on this device has issues saving and restoring
+ GICR registers when the GIC redistributors are powered off.
+
dependencies:
mbi-ranges: [ msi-controller ]
msi-controller: [ mbi-ranges ]
required:
- compatible
- - interrupts
- reg
patternProperties:
@@ -186,6 +198,12 @@ patternProperties:
compatible:
const: arm,gic-v3-its
+ dma-noncoherent:
+ description:
+ Present if the GIC ITS permits programming shareability and
+ cacheability attributes but is connected to a non-coherent
+ downstream interconnect.
+
msi-controller: true
"#msi-cells":
@@ -204,9 +222,8 @@ patternProperties:
(u32, u32) tuple describing the untranslated
address and size of the pre-ITS window.
$ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- minItems: 2
- maxItems: 2
+ minItems: 2
+ maxItems: 2
required:
- compatible
@@ -288,7 +305,6 @@ examples:
};
};
-
device@0 {
reg = <0 4>;
interrupts = <1 1 4 &part0>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5-iwb.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5-iwb.yaml
new file mode 100644
index 000000000000..99a266a62385
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5-iwb.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/arm,gic-v5-iwb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Generic Interrupt Controller, version 5 Interrupt Wire Bridge (IWB)
+
+maintainers:
+ - Lorenzo Pieralisi <lpieralisi@kernel.org>
+ - Marc Zyngier <maz@kernel.org>
+
+description: |
+ The GICv5 architecture defines the guidelines to implement GICv5
+ compliant interrupt controllers for AArch64 systems.
+
+ The GICv5 specification can be found at
+ https://developer.arm.com/documentation/aes0070
+
+ GICv5 has zero or more Interrupt Wire Bridges (IWB) that are responsible
+ for translating wire signals into interrupt messages to the GICv5 ITS.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ const: arm,gic-v5-iwb
+
+ reg:
+ items:
+ - description: IWB control frame
+
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ description: |
+ The 1st cell corresponds to the IWB wire.
+
+ The 2nd cell is the flags, encoded as follows:
+ bits[3:0] trigger type and level flags.
+
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive
+
+ const: 2
+
+ interrupt-controller: true
+
+ msi-parent:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#interrupt-cells"
+ - interrupt-controller
+ - msi-parent
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@2f000000 {
+ compatible = "arm,gic-v5-iwb";
+ reg = <0x2f000000 0x10000>;
+
+ #address-cells = <0>;
+
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ msi-parent = <&its0 64>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5.yaml
new file mode 100644
index 000000000000..86ca7f3ac281
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v5.yaml
@@ -0,0 +1,267 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/arm,gic-v5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Generic Interrupt Controller, version 5
+
+maintainers:
+ - Lorenzo Pieralisi <lpieralisi@kernel.org>
+ - Marc Zyngier <maz@kernel.org>
+
+description: |
+ The GICv5 architecture defines the guidelines to implement GICv5
+ compliant interrupt controllers for AArch64 systems.
+
+ The GICv5 specification can be found at
+ https://developer.arm.com/documentation/aes0070
+
+ The GICv5 architecture is composed of multiple components:
+ - one or more IRS (Interrupt Routing Service)
+ - zero or more ITS (Interrupt Translation Service)
+
+ The architecture defines:
+ - PE-Private Peripheral Interrupts (PPI)
+ - Shared Peripheral Interrupts (SPI)
+ - Logical Peripheral Interrupts (LPI)
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ const: arm,gic-v5
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ "#interrupt-cells":
+ description: |
+ The 1st cell corresponds to the INTID.Type field in the INTID; 1 for PPI,
+ 3 for SPI. LPI interrupts must not be described in the bindings since
+ they are allocated dynamically by the software component managing them.
+
+ The 2nd cell contains the interrupt INTID.ID field.
+
+ The 3rd cell is the flags, encoded as follows:
+ bits[3:0] trigger type and level flags.
+
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive
+
+ const: 3
+
+ interrupt-controller: true
+
+ interrupts:
+ description:
+ The VGIC maintenance interrupt.
+ maxItems: 1
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - "#interrupt-cells"
+ - interrupt-controller
+
+patternProperties:
+ "^irs@[0-9a-f]+$":
+ type: object
+ description:
+ GICv5 has one or more Interrupt Routing Services (IRS) that are
+ responsible for handling IRQ state and routing.
+
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: arm,gic-v5-irs
+
+ reg:
+ minItems: 1
+ items:
+ - description: IRS config frames
+ - description: IRS setlpi frames
+
+ reg-names:
+ description:
+ Describe config and setlpi frames that are present.
+ "ns-" stands for non-secure, "s-" for secure, "realm-" for realm
+ and "el3-" for EL3.
+ minItems: 1
+ maxItems: 8
+ items:
+ enum: [ ns-config, s-config, realm-config, el3-config, ns-setlpi,
+ s-setlpi, realm-setlpi, el3-setlpi ]
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ dma-noncoherent:
+ description:
+ Present if the GIC IRS permits programming shareability and
+ cacheability attributes but is connected to a non-coherent
+ downstream interconnect.
+
+ cpus:
+ description:
+ CPUs managed by the IRS.
+
+ arm,iaffids:
+ $ref: /schemas/types.yaml#/definitions/uint16-array
+ description:
+ Interrupt AFFinity ID (IAFFID) associated with the CPU whose
+ CPU node phandle is at the same index in the cpus array.
+
+ patternProperties:
+ "^its@[0-9a-f]+$":
+ type: object
+ description:
+ GICv5 has zero or more Interrupt Translation Services (ITS) that are
+ used to route Message Signalled Interrupts (MSI) to the CPUs. Each
+ ITS is connected to an IRS.
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: arm,gic-v5-its
+
+ reg:
+ items:
+ - description: ITS config frames
+
+ reg-names:
+ description:
+ Describe config frames that are present.
+ "ns-" stands for non-secure, "s-" for secure, "realm-" for realm
+ and "el3-" for EL3.
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ ns-config, s-config, realm-config, el3-config ]
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ dma-noncoherent:
+ description:
+ Present if the GIC ITS permits programming shareability and
+ cacheability attributes but is connected to a non-coherent
+ downstream interconnect.
+
+ patternProperties:
+ "^msi-controller@[0-9a-f]+$":
+ type: object
+ description:
+ GICv5 ITS has one or more translate register frames.
+ additionalProperties: false
+
+ properties:
+ reg:
+ items:
+ - description: ITS translate frames
+
+ reg-names:
+ description:
+ Describe translate frames that are present.
+ "ns-" stands for non-secure, "s-" for secure, "realm-" for realm
+ and "el3-" for EL3.
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ ns-translate, s-translate, realm-translate, el3-translate ]
+
+ "#msi-cells":
+ description:
+ The single msi-cell is the DeviceID of the device which will
+ generate the MSI.
+ const: 1
+
+ msi-controller: true
+
+ required:
+ - reg
+ - reg-names
+ - "#msi-cells"
+ - msi-controller
+
+ required:
+ - compatible
+ - reg
+ - reg-names
+
+ required:
+ - compatible
+ - reg
+ - reg-names
+ - cpus
+ - arm,iaffids
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "arm,gic-v5";
+
+ #interrupt-cells = <3>;
+ interrupt-controller;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ interrupts = <1 25 4>;
+
+ irs@2f1a0000 {
+ compatible = "arm,gic-v5-irs";
+ reg = <0x2f1a0000 0x10000>; // IRS_CONFIG_FRAME
+ reg-names = "ns-config";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>, <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+ arm,iaffids = /bits/ 16 <0 1 2 3 4 5 6 7>;
+
+ its@2f120000 {
+ compatible = "arm,gic-v5-its";
+ reg = <0x2f120000 0x10000>; // ITS_CONFIG_FRAME
+ reg-names = "ns-config";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ msi-controller@2f130000 {
+ reg = <0x2f130000 0x10000>; // ITS_TRANSLATE_FRAME
+ reg-names = "ns-translate";
+
+ #msi-cells = <1>;
+ msi-controller;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
index 62219a5c21c5..ee4c77dac201 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
@@ -59,14 +59,15 @@ properties:
- nvidia,tegra186-agic
- nvidia,tegra194-agic
- nvidia,tegra234-agic
+ - nvidia,tegra264-agic
- const: nvidia,tegra210-agic
interrupt-controller: true
"#address-cells":
- enum: [ 0, 1 ]
+ enum: [ 0, 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
"#interrupt-cells":
const: 3
@@ -110,8 +111,8 @@ properties:
interrupts:
description: Interrupt source of the parent interrupt controller on
- secondary GICs, or VGIC maintenance interrupt on primary GIC (see
- below).
+ secondary GICs, or VGIC maintenance interrupt on primary GIC (see "GICv2
+ with virtualization extensions" paragraph in the "reg" property).
maxItems: 1
cpu-offset:
@@ -133,8 +134,8 @@ properties:
- items: # for "arm,cortex-a9-gic"
- const: PERIPHCLK
- const: PERIPHCLKEN
- - const: clk # for "arm,gic-400" and "nvidia,tegra210"
- - const: gclk #for "arm,pl390"
+ - const: clk # for "arm,gic-400" and "nvidia,tegra210"
+ - const: gclk # for "arm,pl390"
power-domains:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
deleted file mode 100644
index 386ab37a383f..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* ARM Nested Vector Interrupt Controller (NVIC)
-
-The NVIC provides an interrupt controller that is tightly coupled to
-Cortex-M based processor cores. The NVIC implemented on different SoCs
-vary in the number of interrupts and priority bits per interrupt.
-
-Main node required properties:
-
-- compatible : should be one of:
- "arm,v6m-nvic"
- "arm,v7m-nvic"
- "arm,v8m-nvic"
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The type shall be a <u32> and the value shall be 2.
-
- The 1st cell contains the interrupt number for the interrupt type.
-
- The 2nd cell is the priority of the interrupt.
-
-- reg : Specifies base physical address(s) and size of the NVIC registers.
- This is at a fixed address (0xe000e100) and size (0xc00).
-
-- arm,num-irq-priority-bits: The number of priority bits implemented by the
- given SoC
-
-Example:
-
- intc: interrupt-controller@e000e100 {
- compatible = "arm,v7m-nvic";
- #interrupt-cells = <2>;
- #address-cells = <1>;
- interrupt-controller;
- reg = <0xe000e100 0xc00>;
- arm,num-irq-priority-bits = <4>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.yaml
new file mode 100644
index 000000000000..32dfa2bf05d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/arm,nvic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Nested Vector Interrupt Controller (NVIC)
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+description:
+ The NVIC provides an interrupt controller that is tightly coupled to Cortex-M
+ based processor cores. The NVIC implemented on different SoCs vary in the
+ number of interrupts and priority bits per interrupt.
+
+properties:
+ compatible:
+ enum:
+ - arm,armv7m-nvic # deprecated
+ - arm,v6m-nvic
+ - arm,v7m-nvic
+ - arm,v8m-nvic
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ enum: [1, 2]
+ description: |
+ Number of cells to encode an interrupt source:
+ first = interrupt number, second = priority.
+
+ arm,num-irq-priority-bits:
+ description: Number of priority bits implemented by the SoC
+ minimum: 1
+ maximum: 8
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - arm,num-irq-priority-bits
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@e000e100 {
+ compatible = "arm,v7m-nvic";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0xe000e100 0xc00>;
+ arm,num-irq-priority-bits = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
deleted file mode 100644
index 2a1d16bdf834..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* ARM Versatile FPGA interrupt controller
-
-One or more FPGA IRQ controllers can be synthesized in an ARM reference board
-such as the Integrator or Versatile family. The output of these different
-controllers are OR:ed together and fed to the CPU tile's IRQ input. Each
-instance can handle up to 32 interrupts.
-
-Required properties:
-- compatible: "arm,versatile-fpga-irq" or "oxsemi,ox810se-rps-irq"
-- interrupt-controller: Identifies the node as an interrupt controller
-- #interrupt-cells: The number of cells to define the interrupts. Must be 1
- as the FPGA IRQ controller has no configuration options for interrupt
- sources. The cell is a u32 and defines the interrupt number.
-- reg: The register bank for the FPGA interrupt controller.
-- clear-mask: a u32 number representing the mask written to clear all IRQs
- on the controller at boot for example.
-- valid-mask: a u32 number representing a bit mask determining which of
- the interrupts are valid. Unconnected/unused lines are set to 0, and
- the system till not make it possible for devices to request these
- interrupts.
-
-Example:
-
-pic: pic@14000000 {
- compatible = "arm,versatile-fpga-irq";
- #interrupt-cells = <1>;
- interrupt-controller;
- reg = <0x14000000 0x100>;
- clear-mask = <0xffffffff>;
- valid-mask = <0x003fffff>;
-};
-
-Optional properties:
-- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ
- output is simply connected to the input of another IRQ controller,
- then the parent IRQ shall be specified in this property.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.yaml
new file mode 100644
index 000000000000..8d581b3aac3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/arm,versatile-fpga-irq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Versatile FPGA IRQ Controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ One or more FPGA IRQ controllers can be synthesized in an ARM reference board
+ such as the Integrator or Versatile family. The output of these different
+ controllers are OR:ed together and fed to the CPU tile's IRQ input. Each
+ instance can handle up to 32 interrupts.
+
+properties:
+ compatible:
+ const: arm,versatile-fpga-irq
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clear-mask:
+ description: A mask written to clear all IRQs on the controller at boot.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ valid-mask:
+ description:
+ A bit mask determining which interrupts are valid; unused lines are set to 0.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ interrupts:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+ - reg
+ - clear-mask
+ - valid-mask
+
+examples:
+ - |
+ interrupt-controller@14000000 {
+ compatible = "arm,versatile-fpga-irq";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ reg = <0x14000000 0x100>;
+ clear-mask = <0xffffffff>;
+ valid-mask = <0x003fffff>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
deleted file mode 100644
index 033cc82e5684..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Device tree configuration for the I2C Interrupt Controller on the AST24XX and
-AST25XX SoCs.
-
-Required Properties:
-- #address-cells : should be 1
-- #size-cells : should be 1
-- #interrupt-cells : should be 1
-- compatible : should be "aspeed,ast2400-i2c-ic"
- or "aspeed,ast2500-i2c-ic"
-- reg : address start and range of controller
-- interrupts : interrupt number
-- interrupt-controller : denotes that the controller receives and fires
- new interrupts for child busses
-
-Example:
-
-i2c_ic: interrupt-controller@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- #interrupt-cells = <1>;
- compatible = "aspeed,ast2400-i2c-ic";
- reg = <0x0 0x40>;
- interrupts = <12>;
- interrupt-controller;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.yaml
new file mode 100644
index 000000000000..6cff6a7231bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/aspeed,ast2400-i2c-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed I2C Interrupt Controller (AST24XX/AST25XX)
+
+maintainers:
+ - Ryan Chen <ryan_chen@aspeedtech.com>
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-i2c-ic
+ - aspeed,ast2500-i2c-ic
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupts
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@0 {
+ compatible = "aspeed,ast2400-i2c-ic";
+ reg = <0x0 0x40>;
+ #interrupt-cells = <1>;
+ interrupts = <12>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.txt b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.txt
deleted file mode 100644
index e3fea0758d25..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Aspeed Vectored Interrupt Controller
-
-These bindings are for the Aspeed interrupt controller. The AST2400 and
-AST2500 SoC families include a legacy register layout before a re-designed
-layout, but the bindings do not prescribe the use of one or the other.
-
-Required properties:
-
-- compatible : "aspeed,ast2400-vic"
- "aspeed,ast2500-vic"
-
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-Example:
-
- vic: interrupt-controller@1e6c0080 {
- compatible = "aspeed,ast2400-vic";
- interrupt-controller;
- #interrupt-cells = <1>;
- reg = <0x1e6c0080 0x80>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml
new file mode 100644
index 000000000000..86516cd44b9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/aspeed,ast2400-vic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Vectored Interrupt Controller
+
+maintainers:
+ - Andrew Jeffery <andrew@codeconstruct.com.au>
+
+description:
+ The AST2400 and AST2500 SoC families include a legacy register layout before
+ a redesigned layout, but the bindings do not prescribe the use of one or the
+ other.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-vic
+ - aspeed,ast2500-vic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+ description:
+ Specifies the number of cells needed to encode an interrupt source. It
+ must be 1 as the VIC has no configuration options for interrupt sources.
+ The single cell defines the interrupt number.
+
+ valid-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ description:
+ A bitmap of supported sources for the implementation.
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1e6c0080 {
+ compatible = "aspeed,ast2400-vic";
+ reg = <0x1e6c0080 0x80>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ valid-sources = <0xffffffff 0x0007ffff>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2500-scu-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2500-scu-ic.yaml
new file mode 100644
index 000000000000..d998a9d69b91
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2500-scu-ic.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Eddie James
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/aspeed,ast2500-scu-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed AST25XX, AST26XX, AST27XX SCU Interrupt Controller
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2500-scu-ic
+ - aspeed,ast2600-scu-ic0
+ - aspeed,ast2600-scu-ic1
+ - aspeed,ast2700-scu-ic0
+ - aspeed,ast2700-scu-ic1
+ - aspeed,ast2700-scu-ic2
+ - aspeed,ast2700-scu-ic3
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupts
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@18 {
+ compatible = "aspeed,ast2500-scu-ic";
+ reg = <0x18 0x4>;
+ #interrupt-cells = <1>;
+ interrupts = <21>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc.yaml
new file mode 100644
index 000000000000..258d21fe6e35
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2700-intc.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/aspeed,ast2700-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed AST2700 Interrupt Controller
+
+description:
+ This interrupt controller hardware is second level interrupt controller that
+ is hooked to a parent interrupt controller. It's useful to combine multiple
+ interrupt sources into 1 interrupt to parent interrupt controller.
+
+maintainers:
+ - Kevin Chen <kevin_chen@aspeedtech.com>
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2700-intc-ic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+ description:
+ The first cell is the IRQ number, the second cell is the trigger
+ type as defined in interrupt.txt in this directory.
+
+ interrupts:
+ minItems: 1
+ maxItems: 10
+ description: |
+ Depend to which INTC0 or INTC1 used.
+ INTC0 and INTC1 are two kinds of interrupt controller with enable and raw
+ status registers for use.
+ INTC0 is used to assert GIC if interrupt in INTC1 asserted.
+ INTC1 is used to assert INTC0 if interrupt of modules asserted.
+ +-----+ +-------+ +---------+---module0
+ | GIC |---| INTC0 |--+--| INTC1_0 |---module2
+ | | | | | | |---...
+ +-----+ +-------+ | +---------+---module31
+ |
+ | +---------+---module0
+ +---| INTC1_1 |---module2
+ | | |---...
+ | +---------+---module31
+ ...
+ | +---------+---module0
+ +---| INTC1_5 |---module2
+ | |---...
+ +---------+---module31
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ interrupt-controller@12101b00 {
+ compatible = "aspeed,ast2700-intc-ic";
+ reg = <0 0x12101b00 0 0x10>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2xxx-scu-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2xxx-scu-ic.txt
deleted file mode 100644
index 251ed44171db..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2xxx-scu-ic.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Aspeed AST25XX and AST26XX SCU Interrupt Controller
-
-Required Properties:
- - #interrupt-cells : must be 1
- - compatible : must be "aspeed,ast2500-scu-ic",
- "aspeed,ast2600-scu-ic0" or
- "aspeed,ast2600-scu-ic1"
- - interrupts : interrupt from the parent controller
- - interrupt-controller : indicates that the controller receives and
- fires new interrupts for child busses
-
-Example:
-
- syscon@1e6e2000 {
- ranges = <0 0x1e6e2000 0x1a8>;
-
- scu_ic: interrupt-controller@18 {
- #interrupt-cells = <1>;
- compatible = "aspeed,ast2500-scu-ic";
- interrupts = <21>;
- interrupt-controller;
- };
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
deleted file mode 100644
index 7079d44bf3ba..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-* Advanced Interrupt Controller (AIC)
-
-Required properties:
-- compatible: Should be:
- - "atmel,<chip>-aic" where <chip> can be "at91rm9200", "sama5d2",
- "sama5d3" or "sama5d4"
- - "microchip,<chip>-aic" where <chip> can be "sam9x60"
-
-- interrupt-controller: Identifies the node as an interrupt controller.
-- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
- The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
- The second cell is used to specify flags:
- bits[3:0] trigger type and level flags:
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 4 = active high level-sensitive.
- 8 = active low level-sensitive.
- Valid combinations are 1, 2, 3, 4, 8.
- Default flag for internal sources should be set to 4 (active high).
- The third cell is used to specify the irq priority from 0 (lowest) to 7
- (highest).
-- reg: Should contain AIC registers location and length
-- atmel,external-irqs: u32 array of external irqs.
-
-Examples:
- /*
- * AIC
- */
- aic: interrupt-controller@fffff000 {
- compatible = "atmel,at91rm9200-aic";
- interrupt-controller;
- #interrupt-cells = <3>;
- reg = <0xfffff000 0x200>;
- };
-
- /*
- * An interrupt generating device that is wired to an AIC.
- */
- dma: dma-controller@ffffec00 {
- compatible = "atmel,at91sam9g45-dma";
- reg = <0xffffec00 0x200>;
- interrupts = <21 4 5>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml
new file mode 100644
index 000000000000..d671ed884c9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/atmel,aic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advanced Interrupt Controller (AIC)
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Dharma balasubiramani <dharma.b@microchip.com>
+
+description:
+ The Advanced Interrupt Controller (AIC) is an 8-level priority, individually
+ maskable, vectored interrupt controller providing handling of up to one
+ hundred and twenty-eight interrupt sources.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91rm9200-aic
+ - atmel,sama5d2-aic
+ - atmel,sama5d3-aic
+ - atmel,sama5d4-aic
+ - microchip,sam9x60-aic
+ - microchip,sam9x7-aic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 3
+ description: |
+ The 1st cell is the IRQ number (Peripheral IDentifier on datasheet).
+ The 2nd cell specifies flags:
+ bits[3:0] trigger type and level flags:
+ 1 = low-to-high edge triggered.
+ 2 = high-to-low edge triggered.
+ 4 = active high level-sensitive.
+ 8 = active low level-sensitive.
+ Valid combinations: 1, 2, 3, 4, 8.
+ Default for internal sources: 4 (active high).
+ The 3rd cell specifies irq priority from 0 (lowest) to 7 (highest).
+
+ interrupts:
+ maxItems: 1
+
+ atmel,external-irqs:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: u32 array of external irqs.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91rm9200-aic
+ then:
+ properties:
+ atmel,external-irqs:
+ minItems: 1
+ maxItems: 7
+ else:
+ properties:
+ atmel,external-irqs:
+ minItems: 1
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+ - atmel,external-irqs
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interrupt-controller@fffff000 {
+ compatible = "atmel,at91rm9200-aic";
+ reg = <0xfffff000 0x200>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ atmel,external-irqs = <31>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml
new file mode 100644
index 000000000000..c84614663b5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm2712-msix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom bcm2712 MSI-X Interrupt Peripheral support
+
+maintainers:
+ - Stanimir Varbanov <svarbanov@suse.de>
+
+description:
+ This interrupt controller is used to provide interrupt vectors to the
+ generic interrupt controller (GIC) on bcm2712. It will be used as
+ external MSI-X controller for PCIe root complex.
+
+allOf:
+ - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm2712-mip
+
+ reg:
+ items:
+ - description: Base register address
+ - description: PCIe message address
+
+ "#msi-cells":
+ const: 0
+
+ brcm,msi-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Shift the allocated MSI's.
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - msi-controller
+ - msi-ranges
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ axi {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ msi-controller@1000130000 {
+ compatible = "brcm,bcm2712-mip";
+ reg = <0x10 0x00130000 0x00 0xc0>,
+ <0xff 0xfffff000 0x00 0x1000>;
+ msi-controller;
+ #msi-cells = <0>;
+ msi-ranges = <&gicv2 GIC_SPI 128 IRQ_TYPE_EDGE_RISING 64>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
deleted file mode 100644
index 0f1af5a1c12e..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+++ /dev/null
@@ -1,131 +0,0 @@
-BCM2835 Top-Level ("ARMCTRL") Interrupt Controller
-
-The BCM2835 contains a custom top-level interrupt controller, which supports
-72 interrupt sources using a 2-level register scheme. The interrupt
-controller, or the HW block containing it, is referred to occasionally
-as "armctrl" in the SoC documentation, hence naming of this binding.
-
-The BCM2836 contains the same interrupt controller with the same
-interrupts, but the per-CPU interrupt controller is the root, and an
-interrupt there indicates that the ARMCTRL has an interrupt to handle.
-
-Required properties:
-
-- compatible : should be "brcm,bcm2835-armctrl-ic" or
- "brcm,bcm2836-armctrl-ic"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 2.
-
- The 1st cell is the interrupt bank; 0 for interrupts in the "IRQ basic
- pending" register, or 1/2 respectively for interrupts in the "IRQ pending
- 1/2" register.
-
- The 2nd cell contains the interrupt number within the bank. Valid values
- are 0..7 for bank 0, and 0..31 for bank 1.
-
-Additional required properties for brcm,bcm2836-armctrl-ic:
-- interrupts : Specifies the interrupt on the parent for this interrupt
- controller to handle.
-
-The interrupt sources are as follows:
-
-Bank 0:
-0: ARM_TIMER
-1: ARM_MAILBOX
-2: ARM_DOORBELL_0
-3: ARM_DOORBELL_1
-4: VPU0_HALTED
-5: VPU1_HALTED
-6: ILLEGAL_TYPE0
-7: ILLEGAL_TYPE1
-
-Bank 1:
-0: TIMER0
-1: TIMER1
-2: TIMER2
-3: TIMER3
-4: CODEC0
-5: CODEC1
-6: CODEC2
-7: VC_JPEG
-8: ISP
-9: VC_USB
-10: VC_3D
-11: TRANSPOSER
-12: MULTICORESYNC0
-13: MULTICORESYNC1
-14: MULTICORESYNC2
-15: MULTICORESYNC3
-16: DMA0
-17: DMA1
-18: VC_DMA2
-19: VC_DMA3
-20: DMA4
-21: DMA5
-22: DMA6
-23: DMA7
-24: DMA8
-25: DMA9
-26: DMA10
-27: DMA11-14 - shared interrupt for DMA 11 to 14
-28: DMAALL - triggers on all dma interrupts (including chanel 15)
-29: AUX
-30: ARM
-31: VPUDMA
-
-Bank 2:
-0: HOSTPORT
-1: VIDEOSCALER
-2: CCP2TX
-3: SDC
-4: DSI0
-5: AVE
-6: CAM0
-7: CAM1
-8: HDMI0
-9: HDMI1
-10: PIXELVALVE1
-11: I2CSPISLV
-12: DSI1
-13: PWA0
-14: PWA1
-15: CPR
-16: SMI
-17: GPIO0
-18: GPIO1
-19: GPIO2
-20: GPIO3
-21: VC_I2C
-22: VC_SPI
-23: VC_I2SPCM
-24: VC_SDIO
-25: VC_UART
-26: SLIMBUS
-27: VEC
-28: CPG
-29: RNG
-30: VC_ARASANSDIO
-31: AVSPMON
-
-Example:
-
-/* BCM2835, first level */
-intc: interrupt-controller {
- compatible = "brcm,bcm2835-armctrl-ic";
- reg = <0x7e00b200 0x200>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
-
-/* BCM2836, second level */
-intc: interrupt-controller {
- compatible = "brcm,bcm2836-armctrl-ic";
- reg = <0x7e00b200 0x200>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- interrupt-parent = <&local_intc>;
- interrupts = <8>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.yaml
new file mode 100644
index 000000000000..625eb22bedf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.yaml
@@ -0,0 +1,162 @@
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm2835-armctrl-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 ARMCTRL Interrupt Controller
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description: >
+ The BCM2835 contains a custom top-level interrupt controller, which supports
+ 72 interrupt sources using a 2-level register scheme. The interrupt
+ controller, or the HW block containing it, is referred to occasionally as
+ "armctrl" in the SoC documentation, hence naming of this binding.
+
+ The BCM2836 contains the same interrupt controller with the same interrupts,
+ but the per-CPU interrupt controller is the root, and an interrupt there
+ indicates that the ARMCTRL has an interrupt to handle.
+
+ The interrupt sources are as follows:
+
+ Bank 0:
+ 0: ARM_TIMER
+ 1: ARM_MAILBOX
+ 2: ARM_DOORBELL_0
+ 3: ARM_DOORBELL_1
+ 4: VPU0_HALTED
+ 5: VPU1_HALTED
+ 6: ILLEGAL_TYPE0
+ 7: ILLEGAL_TYPE1
+
+ Bank 1:
+ 0: TIMER0
+ 1: TIMER1
+ 2: TIMER2
+ 3: TIMER3
+ 4: CODEC0
+ 5: CODEC1
+ 6: CODEC2
+ 7: VC_JPEG
+ 8: ISP
+ 9: VC_USB
+ 10: VC_3D
+ 11: TRANSPOSER
+ 12: MULTICORESYNC0
+ 13: MULTICORESYNC1
+ 14: MULTICORESYNC2
+ 15: MULTICORESYNC3
+ 16: DMA0
+ 17: DMA1
+ 18: VC_DMA2
+ 19: VC_DMA3
+ 20: DMA4
+ 21: DMA5
+ 22: DMA6
+ 23: DMA7
+ 24: DMA8
+ 25: DMA9
+ 26: DMA10
+ 27: DMA11-14 - shared interrupt for DMA 11 to 14
+ 28: DMAALL - triggers on all dma interrupts (including channel 15)
+ 29: AUX
+ 30: ARM
+ 31: VPUDMA
+
+ Bank 2:
+ 0: HOSTPORT
+ 1: VIDEOSCALER
+ 2: CCP2TX
+ 3: SDC
+ 4: DSI0
+ 5: AVE
+ 6: CAM0
+ 7: CAM1
+ 8: HDMI0
+ 9: HDMI1
+ 10: PIXELVALVE1
+ 11: I2CSPISLV
+ 12: DSI1
+ 13: PWA0
+ 14: PWA1
+ 15: CPR
+ 16: SMI
+ 17: GPIO0
+ 18: GPIO1
+ 19: GPIO2
+ 20: GPIO3
+ 21: VC_I2C
+ 22: VC_SPI
+ 23: VC_I2SPCM
+ 24: VC_SDIO
+ 25: VC_UART
+ 26: SLIMBUS
+ 27: VEC
+ 28: CPG
+ 29: RNG
+ 30: VC_ARASANSDIO
+ 31: AVSPMON
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-armctrl-ic
+ - brcm,bcm2836-armctrl-ic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description: >
+ The 1st cell is the interrupt bank; 0 for interrupts in the "IRQ basic
+ pending" register, or 1/2 respectively for interrupts in the "IRQ pending
+ 1/2" register.
+
+ The 2nd cell contains the interrupt number within the bank. Valid values
+ are 0..7 for bank 0, and 0..31 for bank 1.
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm2836-armctrl-ic
+ then:
+ required:
+ - interrupts
+ else:
+ properties:
+ interrupts: false
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@7e00b200 {
+ compatible = "brcm,bcm2835-armctrl-ic";
+ reg = <0x7e00b200 0x200>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ - |
+ interrupt-controller@7e00b200 {
+ compatible = "brcm,bcm2836-armctrl-ic";
+ reg = <0x7e00b200 0x200>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <8>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
deleted file mode 100644
index 8ced1696c325..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-BCM2836 per-CPU interrupt controller
-
-The BCM2836 has a per-cpu interrupt controller for the timer, PMU
-events, and SMP IPIs. One of the CPUs may receive interrupts for the
-peripheral (GPU) events, which chain to the BCM2835-style interrupt
-controller.
-
-Required properties:
-
-- compatible: Should be "brcm,bcm2836-l1-intc"
-- reg: Specifies base physical address and size of the
- registers
-- interrupt-controller: Identifies the node as an interrupt controller
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value shall be 2
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-The interrupt sources are as follows:
-
-0: CNTPSIRQ
-1: CNTPNSIRQ
-2: CNTHPIRQ
-3: CNTVIRQ
-8: GPU_FAST
-9: PMU_FAST
-
-Example:
-
-local_intc: local_intc {
- compatible = "brcm,bcm2836-l1-intc";
- reg = <0x40000000 0x100>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <&local_intc>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.yaml
new file mode 100644
index 000000000000..2ff390c1705b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm2836-l1-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2836 per-CPU interrupt controller
+
+maintainers:
+ - Stefan Wahren <wahrenst@gmx.net>
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description:
+ The BCM2836 has a per-cpu interrupt controller for the timer, PMU
+ events, and SMP IPIs. One of the CPUs may receive interrupts for the
+ peripheral (GPU) events, which chain to the BCM2835-style interrupt
+ controller.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm2836-l1-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ local_intc: interrupt-controller@40000000 {
+ compatible = "brcm,bcm2836-l1-intc";
+ reg = <0x40000000 0x100>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&local_intc>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
deleted file mode 100644
index 2bc19b1ac877..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Broadcom BCM6345-style Level 1 interrupt controller
-
-This block is a first level interrupt controller that is typically connected
-directly to one of the HW INT lines on each CPU.
-
-Key elements of the hardware design include:
-
-- 32, 64 or 128 incoming level IRQ lines
-
-- Most onchip peripherals are wired directly to an L1 input
-
-- A separate instance of the register set for each CPU, allowing individual
- peripheral IRQs to be routed to any CPU
-
-- Contains one or more enable/status word pairs per CPU
-
-- No atomic set/clear operations
-
-- No polarity/level/edge settings
-
-- No FIFO or priority encoder logic; software is expected to read all
- 2-4 status words to determine which IRQs are pending
-
-Required properties:
-
-- compatible: should be "brcm,bcm<soc>-l1-intc", "brcm,bcm6345-l1-intc"
-- reg: specifies the base physical address and size of the registers;
- the number of supported IRQs is inferred from the size argument
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: specifies the number of cells needed to encode an interrupt
- source, should be 1.
-- interrupts: specifies the interrupt line(s) in the interrupt-parent controller
- node; valid values depend on the type of parent interrupt controller
-
-If multiple reg ranges and interrupt-parent entries are present on an SMP
-system, the driver will allow IRQ SMP affinity to be set up through the
-/proc/irq/ interface. In the simplest possible configuration, only one
-reg range and one interrupt-parent is needed.
-
-The driver operates in native CPU endian by default, there is no support for
-specifying an alternative endianness.
-
-Example:
-
-periph_intc: interrupt-controller@10000000 {
- compatible = "brcm,bcm63168-l1-intc", "brcm,bcm6345-l1-intc";
- reg = <0x10000020 0x20>,
- <0x10000040 0x20>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interrupt-parent = <&cpu_intc>;
- interrupts = <2>, <3>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.yaml
new file mode 100644
index 000000000000..ca6a2ff43acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm6345-l1-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM6345-style Level 1 interrupt controller
+
+maintainers:
+ - Simon Arlott <simon@octiron.net>
+
+description: >
+ This block is a first level interrupt controller that is typically connected
+ directly to one of the HW INT lines on each CPU.
+
+ Key elements of the hardware design include:
+
+ - 32, 64 or 128 incoming level IRQ lines
+
+ - Most onchip peripherals are wired directly to an L1 input
+
+ - A separate instance of the register set for each CPU, allowing individual
+ peripheral IRQs to be routed to any CPU
+
+ - Contains one or more enable/status word pairs per CPU
+
+ - No atomic set/clear operations
+
+ - No polarity/level/edge settings
+
+ - No FIFO or priority encoder logic; software is expected to read all
+ 2-4 status words to determine which IRQs are pending
+
+ If multiple reg ranges and interrupt-parent entries are present on an SMP
+ system, the driver will allow IRQ SMP affinity to be set up through the
+ /proc/irq/ interface. In the simplest possible configuration, only one
+ reg range and one interrupt-parent is needed.
+
+ The driver operates in native CPU endian by default, there is no support for
+ specifying an alternative endianness.
+
+properties:
+ compatible:
+ const: brcm,bcm6345-l1-intc
+
+ reg:
+ description: One entry per CPU core
+ minItems: 1
+ maxItems: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupts:
+ description: One entry per CPU core
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@10000000 {
+ compatible = "brcm,bcm6345-l1-intc";
+ reg = <0x10000020 0x20>,
+ <0x10000040 0x20>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupts = <2>, <3>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
index 46b2eb3c43ee..0fcbe304cd05 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml
@@ -59,7 +59,7 @@ description: >
..
31 ........................ X
- The BCM3380 Level 1 / Level 2 interrrupt controller shows up in various forms
+ The BCM3380 Level 1 / Level 2 interrupt controller shows up in various forms
on many BCM338x/BCM63xx chipsets. It has the following properties:
- outputs a single interrupt signal to its interrupt controller parent
@@ -109,7 +109,8 @@ properties:
for system suspend/resume.
brcm,int-fwd-mask:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: >
if present, a bit mask to configure the interrupts which have a mux gate,
typically UARTs. Setting these bits will make their respective interrupt
@@ -129,23 +130,23 @@ required:
examples:
- |
irq0_intc: interrupt-controller@f0406800 {
- compatible = "brcm,bcm7120-l2-intc";
- interrupt-parent = <&intc>;
- #interrupt-cells = <1>;
- reg = <0xf0406800 0x8>;
- interrupt-controller;
- interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>;
- brcm,int-map-mask = <0xeb8>, <0x140>;
- brcm,int-fwd-mask = <0x7>;
+ compatible = "brcm,bcm7120-l2-intc";
+ interrupt-parent = <&intc>;
+ #interrupt-cells = <1>;
+ reg = <0xf0406800 0x8>;
+ interrupt-controller;
+ interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>;
+ brcm,int-map-mask = <0xeb8>, <0x140>;
+ brcm,int-fwd-mask = <0x7>;
};
- |
irq1_intc: interrupt-controller@10000020 {
- compatible = "brcm,bcm3380-l2-intc";
- reg = <0x10000024 0x4>, <0x1000002c 0x4>,
- <0x10000020 0x4>, <0x10000028 0x4>;
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupt-parent = <&cpu_intc>;
- interrupts = <2>;
+ compatible = "brcm,bcm3380-l2-intc";
+ reg = <0x10000024 0x4>, <0x1000002c 0x4>,
+ <0x10000020 0x4>, <0x10000028 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <2>;
};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-mx.txt b/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-mx.txt
deleted file mode 100644
index d4de980e55fa..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-mx.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Xtensa Interrupt Distributor and Programmable Interrupt Controller (MX)
-
-Required properties:
-- compatible: Should be "cdns,xtensa-mx".
-
-Remaining properties have exact same meaning as in Xtensa PIC
-(see cdns,xtensa-pic.txt).
-
-Examples:
- pic: pic {
- compatible = "cdns,xtensa-mx";
- /* one cell: internal irq number,
- * two cells: second cell == 0: internal irq number
- * second cell == 1: external irq number
- */
- #interrupt-cells = <2>;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.txt
deleted file mode 100644
index 026ef4cfc1d5..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Xtensa built-in Programmable Interrupt Controller (PIC)
-
-Required properties:
-- compatible: Should be "cdns,xtensa-pic".
-- interrupt-controller: Identifies the node as an interrupt controller.
-- #interrupt-cells: The number of cells to define the interrupts.
- It may be either 1 or 2.
- When it's 1, the first cell is the internal IRQ number.
- When it's 2, the first cell is the IRQ number, and the second cell
- specifies whether it's internal (0) or external (1).
- Periferals are usually connected to a fixed external IRQ, but for different
- core variants it may be mapped to different internal IRQ.
- IRQ sensitivity and priority are fixed for each core variant and may not be
- changed at runtime.
-
-Examples:
- pic: pic {
- compatible = "cdns,xtensa-pic";
- /* one cell: internal irq number,
- * two cells: second cell == 0: internal irq number
- * second cell == 1: external irq number
- */
- #interrupt-cells = <2>;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.yaml
new file mode 100644
index 000000000000..6773207fee01
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/cdns,xtensa-pic.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Max Filippov <jcmvbkbc@gmail.com>
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/cdns,xtensa-pic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xtensa Interrupt Controllers
+
+maintainers:
+ - Max Filippov <jcmvbkbc@gmail.com>
+
+description:
+ Xtensa Interrupt Distributor and Programmable Interrupt Controller (MX) and
+ Xtensa built-in Programmable Interrupt Controller (PIC)
+
+properties:
+ compatible:
+ enum:
+ - cdns,xtensa-mx
+ - cdns,xtensa-pic
+
+ '#interrupt-cells':
+ enum: [ 1, 2 ]
+ description:
+ Number of cells to define the interrupts. When 1, the first cell is the
+ internal IRQ number; when 2, the second cell specifies internal (0) or
+ external (1).
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "cdns,xtensa-pic";
+ /* one cell: internal irq number,
+ * two cells: second cell == 0: internal irq number
+ * second cell == 1: external irq number
+ */
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/chrp,open-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/chrp,open-pic.yaml
new file mode 100644
index 000000000000..642738512f3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/chrp,open-pic.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/chrp,open-pic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Open PIC Interrupt Controller
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+description:
+ This binding specifies what properties must be available in the device tree
+ representation of an Open PIC compliant interrupt controller. This binding is
+ based on the binding defined for Open PIC in [1] and is a superset of that
+ binding.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,mpic
+ - const: chrp,open-pic
+ - const: chrp,open-pic
+
+ device_type:
+ const: open-pci
+ deprecated: true
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#address-cells':
+ const: 0
+
+ '#interrupt-cells':
+ description:
+ A value of 4 means that interrupt specifiers contain the interrupt-type or
+ type-specific information cells.
+ enum: [ 2, 4 ]
+
+ pic-no-reset:
+ description: Indicates the PIC shall not be reset during runtime initialization.
+ type: boolean
+
+ single-cpu-affinity:
+ description:
+ If present, non-IPI interrupts will be routed to a single CPU at a time.
+ type: boolean
+
+ last-interrupt-source:
+ description:
+ Some MPICs do not correctly report the number of hardware sources in the
+ global feature registers. This value, if specified, overrides the value
+ read from MPIC_GREG_FEATURE_LAST_SRC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#address-cells'
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@40000 {
+ compatible = "chrp,open-pic";
+ reg = <0x40000 0x40000>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ pic-no-reset;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
deleted file mode 100644
index 969b4582ec60..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Cirrus Logic CLPS711X Interrupt Controller
-
-Required properties:
-
-- compatible: Should be "cirrus,ep7209-intc".
-- reg: Specifies base physical address of the registers set.
-- interrupt-controller: Identifies the node as an interrupt controller.
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-The interrupt sources are as follows:
-ID Name Description
----------------------------
-1: BLINT Battery low (FIQ)
-3: MCINT Media changed (FIQ)
-4: CSINT CODEC sound
-5: EINT1 External 1
-6: EINT2 External 2
-7: EINT3 External 3
-8: TC1OI TC1 under flow
-9: TC2OI TC2 under flow
-10: RTCMI RTC compare match
-11: TINT 64Hz tick
-12: UTXINT1 UART1 transmit FIFO half empty
-13: URXINT1 UART1 receive FIFO half full
-14: UMSINT UART1 modem status changed
-15: SSEOTI SSI1 end of transfer
-16: KBDINT Keyboard
-17: SS2RX SSI2 receive FIFO half or greater full
-18: SS2TX SSI2 transmit FIFO less than half empty
-28: UTXINT2 UART2 transmit FIFO half empty
-29: URXINT2 UART2 receive FIFO half full
-32: DAIINT DAI interface (FIQ)
-
-Example:
- intc: interrupt-controller {
- compatible = "cirrus,ep7312-intc", "cirrus,ep7209-intc";
- reg = <0x80000000 0x4000>;
- interrupt-controller;
- #interrupt-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,ep7209-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/cirrus,ep7209-intc.yaml
new file mode 100644
index 000000000000..d3cc49d29e10
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,ep7209-intc.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/cirrus,ep7209-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CLPS711X Interrupt Controller
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+description: >
+ Cirrus Logic CLPS711X Interrupt Controller
+
+ The interrupt sources are as follows:
+ ID Name Description
+ ---------------------------
+ 1: BLINT Battery low (FIQ)
+ 3: MCINT Media changed (FIQ)
+ 4: CSINT CODEC sound
+ 5: EINT1 External 1
+ 6: EINT2 External 2
+ 7: EINT3 External 3
+ 8: TC1OI TC1 under flow
+ 9: TC2OI TC2 under flow
+ 10: RTCMI RTC compare match
+ 11: TINT 64Hz tick
+ 12: UTXINT1 UART1 transmit FIFO half empty
+ 13: URXINT1 UART1 receive FIFO half full
+ 14: UMSINT UART1 modem status changed
+ 15: SSEOTI SSI1 end of transfer
+ 16: KBDINT Keyboard
+ 17: SS2RX SSI2 receive FIFO half or greater full
+ 18: SS2TX SSI2 transmit FIFO less than half empty
+ 28: UTXINT2 UART2 transmit FIFO half empty
+ 29: URXINT2 UART2 receive FIFO half full
+ 32: DAIINT DAI interface (FIQ)
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: cirrus,ep7312-intc
+ - const: cirrus,ep7209-intc
+ - items:
+ - const: cirrus,ep7209-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@80000000 {
+ compatible = "cirrus,ep7312-intc", "cirrus,ep7209-intc";
+ reg = <0x80000000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cnxt,cx92755-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/cnxt,cx92755-ic.yaml
new file mode 100644
index 000000000000..3f016cf47812
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/cnxt,cx92755-ic.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/cnxt,cx92755-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Conexant Digicolor Interrupt Controller
+
+maintainers:
+ - Baruch Siach <baruch@tkos.co.il>
+
+description: Conexant Digicolor Interrupt Controller
+
+properties:
+ compatible:
+ const: cnxt,cx92755-ic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ syscon:
+ description: A phandle to the syscon node describing UC registers
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@f0000040 {
+ compatible = "cnxt,cx92755-ic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0xf0000040 0x40>;
+ syscon = <&uc_regs>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
deleted file mode 100644
index 44286dcbac62..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-==============================
-C-SKY APB Interrupt Controller
-==============================
-
-C-SKY APB Interrupt Controller is a simple soc interrupt controller
-on the apb bus and we only use it as root irq controller.
-
- - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq nums.
- - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported.
- - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq nums.
-
-=============================
-intc node bindings definition
-=============================
-
- Description: Describes APB interrupt controller
-
- PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: must be "csky,apb-intc"
- "csky,dual-apb-intc"
- "csky,gx6605s-intc"
- - #interrupt-cells
- Usage: required
- Value type: <u32>
- Definition: must be <1>
- - reg
- Usage: required
- Value type: <u32 u32>
- Definition: <phyaddr size> in soc from cpu view
- - interrupt-controller:
- Usage: required
- - csky,support-pulse-signal:
- Usage: select
- Description: to support pulse signal flag
-
-Examples:
----------
-
- intc: interrupt-controller@500000 {
- compatible = "csky,apb-intc";
- #interrupt-cells = <1>;
- reg = <0x00500000 0x400>;
- interrupt-controller;
- };
-
- intc: interrupt-controller@500000 {
- compatible = "csky,dual-apb-intc";
- #interrupt-cells = <1>;
- reg = <0x00500000 0x400>;
- interrupt-controller;
- };
-
- intc: interrupt-controller@500000 {
- compatible = "csky,gx6605s-intc";
- #interrupt-cells = <1>;
- reg = <0x00500000 0x400>;
- interrupt-controller;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.yaml
new file mode 100644
index 000000000000..902648ead975
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/csky,apb-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: C-SKY APB Interrupt Controller
+
+maintainers:
+ - Guo Ren <guoren@kernel.org>
+
+description: >
+ C-SKY APB Interrupt Controller is a simple soc interrupt controller on the apb
+ bus and we only use it as root irq controller.
+
+ - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq nums.
+ - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported.
+ - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq nums.
+
+properties:
+ compatible:
+ enum:
+ - csky,apb-intc
+ - csky,dual-apb-intc
+ - csky,gx6605s-intc
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+ csky,support-pulse-signal:
+ type: boolean
+ description: Support for pulse signal flag.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+
+examples:
+ - |
+ intc: interrupt-controller@500000 {
+ compatible = "csky,apb-intc";
+ #interrupt-cells = <1>;
+ reg = <0x00500000 0x400>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
deleted file mode 100644
index e6bbcae4d07f..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-===========================================
-C-SKY Multi-processors Interrupt Controller
-===========================================
-
-C-SKY Multi-processors Interrupt Controller is designed for ck807/ck810/ck860
-SMP soc, and it also could be used in non-SMP system.
-
-Interrupt number definition:
- 0-15 : software irq, and we use 15 as our IPI_IRQ.
- 16-31 : private irq, and we use 16 as the co-processor timer.
- 31-1024: common irq for soc ip.
-
-Interrupt trigger mode: (Defined in dt-bindings/interrupt-controller/irq.h)
- IRQ_TYPE_LEVEL_HIGH (default)
- IRQ_TYPE_LEVEL_LOW
- IRQ_TYPE_EDGE_RISING
- IRQ_TYPE_EDGE_FALLING
-
-=============================
-intc node bindings definition
-=============================
-
- Description: Describes SMP interrupt controller
-
- PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: must be "csky,mpintc"
- - #interrupt-cells
- Usage: required
- Value type: <u32>
- Definition: <2>
- - interrupt-controller:
- Usage: required
-
-Examples: ("interrupts = <irq_num IRQ_TYPE_XXX>")
----------
-#include <dt-bindings/interrupt-controller/irq.h>
-
- intc: interrupt-controller {
- compatible = "csky,mpintc";
- #interrupt-cells = <2>;
- interrupt-controller;
- };
-
- device: device-example {
- ...
- interrupts = <34 IRQ_TYPE_EDGE_RISING>;
- interrupt-parent = <&intc>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.yaml b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.yaml
new file mode 100644
index 000000000000..3df7739e31c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/csky,mpintc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: C-SKY Multi-processors Interrupt Controller
+
+maintainers:
+ - Guo Ren <guoren@kernel.org>
+
+description: >
+ C-SKY Multi-processors Interrupt Controller is designed for ck807/ck810/ck860
+ SMP soc, and it also could be used in non-SMP system.
+
+ Interrupt number definition:
+ 0-15 : software irq, and we use 15 as our IPI_IRQ.
+ 16-31 : private irq, and we use 16 as the co-processor timer.
+ 31-1024: common irq for soc ip.
+
+properties:
+ compatible:
+ const: csky,mpintc
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - "#interrupt-cells"
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "csky,mpintc";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/digicolor-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/digicolor-ic.txt
deleted file mode 100644
index 42d41ec84c7b..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/digicolor-ic.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Conexant Digicolor Interrupt Controller
-
-Required properties:
-
-- compatible : should be "cnxt,cx92755-ic"
-- reg : Specifies base physical address and size of the interrupt controller
- registers (IC) area
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-- syscon: A phandle to the syscon node describing UC registers
-
-Example:
-
- intc: interrupt-controller@f0000040 {
- compatible = "cnxt,cx92755-ic";
- interrupt-controller;
- #interrupt-cells = <1>;
- reg = <0xf0000040 0x40>;
- syscon = <&uc_regs>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/econet,en751221-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/econet,en751221-intc.yaml
new file mode 100644
index 000000000000..5536319c49c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/econet,en751221-intc.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/econet,en751221-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet EN751221 Interrupt Controller
+
+maintainers:
+ - Caleb James DeLisle <cjd@cjdns.fr>
+
+description:
+ The EcoNet EN751221 Interrupt Controller is a simple interrupt controller
+ designed for the MIPS 34Kc MT SMP processor with 2 VPEs. Each interrupt can
+ be routed to either VPE but not both, so to support per-CPU interrupts, a
+ secondary IRQ number is allocated to control masking/unmasking on VPE#1. For
+ lack of a better term we call these "shadow interrupts". The assignment of
+ shadow interrupts is defined by the SoC integrator when wiring the interrupt
+ lines, so they are configurable in the device tree.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ const: econet,en751221-intc
+
+ reg:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+ description: Interrupt line connecting this controller to its parent.
+
+ econet,shadow-interrupts:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ An array of interrupt number pairs where each pair represents a shadow
+ interrupt relationship. The first number in each pair is the primary IRQ,
+ and the second is its shadow IRQ used for VPE#1 control. For example,
+ <8 3> means IRQ 8 is shadowed by IRQ 3, so IRQ 3 cannot be mapped, but
+ when VPE#1 requests IRQ 8, it will manipulate the IRQ 3 mask bit.
+ minItems: 1
+ maxItems: 20
+ items:
+ items:
+ - description: primary per-CPU IRQ
+ - description: shadow IRQ number
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1fb40000 {
+ compatible = "econet,en751221-intc";
+ reg = <0x1fb40000 0x100>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <2>;
+
+ econet,shadow-interrupts = <7 2>, <8 3>, <13 12>, <30 29>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.txt
deleted file mode 100644
index 888b2b9f7064..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-EZchip NPS Interrupt Controller
-
-Required properties:
-
-- compatible : should be "ezchip,nps400-ic"
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-
-Example:
-
-intc: interrupt-controller {
- compatible = "ezchip,nps400-ic";
- interrupt-controller;
- #interrupt-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.yaml
new file mode 100644
index 000000000000..589c6ebf6c1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ezchip,nps400-ic.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ezchip,nps400-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EZchip NPS Interrupt Controller
+
+maintainers:
+ - Noam Camus <noamc@ezchip.com>
+
+properties:
+ compatible:
+ const: ezchip,nps400-ic
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "ezchip,nps400-ic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.txt b/Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.txt
deleted file mode 100644
index 24428d47f487..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Faraday Technologt FTINTC010 interrupt controller
-
-This interrupt controller is a stock IP block from Faraday Technology found
-in the Gemini SoCs and other designs.
-
-Required properties:
-- compatible: must be one of
- "faraday,ftintc010"
- "cortina,gemini-interrupt-controller" (deprecated)
-- reg: The register bank for the interrupt controller.
-- interrupt-controller: Identifies the node as an interrupt controller
-- #interrupt-cells: The number of cells to define the interrupts.
- Must be 2 as the controller can specify level or rising edge
- IRQs. The bindings follows the standard binding for controllers
- with two cells specified in
- interrupt-controller/interrupts.txt
-
-Example:
-
-interrupt-controller@48000000 {
- compatible = "faraday,ftintc010"
- reg = <0x48000000 0x1000>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.yaml b/Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.yaml
new file mode 100644
index 000000000000..980e5c45f25b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/faraday,ftintc010.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+---
+$id: http://devicetree.org/schemas/interrupt-controller/faraday,ftintc010.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday Technology FTINTC010 interrupt controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ This interrupt controller is a stock IP block from Faraday Technology found
+ in the Gemini SoCs and other designs.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: moxa,moxart-ic
+ - const: faraday,ftintc010
+ - enum:
+ - faraday,ftintc010
+ - cortina,gemini-interrupt-controller
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@48000000 {
+ compatible = "faraday,ftintc010";
+ reg = <0x48000000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,icoll.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,icoll.yaml
new file mode 100644
index 000000000000..7b09fd7d588f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,icoll.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,icoll.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS icoll Interrupt controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx23-icoll
+ - fsl,imx28-icoll
+ - const: fsl,icoll
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@80000000 {
+ compatible = "fsl,imx28-icoll", "fsl,icoll";
+ reg = <0x80000000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,imx8qxp-dc-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,imx8qxp-dc-intc.yaml
new file mode 100644
index 000000000000..6985ee644a25
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,imx8qxp-dc-intc.yaml
@@ -0,0 +1,318 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,imx8qxp-dc-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Display Controller interrupt controller
+
+description: |
+ The Display Controller has a built-in interrupt controller with the following
+ features for all relevant HW events:
+
+ * Enable bit (mask)
+ * Status bit (set by an HW event)
+ * Preset bit (can be used by SW to set status)
+ * Clear bit (used by SW to reset the status)
+
+ Each interrupt can be connected as IRQ (maskable) and/or NMI (non-maskable).
+ Alternatively the un-masked trigger signals for all HW events are provided,
+ allowing it to use a global interrupt controller instead.
+
+ Each interrupt can be protected against SW running in user mode. In that case,
+ only privileged AHB access can control the interrupt status.
+
+maintainers:
+ - Liu Ying <victor.liu@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qxp-dc-intc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupts:
+ items:
+ - description: store9 shadow load interrupt(blit engine)
+ - description: store9 frame complete interrupt(blit engine)
+ - description: store9 sequence complete interrupt(blit engine)
+ - description:
+ extdst0 shadow load interrupt
+ (display controller, content stream 0)
+ - description:
+ extdst0 frame complete interrupt
+ (display controller, content stream 0)
+ - description:
+ extdst0 sequence complete interrupt
+ (display controller, content stream 0)
+ - description:
+ extdst4 shadow load interrupt
+ (display controller, safety stream 0)
+ - description:
+ extdst4 frame complete interrupt
+ (display controller, safety stream 0)
+ - description:
+ extdst4 sequence complete interrupt
+ (display controller, safety stream 0)
+ - description:
+ extdst1 shadow load interrupt
+ (display controller, content stream 1)
+ - description:
+ extdst1 frame complete interrupt
+ (display controller, content stream 1)
+ - description:
+ extdst1 sequence complete interrupt
+ (display controller, content stream 1)
+ - description:
+ extdst5 shadow load interrupt
+ (display controller, safety stream 1)
+ - description:
+ extdst5 frame complete interrupt
+ (display controller, safety stream 1)
+ - description:
+ extdst5 sequence complete interrupt
+ (display controller, safety stream 1)
+ - description:
+ disengcfg0 shadow load interrupt
+ (display controller, display stream 0)
+ - description:
+ disengcfg0 frame complete interrupt
+ (display controller, display stream 0)
+ - description:
+ disengcfg0 sequence complete interrupt
+ (display controller, display stream 0)
+ - description:
+ framegen0 programmable interrupt0
+ (display controller, display stream 0)
+ - description:
+ framegen0 programmable interrupt1
+ (display controller, display stream 0)
+ - description:
+ framegen0 programmable interrupt2
+ (display controller, display stream 0)
+ - description:
+ framegen0 programmable interrupt3
+ (display controller, display stream 0)
+ - description:
+ signature0 shadow load interrupt
+ (display controller, display stream 0)
+ - description:
+ signature0 measurement valid interrupt
+ (display controller, display stream 0)
+ - description:
+ signature0 error condition interrupt
+ (display controller, display stream 0)
+ - description:
+ disengcfg1 shadow load interrupt
+ (display controller, display stream 1)
+ - description:
+ disengcfg1 frame complete interrupt
+ (display controller, display stream 1)
+ - description:
+ disengcfg1 sequence complete interrupt
+ (display controller, display stream 1)
+ - description:
+ framegen1 programmable interrupt0
+ (display controller, display stream 1)
+ - description:
+ framegen1 programmable interrupt1
+ (display controller, display stream 1)
+ - description:
+ framegen1 programmable interrupt2
+ (display controller, display stream 1)
+ - description:
+ framegen1 programmable interrupt3
+ (display controller, display stream 1)
+ - description:
+ signature1 shadow load interrupt
+ (display controller, display stream 1)
+ - description:
+ signature1 measurement valid interrupt
+ (display controller, display stream 1)
+ - description:
+ signature1 error condition interrupt
+ (display controller, display stream 1)
+ - description: reserved
+ - description:
+ command sequencer error condition interrupt(command sequencer)
+ - description:
+ common control software interrupt0(common control)
+ - description:
+ common control software interrupt1(common control)
+ - description:
+ common control software interrupt2(common control)
+ - description:
+ common control software interrupt3(common control)
+ - description:
+ framegen0 synchronization status activated interrupt
+ (display controller, safety stream 0)
+ - description:
+ framegen0 synchronization status deactivated interrupt
+ (display controller, safety stream 0)
+ - description:
+ framegen0 synchronization status activated interrupt
+ (display controller, content stream 0)
+ - description:
+ framegen0 synchronization status deactivated interrupt
+ (display controller, content stream 0)
+ - description:
+ framegen1 synchronization status activated interrupt
+ (display controller, safety stream 1)
+ - description:
+ framegen1 synchronization status deactivated interrupt
+ (display controller, safety stream 1)
+ - description:
+ framegen1 synchronization status activated interrupt
+ (display controller, content stream 1)
+ - description:
+ framegen1 synchronization status deactivated interrupt
+ (display controller, content stream 1)
+ minItems: 49
+
+ interrupt-names:
+ items:
+ - const: store9_shdload
+ - const: store9_framecomplete
+ - const: store9_seqcomplete
+ - const: extdst0_shdload
+ - const: extdst0_framecomplete
+ - const: extdst0_seqcomplete
+ - const: extdst4_shdload
+ - const: extdst4_framecomplete
+ - const: extdst4_seqcomplete
+ - const: extdst1_shdload
+ - const: extdst1_framecomplete
+ - const: extdst1_seqcomplete
+ - const: extdst5_shdload
+ - const: extdst5_framecomplete
+ - const: extdst5_seqcomplete
+ - const: disengcfg_shdload0
+ - const: disengcfg_framecomplete0
+ - const: disengcfg_seqcomplete0
+ - const: framegen0_int0
+ - const: framegen0_int1
+ - const: framegen0_int2
+ - const: framegen0_int3
+ - const: sig0_shdload
+ - const: sig0_valid
+ - const: sig0_error
+ - const: disengcfg_shdload1
+ - const: disengcfg_framecomplete1
+ - const: disengcfg_seqcomplete1
+ - const: framegen1_int0
+ - const: framegen1_int1
+ - const: framegen1_int2
+ - const: framegen1_int3
+ - const: sig1_shdload
+ - const: sig1_valid
+ - const: sig1_error
+ - const: reserved
+ - const: cmdseq_error
+ - const: comctrl_sw0
+ - const: comctrl_sw1
+ - const: comctrl_sw2
+ - const: comctrl_sw3
+ - const: framegen0_primsync_on
+ - const: framegen0_primsync_off
+ - const: framegen0_secsync_on
+ - const: framegen0_secsync_off
+ - const: framegen1_primsync_on
+ - const: framegen1_primsync_off
+ - const: framegen1_secsync_on
+ - const: framegen1_secsync_off
+ minItems: 49
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupt-controller
+ - "#interrupt-cells"
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+
+ interrupt-controller@56180040 {
+ compatible = "fsl,imx8qxp-dc-intc";
+ reg = <0x56180040 0x60>;
+ clocks = <&dc0_lpcg IMX_LPCG_CLK_5>;
+ interrupt-controller;
+ interrupt-parent = <&dc0_irqsteer>;
+ #interrupt-cells = <1>;
+ interrupts = <448>, <449>, <450>, <64>,
+ <65>, <66>, <67>, <68>,
+ <69>, <70>, <193>, <194>,
+ <195>, <196>, <197>, <72>,
+ <73>, <74>, <75>, <76>,
+ <77>, <78>, <79>, <80>,
+ <81>, <199>, <200>, <201>,
+ <202>, <203>, <204>, <205>,
+ <206>, <207>, <208>, <5>,
+ <0>, <1>, <2>, <3>,
+ <4>, <82>, <83>, <84>,
+ <85>, <209>, <210>, <211>,
+ <212>;
+ interrupt-names = "store9_shdload",
+ "store9_framecomplete",
+ "store9_seqcomplete",
+ "extdst0_shdload",
+ "extdst0_framecomplete",
+ "extdst0_seqcomplete",
+ "extdst4_shdload",
+ "extdst4_framecomplete",
+ "extdst4_seqcomplete",
+ "extdst1_shdload",
+ "extdst1_framecomplete",
+ "extdst1_seqcomplete",
+ "extdst5_shdload",
+ "extdst5_framecomplete",
+ "extdst5_seqcomplete",
+ "disengcfg_shdload0",
+ "disengcfg_framecomplete0",
+ "disengcfg_seqcomplete0",
+ "framegen0_int0",
+ "framegen0_int1",
+ "framegen0_int2",
+ "framegen0_int3",
+ "sig0_shdload",
+ "sig0_valid",
+ "sig0_error",
+ "disengcfg_shdload1",
+ "disengcfg_framecomplete1",
+ "disengcfg_seqcomplete1",
+ "framegen1_int0",
+ "framegen1_int1",
+ "framegen1_int2",
+ "framegen1_int3",
+ "sig1_shdload",
+ "sig1_valid",
+ "sig1_error",
+ "reserved",
+ "cmdseq_error",
+ "comctrl_sw0",
+ "comctrl_sw1",
+ "comctrl_sw2",
+ "comctrl_sw3",
+ "framegen0_primsync_on",
+ "framegen0_primsync_off",
+ "framegen0_secsync_on",
+ "framegen0_secsync_off",
+ "framegen1_primsync_on",
+ "framegen1_primsync_off",
+ "framegen1_secsync_on",
+ "framegen1_secsync_off";
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,intmux.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,intmux.yaml
index 1d6e0f64a807..78baa0a571cf 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,intmux.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,intmux.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale INTMUX interrupt multiplexer
maintainers:
- - Joakim Zhang <qiangqing.zhang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - NXP Linux Team <linux-imx@nxp.com>
properties:
compatible:
@@ -36,6 +37,9 @@ properties:
clock-names:
const: ipg
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
index bcb5e20fa9ca..5c768c1e159c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
@@ -14,7 +14,13 @@ properties:
oneOf:
- const: fsl,imx-irqsteer
- items:
- - const: fsl,imx8m-irqsteer
+ - enum:
+ - fsl,imx8m-irqsteer
+ - fsl,imx8mp-irqsteer
+ - fsl,imx8qm-irqsteer
+ - fsl,imx8qxp-irqsteer
+ - fsl,imx94-irqsteer
+ - fsl,imx95-irqsteer
- const: fsl,imx-irqsteer
reg:
@@ -42,19 +48,22 @@ properties:
clock-names:
const: ipg
+ power-domains:
+ maxItems: 1
+
interrupt-controller: true
"#interrupt-cells":
const: 1
fsl,channel:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
u32 value representing the output channel that all input IRQs should be
steered into.
fsl,num-irqs:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
u32 value representing the number of input interrupts of this channel,
should be multiple of 32 input interrupts and up to 512 interrupts.
@@ -70,6 +79,23 @@ required:
- fsl,channel
- fsl,num-irqs
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mp-irqsteer
+ - fsl,imx8qm-irqsteer
+ - fsl,imx8qxp-irqsteer
+ - fsl,imx95-irqsteer
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
index 887e565b9573..7ff4efc4758a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
@@ -8,7 +8,6 @@ title: Freescale Layerscape External Interrupt Controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Li Yang <leoyang.li@nxp.com>
description: |
Some Layerscape SOCs (LS1021A, LS1043A, LS1046A LS1088A, LS208xA,
@@ -83,9 +82,6 @@ allOf:
enum:
- fsl,ls1043a-extirq
- fsl,ls1046a-extirq
- - fsl,ls1088a-extirq
- - fsl,ls2080a-extirq
- - fsl,lx2160a-extirq
then:
properties:
interrupt-map:
@@ -96,6 +92,29 @@ allOf:
- const: 0xf
- 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
examples:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-msi.yaml
new file mode 100644
index 000000000000..9ba8d4d73351
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-msi.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,ls-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape SCFG PCIe MSI controller
+
+description: |
+ This interrupt controller hardware is a second level interrupt controller that
+ is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based
+ platforms. If interrupt-parent is not provided, the default parent interrupt
+ controller will be used.
+
+ Each PCIe node needs to have property msi-parent that points to
+ MSI controller node
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls1012a-msi
+ - fsl,ls1021a-msi
+ - fsl,ls1043a-msi
+ - fsl,ls1043a-v1.1-msi
+ - fsl,ls1046a-msi
+
+ reg:
+ maxItems: 1
+
+ '#msi-cells':
+ const: 1
+
+ interrupts:
+ items:
+ - description: Shared MSI interrupt group 0
+ - description: Shared MSI interrupt group 1
+ - description: Shared MSI interrupt group 2
+ - description: Shared MSI interrupt group 3
+ minItems: 1
+
+required:
+ - compatible
+ - reg
+ - msi-controller
+ - interrupts
+
+allOf:
+ - $ref: msi-controller.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,ls1046a-msi
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@1571000 {
+ compatible = "fsl,ls1043a-msi";
+ reg = <0x1571000 0x8>;
+ msi-controller;
+ #msi-cells = <1>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
deleted file mode 100644
index 454ce04d6787..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Freescale Layerscape SCFG PCIe MSI controller
-
-Required properties:
-
-- compatible: should be "fsl,<soc-name>-msi" to identify
- Layerscape PCIe MSI controller block such as:
- "fsl,ls1021a-msi"
- "fsl,ls1043a-msi"
- "fsl,ls1046a-msi"
- "fsl,ls1043a-v1.1-msi"
- "fsl,ls1012a-msi"
-- msi-controller: indicates that this is a PCIe MSI controller node
-- reg: physical base address of the controller and length of memory mapped.
-- interrupts: an interrupt to the parent interrupt controller.
-
-This interrupt controller hardware is a second level interrupt controller that
-is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based
-platforms. If interrupt-parent is not provided, the default parent interrupt
-controller will be used.
-Each PCIe node needs to have property msi-parent that points to
-MSI controller node
-
-Examples:
-
- msi1: msi-controller@1571000 {
- compatible = "fsl,ls1043a-msi";
- reg = <0x0 0x1571000 0x0 0x8>,
- msi-controller;
- interrupts = <0 116 0x4>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml
new file mode 100644
index 000000000000..78d784973661
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,mpic-msi.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,mpic-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MSI interrupt controller
+
+description: |
+ The Freescale hypervisor and msi-address-64
+ -------------------------------------------
+
+ Normally, PCI devices have access to all of CCSR via an ATMU mapping. The
+ Freescale MSI driver calculates the address of MSIIR (in the MSI register
+ block) and sets that address as the MSI message address.
+
+ In a virtualized environment, the hypervisor may need to create an IOMMU
+ mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement
+ because of hardware limitations of the Peripheral Access Management Unit
+ (PAMU), which is currently the only IOMMU that the hypervisor supports.
+ The ATMU is programmed with the guest physical address, and the PAMU
+ intercepts transactions and reroutes them to the true physical address.
+
+ In the PAMU, each PCI controller is given only one primary window. The
+ PAMU restricts DMA operations so that they can only occur within a window.
+ Because PCI devices must be able to DMA to memory, the primary window must
+ be used to cover all of the guest's memory space.
+
+ PAMU primary windows can be divided into 256 subwindows, and each
+ subwindow can have its own address mapping ("guest physical" to "true
+ physical"). However, each subwindow has to have the same alignment, which
+ means they cannot be located at just any address. Because of these
+ restrictions, it is usually impossible to create a 4KB subwindow that
+ covers MSIIR where it's normally located.
+
+ Therefore, the hypervisor has to create a subwindow inside the same
+ primary window used for memory, but mapped to the MSIR block (where MSIIR
+ lives). The first subwindow after the end of guest memory is used for
+ this. The address specified in the msi-address-64 property is the PCI
+ address of MSIIR. The hypervisor configures the PAMU to map that address to
+ the true physical address of MSIIR.
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,mpic-msi
+ - fsl,mpic-msi-v4.3
+ - fsl,ipic-msi
+ - fsl,vmpic-msi
+ - fsl,vmpic-msi-v4.3
+ - items:
+ - enum:
+ - fsl,mpc8572-msi
+ - fsl,mpc8610-msi
+ - fsl,mpc8641-msi
+ - const: fsl,mpic-msi
+
+ reg:
+ minItems: 1
+ items:
+ - description: Address and length of the shared message interrupt
+ register set
+ - description: Address of aliased MSIIR or MSIIR1 register for platforms
+ that have such an alias. If using MSIIR1, the second region must be
+ added because different MSI group has different MSIIR1 offset.
+
+ interrupts:
+ minItems: 1
+ maxItems: 16
+ description:
+ Each one of the interrupts here is one entry per 32 MSIs, and routed to
+ the host interrupt controller. The interrupts should be set as edge
+ sensitive. If msi-available-ranges is present, only the interrupts that
+ correspond to available ranges shall be present.
+
+ msi-available-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: First MSI interrupt in this range
+ - description: Number of MSI interrupts in this range
+ description:
+ Define which MSI interrupt can be used in the 256 MSI interrupts.
+ If not specified, all the MSI interrupts can be used.
+ Each available range must begin and end on a multiple of 32 (i.e. no
+ splitting an individual MSI register or the associated PIC interrupt).
+
+ msi-address-64:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ 64-bit PCI address of the MSIIR register. The MSIIR register is used for
+ MSI messaging. The address of MSIIR in PCI address space is the MSI
+ message address.
+
+ This property may be used in virtualized environments where the hypervisor
+ has created an alternate mapping for the MSIR block. See the top-level
+ description for an explanation.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,mpic-msi-v4.3
+ - fsl,vmpic-msi-v4.3
+ then:
+ properties:
+ interrupts:
+ minItems: 16
+ description:
+ Version 4.3 implies that there are 16 shared interrupts, and they
+ are configured through MSIIR1.
+
+ # MPIC v4.3 does not support this property because the 32 interrupts of
+ # an individual register are not continuous when using MSIIR1.
+ msi-available-ranges: false
+
+ reg:
+ minItems: 2
+
+ else:
+ properties:
+ interrupts:
+ maxItems: 8
+ description:
+ In versions before 4.3, only 8 shared interrupts are available, and
+ they are configured through MSIIR.
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ msi@41600 {
+ compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <0xe0 0>, <0xe1 0>, <0xe2 0>, <0xe3 0>,
+ <0xe4 0>, <0xe5 0>, <0xe6 0>, <0xe7 0>;
+ };
+
+ - |
+ msi@41600 {
+ compatible = "fsl,mpic-msi-v4.3";
+ reg = <0x41600 0x200>, <0x44148 4>;
+ interrupts = <0xe0 0 0 0>, <0xe1 0 0 0>, <0xe2 0 0 0>, <0xe3 0 0 0>,
+ <0xe4 0 0 0>, <0xe5 0 0 0>, <0xe6 0 0 0>, <0xe7 0 0 0>,
+ <0x100 0 0 0>, <0x101 0 0 0>, <0x102 0 0 0>, <0x103 0 0 0>,
+ <0x104 0 0 0>, <0x105 0 0 0>, <0x106 0 0 0>, <0x107 0 0 0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,mu-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,mu-msi.yaml
new file mode 100644
index 000000000000..b5282c857f44
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,mu-msi.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,mu-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale/NXP i.MX Messaging Unit (MU) work as msi controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The Messaging Unit module enables two processors within the SoC to
+ communicate and coordinate by passing messages (e.g. data, status
+ and control) through the MU interface. The MU also provides the ability
+ for one processor (A side) to signal the other processor (B side) using
+ interrupts.
+
+ Because the MU manages the messaging between processors, the MU uses
+ different clocks (from each side of the different peripheral buses).
+ Therefore, the MU must synchronize the accesses from one side to the
+ other. The MU accomplishes synchronization using two sets of matching
+ registers (Processor A-side, Processor B-side).
+
+ MU can work as msi interrupt controller to do doorbell
+
+allOf:
+ - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx6sx-mu-msi
+ - fsl,imx7ulp-mu-msi
+ - fsl,imx8ulp-mu-msi
+ - fsl,imx8ulp-mu-msi-s4
+
+ reg:
+ items:
+ - description: a side register base address
+ - description: b side register base address
+
+ reg-names:
+ items:
+ - const: processor-a-side
+ - const: processor-b-side
+
+ interrupts:
+ description: a side interrupt number.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: a side power domain
+ - description: b side power domain
+
+ power-domain-names:
+ items:
+ - const: processor-a-side
+ - const: processor-b-side
+
+ msi-controller: true
+
+ "#msi-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - msi-controller
+ - "#msi-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ msi-controller@5d270000 {
+ compatible = "fsl,imx6sx-mu-msi";
+ msi-controller;
+ #msi-cells = <0>;
+ reg = <0x5d270000 0x10000>, /* A side */
+ <0x5d300000 0x10000>; /* B side */
+ reg-names = "processor-a-side", "processor-b-side";
+ interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&pd IMX_SC_R_MU_12A>,
+ <&pd IMX_SC_R_MU_12B>;
+ power-domain-names = "processor-a-side", "processor-b-side";
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,tzic.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,tzic.yaml
new file mode 100644
index 000000000000..5f2c8761a31d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,tzic.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,tzic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale tzic Interrupt controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx51-tzic
+ - fsl,imx53-tzic
+ - const: fsl,tzic
+ - items:
+ - const: fsl,imx50-tzic
+ - const: fsl,imx53-tzic
+ - const: fsl,tzic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ tz-interrupt-controller@fffc000 {
+ compatible = "fsl,imx53-tzic", "fsl,tzic";
+ reg = <0x0fffc000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,vf610-mscm-ir.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,vf610-mscm-ir.yaml
new file mode 100644
index 000000000000..55b1ae863b91
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,vf610-mscm-ir.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,vf610-mscm-ir.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Vybrid Miscellaneous System Control - Interrupt Router
+
+description:
+ The MSCM IP contains multiple sub modules, this binding describes the second
+ block of registers which control the interrupt router. The interrupt router
+ allows to configure the recipient of each peripheral interrupt. Furthermore
+ it controls the directed processor interrupts. The module is available in all
+ Vybrid SoC's but is only really useful in dual core configurations (VF6xx
+ which comes with a Cortex-A5/Cortex-M4 combination).
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,vf610-mscm-ir
+
+ reg:
+ maxItems: 1
+
+ fsl,cpucfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The handle to the MSCM CPU configuration node, required
+ to get the current CPU ID
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description:
+ Two cells, interrupt number and cells.
+ The hardware interrupt number according to interrupt
+ assignment of the interrupt router is required.
+ Flags get passed only when using GIC as parent. Flags
+ encoding as documented by the GIC bindings.
+
+required:
+ - compatible
+ - reg
+ - fsl,cpucfg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@40001800 {
+ compatible = "fsl,vf610-mscm-ir";
+ reg = <0x40001800 0x400>;
+ fsl,cpucfg = <&mscm_cpucfg>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&intc>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt
deleted file mode 100644
index 35f752706e7d..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Android Goldfish PIC
-
-Android Goldfish programmable interrupt device used by Android
-emulator.
-
-Required properties:
-
-- compatible : should contain "google,goldfish-pic"
-- reg : <registers mapping>
-- interrupts : <interrupt mapping>
-
-Example for mips when used in cascade mode:
-
- cpuintc {
- #interrupt-cells = <0x1>;
- #address-cells = <0>;
- interrupt-controller;
- compatible = "mti,cpu-interrupt-controller";
- };
-
- interrupt-controller@1f000000 {
- compatible = "google,goldfish-pic";
- reg = <0x1f000000 0x1000>;
-
- interrupt-controller;
- #interrupt-cells = <0x1>;
-
- interrupt-parent = <&cpuintc>;
- interrupts = <0x2>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.yaml
new file mode 100644
index 000000000000..ac3c3c3ca186
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/google,goldfish-pic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Android Goldfish PIC
+
+maintainers:
+ - Miodrag Dinic <miodrag.dinic@mips.com>
+
+description:
+ Android Goldfish programmable interrupt device used by Android emulator.
+
+properties:
+ compatible:
+ const: google,goldfish-pic
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+examples:
+ - |
+ interrupt-controller@1f000000 {
+ compatible = "google,goldfish-pic";
+ reg = <0x1f000000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <2>;
+ };
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
deleted file mode 100644
index a6813a071f15..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-Hisilicon mbigen device tree bindings.
-=======================================
-
-Mbigen means: message based interrupt generator.
-
-MBI is kind of msi interrupt only used on Non-PCI devices.
-
-To reduce the wired interrupt number connected to GIC,
-Hisilicon designed mbigen to collect and generate interrupt.
-
-
-Non-pci devices can connect to mbigen and generate the
-interrupt by writing ITS register.
-
-The mbigen chip and devices connect to mbigen have the following properties:
-
-Mbigen main node required properties:
--------------------------------------------
-- compatible: Should be "hisilicon,mbigen-v2"
-
-- reg: Specifies the base physical address and size of the Mbigen
- registers.
-
-Mbigen sub node required properties:
-------------------------------------------
-- interrupt controller: Identifies the node as an interrupt controller
-
-- msi-parent: Specifies the MSI controller this mbigen use.
- For more detail information,please refer to the generic msi-parent binding in
- Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-- num-pins: the total number of pins implemented in this Mbigen
- instance.
-
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 2.
-
- The 1st cell is hardware pin number of the interrupt.This number is local to
- each mbigen chip and in the range from 0 to the maximum interrupts number
- of the mbigen.
-
- The 2nd cell is the interrupt trigger type.
- The value of this cell should be:
- 1: rising edge triggered
- or
- 4: high level triggered
-
-Examples:
-
- mbigen_chip_dsa {
- compatible = "hisilicon,mbigen-v2";
- reg = <0x0 0xc0080000 0x0 0x10000>;
-
- mbigen_gmac:intc_gmac {
- interrupt-controller;
- msi-parent = <&its_dsa 0x40b1c>;
- num-pins = <9>;
- #interrupt-cells = <2>;
- };
-
- mbigen_i2c:intc_i2c {
- interrupt-controller;
- msi-parent = <&its_dsa 0x40b0e>;
- num-pins = <2>;
- #interrupt-cells = <2>;
- };
- };
-
-Devices connect to mbigen required properties:
-----------------------------------------------------
--interrupts:Specifies the interrupt source.
- For the specific information of each cell in this property,please refer to
- the "interrupt-cells" description mentioned above.
-
-Examples:
- gmac0: ethernet@c2080000 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0 0xc2080000 0 0x20000>,
- <0 0xc0000000 0 0x1000>;
- interrupt-parent = <&mbigen_device_gmac>;
- interrupts = <656 1>,
- <657 1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.yaml b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.yaml
new file mode 100644
index 000000000000..326424e6e02a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/hisilicon,mbigen-v2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon mbigen v2
+
+maintainers:
+ - Wei Xu <xuwei5@hisilicon.com>
+
+description: >
+ Mbigen means: message based interrupt generator.
+
+ MBI is kind of msi interrupt only used on Non-PCI devices.
+
+ To reduce the wired interrupt number connected to GIC, Hisilicon designed
+ mbigen to collect and generate interrupt.
+
+ Non-pci devices can connect to mbigen and generate the interrupt by writing
+ ITS register.
+
+properties:
+ compatible:
+ const: hisilicon,mbigen-v2
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ type: object
+ additionalProperties: false
+
+ properties:
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ msi-parent:
+ maxItems: 1
+
+ num-pins:
+ description: The total number of pins implemented in this Mbigen instance.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - interrupt-controller
+ - "#interrupt-cells"
+ - msi-parent
+ - num-pins
+
+examples:
+ - |
+ mbigen@c0080000 {
+ compatible = "hisilicon,mbigen-v2";
+ reg = <0xc0080000 0x10000>;
+
+ mbigen_gmac: intc_gmac {
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ msi-parent = <&its_dsa 0x40b1c>;
+ num-pins = <9>;
+ };
+
+ mbigen_i2c: intc_i2c {
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ msi-parent = <&its_dsa 0x40b0e>;
+ num-pins = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/idt,32434-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/idt,32434-pic.yaml
index 160ff4b07cac..afb3dd80b643 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/idt,32434-pic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/idt,32434-pic.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/idt,32434-pic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: IDT 79RC32434 Interrupt Controller Device Tree Bindings
+title: IDT 79RC32434 Interrupt Controller
maintainers:
- Thomas Bogendoerfer <tsbogend@alpha.franken.de>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt
deleted file mode 100644
index 5dc2a55ad811..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt
+++ /dev/null
@@ -1,105 +0,0 @@
-* ImgTec Powerdown Controller (PDC) Interrupt Controller Binding
-
-This binding specifies what properties must be available in the device tree
-representation of a PDC IRQ controller. This has a number of input interrupt
-lines which can wake the system, and are passed on through output interrupt
-lines.
-
-Required properties:
-
- - compatible: Specifies the compatibility list for the interrupt controller.
- The type shall be <string> and the value shall include "img,pdc-intc".
-
- - reg: Specifies the base PDC physical address(s) and size(s) of the
- addressable register space. The type shall be <prop-encoded-array>.
-
- - interrupt-controller: The presence of this property identifies the node
- as an interrupt controller. No property value shall be defined.
-
- - #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The type shall be a <u32> and the value shall be 2.
-
- - num-perips: Number of waking peripherals.
-
- - num-syswakes: Number of SysWake inputs.
-
- - interrupts: List of interrupt specifiers. The first specifier shall be the
- shared SysWake interrupt, and remaining specifies shall be PDC peripheral
- interrupts in order.
-
-* Interrupt Specifier Definition
-
- Interrupt specifiers consists of 2 cells encoded as follows:
-
- - <1st-cell>: The interrupt-number that identifies the interrupt source.
- 0-7: Peripheral interrupts
- 8-15: SysWake interrupts
-
- - <2nd-cell>: The level-sense information, encoded using the Linux interrupt
- flags as follows (only 4 valid for peripheral interrupts):
- 0 = none (decided by software)
- 1 = low-to-high edge triggered
- 2 = high-to-low edge triggered
- 3 = both edge triggered
- 4 = active-high level-sensitive (required for perip irqs)
- 8 = active-low level-sensitive
-
-* Examples
-
-Example 1:
-
- /*
- * TZ1090 PDC block
- */
- pdc: pdc@02006000 {
- // This is an interrupt controller node.
- interrupt-controller;
-
- // Three cells to encode interrupt sources.
- #interrupt-cells = <2>;
-
- // Offset address of 0x02006000 and size of 0x1000.
- reg = <0x02006000 0x1000>;
-
- // Compatible with Meta hardware trigger block.
- compatible = "img,pdc-intc";
-
- // Three peripherals are connected.
- num-perips = <3>;
-
- // Four SysWakes are connected.
- num-syswakes = <4>;
-
- interrupts = <18 4 /* level */>, /* Syswakes */
- <30 4 /* level */>, /* Peripheral 0 (RTC) */
- <29 4 /* level */>, /* Peripheral 1 (IR) */
- <31 4 /* level */>; /* Peripheral 2 (WDT) */
- };
-
-Example 2:
-
- /*
- * An SoC peripheral that is wired through the PDC.
- */
- rtc0 {
- // The interrupt controller that this device is wired to.
- interrupt-parent = <&pdc>;
-
- // Interrupt source Peripheral 0
- interrupts = <0 /* Peripheral 0 (RTC) */
- 4> /* IRQ_TYPE_LEVEL_HIGH */
- };
-
-Example 3:
-
- /*
- * An interrupt generating device that is wired to a SysWake pin.
- */
- touchscreen0 {
- // The interrupt controller that this device is wired to.
- interrupt-parent = <&pdc>;
-
- // Interrupt source SysWake 0 that is active-low level-sensitive
- interrupts = <8 /* SysWake0 */
- 8 /* IRQ_TYPE_LEVEL_LOW */>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.yaml
new file mode 100644
index 000000000000..99e7a4281595
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/img,pdc-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ImgTec Powerdown Controller (PDC) Interrupt Controller
+
+maintainers:
+ - James Hogan <jhogan@kernel.org>
+
+description:
+ ImgTec Powerdown Controller (PDC) Interrupt Controller has a number of input
+ interrupt lines which can wake the system, and are passed on through output
+ interrupt lines.
+
+properties:
+ compatible:
+ const: img,pdc-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description: >
+ <1st-cell>: The interrupt-number that identifies the interrupt source.
+ 0-7: Peripheral interrupts
+ 8-15: SysWake interrupts
+
+ <2nd-cell>: The level-sense information, encoded using the Linux interrupt
+ flags as follows (only 4 valid for peripheral interrupts):
+ 0 = none (decided by software)
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 3 = both edge triggered
+ 4 = active-high level-sensitive (required for perip irqs)
+ 8 = active-low level-sensitive
+ const: 2
+
+ num-perips:
+ description: Number of waking peripherals
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 8
+
+ num-syswakes:
+ description: Number of SysWake inputs
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 8
+
+ interrupts:
+ description:
+ First entry is syswake IRQ. Subsequent entries are 1 per peripheral.
+ minItems: 2
+ maxItems: 9
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - num-perips
+ - num-syswakes
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@2006000 {
+ compatible = "img,pdc-intc";
+ reg = <0x02006000 0x1000>;
+ interrupts = <18 4>, <30 4>, <29 4>, <31 4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-perips = <3>;
+ num-syswakes = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
index 0358a7739c8e..609308a5f91d 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/ingenic,intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs interrupt controller devicetree bindings
+title: Ingenic SoCs interrupt controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt
deleted file mode 100644
index 7d19f494f19a..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Interrupt chips
----------------
-
-* Intel I/O Advanced Programmable Interrupt Controller (IO APIC)
-
- Required properties:
- --------------------
- compatible = "intel,ce4100-ioapic";
- #interrupt-cells = <2>;
-
- Device's interrupt property:
-
- interrupts = <P S>;
-
- The first number (P) represents the interrupt pin which is wired to the
- IO APIC. The second number (S) represents the sense of interrupt which
- should be configured and can be one of:
- 0 - Edge Rising
- 1 - Level Low
- 2 - Level High
- 3 - Edge Falling
-
-* Local APIC
- Required property:
-
- compatible = "intel,ce4100-lapic";
diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml
new file mode 100644
index 000000000000..a3ac818f067d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/intel,ce4100-ioapic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel I/O Advanced Programmable Interrupt Controller (IO APIC)
+
+maintainers:
+ - Rahul Tanwar <rtanwar@maxlinear.com>
+
+description: |
+ Intel's Advanced Programmable Interrupt Controller (APIC) is a
+ family of interrupt controllers. The APIC is a split
+ architecture design, with a local component (LAPIC) integrated
+ into the processor itself and an external I/O APIC. Local APIC
+ (lapic) receives interrupts from the processor's interrupt pins,
+ from internal sources and from an external I/O APIC (ioapic).
+ And it sends these to the processor core for handling.
+ See [1] Chapter 8 for more details.
+
+ Many of the Intel's generic devices like hpet, ioapic, lapic have
+ the ce4100 name in their compatible property names because they
+ first appeared in CE4100 SoC.
+
+ This schema defines bindings for I/O APIC interrupt controller.
+
+ [1] https://pdos.csail.mit.edu/6.828/2008/readings/ia32/IA32-3A.pdf
+
+properties:
+ compatible:
+ const: intel,ce4100-ioapic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ ioapic1: interrupt-controller@fec00000 {
+ compatible = "intel,ce4100-ioapic";
+ reg = <0xfec00000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml
new file mode 100644
index 000000000000..6b20a5fa8590
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/intel,ce4100-lapic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Local Advanced Programmable Interrupt Controller (LAPIC)
+
+maintainers:
+ - Rahul Tanwar <rtanwar@maxlinear.com>
+
+description: |
+ Intel's Advanced Programmable Interrupt Controller (APIC) is a
+ family of interrupt controllers. The APIC is a split
+ architecture design, with a local component (LAPIC) integrated
+ into the processor itself and an external I/O APIC. Local APIC
+ (lapic) receives interrupts from the processor's interrupt pins,
+ from internal sources and from an external I/O APIC (ioapic).
+ And it sends these to the processor core for handling.
+ See [1] Chapter 8 for more details.
+
+ Many of the Intel's generic devices like hpet, ioapic, lapic have
+ the ce4100 name in their compatible property names because they
+ first appeared in CE4100 SoC.
+
+ This schema defines bindings for local APIC interrupt controller.
+
+ [1] https://pdos.csail.mit.edu/6.828/2008/readings/ia32/IA32-3A.pdf
+
+properties:
+ compatible:
+ const: intel,ce4100-lapic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ intel,virtual-wire-mode:
+ description: Intel defines a few possible interrupt delivery
+ modes. With respect to boot/init time, mainly two interrupt
+ delivery modes are possible.
+ PIC Mode - Legacy external 8259 compliant PIC interrupt controller.
+ Virtual Wire Mode - use lapic as virtual wire interrupt delivery mode.
+ For ACPI or MPS spec compliant systems, it is figured out by some read
+ only bit field/s available in their respective defined data structures.
+ For OF based systems, it is by default set to PIC mode.
+ But if this optional boolean property is set, then the interrupt delivery
+ mode is configured to virtual wire compatibility mode.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ lapic0: interrupt-controller@fee00000 {
+ compatible = "intel,ce4100-lapic";
+ reg = <0xfee00000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ intel,virtual-wire-mode;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
index 14dced11877b..a02a6b5af205 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
@@ -2,8 +2,8 @@
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/intel,ixp4xx-interrupt.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/intel,ixp4xx-interrupt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx XScale Networking Processors Interrupt Controller
diff --git a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
deleted file mode 100644
index ee2ad36f8df8..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-J-Core Advanced Interrupt Controller
-
-Required properties:
-
-- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic
- with 8 interrupt lines with programmable priorities, or "jcore,aic2" for
- the "aic2" core with 64 interrupts.
-
-- reg: Memory region(s) for configuration. For SMP, there should be one
- region per cpu, indexed by the sequential, zero-based hardware cpu
- number.
-
-- interrupt-controller: Identifies the node as an interrupt controller
-
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-
-Example:
-
-aic: interrupt-controller@200 {
- compatible = "jcore,aic2";
- reg = < 0x200 0x30 0x500 0x30 >;
- interrupt-controller;
- #interrupt-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.yaml
new file mode 100644
index 000000000000..df8abc24591c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2018 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/jcore,aic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: J-Core Advanced Interrupt Controller
+
+maintainers:
+ - Rich Felker <dalias@libc.org>
+
+properties:
+ compatible:
+ enum:
+ - jcore,aic1
+ - jcore,aic2
+
+ reg:
+ description: Memory region(s) for configuration. For SMP, there should be one
+ region per CPU, indexed by the sequential, zero-based hardware CPU number.
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ aic: interrupt-controller@200 {
+ compatible = "jcore,aic2";
+ reg = <0x200 0x30>, <0x500 0x30>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
index e8dfa6507f64..87df07beda59 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
This module is part of the sl28cpld multi-function device. For more
- details see ../mfd/kontron,sl28cpld.yaml.
+ details see ../embedded-controller/kontron,sl28cpld.yaml.
The following interrupts are available. All types and levels are fixed
and handled by the board management controller.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml
new file mode 100644
index 000000000000..adf989976dcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,cpu-interrupt-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LoongArch CPU Interrupt Controller
+
+maintainers:
+ - Liu Peibao <liupeibao@loongson.cn>
+
+properties:
+ compatible:
+ const: loongson,cpu-interrupt-controller
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - interrupt-controller
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "loongson,cpu-interrupt-controller";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml
new file mode 100644
index 000000000000..393c128a41d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,eiointc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson Extended I/O Interrupt Controller
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+description: |
+ This interrupt controller is found on the Loongson-3 family chips and
+ Loongson-2K series chips and is used to distribute interrupts directly to
+ individual cores without forwarding them through the HT's interrupt line.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k0500-eiointc
+ - loongson,ls2k2000-eiointc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ eiointc: interrupt-controller@1fe11600 {
+ compatible = "loongson,ls2k0500-eiointc";
+ reg = <0x1fe10000 0x10000>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <3>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml
index d6bc1a687fc7..f0acd5671bb1 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/loongson,htpic.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,htpic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson-3 HyperTransport Interrupt Controller
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml
index 87a74558204f..1d145763908e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/loongson,htvec.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,htvec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson-3 HyperTransport Interrupt Vector Controller
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
index 750cc44628e9..f63b23f48d8e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/loongson,liointc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,liointc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson Local I/O Interrupt Controller
@@ -11,8 +11,13 @@ maintainers:
description: |
This interrupt controller is found in the Loongson-3 family of chips and
- Loongson-2K1000 chip, as the primary package interrupt controller which
+ Loongson-2K series chips, as the primary package interrupt controller which
can route local I/O interrupt to interrupt lines of cores.
+ Be aware of the following points.
+ 1.The Loongson-2K0500 is a single core CPU;
+ 2.The Loongson-2K0500/2K1000 has 64 device interrupt sources as inputs, so we
+ need to define two nodes in dts{i} to describe the "0-31" and "32-61" interrupt
+ sources respectively.
allOf:
- $ref: /schemas/interrupt-controller.yaml#
@@ -33,6 +38,7 @@ properties:
- const: main
- const: isr0
- const: isr1
+ minItems: 2
interrupt-controller: true
@@ -45,16 +51,14 @@ properties:
interrupt-names:
description: List of names for the parent interrupts.
items:
- - const: int0
- - const: int1
- - const: int2
- - const: int3
+ pattern: int[0-3]
minItems: 1
+ maxItems: 4
'#interrupt-cells':
const: 2
- 'loongson,parent_int_map':
+ loongson,parent_int_map:
description: |
This property points how the children interrupts will be mapped into CPU
interrupt lines. Each cell refers to a parent interrupt line from 0 to 3
@@ -69,10 +73,10 @@ required:
- compatible
- reg
- interrupts
+ - interrupt-names
- interrupt-controller
- '#interrupt-cells'
- - 'loongson,parent_int_map'
-
+ - loongson,parent_int_map
unevaluatedProperties: false
@@ -86,7 +90,8 @@ if:
then:
properties:
reg:
- minItems: 3
+ minItems: 2
+ maxItems: 3
required:
- reg-names
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
deleted file mode 100644
index a63ed9fcb535..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Loongson ls1x Interrupt Controller
-
-Required properties:
-
-- compatible : should be "loongson,ls1x-intc". Valid strings are:
-
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 2.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-intc: interrupt-controller@1fd01040 {
- compatible = "loongson,ls1x-intc";
- reg = <0x1fd01040 0x18>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- interrupt-parent = <&cpu_intc>;
- interrupts = <2>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml
new file mode 100644
index 000000000000..c60125fb1cbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,ls1x-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 Interrupt Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ Loongson-1 interrupt controller is connected to the MIPS core interrupt
+ controller, which controls several groups of interrupts.
+
+properties:
+ compatible:
+ const: loongson,ls1x-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ intc0: interrupt-controller@1fd01040 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd01040 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml
index 1f6fd73d4624..a71fc2218ede 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/loongson,pch-msi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,pch-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson PCH MSI Controller
@@ -25,7 +25,7 @@ properties:
description:
u32 value of the base of parent HyperTransport vector allocated
to PCH MSI.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
@@ -33,7 +33,7 @@ properties:
description:
u32 value of the number of parent HyperTransport vectors allocated
to PCH MSI.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 256
@@ -46,7 +46,7 @@ required:
- loongson,msi-base-vec
- loongson,msi-num-vecs
-additionalProperties: true #fixme
+additionalProperties: true # fixme
examples:
- |
diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml
index fdd6a38a31db..b7bc5cb1dff2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/loongson,pch-pic.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/loongson,pch-pic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson PCH PIC Controller
@@ -25,7 +25,7 @@ properties:
description:
u32 value of the base of parent HyperTransport vector allocated
to PCH PIC.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 192
diff --git a/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
deleted file mode 100644
index aee38e7c13e7..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-TI-NSPIRE interrupt controller
-
-Required properties:
-- compatible: Compatible property value should be "lsi,zevio-intc".
-
-- reg: Physical base address of the controller and length of memory mapped
- region.
-
-- interrupt-controller : Identifies the node as an interrupt controller
-
-Example:
-
-interrupt-controller {
- compatible = "lsi,zevio-intc";
- interrupt-controller;
- reg = <0xDC000000 0x1000>;
- #interrupt-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.yaml
new file mode 100644
index 000000000000..e66b25f579c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Daniel Tang <dt.tangr@gmail.com>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/lsi,zevio-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-NSPIRE Interrupt Controller
+
+maintainers:
+ - Daniel Tang <dt.tangr@gmail.com>
+
+description: |
+ TI-NSPIRE interrupt controller
+
+properties:
+ compatible:
+ const: lsi,zevio-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@dc000000 {
+ compatible = "lsi,zevio-intc";
+ interrupt-controller;
+ reg = <0xdc000000 0x1000>;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-gicp.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-gicp.yaml
new file mode 100644
index 000000000000..5faedd95b9a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-gicp.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,ap806-gicp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell GICP Controller
+
+maintainers:
+ - Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+
+description:
+ GICP is a Marvell extension of the GIC that allows to trigger GIC SPI
+ interrupts by doing a memory transaction. It is used by the ICU
+ located in the Marvell CP110 to turn wired interrupts inside the CP
+ into GIC SPI interrupts.
+
+properties:
+ compatible:
+ const: marvell,ap806-gicp
+
+ reg:
+ maxItems: 1
+
+ marvell,spi-ranges:
+ description: Tuples of GIC SPI interrupt ranges available for this GICP
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: SPI interrupt base
+ - description: Number of interrupts in the range
+
+ msi-controller: true
+
+required:
+ - compatible
+ - reg
+ - msi-controller
+ - marvell,spi-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ msi-controller@3f0040 {
+ compatible = "marvell,ap806-gicp";
+ reg = <0x3f0040 0x10>;
+ marvell,spi-ranges = <64 64>, <288 64>;
+ msi-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-sei.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-sei.yaml
new file mode 100644
index 000000000000..e812f9a86307
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,ap806-sei.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,ap806-sei.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell SEI (System Error Interrupt) Controller
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: >
+ Marvell SEI (System Error Interrupt) controller is an interrupt aggregator. It
+ receives interrupts from several sources and aggregates them to a single
+ interrupt line (an SPI) on the parent interrupt controller.
+
+ This interrupt controller can handle up to 64 SEIs, a set comes from the AP
+ and is wired while a second set comes from the CPs by the mean of MSIs.
+
+properties:
+ compatible:
+ const: marvell,ap806-sei
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+ msi-controller: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#interrupt-cells'
+ - interrupt-controller
+ - msi-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@3f0200 {
+ compatible = "marvell,ap806-sei";
+ reg = <0x3f0200 0x40>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ msi-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt
deleted file mode 100644
index 5fc03134a999..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Marvell Armada 370, 375, 38x, XP Interrupt Controller
------------------------------------------------------
-
-Required properties:
-- compatible: Should be "marvell,mpic"
-- interrupt-controller: Identifies the node as an interrupt controller.
-- msi-controller: Identifies the node as an PCI Message Signaled
- Interrupt controller.
-- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
- The cell is the IRQ number
-
-- reg: Should contain PMIC registers location and length. First pair
- for the main interrupt registers, second pair for the per-CPU
- interrupt registers. For this last pair, to be compliant with SMP
- support, the "virtual" must be use (For the record, these registers
- automatically map to the interrupt controller registers of the
- current CPU)
-
-Optional properties:
-
-- interrupts: If defined, then it indicates that this MPIC is
- connected as a slave to another interrupt controller. This is
- typically the case on Armada 375 and Armada 38x, where the MPIC is
- connected as a slave to the Cortex-A9 GIC. The provided interrupt
- indicate to which GIC interrupt the MPIC output is connected.
-
-Example:
-
- mpic: interrupt-controller@d0020000 {
- compatible = "marvell,mpic";
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <1>;
- interrupt-controller;
- msi-controller;
- reg = <0xd0020a00 0x1d0>,
- <0xd0021070 0x58>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.txt
deleted file mode 100644
index 86a7b4cd03f5..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Marvell Armada 7K/8K PIC Interrupt controller
----------------------------------------------
-
-This is the Device Tree binding for the PIC, a secondary interrupt
-controller available on the Marvell Armada 7K/8K ARM64 SoCs, and
-typically connected to the GIC as the primary interrupt controller.
-
-Required properties:
-- compatible: should be "marvell,armada-8k-pic"
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: the number of cells to define interrupts on this
- controller. Should be 1
-- reg: the register area for the PIC interrupt controller
-- interrupts: the interrupt to the primary interrupt controller,
- typically the GIC
-
-Example:
-
- pic: interrupt-controller@3f0100 {
- compatible = "marvell,armada-8k-pic";
- reg = <0x3f0100 0x10>;
- #interrupt-cells = <1>;
- interrupt-controller;
- interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.yaml
new file mode 100644
index 000000000000..5a455f7353db
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-8k-pic.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,armada-8k-pic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 7K/8K PIC Interrupt controller
+
+maintainers:
+ - Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+
+description:
+ The Marvell Armada 7K/8K PIC is a secondary interrupt controller available on
+ the Marvell Armada 7K/8K ARM64 SoCs, and typically connected to the GIC as the
+ primary interrupt controller.
+
+properties:
+ compatible:
+ const: marvell,armada-8k-pic
+
+ reg:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+ description: Interrupt to the primary interrupt controller (GIC).
+
+required:
+ - compatible
+ - reg
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@3f0100 {
+ compatible = "marvell,armada-8k-pic";
+ reg = <0x3f0100 0x10>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,cp110-icu.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,cp110-icu.yaml
new file mode 100644
index 000000000000..ddfce217e119
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,cp110-icu.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,cp110-icu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+ - Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+
+title: Marvell ICU Interrupt Controller
+
+description:
+ The Marvell ICU (Interrupt Consolidation Unit) controller is responsible for
+ collecting all wired-interrupt sources in the CP and communicating them to the
+ GIC in the AP. The unit translates interrupt requests on input wires to MSG
+ memory mapped transactions to the GIC. These messages access different GIC
+ memory areas depending on their type (NSR, SR, SEI, REI, etc).
+
+properties:
+ compatible:
+ const: marvell,cp110-icu
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^interrupt-controller@":
+ type: object
+ description: Interrupt group child nodes
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - marvell,cp110-icu-nsr
+ - marvell,cp110-icu-sr
+ - marvell,cp110-icu-sei
+ - marvell,cp110-icu-rei
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 0
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ msi-parent:
+ maxItems: 1
+ description: Phandle to the GICP controller
+
+ required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+ - msi-parent
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1e0000 {
+ compatible = "marvell,cp110-icu";
+ reg = <0x1e0000 0x440>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ interrupt-controller@10 {
+ compatible = "marvell,cp110-icu-nsr";
+ reg = <0x10 0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ msi-parent = <&gicp>;
+ };
+
+ interrupt-controller@50 {
+ compatible = "marvell,cp110-icu-sei";
+ reg = <0x50 0x10>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ msi-parent = <&sei>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,gicp.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,gicp.txt
deleted file mode 100644
index 64a00ceb7da4..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,gicp.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Marvell GICP Controller
------------------------
-
-GICP is a Marvell extension of the GIC that allows to trigger GIC SPI
-interrupts by doing a memory transaction. It is used by the ICU
-located in the Marvell CP110 to turn wired interrupts inside the CP
-into GIC SPI interrupts.
-
-Required properties:
-
-- compatible: Must be "marvell,ap806-gicp"
-
-- reg: Must be the address and size of the GICP SPI registers
-
-- marvell,spi-ranges: tuples of GIC SPI interrupts ranges available
- for this GICP
-
-- msi-controller: indicates that this is an MSI controller
-
-Example:
-
-gicp_spi: gicp-spi@3f0040 {
- compatible = "marvell,ap806-gicp";
- reg = <0x3f0040 0x10>;
- marvell,spi-ranges = <64 64>, <288 64>;
- msi-controller;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
deleted file mode 100644
index 1c94a57a661e..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-Marvell ICU Interrupt Controller
---------------------------------
-
-The Marvell ICU (Interrupt Consolidation Unit) controller is
-responsible for collecting all wired-interrupt sources in the CP and
-communicating them to the GIC in the AP, the unit translates interrupt
-requests on input wires to MSG memory mapped transactions to the GIC.
-These messages will access a different GIC memory area depending on
-their type (NSR, SR, SEI, REI, etc).
-
-Required properties:
-
-- compatible: Should be "marvell,cp110-icu"
-
-- reg: Should contain ICU registers location and length.
-
-Subnodes: Each group of interrupt is declared as a subnode of the ICU,
-with their own compatible.
-
-Required properties for the icu_nsr/icu_sei subnodes:
-
-- compatible: Should be one of:
- * "marvell,cp110-icu-nsr"
- * "marvell,cp110-icu-sr"
- * "marvell,cp110-icu-sei"
- * "marvell,cp110-icu-rei"
-
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value shall be 2.
-
- The 1st cell is the index of the interrupt in the ICU unit.
-
- The 2nd cell is the type of the interrupt. See arm,gic.txt for
- details.
-
-- interrupt-controller: Identifies the node as an interrupt
- controller.
-
-- msi-parent: Should point to the GICP controller, the GIC extension
- that allows to trigger interrupts using MSG memory mapped
- transactions.
-
-Note: each 'interrupts' property referring to any 'icu_xxx' node shall
- have a different number within [0:206].
-
-Example:
-
-icu: interrupt-controller@1e0000 {
- compatible = "marvell,cp110-icu";
- reg = <0x1e0000 0x440>;
-
- CP110_LABEL(icu_nsr): interrupt-controller@10 {
- compatible = "marvell,cp110-icu-nsr";
- reg = <0x10 0x20>;
- #interrupt-cells = <2>;
- interrupt-controller;
- msi-parent = <&gicp>;
- };
-
- CP110_LABEL(icu_sei): interrupt-controller@50 {
- compatible = "marvell,cp110-icu-sei";
- reg = <0x50 0x10>;
- #interrupt-cells = <2>;
- interrupt-controller;
- msi-parent = <&sei>;
- };
-};
-
-node1 {
- interrupt-parent = <&icu_nsr>;
- interrupts = <106 IRQ_TYPE_LEVEL_HIGH>;
-};
-
-node2 {
- interrupt-parent = <&icu_sei>;
- interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
-};
-
-/* Would not work with the above nodes */
-node3 {
- interrupt-parent = <&icu_nsr>;
- interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
-};
-
-The legacy bindings were different in this way:
-
-- #interrupt-cells: The value was 3.
- The 1st cell was the group type of the ICU interrupt. Possible
- group types were:
- ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure
- ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure
- ICU_GRP_SEI (0x4) : System error interrupt
- ICU_GRP_REI (0x5) : RAM error interrupt
- The 2nd cell was the index of the interrupt in the ICU unit.
- The 3rd cell was the type of the interrupt. See arm,gic.txt for
- details.
-
-Example:
-
-icu: interrupt-controller@1e0000 {
- compatible = "marvell,cp110-icu";
- reg = <0x1e0000 0x440>;
-
- #interrupt-cells = <3>;
- interrupt-controller;
- msi-parent = <&gicp>;
-};
-
-node1 {
- interrupt-parent = <&icu>;
- interrupts = <ICU_GRP_NSR 106 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,mpic.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,mpic.yaml
new file mode 100644
index 000000000000..616a41c87352
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,mpic.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,mpic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 370, 375, 38x, 39x, XP Interrupt Controller
+
+maintainers:
+ - Marek Behún <kabel@kernel.org>
+
+description: |
+ The top-level interrupt controller on Marvell Armada 370 and XP. On these
+ platforms it also provides inter-processor interrupts.
+
+ On Marvell Armada 375, 38x and 39x this controller is wired under ARM GIC.
+
+ Provides MSI handling for the PCIe controllers.
+
+properties:
+ compatible:
+ const: marvell,mpic
+
+ reg:
+ items:
+ - description: main registers
+ - description: per-cpu registers
+
+ interrupts:
+ items:
+ - description: |
+ Parent interrupt on platforms where MPIC is not the top-level
+ interrupt controller.
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ msi-controller: true
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - msi-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ interrupt-controller@20a00 {
+ compatible = "marvell,mpic";
+ reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+ interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ msi-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
deleted file mode 100644
index 0ebfc952cb34..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-
-* Marvell ODMI for MSI support
-
-Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
-which can be used by on-board peripheral for MSI interrupts.
-
-Required properties:
-
-- compatible : The value here should contain:
-
- "marvell,ap806-odmi-controller", "marvell,odmi-controller".
-
-- interrupt,controller : Identifies the node as an interrupt controller.
-
-- msi-controller : Identifies the node as an MSI controller.
-
-- marvell,odmi-frames : Number of ODMI frames available. Each frame
- provides a number of events.
-
-- reg : List of register definitions, one for each
- ODMI frame.
-
-- marvell,spi-base : List of GIC base SPI interrupts, one for each
- ODMI frame. Those SPI interrupts are 0-based,
- i.e marvell,spi-base = <128> will use SPI #96.
- See Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
- for details about the GIC Device Tree binding.
-
-Example:
-
- odmi: odmi@300000 {
- compatible = "marvell,ap806-odmi-controller",
- "marvell,odmi-controller";
- interrupt-controller;
- msi-controller;
- marvell,odmi-frames = <4>;
- reg = <0x300000 0x4000>,
- <0x304000 0x4000>,
- <0x308000 0x4000>,
- <0x30C000 0x4000>;
- marvell,spi-base = <128>, <136>, <144>, <152>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.yaml
new file mode 100644
index 000000000000..9ec1ed4a5155
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,odmi-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell ODMI controller
+
+maintainers:
+ - Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+description:
+ Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller which can
+ be used by on-board peripherals for MSI interrupts.
+
+properties:
+ compatible:
+ const: marvell,odmi-controller
+
+ reg:
+ description: List of register definitions, one for each ODMI frame.
+
+ msi-controller: true
+
+ marvell,odmi-frames:
+ description: Number of ODMI frames available. Each frame provides a number of events.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ marvell,spi-base:
+ description: >
+ List of GIC base SPI interrupts, one for each ODMI frame. Those SPI
+ interrupts are 0-based, i.e. marvell,spi-base = <128> will use SPI #96.
+ See Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+ for details.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+required:
+ - compatible
+ - reg
+ - msi-controller
+ - marvell,odmi-frames
+ - marvell,spi-base
+
+additionalProperties: false
+
+examples:
+ - |
+ msi-controller@300000 {
+ compatible = "marvell,odmi-controller";
+ msi-controller;
+ marvell,odmi-frames = <4>;
+ reg = <0x300000 0x4000>, <0x304000 0x4000>, <0x308000 0x4000>, <0x30C000 0x4000>;
+ marvell,spi-base = <128>, <136>, <144>, <152>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-bridge-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-bridge-intc.yaml
new file mode 100644
index 000000000000..e1310ec65382
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-bridge-intc.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+---
+$id: http://devicetree.org/schemas/interrupt-controller/marvell,orion-bridge-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Orion SoC Bridge Interrupt Controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ const: marvell,orion-bridge-intc
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupts:
+ description: Bridge interrupt of the main interrupt controller
+
+ marvell,#interrupts:
+ description: Number of interrupts provided by bridge interrupt controller.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 32
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@20110 {
+ compatible = "marvell,orion-bridge-intc";
+ reg = <0x20110 0x8>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <0>;
+ /* Dove bridge provides 5 interrupts */
+ marvell,#interrupts = <5>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt
deleted file mode 100644
index 2c11ac76fac9..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Marvell Orion SoC interrupt controllers
-
-* Main interrupt controller
-
-Required properties:
-- compatible: shall be "marvell,orion-intc"
-- reg: base address(es) of interrupt registers starting with CAUSE register
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
-
-The interrupt sources map to the corresponding bits in the interrupt
-registers, i.e.
-- 0 maps to bit 0 of first base address,
-- 1 maps to bit 1 of first base address,
-- 32 maps to bit 0 of second base address, and so on.
-
-Example:
- intc: interrupt-controller {
- compatible = "marvell,orion-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- /* Dove has 64 first level interrupts */
- reg = <0x20200 0x10>, <0x20210 0x10>;
- };
-
-* Bridge interrupt controller
-
-Required properties:
-- compatible: shall be "marvell,orion-bridge-intc"
-- reg: base address of bridge interrupt registers starting with CAUSE register
-- interrupts: bridge interrupt of the main interrupt controller
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
-
-Optional properties:
-- marvell,#interrupts: number of interrupts provided by bridge interrupt
- controller, defaults to 32 if not set
-
-Example:
- bridge_intc: interrupt-controller {
- compatible = "marvell,orion-bridge-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- reg = <0x20110 0x8>;
- interrupts = <0>;
- /* Dove bridge provides 5 interrupts */
- marvell,#interrupts = <5>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
deleted file mode 100644
index 0beafed502f5..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Marvell SEI (System Error Interrupt) Controller
------------------------------------------------
-
-Marvell SEI (System Error Interrupt) controller is an interrupt
-aggregator. It receives interrupts from several sources and aggregates
-them to a single interrupt line (an SPI) on the parent interrupt
-controller.
-
-This interrupt controller can handle up to 64 SEIs, a set comes from the
-AP and is wired while a second set comes from the CPs by the mean of
-MSIs.
-
-Required properties:
-
-- compatible: should be one of:
- * "marvell,ap806-sei"
-- reg: SEI registers location and length.
-- interrupts: identifies the parent IRQ that will be triggered.
-- #interrupt-cells: number of cells to define an SEI wired interrupt
- coming from the AP, should be 1. The cell is the IRQ
- number.
-- interrupt-controller: identifies the node as an interrupt controller
- for AP interrupts.
-- msi-controller: identifies the node as an MSI controller for the CPs
- interrupts.
-
-Example:
-
- sei: interrupt-controller@3f0200 {
- compatible = "marvell,ap806-sei";
- reg = <0x3f0200 0x40>;
- interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
- #interrupt-cells = <1>;
- interrupt-controller;
- msi-controller;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
deleted file mode 100644
index 5865f4f2c69d..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Mediatek 27xx cirq
-
-In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to
-work outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC.
-The external interrupts (outside MCUSYS) will feed through CIRQ and connect
-to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
-interrupts and generate a pulse signal to parent interrupt controller when
-flush command is executed. With CIRQ, MCUSYS can be completely turned off
-to improve the system power consumption without losing interrupts.
-
-Required properties:
-- compatible: should be one of
- - "mediatek,mt2701-cirq" for mt2701 CIRQ
- - "mediatek,mt8135-cirq" for mt8135 CIRQ
- - "mediatek,mt8173-cirq" for mt8173 CIRQ
- and "mediatek,cirq" as a fallback.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
-- reg: Physical base address of the cirq registers and length of memory
- mapped region.
-- mediatek,ext-irq-range: Identifies external irq number range in different
- SOCs.
-
-Example:
- cirq: interrupt-controller@10204000 {
- compatible = "mediatek,mt2701-cirq",
- "mediatek,mtk-cirq";
- interrupt-controller;
- #interrupt-cells = <3>;
- interrupt-parent = <&sysirq>;
- reg = <0 0x10204000 0 0x400>;
- mediatek,ext-irq-start = <32 200>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml
new file mode 100644
index 000000000000..30d76692ca87
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,mt6577-sysirq.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/mediatek,mt6577-sysirq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek sysirq
+
+description:
+ MediaTek SOCs sysirq support controllable irq inverter for each GIC SPI
+ interrupt.
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt6577-sysirq
+ - items:
+ - enum:
+ - mediatek,mt2701-sysirq
+ - mediatek,mt2712-sysirq
+ - mediatek,mt6572-sysirq
+ - mediatek,mt6580-sysirq
+ - mediatek,mt6582-sysirq
+ - mediatek,mt6589-sysirq
+ - mediatek,mt6592-sysirq
+ - mediatek,mt6755-sysirq
+ - mediatek,mt6765-sysirq
+ - mediatek,mt6779-sysirq
+ - mediatek,mt6795-sysirq
+ - mediatek,mt6797-sysirq
+ - mediatek,mt7622-sysirq
+ - mediatek,mt7623-sysirq
+ - mediatek,mt7629-sysirq
+ - mediatek,mt8127-sysirq
+ - mediatek,mt8135-sysirq
+ - mediatek,mt8173-sysirq
+ - mediatek,mt8183-sysirq
+ - mediatek,mt8365-sysirq
+ - mediatek,mt8516-sysirq
+ - const: mediatek,mt6577-sysirq
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ $ref: arm,gic.yaml#/properties/#interrupt-cells
+
+required:
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt6797-sysirq
+ then:
+ properties:
+ reg:
+ minItems: 2
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interrupt-controller@10200620 {
+ compatible = "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq";
+ reg = <0x10220620 0x20>,
+ <0x10220690 0x10>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,mtk-cirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/mediatek,mtk-cirq.yaml
new file mode 100644
index 000000000000..20dfffb34f0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,mtk-cirq.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/mediatek,mtk-cirq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek System Interrupt Controller
+
+maintainers:
+ - Youlin Pei <youlin.pei@mediatek.com>
+
+description:
+ In MediaTek SoCs, the CIRQ is a low power interrupt controller designed to
+ work outside of MCUSYS which comprises with Cortex-Ax cores, CCI and GIC.
+ The external interrupts (outside MCUSYS) will feed through CIRQ and connect
+ to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
+ interrupts and generate a pulse signal to parent interrupt controller when
+ flush command is executed. With CIRQ, MCUSYS can be completely turned off
+ to improve the system power consumption without losing interrupts.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt2701-cirq
+ - mediatek,mt8135-cirq
+ - mediatek,mt8173-cirq
+ - mediatek,mt8192-cirq
+ - const: mediatek,mtk-cirq
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 3
+
+ interrupt-controller: true
+
+ mediatek,ext-irq-range:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: First CIRQ interrupt
+ - description: Last CIRQ interrupt
+ description:
+ Identifies the range of external interrupts in different SoCs
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+ - mediatek,ext-irq-range
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ cirq: interrupt-controller@10204000 {
+ compatible = "mediatek,mt2701-cirq", "mediatek,mtk-cirq";
+ reg = <0x10204000 0x400>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupt-parent = <&sysirq>;
+ mediatek,ext-irq-range = <32 200>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
deleted file mode 100644
index 84ced3f4179b..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-MediaTek sysirq
-
-MediaTek SOCs sysirq support controllable irq inverter for each GIC SPI
-interrupt.
-
-Required properties:
-- compatible: should be
- "mediatek,mt8516-sysirq", "mediatek,mt6577-sysirq": for MT8516
- "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183
- "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173
- "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135
- "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127
- "mediatek,mt7622-sysirq", "mediatek,mt6577-sysirq": for MT7622
- "mediatek,mt7623-sysirq", "mediatek,mt6577-sysirq": for MT7623
- "mediatek,mt7629-sysirq", "mediatek,mt6577-sysirq": for MT7629
- "mediatek,mt6795-sysirq", "mediatek,mt6577-sysirq": for MT6795
- "mediatek,mt6797-sysirq", "mediatek,mt6577-sysirq": for MT6797
- "mediatek,mt6779-sysirq", "mediatek,mt6577-sysirq": for MT6779
- "mediatek,mt6765-sysirq", "mediatek,mt6577-sysirq": for MT6765
- "mediatek,mt6755-sysirq", "mediatek,mt6577-sysirq": for MT6755
- "mediatek,mt6592-sysirq", "mediatek,mt6577-sysirq": for MT6592
- "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq": for MT6589
- "mediatek,mt6582-sysirq", "mediatek,mt6577-sysirq": for MT6582
- "mediatek,mt6580-sysirq", "mediatek,mt6577-sysirq": for MT6580
- "mediatek,mt6577-sysirq": for MT6577
- "mediatek,mt2712-sysirq", "mediatek,mt6577-sysirq": for MT2712
- "mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt.
-- reg: Physical base address of the intpol registers and length of memory
- mapped region. Could be multiple bases here. Ex: mt6797 needs 2 reg, others
- need 1.
-
-Example:
- sysirq: intpol-controller@10200620 {
- compatible = "mediatek,mt6797-sysirq",
- "mediatek,mt6577-sysirq";
- interrupt-controller;
- #interrupt-cells = <3>;
- interrupt-parent = <&gic>;
- reg = <0 0x10220620 0 0x20>,
- <0 0x10220690 0 0x10>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml
deleted file mode 100644
index 50003880ee6f..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/microchip,eic.yaml
+++ /dev/null
@@ -1,73 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/interrupt-controller/microchip,eic.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip External Interrupt Controller
-
-maintainers:
- - Claudiu Beznea <claudiu.beznea@microchip.com>
-
-description:
- This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides
- support for handling up to 2 external interrupt lines.
-
-properties:
- compatible:
- enum:
- - microchip,sama7g5-eic
-
- reg:
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
- description:
- The first cell is the input IRQ number (between 0 and 1), the second cell
- is the trigger type as defined in interrupt.txt present in this directory.
-
- interrupts:
- description: |
- Contains the GIC SPI IRQs mapped to the external interrupt lines. They
- should be specified sequentially from output 0 to output 1.
- minItems: 2
- maxItems: 2
-
- clocks:
- maxItems: 1
-
- clock-names:
- const: pclk
-
-required:
- - compatible
- - reg
- - interrupt-controller
- - '#interrupt-cells'
- - interrupts
- - clocks
- - clock-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- eic: interrupt-controller@e1628000 {
- compatible = "microchip,sama7g5-eic";
- reg = <0xe1628000 0x100>;
- interrupt-parent = <&gic>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&pmc PMC_TYPE_PERIPHERAL 37>;
- clock-names = "pclk";
- };
-
-...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml
new file mode 100644
index 000000000000..dca16e202da9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/microchip,lan966x-oic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN966x outband interrupt controller
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+ The Microchip LAN966x outband interrupt controller (OIC) maps the internal
+ interrupt sources of the LAN966x device to a PCI interrupt when the LAN966x
+ device is used as a PCI device.
+
+properties:
+ compatible:
+ const: microchip,lan966x-oic
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - interrupt-controller
+ - interrupts
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@e00c0120 {
+ compatible = "microchip,lan966x-oic";
+ reg = <0xe00c0120 0x190>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts = <0>;
+ interrupt-parent = <&intc>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32-evic.txt b/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32-evic.txt
deleted file mode 100644
index c3a1b37c4c35..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32-evic.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-Microchip PIC32 Interrupt Controller
-====================================
-
-The Microchip PIC32 contains an Enhanced Vectored Interrupt Controller (EVIC).
-It handles all internal and external interrupts. This controller exists outside
-of the CPU and is the arbitrator of all interrupts (including interrupts from
-the CPU itself) before they are presented to the CPU.
-
-External interrupts have a software configurable edge polarity. Non external
-interrupts have a type and polarity that is determined by the source of the
-interrupt.
-
-Required properties
--------------------
-
-- compatible: Should be "microchip,pic32mzda-evic"
-- reg: Specifies physical base address and size of register range.
-- interrupt-controller: Identifies the node as an interrupt controller.
-- #interrupt cells: Specifies the number of cells used to encode an interrupt
- source connected to this controller. The value shall be 2 and interrupt
- descriptor shall have the following format:
-
- <hw_irq irq_type>
-
- hw_irq - represents the hardware interrupt number as in the data sheet.
- irq_type - is used to describe the type and polarity of an interrupt. For
- internal interrupts use IRQ_TYPE_EDGE_RISING for non persistent interrupts and
- IRQ_TYPE_LEVEL_HIGH for persistent interrupts. For external interrupts use
- IRQ_TYPE_EDGE_RISING or IRQ_TYPE_EDGE_FALLING to select the desired polarity.
-
-Optional properties
--------------------
-- microchip,external-irqs: u32 array of external interrupts with software
- polarity configuration. This array corresponds to the bits in the INTCON
- SFR.
-
-Example
--------
-
-evic: interrupt-controller@1f810000 {
- compatible = "microchip,pic32mzda-evic";
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x1f810000 0x1000>;
- microchip,external-irqs = <3 8 13 18 23>;
-};
-
-Each device/peripheral must request its interrupt line with the associated type
-and polarity.
-
-Internal interrupt DTS snippet
-------------------------------
-
-device@1f800000 {
- ...
- interrupts = <113 IRQ_TYPE_LEVEL_HIGH>;
- ...
-};
-
-External interrupt DTS snippet
-------------------------------
-
-device@1f800000 {
- ...
- interrupts = <3 IRQ_TYPE_EDGE_RISING>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mzda-evic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mzda-evic.yaml
new file mode 100644
index 000000000000..74bfc42693f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,pic32mzda-evic.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/microchip,pic32mzda-evic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 EVIC Interrupt Controller
+
+maintainers:
+ - Cristian Birsan <cristian.birsan@microchip.com>
+
+description: >
+ The Microchip PIC32 contains an Enhanced Vectored Interrupt Controller (EVIC).
+ It handles all internal and external interrupts. This controller exists
+ outside of the CPU and is the arbitrator of all interrupts (including
+ interrupts from the CPU itself) before they are presented to the CPU.
+
+ External interrupts have a software configurable edge polarity. Non external
+ interrupts have a type and polarity that is determined by the source of the
+ interrupt.
+
+properties:
+ compatible:
+ items:
+ - const: microchip,pic32mzda-evic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ microchip,external-irqs:
+ description:
+ External interrupts with software polarity configuration corresponding to
+ the INTCON SFR bits.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1f810000 {
+ compatible = "microchip,pic32mzda-evic";
+ reg = <0x1f810000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ microchip,external-irqs = <3 8 13 18 23>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
new file mode 100644
index 000000000000..d56ba65b17d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/microchip,sama7g5-eic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip External Interrupt Controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description:
+ This interrupt controller is found in Microchip SoCs (SAMA7G5) and provides
+ support for handling up to 2 external interrupt lines.
+
+properties:
+ compatible:
+ enum:
+ - microchip,sama7g5-eic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description:
+ The first cell is the input IRQ number (between 0 and 1), the second cell
+ is the trigger type as defined in interrupt.txt present in this directory.
+
+ interrupts:
+ description: |
+ Contains the GIC SPI IRQs mapped to the external interrupt lines. They
+ should be specified sequentially from output 0 to output 1.
+ minItems: 2
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ eic: interrupt-controller@e1628000 {
+ compatible = "microchip,sama7g5-eic";
+ reg = <0xe1628000 0x100>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 37>;
+ clock-names = "pclk";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml
index 5a583bf3dbc1..b7c5022eec84 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/mrvl,intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell MMP/Orion Interrupt controller bindings
+title: Marvell MMP/Orion Interrupt controller
maintainers:
- Andrew Lunn <andrew@lunn.ch>
@@ -53,8 +53,8 @@ allOf:
maxItems: 1
reg-names:
items:
- - const: 'mux status'
- - const: 'mux mask'
+ - const: mux status
+ - const: mux mask
required:
- interrupts
else:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
index 27b798bfe29b..d943ea820cdd 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microsemi Ocelot SoC ICPU Interrupt Controller
@@ -26,7 +26,6 @@ properties:
- mscc,ocelot-icpu-intr
- mscc,serval-icpu-intr
-
'#interrupt-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mti,cpu-interrupt-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/mti,cpu-interrupt-controller.yaml
new file mode 100644
index 000000000000..46a1f5f54b74
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/mti,cpu-interrupt-controller.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/mti,cpu-interrupt-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS CPU Interrupt Controller
+
+description: >
+ On MIPS the mips_cpu_irq_of_init() helper can be used to initialize the 8 CPU
+ IRQs from a devicetree file and create a irq_domain for IRQ controller.
+
+ With the irq_domain in place we can describe how the 8 IRQs are wired to the
+ platforms internal interrupt controller cascade.
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+properties:
+ compatible:
+ const: mti,cpu-interrupt-controller
+
+ '#interrupt-cells':
+ const: 1
+
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - '#address-cells'
+ - interrupt-controller
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "mti,cpu-interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml
index 9ce6804bdb99..2d6307a383ad 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/nuvoton,wpcm450-aic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Nuvoton WPCM450 Advanced Interrupt Controller bindings
+title: Nuvoton WPCM450 Advanced Interrupt Controller
maintainers:
- Jonathan Neuschäfer <j.neuschaefer@gmx.net>
diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
deleted file mode 100644
index 2ff356640100..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-NVIDIA Legacy Interrupt Controller
-
-All Tegra SoCs contain a legacy interrupt controller that routes
-interrupts to the GIC, and also serves as a wakeup source. It is also
-referred to as "ictlr", hence the name of the binding.
-
-The HW block exposes a number of interrupt controllers, each
-implementing a set of 32 interrupts.
-
-Required properties:
-
-- compatible : should be: "nvidia,tegra<chip>-ictlr". The LIC on
- subsequent SoCs remained backwards-compatible with Tegra30, so on
- Tegra generations later than Tegra30 the compatible value should
- include "nvidia,tegra30-ictlr".
-- reg : Specifies base physical address and size of the registers.
- Each controller must be described separately (Tegra20 has 4 of them,
- whereas Tegra30 and later have 5).
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 3.
-
-Notes:
-
-- Because this HW ultimately routes interrupts to the GIC, the
- interrupt specifier must be that of the GIC.
-- Only SPIs can use the ictlr as an interrupt parent. SGIs and PPIs
- are explicitly forbidden.
-
-Example:
-
- ictlr: interrupt-controller@60004000 {
- compatible = "nvidia,tegra20-ictlr", "nvidia,tegra-ictlr";
- reg = <0x60004000 64>,
- <0x60004100 64>,
- <0x60004200 64>,
- <0x60004300 64>;
- interrupt-controller;
- #interrupt-cells = <3>;
- interrupt-parent = <&intc>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml
new file mode 100644
index 000000000000..074a873880e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/nvidia,tegra20-ictlr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 Legacy Interrupt Controller
+
+maintainers:
+ - Thierry Reding <treding@nvidia.com>
+ - Jonathan Hunter <jonathanh@nvidia.com>
+
+description: >
+ All Tegra SoCs contain a legacy interrupt controller that routes interrupts to
+ the GIC, and also serves as a wakeup source. It is also referred to as
+ "ictlr", hence the name of the binding.
+
+ The HW block exposes a number of interrupt controllers, each implementing a
+ set of 32 interrupts.
+
+ Notes:
+ - Because this HW ultimately routes interrupts to the GIC, the
+ interrupt specifier must be that of the GIC.
+ - Only SPIs can use the ictlr as an interrupt parent. SGIs and PPIs
+ are explicitly forbidden.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - nvidia,tegra114-ictlr
+ - nvidia,tegra124-ictlr
+ - const: nvidia,tegra30-ictlr
+ - enum:
+ - nvidia,tegra20-ictlr
+ - nvidia,tegra30-ictlr
+
+ reg:
+ description: Each entry is a block of 32 interrupts
+ minItems: 4
+ maxItems: 5
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra20-ictlr
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ else:
+ properties:
+ reg:
+ minItems: 5
+
+examples:
+ - |
+ interrupt-controller@60004000 {
+ compatible = "nvidia,tegra20-ictlr";
+ reg = <0x60004000 64>,
+ <0x60004100 64>,
+ <0x60004200 64>,
+ <0x60004300 64>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
deleted file mode 100644
index 0bfb3ba55f4c..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* NXP LPC32xx MIC, SIC1 and SIC2 Interrupt Controllers
-
-Required properties:
-- compatible: "nxp,lpc3220-mic" or "nxp,lpc3220-sic".
-- reg: should contain IC registers location and length.
-- interrupt-controller: identifies the node as an interrupt controller.
-- #interrupt-cells: the number of cells to define an interrupt, should be 2.
- The first cell is the IRQ number, the second cell is used to specify
- one of the supported IRQ types:
- IRQ_TYPE_EDGE_RISING = low-to-high edge triggered,
- IRQ_TYPE_EDGE_FALLING = high-to-low edge triggered,
- IRQ_TYPE_LEVEL_HIGH = active high level-sensitive,
- IRQ_TYPE_LEVEL_LOW = active low level-sensitive.
- Reset value is IRQ_TYPE_LEVEL_LOW.
-
-Optional properties:
-- interrupts: empty for MIC interrupt controller, cascaded MIC
- hardware interrupts for SIC1 and SIC2
-
-Examples:
-
- /* LPC32xx MIC, SIC1 and SIC2 interrupt controllers */
- mic: interrupt-controller@40008000 {
- compatible = "nxp,lpc3220-mic";
- reg = <0x40008000 0x4000>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- sic1: interrupt-controller@4000c000 {
- compatible = "nxp,lpc3220-sic";
- reg = <0x4000c000 0x4000>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- interrupt-parent = <&mic>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>,
- <30 IRQ_TYPE_LEVEL_LOW>;
- };
-
- sic2: interrupt-controller@40010000 {
- compatible = "nxp,lpc3220-sic";
- reg = <0x40010000 0x4000>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- interrupt-parent = <&mic>;
- interrupts = <1 IRQ_TYPE_LEVEL_LOW>,
- <31 IRQ_TYPE_LEVEL_LOW>;
- };
-
- /* ADC */
- adc@40048000 {
- compatible = "nxp,lpc3220-adc";
- reg = <0x40048000 0x1000>;
- interrupt-parent = <&sic1>;
- interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml
new file mode 100644
index 000000000000..724c869e3c40
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/nxp,lpc3220-mic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx MIC, SIC1 and SIC2 Interrupt Controllers
+
+maintainers:
+ - Vladimir Zapolskiy <vz@mleia.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,lpc3220-mic
+ - nxp,lpc3220-sic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ items:
+ - description: Regular interrupt request
+ - description: Fast interrupt request
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,lpc3220-sic
+ then:
+ required:
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mic: interrupt-controller@40008000 {
+ compatible = "nxp,lpc3220-mic";
+ reg = <0x40008000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ interrupt-controller@4000c000 {
+ compatible = "nxp,lpc3220-sic";
+ reg = <0x4000c000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&mic>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>,
+ <30 IRQ_TYPE_LEVEL_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt
deleted file mode 100644
index ccbbfdc53c72..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-* Open PIC Binding
-
-This binding specifies what properties must be available in the device tree
-representation of an Open PIC compliant interrupt controller. This binding is
-based on the binding defined for Open PIC in [1] and is a superset of that
-binding.
-
-Required properties:
-
- NOTE: Many of these descriptions were paraphrased here from [1] to aid
- readability.
-
- - compatible: Specifies the compatibility list for the PIC. The type
- shall be <string> and the value shall include "open-pic".
-
- - reg: Specifies the base physical address(s) and size(s) of this
- PIC's addressable register space. The type shall be <prop-encoded-array>.
-
- - interrupt-controller: The presence of this property identifies the node
- as an Open PIC. No property value shall be defined.
-
- - #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The type shall be a <u32> and the value shall be 2.
-
- - #address-cells: Specifies the number of cells needed to encode an
- address. The type shall be <u32> and the value shall be 0. As such,
- 'interrupt-map' nodes do not have to specify a parent unit address.
-
-Optional properties:
-
- - pic-no-reset: The presence of this property indicates that the PIC
- shall not be reset during runtime initialization. No property value shall
- be defined. The presence of this property also mandates that any
- initialization related to interrupt sources shall be limited to sources
- explicitly referenced in the device tree.
-
-* Interrupt Specifier Definition
-
- Interrupt specifiers consists of 2 cells encoded as
- follows:
-
- - <1st-cell>: The interrupt-number that identifies the interrupt source.
-
- - <2nd-cell>: The level-sense information, encoded as follows:
- 0 = low-to-high edge triggered
- 1 = active low level-sensitive
- 2 = active high level-sensitive
- 3 = high-to-low edge triggered
-
-* Examples
-
-Example 1:
-
- /*
- * An Open PIC interrupt controller
- */
- mpic: pic@40000 {
- // This is an interrupt controller node.
- interrupt-controller;
-
- // No address cells so that 'interrupt-map' nodes which reference
- // this Open PIC node do not need a parent address specifier.
- #address-cells = <0>;
-
- // Two cells to encode interrupt sources.
- #interrupt-cells = <2>;
-
- // Offset address of 0x40000 and size of 0x40000.
- reg = <0x40000 0x40000>;
-
- // Compatible with Open PIC.
- compatible = "open-pic";
-
- // The PIC shall not be reset.
- pic-no-reset;
- };
-
-Example 2:
-
- /*
- * An interrupt generating device that is wired to an Open PIC.
- */
- serial0: serial@4500 {
- // Interrupt source '42' that is active high level-sensitive.
- // Note that there are only two cells as specified in the interrupt
- // parent's '#interrupt-cells' property.
- interrupts = <42 2>;
-
- // The interrupt controller that this device is wired to.
- interrupt-parent = <&mpic>;
- };
-
-* References
-
-[1] Devicetree Specification
- (https://www.devicetree.org/specifications/)
-
diff --git a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt
deleted file mode 100644
index 55c04faa3f3f..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-OpenRISC 1000 Programmable Interrupt Controller
-
-Required properties:
-
-- compatible : should be "opencores,or1k-pic-level" for variants with
- level triggered interrupt lines, "opencores,or1k-pic-edge" for variants with
- edge triggered interrupt lines or "opencores,or1200-pic" for machines
- with the non-spec compliant or1200 type implementation.
-
- "opencores,or1k-pic" is also provided as an alias to "opencores,or1200-pic",
- but this is only for backwards compatibility.
-
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-Example:
-
-intc: interrupt-controller {
- compatible = "opencores,or1k-pic-level";
- interrupt-controller;
- #interrupt-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml
new file mode 100644
index 000000000000..995b68c3aed4
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/opencores,or1k-pic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OpenRISC 1000 Programmable Interrupt Controller
+
+maintainers:
+ - Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+
+properties:
+ compatible:
+ enum:
+ - opencores,or1k-pic-level
+ - opencores,or1k-pic-edge
+ - opencores,or1200-pic
+ - opencores,or1k-pic
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "opencores,or1k-pic-level";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt
deleted file mode 100644
index caec07cc7149..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Open Multi-Processor Interrupt Controller
-
-Required properties:
-
-- compatible : This should be "openrisc,ompic"
-- reg : Specifies base physical address and size of the register space. The
- size is based on the number of cores the controller has been configured
- to handle, this should be set to 8 bytes per cpu core.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : This should be set to 0 as this will not be an irq
- parent.
-- interrupts : Specifies the interrupt line to which the ompic is wired.
-
-Example:
-
-ompic: interrupt-controller@98000000 {
- compatible = "openrisc,ompic";
- reg = <0x98000000 16>;
- interrupt-controller;
- #interrupt-cells = <0>;
- interrupts = <1>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml
new file mode 100644
index 000000000000..4efbfba3aa6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/openrisc,ompic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Open Multi-Processor Interrupt Controller
+
+maintainers:
+ - Stafford Horne <shorne@gmail.com>
+
+properties:
+ compatible:
+ items:
+ - const: openrisc,ompic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@98000000 {
+ compatible = "openrisc,ompic";
+ reg = <0x98000000 16>;
+ interrupt-controller;
+ #interrupt-cells = <0>;
+ interrupts = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-cpu-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-cpu-intc.yaml
new file mode 100644
index 000000000000..ab32a91af4c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-cpu-intc.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/qca,ar7100-cpu-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros ath79 CPU interrupt controller
+
+maintainers:
+ - Alban Bedel <albeu@free.fr>
+
+description:
+ On most SoC the IRQ controller need to flush the DDR FIFO before running the
+ interrupt handler of some devices. This is configured using the
+ qca,ddr-wb-channels and qca,ddr-wb-channel-interrupts properties.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qca,ar9132-cpu-intc
+ - const: qca,ar7100-cpu-intc
+ - items:
+ - const: qca,ar7100-cpu-intc
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ qca,ddr-wb-channel-interrupts:
+ description: List of interrupts needing a write buffer flush
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ qca,ddr-wb-channels:
+ description: List of write buffer channel phandles for each interrupt
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "qca,ar9132-cpu-intc", "qca,ar7100-cpu-intc";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ qca,ddr-wb-channel-interrupts = <2>, <3>, <4>, <5>;
+ qca,ddr-wb-channels = <&ddr_ctrl 3>, <&ddr_ctrl 2>,
+ <&ddr_ctrl 0>, <&ddr_ctrl 1>;
+ };
+
+ ddr_ctrl: memory-controller {
+ #qca,ddr-wb-channel-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-misc-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-misc-intc.yaml
new file mode 100644
index 000000000000..ae813189f5ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/qca,ar7100-misc-intc.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/qca,ar7100-misc-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros AR7xxx/AR9XXX MISC interrupt controller
+
+maintainers:
+ - Alban Bedel <albeu@free.fr>
+ - Alexander Couzens <lynxis@fe80.eu>
+
+description:
+ The Qualcomm Atheros AR7xxx/AR9XXX MISC interrupt controller is a secondary
+ controller for lower priority interrupts.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qca,ar9132-misc-intc
+ - const: qca,ar7100-misc-intc
+ - const: qca,ar7240-misc-intc
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+examples:
+ - |
+ interrupt-controller@18060010 {
+ compatible = "qca,ar9132-misc-intc", "qca,ar7100-misc-intc";
+ reg = <0x18060010 0x4>;
+ interrupts = <6>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-cpu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-cpu-intc.txt
deleted file mode 100644
index aabce7810d29..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-cpu-intc.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Binding for Qualcomm Atheros AR7xxx/AR9XXX CPU interrupt controller
-
-On most SoC the IRQ controller need to flush the DDR FIFO before running
-the interrupt handler of some devices. This is configured using the
-qca,ddr-wb-channels and qca,ddr-wb-channel-interrupts properties.
-
-Required Properties:
-
-- compatible: has to be "qca,<soctype>-cpu-intc", "qca,ar7100-cpu-intc"
- as fallback
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode interrupt
- source, should be 1 for intc
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-Optional Properties:
-
-- qca,ddr-wb-channel-interrupts: List of the interrupts needing a write
- buffer flush
-- qca,ddr-wb-channels: List of phandles to the write buffer channels for
- each interrupt. If qca,ddr-wb-channel-interrupts is not present the interrupt
- default to the entry's index.
-
-Example:
-
- interrupt-controller {
- compatible = "qca,ar9132-cpu-intc", "qca,ar7100-cpu-intc";
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- qca,ddr-wb-channel-interrupts = <2>, <3>, <4>, <5>;
- qca,ddr-wb-channels = <&ddr_ctrl 3>, <&ddr_ctrl 2>,
- <&ddr_ctrl 0>, <&ddr_ctrl 1>;
- };
-
- ...
-
- ddr_ctrl: memory-controller@18000000 {
- ...
- #qca,ddr-wb-channel-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
deleted file mode 100644
index ad70006c1848..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Binding for Qualcomm Atheros AR7xxx/AR9XXX MISC interrupt controller
-
-The MISC interrupt controller is a secondary controller for lower priority
-interrupt.
-
-Required Properties:
-- compatible: has to be "qca,<soctype>-cpu-intc", "qca,ar7100-misc-intc" or
- "qca,<soctype>-cpu-intc", "qca,ar7240-misc-intc"
-- reg: Base address and size of the controllers memory area
-- interrupts: Interrupt specifier for the controllers interrupt.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode interrupt
- source, should be 1
-
-Compatible fallback depends on the SoC. Use ar7100 for ar71xx and ar913x,
-use ar7240 for all other SoCs.
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-Example:
-
- interrupt-controller@18060010 {
- compatible = "qca,ar9132-misc-intc", "qca,ar7100-misc-intc";
- reg = <0x18060010 0x4>;
-
- interrupt-parent = <&cpuintc>;
- interrupts = <6>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
- };
-
-Another example:
-
- interrupt-controller@18060010 {
- compatible = "qca,ar9331-misc-intc", qca,ar7240-misc-intc";
- reg = <0x18060010 0x4>;
-
- interrupt-parent = <&cpuintc>;
- interrupts = <6>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
index 509d20c091af..ebb40c48950a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
@@ -29,6 +29,12 @@ properties:
maxItems: 1
description:
Specifies the base address and size of vMPM registers in RPM MSG RAM.
+ deprecated: true
+
+ qcom,rpm-msg-ram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the APSS MPM slice of the RPM Message RAM
interrupts:
maxItems: 1
@@ -62,35 +68,51 @@ properties:
- description: MPM pin number
- description: GIC SPI number for the MPM pin
+ '#power-domain-cells':
+ const: 0
+
required:
- compatible
- - reg
- interrupts
- mboxes
- interrupt-controller
- '#interrupt-cells'
- qcom,mpm-pin-count
- qcom,mpm-pin-map
+ - qcom,rpm-msg-ram
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- mpm: interrupt-controller@45f01b8 {
- compatible = "qcom,mpm";
- interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
- reg = <0x45f01b8 0x1000>;
- mboxes = <&apcs_glb 1>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <&intc>;
- qcom,mpm-pin-count = <96>;
- qcom,mpm-pin-map = <2 275>,
- <5 296>,
- <12 422>,
- <24 79>,
- <86 183>,
- <90 260>,
- <91 260>;
+
+ remoteproc-rpm {
+ compatible = "qcom,msm8998-rpm-proc", "qcom,rpm-proc";
+
+ glink-edge {
+ compatible = "qcom,glink-rpm";
+
+ interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+ mboxes = <&apcs_glb 0>;
+ };
+
+ mpm: interrupt-controller {
+ compatible = "qcom,mpm";
+ qcom,rpm-msg-ram = <&apss_mpm>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&intc>;
+ qcom,mpm-pin-count = <96>;
+ qcom,mpm-pin-map = <2 275>,
+ <5 296>,
+ <12 422>,
+ <24 79>,
+ <86 183>,
+ <91 260>;
+ #power-domain-cells = <0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
deleted file mode 100644
index 159a423e5586..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-PDC interrupt controller
-
-Qualcomm Technologies Inc. SoCs based on the RPM Hardened architecture have a
-Power Domain Controller (PDC) that is on always-on domain. In addition to
-providing power control for the power domains, the hardware also has an
-interrupt controller that can be used to help detect edge low interrupts as
-well detect interrupts when the GIC is non-operational.
-
-GIC is parent interrupt controller at the highest level. Platform interrupt
-controller PDC is next in hierarchy, followed by others. Drivers requiring
-wakeup capabilities of their device interrupts routed through the PDC, must
-specify PDC as their interrupt controller and request the PDC port associated
-with the GIC interrupt. See example below.
-
-Properties:
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Should contain "qcom,<soc>-pdc" and "qcom,pdc"
- - "qcom,sc7180-pdc": For SC7180
- - "qcom,sc7280-pdc": For SC7280
- - "qcom,sdm845-pdc": For SDM845
- - "qcom,sm6350-pdc": For SM6350
- - "qcom,sm8150-pdc": For SM8150
- - "qcom,sm8250-pdc": For SM8250
- - "qcom,sm8350-pdc": For SM8350
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Specifies the base physical address for PDC hardware.
-
-- interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: Specifies the number of cells needed to encode an interrupt
- source.
- Must be 2.
- The first element of the tuple is the PDC pin for the
- interrupt.
- The second element is the trigger type.
-
-- interrupt-controller:
- Usage: required
- Value type: <bool>
- Definition: Identifies the node as an interrupt controller.
-
-- qcom,pdc-ranges:
- Usage: required
- Value type: <u32 array>
- Definition: Specifies the PDC pin offset and the number of PDC ports.
- The tuples indicates the valid mapping of valid PDC ports
- and their hwirq mapping.
- The first element of the tuple is the starting PDC port.
- The second element is the GIC hwirq number for the PDC port.
- The third element is the number of interrupts in sequence.
-
-Example:
-
- pdc: interrupt-controller@b220000 {
- compatible = "qcom,sdm845-pdc";
- reg = <0xb220000 0x30000>;
- qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
- #interrupt-cells = <2>;
- interrupt-parent = <&intc>;
- interrupt-controller;
- };
-
-DT binding of a device that wants to use the GIC SPI 514 as a wakeup
-interrupt, must do -
-
- wake-device {
- interrupts-extended = <&pdc 2 IRQ_TYPE_LEVEL_HIGH>;
- };
-
-In this case interrupt 514 would be mapped to port 2 on the PDC as defined by
-the qcom,pdc-ranges property.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
new file mode 100644
index 000000000000..38d0c2d57dd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/qcom,pdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PDC interrupt controller
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Qualcomm Technologies Inc. SoCs based on the RPM Hardened architecture have a
+ Power Domain Controller (PDC) that is on always-on domain. In addition to
+ providing power control for the power domains, the hardware also has an
+ interrupt controller that can be used to help detect edge low interrupts as
+ well detect interrupts when the GIC is non-operational.
+
+ GIC is parent interrupt controller at the highest level. Platform interrupt
+ controller PDC is next in hierarchy, followed by others. Drivers requiring
+ wakeup capabilities of their device interrupts routed through the PDC, must
+ specify PDC as their interrupt controller and request the PDC port associated
+ with the GIC interrupt. See example below.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,glymur-pdc
+ - qcom,qcs615-pdc
+ - qcom,qcs8300-pdc
+ - qcom,qdu1000-pdc
+ - qcom,sa8255p-pdc
+ - qcom,sa8775p-pdc
+ - qcom,sar2130p-pdc
+ - qcom,sc7180-pdc
+ - qcom,sc7280-pdc
+ - qcom,sc8180x-pdc
+ - qcom,sc8280xp-pdc
+ - qcom,sdm670-pdc
+ - qcom,sdm845-pdc
+ - qcom,sdx55-pdc
+ - qcom,sdx65-pdc
+ - qcom,sdx75-pdc
+ - qcom,sm4450-pdc
+ - qcom,sm6350-pdc
+ - qcom,sm8150-pdc
+ - qcom,sm8250-pdc
+ - qcom,sm8350-pdc
+ - qcom,sm8450-pdc
+ - qcom,sm8550-pdc
+ - qcom,sm8650-pdc
+ - qcom,sm8750-pdc
+ - qcom,x1e80100-pdc
+ - const: qcom,pdc
+
+ reg:
+ minItems: 1
+ items:
+ - description: PDC base register region
+ - description: Edge or Level config register for SPI interrupts
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ qcom,pdc-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 128 # no hard limit
+ items:
+ items:
+ - description: starting PDC port
+ - description: GIC hwirq number for the PDC port
+ - description: number of interrupts in sequence
+ description: |
+ Specifies the PDC pin offset and the number of PDC ports.
+ The tuples indicates the valid mapping of valid PDC ports
+ and their hwirq mapping.
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+ - qcom,pdc-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pdc: interrupt-controller@b220000 {
+ compatible = "qcom,sdm845-pdc", "qcom,pdc";
+ reg = <0xb220000 0x30000>;
+ qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&intc>;
+ interrupt-controller;
+ };
+
+ wake-device {
+ interrupts-extended = <&pdc 2 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml
new file mode 100644
index 000000000000..0fa952a9edfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ralink,rt2880-intc.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ralink,rt2880-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink SoCs Interrupt Controller
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description:
+ This interrupt controller support a central point for interrupt aggregation
+ for platform related blocks.
+
+properties:
+ compatible:
+ const: ralink,rt2880-intc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@200 {
+ compatible = "ralink,rt2880-intc";
+ reg = <0x200 0x100>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
index 9e76fff20323..833a01cdd1b1 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
@@ -4,7 +4,15 @@
$id: http://devicetree.org/schemas/interrupt-controller/realtek,rtl-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Realtek RTL SoC interrupt controller devicetree bindings
+title: Realtek RTL SoC interrupt controller
+
+description:
+ Interrupt controller and router for Realtek MIPS SoCs, allowing each SoC
+ interrupt to be routed to one parent CPU (hardware) interrupt, or left
+ disconnected.
+ All connected input lines from SoC peripherals can be masked individually,
+ and an interrupt status register is present to indicate which interrupts are
+ pending.
maintainers:
- Birger Koblitz <mail@birger-koblitz.de>
@@ -13,23 +21,37 @@ maintainers:
properties:
compatible:
- const: realtek,rtl-intc
+ oneOf:
+ - items:
+ - enum:
+ - realtek,rtl8380-intc
+ - realtek,rtl9300-intc
+ - const: realtek,rtl-intc
+ - const: realtek,rtl-intc
+ deprecated: true
"#interrupt-cells":
+ description:
+ SoC interrupt line index.
const: 1
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: vpe0 registers
+ - description: vpe1 registers
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 15
+ description:
+ List of parent interrupts, in the order that they are connected to this
+ interrupt router's outputs, starting at the first output.
interrupt-controller: true
- "#address-cells":
- const: 0
-
interrupt-map:
+ deprecated: true
description: Describes mapping from SoC interrupts to CPU interrupts
required:
@@ -37,21 +59,47 @@ required:
- reg
- "#interrupt-cells"
- interrupt-controller
- - "#address-cells"
- - interrupt-map
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: realtek,rtl-intc
+ then:
+ properties:
+ "#address-cells":
+ const: 0
+ required:
+ - "#address-cells"
+ - interrupt-map
+ else:
+ required:
+ - interrupts
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: realtek,rtl9300-intc
+ then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+ else:
+ properties:
+ reg:
+ maxItems: 1
additionalProperties: false
examples:
- |
- intc: interrupt-controller@3000 {
- compatible = "realtek,rtl-intc";
+ interrupt-controller@3000 {
+ compatible = "realtek,rtl8380-intc", "realtek,rtl-intc";
#interrupt-cells = <1>;
interrupt-controller;
- reg = <0x3000 0x20>;
- #address-cells = <0>;
- interrupt-map =
- <31 &cpuintc 2>,
- <30 &cpuintc 1>,
- <29 &cpuintc 5>;
+ reg = <0x3000 0x18>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <2>, <3>, <4>, <5>, <6>;
};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
index 620f01775e42..fb3c29e81349 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/renesas,irqc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DT bindings for the R-Mobile/R-Car/RZ/G interrupt controller
+title: R-Mobile/R-Car/RZ/G interrupt controller
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
@@ -37,6 +37,9 @@ properties:
- renesas,intc-ex-r8a77990 # R-Car E3
- renesas,intc-ex-r8a77995 # R-Car D3
- renesas,intc-ex-r8a779a0 # R-Car V3U
+ - renesas,intc-ex-r8a779f0 # R-Car S4-8
+ - renesas,intc-ex-r8a779g0 # R-Car V4H
+ - renesas,intc-ex-r8a779h0 # R-Car V4M
- const: renesas,irqc
'#interrupt-cells':
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
index 33b90e975e33..44b6ae5fc802 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml
@@ -19,20 +19,23 @@ description: |
- NMI edge select (NMI is not treated as NMI exception and supports fall edge and
stand-up edge detection interrupts)
-allOf:
- - $ref: /schemas/interrupt-controller.yaml#
-
properties:
compatible:
- items:
- - enum:
- - renesas,r9a07g044-irqc # RZ/G2{L,LC}
- - renesas,r9a07g054-irqc # RZ/V2L
- - const: renesas,rzg2l-irqc
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043u-irqc # RZ/G2UL
+ - renesas,r9a07g044-irqc # RZ/G2{L,LC}
+ - renesas,r9a07g054-irqc # RZ/V2L
+ - renesas,r9a08g045-irqc # RZ/G3S
+ - const: renesas,rzg2l-irqc
+
+ - const: renesas,r9a07g043f-irqc # RZ/Five
'#interrupt-cells':
- description: The first cell should contain external interrupt number (IRQ0-7) and the
- second cell is used to specify the flag.
+ description: The first cell should contain a macro RZG2L_{NMI,IRQX} included in the
+ include/dt-bindings/interrupt-controller/irqc-rzg2l.h and the second
+ cell is used to specify the flag.
const: 2
'#address-cells':
@@ -44,7 +47,108 @@ properties:
maxItems: 1
interrupts:
- maxItems: 41
+ minItems: 45
+ items:
+ - description: NMI interrupt
+ - description: IRQ0 interrupt
+ - description: IRQ1 interrupt
+ - description: IRQ2 interrupt
+ - description: IRQ3 interrupt
+ - description: IRQ4 interrupt
+ - description: IRQ5 interrupt
+ - description: IRQ6 interrupt
+ - description: IRQ7 interrupt
+ - description: GPIO interrupt, TINT0
+ - description: GPIO interrupt, TINT1
+ - description: GPIO interrupt, TINT2
+ - description: GPIO interrupt, TINT3
+ - description: GPIO interrupt, TINT4
+ - description: GPIO interrupt, TINT5
+ - description: GPIO interrupt, TINT6
+ - description: GPIO interrupt, TINT7
+ - description: GPIO interrupt, TINT8
+ - description: GPIO interrupt, TINT9
+ - description: GPIO interrupt, TINT10
+ - description: GPIO interrupt, TINT11
+ - description: GPIO interrupt, TINT12
+ - description: GPIO interrupt, TINT13
+ - description: GPIO interrupt, TINT14
+ - description: GPIO interrupt, TINT15
+ - description: GPIO interrupt, TINT16
+ - description: GPIO interrupt, TINT17
+ - description: GPIO interrupt, TINT18
+ - description: GPIO interrupt, TINT19
+ - description: GPIO interrupt, TINT20
+ - description: GPIO interrupt, TINT21
+ - description: GPIO interrupt, TINT22
+ - description: GPIO interrupt, TINT23
+ - description: GPIO interrupt, TINT24
+ - description: GPIO interrupt, TINT25
+ - description: GPIO interrupt, TINT26
+ - description: GPIO interrupt, TINT27
+ - description: GPIO interrupt, TINT28
+ - description: GPIO interrupt, TINT29
+ - description: GPIO interrupt, TINT30
+ - description: GPIO interrupt, TINT31
+ - description: Bus error interrupt
+ - description: ECCRAM0 or combined ECCRAM0/1 1bit error interrupt
+ - description: ECCRAM0 or combined ECCRAM0/1 2bit error interrupt
+ - description: ECCRAM0 or combined ECCRAM0/1 error overflow interrupt
+ - description: ECCRAM1 1bit error interrupt
+ - description: ECCRAM1 2bit error interrupt
+ - description: ECCRAM1 error overflow interrupt
+
+ interrupt-names:
+ minItems: 45
+ items:
+ - const: nmi
+ - const: irq0
+ - const: irq1
+ - const: irq2
+ - const: irq3
+ - const: irq4
+ - const: irq5
+ - const: irq6
+ - const: irq7
+ - const: tint0
+ - const: tint1
+ - const: tint2
+ - const: tint3
+ - const: tint4
+ - const: tint5
+ - const: tint6
+ - const: tint7
+ - const: tint8
+ - const: tint9
+ - const: tint10
+ - const: tint11
+ - const: tint12
+ - const: tint13
+ - const: tint14
+ - const: tint15
+ - const: tint16
+ - const: tint17
+ - const: tint18
+ - const: tint19
+ - const: tint20
+ - const: tint21
+ - const: tint22
+ - const: tint23
+ - const: tint24
+ - const: tint25
+ - const: tint26
+ - const: tint27
+ - const: tint28
+ - const: tint29
+ - const: tint30
+ - const: tint31
+ - const: bus-err
+ - const: ec7tie1-0
+ - const: ec7tie2-0
+ - const: ec7tiovf-0
+ - const: ec7tie1-1
+ - const: ec7tie2-1
+ - const: ec7tiovf-1
clocks:
maxItems: 2
@@ -67,11 +171,34 @@ required:
- interrupt-controller
- reg
- interrupts
+ - interrupt-names
- clocks
- clock-names
- power-domains
- resets
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a08g045-irqc
+ then:
+ properties:
+ interrupts:
+ maxItems: 45
+ interrupt-names:
+ maxItems: 45
+ else:
+ properties:
+ interrupts:
+ minItems: 48
+ interrupt-names:
+ minItems: 48
+
unevaluatedProperties: false
examples:
@@ -80,55 +207,76 @@ examples:
#include <dt-bindings/clock/r9a07g044-cpg.h>
irqc: interrupt-controller@110a0000 {
- compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc";
- reg = <0x110a0000 0x10000>;
- #interrupt-cells = <2>;
- #address-cells = <0>;
- interrupt-controller;
- interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>,
- <&cpg CPG_MOD R9A07G044_IA55_PCLK>;
- clock-names = "clk", "pclk";
- power-domains = <&cpg>;
- resets = <&cpg R9A07G044_IA55_RESETN>;
+ compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc";
+ reg = <0x110a0000 0x10000>;
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 37 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 38 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 39 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "nmi",
+ "irq0", "irq1", "irq2", "irq3",
+ "irq4", "irq5", "irq6", "irq7",
+ "tint0", "tint1", "tint2", "tint3",
+ "tint4", "tint5", "tint6", "tint7",
+ "tint8", "tint9", "tint10", "tint11",
+ "tint12", "tint13", "tint14", "tint15",
+ "tint16", "tint17", "tint18", "tint19",
+ "tint20", "tint21", "tint22", "tint23",
+ "tint24", "tint25", "tint26", "tint27",
+ "tint28", "tint29", "tint30", "tint31",
+ "bus-err", "ec7tie1-0", "ec7tie2-0",
+ "ec7tiovf-0", "ec7tie1-1", "ec7tie2-1",
+ "ec7tiovf-1";
+ clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>,
+ <&cpg CPG_MOD R9A07G044_IA55_PCLK>;
+ clock-names = "clk", "pclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_IA55_RESETN>;
};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml
new file mode 100644
index 000000000000..3f99c8645767
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml
@@ -0,0 +1,280 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/renesas,rzv2h-icu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/{G3E,V2H(P)} Interrupt Control Unit
+
+maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description:
+ The Interrupt Control Unit (ICU) handles external interrupts (NMI, IRQ, and
+ TINT), error interrupts, DMAC requests, GPT interrupts, and internal
+ interrupts.
+
+properties:
+ compatible:
+ enum:
+ - renesas,r9a09g047-icu # RZ/G3E
+ - renesas,r9a09g057-icu # RZ/V2H(P)
+
+ '#interrupt-cells':
+ description: The first cell is the SPI number of the NMI or the
+ PORT_IRQ[0-15] interrupt, as per user manual. The second cell is used to
+ specify the flag.
+ const: 2
+
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 58
+ items:
+ - description: NMI interrupt
+ - description: PORT_IRQ0 interrupt
+ - description: PORT_IRQ1 interrupt
+ - description: PORT_IRQ2 interrupt
+ - description: PORT_IRQ3 interrupt
+ - description: PORT_IRQ4 interrupt
+ - description: PORT_IRQ5 interrupt
+ - description: PORT_IRQ6 interrupt
+ - description: PORT_IRQ7 interrupt
+ - description: PORT_IRQ8 interrupt
+ - description: PORT_IRQ9 interrupt
+ - description: PORT_IRQ10 interrupt
+ - description: PORT_IRQ11 interrupt
+ - description: PORT_IRQ12 interrupt
+ - description: PORT_IRQ13 interrupt
+ - description: PORT_IRQ14 interrupt
+ - description: PORT_IRQ15 interrupt
+ - description: GPIO interrupt, TINT0
+ - description: GPIO interrupt, TINT1
+ - description: GPIO interrupt, TINT2
+ - description: GPIO interrupt, TINT3
+ - description: GPIO interrupt, TINT4
+ - description: GPIO interrupt, TINT5
+ - description: GPIO interrupt, TINT6
+ - description: GPIO interrupt, TINT7
+ - description: GPIO interrupt, TINT8
+ - description: GPIO interrupt, TINT9
+ - description: GPIO interrupt, TINT10
+ - description: GPIO interrupt, TINT11
+ - description: GPIO interrupt, TINT12
+ - description: GPIO interrupt, TINT13
+ - description: GPIO interrupt, TINT14
+ - description: GPIO interrupt, TINT15
+ - description: GPIO interrupt, TINT16
+ - description: GPIO interrupt, TINT17
+ - description: GPIO interrupt, TINT18
+ - description: GPIO interrupt, TINT19
+ - description: GPIO interrupt, TINT20
+ - description: GPIO interrupt, TINT21
+ - description: GPIO interrupt, TINT22
+ - description: GPIO interrupt, TINT23
+ - description: GPIO interrupt, TINT24
+ - description: GPIO interrupt, TINT25
+ - description: GPIO interrupt, TINT26
+ - description: GPIO interrupt, TINT27
+ - description: GPIO interrupt, TINT28
+ - description: GPIO interrupt, TINT29
+ - description: GPIO interrupt, TINT30
+ - description: GPIO interrupt, TINT31
+ - description: Software interrupt, INTA55_0
+ - description: Software interrupt, INTA55_1
+ - description: Software interrupt, INTA55_2
+ - description: Software interrupt, INTA55_3
+ - description: Error interrupt to CA55
+ - description: GTCCRA compare match/input capture (U0)
+ - description: GTCCRB compare match/input capture (U0)
+ - description: GTCCRA compare match/input capture (U1)
+ - description: GTCCRB compare match/input capture (U1)
+
+ interrupt-names:
+ minItems: 58
+ items:
+ - const: nmi
+ - const: port_irq0
+ - const: port_irq1
+ - const: port_irq2
+ - const: port_irq3
+ - const: port_irq4
+ - const: port_irq5
+ - const: port_irq6
+ - const: port_irq7
+ - const: port_irq8
+ - const: port_irq9
+ - const: port_irq10
+ - const: port_irq11
+ - const: port_irq12
+ - const: port_irq13
+ - const: port_irq14
+ - const: port_irq15
+ - const: tint0
+ - const: tint1
+ - const: tint2
+ - const: tint3
+ - const: tint4
+ - const: tint5
+ - const: tint6
+ - const: tint7
+ - const: tint8
+ - const: tint9
+ - const: tint10
+ - const: tint11
+ - const: tint12
+ - const: tint13
+ - const: tint14
+ - const: tint15
+ - const: tint16
+ - const: tint17
+ - const: tint18
+ - const: tint19
+ - const: tint20
+ - const: tint21
+ - const: tint22
+ - const: tint23
+ - const: tint24
+ - const: tint25
+ - const: tint26
+ - const: tint27
+ - const: tint28
+ - const: tint29
+ - const: tint30
+ - const: tint31
+ - const: int-ca55-0
+ - const: int-ca55-1
+ - const: int-ca55-2
+ - const: int-ca55-3
+ - const: icu-error-ca55
+ - const: gpt-u0-gtciada
+ - const: gpt-u0-gtciadb
+ - const: gpt-u1-gtciada
+ - const: gpt-u1-gtciadb
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - '#address-cells'
+ - interrupt-controller
+ - interrupts
+ - interrupt-names
+ - clocks
+ - power-domains
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/renesas-cpg-mssr.h>
+
+ icu: interrupt-controller@10400000 {
+ compatible = "renesas,r9a09g057-icu";
+ reg = <0x10400000 0x10000>;
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 434 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 435 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 437 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 438 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 439 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 440 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 441 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 442 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 443 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 262 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 263 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 265 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "nmi",
+ "port_irq0", "port_irq1", "port_irq2",
+ "port_irq3", "port_irq4", "port_irq5",
+ "port_irq6", "port_irq7", "port_irq8",
+ "port_irq9", "port_irq10", "port_irq11",
+ "port_irq12", "port_irq13", "port_irq14",
+ "port_irq15",
+ "tint0", "tint1", "tint2", "tint3",
+ "tint4", "tint5", "tint6", "tint7",
+ "tint8", "tint9", "tint10", "tint11",
+ "tint12", "tint13", "tint14", "tint15",
+ "tint16", "tint17", "tint18", "tint19",
+ "tint20", "tint21", "tint22", "tint23",
+ "tint24", "tint25", "tint26", "tint27",
+ "tint28", "tint29", "tint30", "tint31",
+ "int-ca55-0", "int-ca55-1",
+ "int-ca55-2", "int-ca55-3",
+ "icu-error-ca55",
+ "gpt-u0-gtciada", "gpt-u0-gtciadb",
+ "gpt-u1-gtciada", "gpt-u1-gtciadb";
+ clocks = <&cpg CPG_MOD 0x5>;
+ power-domains = <&cpg>;
+ resets = <&cpg 0x36>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
new file mode 100644
index 000000000000..bef00521d5da
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/riscv,aplic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V Advanced Platform Level Interrupt Controller (APLIC)
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description:
+ The RISC-V advanced interrupt architecture (AIA) defines an advanced
+ platform level interrupt controller (APLIC) for handling wired interrupts
+ in a RISC-V platform. The RISC-V AIA specification can be found at
+ https://github.com/riscv/riscv-aia.
+
+ The RISC-V APLIC is implemented as hierarchical APLIC domains where all
+ interrupt sources connect to the root APLIC domain and a parent APLIC
+ domain can delegate interrupt sources to it's child APLIC domains. There
+ is one device tree node for each APLIC domain.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qemu,aplic
+ - const: riscv,aplic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 16384
+ description:
+ Given APLIC domain directly injects external interrupts to a set of
+ RISC-V HARTS (or CPUs). Each node pointed to should be a riscv,cpu-intc
+ node, which has a CPU node (i.e. RISC-V HART) as parent.
+
+ msi-parent:
+ description:
+ Given APLIC domain forwards wired interrupts as MSIs to a AIA incoming
+ message signaled interrupt controller (IMSIC). If both "msi-parent" and
+ "interrupts-extended" properties are present then it means the APLIC
+ domain supports both MSI mode and Direct mode in HW. In this case, the
+ APLIC driver has to choose between MSI mode or Direct mode.
+
+ riscv,num-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 1023
+ description:
+ Specifies the number of wired interrupt sources supported by this
+ APLIC domain.
+
+ riscv,children:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 1024
+ items:
+ maxItems: 1
+ description:
+ A list of child APLIC domains for the given APLIC domain. Each child
+ APLIC domain is assigned a child index in increasing order, with the
+ first child APLIC domain assigned child index 0. The APLIC domain child
+ index is used by firmware to delegate interrupts from the given APLIC
+ domain to a particular child APLIC domain.
+
+ riscv,delegation:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 1024
+ items:
+ items:
+ - description: child APLIC domain phandle
+ - description: first interrupt number of the parent APLIC domain (inclusive)
+ - description: last interrupt number of the parent APLIC domain (inclusive)
+ description:
+ A interrupt delegation list where each entry is a triple consisting
+ of child APLIC domain phandle, first interrupt number of the parent
+ APLIC domain, and last interrupt number of the parent APLIC domain.
+ Firmware must configure interrupt delegation registers based on
+ interrupt delegation list.
+
+ riscv,hart-indexes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 16384
+ description:
+ A list of hart indexes that APLIC should use to address each hart
+ that is mentioned in the "interrupts-extended"
+
+dependencies:
+ riscv,delegation: [ "riscv,children" ]
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+ - riscv,num-sources
+
+anyOf:
+ - required:
+ - interrupts-extended
+ - required:
+ - msi-parent
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example 1 (APLIC domains directly injecting interrupt to HARTs):
+
+ interrupt-controller@c000000 {
+ compatible = "qemu,aplic", "riscv,aplic";
+ interrupts-extended = <&cpu1_intc 11>,
+ <&cpu2_intc 11>,
+ <&cpu3_intc 11>,
+ <&cpu4_intc 11>;
+ reg = <0xc000000 0x4080>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ riscv,num-sources = <63>;
+ riscv,children = <&aplic1>, <&aplic2>;
+ riscv,delegation = <&aplic1 1 63>;
+ };
+
+ aplic1: interrupt-controller@d000000 {
+ compatible = "qemu,aplic", "riscv,aplic";
+ interrupts-extended = <&cpu1_intc 9>,
+ <&cpu2_intc 9>;
+ reg = <0xd000000 0x4080>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ riscv,num-sources = <63>;
+ };
+
+ aplic2: interrupt-controller@e000000 {
+ compatible = "qemu,aplic", "riscv,aplic";
+ interrupts-extended = <&cpu3_intc 9>,
+ <&cpu4_intc 9>;
+ reg = <0xe000000 0x4080>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ riscv,num-sources = <63>;
+ };
+
+ - |
+ // Example 2 (APLIC domains forwarding interrupts as MSIs):
+
+ interrupt-controller@c000000 {
+ compatible = "qemu,aplic", "riscv,aplic";
+ msi-parent = <&imsic_mlevel>;
+ reg = <0xc000000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ riscv,num-sources = <63>;
+ riscv,children = <&aplic3>;
+ riscv,delegation = <&aplic3 1 63>;
+ };
+
+ aplic3: interrupt-controller@d000000 {
+ compatible = "qemu,aplic", "riscv,aplic";
+ msi-parent = <&imsic_slevel>;
+ reg = <0xd000000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ riscv,num-sources = <63>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
deleted file mode 100644
index 265b223cd978..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-RISC-V Hart-Level Interrupt Controller (HLIC)
----------------------------------------------
-
-RISC-V cores include Control Status Registers (CSRs) which are local to each
-CPU core (HART in RISC-V terminology) and can be read or written by software.
-Some of these CSRs are used to control local interrupts connected to the core.
-Every interrupt is ultimately routed through a hart's HLIC before it
-interrupts that hart.
-
-The RISC-V supervisor ISA manual specifies three interrupt sources that are
-attached to every HLIC: software interrupts, the timer interrupt, and external
-interrupts. Software interrupts are used to send IPIs between cores. The
-timer interrupt comes from an architecturally mandated real-time timer that is
-controlled via Supervisor Binary Interface (SBI) calls and CSR reads. External
-interrupts connect all other device interrupts to the HLIC, which are routed
-via the platform-level interrupt controller (PLIC).
-
-All RISC-V systems that conform to the supervisor ISA specification are
-required to have a HLIC with these three interrupt sources present. Since the
-interrupt map is defined by the ISA it's not listed in the HLIC's device tree
-entry, though external interrupt controllers (like the PLIC, for example) will
-need to define how their interrupts map to the relevant HLICs. This means
-a PLIC interrupt property will typically list the HLICs for all present HARTs
-in the system.
-
-Required properties:
-- compatible : "riscv,cpu-intc"
-- #interrupt-cells : should be <1>. The interrupt sources are defined by the
- RISC-V supervisor ISA manual, with only the following three interrupts being
- defined for supervisor mode:
- - Source 1 is the supervisor software interrupt, which can be sent by an SBI
- call and is reserved for use by software.
- - Source 5 is the supervisor timer interrupt, which can be configured by
- SBI calls and implements a one-shot timer.
- - Source 9 is the supervisor external interrupt, which chains to all other
- device interrupts.
-- interrupt-controller : Identifies the node as an interrupt controller
-
-Furthermore, this interrupt-controller MUST be embedded inside the cpu
-definition of the hart whose CSRs control these local interrupts.
-
-An example device tree entry for a HLIC is show below.
-
- cpu1: cpu@1 {
- compatible = "riscv";
- ...
- cpu1-intc: interrupt-controller {
- #interrupt-cells = <1>;
- compatible = "sifive,fu540-c000-cpu-intc", "riscv,cpu-intc";
- interrupt-controller;
- };
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.yaml
new file mode 100644
index 000000000000..83256cc0bd5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/riscv,cpu-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V Hart-Level Interrupt Controller (HLIC)
+
+description:
+ RISC-V cores include Control Status Registers (CSRs) which are local to
+ each CPU core (HART in RISC-V terminology) and can be read or written by
+ software. Some of these CSRs are used to control local interrupts connected
+ to the core. Every interrupt is ultimately routed through a hart's HLIC
+ before it interrupts that hart.
+
+ The RISC-V supervisor ISA manual specifies three interrupt sources that are
+ attached to every HLIC namely software interrupts, the timer interrupt, and
+ external interrupts. Software interrupts are used to send IPIs between
+ cores. The timer interrupt comes from an architecturally mandated real-
+ time timer that is controlled via Supervisor Binary Interface (SBI) calls
+ and CSR reads. External interrupts connect all other device interrupts to
+ the HLIC, which are routed via the platform-level interrupt controller
+ (PLIC).
+
+ All RISC-V systems that conform to the supervisor ISA specification are
+ required to have a HLIC with these three interrupt sources present. Since
+ the interrupt map is defined by the ISA it's not listed in the HLIC's device
+ tree entry, though external interrupt controllers (like the PLIC, for
+ example) will need to define how their interrupts map to the relevant HLICs.
+ This means a PLIC interrupt property will typically list the HLICs for all
+ present HARTs in the system.
+
+maintainers:
+ - Palmer Dabbelt <palmer@dabbelt.com>
+ - Paul Walmsley <paul.walmsley@sifive.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: andestech,cpu-intc
+ - const: riscv,cpu-intc
+ - const: riscv,cpu-intc
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+ description: |
+ The interrupt sources are defined by the RISC-V supervisor ISA manual,
+ with only the following three interrupts being defined for
+ supervisor mode:
+ - Source 1 is the supervisor software interrupt, which can be sent by
+ an SBI call and is reserved for use by software.
+ - Source 5 is the supervisor timer interrupt, which can be configured
+ by SBI calls and implements a one-shot timer.
+ - Source 9 is the supervisor external interrupt, which chains to all
+ other device interrupts.
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
new file mode 100644
index 000000000000..c23b5c09fdb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/riscv,imsics.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V Incoming MSI Controller (IMSIC)
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V advanced interrupt architecture (AIA) defines a per-CPU incoming
+ MSI controller (IMSIC) for handling MSIs in a RISC-V platform. The RISC-V
+ AIA specification can be found at https://github.com/riscv/riscv-aia.
+
+ The IMSIC is a per-CPU (or per-HART) device with separate interrupt file
+ for each privilege level (machine or supervisor). The configuration of
+ a IMSIC interrupt file is done using AIA CSRs and it also has a 4KB MMIO
+ space to receive MSIs from devices. Each IMSIC interrupt file supports a
+ fixed number of interrupt identities (to distinguish MSIs from devices)
+ which is same for given privilege level across CPUs (or HARTs).
+
+ The device tree of a RISC-V platform will have one IMSIC device tree node
+ for each privilege level (machine or supervisor) which collectively describe
+ IMSIC interrupt files at that privilege level across CPUs (or HARTs).
+
+ The arrangement of IMSIC interrupt files in MMIO space of a RISC-V platform
+ follows a particular scheme defined by the RISC-V AIA specification. A IMSIC
+ group is a set of IMSIC interrupt files co-located in MMIO space and we can
+ have multiple IMSIC groups (i.e. clusters, sockets, chiplets, etc) in a
+ RISC-V platform. The MSI target address of a IMSIC interrupt file at given
+ privilege level (machine or supervisor) encodes group index, HART index,
+ and guest index (shown below).
+
+ XLEN-1 > (HART Index MSB) 12 0
+ | | | |
+ -------------------------------------------------------------
+ |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index| 0 |
+ -------------------------------------------------------------
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+ - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qemu,imsics
+ - const: riscv,imsics
+
+ reg:
+ minItems: 1
+ maxItems: 16384
+ description:
+ Base address of each IMSIC group.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 0
+
+ msi-controller: true
+
+ "#msi-cells":
+ const: 0
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 16384
+ description:
+ This property represents the set of CPUs (or HARTs) for which given
+ device tree node describes the IMSIC interrupt files. Each node pointed
+ to should be a riscv,cpu-intc node, which has a CPU node (i.e. RISC-V
+ HART) as parent.
+
+ riscv,num-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 63
+ maximum: 2047
+ description:
+ Number of interrupt identities supported by IMSIC interrupt file.
+
+ riscv,num-guest-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 63
+ maximum: 2047
+ description:
+ Number of interrupt identities are supported by IMSIC guest interrupt
+ file. When not specified it is assumed to be same as specified by the
+ riscv,num-ids property.
+
+ riscv,guest-index-bits:
+ minimum: 0
+ maximum: 7
+ default: 0
+ description:
+ Number of guest index bits in the MSI target address.
+
+ riscv,hart-index-bits:
+ minimum: 0
+ maximum: 15
+ description:
+ Number of HART index bits in the MSI target address. When not
+ specified it is calculated based on the interrupts-extended property.
+
+ riscv,group-index-bits:
+ minimum: 0
+ maximum: 7
+ default: 0
+ description:
+ Number of group index bits in the MSI target address.
+
+ riscv,group-index-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 55
+ default: 24
+ description:
+ The least significant bit position of the group index bits in the
+ MSI target address.
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - msi-controller
+ - "#msi-cells"
+ - interrupts-extended
+ - riscv,num-ids
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ // Example 1 (Machine-level IMSIC files with just one group):
+
+ interrupt-controller@24000000 {
+ compatible = "qemu,imsics", "riscv,imsics";
+ interrupts-extended = <&cpu1_intc 11>,
+ <&cpu2_intc 11>,
+ <&cpu3_intc 11>,
+ <&cpu4_intc 11>;
+ reg = <0x24000000 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <0>;
+ msi-controller;
+ #msi-cells = <0>;
+ riscv,num-ids = <127>;
+ };
+
+ - |
+ // Example 2 (Supervisor-level IMSIC files with two groups):
+
+ interrupt-controller@28000000 {
+ compatible = "qemu,imsics", "riscv,imsics";
+ interrupts-extended = <&cpu1_intc 9>,
+ <&cpu2_intc 9>,
+ <&cpu3_intc 9>,
+ <&cpu4_intc 9>;
+ reg = <0x28000000 0x2000>, /* Group0 IMSICs */
+ <0x29000000 0x2000>; /* Group1 IMSICs */
+ interrupt-controller;
+ #interrupt-cells = <0>;
+ msi-controller;
+ #msi-cells = <0>;
+ riscv,num-ids = <127>;
+ riscv,group-index-bits = <1>;
+ riscv,group-index-shift = <24>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-mpxy-system-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-mpxy-system-msi.yaml
new file mode 100644
index 000000000000..1991f5c7446a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-mpxy-system-msi.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/riscv,rpmi-mpxy-system-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V RPMI system MSI service group based message proxy
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V Platform Management Interface (RPMI) [1] defines a
+ messaging protocol which is modular and extensible. The supervisor
+ software can send/receive RPMI messages via SBI MPXY extension [2]
+ or some dedicated supervisor-mode RPMI transport.
+
+ The RPMI specification [1] defines system MSI service group which
+ allow application processors to receive MSIs upon system events
+ such as P2A doorbell, graceful shutdown/reboot request, CPU hotplug
+ event, memory hotplug event, etc from the platform microcontroller.
+ The SBI implementation (machine mode firmware or hypervisor) can
+ implement an SBI MPXY channel to allow RPMI system MSI service
+ group access to the supervisor software.
+
+ ===========================================
+ References
+ ===========================================
+
+ [1] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+ [2] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-sbi-doc/releases
+
+properties:
+ compatible:
+ description:
+ Intended for use by the SBI implementation.
+ const: riscv,rpmi-mpxy-system-msi
+
+ mboxes:
+ maxItems: 1
+ description:
+ Mailbox channel of the underlying RPMI transport.
+
+ riscv,sbi-mpxy-channel-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The SBI MPXY channel id to be used for providing RPMI access to
+ the supervisor software.
+
+required:
+ - compatible
+ - mboxes
+ - riscv,sbi-mpxy-channel-id
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "riscv,rpmi-mpxy-system-msi";
+ mboxes = <&rpmi_shmem_mbox 0x2>;
+ riscv,sbi-mpxy-channel-id = <0x2000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-system-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-system-msi.yaml
new file mode 100644
index 000000000000..b10a0532e586
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,rpmi-system-msi.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/riscv,rpmi-system-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V RPMI system MSI service group based interrupt controller
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V Platform Management Interface (RPMI) [1] defines a
+ messaging protocol which is modular and extensible. The supervisor
+ software can send/receive RPMI messages via SBI MPXY extension [2]
+ or some dedicated supervisor-mode RPMI transport.
+
+ The RPMI specification [1] defines system MSI service group which
+ allow application processors to receive MSIs upon system events
+ such as P2A doorbell, graceful shutdown/reboot request, CPU hotplug
+ event, memory hotplug event, etc from the platform microcontroller.
+ The supervisor software can access RPMI system MSI service group via
+ SBI MPXY channel or some dedicated supervisor-mode RPMI transport.
+
+ ===========================================
+ References
+ ===========================================
+
+ [1] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+ [2] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-sbi-doc/releases
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ description:
+ Intended for use by the supervisor software.
+ const: riscv,rpmi-system-msi
+
+ mboxes:
+ maxItems: 1
+ description:
+ Mailbox channel of the underlying RPMI transport or SBI message proxy channel.
+
+ msi-parent: true
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+required:
+ - compatible
+ - mboxes
+ - msi-parent
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "riscv,rpmi-system-msi";
+ mboxes = <&mpxy_mbox 0x2000 0x0>;
+ msi-parent = <&imsic_slevel>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
deleted file mode 100644
index c54c5a9a2a90..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Samsung S3C24XX Interrupt Controllers
-
-The S3C24XX SoCs contain a custom set of interrupt controllers providing a
-varying number of interrupt sources. The set consists of a main- and sub-
-controller and on newer SoCs even a second main controller.
-
-Required properties:
-- compatible: Compatible property value should be "samsung,s3c2410-irq"
- for machines before s3c2416 and "samsung,s3c2416-irq" for s3c2416 and later.
-
-- reg: Physical base address of the controller and length of memory mapped
- region.
-
-- interrupt-controller : Identifies the node as an interrupt controller
-
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 4 and interrupt descriptor shall
- have the following format:
- <ctrl_num parent_irq ctrl_irq type>
-
- ctrl_num contains the controller to use:
- - 0 ... main controller
- - 1 ... sub controller
- - 2 ... second main controller on s3c2416 and s3c2450
- parent_irq contains the parent bit in the main controller and will be
- ignored in main controllers
- ctrl_irq contains the interrupt bit of the controller
- type contains the trigger type to use
-
-Example:
-
- interrupt-controller@4a000000 {
- compatible = "samsung,s3c2410-irq";
- reg = <0x4a000000 0x100>;
- interrupt-controller;
- #interrupt-cells=<4>;
- };
-
- [...]
-
- serial@50000000 {
- compatible = "samsung,s3c2410-uart";
- reg = <0x50000000 0x4000>;
- interrupt-parent = <&subintc>;
- interrupts = <1 28 0 4>, <1 28 1 4>;
- };
-
- rtc@57000000 {
- compatible = "samsung,s3c2410-rtc";
- reg = <0x57000000 0x100>;
- interrupt-parent = <&intc>;
- interrupts = <0 30 0 3>, <0 8 0 3>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 92e0f8c3eff2..388fc2c620c0 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -45,7 +45,6 @@ description:
from S-mode. So add thead,c900-plic to distinguish them.
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
- Palmer Dabbelt <palmer@dabbelt.com>
@@ -54,18 +53,39 @@ properties:
oneOf:
- items:
- enum:
+ - andestech,qilai-plic
- renesas,r9a07g043-plic
- const: andestech,nceplic100
- items:
- enum:
+ - anlogic,dr1v90-plic
+ - canaan,k210-plic
+ - eswin,eic7700-plic
+ - microchip,pic64gx-plic
- sifive,fu540-c000-plic
+ - spacemit,k1-plic
- starfive,jh7100-plic
- - canaan,k210-plic
+ - starfive,jh7110-plic
+ - tenstorrent,blackhole-plic
- const: sifive,plic-1.0.0
- items:
- enum:
- allwinner,sun20i-d1-plic
+ - sophgo,cv1800b-plic
+ - sophgo,cv1812h-plic
+ - sophgo,sg2002-plic
+ - sophgo,sg2042-plic
+ - sophgo,sg2044-plic
+ - thead,th1520-plic
- const: thead,c900-plic
+ - items:
+ - const: ultrarisc,dp1000-plic
+ - const: ultrarisc,cp100-plic
+ - items:
+ - const: sifive,plic-1.0.0
+ - const: riscv,plic0
+ deprecated: true
+ description: For the QEMU virt machine only
reg:
maxItems: 1
@@ -86,7 +106,7 @@ properties:
riscv,cpu-intc node, which has a riscv node as parent.
riscv,ndev:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Specifies how many external interrupts are supported by this controller.
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt
deleted file mode 100644
index 9a5d562435ea..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* ARC700 incore Interrupt Controller
-
- The core interrupt controller provides 32 prioritised interrupts (2 levels)
- to ARC700 core.
-
-Properties:
-
-- compatible: "snps,arc700-intc"
-- interrupt-controller: This is an interrupt controller.
-- #interrupt-cells: Must be <1>.
-
- Single Cell "interrupts" property of a device specifies the IRQ number
- between 0 to 31
-
- intc accessed via the special ARC AUX register interface, hence "reg" property
- is not specified.
-
-Example:
-
- intc: interrupt-controller {
- compatible = "snps,arc700-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.yaml
new file mode 100644
index 000000000000..000a734d997c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/snps,arc700-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARC700 incore Interrupt Controller
+
+maintainers:
+ - Vineet Gupta <vgupta@kernel.org>
+
+description: >
+ The core interrupt controller provides 32 prioritized interrupts (2 levels)
+ to ARC700 core.
+
+ intc accessed via the special ARC AUX register interface, hence "reg" property
+ is not specified.
+
+properties:
+ compatible:
+ const: snps,arc700-intc
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description: An interrupt number 0-31
+ const: 1
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "snps,arc700-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt
deleted file mode 100644
index a5c1db95b3ec..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* ARC-HS Interrupt Distribution Unit
-
- This optional 2nd level interrupt controller can be used in SMP configurations
- for dynamic IRQ routing, load balancing of common/external IRQs towards core
- intc.
-
-Properties:
-
-- compatible: "snps,archs-idu-intc"
-- interrupt-controller: This is an interrupt controller.
-- #interrupt-cells: Must be <1> or <2>.
-
- Value of the first cell specifies the "common" IRQ from peripheral to IDU.
- Number N of the particular interrupt line of IDU corresponds to the line N+24
- of the core interrupt controller.
-
- The (optional) second cell specifies any of the following flags:
- - bits[3:0] trigger type and level flags
- 1 = low-to-high edge triggered
- 2 = NOT SUPPORTED (high-to-low edge triggered)
- 4 = active high level-sensitive <<< DEFAULT
- 8 = NOT SUPPORTED (active low level-sensitive)
- When no second cell is specified, the interrupt is assumed to be level
- sensitive.
-
- The interrupt controller is accessed via the special ARC AUX register
- interface, hence "reg" property is not specified.
-
-Example:
- core_intc: core-interrupt-controller {
- compatible = "snps,archs-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- };
-
- idu_intc: idu-interrupt-controller {
- compatible = "snps,archs-idu-intc";
- interrupt-controller;
- interrupt-parent = <&core_intc>;
- #interrupt-cells = <1>;
- };
-
- some_device: serial@c0fc1000 {
- interrupt-parent = <&idu_intc>;
- interrupts = <0>; /* upstream idu IRQ #24 */
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.yaml
new file mode 100644
index 000000000000..286a964f23e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/snps,archs-idu-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARC-HS Interrupt Distribution Unit
+
+maintainers:
+ - Vineet Gupta <vgupta@kernel.org>
+
+description: >
+ ARC-HS Interrupt Distribution Unit is an optional 2nd level interrupt
+ controller which can be used in SMP configurations for dynamic IRQ routing,
+ load balancing of common/external IRQs towards core intc.
+
+ The interrupt controller is accessed via the special ARC AUX register
+ interface, hence "reg" property is not specified.
+
+properties:
+ compatible:
+ const: snps,archs-idu-intc
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description: |
+ Number of interrupt specifier cells:
+ - 1: only a common IRQ is specified.
+ - 2: a second cell encodes trigger type and level flags:
+ 1 = low-to-high edge triggered
+ 4 = active high level-sensitive (default)
+ enum: [1, 2]
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "snps,archs-idu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt
deleted file mode 100644
index 69f326d6a5ad..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* ARC-HS incore Interrupt Controller (Provided by cores implementing ARCv2 ISA)
-
-Properties:
-
-- compatible: "snps,archs-intc"
-- interrupt-controller: This is an interrupt controller.
-- #interrupt-cells: Must be <1>.
-
- Single Cell "interrupts" property of a device specifies the IRQ number
- between 16 to 256
-
- intc accessed via the special ARC AUX register interface, hence "reg" property
- is not specified.
-
-Example:
-
- intc: interrupt-controller {
- compatible = "snps,archs-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupts = <16 17 18 19 20 21 22 23 24 25>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.yaml
new file mode 100644
index 000000000000..9d248ef7fe3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/snps,archs-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARC-HS incore Interrupt Controller
+
+maintainers:
+ - Vineet Gupta <vgupta@kernel.org>
+
+description:
+ ARC-HS incore Interrupt Controller provided by cores implementing ARCv2 ISA.
+ intc accessed via the special ARC AUX register interface, hence "reg" property
+ is not specified.
+
+properties:
+ compatible:
+ const: snps,archs-intc
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupts:
+ description: List of IRQ numbers between 16 and 256
+ items:
+ items:
+ - minimum: 16
+ maximum: 256
+
+required:
+ - compatible
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller {
+ compatible = "snps,archs-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <16>, <17>, <18>, <19>, <20>, <21>, <22>, <23>, <24>, <25>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
deleted file mode 100644
index 2db59df9408f..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
-
-Synopsys DesignWare provides interrupt controller IP for APB known as
-dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
-APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
-controller in some SoCs, e.g. Hisilicon SD5203.
-
-Required properties:
-- compatible: shall be "snps,dw-apb-ictl"
-- reg: physical base address of the controller and length of memory mapped
- region starting with ENABLE_LOW register
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: number of cells to encode an interrupt-specifier, shall be 1
-
-Additional required property when it's used as secondary interrupt controller:
-- interrupts: interrupt reference to primary interrupt controller
-
-The interrupt sources map to the corresponding bits in the interrupt
-registers, i.e.
-- 0 maps to bit 0 of low interrupts,
-- 1 maps to bit 1 of low interrupts,
-- 32 maps to bit 0 of high interrupts,
-- 33 maps to bit 1 of high interrupts,
-- (optional) fast interrupts start at 64.
-
-Example:
- /* dw_apb_ictl is used as secondary interrupt controller */
- aic: interrupt-controller@3000 {
- compatible = "snps,dw-apb-ictl";
- reg = <0x3000 0xc00>;
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- /* dw_apb_ictl is used as primary interrupt controller */
- vic: interrupt-controller@10130000 {
- compatible = "snps,dw-apb-ictl";
- reg = <0x10130000 0x1000>;
- interrupt-controller;
- #interrupt-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
new file mode 100644
index 000000000000..6b59b600a037
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare APB interrupt controller
+
+maintainers:
+ - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ - Zhen Lei <thunder.leizhen@huawei.com>
+
+description:
+ Synopsys DesignWare provides interrupt controller IP for APB known as
+ dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
+ with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
+ interrupt controller in some SoCs, e.g. Hisilicon SD5203.
+
+properties:
+ compatible:
+ const: snps,dw-apb-ictl
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupts:
+ maxItems: 1
+ description: >
+ Interrupt input connected to the primary interrupt controller when used
+ as a secondary controller. The interrupt specifier maps to bits in the
+ low and high interrupt registers (0⇒bit 0 low, 1⇒bit 1 low, 32⇒bit 0 high,
+ 33⇒bit 1 high, fast interrupts start at 64).
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@3000 {
+ compatible = "snps,dw-apb-ictl";
+ reg = <0x3000 0xc00>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ - |
+ interrupt-controller@10130000 {
+ compatible = "snps,dw-apb-ictl";
+ reg = <0x10130000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt
deleted file mode 100644
index dac0846fe789..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Socionext SynQuacer External Interrupt Unit (EXIU)
-
-The Socionext Synquacer SoC has an external interrupt unit (EXIU)
-that forwards a block of 32 configurable input lines to 32 adjacent
-level-high type GICv3 SPIs.
-
-Required properties:
-
-- compatible : Should be "socionext,synquacer-exiu".
-- reg : Specifies base physical address and size of the
- control registers.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 3.
-- socionext,spi-base : The SPI number of the first SPI of the 32 adjacent
- ones the EXIU forwards its interrups to.
-
-Notes:
-
-- Only SPIs can use the EXIU as an interrupt parent.
-
-Example:
-
- exiu: interrupt-controller@510c0000 {
- compatible = "socionext,synquacer-exiu";
- reg = <0x0 0x510c0000 0x0 0x20>;
- interrupt-controller;
- interrupt-parent = <&gic>;
- #interrupt-cells = <3>;
- socionext,spi-base = <112>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml
new file mode 100644
index 000000000000..92cec2255cca
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/socionext,synquacer-exiu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext SynQuacer External Interrupt Unit (EXIU)
+
+maintainers:
+ - Ard Biesheuvel <ardb@kernel.org>
+
+description: |+
+ The Socionext SynQuacer SoC has an external interrupt unit (EXIU)
+ that forwards a block of 32 configurable input lines to 32 adjacent
+ level-high type GICv3 SPIs.
+
+properties:
+ compatible:
+ const: socionext,synquacer-exiu
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 3
+
+ interrupt-controller: true
+
+ socionext,spi-base:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The SPI number of the first SPI of the 32 adjacent ones the
+ EXIU forwards its interrupts to.
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+ - socionext,spi-base
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interrupt-controller@510c0000 {
+ compatible = "socionext,synquacer-exiu";
+ reg = <0x510c0000 0x20>;
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ #interrupt-cells = <3>;
+ socionext,spi-base = <112>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml
new file mode 100644
index 000000000000..f6b8b1d92f79
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/sophgo,sg2042-msi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 MSI Controller
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+description:
+ This interrupt controller is in Sophgo SG2042 for transforming interrupts from
+ PCIe MSI to PLIC interrupts.
+
+allOf:
+ - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - sophgo,sg2042-msi
+ - sophgo,sg2044-msi
+
+ reg:
+ items:
+ - description: clear register
+ - description: msi doorbell address
+
+ reg-names:
+ items:
+ - const: clr
+ - const: doorbell
+
+ msi-controller: true
+
+ msi-ranges:
+ maxItems: 1
+
+ "#msi-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - msi-controller
+ - msi-ranges
+ - "#msi-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ msi-controller@30000000 {
+ compatible = "sophgo,sg2042-msi";
+ reg = <0x30000000 0x4>, <0x30000008 0x4>;
+ reg-names = "clr", "doorbell";
+ msi-controller;
+ #msi-cells = <0>;
+ msi-ranges = <&plic 64 IRQ_TYPE_LEVEL_HIGH 32>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,spear300-shirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,spear300-shirq.yaml
new file mode 100644
index 000000000000..27d36173366a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,spear300-shirq.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/st,spear300-shirq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr3xx Shared IRQ controller
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+ - Shiraz Hashim <shiraz.linux.kernel@gmail.com>
+
+description: |
+ SPEAr3xx architecture includes shared/multiplexed irqs for certain set of
+ devices. The multiplexor provides a single interrupt to parent interrupt
+ controller (VIC) on behalf of a group of devices.
+
+ There can be multiple groups available on SPEAr3xx variants but not exceeding
+ 4. The number of devices in a group can differ, further they may share same
+ set of status/mask registers spanning across different bit masks. Also in some
+ cases the group may not have enable or other registers. This makes software
+ little complex.
+
+ A single node in the device tree is used to describe the shared interrupt
+ multiplexer (one node for all groups). A group in the interrupt controller
+ shares config/control registers with other groups. For example, a 32-bit
+ interrupt enable/disable config register can accommodate up to 4 interrupt
+ groups.
+
+properties:
+ compatible:
+ enum:
+ - st,spear300-shirq
+ - st,spear310-shirq
+ - st,spear320-shirq
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ description: Interrupt specifier array for SHIRQ groups
+ minItems: 1
+ maxItems: 4
+
+required:
+ - compatible
+ - reg
+ - '#interrupt-cells'
+ - interrupt-controller
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@b3000000 {
+ compatible = "st,spear320-shirq";
+ reg = <0xb3000000 0x1000>;
+ interrupts = <28 29 30 1>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt b/Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt
deleted file mode 100644
index a407c499b3cc..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-* SPEAr Shared IRQ layer (shirq)
-
-SPEAr3xx architecture includes shared/multiplexed irqs for certain set
-of devices. The multiplexor provides a single interrupt to parent
-interrupt controller (VIC) on behalf of a group of devices.
-
-There can be multiple groups available on SPEAr3xx variants but not
-exceeding 4. The number of devices in a group can differ, further they
-may share same set of status/mask registers spanning across different
-bit masks. Also in some cases the group may not have enable or other
-registers. This makes software little complex.
-
-A single node in the device tree is used to describe the shared
-interrupt multiplexor (one node for all groups). A group in the
-interrupt controller shares config/control registers with other groups.
-For example, a 32-bit interrupt enable/disable config register can
-accommodate up to 4 interrupt groups.
-
-Required properties:
- - compatible: should be, either of
- - "st,spear300-shirq"
- - "st,spear310-shirq"
- - "st,spear320-shirq"
- - interrupt-controller: Identifies the node as an interrupt controller.
- - #interrupt-cells: should be <1> which basically contains the offset
- (starting from 0) of interrupts for all the groups.
- - reg: Base address and size of shirq registers.
- - interrupts: The list of interrupts generated by the groups which are
- then connected to a parent interrupt controller. Each group is
- associated with one of the interrupts, hence number of interrupts (to
- parent) is equal to number of groups. The format of the interrupt
- specifier depends in the interrupt parent controller.
-
-Example:
-
-The following is an example from the SPEAr320 SoC dtsi file.
-
-shirq: interrupt-controller@b3000000 {
- compatible = "st,spear320-shirq";
- reg = <0xb3000000 0x1000>;
- interrupts = <28 29 30 1>;
- #interrupt-cells = <1>;
- interrupt-controller;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
deleted file mode 100644
index ced6014061a3..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-STMicroelectronics STi System Configuration Controlled IRQs
------------------------------------------------------------
-
-On STi based systems; External, CTI (Core Sight), PMU (Performance Management),
-and PL310 L2 Cache IRQs are controlled using System Configuration registers.
-This driver is used to unmask them prior to use.
-
-Required properties:
-- compatible : Should be set to one of:
- "st,stih415-irq-syscfg"
- "st,stih416-irq-syscfg"
- "st,stih407-irq-syscfg"
- "st,stid127-irq-syscfg"
-- st,syscfg : Phandle to Cortex-A9 IRQ system config registers
-- st,irq-device : Array of IRQs to enable - should be 2 in length
-- st,fiq-device : Array of FIQs to enable - should be 2 in length
-
-Optional properties:
-- st,invert-ext : External IRQs can be inverted at will. This property inverts
- these IRQs using bitwise logic. A number of defines have been
- provided for convenience:
- ST_IRQ_SYSCFG_EXT_1_INV
- ST_IRQ_SYSCFG_EXT_2_INV
- ST_IRQ_SYSCFG_EXT_3_INV
-Example:
-
-irq-syscfg {
- compatible = "st,stih416-irq-syscfg";
- st,syscfg = <&syscfg_cpu>;
- st,irq-device = <ST_IRQ_SYSCFG_PMU_0>,
- <ST_IRQ_SYSCFG_PMU_1>;
- st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>,
- <ST_IRQ_SYSCFG_DISABLED>;
- st,invert-ext = <(ST_IRQ_SYSCFG_EXT_1_INV | ST_IRQ_SYSCFG_EXT_3_INV)>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml
new file mode 100644
index 000000000000..e44e4e5708a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,stih407-irq-syscfg.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/st,stih407-irq-syscfg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi System Configuration Controlled IRQs
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+description:
+ On STi based systems; External, CTI (Core Sight), PMU (Performance
+ Management), and PL310 L2 Cache IRQs are controlled using System
+ Configuration registers. This device is used to unmask them prior to use.
+
+properties:
+ compatible:
+ const: st,stih407-irq-syscfg
+
+ st,syscfg:
+ description: Phandle to Cortex-A9 IRQ system config registers
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ st,irq-device:
+ description: Array of IRQs to enable.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: Enable the IRQ of the channel one.
+ - description: Enable the IRQ of the channel two.
+
+ st,fiq-device:
+ description: Array of FIQs to enable.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: Enable the IRQ of the channel one.
+ - description: Enable the IRQ of the channel two.
+
+ st,invert-ext:
+ description: External IRQs can be inverted at will. This property inverts
+ these three IRQs using bitwise logic, each one being encoded respectively
+ on the first, second and fourth bit.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1, 2, 3, 4, 5, 6 ]
+
+required:
+ - compatible
+ - st,syscfg
+ - st,irq-device
+ - st,fiq-device
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq-st.h>
+ irq-syscfg {
+ compatible = "st,stih407-irq-syscfg";
+ st,syscfg = <&syscfg_cpu>;
+ st,irq-device = <ST_IRQ_SYSCFG_PMU_0>,
+ <ST_IRQ_SYSCFG_PMU_1>;
+ st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>,
+ <ST_IRQ_SYSCFG_DISABLED>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml
index e44daa09b137..9967e57b449b 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/interrupt-controller/st,stm32-exti.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STM32 External Interrupt Controller Device Tree Bindings
+title: STM32 External Interrupt Controller
maintainers:
- Alexandre Torgue <alexandre.torgue@foss.st.com>
@@ -89,8 +89,23 @@ examples:
reg = <0x5000d000 0x400>;
};
+ - |
//Example 2
- exti2: interrupt-controller@40013c00 {
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ exti2: interrupt-controller@5000d000 {
+ compatible = "st,stm32mp1-exti", "syscon";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x5000d000 0x400>;
+ interrupts-extended =
+ <&intc GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <0>,
+ <&intc GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ - |
+ //Example 3
+ exti3: interrupt-controller@40013c00 {
compatible = "st,stm32-exti";
interrupt-controller;
#interrupt-cells = <2>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
new file mode 100644
index 000000000000..ada5788602d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/starfive,jh8100-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive External Interrupt Controller
+
+description:
+ StarFive SoC JH8100 contain a external interrupt controller. It can be used
+ to handle high-level input interrupt signals. It also send the output
+ interrupt signal to RISC-V PLIC.
+
+maintainers:
+ - Changhuang Liang <changhuang.liang@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh8100-intc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: APB clock for the interrupt controller
+ maxItems: 1
+
+ resets:
+ description: APB reset for the interrupt controller
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@12260000 {
+ compatible = "starfive,jh8100-intc";
+ reg = <0x12260000 0x10000>;
+ clocks = <&syscrg_ne 76>;
+ resets = <&syscrg_ne 13>;
+ interrupts = <45>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800-irqc.yaml
new file mode 100644
index 000000000000..f1a15d725cd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800-irqc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/technologic,ts4800-irqc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TS-4800 FPGA Interrupt Controller
+
+maintainers:
+ - Damien Riegel <damien.riegel@savoirfairelinux.com>
+
+description:
+ TS-4800 FPGA has an internal interrupt controller. When one of the interrupts
+ is triggered, the SoC is notified, usually using a GPIO as parent interrupt
+ source.
+
+properties:
+ compatible:
+ const: technologic,ts4800-irqc
+
+ reg:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1000 {
+ compatible = "technologic,ts4800-irqc";
+ reg = <0x1000 0x80>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt b/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt
deleted file mode 100644
index 341ae5909333..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/technologic,ts4800.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-TS-4800 FPGA interrupt controller
-
-TS-4800 FPGA has an internal interrupt controller. When one of the
-interrupts is triggered, the SoC is notified, usually using a GPIO as
-parent interrupt source.
-
-Required properties:
-- compatible: should be "technologic,ts4800-irqc"
-- interrupt-controller: identifies the node as an interrupt controller
-- reg: physical base address of the controller and length of memory mapped
- region
-- #interrupt-cells: specifies the number of cells needed to encode an interrupt
- source, should be 1.
-- interrupts: specifies the interrupt line in the interrupt-parent controller
diff --git a/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml b/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml
new file mode 100644
index 000000000000..62fd220e126e
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-mswi.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/thead,c900-aclint-mswi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ACLINT Machine-level Software Interrupt Device
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sophgo,sg2042-aclint-mswi
+ - sophgo,sg2044-aclint-mswi
+ - const: thead,c900-aclint-mswi
+ - items:
+ - enum:
+ - anlogic,dr1v90-aclint-mswi
+ - const: nuclei,ux900-aclint-mswi
+
+ reg:
+ maxItems: 1
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4095
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts-extended
+
+examples:
+ - |
+ interrupt-controller@94000000 {
+ compatible = "sophgo,sg2042-aclint-mswi", "thead,c900-aclint-mswi";
+ interrupts-extended = <&cpu1intc 3>,
+ <&cpu2intc 3>,
+ <&cpu3intc 3>,
+ <&cpu4intc 3>;
+ reg = <0x94000000 0x00010000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-sswi.yaml b/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-sswi.yaml
new file mode 100644
index 000000000000..d02c6886283a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/thead,c900-aclint-sswi.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/thead,c900-aclint-sswi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ACLINT Supervisor-level Software Interrupt Device
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+description:
+ The SSWI device is a part of the ACLINT device. It provides
+ supervisor-level IPI functionality for a set of HARTs on a supported
+ platforms. It provides a register to set an IPI (SETSSIP) for each
+ HART connected to the SSWI device. See draft specification
+ https://github.com/riscvarchive/riscv-aclint
+
+ Following variants of the SSWI ACLINT supported, using dedicated
+ compatible string
+ - THEAD C900
+ - MIPS P8700
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sophgo,sg2044-aclint-sswi
+ - const: thead,c900-aclint-sswi
+ - items:
+ - const: mips,p8700-aclint-sswi
+ - items:
+ - enum:
+ - anlogic,dr1v90-aclint-sswi
+ - const: nuclei,ux900-aclint-sswi
+
+ reg:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 0
+
+ interrupt-controller: true
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4095
+
+ riscv,hart-indexes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4095
+ description:
+ A list of hart indexes that APLIC should use to address each hart
+ that is mentioned in the "interrupts-extended"
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupts-extended
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mips,p8700-aclint-sswi
+ then:
+ required:
+ - riscv,hart-indexes
+ else:
+ properties:
+ riscv,hart-indexes: false
+
+examples:
+ - |
+ //Example 1
+ interrupt-controller@94000000 {
+ compatible = "sophgo,sg2044-aclint-sswi", "thead,c900-aclint-sswi";
+ reg = <0x94000000 0x00004000>;
+ #interrupt-cells = <0>;
+ interrupt-controller;
+ interrupts-extended = <&cpu1intc 1>,
+ <&cpu2intc 1>,
+ <&cpu3intc 1>,
+ <&cpu4intc 1>;
+ };
+
+ - |
+ //Example 2
+ interrupt-controller@94000000 {
+ compatible = "mips,p8700-aclint-sswi";
+ reg = <0x94000000 0x00004000>;
+ #interrupt-cells = <0>;
+ interrupt-controller;
+ interrupts-extended = <&cpu1intc 1>,
+ <&cpu2intc 1>,
+ <&cpu3intc 1>,
+ <&cpu4intc 1>;
+ riscv,hart-indexes = <0x0 0x1 0x10 0x11>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt
deleted file mode 100644
index 597e8a089fe4..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* TI Common Platform Interrupt Controller
-
-Common Platform Interrupt Controller (cp_intc) is used on
-OMAP-L1x SoCs and can support several configurable number
-of interrupts.
-
-Main node required properties:
-
-- compatible : should be:
- "ti,cp-intc"
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The type shall be a <u32> and the value shall be 1.
-
- The cell contains the interrupt number in the range [0-128].
-- ti,intc-size: Number of interrupts handled by the interrupt controller.
-- reg: physical base address and size of the intc registers map.
-
-Example:
-
- intc: interrupt-controller@1 {
- compatible = "ti,cp-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- ti,intc-size = <101>;
- reg = <0xfffee000 0x2000>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.yaml
new file mode 100644
index 000000000000..77d018d20f9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,cp-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Common Platform Interrupt Controller
+
+maintainers:
+ - Bartosz Golaszewski <brgl@bgdev.pl>
+
+description:
+ Common Platform Interrupt Controller (cp_intc) is used on OMAP-L1x SoCs and
+ can support several configurable number of interrupts.
+
+properties:
+ compatible:
+ const: ti,cp-intc
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+ description: Encodes an interrupt number in the range 0–128.
+
+ ti,intc-size:
+ description: Number of interrupts handled by the interrupt controller.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - ti,intc-size
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@fffee000 {
+ compatible = "ti,cp-intc";
+ reg = <0xfffee000 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <101>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
deleted file mode 100644
index 5f94d7739d8d..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Keystone 2 IRQ controller IP
-
-On Keystone SOCs, DSP cores can send interrupts to ARM
-host using the IRQ controller IP. It provides 28 IRQ signals to ARM.
-The IRQ handler running on HOST OS can identify DSP signal source by
-analyzing SRCCx bits in IPCARx registers. This is one of the component
-used by the IPC mechanism used on Keystone SOCs.
-
-Required Properties:
-- compatible: should be "ti,keystone-irq"
-- ti,syscon-dev : phandle and offset pair. The phandle to syscon used to
- access device control registers and the offset inside
- device control registers range.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode interrupt
- source should be 1.
-- interrupts: interrupt reference to primary interrupt controller
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-Example:
- kirq0: keystone_irq0@26202a0 {
- compatible = "ti,keystone-irq";
- ti,syscon-dev = <&devctrl 0x2a0>;
- interrupts = <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
- interrupt-controller;
- #interrupt-cells = <1>;
- };
-
- dsp0: dsp0 {
- compatible = "linux,rproc-user";
- ...
- interrupt-parent = <&kirq0>;
- interrupts = <10 2>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.yaml
new file mode 100644
index 000000000000..27d448d1786a
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ti,keystone-irq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Keystone 2 IRQ controller IP
+
+maintainers:
+ - Grygorii Strashko <grygorii.strashko@ti.com>
+
+description:
+ On Keystone SOCs, DSP cores can send interrupts to ARM host using the IRQ
+ controller IP. It provides 28 IRQ signals to ARM. The IRQ handler running on
+ HOST OS can identify DSP signal source by analyzing SRCCx bits in IPCARx
+ registers. This is one of the component used by the IPC mechanism used on
+ Keystone SOCs.
+
+properties:
+ compatible:
+ const: ti,keystone-irq
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupts:
+ maxItems: 1
+
+ ti,syscon-dev:
+ description: Phandle and offset to syscon device
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to syscon device control registers
+ - description: Offset to control register
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+ - ti,syscon-dev
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ interrupt-controller@2a0 {
+ compatible = "ti,keystone-irq";
+ reg = <0x2a0 0x4>;
+ ti,syscon-dev = <&devctrl 0x2a0>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.txt
deleted file mode 100644
index 38ce5d037722..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Omap2/3 intc controller
-
-On TI omap2 and 3 the intc interrupt controller can provide
-96 or 128 IRQ signals to the ARM host depending on the SoC.
-
-Required Properties:
-- compatible: should be one of
- "ti,omap2-intc"
- "ti,omap3-intc"
- "ti,dm814-intc"
- "ti,dm816-intc"
- "ti,am33xx-intc"
-
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode interrupt
- source, should be 1 for intc
-- interrupts: interrupt reference to primary interrupt controller
-
-Please refer to interrupts.txt in this directory for details of the common
-Interrupt Controllers bindings used by client devices.
-
-Example:
- intc: interrupt-controller@48200000 {
- compatible = "ti,omap3-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- reg = <0x48200000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.yaml
new file mode 100644
index 000000000000..cb118180621f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap-intc-irq.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,omap-intc-irq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI OMAP Interrupt Controller
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description:
+ On TI omap2 and 3 the intc interrupt controller can provide 96 or 128 IRQ
+ signals to the ARM host depending on the SoC.
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2-intc
+ - ti,omap3-intc
+ - ti,dm814-intc
+ - ti,dm816-intc
+ - ti,am33xx-intc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@48200000 {
+ compatible = "ti,omap3-intc";
+ reg = <0x48200000 0x1000>;
+ interrupts = <32>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt
deleted file mode 100644
index f2583e6ec060..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* OMAP Interrupt Controller
-
-OMAP2/3 are using a TI interrupt controller that can support several
-configurable number of interrupts.
-
-Main node required properties:
-
-- compatible : should be:
- "ti,omap2-intc"
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The type shall be a <u32> and the value shall be 1.
-
- The cell contains the interrupt number in the range [0-128].
-- ti,intc-size: Number of interrupts handled by the interrupt controller.
-- reg: physical base address and size of the intc registers map.
-
-Example:
-
- intc: interrupt-controller@1 {
- compatible = "ti,omap2-intc";
- interrupt-controller;
- #interrupt-cells = <1>;
- ti,intc-size = <96>;
- reg = <0x48200000 0x1000>;
- };
-
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
deleted file mode 100644
index 422d6908f8b2..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
+++ /dev/null
@@ -1,31 +0,0 @@
-TI OMAP4 Wake-up Generator
-
-All TI OMAP4/5 (and their derivatives) an interrupt controller that
-routes interrupts to the GIC, and also serves as a wakeup source. It
-is also referred to as "WUGEN-MPU", hence the name of the binding.
-
-Required properties:
-
-- compatible : should contain at least "ti,omap4-wugen-mpu" or
- "ti,omap5-wugen-mpu"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller.
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value must be 3.
-
-Notes:
-
-- Because this HW ultimately routes interrupts to the GIC, the
- interrupt specifier must be that of the GIC.
-- Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs
- are explicitly forbidden.
-
-Example:
-
- wakeupgen: interrupt-controller@48281000 {
- compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
- interrupt-controller;
- #interrupt-cells = <3>;
- reg = <0x48281000 0x1000>;
- interrupt-parent = <&gic>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu.yaml
new file mode 100644
index 000000000000..61b30a7732ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,omap4-wugen-mpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI OMAP4 Wake-up Generator
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: >
+ All TI OMAP4/5 (and their derivatives) are interrupt controllers that route
+ interrupts to the GIC, and also serve as wakeup sources. They are also
+ referred to as "WUGEN-MPU", hence the name of the binding.
+
+ Notes:
+
+ - Because this HW ultimately routes interrupts to the GIC, the interrupt
+ specifier must be that of the GIC.
+ - Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs are
+ explicitly forbidden.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: ti,omap5-wugen-mpu
+ - const: ti,omap4-wugen-mpu
+ - const: ti,omap4-wugen-mpu
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@48281000 {
+ compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
+ reg = <0x48281000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
index 65523d9459d8..3cd5a1822e14 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/ti,pruss-intc.yaml#
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
index 88c46e61732e..5449266f258a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
@@ -59,6 +59,9 @@ properties:
interrupt-controller: true
+ '#interrupt-cells':
+ const: 0
+
msi-controller: true
ti,interrupt-ranges:
@@ -82,6 +85,9 @@ properties:
description:
Array of phandles to DMA controllers where the unmapped events originate.
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -103,6 +109,7 @@ examples:
compatible = "ti,sci-inta";
reg = <0x0 0x33d00000 0x0 0x100000>;
interrupt-controller;
+ #interrupt-cells = <0>;
msi-controller;
interrupt-parent = <&main_navss_intr>;
ti,sci = <&dmsc>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
index e12aee42b126..c99cc7323c71 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
@@ -58,6 +58,9 @@ properties:
1 = If intr supports edge triggered interrupts.
4 = If intr supports level triggered interrupts.
+ reg:
+ maxItems: 1
+
interrupt-controller: true
'#interrupt-cells':
diff --git a/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt
deleted file mode 100644
index 0a4ce1051b02..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-VIA/Wondermedia VT8500 Interrupt Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-intc"
-- reg : Should contain 1 register ranges(address and length)
-- #interrupt-cells : should be <1>
-
-Example:
-
- intc: interrupt-controller@d8140000 {
- compatible = "via,vt8500-intc";
- interrupt-controller;
- reg = <0xd8140000 0x10000>;
- #interrupt-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml
new file mode 100644
index 000000000000..bc14c74bf7d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/via,vt8500-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA and WonderMedia SoCs Interrupt Controller
+
+description:
+ This is the interrupt controller used in single-core ARM SoCs made by
+ VIA and WonderMedia (up to and including WM8950). Each block handles
+ up to 64 interrupt sources (level or edge triggered) and can generate
+ up to 8 interrupts to its parent when used in a chained configuration.
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+ const: via,vt8500-intc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description:
+ Interrupt number raised by the IRQ0 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ1 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ2 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ3 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ4 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ5 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ6 output of this controller
+ Only used if this controller is chained
+ - description:
+ Interrupt number raised by the IRQ7 output of this controller
+ Only used if this controller is chained
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@d8140000 {
+ compatible = "via,vt8500-intc";
+ interrupt-controller;
+ reg = <0xd8140000 0x10000>;
+ #interrupt-cells = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml
new file mode 100644
index 000000000000..b4f58ed25993
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/xlnx,intc.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/xlnx,intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Interrupt Controller
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+
+description:
+ The controller is a soft IP core that is configured at build time for the
+ number of interrupts and the type of each interrupt. These details cannot
+ be changed at run time.
+
+properties:
+ compatible:
+ const: xlnx,xps-intc-1.00.a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+ description:
+ Specifies the number of cells needed to encode an interrupt source.
+ The value shall be a minimum of 1. The Xilinx device trees typically
+ use 2 but the 2nd value is not used.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+ description:
+ Specifies the interrupt of the parent controller from which it is chained.
+
+ xlnx,kind-of-intr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ A 32 bit value specifying the interrupt type for each possible interrupt
+ (1 = edge, 0 = level). The interrupt type typically comes in thru
+ the device tree node of the interrupt generating device, but in this case
+ the interrupt type is determined by the interrupt controller based on how
+ it was implemented.
+
+ xlnx,num-intr-inputs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 32
+ description:
+ Specifies the number of interrupts supported by the specific
+ implementation of the controller.
+
+required:
+ - reg
+ - "#interrupt-cells"
+ - interrupt-controller
+ - xlnx,kind-of-intr
+ - xlnx,num-intr-inputs
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@41800000 {
+ compatible = "xlnx,xps-intc-1.00.a";
+ reg = <0x41800000 0x10000>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ xlnx,kind-of-intr = <0x1>;
+ xlnx,num-intr-inputs = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml b/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml
index 5e125cf2a88b..a8409db4a3e3 100644
--- a/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iommu/allwinner,sun50i-h6-iommu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner H6 IOMMU Device Tree Bindings
+title: Allwinner H6 IOMMU
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -17,7 +17,12 @@ properties:
The content of the cell is the master ID.
compatible:
- const: allwinner,sun50i-h6-iommu
+ oneOf:
+ - const: allwinner,sun50i-h6-iommu
+ - const: allwinner,sun50i-h616-iommu
+ - items:
+ - const: allwinner,sun55i-a523-iommu
+ - const: allwinner,sun50i-h616-iommu
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml
index 82ad669feef7..47ec7fa52c3a 100644
--- a/Documentation/devicetree/bindings/iommu/apple,dart.yaml
+++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml
@@ -22,7 +22,15 @@ description: |+
properties:
compatible:
- const: apple,t8103-dart
+ oneOf:
+ - enum:
+ - apple,t8103-dart
+ - apple,t8103-usb4-dart
+ - apple,t8110-dart
+ - apple,t6000-dart
+ - items:
+ - const: apple,t6020-dart
+ - const: apple,t8110-dart
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iommu/apple,sart.yaml b/Documentation/devicetree/bindings/iommu/apple,sart.yaml
index 1524fa3094ef..88e66d4b13c6 100644
--- a/Documentation/devicetree/bindings/iommu/apple,sart.yaml
+++ b/Documentation/devicetree/bindings/iommu/apple,sart.yaml
@@ -28,9 +28,16 @@ description:
properties:
compatible:
- enum:
- - apple,t6000-sart
- - apple,t8103-sart
+ oneOf:
+ - items:
+ - enum:
+ - apple,t6020-sart
+ - apple,t8112-sart
+ - const: apple,t6000-sart
+ - enum:
+ - apple,t6000-sart
+ - apple,t8015-sart
+ - apple,t8103-sart
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
index c57a53d87e4e..75fcf4cb52d9 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
@@ -39,16 +39,11 @@ properties:
any others.
- minItems: 1
items:
- - enum:
- - eventq # Event Queue not empty
- - gerror # Global Error activated
- - const: gerror
- - enum:
- - cmdq-sync # CMD_SYNC complete
- - priq # PRI Queue not empty
- - enum:
- - cmdq-sync
- - priq
+ enum:
+ - eventq # Event Queue not empty
+ - gerror # Global Error activated
+ - cmdq-sync # CMD_SYNC complete
+ - priq # PRI Queue not empty
'#iommu-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 9066e6df1ba1..cdbd23b5c08c 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -28,31 +28,114 @@ properties:
- enum:
- qcom,msm8996-smmu-v2
- qcom,msm8998-smmu-v2
+ - qcom,sdm630-smmu-v2
+ - qcom,sm6375-smmu-v2
- const: qcom,smmu-v2
- - description: Qcom SoCs implementing "arm,mmu-500"
+ - description: Qcom SoCs implementing "qcom,smmu-500" and "arm,mmu-500"
items:
- enum:
+ - qcom,glymur-smmu-500
+ - qcom,kaanapali-smmu-500
+ - qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
+ - qcom,qcs615-smmu-500
+ - qcom,qcs8300-smmu-500
+ - qcom,qdu1000-smmu-500
+ - qcom,sa8255p-smmu-500
+ - qcom,sa8775p-smmu-500
+ - qcom,sar2130p-smmu-500
- qcom,sc7180-smmu-500
- qcom,sc7280-smmu-500
- qcom,sc8180x-smmu-500
- qcom,sc8280xp-smmu-500
+ - qcom,sdm670-smmu-500
- qcom,sdm845-smmu-500
- qcom,sdx55-smmu-500
- qcom,sdx65-smmu-500
+ - qcom,sdx75-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
+ - qcom,sm8550-smmu-500
+ - qcom,sm8650-smmu-500
+ - qcom,sm8750-smmu-500
+ - qcom,x1e80100-smmu-500
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+
+ - description: Qcom SoCs implementing "arm,mmu-500" (legacy binding)
+ deprecated: true
+ items:
+ # Do not add additional SoC to this list. Instead use two previous lists.
+ - enum:
+ - qcom,qcm2290-smmu-500
+ - qcom,sc7180-smmu-500
+ - qcom,sc7280-smmu-500
+ - qcom,sc8180x-smmu-500
+ - qcom,sc8280xp-smmu-500
+ - qcom,sdm845-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6350-smmu-500
+ - qcom,sm6375-smmu-500
+ - qcom,sm8150-smmu-500
+ - qcom,sm8250-smmu-500
+ - qcom,sm8350-smmu-500
+ - qcom,sm8450-smmu-500
+ - const: arm,mmu-500
+ - description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500"
+ items:
+ - enum:
+ - qcom,glymur-smmu-500
+ - qcom,kaanapali-smmu-500
+ - qcom,milos-smmu-500
+ - qcom,qcm2290-smmu-500
+ - qcom,qcs615-smmu-500
+ - qcom,qcs8300-smmu-500
+ - qcom,sa8255p-smmu-500
+ - qcom,sa8775p-smmu-500
+ - qcom,sar2130p-smmu-500
+ - qcom,sc7280-smmu-500
+ - qcom,sc8180x-smmu-500
+ - qcom,sc8280xp-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
+ - qcom,sm8150-smmu-500
+ - qcom,sm8250-smmu-500
+ - qcom,sm8350-smmu-500
+ - qcom,sm8450-smmu-500
+ - qcom,sm8550-smmu-500
+ - qcom,sm8650-smmu-500
+ - qcom,sm8750-smmu-500
+ - qcom,x1e80100-smmu-500
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ - description: Qcom Adreno GPUs implementing "arm,mmu-500" (legacy binding)
+ deprecated: true
+ items:
+ # Do not add additional SoC to this list. Instead use previous list.
+ - enum:
+ - qcom,sc7280-smmu-500
+ - qcom,sm8150-smmu-500
+ - qcom,sm8250-smmu-500
+ - const: qcom,adreno-smmu
- const: arm,mmu-500
- description: Qcom Adreno GPUs implementing "arm,smmu-v2"
items:
- enum:
+ - qcom,msm8996-smmu-v2
- qcom,sc7180-smmu-v2
+ - qcom,sdm630-smmu-v2
+ - qcom,sdm670-smmu-v2
- qcom,sdm845-smmu-v2
+ - qcom,sm6350-smmu-v2
+ - qcom,sm7150-smmu-v2
- const: qcom,adreno-smmu
- const: qcom,smmu-v2
- description: Marvell SoCs implementing "arm,mmu-500"
@@ -147,19 +230,16 @@ properties:
present in such cases.
clock-names:
- items:
- - const: bus
- - const: iface
+ minItems: 1
+ maxItems: 7
clocks:
- items:
- - description: bus clock required for downstream bus access and for the
- smmu ptw
- - description: interface clock required to access smmu's registers
- through the TCU's programming interface.
+ minItems: 1
+ maxItems: 7
power-domains:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
nvidia,memory-controller:
description: |
@@ -206,6 +286,340 @@ allOf:
reg:
maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-smmu-v2
+ - qcom,sdm630-smmu-v2
+ then:
+ anyOf:
+ - properties:
+ clock-names:
+ items:
+ - const: bus
+ clocks:
+ items:
+ - description: bus clock required for downstream bus access and for
+ the smmu ptw
+ - properties:
+ clock-names:
+ items:
+ - const: iface
+ - const: mem
+ - const: mem_iface
+ clocks:
+ items:
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+ - description: bus clock required for memory access
+ - description: bus clock required for GPU memory access
+ - properties:
+ clock-names:
+ items:
+ - const: iface-mm
+ - const: iface-smmu
+ - const: bus-smmu
+ clocks:
+ items:
+ - description: interface clock required to access mnoc's registers
+ through the TCU's programming interface.
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+ - description: bus clock required for the smmu ptw
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6375-smmu-v2
+ then:
+ anyOf:
+ - properties:
+ clock-names:
+ items:
+ - const: bus
+ clocks:
+ items:
+ - description: bus clock required for downstream bus access and for
+ the smmu ptw
+ - properties:
+ clock-names:
+ items:
+ - const: iface
+ - const: mem
+ - const: mem_iface
+ clocks:
+ items:
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+ - description: bus clock required for memory access
+ - description: bus clock required for GPU memory access
+ - properties:
+ clock-names:
+ items:
+ - const: iface-mm
+ - const: iface-smmu
+ - const: bus-mm
+ - const: bus-smmu
+ clocks:
+ items:
+ - description: interface clock required to access mnoc's registers
+ through the TCU's programming interface.
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+ - description: bus clock required for downstream bus access
+ - description: bus clock required for the smmu ptw
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-smmu-v2
+ - qcom,sc7180-smmu-v2
+ - qcom,sdm845-smmu-v2
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: bus
+ - const: iface
+
+ clocks:
+ items:
+ - description: bus clock required for downstream bus access and for
+ the smmu ptw
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-smmu-500
+ - qcom,sa8775p-smmu-500
+ - qcom,sc7280-smmu-500
+ - qcom,sc8280xp-smmu-500
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: gcc_gpu_memnoc_gfx_clk
+ - const: gcc_gpu_snoc_dvm_gfx_clk
+ - const: gpu_cc_ahb_clk
+ - const: gpu_cc_hlos1_vote_gpu_smmu_clk
+ - const: gpu_cc_cx_gmu_clk
+ - const: gpu_cc_hub_cx_int_clk
+ - const: gpu_cc_hub_aon_clk
+
+ clocks:
+ items:
+ - description: GPU memnoc_gfx clock
+ - description: GPU snoc_dvm_gfx clock
+ - description: GPU ahb clock
+ - description: GPU hlos1_vote_GPU smmu clock
+ - description: GPU cx_gmu clock
+ - description: GPU hub_cx_int clock
+ - description: GPU hub_aon clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8180x-smmu-500
+ - qcom,sm6350-smmu-v2
+ - qcom,sm7150-smmu-v2
+ - qcom,sm8150-smmu-500
+ - qcom,sm8250-smmu-500
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: ahb
+ - const: bus
+ - const: iface
+
+ clocks:
+ items:
+ - description: bus clock required for AHB bus access
+ - description: bus clock required for downstream bus access and for
+ the smmu ptw
+ - description: interface clock required to access smmu's registers
+ through the TCU's programming interface.
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,sm8350-smmu-500
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: bus
+ - const: iface
+ - const: ahb
+ - const: hlos1_vote_gpu_smmu
+ - const: cx_gmu
+ - const: hub_cx_int
+ - const: hub_aon
+ clocks:
+ minItems: 7
+ maxItems: 7
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,qcm2290-smmu-500
+ - qcom,qcs615-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: mem
+ - const: hlos
+ - const: iface
+
+ clocks:
+ items:
+ - description: GPU memory bus clock
+ - description: Voter clock required for HLOS SMMU access
+ - description: Interface clock required for register access
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8450-smmu-500
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: gmu
+ - const: hub
+ - const: hlos
+ - const: bus
+ - const: iface
+ - const: ahb
+
+ clocks:
+ items:
+ - description: GMU clock
+ - description: GPU HUB clock
+ - description: HLOS vote clock
+ - description: GPU memory bus clock
+ - description: GPU SNoC bus clock
+ - description: GPU AHB clock
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,milos-smmu-500
+ - qcom,sar2130p-smmu-500
+ - qcom,sm8550-smmu-500
+ - qcom,sm8650-smmu-500
+ - qcom,x1e80100-smmu-500
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: hlos
+ - const: bus
+ - const: iface
+ - const: ahb
+
+ clocks:
+ items:
+ - description: HLOS vote clock
+ - description: GPU memory bus clock
+ - description: GPU SNoC bus clock
+ - description: GPU AHB clock
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - const: qcom,sm8750-smmu-500
+ - const: qcom,adreno-smmu
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: hlos
+ clocks:
+ items:
+ - description: HLOS vote clock
+
+ # Disallow clocks for all other platforms with specific compatibles
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - cavium,smmu-v2
+ - marvell,ap806-smmu-500
+ - nvidia,smmu-500
+ - qcom,qdu1000-smmu-500
+ - qcom,sa8255p-smmu-500
+ - qcom,sc7180-smmu-500
+ - qcom,sdm670-smmu-500
+ - qcom,sdm845-smmu-500
+ - qcom,sdx55-smmu-500
+ - qcom,sdx65-smmu-500
+ - qcom,sm6350-smmu-500
+ - qcom,sm6375-smmu-500
+ then:
+ properties:
+ clock-names: false
+ clocks: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm6375-smmu-500
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: SNoC MMU TBU RT GDSC
+ - description: SNoC MMU TBU NRT GDSC
+ - description: SNoC TURING MMU TBU0 GDSC
+
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains:
+ maxItems: 1
+
examples:
- |+
/* SMMU with stream matching or stream indexing */
@@ -228,7 +642,6 @@ examples:
<&smmu1 7>;
};
-
/* SMMU with stream matching */
smmu2: iommu@ba5f0000 {
compatible = "arm,smmu-v1";
@@ -254,7 +667,6 @@ examples:
iommus = <&smmu2 1 0x30>;
};
-
/* ARM MMU-500 with 10-bit stream ID input configuration */
smmu3: iommu@ba600000 {
compatible = "arm,mmu-500", "arm,smmu-v2";
@@ -275,8 +687,6 @@ examples:
/* bus whose child devices emit one unique 10-bit stream
ID each, but may master through multiple SMMU TBUs */
iommu-map = <0 &smmu3 0 0x400>;
-
-
};
- |+
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index fee0241b5098..79c573c47b08 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -52,7 +52,7 @@ description: |+
As above, The Multimedia HW will go through SMI and M4U while it
access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
smi local arbiter and smi common. It will control whether the Multimedia
- HW should go though the m4u for translation or bypass it and talk
+ HW should go through the m4u for translation or bypass it and talk
directly with EMI. And also SMI help control the power domain and clocks for
each local arbiter.
@@ -73,14 +73,23 @@ properties:
- mediatek,mt2701-m4u # generation one
- mediatek,mt2712-m4u # generation two
- mediatek,mt6779-m4u # generation two
+ - mediatek,mt6795-m4u # generation two
+ - mediatek,mt6893-iommu-mm # generation two
- mediatek,mt8167-m4u # generation two
- mediatek,mt8173-m4u # generation two
- mediatek,mt8183-m4u # generation two
- mediatek,mt8186-iommu-mm # generation two
+ - mediatek,mt8188-iommu-vdo # generation two
+ - mediatek,mt8188-iommu-vpp # generation two
+ - mediatek,mt8188-iommu-infra # generation two
+ - mediatek,mt8189-iommu-apu # generation two
+ - mediatek,mt8189-iommu-infra # generation two
+ - mediatek,mt8189-iommu-mm # generation two
- mediatek,mt8192-m4u # generation two
- mediatek,mt8195-iommu-vdo # generation two
- mediatek,mt8195-iommu-vpp # generation two
- mediatek,mt8195-iommu-infra # generation two
+ - mediatek,mt8365-m4u # generation two
- description: mt7623 generation one
items:
@@ -121,15 +130,20 @@ properties:
description: |
This is the mtk_m4u_id according to the HW. Specifies the mtk_m4u_id as
defined in
+ dt-binding/memory/mediatek,mt8188-memory-port.h for mt8188,
+ dt-binding/memory/mediatek,mt8189-memory-port.h for mt8189,
dt-binding/memory/mt2701-larb-port.h for mt2701 and mt7623,
dt-binding/memory/mt2712-larb-port.h for mt2712,
dt-binding/memory/mt6779-larb-port.h for mt6779,
+ dt-binding/memory/mt6795-larb-port.h for mt6795,
+ dt-binding/memory/mediatek,mt6893-memory-port.h for mt6893,
dt-binding/memory/mt8167-larb-port.h for mt8167,
dt-binding/memory/mt8173-larb-port.h for mt8173,
dt-binding/memory/mt8183-larb-port.h for mt8183,
dt-binding/memory/mt8186-memory-port.h for mt8186,
dt-binding/memory/mt8192-larb-port.h for mt8192.
dt-binding/memory/mt8195-memory-port.h for mt8195.
+ dt-binding/memory/mediatek,mt8365-larb-port.h for mt8365.
power-domains:
maxItems: 1
@@ -148,8 +162,13 @@ allOf:
enum:
- mediatek,mt2701-m4u
- mediatek,mt2712-m4u
+ - mediatek,mt6795-m4u
+ - mediatek,mt6893-iommu-mm
- mediatek,mt8173-m4u
- mediatek,mt8186-iommu-mm
+ - mediatek,mt8188-iommu-vdo
+ - mediatek,mt8188-iommu-vpp
+ - mediatek,mt8189-iommu-mm
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@@ -162,7 +181,11 @@ allOf:
properties:
compatible:
enum:
+ - mediatek,mt6893-iommu-mm
- mediatek,mt8186-iommu-mm
+ - mediatek,mt8188-iommu-vdo
+ - mediatek,mt8188-iommu-vpp
+ - mediatek,mt8189-iommu-mm
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@@ -177,6 +200,7 @@ allOf:
contains:
enum:
- mediatek,mt2712-m4u
+ - mediatek,mt6795-m4u
- mediatek,mt8173-m4u
then:
@@ -188,7 +212,11 @@ allOf:
properties:
compatible:
contains:
- const: mediatek,mt8195-iommu-infra
+ enum:
+ - mediatek,mt8188-iommu-infra
+ - mediatek,mt8189-iommu-apu
+ - mediatek,mt8189-iommu-infra
+ - mediatek,mt8195-iommu-infra
then:
required:
diff --git a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt b/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
deleted file mode 100644
index 20236385f26e..000000000000
--- a/Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-* QCOM IOMMU
-
-The MSM IOMMU is an implementation compatible with the ARM VMSA short
-descriptor page tables. It provides address translation for bus masters outside
-of the CPU, each connected to the IOMMU through a port called micro-TLB.
-
-Required Properties:
-
- - compatible: Must contain "qcom,apq8064-iommu".
- - reg: Base address and size of the IOMMU registers.
- - interrupts: Specifiers for the MMU fault interrupts. For instances that
- support secure mode two interrupts must be specified, for non-secure and
- secure mode, in that order. For instances that don't support secure mode a
- single interrupt must be specified.
- - #iommu-cells: The number of cells needed to specify the stream id. This
- is always 1.
- - qcom,ncb: The total number of context banks in the IOMMU.
- - clocks : List of clocks to be used during SMMU register access. See
- Documentation/devicetree/bindings/clock/clock-bindings.txt
- for information about the format. For each clock specified
- here, there must be a corresponding entry in clock-names
- (see below).
-
- - clock-names : List of clock names corresponding to the clocks specified in
- the "clocks" property (above).
- Should be "smmu_pclk" for specifying the interface clock
- required for iommu's register accesses.
- Should be "smmu_clk" for specifying the functional clock
- required by iommu for bus accesses.
-
-Each bus master connected to an IOMMU must reference the IOMMU in its device
-node with the following property:
-
- - iommus: A reference to the IOMMU in multiple cells. The first cell is a
- phandle to the IOMMU and the second cell is the stream id.
- A single master device can be connected to more than one iommu
- and multiple contexts in each of the iommu. So multiple entries
- are required to list all the iommus and the stream ids that the
- master is connected to.
-
-Example: mdp iommu and its bus master
-
- mdp_port0: iommu@7500000 {
- compatible = "qcom,apq8064-iommu";
- #iommu-cells = <1>;
- clock-names =
- "smmu_pclk",
- "smmu_clk";
- clocks =
- <&mmcc SMMU_AHB_CLK>,
- <&mmcc MDP_AXI_CLK>;
- reg = <0x07500000 0x100000>;
- interrupts =
- <GIC_SPI 63 0>,
- <GIC_SPI 64 0>;
- qcom,ncb = <2>;
- };
-
- mdp: qcom,mdp@5100000 {
- compatible = "qcom,mdp";
- ...
- iommus = <&mdp_port0 0
- &mdp_port0 2>;
- };
diff --git a/Documentation/devicetree/bindings/iommu/qcom,apq8064-iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,apq8064-iommu.yaml
new file mode 100644
index 000000000000..9f83f851e61a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/qcom,apq8064-iommu.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/iommu/qcom,apq8064-iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm APQ8064 IOMMU
+
+maintainers:
+ - David Heidelberg <david@ixit.cz>
+
+description:
+ The MSM IOMMU is an implementation compatible with the ARM VMSA short
+ descriptor page tables. It provides address translation for bus masters
+ outside of the CPU, each connected to the IOMMU through a port called micro-TLB.
+
+properties:
+ compatible:
+ const: qcom,apq8064-iommu
+
+ clocks:
+ items:
+ - description: interface clock for register accesses
+ - description: functional clock for bus accesses
+
+ clock-names:
+ items:
+ - const: smmu_pclk
+ - const: iommu_clk
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Specifiers for the MMU fault interrupts.
+ minItems: 1
+ items:
+ - description: non-secure mode interrupt
+ - description: secure mode interrupt (for instances which supports it)
+
+ "#iommu-cells":
+ const: 1
+ description: Each IOMMU specifier describes a single Stream ID.
+
+ qcom,ncb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The total number of context banks in the IOMMU.
+ minimum: 1
+ maximum: 4
+
+required:
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - qcom,ncb
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,mmcc-msm8960.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ iommu@7500000 {
+ compatible = "qcom,apq8064-iommu";
+ reg = <0x07500000 0x100000>;
+ interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk SMMU_AHB_CLK>,
+ <&clk MDP_AXI_CLK>;
+ clock-names = "smmu_pclk",
+ "iommu_clk";
+ #iommu-cells = <1>;
+ qcom,ncb = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
deleted file mode 100644
index 059139abce35..000000000000
--- a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-* QCOM IOMMU v1 Implementation
-
-Qualcomm "B" family devices which are not compatible with arm-smmu have
-a similar looking IOMMU but without access to the global register space,
-and optionally requiring additional configuration to route context irqs
-to non-secure vs secure interrupt line.
-
-** Required properties:
-
-- compatible : Should be one of:
-
- "qcom,msm8916-iommu"
-
- Followed by "qcom,msm-iommu-v1".
-
-- clock-names : Should be a pair of "iface" (required for IOMMUs
- register group access) and "bus" (required for
- the IOMMUs underlying bus access).
-
-- clocks : Phandles for respective clocks described by
- clock-names.
-
-- #address-cells : must be 1.
-
-- #size-cells : must be 1.
-
-- #iommu-cells : Must be 1. Index identifies the context-bank #.
-
-- ranges : Base address and size of the iommu context banks.
-
-- qcom,iommu-secure-id : secure-id.
-
-- List of sub-nodes, one per translation context bank. Each sub-node
- has the following required properties:
-
- - compatible : Should be one of:
- - "qcom,msm-iommu-v1-ns" : non-secure context bank
- - "qcom,msm-iommu-v1-sec" : secure context bank
- - reg : Base address and size of context bank within the iommu
- - interrupts : The context fault irq.
-
-** Optional properties:
-
-- reg : Base address and size of the SMMU local base, should
- be only specified if the iommu requires configuration
- for routing of context bank irq's to secure vs non-
- secure lines. (Ie. if the iommu contains secure
- context banks)
-
-
-** Examples:
-
- apps_iommu: iommu@1e20000 {
- #address-cells = <1>;
- #size-cells = <1>;
- #iommu-cells = <1>;
- compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
- ranges = <0 0x1e20000 0x40000>;
- reg = <0x1ef0000 0x3000>;
- clocks = <&gcc GCC_SMMU_CFG_CLK>,
- <&gcc GCC_APSS_TCU_CLK>;
- clock-names = "iface", "bus";
- qcom,iommu-secure-id = <17>;
-
- // mdp_0:
- iommu-ctx@4000 {
- compatible = "qcom,msm-iommu-v1-ns";
- reg = <0x4000 0x1000>;
- interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- // venus_ns:
- iommu-ctx@5000 {
- compatible = "qcom,msm-iommu-v1-sec";
- reg = <0x5000 0x1000>;
- interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
-
- gpu_iommu: iommu@1f08000 {
- #address-cells = <1>;
- #size-cells = <1>;
- #iommu-cells = <1>;
- compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
- ranges = <0 0x1f08000 0x10000>;
- clocks = <&gcc GCC_SMMU_CFG_CLK>,
- <&gcc GCC_GFX_TCU_CLK>;
- clock-names = "iface", "bus";
- qcom,iommu-secure-id = <18>;
-
- // gfx3d_user:
- iommu-ctx@1000 {
- compatible = "qcom,msm-iommu-v1-ns";
- reg = <0x1000 0x1000>;
- interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- // gfx3d_priv:
- iommu-ctx@2000 {
- compatible = "qcom,msm-iommu-v1-ns";
- reg = <0x2000 0x1000>;
- interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
-
- ...
-
- venus: video-codec@1d00000 {
- ...
- iommus = <&apps_iommu 5>;
- };
-
- mdp: mdp@1a01000 {
- ...
- iommus = <&apps_iommu 4>;
- };
-
- gpu@1c00000 {
- ...
- iommus = <&gpu_iommu 1>, <&gpu_iommu 2>;
- };
diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml
new file mode 100644
index 000000000000..93a489025317
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/qcom,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies legacy IOMMU implementations
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ Qualcomm "B" family devices which are not compatible with arm-smmu have
+ a similar looking IOMMU, but without access to the global register space
+ and optionally requiring additional configuration to route context IRQs
+ to non-secure vs secure interrupt line.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,msm8916-iommu
+ - qcom,msm8917-iommu
+ - qcom,msm8937-iommu
+ - qcom,msm8953-iommu
+ - const: qcom,msm-iommu-v1
+ - items:
+ - enum:
+ - qcom,msm8953-iommu
+ - qcom,msm8976-iommu
+ - const: qcom,msm-iommu-v2
+
+ clocks:
+ minItems: 2
+ items:
+ - description: Clock required for IOMMU register group access
+ - description: Clock required for underlying bus access
+ - description: Clock required for Translation Buffer Unit access
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: iface
+ - const: bus
+ - const: tbu
+
+ power-domains:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ qcom,iommu-secure-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The SCM secure ID of the IOMMU instance.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ '#iommu-cells':
+ const: 1
+
+patternProperties:
+ "^iommu-ctx@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ enum:
+ - qcom,msm-iommu-v1-ns
+ - qcom,msm-iommu-v1-sec
+ - qcom,msm-iommu-v2-ns
+ - qcom,msm-iommu-v2-sec
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ qcom,ctx-asid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The ASID number associated to the context bank.
+
+ required:
+ - compatible
+ - interrupts
+ - reg
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ranges
+ - '#address-cells'
+ - '#size-cells'
+ - '#iommu-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ apps_iommu: iommu@1e20000 {
+ compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
+ reg = <0x01ef0000 0x3000>;
+ clocks = <&gcc GCC_SMMU_CFG_CLK>,
+ <&gcc GCC_APSS_TCU_CLK>;
+ clock-names = "iface", "bus";
+ qcom,iommu-secure-id = <17>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+ ranges = <0 0x01e20000 0x40000>;
+
+ /* mdp_0: */
+ iommu-ctx@4000 {
+ compatible = "qcom,msm-iommu-v1-ns";
+ reg = <0x4000 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iommu/qcom,tbu.yaml b/Documentation/devicetree/bindings/iommu/qcom,tbu.yaml
new file mode 100644
index 000000000000..82dfe935573e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/qcom,tbu.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/qcom,tbu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm TBU (Translation Buffer Unit)
+
+maintainers:
+ - Georgi Djakov <quic_c_gdjako@quicinc.com>
+
+description:
+ The Qualcomm SMMU500 implementation consists of TCU and TBU. The TBU contains
+ a Translation Lookaside Buffer (TLB) that caches page tables. TBUs provides
+ debug features to trace and trigger debug transactions. There are multiple TBU
+ instances with each client core.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7280-tbu
+ - qcom,sdm845-tbu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ qcom,stream-id-range:
+ description: |
+ Phandle of a SMMU device and Stream ID range (address and size) that
+ is assigned by the TBU
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle of a smmu node
+ - description: stream id base address
+ - description: stream id size
+
+required:
+ - compatible
+ - reg
+ - qcom,stream-id-range
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sdm845.h>
+
+ tbu@150e1000 {
+ compatible = "qcom,sdm845-tbu";
+ reg = <0x150e1000 0x1000>;
+ clocks = <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>;
+ interconnects = <&system_noc MASTER_GNOC_SNOC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_IMEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ power-domains = <&gcc HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC>;
+ qcom,stream-id-range = <&apps_smmu 0x1c00 0x400>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
index 8854569ca3a6..0acaa2bcec08 100644
--- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
+++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
@@ -29,6 +29,7 @@ properties:
- renesas,ipmmu-r8a7793 # R-Car M2-N
- renesas,ipmmu-r8a7794 # R-Car E2
- const: renesas,ipmmu-vmsa # R-Mobile APE6 or R-Car Gen2 or RZ/G1
+
- items:
- enum:
- renesas,ipmmu-r8a774a1 # RZ/G2M
@@ -43,10 +44,13 @@ properties:
- renesas,ipmmu-r8a77980 # R-Car V3H
- renesas,ipmmu-r8a77990 # R-Car E3
- renesas,ipmmu-r8a77995 # R-Car D3
- - renesas,ipmmu-r8a779a0 # R-Car V3U
+
- items:
- enum:
- - renesas,ipmmu-r8a779f0 # R-Car S4-8
+ - renesas,ipmmu-r8a779a0 # R-Car V3U
+ - renesas,ipmmu-r8a779f0 # R-Car S4-8
+ - renesas,ipmmu-r8a779g0 # R-Car V4H
+ - renesas,ipmmu-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-ipmmu-vmsa # R-Car Gen4
reg:
@@ -71,16 +75,16 @@ properties:
renesas,ipmmu-main:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- - items:
+ - minItems: 1
+ items:
- description: phandle to main IPMMU
- - description: the interrupt bit number associated with the particular
- cache IPMMU device. The interrupt bit number needs to match the main
- IPMMU IMSSTR register. Only used by cache IPMMU instances.
+ - description:
+ The interrupt bit number associated with the particular cache
+ IPMMU device. If present, the interrupt bit number needs to match
+ the main IPMMU IMSSTR register. Only used by cache IPMMU
+ instances.
description:
- Reference to the main IPMMU phandle plus 1 cell. The cell is
- the interrupt bit number associated with the particular cache IPMMU
- device. The interrupt bit number needs to match the main IPMMU IMSSTR
- register. Only used by cache IPMMU instances.
+ Reference to the main IPMMU.
required:
- compatible
@@ -106,6 +110,22 @@ allOf:
required:
- power-domains
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rcar-gen4-ipmmu-vmsa
+ then:
+ properties:
+ renesas,ipmmu-main:
+ items:
+ - maxItems: 1
+ else:
+ properties:
+ renesas,ipmmu-main:
+ items:
+ - minItems: 2
+
examples:
- |
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>
diff --git a/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml b/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
new file mode 100644
index 000000000000..d4838c3b3741
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/riscv,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V IOMMU Architecture Implementation
+
+maintainers:
+ - Tomasz Jeznach <tjeznach@rivosinc.com>
+
+description: |
+ The RISC-V IOMMU provides memory address translation and isolation for
+ input and output devices, supporting per-device translation context,
+ shared process address spaces including the ATS and PRI components of
+ the PCIe specification, two stage address translation and MSI remapping.
+ It supports identical translation table format to the RISC-V address
+ translation tables with page level access and protection attributes.
+ Hardware uses in-memory command and fault reporting queues with wired
+ interrupt or MSI notifications.
+
+ Visit https://github.com/riscv-non-isa/riscv-iommu for more details.
+
+ For information on assigning RISC-V IOMMU to its peripheral devices,
+ see generic IOMMU bindings.
+
+properties:
+ # For PCIe IOMMU hardware compatible property should contain the vendor
+ # and device ID according to the PCI Bus Binding specification.
+ # Since PCI provides built-in identification methods, compatible is not
+ # actually required. For non-PCIe hardware implementations 'riscv,iommu'
+ # should be specified along with 'reg' property providing MMIO location.
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qemu,riscv-iommu
+ - const: riscv,iommu
+ - items:
+ - enum:
+ - pci1efd,edf1
+ - const: riscv,pci-iommu
+
+ reg:
+ maxItems: 1
+ description:
+ For non-PCI devices this represents base address and size of for the
+ IOMMU memory mapped registers interface.
+ For PCI IOMMU hardware implementation this should represent an address
+ of the IOMMU, as defined in the PCI Bus Binding reference.
+
+ '#iommu-cells':
+ const: 1
+ description:
+ The single cell describes the requester id emitted by a master to the
+ IOMMU.
+
+ interrupts:
+ minItems: 1
+ maxItems: 4
+ description:
+ Wired interrupt vectors available for RISC-V IOMMU to notify the
+ RISC-V HARTS. The cause to interrupt vector is software defined
+ using IVEC IOMMU register.
+
+ msi-parent: true
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#iommu-cells'
+
+additionalProperties: false
+
+examples:
+ - |+
+ /* Example 1 (IOMMU device with wired interrupts) */
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ iommu1: iommu@1bccd000 {
+ compatible = "qemu,riscv-iommu", "riscv,iommu";
+ reg = <0x1bccd000 0x1000>;
+ interrupt-parent = <&aplic_smode>;
+ interrupts = <32 IRQ_TYPE_LEVEL_HIGH>,
+ <33 IRQ_TYPE_LEVEL_HIGH>,
+ <34 IRQ_TYPE_LEVEL_HIGH>,
+ <35 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ };
+
+ /* Device with two IOMMU device IDs, 0 and 7 */
+ master1 {
+ iommus = <&iommu1 0>, <&iommu1 7>;
+ };
+
+ - |+
+ /* Example 2 (IOMMU device with shared wired interrupt) */
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ iommu2: iommu@1bccd000 {
+ compatible = "qemu,riscv-iommu", "riscv,iommu";
+ reg = <0x1bccd000 0x1000>;
+ interrupt-parent = <&aplic_smode>;
+ interrupts = <32 IRQ_TYPE_LEVEL_HIGH>;
+ #iommu-cells = <1>;
+ };
+
+ - |+
+ /* Example 3 (IOMMU device with MSIs) */
+ iommu3: iommu@1bcdd000 {
+ compatible = "qemu,riscv-iommu", "riscv,iommu";
+ reg = <0x1bccd000 0x1000>;
+ msi-parent = <&imsics_smode>;
+ #iommu-cells = <1>;
+ };
+
+ - |+
+ /* Example 4 (IOMMU PCIe device with MSIs) */
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@30000000 {
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0x0 0x30000000 0x0 0x1000000>;
+ ranges = <0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x0f000000>;
+
+ /*
+ * The IOMMU manages all functions in this PCI domain except
+ * itself. Omit BDF 00:01.0.
+ */
+ iommu-map = <0x0 &iommu0 0x0 0x8>,
+ <0x9 &iommu0 0x9 0xfff7>;
+
+ /* The IOMMU programming interface uses slot 00:01.0 */
+ iommu0: iommu@1,0 {
+ compatible = "pci1efd,edf1", "riscv,pci-iommu";
+ reg = <0x800 0 0 0 0>;
+ #iommu-cells = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
index ba9124f721f1..6ce41d11ff5e 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -19,9 +19,15 @@ description: |+
properties:
compatible:
- enum:
- - rockchip,iommu
- - rockchip,rk3568-iommu
+ oneOf:
+ - enum:
+ - rockchip,iommu
+ - rockchip,rk3568-iommu
+ - items:
+ - enum:
+ - rockchip,rk3576-iommu
+ - rockchip,rk3588-iommu
+ - const: rockchip,rk3568-iommu
reg:
items:
diff --git a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
index be1539d234f9..3528b81daa25 100644
--- a/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
+++ b/Documentation/devicetree/bindings/iommu/xen,grant-dma.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iommu/xen,grant-dma.yaml#
diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt
deleted file mode 100644
index 25f86da804b7..000000000000
--- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Aspeed BT (Block Transfer) IPMI interface
-
-The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs
-(BaseBoard Management Controllers) and the BT interface can be used to
-perform in-band IPMI communication with their host.
-
-Required properties:
-
-- compatible : should be one of
- "aspeed,ast2400-ibt-bmc"
- "aspeed,ast2500-ibt-bmc"
- "aspeed,ast2600-ibt-bmc"
-- reg: physical address and size of the registers
-- clocks: clock for the device
-
-Optional properties:
-
-- interrupts: interrupt generated by the BT interface. without an
- interrupt, the driver will operate in poll mode.
-
-Example:
-
- ibt@1e789140 {
- compatible = "aspeed,ast2400-ibt-bmc";
- reg = <0x1e789140 0x18>;
- interrupts = <8>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- };
diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml
new file mode 100644
index 000000000000..c4f7cdbbe16b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-ibt-bmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Block Transfer (BT) IPMI interface
+
+maintainers:
+ - Joel Stanley <joel@jms.id.au>
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-ibt-bmc
+ - aspeed,ast2500-ibt-bmc
+ - aspeed,ast2600-ibt-bmc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+
+ bt@1e789140 {
+ compatible = "aspeed,ast2400-ibt-bmc";
+ reg = <0x1e789140 0x18>;
+ interrupts = <8>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ };
diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
index 4ff6fabfcb30..610c79863208 100644
--- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
@@ -40,8 +40,11 @@ properties:
- description: ODR register
- description: STR register
+ clocks:
+ maxItems: 1
+
aspeed,lpc-io-reg:
- $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 2
description: |
@@ -50,7 +53,7 @@ properties:
status address may be optionally provided.
aspeed,lpc-interrupts:
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
description: |
@@ -63,12 +66,12 @@ properties:
kcs_chan:
deprecated: true
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: The LPC channel number in the controller
kcs_addr:
deprecated: true
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: The host CPU IO map address
required:
diff --git a/Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml b/Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml
new file mode 100644
index 000000000000..8b0d71901195
--- /dev/null
+++ b/Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ipmi/ipmb-dev.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Intelligent Platform Management Bus(IPMB) Device
+
+description: |
+ The IPMB is an I2C bus which provides interconnection between a Baseboard
+ Management Controller(BMC) and chassis electronics. The BMC sends IPMI
+ requests to intelligent controllers like Satellite Management Controller(MC)
+ devices via IPMB and the device sends responses back to the BMC.
+ This device uses an I2C slave device to send and receive IPMB messages,
+ either on a BMC or other MC. A miscellaneous device provices a user space
+ program to communicate with the kernel and the backend device. Some IPMB
+ devices only support the I2C protocol and not the SMB protocol.
+
+ IPMB communications protocol Specification V1.0
+ https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf
+
+maintainers:
+ - Ninad Palsule <ninad@linux.ibm.com>
+
+properties:
+ compatible:
+ enum:
+ - ipmb-dev
+
+ reg:
+ maxItems: 1
+
+ i2c-protocol:
+ description:
+ Use I2C block transfer instead of SMBUS block transfer.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/i2c/i2c.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ipmb-dev@10 {
+ compatible = "ipmb-dev";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ i2c-protocol;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml
index 71bc031c4fde..52647bff31af 100644
--- a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml
+++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ipmi/ipmi-ipmb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: IPMI IPMB device bindings
+title: IPMI IPMB device
description: IPMI IPMB device bindings
@@ -18,7 +18,7 @@ properties:
device_type:
items:
- - const: "ipmi"
+ - const: ipmi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
index 898e3267893a..4bffa3d86128 100644
--- a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
+++ b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ipmi/ipmi-smic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: IPMI device bindings
+title: IPMI device
description: IPMI device bindings
@@ -20,7 +20,7 @@ properties:
device_type:
items:
- - const: "ipmi"
+ - const: ipmi
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
deleted file mode 100644
index 352f5e9c759b..000000000000
--- a/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-* Nuvoton NPCM7xx KCS (Keyboard Controller Style) IPMI interface
-
-The Nuvoton SOCs (NPCM7xx) are commonly used as BMCs
-(Baseboard Management Controllers) and the KCS interface can be
-used to perform in-band IPMI communication with their host.
-
-Required properties:
-- compatible : should be one of
- "nuvoton,npcm750-kcs-bmc"
-- interrupts : interrupt generated by the controller
-- kcs_chan : The KCS channel number in the controller
-
-Example:
-
- lpc_kcs: lpc_kcs@f0007000 {
- compatible = "nuvoton,npcm750-lpc-kcs", "simple-mfd", "syscon";
- reg = <0xf0007000 0x40>;
- reg-io-width = <1>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0xf0007000 0x40>;
-
- kcs1: kcs1@0 {
- compatible = "nuvoton,npcm750-kcs-bmc";
- reg = <0x0 0x40>;
- interrupts = <0 9 4>;
- kcs_chan = <1>;
- status = "disabled";
- };
-
- kcs2: kcs2@0 {
- compatible = "nuvoton,npcm750-kcs-bmc";
- reg = <0x0 0x40>;
- interrupts = <0 9 4>;
- kcs_chan = <2>;
- status = "disabled";
- };
- };
diff --git a/Documentation/devicetree/bindings/ipmi/nuvoton,npcm750-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/nuvoton,npcm750-kcs-bmc.yaml
new file mode 100644
index 000000000000..fc5df1c5e3bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/ipmi/nuvoton,npcm750-kcs-bmc.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ipmi/nuvoton,npcm750-kcs-bmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM KCS BMC
+
+maintainers:
+ - Avi Fishman <avifishman70@gmail.com>
+ - Tomer Maimon <tmaimon77@gmail.com>
+ - Tali Perry <tali.perry1@gmail.com>
+
+description:
+ The Nuvoton SOCs (NPCM) are commonly used as BMCs (Baseboard Management
+ Controllers) and the KCS interface can be used to perform in-band IPMI
+ communication with their host.
+
+properties:
+ compatible:
+ oneOf:
+ - const: nuvoton,npcm750-kcs-bmc
+ - items:
+ - enum:
+ - nuvoton,npcm845-kcs-bmc
+ - const: nuvoton,npcm750-kcs-bmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ kcs_chan:
+ description: The KCS channel number in the controller
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 3
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - kcs_chan
+
+additionalProperties: false
+
+examples:
+ - |
+ kcs@0 {
+ compatible = "nuvoton,npcm750-kcs-bmc";
+ reg = <0x0 0x40>;
+ interrupts = <9 4>;
+ kcs_chan = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/ipmi/ssif-bmc.yaml b/Documentation/devicetree/bindings/ipmi/ssif-bmc.yaml
new file mode 100644
index 000000000000..02b662d780bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/ipmi/ssif-bmc.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ipmi/ssif-bmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SSIF IPMI BMC interface
+
+description: SSIF IPMI BMC device bindings
+
+maintainers:
+ - Quan Nguyen <quan@os.amperecomputing.com>
+
+properties:
+ compatible:
+ enum:
+ - ssif-bmc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ssif-bmc@10 {
+ compatible = "ssif-bmc";
+ reg = <0x10>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml b/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml
new file mode 100644
index 000000000000..760cb336dccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/allwinner,sun50i-a100-ledc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A100 LED Controller
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ The LED controller found in Allwinner sunxi SoCs uses a one-wire serial
+ interface to drive up to 1024 RGB LEDs.
+
+properties:
+ compatible:
+ oneOf:
+ - const: allwinner,sun50i-a100-ledc
+ - items:
+ - enum:
+ - allwinner,sun20i-d1-ledc
+ - allwinner,sun50i-r329-ledc
+ - const: allwinner,sun50i-a100-ledc
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Bus clock
+ - description: Module clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: mod
+
+ resets:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+ description: TX DMA channel
+
+ dma-names:
+ const: tx
+
+ allwinner,pixel-format:
+ description: Pixel format (subpixel transmission order), default is "grb"
+ enum:
+ - bgr
+ - brg
+ - gbr
+ - grb
+ - rbg
+ - rgb
+
+ allwinner,t0h-ns:
+ default: 336
+ description: Length of high pulse when transmitting a "0" bit
+
+ allwinner,t0l-ns:
+ default: 840
+ description: Length of low pulse when transmitting a "0" bit
+
+ allwinner,t1h-ns:
+ default: 882
+ description: Length of high pulse when transmitting a "1" bit
+
+ allwinner,t1l-ns:
+ default: 294
+ description: Length of low pulse when transmitting a "1" bit
+
+ allwinner,treset-ns:
+ default: 300000
+ description: Minimum delay between transmission frames
+
+patternProperties:
+ "^multi-led@[0-9a-f]+$":
+ type: object
+ $ref: leds-class-multicolor.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ minimum: 0
+ maximum: 1023
+ description: Index of the LED in the series (must be contiguous)
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+
+ ledc: led-controller@2008000 {
+ compatible = "allwinner,sun20i-d1-ledc",
+ "allwinner,sun50i-a100-ledc";
+ reg = <0x2008000 0x400>;
+ interrupts = <36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu 12>, <&ccu 34>;
+ clock-names = "bus", "mod";
+ resets = <&ccu 12>;
+ dmas = <&dma 42>;
+ dma-names = "tx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ multi-led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
deleted file mode 100644
index 4af2987b25e9..000000000000
--- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
+++ /dev/null
@@ -1,85 +0,0 @@
-Analog devices AS3645A device tree bindings
-
-The AS3645A flash LED controller can drive two LEDs, one high current
-flash LED and one indicator LED. The high current flash LED can be
-used in torch mode as well.
-
-Ranges below noted as [a, b] are closed ranges between a and b, i.e. a
-and b are included in the range.
-
-Please also see common.txt in the same directory.
-
-
-Required properties
-===================
-
-compatible : Must be "ams,as3645a".
-reg : The I2C address of the device. Typically 0x30.
-#address-cells : 1
-#size-cells : 0
-
-
-Required properties of the flash child node (0)
-===============================================
-
-reg: 0
-flash-timeout-us: Flash timeout in microseconds. The value must be in
- the range [100000, 850000] and divisible by 50000.
-flash-max-microamp: Maximum flash current in microamperes. Has to be
- in the range between [200000, 500000] and
- divisible by 20000.
-led-max-microamp: Maximum torch (assist) current in microamperes. The
- value must be in the range between [20000, 160000] and
- divisible by 20000.
-ams,input-max-microamp: Maximum flash controller input current. The
- value must be in the range [1250000, 2000000]
- and divisible by 50000.
-
-
-Optional properties of the flash child node
-===========================================
-
-function : See Documentation/devicetree/bindings/leds/common.txt.
-color : See Documentation/devicetree/bindings/leds/common.txt.
-label : See Documentation/devicetree/bindings/leds/common.txt (deprecated).
-
-
-Required properties of the indicator child node (1)
-===================================================
-
-reg: 1
-led-max-microamp: Maximum indicator current. The allowed values are
- 2500, 5000, 7500 and 10000.
-
-Optional properties of the indicator child node
-===============================================
-
-function : See Documentation/devicetree/bindings/leds/common.txt.
-color : See Documentation/devicetree/bindings/leds/common.txt.
-label : See Documentation/devicetree/bindings/leds/common.txt (deprecated).
-
-
-Example
-=======
-
-#include <dt-bindings/leds/common.h>
-
- as3645a@30 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x30>;
- compatible = "ams,as3645a";
- led@0 {
- reg = <0x0>;
- flash-timeout-us = <150000>;
- flash-max-microamp = <320000>;
- led-max-microamp = <60000>;
- ams,input-max-microamp = <1750000>;
- function = LED_FUNCTION_FLASH;
- };
- led@1 {
- reg = <0x1>;
- led-max-microamp = <10000>;
- function = LED_FUNCTION_INDICATOR;
- };
- };
diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.yaml b/Documentation/devicetree/bindings/leds/ams,as3645a.yaml
new file mode 100644
index 000000000000..250a4b275d8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ams,as3645a.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ams,as3645a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AS3645A LED Controller
+
+maintainers:
+ - Sakari Ailus <sakari.ailus@iki.fi>
+
+description:
+ The AS3645A flash LED controller can drive two LEDs, one
+ high current flash LED and one indicator LED. The high
+ current flash LED can be used in torch mode as well.
+
+properties:
+ compatible:
+ const: ams,as3645a
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ led@0:
+ description: led0 describes the 'flash' feature
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0
+
+ flash-timeout-us:
+ minimum: 100000
+ maximum: 850000
+ multipleOf: 50000
+
+ flash-max-microamp:
+ minimum: 200000
+ maximum: 500000
+ multipleOf: 20000
+
+ led-max-microamp:
+ minimum: 20000
+ maximum: 160000
+ multipleOf: 20000
+ description:
+ Maximum current when in torch (assist) mode.
+
+ ams,input-max-microamp:
+ minimum: 1250000
+ maximum: 2000000
+ multipleOf: 50000
+
+ required:
+ - reg
+ - flash-timeout-us
+ - flash-max-microamp
+ - led-max-microamp
+ - ams,input-max-microamp
+
+ led@1:
+ description: led1 describes the 'indicator' feature
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 1
+
+ led-max-microamp:
+ enum:
+ - 2500
+ - 5000
+ - 7500
+ - 10000
+ description:
+ Maximum indicator current.
+
+ required:
+ - reg
+ - led-max-microamp
+
+required:
+ - compatible
+ - reg
+ - "#size-cells"
+ - "#address-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c{
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@30 {
+ compatible = "ams,as3645a";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x30>;
+
+ led@0 {
+ reg = <0>;
+ flash-timeout-us = <150000>;
+ flash-max-microamp = <320000>;
+ led-max-microamp = <60000>;
+ ams,input-max-microamp = <1750000>;
+ function = LED_FUNCTION_FLASH;
+ };
+
+ led@1 {
+ reg = <1>;
+ led-max-microamp = <10000>;
+ function = LED_FUNCTION_INDICATOR;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml b/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml
new file mode 100644
index 000000000000..17e971903ee9
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/awinic,aw200xx.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/awinic,aw200xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AWINIC AW200XX LED
+
+maintainers:
+ - Martin Kurbanov <mmkurbanov@sberdevices.ru>
+
+description: |
+ It is a matrix LED driver programmed via an I2C interface. Devices have
+ a set of individually controlled leds and support 3 pattern controllers
+ for auto breathing or group dimming control. Supported devices:
+ - AW20036 (3x12) 36 LEDs
+ - AW20054 (6x9) 54 LEDs
+ - AW20072 (6x12) 72 LEDs
+ - AW20108 (9x12) 108 LEDs
+
+ For more product information please see the link below:
+ aw20036 - https://www.awinic.com/en/productDetail/AW20036QNR#tech-docs
+ aw20054 - https://www.awinic.com/en/productDetail/AW20054QNR#tech-docs
+ aw20072 - https://www.awinic.com/en/productDetail/AW20072QNR#tech-docs
+ aw20108 - https://www.awinic.com/en/productDetail/AW20108QNR#tech-docs
+
+properties:
+ compatible:
+ enum:
+ - awinic,aw20036
+ - awinic,aw20054
+ - awinic,aw20072
+ - awinic,aw20108
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+
+patternProperties:
+ "^led@[0-9a-f]+$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ LED number
+ maxItems: 1
+
+ led-max-microamp:
+ default: 9780
+ description: |
+ Note that a driver will take the minimum of all LED limits
+ since the chip has a single global setting.
+ The maximum output current of each LED is calculated by the
+ following formula:
+ IMAXled = 160000 * (592 / 600.5) * (1 / max-current-switch-number)
+ And the minimum output current formula:
+ IMINled = 3300 * (592 / 600.5) * (1 / max-current-switch-number)
+ where max-current-switch-number is determined by led configuration
+ and depends on how leds are physically connected to the led driver.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: awinic,aw20036
+ then:
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 36
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: awinic,aw20054
+ then:
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 54
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: awinic,aw20072
+ then:
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 72
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: awinic,aw20108
+ then:
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 108
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@3a {
+ compatible = "awinic,aw20036";
+ reg = <0x3a>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
+
+ led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RED>;
+ led-max-microamp = <9780>;
+ };
+
+ led@1 {
+ reg = <0x1>;
+ color = <LED_COLOR_ID_GREEN>;
+ led-max-microamp = <9780>;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_BLUE>;
+ led-max-microamp = <9780>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml b/Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml
new file mode 100644
index 000000000000..29caeb356e6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/apple,dwi-bl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple DWI 2-Wire Interface Backlight Controller
+
+maintainers:
+ - Nick Chan <towinchenmi@gmail.com>
+
+description:
+ Apple SoCs contain a 2-wire interface called DWI. On some Apple iPhones,
+ iPads and iPod touches with a LCD display, 1-2 backlight controllers
+ are connected via DWI. Interfacing with DWI controls all backlight
+ controllers at the same time. As such, the backlight controllers are
+ treated as a single controller regardless of the underlying
+ configuration.
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,s5l8960x-dwi-bl
+ - apple,t7000-dwi-bl
+ - apple,s8000-dwi-bl
+ - apple,t8010-dwi-bl
+ - apple,t8015-dwi-bl
+ - const: apple,dwi-bl
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dwi_bl: backlight@20e200010 {
+ compatible = "apple,s5l8960x-dwi-bl", "apple,dwi-bl";
+ reg = <0x2 0x0e200010 0x0 0x8>;
+ power-domains = <&ps_dwi>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/arc,arc2c0608.yaml b/Documentation/devicetree/bindings/leds/backlight/arc,arc2c0608.yaml
new file mode 100644
index 000000000000..786beced5590
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arc,arc2c0608.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/arc,arc2c0608.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ArcticSand arc2c0608 LED driver
+
+description: |
+ The ArcticSand arc2c0608 LED driver provides ultra
+ efficient notebook backlighting. Optional properties not
+ specified will default to values in IC EPROM.
+
+ Datasheet:
+ https://www.murata.com/-/media/webrenewal/products/power/power-semiconductor/overview/lineup/led-boost/arc2/arc2c0608.ashx.
+
+maintainers:
+ - Brian Dodge <bdodge@arcticsand.com>
+
+allOf:
+ - $ref: /schemas/leds/common.yaml
+
+properties:
+ compatible:
+ const: arc,arc2c0608
+
+ reg:
+ maxItems: 1
+
+ default-brightness:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 4095
+
+ led-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: List of enabled channels
+ items:
+ enum: [0, 1, 2, 3, 4, 5]
+ minItems: 1
+ uniqueItems: true
+
+ arc,led-config-0:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Fading speed (period between intensity
+ steps)
+
+ arc,led-config-1:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: If set, sets ILED_CONFIG register. Used for
+ fine tuning the maximum LED current.
+
+ arc,dim-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: PWM mode frequency setting (bits [3:0] used)
+
+ arc,comp-config:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Setting for register CONFIG_COMP which
+ controls internal resitances, feed forward freqs,
+ and initial VOUT at startup. Consult the datasheet.
+
+ arc,filter-config:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: RC and PWM Filter settings.
+ Bit Assignment
+ 7654 3 2 1 0
+ xxxx RCF1 RCF0 PWM1 PWM0
+ RCF statuses PWM Filter Statues
+ 00 = OFF (default) 00 = OFF (default)
+ 01 = LOW 01 = 2 STEPS
+ 10 - MEDIUM 10 = 4 STEPS
+ 11 = HIGH 11 = 8 STEPS
+
+ arc,trim-config:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Sets percentage increase of Maximum LED
+ Current.
+ 0x00 = 0% increase.
+ 0x20 = 20.2%.
+ 0x3F = 41.5%
+
+ label: true
+
+ linux,default-trigger: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@30 {
+ compatible = "arc,arc2c0608";
+ reg = <0x30>;
+ default-brightness = <500>;
+ label = "lcd-backlight";
+ linux,default-trigger = "backlight";
+ led-sources = <0 1 2 5>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
deleted file mode 100644
index 230abdefd6e7..000000000000
--- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Binding for ArcticSand arc2c0608 LED driver
-
-Required properties:
-- compatible: should be "arc,arc2c0608"
-- reg: slave address
-
-Optional properties:
-- default-brightness: brightness value on boot, value from: 0-4095
-- label: The name of the backlight device
- See Documentation/devicetree/bindings/leds/common.txt
-- led-sources: List of enabled channels from 0 to 5.
- See Documentation/devicetree/bindings/leds/common.txt
-
-- arc,led-config-0: setting for register ILED_CONFIG_0
-- arc,led-config-1: setting for register ILED_CONFIG_1
-- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
-- arc,comp-config: setting for register CONFIG_COMP
-- arc,filter-config: setting for register FILTER_CONFIG
-- arc,trim-config: setting for register IMAXTUNE
-
-Note: Optional properties not specified will default to values in IC EPROM
-
-Example:
-
-arc2c0608@30 {
- compatible = "arc,arc2c0608";
- reg = <0x30>;
- default-brightness = <500>;
- label = "lcd-backlight";
- linux,default-trigger = "backlight";
- led-sources = <0 1 2 5>;
-};
-
diff --git a/Documentation/devicetree/bindings/leds/backlight/awinic,aw99706.yaml b/Documentation/devicetree/bindings/leds/backlight/awinic,aw99706.yaml
new file mode 100644
index 000000000000..f48ce7a3434d
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/awinic,aw99706.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/awinic,aw99706.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW99706 6-channel WLED Backlight Driver
+
+maintainers:
+ - Junjie Cao <caojunjie650@gmail.com>
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ const: awinic,aw99706
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO to use to enable/disable the backlight (HWEN pin).
+ maxItems: 1
+
+ awinic,dim-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ Select dimming mode of the device.
+ 0 = Bypass mode.
+ 1 = DC mode.
+ 2 = MIX mode(PWM at low brightness and DC at high brightness).
+ 3 = MIX-26k mode(MIX mode with different PWM frequency).
+ enum: [ 0, 1, 2, 3 ]
+ default: 1
+
+ awinic,sw-freq-hz:
+ description: Boost switching frequency in Hz.
+ enum: [ 300000, 400000, 500000, 600000, 660000, 750000, 850000, 1000000,
+ 1200000, 1330000, 1500000, 1700000 ]
+ default: 750000
+
+ awinic,sw-ilmt-microamp:
+ description: Switching current limitation in uA.
+ enum: [ 1500000, 2000000, 2500000, 3000000 ]
+ default: 3000000
+
+ awinic,iled-max-microamp:
+ description: Maximum LED current setting in uA.
+ minimum: 5000
+ maximum: 50000
+ multipleOf: 500
+ default: 20000
+
+ awinic,uvlo-thres-microvolt:
+ description: UVLO(Under Voltage Lock Out) in uV.
+ enum: [ 2200000, 5000000 ]
+ default: 2200000
+
+ awinic,ramp-ctl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ Select ramp control and filter of the device.
+ 0 = Fade in/fade out.
+ 1 = Light filter.
+ 2 = Medium filter.
+ 3 = Heavy filter.
+ enum: [ 0, 1, 2, 3 ]
+ default: 2
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@76 {
+ compatible = "awinic,aw99706";
+ reg = <0x76>;
+ enable-gpios = <&tlmm 88 GPIO_ACTIVE_HIGH>;
+ default-brightness = <2047>;
+ max-brightness = <4095>;
+ awinic,dim-mode = <1>;
+ awinic,sw-freq-hz = <750000>;
+ awinic,sw-ilmt-microamp = <3000000>;
+ awinic,uvlo-thres-microvolt = <2200000>;
+ awinic,iled-max-microamp = <20000>;
+ awinic,ramp-ctl = <2>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml b/Documentation/devicetree/bindings/leds/backlight/common.yaml
index 3b60afbab68b..e0983e44934c 100644
--- a/Documentation/devicetree/bindings/leds/backlight/common.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml
@@ -33,4 +33,21 @@ properties:
due to restrictions in a specific system, such as mounting conditions.
$ref: /schemas/types.yaml#/definitions/uint32
+ brightness-levels:
+ description:
+ Array of distinct brightness levels. The levels must be in the range
+ accepted by the underlying LED device. Typically these are in the range
+ from 0 to 255, but any range starting at 0 will do, as long as they are
+ accepted by the LED.
+ The 0 value means a 0% of brightness (darkest/off), while the last value
+ in the array represents a full 100% brightness (brightest).
+ If this array is not provided, the driver default mapping is used.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ default-brightness-level:
+ description:
+ The default brightness level (index into the array defined by the
+ "brightness-levels" property).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
index 3300451fcfd5..584030b6b0b9 100644
--- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/leds/backlight/gpio-backlight.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: gpio-backlight bindings
+title: gpio-backlight
maintainers:
- Lee Jones <lee@kernel.org>
diff --git a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd2801.yaml b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd2801.yaml
new file mode 100644
index 000000000000..b005065e0f48
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd2801.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktd2801.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTD2801 one-wire backlight
+
+maintainers:
+ - Duje Mihanović <duje.mihanovic@skole.hr>
+
+description: |
+ The Kinetic Technologies KTD2801 is a LED backlight driver controlled
+ by a single GPIO line. The driver can be controlled with a PWM signal
+ or by pulsing the GPIO line to set the backlight level. This is called
+ "ExpressWire".
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ const: kinetic,ktd2801
+
+ ctrl-gpios:
+ maxItems: 1
+
+ default-brightness: true
+ max-brightness: true
+
+required:
+ - compatible
+ - ctrl-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ backlight {
+ compatible = "kinetic,ktd2801";
+ ctrl-gpios = <&gpio 97 GPIO_ACTIVE_HIGH>;
+ max-brightness = <210>;
+ default-brightness = <100>;
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
new file mode 100644
index 000000000000..c914e1276982
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTZ8866 backlight
+
+maintainers:
+ - Jianhua Lu <lujianhua000@gmail.com>
+
+description: |
+ The Kinetic Technologies KTZ8866 is a high efficiency 6-channels-current-sinks
+ led backlight with dual lcd bias power.
+ https://www.kinet-ic.com/ktz8866/
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ const: kinetic,ktz8866
+
+ reg:
+ maxItems: 1
+
+ vddpos-supply:
+ description: positive boost supply regulator.
+
+ vddneg-supply:
+ description: negative boost supply regulator.
+
+ enable-gpios:
+ description: GPIO to use to enable/disable the backlight (HWEN pin).
+ maxItems: 1
+
+ current-num-sinks:
+ description: number of the LED current sinks' channels.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3, 4, 5, 6]
+
+ kinetic,current-ramp-delay-ms:
+ description: |
+ LED current ramping delay time in milliseconds, note that the
+ case 1 will be mapped to 1μs.
+ enum: [1, 2, 4, 8, 16, 32, 64, 128, 192, 256, 320, 384, 448, 512, 576, 640]
+
+ kinetic,led-enable-ramp-delay-ms:
+ description: |
+ LED on/off ramping delay time in milliseconds, note that the case 0 will be
+ mapped to 512μs because ktz8866 can't ramp faster than it.
+ enum: [0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384]
+
+ kinetic,enable-lcd-bias:
+ description: Set if we want to output bias power supply for LCD.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - vddpos-supply
+ - vddneg-supply
+ - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@11 {
+ compatible = "kinetic,ktz8866";
+ reg = <0x11>;
+ vddpos-supply = <&bl_vddpos_5p5>;
+ vddneg-supply = <&bl_vddneg_5p5>;
+ enable-gpios = <&tlmm 139 GPIO_ACTIVE_HIGH>;
+ current-num-sinks = <5>;
+ kinetic,current-ramp-delay-ms = <128>;
+ kinetic,led-enable-ramp-delay-ms = <1>;
+ kinetic,enable-lcd-bias;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
index 0793d0adc4ec..8fc5af8f27f9 100644
--- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/leds/backlight/led-backlight.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: led-backlight bindings
+title: led-backlight
maintainers:
- Lee Jones <lee@kernel.org>
@@ -16,35 +16,20 @@ description:
can also be used to describe a backlight device controlled by the output of
a LED driver.
+allOf:
+ - $ref: common.yaml#
+
properties:
compatible:
const: led-backlight
- leds:
- description: A list of LED nodes
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- maxItems: 1
-
- brightness-levels:
- description:
- Array of distinct brightness levels. The levels must be in the range
- accepted by the underlying LED devices. This is used to translate a
- backlight brightness level into a LED brightness level. If it is not
- provided, the identity mapping is used.
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
- default-brightness-level:
- description:
- The default brightness level (index into the array defined by the
- "brightness-levels" property).
- $ref: /schemas/types.yaml#/definitions/uint32
+ leds: true
required:
- compatible
- leds
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
new file mode 100644
index 000000000000..9416e1bfab92
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lp855x-backlight.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lp855x-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments LP855X backlight controllers
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,lp8550
+ - ti,lp8551
+ - ti,lp8552
+ - ti,lp8553
+ - ti,lp8555
+ - ti,lp8556
+ - ti,lp8557
+
+ reg:
+ maxItems: 1
+
+ dev-ctrl:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description:
+ Value of device control register. This is a device-specific value.
+
+ bl-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Backlight device name.
+
+ init-brt:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Initial value of backlight brightness.
+
+ power-supply:
+ description: Regulator which controls the 3V rail.
+
+ enable-supply:
+ description: Regulator which controls the EN/VDDIO input.
+
+ pwms:
+ maxItems: 1
+ description: |
+ PWM channel to use for controlling the backlight; setting this
+ enables the PWM-based backlight control mode.
+
+ pwm-names: true
+
+ pwm-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ PWM period value. Deprecated; set the period value in the pwms
+ property instead.
+ deprecated: true
+
+patternProperties:
+ "^rom-[0-9a-f]{2}h$":
+ type: object
+ description: Nodes containing the values of configuration registers.
+ additionalProperties: false
+ properties:
+ rom-addr:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Register address of ROM area to be updated.
+
+ rom-val:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Value to write to the ROM register.
+
+required:
+ - compatible
+ - reg
+ - dev-ctrl
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@2c {
+ compatible = "ti,lp8555";
+ reg = <0x2c>;
+
+ dev-ctrl = /bits/ 8 <0x00>;
+
+ pwms = <&pwm 0 10000>;
+ pwm-names = "lp8555";
+
+ /* 4V OV, 4 output LED0 string enabled */
+ rom-14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xcf>;
+ };
+
+ /* Heavy smoothing, 24ms ramp time step */
+ rom-15h {
+ rom-addr = /bits/ 8 <0x15>;
+ rom-val = /bits/ 8 <0xc7>;
+ };
+
+ /* 4 output LED1 string enabled */
+ rom-19h {
+ rom-addr = /bits/ 8 <0x19>;
+ rom-val = /bits/ 8 <0x0f>;
+ };
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@2c {
+ compatible = "ti,lp8556";
+ reg = <0x2c>;
+
+ bl-name = "lcd-bl";
+ dev-ctrl = /bits/ 8 <0x85>;
+ init-brt = /bits/ 8 <0x10>;
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@2c {
+ compatible = "ti,lp8557";
+ reg = <0x2c>;
+ enable-supply = <&backlight_vddio>;
+ power-supply = <&backlight_vdd>;
+
+ dev-ctrl = /bits/ 8 <0x41>;
+ init-brt = /bits/ 8 <0x0a>;
+
+ /* 4V OV, 4 output LED string enabled */
+ rom-14h {
+ rom-addr = /bits/ 8 <0x14>;
+ rom-val = /bits/ 8 <0xcf>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
deleted file mode 100644
index 88f56641fc28..000000000000
--- a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-lp855x bindings
-
-Required properties:
- - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
- "ti,lp8555", "ti,lp8556", "ti,lp8557"
- - reg: I2C slave address (u8)
- - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
-
-Optional properties:
- - bl-name: Backlight device name (string)
- - init-brt: Initial value of backlight brightness (u8)
- - pwm-period: PWM period value. Set only PWM input mode used (u32)
- - rom-addr: Register address of ROM area to be updated (u8)
- - rom-val: Register value to be updated (u8)
- - power-supply: Regulator which controls the 3V rail
- - enable-supply: Regulator which controls the EN/VDDIO input
-
-Example:
-
- /* LP8555 */
- backlight@2c {
- compatible = "ti,lp8555";
- reg = <0x2c>;
-
- dev-ctrl = /bits/ 8 <0x00>;
- pwm-period = <10000>;
-
- /* 4V OV, 4 output LED0 string enabled */
- rom_14h {
- rom-addr = /bits/ 8 <0x14>;
- rom-val = /bits/ 8 <0xcf>;
- };
-
- /* Heavy smoothing, 24ms ramp time step */
- rom_15h {
- rom-addr = /bits/ 8 <0x15>;
- rom-val = /bits/ 8 <0xc7>;
- };
-
- /* 4 output LED1 string enabled */
- rom_19h {
- rom-addr = /bits/ 8 <0x19>;
- rom-val = /bits/ 8 <0x0f>;
- };
- };
-
- /* LP8556 */
- backlight@2c {
- compatible = "ti,lp8556";
- reg = <0x2c>;
-
- bl-name = "lcd-bl";
- dev-ctrl = /bits/ 8 <0x85>;
- init-brt = /bits/ 8 <0x10>;
- };
-
- /* LP8557 */
- backlight@2c {
- compatible = "ti,lp8557";
- reg = <0x2c>;
- enable-supply = <&backlight_vddio>;
- power-supply = <&backlight_vdd>;
-
- dev-ctrl = /bits/ 8 <0x41>;
- init-brt = /bits/ 8 <0x0a>;
-
- /* 4V OV, 4 output LED string enabled */
- rom_14h {
- rom-addr = /bits/ 8 <0x14>;
- rom-val = /bits/ 8 <0xcf>;
- };
- };
diff --git a/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt
deleted file mode 100644
index b4cffdaa4137..000000000000
--- a/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-88pm860x-backlight bindings
-
-Optional properties:
- - maxim,max8925-dual-string: whether support dual string
-
-Example:
-
- backlights {
- maxim,max8925-dual-string = <0>;
- };
diff --git a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
index 5533b6562d92..16fc98e71233 100644
--- a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
@@ -66,7 +66,7 @@ properties:
mediatek,bled-ocp-shutdown:
description: |
- Enable the backlight shutdown when OCP level triggerred.
+ Enable the backlight shutdown when OCP level triggered.
type: boolean
mediatek,bled-ocp-microamp:
diff --git a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
new file mode 100644
index 000000000000..527a37368ed7
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/mps,mp3309c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MPS MP3309C backlight
+
+maintainers:
+ - Flavio Suligoi <f.suligoi@asem.it>
+
+description: |
+ The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
+ programmable switching frequency to optimize efficiency.
+ It supports two different dimming modes:
+
+ - analog mode, via I2C commands, as default mode (32 dimming levels)
+ - PWM controlled mode (optional)
+
+ The datasheet is available at:
+ https://www.monolithicpower.com/en/mp3309c.html
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ const: mps,mp3309c
+
+ reg:
+ maxItems: 1
+
+ pwms:
+ description: if present, the backlight is controlled in PWM mode.
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO used to enable the backlight in "analog-i2c" dimming mode.
+ maxItems: 1
+
+ mps,overvoltage-protection-microvolt:
+ description: Overvoltage protection (13.5V, 24V or 35.5V).
+ enum: [ 13500000, 24000000, 35500000 ]
+ default: 35500000
+
+ mps,no-sync-mode:
+ description: disable synchronous rectification mode
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Backlight with PWM control */
+ backlight_pwm: backlight@17 {
+ compatible = "mps,mp3309c";
+ reg = <0x17>;
+ pwms = <&pwm1 0 3333333 0>; /* 300 Hz --> (1/f) * 1*10^9 */
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness = <6>;
+ mps,overvoltage-protection-microvolt = <24000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
index 78fbe20a1758..b71f6454a4ac 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
@@ -4,13 +4,16 @@
$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: pwm-backlight bindings
+title: pwm-backlight
maintainers:
- Lee Jones <lee@kernel.org>
- Daniel Thompson <daniel.thompson@linaro.org>
- Jingoo Han <jingoohan1@gmail.com>
+allOf:
+ - $ref: common.yaml#
+
properties:
compatible:
const: pwm-backlight
@@ -39,21 +42,6 @@ properties:
Delay in ms between disabling the backlight using GPIO and setting PWM
value to 0.
- brightness-levels:
- description:
- Array of distinct brightness levels. Typically these are in the range
- from 0 to 255, but any range starting at 0 will do. The actual brightness
- level (PWM duty cycle) will be interpolated from these values. 0 means a
- 0% duty cycle (darkest/off), while the last value in the array represents
- a 100% duty cycle (brightest).
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
- default-brightness-level:
- description:
- The default brightness level (index into the array defined by the
- "brightness-levels" property).
- $ref: /schemas/types.yaml#/definitions/uint32
-
num-interpolated-steps:
description:
Number of interpolated steps between each value of brightness-levels
@@ -68,9 +56,8 @@ dependencies:
required:
- compatible
- pwms
- - power-supply
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
index 5d66c3e4def5..a8490781011d 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/leds/backlight/qcom-wled.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for Qualcomm Technologies, Inc. WLED driver
+title: Qualcomm Technologies, Inc. WLED driver
maintainers:
- - Bjorn Andersson <bjorn.andersson@linaro.org>
- - Kiran Gunda <kgunda@codeaurora.org>
+ - Bjorn Andersson <andersson@kernel.org>
+ - Kiran Gunda <quic_kgunda@quicinc.com>
description: |
WLED (White Light Emitting Diode) driver is used for controlling display
@@ -19,6 +19,7 @@ properties:
compatible:
enum:
- qcom,pm8941-wled
+ - qcom,pmi8950-wled
- qcom,pmi8994-wled
- qcom,pmi8998-wled
- qcom,pm660l-wled
@@ -26,7 +27,8 @@ properties:
- qcom,pm8150l-wled
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
default-brightness:
description: |
@@ -171,6 +173,9 @@ allOf:
then:
properties:
+ reg:
+ maxItems: 1
+
qcom,current-boost-limit:
enum: [ 105, 385, 525, 805, 980, 1260, 1400, 1680 ]
default: 805
@@ -189,6 +194,9 @@ allOf:
else:
properties:
+ reg:
+ minItems: 2
+
qcom,current-boost-limit:
enum: [ 105, 280, 450, 620, 970, 1150, 1300, 1500 ]
default: 970
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
new file mode 100644
index 000000000000..482fae71dd53
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,lm3509.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3509 High Efficiency Boost for White LED's and/or OLED Displays
+
+maintainers:
+ - Patrick Gansterer <paroga@paroga.com>
+
+description:
+ The LM3509 current mode boost converter offers two separate outputs.
+ https://www.ti.com/product/LM3509
+
+properties:
+ compatible:
+ const: ti,lm3509
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+ ti,brightness-rate-of-change-us:
+ description: Brightness Rate of Change in microseconds.
+ enum: [51, 13000, 26000, 52000]
+
+ ti,oled-mode:
+ description: Enable OLED mode.
+ type: boolean
+
+patternProperties:
+ "^led@[01]$":
+ type: object
+ description: Properties for a string of connected LEDs.
+ $ref: common.yaml#
+
+ properties:
+ reg:
+ description:
+ The control register that is used to program the two current sinks.
+ The LM3509 has two registers (BMAIN and BSUB) and are represented
+ as 0 or 1 in this property. The two current sinks can be controlled
+ independently with both registers, or register BMAIN can be
+ configured to control both sinks with the led-sources property.
+ minimum: 0
+ maximum: 1
+
+ label: true
+
+ led-sources:
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+ minimum: 0
+ maximum: 31
+ default: 18
+
+ max-brightness:
+ minimum: 0
+ maximum: 31
+ default: 31
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@36 {
+ compatible = "ti,lm3509";
+ reg = <0x36>;
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+
+ ti,oled-mode;
+ ti,brightness-rate-of-change-us = <52000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ led-sources = <0 1>;
+ label = "lcd-backlight";
+ default-brightness = <12>;
+ max-brightness = <31>;
+ };
+ };
+ };
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@36 {
+ compatible = "ti,lm3509";
+ reg = <0x36>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ default-brightness = <12>;
+ };
+
+ led@1 {
+ reg = <1>;
+ default-brightness = <15>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
new file mode 100644
index 000000000000..d44232d462bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,lp8864.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - LP8864/LP8866 4/6-Channel LED Driver family
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+ - Alexander Sverdlin <alexander.sverdlin@siemens.com>
+
+description: |
+ LP8866-Q1, LP8866S-Q1, LP8864-Q1, LP8864S-Q1 are display LED-backlight drivers
+ with 4/6 channels. LED brightness can be controlled globally through the I2C
+ interface or PWM input.
+
+ For more product information please see the links below:
+ https://www.ti.com/product/LP8864-Q1
+ https://www.ti.com/product/LP8864S-Q1
+ https://www.ti.com/product/LP8866-Q1
+ https://www.ti.com/product/LP8866S-Q1
+
+properties:
+ compatible:
+ const: ti,lp8864
+
+ reg:
+ maxItems: 1
+ description: I2C slave address
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO pin to enable (active high) / disable the device
+
+ vled-supply:
+ description: LED supply
+
+ led:
+ type: object
+ $ref: common.yaml#
+ properties:
+ function: true
+ color: true
+ label: true
+ linux,default-trigger: true
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - led
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@3a {
+ compatible = "ti,lp8864";
+ reg = <0x3a>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <&vbatt>;
+
+ led {
+ function = LED_FUNCTION_BACKLIGHT;
+ color = <LED_COLOR_ID_WHITE>;
+ linux,default-trigger = "backlight";
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt
deleted file mode 100644
index ff5c92138650..000000000000
--- a/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Zodiac Inflight Innovations RAVE Supervisory Processor Backlight Bindings
-
-RAVE SP backlight device is a "MFD cell" device corresponding to
-backlight functionality of RAVE Supervisory Processor. It is expected
-that its Device Tree node is specified as a child of the node
-corresponding to the parent RAVE SP device (as documented in
-Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
-
-Required properties:
-
-- compatible: Should be "zii,rave-sp-backlight"
-
-Example:
-
- rave-sp {
- compatible = "zii,rave-sp-rdu1";
- current-speed = <38400>;
-
- backlight {
- compatible = "zii,rave-sp-backlight";
- };
- }
-
diff --git a/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.yaml
new file mode 100644
index 000000000000..ee93a3e64852
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/zii,rave-sp-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zodiac Inflight Innovations RAVE Supervisory Processor Backlight
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ RAVE SP backlight device is a "MFD cell" device corresponding to
+ backlight functionality of RAVE Supervisory Processor. It is expected
+ that its Device Tree node is specified as a child of the node
+ corresponding to the parent RAVE SP device (as documented in
+ Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml)
+
+properties:
+ compatible:
+ const: zii,rave-sp-backlight
+
+required:
+ - compatible
+
+allOf:
+ - $ref: common.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ backlight {
+ compatible = "zii,rave-sp-backlight";
+ };
+
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 328952d7acbb..f4e44b33f56d 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -43,7 +43,7 @@ properties:
LED_COLOR_ID available, add a new one.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
- maximum: 9
+ maximum: 14
function-enumerator:
description:
@@ -62,7 +62,7 @@ properties:
default-state:
description:
The initial state of the LED. If the LED is already on or off and the
- default-state property is set the to same value, then no glitch should be
+ default-state property is set to the same value, then no glitch should be
produced where the LED momentarily turns off (or on). The "keep" setting
will keep the LED at whatever its current state is, without producing a
glitch.
@@ -79,24 +79,63 @@ properties:
the LED.
$ref: /schemas/types.yaml#/definitions/string
- enum:
- # LED will act as a back-light, controlled by the framebuffer system
- - backlight
- # LED will turn on (but for leds-gpio see "default-state" property in
- # Documentation/devicetree/bindings/leds/leds-gpio.yaml)
- - default-on
- # LED "double" flashes at a load average based rate
- - heartbeat
- # LED indicates disk activity
- - disk-activity
- # LED indicates IDE disk activity (deprecated), in new implementations
- # use "disk-activity"
- - ide-disk
- # LED flashes at a fixed, configurable rate
- - timer
- # LED alters the brightness for the specified duration with one software
- # timer (requires "led-pattern" property)
- - pattern
+ oneOf:
+ - enum:
+ # LED will act as a back-light, controlled by the framebuffer system
+ - backlight
+ # LED will turn on (see also "default-state" property)
+ - default-on
+ # LED "double" flashes at a load average based rate
+ - heartbeat
+ # LED indicates disk activity
+ - disk-activity
+ # LED indicates disk read activity
+ - disk-read
+ # LED indicates disk write activity
+ - disk-write
+ # LED flashes at a fixed, configurable rate
+ - timer
+ # LED alters the brightness for the specified duration with one software
+ # timer (requires "led-pattern" property)
+ - pattern
+ # LED indicates mic mute state
+ - audio-micmute
+ # LED indicates audio mute state
+ - audio-mute
+ # LED indicates bluetooth power state
+ - bluetooth-power
+ # LED indicates camera flash state
+ - flash
+ # LED indicated keyboard capslock
+ - kbd-capslock
+ # LED indicates MTD memory activity
+ - mtd
+ # LED indicates NAND memory activity (deprecated),
+ # in new implementations use "mtd"
+ - nand-disk
+ # LED indicates network activity
+ - netdev
+ # No trigger assigned to the LED. This is the default mode
+ # if trigger is absent
+ - none
+ # LED indicates remote control feedback
+ - rc-feedback
+ # LED indicates camera torch state
+ - torch
+ # LED indicates USB gadget activity
+ - usb-gadget
+ # LED indicates USB host activity
+ - usb-host
+ # LED indicates USB port state
+ - usbport
+ # LED is triggered by CPU activity
+ - pattern: "^cpu[0-9]*$"
+ # LED is triggered by Bluetooth activity
+ - pattern: "^hci[0-9]+-power$"
+ # LED is triggered by SD/MMC activity
+ - pattern: "^mmc[0-9]+$"
+ # LED is triggered by WLAN activity
+ - pattern: "^phy[0-9]+tx$"
led-pattern:
description: |
@@ -122,6 +161,24 @@ properties:
For flash LED controllers with configurable current this property is
mandatory for the LEDs in the non-flash modes (e.g. torch or indicator).
+ max-brightness:
+ description:
+ Normally, the maximum brightness is determined by the hardware, and this
+ property is not required. This property is used to set a software limit.
+ It could happen that an LED is made so bright that it gets damaged or
+ causes damage due to restrictions in a specific system, such as mounting
+ conditions.
+ Note that this flag is mainly used for PWM-LEDs, where it is not possible
+ to map brightness to current. Drivers for other controllers should use
+ led-max-microamp.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ default-brightness:
+ description:
+ Brightness to be set if LED's default state is on. Used only during
+ initialization. If the option is not set then max brightness is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
panic-indicator:
description:
This property specifies that the LED should be used, if at all possible,
@@ -144,6 +201,8 @@ properties:
each of them having its own LED assigned (assuming they are not
hardwired). In such cases this property should contain phandle(s) of
related source device(s).
+ Another example is a GPIO line that will be monitored and mirror the
+ state of the line (with or without inversion flags) to the LED.
In many cases LED can be related to more than one device (e.g. one USB LED
vs. multiple USB ports). Each source should be represented by a node in
the device tree and be referenced by a phandle and a set of phandle
@@ -151,6 +210,24 @@ properties:
#trigger-source-cells property in the source node.
$ref: /schemas/types.yaml#/definitions/phandle-array
+ active-high:
+ type: boolean
+ description:
+ Makes LED active high. To turn the LED ON, line needs to be
+ set to high voltage instead of low.
+
+ active-low:
+ type: boolean
+ description:
+ Makes LED active low. To turn the LED ON, line needs to be
+ set to low voltage instead of high.
+
+ inactive-high-impedance:
+ type: boolean
+ description:
+ Set LED to high-impedance mode to turn the LED OFF. LED might also
+ describe this mode as tristate.
+
# Required properties for flash LED child nodes:
flash-max-microamp:
description:
@@ -162,6 +239,14 @@ properties:
Maximum timeout in microseconds after which the flash LED is turned off.
Required for flash LED nodes with configurable timeout.
+allOf:
+ - if:
+ required:
+ - active-low
+ then:
+ properties:
+ active-high: false
+
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml
index 14bebe1ad8f8..f52f6304c79e 100644
--- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml
+++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml
@@ -23,6 +23,12 @@ properties:
description: I2C slave address of the microcontroller.
maxItems: 1
+ interrupts:
+ description:
+ Specifier for the global LED brightness changed by front button press
+ interrupt.
+ maxItems: 1
+
"#address-cells":
const: 1
@@ -56,15 +62,17 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@2b {
compatible = "cznic,turris-omnia-leds";
reg = <0x2b>;
+ interrupts-extended = <&mcu 11 IRQ_TYPE_NONE>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt b/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt
deleted file mode 100644
index cbe8dfd29715..000000000000
--- a/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Device tree bindings for IR LED connected through gpio pin which is used as
-remote controller transmitter.
-
-Required properties:
- - compatible: should be "gpio-ir-tx".
- - gpios : Should specify the IR LED GPIO, see "gpios property" in
- Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs
- should be indicated using flags in the GPIO specifier.
-
-Example:
- irled@0 {
- compatible = "gpio-ir-tx";
- gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.yaml b/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.yaml
new file mode 100644
index 000000000000..5839d00c7089
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/irled/gpio-ir-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IR LED connected through GPIO pin
+
+maintainers:
+ - Sean Young <sean@mess.org>
+
+description:
+ IR LED connected through GPIO pin which is used as remote controller
+ transmitter.
+
+properties:
+ compatible:
+ const: gpio-ir-tx
+
+ gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ irled {
+ compatible = "gpio-ir-tx";
+ gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
new file mode 100644
index 000000000000..72cadebf6e3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/irled/ir-spi-led.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IR LED connected through SPI bus
+
+maintainers:
+ - Sean Young <sean@mess.org>
+
+description:
+ IR LED switch is connected to the MOSI line of the SPI device and the data
+ is delivered through that.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: ir-spi-led
+
+ reg:
+ maxItems: 1
+
+ duty-cycle:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ enum: [50, 60, 70, 75, 80, 90]
+ description:
+ Percentage of one period in which the signal is active.
+
+ led-active-low:
+ type: boolean
+ description:
+ Output is negated with a NOT gate.
+
+ power-supply: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ irled@0 {
+ compatible = "ir-spi-led";
+ reg = <0x0>;
+
+ duty-cycle = /bits/ 8 <60>;
+ led-active-low;
+ power-supply = <&irda_regulator>;
+ spi-max-frequency = <5000000>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt b/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt
deleted file mode 100644
index 66e5672c2e3d..000000000000
--- a/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-Device tree bindings for IR LED connected through pwm pin which is used as
-remote controller transmitter.
-
-Required properties:
- - compatible: should be "pwm-ir-tx".
- - pwms : PWM property to point to the PWM device (phandle)/port (id)
- and to specify the period time to be used: <&phandle id period_ns>;
-
-Example:
- irled {
- compatible = "pwm-ir-tx";
- pwms = <&pwm0 0 10000000>;
- };
diff --git a/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml b/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml
new file mode 100644
index 000000000000..7526e3149f72
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/irled/pwm-ir-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IR LED connected through PWM pin
+
+maintainers:
+ - Sean Young <sean@mess.org>
+
+description:
+ IR LED connected through PWM pin which is used as remote controller
+ transmitter.
+
+properties:
+ compatible:
+ oneOf:
+ - const: pwm-ir-tx
+ - const: nokia,n900-ir
+ deprecated: true
+
+ pwms:
+ maxItems: 1
+
+required:
+ - compatible
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ irled {
+ compatible = "pwm-ir-tx";
+ pwms = <&pwm0 0 10000000>;
+ };
diff --git a/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
deleted file mode 100644
index 83ff1b4d70a6..000000000000
--- a/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Device tree bindings for IR LED connected through SPI bus which is used as
-remote controller.
-
-The IR LED switch is connected to the MOSI line of the SPI device and the data
-are delivered thourgh that.
-
-Required properties:
- - compatible: should be "ir-spi-led".
-
-Optional properties:
- - duty-cycle: 8 bit value that represents the percentage of one period
- in which the signal is active. It can be 50, 60, 70, 75, 80 or 90.
- - led-active-low: boolean value that specifies whether the output is
- negated with a NOT gate.
- - power-supply: specifies the power source. It can either be a regulator
- or a gpio which enables a regulator, i.e. a regulator-fixed as
- described in
- Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
-
-Example:
-
- irled@0 {
- compatible = "ir-spi-led";
- reg = <0x0>;
- spi-max-frequency = <5000000>;
- power-supply = <&vdd_led>;
- led-active-low;
- duty-cycle = /bits/ 8 <60>;
- };
diff --git a/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml b/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml
index 940333f2d69c..906735acfbaf 100644
--- a/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml
+++ b/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/leds/issi,is31fl319x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ISSI LED controllers bindings for IS31FL319{0,1,3,6,9}
+title: ISSI LED Controllers for IS31FL319{0,1,3,6,9}
maintainers:
- Vincent Knecht <vincent.knecht@mailoo.org>
@@ -42,7 +42,6 @@ properties:
description: GPIO attached to the SDB pin.
audio-gain-db:
- $ref: /schemas/types.yaml#/definitions/uint32
default: 0
description: Audio gain selection for external analog modulation input.
enum: [0, 3, 6, 9, 12, 15, 18, 21]
@@ -57,6 +56,7 @@ patternProperties:
"^led@[1-9]$":
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -164,7 +164,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/kinetic,ktd202x.yaml b/Documentation/devicetree/bindings/leds/kinetic,ktd202x.yaml
new file mode 100644
index 000000000000..832c030a5acf
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/kinetic,ktd202x.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/kinetic,ktd202x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic KTD2026/7 RGB/White LED Driver
+
+maintainers:
+ - André Apitzsch <git@apitzsch.eu>
+
+description: |
+ The KTD2026/7 is a RGB/White LED driver with I2C interface.
+
+ The data sheet can be found at:
+ https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf
+
+properties:
+ compatible:
+ enum:
+ - kinetic,ktd2026
+ - kinetic,ktd2027
+
+ reg:
+ maxItems: 1
+
+ vin-supply:
+ description: Regulator providing power to the "VIN" pin.
+
+ vio-supply:
+ description: Regulator providing power for pull-up of the I/O lines.
+ Note that this regulator does not directly connect to KTD2026, but is
+ needed for the correct operation of the status ("ST") and I2C lines.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ multi-led:
+ type: object
+ $ref: leds-class-multicolor.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-3]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: Index of the LED.
+ minimum: 0
+ maximum: 3
+
+ required:
+ - reg
+ - color
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+patternProperties:
+ "^led@[0-3]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: Index of the LED.
+ minimum: 0
+ maximum: 3
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@30 {
+ compatible = "kinetic,ktd2026";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin-supply = <&pm8916_l17>;
+ vio-supply = <&pm8916_l6>;
+
+ led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <1>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@30 {
+ compatible = "kinetic,ktd2026";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin-supply = <&pm8916_l17>;
+ vio-supply = <&pm8916_l6>;
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/leds-an30259a.txt b/Documentation/devicetree/bindings/leds/leds-an30259a.txt
deleted file mode 100644
index cbd833906b2b..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-an30259a.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-* Panasonic AN30259A 3-channel LED driver
-
-The AN30259A is a LED controller capable of driving three LEDs independently. It supports
-constant current output and sloping current output modes. The chip is connected over I2C.
-
-Required properties:
- - compatible: Must be "panasonic,an30259a".
- - reg: I2C slave address.
- - #address-cells: Must be 1.
- - #size-cells: Must be 0.
-
-Each LED is represented as a sub-node of the panasonic,an30259a node.
-
-Required sub-node properties:
- - reg: Pin that the LED is connected to. Must be 1, 2, or 3.
-
-Optional sub-node properties:
- - function :
- see Documentation/devicetree/bindings/leds/common.txt
- - color :
- see Documentation/devicetree/bindings/leds/common.txt
- - label :
- see Documentation/devicetree/bindings/leds/common.txt (deprecated)
- - linux,default-trigger :
- see Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
-#include <dt-bindings/leds/common.h>
-
-led-controller@30 {
- compatible = "panasonic,an30259a";
- reg = <0x30>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- led@1 {
- reg = <1>;
- linux,default-trigger = "heartbeat";
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_RED>;
- };
-
- led@2 {
- reg = <2>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_GREEN>;
- };
-
- led@3 {
- reg = <3>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_BLUE>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
index e24b0d15ef01..26238446f2bd 100644
--- a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml
@@ -20,9 +20,20 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+ description: Open-drain, low active interrupt pin "INTN".
+ Used to report completion of operations (power up, LED breath effects).
+
vcc-supply:
description: Regulator providing power to the "VCC" pin.
+ vio-supply:
+ description: Regulator providing power for pull-up of the I/O lines.
+ "VIO1" in the typical application circuit example of the datasheet.
+ Note that this regulator does not directly connect to AW2013, but is
+ needed for the correct operation of the interrupt and I2C lines.
+
"#address-cells":
const: 1
@@ -33,6 +44,7 @@ patternProperties:
"^led@[0-2]$":
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -51,15 +63,17 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@45 {
compatible = "awinic,aw2013";
reg = <0x45>;
+ interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml
index 52252fb6bb32..62326507c1aa 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-bcm63138.yaml
@@ -41,6 +41,16 @@ properties:
"#size-cells":
const: 0
+ brcm,serial-shift-bits:
+ minimum: 1
+ maximum: 32
+ description:
+ This describes the number of 8-bit serial shifters connected to the LED
+ controller block. The hardware is typically using 8-bit shift registers
+ with 8 LEDs per shift register, so 4 shifters results in 32 LEDs or 2
+ shifters give 16 LEDs etc, but the hardware supports any odd number of
+ registers. If left unspecified, the hardware boot-time default is used.
+
patternProperties:
"^led@[a-f0-9]+$":
type: object
@@ -52,10 +62,6 @@ patternProperties:
maxItems: 1
description: LED pin number
- active-low:
- type: boolean
- description: Makes LED active low
-
required:
- reg
@@ -75,6 +81,7 @@ examples:
leds@ff800800 {
compatible = "brcm,bcm4908-leds", "brcm,bcm63138-leds";
reg = <0xff800800 0xdc>;
+ brcm,serial-shift-bits = <16>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml
index 51cc0d82c12e..f3a3ef992929 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml
@@ -78,10 +78,6 @@ patternProperties:
- maximum: 23
description: LED pin number (only LEDs 0 to 23 are valid).
- active-low:
- type: boolean
- description: Makes LED active low.
-
brcm,hardware-controlled:
type: boolean
description: Makes this LED hardware controlled.
diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt
index 6e51c6b91ee5..211ffc3c4a20 100644
--- a/Documentation/devicetree/bindings/leds/leds-bcm6358.txt
+++ b/Documentation/devicetree/bindings/leds/leds-bcm6358.txt
@@ -25,8 +25,6 @@ LED sub-node required properties:
LED sub-node optional properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
- - active-low : Boolean, makes LED active low.
- Default : false
- default-state : see
Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : see
diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
index 31840e33dcf5..bb40bb9e036e 100644
--- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
@@ -27,14 +27,14 @@ properties:
description: |
For multicolor LED support this property should be defined as either
LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in
- include/linux/leds/common.h.
+ include/dt-bindings/leds/common.h.
enum: [ 8, 9 ]
required:
- color
allOf:
- - $ref: "common.yaml#"
+ - $ref: common.yaml#
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/leds/leds-consumer.yaml b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
new file mode 100644
index 000000000000..fe6a0faa1d3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common leds consumer
+
+maintainers:
+ - Aleksandrs Vinarskis <alex@vinarskis.com>
+
+description:
+ Some LED defined in DT are required by other DT consumers, for example
+ v4l2 subnode may require privacy or flash LED. Unlike trigger-source
+ approach which is typically used as 'soft' binding, referencing LED
+ devices by phandle makes things simpler when 'hard' binding is desired.
+
+ Document LED properties that its consumers may define.
+
+select: true
+
+properties:
+ leds:
+ oneOf:
+ - type: object
+ - $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ A list of LED device(s) required by a particular consumer.
+ items:
+ maxItems: 1
+
+ led-names:
+ description:
+ A list of device name(s). Used to map LED devices to their respective
+ functions, when consumer requires more than one LED.
+
+additionalProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ leds {
+ compatible = "gpio-leds";
+
+ privacy_led: privacy-led {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_INDICATOR;
+ gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ v4l2_node: camera@36 {
+ reg = <0x36>;
+
+ leds = <&privacy_led>;
+ led-names = "privacy";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.yaml b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
index 7ad2baeda0b0..7e11703acbd6 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
@@ -23,8 +23,8 @@ patternProperties:
# node name to at least catch some child nodes.
"(^led-[0-9a-f]$|led)":
type: object
-
$ref: common.yaml#
+ unevaluatedProperties: false
properties:
gpios:
diff --git a/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
new file mode 100644
index 000000000000..5c9cfa39396b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-group-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Multi-color LED built with monochromatic LEDs
+
+maintainers:
+ - Jean-Jacques Hiblot <jjhiblot@traphandler.com>
+
+description: |
+ This driver combines several monochromatic LEDs into one multi-color
+ LED using the multicolor LED class.
+
+properties:
+ compatible:
+ const: leds-group-multicolor
+
+ leds: true
+
+required:
+ - leds
+
+allOf:
+ - $ref: leds-class-multicolor.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ monochromatic-leds {
+ compatible = "gpio-leds";
+
+ led0: led-0 {
+ gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led1: led-1 {
+ gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led2: led-2 {
+ gpios = <&mcu_pio 2 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
+ multi-led {
+ compatible = "leds-group-multicolor";
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ leds = <&led0>, <&led1>, <&led2>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/leds-lgm.yaml b/Documentation/devicetree/bindings/leds/leds-lgm.yaml
index f8d7963c3a13..8b3b3bf1eaf2 100644
--- a/Documentation/devicetree/bindings/leds/leds-lgm.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lgm.yaml
@@ -56,7 +56,8 @@ properties:
patternProperties:
"^led@[0-2]$":
- type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -64,6 +65,9 @@ properties:
minimum: 0
maximum: 2
+ led-gpios:
+ maxItems: 1
+
intel,sso-hw-trigger:
type: boolean
description: This property indicates Hardware driven/control LED.
@@ -118,14 +122,14 @@ examples:
reg = <0>;
function = "gphy";
color = <LED_COLOR_ID_GREEN>;
- led-gpio = <&ssogpio 0 0>;
+ led-gpios = <&ssogpio 0 0>;
};
led@2 {
reg = <2>;
function = LED_FUNCTION_POWER;
color = <LED_COLOR_ID_GREEN>;
- led-gpio = <&ssogpio 23 0>;
+ led-gpios = <&ssogpio 23 0>;
};
};
};
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
deleted file mode 100644
index b1103d961d6c..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-* Texas Instruments - LM3692x Highly Efficient White LED Driver
-
-The LM3692x is an ultra-compact, highly efficient,
-white-LED driver designed for LCD display backlighting.
-
-The main difference between the LM36922 and LM36923 is the number of
-LED strings it supports. The LM36922 supports two strings while the LM36923
-supports three strings.
-
-Required properties:
- - compatible:
- "ti,lm36922"
- "ti,lm36923"
- - reg : I2C slave address
- - #address-cells : 1
- - #size-cells : 0
-
-Optional properties:
- - enable-gpios : gpio pin to enable/disable the device.
- - vled-supply : LED supply
- - ti,ovp-microvolt: Overvoltage protection in
- micro-volt, can be 17000000, 21000000, 25000000 or
- 29000000. If ti,ovp-microvolt is not specified it
- defaults to 29000000.
-
-Required child properties:
- - reg : 0 - Will enable all LED sync paths
- 1 - Will enable the LED1 sync
- 2 - Will enable the LED2 sync
- 3 - Will enable the LED3 sync (LM36923 only)
-
-Optional child properties:
- - function : see Documentation/devicetree/bindings/leds/common.txt
- - color : see Documentation/devicetree/bindings/leds/common.txt
- - label : see Documentation/devicetree/bindings/leds/common.txt (deprecated)
- - linux,default-trigger :
- see Documentation/devicetree/bindings/leds/common.txt
- - led-max-microamp :
- see Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
-#include <dt-bindings/leds/common.h>
-
-led-controller@36 {
- compatible = "ti,lm3692x";
- reg = <0x36>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
- vled-supply = <&vbatt>;
- ti,ovp-microvolt = <29000000>;
-
- led@0 {
- reg = <0>;
- function = LED_FUNCTION_BACKLIGHT;
- color = <LED_COLOR_ID_WHITE>;
- linux,default-trigger = "backlight";
- led-max-microamp = <20000>;
- };
-}
-
-For more product information please see the link below:
-https://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
index 63da380748bf..23f809906ba7 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
@@ -77,6 +77,19 @@ patternProperties:
"^led@[0-9a-f]+$":
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ items:
+ - minimum: 0
+ maximum: 2
+
+ description:
+ This property denotes the index within the LED bank.
+
+ required:
+ - reg
required:
- compatible
@@ -130,18 +143,18 @@ examples:
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_STANDBY;
- led@3 {
- reg = <0x3>;
+ led@0 {
+ reg = <0x0>;
color = <LED_COLOR_ID_RED>;
};
- led@4 {
- reg = <0x4>;
+ led@1 {
+ reg = <0x1>;
color = <LED_COLOR_ID_GREEN>;
};
- led@5 {
- reg = <0x5>;
+ led@2 {
+ reg = <0x2>;
color = <LED_COLOR_ID_BLUE>;
};
};
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
index 7ec676e53851..fe8aaecf3010 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
@@ -28,6 +28,7 @@ properties:
- national,lp5523
- ti,lp55231
- ti,lp5562
+ - ti,lp5569
- ti,lp8501
reg:
@@ -43,11 +44,13 @@ properties:
- 1 # internal
- 2 # external
- enable-gpio:
+ enable-gpios:
maxItems: 1
description: |
GPIO attached to the chip's enable pin
+ label: true
+
pwr-sel:
$ref: /schemas/types.yaml#/definitions/uint8
description: |
@@ -64,10 +67,59 @@ properties:
'#size-cells':
const: 0
+ ti,charge-pump-mode:
+ description:
+ Set the operating mode of the internal charge pump as defined in
+ <dt-bindings/leds/leds-lp55xx.h>.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 3 # auto
+ maximum: 3
+
patternProperties:
- "(^led@[0-9a-f]$|led)":
+ '^multi-led@[0-8]$':
+ type: object
+ $ref: leds-class-multicolor.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maximum: 8
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^led@[0-8]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ led-cur:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: |
+ Current setting at each LED channel (mA x10, 0 if LED is not connected)
+ minimum: 0
+ maximum: 255
+
+ max-cur:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: Maximum current at each LED channel.
+
+ reg:
+ maximum: 8
+
+ required:
+ - reg
+
+ "^led@[0-8]$":
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
+
properties:
led-cur:
$ref: /schemas/types.yaml#/definitions/uint8
@@ -78,7 +130,7 @@ patternProperties:
max-cur:
$ref: /schemas/types.yaml#/definitions/uint8
- description: Maximun current at each LED channel.
+ description: Maximum current at each LED channel.
reg:
description: |
@@ -100,6 +152,16 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/string
description: name of channel
+if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: ti,lp8501
+then:
+ properties:
+ pwr-sel: false
+
required:
- compatible
- reg
@@ -109,6 +171,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
+ #include <dt-bindings/leds/leds-lp55xx.h>
i2c {
#address-cells = <1>;
@@ -121,6 +184,7 @@ examples:
reg = <0x32>;
clock-mode = /bits/ 8 <2>;
pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
+ ti,charge-pump-mode = <LP55XX_CP_BYPASS>;
led@0 {
reg = <0>;
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
deleted file mode 100644
index 8bb25749a3da..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Texas Instruments - lp8860 4-Channel LED Driver
-
-The LP8860-Q1 is an high-efficiency LED
-driver with boost controller. It has 4 high-precision
-current sinks that can be controlled by a PWM input
-signal, a SPI/I2C master, or both.
-
-Required properties:
- - compatible :
- "ti,lp8860"
- - reg : I2C slave address
- - #address-cells : 1
- - #size-cells : 0
-
-Optional properties:
- - enable-gpios : gpio pin to enable (active high)/disable the device.
- - vled-supply : LED supply
-
-Required child properties:
- - reg : 0
-
-Optional child properties:
- - function : see Documentation/devicetree/bindings/leds/common.txt
- - color : see Documentation/devicetree/bindings/leds/common.txt
- - label : see Documentation/devicetree/bindings/leds/common.txt (deprecated)
- - linux,default-trigger :
- see Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
-#include <dt-bindings/leds/common.h>
-
-led-controller@2d {
- compatible = "ti,lp8860";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x2d>;
- enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
- vled-supply = <&vbatt>;
-
- led@0 {
- reg = <0>;
- function = LED_FUNCTION_BACKLIGHT;
- color = <LED_COLOR_ID_WHITE>;
- linux,default-trigger = "backlight";
- };
-}
-
-For more product information please see the link below:
-https://www.ti.com/product/lp8860-q1
diff --git a/Documentation/devicetree/bindings/leds/leds-max77650.yaml b/Documentation/devicetree/bindings/leds/leds-max77650.yaml
index c6f96cabd4d1..fdb08f44a45d 100644
--- a/Documentation/devicetree/bindings/leds/leds-max77650.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-max77650.yaml
@@ -30,9 +30,8 @@ properties:
patternProperties:
"^led@[0-2]$":
- type: object
- description: |
- Properties for a single LED.
+ $ref: common.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -41,10 +40,6 @@ patternProperties:
minimum: 0
maximum: 2
- label: true
-
- linux,default-trigger: true
-
required:
- compatible
- "#address-cells"
diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
deleted file mode 100644
index 45bf9f7d85f3..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-mt6323.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Device Tree Bindings for LED support on MT6323 PMIC
-
-MT6323 LED controller is subfunction provided by MT6323 PMIC, so the LED
-controllers are defined as the subnode of the function node provided by MT6323
-PMIC controller that is being defined as one kind of Muti-Function Device (MFD)
-using shared bus called PMIC wrapper for each subfunction to access remote
-MT6323 PMIC hardware.
-
-For MT6323 MFD bindings see:
-Documentation/devicetree/bindings/mfd/mt6397.txt
-For MediaTek PMIC wrapper bindings see:
-Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
-
-Required properties:
-- compatible : Must be "mediatek,mt6323-led"
-- address-cells : Must be 1
-- size-cells : Must be 0
-
-Each led is represented as a child node of the mediatek,mt6323-led that
-describes the initial behavior for each LED physically and currently only four
-LED child nodes can be supported.
-
-Required properties for the LED child node:
-- reg : LED channel number (0..3)
-
-Optional properties for the LED child node:
-- label : See Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger : See Documentation/devicetree/bindings/leds/common.txt
-- default-state: See Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
- mt6323: pmic {
- compatible = "mediatek,mt6323";
-
- ...
-
- mt6323led: leds {
- compatible = "mediatek,mt6323-led";
- #address-cells = <1>;
- #size-cells = <0>;
-
- led@0 {
- reg = <0>;
- label = "LED0";
- linux,default-trigger = "timer";
- default-state = "on";
- };
- led@1 {
- reg = <1>;
- label = "LED1";
- default-state = "off";
- };
- led@2 {
- reg = <2>;
- label = "LED2";
- default-state = "on";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml
index 69e579226d9b..d2e1d8afc302 100644
--- a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml
@@ -26,11 +26,10 @@ properties:
const: 0
patternProperties:
- "^(multi-)?led@[0-5]$":
+ "^multi-led@[0-5]$":
type: object
- $ref: common.yaml#
- description:
- Properties for a single LED.
+ $ref: leds-class-multicolor.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -43,6 +42,42 @@ patternProperties:
- 4 # LED output FLASH1
- 5 # LED output FLASH2
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-2]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [0, 1, 2]
+
+ required:
+ - reg
+ - color
+
+ required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+ "^led@[0-5]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for a single LED.
+
+ properties:
+ reg:
+ enum: [0, 1, 2, 3, 4, 5]
+
required:
- compatible
- "#address-cells"
@@ -52,106 +87,105 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/leds/common.h>
- led-controller {
- compatible = "mediatek,mt6360-led";
- #address-cells = <1>;
- #size-cells = <0>;
-
- multi-led@0 {
- reg = <0>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_RGB>;
- led-max-microamp = <24000>;
- #address-cells = <1>;
- #size-cells = <0>;
- led@0 {
- reg = <0>;
- color = <LED_COLOR_ID_RED>;
- };
- led@1 {
- reg = <1>;
- color = <LED_COLOR_ID_GREEN>;
- };
- led@2 {
- reg = <2>;
- color = <LED_COLOR_ID_BLUE>;
- };
- };
- led@3 {
- reg = <3>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_WHITE>;
- led-max-microamp = <150000>;
- };
- led@4 {
- reg = <4>;
- function = LED_FUNCTION_FLASH;
- color = <LED_COLOR_ID_WHITE>;
- function-enumerator = <1>;
- led-max-microamp = <200000>;
- flash-max-microamp = <500000>;
- flash-max-timeout-us = <1024000>;
- };
- led@5 {
- reg = <5>;
- function = LED_FUNCTION_FLASH;
- color = <LED_COLOR_ID_WHITE>;
- function-enumerator = <2>;
- led-max-microamp = <200000>;
- flash-max-microamp = <500000>;
- flash-max-timeout-us = <1024000>;
- };
- };
+ #include <dt-bindings/leds/common.h>
+ led-controller {
+ compatible = "mediatek,mt6360-led";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ multi-led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_RGB>;
+ led-max-microamp = <24000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_WHITE>;
+ led-max-microamp = <150000>;
+ };
+ led@4 {
+ reg = <4>;
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ function-enumerator = <1>;
+ led-max-microamp = <200000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <1024000>;
+ };
+ led@5 {
+ reg = <5>;
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ function-enumerator = <2>;
+ led-max-microamp = <200000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <1024000>;
+ };
+ };
- |
+ led-controller {
+ compatible = "mediatek,mt6360-led";
+ #address-cells = <1>;
+ #size-cells = <0>;
- led-controller {
- compatible = "mediatek,mt6360-led";
- #address-cells = <1>;
- #size-cells = <0>;
-
- led@0 {
- reg = <0>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_RED>;
- led-max-microamp = <24000>;
- };
- led@1 {
- reg = <1>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_GREEN>;
- led-max-microamp = <24000>;
- };
- led@2 {
- reg = <2>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_BLUE>;
- led-max-microamp = <24000>;
- };
- led@3 {
- reg = <3>;
- function = LED_FUNCTION_INDICATOR;
- color = <LED_COLOR_ID_WHITE>;
- led-max-microamp = <150000>;
- };
- led@4 {
- reg = <4>;
- function = LED_FUNCTION_FLASH;
- color = <LED_COLOR_ID_WHITE>;
- function-enumerator = <1>;
- led-max-microamp = <200000>;
- flash-max-microamp = <500000>;
- flash-max-timeout-us = <1024000>;
- };
- led@5 {
- reg = <5>;
- function = LED_FUNCTION_FLASH;
- color = <LED_COLOR_ID_WHITE>;
- function-enumerator = <2>;
- led-max-microamp = <200000>;
- flash-max-microamp = <500000>;
- flash-max-timeout-us = <1024000>;
- };
- };
+ led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_RED>;
+ led-max-microamp = <24000>;
+ };
+ led@1 {
+ reg = <1>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_GREEN>;
+ led-max-microamp = <24000>;
+ };
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_BLUE>;
+ led-max-microamp = <24000>;
+ };
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_WHITE>;
+ led-max-microamp = <150000>;
+ };
+ led@4 {
+ reg = <4>;
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ function-enumerator = <1>;
+ led-max-microamp = <200000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <1024000>;
+ };
+ led@5 {
+ reg = <5>;
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ function-enumerator = <2>;
+ led-max-microamp = <200000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <1024000>;
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
deleted file mode 100644
index f769c52e3643..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-*NXP - pca9532 PWM LED Driver
-
-The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
-The PWM support 256 steps.
-
-Required properties:
- - compatible:
- "nxp,pca9530"
- "nxp,pca9531"
- "nxp,pca9532"
- "nxp,pca9533"
- - reg - I2C slave address
-
-Each led is represented as a sub-node of the nxp,pca9530.
-
-Optional sub-node properties:
- - label: see Documentation/devicetree/bindings/leds/common.txt
- - type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
- - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
- - default-state: see Documentation/devicetree/bindings/leds/common.txt
- This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
-
-Example:
- #include <dt-bindings/leds/leds-pca9532.h>
-
- leds: pca9530@60 {
- compatible = "nxp,pca9530";
- reg = <0x60>;
-
- red-power {
- label = "pca:red:power";
- type = <PCA9532_TYPE_LED>;
- };
- green-power {
- label = "pca:green:power";
- type = <PCA9532_TYPE_LED>;
- };
- kernel-booting {
- type = <PCA9532_TYPE_LED>;
- default-state = "on";
- };
- sys-stat {
- type = <PCA9532_TYPE_LED>;
- default-state = "keep"; // don't touch, was set by U-Boot
- };
- };
-
-For more product information please see the link below:
-http://nxp.com/documents/data_sheet/PCA9532.pdf
diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
deleted file mode 100644
index 817f460f3a72..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-* NXP - pca955x LED driver
-
-The PCA955x family of chips are I2C LED blinkers whose pins not used
-to control LEDs can be used as general purpose I/Os. The GPIO pins can
-be input or output, and output pins can also be pulse-width controlled.
-
-Required properties:
-- compatible : should be one of :
- "nxp,pca9550"
- "nxp,pca9551"
- "nxp,pca9552"
- "ibm,pca9552"
- "nxp,pca9553"
-- #address-cells: must be 1
-- #size-cells: must be 0
-- reg: I2C slave address. depends on the model.
-
-Optional properties:
-- gpio-controller: allows pins to be used as GPIOs.
-- #gpio-cells: must be 2.
-- gpio-line-names: define the names of the GPIO lines
-
-LED sub-node properties:
-- reg : number of LED line.
- from 0 to 1 for the pca9550
- from 0 to 7 for the pca9551
- from 0 to 15 for the pca9552
- from 0 to 3 for the pca9553
-- type: (optional) either
- PCA955X_TYPE_NONE
- PCA955X_TYPE_LED
- PCA955X_TYPE_GPIO
- see dt-bindings/leds/leds-pca955x.h (default to LED)
-- label : (optional)
- see Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger : (optional)
- see Documentation/devicetree/bindings/leds/common.txt
-
-Examples:
-
-pca9552: pca9552@60 {
- compatible = "nxp,pca9552";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x60>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-line-names = "GPIO12", "GPIO13", "GPIO14", "GPIO15";
-
- gpio@12 {
- reg = <12>;
- type = <PCA955X_TYPE_GPIO>;
- };
- gpio@13 {
- reg = <13>;
- type = <PCA955X_TYPE_GPIO>;
- };
- gpio@14 {
- reg = <14>;
- type = <PCA955X_TYPE_GPIO>;
- };
- gpio@15 {
- reg = <15>;
- type = <PCA955X_TYPE_GPIO>;
- };
-
- led@0 {
- label = "red:power";
- linux,default-trigger = "default-on";
- reg = <0>;
- type = <PCA955X_TYPE_LED>;
- };
- led@1 {
- label = "green:power";
- reg = <1>;
- type = <PCA955X_TYPE_LED>;
- };
- led@2 {
- label = "pca9552:yellow";
- reg = <2>;
- type = <PCA955X_TYPE_LED>;
- };
- led@3 {
- label = "pca9552:white";
- reg = <3>;
- type = <PCA955X_TYPE_LED>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-pm8058.txt b/Documentation/devicetree/bindings/leds/leds-pm8058.txt
deleted file mode 100644
index 89584c49aab2..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-pm8058.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-Qualcomm PM8058 LED driver
-
-The Qualcomm PM8058 is a multi-functional device which contains
-an LED driver block for up to six LEDs: three normal LEDs, two
-"flash" LEDs and one "keypad backlight" LED. The names are
-quoted because sometimes these LED drivers are used for wildly
-different things than flash or keypad backlight: their names
-are more of a suggestion than a hard-wired usecase.
-
-Hardware-wise the different LEDs support slightly different
-output currents. The "flash" LEDs do not need to charge nor
-do they support external triggers. They are just powerful LED
-drivers.
-
-The LEDs appear as children to the PM8058 device, with the
-proper compatible string. For the PM8058 bindings see:
-mfd/qcom-pm8xxx.txt.
-
-Each LED is represented as a sub-node of the syscon device. Each
-node's name represents the name of the corresponding LED.
-
-LED sub-node properties:
-
-Required properties:
-- compatible: one of
- "qcom,pm8058-led" (for the normal LEDs at 0x131, 0x132 and 0x133)
- "qcom,pm8058-keypad-led" (for the "keypad" LED at 0x48)
- "qcom,pm8058-flash-led" (for the "flash" LEDs at 0x49 and 0xFB)
-
-Optional properties:
-- label: see Documentation/devicetree/bindings/leds/common.txt
-- default-state: see Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
-
-Example:
-
-qcom,ssbi@500000 {
- pmicintc: pmic@0 {
- compatible = "qcom,pm8058";
- led@48 {
- compatible = "qcom,pm8058-keypad-led";
- reg = <0x48>;
- label = "pm8050:white:keypad";
- default-state = "off";
- };
- led@131 {
- compatible = "qcom,pm8058-led";
- reg = <0x131>;
- label = "pm8058:red";
- default-state = "off";
- };
- led@132 {
- compatible = "qcom,pm8058-led";
- reg = <0x132>;
- label = "pm8058:yellow";
- default-state = "off";
- linux,default-trigger = "mmc0";
- };
- led@133 {
- compatible = "qcom,pm8058-led";
- reg = <0x133>;
- label = "pm8058:green";
- default-state = "on";
- linux,default-trigger = "heartbeat";
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
index bd6ec04a8727..a31a202afe5c 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
@@ -41,9 +41,7 @@ properties:
pwm-names: true
- active-low:
- description: For PWMs where the LED is wired to supply rather than ground.
- type: boolean
+ active-low: true
color: true
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
index fe4d5fd25913..6c4fcefbe25f 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
@@ -20,8 +20,8 @@ properties:
patternProperties:
"^led(-[0-9a-f]+)?$":
type: object
-
$ref: common.yaml#
+ unevaluatedProperties: false
properties:
pwms:
@@ -34,10 +34,18 @@ patternProperties:
Maximum brightness possible for the LED
$ref: /schemas/types.yaml#/definitions/uint32
- active-low:
+ default-brightness:
description:
- For PWMs where the LED is wired to supply rather than ground.
- type: boolean
+ Brightness to be set if LED's default state is on. Used only during
+ initialization. If the option is not set then max brightness is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ enable-gpios:
+ description:
+ GPIO for LED hardware enable control. Set active when brightness is
+ non-zero and inactive when brightness is zero.
+ The GPIO default state follows the "default-state" property.
+ maxItems: 1
required:
- pwms
diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
index 497db289169d..c4b7e57b2518 100644
--- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml
@@ -11,22 +11,43 @@ maintainers:
description: >
The Qualcomm Light Pulse Generator consists of three different hardware blocks;
- a ramp generator with lookup table, the light pulse generator and a three
+ a ramp generator with lookup table (LUT), the light pulse generator and a three
channel current sink. These blocks are found in a wide range of Qualcomm PMICs.
+ The light pulse generator (LPG) can also be used independently to output PWM
+ signal for standard PWM applications. In this scenario, the LPG output should
+ be routed to a specific PMIC GPIO by setting the GPIO pin mux to the special
+ functions indicated in the datasheet, the TRILED driver for the channel will
+ not be enabled in this configuration.
properties:
compatible:
- enum:
- - qcom,pm660l-lpg
- - qcom,pm8150b-lpg
- - qcom,pm8150l-lpg
- - qcom,pm8350c-pwm
- - qcom,pm8916-pwm
- - qcom,pm8941-lpg
- - qcom,pm8994-lpg
- - qcom,pmc8180c-lpg
- - qcom,pmi8994-lpg
- - qcom,pmi8998-lpg
+ oneOf:
+ - enum:
+ - qcom,pm660l-lpg
+ - qcom,pm8150b-lpg
+ - qcom,pm8150l-lpg
+ - qcom,pm8350c-pwm
+ - qcom,pm8916-pwm
+ - qcom,pm8941-lpg
+ - qcom,pm8994-lpg
+ - qcom,pmc8180c-lpg
+ - qcom,pmi632-lpg
+ - qcom,pmi8950-pwm
+ - qcom,pmi8994-lpg
+ - qcom,pmi8998-lpg
+ - qcom,pmk8550-pwm
+ - items:
+ - enum:
+ - qcom,pm6150l-lpg
+ - const: qcom,pm8150l-lpg
+ - items:
+ - enum:
+ - qcom,pm8550-pwm
+ - const: qcom,pm8350c-pwm
+ - items:
+ - enum:
+ - qcom,pm8937-pwm
+ - const: qcom,pm8916-pwm
"#pwm-cells":
const: 2
@@ -49,13 +70,36 @@ properties:
description: >
A list of integer pairs, where each pair represent the dtest line the
particular channel should be connected to and the flags denoting how the
- value should be outputed, as defined in the datasheet. The number of
+ value should be outputted, as defined in the datasheet. The number of
pairs should be the same as the number of channels.
items:
items:
- description: dtest line to attach
- description: flags for the attachment
+ nvmem:
+ description: >
+ This property is required for PMICs that supports PPG, which is when a
+ PMIC stores LPG per-channel data and pattern LUT in SDAM modules instead
+ of in a LUT peripheral. For PMICs, such as PM8350C, per-channel data
+ and pattern LUT is separated into 2 SDAM modules. In that case, phandles
+ to both SDAM modules need to be specified.
+ minItems: 1
+ maxItems: 2
+
+ nvmem-names:
+ minItems: 1
+ items:
+ - const: lpg_chan_sdam
+ - const: lut_sdam
+
+ qcom,pbs:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: >
+ Phandle of the Qualcomm Programmable Boot Sequencer node (PBS).
+ PBS node is used to trigger LPG pattern sequences for PMICs that support
+ single SDAM PPG.
+
multi-led:
type: object
$ref: leds-class-multicolor.yaml#
@@ -72,14 +116,24 @@ properties:
"^led@[0-9a-f]$":
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
patternProperties:
"^led@[0-9a-f]$":
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
properties:
- reg: true
+ reg:
+ maxItems: 1
required:
- reg
@@ -89,6 +143,53 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pm660l-lpg
+ - qcom,pm8150b-lpg
+ - qcom,pm8150l-lpg
+ - qcom,pm8916-pwm
+ - qcom,pm8941-lpg
+ - qcom,pm8994-lpg
+ - qcom,pmc8180c-lpg
+ - qcom,pmi8950-pwm
+ - qcom,pmi8994-lpg
+ - qcom,pmi8998-lpg
+ - qcom,pmk8550-pwm
+ then:
+ properties:
+ nvmem: false
+ nvmem-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,pmi632-lpg
+ then:
+ properties:
+ nvmem:
+ maxItems: 1
+ nvmem-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pm8350c-pwm
+ then:
+ properties:
+ nvmem:
+ minItems: 2
+ nvmem-names:
+ minItems: 2
+
examples:
- |
#include <dt-bindings/leds/common.h>
@@ -174,4 +275,33 @@ examples:
compatible = "qcom,pm8916-pwm";
#pwm-cells = <2>;
};
-...
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ led-controller {
+ compatible = "qcom,pmi632-lpg";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pwm-cells = <2>;
+ nvmem-names = "lpg_chan_sdam";
+ nvmem = <&pmi632_sdam_7>;
+ qcom,pbs = <&pmi632_pbs_client3>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ label = "red";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_GREEN>;
+ label = "green";
+ };
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_BLUE>;
+ label = "blue";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/leds-rt4505.yaml b/Documentation/devicetree/bindings/leds/leds-rt4505.yaml
index 5b0c74aa6723..bfd0e240f7d6 100644
--- a/Documentation/devicetree/bindings/leds/leds-rt4505.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-rt4505.yaml
@@ -27,6 +27,7 @@ properties:
led:
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
required:
- compatible
@@ -38,7 +39,7 @@ examples:
- |
#include <dt-bindings/leds/common.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt b/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt
deleted file mode 100644
index df2b4e1c492b..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-sc27xx-bltc.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-LEDs connected to Spreadtrum SC27XX PMIC breathing light controller
-
-The SC27xx breathing light controller supports to 3 outputs:
-red LED, green LED and blue LED. Each LED can work at normal
-PWM mode or breath light mode.
-
-Required properties:
-- compatible: Should be "sprd,sc2731-bltc".
-- #address-cells: Must be 1.
-- #size-cells: Must be 0.
-- reg: Specify the controller address.
-
-Required child properties:
-- reg: Port this LED is connected to.
-
-Optional child properties:
-- function: See Documentation/devicetree/bindings/leds/common.txt.
-- color: See Documentation/devicetree/bindings/leds/common.txt.
-- label: See Documentation/devicetree/bindings/leds/common.txt (deprecated).
-
-Examples:
-
-led-controller@200 {
- compatible = "sprd,sc2731-bltc";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x200>;
-
- led@0 {
- color = <LED_COLOR_ID_RED>;
- reg = <0x0>;
- };
-
- led@1 {
- color = <LED_COLOR_ID_GREEN>;
- reg = <0x1>;
- };
-
- led@2 {
- color = <LED_COLOR_ID_BLUE>;
- reg = <0x2>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
index f68259619488..37d2a93780ab 100644
--- a/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-sgm3140.yaml
@@ -18,7 +18,10 @@ description: |
properties:
compatible:
- const: sgmicro,sgm3140
+ enum:
+ - ocs,ocp8110
+ - richtek,rt5033-led
+ - sgmicro,sgm3140
enable-gpios:
maxItems: 1
@@ -34,6 +37,7 @@ properties:
led:
type: object
$ref: common.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/leds/leds-tlc591xx.txt b/Documentation/devicetree/bindings/leds/leds-tlc591xx.txt
deleted file mode 100644
index 3bbbf7024411..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-tlc591xx.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-LEDs connected to tlc59116 or tlc59108
-
-Required properties
-- compatible: should be "ti,tlc59116" or "ti,tlc59108"
-- #address-cells: must be 1
-- #size-cells: must be 0
-- reg: typically 0x68
-
-Each led is represented as a sub-node of the ti,tlc59116.
-See Documentation/devicetree/bindings/leds/common.txt
-
-LED sub-node properties:
-- reg: number of LED line, 0 to 15 or 0 to 7
-- label: (optional) name of LED
-- linux,default-trigger : (optional)
-
-Examples:
-
-tlc59116@68 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "ti,tlc59116";
- reg = <0x68>;
-
- wan@0 {
- label = "wrt1900ac:amber:wan";
- reg = <0x0>;
- };
-
- 2g@2 {
- label = "wrt1900ac:white:2g";
- reg = <0x2>;
- };
-
- alive@9 {
- label = "wrt1900ac:green:alive";
- reg = <0x9>;
- linux,default_trigger = "heartbeat";
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml b/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml
new file mode 100644
index 000000000000..e9d02ed6a590
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/mediatek,mt6370-flashlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Flash LED driver for MT6370 PMIC from MediaTek Integrated.
+
+maintainers:
+ - Alice Chen <alice_chen@richtek.com>
+
+description: |
+ This module is part of the MT6370 MFD device.
+ Add MT6370 flash LED driver include 2-channel flash LED support Torch/Strobe Mode.
+
+properties:
+ compatible:
+ const: mediatek,mt6370-flashlight
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-1]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [0, 1]
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml b/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml
new file mode 100644
index 000000000000..16b3abc2af3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/mediatek,mt6370-indicator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for MT6370 PMIC from MediaTek Integrated.
+
+maintainers:
+ - Alice Chen <alice_chen@richtek.com>
+
+description: |
+ This module is part of the MT6370 MFD device.
+ Add MT6370 LED driver include 4-channel RGB LED support Register/PWM/Breath Mode
+
+properties:
+ compatible:
+ const: mediatek,mt6370-indicator
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^multi-led@[0-3]$":
+ type: object
+ $ref: leds-class-multicolor.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [0, 1, 2, 3]
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-2]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [0, 1, 2]
+
+ required:
+ - reg
+ - color
+
+ required:
+ - reg
+ - color
+ - "#address-cells"
+ - "#size-cells"
+
+ "^led@[0-3]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [0, 1, 2, 3]
+
+ required:
+ - reg
+ - color
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml
new file mode 100644
index 000000000000..9610bca57dd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/nxp,pca953x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA9532 LED Dimmer
+
+maintainers:
+ - Riku Voipio <riku.voipio@iki.fi>
+
+description: |
+ The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
+ The PWM support 256 steps.
+
+ For more product information please see the link below:
+ https://www.nxp.com/docs/en/data-sheet/PCA9532.pdf
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9530
+ - nxp,pca9531
+ - nxp,pca9532
+ - nxp,pca9533
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 16
+
+ '#gpio-cells':
+ const: 2
+
+patternProperties:
+ "^led-[0-9a-z]+$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ type:
+ description: |
+ Output configuration, see include/dt-bindings/leds/leds-pca9532.h
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ minimum: 0
+ maximum: 4
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/leds-pca9532.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@62 {
+ compatible = "nxp,pca9533";
+ reg = <0x62>;
+
+ led-1 {
+ label = "pca:red:power";
+ type = <PCA9532_TYPE_LED>;
+ };
+
+ led-2 {
+ label = "pca:green:power";
+ type = <PCA9532_TYPE_LED>;
+ };
+
+ led-3 {
+ type = <PCA9532_TYPE_LED>;
+ default-state = "on";
+ };
+
+ led-4 {
+ type = <PCA9532_TYPE_LED>;
+ default-state = "keep";
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/nxp,pca955x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca955x.yaml
new file mode 100644
index 000000000000..ae7384cc760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/nxp,pca955x.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/nxp,pca955x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA955X LED controllers
+
+maintainers:
+ - Nate Case <ncase@xes-inc.com>
+
+description: |
+ The PCA955x family of chips are I2C LED blinkers whose pins not used
+ to control LEDs can be used as general purpose I/Os. The GPIO pins can
+ be input or output, and output pins can also be pulse-width controlled.
+
+ For more product information please see the link below:
+ - https://www.nxp.com/docs/en/data-sheet/PCA9552.pdf
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9550
+ - nxp,pca9551
+ - nxp,pca9552
+ - ibm,pca9552
+ - nxp,pca9553
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ gpio-controller: true
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 16
+
+ "#gpio-cells":
+ const: 2
+
+patternProperties:
+ "^led@[0-9a-f]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+ type:
+ description: |
+ Output configuration, see include/dt-bindings/leds/leds-pca955x.h
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ minimum: 0
+ maximum: 2
+
+ required:
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,pca9550
+ then:
+ patternProperties:
+ "^led@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,pca9551
+ then:
+ patternProperties:
+ "^led@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 7
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,pca9552
+ - ibm,pca9552
+ then:
+ patternProperties:
+ "^led@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 15
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,pca9553
+ then:
+ patternProperties:
+ "^led@[0-9a-f]$":
+ properties:
+ reg:
+ maximum: 3
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/leds-pca955x.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@60 {
+ compatible = "nxp,pca9552";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ label = "red:power";
+ linux,default-trigger = "default-on";
+ type = <PCA955X_TYPE_LED>;
+ };
+ led@1 {
+ reg = <1>;
+ label = "green:power";
+ type = <PCA955X_TYPE_LED>;
+ };
+ led@2 {
+ reg = <2>;
+ label = "pca9552:yellow";
+ type = <PCA955X_TYPE_LED>;
+ };
+ led@3 {
+ reg = <3>;
+ label = "pca9552:white";
+ type = <PCA955X_TYPE_LED>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
new file mode 100644
index 000000000000..938d0e48fe51
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/nxp,pca963x.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/nxp,pca963x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA963x LED controllers
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ The NXP PCA963x are I2C-controlled LED drivers optimized for
+ Red/Green/Blue/Amber (RGBA) color mixing applications. Each LED is
+ individually controllable and has its own PWM controller.
+
+ Datasheets are available at
+
+ - https://www.nxp.com/docs/en/data-sheet/PCA9632.pdf
+ - https://www.nxp.com/docs/en/data-sheet/PCA9633.pdf
+ - https://www.nxp.com/docs/en/data-sheet/PCA9634.pdf
+ - https://www.nxp.com/docs/en/data-sheet/PCA9635.pdf
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9632
+ - nxp,pca9633
+ - nxp,pca9634
+ - nxp,pca9635
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ nxp,hw-blink:
+ type: boolean
+ description:
+ Use hardware blinking instead of software blinking
+
+ nxp,inverted-out:
+ type: boolean
+ description:
+ Invert the polarity of the generated PWM.
+
+ nxp,period-scale:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ In some configurations, the chip blinks faster than expected. This
+ parameter provides a scaling ratio (fixed point, decimal divided by 1000)
+ to compensate, e.g. 1300=1.3x and 750=0.75x.
+
+ nxp,totem-pole:
+ type: boolean
+ description:
+ Use totem pole (push-pull) instead of open-drain (pca9632 defaults to
+ open-drain, newer chips to totem pole).
+
+patternProperties:
+ "^led@[0-9a-f]+$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+
+ required:
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,pca9632
+ - nxp,pca9633
+ then:
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ properties:
+ reg:
+ maximum: 3
+ else:
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ properties:
+ reg:
+ maximum: 7
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@62 {
+ compatible = "nxp,pca9632";
+ reg = <0x62>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_STATUS;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ };
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_STATUS;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml
new file mode 100644
index 000000000000..ab8c90cbadb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/nxp,pca995x.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/nxp,pca995x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA995x LED controllers
+
+maintainers:
+ - Isai Gaspar <isaiezequiel.gaspar@nxp.com>
+ - Marek Vasut <marex@denx.de>
+
+description:
+ The NXP PCA995x family are programmable LED controllers connected via I2C
+ that can drive separate lines. Each of them can be individually switched
+ on and off, and brightness can be controlled via individual PWM.
+
+ Datasheets are available at
+ https://www.nxp.com/docs/en/data-sheet/PCA9952_PCA9955.pdf
+ https://www.nxp.com/docs/en/data-sheet/PCA9955B.pdf
+ https://www.nxp.com/docs/en/data-sheet/PCA9956B.pdf
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9952
+ - nxp,pca9955b
+ - nxp,pca9956b
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-9a-f]+$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 15
+
+ required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1 {
+ compatible = "nxp,pca9955b";
+ reg = <0x01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_POWER;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_STATUS;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/onnn,ncp5623.yaml b/Documentation/devicetree/bindings/leds/onnn,ncp5623.yaml
new file mode 100644
index 000000000000..11d45c7f741d
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/onnn,ncp5623.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/onnn,ncp5623.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor NCP5623 multi-LED Driver
+
+maintainers:
+ - Abdel Alkuor <alkuor@gmail.com>
+
+description:
+ NCP5623 Triple Output I2C Controlled LED Driver.
+ https://www.onsemi.com/pdf/datasheet/ncp5623-d.pdf
+
+properties:
+ compatible:
+ enum:
+ - onnn,ncp5623
+
+ reg:
+ enum:
+ - 0x38
+ - 0x39
+
+ multi-led:
+ type: object
+ $ref: leds-class-multicolor.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-2]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 2
+
+ required:
+ - reg
+ - color
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+required:
+ - compatible
+ - reg
+ - multi-led
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@38 {
+ compatible = "onnn,ncp5623";
+ reg = <0x38>;
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml b/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml
new file mode 100644
index 000000000000..e918dceea082
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/panasonic,an30259a.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/panasonic,an30259a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Panasonic AN30259A 3-channel LED controller
+
+maintainers:
+ - Iskren Chernev <me@iskren.info>
+
+description:
+ The AN30259A is a LED controller capable of driving three LEDs independently.
+ It supports constant current output and sloping current output modes. The chip
+ is connected over I2C.
+
+properties:
+ compatible:
+ const: panasonic,an30259a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[1-3]$":
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ enum: [ 1, 2, 3 ]
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@30 {
+ compatible = "panasonic,an30259a";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ linux,default-trigger = "heartbeat";
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_INDICATOR;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt b/Documentation/devicetree/bindings/leds/pca963x.txt
deleted file mode 100644
index 4eee41482041..000000000000
--- a/Documentation/devicetree/bindings/leds/pca963x.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-LEDs connected to pca9632, pca9633 or pca9634
-
-Required properties:
-- compatible : should be : "nxp,pca9632", "nxp,pca9633", "nxp,pca9634" or "nxp,pca9635"
-
-Optional properties:
-- nxp,totem-pole : use totem pole (push-pull) instead of open-drain (pca9632 defaults
- to open-drain, newer chips to totem pole)
-- nxp,hw-blink : use hardware blinking instead of software blinking
-- nxp,period-scale : In some configurations, the chip blinks faster than expected.
- This parameter provides a scaling ratio (fixed point, decimal divided
- by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
-- nxp,inverted-out: invert the polarity of the generated PWM
-
-Each led is represented as a sub-node of the nxp,pca963x device.
-
-LED sub-node properties:
-- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
-- reg : number of LED line (could be from 0 to 3 in pca9632 or pca9633,
- 0 to 7 in pca9634, or 0 to 15 in pca9635)
-- linux,default-trigger : (optional)
- see Documentation/devicetree/bindings/leds/common.txt
-
-Examples:
-
-pca9632: pca9632 {
- compatible = "nxp,pca9632";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x62>;
-
- red@0 {
- label = "red";
- reg = <0>;
- linux,default-trigger = "none";
- };
- green@1 {
- label = "green";
- reg = <1>;
- linux,default-trigger = "none";
- };
- blue@2 {
- label = "blue";
- reg = <2>;
- linux,default-trigger = "none";
- };
- unused@3 {
- label = "unused";
- reg = <3>;
- linux,default-trigger = "none";
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
new file mode 100644
index 000000000000..b409b2a8b5c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/qcom,pm8058-led.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8058 PMIC LED
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
+ LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
+ because sometimes these LED drivers are used for wildly different things than
+ flash or keypad backlight:: their names are more of a suggestion than a
+ hard-wired usecase.
+
+ Hardware-wise the different LEDs support slightly different output currents.
+ The "flash" LEDs do not need to charge nor do they support external triggers.
+ They are just powerful LED drivers.
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,pm8058-led
+ - qcom,pm8058-keypad-led
+ - qcom,pm8058-flash-led
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@131 {
+ compatible = "qcom,pm8058-led";
+ reg = <0x131>;
+ label = "pm8058:red";
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml
new file mode 100644
index 000000000000..05250aefd385
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/qcom,spmi-flash-led.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Flash LED device inside Qualcomm Technologies, Inc. PMICs
+
+maintainers:
+ - Fenglin Wu <quic_fenglinw@quicinc.com>
+
+description: |
+ Flash LED controller is present inside some Qualcomm Technologies, Inc. PMICs.
+ The flash LED module can have different number of LED channels supported
+ e.g. 3 or 4. There are some different registers between them but they can
+ both support maximum current up to 1.5 A per channel and they can also support
+ ganging 2 channels together to supply maximum current up to 2 A. The current
+ will be split symmetrically on each channel and they will be enabled and
+ disabled at the same time.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,pm6150l-flash-led
+ - qcom,pm660l-flash-led
+ - qcom,pm7550-flash-led
+ - qcom,pm8150c-flash-led
+ - qcom,pm8150l-flash-led
+ - qcom,pm8350c-flash-led
+ - qcom,pm8550-flash-led
+ - qcom,pmi8998-flash-led
+ - const: qcom,spmi-flash-led
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^led-[0-3]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+ description:
+ Represents the physical LED components which are connected to the
+ flash LED channels' output.
+
+ properties:
+ led-sources:
+ description:
+ The HW indices of the flash LED channels that connect to the
+ physical LED
+ allOf:
+ - minItems: 1
+ maxItems: 2
+ items:
+ enum: [1, 2, 3, 4]
+
+ led-max-microamp:
+ anyOf:
+ - minimum: 5000
+ maximum: 500000
+ multipleOf: 5000
+ - minimum: 10000
+ maximum: 1000000
+ multipleOf: 10000
+
+ flash-max-microamp:
+ anyOf:
+ - minimum: 12500
+ maximum: 1500000
+ multipleOf: 12500
+ - minimum: 25000
+ maximum: 2000000
+ multipleOf: 25000
+
+ flash-max-timeout-us:
+ minimum: 10000
+ maximum: 1280000
+ multipleOf: 10000
+
+ required:
+ - led-sources
+ - led-max-microamp
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@ee00 {
+ compatible = "qcom,pm8350c-flash-led", "qcom,spmi-flash-led";
+ reg = <0xee00>;
+
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <4>;
+ led-max-microamp = <300000>;
+ flash-max-microamp = <2000000>;
+ flash-max-timeout-us = <1280000>;
+ function-enumerator = <0>;
+ };
+
+ led-1 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_YELLOW>;
+ led-sources = <2>, <3>;
+ led-max-microamp = <300000>;
+ flash-max-microamp = <2000000>;
+ flash-max-timeout-us = <1280000>;
+ function-enumerator = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.yaml b/Documentation/devicetree/bindings/leds/register-bit-led.yaml
index 79b8fc0f9d23..20930d327ae9 100644
--- a/Documentation/devicetree/bindings/leds/register-bit-led.yaml
+++ b/Documentation/devicetree/bindings/leds/register-bit-led.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/leds/register-bit-led.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device Tree Bindings for Register Bit LEDs
+title: Register Bit LEDs
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -60,7 +60,7 @@ examples:
- |
syscon@10000000 {
- compatible = "arm,realview-pb1176-syscon", "syscon";
+ compatible = "arm,realview-pb1176-syscon", "syscon", "simple-mfd";
reg = <0x10000000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/leds/regulator-led.yaml b/Documentation/devicetree/bindings/leds/regulator-led.yaml
index 3e020d700c00..4ef7b96e9a08 100644
--- a/Documentation/devicetree/bindings/leds/regulator-led.yaml
+++ b/Documentation/devicetree/bindings/leds/regulator-led.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/leds/regulator-led.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device Tree Bindings for Regulator LEDs
+title: Regulator LEDs
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
diff --git a/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml
new file mode 100644
index 000000000000..44dd91aa239d
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/rohm,bd2606mvv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD2606MVV LED controller
+
+maintainers:
+ - Andreas Kemnade <andreas@kemnade.info>
+
+description:
+ The BD2606 MVV is a programmable LED controller connected via I2C that can
+ drive 6 separate lines. Each of them can be individually switched on and off,
+ but the brightness setting is shared between pairs of them.
+
+ Datasheet is available at
+ https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/led_driver/bd2606mvv_1-e.pdf
+
+properties:
+ compatible:
+ const: rohm,bd2606mvv
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO pin to enable/disable the device.
+
+patternProperties:
+ "^led@[0-5]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 5
+
+ required:
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@66 {
+ compatible = "rohm,bd2606mvv";
+ reg = <0x66>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_POWER;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_STATUS;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
index 86a37c92b834..b7a3ef76cbf4 100644
--- a/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
+++ b/Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD71828 Power Management Integrated Circuit LED driver
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
This module is part of the ROHM BD71828 MFD device. For more details
@@ -18,34 +18,22 @@ description: |
The device has two LED outputs referred as GRNLED and AMBLED in data-sheet.
-select: false
-
properties:
compatible:
const: rohm,bd71828-leds
patternProperties:
"^led-[1-2]$":
- type: object
- description:
- Properties for a single LED.
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
properties:
- #allOf:
- #- $ref: "common.yaml#"
rohm,led-compatible:
description: LED identification string
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- bd71828-ambled
- bd71828-grnled
- function:
- description:
- Purpose of LED as defined in dt-bindings/leds/common.h
- $ref: "/schemas/types.yaml#/definitions/string"
- color:
- description:
- LED colour as defined in dt-bindings/leds/common.h
- $ref: "/schemas/types.yaml#/definitions/uint32"
required:
- compatible
diff --git a/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
new file mode 100644
index 000000000000..46b8e5452b62
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/silergy,sy7802.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SY7802 1800mA Boost Charge Pump LED Driver
+
+maintainers:
+ - André Apitzsch <git@apitzsch.eu>
+
+description: |
+ The SY7802 is a current-regulated charge pump which can regulate two current
+ levels for Flash and Torch modes.
+
+ The SY7802 is a high-current synchronous boost converter with 2-channel
+ high side current sources. Each channel is able to deliver 900mA current.
+
+properties:
+ compatible:
+ enum:
+ - silergy,sy7802
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+ description: A connection to the 'EN' pin.
+
+ flash-gpios:
+ maxItems: 1
+ description: A connection to the 'FLEN' pin.
+
+ vin-supply:
+ description: Regulator providing power to the 'VIN' pin.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-1]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: Index of the LED.
+ minimum: 0
+ maximum: 1
+
+ led-sources:
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 1
+
+ required:
+ - reg
+ - led-sources
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - enable-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash-led-controller@53 {
+ compatible = "silergy,sy7802";
+ reg = <0x53>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
+
+ led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <0>, <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml b/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml
new file mode 100644
index 000000000000..97535d6dc47a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/sprd,sc2731-bltc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC2731 PMIC breathing light controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ The SC2731 breathing light controller supports up to 3 outputs:
+ red LED, green LED and blue LED. Each LED can work at normal PWM mode
+ or breath light mode.
+
+properties:
+ compatible:
+ const: sprd,sc2731-bltc
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^led@[0-2]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 2
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+...
diff --git a/Documentation/devicetree/bindings/leds/st,led1202.yaml b/Documentation/devicetree/bindings/leds/st,led1202.yaml
new file mode 100644
index 000000000000..f1e5e4efaa3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/st,led1202.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/st,led1202.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST LED1202 LED controllers
+
+maintainers:
+ - Vicentiu Galanopulo <vicentiu.galanopulo@remote-tech.co.uk>
+
+description: |
+ The LED1202 is a 12-channel low quiescent current LED controller
+ programmable via I2C; The output current can be adjusted separately
+ for each channel by 8-bit analog and 12-bit digital dimming control.
+ Datasheet available at
+ https://www.st.com/en/power-management/led1202.html
+
+properties:
+ compatible:
+ const: st,led1202
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-9a-f]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 11
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@58 {
+ compatible = "st,led1202";
+ reg = <0x58>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_RED>;
+ function-enumerator = <1>;
+ };
+
+ led@1 {
+ reg = <0x1>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ function-enumerator = <2>;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_BLUE>;
+ function-enumerator = <3>;
+ };
+
+ led@3 {
+ reg = <0x3>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_RED>;
+ function-enumerator = <4>;
+ };
+
+ led@4 {
+ reg = <0x4>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ function-enumerator = <5>;
+ };
+
+ led@5 {
+ reg = <0x5>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_BLUE>;
+ function-enumerator = <6>;
+ };
+
+ led@6 {
+ reg = <0x6>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_RED>;
+ function-enumerator = <7>;
+ };
+
+ led@7 {
+ reg = <0x7>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ function-enumerator = <8>;
+ };
+
+ led@8 {
+ reg = <0x8>;
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_BLUE>;
+ function-enumerator = <9>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/leds/ti,lp8860.yaml b/Documentation/devicetree/bindings/leds/ti,lp8860.yaml
new file mode 100644
index 000000000000..0ee357b02661
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,lp8860.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,lp8860.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - lp8860 4-Channel LED Driver
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+
+description: |
+ The LP8860-Q1 is an high-efficiency LED driver with boost controller.
+ It has 4 high-precision current sinks that can be controlled by a PWM input
+ signal, a SPI/I2C master, or both.
+
+ For more product information please see the link below:
+ https://www.ti.com/product/lp8860-q1
+
+properties:
+ compatible:
+ const: ti,lp8860
+
+ reg:
+ maxItems: 1
+ description: I2C slave address
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO pin to enable (active high) / disable the device
+
+ vled-supply:
+ description: LED supply
+
+patternProperties:
+ "^led(@[0-3])?$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ Index of the LED.
+ maxItems: 1
+
+ function: true
+ color: true
+ label: true
+ linux,default-trigger: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@2d {
+ compatible = "ti,lp8860";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2d>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <&vbatt>;
+
+ led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_BACKLIGHT;
+ color = <LED_COLOR_ID_WHITE>;
+ linux,default-trigger = "backlight";
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/ti,tca6507.yaml b/Documentation/devicetree/bindings/leds/ti,tca6507.yaml
index 32c600387895..4b1575e4f180 100644
--- a/Documentation/devicetree/bindings/leds/ti,tca6507.yaml
+++ b/Documentation/devicetree/bindings/leds/ti,tca6507.yaml
@@ -38,8 +38,8 @@ properties:
patternProperties:
"^led@[0-6]$":
type: object
-
$ref: common.yaml#
+ unevaluatedProperties: false
properties:
reg:
@@ -87,7 +87,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/leds/ti,tlc59116.yaml b/Documentation/devicetree/bindings/leds/ti,tlc59116.yaml
new file mode 100644
index 000000000000..ce9713793908
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,tlc59116.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,tlc59116.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LEDs connected to tlc59116 or tlc59108
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+
+properties:
+ compatible:
+ enum:
+ - ti,tlc59108
+ - ti,tlc59116
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-9a-f]$":
+ type: object
+ $ref: common.yaml#
+ properties:
+ reg:
+ items:
+ minimum: 0
+ maximum: 15
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,tlc59108
+ then:
+ patternProperties:
+ "^led@[0-9a-f]$":
+ properties:
+ reg:
+ items:
+ maximum: 7
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@68 {
+ compatible = "ti,tlc59116";
+ reg = <0x68>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ label = "wrt1900ac:amber:wan";
+ };
+
+ led@2 {
+ reg = <0x2>;
+ label = "wrt1900ac:white:2g";
+ };
+
+ led@9 {
+ reg = <0x9>;
+ label = "wrt1900ac:green:alive";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/leds/ti,tps61310.yaml b/Documentation/devicetree/bindings/leds/ti,tps61310.yaml
new file mode 100644
index 000000000000..118f9c8bfdf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,tps61310.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,tps61310.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TPS6131X flash LED driver
+
+maintainers:
+ - Matthias Fend <matthias.fend@emfend.at>
+
+description: |
+ The TPS61310/TPS61311 is a flash LED driver with I2C interface.
+ Its power stage is capable of supplying a maximum total current of roughly 1500mA.
+ The TPS6131x provides three constant-current sinks, capable of sinking
+ up to 2 x 400mA (LED1 and LED3) and 800mA (LED2) in flash mode.
+ In torch mode, each sink (LED1, LED2, LED3) supports currents up to 175mA.
+ Since the three current sinks share most of the control components such as
+ flash timer, control logic, safety timer and the operating mode, they cannot
+ be used completely independently of each other. Therefore, only one LED is
+ supported, but the current sinks can be combined accordingly.
+
+ The data sheet can be found at:
+ https://www.ti.com/lit/ds/symlink/tps61310.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,tps61311
+ - const: ti,tps61310
+ - items:
+ - const: ti,tps61310
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO connected to NRESET pin
+
+ ti,valley-current-limit:
+ type: boolean
+ description:
+ Reduce the valley peak current limit from 1750mA to 1250mA (TPS61310) or
+ from 2480mA to 1800mA (TPS61311).
+
+ led:
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ led-sources:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [1, 2, 3]
+
+ led-max-microamp:
+ oneOf:
+ - minimum: 50000
+ maximum: 350000
+ multipleOf: 50000
+ - minimum: 25000
+ maximum: 525000
+ multipleOf: 25000
+
+ flash-max-microamp:
+ oneOf:
+ - minimum: 50000
+ maximum: 800000
+ multipleOf: 50000
+ - minimum: 25000
+ maximum: 1500000
+ multipleOf: 25000
+
+ flash-max-timeout-us:
+ enum: [ 5300, 10700, 16000, 21300, 26600, 32000, 37300, 68200, 71500,
+ 102200, 136300, 170400, 204500, 340800, 579300, 852000 ]
+
+ required:
+ - led-sources
+ - led-max-microamp
+ - flash-max-microamp
+ - flash-max-timeout-us
+
+required:
+ - compatible
+ - reg
+ - led
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@33 {
+ compatible = "ti,tps61311", "ti,tps61310";
+ reg = <0x33>;
+
+ reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+
+ led {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <2>, <3>;
+ led-max-microamp = <525000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <852000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/ti.lm36922.yaml b/Documentation/devicetree/bindings/leds/ti.lm36922.yaml
new file mode 100644
index 000000000000..8ffbc6b785a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti.lm36922.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti.lm36922.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - LM3692x Highly Efficient White LED Driver
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ The LM3692x is an ultra-compact, highly efficient,
+ white-LED driver designed for LCD display backlighting.
+
+ The main difference between the LM36922 and LM36923 is the number of
+ LED strings it supports. The LM36922 supports two strings while the LM36923
+ supports three strings.
+
+ For more product information please see the link below:
+ https://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
+
+properties:
+ compatible:
+ enum:
+ - ti,lm36922
+ - ti,lm36923
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ enable-gpios:
+ description: gpio pin to enable/disable the device.
+
+ vled-supply:
+ description: LED supply
+
+ ti,ovp-microvolt:
+ description: Overvoltage protection.
+ default: 29000000
+ enum: [17000000, 21000000, 25000000, 29000000]
+
+patternProperties:
+ '^led@[0-3]$':
+ type: object
+ $ref: common.yaml
+ properties:
+ reg:
+ enum: [0, 1, 2, 3]
+ description: |
+ 0 - Will enable all LED sync paths
+ 1 - Will enable the LED1 sync
+ 2 - Will enable the LED2 sync
+ 3 - Will enable the LED3 sync (LM36923 only)
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,lm36922
+ then:
+ properties:
+ led@3: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@36 {
+ compatible = "ti,lm36922";
+ reg = <0x36>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <&vbatt>;
+ ti,ovp-microvolt = <29000000>;
+
+ led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_BACKLIGHT;
+ color = <LED_COLOR_ID_WHITE>;
+ linux,default-trigger = "backlight";
+ led-max-microamp = <20000>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/loongarch/cpus.yaml b/Documentation/devicetree/bindings/loongarch/cpus.yaml
new file mode 100644
index 000000000000..f175872995e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/loongarch/cpus.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/loongarch/cpus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LoongArch CPUs
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+description:
+ This document describes the list of LoongArch CPU cores that support FDT,
+ it describe the layout of CPUs in a system through the "cpus" node.
+
+allOf:
+ - $ref: /schemas/cpu.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,la264
+ - loongson,la364
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls2k-clk.h>
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ cpu@0 {
+ compatible = "loongson,la264";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&clk LOONGSON2_NODE_CLK>;
+ };
+
+ cpu@1 {
+ compatible = "loongson,la264";
+ device_type = "cpu";
+ reg = <1>;
+ clocks = <&clk LOONGSON2_NODE_CLK>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/loongarch/loongson.yaml b/Documentation/devicetree/bindings/loongarch/loongson.yaml
new file mode 100644
index 000000000000..e1a4a97b7576
--- /dev/null
+++ b/Documentation/devicetree/bindings/loongarch/loongson.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/loongarch/loongson.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson SoC-based boards
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Loongson-2K0500 processor based boards
+ items:
+ - const: loongson,ls2k0500-ref
+ - const: loongson,ls2k0500
+
+ - description: Loongson-2K1000 processor based boards
+ items:
+ - const: loongson,ls2k1000-ref
+ - const: loongson,ls2k1000
+
+ - description: Loongson-2K2000 processor based boards
+ items:
+ - const: loongson,ls2k2000-ref
+ - const: loongson,ls2k2000
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/mailbox/allwinner,sun6i-a31-msgbox.yaml b/Documentation/devicetree/bindings/mailbox/allwinner,sun6i-a31-msgbox.yaml
index 75d5d97305e1..87d31963c1b7 100644
--- a/Documentation/devicetree/bindings/mailbox/allwinner,sun6i-a31-msgbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/allwinner,sun6i-a31-msgbox.yaml
@@ -68,13 +68,13 @@ examples:
#include <dt-bindings/reset/sun8i-h3-ccu.h>
msgbox: mailbox@1c17000 {
- compatible = "allwinner,sun8i-h3-msgbox",
- "allwinner,sun6i-a31-msgbox";
- reg = <0x01c17000 0x1000>;
- clocks = <&ccu CLK_BUS_MSGBOX>;
- resets = <&ccu RST_BUS_MSGBOX>;
- interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
- #mbox-cells = <1>;
+ compatible = "allwinner,sun8i-h3-msgbox",
+ "allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = <&ccu CLK_BUS_MSGBOX>;
+ resets = <&ccu RST_BUS_MSGBOX>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
index dfd26b998189..79963c9878ba 100644
--- a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson Message-Handling-Unit Controller
@@ -27,7 +27,7 @@ properties:
maxItems: 1
interrupts:
- minItems: 3
+ maxItems: 3
description:
Contains the interrupt information corresponding to each of the 3 links
of MHU.
@@ -46,8 +46,8 @@ additionalProperties: false
examples:
- |
mailbox@c883c404 {
- compatible = "amlogic,meson-gxbb-mhu";
- reg = <0xc883c404 0x4c>;
- interrupts = <208>, <209>, <210>;
- #mbox-cells = <1>;
+ compatible = "amlogic,meson-gxbb-mhu";
+ reg = <0xc883c404 0x4c>;
+ interrupts = <208>, <209>, <210>;
+ #mbox-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/mailbox/apm,xgene-slimpro-mbox.yaml b/Documentation/devicetree/bindings/mailbox/apm,xgene-slimpro-mbox.yaml
new file mode 100644
index 000000000000..815f08d61de8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/apm,xgene-slimpro-mbox.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/apm,xgene-slimpro-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SLIMpro mailbox
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+description:
+ The APM X-Gene SLIMpro mailbox is used to communicate messages between
+ the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
+ interrupt based door bell mechanism and can exchange simple messages using the
+ internal registers.
+
+properties:
+ compatible:
+ const: apm,xgene-slimpro-mbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: mailbox channel 0 doorbell
+ - description: mailbox channel 1 doorbell
+ - description: mailbox channel 2 doorbell
+ - description: mailbox channel 3 doorbell
+ - description: mailbox channel 4 doorbell
+ - description: mailbox channel 5 doorbell
+ - description: mailbox channel 6 doorbell
+ - description: mailbox channel 7 doorbell
+
+ '#mbox-cells':
+ description: Number of mailbox channel.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ mailbox@10540000 {
+ compatible = "apm,xgene-slimpro-mbox";
+ reg = <0x10540000 0xa000>;
+ #mbox-cells = <1>;
+ interrupts = <0x0 0x0 0x4>,
+ <0x0 0x1 0x4>,
+ <0x0 0x2 0x4>,
+ <0x0 0x3 0x4>,
+ <0x0 0x4 0x4>,
+ <0x0 0x5 0x4>,
+ <0x0 0x6 0x4>,
+ <0x0 0x7 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
index 5c5c328b3134..28985cc62c25 100644
--- a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml
@@ -29,16 +29,26 @@ properties:
items:
- enum:
- apple,t8103-asc-mailbox
+ - apple,t8112-asc-mailbox
- apple,t6000-asc-mailbox
+ - apple,t6020-asc-mailbox
- const: apple,asc-mailbox-v4
- description:
+ An older ASC mailbox interface found on T2 and A11 that is also
+ used for the NVMe coprocessor and the system management
+ controller.
+ items:
+ - const: apple,t8015-asc-mailbox
+
+ - description:
M3 mailboxes are an older variant with a slightly different MMIO
interface still found on the M1. It is used for the Thunderbolt
co-processors.
items:
- enum:
- apple,t8103-m3-mailbox
+ - apple,t8112-m3-mailbox
- apple,t6000-m3-mailbox
- const: apple,m3-mailbox-v2
@@ -76,11 +86,11 @@ additionalProperties: false
examples:
- |
- mailbox@77408000 {
- compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox-v4";
- reg = <0x77408000 0x4000>;
- interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>;
- interrupt-names = "send-empty", "send-not-empty",
- "recv-empty", "recv-not-empty";
- #mbox-cells = <0>;
- };
+ mailbox@77408000 {
+ compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox-v4";
+ reg = <0x77408000 0x4000>;
+ interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>;
+ interrupt-names = "send-empty", "send-not-empty",
+ "recv-empty", "recv-not-empty";
+ #mbox-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
index d9a4f4a02d7c..e45b661e8b41 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
@@ -52,7 +52,6 @@ properties:
- const: arm,mhu-doorbell
- const: arm,primecell
-
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
index a4f1fe63659a..3828d77f6316 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
@@ -127,7 +127,6 @@ properties:
- minimum: 0
maximum: 124
-
'#mbox-cells':
description: |
It is always set to 2. The first argument in the consumers 'mboxes'
@@ -197,7 +196,7 @@ examples:
reg = <0 0x596e8000 0 0x88000>;
clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>;
clock-names = "ipg", "ocram", "core";
- power-domains = <&pd 0>, <&pd 1>, <&pd 2>, <&pd 3>;
+ power-domains = <&pd 0>, <&pd 1>;
mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx
<&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
new file mode 100644
index 000000000000..449b55afeb7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
@@ -0,0 +1,224 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm,mhuv3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM MHUv3 Mailbox Controller
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+ - Cristian Marussi <cristian.marussi@arm.com>
+
+description: |
+ The Arm Message Handling Unit (MHU) Version 3 is a mailbox controller that
+ enables unidirectional communications with remote processors through various
+ possible transport protocols.
+ The controller can optionally support a varying number of extensions that, in
+ turn, enable different kinds of transport to be used for communication.
+ Number, type and characteristics of each supported extension can be discovered
+ dynamically at runtime.
+
+ Given the unidirectional nature of the controller, an MHUv3 mailbox controller
+ is composed of a MHU Sender (MHUS) containing a PostBox (PBX) block and a MHU
+ Receiver (MHUR) containing a MailBox (MBX) block, where
+
+ PBX is used to
+ - Configure the MHU
+ - Send Transfers to the Receiver
+ - Optionally receive acknowledgment of a Transfer from the Receiver
+
+ MBX is used to
+ - Configure the MHU
+ - Receive Transfers from the Sender
+ - Optionally acknowledge Transfers sent by the Sender
+
+ Both PBX and MBX need to be present and defined in the DT description if you
+ need to establish a bidirectional communication, since you will have to
+ acquire two distinct unidirectional channels, one for each block.
+
+ As a consequence both blocks needs to be represented separately and specified
+ as distinct DT nodes in order to properly describe their resources.
+
+ Note that, though, thanks to the runtime discoverability, there is no need to
+ identify the type of blocks with distinct compatibles.
+
+ Following are the MHUv3 possible extensions.
+
+ - Doorbell Extension (DBE): DBE defines a type of channel called a Doorbell
+ Channel (DBCH). DBCH enables a single bit Transfer to be sent from the
+ Sender to Receiver. The Transfer indicates that an event has occurred.
+ When DBE is implemented, the number of DBCHs that an implementation of the
+ MHU can support is between 1 and 128, numbered starting from 0 in ascending
+ order and discoverable at run-time.
+ Each DBCH contains 32 individual fields, referred to as flags, each of which
+ can be used independently. It is possible for the Sender to send multiple
+ Transfers at once using a single DBCH, so long as each Transfer uses
+ a different flag in the DBCH.
+ Optionally, data may be transmitted through an out-of-band shared memory
+ region, wherein the MHU Doorbell is used strictly as an interrupt generation
+ mechanism, but this is out of the scope of these bindings.
+
+ - FastChannel Extension (FCE): FCE defines a type of channel called a Fast
+ Channel (FCH). FCH is intended for lower overhead communication between
+ Sender and Receiver at the expense of determinism. An FCH allows the Sender
+ to update the channel value at any time, regardless of whether the previous
+ value has been seen by the Receiver. When the Receiver reads the channel's
+ content it gets the last value written to the channel.
+ FCH is considered lossy in nature, and means that the Sender has no way of
+ knowing if, or when, the Receiver will act on the Transfer.
+ FCHs are expected to behave as RAM which generates interrupts when writes
+ occur to the locations within the RAM.
+ When FCE is implemented, the number of FCHs that an implementation of the
+ MHU can support is between 1-1024, if the FastChannel word-size is 32-bits,
+ or between 1-512, when the FastChannel word-size is 64-bits.
+ FCHs are numbered from 0 in ascending order.
+ Note that the number of FCHs and the word-size are implementation defined,
+ not configurable but discoverable at run-time.
+ Optionally, data may be transmitted through an out-of-band shared memory
+ region, wherein the MHU FastChannel is used as an interrupt generation
+ mechanism which carries also a pointer to such out-of-band data, but this
+ is out of the scope of these bindings.
+
+ - FIFO Extension (FE): FE defines a Channel type called a FIFO Channel (FFCH).
+ FFCH allows a Sender to send
+ - Multiple Transfers to the Receiver without having to wait for the
+ previous Transfer to be acknowledged by the Receiver, as long as the
+ FIFO has room for the Transfer.
+ - Transfers which require the Receiver to provide acknowledgment.
+ - Transfers which have in-band payload.
+ In all cases, the data is guaranteed to be observed by the Receiver in the
+ same order which the Sender sent it.
+ When FE is implemented, the number of FFCHs that an implementation of the
+ MHU can support is between 1 and 64, numbered starting from 0 in ascending
+ order. The number of FFCHs, their depth (same for all implemented FFCHs) and
+ the access-granularity are implementation defined, not configurable but
+ discoverable at run-time.
+ Optionally, additional data may be transmitted through an out-of-band shared
+ memory region, wherein the MHU FIFO is used to transmit, in order, a small
+ part of the payload (like a header) and a reference to the shared memory
+ area holding the remaining, bigger, chunk of the payload, but this is out of
+ the scope of these bindings.
+
+properties:
+ compatible:
+ const: arm,mhuv3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 74
+
+ interrupt-names:
+ description: |
+ The MHUv3 controller generates a number of events some of which are used
+ to generate interrupts; as a consequence it can expose a varying number of
+ optional PBX/MBX interrupts, representing the events generated during the
+ operation of the various transport protocols associated with different
+ extensions. All interrupts of the MHU are level-sensitive.
+ Some of these optional interrupts are defined per-channel, where the
+ number of channels effectively available is implementation defined and
+ run-time discoverable.
+ In the following names are enumerated using patterns, with per-channel
+ interrupts implicitly capped at the maximum channels allowed by the
+ specification for each extension type.
+ For the sake of simplicity maxItems is anyway capped to a most plausible
+ number, assuming way less channels would be implemented than actually
+ possible.
+
+ The only mandatory interrupts on the MHU are:
+ - combined
+ - mbx-fch-xfer-<N> but only if mbx-fcgrp-xfer-<N> is not implemented.
+
+ minItems: 1
+ maxItems: 74
+ items:
+ oneOf:
+ - const: combined
+ description: PBX/MBX Combined interrupt
+ - const: combined-ffch
+ description: PBX/MBX FIFO Combined interrupt
+ - pattern: '^ffch-low-tide-[0-9]+$'
+ description: PBX/MBX FIFO Channel <N> Low Tide interrupt
+ - pattern: '^ffch-high-tide-[0-9]+$'
+ description: PBX/MBX FIFO Channel <N> High Tide interrupt
+ - pattern: '^ffch-flush-[0-9]+$'
+ description: PBX/MBX FIFO Channel <N> Flush interrupt
+ - pattern: '^mbx-dbch-xfer-[0-9]+$'
+ description: MBX Doorbell Channel <N> Transfer interrupt
+ - pattern: '^mbx-fch-xfer-[0-9]+$'
+ description: MBX FastChannel <N> Transfer interrupt
+ - pattern: '^mbx-fchgrp-xfer-[0-9]+$'
+ description: MBX FastChannel <N> Group Transfer interrupt
+ - pattern: '^mbx-ffch-xfer-[0-9]+$'
+ description: MBX FIFO Channel <N> Transfer interrupt
+ - pattern: '^pbx-dbch-xfer-ack-[0-9]+$'
+ description: PBX Doorbell Channel <N> Transfer Ack interrupt
+ - pattern: '^pbx-ffch-xfer-ack-[0-9]+$'
+ description: PBX FIFO Channel <N> Transfer Ack interrupt
+
+ '#mbox-cells':
+ description: |
+ The first argument in the consumers 'mboxes' property represents the
+ extension type, the second is for the channel number while the third
+ depends on extension type.
+
+ Extension types constants are defined in <dt-bindings/arm/mhuv3-dt.h>.
+
+ Extension type for DBE is DBE_EXT and the third parameter represents the
+ doorbell flag number to use.
+ Extension type for FCE is FCE_EXT, third parameter unused.
+ Extension type for FE is FE_EXT, third parameter unused.
+
+ mboxes = <&mhu DBE_EXT 0 5>; // DBE, Doorbell Channel Window 0, doorbell 5.
+ mboxes = <&mhu DBE_EXT 7>; // DBE, Doorbell Channel Window 1, doorbell 7.
+ mboxes = <&mhu FCE_EXT 0 0>; // FCE, FastChannel Window 0.
+ mboxes = <&mhu FCE_EXT 3 0>; // FCE, FastChannel Window 3.
+ mboxes = <&mhu FE_EXT 1 0>; // FE, FIFO Channel Window 1.
+ mboxes = <&mhu FE_EXT 7 0>; // FE, FIFO Channel Window 7.
+ const: 3
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mailbox@2aaa0000 {
+ compatible = "arm,mhuv3";
+ #mbox-cells = <3>;
+ reg = <0 0x2aaa0000 0 0x10000>;
+ clocks = <&clock 0>;
+ interrupt-names = "combined", "pbx-dbch-xfer-ack-1",
+ "ffch-high-tide-0";
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ mailbox@2ab00000 {
+ compatible = "arm,mhuv3";
+ #mbox-cells = <3>;
+ reg = <0 0x2aab0000 0 0x10000>;
+ clocks = <&clock 0>;
+ interrupt-names = "combined", "mbx-dbch-xfer-1", "ffch-low-tide-0";
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/aspeed,ast2700-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/aspeed,ast2700-mailbox.yaml
new file mode 100644
index 000000000000..600e2d63fccd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/aspeed,ast2700-mailbox.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/aspeed,ast2700-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2700 mailbox controller
+
+maintainers:
+ - Jammy Huang <jammy_huang@aspeedtech.com>
+
+description: >
+ ASPEED AST2700 has multiple processors that need to communicate with each
+ other. The mailbox controller provides a way for these processors to send
+ messages to each other. It is a hardware-based inter-processor communication
+ mechanism that allows processors to send and receive messages through
+ dedicated channels.
+
+ The mailbox's tx/rx are independent, meaning that one processor can send a
+ message while another processor is receiving a message simultaneously.
+ There are 4 channels available for both tx and rx operations. Each channel
+ has a FIFO buffer that can hold messages of a fixed size (32 bytes in this
+ case).
+
+ The mailbox controller also supports interrupt generation, allowing
+ processors to notify each other when a message is available or when an event
+ occurs.
+
+properties:
+ compatible:
+ const: aspeed,ast2700-mailbox
+
+ reg:
+ items:
+ - description: TX control register
+ - description: RX control register
+
+ reg-names:
+ items:
+ - const: tx
+ - const: rx
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@12c1c200 {
+ compatible = "aspeed,ast2700-mailbox";
+ reg = <0x12c1c200 0x100>, <0x12c1c300 0x100>;
+ reg-names = "tx", "rx";
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
deleted file mode 100644
index b48d7d30012c..000000000000
--- a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Broadcom BCM2835 VideoCore mailbox IPC
-
-Required properties:
-
-- compatible: Should be "brcm,bcm2835-mbox"
-- reg: Specifies base physical address and size of the registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-- #mbox-cells: Specifies the number of cells needed to encode a mailbox
- channel. The value shall be 0, since there is only one
- mailbox channel implemented by the device.
-
-Example:
-
-mailbox: mailbox@7e00b880 {
- compatible = "brcm,bcm2835-mbox";
- reg = <0x7e00b880 0x40>;
- interrupts = <0 1>;
- #mbox-cells = <0>;
-};
-
-firmware: firmware {
- compatible = "raspberrypi,firmware";
- mboxes = <&mailbox>;
- #power-domain-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml
new file mode 100644
index 000000000000..9588817f4511
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/brcm,bcm2835-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 VideoCore mailbox IPC
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-mbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ mailbox@7e00b880 {
+ compatible = "brcm,bcm2835-mbox";
+ reg = <0x7e00b880 0x40>;
+ interrupts = <0 1>;
+ #mbox-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml
new file mode 100644
index 000000000000..750cc96edb46
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm74110-mbox.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/brcm,bcm74110-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM74110 Mailbox
+
+maintainers:
+ - Justin Chen <justin.chen@broadcom.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+description: Broadcom mailbox hardware first introduced with 74110
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm74110-mbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: RX doorbell and watermark interrupts
+ - description: TX doorbell and watermark interrupts
+
+ "#mbox-cells":
+ const: 2
+ description:
+ The first cell is channel type and second cell is shared memory slot
+
+ brcm,rx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: RX Mailbox number
+
+ brcm,tx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TX Mailbox number
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+ - brcm,rx
+ - brcm,tx
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@a552000 {
+ compatible = "brcm,bcm74110-mbox";
+ reg = <0xa552000 0x1104>;
+ interrupts = <GIC_SPI 0x67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 0x66 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <0x2>;
+ brcm,rx = <0x7>;
+ brcm,tx = <0x6>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
deleted file mode 100644
index 752ae6b00d26..000000000000
--- a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Broadcom FlexRM Ring Manager
-============================
-The Broadcom FlexRM ring manager provides a set of rings which can be
-used to submit work to offload engines. An SoC may have multiple FlexRM
-hardware blocks. There is one device tree entry per FlexRM block. The
-FlexRM driver will create a mailbox-controller instance for given FlexRM
-hardware block where each mailbox channel is a separate FlexRM ring.
-
-Required properties:
---------------------
-- compatible: Should be "brcm,iproc-flexrm-mbox"
-- reg: Specifies base physical address and size of the FlexRM
- ring registers
-- msi-parent: Phandles (and potential Device IDs) to MSI controllers
- The FlexRM engine will send MSIs (instead of wired
- interrupts) to CPU. There is one MSI for each FlexRM ring.
- Refer devicetree/bindings/interrupt-controller/msi.txt
-- #mbox-cells: Specifies the number of cells needed to encode a mailbox
- channel. This should be 3.
-
- The 1st cell is the mailbox channel number.
-
- The 2nd cell contains MSI completion threshold. This is the
- number of completion messages for which FlexRM will inject
- one MSI interrupt to CPU.
-
- The 3nd cell contains MSI timer value representing time for
- which FlexRM will wait to accumulate N completion messages
- where N is the value specified by 2nd cell above. If FlexRM
- does not get required number of completion messages in time
- specified by this cell then it will inject one MSI interrupt
- to CPU provided atleast one completion message is available.
-
-Optional properties:
---------------------
-- dma-coherent: Present if DMA operations made by the FlexRM engine (such
- as DMA descriptor access, access to buffers pointed by DMA
- descriptors and read/write pointer updates to DDR) are
- cache coherent with the CPU.
-
-Example:
---------
-crypto_mbox: mbox@67000000 {
- compatible = "brcm,iproc-flexrm-mbox";
- reg = <0x67000000 0x200000>;
- msi-parent = <&gic_its 0x7f00>;
- #mbox-cells = <3>;
-};
-
-crypto@672c0000 {
- compatible = "brcm,spu2-v2-crypto";
- reg = <0x672c0000 0x1000>;
- mboxes = <&crypto_mbox 0 0x1 0xffff>,
- <&crypto_mbox 1 0x1 0xffff>,
- <&crypto_mbox 16 0x1 0xffff>,
- <&crypto_mbox 17 0x1 0xffff>,
- <&crypto_mbox 30 0x1 0xffff>,
- <&crypto_mbox 31 0x1 0xffff>;
-};
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.yaml
new file mode 100644
index 000000000000..c801bd2e95f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/brcm,iproc-flexrm-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom FlexRM Ring Manager
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+description:
+ The Broadcom FlexRM ring manager provides a set of rings which can be used to
+ submit work to offload engines. An SoC may have multiple FlexRM hardware
+ blocks. There is one device tree entry per FlexRM block. The FlexRM driver
+ will create a mailbox-controller instance for given FlexRM hardware block
+ where each mailbox channel is a separate FlexRM ring.
+
+properties:
+ compatible:
+ const: brcm,iproc-flexrm-mbox
+
+ reg:
+ maxItems: 1
+
+ msi-parent:
+ maxItems: 1
+
+ '#mbox-cells':
+ description: >
+ The 1st cell is the mailbox channel number.
+
+ The 2nd cell contains MSI completion threshold. This is the number of
+ completion messages for which FlexRM will inject one MSI interrupt to CPU.
+
+ The 3rd cell contains MSI timer value representing time for which FlexRM
+ will wait to accumulate N completion messages where N is the value
+ specified by 2nd cell above. If FlexRM does not get required number of
+ completion messages in time specified by this cell then it will inject one
+ MSI interrupt to CPU provided at least one completion message is
+ available.
+ const: 3
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - msi-parent
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ mailbox@67000000 {
+ compatible = "brcm,iproc-flexrm-mbox";
+ reg = <0x67000000 0x200000>;
+ msi-parent = <&gic_its 0x7f00>;
+ #mbox-cells = <3>;
+ dma-coherent;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt
deleted file mode 100644
index 9bcdf2087625..000000000000
--- a/Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-The PDC driver manages data transfer to and from various offload engines
-on some Broadcom SoCs. An SoC may have multiple PDC hardware blocks. There is
-one device tree entry per block. On some chips, the PDC functionality is
-handled by the FA2 (Northstar Plus).
-
-Required properties:
-- compatible : Should be "brcm,iproc-pdc-mbox" or "brcm,iproc-fa2-mbox" for
- FA2/Northstar Plus.
-- reg: Should contain PDC registers location and length.
-- interrupts: Should contain the IRQ line for the PDC.
-- #mbox-cells: 1
-- brcm,rx-status-len: Length of metadata preceding received frames, in bytes.
-
-Optional properties:
-- brcm,use-bcm-hdr: present if a BCM header precedes each frame.
-
-Example:
- pdc0: iproc-pdc0@612c0000 {
- compatible = "brcm,iproc-pdc-mbox";
- reg = <0 0x612c0000 0 0x445>; /* PDC FS0 regs */
- interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
- #mbox-cells = <1>; /* one cell per mailbox channel */
- brcm,rx-status-len = <32>;
- brcm,use-bcm-hdr;
- };
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.yaml b/Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.yaml
new file mode 100644
index 000000000000..5534ae07c9fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/brcm,iproc-pdc-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom iProc PDC mailbox
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+description:
+ The PDC driver manages data transfer to and from various offload engines on
+ some Broadcom SoCs. An SoC may have multiple PDC hardware blocks. There is one
+ device tree entry per block. On some chips, the PDC functionality is handled
+ by the FA2 (Northstar Plus).
+
+properties:
+ compatible:
+ enum:
+ - brcm,iproc-pdc-mbox
+ - brcm,iproc-fa2-mbox
+
+ reg:
+ maxItems: 1
+
+ dma-coherent: true
+
+ interrupts:
+ maxItems: 1
+
+ '#mbox-cells':
+ const: 1
+
+ brcm,rx-status-len:
+ description:
+ Length of metadata preceding received frames, in bytes.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ brcm,use-bcm-hdr:
+ type: boolean
+ description:
+ Present if a BCM header precedes each frame.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#mbox-cells'
+ - brcm,rx-status-len
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox0@612c0000 {
+ compatible = "brcm,iproc-pdc-mbox";
+ reg = <0x612c0000 0x445>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ brcm,rx-status-len = <32>;
+ brcm,use-bcm-hdr;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/cix,sky1-mbox.yaml b/Documentation/devicetree/bindings/mailbox/cix,sky1-mbox.yaml
new file mode 100644
index 000000000000..66d75b7bc8c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/cix,sky1-mbox.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/cix,sky1-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cixtech mailbox controller
+
+maintainers:
+ - Guomin Chen <Guomin.Chen@cixtech.com>
+
+description:
+ The Cixtech mailbox controller, used in the Cixtech Sky1 SoC,
+ is used for message transmission between multiple processors
+ within the SoC, such as the AP, PM, audio DSP, SensorHub MCU,
+ and others
+
+ Each Cixtech mailbox controller is unidirectional, so they are
+ typically used in pairs-one for receiving and one for transmitting.
+
+ Each Cixtech mailbox supports 11 channels with different transmission modes
+ channel 0-7 - Fast channel with 32bit transmit register and IRQ support
+ channel 8 - Doorbell mode,using the mailbox as an interrupt-generating
+ mechanism.
+ channel 9 - Fifo based channel with 32*32bit depth fifo and IRQ support
+ channel 10 - Reg based channel with 32*32bit transmit register and
+ Doorbell+transmit acknowledgment IRQ support
+
+ In the CIX Sky1 SoC use case, there are 4 pairs of mailbox controllers
+ AP <--> PM - using Doorbell transfer mode
+ AP <--> SE - using REG transfer mode
+ AP <--> DSP - using FIFO transfer mode
+ AP <--> SensorHub - using FIFO transfer mode
+
+properties:
+ compatible:
+ const: cix,sky1-mbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 1
+
+ cix,mbox-dir:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Direction of the mailbox relative to the AP
+ enum: [tx, rx]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+ - cix,mbox-dir
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mbox_ap2pm: mailbox@30000000 {
+ compatible = "cix,sky1-mbox";
+ reg = <0 0x30000000 0 0x10000>;
+ interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH 0>;
+ #mbox-cells = <1>;
+ cix,mbox-dir = "tx";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
index 191c1ce15009..581425aacdcc 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
@@ -29,8 +29,11 @@ properties:
- const: fsl,imx8ulp-mu
- const: fsl,imx8-mu-scu
- const: fsl,imx8-mu-seco
- - const: fsl,imx93-mu-s4
- const: fsl,imx8ulp-mu-s4
+ - const: fsl,imx93-mu-s4
+ - const: fsl,imx95-mu
+ - const: fsl,imx95-mu-ele
+ - const: fsl,imx95-mu-v2x
- items:
- const: fsl,imx93-mu
- const: fsl,imx8ulp-mu
@@ -51,6 +54,10 @@ properties:
- fsl,imx8qm-mu
- fsl,imx8qxp-mu
- const: fsl,imx6sx-mu
+ - items:
+ - enum:
+ - fsl,imx94-mu
+ - const: fsl,imx95-mu
reg:
maxItems: 1
@@ -72,9 +79,9 @@ properties:
type : Channel type
channel : Channel number
- This MU support 5 type of unidirectional channels, each type
+ This MU support 6 type of unidirectional channels, each type
has 4 channels except RST channel which only has 1 channel.
- A total of 17 channels. Following types are
+ A total of 21 channels. Following types are
supported:
0 - TX channel with 32bit transmit register and IRQ transmit
acknowledgment support.
@@ -82,6 +89,7 @@ properties:
2 - TX doorbell channel. Without own register and no ACK support.
3 - RX doorbell channel.
4 - RST channel
+ 5 - Tx doorbell channel. With S/W ACK from the other side.
const: 2
clocks:
@@ -94,6 +102,19 @@ properties:
power-domains:
maxItems: 1
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+patternProperties:
+ "^sram@[a-f0-9]+":
+ $ref: /schemas/sram/sram.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -121,6 +142,16 @@ allOf:
required:
- interrupt-names
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx95-mu
+ then:
+ patternProperties:
+ "^sram@[a-f0-9]+": false
+
additionalProperties: false
examples:
@@ -133,3 +164,34 @@ examples:
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
#mbox-cells = <2>;
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@445b0000 {
+ compatible = "fsl,imx95-mu";
+ reg = <0x445b0000 0x10000>;
+ ranges;
+ interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #mbox-cells = <2>;
+
+ sram@445b1000 {
+ compatible = "mmio-sram";
+ reg = <0x445b1000 0x400>;
+ ranges = <0x0 0x445b1000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ scmi-sram-section@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x80>;
+ };
+
+ scmi-sram-section@80 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x80 0x80>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml b/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
new file mode 100644
index 000000000000..e249db4c1fbc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2024 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/google,gs101-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos Mailbox Controller
+
+maintainers:
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
+
+description:
+ The Samsung Exynos mailbox controller, used on Google GS101 SoC, has 16 flag
+ bits for hardware interrupt generation and a shared register for passing
+ mailbox messages. When the controller is used by the ACPM interface
+ the shared register is ignored and the mailbox controller acts as a doorbell.
+ The controller just raises the interrupt to the firmware after the
+ ACPM interface has written the message to SRAM.
+
+properties:
+ compatible:
+ const: google,gs101-mbox
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pclk
+
+ interrupts:
+ description: IRQ line for the RX mailbox.
+ maxItems: 1
+
+ '#mbox-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/google,gs101.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ap2apm_mailbox: mailbox@17610000 {
+ compatible = "google,gs101-mbox";
+ reg = <0x17610000 0x1000>;
+ clocks = <&cmu_apm CLK_GOUT_APM_MAILBOX_APM_AP_PCLK>;
+ clock-names = "pclk";
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH 0>;
+ #mbox-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
deleted file mode 100644
index 282ab81a4ea6..000000000000
--- a/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* rWTM BIU Mailbox driver for Armada 37xx
-
-Required properties:
-- compatible: must be "marvell,armada-3700-rwtm-mailbox"
-- reg: physical base address of the mailbox and length of memory mapped
- region
-- interrupts: the IRQ line for the mailbox
-- #mbox-cells: must be 1
-
-Example:
- rwtm: mailbox@b0000 {
- compatible = "marvell,armada-3700-rwtm-mailbox";
- reg = <0xb0000 0x100>;
- interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
- #mbox-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.yaml
new file mode 100644
index 000000000000..0a07ed1b1beb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/marvell,armada-3700-rwtm-mailbox.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/marvell,armada-3700-rwtm-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 3700 rWTM Mailbox
+
+maintainers:
+ - Marek Behún <kabel@kernel.org>
+
+properties:
+ compatible:
+ const: marvell,armada-3700-rwtm-mailbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#mbox-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@b0000 {
+ compatible = "marvell,armada-3700-rwtm-mailbox";
+ reg = <0xb0000 0x100>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
new file mode 100644
index 000000000000..587126d03fc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/mediatek,gce-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Global Command Engine Mailbox
+
+maintainers:
+ - Houlong Wei <houlong.wei@mediatek.com>
+
+description:
+ The Global Command Engine (GCE) is used to help read/write registers with
+ critical time limitation, such as updating display configuration during the
+ vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt6779-gce
+ - mediatek,mt8173-gce
+ - mediatek,mt8183-gce
+ - mediatek,mt8186-gce
+ - mediatek,mt8188-gce
+ - mediatek,mt8192-gce
+ - mediatek,mt8195-gce
+ - mediatek,mt8196-gce
+ - items:
+ - const: mediatek,mt6795-gce
+ - const: mediatek,mt8173-gce
+
+ "#mbox-cells":
+ const: 2
+ description:
+ The first cell describes the Thread ID of the GCE,
+ the second cell describes the priority of the GCE thread
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Global Command Engine clock
+
+ clock-names:
+ items:
+ - const: gce
+
+ iommus:
+ maxItems: 1
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ gce: mailbox@10212000 {
+ compatible = "mediatek,mt8173-gce";
+ reg = <0 0x10212000 0 0x1000>;
+ interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
+ #mbox-cells = <2>;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml
new file mode 100644
index 000000000000..c25eed4606fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/mediatek,gce-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Global Command Engine Common Properties
+
+maintainers:
+ - Houlong Wei <houlong.wei@mediatek.com>
+
+description:
+ The Global Command Engine (GCE) is an instruction based, multi-threaded,
+ single-core command dispatcher for MediaTek hardware. The Command Queue
+ (CMDQ) mailbox driver is a driver for GCE, implemented using the Linux
+ mailbox framework. It is used to receive messages from mailbox consumers
+ and configure GCE to execute the specified instruction set in the message.
+ We use mediatek,gce-mailbox.yaml to define the properties for CMDQ mailbox
+ driver. A device driver that uses the CMDQ driver to configure its hardware
+ registers is a mailbox consumer. The mailbox consumer can request a mailbox
+ channel corresponding to a GCE hardware thread to send a message, specifying
+ that the GCE thread to configure its hardware. The mailbox provider can also
+ reserve a mailbox channel to configure GCE hardware register by the specific
+ GCE thread. This binding defines the common GCE properties for both mailbox
+ provider and consumers.
+
+properties:
+ mediatek,gce-events:
+ description:
+ GCE has an event table in SRAM, consisting of 1024 event IDs (0~1023).
+ Each event ID has a boolean event value with the default value 0.
+ The property mediatek,gce-events is used to obtain the event IDs.
+ Some gce-events are hardware-bound and cannot be changed by software.
+ For instance, in MT8195, when VDO0_MUTEX is stream done, VDO_MUTEX will
+ send an event signal to GCE, setting the value of event ID 597 to 1.
+ Similarly, in MT8188, the value of event ID 574 will be set to 1 when
+ VOD0_MUTEX is stream done.
+ On the other hand, some gce-events are not hardware-bound and can be
+ changed by software. For example, in MT8188, we can set the value of
+ event ID 855, which is not bound to any hardware, to 1 when the driver
+ in the secure world completes a task. However, in MT8195, event ID 855
+ is already bound to VDEC_LAT1, so we need to select another event ID to
+ achieve the same purpose. This event ID can be any ID that is not bound
+ to any hardware and is not yet used in any software driver.
+ To determine if the event ID is bound to the hardware or used by a
+ software driver, refer to the GCE header
+ include/dt-bindings/gce/<chip>-gce.h of each chip.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 32
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml
new file mode 100644
index 000000000000..ab5b780cb83a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,mt8196-gpueb-mbox.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/mediatek,mt8196-gpueb-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MFlexGraphics GPUEB Mailbox Controller
+
+maintainers:
+ - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8196-gpueb-mbox
+
+ reg:
+ items:
+ - description: mailbox data registers
+ - description: mailbox control registers
+
+ reg-names:
+ items:
+ - const: data
+ - const: ctl
+
+ clocks:
+ items:
+ - description: main clock of the GPUEB MCU
+
+ interrupts:
+ items:
+ - description: fires when a new message is received
+
+ "#mbox-cells":
+ const: 1
+ description:
+ The number of the mailbox channel.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mediatek,mt8196-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mailbox@4b09fd80 {
+ compatible = "mediatek,mt8196-gpueb-mbox";
+ reg = <0x4b09fd80 0x280>,
+ <0x4b170000 0x7c>;
+ reg-names = "data", "ctl";
+ clocks = <&topckgen CLK_TOP_MFG_EB>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH 0>;
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml
index 082d397d3e89..1332aab9a888 100644
--- a/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller
@@ -14,9 +14,18 @@ properties:
const: microchip,mpfs-mailbox
reg:
- items:
- - description: mailbox data registers
- - description: mailbox interrupt registers
+ oneOf:
+ - items:
+ - description: mailbox data registers
+ - items:
+ - description: mailbox control & data registers
+ - description: mailbox interrupt registers
+ deprecated: true
+ - items:
+ - description: mailbox control registers
+ - description: mailbox interrupt registers
+ - description: mailbox data registers
+ deprecated: true
interrupts:
maxItems: 1
@@ -35,11 +44,12 @@ additionalProperties: false
examples:
- |
soc {
- #address-cells = <2>;
- #size-cells = <2>;
- mbox: mailbox@37020000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mailbox@37020800 {
compatible = "microchip,mpfs-mailbox";
- reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>;
+ reg = <0x37020800 0x100>;
interrupt-parent = <&L1>;
interrupts = <96>;
#mbox-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
new file mode 100644
index 000000000000..8ed67ea7c883
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/microchip,sbi-ipc.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/microchip,sbi-ipc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Inter-processor communication (IPC) mailbox controller
+
+maintainers:
+ - Valentina Fernandez <valentina.fernandezalanis@microchip.com>
+
+description:
+ The Microchip Inter-processor Communication (IPC) facilitates
+ message passing between processors using an interrupt signaling
+ mechanism.
+
+properties:
+ compatible:
+ oneOf:
+ - description:
+ Intended for use by software running in supervisor privileged
+ mode (s-mode). This SBI interface is compatible with the Mi-V
+ Inter-hart Communication (IHC) IP.
+ const: microchip,sbi-ipc
+
+ - description:
+ Intended for use by the SBI implementation in machine mode
+ (m-mode), this compatible string is for the MIV_IHC Soft-IP.
+ const: microchip,miv-ihc-rtl-v2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 5
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 5
+ items:
+ enum:
+ - hart-0
+ - hart-1
+ - hart-2
+ - hart-3
+ - hart-4
+ - hart-5
+
+ "#mbox-cells":
+ description: >
+ For "microchip,sbi-ipc", the cell represents the global "logical"
+ channel IDs. The meaning of channel IDs are platform firmware dependent.
+
+ For "microchip,miv-ihc-rtl-v2", the cell represents the physical
+ channel and does not vary based on the platform firmware.
+ const: 1
+
+ microchip,ihc-chan-disabled-mask:
+ description: >
+ Represents the enable/disable state of the bi-directional IHC
+ channels within the MIV-IHC IP configuration.
+
+ A bit set to '1' indicates that the corresponding channel is disabled,
+ and any read or write operations to that channel will return zero.
+
+ A bit set to '0' indicates that the corresponding channel is enabled
+ and will be accessible through its dedicated address range registers.
+
+ The actual enable/disable state of each channel is determined by the
+ IP block’s configuration.
+ $ref: /schemas/types.yaml#/definitions/uint16
+ maximum: 0x7fff
+ default: 0
+
+required:
+ - compatible
+ - interrupts
+ - interrupt-names
+ - "#mbox-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,sbi-ipc
+ then:
+ properties:
+ reg:
+ not: {}
+ description:
+ The 'microchip,sbi-ipc' operates in a programming model
+ that does not require memory-mapped I/O (MMIO) registers
+ since it uses SBI ecalls provided by the m-mode/firmware
+ SBI implementation to access hardware registers.
+ microchip,ihc-chan-disabled-mask: false
+ else:
+ required:
+ - reg
+ - microchip,ihc-chan-disabled-mask
+
+additionalProperties: false
+
+examples:
+ - |
+ mailbox {
+ compatible = "microchip,sbi-ipc";
+ interrupt-parent = <&plic>;
+ interrupts = <180>, <179>, <178>;
+ interrupt-names = "hart-1", "hart-2", "hart-3";
+ #mbox-cells = <1>;
+ };
+ - |
+ mailbox@50000000 {
+ compatible = "microchip,miv-ihc-rtl-v2";
+ microchip,ihc-chan-disabled-mask = /bits/ 16 <0>;
+ reg = <0x50000000 0x1c000>;
+ interrupt-parent = <&plic>;
+ interrupts = <180>, <179>, <178>;
+ interrupt-names = "hart-1", "hart-2", "hart-3";
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml
index 72c1d9e82c89..4ca0d5e49c79 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml
@@ -17,9 +17,14 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt8195-adsp-mbox
- - mediatek,mt8186-adsp-mbox
+ oneOf:
+ - enum:
+ - mediatek,mt8186-adsp-mbox
+ - mediatek,mt8195-adsp-mbox
+ - items:
+ - enum:
+ - mediatek,mt8188-adsp-mbox
+ - const: mediatek,mt8186-adsp-mbox
"#mbox-cells":
const: 0
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
deleted file mode 100644
index c2aeba63bd47..000000000000
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-MediaTek GCE
-===============
-
-The Global Command Engine (GCE) is used to help read/write registers with
-critical time limitation, such as updating display configuration during the
-vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
-
-CMDQ driver uses mailbox framework for communication. Please refer to
-mailbox.txt for generic information about mailbox device-tree bindings.
-
-Required properties:
-- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce",
- "mediatek,mt8186-gce", "mediatek,mt8192-gce", "mediatek,mt8195-gce" or
- "mediatek,mt6779-gce".
-- reg: Address range of the GCE unit
-- interrupts: The interrupt signal from the GCE block
-- clock: Clocks according to the common clock binding
-- clock-names: Must be "gce" to stand for GCE clock
-- #mbox-cells: Should be 2.
- <&phandle channel priority>
- phandle: Label name of a gce node.
- channel: Channel of mailbox. Be equal to the thread id of GCE.
- priority: Priority of GCE thread.
-
-Required properties for a client device:
-- mboxes: Client use mailbox to communicate with GCE, it should have this
- property and list of phandle, mailbox specifiers.
-Optional properties for a client device:
-- mediatek,gce-client-reg: Specify the sub-system id which is corresponding
- to the register address, it should have this property and list of phandle,
- sub-system specifiers.
- <&phandle subsys_number start_offset size>
- phandle: Label name of a gce node.
- subsys_number: specify the sub-system id which is corresponding
- to the register address.
- start_offset: the start offset of register address that GCE can access.
- size: the total size of register address that GCE can access.
-
-Optional properties for a client mutex node:
-- mediatek,gce-events: GCE events used by clients. The event numbers are
- defined in 'dt-bindings/gce/<chip>-gce.h'.
-
-Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h',
-'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8186-gce.h'
-'dt-bindings/gce/mt8192-gce.h', 'dt-bindings/gce/mt8195-gce.h' or
-'dt-bindings/gce/mt6779-gce.h'.
-Such as sub-system ids, thread priority, event ids.
-
-Example:
-
- gce: gce@10212000 {
- compatible = "mediatek,mt8173-gce";
- reg = <0 0x10212000 0 0x1000>;
- interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&infracfg CLK_INFRA_GCE>;
- clock-names = "gce";
- #mbox-cells = <2>;
- };
-
-Example for a client device:
-
- mmsys: clock-controller@14000000 {
- compatible = "mediatek,mt8173-mmsys";
- mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST>,
- <&gce 1 CMDQ_THR_PRIO_LOWEST>;
- mutex-event-eof = <CMDQ_EVENT_MUTEX0_STREAM_EOF
- CMDQ_EVENT_MUTEX1_STREAM_EOF>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>,
- <&gce SUBSYS_1401XXXX 0x2000 0x100>;
- ...
- };
-
-Example for a client mutex node:
- mutex: mutex@14020000 {
- compatible = "mediatek,mt8173-disp-mutex";
- reg = <0 0x14020000 0 0x1000>;
- interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- clocks = <&mmsys CLK_MM_MUTEX_32K>;
- mediatek,gce-events = <CMDQ_EVENT_MUTEX0_STREAM_EOF>,
- <CMDQ_EVENT_MUTEX1_STREAM_EOF>;
- };
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
index a3e87516d637..f833b845de0d 100644
--- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
@@ -59,13 +59,12 @@ description: |
<dt-bindings/mailbox/tegra186-hsp.h>
properties:
- $nodename:
- pattern: "^hsp@[0-9a-f]+$"
-
compatible:
oneOf:
- - const: nvidia,tegra186-hsp
- - const: nvidia,tegra194-hsp
+ - enum:
+ - nvidia,tegra186-hsp
+ - nvidia,tegra194-hsp
+ - nvidia,tegra264-hsp
- items:
- const: nvidia,tegra234-hsp
- const: nvidia,tegra194-hsp
@@ -75,7 +74,7 @@ properties:
interrupts:
minItems: 1
- maxItems: 9
+ maxItems: 17
interrupt-names:
oneOf:
@@ -85,6 +84,25 @@ properties:
- items:
- const: doorbell
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+ - pattern: "^shared([0-9]|1[0-5])$"
+
+ - items:
+ - const: doorbell
- pattern: "^shared[0-7]$"
- pattern: "^shared[0-7]$"
- pattern: "^shared[0-7]$"
@@ -110,14 +128,10 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mailbox/tegra186-hsp.h>
- hsp_top0: hsp@3c00000 {
+ mailbox@3c00000 {
compatible = "nvidia,tegra186-hsp";
reg = <0x03c00000 0xa0000>;
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "doorbell";
#mbox-cells = <2>;
};
-
- client {
- mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_CCPLEX>;
- };
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
index f504652fc0ea..f40dc9048327 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mailbox/qcom,apcs-kpss-global.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mailbox/qcom,apcs-kpss-global.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm APCS global block bindings
+title: Qualcomm APCS global block
description:
This binding describes the APCS "global" block found in various Qualcomm
@@ -18,50 +18,89 @@ properties:
oneOf:
- items:
- enum:
- - qcom,ipq6018-apcs-apps-global
+ - qcom,ipq5018-apcs-apps-global
+ - qcom,ipq5332-apcs-apps-global
+ - qcom,ipq5424-apcs-apps-global
- qcom,ipq8074-apcs-apps-global
+ - qcom,ipq9574-apcs-apps-global
+ - const: qcom,ipq6018-apcs-apps-global
+ - items:
+ - enum:
+ - qcom,msm8226-apcs-kpss-global
+ - qcom,qcs404-apcs-apps-global
+ - const: qcom,msm8916-apcs-kpss-global
+ - const: syscon
+ - items:
+ - enum:
+ - qcom,msm8974-apcs-kpss-global
- qcom,msm8976-apcs-kpss-global
- - qcom,msm8996-apcs-hmss-global
+ - const: qcom,msm8994-apcs-kpss-global
+ - const: syscon
+ - items:
+ - enum:
- qcom,msm8998-apcs-hmss-global
- - qcom,qcm2290-apcs-hmss-global
- - qcom,sc7180-apss-shared
- - qcom,sc8180x-apss-shared
- qcom,sdm660-apcs-hmss-global
- - qcom,sdm845-apss-shared
- - qcom,sm6125-apcs-hmss-global
+ - qcom,sm4250-apcs-hmss-global
- qcom,sm6115-apcs-hmss-global
+ - qcom,sm6125-apcs-hmss-global
+ - const: qcom,msm8994-apcs-kpss-global
+ - items:
+ - enum:
+ - qcom,qcs615-apss-shared
+ - qcom,sc7180-apss-shared
+ - qcom,sc8180x-apss-shared
+ - qcom,sm7150-apss-shared
- qcom,sm8150-apss-shared
+ - const: qcom,sdm845-apss-shared
- items:
- enum:
- qcom,msm8916-apcs-kpss-global
- qcom,msm8939-apcs-kpss-global
- qcom,msm8953-apcs-kpss-global
- qcom,msm8994-apcs-kpss-global
- - qcom,qcs404-apcs-apps-global
+ - qcom,sdx55-apcs-gcc
- const: syscon
+ - enum:
+ - qcom,ipq6018-apcs-apps-global
+ - qcom,msm8996-apcs-hmss-global
+ - qcom,qcm2290-apcs-hmss-global
+ - qcom,sdm845-apss-shared
+
reg:
maxItems: 1
clocks:
description: phandles to the parent clocks of the clock driver
minItems: 2
- items:
- - description: primary pll parent of the clock driver
- - description: auxiliary parent
- - description: reference clock
+ maxItems: 3
+ deprecated: true
'#mbox-cells':
const: 1
'#clock-cells':
- const: 0
+ enum: [0, 1]
clock-names:
minItems: 2
- items:
- - const: pll
- - const: aux
- - const: ref
+ maxItems: 3
+ deprecated: true
+
+ clock-controller:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ description: phandles to the parent clocks of the clock driver
+ minItems: 2
+ maxItems: 3
+
+ '#clock-cells':
+ enum: [0, 1]
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
required:
- compatible
@@ -70,62 +109,180 @@ required:
additionalProperties: false
+# Clocks should be specified either on the parent node or on the child node
+oneOf:
+ - required:
+ - clock-controller
+ properties:
+ clocks: false
+ clock-names: false
+ '#clock-cells': false
+ - properties:
+ clock-controller: false
+
+$defs:
+ msm8916-apcs-clock-controller:
+ properties:
+ clocks:
+ items:
+ - description: primary pll parent of the clock driver
+ - description: auxiliary parent
+ clock-names:
+ items:
+ - const: pll
+ - const: aux
+ '#clock-cells':
+ const: 0
+
+ msm8939-apcs-clock-controller:
+ properties:
+ clocks:
+ items:
+ - description: primary pll parent of the clock driver
+ - description: auxiliary parent
+ - description: reference clock
+ clock-names:
+ items:
+ - const: pll
+ - const: aux
+ - const: ref
+ '#clock-cells':
+ const: 0
+
+ sdx55-apcs-clock-controller:
+ properties:
+ clocks:
+ items:
+ - description: reference clock
+ - description: primary pll parent of the clock driver
+ - description: auxiliary parent
+ clock-names:
+ items:
+ - const: ref
+ - const: pll
+ - const: aux
+ '#clock-cells':
+ const: 0
+
+ ipq6018-apcs-clock-controller:
+ properties:
+ clocks:
+ items:
+ - description: primary pll parent of the clock driver
+ - description: XO clock
+ - description: GCC GPLL0 clock source
+ clock-names:
+ items:
+ - const: pll
+ - const: xo
+ - const: gpll0
+ '#clock-cells':
+ const: 1
+
allOf:
- if:
properties:
compatible:
- enum:
- - qcom,ipq6018-apcs-apps-global
- - qcom,ipq8074-apcs-apps-global
- - qcom,msm8916-apcs-kpss-global
- - qcom,msm8994-apcs-kpss-global
- - qcom,msm8996-apcs-hmss-global
- - qcom,msm8998-apcs-hmss-global
- - qcom,qcs404-apcs-apps-global
- - qcom,sc7180-apss-shared
- - qcom,sdm660-apcs-hmss-global
- - qcom,sdm845-apss-shared
- - qcom,sm6125-apcs-hmss-global
- - qcom,sm8150-apss-shared
+ contains:
+ enum:
+ - qcom,msm8916-apcs-kpss-global
+ then:
+ $ref: '#/$defs/msm8916-apcs-clock-controller'
+ properties:
+ clock-controller:
+ $ref: '#/$defs/msm8916-apcs-clock-controller'
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8939-apcs-kpss-global
+ then:
+ $ref: '#/$defs/msm8939-apcs-clock-controller'
+ properties:
+ clock-controller:
+ $ref: '#/$defs/msm8939-apcs-clock-controller'
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdx55-apcs-gcc
+ then:
+ $ref: '#/$defs/sdx55-apcs-clock-controller'
+ properties:
+ clock-controller:
+ $ref: '#/$defs/sdx55-apcs-clock-controller'
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq6018-apcs-apps-global
then:
+ $ref: '#/$defs/ipq6018-apcs-clock-controller'
properties:
- clocks:
- maxItems: 2
+ clock-controller:
+ $ref: '#/$defs/ipq6018-apcs-clock-controller'
+
- if:
properties:
compatible:
- enum:
- - qcom,sdx55-apcs-gcc
+ contains:
+ enum:
+ - qcom,msm8953-apcs-kpss-global
+ - qcom,msm8994-apcs-kpss-global
+ - qcom,msm8996-apcs-hmss-global
+ - qcom,qcm2290-apcs-hmss-global
+ - qcom,sdm845-apss-shared
then:
properties:
- clocks:
- maxItems: 3
+ clocks: false
+ clock-names: false
+ clock-controller: false
+ '#clock-cells':
+ const: 0
+
examples:
# Example apcs with msm8996
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- apcs_glb: mailbox@9820000 {
+ mailbox@9820000 {
compatible = "qcom,msm8996-apcs-hmss-global";
reg = <0x9820000 0x1000>;
#mbox-cells = <1>;
+ #clock-cells = <0>;
};
- rpm-glink {
- compatible = "qcom,glink-rpm";
- interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
- qcom,rpm-msg-ram = <&rpm_msg_ram>;
- mboxes = <&apcs_glb 0>;
- mbox-names = "rpm_hlos";
+ # Example apcs with qcs404
+ - |
+ #define GCC_APSS_AHB_CLK_SRC 1
+ #define GCC_GPLL0_AO_OUT_MAIN 123
+ mailbox@b011000 {
+ compatible = "qcom,qcs404-apcs-apps-global",
+ "qcom,msm8916-apcs-kpss-global", "syscon";
+ reg = <0x0b011000 0x1000>;
+ #mbox-cells = <1>;
+
+ apcs_clk: clock-controller {
+ clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>;
+ clock-names = "pll", "aux";
+ #clock-cells = <0>;
+ };
};
- # Example apcs with qcs404
+ # Example apcs with qcs404 (deprecated: use clock-controller subnode)
- |
#define GCC_APSS_AHB_CLK_SRC 1
#define GCC_GPLL0_AO_OUT_MAIN 123
apcs: mailbox@b011000 {
- compatible = "qcom,qcs404-apcs-apps-global", "syscon";
+ compatible = "qcom,qcs404-apcs-apps-global",
+ "qcom,msm8916-apcs-kpss-global", "syscon";
reg = <0x0b011000 0x1000>;
#mbox-cells = <1>;
clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>;
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
new file mode 100644
index 000000000000..9122c3d2dc30
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/qcom,cpucp-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. CPUCP Mailbox Controller
+
+maintainers:
+ - Sibi Sankar <quic_sibis@quicinc.com>
+
+description:
+ The CPUSS Control Processor (CPUCP) mailbox controller enables communication
+ between AP and CPUCP by acting as a doorbell between them.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,glymur-cpucp-mbox
+ - const: qcom,x1e80100-cpucp-mbox
+ - enum:
+ - qcom,x1e80100-cpucp-mbox
+
+ reg:
+ items:
+ - description: CPUCP rx register region
+ - description: CPUCP tx register region
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@17430000 {
+ compatible = "qcom,x1e80100-cpucp-mbox";
+ reg = <0x17430000 0x10000>, <0x18830000 0x10000>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
index baca4786ff94..e5c423130db6 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
@@ -24,12 +24,24 @@ properties:
compatible:
items:
- enum:
+ - qcom,milos-ipcc
+ - qcom,qcs8300-ipcc
+ - qcom,qdu1000-ipcc
+ - qcom,sa8255p-ipcc
+ - qcom,sa8775p-ipcc
+ - qcom,sar2130p-ipcc
+ - qcom,sc7280-ipcc
+ - qcom,sc8280xp-ipcc
+ - qcom,sdx75-ipcc
- qcom,sm6350-ipcc
- qcom,sm6375-ipcc
- qcom,sm8250-ipcc
- qcom,sm8350-ipcc
- qcom,sm8450-ipcc
- - qcom,sc7280-ipcc
+ - qcom,sm8550-ipcc
+ - qcom,sm8650-ipcc
+ - qcom,sm8750-ipcc
+ - qcom,x1e80100-ipcc
- const: qcom,ipcc
reg:
diff --git a/Documentation/devicetree/bindings/mailbox/riscv,rpmi-shmem-mbox.yaml b/Documentation/devicetree/bindings/mailbox/riscv,rpmi-shmem-mbox.yaml
new file mode 100644
index 000000000000..3aabc52a0c03
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/riscv,rpmi-shmem-mbox.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/riscv,rpmi-shmem-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V Platform Management Interface (RPMI) shared memory mailbox
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V Platform Management Interface (RPMI) [1] defines a common shared
+ memory based RPMI transport. This RPMI shared memory transport integrates as
+ mailbox controller in the SBI implementation or supervisor software whereas
+ each RPMI service group is mailbox client in the SBI implementation and
+ supervisor software.
+
+ ===========================================
+ References
+ ===========================================
+
+ [1] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+properties:
+ compatible:
+ const: riscv,rpmi-shmem-mbox
+
+ reg:
+ minItems: 2
+ items:
+ - description: A2P request queue base address
+ - description: P2A acknowledgment queue base address
+ - description: P2A request queue base address
+ - description: A2P acknowledgment queue base address
+ - description: A2P doorbell address
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: a2p-req
+ - const: p2a-ack
+ - enum: [ p2a-req, a2p-doorbell ]
+ - const: a2p-ack
+ - const: a2p-doorbell
+
+ interrupts:
+ maxItems: 1
+ description:
+ The RPMI shared memory transport supports P2A doorbell as a wired
+ interrupt and this property specifies the interrupt source.
+
+ msi-parent:
+ description:
+ The RPMI shared memory transport supports P2A doorbell as a system MSI
+ and this property specifies the target MSI controller.
+
+ riscv,slot-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 64
+ description:
+ Power-of-2 RPMI slot size of the RPMI shared memory transport.
+
+ riscv,a2p-doorbell-value:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x1
+ description:
+ Value written to the 32-bit A2P doorbell register.
+
+ riscv,p2a-doorbell-sysmsi-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The RPMI shared memory transport supports P2A doorbell as a system MSI
+ and this property specifies system MSI index to be used for configuring
+ the P2A doorbell MSI.
+
+ "#mbox-cells":
+ const: 1
+ description:
+ The first cell specifies RPMI service group ID.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - riscv,slot-size
+ - "#mbox-cells"
+
+anyOf:
+ - required:
+ - interrupts
+ - required:
+ - msi-parent
+
+additionalProperties: false
+
+examples:
+ - |
+ // Example 1 (RPMI shared memory with only 2 queues):
+ mailbox@10080000 {
+ compatible = "riscv,rpmi-shmem-mbox";
+ reg = <0x10080000 0x10000>,
+ <0x10090000 0x10000>;
+ reg-names = "a2p-req", "p2a-ack";
+ msi-parent = <&imsic_mlevel>;
+ riscv,slot-size = <64>;
+ #mbox-cells = <1>;
+ };
+ - |
+ // Example 2 (RPMI shared memory with only 4 queues):
+ mailbox@10001000 {
+ compatible = "riscv,rpmi-shmem-mbox";
+ reg = <0x10001000 0x800>,
+ <0x10001800 0x800>,
+ <0x10002000 0x800>,
+ <0x10002800 0x800>,
+ <0x10003000 0x4>;
+ reg-names = "a2p-req", "p2a-ack", "p2a-req", "a2p-ack", "a2p-doorbell";
+ msi-parent = <&imsic_mlevel>;
+ riscv,slot-size = <64>;
+ riscv,a2p-doorbell-value = <0x00008000>;
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml b/Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml
new file mode 100644
index 000000000000..061437a0b45a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/riscv,sbi-mpxy-mbox.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/riscv,sbi-mpxy-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V SBI Message Proxy (MPXY) extension based mailbox
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |
+ The RISC-V SBI Message Proxy (MPXY) extension [1] allows supervisor
+ software to send messages through the SBI implementation (M-mode
+ firmware or HS-mode hypervisor). The underlying message protocol
+ and message format used by the supervisor software could be some
+ other standard protocol compatible with the SBI MPXY extension
+ (such as RISC-V Platform Management Interface (RPMI) [2]).
+
+ ===========================================
+ References
+ ===========================================
+
+ [1] RISC-V Supervisor Binary Interface (SBI) v3.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-sbi-doc/releases
+
+ [2] RISC-V Platform Management Interface (RPMI) v1.0 (or higher)
+ https://github.com/riscv-non-isa/riscv-rpmi/releases
+
+properties:
+ compatible:
+ const: riscv,sbi-mpxy-mbox
+
+ "#mbox-cells":
+ const: 2
+ description:
+ The first cell specifies channel_id of the SBI MPXY channel,
+ the second cell specifies MSG_PROT_ID of the SBI MPXY channel
+
+required:
+ - compatible
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ mailbox {
+ compatible = "riscv,sbi-mpxy-mbox";
+ #mbox-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/rockchip,rk3368-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/rockchip,rk3368-mailbox.yaml
new file mode 100644
index 000000000000..107bc96a8f3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/rockchip,rk3368-mailbox.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/rockchip,rk3368-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3368 Mailbox Controller
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ The Rockchip mailbox is used by the Rockchip CPU cores to communicate
+ requests to MCU processor.
+
+properties:
+ compatible:
+ const: rockchip,rk3368-mailbox
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pclk_mailbox
+
+ interrupts:
+ description: One interrupt for each channel
+ maxItems: 4
+
+ '#mbox-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@ff6b0000 {
+ compatible = "rockchip,rk3368-mailbox";
+ reg = <0xff6b0000 0x1000>;
+ interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
deleted file mode 100644
index b6bb84acf5be..000000000000
--- a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Rockchip mailbox
-
-The Rockchip mailbox is used by the Rockchip CPU cores to communicate
-requests to MCU processor.
-
-Refer to ./mailbox.txt for generic information about mailbox device-tree
-bindings.
-
-Required properties:
-
- - compatible: should be one of the following.
- - "rockchip,rk3368-mbox" for rk3368
- - reg: physical base address of the controller and length of memory mapped
- region.
- - interrupts: The interrupt number to the cpu. The interrupt specifier format
- depends on the interrupt controller.
- - #mbox-cells: Common mailbox binding property to identify the number
- of cells required for the mailbox specifier. Should be 1
-
-Example:
---------
-
-/* RK3368 */
-mbox: mbox@ff6b0000 {
- compatible = "rockchip,rk3368-mailbox";
- reg = <0x0 0xff6b0000 0x0 0x1000>,
- interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
- #mbox-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml
new file mode 100644
index 000000000000..24e126bd3a20
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/sophgo,cv1800b-mailbox.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/sophgo,cv1800b-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800/SG2000 mailbox controller
+
+maintainers:
+ - Yuntao Dai <d1581209858@live.com>
+ - Junhui Liu <junhui.liu@pigmoral.tech>
+
+description:
+ Mailboxes integrated in Sophgo CV1800/SG2000 SoCs have 8 channels, each
+ shipping an 8-byte FIFO. Any processor can write to an arbitrary channel
+ and raise interrupts to receivers. Sending messages to itself is also
+ supported.
+
+properties:
+ compatible:
+ const: sophgo,cv1800b-mailbox
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 2
+ description: |
+ <&phandle channel target>
+ phandle : Label name of mailbox controller
+ channel : 0-7, Channel index
+ target : 0-3, Target processor ID
+
+ Sophgo CV1800/SG2000 SoCs include the following processors, numbered as:
+ <0> Cortex-A53 (Only available on CV181X/SG200X)
+ <1> C906B
+ <2> C906L
+ <3> 8051
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mailbox@1900000 {
+ compatible = "sophgo,cv1800b-mailbox";
+ reg = <0x01900000 0x1000>;
+ interrupts = <101 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml
index 80feba82cbd6..b526f9c0c272 100644
--- a/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mailbox/sprd-mailbox.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mailbox/sprd-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Spreadtrum mailbox controller bindings
+title: Spreadtrum mailbox controller
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
diff --git a/Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml
new file mode 100644
index 000000000000..a023c28dff49
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/st,sti-mailbox.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/st,sti-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics Mailbox Driver for STi platform
+
+description:
+ Each ST Mailbox IP currently consists of 4 instances of 32 channels.
+ Messages are passed between Application and Remote processors using
+ shared memory.
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+properties:
+ compatible:
+ const: st,stih407-mailbox
+
+ reg:
+ maxItems: 1
+
+ mbox-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: name of the mailbox IP
+
+ interrupts:
+ description: the irq line for the RX mailbox
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mailbox0: mailbox@8f00000 {
+ compatible = "st,stih407-mailbox";
+ reg = <0x8f00000 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <2>;
+ mbox-name = "a9";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml
index 2c8b47285aa3..134fd223a02b 100644
--- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml
+++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mailbox/st,stm32-ipcc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mailbox/st,stm32-ipcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 IPC controller bindings
+title: STMicroelectronics STM32 IPC controller
description:
The IPCC block provides a non blocking signaling mechanism to post and
diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
deleted file mode 100644
index 351f612673fc..000000000000
--- a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-ST Microelectronics Mailbox Driver
-
-Each ST Mailbox IP currently consists of 4 instances of 32 channels. Messages
-are passed between Application and Remote processors using shared memory.
-
-Controller
-----------
-
-Required properties:
-- compatible : Should be "st,stih407-mailbox"
-- reg : Offset and length of the device's register set
-- mbox-name : Name of the mailbox
-- #mbox-cells: : Must be 2
- <&phandle instance channel direction>
- phandle : Label name of controller
- instance : Instance number
- channel : Channel number
-
-Optional properties
-- interrupts : Contains the IRQ line for a Rx mailbox
-
-Example:
-
-mailbox0: mailbox@0 {
- compatible = "st,stih407-mailbox";
- reg = <0x08f00000 0x1000>;
- interrupts = <GIC_SPI 1 IRQ_TYPE_NONE>;
- #mbox-cells = <2>;
- mbox-name = "a9";
-};
-
-Client
-------
-
-Required properties:
-- compatible : Many (See the client docs)
-- reg : Shared (between Application and Remote) memory address
-- mboxes : Standard property to specify a Mailbox (See ./mailbox.txt)
- Cells must match 'mbox-cells' (See Controller docs above)
-
-Optional properties
-- mbox-names : Name given to channels seen in the 'mboxes' property.
-
-Example:
-
-mailbox_test {
- compatible = "mailbox-test";
- reg = <0x[shared_memory_address], [shared_memory_size]>;
- mboxes = <&mailbox2 0 1>, <&mailbox0 2 1>;
- mbox-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/mailbox/thead,th1520-mbox.yaml b/Documentation/devicetree/bindings/mailbox/thead,th1520-mbox.yaml
new file mode 100644
index 000000000000..0971fb97896e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/thead,th1520-mbox.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/thead,th1520-mbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-head TH1520 Mailbox Controller
+
+description:
+ The T-head mailbox controller enables communication and coordination between
+ cores within the SoC by passing messages (e.g., data, status, and control)
+ through mailbox channels. It also allows one core to signal another processor
+ using interrupts via the Interrupt Controller Unit (ICU).
+
+maintainers:
+ - Michal Wilczynski <m.wilczynski@samsung.com>
+
+properties:
+ compatible:
+ const: thead,th1520-mbox
+
+ clocks:
+ items:
+ - description: Clock for the local mailbox
+ - description: Clock for remote ICU 0
+ - description: Clock for remote ICU 1
+ - description: Clock for remote ICU 2
+
+ clock-names:
+ items:
+ - const: clk-local
+ - const: clk-remote-icu0
+ - const: clk-remote-icu1
+ - const: clk-remote-icu2
+
+ reg:
+ items:
+ - description: Mailbox local base address
+ - description: Remote ICU 0 base address
+ - description: Remote ICU 1 base address
+ - description: Remote ICU 2 base address
+
+ reg-names:
+ items:
+ - const: local
+ - const: remote-icu0
+ - const: remote-icu1
+ - const: remote-icu2
+
+ interrupts:
+ maxItems: 1
+
+ '#mbox-cells':
+ const: 1
+ description:
+ The one and only cell describes destination CPU ID.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - reg-names
+ - interrupts
+ - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/thead,th1520-clk-ap.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ mailbox@ffffc38000 {
+ compatible = "thead,th1520-mbox";
+ reg = <0xff 0xffc38000 0x0 0x4000>,
+ <0xff 0xffc44000 0x0 0x1000>,
+ <0xff 0xffc4c000 0x0 0x1000>,
+ <0xff 0xffc54000 0x0 0x1000>;
+ reg-names = "local", "remote-icu0", "remote-icu1", "remote-icu2";
+ clocks = <&clk CLK_MBOX0>, <&clk CLK_MBOX1>, <&clk CLK_MBOX2>,
+ <&clk CLK_MBOX3>;
+ clock-names = "clk-local", "clk-remote-icu0", "clk-remote-icu1",
+ "clk-remote-icu2";
+ interrupts = <28>;
+ #mbox-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
index d433e496ec6e..8504ceb64806 100644
--- a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml#
@@ -159,7 +159,7 @@ properties:
a corresponding sysc interconnect node.
This property is only needed on some legacy OMAP SoCs which have not
- yet been converted to the ti,sysc interconnect hierarachy, but is
+ yet been converted to the ti,sysc interconnect hierarchy, but is
otherwise considered obsolete.
patternProperties:
@@ -242,7 +242,7 @@ examples:
- |
/* OMAP4 */
#include <dt-bindings/interrupt-controller/arm-gic.h>
- mailbox: mailbox@4a0f4000 {
+ mailbox@4a0f4000 {
compatible = "ti,omap4-mailbox";
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -260,13 +260,9 @@ examples:
};
};
- dsp {
- mboxes = <&mailbox &mbox_dsp>;
- };
-
- |
/* AM33xx */
- mailbox1: mailbox@480c8000 {
+ mailbox@480c8000 {
compatible = "ti,omap4-mailbox";
reg = <0x480c8000 0x200>;
interrupts = <77>;
@@ -283,7 +279,7 @@ examples:
- |
/* AM65x */
- mailbox0_cluster0: mailbox@31f80000 {
+ mailbox@31f80000 {
compatible = "ti,am654-mailbox";
reg = <0x31f80000 0x200>;
#mbox-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
index eea822861804..c321b69f0ccd 100644
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -36,7 +36,7 @@ properties:
- const: scfg
reg:
- minItems: 3
+ maxItems: 3
interrupt-names:
minItems: 1
@@ -68,12 +68,12 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
secure_proxy: mailbox@32c00000 {
- compatible = "ti,am654-secure-proxy";
- #mbox-cells = <1>;
- reg-names = "target_data", "rt", "scfg";
- reg = <0x32c00000 0x100000>,
- <0x32400000 0x100000>,
- <0x32800000 0x100000>;
- interrupt-names = "rx_011";
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x32c00000 0x100000>,
+ <0x32400000 0x100000>,
+ <0x32800000 0x100000>;
+ interrupt-names = "rx_011";
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
};
diff --git a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
deleted file mode 100644
index e46451bb242f..000000000000
--- a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-The APM X-Gene SLIMpro mailbox is used to communicate messages between
-the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
-interrupt based door bell mechanism and can exchange simple messages using the
-internal registers.
-
-There are total of 8 interrupts in this mailbox. Each used for an individual
-door bell (or mailbox channel).
-
-Required properties:
-- compatible: Should be as "apm,xgene-slimpro-mbox".
-
-- reg: Contains the mailbox register address range.
-
-- interrupts: 8 interrupts must be from 0 to 7, interrupt 0 define the
- the interrupt for mailbox channel 0 and interrupt 1 for
- mailbox channel 1 and so likewise for the reminder.
-
-- #mbox-cells: only one to specify the mailbox channel number.
-
-Example:
-
-Mailbox Node:
- mailbox: mailbox@10540000 {
- compatible = "apm,xgene-slimpro-mbox";
- reg = <0x0 0x10540000 0x0 0xa000>;
- #mbox-cells = <1>;
- interrupts = <0x0 0x0 0x4>,
- <0x0 0x1 0x4>,
- <0x0 0x2 0x4>,
- <0x0 0x3 0x4>,
- <0x0 0x4 0x4>,
- <0x0 0x5 0x4>,
- <0x0 0x6 0x4>,
- <0x0 0x7 0x4>,
- };
diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
index 2193141dd7fd..04d6473d666f 100644
--- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mailbox/xlnx,zynqmp-ipi-mailbox.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mailbox/xlnx,zynqmp-ipi-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx IPI(Inter Processor Interrupt) mailbox controller
@@ -33,11 +33,13 @@ description: |
+------------------------------------------+
maintainers:
- - Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
properties:
compatible:
- const: xlnx,zynqmp-ipi-mailbox
+ enum:
+ - xlnx,zynqmp-ipi-mailbox
+ - xlnx,versal-ipi-mailbox
method:
description: |
@@ -58,6 +60,12 @@ properties:
'#size-cells':
const: 2
+ reg:
+ maxItems: 2
+
+ reg-names:
+ maxItems: 2
+
xlnx,ipi-id:
description: |
Remote Xilinx IPI agent ID of which the mailbox is connected to.
@@ -72,7 +80,22 @@ patternProperties:
'^mailbox@[0-9a-f]+$':
description: Internal ipi mailbox node
type: object # DT nodes are json objects
+ additionalProperties: false
properties:
+
+ compatible:
+ enum:
+ - xlnx,zynqmp-ipi-dest-mailbox
+ - xlnx,versal-ipi-dest-mailbox
+
+ reg:
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ minItems: 1
+ maxItems: 4
+
xlnx,ipi-id:
description:
Remote Xilinx IPI agent ID of which the mailbox is connected to.
@@ -83,22 +106,44 @@ patternProperties:
description:
It contains tx(0) or rx(1) channel IPI id number.
- reg:
- maxItems: 4
-
- reg-names:
- items:
- - const: local_request_region
- - const: local_response_region
- - const: remote_request_region
- - const: remote_response_region
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-ipi-dest-mailbox
+ then:
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: local_request_region
+ - const: local_response_region
+ - const: remote_request_region
+ - const: remote_response_region
+ else:
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: Remote IPI agent control register region
+ - description: Remote IPI agent optional message buffers
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: ctrl
+ - const: msg
required:
+ - compatible
- reg
- reg-names
- - "#mbox-cells"
-
-additionalProperties: false
+ - '#mbox-cells'
+ - xlnx,ipi-id
required:
- compatible
@@ -107,6 +152,36 @@ required:
- '#size-cells'
- xlnx,ipi-id
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-ipi-mailbox
+ then:
+ properties:
+ reg: false
+ reg-names: false
+
+ else:
+ properties:
+ reg:
+ items:
+ - description: Host IPI agent control register region
+ - description: Host IPI agent optional message buffers
+
+ reg-names:
+ items:
+ - const: ctrl
+ - const: msg
+
+ required:
+ - reg
+ - reg-names
+
+additionalProperties: false
+
examples:
- |
#include<dt-bindings/interrupt-controller/arm-gic.h>
@@ -123,6 +198,7 @@ examples:
ranges;
mailbox: mailbox@ff9905c0 {
+ compatible = "xlnx,zynqmp-ipi-dest-mailbox";
reg = <0x0 0xff9905c0 0x0 0x20>,
<0x0 0xff9905e0 0x0 0x20>,
<0x0 0xff990e80 0x0 0x20>,
@@ -137,4 +213,41 @@ examples:
};
};
+ - |
+ #include<dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ mailbox@ff300000 {
+ compatible = "xlnx,versal-ipi-mailbox";
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ reg = <0x0 0xff300000 0x0 0x1000>,
+ <0x0 0xff990000 0x0 0x1ff>;
+ reg-names = "ctrl", "msg";
+ xlnx,ipi-id = <0>;
+ ranges;
+
+ /* buffered IPI */
+ mailbox@ff340000 {
+ compatible = "xlnx,versal-ipi-dest-mailbox";
+ reg = <0x0 0xff340000 0x0 0x1000>,
+ <0x0 0xff990400 0x0 0x1ff>;
+ reg-names = "ctrl", "msg";
+ #mbox-cells = <1>;
+ xlnx,ipi-id = <4>;
+ };
+
+ /* bufferless IPI */
+ mailbox@ff370000 {
+ compatible = "xlnx,versal-ipi-dest-mailbox";
+ reg = <0x0 0xff370000 0x0 0x1000>;
+ reg-names = "ctrl";
+ #mbox-cells = <1>;
+ xlnx,ipi-id = <7>;
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/media/allegro,al5e.yaml b/Documentation/devicetree/bindings/media/allegro,al5e.yaml
index 135bea94b587..2899d26d690e 100644
--- a/Documentation/devicetree/bindings/media/allegro,al5e.yaml
+++ b/Documentation/devicetree/bindings/media/allegro,al5e.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allegro,al5e.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allegro DVT Video IP Codecs Device Tree Bindings
+title: Allegro DVT Video IP Codecs
maintainers:
- Michael Tretter <m.tretter@pengutronix.de>
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
index 6ced94064215..617264ce477d 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun4i-a10-csi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 CMOS Sensor Interface (CSI) Device Tree Bindings
+title: Allwinner A10 CMOS Sensor Interface (CSI)
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
index 6d8395d6bca0..42dfe22ad5f1 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/media/allwinner,sun4i-a10-ir.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Infrared Controller Device Tree Bindings
+title: Allwinner A10 Infrared Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "rc.yaml#"
+ - $ref: rc.yaml#
properties:
compatible:
@@ -21,6 +21,7 @@ properties:
- const: allwinner,sun6i-a31-ir
- items:
- enum:
+ - allwinner,suniv-f1c100s-ir
- allwinner,sun8i-a83t-ir
- allwinner,sun8i-r40-ir
- allwinner,sun50i-a64-ir
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
index ee7fc3515d89..541325f900a1 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun4i-a10-video-engine.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Video Engine Device Tree Bindings
+title: Allwinner A10 Video Engine
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml
index 24d7bf21499e..8ba5177ac631 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hantro G2 VPU codec implemented on Allwinner H6 SoC
@@ -36,6 +35,9 @@ properties:
resets:
maxItems: 1
+ iommus:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -43,6 +45,7 @@ required:
- clocks
- clock-names
- resets
+ - iommus
additionalProperties: false
@@ -59,6 +62,7 @@ examples:
clocks = <&ccu CLK_BUS_VP9>, <&ccu CLK_VP9>;
clock-names = "bus", "mod";
resets = <&ccu RST_BUS_VP9>;
+ iommus = <&iommu 5>;
};
...
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 8551c4a711dc..1aa5775ba2bc 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-csi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 CMOS Sensor Interface (CSI) Device Tree Bindings
+title: Allwinner A31 CMOS Sensor Interface (CSI)
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -73,6 +73,10 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: MIPI CSI-2 bridge input port
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Internal output port to the ISP
+
anyOf:
- required:
- port@0
@@ -106,7 +110,7 @@ examples:
reg = <0x01cb4000 0x1000>;
interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_CSI>,
- <&ccu CLK_CSI1_SCLK>,
+ <&ccu CLK_CSI_SCLK>,
<&ccu CLK_DRAM_CSI>;
clock-names = "bus",
"mod",
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml
new file mode 100644
index 000000000000..3ea4a4290f23
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-isp.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-isp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A31 Image Signal Processor Driver (ISP)
+
+maintainers:
+ - Paul Kocialkowski <paul.kocialkowski@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun6i-a31-isp
+ - allwinner,sun8i-v3s-isp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Bus Clock
+ - description: Module Clock
+ - description: DRAM Clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: mod
+ - const: ram
+
+ resets:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CSI0 input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CSI1 input port
+
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun8i-v3s-isp
+ then:
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/sun8i-v3s-ccu.h>
+ #include <dt-bindings/reset/sun8i-v3s-ccu.h>
+
+ isp: isp@1cb8000 {
+ compatible = "allwinner,sun8i-v3s-isp";
+ reg = <0x01cb8000 0x1000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ isp_in_csi0: endpoint {
+ remote-endpoint = <&csi0_out_isp>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
index 09725ca955f6..627b28e94354 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 MIPI CSI-2 Device Tree Bindings
+title: Allwinner A31 MIPI CSI-2
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
@@ -103,7 +103,7 @@ examples:
reg = <0x01cb1000 0x1000>;
interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_CSI>,
- <&ccu CLK_CSI1_SCLK>;
+ <&ccu CLK_CSI_SCLK>;
clock-names = "bus", "mod";
resets = <&ccu RST_BUS_CSI>;
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml
index a258832d520c..c2f292dd01ed 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-de2-rotate.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83T DE2 Rotate Device Tree Bindings
+title: Allwinner A83T DE2 Rotate
maintainers:
- Jernej Skrabec <jernej.skrabec@siol.net>
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
index 5b27482b5687..3cac68a87ad7 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83T MIPI CSI-2 Device Tree Bindings
+title: Allwinner A83T MIPI CSI-2
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun8i-h3-deinterlace.yaml b/Documentation/devicetree/bindings/media/allwinner,sun8i-h3-deinterlace.yaml
index b80980b1908e..3ccd52164f5b 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun8i-h3-deinterlace.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun8i-h3-deinterlace.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/allwinner,sun8i-h3-deinterlace.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner H3 Deinterlace Device Tree Bindings
+title: Allwinner H3 Deinterlace
maintainers:
- Jernej Skrabec <jernej.skrabec@siol.net>
diff --git a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
index e551be5e680e..f23fa6d06ad0 100644
--- a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
+++ b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic GE2D Acceleration Unit
diff --git a/Documentation/devicetree/bindings/media/amlogic,c3-isp.yaml b/Documentation/devicetree/bindings/media/amlogic,c3-isp.yaml
new file mode 100644
index 000000000000..123bf462f098
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/amlogic,c3-isp.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/amlogic,c3-isp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic C3 Image Signal Processing Unit
+
+maintainers:
+ - Keke Li <keke.li@amlogic.com>
+
+description:
+ Amlogic ISP is the RAW image processing module
+ and supports three channels image output.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,c3-isp
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: isp
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: vapb
+ - const: isp0
+
+ interrupts:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: input port node.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - clock-names
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/amlogic,c3-peripherals-clkc.h>
+ #include <dt-bindings/power/amlogic,c3-pwrc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp: isp@ff000000 {
+ compatible = "amlogic,c3-isp";
+ reg = <0x0 0xff000000 0x0 0xf000>;
+ reg-names = "isp";
+ power-domains = <&pwrc PWRC_C3_ISP_TOP_ID>;
+ clocks = <&clkc_periphs CLKID_VAPB>,
+ <&clkc_periphs CLKID_ISP0>;
+ clock-names = "vapb", "isp0";
+ assigned-clocks = <&clkc_periphs CLKID_VAPB>,
+ <&clkc_periphs CLKID_ISP0>;
+ assigned-clock-rates = <0>, <400000000>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_EDGE_RISING>;
+
+ port {
+ c3_isp_in: endpoint {
+ remote-endpoint = <&c3_adap_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/amlogic,c3-mipi-adapter.yaml b/Documentation/devicetree/bindings/media/amlogic,c3-mipi-adapter.yaml
new file mode 100644
index 000000000000..ba43bc6709a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/amlogic,c3-mipi-adapter.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/amlogic,c3-mipi-adapter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic C3 MIPI adapter receiver
+
+maintainers:
+ - Keke Li <keke.li@amlogic.com>
+
+description:
+ MIPI adapter is used to convert the MIPI CSI-2 data
+ into an ISP supported data format.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,c3-mipi-adapter
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: top
+ - const: fd
+ - const: rd
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: vapb
+ - const: isp0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: input port node.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: output port node.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,c3-peripherals-clkc.h>
+ #include <dt-bindings/power/amlogic,c3-pwrc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ adap: adap@ff010000 {
+ compatible = "amlogic,c3-mipi-adapter";
+ reg = <0x0 0xff010000 0x0 0x100>,
+ <0x0 0xff01b000 0x0 0x100>,
+ <0x0 0xff01d000 0x0 0x200>;
+ reg-names = "top", "fd", "rd";
+ power-domains = <&pwrc PWRC_C3_ISP_TOP_ID>;
+ clocks = <&clkc_periphs CLKID_VAPB>,
+ <&clkc_periphs CLKID_ISP0>;
+ clock-names = "vapb", "isp0";
+ assigned-clocks = <&clkc_periphs CLKID_VAPB>,
+ <&clkc_periphs CLKID_ISP0>;
+ assigned-clock-rates = <0>, <400000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ c3_adap_in: endpoint {
+ remote-endpoint = <&c3_mipi_csi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ c3_adap_out: endpoint {
+ remote-endpoint = <&c3_isp_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/amlogic,c3-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/amlogic,c3-mipi-csi2.yaml
new file mode 100644
index 000000000000..b0129beab0c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/amlogic,c3-mipi-csi2.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/amlogic,c3-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic C3 MIPI CSI-2 receiver
+
+maintainers:
+ - Keke Li <keke.li@amlogic.com>
+
+description:
+ MIPI CSI-2 receiver contains CSI-2 RX PHY and host controller.
+ It receives the MIPI data from the image sensor and sends MIPI data
+ to MIPI adapter.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,c3-mipi-csi2
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: aphy
+ - const: dphy
+ - const: host
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: vapb
+ - const: phy0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: input port node, connected to sensor.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: output port node
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/amlogic,c3-peripherals-clkc.h>
+ #include <dt-bindings/power/amlogic,c3-pwrc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ csi: csi@ff018000 {
+ compatible = "amlogic,c3-mipi-csi2";
+ reg = <0x0 0xff018000 0x0 0x400>,
+ <0x0 0xff019000 0x0 0x300>,
+ <0x0 0xff01a000 0x0 0x100>;
+ reg-names = "aphy", "dphy", "host";
+ power-domains = <&pwrc PWRC_C3_MIPI_ISP_WRAP_ID>;
+ clocks = <&clkc_periphs CLKID_VAPB>,
+ <&clkc_periphs CLKID_CSI_PHY0>;
+ clock-names = "vapb", "phy0";
+ assigned-clocks = <&clkc_periphs CLKID_VAPB>,
+ <&clkc_periphs CLKID_CSI_PHY0>;
+ assigned-clock-rates = <0>, <200000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ c3_mipi_csi_in: endpoint {
+ remote-endpoint = <&imx290_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ c3_mipi_csi_out: endpoint {
+ remote-endpoint = <&c3_adap_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml
index b827edabcafa..47dce75aeae6 100644
--- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml
+++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/amlogic,gx-vdec.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/amlogic,gx-vdec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Video Decoder
@@ -31,7 +31,8 @@ properties:
- items:
- enum:
- amlogic,gxbb-vdec # GXBB (S905)
- - amlogic,gxl-vdec # GXL (S905X, S905D)
+ - amlogic,gxl-vdec # GXL (S905D, S905W, S905X, S905Y)
+ - amlogic,gxlx-vdec # GXLX (S905L)
- amlogic,gxm-vdec # GXM (S912)
- const: amlogic,gx-vdec
- enum:
diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml
index 4432fea32650..6da8a6aded23 100644
--- a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml
+++ b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson IR transmitter
diff --git a/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml b/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml
new file mode 100644
index 000000000000..0f95fe8dd9ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/amlogic,meson6-ir.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson IR remote control receiver
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: rc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson6-ir
+ - amlogic,meson8b-ir
+ - amlogic,meson-gxbb-ir
+ - amlogic,meson-s4-ir
+ - items:
+ - const: amlogic,meson-gx-ir
+ - const: amlogic,meson-gxbb-ir
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ ir-receiver@c8100480 {
+ compatible = "amlogic,meson6-ir";
+ reg = <0xc8100480 0x20>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_EDGE_RISING>;
+ };
diff --git a/Documentation/devicetree/bindings/media/amphion,vpu.yaml b/Documentation/devicetree/bindings/media/amphion,vpu.yaml
index a9d80eaeeeb6..fa18013d705d 100644
--- a/Documentation/devicetree/bindings/media/amphion,vpu.yaml
+++ b/Documentation/devicetree/bindings/media/amphion,vpu.yaml
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/amphion,vpu.yaml#
@@ -44,10 +43,9 @@ patternProperties:
description:
Each vpu encoder or decoder correspond a MU, which used for communication
between driver and firmware. Implement via mailbox on driver.
- $ref: ../mailbox/fsl,mu.yaml#
-
+ $ref: /schemas/mailbox/fsl,mu.yaml#
- "^vpu_core@[0-9a-f]+$":
+ "^vpu-core@[0-9a-f]+$":
description:
Each core correspond a decoder or encoder, need to configure them
separately. NXP i.MX8QM SoC has one decoder and two encoder, i.MX8QXP SoC
@@ -143,7 +141,7 @@ examples:
power-domains = <&pd IMX_SC_R_VPU_MU_2>;
};
- vpu_core0: vpu_core@2d080000 {
+ vpu_core0: vpu-core@2d080000 {
compatible = "nxp,imx8q-vpu-decoder";
reg = <0x2d080000 0x10000>;
power-domains = <&pd IMX_SC_R_VPU_DEC_0>;
@@ -154,7 +152,7 @@ examples:
memory-region = <&decoder_boot>, <&decoder_rpc>;
};
- vpu_core1: vpu_core@2d090000 {
+ vpu_core1: vpu-core@2d090000 {
compatible = "nxp,imx8q-vpu-encoder";
reg = <0x2d090000 0x10000>;
power-domains = <&pd IMX_SC_R_VPU_ENC_0>;
@@ -165,7 +163,7 @@ examples:
memory-region = <&encoder1_boot>, <&encoder1_rpc>;
};
- vpu_core2: vpu_core@2d0a0000 {
+ vpu_core2: vpu-core@2d0a0000 {
reg = <0x2d0a0000 0x10000>;
compatible = "nxp,imx8q-vpu-encoder";
power-domains = <&pd IMX_SC_R_VPU_ENC_1>;
diff --git a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
new file mode 100644
index 000000000000..fc4fcd19922a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/arm,mali-c55.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Mali-C55 Image Signal Processor
+
+maintainers:
+ - Daniel Scally <dan.scally@ideasonboard.com>
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+
+properties:
+ compatible:
+ const: arm,mali-c55
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ISP Video Clock
+ - description: ISP AXI clock
+ - description: ISP AHB-lite clock
+
+ clock-names:
+ items:
+ - const: vclk
+ - const: aclk
+ - const: hclk
+
+ resets:
+ items:
+ - description: vclk domain reset
+ - description: aclk domain reset
+ - description: hclk domain reset
+
+ reset-names:
+ items:
+ - const: vresetn
+ - const: aresetn
+ - const: hresetn
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input parallel video bus
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ isp@400000 {
+ compatible = "arm,mali-c55";
+ reg = <0x400000 0x200000>;
+ clocks = <&clk 0>, <&clk 1>, <&clk 2>;
+ clock-names = "vclk", "aclk", "hclk";
+ resets = <&resets 0>, <&resets 1>, <&resets 2>;
+ reset-names = "vresetn", "aresetn", "hresetn";
+ interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>;
+
+ port {
+ isp_in: endpoint {
+ remote-endpoint = <&csi2_rx_out>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml b/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml
new file mode 100644
index 000000000000..682bba20778c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/aspeed,video-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED Video Engine
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ The Video Engine (VE) embedded in the ASPEED SOCs can be configured to
+ capture and compress video data from digital or analog sources.
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-video-engine
+ - aspeed,ast2500-video-engine
+ - aspeed,ast2600-video-engine
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: vclk
+ - const: eclk
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+ description: |
+ Phandle to the reserved memory nodes to be associated with the
+ VE. VE will acquires memory space for 3 purposes:
+ 1. JPEG header
+ 2. Compressed result
+ 3. Temporary transformed image data
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/ast2600-clock.h>
+
+ video@1e700000 {
+ compatible = "aspeed,ast2600-video-engine";
+ reg = <0x1e700000 0x1000>;
+ clocks = <&syscon ASPEED_CLK_GATE_VCLK>,
+ <&syscon ASPEED_CLK_GATE_ECLK>;
+ clock-names = "vclk", "eclk";
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/media/aspeed-video.txt b/Documentation/devicetree/bindings/media/aspeed-video.txt
deleted file mode 100644
index d2ca32512272..000000000000
--- a/Documentation/devicetree/bindings/media/aspeed-video.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Device tree bindings for Aspeed Video Engine
-
-The Video Engine (VE) embedded in the Aspeed AST2400/2500/2600 SOCs can
-capture and compress video data from digital or analog sources.
-
-Required properties:
- - compatible: "aspeed,ast2400-video-engine" or
- "aspeed,ast2500-video-engine" or
- "aspeed,ast2600-video-engine"
- - reg: contains the offset and length of the VE memory region
- - clocks: clock specifiers for the syscon clocks associated with
- the VE (ordering must match the clock-names property)
- - clock-names: "vclk" and "eclk"
- - resets: reset specifier for the syscon reset associated with
- the VE
- - interrupts: the interrupt associated with the VE on this platform
-
-Optional properties:
- - memory-region:
- phandle to a memory region to allocate from, as defined in
- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
-
-Example:
-
-video-engine@1e700000 {
- compatible = "aspeed,ast2500-video-engine";
- reg = <0x1e700000 0x20000>;
- clocks = <&syscon ASPEED_CLK_GATE_VCLK>, <&syscon ASPEED_CLK_GATE_ECLK>;
- clock-names = "vclk", "eclk";
- resets = <&syscon ASPEED_RESET_VIDEO>;
- interrupts = <7>;
- memory-region = <&video_engine_memory>;
-};
diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml
index cd6d7af0c768..dc8aba698d78 100644
--- a/Documentation/devicetree/bindings/media/atmel,isc.yaml
+++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml
@@ -45,7 +45,7 @@ properties:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
- unevaluatedProperties: false
+ additionalProperties: false
description:
Input port node, single endpoint describing the input pad.
@@ -77,8 +77,6 @@ properties:
additionalProperties: false
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml b/Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
new file mode 100644
index 000000000000..5fb5d60f069a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/brcm,bcm2835-unicam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM283x Camera Interface (Unicam)
+
+maintainers:
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description: |-
+ The Unicam block on BCM283x SoCs is the receiver for either
+ CSI-2 or CCP2 data from image sensors or similar devices.
+
+ The main platform using this SoC is the Raspberry Pi family of boards. On
+ the Pi the VideoCore firmware can also control this hardware block, and
+ driving it from two different processors will cause issues. To avoid this,
+ the firmware checks the device tree configuration during boot. If it finds
+ device tree nodes whose name starts with 'csi' then it will stop the firmware
+ accessing the block, and it can then safely be used via the device tree
+ binding.
+
+properties:
+ compatible:
+ const: brcm,bcm2835-unicam
+
+ reg:
+ items:
+ - description: Unicam block.
+ - description: Clock Manager Image (CMI) block.
+
+ reg-names:
+ items:
+ - const: unicam
+ - const: cmi
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Clock to drive the LP state machine of Unicam.
+ - description: Clock for the VPU (core clock).
+
+ clock-names:
+ items:
+ - const: lp
+ - const: vpu
+
+ power-domains:
+ items:
+ - description: Unicam power domain
+
+ brcm,num-data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 2, 4 ]
+ description: |
+ Number of CSI-2 data lanes supported by this Unicam instance. The number
+ of data lanes actively used is specified with the data-lanes endpoint
+ property.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ bus-type:
+ enum: [ 3, 4 ]
+
+ clock-noncontinuous: true
+ data-lanes: true
+ remote-endpoint: true
+
+ required:
+ - bus-type
+ - data-lanes
+ - remote-endpoint
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - brcm,num-data-lanes
+ - port
+
+additionalProperties: False
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/power/raspberrypi-power.h>
+
+ csi1: csi@7e801000 {
+ compatible = "brcm,bcm2835-unicam";
+ reg = <0x7e801000 0x800>,
+ <0x7e802004 0x4>;
+ reg-names = "unicam", "cmi";
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clocks BCM2835_CLOCK_CAM1>,
+ <&firmware_clocks 4>;
+ clock-names = "lp", "vpu";
+ power-domains = <&power RPI_POWER_DOMAIN_UNICAM1>;
+ brcm,num-data-lanes = <2>;
+ port {
+ csi1_ep: endpoint {
+ remote-endpoint = <&imx219_0>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt b/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
deleted file mode 100644
index 6b02a0657ad9..000000000000
--- a/Documentation/devicetree/bindings/media/cdns,csi2rx.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Cadence MIPI-CSI2 RX controller
-===============================
-
-The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
-lanes in input, and 4 different pixel streams in output.
-
-Required properties:
- - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
- - reg: base address and size of the memory mapped region
- - clocks: phandles to the clocks driving the controller
- - clock-names: must contain:
- * sys_clk: main clock
- * p_clk: register bank clock
- * pixel_if[0-3]_clk: pixel stream output clock, one for each stream
- implemented in hardware, between 0 and 3
-
-Optional properties:
- - phys: phandle to the external D-PHY, phy-names must be provided
- - phy-names: must contain "dphy", if the implementation uses an
- external D-PHY
-
-Required subnodes:
- - ports: A ports node with one port child node per device input and output
- port, in accordance with the video interface bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt. The
- port nodes are numbered as follows:
-
- Port Description
- -----------------------------
- 0 CSI-2 input
- 1 Stream 0 output
- 2 Stream 1 output
- 3 Stream 2 output
- 4 Stream 3 output
-
- The stream output port nodes are optional if they are not
- connected to anything at the hardware level or implemented
- in the design.Since there is only one endpoint per port,
- the endpoints are not numbered.
-
-
-Example:
-
-csi2rx: csi-bridge@0d060000 {
- compatible = "cdns,csi2rx";
- reg = <0x0d060000 0x1000>;
- clocks = <&byteclock>, <&byteclock>
- <&coreclock>, <&coreclock>,
- <&coreclock>, <&coreclock>;
- clock-names = "sys_clk", "p_clk",
- "pixel_if0_clk", "pixel_if1_clk",
- "pixel_if2_clk", "pixel_if3_clk";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- csi2rx_in_sensor: endpoint {
- remote-endpoint = <&sensor_out_csi2rx>;
- clock-lanes = <0>;
- data-lanes = <1 2>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- csi2rx_out_grabber0: endpoint {
- remote-endpoint = <&grabber0_in_csi2rx>;
- };
- };
-
- port@2 {
- reg = <2>;
-
- csi2rx_out_grabber1: endpoint {
- remote-endpoint = <&grabber1_in_csi2rx>;
- };
- };
-
- port@3 {
- reg = <3>;
-
- csi2rx_out_grabber2: endpoint {
- remote-endpoint = <&grabber2_in_csi2rx>;
- };
- };
-
- port@4 {
- reg = <4>;
-
- csi2rx_out_grabber3: endpoint {
- remote-endpoint = <&grabber3_in_csi2rx>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
new file mode 100644
index 000000000000..6ed9a5621064
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns,csi2rx.yaml
@@ -0,0 +1,210 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cdns,csi2rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MIPI-CSI2 RX controller
+
+maintainers:
+ - Maxime Ripard <mripard@kernel.org>
+
+description:
+ The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+ lanes in input, and 4 different pixel streams in output.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - starfive,jh7110-csi2rx
+ - ti,j721e-csi2rx
+ - const: cdns,csi2rx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: error_irq
+ - const: irq
+
+ clocks:
+ items:
+ - description: CSI2Rx system clock
+ - description: Gated Register bank clock for APB interface
+ - description: pixel Clock for Stream interface 0
+ - description: pixel Clock for Stream interface 1
+ - description: pixel Clock for Stream interface 2
+ - description: pixel Clock for Stream interface 3
+
+ clock-names:
+ items:
+ - const: sys_clk
+ - const: p_clk
+ - const: pixel_if0_clk
+ - const: pixel_if1_clk
+ - const: pixel_if2_clk
+ - const: pixel_if3_clk
+
+ resets:
+ items:
+ - description: CSI2Rx system reset
+ - description: Gated Register bank reset for APB interface
+ - description: pixel reset for Stream interface 0
+ - description: pixel reset for Stream interface 1
+ - description: pixel reset for Stream interface 2
+ - description: pixel reset for Stream interface 3
+
+ reset-names:
+ items:
+ - const: sys
+ - const: reg_bank
+ - const: pixel_if0
+ - const: pixel_if1
+ - const: pixel_if2
+ - const: pixel_if3
+
+ phys:
+ maxItems: 1
+ description: MIPI D-PHY
+
+ phy-names:
+ items:
+ - const: dphy
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ const: 4
+
+ clock-lanes:
+ const: 0
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 4
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 0 Output port node
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 1 Output port node
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 2 Output port node
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Stream 3 Output port node
+
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ csi@d060000 {
+ compatible = "starfive,jh7110-csi2rx", "cdns,csi2rx";
+ reg = <0x0d060000 0x1000>;
+ clocks = <&byteclock 7>, <&byteclock 6>,
+ <&coreclock 8>, <&coreclock 9>,
+ <&coreclock 10>, <&coreclock 11>;
+ clock-names = "sys_clk", "p_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+ resets = <&bytereset 9>, <&bytereset 4>,
+ <&corereset 5>, <&corereset 6>,
+ <&corereset 7>, <&corereset 8>;
+ reset-names = "sys", "reg_bank",
+ "pixel_if0", "pixel_if1",
+ "pixel_if2", "pixel_if3";
+ phys = <&csi_phy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csi2rx_in_sensor: endpoint {
+ remote-endpoint = <&sensor_out_csi2rx>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csi2rx_out_grabber0: endpoint {
+ remote-endpoint = <&grabber0_in_csi2rx>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ csi2rx_out_grabber1: endpoint {
+ remote-endpoint = <&grabber1_in_csi2rx>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ csi2rx_out_grabber2: endpoint {
+ remote-endpoint = <&grabber2_in_csi2rx>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ csi2rx_out_grabber3: endpoint {
+ remote-endpoint = <&grabber3_in_csi2rx>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt b/Documentation/devicetree/bindings/media/cec-gpio.txt
deleted file mode 100644
index 47e8d73d32a3..000000000000
--- a/Documentation/devicetree/bindings/media/cec-gpio.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* HDMI CEC GPIO driver
-
-The HDMI CEC GPIO module supports CEC implementations where the CEC line
-is hooked up to a pull-up GPIO line and - optionally - the HPD line is
-hooked up to another GPIO line.
-
-Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
-5V lines it is 5.3V. So you may need some sort of level conversion circuitry
-when connecting them to a GPIO line.
-
-Required properties:
- - compatible: value must be "cec-gpio".
- - cec-gpios: gpio that the CEC line is connected to. The line should be
- tagged as open drain.
-
-If the CEC line is associated with an HDMI receiver/transmitter, then the
-following property is also required:
-
- - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
-
-If the CEC line is not associated with an HDMI receiver/transmitter, then
-the following property is optional and can be used for debugging HPD changes:
-
- - hpd-gpios: gpio that the HPD line is connected to.
-
-This property is optional and can be used for debugging changes on the 5V line:
-
- - v5-gpios: gpio that the 5V line is connected to.
-
-Example for the Raspberry Pi 3 where the CEC line is connected to
-pin 26 aka BCM7 aka CE1 on the GPIO pin header, the HPD line is
-connected to pin 11 aka BCM17 and the 5V line is connected to pin
-15 aka BCM22 (some level shifter is needed for the HPD and 5V lines!):
-
-#include <dt-bindings/gpio/gpio.h>
-
-cec-gpio {
- compatible = "cec-gpio";
- cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
- hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
- v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/media/cec.txt b/Documentation/devicetree/bindings/media/cec.txt
deleted file mode 100644
index 22d7aae3d3d7..000000000000
--- a/Documentation/devicetree/bindings/media/cec.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Common bindings for HDMI CEC adapters
-
-- hdmi-phandle: phandle to the HDMI controller.
-
-- needs-hpd: if present the CEC support is only available when the HPD
- is high. Some boards only let the CEC pin through if the HPD is high,
- for example if there is a level converter that uses the HPD to power
- up or down.
diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml b/Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml
index 8d844f4312d1..b1fab53418f9 100644
--- a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml
+++ b/Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/amlogic,meson-gx-ao-cec.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/cec/amlogic,meson-gx-ao-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson AO-CEC Controller
@@ -33,11 +33,8 @@ properties:
interrupts:
maxItems: 1
- hdmi-phandle:
- description: phandle to the HDMI controller
- $ref: /schemas/types.yaml#/definitions/phandle
-
allOf:
+ - $ref: cec-common.yaml#
- if:
properties:
compatible:
@@ -81,7 +78,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/media/cec/cec-common.yaml b/Documentation/devicetree/bindings/media/cec/cec-common.yaml
new file mode 100644
index 000000000000..6d5017d9bf55
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/cec-common.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/cec-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HDMI CEC Adapters Common Properties
+
+maintainers:
+ - Hans Verkuil <hverkuil@kernel.org>
+
+properties:
+ $nodename:
+ pattern: "^cec(@[0-9a-f]+|-[0-9]+)?$"
+
+ hdmi-phandle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the HDMI controller.
+
+ needs-hpd:
+ type: boolean
+ description:
+ The CEC support is only available when the HPD is high. Some boards only
+ let the CEC pin through if the HPD is high, for example if there is a
+ level converter that uses the HPD to power up or down.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
new file mode 100644
index 000000000000..582c6c9cae48
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/cec-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HDMI CEC GPIO
+
+maintainers:
+ - Hans Verkuil <hverkuil@kernel.org>
+
+description: |
+ The HDMI CEC GPIO module supports CEC implementations where the CEC line is
+ hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
+ to another GPIO line.
+
+ Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
+ 5V lines it is 5.3V. So you may need some sort of level conversion
+ circuitry when connecting them to a GPIO line.
+
+properties:
+ compatible:
+ const: cec-gpio
+
+ cec-gpios:
+ maxItems: 1
+ description:
+ GPIO that the CEC line is connected to. The line should be tagged as open
+ drain.
+
+ hpd-gpios:
+ maxItems: 1
+ description:
+ GPIO that the HPD line is connected to. Used for debugging HPD changes
+ when the CEC line is not associated with an HDMI receiver/transmitter.
+
+ v5-gpios:
+ maxItems: 1
+ description:
+ GPIO that the 5V line is connected to. Used for debugging changes on the
+ 5V line.
+
+required:
+ - compatible
+ - cec-gpios
+
+allOf:
+ - $ref: cec-common.yaml#
+ - if:
+ required:
+ - hdmi-phandle
+ then:
+ properties:
+ hpd-gpios: false
+
+ - if:
+ required:
+ - hpd-gpios
+ then:
+ properties:
+ hdmi-phandle: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ cec {
+ compatible = "cec-gpio";
+ cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
new file mode 100644
index 000000000000..6ef545b1d622
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/nvidia,tegra114-cec.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/nvidia,tegra114-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra HDMI CEC
+
+maintainers:
+ - Hans Verkuil <hverkuil@kernel.org>
+
+allOf:
+ - $ref: cec-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra114-cec
+ - nvidia,tegra124-cec
+ - nvidia,tegra210-cec
+ - items:
+ - enum:
+ - nvidia,tegra186-cec
+ - nvidia,tegra194-cec
+ - const: nvidia,tegra210-cec
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cec
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - hdmi-phandle
+ - interrupts
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ cec@70015000 {
+ compatible = "nvidia,tegra124-cec";
+ reg = <0x70015000 0x00001000>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_CEC>;
+ clock-names = "cec";
+ hdmi-phandle = <&hdmi>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml b/Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml
new file mode 100644
index 000000000000..016c8a77c1a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/samsung,s5p-cec.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/samsung,s5p-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5PV210 and Exynos HDMI CEC
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+
+allOf:
+ - $ref: cec-common.yaml#
+
+properties:
+ compatible:
+ const: samsung,s5p-cec
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: hdmicec
+
+ interrupts:
+ maxItems: 1
+
+ samsung,syscon-phandle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to PMU system controller interface
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - hdmi-phandle
+ - interrupts
+ - samsung,syscon-phandle
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos5420.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ cec@101b0000 {
+ compatible = "samsung,s5p-cec";
+ reg = <0x101B0000 0x200>;
+
+ clocks = <&clock CLK_HDMI_CEC>;
+ clock-names = "hdmicec";
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ hdmi-phandle = <&hdmi>;
+ needs-hpd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ };
diff --git a/Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml
new file mode 100644
index 000000000000..aeddf16ed339
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec/st,stih-cec.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cec/st,stih-cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STIH4xx HDMI CEC
+
+maintainers:
+ - Alain Volmat <alain.volmat@foss.st.com>
+
+allOf:
+ - $ref: cec-common.yaml#
+
+properties:
+ compatible:
+ const: st,stih-cec
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cec-clk
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: cec-irq
+
+ resets:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - hdmi-phandle
+ - interrupts
+ - resets
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/stih407-resets.h>
+
+ cec@94a087c {
+ compatible = "st,stih-cec";
+ reg = <0x94a087c 0x64>;
+
+ clocks = <&clk_sysin>;
+ clock-names = "cec-clk";
+ hdmi-phandle = <&sti_hdmi>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "cec-irq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cec0_default>;
+ resets = <&softreset STIH407_LPM_SOFTRESET>;
+ };
diff --git a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
index 77144cc6f7db..1d930d9e10fd 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml
+++ b/Documentation/devicetree/bindings/media/cec/st,stm32-cec.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/media/st,stm32-cec.yaml#
+$id: http://devicetree.org/schemas/media/cec/st,stm32-cec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 CEC bindings
+title: STMicroelectronics STM32 CEC
maintainers:
- Yannick Fertre <yannick.fertre@foss.st.com>
@@ -29,6 +29,10 @@ properties:
- const: cec
- const: hdmi-cec
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/cnm,wave521c.yaml b/Documentation/devicetree/bindings/media/cnm,wave521c.yaml
new file mode 100644
index 000000000000..6a11c1d11fb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cnm,wave521c.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/cnm,wave521c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Chips&Media Wave 5 Series multi-standard codec IP
+
+maintainers:
+ - Nas Chung <nas.chung@chipsnmedia.com>
+ - Jackson Lee <jackson.lee@chipsnmedia.com>
+
+description:
+ The Chips&Media WAVE codec IP is a multi format video encoder/decoder
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ti,j721s2-wave521c
+ - const: cnm,wave521c
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: VCODEC clock
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The VPU uses the SRAM to store some of the reference data instead of
+ storing it on DMA memory. It is mainly used for the purpose of reducing
+ bandwidth.
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ vpu: video-codec@12345678 {
+ compatible = "ti,j721s2-wave521c", "cnm,wave521c";
+ reg = <0x12345678 0x1000>;
+ clocks = <&clks 42>;
+ interrupts = <42>;
+ sram = <&sram>;
+ };
diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
deleted file mode 100644
index 0bf6fb7fbeab..000000000000
--- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
-
-Required properties:
-
-- compatible : should be one of:
- "samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs,
- "samsung,exynos5250-fimc-lite" for Exynos5250 compatible
- devices;
-- reg : physical base address and size of the device memory mapped
- registers;
-- interrupts : should contain FIMC-LITE interrupt;
-- clocks : FIMC LITE gate clock should be specified in this property.
-- clock-names : should contain "flite" entry.
-
-Each FIMC device should have an alias in the aliases node, in the form of
-fimc-lite<n>, where <n> is an integer specifying the IP block instance.
diff --git a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt
deleted file mode 100644
index 32ced99d4244..000000000000
--- a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Exynos4x12 SoC series Imaging Subsystem (FIMC-IS)
-
-The FIMC-IS is a subsystem for processing image signal from an image sensor.
-The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5
-processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C
-and SPI bus controllers, PWM and ADC.
-
-fimc-is node
-------------
-
-Required properties:
-- compatible : should be "samsung,exynos4212-fimc-is" for Exynos4212 and
- Exynos4412 SoCs;
-- reg : physical base address and length of the registers set;
-- interrupts : must contain two FIMC-IS interrupts, in order: ISP0, ISP1;
-- clocks : list of clock specifiers, corresponding to entries in
- clock-names property;
-- clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1"
- "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "gicisp",
- "pwm_isp", "mcuctl_isp", "uart", "ispdiv0", "ispdiv1",
- "mcuispdiv0", "mcuispdiv1", "aclk200", "div_aclk200",
- "aclk400mcuisp", "div_aclk400mcuisp" entries,
- matching entries in the clocks property.
-pmu subnode
------------
-
-Required properties:
- - reg : must contain PMU physical base address and size of the register set.
-
-The following are the FIMC-IS peripheral device nodes and can be specified
-either standalone or as the fimc-is node child nodes.
-
-i2c-isp (ISP I2C bus controller) nodes
-------------------------------------------
-
-Required properties:
-
-- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and
- Exynos4412 SoCs;
-- reg : physical base address and length of the registers set;
-- clocks : must contain gate clock specifier for this controller;
-- clock-names : must contain "i2c_isp" entry.
-
-For the above nodes it is required to specify a pinctrl state named "default",
-according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
-
-Device tree nodes of the image sensors' controlled directly by the FIMC-IS
-firmware must be child nodes of their corresponding ISP I2C bus controller node.
-The data link of these image sensors must be specified using the common video
-interfaces bindings, defined in video-interfaces.txt.
diff --git a/Documentation/devicetree/bindings/media/fsl,imx-capture-subsystem.yaml b/Documentation/devicetree/bindings/media/fsl,imx-capture-subsystem.yaml
new file mode 100644
index 000000000000..25e65a344a0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx-capture-subsystem.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx-capture-subsystem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX Media Video Device
+
+description:
+ This is the media controller node for video capture support. It is a
+ virtual device that lists the camera serial interface nodes that the
+ media device will control
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx-capture-subsystem
+
+ ports:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Should contain a list of phandles pointing to camera
+ sensor interface ports of IPU devices.
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ capture-subsystem {
+ compatible = "fsl,imx-capture-subsystem";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>;
+ };
diff --git a/Documentation/devicetree/bindings/media/fsl,imx6-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/fsl,imx6-mipi-csi2.yaml
new file mode 100644
index 000000000000..65255f576f26
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx6-mipi-csi2.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx6-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI CSI-2 Receiver core in the i.MX SoC
+
+description:
+ This is the device node for the MIPI CSI-2 Receiver core in the i.MX
+ SoC. This is a Synopsys Designware MIPI CSI-2 host controller core
+ combined with a D-PHY core mixed into the same register block. In
+ addition this device consists of an i.MX-specific "CSI2IPU gasket"
+ glue logic, also controlled from the same register block. The CSI2IPU
+ gasket demultiplexes the four virtual channel streams from the host
+ controller's 32-bit output image bus onto four 16-bit parallel busses
+ to the i.MX IPU CSIs.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6-mipi-csi2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: hsi_tx (the D-PHY clock)
+ - description: video_27m (D-PHY PLL reference clock)
+ - description: eim_podf;
+
+ clock-names:
+ items:
+ - const: dphy
+ - const: ref
+ - const: pix
+
+ interrupts:
+ items:
+ - description: CSI-2 ERR1 irq
+ - description: CSI-2 ERR2 irq
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ const: 0
+
+ data-lanes:
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+
+patternProperties:
+ '^port@[1-4]$':
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ ports 1 through 4 are output ports connecting with parallel bus sink
+ endpoint nodes and correspond to the four MIPI CSI-2 virtual channel
+ outputs.
+
+ properties:
+ endpoint@0:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ endpoint@1:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+
+ mipi@21dc000 {
+ compatible = "fsl,imx6-mipi-csi2";
+ reg = <0x021dc000 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clks IMX6QDL_CLK_HSI_TX>,
+ <&clks IMX6QDL_CLK_VIDEO_27M>,
+ <&clks IMX6QDL_CLK_EIM_PODF>;
+ clock-names = "dphy", "ref", "pix";
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&ov5640_to_mipi_csi2>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc0>;
+ };
+
+ endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/fsl,imx6q-vdoa.yaml b/Documentation/devicetree/bindings/media/fsl,imx6q-vdoa.yaml
new file mode 100644
index 000000000000..988a5b3a62bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx6q-vdoa.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx6q-vdoa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Video Data Order Adapter
+
+description:
+ The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+ is to reorder video data from the macroblock tiled order produced by the CODA
+ 960 VPU to the conventional raster-scan order for scanout.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx6q-vdoa
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+
+ vdoa@21e4000 {
+ compatible = "fsl,imx6q-vdoa";
+ reg = <0x021e4000 0x4000>;
+ interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_VDOA>;
+ };
diff --git a/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml b/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml
new file mode 100644
index 000000000000..3f47744459aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx6ull-pxp.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx6ull-pxp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Pixel Pipeline
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+ - Michael Tretter <m.tretter@pengutronix.de>
+
+description:
+ The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine
+ that supports scaling, colorspace conversion, alpha blending, rotation, and
+ pixel conversion via lookup table. Different versions are present on various
+ i.MX SoCs from i.MX23 to i.MX7.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx6ul-pxp
+ - fsl,imx6ull-pxp
+ - fsl,imx7d-pxp
+ - items:
+ - enum:
+ - fsl,imx6sll-pxp
+ - fsl,imx6sx-pxp
+ - const: fsl,imx6ull-pxp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: axi
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sx-pxp
+ - fsl,imx6ul-pxp
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ else:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6ul-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pxp: pxp@21cc000 {
+ compatible = "fsl,imx6ull-pxp";
+ reg = <0x021cc000 0x4000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "axi";
+ clocks = <&clks IMX6UL_CLK_PXP>;
+ };
diff --git a/Documentation/devicetree/bindings/media/fsl,imx8qm-isi.yaml b/Documentation/devicetree/bindings/media/fsl,imx8qm-isi.yaml
new file mode 100644
index 000000000000..93f527e223af
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx8qm-isi.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx8qm-isi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX8QM Image Sensing Interface
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Image Sensing Interface (ISI) combines image processing pipelines with
+ DMA engines to process and capture frames originating from a variety of
+ sources. The inputs to the ISI go through Pixel Link interfaces, and their
+ number and nature is SoC-dependent. They cover both capture interfaces (MIPI
+ CSI-2 RX, HDMI RX, ...) and display engine outputs for writeback support.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qm-isi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 8
+
+ clock-names:
+ items:
+ - const: per0
+ - const: per1
+ - const: per2
+ - const: per3
+ - const: per4
+ - const: per5
+ - const: per6
+ - const: per7
+
+ interrupts:
+ maxItems: 8
+
+ power-domains:
+ maxItems: 8
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: MIPI CSI-2 RX 0
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: MIPI CSI-2 RX 1
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: HDMI RX
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ image-controller@58100000 {
+ compatible = "fsl,imx8qm-isi";
+ reg = <0x58100000 0x80000>;
+ interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pdma0_lpcg IMX_LPCG_CLK_0>,
+ <&pdma1_lpcg IMX_LPCG_CLK_0>,
+ <&pdma2_lpcg IMX_LPCG_CLK_0>,
+ <&pdma3_lpcg IMX_LPCG_CLK_0>,
+ <&pdma4_lpcg IMX_LPCG_CLK_0>,
+ <&pdma5_lpcg IMX_LPCG_CLK_0>,
+ <&pdma6_lpcg IMX_LPCG_CLK_0>,
+ <&pdma7_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "per0", "per1", "per2", "per3",
+ "per4", "per5", "per6", "per7";
+ power-domains = <&pd IMX_SC_R_ISI_CH0>, <&pd IMX_SC_R_ISI_CH1>,
+ <&pd IMX_SC_R_ISI_CH2>, <&pd IMX_SC_R_ISI_CH3>,
+ <&pd IMX_SC_R_ISI_CH4>, <&pd IMX_SC_R_ISI_CH5>,
+ <&pd IMX_SC_R_ISI_CH6>, <&pd IMX_SC_R_ISI_CH7>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@2 {
+ reg = <2>;
+ endpoint {
+ remote-endpoint = <&mipi_csi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/fsl,imx8qxp-isi.yaml b/Documentation/devicetree/bindings/media/fsl,imx8qxp-isi.yaml
new file mode 100644
index 000000000000..bb41996bd2e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl,imx8qxp-isi.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/fsl,imx8qxp-isi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX8QXP Image Sensing Interface
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Image Sensing Interface (ISI) combines image processing pipelines with
+ DMA engines to process and capture frames originating from a variety of
+ sources. The inputs to the ISI go through Pixel Link interfaces, and their
+ number and nature is SoC-dependent. They cover both capture interfaces (MIPI
+ CSI-2 RX, HDMI RX, ...) and display engine outputs for writeback support.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-isi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: per0
+ - const: per1
+ - const: per2
+ - const: per3
+ - const: per4
+ - const: per5
+
+ interrupts:
+ maxItems: 6
+
+ power-domains:
+ maxItems: 6
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: MIPI CSI-2 RX 0
+ port@6:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CSI-2 Parallel RX
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+
+ image-controller@58100000 {
+ compatible = "fsl,imx8qxp-isi";
+ reg = <0x58100000 0x60000>;
+ interrupts = <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pdma0_lpcg IMX_LPCG_CLK_0>,
+ <&pdma1_lpcg IMX_LPCG_CLK_0>,
+ <&pdma2_lpcg IMX_LPCG_CLK_0>,
+ <&pdma3_lpcg IMX_LPCG_CLK_0>,
+ <&pdma4_lpcg IMX_LPCG_CLK_0>,
+ <&pdma5_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "per0", "per1", "per2", "per3", "per4", "per5";
+ power-domains = <&pd IMX_SC_R_ISI_CH0>, <&pd IMX_SC_R_ISI_CH1>,
+ <&pd IMX_SC_R_ISI_CH2>, <&pd IMX_SC_R_ISI_CH3>,
+ <&pd IMX_SC_R_ISI_CH4>, <&pd IMX_SC_R_ISI_CH5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@2 {
+ reg = <2>;
+ endpoint {
+ remote-endpoint = <&mipi_csi0_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/fsl-pxp.txt b/Documentation/devicetree/bindings/media/fsl-pxp.txt
deleted file mode 100644
index f8090e06530d..000000000000
--- a/Documentation/devicetree/bindings/media/fsl-pxp.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Freescale Pixel Pipeline
-========================
-
-The Pixel Pipeline (PXP) is a memory-to-memory graphics processing engine
-that supports scaling, colorspace conversion, alpha blending, rotation, and
-pixel conversion via lookup table. Different versions are present on various
-i.MX SoCs from i.MX23 to i.MX7.
-
-Required properties:
-- compatible: should be "fsl,<soc>-pxp", where SoC can be one of imx23, imx28,
- imx6dl, imx6sl, imx6sll, imx6ul, imx6sx, imx6ull, or imx7d.
-- reg: the register base and size for the device registers
-- interrupts: the PXP interrupt, two interrupts for imx6ull and imx7d.
-- clock-names: should be "axi"
-- clocks: the PXP AXI clock
-
-Example:
-
-pxp@21cc000 {
- compatible = "fsl,imx6ull-pxp";
- reg = <0x021cc000 0x4000>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "axi";
- clocks = <&clks IMX6UL_CLK_PXP>;
-};
diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
deleted file mode 100644
index 6c5628530bb7..000000000000
--- a/Documentation/devicetree/bindings/media/fsl-vdoa.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Freescale Video Data Order Adapter
-==================================
-
-The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
-is to reorder video data from the macroblock tiled order produced by the CODA
-960 VPU to the conventional raster-scan order for scanout.
-
-Required properties:
-- compatible: must be "fsl,imx6q-vdoa"
-- reg: the register base and size for the device registers
-- interrupts: the VDOA interrupt
-- clocks: the vdoa clock
-
-Example:
-
-vdoa@21e4000 {
- compatible = "fsl,imx6q-vdoa";
- reg = <0x021e4000 0x4000>;
- interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6QDL_CLK_VDOA>;
-};
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml
index 61072745b983..008c007ed702 100644
--- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml
@@ -23,6 +23,9 @@ properties:
description: autosuspend delay time in milliseconds
$ref: /schemas/types.yaml#/definitions/uint32
+ wakeup-source:
+ description: IR receiver can wake-up the system.
+
required:
- compatible
- gpios
diff --git a/Documentation/devicetree/bindings/media/i2c/ad5820.txt b/Documentation/devicetree/bindings/media/i2c/ad5820.txt
deleted file mode 100644
index 5764cbedf9b7..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ad5820.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Analog Devices AD5820 autofocus coil
-
-Required Properties:
-
- - compatible: Must contain one of:
- - "adi,ad5820"
- - "adi,ad5821"
- - "adi,ad5823"
-
- - reg: I2C slave address
-
- - VANA-supply: supply of voltage for VANA pin
-
-Optional properties:
-
- - enable-gpios : GPIO spec for the XSHUTDOWN pin. The XSHUTDOWN signal is
-active low, a high level on the pin enables the device.
-
-Example:
-
- ad5820: coil@c {
- compatible = "adi,ad5820";
- reg = <0x0c>;
-
- VANA-supply = <&vaux4>;
- enable-gpios = <&msmgpio 26 GPIO_ACTIVE_HIGH>;
- };
-
diff --git a/Documentation/devicetree/bindings/media/i2c/adi,ad5820.yaml b/Documentation/devicetree/bindings/media/i2c/adi,ad5820.yaml
new file mode 100644
index 000000000000..0c8f24f692ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adi,ad5820.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/adi,ad5820.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5820 autofocus coil
+
+maintainers:
+ - Pavel Machek <pavel@ucw.cz>
+
+description:
+ The AD5820 is a current sink driver designed for precise control of
+ voice coil motors (VCMs) in camera autofocus systems.
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5820
+ - adi,ad5821
+ - adi,ad5823
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO spec for the XSHUTDOWN pin. The XSHUTDOWN signal is active low,
+ a high level on the pin enables the device.
+
+ VANA-supply:
+ description: supply of voltage for VANA pin
+
+required:
+ - compatible
+ - reg
+ - VANA-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ coil@c {
+ compatible = "adi,ad5820";
+ reg = <0x0c>;
+
+ enable-gpios = <&msmgpio 26 GPIO_ACTIVE_HIGH>;
+ VANA-supply = <&vaux4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt b/Documentation/devicetree/bindings/media/i2c/adi,adp1653.txt
index 4cce0de40ee9..4cce0de40ee9 100644
--- a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adi,adp1653.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adi,adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adi,adv7180.yaml
new file mode 100644
index 000000000000..dee8ce7cb7ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adi,adv7180.yaml
@@ -0,0 +1,189 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/adi,adv7180.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7180 analog video decoder family
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+description:
+ The adv7180 family devices are used to capture analog video to different
+ digital interfaces like MIPI CSI-2 or parallel video.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - adi,adv7180
+ - adi,adv7180cp
+ - adi,adv7180st
+ - adi,adv7182
+ - adi,adv7280
+ - adi,adv7280-m
+ - adi,adv7281
+ - adi,adv7281-m
+ - adi,adv7281-ma
+ - adi,adv7282
+ - adi,adv7282-m
+
+ reg:
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ adv,force-bt656-4:
+ deprecated: true
+ description:
+ Indicates that the output is a BT.656-4 compatible stream.
+ type: boolean
+
+ adi,force-bt656-4:
+ description:
+ Indicates that the output is a BT.656-4 compatible stream.
+ type: boolean
+
+ interrupts:
+ items:
+ - description: The GPIO connected to the INTRQ pin.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ ports: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - adi,adv7180
+ - adi,adv7182
+ - adi,adv7280
+ - adi,adv7280-m
+ - adi,adv7281
+ - adi,adv7281-m
+ - adi,adv7281-ma
+ - adi,adv7282
+ - adi,adv7282-m
+ then:
+ required:
+ - port
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7180cp
+ then:
+ properties:
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output port
+
+ patternProperties:
+ "^port@[0-2]$":
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port
+
+ required:
+ - port@3
+
+ required:
+ - ports
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7180st
+ then:
+ properties:
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@6:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output port
+
+ patternProperties:
+ "^port@[0-5]$":
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port
+
+ required:
+ - port@6
+
+ required:
+ - ports
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ composite-in@20 {
+ compatible = "adi,adv7180";
+ reg = <0x20>;
+
+ port {
+ adv7180: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&vin1ep>;
+ };
+ };
+ };
+
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ composite-in@20 {
+ compatible = "adi,adv7180cp";
+ reg = <0x20>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7180_in: endpoint {
+ remote-endpoint = <&composite_con_in>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ adv7180_out: endpoint {
+ remote-endpoint = <&vin4_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt b/Documentation/devicetree/bindings/media/i2c/adi,adv7343.txt
index 5653bc2428b8..5653bc2428b8 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7343.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adi,adv7343.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adi,adv748x.yaml b/Documentation/devicetree/bindings/media/i2c/adi,adv748x.yaml
new file mode 100644
index 000000000000..254987350321
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adi,adv748x.yaml
@@ -0,0 +1,212 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/adi,adv748x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV748X video decoder with HDMI receiver
+
+maintainers:
+ - Kieran Bingham <kieran.bingham@ideasonboard.com>
+ - Niklas Söderlund <niklas.soderlund@ragnatech.se>
+
+description:
+ The ADV7481 and ADV7482 are multi format video decoders with an integrated
+ HDMI receiver. They can output CSI-2 on two independent outputs TXA and TXB
+ from three input sources HDMI, analog and TTL.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - adi,adv7481
+ - adi,adv7482
+
+ reg:
+ minItems: 1
+ maxItems: 12
+ description:
+ The ADV748x has up to twelve 256-byte maps that can be accessed via the
+ main I2C ports. Each map has it own I2C address and acts as a standard
+ slave device on the I2C bus. The main address is mandatory, others are
+ optional and remain at default values if not specified.
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: main
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+ - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
+
+ interrupts: true
+
+ interrupt-names: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ "^port@[0-7]$":
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port nodes for analog inputs AIN[0-7].
+
+ properties:
+ port@8:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port node for HDMI.
+
+ port@9:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port node for TTL.
+
+ port@a:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter TXA.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@b:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter TXB.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ maxItems: 1
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7481
+ then:
+ properties:
+ interrupts:
+ minItems: 1
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [ intrq1, intrq2, intrq3 ]
+ else:
+ properties:
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ intrq1, intrq2 ]
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ports
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ video-receiver@70 {
+ compatible = "adi,adv7482";
+ reg = <0x70 0x71 0x72 0x73 0x74 0x75
+ 0x60 0x61 0x62 0x63 0x64 0x65>;
+ reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater",
+ "infoframe", "cbus", "cec", "sdp", "txa", "txb";
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>, <31 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "intrq1", "intrq2";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@7 {
+ reg = <7>;
+
+ adv7482_ain7: endpoint {
+ remote-endpoint = <&cvbs_in>;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+
+ adv7482_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+
+ port@a {
+ reg = <10>;
+
+ adv7482_txa: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csi40_in>;
+ };
+ };
+
+ port@b {
+ reg = <11>;
+
+ adv7482_txb: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ remote-endpoint = <&csi20_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/adi,adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adi,adv7604.yaml
new file mode 100644
index 000000000000..f8d9889dbc21
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adi,adv7604.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/adi,adv7604.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7604/10/11/12 video decoder with HDMI receiver
+
+maintainers:
+ - Hans Verkuil <hverkuil@kernel.org>
+
+description:
+ The ADV7604 and ADV7610/11/12 are multiformat video decoders with
+ an integrated HDMI receiver. The ADV7604 has four multiplexed HDMI inputs
+ and one analog input, and the ADV7610/11 have one HDMI input and no analog
+ input. The ADV7612 is similar to the ADV7610/11 but has 2 HDMI inputs.
+
+ These device tree bindings support the ADV7610/11/12 only at the moment.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - adi,adv7610
+ - adi,adv7611
+ - adi,adv7612
+
+ reg:
+ minItems: 1
+ maxItems: 13
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: main
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+ - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ hpd-gpios:
+ minItems: 1
+ description:
+ References to the GPIOs that control the HDMI hot-plug detection pins,
+ one per HDMI input. The active flag indicates the GPIO level that
+ enables hot-plug detection.
+
+ default-input:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Select which input is selected after reset.
+
+ ports: true
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7611
+ then:
+ properties:
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output port
+
+ required:
+ - port@1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adv7612
+ then:
+ properties:
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output port
+
+ patternProperties:
+ "^port@[0-1]$":
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port
+
+ required:
+ - port@2
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_receiver@4c {
+ compatible = "adi,adv7611";
+ /*
+ * The edid page will be accessible @ 0x66 on the I2C bus. All
+ * other maps will retain their default addresses.
+ */
+ reg = <0x4c>, <0x66>;
+ reg-names = "main", "edid";
+
+ reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
+ hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
+ default-input = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_in: endpoint {
+ remote-endpoint = <&ccdc_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
deleted file mode 100644
index c8d887eee3bb..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
+++ /dev/null
@@ -1,179 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/media/i2c/adv7180.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Analog Devices ADV7180 analog video decoder family
-
-maintainers:
- - Lars-Peter Clausen <lars@metafoo.de>
-
-description:
- The adv7180 family devices are used to capture analog video to different
- digital interfaces like MIPI CSI-2 or parallel video.
-
-properties:
- compatible:
- items:
- - enum:
- - adi,adv7180
- - adi,adv7180cp
- - adi,adv7180st
- - adi,adv7182
- - adi,adv7280
- - adi,adv7280-m
- - adi,adv7281
- - adi,adv7281-m
- - adi,adv7281-ma
- - adi,adv7282
- - adi,adv7282-m
-
- reg:
- maxItems: 1
-
- powerdown-gpios:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
- adv,force-bt656-4:
- description:
- Indicates that the output is a BT.656-4 compatible stream.
- type: boolean
-
- port:
- $ref: /schemas/graph.yaml#/$defs/port-base
- unevaluatedProperties: false
-
- properties:
- endpoint:
- $ref: /schemas/media/video-interfaces.yaml#
- unevaluatedProperties: false
-
- ports: true
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
-
-allOf:
- - if:
- properties:
- compatible:
- enum:
- - adi,adv7180
- - adi,adv7182
- - adi,adv7280
- - adi,adv7280-m
- - adi,adv7281
- - adi,adv7281-m
- - adi,adv7281-ma
- - adi,adv7282
- - adi,adv7282-m
- then:
- required:
- - port
-
- - if:
- properties:
- compatible:
- contains:
- const: adi,adv7180cp
- then:
- properties:
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- properties:
- port@3:
- $ref: /schemas/graph.yaml#/properties/port
- description: Output port
-
- patternProperties:
- "^port@[0-2]$":
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port
-
- required:
- - port@3
-
- required:
- - ports
-
- - if:
- properties:
- compatible:
- contains:
- const: adi,adv7180st
- then:
- properties:
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- properties:
- port@6:
- $ref: /schemas/graph.yaml#/properties/port
- description: Output port
-
- patternProperties:
- "^port@[0-5]$":
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port
-
- required:
- - port@6
-
- required:
- - ports
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- composite-in@20 {
- compatible = "adi,adv7180";
- reg = <0x20>;
-
- port {
- adv7180: endpoint {
- bus-width = <8>;
- remote-endpoint = <&vin1ep>;
- };
- };
- };
-
- };
-
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- composite-in@20 {
- compatible = "adi,adv7180cp";
- reg = <0x20>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- adv7180_in: endpoint {
- remote-endpoint = <&composite_con_in>;
- };
- };
-
- port@3 {
- reg = <3>;
- adv7180_out: endpoint {
- remote-endpoint = <&vin4_in>;
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.yaml b/Documentation/devicetree/bindings/media/i2c/adv748x.yaml
deleted file mode 100644
index d6353081402b..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/adv748x.yaml
+++ /dev/null
@@ -1,212 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/media/i2c/adv748x.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Analog Devices ADV748X video decoder with HDMI receiver
-
-maintainers:
- - Kieran Bingham <kieran.bingham@ideasonboard.com>
- - Niklas Söderlund <niklas.soderlund@ragnatech.se>
-
-description:
- The ADV7481 and ADV7482 are multi format video decoders with an integrated
- HDMI receiver. They can output CSI-2 on two independent outputs TXA and TXB
- from three input sources HDMI, analog and TTL.
-
-properties:
- compatible:
- items:
- - enum:
- - adi,adv7481
- - adi,adv7482
-
- reg:
- minItems: 1
- maxItems: 12
- description:
- The ADV748x has up to twelve 256-byte maps that can be accessed via the
- main I2C ports. Each map has it own I2C address and acts as a standard
- slave device on the I2C bus. The main address is mandatory, others are
- optional and remain at default values if not specified.
-
- reg-names:
- minItems: 1
- items:
- - const: main
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
- - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ]
-
- interrupts: true
-
- interrupt-names: true
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
-
- patternProperties:
- "^port@[0-7]$":
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port nodes for analog inputs AIN[0-7].
-
- properties:
- port@8:
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port node for HDMI.
-
- port@9:
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port node for TTL.
-
- port@a:
- $ref: /schemas/graph.yaml#/$defs/port-base
- unevaluatedProperties: false
- description:
- Output port node, single endpoint describing the CSI-2 transmitter TXA.
-
- properties:
- endpoint:
- $ref: /schemas/media/video-interfaces.yaml#
- unevaluatedProperties: false
-
- properties:
- clock-lanes:
- maxItems: 1
-
- data-lanes:
- minItems: 1
- maxItems: 4
-
- required:
- - clock-lanes
- - data-lanes
-
- port@b:
- $ref: /schemas/graph.yaml#/$defs/port-base
- unevaluatedProperties: false
- description:
- Output port node, single endpoint describing the CSI-2 transmitter TXB.
-
- properties:
- endpoint:
- $ref: /schemas/media/video-interfaces.yaml#
- unevaluatedProperties: false
-
- properties:
- clock-lanes:
- maxItems: 1
-
- data-lanes:
- maxItems: 1
-
- required:
- - clock-lanes
- - data-lanes
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- const: adi,adv7481
- then:
- properties:
- interrupts:
- minItems: 1
- maxItems: 3
-
- interrupt-names:
- minItems: 1
- maxItems: 3
- items:
- enum: [ intrq1, intrq2, intrq3 ]
- else:
- properties:
- interrupts:
- minItems: 1
- maxItems: 2
-
- interrupt-names:
- minItems: 1
- maxItems: 2
- items:
- enum: [ intrq1, intrq2 ]
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
- - ports
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- video-receiver@70 {
- compatible = "adi,adv7482";
- reg = <0x70 0x71 0x72 0x73 0x74 0x75
- 0x60 0x61 0x62 0x63 0x64 0x65>;
- reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater",
- "infoframe", "cbus", "cec", "sdp", "txa", "txb";
-
- interrupt-parent = <&gpio6>;
- interrupts = <30 IRQ_TYPE_LEVEL_LOW>, <31 IRQ_TYPE_LEVEL_LOW>;
- interrupt-names = "intrq1", "intrq2";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@7 {
- reg = <7>;
-
- adv7482_ain7: endpoint {
- remote-endpoint = <&cvbs_in>;
- };
- };
-
- port@8 {
- reg = <8>;
-
- adv7482_hdmi: endpoint {
- remote-endpoint = <&hdmi_in>;
- };
- };
-
- port@a {
- reg = <10>;
-
- adv7482_txa: endpoint {
- clock-lanes = <0>;
- data-lanes = <1 2 3 4>;
- remote-endpoint = <&csi40_in>;
- };
- };
-
- port@b {
- reg = <11>;
-
- adv7482_txb: endpoint {
- clock-lanes = <0>;
- data-lanes = <1>;
- remote-endpoint = <&csi20_in>;
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
deleted file mode 100644
index 7589d377c686..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
+++ /dev/null
@@ -1,160 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/media/i2c/adv7604.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Analog Devices ADV7604/10/11/12 video decoder with HDMI receiver
-
-maintainers:
- - Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
-description:
- The ADV7604 and ADV7610/11/12 are multiformat video decoders with
- an integrated HDMI receiver. The ADV7604 has four multiplexed HDMI inputs
- and one analog input, and the ADV7610/11 have one HDMI input and no analog
- input. The ADV7612 is similar to the ADV7610/11 but has 2 HDMI inputs.
-
- These device tree bindings support the ADV7610/11/12 only at the moment.
-
-properties:
- compatible:
- items:
- - enum:
- - adi,adv7610
- - adi,adv7611
- - adi,adv7612
-
- reg:
- minItems: 1
- maxItems: 13
-
- reg-names:
- minItems: 1
- items:
- - const: main
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
-
- interrupts:
- maxItems: 1
-
- reset-gpios:
- maxItems: 1
-
- hpd-gpios:
- minItems: 1
- description:
- References to the GPIOs that control the HDMI hot-plug detection pins,
- one per HDMI input. The active flag indicates the GPIO level that
- enables hot-plug detection.
-
- default-input:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
- description:
- Select which input is selected after reset.
-
- ports: true
-
-required:
- - compatible
- - reg
- - ports
-
-additionalProperties: false
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- const: adi,adv7611
- then:
- properties:
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- properties:
- port@0:
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port
-
- port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description: Output port
-
- required:
- - port@1
-
- - if:
- properties:
- compatible:
- contains:
- const: adi,adv7612
- then:
- properties:
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- properties:
- port@2:
- $ref: /schemas/graph.yaml#/properties/port
- description: Output port
-
- patternProperties:
- "^port@[0-1]$":
- $ref: /schemas/graph.yaml#/properties/port
- description: Input port
-
- required:
- - port@2
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- hdmi_receiver@4c {
- compatible = "adi,adv7611";
- /*
- * The edid page will be accessible @ 0x66 on the I2C bus. All
- * other maps will retain their default addresses.
- */
- reg = <0x4c>, <0x66>;
- reg-names = "main", "edid";
-
- reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
- hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
- default-input = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- };
-
- port@1 {
- reg = <1>;
- hdmi_in: endpoint {
- remote-endpoint = <&ccdc_in>;
- };
- };
- };
-
-
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/ak7375.txt b/Documentation/devicetree/bindings/media/i2c/ak7375.txt
deleted file mode 100644
index aa3e24b41241..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ak7375.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Asahi Kasei Microdevices AK7375 voice coil lens driver
-
-AK7375 is a camera voice coil lens.
-
-Mandatory properties:
-
-- compatible: "asahi-kasei,ak7375"
-- reg: I2C slave address
diff --git a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml
new file mode 100644
index 000000000000..d3329e991d16
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/alliedvision,alvium-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allied Vision Alvium Camera
+
+maintainers:
+ - Tommaso Merciai <tomm.merciai@gmail.com>
+ - Martin Hecht <martin.hecht@avnet.eu>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: alliedvision,alvium-csi2
+
+ reg:
+ maxItems: 1
+
+ vcc-ext-in-supply:
+ description: |
+ The regulator that supplies power to the VCC_EXT_IN pins.
+
+ port:
+ description: Digital Output Port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ link-frequencies: true
+
+ data-lanes:
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - vcc-ext-in-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ alvium: camera@3c {
+ compatible = "alliedvision,alvium-csi2";
+ reg = <0x3c>;
+ vcc-ext-in-supply = <&reg_vcc_ext_in>;
+
+ port {
+ alvium_out: endpoint {
+ remote-endpoint = <&mipi_csi_0_in>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <681250000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml
index 1d6af1bf9a6b..be00de2f2d58 100644
--- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml
@@ -82,7 +82,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v032.txt
index 100f0ae43269..100f0ae43269 100644
--- a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v032.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
index e53b8d65f381..088022f88010 100644
--- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
@@ -55,7 +55,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
new file mode 100644
index 000000000000..fe312cc6a873
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/asahi-kasei,ak7375.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/asahi-kasei,ak7375.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asahi Kasei Microdevices AK7375 voice coil lens actuator
+
+maintainers:
+ - Tianshu Qiu <tian.shu.qiu@intel.com>
+
+description:
+ AK7375 is a voice coil motor (VCM) camera lens actuator that
+ is controlled over I2C.
+
+properties:
+ compatible:
+ enum:
+ - asahi-kasei,ak7345
+ - asahi-kasei,ak7375
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: VDD supply
+
+ vio-supply:
+ description: I/O pull-up supply
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ak7375: camera-lens@c {
+ compatible = "asahi-kasei,ak7375";
+ reg = <0x0c>;
+
+ vdd-supply = <&vreg_l23a_2p8>;
+ vio-supply = <&vreg_lvs1a_1p8>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
index 63e5b89d2e0b..4e69b6a7ffcc 100644
--- a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Chrontel HDMI-CEC Controller
@@ -13,6 +13,9 @@ description:
The Chrontel CH7322 is a discrete HDMI-CEC controller. It is
programmable through I2C and drives a single CEC line.
+allOf:
+ - $ref: /schemas/media/cec/cec-common.yaml#
+
properties:
compatible:
const: chrontel,ch7322
@@ -40,16 +43,12 @@ properties:
if in auto mode.
maxItems: 1
- # see ../cec.txt
- hdmi-phandle:
- description: phandle to the HDMI controller
-
required:
- compatible
- reg
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -58,7 +57,7 @@ examples:
i2c {
#address-cells = <1>;
#size-cells = <0>;
- ch7322@75 {
+ cec@75 {
compatible = "chrontel,ch7322";
reg = <0x75>;
interrupts = <47 IRQ_TYPE_EDGE_RISING>;
diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt
deleted file mode 100644
index b88dcdd41def..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-Dongwoon Anatech DW9714 camera voice coil lens driver
-
-DW9174 is a 10-bit DAC with current sink capability. It is intended
-for driving voice coil lenses in camera modules.
-
-Mandatory properties:
-
-- compatible: "dongwoon,dw9714"
-- reg: I²C slave address
diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml
new file mode 100644
index 000000000000..66229a3dc05d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9714.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dongwoon Anatech DW9714 camera voice coil lens driver
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ DW9174 is a 10-bit DAC with current sink capability. It is intended for
+ driving voice coil lenses in camera modules.
+
+properties:
+ compatible:
+ const: dongwoon,dw9714
+
+ reg:
+ maxItems: 1
+
+ powerdown-gpios:
+ description:
+ XSD pin for shutdown (active low)
+
+ vcc-supply:
+ description: VDD power supply
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera-lens@c {
+ compatible = "dongwoon,dw9714";
+ reg = <0x0c>;
+ vcc-supply = <&reg_csi_1v8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml
new file mode 100644
index 000000000000..8e8d62436e0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9719.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dongwoon Anatech DW9719 Voice Coil Motor (VCM) Controller
+
+maintainers:
+ - André Apitzsch <git@apitzsch.eu>
+
+description:
+ The Dongwoon DW9718S/9719/9761 is a single 10-bit digital-to-analog converter
+ with 100 mA output current sink capability, designed for linear control of
+ voice coil motors (VCM) in camera lenses. This chip provides a Smart Actuator
+ Control (SAC) mode intended for driving voice coil lenses in camera modules.
+
+properties:
+ compatible:
+ enum:
+ - dongwoon,dw9718s
+ - dongwoon,dw9719
+ - dongwoon,dw9761
+ - dongwoon,dw9800k
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: VDD power supply
+
+ dongwoon,sac-mode:
+ description: |
+ Slew Rate Control mode to use: direct, LSC (Linear Slope Control) or
+ SAC1-SAC6 (Smart Actuator Control).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # Direct mode
+ - 1 # LSC mode
+ - 2 # SAC1 mode (operation time# 0.32 x Tvib)
+ - 3 # SAC2 mode (operation time# 0.48 x Tvib)
+ - 4 # SAC3 mode (operation time# 0.72 x Tvib)
+ - 5 # SAC4 mode (operation time# 1.20 x Tvib)
+ - 6 # SAC5 mode (operation time# 1.64 x Tvib)
+ - 7 # SAC6 mode (operation time# 1.88 x Tvib)
+ default: 4
+
+ dongwoon,vcm-prescale:
+ description:
+ Indication of VCM switching frequency dividing rate select.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: dongwoon,dw9718s
+ then:
+ properties:
+ dongwoon,vcm-prescale:
+ description:
+ The final frequency is 10 MHz divided by (value + 2).
+ maximum: 15
+ default: 0
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ actuator@c {
+ compatible = "dongwoon,dw9718s";
+ reg = <0x0c>;
+
+ vdd-supply = <&pm8937_l17>;
+
+ dongwoon,sac-mode = <4>;
+ dongwoon,vcm-prescale = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
index 21864ab86ec4..a0855d3b7577 100644
--- a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
+title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens
maintainers:
- Dongchun Zhu <dongchun.zhu@mediatek.com>
@@ -38,7 +38,7 @@ properties:
dongwoon,aac-mode:
description:
Indication of AAC mode select.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum:
- 1 # AAC2 mode(operation time# 0.48 x Tvib)
- 2 # AAC3 mode(operation time# 0.70 x Tvib)
@@ -50,7 +50,7 @@ properties:
description:
Number of AAC Timing count that controlled by one 6-bit period of
vibration register AACT[5:0], the unit of which is 100 us.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 0x20
minimum: 0x00
maximum: 0x3f
@@ -59,7 +59,7 @@ properties:
description:
Indication of VCM internal clock dividing rate select, as one multiple
factor to calculate VCM ring periodic time Tvib.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum:
- 0 # Dividing Rate - 2
- 1 # Dividing Rate - 1
diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc0308.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc0308.yaml
new file mode 100644
index 000000000000..2bf1a81feaf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc0308.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc0308.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Galaxycore GC0308 and GC0309 Image Sensors
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description: |
+ The GalaxyCore GC0308 (1/6.5") and GC0309 (1/9") are 640x480 VGA sensors
+ programmable through an I2C interface and connected via parallel bus.
+ They include an ISP capable of auto exposure and auto white balance.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: galaxycore,gc0308
+ - items:
+ - const: galaxycore,gc0309
+ - const: galaxycore,gc0308
+
+ reg:
+ const: 0x21
+
+ clocks:
+ description: Reference to the xclk clock.
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO descriptor for the reset pin.
+ maxItems: 1
+
+ powerdown-gpios:
+ description: GPIO descriptor for the powerdown pin.
+ maxItems: 1
+
+ vdd28-supply:
+ description: 2.8V supply
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: |
+ Video output port.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-width: true
+ data-shift: true
+ hsync-active: true
+ vsync-active: true
+ data-active: true
+ pclk-sample: true
+
+ required:
+ - bus-width
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - powerdown-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera-sensor@21 {
+ compatible = "galaxycore,gc0308";
+ reg = <0x21>;
+ clocks = <&camera_clk>;
+ powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ vdd28-supply = <&vdd28>;
+
+ port {
+ gc0308_ep: endpoint {
+ remote-endpoint = <&parallel_from_gc0308>;
+ bus-width = <8>;
+ data-shift = <2>; /* lines 9:2 are used */
+ hsync-active = <1>; /* active high */
+ vsync-active = <1>; /* active high */
+ data-active = <1>; /* active high */
+ pclk-sample = <1>; /* sample on rising edge */
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml
new file mode 100644
index 000000000000..0e7a7b5ac89f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc05a2.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc05a2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GalaxyCore gc05a2 1/5" 5M Pixel MIPI CSI-2 sensor
+
+maintainers:
+ - Zhi Mao <zhi.mao@mediatek.com>
+
+description:
+ The gc05a2 is a raw image sensor with an MIPI CSI-2 image data
+ interface and CCI (I2C compatible) control bus. The output format
+ is raw Bayer.
+
+properties:
+ compatible:
+ const: galaxycore,gc05a2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dovdd-supply: true
+
+ avdd-supply: true
+
+ dvdd-supply: true
+
+ reset-gpios:
+ description: Reference to the GPIO connected to the RESETB pin.
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ - items:
+ - const: 1
+ - const: 2
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@37 {
+ compatible = "galaxycore,gc05a2";
+ reg = <0x37>;
+
+ clocks = <&gc05a2_clk>;
+
+ reset-gpios = <&pio 21 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&gc05a2_avdd>;
+ dovdd-supply = <&gc05a2_dovdd>;
+ dvdd-supply = <&gc05a2_dvdd>;
+
+ port {
+ sensor_out: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <448000000 224000000>;
+ remote-endpoint = <&seninf_csi_port_1_in>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
new file mode 100644
index 000000000000..51b8ece09c72
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc08a3.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc08a3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GalaxyCore gc08a3 1/4" 8M Pixel MIPI CSI-2 sensor
+
+maintainers:
+ - Zhi Mao <zhi.mao@mediatek.com>
+
+description:
+ The gc08a3 is a raw image sensor with an MIPI CSI-2 image data
+ interface and CCI (I2C compatible) control bus. The output format
+ is raw Bayer.
+
+properties:
+ compatible:
+ const: galaxycore,gc08a3
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dovdd-supply: true
+
+ avdd-supply: true
+
+ dvdd-supply: true
+
+ reset-gpios:
+ description: Reference to the GPIO connected to the RESETB pin.
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ - items:
+ - const: 1
+ - const: 2
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@31 {
+ compatible = "galaxycore,gc08a3";
+ reg = <0x31>;
+
+ clocks = <&gc08a3_clk>;
+
+ reset-gpios = <&pio 19 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&gc08a3_avdd>;
+ dovdd-supply = <&gc08a3_dovdd>;
+ dvdd-supply = <&gc08a3_dvdd>;
+
+ port {
+ sensor_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <336000000 207000000>;
+ remote-endpoint = <&seninf_csi_port_0_in>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml
new file mode 100644
index 000000000000..9eac588de0bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/galaxycore,gc2145.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/galaxycore,gc2145.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Galaxy Core 1/5'' UXGA CMOS Image Sensor
+
+maintainers:
+ - Alain Volmat <alain.volmat@foss.st.com>
+
+description:
+ The Galaxy Core GC2145 is a 2 Megapixel CMOS image sensor, for mobile
+ phone camera applications and digital camera products. GC2145 incorporates a
+ 1616V x 1232H active pixel array, on-chip 10-bit ADC, and image signal
+ processor allowing AE/AWB/interpolation/de-noise/color-conversion and
+ gamma correction. Bayer RGB, RGB565 and YCbCr 4:2:2 can be provided by the
+ sensor. It is programmable through an I2C interface. Image data is sent
+ either through a parallel interface or through MIPI CSI-2.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: galaxycore,gc2145
+
+ reg:
+ const: 0x3c
+
+ clocks:
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ iovdd-supply:
+ description: Power Supply for I/O circuits (1.7 - 3V).
+
+ avdd-supply:
+ description: Power for analog circuit/sensor array (2.7 - 3V).
+
+ dvdd-supply:
+ description: Power for digital core (1.7 - 1.9V).
+
+ orientation: true
+
+ rotation: true
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ link-frequencies: true
+
+ required:
+ - link-frequencies
+
+ required:
+ - endpoint
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - powerdown-gpios
+ - reset-gpios
+ - iovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@3c {
+ compatible = "galaxycore,gc2145";
+ reg = <0x3c>;
+ clocks = <&clk_ext_camera>;
+ iovdd-supply = <&scmi_v3v3_sw>;
+ avdd-supply = <&scmi_v3v3_sw>;
+ dvdd-supply = <&scmi_v3v3_sw>;
+ powerdown-gpios = <&mcp23017 3 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
+ reset-gpios = <&mcp23017 4 (GPIO_ACTIVE_LOW | GPIO_PUSH_PULL)>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&mipid02_0>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <120000000 192000000 240000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
index 1e2df8cf2937..1a57f2aa1982 100644
--- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
@@ -14,6 +14,9 @@ description: |-
interface and CCI (I2C compatible) control bus. The output format
is raw Bayer.
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
properties:
compatible:
const: hynix,hi846
@@ -25,12 +28,6 @@ properties:
items:
- description: Reference to the mclk clock.
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-rates:
- maxItems: 1
-
reset-gpios:
description: Reference to the GPIO connected to the RESETB pin. Active low.
maxItems: 1
@@ -79,14 +76,12 @@ required:
- compatible
- reg
- clocks
- - assigned-clocks
- - assigned-clock-rates
- vddio-supply
- vdda-supply
- vddd-supply
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -102,13 +97,13 @@ examples:
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_csi1>;
clocks = <&clk 0>;
- assigned-clocks = <&clk 0>;
- assigned-clock-rates = <25000000>;
vdda-supply = <&reg_camera_vdda>;
vddd-supply = <&reg_camera_vddd>;
vddio-supply = <&reg_camera_vddio>;
reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
+ orientation = <0>;
+ rotation = <0>;
port {
camera_out: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
deleted file mode 100644
index 5fc96944b448..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml
+++ /dev/null
@@ -1,109 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/media/i2c/imx219.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Sony 1/4.0-Inch 8Mpixel CMOS Digital Image Sensor
-
-maintainers:
- - Dave Stevenson <dave.stevenson@raspberrypi.com>
-
-description: |-
- The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor
- with an active array size of 3280H x 2464V. It is programmable through
- I2C interface. The I2C address is fixed to 0x10 as per sensor data sheet.
- Image data is sent through MIPI CSI-2, which is configured as either 2 or
- 4 data lanes.
-
-properties:
- compatible:
- const: sony,imx219
-
- reg:
- description: I2C device address
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- VDIG-supply:
- description:
- Digital I/O voltage supply, 1.8 volts
-
- VANA-supply:
- description:
- Analog voltage supply, 2.8 volts
-
- VDDL-supply:
- description:
- Digital core voltage supply, 1.2 volts
-
- reset-gpios:
- maxItems: 1
- description: |-
- Reference to the GPIO connected to the xclr pin, if any.
- Must be released (set high) after all supplies are applied.
-
- port:
- $ref: /schemas/graph.yaml#/$defs/port-base
- additionalProperties: false
-
- properties:
- endpoint:
- $ref: /schemas/media/video-interfaces.yaml#
- unevaluatedProperties: false
-
- properties:
- data-lanes:
- description: |-
- The sensor supports either two-lane, or four-lane operation.
- If this property is omitted four-lane operation is assumed.
- For two-lane operation the property must be set to <1 2>.
- items:
- - const: 1
- - const: 2
-
- clock-noncontinuous: true
- link-frequencies: true
-
- required:
- - link-frequencies
-
-required:
- - compatible
- - reg
- - clocks
- - VANA-supply
- - VDIG-supply
- - VDDL-supply
- - port
-
-additionalProperties: false
-
-examples:
- - |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- imx219: sensor@10 {
- compatible = "sony,imx219";
- reg = <0x10>;
- clocks = <&imx219_clk>;
- VANA-supply = <&imx219_vana>; /* 2.8v */
- VDIG-supply = <&imx219_vdig>; /* 1.8v */
- VDDL-supply = <&imx219_vddl>; /* 1.2v */
-
- port {
- imx219_0: endpoint {
- remote-endpoint = <&csi1_ep>;
- data-lanes = <1 2>;
- clock-noncontinuous;
- link-frequencies = /bits/ 64 <456000000>;
- };
- };
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml b/Documentation/devicetree/bindings/media/i2c/imx258.yaml
deleted file mode 100644
index cde0f7383b2a..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/imx258.yaml
+++ /dev/null
@@ -1,134 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/media/i2c/imx258.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Sony IMX258 13 Mpixel CMOS Digital Image Sensor
-
-maintainers:
- - Krzysztof Kozlowski <krzk@kernel.org>
-
-description: |-
- IMX258 is a diagonal 5.867mm (Type 1/3.06) 13 Mega-pixel CMOS active pixel
- type stacked image sensor with a square pixel array of size 4208 x 3120. It
- is programmable through I2C interface. Image data is sent through MIPI
- CSI-2.
-
-properties:
- compatible:
- const: sony,imx258
-
- assigned-clocks: true
- assigned-clock-parents: true
- assigned-clock-rates: true
-
- clocks:
- description:
- Clock frequency from 6 to 27 MHz.
- maxItems: 1
-
- reg:
- maxItems: 1
-
- reset-gpios:
- description: |-
- Reference to the GPIO connected to the XCLR pin, if any.
-
- vana-supply:
- description:
- Analog voltage (VANA) supply, 2.7 V
-
- vdig-supply:
- description:
- Digital I/O voltage (VDIG) supply, 1.2 V
-
- vif-supply:
- description:
- Interface voltage (VIF) supply, 1.8 V
-
- # See ../video-interfaces.txt for more details
- port:
- $ref: /schemas/graph.yaml#/$defs/port-base
- additionalProperties: false
-
- properties:
- endpoint:
- $ref: /schemas/media/video-interfaces.yaml#
- unevaluatedProperties: false
-
- properties:
- data-lanes:
- oneOf:
- - items:
- - const: 1
- - const: 2
- - const: 3
- - const: 4
- - items:
- - const: 1
- - const: 2
-
- link-frequencies: true
-
- required:
- - data-lanes
- - link-frequencies
-
-required:
- - compatible
- - reg
- - port
-
-additionalProperties: false
-
-examples:
- - |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sensor@6c {
- compatible = "sony,imx258";
- reg = <0x6c>;
- clocks = <&imx258_clk>;
-
- port {
- endpoint {
- remote-endpoint = <&csi1_ep>;
- data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <320000000>;
- };
- };
- };
- };
-
- /* Oscillator on the camera board */
- imx258_clk: clk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <19200000>;
- };
-
- - |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- sensor@6c {
- compatible = "sony,imx258";
- reg = <0x6c>;
- clocks = <&imx258_clk>;
-
- assigned-clocks = <&imx258_clk>;
- assigned-clock-rates = <19200000>;
-
- port {
- endpoint {
- remote-endpoint = <&csi1_ep>;
- data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <633600000>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/imx290.txt b/Documentation/devicetree/bindings/media/i2c/imx290.txt
deleted file mode 100644
index a3cc21410f7c..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/imx290.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-* Sony IMX290 1/2.8-Inch CMOS Image Sensor
-
-The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with
-Square Pixel for Color Cameras. It is programmable through I2C and 4-wire
-interfaces. The sensor output is available via CMOS logic parallel SDR output,
-Low voltage LVDS DDR output and CSI-2 serial data output. The CSI-2 bus is the
-default. No bindings have been defined for the other busses.
-
-Required Properties:
-- compatible: Should be "sony,imx290"
-- reg: I2C bus address of the device
-- clocks: Reference to the xclk clock.
-- clock-names: Should be "xclk".
-- clock-frequency: Frequency of the xclk clock in Hz.
-- vdddo-supply: Sensor digital IO regulator.
-- vdda-supply: Sensor analog regulator.
-- vddd-supply: Sensor digital core regulator.
-
-Optional Properties:
-- reset-gpios: Sensor reset GPIO
-
-The imx290 device node should contain one 'port' child node with
-an 'endpoint' subnode. For further reading on port node refer to
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Required Properties on endpoint:
-- data-lanes: check ../video-interfaces.txt
-- link-frequencies: check ../video-interfaces.txt
-- remote-endpoint: check ../video-interfaces.txt
-
-Example:
- &i2c1 {
- ...
- imx290: camera-sensor@1a {
- compatible = "sony,imx290";
- reg = <0x1a>;
-
- reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&camera_rear_default>;
-
- clocks = <&gcc GCC_CAMSS_MCLK0_CLK>;
- clock-names = "xclk";
- clock-frequency = <37125000>;
-
- vdddo-supply = <&camera_vdddo_1v8>;
- vdda-supply = <&camera_vdda_2v8>;
- vddd-supply = <&camera_vddd_1v5>;
-
- port {
- imx290_ep: endpoint {
- data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <445500000>;
- remote-endpoint = <&csiphy0_ep>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt b/Documentation/devicetree/bindings/media/i2c/maxim,max2175.txt
index 02b4e9cd7b1b..02b4e9cd7b1b 100644
--- a/Documentation/devicetree/bindings/media/i2c/max2175.txt
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max2175.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 90315e217003..a37447256f8d 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -39,7 +39,7 @@ properties:
maxItems: 1
poc-supply:
- description: Regulator providing Power over Coax to the cameras
+ description: Regulator providing Power over Coax to all the ports
enable-gpios:
description: GPIO connected to the \#PWDN pin with inverted polarity
@@ -50,6 +50,21 @@ properties:
'#gpio-cells':
const: 2
+ maxim,bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 24, 27, 32 ]
+ description: |
+ The GMSL serial data bus width. This setting is normally controlled by
+ the BWS pin, but may be overridden with this property. The value must
+ match the configuration of the remote serializers.
+
+ maxim,i2c-remote-bus-hz:
+ enum: [ 8470, 28300, 84700, 105000, 173000, 339000, 533000, 837000 ]
+ default: 105000
+ description: |
+ The I2C clock frequency for the remote I2C buses. The value must match
+ the configuration of the remote serializers.
+
maxim,reverse-channel-microvolt:
minimum: 30000
maximum: 200000
@@ -71,7 +86,7 @@ properties:
is 100000 micro volts
maxim,gpio-poc:
- $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
description: |
@@ -141,6 +156,7 @@ properties:
patternProperties:
"^i2c@[0-3]$":
type: object
+ additionalProperties: false
description: |
Child node of the i2c bus multiplexer which represents a GMSL link.
Each serializer device on the GMSL link remote end is represented with
@@ -152,6 +168,12 @@ properties:
description: The index of the GMSL channel.
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
patternProperties:
"^camera@[a-f0-9]+$":
type: object
@@ -182,21 +204,36 @@ properties:
additionalProperties: false
+patternProperties:
+ "^port[0-3]-poc-supply$":
+ description: Regulator providing Power over Coax for a particular port
+
required:
- compatible
- reg
- ports
- i2c-mux
-# If 'maxim,gpio-poc' is present, then 'poc-supply' and 'gpio-controller'
-# are not allowed.
-if:
- required:
- - maxim,gpio-poc
-then:
- properties:
- poc-supply: false
- gpio-controller: false
+allOf:
+ # Only one way of specifying power supplies is allowed: 'maxim,gpio-poc',
+ # 'poc-supply' or per-port poc-supply. Additionally, if 'maxim,gpio-poc' is
+ # present, then 'gpio-controller' isn't allowed.
+ - if:
+ required:
+ - maxim,gpio-poc
+ then:
+ properties:
+ poc-supply: false
+ gpio-controller: false
+ patternProperties:
+ "^port[0-3]-poc-supply$": false
+
+ - if:
+ required:
+ - poc-supply
+ then:
+ patternProperties:
+ "^port[0-3]-poc-supply$": false
additionalProperties: false
@@ -219,6 +256,7 @@ examples:
gpio-controller;
#gpio-cells = <2>;
+ maxim,i2c-remote-bus-hz = <339000>;
maxim,reverse-channel-microvolt = <170000>;
ports {
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml
index 444f24838d3d..26f85151afbd 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml
@@ -25,7 +25,10 @@ description: |
properties:
compatible:
- const: maxim,max96712
+ items:
+ - enum:
+ - maxim,max96712
+ - maxim,max96724
reg:
description: I2C device address
@@ -65,9 +68,14 @@ properties:
properties:
data-lanes: true
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
required:
- data-lanes
+ - bus-type
required:
- port@4
@@ -82,6 +90,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
i2c@e6508000 {
#address-cells = <1>;
@@ -101,6 +110,7 @@ examples:
port@4 {
reg = <4>;
max96712_out0: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
clock-lanes = <0>;
data-lanes = <1 2 3 4>;
remote-endpoint = <&csi40_in>;
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
new file mode 100644
index 000000000000..3ace50e11921
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96714.yaml
@@ -0,0 +1,174 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Collabora Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/maxim,max96714.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX96714 GMSL2 to CSI-2 Deserializer
+
+maintainers:
+ - Julien Massot <julien.massot@collabora.com>
+
+description:
+ The MAX96714 deserializer converts GMSL2 serial inputs into MIPI
+ CSI-2 D-PHY formatted output. The device allows the GMSL2 link to
+ simultaneously transmit bidirectional control-channel data while forward
+ video transmissions are in progress. The MAX96714 can connect to one
+ remotely located serializer using industry-standard coax or STP
+ interconnects. The device cans operate in pixel or tunnel mode. In pixel mode
+ the MAX96714 can select individual video stream, while the tunnel mode forward all
+ the MIPI data received by the serializer.
+
+ The GMSL2 serial link operates at a fixed rate of 3Gbps or 6Gbps in the
+ forward direction and 187.5Mbps in the reverse direction.
+ MAX96714F only supports a fixed rate of 3Gbps in the forward direction.
+
+properties:
+ compatible:
+ oneOf:
+ - const: maxim,max96714f
+ - items:
+ - enum:
+ - maxim,max96714
+ - const: maxim,max96714f
+
+ reg:
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+ description:
+ Specifier for the GPIO connected to the PWDNB pin.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ description: GMSL Input
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for GMSL2-Link port.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 5
+
+ link-frequencies:
+ maxItems: 1
+
+ required:
+ - data-lanes
+
+ required:
+ - port@1
+
+ i2c-gate:
+ $ref: /schemas/i2c/i2c-gate.yaml
+ unevaluatedProperties: false
+ description:
+ The MAX96714 will pass through and forward the I2C requests from the
+ incoming I2C bus over the GMSL2 link. Therefore it supports an i2c-gate
+ subnode to configure a serializer.
+
+ port0-poc-supply:
+ description: Regulator providing Power over Coax for the GMSL port
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deserializer@28 {
+ compatible = "maxim,max96714f";
+ reg = <0x28>;
+ powerdown-gpios = <&main_gpio0 37 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ max96714_gmsl_in: endpoint {
+ remote-endpoint = <&max96917f_gmsl_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ max96714_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <400000000>;
+ remote-endpoint = <&csi_in>;
+ };
+ };
+ };
+
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ serializer@40 {
+ compatible = "maxim,max96717f";
+ reg = <0x40>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ max96717f_csi_in: endpoint {
+ data-lanes = <1 2>;
+ lane-polarities = <1 0 1>;
+ remote-endpoint = <&sensor_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ max96917f_gmsl_out: endpoint {
+ remote-endpoint = <&max96714_gmsl_in>;
+ };
+ };
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
new file mode 100644
index 000000000000..d1e8ba6e368e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96717.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Collabora Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/maxim,max96717.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX96717 CSI-2 to GMSL2 Serializer
+
+maintainers:
+ - Julien Massot <julien.massot@collabora.com>
+
+description:
+ The MAX96717 serializer converts MIPI CSI-2 D-PHY formatted input
+ into GMSL2 serial outputs. The device allows the GMSL2 link to
+ simultaneously transmit bidirectional control-channel data while forward
+ video transmissions are in progress. The MAX96717 can connect to one
+ remotely located deserializer using industry-standard coax or STP
+ interconnects. The device cans operate in pixel or tunnel mode. In pixel mode
+ the MAX96717 can select the MIPI datatype, while the tunnel mode forward all the MIPI
+ data received by the serializer.
+ The MAX96717 supports Reference Over Reverse (channel),
+ to generate a clock output for the sensor from the GMSL reverse channel.
+
+ The GMSL2 serial link operates at a fixed rate of 3Gbps or 6Gbps in the
+ forward direction and 187.5Mbps in the reverse direction.
+ MAX96717F only supports a fixed rate of 3Gbps in the forward direction.
+
+properties:
+ compatible:
+ oneOf:
+ - const: maxim,max96717f
+ - items:
+ - enum:
+ - maxim,max96717
+ - const: maxim,max96717f
+
+ '#gpio-cells':
+ const: 2
+ description:
+ First cell is the GPIO pin number, second cell is the flags. The GPIO pin
+ number must be in range of [0, 10].
+
+ gpio-controller: true
+
+ '#clock-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Input port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 5
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ description: GMSL Output port
+
+ required:
+ - port@1
+
+ i2c-gate:
+ $ref: /schemas/i2c/i2c-gate.yaml
+ unevaluatedProperties: false
+ description:
+ The MAX96717 will forward the I2C requests from the
+ incoming GMSL2 link. Therefore, it supports an i2c-gate
+ subnode to configure a sensor.
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ serializer: serializer@40 {
+ compatible = "maxim,max96717f";
+ reg = <0x40>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ max96717f_csi_in: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&sensor_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ max96917f_gmsl_out: endpoint {
+ remote-endpoint = <&deser_gmsl_in>;
+ };
+ };
+ };
+
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sensor@10 {
+ compatible = "st,st-vgxy61";
+ reg = <0x10>;
+ reset-gpios = <&serializer 0 GPIO_ACTIVE_LOW>;
+ clocks = <&serializer>;
+ VCORE-supply = <&v1v2>;
+ VDDIO-supply = <&v1v8>;
+ VANA-supply = <&v2v8>;
+ port {
+ sensor_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&max96717f_csi_in>;
+ };
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt b/Documentation/devicetree/bindings/media/i2c/micron,mt9m111.txt
index d0bed6fa901a..d0bed6fa901a 100644
--- a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt
+++ b/Documentation/devicetree/bindings/media/i2c/micron,mt9m111.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
index 39395ea8c318..217b08c8cbbd 100644
--- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
@@ -23,6 +23,9 @@ description:
More detailed documentation can be found in
Documentation/devicetree/bindings/media/video-interfaces.txt .
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
properties:
compatible:
oneOf:
@@ -52,22 +55,17 @@ properties:
clock-frequency:
description: Frequency of the external clock to the sensor in Hz.
+ deprecated: true
reset-gpios:
description: Reset GPIO. Also commonly called XSHUTDOWN in hardware
documentation.
maxItems: 1
- flash-leds:
- description: Flash LED phandles. See ../video-interfaces.txt for details.
-
- lens-focus:
- description: Lens focus controller phandles. See ../video-interfaces.txt
- for details.
+ flash-leds: true
+ lens-focus: true
rotation:
- description: Rotation of the sensor. See ../video-interfaces.txt for
- details.
enum: [ 0, 180 ]
port:
@@ -96,7 +94,6 @@ properties:
required:
- compatible
- reg
- - clock-frequency
- clocks
additionalProperties: false
@@ -104,8 +101,9 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
- i2c2 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -116,15 +114,18 @@ examples:
reg = <0x10>;
reset-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
vana-supply = <&vaux3>;
+
clocks = <&omap3_isp 0>;
- clock-frequency = <9600000>;
+ assigned-clocks = <&omap3_isp 0>;
+ assigned-clock-rates = <9600000>;
+
port {
ccs_ep: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&csi2a_ep>;
link-frequencies = /bits/ 64 <199200000 210000000
499200000>;
- bus-type = <4>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
};
};
};
diff --git a/Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml b/Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml
new file mode 100644
index 000000000000..477e59316dfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/nxp,tda19971.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP TDA1997x HDMI receiver
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The TDA19971/73 are HDMI video receivers.
+
+ The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+ The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+ The Video port output pins are mapped via 4-bit 'pin groups' allowing
+ for a variety of connection possibilities including swapping pin order within
+ pin groups. The video_portcfg device-tree property consists of register mapping
+ pairs which map a chip-specific VP output register to a 4-bit pin group. If
+ the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+properties:
+ compatible:
+ enum:
+ - nxp,tda19971
+ - nxp,tda19973
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ DOVDD-supply: true
+
+ DVDD-supply: true
+
+ AVDD-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ nxp,vidout-portcfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 4
+ items:
+ items:
+ - description: Video Port control registers index.
+ maximum: 8
+ minimum: 0
+ - description: pin(pinswapped) groups
+
+ description:
+ array of pairs mapping VP output pins to pin groups.
+
+ nxp,audout-format:
+ enum:
+ - i2s
+ - spdif
+
+ nxp,audout-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16, 24, 32]
+ description:
+ width of audio output data bus.
+
+ nxp,audout-layout:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description:
+ data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+
+ nxp,audout-mclk-fs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Multiplication factor between stream rate and codec mclk.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - DOVDD-supply
+ - AVDD-supply
+ - DVDD-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/media/tda1997x.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ reg = <0x48>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <&reg_3p3v>;
+ AVDD-supply = <&reg_1p8v>;
+ DVDD-supply = <&reg_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+ * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+ * and Y[11:4] across 16bits in the same pixclk cycle.
+ */
+ nxp,vidout-portcfg =
+ /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9m001.txt b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m001.txt
index c920552b03ef..c920552b03ef 100644
--- a/Documentation/devicetree/bindings/media/i2c/mt9m001.txt
+++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m001.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
new file mode 100644
index 000000000000..a89f740214f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/onnn,mt9m114.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: onsemi 1/6-inch 720p CMOS Digital Image Sensor
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |-
+ The onsemi MT9M114 is a 1/6-inch 720p (1.26 Mp) CMOS digital image sensor
+ with an active pixel-array size of 1296H x 976V. It is programmable through
+ an I2C interface and outputs image data over a 8-bit parallel or 1-lane MIPI
+ CSI-2 connection.
+
+properties:
+ compatible:
+ const: onnn,mt9m114
+
+ reg:
+ description: I2C device address
+ enum:
+ - 0x48
+ - 0x5d
+
+ clocks:
+ description: EXTCLK clock signal
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Core digital voltage supply, 1.8V
+
+ vddio-supply:
+ description:
+ I/O digital voltage supply, 1.8V or 2.8V
+
+ vaa-supply:
+ description:
+ Analog voltage supply, 2.8V
+
+ reset-gpios:
+ description: |-
+ Reference to the GPIO connected to the RESET_BAR pin, if any (active
+ low).
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ bus-type:
+ enum: [4, 5, 6]
+
+ link-frequencies: true
+ remote-endpoint: true
+
+ # The number and mapping of lanes (for CSI-2), and the bus width and
+ # signal polarities (for parallel and BT.656) are fixed and must not
+ # be specified.
+
+ required:
+ - bus-type
+ - link-frequencies
+
+ slew-rate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Slew rate ot the output pads DOUT[7:0], LINE_VALID, FRAME_VALID and
+ PIXCLK. Higher values imply steeper voltage-flanks on the pads.
+ minimum: 0
+ maximum: 7
+ default: 7
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vdd-supply
+ - vddio-supply
+ - vaa-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "onnn,mt9m114";
+ reg = <0x48>;
+
+ clocks = <&clk24m 0>;
+
+ reset-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
+
+ vddio-supply = <&reg_cam_1v8>;
+ vdd-supply = <&reg_cam_1v8>;
+ vaa-supply = <&reg_2p8v>;
+
+ port {
+ endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ link-frequencies = /bits/ 64 <384000000>;
+ remote-endpoint = <&mipi_csi_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt b/Documentation/devicetree/bindings/media/i2c/ov2685.txt
deleted file mode 100644
index 625c4a8c0d53..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ov2685.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Omnivision OV2685 MIPI CSI-2 sensor
-
-Required Properties:
-- compatible: shall be "ovti,ov2685"
-- clocks: reference to the xvclk input clock
-- clock-names: shall be "xvclk"
-- avdd-supply: Analog voltage supply, 2.8 volts
-- dovdd-supply: Digital I/O voltage supply, 1.8 volts
-- dvdd-supply: Digital core voltage supply, 1.8 volts
-- reset-gpios: Low active reset gpio
-
-The device node shall contain one 'port' child node with an
-'endpoint' subnode for its digital output video port,
-in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-The endpoint optional property 'data-lanes' shall be "<1>".
-
-Example:
-&i2c7 {
- ov2685: camera-sensor@3c {
- compatible = "ovti,ov2685";
- reg = <0x3c>;
- pinctrl-names = "default";
- pinctrl-0 = <&clk_24m_cam>;
-
- clocks = <&cru SCLK_TESTCLKOUT1>;
- clock-names = "xvclk";
-
- avdd-supply = <&pp2800_cam>;
- dovdd-supply = <&pp1800>;
- dvdd-supply = <&pp1800>;
- reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
-
- port {
- ucam_out: endpoint {
- remote-endpoint = <&mipi_in_ucam>;
- data-lanes = <1>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
deleted file mode 100644
index 72ad992f77be..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ov5645.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
-
-The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor with
-an active array size of 2592H x 1944V. It is programmable through a serial I2C
-interface.
-
-Required Properties:
-- compatible: Value should be "ovti,ov5645".
-- clocks: Reference to the xclk clock.
-- clock-names: Should be "xclk".
-- clock-frequency: Frequency of the xclk clock.
-- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
- to the hardware pin PWDNB which is physically active low.
-- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This corresponds to
- the hardware pin RESETB.
-- vdddo-supply: Chip digital IO regulator.
-- vdda-supply: Chip analog regulator.
-- vddd-supply: Chip digital core regulator.
-
-The device node must contain one 'port' child node for its digital output
-video port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-
- &i2c1 {
- ...
-
- ov5645: ov5645@3c {
- compatible = "ovti,ov5645";
- reg = <0x3c>;
-
- enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&camera_rear_default>;
-
- clocks = <&clks 200>;
- clock-names = "xclk";
- clock-frequency = <24000000>;
-
- vdddo-supply = <&camera_dovdd_1v8>;
- vdda-supply = <&camera_avdd_2v8>;
- vddd-supply = <&camera_dvdd_1v2>;
-
- port {
- ov5645_ep: endpoint {
- clock-lanes = <1>;
- data-lanes = <0 2>;
- remote-endpoint = <&csi0_ep>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5695.txt b/Documentation/devicetree/bindings/media/i2c/ov5695.txt
deleted file mode 100644
index 640a63717d96..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ov5695.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Omnivision OV5695 MIPI CSI-2 sensor
-
-Required Properties:
-- compatible: shall be "ovti,ov5695"
-- clocks: reference to the xvclk input clock
-- clock-names: shall be "xvclk"
-- avdd-supply: Analog voltage supply, 2.8 volts
-- dovdd-supply: Digital I/O voltage supply, 1.8 volts
-- dvdd-supply: Digital core voltage supply, 1.2 volts
-- reset-gpios: Low active reset gpio
-
-The device node shall contain one 'port' child node with an
-'endpoint' subnode for its digital output video port,
-in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-The endpoint optional property 'data-lanes' shall be "<1 2>".
-
-Example:
-&i2c7 {
- ov5695: camera-sensor@36 {
- compatible = "ovti,ov5695";
- reg = <0x36>;
- pinctrl-names = "default";
- pinctrl-0 = <&clk_24m_cam>;
-
- clocks = <&cru SCLK_TESTCLKOUT1>;
- clock-names = "xvclk";
-
- avdd-supply = <&pp2800_cam>;
- dovdd-supply = <&pp1800>;
- dvdd-supply = <&pp1250_cam>;
- reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
-
- port {
- wcam_out: endpoint {
- remote-endpoint = <&mipi_in_wcam>;
- data-lanes = <1 2>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/ov7251.txt b/Documentation/devicetree/bindings/media/i2c/ov7251.txt
deleted file mode 100644
index 8281151f7493..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ov7251.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* Omnivision 1/7.5-Inch B&W VGA CMOS Digital Image Sensor
-
-The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
-with an active array size of 640H x 480V. It is programmable through a serial
-I2C interface.
-
-Required Properties:
-- compatible: Value should be "ovti,ov7251".
-- clocks: Reference to the xclk clock.
-- clock-names: Should be "xclk".
-- clock-frequency: Frequency of the xclk clock.
-- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
- to the hardware pin XSHUTDOWN which is physically active low.
-- vdddo-supply: Chip digital IO regulator.
-- vdda-supply: Chip analog regulator.
-- vddd-supply: Chip digital core regulator.
-
-The device node shall contain one 'port' child node with a single 'endpoint'
-subnode for its digital output video port, in accordance with the video
-interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-
- &i2c1 {
- ...
-
- ov7251: camera-sensor@60 {
- compatible = "ovti,ov7251";
- reg = <0x60>;
-
- enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&camera_bw_default>;
-
- clocks = <&clks 200>;
- clock-names = "xclk";
- clock-frequency = <24000000>;
-
- vdddo-supply = <&camera_dovdd_1v8>;
- vdda-supply = <&camera_avdd_2v8>;
- vddd-supply = <&camera_dvdd_1v2>;
-
- port {
- ov7251_ep: endpoint {
- clock-lanes = <1>;
- data-lanes = <0>;
- remote-endpoint = <&csi0_ep>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
deleted file mode 100644
index baf92aaaf049..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
+++ /dev/null
@@ -1,134 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-# Copyright (c) 2019 MediaTek Inc.
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/media/i2c/ov8856.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Omnivision OV8856 CMOS Sensor Device Tree Bindings
-
-maintainers:
- - Dongchun Zhu <dongchun.zhu@mediatek.com>
-
-description: |-
- The Omnivision OV8856 is a high performance, 1/4-inch, 8 megapixel, CMOS
- image sensor that delivers 3264x2448 at 30fps. It provides full-frame,
- sub-sampled, and windowed 10-bit MIPI images in various formats via the
- Serial Camera Control Bus (SCCB) interface. This chip is programmable
- through I2C and two-wire SCCB. The sensor output is available via CSI-2
- serial data output (up to 4-lane).
-
-properties:
- compatible:
- const: ovti,ov8856
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- clock-names:
- description:
- Input clock for the sensor.
- items:
- - const: xvclk
-
- clock-frequency:
- description:
- Frequency of the xvclk clock in Hertz.
-
- dovdd-supply:
- description:
- Definition of the regulator used as interface power supply.
-
- avdd-supply:
- description:
- Definition of the regulator used as analog power supply.
-
- dvdd-supply:
- description:
- Definition of the regulator used as digital power supply.
-
- reset-gpios:
- description:
- The phandle and specifier for the GPIO that controls sensor reset.
- This corresponds to the hardware pin XSHUTDOWN which is physically
- active low.
-
- port:
- $ref: /schemas/graph.yaml#/$defs/port-base
- additionalProperties: false
-
- properties:
- endpoint:
- $ref: /schemas/media/video-interfaces.yaml#
- unevaluatedProperties: false
-
- properties:
- data-lanes:
- description: |-
- The driver only supports four-lane operation.
- items:
- - const: 1
- - const: 2
- - const: 3
- - const: 4
-
- link-frequencies:
- description: Frequencies listed are driver, not h/w limitations.
- maxItems: 2
- items:
- enum: [ 360000000, 180000000 ]
-
- required:
- - link-frequencies
-
-required:
- - compatible
- - reg
- - clocks
- - clock-names
- - clock-frequency
- - dovdd-supply
- - avdd-supply
- - dvdd-supply
- - reset-gpios
- - port
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
-
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ov8856: camera@10 {
- compatible = "ovti,ov8856";
- reg = <0x10>;
-
- reset-gpios = <&pio 111 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&clk_24m_cam>;
-
- clocks = <&cam_osc>;
- clock-names = "xvclk";
- clock-frequency = <19200000>;
-
- avdd-supply = <&mt6358_vcama2_reg>;
- dvdd-supply = <&mt6358_vcamd_reg>;
- dovdd-supply = <&mt6358_vcamio_reg>;
-
- port {
- wcam_out: endpoint {
- remote-endpoint = <&mipi_in_wcam>;
- data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <360000000>;
- };
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml
new file mode 100644
index 000000000000..ca57c01739d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,og01a1b.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023-2024 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,og01a1b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OG01A1B Image Sensor
+
+maintainers:
+ - Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
+
+description:
+ The OmniVision OG01A1B is black and white CMOS 1.3 Megapixel (1280x1024)
+ image sensor controlled over an I2C-compatible SCCB bus.
+ The sensor transmits images on a MIPI CSI-2 output interface with one or
+ two data lanes.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,og01a1b
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ reset-gpios:
+ description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
+ maxItems: 1
+
+ strobe-gpios:
+ description: Input GPIO connected to strobe pad of the sensor.
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogue circuit voltage supply.
+
+ dovdd-supply:
+ description: I/O circuit voltage supply.
+
+ dvdd-supply:
+ description: Digital circuit voltage supply.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [1, 2]
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@60 {
+ compatible = "ovti,og01a1b";
+ reg = <0x60>;
+ clocks = <&clk 0>;
+ reset-gpios = <&gpio 117 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&vreg_3v3>;
+ dovdd-supply = <&vreg_1p8>;
+ dvdd-supply = <&vreg_1p2>;
+
+ port {
+ og01a1b_ep: endpoint {
+ remote-endpoint = <&csiphy_ep>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <500000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,og0ve1b.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,og0ve1b.yaml
new file mode 100644
index 000000000000..bd2f1ae23e65
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,og0ve1b.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,og0ve1b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OG0VE1B Image Sensor
+
+description:
+ OmniVision OG0VE1B image sensor is a low power consuming monochrome
+ image sensor. The sensor is controlled over a serial camera control
+ bus protocol (SCCB), the widest supported image size is 640x480 at
+ 120 frames per second rate, data output format is 8/10-bit RAW
+ transferred over one-lane MIPI D-PHY at up to 800 Mbps.
+
+maintainers:
+ - Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,og0ve1b
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: XVCLK supply clock, 6MHz to 27MHz frequency.
+ maxItems: 1
+
+ reset-gpios:
+ description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
+ maxItems: 1
+
+ strobe-gpios:
+ description: Input GPIO connected to strobe pad of the sensor.
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog voltage supply, 2.6 to 3.0 volts.
+
+ dovdd-supply:
+ description: Digital I/O voltage supply, 1.7 to 3.0 volts.
+
+ dvdd-supply:
+ description: Digital core voltage supply.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@3e {
+ compatible = "ovti,og0ve1b";
+ reg = <0x3e>;
+ clocks = <&camera_clk 0>;
+ assigned-clocks = <&camera_clk 0>;
+ assigned-clock-rates = <24000000>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&vreg_2p8>;
+ dovdd-supply = <&vreg_1p8>;
+ dvdd-supply = <&vreg_1p2>;
+
+ port {
+ endpoint {
+ link-frequencies = /bits/ 64 <500000000>;
+ remote-endpoint = <&mipi_csi2_ep>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
index 63a040944f3d..0e1d9c390180 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
+title: Omnivision OV02A10 CMOS Sensor
maintainers:
- Dongchun Zhu <dongchun.zhu@mediatek.com>
@@ -39,6 +39,7 @@ properties:
clock-frequency:
description:
Frequency of the eclk clock in Hz.
+ deprecated: true
dovdd-supply:
description:
@@ -68,12 +69,6 @@ properties:
marked GPIO_ACTIVE_LOW.
maxItems: 1
- rotation:
- enum:
- - 0 # Sensor Mounted Upright
- - 180 # Sensor Mounted Upside Down
- default: 0
-
port:
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
@@ -88,7 +83,7 @@ properties:
properties:
link-frequencies: true
ovti,mipi-clock-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
Definition of MIPI clock voltage unit. This entry corresponds to
the link speed defined by the 'link-frequencies' property.
@@ -106,7 +101,6 @@ required:
- reg
- clocks
- clock-names
- - clock-frequency
- dovdd-supply
- avdd-supply
- dvdd-supply
@@ -114,7 +108,7 @@ required:
- reset-gpios
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -133,7 +127,6 @@ examples:
clocks = <&ov02a10_clk>;
clock-names = "eclk";
- clock-frequency = <24000000>;
rotation = <180>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02e10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02e10.yaml
new file mode 100644
index 000000000000..03d476bcf805
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02e10.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2025 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov02e10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV02E10 CMOS Sensor
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description: |
+ The Omnivision OV02E10 and OV02C10 sensors are 2 megapixel, CMOS image sensors which support:
+ - Automatic black level calibration (ABLC)
+ - Programmable controls for frame rate, mirror and flip, binning, cropping
+ and windowing
+ - OVO2C10
+ - 10 bit RAW Bayer 1920x1080 60 fps 2-lane @ 800 Mbps/lane
+ - 10 bit RAW Bayer 1920x1080 60 fps 1-lane @ 1500 Mbps/lane
+ - 10 bit RAW Bayer 1280x720 60 fps cropped 1-lane @ 960 Mbps/lane
+ - 10 bit RGB/BW 640x480 60 fps bin2 or skip2 1-lane @ 800 Mbps/lane
+ - 10 bit RGB/BW 480x270 60 fps bin4 or skip4 1-lane @ 800 Mbps/lane
+ - OV02E10
+ - 10 bit RAW Bayer 1920x1088 60 fps 2-lane @ 720 Mbps/lane
+ - 10 bit RAW Bayer 1280x1080 60 fps 2-lane @ 720 Mbps/lane
+ - 10 bit Quad Bayer 960x540 60 fps 2-lane 360 Mbps/lane
+ - 8 bit Quad Bayer 480x270 1/3/5/10 fps sub2 288 Mbps/lane
+ - 8 bit Quad Bayer 232x132 1/3/5/10 fps sub4 144 Mbps/lane
+ - Dynamic defect pixel cancellation
+ - Standard SCCB command interface
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ovti,ov02c10
+ - ovti,ov02e10
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogue circuit voltage supply.
+
+ dovdd-supply:
+ description: I/O circuit voltage supply.
+
+ dvdd-supply:
+ description: Digital circuit voltage supply.
+
+ reset-gpios:
+ description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ data-lanes:
+ items:
+ - const: 1
+ - const: 2
+ link-frequencies: true
+ remote-endpoint: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+ - remote-endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov02e10: camera@10 {
+ compatible = "ovti,ov02e10";
+ reg = <0x10>;
+
+ reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_rgb_defaultt>;
+
+ clocks = <&ov02e10_clk>;
+
+ assigned-clocks = <&ov02e10_clk>;
+ assigned-clock-parents = <&ov02e10_clk_parent>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vreg_l7b_2p8>;
+ dvdd-supply = <&vreg_l7b_1p8>;
+ dovdd-supply = <&vreg_l3m_1p8>;
+
+ port {
+ ov02e10_ep: endpoint {
+ remote-endpoint = <&csiphy4_ep>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <400000000>;
+ };
+ };
+ };
+
+ ov02c10: camera@36 {
+ compatible = "ovti,ov02c10";
+ reg = <0x36>;
+
+ reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_rgb_defaultt>;
+
+ clocks = <&ov02c10_clk>;
+
+ assigned-clocks = <&ov02c10_clk>;
+ assigned-clock-parents = <&ov02c10_clk_parent>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vreg_l7b_2p8>;
+ dvdd-supply = <&vreg_l7b_1p8>;
+ dovdd-supply = <&vreg_l3m_1p8>;
+
+ port {
+ ov02c10_ep: endpoint {
+ remote-endpoint = <&csiphy4_ep>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <400000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml
new file mode 100644
index 000000000000..552efdf8934f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08x40.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2024 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov08x40.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV08X40 CMOS Sensor
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description: |
+ The Omnivision OV08X40 is a 9.2 megapixel, CMOS image sensor which supports:
+ - Automatic black level calibration (ABLC)
+ - Programmable controls for frame rate, mirror and flip, binning, cropping
+ and windowing
+ - Output formats 10-bit 4C RGB RAW, 10-bit Bayer RAW
+ - 4-lane MIPI D-PHY TX @ 1 Gbps per lane
+ - 2-lane MPIP D-PHY TX @ 2 Gbps per lane
+ - Dynamic defect pixel cancellation
+ - Standard SCCB command interface
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,ov08x40
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogue circuit voltage supply.
+
+ dovdd-supply:
+ description: I/O circuit voltage supply.
+
+ dvdd-supply:
+ description: Digital circuit voltage supply.
+
+ reset-gpios:
+ description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ link-frequencies: true
+ remote-endpoint: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+ - remote-endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov08x40: camera@36 {
+ compatible = "ovti,ov08x40";
+ reg = <0x36>;
+
+ reset-gpios = <&tlmm 111 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_rgb_defaultt>;
+
+ clocks = <&ov08x40_clk>;
+
+ assigned-clocks = <&ov08x40_clk>;
+ assigned-clock-parents = <&ov08x40_clk_parent>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vreg_l7b_2p8>;
+ dvdd-supply = <&vreg_l7b_1p8>;
+ dovdd-supply = <&vreg_l3m_1p8>;
+
+ port {
+ ov08x40_ep: endpoint {
+ remote-endpoint = <&csiphy4_ep>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <400000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt b/Documentation/devicetree/bindings/media/i2c/ovti,ov2640.txt
index 989ce6cb6ac3..989ce6cb6ac3 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2659.txt b/Documentation/devicetree/bindings/media/i2c/ovti,ov2659.txt
index 92989a619f29..92989a619f29 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov2659.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2659.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
index cf456f8d9ddc..634d3b821b8c 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
@@ -37,31 +37,45 @@ properties:
active low.
maxItems: 1
- dovdd-supply:
+ DOVDD-supply:
description:
Definition of the regulator used as interface power supply.
- avdd-supply:
+ AVDD-supply:
description:
Definition of the regulator used as analog power supply.
- dvdd-supply:
+ DVDD-supply:
description:
Definition of the regulator used as digital power supply.
port:
- $ref: /schemas/graph.yaml#/properties/port
description:
A node containing an output port node.
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ link-frequencies: true
+
+ remote-endpoint: true
+
+ required:
+ - link-frequencies
required:
- compatible
- reg
- clocks
- clock-names
- - dovdd-supply
- - avdd-supply
- - dvdd-supply
+ - DOVDD-supply
+ - AVDD-supply
+ - DVDD-supply
- reset-gpios
- port
@@ -82,13 +96,14 @@ examples:
clock-names = "xvclk";
reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
- dovdd-supply = <&sw2_reg>;
- dvdd-supply = <&sw2_reg>;
- avdd-supply = <&reg_peri_3p15v>;
+ DOVDD-supply = <&sw2_reg>;
+ DVDD-supply = <&sw2_reg>;
+ AVDD-supply = <&reg_peri_3p15v>;
port {
ov2680_to_mipi: endpoint {
remote-endpoint = <&mipi_from_sensor>;
+ link-frequencies = /bits/ 64 <330000000>;
};
};
};
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml
new file mode 100644
index 000000000000..e2ffe0a9c26b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov2685.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV2685 Image Sensor
+
+maintainers:
+ - Shunqian Zheng <zhengsq@rock-chips.com>
+
+properties:
+ compatible:
+ const: ovti,ov2685
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XVCLK clock
+
+ clock-names:
+ items:
+ - const: xvclk
+
+ dvdd-supply:
+ description: Digital Domain Power Supply
+
+ avdd-supply:
+ description: Analog Domain Power Supply
+
+ dovdd-supply:
+ description: I/O Domain Power Supply
+
+ reset-gpios:
+ maxItems: 1
+ description: Reset Pin GPIO Control (active low)
+
+ port:
+ description: MIPI CSI-2 transmitter port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dvdd-supply
+ - avdd-supply
+ - dovdd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov2685: camera-sensor@3c {
+ compatible = "ovti,ov2685";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk_24m_cam>;
+
+ clocks = <&cru SCLK_TESTCLKOUT1>;
+ clock-names = "xvclk";
+
+ avdd-supply = <&pp2800_cam>;
+ dovdd-supply = <&pp1800>;
+ dvdd-supply = <&pp1800>;
+ reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2735.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2735.yaml
new file mode 100644
index 000000000000..bb34f21519c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2735.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov2735.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV2735 Image Sensor
+
+maintainers:
+ - Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>
+
+description:
+ The OmniVision OV2735 is a 2MP (1920x1080) color CMOS image sensor controlled
+ through an I2C-compatible SCCB bus. it outputs RAW10 format and uses a 1/2.7"
+ optical format.
+
+properties:
+ compatible:
+ const: ovti,ov2735
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XVCLK clock
+
+ avdd-supply:
+ description: Analog Domain Power Supply
+
+ dovdd-supply:
+ description: I/O Domain Power Supply
+
+ dvdd-supply:
+ description: Digital Domain Power Supply
+
+ reset-gpios:
+ maxItems: 1
+ description: Reset Pin GPIO Control (active low)
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ Active-low enable pin. Labeled as 'PWDN' in the datasheet, but acts as
+ an enable signal. During power rail ramp-up, the device remains powered
+ down. Once power rails are stable, pulling this pin low powers on the
+ device.
+
+ port:
+ description: MIPI CSI-2 transmitter port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ items:
+ - const: 1
+ - const: 2
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - avdd-supply
+ - dovdd-supply
+ - dvdd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera-sensor@3c {
+ compatible = "ovti,ov2735";
+ reg = <0x3c>;
+ clocks = <&ov2735_clk>;
+
+ avdd-supply = <&ov2735_avdd>;
+ dovdd-supply = <&ov2735_dovdd>;
+ dvdd-supply = <&ov2735_dvdd>;
+
+ reset-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+
+ port {
+ cam_out: endpoint {
+ remote-endpoint = <&mipi_in_cam>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <420000000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
new file mode 100644
index 000000000000..d96199031b66
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov4689.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV4689 CMOS
+
+maintainers:
+ - Mikhail Rudenko <mike.rudenko@gmail.com>
+
+description: |
+ The Omnivision OV4689 is a high performance, 1/3-inch, 4 megapixel
+ image sensor. Ihis chip supports high frame rate speeds up to 90 fps
+ at 2688x1520 resolution. It is programmable through an I2C
+ interface, and sensor output is sent via 1/2/4 lane MIPI CSI-2
+ connection.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,ov4689
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description:
+ External clock (XVCLK) for the sensor, 6-64 MHz
+ maxItems: 1
+
+ dovdd-supply:
+ description:
+ Digital I/O voltage supply, 1.7-3.0 V
+
+ avdd-supply:
+ description:
+ Analog voltage supply, 2.6-3.0 V
+
+ dvdd-supply:
+ description:
+ Digital core voltage supply, 1.1-1.3 V
+
+ powerdown-gpios:
+ description:
+ GPIO connected to the powerdown pin (active low)
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the reset pin (active low)
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+ description:
+ Output port node, single endpoint describing the CSI-2 transmitter
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov4689: camera@36 {
+ compatible = "ovti,ov4689";
+ reg = <0x36>;
+
+ clocks = <&ov4689_clk>;
+
+ avdd-supply = <&ov4689_avdd>;
+ dovdd-supply = <&ov4689_dovdd>;
+ dvdd-supply = <&ov4689_dvdd>;
+
+ powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
+
+ orientation = <2>;
+ rotation = <0>;
+
+ port {
+ wcam_out: endpoint {
+ remote-endpoint = <&mipi_in_wcam>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <504000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
index 540fd69ac39f..2c5e69356658 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5640.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: OmniVision OV5640 Image Sensor Device Tree Bindings
+title: OmniVision OV5640 Image Sensor
maintainers:
- Steve Longerbeam <slongerbeam@gmail.com>
@@ -44,11 +44,6 @@ properties:
description: >
Reference to the GPIO connected to the reset pin, if any.
- rotation:
- enum:
- - 0
- - 180
-
port:
description: Digital Output Port
$ref: /schemas/graph.yaml#/$defs/port-base
@@ -85,7 +80,7 @@ required:
- DOVDD-supply
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5642.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5642.yaml
new file mode 100644
index 000000000000..01f8b2b3fd17
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5642.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5642.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5642 Image Sensor
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,ov5642
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: XCLK Input Clock
+
+ AVDD-supply:
+ description: Analog voltage supply, 2.8V.
+
+ DVDD-supply:
+ description: Digital core voltage supply, 1.5V.
+
+ DOVDD-supply:
+ description: Digital I/O voltage supply, 1.8V.
+
+ powerdown-gpios:
+ maxItems: 1
+ description: Reference to the GPIO connected to the powerdown pin, if any.
+
+ reset-gpios:
+ maxItems: 1
+ description: Reference to the GPIO connected to the reset pin, if any.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: |
+ Video output port.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ enum: [5, 6]
+
+ bus-width:
+ enum: [8, 10]
+ default: 10
+
+ data-shift:
+ enum: [0, 2]
+ default: 0
+
+ hsync-active:
+ enum: [0, 1]
+ default: 1
+
+ vsync-active:
+ enum: [0, 1]
+ default: 1
+
+ pclk-sample:
+ enum: [0, 1]
+ default: 1
+
+ allOf:
+ - if:
+ properties:
+ bus-type:
+ const: 6
+ then:
+ properties:
+ hsync-active: false
+ vsync-active: false
+
+ - if:
+ properties:
+ bus-width:
+ const: 10
+ then:
+ properties:
+ data-shift:
+ const: 0
+
+ required:
+ - bus-type
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@3c {
+ compatible = "ovti,ov5642";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5642>;
+ clocks = <&clk_ext_camera>;
+ DOVDD-supply = <&vgen4_reg>;
+ AVDD-supply = <&vgen3_reg>;
+ DVDD-supply = <&vgen2_reg>;
+ powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+
+ port {
+ ov5642_to_parallel: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
+ remote-endpoint = <&parallel_from_ov5642>;
+ bus-width = <8>;
+ data-shift = <2>; /* lines 9:2 are used */
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5645.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5645.yaml
new file mode 100644
index 000000000000..a583714b1ac7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5645.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5645.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5645 Image Sensor
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+properties:
+ compatible:
+ const: ovti,ov5645
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: XCLK Input Clock
+
+ clock-frequency:
+ description: Frequency of the xclk clock in Hz.
+ deprecated: true
+
+ vdda-supply:
+ description: Analog voltage supply, 2.8 volts
+
+ vddd-supply:
+ description: Digital core voltage supply, 1.5 volts
+
+ vdddo-supply:
+ description: Digital I/O voltage supply, 1.8 volts
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ Reference to the GPIO connected to the PWDNB pin, if any.
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ Reference to the GPIO connected to the RESETB pin, if any.
+
+ port:
+ description: Digital Output Port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [1, 2]
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vdddo-supply
+ - vdda-supply
+ - vddd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@3c {
+ compatible = "ovti,ov5645";
+ reg = <0x3c>;
+
+ clocks = <&clks 1>;
+ assigned-clocks = <&clks 1>;
+ assigned-clock-rates = <24000000>;
+
+ vdddo-supply = <&ov5645_vdddo_1v8>;
+ vdda-supply = <&ov5645_vdda_2v8>;
+ vddd-supply = <&ov5645_vddd_1v5>;
+ enable-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5645>;
+
+ port {
+ ov5645_ep: endpoint {
+ remote-endpoint = <&csi0_ep>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
index 246dc5fec716..8028c8b107c4 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5648.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: OmniVision OV5648 Image Sensor Device Tree Bindings
+title: OmniVision OV5648 Image Sensor
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
@@ -20,12 +20,6 @@ properties:
items:
- description: XVCLK Clock
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-rates:
- maxItems: 1
-
dvdd-supply:
description: Digital Domain Power Supply
@@ -68,8 +62,6 @@ required:
- compatible
- reg
- clocks
- - assigned-clocks
- - assigned-clock-rates
- dvdd-supply
- dovdd-supply
- port
@@ -81,7 +73,7 @@ examples:
#include <dt-bindings/clock/sun8i-v3s-ccu.h>
#include <dt-bindings/gpio/gpio.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -93,9 +85,6 @@ examples:
avdd-supply = <&ov5648_avdd>;
dovdd-supply = <&ov5648_dovdd>;
clocks = <&ov5648_xvclk 0>;
- assigned-clocks = <&ov5648_xvclk 0>;
- assigned-clock-rates = <24000000>;
-
ov5648_out: port {
ov5648_out_mipi_csi2: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml
new file mode 100644
index 000000000000..6e089fe1d613
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5670.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV5670 5 Megapixels raw image sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+
+description: |-
+ The OV5670 is a 5 Megapixels raw image sensor which provides images in 10-bits
+ RAW BGGR Bayer format on a 2 data lanes MIPI CSI-2 serial interface and is
+ controlled through an I2C compatible control bus.
+
+properties:
+ compatible:
+ const: ovti,ov5670
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: System clock. From 6 to 27 MHz.
+ maxItems: 1
+
+ powerdown-gpios:
+ description: Reference to the GPIO connected to the PWDNB pin. Active low.
+
+ reset-gpios:
+ description: Reference to the GPIO connected to the XSHUTDOWN pin. Active low.
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog circuit power. Typically 2.8V.
+
+ dvdd-supply:
+ description: Digital circuit power. Typically 1.2V.
+
+ dovdd-supply:
+ description: Digital I/O circuit power. Typically 2.8V or 1.8V.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [1, 2]
+
+ clock-noncontinuous: true
+ remote-endpoint: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5670: sensor@36 {
+ compatible = "ovti,ov5670";
+ reg = <0x36>;
+
+ clocks = <&sensor_xclk>;
+
+ port {
+ ov5670_ep: endpoint {
+ remote-endpoint = <&csi_ep>;
+ data-lanes = <1 2>;
+ clock-noncontinuous;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
new file mode 100644
index 000000000000..ad07204057f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2022 Theobroma Systems Design und Consulting GmbH
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5675.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV5675 CMOS Sensor
+
+maintainers:
+ - Quentin Schulz <quentin.schulz@theobroma-systems.com>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+description: |
+ The Omnivision OV5675 is a high performance, 1/5-inch, 5 megapixel, CMOS
+ image sensor that delivers 2592x1944 at 30fps. It provides full-frame,
+ sub-sampled, and windowed 10-bit MIPI images in various formats via the
+ Serial Camera Control Bus (SCCB) interface.
+
+ This chip is programmable through I2C and two-wire SCCB. The sensor output
+ is available via CSI-2 serial data output (up to 2-lane).
+
+properties:
+ compatible:
+ const: ovti,ov5675
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description:
+ System input clock (aka XVCLK). From 6 to 27 MHz.
+ maxItems: 1
+
+ dovdd-supply:
+ description:
+ Digital I/O voltage supply, 1.8 volts.
+
+ avdd-supply:
+ description:
+ Analog voltage supply, 2.8 volts.
+
+ dvdd-supply:
+ description:
+ Digital core voltage supply, 1.2 volts.
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+ This corresponds to the hardware pin XSHUTDN which is physically
+ active low.
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+
+ # Supports max data transfer of 900 Mbps per lane
+ link-frequencies: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/px30-cru.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5675: camera@36 {
+ compatible = "ovti,ov5675";
+ reg = <0x36>;
+
+ reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cif_clkout_m0>;
+
+ clocks = <&cru SCLK_CIF_OUT>;
+ assigned-clocks = <&cru SCLK_CIF_OUT>;
+ assigned-clock-rates = <19200000>;
+
+ avdd-supply = <&vcc_1v8>;
+ dvdd-supply = <&vcc_1v2>;
+ dovdd-supply = <&vcc_2v8>;
+
+ rotation = <90>;
+ orientation = <0>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <450000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
index 359dc08440a8..3368b3bd8ef2 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
@@ -5,26 +5,41 @@
$id: http://devicetree.org/schemas/media/i2c/ovti,ov5693.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Omnivision OV5693 CMOS Sensor
+title: Omnivision OV5693/OV5695 CMOS Sensors
maintainers:
- - Tommaso Merciai <tommaso.merciai@amarulasolutions.com>
+ - Tommaso Merciai <tomm.merciai@gmail.com>
description: |
- The Omnivision OV5693 is a high performance, 1/4-inch, 5 megapixel, CMOS
- image sensor that delivers 2592x1944 at 30fps. It provides full-frame,
+ The Omnivision OV5693/OV5695 are high performance, 1/4-inch, 5 megapixel, CMOS
+ image sensors that deliver 2592x1944 at 30fps. It provides full-frame,
sub-sampled, and windowed 10-bit MIPI images in various formats via the
Serial Camera Control Bus (SCCB) interface.
- OV5693 is controlled via I2C and two-wire Serial Camera Control Bus (SCCB).
- The sensor output is available via CSI-2 serial data output (up to 2-lane).
+ OV5693/OV5695 are controlled via I2C and two-wire Serial Camera Control Bus
+ (SCCB). The sensor output is available via CSI-2 serial data output (up to
+ 2-lane).
allOf:
- $ref: /schemas/media/video-interface-devices.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ovti,ov5693
+ then:
+ properties:
+ port:
+ properties:
+ endpoint:
+ required:
+ - link-frequencies
properties:
compatible:
- const: ovti,ov5693
+ enum:
+ - ovti,ov5693
+ - ovti,ov5695
reg:
maxItems: 1
@@ -34,6 +49,9 @@ properties:
System input clock (aka XVCLK). From 6 to 27 MHz.
maxItems: 1
+ clock-names:
+ const: xvclk
+
dovdd-supply:
description:
Digital I/O voltage supply, 1.8V.
@@ -72,7 +90,6 @@ properties:
required:
- data-lanes
- - link-frequencies
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov6211.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov6211.yaml
new file mode 100644
index 000000000000..5a857fa2f371
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov6211.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov6211.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV6211 Image Sensor
+
+description:
+ OmniVision OV6211 image sensor is a high performance monochrome image
+ sensor. The sensor is controlled over a serial camera control bus
+ protocol (SCCB), the widest supported output image frame size is 400x400
+ at 120 frames per second rate, data output format is 8/10-bit RAW
+ transferred over one-lane MIPI D-PHY interface.
+
+maintainers:
+ - Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,ov6211
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: XVCLK supply clock, 6MHz to 27MHz frequency.
+ maxItems: 1
+
+ reset-gpios:
+ description: Active low GPIO connected to XSHUTDOWN pad of the sensor.
+ maxItems: 1
+
+ strobe-gpios:
+ description: Input GPIO connected to strobe pad of the sensor.
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogue voltage supply, 2.6 to 3.0 volts.
+
+ dovdd-supply:
+ description: Digital I/O voltage supply, 1.8 volts.
+
+ dvdd-supply:
+ description: Digital core voltage supply.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@60 {
+ compatible = "ovti,ov6211";
+ reg = <0x60>;
+ clocks = <&camera_clk 0>;
+ assigned-clocks = <&camera_clk 0>;
+ assigned-clock-rates = <24000000>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&vreg_2p8>;
+ dovdd-supply = <&vreg_1p8>;
+ dvdd-supply = <&vreg_1p2>;
+
+ port {
+ endpoint {
+ link-frequencies = /bits/ 64 <480000000>;
+ remote-endpoint = <&mipi_csi2_ep>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
new file mode 100644
index 000000000000..2b6143aff391
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov64a40.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV64A40 Image Sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,ov64a40
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog voltage supply, 2.8 volts
+
+ dvdd-supply:
+ description: Digital core voltage supply, 1.1 volts
+
+ dovdd-supply:
+ description: Digital I/O voltage supply, 1.8 volts
+
+ powerdown-gpios:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ additionalProperties: false
+
+ properties:
+ bus-type:
+ enum:
+ - 1 # MIPI CSI-2 C-PHY
+ - 4 # MIPI CSI-2 D-PHY
+ data-lanes: true
+ link-frequencies: true
+ clock-noncontinuous: true
+ remote-endpoint: true
+
+ required:
+ - bus-type
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@36 {
+ compatible = "ovti,ov64a40";
+ reg = <0x36>;
+ clocks = <&camera_clk>;
+ dovdd-supply = <&vgen4_reg>;
+ avdd-supply = <&vgen3_reg>;
+ dvdd-supply = <&vgen2_reg>;
+ powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ rotation = <180>;
+ orientation = <2>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&mipi_csi2_in>;
+ bus-type = <4>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <456000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml
new file mode 100644
index 000000000000..922996da59b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov7251.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov7251.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV7251 Image Sensor
+
+description:
+ The Omnivision OV7251 is a 1/7.5-Inch CMOS active pixel digital image sensor
+ with an active array size of 640H x 480V. It is programmable through a serial
+ I2C interface.
+
+maintainers:
+ - Todor Tomov <todor.too@gmail.com>
+
+properties:
+ compatible:
+ const: ovti,ov7251
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: XCLK Input Clock
+
+ clock-names:
+ const: xclk
+
+ clock-frequency:
+ description: Frequency of the xclk clock in Hz.
+ deprecated: true
+
+ vdda-supply:
+ description: Analog voltage supply, 2.8 volts
+
+ vddd-supply:
+ description: Digital core voltage supply, 1.2 volts
+
+ vdddo-supply:
+ description: Digital I/O voltage supply, 1.8 volts
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ Reference to the GPIO connected to the XSHUTDOWN pin, if any. Polarity
+ is GPIO_ACTIVE_HIGH.
+
+ port:
+ description: Digital Output Port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maximum: 1
+
+ data-lanes:
+ maxItems: 1
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vdddo-supply
+ - vdda-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@3c {
+ compatible = "ovti,ov7251";
+ reg = <0x3c>;
+
+ clocks = <&clks 1>;
+ assigned-clocks = <&clks 1>;
+ assigned-clock-rates = <24000000>;
+
+ vdddo-supply = <&ov7251_vdddo_1v8>;
+ vdda-supply = <&ov7251_vdda_2v8>;
+ vddd-supply = <&ov7251_vddd_1v5>;
+ enable-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov7251_ep: endpoint {
+ remote-endpoint = <&csi0_ep>;
+ clock-lanes = <1>;
+ data-lanes = <0>;
+ link-frequencies = /bits/ 64 <240000000 319200000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt b/Documentation/devicetree/bindings/media/i2c/ovti,ov7670.txt
index 2c972a56f3cb..2c972a56f3cb 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov7670.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov7670.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
index 44529425ce3a..5d24edba8f99 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
@@ -105,8 +105,9 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
ov772x: camera@21 {
@@ -118,7 +119,7 @@ examples:
port {
ov772x_0: endpoint {
- bus-type = <5>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
vsync-active = <0>;
hsync-active = <0>;
pclk-sample = <0>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt b/Documentation/devicetree/bindings/media/i2c/ovti,ov7740.txt
index af781c3a5f0e..af781c3a5f0e 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov7740.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov7740.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml
new file mode 100644
index 000000000000..fa71f24823f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2019 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov8856.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV8856 CMOS Sensor
+
+maintainers:
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+description: |-
+ The Omnivision OV8856 is a high performance, 1/4-inch, 8 megapixel, CMOS
+ image sensor that delivers 3264x2448 at 30fps. It provides full-frame,
+ sub-sampled, and windowed 10-bit MIPI images in various formats via the
+ Serial Camera Control Bus (SCCB) interface. This chip is programmable
+ through I2C and two-wire SCCB. The sensor output is available via CSI-2
+ serial data output (up to 4-lane).
+
+properties:
+ compatible:
+ const: ovti,ov8856
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description:
+ Input clock for the sensor.
+ items:
+ - const: xvclk
+
+ clock-frequency:
+ description:
+ Frequency of the xvclk clock in Hertz.
+ deprecated: true
+
+ dovdd-supply:
+ description:
+ Definition of the regulator used as interface power supply.
+
+ avdd-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+ dvdd-supply:
+ description:
+ Definition of the regulator used as digital power supply.
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls sensor reset.
+ This corresponds to the hardware pin XSHUTDOWN which is physically
+ active low.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dovdd-supply
+ - avdd-supply
+ - dvdd-supply
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov8856: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ reset-gpios = <&pio 111 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk_24m_cam>;
+
+ clocks = <&cam_osc>;
+ clock-names = "xvclk";
+
+ avdd-supply = <&mt6358_vcama2_reg>;
+ dvdd-supply = <&mt6358_vcamd_reg>;
+ dovdd-supply = <&mt6358_vcamio_reg>;
+
+ port {
+ wcam_out: endpoint {
+ remote-endpoint = <&mipi_in_wcam>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml
new file mode 100644
index 000000000000..491f2931e6bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8858.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov8858.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV8858 Image Sensor
+
+maintainers:
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+ - Nicholas Roth <nicholas@rothemail.net>
+
+description: |
+ The OmniVision OV8858 is a color CMOS 8 Megapixels (3264x2448) image sensor
+ controlled through an I2C-compatible SCCB bus. The sensor transmits images
+ on a MIPI CSI-2 output interface with up to 4 data lanes.
+
+$ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: ovti,ov8858
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: XVCLK external clock
+
+ clock-names:
+ const: xvclk
+
+ dvdd-supply:
+ description: Digital Domain Power Supply
+
+ avdd-supply:
+ description: Analog Domain Power Supply
+
+ dovdd-supply:
+ description: I/O Domain Power Supply
+
+ powerdown-gpios:
+ description: PWDNB powerdown GPIO (active low)
+
+ reset-gpios:
+ maxItems: 1
+ description: XSHUTDN reset GPIO (active low)
+
+ port:
+ description: MIPI CSI-2 transmitter port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov8858: camera@36 {
+ compatible = "ovti,ov8858";
+ reg = <0x36>;
+
+ clocks = <&cru SCLK_CIF_OUT>;
+ clock-names = "xvclk";
+ assigned-clocks = <&cru SCLK_CIF_OUT>;
+ assigned-clock-rates = <24000000>;
+
+ dovdd-supply = <&vcc1v8_dvp>;
+
+ reset-gpios = <&gpio1 RK_PA4 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&gpio2 RK_PB4 GPIO_ACTIVE_LOW>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
index b962863e4f65..320b9aacbb8b 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/i2c/ovti,ov8865.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: OmniVision OV8865 Image Sensor Device Tree Bindings
+title: OmniVision OV8865 Image Sensor
maintainers:
- Paul Kocialkowski <paul.kocialkowski@bootlin.com>
@@ -20,12 +20,6 @@ properties:
items:
- description: EXTCLK Clock
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-rates:
- maxItems: 1
-
dvdd-supply:
description: Digital Domain Power Supply
@@ -68,8 +62,6 @@ required:
- compatible
- reg
- clocks
- - assigned-clocks
- - assigned-clock-rates
- dvdd-supply
- avdd-supply
- dovdd-supply
@@ -82,7 +74,7 @@ examples:
#include <dt-bindings/clock/sun8i-a83t-ccu.h>
#include <dt-bindings/gpio/gpio.h>
- i2c2 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -94,8 +86,6 @@ examples:
pinctrl-0 = <&csi_mclk_pin>;
clocks = <&ccu CLK_CSI_MCLK>;
- assigned-clocks = <&ccu CLK_CSI_MCLK>;
- assigned-clock-rates = <24000000>;
avdd-supply = <&reg_ov8865_avdd>;
dovdd-supply = <&reg_ov8865_dovdd>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml
index bf115ab9d926..401c8613f840 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml
@@ -16,18 +16,17 @@ description:
sensor with an active array size of 1296H x 816V. It is programmable through
I2C interface. The I2C client address is fixed to 0x60/0x70 as per sensor data
sheet. Image data is sent through MIPI CSI-2.
+ OV9281 has a different lens chief ray angle.
properties:
compatible:
- const: ovti,ov9282
+ enum:
+ - ovti,ov9281
+ - ovti,ov9282
reg:
description: I2C address
maxItems: 1
- assigned-clocks: true
- assigned-clock-parents: true
- assigned-clock-rates: true
-
clocks:
description: Clock frequency from 6 to 27MHz
maxItems: 1
@@ -36,6 +35,15 @@ properties:
description: Reference to the GPIO connected to the XCLR pin, if any.
maxItems: 1
+ avdd-supply:
+ description: Analog voltage supply, 2.8 volts
+
+ dvdd-supply:
+ description: Digital core voltage supply, 1.2 volts
+
+ dovdd-supply:
+ description: Digital I/O voltage supply, 1.8 volts
+
port:
additionalProperties: false
$ref: /schemas/graph.yaml#/$defs/port-base
@@ -66,7 +74,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -75,10 +83,6 @@ examples:
reg = <0x60>;
clocks = <&ov9282_clk>;
- assigned-clocks = <&ov9282_clk>;
- assigned-clock-parents = <&ov9282_clk_parent>;
- assigned-clock-rates = <24000000>;
-
port {
ov9282: endpoint {
remote-endpoint = <&cam>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ov9650.txt b/Documentation/devicetree/bindings/media/i2c/ovti,ov9650.txt
index 506dfc52872a..506dfc52872a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov9650.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9650.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml
index f50e54a722eb..34a05df786ce 100644
--- a/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml
@@ -50,7 +50,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml b/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml
new file mode 100644
index 000000000000..4cb0f5aa1301
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/samsung,s5k5baf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ const: samsung,s5k5baf
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
+ clock-frequency:
+ default: 24000000
+ description: mclk clock frequency
+ deprecated: true
+
+ rstn-gpios:
+ maxItems: 1
+ description: RSTN pin
+
+ stbyn-gpios:
+ maxItems: 1
+ description: STDBYN pin
+
+ vdda-supply:
+ description: Analog power supply 2.8V (2.6V to 3.0V)
+
+ vddio-supply:
+ description: I/O power supply 1.8V (1.65V to 1.95V) or 2.8V (2.5V to 3.1V)
+
+ vddreg-supply:
+ description:
+ Regulator input power supply 1.8V (1.7V to 1.9V) or 2.8V (2.6V to 3.0)
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ items:
+ - const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - rstn-gpios
+ - stbyn-gpios
+ - vdda-supply
+ - vddio-supply
+ - vddreg-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@2d {
+ compatible = "samsung,s5k5baf";
+ reg = <0x2d>;
+
+ clocks = <&camera 0>;
+ assigned-clocks = <&camera 0>;
+ assigned-clock-rates = <24000000>;
+
+ clock-names = "mclk";
+ rstn-gpios = <&gpl2 1 GPIO_ACTIVE_LOW>;
+ stbyn-gpios = <&gpl2 0 GPIO_ACTIVE_LOW>;
+ vdda-supply = <&cam_io_en_reg>;
+ vddio-supply = <&vtcam_reg>;
+ vddreg-supply = <&vt_core_15v_reg>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&csis1_ep>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml b/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml
new file mode 100644
index 000000000000..9df1e0f872f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/samsung,s5k6a3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5K6A3(YX) raw image sensor
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data
+ interfaces and CCI (I2C compatible) control bus.
+
+properties:
+ compatible:
+ const: samsung,s5k6a3
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: extclk
+
+ clock-frequency:
+ default: 24000000
+ description: extclk clock frequency
+ deprecated: true
+
+ gpios:
+ maxItems: 1
+ description: GPIO connected to the RESET pin
+
+ afvdd-supply:
+ description: AF (actuator) voltage supply
+
+ svdda-supply:
+ description: Core voltage supply
+
+ svddio-supply:
+ description: I/O voltage supply
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ items:
+ - const: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - gpios
+ - afvdd-supply
+ - svdda-supply
+ - svddio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@10 {
+ compatible = "samsung,s5k6a3";
+ reg = <0x10>;
+
+ clocks = <&camera 1>;
+ assigned-clocks = <&camera 1>;
+ assigned-clock-rates = <24000000>;
+
+ clock-names = "extclk";
+ gpios = <&gpm1 6 GPIO_ACTIVE_LOW>;
+ afvdd-supply = <&ldo19_reg>;
+ svdda-supply = <&cam_io_reg>;
+ svddio-supply = <&ldo19_reg>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&csis1_ep>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
new file mode 100644
index 000000000000..20f48d5e9b2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx111.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX111 8MP CMOS Digital Image Sensor
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ IMX111 sensor is a Sony CMOS active pixel digital image sensor with an active
+ array size of 2464H x 3280V. It is programmable through I2C interface. Image
+ data is sent through MIPI CSI-2, through 1 or 2 lanes.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+ - $ref: /schemas/nvmem/nvmem-consumer.yaml#
+
+properties:
+ compatible:
+ const: sony,imx111
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: EXTCLK with possible frequency from 6 to 54 MHz
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ iovdd-supply:
+ description: Digital IO power supply (1.8V)
+
+ dvdd-supply:
+ description: Digital power supply (1.2V)
+
+ avdd-supply:
+ description: Analog power supply (2.7V)
+
+ port:
+ additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@10 {
+ compatible = "sony,imx111";
+ reg = <0x10>;
+
+ clocks = <&imx111_clk>;
+
+ iovdd-supply = <&camera_vddio_1v8>;
+ dvdd-supply = <&camera_vddd_1v2>;
+ avdd-supply = <&camera_vdda_2v7>;
+
+ orientation = <1>;
+ rotation = <90>;
+
+ nvmem = <&eeprom>;
+ flash-leds = <&led>;
+ lens-focus = <&vcm>;
+
+ reset-gpios = <&gpio 84 GPIO_ACTIVE_LOW>;
+
+ port {
+ imx111_output: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <542400000>;
+ remote-endpoint = <&csi_input>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
index c9760f895b3e..aea99ebf8e9e 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
@@ -16,7 +16,7 @@ description: |
maximum throughput of 1.2Gbps/lane.
allOf:
- - $ref: ../video-interface-devices.yaml#
+ - $ref: /schemas/media/video-interface-devices.yaml#
properties:
compatible:
@@ -33,20 +33,21 @@ properties:
clock-frequency:
description: Frequency of the xclk clock in Hz.
+ deprecated: true
enable-gpios:
description: GPIO descriptor for the enable pin.
maxItems: 1
- vdddo-supply:
- description: Chip digital IO regulator (1.8V).
-
vdda-supply:
description: Chip analog regulator (2.7V).
vddd-supply:
description: Chip digital core regulator (1.12V).
+ vdddo-supply:
+ description: Chip digital IO regulator (1.8V).
+
flash-leds: true
lens-focus: true
@@ -84,42 +85,44 @@ required:
- compatible
- reg
- clocks
- - clock-frequency
- enable-gpios
- - vdddo-supply
- vdda-supply
- vddd-supply
+ - vdddo-supply
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
camera-sensor@1a {
compatible = "sony,imx214";
reg = <0x1a>;
- vdddo-supply = <&pm8994_lvs1>;
- vddd-supply = <&camera_vddd_1v12>;
+
+ clocks = <&camera_clk>;
+ assigned-clocks = <&camera_clk>;
+ assigned-clock-rates = <24000000>;
+
+ enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
+
vdda-supply = <&pm8994_l17>;
+ vddd-supply = <&camera_vddd_1v12>;
+ vdddo-supply = <&pm8994_lvs1>;
+
lens-focus = <&ad5820>;
- enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
- clocks = <&camera_clk>;
- clock-frequency = <24000000>;
port {
imx214_ep: endpoint {
data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <480000000>;
+ link-frequencies = /bits/ 64 <600000000>;
remote-endpoint = <&csiphy0_ep>;
};
};
};
};
-
-...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx219.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx219.yaml
new file mode 100644
index 000000000000..38c3759bcd9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx219.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx219.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony 1/4.0-Inch 8Mpixel CMOS Digital Image Sensor
+
+maintainers:
+ - Dave Stevenson <dave.stevenson@raspberrypi.com>
+
+description: |-
+ The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor
+ with an active array size of 3280H x 2464V. It is programmable through
+ I2C interface. The I2C address is fixed to 0x10 as per sensor data sheet.
+ Image data is sent through MIPI CSI-2, which is configured as either 2 or
+ 4 data lanes.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: sony,imx219
+
+ reg:
+ description: I2C device address
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ VDIG-supply:
+ description:
+ Digital I/O voltage supply, 1.8 volts
+
+ VANA-supply:
+ description:
+ Analog voltage supply, 2.8 volts
+
+ VDDL-supply:
+ description:
+ Digital core voltage supply, 1.2 volts
+
+ reset-gpios:
+ maxItems: 1
+ description: |-
+ Reference to the GPIO connected to the xclr pin, if any.
+ Must be released (set high) after all supplies are applied.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: |-
+ The sensor supports either two-lane, or four-lane operation.
+ If this property is omitted four-lane operation is assumed.
+ For two-lane operation the property must be set to <1 2>.
+ items:
+ - const: 1
+ - const: 2
+
+ clock-noncontinuous: true
+ link-frequencies: true
+
+ required:
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - VANA-supply
+ - VDIG-supply
+ - VDDL-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx219: sensor@10 {
+ compatible = "sony,imx219";
+ reg = <0x10>;
+ clocks = <&imx219_clk>;
+ VANA-supply = <&imx219_vana>; /* 2.8v */
+ VDIG-supply = <&imx219_vdig>; /* 1.8v */
+ VDDL-supply = <&imx219_vddl>; /* 1.2v */
+
+ port {
+ imx219_0: endpoint {
+ remote-endpoint = <&csi1_ep>;
+ data-lanes = <1 2>;
+ clock-noncontinuous;
+ link-frequencies = /bits/ 64 <456000000>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
new file mode 100644
index 000000000000..d105bd357dbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx258.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX258 13 Mpixel CMOS Digital Image Sensor
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |-
+ IMX258 is a diagonal 5.867mm (Type 1/3.06) 13 Mega-pixel CMOS active pixel
+ type stacked image sensor with a square pixel array of size 4208 x 3120. It
+ is programmable through I2C interface. Image data is sent through MIPI
+ CSI-2. The sensor exists in two different models, a standard variant
+ (IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
+ The camera module does not expose the model through registers, so the
+ exact model needs to be specified.
+
+$ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ enum:
+ - sony,imx258
+ - sony,imx258-pdaf
+
+ clocks:
+ description:
+ Clock frequency from 6 to 27 MHz.
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description: |-
+ Reference to the GPIO connected to the XCLR pin, if any.
+
+ vana-supply:
+ description:
+ Analog voltage (VANA) supply, 2.7 V
+
+ vdig-supply:
+ description:
+ Digital I/O voltage (VDIG) supply, 1.2 V
+
+ vif-supply:
+ description:
+ Interface voltage (VIF) supply, 1.8 V
+
+ # See ../video-interfaces.txt for more details
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ - items:
+ - const: 1
+ - const: 2
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@6c {
+ compatible = "sony,imx258";
+ reg = <0x6c>;
+ clocks = <&imx258_clk>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&csi1_ep>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <320000000>;
+ };
+ };
+ };
+ };
+
+ /* Oscillator on the camera board */
+ imx258_clk: clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <19200000>;
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@6c {
+ compatible = "sony,imx258";
+ reg = <0x6c>;
+ clocks = <&imx258_clk>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&csi1_ep>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <633600000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
index 4271fc3cc623..b06a6e75ba97 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
@@ -46,19 +46,23 @@ properties:
required:
- compatible
- reg
+ - clocks
+ - clock-names
- port
additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
imx274: camera-sensor@1a {
compatible = "sony,imx274";
reg = <0x1a>;
+ clocks = <&imx274_clk>;
+ clock-names = "inck";
reset-gpios = <&gpio_sensor 0 0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
new file mode 100644
index 000000000000..e4f49f1435a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx283.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Ideas on Board Oy
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx283.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX283 Sensor
+
+maintainers:
+ - Kieran Bingham <kieran.bingham@ideasonboard.com>
+ - Umang Jain <umang.jain@ideasonboard.com>
+
+description:
+ IMX283 sensor is a Sony CMOS active pixel digital image sensor with an active
+ array size of 5472H x 3648V. It is programmable through I2C interface. The
+ I2C client address is fixed to 0x1a as per sensor data sheet. Image data is
+ sent through MIPI CSI-2.
+
+properties:
+ compatible:
+ const: sony,imx283
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Clock frequency from 6 to 24 MHz.
+ maxItems: 1
+
+ vadd-supply:
+ description: Analog power supply (2.9V)
+
+ vdd1-supply:
+ description: Interface power supply (1.8V)
+
+ vdd2-supply:
+ description: Digital power supply (1.2V)
+
+ reset-gpios:
+ description: Sensor reset (XCLR) GPIO
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ anyOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@1a {
+ compatible = "sony,imx283";
+ reg = <0x1a>;
+ clocks = <&imx283_clk>;
+
+ assigned-clocks = <&imx283_clk>;
+ assigned-clock-parents = <&imx283_clk_parent>;
+ assigned-clock-rates = <12000000>;
+
+ vadd-supply = <&camera_vadd_2v9>;
+ vdd1-supply = <&camera_vdd1_1v8>;
+ vdd2-supply = <&camera_vdd2_1v2>;
+
+ port {
+ imx283: endpoint {
+ remote-endpoint = <&cam>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml
new file mode 100644
index 000000000000..484039671cd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx290.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX290 1/2.8-Inch CMOS Image Sensor
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |-
+ The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with Square
+ Pixel, available in either mono or colour variants. It is programmable
+ through I2C and 4-wire interfaces.
+
+ The sensor output is available via CMOS logic parallel SDR output, Low voltage
+ LVDS DDR output and CSI-2 serial data output. The CSI-2 bus is the default.
+ No bindings have been defined for the other busses.
+
+ imx290lqr is the full model identifier for the colour variant. "sony,imx290"
+ is treated the same as this as it was the original compatible string.
+ imx290llr is the mono version of the sensor.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - sony,imx290lqr # Colour
+ - sony,imx290llr # Monochrome
+ - sony,imx327lqr # Colour
+ - sony,imx462lqr # Colour
+ - sony,imx462llr # Monochrome
+ - const: sony,imx290
+ deprecated: true
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: Input clock (37.125 MHz or 74.25 MHz)
+ items:
+ - const: xclk
+
+ clock-frequency:
+ description: Frequency of the xclk clock in Hz
+ deprecated: true
+
+ vdda-supply:
+ description: Analog power supply (2.9V)
+
+ vddd-supply:
+ description: Digital core power supply (1.2V)
+
+ vdddo-supply:
+ description: Digital I/O power supply (1.8V)
+
+ reset-gpios:
+ description: Sensor reset (XCLR) GPIO
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: |
+ Video output port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ anyOf:
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - vdda-supply
+ - vddd-supply
+ - vdddo-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx290: camera-sensor@1a {
+ compatible = "sony,imx290lqr";
+ reg = <0x1a>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&gcc 90>;
+ clock-names = "xclk";
+ assigned-clocks = <&clks 1>;
+ assigned-clock-rates = <37125000>;
+
+ vdddo-supply = <&camera_vdddo_1v8>;
+ vdda-supply = <&camera_vdda_2v8>;
+ vddd-supply = <&camera_vddd_1v5>;
+
+ reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
+
+ port {
+ imx290_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <222750000 148500000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml
new file mode 100644
index 000000000000..65ad9c100e45
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx296.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx296.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX296 1/2.8-Inch CMOS Image Sensor
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |-
+ The Sony IMX296 is a 1/2.9-Inch active pixel type CMOS Solid-state image
+ sensor with square pixel array and 1.58 M effective pixels. This chip
+ features a global shutter with variable charge-integration time. It is
+ programmable through I2C and 4-wire interfaces. The sensor output is
+ available via CSI-2 serial data output (1 Lane).
+
+properties:
+ compatible:
+ enum:
+ - sony,imx296
+ - sony,imx296ll
+ - sony,imx296lq
+ description:
+ The IMX296 sensor exists in two different models, a colour variant
+ (IMX296LQ) and a monochrome variant (IMX296LL). The device exposes the
+ model through registers, allowing for auto-detection with a common
+ "sony,imx296" compatible string. However, some camera modules disable the
+ ability to read the sensor model register, which disables this feature.
+ In those cases, the exact model needs to be specified as "sony,imx296ll"
+ or "sony,imx296lq".
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: Input clock (37.125 MHz, 54 MHz or 74.25 MHz)
+ items:
+ - const: inck
+
+ avdd-supply:
+ description: Analog power supply (3.3V)
+
+ dvdd-supply:
+ description: Digital power supply (1.2V)
+
+ ovdd-supply:
+ description: Interface power supply (1.8V)
+
+ reset-gpios:
+ description: Sensor reset (XCLR) GPIO
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - avdd-supply
+ - dvdd-supply
+ - ovdd-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx296: camera-sensor@1a {
+ compatible = "sony,imx296";
+ reg = <0x1a>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&gcc 90>;
+ clock-names = "inck";
+
+ avdd-supply = <&camera_vdda_3v3>;
+ dvdd-supply = <&camera_vddd_1v2>;
+ ovdd-supply = <&camera_vddo_1v8>;
+
+ reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
+
+ port {
+ imx296_ep: endpoint {
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml
index f5055b9db693..3842e5130463 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml
@@ -24,10 +24,6 @@ properties:
description: I2C address
maxItems: 1
- assigned-clocks: true
- assigned-clock-parents: true
- assigned-clock-rates: true
-
clocks:
description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz
maxItems: 1
@@ -65,7 +61,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -74,15 +70,11 @@ examples:
reg = <0x1a>;
clocks = <&imx334_clk>;
- assigned-clocks = <&imx334_clk>;
- assigned-clock-parents = <&imx334_clk_parent>;
- assigned-clock-rates = <24000000>;
-
port {
imx334: endpoint {
remote-endpoint = <&cam>;
data-lanes = <1 2 3 4>;
- link-frequencies = /bits/ 64 <891000000>;
+ link-frequencies = /bits/ 64 <891000000 445500000>;
};
};
};
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
index cf2ca2702cc9..80f879b6bd01 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
@@ -24,14 +24,19 @@ properties:
description: I2C address
maxItems: 1
- assigned-clocks: true
- assigned-clock-parents: true
- assigned-clock-rates: true
-
clocks:
description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz
maxItems: 1
+ avdd-supply:
+ description: Analog power supply (2.9V)
+
+ ovdd-supply:
+ description: Interface power supply (1.8V)
+
+ dvdd-supply:
+ description: Digital power supply (1.2V)
+
reset-gpios:
description: Reference to the GPIO connected to the XCLR pin, if any.
maxItems: 1
@@ -66,7 +71,9 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -75,9 +82,11 @@ examples:
reg = <0x1a>;
clocks = <&imx335_clk>;
- assigned-clocks = <&imx335_clk>;
- assigned-clock-parents = <&imx335_clk_parent>;
- assigned-clock-rates = <24000000>;
+ avdd-supply = <&camera_vdda_2v9>;
+ ovdd-supply = <&camera_vddo_1v8>;
+ dvdd-supply = <&camera_vddd_1v2>;
+
+ reset-gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
port {
imx335: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml
index 26d1807d0bb6..5447ab0768a6 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml
@@ -19,15 +19,13 @@ description:
properties:
compatible:
- const: sony,imx412
+ enum:
+ - sony,imx412
+ - sony,imx577
reg:
description: I2C address
maxItems: 1
- assigned-clocks: true
- assigned-clock-parents: true
- assigned-clock-rates: true
-
clocks:
description: Clock frequency 6MHz, 12MHz, 18MHz, 24MHz or 27MHz
maxItems: 1
@@ -75,7 +73,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -84,10 +82,6 @@ examples:
reg = <0x1a>;
clocks = <&imx412_clk>;
- assigned-clocks = <&imx412_clk>;
- assigned-clock-parents = <&imx412_clk_parent>;
- assigned-clock-rates = <24000000>;
-
port {
imx412: endpoint {
remote-endpoint = <&cam>;
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
new file mode 100644
index 000000000000..7c11e871dca6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx415.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony IMX415 CMOS Image Sensor
+
+maintainers:
+ - Michael Riesch <michael.riesch@collabora.com>
+
+description: |-
+ The Sony IMX415 is a diagonal 6.4 mm (Type 1/2.8) CMOS active pixel type
+ solid-state image sensor with a square pixel array and 8.46 M effective
+ pixels. This chip operates with analog 2.9 V, digital 1.1 V, and interface
+ 1.8 V triple power supply, and has low power consumption.
+ The IMX415 is programmable through I2C interface. The sensor output is
+ available via CSI-2 serial data output (two or four lanes).
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: sony,imx415
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Input clock (24 MHz, 27 MHz, 37.125 MHz, 72 MHz or 74.25 MHz)
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog power supply (2.9 V)
+
+ dvdd-supply:
+ description: Digital power supply (1.1 V)
+
+ ovdd-supply:
+ description: Interface power supply (1.8 V)
+
+ reset-gpios:
+ description: Sensor reset (XCLR) GPIO
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - avdd-supply
+ - dvdd-supply
+ - ovdd-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ imx415: camera-sensor@1a {
+ compatible = "sony,imx415";
+ reg = <0x1a>;
+ avdd-supply = <&vcc2v9_cam>;
+ clocks = <&clock_cam>;
+ dvdd-supply = <&vcc1v1_cam>;
+ lens-focus = <&vcm>;
+ orientation = <2>;
+ ovdd-supply = <&vcc1v8_cam>;
+ reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
+ rotation = <180>;
+
+ port {
+ imx415_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&mipi_in>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt
deleted file mode 100644
index 7976e6c40a80..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge
-
-MIPID02 has two CSI-2 input ports, only one of those ports can be active at a
-time. Active port input stream will be de-serialized and its content outputted
-through PARALLEL output port.
-CSI-2 first input port is a dual lane 800Mbps per lane whereas CSI-2 second
-input port is a single lane 800Mbps. Both ports support clock and data lane
-polarity swap. First port also supports data lane swap.
-PARALLEL output port has a maximum width of 12 bits.
-Supported formats are RAW6, RAW7, RAW8, RAW10, RAW12, RGB565, RGB888, RGB444,
-YUV420 8-bit, YUV422 8-bit and YUV420 10-bit.
-
-Required Properties:
-- compatible: shall be "st,st-mipid02"
-- clocks: reference to the xclk input clock.
-- clock-names: shall be "xclk".
-- VDDE-supply: sensor digital IO supply. Must be 1.8 volts.
-- VDDIN-supply: sensor internal regulator supply. Must be 1.8 volts.
-
-Optional Properties:
-- reset-gpios: reference to the GPIO connected to the xsdn pin, if any.
- This is an active low signal to the mipid02.
-
-Required subnodes:
- - ports: A ports node with one port child node per device input and output
- port, in accordance with the video interface bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt. The
- port nodes are numbered as follows:
-
- Port Description
- -----------------------------
- 0 CSI-2 first input port
- 1 CSI-2 second input port
- 2 PARALLEL output
-
-Endpoint node required property for CSI-2 connection is:
-- data-lanes: shall be <1> for Port 1. for Port 0 dual-lane operation shall be
-<1 2> or <2 1>. For Port 0 single-lane operation shall be <1> or <2>.
-Endpoint node optional property for CSI-2 connection is:
-- lane-polarities: any lane can be inverted or not.
-
-Endpoint node required property for PARALLEL connection is:
-- bus-width: shall be set to <6>, <7>, <8>, <10> or <12>.
-Endpoint node optional properties for PARALLEL connection are:
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
-LOW being the default.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
-LOW being the default.
-
-Example:
-
-mipid02: csi2rx@14 {
- compatible = "st,st-mipid02";
- reg = <0x14>;
- status = "okay";
- clocks = <&clk_ext_camera_12>;
- clock-names = "xclk";
- VDDE-supply = <&vdd>;
- VDDIN-supply = <&vdd>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
-
- ep0: endpoint {
- data-lanes = <1 2>;
- remote-endpoint = <&mipi_csi2_in>;
- };
- };
- port@2 {
- reg = <2>;
-
- ep2: endpoint {
- bus-width = <8>;
- hsync-active = <0>;
- vsync-active = <0>;
- remote-endpoint = <&parallel_out>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
new file mode 100644
index 000000000000..4d40e75b4e1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/st,st-mipid02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics MIPID02 CSI-2 to PARALLEL bridge
+
+maintainers:
+ - Benjamin Mugnier <benjamin.mugnier@foss.st.com>
+ - Sylvain Petinot <sylvain.petinot@foss.st.com>
+
+description:
+ MIPID02 has two CSI-2 input ports, only one of those ports can be
+ active at a time. Active port input stream will be de-serialized
+ and its content outputted through PARALLEL output port.
+ CSI-2 first input port is a dual lane 800Mbps per lane whereas CSI-2
+ second input port is a single lane 800Mbps. Both ports support clock
+ and data lane polarity swap. First port also supports data lane swap.
+ PARALLEL output port has a maximum width of 12 bits.
+ Supported formats are RAW6, RAW7, RAW8, RAW10, RAW12, RGB565, RGB888,
+ RGB444, YUV420 8-bit, YUV422 8-bit and YUV420 10-bit.
+
+properties:
+ compatible:
+ const: st,st-mipid02
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: xclk
+
+ VDDE-supply:
+ description:
+ Sensor digital IO supply. Must be 1.8 volts.
+
+ VDDIN-supply:
+ description:
+ Sensor internal regulator supply. Must be 1.8 volts.
+
+ reset-gpios:
+ description:
+ Reference to the GPIO connected to the xsdn pin, if any.
+ This is an active low signal to the mipid02.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 first input port
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description:
+ Single-lane operation shall be <1> or <2> .
+ Dual-lane operation shall be <1 2> or <2 1> .
+ minItems: 1
+ maxItems: 2
+
+ lane-polarities:
+ description:
+ Any lane can be inverted or not.
+ minItems: 1
+ maxItems: 3
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 second input port
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description:
+ Single-lane operation shall be <1> or <2> .
+ maxItems: 1
+
+ lane-polarities:
+ description:
+ Any lane can be inverted or not.
+ maxItems: 1
+
+ required:
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Output port
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-width:
+ enum: [6, 7, 8, 10, 12]
+
+ required:
+ - bus-width
+
+ anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+
+ required:
+ - port@2
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - VDDE-supply
+ - VDDIN-supply
+ - ports
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mipid02: csi2rx@14 {
+ compatible = "st,st-mipid02";
+ reg = <0x14>;
+ clocks = <&clk_ext_camera_12>;
+ clock-names = "xclk";
+ VDDE-supply = <&vdd>;
+ VDDIN-supply = <&vdd>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+
+ ep0: endpoint {
+ data-lanes = <1 2>;
+ remote-endpoint = <&mipi_csi2_in>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+
+ ep2: endpoint {
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ remote-endpoint = <&parallel_out>;
+ };
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-vgxy61.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-vgxy61.yaml
new file mode 100644
index 000000000000..8c28848b226a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/st,st-vgxy61.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2022 STMicroelectronics SA.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/st,st-vgxy61.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics VGxy61 HDR Global Shutter Sensor Family
+
+maintainers:
+ - Benjamin Mugnier <benjamin.mugnier@foss.st.com>
+ - Sylvain Petinot <sylvain.petinot@foss.st.com>
+
+description: |-
+ STMicroelectronics VGxy61 family has a CSI-2 output port. CSI-2 output is a
+ quad lanes 800Mbps per lane.
+ Supported formats are RAW8, RAW10, RAW12, RAW14 and RAW16.
+ Following part number are supported
+ - VG5661 and VG6661 are 1.6 Mpx (1464 x 1104) monochrome and color sensors.
+ Maximum frame rate is 75 fps.
+ - VG5761 and VG6761 are 2.3 Mpx (1944 x 1204) monochrome and color sensors.
+ Maximum frame rate is 60 fps.
+
+properties:
+ compatible:
+ const: st,st-vgxy61
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ VCORE-supply:
+ description:
+ Sensor digital core supply. Must be 1.2 volts.
+
+ VDDIO-supply:
+ description:
+ Sensor digital IO supply. Must be 1.8 volts.
+
+ VANA-supply:
+ description:
+ Sensor analog supply. Must be 2.8 volts.
+
+ reset-gpios:
+ description:
+ Reference to the GPIO connected to the reset pin, if any.
+ This is an active low signal to the vgxy61.
+
+ st,strobe-gpios-polarity:
+ description:
+ Invert polarity of illuminator's lights strobe GPIOs.
+ These GPIOs directly drive the illuminator LEDs.
+ type: boolean
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description:
+ CSI lanes to use
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ remote-endpoint: true
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - clocks
+ - VCORE-supply
+ - VDDIO-supply
+ - VANA-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ vgxy61: csi2tx@10 {
+ compatible = "st,st-vgxy61";
+ reg = <0x10>;
+ clocks = <&clk_ext_camera>;
+ VCORE-supply = <&v1v2>;
+ VDDIO-supply = <&v1v8>;
+ VANA-supply = <&v2v8>;
+ reset-gpios = <&mfxgpio 18 GPIO_ACTIVE_LOW>;
+ port {
+ ep0: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&mipi_csi2_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
new file mode 100644
index 000000000000..060ac6829b66
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2025 STMicroelectronics SA.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/st,vd55g1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics VD55G1 Global Shutter Image Sensor
+
+maintainers:
+ - Benjamin Mugnier <benjamin.mugnier@foss.st.com>
+ - Sylvain Petinot <sylvain.petinot@foss.st.com>
+
+description: |-
+ The STMicroelectronics VD55G1 is a global shutter image sensor with an active
+ array size of 804H x 704V. It is programmable through I2C interface. The I2C
+ address is fixed to 0x10.
+
+ Image data is sent through MIPI CSI-2, which is configured as only 1 data
+ lane. The sensor provides 4 GPIOS that can be used for external LED signal
+ (synchronized with sensor integration periods).
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,vd55g1
+ - st,vd65g4
+ description:
+ VD55G1 is the monochrome variant, while VD65G4 is the color one.
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ vcore-supply:
+ description: Digital core power supply (1.15V)
+
+ vddio-supply:
+ description: Digital IO power supply (1.8V)
+
+ vana-supply:
+ description: Analog power supply (2.8V)
+
+ reset-gpios:
+ description: Sensor reset active low GPIO (XSHUTDOWN)
+ maxItems: 1
+
+ st,leds:
+ description:
+ List sensor's GPIOs used to control strobe light sources during exposure
+ time. The numbers identify the sensor pin on which the illumination
+ system is connected. GPIOs are active-high.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ items:
+ minimum: 0
+ maximum: 3
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ items:
+ - const: 1
+
+ link-frequencies:
+ maxItems: 1
+ items:
+ minimum: 125000000
+ maximum: 600000000
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 2
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vcore-supply
+ - vddio-supply
+ - vana-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera-sensor@10 {
+ compatible = "st,vd55g1";
+ reg = <0x10>;
+
+ clocks = <&camera_clk_12M>;
+
+ vcore-supply = <&camera_vcore_v1v15>;
+ vddio-supply = <&camera_vddio_v1v8>;
+ vana-supply = <&camera_vana_v2v8>;
+
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ st,leds = <2>;
+
+ orientation = <2>;
+ rotation = <0>;
+
+ port {
+ endpoint {
+ data-lanes = <1>;
+ link-frequencies = /bits/ 64 <600000000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
new file mode 100644
index 000000000000..c6673b8539db
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2024 STMicroelectronics SA.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/st,vd56g3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics VD56G3 Global Shutter Image Sensor
+
+maintainers:
+ - Benjamin Mugnier <benjamin.mugnier@foss.st.com>
+ - Sylvain Petinot <sylvain.petinot@foss.st.com>
+
+description: |-
+ The STMicroelectronics VD56G3 is a 1.5 M pixel global shutter image sensor
+ with an active array size of 1124 x 1364 (portrait orientation). It is
+ programmable through I2C, the address is fixed to 0x10. The sensor output is
+ available via CSI-2, which is configured as either 1 or 2 data lanes. The
+ sensor provides 8 GPIOS that can be used for external LED signal
+ (synchronized with sensor integration periods)
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,vd56g3
+ - st,vd66gy
+ description:
+ Two variants are availables; VD56G3 is a monochrome sensor while VD66GY
+ is a colour variant.
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ vcore-supply:
+ description: Digital core power supply (1.15V)
+
+ vddio-supply:
+ description: Digital IO power supply (1.8V)
+
+ vana-supply:
+ description: Analog power supply (2.8V)
+
+ reset-gpios:
+ description: Sensor reset active low GPIO (XSHUTDOWN)
+ maxItems: 1
+
+ st,leds:
+ description:
+ List sensor's GPIOs used to control strobe light sources during exposure
+ time. The numbers identify the sensor pin on which the illumination system
+ is connected. GPIOs are active-high.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 7
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [1, 2]
+
+ link-frequencies:
+ maxItems: 1
+ items:
+ enum: [402000000, 750000000]
+
+ lane-polarities:
+ minItems: 1
+ maxItems: 3
+ description: Any lane can be inverted or not.
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vcore-supply
+ - vddio-supply
+ - vana-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera-sensor@10 {
+ compatible = "st,vd56g3";
+ reg = <0x10>;
+
+ clocks = <&camera_clk_12M>;
+
+ vcore-supply = <&camera_vcore_v1v15>;
+ vddio-supply = <&camera_vddio_v1v8>;
+ vana-supply = <&camera_vana_v2v8>;
+
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ st,leds = <6>;
+
+ orientation = <2>;
+ rotation = <0>;
+
+ port {
+ endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <402000000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
deleted file mode 100644
index e76167999d76..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
+++ /dev/null
@@ -1,178 +0,0 @@
-Device-Tree bindings for the NXP TDA1997x HDMI receiver
-
-The TDA19971/73 are HDMI video receivers.
-
-The TDA19971 Video port output pins can be used as follows:
- - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
- - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
- - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
- - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
- - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
- - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
- - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
- - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
-
-The TDA19973 Video port output pins can be used as follows:
- - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
- - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
- - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
- - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
-
-The Video port output pins are mapped via 4-bit 'pin groups' allowing
-for a variety of connection possibilities including swapping pin order within
-pin groups. The video_portcfg device-tree property consists of register mapping
-pairs which map a chip-specific VP output register to a 4-bit pin group. If
-the pin group needs to be bit-swapped you can use the *_S pin-group defines.
-
-Required Properties:
- - compatible :
- - "nxp,tda19971" for the TDA19971
- - "nxp,tda19973" for the TDA19973
- - reg : I2C slave address
- - interrupts : The interrupt number
- - DOVDD-supply : Digital I/O supply
- - DVDD-supply : Digital Core supply
- - AVDD-supply : Analog supply
- - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
-
-Optional Properties:
- - nxp,audout-format : DAI bus format: "i2s" or "spdif".
- - nxp,audout-width : width of audio output data bus (1-4).
- - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
- - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
- mclk.
-
-The port node shall contain one endpoint child node for its digital
-output video port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Optional Endpoint Properties:
- The following three properties are defined in video-interfaces.txt and
- are valid for the output parallel bus endpoint:
- - hsync-active: Horizontal synchronization polarity. Defaults to active high.
- - vsync-active: Vertical synchronization polarity. Defaults to active high.
- - data-active: Data polarity. Defaults to active high.
-
-Examples:
- - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
- 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
- hdmi-receiver@48 {
- compatible = "nxp,tda19971";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_tda1997x>;
- reg = <0x48>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
- DOVDD-supply = <&reg_3p3v>;
- AVDD-supply = <&reg_1p8v>;
- DVDD-supply = <&reg_1p8v>;
- /* audio */
- #sound-dai-cells = <0>;
- nxp,audout-format = "i2s";
- nxp,audout-layout = <0>;
- nxp,audout-width = <16>;
- nxp,audout-mclk-fs = <128>;
- /*
- * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
- * and Y[11:4] across 16bits in the same pixclk cycle.
- */
- nxp,vidout-portcfg =
- /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
- < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
- /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
- < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
- /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
- < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
- /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */
- < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
-
- port {
- tda1997x_to_ipu1_csi0_mux: endpoint {
- remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
- bus-width = <16>;
- hsync-active = <1>;
- vsync-active = <1>;
- data-active = <1>;
- };
- };
- };
- - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656
- 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
- hdmi-receiver@48 {
- compatible = "nxp,tda19971";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_tda1997x>;
- reg = <0x48>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
- DOVDD-supply = <&reg_3p3v>;
- AVDD-supply = <&reg_1p8v>;
- DVDD-supply = <&reg_1p8v>;
- /* audio */
- #sound-dai-cells = <0>;
- nxp,audout-format = "i2s";
- nxp,audout-layout = <0>;
- nxp,audout-width = <16>;
- nxp,audout-mclk-fs = <128>;
- /*
- * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
- * and Y[11:4] across 16bits in the same pixclk cycle.
- */
- nxp,vidout-portcfg =
- /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
- < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
- /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
- < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
- /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */
- < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
- /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */
- < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
-
- port {
- tda1997x_to_ipu1_csi0_mux: endpoint {
- remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
- bus-width = <16>;
- hsync-active = <1>;
- vsync-active = <1>;
- data-active = <1>;
- };
- };
- };
- - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656
- 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
- hdmi-receiver@48 {
- compatible = "nxp,tda19971";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_tda1997x>;
- reg = <0x48>;
- interrupt-parent = <&gpio1>;
- interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
- DOVDD-supply = <&reg_3p3v>;
- AVDD-supply = <&reg_1p8v>;
- DVDD-supply = <&reg_1p8v>;
- /* audio */
- #sound-dai-cells = <0>;
- nxp,audout-format = "i2s";
- nxp,audout-layout = <0>;
- nxp,audout-width = <16>;
- nxp,audout-mclk-fs = <128>;
- /*
- * The 8bpp BT656 mode outputs YCbCr[11:4] across 8bits over
- * 2 pixclk cycles.
- */
- nxp,vidout-portcfg =
- /* YCbCr[11:8]<->VP[15:12]<->CSI_DATA[19:16] */
- < TDA1997X_VP24_V15_12 TDA1997X_R_CR_CBCR_11_8 >,
- /* YCbCr[7:4]<->VP[11:08]<->CSI_DATA[15:12] */
- < TDA1997X_VP24_V11_08 TDA1997X_R_CR_CBCR_7_4 >,
-
- port {
- tda1997x_to_ipu1_csi0_mux: endpoint {
- remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
- bus-width = <16>;
- hsync-active = <1>;
- vsync-active = <1>;
- data-active = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml
new file mode 100644
index 000000000000..0592d0b9af92
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/techwell,tw9900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Techwell TW9900 NTSC/PAL video decoder
+
+maintainers:
+ - Mehdi Djait <mehdi.djait@bootlin.com>
+
+description:
+ The tw9900 is a multi-standard video decoder, supporting NTSC, PAL standards
+ with auto-detection features.
+
+properties:
+ compatible:
+ const: techwell,tw9900
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: VDD power supply
+
+ reset-gpios:
+ description: GPIO descriptor for the RESET input pin
+ maxItems: 1
+
+ powerdown-gpios:
+ description: GPIO descriptor for the POWERDOWN input pin
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Analog input port
+
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: CVBS over MUX0
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: CVBS over MUX1
+
+ endpoint@2:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Chroma over CIN0 and Y over MUX0
+
+ endpoint@3:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Chroma over CIN0 and Y over MUX1
+
+ oneOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+ - required:
+ - endpoint@2
+ - required:
+ - endpoint@3
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Video port for the decoder output.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/display/sdtv-standards.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ composite_connector {
+ compatible = "composite-video-connector";
+ label = "tv";
+ sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>;
+
+ port {
+ composite_to_tw9900: endpoint {
+ remote-endpoint = <&tw9900_to_composite>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ video-decoder@44 {
+ compatible = "techwell,tw9900";
+ reg = <0x44>;
+
+ vdd-supply = <&tw9900_supply>;
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0>;
+ tw9900_to_composite: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&composite_to_tw9900>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&cif_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
new file mode 100644
index 000000000000..bc339a7374b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Ideas on Board
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/thine,thp7312.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: THine THP7312
+
+maintainers:
+ - Paul Elder <paul.elder@@ideasonboard.com>
+
+description:
+ The THP7312 is a standalone ISP controlled over i2c, and is capable of
+ various image processing and correction functions, including 3A control. It
+ can be connected to CMOS image sensors from various vendors, supporting both
+ MIPI CSI-2 and parallel interfaces. It can also output on either MIPI CSI-2
+ or parallel. The hardware is capable of transmitting and receiving MIPI
+ interleaved data streams with data types or multiple virtual channel
+ identifiers.
+
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
+properties:
+ compatible:
+ const: thine,thp7312
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: CLKI clock input
+
+ thine,boot-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 1
+ description:
+ Boot mode of the THP7312, reflecting the value of the BOOT[0] pin strap.
+ 0 is for the SPI/2-wire slave boot, 1 is for the SPI master boot (from
+ external flash ROM).
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ Reference to the GPIO connected to the RESET_N pin, if any.
+ Must be released (set high) after all supplies are applied.
+
+ vddcore-supply:
+ description:
+ 1.2V supply for core, PLL, MIPI rx and MIPI tx.
+
+ vhtermrx-supply:
+ description:
+ Supply for input (RX). 1.8V for MIPI, or 1.8/2.8/3.3V for parallel.
+
+ vddtx-supply:
+ description:
+ Supply for output (TX). 1.8V for MIPI, or 1.8/2.8/3.3V for parallel.
+
+ vddhost-supply:
+ description:
+ Supply for host interface. 1.8V, 2.8V, or 3.3V.
+
+ vddcmos-supply:
+ description:
+ Supply for sensor interface. 1.8V, 2.8V, or 3.3V.
+
+ vddgpio-0-supply:
+ description:
+ Supply for GPIO_0. 1.8V, 2.8V, or 3.3V.
+
+ vddgpio-1-supply:
+ description:
+ Supply for GPIO_1. 1.8V, 2.8V, or 3.3V.
+
+ orientation: true
+ rotation: true
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ const: 4 # CSI-2 D-PHY
+
+ data-lanes:
+ description:
+ This property is for lane reordering between the THP7312 and the
+ SoC. The sensor supports either two-lane, or four-lane operation.
+ If this property is omitted four-lane operation is assumed. For
+ two-lane operation the property must be set to <1 2>.
+ minItems: 2
+ maxItems: 4
+ items:
+ maximum: 4
+
+ sensors:
+ type: object
+ description: List of connected sensors
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^sensor@[01]$":
+ type: object
+ description:
+ Sensors connected to the first and second input, with one node per
+ sensor.
+
+ properties:
+ thine,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Model of the connected sensors. Must be a valid compatible string.
+
+ reg:
+ description: THP7312 input port number
+ items:
+ - maximum: 1
+
+ data-lanes:
+ $ref: /schemas/media/video-interfaces.yaml#/properties/data-lanes
+ maxItems: 4
+ description:
+ This property is for lane reordering between the THP7312 and the imaging
+ sensor that it is connected to.
+
+ required:
+ - reg
+ - data-lanes
+
+ additionalProperties: false
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - clocks
+ - vddcore-supply
+ - vhtermrx-supply
+ - vddtx-supply
+ - vddhost-supply
+ - vddcmos-supply
+ - vddgpio-0-supply
+ - vddgpio-1-supply
+ - sensors
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@61 {
+ compatible = "thine,thp7312";
+ reg = <0x61>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam1_pins_default>;
+
+ reset-gpios = <&pio 119 GPIO_ACTIVE_LOW>;
+ clocks = <&camera61_clk>;
+
+ vddcore-supply = <&vsys_v4p2>;
+ vhtermrx-supply = <&vsys_v4p2>;
+ vddtx-supply = <&vsys_v4p2>;
+ vddhost-supply = <&vsys_v4p2>;
+ vddcmos-supply = <&vsys_v4p2>;
+ vddgpio-0-supply = <&vsys_v4p2>;
+ vddgpio-1-supply = <&vsys_v4p2>;
+
+ orientation = <0>;
+ rotation = <0>;
+
+ sensors {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@0 {
+ thine,model = "sony,imx258";
+ reg = <0>;
+
+ data-lanes = <4 1 3 2>;
+ };
+ };
+
+ port {
+ thp7312_2_endpoint: endpoint {
+ remote-endpoint = <&mipi_thp7312_2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <4 2 1 3>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml
new file mode 100644
index 000000000000..f6612bb0f667
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub913.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub913.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DS90UB913 FPD-Link III Serializer
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ The TI DS90UB913 is an FPD-Link III video serializer for parallel video.
+
+properties:
+ compatible:
+ enum:
+ - ti,ds90ub913a-q1
+
+ '#gpio-cells':
+ const: 2
+ description:
+ First cell is the GPO pin number, second cell is the flags. The GPO pin
+ number must be in range of [0, 3]. Note that GPOs 2 and 3 are not
+ available in external oscillator mode.
+
+ gpio-controller: true
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference clock connected to the CLKIN pin.
+
+ clock-names:
+ items:
+ - const: clkin
+
+ '#clock-cells':
+ const: 0
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Parallel input port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - pclk-sample
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ description: FPD-Link III output port
+
+ required:
+ - port@0
+ - port@1
+
+ i2c:
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - '#gpio-cells'
+ - gpio-controller
+ - '#clock-cells'
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ serializer {
+ compatible = "ti,ds90ub913a-q1";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ clocks = <&clk_cam_48M>;
+ clock-names = "clkin";
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub913_in: endpoint {
+ remote-endpoint = <&sensor_out>;
+ pclk-sample = <1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&deser_fpd_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+
+ clocks = <&fixed_clock>;
+
+ port {
+ sensor_out: endpoint {
+ remote-endpoint = <&ub913_in>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml
new file mode 100644
index 000000000000..2e129bf573b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub953.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub953.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DS90UB953 FPD-Link III Serializer
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ The TI DS90UB953 is an FPD-Link III video serializer for MIPI CSI-2.
+
+properties:
+ compatible:
+ enum:
+ - ti,ds90ub953-q1
+ - ti,ds90ub971-q1
+
+ '#gpio-cells':
+ const: 2
+ description:
+ First cell is the GPIO pin number, second cell is the flags. The GPIO pin
+ number must be in range of [0, 3].
+
+ gpio-controller: true
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference clock connected to the CLKIN pin.
+
+ clock-names:
+ items:
+ - const: clkin
+
+ '#clock-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+ description:
+ The strap I2C address of the serializer. Can be used by the deserializer
+ to communicate over back-channel when the forward-channel is not yet
+ active.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 input port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ unevaluatedProperties: false
+ description: FPD-Link III output port
+
+ required:
+ - port@0
+ - port@1
+
+ i2c:
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - '#gpio-cells'
+ - gpio-controller
+ - '#clock-cells'
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ link {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ serializer@18 {
+ compatible = "ti,ds90ub953-q1";
+ reg = <0x18>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub953_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&sensor_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&deser_fpd_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@1a {
+ compatible = "sony,imx274";
+ reg = <0x1a>;
+
+ reset-gpios = <&serializer 0 GPIO_ACTIVE_LOW>;
+
+ clocks = <&serializer>;
+ clock-names = "inck";
+
+ port {
+ sensor_out: endpoint {
+ remote-endpoint = <&ub953_in>;
+ };
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml
new file mode 100644
index 000000000000..0539d52de422
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml
@@ -0,0 +1,441 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ti,ds90ub960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DS90UB9XX Family FPD-Link Deserializer Hubs
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+description:
+ The TI DS90UB9XX devices are FPD-Link video deserializers with I2C and GPIO
+ forwarding.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-atr.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,ds90ub960-q1
+ - ti,ds90ub9702-q1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference clock connected to the REFCLK pin.
+
+ clock-names:
+ items:
+ - const: refclk
+
+ powerdown-gpios:
+ maxItems: 1
+ description:
+ Specifier for the GPIO connected to the PDB pin.
+
+ i2c-alias-pool:
+ minItems: 1
+ maxItems: 32
+
+ links:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ ti,manual-strobe:
+ type: boolean
+ description:
+ Enable manual strobe position and EQ level
+
+ patternProperties:
+ '^link@[0-3]$':
+ type: object
+ additionalProperties: false
+ properties:
+ reg:
+ description: The link number
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ i2c-alias:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The I2C address used for the serializer. Transactions to this
+ address on the I2C bus where the deserializer resides are
+ forwarded to the serializer.
+
+ ti,rx-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # RAW10
+ - 1 # RAW12 HF
+ - 2 # RAW12 LF
+ - 3 # CSI2 SYNC
+ - 4 # CSI2 NON-SYNC
+ description:
+ FPD-Link Input Mode. This should reflect the hardware and the
+ default mode of the connected device.
+
+ ti,cdr-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # FPD-Link III
+ - 1 # FPD-Link IV
+ description:
+ FPD-Link CDR Mode. This should reflect the hardware and the
+ default mode of the connected device.
+
+ ti,strobe-pos:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -13
+ maximum: 13
+ description: Manual strobe position
+
+ ti,eq-level:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 14
+ description: Manual EQ level
+
+ patternProperties:
+ '^serializer(@[0-9a-f]+)*$':
+ type: object
+ description: FPD-Link Serializer node
+
+ required:
+ - reg
+ - i2c-alias
+ - ti,rx-mode
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 0
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 1
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 2
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: FPD-Link input 3
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+ description:
+ Endpoint for FPD-Link port. If the RX mode for this port is RAW,
+ hsync-active and vsync-active must be defined.
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output 0
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ link-frequencies:
+ maxItems: 1
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ port@5:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output 1
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ link-frequencies:
+ maxItems: 1
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - port@0
+ - port@1
+ - port@2
+ - port@3
+ - port@4
+ - port@5
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+
+ clock-names = "refclk";
+ clocks = <&fixed_clock>;
+
+ powerdown-gpios = <&pca9555 7 GPIO_ACTIVE_LOW>;
+
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Port 0, Camera 0 */
+ port@0 {
+ reg = <0>;
+
+ ub960_fpd3_1_in: endpoint {
+ remote-endpoint = <&ub953_1_out>;
+ };
+ };
+
+ /* Port 1, Camera 1 */
+ port@1 {
+ reg = <1>;
+
+ ub960_fpd3_2_in: endpoint {
+ remote-endpoint = <&ub913_2_out>;
+ hsync-active = <0>;
+ vsync-active = <1>;
+ };
+ };
+
+ /* Port 2, unconnected */
+ port@2 {
+ reg = <2>;
+ };
+
+ /* Port 3, unconnected */
+ port@3 {
+ reg = <3>;
+ };
+
+ /* Port 4, CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ /* Port 5, unconnected */
+ port@5 {
+ reg = <5>;
+ };
+ };
+
+ links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Link 0 has DS90UB953 serializer and IMX274 sensor */
+
+ link@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0>;
+ i2c-alias = <0x44>;
+
+ ti,rx-mode = <3>;
+
+ serializer1: serializer@30 {
+ compatible = "ti,ds90ub953-q1";
+ reg = <0x30>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub953_1_in: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&sensor_1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ub953_1_out: endpoint {
+ remote-endpoint = <&ub960_fpd3_1_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@1a {
+ compatible = "sony,imx274";
+ reg = <0x1a>;
+
+ clocks = <&serializer>;
+ clock-names = "inck";
+
+ reset-gpios = <&serializer1 0 GPIO_ACTIVE_LOW>;
+
+ port {
+ sensor_1_out: endpoint {
+ remote-endpoint = <&ub953_1_in>;
+ };
+ };
+ };
+ };
+ };
+ }; /* End of link@0 */
+
+ /* Link 1 has DS90UB913 serializer and MT9V111 sensor */
+
+ link@1 {
+ reg = <1>;
+ i2c-alias = <0x45>;
+
+ ti,rx-mode = <0>;
+
+ serializer2: serializer {
+ compatible = "ti,ds90ub913a-q1";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ clocks = <&clk_cam_48M>;
+ clock-names = "clkin";
+
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ub913_2_in: endpoint {
+ remote-endpoint = <&sensor_2_out>;
+ pclk-sample = <1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ub913_2_out: endpoint {
+ remote-endpoint = <&ub960_fpd3_2_in>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+
+ clocks = <&serializer2>;
+
+ port {
+ sensor_2_out: endpoint {
+ remote-endpoint = <&ub913_2_in>;
+ };
+ };
+ };
+ };
+ };
+ }; /* End of link@1 */
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/i2c/ths8200.txt b/Documentation/devicetree/bindings/media/i2c/ti,ths8200.txt
index 285f6ae7dfa9..285f6ae7dfa9 100644
--- a/Documentation/devicetree/bindings/media/i2c/ths8200.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ti,ths8200.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt b/Documentation/devicetree/bindings/media/i2c/ti,tvp514x.txt
index 46752cc71f2e..46752cc71f2e 100644
--- a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ti,tvp514x.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml b/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml
new file mode 100644
index 000000000000..382a29652a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ti,tvp5150.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TVP5150 and TVP5151 video decoders
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
+ (and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
+ with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
+
+properties:
+ compatible:
+ const: ti,tvp5150
+
+ reg:
+ maxItems: 1
+
+ pdn-gpios:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ sink port node, AIP1A
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ sink port node, AIP1B
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ source port node, Y-OUT
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - port@2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/display/sdtv-standards.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@5c {
+ compatible = "ti,tvp5150";
+ reg = <0x5c>;
+ pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&composite0_to_tvp5150>;
+ };
+
+ endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&svideo_luma_to_tvp5150>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&composite1_to_tvp5150>;
+ };
+
+ endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&svideo_chroma_to_tvp5150>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&ccdc_ep>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/ti,tvp7002.txt
index 5f28b5d9abcc..5f28b5d9abcc 100644
--- a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
+++ b/Documentation/devicetree/bindings/media/i2c/ti,tvp7002.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
index e80d5891b7ed..8d8e40c56872 100644
--- a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
@@ -13,9 +13,6 @@ Mandatory properties
- reg: I2C address (0x3e, or an alternative address)
- vana-supply: Analogue voltage supply (VANA), 2.8 volts
- clocks: External clock to the sensor
-- clock-frequency: Frequency of the external clock to the sensor. Camera
- driver will set this frequency on the external clock. The clock frequency is
- a pre-determined frequency known to be suitable to the board.
- reset-gpios: XSHUTDOWN GPIO. The XSHUTDOWN signal is active low. The sensor
is in hardware standby mode when the signal is in the low state.
@@ -43,8 +40,11 @@ Example
compatible = "toshiba,et8ek8";
reg = <0x3e>;
vana-supply = <&vaux4>;
+
clocks = <&isp 0>;
- clock-frequency = <9600000>;
+ assigned-clocks = <&isp 0>;
+ assigned-clock-rates = <9600000>;
+
reset-gpio = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102 */
port {
csi_cam1: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/tc358743.txt b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt
index 59102edcf01e..59102edcf01e 100644
--- a/Documentation/devicetree/bindings/media/i2c/tc358743.txt
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
new file mode 100644
index 000000000000..1c476b635b69
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,tc358746.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/toshiba,tc358746.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC358746 Parallel to MIPI CSI2 Bridge
+
+maintainers:
+ - Marco Felsch <kernel@pengutronix.de>
+
+description: |-
+ The Toshiba TC358746 converts a parallel video stream into a MIPI CSI-2
+ stream. The direction can be either parallel-in -> csi-out or csi-in ->
+ parallel-out The chip is programmable through I2C and SPI but the SPI
+ interface is only supported in parallel-in -> csi-out mode.
+
+ Note that the current device tree bindings only support the
+ parallel-in -> csi-out path.
+
+properties:
+ compatible:
+ const: toshiba,tc358746
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description:
+ The phandle to the reference clock source. This corresponds to the
+ hardware pin REFCLK.
+ maxItems: 1
+
+ clock-names:
+ const: refclk
+
+ "#clock-cells":
+ description: |
+ The bridge can act as clock provider for the sensor. To enable this
+ support #clock-cells must be specified. Attention if this feature is used
+ then the mclk rate must be at least: (2 * link-frequency) / 8
+ `------------------´ ^
+ internal PLL rate smallest possible
+ mclk-div
+ const: 0
+
+ clock-output-names:
+ description:
+ The clock name of the MCLK output, the default name is tc358746-mclk.
+ maxItems: 1
+
+ vddc-supply:
+ description: Digital core voltage supply, 1.2 volts
+
+ vddio-supply:
+ description: Digital I/O voltage supply, 1.8 volts
+
+ vddmipi-supply:
+ description: MIPI CSI phy voltage supply, 1.2 volts
+
+ reset-gpios:
+ description:
+ The phandle and specifier for the GPIO that controls the chip reset.
+ This corresponds to the hardware pin RESX which is physically active low.
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Input port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ hsync-active: true
+ vsync-active: true
+ bus-type:
+ enum: [ 5, 6 ]
+
+ required:
+ - hsync-active
+ - vsync-active
+ - bus-type
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Output port
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ clock-noncontinuous: true
+ link-frequencies: true
+
+ required:
+ - data-lanes
+ - link-frequencies
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - vddc-supply
+ - vddio-supply
+ - vddmipi-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi-bridge@e {
+ compatible = "toshiba,tc358746";
+ reg = <0xe>;
+
+ clocks = <&refclk>;
+ clock-names = "refclk";
+
+ reset-gpios = <&gpio 2 GPIO_ACTIVE_LOW>;
+
+ vddc-supply = <&v1_2d>;
+ vddio-supply = <&v1_8d>;
+ vddmipi-supply = <&v1_2d>;
+
+ /* sensor mclk provider */
+ #clock-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Input */
+ port@0 {
+ reg = <0>;
+ tc358746_in: endpoint {
+ remote-endpoint = <&sensor_out>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ bus-type = <5>;
+ };
+ };
+
+ /* Output */
+ port@1 {
+ reg = <1>;
+ tc358746_out: endpoint {
+ remote-endpoint = <&mipi_csi2_in>;
+ data-lanes = <1 2>;
+ clock-noncontinuous;
+ link-frequencies = /bits/ 64 <216000000>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
deleted file mode 100644
index 719b2995dc17..000000000000
--- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-* Texas Instruments TVP5150 and TVP5151 video decoders
-
-The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
-(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
-with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
-
-Required Properties:
-====================
-- compatible: Value must be "ti,tvp5150".
-- reg: I2C slave address.
-
-Optional Properties:
-====================
-- pdn-gpios: Phandle for the GPIO connected to the PDN pin, if any.
-- reset-gpios: Phandle for the GPIO connected to the RESETB pin, if any.
-
-The device node must contain one 'port' child node per device physical input
-and output port, in accordance with the video interface bindings defined in
-Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
-are numbered as follows
-
- Name Type Port
- --------------------------------------
- AIP1A sink 0
- AIP1B sink 1
- Y-OUT src 2
-
-The device node must contain at least one sink port and the src port. Each input
-port must be linked to an endpoint defined in [1]. The port/connector layout is
-as follows
-
-tvp-5150 port@0 (AIP1A)
- endpoint@0 -----------> Comp0-Con port
- endpoint@1 ------+----> Svideo-Con port
-tvp-5150 port@1 (AIP1B) |
- endpoint@1 ------+
- endpoint@0 -----------> Comp1-Con port
-tvp-5150 port@2
- endpoint (video bitstream output at YOUT[0-7] parallel bus)
-
-Required Endpoint Properties for parallel synchronization on output port:
-=========================================================================
-
-- hsync-active: Active state of the HSYNC signal. Must be <1> (HIGH).
-- vsync-active: Active state of the VSYNC signal. Must be <1> (HIGH).
-- field-even-active: Field signal level during the even field data
- transmission. Must be <0>.
-
-Note: Do not specify any of these properties if you want to use the embedded
- BT.656 synchronization.
-
-Optional Connector Properties:
-==============================
-
-- sdtv-standards: Set the possible signals to which the hardware tries to lock
- instead of using the autodetection mechnism. Please look at
- [1] for more information.
-
-[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml.
-
-Example - three input sources:
-#include <dt-bindings/display/sdtv-standards.h>
-
-comp_connector_0 {
- compatible = "composite-video-connector";
- label = "Composite0";
- sdtv-standards = <SDTV_STD_PAL_M>; /* limit to pal-m signals */
-
- port {
- composite0_to_tvp5150: endpoint {
- remote-endpoint = <&tvp5150_to_composite0>;
- };
- };
-};
-
-comp_connector_1 {
- compatible = "composite-video-connector";
- label = "Composite1";
- sdtv-standards = <SDTV_STD_NTSC_M>; /* limit to ntsc-m signals */
-
- port {
- composite1_to_tvp5150: endpoint {
- remote-endpoint = <&tvp5150_to_composite1>;
- };
- };
-};
-
-svideo_connector {
- compatible = "svideo-connector";
- label = "S-Video";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- svideo_luma_to_tvp5150: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&tvp5150_to_svideo_luma>;
- };
-
- svideo_chroma_to_tvp5150: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&tvp5150_to_svideo_chroma>;
- };
- };
-};
-
-&i2c2 {
- tvp5150@5c {
- compatible = "ti,tvp5150";
- reg = <0x5c>;
- pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
- reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- tvp5150_to_composite0: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&composite0_to_tvp5150>;
- };
-
- tvp5150_to_svideo_luma: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&svideo_luma_to_tvp5150>;
- };
- };
-
- port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <1>;
-
- tvp5150_to_composite1: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&composite1_to_tvp5150>;
- };
-
- tvp5150_to_svideo_chroma: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&svideo_chroma_to_tvp5150>;
- };
- };
-
- port@2 {
- reg = <2>;
-
- tvp5150_1: endpoint {
- remote-endpoint = <&ccdc_ep>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/img,e5010-jpeg-enc.yaml b/Documentation/devicetree/bindings/media/img,e5010-jpeg-enc.yaml
new file mode 100644
index 000000000000..085020cb9e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/img,e5010-jpeg-enc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/img,e5010-jpeg-enc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination E5010 JPEG Encoder
+
+maintainers:
+ - Devarsh Thakkar <devarsht@ti.com>
+
+description: |
+ The E5010 is a JPEG encoder from Imagination Technologies implemented on
+ TI's AM62A SoC. It is capable of real time encoding of YUV420 and YUV422
+ inputs to JPEG and M-JPEG. It supports baseline JPEG Encoding up to
+ 8Kx8K resolution.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: ti,am62a-jpeg-enc
+ - const: img,e5010-jpeg-enc
+ - const: img,e5010-jpeg-enc
+
+ reg:
+ items:
+ - description: The E5010 core register region
+ - description: The E5010 mmu register region
+
+ reg-names:
+ items:
+ - const: core
+ - const: mmu
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ jpeg-encoder@fd20000 {
+ compatible = "img,e5010-jpeg-enc";
+ reg = <0x00 0xfd20000 0x00 0x100>,
+ <0x00 0xfd20200 0x00 0x200>;
+ reg-names = "core", "mmu";
+ clocks = <&k3_clks 201 0>;
+ power-domains = <&k3_pds 201 TI_SCI_PD_EXCLUSIVE>;
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
deleted file mode 100644
index 77f4b0a7fd2b..000000000000
--- a/Documentation/devicetree/bindings/media/imx.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Freescale i.MX Media Video Device
-=================================
-
-Video Media Controller node
----------------------------
-
-This is the media controller node for video capture support. It is a
-virtual device that lists the camera serial interface nodes that the
-media device will control.
-
-Required properties:
-- compatible : "fsl,imx-capture-subsystem";
-- ports : Should contain a list of phandles pointing to camera
- sensor interface ports of IPU devices
-
-example:
-
-capture-subsystem {
- compatible = "fsl,imx-capture-subsystem";
- ports = <&ipu1_csi0>, <&ipu1_csi1>;
-};
-
-
-mipi_csi2 node
---------------
-
-This is the device node for the MIPI CSI-2 Receiver core in the i.MX
-SoC. This is a Synopsys Designware MIPI CSI-2 host controller core
-combined with a D-PHY core mixed into the same register block. In
-addition this device consists of an i.MX-specific "CSI2IPU gasket"
-glue logic, also controlled from the same register block. The CSI2IPU
-gasket demultiplexes the four virtual channel streams from the host
-controller's 32-bit output image bus onto four 16-bit parallel busses
-to the i.MX IPU CSIs.
-
-Required properties:
-- compatible : "fsl,imx6-mipi-csi2";
-- reg : physical base address and length of the register set;
-- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
- (the D-PHY clock), video_27m (D-PHY PLL reference
- clock), and eim_podf;
-- clock-names : must contain "dphy", "ref", "pix";
-- port@* : five port nodes must exist, containing endpoints
- connecting to the source and sink devices according to
- of_graph bindings. The first port is an input port,
- connecting with a MIPI CSI-2 source, and ports 1
- through 4 are output ports connecting with parallel
- bus sink endpoint nodes and correspond to the four
- MIPI CSI-2 virtual channel outputs.
-
-Optional properties:
-- interrupts : must contain two level-triggered interrupts,
- in order: 100 and 101;
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
index b39b84c5f012..de3e483f146a 100644
--- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
+++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/media/marvell,mmp2-ccic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell MMP2 camera host interface bindings
+title: Marvell MMP2 camera host interface
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
@@ -68,6 +68,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/marvell,mmp2.h>
+ #include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/power/marvell,mmp2.h>
camera@d420a000 {
@@ -83,7 +84,7 @@ examples:
port {
camera0_0: endpoint {
remote-endpoint = <&ov7670_0>;
- bus-type = <5>; /* Parallel */
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
hsync-active = <1>; /* Active high */
vsync-active = <1>; /* Active high */
pclk-sample = <0>; /* Falling */
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
new file mode 100644
index 000000000000..40fda59fa8a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-fg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 Film Grain
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Moudy Ho <moudy.ho@mediatek.com>
+
+description:
+ Film Grain (FG) is a Media Data Path 3 (MDP3) component used to add
+ the film grain according to the AOMedia Video 1 (AV1) standard.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8195-mdp3-fg
+ - items:
+ - const: mediatek,mt8188-mdp3-fg
+ - const: mediatek,mt8195-mdp3-fg
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description:
+ The register of display function block to be set by gce. There are 4 arguments,
+ such as gce node, subsys id, offset and register size. The subsys id that is
+ mapping to the register of display function blocks is defined in the gce header
+ include/dt-bindings/gce/<chip>-gce.h of each chips.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of GCE
+ - description: GCE subsys id
+ - description: register offset
+ - description: register size
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+
+ display@14002000 {
+ compatible = "mediatek,mt8195-mdp3-fg";
+ reg = <0x14002000 0x1000>;
+ mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x2000 0x1000>;
+ clocks = <&vppsys0 CLK_VPP0_MDP_FG>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
new file mode 100644
index 000000000000..d9f926c20220
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-hdr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 HDR
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Moudy Ho <moudy.ho@mediatek.com>
+
+description:
+ A Media Data Path 3 (MDP3) component used to perform conversion from
+ High Dynamic Range (HDR) to Standard Dynamic Range (SDR).
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8195-mdp3-hdr
+ - items:
+ - const: mediatek,mt8188-mdp3-hdr
+ - const: mediatek,mt8195-mdp3-hdr
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description:
+ The register of display function block to be set by gce. There are 4 arguments,
+ such as gce node, subsys id, offset and register size. The subsys id that is
+ mapping to the register of display function blocks is defined in the gce header
+ include/dt-bindings/gce/<chip>-gce.h of each chips.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of GCE
+ - description: GCE subsys id
+ - description: register offset
+ - description: register size
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+
+ display@14004000 {
+ compatible = "mediatek,mt8195-mdp3-hdr";
+ reg = <0x14004000 0x1000>;
+ mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x4000 0x1000>;
+ clocks = <&vppsys0 CLK_VPP0_MDP_HDR>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 9cfc0c7d23e0..18603f6c5e06 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -20,14 +20,21 @@ description: |
properties:
compatible:
- items:
- - const: mediatek,mt8183-mdp3-rdma
+ oneOf:
+ - enum:
+ - mediatek,mt8183-mdp3-rdma
+ - mediatek,mt8188-mdp3-rdma
+ - mediatek,mt8195-mdp3-rdma
+ - mediatek,mt8195-vdo1-rdma
+ - items:
+ - const: mediatek,mt8188-vdo1-rdma
+ - const: mediatek,mt8195-vdo1-rdma
reg:
maxItems: 1
mediatek,gce-client-reg:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
items:
- description: phandle of GCE
@@ -45,6 +52,14 @@ properties:
include/dt-bindings/gce/<chip>-gce.h of each chips.
$ref: /schemas/types.yaml#/definitions/uint32-array
+ mediatek,scp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the System Control Processor (SCP) used for initializing
+ and stopping the MDP3, for sending frame data locations to the MDP3's
+ VPU and to install Inter-Processor Interrupt handlers to control
+ processing states.
+
power-domains:
maxItems: 1
@@ -52,6 +67,7 @@ properties:
items:
- description: RDMA clock
- description: RSZ clock
+ minItems: 1
iommus:
maxItems: 1
@@ -60,16 +76,72 @@ properties:
items:
- description: used for 1st data pipe from RDMA
- description: used for 2nd data pipe from RDMA
+ - description: used for 3rd data pipe from RDMA
+ - description: used for 4th data pipe from RDMA
+ - description: used for the data pipe from SPLIT
+ minItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#dma-cells':
+ const: 1
required:
- compatible
- reg
- mediatek,gce-client-reg
- - mediatek,gce-events
- power-domains
- clocks
- iommus
- - mboxes
+ - '#dma-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8183-mdp3-rdma
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ mboxes:
+ minItems: 2
+
+ required:
+ - mboxes
+ - mediatek,gce-events
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8195-mdp3-rdma
+
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ mboxes:
+ minItems: 5
+
+ required:
+ - mediatek,gce-events
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8195-vdo1-rdma
+
+ then:
+ properties:
+ clocks:
+ maxItems: 1
additionalProperties: false
@@ -80,16 +152,17 @@ examples:
#include <dt-bindings/power/mt8183-power.h>
#include <dt-bindings/memory/mt8183-larb-port.h>
- mdp3_rdma0: mdp3-rdma0@14001000 {
- compatible = "mediatek,mt8183-mdp3-rdma";
- reg = <0x14001000 0x1000>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>;
- mediatek,gce-events = <CMDQ_EVENT_MDP_RDMA0_SOF>,
- <CMDQ_EVENT_MDP_RDMA0_EOF>;
- power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
- <&mmsys CLK_MM_MDP_RSZ1>;
- iommus = <&iommu>;
- mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
- <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+ dma-controller@14001000 {
+ compatible = "mediatek,mt8183-mdp3-rdma";
+ reg = <0x14001000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>;
+ mediatek,gce-events = <CMDQ_EVENT_MDP_RDMA0_SOF>,
+ <CMDQ_EVENT_MDP_RDMA0_EOF>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MDP_RSZ1>;
+ iommus = <&iommu>;
+ mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+ #dma-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
index 78f9de6192ef..8124c39d73e9 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
@@ -15,9 +15,14 @@ description: |
properties:
compatible:
- items:
+ oneOf:
- enum:
- mediatek,mt8183-mdp3-rsz
+ - items:
+ - enum:
+ - mediatek,mt8188-mdp3-rsz
+ - mediatek,mt8195-mdp3-rsz
+ - const: mediatek,mt8183-mdp3-rsz
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
new file mode 100644
index 000000000000..1d8e7e202c42
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-stitch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 STITCH
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Moudy Ho <moudy.ho@mediatek.com>
+
+description:
+ One of Media Data Path 3 (MDP3) components used to combine multiple video frame
+ with overlapping fields of view to produce a segmented panorame.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8195-mdp3-stitch
+ - items:
+ - const: mediatek,mt8188-mdp3-stitch
+ - const: mediatek,mt8195-mdp3-stitch
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description:
+ The register of display function block to be set by gce. There are 4 arguments,
+ such as gce node, subsys id, offset and register size. The subsys id that is
+ mapping to the register of display function blocks is defined in the gce header
+ include/dt-bindings/gce/<chip>-gce.h of each chips.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of GCE
+ - description: GCE subsys id
+ - description: register offset
+ - description: register size
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+
+ display@14003000 {
+ compatible = "mediatek,mt8195-mdp3-stitch";
+ reg = <0x14003000 0x1000>;
+ mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x3000 0x1000>;
+ clocks = <&vppsys0 CLK_VPP0_STITCH>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
new file mode 100644
index 000000000000..6cff7c073ce4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 Tone Curve Conversion
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description:
+ Tone Curve Conversion (TCC) is one of Media Profile Path 3 (MDP3) components.
+ It is used to handle the tone mapping of various gamma curves in order to
+ achieve HDR10 effects. This helps adapt the content to the color and
+ brightness range that standard display devices typically support.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8195-mdp3-tcc
+ - items:
+ - const: mediatek,mt8188-mdp3-tcc
+ - const: mediatek,mt8195-mdp3-tcc
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description:
+ The register of display function block to be set by gce. There are 4 arguments,
+ such as gce node, subsys id, offset and register size. The subsys id that is
+ mapping to the register of display function blocks is defined in the gce header
+ include/dt-bindings/gce/<chip>-gce.h of each chips.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of GCE
+ - description: GCE subsys id
+ - description: register offset
+ - description: register size
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+
+ display@1400b000 {
+ compatible = "mediatek,mt8195-mdp3-tcc";
+ reg = <0x1400b000 0x1000>;
+ mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0xb000 0x1000>;
+ clocks = <&vppsys0 CLK_VPP0_MDP_TCC>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
new file mode 100644
index 000000000000..cdfa27324738
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tdshp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 Two-Dimensional Sharpness
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+ - Moudy Ho <moudy.ho@mediatek.com>
+
+description:
+ Two-Dimensional Sharpness (TDSHP) is a Media Profile Path 3 (MDP3) component
+ used to perform image edge sharpening and enhance vividness and contrast.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8195-mdp3-tdshp
+ - items:
+ - const: mediatek,mt8188-mdp3-tdshp
+ - const: mediatek,mt8195-mdp3-tdshp
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description:
+ The register of display function block to be set by gce. There are 4 arguments,
+ such as gce node, subsys id, offset and register size. The subsys id that is
+ mapping to the register of display function blocks is defined in the gce header
+ include/dt-bindings/gce/<chip>-gce.h of each chips.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of GCE
+ - description: GCE subsys id
+ - description: register offset
+ - description: register size
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/gce/mt8195-gce.h>
+
+ display@14007000 {
+ compatible = "mediatek,mt8195-mdp3-tdshp";
+ reg = <0x14007000 0x1000>;
+ mediatek,gce-client-reg = <&gce1 SUBSYS_1400XXXX 0x7000 0x1000>;
+ clocks = <&vppsys0 CLK_VPP0_MDP_TDSHP>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
index 0baa77198fa2..b6269f4f9fd6 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -15,9 +15,14 @@ description: |
properties:
compatible:
- items:
+ oneOf:
- enum:
- mediatek,mt8183-mdp3-wrot
+ - items:
+ - enum:
+ - mediatek,mt8188-mdp3-wrot
+ - mediatek,mt8195-mdp3-wrot
+ - const: mediatek,mt8183-mdp3-wrot
reg:
maxItems: 1
@@ -50,6 +55,9 @@ properties:
iommus:
maxItems: 1
+ '#dma-cells':
+ const: 1
+
required:
- compatible
- reg
@@ -58,6 +66,7 @@ required:
- power-domains
- clocks
- iommus
+ - '#dma-cells'
additionalProperties: false
@@ -68,13 +77,14 @@ examples:
#include <dt-bindings/power/mt8183-power.h>
#include <dt-bindings/memory/mt8183-larb-port.h>
- mdp3_wrot0: mdp3-wrot0@14005000 {
- compatible = "mediatek,mt8183-mdp3-wrot";
- reg = <0x14005000 0x1000>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
- mediatek,gce-events = <CMDQ_EVENT_MDP_WROT0_SOF>,
- <CMDQ_EVENT_MDP_WROT0_EOF>;
- power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
- clocks = <&mmsys CLK_MM_MDP_WROT0>;
- iommus = <&iommu>;
+ dma-controller@14005000 {
+ compatible = "mediatek,mt8183-mdp3-wrot";
+ reg = <0x14005000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
+ mediatek,gce-events = <CMDQ_EVENT_MDP_WROT0_SOF>,
+ <CMDQ_EVENT_MDP_WROT0_EOF>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ iommus = <&iommu>;
+ #dma-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt7622-cir.yaml b/Documentation/devicetree/bindings/media/mediatek,mt7622-cir.yaml
new file mode 100644
index 000000000000..c01210e053f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt7622-cir.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Consumer Infrared Receiver on-SoC Controller
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+allOf:
+ - $ref: rc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7622-cir
+ - mediatek,mt7623-cir
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: clk
+ - const: bus
+
+required:
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ir@10013000 {
+ compatible = "mediatek,mt7623-cir";
+ reg = <0x10013000 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_IRRX>, <&topckgen CLK_TOP_AXI_SEL>;
+ clock-names = "clk", "bus";
+ linux,rc-map-name = "rc-rc6-mce";
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
new file mode 100644
index 000000000000..8ca33a733c47
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mt8173-mdp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8173 Media Data Path
+
+maintainers:
+ - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
+
+description:
+ Media Data Path is used for scaling and color space conversion.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8173-mdp-rdma
+ - mediatek,mt8173-mdp-rsz
+ - mediatek,mt8173-mdp-wdma
+ - mediatek,mt8173-mdp-wrot
+ - items:
+ - const: mediatek,mt8173-mdp-rdma
+ - const: mediatek,mt8173-mdp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ mediatek,vpu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to Mediatek Video Processor Unit for HW Codec encode/decode and
+ image processing.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8173-mdp-rdma
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Main clock
+ - description: Mutex clock
+ else:
+ properties:
+ clocks:
+ items:
+ - description: Main clock
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8173-mdp-rdma
+ - mediatek,mt8173-mdp-wdma
+ - mediatek,mt8173-mdp-wrot
+ then:
+ required:
+ - iommus
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8173-mdp
+ then:
+ required:
+ - mediatek,vpu
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/memory/mt8173-larb-port.h>
+ #include <dt-bindings/power/mt8173-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mdp_rdma0: rdma@14001000 {
+ compatible = "mediatek,mt8173-mdp-rdma",
+ "mediatek,mt8173-mdp";
+ reg = <0 0x14001000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,vpu = <&vpu>;
+ };
+
+ mdp_rdma1: rdma@14002000 {
+ compatible = "mediatek,mt8173-mdp-rdma";
+ reg = <0 0x14002000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA1>,
+ <&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA1>;
+ };
+
+ mdp_rsz0: rsz@14003000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14003000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_rsz1: rsz@14004000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14004000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_rsz2: rsz@14005000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14005000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ2>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ };
+
+ mdp_wdma0: wdma@14006000 {
+ compatible = "mediatek,mt8173-mdp-wdma";
+ reg = <0 0x14006000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WDMA>;
+ };
+
+ mdp_wrot0: wrot@14007000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT0>;
+ };
+
+ mdp_wrot1: wrot@14008000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14008000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT1>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT1>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
new file mode 100644
index 000000000000..8a47761f1e6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mt8173-vpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8173 Video Processor Unit
+
+maintainers:
+ - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
+
+description:
+ Video Processor Unit is a HW video controller. It controls HW Codec including
+ H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color
+ convert).
+
+properties:
+ compatible:
+ const: mediatek,mt8173-vpu
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: tcm
+ - const: cfg_reg
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: main
+
+ memory-region:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ vpu: vpu@10020000 {
+ compatible = "mediatek,mt8173-vpu";
+ reg = <0 0x10020000 0 0x30000>,
+ <0 0x10050000 0 0x100>;
+ reg-names = "tcm", "cfg_reg";
+ interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&topckgen CLK_TOP_SCP_SEL>;
+ clock-names = "main";
+ memory-region = <&vpu_dma_reserved>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
new file mode 100644
index 000000000000..e5448c60e3eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mt8195-jpegdec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek JPEG Decoder
+
+maintainers:
+ - kyrie wu <kyrie.wu@mediatek.corp-partner.google.com>
+
+description:
+ MediaTek JPEG Decoder is the JPEG decode hardware present in MediaTek SoCs
+
+properties:
+ compatible:
+ const: mediatek,mt8195-jpgdec
+
+ power-domains:
+ maxItems: 1
+
+ iommus:
+ maxItems: 6
+ description:
+ Points to the respective IOMMU block with master port as argument, see
+ Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
+ Ports are according to the HW.
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges: true
+
+# Required child node:
+patternProperties:
+ "^jpgdec@[0-9a-f]+$":
+ type: object
+ description:
+ The jpeg decoder hardware device node which should be added as subnodes to
+ the main jpeg node.
+
+ properties:
+ compatible:
+ const: mediatek,mt8195-jpgdec-hw
+
+ reg:
+ maxItems: 1
+
+ iommus:
+ minItems: 1
+ maxItems: 32
+ description:
+ List of the hardware port in respective IOMMU block for current Socs.
+ Refer to bindings/iommu/mediatek,iommu.yaml.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: jpgdec
+
+ power-domains:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+ - iommus
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - power-domains
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/mt8195-memory-port.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/power/mt8195-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ jpgdec-master {
+ compatible = "mediatek,mt8195-jpgdec";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDEC1>;
+ iommus = <&iommu_vpp M4U_PORT_L19_JPGDEC_WDMA0>,
+ <&iommu_vpp M4U_PORT_L19_JPGDEC_BSDMA0>,
+ <&iommu_vpp M4U_PORT_L19_JPGDEC_WDMA1>,
+ <&iommu_vpp M4U_PORT_L19_JPGDEC_BSDMA1>,
+ <&iommu_vpp M4U_PORT_L19_JPGDEC_BUFF_OFFSET1>,
+ <&iommu_vpp M4U_PORT_L19_JPGDEC_BUFF_OFFSET0>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ jpgdec@1a040000 {
+ compatible = "mediatek,mt8195-jpgdec-hw";
+ reg = <0 0x1a040000 0 0x10000>;/* JPGDEC_C0 */
+ iommus = <&iommu_vdo M4U_PORT_L19_JPGDEC_WDMA0>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BSDMA0>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_WDMA1>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BSDMA1>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BUFF_OFFSET1>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BUFF_OFFSET0>;
+ interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&vencsys CLK_VENC_JPGDEC>;
+ clock-names = "jpgdec";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDEC0>;
+ };
+
+ jpgdec@1a050000 {
+ compatible = "mediatek,mt8195-jpgdec-hw";
+ reg = <0 0x1a050000 0 0x10000>;/* JPGDEC_C1 */
+ iommus = <&iommu_vdo M4U_PORT_L19_JPGDEC_WDMA0>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BSDMA0>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_WDMA1>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BSDMA1>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BUFF_OFFSET1>,
+ <&iommu_vdo M4U_PORT_L19_JPGDEC_BUFF_OFFSET0>;
+ interrupts = <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&vencsys CLK_VENC_JPGDEC_C1>;
+ clock-names = "jpgdec";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDEC1>;
+ };
+
+ jpgdec@1b040000 {
+ compatible = "mediatek,mt8195-jpgdec-hw";
+ reg = <0 0x1b040000 0 0x10000>;/* JPGDEC_C2 */
+ iommus = <&iommu_vpp M4U_PORT_L20_JPGDEC_WDMA0>,
+ <&iommu_vpp M4U_PORT_L20_JPGDEC_BSDMA0>,
+ <&iommu_vpp M4U_PORT_L20_JPGDEC_WDMA1>,
+ <&iommu_vpp M4U_PORT_L20_JPGDEC_BSDMA1>,
+ <&iommu_vpp M4U_PORT_L20_JPGDEC_BUFF_OFFSET1>,
+ <&iommu_vpp M4U_PORT_L20_JPGDEC_BUFF_OFFSET0>;
+ interrupts = <GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&vencsys_core1 CLK_VENC_CORE1_JPGDEC>;
+ clock-names = "jpgdec";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDEC2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
new file mode 100644
index 000000000000..596186497b68
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mt8195-jpegenc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek JPEG Encoder
+
+maintainers:
+ - kyrie wu <kyrie.wu@mediatek.corp-partner.google.com>
+
+description:
+ MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
+
+properties:
+ compatible:
+ const: mediatek,mt8195-jpgenc
+
+ power-domains:
+ maxItems: 1
+
+ iommus:
+ maxItems: 4
+ description:
+ Points to the respective IOMMU block with master port as argument, see
+ Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
+ Ports are according to the HW.
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges: true
+
+# Required child node:
+patternProperties:
+ "^jpgenc@[0-9a-f]+$":
+ type: object
+ description:
+ The jpeg encoder hardware device node which should be added as subnodes to
+ the main jpeg node.
+
+ properties:
+ compatible:
+ const: mediatek,mt8195-jpgenc-hw
+
+ reg:
+ maxItems: 1
+
+ iommus:
+ minItems: 1
+ maxItems: 32
+ description:
+ List of the hardware port in respective IOMMU block for current Socs.
+ Refer to bindings/iommu/mediatek,iommu.yaml.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: jpgenc
+
+ power-domains:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+ - iommus
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - power-domains
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/mt8195-memory-port.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/power/mt8195-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ jpgenc-master {
+ compatible = "mediatek,mt8195-jpgenc";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VENC_CORE1>;
+ iommus = <&iommu_vpp M4U_PORT_L20_JPGENC_Y_RDMA>,
+ <&iommu_vpp M4U_PORT_L20_JPGENC_C_RDMA>,
+ <&iommu_vpp M4U_PORT_L20_JPGENC_Q_TABLE>,
+ <&iommu_vpp M4U_PORT_L20_JPGENC_BSDMA>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ jpgenc@1a030000 {
+ compatible = "mediatek,mt8195-jpgenc-hw";
+ reg = <0 0x1a030000 0 0x10000>;
+ iommus = <&iommu_vdo M4U_PORT_L19_JPGENC_Y_RDMA>,
+ <&iommu_vdo M4U_PORT_L19_JPGENC_C_RDMA>,
+ <&iommu_vdo M4U_PORT_L19_JPGENC_Q_TABLE>,
+ <&iommu_vdo M4U_PORT_L19_JPGENC_BSDMA>;
+ interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&vencsys CLK_VENC_JPGENC>;
+ clock-names = "jpgenc";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VENC>;
+ };
+
+ jpgenc@1b030000 {
+ compatible = "mediatek,mt8195-jpgenc-hw";
+ reg = <0 0x1b030000 0 0x10000>;
+ iommus = <&iommu_vpp M4U_PORT_L20_JPGENC_Y_RDMA>,
+ <&iommu_vpp M4U_PORT_L20_JPGENC_C_RDMA>,
+ <&iommu_vpp M4U_PORT_L20_JPGENC_Q_TABLE>,
+ <&iommu_vpp M4U_PORT_L20_JPGENC_BSDMA>;
+ interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&vencsys_core1 CLK_VENC_CORE1_JPGENC>;
+ clock-names = "jpgenc";
+ power-domains = <&spm MT8195_POWER_DOMAIN_VENC_CORE1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
index aa55ca65d6ed..d726d141a434 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/mediatek,vcodec-decoder.yaml#
@@ -21,24 +20,33 @@ properties:
- mediatek,mt8183-vcodec-dec
reg:
- maxItems: 12
+ minItems: 11
+ maxItems: 11
+
+ reg-names:
+ items:
+ - const: misc
+ - const: ld
+ - const: top
+ - const: cm
+ - const: ad
+ - const: av
+ - const: pp
+ - const: hwd
+ - const: hwq
+ - const: hwb
+ - const: hwg
interrupts:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 8
clock-names:
- items:
- - const: vcodecpll
- - const: univpll_d2
- - const: clk_cci400_sel
- - const: vdec_sel
- - const: vdecpll
- - const: vencpll
- - const: venc_lt_sel
- - const: vdec_bus_clk_src
+ minItems: 1
+ maxItems: 8
assigned-clocks: true
@@ -56,11 +64,6 @@ properties:
List of the hardware port in respective IOMMU block for current Socs.
Refer to bindings/iommu/mediatek,iommu.yaml.
- dma-ranges:
- maxItems: 1
- description: |
- Describes the physical address space of IOMMU maps to memory.
-
mediatek,vpu:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -71,6 +74,10 @@ properties:
description:
Describes point to scp.
+ mediatek,vdecsys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the vdecsys syscon node.
+
required:
- compatible
- reg
@@ -78,8 +85,7 @@ required:
- clocks
- clock-names
- iommus
- - assigned-clocks
- - assigned-clock-parents
+ - mediatek,vdecsys
allOf:
- if:
@@ -93,6 +99,15 @@ allOf:
required:
- mediatek,scp
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: vdec
+
- if:
properties:
compatible:
@@ -104,6 +119,22 @@ allOf:
required:
- mediatek,vpu
+ properties:
+ clocks:
+ minItems: 8
+ maxItems: 8
+
+ clock-names:
+ items:
+ - const: vcodecpll
+ - const: univpll_d2
+ - const: clk_cci400_sel
+ - const: vdec_sel
+ - const: vdecpll
+ - const: vencpll
+ - const: venc_lt_sel
+ - const: vdec_bus_clk_src
+
additionalProperties: false
examples:
@@ -114,10 +145,9 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/mt8173-power.h>
- vcodec_dec: vcodec@16000000 {
+ vcodec_dec: vcodec@16020000 {
compatible = "mediatek,mt8173-vcodec-dec";
- reg = <0x16000000 0x100>, /*VDEC_SYS*/
- <0x16020000 0x1000>, /*VDEC_MISC*/
+ reg = <0x16020000 0x1000>, /*VDEC_MISC*/
<0x16021000 0x800>, /*VDEC_LD*/
<0x16021800 0x800>, /*VDEC_TOP*/
<0x16022000 0x1000>, /*VDEC_CM*/
@@ -138,6 +168,7 @@ examples:
<&iommu M4U_PORT_HW_VDEC_VLD_EXT>,
<&iommu M4U_PORT_HW_VDEC_VLD2_EXT>;
mediatek,vpu = <&vpu>;
+ mediatek,vdecsys = <&vdecsys>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>,
<&topckgen CLK_TOP_UNIVPLL_D2>,
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
index 32aee09aea33..ebc615584f92 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml#
@@ -16,14 +15,18 @@ description: |+
properties:
compatible:
- enum:
- - mediatek,mt8173-vcodec-enc-vp8
- - mediatek,mt8173-vcodec-enc
- - mediatek,mt8183-vcodec-enc
- - mediatek,mt8188-vcodec-enc
- - mediatek,mt8192-vcodec-enc
- - mediatek,mt8195-vcodec-enc
-
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt8173-vcodec-enc-vp8
+ - mediatek,mt8173-vcodec-enc
+ - mediatek,mt8183-vcodec-enc
+ - mediatek,mt8188-vcodec-enc
+ - mediatek,mt8192-vcodec-enc
+ - mediatek,mt8195-vcodec-enc
+ - items:
+ - const: mediatek,mt8186-vcodec-enc
+ - const: mediatek,mt8183-vcodec-enc
reg:
maxItems: 1
@@ -38,10 +41,6 @@ properties:
minItems: 1
maxItems: 5
- assigned-clocks: true
-
- assigned-clock-parents: true
-
iommus:
minItems: 1
maxItems: 32
@@ -49,11 +48,6 @@ properties:
List of the hardware port in respective IOMMU block for current Socs.
Refer to bindings/iommu/mediatek,iommu.yaml.
- dma-ranges:
- maxItems: 1
- description: |
- Describes the physical address space of IOMMU maps to memory.
-
mediatek,vpu:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -67,6 +61,12 @@ properties:
power-domains:
maxItems: 1
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
required:
- compatible
- reg
@@ -74,8 +74,6 @@ required:
- clocks
- clock-names
- iommus
- - assigned-clocks
- - assigned-clock-parents
allOf:
- if:
@@ -84,7 +82,9 @@ allOf:
contains:
enum:
- mediatek,mt8183-vcodec-enc
+ - mediatek,mt8188-vcodec-enc
- mediatek,mt8192-vcodec-enc
+ - mediatek,mt8195-vcodec-enc
then:
required:
@@ -106,8 +106,7 @@ allOf:
properties:
compatible:
enum:
- - mediatek,mt8173-vcodec-enc
- - mediatek,mt8192-vcodec-enc
+ - mediatek,mt8173-vcodec-enc-vp8
then:
properties:
@@ -117,8 +116,8 @@ allOf:
maxItems: 1
clock-names:
items:
- - const: venc_sel
- else: # for vp8 hw decoder
+ - const: venc_lt_sel
+ else:
properties:
clock:
items:
@@ -126,7 +125,7 @@ allOf:
maxItems: 1
clock-names:
items:
- - const: venc_lt_sel
+ - const: venc_sel
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
index c4f20acdc1f8..bf8082d87ac0 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
@@ -1,56 +1,73 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek Video Decode Accelerator With Multi Hardware
+title: MediaTek Video Decode Accelerator With Multi Hardware
maintainers:
- Yunfei Dong <yunfei.dong@mediatek.com>
description: |
- Mediatek Video Decode is the video decode hardware present in Mediatek
- SoCs which supports high resolution decoding functionalities. Required
- parent and child device node.
-
- About the Decoder Hardware Block Diagram, please check below:
-
- +------------------------------------------------+-------------------------------------+
- | | |
- | input -> lat soc HW -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output |
- | || || | || |
- +------------||-------------||-------------------+---------------------||--------------+
- || lat || | core workqueue <parent>
- -------------||-------------||-------------------|---------------------||---------------
- ||<------------||----------------HW index---------------->|| <child>
- \/ \/ \/
- +-------------------------------------------------------------+
- | enable/disable |
- | clk power irq iommu |
- | (lat/lat soc/core0/core1) |
- +-------------------------------------------------------------+
-
- As above, there are parent and child devices, child mean each hardware. The child device
- controls the information of each hardware independent which include clk/power/irq.
-
- There are two workqueues in parent device: lat workqueue and core workqueue. They are used
- to lat and core hardware deocder. Lat workqueue need to get input bitstream and lat buffer,
- then enable lat to decode, writing the result to lat buffer, dislabe hardware when lat decode
- done. Core workqueue need to get lat buffer and output buffer, then enable core to decode,
- writing the result to output buffer, disable hardware when core decode done. These two
- hardwares will decode each frame cyclically.
-
- For the smi common may not the same for each hardware, can't combine all hardware in one node,
- or leading to iommu fault when access dram data.
-
- Lat soc is a hardware which is related with some larb(local arbiter) ports. For mt8195
- platform, there are some ports like RDMA, UFO in lat soc larb, need to enable its power and
- clock when lat start to work, don't have interrupt.
-
- mt8195: lat soc HW + lat HW + core HW
- mt8192: lat HW + core HW
+ MediaTek Video Decode Accelerator is the video decoding hardware present in
+ MediaTek SoCs that supports high-resolution decoding functionalities.
+ It consists of parent and child nodes.
+
+ The decoder hardware block diagram is shown below:
+
+ +------------------------------------------------+------------------------------+
+ | | |
+ | input -> LAT-SoC HW -> LAT HW -> LAT buffer --|--> Core HW -> output buffer |
+ | || || | || |
+ +--------------||-----------||-------------------+-------||---------------------+
+ LAT Workqueue | Core Workqueue <parent>
+ ---------------||-----------||-------------------|-------||----------------------
+ ||<----------||---------HW index--------->|| <child>
+ \/ \/ \/
+ +-------------------------------------------------------------+
+ | enable/disable |
+ | clk power irq iommu |
+ | (lat/lat-soc/core0/core1) |
+ +-------------------------------------------------------------+
+
+ The child nodes represent the individual hardware blocks within the decoding
+ pipeline, such as LAT-SoC, LAT and Core.
+ Each child node is responsible for managing the dedicated resources of the
+ hardware, such as clocks, power domains, interrupts and IOMMUs.
+
+ The parent node is a central point of control for the child nodes.
+ It identifies the specific video decoding pipeline architecture used by the
+ SoC, manages the shared resources like workqueues and platform data, and
+ handles V4L2 API calls on behalf of the underlying hardware.
+
+ The parent utilizes two workqueues to manage the decoding process.
+ 1. LAT Workqueue, for LAT-SoC and LAT decoder:
+ Its workers take input bitstream and LAT buffer, enable the hardware for
+ decoding tasks, write the result to LAT buffer, and disable the hardware
+ after the LAT decoding is done.
+ 2. Core Workqueue, for Core decoder:
+ Its workers take LAT buffer and output buffer, enable the hardware for
+ decoding tasks, write the result to output buffer, and disable the hardware
+ after the Core decoding is done.
+
+ These hardware decode each frame cyclically.
+
+ The hardware might be associated with different SMI-common devices.
+ To prevent IOMMU faults during DRAM access in such cases, each hardware with
+ the unique SMI-common device must be placed under a separate parent node in
+ the device tree.
+
+ LAT-SoC refers to another hardware block that connected to additional LARB
+ (local arbiter) ports, such as RDMA and UFO.
+ It requires independent power and clock control to work with LAT decoder, and
+ it doesn't have a dedicated interrupt.
+
+ The used video decoding pipeline architecture across various Mediatek SoC:
+ MT8195: LAT-SoC + LAT + Core
+ MT8192: LAT + Core
+ MT8188: LAT + Core
+ MT8186: Core
properties:
compatible:
@@ -61,7 +78,10 @@ properties:
- mediatek,mt8195-vcodec-dec
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: VDEC_SYS register space
+ - description: VDEC_RACING_CTRL register space
iommus:
minItems: 1
@@ -76,11 +96,6 @@ properties:
The node of system control processor (SCP), using
the remoteproc & rpmsg framework.
- dma-ranges:
- maxItems: 1
- description: |
- Describes the physical address space of IOMMU maps to memory.
-
"#address-cells":
const: 2
@@ -91,17 +106,19 @@ properties:
# Required child node:
patternProperties:
- '^vcodec-lat@[0-9a-f]+$':
+ '^video-codec@[0-9a-f]+$':
type: object
properties:
compatible:
enum:
+ - mediatek,mtk-vcodec-core
- mediatek,mtk-vcodec-lat
- mediatek,mtk-vcodec-lat-soc
reg:
maxItems: 1
+ description: VDEC_MISC register space
interrupts:
maxItems: 1
@@ -114,68 +131,13 @@ patternProperties:
Refer to bindings/iommu/mediatek,iommu.yaml.
clocks:
+ minItems: 4
maxItems: 5
clock-names:
- items:
- - const: sel
- - const: soc-vdec
- - const: soc-lat
- - const: vdec
- - const: top
-
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-parents:
- maxItems: 1
-
- power-domains:
- maxItems: 1
-
- required:
- - compatible
- - reg
- - iommus
- - clocks
- - clock-names
- - assigned-clocks
- - assigned-clock-parents
- - power-domains
-
- additionalProperties: false
-
- '^vcodec-core@[0-9a-f]+$':
- type: object
-
- properties:
- compatible:
- const: mediatek,mtk-vcodec-core
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- iommus:
- minItems: 1
- maxItems: 32
- description: |
- List of the hardware port in respective IOMMU block for current Socs.
- Refer to bindings/iommu/mediatek,iommu.yaml.
-
- clocks:
+ minItems: 4
maxItems: 5
- clock-names:
- items:
- - const: sel
- - const: soc-vdec
- - const: soc-lat
- - const: vdec
- - const: top
-
assigned-clocks:
maxItems: 1
@@ -188,7 +150,6 @@ patternProperties:
required:
- compatible
- reg
- - interrupts
- iommus
- clocks
- clock-names
@@ -203,7 +164,6 @@ required:
- reg
- iommus
- mediatek,scp
- - dma-ranges
- ranges
if:
@@ -211,12 +171,45 @@ if:
compatible:
contains:
enum:
+ - mediatek,mtk-vcodec-core
- mediatek,mtk-vcodec-lat
then:
required:
- interrupts
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8192-vcodec-dec
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: sel
+ - const: soc-vdec
+ - const: soc-lat
+ - const: vdec
+ - const: top
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8195-vcodec-dec
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: sel
+ - const: vdec
+ - const: lat
+ - const: top
+
additionalProperties: false
examples:
@@ -236,12 +229,11 @@ examples:
compatible = "mediatek,mt8192-vcodec-dec";
mediatek,scp = <&scp>;
iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
- dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0 0 0 0x16000000 0 0x40000>;
reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS */
- vcodec-lat@10000 {
+ video-codec@10000 {
compatible = "mediatek,mtk-vcodec-lat";
reg = <0 0x10000 0 0x800>;
interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>;
@@ -264,7 +256,7 @@ examples:
power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>;
};
- vcodec-core@25000 {
+ video-codec@25000 {
compatible = "mediatek,mtk-vcodec-core";
reg = <0 0x25000 0 0x1000>;
interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>;
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index 052e752157b4..a4aacd3eb189 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/mediatek-jpeg-decoder.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek JPEG Decoder Device Tree Bindings
+title: MediaTek JPEG Decoder
maintainers:
- Xia Jiang <xia.jiang@mediatek.com>
@@ -22,6 +22,7 @@ properties:
- items:
- enum:
- mediatek,mt7623-jpgdec
+ - mediatek,mt8188-jpgdec
- const: mediatek,mt2701-jpgdec
reg:
@@ -43,7 +44,8 @@ properties:
maxItems: 1
iommus:
- maxItems: 2
+ minItems: 2
+ maxItems: 32
description: |
Points to the respective IOMMU block with master port as argument, see
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 4fd390c042a9..5b15f8977f67 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/mediatek-jpeg-encoder.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek JPEG Encoder Device Tree Bindings
+title: MediaTek JPEG Encoder
maintainers:
- Xia Jiang <xia.jiang@mediatek.com>
@@ -19,6 +19,7 @@ properties:
- mediatek,mt2701-jpgenc
- mediatek,mt8183-jpgenc
- mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
- const: mediatek,mtk-jpgenc
reg:
maxItems: 1
@@ -37,17 +38,13 @@ properties:
maxItems: 1
iommus:
- maxItems: 2
+ minItems: 2
+ maxItems: 32
description: |
Points to the respective IOMMU block with master port as argument, see
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
- dma-ranges:
- maxItems: 1
- description: |
- Describes the physical address space of IOMMU maps to memory.
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
deleted file mode 100644
index 53ef26e2c857..000000000000
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-* Mediatek Media Data Path
-
-Media Data Path is used for scaling and color space conversion.
-
-Required properties (controller node):
-- compatible: "mediatek,mt8173-mdp"
-- mediatek,vpu: the node of video processor unit, see
- Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
-
-Required properties (all function blocks, child node):
-- compatible: Should be one of
- "mediatek,mt8173-mdp-rdma" - read DMA
- "mediatek,mt8173-mdp-rsz" - resizer
- "mediatek,mt8173-mdp-wdma" - write DMA
- "mediatek,mt8173-mdp-wrot" - write DMA with rotation
-- reg: Physical base address and length of the function block register space
-- clocks: device clocks, see
- Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- power-domains: a phandle to the power domain, see
- Documentation/devicetree/bindings/power/power_domain.txt for details.
-
-Required properties (DMA function blocks, child node):
-- compatible: Should be one of
- "mediatek,mt8173-mdp-rdma"
- "mediatek,mt8173-mdp-wdma"
- "mediatek,mt8173-mdp-wrot"
-- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
- for details.
-
-Example:
- mdp_rdma0: rdma@14001000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- "mediatek,mt8173-mdp";
- reg = <0 0x14001000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
- <&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA0>;
- mediatek,vpu = <&vpu>;
- };
-
- mdp_rdma1: rdma@14002000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14002000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA1>,
- <&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA1>;
- };
-
- mdp_rsz0: rsz@14003000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14003000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ0>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
-
- mdp_rsz1: rsz@14004000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14004000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ1>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
-
- mdp_rsz2: rsz@14005000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14005000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ2>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
-
- mdp_wdma0: wdma@14006000 {
- compatible = "mediatek,mt8173-mdp-wdma";
- reg = <0 0x14006000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WDMA>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WDMA>;
- };
-
- mdp_wrot0: wrot@14007000 {
- compatible = "mediatek,mt8173-mdp-wrot";
- reg = <0 0x14007000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WROT0>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WROT0>;
- };
-
- mdp_wrot1: wrot@14008000 {
- compatible = "mediatek,mt8173-mdp-wrot";
- reg = <0 0x14008000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WROT1>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WROT1>;
- };
diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
deleted file mode 100644
index 2a5bac37f9a2..000000000000
--- a/Documentation/devicetree/bindings/media/mediatek-vpu.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* Mediatek Video Processor Unit
-
-Video Processor Unit is a HW video controller. It controls HW Codec including
-H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color convert).
-
-Required properties:
- - compatible: "mediatek,mt8173-vpu"
- - reg: Must contain an entry for each entry in reg-names.
- - reg-names: Must include the following entries:
- "tcm": tcm base
- "cfg_reg": Main configuration registers base
- - interrupts: interrupt number to the cpu.
- - clocks : clock name from clock manager
- - clock-names: must be main. It is the main clock of VPU
-
-Optional properties:
- - memory-region: phandle to a node describing memory (see
- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
- to be used for VPU extended memory; if not present, VPU may be located
- anywhere in the memory
-
-Example:
- vpu: vpu@10020000 {
- compatible = "mediatek,mt8173-vpu";
- reg = <0 0x10020000 0 0x30000>,
- <0 0x10050000 0 0x100>;
- reg-names = "tcm", "cfg_reg";
- interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&topckgen TOP_SCP_SEL>;
- clock-names = "main";
- };
diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/media/meson-ir.txt
deleted file mode 100644
index efd9d29a8f10..000000000000
--- a/Documentation/devicetree/bindings/media/meson-ir.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Amlogic Meson IR remote control receiver
-
-Required properties:
- - compatible : depending on the platform this should be one of:
- - "amlogic,meson6-ir"
- - "amlogic,meson8b-ir"
- - "amlogic,meson-gxbb-ir"
- - reg : physical base address and length of the device registers
- - interrupts : a single specifier for the interrupt from the device
-
-Optional properties:
- - linux,rc-map-name: see rc.txt file in the same directory.
-
-Example:
-
- ir-receiver@c8100480 {
- compatible= "amlogic,meson6-ir";
- reg = <0xc8100480 0x20>;
- interrupts = <0 15 1>;
- };
diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
index e8544fb2d034..b3a345fc6464 100644
--- a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
+++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
@@ -75,6 +75,7 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the input port.
@@ -103,6 +104,7 @@ properties:
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Output port node, single endpoint describing the output port.
diff --git a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml
index 4b77103ca913..ede086d55add 100644
--- a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml
+++ b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hantro G1 VPU codec implemented on Microchip SAMA5D4 SoCs
@@ -36,12 +35,12 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/interrupt-controller/irq.h>
-
- vdec0: vdec@300000 {
- compatible = "microchip,sama5d4-vdec";
- reg = <0x00300000 0x100000>;
- interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>;
- clocks = <&pmc PMC_TYPE_PERIPHERAL 19>;
- };
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ vdec@300000 {
+ compatible = "microchip,sama5d4-vdec";
+ reg = <0x00300000 0x100000>;
+ interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 19>;
+ };
diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
index 8b37fccab5e2..25f5f79d40ce 100644
--- a/Documentation/devicetree/bindings/media/microchip,xisc.yaml
+++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
@@ -106,6 +106,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/at91.h>
#include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/media/video-interfaces.h>
xisc: xisc@e1408000 {
compatible = "microchip,sama7g5-isc";
@@ -118,7 +119,7 @@ examples:
port {
xisc_in: endpoint {
- bus-type = <5>; /* Parallel */
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
remote-endpoint = <&csi2dc_out>;
hsync-active = <1>;
vsync-active = <1>;
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
deleted file mode 100644
index 5e18087ce11f..000000000000
--- a/Documentation/devicetree/bindings/media/mtk-cir.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Device-Tree bindings for Mediatek consumer IR controller
-found in Mediatek SoC family
-
-Required properties:
-- compatible : Should be
- "mediatek,mt7623-cir": for MT7623 SoC
- "mediatek,mt7622-cir": for MT7622 SoC
-- clocks : list of clock specifiers, corresponding to
- entries in clock-names property;
-- clock-names : should contain
- - "clk" entries: for MT7623 SoC
- - "clk", "bus" entries: for MT7622 SoC
-- interrupts : should contain IR IRQ number;
-- reg : should contain IO map address for IR.
-
-Optional properties:
-- linux,rc-map-name : see rc.txt file in the same directory.
-
-Example:
-
-cir: cir@10013000 {
- compatible = "mediatek,mt7623-cir";
- reg = <0 0x10013000 0 0x1000>;
- interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&infracfg CLK_INFRA_IRRX>;
- clock-names = "clk";
- linux,rc-map-name = "rc-rc6-mce";
-};
diff --git a/Documentation/devicetree/bindings/media/nokia,n900-ir b/Documentation/devicetree/bindings/media/nokia,n900-ir
deleted file mode 100644
index 13a18ce37dd1..000000000000
--- a/Documentation/devicetree/bindings/media/nokia,n900-ir
+++ /dev/null
@@ -1,20 +0,0 @@
-Device-Tree bindings for LIRC TX driver for Nokia N900(RX51)
-
-Required properties:
- - compatible: should be "nokia,n900-ir".
- - pwms: specifies PWM used for IR signal transmission.
-
-Example node:
-
- pwm9: dmtimer-pwm@9 {
- compatible = "ti,omap-dmtimer-pwm";
- ti,timers = <&timer9>;
- ti,clock-source = <0x00>; /* timer_sys_ck */
- #pwm-cells = <3>;
- };
-
- ir: n900-ir {
- compatible = "nokia,n900-ir";
-
- pwms = <&pwm9 0 26316 0>; /* 38000 Hz */
- };
diff --git a/Documentation/devicetree/bindings/media/nuvoton,npcm-ece.yaml b/Documentation/devicetree/bindings/media/nuvoton,npcm-ece.yaml
new file mode 100644
index 000000000000..b47468e54504
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nuvoton,npcm-ece.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/nuvoton,npcm-ece.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Encoding Compression Engine
+
+maintainers:
+ - Joseph Liu <kwliu@nuvoton.com>
+ - Marvin Lin <kflin@nuvoton.com>
+
+description: |
+ Video Encoding Compression Engine (ECE) present on Nuvoton NPCM SoCs.
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-ece
+ - nuvoton,npcm845-ece
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/nuvoton,npcm7xx-reset.h>
+
+ ece: video-codec@f0820000 {
+ compatible = "nuvoton,npcm750-ece";
+ reg = <0xf0820000 0x2000>;
+ resets = <&rstc NPCM7XX_RESET_IPSRST2 NPCM7XX_RESET_ECE>;
+ };
diff --git a/Documentation/devicetree/bindings/media/nuvoton,npcm-vcd.yaml b/Documentation/devicetree/bindings/media/nuvoton,npcm-vcd.yaml
new file mode 100644
index 000000000000..c885f559d2e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nuvoton,npcm-vcd.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/nuvoton,npcm-vcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Video Capture/Differentiation Engine
+
+maintainers:
+ - Joseph Liu <kwliu@nuvoton.com>
+ - Marvin Lin <kflin@nuvoton.com>
+
+description: |
+ Video Capture/Differentiation Engine (VCD) present on Nuvoton NPCM SoCs.
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-vcd
+ - nuvoton,npcm845-vcd
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ nuvoton,sysgcr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to access GCR (Global Control Register) registers.
+
+ nuvoton,sysgfxi:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to access GFXI (Graphics Core Information) registers.
+
+ nuvoton,ece:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to access ECE (Encoding Compression Engine) registers.
+
+ memory-region:
+ maxItems: 1
+ description:
+ CMA pool to use for buffers allocation instead of the default CMA pool.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+ - nuvoton,sysgcr
+ - nuvoton,sysgfxi
+ - nuvoton,ece
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/nuvoton,npcm7xx-reset.h>
+
+ vcd: vcd@f0810000 {
+ compatible = "nuvoton,npcm750-vcd";
+ reg = <0xf0810000 0x10000>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&rstc NPCM7XX_RESET_IPSRST2 NPCM7XX_RESET_VCD>;
+ nuvoton,sysgcr = <&gcr>;
+ nuvoton,sysgfxi = <&gfxi>;
+ nuvoton,ece = <&ece>;
+ };
diff --git a/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml
index 03a23a26c4f3..41ad5b84eaeb 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml
@@ -66,6 +66,14 @@ properties:
clock-frequency:
description: The desired external clock ("wrap") frequency, in Hz
default: 166000000
+ deprecated: true
+
+ fsl,num-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of output channels
+ minimum: 1
+ maximum: 4
+ default: 1
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -147,7 +155,9 @@ examples:
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
clock-names = "pclk", "wrap", "phy";
- clock-frequency = <166000000>;
+
+ assigned-clocks = <&clks IMX7D_MIPI_CSI_ROOT_CLK>;
+ assigned-clock-rates = <166000000>;
power-domains = <&pgc_mipi_phy>;
phy-supply = <&reg_1p0d>;
@@ -185,12 +195,16 @@ examples:
compatible = "fsl,imx8mm-mipi-csi2";
reg = <0x32e30000 0x1000>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
- clock-frequency = <333000000>;
+
clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>,
<&clk IMX8MM_CLK_CSI1_ROOT>,
<&clk IMX8MM_CLK_CSI1_PHY_REF>,
<&clk IMX8MM_CLK_DISP_AXI_ROOT>;
clock-names = "pclk", "wrap", "phy", "axi";
+
+ assigned-clocks = <&clk IMX8MM_CLK_CSI1_ROOT>;
+ assigned-clock-rates = <250000000>;
+
power-domains = <&mipi_pd>;
ports {
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
index 4f7b78265336..326284e151f6 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
@@ -37,6 +37,9 @@ properties:
items:
- const: mclk
+ power-domains:
+ maxItems: 1
+
port:
$ref: /schemas/graph.yaml#/properties/port
@@ -50,6 +53,17 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mm-csi
+ then:
+ required:
+ - power-domains
+
examples:
- |
#include <dt-bindings/clock/imx7d-clock.h>
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
new file mode 100644
index 000000000000..001a0d9b71e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/nxp,imx8-isi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX8 Image Sensing Interface
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ The Image Sensing Interface (ISI) combines image processing pipelines with
+ DMA engines to process and capture frames originating from a variety of
+ sources. The inputs to the ISI go through Pixel Link interfaces, and their
+ number and nature is SoC-dependent. They cover both capture interfaces (MIPI
+ CSI-2 RX, HDMI RX, ...) and display engine outputs for writeback support.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8mn-isi
+ - fsl,imx8mp-isi
+ - fsl,imx8ulp-isi
+ - fsl,imx91-isi
+ - fsl,imx93-isi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The AXI clock
+ - description: The APB clock
+ # TODO: Check if the per-channel ipg_proc_clk clocks need to be specified
+ # as well, in case some SoCs have the ability to control them separately.
+ # This may be the case of the i.MX8[DQ]X(P)
+
+ clock-names:
+ items:
+ - const: axi
+ - const: apb
+
+ fsl,blk-ctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle referencing the block control that contains the CSIS to ISI
+ gasket.
+
+ interrupts:
+ description: Processing pipeline interrupts, one per pipeline
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: |
+ Ports represent the Pixel Link inputs to the ISI. Their number and
+ assignment are model-dependent. Each port shall have a single endpoint.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mn-isi
+ - fsl,imx8ulp-isi
+ - fsl,imx91-isi
+ - fsl,imx93-isi
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ ports:
+ properties:
+ port@0:
+ description: MIPI CSI-2 RX
+ port@1: false
+ required:
+ - port@0
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8mp-isi
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+ ports:
+ properties:
+ port@0:
+ description: MIPI CSI-2 RX 0
+ port@1:
+ description: MIPI CSI-2 RX 1
+ required:
+ - port@0
+ - port@1
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: fsl,imx91-isi
+ then:
+ required:
+ - fsl,blk-ctrl
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mn-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/imx8mn-power.h>
+
+ isi@32e20000 {
+ compatible = "fsl,imx8mn-isi";
+ reg = <0x32e20000 0x100>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_DISP_AXI_ROOT>,
+ <&clk IMX8MN_CLK_DISP_APB_ROOT>;
+ clock-names = "axi", "apb";
+ fsl,blk-ctrl = <&disp_blk_ctrl>;
+ power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_ISI>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ isi_in: endpoint {
+ remote-endpoint = <&mipi_csi_out>;
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ isi@32e00000 {
+ compatible = "fsl,imx8mp-isi";
+ reg = <0x32e00000 0x4000>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
+ <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
+ clock-names = "axi", "apb";
+ fsl,blk-ctrl = <&media_blk_ctrl>;
+ power-domains = <&mediamix_pd>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ isi_in_0: endpoint {
+ remote-endpoint = <&mipi_csi_0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ isi_in_1: endpoint {
+ remote-endpoint = <&mipi_csi_1_out>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
index 3cc6f42aeb76..b5aca3d2cc5c 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX8QXP/QM JPEG decoder/encoder Device Tree Bindings
+title: i.MX8QXP/QM JPEG decoder/encoder
maintainers:
- Mirela Rabulea <mirela.rabulea@nxp.com>
@@ -22,15 +22,24 @@ properties:
- nxp,imx8qxp-jpgdec
- nxp,imx8qxp-jpgenc
- items:
- - const: nxp,imx8qm-jpgdec
+ - enum:
+ - nxp,imx8qm-jpgdec
+ - nxp,imx95-jpgdec
- const: nxp,imx8qxp-jpgdec
- items:
- - const: nxp,imx8qm-jpgenc
+ - enum:
+ - nxp,imx8qm-jpgenc
+ - nxp,imx95-jpgenc
- const: nxp,imx8qxp-jpgenc
reg:
maxItems: 1
+ clocks:
+ items:
+ - description: AXI DMA engine clock for fetching JPEG bitstream from memory (per)
+ - description: IP bus clock for register access (ipg)
+
interrupts:
description: |
There are 4 slots available in the IP, which the driver may use
@@ -43,25 +52,46 @@ properties:
description:
List of phandle and PM domain specifier as documented in
Documentation/devicetree/bindings/power/power_domain.txt
- minItems: 2 # Wrapper and 1 slot
+ minItems: 1 # Wrapper and all slots
maxItems: 5 # Wrapper and 4 slots
required:
- compatible
- reg
+ - clocks
- interrupts
- power-domains
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,imx95-jpgenc
+ - nxp,imx95-jpgdec
+ then:
+ properties:
+ power-domains:
+ maxItems: 1
+ else:
+ properties:
+ power-domains:
+ minItems: 2 # Wrapper and 1 slot
+
additionalProperties: false
examples:
- |
+ #include <dt-bindings/clock/imx8-lpcg.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/firmware/imx/rsrc.h>
jpegdec: jpegdec@58400000 {
compatible = "nxp,imx8qxp-jpgdec";
reg = <0x58400000 0x00050000 >;
+ clocks = <&img_jpeg_dec_lpcg IMX_LPCG_CLK_0>,
+ <&img_jpeg_dec_lpcg IMX_LPCG_CLK_4>;
interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
@@ -76,6 +106,8 @@ examples:
jpegenc: jpegenc@58450000 {
compatible = "nxp,imx8qm-jpgenc", "nxp,imx8qxp-jpgenc";
reg = <0x58450000 0x00050000 >;
+ clocks = <&img_jpeg_enc_lpcg IMX_LPCG_CLK_0>,
+ <&img_jpeg__lpcg IMX_LPCG_CLK_4>;
interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
index 2a14e3b0e004..3389bab266a9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml
@@ -16,11 +16,19 @@ description: |-
properties:
compatible:
- enum:
- - fsl,imx8mq-mipi-csi2
+ oneOf:
+ - enum:
+ - fsl,imx8mq-mipi-csi2
+ - fsl,imx8qxp-mipi-csi2
+ - items:
+ - const: fsl,imx8qm-mipi-csi2
+ - const: fsl,imx8qxp-mipi-csi2
reg:
- maxItems: 1
+ items:
+ - description: MIPI CSI-2 RX host controller register.
+ - description: MIPI CSI-2 control and status register (csr).
+ minItems: 1
clocks:
items:
@@ -46,6 +54,7 @@ properties:
- description: CORE_RESET reset register bit definition
- description: PHY_REF_RESET reset register bit definition
- description: ESC_RESET reset register bit definition
+ minItems: 1
fsl,mipi-phy-gpr:
description: |
@@ -113,9 +122,30 @@ required:
- clock-names
- power-domains
- resets
- - fsl,mipi-phy-gpr
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-mipi-csi2
+ then:
+ properties:
+ reg:
+ minItems: 2
+ resets:
+ maxItems: 1
+ else:
+ properties:
+ reg:
+ maxItems: 1
+ resets:
+ minItems: 3
+ required:
+ - fsl,mipi-phy-gpr
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
index 7dc13a4b1805..19528262810a 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hantro G1/G2 VPU codecs implemented on i.MX8M SoCs
@@ -44,26 +43,26 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/imx8mq-clock.h>
- #include <dt-bindings/power/imx8mq-power.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx8mq-clock.h>
+ #include <dt-bindings/power/imx8mq-power.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
- vpu_g1: video-codec@38300000 {
- compatible = "nxp,imx8mq-vpu-g1";
- reg = <0x38300000 0x10000>;
- interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>;
- power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G1>;
- };
+ video-codec@38300000 {
+ compatible = "nxp,imx8mq-vpu-g1";
+ reg = <0x38300000 0x10000>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>;
+ power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G1>;
+ };
- |
- #include <dt-bindings/clock/imx8mq-clock.h>
- #include <dt-bindings/power/imx8mq-power.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx8mq-clock.h>
+ #include <dt-bindings/power/imx8mq-power.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
- vpu_g2: video-codec@38300000 {
- compatible = "nxp,imx8mq-vpu-g2";
- reg = <0x38310000 0x10000>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MQ_CLK_VPU_G2_ROOT>;
- power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G2>;
- };
+ video-codec@38300000 {
+ compatible = "nxp,imx8mq-vpu-g2";
+ reg = <0x38310000 0x10000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MQ_CLK_VPU_G2_ROOT>;
+ power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G2>;
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
index 12ec3e1ea869..7c8e0a905d89 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm CAMSS ISP
@@ -94,6 +93,10 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -113,6 +116,10 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -155,7 +162,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
- camss: camss@1b00000 {
+ camss: camss@1b0ac00 {
compatible = "qcom,msm8916-camss";
clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
index 59ab16ad12f1..da140c2e3d3f 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm MSM8916 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,16 +13,13 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
const: qcom,msm8916-venus
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
power-domains:
maxItems: 1
@@ -39,19 +35,17 @@ properties:
iommus:
maxItems: 1
- memory-region:
- maxItems: 1
-
video-decoder:
type: object
properties:
compatible:
- const: "venus-decoder"
+ const: venus-decoder
required:
- compatible
+ deprecated: true
additionalProperties: false
video-encoder:
@@ -59,63 +53,34 @@ properties:
properties:
compatible:
- const: "venus-encoder"
+ const: venus-encoder
required:
- compatible
+ deprecated: true
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- - clocks
- - clock-names
- iommus
- - memory-region
- - video-decoder
- - video-encoder
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,gcc-msm8916.h>
-
- video-codec@1d00000 {
- compatible = "qcom,msm8916-venus";
- reg = <0x01d00000 0xff000>;
- interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
- <&gcc GCC_VENUS0_AHB_CLK>,
- <&gcc GCC_VENUS0_AXI_CLK>;
- clock-names = "core", "iface", "bus";
- power-domains = <&gcc VENUS_GDSC>;
- iommus = <&apps_iommu 5>;
- memory-region = <&venus_mem>;
-
- video-decoder {
- compatible = "venus-decoder";
- };
-
- video-encoder {
- compatible = "venus-encoder";
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+
+ video-codec@1d00000 {
+ compatible = "qcom,msm8916-venus";
+ reg = <0x01d00000 0xff000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
+ <&gcc GCC_VENUS0_AHB_CLK>,
+ <&gcc GCC_VENUS0_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ power-domains = <&gcc VENUS_GDSC>;
+ iommus = <&apps_iommu 5>;
+ memory-region = <&venus_mem>;
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
new file mode 100644
index 000000000000..77b389d76a43
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
@@ -0,0 +1,254 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8939 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Vincent Knecht <vincent.knecht@mailoo.org>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
+
+properties:
+ compatible:
+ const: qcom,msm8939-camss
+
+ reg:
+ maxItems: 11
+
+ reg-names:
+ items:
+ - const: csiphy0
+ - const: csiphy0_clk_mux
+ - const: csiphy1
+ - const: csiphy1_clk_mux
+ - const: csid0
+ - const: csid1
+ - const: ispif
+ - const: csi_clk_mux
+ - const: vfe0
+ - const: csid2
+ - const: vfe0_vbif
+
+ clocks:
+ maxItems: 24
+
+ clock-names:
+ items:
+ - const: top_ahb
+ - const: ispif_ahb
+ - const: csiphy0_timer
+ - const: csiphy1_timer
+ - const: csi0_ahb
+ - const: csi0
+ - const: csi0_phy
+ - const: csi0_pix
+ - const: csi0_rdi
+ - const: csi1_ahb
+ - const: csi1
+ - const: csi1_phy
+ - const: csi1_pix
+ - const: csi1_rdi
+ - const: ahb
+ - const: vfe0
+ - const: csi_vfe0
+ - const: vfe_ahb
+ - const: vfe_axi
+ - const: csi2_ahb
+ - const: csi2
+ - const: csi2_phy
+ - const: csi2_pix
+ - const: csi2_rdi
+
+ interrupts:
+ maxItems: 7
+
+ interrupt-names:
+ items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csid0
+ - const: csid1
+ - const: ispif
+ - const: vfe0
+ - const: csid2
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: VFE GDSC - Video Front End, Global Distributed Switch
+ Controller.
+
+ vdda-supply:
+ description:
+ Definition of the regulator used as 1.2V analog power supply.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-1]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - vdda-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-msm8939.h>
+
+ isp@1b0ac00 {
+ compatible = "qcom,msm8939-camss";
+
+ reg = <0x01b0ac00 0x200>,
+ <0x01b00030 0x4>,
+ <0x01b0b000 0x200>,
+ <0x01b00038 0x4>,
+ <0x01b08000 0x100>,
+ <0x01b08400 0x100>,
+ <0x01b0a000 0x500>,
+ <0x01b00020 0x10>,
+ <0x01b10000 0x1000>,
+ <0x01b08800 0x100>,
+ <0x01b40000 0x200>;
+
+ reg-names = "csiphy0",
+ "csiphy0_clk_mux",
+ "csiphy1",
+ "csiphy1_clk_mux",
+ "csid0",
+ "csid1",
+ "ispif",
+ "csi_clk_mux",
+ "vfe0",
+ "csid2",
+ "vfe0_vbif";
+
+ clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI0PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI0RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI1_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI1PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI1RDI_CLK>,
+ <&gcc GCC_CAMSS_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
+ <&gcc GCC_CAMSS_VFE_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE_AXI_CLK>,
+ <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI2_CLK>,
+ <&gcc GCC_CAMSS_CSI2PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI2PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI2RDI_CLK>;
+
+ clock-names = "top_ahb",
+ "ispif_ahb",
+ "csiphy0_timer",
+ "csiphy1_timer",
+ "csi0_ahb",
+ "csi0",
+ "csi0_phy",
+ "csi0_pix",
+ "csi0_rdi",
+ "csi1_ahb",
+ "csi1",
+ "csi1_phy",
+ "csi1_pix",
+ "csi1_rdi",
+ "ahb",
+ "vfe0",
+ "csi_vfe0",
+ "vfe_ahb",
+ "vfe_axi",
+ "csi2_ahb",
+ "csi2",
+ "csi2_phy",
+ "csi2_pix",
+ "csi2_rdi";
+
+ interrupts = <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csiphy0",
+ "csiphy1",
+ "csid0",
+ "csid1",
+ "ispif",
+ "vfe0",
+ "csid2";
+
+ iommus = <&apps_iommu 3>;
+
+ power-domains = <&gcc VFE_GDSC>;
+
+ vdda-supply = <&reg_1v2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csiphy1_ep: endpoint {
+ data-lanes = <0 2>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8953-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8953-camss.yaml
new file mode 100644
index 000000000000..6d776b0ca711
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,msm8953-camss.yaml
@@ -0,0 +1,337 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,msm8953-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8953 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Barnabas Czeman <barnabas.czeman@mainlining.org>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
+
+properties:
+ compatible:
+ const: qcom,msm8953-camss
+
+ clocks:
+ minItems: 30
+ maxItems: 30
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: csi0
+ - const: csi0_ahb
+ - const: csi0_phy
+ - const: csi0_pix
+ - const: csi0_rdi
+ - const: csi1
+ - const: csi1_ahb
+ - const: csi1_phy
+ - const: csi1_pix
+ - const: csi1_rdi
+ - const: csi2
+ - const: csi2_ahb
+ - const: csi2_phy
+ - const: csi2_pix
+ - const: csi2_rdi
+ - const: csi_vfe0
+ - const: csi_vfe1
+ - const: csiphy0_timer
+ - const: csiphy1_timer
+ - const: csiphy2_timer
+ - const: ispif_ahb
+ - const: micro_ahb
+ - const: top_ahb
+ - const: vfe0
+ - const: vfe0_ahb
+ - const: vfe0_axi
+ - const: vfe1
+ - const: vfe1_ahb
+ - const: vfe1_axi
+
+ interrupts:
+ minItems: 9
+ maxItems: 9
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: ispif
+ - const: vfe0
+ - const: vfe1
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: VFE0 GDSC - Video Front End, Global Distributed Switch Controller.
+ - description: VFE1 GDSC - Video Front End, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: vfe0
+ - const: vfe1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description:
+ An array of physical data lanes indexes.
+ Position of an entry determines the logical
+ lane number, while the value of an entry
+ indicates physical lane index. Lane swapping
+ is supported. Physical lane indexes;
+ 0, 2, 3, 4.
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+ reg:
+ minItems: 13
+ maxItems: 13
+
+ reg-names:
+ items:
+ - const: csi_clk_mux
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy0_clk_mux
+ - const: csiphy1
+ - const: csiphy1_clk_mux
+ - const: csiphy2
+ - const: csiphy2_clk_mux
+ - const: ispif
+ - const: vfe0
+ - const: vfe1
+
+ vdda-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-msm8953.h>
+
+ camss: camss@1b00020 {
+ compatible = "qcom,msm8953-camss";
+
+ reg = <0x1b00020 0x10>,
+ <0x1b30000 0x100>,
+ <0x1b30400 0x100>,
+ <0x1b30800 0x100>,
+ <0x1b34000 0x1000>,
+ <0x1b00030 0x4>,
+ <0x1b35000 0x1000>,
+ <0x1b00038 0x4>,
+ <0x1b36000 0x1000>,
+ <0x1b00040 0x4>,
+ <0x1b31000 0x500>,
+ <0x1b10000 0x1000>,
+ <0x1b14000 0x1000>;
+ reg-names = "csi_clk_mux",
+ "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy0_clk_mux",
+ "csiphy1",
+ "csiphy1_clk_mux",
+ "csiphy2",
+ "csiphy2_clk_mux",
+ "ispif",
+ "vfe0",
+ "vfe1";
+
+ clocks = <&gcc GCC_CAMSS_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0_CLK>,
+ <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI0PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI0RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI1_CLK>,
+ <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI1PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI1RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI2_CLK>,
+ <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI2PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI2PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI2RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE1_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI2PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+ <&gcc GCC_CAMSS_MICRO_AHB_CLK>,
+ <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_CLK>,
+ <&gcc GCC_CAMSS_VFE0_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_AXI_CLK>,
+ <&gcc GCC_CAMSS_VFE1_CLK>,
+ <&gcc GCC_CAMSS_VFE1_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE1_AXI_CLK>;
+ clock-names = "ahb",
+ "csi0",
+ "csi0_ahb",
+ "csi0_phy",
+ "csi0_pix",
+ "csi0_rdi",
+ "csi1",
+ "csi1_ahb",
+ "csi1_phy",
+ "csi1_pix",
+ "csi1_rdi",
+ "csi2",
+ "csi2_ahb",
+ "csi2_phy",
+ "csi2_pix",
+ "csi2_rdi",
+ "csi_vfe0",
+ "csi_vfe1",
+ "csiphy0_timer",
+ "csiphy1_timer",
+ "csiphy2_timer",
+ "ispif_ahb",
+ "micro_ahb",
+ "top_ahb",
+ "vfe0",
+ "vfe0_ahb",
+ "vfe0_axi",
+ "vfe1",
+ "vfe1_ahb",
+ "vfe1_axi";
+
+ interrupts = <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 315 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "ispif",
+ "vfe0",
+ "vfe1";
+
+ iommus = <&apps_iommu 0x14>;
+
+ power-domains = <&gcc VFE0_GDSC>,
+ <&gcc VFE1_GDSC>;
+ power-domain-names = "vfe0", "vfe1";
+
+ vdda-supply = <&reg_2v8>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml
index 6aeb3d6d02d5..a2025952fe95 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm CAMSS ISP
@@ -116,6 +115,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -135,6 +139,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -154,6 +163,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -173,6 +187,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -221,7 +240,7 @@ examples:
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
- camss: camss@a00000 {
+ camss: camss@a34000 {
compatible = "qcom,msm8996-camss";
clocks = <&mmcc CAMSS_TOP_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
index 199f45217b4a..56c16458e3bb 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm MSM8996 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,15 +13,14 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
- const: qcom,msm8996-venus
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
+ enum:
+ - qcom,msm8996-venus
+ - qcom,msm8998-venus
power-domains:
maxItems: 1
@@ -37,12 +35,17 @@ properties:
- const: bus
- const: mbus
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: video-mem
+ - const: cpu-cfg
+
iommus:
maxItems: 20
- memory-region:
- maxItems: 1
-
video-decoder:
type: object
@@ -93,82 +96,62 @@ properties:
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- - clocks
- - clock-names
- iommus
- - memory-region
- video-decoder
- video-encoder
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,mmcc-msm8996.h>
-
- video-codec@c00000 {
- compatible = "qcom,msm8996-venus";
- reg = <0x00c00000 0xff000>;
- interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mmcc VIDEO_CORE_CLK>,
- <&mmcc VIDEO_AHB_CLK>,
- <&mmcc VIDEO_AXI_CLK>,
- <&mmcc VIDEO_MAXI_CLK>;
- clock-names = "core", "iface", "bus", "mbus";
- power-domains = <&mmcc VENUS_GDSC>;
- iommus = <&venus_smmu 0x00>,
- <&venus_smmu 0x01>,
- <&venus_smmu 0x0a>,
- <&venus_smmu 0x07>,
- <&venus_smmu 0x0e>,
- <&venus_smmu 0x0f>,
- <&venus_smmu 0x08>,
- <&venus_smmu 0x09>,
- <&venus_smmu 0x0b>,
- <&venus_smmu 0x0c>,
- <&venus_smmu 0x0d>,
- <&venus_smmu 0x10>,
- <&venus_smmu 0x11>,
- <&venus_smmu 0x21>,
- <&venus_smmu 0x28>,
- <&venus_smmu 0x29>,
- <&venus_smmu 0x2b>,
- <&venus_smmu 0x2c>,
- <&venus_smmu 0x2d>,
- <&venus_smmu 0x31>;
- memory-region = <&venus_mem>;
-
- video-decoder {
- compatible = "venus-decoder";
- clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
- clock-names = "core";
- power-domains = <&mmcc VENUS_CORE0_GDSC>;
- };
-
- video-encoder {
- compatible = "venus-encoder";
- clocks = <&mmcc VIDEO_SUBCORE1_CLK>;
- clock-names = "core";
- power-domains = <&mmcc VENUS_CORE1_GDSC>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,mmcc-msm8996.h>
+
+ video-codec@c00000 {
+ compatible = "qcom,msm8996-venus";
+ reg = <0x00c00000 0xff000>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mmcc VIDEO_CORE_CLK>,
+ <&mmcc VIDEO_AHB_CLK>,
+ <&mmcc VIDEO_AXI_CLK>,
+ <&mmcc VIDEO_MAXI_CLK>;
+ clock-names = "core", "iface", "bus", "mbus";
+ power-domains = <&mmcc VENUS_GDSC>;
+ iommus = <&venus_smmu 0x00>,
+ <&venus_smmu 0x01>,
+ <&venus_smmu 0x0a>,
+ <&venus_smmu 0x07>,
+ <&venus_smmu 0x0e>,
+ <&venus_smmu 0x0f>,
+ <&venus_smmu 0x08>,
+ <&venus_smmu 0x09>,
+ <&venus_smmu 0x0b>,
+ <&venus_smmu 0x0c>,
+ <&venus_smmu 0x0d>,
+ <&venus_smmu 0x10>,
+ <&venus_smmu 0x11>,
+ <&venus_smmu 0x21>,
+ <&venus_smmu 0x28>,
+ <&venus_smmu 0x29>,
+ <&venus_smmu 0x2b>,
+ <&venus_smmu 0x2c>,
+ <&venus_smmu 0x2d>,
+ <&venus_smmu 0x31>;
+ memory-region = <&venus_mem>;
+
+ video-decoder {
+ compatible = "venus-decoder";
+ clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
+ clock-names = "core";
+ power-domains = <&mmcc VENUS_CORE0_GDSC>;
+ };
+
+ video-encoder {
+ compatible = "venus-encoder";
+ clocks = <&mmcc VIDEO_SUBCORE1_CLK>;
+ clock-names = "core";
+ power-domains = <&mmcc VENUS_CORE1_GDSC>;
};
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
new file mode 100644
index 000000000000..391d0f6f67ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
@@ -0,0 +1,243 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,qcm2290-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCM2290 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Loic Poulain <loic.poulain@oss.qualcomm.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,qcm2290-camss
+
+ reg:
+ maxItems: 9
+
+ reg-names:
+ items:
+ - const: top
+ - const: csid0
+ - const: csid1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csitpg0
+ - const: csitpg1
+ - const: vfe0
+ - const: vfe1
+
+ clocks:
+ maxItems: 15
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: axi
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: csi0
+ - const: csi1
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: top_ahb
+ - const: vfe0
+ - const: vfe0_cphy_rx
+ - const: vfe1
+ - const: vfe1_cphy_rx
+
+ interrupts:
+ maxItems: 8
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csitpg0
+ - const: csitpg1
+ - const: vfe0
+ - const: vfe1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+ - const: sf_mnoc
+
+ iommus:
+ maxItems: 4
+
+ power-domains:
+ items:
+ - description: GDSC CAMSS Block, Global Distributed Switch Controller.
+
+ vdd-csiphy-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSI PHYs.
+
+ vdd-csiphy-1p8-supply:
+ description:
+ Phandle to 1.8V regulator supply to CSI PHYs pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-3]+$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data from a CSIPHY.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - vdd-csiphy-1p2-supply
+ - vdd-csiphy-1p8-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-qcm2290.h>
+ #include <dt-bindings/interconnect/qcom,rpm-icc.h>
+ #include <dt-bindings/interconnect/qcom,qcm2290.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: camss@5c6e000 {
+ compatible = "qcom,qcm2290-camss";
+
+ reg = <0x0 0x5c11000 0x0 0x1000>,
+ <0x0 0x5c6e000 0x0 0x1000>,
+ <0x0 0x5c75000 0x0 0x1000>,
+ <0x0 0x5c52000 0x0 0x1000>,
+ <0x0 0x5c53000 0x0 0x1000>,
+ <0x0 0x5c66000 0x0 0x400>,
+ <0x0 0x5c68000 0x0 0x400>,
+ <0x0 0x5c6f000 0x0 0x4000>,
+ <0x0 0x5c76000 0x0 0x4000>;
+ reg-names = "top",
+ "csid0",
+ "csid1",
+ "csiphy0",
+ "csiphy1",
+ "csitpg0",
+ "csitpg1",
+ "vfe0",
+ "vfe1";
+
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMSS_AXI_CLK>,
+ <&gcc GCC_CAMSS_NRT_AXI_CLK>,
+ <&gcc GCC_CAMSS_RT_AXI_CLK>,
+ <&gcc GCC_CAMSS_TFE_0_CSID_CLK>,
+ <&gcc GCC_CAMSS_TFE_1_CSID_CLK>,
+ <&gcc GCC_CAMSS_CPHY_0_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CPHY_1_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_TFE_0_CLK>,
+ <&gcc GCC_CAMSS_TFE_0_CPHY_RX_CLK>,
+ <&gcc GCC_CAMSS_TFE_1_CLK>,
+ <&gcc GCC_CAMSS_TFE_1_CPHY_RX_CLK>;
+ clock-names = "ahb",
+ "axi",
+ "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "csi0",
+ "csi1",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "top_ahb",
+ "vfe0",
+ "vfe0_cphy_rx",
+ "vfe1",
+ "vfe1_cphy_rx";
+
+ interrupts = <GIC_SPI 210 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 73 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 309 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 310 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 211 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 213 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csiphy0",
+ "csiphy1",
+ "csitpg0",
+ "csitpg1",
+ "vfe0",
+ "vfe1";
+
+ interconnects = <&bimc MASTER_APPSS_PROC RPM_ACTIVE_TAG
+ &config_noc SLAVE_CAMERA_CFG RPM_ACTIVE_TAG>,
+ <&mmrt_virt MASTER_CAMNOC_HF RPM_ALWAYS_TAG
+ &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
+ <&mmnrt_virt MASTER_CAMNOC_SF RPM_ALWAYS_TAG
+ &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>;
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_mnoc";
+
+ iommus = <&apps_smmu 0x400 0x0>,
+ <&apps_smmu 0x800 0x0>,
+ <&apps_smmu 0x820 0x0>,
+ <&apps_smmu 0x840 0x0>;
+
+ power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
+
+ vdd-csiphy-1p2-supply = <&pm4125_l5>;
+ vdd-csiphy-1p8-supply = <&pm4125_l13>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
new file mode 100644
index 000000000000..3f3ee82fc878
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,qcm2290-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCM2290 Venus video encode and decode accelerators
+
+maintainers:
+ - Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
+
+description:
+ The Venus AR50_LITE IP is a video encode and decode accelerator present
+ on Qualcomm platforms.
+
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qcm2290-venus
+
+ power-domains:
+ maxItems: 3
+
+ power-domain-names:
+ items:
+ - const: venus
+ - const: vcodec0
+ - const: cx
+
+ clocks:
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+ - const: bus
+ - const: throttle
+ - const: vcodec0_core
+ - const: vcodec0_bus
+
+ iommus:
+ maxItems: 5
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: video-mem
+ - const: cpu-cfg
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+required:
+ - compatible
+ - power-domain-names
+ - iommus
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-qcm2290.h>
+ #include <dt-bindings/interconnect/qcom,qcm2290.h>
+ #include <dt-bindings/interconnect/qcom,rpm-icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ venus: video-codec@5a00000 {
+ compatible = "qcom,qcm2290-venus";
+ reg = <0x5a00000 0xf0000>;
+
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+
+ power-domains = <&gcc GCC_VENUS_GDSC>,
+ <&gcc GCC_VCODEC0_GDSC>,
+ <&rpmpd QCM2290_VDDCX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "cx";
+
+ operating-points-v2 = <&venus_opp_table>;
+
+ clocks = <&gcc GCC_VIDEO_VENUS_CTL_CLK>,
+ <&gcc GCC_VIDEO_AHB_CLK>,
+ <&gcc GCC_VENUS_CTL_AXI_CLK>,
+ <&gcc GCC_VIDEO_THROTTLE_CORE_CLK>,
+ <&gcc GCC_VIDEO_VCODEC0_SYS_CLK>,
+ <&gcc GCC_VCODEC0_AXI_CLK>;
+ clock-names = "core",
+ "iface",
+ "bus",
+ "throttle",
+ "vcodec0_core",
+ "vcodec0_bus";
+
+ memory-region = <&pil_video_mem>;
+
+ iommus = <&apps_smmu 0x860 0x0>,
+ <&apps_smmu 0x880 0x0>,
+ <&apps_smmu 0x861 0x04>,
+ <&apps_smmu 0x863 0x0>,
+ <&apps_smmu 0x804 0xe0>;
+
+ interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
+ &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
+ <&bimc MASTER_APPSS_PROC RPM_ACTIVE_TAG
+ &config_noc SLAVE_VENUS_CFG RPM_ACTIVE_TAG>;
+ interconnect-names = "video-mem",
+ "cpu-cfg";
+
+ venus_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133333333 {
+ opp-hz = /bits/ 64 <133333333>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ };
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmpd_opp_svs>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml
new file mode 100644
index 000000000000..80a4540a22dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,qcs8300-camss.yaml
@@ -0,0 +1,336 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,qcs8300-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCS8300 CAMSS ISP
+
+maintainers:
+ - Vikram Sharma <quic_vikramsa@quicinc.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,qcs8300-camss
+
+ reg:
+ maxItems: 21
+
+ reg-names:
+ items:
+ - const: csid_wrapper
+ - const: csid0
+ - const: csid1
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_lite2
+ - const: csid_lite3
+ - const: csid_lite4
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: vfe_lite2
+ - const: vfe_lite3
+ - const: vfe_lite4
+
+ clocks:
+ maxItems: 26
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cpas_fast_ahb_clk
+ - const: cpas_vfe_lite
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: csid
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy_rx
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: icp_ahb
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 20
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_lite2
+ - const: csid_lite3
+ - const: csid_lite4
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: vfe_lite2
+ - const: vfe_lite3
+ - const: vfe_lite4
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_0
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: top
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-2]+$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 0-2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sa8775p-camcc.h>
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ #include <dt-bindings/interconnect/qcom,sa8775p-rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@ac78000 {
+ compatible = "qcom,qcs8300-camss";
+
+ reg = <0x0 0xac78000 0x0 0x1000>,
+ <0x0 0xac7a000 0x0 0x0f00>,
+ <0x0 0xac7c000 0x0 0x0f00>,
+ <0x0 0xac84000 0x0 0x0f00>,
+ <0x0 0xac88000 0x0 0x0f00>,
+ <0x0 0xac8c000 0x0 0x0f00>,
+ <0x0 0xac90000 0x0 0x0f00>,
+ <0x0 0xac94000 0x0 0x0f00>,
+ <0x0 0xac9c000 0x0 0x2000>,
+ <0x0 0xac9e000 0x0 0x2000>,
+ <0x0 0xaca0000 0x0 0x2000>,
+ <0x0 0xacac000 0x0 0x0400>,
+ <0x0 0xacad000 0x0 0x0400>,
+ <0x0 0xacae000 0x0 0x0400>,
+ <0x0 0xac4d000 0x0 0xd000>,
+ <0x0 0xac60000 0x0 0xd000>,
+ <0x0 0xac85000 0x0 0x0d00>,
+ <0x0 0xac89000 0x0 0x0d00>,
+ <0x0 0xac8d000 0x0 0x0d00>,
+ <0x0 0xac91000 0x0 0x0d00>,
+ <0x0 0xac95000 0x0 0x0d00>;
+ reg-names = "csid_wrapper",
+ "csid0",
+ "csid1",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_lite2",
+ "csid_lite3",
+ "csid_lite4",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "tpg0",
+ "tpg1",
+ "tpg2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1",
+ "vfe_lite2",
+ "vfe_lite3",
+ "vfe_lite4";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_ICP_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+ clock-names = "camnoc_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "cpas_vfe_lite",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "csid",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy_rx",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "icp_ahb",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 565 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 564 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 759 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 758 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 545 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 546 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 547 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 761 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 760 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_lite2",
+ "csid_lite3",
+ "csid_lite4",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "tpg0",
+ "tpg1",
+ "tpg2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1",
+ "vfe_lite2",
+ "vfe_lite3",
+ "vfe_lite4";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_0";
+
+ iommus = <&apps_smmu 0x2400 0x20>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "top";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sa8775p-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sa8775p-camss.yaml
new file mode 100644
index 000000000000..019caa2b09c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sa8775p-camss.yaml
@@ -0,0 +1,361 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sa8775p-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SA8775P CAMSS ISP
+
+maintainers:
+ - Vikram Sharma <quic_vikramsa@quicinc.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sa8775p-camss
+
+ reg:
+ maxItems: 22
+
+ reg-names:
+ items:
+ - const: csid_wrapper
+ - const: csid0
+ - const: csid1
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_lite2
+ - const: csid_lite3
+ - const: csid_lite4
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: vfe_lite2
+ - const: vfe_lite3
+ - const: vfe_lite4
+
+ clocks:
+ maxItems: 28
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cpas_fast_ahb_clk
+ - const: cpas_vfe_lite
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: csid
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy_rx
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: icp_ahb
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 21
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_lite2
+ - const: csid_lite3
+ - const: csid_lite4
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: vfe_lite2
+ - const: vfe_lite3
+ - const: vfe_lite4
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_0
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: top
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-3]+$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 0-3.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sa8775p-camcc.h>
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ #include <dt-bindings/interconnect/qcom,sa8775p-rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@ac78000 {
+ compatible = "qcom,sa8775p-camss";
+
+ reg = <0x0 0xac78000 0x0 0x1000>,
+ <0x0 0xac7a000 0x0 0x0f00>,
+ <0x0 0xac7c000 0x0 0x0f00>,
+ <0x0 0xac84000 0x0 0x0f00>,
+ <0x0 0xac88000 0x0 0x0f00>,
+ <0x0 0xac8c000 0x0 0x0f00>,
+ <0x0 0xac90000 0x0 0x0f00>,
+ <0x0 0xac94000 0x0 0x0f00>,
+ <0x0 0xac9c000 0x0 0x2000>,
+ <0x0 0xac9e000 0x0 0x2000>,
+ <0x0 0xaca0000 0x0 0x2000>,
+ <0x0 0xaca2000 0x0 0x2000>,
+ <0x0 0xacac000 0x0 0x0400>,
+ <0x0 0xacad000 0x0 0x0400>,
+ <0x0 0xacae000 0x0 0x0400>,
+ <0x0 0xac4d000 0x0 0xd000>,
+ <0x0 0xac5a000 0x0 0xd000>,
+ <0x0 0xac85000 0x0 0x0d00>,
+ <0x0 0xac89000 0x0 0x0d00>,
+ <0x0 0xac8d000 0x0 0x0d00>,
+ <0x0 0xac91000 0x0 0x0d00>,
+ <0x0 0xac95000 0x0 0x0d00>;
+ reg-names = "csid_wrapper",
+ "csid0",
+ "csid1",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_lite2",
+ "csid_lite3",
+ "csid_lite4",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "tpg0",
+ "tpg1",
+ "tpg2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1",
+ "vfe_lite2",
+ "vfe_lite3",
+ "vfe_lite4";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_ICP_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+ clock-names = "camnoc_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "cpas_vfe_lite",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "csid",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy_rx",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "icp_ahb",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 565 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 564 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 759 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 758 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 545 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 546 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 547 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 761 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 760 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_lite2",
+ "csid_lite3",
+ "csid_lite4",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "tpg0",
+ "tpg1",
+ "tpg2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1",
+ "vfe_lite2",
+ "vfe_lite3",
+ "vfe_lite4";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_0";
+
+ iommus = <&apps_smmu 0x3400 0x20>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "top";
+
+ vdda-phy-supply = <&vreg_l4a_0p88>;
+ vdda-pll-supply = <&vreg_l1c_1p2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 90b4af2c9724..bfd8b1ad4731 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm SC7180 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,15 +13,17 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
- const: qcom,sc7180-venus
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcs615-venus
+ - const: qcom,sc7180-venus
+ - const: qcom,sc7180-venus
power-domains:
minItems: 2
@@ -60,6 +61,10 @@ properties:
- const: video-mem
- const: cpu-cfg
+ operating-points-v2: true
+ opp-table:
+ type: object
+
video-decoder:
type: object
@@ -70,6 +75,7 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
video-encoder:
@@ -82,64 +88,35 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- power-domain-names
- - clocks
- - clock-names
- iommus
- - memory-region
- - video-decoder
- - video-encoder
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,videocc-sc7180.h>
-
- venus: video-codec@aa00000 {
- compatible = "qcom,sc7180-venus";
- reg = <0x0aa00000 0xff000>;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
- power-domains = <&videocc VENUS_GDSC>,
- <&videocc VCODEC0_GDSC>;
- power-domain-names = "venus", "vcodec0";
- clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
- <&videocc VIDEO_CC_VENUS_AHB_CLK>,
- <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
- <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
- <&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
- clock-names = "core", "iface", "bus",
- "vcodec0_core", "vcodec0_bus";
- iommus = <&apps_smmu 0x0c00 0x60>;
- memory-region = <&venus_mem>;
-
- video-decoder {
- compatible = "venus-decoder";
- };
-
- video-encoder {
- compatible = "venus-encoder";
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,videocc-sc7180.h>
+
+ venus: video-codec@aa00000 {
+ compatible = "qcom,sc7180-venus";
+ reg = <0x0aa00000 0xff000>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&videocc VENUS_GDSC>,
+ <&videocc VCODEC0_GDSC>;
+ power-domain-names = "venus", "vcodec0";
+ clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+ <&videocc VIDEO_CC_VENUS_AHB_CLK>,
+ <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
+ <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+ <&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+ clock-names = "core", "iface", "bus",
+ "vcodec0_core", "vcodec0_bus";
+ iommus = <&apps_smmu 0x0c00 0x60>;
+ memory-region = <&venus_mem>;
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml
new file mode 100644
index 000000000000..ee35e3bc97ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml
@@ -0,0 +1,425 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sc7280-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7280 CAMSS ISP
+
+maintainers:
+ - Azam Sadiq Pasha Kapatrala Syed <akapatra@quicinc.com>
+ - Hariram Purushothaman <hariramp@quicinc.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sc7280-camss
+
+ reg:
+ maxItems: 15
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 33
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: icp_ahb
+ - const: vfe0
+ - const: vfe0_axi
+ - const: vfe0_cphy_rx
+ - const: vfe0_csid
+ - const: vfe1
+ - const: vfe1_axi
+ - const: vfe1_cphy_rx
+ - const: vfe1_csid
+ - const: vfe2
+ - const: vfe2_axi
+ - const: vfe2_cphy_rx
+ - const: vfe2_csid
+ - const: vfe_lite0
+ - const: vfe_lite0_cphy_rx
+ - const: vfe_lite0_csid
+ - const: vfe_lite1
+ - const: vfe_lite1_cphy_rx
+ - const: vfe_lite1_csid
+
+ interrupts:
+ maxItems: 15
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_0
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 0.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 1.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 3.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSIPHY 4.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,camcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/interconnect/qcom,sc7280.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@acb3000 {
+ compatible = "qcom,sc7280-camss";
+
+ reg = <0x0 0x0acb3000 0x0 0x1000>,
+ <0x0 0x0acba000 0x0 0x1000>,
+ <0x0 0x0acc1000 0x0 0x1000>,
+ <0x0 0x0acc8000 0x0 0x1000>,
+ <0x0 0x0accf000 0x0 0x1000>,
+ <0x0 0x0ace0000 0x0 0x2000>,
+ <0x0 0x0ace2000 0x0 0x2000>,
+ <0x0 0x0ace4000 0x0 0x2000>,
+ <0x0 0x0ace6000 0x0 0x2000>,
+ <0x0 0x0ace8000 0x0 0x2000>,
+ <0x0 0x0acaf000 0x0 0x4000>,
+ <0x0 0x0acb6000 0x0 0x4000>,
+ <0x0 0x0acbd000 0x0 0x4000>,
+ <0x0 0x0acc4000 0x0 0x4000>,
+ <0x0 0x0accb000 0x0 0x4000>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_ICP_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_0_CSID_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_AXI_CLK>,
+ <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_1_CSID_CLK>,
+ <&camcc CAM_CC_IFE_2_CLK>,
+ <&camcc CAM_CC_IFE_2_AXI_CLK>,
+ <&camcc CAM_CC_IFE_2_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_2_CSID_CLK>,
+ <&camcc CAM_CC_IFE_LITE_0_CLK>,
+ <&camcc CAM_CC_IFE_LITE_0_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_0_CSID_CLK>,
+ <&camcc CAM_CC_IFE_LITE_1_CLK>,
+ <&camcc CAM_CC_IFE_LITE_1_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_1_CSID_CLK>;
+ clock-names = "camnoc_axi",
+ "cpas_ahb",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "icp_ahb",
+ "vfe0",
+ "vfe0_axi",
+ "vfe0_cphy_rx",
+ "vfe0_csid",
+ "vfe1",
+ "vfe1_axi",
+ "vfe1_cphy_rx",
+ "vfe1_csid",
+ "vfe2",
+ "vfe2_axi",
+ "vfe2_cphy_rx",
+ "vfe2_csid",
+ "vfe_lite0",
+ "vfe_lite0_cphy_rx",
+ "vfe_lite0_csid",
+ "vfe_lite1",
+ "vfe_lite1_cphy_rx",
+ "vfe_lite1_csid";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 640 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 641 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &cnoc2 SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_0";
+
+ iommus = <&apps_smmu 0x800 0x4e0>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_IFE_1_GDSC>,
+ <&camcc CAM_CC_IFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
index e2874683b4d5..413c5b4ee650 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm SC7280 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,16 +13,13 @@ description: |
The Venus Iris2 IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
const: qcom,sc7280-venus
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
power-domains:
minItems: 2
maxItems: 3
@@ -47,11 +43,9 @@ properties:
- const: vcodec_bus
iommus:
+ minItems: 1
maxItems: 2
- memory-region:
- maxItems: 1
-
interconnects:
maxItems: 2
@@ -60,6 +54,10 @@ properties:
- const: cpu-cfg
- const: video-mem
+ operating-points-v2: true
+ opp-table:
+ type: object
+
video-decoder:
type: object
@@ -70,6 +68,7 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
video-encoder:
@@ -82,80 +81,51 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- power-domain-names
- - clocks
- - clock-names
- iommus
- - memory-region
- - video-decoder
- - video-encoder
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,videocc-sc7280.h>
- #include <dt-bindings/interconnect/qcom,sc7280.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- venus: video-codec@aa00000 {
- compatible = "qcom,sc7280-venus";
- reg = <0x0aa00000 0xd0600>;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
-
- clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>,
- <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>,
- <&videocc VIDEO_CC_VENUS_AHB_CLK>,
- <&videocc VIDEO_CC_MVS0_CORE_CLK>,
- <&videocc VIDEO_CC_MVS0_AXI_CLK>;
- clock-names = "core", "bus", "iface",
- "vcodec_core", "vcodec_bus";
-
- power-domains = <&videocc MVSC_GDSC>,
- <&videocc MVS0_GDSC>,
- <&rpmhpd SC7280_CX>;
- power-domain-names = "venus", "vcodec0", "cx";
-
- interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>,
- <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>;
- interconnect-names = "cpu-cfg", "video-mem";
-
- iommus = <&apps_smmu 0x2180 0x20>,
- <&apps_smmu 0x2184 0x20>;
-
- memory-region = <&video_mem>;
-
- video-decoder {
- compatible = "venus-decoder";
- };
-
- video-encoder {
- compatible = "venus-encoder";
- };
-
- video-firmware {
- iommus = <&apps_smmu 0x21a2 0x0>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,videocc-sc7280.h>
+ #include <dt-bindings/interconnect/qcom,sc7280.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ venus: video-codec@aa00000 {
+ compatible = "qcom,sc7280-venus";
+ reg = <0x0aa00000 0xd0600>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>,
+ <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>,
+ <&videocc VIDEO_CC_VENUS_AHB_CLK>,
+ <&videocc VIDEO_CC_MVS0_CORE_CLK>,
+ <&videocc VIDEO_CC_MVS0_AXI_CLK>;
+ clock-names = "core", "bus", "iface",
+ "vcodec_core", "vcodec_bus";
+
+ power-domains = <&videocc MVSC_GDSC>,
+ <&videocc MVS0_GDSC>,
+ <&rpmhpd SC7280_CX>;
+ power-domain-names = "venus", "vcodec0", "cx";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>,
+ <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "cpu-cfg", "video-mem";
+
+ iommus = <&apps_smmu 0x2180 0x20>,
+ <&apps_smmu 0x2184 0x20>;
+
+ memory-region = <&video_mem>;
+
+ video-firmware {
+ iommus = <&apps_smmu 0x21a2 0x0>;
};
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml
new file mode 100644
index 000000000000..c99fe4106eee
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml
@@ -0,0 +1,531 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sc8280xp-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP Camera Subsystem (CAMSS)
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description: |
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sc8280xp-camss
+
+ clocks:
+ maxItems: 40
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: vfe0_axi
+ - const: vfe0
+ - const: vfe0_cphy_rx
+ - const: vfe0_csid
+ - const: vfe1_axi
+ - const: vfe1
+ - const: vfe1_cphy_rx
+ - const: vfe1_csid
+ - const: vfe2_axi
+ - const: vfe2
+ - const: vfe2_cphy_rx
+ - const: vfe2_csid
+ - const: vfe3_axi
+ - const: vfe3
+ - const: vfe3_cphy_rx
+ - const: vfe3_csid
+ - const: vfe_lite0
+ - const: vfe_lite0_cphy_rx
+ - const: vfe_lite0_csid
+ - const: vfe_lite1
+ - const: vfe_lite1_cphy_rx
+ - const: vfe_lite1_csid
+ - const: vfe_lite2
+ - const: vfe_lite2_cphy_rx
+ - const: vfe_lite2_csid
+ - const: vfe_lite3
+ - const: vfe_lite3_cphy_rx
+ - const: vfe_lite3_csid
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+
+ interrupts:
+ maxItems: 20
+
+ interrupt-names:
+ items:
+ - const: csid1_lite
+ - const: vfe_lite1
+ - const: csiphy3
+ - const: csid0
+ - const: vfe0
+ - const: csid1
+ - const: vfe1
+ - const: csid0_lite
+ - const: vfe_lite0
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csid2
+ - const: vfe2
+ - const: csid3_lite
+ - const: csid2_lite
+ - const: vfe_lite3
+ - const: vfe_lite2
+ - const: csid3
+ - const: vfe3
+
+ iommus:
+ maxItems: 16
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: cam_ahb
+ - const: cam_hf_mnoc
+ - const: cam_sf_mnoc
+ - const: cam_sf_icp_mnoc
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE3 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: ife3
+ - const: top
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY0.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY1.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY3.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ reg:
+ maxItems: 20
+
+ reg-names:
+ items:
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy0
+ - const: csiphy1
+ - const: vfe0
+ - const: csid0
+ - const: vfe1
+ - const: csid1
+ - const: vfe2
+ - const: csid2
+ - const: vfe_lite0
+ - const: csid0_lite
+ - const: vfe_lite1
+ - const: csid1_lite
+ - const: vfe_lite2
+ - const: csid2_lite
+ - const: vfe_lite3
+ - const: csid3_lite
+ - const: vfe3
+ - const: csid3
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+required:
+ - clock-names
+ - clocks
+ - compatible
+ - interconnects
+ - interconnect-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - reg
+ - reg-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,sc8280xp-camcc.h>
+ #include <dt-bindings/interconnect/qcom,sc8280xp.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: camss@ac5a000 {
+ compatible = "qcom,sc8280xp-camss";
+
+ reg = <0 0x0ac5a000 0 0x2000>,
+ <0 0x0ac5c000 0 0x2000>,
+ <0 0x0ac65000 0 0x2000>,
+ <0 0x0ac67000 0 0x2000>,
+ <0 0x0acaf000 0 0x4000>,
+ <0 0x0acb3000 0 0x1000>,
+ <0 0x0acb6000 0 0x4000>,
+ <0 0x0acba000 0 0x1000>,
+ <0 0x0acbd000 0 0x4000>,
+ <0 0x0acc1000 0 0x1000>,
+ <0 0x0acc4000 0 0x4000>,
+ <0 0x0acc8000 0 0x1000>,
+ <0 0x0accb000 0 0x4000>,
+ <0 0x0accf000 0 0x1000>,
+ <0 0x0acd2000 0 0x4000>,
+ <0 0x0acd6000 0 0x1000>,
+ <0 0x0acd9000 0 0x4000>,
+ <0 0x0acdd000 0 0x1000>,
+ <0 0x0ace0000 0 0x4000>,
+ <0 0x0ace4000 0 0x1000>;
+
+ reg-names = "csiphy2",
+ "csiphy3",
+ "csiphy0",
+ "csiphy1",
+ "vfe0",
+ "csid0",
+ "vfe1",
+ "csid1",
+ "vfe2",
+ "csid2",
+ "vfe_lite0",
+ "csid0_lite",
+ "vfe_lite1",
+ "csid1_lite",
+ "vfe_lite2",
+ "csid2_lite",
+ "vfe_lite3",
+ "csid3_lite",
+ "vfe3",
+ "csid3";
+
+ vdda-phy-supply = <&vreg_l6d>;
+ vdda-pll-supply = <&vreg_l4d>;
+
+ interrupts = <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 640 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 641 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 758 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 759 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 760 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 761 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 762 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 764 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid1_lite",
+ "vfe_lite1",
+ "csiphy3",
+ "csid0",
+ "vfe0",
+ "csid1",
+ "vfe1",
+ "csid0_lite",
+ "vfe_lite0",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csid2",
+ "vfe2",
+ "csid3_lite",
+ "csid2_lite",
+ "vfe_lite3",
+ "vfe_lite2",
+ "csid3",
+ "vfe3";
+
+ power-domains = <&camcc IFE_0_GDSC>,
+ <&camcc IFE_1_GDSC>,
+ <&camcc IFE_2_GDSC>,
+ <&camcc IFE_3_GDSC>,
+ <&camcc TITAN_TOP_GDSC>;
+
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "ife3",
+ "top";
+
+ clocks = <&camcc CAMCC_CAMNOC_AXI_CLK>,
+ <&camcc CAMCC_CPAS_AHB_CLK>,
+ <&camcc CAMCC_CSIPHY0_CLK>,
+ <&camcc CAMCC_CSI0PHYTIMER_CLK>,
+ <&camcc CAMCC_CSIPHY1_CLK>,
+ <&camcc CAMCC_CSI1PHYTIMER_CLK>,
+ <&camcc CAMCC_CSIPHY2_CLK>,
+ <&camcc CAMCC_CSI2PHYTIMER_CLK>,
+ <&camcc CAMCC_CSIPHY3_CLK>,
+ <&camcc CAMCC_CSI3PHYTIMER_CLK>,
+ <&camcc CAMCC_IFE_0_AXI_CLK>,
+ <&camcc CAMCC_IFE_0_CLK>,
+ <&camcc CAMCC_IFE_0_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_0_CSID_CLK>,
+ <&camcc CAMCC_IFE_1_AXI_CLK>,
+ <&camcc CAMCC_IFE_1_CLK>,
+ <&camcc CAMCC_IFE_1_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_1_CSID_CLK>,
+ <&camcc CAMCC_IFE_2_AXI_CLK>,
+ <&camcc CAMCC_IFE_2_CLK>,
+ <&camcc CAMCC_IFE_2_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_2_CSID_CLK>,
+ <&camcc CAMCC_IFE_3_AXI_CLK>,
+ <&camcc CAMCC_IFE_3_CLK>,
+ <&camcc CAMCC_IFE_3_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_3_CSID_CLK>,
+ <&camcc CAMCC_IFE_LITE_0_CLK>,
+ <&camcc CAMCC_IFE_LITE_0_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_LITE_0_CSID_CLK>,
+ <&camcc CAMCC_IFE_LITE_1_CLK>,
+ <&camcc CAMCC_IFE_LITE_1_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_LITE_1_CSID_CLK>,
+ <&camcc CAMCC_IFE_LITE_2_CLK>,
+ <&camcc CAMCC_IFE_LITE_2_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_LITE_2_CSID_CLK>,
+ <&camcc CAMCC_IFE_LITE_3_CLK>,
+ <&camcc CAMCC_IFE_LITE_3_CPHY_RX_CLK>,
+ <&camcc CAMCC_IFE_LITE_3_CSID_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>;
+
+ clock-names = "camnoc_axi",
+ "cpas_ahb",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "vfe0_axi",
+ "vfe0",
+ "vfe0_cphy_rx",
+ "vfe0_csid",
+ "vfe1_axi",
+ "vfe1",
+ "vfe1_cphy_rx",
+ "vfe1_csid",
+ "vfe2_axi",
+ "vfe2",
+ "vfe2_cphy_rx",
+ "vfe2_csid",
+ "vfe3_axi",
+ "vfe3",
+ "vfe3_cphy_rx",
+ "vfe3_csid",
+ "vfe_lite0",
+ "vfe_lite0_cphy_rx",
+ "vfe_lite0_csid",
+ "vfe_lite1",
+ "vfe_lite1_cphy_rx",
+ "vfe_lite1_csid",
+ "vfe_lite2",
+ "vfe_lite2_cphy_rx",
+ "vfe_lite2_csid",
+ "vfe_lite3",
+ "vfe_lite3_cphy_rx",
+ "vfe_lite3_csid",
+ "gcc_axi_hf",
+ "gcc_axi_sf";
+
+ iommus = <&apps_smmu 0x2000 0x4e0>,
+ <&apps_smmu 0x2020 0x4e0>,
+ <&apps_smmu 0x2040 0x4e0>,
+ <&apps_smmu 0x2060 0x4e0>,
+ <&apps_smmu 0x2080 0x4e0>,
+ <&apps_smmu 0x20e0 0x4e0>,
+ <&apps_smmu 0x20c0 0x4e0>,
+ <&apps_smmu 0x20a0 0x4e0>,
+ <&apps_smmu 0x2400 0x4e0>,
+ <&apps_smmu 0x2420 0x4e0>,
+ <&apps_smmu 0x2440 0x4e0>,
+ <&apps_smmu 0x2460 0x4e0>,
+ <&apps_smmu 0x2480 0x4e0>,
+ <&apps_smmu 0x24e0 0x4e0>,
+ <&apps_smmu 0x24c0 0x4e0>,
+ <&apps_smmu 0x24a0 0x4e0>;
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "cam_ahb",
+ "cam_hf_mnoc",
+ "cam_sf_mnoc",
+ "cam_sf_icp_mnoc";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy_ep0: endpoint@0 {
+ reg = <0>;
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml
index b28c8e17f158..6e6ad8390e44 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm CAMSS ISP
@@ -122,6 +121,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -141,6 +145,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -160,6 +169,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -179,6 +193,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -227,7 +246,7 @@ examples:
#include <dt-bindings/clock/qcom,gcc-sdm660.h>
#include <dt-bindings/clock/qcom,mmcc-sdm660.h>
- camss: camss@ca00000 {
+ camss: camss@ca00020 {
compatible = "qcom,sdm660-camss";
clocks = <&mmcc CAMSS_AHB_CLK>,
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml
index 33da7d3cfd38..a51835b22045 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm SDM660 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -15,13 +14,13 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
const: qcom,sdm660-venus
- reg:
- maxItems: 1
-
clocks:
maxItems: 4
@@ -40,15 +39,9 @@ properties:
- const: cpu-cfg
- const: video-mem
- interrupts:
- maxItems: 1
-
iommus:
maxItems: 20
- memory-region:
- maxItems: 1
-
power-domains:
maxItems: 1
@@ -102,85 +95,65 @@ properties:
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - clocks
- - clock-names
- - interrupts
- iommus
- - memory-region
- - power-domains
- video-decoder
- video-encoder
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,mmcc-sdm660.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- video-codec@cc00000 {
- compatible = "qcom,sdm660-venus";
- reg = <0x0cc00000 0xff000>;
- clocks = <&mmcc VIDEO_CORE_CLK>,
- <&mmcc VIDEO_AHB_CLK>,
- <&mmcc VIDEO_AXI_CLK>,
- <&mmcc THROTTLE_VIDEO_AXI_CLK>;
- clock-names = "core", "iface", "bus", "bus_throttle";
- interconnects = <&gnoc 0 &mnoc 13>,
- <&mnoc 4 &bimc 5>;
- interconnect-names = "cpu-cfg", "video-mem";
- interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
- iommus = <&mmss_smmu 0x400>,
- <&mmss_smmu 0x401>,
- <&mmss_smmu 0x40a>,
- <&mmss_smmu 0x407>,
- <&mmss_smmu 0x40e>,
- <&mmss_smmu 0x40f>,
- <&mmss_smmu 0x408>,
- <&mmss_smmu 0x409>,
- <&mmss_smmu 0x40b>,
- <&mmss_smmu 0x40c>,
- <&mmss_smmu 0x40d>,
- <&mmss_smmu 0x410>,
- <&mmss_smmu 0x421>,
- <&mmss_smmu 0x428>,
- <&mmss_smmu 0x429>,
- <&mmss_smmu 0x42b>,
- <&mmss_smmu 0x42c>,
- <&mmss_smmu 0x42d>,
- <&mmss_smmu 0x411>,
- <&mmss_smmu 0x431>;
- memory-region = <&venus_region>;
- power-domains = <&mmcc VENUS_GDSC>;
-
- video-decoder {
- compatible = "venus-decoder";
- clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
- clock-names = "vcodec0_core";
- power-domains = <&mmcc VENUS_CORE0_GDSC>;
- };
-
- video-encoder {
- compatible = "venus-encoder";
- clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
- clock-names = "vcodec0_core";
- power-domains = <&mmcc VENUS_CORE0_GDSC>;
- };
+ #include <dt-bindings/clock/qcom,mmcc-sdm660.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ video-codec@cc00000 {
+ compatible = "qcom,sdm660-venus";
+ reg = <0x0cc00000 0xff000>;
+ clocks = <&mmcc VIDEO_CORE_CLK>,
+ <&mmcc VIDEO_AHB_CLK>,
+ <&mmcc VIDEO_AXI_CLK>,
+ <&mmcc THROTTLE_VIDEO_AXI_CLK>;
+ clock-names = "core", "iface", "bus", "bus_throttle";
+ interconnects = <&gnoc 0 &mnoc 13>,
+ <&mnoc 4 &bimc 5>;
+ interconnect-names = "cpu-cfg", "video-mem";
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ iommus = <&mmss_smmu 0x400>,
+ <&mmss_smmu 0x401>,
+ <&mmss_smmu 0x40a>,
+ <&mmss_smmu 0x407>,
+ <&mmss_smmu 0x40e>,
+ <&mmss_smmu 0x40f>,
+ <&mmss_smmu 0x408>,
+ <&mmss_smmu 0x409>,
+ <&mmss_smmu 0x40b>,
+ <&mmss_smmu 0x40c>,
+ <&mmss_smmu 0x40d>,
+ <&mmss_smmu 0x410>,
+ <&mmss_smmu 0x421>,
+ <&mmss_smmu 0x428>,
+ <&mmss_smmu 0x429>,
+ <&mmss_smmu 0x42b>,
+ <&mmss_smmu 0x42c>,
+ <&mmss_smmu 0x42d>,
+ <&mmss_smmu 0x411>,
+ <&mmss_smmu 0x431>;
+ memory-region = <&venus_region>;
+ power-domains = <&mmcc VENUS_GDSC>;
+
+ video-decoder {
+ compatible = "venus-decoder";
+ clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
+ clock-names = "vcodec0_core";
+ power-domains = <&mmcc VENUS_CORE0_GDSC>;
+ };
+
+ video-encoder {
+ compatible = "venus-encoder";
+ clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
+ clock-names = "vcodec0_core";
+ power-domains = <&mmcc VENUS_CORE0_GDSC>;
};
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml
new file mode 100644
index 000000000000..35c40fe22376
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml
@@ -0,0 +1,318 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sdm670-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM670 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Richard Acayan <mailingradian@gmail.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sdm670-camss
+
+ reg:
+ maxItems: 9
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite
+
+ interrupts:
+ maxItems: 9
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite
+
+ clocks:
+ maxItems: 22
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: csi0
+ - const: csi1
+ - const: csi2
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: gcc_camera_ahb
+ - const: gcc_camera_axi
+ - const: soc_ahb
+ - const: vfe0
+ - const: vfe0_axi
+ - const: vfe0_cphy_rx
+ - const: vfe1
+ - const: vfe1_axi
+ - const: vfe1_cphy_rx
+ - const: vfe_lite
+ - const: vfe_lite_cphy_rx
+
+ iommus:
+ maxItems: 4
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: top
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY0.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY1.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,camcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@acb3000 {
+ compatible = "qcom,sdm670-camss";
+
+ reg = <0 0x0acb3000 0 0x1000>,
+ <0 0x0acba000 0 0x1000>,
+ <0 0x0acc8000 0 0x1000>,
+ <0 0x0ac65000 0 0x1000>,
+ <0 0x0ac66000 0 0x1000>,
+ <0 0x0ac67000 0 0x1000>,
+ <0 0x0acaf000 0 0x4000>,
+ <0 0x0acb6000 0 0x4000>,
+ <0 0x0acc4000 0 0x4000>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CSID_CLK>,
+ <&camcc CAM_CC_IFE_1_CSID_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_AXI_CLK>,
+ <&camcc CAM_CC_SOC_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_AXI_CLK>,
+ <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>;
+ clock-names = "camnoc_axi",
+ "cpas_ahb",
+ "csi0",
+ "csi1",
+ "csi2",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "gcc_camera_ahb",
+ "gcc_camera_axi",
+ "soc_ahb",
+ "vfe0",
+ "vfe0_axi",
+ "vfe0_cphy_rx",
+ "vfe1",
+ "vfe1_axi",
+ "vfe1_cphy_rx",
+ "vfe_lite",
+ "vfe_lite_cphy_rx";
+
+ iommus = <&apps_smmu 0x808 0x0>,
+ <&apps_smmu 0x810 0x8>,
+ <&apps_smmu 0xc08 0x0>,
+ <&apps_smmu 0xc10 0x8>;
+
+ power-domains = <&camcc IFE_0_GDSC>,
+ <&camcc IFE_1_GDSC>,
+ <&camcc TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "top";
+
+ vdda-phy-supply = <&vreg_l1a_1p225>;
+ vdda-pll-supply = <&vreg_l8a_1p8>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csiphy_ep0: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&front_sensor_ep>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml
index f9a003882f84..82bf4689d330 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm CAMSS ISP
@@ -109,6 +108,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -128,6 +132,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -147,6 +156,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -166,6 +180,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -219,7 +238,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
- camss: camss@a00000 {
+ camss: camss@acb3000 {
compatible = "qcom,sdm845-camss";
clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>,
@@ -296,16 +315,16 @@ examples:
"vfe_lite_cphy_rx",
"vfe_lite_src";
- interrupts = <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "csid0",
"csid1",
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 177bf81544b1..c839cb1ebc09 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm SDM845 Venus v2 video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,16 +13,13 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
const: qcom,sdm845-venus-v2
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
power-domains:
minItems: 3
maxItems: 4
@@ -52,8 +48,17 @@ properties:
iommus:
maxItems: 2
- memory-region:
- maxItems: 1
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: video-mem
+ - const: cpu-cfg
+
+ operating-points-v2: true
+ opp-table:
+ type: object
video-core0:
type: object
@@ -65,6 +70,7 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
video-core1:
@@ -77,69 +83,40 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- power-domain-names
- - clocks
- - clock-names
- iommus
- - memory-region
- - video-core0
- - video-core1
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,videocc-sdm845.h>
-
- video-codec@aa00000 {
- compatible = "qcom,sdm845-venus-v2";
- reg = <0x0aa00000 0xff000>;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
- <&videocc VIDEO_CC_VENUS_AHB_CLK>,
- <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
- <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
- <&videocc VIDEO_CC_VCODEC0_AXI_CLK>,
- <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
- <&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
- clock-names = "core", "iface", "bus",
- "vcodec0_core", "vcodec0_bus",
- "vcodec1_core", "vcodec1_bus";
- power-domains = <&videocc VENUS_GDSC>,
- <&videocc VCODEC0_GDSC>,
- <&videocc VCODEC1_GDSC>;
- power-domain-names = "venus", "vcodec0", "vcodec1";
- iommus = <&apps_smmu 0x10a0 0x8>,
- <&apps_smmu 0x10b0 0x0>;
- memory-region = <&venus_mem>;
-
- video-core0 {
- compatible = "venus-decoder";
- };
-
- video-core1 {
- compatible = "venus-encoder";
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,videocc-sdm845.h>
+
+ video-codec@aa00000 {
+ compatible = "qcom,sdm845-venus-v2";
+ reg = <0x0aa00000 0xff000>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+ <&videocc VIDEO_CC_VENUS_AHB_CLK>,
+ <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
+ <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+ <&videocc VIDEO_CC_VCODEC0_AXI_CLK>,
+ <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
+ <&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
+ clock-names = "core", "iface", "bus",
+ "vcodec0_core", "vcodec0_bus",
+ "vcodec1_core", "vcodec1_bus";
+ power-domains = <&videocc VENUS_GDSC>,
+ <&videocc VCODEC0_GDSC>,
+ <&videocc VCODEC1_GDSC>;
+ power-domain-names = "venus", "vcodec0", "vcodec1";
+ iommus = <&apps_smmu 0x10a0 0x8>,
+ <&apps_smmu 0x10b0 0x0>;
+ memory-region = <&venus_mem>;
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
index 680f37726fdf..eabc0957b241 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm SDM845 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,16 +13,13 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
const: qcom,sdm845-venus
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
power-domains:
maxItems: 1
@@ -39,9 +35,6 @@ properties:
iommus:
maxItems: 2
- memory-region:
- maxItems: 1
-
video-core0:
type: object
@@ -94,65 +87,45 @@ properties:
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- - clocks
- - clock-names
- iommus
- - memory-region
- video-core0
- video-core1
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,videocc-sdm845.h>
-
- video-codec@aa00000 {
- compatible = "qcom,sdm845-venus";
- reg = <0x0aa00000 0xff000>;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
- <&videocc VIDEO_CC_VENUS_AHB_CLK>,
- <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
- clock-names = "core", "iface", "bus";
- power-domains = <&videocc VENUS_GDSC>;
- iommus = <&apps_smmu 0x10a0 0x8>,
- <&apps_smmu 0x10b0 0x0>;
- memory-region = <&venus_mem>;
-
- video-core0 {
- compatible = "venus-decoder";
- clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
- <&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
- clock-names = "core", "bus";
- power-domains = <&videocc VCODEC0_GDSC>;
- };
-
- video-core1 {
- compatible = "venus-encoder";
- clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
- <&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
- clock-names = "core", "bus";
- power-domains = <&videocc VCODEC1_GDSC>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,videocc-sdm845.h>
+
+ video-codec@aa00000 {
+ compatible = "qcom,sdm845-venus";
+ reg = <0x0aa00000 0xff000>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
+ <&videocc VIDEO_CC_VENUS_AHB_CLK>,
+ <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ power-domains = <&videocc VENUS_GDSC>;
+ iommus = <&apps_smmu 0x10a0 0x8>,
+ <&apps_smmu 0x10b0 0x0>;
+ memory-region = <&venus_mem>;
+
+ video-core0 {
+ compatible = "venus-decoder";
+ clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
+ <&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <&videocc VCODEC0_GDSC>;
+ };
+
+ video-core1 {
+ compatible = "venus-encoder";
+ clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
+ <&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
+ clock-names = "core", "bus";
+ power-domains = <&videocc VCODEC1_GDSC>;
};
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml
index 07a2af12f37d..ebf68ff4ab96 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm CAMSS ISP
@@ -129,6 +128,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- clock-lanes
- data-lanes
@@ -152,6 +156,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- clock-lanes
- data-lanes
@@ -175,6 +184,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- clock-lanes
- data-lanes
@@ -198,6 +212,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- clock-lanes
- data-lanes
@@ -221,6 +240,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- clock-lanes
- data-lanes
@@ -244,6 +268,11 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- clock-lanes
- data-lanes
@@ -329,20 +358,20 @@ examples:
vdda-phy-supply = <&vreg_l5a_0p88>;
vdda-pll-supply = <&vreg_l9a_1p2>;
- interrupts = <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 86 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "csiphy0",
"csiphy1",
"csiphy2",
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml
index ebf8f3d866a5..da54493220c9 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/qcom,sm8250-venus.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/qcom,sm8250-venus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Venus video encode and decode accelerators
+title: Qualcomm SM8250 Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
@@ -14,16 +13,13 @@ description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
properties:
compatible:
const: qcom,sm8250-venus
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
power-domains:
minItems: 2
maxItems: 3
@@ -47,9 +43,6 @@ properties:
iommus:
maxItems: 1
- memory-region:
- maxItems: 1
-
interconnects:
maxItems: 2
@@ -58,6 +51,10 @@ properties:
- const: cpu-cfg
- const: video-mem
+ operating-points-v2: true
+ opp-table:
+ type: object
+
resets:
maxItems: 2
@@ -76,6 +73,7 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
video-encoder:
@@ -88,79 +86,50 @@ properties:
required:
- compatible
+ deprecated: true
additionalProperties: false
- video-firmware:
- type: object
-
- description: |
- Firmware subnode is needed when the platform does not
- have TrustZone.
-
- properties:
- iommus:
- maxItems: 1
-
- required:
- - iommus
-
required:
- compatible
- - reg
- - interrupts
- - power-domains
- power-domain-names
- - clocks
- - clock-names
- interconnects
- interconnect-names
- iommus
- - memory-region
- resets
- reset-names
- - video-decoder
- - video-encoder
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,videocc-sm8250.h>
- #include <dt-bindings/interconnect/qcom,sm8250.h>
- #include <dt-bindings/clock/qcom,gcc-sm8250.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
-
- venus: video-codec@aa00000 {
- compatible = "qcom,sm8250-venus";
- reg = <0x0aa00000 0xff000>;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
- power-domains = <&videocc MVS0C_GDSC>,
- <&videocc MVS0_GDSC>,
- <&rpmhpd SM8250_MX>;
- power-domain-names = "venus", "vcodec0", "mx";
-
- clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
- <&videocc VIDEO_CC_MVS0C_CLK>,
- <&videocc VIDEO_CC_MVS0_CLK>;
- clock-names = "iface", "core", "vcodec0_core";
-
- interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_VENUS_CFG>,
- <&mmss_noc MASTER_VIDEO_P0 &mc_virt SLAVE_EBI_CH0>;
- interconnect-names = "cpu-cfg", "video-mem";
-
- iommus = <&apps_smmu 0x2100 0x0400>;
- memory-region = <&video_mem>;
-
- resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
- <&videocc VIDEO_CC_MVS0C_CLK_ARES>;
- reset-names = "bus", "core";
-
- video-decoder {
- compatible = "venus-decoder";
- };
-
- video-encoder {
- compatible = "venus-encoder";
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,videocc-sm8250.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ venus: video-codec@aa00000 {
+ compatible = "qcom,sm8250-venus";
+ reg = <0x0aa00000 0xff000>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&videocc MVS0C_GDSC>,
+ <&videocc MVS0_GDSC>,
+ <&rpmhpd RPMHPD_MX>;
+ power-domain-names = "venus", "vcodec0", "mx";
+
+ clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
+ <&videocc VIDEO_CC_MVS0C_CLK>,
+ <&videocc VIDEO_CC_MVS0_CLK>;
+ clock-names = "iface", "core", "vcodec0_core";
+
+ interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_VENUS_CFG>,
+ <&mmss_noc MASTER_VIDEO_P0 &mc_virt SLAVE_EBI_CH0>;
+ interconnect-names = "cpu-cfg", "video-mem";
+
+ iommus = <&apps_smmu 0x2100 0x0400>;
+ memory-region = <&video_mem>;
+
+ resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
+ <&videocc VIDEO_CC_MVS0C_CLK_ARES>;
+ reset-names = "bus", "core";
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
new file mode 100644
index 000000000000..cd34f14916b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
@@ -0,0 +1,597 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Depeng Shao <quic_depengs@quicinc.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sm8550-camss
+
+ reg:
+ maxItems: 19
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_wrapper
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csiphy6
+ - const: csiphy7
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 36
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: cpas_fast_ahb_clk
+ - const: cpas_ife_lite
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: cpas_vfe2
+ - const: csid
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: csiphy6
+ - const: csiphy6_timer
+ - const: csiphy7
+ - const: csiphy7_timer
+ - const: csiphy_rx
+ - const: gcc_axi_hf
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 18
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csiphy6
+ - const: csiphy7
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_0_mnoc
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI0.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI1.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI3.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI4.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@5:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI5.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@6:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI6.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@7:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI7.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm8550-camcc.h>
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@acb7000 {
+ compatible = "qcom,sm8550-camss";
+
+ reg = <0 0x0acb7000 0 0xd00>,
+ <0 0x0acb9000 0 0xd00>,
+ <0 0x0acbb000 0 0xd00>,
+ <0 0x0acca000 0 0xa00>,
+ <0 0x0acce000 0 0xa00>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ace4000 0 0x2000>,
+ <0 0x0ace6000 0 0x2000>,
+ <0 0x0ace8000 0 0x2000>,
+ <0 0x0acea000 0 0x2000>,
+ <0 0x0acec000 0 0x2000>,
+ <0 0x0acee000 0 0x2000>,
+ <0 0x0acf0000 0 0x2000>,
+ <0 0x0acf2000 0 0x2000>,
+ <0 0x0ac62000 0 0xf000>,
+ <0 0x0ac71000 0 0xf000>,
+ <0 0x0ac80000 0 0xf000>,
+ <0 0x0accb000 0 0x1800>,
+ <0 0x0accf000 0 0x1800>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_wrapper",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csiphy6",
+ "csiphy7",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_2_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY6_CLK>,
+ <&camcc CAM_CC_CSI6PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY7_CLK>,
+ <&camcc CAM_CC_CSI7PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_2_CLK>,
+ <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+ clock-names = "camnoc_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "cpas_ife_lite",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "csid",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "csiphy6",
+ "csiphy6_timer",
+ "csiphy7",
+ "csiphy7_timer",
+ "csiphy_rx",
+ "gcc_axi_hf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 278 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 602 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 688 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csiphy6",
+ "csiphy7",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_0_mnoc";
+
+ iommus = <&apps_smmu 0x800 0x20>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_IFE_1_GDSC>,
+ <&camcc CAM_CC_IFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy_ep0: endpoint@0 {
+ reg = <0>;
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
new file mode 100644
index 000000000000..9c4b760508b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8550-iris.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm iris video encode and decode accelerators
+
+maintainers:
+ - Vikash Garodia <quic_vgarodia@quicinc.com>
+ - Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
+
+description:
+ The iris video processing unit is a video encode and decode accelerator
+ present on Qualcomm platforms.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sa8775p-iris
+ - qcom,x1e80100-iris
+ - const: qcom,sm8550-iris
+ - enum:
+ - qcom,qcs8300-iris
+ - qcom,sm8550-iris
+ - qcom,sm8650-iris
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 4
+
+ power-domain-names:
+ items:
+ - const: venus
+ - const: vcodec0
+ - const: mxc
+ - const: mmcx
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: iface
+ - const: core
+ - const: vcodec0_core
+
+ firmware-name:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - const: video-mem
+
+ resets:
+ minItems: 1
+ maxItems: 3
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: bus
+ - const: xo
+ - const: core
+
+ iommus:
+ maxItems: 2
+
+ dma-coherent: true
+
+ memory-region:
+ maxItems: 1
+
+ operating-points-v2: true
+
+ opp-table:
+ type: object
+
+required:
+ - compatible
+ - power-domain-names
+ - interconnects
+ - interconnect-names
+ - resets
+ - reset-names
+ - iommus
+ - dma-coherent
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8650-iris
+ then:
+ properties:
+ resets:
+ minItems: 3
+ reset-names:
+ minItems: 3
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/clock/qcom,sm8450-videocc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ video-codec@aa00000 {
+ compatible = "qcom,sm8550-iris";
+ reg = <0x0aa00000 0xf0000>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+ power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
+ <&videocc VIDEO_CC_MVS0_GDSC>,
+ <&rpmhpd RPMHPD_MXC>,
+ <&rpmhpd RPMHPD_MMCX>;
+ power-domain-names = "venus", "vcodec0", "mxc", "mmcx";
+
+ clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
+ <&videocc VIDEO_CC_MVS0C_CLK>,
+ <&videocc VIDEO_CC_MVS0_CLK>;
+ clock-names = "iface", "core", "vcodec0_core";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
+ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_VIDEO QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-cfg", "video-mem";
+
+ memory-region = <&video_mem>;
+
+ resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
+ reset-names = "bus";
+
+ iommus = <&apps_smmu 0x1940 0x0000>,
+ <&apps_smmu 0x1947 0x0000>;
+ dma-coherent;
+
+ operating-points-v2 = <&iris_opp_table>;
+
+ iris_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-338000000 {
+ opp-hz = /bits/ 64 <338000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_svs>;
+ };
+
+ opp-366000000 {
+ opp-hz = /bits/ 64 <366000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>,
+ <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-444000000 {
+ opp-hz = /bits/ 64 <444000000>;
+ required-opps = <&rpmhpd_opp_turbo>,
+ <&rpmhpd_opp_turbo>;
+ };
+
+ opp-533333334 {
+ opp-hz = /bits/ 64 <533333334>;
+ required-opps = <&rpmhpd_opp_turbo_l1>,
+ <&rpmhpd_opp_turbo_l1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml
new file mode 100644
index 000000000000..9c8de722601e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml
@@ -0,0 +1,375 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8650-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8650 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sm8650-camss
+
+ reg:
+ maxItems: 17
+
+ reg-names:
+ items:
+ - const: csid_wrapper
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 33
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: cpas_vfe2
+ - const: cpas_vfe_lite
+ - const: csid
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: csiphy_rx
+ - const: gcc_axi_hf
+ - const: qdss_debug_xo
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 16
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+
+ iommus:
+ maxItems: 3
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-5]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data from a CSIPHY.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+ vdd-csiphy01-0p9-supply:
+ description:
+ Phandle to a 0.9V regulator supply to CSIPHY0 and CSIPHY1 IP blocks.
+
+ vdd-csiphy01-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY0 and CSIPHY1 IP blocks.
+
+ vdd-csiphy24-0p9-supply:
+ description:
+ Phandle to a 0.9V regulator supply to CSIPHY2 and CSIPHY4 IP blocks.
+
+ vdd-csiphy24-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY2 and CSIPHY4 IP blocks.
+
+ vdd-csiphy35-0p9-supply:
+ description:
+ Phandle to a 0.9V regulator supply to CSIPHY3 and CSIPHY5 IP blocks.
+
+ vdd-csiphy35-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY3 and CSIPHY5 IP blocks.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interconnects
+ - interconnect-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - power-domain-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8650-camcc.h>
+ #include <dt-bindings/clock/qcom,sm8650-gcc.h>
+ #include <dt-bindings/interconnect/qcom,sm8650-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@acb6000 {
+ compatible = "qcom,sm8650-camss";
+ reg = <0 0x0acb6000 0 0x1000>,
+ <0 0x0acb8000 0 0x1000>,
+ <0 0x0acba000 0 0x1000>,
+ <0 0x0acbc000 0 0x1000>,
+ <0 0x0accb000 0 0x1000>,
+ <0 0x0acd0000 0 0x1000>,
+ <0 0x0ace4000 0 0x2000>,
+ <0 0x0ace6000 0 0x2000>,
+ <0 0x0ace8000 0 0x2000>,
+ <0 0x0acea000 0 0x2000>,
+ <0 0x0acec000 0 0x2000>,
+ <0 0x0acee000 0 0x2000>,
+ <0 0x0ac62000 0 0xf000>,
+ <0 0x0ac71000 0 0xf000>,
+ <0 0x0ac80000 0 0xf000>,
+ <0 0x0accc000 0 0x2000>,
+ <0 0x0acd1000 0 0x2000>;
+ reg-names = "csid_wrapper",
+ "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_2_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_2_CLK>,
+ <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+ clock-names = "camnoc_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "cpas_vfe_lite",
+ "csid",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "csiphy_rx",
+ "gcc_axi_hf",
+ "qdss_debug_xo",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 602 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 688 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+ interconnects = <&gem_noc MASTER_APPSS_PROC 0
+ &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0
+ &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "ahb", "hf_mnoc";
+ iommus = <&apps_smmu 0x800 0x20>,
+ <&apps_smmu 0x18a0 0x40>,
+ <&apps_smmu 0x1860 0x00>;
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_IFE_1_GDSC>,
+ <&camcc CAM_CC_IFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0", "ife1", "ife2", "top";
+ vdd-csiphy01-0p9-supply = <&vreg_0p9>;
+ vdd-csiphy01-1p2-supply = <&vreg_1p2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csiphy1_ep: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&camera_sensor>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml
new file mode 100644
index 000000000000..c42d3470bdac
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8750-iris.yaml
@@ -0,0 +1,186 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8750-iris.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8750 SoC Iris video encoder and decoder
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ The Iris video processing unit on Qualcomm SM8750 SoC is a video encode and
+ decode accelerator.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8750-iris
+
+ clocks:
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: iface # AXI0
+ - const: core
+ - const: vcodec0_core
+ - const: iface1 # AXI1
+ - const: core_freerun
+ - const: vcodec0_core_freerun
+
+ dma-coherent: true
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - const: video-mem
+
+ iommus:
+ maxItems: 2
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ power-domains:
+ maxItems: 4
+
+ power-domain-names:
+ items:
+ - const: venus
+ - const: vcodec0
+ - const: mxc
+ - const: mmcx
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: bus0
+ - const: bus1
+ - const: core
+ - const: vcodec0_core
+
+required:
+ - compatible
+ - dma-coherent
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domain-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm8750-gcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8750-rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ video-codec@aa00000 {
+ compatible = "qcom,sm8750-iris";
+ reg = <0x0aa00000 0xf0000>;
+
+ clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
+ <&videocc_mvs0c_clk>,
+ <&videocc_mvs0_clk>,
+ <&gcc GCC_VIDEO_AXI1_CLK>,
+ <&videocc_mvs0c_freerun_clk>,
+ <&videocc_mvs0_freerun_clk>;
+ clock-names = "iface",
+ "core",
+ "vcodec0_core",
+ "iface1",
+ "core_freerun",
+ "vcodec0_core_freerun";
+
+ dma-coherent;
+ iommus = <&apps_smmu 0x1940 0>,
+ <&apps_smmu 0x1947 0>;
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_VIDEO_MVP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-cfg",
+ "video-mem";
+
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+ operating-points-v2 = <&iris_opp_table>;
+
+ memory-region = <&video_mem>;
+
+ power-domains = <&videocc_mvs0c_gdsc>,
+ <&videocc_mvs0_gdsc>,
+ <&rpmhpd RPMHPD_MXC>,
+ <&rpmhpd RPMHPD_MMCX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "mxc",
+ "mmcx";
+
+ resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
+ <&gcc GCC_VIDEO_AXI1_CLK_ARES>,
+ <&videocc_mvs0c_freerun_clk_ares>,
+ <&videocc_mvs0_freerun_clk_ares>;
+ reset-names = "bus0",
+ "bus1",
+ "core",
+ "vcodec0_core";
+
+ iris_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-338000000 {
+ opp-hz = /bits/ 64 <338000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-420000000 {
+ opp-hz = /bits/ 64 <420000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_svs>;
+ };
+
+ opp-444000000 {
+ opp-hz = /bits/ 64 <444000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>,
+ <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-533333334 {
+ opp-hz = /bits/ 64 <533333334>;
+ required-opps = <&rpmhpd_opp_nom>,
+ <&rpmhpd_opp_nom>;
+ };
+
+ opp-630000000 {
+ opp-hz = /bits/ 64 <630000000>;
+ required-opps = <&rpmhpd_opp_turbo>,
+ <&rpmhpd_opp_turbo>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
new file mode 100644
index 000000000000..3153d91f9d18
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,venus-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoC Venus Video Encode and Decode Accelerators Common Properties
+
+maintainers:
+ - Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
+ - Vikash Garodia <quic_vgarodia@quicinc.com>
+
+description: |
+ The Venus IP is a video encode and decode accelerator present
+ on Qualcomm platforms
+
+properties:
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 7
+
+ clock-names:
+ minItems: 3
+ maxItems: 7
+
+ firmware-name:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ minItems: 1
+ maxItems: 20
+
+ memory-region:
+ maxItems: 1
+
+ power-domains:
+ minItems: 1
+ maxItems: 4
+
+ power-domain-names:
+ minItems: 1
+ maxItems: 4
+
+ video-firmware:
+ type: object
+ additionalProperties: false
+
+ description: |
+ Firmware subnode is needed when the platform does not
+ have TrustZone.
+
+ properties:
+ iommus:
+ maxItems: 1
+
+ required:
+ - iommus
+
+required:
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - memory-region
+ - power-domains
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
new file mode 100644
index 000000000000..b87a13479a4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml
@@ -0,0 +1,367 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,x1e80100-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,x1e80100-camss
+
+ reg:
+ maxItems: 17
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_wrapper
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy4
+ - const: csitpg0
+ - const: csitpg1
+ - const: csitpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 29
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: cpas_vfe_lite
+ - const: cphy_rx_clk_src
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 13
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy4
+ - const: vfe0
+ - const: vfe1
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+ - const: sf_mnoc
+ - const: sf_icp_mnoc
+
+ iommus:
+ maxItems: 8
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: top
+
+ vdd-csiphy-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to a PHY.
+
+ vdd-csiphy-1p2-supply:
+ description:
+ Phandle to 1.2V regulator supply to a PHY.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-3]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data from a CSIPHY.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdd-csiphy-0p8-supply
+ - vdd-csiphy-1p2-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
+ #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: isp@acb7000 {
+ compatible = "qcom,x1e80100-camss";
+
+ reg = <0 0x0acb7000 0 0x2000>,
+ <0 0x0acb9000 0 0x2000>,
+ <0 0x0acbb000 0 0x2000>,
+ <0 0x0acc6000 0 0x1000>,
+ <0 0x0acca000 0 0x1000>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ace4000 0 0x1000>,
+ <0 0x0ace6000 0 0x1000>,
+ <0 0x0ace8000 0 0x1000>,
+ <0 0x0acec000 0 0x4000>,
+ <0 0x0acf6000 0 0x1000>,
+ <0 0x0acf7000 0 0x1000>,
+ <0 0x0acf8000 0 0x1000>,
+ <0 0x0ac62000 0 0x4000>,
+ <0 0x0ac71000 0 0x4000>,
+ <0 0x0acc7000 0 0x2000>,
+ <0 0x0accb000 0 0x2000>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_wrapper",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy4",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_NRT_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPHY_RX_CLK_SRC>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe_lite",
+ "cphy_rx_clk_src",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy4",
+ "vfe0",
+ "vfe1",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_mnoc",
+ "sf_icp_mnoc";
+
+ iommus = <&apps_smmu 0x800 0x60>,
+ <&apps_smmu 0x860 0x60>,
+ <&apps_smmu 0x1800 0x60>,
+ <&apps_smmu 0x1860 0x60>,
+ <&apps_smmu 0x18e0 0x00>,
+ <&apps_smmu 0x1980 0x20>,
+ <&apps_smmu 0x1900 0x00>,
+ <&apps_smmu 0x19a0 0x20>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_IFE_1_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ power-domain-names = "ife0",
+ "ife1",
+ "top";
+
+ vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
+ vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ csiphy_ep0: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/raspberrypi,pispbe.yaml b/Documentation/devicetree/bindings/media/raspberrypi,pispbe.yaml
new file mode 100644
index 000000000000..1fc62a1d8eda
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/raspberrypi,pispbe.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/raspberrypi,pispbe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi PiSP Image Signal Processor (ISP) Back End
+
+maintainers:
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+ - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
+
+description: |
+ The Raspberry Pi PiSP Image Signal Processor (ISP) Back End is an image
+ processor that fetches images in Bayer or Grayscale format from DRAM memory
+ in tiles and produces images consumable by applications.
+
+ The full ISP documentation is available at
+ https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm2712-pispbe
+ - const: raspberrypi,pispbe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@880000 {
+ compatible = "brcm,bcm2712-pispbe", "raspberrypi,pispbe";
+ reg = <0x10 0x00880000 0x0 0x4000>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&firmware_clocks 7>;
+ iommus = <&iommu2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml b/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml
new file mode 100644
index 000000000000..eba5394719b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/raspberrypi,rp1-cfe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi PiSP Camera Front End
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description: |
+ The Raspberry Pi PiSP Camera Front End is a module in Raspberrypi 5's RP1 I/O
+ controller, that contains:
+ - MIPI D-PHY
+ - MIPI CSI-2 receiver
+ - Simple image processor (called PiSP Front End, or FE)
+
+ The FE documentation is available at:
+ https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
+
+ The PHY and CSI-2 receiver part have no public documentation.
+
+properties:
+ compatible:
+ items:
+ - const: raspberrypi,rp1-cfe
+
+ reg:
+ items:
+ - description: CSI-2 registers
+ - description: D-PHY registers
+ - description: MIPI CFG (a simple top-level mux) registers
+ - description: FE registers
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+ description: CSI-2 RX Port
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ rp1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ csi@110000 {
+ compatible = "raspberrypi,rp1-cfe";
+ reg = <0xc0 0x40110000 0x0 0x100>,
+ <0xc0 0x40114000 0x0 0x100>,
+ <0xc0 0x40120000 0x0 0x100>,
+ <0xc0 0x40124000 0x0 0x1000>;
+
+ interrupts = <42>;
+
+ clocks = <&rp1_clocks>;
+
+ port {
+ csi_ep: endpoint {
+ remote-endpoint = <&cam_endpoint>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml
index b11d14ab89c4..dedc5a4b81ec 100644
--- a/Documentation/devicetree/bindings/media/rc.yaml
+++ b/Documentation/devicetree/bindings/media/rc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/rc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic Infrared Remote Controller Device Tree Bindings
+title: Generic Infrared Remote Controller
maintainers:
- Mauro Carvalho Chehab <mchehab@kernel.org>
@@ -18,7 +18,7 @@ properties:
description:
Specifies the scancode/key mapping table defined in-kernel for
the remote controller.
- $ref: '/schemas/types.yaml#/definitions/string'
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- rc-adstech-dvb-t-pci
- rc-alink-dtu-m
@@ -39,6 +39,7 @@ properties:
- rc-avertv-303
- rc-azurewave-ad-tu700
- rc-beelink-gs1
+ - rc-beelink-mxiii
- rc-behold
- rc-behold-columbus
- rc-budget-ci-old
@@ -55,6 +56,7 @@ properties:
- rc-dm1105-nec
- rc-dntv-live-dvb-t
- rc-dntv-live-dvbt-pro
+ - rc-dreambox
- rc-dtt200u
- rc-dvbsky
- rc-dvico-mce
@@ -101,6 +103,7 @@ properties:
- rc-msi-digivox-iii
- rc-msi-tvanywhere
- rc-msi-tvanywhere-plus
+ - rc-mygica-utv3
- rc-nebula
- rc-nec-terratec-cinergy-xs
- rc-norwood
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.yaml b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
index 50e0740af15a..d527fc42c3fd 100644
--- a/Documentation/devicetree/bindings/media/renesas,ceu.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/renesas,ceu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas Capture Engine Unit (CEU) Bindings
+title: Renesas Capture Engine Unit (CEU)
maintainers:
- Jacopo Mondi <jacopo+renesas@jmondi.org>
diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
index b520d6c5c102..80b77875874d 100644
--- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
@@ -31,6 +31,8 @@ properties:
- renesas,r8a77980-csi2 # R-Car V3H
- renesas,r8a77990-csi2 # R-Car E3
- renesas,r8a779a0-csi2 # R-Car V3U
+ - renesas,r8a779g0-csi2 # R-Car V4H
+ - renesas,r8a779h0-csi2 # R-Car V4M
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
index 43f2fed8cd33..cf92dfe69637 100644
--- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
@@ -21,15 +21,34 @@ description: |
properties:
compatible:
- enum:
- - renesas,fcpv # FCP for VSP
- - renesas,fcpf # FCP for FDP
+ oneOf:
+ - enum:
+ - renesas,fcpv # FCP for VSP
+ - renesas,fcpf # FCP for FDP
+ - items:
+ - enum:
+ - renesas,r9a07g043u-fcpvd # RZ/G2UL
+ - renesas,r9a07g044-fcpvd # RZ/G2{L,LC}
+ - renesas,r9a07g054-fcpvd # RZ/V2L
+ - renesas,r9a09g056-fcpvd # RZ/V2N
+ - renesas,r9a09g057-fcpvd # RZ/V2H(P)
+ - const: renesas,fcpv # Generic FCP for VSP fallback
reg:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Main clock
+ - description: Register access clock
+ - description: Video clock
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: pclk
+ - const: vclk
iommus:
maxItems: 1
@@ -49,6 +68,28 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a07g043u-fcpvd
+ - renesas,r9a07g044-fcpvd
+ - renesas,r9a07g054-fcpvd
+ - renesas,r9a09g057-fcpvd
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ required:
+ - clock-names
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names: false
+
examples:
# R8A7795 (R-Car H3) FCP for VSP-D1
- |
diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml
index 514857d36f6b..d25e020f5e5e 100644
--- a/Documentation/devicetree/bindings/media/renesas,isp.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml
@@ -21,20 +21,59 @@ properties:
items:
- enum:
- renesas,r8a779a0-isp # V3U
+ - renesas,r8a779g0-isp # V4H
+ - renesas,r8a779h0-isp # V4M
+ - const: renesas,rcar-gen4-isp # Generic R-Car Gen4
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: cs
+ - const: core
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: cs
+ - const: core
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: cs
+ - const: core
power-domains:
maxItems: 1
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: cs
+ - const: core
+
+ renesas,vspx:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to the companion VSPX responsible for the Streaming Bridge
+ functionality. The Streaming Bridge is responsible for feeding image
+ and configuration data to the ISP when operating in memory-to-memory
+ mode.
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -100,10 +139,14 @@ properties:
required:
- compatible
- reg
+ - reg-names
- interrupts
+ - interrupt-names
- clocks
+ - clock-names
- power-domains
- resets
+ - reset-names
- ports
additionalProperties: false
@@ -115,12 +158,19 @@ examples:
#include <dt-bindings/power/r8a779a0-sysc.h>
isp1: isp@fed20000 {
- compatible = "renesas,r8a779a0-isp";
- reg = <0xfed20000 0x10000>;
- interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 613>;
+ compatible = "renesas,r8a779a0-isp", "renesas,rcar-gen4-isp";
+ reg = <0xfed20000 0x10000>, <0xfee00000 0x100000>;
+ reg-names = "cs", "core";
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "cs", "core";
+ clocks = <&cpg CPG_MOD 613>, <&cpg CPG_MOD 17>;
+ clock-names = "cs", "core";
power-domains = <&sysc R8A779A0_PD_A3ISP01>;
- resets = <&cpg 613>;
+ resets = <&cpg 613>, <&cpg 17>;
+ reset-names = "cs", "core";
+
+ renesas,vspx = <&vspx1>;
ports {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml b/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml
new file mode 100644
index 000000000000..c09cbd8c9e35
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/renesas,r9a09g057-ivc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2H(P) Input Video Control Block
+
+maintainers:
+ - Daniel Scally <dan.scally@ideasonboard.com>
+
+description:
+ The IVC block is a module that takes video frames from memory and feeds them
+ to the Image Signal Processor for processing.
+
+properties:
+ compatible:
+ const: renesas,r9a09g057-ivc # RZ/V2H(P)
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Input Video Control block register access clock
+ - description: Video input data AXI bus clock
+ - description: ISP system clock
+
+ clock-names:
+ items:
+ - const: reg
+ - const: axi
+ - const: isp
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: Input Video Control block register access reset
+ - description: Video input data AXI bus reset
+ - description: ISP core reset
+
+ reset-names:
+ items:
+ - const: reg
+ - const: axi
+ - const: isp
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output parallel video bus
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g057-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ isp-input@16040000 {
+ compatible = "renesas,r9a09g057-ivc";
+ reg = <0x16040000 0x230>;
+
+ clocks = <&cpg CPG_MOD 0xe3>,
+ <&cpg CPG_MOD 0xe4>,
+ <&cpg CPG_MOD 0xe5>;
+ clock-names = "reg", "axi", "isp";
+
+ power-domains = <&cpg>;
+
+ resets = <&cpg 0xd4>,
+ <&cpg 0xd1>,
+ <&cpg 0xd3>;
+ reset-names = "reg", "axi", "isp";
+
+ interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>;
+
+ port {
+ ivc_out: endpoint {
+ remote-endpoint = <&isp_in>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml
new file mode 100644
index 000000000000..47e18690fa57
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,rzg2l-cru.yaml
@@ -0,0 +1,227 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2022 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/renesas,rzg2l-cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L (and alike SoC's) Camera Data Receiving Unit (CRU) Image processing
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ The CRU image processing module is a data conversion module equipped with pixel
+ color space conversion, LUT, pixel format conversion, etc. An MIPI CSI-2 input and
+ parallel (including ITU-R BT.656) input are provided as the image sensor interface.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043-cru # RZ/G2UL
+ - renesas,r9a07g044-cru # RZ/G2{L,LC}
+ - renesas,r9a07g054-cru # RZ/V2L
+ - const: renesas,rzg2l-cru
+ - const: renesas,r9a09g047-cru # RZ/G3E
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ oneOf:
+ - items:
+ - description: CRU Interrupt for image_conv
+ - description: CRU Interrupt for image_conv_err
+ - description: CRU AXI master error interrupt
+ - items:
+ - description: CRU Interrupt for image_conv
+ - description: CRU AXI master error interrupt
+ - description: CRU Video Data AXI Master Address 0 Write End interrupt
+ - description: CRU Statistics data AXI master addr 0 write end interrupt
+ - description: CRU Video statistics data AXI master addr 0 write end interrupt
+
+ interrupt-names:
+ oneOf:
+ - items:
+ - const: image_conv
+ - const: image_conv_err
+ - const: axi_mst_err
+ - items:
+ - const: image_conv
+ - const: axi_mst_err
+ - const: vd_addr_wend
+ - const: sd_addr_wend
+ - const: vsd_addr_wend
+
+ clocks:
+ items:
+ - description: CRU Main clock
+ - description: CRU Register access clock
+ - description: CRU image transfer clock
+
+ clock-names:
+ items:
+ - const: video
+ - const: apb
+ - const: axi
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: CRU_PRESETN reset terminal
+ - description: CRU_ARESETN reset terminal
+
+ reset-names:
+ items:
+ - const: presetn
+ - const: aresetn
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port node, single endpoint describing a parallel input source.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ hsync-active: true
+ vsync-active: true
+ bus-width: true
+ data-shift: true
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Input port node, describing the Image Processing module connected to the
+ CSI-2 receiver.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a07g044-cru
+ - renesas,r9a07g054-cru
+ then:
+ properties:
+ interrupts:
+ maxItems: 3
+ interrupt-names:
+ maxItems: 3
+ ports:
+ required:
+ - port@0
+ - port@1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a07g043-cru
+ then:
+ properties:
+ interrupts:
+ maxItems: 3
+ interrupt-names:
+ maxItems: 3
+ ports:
+ properties:
+ port@0: false
+ required:
+ - port@1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g047-cru
+ then:
+ properties:
+ interrupts:
+ minItems: 5
+ interrupt-names:
+ minItems: 5
+ ports:
+ properties:
+ port@0: false
+ required:
+ - port@1
+
+additionalProperties: false
+
+examples:
+ # Device node example with CSI-2
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ cru: video@10830000 {
+ compatible = "renesas,r9a07g044-cru", "renesas,rzg2l-cru";
+ reg = <0x10830000 0x400>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "image_conv", "image_conv_err", "axi_mst_err";
+ clocks = <&cpg CPG_MOD R9A07G044_CRU_VCLK>,
+ <&cpg CPG_MOD R9A07G044_CRU_PCLK>,
+ <&cpg CPG_MOD R9A07G044_CRU_ACLK>;
+ clock-names = "video", "apb", "axi";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_CRU_PRESETN>,
+ <&cpg R9A07G044_CRU_ARESETN>;
+ reset-names = "presetn", "aresetn";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ cru_parallel_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ov5642>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ cru_csi_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&csi_cru_in>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/renesas,rzg2l-csi2.yaml b/Documentation/devicetree/bindings/media/renesas,rzg2l-csi2.yaml
new file mode 100644
index 000000000000..c5c511c9f0db
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,rzg2l-csi2.yaml
@@ -0,0 +1,182 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2022 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/renesas,rzg2l-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L (and alike SoC's) MIPI CSI-2 receiver
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ The CSI-2 receiver device provides MIPI CSI-2 capabilities for the Renesas RZ/G2L
+ (and alike SoCs). MIPI CSI-2 is part of the CRU block which is used in conjunction
+ with the Image Processing module, which provides the video capture capabilities.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043-csi2 # RZ/G2UL
+ - renesas,r9a07g044-csi2 # RZ/G2{L,LC}
+ - renesas,r9a07g054-csi2 # RZ/V2L
+ - const: renesas,rzg2l-csi2
+ - items:
+ - const: renesas,r9a09g047-csi2 # RZ/G3E
+ - const: renesas,r9a09g057-csi2
+ - const: renesas,r9a09g057-csi2 # RZ/V2H(P)
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ oneOf:
+ - items:
+ - description: Internal clock for connecting CRU and MIPI
+ - description: CRU Main clock
+ - description: CRU Register access clock
+ - items:
+ - description: CRU Main clock
+ - description: CRU Register access clock
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: system
+ - const: video
+ - const: apb
+ - items:
+ - const: video
+ - const: apb
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: CRU_PRESETN reset terminal
+ - description: D-PHY reset (CRU_CMN_RSTB or CRU_n_S_RESETN)
+
+ reset-names:
+ items:
+ - const: presetn
+ - const: cmn-rstb
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port node, single endpoint describing the CSI-2 transmitter.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port node, Image Processing block connected to the CSI-2 receiver.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+ - ports
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g057-csi2
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+ else:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ csi: csi@10830400 {
+ compatible = "renesas,r9a07g044-csi2", "renesas,rzg2l-csi2";
+ reg = <0x10830400 0xfc00>;
+ interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A07G044_CRU_SYSCLK>,
+ <&cpg CPG_MOD R9A07G044_CRU_VCLK>,
+ <&cpg CPG_MOD R9A07G044_CRU_PCLK>;
+ clock-names = "system", "video", "apb";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_CRU_PRESETN>,
+ <&cpg R9A07G044_CRU_CMN_RSTB>;
+ reset-names = "presetn", "cmn-rstb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csi2_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&ov5645_ep>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ csi2cru: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&crucsi2>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml
index c0442e79cbb4..cf54176f4fbd 100644
--- a/Documentation/devicetree/bindings/media/renesas,vin.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
@@ -52,7 +52,12 @@ properties:
- renesas,vin-r8a77980 # R-Car V3H
- renesas,vin-r8a77990 # R-Car E3
- renesas,vin-r8a77995 # R-Car D3
+ - items:
+ - enum:
- renesas,vin-r8a779a0 # R-Car V3U
+ - renesas,vin-r8a779g0 # R-Car V4H
+ - renesas,vin-r8a779h0 # R-Car V4M
+ - const: renesas,rcar-gen4-vin # Generic R-Car Gen4
reg:
maxItems: 1
@@ -69,7 +74,7 @@ properties:
resets:
maxItems: 1
- #The per-board settings for Gen2 and RZ/G1 platforms:
+ # The per-board settings for Gen2 and RZ/G1 platforms:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
@@ -94,7 +99,7 @@ properties:
synchronization is selected.
default: 1
- field-active-even: true
+ field-even-active: true
bus-width: true
@@ -108,7 +113,7 @@ properties:
data-active: true
- #The per-board settings for Gen3 and RZ/G2 platforms:
+ # The per-board settings for Gen3 and RZ/G2 platforms:
renesas,id:
description: VIN channel number
$ref: /schemas/types.yaml#/definitions/uint32
@@ -143,7 +148,7 @@ properties:
synchronization is selected.
default: 1
- field-active-even: true
+ field-even-active: true
bus-width: true
@@ -302,11 +307,11 @@ examples:
vin0csi20: endpoint@0 {
reg = <0>;
- remote-endpoint= <&csi20vin0>;
+ remote-endpoint = <&csi20vin0>;
};
vin0csi40: endpoint@2 {
reg = <2>;
- remote-endpoint= <&csi40vin0>;
+ remote-endpoint = <&csi40vin0>;
};
};
};
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
index 7a8f32473852..07a97dd87a5b 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
@@ -16,10 +16,18 @@ description:
properties:
compatible:
- enum:
- - renesas,r9a07g044-vsp2 # RZ/G2L
- - renesas,vsp1 # R-Car Gen2 and RZ/G1
- - renesas,vsp2 # R-Car Gen3 and RZ/G2
+ oneOf:
+ - enum:
+ - renesas,r9a07g044-vsp2 # RZ/G2L
+ - renesas,vsp1 # R-Car Gen2 and RZ/G1
+ - renesas,vsp2 # R-Car Gen3 and RZ/G2
+ - items:
+ - enum:
+ - renesas,r9a07g043u-vsp2 # RZ/G2UL
+ - renesas,r9a07g054-vsp2 # RZ/V2L
+ - renesas,r9a09g056-vsp2 # RZ/V2N
+ - renesas,r9a09g057-vsp2 # RZ/V2H(P)
+ - const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
reg:
maxItems: 1
@@ -27,8 +35,18 @@ properties:
interrupts:
maxItems: 1
- clocks: true
- clock-names: true
+ clocks:
+ minItems: 1
+ items:
+ - description: Main clock
+ - description: Register access clock
+ - description: Video clock
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: pclk
+ - const: vclk
power-domains:
maxItems: 1
@@ -72,15 +90,7 @@ allOf:
then:
properties:
clocks:
- items:
- - description: Main clock
- - description: Register access clock
- - description: Video clock
- clock-names:
- items:
- - const: aclk
- - const: pclk
- - const: vclk
+ minItems: 3
required:
- clock-names
else:
diff --git a/Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml b/Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml
new file mode 100644
index 000000000000..cc08ce94bef7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip,px30-vip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PX30 Video Input Processor (VIP)
+
+maintainers:
+ - Mehdi Djait <mehdi.djait@linux.intel.com>
+ - Michael Riesch <michael.riesch@collabora.com>
+
+description:
+ The Rockchip PX30 Video Input Processor (VIP) receives the data from a camera
+ sensor or CCIR656 encoder and transfers it into system main memory by AXI bus.
+
+properties:
+ compatible:
+ const: rockchip,px30-vip
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ACLK
+ - description: HCLK
+ - description: PCLK
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: hclk
+ - const: pclk
+
+ resets:
+ items:
+ - description: AXI
+ - description: AHB
+ - description: PCLK IN
+
+ reset-names:
+ items:
+ - const: axi
+ - const: ahb
+ - const: pclkin
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: input port on the parallel interface
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ enum:
+ - 5 # MEDIA_BUS_TYPE_PARALLEL
+ - 6 # MEDIA_BUS_TYPE_BT656
+
+ required:
+ - bus-type
+
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/px30-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/power/px30-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ video-capture@ff490000 {
+ compatible = "rockchip,px30-vip";
+ reg = <0x0 0xff490000 0x0 0x200>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_CIF>, <&cru HCLK_CIF>, <&cru PCLK_CIF>;
+ clock-names = "aclk", "hclk", "pclk";
+ power-domains = <&power PX30_PD_VI>;
+ resets = <&cru SRST_CIF_A>, <&cru SRST_CIF_H>, <&cru SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ cif_in: endpoint {
+ remote-endpoint = <&tw9900_out>;
+ bus-type = <MEDIA_BUS_TYPE_BT656>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
index 81b26eb4cd35..d246f5d38427 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hantro G1 VPU encoders implemented on Rockchip SoCs
@@ -17,6 +16,7 @@ properties:
compatible:
enum:
- rockchip,rk3568-vepu
+ - rockchip,rk3588-vepu121
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
new file mode 100644
index 000000000000..18cd0a5a5318
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip,rk3568-vicap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3568 Video Capture (VICAP)
+
+maintainers:
+ - Michael Riesch <michael.riesch@collabora.com>
+
+description:
+ The Rockchip RK3568 Video Capture (VICAP) block features a digital video
+ port (DVP, a parallel video interface) and a MIPI CSI-2 port. It receives
+ the data from camera sensors, video decoders, or other companion ICs and
+ transfers it into system main memory by AXI bus.
+
+properties:
+ compatible:
+ const: rockchip,rk3568-vicap
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ACLK
+ - description: HCLK
+ - description: DCLK
+ - description: ICLK
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: hclk
+ - const: dclk
+ - const: iclk
+
+ iommus:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: ARST
+ - description: HRST
+ - description: DRST
+ - description: PRST
+ - description: IRST
+
+ reset-names:
+ items:
+ - const: arst
+ - const: hrst
+ - const: drst
+ - const: prst
+ - const: irst
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to general register file used for video input block control.
+
+ power-domains:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: The digital video port (DVP, a parallel video interface).
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ enum:
+ - 5 # MEDIA_BUS_TYPE_PARALLEL
+ - 6 # MEDIA_BUS_TYPE_BT656
+
+ rockchip,dvp-clk-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ minimum: 0
+ maximum: 127
+ description:
+ Delay the DVP path clock input to align the sampling phase,
+ only valid in dual edge sampling mode. Delay is zero by
+ default and can be adjusted optionally.
+
+ required:
+ - bus-type
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the MIPI CSI-2 receiver output.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3568-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/rk3568-power.h>
+ #include <dt-bindings/media/video-interfaces.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ vicap: video-capture@fdfe0000 {
+ compatible = "rockchip,rk3568-vicap";
+ reg = <0x0 0xfdfe0000 0x0 0x200>;
+ interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ assigned-clocks = <&cru DCLK_VICAP>;
+ assigned-clock-rates = <300000000>;
+ clocks = <&cru ACLK_VICAP>, <&cru HCLK_VICAP>,
+ <&cru DCLK_VICAP>, <&cru ICLK_VICAP_G>;
+ clock-names = "aclk", "hclk", "dclk", "iclk";
+ iommus = <&vicap_mmu>;
+ power-domains = <&power RK3568_PD_VI>;
+ resets = <&cru SRST_A_VICAP>, <&cru SRST_H_VICAP>,
+ <&cru SRST_D_VICAP>, <&cru SRST_P_VICAP>,
+ <&cru SRST_I_VICAP>;
+ reset-names = "arst", "hrst", "drst", "prst", "irst";
+ rockchip,grf = <&grf>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vicap_dvp: port@0 {
+ reg = <0>;
+
+ vicap_dvp_input: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_BT656>;
+ bus-width = <16>;
+ pclk-sample = <MEDIA_PCLK_SAMPLE_DUAL_EDGE>;
+ remote-endpoint = <&it6801_output>;
+ };
+ };
+
+ vicap_mipi: port@1 {
+ reg = <1>;
+
+ vicap_mipi_input: endpoint {
+ remote-endpoint = <&csi_output>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
index 3bcfb8e12333..809fda45b3bd 100644
--- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml
@@ -4,19 +4,22 @@
$id: http://devicetree.org/schemas/media/rockchip,vdec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip Video Decoder (VDec) Device Tree Bindings
+title: Rockchip Video Decoder (VDec)
maintainers:
- Heiko Stuebner <heiko@sntech.de>
description: |-
- The Rockchip rk3399 has a stateless Video Decoder that can decodes H.264,
- HEVC an VP9 streams.
+ Rockchip SoCs have variants of the same stateless Video Decoder that can
+ decodes H.264, HEVC, VP9 and AV1 streams, depending on the variant.
properties:
compatible:
oneOf:
+ - const: rockchip,rk3288-vdec
- const: rockchip,rk3399-vdec
+ - const: rockchip,rk3576-vdec
+ - const: rockchip,rk3588-vdec
- items:
- enum:
- rockchip,rk3228-vdec
@@ -24,35 +27,72 @@ properties:
- const: rockchip,rk3399-vdec
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: The function configuration registers base
+ - description: The link table configuration registers base
+ - description: The cache configuration registers base
+
+ reg-names:
+ items:
+ - const: function
+ - const: link
+ - const: cache
interrupts:
maxItems: 1
clocks:
+ minItems: 4
items:
- description: The Video Decoder AXI interface clock
- description: The Video Decoder AHB interface clock
- description: The Video Decoded CABAC clock
- description: The Video Decoder core clock
+ - description: The Video decoder HEVC CABAC clock
clock-names:
+ minItems: 4
items:
- const: axi
- const: ahb
- const: cabac
- const: core
+ - const: hevc_cabac
assigned-clocks: true
assigned-clock-rates: true
+ resets:
+ items:
+ - description: The Video Decoder AXI interface reset
+ - description: The Video Decoder AHB interface reset
+ - description: The Video Decoded CABAC reset
+ - description: The Video Decoder core reset
+ - description: The Video decoder HEVC CABAC reset
+
+ reset-names:
+ items:
+ - const: axi
+ - const: ahb
+ - const: cabac
+ - const: core
+ - const: hevc_cabac
+
power-domains:
maxItems: 1
iommus:
maxItems: 1
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ phandle to a reserved on-chip SRAM regions.
+ Some SoCs, like rk3588 provide on-chip SRAM to store temporary
+ buffers during decoding.
+
required:
- compatible
- reg
@@ -61,6 +101,41 @@ required:
- clock-names
- power-domains
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-vdec
+ - rockchip,rk3588-vdec
+ then:
+ properties:
+ reg:
+ minItems: 3
+ reg-names:
+ minItems: 3
+ clocks:
+ minItems: 5
+ clock-names:
+ minItems: 5
+ resets:
+ minItems: 5
+ reset-names:
+ minItems: 5
+ else:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names: false
+ clocks:
+ maxItems: 4
+ clock-names:
+ maxItems: 4
+ resets: false
+ reset-names: false
+ sram: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
index b3661d7d4357..477c21417e75 100644
--- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
@@ -16,6 +16,7 @@ description: |
properties:
compatible:
enum:
+ - fsl,imx8mp-isp
- rockchip,px30-cif-isp
- rockchip,rk3399-cif-isp
@@ -36,9 +37,9 @@ properties:
minItems: 3
items:
# isp0 and isp1
- - description: ISP clock
- - description: ISP AXI clock
- - description: ISP AHB clock
+ - description: ISP clock (for imx8mp, clk)
+ - description: ISP AXI clock (for imx8mp, m_hclk)
+ - description: ISP AHB clock (for imx8mp, hclk)
# only for isp1
- description: ISP Pixel clock
@@ -52,6 +53,13 @@ properties:
# only for isp1
- const: pclk
+ fsl,blk-ctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+ description:
+ A phandle to the media block control for the ISP, followed by a cell
+ containing the index of the gasket.
+
iommus:
maxItems: 1
@@ -63,7 +71,16 @@ properties:
const: dphy
power-domains:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: ISP power domain
+ - description: MIPI CSI-2 power domain
+
+ power-domain-names:
+ minItems: 1
+ items:
+ - const: isp
+ - const: csi2
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -90,15 +107,16 @@ properties:
description: connection point for input on the parallel interface
properties:
- bus-type:
- enum: [5, 6]
-
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
- required:
- - bus-type
+ properties:
+ bus-type:
+ enum: [5, 6]
+
+ required:
+ - bus-type
anyOf:
- required:
@@ -112,9 +130,6 @@ required:
- interrupts
- clocks
- clock-names
- - iommus
- - phys
- - phy-names
- power-domains
- ports
@@ -142,6 +157,38 @@ allOf:
required:
- interrupt-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8mp-isp
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+ iommus: false
+ phys: false
+ phy-names: false
+ power-domains:
+ minItems: 2
+ power-domain-names:
+ minItems: 2
+ required:
+ - fsl,blk-ctrl
+ - power-domain-names
+ else:
+ properties:
+ fsl,blk-ctrl: false
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
+ required:
+ - iommus
+ - phys
+ - phy-names
+
additionalProperties: false
examples:
@@ -199,6 +246,7 @@ examples:
wcam: camera@36 {
compatible = "ovti,ov5695";
reg = <0x36>;
+ clocks = <&cru SCLK_TESTCLKOUT1>;
port {
wcam_out: endpoint {
@@ -212,12 +260,19 @@ examples:
compatible = "ovti,ov2685";
reg = <0x3c>;
- port {
- ucam_out: endpoint {
- remote-endpoint = <&mipi_in_ucam>;
- data-lanes = <1>;
- };
- };
+ clocks = <&cru SCLK_TESTCLKOUT1>;
+ clock-names = "xvclk";
+
+ avdd-supply = <&pp2800_cam>;
+ dovdd-supply = <&pp1800>;
+ dvdd-supply = <&pp1800>;
+
+ port {
+ ucam_out: endpoint {
+ remote-endpoint = <&mipi_in_ucam>;
+ data-lanes = <1>;
+ };
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.yaml b/Documentation/devicetree/bindings/media/rockchip-rga.yaml
index dd645ddccb07..ac17cda65191 100644
--- a/Documentation/devicetree/bindings/media/rockchip-rga.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.yaml
@@ -21,7 +21,10 @@ properties:
- const: rockchip,rk3288-rga
- const: rockchip,rk3399-rga
- items:
- - const: rockchip,rk3228-rga
+ - enum:
+ - rockchip,rk3228-rga
+ - rockchip,rk3568-rga
+ - rockchip,rk3588-rga
- const: rockchip,rk3288-rga
reg:
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
index 6cc4d3e5a61d..8c2501634080 100644
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/media/rockchip-vpu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/media/rockchip-vpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hantro G1 VPU codecs implemented on Rockchip SoCs
@@ -24,12 +23,18 @@ properties:
- rockchip,rk3399-vpu
- rockchip,px30-vpu
- rockchip,rk3568-vpu
+ - rockchip,rk3588-av1-vpu
- items:
- - const: rockchip,rk3188-vpu
+ - enum:
+ - rockchip,rk3128-vpu
+ - rockchip,rk3188-vpu
- const: rockchip,rk3066-vpu
- items:
- const: rockchip,rk3228-vpu
- const: rockchip,rk3399-vpu
+ - items:
+ - const: rockchip,rk3588-vpu121
+ - const: rockchip,rk3568-vpu
reg:
maxItems: 1
@@ -67,6 +72,13 @@ properties:
iommus:
maxItems: 1
+ resets:
+ items:
+ - description: AXI reset line
+ - description: AXI bus interface unit reset line
+ - description: APB reset line
+ - description: APB bus interface unit reset line
+
required:
- compatible
- reg
@@ -79,18 +91,18 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/rk3288-cru.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/power/rk3288-power.h>
-
- vpu: video-codec@ff9a0000 {
- compatible = "rockchip,rk3288-vpu";
- reg = <0xff9a0000 0x800>;
- interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "vepu", "vdpu";
- clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
- clock-names = "aclk", "hclk";
- power-domains = <&power RK3288_PD_VIDEO>;
- iommus = <&vpu_mmu>;
- };
+ #include <dt-bindings/clock/rk3288-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/rk3288-power.h>
+
+ video-codec@ff9a0000 {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0xff9a0000 0x800>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vepu", "vdpu";
+ clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = <&power RK3288_PD_VIDEO>;
+ iommus = <&vpu_mmu>;
+ };
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt b/Documentation/devicetree/bindings/media/s5p-cec.txt
deleted file mode 100644
index e847291d4aff..000000000000
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Samsung HDMI CEC driver
-
-The HDMI CEC module is present is Samsung SoCs and its purpose is to
-handle communication between HDMI connected devices over the CEC bus.
-
-Required properties:
- - compatible : value should be following
- "samsung,s5p-cec"
-
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
-
- - interrupts : HDMI CEC interrupt number to the CPU.
- - clocks : from common clock binding: handle to HDMI CEC clock.
- - clock-names : from common clock binding: must contain "hdmicec",
- corresponding to entry in the clocks property.
- - samsung,syscon-phandle - phandle to the PMU system controller
- - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
-
-Optional:
- - needs-hpd : if present the CEC support is only available when the HPD
- is high. See cec.txt for more details.
-
-Example:
-
-hdmicec: cec@100b0000 {
- compatible = "samsung,s5p-cec";
- reg = <0x100B0000 0x200>;
- interrupts = <0 114 0>;
- clocks = <&clock CLK_HDMI_CEC>;
- clock-names = "hdmicec";
- samsung,syscon-phandle = <&pmu_system_controller>;
- hdmi-phandle = <&hdmi>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_cec>;
-};
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
deleted file mode 100644
index aa54c8159d9f..000000000000
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-* Samsung Multi Format Codec (MFC)
-
-Multi Format Codec (MFC) is the IP present in Samsung SoCs which
-supports high resolution decoding and encoding functionalities.
-The MFC device driver is a v4l2 driver which can encode/decode
-video raw/elementary streams and has support for all popular
-video codecs.
-
-Required properties:
- - compatible : value should be either one among the following
- (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
- (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
- (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
- (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
- (e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
- (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
-
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
-
- - interrupts : MFC interrupt number to the CPU.
- - clocks : from common clock binding: handle to mfc clock.
- - clock-names : from common clock binding: must contain "mfc",
- corresponding to entry in the clocks property.
-
-Optional properties:
- - power-domains : power-domain property defined with a phandle
- to respective power domain.
- - memory-region : from reserved memory binding: phandles to two reserved
- memory regions, first is for "left" mfc memory bus interfaces,
- second if for the "right" mfc memory bus, used when no SYSMMU
- support is available; used only by MFC v5 present in Exynos4 SoCs
-
-Obsolete properties:
- - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
- property instead
-
-
-Example:
-SoC specific DT entry:
-
-mfc: codec@13400000 {
- compatible = "samsung,mfc-v5";
- reg = <0x13400000 0x10000>;
- interrupts = <0 94 0>;
- power-domains = <&pd_mfc>;
- clocks = <&clock 273>;
- clock-names = "mfc";
-};
-
-Reserved memory specific DT entry for given board (see reserved memory binding
-for more information):
-
-reserved-memory {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- mfc_left: region@51000000 {
- compatible = "shared-dma-pool";
- no-map;
- reg = <0x51000000 0x800000>;
- };
-
- mfc_right: region@43000000 {
- compatible = "shared-dma-pool";
- no-map;
- reg = <0x43000000 0x800000>;
- };
-};
-
-Board specific DT entry:
-
-codec@13400000 {
- memory-region = <&mfc_left>, <&mfc_right>;
-};
diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml
new file mode 100644
index 000000000000..2ddca4167b0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,exynos4210-csis.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+properties:
+ compatible:
+ enum:
+ - samsung,s5pv210-csis
+ - samsung,exynos4210-csis
+ - samsung,exynos4212-csis
+ - samsung,exynos5250-csis
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [2, 4]
+ description:
+ Number of data lines supported.
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: csis
+ - const: sclk_csis
+
+ clock-frequency:
+ default: 166000000
+ description:
+ The IP's main (system bus) clock frequency in Hz.
+
+ interrupts:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: csis
+
+ power-domains:
+ maxItems: 1
+
+ vddio-supply:
+ description: MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V).
+
+ vddcore-supply:
+ description: MIPI CSIS Core voltage supply (e.g. 1.1V).
+
+patternProperties:
+ "^port@[34]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+ description:
+ Camera input port.
+
+ properties:
+ reg:
+ enum: [3, 4]
+
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ samsung,csis-hs-settle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Differential receiver (HS-RX) settle time.
+
+ samsung,csis-wclk:
+ type: boolean
+ description:
+ CSI-2 wrapper clock selection. If this property is present external clock
+ from CMU will be used, or the bus clock if it's not specified.
+
+ required:
+ - data-lanes
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - bus-width
+ - clocks
+ - clock-names
+ - interrupts
+ - vddio-supply
+ - vddcore-supply
+
+anyOf:
+ - required:
+ - port@3
+ - required:
+ - port@4
+
+allOf:
+ - if:
+ required:
+ - samsung,isp-wb
+ then:
+ required:
+ - samsung,sysreg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ csis@11890000 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x11890000 0x4000>;
+ clocks = <&clock CLK_CSIS1>,
+ <&clock CLK_SCLK_CSIS1>;
+ clock-names = "csis", "sclk_csis";
+ assigned-clocks = <&clock CLK_MOUT_CSIS1>,
+ <&clock CLK_SCLK_CSIS1>;
+ assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
+ assigned-clock-rates = <0>, <176000000>;
+
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-width = <2>;
+ power-domains = <&pd_cam>;
+ phys = <&mipi_phy 2>;
+ phy-names = "csis";
+
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Camera D (4) MIPI CSI-2 (CSIS1) */
+ port@4 {
+ reg = <4>;
+
+ endpoint {
+ remote-endpoint = <&is_s5k6a3_ep>;
+ data-lanes = <1>;
+ samsung,csis-hs-settle = <18>;
+ samsung,csis-wclk;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml
new file mode 100644
index 000000000000..17ece4eb300c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,exynos4210-fimc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5P/Exynos SoC Fully Integrated Mobile Camera
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+description:
+ Each FIMC device should have an alias in the aliases node, in the form of
+ fimc<n>, where <n> is an integer specifying the IP block instance.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos4210-fimc
+ - samsung,exynos4212-fimc
+ - samsung,s5pv210-fimc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: fimc
+ - const: sclk_fimc
+
+ clock-frequency:
+ description:
+ Maximum FIMC local clock (LCLK) frequency.
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ samsung,cam-if:
+ type: boolean
+ description:
+ The FIMC IP block includes the camera input interface.
+
+ samsung,isp-wb:
+ type: boolean
+ description: |
+ The FIMC IP block has the ISP writeback input.
+
+ samsung,lcd-wb:
+ type: boolean
+ description: |
+ The FIMC IP block has the LCD writeback input.
+
+ samsung,mainscaler-ext:
+ type: boolean
+ description:
+ FIMC IP supports extended image size and has CIEXTEN register.
+
+ samsung,min-pix-alignment:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: Minimum supported image height alignment.
+ - description: Horizontal image offset.
+ description:
+ The values are in pixels and default is <2 1>.
+
+ samsung,min-pix-sizes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ description: |
+ An array specifying minimum image size in pixels at the FIMC input and
+ output DMA, in the first and second cell respectively. Default value
+ is <16 16>.
+
+ samsung,pix-limits:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 4
+ description: |
+ An array of maximum supported image sizes in pixels, for details refer to
+ Table 2-1 in the S5PV210 SoC User Manual. The meaning of each cell is as
+ follows:
+ 0 - scaler input horizontal size
+ 1 - input horizontal size for the scaler bypassed
+ 2 - REAL_WIDTH without input rotation
+ 3 - REAL_HEIGHT with input rotation
+
+ samsung,rotators:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x11
+ description: |
+ A bitmask specifying whether this IP has the input and the output
+ rotator. Bits 4 and 0 correspond to input and output rotator
+ respectively. If a rotator is present its corresponding bit should be
+ set.
+
+ samsung,sysreg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ System Registers (SYSREG) node.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - samsung,pix-limits
+
+allOf:
+ - if:
+ required:
+ - samsung,isp-wb
+ then:
+ required:
+ - samsung,sysreg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ fimc@11800000 {
+ compatible = "samsung,exynos4212-fimc";
+ reg = <0x11800000 0x1000>;
+ clocks = <&clock CLK_FIMC0>,
+ <&clock CLK_SCLK_FIMC0>;
+ clock-names = "fimc", "sclk_fimc";
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ iommus = <&sysmmu_fimc0>;
+ power-domains = <&pd_cam>;
+ samsung,sysreg = <&sys_reg>;
+
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,isp-wb;
+ samsung,cam-if;
+
+ assigned-clocks = <&clock CLK_MOUT_FIMC0>,
+ <&clock CLK_SCLK_FIMC0>;
+ assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
+ assigned-clock-rates = <0>, <176000000>;
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml
new file mode 100644
index 000000000000..c8894358c46c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml
@@ -0,0 +1,225 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,exynos4212-fimc-is.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos4212/4412 SoC Imaging Subsystem (FIMC-IS)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+description:
+ The FIMC-IS is a subsystem for processing image signal from an image sensor.
+ The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5
+ processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C
+ and SPI bus controllers, PWM and ADC.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos4212-fimc-is
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ clocks:
+ maxItems: 21
+
+ clock-names:
+ items:
+ - const: lite0
+ - const: lite1
+ - const: ppmuispx
+ - const: ppmuispmx
+ - const: isp
+ - const: drc
+ - const: fd
+ - const: mcuisp
+ - const: gicisp
+ - const: mcuctl_isp
+ - const: pwm_isp
+ - const: ispdiv0
+ - const: ispdiv1
+ - const: mcuispdiv0
+ - const: mcuispdiv1
+ - const: mpll
+ - const: aclk200
+ - const: aclk400mcuisp
+ - const: div_aclk200
+ - const: div_aclk400mcuisp
+ - const: uart
+
+ interrupts:
+ maxItems: 2
+
+ iommus:
+ maxItems: 4
+
+ iommu-names:
+ items:
+ - const: isp
+ - const: drc
+ - const: fd
+ - const: mcuctl
+
+ power-domains:
+ maxItems: 1
+
+ samsung,pmu-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Power Management Unit (PMU) system controller interface, used to
+ power/start the ISP.
+
+patternProperties:
+ "^pmu@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+ deprecated: true
+ description:
+ Node representing the SoC's Power Management Unit (duplicated with the
+ correct PMU node in the SoC). Deprecated, use samsung,pmu-syscon.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ "^i2c-isp@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+ description:
+ ISP I2C bus controller
+
+ properties:
+ compatible:
+ const: samsung,exynos4212-i2c-isp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: i2c_isp
+
+ pinctrl-0: true
+ pinctrl-names:
+ items:
+ - const: default
+
+ required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - clocks
+ - clock-names
+ - interrupts
+ - ranges
+ - samsung,pmu-syscon
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ fimc-is@12000000 {
+ compatible = "samsung,exynos4212-fimc-is";
+ reg = <0x12000000 0x260000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&isp_clock CLK_ISP_FIMC_LITE0>,
+ <&isp_clock CLK_ISP_FIMC_LITE1>,
+ <&isp_clock CLK_ISP_PPMUISPX>,
+ <&isp_clock CLK_ISP_PPMUISPMX>,
+ <&isp_clock CLK_ISP_FIMC_ISP>,
+ <&isp_clock CLK_ISP_FIMC_DRC>,
+ <&isp_clock CLK_ISP_FIMC_FD>,
+ <&isp_clock CLK_ISP_MCUISP>,
+ <&isp_clock CLK_ISP_GICISP>,
+ <&isp_clock CLK_ISP_MCUCTL_ISP>,
+ <&isp_clock CLK_ISP_PWM_ISP>,
+ <&isp_clock CLK_ISP_DIV_ISP0>,
+ <&isp_clock CLK_ISP_DIV_ISP1>,
+ <&isp_clock CLK_ISP_DIV_MCUISP0>,
+ <&isp_clock CLK_ISP_DIV_MCUISP1>,
+ <&clock CLK_MOUT_MPLL_USER_T>,
+ <&clock CLK_ACLK200>,
+ <&clock CLK_ACLK400_MCUISP>,
+ <&clock CLK_DIV_ACLK200>,
+ <&clock CLK_DIV_ACLK400_MCUISP>,
+ <&clock CLK_UART_ISP_SCLK>;
+ clock-names = "lite0", "lite1", "ppmuispx",
+ "ppmuispmx", "isp",
+ "drc", "fd", "mcuisp",
+ "gicisp", "mcuctl_isp", "pwm_isp",
+ "ispdiv0", "ispdiv1", "mcuispdiv0",
+ "mcuispdiv1", "mpll", "aclk200",
+ "aclk400mcuisp", "div_aclk200",
+ "div_aclk400mcuisp", "uart";
+ iommus = <&sysmmu_fimc_isp>, <&sysmmu_fimc_drc>,
+ <&sysmmu_fimc_fd>, <&sysmmu_fimc_mcuctl>;
+ iommu-names = "isp", "drc", "fd", "mcuctl";
+ power-domains = <&pd_isp>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c-isp@12140000 {
+ compatible = "samsung,exynos4212-i2c-isp";
+ reg = <0x12140000 0x100>;
+ clocks = <&isp_clock CLK_ISP_I2C1_ISP>;
+ clock-names = "i2c_isp";
+ pinctrl-0 = <&fimc_is_i2c1>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ image-sensor@10 {
+ compatible = "samsung,s5k6a3";
+ reg = <0x10>;
+ svdda-supply = <&cam_io_reg>;
+ svddio-supply = <&ldo19_reg>;
+ afvdd-supply = <&ldo19_reg>;
+ clocks = <&camera 1>;
+ clock-names = "extclk";
+ assigned-clocks = <&camera 1>;
+ assigned-clock-rates = <24000000>;
+ gpios = <&gpm1 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&csis1_ep>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml
new file mode 100644
index 000000000000..bda724897293
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,exynos4212-fimc-lite.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series camera host interface (FIMC-LITE)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+description:
+ Each FIMC device should have an alias in the aliases node, in the form of
+ fimc-lite<n>, where <n> is an integer specifying the IP block instance.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos4212-fimc-lite
+ - samsung,exynos5250-fimc-lite
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: flite
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ fimc-lite@12390000 {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x12390000 0x1000>;
+ clocks = <&isp_clock CLK_ISP_FIMC_LITE0>;
+ clock-names = "flite";
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&pd_isp>;
+ iommus = <&sysmmu_fimc_lite0>;
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,fimc.yaml b/Documentation/devicetree/bindings/media/samsung,fimc.yaml
new file mode 100644
index 000000000000..1bfba84f8854
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,fimc.yaml
@@ -0,0 +1,278 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,fimc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5P/Exynos SoC Camera Subsystem (FIMC)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+description: |
+ The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices
+ represented by separate device tree nodes. Currently this includes: Fully
+ Integrated Mobile Camera (FIMC, in the S5P SoCs series known as CAMIF), MIPI
+ CSIS, FIMC-LITE and FIMC-IS (ISP).
+
+properties:
+ compatible:
+ const: samsung,fimc
+
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ '#clock-cells':
+ const: 1
+ description: |
+ The clock specifier cell stores an index of a clock: 0, 1 for
+ CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
+
+ clocks:
+ minItems: 2
+ maxItems: 4
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: sclk_cam0
+ - const: sclk_cam1
+ - const: pxl_async0
+ - const: pxl_async1
+
+ clock-output-names:
+ maxItems: 2
+
+ parallel-ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Active parallel video input ports.
+
+ patternProperties:
+ "^port@[01]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Camera A and camera B inputs.
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: idle
+ - const: active_a
+ - const: active_b
+
+patternProperties:
+ "^csis@[0-9a-f]+$":
+ type: object
+ $ref: samsung,exynos4210-csis.yaml#
+ description: MIPI CSI-2 receiver.
+
+ "^fimc@[0-9a-f]+$":
+ type: object
+ $ref: samsung,exynos4210-fimc.yaml#
+ description: Fully Integrated Mobile Camera.
+
+ "^fimc-is@[0-9a-f]+$":
+ type: object
+ $ref: samsung,exynos4212-fimc-is.yaml#
+ description: Imaging Subsystem (FIMC-IS).
+
+ "^fimc-lite@[0-9a-f]+$":
+ type: object
+ $ref: samsung,exynos4212-fimc-lite.yaml#
+ description: Camera host interface (FIMC-LITE).
+
+required:
+ - compatible
+ - '#address-cells'
+ - '#clock-cells'
+ - clocks
+ - clock-names
+ - clock-output-names
+ - ranges
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ camera@11800000 {
+ compatible = "samsung,fimc";
+ #clock-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0xba1000>;
+
+ clocks = <&clock CLK_SCLK_CAM0>, <&clock CLK_SCLK_CAM1>,
+ <&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>;
+ clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
+ clock-output-names = "cam_a_clkout", "cam_b_clkout";
+
+ assigned-clocks = <&clock CLK_MOUT_CAM0>,
+ <&clock CLK_MOUT_CAM1>;
+ assigned-clock-parents = <&clock CLK_XUSBXTI>,
+ <&clock CLK_XUSBXTI>;
+
+ pinctrl-0 = <&cam_port_a_clk_active &cam_port_b_clk_active>;
+ pinctrl-names = "default";
+
+ fimc@0 {
+ compatible = "samsung,exynos4212-fimc";
+ reg = <0x00000000 0x1000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_FIMC0>,
+ <&clock CLK_SCLK_FIMC0>;
+ clock-names = "fimc", "sclk_fimc";
+ power-domains = <&pd_cam>;
+ samsung,sysreg = <&sys_reg>;
+ iommus = <&sysmmu_fimc0>;
+
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,isp-wb;
+ samsung,cam-if;
+ };
+
+ /* ... FIMC 1-3 */
+
+ csis@80000 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x00080000 0x4000>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_CSIS0>,
+ <&clock CLK_SCLK_CSIS0>;
+ clock-names = "csis", "sclk_csis";
+ assigned-clocks = <&clock CLK_MOUT_CSIS0>,
+ <&clock CLK_SCLK_CSIS0>;
+ assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>;
+ assigned-clock-rates = <0>, <176000000>;
+
+ bus-width = <4>;
+ power-domains = <&pd_cam>;
+ phys = <&mipi_phy 0>;
+ phy-names = "csis";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+
+ /* Camera C (3) MIPI CSI-2 (CSIS0) */
+ port@3 {
+ reg = <3>;
+ endpoint {
+ remote-endpoint = <&s5c73m3_ep>;
+ data-lanes = <1 2 3 4>;
+ samsung,csis-hs-settle = <12>;
+ };
+ };
+ };
+
+ /* ... CSIS 1 */
+
+ fimc-lite@b90000 {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0xb90000 0x1000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&pd_isp>;
+ clocks = <&isp_clock CLK_ISP_FIMC_LITE0>;
+ clock-names = "flite";
+ iommus = <&sysmmu_fimc_lite0>;
+ };
+
+ /* ... FIMC-LITE 1 */
+
+ fimc-is@800000 {
+ compatible = "samsung,exynos4212-fimc-is";
+ reg = <0x00800000 0x260000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&isp_clock CLK_ISP_FIMC_LITE0>,
+ <&isp_clock CLK_ISP_FIMC_LITE1>,
+ <&isp_clock CLK_ISP_PPMUISPX>,
+ <&isp_clock CLK_ISP_PPMUISPMX>,
+ <&isp_clock CLK_ISP_FIMC_ISP>,
+ <&isp_clock CLK_ISP_FIMC_DRC>,
+ <&isp_clock CLK_ISP_FIMC_FD>,
+ <&isp_clock CLK_ISP_MCUISP>,
+ <&isp_clock CLK_ISP_GICISP>,
+ <&isp_clock CLK_ISP_MCUCTL_ISP>,
+ <&isp_clock CLK_ISP_PWM_ISP>,
+ <&isp_clock CLK_ISP_DIV_ISP0>,
+ <&isp_clock CLK_ISP_DIV_ISP1>,
+ <&isp_clock CLK_ISP_DIV_MCUISP0>,
+ <&isp_clock CLK_ISP_DIV_MCUISP1>,
+ <&clock CLK_MOUT_MPLL_USER_T>,
+ <&clock CLK_ACLK200>,
+ <&clock CLK_ACLK400_MCUISP>,
+ <&clock CLK_DIV_ACLK200>,
+ <&clock CLK_DIV_ACLK400_MCUISP>,
+ <&clock CLK_UART_ISP_SCLK>;
+ clock-names = "lite0", "lite1", "ppmuispx",
+ "ppmuispmx", "isp",
+ "drc", "fd", "mcuisp",
+ "gicisp", "mcuctl_isp", "pwm_isp",
+ "ispdiv0", "ispdiv1", "mcuispdiv0",
+ "mcuispdiv1", "mpll", "aclk200",
+ "aclk400mcuisp", "div_aclk200",
+ "div_aclk400mcuisp", "uart";
+ iommus = <&sysmmu_fimc_isp>, <&sysmmu_fimc_drc>,
+ <&sysmmu_fimc_fd>, <&sysmmu_fimc_mcuctl>;
+ iommu-names = "isp", "drc", "fd", "mcuctl";
+ power-domains = <&pd_isp>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c-isp@940000 {
+ compatible = "samsung,exynos4212-i2c-isp";
+ reg = <0x00940000 0x100>;
+ clocks = <&isp_clock CLK_ISP_I2C1_ISP>;
+ clock-names = "i2c_isp";
+ pinctrl-0 = <&fimc_is_i2c1>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ image-sensor@10 {
+ compatible = "samsung,s5k6a3";
+ reg = <0x10>;
+ svdda-supply = <&cam_io_reg>;
+ svddio-supply = <&ldo19_reg>;
+ afvdd-supply = <&ldo19_reg>;
+ /* CAM_B_CLKOUT */
+ clocks = <&camera 1>;
+ clock-names = "extclk";
+ assigned-clocks = <&camera 1>;
+ assigned-clock-rates = <24000000>;
+ gpios = <&gpm1 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&csis1_ep>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml b/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml
new file mode 100644
index 000000000000..1af5d7ac382c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml
@@ -0,0 +1,165 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,s5c73m3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5C73M3 8Mp camera ISP
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Sylwester Nawrocki <s.nawrocki@samsung.com>
+
+description:
+ The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656)
+ video data busses. The I2C bus is the main control bus and additionally the
+ SPI bus is used, mostly for transferring the firmware to and from the
+ device. Two slave device nodes corresponding to these control bus
+ interfaces are required and should be placed under respective bus
+ controller nodes.
+
+properties:
+ compatible:
+ const: samsung,s5c73m3
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cis_extclk
+
+ clock-frequency:
+ default: 24000000
+ description: cis_extclk clock frequency.
+
+ standby-gpios:
+ maxItems: 1
+ description: STANDBY pin.
+
+ vdda-supply:
+ description: Analog power supply (1.2V).
+
+ vdd-af-supply:
+ description: lens power supply (2.8V).
+
+ vddio-cis-supply:
+ description: CIS I/O power supply (1.2V to 1.8V).
+
+ vddio-host-supply:
+ description: Host I/O power supply (1.8V to 2.8V).
+
+ vdd-int-supply:
+ description: Digital power supply (1.2V).
+
+ vdd-reg-supply:
+ description: Regulator input power supply (2.8V).
+
+ xshutdown-gpios:
+ maxItems: 1
+ description: XSHUTDOWN pin.
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ required:
+ - spi-max-frequency
+ then:
+ properties:
+ # The SPI node is simplified firmware-transfer interface only
+ clocks: false
+ clock-names: false
+ standby-gpios: false
+ vdda-supply: false
+ vdd-af-supply: false
+ vddio-cis-supply: false
+ vddio-host-supply: false
+ vdd-int-supply: false
+ vdd-reg-supply: false
+ xshutdown-gpios: false
+ port: false
+ else:
+ required:
+ - clocks
+ - clock-names
+ - standby-gpios
+ - vdda-supply
+ - vdd-af-supply
+ - vddio-cis-supply
+ - vddio-host-supply
+ - vdd-int-supply
+ - vdd-reg-supply
+ - xshutdown-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ image-sensor@3c {
+ compatible = "samsung,s5c73m3";
+ reg = <0x3c>;
+ clock-frequency = <24000000>;
+ clocks = <&camera 0>;
+ clock-names = "cis_extclk";
+ standby-gpios = <&gpm0 6 GPIO_ACTIVE_LOW>;
+ vdda-supply = <&cam_vdda_reg>;
+ vdd-af-supply = <&cam_af_reg>;
+ vddio-cis-supply = <&ldo9_reg>;
+ vddio-host-supply = <&ldo18_reg>;
+ vdd-int-supply = <&buck9_reg>;
+ vdd-reg-supply = <&cam_io_reg>;
+ xshutdown-gpios = <&gpf1 3 GPIO_ACTIVE_LOW>; /* ISP_RESET */
+
+ port {
+ s5c73m3_ep: endpoint {
+ remote-endpoint = <&csis0_ep>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+ };
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ image-sensor@0 {
+ compatible = "samsung,s5c73m3";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ controller-data {
+ samsung,spi-feedback-delay = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
new file mode 100644
index 000000000000..b46cc780703c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung,s5p-mfc.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/samsung,s5p-mfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos Multi Format Codec (MFC)
+
+maintainers:
+ - Marek Szyprowski <m.szyprowski@samsung.com>
+ - Aakarsh Jain <aakarsh.jain@samsung.com>
+
+description:
+ Multi Format Codec (MFC) is the IP present in Samsung SoCs which
+ supports high resolution decoding and encoding functionalities.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - samsung,exynos5433-mfc # Exynos5433
+ - samsung,mfc-v5 # Exynos4
+ - samsung,mfc-v6 # Exynos5
+ - samsung,mfc-v7 # Exynos5420
+ - samsung,mfc-v8 # Exynos5800
+ - samsung,mfc-v10 # Exynos7880
+ - tesla,fsd-mfc # Tesla FSD
+ - items:
+ - enum:
+ - samsung,exynos3250-mfc # Exynos3250
+ - const: samsung,mfc-v7 # Fall back for Exynos3250
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ iommu-names:
+ minItems: 1
+ items:
+ - const: left
+ - const: right
+
+ power-domains:
+ maxItems: 1
+
+ memory-region:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos3250-mfc
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ items:
+ - const: mfc
+ - const: sclk_mfc
+ iommus:
+ maxItems: 1
+ iommu-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5433-mfc
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: pclk
+ - const: aclk
+ - const: aclk_xiu
+ iommus:
+ minItems: 2
+ iommu-names:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,mfc-v5
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ items:
+ - const: mfc
+ - const: sclk_mfc
+ iommus:
+ minItems: 2
+ iommu-names:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,mfc-v6
+ - samsung,mfc-v8
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: mfc
+ iommus:
+ minItems: 2
+ iommu-names:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,mfc-v7
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - tesla,fsd-mfc
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: mfc
+ iommus:
+ maxItems: 2
+ iommus-names: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/exynos4.h>
+ #include <dt-bindings/clock/exynos-audss-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ codec@13400000 {
+ compatible = "samsung,mfc-v5";
+ reg = <0x13400000 0x10000>;
+ interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&pd_mfc>;
+ clocks = <&clock CLK_MFC>, <&clock CLK_SCLK_MFC>;
+ clock-names = "mfc", "sclk_mfc";
+ iommus = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
+ iommu-names = "left", "right";
+ };
diff --git a/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml b/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml
index e28d6ec56c0b..5c969e764d4f 100644
--- a/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml
+++ b/Documentation/devicetree/bindings/media/samsung,s5pv210-jpeg.yaml
@@ -42,7 +42,6 @@ properties:
reg:
maxItems: 1
-
required:
- compatible
- clocks
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
deleted file mode 100644
index 20447529c985..000000000000
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ /dev/null
@@ -1,209 +0,0 @@
-Samsung S5P/Exynos SoC Camera Subsystem (FIMC)
-----------------------------------------------
-
-The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices
-represented by separate device tree nodes. Currently this includes: FIMC (in
-the S5P SoCs series known as CAMIF), MIPI CSIS, FIMC-LITE and FIMC-IS (ISP).
-
-The sub-subdevices are defined as child nodes of the common 'camera' node which
-also includes common properties of the whole subsystem not really specific to
-any single sub-device, like common camera port pins or the CAMCLK clock outputs
-for external image sensors attached to an SoC.
-
-Common 'camera' node
---------------------
-
-Required properties:
-
-- compatible: must be "samsung,fimc", "simple-bus"
-- clocks: list of clock specifiers, corresponding to entries in
- the clock-names property;
-- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0",
- "pxl_async1" entries, matching entries in the clocks property.
-
-- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt),
- must be 1. A clock provider is associated with the 'camera' node and it should
- be referenced by external sensors that use clocks provided by the SoC on
- CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
- The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
-
-- clock-output-names: from the common clock bindings, should contain names of
- clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
- CAM_B_CLKOUT output clocks respectively.
-
-The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
-to define a required pinctrl state named "default" and optional pinctrl states:
-"idle", "active-a", active-b". These optional states can be used to switch the
-camera port pinmux at runtime. The "idle" state should configure both the camera
-ports A and B into high impedance state, especially the CAMCLK clock output
-should be inactive. For the "active-a" state the camera port A must be activated
-and the port B deactivated and for the state "active-b" it should be the other
-way around.
-
-The 'camera' node must include at least one 'fimc' child node.
-
-
-'fimc' device nodes
--------------------
-
-Required properties:
-
-- compatible: "samsung,s5pv210-fimc" for S5PV210, "samsung,exynos4210-fimc"
- for Exynos4210 and "samsung,exynos4212-fimc" for Exynos4x12 SoCs;
-- reg: physical base address and length of the registers set for the device;
-- interrupts: should contain FIMC interrupt;
-- clocks: list of clock specifiers, must contain an entry for each required
- entry in clock-names;
-- clock-names: must contain "fimc", "sclk_fimc" entries.
-- samsung,pix-limits: an array of maximum supported image sizes in pixels, for
- details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of
- each cell is as follows:
- 0 - scaler input horizontal size,
- 1 - input horizontal size for the scaler bypassed,
- 2 - REAL_WIDTH without input rotation,
- 3 - REAL_HEIGHT with input rotation,
-- samsung,sysreg: a phandle to the SYSREG node.
-
-Each FIMC device should have an alias in the aliases node, in the form of
-fimc<n>, where <n> is an integer specifying the IP block instance.
-
-Optional properties:
-
-- clock-frequency: maximum FIMC local clock (LCLK) frequency;
-- samsung,min-pix-sizes: an array specyfing minimum image size in pixels at
- the FIMC input and output DMA, in the first and second cell respectively.
- Default value when this property is not present is <16 16>;
-- samsung,min-pix-alignment: minimum supported image height alignment (first
- cell) and the horizontal image offset (second cell). The values are in pixels
- and default to <2 1> when this property is not present;
-- samsung,mainscaler-ext: a boolean property indicating whether the FIMC IP
- supports extended image size and has CIEXTEN register;
-- samsung,rotators: a bitmask specifying whether this IP has the input and
- the output rotator. Bits 4 and 0 correspond to input and output rotator
- respectively. If a rotator is present its corresponding bit should be set.
- Default value when this property is not specified is 0x11.
-- samsung,cam-if: a bolean property indicating whether the IP block includes
- the camera input interface.
-- samsung,isp-wb: this property must be present if the IP block has the ISP
- writeback input.
-- samsung,lcd-wb: this property must be present if the IP block has the LCD
- writeback input.
-
-
-'parallel-ports' node
----------------------
-
-This node should contain child 'port' nodes specifying active parallel video
-input ports. It includes camera A and camera B inputs. 'reg' property in the
-port nodes specifies data input - 1, 2 indicates input A, B respectively.
-
-Optional properties
-
-- samsung,camclk-out (deprecated) : specifies clock output for remote sensor,
- 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
-
-Image sensor nodes
-------------------
-
-The sensor device nodes should be added to their control bus controller (e.g.
-I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
-using the common video interfaces bindings, defined in video-interfaces.txt.
-
-Example:
-
- aliases {
- fimc0 = &fimc_0;
- };
-
- /* Parallel bus IF sensor */
- i2c_0: i2c@13860000 {
- s5k6aa: sensor@3c {
- compatible = "samsung,s5k6aafx";
- reg = <0x3c>;
- vddio-supply = <...>;
-
- clock-frequency = <24000000>;
- clocks = <&camera 1>;
- clock-names = "mclk";
-
- port {
- s5k6aa_ep: endpoint {
- remote-endpoint = <&fimc0_ep>;
- bus-width = <8>;
- hsync-active = <0>;
- vsync-active = <1>;
- pclk-sample = <1>;
- };
- };
- };
-
- /* MIPI CSI-2 bus IF sensor */
- s5c73m3: sensor@1a {
- compatible = "samsung,s5c73m3";
- reg = <0x1a>;
- vddio-supply = <...>;
-
- clock-frequency = <24000000>;
- clocks = <&camera 0>;
- clock-names = "mclk";
-
- port {
- s5c73m3_1: endpoint {
- data-lanes = <1 2 3 4>;
- remote-endpoint = <&csis0_ep>;
- };
- };
- };
- };
-
- camera {
- compatible = "samsung,fimc", "simple-bus";
- clocks = <&clock 132>, <&clock 133>, <&clock 351>,
- <&clock 352>;
- clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0",
- "pxl_async1";
- #clock-cells = <1>;
- clock-output-names = "cam_a_clkout", "cam_b_clkout";
- pinctrl-names = "default";
- pinctrl-0 = <&cam_port_a_clk_active>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- /* parallel camera ports */
- parallel-ports {
- /* camera A input */
- port@1 {
- reg = <1>;
- fimc0_ep: endpoint {
- remote-endpoint = <&s5k6aa_ep>;
- bus-width = <8>;
- hsync-active = <0>;
- vsync-active = <1>;
- pclk-sample = <1>;
- };
- };
- };
-
- fimc_0: fimc@11800000 {
- compatible = "samsung,exynos4210-fimc";
- reg = <0x11800000 0x1000>;
- interrupts = <0 85 0>;
- };
-
- csis_0: csis@11880000 {
- compatible = "samsung,exynos4210-csis";
- reg = <0x11880000 0x1000>;
- interrupts = <0 78 0>;
- /* camera C input */
- port@3 {
- reg = <3>;
- csis0_ep: endpoint {
- remote-endpoint = <&s5c73m3_ep>;
- data-lanes = <1 2 3 4>;
- samsung,csis-hs-settle = <12>;
- };
- };
- };
- };
-
-The MIPI-CSIS device binding is defined in samsung-mipi-csis.txt.
diff --git a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
deleted file mode 100644
index a4149c9434ea..000000000000
--- a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS)
--------------------------------------------------------------
-
-Required properties:
-
-- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
- "samsung,exynos4210-csis" for Exynos4210 (S5PC210),
- "samsung,exynos4212-csis" for Exynos4212/Exynos4412,
- "samsung,exynos5250-csis" for Exynos5250;
-- reg : offset and length of the register set for the device;
-- interrupts : should contain MIPI CSIS interrupt; the format of the
- interrupt specifier depends on the interrupt controller;
-- bus-width : maximum number of data lanes supported (SoC specific);
-- vddio-supply : MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V);
-- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V);
-- clocks : list of clock specifiers, corresponding to entries in
- clock-names property;
-- clock-names : must contain "csis", "sclk_csis" entries, matching entries
- in the clocks property.
-
-Optional properties:
-
-- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
- value when this property is not specified is 166 MHz;
-- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is present
- external clock from CMU will be used, or the bus clock if
- if it's not specified.
-
-The device node should contain one 'port' child node with one child 'endpoint'
-node, according to the bindings defined in Documentation/devicetree/bindings/
-media/video-interfaces.txt. The following are properties specific to those nodes.
-
-port node
----------
-
-- reg : (required) must be 3 for camera C input (CSIS0) or 4 for
- camera D input (CSIS1);
-
-endpoint node
--------------
-
-- data-lanes : (required) an array specifying active physical MIPI-CSI2
- data input lanes and their mapping to logical lanes; the
- array's content is unused, only its length is meaningful;
-
-- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle time;
-
-
-Example:
-
- reg0: regulator@0 {
- };
-
- reg1: regulator@1 {
- };
-
-/* SoC properties */
-
- csis_0: csis@11880000 {
- compatible = "samsung,exynos4210-csis";
- reg = <0x11880000 0x1000>;
- interrupts = <0 78 0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
-/* Board properties */
-
- csis_0: csis@11880000 {
- clock-frequency = <166000000>;
- vddio-supply = <&reg0>;
- vddcore-supply = <&reg1>;
- port {
- reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */
- csis0_ep: endpoint {
- remote-endpoint = <...>;
- data-lanes = <1>, <2>;
- samsung,csis-hs-settle = <12>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
deleted file mode 100644
index 21f31fdf5543..000000000000
--- a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Samsung S5C73M3 8Mp camera ISP
-------------------------------
-
-The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video
-data busses. The I2C bus is the main control bus and additionally the SPI bus
-is used, mostly for transferring the firmware to and from the device. Two
-slave device nodes corresponding to these control bus interfaces are required
-and should be placed under respective bus controller nodes.
-
-I2C slave device node
----------------------
-
-Required properties:
-
-- compatible : "samsung,s5c73m3";
-- reg : I2C slave address of the sensor;
-- vdd-int-supply : digital power supply (1.2V);
-- vdda-supply : analog power supply (1.2V);
-- vdd-reg-supply : regulator input power supply (2.8V);
-- vddio-host-supply : host I/O power supply (1.8V to 2.8V);
-- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V);
-- vdd-af-supply : lens power supply (2.8V);
-- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin;
-- standby-gpios : specifier of GPIO connected to the STANDBY pin;
-- clocks : should contain list of phandle and clock specifier pairs
- according to common clock bindings for the clocks described
- in the clock-names property;
-- clock-names : should contain "cis_extclk" entry for the CIS_EXTCLK clock;
-
-Optional properties:
-
-- clock-frequency : the frequency at which the "cis_extclk" clock should be
- configured to operate, in Hz; if this property is not
- specified default 24 MHz value will be used.
-
-The common video interfaces bindings (see video-interfaces.txt) should be used
-to specify link from the S5C73M3 to an external image data receiver. The S5C73M3
-device node should contain one 'port' child node with an 'endpoint' subnode for
-this purpose. The data link from a raw image sensor to the S5C73M3 can be
-similarly specified, but it is optional since the S5C73M3 ISP and a raw image
-sensor are usually inseparable and form a hybrid module.
-
-Following properties are valid for the endpoint node(s):
-
-endpoint subnode
-----------------
-
-- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
- video-interfaces.txt. This sensor doesn't support data lane remapping
- and physical lane indexes in subsequent elements of the array should
- be only consecutive ascending values.
-
-SPI device node
----------------
-
-Required properties:
-
-- compatible : "samsung,s5c73m3";
-
-For more details see description of the SPI busses bindings
-(../spi/spi-bus.txt) and bindings of a specific bus controller.
-
-Example:
-
-i2c@138a000000 {
- ...
- s5c73m3@3c {
- compatible = "samsung,s5c73m3";
- reg = <0x3c>;
- vdd-int-supply = <&buck9_reg>;
- vdda-supply = <&ldo17_reg>;
- vdd-reg-supply = <&cam_io_reg>;
- vddio-host-supply = <&ldo18_reg>;
- vddio-cis-supply = <&ldo9_reg>;
- vdd-af-supply = <&cam_af_reg>;
- clock-frequency = <24000000>;
- clocks = <&clk 0>;
- clock-names = "cis_extclk";
- reset-gpios = <&gpf1 3 1>;
- standby-gpios = <&gpm0 1 1>;
- port {
- s5c73m3_ep: endpoint {
- remote-endpoint = <&csis0_ep>;
- data-lanes = <1 2 3 4>;
- };
- };
- };
-};
-
-spi@1392000 {
- ...
- s5c73m3_spi: s5c73m3@0 {
- compatible = "samsung,s5c73m3";
- reg = <0>;
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
deleted file mode 100644
index 1f51e0439c96..000000000000
--- a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP
---------------------------------------------------------------------
-
-Required properties:
-
-- compatible : "samsung,s5k5baf";
-- reg : I2C slave address of the sensor;
-- vdda-supply : analog power supply 2.8V (2.6V to 3.0V);
-- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V)
- or 2.8V (2.6V to 3.0);
-- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V)
- or 2.8V (2.5V to 3.1V);
-- stbyn-gpios : GPIO connected to STDBYN pin;
-- rstn-gpios : GPIO connected to RSTN pin;
-- clocks : list of phandle and clock specifier pairs
- according to common clock bindings for the
- clocks described in clock-names;
-- clock-names : should include "mclk" for the sensor's master clock;
-
-Optional properties:
-
-- clock-frequency : the frequency at which the "mclk" clock should be
- configured to operate, in Hz; if this property is not
- specified default 24 MHz value will be used.
-
-The device node should contain one 'port' child node with one child 'endpoint'
-node, according to the bindings defined in Documentation/devicetree/bindings/
-media/video-interfaces.txt. The following are properties specific to those
-nodes.
-
-endpoint node
--------------
-
-- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
- video-interfaces.txt. If present it should be <1> - the device
- supports only one data lane without re-mapping.
-
-Example:
-
-s5k5bafx@2d {
- compatible = "samsung,s5k5baf";
- reg = <0x2d>;
- vdda-supply = <&cam_io_en_reg>;
- vddreg-supply = <&vt_core_15v_reg>;
- vddio-supply = <&vtcam_reg>;
- stbyn-gpios = <&gpl2 0 1>;
- rstn-gpios = <&gpl2 1 1>;
- clock-names = "mclk";
- clocks = <&clock_cam 0>;
- clock-frequency = <24000000>;
-
- port {
- s5k5bafx_ep: endpoint {
- remote-endpoint = <&csis1_ep>;
- data-lanes = <1>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt
deleted file mode 100644
index cce01e82f3e3..000000000000
--- a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Samsung S5K6A3(YX) raw image sensor
----------------------------------
-
-S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
-and CCI (I2C compatible) control bus.
-
-Required properties:
-
-- compatible : "samsung,s5k6a3";
-- reg : I2C slave address of the sensor;
-- svdda-supply : core voltage supply;
-- svddio-supply : I/O voltage supply;
-- afvdd-supply : AF (actuator) voltage supply;
-- gpios : specifier of a GPIO connected to the RESET pin;
-- clocks : should contain list of phandle and clock specifier pairs
- according to common clock bindings for the clocks described
- in the clock-names property;
-- clock-names : should contain "extclk" entry for the sensor's EXTCLK clock;
-
-Optional properties:
-
-- clock-frequency : the frequency at which the "extclk" clock should be
- configured to operate, in Hz; if this property is not
- specified default 24 MHz value will be used.
-
-The common video interfaces bindings (see video-interfaces.txt) should be
-used to specify link to the image data receiver. The S5K6A3(YX) device
-node should contain one 'port' child node with an 'endpoint' subnode.
-
-Following properties are valid for the endpoint node:
-
-- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
- video-interfaces.txt. The sensor supports only one data lane.
diff --git a/Documentation/devicetree/bindings/media/si470x.txt b/Documentation/devicetree/bindings/media/si470x.txt
deleted file mode 100644
index a9403558362e..000000000000
--- a/Documentation/devicetree/bindings/media/si470x.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Silicon Labs FM Radio receiver
-
-The Silicon Labs Si470x is family of FM radio receivers with receive power scan
-supporting 76-108 MHz, programmable through an I2C interface.
-Some of them includes an RDS encoder.
-
-Required Properties:
-- compatible: Should contain "silabs,si470x"
-- reg: the I2C address of the device
-
-Optional Properties:
-- interrupts : The interrupt number
-- reset-gpios: GPIO specifier for the chips reset line
-
-Example:
-
-&i2c2 {
- si470x@63 {
- compatible = "silabs,si470x";
- reg = <0x63>;
-
- interrupt-parent = <&gpj2>;
- interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>;
- };
-};
diff --git a/Documentation/devicetree/bindings/media/silabs,si470x.yaml b/Documentation/devicetree/bindings/media/silabs,si470x.yaml
new file mode 100644
index 000000000000..db22b88fc5bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/silabs,si470x.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/silabs,si470x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Labs Si470x FM Radio Receiver
+
+maintainers:
+ - Hans Verkuil <hverkuil@kernel.org>
+ - Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
+
+properties:
+ compatible:
+ const: silabs,si470x
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fmradio@10 {
+ compatible = "silabs,si470x";
+ reg = <0x10>;
+ interrupt-parent = <&gpj2>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
new file mode 100644
index 000000000000..b7f6c87d0e06
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
+
+---
+$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare HDMI RX Controller
+
+maintainers:
+ - Dmitry Osipenko <dmitry.osipenko@collabora.com>
+
+description:
+ Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
+ allowing devices to receive and decode high-resolution video streams
+ from external sources like media players, cameras, laptops, etc.
+
+properties:
+ compatible:
+ items:
+ - const: rockchip,rk3588-hdmirx-ctrler
+ - const: snps,dw-hdmi-rx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: cec
+ - const: hdmi
+ - const: dma
+
+ clocks:
+ maxItems: 7
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: audio
+ - const: cr_para
+ - const: pclk
+ - const: ref
+ - const: hclk_s_hdmirx
+ - const: hclk_vo1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: axi
+ - const: apb
+ - const: ref
+ - const: biu
+
+ memory-region:
+ maxItems: 1
+
+ hpd-gpios:
+ description: GPIO specifier for HPD.
+ maxItems: 1
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle of the syscon node for the general register file
+ containing HDMIRX PHY status bits.
+
+ rockchip,vo1-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle of the syscon node for the Video Output GRF register
+ to enable EDID transfer through SDAIN and SCLIN.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - pinctrl-0
+ - hpd-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/gpio/gpio.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>
+ hdmi_receiver: hdmi-receiver@fdee0000 {
+ compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
+ reg = <0xfdee0000 0x6000>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "cec", "hdmi", "dma";
+ clocks = <&cru ACLK_HDMIRX>,
+ <&cru CLK_HDMIRX_AUD>,
+ <&cru CLK_CR_PARA>,
+ <&cru PCLK_HDMIRX>,
+ <&cru CLK_HDMIRX_REF>,
+ <&cru PCLK_S_HDMIRX>,
+ <&cru HCLK_VO1>;
+ clock-names = "aclk",
+ "audio",
+ "cr_para",
+ "pclk",
+ "ref",
+ "hclk_s_hdmirx",
+ "hclk_vo1";
+ power-domains = <&power RK3588_PD_VO1>;
+ resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
+ <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
+ reset-names = "axi", "apb", "ref", "biu";
+ memory-region = <&hdmi_receiver_cma>;
+ pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
+ pinctrl-names = "default";
+ hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 9c1262a276b5..34147127192f 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/st,stm32-dcmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) binding
+title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
maintainers:
- Hugues Fruchet <hugues.fruchet@foss.st.com>
@@ -36,6 +36,10 @@ properties:
resets:
maxItems: 1
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
port:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
@@ -90,7 +94,9 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
+ #include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
+
dcmi: dcmi@4c006000 {
compatible = "st,stm32-dcmi";
reg = <0x4c006000 0x400>;
@@ -104,7 +110,7 @@ examples:
port {
dcmi_0: endpoint {
remote-endpoint = <&ov5640_0>;
- bus-type = <5>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
hsync-active = <0>;
vsync-active = <0>;
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml
new file mode 100644
index 000000000000..7b03a77adbce
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmipp.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/st,stm32-dcmipp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 DCMIPP Digital Camera Memory Interface Pixel Processor
+
+maintainers:
+ - Hugues Fruchet <hugues.fruchet@foss.st.com>
+ - Alain Volmat <alain.volmat@foss.st.com>
+
+properties:
+ compatible:
+ enum:
+ - st,stm32mp13-dcmipp
+ - st,stm32mp25-dcmipp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: bus clock
+ - description: csi clock
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: kclk
+ - const: mclk
+ minItems: 1
+
+ resets:
+ maxItems: 1
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ DCMIPP supports a single port node with parallel bus.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ enum: [4, 5, 6]
+ default: 5
+
+ bus-width:
+ enum: [8, 10, 12, 14]
+ default: 8
+
+ pclk-sample: true
+ hsync-active: true
+ vsync-active: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - port
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp13-dcmipp
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ port:
+ properties:
+ endpoint:
+ properties:
+ bus-type:
+ enum: [5, 6]
+ else:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ minItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stm32mp13-clks.h>
+ #include <dt-bindings/reset/stm32mp13-resets.h>
+ dcmipp@5a000000 {
+ compatible = "st,stm32mp13-dcmipp";
+ reg = <0x5a000000 0x400>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&rcc DCMIPP_R>;
+ clocks = <&rcc DCMIPP_K>;
+
+ port {
+ endpoint {
+ remote-endpoint = <&mipid02_2>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml b/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml
index f97b4a246605..b9f7d84f38c2 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/st,stm32-dma2d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Chrom-Art Accelerator DMA2D binding
+title: STMicroelectronics STM32 Chrom-Art Accelerator DMA2D
description:
Chrom-ART Accelerator(DMA2D), graphical hardware accelerator
@@ -21,7 +21,6 @@ description:
format and copy the result into a part or the whole of a destination image
with a different color format. (TODO)
-
maintainers:
- Dillon Min <dillon.minfei@gmail.com>
diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml
new file mode 100644
index 000000000000..e9fa3cfea5d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/st,stm32mp25-csi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 CSI controller
+
+description:
+ The STM32 CSI controller, coupled with a D-PHY allows connecting a CSI-2
+ based camera to the DCMIPP camera pipeline.
+
+maintainers:
+ - Alain Volmat <alain.volmat@foss.st.com>
+
+properties:
+ compatible:
+ enum:
+ - st,stm32mp25-csi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: txesc
+ - const: csi2phy
+
+ resets:
+ maxItems: 1
+
+ vdd-supply:
+ description: Digital core power supply (0.91V)
+
+ vdda18-supply:
+ description: System analog power supply (1.8V)
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port node
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port node
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+ csi@48020000 {
+ compatible = "st,stm32mp25-csi";
+ reg = <0x48020000 0x2000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&rcc CSI_R>;
+ clocks = <&rcc CK_KER_CSI>, <&rcc CK_KER_CSITXESC>, <&rcc CK_KER_CSIPHY>;
+ clock-names = "pclk", "txesc", "csi2phy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&imx335_ep>;
+ data-lanes = <1 2>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&dcmipp_0>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
new file mode 100644
index 000000000000..73726c65cfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/st,stm32mp25-video-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 VDEC video decoder & VENC video encoder
+
+maintainers:
+ - Hugues Fruchet <hugues.fruchet@foss.st.com>
+
+description:
+ The STMicroelectronics STM32MP25 SOCs embeds a VDEC video hardware
+ decoder peripheral based on Verisilicon VC8000NanoD IP (former Hantro G1)
+ and a VENC video hardware encoder peripheral based on Verisilicon
+ VC8000NanoE IP (former Hantro H1).
+
+properties:
+ compatible:
+ enum:
+ - st,stm32mp25-vdec
+ - st,stm32mp25-venc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ video-codec@580d0000 {
+ compatible = "st,stm32mp25-vdec";
+ reg = <0x580d0000 0x3c8>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ck_icn_p_vdec>;
+ };
diff --git a/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml b/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml
new file mode 100644
index 000000000000..c66586d90fa2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/starfive,jh7110-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Starfive SoC CAMSS ISP
+
+maintainers:
+ - Jack Zhu <jack.zhu@starfivetech.com>
+ - Changhuang Liang <changhuang.liang@starfivetech.com>
+
+description:
+ The Starfive CAMSS ISP is a Camera interface for Starfive JH7110 SoC. It
+ consists of a VIN controller (Video In Controller, a top-level control unit)
+ and an ISP.
+
+properties:
+ compatible:
+ const: starfive,jh7110-camss
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: syscon
+ - const: isp
+
+ clocks:
+ maxItems: 7
+
+ clock-names:
+ items:
+ - const: apb_func
+ - const: wrapper_clk_c
+ - const: dvp_inv
+ - const: axiwr
+ - const: mipi_rx0_pxl
+ - const: ispcore_2x
+ - const: isp_axi
+
+ resets:
+ maxItems: 6
+
+ reset-names:
+ items:
+ - const: wrapper_p
+ - const: wrapper_c
+ - const: axird
+ - const: axiwr
+ - const: isp_top_n
+ - const: isp_top_axi
+
+ power-domains:
+ items:
+ - description: JH7110 ISP Power Domain Switch Controller.
+
+ interrupts:
+ maxItems: 4
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Input port for receiving DVP data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ bus-type:
+ enum: [5, 6]
+
+ bus-width:
+ enum: [8, 10, 12]
+
+ data-shift:
+ enum: [0, 2]
+ default: 0
+
+ hsync-active:
+ enum: [0, 1]
+ default: 1
+
+ vsync-active:
+ enum: [0, 1]
+ default: 1
+
+ required:
+ - bus-type
+ - bus-width
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Input port for receiving CSI data.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ isp@19840000 {
+ compatible = "starfive,jh7110-camss";
+ reg = <0x19840000 0x10000>,
+ <0x19870000 0x30000>;
+ reg-names = "syscon", "isp";
+ clocks = <&ispcrg 0>,
+ <&ispcrg 13>,
+ <&ispcrg 2>,
+ <&ispcrg 12>,
+ <&ispcrg 1>,
+ <&syscrg 51>,
+ <&syscrg 52>;
+ clock-names = "apb_func",
+ "wrapper_clk_c",
+ "dvp_inv",
+ "axiwr",
+ "mipi_rx0_pxl",
+ "ispcore_2x",
+ "isp_axi";
+ resets = <&ispcrg 0>,
+ <&ispcrg 1>,
+ <&ispcrg 10>,
+ <&ispcrg 11>,
+ <&syscrg 41>,
+ <&syscrg 42>;
+ reset-names = "wrapper_p",
+ "wrapper_c",
+ "axird",
+ "axiwr",
+ "isp_top_n",
+ "isp_top_axi";
+ power-domains = <&pwrc 5>;
+ interrupts = <92>, <87>, <88>, <90>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ vin_from_sc2235: endpoint {
+ remote-endpoint = <&sc2235_to_vin>;
+ bus-type = <5>;
+ bus-width = <8>;
+ data-shift = <2>;
+ hsync-active = <1>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ vin_from_csi2rx: endpoint {
+ remote-endpoint = <&csi2rx_to_vin>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt b/Documentation/devicetree/bindings/media/stih-cec.txt
deleted file mode 100644
index ece0832fdeaf..000000000000
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-STMicroelectronics STIH4xx HDMI CEC driver
-
-Required properties:
- - compatible : value should be "st,stih-cec"
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
- - clocks : from common clock binding: handle to HDMI CEC clock
- - interrupts : HDMI CEC interrupt number to the CPU.
- - pinctrl-names: Contains only one value - "default"
- - pinctrl-0: Specifies the pin control groups used for CEC hardware.
- - resets: Reference to a reset controller
- - hdmi-phandle: Phandle to the HDMI controller, see also cec.txt.
-
-Example for STIH407:
-
-sti-cec@94a087c {
- compatible = "st,stih-cec";
- reg = <0x94a087c 0x64>;
- clocks = <&clk_sysin>;
- clock-names = "cec-clk";
- interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
- interrupt-names = "cec-irq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_cec0_default>;
- resets = <&softreset STIH407_LPM_SOFTRESET>;
- hdmi-phandle = <&hdmi>;
-};
diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
deleted file mode 100644
index 880d4d70c9fd..000000000000
--- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-STMicroelectronics STi c8sectpfe binding
-============================================
-
-This document describes the c8sectpfe device bindings that is used to get transport
-stream data into the SoC on the TS pins, and into DDR for further processing.
-
-It is typically used in conjunction with one or more demodulator and tuner devices
-which converts from the RF to digital domain. Demodulators and tuners are usually
-located on an external DVB frontend card connected to SoC TS input pins.
-
-Currently 7 TS input (tsin) channels are supported on the stih407 family SoC.
-
-Required properties (controller (parent) node):
-- compatible : Should be "stih407-c8sectpfe"
-
-- reg : Address and length of register sets for each device in
- "reg-names"
-
-- reg-names : The names of the register addresses corresponding to the
- registers filled in "reg":
- - c8sectpfe: c8sectpfe registers
- - c8sectpfe-ram: c8sectpfe internal sram
-
-- clocks : phandle list of c8sectpfe clocks
-- clock-names : should be "c8sectpfe"
-See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- pinctrl-names : a pinctrl state named tsin%d-serial or tsin%d-parallel (where %d is tsin-num)
- must be defined for each tsin child node.
-- pinctrl-0 : phandle referencing pin configuration for this tsin configuration
-See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-
-Required properties (tsin (child) node):
-
-- tsin-num : tsin id of the InputBlock (must be between 0 to 6)
-- i2c-bus : phandle to the I2C bus DT node which the demodulators & tuners on this tsin channel are connected.
-- reset-gpios : reset gpio for this tsin channel.
-
-Optional properties (tsin (child) node):
-
-- invert-ts-clk : Bool property to control sense of ts input clock (data stored on falling edge of clk).
-- serial-not-parallel : Bool property to configure input bus width (serial on ts_data<7>).
-- async-not-sync : Bool property to control if data is received in asynchronous mode
- (all bits/bytes with ts_valid or ts_packet asserted are valid).
-
-- dvb-card : Describes the NIM card connected to this tsin channel.
-
-Example:
-
-/* stih410 SoC b2120 + b2004a + stv0367-pll(NIMB) + stv0367-tda18212 (NIMA) DT example) */
-
- c8sectpfe@8a20000 {
- compatible = "st,stih407-c8sectpfe";
- reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>;
- reg-names = "stfe", "stfe-ram";
- interrupts = <GIC_SPI 34 IRQ_TYPE_NONE>, <GIC_SPI 35 IRQ_TYPE_NONE>;
- interrupt-names = "stfe-error-irq", "stfe-idle-irq";
- pinctrl-0 = <&pinctrl_tsin0_serial>;
- pinctrl-1 = <&pinctrl_tsin0_parallel>;
- pinctrl-2 = <&pinctrl_tsin3_serial>;
- pinctrl-3 = <&pinctrl_tsin4_serial_alt3>;
- pinctrl-4 = <&pinctrl_tsin5_serial_alt1>;
- pinctrl-names = "tsin0-serial",
- "tsin0-parallel",
- "tsin3-serial",
- "tsin4-serial",
- "tsin5-serial";
- clocks = <&clk_s_c0_flexgen CLK_PROC_STFE>;
- clock-names = "c8sectpfe";
-
- /* tsin0 is TSA on NIMA */
- tsin0: port@0 {
- tsin-num = <0>;
- serial-not-parallel;
- i2c-bus = <&ssc2>;
- reset-gpios = <&pio15 4 GPIO_ACTIVE_HIGH>;
- dvb-card = <STV0367_TDA18212_NIMA_1>;
- };
-
- tsin3: port@3 {
- tsin-num = <3>;
- serial-not-parallel;
- i2c-bus = <&ssc3>;
- reset-gpios = <&pio15 7 GPIO_ACTIVE_HIGH>;
- dvb-card = <STV0367_TDA18212_NIMB_1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt b/Documentation/devicetree/bindings/media/tegra-cec.txt
deleted file mode 100644
index c503f06f3b84..000000000000
--- a/Documentation/devicetree/bindings/media/tegra-cec.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Tegra HDMI CEC hardware
-
-The HDMI CEC module is present in Tegra SoCs and its purpose is to
-handle communication between HDMI connected devices over the CEC bus.
-
-Required properties:
- - compatible : value should be one of the following:
- "nvidia,tegra114-cec"
- "nvidia,tegra124-cec"
- "nvidia,tegra210-cec"
- - reg : Physical base address of the IP registers and length of memory
- mapped region.
- - interrupts : HDMI CEC interrupt number to the CPU.
- - clocks : from common clock binding: handle to HDMI CEC clock.
- - clock-names : from common clock binding: must contain "cec",
- corresponding to the entry in the clocks property.
- - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
-
-Example:
-
-cec@70015000 {
- compatible = "nvidia,tegra124-cec";
- reg = <0x0 0x70015000 0x0 0x00001000>;
- interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA124_CLK_CEC>;
- clock-names = "cec";
-};
diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml
index 7e078424ca4d..f1a940a110d2 100644
--- a/Documentation/devicetree/bindings/media/ti,cal.yaml
+++ b/Documentation/devicetree/bindings/media/ti,cal.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/ti,cal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL) Device Tree Bindings
+title: Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
maintainers:
- Benoit Parrot <bparrot@ti.com>
@@ -47,7 +47,7 @@ properties:
maxItems: 1
ti,camerrx-control:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to device control module
@@ -75,7 +75,7 @@ properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
- description: CSI2 Port #0
+ description: 'CSI2 Port #0'
properties:
endpoint:
@@ -93,7 +93,7 @@ properties:
port@1:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
- description: CSI2 Port #1
+ description: 'CSI2 Port #1'
properties:
endpoint:
diff --git a/Documentation/devicetree/bindings/media/ti,j721e-csi2rx-shim.yaml b/Documentation/devicetree/bindings/media/ti,j721e-csi2rx-shim.yaml
new file mode 100644
index 000000000000..b9f033f2f3ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,j721e-csi2rx-shim.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/ti,j721e-csi2rx-shim.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI J721E CSI2RX Shim
+
+description: |
+ The TI J721E CSI2RX Shim is a wrapper around Cadence CSI2RX bridge that
+ enables sending captured frames to memory over PSI-L DMA. In the J721E
+ Technical Reference Manual (SPRUIL1B) it is referred to as "SHIM" under the
+ CSI_RX_IF section.
+
+maintainers:
+ - Jai Luthra <jai.luthra@linux.dev>
+
+properties:
+ compatible:
+ const: ti,j721e-csi2rx-shim
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: rx0
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ranges: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+patternProperties:
+ "^csi-bridge@":
+ type: object
+ description: CSI2 bridge node.
+ $ref: cdns,csi2rx.yaml#
+
+required:
+ - compatible
+ - reg
+ - dmas
+ - dma-names
+ - power-domains
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+ ti_csi2rx0: ticsi2rx@4500000 {
+ compatible = "ti,j721e-csi2rx-shim";
+ dmas = <&main_udmap 0x4940>;
+ dma-names = "rx0";
+ reg = <0x4500000 0x1000>;
+ power-domains = <&k3_pds 26 TI_SCI_PD_EXCLUSIVE>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ cdns_csi2rx: csi-bridge@4504000 {
+ compatible = "ti,j721e-csi2rx", "cdns,csi2rx";
+ reg = <0x4504000 0x1000>;
+ clocks = <&k3_clks 26 2>, <&k3_clks 26 0>, <&k3_clks 26 2>,
+ <&k3_clks 26 2>, <&k3_clks 26 3>, <&k3_clks 26 3>;
+ clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ phys = <&dphy0>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi2_0: port@0 {
+
+ reg = <0>;
+
+ csi2rx0_in_sensor: endpoint {
+ remote-endpoint = <&csi2_cam0>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/ti,vpe.yaml b/Documentation/devicetree/bindings/media/ti,vpe.yaml
index ef473f287399..7fa8a367ed22 100644
--- a/Documentation/devicetree/bindings/media/ti,vpe.yaml
+++ b/Documentation/devicetree/bindings/media/ti,vpe.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/ti,vpe.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments DRA7x Video Processing Engine (VPE) Device Tree Bindings
+title: Texas Instruments DRA7x Video Processing Engine (VPE)
maintainers:
- Benoit Parrot <bparrot@ti.com>
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
index 4527f56a5a6e..a81d2a155fe6 100644
--- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/video-interface-devices.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common bindings for video receiver and transmitter devices
+title: Common Properties for Video Receiver and Transmitter Devices
maintainers:
- Jacopo Mondi <jacopo@jmondi.org>
@@ -17,6 +17,14 @@ properties:
An array of phandles, each referring to a flash LED, a sub-node of the LED
driver device node.
+ leds:
+ minItems: 1
+ maxItems: 1
+
+ led-names:
+ enum:
+ - privacy
+
lens-focus:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -120,7 +128,6 @@ properties:
0 degrees camera rotation:
-
Y-Rp
^
Y-Rc !
@@ -137,7 +144,6 @@ properties:
0 +------------------------------------->
0 X-Rc
-
X-Rc 0
<------------------------------------+ 0
X-Rp 0 !
@@ -220,7 +226,6 @@ properties:
V
X-Rc
-
Example one - Webcam
A camera module installed on the user facing part of a laptop screen
@@ -265,7 +270,6 @@ properties:
optical inversion, the two reference systems will not be aligned, with
'Rp' being rotated 180 degrees relatively to 'Rc':
-
X-Rc 0
<------------------------------------+ 0
!
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml
index 68c3b9871cf3..6ed4695cacf7 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.yaml
+++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common bindings for video receiver and transmitter interface endpoints
+title: Common Properties for Video Receiver and Transmitter Interface Endpoints
maintainers:
- Sakari Ailus <sakari.ailus@linux.intel.com>
@@ -95,7 +95,7 @@ properties:
- 6 # BT.656
- 7 # DPI
description:
- Data bus type.
+ Data bus type. See include/dt-bindings/media/video-interfaces.h.
bus-width:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -145,9 +145,10 @@ properties:
pclk-sample:
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
+ enum: [ 0, 1, 2 ]
description:
- Sample data on rising (1) or falling (0) edge of the pixel clock signal.
+ Sample data on falling (0), rising (1) or both (2) edges of the pixel
+ clock signal.
sync-on-green-active:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -159,6 +160,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
+ uniqueItems: true
items:
# Assume up to 9 physical lane indices
maximum: 8
@@ -208,6 +210,27 @@ properties:
lane-polarities property is omitted, the value must be interpreted as 0
(normal). This property is valid for serial busses only.
+ line-orders:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ items:
+ enum:
+ - 0 # ABC
+ - 1 # ACB
+ - 2 # BAC
+ - 3 # BCA
+ - 4 # CAB
+ - 5 # CBA
+ description:
+ An array of line orders of the CSI-2 C-PHY data lanes. The order of the
+ lanes are the same as in data-lanes property. Valid values are 0-5 as
+ defined in the MIPI Discovery and Configuration (DisCo) Specification for
+ Imaging. The length of the array must be the same length as the
+ data-lanes property. If the line-orders property is omitted, the value
+ shall be interpreted as 0 (ABC). This property is valid for CSI-2 C-PHY
+ busses only. See include/dt-bindings/media/video-interfaces.h.
+
strobe:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1 ]
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
index 7d77823dbb7a..43daf837fc9f 100644
--- a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx MIPI CSI-2 Receiver Subsystem
maintainers:
- - Vishal Sagar <vishal.sagar@xilinx.com>
+ - Vishal Sagar <vishal.sagar@amd.com>
description: |
The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2
diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt
deleted file mode 100644
index 22b77ee02f58..000000000000
--- a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-* Device tree bindings for ARM PL172/PL175/PL176 MultiPort Memory Controller
-
-Required properties:
-
-- compatible: Must be "arm,primecell" and exactly one from
- "arm,pl172", "arm,pl175" or "arm,pl176".
-
-- reg: Must contains offset/length value for controller.
-
-- #address-cells: Must be 2. The partition number has to be encoded in the
- first address cell and it may accept values 0..N-1
- (N - total number of partitions). The second cell is the
- offset into the partition.
-
-- #size-cells: Must be set to 1.
-
-- ranges: Must contain one or more chip select memory regions.
-
-- clocks: Must contain references to controller clocks.
-
-- clock-names: Must contain "mpmcclk" and "apb_pclk".
-
-- clock-ranges: Empty property indicating that child nodes can inherit
- named clocks. Required only if clock tree data present
- in device tree.
- See clock-bindings.txt
-
-Child chip-select (cs) nodes contain the memory devices nodes connected to
-such as NOR (e.g. cfi-flash) and NAND.
-
-Required child cs node properties:
-
-- #address-cells: Must be 2.
-
-- #size-cells: Must be 1.
-
-- ranges: Empty property indicating that child nodes can inherit
- memory layout.
-
-- clock-ranges: Empty property indicating that child nodes can inherit
- named clocks. Required only if clock tree data present
- in device tree.
-
-- mpmc,cs: Chip select number. Indicates to the pl0172 driver
- which chipselect is used for accessing the memory.
-
-- mpmc,memory-width: Width of the chip select memory. Must be equal to
- either 8, 16 or 32.
-
-Optional child cs node config properties:
-
-- mpmc,async-page-mode: Enable asynchronous page mode.
-
-- mpmc,cs-active-high: Set chip select polarity to active high.
-
-- mpmc,byte-lane-low: Set byte lane state to low.
-
-- mpmc,extended-wait: Enable extended wait.
-
-- mpmc,buffer-enable: Enable write buffer, option is not supported by
- PL175 and PL176 controllers.
-
-- mpmc,write-protect: Enable write protect.
-
-Optional child cs node timing properties:
-
-- mpmc,write-enable-delay: Delay from chip select assertion to write
- enable (WE signal) in nano seconds.
-
-- mpmc,output-enable-delay: Delay from chip select assertion to output
- enable (OE signal) in nano seconds.
-
-- mpmc,write-access-delay: Delay from chip select assertion to write
- access in nano seconds.
-
-- mpmc,read-access-delay: Delay from chip select assertion to read
- access in nano seconds.
-
-- mpmc,page-mode-read-delay: Delay for asynchronous page mode sequential
- accesses in nano seconds.
-
-- mpmc,turn-round-delay: Delay between access to memory banks in nano
- seconds.
-
-If any of the above timing parameters are absent, current parameter value will
-be taken from the corresponding HW reg.
-
-Example for pl172 with nor flash on chip select 0 shown below.
-
-emc: memory-controller@40005000 {
- compatible = "arm,pl172", "arm,primecell";
- reg = <0x40005000 0x1000>;
- clocks = <&ccu1 CLK_CPU_EMCDIV>, <&ccu1 CLK_CPU_EMC>;
- clock-names = "mpmcclk", "apb_pclk";
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <0 0 0x1c000000 0x1000000
- 1 0 0x1d000000 0x1000000
- 2 0 0x1e000000 0x1000000
- 3 0 0x1f000000 0x1000000>;
-
- cs0 {
- #address-cells = <2>;
- #size-cells = <1>;
- ranges;
-
- mpmc,cs = <0>;
- mpmc,memory-width = <16>;
- mpmc,byte-lane-low;
- mpmc,write-enable-delay = <0>;
- mpmc,output-enable-delay = <0>;
- mpmc,read-enable-delay = <70>;
- mpmc,page-mode-read-delay = <70>;
-
- flash@0,0 {
- compatible = "sst,sst39vf320", "cfi-flash";
- reg = <0 0 0x400000>;
- bank-width = <2>;
- #address-cells = <1>;
- #size-cells = <1>;
- partition@0 {
- label = "data";
- reg = <0 0x400000>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.yaml
new file mode 100644
index 000000000000..c1b702669bd9
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.yaml
@@ -0,0 +1,222 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/arm,pl172.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM PL172/PL175/PL176 MultiPort Memory Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+# We need a select here so we don't match all nodes with 'arm,primecell'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - arm,pl172
+ - arm,pl175
+ - arm,pl176
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - arm,pl172
+ - arm,pl175
+ - arm,pl176
+ - const: arm,primecell
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: mpmcclk
+ - const: apb_pclk
+
+ clock-ranges: true
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ "^cs[0-9]$":
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^flash@[0-9],[0-9a-f]+$":
+ type: object
+ $ref: /schemas/mtd/mtd-physmap.yaml#
+ unevaluatedProperties: false
+
+ "^(gpio|sram)@[0-9],[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
+
+ clocks:
+ maxItems: 2
+
+ clock-ranges: true
+
+ mpmc,cs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Chip select number. Indicates to the pl0172 driver
+ which chipselect is used for accessing the memory.
+
+ mpmc,memory-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16, 32]
+ description:
+ Width of the chip select memory. Must be equal to either 8, 16 or 32.
+
+ mpmc,async-page-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable asynchronous page mode.
+
+ mpmc,cs-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Set chip select polarity to active high.
+
+ mpmc,byte-lane-low:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Set byte lane state to low.
+
+ mpmc,extended-wait:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable extended wait.
+
+ mpmc,buffer-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable write buffer, option is not supported by
+ PL175 and PL176 controllers.
+
+ mpmc,write-protect:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable write protect.
+
+ mpmc,read-enable-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay from chip select assertion to read
+ enable (RE signal) in nano seconds.
+
+ mpmc,write-enable-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay from chip select assertion to write
+ enable (WE signal) in nano seconds.
+
+ mpmc,output-enable-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay from chip select assertion to output
+ enable (OE signal) in nano seconds.
+
+ mpmc,write-access-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay from chip select assertion to write
+ access in nano seconds.
+
+ mpmc,read-access-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay from chip select assertion to read
+ access in nano seconds.
+
+ mpmc,page-mode-read-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay for asynchronous page mode sequential
+ accesses in nano seconds.
+
+ mpmc,turn-round-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay between access to memory banks in nano
+ seconds.
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ memory-controller@40005000 {
+ compatible = "arm,pl172", "arm,primecell";
+ reg = <0x40005000 0x1000>;
+ clocks = <&ccu1 CLK_CPU_EMCDIV>, <&ccu1 CLK_CPU_EMC>;
+ clock-names = "mpmcclk", "apb_pclk";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x1c000000 0x1000000
+ 1 0 0x1d000000 0x1000000
+ 2 0 0x1e000000 0x1000000
+ 3 0 0x1f000000 0x1000000>;
+
+ cs0 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+
+ mpmc,cs = <0>;
+ mpmc,memory-width = <16>;
+ mpmc,byte-lane-low;
+ mpmc,write-enable-delay = <0>;
+ mpmc,output-enable-delay = <0>;
+ mpmc,read-enable-delay = <70>;
+ mpmc,page-mode-read-delay = <70>;
+
+ flash@0,0 {
+ compatible = "sst,sst39vf320", "cfi-flash";
+ reg = <0 0 0x400000>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "data";
+ reg = <0 0x400000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
deleted file mode 100644
index 01c9acf9275d..000000000000
--- a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml
+++ /dev/null
@@ -1,130 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/memory-controllers/arm,pl353-smc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: ARM PL353 Static Memory Controller (SMC) device-tree bindings
-
-maintainers:
- - Miquel Raynal <miquel.raynal@bootlin.com>
- - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
-
-description:
- The PL353 Static Memory Controller is a bus where you can connect two kinds
- of memory interfaces, which are NAND and memory mapped interfaces (such as
- SRAM or NOR).
-
-# We need a select here so we don't match all nodes with 'arm,primecell'
-select:
- properties:
- compatible:
- contains:
- const: arm,pl353-smc-r2p1
- required:
- - compatible
-
-properties:
- $nodename:
- pattern: "^memory-controller@[0-9a-f]+$"
-
- compatible:
- items:
- - const: arm,pl353-smc-r2p1
- - const: arm,primecell
-
- "#address-cells":
- const: 2
-
- "#size-cells":
- const: 1
-
- reg:
- items:
- - description:
- Configuration registers for the host and sub-controllers.
- The three chip select regions are defined in 'ranges'.
-
- clocks:
- items:
- - description: clock for the memory device bus
- - description: main clock of the SMC
-
- clock-names:
- items:
- - const: memclk
- - const: apb_pclk
-
- ranges:
- minItems: 1
- description: |
- Memory bus areas for interacting with the devices. Reflects
- the memory layout with four integer values following:
- <cs-number> 0 <offset> <size>
- items:
- - description: NAND bank 0
- - description: NOR/SRAM bank 0
- - description: NOR/SRAM bank 1
-
- interrupts: true
-
-patternProperties:
- "@[0-3],[a-f0-9]+$":
- type: object
- description: |
- The child device node represents the controller connected to the SMC
- bus. The controller can be a NAND controller or a pair of any memory
- mapped controllers such as NOR and SRAM controllers.
-
- properties:
- compatible:
- description:
- Compatible of memory controller.
-
- reg:
- items:
- - items:
- - description: |
- Chip-select ID, as in the parent range property.
- minimum: 0
- maximum: 2
- - description: |
- Offset of the memory region requested by the device.
- - description: |
- Length of the memory region requested by the device.
-
- required:
- - compatible
- - reg
-
-required:
- - compatible
- - reg
- - clock-names
- - clocks
- - "#address-cells"
- - "#size-cells"
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- smcc: memory-controller@e000e000 {
- compatible = "arm,pl353-smc-r2p1", "arm,primecell";
- reg = <0xe000e000 0x0001000>;
- clock-names = "memclk", "apb_pclk";
- clocks = <&clkc 11>, <&clkc 44>;
- ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */
- 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */
- 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */
- #address-cells = <2>;
- #size-cells = <1>;
-
- nfc0: nand-controller@0,0 {
- compatible = "arm,pl353-nand-r2p1";
- reg = <0 0 0x1000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml
new file mode 100644
index 000000000000..05dd6b3a1a3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/arm,pl35x-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm PL35x Series Static Memory Controller (SMC)
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: |
+ The PL35x Static Memory Controller is a bus where you can connect two kinds
+ of memory interfaces, which are NAND and memory mapped interfaces (such as
+ SRAM or NOR) depending on the specific configuration.
+
+ The TRM is available here:
+ https://documentation-service.arm.com/static/5e8e2524fd977155116a58aa
+
+# We need a select here so we don't match all nodes with 'arm,primecell'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - arm,pl353-smc-r2p1
+ - arm,pl354
+ required:
+ - compatible
+
+properties:
+ $nodename:
+ pattern: "^memory-controller@[0-9a-f]+$"
+
+ compatible:
+ items:
+ - enum:
+ - arm,pl353-smc-r2p1
+ - arm,pl354
+ - const: arm,primecell
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 1
+
+ reg:
+ items:
+ - description:
+ Configuration registers for the host and sub-controllers.
+ The three chip select regions are defined in 'ranges'.
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ ranges:
+ minItems: 1
+ maxItems: 8
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Combined or Memory interface 0 IRQ
+ - description: Memory interface 1 IRQ
+
+patternProperties:
+ "@[0-7],[a-f0-9]+$":
+ type: object
+ additionalProperties: true
+ description: |
+ The child device node represents the controller connected to the SMC
+ bus. The controller can be a NAND controller or a pair of any memory
+ mapped controllers such as NOR and SRAM controllers.
+
+ properties:
+ compatible:
+ description:
+ Compatible of memory controller.
+
+ reg:
+ items:
+ - items:
+ - description: |
+ Chip-select ID, as in the parent range property.
+ minimum: 0
+ maximum: 7
+ - description: |
+ Offset of the memory region requested by the device.
+ - description: |
+ Length of the memory region requested by the device.
+
+ required:
+ - compatible
+ - reg
+
+required:
+ - compatible
+ - reg
+ - clock-names
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,pl354
+ then:
+ properties:
+ clocks:
+ # According to TRM, really should be 3 clocks
+ maxItems: 1
+
+ clock-names:
+ const: apb_pclk
+
+ else:
+ properties:
+ clocks:
+ items:
+ - description: clock for the memory device bus
+ - description: main clock of the SMC
+
+ clock-names:
+ items:
+ - const: memclk
+ - const: apb_pclk
+
+examples:
+ - |
+ smcc: memory-controller@e000e000 {
+ compatible = "arm,pl353-smc-r2p1", "arm,primecell";
+ reg = <0xe000e000 0x0001000>;
+ clock-names = "memclk", "apb_pclk";
+ clocks = <&clkc 11>, <&clkc 44>;
+ ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */
+ 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */
+ 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ nfc0: nand-controller@0,0 {
+ compatible = "arm,pl353-nand-r2p1";
+ reg = <0 0 0x1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,brcmstb-memc-ddr.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,brcmstb-memc-ddr.yaml
index 4b072c879b02..3328c8df8190 100644
--- a/Documentation/devicetree/bindings/memory-controllers/brcm,brcmstb-memc-ddr.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/brcm,brcmstb-memc-ddr.yaml
@@ -11,25 +11,41 @@ maintainers:
properties:
compatible:
- items:
- - enum:
- - brcm,brcmstb-memc-ddr-rev-b.1.x
- - brcm,brcmstb-memc-ddr-rev-b.2.0
- - brcm,brcmstb-memc-ddr-rev-b.2.1
- - brcm,brcmstb-memc-ddr-rev-b.2.2
- - brcm,brcmstb-memc-ddr-rev-b.2.3
- - brcm,brcmstb-memc-ddr-rev-b.2.5
- - brcm,brcmstb-memc-ddr-rev-b.2.6
- - brcm,brcmstb-memc-ddr-rev-b.2.7
- - brcm,brcmstb-memc-ddr-rev-b.2.8
- - brcm,brcmstb-memc-ddr-rev-b.3.0
- - brcm,brcmstb-memc-ddr-rev-b.3.1
- - brcm,brcmstb-memc-ddr-rev-c.1.0
- - brcm,brcmstb-memc-ddr-rev-c.1.1
- - brcm,brcmstb-memc-ddr-rev-c.1.2
- - brcm,brcmstb-memc-ddr-rev-c.1.3
- - brcm,brcmstb-memc-ddr-rev-c.1.4
- - const: brcm,brcmstb-memc-ddr
+ oneOf:
+ - description: Revision > 2.1 controllers
+ items:
+ - enum:
+ - brcm,brcmstb-memc-ddr-rev-b.2.2
+ - brcm,brcmstb-memc-ddr-rev-b.2.3
+ - brcm,brcmstb-memc-ddr-rev-b.2.5
+ - brcm,brcmstb-memc-ddr-rev-b.2.6
+ - brcm,brcmstb-memc-ddr-rev-b.2.7
+ - brcm,brcmstb-memc-ddr-rev-b.2.8
+ - brcm,brcmstb-memc-ddr-rev-b.3.0
+ - brcm,brcmstb-memc-ddr-rev-b.3.1
+ - brcm,brcmstb-memc-ddr-rev-c.1.0
+ - brcm,brcmstb-memc-ddr-rev-c.1.1
+ - brcm,brcmstb-memc-ddr-rev-c.1.2
+ - brcm,brcmstb-memc-ddr-rev-c.1.3
+ - brcm,brcmstb-memc-ddr-rev-c.1.4
+ - const: brcm,brcmstb-memc-ddr-rev-b.2.1
+ - const: brcm,brcmstb-memc-ddr
+ - description: Revision 2.1 controllers
+ items:
+ - const: brcm,brcmstb-memc-ddr-rev-b.2.1
+ - const: brcm,brcmstb-memc-ddr
+ - description: Revision 2.0 controllers
+ items:
+ - const: brcm,brcmstb-memc-ddr-rev-b.2.0
+ - const: brcm,brcmstb-memc-ddr
+ - description: Revision 1.x controllers
+ items:
+ - const: brcm,brcmstb-memc-ddr-rev-b.1.x
+ - const: brcm,brcmstb-memc-ddr
+ - description: Revision 0.x controllers
+ items:
+ - const: brcm,brcmstb-memc-ddr-rev-a.0.0
+ - const: brcm,brcmstb-memc-ddr
reg:
maxItems: 1
@@ -46,7 +62,9 @@ additionalProperties: false
examples:
- |
memory-controller@9902000 {
- compatible = "brcm,brcmstb-memc-ddr-rev-c.1.1", "brcm,brcmstb-memc-ddr";
+ compatible = "brcm,brcmstb-memc-ddr-rev-c.1.1",
+ "brcm,brcmstb-memc-ddr-rev-b.2.1",
+ "brcm,brcmstb-memc-ddr";
reg = <0x9902000 0x600>;
clock-frequency = <2133000000>;
};
diff --git a/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml
index 96d563fd61f5..e42aa488704d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/memory-controllers/calxeda-ddr-ctrlr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Calxeda DDR memory controller binding
+title: Calxeda DDR memory controller
description: |
The Calxeda DDR memory controller is initialised and programmed by the
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
new file mode 100644
index 000000000000..34b5bd153f63
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-channel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LPDDR channel with chip/rank topology description
+
+description:
+ An LPDDR channel is a completely independent set of LPDDR pins (DQ, CA, CS,
+ CK, etc.) that connect one or more LPDDR chips to a host system. The main
+ purpose of this node is to overall LPDDR topology of the system, including the
+ amount of individual LPDDR chips and the ranks per chip.
+
+maintainers:
+ - Julius Werner <jwerner@chromium.org>
+
+properties:
+ compatible:
+ enum:
+ - jedec,lpddr2-channel
+ - jedec,lpddr3-channel
+ - jedec,lpddr4-channel
+ - jedec,lpddr5-channel
+
+ io-width:
+ description:
+ The number of DQ pins in the channel. If this number is different
+ from (a multiple of) the io-width of the LPDDR chip, that means that
+ multiple instances of that type of chip are wired in parallel on this
+ channel (with the channel's DQ pins split up between the different
+ chips, and the CA, CS, etc. pins of the different chips all shorted
+ together). This means that the total physical memory controlled by a
+ channel is equal to the sum of the densities of each rank on the
+ connected LPDDR chip, times the io-width of the channel divided by
+ the io-width of the LPDDR chip.
+ enum:
+ - 8
+ - 16
+ - 32
+ - 64
+ - 128
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^rank@[0-9]+$":
+ type: object
+ description:
+ Each physical LPDDR chip may have one or more ranks. Ranks are
+ internal but fully independent sub-units of the chip. Each LPDDR bus
+ transaction on the channel targets exactly one rank, based on the
+ state of the CS pins. Different ranks may have different densities and
+ timing requirements.
+ required:
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: jedec,lpddr2-channel
+ then:
+ patternProperties:
+ "^rank@[0-9]+$":
+ $ref: /schemas/memory-controllers/ddr/jedec,lpddr2.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: jedec,lpddr3-channel
+ then:
+ patternProperties:
+ "^rank@[0-9]+$":
+ $ref: /schemas/memory-controllers/ddr/jedec,lpddr3.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: jedec,lpddr4-channel
+ then:
+ patternProperties:
+ "^rank@[0-9]+$":
+ $ref: /schemas/memory-controllers/ddr/jedec,lpddr4.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: jedec,lpddr5-channel
+ then:
+ patternProperties:
+ "^rank@[0-9]+$":
+ $ref: /schemas/memory-controllers/ddr/jedec,lpddr5.yaml#
+
+required:
+ - compatible
+ - io-width
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ lpddr-channel0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "jedec,lpddr3-channel";
+ io-width = <32>;
+
+ rank@0 {
+ compatible = "lpddr3-ff,0100", "jedec,lpddr3";
+ reg = <0>;
+ density = <8192>;
+ io-width = <16>;
+ revision-id = <1 0>;
+ };
+ };
+
+ lpddr-channel1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "jedec,lpddr4-channel";
+ io-width = <32>;
+
+ rank@0 {
+ compatible = "lpddr4-05,0301", "jedec,lpddr4";
+ reg = <0>;
+ density = <4096>;
+ io-width = <32>;
+ revision-id = <3 1>;
+ };
+
+ rank@1 {
+ compatible = "lpddr4-05,0301", "jedec,lpddr4";
+ reg = <1>;
+ density = <2048>;
+ io-width = <32>;
+ revision-id = <3 1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml
new file mode 100644
index 000000000000..30267ce70124
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for LPDDR types
+
+description:
+ Different LPDDR types generally use the same properties and only differ in the
+ range of legal values for each. This file defines the common parts that can be
+ reused for each type. Nodes using this schema should generally be nested under
+ an LPDDR channel node.
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ description:
+ Compatible strings can be either explicit vendor names and part numbers
+ (e.g. elpida,ECB240ABACN), or generated strings of the form
+ lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID
+ (from MR5) and ZZZZ is the revision ID (from MR6 and MR7). Both IDs are
+ formatted in lower case hexadecimal representation with leading zeroes.
+ The latter form can be useful when LPDDR nodes are created at runtime by
+ boot firmware that doesn't have access to static part number information.
+
+ reg:
+ description:
+ The rank number of this LPDDR rank when used as a subnode to an LPDDR
+ channel.
+ minimum: 0
+ maximum: 3
+
+ revision-id:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 255
+
+ density:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Density in megabits of SDRAM chip. Decoded from Mode Register 8.
+ enum:
+ - 64
+ - 128
+ - 256
+ - 512
+ - 1024
+ - 2048
+ - 3072
+ - 4096
+ - 6144
+ - 8192
+ - 12288
+ - 16384
+ - 24576
+ - 32768
+
+ io-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ IO bus width in bits of SDRAM chip. Decoded from Mode Register 8.
+ enum:
+ - 8
+ - 16
+ - 32
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
index 9d78f140609b..a237bc259273 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
@@ -9,6 +9,9 @@ title: LPDDR2 SDRAM compliant to JEDEC JESD209-2
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
+allOf:
+ - $ref: jedec,lpddr-props.yaml#
+
properties:
compatible:
oneOf:
@@ -17,13 +20,15 @@ properties:
- elpida,ECB240ABACN
- elpida,B8132B2PB-6D-F
- enum:
- - jedec,lpddr2-s4
- - items:
- - enum:
+ - jedec,lpddr2-nvm
- jedec,lpddr2-s2
+ - jedec,lpddr2-s4
- items:
+ - pattern: "^lpddr2-[0-9a-f]{2},[0-9a-f]{4}$"
- enum:
- jedec,lpddr2-nvm
+ - jedec,lpddr2-s2
+ - jedec,lpddr2-s4
revision-id1:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -41,41 +46,6 @@ properties:
Property is deprecated, use revision-id instead.
deprecated: true
- revision-id:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: |
- Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
- minItems: 2
- maxItems: 2
- items:
- minimum: 0
- maximum: 255
-
- density:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- Density in megabits of SDRAM chip. Obtained from device datasheet.
- enum:
- - 64
- - 128
- - 256
- - 512
- - 1024
- - 2048
- - 4096
- - 8192
- - 16384
- - 32768
-
- io-width:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- IO bus width in bits of SDRAM chip. Obtained from device datasheet.
- enum:
- - 32
- - 16
- - 8
-
tRRD-min-tck:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 16
@@ -168,7 +138,7 @@ required:
- density
- io-width
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml
index 48908a19473c..e328a1195ba6 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml
@@ -9,35 +9,24 @@ title: LPDDR3 SDRAM compliant to JEDEC JESD209-3
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
+allOf:
+ - $ref: jedec,lpddr-props.yaml#
+
properties:
compatible:
- items:
- - enum:
- - samsung,K3QF2F20DB
- - const: jedec,lpddr3
+ oneOf:
+ - items:
+ - enum:
+ - samsung,K3QF2F20DB
+ - const: jedec,lpddr3
+ - items:
+ - pattern: "^lpddr3-[0-9a-f]{2},[0-9a-f]{4}$"
+ - const: jedec,lpddr3
'#address-cells':
const: 1
deprecated: true
- density:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- Density in megabits of SDRAM chip.
- enum:
- - 4096
- - 8192
- - 16384
- - 32768
-
- io-width:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- IO bus width in bits of SDRAM chip.
- enum:
- - 32
- - 16
-
manufacturer-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -45,15 +34,6 @@ properties:
deprecated, manufacturer should be derived from the compatible.
deprecated: true
- revision-id:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 2
- maxItems: 2
- items:
- maximum: 255
- description: |
- Revision value of SDRAM chip read from Mode Registers 6 and 7.
-
'#size-cells':
const: 0
deprecated: true
@@ -206,7 +186,7 @@ required:
- density
- io-width
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
new file mode 100644
index 000000000000..a078892fecee
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LPDDR4 SDRAM compliant to JEDEC JESD209-4
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+allOf:
+ - $ref: jedec,lpddr-props.yaml#
+
+properties:
+ compatible:
+ items:
+ - pattern: "^lpddr4-[0-9a-f]{2},[0-9a-f]{4}$"
+ - const: jedec,lpddr4
+
+required:
+ - compatible
+ - density
+ - io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ lpddr {
+ compatible = "lpddr4-ff,0100", "jedec,lpddr4";
+ density = <8192>;
+ io-width = <16>;
+ revision-id = <1 0>;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml
new file mode 100644
index 000000000000..e441dac5f154
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LPDDR5 SDRAM compliant to JEDEC JESD209-5
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+allOf:
+ - $ref: jedec,lpddr-props.yaml#
+
+properties:
+ compatible:
+ items:
+ - pattern: "^lpddr5-[0-9a-f]{2},[0-9a-f]{4}$"
+ - const: jedec,lpddr5
+
+ serial-id:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Serial IDs read from Mode Registers 47 through 54. One byte per uint32
+ cell (i.e. <MR47 MR48 MR49 MR50 MR51 MR52 MR53 MR54>).
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 255
+
+required:
+ - compatible
+ - density
+ - io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ lpddr {
+ compatible = "lpddr5-01,0200", "jedec,lpddr5";
+ density = <8192>;
+ io-width = <8>;
+ revision-id = <2 0>;
+ serial-id = <3 1 0 0 0 0 0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
index c6e44f47ce7c..1578514ec58d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml
@@ -38,50 +38,16 @@ properties:
patternProperties:
"^.*@[0-3],[a-f0-9]+$":
type: object
- description:
- The actual device nodes should be added as subnodes to the SROMc node.
- These subnodes, in addition to regular device specification, should
- contain the following properties, describing configuration
- of the relevant SROM bank.
+ $ref: mc-peripheral-props.yaml#
+ additionalProperties: true
properties:
- reg:
- description:
- Bank number, base address (relative to start of the bank) and size
- of the memory mapped for the device. Note that base address will be
- typically 0 as this is the start of the bank.
- maxItems: 1
-
reg-io-width:
enum: [1, 2]
description:
Data width in bytes (1 or 2). If omitted, default of 1 is used.
- samsung,srom-page-mode:
- description:
- If page mode is set, 4 data page mode will be configured,
- else normal (1 data) page mode will be set.
- type: boolean
-
- samsung,srom-timing:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- minItems: 6
- maxItems: 6
- description: |
- Array of 6 integers, specifying bank timings in the following order:
- Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
- Each value is specified in cycles and has the following meaning
- and valid range:
- Tacp: Page mode access cycle at Page mode (0 - 15)
- Tcah: Address holding time after CSn (0 - 15)
- Tcoh: Chip selection hold on OEn (0 - 15)
- Tacc: Access cycle (0 - 31, the actual time is N + 1)
- Tcos: Chip selection set-up before OEn (0 - 15)
- Tacs: Address set-up before CSn (0 - 15)
-
required:
- - reg
- samsung,srom-timing
required:
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml
index 84f778a99546..e0786153eec7 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ddr.yaml
@@ -40,6 +40,7 @@ properties:
- fsl,p1021-memory-controller
- fsl,p2020-memory-controller
- fsl,qoriq-memory-controller
+ - nxp,imx9-memory-controller
interrupts:
maxItems: 1
@@ -51,13 +52,41 @@ properties:
type: boolean
reg:
- maxItems: 1
+ items:
+ - description: Controller register space
+ - description: Inject register space
+ minItems: 1
+
+ reg-names:
+ items:
+ - const: ctrl
+ - const: inject
+ minItems: 1
required:
- compatible
- interrupts
- reg
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,imx9-memory-controller
+ then:
+ properties:
+ reg:
+ minItems: 2
+ reg-names:
+ minItems: 2
+ else:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml
index 3be1db30bf41..f7cf0f91c1c0 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: FSL/NXP Integrated Flash Controller
maintainers:
- - Li Yang <leoyang.li@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
description: |
NXP's integrated flash controller (IFC) is an advanced version of the
@@ -58,17 +58,39 @@ properties:
access window as configured.
patternProperties:
- "^.*@[a-f0-9]+(,[a-f0-9]+)+$":
+ "^nand@[a-f0-9]+(,[a-f0-9]+)+$":
type: object
- description: |
- Child device nodes describe the devices connected to IFC such as NOR (e.g.
- cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
- like FPGAs, CPLDs, etc.
+ properties:
+ compatible:
+ const: fsl,ifc-nand
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ patternProperties:
+ "^partition@[0-9a-f]+":
+ $ref: /schemas/mtd/partitions/partition.yaml#
+ deprecated: true
required:
- compatible
- reg
+ additionalProperties: false
+
+ "(flash|fpga|board-control|cpld)@[a-f0-9]+(,[a-f0-9]+)+$":
+ type: object
+ oneOf:
+ - $ref: /schemas/board/fsl,fpga-qixis.yaml#
+ - $ref: /schemas/mtd/mtd-physmap.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml
new file mode 100644
index 000000000000..82fc5f4a1ed6
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX WEIM Bus Peripheral Nodes
+
+maintainers:
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+description:
+ This binding is meant for the child nodes of the WEIM node. The node
+ represents any device connected to the WEIM bus. It may be a Flash chip,
+ RAM chip or Ethernet controller, etc. These properties are meant for
+ configuring the WEIM settings/timings and will accompany the bindings
+ supported by the respective device.
+
+properties:
+ reg: true
+
+ fsl,weim-cs-timing:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Timing values for the child node.
+ minItems: 2
+ maxItems: 6
+
+# the WEIM child will have its own native properties
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim.yaml
new file mode 100644
index 000000000000..ce4ec94a561c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim.yaml
@@ -0,0 +1,201 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,imx-weim.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX Wireless External Interface Module (WEIM)
+
+maintainers:
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+description:
+ The term "wireless" does not imply that the WEIM is literally an interface
+ without wires. It simply means that this module was originally designed for
+ wireless and mobile applications that use low-power technology. The actual
+ devices are instantiated from the child nodes of a WEIM node.
+
+properties:
+ $nodename:
+ pattern: "^memory-controller@[0-9a-f]+$"
+
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx1-weim
+ - fsl,imx27-weim
+ - fsl,imx50-weim
+ - fsl,imx51-weim
+ - fsl,imx6q-weim
+ - items:
+ - enum:
+ - fsl,imx31-weim
+ - fsl,imx35-weim
+ - const: fsl,imx27-weim
+ - items:
+ - enum:
+ - fsl,imx6sx-weim
+ - fsl,imx6ul-weim
+ - const: fsl,imx6q-weim
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ranges: true
+
+ fsl,weim-cs-gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Phandle to the system General Purpose Register controller that contains
+ WEIM CS GPR register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0]
+ should be set up as one of the following 4 possible values depending on
+ the CS space configuration.
+
+ IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3
+ ---------------------------------------------
+ 05 128M 0M 0M 0M
+ 033 64M 64M 0M 0M
+ 0113 64M 32M 32M 0M
+ 01111 32M 32M 32M 32M
+
+ In case that the property is absent, the reset value or what bootloader
+ sets up in IOMUXC_GPR1[11:0] will be used.
+
+ fsl,burst-clk-enable:
+ type: boolean
+ description:
+ The presence of this property indicates that the weim bus should operate
+ in Burst Clock Mode.
+
+ fsl,continuous-burst-clk:
+ type: boolean
+ description:
+ Make Burst Clock to output continuous clock. Without this option Burst
+ Clock will output clock only when necessary.
+
+patternProperties:
+ "^.*@[0-7],[0-9a-f]+$":
+ type: object
+ description: Devices attached to chip selects are represented as subnodes.
+ $ref: fsl,imx-weim-peripherals.yaml
+ additionalProperties: true
+ required:
+ - fsl,weim-cs-timing
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - fsl,imx50-weim
+ - fsl,imx6q-weim
+ then:
+ properties:
+ fsl,weim-cs-gpr: false
+ fsl,burst-clk-enable: false
+ - if:
+ not:
+ required:
+ - fsl,burst-clk-enable
+ then:
+ properties:
+ fsl,continuous-burst-clk: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx1-weim
+ then:
+ patternProperties:
+ "^.*@[0-7],[0-9a-f]+$":
+ properties:
+ fsl,weim-cs-timing:
+ items:
+ - description: CSxU
+ - description: CSxL
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx27-weim
+ - fsl,imx31-weim
+ - fsl,imx35-weim
+ then:
+ patternProperties:
+ "^.*@[0-7],[0-9a-f]+$":
+ properties:
+ fsl,weim-cs-timing:
+ items:
+ - description: CSCRxU
+ - description: CSCRxL
+ - description: CSCRxA
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx50-weim
+ - fsl,imx51-weim
+ - fsl,imx6q-weim
+ - fsl,imx6sx-weim
+ - fsl,imx6ul-weim
+ then:
+ patternProperties:
+ "^.*@[0-7],[0-9a-f]+$":
+ properties:
+ fsl,weim-cs-timing:
+ items:
+ - description: CSxGCR1
+ - description: CSxGCR2
+ - description: CSxRCR1
+ - description: CSxRCR2
+ - description: CSxWCR1
+ - description: CSxWCR2
+
+additionalProperties: false
+
+examples:
+ - |
+ memory-controller@21b8000 {
+ compatible = "fsl,imx6q-weim";
+ reg = <0x021b8000 0x4000>;
+ clocks = <&clks 196>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x08000000>;
+ fsl,weim-cs-gpr = <&gpr>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
+ 0x0000c000 0x1404a38e 0x00000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml
index 2b39fce5f650..519b123116dc 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/imx8m-ddrc.yaml
@@ -47,7 +47,8 @@ properties:
- const: apb
operating-points-v2: true
- opp-table: true
+ opp-table:
+ type: object
required:
- reg
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml
index 71547eee9919..5447f1dddedf 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml
@@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Multi Mode DDR controller (MMDC)
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-peripherals.yaml b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-peripherals.yaml
index b8ed52a44d57..89ebe3979012 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-peripherals.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-peripherals.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/memory-controllers/ingenic,nemc-peripherals.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs NAND / External Memory Controller (NEMC) devicetree bindings
+title: Ingenic SoCs NAND / External Memory Controller (NEMC)
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
index dd13a5106d6c..ee74a362f4ca 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/memory-controllers/ingenic,nemc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs NAND / External Memory Controller (NEMC) devicetree bindings
+title: Ingenic SoCs NAND / External Memory Controller (NEMC)
maintainers:
- Paul Cercueil <paul@crapouillou.net>
@@ -39,6 +39,8 @@ properties:
patternProperties:
".*@[0-9]+$":
type: object
+ $ref: mc-peripheral-props.yaml#
+ additionalProperties: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml
new file mode 100644
index 000000000000..3049d6bb0b1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel IXP4xx Expansion Bus Controller
+
+description: |
+ The IXP4xx expansion bus controller handles access to devices on the
+ memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
+ including IXP42x, IXP43x, IXP45x and IXP46x.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ $nodename:
+ pattern: '^bus@[0-9a-f]+$'
+
+ compatible:
+ items:
+ - enum:
+ - intel,ixp42x-expansion-bus-controller
+ - intel,ixp43x-expansion-bus-controller
+ - intel,ixp45x-expansion-bus-controller
+ - intel,ixp46x-expansion-bus-controller
+ - const: syscon
+
+ reg:
+ description: Control registers for the expansion bus, these are not
+ inside the memory range handled by the expansion bus.
+ maxItems: 1
+
+ native-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: The IXP4xx has a peculiar MMIO access scheme, as it changes
+ the access pattern for words (swizzling) on the bus depending on whether
+ the SoC is running in big-endian or little-endian mode. Thus the
+ registers must always be accessed using native endianness.
+
+ "#address-cells":
+ description: |
+ The first cell is the chip select number.
+ The second cell is the address offset within the bank.
+ const: 2
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+ dma-ranges: true
+
+patternProperties:
+ "^.*@[0-7],[0-9a-f]+$":
+ description: Devices attached to chip selects are represented as
+ subnodes.
+ type: object
+ $ref: /schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
+ additionalProperties: true
+
+required:
+ - compatible
+ - reg
+ - native-endian
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - dma-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ bus@50000000 {
+ compatible = "intel,ixp42x-expansion-bus-controller", "syscon";
+ reg = <0xc4000000 0x28>;
+ native-endian;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x50000000 0x01000000>,
+ <1 0x0 0x51000000 0x01000000>;
+ dma-ranges = <0 0x0 0x50000000 0x01000000>,
+ <1 0x0 0x51000000 0x01000000>;
+ flash@0,0 {
+ compatible = "intel,ixp4xx-flash", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 0x00000000 0x1000000>;
+ intel,ixp4xx-eb-t3 = <3>;
+ intel,ixp4xx-eb-cycle-type = <0>;
+ intel,ixp4xx-eb-byte-access-on-halfword = <1>;
+ intel,ixp4xx-eb-write-enable = <1>;
+ intel,ixp4xx-eb-byte-access = <0>;
+ };
+ serial@1,0 {
+ compatible = "exar,xr16l2551", "ns8250";
+ reg = <1 0x00000000 0x10>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <1843200>;
+ intel,ixp4xx-eb-t3 = <3>;
+ intel,ixp4xx-eb-cycle-type = <1>;
+ intel,ixp4xx-eb-write-enable = <1>;
+ intel,ixp4xx-eb-byte-access = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml
new file mode 100644
index 000000000000..d1479a7b9c8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral properties for Intel IXP4xx Expansion Bus
+
+description:
+ The IXP4xx expansion bus controller handles access to devices on the
+ memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
+ including IXP42x, IXP43x, IXP45x and IXP46x.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ intel,ixp4xx-eb-t1:
+ description: Address timing, extend address phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ intel,ixp4xx-eb-t2:
+ description: Setup chip select timing, extend setup phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ intel,ixp4xx-eb-t3:
+ description: Strobe timing, extend strobe phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+
+ intel,ixp4xx-eb-t4:
+ description: Hold timing, extend hold phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+
+ intel,ixp4xx-eb-t5:
+ description: Recovery timing, extend recovery phase with n cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+
+ intel,ixp4xx-eb-cycle-type:
+ description: The type of cycles to use on the expansion bus for this
+ chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ intel,ixp4xx-eb-byte-access-on-halfword:
+ description: Allow byte read access on half word devices.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-hpi-hrdy-pol-high:
+ description: Set HPI HRDY polarity to active high when using HPI.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-mux-address-and-data:
+ description: Multiplex address and data on the data bus.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-ahb-split-transfers:
+ description: Enable AHB split transfers.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-write-enable:
+ description: Enable write cycles.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ intel,ixp4xx-eb-byte-access:
+ description: Expansion bus uses only 8 bits. The default is to use
+ 16 bits.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
new file mode 100644
index 000000000000..73a6dac946b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/mc-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral-specific properties for a Memory Controller bus.
+
+description:
+ Many Memory Controllers need to add properties to peripheral devices.
+ They could be common properties like reg or they could be controller
+ specific like delay in clock or data lines, etc. These properties need
+ to be defined in the peripheral node because they are per-peripheral
+ and there can be multiple peripherals attached to a controller. All
+ those properties are listed here. The controller specific properties
+ should go in their own separate schema that should be referenced
+ from here.
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+properties:
+ reg:
+ description: Bank number, base address and size of the device.
+
+ bank-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Bank width of the device, in bytes.
+ enum: [1, 2, 4]
+
+required:
+ - reg
+
+# The controller specific properties go here.
+allOf:
+ - $ref: st,stm32-fmc2-ebi-props.yaml#
+ - $ref: ingenic,nemc-peripherals.yaml#
+ - $ref: intel,ixp4xx-expansion-peripheral-props.yaml#
+ - $ref: qcom,ebi2-peripheral-props.yaml#
+ - $ref: samsung,exynos4210-srom-peripheral-props.yaml#
+ - $ref: ti,gpmc-child.yaml#
+ - $ref: fsl/fsl,imx-weim-peripherals.yaml
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
index a8fda30cccbb..0762e0ff66ef 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -33,6 +33,7 @@ properties:
- mediatek,mt2712-smi-common
- mediatek,mt6779-smi-common
- mediatek,mt6795-smi-common
+ - mediatek,mt6893-smi-common
- mediatek,mt8167-smi-common
- mediatek,mt8173-smi-common
- mediatek,mt8183-smi-common
@@ -43,6 +44,7 @@ properties:
- mediatek,mt8195-smi-common-vdo
- mediatek,mt8195-smi-common-vpp
- mediatek,mt8195-smi-sub-common
+ - mediatek,mt8365-smi-common
- description: for mt7623
items:
@@ -133,6 +135,7 @@ allOf:
- mediatek,mt8192-smi-common
- mediatek,mt8195-smi-common-vdo
- mediatek,mt8195-smi-common-vpp
+ - mediatek,mt8365-smi-common
then:
properties:
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index 5f4ac3609887..2e7fac4b5094 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -21,6 +21,7 @@ properties:
- mediatek,mt2712-smi-larb
- mediatek,mt6779-smi-larb
- mediatek,mt6795-smi-larb
+ - mediatek,mt6893-smi-larb
- mediatek,mt8167-smi-larb
- mediatek,mt8173-smi-larb
- mediatek,mt8183-smi-larb
@@ -34,6 +35,10 @@ properties:
- const: mediatek,mt7623-smi-larb
- const: mediatek,mt2701-smi-larb
+ - items:
+ - const: mediatek,mt8365-smi-larb
+ - const: mediatek,mt8186-smi-larb
+
reg:
maxItems: 1
@@ -63,7 +68,7 @@ properties:
minimum: 0
maximum: 31
description: the hardware id of this larb. It's only required when this
- hardward id is not consecutive from its M4U point of view.
+ hardware id is not consecutive from its M4U point of view.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml
new file mode 100644
index 000000000000..ac1a5a17749d
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/nuvoton,npcm-memory-controller.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/nuvoton,npcm-memory-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Memory Controller
+
+maintainers:
+ - Marvin Lin <kflin@nuvoton.com>
+ - Stanley Chu <yschu@nuvoton.com>
+
+description: |
+ The Nuvoton BMC SoC supports DDR4 memory with or without ECC (error correction
+ check).
+
+ The memory controller supports single bit error correction, double bit error
+ detection (in-line ECC in which a section (1/8th) of the memory device used to
+ store data is used for ECC storage).
+
+ Note, the bootloader must configure ECC mode for the memory controller.
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-memory-controller
+ - nuvoton,npcm845-memory-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mc: memory-controller@f0824000 {
+ compatible = "nuvoton,npcm750-memory-controller";
+ reg = <0xf0824000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
index 9163c3f12a85..f5f03bf36413 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
@@ -50,6 +50,7 @@ properties:
patternProperties:
"^emc-timings-[0-9]+$":
type: object
+ additionalProperties: false
properties:
nvidia,ram-code:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
index 935d63d181d9..b901f1b3e0fc 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
@@ -32,6 +32,7 @@ properties:
- nvidia,tegra186-mc
- nvidia,tegra194-mc
- nvidia,tegra234-mc
+ - nvidia,tegra264-mc
reg:
minItems: 6
@@ -42,8 +43,12 @@ properties:
maxItems: 18
interrupts:
- items:
- - description: MC general interrupt
+ minItems: 1
+ maxItems: 8
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 8
"#address-cells":
const: 2
@@ -74,6 +79,7 @@ patternProperties:
- nvidia,tegra186-emc
- nvidia,tegra194-emc
- nvidia,tegra234-emc
+ - nvidia,tegra264-emc
reg:
minItems: 1
@@ -127,6 +133,15 @@ patternProperties:
reg:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra264-emc
+ then:
+ properties:
+ reg:
+ minItems: 2
+
additionalProperties: false
required:
@@ -158,6 +173,12 @@ allOf:
- const: ch2
- const: ch3
+ interrupts:
+ items:
+ - description: MC general interrupt
+
+ interrupt-names: false
+
- if:
properties:
compatible:
@@ -189,6 +210,12 @@ allOf:
- const: ch14
- const: ch15
+ interrupts:
+ items:
+ - description: MC general interrupt
+
+ interrupt-names: false
+
- if:
properties:
compatible:
@@ -220,6 +247,59 @@ allOf:
- const: ch14
- const: ch15
+ interrupts:
+ items:
+ - description: MC general interrupt
+
+ interrupt-names: false
+
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra264-mc
+ then:
+ properties:
+ reg:
+ minItems: 17
+ maxItems: 17
+ description: 17 memory controller channels
+
+ reg-names:
+ items:
+ - const: broadcast
+ - const: ch0
+ - const: ch1
+ - const: ch2
+ - const: ch3
+ - const: ch4
+ - const: ch5
+ - const: ch6
+ - const: ch7
+ - const: ch8
+ - const: ch9
+ - const: ch10
+ - const: ch11
+ - const: ch12
+ - const: ch13
+ - const: ch14
+ - const: ch15
+
+ interrupts:
+ minItems: 8
+ maxItems: 8
+ description: One interrupt line for each MC component
+
+ interrupt-names:
+ items:
+ - const: mcf
+ - const: hub1
+ - const: hub2
+ - const: hub3
+ - const: hub4
+ - const: hub5
+ - const: sbs
+ - const: channel
+
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
index 2fa44951cfde..71896cb10692 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
@@ -145,7 +145,7 @@ patternProperties:
"^emc-table@[0-9]+$":
$ref: "#/$defs/emc-table"
- "^emc-tables@[a-z0-9-]+$":
+ "^emc-tables@[a-f0-9-]+$":
type: object
properties:
reg:
@@ -165,7 +165,7 @@ patternProperties:
const: 0
lpddr2:
- $ref: "ddr/jedec,lpddr2.yaml#"
+ $ref: ddr/jedec,lpddr2.yaml#
type: object
patternProperties:
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
index bc8477e7ab19..4e4fb4acd7f9 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
@@ -33,6 +33,9 @@ properties:
items:
- description: EMC general interrupt
+ "#interconnect-cells":
+ const: 0
+
memory-region:
maxItems: 1
description:
@@ -44,6 +47,11 @@ properties:
description:
phandle of the memory controller node
+ operating-points-v2:
+ description:
+ Should contain freqs and voltages and opp-supported-hw property, which
+ is a bitfield indicating SoC speedo ID mask.
+
required:
- compatible
- reg
@@ -79,4 +87,7 @@ examples:
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
memory-region = <&emc_table>;
nvidia,memory-controller = <&mc>;
+ operating-points-v2 = <&dvfs_opp_table>;
+
+ #interconnect-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml
index 0c511ab906bf..8b937f90a1fb 100644
--- a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml
@@ -52,10 +52,3 @@ examples:
#qca,ddr-wb-channel-cells = <1>;
};
-
- interrupt-controller {
- // ...
- qca,ddr-wb-channel-interrupts = <2>, <3>, <4>, <5>;
- qca,ddr-wb-channels = <&ddr_ctrl 3>, <&ddr_ctrl 2>,
- <&ddr_ctrl 0>, <&ddr_ctrl 1>;
- };
diff --git a/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml
new file mode 100644
index 000000000000..aec88cd2df76
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/qcom,ebi2-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral Properties for Qualcomm External Bus Interface 2 (EBI2)
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ # SLOW chip selects
+ qcom,xmem-recovery-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The time the memory continues to drive the data bus after OE
+ is de-asserted, in order to avoid contention on the data bus.
+ They are inserted when reading one CS and switching to another
+ CS or read followed by write on the same CS. Minimum value is
+ actually 1, so a value of 0 will still yield 1 recovery cycle.
+ minimum: 0
+ maximum: 15
+
+ qcom,xmem-write-hold-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The extra cycles inserted after every write minimum 1. The
+ data out is driven from the time WE is asserted until CS is
+ asserted. With a hold of 1 (value = 0), the CS stays active
+ for 1 extra cycle, etc.
+ minimum: 0
+ maximum: 15
+
+ qcom,xmem-write-delta-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The initial latency for write cycles inserted for the first
+ write to a page or burst memory.
+ minimum: 0
+ maximum: 255
+
+ qcom,xmem-read-delta-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The initial latency for read cycles inserted for the first
+ read to a page or burst memory.
+ minimum: 0
+ maximum: 255
+
+ qcom,xmem-write-wait-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The number of wait cycles for every write access.
+ minimum: 0
+ maximum: 15
+
+ qcom,xmem-read-wait-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The number of wait cycles for every read access.
+ minimum: 0
+ maximum: 15
+
+ # FAST chip selects
+ qcom,xmem-address-hold-enable:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ Holds the address for an extra cycle to meet hold time
+ requirements with ADV assertion, when set to 1.
+ enum: [ 0, 1 ]
+
+ qcom,xmem-adv-to-oe-recovery-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The number of cycles elapsed before an OE assertion, with
+ respect to the cycle where ADV (address valid) is asserted.
+ minimum: 0
+ maximum: 3
+
+ qcom,xmem-read-hold-cycles:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The length in cycles of the first segment of a read transfer.
+ For a single read transfer this will be the time from CS
+ assertion to OE assertion.
+ minimum: 0
+ maximum: 15
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2.yaml b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2.yaml
new file mode 100644
index 000000000000..423d7a75134f
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/qcom,ebi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm External Bus Interface 2 (EBI2)
+
+description: |
+ The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any
+ external memory (such as NAND or other memory-mapped peripherals) whereas
+ LCDC handles LCD displays.
+
+ As it says it connects devices to an external bus interface, meaning address
+ lines (up to 9 address lines so can only address 1KiB external memory space),
+ data lines (16 bits), OE (output enable), ADV (address valid, used on some
+ NOR flash memories), WE (write enable). This on top of 6 different chip selects
+ (CS0 thru CS5) so that in theory 6 different devices can be connected.
+
+ Apparently this bus is clocked at 64MHz. It has dedicated pins on the package
+ and the bus can only come out on these pins, however if some of the pins are
+ unused they can be left unconnected or remuxed to be used as GPIO or in some
+ cases other orthogonal functions as well.
+
+ Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me.
+
+ The chip selects have the following memory range assignments. This region of
+ memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big.
+
+ Chip Select Physical address base
+ CS0 GPIO134 0x1a800000-0x1b000000 (8MB)
+ CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB)
+ CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB)
+ CS3 GPIO133 0x1d000000-0x25000000 (128 MB)
+ CS4 GPIO132 0x1c800000-0x1d000000 (8MB)
+ CS5 GPIO131 0x1c000000-0x1c800000 (8MB)
+
+ The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A,
+ August 6, 2012 contains some incomplete documentation of the EBI2.
+
+ FIXME: the manual mentions "write precharge cycles" and "precharge cycles".
+ We have not been able to figure out which bit fields these correspond to
+ in the hardware, or what valid values exist. The current hypothesis is that
+ this is something just used on the FAST chip selects and that the SLOW
+ chip selects are understood fully. There is also a "byte device enable"
+ flag somewhere for 8bit memories.
+
+ FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit
+ unclear what this means, if they are mutually exclusive or can be used
+ together, or if some chip selects are hardwired to be FAST and others are SLOW
+ by design.
+
+ The XMEM registers are totally undocumented but could be partially decoded
+ because the Cypress AN49576 Antioch Westbridge apparently has suspiciously
+ similar register layout, see: http://www.cypress.com/file/105771/download
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,apq8060-ebi2
+ - qcom,msm8660-ebi2
+
+ reg:
+ items:
+ - description: EBI2 config region
+ - description: XMEM config region
+
+ reg-names:
+ items:
+ - const: ebi2
+ - const: xmem
+
+ ranges: true
+
+ clocks:
+ items:
+ - description: EBI_2X clock
+ - description: EBI clock
+
+ clock-names:
+ items:
+ - const: ebi2x
+ - const: ebi2
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ranges
+ - clocks
+ - clock-names
+ - '#address-cells'
+ - '#size-cells'
+
+patternProperties:
+ "^.*@[0-5],[0-9a-f]+$":
+ type: object
+ $ref: mc-peripheral-props.yaml#
+ additionalProperties: true
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8660.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ external-bus@1a100000 {
+ compatible = "qcom,msm8660-ebi2";
+ reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>;
+ reg-names = "ebi2", "xmem";
+ ranges = <0 0x0 0x1a800000 0x00800000>,
+ <1 0x0 0x1b000000 0x00800000>,
+ <2 0x0 0x1b800000 0x00800000>,
+ <3 0x0 0x1d000000 0x08000000>,
+ <4 0x0 0x1c800000 0x00800000>,
+ <5 0x0 0x1c000000 0x00800000>;
+
+ clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>;
+ clock-names = "ebi2x", "ebi2";
+
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ethernet@2,0 {
+ compatible = "smsc,lan9221", "smsc,lan9115";
+ reg = <2 0x0 0x100>;
+
+ interrupts-extended = <&pm8058_gpio 7 IRQ_TYPE_EDGE_FALLING>,
+ <&tlmm 29 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
+
+ phy-mode = "mii";
+ reg-io-width = <2>;
+ smsc,force-external-phy;
+ smsc,irq-push-pull;
+
+ /* SLOW chipselect config */
+ qcom,xmem-recovery-cycles = <0>;
+ qcom,xmem-write-hold-cycles = <3>;
+ qcom,xmem-write-delta-cycles = <31>;
+ qcom,xmem-read-delta-cycles = <28>;
+ qcom,xmem-write-wait-cycles = <9>;
+ qcom,xmem-read-wait-cycles = <9>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
index 7056ccb7eb30..8e3822314b25 100644
--- a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas DDR Bus Controllers
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
index 645249ea21d1..4f4bc953e31a 100644
--- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
@@ -20,7 +20,7 @@ description: |
- if it contains "cfi-flash", then HyperFlash is used.
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -44,6 +44,12 @@ properties:
- items:
- enum:
+ - renesas,r8a779g0-rpc-if # R-Car V4H
+ - renesas,r8a779h0-rpc-if # R-Car V4M
+ - const: renesas,rcar-gen4-rpc-if # a generic R-Car gen4 device
+
+ - items:
+ - enum:
- renesas,r9a07g043-rpc-if # RZ/G2UL
- renesas,r9a07g044-rpc-if # RZ/G2{L,LC}
- renesas,r9a07g054-rpc-if # RZ/V2L
@@ -61,7 +67,9 @@ properties:
- const: dirmap
- const: wbuf
- clocks: true
+ clocks:
+ minItems: 1
+ maxItems: 2
interrupts:
maxItems: 1
@@ -75,6 +83,8 @@ properties:
patternProperties:
"flash@[0-9a-f]+$":
type: object
+ additionalProperties: true
+
properties:
compatible:
contains:
diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
new file mode 100644
index 000000000000..7a84f5bb7284
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/renesas,rzg3e-xspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Expanded Serial Peripheral Interface (xSPI)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ Renesas xSPI allows a SPI flash connected to the SoC to be accessed via
+ the memory-mapping or the manual command mode.
+
+ The flash chip itself should be represented by a subnode of the XSPI node.
+ The flash interface is selected based on the "compatible" property of this
+ subnode:
+ - "jedec,spi-nor";
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: renesas,r9a09g047-xspi # RZ/G3E
+
+ - items:
+ - enum:
+ - renesas,r9a09g056-xspi # RZ/V2N
+ - renesas,r9a09g057-xspi # RZ/V2H(P)
+ - const: renesas,r9a09g047-xspi
+
+ reg:
+ items:
+ - description: xSPI registers
+ - description: direct mapping area
+
+ reg-names:
+ items:
+ - const: regs
+ - const: dirmap
+
+ interrupts:
+ items:
+ - description: Interrupt pulse signal by factors excluding errors
+ - description: Interrupt pulse signal by error factors
+
+ interrupt-names:
+ items:
+ - const: pulse
+ - const: err_pulse
+
+ clocks:
+ items:
+ - description: AHB clock
+ - description: AXI clock
+ - description: SPI clock
+ - description: Double speed SPI clock
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: axi
+ - const: spi
+ - const: spix2
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: Hardware reset
+ - description: AXI reset
+
+ reset-names:
+ items:
+ - const: hresetn
+ - const: aresetn
+
+ renesas,xspi-cs-addr-sys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Phandle to the system controller (sys) that allows to configure
+ xSPI CS0 and CS1 addresses.
+
+patternProperties:
+ "flash@[0-9a-f]+$":
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ contains:
+ const: jedec,spi-nor
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/renesas,r9a09g047-cpg.h>
+
+ spi@11030000 {
+ compatible = "renesas,r9a09g047-xspi";
+ reg = <0x11030000 0x10000>, <0x20000000 0x10000000>;
+ reg-names = "regs", "dirmap";
+ interrupts = <GIC_SPI 228 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 229 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "pulse", "err_pulse";
+ clocks = <&cpg CPG_MOD 0x9f>, <&cpg CPG_MOD 0xa0>,
+ <&cpg CPG_CORE 9>, <&cpg CPG_MOD 0xa1>;
+ clock-names = "ahb", "axi", "spi", "spix2";
+ power-domains = <&cpg>;
+ resets = <&cpg 0xa3>, <&cpg 0xa4>;
+ reset-names = "hresetn", "aresetn";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml
index fb4920397d08..1f58ee99be28 100644
--- a/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/rockchip,rk3399-dmc.yaml
@@ -18,7 +18,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Node to get DDR loading. Refer to
- Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt.
+ Documentation/devicetree/bindings/devfreq/event/rockchip,dfi.yaml.
clocks:
maxItems: 1
@@ -152,7 +152,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the phy side CA line
- (incluing command line, address line and clock line) drive strength.
+ (including command line, address line and clock line) drive strength.
default: 40
rockchip,phy_ddr3_dq_drv:
@@ -305,7 +305,7 @@ properties:
description:
Defines the self-refresh power down idle period in which memories are
placed into self-refresh power down mode if bus is idle for
- srpd_lite_idle nanoseonds. This parameter is for LPDDR4 only.
+ srpd_lite_idle nanoseconds. This parameter is for LPDDR4 only.
rockchip,standby-idle-ns:
description:
diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml
new file mode 100644
index 000000000000..c474f90846e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral Properties for Samsung Exynos SoC SROM Controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ samsung,srom-page-mode:
+ description:
+ If page mode is set, 4 data page mode will be configured,
+ else normal (1 data) page mode will be set.
+ type: boolean
+
+ samsung,srom-timing:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 6
+ maxItems: 6
+ description: |
+ Array of 6 integers, specifying bank timings in the following order:
+ Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+ Each value is specified in cycles and has the following meaning
+ and valid range:
+ Tacp: Page mode access cycle at Page mode (0 - 15)
+ Tcah: Address holding time after CSn (0 - 15)
+ Tcoh: Chip selection hold on OEn (0 - 15)
+ Tacc: Access cycle (0 - 31, the actual time is N + 1)
+ Tcos: Chip selection set-up before OEn (0 - 15)
+ Tacs: Address set-up before CSn (0 - 15)
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml
index 098348b2b815..783ac984d898 100644
--- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml
@@ -42,7 +42,7 @@ properties:
maxItems: 8
devfreq-events:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
maxItems: 16
items:
@@ -50,7 +50,7 @@ properties:
description: phandles of the PPMU events used by the controller.
device-handle:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
phandle of the connected DRAM memory device. For more information please
refer to jedec,lpddr3.yaml.
@@ -73,7 +73,7 @@ properties:
- description: registers of DREX1
samsung,syscon-clk:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Phandle of the clock register set used by the controller, these registers
are used for enabling a 'pause' feature and are not exposed by clock
diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml
new file mode 100644
index 000000000000..c0e47055f28c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/samsung,s5pv210-dmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5Pv210 SoC Dynamic Memory Controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Dynamic Memory Controller interfaces external JEDEC DDR-type SDRAM.
+
+properties:
+ compatible:
+ const: samsung,s5pv210-dmc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ memory-controller@f0000000 {
+ compatible = "samsung,s5pv210-dmc";
+ reg = <0xf0000000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml b/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
index e68c4306025a..87ff9ee098f5 100644
--- a/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml
@@ -8,8 +8,7 @@ title: Synopsys DesignWare Universal Multi-Protocol Memory Controller
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- - Manish Narani <manish.narani@xilinx.com>
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
Synopsys DesignWare Enhanced uMCTL2 DDR Memory Controller is capable of
diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml
new file mode 100644
index 000000000000..475e4095068c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral properties for ST FMC2 Controller
+
+maintainers:
+ - Christophe Kerello <christophe.kerello@foss.st.com>
+ - Marek Vasut <marex@denx.de>
+
+properties:
+ st,fmc2-ebi-cs-transaction-type:
+ description: |
+ Select one of the transactions type supported
+ 0: Asynchronous mode 1 SRAM/FRAM.
+ 1: Asynchronous mode 1 PSRAM.
+ 2: Asynchronous mode A SRAM/FRAM.
+ 3: Asynchronous mode A PSRAM.
+ 4: Asynchronous mode 2 NOR.
+ 5: Asynchronous mode B NOR.
+ 6: Asynchronous mode C NOR.
+ 7: Asynchronous mode D NOR.
+ 8: Synchronous read synchronous write PSRAM.
+ 9: Synchronous read asynchronous write PSRAM.
+ 10: Synchronous read synchronous write NOR.
+ 11: Synchronous read asynchronous write NOR.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 11
+
+ st,fmc2-ebi-cs-cclk-enable:
+ description: Continuous clock enable (first bank must be configured
+ in synchronous mode). The FMC_CLK is generated continuously
+ during asynchronous and synchronous access. By default, the
+ FMC_CLK is only generated during synchronous access.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,fmc2-ebi-cs-mux-enable:
+ description: Address/Data multiplexed on databus (valid only with
+ NOR and PSRAM transactions type). By default, Address/Data
+ are not multiplexed.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,fmc2-ebi-cs-buswidth:
+ description: Data bus width
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 8, 16 ]
+ default: 16
+
+ st,fmc2-ebi-cs-waitpol-high:
+ description: Wait signal polarity (NWAIT signal active high).
+ By default, NWAIT is active low.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,fmc2-ebi-cs-waitcfg-enable:
+ description: The NWAIT signal indicates wheither the data from the
+ device are valid or if a wait state must be inserted when accessing
+ the device in synchronous mode. By default, the NWAIT signal is
+ active one data cycle before wait state.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,fmc2-ebi-cs-wait-enable:
+ description: The NWAIT signal is enabled (its level is taken into
+ account after the programmed latency period to insert wait states
+ if asserted). By default, the NWAIT signal is disabled.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,fmc2-ebi-cs-asyncwait-enable:
+ description: The NWAIT signal is taken into account during asynchronous
+ transactions. By default, the NWAIT signal is not taken into account
+ during asynchronous transactions.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,fmc2-ebi-cs-cpsize:
+ description: CRAM page size. The controller splits the burst access
+ when the memory page is reached. By default, no burst split when
+ crossing page boundary.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 128, 256, 512, 1024 ]
+ default: 0
+
+ st,fmc2-ebi-cs-byte-lane-setup-ns:
+ description: This property configures the byte lane setup timing
+ defined in nanoseconds from NBLx low to Chip Select NEx low.
+
+ st,fmc2-ebi-cs-address-setup-ns:
+ description: This property defines the duration of the address setup
+ phase in nanoseconds used for asynchronous read/write transactions.
+
+ st,fmc2-ebi-cs-address-hold-ns:
+ description: This property defines the duration of the address hold
+ phase in nanoseconds used for asynchronous multiplexed read/write
+ transactions.
+
+ st,fmc2-ebi-cs-data-setup-ns:
+ description: This property defines the duration of the data setup phase
+ in nanoseconds used for asynchronous read/write transactions.
+
+ st,fmc2-ebi-cs-bus-turnaround-ns:
+ description: This property defines the delay in nanoseconds between the
+ end of current read/write transaction and the next transaction.
+
+ st,fmc2-ebi-cs-data-hold-ns:
+ description: This property defines the duration of the data hold phase
+ in nanoseconds used for asynchronous read/write transactions.
+
+ st,fmc2-ebi-cs-clk-period-ns:
+ description: This property defines the FMC_CLK output signal period in
+ nanoseconds.
+
+ st,fmc2-ebi-cs-data-latency-ns:
+ description: This property defines the data latency before reading or
+ writing the first data in nanoseconds.
+
+ st,fmc2-ebi-cs-write-address-setup-ns:
+ description: This property defines the duration of the address setup
+ phase in nanoseconds used for asynchronous write transactions.
+
+ st,fmc2-ebi-cs-write-address-hold-ns:
+ description: This property defines the duration of the address hold
+ phase in nanoseconds used for asynchronous multiplexed write
+ transactions.
+
+ st,fmc2-ebi-cs-write-data-setup-ns:
+ description: This property defines the duration of the data setup
+ phase in nanoseconds used for asynchronous write transactions.
+
+ st,fmc2-ebi-cs-write-bus-turnaround-ns:
+ description: This property defines the delay between the end of current
+ write transaction and the next transaction in nanoseconds.
+
+ st,fmc2-ebi-cs-write-data-hold-ns:
+ description: This property defines the duration of the data hold phase
+ in nanoseconds used for asynchronous write transactions.
+
+ st,fmc2-ebi-cs-max-low-pulse-ns:
+ description: This property defines the maximum chip select low pulse
+ duration in nanoseconds for synchronous transactions. When this timing
+ reaches 0, the controller splits the current access, toggles NE to
+ allow device refresh and restarts a new access.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
index 6b516d3895af..706e45eb4d27 100644
--- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics Flexible Memory Controller 2 (FMC2) Bindings
+title: STMicroelectronics Flexible Memory Controller 2 (FMC2)
description: |
The FMC2 functional block makes the interface with: synchronous and
@@ -23,7 +23,9 @@ maintainers:
properties:
compatible:
- const: st,stm32mp1-fmc2-ebi
+ enum:
+ - st,stm32mp1-fmc2-ebi
+ - st,stm32mp25-fmc2-ebi
reg:
maxItems: 1
@@ -34,6 +36,9 @@ properties:
resets:
maxItems: 1
+ power-domains:
+ maxItems: 1
+
"#address-cells":
const: 2
@@ -45,146 +50,15 @@ properties:
Reflects the memory layout with four integer values per bank. Format:
<bank-number> 0 <address of the bank> <size>
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
patternProperties:
"^.*@[0-4],[a-f0-9]+$":
+ additionalProperties: true
type: object
-
- properties:
- reg:
- description: Bank number, base address and size of the device.
-
- st,fmc2-ebi-cs-transaction-type:
- description: |
- Select one of the transactions type supported
- 0: Asynchronous mode 1 SRAM/FRAM.
- 1: Asynchronous mode 1 PSRAM.
- 2: Asynchronous mode A SRAM/FRAM.
- 3: Asynchronous mode A PSRAM.
- 4: Asynchronous mode 2 NOR.
- 5: Asynchronous mode B NOR.
- 6: Asynchronous mode C NOR.
- 7: Asynchronous mode D NOR.
- 8: Synchronous read synchronous write PSRAM.
- 9: Synchronous read asynchronous write PSRAM.
- 10: Synchronous read synchronous write NOR.
- 11: Synchronous read asynchronous write NOR.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 11
-
- st,fmc2-ebi-cs-cclk-enable:
- description: Continuous clock enable (first bank must be configured
- in synchronous mode). The FMC_CLK is generated continuously
- during asynchronous and synchronous access. By default, the
- FMC_CLK is only generated during synchronous access.
- $ref: /schemas/types.yaml#/definitions/flag
-
- st,fmc2-ebi-cs-mux-enable:
- description: Address/Data multiplexed on databus (valid only with
- NOR and PSRAM transactions type). By default, Address/Data
- are not multiplexed.
- $ref: /schemas/types.yaml#/definitions/flag
-
- st,fmc2-ebi-cs-buswidth:
- description: Data bus width
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 8, 16 ]
- default: 16
-
- st,fmc2-ebi-cs-waitpol-high:
- description: Wait signal polarity (NWAIT signal active high).
- By default, NWAIT is active low.
- $ref: /schemas/types.yaml#/definitions/flag
-
- st,fmc2-ebi-cs-waitcfg-enable:
- description: The NWAIT signal indicates wheither the data from the
- device are valid or if a wait state must be inserted when accessing
- the device in synchronous mode. By default, the NWAIT signal is
- active one data cycle before wait state.
- $ref: /schemas/types.yaml#/definitions/flag
-
- st,fmc2-ebi-cs-wait-enable:
- description: The NWAIT signal is enabled (its level is taken into
- account after the programmed latency period to insert wait states
- if asserted). By default, the NWAIT signal is disabled.
- $ref: /schemas/types.yaml#/definitions/flag
-
- st,fmc2-ebi-cs-asyncwait-enable:
- description: The NWAIT signal is taken into account during asynchronous
- transactions. By default, the NWAIT signal is not taken into account
- during asynchronous transactions.
- $ref: /schemas/types.yaml#/definitions/flag
-
- st,fmc2-ebi-cs-cpsize:
- description: CRAM page size. The controller splits the burst access
- when the memory page is reached. By default, no burst split when
- crossing page boundary.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 128, 256, 512, 1024 ]
- default: 0
-
- st,fmc2-ebi-cs-byte-lane-setup-ns:
- description: This property configures the byte lane setup timing
- defined in nanoseconds from NBLx low to Chip Select NEx low.
-
- st,fmc2-ebi-cs-address-setup-ns:
- description: This property defines the duration of the address setup
- phase in nanoseconds used for asynchronous read/write transactions.
-
- st,fmc2-ebi-cs-address-hold-ns:
- description: This property defines the duration of the address hold
- phase in nanoseconds used for asynchronous multiplexed read/write
- transactions.
-
- st,fmc2-ebi-cs-data-setup-ns:
- description: This property defines the duration of the data setup phase
- in nanoseconds used for asynchronous read/write transactions.
-
- st,fmc2-ebi-cs-bus-turnaround-ns:
- description: This property defines the delay in nanoseconds between the
- end of current read/write transaction and the next transaction.
-
- st,fmc2-ebi-cs-data-hold-ns:
- description: This property defines the duration of the data hold phase
- in nanoseconds used for asynchronous read/write transactions.
-
- st,fmc2-ebi-cs-clk-period-ns:
- description: This property defines the FMC_CLK output signal period in
- nanoseconds.
-
- st,fmc2-ebi-cs-data-latency-ns:
- description: This property defines the data latency before reading or
- writing the first data in nanoseconds.
-
- st,fmc2_ebi-cs-write-address-setup-ns:
- description: This property defines the duration of the address setup
- phase in nanoseconds used for asynchronous write transactions.
-
- st,fmc2-ebi-cs-write-address-hold-ns:
- description: This property defines the duration of the address hold
- phase in nanoseconds used for asynchronous multiplexed write
- transactions.
-
- st,fmc2-ebi-cs-write-data-setup-ns:
- description: This property defines the duration of the data setup
- phase in nanoseconds used for asynchronous write transactions.
-
- st,fmc2-ebi-cs-write-bus-turnaround-ns:
- description: This property defines the delay between the end of current
- write transaction and the next transaction in nanoseconds.
-
- st,fmc2-ebi-cs-write-data-hold-ns:
- description: This property defines the duration of the data hold phase
- in nanoseconds used for asynchronous write transactions.
-
- st,fmc2-ebi-cs-max-low-pulse-ns:
- description: This property defines the maximum chip select low pulse
- duration in nanoseconds for synchronous transactions. When this timing
- reaches 0, the controller splits the current access, toggles NE to
- allow device refresh and restarts a new access.
-
- required:
- - reg
+ $ref: mc-peripheral-props.yaml#
required:
- "#address-cells"
diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml
new file mode 100644
index 000000000000..344878db8818
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32mp25-omm.yaml
@@ -0,0 +1,226 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/st,stm32mp25-omm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Octo Memory Manager (OMM)
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+description: |
+ The STM32 Octo Memory Manager is a low-level interface that enables an
+ efficient OCTOSPI pin assignment with a full I/O matrix (before alternate
+ function map) and multiplex of single/dual/quad/octal SPI interfaces over
+ the same bus. It Supports up to:
+ - Two single/dual/quad/octal SPI interfaces
+ - Two ports for pin assignment
+
+properties:
+ compatible:
+ const: st,stm32mp25-omm
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 1
+
+ ranges:
+ description: |
+ Reflects the memory layout per OSPI instance.
+ Format:
+ <chip-select> 0 <registers base address> <size>
+ minItems: 2
+ maxItems: 2
+
+ reg:
+ items:
+ - description: OMM registers
+ - description: OMM memory map area
+
+ reg-names:
+ items:
+ - const: regs
+ - const: memory_map
+
+ memory-region:
+ description:
+ Memory region shared between the 2 OCTOSPI instance.
+ One or two phandle to a node describing a memory mapped region
+ depending of child number.
+ minItems: 1
+ maxItems: 2
+
+ memory-region-names:
+ description:
+ Identify to which OSPI instance the memory region belongs to.
+ items:
+ enum: [ospi1, ospi2]
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: omm
+ - const: ospi1
+ - const: ospi2
+
+ resets:
+ maxItems: 3
+
+ reset-names:
+ items:
+ - const: omm
+ - const: ospi1
+ - const: ospi2
+
+ access-controllers:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ st,syscfg-amcr:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ The Address Mapping Control Register (AMCR) is used to split the 256MB
+ memory map area shared between the 2 OSPI instance. The Octo Memory
+ Manager sets the AMCR depending of the memory-region configuration.
+ The memory split bitmask description is:
+ - 000: OCTOSPI1 (256 Mbytes), OCTOSPI2 unmapped
+ - 001: OCTOSPI1 (192 Mbytes), OCTOSPI2 (64 Mbytes)
+ - 010: OCTOSPI1 (128 Mbytes), OCTOSPI2 (128 Mbytes)
+ - 011: OCTOSPI1 (64 Mbytes), OCTOSPI2 (192 Mbytes)
+ - 1xx: OCTOSPI1 unmapped, OCTOSPI2 (256 Mbytes)
+ items:
+ - items:
+ - description: phandle to syscfg
+ - description: register offset within syscfg
+ - description: register bitmask for memory split
+
+ st,omm-req2ack-ns:
+ description:
+ In multiplexed mode (MUXEN = 1), this field defines the time in
+ nanoseconds between two transactions.
+ default: 0
+
+ st,omm-cssel-ovr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Configure the chip select selector override for the 2 OCTOSPIs.
+ - 0: OCTOSPI1 chip select send to NCS1 OCTOSPI2 chip select send to NCS1
+ - 1: OCTOSPI1 chip select send to NCS2 OCTOSPI2 chip select send to NCS1
+ - 2: OCTOSPI1 chip select send to NCS1 OCTOSPI2 chip select send to NCS2
+ - 3: OCTOSPI1 chip select send to NCS2 OCTOSPI2 chip select send to NCS2
+ minimum: 0
+ maximum: 3
+ default: 0
+
+ st,omm-mux:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Configure the muxing between the 2 OCTOSPIs busses and the 2 output ports.
+ - 0: direct mode
+ - 1: mux OCTOSPI1 and OCTOSPI2 to port 1
+ - 2: swapped mode
+ - 3: mux OCTOSPI1 and OCTOSPI2 to port 2
+ minimum: 0
+ maximum: 3
+ default: 0
+
+patternProperties:
+ ^spi@[0-9]:
+ type: object
+ $ref: /schemas/spi/st,stm32mp25-ospi.yaml#
+ description: Required spi child node
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - st,syscfg-amcr
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+ ommanager@40500000 {
+ compatible = "st,stm32mp25-omm";
+ reg = <0x40500000 0x400>, <0x60000000 0x10000000>;
+ reg-names = "regs", "memory_map";
+ ranges = <0 0 0x40430000 0x400>,
+ <1 0 0x40440000 0x400>;
+ memory-region = <&mm_ospi1>, <&mm_ospi2>;
+ memory-region-names = "ospi1", "ospi2";
+ pinctrl-0 = <&ospi_port1_clk_pins_a
+ &ospi_port1_io03_pins_a
+ &ospi_port1_cs0_pins_a>;
+ pinctrl-1 = <&ospi_port1_clk_sleep_pins_a
+ &ospi_port1_io03_sleep_pins_a
+ &ospi_port1_cs0_sleep_pins_a>;
+ pinctrl-names = "default", "sleep";
+ clocks = <&rcc CK_BUS_OSPIIOM>,
+ <&scmi_clk CK_SCMI_OSPI1>,
+ <&scmi_clk CK_SCMI_OSPI2>;
+ clock-names = "omm", "ospi1", "ospi2";
+ resets = <&rcc OSPIIOM_R>,
+ <&scmi_reset RST_SCMI_OSPI1>,
+ <&scmi_reset RST_SCMI_OSPI2>;
+ reset-names = "omm", "ospi1", "ospi2";
+ access-controllers = <&rifsc 111>;
+ power-domains = <&CLUSTER_PD>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ st,syscfg-amcr = <&syscfg 0x2c00 0x7>;
+ st,omm-req2ack-ns = <0>;
+ st,omm-mux = <0>;
+ st,omm-cssel-ovr = <0>;
+
+ spi@0 {
+ compatible = "st,stm32mp25-ospi";
+ reg = <0 0 0x400>;
+ memory-region = <&mm_ospi1>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&hpdma 2 0x62 0x00003121 0x0>,
+ <&hpdma 2 0x42 0x00003112 0x0>;
+ dma-names = "tx", "rx";
+ clocks = <&scmi_clk CK_SCMI_OSPI1>;
+ resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>;
+ access-controllers = <&rifsc 74>;
+ power-domains = <&CLUSTER_PD>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ st,syscfg-dlyb = <&syscfg 0x1000>;
+ };
+
+ spi@1 {
+ compatible = "st,stm32mp25-ospi";
+ reg = <1 0 0x400>;
+ memory-region = <&mm_ospi1>;
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&hpdma 3 0x62 0x00003121 0x0>,
+ <&hpdma 3 0x42 0x00003112 0x0>;
+ dma-names = "tx", "rx";
+ clocks = <&scmi_clk CK_KER_OSPI2>;
+ resets = <&scmi_reset RST_SCMI_OSPI2>, <&scmi_reset RST_SCMI_OSPI1DLL>;
+ access-controllers = <&rifsc 75>;
+ power-domains = <&CLUSTER_PD>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ st,syscfg-dlyb = <&syscfg 0x1000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/starfive,jh7110-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/starfive,jh7110-dmc.yaml
new file mode 100644
index 000000000000..d65313b33a3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/starfive,jh7110-dmc.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/starfive,jh7110-dmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 DMC
+
+maintainers:
+ - E Shattow <e@freeshell.de>
+
+description:
+ JH7110 DDR external memory interface LPDDR4/DDR4/DDR3/LPDDR3 32-bit at
+ 2133Mbps (up to 2800Mbps).
+
+properties:
+ compatible:
+ items:
+ - const: starfive,jh7110-dmc
+
+ reg:
+ items:
+ - description: controller registers
+ - description: phy registers
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: axi
+ - description: osc
+ - description: apb
+
+ reset-names:
+ items:
+ - const: axi
+ - const: osc
+ - const: apb
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/starfive,jh7110-crg.h>
+ #include <dt-bindings/reset/starfive,jh7110-crg.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ memory-controller@15700000 {
+ compatible = "starfive,jh7110-dmc";
+ reg = <0x0 0x15700000 0x0 0x10000>,
+ <0x0 0x13000000 0x0 0x10000>;
+ clocks = <&syscrg JH7110_PLLCLK_PLL1_OUT>;
+ clock-names = "pll";
+ resets = <&syscrg JH7110_SYSRST_DDR_AXI>,
+ <&syscrg JH7110_SYSRST_DDR_OSC>,
+ <&syscrg JH7110_SYSRST_DDR_APB>;
+ reset-names = "axi", "osc", "apb";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml
index 6e3995bb1630..383d19e0ba26 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc-child.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc-child.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: device tree bindings for children of the Texas Instruments GPMC
+title: Texas Instruments GPMC Bus Child Nodes
maintainers:
- Tony Lindgren <tony@atomide.com>
@@ -230,6 +230,13 @@ properties:
Wait-pin used by client. Must be less than "gpmc,num-waitpins".
$ref: /schemas/types.yaml#/definitions/uint32
+ ti,wait-pin-polarity:
+ description: |
+ Set the desired polarity for the selected wait pin.
+ 0 for active low, 1 for active high.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
gpmc,wait-on-read:
description: Enables wait monitoring on reads.
type: boolean
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
index e188a4bf755c..c7a8a041da50 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/memory-controllers/ti,gpmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments GPMC Memory Controller device-tree bindings
+title: Texas Instruments GPMC Memory Controller
maintainers:
- Tony Lindgren <tony@atomide.com>
@@ -90,7 +90,7 @@ properties:
interrupt-controller:
description: |
- The GPMC driver implements and interrupt controller for
+ The GPMC driver implements an interrupt controller for
the NAND events "fifoevent" and "termcount" plus the
rising/falling edges on the GPMC_WAIT pins.
The interrupt number mapping is as follows
@@ -129,8 +129,8 @@ patternProperties:
The child device node represents the device connected to the GPMC
bus. The device can be a NAND chip, SRAM device, NOR device
or an ASIC.
- $ref: "ti,gpmc-child.yaml"
-
+ $ref: ti,gpmc-child.yaml
+ additionalProperties: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
new file mode 100644
index 000000000000..12f8e9f350bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/xlnx,versal-ddrmc-edac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal DDRMC (Integrated DDR Memory Controller)
+
+maintainers:
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+description:
+ The integrated DDR Memory Controllers (DDRMCs) support both DDR4 and LPDDR4/
+ 4X memory interfaces. Versal DDR memory controller has an optional ECC support
+ which correct single bit ECC errors and detect double bit ECC errors.
+
+properties:
+ compatible:
+ const: xlnx,versal-ddrmc
+
+ reg:
+ items:
+ - description: DDR Memory Controller registers
+ - description: NOC registers corresponding to DDR Memory Controller
+
+ reg-names:
+ items:
+ - const: base
+ - const: noc
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ memory-controller@f6150000 {
+ compatible = "xlnx,versal-ddrmc";
+ reg = <0x0 0xf6150000 0x0 0x2000>, <0x0 0xf6070000 0x0 0x20000>;
+ reg-names = "base", "noc";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-net-ddrmc5.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-net-ddrmc5.yaml
new file mode 100644
index 000000000000..479288567d0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-net-ddrmc5.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/xlnx,versal-net-ddrmc5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal NET Memory Controller
+
+maintainers:
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+
+description:
+ The integrated DDR Memory Controllers (DDRMCs) support both DDR5 and LPDDR5
+ compact and extended memory interfaces. Versal NET DDR memory controller
+ has an optional ECC support which correct single bit ECC errors and detect
+ double bit ECC errors. It also has support for reporting other errors like
+ MMCM (Mixed-Mode Clock Manager) errors and General software errors.
+
+properties:
+ compatible:
+ const: xlnx,versal-net-ddrmc5
+
+ amd,rproc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the remoteproc_r5 rproc node using which APU interacts
+ with remote processor. APU primarily communicates with the RPU for
+ accessing the DDRMC address space and getting error notification.
+
+required:
+ - compatible
+ - amd,rproc
+
+additionalProperties: false
+
+examples:
+ - |
+ memory-controller {
+ compatible = "xlnx,versal-net-ddrmc5";
+ amd,rproc = <&remoteproc_r5>;
+ };
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
index 8f72e2f8588a..b74ad9a3305c 100644
--- a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynq-ddrc-a05.yaml
@@ -8,12 +8,11 @@ title: Zynq A05 DDR Memory Controller
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- - Manish Narani <manish.narani@xilinx.com>
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description:
The Zynq DDR ECC controller has an optional ECC support in half-bus width
- (16-bit) configuration. It is cappable of correcting single bit ECC errors
+ (16-bit) configuration. It is capable of correcting single bit ECC errors
and detecting double bit ECC errors.
properties:
diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml
new file mode 100644
index 000000000000..ca9fc747bf4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/xlnx,zynqmp-ocmc-1.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynqmp OCM(On-Chip Memory) Controller
+
+maintainers:
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+description: |
+ The OCM supports 64-bit wide ECC functionality to detect multi-bit errors
+ and recover from a single-bit memory fault.On a write, if all bytes are
+ being written, the ECC is generated and written into the ECC RAM along with
+ the write-data that is written into the data RAM. If one or more bytes are
+ not written, then the read operation results in an correctable error or
+ uncorrectable error.
+
+properties:
+ compatible:
+ const: xlnx,zynqmp-ocmc-1.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ memory-controller@ff960000 {
+ compatible = "xlnx,zynqmp-ocmc-1.0";
+ reg = <0xff960000 0x1000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt b/Documentation/devicetree/bindings/mfd/act8945a.txt
deleted file mode 100644
index 5ca75d888b4a..000000000000
--- a/Documentation/devicetree/bindings/mfd/act8945a.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-Device-Tree bindings for Active-semi ACT8945A MFD driver
-
-Required properties:
- - compatible: "active-semi,act8945a".
- - reg: the I2C slave address for the ACT8945A chip
-
-The chip exposes two subdevices:
- - a regulators: see ../regulator/act8945a-regulator.txt
- - a charger: see ../power/act8945a-charger.txt
-
-Example:
- pmic@5b {
- compatible = "active-semi,act8945a";
- reg = <0x5b>;
-
- active-semi,vsel-high;
-
- regulators {
- vdd_1v35_reg: REG_DCDC1 {
- regulator-name = "VDD_1V35";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
- };
-
- vdd_1v2_reg: REG_DCDC2 {
- regulator-name = "VDD_1V2";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
- };
-
- vdd_3v3_reg: REG_DCDC3 {
- regulator-name = "VDD_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_fuse_reg: REG_LDO1 {
- regulator-name = "VDD_FUSE";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- regulator-always-on;
- };
-
- vdd_3v3_lp_reg: REG_LDO2 {
- regulator-name = "VDD_3V3_LP";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_led_reg: REG_LDO3 {
- regulator-name = "VDD_LED";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_sdhc_1v8_reg: REG_LDO4 {
- regulator-name = "VDD_SDHC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
- };
-
- charger {
- compatible = "active-semi,act8945a-charger";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>;
- interrupt-parent = <&pioA>;
- interrupts = <45 IRQ_TYPE_LEVEL_LOW>;
-
- active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>;
- active-semi,lbo-gpios = <&pioA 72 GPIO_ACTIVE_LOW>;
- active-semi,input-voltage-threshold-microvolt = <6600>;
- active-semi,precondition-timeout = <40>;
- active-semi,total-timeout = <3>;
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml b/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
index dd43a0c766f3..9ae419748aa7 100644
--- a/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
+++ b/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/actions,atc260x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Actions Semi ATC260x Power Management IC bindings
+title: Actions Semi ATC260x Power Management IC
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
@@ -21,7 +21,7 @@ description: |
regulators.
allOf:
- - $ref: ../input/input.yaml
+ - $ref: /schemas/input/input.yaml
properties:
compatible:
@@ -57,7 +57,7 @@ properties:
switchldo1:
type: object
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
properties:
regulator-name: true
@@ -76,7 +76,7 @@ properties:
"^(dcdc[0-4]|ldo[0-9]|ldo1[1-2])$":
type: object
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
properties:
regulator-name: true
@@ -129,7 +129,7 @@ required:
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/mfd/adi,adp5585.yaml b/Documentation/devicetree/bindings/mfd/adi,adp5585.yaml
new file mode 100644
index 000000000000..2d4ecee3f254
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/adi,adp5585.yaml
@@ -0,0 +1,313 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/adi,adp5585.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADP5585 Keypad Decoder and I/O Expansion
+
+maintainers:
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description:
+ The ADP5585 is a 10/11 input/output port expander with a built in keypad
+ matrix decoder, programmable logic, reset generator, and PWM generator.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - adi,adp5585-00 # Default
+ - adi,adp5585-01 # 11 GPIOs
+ - adi,adp5585-02 # No pull-up resistors by default on special pins
+ - adi,adp5585-03 # Alternate I2C address
+ - adi,adp5585-04 # Pull-down resistors on all pins by default
+ - const: adi,adp5585
+ - items:
+ - enum:
+ - adi,adp5589-00 # Default
+ - adi,adp5589-01 # R4 defaulted to RESET1 output
+ - adi,adp5589-02 # Pull-down resistors by default on special pins
+ - const: adi,adp5589
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply: true
+
+ reset-gpios:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-reserved-ranges: true
+
+ "#pwm-cells":
+ const: 3
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ poll-interval:
+ enum: [10, 20, 30, 40]
+ default: 10
+
+ adi,keypad-pins:
+ description: Specifies the pins used for the keypad matrix.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ adi,unlock-events:
+ description:
+ Specifies a maximum of 2 events that can be used to unlock the keypad.
+ If this property is set, the keyboard will be locked and only unlocked
+ after these keys/gpis are pressed. The value 127 serves as a wildcard which
+ means any key can be used for unlocking.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 88
+ - minimum: 97
+ maximum: 115
+ - const: 127
+
+ adi,unlock-trigger-sec:
+ description:
+ Defines the time in which the second unlock event must occur after the
+ first unlock event has occurred.
+ maximum: 7
+ default: 0
+
+ adi,reset1-events:
+ description:
+ Defines the trigger events (key/gpi presses) that can generate reset
+ conditions one the reset1 block.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 3
+
+ adi,reset2-events:
+ description:
+ Defines the trigger events (key/gpi presses) that can generate reset
+ conditions one the reset2 block.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+
+ adi,reset1-active-high:
+ description: Sets the reset1 signal as active high.
+ type: boolean
+
+ adi,reset2-active-high:
+ description: Sets the reset2 signal as active high.
+ type: boolean
+
+ adi,rst-passthrough-enable:
+ description: Allows the RST pin to override (OR with) the reset1 signal.
+ type: boolean
+
+ adi,reset-trigger-ms:
+ description:
+ Defines the length of time that the reset events must be active before a
+ reset signal is generated. All events must be active at the same time for
+ the same duration.
+ enum: [0, 1000, 1500, 2000, 2500, 3000, 3500, 4000]
+ default: 0
+
+ adi,reset-pulse-width-us:
+ description: Defines the pulse width of the reset signals.
+ enum: [500, 1000, 2000, 10000]
+ default: 500
+
+patternProperties:
+ "-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
+dependencies:
+ linux,keymap:
+ - adi,keypad-pins
+ - interrupts
+ interrupt-controller:
+ - interrupts
+ adi,unlock-trigger-sec:
+ - adi,unlock-events
+ adi,reset1-active-high:
+ - adi,reset1-events
+ adi,rst-passtrough-enable:
+ - adi,reset1-events
+ adi,reset2-active-high:
+ - adi,reset2-events
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/input/matrix-keymap.yaml#
+ - $ref: /schemas/input/input.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adp5585-01
+ then:
+ properties:
+ adi,unlock-events: false
+ adi,unlock-trigger-sec: false
+ gpio-reserved-ranges: false
+ reset-gpios: false
+ adi,keypad-pins:
+ minItems: 2
+ maxItems: 11
+ items:
+ minimum: 0
+ maximum: 10
+ adi,reset1-events:
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 30
+ - minimum: 37
+ maximum: 47
+ adi,reset2-events:
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 30
+ - minimum: 37
+ maximum: 47
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,adp5585-00
+ - adi,adp5585-02
+ - adi,adp5585-03
+ - adi,adp5585-04
+ then:
+ properties:
+ adi,unlock-events: false
+ adi,unlock-trigger-sec: false
+ adi,keypad-pins:
+ minItems: 2
+ maxItems: 10
+ items:
+ enum: [0, 1, 2, 3, 4, 6, 7, 8, 9, 10]
+ adi,reset1-events:
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 25
+ - enum: [37, 38, 39, 40, 41, 43, 44, 45, 46, 47]
+ adi,reset2-events:
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 25
+ - enum: [37, 38, 39, 40, 41, 43, 44, 45, 46, 47]
+ gpio-reserved-ranges:
+ maxItems: 1
+ items:
+ items:
+ - const: 5
+ - const: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,adp5589-00
+ - adi,adp5589-01
+ - adi,adp5589-02
+ then:
+ properties:
+ gpio-reserved-ranges: false
+ adi,keypad-pins:
+ minItems: 2
+ maxItems: 19
+ items:
+ minimum: 0
+ maximum: 18
+ adi,reset1-events:
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 88
+ - minimum: 97
+ maximum: 115
+ adi,reset2-events:
+ items:
+ anyOf:
+ - minimum: 1
+ maximum: 88
+ - minimum: 97
+ maximum: 115
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ io-expander@34 {
+ compatible = "adi,adp5585-00", "adi,adp5585";
+ reg = <0x34>;
+
+ vdd-supply = <&reg_3v3>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-reserved-ranges = <5 1>;
+
+ #pwm-cells = <3>;
+
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+
+ adi,reset1-events = <1 43>;
+ adi,reset2-events = <2 3>;
+ adi,reset-trigger-ms = <2000>;
+
+ /*
+ * col0, col1, col2
+ * row0, row1, row2
+ */
+ adi,keypad-pins = <0 1 2 6 7 8>;
+
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x00, KEY_1)
+ MATRIX_KEY(0x00, 0x01, KEY_2)
+ MATRIX_KEY(0x00, 0x02, KEY_3)
+
+ MATRIX_KEY(0x01, 0x00, KEY_A)
+ MATRIX_KEY(0x01, 0x01, KEY_B)
+ MATRIX_KEY(0x01, 0x02, KEY_C)
+
+ MATRIX_KEY(0x02, 0x00, BTN_1)
+ MATRIX_KEY(0x02, 0x01, BTN_2)
+ MATRIX_KEY(0x02, 0x02, BTN_3)
+ >;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/adi,max77541.yaml b/Documentation/devicetree/bindings/mfd/adi,max77541.yaml
new file mode 100644
index 000000000000..c7895b2c38c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/adi,max77541.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/adi,max77541.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX77540/MAX77541 PMIC from ADI
+
+maintainers:
+ - Okan Sahin <okan.sahin@analog.com>
+
+description: |
+ MAX77540 is a Power Management IC with 2 buck regulators.
+
+ MAX77541 is a Power Management IC with 2 buck regulators and 1 ADC.
+
+properties:
+ compatible:
+ enum:
+ - adi,max77540
+ - adi,max77541
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ $ref: /schemas/regulator/adi,max77541-regulator.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@69 {
+ compatible = "adi,max77541";
+ reg = <0x69>;
+ interrupt-parent = <&gpio>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ buck1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <5200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ buck2 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <5200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/airoha,en7581-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/airoha,en7581-gpio-sysctl.yaml
new file mode 100644
index 000000000000..4a81ed82ef34
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/airoha,en7581-gpio-sysctl.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/airoha,en7581-gpio-sysctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 GPIO System Controller
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ Airoha EN7581 SoC GPIO system controller which provided a register map
+ for controlling the GPIO, pins and PWM of the SoC.
+
+properties:
+ compatible:
+ items:
+ - const: airoha,en7581-gpio-sysctl
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ pinctrl:
+ type: object
+ $ref: /schemas/pinctrl/airoha,en7581-pinctrl.yaml
+ description:
+ Child node definition for EN7581 Pin controller
+
+ pwm:
+ type: object
+ $ref: /schemas/pwm/airoha,en7581-pwm.yaml
+ description:
+ Child node definition for EN7581 PWM controller
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ system-controller@1fbf0200 {
+ compatible = "airoha,en7581-gpio-sysctl", "syscon", "simple-mfd";
+ reg = <0x1fbf0200 0xc0>;
+
+ pinctrl {
+ compatible = "airoha,en7581-pinctrl";
+
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ mmc-pins {
+ mux {
+ function = "emmc";
+ groups = "emmc";
+ };
+ };
+
+ mdio-pins {
+ mux {
+ function = "mdio";
+ groups = "mdio";
+ };
+
+ conf {
+ pins = "gpio2";
+ output-enable;
+ };
+ };
+ };
+
+ pwm {
+ compatible = "airoha,en7581-pwm";
+
+ #pwm-cells = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
index f591332fc462..93f5065a6280 100644
--- a/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
+++ b/Documentation/devicetree/bindings/mfd/allwinner,sun4i-a10-ts.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/allwinner,sun4i-a10-ts.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Resistive Touchscreen Controller Device Tree Bindings
+title: Allwinner A10 Resistive Touchscreen Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
index 021d33cb3dd6..ca0e9f1f2354 100644
--- a/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
+++ b/Documentation/devicetree/bindings/mfd/allwinner,sun6i-a31-prcm.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/allwinner,sun6i-a31-prcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 PRCM Device Tree Bindings
+title: Allwinner A31 PRCM
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -20,7 +20,7 @@ properties:
maxItems: 1
patternProperties:
- "^.*_(clk|rst)$":
+ "^.*-(clk|rst)$":
type: object
unevaluatedProperties: false
@@ -34,6 +34,9 @@ patternProperties:
- allwinner,sun6i-a31-clock-reset
- fixed-factor-clock
+ required:
+ - compatible
+
allOf:
- if:
properties:
@@ -55,25 +58,17 @@ patternProperties:
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 2
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -85,25 +80,17 @@ patternProperties:
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -119,9 +106,6 @@ patternProperties:
offset of the bit controlling this particular gate in
the register.
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
@@ -129,16 +113,11 @@ patternProperties:
minItems: 1
maxItems: 32
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -150,9 +129,6 @@ patternProperties:
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 4
description: >
@@ -162,16 +138,11 @@ patternProperties:
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -183,16 +154,8 @@ patternProperties:
"#reset-cells":
const: 1
- # Already checked in the main schema
- compatible: true
-
- phandle: true
-
required:
- "#reset-cells"
- - compatible
-
- additionalProperties: false
required:
- compatible
@@ -208,7 +171,7 @@ examples:
compatible = "allwinner,sun6i-a31-prcm";
reg = <0x01f01400 0x200>;
- ar100: ar100_clk {
+ ar100: ar100-clk {
compatible = "allwinner,sun6i-a31-ar100-clk";
#clock-cells = <0>;
clocks = <&rtc 0>, <&osc24M>,
@@ -217,7 +180,7 @@ examples:
clock-output-names = "ar100";
};
- ahb0: ahb0_clk {
+ ahb0: ahb0-clk {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <1>;
@@ -226,14 +189,14 @@ examples:
clock-output-names = "ahb0";
};
- apb0: apb0_clk {
+ apb0: apb0-clk {
compatible = "allwinner,sun6i-a31-apb0-clk";
#clock-cells = <0>;
clocks = <&ahb0>;
clock-output-names = "apb0";
};
- apb0_gates: apb0_gates_clk {
+ apb0_gates: apb0-gates-clk {
compatible = "allwinner,sun6i-a31-apb0-gates-clk";
#clock-cells = <1>;
clocks = <&apb0>;
@@ -243,14 +206,14 @@ examples:
"apb0_i2c";
};
- ir_clk: ir_clk {
+ ir_clk: ir-clk {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
clocks = <&rtc 0>, <&osc24M>;
clock-output-names = "ir";
};
- apb0_rst: apb0_rst {
+ apb0_rst: apb0-rst {
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml b/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
index 01f4f5210574..e51f85519911 100644
--- a/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
+++ b/Documentation/devicetree/bindings/mfd/allwinner,sun8i-a23-prcm.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/allwinner,sun8i-a23-prcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A23 PRCM Device Tree Bindings
+title: Allwinner A23 PRCM
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -57,25 +57,17 @@ patternProperties:
"#clock-cells":
const: 0
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -91,9 +83,6 @@ patternProperties:
offset of the bit controlling this particular gate in
the register.
- # Already checked in the main schema
- compatible: true
-
clocks:
maxItems: 1
@@ -101,16 +90,11 @@ patternProperties:
minItems: 1
maxItems: 32
- phandle: true
-
required:
- "#clock-cells"
- - compatible
- clocks
- clock-output-names
- additionalProperties: false
-
- if:
properties:
compatible:
@@ -122,34 +106,8 @@ patternProperties:
"#reset-cells":
const: 1
- # Already checked in the main schema
- compatible: true
-
- phandle: true
-
required:
- "#reset-cells"
- - compatible
-
- additionalProperties: false
-
- - if:
- properties:
- compatible:
- contains:
- const: allwinner,sun8i-a23-codec-analog
-
- then:
- properties:
- # Already checked in the main schema
- compatible: true
-
- phandle: true
-
- required:
- - compatible
-
- additionalProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml
new file mode 100644
index 000000000000..c442c3cdffed
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ampere,smpro.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ampere Altra SMPro firmware driver
+
+maintainers:
+ - Quan Nguyen <quan@os.amperecomputing.com>
+
+description: |
+ Ampere Altra SMPro firmware may contain different blocks like hardware
+ monitoring, error monitoring and other miscellaneous features.
+
+properties:
+ compatible:
+ enum:
+ - ampere,smpro
+
+ reg:
+ description:
+ I2C device address.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ smpro@4f {
+ compatible = "ampere,smpro";
+ reg = <0x4f>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/ams,as3711.yaml b/Documentation/devicetree/bindings/mfd/ams,as3711.yaml
new file mode 100644
index 000000000000..ad8649cbb2cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ams,as3711.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ams,as3711.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Austria MicroSystems AS3711 Quad Buck High Current PMIC with Charger
+
+maintainers:
+ - Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
+
+description:
+ AS3711 is an I2C PMIC from Austria MicroSystems with multiple DC/DC and LDO
+ power supplies, a battery charger and an RTC. So far only bindings for the
+ two step-up DC/DC converters are defined.
+
+properties:
+ compatible:
+ const: ams,as3711
+
+ reg:
+ maxItems: 1
+
+ backlight:
+ description:
+ Step-up converter configuration, to be used as a backlight source
+ type: object
+ additionalProperties: false
+ properties:
+ compatible:
+ const: ams,as3711-bl
+
+ su1-dev:
+ description: Framebuffer phandle for the first step-up converter
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ su1-max-uA:
+ description: Maximum current for the first step-up converter
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ su2-dev:
+ description: Framebuffer phandle for the second step-up converter
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ su2-max-uA:
+ description: Maximum current for the second step-up converter
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ su2-feedback-voltage:
+ description: Second step-up converter uses voltage feedback
+ type: boolean
+
+ su2-feedback-curr1:
+ description:
+ Second step-up converter uses CURR1 input for current feedback
+ type: boolean
+
+ su2-feedback-curr2:
+ description:
+ Second step-up converter uses CURR2 input for current feedback
+ type: boolean
+
+ su2-feedback-curr3:
+ description:
+ Second step-up converter uses CURR3 input for current feedback
+ type: boolean
+
+ su2-feedback-curr-auto:
+ description:
+ Second step-up converter uses automatic current feedback selection
+ type: boolean
+
+ su2-fbprot-lx-sd4:
+ description:
+ Second step-up converter uses LX_SD4 for over-voltage protection
+ type: boolean
+
+ su2-fbprot-gpio2:
+ description:
+ Second step-up converter uses GPIO2 for over-voltage protection
+ type: boolean
+
+ su2-fbprot-gpio3:
+ description:
+ Second step-up converter uses GPIO3 for over-voltage protection
+ type: boolean
+
+ su2-fbprot-gpio4:
+ description:
+ Second step-up converter uses GPIO4 for over-voltage protection
+ type: boolean
+
+ su2-auto-curr1:
+ description:
+ Second step-up converter uses CURR1 input for automatic current
+ feedback
+ type: boolean
+
+ su2-auto-curr2:
+ description:
+ Second step-up converter uses CURR2 input for automatic current
+ feedback
+ type: boolean
+
+ su2-auto-curr3:
+ description:
+ Second step-up converter uses CURR3 input for automatic current
+ feedback
+ type: boolean
+
+ required:
+ - compatible
+
+ dependentRequired:
+ # To use the SU1 converter as a backlight source the following two
+ # properties must be provided:
+ su1-dev: [ su1-max-uA ]
+ su1-max-uA: [ su1-dev ]
+
+ # To use the SU2 converter as a backlight source the following two
+ # properties must be provided:
+ su2-dev: [ su2-max-uA ]
+ su2-max-uA: [ su2-dev ]
+
+ su2-feedback-voltage: [ su2-dev ]
+ su2-feedback-curr1: [ su2-dev ]
+ su2-feedback-curr2: [ su2-dev ]
+ su2-feedback-curr3: [ su2-dev ]
+ su2-feedback-curr-auto: [ su2-dev ]
+ su2-fbprot-lx-sd4: [ su2-dev ]
+ su2-fbprot-gpio2: [ su2-dev ]
+ su2-fbprot-gpio3: [ su2-dev ]
+ su2-fbprot-gpio4: [ su2-dev ]
+ su2-auto-curr1: [ su2-feedback-curr-auto ]
+ su2-auto-curr2: [ su2-feedback-curr-auto ]
+ su2-auto-curr3: [ su2-feedback-curr-auto ]
+
+ dependentSchemas:
+ su2-dev:
+ allOf:
+ - oneOf:
+ - required:
+ - su2-feedback-voltage
+ - required:
+ - su2-feedback-curr1
+ - required:
+ - su2-feedback-curr2
+ - required:
+ - su2-feedback-curr3
+ - required:
+ - su2-feedback-curr-auto
+ - oneOf:
+ - required:
+ - su2-fbprot-lx-sd4
+ - required:
+ - su2-fbprot-gpio2
+ - required:
+ - su2-fbprot-gpio3
+ - required:
+ - su2-fbprot-gpio4
+
+ su2-feedback-curr-auto:
+ anyOf:
+ - required:
+ - su2-auto-curr1
+ - required:
+ - su2-auto-curr2
+ - required:
+ - su2-auto-curr3
+
+ regulators:
+ description: Other DC/DC and LDO supplies
+ type: object
+ unevaluatedProperties: false
+ patternProperties:
+ "^(sd[1-4]|ldo[1-8])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@40 {
+ compatible = "ams,as3711";
+ reg = <0x40>;
+
+ regulators {
+ sd4 {
+ regulator-name = "1.215V";
+ regulator-min-microvolt = <1215000>;
+ regulator-max-microvolt = <1235000>;
+ };
+ ldo2 {
+ regulator-name = "2.8V CPU";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ backlight {
+ compatible = "ams,as3711-bl";
+ su2-dev = <&lcdc>;
+ su2-max-uA = <36000>;
+ su2-feedback-curr-auto;
+ su2-fbprot-gpio4;
+ su2-auto-curr1;
+ su2-auto-curr2;
+ su2-auto-curr3;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
new file mode 100644
index 000000000000..5429538f7e2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/apple,smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple Mac System Management Controller
+
+maintainers:
+ - Sven Peter <sven@kernel.org>
+
+description:
+ Apple Mac System Management Controller implements various functions
+ such as GPIO, RTC, power, reboot.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: apple,t6020-smc
+ - const: apple,t8103-smc
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,t6000-smc
+ - apple,t8103-smc
+ - apple,t8112-smc
+ - const: apple,smc
+
+ reg:
+ items:
+ - description: SMC area
+ - description: SRAM area
+
+ reg-names:
+ items:
+ - const: smc
+ - const: sram
+
+ mboxes:
+ maxItems: 1
+
+ gpio:
+ $ref: /schemas/gpio/apple,smc-gpio.yaml
+
+ reboot:
+ $ref: /schemas/power/reset/apple,smc-reboot.yaml
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - mboxes
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ smc@23e400000 {
+ compatible = "apple,t8103-smc", "apple,smc";
+ reg = <0x2 0x3e400000 0x0 0x4000>,
+ <0x2 0x3fe00000 0x0 0x100000>;
+ reg-names = "smc", "sram";
+ mboxes = <&smc_mbox>;
+
+ smc_gpio: gpio {
+ compatible = "apple,smc-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ reboot {
+ compatible = "apple,smc-reboot";
+ nvmem-cells = <&shutdown_flag>, <&boot_stage>,
+ <&boot_error_count>, <&panic_count>;
+ nvmem-cell-names = "shutdown_flag", "boot_stage",
+ "boot_error_count", "panic_count";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/arm,dev-platforms-syscon.yaml b/Documentation/devicetree/bindings/mfd/arm,dev-platforms-syscon.yaml
new file mode 100644
index 000000000000..46b164ae0831
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/arm,dev-platforms-syscon.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/arm,dev-platforms-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Ltd Developer Platforms System Controllers
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ The Arm Ltd Integrator, Realview, and Versatile families of developer
+ platforms are contain various system controller blocks. Often these blocks
+ are part of a daughterboard or motherboard module.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - arm,integrator-ap-syscon
+ - arm,integrator-cp-syscon
+ - arm,integrator-sp-syscon
+ - arm,im-pd1-syscon
+ - const: syscon
+ - items:
+ - enum:
+ - arm,core-module-integrator
+ - arm,integrator-ap-syscon
+ - arm,integrator-cp-syscon
+ - arm,integrator-sp-syscon
+ - arm,realview-eb-syscon
+ - arm,realview-pb1176-syscon
+ - arm,realview-pb11mp-syscon
+ - arm,realview-pba8-syscon
+ - arm,realview-pbx-syscon
+ - arm,versatile-ib2-syscon
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - arm,realview-eb11mp-revb-syscon
+ - arm,realview-eb11mp-revc-syscon
+ - const: arm,realview-eb-syscon
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ type: object
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/as3711.txt b/Documentation/devicetree/bindings/mfd/as3711.txt
deleted file mode 100644
index d98cf18c721c..000000000000
--- a/Documentation/devicetree/bindings/mfd/as3711.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
-supplies, a battery charger and an RTC. So far only bindings for the two stepup
-DCDC converters are defined. Other DCDC and LDO supplies are configured, using
-standard regulator properties, they must belong to a sub-node, called
-"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
-configuration should be placed in a subnode, called "backlight."
-
-Compulsory properties:
-- compatible : must be "ams,as3711"
-- reg : specifies the I2C address
-
-To use the SU1 converter as a backlight source the following two properties must
-be provided:
-- su1-dev : framebuffer phandle
-- su1-max-uA : maximum current
-
-To use the SU2 converter as a backlight source the following two properties must
-be provided:
-- su2-dev : framebuffer phandle
-- su1-max-uA : maximum current
-
-Additionally one of these properties must be provided to select the type of
-feedback used:
-- su2-feedback-voltage : voltage feedback is used
-- su2-feedback-curr1 : CURR1 input used for current feedback
-- su2-feedback-curr2 : CURR2 input used for current feedback
-- su2-feedback-curr3 : CURR3 input used for current feedback
-- su2-feedback-curr-auto: automatic current feedback selection
-
-and one of these to select the over-voltage protection pin
-- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
-- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
-- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
-- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
-
-If "su2-feedback-curr-auto" is selected, one or more of the following properties
-have to be specified:
-- su2-auto-curr1 : use CURR1 input for current feedback
-- su2-auto-curr2 : use CURR2 input for current feedback
-- su2-auto-curr3 : use CURR3 input for current feedback
-
-Example:
-
-as3711@40 {
- compatible = "ams,as3711";
- reg = <0x40>;
-
- regulators {
- sd4 {
- regulator-name = "1.215V";
- regulator-min-microvolt = <1215000>;
- regulator-max-microvolt = <1235000>;
- };
- ldo2 {
- regulator-name = "2.8V CPU";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-always-on;
- regulator-boot-on;
- };
- };
-
- backlight {
- compatible = "ams,as3711-bl";
- su2-dev = <&lcdc>;
- su2-max-uA = <36000>;
- su2-feedback-curr-auto;
- su2-fbprot-gpio4;
- su2-auto-curr1;
- su2-auto-curr2;
- su2-auto-curr3;
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
index 1689b986f441..da1887d7a8fe 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
@@ -9,6 +9,8 @@ title: Aspeed System Control Unit
description:
The Aspeed System Control Unit manages the global behaviour of the SoC,
configuring elements such as clocks, pinmux, and reset.
+ In AST2700 SOC which has two soc connection, each soc have its own scu
+ register control, ast2700-scu0 for soc0, ast2700-scu1 for soc1.
maintainers:
- Joel Stanley <joel@jms.id.au>
@@ -21,6 +23,8 @@ properties:
- aspeed,ast2400-scu
- aspeed,ast2500-scu
- aspeed,ast2600-scu
+ - aspeed,ast2700-scu0
+ - aspeed,ast2700-scu1
- const: syscon
- const: simple-mfd
@@ -30,7 +34,8 @@ properties:
ranges: true
'#address-cells':
- const: 1
+ minimum: 1
+ maximum: 2
'#size-cells':
const: 1
@@ -43,18 +48,63 @@ properties:
patternProperties:
'^p2a-control@[0-9a-f]+$':
- description: See Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
+ description: >
+ PCI-to-AHB Bridge Control
+
+ The bridge is available on platforms with the VGA enabled on the Aspeed
+ device. In this case, the host has access to a 64KiB window into all of
+ the BMC's memory. The BMC can disable this bridge. If the bridge is
+ enabled, the host has read access to all the regions of memory, however
+ the host only has read and write access depending on a register
+ controlled by the BMC.
type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-p2a-ctrl
+ - aspeed,ast2500-p2a-ctrl
+ reg:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+ description:
+ A reserved_memory region to be used for the PCI to AHB mapping
+
+ required:
+ - compatible
+ - reg
'^pinctrl(@[0-9a-f]+)?$':
- oneOf:
- - $ref: /schemas/pinctrl/aspeed,ast2400-pinctrl.yaml
- - $ref: /schemas/pinctrl/aspeed,ast2500-pinctrl.yaml
- - $ref: /schemas/pinctrl/aspeed,ast2600-pinctrl.yaml
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ enum:
+ - aspeed,ast2400-pinctrl
+ - aspeed,ast2500-pinctrl
+ - aspeed,ast2600-pinctrl
+
+ required:
+ - compatible
'^interrupt-controller@[0-9a-f]+$':
- description: See Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2xxx-scu-ic.txt
type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ enum:
+ - aspeed,ast2500-scu-ic
+ - aspeed,ast2600-scu-ic0
+ - aspeed,ast2600-scu-ic1
+ - aspeed,ast2700-scu-ic0
+ - aspeed,ast2700-scu-ic1
+ - aspeed,ast2700-scu-ic2
+ - aspeed,ast2700-scu-ic3
'^silicon-id@[0-9a-f]+$':
description: Unique hardware silicon identifiers within the SoC
@@ -68,6 +118,7 @@ patternProperties:
- aspeed,ast2400-silicon-id
- aspeed,ast2500-silicon-id
- aspeed,ast2600-silicon-id
+ - aspeed,ast2700-silicon-id
- const: aspeed,silicon-id
reg:
@@ -102,6 +153,11 @@ examples:
#size-cells = <1>;
ranges = <0x0 0x1e6e2000 0x1000>;
+ p2a-control@2c {
+ compatible = "aspeed,ast2400-p2a-ctrl";
+ reg = <0x2c 0x4>;
+ };
+
silicon-id@7c {
compatible = "aspeed,ast2500-silicon-id", "aspeed,silicon-id";
reg = <0x7c 0x4>, <0x150 0x8>;
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
deleted file mode 100644
index aea5370efd97..000000000000
--- a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device tree bindings for Aspeed SoC Display Controller (GFX)
-
-The Aspeed SoC Display Controller primarily does as its name suggests, but also
-participates in pinmux requests on the g5 SoCs. It is therefore considered a
-syscon device.
-
-Required properties:
-- compatible: "aspeed,ast2500-gfx", "syscon"
-- reg: contains offset/length value of the GFX memory
- region.
-
-Example:
-
-gfx: display@1e6e6000 {
- compatible = "aspeed,ast2500-gfx", "syscon";
- reg = <0x1e6e6000 0x1000>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml
index 750996d9a175..cbc3a2485a2f 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml
+++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# # Copyright (c) 2021 Aspeed Tehchnology Inc.
+# # Copyright (c) 2021 Aspeed Technology Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/aspeed-lpc.yaml#
@@ -27,7 +27,7 @@ description:
as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
management and bus snoop configuration.
- * A set of SuperIO[3] scratch registers enableing implementation of e.g. custom
+ * A set of SuperIO[3] scratch registers enabling implementation of e.g. custom
hardware management protocols for handover between the host and baseboard
management controller.
@@ -48,16 +48,16 @@ properties:
reg:
maxItems: 1
- "#address-cells":
+ '#address-cells':
const: 1
- "#size-cells":
+ '#size-cells':
const: 1
ranges: true
patternProperties:
- "^lpc-ctrl@[0-9a-f]+$":
+ '^lpc-ctrl@[0-9a-f]+$':
type: object
additionalProperties: false
@@ -92,7 +92,7 @@ patternProperties:
- compatible
- clocks
- "^reset-controller@[0-9a-f]+$":
+ '^reset-controller@[0-9a-f]+$':
type: object
additionalProperties: false
@@ -118,7 +118,7 @@ patternProperties:
- compatible
- '#reset-cells'
- "^lpc-snoop@[0-9a-f]+$":
+ '^lpc-snoop@[0-9a-f]+$':
type: object
additionalProperties: false
@@ -137,6 +137,9 @@ patternProperties:
reg:
maxItems: 1
+ clocks:
+ maxItems: 1
+
interrupts:
maxItems: 1
@@ -149,15 +152,15 @@ patternProperties:
- interrupts
- snoop-ports
- "^uart-routing@[0-9a-f]+$":
+ '^uart-routing@[0-9a-f]+$':
$ref: /schemas/soc/aspeed/uart-routing.yaml#
description: The UART routing control under LPC register space
required:
- compatible
- reg
- - "#address-cells"
- - "#size-cells"
+ - '#address-cells'
+ - '#size-cells'
- ranges
additionalProperties:
diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml
new file mode 100644
index 000000000000..f6f47999c6c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-gpbr.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/atmel,at91sam9260-gpbr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 General Purpose Backup Registers
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+
+description:
+ The system controller embeds 256 bits of General Purpose Backup
+ registers organized as 8 32-bit registers.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at91sam9260-gpbr
+ - microchip,sama7d65-gpbr
+ - const: syscon
+ - items:
+ - enum:
+ - microchip,sam9x60-gpbr
+ - microchip,sam9x7-gpbr
+ - const: atmel,at91sam9260-gpbr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@fffffd50 {
+ compatible = "atmel,at91sam9260-gpbr", "syscon";
+ reg = <0xfffffd50 0x10>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml
new file mode 100644
index 000000000000..447b3a3edbfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel,at91sam9260-matrix.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/atmel,at91sam9260-matrix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 Bus Matrix
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+
+description:
+ The Bus Matrix (MATRIX) implements a multi-layer AHB, based on the
+ AHB-Lite protocol, that enables parallel access paths between multiple
+ masters and slaves in a system, thus increasing the overall bandwidth.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at91sam9260-matrix
+ - atmel,at91sam9261-matrix
+ - atmel,at91sam9263-matrix
+ - atmel,at91sam9rl-matrix
+ - atmel,at91sam9g45-matrix
+ - atmel,at91sam9n12-matrix
+ - atmel,at91sam9x5-matrix
+ - atmel,sama5d3-matrix
+ - const: syscon
+ - items:
+ - enum:
+ - microchip,sam9x60-matrix
+ - microchip,sam9x7-matrix
+ - const: atmel,at91sam9x5-matrix
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@ffffec00 {
+ compatible = "atmel,sama5d3-matrix", "syscon";
+ reg = <0xffffec00 0x200>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml
new file mode 100644
index 000000000000..4aa36903e755
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel,hlcdc.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/atmel,hlcdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel's HLCD Controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+ - Claudiu Beznea <claudiu.beznea@tuxon.dev>
+
+description:
+ The Atmel HLCDC (HLCD Controller) IP available on Atmel SoCs exposes two
+ subdevices, a PWM chip and a Display Controller.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91sam9n12-hlcdc
+ - atmel,at91sam9x5-hlcdc
+ - atmel,sama5d2-hlcdc
+ - atmel,sama5d3-hlcdc
+ - atmel,sama5d4-hlcdc
+ - microchip,sam9x60-hlcdc
+ - microchip,sam9x75-xlcdc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+
+ clock-names:
+ items:
+ - const: periph_clk
+ - const: sys_clk
+ - const: slow_clk
+ - const: lvds_pll_clk
+ minItems: 3
+
+ display-controller:
+ $ref: /schemas/display/atmel/atmel,hlcdc-display-controller.yaml
+
+ pwm:
+ $ref: /schemas/pwm/atmel,hlcdc-pwm.yaml
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ lcd_controller: lcd-controller@f0030000 {
+ compatible = "atmel,sama5d3-hlcdc";
+ reg = <0xf0030000 0x2000>;
+ clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
+ clock-names = "periph_clk", "sys_clk", "slow_clk";
+ interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ display-controller {
+ compatible = "atmel,hlcdc-display-controller";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ hlcdc_panel_output: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+ };
+ };
+
+ pwm {
+ compatible = "atmel,hlcdc-pwm";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_pwm>;
+ #pwm-cells = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml b/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml
new file mode 100644
index 000000000000..c7d6cf96796c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/atmel,sama5d2-flexcom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Flexcom (Flexible Serial Communication Unit)
+
+maintainers:
+ - Kavyasree Kotagiri <kavyasree.kotagiri@microchip.com>
+
+description:
+ The Microchip Flexcom is just a wrapper which embeds a SPI controller,
+ an I2C controller and an USART. Only one function can be used at a
+ time and is chosen at boot time according to the device tree.
+
+properties:
+ compatible:
+ oneOf:
+ - const: atmel,sama5d2-flexcom
+ - items:
+ - enum:
+ - microchip,sam9x7-flexcom
+ - microchip,sama7d65-flexcom
+ - microchip,sama7g5-flexcom
+ - const: atmel,sama5d2-flexcom
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges:
+ description:
+ One range for the full I/O register region. (including USART,
+ TWI and SPI registers).
+ items:
+ maxItems: 3
+
+ atmel,flexcom-mode:
+ description: |
+ Specifies the flexcom mode as follows:
+ 1: USART
+ 2: SPI
+ 3: I2C.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3]
+
+patternProperties:
+ "^serial@[0-9a-f]+$":
+ type: object
+ description:
+ Child node describing USART. See atmel-usart.txt for details
+ of USART bindings.
+
+ "^spi@[0-9a-f]+$":
+ type: object
+ description:
+ Child node describing SPI. See ../spi/spi_atmel.txt for details
+ of SPI bindings.
+
+ "^i2c@[0-9a-f]+$":
+ $ref: /schemas/i2c/atmel,at91sam-i2c.yaml
+ description:
+ Child node describing I2C.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - atmel,flexcom-mode
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ flx0: flexcom@f8034000 {
+ compatible = "atmel,sama5d2-flexcom";
+ reg = <0xf8034000 0x200>;
+ clocks = <&flx0_clk>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xf8034000 0x800>;
+ atmel,flexcom-mode = <2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
deleted file mode 100644
index 9d837535637b..000000000000
--- a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
-
-The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
-controller and an USART. Only one function can be used at a time and is chosen
-at boot time according to the device tree.
-
-Required properties:
-- compatible: Should be "atmel,sama5d2-flexcom"
-- reg: Should be the offset/length value for Flexcom dedicated
- I/O registers (without USART, TWI or SPI registers).
-- clocks: Should be the Flexcom peripheral clock from PMC.
-- #address-cells: Should be <1>
-- #size-cells: Should be <1>
-- ranges: Should be one range for the full I/O register region
- (including USART, TWI and SPI registers).
-- atmel,flexcom-mode: Should be one of the following values:
- - <1> for USART
- - <2> for SPI
- - <3> for I2C
-
-Required child:
-A single available child device of type matching the "atmel,flexcom-mode"
-property.
-
-The phandle provided by the clocks property of the child is the same as one for
-the Flexcom parent.
-
-For other properties, please refer to the documentations of the respective
-device:
-- ../serial/atmel-usart.txt
-- ../spi/spi_atmel.txt
-- ../i2c/i2c-at91.txt
-
-Example:
-
-flexcom@f8034000 {
- compatible = "atmel,sama5d2-flexcom";
- reg = <0xf8034000 0x200>;
- clocks = <&flx0_clk>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0xf8034000 0x800>;
- atmel,flexcom-mode = <2>;
-
- spi@400 {
- compatible = "atmel,at91rm9200-spi";
- reg = <0x400 0x200>;
- interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_flx0_default>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&flx0_clk>;
- clock-names = "spi_clk";
- atmel,fifo-size = <32>;
-
- flash@0 {
- compatible = "atmel,at25f512b";
- reg = <0>;
- spi-max-frequency = <20000000>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt b/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt
deleted file mode 100644
index e8c525569f10..000000000000
--- a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device tree bindings for Atmel GPBR (General Purpose Backup Registers)
-
-The GPBR are a set of battery-backed registers.
-
-Required properties:
-- compatible: Should be one of the following:
- "atmel,at91sam9260-gpbr", "syscon"
- "microchip,sam9x60-gpbr", "syscon"
-- reg: contains offset/length value of the GPBR memory
- region.
-
-Example:
-
-gpbr: gpbr@fffffd50 {
- compatible = "atmel,at91sam9260-gpbr", "syscon";
- reg = <0xfffffd50 0x10>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
deleted file mode 100644
index 5f8880cc757e..000000000000
--- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
-
-Required properties:
- - compatible: value should be one of the following:
- "atmel,at91sam9n12-hlcdc"
- "atmel,at91sam9x5-hlcdc"
- "atmel,sama5d2-hlcdc"
- "atmel,sama5d3-hlcdc"
- "atmel,sama5d4-hlcdc"
- "microchip,sam9x60-hlcdc"
- - reg: base address and size of the HLCDC device registers.
- - clock-names: the name of the 3 clocks requested by the HLCDC device.
- Should contain "periph_clk", "sys_clk" and "slow_clk".
- - clocks: should contain the 3 clocks requested by the HLCDC device.
- - interrupts: should contain the description of the HLCDC interrupt line
-
-The HLCDC IP exposes two subdevices:
- - a PWM chip: see ../pwm/atmel-hlcdc-pwm.txt
- - a Display Controller: see ../display/atmel/hlcdc-dc.txt
-
-Example:
-
- hlcdc: hlcdc@f0030000 {
- compatible = "atmel,sama5d3-hlcdc";
- reg = <0xf0030000 0x2000>;
- clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
- clock-names = "periph_clk","sys_clk", "slow_clk";
- interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
-
- hlcdc-display-controller {
- compatible = "atmel,hlcdc-display-controller";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- hlcdc_panel_output: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&panel_input>;
- };
- };
- };
-
- hlcdc_pwm: hlcdc-pwm {
- compatible = "atmel,hlcdc-pwm";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcd_pwm>;
- #pwm-cells = <3>;
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt b/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
deleted file mode 100644
index 89d05c64fb01..000000000000
--- a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Device tree bindings for Atmel Bus Matrix
-
-The Bus Matrix registers are used to configure Atmel SoCs internal bus
-behavior (master/slave priorities, undefined burst length type, ...)
-
-Required properties:
-- compatible: Should be one of the following
- "atmel,at91sam9260-matrix", "syscon"
- "atmel,at91sam9261-matrix", "syscon"
- "atmel,at91sam9263-matrix", "syscon"
- "atmel,at91sam9rl-matrix", "syscon"
- "atmel,at91sam9g45-matrix", "syscon"
- "atmel,at91sam9n12-matrix", "syscon"
- "atmel,at91sam9x5-matrix", "syscon"
- "atmel,sama5d3-matrix", "syscon"
- "microchip,sam9x60-matrix", "syscon"
-- reg: Contains offset/length value of the Bus Matrix
- memory region.
-
-Example:
-
-matrix: matrix@ffffec00 {
- compatible = "atmel,sama5d3-matrix", "syscon";
- reg = <0xffffec00 0x200>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
index 5696d9fcb5dc..fd62add38a79 100644
--- a/Documentation/devicetree/bindings/mfd/atmel-smc.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-smc.txt
@@ -10,6 +10,7 @@ Required properties:
"atmel,sama5d3-smc", "syscon"
"atmel,sama5d2-smc", "syscon"
"microchip,sam9x60-smc", "syscon"
+ "microchip,sam9x7-smc", "atmel,at91sam9260-smc", "syscon"
- reg: Contains offset/length value of the SMC memory
region.
diff --git a/Documentation/devicetree/bindings/mfd/atmel-usart.txt b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
deleted file mode 100644
index a09133066aff..000000000000
--- a/Documentation/devicetree/bindings/mfd/atmel-usart.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
-
-Required properties for USART:
-- compatible: Should be one of the following:
- - "atmel,at91rm9200-usart"
- - "atmel,at91sam9260-usart"
- - "microchip,sam9x60-usart"
- - "atmel,at91rm9200-dbgu", "atmel,at91rm9200-usart"
- - "atmel,at91sam9260-dbgu", "atmel,at91sam9260-usart"
- - "microchip,sam9x60-dbgu", "microchip,sam9x60-usart"
-- reg: Should contain registers location and length
-- interrupts: Should contain interrupt
-- clock-names: tuple listing input clock names.
- Required elements: "usart"
-- clocks: phandles to input clocks.
-
-Required properties for USART in SPI mode:
-- #size-cells : Must be <0>
-- #address-cells : Must be <1>
-- cs-gpios: chipselects (internal cs not supported)
-- atmel,usart-mode : Must be <AT91_USART_MODE_SPI> (found in dt-bindings/mfd/at91-usart.h)
-
-Optional properties in serial and SPI mode:
-- dma bindings for dma transfer:
- - dmas: DMA specifier, consisting of a phandle to DMA controller node,
- memory peripheral interface and USART DMA channel ID, FIFO configuration.
- The order of DMA channels is fixed. The first DMA channel must be TX
- associated channel and the second one must be RX associated channel.
- Refer to dma.txt and atmel-dma.txt for details.
- - dma-names: "tx" for TX channel.
- "rx" for RX channel.
- The order of dma-names is also fixed. The first name must be "tx"
- and the second one must be "rx" as in the examples below.
-
-Optional properties in serial mode:
-- atmel,use-dma-rx: use of PDC or DMA for receiving data
-- atmel,use-dma-tx: use of PDC or DMA for transmitting data
-- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively.
- It will use specified PIO instead of the peripheral function pin for the USART feature.
- If unsure, don't specify this property.
-- atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO
- capable USARTs.
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt
-
-<chip> compatible description:
-- at91rm9200: legacy USART support
-- at91sam9260: generic USART implementation for SAM9 SoCs
-
-Example:
-- use PDC:
- usart0: serial@fff8c000 {
- compatible = "atmel,at91sam9260-usart";
- reg = <0xfff8c000 0x4000>;
- interrupts = <7>;
- clocks = <&usart0_clk>;
- clock-names = "usart";
- atmel,use-dma-rx;
- atmel,use-dma-tx;
- rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>;
- cts-gpios = <&pioD 16 GPIO_ACTIVE_LOW>;
- dtr-gpios = <&pioD 17 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&pioD 18 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&pioD 20 GPIO_ACTIVE_LOW>;
- rng-gpios = <&pioD 19 GPIO_ACTIVE_LOW>;
- };
-
-- use DMA:
- usart0: serial@f001c000 {
- compatible = "atmel,at91sam9260-usart";
- reg = <0xf001c000 0x100>;
- interrupts = <12 4 5>;
- clocks = <&usart0_clk>;
- clock-names = "usart";
- atmel,use-dma-rx;
- atmel,use-dma-tx;
- dmas = <&dma0 2 0x3>,
- <&dma0 2 0x204>;
- dma-names = "tx", "rx";
- atmel,fifo-size = <32>;
- };
-
-- SPI mode:
- #include <dt-bindings/mfd/at91-usart.h>
-
- spi0: spi@f001c000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "atmel,at91rm9200-usart", "atmel,at91sam9260-usart";
- atmel,usart-mode = <AT91_USART_MODE_SPI>;
- reg = <0xf001c000 0x100>;
- interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
- clocks = <&usart0_clk>;
- clock-names = "usart";
- dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
- <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
- dma-names = "tx", "rx";
- cs-gpios = <&pioB 3 0>;
- };
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt
deleted file mode 100644
index be51a15e05f9..000000000000
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.txt
+++ /dev/null
@@ -1,39 +0,0 @@
--------------------------------
-BCM590xx Power Management Units
--------------------------------
-
-Required properties:
-- compatible: "brcm,bcm59056"
-- reg: I2C slave address
-- interrupts: interrupt for the PMU. Generic interrupt client node bindings
- are described in interrupt-controller/interrupts.txt
-
-------------------
-Voltage Regulators
-------------------
-
-Optional child nodes:
-- regulators: container node for regulators following the generic
- regulator binding in regulator/regulator.txt
-
- The valid regulator node names for BCM59056 are:
- rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
- mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
- csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
- gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
- vbus
-
-Example:
- pmu: bcm59056@8 {
- compatible = "brcm,bcm59056";
- reg = <0x08>;
- interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
- regulators {
- rfldo_reg: rfldo {
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml
new file mode 100644
index 000000000000..b67d7a723fc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/brcm,bcm59056.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM590xx Power Management Units
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm59054
+ - brcm,bcm59056
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm59054
+ then:
+ properties:
+ regulators:
+ $ref: /schemas/regulator/brcm,bcm59054.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm59056
+ then:
+ properties:
+ regulators:
+ $ref: /schemas/regulator/brcm,bcm59056.yaml#
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "brcm,bcm59056";
+ reg = <0x08>;
+ interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+
+ regulators {
+ rfldo {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
index afc569bc15cf..cb480162f967 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/brcm,bcm6318-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6318 GPIO System Controller Device Tree Bindings
+title: Broadcom BCM6318 GPIO System Controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
@@ -35,16 +35,16 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6318-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6318-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
index c7771c86d7c1..9c2a04829da5 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/brcm,bcm63268-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM63268 GPIO System Controller Device Tree Bindings
+title: Broadcom BCM63268 GPIO System Controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
@@ -35,16 +35,16 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm63268-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm63268-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
@@ -148,47 +148,47 @@ examples:
pinctrl_nand: nand-pins {
function = "nand";
- group = "nand_grp";
+ pins = "nand_grp";
};
pinctrl_gpio35_alt: gpio35_alt-pins {
function = "gpio35_alt";
- pin = "gpio35";
+ pins = "gpio35";
};
pinctrl_dectpd: dectpd-pins {
function = "dectpd";
- group = "dectpd_grp";
+ pins = "dectpd_grp";
};
pinctrl_vdsl_phy_override_0: vdsl_phy_override_0-pins {
function = "vdsl_phy_override_0";
- group = "vdsl_phy_override_0_grp";
+ pins = "vdsl_phy_override_0_grp";
};
pinctrl_vdsl_phy_override_1: vdsl_phy_override_1-pins {
function = "vdsl_phy_override_1";
- group = "vdsl_phy_override_1_grp";
+ pins = "vdsl_phy_override_1_grp";
};
pinctrl_vdsl_phy_override_2: vdsl_phy_override_2-pins {
function = "vdsl_phy_override_2";
- group = "vdsl_phy_override_2_grp";
+ pins = "vdsl_phy_override_2_grp";
};
pinctrl_vdsl_phy_override_3: vdsl_phy_override_3-pins {
function = "vdsl_phy_override_3";
- group = "vdsl_phy_override_3_grp";
+ pins = "vdsl_phy_override_3_grp";
};
pinctrl_dsl_gpio8: dsl_gpio8-pins {
function = "dsl_gpio8";
- group = "dsl_gpio8";
+ pins = "dsl_gpio8";
};
pinctrl_dsl_gpio9: dsl_gpio9-pins {
function = "dsl_gpio9";
- group = "dsl_gpio9";
+ pins = "dsl_gpio9";
};
};
};
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
index 33963c11ae62..5f48209ed40f 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/brcm,bcm6328-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6328 GPIO System Controller Device Tree Bindings
+title: Broadcom BCM6328 GPIO System Controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
@@ -35,16 +35,16 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6328-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6328-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
index 3e44bea78b03..f1f4629565d9 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/brcm,bcm6358-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6358 GPIO System Controller Device Tree Bindings
+title: Broadcom BCM6358 GPIO System Controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
@@ -35,16 +35,16 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6358-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6358-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
index 48d14a5fe0d5..c2941638c8f2 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/brcm,bcm6362-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6362 GPIO System Controller Device Tree Bindings
+title: Broadcom BCM6362 GPIO System Controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
@@ -35,16 +35,16 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6362-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6362-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
@@ -230,7 +230,7 @@ examples:
pinctrl_nand: nand-pins {
function = "nand";
- group = "nand_grp";
+ pins = "nand_grp";
};
};
};
diff --git a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
index 307270b0cfed..44e77d77d314 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,bcm6368-gpio-sysctl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/brcm,bcm6368-gpio-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6368 GPIO System Controller Device Tree Bindings
+title: Broadcom BCM6368 GPIO System Controller
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
@@ -35,16 +35,16 @@ patternProperties:
"^gpio@[0-9a-f]+$":
# Child node
type: object
- $ref: "../gpio/brcm,bcm6345-gpio.yaml"
+ $ref: /schemas/gpio/brcm,bcm63xx-gpio.yaml
description:
GPIO controller for the SoC GPIOs. This child node definition
should follow the bindings specified in
- Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml.
+ Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml.
"^pinctrl@[0-9a-f]+$":
# Child node
type: object
- $ref: "../pinctrl/brcm,bcm6368-pinctrl.yaml"
+ $ref: /schemas/pinctrl/brcm,bcm6368-pinctrl.yaml
description:
Pin controller for the SoC pins. This child node definition
should follow the bindings specified in
@@ -240,7 +240,7 @@ examples:
pinctrl_uart1: uart1-pins {
function = "uart1";
- group = "uart1_grp";
+ pins = "uart1_grp";
};
};
};
diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
index b85819fbb07c..04910e4f88b2 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
@@ -34,19 +34,19 @@ properties:
patternProperties:
'^clock-controller@[a-f0-9]+$':
- $ref: ../clock/brcm,iproc-clocks.yaml
+ $ref: /schemas/clock/brcm,iproc-clocks.yaml
'^phy@[a-f0-9]+$':
- $ref: ../phy/bcm-ns-usb2-phy.yaml
+ $ref: /schemas/phy/bcm-ns-usb2-phy.yaml
'^pinctrl@[a-f0-9]+$':
- $ref: ../pinctrl/brcm,ns-pinmux.yaml
+ $ref: /schemas/pinctrl/brcm,ns-pinmux.yaml
'^syscon@[a-f0-9]+$':
$ref: syscon.yaml
'^thermal@[a-f0-9]+$':
- $ref: ../thermal/brcm,ns-thermal.yaml
+ $ref: /schemas/thermal/brcm,ns-thermal.yaml
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt b/Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt
deleted file mode 100644
index 82f82e069563..000000000000
--- a/Documentation/devicetree/bindings/mfd/brcm,iproc-cdru.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Broadcom iProc Chip Device Resource Unit (CDRU)
-
-Various Broadcom iProc SoCs have a set of registers that provide various
-chip specific device and resource configurations. This node allows access to
-these CDRU registers via syscon.
-
-Required properties:
-- compatible: should contain:
- "brcm,sr-cdru", "syscon" for Stingray
-- reg: base address and range of the CDRU registers
-
-Example:
- cdru: syscon@6641d000 {
- compatible = "brcm,sr-cdru", "syscon";
- reg = <0 0x6641d000 0 0x400>;
- };
diff --git a/Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt b/Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt
deleted file mode 100644
index 4421e9771b8a..000000000000
--- a/Documentation/devicetree/bindings/mfd/brcm,iproc-mhb.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Broadcom iProc Multi Host Bridge (MHB)
-
-Certain Broadcom iProc SoCs have a multi host bridge (MHB) block that controls
-the connection and configuration of 1) internal PCIe serdes; 2) PCIe endpoint
-interface; 3) access to the Nitro (network processing) engine
-
-This node allows access to these MHB registers via syscon.
-
-Required properties:
-- compatible: should contain:
- "brcm,sr-mhb", "syscon" for Stingray
-- reg: base address and range of the MHB registers
-
-Example:
- mhb: syscon@60401000 {
- compatible = "brcm,sr-mhb", "syscon";
- reg = <0 0x60401000 0 0x38c>;
- };
diff --git a/Documentation/devicetree/bindings/mfd/brcm,misc.yaml b/Documentation/devicetree/bindings/mfd/brcm,misc.yaml
index cff7d772a7db..abe24526f3d7 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,misc.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,misc.yaml
@@ -33,7 +33,7 @@ properties:
patternProperties:
'^reset-controller@[a-f0-9]+$':
- $ref: ../reset/brcm,bcm4908-misc-pcie-reset.yaml
+ $ref: /schemas/reset/brcm,bcm4908-misc-pcie-reset.yaml
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml
index 634526f790b8..e5136a37b0a3 100644
--- a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml
+++ b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml
@@ -36,6 +36,9 @@ properties:
const: 1
patternProperties:
+ '^timer@[a-f0-9]+$':
+ $ref: /schemas/timer/brcm,bcmbca-timer.yaml
+
'^watchdog@[a-f0-9]+$':
$ref: /schemas/watchdog/brcm,bcm7038-wdt.yaml
@@ -54,6 +57,11 @@ examples:
#address-cells = <1>;
#size-cells = <1>;
+ timer@0 {
+ compatible = "brcm,bcm63138-timer";
+ reg = <0x0 0x28>;
+ };
+
watchdog@28 {
compatible = "brcm,bcm7038-wdt";
reg = <0x28 0x8>;
diff --git a/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml b/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
index c24ad45cabb5..2451d0f0e4e3 100644
--- a/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
+++ b/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/canaan,k210-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Canaan Kendryte K210 System Controller Device Tree Bindings
+title: Canaan Kendryte K210 System Controller
maintainers:
- - Damien Le Moal <damien.lemoal@wdc.com>
+ - Damien Le Moal <dlemoal@kernel.org>
description:
Canaan Inc. Kendryte K210 SoC system controller which provides a
@@ -36,7 +36,7 @@ properties:
clock-controller:
# Child node
type: object
- $ref: "../clock/canaan,k210-clk.yaml"
+ $ref: /schemas/clock/canaan,k210-clk.yaml
description:
Clock controller for the SoC clocks. This child node definition
should follow the bindings specified in
@@ -45,7 +45,7 @@ properties:
reset-controller:
# Child node
type: object
- $ref: "../reset/canaan,k210-rst.yaml"
+ $ref: /schemas/reset/canaan,k210-rst.yaml
description:
Reset controller for the SoC. This child node definition
should follow the bindings specified in
@@ -54,7 +54,7 @@ properties:
syscon-reboot:
# Child node
type: object
- $ref: "../power/reset/syscon-reboot.yaml"
+ $ref: /schemas/power/reset/syscon-reboot.yaml
description:
Reboot method for the SoC. This child node definition
should follow the bindings specified in
diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
index 86f7341eb7e1..ebbedabb2bd4 100644
--- a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
+++ b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
@@ -266,7 +266,7 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/clk/lochnagar.h>
+ #include <dt-bindings/clock/lochnagar.h>
#include <dt-bindings/pinctrl/lochnagar.h>
i2c@e0004000 {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
deleted file mode 100644
index 07c69c0c6624..000000000000
--- a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Dialog DA9052/53 Power Management Integrated Circuit (PMIC)
-
-Required properties:
-- compatible : Should be "dlg,da9052", "dlg,da9053-aa",
- "dlg,da9053-ab", or "dlg,da9053-bb"
-
-Optional properties:
-- dlg,tsi-as-adc : Boolean, if set the X+, X-, Y+, Y- touchscreen
- input lines are used as general purpose analogue
- input.
-- tsiref-supply: Phandle to the regulator, which provides the reference
- voltage for the TSIREF pin. Must be provided when the
- touchscreen pins are used for ADC purposes.
-
-Sub-nodes:
-- regulators : Contain the regulator nodes. The DA9052/53 regulators are
- bound using their names as listed below:
-
- buck1 : regulator BUCK CORE
- buck2 : regulator BUCK PRO
- buck3 : regulator BUCK MEM
- buck4 : regulator BUCK PERI
- ldo1 : regulator LDO1
- ldo2 : regulator LDO2
- ldo3 : regulator LDO3
- ldo4 : regulator LDO4
- ldo5 : regulator LDO5
- ldo6 : regulator LDO6
- ldo7 : regulator LDO7
- ldo8 : regulator LDO8
- ldo9 : regulator LDO9
- ldo10 : regulator LDO10
-
- The bindings details of individual regulator device can be found in:
- Documentation/devicetree/bindings/regulator/regulator.txt
-
-Examples:
-
-i2c@63fc8000 { /* I2C1 */
-
- pmic: dialog@48 {
- compatible = "dlg,da9053-aa";
- reg = <0x48>;
-
- regulators {
- buck1 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <2075000>;
- };
-
- buck2 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <2075000>;
- };
-
- buck3 {
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <2500000>;
- };
-
- buck4 {
- regulator-min-microvolt = <925000>;
- regulator-max-microvolt = <2500000>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
deleted file mode 100644
index bab0d0e66cb3..000000000000
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ /dev/null
@@ -1,123 +0,0 @@
-* Dialog DA9062 Power Management Integrated Circuit (PMIC)
-
-Product information for the DA9062 and DA9061 devices can be found here:
-- https://www.dialog-semiconductor.com/products/da9062
-- https://www.dialog-semiconductor.com/products/da9061
-
-The DA9062 PMIC consists of:
-
-Device Supply Names Description
------- ------------ -----------
-da9062-regulator : : LDOs & BUCKs
-da9062-rtc : : Real-Time Clock
-da9062-onkey : : On Key
-da9062-watchdog : : Watchdog Timer
-da9062-thermal : : Thermal
-da9062-gpio : : GPIOs
-
-The DA9061 PMIC consists of:
-
-Device Supply Names Description
------- ------------ -----------
-da9062-regulator : : LDOs & BUCKs
-da9062-onkey : : On Key
-da9062-watchdog : : Watchdog Timer
-da9062-thermal : : Thermal
-
-======
-
-Required properties:
-
-- compatible : Should be
- "dlg,da9062" for DA9062
- "dlg,da9061" for DA9061
-- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
- modified to match the chip's OTP settings).
-- interrupts : IRQ line information.
-- interrupt-controller
-
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
-further information on IRQ bindings.
-
-Optional properties:
-
-- gpio-controller : Marks the device as a gpio controller.
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify the gpio polarity.
-
-See Documentation/devicetree/bindings/gpio/gpio.txt for further information on
-GPIO bindings.
-
-Sub-nodes:
-
-- regulators : This node defines the settings for the LDOs and BUCKs.
- The DA9062 regulators are bound using their names listed below:
-
- buck1 : BUCK_1
- buck2 : BUCK_2
- buck3 : BUCK_3
- buck4 : BUCK_4
- ldo1 : LDO_1
- ldo2 : LDO_2
- ldo3 : LDO_3
- ldo4 : LDO_4
-
- The DA9061 regulators are bound using their names listed below:
-
- buck1 : BUCK_1
- buck2 : BUCK_2
- buck3 : BUCK_3
- ldo1 : LDO_1
- ldo2 : LDO_2
- ldo3 : LDO_3
- ldo4 : LDO_4
-
- The component follows the standard regulator framework and the bindings
- details of individual regulator device can be found in:
- Documentation/devicetree/bindings/regulator/regulator.txt
-
- regulator-initial-mode may be specified for buck regulators using mode values
- from include/dt-bindings/regulator/dlg,da9063-regulator.h.
-
-- rtc : This node defines settings required for the Real-Time Clock associated
- with the DA9062. There are currently no entries in this binding, however
- compatible = "dlg,da9062-rtc" should be added if a node is created.
-
-- onkey : See ../input/da9062-onkey.txt
-
-- watchdog: See ../watchdog/da9062-watchdog.txt
-
-- thermal : See ../thermal/da9062-thermal.txt
-
-Example:
-
- pmic0: da9062@58 {
- compatible = "dlg,da9062";
- reg = <0x58>;
- interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
-
- rtc {
- compatible = "dlg,da9062-rtc";
- };
-
- regulators {
- DA9062_BUCK1: buck1 {
- regulator-name = "BUCK1";
- regulator-min-microvolt = <300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <500000>;
- regulator-max-microamp = <2000000>;
- regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
- regulator-boot-on;
- };
- DA9062_LDO1: ldo1 {
- regulator-name = "LDO_1";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <3600000>;
- regulator-boot-on;
- };
- };
- };
-
diff --git a/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
index f6967c1f6235..d3b79140cce2 100644
--- a/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
+++ b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
@@ -42,10 +42,10 @@ required:
patternProperties:
"^gpio(@[0-9a-f]+)?$":
- $ref: ../gpio/delta,tn48m-gpio.yaml
+ $ref: /schemas/gpio/delta,tn48m-gpio.yaml
"^reset-controller?$":
- $ref: ../reset/delta,tn48m-reset.yaml
+ $ref: /schemas/reset/delta,tn48m-reset.yaml
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9052.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9052.yaml
new file mode 100644
index 000000000000..1103a8cc5cea
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/dlg,da9052.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/dlg,da9052.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog DA9052/53 Power Management Integrated Circuit (PMIC)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - dlg,da9053-aa
+ - dlg,da9053-ab
+ - dlg,da9053-bb
+ - dlg,da9053-bc
+ - dlg,da9052
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dlg,tsi-as-adc:
+ type: boolean
+ description:
+ if set the X+, X-, Y+, Y- touchscreen input lines are used as general
+ purpose analogue input.
+
+ tsiref-supply:
+ description: The reference voltage for the TSIREF pin.
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^(ldo([1-9]|10)|buck[1-4])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@48 {
+ compatible = "dlg,da9053-aa";
+ reg = <0x48>;
+
+ regulators {
+ buck1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck2 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2075000>;
+ };
+
+ buck3 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ buck4 {
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
index e8e74e91070c..4f08e9ac7e56 100644
--- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/dlg,da9063.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
+title: Dialog DA906{3L,3,2,1} Power Management Integrated Circuit (PMIC)
maintainers:
- Steve Twiss <stwiss.opensource@diasemi.com>
@@ -12,10 +12,22 @@ maintainers:
description: |
For device-tree bindings of other sub-modules refer to the binding documents
under the respective sub-system directories.
+ Using regulator-{uv,ov}-{warn,error,protection}-microvolt requires special
+ handling: First, when GP_FB2 is used, it must be ensured that there is no
+ moment where all voltage monitors are disabled. Next, as da9063 only supports
+ UV *and* OV monitoring, both must be set to the same severity and value
+ (0: disable, 1: enable).
+ Product information for the DA906{3L,3,2,1} devices can be found here:
+ - https://www.dialog-semiconductor.com/products/da9063l
+ - https://www.dialog-semiconductor.com/products/da9063
+ - https://www.dialog-semiconductor.com/products/da9062
+ - https://www.dialog-semiconductor.com/products/da9061
properties:
compatible:
enum:
+ - dlg,da9061
+ - dlg,da9062
- dlg,da9063
- dlg,da9063l
@@ -30,20 +42,28 @@ properties:
"#interrupt-cells":
const: 2
- dlg,use-sw-pm:
- type: boolean
- description:
- Disable the watchdog during suspend.
- Only use this option if you can't use the watchdog automatic suspend
- function during a suspend (see register CONTROL_B).
+ gpio-controller: true
- watchdog:
+ "#gpio-cells":
+ const: 2
+
+ gpio:
type: object
- $ref: /schemas/watchdog/watchdog.yaml#
- unevaluatedProperties: false
+ additionalProperties: false
properties:
compatible:
- const: dlg,da9063-watchdog
+ const: dlg,da9062-gpio
+
+ onkey:
+ $ref: /schemas/input/dlg,da9062-onkey.yaml
+
+ regulators:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck[1-4])$":
+ $ref: /schemas/regulator/regulator.yaml
+ unevaluatedProperties: false
rtc:
type: object
@@ -51,37 +71,88 @@ properties:
unevaluatedProperties: false
properties:
compatible:
- const: dlg,da9063-rtc
+ enum:
+ - dlg,da9062-rtc
+ - dlg,da9063-rtc
- onkey:
- type: object
- $ref: /schemas/input/input.yaml#
- unevaluatedProperties: false
- properties:
- compatible:
- const: dlg,da9063-onkey
+ thermal:
+ $ref: /schemas/thermal/dlg,da9062-thermal.yaml
- dlg,disable-key-power:
- type: boolean
- description: |
- Disable power-down using a long key-press.
- If this entry does not exist then by default the key-press triggered
- power down is enabled and the OnKey will support both KEY_POWER and
- KEY_SLEEP.
+ watchdog:
+ $ref: /schemas/watchdog/dlg,da9062-watchdog.yaml
- regulators:
+ wakeup-source: true
+
+patternProperties:
+ "^(.+-hog(-[0-9]+)?)$":
type: object
- additionalProperties: false
- patternProperties:
- "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$":
- $ref: /schemas/regulator/regulator.yaml
- unevaluatedProperties: false
+
+ required:
+ - gpio-hog
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9063
+ - dlg,da9063l
+ then:
+ properties:
+ gpio-controller: false
+ "#gpio-cells": false
+ gpio: false
+ regulators:
+ patternProperties:
+ "^buck[1-4]$": false
+ thermal: false
+ required:
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9062
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$": false
+ required:
+ - gpio
+ - onkey
+ - rtc
+ - thermal
+ - watchdog
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - dlg,da9061
+ then:
+ properties:
+ gpio-controller: false
+ "#gpio-cells": false
+ gpio: false
+ regulators:
+ patternProperties:
+ "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck4)$": false
+ rtc: false
+ required:
+ - onkey
+ - thermal
+ - watchdog
additionalProperties: false
@@ -94,10 +165,10 @@ examples:
pmic@58 {
compatible = "dlg,da9063";
reg = <0x58>;
- #interrupt-cells = <2>;
interrupt-parent = <&gpio6>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
+ #interrupt-cells = <2>;
rtc {
compatible = "dlg,da9063-rtc";
@@ -121,12 +192,137 @@ examples:
regulator-max-microamp = <2000000>;
regulator-boot-on;
};
+ ldo6 {
+ /* UNUSED */
+ regulator-name = "LDO_6";
+ regulator-uv-protection-microvolt = <0>;
+ regulator-ov-protection-microvolt = <0>;
+ };
ldo11 {
regulator-name = "LDO_11";
regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <3600000>;
- regulator-boot-on;
+ regulator-max-microvolt = <900000>;
+ regulator-uv-protection-microvolt = <1>;
+ regulator-ov-protection-microvolt = <1>;
+ regulator-always-on;
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/dlg,da9063-regulator.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@58 {
+ compatible = "dlg,da9062";
+ reg = <0x58>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ sd0-pwr-sel-hog {
+ gpio-hog;
+ gpios = <1 0>;
+ input;
+ line-name = "SD0_PWR_SEL";
+ };
+
+ sd1-pwr-sel-hog {
+ gpio-hog;
+ gpios = <2 0>;
+ input;
+ line-name = "SD1_PWR_SEL";
+ };
+
+ sw-et0-en-hog {
+ gpio-hog;
+ gpios = <3 0>;
+ input;
+ line-name = "SW_ET0_EN#";
+ };
+
+ pmic-good-hog {
+ gpio-hog;
+ gpios = <4 0>;
+ output-high;
+ line-name = "PMIC_PGOOD";
+ };
+
+ gpio {
+ compatible = "dlg,da9062-gpio";
+ };
+
+ onkey {
+ compatible = "dlg,da9062-onkey";
+ };
+
+ regulators {
+ buck1 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck2 {
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1380000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck3 {
+ regulator-name = "vdd_ddr3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ buck4 {
+ regulator-name = "vdd_eth";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
+ regulator-always-on;
+ };
+ ldo1 {
+ regulator-name = "vdd_snvs";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ ldo2 {
+ regulator-name = "vdd_high";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+ ldo3 {
+ regulator-name = "vdd_eth_io";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
};
+ ldo4 {
+ regulator-name = "vdd_emmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+
+ rtc {
+ compatible = "dlg,da9062-rtc";
+ };
+
+ thermal {
+ compatible = "dlg,da9062-thermal";
+ };
+
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ dlg,use-sw-pm;
};
};
};
diff --git a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
index 08af356f5d27..9b11b6e2bbf7 100644
--- a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
+++ b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/ene-kb3930.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ENE KB3930 Embedded Controller bindings
+title: ENE KB3930 Embedded Controller
description: |
This binding describes the ENE KB3930 Embedded Controller attached to an
diff --git a/Documentation/devicetree/bindings/mfd/ene-kb930.yaml b/Documentation/devicetree/bindings/mfd/ene-kb930.yaml
index 06ed9ec8f4bb..02c111def5de 100644
--- a/Documentation/devicetree/bindings/mfd/ene-kb930.yaml
+++ b/Documentation/devicetree/bindings/mfd/ene-kb930.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/ene-kb930.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ENE KB930 Embedded Controller bindings
+title: ENE KB930 Embedded Controller
description: |
This binding describes the ENE KB930 Embedded Controller attached to an
@@ -13,6 +13,8 @@ description: |
maintainers:
- Dmitry Osipenko <digetx@gmail.com>
+$ref: /schemas/power/supply/power-supply.yaml
+
properties:
compatible:
items:
@@ -22,15 +24,13 @@ properties:
reg:
maxItems: 1
- monitored-battery: true
- power-supplies: true
system-power-controller: true
required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
deleted file mode 100644
index f09577105b50..000000000000
--- a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
+++ /dev/null
@@ -1,192 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mfd/fsl,imx8qxp-csr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings
-
-maintainers:
- - Liu Ying <victor.liu@nxp.com>
-
-description: |
- As a system controller, the Freescale i.MX8qm/qxp Control and Status
- Registers(CSR) module represents a set of miscellaneous registers of a
- specific subsystem. It may provide control and/or status report interfaces
- to a mix of standalone hardware devices within that subsystem. One typical
- use-case is for some other nodes to acquire a reference to the syscon node
- by phandle, and the other typical use-case is that the operating system
- should consider all subnodes of the CSR module as separate child devices.
-
-properties:
- $nodename:
- pattern: "^syscon@[0-9a-f]+$"
-
- compatible:
- items:
- - enum:
- - fsl,imx8qxp-mipi-lvds-csr
- - fsl,imx8qm-lvds-csr
- - const: syscon
- - const: simple-mfd
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- clock-names:
- const: ipg
-
-patternProperties:
- "^(ldb|phy|pxl2dpi)$":
- type: object
- description: The possible child devices of the CSR module.
-
-required:
- - compatible
- - reg
- - clocks
- - clock-names
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- const: fsl,imx8qxp-mipi-lvds-csr
- then:
- required:
- - pxl2dpi
- - ldb
-
- - if:
- properties:
- compatible:
- contains:
- const: fsl,imx8qm-lvds-csr
- then:
- required:
- - phy
- - ldb
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/imx8-lpcg.h>
- #include <dt-bindings/firmware/imx/rsrc.h>
- mipi_lvds_0_csr: syscon@56221000 {
- compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd";
- reg = <0x56221000 0x1000>;
- clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
- clock-names = "ipg";
-
- mipi_lvds_0_pxl2dpi: pxl2dpi {
- compatible = "fsl,imx8qxp-pxl2dpi";
- fsl,sc-resource = <IMX_SC_R_MIPI_0>;
- power-domains = <&pd IMX_SC_R_MIPI_0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&dc0_pixel_link0_mipi_lvds_0_pxl2dpi>;
- };
-
- mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&dc0_pixel_link1_mipi_lvds_0_pxl2dpi>;
- };
- };
-
- port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <1>;
-
- mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
- };
-
- mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
- };
- };
- };
- };
-
- mipi_lvds_0_ldb: ldb {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx8qxp-ldb";
- clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
- <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
- clock-names = "pixel", "bypass";
- power-domains = <&pd IMX_SC_R_LVDS_0>;
-
- channel@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
- phys = <&mipi_lvds_0_phy>;
- phy-names = "lvds_phy";
-
- port@0 {
- reg = <0>;
-
- mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
- remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- /* ... */
- };
- };
-
- channel@1 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <1>;
- phys = <&mipi_lvds_0_phy>;
- phy-names = "lvds_phy";
-
- port@0 {
- reg = <0>;
-
- mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi: endpoint {
- remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- /* ... */
- };
- };
- };
- };
-
- mipi_lvds_0_phy: phy@56228300 {
- compatible = "fsl,imx8qxp-mipi-dphy";
- reg = <0x56228300 0x100>;
- clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_PHY>;
- clock-names = "phy_ref";
- #phy-cells = <0>;
- fsl,syscon = <&mipi_lvds_0_csr>;
- power-domains = <&pd IMX_SC_R_MIPI_0>;
- };
diff --git a/Documentation/devicetree/bindings/mfd/fsl,mc13xxx.yaml b/Documentation/devicetree/bindings/mfd/fsl,mc13xxx.yaml
new file mode 100644
index 000000000000..cfa69f1f380a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl,mc13xxx.yaml
@@ -0,0 +1,300 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/fsl,mc13xxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MC13xxx Power Management Integrated Circuits (PMIC)
+
+maintainers:
+ - Alexander Kurz <akurz@blala.de>
+
+description: >
+ The MC13xxx PMIC series consists of the three models MC13783, MC13892
+ and MC34708 and provide regulators and other features like RTC, ADC,
+ LED, touchscreen, codec and input buttons.
+
+ Link to datasheets
+ https://www.nxp.com/docs/en/data-sheet/MC13783.pdf
+ https://www.nxp.com/docs/en/data-sheet/MC13892.pdf
+ https://www.nxp.com/docs/en/data-sheet/MC34708.pdf
+
+properties:
+ compatible:
+ enum:
+ - fsl,mc13783
+ - fsl,mc13892
+ - fsl,mc34708
+
+ reg:
+ description: I2C slave address or SPI chip select number.
+ maxItems: 1
+
+ spi-max-frequency: true
+
+ spi-cs-high: true
+
+ system-power-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ buttons:
+ type: object
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^onkey@[0-2]$":
+ $ref: /schemas/input/input.yaml#
+ unevaluatedProperties: false
+ type: object
+
+ properties:
+ reg:
+ description: |
+ One of
+ MC13783 BUTTON IDs:
+ 0: ONOFD1
+ 1: ONOFD2
+ 2: ONOFD3
+
+ MC13892 BUTTON IDs:
+ 0: PWRON1
+ 1: PWRON2
+ 2: PWRON3
+
+ MC34708 BUTTON IDs:
+ 0: PWRON1
+ 1: PWRON2
+ maximum: 2
+
+ debounce-delay-ms:
+ enum: [0, 30, 150, 750]
+ default: 30
+ description:
+ Sets the debouncing delay in milliseconds.
+
+ active-low:
+ description: Set active when pin is pulled low.
+
+ linux,code: true
+
+ fsl,enable-reset:
+ description:
+ Setting of the global reset option.
+ type: boolean
+
+ unevaluatedProperties: false
+
+ leds:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ led-control:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Setting for LED-Control register array length depends on model,
+ mc13783: 6, mc13892: 4, mc34708: 1
+
+ patternProperties:
+ '^led@[0-9a-b]$':
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: |
+ One of
+ MC13783 LED IDs
+ 0: Main display
+ 1: AUX display
+ 2: Keypad
+ 3: Red 1
+ 4: Green 1
+ 5: Blue 1
+ 6: Red 2
+ 7: Green 2
+ 8: Blue 2
+ 9: Red 3
+ 10: Green 3
+ 11: Blue 3
+
+ MC13892 LED IDs
+ 0: Main display
+ 1: AUX display
+ 2: Keypad
+ 3: Red
+ 4: Green
+ 5: Blue
+
+ MC34708 LED IDs
+ 0: Charger Red
+ 1: Charger Green
+ maxItems: 1
+
+ regulators:
+ type: object
+
+ additionalProperties:
+ type: object
+
+ description: |
+ List of child nodes specifying the regulators, depending on chip variant.
+ Each child node is defined using the standard binding for regulators and
+ the optional regulator properties defined below.
+
+ fsl,mc13xxx-uses-adc:
+ type: boolean
+ description: Indicate the ADC is being used
+
+ fsl,mc13xxx-uses-codec:
+ type: boolean
+ description: Indicate the Audio Codec is being used
+
+ fsl,mc13xxx-uses-rtc:
+ type: boolean
+ description: Indicate the RTC is being used
+
+ fsl,mc13xxx-uses-touch:
+ type: boolean
+ description: Indicate the touchscreen controller is being used
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,mc13783
+ then:
+ properties:
+ leds:
+ properties:
+ led-control:
+ minItems: 6
+ maxItems: 6
+ regulators:
+ patternProperties:
+ "^gpo[1-4]|pwgt[12]spi|sw[12][ab]|sw3|vaudio|vcam|vdig|vesim|vgen|viohi|violo|vmmc[12]|vrf[12]|vrfbg|vrfcp|vrfdig|vrfref|vsim|vvib$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,mc13892
+ then:
+ properties:
+ leds:
+ properties:
+ led-control:
+ minItems: 4
+ maxItems: 4
+ regulators:
+ patternProperties:
+ "^gpo[1-4]|pwgt[12]spi|sw[1-4]|swbst|vaudio|vcam|vcoincell|vdig|vgen[1-3]|viohi|vpll|vsd|vusb|vusb2|vvideo$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,mc34708
+ then:
+ properties:
+ buttons:
+ patternProperties:
+ "^onkey@[0-2]$":
+ properties:
+ reg:
+ maximum: 1
+ leds:
+ properties:
+ led-control:
+ minItems: 1
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic: mc13892@0 {
+ compatible = "fsl,mc13892";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cs-high;
+ interrupt-parent = <&gpio0>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,mc13xxx-uses-rtc;
+ fsl,mc13xxx-uses-adc;
+
+ buttons {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ onkey@0 {
+ reg = <0>;
+ debounce-delay-ms = <30>;
+ active-low;
+ fsl,enable-reset;
+ };
+ };
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ led-control = <0x000 0x000 0x0e0 0x000>;
+
+ led@3 {
+ reg = <3>;
+ label = "system:red:live";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ regulators {
+ sw1_reg: sw1 {
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1375000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml b/Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml
new file mode 100644
index 000000000000..8beb2ed9edb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/fsl,mcu-mpc8349emitx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU)
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,mc9s08qg8-mpc8315erdb
+ - fsl,mc9s08qg8-mpc8349emitx
+ - fsl,mc9s08qg8-mpc8377erdb
+ - fsl,mc9s08qg8-mpc8378erdb
+ - fsl,mc9s08qg8-mpc8379erdb
+ - const: fsl,mcu-mpc8349emitx
+
+ reg:
+ maxItems: 1
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mcu@a {
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8349emitx",
+ "fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
deleted file mode 100644
index acb9c54942d9..000000000000
--- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml
+++ /dev/null
@@ -1,203 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mfd/gateworks-gsc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Gateworks System Controller
-
-description: |
- The Gateworks System Controller (GSC) is a device present across various
- Gateworks product families that provides a set of system related features
- such as the following (refer to the board hardware user manuals to see what
- features are present)
- - Watchdog Timer
- - GPIO
- - Pushbutton controller
- - Hardware monitor with ADC's for temperature and voltage rails and
- fan controller
-
-maintainers:
- - Tim Harvey <tharvey@gateworks.com>
-
-properties:
- $nodename:
- pattern: "gsc@[0-9a-f]{1,2}"
- compatible:
- const: gw,gsc
-
- reg:
- description: I2C device address
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- "#interrupt-cells":
- const: 1
-
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
- adc:
- type: object
- additionalProperties: false
- description: Optional hardware monitoring module
-
- properties:
- compatible:
- const: gw,gsc-adc
-
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
- patternProperties:
- "^channel@[0-9a-f]+$":
- type: object
- additionalProperties: false
- description: |
- Properties for a single ADC which can report cooked values
- (i.e. temperature sensor based on thermister), raw values
- (i.e. voltage rail with a pre-scaling resistor divider).
-
- properties:
- reg:
- description: Register of the ADC
- maxItems: 1
-
- label:
- description: Name of the ADC input
-
- gw,mode:
- description: |
- conversion mode:
- 0 - temperature, in C*10
- 1 - pre-scaled 24-bit voltage value
- 2 - scaled voltage based on an optional resistor divider
- and optional offset
- 3 - pre-scaled 16-bit voltage value
- 4 - fan tach input to report RPM's
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2, 3, 4]
-
- gw,voltage-divider-ohms:
- description: Values of resistors for divider on raw ADC input
- maxItems: 2
- items:
- minimum: 1000
- maximum: 1000000
-
- gw,voltage-offset-microvolt:
- description: |
- A positive voltage offset to apply to a raw ADC
- (i.e. to compensate for a diode drop).
- minimum: 0
- maximum: 1000000
-
- required:
- - gw,mode
- - reg
- - label
-
- required:
- - compatible
- - "#address-cells"
- - "#size-cells"
-
-patternProperties:
- "^fan-controller@[0-9a-f]+$":
- type: object
- additionalProperties: false
- description: Optional fan controller
-
- properties:
- compatible:
- const: gw,gsc-fan
-
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
- reg:
- description: The fan controller base address
- maxItems: 1
-
- required:
- - compatible
- - reg
- - "#address-cells"
- - "#size-cells"
-
-required:
- - compatible
- - reg
- - interrupts
- - interrupt-controller
- - "#interrupt-cells"
- - "#address-cells"
- - "#size-cells"
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- gsc@20 {
- compatible = "gw,gsc";
- reg = <0x20>;
- interrupt-parent = <&gpio1>;
- interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- adc {
- compatible = "gw,gsc-adc";
- #address-cells = <1>;
- #size-cells = <0>;
-
- channel@0 { /* A0: Board Temperature */
- reg = <0x00>;
- label = "temp";
- gw,mode = <0>;
- };
-
- channel@2 { /* A1: Input Voltage (raw ADC) */
- reg = <0x02>;
- label = "vdd_vin";
- gw,mode = <1>;
- gw,voltage-divider-ohms = <22100 1000>;
- gw,voltage-offset-microvolt = <800000>;
- };
-
- channel@b { /* A2: Battery voltage */
- reg = <0x0b>;
- label = "vdd_bat";
- gw,mode = <1>;
- };
- };
-
- fan-controller@2c {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "gw,gsc-fan";
- reg = <0x2c>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
deleted file mode 100644
index 04962bb29576..000000000000
--- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
+++ /dev/null
@@ -1,225 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mfd/google,cros-ec.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: ChromeOS Embedded Controller
-
-maintainers:
- - Benson Leung <bleung@chromium.org>
- - Guenter Roeck <groeck@chromium.org>
-
-description:
- Google's ChromeOS EC is a microcontroller which talks to the AP and
- implements various functions such as keyboard and battery charging.
- The EC can be connected through various interfaces (I2C, SPI, and others)
- and the compatible string specifies which interface is being used.
-
-properties:
- compatible:
- oneOf:
- - description:
- For implementations of the EC is connected through I2C.
- const: google,cros-ec-i2c
- - description:
- For implementations of the EC is connected through SPI.
- const: google,cros-ec-spi
- - description:
- For implementations of the EC is connected through RPMSG.
- const: google,cros-ec-rpmsg
-
- controller-data:
- description:
- SPI controller data, see bindings/spi/samsung,spi-peripheral-props.yaml
- type: object
-
- google,cros-ec-spi-pre-delay:
- description:
- This property specifies the delay in usecs between the
- assertion of the CS and the first clock pulse.
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 0
-
- google,cros-ec-spi-msg-delay:
- description:
- This property specifies the delay in usecs between messages.
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 0
-
- google,has-vbc-nvram:
- description:
- Some implementations of the EC include a small nvram space used to
- store verified boot context data. This boolean flag is used to specify
- whether this nvram is present or not.
- type: boolean
-
- mediatek,rpmsg-name:
- description:
- Must be defined if the cros-ec is a rpmsg device for a Mediatek
- ARM Cortex M4 Co-processor. Contains the name of the rpmsg
- device. Used to match the subnode to the rpmsg device announced by
- the SCP.
- $ref: "/schemas/types.yaml#/definitions/string"
-
- spi-max-frequency:
- description: Maximum SPI frequency of the device in Hz.
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- wakeup-source:
- description: Button can wake-up the system.
-
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- typec:
- $ref: "/schemas/chrome/google,cros-ec-typec.yaml#"
-
- ec-pwm:
- $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#"
- deprecated: true
-
- pwm:
- $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#"
-
- kbd-led-backlight:
- $ref: "/schemas/chrome/google,cros-kbd-led-backlight.yaml#"
-
- keyboard-controller:
- $ref: "/schemas/input/google,cros-ec-keyb.yaml#"
-
- proximity:
- $ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#"
-
- codecs:
- type: object
- additionalProperties: false
-
- properties:
- '#address-cells':
- const: 2
-
- '#size-cells':
- const: 1
-
- patternProperties:
- "^ec-codec@[a-f0-9]+$":
- type: object
- $ref: "/schemas/sound/google,cros-ec-codec.yaml#"
-
- required:
- - "#address-cells"
- - "#size-cells"
-
- cbas:
- type: object
-
- description:
- This device is used to signal when a detachable base is attached
- to a Chrome OS tablet. This device cannot be detected at runtime.
-
- properties:
- compatible:
- const: google,cros-cbas
-
- required:
- - compatible
-
- additionalProperties: false
-
-patternProperties:
- "^i2c-tunnel[0-9]*$":
- type: object
- $ref: "/schemas/i2c/google,cros-ec-i2c-tunnel.yaml#"
-
- "^regulator@[0-9]+$":
- type: object
- $ref: "/schemas/regulator/google,cros-ec-regulator.yaml#"
-
- "^extcon[0-9]*$":
- type: object
- $ref: "/schemas/extcon/extcon-usbc-cros-ec.yaml#"
-
-required:
- - compatible
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - google,cros-ec-i2c
- - google,cros-ec-rpmsg
- then:
- properties:
- google,cros-ec-spi-pre-delay: false
- google,cros-ec-spi-msg-delay: false
- spi-max-frequency: false
- else:
- $ref: /schemas/spi/spi-peripheral-props.yaml
-
-additionalProperties: false
-
-examples:
- # Example for I2C
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
-
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cros-ec@1e {
- compatible = "google,cros-ec-i2c";
- reg = <0x1e>;
- interrupts = <6 0>;
- interrupt-parent = <&gpio0>;
- };
- };
-
- # Example for SPI
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
-
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cros-ec@0 {
- compatible = "google,cros-ec-spi";
- reg = <0x0>;
- google,cros-ec-spi-msg-delay = <30>;
- google,cros-ec-spi-pre-delay = <10>;
- interrupts = <99 0>;
- interrupt-parent = <&gpio7>;
- spi-max-frequency = <5000000>;
-
- proximity {
- compatible = "google,cros-ec-mkbp-proximity";
- };
-
- cbas {
- compatible = "google,cros-cbas";
- };
- };
- };
-
- # Example for RPMSG
- - |
- scp0 {
- cros-ec {
- compatible = "google,cros-ec-rpmsg";
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
index 22edcb4b212f..6a824351834e 100644
--- a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
@@ -17,7 +17,7 @@ description: |
node.
The SPMI controller part is provided by
- Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
+ Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
properties:
$nodename:
@@ -42,18 +42,11 @@ properties:
additionalProperties: false
- properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
patternProperties:
'^ldo[0-9]+$':
type: object
- $ref: "/schemas/regulator/regulator.yaml#"
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
@@ -66,72 +59,75 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/spmi/spmi.h>
- pmic: pmic@0 {
- compatible = "hisilicon,hi6421v600-spmi";
- reg = <0 0>;
-
- #interrupt-cells = <2>;
- interrupt-controller;
- interrupt-parent = <&gpio28>;
- interrupts = <0 0>;
-
- regulators {
- #address-cells = <1>;
+ spmi {
+ #address-cells = <2>;
#size-cells = <0>;
- ldo3: ldo3 {
- regulator-name = "ldo3";
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <2000000>;
- regulator-boot-on;
- };
-
- ldo4: ldo4 {
- regulator-name = "ldo4";
- regulator-min-microvolt = <1725000>;
- regulator-max-microvolt = <1900000>;
- regulator-boot-on;
- };
-
- ldo9: ldo9 {
- regulator-name = "ldo9";
- regulator-min-microvolt = <1750000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- };
-
- ldo15: ldo15 {
- regulator-name = "ldo15";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-always-on;
- };
-
- ldo16: ldo16 {
- regulator-name = "ldo16";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-boot-on;
- };
-
- ldo17: ldo17 {
- regulator-name = "ldo17";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo33: ldo33 {
- regulator-name = "ldo33";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- };
-
- ldo34: ldo34 {
- regulator-name = "ldo34";
- regulator-min-microvolt = <2600000>;
- regulator-max-microvolt = <3300000>;
+ pmic@0 {
+ compatible = "hisilicon,hi6421v600-spmi";
+ reg = <0 SPMI_USID>;
+
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio28>;
+ interrupts = <0 0>;
+
+ regulators {
+ ldo3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-boot-on;
+ };
+
+ ldo4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <1725000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-boot-on;
+ };
+
+ ldo9 {
+ regulator-name = "ldo9";
+ regulator-min-microvolt = <1750000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+
+ ldo15 {
+ regulator-name = "ldo15";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ ldo16 {
+ regulator-name = "ldo16";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ };
+
+ ldo17 {
+ regulator-name = "ldo17";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo33 {
+ regulator-name = "ldo33";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+
+ ldo34 {
+ regulator-name = "ldo34";
+ regulator-min-microvolt = <2600000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
};
- };
};
diff --git a/Documentation/devicetree/bindings/mfd/iqs62x.yaml b/Documentation/devicetree/bindings/mfd/iqs62x.yaml
index 044cd7542c2b..f242dd0e18fd 100644
--- a/Documentation/devicetree/bindings/mfd/iqs62x.yaml
+++ b/Documentation/devicetree/bindings/mfd/iqs62x.yaml
@@ -31,17 +31,17 @@ properties:
maxItems: 1
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
description:
Specifies the name of the calibration and configuration file selected by
the driver. If this property is omitted, the name is chosen based on the
device name with ".bin" as the extension (e.g. iqs620a.bin for IQS620A).
keys:
- $ref: ../input/iqs62x-keys.yaml
+ $ref: /schemas/input/iqs62x-keys.yaml
pwm:
- $ref: ../pwm/iqs620a-pwm.yaml
+ $ref: /schemas/pwm/iqs620a-pwm.yaml
required:
- compatible
@@ -60,43 +60,34 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- iqs620a@44 {
- compatible = "azoteq,iqs620a";
- reg = <0x44>;
- interrupt-parent = <&gpio>;
- interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
-
- keys {
- compatible = "azoteq,iqs620a-keys";
-
- linux,keycodes = <KEY_SELECT>,
- <KEY_MENU>,
- <KEY_OK>,
- <KEY_MENU>;
-
- hall-switch-south {
- linux,code = <SW_LID>;
- azoteq,use-prox;
- };
- };
-
- iqs620a_pwm: pwm {
- compatible = "azoteq,iqs620a-pwm";
- #pwm-cells = <2>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ iqs620a@44 {
+ compatible = "azoteq,iqs620a";
+ reg = <0x44>;
+ interrupt-parent = <&gpio>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+
+ keys {
+ compatible = "azoteq,iqs620a-keys";
+
+ linux,keycodes = <KEY_SELECT>,
+ <KEY_MENU>,
+ <KEY_OK>,
+ <KEY_MENU>;
+
+ hall-switch-south {
+ linux,code = <SW_LID>;
+ azoteq,use-prox;
+ };
};
- };
-
- pwmleds {
- compatible = "pwm-leds";
- led-1 {
- pwms = <&iqs620a_pwm 0 1000000>;
- max-brightness = <255>;
+ iqs620a_pwm: pwm {
+ compatible = "azoteq,iqs620a-pwm";
+ #pwm-cells = <2>;
};
+ };
};
- |
@@ -105,37 +96,37 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- iqs620a@44 {
- compatible = "azoteq,iqs620a";
- reg = <0x44>;
- interrupt-parent = <&gpio>;
- interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
-
- firmware-name = "iqs620a_coil.bin";
-
- keys {
- compatible = "azoteq,iqs620a-keys";
-
- linux,keycodes = <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <KEY_MUTE>;
-
- hall-switch-north {
- linux,code = <SW_DOCK>;
- };
-
- hall-switch-south {
- linux,code = <SW_TABLET_MODE>;
- };
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ iqs620a@44 {
+ compatible = "azoteq,iqs620a";
+ reg = <0x44>;
+ interrupt-parent = <&gpio>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+
+ firmware-name = "iqs620a_coil.bin";
+
+ keys {
+ compatible = "azoteq,iqs620a-keys";
+
+ linux,keycodes = <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <KEY_MUTE>;
+
+ hall-switch-north {
+ linux,code = <SW_DOCK>;
+ };
+
+ hall-switch-south {
+ linux,code = <SW_TABLET_MODE>;
+ };
};
+ };
};
- |
@@ -144,36 +135,36 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- iqs624@44 {
- compatible = "azoteq,iqs624";
- reg = <0x44>;
- interrupt-parent = <&gpio>;
- interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
-
- keys {
- compatible = "azoteq,iqs624-keys";
-
- linux,keycodes = <BTN_0>,
- <0>,
- <BTN_1>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <0>,
- <KEY_VOLUMEUP>,
- <KEY_VOLUMEDOWN>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ iqs624@44 {
+ compatible = "azoteq,iqs624";
+ reg = <0x44>;
+ interrupt-parent = <&gpio>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+
+ keys {
+ compatible = "azoteq,iqs624-keys";
+
+ linux,keycodes = <BTN_0>,
+ <0>,
+ <BTN_1>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <KEY_VOLUMEUP>,
+ <KEY_VOLUMEDOWN>;
};
+ };
};
...
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 5750cc06e923..084960fd5a1f 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/khadas,mcu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Khadas on-board Microcontroller Device Tree Bindings
+title: Khadas on-board Microcontroller
maintainers:
- Neil Armstrong <neil.armstrong@linaro.org>
diff --git a/Documentation/devicetree/bindings/mfd/lp3943.txt b/Documentation/devicetree/bindings/mfd/lp3943.txt
index e8591d6b11b4..ca5324ed0df4 100644
--- a/Documentation/devicetree/bindings/mfd/lp3943.txt
+++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
@@ -7,7 +7,7 @@ Required properties:
LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm.
For the LP3943 GPIO properties please refer to:
-Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
For the LP3943 PWM properties please refer to:
Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
deleted file mode 100644
index ae9cf39bd101..000000000000
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-TI LP873X PMIC MFD driver
-
-Required properties:
- - compatible: "ti,lp8732", "ti,lp8733"
- - reg: I2C slave address.
- - gpio-controller: Marks the device node as a GPIO Controller.
- - #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify flags.
- See ../gpio/gpio.txt for more information.
- - xxx-in-supply: Phandle to parent supply node of each regulator
- populated under regulators node. xxx can be
- buck0, buck1, ldo0 or ldo1.
- - regulators: List of child nodes that specify the regulator
- initialization data.
-Example:
-
-pmic: lp8733@60 {
- compatible = "ti,lp8733";
- reg = <0x60>;
- gpio-controller;
- #gpio-cells = <2>;
-
- buck0-in-supply = <&vsys_3v3>;
- buck1-in-supply = <&vsys_3v3>;
- ldo0-in-supply = <&vsys_3v3>;
- ldo1-in-supply = <&vsys_3v3>;
-
- regulators {
- lp8733_buck0: buck0 {
- regulator-name = "lp8733-buck0";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1400000>;
- regulator-min-microamp = <1500000>;
- regulator-max-microamp = <4000000>;
- regulator-ramp-delay = <10000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- lp8733_buck1: buck1 {
- regulator-name = "lp8733-buck1";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1400000>;
- regulator-min-microamp = <1500000>;
- regulator-max-microamp = <4000000>;
- regulator-ramp-delay = <10000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- lp8733_ldo0: ldo0 {
- regulator-name = "lp8733-ldo0";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <3000000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- lp8733_ldo1: ldo1 {
- regulator-name = "lp8733-ldo1";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <3000000>;
- regulator-always-on;
- regulator-boot-on;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
new file mode 100644
index 000000000000..92a72a99fd79
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/marvell,88pm886-a1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell 88PM886 PMIC core
+
+maintainers:
+ - Karel Balej <balejk@matfyz.cz>
+
+description:
+ Marvell 88PM886 is a PMIC providing several functions such as onkey,
+ regulators or battery and charger.
+
+properties:
+ compatible:
+ const: marvell,88pm886-a1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ regulators:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^(ldo(1[0-6]|[1-9])|buck[1-5])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ description: LDO or buck regulator.
+ unevaluatedProperties: false
+
+ '#io-channel-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@30 {
+ compatible = "marvell,88pm886-a1";
+ reg = <0x30>;
+ interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ #io-channel-cells = <1>;
+ wakeup-source;
+
+ regulators {
+ ldo2: ldo2 {
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo15: ldo15 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ buck2: buck2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/max77650.yaml b/Documentation/devicetree/bindings/mfd/max77650.yaml
index b0a0f0d3d9d4..d93d84171a31 100644
--- a/Documentation/devicetree/bindings/mfd/max77650.yaml
+++ b/Documentation/devicetree/bindings/mfd/max77650.yaml
@@ -53,16 +53,16 @@ properties:
Single string containing the name of the GPIO line.
regulators:
- $ref: ../regulator/max77650-regulator.yaml
+ $ref: /schemas/regulator/max77650-regulator.yaml
charger:
- $ref: ../power/supply/max77650-charger.yaml
+ $ref: /schemas/power/supply/max77650-charger.yaml
leds:
- $ref: ../leds/leds-max77650.yaml
+ $ref: /schemas/leds/leds-max77650.yaml
onkey:
- $ref: ../input/max77650-onkey.yaml
+ $ref: /schemas/input/max77650-onkey.yaml
required:
- compatible
@@ -100,14 +100,12 @@ examples:
compatible = "maxim,max77650-regulator";
max77650_ldo: regulator-ldo {
- regulator-compatible = "ldo";
regulator-name = "max77650-ldo";
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <2937500>;
};
max77650_sbb0: regulator-sbb0 {
- regulator-compatible = "sbb0";
regulator-name = "max77650-sbb0";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1587500>;
diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt b/Documentation/devicetree/bindings/mfd/max8925.txt
deleted file mode 100644
index 4f0dc6638e5e..000000000000
--- a/Documentation/devicetree/bindings/mfd/max8925.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-* Maxim max8925 Power Management IC
-
-Required parent device properties:
-- compatible : "maxim,max8925"
-- reg : the I2C slave address for the max8925 chip
-- interrupts : IRQ line for the max8925 chip
-- interrupt-controller: describes the max8925 as an interrupt
- controller (has its own domain)
-- #interrupt-cells : should be 1.
- - The cell is the max8925 local IRQ number
-
-Optional parent device properties:
-- maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in
- interrupts property, the other is indicated here.
-
-max8925 consists of a large and varied group of sub-devices:
-
-Device Supply Names Description
------- ------------ -----------
-max8925-onkey : : On key
-max8925-rtc : : RTC
-max8925-regulator : : Regulators
-max8925-backlight : : Backlight
-max8925-touch : : Touchscreen
-max8925-power : : Charger
-
-Example:
-
- pmic: max8925@3c {
- compatible = "maxim,max8925";
- reg = <0x3c>;
- interrupts = <1>;
- interrupt-parent = <&intcmux4>;
- interrupt-controller;
- #interrupt-cells = <1>;
- maxim,tsc-irq = <0>;
-
- regulators {
- SDV1 {
- regulator-min-microvolt = <637500>;
- regulator-max-microvolt = <1425000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- LDO1 {
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <3900000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- };
- backlight {
- maxim,max8925-dual-string = <0>;
- };
- charger {
- batt-detect = <0>;
- topoff-threshold = <1>;
- fast-charge = <7>;
- no-temp-support = <0>;
- no-insert-detect = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/max8998.txt b/Documentation/devicetree/bindings/mfd/max8998.txt
deleted file mode 100644
index 4ed52184d081..000000000000
--- a/Documentation/devicetree/bindings/mfd/max8998.txt
+++ /dev/null
@@ -1,125 +0,0 @@
-* Maxim MAX8998, National/TI LP3974 multi-function device
-
-The Maxim MAX8998 is a multi-function device which includes voltage/current
-regulators, real time clock, battery charging controller and several
-other sub-blocks. It is interfaced using an I2C interface. Each sub-block
-is addressed by the host system using different i2c slave address.
-
-PMIC sub-block
---------------
-
-The PMIC sub-block contains a number of voltage and current regulators,
-with controllable parameters and dynamic voltage scaling capability.
-In addition, it includes a real time clock and battery charging controller
-as well. It is accessible at I2C address 0x66.
-
-Required properties:
-- compatible: Should be one of the following:
- - "maxim,max8998" for Maxim MAX8998
- - "national,lp3974" or "ti,lp3974" for National/TI LP3974.
-- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
-
-Optional properties:
-- interrupts: Interrupt specifiers for two interrupt sources.
- - First interrupt specifier is for main interrupt.
- - Second interrupt specifier is for power-on/-off interrupt.
-- max8998,pmic-buck1-dvs-gpios: GPIO specifiers for two host gpios used
- for buck 1 dvs. The format of the gpio specifier depends on the gpio
- controller.
-- max8998,pmic-buck2-dvs-gpio: GPIO specifier for host gpio used
- for buck 2 dvs. The format of the gpio specifier depends on the gpio
- controller.
-- max8998,pmic-buck1-default-dvs-idx: Default voltage setting selected from
- the possible 4 options selectable by the dvs gpios. The value of this
- property should be 0, 1, 2 or 3. If not specified or out of range,
- a default value of 0 is taken.
-- max8998,pmic-buck2-default-dvs-idx: Default voltage setting selected from
- the possible 2 options selectable by the dvs gpios. The value of this
- property should be 0 or 1. If not specified or out of range, a default
- value of 0 is taken.
-- max8998,pmic-buck-voltage-lock: If present, disallows changing of
- preprogrammed buck dvfs voltages.
-
-Additional properties required if max8998,pmic-buck1-dvs-gpios is defined:
-- max8998,pmic-buck1-dvs-voltage: An array of 4 voltage values in microvolts
- for buck1 regulator that can be selected using dvs gpio.
-
-Additional properties required if max8998,pmic-buck2-dvs-gpio is defined:
-- max8998,pmic-buck2-dvs-voltage: An array of 2 voltage values in microvolts
- for buck2 regulator that can be selected using dvs gpio.
-
-Regulators: All the regulators of MAX8998 to be instantiated shall be
-listed in a child node named 'regulators'. Each regulator is represented
-by a child node of the 'regulators' node.
-
- regulator-name {
- /* standard regulator bindings here */
- };
-
-Following regulators of the MAX8998 PMIC block are supported. Note that
-the 'n' in regulator name, as in LDOn or BUCKn, represents the LDO or BUCK
-number as described in MAX8998 datasheet.
-
- - LDOn
- - valid values for n are 2 to 17
- - Example: LDO2, LDO10, LDO17
- - BUCKn
- - valid values for n are 1 to 4.
- - Example: BUCK1, BUCK2, BUCK3, BUCK4
-
- - ENVICHG: Battery Charging Current Monitor Output. This is a fixed
- voltage type regulator
-
- - ESAFEOUT1: (ldo19)
- - ESAFEOUT2: (ld020)
-
- - CHARGER: main battery charger current control
-
-Standard regulator bindings are used inside regulator subnodes. Check
- Documentation/devicetree/bindings/regulator/regulator.txt
-for more details.
-
-Example:
-
- pmic@66 {
- compatible = "maxim,max8998-pmic";
- reg = <0x66>;
- interrupt-parent = <&wakeup_eint>;
- interrupts = <4 0>, <3 0>;
-
- /* Buck 1 DVS settings */
- max8998,pmic-buck1-default-dvs-idx = <0>;
- max8998,pmic-buck1-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
- <&gpx0 1 1 0 0>; /* SET2 */
- max8998,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
- <1000000>, <950000>;
-
- /* Buck 2 DVS settings */
- max8998,pmic-buck2-default-dvs-idx = <0>;
- max8998,pmic-buck2-dvs-gpio = <&gpx0 0 3 0 0>; /* SET3 */
- max8998,pmic-buck2-dvs-voltage = <1350000>, <1300000>;
-
- /* Regulators to instantiate */
- regulators {
- ldo2_reg: LDO2 {
- regulator-name = "VDD_ALIVE_1.1V";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1100000>;
- regulator-always-on;
- };
-
- buck1_reg: BUCK1 {
- regulator-name = "VDD_ARM_1.2V";
- regulator-min-microvolt = <950000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- charger_reg: CHARGER {
- regulator-name = "CHARGER";
- regulator-min-microamp = <90000>;
- regulator-max-microamp = <800000>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max5970.yaml b/Documentation/devicetree/bindings/mfd/maxim,max5970.yaml
new file mode 100644
index 000000000000..0da5cae3852e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max5970.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max5970.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator for MAX5970 Smart Switch from Maxim Integrated
+
+maintainers:
+ - Patrick Rudolph <patrick.rudolph@9elements.com>
+
+description: |
+ The smart switch provides no output regulation, but independent fault protection
+ and voltage and current sensing.
+ Programming is done through I2C bus.
+
+ Datasheets:
+ https://datasheets.maximintegrated.com/en/ds/MAX5970.pdf
+ https://datasheets.maximintegrated.com/en/ds/MAX5978.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,max5970
+ - maxim,max5978
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ leds:
+ type: object
+ description:
+ Properties for four LEDS.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-3]$":
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+ type: object
+
+ properties:
+ reg:
+ maximum: 3
+
+ additionalProperties: false
+
+ vss1-supply:
+ description: Supply of the first channel.
+
+ vss2-supply:
+ description: Supply of the second channel.
+
+ regulators:
+ type: object
+ description:
+ Properties for both hot swap control/switch.
+
+ patternProperties:
+ "^sw[0-1]$":
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ properties:
+ shunt-resistor-micro-ohms:
+ description: |
+ The value of current sense resistor in microohms.
+
+ required:
+ - shunt-resistor-micro-ohms
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+ - vss1-supply
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - maxim,max5970
+ then:
+ required:
+ - vss2-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ regulator@3a {
+ compatible = "maxim,max5978";
+ reg = <0x3a>;
+ vss1-supply = <&p3v3>;
+
+ regulators {
+ sw0_ref_0: sw0 {
+ shunt-resistor-micro-ohms = <12000>;
+ };
+ };
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ led@0 {
+ reg = <0>;
+ label = "led0";
+ default-state = "on";
+ };
+ led@1 {
+ reg = <1>;
+ label = "led1";
+ default-state = "on";
+ };
+ };
+ };
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@3a {
+ compatible = "maxim,max5970";
+ reg = <0x3a>;
+ vss1-supply = <&p3v3>;
+ vss2-supply = <&p5v>;
+
+ regulators {
+ sw0_ref_1: sw0 {
+ shunt-resistor-micro-ohms = <12000>;
+ };
+ sw1_ref_1: sw1 {
+ shunt-resistor-micro-ohms = <10000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max7360.yaml b/Documentation/devicetree/bindings/mfd/maxim,max7360.yaml
new file mode 100644
index 000000000000..3fc920c8639d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max7360.yaml
@@ -0,0 +1,191 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max7360.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX7360 Keypad, Rotary encoder, PWM and GPIO controller
+
+maintainers:
+ - Kamel Bouhara <kamel.bouhara@bootlin.com>
+ - Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
+
+description: |
+ Maxim MAX7360 device, with following functions:
+ - keypad controller
+ - rotary controller
+ - GPIO and GPO controller
+ - PWM controller
+
+ https://www.analog.com/en/products/max7360.html
+
+allOf:
+ - $ref: /schemas/input/matrix-keymap.yaml#
+ - $ref: /schemas/input/input.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max7360
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: inti
+ - const: intk
+
+ keypad-debounce-delay-ms:
+ description: Keypad debounce delay in ms
+ minimum: 9
+ maximum: 40
+ default: 9
+
+ rotary-debounce-delay-ms:
+ description: Rotary encoder debounce delay in ms
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ linux,axis:
+ $ref: /schemas/input/rotary-encoder.yaml#/properties/linux,axis
+
+ rotary-encoder,relative-axis:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Register a relative axis rather than an absolute one.
+
+ rotary-encoder,steps:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 24
+ description:
+ Number of steps in a full turnaround of the
+ encoder. Only relevant for absolute axis. Defaults to 24 which is a
+ typical value for such devices.
+
+ rotary-encoder,rollover:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Automatic rollover when the rotary value becomes
+ greater than the specified steps or smaller than 0. For absolute axis only.
+
+ "#pwm-cells":
+ const: 3
+
+ gpio:
+ $ref: /schemas/gpio/maxim,max7360-gpio.yaml#
+ description:
+ PORT0 to PORT7 general purpose input/output pins configuration.
+
+ gpo:
+ $ref: /schemas/gpio/maxim,max7360-gpio.yaml#
+ description: >
+ COL2 to COL7 general purpose output pins configuration. Allows to use
+ unused keypad columns as outputs.
+
+ The MAX7360 has 8 column lines and 6 of them can be used as GPOs. GPIOs
+ numbers used for this gpio-controller node do correspond to the column
+ numbers: values 0 and 1 are never valid, values from 2 to 7 might be valid
+ depending on the value of the keypad,num-column property.
+
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: '^(PORT[0-7]|ROTARY)$'
+ minItems: 1
+ maxItems: 8
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [gpio, pwm, rotary]
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - linux,keymap
+ - linux,axis
+ - "#pwm-cells"
+ - gpio
+ - gpo
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ io-expander@38 {
+ compatible = "maxim,max7360";
+ reg = <0x38>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>,
+ <24 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "inti", "intk";
+
+ keypad,num-rows = <8>;
+ keypad,num-columns = <4>;
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x00, KEY_F5)
+ MATRIX_KEY(0x01, 0x00, KEY_F4)
+ MATRIX_KEY(0x02, 0x01, KEY_F6)
+ >;
+ keypad-debounce-delay-ms = <10>;
+ autorepeat;
+
+ rotary-debounce-delay-ms = <2>;
+ linux,axis = <0>; /* REL_X */
+ rotary-encoder,relative-axis;
+
+ #pwm-cells = <3>;
+
+ max7360_gpio: gpio {
+ compatible = "maxim,max7360-gpio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ maxim,constant-current-disable = <0x06>;
+
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+ };
+
+ max7360_gpo: gpo {
+ compatible = "maxim,max7360-gpo";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ backlight_pins: backlight-pins {
+ pins = "PORT2";
+ function = "pwm";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
index d027aabe453b..c13d51e462ba 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
@@ -35,7 +35,7 @@ properties:
maxItems: 1
voltage-regulators:
- $ref: ../regulator/maxim,max77686.yaml
+ $ref: /schemas/regulator/maxim,max77686.yaml
description:
List of child nodes that specify the regulators.
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
index 1b06a77ec798..cce273ba4034 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml
@@ -37,6 +37,7 @@ properties:
max77693-muic:
type: object
additionalProperties: false
+ deprecated: true
properties:
compatible:
@@ -45,6 +46,21 @@ properties:
required:
- compatible
+ muic:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: maxim,max77693-muic
+
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - compatible
+
motor-driver:
type: object
additionalProperties: false
@@ -65,7 +81,7 @@ properties:
- pwms
regulators:
- $ref: ../regulator/maxim,max77693.yaml
+ $ref: /schemas/regulator/maxim,max77693.yaml
description:
List of child nodes that specify the regulators.
@@ -107,6 +123,38 @@ examples:
};
};
+ muic {
+ compatible = "maxim,max77693-muic";
+
+ connector {
+ compatible = "samsung,usb-connector-11pin",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ muic_to_usb: endpoint {
+ remote-endpoint = <&usb_to_muic>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ muic_to_mhl: endpoint {
+ remote-endpoint = <&mhl_to_muic>;
+ };
+ };
+ };
+ };
+ };
+
motor-driver {
compatible = "maxim,max77693-haptic";
haptic-supply = <&ldo26_reg>;
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77705.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77705.yaml
new file mode 100644
index 000000000000..8b62aadb4213
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77705.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max77705.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX77705 Companion Power Management and USB Type-C interface
+
+maintainers:
+ - Dzmitry Sankouski <dsankouski@gmail.com>
+
+description: |
+ This is a part of device tree bindings for Maxim MAX77705.
+
+ Maxim MAX77705 is a Companion Power Management and Type-C
+ interface IC which includes charger, fuelgauge, LED, haptic motor driver and
+ Type-C management.
+
+properties:
+ compatible:
+ const: maxim,max77705
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller:
+ description:
+ The driver implements an interrupt controller for the sub devices.
+ The interrupt number mapping is as follows
+ 0 - charger
+ 1 - topsys
+ 2 - fuelgauge
+ 3 - usb type-c management block.
+
+ '#interrupt-cells':
+ const: 1
+
+ haptic:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: maxim,max77705-haptic
+
+ haptic-supply: true
+
+ pwms:
+ maxItems: 1
+
+ required:
+ - compatible
+ - haptic-supply
+ - pwms
+
+ leds:
+ type: object
+ additionalProperties: false
+ description:
+ Up to 4 LED channels supported.
+
+ properties:
+ compatible:
+ const: maxim,max77705-rgb
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ multi-led:
+ type: object
+ $ref: /schemas/leds/leds-class-multicolor.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-3]$":
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ patternProperties:
+ "^led@[0-3]$":
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ required:
+ - compatible
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@66 {
+ compatible = "maxim,max77705";
+ reg = <0x66>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&pm8998_gpios>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ pinctrl-0 = <&chg_int_default>;
+ pinctrl-names = "default";
+
+ leds {
+ compatible = "maxim,max77705-rgb";
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_STATUS;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+
+ haptic {
+ compatible = "maxim,max77705-haptic";
+ haptic-supply = <&vib_regulator>;
+ pwms = <&vib_pwm 0 50000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
new file mode 100644
index 000000000000..525de9ab3c2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max77759.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX77759 PMIC for USB Type-C applications
+
+maintainers:
+ - André Draszik <andre.draszik@linaro.org>
+
+description: |
+ This is a part of device tree bindings for the MAX77759 companion Power
+ Management IC for USB Type-C applications.
+
+ The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensors, USB
+ Type-C Port Controller (TCPC), NVMEM, and a GPIO expander.
+
+properties:
+ compatible:
+ const: maxim,max77759
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ reg:
+ maxItems: 1
+
+ gpio:
+ $ref: /schemas/gpio/maxim,max77759-gpio.yaml
+
+ nvmem-0:
+ $ref: /schemas/nvmem/maxim,max77759-nvmem.yaml
+
+required:
+ - compatible
+ - interrupts
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@66 {
+ compatible = "maxim,max77759";
+ reg = <0x66>;
+ interrupts-extended = <&gpa8 3 IRQ_TYPE_LEVEL_LOW>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio {
+ compatible = "maxim,max77759-gpio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ nvmem-0 {
+ compatible = "maxim,max77759-nvmem";
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ reboot-mode@0 {
+ reg = <0x0 0x4>;
+ };
+
+ boot-reason@4 {
+ reg = <0x4 0x4>;
+ };
+
+ shutdown-user-flag@8 {
+ reg = <0x8 0x1>;
+ };
+
+ rsoc@10 {
+ reg = <0xa 0x2>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max8925.yaml b/Documentation/devicetree/bindings/mfd/maxim,max8925.yaml
new file mode 100644
index 000000000000..86dd810851ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max8925.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max8925.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX8925 PMIC from Maxim Integrated.
+
+maintainers:
+ - Lee Jones <lee@kernel.org>
+
+properties:
+ compatible:
+ const: maxim,max8925
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+ description:
+ The cell is the IRQ number
+
+ maxim,tsc-irq:
+ description: second interrupt from max8925
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ regulators:
+ type: object
+
+ patternProperties:
+ "^SDV[1-3]$|^LDO[1-9]$|^LDO1[0-9]$|^LDO20$":
+ description: regulator configuration for SDV1-3 and LDO1-20
+ $ref: /schemas/regulator/regulator.yaml
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+ backlight:
+ type: object
+ properties:
+ maxim,max8925-dual-string:
+ description: set to 1 to support dual string
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ default: 0
+
+ additionalProperties: false
+
+ charger:
+ type: object
+ properties:
+ batt-detect:
+ description: set to 1 if battery detection via ID pin is supported
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ default: 0
+
+ topoff-threshold:
+ description: charging current in topoff mode, configures bits 5-6 in CHG_CNTL1
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 0
+
+ fast-charge:
+ description: set charging current in fast mode, configures bits 0-3 in CHG_CNTL1
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ default: 0
+
+ no-temp-support:
+ description: set to 1 if temperature sensing is not supported
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ default: 0
+
+ no-insert-detect:
+ description: set to 1 if AC detection is not supported
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ default: 0
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3c {
+ compatible = "maxim,max8925";
+ reg = <0x3c>;
+ interrupts = <1>;
+ interrupt-parent = <&intcmux4>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ maxim,tsc-irq = <0>;
+
+ regulators {
+ SDV1 {
+ regulator-min-microvolt = <637500>;
+ regulator-max-microvolt = <1425000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO1 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <3900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+
+ backlight {
+ maxim,max8925-dual-string = <0>;
+ };
+
+ charger {
+ batt-detect = <0>;
+ topoff-threshold = <1>;
+ fast-charge = <7>;
+ no-temp-support = <0>;
+ no-insert-detect = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max8998.yaml b/Documentation/devicetree/bindings/mfd/maxim,max8998.yaml
new file mode 100644
index 000000000000..f3c3f64fd012
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max8998.yaml
@@ -0,0 +1,324 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max8998.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX8998, National/TI LP3974 Power Management IC
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ The Maxim MAX8998 is a Power Management IC which includes voltage/current
+ regulators, real time clock, battery charging controller and several other
+ sub-blocks. It is interfaced using an I2C interface. Each sub-block is
+ addressed by the host system using different i2c slave address.
+
+properties:
+ compatible:
+ enum:
+ - maxim,max8998
+ - national,lp3974
+ - ti,lp3974
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Main interrupt
+ - description: Power-on/-off interrupt
+
+ max8998,pmic-buck1-dvs-gpios:
+ maxItems: 2
+ description:
+ Two host gpios used for buck1 DVS.
+
+ max8998,pmic-buck2-dvs-gpio:
+ maxItems: 1
+ description:
+ Host gpio used for buck2 DVS.
+
+ max8998,pmic-buck1-default-dvs-idx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ default: 0
+ description:
+ Default voltage setting selected from the possible 4 options selectable
+ by the DVS gpios.
+
+ max8998,pmic-buck2-default-dvs-idx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ default: 0
+ description:
+ Default voltage setting selected from the possible 2 options selectable
+ by the DVS GPIOs.
+
+ max8998,pmic-buck-voltage-lock:
+ type: boolean
+ description:
+ If present, disallows changing of preprogrammed buck DVS voltages.
+
+ max8998,pmic-buck1-dvs-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 4
+ description:
+ Four voltage values in microvolts for buck1 regulator that can be
+ selected using DVS GPIO.
+
+ max8998,pmic-buck2-dvs-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ description:
+ Two voltage values in microvolts for buck2 regulator that can be
+ selected using DVS GPIO.
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ CHARGER:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ CHARGER is main battery charger current control, wrongly represented
+ as regulator.
+
+ properties:
+ regulator-min-microamp:
+ minimum: 90000
+ maximum: 800000
+
+ regulator-max-microamp:
+ minimum: 90000
+ maximum: 800000
+
+ regulator-min-microvolt: false
+ regulator-max-microvolt: false
+
+ required:
+ - regulator-name
+
+ patternProperties:
+ "^(LDO([2-9]|1[0-7])|BUCK[1-4])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - regulator-name
+
+ "^(EN32KHz-AP|EN32KHz-CP|ENVICHG|ESAFEOUT[12])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ description: |
+ EN32KHz-AP and EN32KHz-CP are 32768 Hz clocks, wrongly represented as
+ regulators.
+ ENVICHG is a Battery Charging Current Monitor Output.
+
+ properties:
+ regulator-min-microvolt: false
+ regulator-max-microvolt: false
+
+ required:
+ - regulator-name
+
+dependencies:
+ max8998,pmic-buck1-dvs-gpios: [ "max8998,pmic-buck1-dvs-voltage" ]
+ max8998,pmic-buck2-dvs-gpio: [ "max8998,pmic-buck2-dvs-voltage" ]
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@66 {
+ compatible = "national,lp3974";
+ reg = <0x66>;
+ interrupts-extended = <&gpx0 7 IRQ_TYPE_LEVEL_LOW>,
+ <&gpx2 7 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lp3974_irq>;
+
+ max8998,pmic-buck1-default-dvs-idx = <0>;
+ max8998,pmic-buck1-dvs-gpios = <&gpx0 5 GPIO_ACTIVE_HIGH>,
+ <&gpx0 6 GPIO_ACTIVE_HIGH>;
+ max8998,pmic-buck1-dvs-voltage = <1100000>, <1000000>,
+ <1100000>, <1000000>;
+ max8998,pmic-buck2-default-dvs-idx = <0>;
+ max8998,pmic-buck2-dvs-gpio = <&gpe2 0 GPIO_ACTIVE_HIGH>;
+ max8998,pmic-buck2-dvs-voltage = <1200000>, <1100000>;
+
+ regulators {
+ LDO2 {
+ regulator-name = "VALIVE_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ LDO3 {
+ regulator-name = "VUSB+MIPI_1.1V";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ };
+
+ LDO4 {
+ regulator-name = "VADC_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ LDO5 {
+ regulator-name = "VTF_2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ LDO6 {
+ regulator-name = "LDO6";
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ };
+
+ LDO7 {
+ regulator-name = "VLCD+VMIPI_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ LDO8 {
+ regulator-name = "VUSB+VDAC_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ LDO9 {
+ regulator-name = "VCC_2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ };
+
+ LDO10 {
+ regulator-name = "VPLL_1.1V";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO11 {
+ regulator-name = "CAM_AF_3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ LDO12 {
+ regulator-name = "PS_2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ LDO13 {
+ regulator-name = "VHIC_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ LDO14 {
+ regulator-name = "CAM_I_HOST_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ LDO15 {
+ regulator-name = "CAM_S_DIG+FM33_CORE_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ LDO16 {
+ regulator-name = "CAM_S_ANA_2.8V";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ LDO17 {
+ regulator-name = "VCC_3.0V_LCD";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ BUCK1 {
+ regulator-name = "VINT_1.1V";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK2 {
+ regulator-name = "VG3D_1.1V";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ };
+
+ BUCK3 {
+ regulator-name = "VCC_1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ BUCK4 {
+ regulator-name = "VMEM_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ EN32KHz-AP {
+ regulator-name = "32KHz AP";
+ regulator-always-on;
+ };
+
+ EN32KHz-CP {
+ regulator-name = "32KHz CP";
+ };
+
+ ENVICHG {
+ regulator-name = "VICHG";
+ };
+
+ ESAFEOUT1 {
+ regulator-name = "SAFEOUT1";
+ };
+
+ ESAFEOUT2 {
+ regulator-name = "SAFEOUT2";
+ regulator-boot-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
deleted file mode 100644
index 8261ea73278a..000000000000
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ /dev/null
@@ -1,156 +0,0 @@
-* Freescale MC13783/MC13892 Power Management Integrated Circuit (PMIC)
-
-Required properties:
-- compatible : Should be "fsl,mc13783" or "fsl,mc13892"
-
-Optional properties:
-- fsl,mc13xxx-uses-adc : Indicate the ADC is being used
-- fsl,mc13xxx-uses-codec : Indicate the Audio Codec is being used
-- fsl,mc13xxx-uses-rtc : Indicate the RTC is being used
-- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
-
-Sub-nodes:
-- codec: Contain the Audio Codec node.
- - adc-port: Contain PMIC SSI port number used for ADC.
- - dac-port: Contain PMIC SSI port number used for DAC.
-- leds : Contain the led nodes and initial register values in property
- "led-control". Number of register depends of used IC, for MC13783 is 6,
- for MC13892 is 4, for MC34708 is 1. See datasheet for bits definitions of
- these registers.
- - #address-cells: Must be 1.
- - #size-cells: Must be 0.
- Each led node should contain "reg", which used as LED ID (described below).
- Optional properties "label" and "linux,default-trigger" is described in
- Documentation/devicetree/bindings/leds/common.txt.
-- regulators : Contain the regulator nodes. The regulators are bound using
- their names as listed below with their registers and bits for enabling.
-
-MC13783 LED IDs:
- 0 : Main display
- 1 : AUX display
- 2 : Keypad
- 3 : Red 1
- 4 : Green 1
- 5 : Blue 1
- 6 : Red 2
- 7 : Green 2
- 8 : Blue 2
- 9 : Red 3
- 10 : Green 3
- 11 : Blue 3
-
-MC13892 LED IDs:
- 0 : Main display
- 1 : AUX display
- 2 : Keypad
- 3 : Red
- 4 : Green
- 5 : Blue
-
-MC34708 LED IDs:
- 0 : Charger Red
- 1 : Charger Green
-
-MC13783 regulators:
- sw1a : regulator SW1A (register 24, bit 0)
- sw1b : regulator SW1B (register 25, bit 0)
- sw2a : regulator SW2A (register 26, bit 0)
- sw2b : regulator SW2B (register 27, bit 0)
- sw3 : regulator SW3 (register 29, bit 20)
- vaudio : regulator VAUDIO (register 32, bit 0)
- viohi : regulator VIOHI (register 32, bit 3)
- violo : regulator VIOLO (register 32, bit 6)
- vdig : regulator VDIG (register 32, bit 9)
- vgen : regulator VGEN (register 32, bit 12)
- vrfdig : regulator VRFDIG (register 32, bit 15)
- vrfref : regulator VRFREF (register 32, bit 18)
- vrfcp : regulator VRFCP (register 32, bit 21)
- vsim : regulator VSIM (register 33, bit 0)
- vesim : regulator VESIM (register 33, bit 3)
- vcam : regulator VCAM (register 33, bit 6)
- vrfbg : regulator VRFBG (register 33, bit 9)
- vvib : regulator VVIB (register 33, bit 11)
- vrf1 : regulator VRF1 (register 33, bit 12)
- vrf2 : regulator VRF2 (register 33, bit 15)
- vmmc1 : regulator VMMC1 (register 33, bit 18)
- vmmc2 : regulator VMMC2 (register 33, bit 21)
- gpo1 : regulator GPO1 (register 34, bit 6)
- gpo2 : regulator GPO2 (register 34, bit 8)
- gpo3 : regulator GPO3 (register 34, bit 10)
- gpo4 : regulator GPO4 (register 34, bit 12)
- pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
- pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
-
-MC13892 regulators:
- vcoincell : regulator VCOINCELL (register 13, bit 23)
- sw1 : regulator SW1 (register 24, bit 0)
- sw2 : regulator SW2 (register 25, bit 0)
- sw3 : regulator SW3 (register 26, bit 0)
- sw4 : regulator SW4 (register 27, bit 0)
- swbst : regulator SWBST (register 29, bit 20)
- vgen1 : regulator VGEN1 (register 32, bit 0)
- viohi : regulator VIOHI (register 32, bit 3)
- vdig : regulator VDIG (register 32, bit 9)
- vgen2 : regulator VGEN2 (register 32, bit 12)
- vpll : regulator VPLL (register 32, bit 15)
- vusb2 : regulator VUSB2 (register 32, bit 18)
- vgen3 : regulator VGEN3 (register 33, bit 0)
- vcam : regulator VCAM (register 33, bit 6)
- vvideo : regulator VVIDEO (register 33, bit 12)
- vaudio : regulator VAUDIO (register 33, bit 15)
- vsd : regulator VSD (register 33, bit 18)
- gpo1 : regulator GPO1 (register 34, bit 6)
- gpo2 : regulator GPO2 (register 34, bit 8)
- gpo3 : regulator GPO3 (register 34, bit 10)
- gpo4 : regulator GPO4 (register 34, bit 12)
- pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
- pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
- vusb : regulator VUSB (register 50, bit 3)
-
- The bindings details of individual regulator device can be found in:
- Documentation/devicetree/bindings/regulator/regulator.txt
-
-Examples:
-
-ecspi@70010000 { /* ECSPI1 */
- cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */
- <&gpio4 25 0>; /* GPIO4_25 */
-
- pmic: mc13892@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mc13892";
- spi-max-frequency = <6000000>;
- reg = <0>;
- interrupt-parent = <&gpio0>;
- interrupts = <8>;
-
- leds {
- #address-cells = <1>;
- #size-cells = <0>;
- led-control = <0x000 0x000 0x0e0 0x000>;
-
- sysled@3 {
- reg = <3>;
- label = "system:red:live";
- linux,default-trigger = "heartbeat";
- };
- };
-
- regulators {
- sw1_reg: mc13892__sw1 {
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1375000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- sw2_reg: mc13892__sw2 {
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <1850000>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
new file mode 100644
index 000000000000..b67fbe0e7a63
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mediatek,mt6357.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6357 PMIC
+
+maintainers:
+ - Flora Fu <flora.fu@mediatek.com>
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+description: |
+ MT6357 is a power management system chip containing 5 buck
+ converters and 29 LDOs. Supported features are audio codec,
+ USB battery charging, fuel gauge, RTC
+
+ This is a multifunction device with the following sub modules:
+ - Regulator
+ - RTC
+ - Keys
+
+ It is interfaced to host controller using SPI interface by a proprietary hardware
+ called PMIC wrapper or pwrap. This MFD is a child device of pwrap.
+ See the following for pwrap node definitions:
+ Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
+
+properties:
+ compatible:
+ const: mediatek,mt6357
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ mediatek,hp-pull-down:
+ description:
+ Earphone driver positive output stage short to
+ the audio reference ground.
+ type: boolean
+
+ mediatek,micbias0-microvolt:
+ description: Selects MIC Bias 0 output voltage.
+ enum: [1700000, 1800000, 1900000, 2000000,
+ 2100000, 2500000, 2600000, 2700000]
+ default: 1700000
+
+ mediatek,micbias1-microvolt:
+ description: Selects MIC Bias 1 output voltage.
+ enum: [1700000, 1800000, 1900000, 2000000,
+ 2100000, 2500000, 2600000, 2700000]
+ default: 1700000
+
+ regulators:
+ type: object
+ $ref: /schemas/regulator/mediatek,mt6357-regulator.yaml
+ unevaluatedProperties: false
+ description:
+ List of MT6357 BUCKs and LDOs regulators.
+
+ rtc:
+ type: object
+ $ref: /schemas/rtc/rtc.yaml#
+ unevaluatedProperties: false
+ description:
+ MT6357 Real Time Clock.
+ properties:
+ compatible:
+ const: mediatek,mt6357-rtc
+ start-year: true
+ required:
+ - compatible
+
+ keys:
+ type: object
+ $ref: /schemas/input/mediatek,pmic-keys.yaml
+ unevaluatedProperties: false
+ description:
+ MT6357 power and home keys.
+
+required:
+ - compatible
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pwrap {
+ pmic {
+ compatible = "mediatek,mt6357";
+
+ interrupt-parent = <&pio>;
+ interrupts = <145 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ mediatek,micbias0-microvolt = <1700000>;
+ mediatek,micbias1-microvolt = <1700000>;
+
+ regulators {
+ mt6357_vproc_reg: buck-vproc {
+ regulator-name = "vproc";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+
+ // ...
+
+ mt6357_vusb33_reg: ldo-vusb33 {
+ regulator-name = "vusb33";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ };
+
+ rtc {
+ compatible = "mediatek,mt6357-rtc";
+ };
+
+ keys {
+ compatible = "mediatek,mt6357-keys";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml
index 28eee02441ee..fb65abf30d57 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6360.yaml
@@ -83,7 +83,6 @@ examples:
richtek,vinovp-microvolt = <14500000>;
otg_vbus_regulator: usb-otg-vbus-regulator {
- regulator-compatible = "usb-otg-vbus";
regulator-name = "usb-otg-vbus";
regulator-min-microvolt = <4425000>;
regulator-max-microvolt = <5825000>;
@@ -145,7 +144,6 @@ examples:
compatible = "mediatek,mt6360-regulator";
LDO_VIN3-supply = <&BUCK2>;
buck1 {
- regulator-compatible = "BUCK1";
regulator-name = "mt6360,buck1";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1300000>;
@@ -154,7 +152,6 @@ examples:
MT6360_OPMODE_ULP>;
};
BUCK2: buck2 {
- regulator-compatible = "BUCK2";
regulator-name = "mt6360,buck2";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1300000>;
@@ -163,7 +160,6 @@ examples:
MT6360_OPMODE_ULP>;
};
ldo6 {
- regulator-compatible = "LDO6";
regulator-name = "mt6360,ldo6";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2100000>;
@@ -171,7 +167,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo7 {
- regulator-compatible = "LDO7";
regulator-name = "mt6360,ldo7";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2100000>;
@@ -179,7 +174,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo1 {
- regulator-compatible = "LDO1";
regulator-name = "mt6360,ldo1";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
@@ -187,7 +181,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo2 {
- regulator-compatible = "LDO2";
regulator-name = "mt6360,ldo2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
@@ -195,7 +188,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo3 {
- regulator-compatible = "LDO3";
regulator-name = "mt6360,ldo3";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
@@ -203,7 +195,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo5 {
- regulator-compatible = "LDO5";
regulator-name = "mt6360,ldo5";
regulator-min-microvolt = <2700000>;
regulator-max-microvolt = <3600000>;
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
index 250484d59ecd..c9574b243046 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
@@ -35,6 +35,7 @@ properties:
adc:
type: object
+ additionalProperties: false
description: |
Provides 9 channels for system monitoring, including VBUSDIV5 (lower
accuracy, higher measure range), VBUSDIV2 (higher accuracy, lower
@@ -73,6 +74,7 @@ properties:
regulators:
type: object
+ additionalProperties: false
description: |
List all supported regulators, which support the control for DisplayBias
voltages and one general purpose LDO which commonly used to drive the
@@ -139,8 +141,8 @@ examples:
charger {
compatible = "mediatek,mt6370-charger";
- interrupts = <48>, <68>, <6>;
- interrupt-names = "attach_i", "uvp_d_evt", "mivr";
+ interrupts = <68>, <48>, <6>;
+ interrupt-names = "uvp_d_evt", "attach_i", "mivr";
io-channels = <&mt6370_adc MT6370_CHAN_IBUS>;
mt6370_otg_vbus: usb-otg-vbus-regulator {
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
new file mode 100644
index 000000000000..6a89b479d10f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -0,0 +1,600 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mediatek,mt6397.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6397/MT6323 PMIC
+
+maintainers:
+ - Sen Chu <sen.chu@mediatek.com>
+ - Macpaul Lin <macpaul.lin@mediatek.com>
+
+description: |
+ MT6397/MT6323 is a power management system chip.
+ Please see the sub-modules below for supported features.
+
+ MT6397/MT6323 is a multifunction device with the following sub modules:
+ - Regulators
+ - RTC
+ - ADC
+ - Audio codec
+ - GPIO
+ - Clock
+ - LED
+ - Keys
+ - Power controller
+
+ It is interfaced to host controller using SPI interface by a proprietary hardware
+ called PMIC wrapper or pwrap. MT6397/MT6323 PMIC is a child device of pwrap.
+ See the following for pwrap node definitions:
+ Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt6323
+ - mediatek,mt6331 # "mediatek,mt6331" for PMIC MT6331 and MT6332.
+ - mediatek,mt6328
+ - mediatek,mt6358
+ - mediatek,mt6359
+ - mediatek,mt6397
+ - items:
+ - enum:
+ - mediatek,mt6366
+ - const: mediatek,mt6358
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ rtc:
+ type: object
+ $ref: /schemas/rtc/rtc.yaml#
+ unevaluatedProperties: false
+ description:
+ MT6397 Real Time Clock.
+
+ properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt6323-rtc
+ - mediatek,mt6331-rtc
+ - mediatek,mt6358-rtc
+ - mediatek,mt6397-rtc
+ - items:
+ - enum:
+ - mediatek,mt6366-rtc
+ - const: mediatek,mt6358-rtc
+
+ start-year: true
+
+ required:
+ - compatible
+
+ regulators:
+ type: object
+ description:
+ List of child nodes that specify the regulators.
+ additionalProperties: true
+
+ properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt6323-regulator
+ - mediatek,mt6328-regulator
+ - mediatek,mt6358-regulator
+ - mediatek,mt6359-regulator
+ - mediatek,mt6397-regulator
+ - items:
+ - enum:
+ - mediatek,mt6366-regulator
+ - const: mediatek,mt6358-regulator
+
+ required:
+ - compatible
+
+ adc:
+ type: object
+ $ref: /schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
+ unevaluatedProperties: false
+
+ audio-codec:
+ type: object
+ description:
+ Audio codec support with MT6358 and MT6397.
+ additionalProperties: true
+
+ properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt6358-sound
+ - mediatek,mt6359-codec
+ - mediatek,mt6397-codec
+ - items:
+ - enum:
+ - mediatek,mt6366-sound
+ - const: mediatek,mt6358-sound
+
+ required:
+ - compatible
+
+ clocks:
+ type: object
+ additionalProperties: false
+ description:
+ This is a clock buffer node for mt6397. However, there are no sub nodes
+ or any public document exposed in public.
+
+ properties:
+ compatible:
+ const: mediatek,mt6397-clk
+
+ '#clock-cells':
+ const: 1
+
+ required:
+ - compatible
+
+ leds:
+ type: object
+ additionalProperties: false
+ description: |
+ MT6323 LED controller is subfunction provided by MT6323 PMIC, so the LED
+ controllers are defined as the subnode of the function node provided by MT6323
+ PMIC controller that is being defined as one kind of Muti-Function Device (MFD)
+ using shared bus called PMIC wrapper for each subfunction to access remote
+ MT6323 PMIC hardware.
+
+ Each led is represented as a child node of the mediatek,mt6323-led that
+ describes the initial behavior for each LED physically and currently only four
+ LED child nodes can be supported.
+
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt6323-led
+ - mediatek,mt6331-led
+ - mediatek,mt6332-led
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-3]$":
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description:
+ LED channel number (0..3)
+ minimum: 0
+ maximum: 3
+
+ required:
+ - reg
+
+ required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+ keys:
+ type: object
+ $ref: /schemas/input/mediatek,pmic-keys.yaml
+ unevaluatedProperties: false
+ description:
+ Power and Home keys.
+
+ power-controller:
+ type: object
+ additionalProperties: false
+ description:
+ The power controller which could be found on PMIC is responsible for
+ externally powering off or on the remote MediaTek SoC through the
+ circuit BBPU (baseband power up).
+
+ properties:
+ compatible:
+ const: mediatek,mt6323-pwrc
+
+ '#power-domain-cells':
+ const: 0
+
+ pinctrl:
+ type: object
+ $ref: /schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml
+ unevaluatedProperties: false
+ description:
+ Pin controller
+
+required:
+ - compatible
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/leds/common.h>
+
+ pmic {
+ compatible = "mediatek,mt6323";
+ interrupt-parent = <&pio>;
+ interrupts = <150 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ leds {
+ compatible = "mediatek,mt6323-led";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ regulators {
+ compatible = "mediatek,mt6323-regulator";
+
+ buck_vproc {
+ regulator-name = "vproc";
+ regulator-min-microvolt = < 700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck_vsys {
+ regulator-name = "vsys";
+ regulator-min-microvolt = <1400000>;
+ regulator-max-microvolt = <2987500>;
+ regulator-ramp-delay = <25000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck_vpa {
+ regulator-name = "vpa";
+ regulator-min-microvolt = < 500000>;
+ regulator-max-microvolt = <3650000>;
+ };
+
+ ldo_vtcxo {
+ regulator-name = "vtcxo";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <90>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo_vcn28 {
+ regulator-name = "vcn28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <185>;
+ };
+
+ ldo_vcn33_bt {
+ regulator-name = "vcn33_bt";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3600000>;
+ regulator-enable-ramp-delay = <185>;
+ };
+
+ ldo_vcn33_wifi {
+ regulator-name = "vcn33_wifi";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3600000>;
+ regulator-enable-ramp-delay = <185>;
+ };
+
+ ldo_va {
+ regulator-name = "va";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <216>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo_vcama {
+ regulator-name = "vcama";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vio28 {
+ regulator-name = "vio28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <216>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo_vusb {
+ regulator-name = "vusb";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <216>;
+ regulator-boot-on;
+ };
+
+ ldo_vmc {
+ regulator-name = "vmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <36>;
+ regulator-boot-on;
+ };
+
+ ldo_vmch {
+ regulator-name = "vmch";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <36>;
+ regulator-boot-on;
+ };
+
+ ldo_vemc3v3 {
+ regulator-name = "vemc3v3";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <36>;
+ regulator-boot-on;
+ };
+
+ ldo_vgp1 {
+ regulator-name = "vgp1";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vgp2 {
+ regulator-name = "vgp2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vgp3 {
+ regulator-name = "vgp3";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vcn18 {
+ regulator-name = "vcn18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vsim1 {
+ regulator-name = "vsim1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vsim2 {
+ regulator-name = "vsim2";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vrtc {
+ regulator-name = "vrtc";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo_vcamaf {
+ regulator-name = "vcamaf";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vibr {
+ regulator-name = "vibr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <36>;
+ };
+
+ ldo_vrf18 {
+ regulator-name = "vrf18";
+ regulator-min-microvolt = <1825000>;
+ regulator-max-microvolt = <1825000>;
+ regulator-enable-ramp-delay = <187>;
+ };
+
+ ldo_vm {
+ regulator-name = "vm";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <216>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo_vio18 {
+ regulator-name = "vio18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <216>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo_vcamd {
+ regulator-name = "vcamd";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+
+ ldo_vcamio {
+ regulator-name = "vcamio";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <216>;
+ };
+ };
+
+ keys {
+ compatible = "mediatek,mt6323-keys";
+ mediatek,long-press-mode = <1>;
+ power-off-time-sec = <0>;
+
+ power {
+ linux,keycodes = <116>;
+ wakeup-source;
+ };
+
+ home {
+ linux,keycodes = <114>;
+ };
+ };
+
+ power-controller {
+ compatible = "mediatek,mt6323-pwrc";
+ #power-domain-cells = <0>;
+ };
+
+ rtc {
+ compatible = "mediatek,mt6323-rtc";
+ };
+ };
+
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pmic {
+ compatible = "mediatek,mt6358";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ audio-codec {
+ compatible = "mediatek,mt6358-sound";
+ Avdd-supply = <&mt6358_vaud28_reg>;
+ mediatek,dmic-mode = <0>;
+ };
+
+ regulators {
+ compatible = "mediatek,mt6358-regulator";
+
+ buck_vdram1 {
+ regulator-name = "vdram1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <2087500>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-allowed-modes = <0 1>;
+ };
+
+ // ...
+
+ ldo_vsim2 {
+ regulator-name = "vsim2";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-enable-ramp-delay = <540>;
+ };
+ };
+
+ rtc {
+ compatible = "mediatek,mt6358-rtc";
+ };
+
+ keys {
+ compatible = "mediatek,mt6358-keys";
+
+ power {
+ linux,keycodes = <KEY_POWER>;
+ wakeup-source;
+ };
+
+ home {
+ linux,keycodes = <KEY_HOME>;
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pmic {
+ compatible = "mediatek,mt6397";
+
+ interrupt-parent = <&pio>;
+ interrupts-extended = <&pio 222 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ audio-codec {
+ compatible = "mediatek,mt6397-codec";
+ };
+
+ clocks {
+ compatible = "mediatek,mt6397-clk";
+ #clock-cells = <1>;
+ };
+
+ pinctrl {
+ compatible = "mediatek,mt6397-pinctrl";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ regulators {
+ compatible = "mediatek,mt6397-regulator";
+
+ buck_vpca15 {
+ regulator-name = "vpca15";
+ regulator-min-microvolt = < 850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <200>;
+ };
+
+ // ...
+
+ ldo_vibr {
+ regulator-name = "vibr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+ };
+
+ rtc {
+ compatible = "mediatek,mt6397-rtc";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml
index c8c4812fffe2..0e1d43c96fb9 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml
@@ -18,12 +18,15 @@ properties:
compatible:
items:
- enum:
+ - mediatek,mt6893-scpsys
- mediatek,mt8167-scpsys
- mediatek,mt8173-scpsys
- mediatek,mt8183-scpsys
- mediatek,mt8186-scpsys
+ - mediatek,mt8188-scpsys
- mediatek,mt8192-scpsys
- mediatek,mt8195-scpsys
+ - mediatek,mt8365-scpsys
- const: syscon
- const: simple-mfd
diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
index 336c0495c8a3..b938fa26d2ce 100644
--- a/Documentation/devicetree/bindings/mfd/mfd.txt
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -17,13 +17,14 @@ A typical MFD can be:
Optional properties:
-- compatible : "simple-mfd" - this signifies that the operating system should
- consider all subnodes of the MFD device as separate devices akin to how
- "simple-bus" indicates when to see subnodes as children for a simple
- memory-mapped bus. For more complex devices, when the nexus driver has to
- probe registers to figure out what child devices exist etc, this should not
- be used. In the latter case the child devices will be determined by the
- operating system.
+- compatible : "simple-mfd" - this signifies that the operating system
+ should consider all subnodes of the MFD device as separate and independent
+ devices, so not needing any resources to be provided by the parent device.
+ Similarly to how "simple-bus" indicates when to see subnodes as children for
+ a simple memory-mapped bus.
+ For more complex devices, when the nexus driver has to probe registers to
+ figure out what child devices exist etc, this should not be used. In the
+ latter case the child devices will be determined by the operating system.
- ranges: Describes the address mapping relationship to the parent. Should set
the child's base address to 0, the physical address within parent's address
diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
index 190230216de8..18c3fc26ca93 100644
--- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
+++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
@@ -19,7 +19,7 @@ which are described in the following files:
- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml
- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml
- Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
-- Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
+- Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
- Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
- Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
- Documentation/devicetree/bindings/leds/leds-cpcap.txt
@@ -31,6 +31,10 @@ node must be named "audio-codec".
Required properties for the audio-codec subnode:
- #sound-dai-cells = <1>;
+- interrupts : should contain jack detection interrupts, with headset
+ detect interrupt matching "hs" and microphone bias 2
+ detect interrupt matching "mb2" in interrupt-names.
+- interrupt-names : Contains "hs", "mb2"
The audio-codec provides two DAIs. The first one is connected to the
Stereo HiFi DAC and the second one is connected to the Voice DAC.
@@ -52,6 +56,8 @@ Example:
audio-codec {
#sound-dai-cells = <1>;
+ interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>;
+ interrupt-names = "hs", "mb2";
/* HiFi */
port@0 {
diff --git a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
index 8bf45a5673a4..b613da83dca4 100644
--- a/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
+++ b/Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml
@@ -12,7 +12,8 @@ maintainers:
description: |
The Ocelot ethernet switch family contains chips that have an internal CPU
(VSC7513, VSC7514) and chips that don't (VSC7511, VSC7512). All switches have
- the option to be controlled externally, which is the purpose of this driver.
+ the option to be controlled externally via external interfaces like SPI or
+ PCIe.
The switch family is a multi-port networking switch that supports many
interfaces. Additionally, the device can perform pin control, MDIO buses, and
@@ -56,23 +57,25 @@ patternProperties:
enum:
- mscc,ocelot-miim
+ "^ethernet-switch@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/net/mscc,vsc7514-switch.yaml
+ unevaluatedProperties: false
+ properties:
+ compatible:
+ enum:
+ - mscc,vsc7512-switch
+
required:
- compatible
- reg
- '#address-cells'
- '#size-cells'
- - spi-max-frequency
additionalProperties: false
examples:
- |
- ocelot_clock: ocelot-clock {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <125000000>;
- };
-
spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
deleted file mode 100644
index 0088442efca1..000000000000
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-MediaTek MT6397/MT6323 Multifunction Device Driver
-
-MT6397/MT6323 is a multifunction device with the following sub modules:
-- Regulator
-- RTC
-- Audio codec
-- GPIO
-- Clock
-- LED
-- Keys
-- Power controller
-
-It is interfaced to host controller using SPI interface by a proprietary hardware
-called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
-See the following for pwarp node definitions:
-../soc/mediatek/pwrap.txt
-
-This document describes the binding for MFD device and its sub module.
-
-Required properties:
-compatible:
- "mediatek,mt6323" for PMIC MT6323
- "mediatek,mt6331" for PMIC MT6331 and MT6332
- "mediatek,mt6358" for PMIC MT6358 and MT6366
- "mediatek,mt6359" for PMIC MT6359
- "mediatek,mt6397" for PMIC MT6397
-
-Optional subnodes:
-
-- rtc
- Required properties: Should be one of follows
- - compatible: "mediatek,mt6323-rtc"
- - compatible: "mediatek,mt6331-rtc"
- - compatible: "mediatek,mt6358-rtc"
- - compatible: "mediatek,mt6397-rtc"
- For details, see ../rtc/rtc-mt6397.txt
-- regulators
- Required properties:
- - compatible: "mediatek,mt6323-regulator"
- see ../regulator/mt6323-regulator.txt
- - compatible: "mediatek,mt6358-regulator"
- see ../regulator/mt6358-regulator.txt
- - compatible: "mediatek,mt6397-regulator"
- see ../regulator/mt6397-regulator.txt
-- codec
- Required properties:
- - compatible: "mediatek,mt6397-codec" or "mediatek,mt6358-sound"
-- clk
- Required properties:
- - compatible: "mediatek,mt6397-clk"
-- led
- Required properties:
- - compatible: "mediatek,mt6323-led"
- see ../leds/leds-mt6323.txt
-
-- keys
- Required properties: Should be one of the following
- - compatible: "mediatek,mt6323-keys"
- - compatible: "mediatek,mt6331-keys"
- - compatible: "mediatek,mt6397-keys"
- see ../input/mtk-pmic-keys.txt
-
-- power-controller
- Required properties:
- - compatible: "mediatek,mt6323-pwrc"
- For details, see ../power/reset/mt6323-poweroff.txt
-
-- pin-controller
- Required properties:
- - compatible: "mediatek,mt6397-pinctrl"
- For details, see ../pinctrl/pinctrl-mt65xx.txt
-
-Example:
- pwrap: pwrap@1000f000 {
- compatible = "mediatek,mt8135-pwrap";
-
- ...
-
- pmic {
- compatible = "mediatek,mt6397";
-
- codec: mt6397codec {
- compatible = "mediatek,mt6397-codec";
- };
-
- regulators {
- compatible = "mediatek,mt6397-regulator";
-
- mt6397_vpca15_reg: buck_vpca15 {
- regulator-compatible = "buck_vpca15";
- regulator-name = "vpca15";
- regulator-min-microvolt = <850000>;
- regulator-max-microvolt = <1400000>;
- regulator-ramp-delay = <12500>;
- regulator-always-on;
- };
-
- mt6397_vgp4_reg: ldo_vgp4 {
- regulator-compatible = "ldo_vgp4";
- regulator-name = "vgp4";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/mxs-lradc.txt b/Documentation/devicetree/bindings/mfd/mxs-lradc.txt
deleted file mode 100644
index 755cbef0647d..000000000000
--- a/Documentation/devicetree/bindings/mfd/mxs-lradc.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-* Freescale MXS LRADC device driver
-
-Required properties:
-- compatible: Should be "fsl,imx23-lradc" for i.MX23 SoC and "fsl,imx28-lradc"
- for i.MX28 SoC
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the LRADC interrupts
-
-Optional properties:
-- fsl,lradc-touchscreen-wires: Number of wires used to connect the touchscreen
- to LRADC. Valid value is either 4 or 5. If this
- property is not present, then the touchscreen is
- disabled. 5 wires is valid for i.MX28 SoC only.
-- fsl,ave-ctrl: number of samples per direction to calculate an average value.
- Allowed value is 1 ... 32, default is 4
-- fsl,ave-delay: delay between consecutive samples. Allowed value is
- 2 ... 2048. It is used if 'fsl,ave-ctrl' > 1, counts at
- 2 kHz and its default is 2 (= 1 ms)
-- fsl,settling: delay between plate switch to next sample. Allowed value is
- 1 ... 2047. It counts at 2 kHz and its default is
- 10 (= 5 ms)
-
-Example for i.MX23 SoC:
-
- lradc@80050000 {
- compatible = "fsl,imx23-lradc";
- reg = <0x80050000 0x2000>;
- interrupts = <36 37 38 39 40 41 42 43 44>;
- fsl,lradc-touchscreen-wires = <4>;
- fsl,ave-ctrl = <4>;
- fsl,ave-delay = <2>;
- fsl,settling = <10>;
- };
-
-Example for i.MX28 SoC:
-
- lradc@80050000 {
- compatible = "fsl,imx28-lradc";
- reg = <0x80050000 0x2000>;
- interrupts = <10 14 15 16 17 18 19 20 21 22 23 24 25>;
- fsl,lradc-touchscreen-wires = <5>;
- fsl,ave-ctrl = <4>;
- fsl,ave-delay = <2>;
- fsl,settling = <10>;
- };
diff --git a/Documentation/devicetree/bindings/mfd/mxs-lradc.yaml b/Documentation/devicetree/bindings/mfd/mxs-lradc.yaml
new file mode 100644
index 000000000000..782b2f4005a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mxs-lradc.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/mxs-lradc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS Low-Resolution ADC (LRADC)
+
+maintainers:
+ - Dario Binacchi <dario.binacchi@amarulasolutions.com>
+
+description:
+ The LRADC provides 16 physical channels of 12-bit resolution for
+ analog-to-digital conversion and includes an integrated 4-wire/5-wire
+ touchscreen controller.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,imx23-lradc
+ - fsl,imx28-lradc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+
+ interrupts:
+ minItems: 9
+ maxItems: 13
+
+ fsl,lradc-touchscreen-wires:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [4, 5]
+ description: >
+ Number of wires used to connect the touchscreen to LRADC.
+
+ If this property is not present, then the touchscreen is disabled.
+
+ fsl,ave-ctrl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 32
+ default: 4
+ description:
+ Number of samples per direction to calculate an average value.
+
+ fsl,ave-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 2048
+ default: 2
+ description: >
+ Delay between consecutive samples.
+
+ It is used if 'fsl,ave-ctrl' > 1, counts at 2 kHz and its default value (2)
+ is 1 ms.
+
+ fsl,settling:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 2047
+ default: 10
+ description: >
+ Delay between plate switch to next sample.
+
+ It counts at 2 kHz and its default (10) is 5 ms.
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx23-lradc
+then:
+ properties:
+ interrupts:
+ items:
+ - description: channel 0
+ - description: channel 1
+ - description: channel 2
+ - description: channel 3
+ - description: channel 4
+ - description: channel 5
+ - description: touchscreen
+ - description: channel 6
+ - description: channel 7
+ fsl,lradc-touchscreen-wires:
+ const: 4
+else:
+ properties:
+ interrupts:
+ items:
+ - description: threshold 0
+ - description: threshold 1
+ - description: channel 0
+ - description: channel 1
+ - description: channel 2
+ - description: channel 3
+ - description: channel 4
+ - description: channel 5
+ - description: button 0
+ - description: button 1
+ - description: touchscreen
+ - description: channel 6
+ - description: channel 7
+
+additionalProperties: false
+
+examples:
+ - |
+ lradc@80050000 {
+ compatible = "fsl,imx23-lradc";
+ reg = <0x80050000 0x2000>;
+ interrupts = <36>, <37>, <38>, <39>, <40>,
+ <41>, <42>, <43>, <44>;
+ clocks = <&clks 26>;
+ #io-channel-cells = <1>;
+ fsl,lradc-touchscreen-wires = <4>;
+ fsl,ave-ctrl = <4>;
+ fsl,ave-delay = <2>;
+ fsl,settling = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
index 59a630025f52..37fbb953ea12 100644
--- a/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
+++ b/Documentation/devicetree/bindings/mfd/netronix,ntxec.yaml
@@ -48,29 +48,18 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ec: embedded-controller@43 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ntxec>;
-
- compatible = "netronix,ntxec";
- reg = <0x43>;
- system-power-controller;
- interrupt-parent = <&gpio4>;
- interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
- #pwm-cells = <2>;
- };
- };
-
- backlight {
- compatible = "pwm-backlight";
- pwms = <&ec 0 50000>;
- power-supply = <&backlight_regulator>;
- };
-
- backlight_regulator: regulator-dummy {
- compatible = "regulator-fixed";
- regulator-name = "backlight";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ec: embedded-controller@43 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ntxec>;
+
+ compatible = "netronix,ntxec";
+ reg = <0x43>;
+ system-power-controller;
+ interrupt-parent = <&gpio4>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ #pwm-cells = <2>;
+ };
};
diff --git a/Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml b/Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml
new file mode 100644
index 000000000000..b1ade64a1554
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/nxp,bbnsm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Battery-Backed Non-Secure Module
+
+maintainers:
+ - Jacky Bai <ping.bai@nxp.com>
+
+description: |
+ NXP BBNSM serves as non-volatile logic and storage for the system.
+ it Intergrates RTC & ON/OFF control.
+ The RTC can retain its state and continues counting even when the
+ main chip is power down. A time alarm is generated once the most
+ significant 32 bits of the real-time counter match the value in the
+ Time Alarm register.
+ The ON/OFF logic inside the BBNSM allows for connecting directly to
+ a PMIC or other voltage regulator device. both smart PMIC mode and
+ Dumb PMIC mode supported.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nxp,imx93-bbnsm
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ rtc:
+ type: object
+ $ref: /schemas/rtc/rtc.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - nxp,imx93-bbnsm-rtc
+
+ interrupts:
+ maxItems: 1
+
+ start-year: true
+
+ required:
+ - compatible
+ - interrupts
+
+ additionalProperties: false
+
+ pwrkey:
+ type: object
+ $ref: /schemas/input/input.yaml#
+
+ properties:
+ compatible:
+ enum:
+ - nxp,imx93-bbnsm-pwrkey
+
+ interrupts:
+ maxItems: 1
+
+ linux,code: true
+
+ required:
+ - compatible
+ - interrupts
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - rtc
+ - pwrkey
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/linux-event-codes.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bbnsm: bbnsm@44440000 {
+ compatible = "nxp,imx93-bbnsm", "syscon", "simple-mfd";
+ reg = <0x44440000 0x10000>;
+
+ bbnsm_rtc: rtc {
+ compatible = "nxp,imx93-bbnsm-rtc";
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ bbnsm_pwrkey: pwrkey {
+ compatible = "nxp,imx93-bbnsm-pwrkey";
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ linux,code = <KEY_POWER>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/nxp,lpc1850-creg.yaml b/Documentation/devicetree/bindings/mfd/nxp,lpc1850-creg.yaml
new file mode 100644
index 000000000000..89b4892e9ca7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nxp,lpc1850-creg.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/nxp,lpc1850-creg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The NXP LPC18xx/43xx CREG (Configuration Registers) block
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nxp,lpc1850-creg
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clock-controller:
+ type: object
+ description:
+ The NXP LPC18xx/43xx CREG (Configuration Registers) block contains
+ control registers for two low speed clocks. One of the clocks is a
+ 32 kHz oscillator driver with power up/down and clock gating. Next
+ is a fixed divider that creates a 1 kHz clock from the 32 kHz osc.
+
+ These clocks are used by the RTC and the Event Router peripherals.
+ The 32 kHz can also be routed to other peripherals to enable low
+ power modes.
+
+ properties:
+ compatible:
+ const: nxp,lpc1850-creg-clk
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description: |
+ 0 1 kHz clock
+ 1 32 kHz Oscillator
+
+ required:
+ - compatible
+ - clocks
+ - '#clock-cells'
+
+ additionalProperties: false
+
+ phy:
+ type: object
+ description: the internal USB OTG PHY in NXP LPC18xx and LPC43xx SoCs
+ properties:
+ compatible:
+ const: nxp,lpc1850-usb-otg-phy
+
+ clocks:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+ required:
+ - compatible
+ - clocks
+ - '#phy-cells'
+
+ additionalProperties: false
+
+ dma-mux:
+ type: object
+ description: NXP LPC18xx/43xx DMA MUX (DMA request router)
+ properties:
+ compatible:
+ const: nxp,lpc1850-dmamux
+
+ '#dma-cells':
+ const: 3
+ description: |
+ Should be set to <3>.
+ * 1st cell contain the master dma request signal
+ * 2nd cell contain the mux value (0-3) for the peripheral
+ * 3rd cell contain either 1 or 2 depending on the AHB master used.
+
+ dma-requests:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description: Number of DMA requests the controller can handle
+
+ dma-masters:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle pointing to the DMA controller
+
+ required:
+ - compatible
+ - '#dma-cells'
+ - dma-masters
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ syscon@40043000 {
+ compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
+ reg = <0x40043000 0x1000>;
+ clocks = <&ccu1 CLK_CPU_CREG>;
+ resets = <&rgu 5>;
+
+ clock-controller {
+ compatible = "nxp,lpc1850-creg-clk";
+ clocks = <&xtal32>;
+ #clock-cells = <1>;
+ };
+
+ phy {
+ compatible = "nxp,lpc1850-usb-otg-phy";
+ clocks = <&ccu1 CLK_USB0>;
+ #phy-cells = <0>;
+ };
+
+ dma-mux {
+ compatible = "nxp,lpc1850-dmamux";
+ #dma-cells = <3>;
+ dma-requests = <64>;
+ dma-masters = <&dmac>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/nxp,pf1550.yaml b/Documentation/devicetree/bindings/mfd/nxp,pf1550.yaml
new file mode 100644
index 000000000000..e50dc44252c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nxp,pf1550.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/nxp,pf1550.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PF1550 Power Management IC
+
+maintainers:
+ - Samuel Kayode <samuel.kayode@savoirfairelinux.com>
+
+description:
+ PF1550 PMIC provides battery charging and power supply for low power IoT and
+ wearable applications. This device consists of an i2c controlled MFD that
+ includes regulators, battery charging and an onkey/power button.
+
+$ref: /schemas/power/supply/power-supply.yaml
+
+properties:
+ compatible:
+ const: nxp,pf1550
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^(ldo[1-3]|sw[1-3]|vrefddr)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml
+ description:
+ regulator configuration for ldo1-3, buck converters(sw1-3)
+ and DDR termination reference voltage (vrefddr)
+ unevaluatedProperties: false
+
+ monitored-battery:
+ description: |
+ A phandle to a monitored battery node that contains a valid value
+ for:
+ constant-charge-voltage-max-microvolt.
+
+ nxp,thermal-regulation-celsius:
+ description:
+ Temperature threshold for thermal regulation of charger in celsius.
+ enum: [ 80, 95, 110, 125 ]
+
+ nxp,min-system-microvolt:
+ description:
+ System specific lower limit voltage.
+ enum: [ 3500000, 3700000, 4300000 ]
+
+ nxp,disable-key-power:
+ type: boolean
+ description:
+ Disable power-down using a long key-press. The onkey driver will remove
+ support for the KEY_POWER key press when triggered using a long press of
+ the onkey.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+
+ battery: battery-cell {
+ compatible = "simple-battery";
+ constant-charge-voltage-max-microvolt = <4400000>;
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "nxp,pf1550";
+ reg = <0x8>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+ monitored-battery = <&battery>;
+ nxp,min-system-microvolt = <4300000>;
+ nxp,thermal-regulation-celsius = <80>;
+
+ regulators {
+ sw1_reg: sw1 {
+ regulator-name = "sw1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1387500>;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-min-microvolt = <1270000>;
+ };
+ };
+
+ sw2_reg: sw2 {
+ regulator-name = "sw2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1387500>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ sw3_reg: sw3 {
+ regulator-name = "sw3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vldo1_reg: ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vldo2_reg: ldo2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vldo3_reg: ldo3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index aa1eaa59581b..a0d8c30c2631 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -64,8 +64,8 @@ Required properties if child node exists:
Properties for children:
The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
-See Documentation/devicetree/bindings/usb/ehci-omap.txt and
-Documentation/devicetree/bindings/usb/ohci-omap3.txt.
+See Documentation/devicetree/bindings/usb/generic-ehci.yaml and
+Documentation/devicetree/bindings/usb/generic-ohci.yaml.
Example for OMAP4:
@@ -78,14 +78,14 @@ usbhshost: usbhshost@4a064000 {
ranges;
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 76 0x4>;
};
usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = <0 77 0x4>;
diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
index ec3138c1bbfc..0c6e1870db1d 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/qcom,pm8008.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. PM8008 PMIC bindings
+title: Qualcomm Technologies, Inc. PM8008 PMIC
maintainers:
- - Guru Das Srinagesh <gurus@codeaurora.org>
+ - Guru Das Srinagesh <quic_gurus@quicinc.com>
description: |
Qualcomm Technologies, Inc. PM8008 is a dedicated camera PMIC that integrates
@@ -19,108 +19,136 @@ properties:
const: qcom,pm8008
reg:
- description:
- I2C slave address.
-
maxItems: 1
interrupts:
maxItems: 1
- description: Parent interrupt.
+ reset-gpios:
+ maxItems: 1
+
+ vdd-l1-l2-supply: true
+ vdd-l3-l4-supply: true
+ vdd-l5-supply: true
+ vdd-l6-supply: true
+ vdd-l7-supply: true
- "#interrupt-cells":
+ gpio-controller: true
+
+ "#gpio-cells":
const: 2
- description: |
- The first cell is the IRQ number, the second cell is the IRQ trigger
- flag. All interrupts are listed in include/dt-bindings/mfd/qcom-pm8008.h.
+ gpio-ranges:
+ maxItems: 1
interrupt-controller: true
- "#address-cells":
- const: 1
+ "#interrupt-cells":
+ const: 2
- "#size-cells":
+ "#thermal-sensor-cells":
const: 0
-patternProperties:
- "^gpio@[0-9a-f]+$":
+ pinctrl:
type: object
+ additionalProperties: false
+ patternProperties:
+ "-state$":
+ type: object
- description: |
- The GPIO peripheral. This node may be specified twice, one for each GPIO.
-
- properties:
- compatible:
- items:
- - const: qcom,pm8008-gpio
- - const: qcom,spmi-gpio
-
- reg:
- description: Peripheral address of one of the two GPIO peripherals.
- maxItems: 1
-
- gpio-controller: true
-
- gpio-ranges:
- maxItems: 1
+ allOf:
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
- interrupt-controller: true
+ properties:
+ pins:
+ items:
+ pattern: "^gpio[12]$"
- "#interrupt-cells":
- const: 2
+ function:
+ items:
+ - enum:
+ - normal
- "#gpio-cells":
- const: 2
+ required:
+ - pins
+ - function
- required:
- - compatible
- - reg
- - gpio-controller
- - interrupt-controller
- - "#gpio-cells"
- - gpio-ranges
- - "#interrupt-cells"
+ additionalProperties: false
+ regulators:
+ type: object
additionalProperties: false
+ patternProperties:
+ "^ldo[1-7]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- - "#address-cells"
- - "#size-cells"
+ - vdd-l1-l2-supply
+ - vdd-l3-l4-supply
+ - vdd-l5-supply
+ - vdd-l6-supply
+ - vdd-l7-supply
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+ - interrupt-controller
- "#interrupt-cells"
+ - "#thermal-sensor-cells"
additionalProperties: false
examples:
- |
- #include <dt-bindings/mfd/qcom-pm8008.h>
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- qupv3_se13_i2c {
+
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
- pm8008i@8 {
+
+ pm8008: pmic@8 {
compatible = "qcom,pm8008";
reg = <0x8>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-controller;
- #interrupt-cells = <2>;
interrupt-parent = <&tlmm>;
interrupts = <32 IRQ_TYPE_EDGE_RISING>;
- pm8008_gpios: gpio@c000 {
- compatible = "qcom,pm8008-gpio", "qcom,spmi-gpio";
- reg = <0xc000>;
- gpio-controller;
- gpio-ranges = <&pm8008_gpios 0 0 2>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
+ reset-gpios = <&tlmm 42 GPIO_ACTIVE_LOW>;
+
+ vdd-l1-l2-supply = <&vreg_s8b_1p2>;
+ vdd-l3-l4-supply = <&vreg_s1b_1p8>;
+ vdd-l5-supply = <&vreg_bob>;
+ vdd-l6-supply = <&vreg_bob>;
+ vdd-l7-supply = <&vreg_bob>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8008 0 0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ pinctrl {
+ gpio-keys-state {
+ pins = "gpio1";
+ function = "normal";
+ };
+ };
+
+ regulators {
+ ldo1 {
+ regulator-name = "vreg_l1";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1300000>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
index 6a3e3ede1ede..65c80e3b4500 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -33,16 +33,21 @@ properties:
compatible:
items:
- enum:
+ - qcom,pm2250
+ - qcom,pm6125
- qcom,pm6150
- qcom,pm6150l
- qcom,pm6350
- qcom,pm660
- qcom,pm660l
- qcom,pm7250b
+ - qcom,pm7550ba
- qcom,pm7325
+ - qcom,pm7550
- qcom,pm8004
- qcom,pm8005
- qcom,pm8009
+ - qcom,pm8010
- qcom,pm8019
- qcom,pm8028
- qcom,pm8110
@@ -54,30 +59,48 @@ properties:
- qcom,pm8350
- qcom,pm8350b
- qcom,pm8350c
+ - qcom,pm8450
+ - qcom,pm8550
+ - qcom,pm8550b
+ - qcom,pm8550ve
+ - qcom,pm8550vs
- qcom,pm8841
- qcom,pm8909
- qcom,pm8916
+ - qcom,pm8937
- qcom,pm8941
- qcom,pm8950
- qcom,pm8953
- qcom,pm8994
- qcom,pm8998
- qcom,pma8084
+ - qcom,pmc8180
+ - qcom,pmc8180c
+ - qcom,pmc8380
+ - qcom,pmd8028
- qcom,pmd9635
+ - qcom,pmi632
- qcom,pmi8950
- qcom,pmi8962
- qcom,pmi8994
- qcom,pmi8998
+ - qcom,pmih0108
+ - qcom,pmiv0104
- qcom,pmk8002
- qcom,pmk8350
+ - qcom,pmk8550
- qcom,pmm8155au
+ - qcom,pmm8654au
- qcom,pmp8074
- qcom,pmr735a
- qcom,pmr735b
+ - qcom,pmr735d
- qcom,pms405
- qcom,pmx55
- qcom,pmx65
+ - qcom,pmx75
- qcom,smb2351
+ - qcom,smb2360
- const: qcom,spmi-pmic
reg:
@@ -98,10 +121,17 @@ properties:
type: object
$ref: /schemas/regulator/qcom,spmi-regulator.yaml#
+ pwm:
+ type: object
+ $ref: /schemas/leds/leds-qcom-lpg.yaml#
+
patternProperties:
"^adc@[0-9a-f]+$":
type: object
- $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml#
+ oneOf:
+ - $ref: /schemas/iio/adc/qcom,spmi-iadc.yaml#
+ - $ref: /schemas/iio/adc/qcom,spmi-rradc.yaml#
+ - $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml#
"^adc-tm@[0-9a-f]+$":
type: object
@@ -109,23 +139,44 @@ patternProperties:
"^audio-codec@[0-9a-f]+$":
type: object
- additionalProperties: true # FIXME qcom,pm8916-wcd-analog-codec binding not converted yet
+ $ref: /schemas/sound/qcom,pm8916-wcd-analog-codec.yaml#
- "extcon@[0-9a-f]+$":
+ "^battery@[0-9a-f]+$":
type: object
- $ref: /schemas/extcon/qcom,pm8941-misc.yaml#
+ oneOf:
+ - $ref: /schemas/power/supply/qcom,pm8916-bms-vm.yaml#
+
+ "^charger@[0-9a-f]+$":
+ type: object
+ oneOf:
+ - $ref: /schemas/power/supply/qcom,pm8916-lbc.yaml#
+ - $ref: /schemas/power/supply/qcom,pm8941-charger.yaml#
+ - $ref: /schemas/power/supply/qcom,pm8941-coincell.yaml#
+ - $ref: /schemas/power/supply/qcom,pmi8998-charger.yaml#
- "gpio(s)?@[0-9a-f]+$":
+ "gpio@[0-9a-f]+$":
type: object
$ref: /schemas/pinctrl/qcom,pmic-gpio.yaml#
- "pon@[0-9a-f]+$":
+ "^led-controller@[0-9a-f]+$":
type: object
- $ref: /schemas/power/reset/qcom,pon.yaml#
+ $ref: /schemas/leds/qcom,spmi-flash-led.yaml#
- "pwm@[0-9a-f]+$":
+ "^nvram@[0-9a-f]+$":
type: object
- $ref: /schemas/leds/leds-qcom-lpg.yaml#
+ $ref: /schemas/nvmem/qcom,spmi-sdam.yaml#
+
+ "^pbs@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/soc/qcom/qcom,pbs.yaml#
+
+ "phy@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/phy/qcom,snps-eusb2-repeater.yaml#
+
+ "pon@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/power/reset/qcom,pon.yaml#
"^rtc@[0-9a-f]+$":
type: object
@@ -135,9 +186,21 @@ patternProperties:
type: object
$ref: /schemas/thermal/qcom,spmi-temp-alarm.yaml#
+ "^typec@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/usb/qcom,pmic-typec.yaml#
+
+ "^usb-detect@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/extcon/qcom,pm8941-misc.yaml#
+
+ "^usb-vbus-regulator@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/regulator/qcom,usb-vbus-regulator.yaml#
+
"^vibrator@[0-9a-f]+$":
type: object
- additionalProperties: true # FIXME qcom,pm8916-vib binding not converted yet
+ $ref: /schemas/input/qcom,pm8xxx-vib.yaml#
"^mpps@[0-9a-f]+$":
type: object
@@ -193,13 +256,13 @@ examples:
interrupt-controller;
#interrupt-cells = <4>;
- pmi8998_lsid0: pmic@2 {
+ pmic@2 {
compatible = "qcom,pmi8998", "qcom,spmi-pmic";
reg = <0x2 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
- pmi8998_gpio: gpios@c000 {
+ gpio@c000 {
compatible = "qcom,pmi8998-gpio", "qcom,spmi-gpio";
reg = <0xc000>;
gpio-controller;
@@ -256,12 +319,12 @@ examples:
#size-cells = <0>;
#io-channel-cells = <1>;
- adc-chan@6 {
+ channel@6 {
reg = <ADC5_DIE_TEMP>;
label = "die_temp";
};
- adc-chan@4f {
+ channel@4f {
reg = <ADC5_AMUX_THM3_100K_PU>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
@@ -284,7 +347,7 @@ examples:
};
};
- pm6150_gpio: gpios@c000 {
+ gpio@c000 {
compatible = "qcom,pm6150-gpio", "qcom,spmi-gpio";
reg = <0xc000>;
gpio-controller;
diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
index b12809b5cc22..14ae3f00ef7e 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml
@@ -17,20 +17,43 @@ properties:
compatible:
items:
- enum:
+ - qcom,msm8976-tcsr
- qcom,msm8998-tcsr
+ - qcom,qcm2290-tcsr
- qcom,qcs404-tcsr
+ - qcom,qcs615-tcsr
+ - qcom,qcs8300-tcsr
+ - qcom,sa8255p-tcsr
+ - qcom,sa8775p-tcsr
- qcom,sc7180-tcsr
- qcom,sc7280-tcsr
+ - qcom,sc8280xp-tcsr
- qcom,sdm630-tcsr
- qcom,sdm845-tcsr
+ - qcom,sdx55-tcsr
+ - qcom,sdx65-tcsr
+ - qcom,sdx75-tcsr
+ - qcom,sm4450-tcsr
+ - qcom,sm6115-tcsr
- qcom,sm8150-tcsr
+ - qcom,sm8250-tcsr
+ - qcom,sm8350-tcsr
+ - qcom,sm8450-tcsr
- qcom,tcsr-apq8064
- qcom,tcsr-apq8084
+ - qcom,tcsr-ipq5018
+ - qcom,tcsr-ipq5332
+ - qcom,tcsr-ipq5424
- qcom,tcsr-ipq6018
- qcom,tcsr-ipq8064
+ - qcom,tcsr-ipq8074
+ - qcom,tcsr-ipq9574
- qcom,tcsr-mdm9615
+ - qcom,tcsr-msm8226
- qcom,tcsr-msm8660
- qcom,tcsr-msm8916
+ - qcom,tcsr-msm8917
+ - qcom,tcsr-msm8937
- qcom,tcsr-msm8953
- qcom,tcsr-msm8960
- qcom,tcsr-msm8974
diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml
index 61bd0b3ce02f..63e18d6a9c21 100644
--- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml
@@ -15,11 +15,16 @@ description: |
properties:
compatible:
- enum:
- - qcom,pm8018
- - qcom,pm8058
- - qcom,pm8821
- - qcom,pm8921
+ oneOf:
+ - enum:
+ - qcom,pm8058
+ - qcom,pm8821
+ - qcom,pm8901
+ - qcom,pm8921
+ - items:
+ - enum:
+ - qcom,pm8018
+ - const: qcom,pm8921
reg:
maxItems: 1
@@ -39,9 +44,37 @@ properties:
interrupt-controller: true
patternProperties:
+ "gpio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/qcom,pmic-gpio.yaml#
+
+ "keypad@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/input/qcom,pm8921-keypad.yaml#
+
+ "led@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/leds/qcom,pm8058-led.yaml#
+
+ "mpps@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/pinctrl/qcom,pmic-mpp.yaml#
+
+ "pwrkey@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/input/qcom,pm8921-pwrkey.yaml#
+
"rtc@[0-9a-f]+$":
type: object
- $ref: "../rtc/qcom-pm8xxx-rtc.yaml"
+ $ref: /schemas/rtc/qcom-pm8xxx-rtc.yaml#
+
+ "vibrator@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/input/qcom,pm8xxx-vib.yaml#
+
+ "xoadc@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/iio/adc/qcom,pm8018-adc.yaml#
required:
- compatible
@@ -52,4 +85,23 @@ required:
- interrupt-controller
additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ ssbi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@0 {
+ compatible = "qcom,pm8921";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <32 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
deleted file mode 100644
index b823b8625243..000000000000
--- a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-Qualcomm Resource Power Manager (RPM)
-
-This driver is used to interface with the Resource Power Manager (RPM) found in
-various Qualcomm platforms. The RPM allows each component in the system to vote
-for state of the system resources, such as clocks, regulators and bus
-frequencies.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,rpm-apq8064"
- "qcom,rpm-msm8660"
- "qcom,rpm-msm8960"
- "qcom,rpm-ipq8064"
- "qcom,rpm-mdm9615"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: base address and size of the RPM's message ram
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: three entries specifying the RPM's:
- 1. acknowledgement interrupt
- 2. error interrupt
- 3. wakeup interrupt
-
-- interrupt-names:
- Usage: required
- Value type: <string-array>
- Definition: must be the three strings "ack", "err" and "wakeup", in order
-
-- qcom,ipc:
- Usage: required
- Value type: <prop-encoded-array>
-
- Definition: three entries specifying the outgoing ipc bit used for
- signaling the RPM:
- - phandle to a syscon node representing the apcs registers
- - u32 representing offset to the register within the syscon
- - u32 representing the ipc bit within the register
-
-
-= SUBNODES
-
-The RPM exposes resources to its subnodes. The below bindings specify the set
-of valid subnodes that can operate on these resources.
-
-== Regulators
-
-Regulator nodes are identified by their compatible:
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,rpm-pm8058-regulators"
- "qcom,rpm-pm8901-regulators"
- "qcom,rpm-pm8921-regulators"
- "qcom,rpm-pm8018-regulators"
- "qcom,rpm-smb208-regulators"
-
-- vdd_l0_l1_lvs-supply:
-- vdd_l2_l11_l12-supply:
-- vdd_l3_l4_l5-supply:
-- vdd_l6_l7-supply:
-- vdd_l8-supply:
-- vdd_l9-supply:
-- vdd_l10-supply:
-- vdd_l13_l16-supply:
-- vdd_l14_l15-supply:
-- vdd_l17_l18-supply:
-- vdd_l19_l20-supply:
-- vdd_l21-supply:
-- vdd_l22-supply:
-- vdd_l23_l24_l25-supply:
-- vdd_ncp-supply:
-- vdd_s0-supply:
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
- Usage: optional (pm8058 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- lvs0_in-supply:
-- lvs1_in-supply:
-- lvs2_in-supply:
-- lvs3_in-supply:
-- mvs_in-supply:
-- vdd_l0-supply:
-- vdd_l1-supply:
-- vdd_l2-supply:
-- vdd_l3-supply:
-- vdd_l4-supply:
-- vdd_l5-supply:
-- vdd_l6-supply:
-- vdd_s0-supply:
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s3-supply:
-- vdd_s4-supply:
- Usage: optional (pm8901 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- vdd_l1_l2_l12_l18-supply:
-- vdd_l3_l15_l17-supply:
-- vdd_l4_l14-supply:
-- vdd_l5_l8_l16-supply:
-- vdd_l6_l7-supply:
-- vdd_l9_l11-supply:
-- vdd_l10_l22-supply:
-- vdd_l21_l23_l29-supply:
-- vdd_l24-supply:
-- vdd_l25-supply:
-- vdd_l26-supply:
-- vdd_l27-supply:
-- vdd_l28-supply:
-- vdd_ncp-supply:
-- vdd_s1-supply:
-- vdd_s2-supply:
-- vdd_s4-supply:
-- vdd_s5-supply:
-- vdd_s6-supply:
-- vdd_s7-supply:
-- vdd_s8-supply:
-- vin_5vs-supply:
-- vin_lvs1_3_6-supply:
-- vin_lvs2-supply:
-- vin_lvs4_5_7-supply:
- Usage: optional (pm8921 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-- vin_lvs1-supply:
-- vdd_l7-supply:
-- vdd_l8-supply:
-- vdd_l9_l10_l11_l12-supply:
- Usage: optional (pm8018 only)
- Value type: <phandle>
- Definition: reference to regulator supplying the input pin, as
- described in the data sheet
-
-The regulator node houses sub-nodes for each regulator within the device. Each
-sub-node is identified using the node's name, with valid values listed for each
-of the pmics below.
-
-pm8058:
- l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15,
- l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4,
- lvs0, lvs1, ncp
-
-pm8901:
- l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3,
- mvs
-
-pm8921:
- s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
- l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28,
- l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch,
- ncp
-
-pm8018:
- s1, s2, s3, s4, s5, , l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
- l12, l14, lvs1
-
-smb208:
- s1a, s1b, s2a, s2b
-
-The content of each sub-node is defined by the standard binding for regulators -
-see regulator.txt - with additional custom properties described below:
-
-=== Switch-mode Power Supply regulator custom properties
-
-- bias-pull-down:
- Usage: optional
- Value type: <empty>
- Definition: enable pull down of the regulator when inactive
-
-- qcom,switch-mode-frequency:
- Usage: required
- Value type: <u32>
- Definition: Frequency (Hz) of the switch-mode power supply;
- must be one of:
- 19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
- 2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
- 1480000, 1370000, 1280000, 1200000
-
-- qcom,force-mode:
- Usage: optional (default if no other qcom,force-mode is specified)
- Value type: <u32>
- Definition: indicates that the regulator should be forced to a
- particular mode, valid values are:
- QCOM_RPM_FORCE_MODE_NONE - do not force any mode
- QCOM_RPM_FORCE_MODE_LPM - force into low power mode
- QCOM_RPM_FORCE_MODE_HPM - force into high power mode
- QCOM_RPM_FORCE_MODE_AUTO - allow regulator to automatically
- select its own mode based on
- realtime current draw, only for:
- pm8921 smps and ftsmps
-
-- qcom,power-mode-hysteretic:
- Usage: optional
- Value type: <empty>
- Definition: select that the power supply should operate in hysteretic
- mode, instead of the default pwm mode
-
-=== Low-dropout regulator custom properties
-
-- bias-pull-down:
- Usage: optional
- Value type: <empty>
- Definition: enable pull down of the regulator when inactive
-
-- qcom,force-mode:
- Usage: optional
- Value type: <u32>
- Definition: indicates that the regulator should not be forced to any
- particular mode, valid values are:
- QCOM_RPM_FORCE_MODE_NONE - do not force any mode
- QCOM_RPM_FORCE_MODE_LPM - force into low power mode
- QCOM_RPM_FORCE_MODE_HPM - force into high power mode
- QCOM_RPM_FORCE_MODE_BYPASS - set regulator to use bypass
- mode, i.e. to act as a switch
- and not regulate, only for:
- pm8921 pldo, nldo and nldo1200
-
-=== Negative Charge Pump custom properties
-
-- qcom,switch-mode-frequency:
- Usage: required
- Value type: <u32>
- Definition: Frequency (Hz) of the switch mode power supply;
- must be one of:
- 19200000, 9600000, 6400000, 4800000, 3840000, 3200000,
- 2740000, 2400000, 2130000, 1920000, 1750000, 1600000,
- 1480000, 1370000, 1280000, 1200000
-
-= EXAMPLE
-
- #include <dt-bindings/mfd/qcom-rpm.h>
-
- rpm@108000 {
- compatible = "qcom,rpm-msm8960";
- reg = <0x108000 0x1000>;
- qcom,ipc = <&apcs 0x8 2>;
-
- interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
- interrupt-names = "ack", "err", "wakeup";
-
- regulators {
- compatible = "qcom,rpm-pm8921-regulators";
- vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
-
- s1 {
- regulator-min-microvolt = <1225000>;
- regulator-max-microvolt = <1225000>;
-
- bias-pull-down;
-
- qcom,switch-mode-frequency = <3200000>;
- };
-
- pm8921_s4: s4 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
-
- qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
- };
- };
- };
-
diff --git a/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
new file mode 100644
index 000000000000..5454d9403cad
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qnap,ts433-mcu.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/qnap,ts433-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QNAP NAS on-board Microcontroller
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+description:
+ QNAP embeds a microcontroller on their NAS devices adding system feature
+ as PWM Fan control, additional LEDs, power button status and more.
+
+properties:
+ compatible:
+ enum:
+ - qnap,ts233-mcu
+ - qnap,ts433-mcu
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+
+patternProperties:
+ "^fan-[0-9]+$":
+ $ref: /schemas/hwmon/fan-common.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ uart {
+ mcu {
+ compatible = "qnap,ts433-mcu";
+
+ fan-0 {
+ #cooling-cells = <2>;
+ cooling-levels = <0 64 89 128 166 204 221 238>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/renesas,r2a11302ft.yaml b/Documentation/devicetree/bindings/mfd/renesas,r2a11302ft.yaml
new file mode 100644
index 000000000000..7b96619ebd8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/renesas,r2a11302ft.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/renesas,r2a11302ft.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R2A11302FT Power Supply ICs for R-Car
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+description: |
+ The Renesas R2A11302FT PMIC is used with Renesas R-Car Gen1/Gen2
+ based SoCs.
+
+ FIXME: The binding is incomplete and resembles the information gathered
+ so far.
+
+properties:
+ compatible:
+ const: renesas,r2a11302ft
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 6000000
+
+ spi-cpol: true
+
+ spi-cpha: true
+
+required:
+ - compatible
+ - reg
+ - spi-cpol
+ - spi-cpha
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ compatible = "renesas,r2a11302ft";
+ reg = <0>;
+ spi-max-frequency = <6000000>;
+ spi-cpol;
+ spi-cpha;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
index 4762eb1439ce..e3ccba177b21 100644
--- a/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
+++ b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
@@ -37,10 +37,10 @@ properties:
maxItems: 1
regulators:
- $ref: ../regulator/richtek,rt4831-regulator.yaml
+ $ref: /schemas/regulator/richtek,rt4831-regulator.yaml
backlight:
- $ref: ../leds/backlight/richtek,rt4831-backlight.yaml
+ $ref: /schemas/leds/backlight/richtek,rt4831-backlight.yaml
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
new file mode 100644
index 000000000000..386b1a50158a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/richtek,rt5033.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/richtek,rt5033.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 Power Management Integrated Circuit
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description:
+ RT5033 is a multifunction device which includes battery charger, fuel gauge,
+ flash LED current source, LDO and synchronous Buck converter for portable
+ applications. It is interfaced to host controller using I2C interface. The
+ battery fuel gauge uses a separate I2C bus.
+
+properties:
+ compatible:
+ const: richtek,rt5033
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ description:
+ The regulators of RT5033 have to be instantiated under a sub-node named
+ "regulators". For SAFE_LDO voltage there is only one value of 4.9 V. LDO
+ voltage ranges from 1.2 V to 3.0 V in 0.1 V steps. BUCK voltage ranges
+ from 1.0 V to 3.0 V in 0.1 V steps.
+ type: object
+ patternProperties:
+ "^(SAFE_LDO|LDO|BUCK)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ additionalProperties: false
+
+ charger:
+ type: object
+ $ref: /schemas/power/supply/richtek,rt5033-charger.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ battery: battery {
+ compatible = "simple-battery";
+ precharge-current-microamp = <450000>;
+ constant-charge-current-max-microamp = <1000000>;
+ charge-term-current-microamp = <150000>;
+ precharge-upper-limit-microvolt = <3500000>;
+ constant-charge-voltage-max-microvolt = <4350000>;
+ };
+
+ extcon {
+ usb_con: connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ fuel-gauge@35 {
+ compatible = "richtek,rt5033-battery";
+ reg = <0x35>;
+
+ interrupt-parent = <&msmgpio>;
+ interrupts = <121 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&fg_alert_default>;
+
+ power-supplies = <&rt5033_charger>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ pmic@34 {
+ compatible = "richtek,rt5033";
+ reg = <0x34>;
+
+ interrupt-parent = <&msmgpio>;
+ interrupts = <62 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_default>;
+
+ regulators {
+ safe_ldo_reg: SAFE_LDO {
+ regulator-name = "SAFE_LDO";
+ regulator-min-microvolt = <4900000>;
+ regulator-max-microvolt = <4900000>;
+ regulator-always-on;
+ };
+ ldo_reg: LDO {
+ regulator-name = "LDO";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+ buck_reg: BUCK {
+ regulator-name = "BUCK";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ };
+
+ rt5033_charger: charger {
+ compatible = "richtek,rt5033-charger";
+ monitored-battery = <&battery>;
+ richtek,usb-connector = <&usb_con>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
index 032a7fb0b4a7..e3d64307b531 100644
--- a/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
+++ b/Documentation/devicetree/bindings/mfd/ricoh,rn5t618.yaml
@@ -28,7 +28,7 @@ allOf:
regulators:
patternProperties:
"^(DCDC[1-4]|LDO[1-5]|LDORTC[12])$":
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
additionalProperties: false
- if:
properties:
@@ -40,7 +40,7 @@ allOf:
regulators:
patternProperties:
"^(DCDC[1-3]|LDO[1-5]|LDORTC[12])$":
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
additionalProperties: false
- if:
properties:
@@ -52,7 +52,7 @@ allOf:
regulators:
patternProperties:
"^(DCDC[1-5]|LDO[1-9]|LDO10|LDORTC[12])$":
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
additionalProperties: false
properties:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
index 4992f71b6fc3..da2391530c16 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml
@@ -42,9 +42,12 @@ properties:
rockchip,system-power-controller:
type: boolean
+ deprecated: true
description:
Telling whether or not this PMIC is controlling the system power.
+ system-power-controller: true
+
wakeup-source:
type: boolean
description:
@@ -79,7 +82,8 @@ properties:
patternProperties:
"^(DCDC_REG[1-4]|LDO_REG[1-3])$":
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
unevaluatedProperties: false
allOf:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
new file mode 100644
index 000000000000..eb5bca31948e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml
@@ -0,0 +1,429 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rockchip,rk806.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RK806 Power Management Integrated Circuit
+
+maintainers:
+ - Sebastian Reichel <sebastian.reichel@collabora.com>
+
+description:
+ Rockchip RK806 series PMIC. This device consists of an spi or
+ i2c controlled MFD that includes multiple switchable regulators.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk806
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ system-power-controller: true
+
+ rockchip,reset-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ description:
+ Mode to use when a reset of the PMIC is triggered.
+
+ The reset can be triggered either programmatically, via one of
+ the PWRCTRL pins (provided additional configuration) or
+ asserting RESETB pin low.
+
+ The following modes are supported
+
+ - 0; restart PMU,
+ - 1; reset all power off reset registers and force state to
+ switch to ACTIVE mode,
+ - 2; same as mode 1 and also pull RESETB pin down for 5ms,
+
+ For example, some hardware may require a full restart (mode 0)
+ in order to function properly as regulators are shortly
+ interrupted in this mode.
+
+ vcc1-supply:
+ description:
+ The input supply for dcdc-reg1.
+
+ vcc2-supply:
+ description:
+ The input supply for dcdc-reg2.
+
+ vcc3-supply:
+ description:
+ The input supply for dcdc-reg3.
+
+ vcc4-supply:
+ description:
+ The input supply for dcdc-reg4.
+
+ vcc5-supply:
+ description:
+ The input supply for dcdc-reg5.
+
+ vcc6-supply:
+ description:
+ The input supply for dcdc-reg6.
+
+ vcc7-supply:
+ description:
+ The input supply for dcdc-reg7.
+
+ vcc8-supply:
+ description:
+ The input supply for dcdc-reg8.
+
+ vcc9-supply:
+ description:
+ The input supply for dcdc-reg9.
+
+ vcc10-supply:
+ description:
+ The input supply for dcdc-reg10.
+
+ vcc11-supply:
+ description:
+ The input supply for pldo-reg1, pldo-reg2 and pldo-reg3.
+
+ vcc12-supply:
+ description:
+ The input supply for pldo-reg4 and pldo-reg5.
+
+ vcc13-supply:
+ description:
+ The input supply for nldo-reg1, nldo-reg2 and nldo-reg3.
+
+ vcc14-supply:
+ description:
+ The input supply for nldo-reg4 and nldo-reg5.
+
+ vcca-supply:
+ description:
+ The input supply for pldo-reg6.
+
+ regulators:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^(dcdc-reg([1-9]|10)|pldo-reg[1-6]|nldo-reg[1-5])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ properties:
+ function:
+ enum: [pin_fun0, pin_fun1, pin_fun2, pin_fun3, pin_fun4, pin_fun5]
+
+ pins:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [gpio_pwrctrl1, gpio_pwrctrl2, gpio_pwrctrl3]
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ compatible = "rockchip,rk806";
+ reg = <0x0>;
+
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc5v0_sys>;
+ vcc6-supply = <&vcc5v0_sys>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc5v0_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+ vcc10-supply = <&vcc5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc5v0_sys>;
+ vcc13-supply = <&vcc5v0_sys>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc5v0_sys>;
+
+ regulators {
+ vdd_gpu_s0: dcdc-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_s0: dcdc-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_log_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_log_s0";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd_vdenc_s0: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu_mem_s0: dcdc-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_mem_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_mem_s0: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_mem_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_2v0_pldo_s3: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_2v0_pldo_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2000000>;
+ };
+ };
+
+ vdd_vdenc_mem_s0: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_vdenc_mem_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v1_nldo_s3: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1100000>;
+ };
+ };
+
+ avcc_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "avcc_1v8_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd1_1v8_ddr_s3: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd1_1v8_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_1v8_s3: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vcc_1v8_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vcc_3v3_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vccio_sd_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ master_pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "master_pldo6_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_0v75_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdd2l_0v9_ddr_s3: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-name = "vdd2l_0v9_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ master_nldo3: nldo-reg3 {
+ regulator-name = "master_nldo3";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ avdd_0v75_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "avdd_0v75_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_0v85_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdd_0v85_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
index f5908fa01a61..50dfffac8fbf 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml
@@ -37,9 +37,12 @@ properties:
rockchip,system-power-controller:
type: boolean
+ deprecated: true
description:
Telling whether or not this PMIC is controlling the system power.
+ system-power-controller: true
+
wakeup-source:
type: boolean
description:
@@ -106,7 +109,8 @@ properties:
patternProperties:
"^(DCDC_REG[1-4]|LDO_REG[1-8]|SWITCH_REG[1-2])$":
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
unevaluatedProperties: false
required:
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml
deleted file mode 100644
index 7fb849ac74a7..000000000000
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml
+++ /dev/null
@@ -1,284 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: RK809 Power Management Integrated Circuit
-
-maintainers:
- - Chris Zhong <zyw@rock-chips.com>
- - Zhang Qing <zhangqing@rock-chips.com>
-
-description: |
- Rockchip RK809 series PMIC. This device consists of an i2c controlled MFD
- that includes regulators, an RTC, and power button.
-
-properties:
- compatible:
- enum:
- - rockchip,rk809
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- '#clock-cells':
- description: |
- See <dt-bindings/clock/rockchip,rk808.h> for clock IDs.
- minimum: 0
- maximum: 1
-
- clock-output-names:
- description:
- From common clock binding to override the default output clock name.
-
- rockchip,system-power-controller:
- type: boolean
- description:
- Telling whether or not this PMIC is controlling the system power.
-
- wakeup-source:
- type: boolean
- description:
- Device can be used as a wakeup source.
-
- vcc1-supply:
- description:
- The input supply for DCDC_REG1.
-
- vcc2-supply:
- description:
- The input supply for DCDC_REG2.
-
- vcc3-supply:
- description:
- The input supply for DCDC_REG3.
-
- vcc4-supply:
- description:
- The input supply for DCDC_REG4.
-
- vcc5-supply:
- description:
- The input supply for LDO_REG1, LDO_REG2, and LDO_REG3.
-
- vcc6-supply:
- description:
- The input supply for LDO_REG4, LDO_REG5, and LDO_REG6.
-
- vcc7-supply:
- description:
- The input supply for LDO_REG7, LDO_REG8, and LDO_REG9.
-
- vcc8-supply:
- description:
- The input supply for SWITCH_REG1.
-
- vcc9-supply:
- description:
- The input supply for DCDC_REG5 and SWITCH_REG2.
-
- regulators:
- type: object
- patternProperties:
- "^(LDO_REG[1-9]|DCDC_REG[1-5]|SWITCH_REG[1-2])$":
- type: object
- $ref: ../regulator/regulator.yaml#
- unevaluatedProperties: false
-
-allOf:
- - if:
- properties:
- '#clock-cells':
- const: 0
-
- then:
- properties:
- clock-output-names:
- maxItems: 1
-
- else:
- properties:
- clock-output-names:
- maxItems: 2
-
-required:
- - compatible
- - reg
- - interrupts
- - "#clock-cells"
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/pinctrl/rockchip.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/gpio/gpio.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- rk808: pmic@1b {
- compatible = "rockchip,rk808";
- reg = <0x1b>;
- #clock-cells = <1>;
- clock-output-names = "xin32k", "rk808-clkout2";
- interrupt-parent = <&gpio3>;
- interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&pmic_int_l_pin>;
- rockchip,system-power-controller;
- wakeup-source;
-
- vcc1-supply = <&vcc_sysin>;
- vcc2-supply = <&vcc_sysin>;
- vcc3-supply = <&vcc_sysin>;
- vcc4-supply = <&vcc_sysin>;
- vcc6-supply = <&vcc_sysin>;
- vcc7-supply = <&vcc_sysin>;
- vcc8-supply = <&vcc3v3_sys>;
- vcc9-supply = <&vcc_sysin>;
- vcc10-supply = <&vcc_sysin>;
- vcc11-supply = <&vcc_sysin>;
- vcc12-supply = <&vcc3v3_sys>;
-
- regulators {
- vdd_center: DCDC_REG1 {
- regulator-name = "vdd_center";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <6001>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_cpu_l: DCDC_REG2 {
- regulator-name = "vdd_cpu_l";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <6001>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_ddr: DCDC_REG3 {
- regulator-name = "vcc_ddr";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-on-in-suspend;
- };
- };
-
- vcc_1v8: vcc_wl: DCDC_REG4 {
- regulator-name = "vcc_1v8";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
- vcc1v8_pmupll: LDO_REG3 {
- regulator-name = "vcc1v8_pmupll";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
- vcc_sdio: LDO_REG4 {
- regulator-name = "vcc_sdio";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3000000>;
- };
- };
-
- vcca3v0_codec: LDO_REG5 {
- regulator-name = "vcca3v0_codec";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_1v5: LDO_REG6 {
- regulator-name = "vcc_1v5";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1500000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1500000>;
- };
- };
-
- vcca1v8_codec: LDO_REG7 {
- regulator-name = "vcca1v8_codec";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_3v0: LDO_REG8 {
- regulator-name = "vcc_3v0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3000000>;
- };
- };
-
- vcc3v3_s3: SWITCH_REG1 {
- regulator-name = "vcc3v3_s3";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc3v3_s0: SWITCH_REG2 {
- regulator-name = "vcc3v3_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
new file mode 100644
index 000000000000..0676890f101e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
@@ -0,0 +1,274 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rockchip,rk816.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RK816 Power Management Integrated Circuit
+
+maintainers:
+ - Chris Zhong <zyw@rock-chips.com>
+ - Zhang Qing <zhangqing@rock-chips.com>
+
+description:
+ Rockchip RK816 series PMIC. This device consists of an i2c controlled MFD
+ that includes regulators, a RTC, a GPIO controller, a power button, and a
+ battery charger manager with fuel gauge.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk816
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ description:
+ See <dt-bindings/clock/rockchip,rk808.h> for clock IDs.
+ const: 1
+
+ clock-output-names:
+ maxItems: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ system-power-controller:
+ type: boolean
+ description:
+ Telling whether or not this PMIC is controlling the system power.
+
+ wakeup-source:
+ type: boolean
+
+ vcc1-supply:
+ description:
+ The input supply for dcdc1.
+
+ vcc2-supply:
+ description:
+ The input supply for dcdc2.
+
+ vcc3-supply:
+ description:
+ The input supply for dcdc3.
+
+ vcc4-supply:
+ description:
+ The input supply for dcdc4.
+
+ vcc5-supply:
+ description:
+ The input supply for ldo1, ldo2, and ldo3.
+
+ vcc6-supply:
+ description:
+ The input supply for ldo4, ldo5, and ldo6.
+
+ vcc7-supply:
+ description:
+ The input supply for boost.
+
+ vcc8-supply:
+ description:
+ The input supply for otg-switch.
+
+ regulators:
+ type: object
+ patternProperties:
+ '^(boost|dcdc[1-4]|ldo[1-6]|otg-switch)$':
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ additionalProperties: false
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ properties:
+ function:
+ enum: [gpio, thermistor]
+
+ pins:
+ $ref: /schemas/types.yaml#/definitions/string
+ const: gpio0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rk816: pmic@1a {
+ compatible = "rockchip,rk816";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+ clock-output-names = "xin32k", "rk816-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ gpio-controller;
+ system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ #gpio-cells = <2>;
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc5-supply = <&vcc33_io>;
+ vcc6-supply = <&vcc_sys>;
+
+ regulators {
+ vdd_cpu: dcdc1 {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-ramp-delay = <6001>;
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_logic: dcdc2 {
+ regulator-name = "vdd_logic";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-ramp-delay = <6001>;
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_ddr: dcdc3 {
+ regulator-name = "vcc_ddr";
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc33_io: dcdc4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc33_io";
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vccio_pmu: ldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_tp: ldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_tp";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_10: ldo3 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd_10";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc18_lcd: ldo4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_lcd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: ldo5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd10_lcd: ldo6 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd10_lcd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+ };
+
+ rk816_gpio_pins: gpio-pins {
+ function = "gpio";
+ pins = "gpio0";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
index 935e17099213..2cb6d176a84c 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml
@@ -4,20 +4,21 @@
$id: http://devicetree.org/schemas/mfd/rockchip,rk817.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: RK817 Power Management Integrated Circuit
+title: RK809/RK817 Power Management Integrated Circuit
maintainers:
- Chris Zhong <zyw@rock-chips.com>
- Zhang Qing <zhangqing@rock-chips.com>
description: |
- Rockchip RK817 series PMIC. This device consists of an i2c controlled MFD
- that includes regulators, an RTC, a power button, an audio codec, and a
- battery charger manager.
+ Rockchip RK809/RK817 series PMIC. This device consists of an i2c controlled
+ MFD that includes regulators, an RTC, a power button and an audio codec.
+ The RK817 variant also provides a battery charger manager.
properties:
compatible:
enum:
+ - rockchip,rk809
- rockchip,rk817
reg:
@@ -32,15 +33,28 @@ properties:
minimum: 0
maximum: 1
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
clock-output-names:
description:
From common clock binding to override the default output clock name.
rockchip,system-power-controller:
type: boolean
+ deprecated: true
description:
Telling whether or not this PMIC is controlling the system power.
+ '#sound-dai-cells':
+ const: 0
+
+ system-power-controller: true
+
wakeup-source:
type: boolean
description:
@@ -76,41 +90,22 @@ properties:
vcc8-supply:
description:
- The input supply for BOOST.
+ The input supply for BOOST on RK817, or for SWITCH_REG2 on RK809.
vcc9-supply:
description:
- The input supply for OTG_SWITCH.
+ The input supply for OTG_SWITCH on RK817,
+ or for DCDC_REG5 and SWITCH_REG1 on RK809.
regulators:
type: object
patternProperties:
- "^(LDO_REG[1-9]|DCDC_REG[1-4]|BOOST|OTG_SWITCH)$":
- type: object
+ "^(LDO_REG[1-9]|DCDC_REG[1-5]|BOOST|OTG_SWITCH|SWITCH_REG[1-2])$":
+ $ref: /schemas/regulator/regulator.yaml
unevaluatedProperties: false
- $ref: ../regulator/regulator.yaml#
- unevaluatedProperties: false
-
- clocks:
- description:
- The input clock for the audio codec.
-
- clock-names:
- description:
- The clock name for the codec clock.
- items:
- - const: mclk
-
- '#sound-dai-cells':
- description:
- Needed for the interpretation of sound dais.
- const: 0
+ additionalProperties: false
codec:
- description: |
- The child node for the codec to hold additional properties. If no
- additional properties are required for the codec, this node can be
- omitted.
type: object
additionalProperties: false
properties:
@@ -120,10 +115,9 @@ properties:
Describes if the microphone uses differential mode.
charger:
- description: |
- The child node for the charger to hold additional properties. If a
- battery is not in use, this node can be omitted.
type: object
+ $ref: /schemas/power/supply/power-supply.yaml
+
properties:
monitored-battery:
description: |
@@ -163,6 +157,7 @@ properties:
additionalProperties: false
allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
- if:
properties:
'#clock-cells':
@@ -178,6 +173,22 @@ allOf:
clock-output-names:
maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk817
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^(DCDC_REG5|SWITCH_REG[1-2])$": false
+ else:
+ properties:
+ regulators:
+ patternProperties:
+ "^(BOOST|OTG_SWITCH)$": false
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
index b57c4b005cf4..90d944c27ba1 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml
@@ -37,9 +37,12 @@ properties:
rockchip,system-power-controller:
type: boolean
+ deprecated: true
description:
Telling whether or not this PMIC is controlling the system power.
+ system-power-controller: true
+
wakeup-source:
type: boolean
description:
@@ -98,7 +101,8 @@ properties:
patternProperties:
"^(DCDC_REG[1-4]|DCDC_BOOST|LDO_REG[1-9]|SWITCH_REG|HDMI_SWITCH|OTG_SWITCH)$":
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
unevaluatedProperties: false
required:
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
index fbface720678..4fc78efaa550 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/rohm,bd71815-pmic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ROHM BD71815 Power Management Integrated Circuit bindings
+title: ROHM BD71815 Power Management Integrated Circuit
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
BD71815AGW is a single-chip power management ICs for battery-powered
@@ -46,28 +46,28 @@ properties:
rohm,clkout-open-drain:
description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
- rohm,charger-sense-resistor-ohms:
- minimum: 10000000
- maximum: 50000000
+ rohm,charger-sense-resistor-micro-ohms:
+ minimum: 10000
+ maximum: 50000
description: |
- BD71827 and BD71828 have SAR ADC for measuring charging currents.
- External sense resistor (RSENSE in data sheet) should be used. If
- something other but 30MOhm resistor is used the resistance value
- should be given here in Ohms.
- default: 30000000
+ BD71815 has SAR ADC for measuring charging currents. External sense
+ resistor (RSENSE in data sheet) should be used. If something other
+ but a 30 mOhm resistor is used the resistance value should be given
+ here in micro Ohms.
+ default: 30000
regulators:
- $ref: ../regulator/rohm,bd71815-regulator.yaml
+ $ref: /schemas/regulator/rohm,bd71815-regulator.yaml
description:
List of child nodes that specify the regulators.
gpio-reserved-ranges:
description: |
- Usage of BD71828 GPIO pins can be changed via OTP. This property can be
+ Usage of BD71815 GPIO pins can be changed via OTP. This property can be
used to mark the pins which should not be configured for GPIO. Please see
the ../gpio/gpio.txt for more information.
@@ -113,7 +113,7 @@ examples:
gpio-controller;
#gpio-cells = <2>;
- rohm,charger-sense-resistor-ohms = <10000000>;
+ rohm,charger-sense-resistor-micro-ohms = <10000>;
regulators {
buck1: buck1 {
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
index 8380166d176c..09e7d68e92bf 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/rohm,bd71828-pmic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ROHM BD71828 Power Management Integrated Circuit bindings
+title: ROHM BD71828 Power Management Integrated Circuit
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
BD71828GW is a single-chip power management IC for battery-powered portable
@@ -17,7 +17,12 @@ description: |
properties:
compatible:
- const: rohm,bd71828
+ oneOf:
+ - const: rohm,bd71828
+
+ - items:
+ - const: rohm,bd71879
+ - const: rohm,bd71828
reg:
description:
@@ -46,26 +51,27 @@ properties:
rohm,clkout-open-drain:
description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
- rohm,charger-sense-resistor-ohms:
- minimum: 10000000
- maximum: 50000000
+ rohm,charger-sense-resistor-micro-ohms:
+ minimum: 10000
+ maximum: 50000
+ default: 30000
description: |
BD71827 and BD71828 have SAR ADC for measuring charging currents.
External sense resistor (RSENSE in data sheet) should be used. If some
- other but 30MOhm resistor is used the resistance value should be given
- here in Ohms.
+ other but 30mOhm resistor is used the resistance value should be given
+ here in microohms.
regulators:
- $ref: ../regulator/rohm,bd71828-regulator.yaml
+ $ref: /schemas/regulator/rohm,bd71828-regulator.yaml
description:
List of child nodes that specify the regulators.
leds:
- $ref: ../leds/rohm,bd71828-leds.yaml
+ $ref: /schemas/leds/rohm,bd71828-leds.yaml
gpio-reserved-ranges:
description: |
@@ -73,6 +79,8 @@ properties:
used to mark the pins which should not be configured for GPIO. Please see
the ../gpio/gpio.txt for more information.
+ system-power-controller: true
+
required:
- compatible
- reg
@@ -107,7 +115,7 @@ examples:
#gpio-cells = <2>;
gpio-reserved-ranges = <0 1>, <2 1>;
- rohm,charger-sense-resistor-ohms = <10000000>;
+ rohm,charger-sense-resistor-micro-ohms = <10000>;
regulators {
buck1: BUCK1 {
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
index 3bfdd33702ad..08f958dc700d 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/rohm,bd71837-pmic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ROHM BD71837 Power Management Integrated Circuit bindings
+title: ROHM BD71837 Power Management Integrated Circuit
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
BD71837MWV is programmable Power Management ICs for powering single-core,
@@ -109,7 +109,7 @@ properties:
- 14000
regulators:
- $ref: ../regulator/rohm,bd71837-regulator.yaml
+ $ref: /schemas/regulator/rohm,bd71837-regulator.yaml
description:
List of child nodes that specify the regulators.
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
index 5d531051a153..d783cc4e4e86 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/rohm,bd71847-pmic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ROHM BD71847 and BD71850 Power Management Integrated Circuit bindings
+title: ROHM BD71847 and BD71850 Power Management Integrated Circuit
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
BD71847AMWV and BD71850MWV are programmable Power Management ICs for powering
@@ -130,7 +130,6 @@ dependencies:
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/leds/common.h>
i2c {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
index 89f9efee465b..47611c2a982c 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml
@@ -67,7 +67,7 @@ properties:
patternProperties:
"^(vd09|vd18|vd25|vd33|dvfs)$":
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
properties:
regulator-name:
@@ -99,29 +99,29 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pmic: pmic@30 {
- compatible = "rohm,bd9571mwv";
- reg = <0x30>;
- interrupt-parent = <&gpio2>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- rohm,ddr-backup-power = <0xf>;
- rohm,rstbmode-pulse;
-
- regulators {
- dvfs: dvfs {
- regulator-name = "dvfs";
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1030000>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic: pmic@30 {
+ compatible = "rohm,bd9571mwv";
+ reg = <0x30>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ rohm,ddr-backup-power = <0xf>;
+ rohm,rstbmode-pulse;
+
+ regulators {
+ dvfs: dvfs {
+ regulator-name = "dvfs";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1030000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
index 6483860da955..70fd9b5e4c3f 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mfd/rohm,bd9576-pmic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: ROHM BD9576MUF and BD9573MUF Power Management Integrated Circuit bindings
+title: ROHM BD9576MUF and BD9573MUF Power Management Integrated Circuit
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
BD9576MUF and BD9573MUF are power management ICs primarily intended for
@@ -34,7 +34,7 @@ properties:
BD9576 and BD9573 VOUT1 regulator enable state can be individually
controlled by a GPIO. This is dictated by state of vout1-en pin during
the PMIC startup. If vout1-en is LOW during PMIC startup then the VOUT1
- enable sate is controlled via this pin. Set this property if vout1-en
+ enable state is controlled via this pin. Set this property if vout1-en
is wired to be down at PMIC start-up.
type: boolean
@@ -61,7 +61,7 @@ properties:
rohm,hw-timeout-ms:
maxItems: 2
description:
- Watchog timeout in milliseconds. If single value is given it is
+ Watchdog timeout in milliseconds. If single value is given it is
the maximum timeout. Eg. if pinging watchdog is not done within this time
limit the watchdog will be triggered. If two values are given watchdog
is configured in "window mode". Then first value is limit for short-ping
@@ -71,7 +71,7 @@ properties:
# (HW) minimum for max timeout is 4ms, maximum 4416 ms.
regulators:
- $ref: ../regulator/rohm,bd9576-regulator.yaml
+ $ref: /schemas/regulator/rohm,bd9576-regulator.yaml
description:
List of child nodes that specify the regulators.
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml
new file mode 100644
index 000000000000..adb491bcc8dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd96801-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD96801/BD96805 Scalable Power Management Integrated Circuit
+
+maintainers:
+ - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+
+description:
+ BD96801 and BD96805 are automotive grade, single-chip power management ICs.
+ They both integrate 4 buck converters and 3 LDOs with safety features like
+ over-/under voltage and over current detection and a watchdog.
+
+properties:
+ compatible:
+ enum:
+ - rohm,bd96801
+ - rohm,bd96805
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ The PMIC provides intb and errb IRQ lines. The errb IRQ line is used
+ for fatal IRQs which will cause the PMIC to shut down power outputs.
+ In many systems this will shut down the SoC controlling the PMIC and
+ connecting/handling the errb can be omitted. However, there are cases
+ where the SoC is not powered by the PMIC or has a short time backup
+ energy to handle shutdown of critical hardware. In that case it may be
+ useful to connect the errb and handle errb events.
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - enum: [intb, errb]
+ - const: errb
+
+ rohm,hw-timeout-ms:
+ description:
+ Watchdog timeout value(s). First walue is timeout limit. Second value is
+ optional value for 'too early' watchdog ping if window timeout mode is
+ to be used.
+ minItems: 1
+ maxItems: 2
+
+ rohm,wdg-action:
+ description:
+ Whether the watchdog failure must turn off the regulator power outputs or
+ just toggle the INTB line.
+ enum:
+ - prstb
+ - intb-only
+
+ timeout-sec: true
+
+ regulators:
+ $ref: /schemas/regulator/rohm,bd96801-regulator.yaml
+ description:
+ List of child nodes that specify the regulators.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - regulators
+
+allOf:
+ - $ref: /schemas/watchdog/watchdog.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic: pmic@60 {
+ reg = <0x60>;
+ compatible = "rohm,bd96801";
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>, <6 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "intb", "errb";
+
+ regulators {
+ buck1 {
+ regulator-name = "buck1";
+ regulator-ramp-delay = <1250>;
+ /* 0.5V min INITIAL - 150 mV tune */
+ regulator-min-microvolt = <350000>;
+ /* 3.3V + 150mV tune */
+ regulator-max-microvolt = <3450000>;
+
+ /* These can be set only when PMIC is in STBY */
+ rohm,initial-voltage-microvolt = <500000>;
+ regulator-ov-error-microvolt = <230000>;
+ regulator-uv-error-microvolt = <230000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <0>;
+ };
+ buck2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <350000>;
+ regulator-max-microvolt = <3450000>;
+
+ rohm,initial-voltage-microvolt = <3000000>;
+ regulator-ov-error-microvolt = <18000>;
+ regulator-uv-error-microvolt = <18000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <1>;
+ };
+ buck3 {
+ regulator-name = "buck3";
+ regulator-min-microvolt = <350000>;
+ regulator-max-microvolt = <3450000>;
+
+ rohm,initial-voltage-microvolt = <600000>;
+ regulator-ov-warn-microvolt = <18000>;
+ regulator-uv-warn-microvolt = <18000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-error-kelvin = <0>;
+ };
+ buck4 {
+ regulator-name = "buck4";
+ regulator-min-microvolt = <350000>;
+ regulator-max-microvolt = <3450000>;
+
+ rohm,initial-voltage-microvolt = <600000>;
+ regulator-ov-warn-microvolt = <18000>;
+ regulator-uv-warn-microvolt = <18000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-error-kelvin = <0>;
+ };
+ ldo5 {
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+
+ rohm,initial-voltage-microvolt = <500000>;
+ regulator-ov-error-microvolt = <36000>;
+ regulator-uv-error-microvolt = <34000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <0>;
+ };
+ ldo6 {
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+
+ rohm,initial-voltage-microvolt = <300000>;
+ regulator-ov-error-microvolt = <36000>;
+ regulator-uv-error-microvolt = <34000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <0>;
+ };
+ ldo7 {
+ regulator-name = "ldo7";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+
+ rohm,initial-voltage-microvolt = <500000>;
+ regulator-ov-error-microvolt = <36000>;
+ regulator-uv-error-microvolt = <34000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml
new file mode 100644
index 000000000000..6cbea796d12f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd96802-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD96802 / BD96806 Scalable Power Management Integrated Circuit
+
+maintainers:
+ - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+
+description: |
+ BD96802Qxx-C and BD96806 are automotive grade configurable Power Management
+ Integrated Circuits supporting Functional Safety features for application
+ processors, SoCs and FPGAs
+
+properties:
+ compatible:
+ enum:
+ - rohm,bd96802
+ - rohm,bd96806
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ The PMIC provides intb and errb IRQ lines. The errb IRQ line is used
+ for fatal IRQs which will cause the PMIC to shut down power outputs.
+ In many systems this will shut down the SoC contolling the PMIC and
+ connecting/handling the errb can be omitted. However, there are cases
+ where the SoC is not powered by the PMIC or has a short time backup
+ energy to handle shutdown of critical hardware. In that case it may be
+ useful to connect the errb and handle errb events.
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - enum: [intb, errb]
+ - const: errb
+
+ regulators:
+ $ref: ../regulator/rohm,bd96802-regulator.yaml
+ description:
+ List of child nodes that specify the regulators.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic: pmic@62 {
+ reg = <0x62>;
+ compatible = "rohm,bd96802";
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>, <6 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "intb", "errb";
+
+ regulators {
+ buck1 {
+ regulator-name = "buck1";
+ regulator-ramp-delay = <1250>;
+ /* 0.5V min INITIAL - 150 mV tune */
+ regulator-min-microvolt = <350000>;
+ /* 3.3V + 150mV tune */
+ regulator-max-microvolt = <3450000>;
+
+ /* These can be set only when PMIC is in STBY */
+ rohm,initial-voltage-microvolt = <500000>;
+ regulator-ov-error-microvolt = <230000>;
+ regulator-uv-error-microvolt = <230000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <0>;
+ };
+ buck2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <350000>;
+ regulator-max-microvolt = <3450000>;
+
+ rohm,initial-voltage-microvolt = <3000000>;
+ regulator-ov-error-microvolt = <18000>;
+ regulator-uv-error-microvolt = <18000>;
+ regulator-temp-protection-kelvin = <1>;
+ regulator-temp-warn-kelvin = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml
index b97b06848729..f154103f32cc 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml
@@ -85,7 +85,7 @@ examples:
};
i2s@11440000 {
- compatible = "samsung,exynos7-i2s";
+ compatible = "samsung,exynos5433-i2s", "samsung,exynos7-i2s";
reg = <0x11440000 0x100>;
dmas = <&adma 0>, <&adma 2>;
dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2dos05.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2dos05.yaml
new file mode 100644
index 000000000000..b85285720c16
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/samsung,s2dos05.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/samsung,s2dos05.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S2DOS05 Power Management IC
+
+maintainers:
+ - Dzmitry Sankouski <dsankouski@gmail.com>
+
+description:
+ This is a device tree bindings for S2DOS family of Power Management IC (PMIC).
+
+ The S2DOS05 is a companion power management IC for the panel and touchscreen
+ in smart phones. Provides voltage regulators and
+ ADC for power/current measurements.
+
+ Regulator section has 4 LDO and 1 BUCK regulators and also
+ provides ELVDD, ELVSS, AVDD lines.
+
+properties:
+ compatible:
+ const: samsung,s2dos05
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ patternProperties:
+ "^buck|ldo[1-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - regulator-name
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@60 {
+ compatible = "samsung,s2dos05";
+ reg = <0x60>;
+
+ regulators {
+ ldo1 {
+ regulator-active-discharge = <1>;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-name = "ldo1";
+ };
+
+ ldo2 {
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "ldo2";
+ };
+
+ ldo3 {
+ regulator-active-discharge = <1>;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "ldo3";
+ };
+
+ ldo4 {
+ regulator-active-discharge = <1>;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3775000>;
+ regulator-name = "ldo4";
+ };
+
+ buck {
+ regulator-active-discharge = <1>;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <2100000>;
+ regulator-name = "buck";
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml
index 055dfc337c2f..ad92eb6fcd3a 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml
@@ -27,7 +27,7 @@ properties:
maxItems: 1
regulators:
- $ref: ../regulator/samsung,s2mpa01.yaml
+ $ref: /schemas/regulator/samsung,s2mpa01.yaml
description:
List of child nodes that specify the regulators.
diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
index 5ff6546c72b7..31d544a9c05c 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
@@ -20,14 +20,16 @@ description: |
properties:
compatible:
enum:
+ - samsung,s2mpg10-pmic
- samsung,s2mps11-pmic
- samsung,s2mps13-pmic
- samsung,s2mps14-pmic
- samsung,s2mps15-pmic
- samsung,s2mpu02-pmic
+ - samsung,s2mpu05-pmic
clocks:
- $ref: ../clock/samsung,s2mps11.yaml
+ $ref: /schemas/clock/samsung,s2mps11.yaml
description:
Child node describing clock provider.
@@ -53,15 +55,16 @@ properties:
samsung,s2mps11-wrstbi-ground:
description: |
Indicates that WRSTBI pin of PMIC is pulled down. When the system is
- suspended it will always go down thus triggerring unwanted buck warm
+ suspended it will always go down thus triggering unwanted buck warm
reset (setting buck voltages to default values).
type: boolean
+ system-power-controller: true
+
wakeup-source: true
required:
- compatible
- - reg
- regulators
additionalProperties: false
@@ -71,11 +74,36 @@ allOf:
properties:
compatible:
contains:
+ const: samsung,s2mpg10-pmic
+ then:
+ properties:
+ reg: false
+ samsung,s2mps11-acokb-ground: false
+ samsung,s2mps11-wrstbi-ground: false
+
+ # oneOf is required, because dtschema's fixups.py doesn't handle this
+ # nesting here. Its special treatment to allow either interrupt property
+ # when only one is specified in the binding works at the top level only.
+ oneOf:
+ - required: [interrupts]
+ - required: [interrupts-extended]
+
+ else:
+ properties:
+ system-power-controller: false
+
+ required:
+ - reg
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: samsung,s2mps11-pmic
then:
properties:
regulators:
- $ref: ../regulator/samsung,s2mps11.yaml
+ $ref: /schemas/regulator/samsung,s2mps11.yaml
samsung,s2mps11-wrstbi-ground: false
- if:
@@ -86,7 +114,7 @@ allOf:
then:
properties:
regulators:
- $ref: ../regulator/samsung,s2mps13.yaml
+ $ref: /schemas/regulator/samsung,s2mps13.yaml
samsung,s2mps11-acokb-ground: false
- if:
@@ -97,7 +125,7 @@ allOf:
then:
properties:
regulators:
- $ref: ../regulator/samsung,s2mps14.yaml
+ $ref: /schemas/regulator/samsung,s2mps14.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
@@ -109,7 +137,7 @@ allOf:
then:
properties:
regulators:
- $ref: ../regulator/samsung,s2mps15.yaml
+ $ref: /schemas/regulator/samsung,s2mps15.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
@@ -121,7 +149,19 @@ allOf:
then:
properties:
regulators:
- $ref: ../regulator/samsung,s2mpu02.yaml
+ $ref: /schemas/regulator/samsung,s2mpu02.yaml
+ samsung,s2mps11-acokb-ground: false
+ samsung,s2mps11-wrstbi-ground: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,s2mpu05-pmic
+ then:
+ properties:
+ regulators:
+ $ref: /schemas/regulator/samsung,s2mpu05.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
diff --git a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
index 10c7b408f33a..249248078c59 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
@@ -21,7 +21,7 @@ properties:
const: samsung,s5m8767-pmic
clocks:
- $ref: ../clock/samsung,s2mps11.yaml
+ $ref: /schemas/clock/samsung,s2mps11.yaml
description:
Child node describing clock provider.
@@ -32,7 +32,7 @@ properties:
maxItems: 1
regulators:
- $ref: ../regulator/samsung,s5m8767.yaml
+ $ref: /schemas/regulator/samsung,s5m8767.yaml
description:
List of child nodes that specify the regulators.
@@ -153,29 +153,18 @@ dependencies:
additionalProperties: false
allOf:
- - if:
+ - not:
required:
- s5m8767,pmic-buck2-uses-gpio-dvs
- then:
- properties:
- s5m8767,pmic-buck3-uses-gpio-dvs: false
- s5m8767,pmic-buck4-uses-gpio-dvs: false
-
- - if:
- required:
- s5m8767,pmic-buck3-uses-gpio-dvs
- then:
- properties:
- s5m8767,pmic-buck2-uses-gpio-dvs: false
- s5m8767,pmic-buck4-uses-gpio-dvs: false
-
- - if:
+ - not:
required:
+ - s5m8767,pmic-buck2-uses-gpio-dvs
+ - s5m8767,pmic-buck4-uses-gpio-dvs
+ - not:
+ required:
+ - s5m8767,pmic-buck3-uses-gpio-dvs
- s5m8767,pmic-buck4-uses-gpio-dvs
- then:
- properties:
- s5m8767,pmic-buck2-uses-gpio-dvs: false
- s5m8767,pmic-buck3-uses-gpio-dvs: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml b/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml
index ee0be32ac020..4f829fe75d41 100644
--- a/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml
+++ b/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml
@@ -32,6 +32,17 @@ properties:
Specifying the power good GPIOs.
maxItems: 1
+ enable-gpios:
+ maxItems: 1
+
+ vcom-en-gpios:
+ maxItems: 1
+
+ vin-supply:
+ description:
+ Supply for the whole chip. Some vendor kernels and devicetrees
+ declare this as a non-existing GPIO named "pwrall".
+
regulators:
type: object
diff --git a/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml b/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml
new file mode 100644
index 000000000000..c6593ac6ef6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/spacemit,p1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT P1 Power Management Integrated Circuit
+
+maintainers:
+ - Troy Mitchell <troy.mitchell@linux.spacemit.com>
+
+description:
+ P1 is an I2C-controlled PMIC produced by SpacemiT. It implements six
+ constant-on-time buck converters and twelve low-dropout regulators.
+ It also contains a load switch, watchdog timer, real-time clock, eight
+ 12-bit ADC channels, and six GPIOs. Additional details are available
+ in the "Power Stone/P1" section at the following link.
+ https://developer.spacemit.com/documentation
+
+properties:
+ compatible:
+ const: spacemit,p1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vin-supply:
+ description: Input supply phandle.
+
+ regulators:
+ type: object
+
+ patternProperties:
+ "^(buck[1-6]|aldo[1-4]|dldo[1-7])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@41 {
+ compatible = "spacemit,p1";
+ reg = <0x41>;
+ interrupts = <64>;
+
+ regulators {
+ buck1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ aldo1 {
+ regulator-name = "aldo1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+
+ dldo1 {
+ regulator-name = "dldo1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
new file mode 100644
index 000000000000..b023e1ef8d3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
@@ -0,0 +1,244 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/sprd,sc2731.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC27xx PMIC
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ Spreadtrum PMICs belonging to the SC27xx series integrate all mobile handset
+ power management, audio codec, battery management and user interface support
+ functions in a single chip. They have 6 major functional blocks:
+ - DCDCs to support CPU, memory
+ - LDOs to support both internal and external requirements
+ - Battery management system, such as charger, fuel gauge
+ - Audio codec
+ - User interface functions, such as indicator, flash LED and so on
+ - IC level interface, such as power on/off control, RTC, typec and so on
+
+properties:
+ $nodename:
+ pattern: '^pmic@[0-9a-f]+$'
+
+ compatible:
+ enum:
+ - sprd,sc2720
+ - sprd,sc2721
+ - sprd,sc2723
+ - sprd,sc2730
+ - sprd,sc2731
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+ spi-max-frequency: true
+
+ '#address-cells':
+ const: 1
+
+ '#interrupt-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ regulators:
+ type: object
+ $ref: /schemas/regulator/sprd,sc2731-regulator.yaml#
+
+patternProperties:
+ "^adc@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/iio/adc/sprd,sc2720-adc.yaml#
+
+ "^charger@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/power/supply/sc2731-charger.yaml#
+
+ "^efuse@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/nvmem/sprd,sc2731-efuse.yaml#
+
+ "^fuel-gauge@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/power/supply/sc27xx-fg.yaml#
+
+ "^gpio@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/gpio/sprd,gpio-eic.yaml#
+
+ "^led-controller@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/leds/sprd,sc2731-bltc.yaml#
+
+ "^rtc@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/rtc/sprd,sc2731-rtc.yaml#
+
+ "^vibrator@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/input/sprd,sc27xx-vibrator.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - spi-max-frequency
+ - '#address-cells'
+ - '#interrupt-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ spi-max-frequency = <26000000>;
+ #address-cells = <1>;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ charger@0 {
+ compatible = "sprd,sc2731-charger";
+ reg = <0x0>;
+ phys = <&ssphy>;
+ monitored-battery = <&bat>;
+ };
+
+ led-controller@200 {
+ compatible = "sprd,sc2731-bltc";
+ reg = <0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <0x1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
+ rtc@280 {
+ compatible = "sprd,sc2731-rtc";
+ reg = <0x280>;
+ interrupt-parent = <&sc2731_pmic>;
+ interrupts = <2>;
+ };
+
+ pmic_eic: gpio@300 {
+ compatible = "sprd,sc2731-eic";
+ reg = <0x300>;
+ interrupt-parent = <&sc2731_pmic>;
+ interrupts = <5>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ efuse@380 {
+ compatible = "sprd,sc2731-efuse";
+ reg = <0x380>;
+ hwlocks = <&hwlock 12>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Data cells */
+ fgu_calib: calib@6 {
+ reg = <0x6 0x2>;
+ bits = <0 9>;
+ };
+
+ adc_big_scale: calib@24 {
+ reg = <0x24 0x2>;
+ };
+
+ adc_small_scale: calib@26 {
+ reg = <0x26 0x2>;
+ };
+ };
+
+ pmic_adc: adc@480 {
+ compatible = "sprd,sc2731-adc";
+ reg = <0x480>;
+ interrupt-parent = <&sc2731_pmic>;
+ interrupts = <0>;
+ #io-channel-cells = <1>;
+ hwlocks = <&hwlock 4>;
+ nvmem-cells = <&adc_big_scale>, <&adc_small_scale>;
+ nvmem-cell-names = "big_scale_calib", "small_scale_calib";
+ };
+
+ fuel-gauge@a00 {
+ compatible = "sprd,sc2731-fgu";
+ reg = <0xa00>;
+ battery-detect-gpios = <&pmic_eic 9 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&sc2731_pmic>;
+ interrupts = <4>;
+ io-channels = <&pmic_adc 5>, <&pmic_adc 14>;
+ io-channel-names = "bat-temp", "charge-vol";
+ nvmem-cells = <&fgu_calib>;
+ nvmem-cell-names = "fgu_calib";
+ monitored-battery = <&bat>;
+ sprd,calib-resistance-micro-ohms = <21500>;
+ };
+
+ vibrator@ec8 {
+ compatible = "sprd,sc2731-vibrator";
+ reg = <0xec8>;
+ };
+
+ regulators {
+ compatible = "sprd,sc2731-regulator";
+
+ BUCK_CPU0 {
+ regulator-name = "vddarm0";
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1996875>;
+ regulator-ramp-delay = <25000>;
+ regulator-always-on;
+ };
+
+ LDO_CAMA0 {
+ regulator-name = "vddcama0";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ regulator-enable-ramp-delay = <100>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt b/Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt
deleted file mode 100644
index 21b9a897fca5..000000000000
--- a/Documentation/devicetree/bindings/mfd/sprd,sc27xx-pmic.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Spreadtrum SC27xx Power Management Integrated Circuit (PMIC)
-
-The Spreadtrum SC27xx series PMICs contain SC2720, SC2721, SC2723, SC2730
-and SC2731. The Spreadtrum PMIC belonging to SC27xx series integrates all
-mobile handset power management, audio codec, battery management and user
-interface support function in a single chip. It has 6 major functional
-blocks:
-- DCDCs to support CPU, memory.
-- LDOs to support both internal and external requirement.
-- Battery management system, such as charger, fuel gauge.
-- Audio codec.
-- User interface function, such as indicator, flash LED and so on.
-- IC level interface, such as power on/off control, RTC and typec and so on.
-
-Required properties:
-- compatible: Should be one of the following:
- "sprd,sc2720"
- "sprd,sc2721"
- "sprd,sc2723"
- "sprd,sc2730"
- "sprd,sc2731"
-- reg: The address of the device chip select, should be 0.
-- spi-max-frequency: Typically set to 26000000.
-- interrupts: The interrupt line the device is connected to.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: The number of cells to describe an PMIC IRQ, must be 2.
-- #address-cells: Child device offset number of cells, must be 1.
-- #size-cells: Child device size number of cells, must be 0.
-
-Example:
-pmic@0 {
- compatible = "sprd,sc2731";
- reg = <0>;
- spi-max-frequency = <26000000>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
index 996bd4a17ca3..a750fa23d7e7 100644
--- a/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
+++ b/Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
@@ -19,7 +19,9 @@ description:
properties:
compatible:
items:
- - const: sprd,ums512-glbregs
+ - enum:
+ - sprd,ums512-glbregs
+ - sprd,ums9620-glbregs
- const: syscon
- const: simple-mfd
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
index d950dd5d48bd..4eabafb8079d 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/st,stm32-lptimer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Low-Power Timers bindings
+title: STMicroelectronics STM32 Low-Power Timers
description: |
The STM32 Low-Power Timer (LPTIM) is a 16-bit timer that provides several
@@ -21,7 +21,12 @@ maintainers:
properties:
compatible:
- const: st,stm32-lptimer
+ oneOf:
+ - items:
+ - const: st,stm32mp25-lptimer
+ - const: st,stm32-lptimer
+ - items:
+ - const: st,stm32-lptimer
reg:
maxItems: 1
@@ -44,13 +49,25 @@ properties:
wakeup-source: true
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
+
pwm:
type: object
additionalProperties: false
properties:
compatible:
- const: st,stm32-pwm-lp
+ oneOf:
+ - items:
+ - const: st,stm32mp25-pwm-lp
+ - const: st,stm32-pwm-lp
+ - items:
+ - const: st,stm32-pwm-lp
"#pwm-cells":
const: 3
@@ -65,7 +82,12 @@ properties:
properties:
compatible:
- const: st,stm32-lptimer-counter
+ oneOf:
+ - items:
+ - const: st,stm32mp25-lptimer-counter
+ - const: st,stm32-lptimer-counter
+ - items:
+ - const: st,stm32-lptimer-counter
required:
- compatible
@@ -76,7 +98,12 @@ properties:
properties:
compatible:
- const: st,stm32-lptimer-timer
+ oneOf:
+ - items:
+ - const: st,stm32mp25-lptimer-timer
+ - const: st,stm32-lptimer-timer
+ - items:
+ - const: st,stm32-lptimer-timer
required:
- compatible
@@ -88,13 +115,18 @@ patternProperties:
properties:
compatible:
- const: st,stm32-lptimer-trigger
+ oneOf:
+ - items:
+ - const: st,stm32mp25-lptimer-trigger
+ - const: st,stm32-lptimer-trigger
+ - items:
+ - const: st,stm32-lptimer-trigger
reg:
description: Identify trigger hardware block.
items:
minimum: 0
- maximum: 2
+ maximum: 4
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
index e2c3c3b44abb..66aa1550a4e5 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/st,stm32-timers.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Timers bindings
+title: STMicroelectronics STM32 Timers
description: |
This hardware block provides 3 types of timer along with PWM functionality:
@@ -21,7 +21,9 @@ maintainers:
properties:
compatible:
- const: st,stm32-timers
+ enum:
+ - st,stm32-timers
+ - st,stm32mp25-timers
reg:
maxItems: 1
@@ -36,6 +38,9 @@ properties:
resets:
maxItems: 1
+ power-domains:
+ maxItems: 1
+
dmas:
minItems: 1
maxItems: 7
@@ -67,13 +72,19 @@ properties:
"#size-cells":
const: 0
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
pwm:
type: object
additionalProperties: false
properties:
compatible:
- const: st,stm32-pwm
+ enum:
+ - st,stm32-pwm
+ - st,stm32mp25-pwm
"#pwm-cells":
const: 3
@@ -109,7 +120,9 @@ properties:
properties:
compatible:
- const: st,stm32-timer-counter
+ enum:
+ - st,stm32-timer-counter
+ - st,stm32mp25-timer-counter
required:
- compatible
@@ -124,12 +137,13 @@ patternProperties:
enum:
- st,stm32-timer-trigger
- st,stm32h7-timer-trigger
+ - st,stm32mp25-timer-trigger
reg:
description: Identify trigger hardware block.
items:
minimum: 0
- maximum: 16
+ maximum: 19
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml
index b4d54302582f..61daf36b3c80 100644
--- a/Documentation/devicetree/bindings/mfd/st,stmfx.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stmfx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/st,stmfx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectonics Multi-Function eXpander (STMFX) bindings
+title: STMicroelectonics Multi-Function eXpander (STMFX)
description: ST Multi-Function eXpander (STMFX) is a slave controller using I2C for
communication with the main MCU. Its main features are GPIO expansion,
@@ -60,7 +60,7 @@ properties:
additionalProperties: false
allOf:
- - $ref: ../pinctrl/pinmux-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
properties:
pins: true
diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
new file mode 100644
index 000000000000..b77cc3f3075d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
@@ -0,0 +1,297 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/st,stmpe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectonics Port Expander (STMPE)
+
+description: STMicroelectronics Port Expander (STMPE) is a series of slow
+ bus controllers for various expanded peripherals such as GPIO, keypad,
+ touchscreen, ADC, PWM or rotator. It can contain one or several different
+ peripherals connected to SPI or I2C.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,stmpe601
+ - st,stmpe801
+ - st,stmpe811
+ - st,stmpe1600
+ - st,stmpe1601
+ - st,stmpe2401
+ - st,stmpe2403
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vcc-supply: true
+
+ vio-supply: true
+
+ reset-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
+ st,autosleep-timeout:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 4, 16, 32, 64, 128, 256, 512, 1024 ]
+ description: Time idle before going to automatic sleep to save power
+
+ st,sample-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6 ]
+ description: |
+ Sample time per iteration
+ 0 = 36 clock ticks
+ 1 = 44 clock ticks
+ 2 = 56 clock ticks
+ 3 = 64 clock ticks
+ 4 = 80 clock ticks - recommended
+ 5 = 96 clock ticks
+ 6 = 124 clock ticks
+
+ st,mod-12b:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: ADC bit mode 0 = 10bit ADC, 1 = 12bit ADC
+
+ st,ref-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: ADC reference source 0 = internal, 1 = external
+
+ st,adc-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ ADC clock speed
+ 0 = 1.625 MHz
+ 1 = 3.25 MHz
+ 2, 3 = 6.5 MHz
+
+ adc:
+ type: object
+ $ref: /schemas/iio/adc/st,stmpe-adc.yaml#
+
+ gpio:
+ type: object
+ $ref: /schemas/gpio/st,stmpe-gpio.yaml#
+
+ keyboard-controller:
+ type: object
+ $ref: /schemas/input/matrix-keymap.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-keypad
+
+ debounce-interval:
+ description: Debouncing interval in milliseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ st,no-autorepeat:
+ description: If present, the keys will not autorepeat when pressed
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,scan-count:
+ description: Scanning cycles elapsed before key data is updated
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - compatible
+ - linux,keymap
+
+ pwm:
+ type: object
+ $ref: /schemas/pwm/pwm.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-pwm
+
+ "#pwm-cells":
+ const: 2
+
+ touchscreen:
+ type: object
+ $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: st,stmpe-ts
+
+ st,ave-ctrl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ Sample average control
+ 0 = 1 sample
+ 1 = 2 samples
+ 2 = 4 samples
+ 3 = 8 samples
+
+ st,touch-det-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: |
+ Touch detection delay
+ 0 = 10 us
+ 1 = 50 us
+ 2 = 100 us
+ 3 = 500 us - recommended
+ 4 = 1 ms
+ 5 = 5 ms
+ 6 = 10 ms
+ 7 = 50 ms
+
+ st,settling:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: |
+ Panel driver settling time
+ 0 = 10 us
+ 1 = 100 us
+ 2 = 500 us - recommended
+ 3 = 1 ms
+ 4 = 5 ms
+ 5 = 10 ms
+ 6 = 50 ms
+ 7 = 100 ms
+
+ st,fraction-z:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ description: Length of the fractional part in z, recommended is 7
+ (fraction-z ([0..7]) = Count of the fractional part)
+
+ st,i-drive:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: |
+ current limit value of the touchscreen drivers
+ 0 = 20 mA (typical 35 mA max)
+ 1 = 50 mA (typical 80 mA max)
+
+ required:
+ - compatible
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/input.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port-expander@43 {
+ compatible = "st,stmpe2401";
+ reg = <0x43>;
+ reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-parent = <&gpio>;
+ vcc-supply = <&db8500_vsmps2_reg>;
+ vio-supply = <&db8500_vsmps2_reg>;
+ wakeup-source;
+ st,autosleep-timeout = <1024>;
+
+ gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ st,norequest-mask = <0xf0f002>;
+ };
+
+ keyboard-controller {
+ compatible = "st,stmpe-keypad";
+ debounce-interval = <64>;
+ st,scan-count = <8>;
+ st,no-autorepeat;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <8>;
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x00, KEY_1)
+ MATRIX_KEY(0x00, 0x01, KEY_2)
+ MATRIX_KEY(0x00, 0x02, KEY_3)
+ MATRIX_KEY(0x00, 0x03, KEY_4)
+ MATRIX_KEY(0x00, 0x04, KEY_5)
+ MATRIX_KEY(0x00, 0x05, KEY_6)
+ MATRIX_KEY(0x00, 0x06, KEY_7)
+ MATRIX_KEY(0x00, 0x07, KEY_8)
+ MATRIX_KEY(0x00, 0x08, KEY_9)
+ MATRIX_KEY(0x00, 0x09, KEY_0)
+ >;
+ };
+
+ pwm {
+ compatible = "st,stmpe-pwm";
+ #pwm-cells = <2>;
+ };
+ };
+
+ port-expander@41 {
+ compatible = "st,stmpe811";
+ reg = <0x41>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&gpio>;
+ st,adc-freq = <1>;
+ st,mod-12b = <1>;
+ st,ref-sel = <0>;
+ st,sample-time = <4>;
+
+ adc {
+ compatible = "st,stmpe-adc";
+ st,norequest-mask = <0x0f>;
+ #io-channel-cells = <1>;
+ };
+
+ gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pwm {
+ compatible = "st,stmpe-pwm";
+ #pwm-cells = <2>;
+ };
+
+ touchscreen {
+ compatible = "st,stmpe-ts";
+ st,ave-ctrl = <3>;
+ st,touch-det-delay = <5>;
+ st,settling = <3>;
+ st,fraction-z = <7>;
+ st,i-drive = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
index 426658ad81d4..e822817188fd 100644
--- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/st,stpmic1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectonics STPMIC1 Power Management IC bindings
+title: STMicroelectonics STPMIC1 Power Management IC
description: STMicroelectronics STPMIC1 Power Management IC
@@ -29,7 +29,7 @@ properties:
onkey:
type: object
- $ref: ../input/input.yaml
+ $ref: /schemas/input/input.yaml
properties:
compatible:
@@ -67,7 +67,7 @@ properties:
watchdog:
type: object
- $ref: ../watchdog/watchdog.yaml
+ $ref: /schemas/watchdog/watchdog.yaml
properties:
compatible:
@@ -106,6 +106,7 @@ properties:
const: st,stpmic1-regulators
ldo3:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -128,6 +129,7 @@ properties:
additionalProperties: false
ldo4:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -142,11 +144,14 @@ properties:
regulator-name: true
regulator-boot-on: true
regulator-always-on: true
+ regulator-min-microvolt: true
+ regulator-max-microvolt: true
regulator-over-current-protection: true
additionalProperties: false
vref_ddr:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -165,6 +170,7 @@ properties:
additionalProperties: false
boost:
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -184,13 +190,11 @@ properties:
additionalProperties: false
patternProperties:
- "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$":
+ "^(buck[1-4]|ldo[1-6]|vref_ddr|boost|pwr_sw[1-2])-supply$":
description: STPMIC1 voltage regulators supplies
- "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
- $ref: ../regulator/regulator.yaml
-
"^ldo[1-2,5-6]$":
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -213,6 +217,7 @@ properties:
additionalProperties: false
"^buck[1-4]$":
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
@@ -237,6 +242,7 @@ properties:
additionalProperties: false
"^pwr_sw[1-2]$":
+ $ref: /schemas/regulator/regulator.yaml
type: object
properties:
diff --git a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml
index 6c8d42f27fe8..ce5e845ab5c5 100644
--- a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml
+++ b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml
@@ -126,7 +126,7 @@ properties:
patternProperties:
"^channel@[0-9a-f]+$":
type: object
- $ref: ../iio/adc/adc.yaml#
+ $ref: /schemas/iio/adc/adc.yaml#
description: Represents each of the external channels which are
connected to the ADC.
@@ -180,22 +180,22 @@ properties:
ab8500_fg:
description: Node describing the AB8500 fuel gauge control block.
type: object
- $ref: ../power/supply/stericsson,ab8500-fg.yaml
+ $ref: /schemas/power/supply/stericsson,ab8500-fg.yaml
ab8500_btemp:
description: Node describing the AB8500 battery temperature control block.
type: object
- $ref: ../power/supply/stericsson,ab8500-btemp.yaml
+ $ref: /schemas/power/supply/stericsson,ab8500-btemp.yaml
ab8500_charger:
description: Node describing the AB8500 battery charger control block.
type: object
- $ref: ../power/supply/stericsson,ab8500-charger.yaml
+ $ref: /schemas/power/supply/stericsson,ab8500-charger.yaml
ab8500_chargalg:
description: Node describing the AB8500 battery charger algorithm.
type: object
- $ref: ../power/supply/stericsson,ab8500-chargalg.yaml
+ $ref: /schemas/power/supply/stericsson,ab8500-chargalg.yaml
phy:
description: Node describing the AB8500 USB PHY control block.
@@ -313,7 +313,7 @@ properties:
- const: audioclk
stericsson,earpeice-cmv:
- description: Earpeice voltage
+ description: Earpiece voltage
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 950, 1100, 1270, 1580 ]
@@ -337,65 +337,65 @@ properties:
with power.
ab8500_ldo_aux1:
- description: The voltage for the auxilary LDO regulator 1
+ description: The voltage for the auxiliary LDO regulator 1
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux2:
- description: The voltage for the auxilary LDO regulator 2
+ description: The voltage for the auxiliary LDO regulator 2
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux3:
- description: The voltage for the auxilary LDO regulator 3
+ description: The voltage for the auxiliary LDO regulator 3
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux4:
- description: The voltage for the auxilary LDO regulator 4
+ description: The voltage for the auxiliary LDO regulator 4
only present on AB8505
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux5:
- description: The voltage for the auxilary LDO regulator 5
+ description: The voltage for the auxiliary LDO regulator 5
only present on AB8505
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_aux6:
- description: The voltage for the auxilary LDO regulator 6
+ description: The voltage for the auxiliary LDO regulator 6
only present on AB8505
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
# There is never any AUX7 regulator which is confusing
ab8500_ldo_aux8:
- description: The voltage for the auxilary LDO regulator 8
+ description: The voltage for the auxiliary LDO regulator 8
only present on AB8505
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_intcore:
description: The LDO regulator for the internal core voltage
of the AB8500
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_adc:
description: Analog power regulator for the analog to digital converter
ADC, only present on AB8505
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_tvout:
@@ -404,39 +404,39 @@ properties:
the temperature of the NTC thermistor on the battery.
Only present on AB8500.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_audio:
description: The LDO regulator for the audio codec output
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_anamic1:
description: The LDO regulator for the analog microphone 1
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_anamic2:
description: The LDO regulator for the analog microphone 2
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_dmic:
description: The LDO regulator for the digital microphone
only present on AB8500
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ldo_ana:
description: Analog power regulator for CSI and DSI interfaces,
Camera Serial Interface CSI and Display Serial Interface DSI.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
required:
@@ -444,7 +444,6 @@ properties:
additionalProperties: false
-
regulator-external:
description: Node describing the AB8500 external regulators. This
concerns the autonomous regulators VSMPS1, VSMPS2 and VSMPS3
@@ -459,19 +458,19 @@ properties:
ab8500_ext1:
description: The voltage for the VSMPS1 external regulator
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ext2:
description: The voltage for the VSMPS2 external regulator
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
ab8500_ext3:
description: The voltage for the VSMPS3 external regulator
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
required:
@@ -482,7 +481,7 @@ properties:
patternProperties:
"^pwm@[1-9]+?$":
type: object
- $ref: ../pwm/pwm.yaml#
+ $ref: /schemas/pwm/pwm.yaml#
unevaluatedProperties: false
description: Represents each of the PWM blocks in the AB8500
diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
index 1d4d88f7e82d..d6c13779d44e 100644
--- a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
+++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml
@@ -71,119 +71,139 @@ properties:
description: The voltage for the application processor, the
main voltage domain for the chip.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_varm:
- description: The voltage for the ARM Cortex A-9 CPU.
+ description: The voltage for the ARM Cortex-A9 CPU.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vmodem:
description: The voltage for the modem subsystem.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vpll:
description: The voltage for the phase locked loop clocks.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vsmps1:
description: Also known as VIO12, is a step-down voltage regulator
for 1.2V I/O. SMPS means System Management Power Source.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vsmps2:
description: Also known as VIO18, is a step-down voltage regulator
for 1.8V I/O. SMPS means System Management Power Source.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vsmps3:
description: This is a step-down voltage regulator
for 0.87 thru 1.875V I/O. SMPS means System Management Power Source.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_vrf1:
- description: RF transciever voltage regulator.
+ description: RF transceiver voltage regulator.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sva_mmdsp:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator. This is the voltage for the accelerator DSP
for video encoding and decoding.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sva_mmdsp_ret:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator for retention mode.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sva_pipe:
description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP)
voltage regulator for the data pipe.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sia_mmdsp:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator. This is the voltage for the accelerator DSP
for image encoding and decoding.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sia_mmdsp_ret:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator for retention mode.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sia_pipe:
description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP)
voltage regulator for the data pipe.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_sga:
description: Smart Graphics Accelerator (SGA) voltage regulator.
This is in effect controlling the power to the MALI400 3D
accelerator block.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_b2r2_mcde:
description: Blit Blend Rotate and Rescale (B2R2), and Multi-Channel
Display Engine (MCDE) voltage regulator. These are two graphics
blocks.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram12:
description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram12_ret:
description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator for
retention mode.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram34:
description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
db8500_esram34_ret:
description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator for
retention mode.
type: object
- $ref: ../regulator/regulator.yaml#
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
deleted file mode 100644
index d4408a417193..000000000000
--- a/Documentation/devicetree/bindings/mfd/stmpe.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* ST Microelectronics STMPE Multi-Functional Device
-
-STMPE is an MFD device which may expose the following inbuilt devices: gpio,
-keypad, touchscreen, adc, pwm, rotator.
-
-Required properties:
- - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
- - reg : I2C/SPI address of the device
-
-Optional properties:
- - interrupts : The interrupt outputs from the controller
- - interrupt-controller : Marks the device node as an interrupt controller
- - wakeup-source : Marks the input device as wakable
- - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
- - irq-gpio : If present, which GPIO to use for event IRQ
-
-Optional properties for devices with touch and ADC (STMPE811|STMPE610):
- - st,sample-time : ADC conversion time in number of clock.
- 0 -> 36 clocks 4 -> 80 clocks (recommended)
- 1 -> 44 clocks 5 -> 96 clocks
- 2 -> 56 clocks 6 -> 124 clocks
- 3 -> 64 clocks
- - st,mod-12b : ADC Bit mode
- 0 -> 10bit ADC 1 -> 12bit ADC
- - st,ref-sel : ADC reference source
- 0 -> internal 1 -> external
- - st,adc-freq : ADC Clock speed
- 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
- 1 -> 3.25 MHz
-
-Example:
-
- stmpe1601: stmpe1601@40 {
- compatible = "st,stmpe1601";
- reg = <0x40>;
- interrupts = <26 0x4>;
- interrupt-parent = <&gpio6>;
- interrupt-controller;
-
- wakeup-source;
- st,autosleep-timeout = <1024>;
- };
diff --git a/Documentation/devicetree/bindings/mfd/syscon-common.yaml b/Documentation/devicetree/bindings/mfd/syscon-common.yaml
new file mode 100644
index 000000000000..14a08e7bc8bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/syscon-common.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/syscon-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System Controller Registers R/W Common Properties
+
+description:
+ System controller node represents a register region containing a set
+ of miscellaneous registers. The registers are not cohesive enough to
+ represent as any specific type of device. The typical use-case is
+ for some other node's driver, or platform-specific code, to acquire
+ a reference to the syscon node (e.g. by phandle, node path, or
+ search using a specific compatible value), interrogate the node (or
+ associated OS driver) to determine the location of the registers,
+ and access the registers directly.
+
+maintainers:
+ - Lee Jones <lee@kernel.org>
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: syscon
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ contains:
+ const: syscon
+ minItems: 2
+ maxItems: 5 # Should be enough
+
+ reg-io-width:
+ description:
+ The size (in bytes) of the IO accesses that should be performed
+ on the device.
+ enum: [1, 2, 4, 8]
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: simple-mfd
+ then:
+ properties:
+ compatible:
+ minItems: 3
+ maxItems: 5
+
+additionalProperties: true
+
+examples:
+ - |
+ syscon: syscon@1c00000 {
+ compatible = "allwinner,sun8i-h3-system-controller", "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index 4fc483b1aee7..55efb83b1495 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/syscon.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: System Controller Registers R/W Device Tree Bindings
+title: System Controller Devices
description: |
System controller node represents a register region containing a set
@@ -19,95 +19,256 @@ description: |
maintainers:
- Lee Jones <lee@kernel.org>
+# Need a select with all compatibles listed for compatibility with older
+# dtschema (<2024.02), so this will not be selected for other schemas having
+# syscon fallback.
select:
properties:
compatible:
contains:
enum:
- - syscon
-
+ - airoha,en7581-pbus-csr
+ - al,alpine-sysfabric-service
+ - allwinner,sun8i-a83t-system-controller
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun8i-v3s-system-controller
+ - allwinner,sun50i-a64-system-controller
+ - altr,l3regs
+ - altr,sdr-ctl
+ - amd,pensando-elba-syscon
+ - amlogic,meson-mx-assist
+ - amlogic,meson-mx-bootrom
+ - amlogic,meson8-analog-top
+ - amlogic,meson8b-analog-top
+ - amlogic,meson8-pmu
+ - amlogic,meson8b-pmu
+ - apm,merlin-poweroff-mailbox
+ - apm,mustang-poweroff-mailbox
+ - apm,xgene-csw
+ - apm,xgene-efuse
+ - apm,xgene-mcb
+ - apm,xgene-rb
+ - apm,xgene-scu
+ - atmel,sama5d2-sfrbu
+ - atmel,sama5d3-nfc-io
+ - atmel,sama5d3-sfrbu
+ - atmel,sama5d4-sfrbu
+ - axis,artpec6-syscon
+ - brcm,cru-clkset
+ - brcm,sr-cdru
+ - brcm,sr-mhb
+ - cirrus,ep7209-syscon1
+ - cirrus,ep7209-syscon2
+ - cirrus,ep7209-syscon3
+ - cnxt,cx92755-uc
+ - freecom,fsg-cs2-system-controller
+ - fsl,imx93-aonmix-ns-syscfg
+ - fsl,imx93-wakeupmix-syscfg
+ - fsl,ls1088a-reset
+ - fsl,vf610-anatop
+ - fsl,vf610-mscm-cpucfg
+ - hisilicon,dsa-subctrl
+ - hisilicon,hi6220-sramctrl
+ - hisilicon,hip04-ppe
+ - hisilicon,pcie-sas-subctrl
+ - hisilicon,peri-subctrl
+ - hpe,gxp-sysreg
+ - loongson,ls1b-syscon
+ - loongson,ls1c-syscon
+ - lsi,axxia-syscon
+ - marvell,armada-3700-cpu-misc
+ - marvell,armada-3700-nb-pm
+ - marvell,armada-3700-avs
+ - marvell,armada-3700-usb2-host-device-misc
+ - marvell,armada-3700-usb2-host-misc
+ - marvell,dove-global-config
+ - mediatek,mt2701-pctl-a-syscfg
+ - mediatek,mt2712-pctl-a-syscfg
+ - mediatek,mt6397-pctl-pmic-syscfg
+ - mediatek,mt7981-topmisc
+ - mediatek,mt7988-topmisc
+ - mediatek,mt8135-pctl-a-syscfg
+ - mediatek,mt8135-pctl-b-syscfg
+ - mediatek,mt8173-pctl-a-syscfg
+ - mediatek,mt8365-syscfg
+ - microchip,lan966x-cpu-syscon
+ - microchip,mpfs-control-scb
+ - microchip,mpfs-sysreg-scb
+ - microchip,sam9x60-sfr
+ - microchip,sama7d65-ddr3phy
+ - microchip,sama7d65-sfrbu
+ - microchip,sama7g5-ddr3phy
+ - mscc,ocelot-cpu-syscon
+ - mstar,msc313-pmsleep
+ - nuvoton,ma35d1-sys
+ - nuvoton,wpcm450-shm
+ - qcom,apq8064-mmss-sfpb
+ - qcom,apq8064-sps-sic
+ - rockchip,px30-qos
+ - rockchip,rk3036-qos
+ - rockchip,rk3066-qos
+ - rockchip,rk3128-qos
+ - rockchip,rk3228-qos
+ - rockchip,rk3288-qos
+ - rockchip,rk3368-qos
+ - rockchip,rk3399-qos
+ - rockchip,rk3528-qos
+ - rockchip,rk3562-qos
+ - rockchip,rk3568-qos
+ - rockchip,rk3576-qos
+ - rockchip,rk3588-qos
+ - rockchip,rv1126-qos
+ - st,spear1340-misc
+ - stericsson,nomadik-pmu
+ - starfive,jh7100-sysmain
+ - ti,am62-opp-efuse-table
+ - ti,am62-usb-phy-ctrl
+ - ti,am625-dss-oldi-io-ctrl
+ - ti,am62p-cpsw-mac-efuse
+ - ti,am654-dss-oldi-io-ctrl
+ - ti,j784s4-acspcie-proxy-ctrl
+ - ti,j784s4-pcie-ctrl
+ - ti,keystone-pllctrl
required:
- compatible
properties:
compatible:
- anyOf:
+ oneOf:
- items:
- enum:
+ - airoha,en7581-pbus-csr
+ - al,alpine-sysfabric-service
- allwinner,sun8i-a83t-system-controller
- allwinner,sun8i-h3-system-controller
- allwinner,sun8i-v3s-system-controller
- allwinner,sun50i-a64-system-controller
+ - altr,l3regs
+ - altr,sdr-ctl
+ - amd,pensando-elba-syscon
+ - amlogic,meson-mx-assist
+ - amlogic,meson-mx-bootrom
+ - amlogic,meson8-analog-top
+ - amlogic,meson8b-analog-top
+ - amlogic,meson8-pmu
+ - amlogic,meson8b-pmu
+ - apm,merlin-poweroff-mailbox
+ - apm,mustang-poweroff-mailbox
+ - apm,xgene-csw
+ - apm,xgene-efuse
+ - apm,xgene-mcb
+ - apm,xgene-rb
+ - apm,xgene-scu
+ - atmel,sama5d2-sfrbu
+ - atmel,sama5d3-nfc-io
+ - atmel,sama5d3-sfrbu
+ - atmel,sama5d4-sfrbu
+ - axis,artpec6-syscon
- brcm,cru-clkset
+ - brcm,sr-cdru
+ - brcm,sr-mhb
+ - cirrus,ep7209-syscon1
+ - cirrus,ep7209-syscon2
+ - cirrus,ep7209-syscon3
+ - cnxt,cx92755-uc
- freecom,fsg-cs2-system-controller
- fsl,imx93-aonmix-ns-syscfg
- fsl,imx93-wakeupmix-syscfg
+ - fsl,ls1088a-reset
+ - fsl,vf610-anatop
+ - fsl,vf610-mscm-cpucfg
- hisilicon,dsa-subctrl
- hisilicon,hi6220-sramctrl
+ - hisilicon,hip04-ppe
- hisilicon,pcie-sas-subctrl
- hisilicon,peri-subctrl
- - intel,lgm-syscon
+ - hpe,gxp-sysreg
+ - loongson,ls1b-syscon
+ - loongson,ls1c-syscon
+ - lsi,axxia-syscon
+ - marvell,armada-3700-cpu-misc
+ - marvell,armada-3700-nb-pm
+ - marvell,armada-3700-avs
+ - marvell,armada-3700-usb2-host-device-misc
- marvell,armada-3700-usb2-host-misc
+ - marvell,dove-global-config
+ - mediatek,mt2701-pctl-a-syscfg
+ - mediatek,mt2712-pctl-a-syscfg
+ - mediatek,mt6397-pctl-pmic-syscfg
+ - mediatek,mt7988-topmisc
- mediatek,mt8135-pctl-a-syscfg
- mediatek,mt8135-pctl-b-syscfg
+ - mediatek,mt8173-pctl-a-syscfg
+ - mediatek,mt8365-infracfg-nao
+ - mediatek,mt8365-syscfg
- microchip,lan966x-cpu-syscon
- - microchip,sparx5-cpu-syscon
+ - microchip,mpfs-control-scb
+ - microchip,mpfs-sysreg-scb
+ - microchip,sam9x60-sfr
+ - microchip,sama7d65-ddr3phy
+ - microchip,sama7d65-sfrbu
+ - microchip,sama7g5-ddr3phy
+ - mscc,ocelot-cpu-syscon
- mstar,msc313-pmsleep
+ - nuvoton,ma35d1-sys
+ - nuvoton,wpcm450-shm
+ - qcom,apq8064-mmss-sfpb
+ - qcom,apq8064-sps-sic
- rockchip,px30-qos
- rockchip,rk3036-qos
- rockchip,rk3066-qos
+ - rockchip,rk3128-qos
- rockchip,rk3228-qos
- rockchip,rk3288-qos
- rockchip,rk3368-qos
- rockchip,rk3399-qos
+ - rockchip,rk3528-qos
+ - rockchip,rk3562-qos
- rockchip,rk3568-qos
+ - rockchip,rk3576-qos
- rockchip,rk3588-qos
- rockchip,rv1126-qos
- - samsung,exynos3-sysreg
- - samsung,exynos4-sysreg
- - samsung,exynos5-sysreg
- - samsung,exynos5433-sysreg
- - samsung,exynos850-sysreg
- - samsung,exynosautov9-sysreg
-
+ - st,spear1340-misc
+ - stericsson,nomadik-pmu
+ - starfive,jh7100-sysmain
+ - ti,am62-opp-efuse-table
+ - ti,am62-usb-phy-ctrl
+ - ti,am625-dss-oldi-io-ctrl
+ - ti,am62p-cpsw-mac-efuse
+ - ti,am654-dss-oldi-io-ctrl
+ - ti,j784s4-acspcie-proxy-ctrl
+ - ti,j784s4-pcie-ctrl
+ - ti,keystone-pllctrl
+ - const: syscon
+ - items:
+ - enum:
+ - microchip,sama7g5-sfrbu
+ - microchip,sama7d65-sfrbu
+ - const: atmel,sama5d2-sfrbu
+ - const: syscon
+ - items:
+ - const: microchip,pic64gx-control-scb
+ - const: microchip,mpfs-control-scb
+ - const: syscon
+ - items:
+ - const: microchip,pic64gx-sysreg-scb
+ - const: microchip,mpfs-sysreg-scb
- const: syscon
-
- - contains:
- const: syscon
- minItems: 2
- maxItems: 5 # Should be enough
reg:
maxItems: 1
- reg-io-width:
- description: |
- The size (in bytes) of the IO accesses that should be performed
- on the device.
- enum: [1, 2, 4, 8]
-
- hwlocks:
+ resets:
maxItems: 1
- description:
- Reference to a phandle of a hardware spinlock provider node.
required:
- compatible
- reg
allOf:
- - if:
- properties:
- compatible:
- contains:
- const: simple-mfd
- then:
- properties:
- compatible:
- minItems: 3
- maxItems: 5
+ - $ref: syscon-common.yaml#
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml b/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml
index 34bf6a01436f..70b5dfce07d2 100644
--- a/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,am3359-tscadc.yaml
@@ -52,14 +52,15 @@ properties:
type: object
description: Magnetic reader
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- - dmas
- - dma-names
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml b/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml
new file mode 100644
index 000000000000..ba14663c9266
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,bq25703a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BQ25703A Charger Manager/Buck/Boost Converter
+
+maintainers:
+ - Chris Morgan <macromorgan@hotmail.com>
+
+allOf:
+ - $ref: /schemas/power/supply/power-supply.yaml#
+
+properties:
+ compatible:
+ const: ti,bq25703a
+
+ reg:
+ const: 0x6b
+
+ input-current-limit-microamp:
+ description:
+ Maximum total input current allowed used for both charging and
+ powering the device.
+ minimum: 50000
+ maximum: 6400000
+ default: 3250000
+
+ interrupts:
+ maxItems: 1
+
+ monitored-battery:
+ description:
+ A minimum of constant-charge-current-max-microamp,
+ constant-charge-voltage-max-microvolt, and
+ voltage-min-design-microvolt are required.
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description:
+ Boost converter regulator output of bq257xx.
+
+ properties:
+ vbus:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml
+ additionalProperties: false
+
+ properties:
+ regulator-name: true
+ regulator-min-microamp:
+ minimum: 0
+ maximum: 6350000
+ regulator-max-microamp:
+ minimum: 0
+ maximum: 6350000
+ regulator-min-microvolt:
+ minimum: 4480000
+ maximum: 20800000
+ regulator-max-microvolt:
+ minimum: 4480000
+ maximum: 20800000
+ enable-gpios:
+ description:
+ The BQ25703 may require both a register write and a GPIO
+ toggle to enable the boost regulator.
+
+ required:
+ - regulator-name
+ - regulator-min-microamp
+ - regulator-max-microamp
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - input-current-limit-microamp
+ - monitored-battery
+ - power-supplies
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bq25703: charger@6b {
+ compatible = "ti,bq25703a";
+ reg = <0x6b>;
+ input-current-limit-microamp = <5000000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD5 IRQ_TYPE_LEVEL_LOW>;
+ monitored-battery = <&battery>;
+ power-supplies = <&fusb302>;
+
+ regulators {
+ usb_otg_vbus: vbus {
+ enable-gpios = <&gpio4 RK_PA6 GPIO_ACTIVE_HIGH>;
+ regulator-max-microamp = <960000>;
+ regulator-max-microvolt = <5088000>;
+ regulator-min-microamp = <512000>;
+ regulator-min-microvolt = <4992000>;
+ regulator-name = "usb_otg_vbus";
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
deleted file mode 100644
index 73cffc45e056..000000000000
--- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
+++ /dev/null
@@ -1,95 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mfd/ti,j721e-system-controller.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: TI J721e System Controller Registers R/W Device Tree Bindings
-
-description: |
- This represents the Control Module registers (CTRL_MMR0) on the SoC.
- System controller node represents a register region containing a set
- of miscellaneous registers. The registers are not cohesive enough to
- represent as any specific type of device. The typical use-case is
- for some other node's driver, or platform-specific code, to acquire
- a reference to the syscon node (e.g. by phandle, node path, or
- search using a specific compatible value), interrogate the node (or
- associated OS driver) to determine the location of the registers,
- and access the registers directly.
-
-maintainers:
- - Kishon Vijay Abraham I <kishon@ti.com>
- - Roger Quadros <rogerq@kernel.org>
-
-properties:
- compatible:
- items:
- - enum:
- - ti,j721e-system-controller
- - const: syscon
- - const: simple-mfd
-
- reg:
- maxItems: 1
-
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
- ranges: true
-
-patternProperties:
- # Optional children
- "^mux-controller@[0-9a-f]+$":
- type: object
- description:
- This is the SERDES lane control mux.
-
- "^clock-controller@[0-9a-f]+$":
- type: object
- $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
- description:
- Clock provider for TI EHRPWM nodes.
-
-required:
- - compatible
- - reg
- - "#address-cells"
- - "#size-cells"
- - ranges
-
-additionalProperties: false
-
-examples:
- - |
- scm_conf: scm-conf@100000 {
- compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
- reg = <0x00100000 0x1c000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- serdes_ln_ctrl: mux-controller@4080 {
- compatible = "mmio-mux";
- reg = <0x00004080 0x50>;
-
- #mux-control-cells = <1>;
- mux-reg-masks =
- <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
- <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
- <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
- <0x40b0 0x3>, <0x40b4 0x3>, /* SERDES3 lane0/1 select */
- <0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>;
- /* SERDES4 lane0/1/2/3 select */
- };
-
- clock-controller@4140 {
- compatible = "ti,am654-ehrpwm-tbclk", "syscon";
- reg = <0x4140 0x18>;
- #clock-cells = <1>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/mfd/ti,lp8732.yaml b/Documentation/devicetree/bindings/mfd/ti,lp8732.yaml
new file mode 100644
index 000000000000..9a90cee2b545
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,lp8732.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,lp8732.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LP873X Power Management Integrated Circuit
+
+maintainers:
+ - J Keerthy <j-keerthy@ti.com>
+
+description:
+ PMIC with two high-current buck converters and two linear regulators.
+
+properties:
+ compatible:
+ enum:
+ - ti,lp8732
+ - ti,lp8733
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ regulators:
+ description:
+ List of child nodes that specify the regulator initialization data.
+ type: object
+ patternProperties:
+ "^buck[01]|ldo[01]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ additionalProperties: false
+
+patternProperties:
+ '^(buck[01]|ldo[01])-in-supply$':
+ description: Phandle to parent supply of each regulator populated under regulators node.
+
+required:
+ - compatible
+ - reg
+ - regulators
+ - buck0-in-supply
+ - buck1-in-supply
+ - ldo0-in-supply
+ - ldo1-in-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic: pmic@60 {
+ compatible = "ti,lp8733";
+ reg = <0x60>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
+ regulators {
+ buck0: buck0 {
+ regulator-name = "buck0";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-min-microamp = <1500000>;
+ regulator-max-microamp = <4000000>;
+ regulator-ramp-delay = <10000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck1: buck1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-min-microamp = <1500000>;
+ regulator-max-microamp = <4000000>;
+ regulator-ramp-delay = <10000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo0: ldo0 {
+ regulator-name = "ldo0";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/ti,lp87524-q1.yaml b/Documentation/devicetree/bindings/mfd/ti,lp87524-q1.yaml
index f6cac4b1079c..ca72786b0e0d 100644
--- a/Documentation/devicetree/bindings/mfd/ti,lp87524-q1.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,lp87524-q1.yaml
@@ -26,7 +26,7 @@ properties:
'#gpio-cells':
description:
The first cell is the pin number.
- The second cell is is used to specify flags.
+ The second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
const: 2
@@ -37,6 +37,7 @@ properties:
"^buck[0123]$":
type: object
$ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- buck0
diff --git a/Documentation/devicetree/bindings/mfd/ti,lp87561-q1.yaml b/Documentation/devicetree/bindings/mfd/ti,lp87561-q1.yaml
index dc5a29b5ef7d..885e33276b1b 100644
--- a/Documentation/devicetree/bindings/mfd/ti,lp87561-q1.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,lp87561-q1.yaml
@@ -26,7 +26,7 @@ properties:
'#gpio-cells':
description:
The first cell is the pin number.
- The second cell is is used to specify flags.
+ The second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
const: 2
@@ -41,6 +41,7 @@ properties:
buck3210:
type: object
$ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- buck3210
diff --git a/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml b/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml
index 012d25111054..2b5b54aa6c73 100644
--- a/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml
@@ -28,7 +28,7 @@ properties:
'#gpio-cells':
description:
The first cell is the pin number.
- The second cell is is used to specify flags.
+ The second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
const: 2
@@ -47,6 +47,7 @@ properties:
"^buck(10|23)$":
type: object
$ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- buck10
diff --git a/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml
new file mode 100644
index 000000000000..28cd5164d46f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,nspire-misc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Nspire MISC hardware block
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+
+description:
+ System controller node represents a register region containing a set
+ of miscellaneous registers. The registers are not cohesive enough to
+ represent as any specific type of device. Currently there is a reset
+ controller.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ti,nspire-misc
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ reboot:
+ $ref: /schemas/power/reset/syscon-reboot.yaml#
+
+required:
+ - compatible
+ - reg
+ - reboot
+
+additionalProperties: false
+
+examples:
+ - |
+ misc: misc@900a0000 {
+ compatible = "ti,nspire-misc", "syscon", "simple-mfd";
+ reg = <0x900a0000 0x1000>;
+
+ reboot {
+ compatible = "syscon-reboot";
+ offset = <0x08>;
+ value = <0x02>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml b/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml
index 3fdd9cb5b347..a8eed9065d96 100644
--- a/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml
@@ -49,7 +49,7 @@ properties:
patternProperties:
"^buck[1-6]$":
type: object
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
properties:
regulator-name: true
@@ -72,7 +72,7 @@ properties:
"^(ldoa[1-3]|swa1|swb[1-2]|vtt)$":
type: object
- $ref: ../regulator/regulator.yaml
+ $ref: /schemas/regulator/regulator.yaml
properties:
regulator-name: true
@@ -95,7 +95,7 @@ required:
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml b/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml
new file mode 100644
index 000000000000..f1a76f88fc0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,tps65910.yaml
@@ -0,0 +1,315 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,tps65910.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS65910 Power Management Integrated Circuit
+
+maintainers:
+ - Shree Ramamoorthy <s-ramamoorthy@ti.com>
+
+description:
+ TPS65910 device is a Power Management IC that provides 3 step-down converters,
+ 1 stepup converter, and 8 LDOs. The device contains an embedded power controller (EPC),
+ 1 GPIO, and an RTC.
+
+properties:
+ compatible:
+ enum:
+ - ti,tps65910
+ - ti,tps65911
+
+ reg:
+ description: I2C slave address
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+ description: |
+ The first cell is the GPIO number.
+ The second cell is used to specify additional options <unused>.
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ description: Specifies the IRQ number and flags
+ const: 2
+
+ ti,vmbch-threshold:
+ description: |
+ (TPS65911) Main battery charged threshold comparator.
+ See VMBCH_VSEL in TPS65910 datasheet.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ ti,vmbch2-threshold:
+ description: |
+ (TPS65911) Main battery discharged threshold comparator.
+ See VMBCH_VSEL in TPS65910 datasheet.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ ti,en-ck32k-xtal:
+ type: boolean
+ description: Enable external 32-kHz crystal oscillator.
+
+ ti,en-gpio-sleep:
+ description: |
+ Enable sleep control for gpios.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 9
+ maxItems: 9
+ items:
+ minimum: 0
+ maximum: 1
+
+ ti,system-power-controller:
+ type: boolean
+ description: Identify whether or not this pmic controls the system power
+
+ ti,sleep-enable:
+ type: boolean
+ description: Enable SLEEP state.
+
+ ti,sleep-keep-therm:
+ type: boolean
+ description: Keep thermal monitoring on in sleep state.
+
+ ti,sleep-keep-ck32k:
+ type: boolean
+ description: Keep the 32KHz clock output on in sleep state.
+
+ ti,sleep-keep-hsclk:
+ type: boolean
+ description: Keep high speed internal clock on in sleep state.
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description: List of regulators provided by this controller.
+
+ patternProperties:
+ "^(vrtc|vio|vpll|vdac|vmmc|vbb|vddctrl)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ properties:
+ ti,regulator-ext-sleep-control:
+ description: |
+ Enable external sleep control through external inputs:
+ [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)].
+ If this property is not defined, it defaults to 0 (not enabled).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 4, 8]
+ unevaluatedProperties: false
+
+ "^(vdd[1-3]|vaux([1-2]|33)|vdig[1-2])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ properties:
+ ti,regulator-ext-sleep-control:
+ description: |
+ Enable external sleep control through external inputs:
+ [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)].
+ If this property is not defined, it defaults to 0 (not enabled).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 4, 8]
+ unevaluatedProperties: false
+
+ "^ldo[1-8]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ properties:
+ ti,regulator-ext-sleep-control:
+ description: |
+ Enable external sleep control through external inputs:
+ [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)].
+ If this property is not defined, it defaults to 0 (not enabled).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 4, 8]
+ unevaluatedProperties: false
+
+patternProperties:
+ "^(vcc(io|[1-7])-supply)$":
+ description: |
+ Input voltage supply phandle for regulators.
+ These entries are required if PMIC regulators are enabled, or else it
+ can cause the regulator registration to fail.
+
+ If some input supply is powered through battery or always-on supply, then
+ it is also required to have these parameters with the proper node handle for always-on
+ power supply.
+ tps65910:
+ vcc1-supply: VDD1 input.
+ vcc2-supply: VDD2 input.
+ vcc3-supply: VAUX33 and VMMC input.
+ vcc4-supply: VAUX1 and VAUX2 input.
+ vcc5-supply: VPLL and VDAC input.
+ vcc6-supply: VDIG1 and VDIG2 input.
+ vcc7-supply: VRTC and VBB input.
+ vccio-supply: VIO input.
+ tps65911:
+ vcc1-supply: VDD1 input.
+ vcc2-supply: VDD2 input.
+ vcc3-supply: LDO6, LDO7 and LDO8 input.
+ vcc4-supply: LDO5 input.
+ vcc5-supply: LDO3 and LDO4 input.
+ vcc6-supply: LDO1 and LDO2 input.
+ vcc7-supply: VRTC input.
+ vccio-supply: VIO input.
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - regulators
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tps65910
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^(ldo[1-8]|vddctrl)$": false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tps65911
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^(vdd3|vaux([1-2]|33)|vdig[1-2])$": false
+ "^(vpll|vdac|vmmc|vbb)$": false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic: tps65910@2d {
+ compatible = "ti,tps65910";
+ reg = <0x2d>;
+ interrupt-parent = <&intc>;
+ interrupts = < 0 118 0x04 >;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ ti,system-power-controller;
+
+ ti,vmbch-threshold = <0>;
+ ti,vmbch2-threshold = <0>;
+ ti,en-ck32k-xtal;
+ ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
+
+ vcc1-supply = <&reg_parent>;
+ vcc2-supply = <&some_reg>;
+ vcc3-supply = <&vbat>;
+ vcc4-supply = <&vbat>;
+ vcc5-supply = <&vbat>;
+ vcc6-supply = <&vbat>;
+ vcc7-supply = <&vbat>;
+ vccio-supply = <&vbat>;
+
+ regulators {
+ vio_reg: vio {
+ regulator-name = "vio";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ vdd1_reg: vdd1 {
+ regulator-name = "vdd1";
+ regulator-min-microvolt = < 600000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,regulator-ext-sleep-control = <0>;
+ };
+ vdd2_reg: vdd2 {
+ regulator-name = "vdd2";
+ regulator-min-microvolt = < 600000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ vdd3_reg: vdd3 {
+ regulator-name = "vdd3";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+ vdig1_reg: vdig1 {
+ regulator-name = "vdig1";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <2700000>;
+ regulator-always-on;
+ };
+ vdig2_reg: vdig2 {
+ regulator-name = "vdig2";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ vpll_reg: vpll {
+ regulator-name = "vpll";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+ vdac_reg: vdac {
+ regulator-name = "vdac";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2850000>;
+ regulator-always-on;
+ };
+ vaux1_reg: vaux1 {
+ regulator-name = "vaux1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2850000>;
+ regulator-always-on;
+ };
+ vaux2_reg: vaux2 {
+ regulator-name = "vaux2";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ vaux33_reg: vaux33 {
+ regulator-name = "vaux33";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ vmmc_reg: vmmc {
+ regulator-name = "vmmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
new file mode 100644
index 000000000000..ca17fbdea691
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,tps6594.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS6594 Power Management Integrated Circuit
+
+maintainers:
+ - Julien Panis <jpanis@baylibre.com>
+
+description:
+ TPS6594 is a Power Management IC which provides regulators and others
+ features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
+ PFSM (Pre-configurable Finite State Machine) managing the state of the device.
+ TPS6594 is the super-set device while TPS6593 and LP8764 are derivatives.
+
+properties:
+ compatible:
+ enum:
+ - ti,lp8764-q1
+ - ti,tps6593-q1
+ - ti,tps6594-q1
+ - ti,tps65224-q1
+ - ti,tps652g1
+
+ reg:
+ description: I2C slave address or SPI chip select number.
+ maxItems: 1
+
+ ti,primary-pmic:
+ type: boolean
+ description: |
+ Identify the primary PMIC on SPMI bus.
+ A multi-PMIC synchronization scheme is implemented in the PMIC device
+ to synchronize the power state changes with other PMIC devices. This is
+ accomplished through a SPMI bus: the primary PMIC is the controller
+ device on the SPMI bus, and the secondary PMICs are the target devices
+ on the SPMI bus.
+
+ system-power-controller: true
+
+ gpio-controller: true
+ gpio-line-names: true
+
+ '#gpio-cells':
+ const: 2
+ description: |
+ The first cell is the pin number, the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: List of regulators provided by this controller.
+
+ patternProperties:
+ "^buck([1-5]|12|34|123|1234)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+
+ unevaluatedProperties: false
+
+ "^ldo[1-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+
+ unevaluatedProperties: false
+
+ allOf:
+ - if:
+ required:
+ - buck12
+ then:
+ properties:
+ buck123: false
+ buck1234: false
+ - if:
+ required:
+ - buck123
+ then:
+ properties:
+ buck34: false
+ - if:
+ required:
+ - buck1234
+ then:
+ properties:
+ buck34: false
+
+ additionalProperties: false
+
+patternProperties:
+ "^buck([1-5]|12|34|123|1234)-supply$":
+ description: Input supply phandle for each buck.
+
+ "^ldo[1-4]-supply$":
+ description: Input supply phandle for each ldo.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tps6593: pmic@48 {
+ compatible = "ti,tps6593-q1";
+ reg = <0x48>;
+ ti,primary-pmic;
+ system-power-controller;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&mcu_gpio0>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+
+ buck123-supply = <&vcc_3v3_sys>;
+ buck4-supply = <&vcc_3v3_sys>;
+ buck5-supply = <&vcc_3v3_sys>;
+ ldo1-supply = <&vcc_3v3_sys>;
+ ldo2-supply = <&vcc_3v3_sys>;
+ ldo3-supply = <&buck5>;
+ ldo4-supply = <&vcc_3v3_sys>;
+
+ regulators {
+ buck123: buck123 {
+ regulator-name = "vcc_core";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck4: buck4 {
+ regulator-name = "vcc_1v1";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: buck5 {
+ regulator-name = "vcc_1v8_sys";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: ldo1 {
+ regulator-name = "vddshv5_sdio";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2: ldo2 {
+ regulator-name = "vpp_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3: ldo3 {
+ regulator-name = "vcc_0v85";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: ldo4 {
+ regulator-name = "vdda_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
new file mode 100644
index 000000000000..9cc3e4721612
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
@@ -0,0 +1,585 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,twl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL family
+
+maintainers:
+ - Andreas Kemnade <andreas@kemnade.info>
+
+description: |
+ The TWLs are Integrated Power Management Chips.
+ Some versions might contain much more analog functions like
+ USB transceiver or Audio amplifier.
+ These chips are connected to an I2C bus.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl4030
+ then:
+ patternProperties:
+ "^regulator-":
+ properties:
+ compatible:
+ enum:
+ - ti,twl4030-vaux1
+ - ti,twl4030-vaux2
+ - ti,twl4030-vaux3
+ - ti,twl4030-vaux4
+ - ti,twl4030-vmmc1
+ - ti,twl4030-vmmc2
+ - ti,twl4030-vpll1
+ - ti,twl4030-vpll2
+ - ti,twl4030-vsim
+ - ti,twl4030-vdac
+ - ti,twl4030-vintana2
+ - ti,twl4030-vio
+ - ti,twl4030-vdd1
+ - ti,twl4030-vdd2
+ - ti,twl4030-vintana1
+ - ti,twl4030-vintdig
+ - ti,twl4030-vusb1v5
+ - ti,twl4030-vusb1v8
+ - ti,twl4030-vusb3v1
+ ti,retain-on-reset: false
+
+ properties:
+ charger:
+ $ref: /schemas/power/supply/twl4030-charger.yaml
+ unevaluatedProperties: false
+
+ gpadc: false
+
+ pwrbutton:
+ properties:
+ compatible:
+ const: ti,twl4030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 8
+
+ usb-comparator: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6030
+ then:
+ patternProperties:
+ "^regulator-":
+ properties:
+ compatible:
+ enum:
+ - ti,twl6030-vaux1
+ - ti,twl6030-vaux2
+ - ti,twl6030-vaux3
+ - ti,twl6030-vmmc
+ - ti,twl6030-vpp
+ - ti,twl6030-vusim
+ - ti,twl6030-vana
+ - ti,twl6030-vcxio
+ - ti,twl6030-vdac
+ - ti,twl6030-vusb
+ - ti,twl6030-v1v8
+ - ti,twl6030-v2v1
+ - ti,twl6030-vdd1
+ - ti,twl6030-vdd2
+ - ti,twl6030-vdd3
+ regulator-initial-mode: false
+
+ properties:
+ charger:
+ $ref: /schemas/power/supply/ti,twl6030-charger.yaml
+ unevaluatedProperties: false
+
+ gpadc:
+ properties:
+ compatible:
+ const: ti,twl6030-gpadc
+
+ pwrbutton:
+ properties:
+ compatible:
+ const: ti,twl6030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 0
+
+ madc: false
+
+ watchdog: false
+
+ audio: false
+
+ keypad: false
+
+ twl4030-usb: false
+
+ gpio: false
+
+ power: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,twl6032
+ then:
+ patternProperties:
+ "^regulator-":
+ properties:
+ compatible:
+ enum:
+ - ti,twl6032-ldo1
+ - ti,twl6032-ldo2
+ - ti,twl6032-ldo3
+ - ti,twl6032-ldo4
+ - ti,twl6032-ldo5
+ - ti,twl6032-ldo6
+ - ti,twl6032-ldo7
+ - ti,twl6032-ldoln
+ - ti,twl6032-ldousb
+ - ti,twl6032-smps3
+ - ti,twl6032-smps4
+ - ti,twl6032-vio
+ regulator-initial-mode: false
+
+ properties:
+ charger:
+ $ref: /schemas/power/supply/ti,twl6030-charger.yaml
+ unevaluatedProperties: false
+
+ gpadc:
+ properties:
+ compatible:
+ const: ti,twl6032-gpadc
+
+ pwrbutton:
+ properties:
+ compatible:
+ const: ti,twl6030-pwrbutton
+ interrupts:
+ items:
+ - items:
+ const: 0
+
+ madc: false
+
+ watchdog: false
+
+ audio: false
+
+ keypad: false
+
+ twl4030-usb: false
+
+ gpio: false
+
+ power: false
+
+properties:
+ compatible:
+ description: >
+ TWL4030 for integrated power-management/audio CODEC device used in
+ OMAP3 based boards.
+
+ TWL6030/32 for integrated power-management used in OMAP4 based boards
+ enum:
+ - ti,twl4030
+ - ti,twl6030
+ - ti,twl6032
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ system-power-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: fck
+
+ charger:
+ type: object
+
+ properties:
+ compatible: true
+
+ required:
+ - compatible
+
+ rtc:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: ti,twl4030-rtc
+ interrupts:
+ maxItems: 1
+
+ madc:
+ type: object
+ $ref: /schemas/iio/adc/ti,twl4030-madc.yaml
+ unevaluatedProperties: false
+
+ pwrbutton:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - ti,twl4030-pwrbutton
+ - ti,twl6030-pwrbutton
+ interrupts:
+ maxItems: 1
+
+ watchdog:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: ti,twl4030-wdt
+
+ audio:
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: ti,twl4030-audio
+
+ required:
+ - compatible
+
+ keypad:
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: ti,twl4030-keypad
+
+ required:
+ - compatible
+
+ twl4030-usb:
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: ti,twl4030-usb
+
+ required:
+ - compatible
+
+ gpio:
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: ti,twl4030-gpio
+
+ required:
+ - compatible
+
+ power:
+ type: object
+ additionalProperties: false
+ description: >
+ The power management module inside the TWL4030 provides several
+ facilities to control the power resources, including power scripts.
+
+ For now, the binding only supports the complete shutdown of the
+ system after poweroff.
+
+ Board-specific compatible strings may be used for platform-specific
+ power configurations.
+
+ A board-specific compatible string (e.g., ti,twl4030-power-omap3-evm)
+ may be paired with a generic fallback (generally for power saving mode).
+
+ properties:
+ compatible:
+ oneOf:
+ # Case 1: A single compatible string is provided.
+ - enum:
+ - ti,twl4030-power
+ - ti,twl4030-power-reset
+ - ti,twl4030-power-idle
+ - ti,twl4030-power-idle-osc-off
+ - ti,twl4030-power-omap3-sdp
+ - ti,twl4030-power-omap3-ldp
+ - ti,twl4030-power-omap3-evm
+
+ # Case 2: The specific, valid fallback for 'idle-osc-off'.
+ - items:
+ - const: ti,twl4030-power-idle-osc-off
+ - const: ti,twl4030-power-idle
+
+ # Case 3: The specific, valid fallback for 'omap3-evm'.
+ - items:
+ - const: ti,twl4030-power-omap3-evm
+ - const: ti,twl4030-power-idle
+
+ ti,system-power-controller:
+ type: boolean
+ deprecated: true
+ description: >
+ DEPRECATED. The standard 'system-power-controller'
+ property on the parent node should be used instead.
+
+ ti,use_poweroff:
+ type: boolean
+ deprecated: true
+ description: DEPRECATED, to be removed.
+
+ required:
+ - compatible
+
+ gpadc:
+ type: object
+ $ref: /schemas/iio/adc/ti,twl6030-gpadc.yaml
+ unevaluatedProperties: false
+
+ properties:
+ compatible: true
+
+ usb-comparator:
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: ti,twl6030-usb
+
+ required:
+ - compatible
+
+ pwm:
+ type: object
+ $ref: /schemas/pwm/pwm.yaml#
+ unevaluatedProperties: false
+ description:
+ PWM controllers (PWM1 and PWM2 on TWL4030, PWM0 and PWM1 on TWL6030/32).
+
+ properties:
+ compatible:
+ enum:
+ - ti,twl4030-pwm
+ - ti,twl6030-pwm
+
+ '#pwm-cells':
+ const: 2
+
+ required:
+ - compatible
+ - '#pwm-cells'
+
+ pwmled:
+ type: object
+ $ref: /schemas/pwm/pwm.yaml#
+ unevaluatedProperties: false
+ description: >
+ PWM controllers connected to LED terminals (PWMA and PWMB on TWL4030.
+
+ LED PWM on TWL6030/32, mainly used as charging indicator LED).
+
+ properties:
+ compatible:
+ enum:
+ - ti,twl4030-pwmled
+ - ti,twl6030-pwmled
+
+ '#pwm-cells':
+ const: 2
+
+ required:
+ - compatible
+ - '#pwm-cells'
+
+patternProperties:
+ '^regulator-':
+ type: object
+ unevaluatedProperties: false
+ $ref: /schemas/regulator/regulator.yaml
+
+ properties:
+ compatible: true
+ regulator-initial-mode:
+ enum:
+ - 0x08 # Sleep mode, the nominal output voltage is maintained
+ # with low power consumption with low load current capability
+ - 0x0e # Active mode, the regulator can deliver its nominal output
+ # voltage with full-load current capability
+
+ ti,retain-on-reset:
+ description: >
+ Does not turn off the supplies during warm reset.
+
+ Could be needed for VMMC, as TWL6030 reset sequence for
+ this signal does not comply with the SD specification.
+ type: boolean
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ charger {
+ compatible = "ti,twl6030-charger";
+ interrupts = <2>, <5>;
+ io-channels = <&gpadc 10>;
+ io-channel-names = "vusb";
+ monitored-battery = <&bat>;
+ };
+
+ gpadc {
+ compatible = "ti,twl6030-gpadc";
+ interrupts = <6>;
+ #io-channel-cells = <1>;
+ };
+
+ pwrbutton {
+ compatible = "ti,twl6030-pwrbutton";
+ interrupts = <0>;
+ };
+
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <8>;
+ };
+
+ regulator-vaux1 {
+ compatible = "ti,twl6030-vaux1";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ regulator-vmmc1 {
+ compatible = "ti,twl6030-vmmc";
+ ti,retain-on-reset;
+ };
+
+ pwm {
+ compatible = "ti,twl6030-pwm";
+ #pwm-cells = <2>;
+ };
+
+ pwmled {
+ compatible = "ti,twl6030-pwmled";
+ #pwm-cells = <2>;
+ };
+ };
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@48 {
+ compatible = "ti,twl4030";
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ charger {
+ compatible = "ti,twl4030-bci";
+ interrupts = <9>, <2>;
+ bci3v1-supply = <&vusb3v1>;
+ io-channels = <&twl_madc 11>;
+ io-channel-names = "vac";
+ };
+
+ twl_madc: madc {
+ compatible = "ti,twl4030-madc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
+
+ pwrbutton {
+ compatible = "ti,twl4030-pwrbutton";
+ interrupts = <8>;
+ };
+
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+
+ regulator-vaux1 {
+ compatible = "ti,twl4030-vaux1";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <0xe>;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = "ti,twl4030-vusb3v1";
+ };
+
+ watchdog {
+ compatible = "ti,twl4030-wdt";
+ };
+
+ power {
+ compatible = "ti,twl4030-power";
+ };
+
+ pwm {
+ compatible = "ti,twl4030-pwm";
+ #pwm-cells = <2>;
+ };
+
+ pwmled {
+ compatible = "ti,twl4030-pwmled";
+ #pwm-cells = <2>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt
deleted file mode 100644
index a5ced46bbde9..000000000000
--- a/Documentation/devicetree/bindings/mfd/tps65910.txt
+++ /dev/null
@@ -1,205 +0,0 @@
-TPS65910 Power Management Integrated Circuit
-
-Required properties:
-- compatible: "ti,tps65910" or "ti,tps65911"
-- reg: I2C slave address
-- interrupts: the interrupt outputs of the controller
-- #gpio-cells: number of cells to describe a GPIO, this should be 2.
- The first cell is the GPIO number.
- The second cell is used to specify additional options <unused>.
-- gpio-controller: mark the device as a GPIO controller
-- #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
- The first cell is the IRQ number.
- The second cell is the flags, encoded as the trigger masks from
- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-- regulators: This is the list of child nodes that specify the regulator
- initialization data for defined regulators. Not all regulators for the given
- device need to be present. The definition for each of these nodes is defined
- using the standard binding for regulators found at
- Documentation/devicetree/bindings/regulator/regulator.txt.
- The regulator is matched with the regulator-compatible.
-
- The valid regulator-compatible values are:
- tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1,
- vaux2, vaux33, vmmc, vbb
- tps65911: vrtc, vio, vdd1, vdd2, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
- ldo6, ldo7, ldo8
-
-- xxx-supply: Input voltage supply regulator.
- These entries are required if regulators are enabled for a device. Missing these
- properties can cause the regulator registration to fail.
- If some of input supply is powered through battery or always-on supply then
- also it is require to have these parameters with proper node handle of always
- on power supply.
- tps65910:
- vcc1-supply: VDD1 input.
- vcc2-supply: VDD2 input.
- vcc3-supply: VAUX33 and VMMC input.
- vcc4-supply: VAUX1 and VAUX2 input.
- vcc5-supply: VPLL and VDAC input.
- vcc6-supply: VDIG1 and VDIG2 input.
- vcc7-supply: VRTC and VBB input.
- vccio-supply: VIO input.
- tps65911:
- vcc1-supply: VDD1 input.
- vcc2-supply: VDD2 input.
- vcc3-supply: LDO6, LDO7 and LDO8 input.
- vcc4-supply: LDO5 input.
- vcc5-supply: LDO3 and LDO4 input.
- vcc6-supply: LDO1 and LDO2 input.
- vcc7-supply: VRTC input.
- vccio-supply: VIO input.
-
-Optional properties:
-- ti,vmbch-threshold: (tps65911) main battery charged threshold
- comparator. (see VMBCH_VSEL in TPS65910 datasheet)
-- ti,vmbch2-threshold: (tps65911) main battery discharged threshold
- comparator. (see VMBCH_VSEL in TPS65910 datasheet)
-- ti,en-ck32k-xtal: enable external 32-kHz crystal oscillator (see CK32K_CTRL
- in TPS6591X datasheet)
-- ti,en-gpio-sleep: enable sleep control for gpios
- There should be 9 entries here, one for each gpio.
-- ti,system-power-controller: Telling whether or not this pmic is controlling
- the system power.
-- ti,sleep-enable: Enable SLEEP state.
-- ti,sleep-keep-therm: Keep thermal monitoring on in sleep state.
-- ti,sleep-keep-ck32k: Keep the 32KHz clock output on in sleep state.
-- ti,sleep-keep-hsclk: Keep high speed internal clock on in sleep state.
-
-Regulator Optional properties:
-- ti,regulator-ext-sleep-control: enable external sleep
- control through external inputs [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)]
- If this property is not defined, it defaults to 0 (not enabled).
-
-Example:
-
- pmu: tps65910@d2 {
- compatible = "ti,tps65910";
- reg = <0xd2>;
- interrupt-parent = <&intc>;
- interrupts = < 0 118 0x04 >;
-
- #gpio-cells = <2>;
- gpio-controller;
-
- #interrupt-cells = <2>;
- interrupt-controller;
-
- ti,system-power-controller;
-
- ti,vmbch-threshold = 0;
- ti,vmbch2-threshold = 0;
- ti,en-ck32k-xtal;
- ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
-
- vcc1-supply = <&reg_parent>;
- vcc2-supply = <&some_reg>;
- vcc3-supply = <...>;
- vcc4-supply = <...>;
- vcc5-supply = <...>;
- vcc6-supply = <...>;
- vcc7-supply = <...>;
- vccio-supply = <...>;
-
- regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
- vdd1_reg: regulator@0 {
- regulator-compatible = "vdd1";
- reg = <0>;
- regulator-min-microvolt = < 600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-boot-on;
- ti,regulator-ext-sleep-control = <0>;
- };
- vdd2_reg: regulator@1 {
- regulator-compatible = "vdd2";
- reg = <1>;
- regulator-min-microvolt = < 600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-boot-on;
- ti,regulator-ext-sleep-control = <4>;
- };
- vddctrl_reg: regulator@2 {
- regulator-compatible = "vddctrl";
- reg = <2>;
- regulator-min-microvolt = < 600000>;
- regulator-max-microvolt = <1400000>;
- regulator-always-on;
- regulator-boot-on;
- ti,regulator-ext-sleep-control = <0>;
- };
- vio_reg: regulator@3 {
- regulator-compatible = "vio";
- reg = <3>;
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- ti,regulator-ext-sleep-control = <1>;
- };
- ldo1_reg: regulator@4 {
- regulator-compatible = "ldo1";
- reg = <4>;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3300000>;
- ti,regulator-ext-sleep-control = <0>;
- };
- ldo2_reg: regulator@5 {
- regulator-compatible = "ldo2";
- reg = <5>;
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- ti,regulator-ext-sleep-control = <0>;
- };
- ldo3_reg: regulator@6 {
- regulator-compatible = "ldo3";
- reg = <6>;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3300000>;
- ti,regulator-ext-sleep-control = <0>;
- };
- ldo4_reg: regulator@7 {
- regulator-compatible = "ldo4";
- reg = <7>;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- ti,regulator-ext-sleep-control = <0>;
- };
- ldo5_reg: regulator@8 {
- regulator-compatible = "ldo5";
- reg = <8>;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3300000>;
- ti,regulator-ext-sleep-control = <0>;
- };
- ldo6_reg: regulator@9 {
- regulator-compatible = "ldo6";
- reg = <9>;
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- ti,regulator-ext-sleep-control = <0>;
- };
- ldo7_reg: regulator@10 {
- regulator-compatible = "ldo7";
- reg = <10>;
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- ti,regulator-ext-sleep-control = <1>;
- };
- ldo8_reg: regulator@11 {
- regulator-compatible = "ldo8";
- reg = <11>;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- ti,regulator-ext-sleep-control = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/twl-family.txt b/Documentation/devicetree/bindings/mfd/twl-family.txt
deleted file mode 100644
index c2f9302965de..000000000000
--- a/Documentation/devicetree/bindings/mfd/twl-family.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Texas Instruments TWL family
-
-The TWLs are Integrated Power Management Chips.
-Some version might contain much more analog function like
-USB transceiver or Audio amplifier.
-These chips are connected to an i2c bus.
-
-
-Required properties:
-- compatible : Must be "ti,twl4030";
- For Integrated power-management/audio CODEC device used in OMAP3
- based boards
-- compatible : Must be "ti,twl6030";
- For Integrated power-management used in OMAP4 based boards
-- interrupts : This i2c device has an IRQ line connected to the main SoC
-- interrupt-controller : Since the twl support several interrupts internally,
- it is considered as an interrupt controller cascaded to the SoC one.
-- #interrupt-cells = <1>;
-
-Optional node:
-- Child nodes contain in the twl. The twl family is made of several variants
- that support a different number of features.
- The children nodes will thus depend of the capability of the variant.
-
-
-Example:
-/*
- * Integrated Power Management Chip
- * https://www.ti.com/lit/ds/symlink/twl6030.pdf
- */
-twl@48 {
- compatible = "ti,twl6030";
- reg = <0x48>;
- interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-controller;
- #interrupt-cells = <1>;
- interrupt-parent = <&gic>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- twl_rtc {
- compatible = "ti,twl_rtc";
- interrupts = <11>;
- reg = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
deleted file mode 100644
index 414d2ae0adf6..000000000000
--- a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Texas Instruments TWL family (twl4030) audio module
-
-The audio module inside the TWL family consist of an audio codec and a vibra
-driver.
-
-Required properties:
-- compatible : must be "ti,twl4030-audio"
-
-Optional properties, nodes:
-
-Audio functionality:
-- codec { }: Need to be present if the audio functionality is used. Within this
- section the following options can be used:
-- ti,digimic_delay: Delay need after enabling the digimic to reduce artifacts
- from the start of the recorded sample (in ms)
--ti,ramp_delay_value: HS ramp delay configuration to reduce pop noise
--ti,hs_extmute: Use external mute for HS pop reduction
--ti,hs_extmute_gpio: Use external GPIO to control the external mute
--ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the
- valid values.
-
-Vibra functionality
-- ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if
- missing or it is 0, the vibra functionality is disabled.
-
-Example:
-&i2c1 {
- clock-frequency = <2600000>;
-
- twl: twl@48 {
- reg = <0x48>;
- interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
-
- twl_audio: audio {
- compatible = "ti,twl4030-audio";
-
- ti,enable-vibra = <1>;
-
- codec {
- ti,ramp_delay_value = <3>;
- };
-
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
deleted file mode 100644
index 3d19963312ce..000000000000
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Texas Instruments TWL family (twl4030) reset and power management module
-
-The power management module inside the TWL family provides several facilities
-to control the power resources, including power scripts. For now, the
-binding only supports the complete shutdown of the system after poweroff.
-
-Required properties:
-- compatible : must be one of the following
- "ti,twl4030-power"
- "ti,twl4030-power-reset"
- "ti,twl4030-power-idle"
- "ti,twl4030-power-idle-osc-off"
-
-The use of ti,twl4030-power-reset is recommended at least on
-3530 that needs a special configuration for warm reset to work.
-
-When using ti,twl4030-power-idle, the TI recommended configuration
-for idle modes is loaded to the tlw4030 PMIC.
-
-When using ti,twl4030-power-idle-osc-off, the TI recommended
-configuration is used with the external oscillator being shut
-down during off-idle. Note that this does not work on all boards
-depending on how the external oscillator is wired.
-
-Optional properties:
-
-- ti,system-power-controller: This indicates that TWL4030 is the
- power supply master of the system. With this flag, the chip will
- initiate an ACTIVE-to-OFF or SLEEP-to-OFF transition when the
- system poweroffs.
-
-- ti,use_poweroff: Deprecated name for ti,system-power-controller
-
-Example:
-&i2c1 {
- clock-frequency = <2600000>;
-
- twl: twl@48 {
- reg = <0x48>;
- interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
-
- twl_power: power {
- compatible = "ti,twl4030-power";
- ti,use_poweroff;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt
index 06e9dd7a0d96..dfd8683ede0c 100644
--- a/Documentation/devicetree/bindings/mfd/twl6040.txt
+++ b/Documentation/devicetree/bindings/mfd/twl6040.txt
@@ -2,7 +2,7 @@ Texas Instruments TWL6040 family
The TWL6040s are 8-channel high quality low-power audio codecs providing audio,
vibra and GPO functionality on OMAP4+ platforms.
-They are connected ot the host processor via i2c for commands, McPDM for audio
+They are connected to the host processor via i2c for commands, McPDM for audio
data and commands.
Required properties:
diff --git a/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml
index ea3337dafaf5..7902f3c5d289 100644
--- a/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml
+++ b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml
@@ -156,7 +156,7 @@ properties:
entry has a value that is out of range for a 16 bit register then the
chip default will be used. If present exactly five values must be
specified.
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 5
diff --git a/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
index de330c9869ff..f3d8394b27e7 100644
--- a/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
+++ b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mfd/x-powers,ac100.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mfd/x-powers,ac100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: X-Powers AC100 Device Tree Bindings
+title: X-Powers AC100
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
index 1c7601d05807..45f015d63df1 100644
--- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
+++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mfd/x-powers,axp152.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: X-Powers AXP PMIC Device Tree Bindings
+title: X-Powers AXP PMIC
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -47,9 +47,8 @@ allOf:
- x-powers,axp209
then:
- not:
- required:
- - x-powers,drive-vbus-en
+ properties:
+ x-powers,drive-vbus-en: false
- if:
not:
@@ -59,39 +58,57 @@ allOf:
const: x-powers,axp806
then:
- allOf:
- - not:
- required:
- - x-powers,self-working-mode
-
- - not:
- required:
- - x-powers,master-mode
+ properties:
+ x-powers,self-working-mode: false
+ x-powers,master-mode: false
- if:
not:
properties:
compatible:
contains:
- const: x-powers,axp305
+ enum:
+ - x-powers,axp15060
+ - x-powers,axp305
+ - x-powers,axp313a
+ - x-powers,axp323
then:
required:
- interrupts
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp313a
+ - x-powers,axp323
+ - x-powers,axp15060
+ - x-powers,axp717
+
+ then:
+ properties:
+ x-powers,dcdc-freq: false
+
properties:
compatible:
oneOf:
- enum:
- x-powers,axp152
+ - x-powers,axp192
- x-powers,axp202
- x-powers,axp209
- x-powers,axp221
- x-powers,axp223
+ - x-powers,axp313a
+ - x-powers,axp323
+ - x-powers,axp717
- x-powers,axp803
- x-powers,axp806
- x-powers,axp809
- x-powers,axp813
+ - x-powers,axp15060
- items:
- const: x-powers,axp228
- const: x-powers,axp221
@@ -260,7 +277,7 @@ properties:
Defines the work frequency of DC-DC in kHz.
patternProperties:
- "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|drivevbus|dc5ldo)$":
+ "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
$ref: /schemas/regulator/regulator.yaml#
type: object
unevaluatedProperties: false
@@ -299,106 +316,106 @@ additionalProperties: false
examples:
- |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pmic@30 {
- compatible = "x-powers,axp152";
- reg = <0x30>;
- interrupts = <0>;
- interrupt-controller;
- #interrupt-cells = <1>;
- };
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@30 {
+ compatible = "x-powers,axp152";
+ reg = <0x30>;
+ interrupts = <0>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
- |
- #include <dt-bindings/interrupt-controller/irq.h>
-
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pmic@34 {
- compatible = "x-powers,axp209";
- reg = <0x34>;
- interrupt-parent = <&nmi_intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- ac_power_supply: ac-power {
- compatible = "x-powers,axp202-ac-power-supply";
- };
-
- axp_adc: adc {
- compatible = "x-powers,axp209-adc";
- #io-channel-cells = <1>;
- };
-
- axp_gpio: gpio {
- compatible = "x-powers,axp209-gpio";
- gpio-controller;
- #gpio-cells = <2>;
-
- gpio0-adc-pin {
- pins = "GPIO0";
- function = "adc";
- };
- };
-
- battery_power_supply: battery-power {
- compatible = "x-powers,axp209-battery-power-supply";
- };
-
- regulators {
- /* Default work frequency for buck regulators */
- x-powers,dcdc-freq = <1500>;
-
- reg_dcdc2: dcdc2 {
- regulator-always-on;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1450000>;
- regulator-name = "vdd-cpu";
- };
-
- reg_dcdc3: dcdc3 {
- regulator-always-on;
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1400000>;
- regulator-name = "vdd-int-dll";
- };
-
- reg_ldo1: ldo1 {
- /* LDO1 is a fixed output regulator */
- regulator-always-on;
- regulator-min-microvolt = <1300000>;
- regulator-max-microvolt = <1300000>;
- regulator-name = "vdd-rtc";
- };
-
- reg_ldo2: ldo2 {
- regulator-always-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-name = "avcc";
- };
-
- reg_ldo3: ldo3 {
- regulator-name = "ldo3";
- };
-
- reg_ldo4: ldo4 {
- regulator-name = "ldo4";
- };
-
- reg_ldo5: ldo5 {
- regulator-name = "ldo5";
- };
- };
-
- usb_power_supply: usb-power {
- compatible = "x-powers,axp202-usb-power-supply";
- };
- };
- };
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ ac_power_supply: ac-power {
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
+
+ axp_adc: adc {
+ compatible = "x-powers,axp209-adc";
+ #io-channel-cells = <1>;
+ };
+
+ axp_gpio: gpio {
+ compatible = "x-powers,axp209-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio0-adc-pin {
+ pins = "GPIO0";
+ function = "adc";
+ };
+ };
+
+ battery_power_supply: battery-power {
+ compatible = "x-powers,axp209-battery-power-supply";
+ };
+
+ regulators {
+ /* Default work frequency for buck regulators */
+ x-powers,dcdc-freq = <1500>;
+
+ reg_dcdc2: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+ };
+
+ reg_ldo1: ldo1 {
+ /* LDO1 is a fixed output regulator */
+ regulator-always-on;
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-rtc";
+ };
+
+ reg_ldo2: ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+ };
+
+ reg_ldo3: ldo3 {
+ regulator-name = "ldo3";
+ };
+
+ reg_ldo4: ldo4 {
+ regulator-name = "ldo4";
+ };
+
+ reg_ldo5: ldo5 {
+ regulator-name = "ldo5";
+ };
+ };
+
+ usb_power_supply: usb-power {
+ compatible = "x-powers,axp202-usb-power-supply";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
index 9efd49c39bd2..6e880a46d7ee 100644
--- a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
+++ b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Bootlin
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mfd/xylon,logicvc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mfd/xylon,logicvc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xylon LogiCVC multi-function device
diff --git a/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
deleted file mode 100644
index e0f901edc063..000000000000
--- a/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Zodiac Inflight Innovations RAVE Supervisory Processor
-
-RAVE Supervisory Processor communicates with SoC over UART. It is
-expected that its Device Tree node is specified as a child of a node
-corresponding to UART controller used for communication.
-
-Required parent device properties:
-
- - compatible: Should be one of:
- - "zii,rave-sp-niu"
- - "zii,rave-sp-mezz"
- - "zii,rave-sp-esb"
- - "zii,rave-sp-rdu1"
- - "zii,rave-sp-rdu2"
-
- - current-speed: Should be set to baud rate SP device is using
-
-RAVE SP consists of the following sub-devices:
-
-Device Description
------- -----------
-rave-sp-wdt : Watchdog
-rave-sp-nvmem : Interface to onboard EEPROM
-rave-sp-backlight : Display backlight
-rave-sp-hwmon : Interface to onboard hardware sensors
-rave-sp-leds : Interface to onboard LEDs
-rave-sp-input : Interface to onboard power button
-
-Example of usage:
-
- rdu {
- compatible = "zii,rave-sp-rdu2";
- current-speed = <1000000>;
-
- watchdog {
- compatible = "zii,rave-sp-watchdog";
- };
- };
-
diff --git a/Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml b/Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml
new file mode 100644
index 000000000000..1d078c5ef168
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/zii,rave-sp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zodiac Inflight Innovations RAVE Supervisory Processor
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ RAVE Supervisory Processor communicates with SoC over UART. It is
+ expected that its Device Tree node is specified as a child of a node
+ corresponding to UART controller used for communication.
+
+properties:
+ compatible:
+ enum:
+ - zii,rave-sp-niu
+ - zii,rave-sp-mezz
+ - zii,rave-sp-esb
+ - zii,rave-sp-rdu1
+ - zii,rave-sp-rdu2
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ watchdog:
+ $ref: /schemas/watchdog/zii,rave-sp-wdt.yaml
+
+ backlight:
+ $ref: /schemas/leds/backlight/zii,rave-sp-backlight.yaml
+
+ pwrbutton:
+ $ref: /schemas/input/zii,rave-sp-pwrbutton.yaml
+
+patternProperties:
+ '^eeprom@[0-9a-f]+$':
+ $ref: /schemas/nvmem/zii,rave-sp-eeprom.yaml
+
+required:
+ - compatible
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mfd {
+ compatible = "zii,rave-sp-rdu2";
+ current-speed = <1000000>;
+
+ watchdog {
+ compatible = "zii,rave-sp-watchdog";
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/mips/brcm/brcm,bmips.txt b/Documentation/devicetree/bindings/mips/brcm/brcm,bmips.txt
deleted file mode 100644
index 8ef71b4085ca..000000000000
--- a/Documentation/devicetree/bindings/mips/brcm/brcm,bmips.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-* Broadcom MIPS (BMIPS) CPUs
-
-Required properties:
-- compatible: "brcm,bmips3300", "brcm,bmips4350", "brcm,bmips4380",
- "brcm,bmips5000"
-
-- mips-hpt-frequency: This is common to all CPUs in the system so it lives
- under the "cpus" node.
diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.yaml b/Documentation/devicetree/bindings/mips/brcm/soc.yaml
new file mode 100644
index 000000000000..461a8c063313
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/brcm/soc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom cable/DSL/settop platforms
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+description: |
+ Boards Broadcom cable/DSL/settop SoC shall have the following properties.
+ The experimental -viper variants are for running Linux on the 3384's
+ BMIPS4355 cable modem CPU instead of the BMIPS5000 application processor.
+
+properties:
+ $nodename:
+ const: '/'
+
+ compatible:
+ enum:
+ - brcm,bcm3368
+ - brcm,bcm3384
+ - brcm,bcm33843
+ - brcm,bcm3384-viper
+ - brcm,bcm33843-viper
+ - brcm,bcm6328
+ - brcm,bcm6358
+ - brcm,bcm6362
+ - brcm,bcm6368
+ - brcm,bcm63168
+ - brcm,bcm63268
+ - brcm,bcm7125
+ - brcm,bcm7346
+ - brcm,bcm7358
+ - brcm,bcm7360
+ - brcm,bcm7362
+ - brcm,bcm7420
+ - brcm,bcm7425
+
+ cpus:
+ type: object
+ additionalProperties: false
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ mips-hpt-frequency:
+ description: MIPS counter high precision timer frequency.
+ This is common to all CPUs in the system so it lives
+ under the "cpus" node.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ brcm,bmips-cbr-reg:
+ description: Reference address of the CBR.
+ Some SoC suffer from a BUG where CBR(Core Base Register)
+ address might be badly or never initialized by the Bootloader
+ or reading it from co-processor registers, if the system boots
+ from secondary CPU, results in invalid address.
+ The CBR address is always the same on the SoC hence it
+ can be provided in DT to handle these broken case.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ patternProperties:
+ "^cpu@[0-9]$":
+ type: object
+ $ref: /schemas/mips/cpus.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - mips-hpt-frequency
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm6358
+ - brcm,bcm6368
+
+then:
+ properties:
+ cpus:
+ required:
+ - brcm,bmips-cbr-reg
+
+additionalProperties: true
+
+examples:
+ - |
+ / {
+ compatible = "brcm,bcm3368";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "Broadcom 3368";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mips-hpt-frequency = <150000000>;
+
+ cpu@0 {
+ compatible = "brcm,bmips4350";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "brcm,bmips4350";
+ device_type = "cpu";
+ reg = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mips/cpu_irq.txt b/Documentation/devicetree/bindings/mips/cpu_irq.txt
deleted file mode 100644
index f080f06da6d8..000000000000
--- a/Documentation/devicetree/bindings/mips/cpu_irq.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-MIPS CPU interrupt controller
-
-On MIPS the mips_cpu_irq_of_init() helper can be used to initialize the 8 CPU
-IRQs from a devicetree file and create a irq_domain for IRQ controller.
-
-With the irq_domain in place we can describe how the 8 IRQs are wired to the
-platforms internal interrupt controller cascade.
-
-Below is an example of a platform describing the cascade inside the devicetree
-and the code used to load it inside arch_init_irq().
-
-Required properties:
-- compatible : Should be "mti,cpu-interrupt-controller"
-
-Example devicetree:
- cpu-irq: cpu-irq {
- #address-cells = <0>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- compatible = "mti,cpu-interrupt-controller";
- };
-
- intc: intc@200 {
- compatible = "ralink,rt2880-intc";
- reg = <0x200 0x100>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interrupt-parent = <&cpu-irq>;
- interrupts = <2>;
- };
-
-
-Example platform irq.c:
-static struct of_device_id __initdata of_irq_ids[] = {
- { .compatible = "mti,cpu-interrupt-controller", .data = mips_cpu_irq_of_init },
- { .compatible = "ralink,rt2880-intc", .data = intc_of_init },
- {},
-};
-
-void __init arch_init_irq(void)
-{
- of_irq_init(of_irq_ids);
-}
diff --git a/Documentation/devicetree/bindings/mips/cpus.yaml b/Documentation/devicetree/bindings/mips/cpus.yaml
new file mode 100644
index 000000000000..d3677f53f142
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/cpus.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/cpus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS CPUs
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+ - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
+
+description: |
+ The device tree allows to describe the layout of CPUs in a system through
+ the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
+ defining properties for every CPU.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bmips3300
+ - brcm,bmips4350
+ - brcm,bmips4380
+ - brcm,bmips5000
+ - brcm,bmips5200
+ - img,i6500
+ - ingenic,xburst-fpu1.0-mxu1.1
+ - ingenic,xburst-fpu2.0-mxu2.0
+ - ingenic,xburst-mxu1.0
+ - ingenic,xburst2-fpu2.1-mxu2.1-smt
+ - loongson,gs264
+ - mips,m14Kc
+ - mips,mips1004Kc
+ - mips,mips24KEc
+ - mips,mips24Kc
+ - mips,mips34Kc
+ - mips,mips4KEc
+ - mips,mips4Kc
+ - mips,mips74Kc
+ - mti,interaptiv
+ - mti,mips14KEc
+ - mti,mips14Kc
+ - mti,mips24KEc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ device_type: true
+
+allOf:
+ - $ref: /schemas/opp/opp-v1.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ingenic,xburst-mxu1.0
+ - ingenic,xburst-fpu1.0-mxu1.1
+ - ingenic,xburst-fpu2.0-mxu2.0
+ - ingenic,xburst2-fpu2.1-mxu2.1-smt
+ then:
+ required:
+ - device_type
+ - clocks
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ cpu@0 {
+ compatible = "mips,mips1004Kc";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "mips,mips1004Kc";
+ device_type = "cpu";
+ reg = <1>;
+ };
+ };
+
+ - |
+ // Example 2 (Ingenic CPU)
+ #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ device_type = "cpu";
+ reg = <0>;
+
+ clocks = <&cgu JZ4780_CLK_CPU>;
+ };
+
+ cpu@1 {
+ compatible = "ingenic,xburst-fpu1.0-mxu1.1";
+ device_type = "cpu";
+ reg = <1>;
+
+ clocks = <&cgu JZ4780_CLK_CORE1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mips/econet.yaml b/Documentation/devicetree/bindings/mips/econet.yaml
new file mode 100644
index 000000000000..d8181b58c781
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/econet.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/econet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet MIPS SoCs
+
+maintainers:
+ - Caleb James DeLisle <cjd@cjdns.fr>
+
+properties:
+ $nodename:
+ const: '/'
+
+ compatible:
+ oneOf:
+ - description: Boards with EcoNet EN751221 family SoC
+ items:
+ - enum:
+ - smartfiber,xp8421-b
+ - const: econet,en751221
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
index ee00d414df10..f2e822afe7fb 100644
--- a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
+++ b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mips/ingenic/devices.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic XBurst based Platforms Device Tree Bindings
+title: Ingenic XBurst based Platforms
maintainers:
- 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
deleted file mode 100644
index b7e7fa715437..000000000000
--- a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Bindings for Ingenic XBurst family CPUs
-
-maintainers:
- - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
-
-description:
- Ingenic XBurst family CPUs shall have the following properties.
-
-properties:
- compatible:
- oneOf:
-
- - description: Ingenic XBurst®1 CPU Cores
- enum:
- - ingenic,xburst-mxu1.0
- - ingenic,xburst-fpu1.0-mxu1.1
- - ingenic,xburst-fpu2.0-mxu2.0
-
- - description: Ingenic XBurst®2 CPU Cores
- enum:
- - ingenic,xburst2-fpu2.1-mxu2.1-smt
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- device_type: true
-
-required:
- - device_type
- - compatible
- - reg
- - clocks
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu0: cpu@0 {
- device_type = "cpu";
- compatible = "ingenic,xburst-fpu1.0-mxu1.1";
- reg = <0>;
-
- clocks = <&cgu JZ4780_CLK_CPU>;
- };
-
- cpu1: cpu@1 {
- device_type = "cpu";
- compatible = "ingenic,xburst-fpu1.0-mxu1.1";
- reg = <1>;
-
- clocks = <&cgu JZ4780_CLK_CORE1>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/mips/lantiq/lantiq,dma-xway.yaml b/Documentation/devicetree/bindings/mips/lantiq/lantiq,dma-xway.yaml
index 40130fefa2b4..15d41bdbdc26 100644
--- a/Documentation/devicetree/bindings/mips/lantiq/lantiq,dma-xway.yaml
+++ b/Documentation/devicetree/bindings/mips/lantiq/lantiq,dma-xway.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mips/lantiq/lantiq,dma-xway.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Lantiq Xway SoCs DMA Controller DT bindings
+title: Lantiq Xway SoCs DMA Controller
maintainers:
- John Crispin <john@phrozen.org>
diff --git a/Documentation/devicetree/bindings/mips/loongson/devices.yaml b/Documentation/devicetree/bindings/mips/loongson/devices.yaml
index 9fee6708e6f5..ca66bc49c2d6 100644
--- a/Documentation/devicetree/bindings/mips/loongson/devices.yaml
+++ b/Documentation/devicetree/bindings/mips/loongson/devices.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mips/loongson/devices.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Loongson based Platforms Device Tree Bindings
+title: Loongson based Platforms
maintainers:
- Jiaxun Yang <jiaxun.yang@flygoat.com>
@@ -37,6 +37,20 @@ properties:
items:
- const: loongson,loongson64v-4core-virtio
+ - description: LS1B based boards
+ items:
+ - enum:
+ - loongson,ls1b-demo
+ - loongson,lsgz-1b-dev
+ - const: loongson,ls1b
+
+ - description: LS1C based boards
+ items:
+ - enum:
+ - loongmasses,smartloong-1c
+ - loongson,cq-t300b
+ - const: loongson,ls1c
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml
index 20b5836efd90..358ac8cd4d1d 100644
--- a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml
+++ b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson 2K1000 PM Controller
diff --git a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
index 7c0f9022202c..3e3a3705e879 100644
--- a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
+++ b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mips/loongson/rs780e-acpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson RS780E PCH ACPI Controller
diff --git a/Documentation/devicetree/bindings/mips/mobileye.yaml b/Documentation/devicetree/bindings/mips/mobileye.yaml
new file mode 100644
index 000000000000..d60744550e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/mobileye.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright 2023 Mobileye Vision Technologies Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/mobileye.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mobileye SoC series
+
+maintainers:
+ - Vladimir Kondratiev <vladimir.kondratiev@intel.com>
+ - Gregory CLEMENT <gregory.clement@bootlin.com>
+ - Théo Lebrun <theo.lebrun@bootlin.com>
+
+description:
+ Boards with a Mobileye SoC shall have the following properties.
+
+properties:
+ $nodename:
+ const: '/'
+
+ compatible:
+ oneOf:
+ - description: Boards with Mobileye EyeQ5 SoC
+ items:
+ - enum:
+ - mobileye,eyeq5-epm5
+ - const: mobileye,eyeq5
+ - description: Boards with Mobileye EyeQ6H SoC
+ items:
+ - enum:
+ - mobileye,eyeq6h-epm6
+ - const: mobileye,eyeq6h
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
index cc916eaeed0a..e74165696b76 100644
--- a/Documentation/devicetree/bindings/mips/mscc.txt
+++ b/Documentation/devicetree/bindings/mips/mscc.txt
@@ -25,23 +25,6 @@ Example:
reg = <0x71070000 0x1c>;
};
-
-o CPU system control:
-
-The SoC has a few registers (ICPU_CFG:CPU_SYSTEM_CTRL) handling configuration of
-the CPU: 8 general purpose registers, reset control, CPU en/disabling, CPU
-endianness, CPU bus control, CPU status.
-
-Required properties:
-- compatible: Should be "mscc,ocelot-cpu-syscon", "syscon"
-- reg : Should contain registers location and length
-
-Example:
- syscon@70000000 {
- compatible = "mscc,ocelot-cpu-syscon", "syscon";
- reg = <0x70000000 0x2c>;
- };
-
o HSIO regs:
The SoC has a few registers (HSIO) handling miscellaneous functionalities:
diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
new file mode 100644
index 000000000000..d129d6382847
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/mti,mips-cm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS Coherence Manager
+
+description:
+ The Coherence Manager (CM) is responsible for establishing the
+ global ordering of requests from all elements of the system and
+ sending the correct data back to the requester. It supports Cache
+ to Cache transfers.
+ https://training.mips.com/cps_mips/PDF/CPS_Introduction.pdf
+ https://training.mips.com/cps_mips/PDF/Coherency_Manager.pdf
+
+maintainers:
+ - Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: mti,mips-cm
+ - const: mobileye,eyeq6-cm
+ description:
+ On EyeQ6 the HCI (Hardware Cache Initialization) information for
+ the L2 cache in multi-cluster configuration is broken.
+
+ reg:
+ description:
+ Base address and size of the Global Configuration Registers
+ referred to as CMGCR.They are the system programmer's interface
+ to the Coherency Manager. Their location in the memory map is
+ determined at core build time. In a functional system, the base
+ address is provided by the Coprocessor 0, but some
+ System-on-Chip (SoC) designs may not provide an accurate address
+ that needs to be described statically.
+
+ maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ coherency-manager@1fbf8000 {
+ compatible = "mti,mips-cm";
+ reg = <0x1bde8000 0x8000>;
+ };
+
+ - |
+ coherency-manager {
+ compatible = "mobileye,eyeq6-cm";
+ };
+...
diff --git a/Documentation/devicetree/bindings/mips/ralink.yaml b/Documentation/devicetree/bindings/mips/ralink.yaml
index 0588cee25ae9..53c1f6635377 100644
--- a/Documentation/devicetree/bindings/mips/ralink.yaml
+++ b/Documentation/devicetree/bindings/mips/ralink.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mips/ralink.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ralink SoC based Platforms Device Tree Bindings
+title: Ralink SoC based Platforms
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
@@ -80,6 +80,7 @@ properties:
- enum:
- gnubee,gb-pc1
- gnubee,gb-pc2
+ - tplink,hc220-g5-v1
- const: mediatek,mt7621-soc
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mips/realtek-rtl.yaml b/Documentation/devicetree/bindings/mips/realtek-rtl.yaml
index aadff8ce0f49..d337655bfbf8 100644
--- a/Documentation/devicetree/bindings/mips/realtek-rtl.yaml
+++ b/Documentation/devicetree/bindings/mips/realtek-rtl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mips/realtek-rtl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Realtek RTL83xx/93xx SoC series device tree bindings
+title: Realtek RTL83xx/93xx SoC series
maintainers:
- Bert Vermeulen <bert@biot.com>
@@ -20,5 +20,9 @@ properties:
- enum:
- cisco,sg220-26
- const: realtek,rtl8382-soc
+ - items:
+ - enum:
+ - cameo,rtl9302c-2x-rtl8224-2xge
+ - const: realtek,rtl9302-soc
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/misc/aspeed,ast2400-cvic.yaml b/Documentation/devicetree/bindings/misc/aspeed,ast2400-cvic.yaml
new file mode 100644
index 000000000000..accf1a7ecf12
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/aspeed,ast2400-cvic.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/aspeed,ast2400-cvic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed Coprocessor Vectored Interrupt Controller
+
+maintainers:
+ - Andrew Jeffery <andrew@codeconstruct.com.au>
+
+description:
+ The Aspeed AST2400 and AST2500 SoCs have a controller that provides interrupts
+ to the ColdFire coprocessor. It's not a normal interrupt controller and it
+ would be rather inconvenient to create an interrupt tree for it, as it
+ somewhat shares some of the same sources as the main ARM interrupt controller
+ but with different numbers.
+
+ The AST2500 also supports a software generated interrupt.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - aspeed,ast2400-cvic
+ - aspeed,ast2500-cvic
+ - const: aspeed,cvic
+
+ reg:
+ maxItems: 1
+
+ valid-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
+ description:
+ A bitmap of supported sources for the implementation.
+
+ copro-sw-interrupts:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 32
+ description:
+ A list of interrupt numbers that can be used as software interrupts from
+ the ARM to the coprocessor.
+
+required:
+ - compatible
+ - reg
+ - valid-sources
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1e6c2000 {
+ compatible = "aspeed,ast2500-cvic", "aspeed,cvic";
+ reg = <0x1e6c2000 0x80>;
+ valid-sources = <0xffffffff>;
+ copro-sw-interrupts = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/misc/aspeed,cvic.txt b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
deleted file mode 100644
index d62c783d1d5e..000000000000
--- a/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* ASPEED AST2400 and AST2500 coprocessor interrupt controller
-
-This file describes the bindings for the interrupt controller present
-in the AST2400 and AST2500 BMC SoCs which provides interrupt to the
-ColdFire coprocessor.
-
-It is not a normal interrupt controller and it would be rather
-inconvenient to create an interrupt tree for it as it somewhat shares
-some of the same sources as the main ARM interrupt controller but with
-different numbers.
-
-The AST2500 supports a SW generated interrupt
-
-Required properties:
-- reg: address and length of the register for the device.
-- compatible: "aspeed,cvic" and one of:
- "aspeed,ast2400-cvic"
- or
- "aspeed,ast2500-cvic"
-
-- valid-sources: One cell, bitmap of supported sources for the implementation
-
-Optional properties;
-- copro-sw-interrupts: List of interrupt numbers that can be used as
- SW interrupts from the ARM to the coprocessor.
- (AST2500 only)
-
-Example:
-
- cvic: copro-interrupt-controller@1e6c2000 {
- compatible = "aspeed,ast2500-cvic";
- valid-sources = <0xffffffff>;
- copro-sw-interrupts = <1>;
- reg = <0x1e6c2000 0x80>;
- };
diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
deleted file mode 100644
index f2e2e28b317c..000000000000
--- a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-======================================================================
-Device tree bindings for Aspeed AST2400/AST2500 PCI-to-AHB Bridge Control Driver
-======================================================================
-
-The bridge is available on platforms with the VGA enabled on the Aspeed device.
-In this case, the host has access to a 64KiB window into all of the BMC's
-memory. The BMC can disable this bridge. If the bridge is enabled, the host
-has read access to all the regions of memory, however the host only has read
-and write access depending on a register controlled by the BMC.
-
-Required properties:
-===================
-
- - compatible: must be one of:
- - "aspeed,ast2400-p2a-ctrl"
- - "aspeed,ast2500-p2a-ctrl"
-
-Optional properties:
-===================
-
-- reg: A hint for the memory regions associated with the P2A controller
-- memory-region: A phandle to a reserved_memory region to be used for the PCI
- to AHB mapping
-
-The p2a-control node should be the child of a syscon node with the required
-property:
-
-- compatible : Should be one of the following:
- "aspeed,ast2400-scu", "syscon", "simple-mfd"
- "aspeed,ast2500-scu", "syscon", "simple-mfd"
-
-Example
-===================
-
-g4 Example
-----------
-
-syscon: scu@1e6e2000 {
- compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
- reg = <0x1e6e2000 0x1a8>;
-
- p2a: p2a-control {
- compatible = "aspeed,ast2400-p2a-ctrl";
- memory-region = <&reserved_memory>;
- };
-};
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
deleted file mode 100644
index f9fb412642fe..000000000000
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Atmel SSC driver.
-
-Required properties:
-- compatible: "atmel,at91rm9200-ssc" or "atmel,at91sam9g45-ssc"
- - atmel,at91rm9200-ssc: support pdc transfer
- - atmel,at91sam9g45-ssc: support dma transfer
-- reg: Should contain SSC registers location and length
-- interrupts: Should contain SSC interrupt
-- clock-names: tuple listing input clock names.
- Required elements: "pclk"
-- clocks: phandles to input clocks.
-
-
-Required properties for devices compatible with "atmel,at91sam9g45-ssc":
-- dmas: DMA specifier, consisting of a phandle to DMA controller node,
- the memory interface and SSC DMA channel ID (for tx and rx).
- See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
-- dma-names: Must be "tx", "rx".
-
-Optional properties:
- - atmel,clk-from-rk-pin: bool property.
- - When SSC works in slave mode, according to the hardware design, the
- clock can get from TK pin, and also can get from RK pin. So, add
- this parameter to choose where the clock from.
- - By default the clock is from TK pin, if the clock from RK pin, this
- property is needed.
- - #sound-dai-cells: Should contain <0>.
- - This property makes the SSC into an automatically registered DAI.
-
-Examples:
-- PDC transfer:
-ssc0: ssc@fffbc000 {
- compatible = "atmel,at91rm9200-ssc";
- reg = <0xfffbc000 0x4000>;
- interrupts = <14 4 5>;
- clocks = <&ssc0_clk>;
- clock-names = "pclk";
-};
-
-- DMA transfer:
-ssc0: ssc@f0010000 {
- compatible = "atmel,at91sam9g45-ssc";
- reg = <0xf0010000 0x4000>;
- interrupts = <28 4 5>;
- dmas = <&dma0 1 13>,
- <&dma0 1 14>;
- dma-names = "tx", "rx";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
-};
diff --git a/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt b/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt
deleted file mode 100644
index 05b47232ed9e..000000000000
--- a/Documentation/devicetree/bindings/misc/brcm,kona-smc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Broadcom Secure Monitor Bounce buffer
------------------------------------------------------
-This binding defines the location of the bounce buffer
-used for non-secure to secure communications.
-
-Required properties:
-- compatible : "brcm,kona-smc"
-- DEPRECATED: compatible : "bcm,kona-smc"
-- reg : Location and size of bounce buffer
-
-Example:
- smc@3404c000 {
- compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
- reg = <0x3404c000 0x400>; //1 KiB in SRAM
- };
diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
index 8cc951feb7df..59b83ea5e05e 100644
--- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
+++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
@@ -12,7 +12,7 @@ maintainers:
properties:
compatible:
- const: "fsl,dpaa2-console"
+ const: fsl,dpaa2-console
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
deleted file mode 100644
index 7b486d4985dc..000000000000
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ /dev/null
@@ -1,196 +0,0 @@
-* Freescale Management Complex
-
-The Freescale Management Complex (fsl-mc) is a hardware resource
-manager that manages specialized hardware objects used in
-network-oriented packet processing applications. After the fsl-mc
-block is enabled, pools of hardware resources are available, such as
-queues, buffer pools, I/O interfaces. These resources are building
-blocks that can be used to create functional hardware objects/devices
-such as network interfaces, crypto accelerator instances, L2 switches,
-etc.
-
-For an overview of the DPAA2 architecture and fsl-mc bus see:
-Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
-
-As described in the above overview, all DPAA2 objects in a DPRC share the
-same hardware "isolation context" and a 10-bit value called an ICID
-(isolation context id) is expressed by the hardware to identify
-the requester.
-
-The generic 'iommus' property is insufficient to describe the relationship
-between ICIDs and IOMMUs, so an iommu-map property is used to define
-the set of possible ICIDs under a root DPRC and how they map to
-an IOMMU.
-
-For generic IOMMU bindings, see
-Documentation/devicetree/bindings/iommu/iommu.txt.
-
-For arm-smmu binding, see:
-Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
-
-The MSI writes are accompanied by sideband data which is derived from the ICID.
-The msi-map property is used to associate the devices with both the ITS
-controller and the sideband data which accompanies the writes.
-
-For generic MSI bindings, see
-Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-For GICv3 and GIC ITS bindings, see:
-Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
-
-Required properties:
-
- - compatible
- Value type: <string>
- Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex
- compatible with this binding must have Block Revision
- Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in
- the MC control register region.
-
- - reg
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies one or two regions
- defining the MC's registers:
-
- -the first region is the command portal for the
- this machine and must always be present
-
- -the second region is the MC control registers. This
- region may not be present in some scenarios, such
- as in the device tree presented to a virtual machine.
-
- - ranges
- Value type: <prop-encoded-array>
- Definition: A standard property. Defines the mapping between the child
- MC address space and the parent system address space.
-
- The MC address space is defined by 3 components:
- <region type> <offset hi> <offset lo>
-
- Valid values for region type are
- 0x0 - MC portals
- 0x1 - QBMAN portals
-
- - #address-cells
- Value type: <u32>
- Definition: Must be 3. (see definition in 'ranges' property)
-
- - #size-cells
- Value type: <u32>
- Definition: Must be 1.
-
-Sub-nodes:
-
- The fsl-mc node may optionally have dpmac sub-nodes that describe
- the relationship between the Ethernet MACs which belong to the MC
- and the Ethernet PHYs on the system board.
-
- The dpmac nodes must be under a node named "dpmacs" which contains
- the following properties:
-
- - #address-cells
- Value type: <u32>
- Definition: Must be present if dpmac sub-nodes are defined and must
- have a value of 1.
-
- - #size-cells
- Value type: <u32>
- Definition: Must be present if dpmac sub-nodes are defined and must
- have a value of 0.
-
- These nodes must have the following properties:
-
- - compatible
- Value type: <string>
- Definition: Must be "fsl,qoriq-mc-dpmac".
-
- - reg
- Value type: <prop-encoded-array>
- Definition: Specifies the id of the dpmac.
-
- - phy-handle
- Value type: <phandle>
- Definition: Specifies the phandle to the PHY device node associated
- with the this dpmac.
-Optional properties:
-
-- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
- data.
-
- The property is an arbitrary number of tuples of
- (icid-base,iommu,iommu-base,length).
-
- Any ICID i in the interval [icid-base, icid-base + length) is
- associated with the listed IOMMU, with the iommu-specifier
- (i - icid-base + iommu-base).
-
-- msi-map: Maps an ICID to a GIC ITS and associated msi-specifier
- data.
-
- The property is an arbitrary number of tuples of
- (icid-base,gic-its,msi-base,length).
-
- Any ICID in the interval [icid-base, icid-base + length) is
- associated with the listed GIC ITS, with the msi-specifier
- (i - icid-base + msi-base).
-
-Deprecated properties:
-
- - msi-parent
- Value type: <phandle>
- Definition: Describes the MSI controller node handling message
- interrupts for the MC. When there is no translation
- between the ICID and deviceID this property can be used
- to describe the MSI controller used by the devices on the
- mc-bus.
- The use of this property for mc-bus is deprecated. Please
- use msi-map.
-
-Example:
-
- smmu: iommu@5000000 {
- compatible = "arm,mmu-500";
- #iommu-cells = <1>;
- stream-match-mask = <0x7C00>;
- ...
- };
-
- gic: interrupt-controller@6000000 {
- compatible = "arm,gic-v3";
- ...
- }
- its: gic-its@6020000 {
- compatible = "arm,gic-v3-its";
- msi-controller;
- ...
- };
-
- fsl_mc: fsl-mc@80c000000 {
- compatible = "fsl,qoriq-mc";
- reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
- <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
- /* define map for ICIDs 23-64 */
- iommu-map = <23 &smmu 23 41>;
- /* define msi map for ICIDs 23-64 */
- msi-map = <23 &its 23 41>;
- #address-cells = <3>;
- #size-cells = <1>;
-
- /*
- * Region type 0x0 - MC portals
- * Region type 0x1 - QBMAN portals
- */
- ranges = <0x0 0x0 0x0 0x8 0x0c000000 0x4000000
- 0x1 0x0 0x0 0x8 0x18000000 0x8000000>;
-
- dpmacs {
- #address-cells = <1>;
- #size-cells = <0>;
-
- dpmac@1 {
- compatible = "fsl,qoriq-mc-dpmac";
- reg = <1>;
- phy-handle = <&mdio0_phy0>;
- }
- }
- };
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
new file mode 100644
index 000000000000..df45ff56d444
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
@@ -0,0 +1,187 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/fsl,qoriq-mc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Management Complex
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The Freescale Management Complex (fsl-mc) is a hardware resource
+ manager that manages specialized hardware objects used in
+ network-oriented packet processing applications. After the fsl-mc
+ block is enabled, pools of hardware resources are available, such as
+ queues, buffer pools, I/O interfaces. These resources are building
+ blocks that can be used to create functional hardware objects/devices
+ such as network interfaces, crypto accelerator instances, L2 switches,
+ etc.
+
+ For an overview of the DPAA2 architecture and fsl-mc bus see:
+ Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
+
+ As described in the above overview, all DPAA2 objects in a DPRC share the
+ same hardware "isolation context" and a 10-bit value called an ICID
+ (isolation context id) is expressed by the hardware to identify
+ the requester.
+
+ The generic 'iommus' property is insufficient to describe the relationship
+ between ICIDs and IOMMUs, so an iommu-map property is used to define
+ the set of possible ICIDs under a root DPRC and how they map to
+ an IOMMU.
+
+ For generic IOMMU bindings, see
+ Documentation/devicetree/bindings/iommu/iommu.txt.
+
+ For arm-smmu binding, see:
+ Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
+
+ The MSI writes are accompanied by sideband data which is derived from the ICID.
+ The msi-map property is used to associate the devices with both the ITS
+ controller and the sideband data which accompanies the writes.
+
+ For generic MSI bindings, see
+ Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+ For GICv3 and GIC ITS bindings, see:
+ Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
+
+properties:
+ compatible:
+ enum:
+ - fsl,qoriq-mc
+ description:
+ Must be "fsl,qoriq-mc". A Freescale Management Complex
+ compatible with this binding must have Block Revision
+ Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in
+ the MC control register region.
+
+ reg:
+ items:
+ - description:
+ the first region is the command portal for the
+ this machine and must always be present
+
+ - description:
+ the second region is the MC control registers. This
+ region may not be present in some scenarios, such
+ as in the device tree presented to a virtual machine.
+
+ ranges:
+ description: |
+ A standard property. Defines the mapping between the child
+ MC address space and the parent system address space.
+
+ The MC address space is defined by 3 components:
+ <region type> <offset hi> <offset lo>
+
+ Valid values for region type are
+ 0x0 - MC portals
+ 0x1 - QBMAN portals
+
+ "#address-cells":
+ const: 3
+
+ "#size-cells":
+ const: 1
+
+ iommu-map:
+ description: |
+ Maps an ICID to an IOMMU and associated iommu-specifier
+ data.
+
+ The property is an arbitrary number of tuples of
+ (icid-base,iommu,iommu-base,length).
+
+ Any ICID i in the interval [icid-base, icid-base + length) is
+ associated with the listed IOMMU, with the iommu-specifier
+ (i - icid-base + iommu-base).
+
+ msi-map:
+ description: |
+ Maps an ICID to a GIC ITS and associated msi-specifier
+ data.
+
+ The property is an arbitrary number of tuples of
+ (icid-base,gic-its,msi-base,length).
+
+ Any ICID in the interval [icid-base, icid-base + length) is
+ associated with the listed GIC ITS, with the msi-specifier
+ (i - icid-base + msi-base).
+
+ msi-parent:
+ deprecated: true
+ maxItems: 1
+ description:
+ Describes the MSI controller node handling message
+ interrupts for the MC. When there is no translation
+ between the ICID and deviceID this property can be used
+ to describe the MSI controller used by the devices on the
+ mc-bus.
+ The use of this property for mc-bus is deprecated. Please
+ use msi-map.
+
+ dma-coherent: true
+
+ dpmacs:
+ type: object
+ description:
+ The fsl-mc node may optionally have dpmac sub-nodes that describe
+ the relationship between the Ethernet MACs which belong to the MC
+ and the Ethernet PHYs on the system board.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ '^ethernet@[a-f0-9]+$':
+ $ref: /schemas/net/fsl,qoriq-mc-dpmac.yaml
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ fsl-mc@80c000000 {
+ compatible = "fsl,qoriq-mc";
+ reg = <0x0c000000 0x40>, /* MC portal base */
+ <0x08340000 0x40000>; /* MC control reg */
+ /*
+ * Region type 0x0 - MC portals
+ * Region type 0x1 - QBMAN portals
+ */
+ ranges = <0x0 0x0 0x8 0x0c000000 0x4000000
+ 0x1 0x0 0x8 0x18000000 0x8000000>;
+
+ /* define map for ICIDs 23-64 */
+ iommu-map = <23 &smmu 23 41>;
+ /* define msi map for ICIDs 23-64 */
+ msi-map = <23 &its 23 41>;
+ #address-cells = <3>;
+ #size-cells = <1>;
+
+ dpmacs {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <1>;
+ phy-handle = <&mdio0_phy0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/misc/idt,89hpesx.yaml b/Documentation/devicetree/bindings/misc/idt,89hpesx.yaml
new file mode 100644
index 000000000000..452236e79354
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/idt,89hpesx.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/idt,89hpesx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EEPROM / CSR SMBus-slave interface of IDT 89HPESx devices
+
+maintainers:
+ - Serge Semin <fancer.lancer@gmail.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ pattern: '^idt,89hpes'
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - pattern: '^idt,89hpes(8nt2|12nt3|12n3a?|24n3a?|(12|24)t3g2|4t4g2|10t4g2|[56]t5|8t5a?)$'
+ - pattern: '^idt,89hpes(6t6g2|16t7|(24t6|32t8|48t12|16t4a?)(g2)?)$'
+ - pattern: '^idt,89hpes(24nt6a|32nt8[ab]|12nt12|16nt16|24nt24|32nt24[ab])g2$'
+ - pattern: '^idt,89hpes((32h8|48h12a?|22h16|34h16|64h16a?)(g2)?|16h16)$'
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^eeprom@':
+ $ref: /schemas/eeprom/at24.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ description: Only a subset of devices are supported
+ pattern: ',24c(32|64|128|256|512)$'
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ idt@74 {
+ compatible = "idt,89hpes32nt8ag2";
+ reg = <0x74>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ read-only;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/misc/idt_89hpesx.txt b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
deleted file mode 100644
index b9093b79ab7d..000000000000
--- a/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-EEPROM / CSR SMBus-slave interface of IDT 89HPESx devices
-
-Required properties:
- - compatible : should be "<manufacturer>,<type>"
- Basically there is only one manufacturer: idt, but some
- compatible devices may be produced in future. Following devices
- are supported: 89hpes8nt2, 89hpes12nt3, 89hpes24nt6ag2,
- 89hpes32nt8ag2, 89hpes32nt8bg2, 89hpes12nt12g2, 89hpes16nt16g2,
- 89hpes24nt24g2, 89hpes32nt24ag2, 89hpes32nt24bg2;
- 89hpes12n3, 89hpes12n3a, 89hpes24n3, 89hpes24n3a;
- 89hpes32h8, 89hpes32h8g2, 89hpes48h12, 89hpes48h12g2,
- 89hpes48h12ag2, 89hpes16h16, 89hpes22h16, 89hpes22h16g2,
- 89hpes34h16, 89hpes34h16g2, 89hpes64h16, 89hpes64h16g2,
- 89hpes64h16ag2;
- 89hpes12t3g2, 89hpes24t3g2, 89hpes16t4, 89hpes4t4g2,
- 89hpes10t4g2, 89hpes16t4g2, 89hpes16t4ag2, 89hpes5t5,
- 89hpes6t5, 89hpes8t5, 89hpes8t5a, 89hpes24t6, 89hpes6t6g2,
- 89hpes24t6g2, 89hpes16t7, 89hpes32t8, 89hpes32t8g2,
- 89hpes48t12, 89hpes48t12g2.
- - reg : I2C address of the IDT 89HPESx device.
-
-Optionally there can be EEPROM-compatible subnode:
- - compatible: There are five EEPROM devices supported: 24c32, 24c64, 24c128,
- 24c256 and 24c512 differed by size.
- - reg: Custom address of EEPROM device (If not specified IDT 89HPESx
- (optional) device will try to communicate with EEPROM sited by default
- address - 0x50)
- - read-only : Parameterless property disables writes to the EEPROM
- (optional)
-
-Example:
- idt@60 {
- compatible = "idt,89hpes32nt8ag2";
- reg = <0x74>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeprom@50 {
- compatible = "onsemi,24c64";
- reg = <0x50>;
- read-only;
- };
- };
-
diff --git a/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml b/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml
index 38ab0499102d..aab89946b04f 100644
--- a/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml
+++ b/Documentation/devicetree/bindings/misc/intel,ixp4xx-ahb-queue-manager.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx AHB Queue Manager
@@ -45,7 +45,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
qmgr: queue-manager@60000000 {
- compatible = "intel,ixp4xx-ahb-queue-manager";
- reg = <0x60000000 0x4000>;
- interrupts = <3 IRQ_TYPE_LEVEL_HIGH>, <4 IRQ_TYPE_LEVEL_HIGH>;
+ compatible = "intel,ixp4xx-ahb-queue-manager";
+ reg = <0x60000000 0x4000>;
+ interrupts = <3 IRQ_TYPE_LEVEL_HIGH>, <4 IRQ_TYPE_LEVEL_HIGH>;
};
diff --git a/Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml b/Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml
new file mode 100644
index 000000000000..73fbf672e22a
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/lwn,bk4-spi.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/lwn,bk4-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Liebherr's BK4 external SPI controller
+
+maintainers:
+ - Lukasz Majewski <lukma@denx.de>
+
+description: |
+ Liebherr's BK4 external SPI controller is a device which handles data
+ acquisition from compatible industrial peripherals.
+ The SPI is used for data and management purposes in both master and
+ slave modes.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: lwn,bk4-spi
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 30000000
+
+ fsl,spi-cs-sck-delay: true
+
+ fsl,spi-sck-cs-delay: true
+
+required:
+ - compatible
+ - spi-max-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spidev@0 {
+ compatible = "lwn,bk4-spi";
+ reg = <0>;
+ spi-max-frequency = <30000000>;
+ fsl,spi-cs-sck-delay = <200>;
+ fsl,spi-sck-cs-delay = <400>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/misc/lwn-bk4.txt b/Documentation/devicetree/bindings/misc/lwn-bk4.txt
deleted file mode 100644
index d6a8c188c087..000000000000
--- a/Documentation/devicetree/bindings/misc/lwn-bk4.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Liebherr's BK4 controller external SPI
-
-A device which handles data acquisition from compatible industrial
-peripherals.
-The SPI is used for data and management purposes in both master and
-slave modes.
-
-Required properties:
-
-- compatible : Should be "lwn,bk4"
-
-Required SPI properties:
-
-- reg : Should be address of the device chip select within
- the controller.
-
-- spi-max-frequency : Maximum SPI clocking speed of device in Hz, should be
- 30MHz at most for the Liebherr's BK4 external bus.
-
-Example:
-
-spidev0: spi@0 {
- compatible = "lwn,bk4";
- spi-max-frequency = <30000000>;
- reg = <0>;
-};
diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml b/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml
index cacb845868f4..87fcce7cbb40 100644
--- a/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml
+++ b/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml
@@ -20,6 +20,7 @@ properties:
- nvidia,tegra186-misc
- nvidia,tegra194-misc
- nvidia,tegra234-misc
+ - nvidia,tegra264-misc
reg:
items:
diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
index b3c45c046ba5..e99342f268a6 100644
--- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
+++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/misc/olpc,xo1.75-ec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: OLPC XO-1.75 Embedded Controller bindings
+title: OLPC XO-1.75 Embedded Controller
description: |
This binding describes the Embedded Controller acting as a SPI bus master
diff --git a/Documentation/devicetree/bindings/misc/pci1de4,1.yaml b/Documentation/devicetree/bindings/misc/pci1de4,1.yaml
new file mode 100644
index 000000000000..2f9a7a554ed8
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/pci1de4,1.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/pci1de4,1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RaspberryPi RP1 MFD PCI device
+
+maintainers:
+ - A. della Porta <andrea.porta@suse.com>
+
+description:
+ The RaspberryPi RP1 is a PCI multi function device containing
+ peripherals ranging from Ethernet to USB controller, I2C, SPI
+ and others.
+ The peripherals are accessed by addressing the PCI BAR1 region.
+
+allOf:
+ - $ref: /schemas/pci/pci-ep-bus.yaml
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - const: pci1de4,1
+
+ '#interrupt-cells':
+ const: 2
+ description: |
+ Specifies respectively the interrupt number and flags as defined
+ in include/dt-bindings/interrupt-controller/irq.h.
+ Since all interrupts are active high, only IRQ_TYPE_LEVEL_HIGH
+ and IRQ_TYPE_EDGE_RISING can be specified as type flags.
+ The supported values for the interrupt number are:
+ - IO BANK0: 0
+ - IO BANK1: 1
+ - IO BANK2: 2
+ - AUDIO IN: 3
+ - AUDIO OUT: 4
+ - PWM0: 5
+ - ETH: 6
+ - I2C0: 7
+ - I2C1: 8
+ - I2C2: 9
+ - I2C3: 10
+ - I2C4: 11
+ - I2C5: 12
+ - I2C6: 13
+ - I2S0: 14
+ - I2S1: 15
+ - I2S2: 16
+ - SDIO0: 17
+ - SDIO1: 18
+ - SPI0: 19
+ - SPI1: 20
+ - SPI2: 21
+ - SPI3: 22
+ - SPI4: 23
+ - SPI5: 24
+ - UART0: 25
+ - TIMER0: 26
+ - TIMER1: 27
+ - TIMER2: 28
+ - TIMER3: 29
+ - USB HOST0: 30
+ - USB HOST0-0: 31
+ - USB HOST0-1: 32
+ - USB HOST0-2: 33
+ - USB HOST0-3: 34
+ - USB HOST1: 35
+ - USB HOST1-0: 36
+ - USB HOST1-1: 37
+ - USB HOST1-2: 38
+ - USB HOST1-3: 39
+ - DMA: 40
+ - PWM1: 41
+ - UART1: 42
+ - UART2: 43
+ - UART3: 44
+ - UART4: 45
+ - UART5: 46
+ - MIPI0: 47
+ - MIPI1: 48
+ - VIDEO OUT: 49
+ - PIO0: 50
+ - PIO1: 51
+ - ADC FIFO: 52
+ - PCIE OUT: 53
+ - SPI6: 54
+ - SPI7: 55
+ - SPI8: 56
+ - PROC MISC: 57
+ - SYSCFG: 58
+ - CLOCKS DEFAULT: 59
+ - VBUSCTRL: 60
+
+ interrupt-controller: true
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - '#interrupt-cells'
+ - interrupt-controller
+ - pci-ep-bus@1
+
+examples:
+ - |
+ pci {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ rp1@0,0 {
+ compatible = "pci1de4,1";
+ ranges = <0x01 0x00 0x00000000 0x82010000 0x00 0x00 0x00 0x400000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ pci_ep_bus: pci-ep-bus@1 {
+ compatible = "simple-bus";
+ ranges = <0x00 0x40000000 0x01 0x00 0x00000000 0x00 0x00400000>;
+ dma-ranges = <0x10 0x00000000 0x43000000 0x10 0x00000000 0x10 0x00000000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ rp1_clocks: clocks@40018000 {
+ compatible = "raspberrypi,rp1-clocks";
+ reg = <0x00 0x40018000 0x0 0x10038>;
+ #clock-cells = <1>;
+ clocks = <&clk_rp1_xosc>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
deleted file mode 100644
index 5ec124b138a6..000000000000
--- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Qualcomm Technologies, Inc. FastRPC Driver
-
-The FastRPC implements an IPC (Inter-Processor Communication)
-mechanism that allows for clients to transparently make remote method
-invocations across DSP and APPS boundaries. This enables developers
-to offload tasks to the DSP and free up the application processor for
-other tasks.
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: must be "qcom,fastrpc"
-
-- label
- Usage: required
- Value type: <string>
- Definition: should specify the dsp domain name this fastrpc
- corresponds to. must be one of this: "adsp", "mdsp", "sdsp", "cdsp"
-
-- qcom,non-secure-domain:
- Usage: required
- Value type: <boolean>
- Definition: Property to specify that dsp domain is non-secure.
-
-- qcom,vmids:
- Usage: optional
- Value type: <u32 array>
- Definition: Virtual machine IDs for remote processor.
-
-- #address-cells
- Usage: required
- Value type: <u32>
- Definition: Must be 1
-
-- #size-cells
- Usage: required
- Value type: <u32>
- Definition: Must be 0
-
-= COMPUTE BANKS
-Each subnode of the Fastrpc represents compute context banks available
-on the dsp.
-- All Compute context banks MUST contain the following properties:
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: must be "qcom,fastrpc-compute-cb"
-
-- reg
- Usage: required
- Value type: <u32>
- Definition: Context Bank ID.
-
-- qcom,nsessions:
- Usage: Optional
- Value type: <u32>
- Defination: A value indicating how many sessions can share this
- context bank. Defaults to 1 when this property
- is not specified.
-
-Example:
-
-adsp-pil {
- compatible = "qcom,msm8996-adsp-pil";
- ...
- smd-edge {
- label = "lpass";
- fastrpc {
- compatible = "qcom,fastrpc";
- qcom,smd-channels = "fastrpcsmd-apps-dsp";
- label = "adsp";
- #address-cells = <1>;
- #size-cells = <0>;
-
- cb@1 {
- compatible = "qcom,fastrpc-compute-cb";
- reg = <1>;
- };
-
- cb@2 {
- compatible = "qcom,fastrpc-compute-cb";
- reg = <2>;
- };
- ...
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
new file mode 100644
index 000000000000..3f6199fc9ae6
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/qcom,fastrpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm FastRPC Driver
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ The FastRPC implements an IPC (Inter-Processor Communication)
+ mechanism that allows for clients to transparently make remote method
+ invocations across DSP and APPS boundaries. This enables developers
+ to offload tasks to the DSP and free up the application processor for
+ other tasks.
+
+properties:
+ compatible:
+ const: qcom,fastrpc
+
+ label:
+ enum:
+ - adsp
+ - mdsp
+ - sdsp
+ - cdsp
+ - cdsp1
+ - gdsp0
+ - gdsp1
+
+ memory-region:
+ maxItems: 1
+ description:
+ Phandle to a node describing memory to be used for remote heap CMA.
+
+ qcom,glink-channels:
+ description:
+ A list of channels tied to this function, used for matching
+ the function to a set of virtual channels.
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - const: fastrpcglink-apps-dsp
+
+ qcom,non-secure-domain:
+ description:
+ Used to mark the current domain as non-secure.
+ type: boolean
+
+ qcom,smd-channels:
+ description:
+ Channel name used for the RPM communication
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - const: fastrpcsmd-apps-dsp
+
+ qcom,vmids:
+ description:
+ Virtual machine IDs for remote processor.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "(compute-)?cb@[0-9]*$":
+ type: object
+
+ description: >
+ Each subnode of the Fastrpc represents compute context banks available on the dsp.
+
+ properties:
+ compatible:
+ const: qcom,fastrpc-compute-cb
+
+ reg:
+ maxItems: 1
+
+ dma-coherent: true
+
+ iommus:
+ minItems: 1
+ maxItems: 10
+
+ qcom,nsessions:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ description: >
+ A value indicating how many sessions can share this context bank.
+
+ required:
+ - compatible
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - label
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,glink-channels = "fastrpcglink-apps-dsp";
+ label = "sdsp";
+ qcom,non-secure-domain;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compute-cb@1 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <1>;
+ iommus = <&apps_smmu 0x0541 0x0>;
+ };
+
+ compute-cb@2 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <2>;
+ iommus = <&apps_smmu 0x0542 0x0>;
+ };
+
+ compute-cb@3 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <3>;
+ iommus = <&apps_smmu 0x0543 0x0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml b/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml
index 1aebeb696ee0..e12d80be00cd 100644
--- a/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml
+++ b/Documentation/devicetree/bindings/misc/qemu,vcpu-stall-detector.yaml
@@ -29,6 +29,9 @@ properties:
Defaults to 10 if unset.
default: 10
+ interrupts:
+ maxItems: 1
+
timeout-sec:
description: |
The stall detector expiration timeout measured in seconds.
@@ -43,9 +46,12 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
vmwdt@9030000 {
compatible = "qemu,vcpu-stall-detector";
reg = <0x9030000 0x10000>;
clock-frequency = <10>;
timeout-sec = <8>;
+ interrupts = <GIC_PPI 15 IRQ_TYPE_EDGE_RISING>;
};
diff --git a/Documentation/devicetree/bindings/misc/ti,fpc202.yaml b/Documentation/devicetree/bindings/misc/ti,fpc202.yaml
new file mode 100644
index 000000000000..a8cb10f2d0df
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,fpc202.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/ti,fpc202.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI FPC202 dual port controller with expanded IOs
+
+maintainers:
+ - Romain Gantois <romain.gantois@bootlin.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-atr.yaml#
+
+properties:
+ compatible:
+ const: ti,fpc202
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ enable-gpios:
+ description:
+ Specifier for the GPIO connected to the EN pin.
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ "^i2c@[0-1]$":
+ $ref: /schemas/i2c/i2c-controller.yaml#
+ description: Downstream device ports 0 and 1
+
+ properties:
+ reg:
+ maxItems: 1
+ description:
+ Downstream port ID
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-atr@f {
+ compatible = "ti,fpc202";
+ reg = <0xf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml
new file mode 100644
index 000000000000..0c9a8444844c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,j721e-esm.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/ti,j721e-esm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM
+
+maintainers:
+ - Neha Malcom Francis <n-francis@ti.com>
+
+description:
+ The ESM (Error Signaling Module) is an IP block on TI K3 devices
+ that allows handling of safety events somewhat similar to what interrupt
+ controller would do. The safety signals have their separate paths within
+ the SoC, and they are handled by the ESM, which routes them to the proper
+ destination, which can be system reset, interrupt controller, etc. In the
+ simplest configuration the signals are just routed to reset the SoC.
+
+properties:
+ compatible:
+ const: ti,j721e-esm
+
+ reg:
+ maxItems: 1
+
+ ti,esm-pins:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ integer array of ESM interrupt pins to route to external event pin
+ which can be used to reset the SoC.
+ minItems: 1
+ maxItems: 255
+
+required:
+ - compatible
+ - reg
+ - ti,esm-pins
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ esm@700000 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x700000 0x0 0x1000>;
+ ti,esm-pins = <344>, <345>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
deleted file mode 100644
index e3289634fa30..000000000000
--- a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* Xilinx SDFEC(16nm) IP *
-
-The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block
-which provides high-throughput LDPC and Turbo Code implementations.
-The LDPC decode & encode functionality is capable of covering a range of
-customer specified Quasi-cyclic (QC) codes. The Turbo decode functionality
-principally covers codes used by LTE. The FEC Engine offers significant
-power and area savings versus implementations done in the FPGA fabric.
-
-
-Required properties:
-- compatible: Must be "xlnx,sd-fec-1.1"
-- clock-names : List of input clock names from the following:
- - "core_clk", Main processing clock for processing core (required)
- - "s_axi_aclk", AXI4-Lite memory-mapped slave interface clock (required)
- - "s_axis_din_aclk", DIN AXI4-Stream Slave interface clock (optional)
- - "s_axis_din_words-aclk", DIN_WORDS AXI4-Stream Slave interface clock (optional)
- - "s_axis_ctrl_aclk", Control input AXI4-Stream Slave interface clock (optional)
- - "m_axis_dout_aclk", DOUT AXI4-Stream Master interface clock (optional)
- - "m_axis_dout_words_aclk", DOUT_WORDS AXI4-Stream Master interface clock (optional)
- - "m_axis_status_aclk", Status output AXI4-Stream Master interface clock (optional)
-- clocks : Clock phandles (see clock_bindings.txt for details).
-- reg: Should contain Xilinx SDFEC 16nm Hardened IP block registers
- location and length.
-- xlnx,sdfec-code : Should contain "ldpc" or "turbo" to describe the codes
- being used.
-- xlnx,sdfec-din-words : A value 0 indicates that the DIN_WORDS interface is
- driven with a fixed value and is not present on the device, a value of 1
- configures the DIN_WORDS to be block based, while a value of 2 configures the
- DIN_WORDS input to be supplied for each AXI transaction.
-- xlnx,sdfec-din-width : Configures the DIN AXI stream where a value of 1
- configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width
- of "4x128b".
-- xlnx,sdfec-dout-words : A value 0 indicates that the DOUT_WORDS interface is
- driven with a fixed value and is not present on the device, a value of 1
- configures the DOUT_WORDS to be block based, while a value of 2 configures the
- DOUT_WORDS input to be supplied for each AXI transaction.
-- xlnx,sdfec-dout-width : Configures the DOUT AXI stream where a value of 1
- configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width
- of "4x128b".
-Optional properties:
-- interrupts: should contain SDFEC interrupt number
-
-Example
----------------------------------------
- sd_fec_0: sd-fec@a0040000 {
- compatible = "xlnx,sd-fec-1.1";
- clock-names = "core_clk","s_axi_aclk","s_axis_ctrl_aclk","s_axis_din_aclk","m_axis_status_aclk","m_axis_dout_aclk";
- clocks = <&misc_clk_2>,<&misc_clk_0>,<&misc_clk_1>,<&misc_clk_1>,<&misc_clk_1>, <&misc_clk_1>;
- reg = <0x0 0xa0040000 0x0 0x40000>;
- interrupt-parent = <&axi_intc>;
- interrupts = <1 0>;
- xlnx,sdfec-code = "ldpc";
- xlnx,sdfec-din-words = <0>;
- xlnx,sdfec-din-width = <2>;
- xlnx,sdfec-dout-words = <0>;
- xlnx,sdfec-dout-width = <1>;
- };
diff --git a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml
new file mode 100644
index 000000000000..9bd210337426
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,sd-fec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx SDFEC(16nm) IP
+
+maintainers:
+ - Cvetic, Dragan <dragan.cvetic@amd.com>
+ - Erim, Salih <salih.erim@amd.com>
+
+description:
+ The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block
+ which provides high-throughput LDPC and Turbo Code implementations.
+ The LDPC decode & encode functionality is capable of covering a range of
+ customer specified Quasi-cyclic (QC) codes. The Turbo decode functionality
+ principally covers codes used by LTE. The FEC Engine offers significant
+ power and area savings versus implementations done in the FPGA fabric.
+
+properties:
+ compatible:
+ const: xlnx,sd-fec-1.1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 8
+ additionalItems: true
+ items:
+ - description: Main processing clock for processing core
+ - description: AXI4-Lite memory-mapped slave interface clock
+ - description: Control input AXI4-Stream Slave interface clock
+ - description: DIN AXI4-Stream Slave interface clock
+ - description: Status output AXI4-Stream Master interface clock
+ - description: DOUT AXI4-Stream Master interface clock
+ - description: DIN_WORDS AXI4-Stream Slave interface clock
+ - description: DOUT_WORDS AXI4-Stream Master interface clock
+
+ clock-names:
+ allOf:
+ - minItems: 2
+ maxItems: 8
+ additionalItems: true
+ items:
+ - const: core_clk
+ - const: s_axi_aclk
+ - items:
+ enum:
+ - core_clk
+ - s_axi_aclk
+ - s_axis_ctrl_aclk
+ - s_axis_din_aclk
+ - m_axis_status_aclk
+ - m_axis_dout_aclk
+ - s_axis_din_words_aclk
+ - m_axis_dout_words_aclk
+
+ interrupts:
+ maxItems: 1
+
+ xlnx,sdfec-code:
+ description:
+ The SD-FEC integrated block supports Low Density Parity Check (LDPC)
+ decoding and encoding and Turbo code decoding. The LDPC codes used are
+ highly configurable, and the specific code used can be specified on
+ a codeword-by-codeword basis. The Turbo code decoding is required by LTE
+ standard.
+ $ref: /schemas/types.yaml#/definitions/string
+ items:
+ enum: [ ldpc, turbo ]
+
+ xlnx,sdfec-din-width:
+ description:
+ Configures the DIN AXI stream where a value of 1
+ configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width
+ of "4x128b".
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1, 2, 4 ]
+
+ xlnx,sdfec-din-words:
+ description:
+ A value 0 indicates that the DIN_WORDS interface is
+ driven with a fixed value and is not present on the device, a value of 1
+ configures the DIN_WORDS to be block based, while a value of 2 configures the
+ DIN_WORDS input to be supplied for each AXI transaction.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+
+ xlnx,sdfec-dout-width:
+ description:
+ Configures the DOUT AXI stream where a value of 1 configures a width of "1x128b",
+ 2 a width of "2x128b" and 4 configures a width of "4x128b".
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1, 2, 4 ]
+
+ xlnx,sdfec-dout-words:
+ description:
+ A value 0 indicates that the DOUT_WORDS interface is
+ driven with a fixed value and is not present on the device, a value of 1
+ configures the DOUT_WORDS to be block based, while a value of 2 configures the
+ DOUT_WORDS input to be supplied for each AXI transaction.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - xlnx,sdfec-code
+ - xlnx,sdfec-din-width
+ - xlnx,sdfec-din-words
+ - xlnx,sdfec-dout-width
+ - xlnx,sdfec-dout-words
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ sd-fec@a0040000 {
+ compatible = "xlnx,sd-fec-1.1";
+ reg = <0xa0040000 0x40000>;
+ clocks = <&misc_clk_2>, <&misc_clk_0>, <&misc_clk_1>, <&misc_clk_1>,
+ <&misc_clk_1>, <&misc_clk_1>;
+ clock-names = "core_clk", "s_axi_aclk", "s_axis_ctrl_aclk",
+ "s_axis_din_aclk", "m_axis_status_aclk",
+ "m_axis_dout_aclk";
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+ xlnx,sdfec-code = "ldpc";
+ xlnx,sdfec-din-width = <2>;
+ xlnx,sdfec-din-words = <0>;
+ xlnx,sdfec-dout-width = <1>;
+ xlnx,sdfec-dout-words = <0>;
+ };
+
diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml
new file mode 100644
index 000000000000..1b6020e4ec27
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-inject.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,tmr-inject.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Triple Modular Redundancy(TMR) Inject IP
+
+maintainers:
+ - Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
+
+description: |
+ The Triple Modular Redundancy(TMR) Inject core provides functional fault
+ injection by changing selected MicroBlaze instructions, which provides the
+ possibility to verify that the TMR subsystem error detection and fault
+ recovery logic is working properly.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,tmr-inject-1.0
+
+ reg:
+ maxItems: 1
+
+ xlnx,magic:
+ minimum: 0
+ maximum: 255
+ description: |
+ Magic number, When configured it allows the controller to perform
+ recovery.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - xlnx,magic
+
+additionalProperties: false
+
+examples:
+ - |
+ fault-inject@44a30000 {
+ compatible = "xlnx,tmr-inject-1.0";
+ reg = <0x44a10000 0x10000>;
+ xlnx,magic = <0x46>;
+ };
diff --git a/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml
new file mode 100644
index 000000000000..27de12147a52
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,tmr-manager.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,tmr-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Triple Modular Redundancy(TMR) Manager IP
+
+maintainers:
+ - Appana Durga Kedareswara rao <appana.durga.kedareswara.rao@amd.com>
+
+description: |
+ The Triple Modular Redundancy(TMR) Manager is responsible for handling the
+ TMR subsystem state, including fault detection and error recovery. The core
+ is triplicated in each of the sub-blocks in the TMR subsystem, and provides
+ majority voting of its internal state.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,tmr-manager-1.0
+
+ reg:
+ maxItems: 1
+
+ xlnx,magic1:
+ minimum: 0
+ maximum: 255
+ description:
+ Magic byte 1, When configured it allows the controller to perform
+ recovery.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - xlnx,magic1
+
+additionalProperties: false
+
+examples:
+ - |
+ tmr-manager@44a10000 {
+ compatible = "xlnx,tmr-manager-1.0";
+ reg = <0x44a10000 0x10000>;
+ xlnx,magic1 = <0x46>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
index 7803597b6366..9f3b1edacaa0 100644
--- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mmc/allwinner,sun4i-a10-mmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 MMC Controller Device Tree Bindings
+title: Allwinner A10 MMC Controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -30,38 +30,34 @@ properties:
- const: allwinner,sun50i-a100-emmc
- const: allwinner,sun50i-a100-mmc
- items:
- - const: allwinner,sun8i-a83t-mmc
+ - enum:
+ - allwinner,sun8i-a83t-mmc
+ - allwinner,suniv-f1c100s-mmc
- const: allwinner,sun7i-a20-mmc
- items:
- - const: allwinner,sun8i-r40-emmc
+ - enum:
+ - allwinner,sun8i-r40-emmc
+ - allwinner,sun50i-h5-emmc
+ - allwinner,sun50i-h6-emmc
- const: allwinner,sun50i-a64-emmc
- items:
- - const: allwinner,sun8i-r40-mmc
+ - enum:
+ - allwinner,sun8i-r40-mmc
+ - allwinner,sun50i-h5-mmc
+ - allwinner,sun50i-h6-mmc
- const: allwinner,sun50i-a64-mmc
- items:
- - const: allwinner,sun50i-h5-emmc
- - const: allwinner,sun50i-a64-emmc
- - items:
- - const: allwinner,sun50i-h5-mmc
- - const: allwinner,sun50i-a64-mmc
- - items:
- - const: allwinner,sun50i-h6-emmc
- - const: allwinner,sun50i-a64-emmc
- - items:
- - const: allwinner,sun50i-h6-mmc
- - const: allwinner,sun50i-a64-mmc
- - items:
- - const: allwinner,sun20i-d1-emmc
- - const: allwinner,sun50i-a100-emmc
- - items:
- - const: allwinner,sun50i-h616-emmc
+ - enum:
+ - allwinner,sun20i-d1-emmc
+ - allwinner,sun50i-h616-emmc
+ - allwinner,sun55i-a523-emmc
- const: allwinner,sun50i-a100-emmc
- items:
- const: allwinner,sun50i-h616-mmc
- const: allwinner,sun50i-a100-mmc
- items:
- - const: allwinner,suniv-f1c100s-mmc
- - const: allwinner,sun7i-a20-mmc
+ - const: allwinner,sun55i-a523-mmc
+ - const: allwinner,sun20i-d1-mmc
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
new file mode 100644
index 000000000000..57646575a13f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic SD / eMMC controller for S905/GXBB family SoCs
+
+description:
+ The MMC 5.1 compliant host controller on Amlogic provides the
+ interface for SD, eMMC and SDIO devices
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-axg-mmc
+ - items:
+ - const: amlogic,meson-gx-mmc
+ - const: amlogic,meson-gxbb-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: mmc controller instance
+ - description: card detect
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: core
+ - const: clkin0
+ - const: clkin1
+
+ resets:
+ maxItems: 1
+
+ amlogic,dram-access-quirk:
+ type: boolean
+ description:
+ set when controller's internal DMA engine cannot access the DRAM memory,
+ like on the G12A dedicated SDIO controller.
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mmc@70000 {
+ compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc";
+ reg = <0x70000 0x2000>;
+ interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clk_mmc>, <&xtal>, <&clk_div>;
+ clock-names = "core", "clkin0", "clkin1";
+ pinctrl-0 = <&emm_pins>;
+ resets = <&reset_mmc>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
deleted file mode 100644
index ccc5358db131..000000000000
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Amlogic SD / eMMC controller for S905/GXBB family SoCs
-
-The MMC 5.1 compliant host controller on Amlogic provides the
-interface for SD, eMMC and SDIO devices.
-
-This file documents the properties in addition to those available in
-the MMC core bindings, documented by mmc.txt.
-
-Required properties:
-- compatible : contains one of:
- - "amlogic,meson-gx-mmc"
- - "amlogic,meson-gxbb-mmc"
- - "amlogic,meson-gxl-mmc"
- - "amlogic,meson-gxm-mmc"
- - "amlogic,meson-axg-mmc"
-- clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
-- clock-names: Should contain the following:
- "core" - Main peripheral bus clock
- "clkin0" - Parent clock of internal mux
- "clkin1" - Other parent clock of internal mux
- The driver has an internal mux clock which switches between clkin0 and clkin1 depending on the
- clock rate requested by the MMC core.
-- resets : phandle of the internal reset line
-
-Optional properties:
-- amlogic,dram-access-quirk: set when controller's internal DMA engine cannot access the
- DRAM memory, like on the G12A dedicated SDIO controller.
-
-Example:
-
- sd_emmc_a: mmc@70000 {
- compatible = "amlogic,meson-gxbb-mmc";
- reg = <0x0 0x70000 0x0 0x2000>;
- interrupts = < GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clkc CLKID_SD_EMMC_A>, <&xtal>, <&clkc CLKID_FCLK_DIV2>;
- clock-names = "core", "clkin0", "clkin1";
- pinctrl-0 = <&emmc_pins>;
- resets = <&reset RESET_SD_EMMC_A>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
index 60955acb8e57..1a6cda82f296 100644
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mmc/amlogic,meson-mx-sdhc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Amlogic Meson SDHC controller Device Tree Bindings
+title: Amlogic Meson SDHC controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Martin Blumenstingl <martin.blumenstingl@googlemail.com>
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt
deleted file mode 100644
index 8765c605e6bc..000000000000
--- a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-* Amlogic Meson6, Meson8 and Meson8b SDIO/MMC controller
-
-The highspeed MMC host controller on Amlogic SoCs provides an interface
-for MMC, SD, SDIO and SDHC types of memory cards.
-
-Supported maximum speeds are the ones of the eMMC standard 4.41 as well
-as the speed of SD standard 2.0.
-
-The hardware provides an internal "mux" which allows up to three slots
-to be controlled. Only one slot can be accessed at a time.
-
-Required properties:
- - compatible : must be one of
- - "amlogic,meson8-sdio"
- - "amlogic,meson8b-sdio"
- along with the generic "amlogic,meson-mx-sdio"
- - reg : mmc controller base registers
- - interrupts : mmc controller interrupt
- - #address-cells : must be 1
- - size-cells : must be 0
- - clocks : phandle to clock providers
- - clock-names : must contain "core" and "clkin"
-
-Required child nodes:
-A node for each slot provided by the MMC controller is required.
-NOTE: due to a driver limitation currently only one slot (= child node)
- is supported!
-
-Required properties on each child node (= slot):
- - compatible : must be "mmc-slot" (see mmc.txt within this directory)
- - reg : the slot (or "port") ID
-
-Optional properties on each child node (= slot):
- - bus-width : must be 1 or 4 (8-bit bus is not supported)
- - for cd and all other additional generic mmc parameters
- please refer to mmc.txt within this directory
-
-Examples:
- mmc@c1108c20 {
- compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio";
- reg = <0xc1108c20 0x20>;
- interrupts = <0 28 1>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&clkc CLKID_SDIO>, <&clkc CLKID_CLK81>;
- clock-names = "core", "clkin";
-
- slot@1 {
- compatible = "mmc-slot";
- reg = <1>;
-
- bus-width = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml
new file mode 100644
index 000000000000..0d4d9ca6a8d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/amlogic,meson-mx-sdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson6, Meson8 and Meson8b SDIO/MMC controller
+
+description: |
+ The highspeed MMC host controller on Amlogic SoCs provides an interface
+ for MMC, SD, SDIO and SDHC types of memory cards.
+
+ Supported maximum speeds are the ones of the eMMC standard 4.41 as well
+ as the speed of SD standard 2.0.
+
+ The hardware provides an internal "mux" which allows up to three slots
+ to be controlled. Only one slot can be accessed at a time.
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - amlogic,meson8-sdio
+ - amlogic,meson8b-sdio
+ - const: amlogic,meson-mx-sdio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: clkin
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "slot@[0-2]$":
+ $ref: mmc-slot.yaml#
+ description:
+ A node for each slot provided by the MMC controller
+
+ properties:
+ reg:
+ enum: [0, 1, 2]
+
+ bus-width:
+ enum: [1, 4]
+
+ required:
+ - compatible
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mmc@c1108c20 {
+ compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio";
+ reg = <0xc1108c20 0x20>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clk_core>, <&clk_in>;
+ clock-names = "core", "clkin";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ slot@1 {
+ compatible = "mmc-slot";
+ reg = <1>;
+ bus-width = <4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
index 83be9e93d221..8e79de97b242 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml
@@ -1,16 +1,16 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device Tree Bindings for the Arasan SDHCI Controller
+title: Arasan SDHCI Controller
maintainers:
- Adrian Hunter <adrian.hunter@intel.com>
allOf:
- - $ref: "mmc-controller.yaml#"
+ - $ref: mmc-controller.yaml#
- if:
properties:
compatible:
@@ -27,6 +27,7 @@ allOf:
enum:
- xlnx,zynqmp-8.9a
- xlnx,versal-8.9a
+ - xlnx,versal-net-emmc
then:
properties:
clock-output-names:
@@ -37,6 +38,15 @@ allOf:
- items:
- const: clk_out_sd1
- const: clk_in_sd1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rzn1-sdhci
+ then:
+ properties:
+ interrupts:
+ minItems: 2
properties:
compatible:
@@ -45,6 +55,10 @@ properties:
- const: arasan,sdhci-4.9a # generic Arasan SDHCI 4.9a PHY
- const: arasan,sdhci-5.1 # generic Arasan SDHCI 5.1 PHY
- items:
+ - const: renesas,r9a06g032-sdhci # Renesas RZ/N1D SoC
+ - const: renesas,rzn1-sdhci # Renesas RZ/N1 family
+ - const: arasan,sdhci-8.9a
+ - items:
- const: rockchip,rk3399-sdhci-5.1 # rk3399 eMMC PHY
- const: arasan,sdhci-5.1
description:
@@ -62,6 +76,10 @@ properties:
description:
For this device it is strongly suggested to include
clock-output-names and '#clock-cells'.
+ - const: xlnx,versal-net-emmc # Versal Net eMMC PHY
+ description:
+ For this device it is strongly suggested to include
+ clock-output-names and '#clock-cells'.
- items:
- const: intel,lgm-sdhci-5.1-emmc # Intel LGM eMMC PHY
- const: arasan,sdhci-5.1
@@ -88,12 +106,6 @@ properties:
description:
For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
- - items:
- - const: intel,thunderbay-sdhci-5.1 # Intel Thunder Bay eMMC PHY
- - const: arasan,sdhci-5.1
- description:
- For this device it is strongly suggested to include
- clock-output-names and '#clock-cells'.
reg:
maxItems: 1
@@ -110,7 +122,14 @@ properties:
- const: gate
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: int
+ - const: wakeup
phys:
maxItems: 1
@@ -161,6 +180,12 @@ properties:
description:
The MIO bank number in which the command and data lines are configured.
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
dependencies:
'#clock-cells': [ clock-output-names ]
@@ -221,8 +246,8 @@ examples:
interrupt-parent = <&gic>;
interrupts = <0 48 4>;
reg = <0xff160000 0x1000>;
- clocks = <&clk200>, <&clk200>;
- clock-names = "clk_xin", "clk_ahb";
+ clocks = <&clk200>, <&clk200>, <&clk1200>;
+ clock-names = "clk_xin", "clk_ahb", "gate";
clock-output-names = "clk_out_sd0", "clk_in_sd0";
#clock-cells = <1>;
clk-phase-sd-hs = <63>, <72>;
@@ -234,8 +259,8 @@ examples:
interrupt-parent = <&gic>;
interrupts = <0 126 4>;
reg = <0xf1040000 0x10000>;
- clocks = <&clk200>, <&clk200>;
- clock-names = "clk_xin", "clk_ahb";
+ clocks = <&clk200>, <&clk200>, <&clk1200>;
+ clock-names = "clk_xin", "clk_ahb", "gate";
clock-output-names = "clk_out_sd0", "clk_in_sd0";
#clock-cells = <1>;
clk-phase-sd-hs = <132>, <60>;
@@ -309,22 +334,3 @@ examples:
<&scmi_clk KEEM_BAY_PSS_SD0>;
arasan,soc-ctl-syscon = <&sd0_phy_syscon>;
};
-
- - |
- #define EMMC_XIN_CLK
- #define EMMC_AXI_CLK
- #define TBH_PSS_EMMC_RST_N
- mmc@80420000 {
- compatible = "intel,thunderbay-sdhci-5.1", "arasan,sdhci-5.1";
- interrupts = <GIC_SPI 714 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x80420000 0x400>;
- clocks = <&scmi_clk EMMC_XIN_CLK>,
- <&scmi_clk EMMC_AXI_CLK>;
- clock-names = "clk_xin", "clk_ahb";
- phys = <&emmc_phy>;
- phy-names = "phy_arasan";
- assigned-clocks = <&scmi_clk EMMC_XIN_CLK>;
- clock-output-names = "emmc_cardclock";
- resets = <&rst_pss1 TBH_PSS_EMMC_RST_N>;
- #clock-cells = <0x0>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
index 1e69a5a42439..8f62e2c7fa64 100644
--- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
+++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml
@@ -53,10 +53,11 @@ properties:
items:
- const: arm,pl18x
- const: arm,primecell
- - description: Entry for STMicroelectronics variant of PL18x.
- This dedicated compatible is used by bootloaders.
+ - description: Entries for STMicroelectronics variant of PL18x.
items:
- - const: st,stm32-sdmmc2
+ - enum:
+ - st,stm32-sdmmc2
+ - st,stm32mp25-sdmmc2
- const: arm,pl18x
- const: arm,primecell
@@ -78,6 +79,10 @@ properties:
- const: rx
- const: tx
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
power-domains: true
resets:
@@ -95,7 +100,9 @@ properties:
PIO (polled I/O) interrupt and occurs when the FIFO needs to be
emptied as part of a bulk read from the card. Some variants have these
two interrupts wired into the same line (logic OR) and in that case
- only one interrupt may be provided.
+ only one interrupt may be provided. The interrupt-names property is
+ not used due to inconsistency of existing DTs regarding its content.
+ deprecated: false
minItems: 1
maxItems: 2
@@ -200,7 +207,7 @@ examples:
bus-width = <4>;
cap-sd-highspeed;
cap-mmc-highspeed;
- cd-gpios = <&gpio2 31 0x4>;
+ cd-gpios = <&gpio2 31 0x4>;
st,sig-dir-dat0;
st,sig-dir-dat2;
st,sig-dir-cmd;
diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
index 987b287f3bff..9fce8cd7b0b6 100644
--- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -42,6 +42,7 @@ patternProperties:
"^sdhci@[0-9a-f]+$":
type: object
$ref: mmc-controller.yaml
+ unevaluatedProperties: false
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml b/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml
new file mode 100644
index 000000000000..151b414b9d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/atmel,hsmci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel High-Speed MultiMedia Card Interface (HSMCI)
+
+description:
+ The Atmel HSMCI controller provides an interface for MMC, SD, and SDIO memory
+ cards.
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Aubin Constans <aubin.constans@microchip.com>
+
+allOf:
+ - $ref: mmc-controller.yaml
+
+properties:
+ compatible:
+ const: atmel,hsmci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rxtx
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mci_clk
+
+ "#address-cells":
+ const: 1
+ description: Used for slot IDs.
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "slot@[0-2]$":
+ $ref: mmc-slot.yaml
+ description: A slot node representing an MMC, SD, or SDIO slot.
+
+ properties:
+ reg:
+ enum: [0, 1]
+
+ required:
+ - reg
+ - bus-width
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - "#address-cells"
+ - "#size-cells"
+
+anyOf:
+ - required:
+ - slot@0
+ - required:
+ - slot@1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/at91.h>
+ mmc@f0008000 {
+ compatible = "atmel,hsmci";
+ reg = <0xf0008000 0x600>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mci0_clk>;
+ clock-names = "mci_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 15 0>;
+ cd-inverted;
+ };
+
+ slot@1 {
+ reg = <1>;
+ bus-width = <4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml b/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml
new file mode 100644
index 000000000000..ba75623b7778
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/atmel,sama5d2-sdhci.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/atmel,sama5d2-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel SDHCI controller
+
+maintainers:
+ - Aubin Constans <aubin.constans@microchip.com>
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+
+description:
+ Bindings for the SDHCI controller found in Atmel/Microchip SoCs.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,sama5d2-sdhci
+ - microchip,sam9x60-sdhci
+ - items:
+ - enum:
+ - microchip,sam9x7-sdhci
+ - microchip,sama7d65-sdhci
+ - microchip,sama7g5-sdhci
+ - const: microchip,sam9x60-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: hclock
+ - description: multclk
+ - description: baseclk
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: hclock
+ - const: multclk
+ - const: baseclk
+ minItems: 2
+
+ microchip,sdcal-inverted:
+ type: boolean
+ description:
+ When present, polarity on the SDCAL SoC pin is inverted. The default
+ polarity for this signal is described in the datasheet. For instance on
+ SAMA5D2, the pin is usually tied to the GND with a resistor and a
+ capacitor (see "SDMMC I/O Calibration" chapter).
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: sdhci-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,sama5d2-sdhci
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/at91.h>
+ mmc@a0000000 {
+ compatible = "atmel,sama5d2-sdhci";
+ reg = <0xa0000000 0x300>;
+ interrupts = <31 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&sdmmc0_hclk>, <&sdmmc0_gclk>, <&main>;
+ clock-names = "hclock", "multclk", "baseclk";
+ assigned-clocks = <&sdmmc0_gclk>;
+ assigned-clock-rates = <480000000>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
deleted file mode 100644
index 07ad02075a93..000000000000
--- a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Atmel High Speed MultiMedia Card Interface
-
-This controller on atmel products provides an interface for MMC, SD and SDIO
-types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the atmel-mci driver.
-
-1) MCI node
-
-Required properties:
-- compatible: should be "atmel,hsmci"
-- #address-cells: should be one. The cell is the slot id.
-- #size-cells: should be zero.
-- at least one slot node
-- clock-names: tuple listing input clock names.
- Required elements: "mci_clk"
-- clocks: phandles to input clocks.
-
-The node contains child nodes for each slot that the platform uses
-
-Example MCI node:
-
-mmc0: mmc@f0008000 {
- compatible = "atmel,hsmci";
- reg = <0xf0008000 0x600>;
- interrupts = <12 4>;
- #address-cells = <1>;
- #size-cells = <0>;
- clock-names = "mci_clk";
- clocks = <&mci0_clk>;
-
- [ child node definitions...]
-};
-
-2) slot nodes
-
-Required properties:
-- reg: should contain the slot id.
-- bus-width: number of data lines connected to the controller
-
-Optional properties:
-- cd-gpios: specify GPIOs for card detection
-- cd-inverted: invert the value of external card detect gpio line
-- wp-gpios: specify GPIOs for write protection
-
-Example slot node:
-
-slot@0 {
- reg = <0>;
- bus-width = <4>;
- cd-gpios = <&pioD 15 0>
- cd-inverted;
-};
-
-Example full MCI node:
-mmc0: mmc@f0008000 {
- compatible = "atmel,hsmci";
- reg = <0xf0008000 0x600>;
- interrupts = <12 4>;
- #address-cells = <1>;
- #size-cells = <0>;
- slot@0 {
- reg = <0>;
- bus-width = <4>;
- cd-gpios = <&pioD 15 0>
- cd-inverted;
- };
- slot@1 {
- reg = <1>;
- bus-width = <4>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt
deleted file mode 100644
index d876580ae3b8..000000000000
--- a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Broadcom BCM2835 SDHOST controller
-
-This file documents differences between the core properties described
-by mmc.txt and the properties that represent the BCM2835 controller.
-
-Required properties:
-- compatible: Should be "brcm,bcm2835-sdhost".
-- clocks: The clock feeding the SDHOST controller.
-
-Optional properties:
-- dmas: DMA channel for read and write.
- See Documentation/devicetree/bindings/dma/dma.txt for details
-
-Example:
-
-sdhost: mmc@7e202000 {
- compatible = "brcm,bcm2835-sdhost";
- reg = <0x7e202000 0x100>;
- interrupts = <2 24>;
- clocks = <&clocks BCM2835_CLOCK_VPU>;
- dmas = <&dma 13>;
- dma-names = "rx-tx";
-};
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml
new file mode 100644
index 000000000000..3a5a44800675
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhost.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/brcm,bcm2835-sdhost.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 SDHOST controller
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+allOf:
+ - $ref: mmc-controller.yaml
+
+properties:
+ compatible:
+ const: brcm,bcm2835-sdhost
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ sdhost: mmc@7e202000 {
+ compatible = "brcm,bcm2835-sdhost";
+ reg = <0x7e202000 0x100>;
+ interrupts = <2 24>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>;
+ dmas = <&dma 13>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt
deleted file mode 100644
index 7f5dd83f5bd9..000000000000
--- a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Broadcom BCM281xx SDHCI
-
-This file documents differences between the core properties in mmc.txt
-and the properties present in the bcm281xx SDHCI
-
-Required properties:
-- compatible : Should be "brcm,kona-sdhci"
-- DEPRECATED: compatible : Should be "bcm,kona-sdhci"
-- clocks: phandle + clock specifier pair of the external clock
-
-Refer to clocks/clock-bindings.txt for generic clock consumer properties.
-
-Example:
-
-sdio2: sdio@3f1a0000 {
- compatible = "brcm,kona-sdhci";
- reg = <0x3f1a0000 0x10000>;
- clocks = <&sdio3_clk>;
- interrupts = <0x0 74 0x4>;
-};
-
diff --git a/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml
new file mode 100644
index 000000000000..12eb3988f824
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,kona-sdhci.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/brcm,kona-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family SDHCI controller
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+allOf:
+ - $ref: sdhci-common.yaml#
+
+properties:
+ compatible:
+ const: brcm,kona-sdhci
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/bcm281xx.h>
+
+ mmc@3f1a0000 {
+ compatible = "brcm,kona-sdhci";
+ reg = <0x3f1a0000 0x10000>;
+ clocks = <&master_ccu BCM281XX_MASTER_CCU_SDIO3>;
+ interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
index dead421e17d6..0936bfef8c75 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/brcm,sdhci-brcmstb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BRCMSTB/BMIPS SDHCI Controller binding
+title: Broadcom BRCMSTB/BMIPS SDHCI Controller
maintainers:
- Al Cooper <alcooperx@gmail.com>
@@ -20,11 +20,12 @@ properties:
- const: brcm,sdhci-brcmstb
- items:
- enum:
+ - brcm,bcm2712-sdhci
+ - brcm,bcm72116-sdhci
+ - brcm,bcm74165b0-sdhci
- brcm,bcm7445-sdhci
- - const: brcm,sdhci-brcmstb
- - items:
- - enum:
- brcm,bcm7425-sdhci
+ - brcm,bcm74371-sdhci
- const: brcm,sdhci-brcmstb
reg:
@@ -62,7 +63,7 @@ properties:
description: Specifies that controller should use auto CMD12
allOf:
- - $ref: mmc-controller.yaml#
+ - $ref: sdhci-common.yaml#
- if:
properties:
clock-names:
diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
index 8b1a0fdcb5e3..ac75d694611a 100644
--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -9,19 +9,20 @@ title: Cadence SD/SDIO/eMMC Host Controller (SD4HC)
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
-allOf:
- - $ref: mmc-controller.yaml
-
properties:
compatible:
items:
- enum:
+ - amd,pensando-elba-sd4hc
- microchip,mpfs-sd4hc
+ - microchip,pic64gx-sd4hc
+ - mobileye,eyeq-sd4hc
- socionext,uniphier-sd4hc
- const: cdns,sd4hc
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
interrupts:
maxItems: 1
@@ -29,6 +30,9 @@ properties:
clocks:
maxItems: 1
+ resets:
+ maxItems: 1
+
# PHY DLL input delays:
# They are used to delay the data valid window, and align the window to
# sampling clock. The delay starts from 5ns (for delay parameter equal to 0)
@@ -36,43 +40,43 @@ properties:
cdns,phy-input-delay-sd-highspeed:
description: Value of the delay in the input path for SD high-speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-legacy:
description: Value of the delay in the input path for legacy timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-sdr12:
description: Value of the delay in the input path for SD UHS SDR12 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-sdr25:
description: Value of the delay in the input path for SD UHS SDR25 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-sdr50:
description: Value of the delay in the input path for SD UHS SDR50 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-sd-uhs-ddr50:
description: Value of the delay in the input path for SD UHS DDR50 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
cdns,phy-input-delay-mmc-highspeed:
description: Value of the delay in the input path for MMC high-speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
@@ -83,7 +87,7 @@ properties:
# Each delay property represents the fraction of the clock period.
# The approximate delay value will be
# (<delay property value>/128)*sdmclk_clock_period.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
@@ -91,7 +95,7 @@ properties:
description: |
Value of the delay introduced on the sdclk output for all modes except
HS200, HS400 and HS400_ES.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7f
@@ -99,7 +103,7 @@ properties:
description: |
Value of the delay introduced on the sdclk output for HS200, HS400 and
HS400_ES speed modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7f
@@ -107,7 +111,7 @@ properties:
description: |
Value of the delay introduced on the dat_strobe input used in
HS400 / HS400_ES speed modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7f
@@ -117,6 +121,26 @@ required:
- interrupts
- clocks
+allOf:
+ - $ref: sdhci-common.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amd,pensando-elba-sd4hc
+ then:
+ properties:
+ reg:
+ items:
+ - description: Host controller registers
+ - description: Elba byte-lane enable register for writes
+ required:
+ - resets
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
deleted file mode 100644
index 516fb0143d4c..000000000000
--- a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* TI Highspeed MMC host controller for DaVinci
-
-The Highspeed MMC Host Controller on TI DaVinci family
-provides an interface for MMC, SD and SDIO types of memory cards.
-
-This file documents the properties used by the davinci_mmc driver.
-
-Required properties:
-- compatible:
- Should be "ti,da830-mmc": for da830, da850, dm365
- Should be "ti,dm355-mmc": for dm355, dm644x
-
-Optional properties:
-- bus-width: Number of data lines, can be <1>, <4>, or <8>, default <1>
-- max-frequency: Maximum operating clock frequency, default 25MHz.
-- dmas: List of DMA specifiers with the controller specific format
- as described in the generic DMA client binding. A tx and rx
- specifier is required.
-- dma-names: RX and TX DMA request names. These strings correspond
- 1:1 with the DMA specifiers listed in dmas.
-
-Example:
-mmc0: mmc@1c40000 {
- compatible = "ti,da830-mmc",
- reg = <0x40000 0x1000>;
- interrupts = <16>;
- bus-width = <4>;
- max-frequency = <50000000>;
- dmas = <&edma 16
- &edma 17>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl,esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl,esdhc.yaml
new file mode 100644
index 000000000000..f45e592901e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl,esdhc.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl,esdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Secure Digital Host Controller (eSDHC)
+
+description:
+ The Enhanced Secure Digital Host Controller provides an interface
+ for MMC, SD, and SDIO types of memory cards.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc8536-esdhc
+ - fsl,mpc8378-esdhc
+ - fsl,p2020-esdhc
+ - fsl,p4080-esdhc
+ - fsl,t1040-esdhc
+ - fsl,t4240-esdhc
+ - fsl,ls1012a-esdhc
+ - fsl,ls1021a-esdhc
+ - fsl,ls1028a-esdhc
+ - fsl,ls1088a-esdhc
+ - fsl,ls1043a-esdhc
+ - fsl,ls1046a-esdhc
+ - fsl,ls2080a-esdhc
+ - const: fsl,esdhc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: specifies eSDHC base clock frequency.
+
+ sdhci,wp-inverted:
+ $ref: /schemas/types.yaml#/definitions/flag
+ deprecated: true
+ description:
+ specifies that eSDHC controller reports
+ inverted write-protect state; New devices should use the generic
+ "wp-inverted" property.
+
+ sdhci,1-bit-only:
+ $ref: /schemas/types.yaml#/definitions/flag
+ deprecated: true
+ description:
+ specifies that a controller can only handle
+ 1-bit data transfers. New devices should use the generic
+ "bus-width = <1>" property.
+
+ sdhci,auto-cmd12:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ specifies that a controller can only handle auto CMD12.
+
+ voltage-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: specifies minimum slot voltage (mV).
+ - description: specifies maximum slot voltage (mV).
+ minItems: 1
+ maxItems: 8
+
+ dma-coherent: true
+
+ little-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If the host controller is little-endian mode, specify
+ this property. The default endian mode is big-endian.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: sdhci-common.yaml#
+ - $ref: mmc-controller-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@2e000 {
+ compatible = "fsl,mpc8378-esdhc", "fsl,esdhc";
+ reg = <0x2e000 0x1000>;
+ interrupts = <42 0x8>;
+ interrupt-parent = <&ipic>;
+ /* Filled in by U-Boot */
+ clock-frequency = <100000000>;
+ voltage-ranges = <3300 3300>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
deleted file mode 100644
index edb8cadb9541..000000000000
--- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-* Freescale Enhanced Secure Digital Host Controller (eSDHC)
-
-The Enhanced Secure Digital Host Controller provides an interface
-for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-esdhc driver.
-
-Required properties:
- - compatible : should be "fsl,esdhc", or "fsl,<chip>-esdhc".
- Possible compatibles for PowerPC:
- "fsl,mpc8536-esdhc"
- "fsl,mpc8378-esdhc"
- "fsl,p2020-esdhc"
- "fsl,p4080-esdhc"
- "fsl,t1040-esdhc"
- "fsl,t4240-esdhc"
- Possible compatibles for ARM:
- "fsl,ls1012a-esdhc"
- "fsl,ls1028a-esdhc"
- "fsl,ls1088a-esdhc"
- "fsl,ls1043a-esdhc"
- "fsl,ls1046a-esdhc"
- "fsl,ls2080a-esdhc"
- - clock-frequency : specifies eSDHC base clock frequency.
-
-Optional properties:
- - sdhci,wp-inverted : specifies that eSDHC controller reports
- inverted write-protect state; New devices should use the generic
- "wp-inverted" property.
- - sdhci,1-bit-only : specifies that a controller can only handle
- 1-bit data transfers. New devices should use the generic
- "bus-width = <1>" property.
- - sdhci,auto-cmd12: specifies that a controller can only handle auto
- CMD12.
- - voltage-ranges : two cells are required, first cell specifies minimum
- slot voltage (mV), second cell specifies maximum slot voltage (mV).
- Several ranges could be specified.
- - little-endian : If the host controller is little-endian mode, specify
- this property. The default endian mode is big-endian.
-
-Example:
-
-sdhci@2e000 {
- compatible = "fsl,mpc8378-esdhc", "fsl,esdhc";
- reg = <0x2e000 0x1000>;
- interrupts = <42 0x8>;
- interrupt-parent = <&ipic>;
- /* Filled in by U-Boot */
- clock-frequency = <0>;
- voltage-ranges = <3300 3300>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index 29339d0196ec..b98a84f93277 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -10,7 +10,7 @@ maintainers:
- Shawn Guo <shawnguo@kernel.org>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: sdhci-common.yaml#
description: |
The Enhanced Secure Digital Host Controller on Freescale i.MX family
@@ -29,15 +29,25 @@ properties:
- fsl,imx53-esdhc
- fsl,imx6q-usdhc
- fsl,imx6sl-usdhc
- - fsl,imx6sll-usdhc
- fsl,imx6sx-usdhc
- - fsl,imx6ull-usdhc
- fsl,imx7d-usdhc
- fsl,imx7ulp-usdhc
- fsl,imx8mm-usdhc
- fsl,imxrt1050-usdhc
- nxp,s32g2-usdhc
- items:
+ - const: fsl,imx50-esdhc
+ - const: fsl,imx53-esdhc
+ - items:
+ - enum:
+ - fsl,imx6sll-usdhc
+ - fsl,imx6ull-usdhc
+ - fsl,imx6ul-usdhc
+ - const: fsl,imx6sx-usdhc
+ - items:
+ - const: fsl,imx7d-usdhc
+ - const: fsl,imx6sl-usdhc
+ - items:
- enum:
- fsl,imx8mq-usdhc
- const: fsl,imx7d-usdhc
@@ -45,16 +55,18 @@ properties:
- enum:
- fsl,imx8mn-usdhc
- fsl,imx8mp-usdhc
- - fsl,imx93-usdhc
- fsl,imx8ulp-usdhc
+ - fsl,imx93-usdhc
+ - fsl,imx94-usdhc
+ - fsl,imx95-usdhc
- const: fsl,imx8mm-usdhc
- items:
- enum:
+ - fsl,imx8dxl-usdhc
- fsl,imx8qm-usdhc
- const: fsl,imx8qxp-usdhc
- items:
- enum:
- - fsl,imx8dxl-usdhc
- fsl,imx8mm-usdhc
- fsl,imx8mn-usdhc
- fsl,imx8mp-usdhc
@@ -71,10 +83,18 @@ properties:
deprecated: true
- items:
- enum:
+ - fsl,imx8dxl-usdhc
- fsl,imx8qm-usdhc
- const: fsl,imx8qxp-usdhc
- const: fsl,imx7d-usdhc
deprecated: true
+ - items:
+ - enum:
+ - fsl,imxrt1170-usdhc
+ - const: fsl,imxrt1050-usdhc
+ - items:
+ - const: nxp,s32g3-usdhc
+ - const: nxp,s32g2-usdhc
reg:
maxItems: 1
@@ -93,12 +113,12 @@ properties:
Specify the number of delay cells for override mode.
This is used to set the clock delay for DLL(Delay Line) on override mode
to select a proper data sampling window in case the clock quality is not good
- due to signal path is too long on the board. Please refer to eSDHC/uSDHC
+ because the signal path is too long on the board. Please refer to eSDHC/uSDHC
chapter, DLL (Delay Line) section in RM for details.
default: 0
voltage-ranges:
- $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
description: |
Specify the voltage range in case there are software transparent level
shifters on the outputs of the controller. Two cells are required, first
@@ -122,7 +142,7 @@ properties:
Specify the increasing delay cell steps in tuning procedure.
The uSDHC use one delay cell as default increasing step to do tuning process.
This property allows user to change the tuning step to more than one delay
- cells which is useful for some special boards or cards when the default
+ cell which is useful for some special boards or cards when the default
tuning step can't find the proper delay window within limited tuning retries.
default: 0
@@ -147,6 +167,9 @@ properties:
- const: ahb
- const: per
+ iommus:
+ maxItems: 1
+
power-domains:
maxItems: 1
@@ -158,6 +181,11 @@ properties:
- const: state_100mhz
- const: state_200mhz
- const: sleep
+ - minItems: 2
+ items:
+ - const: default
+ - const: state_100mhz
+ - const: sleep
- minItems: 1
items:
- const: default
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
index ffa162722b8e..7911316fbd6a 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml
@@ -10,7 +10,7 @@ maintainers:
- Markus Pargmann <mpa@pengutronix.de>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
properties:
compatible:
@@ -24,6 +24,14 @@ properties:
reg:
maxItems: 1
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: per
+
interrupts:
maxItems: 1
@@ -34,6 +42,8 @@ properties:
const: rx-tx
required:
+ - clocks
+ - clock-names
- compatible
- reg
- interrupts
@@ -46,6 +56,8 @@ examples:
compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
reg = <0x10014000 0x1000>;
interrupts = <11>;
+ clocks = <&clks 29>, <&clks 60>;
+ clock-names = "ipg", "per";
dmas = <&dma 7>;
dma-names = "rx-tx";
bus-width = <4>;
diff --git a/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml b/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml
new file mode 100644
index 000000000000..430b62899397
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fujitsu,sdhci-fujitsu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fujitsu/Socionext SDHCI controller (F_SDH30)
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: socionext,synquacer-sdhci
+ - const: fujitsu,mb86s70-sdhci-3.0
+ - enum:
+ - fujitsu,mb86s70-sdhci-3.0
+ - socionext,f-sdh30-e51-mmc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: iface
+ - const: core
+
+ dma-coherent: true
+
+ interrupts:
+ maxItems: 2
+
+ resets:
+ maxItems: 1
+
+ fujitsu,cmd-dat-delay-select:
+ type: boolean
+ description: |
+ Indicating that this host requires the CMD_DAT_DELAY control to be enabled
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ sdhci1: mmc@36600000 {
+ compatible = "fujitsu,mb86s70-sdhci-3.0";
+ reg = <0x36600000 0x1000>;
+ bus-width = <4>;
+ vqmmc-supply = <&vccq_sdhci1>;
+ clocks = <&clock 2 2 0>, <&clock 2 3 0>;
+ clock-names = "iface", "core";
+ };
diff --git a/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
deleted file mode 100644
index a0693b7145f2..000000000000
--- a/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-* Hisilicon Hi3798CV200 specific extensions to the Synopsys Designware Mobile
- Storage Host Controller
-
-Read synopsys-dw-mshc.txt for more details
-
-The Synopsys designware mobile storage host controller is used to interface
-a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
-differences between the core Synopsys dw mshc controller properties described
-by synopsys-dw-mshc.txt and the properties used by the Hisilicon Hi3798CV200
-specific extensions to the Synopsys Designware Mobile Storage Host Controller.
-
-Required Properties:
-- compatible: Should contain "hisilicon,hi3798cv200-dw-mshc".
-- clocks: A list of phandle + clock-specifier pairs for the clocks listed
- in clock-names.
-- clock-names: Should contain the following:
- "ciu" - The ciu clock described in synopsys-dw-mshc.txt.
- "biu" - The biu clock described in synopsys-dw-mshc.txt.
- "ciu-sample" - Hi3798CV200 extended phase clock for ciu sampling.
- "ciu-drive" - Hi3798CV200 extended phase clock for ciu driving.
-
-Example:
-
- emmc: mmc@9830000 {
- compatible = "hisilicon,hi3798cv200-dw-mshc";
- reg = <0x9830000 0x10000>;
- interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&crg HISTB_MMC_CIU_CLK>,
- <&crg HISTB_MMC_BIU_CLK>,
- <&crg HISTB_MMC_SAMPLE_CLK>,
- <&crg HISTB_MMC_DRV_CLK>;
- clock-names = "ciu", "biu", "ciu-sample", "ciu-drive";
- fifo-depth = <256>;
- clock-frequency = <200000000>;
- cap-mmc-highspeed;
- mmc-ddr-1_8v;
- mmc-hs200-1_8v;
- non-removable;
- bus-width = <8>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
new file mode 100644
index 000000000000..41c9b22523e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/hisilicon,hi3798cv200-dw-mshc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon HiSTB SoCs specific extensions to the Synopsys DWMMC controller
+
+maintainers:
+ - Yang Xiwen <forbidden405@outlook.com>
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,hi3798cv200-dw-mshc
+ - hisilicon,hi3798mv200-dw-mshc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: bus interface unit clock
+ - description: card interface unit clock
+ - description: card input sample phase clock
+ - description: controller output drive phase clock
+
+ clock-names:
+ items:
+ - const: ciu
+ - const: biu
+ - const: ciu-sample
+ - const: ciu-drive
+
+ hisilicon,sap-dll-reg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ DWMMC core on Hi3798MV2x SoCs has a delay-locked-loop(DLL) attached to card data input path.
+ It is integrated into CRG core on the SoC and has to be controlled during tuning.
+ items:
+ - description: A phandle pointed to the CRG syscon node
+ - description: Sample DLL register offset in CRG address space
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: synopsys-dw-mshc-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: hisilicon,hi3798mv200-dw-mshc
+ then:
+ required:
+ - hisilicon,sap-dll-reg
+ else:
+ properties:
+ hisilicon,sap-dll-reg: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/histb-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mmc@9830000 {
+ compatible = "hisilicon,hi3798cv200-dw-mshc";
+ reg = <0x9830000 0x10000>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&crg HISTB_MMC_CIU_CLK>,
+ <&crg HISTB_MMC_BIU_CLK>,
+ <&crg HISTB_MMC_SAMPLE_CLK>,
+ <&crg HISTB_MMC_DRV_CLK>;
+ clock-names = "ciu", "biu", "ciu-sample", "ciu-drive";
+ resets = <&crg 0xa0 4>;
+ reset-names = "reset";
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_pins_1 &emmc_pins_2
+ &emmc_pins_3 &emmc_pins_4>;
+ fifo-depth = <256>;
+ clock-frequency = <200000000>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ non-removable;
+ bus-width = <8>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml
index 2d10aedf2e00..bb4e0be0c893 100644
--- a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/ingenic,mmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs MMC Controller DT bindings
+title: Ingenic SoCs MMC Controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml b/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml
new file mode 100644
index 000000000000..c142421bc723
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/loongson,ls2k0500-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The SD/SDIO/eMMC host controller for Loongson-2K family SoCs
+
+description:
+ The MMC host controller on the Loongson-2K0500/2K1000 (using an externally
+ shared apbdma controller) provides the SD and SDIO device interfaces.
+ The two MMC host controllers on the Loongson-2K2000 are similar,
+ except that they use internal exclusive DMA. one controller provides
+ the eMMC interface and the other provides the SD/SDIO interface.
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls2k0500-mmc
+ - loongson,ls2k1000-mmc
+ - loongson,ls2k2000-mmc
+
+ reg:
+ minItems: 1
+ items:
+ - description: Loongson-2K MMC controller registers.
+ - description: APB DMA config register for Loongson-2K MMC controller.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - loongson,ls2k0500-mmc
+ - loongson,ls2k1000-mmc
+
+then:
+ properties:
+ reg:
+ minItems: 2
+
+ required:
+ - dmas
+ - dma-names
+
+else:
+ properties:
+ reg:
+ maxItems: 1
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/loongson,ls2k-clk.h>
+
+ mmc@1fe2c000 {
+ compatible = "loongson,ls2k1000-mmc";
+ reg = <0x1fe2c000 0x68>,
+ <0x1fe00438 0x8>;
+ interrupt-parent = <&liointc0>;
+ interrupts = <31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LOONGSON2_APB_CLK>;
+ dmas = <&apbdma1 0>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ cd-gpios = <&gpio0 22 GPIO_ACTIVE_LOW>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/loongson,ls2k-clk.h>
+
+ mmc@79990000 {
+ compatible = "loongson,ls2k2000-mmc";
+ reg = <0x79990000 0x1000>;
+ interrupt-parent = <&pic>;
+ interrupts = <51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LOONGSON2_EMMC_CLK>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ no-sd;
+ no-sdio;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
index 3ee758886558..ee2ddef36369 100644
--- a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.yaml
@@ -27,7 +27,9 @@ properties:
- marvell,armada-ap806-sdhci
- items:
- - const: marvell,armada-ap807-sdhci
+ - enum:
+ - marvell,armada-ap807-sdhci
+ - marvell,ac5-sdhci
- const: marvell,armada-ap806-sdhci
- items:
@@ -36,15 +38,9 @@ properties:
reg:
minItems: 1
- maxItems: 2
- description: |
- For "marvell,armada-3700-sdhci", two register areas. The first one
- for Xenon IP register. The second one for the Armada 3700 SoC PHY PAD
- Voltage Control register. Please follow the examples with compatible
- "marvell,armada-3700-sdhci" in below.
- Please also check property marvell,pad-type in below.
-
- For other compatible strings, one register area for Xenon IP.
+ items:
+ - description: Xenon IP registers
+ - description: Armada 3700 SoC PHY PAD Voltage Control register
clocks:
minItems: 1
@@ -56,9 +52,25 @@ properties:
- const: core
- const: axi
+ dma-coherent: true
+
interrupts:
maxItems: 1
+ iommus:
+ maxItems: 1
+
+ marvell,pad-type:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - sd
+ - fixed-1-8v
+ description:
+ Type of Armada 3700 SoC PHY PAD Voltage Controller register. If "sd" is
+ selected, SoC PHY PAD is set as 3.3V at the beginning and is switched to
+ 1.8V when later in higher speed mode. If "fixed-1-8v" is selected, SoC PHY
+ PAD is fixed 1.8V, such as for eMMC.
+
marvell,xenon-sdhc-id:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
@@ -71,8 +83,8 @@ properties:
marvell,xenon-phy-type:
$ref: /schemas/types.yaml#/definitions/string
enum:
- - "emmc 5.1 phy"
- - "emmc 5.0 phy"
+ - emmc 5.1 phy
+ - emmc 5.0 phy
description: |
Xenon support multiple types of PHYs. To select eMMC 5.1 PHY, set:
marvell,xenon-phy-type = "emmc 5.1 phy" eMMC 5.1 PHY is the default
@@ -135,7 +147,7 @@ properties:
This property provides the re-tuning counter.
allOf:
- - $ref: mmc-controller.yaml#
+ - $ref: sdhci-common.yaml#
- if:
properties:
compatible:
@@ -145,46 +157,17 @@ allOf:
then:
properties:
reg:
- items:
- - description: Xenon IP registers
- - description: Armada 3700 SoC PHY PAD Voltage Control register
-
- marvell,pad-type:
- $ref: /schemas/types.yaml#/definitions/string
- enum:
- - sd
- - fixed-1-8v
- description: |
- Type of Armada 3700 SoC PHY PAD Voltage Controller register.
- If "sd" is selected, SoC PHY PAD is set as 3.3V at the beginning
- and is switched to 1.8V when later in higher speed mode.
- If "fixed-1-8v" is selected, SoC PHY PAD is fixed 1.8V, such as for
- eMMC.
- Please follow the examples with compatible
- "marvell,armada-3700-sdhci" in below.
+ minItems: 2
required:
- marvell,pad-type
- - if:
+ else:
properties:
- compatible:
- contains:
- enum:
- - marvell,armada-cp110-sdhci
- - marvell,armada-ap807-sdhci
- - marvell,armada-ap806-sdhci
-
- then:
- properties:
- clocks:
- minItems: 2
-
- clock-names:
- items:
- - const: core
- - const: axi
+ reg:
+ maxItems: 1
+ marvell,pad-type: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
index 69ff065c9a39..1f63faf17743 100644
--- a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/mmc/microchip,dw-sparx5-sdhci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip Sparx5 Mobile Storage Host Controller Binding
+title: Microchip Sparx5 Mobile Storage Host Controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Lars Povlsen <lars.povlsen@microchip.com>
@@ -35,7 +35,7 @@ properties:
microchip,clock-delay:
description: Delay clock to card to meet setup time requirements.
Each step increase by 1.25ns.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 15
diff --git a/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt b/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
deleted file mode 100644
index f064528effed..000000000000
--- a/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Microchip PIC32 SDHCI Controller
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the sdhci-pic32 driver.
-
-Required properties:
-- compatible: Should be "microchip,pic32mzda-sdhci"
-- interrupts: Should contain interrupt
-- clock-names: Should be "base_clk", "sys_clk".
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the SDHCI controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-Example:
-
- sdhci@1f8ec000 {
- compatible = "microchip,pic32mzda-sdhci";
- reg = <0x1f8ec000 0x100>;
- interrupts = <191 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&rootclk REF4CLK>, <&rootclk PB5CLK>;
- clock-names = "base_clk", "sys_clk";
- bus-width = <4>;
- cap-sd-highspeed;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sdhc1>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.yaml b/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.yaml
new file mode 100644
index 000000000000..ca0ca7df9ee9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/microchip,sdhci-pic32.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/microchip,sdhci-pic32.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 SDHI Controller
+
+description:
+ The Microchip PIC32 family of microcontrollers (MCUs) includes models with
+ Secure Digital Host Controller Interface (SDHCI) controllers, allowing them
+ to interface with Secure Digital (SD) cards. This interface is used for reading,
+ writing, and managing data on SD cards, enabling storage and data transfer
+ capabilities in embedded systems.
+
+allOf:
+ - $ref: mmc-controller.yaml
+
+maintainers:
+ - Ulf Hansson <ulf.hansson@linaro.org>
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: base_clk
+ - const: sys_clk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - pinctrl-names
+ - pinctrl-0
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+ mmc@1f8ec000 {
+ compatible = "microchip,pic32mzda-sdhci";
+ reg = <0x1f8ec000 0x100>;
+ interrupts = <191 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rootclk REF4CLK>, <&rootclk PB5CLK>;
+ clock-names = "base_clk", "sys_clk";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sdhc1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index b17d454442b3..1d91d4272de0 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/mmc-card.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MMC Card / eMMC Generic Device Tree Bindings
+title: MMC Card / eMMC Generic
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -13,6 +13,10 @@ description: |
This documents describes the devicetree bindings for a mmc-host controller
child node describing a mmc-card / an eMMC.
+ It's possible to define a fixed partition table for an eMMC for the user
+ partition, the 2 BOOT partition (boot1/2) and the 4 GP (gp1/2/3/4) if supported
+ by the eMMC.
+
properties:
compatible:
const: mmc-card
@@ -26,6 +30,24 @@ properties:
Use this to indicate that the mmc-card has a broken hpi
implementation, and that hpi should not be used.
+patternProperties:
+ "^partitions(-boot[12]|-gp[14])?$":
+ $ref: /schemas/mtd/partitions/partitions.yaml
+
+ patternProperties:
+ "^partition@[0-9a-f]+$":
+ $ref: /schemas/mtd/partitions/partition.yaml
+
+ properties:
+ reg:
+ description: Must be multiple of 512 as it's converted
+ internally from bytes to SECTOR_SIZE (512 bytes)
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -42,6 +64,36 @@ examples:
compatible = "mmc-card";
reg = <0>;
broken-hpi;
+
+ partitions {
+ compatible = "fixed-partitions";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "kernel"; /* Kernel */
+ reg = <0x0 0x2000000>; /* 32 MB */
+ };
+
+ partition@2000000 {
+ label = "rootfs";
+ reg = <0x2000000 0x40000000>; /* 1GB */
+ };
+ };
+
+ partitions-boot1 {
+ compatible = "fixed-partitions";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bl";
+ reg = <0x0 0x2000000>; /* 32MB */
+ read-only;
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
new file mode 100644
index 000000000000..3d7195e9461c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -0,0 +1,365 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mmc-controller-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MMC Controller & Slots Common Properties
+
+maintainers:
+ - Ulf Hansson <ulf.hansson@linaro.org>
+
+description:
+ These properties are common to multiple MMC host controllers and the
+ possible slots or ports for multi-slot controllers.
+
+properties:
+ "#address-cells":
+ const: 1
+ description:
+ The cell is the SDIO function number if a function subnode is used.
+
+ "#size-cells":
+ const: 0
+
+ # Card Detection.
+ # If none of these properties are supplied, the host native card
+ # detect will be used. Only one of them should be provided.
+
+ broken-cd:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ There is no card detection available; polling must be used.
+
+ cd-gpios:
+ maxItems: 1
+ description:
+ The card detection will be done using the GPIO provided.
+
+ non-removable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Non-removable slot (like eMMC); assume always present.
+
+ # *NOTE* on CD and WP polarity. To use common for all SD/MMC host
+ # controllers line polarity properties, we have to fix the meaning
+ # of the "normal" and "inverted" line levels. We choose to follow
+ # the SDHCI standard, which specifies both those lines as "active
+ # low." Therefore, using the "cd-inverted" property means, that the
+ # CD line is active high, i.e. it is high, when a card is
+ # inserted. Similar logic applies to the "wp-inverted" property.
+ #
+ # CD and WP lines can be implemented on the hardware in one of two
+ # ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or
+ # as dedicated pins. Polarity of dedicated pins can be specified,
+ # using *-inverted properties. GPIO polarity can also be specified
+ # using the GPIO_ACTIVE_LOW flag. This creates an ambiguity in the
+ # latter case. We choose to use the XOR logic for GPIO CD and WP
+ # lines. This means, the two properties are "superimposed," for
+ # example leaving the GPIO_ACTIVE_LOW flag clear and specifying the
+ # respective *-inverted property results in a
+ # double-inversion and actually means the "normal" line polarity is
+ # in effect.
+ wp-inverted:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The Write Protect line polarity is inverted.
+
+ cd-inverted:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The CD line polarity is inverted.
+
+ # Other properties
+
+ bus-width:
+ description:
+ Number of data lines.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 4, 8]
+ default: 1
+
+ max-frequency:
+ description: |
+ Maximum operating frequency of the bus:
+ - for eMMC, the maximum supported frequency is 200MHz,
+ - for SD/SDIO cards the SDR104 mode has a max supported
+ frequency of 208MHz,
+ - some mmc host controllers do support a max frequency up to
+ 384MHz.
+ So, lets keep the maximum supported value here.
+
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 400000
+ maximum: 384000000
+
+ max-sd-hs-hz:
+ description: |
+ Maximum frequency (in Hz) to be used for SD cards operating in
+ High-Speed (HS) mode.
+ minimum: 400000
+ maximum: 50000000
+ default: 50000000
+
+ disable-wp:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ When set, no physical write-protect line is present. This
+ property should only be specified when the controller has a
+ dedicated write-protect detection logic. If a GPIO is always used
+ for the write-protect detection logic, it is sufficient to not
+ specify the wp-gpios property in the absence of a write-protect
+ line. Not used in combination with eMMC or SDIO.
+
+ wp-gpios:
+ maxItems: 1
+ description:
+ GPIO to use for the write-protect detection.
+
+ cd-debounce-delay-ms:
+ description:
+ Set delay time before detecting card after card insert
+ interrupt.
+
+ no-1-8-v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ When specified, denotes that 1.8V card voltage is not supported
+ on this system, even if the controller claims it.
+
+ cap-sd-highspeed:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SD high-speed timing is supported.
+
+ cap-mmc-highspeed:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ MMC high-speed timing is supported.
+
+ sd-uhs-sdr12:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SD UHS SDR12 speed is supported.
+
+ sd-uhs-sdr25:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SD UHS SDR25 speed is supported.
+
+ sd-uhs-sdr50:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SD UHS SDR50 speed is supported.
+
+ sd-uhs-sdr104:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SD UHS SDR104 speed is supported.
+
+ sd-uhs-ddr50:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SD UHS DDR50 speed is supported.
+
+ cap-power-off-card:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Powering off the card is safe.
+
+ cap-mmc-hw-reset:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC hardware reset is supported
+
+ cap-sdio-irq:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ enable SDIO IRQ signalling on this interface
+
+ full-pwr-cycle:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Full power cycle of the card is supported.
+
+ full-pwr-cycle-in-suspend:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Full power cycle of the card in suspend is supported.
+
+ mmc-ddr-1_2v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC high-speed DDR mode (1.2V I/O) is supported.
+
+ mmc-ddr-1_8v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC high-speed DDR mode (1.8V I/O) is supported.
+
+ mmc-ddr-3_3v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC high-speed DDR mode (3.3V I/O) is supported.
+
+ mmc-hs200-1_2v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC HS200 mode (1.2V I/O) is supported.
+
+ mmc-hs200-1_8v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC HS200 mode (1.8V I/O) is supported.
+
+ mmc-hs400-1_2v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC HS400 mode (1.2V I/O) is supported.
+
+ mmc-hs400-1_8v:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC HS400 mode (1.8V I/O) is supported.
+
+ mmc-hs400-enhanced-strobe:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ eMMC HS400 enhanced strobe mode is supported
+
+ no-mmc-hs400:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ All eMMC HS400 modes are not supported.
+
+ dsr:
+ description:
+ Value the card Driver Stage Register (DSR) should be programmed
+ with.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0xffff
+
+ no-sdio:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Controller is limited to send SDIO commands during
+ initialization.
+
+ no-sd:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Controller is limited to send SD commands during initialization.
+
+ no-mmc:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Controller is limited to send MMC commands during
+ initialization.
+
+ fixed-emmc-driver-type:
+ description:
+ For non-removable eMMC, enforce this driver type. The value is
+ the driver type as specified in the eMMC specification (table
+ 206 in spec version 5.1)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 4
+
+ post-power-on-delay-ms:
+ description:
+ It was invented for MMC pwrseq-simple which could be referred to
+ mmc-pwrseq-simple.yaml. But now it\'s reused as a tunable delay
+ waiting for I/O signalling and card power supply to be stable,
+ regardless of whether pwrseq-simple is used. Default to 10ms if
+ not available.
+ default: 10
+
+ supports-cqe:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The presence of this property indicates that the corresponding
+ MMC host controller supports HW command queue feature.
+
+ disable-cqe-dcmd:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The presence of this property indicates that the MMC
+ controller\'s command queue engine (CQE) does not support direct
+ commands (DCMDs).
+
+ keep-power-in-suspend:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SDIO only. Preserves card power during a suspend/resume cycle.
+
+ wakeup-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ SDIO only. Enables wake up of host system on SDIO IRQ assertion.
+
+ vmmc-supply:
+ description:
+ Supply for the card power
+
+ vqmmc-supply:
+ description:
+ Supply for the bus IO line power, such as a level shifter.
+ If the level shifter is controlled by a GPIO line, this shall
+ be modeled as a "regulator-fixed" with a GPIO line for
+ switching the level shifter on/off.
+
+ mmc-pwrseq:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ System-on-Chip designs may specify a specific MMC power
+ sequence. To successfully detect an (e)MMC/SD/SDIO card, that
+ power sequence must be maintained while initializing the card.
+
+patternProperties:
+ "^.*@[0-9]+$":
+ type: object
+ description: |
+ On embedded systems the cards connected to a host may need
+ additional properties. These can be specified in subnodes to the
+ host controller node. The subnodes are identified by the
+ standard \'reg\' property. Which information exactly can be
+ specified depends on the bindings for the SDIO function driver
+ for the subnode, as specified by the compatible string.
+
+ properties:
+ compatible:
+ description:
+ Name of SDIO function following generic names recommended
+ practice
+
+ reg:
+ items:
+ - minimum: 0
+ maximum: 7
+ description:
+ Must contain the SDIO function number of the function this
+ subnode describes. A value of 0 denotes the memory SD
+ function, values from 1 to 7 denote the SDIO functions.
+
+ required:
+ - reg
+
+ "^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)|uhs-(sdr(12|25|50|104)|ddr50))$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ minItems: 2
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 359
+ description:
+ Set the clock (phase) delays which are to be configured in the
+ controller while switching to particular speed mode. These values
+ are in pair of degrees.
+
+dependencies:
+ cd-debounce-delay-ms: [ cd-gpios ]
+ fixed-emmc-driver-type: [ non-removable ]
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
index 802e3ca8be4d..26e4f0f8dc1c 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -4,12 +4,12 @@
$id: http://devicetree.org/schemas/mmc/mmc-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MMC Controller Generic Binding
+title: MMC Controller Common Properties
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
-description: |
+description:
These properties are common to multiple MMC host controllers. Any host
that requires the respective functionality should implement them using
these definitions.
@@ -18,351 +18,12 @@ description: |
(and the corresponding mmcblkN devices) by defining an alias in the
/aliases device tree node.
+$ref: mmc-controller-common.yaml#
+
properties:
$nodename:
pattern: "^mmc(@.*)?$"
- "#address-cells":
- const: 1
- description: |
- The cell is the slot ID if a function subnode is used.
-
- "#size-cells":
- const: 0
-
- # Card Detection.
- # If none of these properties are supplied, the host native card
- # detect will be used. Only one of them should be provided.
-
- broken-cd:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- There is no card detection available; polling must be used.
-
- cd-gpios:
- maxItems: 1
- description:
- The card detection will be done using the GPIO provided.
-
- non-removable:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Non-removable slot (like eMMC); assume always present.
-
- # *NOTE* on CD and WP polarity. To use common for all SD/MMC host
- # controllers line polarity properties, we have to fix the meaning
- # of the "normal" and "inverted" line levels. We choose to follow
- # the SDHCI standard, which specifies both those lines as "active
- # low." Therefore, using the "cd-inverted" property means, that the
- # CD line is active high, i.e. it is high, when a card is
- # inserted. Similar logic applies to the "wp-inverted" property.
- #
- # CD and WP lines can be implemented on the hardware in one of two
- # ways: as GPIOs, specified in cd-gpios and wp-gpios properties, or
- # as dedicated pins. Polarity of dedicated pins can be specified,
- # using *-inverted properties. GPIO polarity can also be specified
- # using the GPIO_ACTIVE_LOW flag. This creates an ambiguity in the
- # latter case. We choose to use the XOR logic for GPIO CD and WP
- # lines. This means, the two properties are "superimposed," for
- # example leaving the GPIO_ACTIVE_LOW flag clear and specifying the
- # respective *-inverted property property results in a
- # double-inversion and actually means the "normal" line polarity is
- # in effect.
- wp-inverted:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- The Write Protect line polarity is inverted.
-
- cd-inverted:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- The CD line polarity is inverted.
-
- # Other properties
-
- bus-width:
- description:
- Number of data lines.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 4, 8]
- default: 1
-
- max-frequency:
- description: |
- Maximum operating frequency of the bus:
- - for eMMC, the maximum supported frequency is 200MHz,
- - for SD/SDIO cards the SDR104 mode has a max supported
- frequency of 208MHz,
- - some mmc host controllers do support a max frequency upto
- 384MHz.
- So, lets keep the maximum supported value here.
-
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 400000
- maximum: 384000000
-
- disable-wp:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- When set, no physical write-protect line is present. This
- property should only be specified when the controller has a
- dedicated write-protect detection logic. If a GPIO is always used
- for the write-protect detection logic, it is sufficient to not
- specify the wp-gpios property in the absence of a write-protect
- line. Not used in combination with eMMC or SDIO.
-
- wp-gpios:
- maxItems: 1
- description:
- GPIO to use for the write-protect detection.
-
- cd-debounce-delay-ms:
- description:
- Set delay time before detecting card after card insert
- interrupt.
-
- no-1-8-v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- When specified, denotes that 1.8V card voltage is not supported
- on this system, even if the controller claims it.
-
- cap-sd-highspeed:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SD high-speed timing is supported.
-
- cap-mmc-highspeed:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- MMC high-speed timing is supported.
-
- sd-uhs-sdr12:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SD UHS SDR12 speed is supported.
-
- sd-uhs-sdr25:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SD UHS SDR25 speed is supported.
-
- sd-uhs-sdr50:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SD UHS SDR50 speed is supported.
-
- sd-uhs-sdr104:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SD UHS SDR104 speed is supported.
-
- sd-uhs-ddr50:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SD UHS DDR50 speed is supported.
-
- cap-power-off-card:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Powering off the card is safe.
-
- cap-mmc-hw-reset:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC hardware reset is supported
-
- cap-sdio-irq:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- enable SDIO IRQ signalling on this interface
-
- full-pwr-cycle:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Full power cycle of the card is supported.
-
- full-pwr-cycle-in-suspend:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Full power cycle of the card in suspend is supported.
-
- mmc-ddr-1_2v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC high-speed DDR mode (1.2V I/O) is supported.
-
- mmc-ddr-1_8v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC high-speed DDR mode (1.8V I/O) is supported.
-
- mmc-ddr-3_3v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC high-speed DDR mode (3.3V I/O) is supported.
-
- mmc-hs200-1_2v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC HS200 mode (1.2V I/O) is supported.
-
- mmc-hs200-1_8v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC HS200 mode (1.8V I/O) is supported.
-
- mmc-hs400-1_2v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC HS400 mode (1.2V I/O) is supported.
-
- mmc-hs400-1_8v:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC HS400 mode (1.8V I/O) is supported.
-
- mmc-hs400-enhanced-strobe:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- eMMC HS400 enhanced strobe mode is supported
-
- no-mmc-hs400:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- All eMMC HS400 modes are not supported.
-
- dsr:
- description:
- Value the card Driver Stage Register (DSR) should be programmed
- with.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 0xffff
-
- no-sdio:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Controller is limited to send SDIO commands during
- initialization.
-
- no-sd:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Controller is limited to send SD commands during initialization.
-
- no-mmc:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Controller is limited to send MMC commands during
- initialization.
-
- fixed-emmc-driver-type:
- description:
- For non-removable eMMC, enforce this driver type. The value is
- the driver type as specified in the eMMC specification (table
- 206 in spec version 5.1)
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 4
-
- post-power-on-delay-ms:
- description:
- It was invented for MMC pwrseq-simple which could be referred to
- mmc-pwrseq-simple.txt. But now it\'s reused as a tunable delay
- waiting for I/O signalling and card power supply to be stable,
- regardless of whether pwrseq-simple is used. Default to 10ms if
- no available.
- default: 10
-
- supports-cqe:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- The presence of this property indicates that the corresponding
- MMC host controller supports HW command queue feature.
-
- disable-cqe-dcmd:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- The presence of this property indicates that the MMC
- controller\'s command queue engine (CQE) does not support direct
- commands (DCMDs).
-
- keep-power-in-suspend:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SDIO only. Preserves card power during a suspend/resume cycle.
-
- # Deprecated: enable-sdio-wakeup
- wakeup-source:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- SDIO only. Enables wake up of host system on SDIO IRQ assertion.
-
- vmmc-supply:
- description:
- Supply for the card power
-
- vqmmc-supply:
- description:
- Supply for the bus IO line power, such as a level shifter.
- If the level shifter is controlled by a GPIO line, this shall
- be modeled as a "regulator-fixed" with a GPIO line for
- switching the level shifter on/off.
-
- mmc-pwrseq:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- System-on-Chip designs may specify a specific MMC power
- sequence. To successfully detect an (e)MMC/SD/SDIO card, that
- power sequence must be maintained while initializing the card.
-
-patternProperties:
- "^.*@[0-9]+$":
- type: object
- description: |
- On embedded systems the cards connected to a host may need
- additional properties. These can be specified in subnodes to the
- host controller node. The subnodes are identified by the
- standard \'reg\' property. Which information exactly can be
- specified depends on the bindings for the SDIO function driver
- for the subnode, as specified by the compatible string.
-
- properties:
- compatible:
- description: |
- Name of SDIO function following generic names recommended
- practice
-
- reg:
- items:
- - minimum: 0
- maximum: 7
- description:
- Must contain the SDIO function number of the function this
- subnode describes. A value of 0 denotes the memory SD
- function, values from 1 to 7 denote the SDIO functions.
-
- required:
- - reg
-
- "^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)|uhs-(sdr(12|25|50|104)|ddr50))$":
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
- minItems: 2
- maxItems: 2
- items:
- minimum: 0
- maximum: 359
- description:
- Set the clock (phase) delays which are to be configured in the
- controller while switching to particular speed mode. These values
- are in pair of degrees.
-
-dependencies:
- cd-debounce-delay-ms: [ cd-gpios ]
- fixed-emmc-driver-type: [ non-removable ]
-
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml
index 1fc7e620f328..588be73168fa 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-emmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Simple eMMC hardware reset provider binding
+title: Simple eMMC hardware reset provider
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -41,7 +41,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- sdhci0_pwrseq {
+ pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
};
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
index 9e2396751030..b35e00e8c65e 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-sd8787.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell SD8787 power sequence provider binding
+title: Marvell SD8787 power sequence provider
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -35,7 +35,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- wifi_pwrseq: wifi_pwrseq {
+ pwrseq {
compatible = "mmc-pwrseq-sd8787";
powerdown-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
reset-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
index 226fb191913d..00feaafc1063 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-simple.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Simple MMC power sequence provider binding
+title: Simple MMC power sequence provider
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -55,7 +55,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
- sdhci0_pwrseq {
+ pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
clocks = <&clk_32768_ck>;
diff --git a/Documentation/devicetree/bindings/mmc/mmc-slot.yaml b/Documentation/devicetree/bindings/mmc/mmc-slot.yaml
new file mode 100644
index 000000000000..ca3d0114bfc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-slot.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mmc-slot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MMC slot properties
+
+maintainers:
+ - Ulf Hansson <ulf.hansson@linaro.org>
+
+description:
+ These properties defines slot properties for MMC controlers that
+ have multiple slots or ports provided by the same controller and
+ sharing the same resources.
+
+$ref: mmc-controller-common.yaml#
+
+properties:
+ $nodename:
+ pattern: "^slot(@.*)?$"
+
+ compatible:
+ const: mmc-slot
+
+ reg:
+ description:
+ the slot (or "port") ID
+ maxItems: 1
+
+required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ slot@0 {
+ compatible = "mmc-slot";
+ reg = <0>;
+ bus-width = <4>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml
index c0662ce9946d..6e2cdac6a85d 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.yaml
@@ -10,7 +10,7 @@ maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
- $ref: /schemas/spi/spi-peripheral-props.yaml
description: |
@@ -27,17 +27,19 @@ properties:
maxItems: 1
voltage-ranges:
- $ref: /schemas/types.yaml#/definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
description: |
Two cells are required, first cell specifies minimum slot voltage (mV),
second cell specifies maximum slot voltage (mV).
items:
- - description: |
- value for minimum slot voltage in mV
- default: 3200
- - description: |
- value for maximum slot voltage in mV
- default: 3400
+ items:
+ - description: |
+ value for minimum slot voltage in mV
+ default: 3200
+ - description: |
+ value for maximum slot voltage in mV
+ default: 3400
+ maxItems: 1
gpios:
description: |
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
index d8e1e2e9adf2..6dd26ad31491 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
@@ -4,15 +4,12 @@
$id: http://devicetree.org/schemas/mmc/mtk-sd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MTK MSDC Storage Host Controller Binding
+title: MTK MSDC Storage Host Controller
maintainers:
- Chaotian Jing <chaotian.jing@mediatek.com>
- Wenbin Mei <wenbin.mei@mediatek.com>
-allOf:
- - $ref: mmc-controller.yaml#
-
properties:
compatible:
oneOf:
@@ -23,19 +20,24 @@ properties:
- mediatek,mt6795-mmc
- mediatek,mt7620-mmc
- mediatek,mt7622-mmc
+ - mediatek,mt7986-mmc
+ - mediatek,mt7988-mmc
- mediatek,mt8135-mmc
- mediatek,mt8173-mmc
- mediatek,mt8183-mmc
+ - mediatek,mt8196-mmc
- mediatek,mt8516-mmc
- items:
- const: mediatek,mt7623-mmc
- const: mediatek,mt2701-mmc
- items:
- enum:
+ - mediatek,mt6893-mmc
- mediatek,mt8186-mmc
- mediatek,mt8188-mmc
- mediatek,mt8192-mmc
- mediatek,mt8195-mmc
+ - mediatek,mt8365-mmc
- const: mediatek,mt8183-mmc
reg:
@@ -48,27 +50,11 @@ properties:
description:
Should contain phandle for the clock feeding the MMC controller.
minItems: 2
- items:
- - description: source clock (required).
- - description: HCLK which used for host (required).
- - description: independent source clock gate (required for MT2712).
- - description: bus clock used for internal register access (required for MT2712 MSDC0/3).
- - description: msdc subsys clock gate (required for MT8192).
- - description: peripheral bus clock gate (required for MT8192).
- - description: AXI bus clock gate (required for MT8192).
- - description: AHB bus clock gate (required for MT8192).
+ maxItems: 7
clock-names:
minItems: 2
- items:
- - const: source
- - const: hclk
- - const: source_cg
- - const: bus_clk
- - const: sys_cg
- - const: pclk_cg
- - const: axi_cg
- - const: ahb_cg
+ maxItems: 7
interrupts:
description:
@@ -108,16 +94,6 @@ properties:
should switch dat1 pin to GPIO mode.
maxItems: 1
- assigned-clocks:
- description:
- PLL of the source clock.
- maxItems: 1
-
- assigned-clock-parents:
- description:
- parent of source clock, used for HS400 mode to get 400Mhz source clock.
- maxItems: 1
-
hs400-ds-delay:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -172,6 +148,15 @@ properties:
minimum: 0
maximum: 7
+ mediatek,tuning-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Some SoCs need extend tuning step for better delay value to avoid CRC issue.
+ If not present, default tuning step is 32. For eMMC and SD, this can yield
+ satisfactory calibration results in most cases.
+ enum: [32, 64]
+ default: 32
+
resets:
maxItems: 1
@@ -190,15 +175,175 @@ required:
- vmmc-supply
- vqmmc-supply
-if:
- properties:
- compatible:
- contains:
- const: mediatek,mt8183-mmc
-then:
- properties:
- reg:
- minItems: 2
+allOf:
+ - $ref: mmc-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-mmc
+ - mediatek,mt6779-mmc
+ - mediatek,mt6795-mmc
+ - mediatek,mt7620-mmc
+ - mediatek,mt7622-mmc
+ - mediatek,mt7623-mmc
+ - mediatek,mt8135-mmc
+ - mediatek,mt8173-mmc
+ - mediatek,mt8183-mmc
+ - mediatek,mt8186-mmc
+ - mediatek,mt8188-mmc
+ - mediatek,mt8195-mmc
+ - mediatek,mt8196-mmc
+ - mediatek,mt8516-mmc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ items:
+ - description: source clock
+ - description: HCLK which used for host
+ - description: independent source clock gate
+ clock-names:
+ minItems: 2
+ items:
+ - const: source
+ - const: hclk
+ - const: source_cg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt2712-mmc
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ items:
+ - description: source clock
+ - description: HCLK which used for host
+ - description: independent source clock gate
+ - description: bus clock used for internal register access (required for MSDC0/3).
+ clock-names:
+ minItems: 3
+ items:
+ - const: source
+ - const: hclk
+ - const: source_cg
+ - const: bus_clk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7986-mmc
+ - mediatek,mt7988-mmc
+ - mediatek,mt8183-mmc
+ - mediatek,mt8196-mmc
+ then:
+ properties:
+ reg:
+ minItems: 2
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7986-mmc
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ items:
+ - description: source clock
+ - description: HCLK which used for host
+ - description: independent source clock gate
+ - description: bus clock used for internal register access (required for MSDC0/3).
+ - description: msdc subsys clock gate
+ clock-names:
+ minItems: 3
+ items:
+ - const: source
+ - const: hclk
+ - const: source_cg
+ - const: bus_clk
+ - const: sys_cg
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7988-mmc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: source clock
+ - description: HCLK which used for host
+ - description: Advanced eXtensible Interface
+ - description: Advanced High-performance Bus clock
+ clock-names:
+ items:
+ - const: source
+ - const: hclk
+ - const: axi_cg
+ - const: ahb_cg
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt6893-mmc
+ - mediatek,mt8186-mmc
+ - mediatek,mt8188-mmc
+ - mediatek,mt8195-mmc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: source clock
+ - description: HCLK which used for host
+ - description: independent source clock gate
+ - description: crypto clock used for data encrypt/decrypt (optional)
+ clock-names:
+ items:
+ - const: source
+ - const: hclk
+ - const: source_cg
+ - const: crypto
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8192-mmc
+ then:
+ properties:
+ clocks:
+ items:
+ - description: source clock
+ - description: HCLK which used for host
+ - description: independent source clock gate
+ - description: msdc subsys clock gate
+ - description: peripheral bus clock gate
+ - description: AXI bus clock gate
+ - description: AHB bus clock gate
+ clock-names:
+ items:
+ - const: source
+ - const: hclk
+ - const: source_cg
+ - const: sys_cg
+ - const: pclk_cg
+ - const: axi_cg
+ - const: ahb_cg
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
index bec8f8c71ff2..df07ea3b81d1 100644
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml
@@ -17,7 +17,7 @@ description: |
and the properties used by the mxsmmc driver.
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller-common.yaml#
properties:
compatible:
@@ -31,6 +31,9 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 1
+
dmas:
maxItems: 1
@@ -41,6 +44,7 @@ required:
- compatible
- reg
- interrupts
+ - clocks
- dmas
- dma-names
@@ -52,6 +56,7 @@ examples:
compatible = "fsl,imx28-mmc";
reg = <0x80010000 2000>;
interrupts = <96>;
+ clocks = <&clks 46>;
dmas = <&dma_apbh 0>;
dma-names = "rx-tx";
bus-width = <8>;
diff --git a/Documentation/devicetree/bindings/mmc/npcm,sdhci.yaml b/Documentation/devicetree/bindings/mmc/npcm,sdhci.yaml
new file mode 100644
index 000000000000..196fdbfa16ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/npcm,sdhci.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/npcm,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NPCM SDHCI Controller
+
+maintainers:
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-sdhci
+ - nuvoton,npcm845-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@f0840000 {
+ compatible = "nuvoton,npcm750-sdhci";
+ reg = <0xf0840000 0x200>;
+ interrupts = <0 27 4>;
+ clocks = <&clk 4>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/nuvoton,ma35d1-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nuvoton,ma35d1-sdhci.yaml
new file mode 100644
index 000000000000..4d787147c300
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/nuvoton,ma35d1-sdhci.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/nuvoton,ma35d1-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 SD/SDIO/MMC Controller
+
+maintainers:
+ - Shan-Chun Hung <shanchun1218@gmail.com>
+
+allOf:
+ - $ref: sdhci-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,ma35d1-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: state_uhs
+
+ pinctrl-0:
+ description:
+ Should contain default/high speed pin ctrl.
+ maxItems: 1
+
+ pinctrl-1:
+ description:
+ Should contain uhs mode pin ctrl.
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ nuvoton,sys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to access GCR (Global Control Register) registers.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - pinctrl-names
+ - pinctrl-0
+ - resets
+ - nuvoton,sys
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+ #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ mmc@40190000 {
+ compatible = "nuvoton,ma35d1-sdhci";
+ reg = <0x0 0x40190000 0x0 0x2000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk SDH1_GATE>;
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&pinctrl_sdhci1>;
+ pinctrl-1 = <&pinctrl_sdhci1_uhs>;
+ resets = <&sys MA35D1_RESET_SDH1>;
+ nuvoton,sys = <&sys>;
+ vqmmc-supply = <&sdhci1_vqmmc_regulator>;
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
index fe0270207622..72987f0326a1 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
@@ -82,8 +82,7 @@ properties:
iommus:
maxItems: 1
- operating-points-v2:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ operating-points-v2: true
power-domains:
items:
@@ -100,53 +99,53 @@ properties:
The DQS trim values are only used on controllers which support HS400
timing. Only SDMMC4 on Tegra210 and Tegra186 supports HS400.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,default-trim:
description: Specify the default outbound clock trimmer value.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,dqs-trim:
description: Specify DQS trim value for HS400 timing.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-1v8:
description: Specify drive strength calibration offsets for 1.8 V
signaling modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-1v8-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 1.8 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-3v3:
description: Specify drive strength calibration offsets for 3.3 V
signaling modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-3v3-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 3.3 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-sdr104:
description: Specify drive strength calibration offsets for SDR104 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-down-offset-hs400:
description: Specify drive strength calibration offsets for HS400 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-1v8:
description: Specify drive strength calibration offsets for 1.8 V
signaling modes.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-1v8-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 1.8 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-3v3:
description: Specify drive strength calibration offsets for 3.3 V
@@ -158,25 +157,25 @@ properties:
refer to the reference manual of the SoC for correct values. The SDR104
and HS400 timing specific values are used in corresponding modes if
specified.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-3v3-timeout:
description: Specify drive strength used as a fallback in case the
automatic calibration times out on a 3.3 V signaling mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-sdr104:
description: Specify drive strength calibration offsets for SDR104 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,pad-autocal-pull-up-offset-hs400:
description: Specify drive strength calibration offsets for HS400 mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
nvidia,only-1-8v:
description: The presence of this property indicates that the controller
operates at a 1.8 V fixed I/O voltage.
- $ref: "/schemas/types.yaml#/definitions/flag"
+ $ref: /schemas/types.yaml#/definitions/flag
required:
- compatible
@@ -187,7 +186,7 @@ required:
- reset-names
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
index b0d81ebe0f6e..1b7d88ed3799 100644
--- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Actions Semi Owl SoCs SD/MMC/SDIO controller
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
diff --git a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
index 5f5c2bec2b8c..66a78eae4dc9 100644
--- a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
@@ -9,7 +9,7 @@ Required properties:
Optional properties:
- marvell,detect-delay-ms: sets the detection delay timeout in ms.
-In addition to the properties described in this docuent, the details
+In addition to the properties described in this document, the details
described in mmc.txt are supported.
Examples:
diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml
index c36ba561c387..024313b79ec9 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml
+++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.yaml
@@ -10,7 +10,7 @@ maintainers:
- Wolfram Sang <wsa+renesas@sang-engineering.com>
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
index 0424b06cb655..c754ea71f51f 100644
--- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
+++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mmc/renesas,sdhi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mmc/renesas,sdhi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas SDHI SD/MMC controller
@@ -12,16 +12,14 @@ maintainers:
properties:
compatible:
oneOf:
- - items:
- - const: renesas,sdhi-sh73a0 # R-Mobile APE6
- - items:
- - const: renesas,sdhi-r7s72100 # RZ/A1H
- - items:
- - const: renesas,sdhi-r7s9210 # SH-Mobile AG5
- - items:
- - const: renesas,sdhi-r8a73a4 # R-Mobile APE6
- - items:
- - const: renesas,sdhi-r8a7740 # R-Mobile A1
+ - enum:
+ - renesas,sdhi-mmc-r8a77470 # RZ/G1C
+ - renesas,sdhi-r7s72100 # RZ/A1H
+ - renesas,sdhi-r7s9210 # SH-Mobile AG5
+ - renesas,sdhi-r8a73a4 # R-Mobile APE6
+ - renesas,sdhi-r8a7740 # R-Mobile A1
+ - renesas,sdhi-r9a09g057 # RZ/V2H(P)
+ - renesas,sdhi-sh73a0 # R-Mobile APE6
- items:
- enum:
- renesas,sdhi-r8a7778 # R-Car M1
@@ -41,8 +39,6 @@ properties:
- renesas,sdhi-r8a7794 # R-Car E2
- const: renesas,rcar-gen2-sdhi # R-Car Gen2 and RZ/G1
- items:
- - const: renesas,sdhi-mmc-r8a77470 # RZ/G1C (SDHI/MMC IP)
- - items:
- enum:
- renesas,sdhi-r8a774a1 # RZ/G2M
- renesas,sdhi-r8a774b1 # RZ/G2N
@@ -56,15 +52,29 @@ properties:
- renesas,sdhi-r8a77980 # R-Car V3H
- renesas,sdhi-r8a77990 # R-Car E3
- renesas,sdhi-r8a77995 # R-Car D3
- - renesas,sdhi-r9a07g043 # RZ/G2UL
- - renesas,sdhi-r9a07g044 # RZ/G2{L,LC}
- - renesas,sdhi-r9a07g054 # RZ/V2L
- const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2
- items:
- enum:
- renesas,sdhi-r8a779a0 # R-Car V3U
- renesas,sdhi-r8a779f0 # R-Car S4-8
+ - renesas,sdhi-r8a779g0 # R-Car V4H
+ - renesas,sdhi-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-sdhi # R-Car Gen4
+ - items:
+ - enum:
+ - renesas,sdhi-r9a07g043 # RZ/G2UL and RZ/Five
+ - renesas,sdhi-r9a07g044 # RZ/G2{L,LC}
+ - renesas,sdhi-r9a07g054 # RZ/V2L
+ - renesas,sdhi-r9a08g045 # RZ/G3S
+ - renesas,sdhi-r9a09g011 # RZ/V2M
+ - const: renesas,rzg2l-sdhi
+ - items:
+ - enum:
+ - renesas,sdhi-r9a09g047 # RZ/G3E
+ - renesas,sdhi-r9a09g056 # RZ/V2N
+ - renesas,sdhi-r9a09g077 # RZ/T2H
+ - renesas,sdhi-r9a09g087 # RZ/N2H
+ - const: renesas,sdhi-r9a09g057 # RZ/V2H(P)
reg:
maxItems: 1
@@ -73,9 +83,13 @@ properties:
minItems: 1
maxItems: 3
- clocks: true
+ clocks:
+ minItems: 1
+ maxItems: 4
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 4
dmas:
minItems: 4
@@ -110,67 +124,85 @@ properties:
max-frequency: true
allOf:
- - $ref: "mmc-controller.yaml"
+ - $ref: mmc-controller.yaml
- if:
properties:
compatible:
contains:
enum:
- - renesas,sdhi-r9a07g043
- - renesas,sdhi-r9a07g044
- - renesas,sdhi-r9a07g054
+ - renesas,sdhi-r9a09g077
+ - renesas,sdhi-r9a09g087
then:
properties:
+ resets: false
clocks:
items:
- - description: IMCLK, SDHI channel main clock1.
- - description: CLK_HS, SDHI channel High speed clock which operates
- 4 times that of SDHI channel main clock1.
- - description: IMCLK2, SDHI channel main clock2. When this clock is
- turned off, external SD card detection cannot be
- detected.
- - description: ACLK, SDHI channel bus clock.
+ - description: ACLK, IMCLK, SDHI channel bus and main clocks.
+ - description: CLK_HS, SDHI channel High speed clock.
clock-names:
items:
- - const: core
- - const: clkh
- - const: cd
- const: aclk
- required:
- - clock-names
- - resets
+ - const: clkh
else:
if:
properties:
compatible:
contains:
enum:
- - renesas,rcar-gen2-sdhi
- - renesas,rcar-gen3-sdhi
- - renesas,rcar-gen4-sdhi
+ - renesas,sdhi-r9a09g057
+ - renesas,rzg2l-sdhi
then:
properties:
clocks:
- minItems: 1
- maxItems: 3
- clock-names:
- minItems: 1
- uniqueItems: true
items:
- - const: core
- - enum: [ clkh, cd ]
- - const: cd
- else:
- properties:
- clocks:
- minItems: 1
- maxItems: 2
+ - description: IMCLK, SDHI channel main clock1.
+ - description: CLK_HS, SDHI channel High speed clock which operates
+ 4 times that of SDHI channel main clock1.
+ - description: IMCLK2, SDHI channel main clock2. When this clock is
+ turned off, external SD card detection cannot be
+ detected.
+ - description: ACLK, SDHI channel bus clock.
clock-names:
- minItems: 1
items:
- const: core
+ - const: clkh
- const: cd
+ - const: aclk
+ required:
+ - clock-names
+ - resets
+ else:
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rcar-gen2-sdhi
+ - renesas,rcar-gen3-sdhi
+ - renesas,rcar-gen4-sdhi
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 3
+ clock-names:
+ minItems: 1
+ uniqueItems: true
+ items:
+ - const: core
+ - enum: [ clkh, cd ]
+ - const: cd
+ else:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: cd
- if:
properties:
@@ -205,6 +237,19 @@ allOf:
sectioned off to be run by a separate second clock source to allow
the main core clock to be turned off to save power.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,sdhi-r9a09g057
+ then:
+ properties:
+ vqmmc-regulator:
+ type: object
+ description: VQMMC SD regulator
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -221,49 +266,49 @@ examples:
#include <dt-bindings/power/r8a7790-sysc.h>
sdhi0: mmc@ee100000 {
- compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
- reg = <0xee100000 0x328>;
- interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 314>;
- dmas = <&dmac0 0xcd>, <&dmac0 0xce>, <&dmac1 0xcd>, <&dmac1 0xce>;
- dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <195000000>;
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 314>;
+ compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
+ reg = <0xee100000 0x328>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 314>;
+ dmas = <&dmac0 0xcd>, <&dmac0 0xce>, <&dmac1 0xcd>, <&dmac1 0xce>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <195000000>;
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 314>;
};
sdhi1: mmc@ee120000 {
- compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
- reg = <0xee120000 0x328>;
- interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 313>;
- dmas = <&dmac0 0xc9>, <&dmac0 0xca>, <&dmac1 0xc9>, <&dmac1 0xca>;
- dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <195000000>;
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 313>;
+ compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
+ reg = <0xee120000 0x328>;
+ interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 313>;
+ dmas = <&dmac0 0xc9>, <&dmac0 0xca>, <&dmac1 0xc9>, <&dmac1 0xca>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <195000000>;
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 313>;
};
sdhi2: mmc@ee140000 {
- compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
- reg = <0xee140000 0x100>;
- interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 312>;
- dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, <&dmac1 0xc1>, <&dmac1 0xc2>;
- dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <97500000>;
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 312>;
- };
+ compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
+ reg = <0xee140000 0x100>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 312>;
+ dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, <&dmac1 0xc1>, <&dmac1 0xc2>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <97500000>;
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 312>;
+ };
- sdhi3: mmc@ee160000 {
- compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
- reg = <0xee160000 0x100>;
- interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 311>;
- dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, <&dmac1 0xd3>, <&dmac1 0xd4>;
- dma-names = "tx", "rx", "tx", "rx";
- max-frequency = <97500000>;
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 311>;
+ sdhi3: mmc@ee160000 {
+ compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi";
+ reg = <0xee160000 0x100>;
+ interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 311>;
+ dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, <&dmac1 0xd3>, <&dmac1 0xd4>;
+ dma-names = "tx", "rx", "tx", "rx";
+ max-frequency = <97500000>;
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 311>;
};
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
index ccf0e3e93efa..acb9fb9a92cd 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip designware mobile storage host controller device tree bindings
+title: Rockchip designware mobile storage host controller
description:
Rockchip uses the Synopsys designware mobile storage host controller
@@ -14,7 +14,7 @@ description:
file and the Rockchip specific extensions.
allOf:
- - $ref: "synopsys-dw-mshc-common.yaml#"
+ - $ref: synopsys-dw-mshc-common.yaml#
maintainers:
- Heiko Stuebner <heiko@sntech.de>
@@ -38,10 +38,16 @@ properties:
- rockchip,rk3328-dw-mshc
- rockchip,rk3368-dw-mshc
- rockchip,rk3399-dw-mshc
+ - rockchip,rk3506-dw-mshc
+ - rockchip,rk3528-dw-mshc
+ - rockchip,rk3562-dw-mshc
- rockchip,rk3568-dw-mshc
+ - rockchip,rk3588-dw-mshc
- rockchip,rv1108-dw-mshc
- rockchip,rv1126-dw-mshc
- const: rockchip,rk3288-dw-mshc
+ # for Rockchip RK3576 with phase tuning inside the controller
+ - const: rockchip,rk3576-dw-mshc
reg:
maxItems: 1
@@ -71,6 +77,9 @@ properties:
to control the clock phases, "ciu-sample" is required for tuning
high speed modes.
+ power-domains:
+ maxItems: 1
+
rockchip,default-sample-phase:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
index fdaa18481aa0..27c4060f2f91 100644
--- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
@@ -14,15 +14,26 @@ maintainers:
properties:
compatible:
- enum:
- - samsung,exynos4210-dw-mshc
- - samsung,exynos4412-dw-mshc
- - samsung,exynos5250-dw-mshc
- - samsung,exynos5420-dw-mshc
- - samsung,exynos5420-dw-mshc-smu
- - samsung,exynos7-dw-mshc
- - samsung,exynos7-dw-mshc-smu
- - axis,artpec8-dw-mshc
+ oneOf:
+ - enum:
+ - axis,artpec8-dw-mshc
+ - samsung,exynos4210-dw-mshc
+ - samsung,exynos4412-dw-mshc
+ - samsung,exynos5250-dw-mshc
+ - samsung,exynos5420-dw-mshc
+ - samsung,exynos5420-dw-mshc-smu
+ - samsung,exynos7-dw-mshc
+ - samsung,exynos7-dw-mshc-smu
+ - samsung,exynos7870-dw-mshc
+ - samsung,exynos7870-dw-mshc-smu
+ - items:
+ - enum:
+ - samsung,exynos5433-dw-mshc-smu
+ - samsung,exynos7885-dw-mshc-smu
+ - samsung,exynos850-dw-mshc-smu
+ - samsung,exynos8890-dw-mshc-smu
+ - samsung,exynos8895-dw-mshc-smu
+ - const: samsung,exynos7-dw-mshc-smu
reg:
maxItems: 1
@@ -112,7 +123,7 @@ required:
- samsung,dw-mshc-sdr-timing
allOf:
- - $ref: "synopsys-dw-mshc-common.yaml#"
+ - $ref: synopsys-dw-mshc-common.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
deleted file mode 100644
index 5f68feb9f9d6..000000000000
--- a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
-
-Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
-with external MMC, SD and SDIO storage mediums.
-
-This file documents differences between the core mmc properties described by
-mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
-implementation.
-
-Required SoC Specific Properties:
-- compatible: should be one of the following
- - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
- - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
- - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
-- reg: register location and length
-- interrupts: mmc controller interrupt
-- clocks: Should reference the controller clock
-- clock-names: Should contain "sdi"
-
-Required Board Specific Properties:
-- pinctrl-0: Should specify pin control groups used for this controller.
-- pinctrl-names: Should contain only one value - "default".
-
-Optional Properties:
-- bus-width: number of data lines (see mmc.txt)
-- cd-gpios: gpio for card detection (see mmc.txt)
-- wp-gpios: gpio for write protection (see mmc.txt)
-
-Example:
-
- mmc0: mmc@5a000000 {
- compatible = "samsung,s3c2440-sdi";
- pinctrl-names = "default";
- pinctrl-0 = <&sdi_pins>;
- reg = <0x5a000000 0x100000>;
- interrupts = <0 0 21 3>;
- clocks = <&clocks PCLK_SDI>;
- clock-names = "sdi";
- bus-width = <4>;
- cd-gpios = <&gpg 8 GPIO_ACTIVE_LOW>;
- wp-gpios = <&gph 8 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
index ea9121fb188d..242a3c6b925c 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mmc/sdhci-am654.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mmc/sdhci-am654.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI AM654 MMC Controller
@@ -11,17 +11,18 @@ maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
allOf:
- - $ref: mmc-controller.yaml#
+ - $ref: sdhci-common.yaml#
properties:
compatible:
oneOf:
- - const: ti,am654-sdhci-5.1
- - const: ti,j721e-sdhci-8bit
- - const: ti,j721e-sdhci-4bit
- - const: ti,am64-sdhci-8bit
- - const: ti,am64-sdhci-4bit
- - const: ti,am62-sdhci
+ - enum:
+ - ti,am62-sdhci
+ - ti,am64-sdhci-4bit
+ - ti,am64-sdhci-8bit
+ - ti,am654-sdhci-5.1
+ - ti,j721e-sdhci-4bit
+ - ti,j721e-sdhci-8bit
- items:
- const: ti,j7200-sdhci-8bit
- const: ti,j721e-sdhci-8bit
@@ -49,10 +50,7 @@ properties:
- const: clk_ahb
- const: clk_xin
- sdhci-caps-mask: true
-
- dma-coherent:
- type: boolean
+ dma-coherent: true
# PHY output tap delays:
# Used to delay the data valid window and align it to the sampling clock.
@@ -61,67 +59,67 @@ properties:
ti,otap-del-sel-legacy:
description: Output tap delay for SD/MMC legacy timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-mmc-hs:
description: Output tap delay for MMC high speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-sd-hs:
description: Output tap delay for SD high speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-sdr12:
description: Output tap delay for SD UHS SDR12 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-sdr25:
description: Output tap delay for SD UHS SDR25 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-sdr50:
description: Output tap delay for SD UHS SDR50 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-sdr104:
description: Output tap delay for SD UHS SDR104 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-ddr50:
description: Output tap delay for SD UHS DDR50 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-ddr52:
description: Output tap delay for eMMC DDR52 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-hs200:
description: Output tap delay for eMMC HS200 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,otap-del-sel-hs400:
description: Output tap delay for eMMC HS400 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
@@ -131,49 +129,55 @@ properties:
ti,itap-del-sel-legacy:
description: Input tap delay for SD/MMC legacy timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
ti,itap-del-sel-mmc-hs:
description: Input tap delay for MMC high speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
ti,itap-del-sel-sd-hs:
description: Input tap delay for SD high speed timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
ti,itap-del-sel-sdr12:
description: Input tap delay for SD UHS SDR12 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
ti,itap-del-sel-sdr25:
description: Input tap delay for SD UHS SDR25 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x1f
+
+ ti,itap-del-sel-ddr50:
+ description: Input tap delay for MMC DDR50 timing
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
ti,itap-del-sel-ddr52:
description: Input tap delay for MMC DDR52 timing
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x1f
ti,trm-icp:
description: DLL trim select
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0xf
ti,driver-strength-ohm:
description: DLL drive strength in ohms
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum:
- 33
- 40
@@ -183,11 +187,11 @@ properties:
ti,strobe-sel:
description: strobe select delay for HS400 speed mode.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
ti,clkbuf-sel:
description: Clock Delay Buffer Select
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
ti,fails-without-test-cd:
$ref: /schemas/types.yaml#/definitions/flag
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
deleted file mode 100644
index 69edfd4d3922..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Atmel SDHCI controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties used by the
-sdhci-of-at91 driver.
-
-Required properties:
-- compatible: Must be "atmel,sama5d2-sdhci" or "microchip,sam9x60-sdhci".
-- clocks: Phandlers to the clocks.
-- clock-names: Must be "hclock", "multclk", "baseclk" for
- "atmel,sama5d2-sdhci".
- Must be "hclock", "multclk" for "microchip,sam9x60-sdhci".
-
-Optional properties:
-- assigned-clocks: The same with "multclk".
-- assigned-clock-rates The rate of "multclk" in order to not rely on the
- gck configuration set by previous components.
-- microchip,sdcal-inverted: when present, polarity on the SDCAL SoC pin is
- inverted. The default polarity for this signal is described in the datasheet.
- For instance on SAMA5D2, the pin is usually tied to the GND with a resistor
- and a capacitor (see "SDMMC I/O Calibration" chapter).
-
-Example:
-
-mmc0: sdio-host@a0000000 {
- compatible = "atmel,sama5d2-sdhci";
- reg = <0xa0000000 0x300>;
- interrupts = <31 IRQ_TYPE_LEVEL_HIGH 0>;
- clocks = <&sdmmc0_hclk>, <&sdmmc0_gclk>, <&main>;
- clock-names = "hclock", "multclk", "baseclk";
- assigned-clocks = <&sdmmc0_gclk>;
- assigned-clock-rates = <480000000>;
-};
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-common.yaml b/Documentation/devicetree/bindings/mmc/sdhci-common.yaml
new file mode 100644
index 000000000000..1664615187c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-common.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/sdhci-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SDHCI Controller Common Properties
+
+maintainers:
+ - Adrian Hunter <adrian.hunter@intel.com>
+
+description:
+ Common properties present on Secure Digital Host Controller Interface (SDHCI)
+ devices.
+
+properties:
+ sdhci-caps:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ Additionally present SDHCI capabilities - values for SDHCI_CAPABILITIES
+ and SDHCI_CAPABILITIES_1 registers.
+
+ sdhci-caps-mask:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ Masked SDHCI capabilities to remove from SDHCI_CAPABILITIES and
+ SDHCI_CAPABILITIES_1 registers.
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt b/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt
deleted file mode 100644
index 3ee9263adf73..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-fujitsu.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* Fujitsu SDHCI controller
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the sdhci_f_sdh30 driver.
-
-Required properties:
-- compatible: "fujitsu,mb86s70-sdhci-3.0"
-- clocks: Must contain an entry for each entry in clock-names. It is a
- list of phandles and clock-specifier pairs.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Should contain the following two entries:
- "iface" - clock used for sdhci interface
- "core" - core clock for sdhci controller
-
-Optional properties:
-- vqmmc-supply: phandle to the regulator device tree node, mentioned
- as the VCCQ/VDD_IO supply in the eMMC/SD specs.
-- fujitsu,cmd-dat-delay-select: boolean property indicating that this host
- requires the CMD_DAT_DELAY control to be enabled.
-
-Example:
-
- sdhci1: mmc@36600000 {
- compatible = "fujitsu,mb86s70-sdhci-3.0";
- reg = <0 0x36600000 0x1000>;
- interrupts = <0 172 0x4>,
- <0 173 0x4>;
- bus-width = <4>;
- vqmmc-supply = <&vccq_sdhci1>;
- clocks = <&clock 2 2 0>, <&clock 2 3 0>;
- clock-names = "iface", "core";
- };
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt b/Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
deleted file mode 100644
index 627ee89c125b..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-milbeaut.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* SOCIONEXT Milbeaut SDHCI controller
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the sdhci_milbeaut driver.
-
-Required properties:
-- compatible: "socionext,milbeaut-m10v-sdhci-3.0"
-- clocks: Must contain an entry for each entry in clock-names. It is a
- list of phandles and clock-specifier pairs.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Should contain the following two entries:
- "iface" - clock used for sdhci interface
- "core" - core clock for sdhci controller
-
-Optional properties:
-- fujitsu,cmd-dat-delay-select: boolean property indicating that this host
- requires the CMD_DAT_DELAY control to be enabled.
-
-Example:
- sdhci3: mmc@1b010000 {
- compatible = "socionext,milbeaut-m10v-sdhci-3.0";
- reg = <0x1b010000 0x10000>;
- interrupts = <0 265 0x4>;
- voltage-ranges = <3300 3300>;
- bus-width = <4>;
- clocks = <&clk 7>, <&ahb_clk>;
- clock-names = "core", "iface";
- cap-sdio-irq;
- fujitsu,cmd-dat-delay-select;
- };
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
index a96f143479c7..938be8228d66 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml
@@ -1,14 +1,14 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mmc/sdhci-msm.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mmc/sdhci-msm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm SDHCI controller (sdhci-msm)
maintainers:
- - Bhupesh Sharma <bhupesh.sharma@linaro.org>
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
description:
Secure Digital Host Controller Interface (SDHCI) present on
@@ -23,9 +23,12 @@ properties:
- items:
- enum:
- qcom,apq8084-sdhci
+ - qcom,ipq4019-sdhci
+ - qcom,ipq8074-sdhci
- qcom,msm8226-sdhci
- qcom,msm8953-sdhci
- qcom,msm8974-sdhci
+ - qcom,msm8976-sdhci
- qcom,msm8916-sdhci
- qcom,msm8992-sdhci
- qcom,msm8994-sdhci
@@ -34,20 +37,42 @@ properties:
- const: qcom,sdhci-msm-v4 # for sdcc versions less than 5.0
- items:
- enum:
+ - qcom,ipq5018-sdhci
+ - qcom,ipq5332-sdhci
+ - qcom,ipq5424-sdhci
+ - qcom,ipq6018-sdhci
+ - qcom,ipq9574-sdhci
+ - qcom,kaanapali-sdhci
+ - qcom,milos-sdhci
+ - qcom,qcm2290-sdhci
- qcom,qcs404-sdhci
+ - qcom,qcs615-sdhci
+ - qcom,qcs8300-sdhci
+ - qcom,qdu1000-sdhci
+ - qcom,sa8775p-sdhci
+ - qcom,sar2130p-sdhci
- qcom,sc7180-sdhci
- qcom,sc7280-sdhci
+ - qcom,sc8280xp-sdhci
- qcom,sdm630-sdhci
- qcom,sdm670-sdhci
- qcom,sdm845-sdhci
- qcom,sdx55-sdhci
- qcom,sdx65-sdhci
+ - qcom,sdx75-sdhci
- qcom,sm6115-sdhci
- qcom,sm6125-sdhci
- qcom,sm6350-sdhci
+ - qcom,sm6375-sdhci
+ - qcom,sm7150-sdhci
- qcom,sm8150-sdhci
- qcom,sm8250-sdhci
+ - qcom,sm8350-sdhci
- qcom,sm8450-sdhci
+ - qcom,sm8550-sdhci
+ - qcom,sm8650-sdhci
+ - qcom,sm8750-sdhci
+ - qcom,x1e80100-sdhci
- const: qcom,sdhci-msm-v5 # for sdcc version 5.0
reg:
@@ -59,7 +84,7 @@ properties:
maxItems: 4
clocks:
- minItems: 3
+ minItems: 2
items:
- description: Main peripheral bus clock, PCLK/HCLK - AHB Bus clock
- description: SDC MMC clock, MCLK
@@ -75,10 +100,12 @@ properties:
- const: iface
- const: core
- const: xo
- - const: ice
- - const: bus
- - const: cal
- - const: sleep
+ - enum: [ice, bus, cal, sleep]
+ - enum: [ice, bus, cal, sleep]
+ - enum: [ice, bus, cal, sleep]
+ - enum: [ice, bus, cal, sleep]
+
+ dma-coherent: true
interrupts:
maxItems: 2
@@ -120,11 +147,13 @@ properties:
phandle to apps_smmu node with sid mask.
interconnects:
+ minItems: 1
items:
- description: data path, sdhc to ddr
- description: config path, cpu to sdhc
interconnect-names:
+ minItems: 1
items:
- const: sdhc-ddr
- const: cpu-sdhc
@@ -133,16 +162,6 @@ properties:
description: A phandle to sdhci power domain node
maxItems: 1
- mmc-ddr-1_8v: true
-
- mmc-hs200-1_8v: true
-
- mmc-hs400-1_8v: true
-
- bus-width: true
-
- max-frequency: true
-
operating-points-v2: true
patternProperties:
@@ -165,7 +184,7 @@ required:
- interrupts
allOf:
- - $ref: mmc-controller.yaml#
+ - $ref: sdhci-common.yaml#
- if:
properties:
@@ -211,7 +230,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-sm8250.h>
#include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
sdhc_2: mmc@8804000 {
compatible = "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5";
@@ -228,7 +247,7 @@ examples:
iommus = <&apps_smmu 0x4a0 0x0>;
qcom,dll-config = <0x0007642c>;
qcom,ddr-config = <0x80040868>;
- power-domains = <&rpmhpd SM8250_CX>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
operating-points-v2 = <&sdhc2_opp_table>;
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
deleted file mode 100644
index f91e341e6b36..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-* TI OMAP SDHCI Controller
-
-Refer to mmc.txt for standard MMC bindings.
-
-For UHS devices which require tuning, the device tree should have a "cpu_thermal" node which maps to the appropriate thermal zone. This is used to get the temperature of the zone during tuning.
-
-Required properties:
-- compatible: Should be "ti,omap2430-sdhci" for omap2430 controllers
- Should be "ti,omap3-sdhci" for omap3 controllers
- Should be "ti,omap4-sdhci" for omap4 and ti81 controllers
- Should be "ti,omap5-sdhci" for omap5 controllers
- Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers
- Should be "ti,k2g-sdhci" for K2G
- Should be "ti,am335-sdhci" for am335x controllers
- Should be "ti,am437-sdhci" for am437x controllers
-- ti,hwmods: Must be "mmc<n>", <n> is controller instance starting 1
- (Not required for K2G).
-- pinctrl-names: Should be subset of "default", "hs", "sdr12", "sdr25", "sdr50",
- "ddr50-rev11", "sdr104-rev11", "ddr50", "sdr104",
- "ddr_1_8v-rev11", "ddr_1_8v" or "ddr_3_3v", "hs200_1_8v-rev11",
- "hs200_1_8v",
-- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
-
-Optional properties:
-- dmas: List of DMA specifiers with the controller specific format as described
- in the generic DMA client binding. A tx and rx specifier is required.
-- dma-names: List of DMA request names. These strings correspond 1:1 with the
- DMA specifiers listed in dmas. The string naming is to be "tx"
- and "rx" for TX and RX DMA requests, respectively.
-
-Deprecated properties:
-- ti,non-removable: Compatible with the generic non-removable property
-
-Example:
- mmc1: mmc@4809c000 {
- compatible = "ti,dra7-sdhci";
- reg = <0x4809c000 0x400>;
- ti,hwmods = "mmc1";
- bus-width = <4>;
- vmmc-supply = <&vmmc>; /* phandle to regulator node */
- dmas = <&sdma 61 &sdma 62>;
- dma-names = "tx", "rx";
- };
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
index 1c87f4218e18..186ce8ff4626 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mmc/sdhci-pxa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell PXA SDHCI v2/v3 bindings
+title: Marvell PXA SDHCI v1/v2/v3
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -18,7 +18,7 @@ allOf:
const: marvell,armada-380-sdhci
then:
properties:
- regs:
+ reg:
minItems: 3
reg-names:
minItems: 3
@@ -26,14 +26,52 @@ allOf:
- reg-names
else:
properties:
- regs:
+ reg:
maxItems: 1
reg-names:
maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mrvl,pxav1-mmc
+ then:
+ properties:
+ pinctrl-names:
+ description:
+ Optional for supporting PXA168 SDIO IRQ errata to switch CMD pin between
+ SDIO CMD and GPIO mode.
+ items:
+ - const: default
+ - const: state_cmd_gpio
+ minItems: 1
+
+ pinctrl-1:
+ description:
+ Should switch CMD pin to GPIO mode as a high output.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mrvl,pxav3-mmc
+ then:
+ properties:
+ pinctrl-names:
+ description:
+ Optional for increasing stability of the controller at fast bus clocks.
+ items:
+ - const: default
+ - const: state_uhs
+ minItems: 1
+
+ pinctrl-1:
+ description:
+ Should switch the drive strength of the data pins to high.
properties:
compatible:
enum:
+ - mrvl,pxav1-mmc
- mrvl,pxav2-mmc
- mrvl,pxav3-mmc
- marvell,armada-380-sdhci
@@ -61,6 +99,14 @@ properties:
- const: io
- const: core
+ pinctrl-names: true
+
+ pinctrl-0:
+ description:
+ Should contain default pinctrl.
+
+ pinctrl-1: true
+
mrvl,clk-delay-cycles:
description: Specify a number of cycles to delay for tuning.
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt b/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt
deleted file mode 100644
index eb7eb1b529f0..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Spreadtrum SDHCI controller (sdhci-sprd)
-
-The Secure Digital (SD) Host controller on Spreadtrum SoCs provides an interface
-for MMC, SD and SDIO types of cards.
-
-This file documents differences between the core properties in mmc.txt
-and the properties used by the sdhci-sprd driver.
-
-Required properties:
-- compatible: Should contain "sprd,sdhci-r11".
-- reg: physical base address of the controller and length.
-- interrupts: Interrupts used by the SDHCI controller.
-- clocks: Should contain phandle for the clock feeding the SDHCI controller
-- clock-names: Should contain the following:
- "sdio" - SDIO source clock (required)
- "enable" - gate clock which used for enabling/disabling the device (required)
- "2x_enable" - gate clock controlling the device for some special platforms (optional)
-
-Optional properties:
-- assigned-clocks: the same with "sdio" clock
-- assigned-clock-parents: the default parent of "sdio" clock
-- pinctrl-names: should be "default", "state_uhs"
-- pinctrl-0: should contain default/high speed pin control
-- pinctrl-1: should contain uhs mode pin control
-
-PHY DLL delays are used to delay the data valid window, and align the window
-to sampling clock. PHY DLL delays can be configured by following properties,
-and each property contains 4 cells which are used to configure the clock data
-write line delay value, clock read command line delay value, clock read data
-positive edge delay value and clock read data negative edge delay value.
-Each cell's delay value unit is cycle of the PHY clock.
-
-- sprd,phy-delay-legacy: Delay value for legacy timing.
-- sprd,phy-delay-sd-highspeed: Delay value for SD high-speed timing.
-- sprd,phy-delay-sd-uhs-sdr50: Delay value for SD UHS SDR50 timing.
-- sprd,phy-delay-sd-uhs-sdr104: Delay value for SD UHS SDR50 timing.
-- sprd,phy-delay-mmc-highspeed: Delay value for MMC high-speed timing.
-- sprd,phy-delay-mmc-ddr52: Delay value for MMC DDR52 timing.
-- sprd,phy-delay-mmc-hs200: Delay value for MMC HS200 timing.
-- sprd,phy-delay-mmc-hs400: Delay value for MMC HS400 timing.
-- sprd,phy-delay-mmc-hs400es: Delay value for MMC HS400 enhanced strobe timing.
-
-Examples:
-
-sdio0: sdio@20600000 {
- compatible = "sprd,sdhci-r11";
- reg = <0 0x20600000 0 0x1000>;
- interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
-
- clock-names = "sdio", "enable";
- clocks = <&ap_clk CLK_EMMC_2X>,
- <&apahb_gate CLK_EMMC_EB>;
- assigned-clocks = <&ap_clk CLK_EMMC_2X>;
- assigned-clock-parents = <&rpll CLK_RPLL_390M>;
-
- pinctrl-names = "default", "state_uhs";
- pinctrl-0 = <&sd0_pins_default>;
- pinctrl-1 = <&sd0_pins_uhs>;
-
- sprd,phy-delay-sd-uhs-sdr104 = <0x3f 0x7f 0x2e 0x2e>;
- bus-width = <8>;
- non-removable;
- no-sdio;
- no-sd;
- cap-mmc-hw-reset;
- status = "okay";
-};
diff --git a/Documentation/devicetree/bindings/mmc/sdhci.txt b/Documentation/devicetree/bindings/mmc/sdhci.txt
deleted file mode 100644
index 0e9923a64024..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-The properties specific for SD host controllers. For properties shared by MMC
-host controllers refer to the mmc[1] bindings.
-
- [1] Documentation/devicetree/bindings/mmc/mmc.txt
-
-Optional properties:
-- sdhci-caps-mask: The sdhci capabilities register is incorrect. This 64bit
- property corresponds to the bits in the sdhci capability register. If the bit
- is on in the mask then the bit is incorrect in the register and should be
- turned off, before applying sdhci-caps.
-- sdhci-caps: The sdhci capabilities register is incorrect. This 64bit
- property corresponds to the bits in the sdhci capability register. If the
- bit is on in the property then the bit should be turned on.
diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
index 71f8e726d641..7e7c55dc2440 100644
--- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
@@ -4,21 +4,33 @@
$id: http://devicetree.org/schemas/mmc/snps,dwcmshc-sdhci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Synopsys Designware Mobile Storage Host Controller Binding
+title: Synopsys Designware Mobile Storage Host Controller
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
- Jisheng Zhang <Jisheng.Zhang@synaptics.com>
-allOf:
- - $ref: mmc-controller.yaml#
-
properties:
compatible:
- enum:
- - rockchip,rk3568-dwcmshc
- - rockchip,rk3588-dwcmshc
- - snps,dwcmshc-sdhci
+ oneOf:
+ - items:
+ - enum:
+ - rockchip,rk3528-dwcmshc
+ - rockchip,rk3562-dwcmshc
+ - rockchip,rk3576-dwcmshc
+ - const: rockchip,rk3588-dwcmshc
+ - items:
+ - const: sophgo,sg2044-dwcmshc
+ - const: sophgo,sg2042-dwcmshc
+ - enum:
+ - rockchip,rk3568-dwcmshc
+ - rockchip,rk3588-dwcmshc
+ - snps,dwcmshc-sdhci
+ - sophgo,cv1800b-dwcmshc
+ - sophgo,sg2002-dwcmshc
+ - sophgo,sg2042-dwcmshc
+ - thead,th1520-dwcmshc
+ - eswin,eic7700-dwcmshc
reg:
maxItems: 1
@@ -28,27 +40,42 @@ properties:
clocks:
minItems: 1
- items:
- - description: core clock
- - description: bus clock for optional
- - description: axi clock for rockchip specified
- - description: block clock for rockchip specified
- - description: timer clock for rockchip specified
-
+ maxItems: 5
clock-names:
minItems: 1
- items:
- - const: core
- - const: bus
- - const: axi
- - const: block
- - const: timer
+ maxItems: 5
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 5
+
+ reset-names:
+ maxItems: 5
rockchip,txclk-tapnum:
description: Specify the number of delay for tx sampling.
$ref: /schemas/types.yaml#/definitions/uint8
+ eswin,hsp-sp-csr:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to HSP(High-Speed Peripheral) device
+ - description: Offset of the stability status register for internal
+ clock.
+ - description: Offset of the stability register for host regulator
+ voltage.
+ description:
+ HSP CSR is to control and get status of different high-speed peripherals
+ (such as Ethernet, USB, SATA, etc.) via register, which can tune
+ board-level's parameters of PHY, etc.
+
+ eswin,drive-impedance-ohms:
+ description: Specifies the drive impedance in Ohm.
+ enum: [33, 40, 50, 66, 100]
required:
- compatible
@@ -57,6 +84,87 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: mmc-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: sophgo,sg2042-dwcmshc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: core clock
+ - description: bus clock
+ - description: timer clock
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+ - const: timer
+ else:
+ properties:
+ clocks:
+ minItems: 1
+ items:
+ - description: core clock
+ - description: bus clock for optional
+ - description: axi clock for rockchip specified
+ - description: block clock for rockchip specified
+ - description: timer clock for rockchip specified
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: bus
+ - const: axi
+ - const: block
+ - const: timer
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: eswin,eic7700-dwcmshc
+ then:
+ properties:
+ resets:
+ minItems: 4
+ maxItems: 4
+ reset-names:
+ items:
+ - const: axi
+ - const: phy
+ - const: prstn
+ - const: txrx
+ required:
+ - eswin,hsp-sp-csr
+ - eswin,drive-impedance-ohms
+ else:
+ properties:
+ resets:
+ maxItems: 5
+ reset-names:
+ items:
+ - const: core
+ - const: bus
+ - const: axi
+ - const: block
+ - const: timer
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3576-dwcmshc
+
+ then:
+ required:
+ - power-domains
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/mmc/socionext,milbeaut-m10v-sdhci-3.0.yaml b/Documentation/devicetree/bindings/mmc/socionext,milbeaut-m10v-sdhci-3.0.yaml
new file mode 100644
index 000000000000..2ba53626a959
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/socionext,milbeaut-m10v-sdhci-3.0.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/socionext,milbeaut-m10v-sdhci-3.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SOCIONEXT Milbeaut SDHCI controller
+
+maintainers:
+ - Taichi Sugaya <sugaya.taichi@socionext.com>
+ - Takao Orito <orito.takao@socionext.com>
+
+description:
+ The SOCIONEXT Milbeaut SDHCI controller is a specialized SD Host
+ Controller found in some of Socionext's Milbeaut image processing SoCs.
+ It features a dedicated "bridge controller." This bridge controller
+ implements special functions like reset control, clock management for
+ various SDR modes (SDR12, SDR25, SDR50) and physical pin property settings.
+
+allOf:
+ - $ref: sdhci-common.yaml#
+
+properties:
+ compatible:
+ const: socionext,milbeaut-m10v-sdhci-3.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+
+ fujitsu,cmd-dat-delay-select:
+ description:
+ Its presence indicates that the controller requires a specific command
+ and data line delay selection mechanism for proper operation, particularly
+ when dealing with high-speed SD/eMMC modes.
+ type: boolean
+
+ voltage-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: minimum slot voltage (mV).
+ - description: maximum slot voltage (mV).
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mmc@1b010000 {
+ compatible = "socionext,milbeaut-m10v-sdhci-3.0";
+ reg = <0x1b010000 0x10000>;
+ interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
+ voltage-ranges = <3300 3300>;
+ bus-width = <4>;
+ clocks = <&clk 7>, <&ahb_clk>;
+ clock-names = "core", "iface";
+ cap-sdio-irq;
+ fujitsu,cmd-dat-delay-select;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
index a586fad0a46b..c71424aeaccd 100644
--- a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
+++ b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml
@@ -55,6 +55,16 @@ properties:
minItems: 1
maxItems: 3
+ socionext,syscon-uhs-mode:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscon that configures UHS mode
+ - description: ID of SD instance
+ description:
+ A phandle to syscon with one argument that configures UHS mode.
+ The argument is the ID of SD instance.
+
allOf:
- $ref: mmc-controller.yaml
diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
new file mode 100644
index 000000000000..13d9382058fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/spacemit,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT SDHCI Controller
+
+maintainers:
+ - Yixun Lan <dlan@gentoo.org>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: core clock, used by internal controller
+ - description: io clock, output for SD, SDIO, eMMC device
+
+ clock-names:
+ items:
+ - const: core
+ - const: io
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@d4281000 {
+ compatible = "spacemit,k1-sdhci";
+ reg = <0xd4281000 0x200>;
+ interrupts = <101>;
+ interrupt-parent = <&plic>;
+ clocks = <&clk_apmu 10>, <&clk_apmu 13>;
+ clock-names = "core", "io";
+ };
diff --git a/Documentation/devicetree/bindings/mmc/sprd,sdhci-r11.yaml b/Documentation/devicetree/bindings/mmc/sprd,sdhci-r11.yaml
new file mode 100644
index 000000000000..b08081bc018b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sprd,sdhci-r11.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/sprd,sdhci-r11.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SDHCI controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,sdhci-r11
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ items:
+ - description: SDIO source clock
+ - description: gate clock for enabling/disabling the device
+ - description: gate clock controlling the device for some special platforms (optional)
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: sdio
+ - const: enable
+ - const: 2x_enable
+
+ pinctrl-0:
+ description: default/high speed pin control
+ maxItems: 1
+
+ pinctrl-1:
+ description: UHS mode pin control
+ maxItems: 1
+
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: state_uhs
+
+patternProperties:
+ "^sprd,phy-delay-(legacy|mmc-(ddr52|highspeed|hs[24]00|hs400es)|sd-(highspeed|uhs-sdr(50|104)))$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: clock data write line delay value
+ - description: clock read command line delay value
+ - description: clock read data positive edge delay value
+ - description: clock read data negative edge delay value
+ description:
+ PHY DLL delays are used to delay the data valid window, and align
+ the window to the sampling clock. Each cell's delay value unit is
+ cycle of the PHY clock.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: sdhci-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sprd,sc9860-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mmc@50430000 {
+ compatible = "sprd,sdhci-r11";
+ reg = <0x50430000 0x1000>;
+ interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&aon_prediv CLK_EMMC_2X>,
+ <&apahb_gate CLK_EMMC_EB>,
+ <&aon_gate CLK_EMMC_2X_EN>;
+ clock-names = "sdio", "enable", "2x_enable";
+
+ pinctrl-0 = <&sd0_pins_default>;
+ pinctrl-1 = <&sd0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ bus-width = <8>;
+ cap-mmc-hw-reset;
+ mmc-hs400-enhanced-strobe;
+ mmc-hs400-1_8v;
+ mmc-hs200-1_8v;
+ mmc-ddr-1_8v;
+ non-removable;
+ no-sdio;
+ no-sd;
+
+ sprd,phy-delay-mmc-ddr52 = <0x3f 0x75 0x14 0x14>;
+ sprd,phy-delay-mmc-hs200 = <0x0 0x8c 0x8c 0x8c>;
+ sprd,phy-delay-mmc-hs400 = <0x44 0x7f 0x2e 0x2e>;
+ sprd,phy-delay-mmc-hs400es = <0x3f 0x3f 0x2e 0x2e>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml b/Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml
new file mode 100644
index 000000000000..553a75195c2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/starfive,jh7110-mmc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/starfive,jh7110-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive Designware Mobile Storage Host Controller
+
+description:
+ StarFive uses the Synopsys designware mobile storage host controller
+ to interface a SoC with storage medium such as eMMC or SD/MMC cards.
+
+allOf:
+ - $ref: synopsys-dw-mshc-common.yaml#
+
+maintainers:
+ - William Qiu <william.qiu@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-mmc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: biu clock
+ - description: ciu clock
+
+ clock-names:
+ items:
+ - const: biu
+ - const: ciu
+
+ interrupts:
+ maxItems: 1
+
+ starfive,sysreg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller syscon node
+ - description: offset of SYS_SYSCONSAIF__SYSCFG register for MMC controller
+ - description: shift of SYS_SYSCONSAIF__SYSCFG register for MMC controller
+ - description: mask of SYS_SYSCONSAIF__SYSCFG register for MMC controller
+ description:
+ Should be four parameters, the phandle to System Register Controller
+ syscon node and the offset/shift/mask of SYS_SYSCONSAIF__SYSCFG register
+ for MMC controller.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@16010000 {
+ compatible = "starfive,jh7110-mmc";
+ reg = <0x16010000 0x10000>;
+ clocks = <&syscrg 91>,
+ <&syscrg 93>;
+ clock-names = "biu","ciu";
+ resets = <&syscrg 64>;
+ reset-names = "reset";
+ interrupts = <74>;
+ fifo-depth = <32>;
+ fifo-watermark-aligned;
+ data-addr = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml b/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml
new file mode 100644
index 000000000000..611687166735
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sunplus,mmc.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) Sunplus Ltd. Co. 2021
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/sunplus,mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sunplus MMC Controller
+
+maintainers:
+ - Tony Huang <tonyhuang.sunplus@gmail.com>
+ - Li-hao Kuo <lhjeff911@gmail.com>
+
+allOf:
+ - $ref: mmc-controller.yaml
+
+properties:
+ compatible:
+ enum:
+ - sunplus,sp7021-mmc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mmc0: mmc@9c003b00 {
+ compatible = "sunplus,sp7021-mmc";
+ reg = <0x9c003b00 0x180>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc 0x4e>;
+ resets = <&rstc 0x3e>;
+ bus-width = <8>;
+ max-frequency = <52000000>;
+ non-removable;
+ disable-wp;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ no-sdio;
+ no-sd;
+ };
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
index 8dfad89c78a7..6f11b2adf103 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Synopsys Designware Mobile Storage Host Controller Common Properties
allOf:
- - $ref: "mmc-controller.yaml#"
+ - $ref: mmc-controller.yaml#
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml
index ae6d6fca79e2..a6292777e376 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml
@@ -4,10 +4,7 @@
$id: http://devicetree.org/schemas/mmc/synopsys-dw-mshc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Synopsys Designware Mobile Storage Host Controller Binding
-
-allOf:
- - $ref: "synopsys-dw-mshc-common.yaml#"
+title: Synopsys Designware Mobile Storage Host Controller
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -38,6 +35,39 @@ properties:
- const: biu
- const: ciu
+ iommus:
+ maxItems: 1
+
+ altr,sysmgr-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to the sysmgr node
+ - description: register offset that controls the SDMMC clock phase
+ - description: register shift for the smplsel(drive in) setting
+ description:
+ This property is optional. Contains the phandle to System Manager block
+ that contains the SDMMC clock-phase control register. The first value is
+ the pointer to the sysmgr, the 2nd value is the register offset for the
+ SDMMC clock phase register, and the 3rd value is the bit shift for the
+ smplsel(drive in) setting.
+
+allOf:
+ - $ref: synopsys-dw-mshc-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: altr,socfpga-dw-mshc
+ then:
+ properties:
+ altr,sysmgr-syscon: true
+ else:
+ properties:
+ iommus: false
+ altr,sysmgr-syscon: false
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/mmc/ti,da830-mmc.yaml b/Documentation/devicetree/bindings/mmc/ti,da830-mmc.yaml
new file mode 100644
index 000000000000..36b33dde086b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti,da830-mmc.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/ti,da830-mmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Highspeed MMC host controller for DaVinci
+
+description:
+ The Highspeed MMC Host Controller on TI DaVinci family
+ provides an interface for MMC, SD and SDIO types of memory cards.
+
+allOf:
+ - $ref: mmc-controller.yaml
+
+maintainers:
+ - Kishon Vijay Abraham I <kishon@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - ti,da830-mmc
+ - ti,dm355-mmc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ mmc@1c40000 {
+ compatible = "ti,da830-mmc";
+ reg = <0x40000 0x1000>;
+ interrupts = <16 IRQ_TYPE_LEVEL_HIGH>,
+ <17 IRQ_TYPE_LEVEL_HIGH>;
+ bus-width = <4>;
+ max-frequency = <50000000>;
+ dmas = <&edma 16>, <&edma 17>;
+ dma-names = "rx", "tx";
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/ti,omap2430-sdhci.yaml b/Documentation/devicetree/bindings/mmc/ti,omap2430-sdhci.yaml
new file mode 100644
index 000000000000..34e288f3ef13
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti,omap2430-sdhci.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/ti,omap2430-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI OMAP SDHCI Controller
+
+maintainers:
+ - Kishon Vijay Abraham I <kishon@ti.com>
+
+description:
+ For UHS devices which require tuning, the device tree should have a
+ cpu_thermal node which maps to the appropriate thermal zone. This
+ is used to get the temperature of the zone during tuning.
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2430-sdhci
+ - ti,omap3-sdhci
+ - ti,omap4-sdhci
+ - ti,omap5-sdhci
+ - ti,dra7-sdhci
+ - ti,k2g-sdhci
+ - ti,am335-sdhci
+ - ti,am437-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: fck
+ - const: mmchsdb_fck
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ pinctrl-names:
+ minItems: 1
+ maxItems: 14
+ items:
+ enum:
+ - default
+ - default-rev11
+ - hs
+ - sdr12
+ - sdr12-rev11
+ - sdr25
+ - sdr25-rev11
+ - sdr50
+ - ddr50-rev11
+ - sdr104-rev11
+ - ddr50
+ - sdr104
+ - ddr_1_8v-rev11
+ - ddr_1_8v
+ - ddr_3_3v
+ - hs-rev11
+ - hs200_1_8v-rev11
+ - hs200_1_8v
+ - sleep
+
+ pinctrl-0:
+ maxItems: 1
+
+ pinctrl-1:
+ maxItems: 1
+
+ pinctrl-2:
+ maxItems: 1
+
+ pinctrl-3:
+ maxItems: 1
+
+ pinctrl-4:
+ maxItems: 1
+
+ pinctrl-5:
+ maxItems: 1
+
+ pinctrl-6:
+ maxItems: 1
+
+ pinctrl-7:
+ maxItems: 1
+
+ pinctrl-8:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ pbias-supply:
+ description:
+ It is used to specify the voltage regulator that provides the bias
+ voltage for certain analog or I/O pads.
+
+ ti,non-removable:
+ description:
+ It indicates that a component is not meant to be easily removed or
+ replaced by the user, such as an embedded battery or a non-removable
+ storage slot like eMMC.
+ type: boolean
+ deprecated: true
+
+ clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ It represents the speed at which a clock signal associated with a device
+ or bus operates, measured in Hertz (Hz). This value is crucial for configuring
+ hardware components that require a specific clock speed.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: sdhci-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,dra7-sdhci
+ - ti,k2g-sdhci
+ then:
+ required:
+ - max-frequency
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,k2g-sdhci
+ then:
+ required:
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mmc@4809c000 {
+ compatible = "ti,dra7-sdhci";
+ reg = <0x4809c000 0x400>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ max-frequency = <192000000>;
+ sdhci-caps-mask = <0x0 0x400000>;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ dmas = <&sdma 61>, <&sdma 62>;
+ dma-names = "tx", "rx";
+ };
+...
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 57d077c0b7c1..7a0e9dcdc444 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -95,7 +95,7 @@ while in suspend.
| card | -- CIRQ --> | hsmmc | -- IRQ --> | CPU |
------ ------- -----
-In suspend the fclk is off and the module is disfunctional. Even register reads
+In suspend the fclk is off and the module is dysfunctional. Even register reads
will fail. A small logic in the host will request fclk restore, when an
external event is detected. Once the clock is restored, the host detects the
event normally. Since am33xx doesn't have this line it never wakes from
diff --git a/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt b/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt
deleted file mode 100644
index d7fb6abb3eb8..000000000000
--- a/Documentation/devicetree/bindings/mmc/vt8500-sdmmc.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Wondermedia WM8505/WM8650 SD/MMC Host Controller
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the wmt-sdmmc driver.
-
-Required properties:
-- compatible: Should be "wm,wm8505-sdhc".
-- interrupts: Two interrupts are required - regular irq and dma irq.
-
-Optional properties:
-- sdon-inverted: SD_ON bit is inverted on the controller
-
-Examples:
-
-sdhc@d800a000 {
- compatible = "wm,wm8505-sdhc";
- reg = <0xd800a000 0x1000>;
- interrupts = <20 21>;
- clocks = <&sdhc>;
- bus-width = <4>;
- sdon-inverted;
-};
-
diff --git a/Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml b/Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml
new file mode 100644
index 000000000000..5b55174e9088
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/wm,wm8505-sdhc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/wm,wm8505-sdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: WonderMedia SoC SDHCI Controller
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: wm,wm8505-sdhc
+ - items:
+ - const: wm,wm8650-sdhc
+ - const: wm,wm8505-sdhc
+ - items:
+ - const: wm,wm8750-sdhc
+ - const: wm,wm8505-sdhc
+ - items:
+ - const: wm,wm8850-sdhc
+ - const: wm,wm8505-sdhc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: SDMMC controller interrupt
+ - description: SDMMC controller DMA interrupt
+
+ sdon-inverted:
+ type: boolean
+ description: All chips before (not including) WM8505 rev. A2 treated their
+ "clock stop" bit (register offset 0x08 a.k.a. SDMMC_BUSMODE, bit 0x10)
+ as "set 1 to disable SD clock", while all the later versions treated it
+ as "set 0 to disable SD clock". Set this property for later versions of
+ wm,wm8505-sdhc. On wm,wm8650-sdhc and later this property is implied and
+ does not need to be set explicitly
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mmc@d800a000 {
+ compatible = "wm,wm8505-sdhc";
+ reg = <0xd800a000 0x1000>;
+ interrupts = <20>, <21>;
+ clocks = <&sdhc>;
+ bus-width = <4>;
+ sdon-inverted;
+ };
diff --git a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
index c033ac3f147d..9d061e2216cb 100644
--- a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
@@ -4,23 +4,19 @@
$id: http://devicetree.org/schemas/mtd/allwinner,sun4i-a10-nand.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 NAND Controller Device Tree Bindings
-
-allOf:
- - $ref: "nand-controller.yaml"
+title: Allwinner A10 NAND Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
enum:
- allwinner,sun4i-a10-nand
- allwinner,sun8i-a23-nand-controller
+ - allwinner,sun50i-h616-nand-controller
+
reg:
maxItems: 1
@@ -28,14 +24,20 @@ properties:
maxItems: 1
clocks:
+ minItems: 2
items:
- description: Bus Clock
- description: Module Clock
+ - description: ECC Clock
+ - description: MBus Clock
clock-names:
+ minItems: 2
items:
- const: ahb
- const: mod
+ - const: ecc
+ - const: mbus
resets:
maxItems: 1
@@ -49,20 +51,15 @@ properties:
dma-names:
const: rxtx
- pinctrl-names: true
-
patternProperties:
- "^pinctrl-[0-9]+$": true
-
- "^nand@[a-f0-9]+$":
+ "^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
reg:
minimum: 0
maximum: 7
- nand-ecc-mode: true
-
nand-ecc-algo:
const: bch
@@ -82,7 +79,7 @@ patternProperties:
minimum: 0
maximum: 1
- additionalProperties: false
+ unevaluatedProperties: false
required:
- compatible
@@ -91,6 +88,59 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
+
+allOf:
+ - $ref: nand-controller.yaml
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun4i-a10-nand
+ - allwinner,sun8i-a23-nand-controller
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun50i-h616-nand-controller
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/sun6i-rtc.h>
+ #include <dt-bindings/clock/sun8i-a23-a33-ccu.h>
+ #include <dt-bindings/reset/sun8i-a23-a33-ccu.h>
+
+ nand-controller@1c03000 {
+ compatible = "allwinner,sun8i-a23-nand-controller";
+ reg = <0x01c03000 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_NAND>, <&ccu CLK_NAND>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_NAND>;
+ reset-names = "ahb";
+ dmas = <&dma 5>;
+ dma-names = "rxtx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins &nand_cs0_pin &nand_rb0_pin>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
...
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
deleted file mode 100644
index 5794ab1147c1..000000000000
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Amlogic NAND Flash Controller (NFC) for GXBB/GXL/AXG family SoCs
-
-This file documents the properties in addition to those available in
-the MTD NAND bindings.
-
-Required properties:
-- compatible : contains one of:
- - "amlogic,meson-gxl-nfc"
- - "amlogic,meson-axg-nfc"
-- clocks :
- A list of phandle + clock-specifier pairs for the clocks listed
- in clock-names.
-
-- clock-names: Should contain the following:
- "core" - NFC module gate clock
- "device" - device clock from eMMC sub clock controller
- "rx" - rx clock phase
- "tx" - tx clock phase
-
-- amlogic,mmc-syscon : Required for NAND clocks, it's shared with SD/eMMC
- controller port C
-
-Optional children nodes:
-Children nodes represent the available nand chips.
-
-Other properties:
-see Documentation/devicetree/bindings/mtd/nand-controller.yaml for generic bindings.
-
-Example demonstrate on AXG SoC:
-
- sd_emmc_c_clkc: mmc@7000 {
- compatible = "amlogic,meson-axg-mmc-clkc", "syscon";
- reg = <0x0 0x7000 0x0 0x800>;
- };
-
- nand-controller@7800 {
- compatible = "amlogic,meson-axg-nfc";
- reg = <0x0 0x7800 0x0 0x100>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>;
-
- clocks = <&clkc CLKID_SD_EMMC_C>,
- <&sd_emmc_c_clkc CLKID_MMC_DIV>,
- <&sd_emmc_c_clkc CLKID_MMC_PHASE_RX>,
- <&sd_emmc_c_clkc CLKID_MMC_PHASE_TX>;
- clock-names = "core", "device", "rx", "tx";
- amlogic,mmc-syscon = <&sd_emmc_c_clkc>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&nand_pins>;
-
- nand@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- nand-on-flash-bbt;
- };
- };
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
new file mode 100644
index 000000000000..fa2aa29be794
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/amlogic,meson-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic NAND Flash Controller (NFC) for GXBB/GXL/AXG family SoCs
+
+allOf:
+ - $ref: nand-controller.yaml
+
+maintainers:
+ - liang.yang@amlogic.com
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxl-nfc
+ - amlogic,meson-axg-nfc
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: nfc
+ - const: emmc
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: device
+
+patternProperties:
+ "^nand@[0-7]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+ properties:
+ reg:
+ minimum: 0
+ maximum: 1
+
+ nand-ecc-mode:
+ const: hw
+
+ nand-ecc-step-size:
+ enum: [512, 1024]
+
+ nand-ecc-strength:
+ enum: [8, 16, 24, 30, 40, 50, 60]
+ description: |
+ The ECC configurations that can be supported are as follows.
+ meson-gxl-nfc 8, 16, 24, 30, 40, 50, 60
+ meson-axg-nfc 8
+
+ nand-rb:
+ maxItems: 1
+ items:
+ maximum: 0
+
+ amlogic,boot-pages:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of pages starting from offset 0, where a special ECC
+ configuration must be used because it is accessed by the ROM
+ code. This ECC configuration uses 384 bytes data blocks.
+ Also scrambling mode is enabled for such pages.
+
+ amlogic,boot-page-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Interval between pages, accessed by the ROM code. For example
+ we have 8 pages [0, 7]. Pages 0,2,4,6 are accessed by the
+ ROM code, so this field will be 2 (e.g. every 2nd page). Rest
+ of pages - 1,3,5,7 are read/written without this mode.
+
+ unevaluatedProperties: false
+
+ dependencies:
+ nand-ecc-strength: [nand-ecc-step-size]
+ nand-ecc-step-size: [nand-ecc-strength]
+ amlogic,boot-pages: [nand-is-boot-medium, "amlogic,boot-page-step"]
+ amlogic,boot-page-step: [nand-is-boot-medium, "amlogic,boot-pages"]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-clkc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ nand-controller@ffe07800 {
+ compatible = "amlogic,meson-axg-nfc";
+ reg = <0xffe07800 0x100>, <0xffe07000 0x800>;
+ reg-names = "nfc", "emmc";
+ interrupts = <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_SD_EMMC_C>, <&clkc CLKID_FCLK_DIV2>;
+ clock-names = "core", "device";
+
+ pinctrl-0 = <&nand_pins>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-rb = <0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
index b32876933269..b90d3b48c2f2 100644
--- a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/mtd/arasan,nand-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Arasan NAND Flash Controller with ONFI 3.1 support device tree bindings
+title: Arasan NAND Flash Controller with ONFI 3.1 support
allOf:
- - $ref: "nand-controller.yaml"
+ - $ref: nand-controller.yaml
maintainers:
- - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
@@ -35,9 +35,6 @@ properties:
interrupts:
maxItems: 1
- "#address-cells": true
- "#size-cells": true
-
required:
- compatible
- reg
@@ -45,7 +42,7 @@ required:
- clock-names
- interrupts
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
index 5f126bb9b202..7bd7c55a9c15 100644
--- a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
+++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml
@@ -4,14 +4,13 @@
$id: http://devicetree.org/schemas/mtd/arm,pl353-nand-r2p1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: PL353 NAND Controller device tree bindings
+title: PL353 NAND Controller
allOf:
- - $ref: "nand-controller.yaml"
+ - $ref: nand-controller.yaml
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
- - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
properties:
compatible:
@@ -34,20 +33,20 @@ unevaluatedProperties: false
examples:
- |
smcc: memory-controller@e000e000 {
- compatible = "arm,pl353-smc-r2p1", "arm,primecell";
- reg = <0xe000e000 0x0001000>;
- clock-names = "memclk", "apb_pclk";
- clocks = <&clkc 11>, <&clkc 44>;
- ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */
- 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */
- 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */
- #address-cells = <2>;
- #size-cells = <1>;
-
- nfc0: nand-controller@0,0 {
- compatible = "arm,pl353-nand-r2p1";
- reg = <0 0 0x1000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
+ compatible = "arm,pl353-smc-r2p1", "arm,primecell";
+ reg = <0xe000e000 0x0001000>;
+ clock-names = "memclk", "apb_pclk";
+ clocks = <&clkc 11>, <&clkc 44>;
+ ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */
+ 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */
+ 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ nfc0: nand-controller@0,0 {
+ compatible = "arm,pl353-nand-r2p1";
+ reg = <0 0 0x1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml b/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml
new file mode 100644
index 000000000000..8c72fa346e36
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/atmel,dataflash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel DataFlash
+
+maintainers:
+ - Nayab Sayed <nayabbasha.sayed@microchip.com>
+
+description:
+ The Atmel DataFlash is a low pin-count serial interface sequential access
+ Flash memory, compatible with SPI standard. The device tree may optionally
+ contain sub-nodes describing partitions of the address space.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at45db321d
+ - atmel,at45db041e
+ - atmel,at45db642d
+ - atmel,at45db021d
+ - const: atmel,at45
+ - const: atmel,dataflash
+ - items:
+ - const: atmel,at45
+ - const: atmel,dataflash
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: mtd.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@1 {
+ compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash";
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt b/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt
deleted file mode 100644
index 1889a4db5b7c..000000000000
--- a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Atmel Data Flash
-
-Required properties:
-- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
-
-The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
-
-Example:
-
-flash@1 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash";
- spi-max-frequency = <25000000>;
- reg = <1>;
-};
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 3aa297c97ab6..e36c35b17873 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -45,10 +45,8 @@ Optional properties:
- atmel,rb: an integer identifying the native Ready/Busy pin. Only meaningful
on sama5 SoCs.
-All generic properties described in
-Documentation/devicetree/bindings/mtd/{common,nand}.txt also apply to the NAND
-device node, and NAND partitions should be defined under the NAND node as
-described in Documentation/devicetree/bindings/mtd/partition.txt.
+All generic properties are described in the generic yaml files under
+Documentation/devicetree/bindings/mtd/.
* ECC engine (PMECC) bindings:
@@ -58,18 +56,10 @@ Required properties:
"atmel,sama5d4-pmecc"
"atmel,sama5d2-pmecc"
"microchip,sam9x60-pmecc"
+ "microchip,sam9x7-pmecc", "atmel,at91sam9g45-pmecc"
- reg: should contain 2 register ranges. The first one is pointing to the PMECC
block, and the second one to the PMECC_ERRLOC block.
-* SAMA5 NFC I/O bindings:
-
-SAMA5 SoCs embed an advanced NAND controller logic to automate READ/WRITE page
-operations. This interface to this logic is placed in a separate I/O range and
-should thus have its own DT node.
-
-- compatible: should be "atmel,sama5d3-nfc-io", "syscon".
-- reg: should contain the I/O range used to interact with the NFC logic.
-
Example:
nfc_io: nfc-io@70000000 {
diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
index dd5a64969e37..064e840aeaa1 100644
--- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
+++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
@@ -9,6 +9,7 @@ title: Broadcom STB NAND Controller
maintainers:
- Brian Norris <computersforpeace@gmail.com>
- Kamal Dasu <kdasu.kdev@gmail.com>
+ - William Zhang <william.zhang@broadcom.com>
description: |
The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND
@@ -18,9 +19,10 @@ description: |
supports basic PROGRAM and READ functions, among other features.
This controller was originally designed for STB SoCs (BCM7xxx) but is now
- available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and
- iProc/Cygnus. Its history includes several similar (but not fully register
- compatible) versions.
+ available on a variety of Broadcom SoCs, including some BCM3xxx, MIPS based
+ Broadband SoC (BCM63xx), ARM based Broadband SoC (BCMBCA) and iProc/Cygnus.
+ Its history includes several similar (but not fully register compatible)
+ versions.
-- Additional SoC-specific NAND controller properties --
@@ -53,7 +55,7 @@ properties:
- brcm,brcmnand-v7.2
- brcm,brcmnand-v7.3
- const: brcm,brcmnand
- - description: BCM63138 SoC-specific NAND controller
+ - description: BCMBCA SoC-specific NAND controller
items:
- const: brcm,nand-bcm63138
- enum:
@@ -86,15 +88,15 @@ properties:
minItems: 1
items:
- description: NAND CTLRDY interrupt
- - description: FLASH_DMA_DONE if flash DMA is available
- - description: FLASH_EDU_DONE if EDU is available
+ - description: FLASH_DMA_DONE (if flash DMA is available) or FLASH_EDU_DONE (if EDU is available)
interrupt-names:
minItems: 1
items:
- const: nand_ctlrdy
- - const: flash_dma_done
- - const: flash_edu_done
+ - enum:
+ - flash_dma_done
+ - flash_edu_done
clocks:
maxItems: 1
@@ -111,9 +113,17 @@ properties:
earlier versions of this core that include WP
type: boolean
+ brcm,wp-not-connected:
+ description:
+ Use this property when WP pin is not physically wired to the NAND chip.
+ Write protection feature cannot be used. By default, controller assumes
+ the pin is connected and feature is used.
+ $ref: /schemas/types.yaml#/definitions/flag
+
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
compatible:
const: brcm,nandcs
@@ -136,6 +146,17 @@ patternProperties:
layout.
$ref: /schemas/types.yaml#/definitions/uint32
+ brcm,nand-ecc-use-strap:
+ description:
+ This property requires the host system to get the ECC related
+ settings from the SoC NAND boot strap configuration instead of
+ the generic NAND ECC settings. This is a common hardware design
+ on BCMBCA based boards. This strap ECC option and generic NAND
+ ECC option can not be specified at the same time.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ unevaluatedProperties: false
+
allOf:
- $ref: nand-controller.yaml#
- if:
@@ -173,62 +194,86 @@ allOf:
- const: nand
- const: iproc-idm
- const: iproc-ext
+ - if:
+ required:
+ - interrupts
+ properties:
+ interrupts:
+ minItems: 2
+ then:
+ required:
+ - interrupt-names
+
+ - if:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ required:
+ - brcm,nand-ecc-use-strap
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-strength: false
+ nand-ecc-step-size: false
+ nand-ecc-maximize: false
+ nand-ecc-algo: false
+ brcm,nand-oob-sector-size: false
unevaluatedProperties: false
required:
- reg
- reg-names
- - interrupts
examples:
- |
nand-controller@f0442800 {
- compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand";
- reg = <0xf0442800 0x600>,
- <0xf0443000 0x100>;
- reg-names = "nand", "flash-dma";
- interrupt-parent = <&hif_intr2_intc>;
- interrupts = <24>, <4>;
+ compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand";
+ reg = <0xf0442800 0x600>,
+ <0xf0443000 0x100>;
+ reg-names = "nand", "flash-dma";
+ interrupt-parent = <&hif_intr2_intc>;
+ interrupts = <24>, <4>;
+ interrupt-names = "nand_ctlrdy", "flash_dma_done";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@1 {
+ compatible = "brcm,nandcs";
+ reg = <1>; // Chip select 1
+ nand-on-flash-bbt;
+ nand-ecc-strength = <12>;
+ nand-ecc-step-size = <512>;
#address-cells = <1>;
- #size-cells = <0>;
-
- nand@1 {
- compatible = "brcm,nandcs";
- reg = <1>; // Chip select 1
- nand-on-flash-bbt;
- nand-ecc-strength = <12>;
- nand-ecc-step-size = <512>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- };
+ #size-cells = <1>;
+ };
};
- |
nand-controller@10000200 {
- compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
- "brcm,brcmnand-v4.0", "brcm,brcmnand";
- reg = <0x10000200 0x180>,
- <0x100000b0 0x10>,
- <0x10000600 0x200>;
- reg-names = "nand", "nand-int-base", "nand-cache";
- interrupt-parent = <&periph_intc>;
- interrupts = <50>;
- clocks = <&periph_clk 20>;
- clock-names = "nand";
+ compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
+ "brcm,brcmnand-v4.0", "brcm,brcmnand";
+ reg = <0x10000200 0x180>,
+ <0x100000b0 0x10>,
+ <0x10000600 0x200>;
+ reg-names = "nand", "nand-int-base", "nand-cache";
+ interrupt-parent = <&periph_intc>;
+ interrupts = <50>;
+ clocks = <&periph_clk 20>;
+ clock-names = "nand";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <1>;
+ nand-ecc-step-size = <512>;
#address-cells = <1>;
- #size-cells = <0>;
-
- nand@0 {
- compatible = "brcm,nandcs";
- reg = <0>;
- nand-on-flash-bbt;
- nand-ecc-strength = <1>;
- nand-ecc-step-size = <512>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- };
+ #size-cells = <1>;
+ };
};
diff --git a/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt b/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt
deleted file mode 100644
index d2eada5044b2..000000000000
--- a/Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Cadence NAND controller
-
-Required properties:
- - compatible : "cdns,hp-nfc"
- - reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the Slave DMA data port.
- - reg-names: should contain "reg" and "sdma"
- - #address-cells: should be 1. The cell encodes the chip select connection.
- - #size-cells : should be 0.
- - interrupts : The interrupt number.
- - clocks: phandle of the controller core clock (nf_clk).
-
-Optional properties:
- - dmas: shall reference DMA channel associated to the NAND controller
- - cdns,board-delay-ps : Estimated Board delay. The value includes the total
- round trip delay for the signals and is used for deciding on values
- associated with data read capture. The example formula for SDR mode is
- the following:
- board delay = RE#PAD delay + PCB trace to device + PCB trace from device
- + DQ PAD delay
-
-Child nodes represent the available NAND chips.
-
-Required properties of NAND chips:
- - reg: shall contain the native Chip Select ids from 0 to max supported by
- the cadence nand flash controller
-
-See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on
-generic bindings.
-
-Example:
-
-nand_controller: nand-controller@60000000 {
- compatible = "cdns,hp-nfc";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x60000000 0x10000>, <0x80000000 0x10000>;
- reg-names = "reg", "sdma";
- clocks = <&nf_clk>;
- cdns,board-delay-ps = <4830>;
- interrupts = <2 0>;
- nand@0 {
- reg = <0>;
- label = "nand-1";
- };
- nand@1 {
- reg = <1>;
- label = "nand-2";
- };
-
-};
diff --git a/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml b/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml
new file mode 100644
index 000000000000..73dc69cee4d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/cdns,hp-nfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence NAND controller
+
+maintainers:
+ - Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
+
+allOf:
+ - $ref: nand-controller.yaml
+
+properties:
+ compatible:
+ items:
+ - const: cdns,hp-nfc
+
+ reg:
+ items:
+ - description: Controller register set
+ - description: Slave DMA data port register set
+
+ reg-names:
+ items:
+ - const: reg
+ - const: sdma
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: nf_clk
+
+ dmas:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ cdns,board-delay-ps:
+ description: |
+ Estimated Board delay. The value includes the total round trip
+ delay for the signals and is used for deciding on values associated
+ with data read capture. The example formula for SDR mode is the
+ following.
+ board delay = RE#PAD delay + PCB trace to device + PCB trace from device
+ + DQ PAD delay
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ nand-controller@10b80000 {
+ compatible = "cdns,hp-nfc";
+ reg = <0x10b80000 0x10000>,
+ <0x10840000 0x10000>;
+ reg-names = "reg", "sdma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk>;
+ clock-names = "nf_clk";
+ cdns,board-delay-ps = <4830>;
+
+ nand@0 {
+ reg = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
deleted file mode 100644
index edebeae1f5b3..000000000000
--- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Device tree bindings for Texas instruments Davinci/Keystone NAND controller
-
-This file provides information, what the device node for the davinci/keystone
-NAND interface contains.
-
-Documentation:
-Davinci DM646x - https://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
-Kestone - https://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
-
-Required properties:
-
-- compatible: "ti,davinci-nand"
- "ti,keystone-nand"
-
-- reg: Contains 2 offset/length values:
- - offset and length for the access window.
- - offset and length for accessing the AEMIF
- control registers.
-
-- ti,davinci-chipselect: number of chipselect. Indicates on the
- davinci_nand driver which chipselect is used
- for accessing the nand.
- Can be in the range [0-3].
-
-Recommended properties :
-
-- ti,davinci-mask-ale: mask for ALE. Needed for executing address
- phase. These offset will be added to the base
- address for the chip select space the NAND Flash
- device is connected to.
- If not set equal to 0x08.
-
-- ti,davinci-mask-cle: mask for CLE. Needed for executing command
- phase. These offset will be added to the base
- address for the chip select space the NAND Flash
- device is connected to.
- If not set equal to 0x10.
-
-- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask
- addresses for given chipselect.
-
-- nand-ecc-mode: operation mode of the NAND ecc mode. ECC mode
- valid values for davinci driver:
- - "none"
- - "soft"
- - "hw"
-
-- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-
-- nand-bus-width: buswidth 8 or 16. If not present 8.
-
-- nand-on-flash-bbt: use flash based bad block table support. OOB
- identifier is saved in OOB area. If not present
- false.
-
-Deprecated properties:
-
-- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode
- valid values for davinci driver:
- - "none"
- - "soft"
- - "hw"
-
-- ti,davinci-nand-buswidth: buswidth 8 or 16. If not present 8.
-
-- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB
- identifier is saved in OOB area. If not present
- false.
-
-Nand device bindings may contain additional sub-nodes describing partitions of
-the address space. See partition.txt for more detail. The NAND Flash timing
-values must be programmed in the chip select’s node of AEMIF
-memory-controller (see Documentation/devicetree/bindings/memory-controllers/
-davinci-aemif.txt).
-
-Example(da850 EVM ):
-
-nand_cs3@62000000 {
- compatible = "ti,davinci-nand";
- reg = <0x62000000 0x807ff
- 0x68000000 0x8000>;
- ti,davinci-chipselect = <1>;
- ti,davinci-mask-ale = <0>;
- ti,davinci-mask-cle = <0>;
- ti,davinci-mask-chipsel = <0>;
- nand-ecc-mode = "hw";
- ti,davinci-ecc-bits = <4>;
- nand-on-flash-bbt;
-
- partition@180000 {
- label = "ubifs";
- reg = <0x180000 0x7e80000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/denali,nand.yaml b/Documentation/devicetree/bindings/mtd/denali,nand.yaml
index 1307ed7e7fc6..81f95538d415 100644
--- a/Documentation/devicetree/bindings/mtd/denali,nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/denali,nand.yaml
@@ -63,6 +63,12 @@ properties:
minItems: 1
maxItems: 2
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+ unevaluatedProperties: false
+
allOf:
- $ref: nand-controller.yaml
@@ -74,7 +80,6 @@ allOf:
then:
patternProperties:
"^nand@[a-f0-9]$":
- type: object
properties:
nand-ecc-strength:
enum:
@@ -92,7 +97,6 @@ allOf:
then:
patternProperties:
"^nand@[a-f0-9]$":
- type: object
properties:
nand-ecc-strength:
enum:
@@ -111,7 +115,6 @@ allOf:
then:
patternProperties:
"^nand@[a-f0-9]$":
- type: object
properties:
nand-ecc-strength:
enum:
@@ -145,6 +148,6 @@ examples:
#size-cells = <0>;
nand@0 {
- reg = <0>;
+ reg = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/mtd/flctl-nand.txt b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
index 427f46dc60ad..51518399d737 100644
--- a/Documentation/devicetree/bindings/mtd/flctl-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
@@ -15,7 +15,7 @@ The DMA fields are not used yet in the driver but are listed here for
completing the bindings.
The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
+address space. See mtd.yaml for more detail.
Example:
diff --git a/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml b/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml
new file mode 100644
index 000000000000..480a5c87859d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/fsl,vf610-nfc.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/fsl,vf610-nfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale's NAND flash controller (NFC)
+
+description:
+ This variant of the Freescale NAND flash controller (NFC) can be found on
+ Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,vf610-nfc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: nfc
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+
+ properties:
+ compatible:
+ const: fsl,vf610-nfc-nandcs
+
+ reg:
+ const: 0
+
+ nand-ecc-strength:
+ enum: [24, 32]
+
+ nand-ecc-step-size:
+ const: 2048
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: nand-controller.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/vf610-clock.h>
+
+ nand-controller@400e0000 {
+ compatible = "fsl,vf610-nfc";
+ reg = <0x400e0000 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_NFC>;
+ clock-names = "nfc";
+ assigned-clocks = <&clks VF610_CLK_NFC>;
+ assigned-clock-rates = <33000000>;
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
index 25f07c1f9e44..530c017e014e 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
@@ -22,7 +22,7 @@ Deprecated properties:
(R/B# pins not connected).
Each flash chip described may optionally contain additional sub-nodes
-describing partitions of the address space. See partition.txt for more
+describing partitions of the address space. See mtd.yaml for more
detail.
Examples:
diff --git a/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt b/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
index 486a17d533d7..0edf55d47ea8 100644
--- a/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
@@ -26,7 +26,7 @@ Optional properties:
read to ensure that the GPIO accesses have completed.
The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
+address space. See mtd.yaml for more detail.
Examples:
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
index 849aeae319a9..0badb2e978c7 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mtd/gpmi-nand.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale General-Purpose Media Interface (GPMI) binding
+title: Freescale General-Purpose Media Interface (GPMI)
maintainers:
- Han Xu <han.xu@nxp.com>
@@ -12,7 +12,7 @@ maintainers:
description: |
The GPMI nand controller provides an interface to control the NAND
flash chips. The device tree may optionally contain sub-nodes
- describing partitions of the address space. See partition.txt for
+ describing partitions of the address space. See mtd.yaml for
more detail.
properties:
@@ -24,11 +24,19 @@ properties:
- fsl,imx6q-gpmi-nand
- fsl,imx6sx-gpmi-nand
- fsl,imx7d-gpmi-nand
+ - fsl,imx8qxp-gpmi-nand
- items:
- enum:
- fsl,imx8mm-gpmi-nand
- fsl,imx8mn-gpmi-nand
+ - fsl,imx8mp-gpmi-nand
+ - fsl,imx8mq-gpmi-nand
- const: fsl,imx7d-gpmi-nand
+ - items:
+ - enum:
+ - fsl,imx8dxl-gpmi-nand
+ - fsl,imx8qm-gpmi-nand
+ - const: fsl,imx8qxp-gpmi-nand
reg:
items:
@@ -93,7 +101,7 @@ required:
unevaluatedProperties: false
allOf:
- - $ref: "nand-controller.yaml"
+ - $ref: nand-controller.yaml
- if:
properties:
@@ -151,6 +159,27 @@ allOf:
- const: gpmi_io
- const: gpmi_bch_apb
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-gpmi-nand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: SoC gpmi io clock
+ - description: SoC gpmi apb clock
+ - description: SoC gpmi bch clock
+ - description: SoC gpmi bch apb clock
+ clock-names:
+ items:
+ - const: gpmi_io
+ - const: gpmi_apb
+ - const: gpmi_bch
+ - const: gpmi_bch_apb
+
examples:
- |
nand-controller@8000c000 {
diff --git a/Documentation/devicetree/bindings/mtd/hisi504-nand.txt b/Documentation/devicetree/bindings/mtd/hisi504-nand.txt
index 8963983ae7cb..362203e7d50e 100644
--- a/Documentation/devicetree/bindings/mtd/hisi504-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/hisi504-nand.txt
@@ -22,7 +22,7 @@ The following ECC strength and step size are currently supported:
- nand-ecc-strength = <16>, nand-ecc-step-size = <1024>
Flash chip may optionally contain additional sub-nodes describing partitions of
-the address space. See partition.txt for more detail.
+the address space. See mtd.yaml for more detail.
Example:
diff --git a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
index 8c272c842bfd..b9312ebefeb9 100644
--- a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mtd/ingenic,nand.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs NAND controller devicetree bindings
+title: Ingenic SoCs NAND controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
@@ -32,14 +32,16 @@ properties:
partitions:
type: object
+ deprecated: true
description:
Node containing description of fixed partitions.
- See Documentation/devicetree/bindings/mtd/partition.txt
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
+
rb-gpios:
description: GPIO specifier for the busy pin.
maxItems: 1
@@ -48,6 +50,8 @@ patternProperties:
description: GPIO specifier for the write-protect pin.
maxItems: 1
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -58,78 +62,78 @@ examples:
- |
#include <dt-bindings/clock/ingenic,jz4780-cgu.h>
memory-controller@13410000 {
- compatible = "ingenic,jz4780-nemc";
- reg = <0x13410000 0x10000>;
- #address-cells = <2>;
- #size-cells = <1>;
- ranges = <1 0 0x1b000000 0x1000000>,
- <2 0 0x1a000000 0x1000000>,
- <3 0 0x19000000 0x1000000>,
- <4 0 0x18000000 0x1000000>,
- <5 0 0x17000000 0x1000000>,
- <6 0 0x16000000 0x1000000>;
-
- clocks = <&cgu JZ4780_CLK_NEMC>;
-
- nand-controller@1 {
- compatible = "ingenic,jz4780-nand";
- reg = <1 0 0x1000000>;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- ecc-engine = <&bch>;
-
- ingenic,nemc-tAS = <10>;
- ingenic,nemc-tAH = <5>;
- ingenic,nemc-tBP = <10>;
- ingenic,nemc-tAW = <15>;
- ingenic,nemc-tSTRV = <100>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&pins_nemc>;
-
- nand@1 {
- reg = <1>;
-
- nand-ecc-step-size = <1024>;
- nand-ecc-strength = <24>;
- nand-ecc-mode = "hw";
- nand-on-flash-bbt;
-
- pinctrl-names = "default";
- pinctrl-0 = <&pins_nemc_cs1>;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <2>;
- #size-cells = <2>;
-
- partition@0 {
- label = "u-boot-spl";
- reg = <0x0 0x0 0x0 0x800000>;
- };
-
- partition@800000 {
- label = "u-boot";
- reg = <0x0 0x800000 0x0 0x200000>;
- };
-
- partition@a00000 {
- label = "u-boot-env";
- reg = <0x0 0xa00000 0x0 0x200000>;
- };
-
- partition@c00000 {
- label = "boot";
- reg = <0x0 0xc00000 0x0 0x4000000>;
- };
-
- partition@4c00000 {
- label = "system";
- reg = <0x0 0x4c00000 0x1 0xfb400000>;
+ compatible = "ingenic,jz4780-nemc";
+ reg = <0x13410000 0x10000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0 0x1b000000 0x1000000>,
+ <2 0 0x1a000000 0x1000000>,
+ <3 0 0x19000000 0x1000000>,
+ <4 0 0x18000000 0x1000000>,
+ <5 0 0x17000000 0x1000000>,
+ <6 0 0x16000000 0x1000000>;
+
+ clocks = <&cgu JZ4780_CLK_NEMC>;
+
+ nand-controller@1 {
+ compatible = "ingenic,jz4780-nand";
+ reg = <1 0 0x1000000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ecc-engine = <&bch>;
+
+ ingenic,nemc-tAS = <10>;
+ ingenic,nemc-tAH = <5>;
+ ingenic,nemc-tBP = <10>;
+ ingenic,nemc-tAW = <15>;
+ ingenic,nemc-tSTRV = <100>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pins_nemc>;
+
+ nand@1 {
+ reg = <1>;
+
+ nand-ecc-step-size = <1024>;
+ nand-ecc-strength = <24>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pins_nemc_cs1>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ partition@0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x0 0x0 0x800000>;
+ };
+
+ partition@800000 {
+ label = "u-boot";
+ reg = <0x0 0x800000 0x0 0x200000>;
+ };
+
+ partition@a00000 {
+ label = "u-boot-env";
+ reg = <0x0 0xa00000 0x0 0x200000>;
+ };
+
+ partition@c00000 {
+ label = "boot";
+ reg = <0x0 0xc00000 0x0 0x4000000>;
+ };
+
+ partition@4c00000 {
+ label = "system";
+ reg = <0x0 0x4c00000 0x1 0xfb400000>;
+ };
+ };
};
- };
};
- };
};
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml
new file mode 100644
index 000000000000..07bc7e3efd3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-ebunand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller
+
+allOf:
+ - $ref: nand-controller.yaml
+
+maintainers:
+ - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
+
+properties:
+ compatible:
+ const: intel,lgm-ebunand
+
+ reg:
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: ebunand
+ - const: hsnand
+ - const: nand_cs0
+ - const: nand_cs1
+ - const: addr_sel0
+ - const: addr_sel1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+ properties:
+ reg:
+ minimum: 0
+ maximum: 1
+
+ nand-ecc-algo:
+ const: hw
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ nand-controller@e0f00000 {
+ compatible = "intel,lgm-ebunand";
+ reg = <0xe0f00000 0x100>,
+ <0xe1000000 0x300>,
+ <0xe1400000 0x8000>,
+ <0xe1c00000 0x1000>,
+ <0x17400000 0x4>,
+ <0x17c00000 0x4>;
+ reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
+ "addr_sel0", "addr_sel1";
+ clocks = <&cgu0 125>;
+ dmas = <&dma0 8>, <&dma0 9>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
deleted file mode 100644
index 30e0c66ab0eb..000000000000
--- a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
+++ /dev/null
@@ -1,99 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Intel LGM SoC NAND Controller Device Tree Bindings
-
-allOf:
- - $ref: "nand-controller.yaml"
-
-maintainers:
- - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
-
-properties:
- compatible:
- const: intel,lgm-nand
-
- reg:
- maxItems: 6
-
- reg-names:
- items:
- - const: ebunand
- - const: hsnand
- - const: nand_cs0
- - const: nand_cs1
- - const: addr_sel0
- - const: addr_sel1
-
- clocks:
- maxItems: 1
-
- dmas:
- maxItems: 2
-
- dma-names:
- items:
- - const: tx
- - const: rx
-
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
-patternProperties:
- "^nand@[a-f0-9]+$":
- type: object
- properties:
- reg:
- minimum: 0
- maximum: 7
-
- nand-ecc-mode: true
-
- nand-ecc-algo:
- const: hw
-
- additionalProperties: false
-
-required:
- - compatible
- - reg
- - reg-names
- - clocks
- - dmas
- - dma-names
- - "#address-cells"
- - "#size-cells"
-
-additionalProperties: false
-
-examples:
- - |
- nand-controller@e0f00000 {
- compatible = "intel,lgm-nand";
- reg = <0xe0f00000 0x100>,
- <0xe1000000 0x300>,
- <0xe1400000 0x8000>,
- <0xe1c00000 0x1000>,
- <0x17400000 0x4>,
- <0x17c00000 0x4>;
- reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
- "addr_sel0", "addr_sel1";
- clocks = <&cgu0 125>;
- dmas = <&dma0 8>, <&dma0 9>;
- dma-names = "tx", "rx";
- #address-cells = <1>;
- #size-cells = <0>;
-
- nand@0 {
- reg = <0>;
- nand-ecc-mode = "hw";
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 7149784a36ac..587af4968255 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -10,7 +10,7 @@ maintainers:
- Rob Herring <robh@kernel.org>
allOf:
- - $ref: "mtd.yaml#"
+ - $ref: mtd.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
@@ -20,7 +20,7 @@ properties:
- pattern: "^((((micron|spansion|st),)?\
(m25p(40|80|16|32|64|128)|\
n25q(32b|064|128a11|128a13|256a|512a|164k)))|\
- atmel,at25df(321a|641|081a)|\
+ atmel,at(25|26)df(321a|641|081a)|\
everspin,mr25h(10|40|128|256)|\
(mxicy|macronix),mx25l(4005a|1606e|6405d|8005|12805d|25635e)|\
(mxicy|macronix),mx25u(4033|4035)|\
@@ -43,13 +43,18 @@ properties:
- const: jedec,spi-nor
- const: jedec,spi-nor
description:
- Must also include "jedec,spi-nor" for any SPI NOR flash that can be
- identified by the JEDEC READ ID opcode (0x9F).
+ SPI NOR flashes compatible with the JEDEC SFDP standard or which may be
+ identified with the READ ID opcode (0x9F) do not deserve a specific
+ compatible. They should instead only be matched against the generic
+ "jedec,spi-nor" compatible.
reg:
minItems: 1
maxItems: 2
+ interrupts:
+ maxItems: 1
+
m25p,fast-read:
type: boolean
description:
@@ -70,24 +75,43 @@ properties:
be used on such systems, to denote the absence of a reliable reset
mechanism.
- partitions:
- type: object
+ no-wp:
+ type: boolean
+ description:
+ The status register write disable (SRWD) bit in status register, combined
+ with the WP# signal, provides hardware data protection for the device. When
+ the SRWD bit is set to 1, and the WP# signal is either driven LOW or hard
+ strapped to LOW, the status register nonvolatile bits become read-only and
+ the WRITE STATUS REGISTER operation will not execute. The only way to exit
+ this hardware-protected mode is to drive WP# HIGH. If the WP# signal of the
+ flash device is not connected or is wrongly tied to GND (that includes internal
+ pull-downs) then status register permanently becomes read-only as the SRWD bit
+ cannot be reset. This boolean flag can be used on such systems to avoid setting
+ the SRWD bit while writing the status register. WP# signal hard strapped to GND
+ can be a valid use case.
+
+ reset-gpios:
+ description:
+ A GPIO line connected to the RESET (active low) signal of the device.
+ If "broken-flash-reset" is present then having this property does not
+ make any difference.
- '#address-cells': true
- '#size-cells': true
+ vcc-supply:
+ description:
+ Supply for the SPI NOR power.
-patternProperties:
- # Note: use 'partitions' node for new users
- '^partition@':
- type: object
+ spi-cpol: true
+ spi-cpha: true
- "^otp(-[0-9]+)?$":
- type: object
+dependencies:
+ spi-cpol: [ spi-cpha ]
+ spi-cpha: [ spi-cpol ]
unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -97,6 +121,7 @@ examples:
reg = <0>;
spi-max-frequency = <40000000>;
m25p,fast-read;
+ reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
};
};
...
diff --git a/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml b/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml
new file mode 100644
index 000000000000..cf85d0cede00
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/loongson,ls1b-nand-controller.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/loongson,ls1b-nand-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson NAND Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+description:
+ The Loongson NAND controller abstracts all supported operations,
+ meaning it does not support low-level access to raw NAND flash chips.
+ Moreover, the controller is paired with the DMA engine to perform
+ READ and PROGRAM functions.
+
+allOf:
+ - $ref: nand-controller.yaml
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls1b-nand-controller
+ - loongson,ls1c-nand-controller
+ - loongson,ls2k0500-nand-controller
+ - loongson,ls2k1000-nand-controller
+ - items:
+ - enum:
+ - loongson,ls1a-nand-controller
+ - const: loongson,ls1b-nand-controller
+
+ reg:
+ minItems: 2
+ maxItems: 3
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: nand
+ - const: nand-dma
+ - const: dma-config
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rxtx
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - loongson,ls2k1000-nand-controller
+
+then:
+ properties:
+ reg:
+ minItems: 3
+ reg-names:
+ minItems: 3
+
+else:
+ properties:
+ reg:
+ maxItems: 2
+ reg-names:
+ maxItems: 2
+
+examples:
+ - |
+ nand-controller@1fe78000 {
+ compatible = "loongson,ls1b-nand-controller";
+ reg = <0x1fe78000 0x24>, <0x1fe78040 0x4>;
+ reg-names = "nand", "nand-dma";
+ dmas = <&dma 0>;
+ dma-names = "rxtx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "ls1x-nand";
+ nand-use-soft-ecc-engine;
+ nand-ecc-algo = "hamming";
+ };
+ };
+
+ - |
+ nand-controller@1fe26000 {
+ compatible = "loongson,ls2k1000-nand-controller";
+ reg = <0x1fe26000 0x24>,
+ <0x1fe26040 0x4>,
+ <0x1fe00438 0x8>;
+ reg-names = "nand", "nand-dma", "dma-config";
+ dmas = <&apbdma0 0>;
+ dma-names = "rxtx";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "ls2k1000-nand";
+ nand-use-soft-ecc-engine;
+ nand-ecc-algo = "bch";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt b/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt
index 6d60bc3063f5..64c06aa05ac7 100644
--- a/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt
+++ b/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt
@@ -19,7 +19,7 @@ accuracy:)
- nxp,wr_low: WR_LOW
Optional subnodes:
-- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt
+- Partitions, see Documentation/devicetree/bindings/mtd/mtd.yaml
Example:
diff --git a/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt b/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt
index d94edc0fc554..39f17630a301 100644
--- a/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt
+++ b/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt
@@ -20,7 +20,7 @@ clock speed:)
- nxp,rsetup: Read setup time (R_SETUP)
Optional subnodes:
-- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt
+- Partitions, see Documentation/devicetree/bindings/mtd/mtd.yaml
Example:
diff --git a/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
new file mode 100644
index 000000000000..bc89cbf8193a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/marvell,nand-controller.yaml
@@ -0,0 +1,226 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/marvell,nand-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell NAND Flash Controller (NFC)
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: marvell,armada-8k-nand-controller
+ - const: marvell,armada370-nand-controller
+ - enum:
+ - marvell,ac5-nand-controller
+ - marvell,armada370-nand-controller
+ - marvell,pxa3xx-nand-controller
+ - description: legacy bindings
+ deprecated: true
+ enum:
+ - marvell,armada-8k-nand
+ - marvell,armada370-nand
+ - marvell,pxa3xx-nand
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description:
+ Shall reference the NAND controller clocks, the second one is
+ is only needed for the Armada 7K/8K SoCs
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: reg
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: data
+
+ marvell,system-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Syscon node that handles NAND controller related registers
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 3
+
+ nand-rb:
+ items:
+ - minimum: 0
+ maximum: 1
+
+ nand-ecc-step-size:
+ const: 512
+
+ nand-ecc-strength:
+ enum: [1, 4, 8, 12, 16]
+
+ nand-ecc-mode:
+ const: hw
+
+ marvell,nand-keep-config:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Orders the driver not to take the timings from the core and
+ leaving them completely untouched. Bootloader timings will then
+ be used.
+
+ marvell,nand-enable-arbiter:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ To enable the arbiter, all boards blindly used it,
+ this bit was set by the bootloader for many boards and even if
+ it is marked reserved in several datasheets, it might be needed to set
+ it (otherwise it is harmless).
+ deprecated: true
+
+ required:
+ - reg
+ - nand-rb
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+allOf:
+ - $ref: nand-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,pxa3xx-nand-controller
+ then:
+ required:
+ - dmas
+ - dma-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,armada-8k-nand-controller
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ minItems: 2
+
+ required:
+ - marvell,system-controller
+
+ else:
+ properties:
+ clocks:
+ minItems: 1
+
+ clock-names:
+ minItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ nand_controller: nand-controller@d0000 {
+ compatible = "marvell,armada370-nand-controller";
+ reg = <0xd0000 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&coredivclk 0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "main-storage";
+ nand-rb = <0>;
+ nand-ecc-mode = "hw";
+ marvell,nand-keep-config;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "Rootfs";
+ reg = <0x00000000 0x40000000>;
+ };
+ };
+ };
+ };
+
+ - |
+ cp0_nand_controller: nand-controller@720000 {
+ compatible = "marvell,armada-8k-nand-controller",
+ "marvell,armada370-nand-controller";
+ reg = <0x720000 0x54>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <115 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "core", "reg";
+ clocks = <&cp0_clk 1 2>,
+ <&cp0_clk 1 17>;
+ marvell,system-controller = <&cp0_syscon0>;
+
+ nand@0 {
+ reg = <0>;
+ label = "main-storage";
+ nand-rb = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ };
+ };
+
+ - |
+ nand-controller@43100000 {
+ compatible = "marvell,pxa3xx-nand-controller";
+ reg = <0x43100000 90>;
+ interrupts = <45>;
+ clocks = <&clks 1>;
+ clock-names = "core";
+ dmas = <&pdma 97 3>;
+ dma-names = "data";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nand@0 {
+ reg = <0>;
+ nand-rb = <0>;
+ nand-ecc-mode = "hw";
+ marvell,nand-keep-config;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
deleted file mode 100644
index a2d9a0f2b683..000000000000
--- a/Documentation/devicetree/bindings/mtd/marvell-nand.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-Marvell NAND Flash Controller (NFC)
-
-Required properties:
-- compatible: can be one of the following:
- * "marvell,armada-8k-nand-controller"
- * "marvell,armada370-nand-controller"
- * "marvell,pxa3xx-nand-controller"
- * "marvell,armada-8k-nand" (deprecated)
- * "marvell,armada370-nand" (deprecated)
- * "marvell,pxa3xx-nand" (deprecated)
- Compatibles marked deprecated support only the old bindings described
- at the bottom.
-- reg: NAND flash controller memory area.
-- #address-cells: shall be set to 1. Encode the NAND CS.
-- #size-cells: shall be set to 0.
-- interrupts: shall define the NAND controller interrupt.
-- clocks: shall reference the NAND controller clocks, the second one is
- is only needed for the Armada 7K/8K SoCs
-- clock-names: mandatory if there is a second clock, in this case there
- should be one clock named "core" and another one named "reg"
-- marvell,system-controller: Set to retrieve the syscon node that handles
- NAND controller related registers (only required with the
- "marvell,armada-8k-nand[-controller]" compatibles).
-
-Optional properties:
-- label: see partition.txt. New platforms shall omit this property.
-- dmas: shall reference DMA channel associated to the NAND controller.
- This property is only used with "marvell,pxa3xx-nand[-controller]"
- compatible strings.
-- dma-names: shall be "rxtx".
- This property is only used with "marvell,pxa3xx-nand[-controller]"
- compatible strings.
-
-Optional children nodes:
-Children nodes represent the available NAND chips.
-
-Required properties:
-- reg: shall contain the native Chip Select ids (0-3).
-- nand-rb: see nand-controller.yaml (0-1).
-
-Optional properties:
-- marvell,nand-keep-config: orders the driver not to take the timings
- from the core and leaving them completely untouched. Bootloader
- timings will then be used.
-- label: MTD name.
-- nand-on-flash-bbt: see nand-controller.yaml.
-- nand-ecc-mode: see nand-controller.yaml. Will use hardware ECC if not specified.
-- nand-ecc-algo: see nand-controller.yaml. This property is essentially useful when
- not using hardware ECC. Howerver, it may be added when using hardware
- ECC for clarification but will be ignored by the driver because ECC
- mode is chosen depending on the page size and the strength required by
- the NAND chip. This value may be overwritten with nand-ecc-strength
- property.
-- nand-ecc-strength: see nand-controller.yaml.
-- nand-ecc-step-size: see nand-controller.yaml. Marvell's NAND flash controller does
- use fixed strength (1-bit for Hamming, 16-bit for BCH), so the actual
- step size will shrink or grow in order to fit the required strength.
- Step sizes are not completely random for all and follow certain
- patterns described in AN-379, "Marvell SoC NFC ECC".
-
-See Documentation/devicetree/bindings/mtd/nand-controller.yaml for more details on
-generic bindings.
-
-
-Example:
-nand_controller: nand-controller@d0000 {
- compatible = "marvell,armada370-nand-controller";
- reg = <0xd0000 0x54>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&coredivclk 0>;
-
- nand@0 {
- reg = <0>;
- label = "main-storage";
- nand-rb = <0>;
- nand-ecc-mode = "hw";
- marvell,nand-keep-config;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "Rootfs";
- reg = <0x00000000 0x40000000>;
- };
- };
- };
-};
-
-
-Note on legacy bindings: One can find, in not-updated device trees,
-bindings slightly different than described above with other properties
-described below as well as the partitions node at the root of a so
-called "nand" node (without clear controller/chip separation).
-
-Legacy properties:
-- marvell,nand-enable-arbiter: To enable the arbiter, all boards blindly
- used it, this bit was set by the bootloader for many boards and even if
- it is marked reserved in several datasheets, it might be needed to set
- it (otherwise it is harmless) so whether or not this property is set,
- the bit is selected by the driver.
-- num-cs: Number of chip-select lines to use, all boards blindly set 1
- to this and for a reason, other values would have failed. The value of
- this property is ignored.
-
-Example:
-
- nand0: nand@43100000 {
- compatible = "marvell,pxa3xx-nand";
- reg = <0x43100000 90>;
- interrupts = <45>;
- dmas = <&pdma 97 0>;
- dma-names = "rxtx";
- #address-cells = <1>;
- marvell,nand-keep-config;
- marvell,nand-enable-arbiter;
- num-cs = <1>;
- /* Partitions (optional) */
- };
diff --git a/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
new file mode 100644
index 000000000000..ab503a33a269
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mediatek,mtk-nfc.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mediatek,mtk-nfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek(MTK) SoCs raw NAND FLASH controller (NFC)
+
+maintainers:
+ - Xiangsheng Hou <xiangsheng.hou@mediatek.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-nfc
+ - mediatek,mt2712-nfc
+ - mediatek,mt7622-nfc
+
+ reg:
+ items:
+ - description: Base physical address and size of NFI.
+
+ interrupts:
+ items:
+ - description: NFI interrupt
+
+ clocks:
+ items:
+ - description: clock used for the controller
+ - description: clock used for the pad
+
+ clock-names:
+ items:
+ - const: nfi_clk
+ - const: pad_clk
+
+ ecc-engine:
+ description: device-tree node of the required ECC engine.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ $ref: raw-nand-chip.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ maximum: 1
+ nand-ecc-mode:
+ const: hw
+
+allOf:
+ - $ref: nand-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt2701-nfc
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-step-size:
+ enum: [ 512, 1024 ]
+ nand-ecc-strength:
+ enum: [4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 36,
+ 40, 44, 48, 52, 56, 60]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt2712-nfc
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-step-size:
+ enum: [ 512, 1024 ]
+ nand-ecc-strength:
+ enum: [4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 36,
+ 40, 44, 48, 52, 56, 60, 68, 72, 80]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7622-nfc
+ then:
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ nand-ecc-step-size:
+ const: 512
+ nand-ecc-strength:
+ enum: [4, 6, 8, 10, 12]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ecc-engine
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ nand-controller@1100d000 {
+ compatible = "mediatek,mt2701-nfc";
+ reg = <0 0x1100d000 0 0x1000>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI>,
+ <&pericfg CLK_PERI_NFI_PAD>;
+ clock-names = "nfi_clk", "pad_clk";
+ ecc-engine = <&bch>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ nand-ecc-step-size = <1024>;
+ nand-ecc-strength = <24>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ preloader@0 {
+ label = "pl";
+ read-only;
+ reg = <0x0 0x400000>;
+ };
+ android@400000 {
+ label = "android";
+ reg = <0x400000 0x12c00000>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml
new file mode 100644
index 000000000000..505baf1e8830
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mediatek,nand-ecc-engine.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mediatek,nand-ecc-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek(MTK) SoCs NAND ECC engine
+
+maintainers:
+ - Xiangsheng Hou <xiangsheng.hou@mediatek.com>
+
+description: |
+ MTK NAND ECC engine can cowork with MTK raw NAND and SPI NAND controller.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-ecc
+ - mediatek,mt2712-ecc
+ - mediatek,mt7622-ecc
+ - mediatek,mt7986-ecc
+
+ reg:
+ items:
+ - description: Base physical address and size of ECC.
+
+ interrupts:
+ items:
+ - description: ECC interrupt
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: nfiecc_clk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ bch: ecc@1100e000 {
+ compatible = "mediatek,mt2701-ecc";
+ reg = <0 0x1100e000 0 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI_ECC>;
+ clock-names = "nfiecc_clk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml
index 8cc2a7ceb5fb..5c6b628c608d 100644
--- a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml
+++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip 48l640 (and similar) serial EERAM bindings
+title: Microchip 48l640 (and similar) serial EERAM
maintainers:
- Heiko Schocher <hs@denx.de>
@@ -16,8 +16,9 @@ description: |
properties:
compatible:
- items:
- - const: microchip,48l640
+ enum:
+ - fujitsu,mb85rs128ty
+ - microchip,48l640
reg:
maxItems: 1
@@ -34,13 +35,13 @@ unevaluatedProperties: false
examples:
- |
spi {
- #address-cells = <1>;
- #size-cells = <0>;
-
- eeram@0 {
- compatible = "microchip,48l640";
- reg = <0>;
- spi-max-frequency = <20000000>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeram@0 {
+ compatible = "microchip,48l640";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
index 82eb4e0f453b..a9ec3ca002c7 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
@@ -13,6 +13,10 @@ description: |
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
+allOf:
+ - $ref: mtd.yaml#
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
+
properties:
compatible:
oneOf:
@@ -65,6 +69,16 @@ properties:
minItems: 1
maxItems: 8
+ clocks:
+ description: |
+ Chips may need clocks to be enabled for themselves or for transparent
+ bridges.
+
+ power-domains:
+ description: |
+ Chips may need power domains to be enabled for themselves or for
+ transparent bridges.
+
bank-width:
description: Width (in bytes) of the bank. Equal to the device width times
the number of interleaved chips.
@@ -118,13 +132,11 @@ properties:
'#size-cells':
const: 1
+ ranges: true
+
big-endian: true
little-endian: true
-patternProperties:
- '@[0-9a-f]+$':
- $ref: partitions/partition.yaml
-
required:
- compatible
- reg
@@ -143,8 +155,7 @@ then:
required:
- syscon
-# FIXME: A parent bus may define timing properties
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
@@ -164,7 +175,7 @@ examples:
reg = <0 0xf80000>;
};
firmware@f80000 {
- label ="firmware";
+ label = "firmware";
reg = <0xf80000 0x80000>;
read-only;
};
diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml
index 376b679cfc70..bbb56216a4e2 100644
--- a/Documentation/devicetree/bindings/mtd/mtd.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd.yaml
@@ -4,15 +4,17 @@
$id: http://devicetree.org/schemas/mtd/mtd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MTD (Memory Technology Device) Device Tree Bindings
+title: MTD (Memory Technology Device)
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
- Richard Weinberger <richard@nod.at>
+select: false
+
properties:
$nodename:
- pattern: "^flash(@.*)?$"
+ pattern: "^(flash|.*sram|nand)(@.*)?$"
label:
description:
@@ -21,10 +23,35 @@ properties:
based name) in order to ease flash device identification and/or
describe what they are used for.
+ '#address-cells':
+ deprecated: true
+
+ '#size-cells':
+ deprecated: true
+
+ partitions:
+ $ref: /schemas/mtd/partitions/partitions.yaml
+
+ required:
+ - compatible
+
patternProperties:
+ "@[0-9a-f]+$":
+ $ref: partitions/partition.yaml
+ deprecated: true
+
+ "^partition@[0-9a-f]+":
+ $ref: partitions/partition.yaml
+ deprecated: true
+
"^otp(-[0-9]+)?$":
type: object
- $ref: ../nvmem/nvmem.yaml#
+
+ allOf:
+ - $ref: /schemas/nvmem/nvmem.yaml#
+ - $ref: /schemas/nvmem/nvmem-deprecated-cells.yaml#
+
+ unevaluatedProperties: false
description: |
An OTP memory region. Some flashes provide a one-time-programmable
@@ -40,6 +67,7 @@ patternProperties:
required:
- compatible
+# This is a generic file other binding inherit from
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/mtd/mtk-nand.txt b/Documentation/devicetree/bindings/mtd/mtk-nand.txt
deleted file mode 100644
index 4d3ec5e4ff8a..000000000000
--- a/Documentation/devicetree/bindings/mtd/mtk-nand.txt
+++ /dev/null
@@ -1,176 +0,0 @@
-MTK SoCs NAND FLASH controller (NFC) DT binding
-
-This file documents the device tree bindings for MTK SoCs NAND controllers.
-The functional split of the controller requires two drivers to operate:
-the nand controller interface driver and the ECC engine driver.
-
-The hardware description for both devices must be captured as device
-tree nodes.
-
-1) NFC NAND Controller Interface (NFI):
-=======================================
-
-The first part of NFC is NAND Controller Interface (NFI) HW.
-Required NFI properties:
-- compatible: Should be one of
- "mediatek,mt2701-nfc",
- "mediatek,mt2712-nfc",
- "mediatek,mt7622-nfc".
-- reg: Base physical address and size of NFI.
-- interrupts: Interrupts of NFI.
-- clocks: NFI required clocks.
-- clock-names: NFI clocks internal name.
-- ecc-engine: Required ECC Engine node.
-- #address-cells: NAND chip index, should be 1.
-- #size-cells: Should be 0.
-
-Example:
-
- nandc: nfi@1100d000 {
- compatible = "mediatek,mt2701-nfc";
- reg = <0 0x1100d000 0 0x1000>;
- interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_NFI>,
- <&pericfg CLK_PERI_NFI_PAD>;
- clock-names = "nfi_clk", "pad_clk";
- ecc-engine = <&bch>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
-Platform related properties, should be set in {platform_name}.dts:
-- children nodes: NAND chips.
-
-Children nodes properties:
-- reg: Chip Select Signal, default 0.
- Set as reg = <0>, <1> when need 2 CS.
-Optional:
-- nand-on-flash-bbt: Store BBT on NAND Flash.
-- nand-ecc-mode: the NAND ecc mode (check driver for supported modes)
-- nand-ecc-step-size: Number of data bytes covered by a single ECC step.
- valid values:
- 512 and 1024 on mt2701 and mt2712.
- 512 only on mt7622.
- 1024 is recommended for large page NANDs.
-- nand-ecc-strength: Number of bits to correct per ECC step.
- The valid values that each controller supports:
- mt2701: 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28,
- 32, 36, 40, 44, 48, 52, 56, 60.
- mt2712: 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28,
- 32, 36, 40, 44, 48, 52, 56, 60, 68, 72, 80.
- mt7622: 4, 6, 8, 10, 12, 14, 16.
- The strength should be calculated as follows:
- E = (S - F) * 8 / B
- S = O / (P / Q)
- E : nand-ecc-strength.
- S : spare size per sector.
- F : FDM size, should be in the range [1,8].
- It is used to store free oob data.
- O : oob size.
- P : page size.
- Q : nand-ecc-step-size.
- B : number of parity bits needed to correct
- 1 bitflip.
- According to MTK NAND controller design,
- this number depends on max ecc step size
- that MTK NAND controller supports.
- If max ecc step size supported is 1024,
- then it should be always 14. And if max
- ecc step size is 512, then it should be
- always 13.
- If the result does not match any one of the listed
- choices above, please select the smaller valid value from
- the list.
- (otherwise the driver will do the adjustment at runtime)
-- pinctrl-names: Default NAND pin GPIO setting name.
-- pinctrl-0: GPIO setting node.
-
-Example:
- &pio {
- nand_pins_default: nanddefault {
- pins_dat {
- pinmux = <MT2701_PIN_111_MSDC0_DAT7__FUNC_NLD7>,
- <MT2701_PIN_112_MSDC0_DAT6__FUNC_NLD6>,
- <MT2701_PIN_114_MSDC0_DAT4__FUNC_NLD4>,
- <MT2701_PIN_118_MSDC0_DAT3__FUNC_NLD3>,
- <MT2701_PIN_121_MSDC0_DAT0__FUNC_NLD0>,
- <MT2701_PIN_120_MSDC0_DAT1__FUNC_NLD1>,
- <MT2701_PIN_113_MSDC0_DAT5__FUNC_NLD5>,
- <MT2701_PIN_115_MSDC0_RSTB__FUNC_NLD8>,
- <MT2701_PIN_119_MSDC0_DAT2__FUNC_NLD2>;
- input-enable;
- drive-strength = <MTK_DRIVE_8mA>;
- bias-pull-up;
- };
-
- pins_we {
- pinmux = <MT2701_PIN_117_MSDC0_CLK__FUNC_NWEB>;
- drive-strength = <MTK_DRIVE_8mA>;
- bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
- };
-
- pins_ale {
- pinmux = <MT2701_PIN_116_MSDC0_CMD__FUNC_NALE>;
- drive-strength = <MTK_DRIVE_8mA>;
- bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
- };
- };
- };
-
- &nandc {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nand_pins_default>;
- nand@0 {
- reg = <0>;
- nand-on-flash-bbt;
- nand-ecc-mode = "hw";
- nand-ecc-strength = <24>;
- nand-ecc-step-size = <1024>;
- };
- };
-
-NAND chip optional subnodes:
-- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt
-
-Example:
- nand@0 {
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- preloader@0 {
- label = "pl";
- read-only;
- reg = <0x00000000 0x00400000>;
- };
- android@00400000 {
- label = "android";
- reg = <0x00400000 0x12c00000>;
- };
- };
- };
-
-2) ECC Engine:
-==============
-
-Required BCH properties:
-- compatible: Should be one of
- "mediatek,mt2701-ecc",
- "mediatek,mt2712-ecc",
- "mediatek,mt7622-ecc".
-- reg: Base physical address and size of ECC.
-- interrupts: Interrupts of ECC.
-- clocks: ECC required clocks.
-- clock-names: ECC clocks internal name.
-
-Example:
-
- bch: ecc@1100e000 {
- compatible = "mediatek,mt2701-ecc";
- reg = <0 0x1100e000 0 0x1000>;
- interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_NFI_ECC>;
- clock-names = "nfiecc_clk";
- };
diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml
index 66da1b476ab7..bd8f7b683953 100644
--- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml
@@ -4,18 +4,22 @@
$id: http://devicetree.org/schemas/mtd/mxc-nand.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale's mxc_nand binding
+title: Freescale's mxc_nand
maintainers:
- Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
allOf:
- - $ref: "nand-controller.yaml"
+ - $ref: nand-controller.yaml
properties:
compatible:
- const: fsl,imx27-nand
-
+ oneOf:
+ - const: fsl,imx27-nand
+ - items:
+ - enum:
+ - fsl,imx31-nand
+ - const: fsl,imx27-nand
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
index 804479999ccb..f92e7234deab 100644
--- a/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
+++ b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mtd/mxicy,nand-ecc-engine.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Macronix NAND ECC engine device tree bindings
+title: Macronix NAND ECC engine
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml
index 97ac3a3fbb52..609d4a4ddd80 100644
--- a/Documentation/devicetree/bindings/mtd/nand-chip.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/mtd/nand-chip.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NAND Chip and NAND Controller Generic Binding
+title: NAND Chip Common Properties
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
+allOf:
+ - $ref: mtd.yaml#
+
description: |
This file covers the generic description of a NAND chip. It implies that the
bus interface should not be taken into account: both raw NAND devices and
@@ -67,4 +70,5 @@ properties:
required:
- reg
+# This file can be referenced by more specific devices (like spi-nands)
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
index 359a015d4e5a..28167c0cf271 100644
--- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: GPL-2.0
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mtd/nand-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NAND Chip and NAND Controller Generic Binding
+title: NAND Controller Common Properties
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
@@ -16,16 +16,6 @@ description: |
children nodes of the NAND controller. This representation should be
enforced even for simple controllers supporting only one chip.
- The ECC strength and ECC step size properties define the user
- desires in terms of correction capability of a controller. Together,
- they request the ECC engine to correct {strength} bit errors per
- {size} bytes.
-
- The interpretation of these parameters is implementation-defined, so
- not all implementations must support all possible
- combinations. However, implementations are encouraged to further
- specify the value(s) they support.
-
properties:
$nodename:
pattern: "^nand-controller(@.*)?"
@@ -52,84 +42,13 @@ properties:
patternProperties:
"^nand@[a-f0-9]$":
type: object
- $ref: "nand-chip.yaml#"
-
- properties:
- reg:
- description:
- Contains the chip-select IDs.
-
- nand-ecc-placement:
- description:
- Location of the ECC bytes. This location is unknown by default
- but can be explicitly set to "oob", if all ECC bytes are
- known to be stored in the OOB area, or "interleaved" if ECC
- bytes will be interleaved with regular data in the main area.
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ oob, interleaved ]
-
- nand-bus-width:
- description:
- Bus width to the NAND chip
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [8, 16]
- default: 8
-
- nand-on-flash-bbt:
- description:
- With this property, the OS will search the device for a Bad
- Block Table (BBT). If not found, it will create one, reserve
- a few blocks at the end of the device to store it and update
- it as the device ages. Otherwise, the out-of-band area of a
- few pages of all the blocks will be scanned at boot time to
- find Bad Block Markers (BBM). These markers will help to
- build a volatile BBT in RAM.
- $ref: /schemas/types.yaml#/definitions/flag
-
- nand-ecc-maximize:
- description:
- Whether or not the ECC strength should be maximized. The
- maximum ECC strength is both controller and chip
- dependent. The ECC engine has to select the ECC config
- providing the best strength and taking the OOB area size
- constraint into account. This is particularly useful when
- only the in-band area is used by the upper layers, and you
- want to make your NAND as reliable as possible.
- $ref: /schemas/types.yaml#/definitions/flag
-
- nand-is-boot-medium:
- description:
- Whether or not the NAND chip is a boot medium. Drivers might
- use this information to select ECC algorithms supported by
- the boot ROM or similar restrictions.
- $ref: /schemas/types.yaml#/definitions/flag
-
- nand-rb:
- description:
- Contains the native Ready/Busy IDs.
- $ref: /schemas/types.yaml#/definitions/uint32-array
-
- rb-gpios:
- description:
- Contains one or more GPIO descriptor (the numper of descriptor
- depends on the number of R/B pins exposed by the flash) for the
- Ready/Busy pins. Active state refers to the NAND ready state and
- should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
-
- wp-gpios:
- description:
- Contains one GPIO descriptor for the Write Protect pin.
- Active state refers to the NAND Write Protect state and should be
- set to GPIOD_ACTIVE_LOW unless the signal is inverted.
- maxItems: 1
-
- required:
- - reg
+ $ref: raw-nand-chip.yaml#
required:
- "#address-cells"
- "#size-cells"
+# This is a generic file other binding inherit from and extend
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml b/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml
new file mode 100644
index 000000000000..0b651450a8f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/nuvoton,ma35d1-nand.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/nuvoton,ma35d1-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 NAND Flash Interface (NFI) Controller
+
+maintainers:
+ - Hui-Ping Chen <hpchen0nvt@gmail.com>
+
+allOf:
+ - $ref: nand-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,ma35d1-nand-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+ properties:
+ reg:
+ minimum: 0
+ maximum: 1
+
+ nand-ecc-step-size:
+ enum: [512, 1024]
+
+ nand-ecc-strength:
+ enum: [8, 12, 24]
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ nand-controller@401A0000 {
+ compatible = "nuvoton,ma35d1-nand-controller";
+ reg = <0x0 0x401A0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NAND_GATE>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-on-flash-bbt;
+ nand-ecc-step-size = <512>;
+ nand-ecc-strength = <8>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot@0 {
+ label = "nand-uboot";
+ read-only;
+ reg = <0x0 0x300000>;
+ };
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
index e737e5beb7bf..4a00ec2b2540 100644
--- a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
@@ -39,7 +39,7 @@ Optional children node properties:
- wp-gpios: GPIO specifier for the write protect pin.
Optional child node of NAND chip nodes:
-Partitions: see partition.txt
+Partitions: see mtd.yaml
Example:
nand-controller@70008000 {
diff --git a/Documentation/devicetree/bindings/mtd/nxp,lpc1773-spifi.yaml b/Documentation/devicetree/bindings/mtd/nxp,lpc1773-spifi.yaml
new file mode 100644
index 000000000000..d6efb9417b7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/nxp,lpc1773-spifi.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/nxp,lpc1773-spifi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP SPI Flash Interface (SPIFI)
+
+description:
+ NXP SPIFI is a specialized SPI interface for serial Flash devices.
+ It supports one Flash device with 1-, 2- and 4-bits width in SPI
+ mode 0 or 3. The controller operates in either command or memory
+ mode. In memory mode the Flash is accessible from the CPU as
+ normal memory.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1773-spifi
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: spifi
+ - const: flash
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: spifi
+ - const: reg
+
+ resets:
+ maxItems: 1
+
+ spi-cpol:
+ enum: [0, 3]
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ spi@40003000 {
+ compatible = "nxp,lpc1773-spifi";
+ reg = <0x40003000 0x1000>, <0x14000000 0x4000000>;
+ reg-names = "spifi", "flash";
+ interrupts = <30>;
+ clocks = <&ccu1 CLK_SPIFI>, <&ccu1 CLK_CPU_SPIFI>;
+ clock-names = "spifi", "reg";
+ resets = <&rgu 53>;
+ };
+
diff --git a/Documentation/devicetree/bindings/mtd/nxp-spifi.txt b/Documentation/devicetree/bindings/mtd/nxp-spifi.txt
deleted file mode 100644
index f8b6b250654e..000000000000
--- a/Documentation/devicetree/bindings/mtd/nxp-spifi.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* NXP SPI Flash Interface (SPIFI)
-
-NXP SPIFI is a specialized SPI interface for serial Flash devices.
-It supports one Flash device with 1-, 2- and 4-bits width in SPI
-mode 0 or 3. The controller operates in either command or memory
-mode. In memory mode the Flash is accessible from the CPU as
-normal memory.
-
-Required properties:
- - compatible : Should be "nxp,lpc1773-spifi"
- - reg : the first contains the register location and length,
- the second contains the memory mapping address and length
- - reg-names: Should contain the reg names "spifi" and "flash"
- - interrupts : Should contain the interrupt for the device
- - clocks : The clocks needed by the SPIFI controller
- - clock-names : Should contain the clock names "spifi" and "reg"
-
-Optional properties:
- - resets : phandle + reset specifier
-
-The SPI Flash must be a child of the SPIFI node and must have a
-compatible property as specified in bindings/mtd/jedec,spi-nor.txt
-
-Optionally it can also contain the following properties.
- - spi-cpol : Controller only supports mode 0 and 3 so either
- both spi-cpol and spi-cpha should be present or
- none of them
- - spi-cpha : See above
- - spi-rx-bus-width : Used to select how many pins that are used
- for input on the controller
-
-See bindings/spi/spi-bus.txt for more information.
-
-Example:
-spifi: spifi@40003000 {
- compatible = "nxp,lpc1773-spifi";
- reg = <0x40003000 0x1000>, <0x14000000 0x4000000>;
- reg-names = "spifi", "flash";
- interrupts = <30>;
- clocks = <&ccu1 CLK_SPIFI>, <&ccu1 CLK_CPU_SPIFI>;
- clock-names = "spifi", "reg";
- resets = <&rgu 53>;
-
- flash@0 {
- compatible = "jedec,spi-nor";
- spi-cpol;
- spi-cpha;
- spi-rx-bus-width = <4>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "data";
- reg = <0 0x200000>;
- };
- };
-};
-
diff --git a/Documentation/devicetree/bindings/mtd/orion-nand.txt b/Documentation/devicetree/bindings/mtd/orion-nand.txt
index 2d6ab660e603..b9997b1f13ac 100644
--- a/Documentation/devicetree/bindings/mtd/orion-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/orion-nand.txt
@@ -13,7 +13,7 @@ Optional properties:
registers in usecs
The device tree may optionally contain sub-nodes describing partitions of the
-address space. See partition.txt for more detail.
+address space. See mtd.yaml for more detail.
Example:
diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
deleted file mode 100644
index 2ba07fc8b79c..000000000000
--- a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Oxford Semiconductor OXNAS NAND Controller
-
-Please refer to nand-controller.yaml for generic information regarding MTD NAND bindings.
-
-Required properties:
- - compatible: "oxsemi,ox820-nand"
- - reg: Base address and length for NAND mapped memory.
-
-Optional Properties:
- - clocks: phandle to the NAND gate clock if needed.
- - resets: phandle to the NAND reset control if needed.
-
-Example:
-
-nandc: nand-controller@41000000 {
- compatible = "oxsemi,ox820-nand";
- reg = <0x41000000 0x100000>;
- clocks = <&stdclk CLK_820_NAND>;
- resets = <&reset RESET_NAND>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- nand@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
- nand-ecc-mode = "soft";
- nand-ecc-algo = "hamming";
-
- partition@0 {
- label = "boot";
- reg = <0x00000000 0x00e00000>;
- read-only;
- };
-
- partition@e00000 {
- label = "ubi";
- reg = <0x00e00000 0x07200000>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
deleted file mode 100644
index ead90e8274d6..000000000000
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Flash partitions in device tree
-===============================
-
-Flash devices can be partitioned into one or more functional ranges (e.g. "boot
-code", "nvram", "kernel").
-
-Different devices may be partitioned in a different ways. Some may use a fixed
-flash layout set at production time. Some may use on-flash table that describes
-the geometry and naming/purpose of each functional region. It is also possible
-to see these methods mixed.
-
-To assist system software in locating partitions, we allow describing which
-method is used for a given flash device. To describe the method there should be
-a subnode of the flash device that is named 'partitions'. It must have a
-'compatible' property, which is used to identify the method to use.
-
-When a single partition is represented with a DT node (it depends on a used
-format) it may also be described using above rules ('compatible' and optionally
-some extra properties / subnodes). It allows describing more complex,
-hierarchical (multi-level) layouts and should be used if there is some
-significant relation between partitions or some partition internally uses
-another partitioning method.
-
-Available bindings are listed in the "partitions" subdirectory.
-
-
-Deprecated: partitions defined in flash node
-============================================
-
-For backwards compatibility partitions as direct subnodes of the flash device are
-supported. This use is discouraged.
-NOTE: also for backwards compatibility, direct subnodes that have a compatible
-string are not considered partitions, as they may be used for other bindings.
diff --git a/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml b/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml
index 76c88027b6d2..97618847ee35 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/arm,arm-firmware-suite.yaml
@@ -9,6 +9,8 @@ title: ARM Firmware Suite (AFS) Partitions
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
+select: false
+
description: |
The ARM Firmware Suite is a flash partitioning system found on the
ARM reference designs: Integrator AP, Integrator CP, Versatile AB,
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index 000000000000..bb4b08546184
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman entries
+
+description: |
+ This corresponds to a binman 'entry'. It is a single partition which holds
+ data of a defined type.
+
+ Binman uses the type to indicate what data file / type to place in the
+ partition. There are quite a number of binman-specific entry types, such as
+ section, fill and files, to be added later.
+
+maintainers:
+ - Simon Glass <sjg@chromium.org>
+
+allOf:
+ - $ref: /schemas/mtd/partitions/partition.yaml#
+
+properties:
+ compatible:
+ enum:
+ - u-boot # u-boot.bin from U-Boot project
+ - tfa-bl31 # bl31.bin or bl31.elf from TF-A project
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@100000 {
+ compatible = "u-boot";
+ reg = <0x100000 0xf00000>;
+ align-size = <0x1000>;
+ align-end = <0x10000>;
+ };
+
+ partition@200000 {
+ compatible = "tfa-bl31";
+ reg = <0x200000 0x100000>;
+ align = <0x4000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
index 7b113e5e3421..94f0742b375c 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
@@ -17,6 +17,8 @@ description: |
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
+select: false
+
properties:
compatible:
const: brcm,bcm4908-partitions
@@ -29,7 +31,7 @@ properties:
patternProperties:
"^partition@[0-9a-f]+$":
- $ref: "partition.yaml#"
+ $ref: partition.yaml#
properties:
compatible:
const: brcm,bcm4908-firmware
diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml
index 3484e06d6bcb..939e7b50db22 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml
@@ -35,6 +35,8 @@ description: |
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
+select: false
+
properties:
compatible:
const: brcm,bcm947xx-cfe-partitions
diff --git a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml
index ad3ccd250802..62086366837c 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/fixed-partitions.yaml
@@ -29,26 +29,37 @@ properties:
"#size-cells": true
+ compression:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Compression algorithm used to store the data in this partition, chosen
+ from a list of well-known algorithms.
+
+ The contents are compressed using this algorithm.
+
+ enum:
+ - none
+ - bzip2
+ - gzip
+ - lzop
+ - lz4
+ - lzma
+ - xz
+ - zstd
+
patternProperties:
"@[0-9a-f]+$":
- allOf:
- - $ref: "partition.yaml#"
- - if:
- properties:
- compatible:
- contains:
- const: sercomm,sc-partitions
- then:
- properties:
- sercomm,scpart-id:
- description: Partition id in Sercomm partition map. Mtd
- parser uses this id to find a record in the partition map
- containing offset and size of the current partition. The
- values from partition map overrides partition offset and
- size defined in reg property of the dts. Frequently these
- values are the same, but may differ if device has bad
- eraseblocks on a flash.
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: partition.yaml#
+
+ properties:
+ sercomm,scpart-id:
+ description: Partition id in Sercomm partition map. Mtd parser
+ uses this id to find a record in the partition map containing
+ offset and size of the current partition. The values from
+ partition map overrides partition offset and size defined in
+ reg property of the dts. Frequently these values are the same,
+ but may differ if device has bad eraseblocks on a flash.
+ $ref: /schemas/types.yaml#/definitions/uint32
required:
- "#address-cells"
@@ -71,6 +82,7 @@ examples:
uimage@100000 {
reg = <0x0100000 0x200000>;
+ compression = "lzma";
};
};
@@ -84,6 +96,7 @@ examples:
partition@0 {
label = "filesystem";
reg = <0x00000000 0x1 0x00000000>;
+ linux,rootfs;
};
};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml
index 99249cdfbfb3..c5fa78ff7125 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml
@@ -18,6 +18,8 @@ description: |
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
+select: false
+
properties:
compatible:
const: linksys,ns-partitions
@@ -30,7 +32,7 @@ properties:
patternProperties:
"^partition@[0-9a-f]+$":
- $ref: "partition.yaml#"
+ $ref: partition.yaml#
properties:
compatible:
items:
diff --git a/Documentation/devicetree/bindings/mtd/partitions/linux,ubi.yaml b/Documentation/devicetree/bindings/mtd/partitions/linux,ubi.yaml
new file mode 100644
index 000000000000..27e1ac1f252e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/linux,ubi.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/linux,ubi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unsorted Block Images
+
+description: |
+ UBI ("Unsorted Block Images") is a volume management system for raw
+ flash devices which manages multiple logical volumes on a single
+ physical flash device and spreads the I/O load (i.e wear-leveling)
+ across the whole flash chip.
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+allOf:
+ - $ref: partition.yaml#
+
+properties:
+ compatible:
+ const: linux,ubi
+
+ volumes:
+ type: object
+ description: UBI Volumes
+
+ patternProperties:
+ "^ubi-volume-.*$":
+ $ref: /schemas/mtd/partitions/ubi-volume.yaml#
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ reg = <0x0 0x100000>;
+ label = "bootloader";
+ read-only;
+ };
+
+ partition@100000 {
+ reg = <0x100000 0x1ff00000>;
+ label = "ubi";
+ compatible = "linux,ubi";
+
+ volumes {
+ ubi-volume-caldata {
+ volid = <2>;
+ volname = "rf";
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ eeprom@0 {
+ reg = <0x0 0x1000>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml
index 5cdd2efa9132..9518281007af 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/nvmem-cells.yaml
@@ -17,7 +17,9 @@ maintainers:
- Ansuel Smith <ansuelsmth@gmail.com>
allOf:
+ - $ref: /schemas/mtd/partitions/partition.yaml#
- $ref: /schemas/nvmem/nvmem.yaml#
+ - $ref: /schemas/nvmem/nvmem-deprecated-cells.yaml#
properties:
compatible:
@@ -26,7 +28,7 @@ properties:
required:
- compatible
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
@@ -84,7 +86,6 @@ examples:
compatible = "nvmem-cells";
label = "calibration";
reg = <0xf00000 0x100000>;
- ranges = <0 0xf00000 0x100000>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
index f1a02d840b12..80d0452a2a33 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
@@ -52,6 +52,62 @@ properties:
immune to paired-pages corruptions
type: boolean
+ linux,rootfs:
+ description: Marks partition that contains root filesystem to mount and boot
+ user space from
+ type: boolean
+
+ align:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 0x80000000
+ multipleOf: 2
+ description:
+ This sets the alignment of the entry in bytes.
+
+ The entry offset is adjusted so that the entry starts on an aligned
+ boundary within the containing section or image. For example ‘align =
+ <16>’ means that the entry will start on a 16-byte boundary. This may
+ mean that padding is added before the entry. The padding is part of
+ the containing section but is not included in the entry, meaning that
+ an empty space may be created before the entry starts. Alignment
+ must be a power of 2. If ‘align’ is not provided, no alignment is
+ performed.
+
+ align-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 0x80000000
+ multipleOf: 2
+ description:
+ This sets the alignment of the entry size in bytes. It must be a power
+ of 2.
+
+ For example, to ensure that the size of an entry is a multiple of 64
+ bytes, set this to 64. While this does not affect the content of the
+ entry itself (the padding is performed only when its parent section is
+ assembled), the end result is that the entry ends with the padding
+ bytes, so may grow. If ‘align-size’ is not provided, no alignment is
+ performed.
+
+ align-end:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 0x80000000
+ multipleOf: 2
+ description:
+ This sets the alignment (in bytes) of the end of an entry with respect
+ to the containing section. It must be a power of 2.
+
+ Some entries require that they end on an alignment boundary,
+ regardless of where they start. This does not move the start of the
+ entry, so the content of the entry will still start at the beginning.
+ But there may be padding at the end. While this does not affect the
+ content of the entry itself (the padding is performed only when its
+ parent section is assembled), the end result is that the entry ends
+ with the padding bytes, so may grow. If ‘align-end’ is not provided,
+ no alignment is performed.
+
if:
not:
required: [ reg ]
@@ -60,4 +116,26 @@ then:
$nodename:
pattern: '^partition-.*$'
+# This is a generic file other binding inherit from and extend
additionalProperties: true
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@100000 {
+ compatible = "u-boot";
+ reg = <0x100000 0xf00000>;
+ align-size = <0x1000>;
+ align-end = <0x10000>;
+ };
+
+ partition@200000 {
+ compatible = "tfa-bl31";
+ reg = <0x200000 0x100000>;
+ align = <0x4000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
new file mode 100644
index 000000000000..1dda2c80747b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/partitions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Partitions
+
+description: |
+ This binding is generic and describes the content of the partitions container
+ node. All partition parsers must be referenced here.
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+oneOf:
+ - $ref: arm,arm-firmware-suite.yaml
+ - $ref: brcm,bcm4908-partitions.yaml
+ - $ref: brcm,bcm947xx-cfe-partitions.yaml
+ - $ref: fixed-partitions.yaml
+ - $ref: linksys,ns-partitions.yaml
+ - $ref: qcom,smem-part.yaml
+ - $ref: redboot-fis.yaml
+ - $ref: tplink,safeloader-partitions.yaml
+
+properties:
+ compatible: true
+
+ '#address-cells':
+ enum: [1, 2]
+
+ '#size-cells':
+ enum: [1, 2]
+
+patternProperties:
+ "^partition(-.+|@[0-9a-f]+)$":
+ $ref: partition.yaml
+
+required:
+ - compatible
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml b/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
index dc07909af023..1c2b4e780ca9 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/qcom,smem-part.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mtd/partitions/qcom,smem-part.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm SMEM NAND flash partition parser binding
+title: Qualcomm SMEM NAND flash partition parser
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
@@ -15,13 +15,15 @@ description: |
varies between partition table revisions. V3 supports maximum 16 partitions
and V4 supports 48 partitions.
+select: false
+
properties:
compatible:
const: qcom,smem-part
patternProperties:
"^partition-[0-9a-z]+$":
- $ref: partition.yaml#
+ $ref: nvmem-cells.yaml
required:
- compatible
@@ -39,22 +41,22 @@ examples:
- |
/* Example declaring dynamic partition */
flash {
- partitions {
- compatible = "qcom,smem-part";
-
- partition-art {
- compatible = "nvmem-cells";
- #address-cells = <1>;
- #size-cells = <1>;
- label = "0:art";
-
- macaddr_art_0: macaddr@0 {
- reg = <0x0 0x6>;
- };
-
- macaddr_art_6: macaddr@6 {
- reg = <0x6 0x6>;
- };
+ partitions {
+ compatible = "qcom,smem-part";
+
+ partition-art {
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ label = "0:art";
+
+ macaddr_art_0: macaddr@0 {
+ reg = <0x0 0x6>;
+ };
+
+ macaddr_art_6: macaddr@6 {
+ reg = <0x6 0x6>;
+ };
+ };
};
- };
};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml
index fee8d81b5276..ba7445cd69e8 100644
--- a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml
+++ b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml
@@ -16,6 +16,8 @@ description: The FLASH Image System (FIS) directory is a flash description
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
+select: false
+
properties:
compatible:
const: redboot-fis
@@ -26,6 +28,10 @@ properties:
device. On a flash memory with 32KB eraseblocks, 0 means the first
eraseblock at 0x00000000, 1 means the second eraseblock at 0x00008000 and so on.
+ '#address-cells': false
+
+ '#size-cells': false
+
required:
- compatible
- fis-index-block
diff --git a/Documentation/devicetree/bindings/mtd/partitions/seama.yaml b/Documentation/devicetree/bindings/mtd/partitions/seama.yaml
new file mode 100644
index 000000000000..4c1cbf43e81a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/seama.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/seama.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Seattle Image Partitions
+
+description: The SEAttle iMAge (SEAMA) partition is a type of partition
+ used for NAND flash devices. This type of flash image is found in some
+ D-Link routers such as DIR-645, DIR-842, DIR-859, DIR-860L, DIR-885L,
+ DIR890L and DCH-M225, as well as in WD and NEC routers on the ath79
+ (MIPS), Broadcom BCM53xx, and RAMIPS platforms. This partition type
+ does not have children defined in the device tree, they need to be
+ detected by software.
+
+allOf:
+ - $ref: partition.yaml#
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ const: seama
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ compatible = "seama";
+ reg = <0x0 0x800000>;
+ label = "firmware";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/tplink,safeloader-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/tplink,safeloader-partitions.yaml
new file mode 100644
index 000000000000..a24bbaac3a90
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/tplink,safeloader-partitions.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/tplink,safeloader-partitions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TP-Link SafeLoader partitions
+
+description: |
+ TP-Link home routers store various data on flash (e.g. bootloader,
+ flash layout, firmware, product info, configuration, calibration
+ data). That requires flash partitioning.
+
+ Flash space layout of TP-Link devices is stored on flash itself using
+ a custom ASCII-based format. That format was first found in TP-Link
+ devices with a custom SafeLoader bootloader. Later it was adapted to
+ CFE and U-Boot bootloaders.
+
+ Partitions specified in partitions table cover whole flash space. Some
+ contain static data that shouldn't get modified (device's MAC or WiFi
+ calibration data). Others are semi-static (like kernel). Finally some
+ partitions contain fully changeable content (like rootfs).
+
+ This binding describes partitioning method and defines offset of ASCII
+ based partitions table. That offset is picked at manufacturing process
+ and doesn't change.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ const: tplink,safeloader-partitions
+
+ partitions-table-offset:
+ description: Flash offset of partitions table
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+patternProperties:
+ "^partition-.*$":
+ $ref: partition.yaml#
+
+required:
+ - partitions-table-offset
+
+additionalProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "tplink,safeloader-partitions";
+ partitions-table-offset = <0x100000>;
+
+ partition-file-system {
+ linux,rootfs;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml b/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
new file mode 100644
index 000000000000..327fa872c001
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/u-boot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-Boot bootloader partition
+
+description: |
+ U-Boot is a bootloader commonly used in embedded devices. It's almost always
+ located on some kind of flash device.
+
+ Device configuration is stored as a set of environment variables that are
+ located in a (usually standalone) block of data.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+allOf:
+ - $ref: partition.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: brcm,u-boot
+ description: |
+ Broadcom stores environment variables inside a U-Boot partition. They
+ can be identified by a custom header with magic value.
+
+patternProperties:
+ "^partition-.*$":
+ $ref: partition.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ compatible = "brcm,u-boot";
+ reg = <0x0 0x100000>;
+ label = "u-boot";
+
+ partition-u-boot-env {
+ };
+ };
+
+ partition@100000 {
+ reg = <0x100000 0x1ff00000>;
+ label = "firmware";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/partitions/ubi-volume.yaml b/Documentation/devicetree/bindings/mtd/partitions/ubi-volume.yaml
new file mode 100644
index 000000000000..19736b26056b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/ubi-volume.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/ubi-volume.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UBI volume
+
+description: |
+ This binding describes a single UBI volume. Volumes can be matches either
+ by their ID or their name, or both.
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+properties:
+ volid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Match UBI volume ID
+
+ volname:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Match UBI volume ID
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+ description:
+ This container may reference an NVMEM layout parser.
+
+anyOf:
+ - required:
+ - volid
+
+ - required:
+ - volname
+
+# This is a generic file other binding inherit from and extend
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
index 482a2c068740..5511389960f0 100644
--- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
+++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
@@ -11,12 +11,18 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,ipq806x-nand
- - qcom,ipq4019-nand
- - qcom,ipq6018-nand
- - qcom,ipq8074-nand
- - qcom,sdx55-nand
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sdx75-nand
+ - const: qcom,sdx55-nand
+ - items:
+ - enum:
+ - qcom,ipq806x-nand
+ - qcom,ipq4019-nand
+ - qcom,ipq6018-nand
+ - qcom,ipq8074-nand
+ - qcom,sdx55-nand
reg:
maxItems: 1
@@ -31,13 +37,24 @@ properties:
- const: core
- const: aon
- "#address-cells": true
- "#size-cells": true
+ qcom,cmd-crci:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Must contain the ADM command type CRCI block instance number specified for
+ the NAND controller on the given platform
+
+ qcom,data-crci:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Must contain the ADM data type CRCI block instance number specified for
+ the NAND controller on the given platform
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
+
nand-bus-width:
const: 8
@@ -48,8 +65,26 @@ patternProperties:
enum:
- 512
+ qcom,boot-partitions:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: offset
+ - description: size
+ description:
+ Boot partition use a different layout where the 4 bytes of spare
+ data are not protected by ECC. Use this to declare these special
+ partitions by defining first the offset and then the size.
+
+ It's in the form of <offset1 size1 offset2 size2 offset3 ...>
+ and should be declared in ascending order.
+
+ Refer to the ipq8064 example on how to use this special binding.
+
+ unevaluatedProperties: false
+
allOf:
- - $ref: "nand-controller.yaml#"
+ - $ref: nand-controller.yaml#
- if:
properties:
@@ -66,17 +101,17 @@ allOf:
items:
- const: rxtx
- qcom,cmd-crci:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- Must contain the ADM command type CRCI block instance number
- specified for the NAND controller on the given platform
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdx75-nand
- qcom,data-crci:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- Must contain the ADM data type CRCI block instance number
- specified for the NAND controller on the given platform
+ then:
+ properties:
+ iommus:
+ maxItems: 1
- if:
properties:
@@ -102,30 +137,13 @@ allOf:
- const: rx
- const: cmd
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,ipq806x-nand
-
- then:
- properties:
- qcom,boot-partitions:
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: offset
- - description: size
- description:
- Boot partition use a different layout where the 4 bytes of spare
- data are not protected by ECC. Use this to declare these special
- partitions by defining first the offset and then the size.
-
- It's in the form of <offset1 size1 offset2 size2 offset3 ...>
- and should be declared in ascending order.
+ qcom,cmd-crci: false
+ qcom,data-crci: false
- Refer to the ipq8064 example on how to use this special binding.
+ patternProperties:
+ "^nand@[a-f0-9]$":
+ properties:
+ qcom,boot-partitions: false
required:
- compatible
@@ -139,85 +157,85 @@ examples:
- |
#include <dt-bindings/clock/qcom,gcc-ipq806x.h>
nand-controller@1ac00000 {
- compatible = "qcom,ipq806x-nand";
- reg = <0x1ac00000 0x800>;
+ compatible = "qcom,ipq806x-nand";
+ reg = <0x1ac00000 0x800>;
- clocks = <&gcc EBI2_CLK>,
- <&gcc EBI2_AON_CLK>;
- clock-names = "core", "aon";
+ clocks = <&gcc EBI2_CLK>,
+ <&gcc EBI2_AON_CLK>;
+ clock-names = "core", "aon";
- dmas = <&adm_dma 3>;
- dma-names = "rxtx";
- qcom,cmd-crci = <15>;
- qcom,data-crci = <3>;
+ dmas = <&adm_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- nand@0 {
- reg = <0>;
+ nand@0 {
+ reg = <0>;
- nand-ecc-strength = <4>;
- nand-bus-width = <8>;
+ nand-ecc-strength = <4>;
+ nand-bus-width = <8>;
- qcom,boot-partitions = <0x0 0x58a0000>;
+ qcom,boot-partitions = <0x0 0x58a0000>;
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
- partition@0 {
- label = "boot-nand";
- reg = <0 0x58a0000>;
- };
+ partition@0 {
+ label = "boot-nand";
+ reg = <0 0x58a0000>;
+ };
- partition@58a0000 {
- label = "fs-nand";
- reg = <0x58a0000 0x4000000>;
- };
+ partition@58a0000 {
+ label = "fs-nand";
+ reg = <0x58a0000 0x4000000>;
+ };
+ };
};
- };
};
#include <dt-bindings/clock/qcom,gcc-ipq4019.h>
nand-controller@79b0000 {
- compatible = "qcom,ipq4019-nand";
- reg = <0x79b0000 0x1000>;
-
- clocks = <&gcc GCC_QPIC_CLK>,
- <&gcc GCC_QPIC_AHB_CLK>;
- clock-names = "core", "aon";
-
- dmas = <&qpicbam 0>,
- <&qpicbam 1>,
- <&qpicbam 2>;
- dma-names = "tx", "rx", "cmd";
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- nand@0 {
- reg = <0>;
- nand-ecc-strength = <4>;
- nand-bus-width = <8>;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "boot-nand";
- reg = <0 0x58a0000>;
- };
-
- partition@58a0000 {
- label = "fs-nand";
- reg = <0x58a0000 0x4000000>;
- };
+ compatible = "qcom,ipq4019-nand";
+ reg = <0x79b0000 0x1000>;
+
+ clocks = <&gcc GCC_QPIC_CLK>,
+ <&gcc GCC_QPIC_AHB_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <&qpicbam 0>,
+ <&qpicbam 1>,
+ <&qpicbam 2>;
+ dma-names = "tx", "rx", "cmd";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-ecc-strength = <4>;
+ nand-bus-width = <8>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "boot-nand";
+ reg = <0 0x58a0000>;
+ };
+
+ partition@58a0000 {
+ label = "fs-nand";
+ reg = <0x58a0000 0x4000000>;
+ };
+ };
};
- };
};
...
diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
new file mode 100644
index 000000000000..092448d7bfc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/raw-nand-chip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raw NAND Chip Common Properties
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+allOf:
+ - $ref: nand-chip.yaml#
+
+description: |
+ The ECC strength and ECC step size properties define the user
+ desires in terms of correction capability of a controller. Together,
+ they request the ECC engine to correct {strength} bit errors per
+ {size} bytes for a particular raw NAND chip.
+
+ The interpretation of these parameters is implementation-defined, so
+ not all implementations must support all possible
+ combinations. However, implementations are encouraged to further
+ specify the value(s) they support.
+
+properties:
+ $nodename:
+ pattern: "^nand@[a-f0-9]$"
+
+ reg:
+ description:
+ Contains the chip-select IDs.
+
+ nand-ecc-placement:
+ description:
+ Location of the ECC bytes. This location is unknown by default
+ but can be explicitly set to "oob", if all ECC bytes are
+ known to be stored in the OOB area, or "interleaved" if ECC
+ bytes will be interleaved with regular data in the main area.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ oob, interleaved ]
+ deprecated: true
+
+ nand-ecc-mode:
+ description:
+ Legacy ECC configuration mixing the ECC engine choice and
+ configuration.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [none, soft, soft_bch, hw, hw_syndrome, on-die]
+ deprecated: true
+
+ nand-bus-width:
+ description:
+ Bus width to the NAND chip
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16]
+ default: 8
+
+ nand-on-flash-bbt:
+ description:
+ With this property, the OS will search the device for a Bad
+ Block Table (BBT). If not found, it will create one, reserve
+ a few blocks at the end of the device to store it and update
+ it as the device ages. Otherwise, the out-of-band area of a
+ few pages of all the blocks will be scanned at boot time to
+ find Bad Block Markers (BBM). These markers will help to
+ build a volatile BBT in RAM.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-ecc-maximize:
+ description:
+ Whether or not the ECC strength should be maximized. The
+ maximum ECC strength is both controller and chip
+ dependent. The ECC engine has to select the ECC config
+ providing the best strength and taking the OOB area size
+ constraint into account. This is particularly useful when
+ only the in-band area is used by the upper layers, and you
+ want to make your NAND as reliable as possible.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-is-boot-medium:
+ description:
+ Whether or not the NAND chip is a boot medium. Drivers might
+ use this information to select ECC algorithms supported by
+ the boot ROM or similar restrictions.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-rb:
+ description:
+ Contains the native Ready/Busy IDs.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ rb-gpios:
+ description:
+ Contains one or more GPIO descriptor (the numper of descriptor
+ depends on the number of R/B pins exposed by the flash) for the
+ Ready/Busy pins. Active state refers to the NAND ready state and
+ should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
+
+ wp-gpios:
+ description:
+ Contains one GPIO descriptor for the Write Protect pin.
+ Active state refers to the NAND Write Protect state and should be
+ set to GPIOD_ACTIVE_LOW unless the signal is inverted.
+ maxItems: 1
+
+required:
+ - reg
+
+# This is a generic file other binding inherit from and extend
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/mtd/realtek,rtl9301-ecc.yaml b/Documentation/devicetree/bindings/mtd/realtek,rtl9301-ecc.yaml
new file mode 100644
index 000000000000..55b35c3db0ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/realtek,rtl9301-ecc.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/realtek,rtl9301-ecc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek SoCs NAND ECC engine
+
+maintainers:
+ - Markus Stockhausen <markus.stockhausen@gmx.de>
+
+properties:
+ compatible:
+ const: realtek,rtl9301-ecc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ecc0: ecc@1a600 {
+ compatible = "realtek,rtl9301-ecc";
+ reg = <0x1a600 0x54>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
index 7b18bc5cc8b3..cc6b8274e6a2 100644
--- a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
+++ b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/mtd/renesas-nandc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas R-Car Gen3 & RZ/N1x NAND flash controller device tree bindings
+title: Renesas R-Car Gen3 & RZ/N1x NAND flash controller
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- - $ref: "nand-controller.yaml"
+ - $ref: nand-controller.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
index d681a4676f06..ee53715ffdca 100644
--- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
+++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip SoCs NAND FLASH Controller (NFC)
allOf:
- - $ref: "nand-controller.yaml#"
+ - $ref: nand-controller.yaml#
maintainers:
- Heiko Stuebner <heiko@sntech.de>
@@ -19,7 +19,9 @@ properties:
- const: rockchip,rk2928-nfc
- const: rockchip,rv1108-nfc
- items:
- - const: rockchip,rk3036-nfc
+ - enum:
+ - rockchip,rk3036-nfc
+ - rockchip,rk3128-nfc
- const: rockchip,rk2928-nfc
- items:
- const: rockchip,rk3308-nfc
@@ -55,6 +57,7 @@ properties:
patternProperties:
"^nand@[0-7]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
reg:
minimum: 0
@@ -114,6 +117,8 @@ patternProperties:
Only used in combination with 'nand-is-boot-medium'.
+ unevaluatedProperties: false
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/mtd/samsung,s5pv210-onenand.yaml b/Documentation/devicetree/bindings/mtd/samsung,s5pv210-onenand.yaml
new file mode 100644
index 000000000000..e07941b69904
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/samsung,s5pv210-onenand.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/samsung,s5pv210-onenand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S5Pv210 SoC OneNAND Controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - samsung,s5pv210-onenand
+
+ reg:
+ items:
+ - description: Control registers
+ - description: OneNAND interface nCE[0]
+ - description: OneNAND interface nCE[1]
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: bus
+ - const: onenand
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+allOf:
+ - $ref: nand-controller.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/s5pv210.h>
+
+ nand-controller@b0600000 {
+ compatible = "samsung,s5pv210-onenand";
+ reg = <0xb0600000 0x2000>,
+ <0xb0000000 0x20000>,
+ <0xb0040000 0x20000>;
+ clocks = <&clocks CLK_NANDXL>, <&clocks DOUT_FLASH>;
+ clock-names = "bus", "onenand";
+ interrupt-parent = <&vic1>;
+ interrupts = <31>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
deleted file mode 100644
index 09815c40fc8a..000000000000
--- a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Samsung S3C2410 and compatible NAND flash controller
-
-Required properties:
-- compatible : The possible values are:
- "samsung,s3c2410-nand"
- "samsung,s3c2412-nand"
- "samsung,s3c2440-nand"
-- reg : register's location and length.
-- #address-cells, #size-cells : see nand-controller.yaml
-- clocks : phandle to the nand controller clock
-- clock-names : must contain "nand"
-
-Optional child nodes:
-Child nodes representing the available nand chips.
-
-Optional child properties:
-- nand-ecc-mode : see nand-controller.yaml
-- nand-on-flash-bbt : see nand-controller.yaml
-
-Each child device node may optionally contain a 'partitions' sub-node,
-which further contains sub-nodes describing the flash partition mapping.
-See partition.txt for more detail.
-
-Example:
-
-nand-controller@4e000000 {
- compatible = "samsung,s3c2440-nand";
- reg = <0x4e000000 0x40>;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- clocks = <&clocks HCLK_NAND>;
- clock-names = "nand";
-
- nand {
- nand-ecc-mode = "soft";
- nand-on-flash-bbt;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "u-boot";
- reg = <0 0x040000>;
- };
-
- partition@40000 {
- label = "kernel";
- reg = <0x040000 0x500000>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
index dd3cd1d53009..77a8727c7966 100644
--- a/Documentation/devicetree/bindings/mtd/spi-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/mtd/spi-nand.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SPI-NAND flash device tree bindings
+title: SPI-NAND flash
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- - $ref: "nand-chip.yaml#"
+ - $ref: nand-chip.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
index eab8ea3da1fa..b8ef9ba88e92 100644
--- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mtd/st,stm32-fmc2-nand.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics Flexible Memory Controller 2 (FMC2) Bindings
+title: STMicroelectronics Flexible Memory Controller 2 (FMC2)
maintainers:
- Christophe Kerello <christophe.kerello@foss.st.com>
@@ -14,10 +14,11 @@ properties:
enum:
- st,stm32mp15-fmc2
- st,stm32mp1-fmc2-nfc
+ - st,stm32mp25-fmc2-nfc
reg:
minItems: 6
- maxItems: 7
+ maxItems: 12
interrupts:
maxItems: 1
@@ -37,6 +38,7 @@ properties:
patternProperties:
"^nand@[a-f0-9]$":
type: object
+ $ref: raw-nand-chip.yaml
properties:
nand-ecc-step-size:
const: 512
@@ -44,8 +46,10 @@ patternProperties:
nand-ecc-strength:
enum: [1, 4, 8]
+ unevaluatedProperties: false
+
allOf:
- - $ref: "nand-controller.yaml#"
+ - $ref: nand-controller.yaml#
- if:
properties:
@@ -89,6 +93,28 @@ allOf:
- description: Chip select 1 command
- description: Chip select 1 address space
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp25-fmc2-nfc
+ then:
+ properties:
+ reg:
+ items:
+ - description: Chip select 0 data
+ - description: Chip select 0 command
+ - description: Chip select 0 address space
+ - description: Chip select 1 data
+ - description: Chip select 1 command
+ - description: Chip select 1 address space
+ - description: Chip select 2 data
+ - description: Chip select 2 command
+ - description: Chip select 2 address space
+ - description: Chip select 3 data
+ - description: Chip select 3 command
+ - description: Chip select 3 address space
+
required:
- compatible
- reg
@@ -101,31 +127,32 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
+
nand-controller@58002000 {
- compatible = "st,stm32mp15-fmc2";
- reg = <0x58002000 0x1000>,
- <0x80000000 0x1000>,
- <0x88010000 0x1000>,
- <0x88020000 0x1000>,
- <0x81000000 0x1000>,
- <0x89010000 0x1000>,
- <0x89020000 0x1000>;
- interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
- <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
- <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
- dma-names = "tx", "rx", "ecc";
- clocks = <&rcc FMC_K>;
- resets = <&rcc FMC_R>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- nand@0 {
- reg = <0>;
- nand-on-flash-bbt;
+ compatible = "st,stm32mp15-fmc2";
+ reg = <0x58002000 0x1000>,
+ <0x80000000 0x1000>,
+ <0x88010000 0x1000>,
+ <0x88020000 0x1000>,
+ <0x81000000 0x1000>,
+ <0x89010000 0x1000>,
+ <0x89020000 0x1000>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
+ <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
+ <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
+ dma-names = "tx", "rx", "ecc";
+ clocks = <&rcc FMC_K>;
+ resets = <&rcc FMC_R>;
#address-cells = <1>;
- #size-cells = <1>;
- };
+ #size-cells = <0>;
+
+ nand@0 {
+ reg = <0>;
+ nand-on-flash-bbt;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/mtd/technologic,nand.yaml b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml
new file mode 100644
index 000000000000..a3c316436317
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/technologic,nand.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/technologic,nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Technologic Systems NAND controller
+
+maintainers:
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: nand-controller.yaml
+
+properties:
+ compatible:
+ oneOf:
+ - const: technologic,ts7200-nand
+ - items:
+ - enum:
+ - technologic,ts7300-nand
+ - technologic,ts7260-nand
+ - technologic,ts7250-nand
+ - const: technologic,ts7200-nand
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ nand-controller@60000000 {
+ compatible = "technologic,ts7200-nand";
+ reg = <0x60000000 0x8000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nand@0 {
+ reg = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml
index 30b458c41cac..df4fdc02456d 100644
--- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml
+++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml
@@ -30,6 +30,8 @@ properties:
patternProperties:
"^flash@[0-1],[0-9a-f]+$":
type: object
+ $ref: mtd-physmap.yaml
+ unevaluatedProperties: false
required:
- compatible
@@ -44,26 +46,26 @@ additionalProperties: false
examples:
- |
bus {
- #address-cells = <2>;
- #size-cells = <2>;
-
- hbmc: memory-controller@47034000 {
- compatible = "ti,am654-hbmc";
- reg = <0x0 0x47034000 0x0 0x100>,
- <0x5 0x00000000 0x1 0x0000000>;
- ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */
- <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */
- clocks = <&k3_clks 102 0>;
#address-cells = <2>;
- #size-cells = <1>;
- power-domains = <&k3_pds 55>;
- mux-controls = <&hbmc_mux 0>;
+ #size-cells = <2>;
- flash@0,0 {
- compatible = "cypress,hyperflash", "cfi-flash";
- reg = <0x0 0x0 0x4000000>;
- #address-cells = <1>;
+ hbmc: memory-controller@47034000 {
+ compatible = "ti,am654-hbmc";
+ reg = <0x0 0x47034000 0x0 0x100>,
+ <0x5 0x00000000 0x1 0x0000000>;
+ ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */
+ <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */
+ clocks = <&k3_clks 102 0>;
+ #address-cells = <2>;
#size-cells = <1>;
+ power-domains = <&k3_pds 55>;
+ mux-controls = <&hbmc_mux 0>;
+
+ flash@0,0 {
+ compatible = "cypress,hyperflash", "cfi-flash";
+ reg = <0x0 0x0 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
};
- };
};
diff --git a/Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml
new file mode 100644
index 000000000000..ed24b0ea86e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/ti,davinci-nand.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/ti,davinci-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DaVinci NAND controller
+
+maintainers:
+ - Marcus Folkesson <marcus.folkesson@gmail.com>
+
+allOf:
+ - $ref: nand-controller.yaml
+
+properties:
+ compatible:
+ enum:
+ - ti,davinci-nand
+ - ti,keystone-nand
+
+ reg:
+ items:
+ - description: Access window.
+ - description: AEMIF control registers.
+
+ partitions:
+ $ref: /schemas/mtd/partitions/partitions.yaml
+
+ ti,davinci-chipselect:
+ description:
+ Number of chipselect. Indicate on the davinci_nand driver which
+ chipselect is used for accessing the nand.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ ti,davinci-mask-ale:
+ description:
+ Mask for ALE. Needed for executing address phase. These offset will be
+ added to the base address for the chip select space the NAND Flash
+ device is connected to.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x08
+
+ ti,davinci-mask-cle:
+ description:
+ Mask for CLE. Needed for executing command phase. These offset will be
+ added to the base address for the chip select space the NAND Flash device
+ is connected to.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x10
+
+ ti,davinci-mask-chipsel:
+ description:
+ Mask for chipselect address. Needed to mask addresses for given
+ chipselect.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ ti,davinci-ecc-bits:
+ description: Used ECC bits.
+ enum: [1, 4]
+
+ ti,davinci-ecc-mode:
+ description: Operation mode of the NAND ECC mode.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [none, soft, hw, on-die]
+ deprecated: true
+
+ ti,davinci-nand-buswidth:
+ description: Bus width to the NAND chip.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16]
+ default: 8
+ deprecated: true
+
+ ti,davinci-nand-use-bbt:
+ type: boolean
+ description:
+ Use flash based bad block table support. OOB identifier is saved in OOB
+ area.
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - ti,davinci-chipselect
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ nand-controller@2000000,0 {
+ compatible = "ti,davinci-nand";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x02000000 0x02000000>,
+ <1 0x00000000 0x00008000>;
+
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+
+ ti,davinci-nand-buswidth = <16>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot env";
+ reg = <0 0x020000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml
index 4ac198814b7a..00540302bcae 100644
--- a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml
@@ -61,12 +61,9 @@ properties:
GPIO connection to R/B signal from NAND chip
maxItems: 1
-patternProperties:
- "@[0-9a-f]+$":
- $ref: "/schemas/mtd/partitions/partition.yaml"
-
allOf:
- - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml"
+ - $ref: /schemas/memory-controllers/ti,gpmc-child.yaml
+ - $ref: mtd.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml
index a953f7397c40..7d3ace4f5505 100644
--- a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml
+++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml
@@ -15,6 +15,9 @@ description:
as child nodes of the GPMC controller.
properties:
+ $nodename:
+ pattern: "^onenand@[0-9],[0,9]$"
+
compatible:
const: ti,omap2-onenand
@@ -33,10 +36,10 @@ properties:
patternProperties:
"@[0-9a-f]+$":
- $ref: "/schemas/mtd/partitions/partition.yaml"
+ $ref: /schemas/mtd/partitions/partition.yaml
allOf:
- - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml"
+ - $ref: /schemas/memory-controllers/ti,gpmc-child.yaml
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
deleted file mode 100644
index 7db5e6e609df..000000000000
--- a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Freescale's NAND flash controller (NFC)
-
-This variant of the Freescale NAND flash controller (NFC) can be found on
-Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
-
-Required properties:
-- compatible: Should be set to "fsl,vf610-nfc".
-- reg: address range of the NFC.
-- interrupts: interrupt of the NFC.
-- #address-cells: shall be set to 1. Encode the nand CS.
-- #size-cells : shall be set to 0.
-- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
-- assigned-clock-rates: The NAND bus timing is derived from this clock
- rate and should not exceed maximum timing for any NAND memory chip
- in a board stuffing. Typical NAND memory timings derived from this
- clock are found in the SoC hardware reference manual. Furthermore,
- there might be restrictions on maximum rates when using hardware ECC.
-
-- #address-cells, #size-cells : Must be present if the device has sub-nodes
- representing partitions.
-
-Required children nodes:
-Children nodes represent the available nand chips. Currently the driver can
-only handle one NAND chip.
-
-Required properties:
-- compatible: Should be set to "fsl,vf610-nfc-cs".
-- nand-bus-width: see nand-controller.yaml
-- nand-ecc-mode: see nand-controller.yaml
-
-Required properties for hardware ECC:
-- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand-controller.yaml)
-- nand-ecc-step-size: step size equals page size, currently only 2k pages are
- supported
-- nand-on-flash-bbt: see nand-controller.yaml
-
-Example:
-
- nfc: nand@400e0000 {
- compatible = "fsl,vf610-nfc";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x400e0000 0x4000>;
- interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks VF610_CLK_NFC>;
- clock-names = "nfc";
- assigned-clocks = <&clks VF610_CLK_NFC>;
- assigned-clock-rates = <33000000>;
-
- nand@0 {
- compatible = "fsl,vf610-nfc-nandcs";
- reg = <0>;
- nand-bus-width = <8>;
- nand-ecc-mode = "hw";
- nand-ecc-strength = <32>;
- nand-ecc-step-size = <2048>;
- nand-on-flash-bbt;
- };
- };
diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
index ee4de9fbaf4d..ef7e33ec85d4 100644
--- a/Documentation/devicetree/bindings/mux/gpio-mux.yaml
+++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mux/gpio-mux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: GPIO-based multiplexer controller bindings
+title: GPIO-based multiplexer controller
maintainers:
- Peter Rosin <peda@axentia.se>
@@ -25,6 +25,10 @@ properties:
description:
List of gpios used to control the multiplexer, least significant bit first.
+ mux-supply:
+ description:
+ Regulator to power on the multiplexer.
+
'#mux-control-cells':
enum: [ 0, 1 ]
diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
index d3d854967359..9e2d78a78e40 100644
--- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mux/mux-consumer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common multiplexer controller consumer bindings
+title: Common multiplexer controller consumer
maintainers:
- Peter Rosin <peda@axentia.se>
diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml
index c855fbad3884..78340bbe4df6 100644
--- a/Documentation/devicetree/bindings/mux/mux-controller.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mux/mux-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common multiplexer controller provider bindings
+title: Common multiplexer controller provider
maintainers:
- Peter Rosin <peda@axentia.se>
@@ -20,7 +20,6 @@ description: |
space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer,
0-7 for an 8-way multiplexer, etc.
-
Mux controller nodes
--------------------
@@ -74,7 +73,7 @@ select:
properties:
$nodename:
- pattern: '^mux-controller(@.*|-[0-9a-f]+)?$'
+ pattern: '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$'
'#mux-control-cells':
enum: [ 0, 1 ]
diff --git a/Documentation/devicetree/bindings/mux/reg-mux.yaml b/Documentation/devicetree/bindings/mux/reg-mux.yaml
index dfd9ea582bb7..dc4be092fc2f 100644
--- a/Documentation/devicetree/bindings/mux/reg-mux.yaml
+++ b/Documentation/devicetree/bindings/mux/reg-mux.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/mux/reg-mux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic register bitfield-based multiplexer controller bindings
+title: Generic register bitfield-based multiplexer controller
maintainers:
- Peter Rosin <peda@axentia.se>
diff --git a/Documentation/devicetree/bindings/net/actions,owl-emac.yaml b/Documentation/devicetree/bindings/net/actions,owl-emac.yaml
index d30fada2ac39..5718ab4654b2 100644
--- a/Documentation/devicetree/bindings/net/actions,owl-emac.yaml
+++ b/Documentation/devicetree/bindings/net/actions,owl-emac.yaml
@@ -16,7 +16,7 @@ description: |
operation modes at 10/100 Mb/s data transfer rates.
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml b/Documentation/devicetree/bindings/net/adi,adin.yaml
index 929cf8c0b0fd..c425a9f1886d 100644
--- a/Documentation/devicetree/bindings/net/adi,adin.yaml
+++ b/Documentation/devicetree/bindings/net/adi,adin.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADIN1200/ADIN1300 PHY
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
description: |
Bindings for Analog Devices Industrial Ethernet PHYs
diff --git a/Documentation/devicetree/bindings/net/adi,adin1110.yaml b/Documentation/devicetree/bindings/net/adi,adin1110.yaml
index b6bd8ee38a18..0a73e01d7f97 100644
--- a/Documentation/devicetree/bindings/net/adi,adin1110.yaml
+++ b/Documentation/devicetree/bindings/net/adi,adin1110.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADI ADIN1110 MAC-PHY
maintainers:
- - Alexandru Tachici <alexandru.tachici@analog.com>
+ - Marcelo Schmitt <marcelo.schmitt@analog.com>
description: |
The ADIN1110 is a low power single port 10BASE-T1L MAC-
@@ -46,6 +46,10 @@ properties:
interrupts:
maxItems: 1
+ reset-gpios:
+ maxItems: 1
+ description: GPIO connected to active low reset
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/net/aeonsemi,as21xxx.yaml b/Documentation/devicetree/bindings/net/aeonsemi,as21xxx.yaml
new file mode 100644
index 000000000000..69eb29dc4d7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/aeonsemi,as21xxx.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/aeonsemi,as21xxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aeonsemi AS21XXX Ethernet PHY
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |
+ Aeonsemi AS21xxx Ethernet PHYs requires a firmware to be loaded to actually
+ work. The same firmware is compatible with various PHYs of the same family.
+
+ A PHY with not firmware loaded will be exposed on the MDIO bus with ID
+ 0x7500 0x7500 or 0x7500 0x9410 on C45 registers.
+
+ This can be done and is implemented by OEM in 2 different way:
+ - Attached SPI flash directly to the PHY with the firmware. The PHY
+ will self load the firmware in the presence of this configuration.
+ - Manually provided firmware loaded from a file in the filesystem.
+
+ Each PHY can support up to 5 LEDs.
+
+ AS2xxx PHY Name logic:
+
+ AS21x1xxB1
+ ^ ^^
+ | |J: Supports SyncE/PTP
+ | |P: No SyncE/PTP support
+ | 1: Supports 2nd Serdes
+ | 2: Not 2nd Serdes support
+ 0: 10G, 5G, 2.5G
+ 5: 5G, 2.5G
+ 2: 2.5G
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id7500.9410
+ - ethernet-phy-id7500.9402
+ - ethernet-phy-id7500.9412
+ - ethernet-phy-id7500.9422
+ - ethernet-phy-id7500.9432
+ - ethernet-phy-id7500.9442
+ - ethernet-phy-id7500.9452
+ - ethernet-phy-id7500.9462
+ - ethernet-phy-id7500.9472
+ - ethernet-phy-id7500.9482
+ - ethernet-phy-id7500.9492
+ required:
+ - compatible
+
+properties:
+ reg:
+ maxItems: 1
+
+ firmware-name:
+ description: specify the name of PHY firmware to load
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id7500.9410
+then:
+ required:
+ - firmware-name
+else:
+ properties:
+ firmware-name: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@1f {
+ compatible = "ethernet-phy-id7500.9410",
+ "ethernet-phy-ieee802.3-c45";
+
+ reg = <31>;
+ firmware-name = "as21x1x_fw.bin";
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ default-state = "keep";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/airoha,an7583-mdio.yaml b/Documentation/devicetree/bindings/net/airoha,an7583-mdio.yaml
new file mode 100644
index 000000000000..3e7e68ec1560
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/airoha,an7583-mdio.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/airoha,an7583-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha AN7583 Dedicated MDIO Controller
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ Airoha AN7583 SoC have 3 different MDIO Controller.
+
+ One comes from the intergated Switch based on MT7530.
+
+ The other 2 (that this schema describe) live under the SCU
+ register supporting both C22 and C45 PHYs.
+
+$ref: mdio.yaml#
+
+properties:
+ compatible:
+ const: airoha,an7583-mdio
+
+ reg:
+ enum: [0xc8, 0xcc]
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clock-frequency:
+ default: 2500000
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ system-controller {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-bus@c8 {
+ compatible = "airoha,an7583-mdio";
+ reg = <0xc8>;
+
+ clocks = <&scu>;
+ resets = <&scu>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
new file mode 100644
index 000000000000..fbe2ddcdd909
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/airoha,en7581-eth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 Frame Engine Ethernet controller
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The frame engine ethernet controller can be found on Airoha SoCs.
+ These SoCs have multi-GMAC ports.
+
+properties:
+ compatible:
+ enum:
+ - airoha,en7581-eth
+ - airoha,an7583-eth
+
+ reg:
+ items:
+ - description: Frame engine base address
+ - description: QDMA0 base address
+ - description: QDMA1 base address
+
+ reg-names:
+ items:
+ - const: fe
+ - const: qdma0
+ - const: qdma1
+
+ interrupts:
+ items:
+ - description: QDMA lan irq0
+ - description: QDMA lan irq1
+ - description: QDMA lan irq2
+ - description: QDMA lan irq3
+ - description: QDMA wan irq0
+ - description: QDMA wan irq1
+ - description: QDMA wan irq2
+ - description: QDMA wan irq3
+ - description: FE error irq
+ - description: PDMA irq
+
+ resets:
+ minItems: 7
+ maxItems: 8
+
+ reset-names:
+ items:
+ - const: fe
+ - const: pdma
+ - const: qdma
+ - const: xsi-mac
+ - const: hsi0-mac
+ - const: hsi1-mac
+ - enum: [ hsi-mac, xfp-mac ]
+ - const: xfp-mac
+ minItems: 7
+
+ memory-region:
+ items:
+ - description: QDMA0 buffer memory
+ - description: QDMA1 buffer memory
+
+ memory-region-names:
+ items:
+ - const: qdma0-buf
+ - const: qdma1-buf
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ airoha,npu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the node used to configure the NPU module.
+ The Airoha Network Processor Unit (NPU) provides a configuration
+ interface to implement hardware flow offloading programming Packet
+ Processor Engine (PPE) flow table.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - airoha,en7581-eth
+ then:
+ properties:
+ resets:
+ minItems: 8
+
+ reset-names:
+ minItems: 8
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - airoha,an7583-eth
+ then:
+ properties:
+ resets:
+ maxItems: 7
+
+ reset-names:
+ maxItems: 7
+
+patternProperties:
+ "^ethernet@[1-4]$":
+ type: object
+ unevaluatedProperties: false
+ $ref: ethernet-controller.yaml#
+ description:
+ Ethernet GMAC port associated to the MAC controller
+ properties:
+ compatible:
+ const: airoha,eth-mac
+
+ reg:
+ minimum: 1
+ maximum: 4
+ description: GMAC port identifier
+
+ required:
+ - reg
+ - compatible
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/en7523-clk.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ eth: ethernet@1fb50000 {
+ compatible = "airoha,en7581-eth";
+ reg = <0 0x1fb50000 0 0x2600>,
+ <0 0x1fb54000 0 0x2000>,
+ <0 0x1fb56000 0 0x2000>;
+ reg-names = "fe", "qdma0", "qdma1";
+
+ resets = <&scuclk 44>,
+ <&scuclk 30>,
+ <&scuclk 31>,
+ <&scuclk 6>,
+ <&scuclk 15>,
+ <&scuclk 16>,
+ <&scuclk 17>,
+ <&scuclk 26>;
+ reset-names = "fe", "pdma", "qdma", "xsi-mac",
+ "hsi0-mac", "hsi1-mac", "hsi-mac",
+ "xfp-mac";
+
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+
+ memory-region = <&qdma0_buf>, <&qdma1_buf>;
+ memory-region-names = "qdma0-buf", "qdma1-buf";
+
+ airoha,npu = <&npu>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mac: ethernet@1 {
+ compatible = "airoha,eth-mac";
+ reg = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
new file mode 100644
index 000000000000..59c57f58116b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/airoha,en7581-npu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha Network Processor Unit for EN7581 SoC
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The Airoha Network Processor Unit (NPU) provides a configuration interface
+ to implement wired and wireless hardware flow offloading programming Packet
+ Processor Engine (PPE) flow table.
+
+properties:
+ compatible:
+ enum:
+ - airoha,en7581-npu
+ - airoha,an7583-npu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: mbox host irq line
+ - description: watchdog0 irq line
+ - description: watchdog1 irq line
+ - description: watchdog2 irq line
+ - description: watchdog3 irq line
+ - description: watchdog4 irq line
+ - description: watchdog5 irq line
+ - description: watchdog6 irq line
+ - description: watchdog7 irq line
+ - description: wlan irq line0
+ - description: wlan irq line1
+ - description: wlan irq line2
+ - description: wlan irq line3
+ - description: wlan irq line4
+ - description: wlan irq line5
+
+ memory-region:
+ oneOf:
+ - items:
+ - description: NPU firmware binary region
+ - items:
+ - description: NPU firmware binary region
+ - description: NPU wlan offload RX buffers region
+ - description: NPU wlan offload TX buffers region
+ - description: NPU wlan offload TX packet identifiers region
+
+ memory-region-names:
+ items:
+ - const: firmware
+ - const: pkt
+ - const: tx-pkt
+ - const: tx-bufid
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ npu@1e900000 {
+ compatible = "airoha,en7581-npu";
+ reg = <0 0x1e900000 0 0x313000>;
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ memory-region = <&npu_firmware>, <&npu_pkt>, <&npu_txpkt>,
+ <&npu_txbufid>;
+ memory-region-names = "firmware", "pkt", "tx-pkt", "tx-bufid";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/airoha,en8811h.yaml b/Documentation/devicetree/bindings/net/airoha,en8811h.yaml
new file mode 100644
index 000000000000..ecb5149ec6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/airoha,en8811h.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/airoha,en8811h.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN8811H PHY
+
+maintainers:
+ - Eric Woudstra <ericwouds@gmail.com>
+
+description:
+ The Airoha EN8811H PHY has the ability to reverse polarity
+ on the lines to and/or from the MAC. It is reversed by
+ the booleans in the devicetree node of the phy.
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id03a2.a411
+
+ reg:
+ maxItems: 1
+
+ airoha,pnswap-rx:
+ type: boolean
+ description:
+ Reverse rx polarity of the SERDES. This is the receiving
+ side of the lines from the MAC towards the EN881H.
+
+ airoha,pnswap-tx:
+ type: boolean
+ description:
+ Reverse tx polarity of SERDES. This is the transmitting
+ side of the lines from EN8811H towards the MAC.
+
+required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@1 {
+ compatible = "ethernet-phy-id03a2.a411";
+ reg = <1>;
+ airoha,pnswap-rx;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
index 098b2bf7d976..d4d8f3a7918e 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/net/allwinner,sun4i-a10-emac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 EMAC Ethernet Controller Device Tree Bindings
+title: Allwinner A10 EMAC Ethernet Controller
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -33,6 +33,15 @@ properties:
- items:
- description: phandle to SRAM
- description: register value for device
+ dmas:
+ items:
+ - description: RX DMA Channel
+ - description: TX DMA Channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml
index 767193ec1d32..85f552b907f3 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/net/allwinner,sun4i-a10-mdio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 MDIO Controller Device Tree Bindings
+title: Allwinner A10 MDIO Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
# Select every compatible, including the deprecated ones. This way, we
# will be able to report a warning when we have that compatible, since
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 703d0d886884..23e92be33ac8 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/net/allwinner,sun7i-a20-gmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A20 GMAC Device Tree Bindings
+title: Allwinner A20 GMAC
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 55fc620c72cd..323a669fa982 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -4,12 +4,27 @@
$id: http://devicetree.org/schemas/net/allwinner,sun8i-a83t-emac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83t EMAC Device Tree Bindings
+title: Allwinner A83t EMAC
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun8i-a83t-emac
+ - allwinner,sun8i-h3-emac
+ - allwinner,sun8i-r40-gmac
+ - allwinner,sun8i-v3s-emac
+ - allwinner,sun50i-a64-emac
+ - allwinner,sun55i-a523-gmac200
+ required:
+ - compatible
+
properties:
compatible:
oneOf:
@@ -21,9 +36,14 @@ properties:
- items:
- enum:
- allwinner,sun20i-d1-emac
+ - allwinner,sun50i-a100-emac
- allwinner,sun50i-h6-emac
- allwinner,sun50i-h616-emac0
+ - allwinner,sun55i-a523-gmac0
- const: allwinner,sun50i-a64-emac
+ - items:
+ - const: allwinner,sun55i-a523-gmac200
+ - const: snps,dwmac-4.20a
reg:
maxItems: 1
@@ -35,10 +55,20 @@ properties:
const: macirq
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
clock-names:
- const: stmmaceth
+ minItems: 1
+ items:
+ - const: stmmaceth
+ - const: mbus
+
+ phy-supply:
+ description: PHY regulator
+
+ power-domains:
+ maxItems: 1
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -60,7 +90,7 @@ required:
- syscon
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
- if:
properties:
compatible:
@@ -155,6 +185,8 @@ allOf:
patternProperties:
"^ethernet-phy@[0-9a-f]$":
type: object
+ $ref: ethernet-phy.yaml#
+ unevaluatedProperties: false
description:
Integrated PHY node
@@ -169,7 +201,6 @@ allOf:
- clocks
- resets
-
mdio@2:
$ref: mdio.yaml#
unevaluatedProperties: false
@@ -184,6 +215,41 @@ allOf:
- mdio-parent-bus
- mdio@1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: allwinner,sun55i-a523-gmac200
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ tx-internal-delay-ps:
+ default: 0
+ minimum: 0
+ maximum: 700
+ multipleOf: 100
+ description:
+ External RGMII PHY TX clock delay chain value in ps.
+ rx-internal-delay-ps:
+ default: 0
+ minimum: 0
+ maximum: 3100
+ multipleOf: 100
+ description:
+ External RGMII PHY TX clock delay chain value in ps.
+ required:
+ - power-domains
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ power-domains: false
+
unevaluatedProperties: false
examples:
@@ -316,4 +382,34 @@ examples:
};
};
+ - |
+ ethernet@4510000 {
+ compatible = "allwinner,sun55i-a523-gmac200",
+ "snps,dwmac-4.20a";
+ reg = <0x04510000 0x10000>;
+ clocks = <&ccu 117>, <&ccu 79>;
+ clock-names = "stmmaceth", "mbus";
+ resets = <&ccu 43>;
+ reset-names = "stmmaceth";
+ interrupts = <0 47 4>;
+ interrupt-names = "macirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins>;
+ power-domains = <&pck600 4>;
+ syscon = <&syscon>;
+ phy-handle = <&ext_rgmii_phy_1>;
+ phy-mode = "rgmii-id";
+ snps,fixed-burst;
+ snps,axi-config = <&gmac1_stmmac_axi_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ext_rgmii_phy_1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/net/altr,gmii-to-sgmii-2.0.yaml b/Documentation/devicetree/bindings/net/altr,gmii-to-sgmii-2.0.yaml
new file mode 100644
index 000000000000..aafb6447b6c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/altr,gmii-to-sgmii-2.0.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2025 Altera Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/altr,gmii-to-sgmii-2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera GMII to SGMII Converter
+
+maintainers:
+ - Matthew Gerlach <matthew.gerlach@altera.com>
+
+description:
+ This binding describes the Altera GMII to SGMII converter.
+
+properties:
+ compatible:
+ const: altr,gmii-to-sgmii-2.0
+
+ reg:
+ items:
+ - description: Registers for the emac splitter IP
+ - description: Registers for the GMII to SGMII converter.
+ - description: Registers for TSE control.
+
+ reg-names:
+ items:
+ - const: hps_emac_interface_splitter_avalon_slave
+ - const: gmii_to_sgmii_adapter_avalon_slave
+ - const: eth_tse_control_port
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ phy@ff000240 {
+ compatible = "altr,gmii-to-sgmii-2.0";
+ reg = <0xff000240 0x00000008>,
+ <0xff000200 0x00000040>,
+ <0xff000250 0x00000008>;
+ reg-names = "hps_emac_interface_splitter_avalon_slave",
+ "gmii_to_sgmii_adapter_avalon_slave",
+ "eth_tse_control_port";
+ };
diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
new file mode 100644
index 000000000000..fc445ad5a1f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/altr,socfpga-stmmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera SOCFPGA SoC DWMAC controller
+
+maintainers:
+ - Matthew Gerlach <matthew.gerlach@altera.com>
+
+description:
+ This binding describes the Altera SOCFPGA SoC implementation of the
+ Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, Agilex5 and Agilex7
+ families of chips.
+ # TODO: Determine how to handle the Arria10 reset-name, stmmaceth-ocp, that
+ # does not validate against net/snps,dwmac.yaml.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - altr,socfpga-stmmac
+ - altr,socfpga-stmmac-a10-s10
+ - altr,socfpga-stmmac-agilex5
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: altr,socfpga-stmmac
+ - const: snps,dwmac-3.70a
+ - const: snps,dwmac
+ - items:
+ - const: altr,socfpga-stmmac-a10-s10
+ - const: snps,dwmac-3.72a
+ - const: snps,dwmac
+ - items:
+ - const: altr,socfpga-stmmac-a10-s10
+ - const: snps,dwmac-3.74a
+ - const: snps,dwmac
+ - items:
+ - const: altr,socfpga-stmmac-agilex5
+ - const: snps,dwxgmac-2.10
+
+ clocks:
+ minItems: 1
+ items:
+ - description: GMAC main clock
+ - description:
+ PTP reference clock. This clock is used for programming the
+ Timestamp Addend Register. If not passed then the system
+ clock will be used and this is fine on some platforms.
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: stmmaceth
+ - const: ptp_ref
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: macirq
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ phy-mode:
+ enum:
+ - gmii
+ - mii
+ - rgmii
+ - rgmii-id
+ - rgmii-rxid
+ - rgmii-txid
+ - sgmii
+ - 1000base-x
+
+ rxc-skew-ps:
+ description: Skew control of RXC pad
+
+ rxd0-skew-ps:
+ description: Skew control of RX data 0 pad
+
+ rxd1-skew-ps:
+ description: Skew control of RX data 1 pad
+
+ rxd2-skew-ps:
+ description: Skew control of RX data 2 pad
+
+ rxd3-skew-ps:
+ description: Skew control of RX data 3 pad
+
+ rxdv-skew-ps:
+ description: Skew control of RX CTL pad
+
+ txc-skew-ps:
+ description: Skew control of TXC pad
+
+ txen-skew-ps:
+ description: Skew control of TXC pad
+
+ altr,emac-splitter:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Should be the phandle to the emac splitter soft IP node if DWMAC
+ controller is connected an emac splitter.
+
+ altr,f2h_ptp_ref_clk:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to Precision Time Protocol reference clock. This clock is
+ common to gmac instances and defaults to osc1.
+
+ altr,gmii-to-sgmii-converter:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Should be the phandle to the gmii to sgmii converter soft IP.
+
+ altr,sysmgr-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Should be the phandle to the system manager node that encompass
+ the glue register, the register offset, and the register shift.
+ On Cyclone5/Arria5, the register shift represents the PHY mode
+ bits, while on the Arria10/Stratix10/Agilex platforms, the
+ register shift represents bit for each emac to enable/disable
+ signals from the FPGA fabric to the EMAC modules.
+ items:
+ - items:
+ - description: phandle to the system manager node
+ - description: offset of the control register
+ - description: shift within the control register
+
+patternProperties:
+ "^mdio[0-9]$":
+ type: object
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - altr,sysmgr-syscon
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ethernet@ff700000 {
+ compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a",
+ "snps,dwmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60 0>;
+ reg = <0xff700000 0x2000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00]; /* Filled in by U-Boot */
+ clocks = <&emac_0_clk>;
+ clock-names = "stmmaceth";
+ phy-mode = "sgmii";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/altr,tse.yaml b/Documentation/devicetree/bindings/net/altr,tse.yaml
index 8d1d94494349..f5d3b70af07a 100644
--- a/Documentation/devicetree/bindings/net/altr,tse.yaml
+++ b/Documentation/devicetree/bindings/net/altr,tse.yaml
@@ -66,14 +66,14 @@ required:
- tx-fifo-depth
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
- if:
properties:
compatible:
contains:
enum:
- - const: altr,tse-1.0
- - const: ALTR,tse-1.0
+ - altr,tse-1.0
+ - ALTR,tse-1.0
then:
properties:
reg:
diff --git a/Documentation/devicetree/bindings/net/amd,xgbe-seattle-v1a.yaml b/Documentation/devicetree/bindings/net/amd,xgbe-seattle-v1a.yaml
new file mode 100644
index 000000000000..006add8b6410
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amd,xgbe-seattle-v1a.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/amd,xgbe-seattle-v1a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD XGBE Seattle v1a
+
+maintainers:
+ - Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
+
+allOf:
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+properties:
+ compatible:
+ const: amd,xgbe-seattle-v1a
+
+ reg:
+ items:
+ - description: MAC registers
+ - description: PCS registers
+ - description: SerDes Rx/Tx registers
+ - description: SerDes integration registers (1/2)
+ - description: SerDes integration registers (2/2)
+
+ interrupts:
+ description: Device interrupts. The first entry is the general device
+ interrupt. If amd,per-channel-interrupt is specified, each DMA channel
+ interrupt must be specified. The last entry is the PCS auto-negotiation
+ interrupt.
+ minItems: 2
+ maxItems: 6
+
+ clocks:
+ items:
+ - description: DMA clock for the device
+ - description: PTP clock for the device
+
+ clock-names:
+ items:
+ - const: dma_clk
+ - const: ptp_clk
+
+ iommus:
+ maxItems: 1
+
+ phy-mode: true
+
+ dma-coherent: true
+
+ amd,per-channel-interrupt:
+ description: Indicates that Rx and Tx complete will generate a unique
+ interrupt for each DMA channel.
+ type: boolean
+
+ amd,speed-set:
+ description: >
+ Speed capabilities of the device.
+ 0 = 1GbE and 10GbE
+ 1 = 2.5GbE and 10GbE
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ amd,serdes-blwc:
+ description: Baseline wandering correction enablement for each speed.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 3
+ items:
+ enum: [0, 1]
+
+ amd,serdes-cdr-rate:
+ description: CDR rate speed selection for each speed.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: CDR rate for 1GbE
+ - description: CDR rate for 2.5GbE
+ - description: CDR rate for 10GbE
+
+ amd,serdes-pq-skew:
+ description: PQ data sampling skew for each speed.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: PQ skew for 1GbE
+ - description: PQ skew for 2.5GbE
+ - description: PQ skew for 10GbE
+
+ amd,serdes-tx-amp:
+ description: TX amplitude boost for each speed.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: TX amplitude for 1GbE
+ - description: TX amplitude for 2.5GbE
+ - description: TX amplitude for 10GbE
+
+ amd,serdes-dfe-tap-config:
+ description: DFE taps available to run for each speed.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: DFE taps available for 1GbE
+ - description: DFE taps available for 2.5GbE
+ - description: DFE taps available for 10GbE
+
+ amd,serdes-dfe-tap-enable:
+ description: DFE taps to enable for each speed.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: DFE taps to enable for 1GbE
+ - description: DFE taps to enable for 2.5GbE
+ - description: DFE taps to enable for 10GbE
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - phy-mode
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@e0700000 {
+ compatible = "amd,xgbe-seattle-v1a";
+ reg = <0xe0700000 0x80000>,
+ <0xe0780000 0x80000>,
+ <0xe1240800 0x00400>,
+ <0xe1250000 0x00060>,
+ <0xe1250080 0x00004>;
+ interrupts = <0 325 4>,
+ <0 326 1>, <0 327 1>, <0 328 1>, <0 329 1>,
+ <0 323 4>;
+ amd,per-channel-interrupt;
+ clocks = <&xgbe_dma_clk>, <&xgbe_ptp_clk>;
+ clock-names = "dma_clk", "ptp_clk";
+ phy-mode = "xgmii";
+ mac-address = [ 02 a1 a2 a3 a4 a5 ];
+ amd,speed-set = <0>;
+ amd,serdes-blwc = <1>, <1>, <0>;
+ amd,serdes-cdr-rate = <2>, <2>, <7>;
+ amd,serdes-pq-skew = <10>, <10>, <30>;
+ amd,serdes-tx-amp = <15>, <15>, <10>;
+ amd,serdes-dfe-tap-config = <3>, <3>, <1>;
+ amd,serdes-dfe-tap-enable = <0>, <0>, <127>;
+ };
diff --git a/Documentation/devicetree/bindings/net/amd-xgbe.txt b/Documentation/devicetree/bindings/net/amd-xgbe.txt
deleted file mode 100644
index 9c27dfcd1133..000000000000
--- a/Documentation/devicetree/bindings/net/amd-xgbe.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-* AMD 10GbE driver (amd-xgbe)
-
-Required properties:
-- compatible: Should be "amd,xgbe-seattle-v1a"
-- reg: Address and length of the register sets for the device
- - MAC registers
- - PCS registers
- - SerDes Rx/Tx registers
- - SerDes integration registers (1/2)
- - SerDes integration registers (2/2)
-- interrupts: Should contain the amd-xgbe interrupt(s). The first interrupt
- listed is required and is the general device interrupt. If the optional
- amd,per-channel-interrupt property is specified, then one additional
- interrupt for each DMA channel supported by the device should be specified.
- The last interrupt listed should be the PCS auto-negotiation interrupt.
-- clocks:
- - DMA clock for the amd-xgbe device (used for calculating the
- correct Rx interrupt watchdog timer value on a DMA channel
- for coalescing)
- - PTP clock for the amd-xgbe device
-- clock-names: Should be the names of the clocks
- - "dma_clk" for the DMA clock
- - "ptp_clk" for the PTP clock
-- phy-mode: See ethernet.txt file in the same directory
-
-Optional properties:
-- dma-coherent: Present if dma operations are coherent
-- amd,per-channel-interrupt: Indicates that Rx and Tx complete will generate
- a unique interrupt for each DMA channel - this requires an additional
- interrupt be configured for each DMA channel
-- amd,speed-set: Speed capabilities of the device
- 0 - 1GbE and 10GbE (default)
- 1 - 2.5GbE and 10GbE
-
-The MAC address will be determined using the optional properties defined in
-ethernet.txt.
-
-The following optional properties are represented by an array with each
-value corresponding to a particular speed. The first array value represents
-the setting for the 1GbE speed, the second value for the 2.5GbE speed and
-the third value for the 10GbE speed. All three values are required if the
-property is used.
-- amd,serdes-blwc: Baseline wandering correction enablement
- 0 - Off
- 1 - On
-- amd,serdes-cdr-rate: CDR rate speed selection
-- amd,serdes-pq-skew: PQ (data sampling) skew
-- amd,serdes-tx-amp: TX amplitude boost
-- amd,serdes-dfe-tap-config: DFE taps available to run
-- amd,serdes-dfe-tap-enable: DFE taps to enable
-
-Example:
- xgbe@e0700000 {
- compatible = "amd,xgbe-seattle-v1a";
- reg = <0 0xe0700000 0 0x80000>,
- <0 0xe0780000 0 0x80000>,
- <0 0xe1240800 0 0x00400>,
- <0 0xe1250000 0 0x00060>,
- <0 0xe1250080 0 0x00004>;
- interrupt-parent = <&gic>;
- interrupts = <0 325 4>,
- <0 326 1>, <0 327 1>, <0 328 1>, <0 329 1>,
- <0 323 4>;
- amd,per-channel-interrupt;
- clocks = <&xgbe_dma_clk>, <&xgbe_ptp_clk>;
- clock-names = "dma_clk", "ptp_clk";
- phy-mode = "xgmii";
- mac-address = [ 02 a1 a2 a3 a4 a5 ];
- amd,speed-set = <0>;
- amd,serdes-blwc = <1>, <1>, <0>;
- amd,serdes-cdr-rate = <2>, <2>, <7>;
- amd,serdes-pq-skew = <10>, <10>, <30>;
- amd,serdes-tx-amp = <15>, <15>, <10>;
- amd,serdes-dfe-tap-config = <3>, <3>, <1>;
- amd,serdes-dfe-tap-enable = <0>, <0>, <127>;
- };
diff --git a/Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml b/Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml
new file mode 100644
index 000000000000..ec5c038ce6a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,g12a-mdio-mux.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/amlogic,g12a-mdio-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MDIO bus multiplexer/glue of Amlogic G12a SoC family
+
+description:
+ This is a special case of a MDIO bus multiplexer. It allows to choose between
+ the internal mdio bus leading to the embedded 10/100 PHY or the external
+ MDIO bus.
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: mdio-mux.yaml#
+
+properties:
+ compatible:
+ const: amlogic,g12a-mdio-mux
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: peripheral clock
+ - description: platform crytal
+ - description: SoC 50MHz MPLL
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: clkin0
+ - const: clkin1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mdio-multiplexer@4c000 {
+ compatible = "amlogic,g12a-mdio-mux";
+ reg = <0x4c000 0xa4>;
+ clocks = <&clkc_eth_phy>, <&xtal>, <&clkc_mpll>;
+ clock-names = "pclk", "clkin0", "clkin1";
+ mdio-parent-bus = <&mdio0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mdio@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@8 {
+ compatible = "ethernet-phy-id0180.3301",
+ "ethernet-phy-ieee802.3-c22";
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <8>;
+ max-speed = <100>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml b/Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml
new file mode 100644
index 000000000000..27ae004dbea0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,gxl-mdio-mux.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/amlogic,gxl-mdio-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic GXL MDIO bus multiplexer
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+description:
+ This is a special case of a MDIO bus multiplexer. It allows to choose between
+ the internal mdio bus leading to the embedded 10/100 PHY or the external
+ MDIO bus on the Amlogic GXL SoC family.
+
+allOf:
+ - $ref: mdio-mux.yaml#
+
+properties:
+ compatible:
+ const: amlogic,gxl-mdio-mux
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ eth_phy_mux: mdio@558 {
+ compatible = "amlogic,gxl-mdio-mux";
+ reg = <0x558 0xc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&refclk>;
+ clock-names = "ref";
+ mdio-parent-bus = <&mdio0>;
+
+ external_mdio: mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ internal_mdio: mdio@1 {
+ reg = <0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
index ddd5a073c3a8..5c91716d1f21 100644
--- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson DWMAC Ethernet controller
@@ -27,7 +27,7 @@ select:
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
- if:
properties:
compatible:
@@ -58,18 +58,18 @@ allOf:
- const: timing-adjustment
amlogic,tx-delay-ns:
- $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 2, 4, 6]
+ default: 2
description:
- The internal RGMII TX clock delay (provided by this driver) in
- nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX delay should be
- explicitly configured. When not configured a fallback of 2ns is
- used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
- the TX clock delay is already provided by the PHY. In that case
- this property should be set to 0ns (which disables the TX clock
- delay in the MAC to prevent the clock from going off because both
- PHY and MAC are adding a delay).
- Any configuration is ignored when the phy-mode is set to "rmii".
+ The internal RGMII TX clock delay (provided by this driver)
+ in nanoseconds. When phy-mode is set to "rgmii" then the TX
+ delay should be explicitly configured. When the phy-mode is
+ set to either "rgmii-id" or "rgmii-txid" the TX clock delay
+ is already provided by the PHY. In that case this property
+ should be set to 0ns (which disables the TX clock delay in
+ the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay). Any configuration is
+ ignored when the phy-mode is set to "rmii".
amlogic,rx-delay-ns:
deprecated: true
@@ -149,9 +149,15 @@ properties:
- description:
The first register range should be the one of the DWMAC controller
- description:
- The second range is is for the Amlogic specific configuration
+ The second range is for the Amlogic specific configuration
(for example the PRG_ETHERNET register range on Meson8b and newer)
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
required:
- compatible
- reg
@@ -166,11 +172,11 @@ unevaluatedProperties: false
examples:
- |
ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
- interrupts = <8>;
- interrupt-names = "macirq";
- clocks = <&clk_eth>, <&clk_fclk_div2>, <&clk_mpll2>, <&clk_fclk_div2>;
- clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment";
- phy-mode = "rgmii";
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clk_fclk_div2>, <&clk_mpll2>, <&clk_fclk_div2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment";
+ phy-mode = "rgmii";
};
diff --git a/Documentation/devicetree/bindings/net/apm,xgene-enet.yaml b/Documentation/devicetree/bindings/net/apm,xgene-enet.yaml
new file mode 100644
index 000000000000..1c767ef8fcc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm,xgene-enet.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/apm,xgene-enet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC Ethernet
+
+maintainers:
+ - Iyappan Subramanian <iyappan@os.amperecomputing.com>
+ - Keyur Chudgar <keyur@os.amperecomputing.com>
+ - Quan Nguyen <quan@os.amperecomputing.com>
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - apm,xgene-enet
+ - apm,xgene1-sgenet
+ - apm,xgene1-xgenet
+ - apm,xgene2-sgenet
+ - apm,xgene2-xgenet
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: enet_csr
+ - const: ring_csr
+ - const: ring_cmd
+
+ clocks:
+ maxItems: 1
+
+ dma-coherent: true
+
+ interrupts:
+ description: An rx and tx completion interrupt pair per queue
+ minItems: 1
+ maxItems: 16
+
+ channel:
+ description: Ethernet to CPU start channel number
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ port-id:
+ description: Port number
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 1
+
+ tx-delay:
+ description: Delay value for RGMII bridge TX clock
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 4
+
+ rx-delay:
+ description: Delay value for RGMII bridge RX clock
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 2
+
+ rxlos-gpios:
+ description: Input GPIO from SFP+ module indicating incoming signal
+ maxItems: 1
+
+ mdio:
+ description: MDIO bus subnode
+ $ref: mdio.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: apm,xgene-mdio
+
+ required:
+ - compatible
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@17020000 {
+ compatible = "apm,xgene-enet";
+ reg = <0x17020000 0xd100>,
+ <0x17030000 0x400>,
+ <0x10000000 0x200>;
+ reg-names = "enet_csr", "ring_csr", "ring_cmd";
+ interrupts = <0x0 0x3c 0x4>;
+ channel = <0>;
+ port-id = <0>;
+ clocks = <&menetclk 0>;
+ local-mac-address = [00 01 73 00 00 01];
+ phy-connection-type = "rgmii";
+ phy-handle = <&menetphy>;
+
+ mdio {
+ compatible = "apm,xgene-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ menetphy: ethernet-phy@3 {
+ compatible = "ethernet-phy-id001c.c915";
+ reg = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/apm,xgene-mdio-rgmii.yaml b/Documentation/devicetree/bindings/net/apm,xgene-mdio-rgmii.yaml
new file mode 100644
index 000000000000..470fb5f7f7b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm,xgene-mdio-rgmii.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/apm,xgene-mdio-rgmii.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC MDIO
+
+maintainers:
+ - Iyappan Subramanian <iyappan@os.amperecomputing.com>
+ - Keyur Chudgar <keyur@os.amperecomputing.com>
+ - Quan Nguyen <quan@os.amperecomputing.com>
+
+allOf:
+ - $ref: mdio.yaml#
+
+properties:
+ compatible:
+ enum:
+ - apm,xgene-mdio-rgmii
+ - apm,xgene-mdio-xfi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ mdio@17020000 {
+ compatible = "apm,xgene-mdio-rgmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x17020000 0xd100>;
+ clocks = <&menetclk 0>;
+
+ phy@3 {
+ reg = <0x3>;
+ };
+ phy@4 {
+ reg = <0x4>;
+ };
+ phy@5 {
+ reg = <0x5>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
deleted file mode 100644
index f591ab782dbc..000000000000
--- a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
+++ /dev/null
@@ -1,91 +0,0 @@
-APM X-Gene SoC Ethernet nodes
-
-Ethernet nodes are defined to describe on-chip ethernet interfaces in
-APM X-Gene SoC.
-
-Required properties for all the ethernet interfaces:
-- compatible: Should state binding information from the following list,
- - "apm,xgene-enet": RGMII based 1G interface
- - "apm,xgene1-sgenet": SGMII based 1G interface
- - "apm,xgene1-xgenet": XFI based 10G interface
-- reg: Address and length of the register set for the device. It contains the
- information of registers in the same order as described by reg-names
-- reg-names: Should contain the register set names
- - "enet_csr": Ethernet control and status register address space
- - "ring_csr": Descriptor ring control and status register address space
- - "ring_cmd": Descriptor ring command register address space
-- interrupts: Two interrupt specifiers can be specified.
- - First is the Rx interrupt. This irq is mandatory.
- - Second is the Tx completion interrupt.
- This is supported only on SGMII based 1GbE and 10GbE interfaces.
-- channel: Ethernet to CPU, start channel (prefetch buffer) number
- - Must map to the first irq and irqs must be sequential
-- port-id: Port number (0 or 1)
-- clocks: Reference to the clock entry.
-- local-mac-address: MAC address assigned to this device
-- phy-connection-type: Interface type between ethernet device and PHY device
-
-Required properties for ethernet interfaces that have external PHY:
-- phy-handle: Reference to a PHY node connected to this device
-
-- mdio: Device tree subnode with the following required properties:
- - compatible: Must be "apm,xgene-mdio".
- - #address-cells: Must be <1>.
- - #size-cells: Must be <0>.
-
- For the phy on the mdio bus, there must be a node with the following fields:
- - compatible: PHY identifier. Please refer ./phy.txt for the format.
- - reg: The ID number for the phy.
-
-Optional properties:
-- status: Should be "ok" or "disabled" for enabled/disabled. Default is "ok".
-- tx-delay: Delay value for RGMII bridge TX clock.
- Valid values are between 0 to 7, that maps to
- 417, 717, 1020, 1321, 1611, 1913, 2215, 2514 ps
- Default value is 4, which corresponds to 1611 ps
-- rx-delay: Delay value for RGMII bridge RX clock.
- Valid values are between 0 to 7, that maps to
- 273, 589, 899, 1222, 1480, 1806, 2147, 2464 ps
- Default value is 2, which corresponds to 899 ps
-- rxlos-gpios: Input gpio from SFP+ module to indicate availability of
- incoming signal.
-
-
-Example:
- menetclk: menetclk {
- compatible = "apm,xgene-device-clock";
- clock-output-names = "menetclk";
- status = "ok";
- };
-
- menet: ethernet@17020000 {
- compatible = "apm,xgene-enet";
- status = "disabled";
- reg = <0x0 0x17020000 0x0 0xd100>,
- <0x0 0x17030000 0x0 0x400>,
- <0x0 0x10000000 0x0 0x200>;
- reg-names = "enet_csr", "ring_csr", "ring_cmd";
- interrupts = <0x0 0x3c 0x4>;
- port-id = <0>;
- clocks = <&menetclk 0>;
- local-mac-address = [00 01 73 00 00 01];
- phy-connection-type = "rgmii";
- phy-handle = <&menetphy>;
- mdio {
- compatible = "apm,xgene-mdio";
- #address-cells = <1>;
- #size-cells = <0>;
- menetphy: menetphy@3 {
- compatible = "ethernet-phy-id001c.c915";
- reg = <0x3>;
- };
-
- };
- };
-
-/* Board-specific peripheral configurations */
-&menet {
- tx-delay = <4>;
- rx-delay = <2>;
- status = "ok";
-};
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-mdio.txt b/Documentation/devicetree/bindings/net/apm-xgene-mdio.txt
deleted file mode 100644
index 78722d74cea8..000000000000
--- a/Documentation/devicetree/bindings/net/apm-xgene-mdio.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-APM X-Gene SoC MDIO node
-
-MDIO node is defined to describe on-chip MDIO controller.
-
-Required properties:
- - compatible: Must be "apm,xgene-mdio-rgmii" or "apm,xgene-mdio-xfi"
- - #address-cells: Must be <1>.
- - #size-cells: Must be <0>.
- - reg: Address and length of the register set
- - clocks: Reference to the clock entry
-
-For the phys on the mdio bus, there must be a node with the following fields:
- - compatible: PHY identifier. Please refer ./phy.txt for the format.
- - reg: The ID number for the phy.
-
-Example:
-
- mdio: mdio@17020000 {
- compatible = "apm,xgene-mdio-rgmii";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0 0x17020000 0x0 0xd100>;
- clocks = <&menetclk 0>;
- };
-
- /* Board-specific peripheral configurations */
- &mdio {
- menetphy: phy@3 {
- reg = <0x3>;
- };
- sgenet0phy: phy@4 {
- reg = <0x4>;
- };
- sgenet1phy: phy@5 {
- reg = <0x5>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt
deleted file mode 100644
index c73a0e9c625e..000000000000
--- a/Documentation/devicetree/bindings/net/arc_emac.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
-
-Required properties:
-- compatible: Should be "snps,arc-emac"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the EMAC interrupts
-- max-speed: see ethernet.txt file in the same directory.
-- phy: see ethernet.txt file in the same directory.
-
-Optional properties:
-- phy-reset-gpios : Should specify the gpio for phy reset
-- phy-reset-duration : Reset duration in milliseconds. Should present
- only if property "phy-reset-gpios" is available. Missing the property
- will have the duration be 1 millisecond. Numbers greater than 1000 are
- invalid and 1 millisecond will be used instead.
-
-Clock handling:
-The clock frequency is needed to calculate and set polling period of EMAC.
-It must be provided by one of:
-- clock-frequency: CPU frequency.
-- clocks: reference to the clock supplying the EMAC.
-
-Child nodes of the driver are the individual PHY devices connected to the
-MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
-
-Examples:
-
- ethernet@c0fc2000 {
- compatible = "snps,arc-emac";
- reg = <0xc0fc2000 0x3c>;
- interrupts = <6>;
- mac-address = [ 00 11 22 33 44 55 ];
-
- clock-frequency = <80000000>;
- /* or */
- clocks = <&emac_clock>;
-
- max-speed = <100>;
- phy = <&phy0>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- phy0: ethernet-phy@0 {
- reg = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/asix,ax88178.yaml b/Documentation/devicetree/bindings/net/asix,ax88178.yaml
index 1af52358de4c..03341b7438d5 100644
--- a/Documentation/devicetree/bindings/net/asix,ax88178.yaml
+++ b/Documentation/devicetree/bindings/net/asix,ax88178.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/asix,ax88178.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: The device tree bindings for the USB Ethernet controllers
+title: ASIX AX88172/AX88772 USB Ethernet Controllers
maintainers:
- Oleksij Rempel <o.rempel@pengutronix.de>
@@ -27,7 +27,9 @@ properties:
- usbb95,772b # ASIX AX88772B
- usbb95,7e2b # ASIX AX88772B
- reg: true
+ reg:
+ maxItems: 1
+
local-mac-address: true
mac-address: true
@@ -61,8 +63,8 @@ examples:
#size-cells = <0>;
ethernet@1 {
- compatible = "usbb95,772b";
- reg = <1>;
+ compatible = "usbb95,772b";
+ reg = <1>;
};
};
};
diff --git a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
index 699ebf452479..6b849a4349c0 100644
--- a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
+++ b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml
@@ -19,6 +19,7 @@ description: |
allOf:
- $ref: ethernet-controller.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
properties:
compatible:
@@ -39,8 +40,8 @@ properties:
it should be marked GPIO_ACTIVE_LOW.
maxItems: 1
+ controller-data: true
local-mac-address: true
-
mac-address: true
required:
@@ -57,7 +58,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
index f81eda8cb0a5..a105dc07ed12 100644
--- a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
@@ -15,11 +15,16 @@ description: |+
MAC.
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
properties:
compatible:
- const: aspeed,ast2600-mdio
+ oneOf:
+ - const: aspeed,ast2600-mdio
+ - items:
+ - enum:
+ - aspeed,ast2700-mdio
+ - const: aspeed,ast2600-mdio
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/bluetooth.txt b/Documentation/devicetree/bindings/net/bluetooth.txt
deleted file mode 100644
index 94797df751b8..000000000000
--- a/Documentation/devicetree/bindings/net/bluetooth.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-The following properties are common to the Bluetooth controllers:
-
-- local-bd-address: array of 6 bytes, specifies the BD address that was
- uniquely assigned to the Bluetooth device, formatted with least significant
- byte first (little-endian).
diff --git a/Documentation/devicetree/bindings/net/bluetooth/amlogic,w155s2-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/amlogic,w155s2-bt.yaml
new file mode 100644
index 000000000000..6fd7557039d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/amlogic,w155s2-bt.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/amlogic,w155s2-bt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Bluetooth chips
+
+description:
+ The W155S2 is an Amlogic Bluetooth and Wi-Fi combo chip. It works on
+ the standard H4 protocol via a 4-wire UART interface, with baud rates
+ up to 4 Mbps.
+
+maintainers:
+ - Yang Li <yang.li@amlogic.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,w265s1-bt
+ - amlogic,w265p1-bt
+ - const: amlogic,w155s2-bt
+ - enum:
+ - amlogic,w155s2-bt
+ - amlogic,w265s2-bt
+
+ clocks:
+ maxItems: 1
+ description: clock provided to the controller (32.768KHz)
+
+ enable-gpios:
+ maxItems: 1
+
+ vddio-supply:
+ description: VDD_IO supply regulator handle
+
+ firmware-name:
+ maxItems: 1
+ description: specify the path of firmware bin to load
+
+required:
+ - compatible
+ - clocks
+ - enable-gpios
+ - vddio-supply
+ - firmware-name
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ bluetooth {
+ compatible = "amlogic,w155s2-bt";
+ clocks = <&extclk>;
+ enable-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ vddio-supply = <&wcn_3v3>;
+ firmware-name = "amlogic/aml_w155s2_bt_uart.bin";
+ };
+
diff --git a/Documentation/devicetree/bindings/net/bluetooth/bluetooth-controller.yaml b/Documentation/devicetree/bindings/net/bluetooth/bluetooth-controller.yaml
new file mode 100644
index 000000000000..59bb0d7e8ab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/bluetooth-controller.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/bluetooth-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bluetooth Controller Common Properties
+
+maintainers:
+ - Marcel Holtmann <marcel@holtmann.org>
+ - Johan Hedberg <johan.hedberg@gmail.com>
+ - Luiz Augusto von Dentz <luiz.dentz@gmail.com>
+
+properties:
+ $nodename:
+ pattern: "^bluetooth(@.*)?$"
+
+ local-bd-address:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ maxItems: 6
+ description:
+ Specifies the BD address that was uniquely assigned to the Bluetooth
+ device. Formatted with least significant byte first (little-endian), e.g.
+ in order to assign the address 00:11:22:33:44:55 this property must have
+ the value [55 44 33 22 11 00].
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
new file mode 100644
index 000000000000..fd78258d71b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/brcm,bcm4377-bluetooth.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/brcm,bcm4377-bluetooth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM4377 family PCIe Bluetooth Chips
+
+maintainers:
+ - Sven Peter <sven@svenpeter.dev>
+
+description:
+ This binding describes Broadcom BCM4377 family PCIe-attached bluetooth chips
+ usually found in Apple machines. The Wi-Fi part of the chip is described in
+ bindings/net/wireless/brcm,bcm4329-fmac.yaml.
+
+allOf:
+ - $ref: bluetooth-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - pci14e4,5fa0 # BCM4377
+ - pci14e4,5f69 # BCM4378
+ - pci14e4,5f71 # BCM4387
+ - pci14e4,5f72 # BCM4388
+
+ reg:
+ maxItems: 1
+
+ brcm,board-type:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Board type of the Bluetooth chip. This is used to decouple
+ the overall system board from the Bluetooth module and used to construct
+ firmware and calibration data filenames.
+ On Apple platforms, this should be the Apple module-instance codename
+ prefixed by "apple,", e.g. "apple,atlantisb".
+ pattern: '^apple,.*'
+
+ brcm,taurus-cal-blob:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: A per-device calibration blob for the Bluetooth radio. This
+ should be filled in by the bootloader from platform configuration
+ data, if necessary, and will be uploaded to the device.
+ This blob is used if the chip stepping of the Bluetooth module does not
+ support beamforming.
+
+ brcm,taurus-bf-cal-blob:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: A per-device calibration blob for the Bluetooth radio. This
+ should be filled in by the bootloader from platform configuration
+ data, if necessary, and will be uploaded to the device.
+ This blob is used if the chip stepping of the Bluetooth module supports
+ beamforming.
+
+ local-bd-address: true
+
+required:
+ - compatible
+ - reg
+ - local-bd-address
+ - brcm,board-type
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie@a0000000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0xa0000000 0x1000000>;
+ device_type = "pci";
+ ranges = <0x43000000 0x6 0xa0000000 0xa0000000 0x0 0x20000000>;
+
+ bluetooth@0,1 {
+ compatible = "pci14e4,5f69";
+ reg = <0x100 0x0 0x0 0x0 0x0>;
+ brcm,board-type = "apple,honshu";
+ /* To be filled by the bootloader */
+ local-bd-address = [00 00 00 00 00 00];
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/brcm,bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/brcm,bluetooth.yaml
new file mode 100644
index 000000000000..3c410cadff23
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/brcm,bluetooth.yaml
@@ -0,0 +1,163 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/brcm,bluetooth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Bluetooth Chips
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ This binding describes Broadcom UART-attached bluetooth chips.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - infineon,cyw43439-bt
+ - const: brcm,bcm4329-bt
+ - enum:
+ - brcm,bcm20702a1
+ - brcm,bcm4329-bt
+ - brcm,bcm4330-bt
+ - brcm,bcm4334-bt
+ - brcm,bcm43430a0-bt
+ - brcm,bcm43430a1-bt
+ - brcm,bcm43438-bt
+ - brcm,bcm4345c5
+ - brcm,bcm43540-bt
+ - brcm,bcm4335a0
+ - brcm,bcm4349-bt
+ - cypress,cyw4373a0-bt
+ - infineon,cyw55572-bt
+
+ shutdown-gpios:
+ maxItems: 1
+ description: GPIO specifier for the line BT_REG_ON used to
+ power on the BT module
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO specifier for the line BT_RST_N used to
+ reset the BT module. This should be marked as
+ GPIO_ACTIVE_LOW.
+
+ device-wakeup-gpios:
+ maxItems: 1
+ description: GPIO specifier for the line BT_WAKE used to
+ wakeup the controller. This is using the BT_GPIO_0
+ pin on the chip when in use.
+
+ host-wakeup-gpios:
+ maxItems: 1
+ deprecated: true
+ description: GPIO specifier for the line HOST_WAKE used
+ to wakeup the host processor. This is using he BT_GPIO_1
+ pin on the chip when in use. This is deprecated and replaced
+ by interrupts and "host-wakeup" interrupt-names
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+ description: 1 or 2 clocks as defined in clock-names below,
+ in that order
+
+ clock-names:
+ description: Names of the 1 to 2 supplied clocks
+ oneOf:
+ - const: extclk
+ deprecated: true
+ description: Deprecated in favor of txco
+
+ - const: txco
+ description: >
+ external reference clock (not a standalone crystal)
+
+ - const: lpo
+ description: >
+ external low power 32.768 kHz clock
+
+ - items:
+ - const: txco
+ - const: lpo
+
+ vbat-supply:
+ description: phandle to regulator supply for VBAT
+
+ vddio-supply:
+ description: phandle to regulator supply for VDDIO
+
+ brcm,bt-pcm-int-params:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 5
+ maxItems: 5
+ description: |-
+ configure PCM parameters via a 5-byte array:
+ sco-routing: 0 = PCM, 1 = Transport, 2 = Codec, 3 = I2S
+ pcm-interface-rate: 128KBps, 256KBps, 512KBps, 1024KBps, 2048KBps
+ pcm-frame-type: short, long
+ pcm-sync-mode: slave, master
+ pcm-clock-mode: slave, master
+
+ brcm,requires-autobaud-mode:
+ type: boolean
+ description:
+ Set this property if autobaud mode is required. Autobaud mode is required
+ if the device's initial baud rate in normal mode is not supported by the
+ host or if the device requires autobaud mode startup before loading FW.
+
+ interrupts:
+ items:
+ - description: Handle to the line HOST_WAKE used to wake
+ up the host processor. This uses the BT_GPIO_1 pin on
+ the chip when in use.
+
+ interrupt-names:
+ items:
+ - const: host-wakeup
+
+required:
+ - compatible
+
+dependencies:
+ brcm,requires-autobaud-mode: [ shutdown-gpios ]
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm20702a1
+ - brcm,bcm4329-bt
+ - brcm,bcm4330-bt
+ then:
+ properties:
+ reset-gpios: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ uart {
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ max-speed = <921600>;
+ brcm,bt-pcm-int-params = [01 02 00 01 01];
+ shutdown-gpios = <&gpio 30 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 9 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio>;
+ interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/marvell,88w8897.yaml b/Documentation/devicetree/bindings/net/bluetooth/marvell,88w8897.yaml
new file mode 100644
index 000000000000..2fc36874deb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/marvell,88w8897.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/marvell,88w8897.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Bluetooth chips
+
+description: |
+ This documents the binding structure and common properties for serial
+ attached Marvell Bluetooth devices.
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - mrvl,88w8897
+ - mrvl,88w8997
+
+ max-speed: true
+
+required:
+ - compatible
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mrvl,88w8997
+ then:
+ properties:
+ max-speed: true
+ else:
+ properties:
+ max-speed: false
+
+additionalProperties: false
+
+examples:
+ - |
+ serial {
+ bluetooth {
+ compatible = "mrvl,88w8897";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/marvell,sd8897-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/marvell,sd8897-bt.yaml
new file mode 100644
index 000000000000..a307c64cfa4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/marvell,sd8897-bt.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/marvell,sd8897-bt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO)
+
+maintainers:
+ - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
+
+allOf:
+ - $ref: /schemas/net/bluetooth/bluetooth-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,sd8897-bt
+ - marvell,sd8997-bt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ marvell,cal-data:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Calibration data downloaded to the device during initialization.
+ maxItems: 28
+
+ marvell,wakeup-pin:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Wakeup pin number of the bluetooth chip. Used by firmware to wakeup host
+ system.
+
+ marvell,wakeup-gap-ms:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description:
+ Wakeup latency of the host platform. Required by the chip sleep feature.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mmc {
+ vmmc-supply = <&wlan_en_reg>;
+ bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bluetooth@2 {
+ compatible = "marvell,sd8897-bt";
+ reg = <2>;
+ interrupt-parent = <&pio>;
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+
+ marvell,cal-data = /bits/ 8 <
+ 0x37 0x01 0x1c 0x00 0xff 0xff 0xff 0xff 0x01 0x7f 0x04 0x02
+ 0x00 0x00 0xba 0xce 0xc0 0xc6 0x2d 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0xf0 0x00>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/bluetooth/mediatek,bluetooth.txt b/Documentation/devicetree/bindings/net/bluetooth/mediatek,bluetooth.txt
new file mode 100644
index 000000000000..988c72685cbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/mediatek,bluetooth.txt
@@ -0,0 +1,80 @@
+MediaTek UART based Bluetooth Devices
+==================================
+
+This device is a serial attached device to UART device and thus it must be a
+child node of the serial node with UART.
+
+Please refer to the following documents for generic properties:
+
+ Documentation/devicetree/bindings/serial/serial.yaml
+
+Required properties:
+
+- compatible: Must be
+ "mediatek,mt7663u-bluetooth": for MT7663U device
+ "mediatek,mt7668u-bluetooth": for MT7668U device
+- vcc-supply: Main voltage regulator
+
+If the pin controller on the platform can support both pinmux and GPIO
+control such as the most of MediaTek platform. Please use below properties.
+
+- pinctrl-names: Should be "default", "runtime"
+- pinctrl-0: Should contain UART RXD low when the device is powered up to
+ enter proper bootstrap mode.
+- pinctrl-1: Should contain UART mode pin ctrl
+
+Else, the pin controller on the platform only can support pinmux control and
+the GPIO control still has to rely on the dedicated GPIO controller such as
+a legacy MediaTek SoC, MT7621. Please use the below properties.
+
+- boot-gpios: GPIO same to the pin as UART RXD and used to keep LOW when
+ the device is powered up to enter proper bootstrap mode when
+- pinctrl-names: Should be "default"
+- pinctrl-0: Should contain UART mode pin ctrl
+
+Optional properties:
+
+- reset-gpios: GPIO used to reset the device whose initial state keeps low,
+ if the GPIO is missing, then board-level design should be
+ guaranteed.
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property. If the clock is missing, then board-level
+ design should be guaranteed.
+- clock-names: Should contain "osc" entry for the external oscillator.
+- current-speed: Current baud rate of the device whose defaults to 921600
+
+Example:
+
+ uart1_pins_boot: uart1-default {
+ pins-dat {
+ pinmux = <MT7623_PIN_81_URXD1_FUNC_GPIO81>;
+ output-low;
+ };
+ };
+
+ uart1_pins_runtime: uart1-runtime {
+ pins-dat {
+ pinmux = <MT7623_PIN_81_URXD1_FUNC_URXD1>,
+ <MT7623_PIN_82_UTXD1_FUNC_UTXD1>;
+ };
+ };
+
+ uart1: serial@11003000 {
+ compatible = "mediatek,mt7623-uart",
+ "mediatek,mt6577-uart";
+ reg = <0 0x11003000 0 0x400>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_UART1_SEL>,
+ <&pericfg CLK_PERI_UART1>;
+ clock-names = "baud", "bus";
+
+ bluetooth {
+ compatible = "mediatek,mt7663u-bluetooth";
+ vcc-supply = <&reg_5v>;
+ reset-gpios = <&pio 24 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default", "runtime";
+ pinctrl-0 = <&uart1_pins_boot>;
+ pinctrl-1 = <&uart1_pins_runtime>;
+ current-speed = <921600>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml
new file mode 100644
index 000000000000..3f9e69208127
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/mediatek,mt7622-bluetooth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SoC built-in Bluetooth
+
+description:
+ This device is a serial attached device to BTIF device and thus it must be a
+ child node of the serial node with BTIF. The dt-bindings details for BTIF
+ device can be known via Documentation/devicetree/bindings/serial/8250.yaml.
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+allOf:
+ - $ref: bluetooth-controller.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt7622-bluetooth
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ref
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/mt7622-power.h>
+
+ serial {
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
+ clocks = <&clk25m>;
+ clock-names = "ref";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml
new file mode 100644
index 000000000000..67ff7caad599
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7921s-bluetooth.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/mediatek,mt7921s-bluetooth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7921S Bluetooth
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+description:
+ MT7921S is an SDIO-attached dual-radio WiFi+Bluetooth Combo chip; each
+ function is its own SDIO function on a shared SDIO interface. The chip
+ has two dedicated reset lines, one for each function core.
+ This binding only covers the Bluetooth SDIO function, with one device
+ node describing only this SDIO function.
+
+allOf:
+ - $ref: bluetooth-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7921s-bluetooth
+
+ reg:
+ const: 2
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ An active-low reset line for the Bluetooth core; on typical M.2
+ key E modules this is the W_DISABLE2# pin.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ mmc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bluetooth@2 {
+ compatible = "mediatek,mt7921s-bluetooth";
+ reg = <2>;
+ reset-gpios = <&pio 8 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/nokia-bluetooth.txt b/Documentation/devicetree/bindings/net/bluetooth/nokia,h4p-bluetooth.txt
index 42be7dc9a70b..42be7dc9a70b 100644
--- a/Documentation/devicetree/bindings/net/nokia-bluetooth.txt
+++ b/Documentation/devicetree/bindings/net/bluetooth/nokia,h4p-bluetooth.txt
diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
new file mode 100644
index 000000000000..857c6234ba9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/nxp,88w8987-bt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Bluetooth chips
+
+description:
+ This binding describes UART-attached NXP bluetooth chips. These chips
+ are dual-radio chips supporting WiFi and Bluetooth. The bluetooth
+ works on standard H4 protocol over 4-wire UART. The RTS and CTS lines
+ are used during FW download. To enable power save mode, the host
+ asserts break signal over UART-TX line to put the chip into power save
+ state. De-asserting break wakes up the BT chip.
+
+maintainers:
+ - Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
+
+allOf:
+ - $ref: bluetooth-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nxp,88w8987-bt
+ - nxp,88w8997-bt
+
+ fw-init-baudrate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 115200
+ description:
+ Chip baudrate after FW is downloaded and initialized.
+ This property depends on the module vendor's
+ configuration.
+
+ max-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 3000000
+ - 4000000
+ default: 3000000
+
+ firmware-name:
+ maxItems: 1
+
+ device-wakeup-gpios:
+ maxItems: 1
+ description:
+ Host-To-Chip power save mechanism is driven by this GPIO
+ connected to BT_WAKE_IN pin of the NXP chipset.
+
+ nxp,wakein-pin:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description:
+ The GPIO number of the NXP chipset used for BT_WAKE_IN.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Host wakeup by falling edge interrupt on this pin which is
+ connected to BT_WAKE_OUT pin of the NXP chipset.
+
+ interrupt-names:
+ items:
+ - const: wakeup
+
+ wakeup-source: true
+
+ nxp,wakeout-pin:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description:
+ The GPIO number of the NXP chipset used for BT_WAKE_OUT.
+
+ vcc-supply:
+ description:
+ phandle of the regulator that provides the supply voltage.
+
+ reset-gpios:
+ description:
+ Chip powerdown/reset signal (PDn).
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ serial {
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ fw-init-baudrate = <3000000>;
+ max-speed = <4000000>;
+ firmware-name = "uartuart8987_bt_v0.bin";
+ device-wakeup-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
+ nxp,wakein-pin = /bits/ 8 <18>;
+ nxp,wakeout-pin = /bits/ 8 <19>;
+ vcc-supply = <&nxp_iw612_supply>;
+ reset-gpios = <&gpioctrl 2 GPIO_ACTIVE_LOW>;
+ local-bd-address = [66 55 44 33 22 11];
+ interrupt-parent = <&gpio>;
+ interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-names = "wakeup";
+ wakeup-source;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
new file mode 100644
index 000000000000..6353a336f382
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml
@@ -0,0 +1,259 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/qualcomm-bluetooth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Bluetooth Chips
+
+maintainers:
+ - Balakrishna Godavarthi <quic_bgodavar@quicinc.com>
+ - Rocky Liao <quic_rjliao@quicinc.com>
+
+description:
+ This binding describes Qualcomm UART-attached bluetooth chips.
+
+properties:
+ compatible:
+ enum:
+ - qcom,qca2066-bt
+ - qcom,qca6174-bt
+ - qcom,qca9377-bt
+ - qcom,wcn3950-bt
+ - qcom,wcn3988-bt
+ - qcom,wcn3990-bt
+ - qcom,wcn3991-bt
+ - qcom,wcn3998-bt
+ - qcom,qca6390-bt
+ - qcom,wcn6750-bt
+ - qcom,wcn6855-bt
+ - qcom,wcn7850-bt
+
+ enable-gpios:
+ maxItems: 1
+ description: gpio specifier used to enable chip
+
+ swctrl-gpios:
+ maxItems: 1
+ description: gpio specifier is used to find status
+ of clock supply to SoC
+
+ clocks:
+ maxItems: 1
+ description: clock provided to the controller (SUSCLK_32KHZ)
+
+ vddio-supply:
+ description: VDD_IO supply regulator handle
+
+ vddxo-supply:
+ description: VDD_XO supply regulator handle
+
+ vddrf-supply:
+ description: VDD_RF supply regulator handle
+
+ vddch0-supply:
+ description: VDD_CH0 supply regulator handle
+
+ vddch1-supply:
+ description: VDD_CH1 supply regulator handle
+
+ vddaon-supply:
+ description: VDD_AON supply regulator handle
+
+ vdddig-supply:
+ description: VDD_DIG supply regulator handle
+
+ vddbtcmx-supply:
+ description: VDD_BT_CMX supply regulator handle
+
+ vddbtcxmx-supply:
+ description: VDD_BT_CXMX supply regulator handle
+
+ vddrfacmn-supply:
+ description: VDD_RFA_CMN supply regulator handle
+
+ vddrfa0p8-supply:
+ description: VDD_RFA_0P8 supply regulator handle
+
+ vddrfa1p7-supply:
+ description: VDD_RFA_1P7 supply regulator handle
+
+ vddrfa1p8-supply:
+ description: VDD_RFA_1P8 supply regulator handle
+
+ vddrfa1p2-supply:
+ description: VDD_RFA_1P2 supply regulator handle
+
+ vddrfa1p9-supply:
+ description: VDD_RFA_1P9 supply regulator handle
+
+ vddrfa2p2-supply:
+ description: VDD_RFA_2P2 supply regulator handle
+
+ vddasd-supply:
+ description: VDD_ASD supply regulator handle
+
+ vddwlcx-supply:
+ description: VDD_WLCX supply regulator handle
+
+ vddwlmx-supply:
+ description: VDD_WLMX supply regulator handle
+
+ max-speed: true
+
+ firmware-name:
+ minItems: 1
+ items:
+ - description: specify the name of nvm firmware to load
+ - description: specify the name of rampatch firmware to load
+
+ local-bd-address: true
+
+ qcom,local-bd-address-broken:
+ type: boolean
+ description:
+ boot firmware is incorrectly passing the address in big-endian order
+
+required:
+ - compatible
+
+additionalProperties: false
+
+allOf:
+ - $ref: bluetooth-controller.yaml#
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qca2066-bt
+ - qcom,qca6174-bt
+ then:
+ required:
+ - enable-gpios
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,wcn3950-bt
+ - qcom,wcn3988-bt
+ - qcom,wcn3990-bt
+ - qcom,wcn3991-bt
+ - qcom,wcn3998-bt
+ then:
+ required:
+ - vddio-supply
+ - vddxo-supply
+ - vddrf-supply
+ - vddch0-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,wcn6750-bt
+ then:
+ required:
+ - vddaon-supply
+ - vddrfacmn-supply
+ - vddrfa0p8-supply
+ - vddrfa1p7-supply
+ - vddrfa1p2-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,wcn6855-bt
+ then:
+ required:
+ - vddrfacmn-supply
+ - vddaon-supply
+ - vddwlcx-supply
+ - vddwlmx-supply
+ - vddbtcmx-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p8-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,wcn7850-bt
+ then:
+ required:
+ - vddrfacmn-supply
+ - vddaon-supply
+ - vddwlcx-supply
+ - vddwlmx-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p8-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qca6390-bt
+ then:
+ required:
+ - vddrfacmn-supply
+ - vddaon-supply
+ - vddbtcmx-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p7-supply
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ serial {
+
+ bluetooth {
+ compatible = "qcom,qca6174-bt";
+ enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
+ clocks = <&divclk4>;
+ firmware-name = "nvm_00440302.bin";
+ };
+ };
+ - |
+ serial {
+
+ bluetooth {
+ compatible = "qcom,wcn3990-bt";
+ vddio-supply = <&vreg_s4a_1p8>;
+ vddxo-supply = <&vreg_l7a_1p8>;
+ vddrf-supply = <&vreg_l17a_1p3>;
+ vddch0-supply = <&vreg_l25a_3p3>;
+ max-speed = <3200000>;
+ firmware-name = "crnv21.bin";
+ };
+ };
+ - |
+ serial {
+
+ bluetooth {
+ compatible = "qcom,wcn6750-bt";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_en_default>;
+ enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>;
+ vddio-supply = <&vreg_l19b_1p8>;
+ vddaon-supply = <&vreg_s7b_0p9>;
+ vddbtcxmx-supply = <&vreg_s7b_0p9>;
+ vddrfacmn-supply = <&vreg_s7b_0p9>;
+ vddrfa0p8-supply = <&vreg_s7b_0p9>;
+ vddrfa1p7-supply = <&vreg_s1b_1p8>;
+ vddrfa1p2-supply = <&vreg_s8b_1p2>;
+ vddrfa2p2-supply = <&vreg_s1c_2p2>;
+ vddasd-supply = <&vreg_l11c_2p8>;
+ max-speed = <3200000>;
+ firmware-name = "msnv11.bin";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/bluetooth/realtek,bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/realtek,bluetooth.yaml
new file mode 100644
index 000000000000..7d567122bac9
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/realtek,bluetooth.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/realtek,bluetooth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RTL8723BS/RTL8723CS/RTL8821CS/RTL8822CS Bluetooth
+
+maintainers:
+ - Vasily Khoruzhick <anarsoul@gmail.com>
+ - Alistair Francis <alistair@alistair23.me>
+
+description:
+ RTL8723BS/RTL8723CS/RTL8821CS/RTL8822CS is a WiFi + BT chip. WiFi part
+ is connected over SDIO, while BT is connected over serial. It speaks
+ H5 protocol with few extra commands to upload firmware and change
+ module speed.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - realtek,rtl8723bs-bt
+ - realtek,rtl8723cs-bt
+ - realtek,rtl8723ds-bt
+ - realtek,rtl8822cs-bt
+ - items:
+ - enum:
+ - realtek,rtl8821cs-bt
+ - const: realtek,rtl8723bs-bt
+
+ device-wake-gpios:
+ maxItems: 1
+ description: GPIO specifier, used to wakeup the BT module
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO specifier, used to enable the BT module
+
+ host-wake-gpios:
+ maxItems: 1
+ description: GPIO specifier, used to wakeup the host processor
+
+ max-speed: true
+
+required:
+ - compatible
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "realtek,rtl8723bs-bt";
+ device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
+ host-wake-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/ti,bluetooth.yaml
index 81616f9fb493..290abc22e18a 100644
--- a/Documentation/devicetree/bindings/net/ti,bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/ti,bluetooth.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/net/ti,bluetooth.yaml#
+$id: http://devicetree.org/schemas/net/bluetooth/ti,bluetooth.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments Bluetooth Chips
@@ -74,6 +74,9 @@ properties:
required:
- compatible
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/net/brcm,amac.yaml b/Documentation/devicetree/bindings/net/brcm,amac.yaml
index 8f031932c8af..210fb29c4e7b 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,amac.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/net/brcm,amac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom AMAC Ethernet Controller Device Tree Bindings
+title: Broadcom AMAC Ethernet Controller
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
new file mode 100644
index 000000000000..a3db6d594c8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom ASP Ethernet controller
+
+maintainers:
+ - Justin Chen <justin.chen@broadcom.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+description: Broadcom Ethernet controller first introduced with 72165
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - brcm,bcm74110-asp
+ - const: brcm,asp-v3.0
+ - items:
+ - enum:
+ - brcm,bcm74165b0-asp
+ - const: brcm,asp-v2.2
+ - items:
+ - enum:
+ - brcm,bcm74165-asp
+ - const: brcm,asp-v2.1
+
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ interrupts:
+ items:
+ - description: RX/TX interrupt
+ - description: Wake-on-LAN interrupt
+
+ clocks:
+ maxItems: 1
+
+ ethernet-ports:
+ type: object
+ properties:
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^port@[0-9a-f]+$":
+ type: object
+
+ $ref: ethernet-controller.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+ description: Port number
+
+ brcm,channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ ASP Channel Number
+
+ The depacketizer channel that consumes packets from
+ the unimac/port.
+
+ required:
+ - reg
+ - brcm,channel
+
+ additionalProperties: false
+
+patternProperties:
+ "^mdio@[0-9a-f]+$":
+ type: object
+ $ref: brcm,unimac-mdio.yaml
+
+ description:
+ ASP internal UniMAC MDIO bus
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@9c00000 {
+ compatible = "brcm,bcm74165-asp", "brcm,asp-v2.1";
+ reg = <0x9c00000 0x1fff14>;
+ interrupts-extended = <&intc GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+ <&aon_pm_l2_intc 14>;
+ ranges = <0x0 0x9c00000 0x1fff14>;
+ clocks = <&scmi 14>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mdio@c614 {
+ compatible = "brcm,asp-v2.1-mdio";
+ reg = <0xc614 0x8>;
+ reg-names = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+
+ mdio@ce14 {
+ compatible = "brcm,asp-v2.1-mdio";
+ reg = <0xce14 0x8>;
+ reg-names = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ brcm,channel = <8>;
+ phy-mode = "rgmii";
+ phy-handle = <&phy0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ brcm,channel = <9>;
+ phy-mode = "rgmii";
+ phy-handle = <&phy1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt b/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt
deleted file mode 100644
index d0935d2afef8..000000000000
--- a/Documentation/devicetree/bindings/net/brcm,bcm7445-switch-v4.0.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Broadcom Starfighter 2 integrated swich
-
-See dsa/brcm,bcm7445-switch-v4.0.yaml for the documentation.
-
-*Deprecated* binding required properties:
-
-- dsa,mii-bus: phandle to the MDIO bus controller, see dsa/dsa.txt
-- dsa,ethernet: phandle to the CPU network interface controller, see dsa/dsa.txt
-- #address-cells: must be 2, see dsa/dsa.txt
-
-Example using the old DSA DeviceTree binding:
-
-switch_top@f0b00000 {
- compatible = "simple-bus";
- #size-cells = <1>;
- #address-cells = <1>;
- ranges = <0 0xf0b00000 0x40804>;
-
- ethernet_switch@0 {
- compatible = "brcm,bcm7445-switch-v4.0";
- #size-cells = <0>;
- #address-cells = <2>;
- reg = <0x0 0x40000
- 0x40000 0x110
- 0x40340 0x30
- 0x40380 0x30
- 0x40400 0x34
- 0x40600 0x208>;
- interrupts = <0 0x18 0
- 0 0x19 0>;
- brcm,num-gphy = <1>;
- brcm,num-rgmii-ports = <2>;
- brcm,fcb-pause-override;
- brcm,acb-packets-inflight;
-
- ...
- switch@0 {
- reg = <0 0>;
- #size-cells = <0>;
- #address-cells = <1>;
-
- port@0 {
- label = "gphy";
- reg = <0>;
- brcm,use-bcm-hdr;
- };
- ...
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml
index e5af53508e25..a1119c47e29b 100644
--- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/brcm,bcmgenet.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM7xxx Ethernet Controller (GENET) binding
+title: Broadcom BCM7xxx Ethernet Controller (GENET)
maintainers:
- Doug Berger <opendmb@gmail.com>
@@ -31,7 +31,6 @@ properties:
- description: RX and TX rings interrupt line
- description: Wake-on-LAN interrupt line
-
clocks:
minItems: 1
items:
@@ -55,7 +54,7 @@ properties:
patternProperties:
"^mdio@[0-9a-f]+$":
type: object
- $ref: "brcm,unimac-mdio.yaml"
+ $ref: brcm,unimac-mdio.yaml
description:
GENET internal UniMAC MDIO bus
@@ -73,8 +72,6 @@ allOf:
unevaluatedProperties: false
examples:
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- |
ethernet@f0b60000 {
phy-mode = "internal";
@@ -87,16 +84,16 @@ examples:
#size-cells = <1>;
mdio0: mdio@e14 {
- compatible = "brcm,genet-mdio-v4";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xe14 0x8>;
+ compatible = "brcm,genet-mdio-v4";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xe14 0x8>;
- phy1: ethernet-phy@1 {
+ phy1: ethernet-phy@1 {
max-speed = <1000>;
reg = <1>;
compatible = "ethernet-phy-ieee802.3-c22";
- };
+ };
};
};
@@ -112,10 +109,10 @@ examples:
interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>;
mdio1: mdio@e14 {
- compatible = "brcm,genet-mdio-v4";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xe14 0x8>;
+ compatible = "brcm,genet-mdio-v4";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xe14 0x8>;
};
};
@@ -131,15 +128,15 @@ examples:
interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>;
mdio2: mdio@e14 {
- compatible = "brcm,genet-mdio-v4";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xe14 0x8>;
+ compatible = "brcm,genet-mdio-v4";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xe14 0x8>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@0 {
max-speed = <1000>;
reg = <0>;
compatible = "ethernet-phy-ieee802.3-c22";
- };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml
index af96b4fd89d5..d544f785e6b9 100644
--- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml
@@ -29,7 +29,6 @@ properties:
maxItems: 1
description: core clock driving the MDIO block
-
required:
- compatible
- reg
@@ -38,43 +37,43 @@ unevaluatedProperties: false
examples:
- |
- mdio_mux_iproc: mdio-mux@66020000 {
+ mdio-mux@66020000 {
compatible = "brcm,mdio-mux-iproc";
reg = <0x66020000 0x250>;
#address-cells = <1>;
#size-cells = <0>;
mdio@0 {
- reg = <0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- pci_phy0: pci-phy@0 {
- compatible = "brcm,ns2-pcie-phy";
- reg = <0x0>;
- #phy-cells = <0>;
- };
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
};
mdio@7 {
- reg = <0x7>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- pci_phy1: pci-phy@0 {
- compatible = "brcm,ns2-pcie-phy";
- reg = <0x0>;
- #phy-cells = <0>;
- };
+ reg = <0x7>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
};
mdio@10 {
- reg = <0x10>;
- #address-cells = <1>;
- #size-cells = <0>;
+ reg = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- gphy0: eth-phy@10 {
- reg = <0x10>;
- };
+ eth-phy@10 {
+ reg = <0x10>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/net/brcm,systemport.yaml b/Documentation/devicetree/bindings/net/brcm,systemport.yaml
index 5fc9c9fafd85..b40006d44791 100644
--- a/Documentation/devicetree/bindings/net/brcm,systemport.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,systemport.yaml
@@ -66,7 +66,7 @@ required:
- phy-mode
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
index 0be426ee1e44..43516dd357b8 100644
--- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
@@ -22,7 +22,11 @@ properties:
- brcm,genet-mdio-v3
- brcm,genet-mdio-v4
- brcm,genet-mdio-v5
+ - brcm,asp-v2.1-mdio
+ - brcm,asp-v2.2-mdio
+ - brcm,asp-v3.0-mdio
- brcm,unimac-mdio
+ - brcm,bcm6846-mdio
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
deleted file mode 100644
index 445b2a553625..000000000000
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
+++ /dev/null
@@ -1,156 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/net/broadcom-bluetooth.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Broadcom Bluetooth Chips
-
-maintainers:
- - Linus Walleij <linus.walleij@linaro.org>
-
-description:
- This binding describes Broadcom UART-attached bluetooth chips.
-
-properties:
- compatible:
- enum:
- - brcm,bcm20702a1
- - brcm,bcm4329-bt
- - brcm,bcm4330-bt
- - brcm,bcm4334-bt
- - brcm,bcm43438-bt
- - brcm,bcm4345c5
- - brcm,bcm43540-bt
- - brcm,bcm4335a0
- - brcm,bcm4349-bt
- - infineon,cyw55572-bt
-
- shutdown-gpios:
- maxItems: 1
- description: GPIO specifier for the line BT_REG_ON used to
- power on the BT module
-
- reset-gpios:
- maxItems: 1
- description: GPIO specifier for the line BT_RST_N used to
- reset the BT module. This should be marked as
- GPIO_ACTIVE_LOW.
-
- device-wakeup-gpios:
- maxItems: 1
- description: GPIO specifier for the line BT_WAKE used to
- wakeup the controller. This is using the BT_GPIO_0
- pin on the chip when in use.
-
- host-wakeup-gpios:
- maxItems: 1
- deprecated: true
- description: GPIO specifier for the line HOST_WAKE used
- to wakeup the host processor. This is using he BT_GPIO_1
- pin on the chip when in use. This is deprecated and replaced
- by interrupts and "host-wakeup" interrupt-names
-
- clocks:
- minItems: 1
- maxItems: 2
- description: 1 or 2 clocks as defined in clock-names below,
- in that order
-
- clock-names:
- description: Names of the 1 to 2 supplied clocks
- oneOf:
- - const: extclk
- deprecated: true
- description: Deprecated in favor of txco
-
- - const: txco
- description: >
- external reference clock (not a standalone crystal)
-
- - const: lpo
- description: >
- external low power 32.768 kHz clock
-
- - items:
- - const: txco
- - const: lpo
-
- vbat-supply:
- description: phandle to regulator supply for VBAT
-
- vddio-supply:
- description: phandle to regulator supply for VDDIO
-
- brcm,bt-pcm-int-params:
- $ref: /schemas/types.yaml#/definitions/uint8-array
- minItems: 5
- maxItems: 5
- description: |-
- configure PCM parameters via a 5-byte array:
- sco-routing: 0 = PCM, 1 = Transport, 2 = Codec, 3 = I2S
- pcm-interface-rate: 128KBps, 256KBps, 512KBps, 1024KBps, 2048KBps
- pcm-frame-type: short, long
- pcm-sync-mode: slave, master
- pcm-clock-mode: slave, master
-
- brcm,requires-autobaud-mode:
- type: boolean
- description:
- Set this property if autobaud mode is required. Autobaud mode is required
- if the device's initial baud rate in normal mode is not supported by the
- host or if the device requires autobaud mode startup before loading FW.
-
- interrupts:
- items:
- - description: Handle to the line HOST_WAKE used to wake
- up the host processor. This uses the BT_GPIO_1 pin on
- the chip when in use.
-
- interrupt-names:
- items:
- - const: host-wakeup
-
- max-speed: true
- current-speed: true
-
-required:
- - compatible
-
-dependencies:
- brcm,requires-autobaud-mode: [ 'shutdown-gpios' ]
-
-if:
- not:
- properties:
- compatible:
- contains:
- enum:
- - brcm,bcm20702a1
- - brcm,bcm4329-bt
- - brcm,bcm4330-bt
-then:
- properties:
- reset-gpios: false
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
-
- uart {
- uart-has-rtscts;
-
- bluetooth {
- compatible = "brcm,bcm4330-bt";
- max-speed = <921600>;
- brcm,bt-pcm-int-params = [01 02 00 01 01];
- shutdown-gpios = <&gpio 30 GPIO_ACTIVE_HIGH>;
- device-wakeup-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio 9 GPIO_ACTIVE_LOW>;
- interrupt-parent = <&gpio>;
- interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
index f546b1f7dd6d..a68022a57c51 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -14,7 +14,7 @@ Required properties:
Also, vendors that use btusb may have device additional properties, e.g:
-Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+Documentation/devicetree/bindings/net/bluetooth/marvell,sd8897-bt.yaml
Optional properties:
diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
index 3c51b2d02957..e42ea28d6ab4 100644
--- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
+++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/can/allwinner,sun4i-a10-can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 CAN Controller Device Tree Bindings
+title: Allwinner A10 CAN Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -21,6 +21,7 @@ properties:
- const: allwinner,sun4i-a10-can
- const: allwinner,sun4i-a10-can
- const: allwinner,sun8i-r40-can
+ - const: allwinner,sun20i-d1-can
reg:
maxItems: 1
@@ -37,8 +38,9 @@ properties:
if:
properties:
compatible:
- contains:
- const: allwinner,sun8i-r40-can
+ enum:
+ - allwinner,sun8i-r40-can
+ - allwinner,sun20i-d1-can
then:
required:
diff --git a/Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml b/Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml
new file mode 100644
index 000000000000..c818c01a718b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/atmel,at91sam9263-can.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/atmel,at91sam9263-can.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 CAN Controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+
+allOf:
+ - $ref: can-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91sam9263-can
+ - atmel,at91sam9x5-can
+ - items:
+ - enum:
+ - microchip,sam9x60-can
+ - const: atmel,at91sam9x5-can
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: can_clk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/at91.h>
+ can@f000c000 {
+ compatible = "atmel,at91sam9263-can";
+ reg = <0xf000c000 0x300>;
+ interrupts = <30 IRQ_TYPE_LEVEL_HIGH 3>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 12>;
+ clock-names = "can_clk";
+ };
diff --git a/Documentation/devicetree/bindings/net/can/atmel-can.txt b/Documentation/devicetree/bindings/net/can/atmel-can.txt
deleted file mode 100644
index 218a3b3eb27e..000000000000
--- a/Documentation/devicetree/bindings/net/can/atmel-can.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* AT91 CAN *
-
-Required properties:
- - compatible: Should be "atmel,at91sam9263-can", "atmel,at91sam9x5-can" or
- "microchip,sam9x60-can"
- - reg: Should contain CAN controller registers location and length
- - interrupts: Should contain IRQ line for the CAN controller
-
-Example:
-
- can0: can@f000c000 {
- compatible = "atmel,at91sam9x5-can";
- reg = <0xf000c000 0x300>;
- interrupts = <40 4 5>
- };
diff --git a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml
index 51aa89ac7e85..ff1b59a0294e 100644
--- a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml
+++ b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/can/bosch,c_can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bosch C_CAN/D_CAN controller Device Tree Bindings
+title: Bosch C_CAN/D_CAN controller
description: Bosch C_CAN/D_CAN controller for CAN bus
@@ -99,11 +99,11 @@ examples:
#include <dt-bindings/reset/altr,rst-mgr.h>
can@ffc00000 {
- compatible = "bosch,d_can";
- reg = <0xffc00000 0x1000>;
- interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>;
- clocks = <&can0_clk>;
- resets = <&rst CAN0_RESET>;
+ compatible = "bosch,d_can";
+ reg = <0xffc00000 0x1000>;
+ interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>;
+ clocks = <&can0_clk>;
+ resets = <&rst CAN0_RESET>;
};
- |
can@0 {
diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
index 26aa0830eea1..2c9d37975bed 100644
--- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
+++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/can/bosch,m_can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bosch MCAN controller Bindings
+title: Bosch MCAN controller
description: Bosch MCAN controller for CAN bus
@@ -50,6 +50,9 @@ properties:
- const: hclk
- const: cclk
+ resets:
+ maxItems: 1
+
bosch,mram-cfg:
description: |
Message RAM configuration data.
@@ -106,6 +109,26 @@ properties:
maximum: 32
minItems: 1
+ pinctrl-0:
+ description: Default pinctrl state
+
+ pinctrl-1:
+ description: Can be "sleep" or "wakeup" pinctrl state
+
+ pinctrl-2:
+ description: Can be "sleep" or "wakeup" pinctrl state
+
+ pinctrl-names:
+ description:
+ When present should contain at least "default" describing the default pin
+ states. Other states are "sleep" which describes the pinstate when
+ sleeping and "wakeup" describing the pins if wakeup is enabled.
+ minItems: 1
+ items:
+ - const: default
+ - enum: [ sleep, wakeup ]
+ - const: wakeup
+
power-domains:
description:
Power domain provider node and an args specifier containing
@@ -118,20 +141,28 @@ properties:
phys:
maxItems: 1
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+ wakeup-source:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ List of phandles to system idle states in which mcan can wakeup the system.
+
required:
- compatible
- reg
- reg-names
- - interrupts
- - interrupt-names
- clocks
- clock-names
- bosch,mram-cfg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ // Example with interrupts
#include <dt-bindings/clock/imx6sx-clock.h>
can@20e8000 {
compatible = "bosch,m_can";
@@ -149,4 +180,21 @@ examples:
};
};
+ - |
+ // Example with timer polling
+ #include <dt-bindings/clock/imx6sx-clock.h>
+ can@20e8000 {
+ compatible = "bosch,m_can";
+ reg = <0x020e8000 0x4000>, <0x02298000 0x4000>;
+ reg-names = "m_can", "message_ram";
+ clocks = <&clks IMX6SX_CLK_CANFD>,
+ <&clks IMX6SX_CLK_CANFD>;
+ clock-names = "hclk", "cclk";
+ bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>;
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+ };
+
...
diff --git a/Documentation/devicetree/bindings/net/can/can-controller.yaml b/Documentation/devicetree/bindings/net/can/can-controller.yaml
index 1f0e98051074..217be90960e8 100644
--- a/Documentation/devicetree/bindings/net/can/can-controller.yaml
+++ b/Documentation/devicetree/bindings/net/can/can-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/can/can-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: CAN Controller Generic Binding
+title: CAN Controller Common Properties
maintainers:
- Marc Kleine-Budde <mkl@pengutronix.de>
diff --git a/Documentation/devicetree/bindings/net/can/can-transceiver.yaml b/Documentation/devicetree/bindings/net/can/can-transceiver.yaml
index d1ef1fe6ab29..d422b3921ffa 100644
--- a/Documentation/devicetree/bindings/net/can/can-transceiver.yaml
+++ b/Documentation/devicetree/bindings/net/can/can-transceiver.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/can/can-transceiver.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: CAN transceiver Bindings
+title: CAN transceiver
description: CAN transceiver generic properties bindings
diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt
index 77027bf6460a..042200cf4419 100644
--- a/Documentation/devicetree/bindings/net/can/cc770.txt
+++ b/Documentation/devicetree/bindings/net/can/cc770.txt
@@ -26,7 +26,7 @@ Optional properties:
will be disabled.
- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
- a resonable value will be calculated.
+ a reasonable value will be calculated.
- bosch,disconnect-rx0-input : see data sheet.
diff --git a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
index 4635cb96fc64..a009a4402938 100644
--- a/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/can/ctu,ctucanfd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: CTU CAN FD Open-source IP Core Device Tree Bindings
+title: CTU CAN FD Open-source IP Core
description: |
Open-source CAN FD IP core developed at the Czech Technical University in Prague
diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
index e52db841bb8c..f81d56f7c12a 100644
--- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
+++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
@@ -10,13 +10,12 @@ title:
maintainers:
- Marc Kleine-Budde <mkl@pengutronix.de>
-allOf:
- - $ref: can-controller.yaml#
-
properties:
compatible:
oneOf:
- enum:
+ - fsl,imx95-flexcan
+ - fsl,imx93-flexcan
- fsl,imx8qm-flexcan
- fsl,imx8mp-flexcan
- fsl,imx6q-flexcan
@@ -26,6 +25,7 @@ properties:
- fsl,vf610-flexcan
- fsl,ls1021ar2-flexcan
- fsl,lx2160ar1-flexcan
+ - nxp,s32g2-flexcan
- items:
- enum:
- fsl,imx53-flexcan
@@ -41,12 +41,25 @@ properties:
- enum:
- fsl,ls1028ar1-flexcan
- const: fsl,lx2160ar1-flexcan
+ - items:
+ - enum:
+ - nxp,s32g3-flexcan
+ - const: nxp,s32g2-flexcan
+ - items:
+ - enum:
+ - fsl,imx94-flexcan
+ - const: fsl,imx95-flexcan
reg:
maxItems: 1
interrupts:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 4
clocks:
maxItems: 2
@@ -62,9 +75,15 @@ properties:
boot loader. This property should only be used the used operating system
doesn't support the clocks and clock-names property.
+ power-domains:
+ maxItems: 1
+
xceiver-supply:
description: Regulator that powers the CAN transceiver.
+ phys:
+ maxItems: 1
+
big-endian:
$ref: /schemas/types.yaml#/definitions/flag
description: |
@@ -73,6 +92,10 @@ properties:
node then controller is assumed to be little endian. If this property is
present then controller is assumed to be big endian.
+ can-transceiver:
+ $ref: can-transceiver.yaml#
+ unevaluatedProperties: false
+
fsl,stop-mode:
description: |
Register bits of stop mode control.
@@ -127,6 +150,41 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: can-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,s32g2-flexcan
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: Message Buffer interrupt for mailboxes 0-7 and Enhanced RX FIFO
+ - description: Device state change
+ - description: Bus Error detection
+ - description: Message Buffer interrupt for mailboxes 8-127
+ interrupt-names:
+ items:
+ - const: mb-0
+ - const: state
+ - const: berr
+ - const: mb-1
+ required:
+ - interrupt-names
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names: false
+ - if:
+ required:
+ - xceiver-supply
+ then:
+ properties:
+ phys: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml
new file mode 100644
index 000000000000..1525a50ded47
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp2510.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/microchip,mcp2510.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip MCP251X stand-alone CAN controller
+
+maintainers:
+ - Marc Kleine-Budde <mkl@pengutronix.de>
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp2510
+ - microchip,mcp2515
+ - microchip,mcp25625
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that powers the CAN controller.
+
+ xceiver-supply:
+ description: Regulator that powers the CAN transceiver.
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ can@1 {
+ compatible = "microchip,mcp2515";
+ reg = <1>;
+ clocks = <&clk24m>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ vdd-supply = <&reg5v0>;
+ xceiver-supply = <&reg5v0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt b/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt
deleted file mode 100644
index 381f8fb3e865..000000000000
--- a/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Microchip MCP251X stand-alone CAN controller device tree bindings
-
-Required properties:
- - compatible: Should be one of the following:
- - "microchip,mcp2510" for MCP2510.
- - "microchip,mcp2515" for MCP2515.
- - "microchip,mcp25625" for MCP25625.
- - reg: SPI chip select.
- - clocks: The clock feeding the CAN controller.
- - interrupts: Should contain IRQ line for the CAN controller.
-
-Optional properties:
- - vdd-supply: Regulator that powers the CAN controller.
- - xceiver-supply: Regulator that powers the CAN transceiver.
- - gpio-controller: Indicates this device is a GPIO controller.
- - #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity.
-
-Example:
- can0: can@1 {
- compatible = "microchip,mcp2515";
- reg = <1>;
- clocks = <&clk24m>;
- interrupt-parent = <&gpio4>;
- interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
- vdd-supply = <&reg5v0>;
- xceiver-supply = <&reg5v0>;
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
index 7a73057707b4..2d13638ebc6a 100644
--- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
@@ -4,9 +4,7 @@
$id: http://devicetree.org/schemas/net/can/microchip,mcp251xfd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title:
- Microchip MCP2517FD, MCP2518FD and MCP251863 stand-alone CAN
- controller device tree bindings
+title: Microchip MCP2517FD, MCP2518FD and MCP251863 stand-alone CAN controller
maintainers:
- Marc Kleine-Budde <mkl@pengutronix.de>
@@ -42,7 +40,7 @@ properties:
microchip,rx-int-gpios:
description:
- GPIO phandle of GPIO connected to to INT1 pin of the MCP251XFD, which
+ GPIO phandle of GPIO connected to INT1 pin of the MCP251XFD, which
signals a pending RX interrupt.
maxItems: 1
@@ -51,6 +49,11 @@ properties:
Must be half or less of "clocks" frequency.
maximum: 20000000
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
required:
- compatible
- reg
@@ -64,7 +67,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml
index 45aa3de7cf01..519a11fbe972 100644
--- a/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml
+++ b/Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml
@@ -15,7 +15,11 @@ allOf:
properties:
compatible:
- const: microchip,mpfs-can
+ oneOf:
+ - items:
+ - const: microchip,pic64gx-can
+ - const: microchip,mpfs-can
+ - const: microchip,mpfs-can
reg:
maxItems: 1
@@ -24,6 +28,11 @@ properties:
maxItems: 1
clocks:
+ items:
+ - description: AHB peripheral clock
+ - description: CAN bus clock
+
+ resets:
maxItems: 1
required:
@@ -31,6 +40,7 @@ required:
- reg
- interrupts
- clocks
+ - resets
additionalProperties: false
@@ -39,7 +49,8 @@ examples:
can@2010c000 {
compatible = "microchip,mpfs-can";
reg = <0x2010c000 0x1000>;
- clocks = <&clkcfg 17>;
+ clocks = <&clkcfg 17>, <&clkcfg 37>;
+ resets = <&clkcfg 17>;
interrupt-parent = <&plic>;
interrupts = <56>;
};
diff --git a/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
index 144a3785132c..ec0c2168e4b9 100644
--- a/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
+++ b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
@@ -16,9 +16,7 @@ properties:
- nxp,sja1000
- technologic,sja1000
- items:
- - enum:
- - renesas,r9a06g032-sja1000 # RZ/N1D
- - renesas,r9a06g033-sja1000 # RZ/N1S
+ - const: renesas,r9a06g032-sja1000 # RZ/N1D
- const: renesas,rzn1-sja1000 # RZ/N1
reg:
diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index 6f71fc96bc4e..f4ac21c68427 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -9,9 +9,6 @@ title: Renesas R-Car CAN FD Controller
maintainers:
- Fabrizio Castro <fabrizio.castro.jz@renesas.com>
-allOf:
- - $ref: can-controller.yaml#
-
properties:
compatible:
oneOf:
@@ -33,26 +30,92 @@ properties:
- items:
- enum:
- - renesas,r9a07g043-canfd # RZ/G2UL
+ - renesas,r8a779a0-canfd # R-Car V3U
+ - renesas,r8a779g0-canfd # R-Car V4H
+ - renesas,r8a779h0-canfd # R-Car V4M
+ - const: renesas,rcar-gen4-canfd # R-Car Gen4
+
+ - items:
+ - enum:
+ - renesas,r9a07g043-canfd # RZ/G2UL and RZ/Five
- renesas,r9a07g044-canfd # RZ/G2{L,LC}
- renesas,r9a07g054-canfd # RZ/V2L
- const: renesas,rzg2l-canfd # RZ/G2L family
- - const: renesas,r8a779a0-canfd # R-Car V3U
+ - const: renesas,r9a09g047-canfd # RZ/G3E
reg:
maxItems: 1
- interrupts: true
+ interrupts:
+ oneOf:
+ - items:
+ - description: Channel interrupt
+ - description: Global interrupt
+ - items:
+ - description: CAN global error interrupt
+ - description: CAN receive FIFO interrupt
+ - description: CAN0 error interrupt
+ - description: CAN0 transmit interrupt
+ - description: CAN0 transmit/receive FIFO receive completion interrupt
+ - description: CAN1 error interrupt
+ - description: CAN1 transmit interrupt
+ - description: CAN1 transmit/receive FIFO receive completion interrupt
+ - description: CAN2 error interrupt
+ - description: CAN2 transmit interrupt
+ - description: CAN2 transmit/receive FIFO receive completion interrupt
+ - description: CAN3 error interrupt
+ - description: CAN3 transmit interrupt
+ - description: CAN3 transmit/receive FIFO receive completion interrupt
+ - description: CAN4 error interrupt
+ - description: CAN4 transmit interrupt
+ - description: CAN4 transmit/receive FIFO receive completion interrupt
+ - description: CAN5 error interrupt
+ - description: CAN5 transmit interrupt
+ - description: CAN5 transmit/receive FIFO receive completion interrupt
+ minItems: 8
+
+ interrupt-names:
+ oneOf:
+ - items:
+ - const: ch_int
+ - const: g_int
+ - items:
+ - const: g_err
+ - const: g_recc
+ - const: ch0_err
+ - const: ch0_rec
+ - const: ch0_trx
+ - const: ch1_err
+ - const: ch1_rec
+ - const: ch1_trx
+ - const: ch2_err
+ - const: ch2_rec
+ - const: ch2_trx
+ - const: ch3_err
+ - const: ch3_rec
+ - const: ch3_trx
+ - const: ch4_err
+ - const: ch4_rec
+ - const: ch4_trx
+ - const: ch5_err
+ - const: ch5_rec
+ - const: ch5_trx
+ minItems: 8
clocks:
maxItems: 3
clock-names:
- items:
- - const: fck
- - const: canfd
- - const: can_clk
+ oneOf:
+ - items:
+ - const: fck
+ - const: canfd
+ - const: can_clk
+ - items:
+ - const: fck
+ - const: ram_clk
+ - const: can_clk
power-domains:
maxItems: 1
@@ -63,7 +126,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/flag
description:
The controller can operate in either CAN FD only mode (default) or
- Classical CAN only mode. The mode is global to both the channels.
+ Classical CAN only mode. The mode is global to all channels.
Specify this property to put the controller in Classical CAN only mode.
assigned-clocks:
@@ -77,12 +140,17 @@ properties:
description: Maximum frequency of the CANFD clock.
patternProperties:
- "^channel[01]$":
+ "^channel[0-7]$":
type: object
description:
- The controller supports two channels and each is represented as a child
- node. Each child node supports the "status" property only, which
- is used to enable/disable the respective channel.
+ The controller supports multiple channels and each is represented as a
+ child node. Each channel can be enabled/disabled individually.
+
+ properties:
+ phys:
+ maxItems: 1
+
+ additionalProperties: false
required:
- compatible
@@ -98,60 +166,106 @@ required:
- channel0
- channel1
-if:
- properties:
- compatible:
- contains:
- enum:
- - renesas,rzg2l-canfd
-then:
- properties:
- interrupts:
- items:
- - description: CAN global error interrupt
- - description: CAN receive FIFO interrupt
- - description: CAN0 error interrupt
- - description: CAN0 transmit interrupt
- - description: CAN0 transmit/receive FIFO receive completion interrupt
- - description: CAN1 error interrupt
- - description: CAN1 transmit interrupt
- - description: CAN1 transmit/receive FIFO receive completion interrupt
-
- interrupt-names:
- items:
- - const: g_err
- - const: g_recc
- - const: ch0_err
- - const: ch0_rec
- - const: ch0_trx
- - const: ch1_err
- - const: ch1_rec
- - const: ch1_trx
-
- resets:
- maxItems: 2
-
- reset-names:
- items:
- - const: rstp_n
- - const: rstc_n
-
- required:
- - reset-names
-else:
- properties:
- interrupts:
- items:
- - description: Channel interrupt
- - description: Global interrupt
-
- interrupt-names:
- items:
- - const: ch_int
- - const: g_int
-
- resets:
- maxItems: 1
+allOf:
+ - $ref: can-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rzg2l-canfd
+ then:
+ properties:
+ interrupts:
+ maxItems: 8
+
+ interrupt-names:
+ maxItems: 8
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ minItems: 2
+ maxItems: 2
+
+ required:
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rcar-gen3-canfd
+ - renesas,rcar-gen4-canfd
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 2
+ maxItems: 2
+
+ resets:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g047-canfd
+ then:
+ properties:
+ interrupts:
+ minItems: 20
+
+ interrupt-names:
+ minItems: 20
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ minItems: 2
+ maxItems: 2
+
+ required:
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rcar-gen3-canfd
+ - renesas,rzg2l-canfd
+ then:
+ patternProperties:
+ "^channel[2-7]$": false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r8a779h0-canfd
+ then:
+ patternProperties:
+ "^channel[4-7]$": false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g047-canfd
+ then:
+ patternProperties:
+ "^channel[6-7]$": false
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
new file mode 100644
index 000000000000..a077c0330013
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/rockchip,rk3568v2-canfd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Rockchip CAN-FD controller
+
+maintainers:
+ - Marc Kleine-Budde <mkl@pengutronix.de>
+
+allOf:
+ - $ref: can-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: rockchip,rk3568v2-canfd
+ - items:
+ - const: rockchip,rk3568v3-canfd
+ - const: rockchip,rk3568v2-canfd
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: baud
+ - const: pclk
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: core
+ - const: apb
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3568-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ can@fe570000 {
+ compatible = "rockchip,rk3568v2-canfd";
+ reg = <0x0 0xfe570000 0x0 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
+ reset-names = "core", "apb";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml b/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml
new file mode 100644
index 000000000000..c7510b00954a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/st,stm32-bxcan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics bxCAN controller
+
+description: STMicroelectronics BxCAN controller for CAN bus
+
+maintainers:
+ - Dario Binacchi <dario.binacchi@amarulasolutions.com>
+
+allOf:
+ - $ref: can-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,stm32f4-bxcan
+
+ st,can-primary:
+ description:
+ Primary mode of the bxCAN peripheral is only relevant if the chip has
+ two CAN peripherals in dual CAN configuration. In that case they share
+ some of the required logic.
+ Not to be used if the peripheral is in single CAN configuration.
+ To avoid misunderstandings, it should be noted that ST documentation
+ uses the terms master instead of primary.
+ type: boolean
+
+ st,can-secondary:
+ description:
+ Secondary mode of the bxCAN peripheral is only relevant if the chip
+ has two CAN peripherals in dual CAN configuration. In that case they
+ share some of the required logic.
+ Not to be used if the peripheral is in single CAN configuration.
+ To avoid misunderstandings, it should be noted that ST documentation
+ uses the terms slave instead of secondary.
+ type: boolean
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: transmit interrupt
+ - description: FIFO 0 receive interrupt
+ - description: FIFO 1 receive interrupt
+ - description: status change error interrupt
+
+ interrupt-names:
+ items:
+ - const: tx
+ - const: rx0
+ - const: rx1
+ - const: sce
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ st,gcan:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle to the gcan node which allows to access the 512-bytes
+ SRAM memory shared by the two bxCAN cells (CAN1 primary and CAN2
+ secondary) in dual CAN peripheral configuration.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+ - clocks
+ - st,gcan
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/stm32fx-clock.h>
+ #include <dt-bindings/mfd/stm32f4-rcc.h>
+
+ can1: can@40006400 {
+ compatible = "st,stm32f4-bxcan";
+ reg = <0x40006400 0x200>;
+ interrupts = <19>, <20>, <21>, <22>;
+ interrupt-names = "tx", "rx0", "rx1", "sce";
+ resets = <&rcc STM32F4_APB1_RESET(CAN1)>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(CAN1)>;
+ st,can-primary;
+ st,gcan = <&gcan>;
+ };
diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
deleted file mode 100644
index e3501bfa22e9..000000000000
--- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Texas Instruments TCAN4x5x CAN Controller
-================================================
-
-This file provides device node information for the TCAN4x5x interface contains.
-
-Required properties:
- - compatible: "ti,tcan4x5x"
- - reg: 0
- - #address-cells: 1
- - #size-cells: 0
- - spi-max-frequency: Maximum frequency of the SPI bus the chip can
- operate at should be less than or equal to 18 MHz.
- - interrupt-parent: the phandle to the interrupt controller which provides
- the interrupt.
- - interrupts: interrupt specification for data-ready.
-
-See Documentation/devicetree/bindings/net/can/bosch,m_can.yaml for additional
-required property details.
-
-Optional properties:
- - reset-gpios: Hardwired output GPIO. If not defined then software
- reset.
- - device-state-gpios: Input GPIO that indicates if the device is in
- a sleep state or if the device is active.
- - device-wake-gpios: Wake up GPIO to wake up the TCAN device.
-
-Example:
-tcan4x5x: tcan4x5x@0 {
- compatible = "ti,tcan4x5x";
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
- spi-max-frequency = <10000000>;
- bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
- interrupt-parent = <&gpio1>;
- interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
- device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
- device-wake-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml b/Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml
new file mode 100644
index 000000000000..384e15da2713
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti,tcan4x5x.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/ti,tcan4x5x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TCAN4x5x CAN Controller
+
+maintainers:
+ - Marc Kleine-Budde <mkl@pengutronix.de>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,tcan4552
+ - ti,tcan4553
+ - const: ti,tcan4x5x
+ - const: ti,tcan4x5x
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: The GPIO parent interrupt.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cclk
+
+ reset-gpios:
+ description: Hardwired output GPIO. If not defined then software reset.
+ maxItems: 1
+
+ device-state-gpios:
+ description:
+ Input GPIO that indicates if the device is in a sleep state or if the
+ device is active. Not available with tcan4552/4553.
+ maxItems: 1
+
+ device-wake-gpios:
+ description:
+ Wake up GPIO to wake up the TCAN device.
+ Not available with tcan4552/4553.
+ maxItems: 1
+
+ bosch,mram-cfg:
+ description: |
+ Message RAM configuration data.
+ Multiple M_CAN instances can share the same Message RAM
+ and each element(e.g Rx FIFO or Tx Buffer and etc) number
+ in Message RAM is also configurable, so this property is
+ telling driver how the shared or private Message RAM are
+ used by this M_CAN controller.
+
+ The format should be as follows:
+ <offset sidf_elems xidf_elems rxf0_elems rxf1_elems rxb_elems txe_elems txb_elems>
+ The 'offset' is an address offset of the Message RAM where
+ the following elements start from. This is usually set to
+ 0x0 if you're using a private Message RAM. The remain cells
+ are used to specify how many elements are used for each FIFO/Buffer.
+
+ M_CAN includes the following elements according to user manual:
+ 11-bit Filter 0-128 elements / 0-128 words
+ 29-bit Filter 0-64 elements / 0-128 words
+ Rx FIFO 0 0-64 elements / 0-1152 words
+ Rx FIFO 1 0-64 elements / 0-1152 words
+ Rx Buffers 0-64 elements / 0-1152 words
+ Tx Event FIFO 0-32 elements / 0-64 words
+ Tx Buffers 0-32 elements / 0-576 words
+
+ Please refer to 2.4.1 Message RAM Configuration in Bosch
+ M_CAN user manual for details.
+ $ref: /schemas/types.yaml#/definitions/int32-array
+ items:
+ - description: The 'offset' is an address offset of the Message RAM where
+ the following elements start from. This is usually set to 0x0 if
+ you're using a private Message RAM.
+ default: 0
+ - description: 11-bit Filter 0-128 elements / 0-128 words
+ minimum: 0
+ maximum: 128
+ - description: 29-bit Filter 0-64 elements / 0-128 words
+ minimum: 0
+ maximum: 64
+ - description: Rx FIFO 0 0-64 elements / 0-1152 words
+ minimum: 0
+ maximum: 64
+ - description: Rx FIFO 1 0-64 elements / 0-1152 words
+ minimum: 0
+ maximum: 64
+ - description: Rx Buffers 0-64 elements / 0-1152 words
+ minimum: 0
+ maximum: 64
+ - description: Tx Event FIFO 0-32 elements / 0-64 words
+ minimum: 0
+ maximum: 32
+ - description: Tx Buffers 0-32 elements / 0-576 words
+ minimum: 0
+ maximum: 32
+ minItems: 1
+
+ spi-max-frequency:
+ description:
+ Must be half or less of "clocks" frequency.
+ maximum: 18000000
+
+ ti,nwkrq-voltage-vio:
+ type: boolean
+ description:
+ nWKRQ Pin GPO buffer voltage configuration.
+ Set nWKRQ to use VIO voltage rail.
+ When not set nWKRQ will use internal voltage rail.
+
+ wakeup-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable CAN remote wakeup.
+
+allOf:
+ - $ref: can-controller.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tcan4552
+ - ti,tcan4553
+ then:
+ properties:
+ device-state-gpios: false
+ device-wake-gpios: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - bosch,mram-cfg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ can@0 {
+ compatible = "ti,tcan4x5x";
+ reg = <0>;
+ clocks = <&can0_osc>;
+ clock-names = "cclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can0_pins>;
+ spi-max-frequency = <10000000>;
+ bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ device-wake-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+ ti,nwkrq-voltage-vio;
+ wakeup-source;
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ can@0 {
+ compatible = "ti,tcan4552", "ti,tcan4x5x";
+ reg = <0>;
+ clocks = <&can0_osc>;
+ clock-names = "cclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can0_pins>;
+ spi-max-frequency = <10000000>;
+ bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
index 65af8183cb9c..40835497050a 100644
--- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
+++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml
@@ -5,7 +5,7 @@ $id: http://devicetree.org/schemas/net/can/xilinx,can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title:
- Xilinx Axi CAN/Zynq CANPS controller
+ Xilinx CAN and CANFD controller
maintainers:
- Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
@@ -35,17 +35,24 @@ properties:
maxItems: 1
tx-fifo-depth:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: CAN Tx fifo depth (Zynq, Axi CAN).
rx-fifo-depth:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode)
tx-mailbox-count:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: CAN Tx mailbox buffer count (CAN FD)
+ resets:
+ maxItems: 1
+
+ xlnx,has-ecc:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: CAN TX_OL, TX_TL and RX FIFOs have ECC support(AXI CAN)
+
required:
- compatible
- reg
@@ -134,6 +141,7 @@ examples:
interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
+ xlnx,has-ecc;
};
- |
diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml
index 318f4efe7f6f..cb14c35ba996 100644
--- a/Documentation/devicetree/bindings/net/cdns,macb.yaml
+++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml
@@ -38,7 +38,10 @@ properties:
- cdns,sam9x60-macb # Microchip sam9x60 SoC
- microchip,mpfs-macb # Microchip PolarFire SoC
- const: cdns,macb # Generic
-
+ - items:
+ - const: microchip,pic64gx-macb # Microchip PIC64GX SoC
+ - const: microchip,mpfs-macb # Microchip PolarFire SoC
+ - const: cdns,macb # Generic
- items:
- enum:
- atmel,sama5d3-macb # 10/100Mbit IP on Atmel sama5d3 SoCs
@@ -47,17 +50,25 @@ properties:
- const: cdns,macb # Generic
- enum:
- - atmel,sama5d29-gem # GEM XL IP (10/100) on Atmel sama5d29 SoCs
- atmel,sama5d2-gem # GEM IP (10/100) on Atmel sama5d2 SoCs
+ - atmel,sama5d29-gem # GEM XL IP (10/100) on Atmel sama5d29 SoCs
- atmel,sama5d3-gem # Gigabit IP on Atmel sama5d3 SoCs
- atmel,sama5d4-gem # GEM IP (10/100) on Atmel sama5d4 SoCs
+ - cdns,emac # Generic
+ - cdns,gem # Generic
+ - cdns,macb # Generic
- cdns,np4-macb # NP4 SoC devices
- microchip,sama7g5-emac # Microchip SAMA7G5 ethernet interface
- microchip,sama7g5-gem # Microchip SAMA7G5 gigabit ethernet interface
+ - mobileye,eyeq5-gem # Mobileye EyeQ5 SoCs
+ - raspberrypi,rp1-gem # Raspberry Pi RP1 gigabit ethernet interface
- sifive,fu540-c000-gem # SiFive FU540-C000 SoC
- - cdns,emac # Generic
- - cdns,gem # Generic
- - cdns,macb # Generic
+
+ - items:
+ - enum:
+ - microchip,sam9x7-gem # Microchip SAM9X7 gigabit ethernet interface
+ - microchip,sama7d65-gem # Microchip SAMA7D65 gigabit ethernet interface
+ - const: microchip,sama7g5-gem # Microchip SAMA7G5 gigabit ethernet interface
reg:
minItems: 1
@@ -79,7 +90,7 @@ properties:
items:
- enum: [ ether_clk, hclk, pclk ]
- enum: [ hclk, pclk ]
- - const: tx_clk
+ - enum: [ tx_clk, tsu_clk ]
- enum: [ rx_clk, tsu_clk ]
- const: tsu_clk
@@ -109,6 +120,23 @@ properties:
power-domains:
maxItems: 1
+ cdns,refclk-ext:
+ type: boolean
+ description:
+ This selects if the REFCLK for RMII is provided by an external source.
+ For RGMII mode this selects if the 125MHz REF clock is provided by an external
+ source.
+
+ cdns,rx-watermark:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the receive partial store and forward mode is activated,
+ the receiver will only begin to forward the packet to the external
+ AHB or AXI slave when enough packet data is stored in the SRAM packet buffer.
+ rx-watermark corresponds to the number of SRAM buffer locations,
+ that need to be filled, before the forwarding process is activated.
+ Width of the SRAM is platform dependent, and can be 4, 8 or 16 bytes.
+
'#address-cells':
const: 1
@@ -131,6 +159,7 @@ patternProperties:
magic-packet:
type: boolean
+ deprecated: true
description:
Indicates that the hardware supports waking up via magic packet.
@@ -158,6 +187,15 @@ allOf:
reg:
maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mobileye,eyeq5-gem
+ then:
+ required:
+ - phys
+
unevaluatedProperties: false
examples:
@@ -166,6 +204,7 @@ examples:
compatible = "cdns,macb";
reg = <0xfffc4000 0x4000>;
interrupts = <21>;
+ cdns,rx-watermark = <0x44>;
phy-mode = "rmii";
local-mac-address = [3a 0e 03 04 05 06];
clock-names = "pclk", "hclk", "tx_clk";
@@ -180,7 +219,6 @@ examples:
};
- |
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/power/xlnx-zynqmp-power.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
#include <dt-bindings/phy/phy.h>
@@ -193,9 +231,9 @@ examples:
interrupt-parent = <&gic>;
interrupts = <0 59 4>, <0 59 4>;
reg = <0x0 0xff0c0000 0x0 0x1000>;
- clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
- <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
- <&zynqmp_clk GEM_TSU>;
+ clocks = <&zynqmp_clk 31>, <&zynqmp_clk 105>,
+ <&zynqmp_clk 51>, <&zynqmp_clk 50>,
+ <&zynqmp_clk 44>;
clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
#address-cells = <1>;
#size-cells = <0>;
@@ -203,7 +241,6 @@ examples:
power-domains = <&zynqmp_firmware PD_ETH_1>;
resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>;
reset-names = "gem1_rst";
- status = "okay";
phy-mode = "sgmii";
phys = <&psgtr 1 PHY_TYPE_SGMII 1 1>;
fixed-link {
diff --git a/Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml b/Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml
new file mode 100644
index 000000000000..ad0915307095
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cirrus,ep9301-eth.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/cirrus,ep9301-eth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EP93xx SoC Ethernet Controller
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-eth
+ - items:
+ - enum:
+ - cirrus,ep9302-eth
+ - cirrus,ep9307-eth
+ - cirrus,ep9312-eth
+ - cirrus,ep9315-eth
+ - const: cirrus,ep9301-eth
+
+ reg:
+ items:
+ - description: The physical base address and size of IO range
+
+ interrupts:
+ items:
+ - description: Combined signal for various interrupt events
+
+ phy-handle: true
+
+ mdio:
+ $ref: mdio.yaml#
+ unevaluatedProperties: false
+ description: optional node for embedded MDIO controller
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - phy-handle
+
+additionalProperties: false
+
+examples:
+ - |
+ ethernet@80010000 {
+ compatible = "cirrus,ep9301-eth";
+ reg = <0x80010000 0x10000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <7>;
+ phy-handle = <&phy0>;
+ };
diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml
index 253b5d1407ee..a930358f6a66 100644
--- a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml
+++ b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml
@@ -31,9 +31,9 @@ properties:
ranges: true
-#The subnodes represents the two ethernet ports in this device.
-#They are not independent of each other since they share resources
-#in the parent node, and are thus children.
+# The subnodes represents the two ethernet ports in this device.
+# They are not independent of each other since they share resources
+# in the parent node, and are thus children.
patternProperties:
"^ethernet-port@[0-9]+$":
type: object
@@ -100,7 +100,6 @@ examples:
};
};
-
ethernet@60000000 {
compatible = "cortina,gemini-ethernet";
reg = <0x60000000 0x4000>, /* Global registers, queue */
diff --git a/Documentation/devicetree/bindings/net/davicom,dm9000.yaml b/Documentation/devicetree/bindings/net/davicom,dm9000.yaml
new file mode 100644
index 000000000000..66a7c6eec767
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom,dm9000.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/davicom,dm9000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Davicom DM9000 Fast Ethernet Controller
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: davicom,dm9000
+
+ reg:
+ items:
+ - description: Address registers
+ - description: Data registers
+
+ interrupts:
+ maxItems: 1
+
+ davicom,no-eeprom:
+ type: boolean
+ description: Configuration EEPROM is not available
+
+ davicom,ext-phy:
+ type: boolean
+ description: Use external PHY
+
+ reset-gpios:
+ maxItems: 1
+
+ vcc-supply: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ethernet@a8000000 {
+ compatible = "davicom,dm9000";
+ reg = <0xa8000000 0x2>, <0xa8000002 0x2>;
+ interrupt-parent = <&gph1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+ local-mac-address = [00 00 de ad be ef];
+ davicom,no-eeprom;
+ };
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
deleted file mode 100644
index 64c159e9cbf7..000000000000
--- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Davicom DM9000 Fast Ethernet controller
-
-Required properties:
-- compatible = "davicom,dm9000";
-- reg : physical addresses and sizes of registers, must contain 2 entries:
- first entry : address register,
- second entry : data register.
-- interrupts : interrupt specifier specific to interrupt controller
-
-Optional properties:
-- davicom,no-eeprom : Configuration EEPROM is not available
-- davicom,ext-phy : Use external PHY
-- reset-gpios : phandle of gpio that will be used to reset chip during probe
-- vcc-supply : phandle of regulator that will be used to enable power to chip
-
-Example:
-
- ethernet@18000000 {
- compatible = "davicom,dm9000";
- reg = <0x18000000 0x2 0x18000004 0x2>;
- interrupt-parent = <&gpn>;
- interrupts = <7 4>;
- local-mac-address = [00 00 de ad be ef];
- davicom,no-eeprom;
- reset-gpios = <&gpf 12 GPIO_ACTIVE_LOW>;
- vcc-supply = <&eth0_power>;
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/ar9331.txt b/Documentation/devicetree/bindings/net/dsa/ar9331.txt
deleted file mode 100644
index f824fdae0da2..000000000000
--- a/Documentation/devicetree/bindings/net/dsa/ar9331.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-Atheros AR9331 built-in switch
-=============================
-
-It is a switch built-in to Atheros AR9331 WiSoC and addressable over internal
-MDIO bus. All PHYs are built-in as well.
-
-Required properties:
-
- - compatible: should be: "qca,ar9331-switch"
- - reg: Address on the MII bus for the switch.
- - resets : Must contain an entry for each entry in reset-names.
- - reset-names : Must include the following entries: "switch"
- - interrupt-parent: Phandle to the parent interrupt controller
- - interrupts: IRQ line for the switch
- - interrupt-controller: Indicates the switch is itself an interrupt
- controller. This is used for the PHY interrupts.
- - #interrupt-cells: must be 1
- - mdio: Container of PHY and devices on the switches MDIO bus.
-
-See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
-required and optional properties.
-Examples:
-
-eth0: ethernet@19000000 {
- compatible = "qca,ar9330-eth";
- reg = <0x19000000 0x200>;
- interrupts = <4>;
-
- resets = <&rst 9>, <&rst 22>;
- reset-names = "mac", "mdio";
- clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
- clock-names = "eth", "mdio";
-
- phy-mode = "mii";
- phy-handle = <&phy_port4>;
-};
-
-eth1: ethernet@1a000000 {
- compatible = "qca,ar9330-eth";
- reg = <0x1a000000 0x200>;
- interrupts = <5>;
- resets = <&rst 13>, <&rst 23>;
- reset-names = "mac", "mdio";
- clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
- clock-names = "eth", "mdio";
-
- phy-mode = "gmii";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch10: switch@10 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- compatible = "qca,ar9331-switch";
- reg = <0x10>;
- resets = <&rst 8>;
- reset-names = "switch";
-
- interrupt-parent = <&miscintc>;
- interrupts = <12>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch_port0: port@0 {
- reg = <0x0>;
- ethernet = <&eth1>;
-
- phy-mode = "gmii";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- switch_port1: port@1 {
- reg = <0x1>;
- phy-handle = <&phy_port0>;
- phy-mode = "internal";
- };
-
- switch_port2: port@2 {
- reg = <0x2>;
- phy-handle = <&phy_port1>;
- phy-mode = "internal";
- };
-
- switch_port3: port@3 {
- reg = <0x3>;
- phy-handle = <&phy_port2>;
- phy-mode = "internal";
- };
-
- switch_port4: port@4 {
- reg = <0x4>;
- phy-handle = <&phy_port3>;
- phy-mode = "internal";
- };
- };
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- interrupt-parent = <&switch10>;
-
- phy_port0: phy@0 {
- reg = <0x0>;
- interrupts = <0>;
- };
-
- phy_port1: phy@1 {
- reg = <0x1>;
- interrupts = <0>;
- };
-
- phy_port2: phy@2 {
- reg = <0x2>;
- interrupts = <0>;
- };
-
- phy_port3: phy@3 {
- reg = <0x3>;
- interrupts = <0>;
- };
-
- phy_port4: phy@4 {
- reg = <0x4>;
- interrupts = <0>;
- };
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
index 259a0c6547f3..9565a7402146 100644
--- a/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/arrow,xrs700x.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/net/dsa/arrow,xrs700x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Arrow SpeedChips XRS7000 Series Switch Device Tree Bindings
+title: Arrow SpeedChips XRS7000 Series Switch
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
maintainers:
- George McCollister <george.mccollister@gmail.com>
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
index 1219b830b1a4..fbab3a1a8d3e 100644
--- a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml
@@ -16,9 +16,11 @@ properties:
compatible:
oneOf:
- const: brcm,bcm5325
+ - const: brcm,bcm53101
- const: brcm,bcm53115
- const: brcm,bcm53125
- const: brcm,bcm53128
+ - const: brcm,bcm53134
- const: brcm,bcm5365
- const: brcm,bcm5395
- const: brcm,bcm5389
@@ -57,22 +59,32 @@ properties:
- items:
- enum:
- brcm,bcm3384-switch
+ - brcm,bcm6318-switch
- brcm,bcm6328-switch
+ - brcm,bcm6362-switch
- brcm,bcm6368-switch
+ - brcm,bcm63268-switch
- const: brcm,bcm63xx-switch
+ brcm,gpio-ctrl:
+ description:
+ A phandle to the syscon node of the bcm63xx gpio controller
+ which contains phy control registers
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- if:
properties:
compatible:
contains:
enum:
- brcm,bcm5325
+ - brcm,bcm53101
- brcm,bcm53115
- brcm,bcm53125
- brcm,bcm53128
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
index d159ac78cec1..f21bdd0f408d 100644
--- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/dsa/brcm,sf2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom Starfighter 2 integrated swich
+title: Broadcom Starfighter 2 integrated switch
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
@@ -76,29 +76,27 @@ properties:
supports reporting the number of packets in-flight in a switch queue
type: boolean
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
ports:
type: object
+ additionalProperties: true
+
+ patternProperties:
+ '^port@[0-9a-f]$':
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
- properties:
- brcm,use-bcm-hdr:
- description: if present, indicates that the switch port has Broadcom
- tags enabled (per-packet metadata)
- type: boolean
+ properties:
+ brcm,use-bcm-hdr:
+ description: if present, indicates that the switch port has Broadcom
+ tags enabled (per-packet metadata)
+ type: boolean
required:
- reg
- interrupts
- - "#address-cells"
- - "#size-cells"
allOf:
- - $ref: "dsa.yaml#"
+ - $ref: dsa.yaml#
- if:
properties:
compatible:
@@ -140,8 +138,6 @@ examples:
- |
switch@f0b00000 {
compatible = "brcm,bcm7445-switch-v4.0";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0xf0b00000 0x40000>,
<0xf0b40000 0x110>,
<0xf0b40340 0x30>,
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
index 10ad7e71097b..480120469953 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
@@ -4,22 +4,24 @@
$id: http://devicetree.org/schemas/net/dsa/dsa-port.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ethernet Switch port Device Tree Bindings
+title: Generic DSA Switch Port
maintainers:
- Andrew Lunn <andrew@lunn.ch>
- Florian Fainelli <f.fainelli@gmail.com>
- - Vivien Didelot <vivien.didelot@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
description:
- Ethernet switch port Description
+ A DSA switch port is a component of a switch that manages one MAC, and can
+ pass Ethernet frames. It can act as a stanadard Ethernet switch port, or have
+ DSA-specific functionality.
-allOf:
- - $ref: /schemas/net/ethernet-controller.yaml#
+$ref: /schemas/net/ethernet-switch-port.yaml#
properties:
reg:
- description: Port number
+ items:
+ - description: Port number
label:
description:
@@ -57,25 +59,6 @@ properties:
- rtl8_4t
- seville
- phy-handle: true
-
- phy-mode: true
-
- fixed-link: true
-
- mac-address: true
-
- sfp: true
-
- managed: true
-
- rx-internal-delay-ps: true
-
- tx-internal-delay-ps: true
-
-required:
- - reg
-
# CPU and DSA ports must have phylink-compatible link descriptions
if:
oneOf:
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
index b9d48e357e77..2abd036578d1 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
@@ -4,12 +4,12 @@
$id: http://devicetree.org/schemas/net/dsa/dsa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ethernet Switch Device Tree Bindings
+title: Ethernet Switch
maintainers:
- Andrew Lunn <andrew@lunn.ch>
- Florian Fainelli <f.fainelli@gmail.com>
- - Vivien Didelot <vivien.didelot@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
description:
This binding represents Ethernet Switches which have a dedicated CPU
@@ -18,10 +18,9 @@ description:
select: false
-properties:
- $nodename:
- pattern: "^(ethernet-)?switch(@.*)?$"
+$ref: /schemas/net/ethernet-switch.yaml#
+properties:
dsa,member:
minItems: 2
maxItems: 2
@@ -32,23 +31,20 @@ properties:
(single device hanging off a CPU port) must not specify this property
$ref: /schemas/types.yaml#/definitions/uint32-array
-patternProperties:
- "^(ethernet-)?ports$":
- type: object
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
-
- patternProperties:
- "^(ethernet-)?port@[0-9]+$":
- type: object
- description: Ethernet switch ports
+additionalProperties: true
- $ref: dsa-port.yaml#
+$defs:
+ ethernet-ports:
+ description: A DSA switch without any extra port properties
+ $ref: '#'
- unevaluatedProperties: false
+ patternProperties:
+ "^(ethernet-)?ports$":
+ patternProperties:
+ "^(ethernet-)?port@[0-9a-f]+$":
+ description: Ethernet switch ports
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
oneOf:
- required:
@@ -56,6 +52,4 @@ oneOf:
- required:
- ethernet-ports
-additionalProperties: true
-
...
diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
index 73b774eadd0b..4021b054f684 100644
--- a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
@@ -4,15 +4,15 @@
$id: http://devicetree.org/schemas/net/dsa/hirschmann,hellcreek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Hirschmann Hellcreek TSN Switch Device Tree Bindings
+title: Hirschmann Hellcreek TSN Switch
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
maintainers:
- Andrew Lunn <andrew@lunn.ch>
- Florian Fainelli <f.fainelli@gmail.com>
- - Vivien Didelot <vivien.didelot@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
- Kurt Kanzenbach <kurt@linutronix.de>
description:
diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
new file mode 100644
index 000000000000..205b683849a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
@@ -0,0 +1,350 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/lantiq,gswip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq GSWIP and MaxLinear GSW1xx Ethernet switches
+
+description:
+ Lantiq GSWIP and MaxLinear GSW1xx switches share the same hardware IP.
+ Lantiq switches are embedded in SoCs and accessed via memory-mapped I/O,
+ while MaxLinear switches are standalone ICs connected via MDIO.
+
+$ref: dsa.yaml#
+
+maintainers:
+ - Hauke Mehrtens <hauke@hauke-m.de>
+
+properties:
+ compatible:
+ enum:
+ - lantiq,xrx200-gswip
+ - lantiq,xrx300-gswip
+ - lantiq,xrx330-gswip
+ - maxlinear,gsw120
+ - maxlinear,gsw125
+ - maxlinear,gsw140
+ - maxlinear,gsw141
+ - maxlinear,gsw145
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: switch
+ - const: mdio
+ - const: mii
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ compatible:
+ const: lantiq,xrx200-mdio
+
+ gphy-fw:
+ type: object
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ compatible:
+ items:
+ - enum:
+ - lantiq,xrx200-gphy-fw
+ - lantiq,xrx300-gphy-fw
+ - lantiq,xrx330-gphy-fw
+ - const: lantiq,gphy-fw
+
+ lantiq,rcu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the RCU syscon
+
+ patternProperties:
+ "^gphy@[0-9a-f]{1,2}$":
+ type: object
+
+ additionalProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 255
+ description:
+ Offset of the GPHY firmware register in the RCU register range
+
+ resets:
+ items:
+ - description: GPHY reset line
+
+ reset-names:
+ items:
+ - const: gphy
+
+ required:
+ - reg
+
+ required:
+ - compatible
+ - lantiq,rcu
+
+ additionalProperties: false
+
+patternProperties:
+ "^(ethernet-)?ports$":
+ type: object
+ patternProperties:
+ "^(ethernet-)?port@[0-6]$":
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ maxlinear,rmii-refclk-out:
+ type: boolean
+ description:
+ Configure the RMII reference clock to be a clock output
+ rather than an input. Only applicable for RMII mode.
+ tx-internal-delay-ps:
+ enum: [0, 500, 1000, 1500, 2000, 2500, 3000, 3500]
+ description:
+ RGMII TX Clock Delay defined in pico seconds.
+ The delay lines adjust the MII clock vs. data timing.
+ If this property is not present the delay is determined by
+ the interface mode.
+ rx-internal-delay-ps:
+ enum: [0, 500, 1000, 1500, 2000, 2500, 3000, 3500]
+ description:
+ RGMII RX Clock Delay defined in pico seconds.
+ The delay lines adjust the MII clock vs. data timing.
+ If this property is not present the delay is determined by
+ the interface mode.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - lantiq,xrx200-gswip
+ - lantiq,xrx300-gswip
+ - lantiq,xrx330-gswip
+ then:
+ properties:
+ reg:
+ minItems: 3
+ maxItems: 3
+ mdio:
+ required:
+ - compatible
+ else:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names: false
+ gphy-fw: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ switch@e108000 {
+ compatible = "lantiq,xrx200-gswip";
+ reg = <0xe108000 0x3100>, /* switch */
+ <0xe10b100 0xd8>, /* mdio */
+ <0xe10b1d8 0x130>; /* mii */
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan3";
+ phy-mode = "rgmii-id";
+ phy-handle = <&phy0>;
+ tx-internal-delay-ps = <2000>;
+ rx-internal-delay-ps = <2000>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan4";
+ phy-mode = "rgmii";
+ phy-handle = <&phy1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ phy-mode = "internal";
+ phy-handle = <&phy11>;
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan1";
+ phy-mode = "internal";
+ phy-handle = <&phy13>;
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "wan";
+ phy-mode = "rgmii";
+ phy-handle = <&phy5>;
+ };
+
+ port@6 {
+ reg = <0x6>;
+ phy-mode = "internal";
+ ethernet = <&eth0>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "lantiq,xrx200-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+ phy5: ethernet-phy@5 {
+ reg = <0x5>;
+ };
+ phy11: ethernet-phy@11 {
+ reg = <0x11>;
+ };
+ phy13: ethernet-phy@13 {
+ reg = <0x13>;
+ };
+ };
+
+ gphy-fw {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw";
+ lantiq,rcu = <&rcu0>;
+
+ gphy@20 {
+ reg = <0x20>;
+
+ resets = <&reset0 31 30>;
+ reset-names = "gphy";
+ };
+
+ gphy@68 {
+ reg = <0x68>;
+
+ resets = <&reset0 29 28>;
+ reset-names = "gphy";
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@1f {
+ compatible = "maxlinear,gsw125";
+ reg = <0x1f>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ phy-handle = <&switchphy0>;
+ phy-mode = "internal";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ phy-handle = <&switchphy1>;
+ phy-mode = "internal";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ phy-mode = "1000base-x";
+ managed = "in-band-status";
+ };
+
+ port@5 {
+ reg = <5>;
+ phy-mode = "rgmii-id";
+ tx-internal-delay-ps = <2000>;
+ rx-internal-delay-ps = <2000>;
+ ethernet = <&eth0>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switchphy0: switchphy@0 {
+ reg = <0>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ };
+ };
+ };
+
+ switchphy1: switchphy@1 {
+ reg = <1>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt b/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
deleted file mode 100644
index 8bb1eff21cb1..000000000000
--- a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt
+++ /dev/null
@@ -1,146 +0,0 @@
-Lantiq GSWIP Ethernet switches
-==================================
-
-Required properties for GSWIP core:
-
-- compatible : "lantiq,xrx200-gswip" for the embedded GSWIP in the
- xRX200 SoC
- "lantiq,xrx300-gswip" for the embedded GSWIP in the
- xRX300 SoC
- "lantiq,xrx330-gswip" for the embedded GSWIP in the
- xRX330 SoC
-- reg : memory range of the GSWIP core registers
- : memory range of the GSWIP MDIO registers
- : memory range of the GSWIP MII registers
-
-See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of
-additional required and optional properties.
-
-
-Required properties for MDIO bus:
-- compatible : "lantiq,xrx200-mdio" for the MDIO bus inside the GSWIP
- core of the xRX200 SoC and the PHYs connected to it.
-
-See Documentation/devicetree/bindings/net/mdio.txt for a list of additional
-required and optional properties.
-
-
-Required properties for GPHY firmware loading:
-- compatible : "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw"
- "lantiq,xrx300-gphy-fw", "lantiq,gphy-fw"
- "lantiq,xrx330-gphy-fw", "lantiq,gphy-fw"
- for the loading of the firmware into the embedded
- GPHY core of the SoC.
-- lantiq,rcu : reference to the rcu syscon
-
-The GPHY firmware loader has a list of GPHY entries, one for each
-embedded GPHY
-
-- reg : Offset of the GPHY firmware register in the RCU
- register range
-- resets : list of resets of the embedded GPHY
-- reset-names : list of names of the resets
-
-Example:
-
-Ethernet switch on the VRX200 SoC:
-
-switch@e108000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "lantiq,xrx200-gswip";
- reg = < 0xe108000 0x3100 /* switch */
- 0xe10b100 0xd8 /* mdio */
- 0xe10b1d8 0x130 /* mii */
- >;
- dsa,member = <0 0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- label = "lan3";
- phy-mode = "rgmii";
- phy-handle = <&phy0>;
- };
-
- port@1 {
- reg = <1>;
- label = "lan4";
- phy-mode = "rgmii";
- phy-handle = <&phy1>;
- };
-
- port@2 {
- reg = <2>;
- label = "lan2";
- phy-mode = "internal";
- phy-handle = <&phy11>;
- };
-
- port@4 {
- reg = <4>;
- label = "lan1";
- phy-mode = "internal";
- phy-handle = <&phy13>;
- };
-
- port@5 {
- reg = <5>;
- label = "wan";
- phy-mode = "rgmii";
- phy-handle = <&phy5>;
- };
-
- port@6 {
- reg = <0x6>;
- ethernet = <&eth0>;
- };
- };
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "lantiq,xrx200-mdio";
- reg = <0>;
-
- phy0: ethernet-phy@0 {
- reg = <0x0>;
- };
- phy1: ethernet-phy@1 {
- reg = <0x1>;
- };
- phy5: ethernet-phy@5 {
- reg = <0x5>;
- };
- phy11: ethernet-phy@11 {
- reg = <0x11>;
- };
- phy13: ethernet-phy@13 {
- reg = <0x13>;
- };
- };
-
- gphy-fw {
- compatible = "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw";
- lantiq,rcu = <&rcu0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- gphy@20 {
- reg = <0x20>;
-
- resets = <&reset0 31 30>;
- reset-names = "gphy";
- };
-
- gphy@68 {
- reg = <0x68>;
-
- resets = <&reset0 29 28>;
- reset-names = "gphy";
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell,mv88e6060.yaml b/Documentation/devicetree/bindings/net/dsa/marvell,mv88e6060.yaml
new file mode 100644
index 000000000000..4f1adf00431a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/marvell,mv88e6060.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6060.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MV88E6060 DSA switch
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+
+description:
+ The Marvell MV88E6060 switch has been produced and sold by Marvell
+ since at least 2008. The switch has one pin ADDR4 that controls the
+ MDIO address of the switch to be 0x10 or 0x00, and on the MDIO bus
+ connected to the switch, the PHYs inside the switch appear as
+ independent devices on address 0x00-0x04 or 0x10-0x14, so in difference
+ from many other DSA switches this switch does not have an internal
+ MDIO bus for the PHY devices.
+
+properties:
+ compatible:
+ const: marvell,mv88e6060
+ description:
+ The MV88E6060 is the oldest Marvell DSA switch product, and
+ as such a bit limited in features compared to later hardware.
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ GPIO to be used to reset the whole device
+ maxItems: 1
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@16 {
+ compatible = "marvell,mv88e6060";
+ reg = <16>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ ethernet-port@5 {
+ reg = <5>;
+ phy-mode = "rev-mii";
+ ethernet = <&ethc>;
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell,mv88e6xxx.yaml b/Documentation/devicetree/bindings/net/dsa/marvell,mv88e6xxx.yaml
new file mode 100644
index 000000000000..19f15bdd1c97
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/marvell,mv88e6xxx.yaml
@@ -0,0 +1,337 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MV88E6xxx DSA switch family
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+
+description:
+ The Marvell MV88E6xxx switch series has been produced and sold
+ by Marvell since at least 2008. The switch has a few compatibles which
+ just indicate the base address of the switch, then operating systems
+ can investigate switch ID registers to find out which actual version
+ of the switch it is dealing with.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - marvell,mv88e6085
+ - marvell,mv88e6190
+ - marvell,mv88e6250
+ description: |
+ marvell,mv88e6085: This switch uses base address 0x10.
+ This switch and its siblings will be autodetected from
+ ID registers found in the switch, so only "marvell,mv88e6085" should be
+ specified. This includes the following list of MV88Exxxx switches:
+ 6085, 6095, 6097, 6123, 6131, 6141, 6161, 6165, 6171, 6172, 6175, 6176,
+ 6185, 6240, 6320, 6321, 6341, 6350, 6351, 6352
+ marvell,mv88e6190: This switch uses base address 0x00.
+ This switch and its siblings will be autodetected from
+ ID registers found in the switch, so only "marvell,mv88e6190" should be
+ specified. This includes the following list of MV88Exxxx switches:
+ 6190, 6190X, 6191, 6290, 6361, 6390, 6390X
+ marvell,mv88e6250: This switch uses base address 0x08 or 0x18.
+ This switch and its siblings will be autodetected from
+ ID registers found in the switch, so only "marvell,mv88e6250" should be
+ specified. This includes the following list of MV88Exxxx switches:
+ 6220, 6250
+ - items:
+ - const: marvell,turris-mox-mv88e6085
+ - const: marvell,mv88e6085
+ - items:
+ - const: marvell,turris-mox-mv88e6190
+ - const: marvell,mv88e6190
+
+ reg:
+ maxItems: 1
+
+ eeprom-length:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Set to the length of an EEPROM connected to the switch. Must be
+ set if the switch can not detect the presence and/or size of a connected
+ EEPROM, otherwise optional.
+
+ reset-gpios:
+ description:
+ GPIO to be used to reset the whole device
+ maxItems: 1
+
+ interrupts:
+ description: The switch provides an external interrupt line, but it is
+ not always used by target systems.
+ maxItems: 1
+
+ interrupt-controller:
+ description: The switch has an internal interrupt controller used by
+ the different sub-blocks.
+
+ '#interrupt-cells':
+ description: The internal interrupt controller only supports triggering
+ on active high level interrupts so the second cell must alway be set to
+ IRQ_TYPE_LEVEL_HIGH.
+ const: 2
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ description: Marvell MV88E6xxx switches have an varying combination of
+ internal and external MDIO buses, in some cases a combined bus that
+ can be used both internally and externally. This node is for the
+ primary bus, used internally and sometimes also externally.
+
+ mdio-external:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ description: Marvell MV88E6xxx switches that have a separate external
+ MDIO bus use this port to access external components on the MDIO bus.
+
+ properties:
+ compatible:
+ const: marvell,mv88e6xxx-mdio-external
+
+ required:
+ - compatible
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@0 {
+ compatible = "marvell,mv88e6085";
+ reg = <0>;
+ reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sw_phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ sw_phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ sw_phy2: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+
+ sw_phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan4";
+ phy-handle = <&sw_phy0>;
+ phy-mode = "internal";
+ };
+
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan3";
+ phy-handle = <&sw_phy1>;
+ phy-mode = "internal";
+ };
+
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan2";
+ phy-handle = <&sw_phy2>;
+ phy-mode = "internal";
+ };
+
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan1";
+ phy-handle = <&sw_phy3>;
+ phy-mode = "internal";
+ };
+
+ ethernet-port@5 {
+ reg = <5>;
+ ethernet = <&fec>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@0 {
+ compatible = "marvell,mv88e6190";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&switch_interrupt_pins>;
+ pinctrl-names = "default";
+ reg = <0>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ switch0phy2: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+
+ switch0phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+
+ switch0phy4: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+
+ switch0phy5: ethernet-phy@5 {
+ reg = <0x5>;
+ };
+
+ switch0phy6: ethernet-phy@6 {
+ reg = <0x6>;
+ };
+
+ switch0phy7: ethernet-phy@7 {
+ reg = <0x7>;
+ };
+
+ switch0phy8: ethernet-phy@8 {
+ reg = <0x8>;
+ };
+ };
+
+ mdio-external {
+ compatible = "marvell,mv88e6xxx-mdio-external";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy1: ethernet-phy@b {
+ reg = <0xb>;
+ compatible = "ethernet-phy-ieee802.3-c45";
+ };
+
+ phy2: ethernet-phy@c {
+ reg = <0xc>;
+ compatible = "ethernet-phy-ieee802.3-c45";
+ };
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ ethernet = <&eth0>;
+ phy-mode = "rgmii";
+ reg = <0>;
+
+ fixed-link {
+ full-duplex;
+ pause;
+ speed = <1000>;
+ };
+ };
+
+ ethernet-port@1 {
+ label = "lan1";
+ phy-handle = <&switch0phy1>;
+ reg = <1>;
+ };
+
+ ethernet-port@2 {
+ label = "lan2";
+ phy-handle = <&switch0phy2>;
+ reg = <2>;
+ };
+
+ ethernet-port@3 {
+ label = "lan3";
+ phy-handle = <&switch0phy3>;
+ reg = <3>;
+ };
+
+ ethernet-port@4 {
+ label = "lan4";
+ phy-handle = <&switch0phy4>;
+ reg = <4>;
+ };
+
+ ethernet-port@5 {
+ label = "lan5";
+ phy-handle = <&switch0phy5>;
+ reg = <5>;
+ };
+
+ ethernet-port@6 {
+ label = "lan6";
+ phy-handle = <&switch0phy6>;
+ reg = <6>;
+ };
+
+ ethernet-port@7 {
+ label = "lan7";
+ phy-handle = <&switch0phy7>;
+ reg = <7>;
+ };
+
+ ethernet-port@8 {
+ label = "lan8";
+ phy-handle = <&switch0phy8>;
+ reg = <8>;
+ };
+
+ ethernet-port@9 {
+ /* 88X3310P external phy */
+ label = "lan9";
+ phy-handle = <&phy1>;
+ phy-mode = "xaui";
+ reg = <9>;
+ };
+
+ ethernet-port@a {
+ /* 88X3310P external phy */
+ label = "lan10";
+ phy-handle = <&phy2>;
+ phy-mode = "xaui";
+ reg = <0xa>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
deleted file mode 100644
index 2363b412410c..000000000000
--- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
+++ /dev/null
@@ -1,109 +0,0 @@
-Marvell DSA Switch Device Tree Bindings
----------------------------------------
-
-WARNING: This binding is currently unstable. Do not program it into a
-FLASH never to be changed again. Once this binding is stable, this
-warning will be removed.
-
-If you need a stable binding, use the old dsa.txt binding.
-
-Marvell Switches are MDIO devices. The following properties should be
-placed as a child node of an mdio device.
-
-The properties described here are those specific to Marvell devices.
-Additional required and optional properties can be found in dsa.txt.
-
-The compatibility string is used only to find an identification register,
-which is at a different MDIO base address in different switch families.
-- "marvell,mv88e6085" : Switch has base address 0x10. Use with models:
- 6085, 6095, 6097, 6123, 6131, 6141, 6161, 6165,
- 6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321,
- 6341, 6350, 6351, 6352
-- "marvell,mv88e6190" : Switch has base address 0x00. Use with models:
- 6190, 6190X, 6191, 6290, 6390, 6390X
-- "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model:
- 6220, 6250
-
-Required properties:
-- compatible : Should be one of "marvell,mv88e6085",
- "marvell,mv88e6190" or "marvell,mv88e6250" as
- indicated above
-- reg : Address on the MII bus for the switch.
-
-Optional properties:
-
-- reset-gpios : Should be a gpio specifier for a reset line
-- interrupts : Interrupt from the switch
-- interrupt-controller : Indicates the switch is itself an interrupt
- controller. This is used for the PHY interrupts.
-#interrupt-cells = <2> : Controller uses two cells, number and flag
-- eeprom-length : Set to the length of an EEPROM connected to the
- switch. Must be set if the switch can not detect
- the presence and/or size of a connected EEPROM,
- otherwise optional.
-- mdio : Container of PHY and devices on the switches MDIO
- bus.
-- mdio? : Container of PHYs and devices on the external MDIO
- bus. The node must contains a compatible string of
- "marvell,mv88e6xxx-mdio-external"
-
-Example:
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <&gpio0>;
- interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- switch0: switch@0 {
- compatible = "marvell,mv88e6085";
- reg = <0>;
- reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- switch1phy0: switch1phy0@0 {
- reg = <0>;
- interrupt-parent = <&switch0>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
- };
- };
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <&gpio0>;
- interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- switch0: switch@0 {
- compatible = "marvell,mv88e6190";
- reg = <0>;
- reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- switch1phy0: switch1phy0@0 {
- reg = <0>;
- interrupt-parent = <&switch0>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
-
- mdio1 {
- compatible = "marvell,mv88e6xxx-mdio-external";
- #address-cells = <1>;
- #size-cells = <0>;
- switch1phy9: switch1phy0@9 {
- reg = <9>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
index f2e9ff3f580b..815a90808901 100644
--- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
@@ -11,69 +11,66 @@ maintainers:
- Landen Chao <Landen.Chao@mediatek.com>
- DENG Qingfang <dqfext@gmail.com>
- Sean Wang <sean.wang@mediatek.com>
+ - Daniel Golle <daniel@makrotopia.org>
description: |
- There are two versions of MT7530, standalone and in a multi-chip module.
+ There are three versions of MT7530, standalone, in a multi-chip module and
+ built-into a SoC.
MT7530 is a part of the multi-chip module in MT7620AN, MT7620DA, MT7620DAN,
MT7620NN, MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs.
- MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs
+ The MT7988 SoC comes with a built-in switch similar to MT7531 as well as four
+ Gigabit Ethernet PHYs. The switch registers are directly mapped into the SoC's
+ memory map rather than using MDIO. The switch has an internally connected 10G
+ CPU port and 4 user ports connected to the built-in Gigabit Ethernet PHYs.
+
+ The MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has 10/100 PHYs
and the switch registers are directly mapped into SoC's memory map rather than
- using MDIO. The DSA driver currently doesn't support this.
+ using MDIO. The DSA driver currently doesn't support MT7620 variants.
There is only the standalone version of MT7531.
- Port 5 on MT7530 has got various ways of configuration.
-
- For standalone MT7530:
+ Port 5 on MT7530 supports various configurations:
- Port 5 can be used as a CPU port.
- - PHY 0 or 4 of the switch can be muxed to connect to the gmac of the SoC
- which port 5 is wired to. Usually used for connecting the wan port
- directly to the CPU to achieve 2 Gbps routing in total.
+ - PHY 0 or 4 of the switch can be muxed to gmac5 of the switch. Therefore,
+ the gmac of the SoC which is wired to port 5 can connect to the PHY.
+ This is usually used for connecting the wan port directly to the CPU to
+ achieve 2 Gbps routing in total.
- The driver looks up the reg on the ethernet-phy node which the phy-handle
- property refers to on the gmac node to mux the specified phy.
+ The driver looks up the reg on the ethernet-phy node, which the phy-handle
+ property on the gmac node refers to, to mux the specified phy.
The driver requires the gmac of the SoC to have "mediatek,eth-mac" as the
- compatible string and the reg must be 1. So, for now, only gmac1 of an
+ compatible string and the reg must be 1. So, for now, only gmac1 of a
MediaTek SoC can benefit this. Banana Pi BPI-R2 suits this.
- Check out example 5 for a similar configuration.
-
- - Port 5 can be wired to an external phy. Port 5 becomes a DSA slave.
- Check out example 7 for a similar configuration.
-
- For multi-chip module MT7530:
-
- - Port 5 can be used as a CPU port.
-
- - PHY 0 or 4 of the switch can be muxed to connect to gmac1 of the SoC.
- Usually used for connecting the wan port directly to the CPU to achieve 2
- Gbps routing in total.
-
- The driver looks up the reg on the ethernet-phy node which the phy-handle
- property refers to on the gmac node to mux the specified phy.
For the MT7621 SoCs, rgmii2 group must be claimed with rgmii2 function.
+
Check out example 5.
- - In case of an external phy wired to gmac1 of the SoC, port 5 must not be
- enabled.
+ - For the multi-chip module MT7530, in case of an external phy wired to
+ gmac1 of the SoC, port 5 must not be enabled.
In case of muxing PHY 0 or 4, the external phy must not be enabled.
For the MT7621 SoCs, rgmii2 group must be claimed with rgmii2 function.
+
Check out example 6.
- - Port 5 can be muxed to an external phy. Port 5 becomes a DSA slave.
- The external phy must be wired TX to TX to gmac1 of the SoC for this to
- work. Ubiquiti EdgeRouter X SFP is wired this way.
+ - Port 5 can be wired to an external phy. Port 5 becomes a DSA user port.
- Muxing PHY 0 or 4 won't work when the external phy is connected TX to TX.
+ For the multi-chip module MT7530, the external phy must be wired TX to TX
+ to gmac1 of the SoC for this to work. Ubiquiti EdgeRouter X SFP is wired
+ this way.
+
+ For the multi-chip module MT7530, muxing PHY 0 or 4 won't work when the
+ external phy is connected TX to TX.
For the MT7621 SoCs, rgmii2 group must be claimed with gpio function.
+
Check out example 7.
properties:
@@ -91,6 +88,18 @@ properties:
Multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs
const: mediatek,mt7621
+ - description:
+ Built-in switch of the MT7988 SoC
+ const: mediatek,mt7988-switch
+
+ - description:
+ Built-in switch of the Airoha EN7581 SoC
+ const: airoha,en7581-switch
+
+ - description:
+ Built-in switch of the Airoha AN7583 SoC
+ const: airoha,an7583-switch
+
reg:
maxItems: 1
@@ -103,7 +112,7 @@ properties:
gpio-controller:
type: boolean
- description:
+ description: |
If defined, LED controller of the MT7530 switch will run on GPIO mode.
There are 15 controllable pins.
@@ -122,11 +131,21 @@ properties:
maxItems: 1
io-supply:
- description:
+ description: |
Phandle to the regulator node necessary for the I/O power.
See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt for
details for the regulator setup on these boards.
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ mediatek,pio:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle pointing to the mediatek pinctrl node.
+
mediatek,mcm:
type: boolean
description:
@@ -134,7 +153,7 @@ properties:
switch is a part of the multi-chip module.
reset-gpios:
- description:
+ description: |
GPIO to reset the switch. Use this if mediatek,mcm is not used.
This property is optional because some boards share the reset line with
other components which makes it impossible to probe the switch if the
@@ -153,13 +172,12 @@ properties:
patternProperties:
"^(ethernet-)?ports$":
type: object
+ additionalProperties: true
patternProperties:
- "^(ethernet-)?port@[0-9]+$":
+ "^(ethernet-)?port@[0-6]$":
type: object
- description: Ethernet switch ports
-
- unevaluatedProperties: false
+ additionalProperties: true
properties:
reg:
@@ -168,7 +186,6 @@ patternProperties:
for user ports.
allOf:
- - $ref: dsa-port.yaml#
- if:
required: [ ethernet ]
then:
@@ -183,11 +200,23 @@ required:
- reg
$defs:
+ builtin-dsa-port:
+ patternProperties:
+ "^(ethernet-)?ports$":
+ patternProperties:
+ "^(ethernet-)?port@[0-6]$":
+ if:
+ required: [ ethernet ]
+ then:
+ properties:
+ phy-mode:
+ const: internal
+
mt7530-dsa-port:
patternProperties:
"^(ethernet-)?ports$":
patternProperties:
- "^(ethernet-)?port@[0-9]+$":
+ "^(ethernet-)?port@[0-6]$":
if:
required: [ ethernet ]
then:
@@ -213,7 +242,7 @@ $defs:
patternProperties:
"^(ethernet-)?ports$":
patternProperties:
- "^(ethernet-)?port@[0-9]+$":
+ "^(ethernet-)?port@[0-6]$":
if:
required: [ ethernet ]
then:
@@ -238,7 +267,7 @@ $defs:
- sgmii
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- if:
required:
- mediatek,mcm
@@ -282,6 +311,20 @@ allOf:
required:
- mediatek,mcm
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt7988-switch
+ - airoha,en7581-switch
+ - airoha,an7583-switch
+ then:
+ $ref: "#/$defs/builtin-dsa-port"
+ properties:
+ gpio-controller: false
+ mediatek,mcm: false
+ reset-names: false
+
unevaluatedProperties: false
examples:
@@ -605,7 +648,7 @@ examples:
label = "lan4";
};
- /* Commented out, phy4 is muxed to gmac1.
+ /* Commented out, phy4 is connected to gmac1.
port@4 {
reg = <4>;
label = "wan";
diff --git a/Documentation/devicetree/bindings/net/dsa/micrel,ks8995.yaml b/Documentation/devicetree/bindings/net/dsa/micrel,ks8995.yaml
new file mode 100644
index 000000000000..854808ff5ad5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/micrel,ks8995.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/micrel,ks8995.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Micrel KS8995 Family DSA Switches
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ The Micrel KS8995 DSA Switches are 100 Mbit switches that were produced in
+ the early-to-mid 2000s. The chip features a CPU port and four outgoing ports,
+ each with an internal PHY. The chip itself is managed over SPI, but all the
+ PHYs need to be accessed from an external MDIO channel.
+
+ Further, a fifth PHY is available and can be used separately from the switch
+ fabric, connected to an external MII interface name MII-P5. This is
+ unrelated from the CPU-facing port 5 which is used for DSA MII traffic.
+
+properties:
+ compatible:
+ enum:
+ - micrel,ks8995
+ - micrel,ksz8795
+ - micrel,ksz8864
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO to be used to reset the whole device
+ maxItems: 1
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995";
+ reg = <0>;
+ spi-max-frequency = <25000000>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ ethernet-port@4 {
+ reg = <4>;
+ ethernet = <&mac2>;
+ phy-mode = "mii";
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* The WAN port connected on MII-P5 */
+ ethernet-port@1000 {
+ reg = <0x00001000 0x1000>;
+ label = "wan";
+ phy-mode = "mii";
+ phy-handle = <&phy5>;
+ };
+
+ mac2: ethernet-port@2000 {
+ reg = <0x00002000 0x1000>;
+ phy-mode = "mii";
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* LAN PHYs 1-4 accessible over external MDIO */
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ phy2: ethernet-phy@2 {
+ reg = <2>;
+ };
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ };
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+ /* WAN PHY accessible over external MDIO */
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
index 4da75b1f9533..a8c8009414ae 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -10,20 +10,19 @@ maintainers:
- Marek Vasut <marex@denx.de>
- Woojung Huh <Woojung.Huh@microchip.com>
-allOf:
- - $ref: dsa.yaml#
- - $ref: /schemas/spi/spi-peripheral-props.yaml#
-
properties:
# See Documentation/devicetree/bindings/net/dsa/dsa.yaml for a list of additional
# required and optional properties.
compatible:
enum:
+ - microchip,ksz8463
- microchip,ksz8765
- microchip,ksz8794
- microchip,ksz8795
- microchip,ksz8863
+ - microchip,ksz8864 # 4-port version of KSZ8895 family switch
- microchip,ksz8873
+ - microchip,ksz8895 # 5-port version of KSZ8895 family switch
- microchip,ksz9477
- microchip,ksz9897
- microchip,ksz9896
@@ -32,12 +31,23 @@ properties:
- microchip,ksz9893
- microchip,ksz9563
- microchip,ksz8563
+ - microchip,ksz8567
+ - microchip,lan9646
+
+ pinctrl-names:
+ items:
+ - const: default
+ - const: reset
+ description:
+ Used during reset for strap configuration.
reset-gpios:
description:
Should be a gpio specifier for a reset line.
maxItems: 1
+ wakeup-source: true
+
microchip,synclko-125:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -49,10 +59,106 @@ properties:
Set if the output SYNCLKO clock should be disabled. Do not mix with
microchip,synclko-125.
+ microchip,pme-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates if the PME pin polarity is active-high.
+
+ microchip,io-drive-strength-microamp:
+ description:
+ IO Pad Drive Strength
+ enum: [8000, 16000]
+ default: 16000
+
+ microchip,hi-drive-strength-microamp:
+ description:
+ High Speed Drive Strength. Controls drive strength of GMII / RGMII /
+ MII / RMII (except TX_CLK/REFCLKI, COL and CRS) and CLKO_25_125 lines.
+ enum: [2000, 4000, 8000, 12000, 16000, 20000, 24000, 28000]
+ default: 24000
+
+ microchip,lo-drive-strength-microamp:
+ description:
+ Low Speed Drive Strength. Controls drive strength of TX_CLK / REFCLKI,
+ COL, CRS, LEDs, PME_N, NTRP_N, SDO and SDI/SDA/MDIO lines.
+ enum: [2000, 4000, 8000, 12000, 16000, 20000, 24000, 28000]
+ default: 8000
+
+ interrupts:
+ maxItems: 1
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ properties:
+ mdio-parent-bus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle pointing to the MDIO bus controller connected to the
+ secondary MDIO interface. This property should be used when
+ the internal MDIO bus is accessed via a secondary MDIO
+ interface rather than the primary management interface.
+
+ patternProperties:
+ "^ethernet-phy@[0-9a-f]$":
+ type: object
+ $ref: /schemas/net/ethernet-phy.yaml#
+ unevaluatedProperties: false
+ description:
+ Integrated PHY node
+
required:
- compatible
- reg
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - microchip,ksz8863
+ - microchip,ksz8873
+ then:
+ $ref: dsa.yaml#/$defs/ethernet-ports
+ else:
+ patternProperties:
+ "^(ethernet-)?ports$":
+ patternProperties:
+ "^(ethernet-)?port@[0-2]$":
+ $ref: dsa-port.yaml#
+ unevaluatedProperties: false
+ properties:
+ microchip,rmii-clk-internal:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ When ksz88x3 is acting as clock provier (via REFCLKO) it
+ can select between internal and external RMII reference
+ clock. Internal reference clock means that the clock for
+ the RMII of ksz88x3 is provided by the ksz88x3 internally
+ and the REFCLKI pin is unconnected. For the external
+ reference clock, the clock needs to be fed back to ksz88x3
+ via REFCLKI.
+ If microchip,rmii-clk-internal is set, ksz88x3 will provide
+ rmii reference clock internally, otherwise reference clock
+ should be provided externally.
+ dependencies:
+ microchip,rmii-clk-internal: [ethernet]
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,ksz8463
+ then:
+ properties:
+ straps-rxd-gpios:
+ description:
+ RXD0 and RXD1 pins, used to select SPI as bus interface.
+ minItems: 2
+ maxItems: 2
+
unevaluatedProperties: false
examples:
@@ -67,13 +173,12 @@ examples:
};
};
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-0 = <&pinctrl_spi_ksz>;
cs-gpios = <&pioC 25 0>;
- id = <1>;
ksz9477: switch@0 {
compatible = "microchip,ksz9477";
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
index 630bf0f8294b..9973d64f15a7 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/net/dsa/microchip,lan937x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LAN937x Ethernet Switch Series Tree Bindings
+title: LAN937x Ethernet Switch Series
maintainers:
- UNGLinuxDriver@microchip.com
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
properties:
compatible:
@@ -37,8 +37,9 @@ properties:
patternProperties:
"^(ethernet-)?ports$":
+ additionalProperties: true
patternProperties:
- "^(ethernet-)?port@[0-9]+$":
+ "^(ethernet-)?port@[0-7]$":
allOf:
- if:
properties:
diff --git a/Documentation/devicetree/bindings/net/dsa/motorcomm,yt921x.yaml b/Documentation/devicetree/bindings/net/dsa/motorcomm,yt921x.yaml
new file mode 100644
index 000000000000..33a6552e46fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/motorcomm,yt921x.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/motorcomm,yt921x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorcomm YT921x Ethernet switch family
+
+maintainers:
+ - David Yang <mmyangfl@gmail.com>
+
+description: |
+ The Motorcomm YT921x series is a family of Ethernet switches with up to 8
+ internal GbE PHYs and up to 2 GMACs, including:
+
+ - YT9215S / YT9215RB / YT9215SC: 5 GbE PHYs (Port 0-4) + 2 GMACs (Port 8-9)
+ - YT9213NB: 2 GbE PHYs (Port 1/3) + 1 GMAC (Port 9)
+ - YT9214NB: 2 GbE PHYs (Port 1/3) + 2 GMACs (Port 8-9)
+ - YT9218N: 8 GbE PHYs (Port 0-7)
+ - YT9218MB: 8 GbE PHYs (Port 0-7) + 2 GMACs (Port 8-9)
+
+ Any port can be used as the CPU port.
+
+properties:
+ compatible:
+ const: motorcomm,yt9215
+
+ reg:
+ enum: [0x0, 0x1d]
+
+ reset-gpios:
+ maxItems: 1
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ description:
+ Internal MDIO bus for the internal GbE PHYs. PHY 0-7 are used for Port
+ 0-7 respectively.
+
+ mdio-external:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ description:
+ External MDIO bus to access external components. External PHYs for GMACs
+ (Port 8-9) are expected to be connected to the external MDIO bus in
+ vendor's reference design, but that is not a hard limitation from the
+ chip.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@1d {
+ compatible = "motorcomm,yt9215";
+ /* default 0x1d, alternate 0x0 */
+ reg = <0x1d>;
+ reset-gpios = <&tlmm 39 GPIO_ACTIVE_LOW>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sw_phy0: phy@0 {
+ reg = <0x0>;
+ };
+
+ sw_phy1: phy@1 {
+ reg = <0x1>;
+ };
+
+ sw_phy2: phy@2 {
+ reg = <0x2>;
+ };
+
+ sw_phy3: phy@3 {
+ reg = <0x3>;
+ };
+
+ sw_phy4: phy@4 {
+ reg = <0x4>;
+ };
+ };
+
+ mdio-external {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy1: phy@b {
+ reg = <0xb>;
+ };
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan1";
+ phy-mode = "internal";
+ phy-handle = <&sw_phy0>;
+ };
+
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan2";
+ phy-mode = "internal";
+ phy-handle = <&sw_phy1>;
+ };
+
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan3";
+ phy-mode = "internal";
+ phy-handle = <&sw_phy2>;
+ };
+
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan4";
+ phy-mode = "internal";
+ phy-handle = <&sw_phy3>;
+ };
+
+ ethernet-port@4 {
+ reg = <4>;
+ label = "lan5";
+ phy-mode = "internal";
+ phy-handle = <&sw_phy4>;
+ };
+
+ /* CPU port */
+ ethernet-port@8 {
+ reg = <8>;
+ phy-mode = "2500base-x";
+ ethernet = <&eth0>;
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ };
+ };
+
+ /* if external phy is connected to a MAC */
+ ethernet-port@9 {
+ reg = <9>;
+ label = "wan";
+ phy-mode = "rgmii-id";
+ phy-handle = <&phy1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml b/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
index 8d93ed9c172c..fe02d05196e4 100644
--- a/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/dsa/mscc,ocelot.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip Ocelot Switch Family Device Tree Bindings
+title: Microchip Ocelot Switch Family
maintainers:
- Vladimir Oltean <vladimir.oltean@nxp.com>
@@ -78,7 +78,7 @@ required:
- reg
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index 1e26d876d146..607b7fe8d28e 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/dsa/nxp,sja1105.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP SJA1105 Automotive Ethernet Switch Family Device Tree Bindings
+title: NXP SJA1105 Automotive Ethernet Switch Family
description:
The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944.pdf) of at
@@ -12,10 +12,6 @@ description:
cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed
depends on the SPI bus master driver.
-allOf:
- - $ref: "dsa.yaml#"
- - $ref: /schemas/spi/spi-peripheral-props.yaml#
-
maintainers:
- Vladimir Oltean <vladimir.oltean@nxp.com>
@@ -36,6 +32,21 @@ properties:
reg:
maxItems: 1
+ reset-gpios:
+ description:
+ A GPIO connected to the active-low RST_N pin of the SJA1105. Note that
+ reset of this chip is performed via SPI and the RST_N pin must be wired
+ to satisfy the power-up sequence documented in "SJA1105PQRS Application
+ Hints" (AH1704) sec. 2.4.4. Connecting the SJA1105 RST_N pin to a GPIO is
+ therefore discouraged.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ spi-cpha: true
+ spi-cpol: true
+
# Optional container node for the 2 internal MDIO buses of the SJA1110
# (one for the internal 100base-T1 PHYs and the other for the single
# 100base-TX PHY). The "reg" property does not have physical significance.
@@ -44,6 +55,7 @@ properties:
# PHY 1.
mdios:
type: object
+ additionalProperties: false
properties:
'#address-cells':
@@ -75,8 +87,9 @@ properties:
patternProperties:
"^(ethernet-)?ports$":
+ additionalProperties: true
patternProperties:
- "^(ethernet-)?port@[0-9]+$":
+ "^(ethernet-)?port@[0-9]$":
allOf:
- if:
properties:
@@ -109,6 +122,30 @@ $defs:
1860, 1880, 1900, 1920, 1940, 1960, 1980, 2000, 2020, 2040, 2060, 2080,
2100, 2120, 2140, 2160, 2180, 2200, 2220, 2240, 2260]
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - nxp,sja1105e
+ - nxp,sja1105p
+ - nxp,sja1105q
+ - nxp,sja1105r
+ - nxp,sja1105s
+ - nxp,sja1105t
+ then:
+ properties:
+ spi-cpol: false
+ required:
+ - spi-cpha
+ else:
+ properties:
+ spi-cpha: false
+ required:
+ - spi-cpol
+
unevaluatedProperties: false
examples:
@@ -120,6 +157,7 @@ examples:
ethernet-switch@1 {
reg = <0x1>;
compatible = "nxp,sja1105t";
+ spi-cpha;
ethernet-ports {
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/net/dsa/qca,ar9331.yaml b/Documentation/devicetree/bindings/net/dsa/qca,ar9331.yaml
new file mode 100644
index 000000000000..fd9ddc59d38c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/qca,ar9331.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/qca,ar9331.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros AR9331 built-in switch
+
+maintainers:
+ - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description:
+ Qualcomm Atheros AR9331 is a switch built-in to Atheros AR9331 WiSoC and
+ addressable over internal MDIO bus. All PHYs are built-in as well.
+
+properties:
+ compatible:
+ const: qca,ar9331-switch
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ properties:
+ interrupt-parent: true
+
+ patternProperties:
+ '(ethernet-)?phy@[0-4]+$':
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ reg: true
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: switch
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - mdio
+ - ports
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch10: switch@10 {
+ compatible = "qca,ar9331-switch";
+ reg = <0x10>;
+
+ interrupt-parent = <&miscintc>;
+ interrupts = <12>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ resets = <&rst 8>;
+ reset-names = "switch";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0x0>;
+ ethernet = <&eth1>;
+
+ phy-mode = "gmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@1 {
+ reg = <0x1>;
+ phy-handle = <&phy_port0>;
+ phy-mode = "internal";
+ };
+
+ port@2 {
+ reg = <0x2>;
+ phy-handle = <&phy_port1>;
+ phy-mode = "internal";
+ };
+
+ port@3 {
+ reg = <0x3>;
+ phy-handle = <&phy_port2>;
+ phy-mode = "internal";
+ };
+
+ port@4 {
+ reg = <0x4>;
+ phy-handle = <&phy_port3>;
+ phy-mode = "internal";
+ };
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ interrupt-parent = <&switch10>;
+
+ phy_port0: ethernet-phy@0 {
+ reg = <0x0>;
+ interrupts = <0>;
+ };
+
+ phy_port1: ethernet-phy@1 {
+ reg = <0x1>;
+ interrupts = <0>;
+ };
+
+ phy_port2: ethernet-phy@2 {
+ reg = <0x2>;
+ interrupts = <0>;
+ };
+
+ phy_port3: ethernet-phy@3 {
+ reg = <0x3>;
+ interrupts = <0>;
+ };
+
+ phy_port4: ethernet-phy@4 {
+ reg = <0x4>;
+ interrupts = <0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml
index 978162df51f7..167398ab253a 100644
--- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml
@@ -18,6 +18,8 @@ description:
PHY it is connected to. In this config, an internal mdio-bus is registered and
the MDIO master is used for communication. Mixed external and internal
mdio-bus configurations are not supported by the hardware.
+ Each phy has at most 3 LEDs connected and can be declared
+ using the standard LEDs structure.
properties:
compatible:
@@ -66,15 +68,12 @@ properties:
With the legacy mapping the reg corresponding to the internal
mdio is the switch reg with an offset of -1.
+$ref: dsa.yaml#
+
patternProperties:
"^(ethernet-)?ports$":
type: object
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
-
+ additionalProperties: true
patternProperties:
"^(ethernet-)?port@[0-6]$":
type: object
@@ -116,11 +115,12 @@ required:
- compatible
- reg
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
mdio {
#address-cells = <1>;
@@ -148,8 +148,6 @@ examples:
switch@10 {
compatible = "qca,qca8337";
- #address-cells = <1>;
- #size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
@@ -209,8 +207,6 @@ examples:
switch@10 {
compatible = "qca,qca8337";
- #address-cells = <1>;
- #size-cells = <0>;
reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
reg = <0x10>;
@@ -234,6 +230,25 @@ examples:
label = "lan1";
phy-mode = "internal";
phy-handle = <&internal_phy_port1>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
};
port@2 {
diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
index 1a7d45a8ad66..f348e66fb515 100644
--- a/Documentation/devicetree/bindings/net/dsa/realtek.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek switches for unmanaged switches
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -59,6 +59,9 @@ properties:
description: GPIO to be used to reset the whole device
maxItems: 1
+ resets:
+ maxItems: 1
+
realtek,disable-leds:
type: boolean
description: |
@@ -68,6 +71,8 @@ properties:
interrupt-controller:
type: object
+ additionalProperties: false
+
description: |
This defines an interrupt controller with an IRQ line (typically
a GPIO) that will demultiplex and handle the interrupt from the single
@@ -125,7 +130,6 @@ else:
- mdc-gpios
- mdio-gpios
- mdio
- - reset-gpios
required:
- compatible
@@ -143,7 +147,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
platform {
- switch {
+ ethernet-switch {
compatible = "realtek,rtl8366rb";
/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
@@ -159,35 +163,35 @@ examples:
#interrupt-cells = <1>;
};
- ports {
+ ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
- port@0 {
+ ethernet-port@0 {
reg = <0>;
label = "lan0";
phy-handle = <&phy0>;
};
- port@1 {
+ ethernet-port@1 {
reg = <1>;
label = "lan1";
phy-handle = <&phy1>;
};
- port@2 {
+ ethernet-port@2 {
reg = <2>;
label = "lan2";
phy-handle = <&phy2>;
};
- port@3 {
+ ethernet-port@3 {
reg = <3>;
label = "lan3";
phy-handle = <&phy3>;
};
- port@4 {
+ ethernet-port@4 {
reg = <4>;
label = "wan";
phy-handle = <&phy4>;
};
- port@5 {
+ ethernet-port@5 {
reg = <5>;
ethernet = <&gmac0>;
phy-mode = "rgmii";
@@ -237,7 +241,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
platform {
- switch {
+ ethernet-switch {
compatible = "realtek,rtl8365mb";
mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
@@ -251,30 +255,30 @@ examples:
#interrupt-cells = <1>;
};
- ports {
+ ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
- port@0 {
+ ethernet-port@0 {
reg = <0>;
label = "swp0";
phy-handle = <&ethphy0>;
};
- port@1 {
+ ethernet-port@1 {
reg = <1>;
label = "swp1";
phy-handle = <&ethphy1>;
};
- port@2 {
+ ethernet-port@2 {
reg = <2>;
label = "swp2";
phy-handle = <&ethphy2>;
};
- port@3 {
+ ethernet-port@3 {
reg = <3>;
label = "swp3";
phy-handle = <&ethphy3>;
};
- port@6 {
+ ethernet-port@6 {
reg = <6>;
ethernet = <&fec1>;
phy-mode = "rgmii";
@@ -326,7 +330,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- switch@29 {
+ ethernet-switch@29 {
compatible = "realtek,rtl8365mb";
reg = <29>;
@@ -340,36 +344,36 @@ examples:
#interrupt-cells = <1>;
};
- ports {
+ ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
- port@0 {
+ ethernet-port@0 {
reg = <0>;
label = "lan4";
};
- port@1 {
+ ethernet-port@1 {
reg = <1>;
label = "lan3";
};
- port@2 {
+ ethernet-port@2 {
reg = <2>;
label = "lan2";
};
- port@3 {
+ ethernet-port@3 {
reg = <3>;
label = "lan1";
};
- port@4 {
+ ethernet-port@4 {
reg = <4>;
label = "wan";
};
- port@7 {
+ ethernet-port@7 {
reg = <7>;
ethernet = <&ethernet>;
phy-mode = "rgmii";
diff --git a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
index 7ca9c19a157c..ea285ef3e64f 100644
--- a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
@@ -14,7 +14,7 @@ description: |
handles 4 ports + 1 CPU management port.
allOf:
- - $ref: dsa.yaml#
+ - $ref: dsa.yaml#/$defs/ethernet-ports
properties:
compatible:
@@ -61,23 +61,17 @@ properties:
ethernet-ports:
type: object
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
-
+ additionalProperties: true
patternProperties:
"^(ethernet-)?port@[0-4]$":
type: object
- description: Ethernet switch ports
-
+ additionalProperties: true
properties:
pcs-handle:
+ maxItems: 1
description:
phandle pointing to a PCS sub-node compatible with
renesas,rzn1-miic.yaml#
- $ref: /schemas/types.yaml#/definitions/phandle
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
deleted file mode 100644
index 258bef483673..000000000000
--- a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt
+++ /dev/null
@@ -1,129 +0,0 @@
-Vitesse VSC73xx Switches
-========================
-
-This defines device tree bindings for the Vitesse VSC73xx switch chips.
-The Vitesse company has been acquired by Microsemi and Microsemi has
-been acquired Microchip but retains this vendor branding.
-
-The currently supported switch chips are:
-Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
-Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
-Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
-Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
-
-This switch could have two different management interface.
-
-If SPI interface is used, the device tree node is an SPI device so it must
-reside inside a SPI bus device tree node, see spi/spi-bus.txt
-
-When the chip is connected to a parallel memory bus and work in memory-mapped
-I/O mode, a platform device is used to represent the vsc73xx. In this case it
-must reside inside a platform bus device tree node.
-
-Required properties:
-
-- compatible: must be exactly one of:
- "vitesse,vsc7385"
- "vitesse,vsc7388"
- "vitesse,vsc7395"
- "vitesse,vsc7398"
-- gpio-controller: indicates that this switch is also a GPIO controller,
- see gpio/gpio.txt
-- #gpio-cells: this must be set to <2> and indicates that we are a twocell
- GPIO controller, see gpio/gpio.txt
-
-Optional properties:
-
-- reset-gpios: a handle to a GPIO line that can issue reset of the chip.
- It should be tagged as active low.
-
-Required subnodes:
-
-See net/dsa/dsa.txt for a list of additional required and optional properties
-and subnodes of DSA switches.
-
-Examples:
-
-SPI:
-switch@0 {
- compatible = "vitesse,vsc7395";
- reg = <0>;
- /* Specified for 2.5 MHz or below */
- spi-max-frequency = <2500000>;
- gpio-controller;
- #gpio-cells = <2>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- label = "lan1";
- };
- port@1 {
- reg = <1>;
- label = "lan2";
- };
- port@2 {
- reg = <2>;
- label = "lan3";
- };
- port@3 {
- reg = <3>;
- label = "lan4";
- };
- vsc: port@6 {
- reg = <6>;
- ethernet = <&gmac1>;
- phy-mode = "rgmii";
- fixed-link {
- speed = <1000>;
- full-duplex;
- pause;
- };
- };
- };
-};
-
-Platform:
-switch@2,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "vitesse,vsc7385";
- reg = <0x2 0x0 0x20000>;
- reset-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- label = "lan1";
- };
- port@1 {
- reg = <1>;
- label = "lan2";
- };
- port@2 {
- reg = <2>;
- label = "lan3";
- };
- port@3 {
- reg = <3>;
- label = "lan4";
- };
- vsc: port@6 {
- reg = <6>;
- ethernet = <&enet0>;
- phy-mode = "rgmii";
- fixed-link {
- speed = <1000>;
- full-duplex;
- pause;
- };
- };
- };
-
-};
diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml
new file mode 100644
index 000000000000..51cf574249be
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml
@@ -0,0 +1,194 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/vitesse,vsc73xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Vitesse VSC73xx DSA Switches
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ The Vitesse DSA Switches were produced in the early-to-mid 2000s.
+
+ The Vitesse company has been acquired by Microsemi and Microsemi has
+ been acquired Microchip but the new owner retains this vendor branding.
+
+ The currently supported switch chips are
+ Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
+ Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
+ Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
+ Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
+
+ This switch can use one of two different management interfaces.
+
+ If SPI interface is used, the device tree node is an SPI device so it must
+ reside inside a SPI bus device tree node, see spi/spi-bus.txt
+
+ When the chip is connected to a parallel memory bus and work in memory-mapped
+ I/O mode, a platform device is used to represent the vsc73xx. In this case it
+ must reside inside a platform bus device tree node.
+
+properties:
+ compatible:
+ enum:
+ - vitesse,vsc7385
+ - vitesse,vsc7388
+ - vitesse,vsc7395
+ - vitesse,vsc7398
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+ "#gpio-cells":
+ const: 2
+
+ reset-gpios:
+ description: GPIO to be used to reset the whole device
+ maxItems: 1
+
+allOf:
+ - $ref: dsa.yaml#/$defs/ethernet-ports
+
+patternProperties:
+ "^(ethernet-)?ports$":
+ additionalProperties: true
+ patternProperties:
+ "^(ethernet-)?port@6$":
+ allOf:
+ - if:
+ properties:
+ phy-mode:
+ contains:
+ enum:
+ - rgmii
+ then:
+ properties:
+ rx-internal-delay-ps:
+ $ref: "#/$defs/internal-delay-ps"
+ tx-internal-delay-ps:
+ $ref: "#/$defs/internal-delay-ps"
+
+# This checks if reg is a chipselect so the device is on an SPI
+# bus, the if-clause will fail if reg is a tuple such as for a
+# platform device.
+if:
+ properties:
+ reg:
+ minimum: 0
+ maximum: 256
+then:
+ $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+required:
+ - compatible
+ - reg
+
+$defs:
+ internal-delay-ps:
+ description:
+ Disable tunable delay lines using 0 ps, or enable them and select
+ the phase between 1400 ps and 2000 ps in increments of 300 ps.
+ default: 2000
+ enum:
+ [0, 1400, 1700, 2000]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@0 {
+ compatible = "vitesse,vsc7395";
+ reg = <0>;
+ spi-max-frequency = <2500000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ ethernet-port@6 {
+ reg = <6>;
+ ethernet = <&gmac1>;
+ phy-mode = "rgmii";
+ rx-internal-delay-ps = <0>;
+ tx-internal-delay-ps = <0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+ };
+
+ bus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ethernet-switch@10000000 {
+ compatible = "vitesse,vsc7385";
+ reg = <0x10000000 0x20000>;
+ reset-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+ ethernet-port@1 {
+ reg = <1>;
+ label = "lan2";
+ };
+ ethernet-port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+ ethernet-port@3 {
+ reg = <3>;
+ label = "lan4";
+ };
+ ethernet-port@6 {
+ reg = <6>;
+ ethernet = <&enet0>;
+ rx-internal-delay-ps = <0>;
+ tx-internal-delay-ps = <0>;
+ phy-mode = "rgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml
index 5bd964a46a9d..34fd24ff6a71 100644
--- a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml
+++ b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/engleder,tsnep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TSN endpoint Ethernet MAC binding
+title: TSN endpoint Ethernet MAC
maintainers:
- Gerhard Engleder <gerhard@engleder-embedded.com>
@@ -47,7 +47,7 @@ properties:
nvmem-cells: true
- nvmem-cells-names: true
+ nvmem-cell-names: true
phy-connection-type:
enum:
@@ -62,7 +62,8 @@ properties:
mdio:
type: object
- $ref: "mdio.yaml#"
+ $ref: mdio.yaml#
+ unevaluatedProperties: false
description: optional node for embedded MDIO controller
required:
diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
new file mode 100644
index 000000000000..91e8cd1db67b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/eswin,eic7700-eth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Eswin EIC7700 SOC Eth Controller
+
+maintainers:
+ - Shuang Liang <liangshuang@eswincomputing.com>
+ - Zhi Li <lizhi2@eswincomputing.com>
+ - Shangjuan Wei <weishangjuan@eswincomputing.com>
+
+description:
+ Platform glue layer implementation for STMMAC Ethernet driver.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - eswin,eic7700-qos-eth
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: eswin,eic7700-qos-eth
+ - const: snps,dwmac-5.20
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
+ clocks:
+ items:
+ - description: AXI clock
+ - description: Configuration clock
+ - description: GMAC main clock
+ - description: Tx clock
+
+ clock-names:
+ items:
+ - const: axi
+ - const: cfg
+ - const: stmmaceth
+ - const: tx
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: stmmaceth
+
+ rx-internal-delay-ps:
+ enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+
+ tx-internal-delay-ps:
+ enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+
+ eswin,hsp-sp-csr:
+ description:
+ HSP CSR is to control and get status of different high-speed peripherals
+ (such as Ethernet, USB, SATA, etc.) via register, which can tune
+ board-level's parameters of PHY, etc.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to HSP(High-Speed Peripheral) device
+ - description: Offset of phy control register for internal
+ or external clock selection
+ - description: Offset of AXI clock controller Low-Power request
+ register
+ - description: Offset of register controlling TX/RX clock delay
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - phy-mode
+ - resets
+ - reset-names
+ - rx-internal-delay-ps
+ - tx-internal-delay-ps
+ - eswin,hsp-sp-csr
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@50400000 {
+ compatible = "eswin,eic7700-qos-eth", "snps,dwmac-5.20";
+ reg = <0x50400000 0x10000>;
+ clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
+ <&d0_clock 193>;
+ clock-names = "axi", "cfg", "stmmaceth", "tx";
+ interrupt-parent = <&plic>;
+ interrupts = <61>;
+ interrupt-names = "macirq";
+ phy-mode = "rgmii-id";
+ phy-handle = <&phy0>;
+ resets = <&reset 95>;
+ reset-names = "stmmaceth";
+ rx-internal-delay-ps = <200>;
+ tx-internal-delay-ps = <200>;
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,aal;
+ snps,fixed-burst;
+ snps,tso;
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,blen = <0 0 0 0 16 8 4>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index 4b3c590fcebf..1bafd687dcb1 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/ethernet-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ethernet Controller Generic Binding
+title: Ethernet Controller Common Properties
maintainers:
- David S. Miller <davem@davemloft.net>
@@ -14,33 +14,8 @@ properties:
pattern: "^ethernet(@.*)?$"
label:
- $ref: /schemas/types.yaml#/definitions/string
description: Human readable label on a port of a box.
- local-mac-address:
- description:
- Specifies the MAC address that was assigned to the network device.
- $ref: /schemas/types.yaml#/definitions/uint8-array
- minItems: 6
- maxItems: 6
-
- mac-address:
- description:
- Specifies the MAC address that was last used by the boot
- program; should be used in cases where the MAC address assigned
- to the device by the boot program is different from the
- local-mac-address property.
- $ref: /schemas/types.yaml#/definitions/uint8-array
- minItems: 6
- maxItems: 6
-
- max-frame-size:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- Maximum transfer unit (IEEE defined MTU), rather than the
- maximum frame size (there\'s contradiction in the Devicetree
- Specification).
-
max-speed:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -64,8 +39,10 @@ properties:
# MAC.
- internal
- mii
+ - mii-lite
- gmii
- sgmii
+ - psgmii
- qsgmii
- qusgmii
- tbi
@@ -74,19 +51,17 @@ properties:
- rev-rmii
- moca
- # RX and TX delays are added by the MAC when required
+ # RX and TX delays are provided by the PCB. See below
- rgmii
- # RGMII with internal RX and TX delays provided by the PHY,
- # the MAC should not add the RX or TX delays in this case
+ # RX and TX delays are not provided by the PCB. This is the most
+ # frequent case. See below
- rgmii-id
- # RGMII with internal RX delay provided by the PHY, the MAC
- # should not add an RX delay in this case
+ # TX delay is provided by the PCB. See below
- rgmii-rxid
- # RGMII with internal TX delay provided by the PHY, the MAC
- # should not add an TX delay in this case
+ # RX delay is provided by the PCB. See below
- rgmii-txid
- rtbi
- smii
@@ -103,16 +78,23 @@ properties:
- usxgmii
- 10gbase-r
- 25gbase-r
+ - 10g-qxgmii
phy-mode:
$ref: "#/properties/phy-connection-type"
pcs-handle:
- $ref: /schemas/types.yaml#/definitions/phandle
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
description:
Specifies a reference to a node representing a PCS PHY device on a MDIO
bus to link with an external PHY (phy-handle) if exists.
+ pcs-handle-names:
+ description:
+ The name of each PCS in pcs-handle.
+
phy-handle:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -126,6 +108,11 @@ properties:
$ref: "#/properties/phy-handle"
deprecated: true
+ ptp-timer:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Specifies a reference to a node representing an IEEE 1588 PTP device.
+
rx-fifo-depth:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -190,7 +177,7 @@ properties:
description:
Link speed.
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [10, 100, 1000, 2500, 10000]
+ enum: [10, 100, 1000, 2500, 5000, 10000]
full-duplex:
$ref: /schemas/types.yaml#/definitions/flag
@@ -199,7 +186,7 @@ properties:
duplex is assumed.
pause:
- $ref: /schemas/types.yaml#definitions/flag
+ $ref: /schemas/types.yaml#/definitions/flag
description:
Indicates that pause should be enabled.
@@ -216,7 +203,46 @@ properties:
required:
- speed
+ leds:
+ description:
+ Describes the LEDs associated by Ethernet Controller.
+ These LEDs are not integrated in the PHY and PHY doesn't have any
+ control on them. Ethernet Controller regs are used to control
+ these defined LEDs.
+
+ type: object
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^led@[a-f0-9]+$':
+ $ref: /schemas/leds/common.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+ description:
+ This defines the LED index in the PHY or the MAC. It's really
+ driver dependent and required for ports that define multiple
+ LED for the same port.
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+dependencies:
+ pcs-handle-names: [pcs-handle]
+
allOf:
+ - $ref: /schemas/net/network-class.yaml#
- if:
properties:
phy-mode:
@@ -230,15 +256,100 @@ allOf:
properties:
rx-internal-delay-ps:
description:
- RGMII Receive Clock Delay defined in pico seconds.This is used for
+ RGMII Receive Clock Delay defined in pico seconds. This is used for
controllers that have configurable RX internal delays. If this
property is present then the MAC applies the RX delay.
tx-internal-delay-ps:
description:
- RGMII Transmit Clock Delay defined in pico seconds.This is used for
+ RGMII Transmit Clock Delay defined in pico seconds. This is used for
controllers that have configurable TX internal delays. If this
property is present then the MAC applies the TX delay.
additionalProperties: true
+# Informative
+# ===========
+#
+# 'phy-modes' & 'phy-connection-type' properties 'rgmii', 'rgmii-id',
+# 'rgmii-rxid', and 'rgmii-txid' are frequently used wrongly by
+# developers. This informative section clarifies their usage.
+#
+# The RGMII specification requires a 2ns delay between the data and
+# clock signals on the RGMII bus. How this delay is implemented is not
+# specified.
+#
+# One option is to make the clock traces on the PCB longer than the
+# data traces. A sufficient difference in length can provide the 2ns
+# delay. If both the RX and TX delays are implemented in this manner,
+# 'rgmii' should be used, so indicating the PCB adds the delays.
+#
+# If the PCB does not add these delays via extra long traces,
+# 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',
+# where either the MAC or PHY adds the delay.
+#
+# If only one of the two delays are implemented via extra long clock
+# lines, either 'rgmii-rxid' or 'rgmii-txid' should be used,
+# indicating the MAC or PHY should implement one of the delays
+# internally, while the PCB implements the other delay.
+#
+# Device Tree describes hardware, and in this case, it describes the
+# PCB between the MAC and the PHY, if the PCB implements delays or
+# not.
+#
+# In practice, very few PCBs make use of extra long clock lines. Hence
+# any RGMII phy mode other than 'rgmii-id' is probably wrong, and is
+# unlikely to be accepted during review without details provided in
+# the commit description and comments in the .dts file.
+#
+# When the PCB does not implement the delays, the MAC or PHY must. As
+# such, this is software configuration, and so not described in Device
+# Tree.
+#
+# The following describes how Linux implements the configuration of
+# the MAC and PHY to add these delays when the PCB does not. As stated
+# above, developers often get this wrong, and the aim of this section
+# is reduce the frequency of these errors by Linux developers. Other
+# users of the Device Tree may implement it differently, and still be
+# consistent with both the normative and informative description
+# above.
+#
+# By default in Linux, when using phylib/phylink, the MAC is expected
+# to read the 'phy-mode' from Device Tree, not implement any delays,
+# and pass the value to the PHY. The PHY will then implement delays as
+# specified by the 'phy-mode'. The PHY should always be reconfigured
+# to implement the needed delays, replacing any setting performed by
+# strapping or the bootloader, etc.
+#
+# Experience to date is that all PHYs which implement RGMII also
+# implement the ability to add or not add the needed delays. Hence
+# this default is expected to work in all cases. Ignoring this default
+# is likely to be questioned by Reviews, and require a strong argument
+# to be accepted.
+#
+# There are a small number of cases where the MAC has hard coded
+# delays which cannot be disabled. The 'phy-mode' only describes the
+# PCB. The inability to disable the delays in the MAC does not change
+# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
+# 'rgmii' is now invalid, it cannot be supported, since both the PCB
+# and the MAC and PHY adding delays cannot result in a functional
+# link. Thus the MAC should report a fatal error for any modes which
+# cannot be supported. When the MAC implements the delay, it must
+# ensure that the PHY does not also implement the same delay. So it
+# must modify the phy-mode it passes to the PHY, removing the delay it
+# has added. Failure to remove the delay will result in a
+# non-functioning link.
+#
+# Sometimes there is a need to fine tune the delays. Often the MAC or
+# PHY can perform this fine tuning. In the MAC node, the Device Tree
+# properties 'rx-internal-delay-ps' and 'tx-internal-delay-ps' should
+# be used to indicate fine tuning performed by the MAC. The values
+# expected here are small. A value of 2000ps, i.e 2ns, and a phy-mode
+# of 'rgmii' will not be accepted by Reviewers.
+#
+# If the PHY is to perform fine tuning, the properties
+# 'rx-internal-delay-ps' and 'tx-internal-delay-ps' in the PHY node
+# should be used. When the PHY is implementing delays, e.g. 'rgmii-id'
+# these properties should have a value near to 2000ps. If the PCB is
+# implementing delays, e.g. 'rgmii', a small value can be used to fine
+# tune the delay added by the PCB.
...
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy-package.yaml b/Documentation/devicetree/bindings/net/ethernet-phy-package.yaml
new file mode 100644
index 000000000000..e567101e6f38
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet-phy-package.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ethernet-phy-package.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ethernet PHY Package Common Properties
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ PHY packages are multi-port Ethernet PHY of the same family
+ and each Ethernet PHY is affected by the global configuration
+ of the PHY package.
+
+ Each reg of the PHYs defined in the PHY package node is
+ absolute and describe the real address of the Ethernet PHY on
+ the MDIO bus.
+
+properties:
+ $nodename:
+ pattern: "^ethernet-phy-package@[a-f0-9]+$"
+
+ reg:
+ minimum: 0
+ maximum: 31
+ description:
+ The base ID number for the PHY package.
+ Commonly the ID of the first PHY in the PHY package.
+
+ Some PHY in the PHY package might be not defined but
+ still occupy ID on the device (just not attached to
+ anything) hence the PHY package reg might correspond
+ to a not attached PHY (offset 0).
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ ^ethernet-phy@[a-f0-9]+$:
+ $ref: ethernet-phy.yaml#
+
+required:
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index ad808e9ce5b9..bb4c49fc5fd8 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/ethernet-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ethernet PHY Generic Binding
+title: Ethernet PHY Common Properties
maintainers:
- Andrew Lunn <andrew@lunn.ch>
@@ -35,9 +35,13 @@ properties:
description: PHYs that implement IEEE802.3 clause 45
- pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
description:
- If the PHY reports an incorrect ID (or none at all) then the
- compatible list may contain an entry with the correct PHY ID
- in the above form.
+ PHYs contain identification registers. These will be read to
+ identify the PHY. If the PHY reports an incorrect ID, or the
+ PHY requires a specific initialization sequence (like a
+ particular order of clocks, resets, power supplies), in
+ order to be able to read the ID registers, then the
+ compatible list must contain an entry with the correct PHY
+ ID in the above form.
The first group of digits is the 16 bit Phy Identifier 1
register, this is the chip vendor OUI bits 3:18. The
second group of digits is the Phy Identifier 2 register,
@@ -83,7 +87,7 @@ properties:
0: Disable 2.4 Vpp operating mode.
1: Request 2.4 Vpp operating mode from link partner.
Absence of this property will leave configuration to default values.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
broken-turn-around:
@@ -93,6 +97,20 @@ properties:
the turn around line low at end of the control phase of the
MDIO transaction.
+ brr-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If set, indicates the network cable interface is an alternative one as
+ defined in the BroadR-Reach link mode specification under 1BR-100 and
+ 1BR-10 names. The PHY must be configured to operate in BroadR-Reach mode
+ by software.
+
+ clocks:
+ maxItems: 1
+ description:
+ External clock connected to the PHY. If not specified it is assumed
+ that the PHY uses a fixed crystal or an internal oscillator.
+
enet-phy-lane-swap:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -104,7 +122,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/flag
description:
If set, indicates that PHY will disable swap of the
- TX/RX lanes. This property allows the PHY to work correcly after
+ TX/RX lanes. This property allows the PHY to work correctly after
e.g. wrong bootstrap configuration caused by issues in PCB
layout design.
@@ -144,6 +162,27 @@ properties:
Mark the corresponding energy efficient ethernet mode as
broken and request the ethernet to stop advertising it.
+ timing-role:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - forced-master
+ - forced-slave
+ - preferred-master
+ - preferred-slave
+ description: |
+ Specifies the timing role of the PHY in the network link. This property is
+ required for setups where the role must be explicitly assigned via the
+ device tree due to limitations in hardware strapping or incorrect strap
+ configurations.
+ It is applicable to Single Pair Ethernet (1000/100/10Base-T1) and other
+ PHY types, including 1000Base-T, where it controls whether the PHY should
+ be a master (clock source) or a slave (clock receiver).
+
+ - 'forced-master': The PHY is forced to operate as a master.
+ - 'forced-slave': The PHY is forced to operate as a slave.
+ - 'preferred-master': Prefer the PHY to be master but allow negotiation.
+ - 'preferred-slave': Prefer the PHY to be slave but allow negotiation.
+
pses:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
@@ -197,6 +236,51 @@ properties:
PHY's that have configurable TX internal delays. If this property is
present then the PHY applies the TX delay.
+ tx-amplitude-100base-tx-percent:
+ description:
+ Transmit amplitude gain applied for 100BASE-TX. 100% matches 2V
+ peak-to-peak specified in ANSI X3.263. When omitted, the PHYs default
+ will be left as is.
+
+ mac-termination-ohms:
+ maximum: 200
+ description:
+ The xMII signals need series termination on the driver side to match both
+ the output driver impedance and the line characteristic impedance, to
+ prevent reflections and EMI problems. Select a resistance value which is
+ supported by the builtin resistors of the PHY, otherwise the resistors may
+ have to be placed on board. When omitted, the PHYs default will be left as
+ is.
+
+ leds:
+ type: object
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^led@[a-f0-9]+$':
+ $ref: /schemas/leds/common.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+ description:
+ This defines the LED index in the PHY or the MAC. It's really
+ driver dependent and required for ports that define multiple
+ LED for the same port.
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
required:
- reg
@@ -204,6 +288,8 @@ additionalProperties: true
examples:
- |
+ #include <dt-bindings/leds/common.h>
+
ethernet {
#address-cells = <1>;
#size-cells = <0>;
@@ -219,5 +305,17 @@ examples:
reset-gpios = <&gpio1 4 1>;
reset-assert-us = <1000>;
reset-deassert-us = <2000>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/net/ethernet-switch-port.yaml b/Documentation/devicetree/bindings/net/ethernet-switch-port.yaml
new file mode 100644
index 000000000000..d5cf7e40e3c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet-switch-port.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ethernet-switch-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Ethernet Switch Port
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
+
+description:
+ An Ethernet switch port is a component of a switch that manages one MAC, and
+ can pass Ethernet frames.
+
+$ref: ethernet-controller.yaml#
+
+properties:
+ reg:
+ description: Port number
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/net/ethernet-switch.yaml b/Documentation/devicetree/bindings/net/ethernet-switch.yaml
new file mode 100644
index 000000000000..6bb68f7dbc7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet-switch.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ethernet-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Ethernet Switch
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Vladimir Oltean <olteanv@gmail.com>
+
+description:
+ Ethernet switches are multi-port Ethernet controllers. Each port has
+ its own number and is represented as its own Ethernet controller.
+ The minimum required functionality is to pass packets to software.
+ They may or may not be able to forward packets automonously between
+ ports.
+
+select: false
+
+allOf:
+ # This condition is here to satisfy the case where certain device
+ # nodes have to preserve non-standard names because of
+ # backward-compatibility with boot loaders inspecting certain
+ # node names.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,turris-mox-mv88e6085
+ - marvell,turris-mox-mv88e6190
+ then:
+ properties:
+ $nodename:
+ pattern: 'switch[0-3]@[0-3]+$'
+ else:
+ properties:
+ $nodename:
+ pattern: '^(ethernet-)?switch(@.*)?$'
+
+patternProperties:
+ '^(ethernet-)?ports$':
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ '^(ethernet-)?port@[0-9a-f]+$':
+ type: object
+ description: Ethernet switch ports
+
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
+oneOf:
+ - required:
+ - ports
+ - required:
+ - ethernet-ports
+
+additionalProperties: true
+
+$defs:
+ ethernet-ports:
+ description: An ethernet switch without any extra port properties
+ $ref: '#'
+
+ patternProperties:
+ '^(ethernet-)?ports$':
+ patternProperties:
+ '^(ethernet-)?port@[0-9a-f]+$':
+ description: Ethernet switch ports
+ $ref: ethernet-switch-port.yaml#
+ unevaluatedProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml
new file mode 100644
index 000000000000..d14410018bcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/faraday,ftgmac100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday Technology FTGMAC100 gigabit ethernet controller
+
+maintainers:
+ - Po-Yu Chuang <ratbert@faraday-tech.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: faraday,ftgmac100
+ - items:
+ - enum:
+ - aspeed,ast2400-mac
+ - aspeed,ast2500-mac
+ - aspeed,ast2600-mac
+ - const: faraday,ftgmac100
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: MAC IP clock
+ - description: RMII RCLK gate for AST2500/2600
+
+ resets:
+ maxItems: 1
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: MACCLK
+ - const: RCLK
+
+ phy-mode:
+ enum:
+ - rgmii
+ - rgmii-id
+ - rgmii-rxid
+ - rgmii-txid
+ - rmii
+
+ phy-handle: true
+
+ use-ncsi:
+ description:
+ Use the NC-SI stack instead of an MDIO PHY. Currently assumes
+ rmii (100bT) but kept as a separate property in case NC-SI grows support
+ for a gigabit link.
+ type: boolean
+
+ no-hw-checksum:
+ description:
+ Used to disable HW checksum support. Here for backward
+ compatibility as the driver now should have correct defaults based on
+ the SoC.
+ type: boolean
+ deprecated: true
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - aspeed,ast2600-mac
+ then:
+ properties:
+ resets: true
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@1e660000 {
+ compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
+ reg = <0x1e660000 0x180>;
+ interrupts = <2>;
+ use-ncsi;
+ };
+
+ ethernet@1e680000 {
+ compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
+ reg = <0x1e680000 0x180>;
+ interrupts = <2>;
+
+ phy-handle = <&phy>;
+ phy-mode = "rgmii";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,cpm-enet.yaml b/Documentation/devicetree/bindings/net/fsl,cpm-enet.yaml
new file mode 100644
index 000000000000..da836477e8ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,cpm-enet.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,cpm-enet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Network for cpm enet
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,cpm1-scc-enet
+ - fsl,cpm2-scc-enet
+ - fsl,cpm1-fec-enet
+ - fsl,cpm2-fcc-enet
+ - fsl,qe-enet
+ - items:
+ - enum:
+ - fsl,mpc8272-fcc-enet
+ - const: fsl,cpm2-fcc-enet
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ interrupts:
+ maxItems: 1
+
+ fsl,cpm-command:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: cpm command
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: ethernet-controller.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@11300 {
+ compatible = "fsl,mpc8272-fcc-enet",
+ "fsl,cpm2-fcc-enet";
+ reg = <0x11300 0x20 0x8400 0x100 0x11390 1>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <20 8>;
+ interrupt-parent = <&pic>;
+ phy-handle = <&phy0>;
+ fsl,cpm-command = <0x12000300>;
+ };
+
diff --git a/Documentation/devicetree/bindings/net/fsl,cpm-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,cpm-mdio.yaml
new file mode 100644
index 000000000000..b1791a3c490e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,cpm-mdio.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,cpm-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale CPM MDIO Device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,pq1-fec-mdio
+ - fsl,cpm2-mdio-bitbang
+ - items:
+ - const: fsl,mpc8272ads-mdio-bitbang
+ - const: fsl,mpc8272-mdio-bitbang
+ - const: fsl,cpm2-mdio-bitbang
+
+ reg:
+ maxItems: 1
+
+ fsl,mdio-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: pin of port C controlling mdio data
+
+ fsl,mdc-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: pin of port C controlling mdio clock
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: mdio.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio@10d40 {
+ compatible = "fsl,mpc8272ads-mdio-bitbang",
+ "fsl,mpc8272-mdio-bitbang",
+ "fsl,cpm2-mdio-bitbang";
+ reg = <0x10d40 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,mdio-pin = <12>;
+ fsl,mdc-pin = <13>;
+ };
+
diff --git a/Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml b/Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml
new file mode 100644
index 000000000000..c8a654310b90
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,enetc-ierb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Integrated Endpoint Register Block
+
+description:
+ The fsl_enetc driver can probe on the Integrated Endpoint Register Block,
+ which preconfigures the FIFO limits for the ENETC ports.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+ - Vladimir Oltean <vladimir.oltean@nxp.com>
+ - Wei Fang <wei.fang@nxp.com>
+ - Claudiu Manoil <claudiu.manoil@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls1028a-enetc-ierb
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ endpoint-config@f0800000 {
+ compatible = "fsl,ls1028a-enetc-ierb";
+ reg = <0xf0800000 0x10000>;
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml
new file mode 100644
index 000000000000..71c43ece8295
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,enetc-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ENETC external MDIO PCIe endpoint device
+
+description:
+ NETC provides an external master MDIO interface (EMDIO) for managing external
+ devices (PHYs). EMDIO supports both Clause 22 and 45 protocols. And the EMDIO
+ provides a means for different software modules to share a single set of MDIO
+ signals to access their PHYs.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+ - Vladimir Oltean <vladimir.oltean@nxp.com>
+ - Wei Fang <wei.fang@nxp.com>
+ - Claudiu Manoil <claudiu.manoil@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - pci1957,ee01
+ - const: fsl,enetc-mdio
+ - items:
+ - const: pci1131,ee00
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: mdio.yaml
+ - $ref: /schemas/pci/pci-device.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pcie{
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ mdio@0,3 {
+ compatible = "pci1957,ee01", "fsl,enetc-mdio";
+ reg = <0x000300 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@2 {
+ reg = <0x2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,enetc.yaml b/Documentation/devicetree/bindings/net/fsl,enetc.yaml
new file mode 100644
index 000000000000..aac20ab72ace
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,enetc.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,enetc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The NIC functionality of NXP NETC
+
+description:
+ The NIC functionality in NETC is known as EtherNET Controller (ENETC). ENETC
+ supports virtualization/isolation based on PCIe Single Root IO Virtualization
+ (SR-IOV), advanced QoS with 8 traffic classes and 4 drop resilience levels,
+ and a full range of TSN standards and NIC offload capabilities
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+ - Vladimir Oltean <vladimir.oltean@nxp.com>
+ - Wei Fang <wei.fang@nxp.com>
+ - Claudiu Manoil <claudiu.manoil@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - pci1957,e100
+ - const: fsl,enetc
+ - enum:
+ - pci1131,e101
+ - pci1131,e110
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: MAC transmit/receive reference clock
+
+ clock-names:
+ items:
+ - const: ref
+
+ mdio:
+ $ref: mdio.yaml
+ unevaluatedProperties: false
+ description: Optional child node for ENETC instance, otherwise use NETC EMDIO.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/pci/pci-device.yaml
+ - $ref: ethernet-controller.yaml
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - pci1131,e101
+ then:
+ properties:
+ clocks: false
+ clock-names: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ethernet@0,0 {
+ compatible = "pci1957,e100", "fsl,enetc";
+ reg = <0x000000 0 0 0 0>;
+ phy-handle = <&sgmii_phy0>;
+ phy-connection-type = "sgmii";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy@2 {
+ reg = <0x2>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml
index e0f376f7e274..24e863fdbdab 100644
--- a/Documentation/devicetree/bindings/net/fsl,fec.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml
@@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Fast Ethernet Controller (FEC)
maintainers:
- - Joakim Zhang <qiangqing.zhang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Wei Fang <wei.fang@nxp.com>
+ - NXP Linux Team <linux-imx@nxp.com>
allOf:
- $ref: ethernet-controller.yaml#
@@ -49,6 +51,7 @@ properties:
- fsl,imx8mm-fec
- fsl,imx8mn-fec
- fsl,imx8mp-fec
+ - fsl,imx93-fec
- const: fsl,imx8mq-fec
- const: fsl,imx6sx-fec
- items:
@@ -56,6 +59,7 @@ properties:
- const: fsl,imx6sx-fec
- items:
- enum:
+ - fsl,imx8dxl-fec
- fsl,imx8qxp-fec
- const: fsl,imx8qm-fec
- const: fsl,imx6sx-fec
@@ -141,6 +145,9 @@ properties:
description:
Regulator that powers the Ethernet PHY.
+ power-domains:
+ maxItems: 1
+
fsl,num-tx-queues:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -176,6 +183,13 @@ properties:
description:
Register bits of stop mode control, the format is <&gpr req_gpr req_bit>.
+ fsl,pps-channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ description:
+ Specifies to which timer instance the PPS signal is routed.
+ enum: [0, 1, 2, 3]
+
mdio:
$ref: mdio.yaml#
unevaluatedProperties: false
@@ -217,6 +231,9 @@ properties:
Can be omitted thus no delay is observed. Delay is in range of 1ms to 1000ms.
Other delays are invalid.
+ iommus:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml b/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
index 3a35ac1c260d..ef1e30a48c91 100644
--- a/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
@@ -81,13 +81,39 @@ properties:
An array of two references: the first is the FMan RX port and the second
is the TX port used by this MAC.
- ptp-timer:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: A reference to the IEEE1588 timer
+ phys:
+ description: A reference to the SerDes lane(s)
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: serdes
pcsphy-handle:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: A reference to the PCS (typically found on the SerDes)
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 3
+ deprecated: true
+ description: See pcs-handle.
+
+ pcs-handle:
+ minItems: 1
+ maxItems: 3
+ description: |
+ A reference to the various PCSs (typically found on the SerDes). If
+ pcs-handle-names is absent, and phy-connection-type is "xgmii", then the first
+ reference will be assumed to be for "xfi". Otherwise, if pcs-handle-names is
+ absent, then the first reference will be assumed to be for "sgmii".
+
+ pcs-handle-names:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum:
+ - sgmii
+ - qsgmii
+ - xfi
+ description: The type of each PCS in pcsphy-handle.
tbi-handle:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -98,7 +124,10 @@ required:
- cell-index
- reg
- fsl,fman-ports
- - ptp-timer
+
+dependencies:
+ pcs-handle-names:
+ - pcs-handle
allOf:
- $ref: ethernet-controller.yaml#
@@ -110,14 +139,6 @@ allOf:
then:
required:
- tbi-handle
- - if:
- properties:
- compatible:
- contains:
- const: fsl,fman-memac
- then:
- required:
- - pcsphy-handle
unevaluatedProperties: false
@@ -138,8 +159,9 @@ examples:
reg = <0xe8000 0x1000>;
fsl,fman-ports = <&fman0_rx_0x0c &fman0_tx_0x2c>;
ptp-timer = <&ptp_timer0>;
- pcsphy-handle = <&pcsphy4>;
- phy-handle = <&sgmii_phy1>;
- phy-connection-type = "sgmii";
+ pcs-handle = <&pcsphy4>, <&qsgmiib_pcs1>;
+ pcs-handle-names = "sgmii", "qsgmii";
+ phys = <&serdes1 1>;
+ phy-names = "serdes";
};
...
diff --git a/Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml
new file mode 100644
index 000000000000..6b2c0aa407a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,fman-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Frame Manager MDIO Device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: FMan MDIO Node.
+ The MDIO is a bus to which the PHY devices are connected.
+
+properties:
+ compatible:
+ enum:
+ - fsl,fman-mdio
+ - fsl,fman-xmdio
+ - fsl,fman-memac-mdio
+ description:
+ Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
+ Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
+ Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
+ FMan v3.
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: A reference to the input clock of the controller
+ from which the MDC frequency is derived.
+
+ interrupts:
+ maxItems: 1
+
+ fsl,fman-internal-mdio:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Fman has internal MDIO for internal PCS(Physical
+ Coding Sublayer) PHYs and external MDIO for external PHYs.
+ The settings and programming routines for internal/external
+ MDIO are different. Must be included for internal MDIO.
+
+ fsl,erratum-a009885:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Indicates the presence of the A009885
+ erratum describing that the contents of MDIO_DATA may
+ become corrupt unless it is read within 16 MDC cycles
+ of MDIO_CFG[BSY] being cleared, when performing an
+ MDIO read operation.
+
+ fsl,erratum-a011043:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates the presence of the A011043 erratum
+ describing that the MDIO_CFG[MDIO_RD_ER] bit may be falsely
+ set when reading internal PCS registers. MDIO reads to
+ internal PCS registers may result in having the
+ MDIO_CFG[MDIO_RD_ER] bit set, even when there is no error and
+ read data (MDIO_DATA[MDIO_DATA]) is correct.
+ Software may get false read error when reading internal
+ PCS registers through MDIO. As a workaround, all internal
+ MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
+
+ For internal PHY device on internal mdio bus, a PHY node should be created.
+ See the definition of the PHY node in booting-without-of.txt for an
+ example of how to define a PHY (Internal PHY has no interrupt line).
+ - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
+ - For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY.
+ The PCS PHY address should correspond to the value of the appropriate
+ MDEV_PORT.
+
+ little-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ IP block is little-endian mode. The default endian mode is big-endian.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: mdio.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio@f1000 {
+ compatible = "fsl,fman-xmdio";
+ reg = <0xf1000 0x1000>;
+ interrupts = <101 2 0 0>;
+ };
+
+ - |
+ mdio@e3120 {
+ compatible = "fsl,fman-mdio";
+ reg = <0xe3120 0xee0>;
+ fsl,fman-internal-mdio;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tbi-phy@8 {
+ reg = <0x8>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ - |
+ mdio@f1000 {
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0xf1000 0x1000>;
+ fsl,fman-internal-mdio;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcsphy6: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/net/fsl,fman-muram.yaml b/Documentation/devicetree/bindings/net/fsl,fman-muram.yaml
new file mode 100644
index 000000000000..aa71acc7fa5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,fman-muram.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,fman-muram.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Frame Manager MURAM Device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ FMan Internal memory - shared between all the FMan modules.
+ It contains data structures that are common and written to or read by
+ the modules.
+
+ FMan internal memory is split into the following parts:
+ Packet buffering (Tx/Rx FIFOs)
+ Frames internal context
+
+properties:
+ compatible:
+ enum:
+ - fsl,fman-muram
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ muram@0 {
+ compatible = "fsl,fman-muram";
+ reg = <0x0 0x28000>;
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,fman-port.yaml b/Documentation/devicetree/bindings/net/fsl,fman-port.yaml
new file mode 100644
index 000000000000..9de445307830
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,fman-port.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,fman-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Frame Manager Port Device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The Frame Manager (FMan) supports several types of hardware ports:
+ Ethernet receiver (RX)
+ Ethernet transmitter (TX)
+ Offline/Host command (O/H)
+
+properties:
+ compatible:
+ enum:
+ - fsl,fman-v2-port-oh
+ - fsl,fman-v2-port-rx
+ - fsl,fman-v2-port-tx
+ - fsl,fman-v3-port-oh
+ - fsl,fman-v3-port-rx
+ - fsl,fman-v3-port-tx
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Specifies the hardware port id.
+ Each hardware port on the FMan has its own hardware PortID.
+ Super set of all hardware Port IDs available at FMan Reference
+ Manual under "FMan Hardware Ports in Freescale Devices" table.
+
+ Each hardware port is assigned a 4KB, port-specific page in
+ the FMan hardware port memory region (which is part of the
+ FMan memory map). The first 4 KB in the FMan hardware ports
+ memory region is used for what are called common registers.
+ The subsequent 63 4KB pages are allocated to the hardware
+ ports.
+ The page of a specific port is determined by the cell-index.
+
+ reg:
+ items:
+ - description: There is one reg region describing the port
+ configuration registers.
+
+ fsl,fman-10g-port:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: The default port rate is 1G.
+ If this property exists, the port is s 10G port.
+
+ fsl,fman-best-effort-port:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: The default port rate is 1G.
+ Can be defined only if 10G-support is set.
+ This property marks a best-effort 10G port (10G port that
+ may not be capable of line rate).
+
+required:
+ - compatible
+ - reg
+ - cell-index
+
+additionalProperties: false
+
+examples:
+ - |
+ port@a8000 {
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xa8000 0x1000>;
+ cell-index = <0x28>;
+ };
+
diff --git a/Documentation/devicetree/bindings/net/fsl,fman.yaml b/Documentation/devicetree/bindings/net/fsl,fman.yaml
new file mode 100644
index 000000000000..9bbf39ef31a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,fman.yaml
@@ -0,0 +1,210 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,fman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Frame Manager Device
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs,
+ etc.) the FMan node will have child nodes for each of them.
+
+properties:
+ compatible:
+ enum:
+ - fsl,fman
+ description:
+ FMan version can be determined via FM_IP_REV_1 register in the
+ FMan block. The offset is 0xc4 from the beginning of the
+ Frame Processing Manager memory map (0xc3000 from the
+ beginning of the FMan node).
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Specifies the index of the FMan unit.
+
+ The cell-index value may be used by the SoC, to identify the
+ FMan unit in the SoC memory map. In the table below,
+ there's a description of the cell-index use in each SoC:
+
+ - P1023:
+ register[bit] FMan unit cell-index
+ ============================================================
+ DEVDISR[1] 1 0
+
+ - P2041, P3041, P4080 P5020, P5040:
+ register[bit] FMan unit cell-index
+ ============================================================
+ DCFG_DEVDISR2[6] 1 0
+ DCFG_DEVDISR2[14] 2 1
+ (Second FM available only in P4080 and P5040)
+
+ - B4860, T1040, T2080, T4240:
+ register[bit] FMan unit cell-index
+ ============================================================
+ DCFG_CCSR_DEVDISR2[24] 1 0
+ DCFG_CCSR_DEVDISR2[25] 2 1
+ (Second FM available only in T4240)
+
+ DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
+ the specific SoC "Device Configuration/Pin Control" Memory
+ Map.
+
+ reg:
+ items:
+ - description: BMI configuration registers.
+ - description: QMI configuration registers.
+ - description: DMA configuration registers.
+ - description: FPM configuration registers.
+ - description: FMan controller configuration registers.
+ minItems: 1
+
+ ranges: true
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: fmanclk
+
+ interrupts:
+ items:
+ - description: The first element is associated with the event interrupts.
+ - description: the second element is associated with the error interrupts.
+
+ dma-coherent: true
+
+ ptimer-handle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: see ptp/fsl,ptp.yaml
+
+ fsl,qman-channel-range:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Specifies the range of the available dedicated
+ channels in the FMan. The first cell specifies the beginning
+ of the range and the second cell specifies the number of
+ channels
+ items:
+ - description: The first cell specifies the beginning of the range.
+ - description: |
+ The second cell specifies the number of channels.
+ Further information available at:
+ "Work Queue (WQ) Channel Assignments in the QMan" section
+ in DPAA Reference Manual.
+
+ fsl,qman:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: See soc/fsl/qman.txt
+
+ fsl,bman:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: See soc/fsl/bman.txt
+
+ fsl,erratum-a050385:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: A boolean property. Indicates the presence of the
+ erratum A050385 which indicates that DMA transactions that are
+ split can result in a FMan lock.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+patternProperties:
+ '^muram@[a-f0-9]+$':
+ $ref: fsl,fman-muram.yaml
+
+ '^port@[a-f0-9]+$':
+ $ref: fsl,fman-port.yaml
+
+ '^ethernet@[a-f0-9]+$':
+ $ref: fsl,fman-dtsec.yaml
+
+ '^mdio@[a-f0-9]+$':
+ $ref: fsl,fman-mdio.yaml
+
+ '^phc@[a-f0-9]+$':
+ $ref: /schemas/ptp/fsl,ptp.yaml
+
+required:
+ - compatible
+ - cell-index
+ - reg
+ - ranges
+ - clocks
+ - clock-names
+ - interrupts
+ - fsl,qman-channel-range
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ fman@400000 {
+ compatible = "fsl,fman";
+ reg = <0x400000 0x100000>;
+ ranges = <0 0x400000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <1>;
+ clocks = <&fman_clk>;
+ clock-names = "fmanclk";
+ interrupts = <96 IRQ_TYPE_EDGE_FALLING>,
+ <16 IRQ_TYPE_EDGE_FALLING>;
+ fsl,qman-channel-range = <0x40 0xc>;
+
+ muram@0 {
+ compatible = "fsl,fman-muram";
+ reg = <0x0 0x28000>;
+ };
+
+ port@81000 {
+ cell-index = <1>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x81000 0x1000>;
+ };
+
+ fman1_rx_0x8: port@88000 {
+ cell-index = <0x8>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x88000 0x1000>;
+ };
+
+ fman1_tx_0x28: port@a8000 {
+ cell-index = <0x28>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xa8000 0x1000>;
+ };
+
+ ethernet@e0000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <0>;
+ reg = <0xe0000 0x1000>;
+ ptp-timer = <&ptp_timer>;
+ fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
+ tbi-handle = <&tbi5>;
+ };
+
+ ptp_timer: phc@fe000 {
+ compatible = "fsl,fman-ptp-timer";
+ reg = <0xfe000 0x1000>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ mdio@f1000 {
+ compatible = "fsl,fman-xmdio";
+ reg = <0xf1000 0x1000>;
+ interrupts = <101 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml
new file mode 100644
index 000000000000..03c819bc701b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,gianfar-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Gianfar (TSEC) MDIO Device
+
+description:
+ This binding describes the MDIO is a bus to which the PHY devices are
+ connected. For each device that exists on this bus, a child node should be
+ created.
+
+ Some TSECs are associated with an internal Ten-Bit Interface (TBI) PHY. This
+ PHY is accessed through the local MDIO bus. These buses are defined similarly
+ to the mdio buses, except they are compatible with "fsl,gianfar-tbi". The TBI
+ PHYs underneath them are similar to normal PHYs, but the reg property is
+ considered instructive, rather than descriptive. The reg property should be
+ chosen so it doesn't interfere with other PHYs on the bus.
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+# This is needed to distinguish gianfar.yaml and gianfar-mdio.yaml, because
+# both use compatible = "gianfar" (with different device_type values)
+select:
+ oneOf:
+ - properties:
+ compatible:
+ contains:
+ const: gianfar
+ device_type:
+ const: mdio
+ required:
+ - device_type
+
+ - properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,gianfar-tbi
+ - fsl,gianfar-mdio
+ - fsl,etsec2-tbi
+ - fsl,etsec2-mdio
+ - fsl,ucc-mdio
+ - ucc_geth_phy
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ enum:
+ - fsl,gianfar-tbi
+ - fsl,gianfar-mdio
+ - fsl,etsec2-tbi
+ - fsl,etsec2-mdio
+ - fsl,ucc-mdio
+ - gianfar
+ - ucc_geth_phy
+
+ reg:
+ minItems: 1
+ items:
+ - description:
+ Offset and length of the register set for the device
+
+ - description:
+ Optionally, the offset and length of the TBIPA register (TBI PHY
+ address register). If TBIPA register is not specified, the driver
+ will attempt to infer it from the register set specified (your
+ mileage may vary).
+
+ device_type:
+ const: mdio
+
+required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+allOf:
+ - $ref: mdio.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ucc_geth_phy
+ then:
+ required:
+ - device_type
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mdio@24520 {
+ reg = <0x24520 0x20>;
+ compatible = "fsl,gianfar-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/fsl,gianfar.yaml b/Documentation/devicetree/bindings/net/fsl,gianfar.yaml
new file mode 100644
index 000000000000..0d8909770ccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl,gianfar.yaml
@@ -0,0 +1,246 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/fsl,gianfar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Three-Speed Ethernet Controller (TSEC), "Gianfar"
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+# This is needed to distinguish gianfar.yaml and gianfar-mdio.yaml, because
+# both use compatible = "gianfar" (with different device_type values)
+select:
+ oneOf:
+ - properties:
+ compatible:
+ contains:
+ const: gianfar
+ device_type:
+ const: network
+ required:
+ - device_type
+
+ - properties:
+ compatible:
+ const: fsl,etsec2
+
+ required:
+ - compatible
+
+properties:
+ compatible:
+ enum:
+ - gianfar
+ - fsl,etsec2
+
+ device_type:
+ const: network
+
+ model:
+ enum:
+ - FEC
+ - TSEC
+ - eTSEC
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Transmit interrupt or single combined interrupt
+ - description: Receive interrupt
+ - description: Error interrupt
+
+ dma-coherent: true
+
+ fsl,magic-packet:
+ type: boolean
+ description:
+ If present, indicates that the hardware supports waking up via magic packet.
+
+ fsl,wake-on-filer:
+ type: boolean
+ description:
+ If present, indicates that the hardware supports waking up by Filer
+ General Purpose Interrupt (FGPI) asserted on the Rx int line. This is
+ an advanced power management capability allowing certain packet types
+ (user) defined by filer rules to wake up the system.
+
+ bd-stash:
+ type: boolean
+ description:
+ If present, indicates that the hardware supports stashing buffer
+ descriptors in the L2.
+
+ rx-stash-len:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Denotes the number of bytes of a received buffer to stash in the L2.
+
+ rx-stash-idx:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Denotes the index of the first byte from the received buffer to stash in
+ the L2.
+
+ fsl,num_rx_queues:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of receive queues
+ const: 8
+
+ fsl,num_tx_queues:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of transmit queues
+ const: 8
+
+ tbi-handle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference (phandle) to the TBI node
+
+required:
+ - compatible
+ - model
+
+patternProperties:
+ "^mdio@[0-9a-f]+$":
+ $ref: /schemas/net/fsl,gianfar-mdio.yaml#
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+ # eTSEC2 controller nodes have "queue group" subnodes and don't need a "reg"
+ # property.
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,etsec2
+ then:
+ patternProperties:
+ "^queue-group@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Transmit interrupt
+ - description: Receive interrupt
+ - description: Error interrupt
+
+ required:
+ - reg
+ - interrupts
+
+ additionalProperties: false
+ else:
+ required:
+ - reg
+
+ # TSEC and eTSEC devices require three interrupts
+ - if:
+ properties:
+ model:
+ contains:
+ enum: [ TSEC, eTSEC ]
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: Transmit interrupt
+ - description: Receive interrupt
+ - description: Error interrupt
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@24000 {
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <0x24000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <29 2>, <30 2>, <34 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ethernet@24000 {
+ compatible = "gianfar";
+ reg = <0x24000 0x1000>;
+ ranges = <0x0 0x24000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <32 IRQ_TYPE_LEVEL_LOW>,
+ <33 IRQ_TYPE_LEVEL_LOW>,
+ <34 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&ipic>;
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x520 0x20>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ethernet {
+ compatible = "fsl,etsec2";
+ ranges;
+ device_type = "network";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&gic>;
+ model = "eTSEC";
+ fsl,magic-packet;
+ dma-coherent;
+
+ queue-group@2d10000 {
+ reg = <0x0 0x2d10000 0x0 0x1000>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ queue-group@2d14000 {
+ reg = <0x0 0x2d14000 0x0 0x1000>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
index 7f620a71a972..be8a2163b73e 100644
--- a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/fsl,qoriq-mc-dpmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DPAA2 MAC bindings
+title: DPAA2 MAC
maintainers:
- Ioana Ciornei <ioana.ciornei@nxp.com>
@@ -14,7 +14,7 @@ description:
located under the 'dpmacs' node for the fsl-mc bus DTS node.
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
properties:
compatible:
@@ -24,24 +24,20 @@ properties:
maxItems: 1
description: The DPMAC number
- phy-handle: true
-
- phy-connection-type: true
-
- phy-mode: true
-
pcs-handle:
- $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
description:
A reference to a node representing a PCS PHY device found on
the internal MDIO bus.
- managed: true
+ phys:
+ description: A reference to the SerDes lane(s)
+ maxItems: 1
required:
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
deleted file mode 100644
index 9b9a3f197e2d..000000000000
--- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-* ENETC ethernet device tree bindings
-
-Depending on board design and ENETC port type (internal or
-external) there are two supported link modes specified by
-below device tree bindings.
-
-Required properties:
-
-- reg : Specifies PCIe Device Number and Function
- Number of the ENETC endpoint device, according
- to parent node bindings.
-- compatible : Should be "fsl,enetc".
-
-1. The ENETC external port is connected to a MDIO configurable phy
-
-1.1. Using the local ENETC Port MDIO interface
-
-In this case, the ENETC node should include a "mdio" sub-node
-that in turn should contain the "ethernet-phy" node describing the
-external phy. Below properties are required, their bindings
-already defined in Documentation/devicetree/bindings/net/ethernet.txt or
-Documentation/devicetree/bindings/net/phy.txt.
-
-Required:
-
-- phy-handle : Phandle to a PHY on the MDIO bus.
- Defined in ethernet.txt.
-
-- phy-connection-type : Defined in ethernet.txt.
-
-- mdio : "mdio" node, defined in mdio.txt.
-
-- ethernet-phy : "ethernet-phy" node, defined in phy.txt.
-
-Example:
-
- ethernet@0,0 {
- compatible = "fsl,enetc";
- reg = <0x000000 0 0 0 0>;
- phy-handle = <&sgmii_phy0>;
- phy-connection-type = "sgmii";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- sgmii_phy0: ethernet-phy@2 {
- reg = <0x2>;
- };
- };
- };
-
-1.2. Using the central MDIO PCIe endpoint device
-
-In this case, the mdio node should be defined as another PCIe
-endpoint node, at the same level with the ENETC port nodes.
-
-Required properties:
-
-- reg : Specifies PCIe Device Number and Function
- Number of the ENETC endpoint device, according
- to parent node bindings.
-- compatible : Should be "fsl,enetc-mdio".
-
-The remaining required mdio bus properties are standard, their bindings
-already defined in Documentation/devicetree/bindings/net/mdio.txt.
-
-Example:
-
- ethernet@0,0 {
- compatible = "fsl,enetc";
- reg = <0x000000 0 0 0 0>;
- phy-handle = <&sgmii_phy0>;
- phy-connection-type = "sgmii";
- };
-
- mdio@0,3 {
- compatible = "fsl,enetc-mdio";
- reg = <0x000300 0 0 0 0>;
- #address-cells = <1>;
- #size-cells = <0>;
- sgmii_phy0: ethernet-phy@2 {
- reg = <0x2>;
- };
- };
-
-2. The ENETC port is an internal port or has a fixed-link external
-connection
-
-In this case, the ENETC port node defines a fixed link connection,
-as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
-
-Required:
-
-- fixed-link : "fixed-link" node, defined in "fixed-link.txt".
-
-Example:
- ethernet@0,2 {
- compatible = "fsl,enetc";
- reg = <0x000200 0 0 0 0>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
-* Integrated Endpoint Register Block bindings
-
-Optionally, the fsl_enetc driver can probe on the Integrated Endpoint Register
-Block, which preconfigures the FIFO limits for the ENETC ports. This is a node
-with the following properties:
-
-- reg : Specifies the address in the SoC memory space.
-- compatible : Must be "fsl,ls1028a-enetc-ierb".
-
-Example:
- ierb@1f0800000 {
- compatible = "fsl,ls1028a-enetc-ierb";
- reg = <0x01 0xf0800000 0x0 0x10000>;
- };
diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
deleted file mode 100644
index b9055335db3b..000000000000
--- a/Documentation/devicetree/bindings/net/fsl-fman.txt
+++ /dev/null
@@ -1,547 +0,0 @@
-=============================================================================
-Freescale Frame Manager Device Bindings
-
-CONTENTS
- - FMan Node
- - FMan Port Node
- - FMan MURAM Node
- - FMan dTSEC/XGEC/mEMAC Node
- - FMan IEEE 1588 Node
- - FMan MDIO Node
- - Example
-
-=============================================================================
-FMan Node
-
-DESCRIPTION
-
-Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs,
-etc.) the FMan node will have child nodes for each of them.
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: Must include "fsl,fman"
- FMan version can be determined via FM_IP_REV_1 register in the
- FMan block. The offset is 0xc4 from the beginning of the
- Frame Processing Manager memory map (0xc3000 from the
- beginning of the FMan node).
-
-- cell-index
- Usage: required
- Value type: <u32>
- Definition: Specifies the index of the FMan unit.
-
- The cell-index value may be used by the SoC, to identify the
- FMan unit in the SoC memory map. In the table below,
- there's a description of the cell-index use in each SoC:
-
- - P1023:
- register[bit] FMan unit cell-index
- ============================================================
- DEVDISR[1] 1 0
-
- - P2041, P3041, P4080 P5020, P5040:
- register[bit] FMan unit cell-index
- ============================================================
- DCFG_DEVDISR2[6] 1 0
- DCFG_DEVDISR2[14] 2 1
- (Second FM available only in P4080 and P5040)
-
- - B4860, T1040, T2080, T4240:
- register[bit] FMan unit cell-index
- ============================================================
- DCFG_CCSR_DEVDISR2[24] 1 0
- DCFG_CCSR_DEVDISR2[25] 2 1
- (Second FM available only in T4240)
-
- DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
- the specific SoC "Device Configuration/Pin Control" Memory
- Map.
-
-- reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the offset of the
- following configuration registers:
- - BMI configuration registers.
- - QMI configuration registers.
- - DMA configuration registers.
- - FPM configuration registers.
- - FMan controller configuration registers.
-
-- ranges
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property.
-
-- clocks
- Usage: required
- Value type: <prop-encoded-array>
- Definition: phandle for the fman input clock.
-
-- clock-names
- usage: required
- Value type: <stringlist>
- Definition: "fmanclk" for the fman input clock.
-
-- interrupts
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A pair of IRQs are specified in this property.
- The first element is associated with the event interrupts and
- the second element is associated with the error interrupts.
-
-- fsl,qman-channel-range
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Specifies the range of the available dedicated
- channels in the FMan. The first cell specifies the beginning
- of the range and the second cell specifies the number of
- channels.
- Further information available at:
- "Work Queue (WQ) Channel Assignments in the QMan" section
- in DPAA Reference Manual.
-
-- fsl,qman
-- fsl,bman
- Usage: required
- Definition: See soc/fsl/qman.txt and soc/fsl/bman.txt
-
-- fsl,erratum-a050385
- Usage: optional
- Value type: boolean
- Definition: A boolean property. Indicates the presence of the
- erratum A050385 which indicates that DMA transactions that are
- split can result in a FMan lock.
-
-=============================================================================
-FMan MURAM Node
-
-DESCRIPTION
-
-FMan Internal memory - shared between all the FMan modules.
-It contains data structures that are common and written to or read by
-the modules.
-FMan internal memory is split into the following parts:
- Packet buffering (Tx/Rx FIFOs)
- Frames internal context
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: Must include "fsl,fman-muram"
-
-- ranges
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property.
- Specifies the multi-user memory offset and the size within
- the FMan.
-
-EXAMPLE
-
-muram@0 {
- compatible = "fsl,fman-muram";
- ranges = <0 0x000000 0x28000>;
-};
-
-=============================================================================
-FMan Port Node
-
-DESCRIPTION
-
-The Frame Manager (FMan) supports several types of hardware ports:
- Ethernet receiver (RX)
- Ethernet transmitter (TX)
- Offline/Host command (O/H)
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: A standard property.
- Must include one of the following:
- - "fsl,fman-v2-port-oh" for FManV2 OH ports
- - "fsl,fman-v2-port-rx" for FManV2 RX ports
- - "fsl,fman-v2-port-tx" for FManV2 TX ports
- - "fsl,fman-v3-port-oh" for FManV3 OH ports
- - "fsl,fman-v3-port-rx" for FManV3 RX ports
- - "fsl,fman-v3-port-tx" for FManV3 TX ports
-
-- cell-index
- Usage: required
- Value type: <u32>
- Definition: Specifies the hardware port id.
- Each hardware port on the FMan has its own hardware PortID.
- Super set of all hardware Port IDs available at FMan Reference
- Manual under "FMan Hardware Ports in Freescale Devices" table.
-
- Each hardware port is assigned a 4KB, port-specific page in
- the FMan hardware port memory region (which is part of the
- FMan memory map). The first 4 KB in the FMan hardware ports
- memory region is used for what are called common registers.
- The subsequent 63 4KB pages are allocated to the hardware
- ports.
- The page of a specific port is determined by the cell-index.
-
-- reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: There is one reg region describing the port
- configuration registers.
-
-- fsl,fman-10g-port
- Usage: optional
- Value type: boolean
- Definition: The default port rate is 1G.
- If this property exists, the port is s 10G port.
-
-- fsl,fman-best-effort-port
- Usage: optional
- Value type: boolean
- Definition: Can be defined only if 10G-support is set.
- This property marks a best-effort 10G port (10G port that
- may not be capable of line rate).
-
-EXAMPLE
-
-port@a8000 {
- cell-index = <0x28>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xa8000 0x1000>;
-};
-
-port@88000 {
- cell-index = <0x8>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x88000 0x1000>;
-};
-
-port@81000 {
- cell-index = <0x1>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x81000 0x1000>;
-};
-
-=============================================================================
-FMan dTSEC/XGEC/mEMAC Node
-
-Refer to Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
-
-============================================================================
-FMan IEEE 1588 Node
-
-Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
-
-=============================================================================
-FMan MDIO Node
-
-DESCRIPTION
-
-The MDIO is a bus to which the PHY devices are connected.
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: A standard property.
- Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
- Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
- Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
- FMan v3.
-
-- reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property.
-
-- clocks
- Usage: optional
- Value type: <phandle>
- Definition: A reference to the input clock of the controller
- from which the MDC frequency is derived.
-
-- clock-frequency
- Usage: optional
- Value type: <u32>
- Definition: Specifies the external MDC frequency, in Hertz, to
- be used. Requires that the input clock is specified in the
- "clocks" property. See also: mdio.yaml.
-
-- suppress-preamble
- Usage: optional
- Value type: <boolean>
- Definition: Disable generation of preamble bits. See also:
- mdio.yaml.
-
-- interrupts
- Usage: required for external MDIO
- Value type: <prop-encoded-array>
- Definition: Event interrupt of external MDIO controller.
-
-- fsl,fman-internal-mdio
- Usage: required for internal MDIO
- Value type: boolean
- Definition: Fman has internal MDIO for internal PCS(Physical
- Coding Sublayer) PHYs and external MDIO for external PHYs.
- The settings and programming routines for internal/external
- MDIO are different. Must be included for internal MDIO.
-
-- fsl,erratum-a009885
- Usage: optional
- Value type: <boolean>
- Definition: Indicates the presence of the A009885
- erratum describing that the contents of MDIO_DATA may
- become corrupt unless it is read within 16 MDC cycles
- of MDIO_CFG[BSY] being cleared, when performing an
- MDIO read operation.
-
-- fsl,erratum-a011043
- Usage: optional
- Value type: <boolean>
- Definition: Indicates the presence of the A011043 erratum
- describing that the MDIO_CFG[MDIO_RD_ER] bit may be falsely
- set when reading internal PCS registers. MDIO reads to
- internal PCS registers may result in having the
- MDIO_CFG[MDIO_RD_ER] bit set, even when there is no error and
- read data (MDIO_DATA[MDIO_DATA]) is correct.
- Software may get false read error when reading internal
- PCS registers through MDIO. As a workaround, all internal
- MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
-
-For internal PHY device on internal mdio bus, a PHY node should be created.
-See the definition of the PHY node in booting-without-of.txt for an
-example of how to define a PHY (Internal PHY has no interrupt line).
-- For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
-- For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY,
- PCS PHY addr must be '0'.
-
-EXAMPLE
-
-Example for FMan v2 external MDIO:
-
-mdio@f1000 {
- compatible = "fsl,fman-xmdio";
- reg = <0xf1000 0x1000>;
- interrupts = <101 2 0 0>;
-};
-
-Example for FMan v2 internal MDIO:
-
-mdio@e3120 {
- compatible = "fsl,fman-mdio";
- reg = <0xe3120 0xee0>;
- fsl,fman-internal-mdio;
-
- tbi1: tbi-phy@8 {
- reg = <0x8>;
- device_type = "tbi-phy";
- };
-};
-
-Example for FMan v3 internal MDIO:
-
-mdio@f1000 {
- compatible = "fsl,fman-memac-mdio";
- reg = <0xf1000 0x1000>;
- fsl,fman-internal-mdio;
-
- pcsphy6: ethernet-phy@0 {
- reg = <0x0>;
- };
-};
-
-=============================================================================
-Example
-
-fman@400000 {
- #address-cells = <1>;
- #size-cells = <1>;
- cell-index = <1>;
- compatible = "fsl,fman"
- ranges = <0 0x400000 0x100000>;
- reg = <0x400000 0x100000>;
- clocks = <&fman_clk>;
- clock-names = "fmanclk";
- interrupts = <
- 96 2 0 0
- 16 2 1 1>;
- fsl,qman-channel-range = <0x40 0xc>;
-
- muram@0 {
- compatible = "fsl,fman-muram";
- reg = <0x0 0x28000>;
- };
-
- port@81000 {
- cell-index = <1>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x81000 0x1000>;
- };
-
- port@82000 {
- cell-index = <2>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x82000 0x1000>;
- };
-
- port@83000 {
- cell-index = <3>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x83000 0x1000>;
- };
-
- port@84000 {
- cell-index = <4>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x84000 0x1000>;
- };
-
- port@85000 {
- cell-index = <5>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x85000 0x1000>;
- };
-
- port@86000 {
- cell-index = <6>;
- compatible = "fsl,fman-v2-port-oh";
- reg = <0x86000 0x1000>;
- };
-
- fman1_rx_0x8: port@88000 {
- cell-index = <0x8>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x88000 0x1000>;
- };
-
- fman1_rx_0x9: port@89000 {
- cell-index = <0x9>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x89000 0x1000>;
- };
-
- fman1_rx_0xa: port@8a000 {
- cell-index = <0xa>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x8a000 0x1000>;
- };
-
- fman1_rx_0xb: port@8b000 {
- cell-index = <0xb>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x8b000 0x1000>;
- };
-
- fman1_rx_0xc: port@8c000 {
- cell-index = <0xc>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x8c000 0x1000>;
- };
-
- fman1_rx_0x10: port@90000 {
- cell-index = <0x10>;
- compatible = "fsl,fman-v2-port-rx";
- reg = <0x90000 0x1000>;
- };
-
- fman1_tx_0x28: port@a8000 {
- cell-index = <0x28>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xa8000 0x1000>;
- };
-
- fman1_tx_0x29: port@a9000 {
- cell-index = <0x29>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xa9000 0x1000>;
- };
-
- fman1_tx_0x2a: port@aa000 {
- cell-index = <0x2a>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xaa000 0x1000>;
- };
-
- fman1_tx_0x2b: port@ab000 {
- cell-index = <0x2b>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xab000 0x1000>;
- };
-
- fman1_tx_0x2c: port@ac0000 {
- cell-index = <0x2c>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xac000 0x1000>;
- };
-
- fman1_tx_0x30: port@b0000 {
- cell-index = <0x30>;
- compatible = "fsl,fman-v2-port-tx";
- reg = <0xb0000 0x1000>;
- };
-
- ethernet@e0000 {
- compatible = "fsl,fman-dtsec";
- cell-index = <0>;
- reg = <0xe0000 0x1000>;
- fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
- tbi-handle = <&tbi5>;
- };
-
- ethernet@e2000 {
- compatible = "fsl,fman-dtsec";
- cell-index = <1>;
- reg = <0xe2000 0x1000>;
- fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>;
- tbi-handle = <&tbi6>;
- };
-
- ethernet@e4000 {
- compatible = "fsl,fman-dtsec";
- cell-index = <2>;
- reg = <0xe4000 0x1000>;
- fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>;
- tbi-handle = <&tbi7>;
- };
-
- ethernet@e6000 {
- compatible = "fsl,fman-dtsec";
- cell-index = <3>;
- reg = <0xe6000 0x1000>;
- fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>;
- tbi-handle = <&tbi8>;
- };
-
- ethernet@e8000 {
- compatible = "fsl,fman-dtsec";
- cell-index = <4>;
- reg = <0xf0000 0x1000>;
- fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>;
- tbi-handle = <&tbi9>;
-
- ethernet@f0000 {
- cell-index = <8>;
- compatible = "fsl,fman-xgec";
- reg = <0xf0000 0x1000>;
- fsl,fman-ports = <&fman1_rx_0x10 &fman1_tx_0x30>;
- };
-
- ptp-timer@fe000 {
- compatible = "fsl,fman-ptp-timer";
- reg = <0xfe000 0x1000>;
- };
-
- mdio@f1000 {
- compatible = "fsl,fman-xmdio";
- reg = <0xf1000 0x1000>;
- interrupts = <101 2 0 0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 047bdf7bdd2f..b18bb4c997ea 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -1,89 +1,15 @@
* MDIO IO device
-The MDIO is a bus to which the PHY devices are connected. For each
-device that exists on this bus, a child node should be created. See
-the definition of the PHY node in booting-without-of.txt for an example
-of how to define a PHY.
-
-Required properties:
- - reg : Offset and length of the register set for the device, and optionally
- the offset and length of the TBIPA register (TBI PHY address
- register). If TBIPA register is not specified, the driver will
- attempt to infer it from the register set specified (your mileage may
- vary).
- - compatible : Should define the compatible device type for the
- mdio. Currently supported strings/devices are:
- - "fsl,gianfar-tbi"
- - "fsl,gianfar-mdio"
- - "fsl,etsec2-tbi"
- - "fsl,etsec2-mdio"
- - "fsl,ucc-mdio"
- - "fsl,fman-mdio"
- When device_type is "mdio", the following strings are also considered:
- - "gianfar"
- - "ucc_geth_phy"
-
-Example:
-
- mdio@24520 {
- reg = <24520 20>;
- compatible = "fsl,gianfar-mdio";
-
- ethernet-phy@0 {
- ......
- };
- };
+Refer to Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml
* TBI Internal MDIO bus
-As of this writing, every tsec is associated with an internal TBI PHY.
-This PHY is accessed through the local MDIO bus. These buses are defined
-similarly to the mdio buses, except they are compatible with "fsl,gianfar-tbi".
-The TBI PHYs underneath them are similar to normal PHYs, but the reg property
-is considered instructive, rather than descriptive. The reg property should
-be chosen so it doesn't interfere with other PHYs on the bus.
+Refer to Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml
* Gianfar-compatible ethernet nodes
-Properties:
-
- - device_type : Should be "network"
- - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
- - compatible : Should be "gianfar"
- - reg : Offset and length of the register set for the device
- - interrupts : For FEC devices, the first interrupt is the device's
- interrupt. For TSEC and eTSEC devices, the first interrupt is
- transmit, the second is receive, and the third is error.
- - phy-handle : See ethernet.txt file in the same directory.
- - fixed-link : See fixed-link.txt in the same directory.
- - phy-connection-type : See ethernet.txt file in the same directory.
- This property is only really needed if the connection is of type
- "rgmii-id", as all other connection types are detected by hardware.
- - fsl,magic-packet : If present, indicates that the hardware supports
- waking up via magic packet.
- - fsl,wake-on-filer : If present, indicates that the hardware supports
- waking up by Filer General Purpose Interrupt (FGPI) asserted on the
- Rx int line. This is an advanced power management capability allowing
- certain packet types (user) defined by filer rules to wake up the system.
- - bd-stash : If present, indicates that the hardware supports stashing
- buffer descriptors in the L2.
- - rx-stash-len : Denotes the number of bytes of a received buffer to stash
- in the L2.
- - rx-stash-idx : Denotes the index of the first byte from the received
- buffer to stash in the L2.
-
-Example:
- ethernet@24000 {
- device_type = "network";
- model = "TSEC";
- compatible = "gianfar";
- reg = <0x24000 0x1000>;
- local-mac-address = [ 00 E0 0C 00 73 00 ];
- interrupts = <29 2 30 2 34 2>;
- interrupt-parent = <&mpic>;
- phy-handle = <&phy0>
- };
+Refer to Documentation/devicetree/bindings/net/fsl,gianfar.yaml
* Gianfar PTP clock nodes
-Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
+Refer to Documentation/devicetree/bindings/ptp/fsl,ptp.yaml
diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt b/Documentation/devicetree/bindings/net/ftgmac100.txt
deleted file mode 100644
index 29234021f601..000000000000
--- a/Documentation/devicetree/bindings/net/ftgmac100.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Faraday Technology FTGMAC100 gigabit ethernet controller
-
-Required properties:
-- compatible: "faraday,ftgmac100"
-
- Must also contain one of these if used as part of an Aspeed AST2400
- or 2500 family SoC as they have some subtle tweaks to the
- implementation:
-
- - "aspeed,ast2400-mac"
- - "aspeed,ast2500-mac"
- - "aspeed,ast2600-mac"
-
-- reg: Address and length of the register set for the device
-- interrupts: Should contain ethernet controller interrupt
-
-Optional properties:
-- phy-handle: See ethernet.txt file in the same directory.
-- phy-mode: See ethernet.txt file in the same directory. If the property is
- absent, "rgmii" is assumed. Supported values are "rgmii*" and "rmii" for
- aspeed parts. Other (unknown) parts will accept any value.
-- use-ncsi: Use the NC-SI stack instead of an MDIO PHY. Currently assumes
- rmii (100bT) but kept as a separate property in case NC-SI grows support
- for a gigabit link.
-- no-hw-checksum: Used to disable HW checksum support. Here for backward
- compatibility as the driver now should have correct defaults based on
- the SoC.
-- clocks: In accordance with the generic clock bindings. Must describe the MAC
- IP clock, and optionally an RMII RCLK gate for the AST2500/AST2600. The
- required MAC clock must be the first cell.
-- clock-names:
-
- - "MACCLK": The MAC IP clock
- - "RCLK": Clock gate for the RMII RCLK
-
-Optional subnodes:
-- mdio: See mdio.txt file in the same directory.
-
-Example:
-
- mac0: ethernet@1e660000 {
- compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
- reg = <0x1e660000 0x180>;
- interrupts = <2>;
- use-ncsi;
- };
-
-Example with phy-handle:
-
- mac1: ethernet@1e680000 {
- compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
- reg = <0x1e680000 0x180>;
- interrupts = <2>;
-
- phy-handle = <&phy>;
- phy-mode = "rgmii";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- phy: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
index 464c0dafc617..c09eec6422ac 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
@@ -19,16 +19,6 @@ Optional properties:
[1] Documentation/devicetree/bindings/net/ethernet.txt
-* Ethernet ppe node:
-Control rx & tx fifos of all ethernet controllers.
-Have 2048 recv channels shared by all ethernet controllers, only if no overlap.
-Each controller's recv channel start from channel * number (RX_DESC_NUM).
-
-Required properties:
-- compatible: "hisilicon,hip04-ppe", "syscon".
-- reg: address and length of the register set for the device.
-
-
* MDIO bus node:
Required properties:
diff --git a/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt
deleted file mode 100644
index 168f1be50912..000000000000
--- a/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* AT86RF230 IEEE 802.15.4 *
-
-Required properties:
- - compatible: should be "atmel,at86rf230", "atmel,at86rf231",
- "atmel,at86rf233" or "atmel,at86rf212"
- - spi-max-frequency: maximal bus speed, should be set to 7500000 depends
- sync or async operation mode
- - reg: the chipselect index
- - interrupts: the interrupt generated by the device. Non high-level
- can occur deadlocks while handling isr.
-
-Optional properties:
- - reset-gpio: GPIO spec for the rstn pin
- - sleep-gpio: GPIO spec for the slp_tr pin
- - xtal-trim: u8 value for fine tuning the internal capacitance
- arrays of xtal pins: 0 = +0 pF, 0xf = +4.5 pF
-
-Example:
-
- at86rf231@0 {
- compatible = "atmel,at86rf231";
- spi-max-frequency = <7500000>;
- reg = <0>;
- interrupts = <19 4>;
- interrupt-parent = <&gpio3>;
- xtal-trim = /bits/ 8 <0x06>;
- };
diff --git a/Documentation/devicetree/bindings/net/ieee802154/atmel,at86rf233.yaml b/Documentation/devicetree/bindings/net/ieee802154/atmel,at86rf233.yaml
new file mode 100644
index 000000000000..32cdc30009cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ieee802154/atmel,at86rf233.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ieee802154/atmel,at86rf233.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AT86RF230 IEEE 802.15.4
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - atmel,at86rf212
+ - atmel,at86rf230
+ - atmel,at86rf231
+ - atmel,at86rf233
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpio:
+ maxItems: 1
+
+ sleep-gpio:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 7500000
+
+ xtal-trim:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ maximum: 0xf
+ description: |
+ Fine tuning the internal capacitance arrays of xtal pins:
+ 0 = +0 pF, 0xf = +4.5 pF
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ zigbee@0 {
+ compatible = "atmel,at86rf231";
+ reg = <0>;
+ spi-max-frequency = <7500000>;
+ interrupts = <19 4>;
+ interrupt-parent = <&gpio3>;
+ xtal-trim = /bits/ 8 <0x06>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt b/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
index a1046e636fa1..f1bd07a0097d 100644
--- a/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
+++ b/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt
@@ -20,7 +20,7 @@ Example:
reg = <0>;
spi-max-frequency = <3000000>;
spi-cpol;
- reset-gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+ reset-gpio = <&gpio1 1 GPIO_ACTIVE_LOW>;
irq-gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
extclock-enable;
extclock-freq = 16000000;
diff --git a/Documentation/devicetree/bindings/net/ingenic,mac.yaml b/Documentation/devicetree/bindings/net/ingenic,mac.yaml
index 93b3e991d209..bdea101c2f75 100644
--- a/Documentation/devicetree/bindings/net/ingenic,mac.yaml
+++ b/Documentation/devicetree/bindings/net/ingenic,mac.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/ingenic,mac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for MAC in Ingenic SoCs
+title: MAC in Ingenic SoCs
maintainers:
- 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml
index 52a7fa4f49a4..62c1da36a2b5 100644
--- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml
+++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/intel,dwmac-plat.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel DWMAC glue layer Device Tree Bindings
+title: Intel DWMAC glue layer
maintainers:
- Vineetha G. Jaya Kumaran <vineetha.g.jaya.kumaran@intel.com>
@@ -19,7 +19,7 @@ select:
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
@@ -41,6 +41,12 @@ properties:
- const: ptp_ref
- const: tx_clk
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
required:
- compatible
- clocks
diff --git a/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml b/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml
index 8b9b3f915d92..f92730b1d2fa 100644
--- a/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml
+++ b/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml
@@ -2,8 +2,8 @@
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP46x PTP Timer (TSYNC)
diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml
index 4e1b79818aff..8689de1aaea1 100644
--- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml
+++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml
@@ -2,13 +2,13 @@
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx ethernet
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -28,7 +28,7 @@ properties:
description: Ethernet MMIO address range
queue-rx:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the RX queue node
@@ -36,7 +36,7 @@ properties:
description: phandle to the RX queue on the NPE
queue-txready:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the TX READY queue node
@@ -47,8 +47,10 @@ properties:
phy-handle: true
+ fixed-link: true
+
intel,npe-handle:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the NPE this ethernet instance is using
diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml
index e6329febb60c..7a405e9b37b2 100644
--- a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml
+++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml
@@ -2,8 +2,8 @@
# Copyright 2021 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx V.35 WAN High Speed Serial Link (HSS)
@@ -24,7 +24,7 @@ properties:
description: The HSS instance
intel,npe-handle:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
items:
- description: phandle to the NPE this HSS instance is using
@@ -33,7 +33,7 @@ properties:
and the instance to use in the second cell
intel,queue-chl-rxtrig:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the RX trigger queue on the NPE
@@ -41,7 +41,7 @@ properties:
description: phandle to the RX trigger queue on the NPE
intel,queue-chl-txready:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the TX ready queue on the NPE
@@ -49,7 +49,7 @@ properties:
description: phandle to the TX ready queue on the NPE
intel,queue-pkt-rx:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the RX queue on the NPE
@@ -57,7 +57,7 @@ properties:
description: phandle to the packet RX queue on the NPE
intel,queue-pkt-tx:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 4
items:
items:
@@ -66,7 +66,7 @@ properties:
description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE
intel,queue-pkt-rxfree:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 4
items:
items:
@@ -76,7 +76,7 @@ properties:
RXFREE3 queues on the NPE
intel,queue-pkt-txdone:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the TXDONE queue on the NPE
diff --git a/Documentation/devicetree/bindings/net/lantiq,pef2256.yaml b/Documentation/devicetree/bindings/net/lantiq,pef2256.yaml
new file mode 100644
index 000000000000..7da8370e2468
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/lantiq,pef2256.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/lantiq,pef2256.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq PEF2256
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The Lantiq PEF2256, also known as Infineon PEF2256 or FALC56, is a framer and
+ line interface component designed to fulfill all required interfacing between
+ an analog E1/T1/J1 line and the digital PCM system highway/H.100 bus.
+
+properties:
+ compatible:
+ items:
+ - const: lantiq,pef2256
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master Clock
+ - description: System Clock Receive
+ - description: System Clock Transmit
+
+ clock-names:
+ items:
+ - const: mclk
+ - const: sclkr
+ - const: sclkx
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ GPIO used to reset the device.
+ maxItems: 1
+
+ pinctrl:
+ $ref: /schemas/pinctrl/pinctrl.yaml#
+ additionalProperties: false
+
+ patternProperties:
+ '-pins$':
+ type: object
+ $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins:
+ enum: [ RPA, RPB, RPC, RPD, XPA, XPB, XPC, XPD ]
+
+ function:
+ enum: [ SYPR, RFM, RFMB, RSIGM, RSIG, DLR, FREEZE, RFSP, LOS,
+ SYPX, XFMS, XSIG, TCLK, XMFB, XSIGM, DLX, XCLK, XLT,
+ GPI, GPOH, GPOL ]
+
+ required:
+ - pins
+ - function
+
+ lantiq,data-rate-bps:
+ enum: [2048000, 4096000, 8192000, 16384000]
+ default: 2048000
+ description:
+ Data rate (bit per seconds) on the system highway.
+
+ lantiq,clock-falling-edge:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Data is sent on falling edge of the clock (and received on the rising
+ edge). If 'clock-falling-edge' is not present, data is sent on the
+ rising edge (and received on the falling edge).
+
+ lantiq,channel-phase:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ default: 0
+ description: |
+ The pef2256 delivers a full frame (32 8-bit time-slots in E1 and 24 8-bit
+ time-slots 8 8-bit signaling in E1/J1) every 125us. This lead to a data
+ rate of 2048000 bit/s. When lantiq,data-rate-bps is more than 2048000
+ bit/s, the data (all 32 8-bit) present in the frame are interleave with
+ unused time-slots. The lantiq,channel-phase property allows to set the
+ correct alignment of the interleave mechanism.
+ For instance, suppose lantiq,data-rate-bps = 8192000 (ie 4*2048000), and
+ lantiq,channel-phase = 2, the interleave schema with unused time-slots
+ (nu) and used time-slots (XX) for TSi is
+ nu nu XX nu nu nu XX nu nu nu XX nu
+ <-- TSi --> <- TSi+1 -> <- TSi+2 ->
+ With lantiq,data-rate-bps = 8192000, and lantiq,channel-phase = 1, the
+ interleave schema is
+ nu XX nu nu nu XX nu nu nu XX nu nu
+ <-- TSi --> <- TSi+1 -> <- TSi+2 ->
+ With lantiq,data-rate-bps = 4096000 (ie 2*2048000), and
+ lantiq,channel-phase = 1, the interleave schema is
+ nu XX nu XX nu XX
+ <-- TSi --> <- TSi+1 -> <- TSi+2 ->
+
+patternProperties:
+ '^codec(-([0-9]|[1-2][0-9]|3[0-1]))?$':
+ type: object
+ $ref: /schemas/sound/dai-common.yaml
+ unevaluatedProperties: false
+ description:
+ Codec provided by the pef2256. This codec allows to use some of the PCM
+ system highway time-slots as audio channels to transport audio data over
+ the E1/T1/J1 lines.
+ The time-slots used by the codec must be set and so, the properties
+ 'dai-tdm-slot-num', 'dai-tdm-slot-width', 'dai-tdm-slot-tx-mask' and
+ 'dai-tdm-slot-rx-mask' must be present in the sound card node for
+ sub-nodes that involve the codec. The codec uses 8-bit time-slots.
+ 'dai-tdm-tdm-slot-with' must be set to 8.
+ The tx and rx masks define the pef2256 time-slots assigned to the codec.
+
+ properties:
+ compatible:
+ const: lantiq,pef2256-codec
+
+ '#sound-dai-cells':
+ const: 0
+
+ required:
+ - compatible
+ - '#sound-dai-cells'
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pef2256: framer@2000000 {
+ compatible = "lantiq,pef2256";
+ reg = <0x2000000 0x100>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&intc>;
+ clocks = <&clk_mclk>, <&clk_sclkr>, <&clk_sclkx>;
+ clock-names = "mclk", "sclkr", "sclkx";
+ reset-gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
+ lantiq,data-rate-bps = <4096000>;
+
+ pinctrl {
+ pef2256_rpa_sypr: rpa-pins {
+ pins = "RPA";
+ function = "SYPR";
+ };
+ pef2256_xpa_sypx: xpa-pins {
+ pins = "XPA";
+ function = "SYPX";
+ };
+ };
+
+ pef2256_codec0: codec-0 {
+ compatible = "lantiq,pef2256-codec";
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "PEF2256_0";
+ };
+
+ pef2256_codec1: codec-1 {
+ compatible = "lantiq,pef2256-codec";
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "PEF2256_1";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ simple-audio-card,dai-link@0 { /* CPU DAI1 - pef2256 codec 1 */
+ reg = <0>;
+ cpu {
+ sound-dai = <&cpu_dai1>;
+ };
+ codec {
+ sound-dai = <&pef2256_codec0>;
+ dai-tdm-slot-num = <4>;
+ dai-tdm-slot-width = <8>;
+ /* TS 1, 2, 3, 4 */
+ dai-tdm-slot-tx-mask = <0 1 1 1 1>;
+ dai-tdm-slot-rx-mask = <0 1 1 1 1>;
+ };
+ };
+ simple-audio-card,dai-link@1 { /* CPU DAI2 - pef2256 codec 2 */
+ reg = <1>;
+ cpu {
+ sound-dai = <&cpu_dai2>;
+ };
+ codec {
+ sound-dai = <&pef2256_codec1>;
+ dai-tdm-slot-num = <4>;
+ dai-tdm-slot-width = <8>;
+ /* TS 5, 6, 7, 8 */
+ dai-tdm-slot-tx-mask = <0 0 0 0 0 1 1 1 1>;
+ dai-tdm-slot-rx-mask = <0 0 0 0 0 1 1 1 1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/litex,liteeth.yaml b/Documentation/devicetree/bindings/net/litex,liteeth.yaml
index ebf4e360f8dd..200b198b0d9b 100644
--- a/Documentation/devicetree/bindings/net/litex,liteeth.yaml
+++ b/Documentation/devicetree/bindings/net/litex,liteeth.yaml
@@ -86,14 +86,12 @@ examples:
phy-handle = <&eth_phy>;
mdio {
- #address-cells = <1>;
- #size-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- eth_phy: ethernet-phy@0 {
- reg = <0>;
- };
+ eth_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
};
};
...
-
-# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml :
diff --git a/Documentation/devicetree/bindings/net/loongson,ls1b-gmac.yaml b/Documentation/devicetree/bindings/net/loongson,ls1b-gmac.yaml
new file mode 100644
index 000000000000..c4f3224bad38
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/loongson,ls1b-gmac.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/loongson,ls1b-gmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1B Gigabit Ethernet MAC Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description: |
+ Loongson-1B Gigabit Ethernet MAC Controller is based on
+ Synopsys DesignWare MAC (version 3.50a).
+
+ Main features
+ - Dual 10/100/1000Mbps GMAC controllers
+ - Full-duplex operation (IEEE 802.3x flow control automatic transmission)
+ - Half-duplex operation (CSMA/CD Protocol and back-pressure support)
+ - RX Checksum Offload
+ - TX Checksum insertion
+ - MII interface
+ - RGMII interface
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - loongson,ls1b-gmac
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - loongson,ls1b-gmac
+ - const: snps,dwmac-3.50a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: stmmaceth
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: macirq
+
+ loongson,ls1-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon containing some extra configurations
+ including PHY interface mode.
+
+ phy-mode:
+ enum:
+ - mii
+ - rgmii-id
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - loongson,ls1-syscon
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls1x-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gmac0: ethernet@1fe10000 {
+ compatible = "loongson,ls1b-gmac", "snps,dwmac-3.50a";
+ reg = <0x1fe10000 0x10000>;
+
+ clocks = <&clkc LS1X_CLKID_AHB>;
+ clock-names = "stmmaceth";
+
+ interrupt-parent = <&intc1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ loongson,ls1-syscon = <&syscon>;
+
+ phy-handle = <&phy0>;
+ phy-mode = "mii";
+ snps,pbl = <1>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/loongson,ls1c-emac.yaml b/Documentation/devicetree/bindings/net/loongson,ls1c-emac.yaml
new file mode 100644
index 000000000000..99001b940b83
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/loongson,ls1c-emac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/loongson,ls1c-emac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1C Ethernet MAC Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description: |
+ Loongson-1C Ethernet MAC Controller is based on
+ Synopsys DesignWare MAC (version 3.50a).
+
+ Main features
+ - 10/100Mbps
+ - Full-duplex operation (IEEE 802.3x flow control automatic transmission)
+ - Half-duplex operation (CSMA/CD Protocol and back-pressure support)
+ - IEEE 802.1Q VLAN tag detection for reception frames
+ - MII interface
+ - RMII interface
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - loongson,ls1c-emac
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - loongson,ls1c-emac
+ - const: snps,dwmac-3.50a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: stmmaceth
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: macirq
+
+ loongson,ls1-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon containing some extra configurations
+ including PHY interface mode.
+
+ phy-mode:
+ enum:
+ - mii
+ - rmii
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - loongson,ls1-syscon
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls1x-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ emac: ethernet@1fe10000 {
+ compatible = "loongson,ls1c-emac", "snps,dwmac-3.50a";
+ reg = <0x1fe10000 0x10000>;
+
+ clocks = <&clkc LS1X_CLKID_AHB>;
+ clock-names = "stmmaceth";
+
+ interrupt-parent = <&intc1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ loongson,ls1-syscon = <&syscon>;
+
+ phy-handle = <&phy0>;
+ phy-mode = "mii";
+ snps,pbl = <1>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@13 {
+ reg = <0x13>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt
deleted file mode 100644
index cfe0e5991d46..000000000000
--- a/Documentation/devicetree/bindings/net/lpc-eth.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* NXP LPC32xx SoC Ethernet Controller
-
-Required properties:
-- compatible: Should be "nxp,lpc-eth"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain ethernet controller interrupt
-
-Optional properties:
-- phy-mode: See ethernet.txt file in the same directory. If the property is
- absent, "rmii" is assumed.
-- use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering
-
-Optional subnodes:
-- mdio : specifies the mdio bus, used as a container for phy nodes according to
- phy.txt in the same directory
-
-
-Example:
-
- mac: ethernet@31060000 {
- compatible = "nxp,lpc-eth";
- reg = <0x31060000 0x1000>;
- interrupt-parent = <&mic>;
- interrupts = <29 0>;
-
- phy-mode = "rmii";
- use-iram;
- };
diff --git a/Documentation/devicetree/bindings/net/marvell,aquantia.yaml b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
new file mode 100644
index 000000000000..f269615126d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,aquantia.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/marvell,aquantia.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Aquantia Ethernet PHY
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description: |
+ Marvell Aquantia Ethernet PHY require a firmware to be loaded to actually
+ work.
+
+ This can be done and is implemented by OEM in 3 different way:
+ - Attached SPI flash directly to the PHY with the firmware. The PHY
+ will self load the firmware in the presence of this configuration.
+ - Read from a dedicated partition on system NAND declared in an
+ NVMEM cell, and loaded to the PHY using its mailbox interface.
+ - Manually provided firmware loaded from a file in the filesystem.
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id03a1.b445
+ - ethernet-phy-id03a1.b460
+ - ethernet-phy-id03a1.b4a2
+ - ethernet-phy-id03a1.b4d0
+ - ethernet-phy-id03a1.b4e0
+ - ethernet-phy-id03a1.b5c2
+ - ethernet-phy-id03a1.b4b0
+ - ethernet-phy-id03a1.b662
+ - ethernet-phy-id03a1.b712
+ - ethernet-phy-id31c3.1c12
+ required:
+ - compatible
+
+properties:
+ reg:
+ maxItems: 1
+
+ firmware-name:
+ description: specify the name of PHY firmware to load
+
+ marvell,mdi-cfg-order:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description:
+ force normal (0) or reverse (1) order of MDI pairs, overriding MDI_CFG bootstrap pin.
+
+ nvmem-cells:
+ description: phandle to the firmware nvmem cell
+ maxItems: 1
+
+ nvmem-cell-names:
+ const: firmware
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ compatible = "ethernet-phy-id31c3.1c12",
+ "ethernet-phy-ieee802.3-c45";
+
+ reg = <0>;
+ firmware-name = "AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x8_ID44776_VER1630.cld";
+ };
+
+ ethernet-phy@1 {
+ compatible = "ethernet-phy-id31c3.1c12",
+ "ethernet-phy-ieee802.3-c45";
+
+ reg = <1>;
+ nvmem-cells = <&aqr_fw>;
+ nvmem-cell-names = "firmware";
+ };
+ };
+
+ flash {
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* ... */
+
+ partition@650000 {
+ compatible = "nvmem-cells";
+ label = "0:ethphyfw";
+ reg = <0x650000 0x80000>;
+ read-only;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aqr_fw: aqr_fw@0 {
+ reg = <0x0 0x5f42a>;
+ };
+ };
+
+ /* ... */
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/marvell,armada-370-neta.yaml b/Documentation/devicetree/bindings/net/marvell,armada-370-neta.yaml
new file mode 100644
index 000000000000..8814977da024
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,armada-370-neta.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/marvell,armada-370-neta.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 370/XP/3700/AC5 Ethernet Controller (NETA)
+
+maintainers:
+ - Marcin Wojtas <marcin.s.wojtas@gmail.com>
+
+allOf:
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-370-neta
+ - marvell,armada-xp-neta
+ - marvell,armada-3700-neta
+ - marvell,armada-ac5-neta
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: bus
+
+ phys:
+ maxItems: 1
+
+ tx-csum-limit:
+ description: Maximum MTU in bytes for Tx checksum offload; default is 1600 for
+ armada-370-neta and 9800 for others.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ buffer-manager:
+ description: Phandle to hardware buffer manager.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ bm,pool-long:
+ description: Pool ID for packets larger than the short threshold.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ bm,pool-short:
+ description: Pool ID for packets smaller than the long threshold.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@70000 {
+ compatible = "marvell,armada-370-neta";
+ reg = <0x70000 0x2500>;
+ interrupts = <8>;
+ clocks = <&gate_clk 4>;
+ tx-csum-limit = <9800>;
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ buffer-manager = <&bm>;
+ bm,pool-long = <0>;
+ bm,pool-short = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/net/marvell,armada-380-neta-bm.yaml b/Documentation/devicetree/bindings/net/marvell,armada-380-neta-bm.yaml
new file mode 100644
index 000000000000..9392e7126e3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,armada-380-neta-bm.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/marvell,armada-380-neta-bm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 380/XP Buffer Manager (BM)
+
+maintainers:
+ - Marcin Wojtas <marcin.s.wojtas@gmail.com>
+
+description:
+ In order to see how to hook the BM to a given ethernet port, please refer to
+ Documentation/devicetree/bindings/net/marvell,armada-370-neta.yaml.
+
+properties:
+ compatible:
+ const: marvell,armada-380-neta-bm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ internal-mem:
+ description: Phandle to internal SRAM region
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+patternProperties:
+ "^pool[0-3],capacity$":
+ description:
+ size of external buffer pointers' ring maintained in DRAM for pool 0-3
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 128
+ maximum: 16352
+
+ "^pool[0-3],pkt-size$":
+ description:
+ maximum packet size for a short buffer pool entry (pool 0-3)
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - internal-mem
+
+additionalProperties: false
+
+examples:
+ - |
+ bm@c8000 {
+ compatible = "marvell,armada-380-neta-bm";
+ reg = <0xc8000 0xac>;
+ clocks = <&gateclk 13>;
+ internal-mem = <&bm_bppi>;
+ pool2,capacity = <4096>;
+ pool1,pkt-size = <512>;
+ };
diff --git a/Documentation/devicetree/bindings/net/marvell,dfx-server.yaml b/Documentation/devicetree/bindings/net/marvell,dfx-server.yaml
new file mode 100644
index 000000000000..8a14c919e3f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,dfx-server.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/marvell,dfx-server.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Prestera DFX server
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: marvell,dfx-server
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: marvell,dfx-server
+ - const: simple-bus
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - ranges
+
+# The DFX server may expose clocks described as subnodes
+additionalProperties:
+ type: object
+
+examples:
+ - |
+
+ #define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+ bus@0 {
+ reg = <0 0>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ dfx-bus@ac000000 {
+ compatible = "marvell,dfx-server", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
+ reg = <MBUS_ID(0x08, 0x00) 0 0x100000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/marvell,mvusb.yaml b/Documentation/devicetree/bindings/net/marvell,mvusb.yaml
index 8e288ab38fd7..ab838c1ffeed 100644
--- a/Documentation/devicetree/bindings/net/marvell,mvusb.yaml
+++ b/Documentation/devicetree/bindings/net/marvell,mvusb.yaml
@@ -20,7 +20,7 @@ description: |+
definition.
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
properties:
compatible:
@@ -50,11 +50,14 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- switch@0 {
+ ethernet-switch@0 {
compatible = "marvell,mv88e6190";
reg = <0x0>;
- ports {
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
/* Port definitions */
};
diff --git a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml
index d2906b4a0f59..73429855d584 100644
--- a/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/marvell,orion-mdio.yaml
@@ -16,9 +16,6 @@ description: |
8k has a second unit which provides an interface with the xMDIO bus. This
driver handles these interfaces.
-allOf:
- - $ref: "mdio.yaml#"
-
properties:
compatible:
enum:
@@ -39,13 +36,16 @@ required:
- compatible
- reg
+allOf:
+ - $ref: mdio.yaml#
+
unevaluatedProperties: false
examples:
- |
mdio@d0072004 {
compatible = "marvell,orion-mdio";
- reg = <0xd0072004 0x4>;
+ reg = <0xd0072004 0x84>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = <30>;
diff --git a/Documentation/devicetree/bindings/net/marvell,pp2.yaml b/Documentation/devicetree/bindings/net/marvell,pp2.yaml
new file mode 100644
index 000000000000..4eadafc43d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,pp2.yaml
@@ -0,0 +1,305 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/marvell,pp2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell CN913X / Marvell Armada 375, 7K, 8K Ethernet Controller
+
+maintainers:
+ - Marcin Wojtas <mw@semihalf.com>
+ - Russell King <linux@armlinux.org>
+
+description: |
+ Marvell Armada 375 Ethernet Controller (PPv2.1)
+ Marvell Armada 7K/8K Ethernet Controller (PPv2.2)
+ Marvell CN913X Ethernet Controller (PPv2.3)
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-375-pp2
+ - marvell,armada-7k-pp22
+
+ reg:
+ minItems: 3
+ maxItems: 4
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ clocks:
+ minItems: 2
+ items:
+ - description: main controller clock
+ - description: GOP clock
+ - description: MG clock
+ - description: MG Core clock
+ - description: AXI clock
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: pp_clk
+ - const: gop_clk
+ - const: mg_clk
+ - const: mg_core_clk
+ - const: axi_clk
+
+ dma-coherent: true
+
+ marvell,system-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the system controller.
+
+patternProperties:
+ '^(ethernet-)?port@[0-2]$':
+ type: object
+ description: subnode for each ethernet port.
+ $ref: ethernet-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ description: ID of the port from the MAC point of view.
+ maximum: 2
+
+ interrupts:
+ minItems: 1
+ maxItems: 10
+ description: interrupt(s) for the port
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: hif0
+ - const: hif1
+ - const: hif2
+ - const: hif3
+ - const: hif4
+ - const: hif5
+ - const: hif6
+ - const: hif7
+ - const: hif8
+ - const: link
+
+ description: >
+ if more than a single interrupt for is given, must be the
+ name associated to the interrupts listed. Valid names are:
+ "hifX", with X in [0..8], and "link". The names "tx-cpu0",
+ "tx-cpu1", "tx-cpu2", "tx-cpu3" and "rx-shared" are supported
+ for backward compatibility but shouldn't be used for new
+ additions.
+
+ phys:
+ minItems: 1
+ maxItems: 2
+ description: >
+ Generic PHY, providing SerDes connectivity. For most modes,
+ one lane is sufficient, but some (e.g. RXAUI) may require two.
+
+ phy-mode:
+ enum:
+ - gmii
+ - sgmii
+ - rgmii-id
+ - 1000base-x
+ - 2500base-x
+ - 5gbase-r
+ - rxaui
+ - 10gbase-r
+
+ port-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: >
+ ID of the port from the MAC point of view.
+ Legacy binding for backward compatibility.
+
+ marvell,loopback:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: port is loopback mode.
+
+ gop-port-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ only for marvell,armada-7k-pp22, ID of the port from the
+ GOP (Group Of Ports) point of view. This ID is used to index the
+ per-port registers in the second register area.
+
+ required:
+ - reg
+ - interrupts
+ - phy-mode
+ - port-id
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: marvell,armada-7k-pp22
+ then:
+ properties:
+ reg:
+ items:
+ - description: Packet Processor registers
+ - description: Networking interfaces registers
+ - description: CM3 address space used for TX Flow Control
+
+ clocks:
+ minItems: 5
+
+ clock-names:
+ minItems: 5
+
+ patternProperties:
+ '^(ethernet-)?port@[0-2]$':
+ required:
+ - gop-port-id
+
+ required:
+ - marvell,system-controller
+ else:
+ properties:
+ reg:
+ items:
+ - description: Packet Processor registers
+ - description: LMS registers
+ - description: Register area per eth0
+ - description: Register area per eth1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ maxItems: 2
+
+ patternProperties:
+ '^(ethernet-)?port@[0-1]$':
+ properties:
+ reg:
+ maximum: 1
+
+ gop-port-id: false
+
+additionalProperties: false
+
+examples:
+ - |
+ // For Armada 375 variant
+ #include <dt-bindings/interrupt-controller/mvebu-icu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@f0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,armada-375-pp2";
+ reg = <0xf0000 0xa000>,
+ <0xc0000 0x3060>,
+ <0xc4000 0x100>,
+ <0xc5000 0x100>;
+ clocks = <&gateclk 3>, <&gateclk 19>;
+ clock-names = "pp_clk", "gop_clk";
+
+ ethernet-port@0 {
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0>;
+ port-id = <0>; /* For backward compatibility. */
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+
+ ethernet-port@1 {
+ interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <1>;
+ port-id = <1>; /* For backward compatibility. */
+ phy = <&phy3>;
+ phy-mode = "gmii";
+ };
+ };
+
+ - |
+ // For Armada 7k/8k and Cn913x variants
+ #include <dt-bindings/interrupt-controller/mvebu-icu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,armada-7k-pp22";
+ reg = <0x0 0x100000>, <0x129000 0xb000>, <0x220000 0x800>;
+ clocks = <&cp0_clk 1 3>, <&cp0_clk 1 9>,
+ <&cp0_clk 1 5>, <&cp0_clk 1 6>, <&cp0_clk 1 18>;
+ clock-names = "pp_clk", "gop_clk", "mg_clk", "mg_core_clk", "axi_clk";
+ marvell,system-controller = <&cp0_syscon0>;
+
+ ethernet-port@0 {
+ interrupts = <ICU_GRP_NSR 39 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 43 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 47 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 51 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 59 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 63 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 67 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 71 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 129 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
+ "hif5", "hif6", "hif7", "hif8", "link";
+ phy-mode = "10gbase-r";
+ phys = <&cp0_comphy4 0>;
+ reg = <0>;
+ port-id = <0>; /* For backward compatibility. */
+ gop-port-id = <0>;
+ };
+
+ ethernet-port@1 {
+ interrupts = <ICU_GRP_NSR 40 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 44 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 48 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 52 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 60 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 64 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 68 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 72 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 128 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
+ "hif5", "hif6", "hif7", "hif8", "link";
+ phy-mode = "rgmii-id";
+ reg = <1>;
+ port-id = <1>; /* For backward compatibility. */
+ gop-port-id = <2>;
+ };
+
+ ethernet-port@2 {
+ interrupts = <ICU_GRP_NSR 41 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 45 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 49 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 53 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 61 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 65 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 69 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 73 IRQ_TYPE_LEVEL_HIGH>,
+ <ICU_GRP_NSR 127 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
+ "hif5", "hif6", "hif7", "hif8", "link";
+ phy-mode = "2500base-x";
+ managed = "in-band-status";
+ phys = <&cp0_comphy5 2>;
+ sfp = <&sfp_eth3>;
+ reg = <2>;
+ port-id = <2>; /* For backward compatibility. */
+ gop-port-id = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt
deleted file mode 100644
index e28938ddfdf5..000000000000
--- a/Documentation/devicetree/bindings/net/marvell,prestera.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-Marvell Prestera Switch Chip bindings
--------------------------------------
-
-Required properties:
-- compatible: must be "marvell,prestera" and one of the following
- "marvell,prestera-98dx3236",
- "marvell,prestera-98dx3336",
- "marvell,prestera-98dx4251",
-- reg: address and length of the register set for the device.
-- interrupts: interrupt for the device
-
-Optional properties:
-- dfx: phandle reference to the "DFX Server" node
-
-Example:
-
-switch {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
-
- packet-processor@0 {
- compatible = "marvell,prestera-98dx3236", "marvell,prestera";
- reg = <0 0x4000000>;
- interrupts = <33>, <34>, <35>;
- dfx = <&dfx>;
- };
-};
-
-DFX Server bindings
--------------------
-
-Required properties:
-- compatible: must be "marvell,dfx-server", "simple-bus"
-- ranges: describes the address mapping of a memory-mapped bus.
-- reg: address and length of the register set for the device.
-
-Example:
-
-dfx-server {
- compatible = "marvell,dfx-server", "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
- reg = <MBUS_ID(0x08, 0x00) 0 0x100000>;
-};
-
-Marvell Prestera SwitchDev bindings
------------------------------------
-Optional properties:
-- compatible: must be "marvell,prestera"
-- base-mac-provider: describes handle to node which provides base mac address,
- might be a static base mac address or nvme cell provider.
-
-Example:
-
-eeprom_mac_addr: eeprom-mac-addr {
- compatible = "eeprom,mac-addr-cell";
- status = "okay";
-
- nvmem = <&eeprom_at24>;
-};
-
-prestera {
- compatible = "marvell,prestera";
- status = "okay";
-
- base-mac-provider = <&eeprom_mac_addr>;
-};
-
-The current implementation of Prestera Switchdev PCI interface driver requires
-that BAR2 is assigned to 0xf6000000 as base address from the PCI IO range:
-
-&cp0_pcie0 {
- ranges = <0x81000000 0x0 0xfb000000 0x0 0xfb000000 0x0 0xf0000
- 0x82000000 0x0 0xf6000000 0x0 0xf6000000 0x0 0x2000000
- 0x82000000 0x0 0xf9000000 0x0 0xf9000000 0x0 0x100000>;
- phys = <&cp0_comphy0 0>;
- status = "okay";
-};
diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.yaml b/Documentation/devicetree/bindings/net/marvell,prestera.yaml
new file mode 100644
index 000000000000..16ff892f7bbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell,prestera.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/marvell,prestera.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Prestera switch family
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - marvell,prestera-98dx3236
+ - marvell,prestera-98dx3336
+ - marvell,prestera-98dx4251
+ - const: marvell,prestera
+ - enum:
+ - pci11ab,c804
+ - pci11ab,c80c
+ - pci11ab,cc1e
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 3
+
+ dfx:
+ description: Reference to the DFX Server bus node.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ nvmem-cells: true
+
+ nvmem-cell-names: true
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,prestera
+
+# Memory mapped AlleyCat3 family
+then:
+ properties:
+ nvmem-cells: false
+ nvmem-cell-names: false
+ required:
+ - interrupts
+
+# PCI Aldrin family
+else:
+ properties:
+ interrupts: false
+ dfx: false
+
+required:
+ - compatible
+ - reg
+
+# Ports can also be described
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ packet-processor@0 {
+ compatible = "marvell,prestera-98dx3236", "marvell,prestera";
+ reg = <0 0x4000000>;
+ interrupts = <33>, <34>, <35>;
+ dfx = <&dfx>;
+ };
+
+ - |
+ pcie@0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0x0 0x100000 0x10000000 0x0 0x0>;
+ reg = <0x0 0x1000>;
+ device_type = "pci";
+
+ switch@0,0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ compatible = "pci11ab,c80c";
+ nvmem-cells = <&mac_address 0>;
+ nvmem-cell-names = "mac-address";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
deleted file mode 100644
index 2bf31572b08d..000000000000
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Marvell Armada 370 / Armada XP / Armada 3700 Ethernet Controller (NETA)
-
-Required properties:
-- compatible: could be one of the following:
- "marvell,armada-370-neta"
- "marvell,armada-xp-neta"
- "marvell,armada-3700-neta"
- "marvell,armada-ac5-neta"
-- reg: address and length of the register set for the device.
-- interrupts: interrupt for the device
-- phy: See ethernet.txt file in the same directory.
-- phy-mode: See ethernet.txt file in the same directory
-- clocks: List of clocks for this device. At least one clock is
- mandatory for the core clock. If several clocks are given, then the
- clock-names property must be used to identify them.
-
-Optional properties:
-- tx-csum-limit: maximum mtu supported by port that allow TX checksum.
- Value is presented in bytes. If not used, by default 1600B is set for
- "marvell,armada-370-neta" and 9800B for others.
-- clock-names: List of names corresponding to clocks property; shall be
- "core" for core clock and "bus" for the optional bus clock.
-- phys: comphy for the ethernet port, see ../phy/phy-bindings.txt
-
-Optional properties (valid only for Armada XP/38x):
-
-- buffer-manager: a phandle to a buffer manager node. Please refer to
- Documentation/devicetree/bindings/net/marvell-neta-bm.txt
-- bm,pool-long: ID of a pool, that will accept all packets of a size
- higher than 'short' pool's threshold (if set) and up to MTU value.
- Obligatory, when the port is supposed to use hardware
- buffer management.
-- bm,pool-short: ID of a pool, that will be used for accepting
- packets of a size lower than given threshold. If not set, the port
- will use a single 'long' pool for all packets, as defined above.
-
-Example:
-
-ethernet@70000 {
- compatible = "marvell,armada-370-neta";
- reg = <0x70000 0x2500>;
- interrupts = <8>;
- clocks = <&gate_clk 4>;
- tx-csum-limit = <9800>
- phy = <&phy0>;
- phy-mode = "rgmii-id";
- buffer-manager = <&bm>;
- bm,pool-long = <0>;
- bm,pool-short = <1>;
-};
diff --git a/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml b/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml
deleted file mode 100644
index 309ef21a1e37..000000000000
--- a/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml
+++ /dev/null
@@ -1,31 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/net/marvell-bluetooth.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Marvell Bluetooth chips
-
-description: |
- This documents the binding structure and common properties for serial
- attached Marvell Bluetooth devices.
-
-maintainers:
- - Rob Herring <robh@kernel.org>
-
-properties:
- compatible:
- const: mrvl,88w8897
-
-required:
- - compatible
-
-additionalProperties: false
-
-examples:
- - |
- serial {
- bluetooth {
- compatible = "mrvl,88w8897";
- };
- };
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
deleted file mode 100644
index 957e5e5c2927..000000000000
--- a/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
-------
-The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
-the btmrvl driver is used and when used on USB interface, the btusb driver is
-used.
-
-Required properties:
-
- - compatible : should be one of the following:
- * "marvell,sd8897-bt" (for SDIO)
- * "marvell,sd8997-bt" (for SDIO)
- * "usb1286,204e" (for USB)
-
-Optional properties:
-
- - marvell,cal-data: Calibration data downloaded to the device during
- initialization. This is an array of 28 values(u8).
- This is only applicable to SDIO devices.
-
- - marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
- firmware will use the pin to wakeup host system (u16).
- - marvell,wakeup-gap-ms: wakeup gap represents wakeup latency of the host
- platform. The value will be configured to firmware. This
- is needed to work chip's sleep feature as expected (u16).
- - interrupt-names: Used only for USB based devices (See below)
- - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
- driver will use the first interrupt specified in the interrupt
- array. For USB based devices, the driver will use the interrupt
- named "wakeup" from the interrupt-names and interrupt arrays.
- The driver will request an irq based on this interrupt number.
- During system suspend, the irq will be enabled so that the
- bluetooth chip can wakeup host platform under certain
- conditions. During system resume, the irq will be disabled
- to make sure unnecessary interrupt is not received.
-
-Example:
-
-IRQ pin 119 is used as system wakeup source interrupt.
-wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
-using this device side pin and wakeup latency.
-
-Example for SDIO device follows (calibration data is also available in
-below example).
-
-&mmc3 {
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
-
- #address-cells = <1>;
- #size-cells = <0>;
- btmrvl: bluetooth@2 {
- compatible = "marvell,sd8897-bt";
- reg = <2>;
- interrupt-parent = <&pio>;
- interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
-
- marvell,cal-data = /bits/ 8 <
- 0x37 0x01 0x1c 0x00 0xff 0xff 0xff 0xff 0x01 0x7f 0x04 0x02
- 0x00 0x00 0xba 0xce 0xc0 0xc6 0x2d 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0xf0 0x00>;
- marvell,wakeup-pin = /bits/ 16 <0x0d>;
- marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
- };
-};
-
-Example for USB device:
-
-&usb_host1_ohci {
- #address-cells = <1>;
- #size-cells = <0>;
-
- mvl_bt1: bt@1 {
- compatible = "usb1286,204e";
- reg = <1>;
- interrupt-parent = <&gpio0>;
- interrupt-names = "wakeup";
- interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
- marvell,wakeup-pin = /bits/ 16 <0x0d>;
- marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/marvell-neta-bm.txt b/Documentation/devicetree/bindings/net/marvell-neta-bm.txt
deleted file mode 100644
index 07b31050dbe5..000000000000
--- a/Documentation/devicetree/bindings/net/marvell-neta-bm.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Marvell Armada 380/XP Buffer Manager driver (BM)
-
-Required properties:
-
-- compatible: should be "marvell,armada-380-neta-bm".
-- reg: address and length of the register set for the device.
-- clocks: a pointer to the reference clock for this device.
-- internal-mem: a phandle to BM internal SRAM definition.
-
-Optional properties (port):
-
-- pool<0 : 3>,capacity: size of external buffer pointers' ring maintained
- in DRAM. Can be set for each pool (id 0 : 3) separately. The value has
- to be chosen between 128 and 16352 and it also has to be aligned to 32.
- Otherwise the driver would adjust a given number or choose default if
- not set.
-- pool<0 : 3>,pkt-size: maximum size of a packet accepted by a given buffer
- pointers' pool (id 0 : 3). It will be taken into consideration only when pool
- type is 'short'. For 'long' ones it would be overridden by port's MTU.
- If not set a driver will choose a default value.
-
-In order to see how to hook the BM to a given ethernet port, please
-refer to Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt.
-
-Example:
-
-- main node:
-
-bm: bm@c8000 {
- compatible = "marvell,armada-380-neta-bm";
- reg = <0xc8000 0xac>;
- clocks = <&gateclk 13>;
- internal-mem = <&bm_bppi>;
- pool2,capacity = <4096>;
- pool1,pkt-size = <512>;
-};
-
-- internal SRAM node:
-
-bm_bppi: bm-bppi {
- compatible = "mmio-sram";
- reg = <MBUS_ID(0x0c, 0x04) 0 0x100000>;
- ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>;
- #address-cells = <1>;
- #size-cells = <1>;
- clocks = <&gateclk 13>;
-};
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt
deleted file mode 100644
index ce15c173f43f..000000000000
--- a/Documentation/devicetree/bindings/net/marvell-pp2.txt
+++ /dev/null
@@ -1,141 +0,0 @@
-* Marvell Armada 375 Ethernet Controller (PPv2.1)
- Marvell Armada 7K/8K Ethernet Controller (PPv2.2)
- Marvell CN913X Ethernet Controller (PPv2.3)
-
-Required properties:
-
-- compatible: should be one of:
- "marvell,armada-375-pp2"
- "marvell,armada-7k-pp2"
-- reg: addresses and length of the register sets for the device.
- For "marvell,armada-375-pp2", must contain the following register
- sets:
- - common controller registers
- - LMS registers
- - one register area per Ethernet port
- For "marvell,armada-7k-pp2" used by 7K/8K and CN913X, must contain the following register
- sets:
- - packet processor registers
- - networking interfaces registers
- - CM3 address space used for TX Flow Control
-
-- clocks: pointers to the reference clocks for this device, consequently:
- - main controller clock (for both armada-375-pp2 and armada-7k-pp2)
- - GOP clock (for both armada-375-pp2 and armada-7k-pp2)
- - MG clock (only for armada-7k-pp2)
- - MG Core clock (only for armada-7k-pp2)
- - AXI clock (only for armada-7k-pp2)
-- clock-names: names of used clocks, must be "pp_clk", "gop_clk", "mg_clk",
- "mg_core_clk" and "axi_clk" (the 3 latter only for armada-7k-pp2).
-
-The ethernet ports are represented by subnodes. At least one port is
-required.
-
-Required properties (port):
-
-- interrupts: interrupt(s) for the port
-- port-id: ID of the port from the MAC point of view
-- gop-port-id: only for marvell,armada-7k-pp2, ID of the port from the
- GOP (Group Of Ports) point of view. This ID is used to index the
- per-port registers in the second register area.
-- phy-mode: See ethernet.txt file in the same directory
-
-Optional properties (port):
-
-- marvell,loopback: port is loopback mode
-- phy: a phandle to a phy node defining the PHY address (as the reg
- property, a single integer).
-- interrupt-names: if more than a single interrupt for is given, must be the
- name associated to the interrupts listed. Valid names are:
- "hifX", with X in [0..8], and "link". The names "tx-cpu0",
- "tx-cpu1", "tx-cpu2", "tx-cpu3" and "rx-shared" are supported
- for backward compatibility but shouldn't be used for new
- additions.
-- marvell,system-controller: a phandle to the system controller.
-
-Example for marvell,armada-375-pp2:
-
-ethernet@f0000 {
- compatible = "marvell,armada-375-pp2";
- reg = <0xf0000 0xa000>,
- <0xc0000 0x3060>,
- <0xc4000 0x100>,
- <0xc5000 0x100>;
- clocks = <&gateclk 3>, <&gateclk 19>;
- clock-names = "pp_clk", "gop_clk";
-
- eth0: eth0@c4000 {
- interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
- port-id = <0>;
- phy = <&phy0>;
- phy-mode = "gmii";
- };
-
- eth1: eth1@c5000 {
- interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
- port-id = <1>;
- phy = <&phy3>;
- phy-mode = "gmii";
- };
-};
-
-Example for marvell,armada-7k-pp2:
-
-cpm_ethernet: ethernet@0 {
- compatible = "marvell,armada-7k-pp22";
- reg = <0x0 0x100000>, <0x129000 0xb000>, <0x220000 0x800>;
- clocks = <&cpm_syscon0 1 3>, <&cpm_syscon0 1 9>,
- <&cpm_syscon0 1 5>, <&cpm_syscon0 1 6>, <&cpm_syscon0 1 18>;
- clock-names = "pp_clk", "gop_clk", "mg_clk", "mg_core_clk", "axi_clk";
-
- eth0: eth0 {
- interrupts = <ICU_GRP_NSR 39 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 43 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 47 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 51 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 55 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 59 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 63 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 67 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 71 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 129 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
- "hif5", "hif6", "hif7", "hif8", "link";
- port-id = <0>;
- gop-port-id = <0>;
- };
-
- eth1: eth1 {
- interrupts = <ICU_GRP_NSR 40 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 44 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 48 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 52 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 56 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 60 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 64 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 68 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 72 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 128 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
- "hif5", "hif6", "hif7", "hif8", "link";
- port-id = <1>;
- gop-port-id = <2>;
- };
-
- eth2: eth2 {
- interrupts = <ICU_GRP_NSR 41 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 45 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 49 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 53 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 57 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 61 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 65 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 69 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 73 IRQ_TYPE_LEVEL_HIGH>,
- <ICU_GRP_NSR 127 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "hif0", "hif1", "hif2", "hif3", "hif4",
- "hif5", "hif6", "hif7", "hif8", "link";
- port-id = <2>;
- gop-port-id = <3>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/maxim,ds26522.txt b/Documentation/devicetree/bindings/net/maxim,ds26522.txt
deleted file mode 100644
index ee8bb725f245..000000000000
--- a/Documentation/devicetree/bindings/net/maxim,ds26522.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* Maxim (Dallas) DS26522 Dual T1/E1/J1 Transceiver
-
-Required properties:
-- compatible: Should contain "maxim,ds26522".
-- reg: SPI CS.
-- spi-max-frequency: SPI clock.
-
-Example:
- slic@1 {
- compatible = "maxim,ds26522";
- reg = <1>;
- spi-max-frequency = <2000000>; /* input clock */
- };
diff --git a/Documentation/devicetree/bindings/net/maxim,ds26522.yaml b/Documentation/devicetree/bindings/net/maxim,ds26522.yaml
new file mode 100644
index 000000000000..6c97eda217e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxim,ds26522.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/maxim,ds26522.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim (Dallas) DS26522 Dual T1/E1/J1 Transceiver
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - const: maxim,ds26522
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ transceiver@1 {
+ compatible = "maxim,ds26522";
+ reg = <1>;
+ spi-max-frequency = <2000000>; /* input clock */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
new file mode 100644
index 000000000000..8a3713abd1ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/maxlinear,gpy2xx.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/maxlinear,gpy2xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxLinear GPY2xx PHY
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Michael Walle <michael@walle.cc>
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ maxlinear,use-broken-interrupts:
+ description: |
+ Interrupts are broken on some GPY2xx PHYs in that they keep the
+ interrupt line asserted for a random amount of time even after the
+ interrupt status register is cleared. Thus it is blocking the
+ interrupt line which is usually bad for shared lines. By default,
+ interrupts are disabled for this PHY and polling mode is used. If one
+ can live with the consequences, this property can be used to enable
+ interrupt handling.
+
+ Affected PHYs (as far as known) are GPY215B and GPY215C.
+ type: boolean
+
+dependencies:
+ maxlinear,use-broken-interrupts: [ interrupts ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&intc 0>;
+ maxlinear,use-broken-interrupts;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml b/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml
index afd11c9422fa..8438af53c5c3 100644
--- a/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml
+++ b/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/mctp-i2c-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MCTP I2C transport binding
+title: MCTP I2C transport
maintainers:
- Matt Johnston <matt@codeconstruct.com.au>
diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-gpio.yaml
index 1d83b8dcce2c..eb4171a1940e 100644
--- a/Documentation/devicetree/bindings/net/mdio-gpio.yaml
+++ b/Documentation/devicetree/bindings/net/mdio-gpio.yaml
@@ -12,7 +12,7 @@ maintainers:
- Russell King <linux@armlinux.org.uk>
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
properties:
compatible:
@@ -33,8 +33,8 @@ properties:
- description: MDIO
- description: MDO
-#Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases"
-#node.
+# Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases"
+# node.
additionalProperties:
type: object
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml
index 71c25c4580ea..cc674b21588c 100644
--- a/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml
+++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml
@@ -53,37 +53,21 @@ examples:
ethernet-phy@1 {
reg = <1>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <10 8>; /* Pin 10, active low */
};
ethernet-phy@2 {
reg = <2>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <10 8>; /* Pin 10, active low */
};
ethernet-phy@3 {
reg = <3>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <10 8>; /* Pin 10, active low */
};
ethernet-phy@4 {
reg = <4>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <10 8>; /* Pin 10, active low */
};
@@ -96,37 +80,21 @@ examples:
ethernet-phy@1 {
reg = <1>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <12 8>; /* Pin 12, active low */
};
ethernet-phy@2 {
reg = <2>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <12 8>; /* Pin 12, active low */
};
ethernet-phy@3 {
reg = <3>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <12 8>; /* Pin 12, active low */
};
ethernet-phy@4 {
reg = <4>;
- marvell,reg-init = <3 0x10 0 0x5777>,
- <3 0x11 0 0x00aa>,
- <3 0x12 0 0x4105>,
- <3 0x13 0 0x0a60>;
interrupt-parent = <&gpio>;
interrupts = <12 8>; /* Pin 12, active low */
};
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt b/Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt
deleted file mode 100644
index 3a96cbed9294..000000000000
--- a/Documentation/devicetree/bindings/net/mdio-mux-meson-g12a.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Properties for the MDIO bus multiplexer/glue of Amlogic G12a SoC family.
-
-This is a special case of a MDIO bus multiplexer. It allows to choose between
-the internal mdio bus leading to the embedded 10/100 PHY or the external
-MDIO bus.
-
-Required properties in addition to the generic multiplexer properties:
-- compatible : amlogic,g12a-mdio-mux
-- reg: physical address and length of the multiplexer/glue registers
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "clkin0" : platform crytal
- * "clkin1" : SoC 50MHz MPLL
-
-Example :
-
-mdio_mux: mdio-multiplexer@4c000 {
- compatible = "amlogic,g12a-mdio-mux";
- reg = <0x0 0x4c000 0x0 0xa4>;
- clocks = <&clkc CLKID_ETH_PHY>,
- <&xtal>,
- <&clkc CLKID_MPLL_5OM>;
- clock-names = "pclk", "clkin0", "clkin1";
- mdio-parent-bus = <&mdio0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- ext_mdio: mdio@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
- int_mdio: mdio@1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- internal_ephy: ethernet-phy@8 {
- compatible = "ethernet-phy-id0180.3301",
- "ethernet-phy-ieee802.3-c22";
- interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
- reg = <8>;
- max-speed = <100>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml
index 282987074ee4..23947ba6aeaf 100644
--- a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml
+++ b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml
@@ -14,7 +14,6 @@ description: |+
of a mux producer device. The mux producer can be of any type like mmio mux
producer, gpio mux producer or generic register based mux producer.
-
allOf:
- $ref: /schemas/net/mdio-mux.yaml#
diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml
index b5706d4e7e38..bed3987a8fbf 100644
--- a/Documentation/devicetree/bindings/net/mdio.yaml
+++ b/Documentation/devicetree/bindings/net/mdio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/mdio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MDIO Bus Generic Binding
+title: MDIO Bus Common Properties
maintainers:
- Andrew Lunn <andrew@lunn.ch>
@@ -19,7 +19,7 @@ description:
properties:
$nodename:
- pattern: "^mdio(@.*)?"
+ pattern: '^mdio(-(bus|external))?(@.+|-([0-9]+))?$'
"#address-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml
index 7ef696204c5a..cc346946291a 100644
--- a/Documentation/devicetree/bindings/net/mediatek,net.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml
@@ -19,20 +19,40 @@ properties:
enum:
- mediatek,mt2701-eth
- mediatek,mt7623-eth
+ - mediatek,mt7621-eth
- mediatek,mt7622-eth
- mediatek,mt7629-eth
+ - mediatek,mt7981-eth
- mediatek,mt7986-eth
+ - mediatek,mt7988-eth
- ralink,rt5350-eth
reg:
maxItems: 1
- clocks: true
- clock-names: true
+ clocks:
+ minItems: 2
+ maxItems: 24
+
+ clock-names:
+ minItems: 2
+ maxItems: 24
interrupts:
- minItems: 3
- maxItems: 4
+ minItems: 1
+ maxItems: 8
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: fe0
+ - const: fe1
+ - const: fe2
+ - const: fe3
+ - const: pdma0
+ - const: pdma1
+ - const: pdma2
+ - const: pdma3
power-domains:
maxItems: 1
@@ -46,6 +66,10 @@ properties:
- const: gmac
- const: ppe
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to mmio SRAM
+
mediatek,ethsys:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -59,6 +83,23 @@ properties:
Phandle to the mediatek hifsys controller used to provide various clocks
and reset to the system.
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon node that handles the path from GMAC to
+ PHY variants.
+
+ mediatek,pcie-mirror:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the mediatek pcie-mirror controller.
+
+ mediatek,pctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon node that handles the ports slew rate and
+ driver current.
+
mediatek,sgmiisys:
$ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
@@ -71,13 +112,18 @@ properties:
mediatek,wed:
$ref: /schemas/types.yaml#/definitions/phandle-array
- minItems: 2
+ minItems: 1
maxItems: 2
items:
maxItems: 1
description:
List of phandles to wireless ethernet dispatch nodes.
+ mediatek,wed-pcie:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the mediatek wed-pcie controller.
+
dma-coherent: true
mdio-bus:
@@ -91,7 +137,7 @@ properties:
const: 0
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
- if:
properties:
compatible:
@@ -102,6 +148,11 @@ allOf:
then:
properties:
interrupts:
+ minItems: 3
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 3
maxItems: 3
clocks:
@@ -115,14 +166,48 @@ allOf:
- const: gp1
- const: gp2
- mediatek,pctl:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the syscon node that handles the ports slew rate and
- driver current.
+ sram: false
+
+ mediatek,infracfg: false
+
+ mediatek,wed: false
+
+ mediatek,wed-pcie: false
+ else:
+ properties:
+ mediatek,pctl: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7621-eth
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ethif
+ - const: fe
+
+ sram: false
+
+ mediatek,infracfg: false
mediatek,wed: false
+ mediatek,wed-pcie: false
+
- if:
properties:
compatible:
@@ -131,6 +216,11 @@ allOf:
then:
properties:
interrupts:
+ minItems: 3
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 3
maxItems: 3
clocks:
@@ -151,14 +241,21 @@ allOf:
- const: sgmii_ck
- const: eth2pll
+ sram: false
+
+ mediatek,infracfg: false
+
mediatek,sgmiisys:
minItems: 1
maxItems: 1
- mediatek,pcie-mirror:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the mediatek pcie-mirror controller.
+ mediatek,wed:
+ minItems: 2
+
+ mediatek,wed-pcie: false
+ else:
+ properties:
+ mediatek,pcie-mirror: false
- if:
properties:
@@ -168,6 +265,11 @@ allOf:
then:
properties:
interrupts:
+ minItems: 3
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 3
maxItems: 3
clocks:
@@ -194,11 +296,7 @@ allOf:
- const: sgmii_ck
- const: eth2pll
- mediatek,infracfg:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the syscon node that handles the path from GMAC to
- PHY variants.
+ sram: false
mediatek,sgmiisys:
minItems: 2
@@ -206,6 +304,50 @@ allOf:
mediatek,wed: false
+ mediatek,wed-pcie: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7981-eth
+ then:
+ properties:
+ interrupts:
+ minItems: 8
+
+ interrupt-names:
+ minItems: 8
+
+ clocks:
+ minItems: 15
+ maxItems: 15
+
+ clock-names:
+ items:
+ - const: fe
+ - const: gp2
+ - const: gp1
+ - const: wocpu0
+ - const: sgmii_ck
+ - const: sgmii_tx250m
+ - const: sgmii_rx250m
+ - const: sgmii_cdr_ref
+ - const: sgmii_cdr_fb
+ - const: sgmii2_tx250m
+ - const: sgmii2_rx250m
+ - const: sgmii2_cdr_ref
+ - const: sgmii2_cdr_fb
+ - const: netsys0
+ - const: netsys1
+
+ mediatek,sgmiisys:
+ minItems: 2
+ maxItems: 2
+
+ mediatek,wed:
+ maxItems: 1
+
- if:
properties:
compatible:
@@ -214,7 +356,10 @@ allOf:
then:
properties:
interrupts:
- minItems: 4
+ minItems: 8
+
+ interrupt-names:
+ minItems: 8
clocks:
minItems: 15
@@ -238,19 +383,76 @@ allOf:
- const: netsys0
- const: netsys1
+ mediatek,infracfg: false
+
mediatek,sgmiisys:
minItems: 2
maxItems: 2
- mediatek,wed-pcie:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the mediatek wed-pcie controller.
+ mediatek,wed:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7988-eth
+ then:
+ properties:
+ interrupts:
+ minItems: 8
+
+ interrupt-names:
+ minItems: 8
+
+ clocks:
+ minItems: 24
+ maxItems: 24
+
+ clock-names:
+ items:
+ - const: crypto
+ - const: fe
+ - const: gp2
+ - const: gp1
+ - const: gp3
+ - const: ethwarp_wocpu2
+ - const: ethwarp_wocpu1
+ - const: ethwarp_wocpu0
+ - const: esw
+ - const: top_eth_gmii_sel
+ - const: top_eth_refck_50m_sel
+ - const: top_eth_sys_200m_sel
+ - const: top_eth_sys_sel
+ - const: top_eth_xgmii_sel
+ - const: top_eth_mii_sel
+ - const: top_netsys_sel
+ - const: top_netsys_500m_sel
+ - const: top_netsys_pao_2x_sel
+ - const: top_netsys_sync_250m_sel
+ - const: top_netsys_ppefb_250m_sel
+ - const: top_netsys_warp_sel
+ - const: xgp1
+ - const: xgp2
+ - const: xgp3
+
+ mediatek,wed:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ralink,rt5350-eth
+ then:
+ properties:
+ mediatek,wed:
+ minItems: 2
patternProperties:
- "^mac@[0-1]$":
+ "^mac@[0-2]$":
type: object
- additionalProperties: false
+ unevaluatedProperties: false
allOf:
- $ref: ethernet-controller.yaml#
description:
@@ -262,14 +464,9 @@ patternProperties:
reg:
maxItems: 1
- phy-handle: true
-
- phy-mode: true
-
required:
- reg
- compatible
- - phy-handle
required:
- compatible
@@ -378,7 +575,11 @@ examples:
interrupts = <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
+ <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ethsys CLK_ETH_FE_EN>,
<&ethsys CLK_ETH_GP2_EN>,
<&ethsys CLK_ETH_GP1_EN>,
diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
index 64c893c98d80..2e889f9a563e 100644
--- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
@@ -15,7 +15,7 @@ description:
modes with flow-control as well as CRC offloading and VLAN tags.
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
deleted file mode 100644
index 9ef5bacda8c1..000000000000
--- a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-MediaTek SoC built-in Bluetooth Devices
-==================================
-
-This device is a serial attached device to BTIF device and thus it must be a
-child node of the serial node with BTIF. The dt-bindings details for BTIF
-device can be known via Documentation/devicetree/bindings/serial/8250.yaml.
-
-Required properties:
-
-- compatible: Must be
- "mediatek,mt7622-bluetooth": for MT7622 SoC
-- clocks: Should be the clock specifiers corresponding to the entry in
- clock-names property.
-- clock-names: Should contain "ref" entries.
-- power-domains: Phandle to the power domain that the device is part of
-
-Example:
-
- btif: serial@1100c000 {
- compatible = "mediatek,mt7622-btif",
- "mediatek,mtk-btif";
- reg = <0 0x1100c000 0 0x1000>;
- interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_BTIF_PD>;
- clock-names = "main";
- reg-shift = <2>;
- reg-io-width = <4>;
-
- bluetooth {
- compatible = "mediatek,mt7622-bluetooth";
- power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
- clocks = <&clk25m>;
- clock-names = "ref";
- };
- };
-
-MediaTek UART based Bluetooth Devices
-==================================
-
-This device is a serial attached device to UART device and thus it must be a
-child node of the serial node with UART.
-
-Please refer to the following documents for generic properties:
-
- Documentation/devicetree/bindings/serial/serial.yaml
-
-Required properties:
-
-- compatible: Must be
- "mediatek,mt7663u-bluetooth": for MT7663U device
- "mediatek,mt7668u-bluetooth": for MT7668U device
-- vcc-supply: Main voltage regulator
-
-If the pin controller on the platform can support both pinmux and GPIO
-control such as the most of MediaTek platform. Please use below properties.
-
-- pinctrl-names: Should be "default", "runtime"
-- pinctrl-0: Should contain UART RXD low when the device is powered up to
- enter proper bootstrap mode.
-- pinctrl-1: Should contain UART mode pin ctrl
-
-Else, the pin controller on the platform only can support pinmux control and
-the GPIO control still has to rely on the dedicated GPIO controller such as
-a legacy MediaTek SoC, MT7621. Please use the below properties.
-
-- boot-gpios: GPIO same to the pin as UART RXD and used to keep LOW when
- the device is powered up to enter proper bootstrap mode when
-- pinctrl-names: Should be "default"
-- pinctrl-0: Should contain UART mode pin ctrl
-
-Optional properties:
-
-- reset-gpios: GPIO used to reset the device whose initial state keeps low,
- if the GPIO is missing, then board-level design should be
- guaranteed.
-- clocks: Should be the clock specifiers corresponding to the entry in
- clock-names property. If the clock is missing, then board-level
- design should be guaranteed.
-- clock-names: Should contain "osc" entry for the external oscillator.
-- current-speed: Current baud rate of the device whose defaults to 921600
-
-Example:
-
- uart1_pins_boot: uart1-default {
- pins-dat {
- pinmux = <MT7623_PIN_81_URXD1_FUNC_GPIO81>;
- output-low;
- };
- };
-
- uart1_pins_runtime: uart1-runtime {
- pins-dat {
- pinmux = <MT7623_PIN_81_URXD1_FUNC_URXD1>,
- <MT7623_PIN_82_UTXD1_FUNC_UTXD1>;
- };
- };
-
- uart1: serial@11003000 {
- compatible = "mediatek,mt7623-uart",
- "mediatek,mt6577-uart";
- reg = <0 0x11003000 0 0x400>;
- interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_UART1_SEL>,
- <&pericfg CLK_PERI_UART1>;
- clock-names = "baud", "bus";
-
- bluetooth {
- compatible = "mediatek,mt7663u-bluetooth";
- vcc-supply = <&reg_5v>;
- reset-gpios = <&pio 24 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default", "runtime";
- pinctrl-0 = <&uart1_pins_boot>;
- pinctrl-1 = <&uart1_pins_runtime>;
- current-speed = <921600>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
index 0fa2132fa4f4..3aab21b8e8de 100644
--- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml
@@ -25,7 +25,7 @@ select:
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
@@ -64,6 +64,12 @@ properties:
- const: rmii_internal
- const: mac_cg
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
power-domains:
maxItems: 1
@@ -129,7 +135,7 @@ properties:
type: boolean
description:
If present, indicates that MAC supports WOL(Wake-On-LAN), and MAC WOL will be enabled.
- Otherwise, PHY WOL is perferred.
+ Otherwise, PHY WOL is preferred.
required:
- compatible
@@ -156,7 +162,7 @@ examples:
reg = <0x1101c000 0x1300>;
interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
interrupt-names = "macirq";
- phy-mode ="rgmii-rxid";
+ phy-mode = "rgmii-rxid";
mac-address = [00 55 7b b5 7d f7];
clock-names = "axi",
"apb",
diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml
index 5aa7cf2eacb1..b726c6e14633 100644
--- a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml
+++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml
@@ -50,6 +50,7 @@ allOf:
contains:
const: micrel,ks8851
then:
+ $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
reg:
maxItems: 1
@@ -59,6 +60,7 @@ allOf:
contains:
const: micrel,ks8851-mll
then:
+ $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
properties:
reg:
minItems: 2
diff --git a/Documentation/devicetree/bindings/net/micrel-ks8995.txt b/Documentation/devicetree/bindings/net/micrel-ks8995.txt
deleted file mode 100644
index 281bc2498d12..000000000000
--- a/Documentation/devicetree/bindings/net/micrel-ks8995.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Micrel KS8995 SPI controlled Ethernet Switch families
-
-Required properties (according to spi-bus.txt):
-- compatible: either "micrel,ks8995", "micrel,ksz8864" or "micrel,ksz8795"
-
-Optional properties:
-- reset-gpios : phandle of gpio that will be used to reset chip during probe
-
-Example:
-
-spi-master {
- ...
- switch@0 {
- compatible = "micrel,ksz8795";
-
- reg = <0>;
- spi-max-frequency = <50000000>;
- reset-gpios = <&gpio0 46 GPIO_ACTIVE_LOW>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index df9e844dd6bc..6f7b907d5a04 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -13,7 +13,7 @@ KSZ9021:
All skew control options are specified in picoseconds. The minimum
value is 0, the maximum value is 3000, and it can be specified in 200ps
- steps, *but* these values are in not fact what you get because this chip's
+ steps, *but* these values are in no way what you get because this chip's
skew values actually increase in 120ps steps, starting from -840ps. The
incorrect values came from an error in the original KSZ9021 datasheet
before it was corrected in revision 1.2 (Feb 2014), but it is too late to
@@ -153,11 +153,12 @@ KSZ9031:
- micrel,force-master:
Boolean, force phy to master mode. Only set this option if the phy
reference clock provided at CLK125_NDO pin is used as MAC reference
- clock because the clock jitter in slave mode is to high (errata#2).
+ clock because the clock jitter in slave mode is too high (errata#2).
Attention: The link partner must be configurable as slave otherwise
no link will be established.
KSZ9131:
+LAN8841:
All skew control options are specified in picoseconds. The increment
step is 100ps. Unlike KSZ9031, the values represent picoseccond delays.
diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
index a407dd1b4614..01622ce58112 100644
--- a/Documentation/devicetree/bindings/net/micrel.txt
+++ b/Documentation/devicetree/bindings/net/micrel.txt
@@ -26,7 +26,7 @@ Optional properties:
Setting the RMII Reference Clock Select bit enables 25 MHz rather
than 50 MHz clock mode.
- Note that this option in only needed for certain PHY revisions with a
+ Note that this option is only needed for certain PHY revisions with a
non-standard, inverted function of this configuration bit.
Specifically, a clock reference ("rmii-ref" below) is always needed to
actually select a mode.
diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
new file mode 100644
index 000000000000..61e11d4a07c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,lan8650.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN8650/1 10BASE-T1S MACPHY Ethernet Controllers
+
+maintainers:
+ - Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
+
+description:
+ The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
+ PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
+ (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
+ with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
+ integrated into the LAN8650/1. The communication between the Host and
+ the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
+ Interface (TC6).
+
+allOf:
+ - $ref: /schemas/net/ethernet-controller.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,lan8650
+ - items:
+ - const: microchip,lan8651
+ - const: microchip,lan8650
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Interrupt from MAC-PHY asserted in the event of Receive Chunks
+ Available, Transmit Chunk Credits Available and Extended Status
+ Event.
+ maxItems: 1
+
+ spi-max-frequency:
+ minimum: 15000000
+ maximum: 25000000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - spi-max-frequency
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@0 {
+ compatible = "microchip,lan8651", "microchip,lan8650";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&eth0_pins>;
+ interrupt-parent = <&gpio>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ local-mac-address = [04 05 06 01 02 03];
+ spi-max-frequency = <15000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
index cf91fecd8909..accff93d38f8 100644
--- a/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/microchip,lan95xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: The device tree bindings for the USB Ethernet controllers
+title: Microchip SMSC9500/LAN9530/LAN9730 USB Ethernet Controllers
maintainers:
- Oleksij Rempel <o.rempel@pengutronix.de>
@@ -33,15 +33,19 @@ properties:
- usb424,9906 # SMSC9505A USB Ethernet Device (HAL)
- usb424,9907 # SMSC9500 USB Ethernet Device (Alternate ID)
- usb424,9908 # SMSC9500A USB Ethernet Device (Alternate ID)
- - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Devic. ID)
+ - usb424,9909 # SMSC9512/9514 USB Hub & Ethernet Device ID)
- usb424,9e00 # SMSC9500A USB Ethernet Device
- usb424,9e01 # SMSC9505A USB Ethernet Device
- usb424,9e08 # SMSC LAN89530 USB Ethernet Device
- usb424,ec00 # SMSC9512/9514 USB Hub & Ethernet Device
- reg: true
+ reg:
+ maxItems: 1
+
local-mac-address: true
mac-address: true
+ nvmem-cells: true
+ nvmem-cell-names: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
index dc116f14750e..306ef9ecf2b9 100644
--- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
@@ -73,7 +73,7 @@ properties:
"^port@[0-9a-f]+$":
type: object
- $ref: "/schemas/net/ethernet-controller.yaml#"
+ $ref: /schemas/net/ethernet-controller.yaml#
unevaluatedProperties: false
properties:
diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
index 57ffeb8fc876..5491d0775ede 100644
--- a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
@@ -9,6 +9,7 @@ title: Microchip Sparx5 Ethernet switch controller
maintainers:
- Steen Hegelund <steen.hegelund@microchip.com>
- Lars Povlsen <lars.povlsen@microchip.com>
+ - Daniel Machon <daniel.machon@microchip.com>
description: |
The SparX-5 Enterprise Ethernet switch family provides a rich set of
@@ -34,15 +35,34 @@ properties:
pattern: "^switch@[0-9a-f]+$"
compatible:
- const: microchip,sparx5-switch
+ oneOf:
+ - enum:
+ - microchip,lan9691-switch
+ - microchip,sparx5-switch
+ - items:
+ - enum:
+ - microchip,lan969c-switch
+ - microchip,lan969b-switch
+ - microchip,lan969a-switch
+ - microchip,lan9699-switch
+ - microchip,lan9698-switch
+ - microchip,lan9697-switch
+ - microchip,lan9696-switch
+ - microchip,lan9695-switch
+ - microchip,lan9694-switch
+ - microchip,lan9693-switch
+ - microchip,lan9692-switch
+ - const: microchip,lan9691-switch
reg:
+ minItems: 2
items:
- description: cpu target
- description: devices target
- description: general control block target
reg-names:
+ minItems: 2
items:
- const: cpu
- const: devices
@@ -99,7 +119,7 @@ properties:
microchip,bandwidth:
description: Specifies bandwidth in Mbit/s allocated to the port.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
maximum: 25000
microchip,sd-sgpio:
@@ -107,10 +127,28 @@ properties:
Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs
This is optional, and only needed if the default used index is
is not correct.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 383
+ rx-internal-delay-ps:
+ description:
+ RGMII Receive Clock Delay defined in pico seconds, used to select
+ the DLL phase shift between 1000 ps (45 degree shift at 1Gbps) and
+ 3300 ps (147 degree shift at 1Gbps). A value of 0 ps will disable
+ any delay. The Default is no delay.
+ enum: [0, 1000, 1700, 2000, 2500, 3000, 3300]
+ default: 0
+
+ tx-internal-delay-ps:
+ description:
+ RGMII Transmit Clock Delay defined in pico seconds, used to select
+ the DLL phase shift between 1000 ps (45 degree shift at 1Gbps) and
+ 3300 ps (147 degree shift at 1Gbps). A value of 0 ps will disable
+ any delay. The Default is no delay.
+ enum: [0, 1000, 1700, 2000, 2500, 3000, 3300]
+ default: 0
+
required:
- reg
- phys
@@ -132,6 +170,26 @@ required:
- interrupt-names
- ethernet-ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,lan9691-switch
+ then:
+ properties:
+ reg:
+ maxItems: 2
+ reg-names:
+ maxItems: 2
+ else:
+ properties:
+ reg:
+ minItems: 3
+ reg-names:
+ minItems: 3
+
additionalProperties: false
examples:
@@ -209,4 +267,3 @@ examples:
};
...
-# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml :
diff --git a/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
new file mode 100644
index 000000000000..26688e2302ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/motorcomm,yt8xxx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MotorComm yt8xxx Ethernet PHY
+
+maintainers:
+ - Frank Sae <frank.sae@motor-comm.com>
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id4f51.e91a
+ - ethernet-phy-id4f51.e91b
+
+ rx-internal-delay-ps:
+ description: |
+ RGMII RX Clock Delay used only when PHY operates in RGMII mode with
+ internal delay (phy-mode is 'rgmii-id' or 'rgmii-rxid') in pico-seconds.
+ enum: [ 0, 150, 300, 450, 600, 750, 900, 1050, 1200, 1350, 1500, 1650,
+ 1800, 1900, 1950, 2050, 2100, 2200, 2250, 2350, 2500, 2650, 2800,
+ 2950, 3100, 3250, 3400, 3550, 3700, 3850, 4000, 4150 ]
+ default: 1950
+
+ tx-internal-delay-ps:
+ description: |
+ RGMII TX Clock Delay used only when PHY operates in RGMII mode with
+ internal delay (phy-mode is 'rgmii-id' or 'rgmii-txid') in pico-seconds.
+ enum: [ 0, 150, 300, 450, 600, 750, 900, 1050, 1200, 1350, 1500, 1650, 1800,
+ 1950, 2100, 2250 ]
+ default: 1950
+
+ motorcomm,clk-out-frequency-hz:
+ description: clock output on clock output pin.
+ enum: [0, 25000000, 125000000]
+ default: 0
+
+ motorcomm,keep-pll-enabled:
+ description: |
+ If set, keep the PLL enabled even if there is no link. Useful if you
+ want to use the clock output without an ethernet link.
+ type: boolean
+
+ motorcomm,auto-sleep-disabled:
+ description: |
+ If set, PHY will not enter sleep mode and close AFE after unplug cable
+ for a timer.
+ type: boolean
+
+ motorcomm,rx-clk-drv-microamp:
+ description: |
+ drive strength of rx_clk rgmii pad.
+ The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can
+ be configured with hardware pull-up resistors to match the SOC voltage
+ (usually 1.8V).
+ The software can read the registers to obtain the LDO voltage and configure
+ the legal drive strength(curren).
+ =====================================================
+ | voltage | current Available (uA) |
+ | 1.8v | 1200 2100 2700 2910 3110 3600 3970 4350 |
+ | 3.3v | 3070 4080 4370 4680 5020 5450 5740 6140 |
+ =====================================================
+ enum: [ 1200, 2100, 2700, 2910, 3070, 3110, 3600, 3970,
+ 4080, 4350, 4370, 4680, 5020, 5450, 5740, 6140 ]
+ default: 2910
+
+ motorcomm,rx-data-drv-microamp:
+ description: |
+ drive strength of rx_data/rx_ctl rgmii pad.
+ The YT8531 RGMII LDO voltage supports 1.8V/3.3V, and the LDO voltage can
+ be configured with hardware pull-up resistors to match the SOC voltage
+ (usually 1.8V).
+ The software can read the registers to obtain the LDO voltage and configure
+ the legal drive strength(curren).
+ =====================================================
+ | voltage | current Available (uA) |
+ | 1.8v | 1200 2100 2700 2910 3110 3600 3970 4350 |
+ | 3.3v | 3070 4080 4370 4680 5020 5450 5740 6140 |
+ =====================================================
+ enum: [ 1200, 2100, 2700, 2910, 3070, 3110, 3600, 3970,
+ 4080, 4350, 4370, 4680, 5020, 5450, 5740, 6140 ]
+ default: 2910
+
+ motorcomm,tx-clk-adj-enabled:
+ description: |
+ This configuration is mainly to adapt to VF2 with JH7110 SoC.
+ Useful if you want to use tx-clk-xxxx-inverted to adj the delay of tx clk.
+ type: boolean
+
+ motorcomm,tx-clk-10-inverted:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 10Mbps.
+ type: boolean
+
+ motorcomm,tx-clk-100-inverted:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 100Mbps.
+ type: boolean
+
+ motorcomm,tx-clk-1000-inverted:
+ description: |
+ Use original or inverted RGMII Transmit PHY Clock to drive the RGMII
+ Transmit PHY Clock delay train configuration when speed is 1000Mbps.
+ type: boolean
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy-mode = "rgmii-id";
+ ethernet-phy@4 {
+ /* Only needed to make DT lint tools work. Do not copy/paste
+ * into real DTS files.
+ */
+ compatible = "ethernet-phy-id4f51.e91a";
+
+ reg = <4>;
+ rx-internal-delay-ps = <2100>;
+ tx-internal-delay-ps = <150>;
+ motorcomm,clk-out-frequency-hz = <0>;
+ motorcomm,keep-pll-enabled;
+ motorcomm,auto-sleep-disabled;
+ };
+ };
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy-mode = "rgmii";
+ ethernet-phy@5 {
+ /* Only needed to make DT lint tools work. Do not copy/paste
+ * into real DTS files.
+ */
+ compatible = "ethernet-phy-id4f51.e91a";
+
+ reg = <5>;
+ motorcomm,clk-out-frequency-hz = <125000000>;
+ motorcomm,keep-pll-enabled;
+ motorcomm,auto-sleep-disabled;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/mscc,miim.yaml b/Documentation/devicetree/bindings/net/mscc,miim.yaml
index 2c451cfa4e0b..792f26b06b06 100644
--- a/Documentation/devicetree/bindings/net/mscc,miim.yaml
+++ b/Documentation/devicetree/bindings/net/mscc,miim.yaml
@@ -10,7 +10,7 @@ maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
properties:
compatible:
@@ -38,6 +38,16 @@ properties:
clock-frequency: true
+ resets:
+ items:
+ - description:
+ Reset shared with all blocks attached to the Switch Core Register
+ Bus (CSR) including VRAP slave.
+
+ reset-names:
+ items:
+ - const: switch
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml
index ee0a504bdb24..86a9c3fc76c8 100644
--- a/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml
+++ b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml
@@ -18,14 +18,42 @@ description: |
packets using CPU. Additionally, PTP is supported as well as FDMA for faster
packet extraction/injection.
-properties:
- $nodename:
- pattern: "^switch@[0-9a-f]+$"
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: mscc,vsc7514-switch
+ then:
+ $ref: ethernet-switch.yaml#/$defs/ethernet-ports
+ required:
+ - interrupts
+ - interrupt-names
+ properties:
+ reg:
+ minItems: 21
+ reg-names:
+ minItems: 21
+
+ - if:
+ properties:
+ compatible:
+ const: mscc,vsc7512-switch
+ then:
+ $ref: /schemas/net/dsa/dsa.yaml#/$defs/ethernet-ports
+ properties:
+ reg:
+ maxItems: 20
+ reg-names:
+ maxItems: 20
+properties:
compatible:
- const: mscc,vsc7514-switch
+ enum:
+ - mscc,vsc7512-switch
+ - mscc,vsc7514-switch
reg:
+ minItems: 20
items:
- description: system target
- description: rewriter target
@@ -50,6 +78,7 @@ properties:
- description: fdma target
reg-names:
+ minItems: 20
items:
- const: sys
- const: rew
@@ -87,59 +116,16 @@ properties:
- const: xtr
- const: fdma
- ethernet-ports:
- type: object
-
- properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
-
- additionalProperties: false
-
- patternProperties:
- "^port@[0-9a-f]+$":
- type: object
- description: Ethernet ports handled by the switch
-
- $ref: ethernet-controller.yaml#
-
- unevaluatedProperties: false
-
- properties:
- reg:
- description: Switch port number
-
- phy-handle: true
-
- phy-mode: true
-
- fixed-link: true
-
- mac-address: true
-
- required:
- - reg
- - phy-mode
-
- oneOf:
- - required:
- - phy-handle
- - required:
- - fixed-link
-
required:
- compatible
- reg
- reg-names
- - interrupts
- - interrupt-names
- ethernet-ports
-additionalProperties: false
+unevaluatedProperties: false
examples:
+ # VSC7514 (Switchdev)
- |
switch@1010000 {
compatible = "mscc,vsc7514-switch";
@@ -187,5 +173,51 @@ examples:
};
};
};
+ # VSC7512 (DSA)
+ - |
+ ethernet-switch@1 {
+ compatible = "mscc,vsc7512-switch";
+ reg = <0x71010000 0x10000>,
+ <0x71030000 0x10000>,
+ <0x71080000 0x100>,
+ <0x710e0000 0x10000>,
+ <0x711e0000 0x100>,
+ <0x711f0000 0x100>,
+ <0x71200000 0x100>,
+ <0x71210000 0x100>,
+ <0x71220000 0x100>,
+ <0x71230000 0x100>,
+ <0x71240000 0x100>,
+ <0x71250000 0x100>,
+ <0x71260000 0x100>,
+ <0x71270000 0x100>,
+ <0x71280000 0x100>,
+ <0x71800000 0x80000>,
+ <0x71880000 0x10000>,
+ <0x71040000 0x10000>,
+ <0x71050000 0x10000>,
+ <0x71060000 0x10000>;
+ reg-names = "sys", "rew", "qs", "ptp", "port0", "port1",
+ "port2", "port3", "port4", "port5", "port6",
+ "port7", "port8", "port9", "port10", "qsys",
+ "ana", "s0", "s1", "s2";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ethernet = <&mac_sw>;
+ phy-handle = <&phy0>;
+ phy-mode = "internal";
+ };
+ port@1 {
+ reg = <1>;
+ phy-handle = <&phy1>;
+ phy-mode = "internal";
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
deleted file mode 100644
index 0a3647fe331b..000000000000
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Microsemi - vsc8531 Giga bit ethernet phy
-
-Optional properties:
-- vsc8531,vddmac : The vddmac in mV. Allowed values is listed
- in the first row of Table 1 (below).
- This property is only used in combination
- with the 'edge-slowdown' property.
- Default value is 3300.
-- vsc8531,edge-slowdown : % the edge should be slowed down relative to
- the fastest possible edge time.
- Edge rate sets the drive strength of the MAC
- interface output signals. Changing the
- drive strength will affect the edge rate of
- the output signal. The goal of this setting
- is to help reduce electrical emission (EMI)
- by being able to reprogram drive strength
- and in effect slow down the edge rate if
- desired.
- To adjust the edge-slowdown, the 'vddmac'
- must be specified. Table 1 lists the
- supported edge-slowdown values for a given
- 'vddmac'.
- Default value is 0%.
- Ref: Table:1 - Edge rate change (below).
-- vsc8531,led-[N]-mode : LED mode. Specify how the LED[N] should behave.
- N depends on the number of LEDs supported by a
- PHY.
- Allowed values are defined in
- "include/dt-bindings/net/mscc-phy-vsc8531.h".
- Default values are VSC8531_LINK_1000_ACTIVITY (1),
- VSC8531_LINK_100_ACTIVITY (2),
- VSC8531_LINK_ACTIVITY (0) and
- VSC8531_DUPLEX_COLLISION (8).
-- load-save-gpios : GPIO used for the load/save operation of the PTP
- hardware clock (PHC).
-
-
-Table: 1 - Edge rate change
-----------------------------------------------------------------|
-| Edge Rate Change (VDDMAC) |
-| |
-| 3300 mV 2500 mV 1800 mV 1500 mV |
-|---------------------------------------------------------------|
-| 0% 0% 0% 0% |
-| (Fastest) (recommended) (recommended) |
-|---------------------------------------------------------------|
-| 2% 3% 5% 6% |
-|---------------------------------------------------------------|
-| 4% 6% 9% 14% |
-|---------------------------------------------------------------|
-| 7% 10% 16% 21% |
-|(recommended) (recommended) |
-|---------------------------------------------------------------|
-| 10% 14% 23% 29% |
-|---------------------------------------------------------------|
-| 17% 23% 35% 42% |
-|---------------------------------------------------------------|
-| 29% 37% 52% 58% |
-|---------------------------------------------------------------|
-| 53% 63% 76% 77% |
-| (slowest) |
-|---------------------------------------------------------------|
-
-Example:
-
- vsc8531_0: ethernet-phy@0 {
- compatible = "ethernet-phy-id0007.0570";
- vsc8531,vddmac = <3300>;
- vsc8531,edge-slowdown = <7>;
- vsc8531,led-0-mode = <VSC8531_LINK_1000_ACTIVITY>;
- vsc8531,led-1-mode = <VSC8531_LINK_100_ACTIVITY>;
- load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.yaml b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.yaml
new file mode 100644
index 000000000000..0afbd0ff126f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/mscc-phy-vsc8531.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microsemi VSC8531 Gigabit Ethernet PHY
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ The VSC8531 is a Gigabit Ethernet PHY with configurable MAC interface
+ drive strength and LED modes.
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0007.0570 # VSC8531
+ - ethernet-phy-id0007.0772 # VSC8541
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ethernet-phy-id0007.0570 # VSC8531
+ - ethernet-phy-id0007.0772 # VSC8541
+ - const: ethernet-phy-ieee802.3-c22
+
+ vsc8531,vddmac:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The VDDMAC voltage in millivolts. This property is used in combination
+ with the edge-slowdown property to control the drive strength of the
+ MAC interface output signals.
+ enum: [3300, 2500, 1800, 1500]
+ default: 3300
+
+ vsc8531,edge-slowdown:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ Percentage by which the edge rate should be slowed down relative to
+ the fastest possible edge time. This setting helps reduce electromagnetic
+ interference (EMI) by adjusting the drive strength of the MAC interface
+ output signals. Valid values depend on the vddmac voltage setting
+ according to the edge rate change table in the datasheet.
+
+ - When vsc8531,vddmac = 3300 mV: allowed values are 0, 2, 4, 7, 10, 17, 29, and 53.
+ (Recommended: 7)
+ - When vsc8531,vddmac = 2500 mV: allowed values are 0, 3, 6, 10, 14, 23, 37, and 63.
+ (Recommended: 10)
+ - When vsc8531,vddmac = 1800 mV: allowed values are 0, 5, 9, 16, 23, 35, 52, and 76.
+ (Recommended: 0)
+ - When vsc8531,vddmac = 1500 mV: allowed values are 0, 6, 14, 21, 29, 42, 58, and 77.
+ (Recommended: 0)
+ enum: [0, 2, 3, 4, 5, 6, 7, 9, 10, 14, 16, 17, 21, 23, 29, 35, 37, 42, 52, 53, 58, 63, 76, 77]
+ default: 0
+
+ vsc8531,led-0-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: LED[0] behavior mode. See include/dt-bindings/net/mscc-phy-vsc8531.h
+ for available modes.
+ minimum: 0
+ maximum: 15
+ default: 1
+
+ vsc8531,led-1-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: LED[1] behavior mode. See include/dt-bindings/net/mscc-phy-vsc8531.h
+ for available modes.
+ minimum: 0
+ maximum: 15
+ default: 2
+
+ vsc8531,led-2-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: LED[2] behavior mode. See include/dt-bindings/net/mscc-phy-vsc8531.h
+ for available modes.
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ vsc8531,led-3-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: LED[3] behavior mode. See include/dt-bindings/net/mscc-phy-vsc8531.h
+ for available modes.
+ minimum: 0
+ maximum: 15
+ default: 8
+
+ load-save-gpios:
+ description: GPIO phandle used for the load/save operation of the PTP hardware
+ clock (PHC).
+ maxItems: 1
+
+dependencies:
+ vsc8531,edge-slowdown:
+ - vsc8531,vddmac
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/net/mscc-phy-vsc8531.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ compatible = "ethernet-phy-id0007.0772", "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ vsc8531,vddmac = <3300>;
+ vsc8531,edge-slowdown = <7>;
+ vsc8531,led-0-mode = <VSC8531_LINK_1000_ACTIVITY>;
+ vsc8531,led-1-mode = <VSC8531_LINK_100_ACTIVITY>;
+ load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/network-class.yaml b/Documentation/devicetree/bindings/net/network-class.yaml
new file mode 100644
index 000000000000..06461fb92eb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/network-class.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/network-class.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Network Class Common Properties
+
+maintainers:
+ - Devicetree Specification Mailing List <devicetree-spec@vger.kernel.org>
+
+properties:
+ address-bits:
+ description:
+ Specifies number of address bits required to address the device
+ described by this node, e.g. size of the MAC address.
+ default: 48
+ const: 48
+
+ local-mac-address:
+ description:
+ Specifies MAC address that was assigned to the network device described by
+ the node containing this property.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 6
+ maxItems: 6
+
+ mac-address:
+ description:
+ Specifies the MAC address that was last used by the boot program. This
+ property should be used in cases where the MAC address assigned to the
+ device by the boot program is different from the
+ local-mac-address property. This property shall be used only if the value
+ differs from local-mac-address property value.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 6
+ maxItems: 6
+
+ max-frame-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum transfer unit (IEEE defined MTU), rather than the
+ maximum frame size (there\'s contradiction in the Devicetree
+ Specification).
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml
index 308485a8ee6c..89663fdd3eba 100644
--- a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml
@@ -28,7 +28,7 @@ properties:
maxItems: 1
reset-n-io:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
description: |
Output GPIO pin used to reset the chip (active low)
@@ -37,13 +37,13 @@ properties:
type: boolean
description: |
For I2C type of connection. Specifies that the chip read event shall be
- trigged on falling edge.
+ triggered on falling edge.
i2c-int-rising:
type: boolean
description: |
For I2C type of connection. Specifies that the chip read event shall be
- trigged on rising edge.
+ triggered on rising edge.
break-control:
type: boolean
diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
index b2558421268a..364b36151180 100644
--- a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml
@@ -14,7 +14,10 @@ properties:
oneOf:
- const: nxp,nxp-nci-i2c
- items:
- - const: nxp,pn547
+ - enum:
+ - nxp,nq310
+ - nxp,pn547
+ - nxp,pn553
- const: nxp,nxp-nci-i2c
enable-gpios:
diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml
index 0509e0166345..07c67c1e985f 100644
--- a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml
@@ -31,7 +31,7 @@ required:
- compatible
dependencies:
- interrupts: [ 'reg' ]
+ interrupts: [ reg ]
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
index 64995cbb0f97..12baee45752c 100644
--- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml
@@ -8,7 +8,6 @@ title: Samsung S3FWRN5 NCI NFC Controller
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- - Krzysztof Opasiak <k.opasiak@samsung.com>
properties:
compatible:
@@ -70,7 +69,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c4 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml
index 9cc236ec42f2..7e96a625f0cf 100644
--- a/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml
+++ b/Documentation/devicetree/bindings/net/nfc/ti,trf7970a.yaml
@@ -55,6 +55,12 @@ properties:
description: |
Regulator for supply voltage to VIN pin
+ ti,rx-gain-reduction-db:
+ description: |
+ Specify an RX gain reduction to reduce antenna sensitivity with 5dB per
+ increment, with a maximum of 15dB.
+ enum: [ 0, 5, 10, 15]
+
required:
- compatible
- interrupts
@@ -73,7 +79,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -95,5 +101,6 @@ examples:
irq-status-read-quirk;
en2-rf-quirk;
clock-frequency = <27120000>;
+ ti,rx-gain-reduction-db = <15>;
};
};
diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
index 011363166789..e5db346beca9 100644
--- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
+++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml
@@ -4,10 +4,12 @@
$id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8 DWMAC glue layer Device Tree Bindings
+title: NXP i.MX8/9 DWMAC glue layer
maintainers:
- - Joakim Zhang <qiangqing.zhang@nxp.com>
+ - Clark Wang <xiaoning.wang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - NXP Linux Team <linux-imx@nxp.com>
# We need a select here so we don't match all nodes with 'snps,dwmac'
select:
@@ -17,11 +19,12 @@ select:
enum:
- nxp,imx8mp-dwmac-eqos
- nxp,imx8dxl-dwmac-eqos
+ - nxp,imx93-dwmac-eqos
required:
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
@@ -30,6 +33,7 @@ properties:
- enum:
- nxp,imx8mp-dwmac-eqos
- nxp,imx8dxl-dwmac-eqos
+ - nxp,imx93-dwmac-eqos
- const: snps,dwmac-5.10a
clocks:
@@ -52,6 +56,14 @@ properties:
- tx
- mem
+ interrupts:
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: macirq
+ - const: eth_wake_irq
+
intf_mode:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
@@ -62,6 +74,10 @@ properties:
Should be phandle/offset pair. The phandle to the syscon node which
encompases the GPR register, and the offset of the GPR register.
+ nvmem-cells: true
+
+ nvmem-cell-names: true
+
snps,rmii_refclk_ext:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -92,5 +108,4 @@ examples:
<&clk IMX8MP_CLK_ENET_QOS>;
clock-names = "stmmaceth", "pclk", "ptp_ref", "tx";
phy-mode = "rgmii";
- status = "disabled";
};
diff --git a/Documentation/devicetree/bindings/net/nxp,lpc-eth.yaml b/Documentation/devicetree/bindings/net/nxp,lpc-eth.yaml
new file mode 100644
index 000000000000..dfe9446a5375
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nxp,lpc-eth.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/nxp,lpc-eth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx SoC Ethernet Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc-eth
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ use-iram:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Use LPC32xx internal SRAM (IRAM) for DMA buffering
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@31060000 {
+ compatible = "nxp,lpc-eth";
+ reg = <0x31060000 0x1000>;
+ interrupt-parent = <&mic>;
+ interrupts = <29 0>;
+ phy-mode = "rmii";
+ use-iram;
+ };
diff --git a/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt b/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt
deleted file mode 100644
index 7edba1264f6f..000000000000
--- a/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* NXP LPC1850 GMAC ethernet controller
-
-This device is a platform glue layer for stmmac.
-Please see stmmac.txt for the other unchanged properties.
-
-Required properties:
- - compatible: Should contain "nxp,lpc1850-dwmac"
-
-Examples:
-
-mac: ethernet@40010000 {
- compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", "snps,dwmac";
- reg = <0x40010000 0x2000>;
- interrupts = <5>;
- interrupt-names = "macirq";
- clocks = <&ccu1 CLK_CPU_ETHERNET>;
- clock-names = "stmmaceth";
- resets = <&rgu 22>;
- reset-names = "stmmaceth";
-}
diff --git a/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.yaml b/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.yaml
new file mode 100644
index 000000000000..05acd9bc7616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/nxp,lpc1850-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1850 GMAC ethernet controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nxp,lpc1850-dwmac
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nxp,lpc1850-dwmac
+ - const: snps,dwmac-3.611
+ - const: snps,dwmac
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: stmmaceth
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: macirq
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: stmmaceth
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ ethernet@40010000 {
+ compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", "snps,dwmac";
+ reg = <0x40010000 0x2000>;
+ interrupts = <5>;
+ interrupt-names = "macirq";
+ clocks = <&ccu1 CLK_CPU_ETHERNET>;
+ clock-names = "stmmaceth";
+ resets = <&rgu 22>;
+ reset-names = "stmmaceth";
+ rx-fifo-depth = <256>;
+ tx-fifo-depth = <256>;
+ snps,pbl = <4>;
+ snps,force_thresh_dma_mode;
+ phy-mode = "rgmii-id";
+ };
diff --git a/Documentation/devicetree/bindings/net/nxp,netc-blk-ctrl.yaml b/Documentation/devicetree/bindings/net/nxp,netc-blk-ctrl.yaml
new file mode 100644
index 000000000000..deea4fd73d76
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nxp,netc-blk-ctrl.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/nxp,netc-blk-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NETC Blocks Control
+
+description:
+ Usually, NETC has 2 blocks of 64KB registers, integrated endpoint register
+ block (IERB) and privileged register block (PRB). IERB is used for pre-boot
+ initialization for all NETC devices, such as ENETC, Timer, EMIDO and so on.
+ And PRB controls global reset and global error handling for NETC. Moreover,
+ for the i.MX platform, there is also a NETCMIX block for link configuration,
+ such as MII protocol, PCS protocol, etc.
+
+maintainers:
+ - Wei Fang <wei.fang@nxp.com>
+ - Clark Wang <xiaoning.wang@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,imx94-netc-blk-ctrl
+ - nxp,imx95-netc-blk-ctrl
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: ierb
+ - const: prb
+ - const: netcmix
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges: true
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ipg
+
+ power-domains:
+ maxItems: 1
+
+patternProperties:
+ "^pcie@[0-9a-f]+$":
+ $ref: /schemas/pci/host-generic-pci.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ system-controller@4cde0000 {
+ compatible = "nxp,imx95-netc-blk-ctrl";
+ reg = <0x0 0x4cde0000 0x0 0x10000>,
+ <0x0 0x4cdf0000 0x0 0x10000>,
+ <0x0 0x4c81000c 0x0 0x18>;
+ reg-names = "ierb", "prb", "netcmix";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ clocks = <&scmi_clk 98>;
+ clock-names = "ipg";
+ power-domains = <&scmi_devpd 18>;
+
+ pcie@4cb00000 {
+ compatible = "pci-host-ecam-generic";
+ reg = <0x0 0x4cb00000 0x0 0x100000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x1 0x1>;
+ ranges = <0x82000000 0x0 0x4cce0000 0x0 0x4cce0000 0x0 0x20000
+ 0xc2000000 0x0 0x4cd10000 0x0 0x4cd10000 0x0 0x10000>;
+
+ mdio@0,0 {
+ compatible = "pci1131,ee00";
+ reg = <0x010000 0 0 0 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml b/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml
new file mode 100644
index 000000000000..2b8b74c5feec
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2021-2024 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/nxp,s32-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP S32G2xx/S32G3xx/S32R45 GMAC ethernet controller
+
+maintainers:
+ - Jan Petrous (OSS) <jan.petrous@oss.nxp.com>
+
+description:
+ This device is a Synopsys DWC IP, integrated on NXP S32G/R SoCs.
+ The SoC series S32G2xx and S32G3xx feature one DWMAC instance,
+ the SoC S32R45 has two instances. The devices can use RGMII/RMII/MII
+ interface over Pinctrl device or the output can be routed
+ to the embedded SerDes for SGMII connectivity.
+
+properties:
+ compatible:
+ oneOf:
+ - const: nxp,s32g2-dwmac
+ - items:
+ - enum:
+ - nxp,s32g3-dwmac
+ - nxp,s32r45-dwmac
+ - const: nxp,s32g2-dwmac
+
+ reg:
+ items:
+ - description: Main GMAC registers
+ - description: GMAC PHY mode control register
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
+ clocks:
+ items:
+ - description: Main GMAC clock
+ - description: Transmit clock
+ - description: Receive clock
+ - description: PTP reference clock
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: tx
+ - const: rx
+ - const: ptp_ref
+
+required:
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/phy/phy.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ethernet@4033c000 {
+ compatible = "nxp,s32g2-dwmac";
+ reg = <0x0 0x4033c000 0x0 0x2000>, /* gmac IP */
+ <0x0 0x4007c004 0x0 0x4>; /* GMAC_0_CTRL_STS */
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ clocks = <&clks 24>, <&clks 17>, <&clks 16>, <&clks 15>;
+ clock-names = "stmmaceth", "tx", "rx", "ptp_ref";
+ phy-mode = "rgmii-id";
+ phy-handle = <&phy0>;
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <5>;
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <5>;
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
index ab8867e6939b..5f9f7efff538 100644
--- a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
+++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml
@@ -14,12 +14,74 @@ maintainers:
description:
Bindings for NXP TJA11xx automotive PHYs
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id0180.dc40
+ - ethernet-phy-id0180.dc41
+ - ethernet-phy-id0180.dc48
+ - ethernet-phy-id0180.dd00
+ - ethernet-phy-id0180.dd01
+ - ethernet-phy-id0180.dd02
+ - ethernet-phy-id0180.dc80
+ - ethernet-phy-id0180.dc82
+ - ethernet-phy-id001b.b010
+ - ethernet-phy-id001b.b013
+ - ethernet-phy-id001b.b030
+ - ethernet-phy-id001b.b031
+
allOf:
- $ref: ethernet-phy.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id0180.dc40
+ - ethernet-phy-id0180.dc41
+ - ethernet-phy-id0180.dc48
+ - ethernet-phy-id0180.dd00
+ - ethernet-phy-id0180.dd01
+ - ethernet-phy-id0180.dd02
+
+ then:
+ properties:
+ nxp,rmii-refclk-in:
+ type: boolean
+ description: |
+ The REF_CLK is provided for both transmitted and received data
+ in RMII mode. This clock signal is provided by the PHY and is
+ typically derived from an external 25MHz crystal. Alternatively,
+ a 50MHz clock signal generated by an external oscillator can be
+ connected to pin REF_CLK. A third option is to connect a 25MHz
+ clock to pin CLK_IN_OUT. So, the REF_CLK should be configured
+ as input or output according to the actual circuit connection.
+ If present, indicates that the REF_CLK will be configured as
+ interface reference clock input when RMII mode enabled.
+ If not present, the REF_CLK will be configured as interface
+ reference clock output when RMII mode enabled.
+ Only supported on TJA1100 and TJA1101.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id001b.b010
+ - ethernet-phy-id001b.b013
+ - ethernet-phy-id001b.b030
+ - ethernet-phy-id001b.b031
+
+ then:
+ properties:
+ nxp,rmii-refclk-out:
+ type: boolean
+ description: Enable 50MHz RMII reference clock output on REF_CLK pin.
patternProperties:
"^ethernet-phy@[0-9a-f]+$":
type: object
+ additionalProperties: false
description: |
Some packages have multiple PHYs. Secondary PHY should be defines as
subnode of the first (parent) PHY.
@@ -31,22 +93,6 @@ patternProperties:
description:
The ID number for the child PHY. Should be +1 of parent PHY.
- nxp,rmii-refclk-in:
- type: boolean
- description: |
- The REF_CLK is provided for both transmitted and received data
- in RMII mode. This clock signal is provided by the PHY and is
- typically derived from an external 25MHz crystal. Alternatively,
- a 50MHz clock signal generated by an external oscillator can be
- connected to pin REF_CLK. A third option is to connect a 25MHz
- clock to pin CLK_IN_OUT. So, the REF_CLK should be configured
- as input or output according to the actual circuit connection.
- If present, indicates that the REF_CLK will be configured as
- interface reference clock input when RMII mode enabled.
- If not present, the REF_CLK will be configured as interface
- reference clock output when RMII mode enabled.
- Only supported on TJA1100 and TJA1101.
-
required:
- reg
@@ -59,6 +105,7 @@ examples:
#size-cells = <0>;
tja1101_phy0: ethernet-phy@4 {
+ compatible = "ethernet-phy-id0180.dc40";
reg = <0x4>;
nxp,rmii-refclk-in;
};
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
deleted file mode 100644
index 27db496f1ce8..000000000000
--- a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Oxford Semiconductor OXNAS DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: For the OX820 SoC, it should be :
- - "oxsemi,ox820-dwmac" to select glue
- - "snps,dwmac-3.512" to select IP version.
- For the OX810SE SoC, it should be :
- - "oxsemi,ox810se-dwmac" to select glue
- - "snps,dwmac-3.512" to select IP version.
-
-- clocks: Should contain phandles to the following clocks
-- clock-names: Should contain the following:
- - "stmmaceth" for the host clock - see stmmac.txt
- - "gmac" for the peripheral gate clock
-
-- oxsemi,sys-ctrl: a phandle to the system controller syscon node
-
-Example :
-
-etha: ethernet@40400000 {
- compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
- reg = <0x40400000 0x2000>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "macirq", "eth_wake_irq";
- mac-address = [000000000000]; /* Filled in by U-Boot */
- phy-mode = "rgmii";
-
- clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
- clock-names = "gmac", "stmmaceth";
- resets = <&reset RESET_MAC>;
-
- /* Regmap for sys registers */
- oxsemi,sys-ctrl = <&sys>;
-
-};
diff --git a/Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml b/Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml
new file mode 100644
index 000000000000..fbedf696c555
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pcs/fsl,lynx-pcs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Lynx PCS
+
+maintainers:
+ - Ioana Ciornei <ioana.ciornei@nxp.com>
+
+description: |
+ NXP Lynx 10G and 28G SerDes have Ethernet PCS devices which can be used as
+ protocol controllers. They are accessible over the Ethernet interface's MDIO
+ bus.
+
+properties:
+ compatible:
+ const: fsl,lynx-pcs
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ qsgmii_pcs1: ethernet-pcs@1 {
+ compatible = "fsl,lynx-pcs";
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
new file mode 100644
index 000000000000..1bacc0eeff75
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pcs/mediatek,sgmiisys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SGMIISYS Controller
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description:
+ The MediaTek SGMIISYS controller provides a SGMII PCS and some clocks
+ to the ethernet subsystem to which it is attached.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt7622-sgmiisys
+ - mediatek,mt7629-sgmiisys
+ - mediatek,mt7981-sgmiisys_0
+ - mediatek,mt7981-sgmiisys_1
+ - mediatek,mt7986-sgmiisys_0
+ - mediatek,mt7986-sgmiisys_1
+ - const: syscon
+ - items:
+ - enum:
+ - mediatek,mt7988-sgmiisys0
+ - mediatek,mt7988-sgmiisys1
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ mediatek,pnswap:
+ description: Invert polarity of the SGMII data lanes
+ type: boolean
+
+ pcs:
+ type: object
+ description: MediaTek LynxI HSGMII PCS
+ properties:
+ compatible:
+ const: mediatek,mt7988-sgmii
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: sgmii_sel
+ - const: sgmii_tx
+ - const: sgmii_rx
+
+ required:
+ - compatible
+ - clocks
+ - clock-names
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7988-sgmiisys0
+ - mediatek,mt7988-sgmiisys1
+
+ then:
+ required:
+ - pcs
+
+ else:
+ properties:
+ pcs: false
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ sgmiisys: syscon@1b128000 {
+ compatible = "mediatek,mt7622-sgmiisys", "syscon";
+ reg = <0 0x1b128000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml b/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml
index 2d33bbab7163..3adbcf56d2be 100644
--- a/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml
+++ b/Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml
@@ -4,14 +4,15 @@
$id: http://devicetree.org/schemas/net/pcs/renesas,rzn1-miic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas RZ/N1 MII converter
+title: Renesas RZ/N1, RZ/N2H and RZ/T2H MII converter
maintainers:
- Clément Léger <clement.leger@bootlin.com>
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
description: |
- This MII converter is present on the Renesas RZ/N1 SoC family. It is
- responsible to do MII passthrough or convert it to RMII/RGMII.
+ This MII converter is present on the Renesas RZ/N1, RZ/N2H and RZ/T2H SoC
+ families. It is responsible to do MII passthrough or convert it to RMII/RGMII.
properties:
'#address-cells':
@@ -21,10 +22,16 @@ properties:
const: 0
compatible:
- items:
- - enum:
- - renesas,r9a06g032-miic
- - const: renesas,rzn1-miic
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a06g032-miic
+ - const: renesas,rzn1-miic
+ - items:
+ - const: renesas,r9a09g077-miic # RZ/T2H
+ - items:
+ - const: renesas,r9a09g087-miic # RZ/N2H
+ - const: renesas,r9a09g077-miic
reg:
maxItems: 1
@@ -43,11 +50,22 @@ properties:
- const: rmii_ref
- const: hclk
+ resets:
+ items:
+ - description: Converter register reset
+ - description: Converter reset
+
+ reset-names:
+ items:
+ - const: rst
+ - const: crst
+
renesas,miic-switch-portin:
description: MII Switch PORTIN configuration. This value should use one of
- the values defined in dt-bindings/net/pcs-rzn1-miic.h.
+ the values defined in dt-bindings/net/pcs-rzn1-miic.h for RZ/N1 SoC and
+ include/dt-bindings/net/renesas,r9a09g077-pcs-miic.h for RZ/N2H, RZ/T2H SoCs.
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2]
+ enum: [0, 1, 2]
power-domains:
maxItems: 1
@@ -60,11 +78,12 @@ patternProperties:
properties:
reg:
description: MII Converter port number.
- enum: [1, 2, 3, 4, 5]
+ enum: [0, 1, 2, 3, 4, 5]
renesas,miic-input:
description: Converter input port configuration. This value should use
- one of the values defined in dt-bindings/net/pcs-rzn1-miic.h.
+ one of the values defined in dt-bindings/net/pcs-rzn1-miic.h for RZ/N1 SoC
+ and include/dt-bindings/net/renesas,r9a09g077-pcs-miic.h for RZ/N2H, RZ/T2H SoCs.
$ref: /schemas/types.yaml#/definitions/uint32
required:
@@ -73,47 +92,109 @@ patternProperties:
additionalProperties: false
- allOf:
- - if:
- properties:
- reg:
- const: 1
- then:
- properties:
- renesas,miic-input:
- const: 0
- - if:
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rzn1-miic
+ then:
+ properties:
+ renesas,miic-switch-portin:
+ enum: [1, 2]
+ resets: false
+ reset-names: false
+ patternProperties:
+ "^mii-conv@[0-5]$":
properties:
reg:
- const: 2
- then:
- properties:
- renesas,miic-input:
- enum: [1, 11]
- - if:
- properties:
- reg:
- const: 3
- then:
- properties:
- renesas,miic-input:
- enum: [7, 10]
- - if:
+ enum: [1, 2, 3, 4, 5]
+ allOf:
+ - if:
+ properties:
+ reg:
+ const: 1
+ then:
+ properties:
+ renesas,miic-input:
+ const: 0
+ - if:
+ properties:
+ reg:
+ const: 2
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [1, 11]
+ - if:
+ properties:
+ reg:
+ const: 3
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [7, 10]
+ - if:
+ properties:
+ reg:
+ const: 4
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [4, 6, 9, 13]
+ - if:
+ properties:
+ reg:
+ const: 5
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [3, 5, 8, 12]
+ else:
+ properties:
+ renesas,miic-switch-portin:
+ const: 0
+ required:
+ - resets
+ - reset-names
+ patternProperties:
+ "^mii-conv@[0-5]$":
properties:
reg:
- const: 4
- then:
- properties:
- renesas,miic-input:
- enum: [4, 6, 9, 13]
- - if:
- properties:
- reg:
- const: 5
- then:
- properties:
- renesas,miic-input:
- enum: [3, 5, 8, 12]
+ enum: [0, 1, 2, 3]
+ allOf:
+ - if:
+ properties:
+ reg:
+ const: 0
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [0, 3, 6]
+ - if:
+ properties:
+ reg:
+ const: 1
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [1, 4, 7]
+ - if:
+ properties:
+ reg:
+ const: 2
+ then:
+ properties:
+ renesas,miic-input:
+ enum: [2, 5, 8]
+ - if:
+ properties:
+ reg:
+ const: 3
+ then:
+ properties:
+ renesas,miic-input:
+ const: 1
required:
- '#address-cells'
diff --git a/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml b/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml
new file mode 100644
index 000000000000..e77eec9ac9ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pcs/snps,dw-xpcs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare Ethernet PCS
+
+maintainers:
+ - Serge Semin <fancer.lancer@gmail.com>
+
+description:
+ Synopsys DesignWare Ethernet Physical Coding Sublayer provides an interface
+ between Media Access Control and Physical Medium Attachment Sublayer through
+ the Media Independent Interface (XGMII, USXGMII, XLGMII, GMII, etc)
+ controlled by means of the IEEE std. Clause 45 registers set. The PCS can be
+ optionally synthesized with a vendor-specific interface connected to
+ Synopsys PMA (also called DesignWare Consumer/Enterprise PHY) although in
+ general it can be used to communicate with any compatible PHY.
+
+ The PCS CSRs can be accessible either over the Ethernet MDIO bus or directly
+ by means of the APB3/MCI interfaces. In the later case the XPCS can be mapped
+ right to the system IO memory space.
+
+properties:
+ compatible:
+ oneOf:
+ - description: Synopsys DesignWare XPCS with none or unknown PMA
+ const: snps,dw-xpcs
+ - description: Synopsys DesignWare XPCS with Consumer Gen1 3G PMA
+ const: snps,dw-xpcs-gen1-3g
+ - description: Synopsys DesignWare XPCS with Consumer Gen2 3G PMA
+ const: snps,dw-xpcs-gen2-3g
+ - description: Synopsys DesignWare XPCS with Consumer Gen2 6G PMA
+ const: snps,dw-xpcs-gen2-6g
+ - description: Synopsys DesignWare XPCS with Consumer Gen4 3G PMA
+ const: snps,dw-xpcs-gen4-3g
+ - description: Synopsys DesignWare XPCS with Consumer Gen4 6G PMA
+ const: snps,dw-xpcs-gen4-6g
+ - description: Synopsys DesignWare XPCS with Consumer Gen5 10G PMA
+ const: snps,dw-xpcs-gen5-10g
+ - description: Synopsys DesignWare XPCS with Consumer Gen5 12G PMA
+ const: snps,dw-xpcs-gen5-12g
+
+ reg:
+ items:
+ - description:
+ In case of the MDIO management interface this just a 5-bits ID
+ of the MDIO bus device. If DW XPCS CSRs space is accessed over the
+ MCI or APB3 management interfaces, then the space mapping can be
+ either 'direct' or 'indirect'. In the former case all Clause 45
+ registers are contiguously mapped within the address space
+ MMD '[20:16]', Reg '[15:0]'. In the later case the space is divided
+ to the multiple 256 register sets. There is a special viewport CSR
+ which is responsible for the set selection. The upper part of
+ the CSR address MMD+REG[20:8] is supposed to be written in there
+ so the corresponding subset would be mapped to the lowest 255 CSRs.
+
+ reg-names:
+ items:
+ - enum: [ direct, indirect ]
+
+ reg-io-width:
+ description:
+ The way the CSRs are mapped to the memory is platform depended. Since
+ each Clause 45 CSR is of 16-bits wide the access instructions must be
+ two bytes aligned at least.
+ default: 2
+ enum: [ 2, 4 ]
+
+ interrupts:
+ description:
+ System interface interrupt output (sbd_intr_o) indicating Clause 73/37
+ auto-negotiation events':' Page received, AN is completed or incompatible
+ link partner.
+ maxItems: 1
+
+ clocks:
+ description:
+ The MCI and APB3 interfaces are supposed to be equipped with a clock
+ source connected to the clk_csr_i line.
+
+ PCS/PMA layer can be clocked by an internal reference clock source
+ (phyN_core_refclk) or by an externally connected (phyN_pad_refclk) clock
+ generator. Both clocks can be supplied at a time.
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ oneOf:
+ - minItems: 1
+ items: # MDIO
+ - enum: [core, pad]
+ - const: pad
+ - minItems: 1
+ items: # MCI or APB
+ - const: csr
+ - enum: [core, pad]
+ - const: pad
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ethernet-pcs@1f05d000 {
+ compatible = "snps,dw-xpcs";
+ reg = <0x1f05d000 0x1000>;
+ reg-names = "indirect";
+
+ reg-io-width = <4>;
+
+ interrupts = <79 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&ccu_pclk>, <&ccu_core>, <&ccu_pad>;
+ clock-names = "csr", "core", "pad";
+ };
+ - |
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-pcs@0 {
+ compatible = "snps,dw-xpcs";
+ reg = <0>;
+
+ clocks = <&ccu_core>, <&ccu_pad>;
+ clock-names = "core", "pad";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
new file mode 100644
index 000000000000..ca61cc37a790
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
@@ -0,0 +1,192 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pse-pd/microchip,pd692x0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PD692x0 Power Sourcing Equipment controller
+
+maintainers:
+ - Kory Maincent <kory.maincent@bootlin.com>
+
+allOf:
+ - $ref: pse-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - microchip,pd69200
+ - microchip,pd69210
+ - microchip,pd69220
+
+ reg:
+ maxItems: 1
+
+ vdd-supply:
+ description: Regulator that provides 3.3V VDD power supply.
+
+ vdda-supply:
+ description: Regulator that provides 3.3V VDDA power supply.
+
+ managers:
+ type: object
+ additionalProperties: false
+ description:
+ List of the PD69208T4/PD69204T4/PD69208M PSE managers. Each manager
+ have 4 or 8 physical ports according to the chip version. No need to
+ specify the SPI chip select as it is automatically detected by the
+ PD692x0 PSE controller. The PSE managers have to be described from
+ the lowest chip select to the greatest one, which is the detection
+ behavior of the PD692x0 PSE controller. The PD692x0 support up to
+ 12 PSE managers which can expose up to 96 physical ports. All
+ physical ports available on a manager have to be described in the
+ incremental order even if they are not used.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ patternProperties:
+ "^manager@[0-9a-b]$":
+ type: object
+ additionalProperties: false
+ description:
+ PD69208T4/PD69204T4/PD69208M PSE manager exposing 4 or 8 physical
+ ports.
+
+ properties:
+ reg:
+ description:
+ Incremental index of the PSE manager starting from 0, ranging
+ from lowest to highest chip select, up to 11.
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ vmain-supply:
+ description: Regulator that provides 44-57V VMAIN power supply.
+
+ vaux5-supply:
+ description: Regulator that provides 5V VAUX5 power supply.
+
+ vaux3p3-supply:
+ description: Regulator that provides 3.3V VAUX3P3 power supply.
+
+ patternProperties:
+ '^port@[0-7]$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+required:
+ - compatible
+ - reg
+ - pse-pis
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-pse@3c {
+ compatible = "microchip,pd69200";
+ reg = <0x3c>;
+
+ managers {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ manager0: manager@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ vmain-supply = <&pse1_supply>;
+
+ phys0: port@0 {
+ reg = <0>;
+ };
+
+ phys1: port@1 {
+ reg = <1>;
+ };
+
+ phys2: port@2 {
+ reg = <2>;
+ };
+
+ phys3: port@3 {
+ reg = <3>;
+ };
+ };
+
+ manager@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phys4: port@0 {
+ reg = <0>;
+ };
+
+ phys5: port@1 {
+ reg = <1>;
+ };
+
+ phys6: port@2 {
+ reg = <2>;
+ };
+
+ phys7: port@3 {
+ reg = <3>;
+ };
+ };
+ };
+
+ pse-pis {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pse_pi0: pse-pi@0 {
+ reg = <0>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a", "alternative-b";
+ pairsets = <&phys0>, <&phys1>;
+ polarity-supported = "MDI", "S";
+ vpwr-supply = <&manager0>;
+ };
+ pse_pi1: pse-pi@1 {
+ reg = <1>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a";
+ pairsets = <&phys2>;
+ polarity-supported = "MDI";
+ vpwr-supply = <&manager0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml b/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml
index c6b1c188abf7..94a527e6aa1b 100644
--- a/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml
+++ b/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml
@@ -13,7 +13,7 @@ description: Regulator based PoDL PSE controller. The device must be referenced
by the PHY node to control power injection to the Ethernet cable.
allOf:
- - $ref: "pse-controller.yaml#"
+ - $ref: pse-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
index b110abb42597..cd09560e0aea 100644
--- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
+++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
@@ -13,20 +13,115 @@ description: Binding for the Power Sourcing Equipment (PSE) as defined in the
maintainers:
- Oleksij Rempel <o.rempel@pengutronix.de>
+ - Kory Maincent <kory.maincent@bootlin.com>
properties:
$nodename:
- pattern: "^ethernet-pse(@.*)?$"
+ pattern: "^ethernet-pse(@.*|-([0-9]|[1-9][0-9]+))?$"
"#pse-cells":
description:
Used to uniquely identify a PSE instance within an IC. Will be
0 on PSE nodes with only a single output and at least 1 on nodes
- controlling several outputs.
+ controlling several outputs which are not described in the pse-pis
+ subnode. This property is deprecated, please use pse-pis instead.
enum: [0, 1]
-required:
- - "#pse-cells"
+ pse-pis:
+ type: object
+ description:
+ Overview of the PSE PIs provided by the controller.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ patternProperties:
+ "^pse-pi@[0-9a-f]+$":
+ type: object
+ description:
+ PSE PI for power delivery via pairsets, compliant with IEEE
+ 802.3-2022, Section 145.2.4. Each pairset comprises a positive and
+ a negative VPSE pair, adhering to the pinout configurations
+ detailed in the standard.
+ See Documentation/networking/pse-pd/pse-pi.rst for details.
+
+ properties:
+ reg:
+ description:
+ Address describing the PSE PI index.
+ maxItems: 1
+
+ "#pse-cells":
+ const: 0
+
+ pairset-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ Names of the pairsets as per IEEE 802.3-2022, Section 145.2.4.
+ Each name should correspond to a phandle in the 'pairset'
+ property pointing to the power supply for that pairset.
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - alternative-a
+ - alternative-b
+
+ pairsets:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ List of phandles, each pointing to the power supply for the
+ corresponding pairset named in 'pairset-names'. This property
+ aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4.
+ PSE Pinout Alternatives (as per IEEE 802.3-2022 Table 145-3)
+ |-----------|---------------|---------------|---------------|---------------|
+ | Conductor | Alternative A | Alternative A | Alternative B | Alternative B |
+ | | (MDI-X) | (MDI) | (X) | (S) |
+ |-----------|---------------|---------------|---------------|---------------|
+ | 1 | Negative VPSE | Positive VPSE | - | - |
+ | 2 | Negative VPSE | Positive VPSE | - | - |
+ | 3 | Positive VPSE | Negative VPSE | - | - |
+ | 4 | - | - | Negative VPSE | Positive VPSE |
+ | 5 | - | - | Negative VPSE | Positive VPSE |
+ | 6 | Positive VPSE | Negative VPSE | - | - |
+ | 7 | - | - | Positive VPSE | Negative VPSE |
+ | 8 | - | - | Positive VPSE | Negative VPSE |
+ minItems: 1
+ maxItems: 2
+
+ polarity-supported:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ Polarity configuration supported by the PSE PI pairsets.
+ minItems: 1
+ maxItems: 4
+ items:
+ enum:
+ - MDI-X
+ - MDI
+ - X
+ - S
+
+ vpwr-supply:
+ description: Regulator power supply for the PSE PI.
+
+ required:
+ - reg
+ - "#pse-cells"
+
+oneOf:
+ - required:
+ - "#pse-cells"
+ - required:
+ - pse-pis
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/net/pse-pd/skyworks,si3474.yaml b/Documentation/devicetree/bindings/net/pse-pd/skyworks,si3474.yaml
new file mode 100644
index 000000000000..edd36a43a387
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pse-pd/skyworks,si3474.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pse-pd/skyworks,si3474.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Skyworks Si3474 Power Sourcing Equipment controller
+
+maintainers:
+ - Piotr Kubik <piotr.kubik@adtran.com>
+
+allOf:
+ - $ref: pse-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - skyworks,si3474
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: main
+ - const: secondary
+
+ channels:
+ description: The Si3474 is a single-chip PoE PSE controller managing
+ 8 physical power delivery channels. Internally, it's structured
+ into two logical "Quads".
+ Quad 0 Manages physical channels ('ports' in datasheet) 0, 1, 2, 3
+ Quad 1 Manages physical channels ('ports' in datasheet) 4, 5, 6, 7.
+
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ '^channel@[0-7]$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+required:
+ - compatible
+ - reg
+ - pse-pis
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-pse@26 {
+ compatible = "skyworks,si3474";
+ reg-names = "main", "secondary";
+ reg = <0x26>, <0x27>;
+
+ channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phys0_0: channel@0 {
+ reg = <0>;
+ };
+ phys0_1: channel@1 {
+ reg = <1>;
+ };
+ phys0_2: channel@2 {
+ reg = <2>;
+ };
+ phys0_3: channel@3 {
+ reg = <3>;
+ };
+ phys0_4: channel@4 {
+ reg = <4>;
+ };
+ phys0_5: channel@5 {
+ reg = <5>;
+ };
+ phys0_6: channel@6 {
+ reg = <6>;
+ };
+ phys0_7: channel@7 {
+ reg = <7>;
+ };
+ };
+ pse-pis {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pse_pi0: pse-pi@0 {
+ reg = <0>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a", "alternative-b";
+ pairsets = <&phys0_0>, <&phys0_1>;
+ polarity-supported = "MDI-X", "S";
+ vpwr-supply = <&reg_pse>;
+ };
+ pse_pi1: pse-pi@1 {
+ reg = <1>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a", "alternative-b";
+ pairsets = <&phys0_2>, <&phys0_3>;
+ polarity-supported = "MDI-X", "S";
+ vpwr-supply = <&reg_pse>;
+ };
+ pse_pi2: pse-pi@2 {
+ reg = <2>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a", "alternative-b";
+ pairsets = <&phys0_4>, <&phys0_5>;
+ polarity-supported = "MDI-X", "S";
+ vpwr-supply = <&reg_pse>;
+ };
+ pse_pi3: pse-pi@3 {
+ reg = <3>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a", "alternative-b";
+ pairsets = <&phys0_6>, <&phys0_7>;
+ polarity-supported = "MDI-X", "S";
+ vpwr-supply = <&reg_pse>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml b/Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml
new file mode 100644
index 000000000000..0b3803f647b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pse-pd/ti,tps23881.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pse-pd/ti,tps23881.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS23881 Power Sourcing Equipment controller
+
+maintainers:
+ - Kory Maincent <kory.maincent@bootlin.com>
+
+allOf:
+ - $ref: pse-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tps23881
+ - ti,tps23881b
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#pse-cells':
+ const: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ channels:
+ description: |
+ Defines the 8 physical delivery channels on the controller that can
+ be referenced by PSE PIs through their "pairsets" property. The actual
+ port matrix mapping is created when PSE PIs reference these channels in
+ their pairsets. For 4-pair operation, two channels from the same group
+ (0-3 or 4-7) must be referenced by a single PSE PI.
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ '^channel@[0-7]$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-pse@20 {
+ compatible = "ti,tps23881";
+ reg = <0x20>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gpiog>;
+
+ channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phys0: channel@0 {
+ reg = <0>;
+ };
+
+ phys1: channel@1 {
+ reg = <1>;
+ };
+
+ phys2: channel@2 {
+ reg = <2>;
+ };
+ };
+
+ pse-pis {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pse_pi0: pse-pi@0 {
+ reg = <0>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a", "alternative-b";
+ pairsets = <&phys0>, <&phys1>;
+ polarity-supported = "MDI", "S";
+ vpwr-supply = <&vpwr1>;
+ };
+
+ pse_pi1: pse-pi@1 {
+ reg = <1>;
+ #pse-cells = <0>;
+ pairset-names = "alternative-a";
+ pairsets = <&phys2>;
+ polarity-supported = "MDI";
+ vpwr-supply = <&vpwr2>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
index 1ebf9e8c8a1d..89f94b31b546 100644
--- a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
+++ b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
@@ -123,7 +123,6 @@ examples:
switch_port0: port@0 {
reg = <0x0>;
- label = "cpu";
ethernet = <&eth1>;
phy-mode = "gmii";
diff --git a/Documentation/devicetree/bindings/net/qca,ar803x.yaml b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
index 161d28919316..7ae5110e7aa2 100644
--- a/Documentation/devicetree/bindings/net/qca,ar803x.yaml
+++ b/Documentation/devicetree/bindings/net/qca,ar803x.yaml
@@ -16,8 +16,37 @@ description: |
allOf:
- $ref: ethernet-phy.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ethernet-phy-id004d.d0c0
+
+ then:
+ properties:
+ reg:
+ const: 7 # This PHY is always at MDIO address 7 in the IPQ5018 SoC
+
+ resets:
+ items:
+ - description:
+ GE PHY MISC reset which triggers a reset across MDC, DSP, RX, and TX lines.
+
+ qcom,dac-preset-short-cable:
+ description:
+ Set if this phy is connected to another phy to adjust the values for
+ MDAC and EDAC to adjust amplitude, bias current settings, and error
+ detection and correction algorithm to accommodate for short cable length.
+ If not set, DAC values are not modified and it is assumed the MDI output pins
+ of this PHY are directly connected to an RJ45 connector.
+ type: boolean
properties:
+ compatible:
+ enum:
+ - ethernet-phy-id004d.d0c0
+
qca,clk-out-frequency:
description: Clock output frequency in Hertz.
$ref: /schemas/types.yaml#/definitions/uint32
@@ -75,6 +104,7 @@ properties:
description:
Initial data for the VDDIO regulator. Set this to 1.5V or 1.8V.
$ref: /schemas/regulator/regulator.yaml
+ unevaluatedProperties: false
vddh-regulator:
type: object
@@ -82,6 +112,7 @@ properties:
Dummy subnode to model the external connection of the PHY VDDH
regulator to VDDIO.
$ref: /schemas/regulator/regulator.yaml
+ unevaluatedProperties: false
unevaluatedProperties: false
@@ -130,3 +161,17 @@ examples:
};
};
};
+ - |
+ #include <dt-bindings/reset/qcom,gcc-ipq5018.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ge_phy: ethernet-phy@7 {
+ compatible = "ethernet-phy-id004d.d0c0";
+ reg = <7>;
+
+ resets = <&gcc GCC_GEPHY_MISC_ARES>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qca,qca7000.txt b/Documentation/devicetree/bindings/net/qca,qca7000.txt
deleted file mode 100644
index 8f5ae0b84eec..000000000000
--- a/Documentation/devicetree/bindings/net/qca,qca7000.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-* Qualcomm QCA7000
-
-The QCA7000 is a serial-to-powerline bridge with a host interface which could
-be configured either as SPI or UART slave. This configuration is done by
-the QCA7000 firmware.
-
-(a) Ethernet over SPI
-
-In order to use the QCA7000 as SPI device it must be defined as a child of a
-SPI master in the device tree.
-
-Required properties:
-- compatible : Should be "qca,qca7000"
-- reg : Should specify the SPI chip select
-- interrupts : The first cell should specify the index of the source
- interrupt and the second cell should specify the trigger
- type as rising edge
-- spi-cpha : Must be set
-- spi-cpol : Must be set
-
-Optional properties:
-- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at.
- Numbers smaller than 1000000 or greater than 16000000
- are invalid. Missing the property will set the SPI
- frequency to 8000000 Hertz.
-- qca,legacy-mode : Set the SPI data transfer of the QCA7000 to legacy mode.
- In this mode the SPI master must toggle the chip select
- between each data word. In burst mode these gaps aren't
- necessary, which is faster. This setting depends on how
- the QCA7000 is setup via GPIO pin strapping. If the
- property is missing the driver defaults to burst mode.
-
-The MAC address will be determined using the optional properties
-defined in ethernet.txt.
-
-SPI Example:
-
-/* Freescale i.MX28 SPI master*/
-ssp2: spi@80014000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx28-spi";
- pinctrl-names = "default";
- pinctrl-0 = <&spi2_pins_a>;
-
- qca7000: ethernet@0 {
- compatible = "qca,qca7000";
- reg = <0x0>;
- interrupt-parent = <&gpio3>; /* GPIO Bank 3 */
- interrupts = <25 0x1>; /* Index: 25, rising edge */
- spi-cpha; /* SPI mode: CPHA=1 */
- spi-cpol; /* SPI mode: CPOL=1 */
- spi-max-frequency = <8000000>; /* freq: 8 MHz */
- local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
- };
-};
-
-(b) Ethernet over UART
-
-In order to use the QCA7000 as UART slave it must be defined as a child of a
-UART master in the device tree. It is possible to preconfigure the UART
-settings of the QCA7000 firmware, but it's not possible to change them during
-runtime.
-
-Required properties:
-- compatible : Should be "qca,qca7000"
-
-Optional properties:
-- local-mac-address : see ./ethernet.txt
-- current-speed : current baud rate of QCA7000 which defaults to 115200
- if absent, see also ../serial/serial.yaml
-
-UART Example:
-
-/* Freescale i.MX28 UART */
-auart0: serial@8006a000 {
- compatible = "fsl,imx28-auart", "fsl,imx23-auart";
- reg = <0x8006a000 0x2000>;
- pinctrl-names = "default";
- pinctrl-0 = <&auart0_2pins_a>;
-
- qca7000: ethernet {
- compatible = "qca,qca7000";
- local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
- current-speed = <38400>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/qca,qca7000.yaml b/Documentation/devicetree/bindings/net/qca,qca7000.yaml
new file mode 100644
index 000000000000..b503c3aa3616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qca,qca7000.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qca,qca7000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCA7000
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The QCA7000 is a serial-to-powerline bridge with a host interface which could
+ be configured either as SPI or UART slave. This configuration is done by
+ the QCA7000 firmware.
+
+ (a) Ethernet over SPI
+
+ In order to use the QCA7000 as SPI device it must be defined as a child of a
+ SPI master in the device tree.
+
+ (b) Ethernet over UART
+
+ In order to use the QCA7000 as UART slave it must be defined as a child of a
+ UART master in the device tree. It is possible to preconfigure the UART
+ settings of the QCA7000 firmware, but it's not possible to change them during
+ runtime
+
+properties:
+ compatible:
+ const: qca,qca7000
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ qca,legacy-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Set the SPI data transfer of the QCA7000 to legacy mode.
+ In this mode the SPI master must toggle the chip select
+ between each data word. In burst mode these gaps aren't
+ necessary, which is faster. This setting depends on how
+ the QCA7000 is setup via GPIO pin strapping. If the
+ property is missing the driver defaults to burst mode.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+ - if:
+ required:
+ - reg
+
+ then:
+ properties:
+ spi-cpha: true
+
+ spi-cpol: true
+
+ spi-max-frequency:
+ default: 8000000
+ maximum: 16000000
+ minimum: 1000000
+
+ allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+ else:
+ properties:
+ current-speed:
+ default: 115200
+
+ qca,legacy-mode: false
+
+ allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@0 {
+ compatible = "qca,qca7000";
+ reg = <0x0>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ spi-cpha;
+ spi-cpol;
+ spi-max-frequency = <8000000>;
+ local-mac-address = [ a0 b0 c0 d0 e0 f0 ];
+ };
+ };
+
+ - |
+ serial {
+ ethernet {
+ compatible = "qca,qca7000";
+ local-mac-address = [ a0 b0 c0 d0 e0 f0 ];
+ current-speed = <38400>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qca,qca808x.yaml b/Documentation/devicetree/bindings/net/qca,qca808x.yaml
new file mode 100644
index 000000000000..e2552655902a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qca,qca808x.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qca,qca808x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros QCA808X PHY
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ QCA808X PHYs can have up to 3 LEDs attached.
+ All 3 LEDs are disabled by default.
+ 2 LEDs have dedicated pins with the 3rd LED having the
+ double function of Interrupt LEDs/GPIO or additional LED.
+
+ By default this special PIN is set to LED function.
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id004d.d101
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ compatible = "ethernet-phy-id004d.d101";
+ reg = <0>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_WAN;
+ default-state = "keep";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.txt b/Documentation/devicetree/bindings/net/qcom,ethqos.txt
deleted file mode 100644
index 1f5746849a71..000000000000
--- a/Documentation/devicetree/bindings/net/qcom,ethqos.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Qualcomm Ethernet ETHQOS device
-
-This documents dwmmac based ethernet device which supports Gigabit
-ethernet for version v2.3.0 onwards.
-
-This device has following properties:
-
-Required properties:
-
-- compatible: Should be one of:
- "qcom,qcs404-ethqos"
- "qcom,sm8150-ethqos"
-
-- reg: Address and length of the register set for the device
-
-- reg-names: Should contain register names "stmmaceth", "rgmii"
-
-- clocks: Should contain phandle to clocks
-
-- clock-names: Should contain clock names "stmmaceth", "pclk",
- "ptp_ref", "rgmii"
-
-- interrupts: Should contain phandle to interrupts
-
-- interrupt-names: Should contain interrupt names "macirq", "eth_lpi"
-
-Rest of the properties are defined in stmmac.txt file in same directory
-
-
-Example:
-
-ethernet: ethernet@7a80000 {
- compatible = "qcom,qcs404-ethqos";
- reg = <0x07a80000 0x10000>,
- <0x07a96000 0x100>;
- reg-names = "stmmaceth", "rgmii";
- clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii";
- clocks = <&gcc GCC_ETH_AXI_CLK>,
- <&gcc GCC_ETH_SLAVE_AHB_CLK>,
- <&gcc GCC_ETH_PTP_CLK>,
- <&gcc GCC_ETH_RGMII_CLK>;
- interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "macirq", "eth_lpi";
- snps,reset-gpio = <&tlmm 60 GPIO_ACTIVE_LOW>;
- snps,reset-active-low;
-
- snps,txpbl = <8>;
- snps,rxpbl = <2>;
- snps,aal;
- snps,tso;
-
- phy-handle = <&phy1>;
- phy-mode = "rgmii";
-
- mdio {
- #address-cells = <0x1>;
- #size-cells = <0x0>;
- compatible = "snps,dwmac-mdio";
- phy1: phy@4 {
- device_type = "ethernet-phy";
- reg = <0x4>;
- };
- };
-
-};
diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
new file mode 100644
index 000000000000..423959cb928d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Ethernet ETHQOS device
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ dwmmac based Qualcomm ethernet devices which support Gigabit
+ ethernet (version v2.3.0 and onwards).
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcs615-ethqos
+ - const: qcom,qcs404-ethqos
+ - items:
+ - enum:
+ - qcom,qcs8300-ethqos
+ - const: qcom,sa8775p-ethqos
+ - enum:
+ - qcom,qcs404-ethqos
+ - qcom,sa8775p-ethqos
+ - qcom,sc8280xp-ethqos
+ - qcom,sm8150-ethqos
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: stmmaceth
+ - const: rgmii
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Combined signal for various interrupt events
+ - description: The interrupt that occurs when Rx exits the LPI state
+ - description: The interrupt that occurs when HW safety error triggered
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: macirq
+ - enum: [eth_lpi, sfty]
+ - const: sfty
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: pclk
+ - const: ptp_ref
+ - enum:
+ - rgmii
+ - phyaux
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: cpu-mac
+ - const: mac-mem
+
+ phys: true
+
+ phy-names:
+ const: serdes
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-qcs404.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ ethernet: ethernet@7a80000 {
+ compatible = "qcom,qcs404-ethqos";
+ reg = <0x07a80000 0x10000>,
+ <0x07a96000 0x100>;
+ reg-names = "stmmaceth", "rgmii";
+ clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii";
+ clocks = <&gcc GCC_ETH_AXI_CLK>,
+ <&gcc GCC_ETH_SLAVE_AHB_CLK>,
+ <&gcc GCC_ETH_PTP_CLK>,
+ <&gcc GCC_ETH_RGMII_CLK>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 782 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_lpi", "sfty";
+
+ rx-fifo-depth = <4096>;
+ tx-fifo-depth = <4096>;
+
+ snps,tso;
+ snps,reset-gpio = <&tlmm 60 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 10000>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&ethernet_defaults>;
+
+ phy-handle = <&phy1>;
+ phy-mode = "rgmii";
+ mdio {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ compatible = "snps,dwmac-mdio";
+ phy1: phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ device_type = "ethernet-phy";
+ reg = <0x4>;
+
+ #phy-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index dd4bb2e74880..c7f5f2ef7452 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -24,7 +24,6 @@ description:
iommu/iommu.txt and iommu/arm,smmu.yaml for more information about SMMU
bindings.
-
- |
-------- ---------
| | | |
@@ -43,13 +42,21 @@ description:
properties:
compatible:
- enum:
- - qcom,msm8998-ipa
- - qcom,sc7180-ipa
- - qcom,sc7280-ipa
- - qcom,sdm845-ipa
- - qcom,sdx55-ipa
- - qcom,sm8350-ipa
+ oneOf:
+ - enum:
+ - qcom,msm8998-ipa
+ - qcom,sc7180-ipa
+ - qcom,sc7280-ipa
+ - qcom,sdm845-ipa
+ - qcom,sdx55-ipa
+ - qcom,sdx65-ipa
+ - qcom,sm6350-ipa
+ - qcom,sm8350-ipa
+ - qcom,sm8550-ipa
+ - items:
+ - enum:
+ - qcom,sm8650-ipa
+ - const: qcom,sm8550-ipa
reg:
items:
@@ -124,22 +131,34 @@ properties:
- const: ipa-clock-enabled-valid
- const: ipa-clock-enabled
+ qcom,gsi-loader:
+ enum:
+ - self
+ - modem
+ - skip
+ description:
+ Indicates how GSI firmware should be loaded. If the AP loads
+ and validates GSI firmware, this property has value "self".
+ If the modem does this, this property has value "modem".
+ Otherwise, "skip" means GSI firmware loading is not required.
+
modem-init:
+ deprecated: true
type: boolean
description:
- If present, it indicates that the modem is responsible for
- performing early IPA initialization, including loading and
- validating firwmare used by the GSI.
+ This is the older (deprecated) way of indicating how GSI firmware
+ should be loaded. If present, the modem loads GSI firmware; if
+ absent, the AP loads GSI firmware.
memory-region:
maxItems: 1
description:
If present, a phandle for a reserved memory area that holds
the firmware passed to Trust Zone for authentication. Required
- when Trust Zone (not the modem) performs early initialization.
+ when the AP (not the modem) performs early initialization.
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
description:
If present, name (or relative path) of the file within the
firmware search path containing the firmware image used when
@@ -155,88 +174,105 @@ required:
- interconnects
- qcom,smem-states
-# Either modem-init is present, or memory-region must be present.
-oneOf:
- - required:
- - modem-init
- - required:
- - memory-region
-
-# If memory-region is present, firmware-name may optionally be present.
-# But if modem-init is present, firmware-name must not be present.
-if:
- required:
- - modem-init
-then:
- not:
- required:
- - firmware-name
+allOf:
+ # If qcom,gsi-loader is present, modem-init must not be present
+ - if:
+ required:
+ - qcom,gsi-loader
+ then:
+ properties:
+ modem-init: false
+
+ # If qcom,gsi-loader is "self", the AP loads GSI firmware, and
+ # memory-region must be specified
+ if:
+ properties:
+ qcom,gsi-loader:
+ contains:
+ const: self
+ then:
+ required:
+ - memory-region
+ else:
+ # If qcom,gsi-loader is not present, we use deprecated behavior.
+ # If modem-init is not present, the AP loads GSI firmware, and
+ # memory-region must be specified.
+ if:
+ not:
+ required:
+ - modem-init
+ then:
+ required:
+ - memory-region
additionalProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/qcom,rpmh.h>
- #include <dt-bindings/interconnect/qcom,sdm845.h>
-
- smp2p-mpss {
- compatible = "qcom,smp2p";
- interrupts = <GIC_SPI 576 IRQ_TYPE_EDGE_RISING>;
- mboxes = <&apss_shared 6>;
- qcom,smem = <94>, <432>;
- qcom,local-pid = <0>;
- qcom,remote-pid = <5>;
-
- ipa_smp2p_out: ipa-ap-to-modem {
- qcom,entry-name = "ipa";
- #qcom,smem-state-cells = <1>;
- };
-
- ipa_smp2p_in: ipa-modem-to-ap {
- qcom,entry-name = "ipa";
- interrupt-controller;
- #interrupt-cells = <2>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,sdm845.h>
+
+ smp2p-mpss {
+ compatible = "qcom,smp2p";
+ interrupts = <GIC_SPI 576 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apss_shared 6>;
+ qcom,smem = <94>, <432>;
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <5>;
+
+ ipa_smp2p_out: ipa-ap-to-modem {
+ qcom,entry-name = "ipa";
+ #qcom,smem-state-cells = <1>;
};
- ipa@1e40000 {
- compatible = "qcom,sdm845-ipa";
-
- modem-init;
-
- iommus = <&apps_smmu 0x720 0x3>;
- reg = <0x1e40000 0x7000>,
- <0x1e47000 0x2000>,
- <0x1e04000 0x2c000>;
- reg-names = "ipa-reg",
- "ipa-shared",
- "gsi";
-
- interrupts-extended = <&intc GIC_SPI 311 IRQ_TYPE_EDGE_RISING>,
- <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
- <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
- <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "ipa",
- "gsi",
- "ipa-clock-query",
- "ipa-setup-ready";
-
- clocks = <&rpmhcc RPMH_IPA_CLK>;
- clock-names = "core";
-
- interconnects =
- <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_EBI1>,
- <&rsc_hlos MASTER_IPA &rsc_hlos SLAVE_IMEM>,
- <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos SLAVE_IPA_CFG>;
- interconnect-names = "memory",
- "imem",
- "config";
-
- qcom,qmp = <&aoss_qmp>;
-
- qcom,smem-states = <&ipa_smp2p_out 0>,
- <&ipa_smp2p_out 1>;
- qcom,smem-state-names = "ipa-clock-enabled-valid",
- "ipa-clock-enabled";
+ ipa_smp2p_in: ipa-modem-to-ap {
+ qcom,entry-name = "ipa";
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
+ };
+
+ ipa@1e40000 {
+ compatible = "qcom,sc7180-ipa";
+
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+ firmware-name = "qcom/sc7180-trogdor/modem/modem.mbn";
+
+ iommus = <&apps_smmu 0x440 0x0>,
+ <&apps_smmu 0x442 0x0>;
+ reg = <0x1e40000 0x7000>,
+ <0x1e47000 0x2000>,
+ <0x1e04000 0x2c000>;
+ reg-names = "ipa-reg",
+ "ipa-shared",
+ "gsi";
+
+ interrupts-extended = <&intc GIC_SPI 311 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>,
+ <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ipa",
+ "gsi",
+ "ipa-clock-query",
+ "ipa-setup-ready";
+
+ clocks = <&rpmhcc RPMH_IPA_CLK>;
+ clock-names = "core";
+
+ interconnects =
+ <&aggre2_noc MASTER_IPA 0 &mc_virt SLAVE_EBI1 0>,
+ <&aggre2_noc MASTER_IPA 0 &system_noc SLAVE_IMEM 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_IPA_CFG 0>;
+ interconnect-names = "memory",
+ "imem",
+ "config";
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&ipa_smp2p_out 0>,
+ <&ipa_smp2p_out 1>;
+ qcom,smem-state-names = "ipa-clock-enabled-valid",
+ "ipa-clock-enabled";
+ };
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
index 2af304341772..a94480e819ac 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
@@ -4,19 +4,24 @@
$id: http://devicetree.org/schemas/net/qcom,ipq4019-mdio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm IPQ40xx MDIO Controller Device Tree Bindings
+title: Qualcomm IPQ40xx MDIO Controller
maintainers:
- Robert Marko <robert.marko@sartura.hr>
-allOf:
- - $ref: "mdio.yaml#"
-
properties:
compatible:
- enum:
- - qcom,ipq4019-mdio
- - qcom,ipq5018-mdio
+ oneOf:
+ - enum:
+ - qcom,ipq4019-mdio
+ - qcom,ipq5018-mdio
+
+ - items:
+ - enum:
+ - qcom,ipq6018-mdio
+ - qcom,ipq8074-mdio
+ - qcom,ipq9574-mdio
+ - const: qcom,ipq4019-mdio
"#address-cells":
const: 1
@@ -33,10 +38,27 @@ properties:
address range is only required by the platform IPQ50xx.
clocks:
- maxItems: 1
- description: |
- MDIO clock source frequency fixed to 100MHZ, this clock should be specified
- by the platform IPQ807x, IPQ60xx and IPQ50xx.
+ items:
+ - description: MDIO clock source frequency fixed to 100MHZ
+
+ clock-names:
+ items:
+ - const: gcc_mdio_ahb_clk
+
+ clock-frequency:
+ description:
+ The MDIO bus clock that must be output by the MDIO bus hardware, if
+ absent, the default hardware values are used.
+
+ MDC rate is feed by an external clock (fixed 100MHz) and is divider
+ internally. The default divider is /256 resulting in the default rate
+ applied of 390KHz.
+
+ To follow 802.3 standard that instruct up to 2.5MHz by default, if
+ this property is not declared and the divider is set to /256, by
+ default 1.5625Mhz is select.
+ enum: [ 390625, 781250, 1562500, 3125000, 6250000, 12500000 ]
+ default: 1562500
required:
- compatible
@@ -44,6 +66,27 @@ required:
- "#address-cells"
- "#size-cells"
+allOf:
+ - $ref: mdio.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5018-mdio
+ - qcom,ipq6018-mdio
+ - qcom,ipq8074-mdio
+ - qcom,ipq9574-mdio
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml
index d7748dd33199..164704338ef0 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml
@@ -14,7 +14,7 @@ description:
used to communicate with the gmac phy connected.
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
properties:
compatible:
@@ -53,7 +53,9 @@ examples:
reg = <0x10>;
ports {
- /* ... */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* ... */
};
};
};
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
new file mode 100644
index 000000000000..753f370b7605
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
@@ -0,0 +1,533 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qcom,ipq9574-ppe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ packet process engine (PPE)
+
+maintainers:
+ - Luo Jie <quic_luoj@quicinc.com>
+ - Lei Wei <quic_leiwei@quicinc.com>
+ - Suruchi Agarwal <quic_suruchia@quicinc.com>
+ - Pavithra R <quic_pavir@quicinc.com>
+
+description: |
+ The Ethernet functionality in the PPE (Packet Process Engine) is comprised
+ of three components, the switch core, port wrapper and Ethernet DMA.
+
+ The Switch core in the IPQ9574 PPE has maximum of 6 front panel ports and
+ two FIFO interfaces. One of the two FIFO interfaces is used for Ethernet
+ port to host CPU communication using Ethernet DMA. The other is used
+ communicating to the EIP engine which is used for IPsec offload. On the
+ IPQ9574, the PPE includes 6 GMAC/XGMACs that can be connected with external
+ Ethernet PHY. Switch core also includes BM (Buffer Management), QM (Queue
+ Management) and SCH (Scheduler) modules for supporting the packet processing.
+
+ The port wrapper provides connections from the 6 GMAC/XGMACS to UNIPHY (PCS)
+ supporting various modes such as SGMII/QSGMII/PSGMII/USXGMII/10G-BASER. There
+ are 3 UNIPHY (PCS) instances supported on the IPQ9574.
+
+ Ethernet DMA is used to transmit and receive packets between the six Ethernet
+ ports and ARM host CPU.
+
+ The follow diagram shows the PPE hardware block along with its connectivity
+ to the external hardware blocks such clock hardware blocks (CMNPLL, GCC,
+ NSS clock controller) and Ethernet PCS/PHY blocks. For depicting the PHY
+ connectivity, one 4x1 Gbps PHY (QCA8075) and two 10 GBps PHYs are used as an
+ example.
+
+ +---------+
+ | 48 MHZ |
+ +----+----+
+ |(clock)
+ v
+ +----+----+
+ +------| CMN PLL |
+ | +----+----+
+ | |(clock)
+ | v
+ | +----+----+ +----+----+ (clock) +----+----+
+ | +---| NSSCC | | GCC |--------->| MDIO |
+ | | +----+----+ +----+----+ +----+----+
+ | | |(clock & reset) |(clock)
+ | | v v
+ | | +----+---------------------+--+----------+----------+---------+
+ | | | +-----+ |EDMA FIFO | | EIP FIFO|
+ | | | | SCH | +----------+ +---------+
+ | | | +-----+ | | |
+ | | | +------+ +------+ +-------------------+ |
+ | | | | BM | | QM | IPQ9574-PPE | L2/L3 Process | |
+ | | | +------+ +------+ +-------------------+ |
+ | | | | |
+ | | | +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ |
+ | | | | MAC0 | | MAC1 | | MAC2 | | MAC3 | | XGMAC4| |XGMAC5 | |
+ | | | +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ |
+ | | | | | | | | | |
+ | | +-----+---------+---------+---------+---------+---------+-----+
+ | | | | | | | |
+ | | +---+---------+---------+---------+---+ +---+---+ +---+---+
+ +--+---->| PCS0 | | PCS1 | | PCS2 |
+ |(clock) +---+---------+---------+---------+---+ +---+---+ +---+---+
+ | | | | | | |
+ | +---+---------+---------+---------+---+ +---+---+ +---+---+
+ +------->| QCA8075 PHY | | PHY4 | | PHY5 |
+ (clock) +-------------------------------------+ +-------+ +-------+
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq9574-ppe
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PPE core clock
+ - description: PPE APB (Advanced Peripheral Bus) clock
+ - description: PPE IPE (Ingress Process Engine) clock
+ - description: PPE BM, QM and scheduler clock
+
+ clock-names:
+ items:
+ - const: ppe
+ - const: apb
+ - const: ipe
+ - const: btq
+
+ resets:
+ maxItems: 1
+ description: PPE reset, which is necessary before configuring PPE hardware
+
+ interrupts:
+ maxItems: 1
+ description: PPE switch miscellaneous interrupt
+
+ interconnects:
+ items:
+ - description: Bus interconnect path leading to PPE switch core function
+ - description: Bus interconnect path leading to PPE register access
+ - description: Bus interconnect path leading to QoS generation
+ - description: Bus interconnect path leading to timeout reference
+ - description: Bus interconnect path leading to NSS NOC from memory NOC
+ - description: Bus interconnect path leading to memory NOC from NSS NOC
+ - description: Bus interconnect path leading to enhanced memory NOC from NSS NOC
+
+ interconnect-names:
+ items:
+ - const: ppe
+ - const: ppe_cfg
+ - const: qos_gen
+ - const: timeout_ref
+ - const: nssnoc_memnoc
+ - const: memnoc_nssnoc
+ - const: memnoc_nssnoc_1
+
+ ethernet-dma:
+ type: object
+ additionalProperties: false
+ description:
+ EDMA (Ethernet DMA) is used to transmit packets between PPE and ARM
+ host CPU. There are 32 TX descriptor rings, 32 TX completion rings,
+ 24 RX descriptor rings and 8 RX fill rings supported.
+
+ properties:
+ clocks:
+ items:
+ - description: EDMA system clock
+ - description: EDMA APB (Advanced Peripheral Bus) clock
+
+ clock-names:
+ items:
+ - const: sys
+ - const: apb
+
+ resets:
+ maxItems: 1
+ description: EDMA reset
+
+ interrupts:
+ minItems: 65
+ maxItems: 65
+
+ interrupt-names:
+ minItems: 65
+ maxItems: 65
+ items:
+ oneOf:
+ - pattern: '^txcmpl_([1-2]?[0-9]|3[01])$'
+ - pattern: '^rxfill_[0-7]$'
+ - pattern: '^rxdesc_(1?[0-9]|2[0-3])$'
+ - const: misc
+ description:
+ Interrupts "txcmpl_[0-31]" are the Ethernet DMA TX completion ring interrupts.
+ Interrupts "rxfill_[0-7]" are the Ethernet DMA RX fill ring interrupts.
+ Interrupts "rxdesc_[0-23]" are the Ethernet DMA RX Descriptor ring interrupts.
+ Interrupt "misc" is the Ethernet DMA miscellaneous error interrupt.
+
+ required:
+ - clocks
+ - clock-names
+ - resets
+ - interrupts
+ - interrupt-names
+
+ ethernet-ports:
+ patternProperties:
+ "^ethernet-port@[1-6]+$":
+ type: object
+ unevaluatedProperties: false
+ $ref: ethernet-switch-port.yaml#
+
+ properties:
+ reg:
+ minimum: 1
+ maximum: 6
+ description: PPE Ethernet port ID
+
+ clocks:
+ items:
+ - description: Port MAC clock
+ - description: Port RX clock
+ - description: Port TX clock
+
+ clock-names:
+ items:
+ - const: mac
+ - const: rx
+ - const: tx
+
+ resets:
+ items:
+ - description: Port MAC reset
+ - description: Port RX reset
+ - description: Port TX reset
+
+ reset-names:
+ items:
+ - const: mac
+ - const: rx
+ - const: tx
+
+ required:
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - interconnects
+ - interconnect-names
+ - ethernet-dma
+
+allOf:
+ - $ref: ethernet-switch.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq9574-gcc.h>
+ #include <dt-bindings/clock/qcom,ipq9574-nsscc.h>
+ #include <dt-bindings/interconnect/qcom,ipq9574.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/qcom,ipq9574-nsscc.h>
+
+ ethernet-switch@3a000000 {
+ compatible = "qcom,ipq9574-ppe";
+ reg = <0x3a000000 0xbef800>;
+ clocks = <&nsscc NSS_CC_PPE_SWITCH_CLK>,
+ <&nsscc NSS_CC_PPE_SWITCH_CFG_CLK>,
+ <&nsscc NSS_CC_PPE_SWITCH_IPE_CLK>,
+ <&nsscc NSS_CC_PPE_SWITCH_BTQ_CLK>;
+ clock-names = "ppe",
+ "apb",
+ "ipe",
+ "btq";
+ resets = <&nsscc PPE_FULL_RESET>;
+ interrupts = <GIC_SPI 498 IRQ_TYPE_LEVEL_HIGH>;
+ interconnects = <&nsscc MASTER_NSSNOC_PPE &nsscc SLAVE_NSSNOC_PPE>,
+ <&nsscc MASTER_NSSNOC_PPE_CFG &nsscc SLAVE_NSSNOC_PPE_CFG>,
+ <&gcc MASTER_NSSNOC_QOSGEN_REF &gcc SLAVE_NSSNOC_QOSGEN_REF>,
+ <&gcc MASTER_NSSNOC_TIMEOUT_REF &gcc SLAVE_NSSNOC_TIMEOUT_REF>,
+ <&gcc MASTER_MEM_NOC_NSSNOC &gcc SLAVE_MEM_NOC_NSSNOC>,
+ <&gcc MASTER_NSSNOC_MEMNOC &gcc SLAVE_NSSNOC_MEMNOC>,
+ <&gcc MASTER_NSSNOC_MEM_NOC_1 &gcc SLAVE_NSSNOC_MEM_NOC_1>;
+ interconnect-names = "ppe",
+ "ppe_cfg",
+ "qos_gen",
+ "timeout_ref",
+ "nssnoc_memnoc",
+ "memnoc_nssnoc",
+ "memnoc_nssnoc_1";
+
+ ethernet-dma {
+ clocks = <&nsscc NSS_CC_PPE_EDMA_CLK>,
+ <&nsscc NSS_CC_PPE_EDMA_CFG_CLK>;
+ clock-names = "sys",
+ "apb";
+ resets = <&nsscc EDMA_HW_RESET>;
+ interrupts = <GIC_SPI 363 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 364 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 366 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 367 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 368 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 369 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 381 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 382 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 383 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 384 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 509 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 507 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 505 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 504 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 502 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 501 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 500 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 362 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 349 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 350 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 499 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "txcmpl_0",
+ "txcmpl_1",
+ "txcmpl_2",
+ "txcmpl_3",
+ "txcmpl_4",
+ "txcmpl_5",
+ "txcmpl_6",
+ "txcmpl_7",
+ "txcmpl_8",
+ "txcmpl_9",
+ "txcmpl_10",
+ "txcmpl_11",
+ "txcmpl_12",
+ "txcmpl_13",
+ "txcmpl_14",
+ "txcmpl_15",
+ "txcmpl_16",
+ "txcmpl_17",
+ "txcmpl_18",
+ "txcmpl_19",
+ "txcmpl_20",
+ "txcmpl_21",
+ "txcmpl_22",
+ "txcmpl_23",
+ "txcmpl_24",
+ "txcmpl_25",
+ "txcmpl_26",
+ "txcmpl_27",
+ "txcmpl_28",
+ "txcmpl_29",
+ "txcmpl_30",
+ "txcmpl_31",
+ "rxfill_0",
+ "rxfill_1",
+ "rxfill_2",
+ "rxfill_3",
+ "rxfill_4",
+ "rxfill_5",
+ "rxfill_6",
+ "rxfill_7",
+ "rxdesc_0",
+ "rxdesc_1",
+ "rxdesc_2",
+ "rxdesc_3",
+ "rxdesc_4",
+ "rxdesc_5",
+ "rxdesc_6",
+ "rxdesc_7",
+ "rxdesc_8",
+ "rxdesc_9",
+ "rxdesc_10",
+ "rxdesc_11",
+ "rxdesc_12",
+ "rxdesc_13",
+ "rxdesc_14",
+ "rxdesc_15",
+ "rxdesc_16",
+ "rxdesc_17",
+ "rxdesc_18",
+ "rxdesc_19",
+ "rxdesc_20",
+ "rxdesc_21",
+ "rxdesc_22",
+ "rxdesc_23",
+ "misc";
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@1 {
+ reg = <1>;
+ phy-mode = "qsgmii";
+ managed = "in-band-status";
+ phy-handle = <&phy0>;
+ pcs-handle = <&pcs0_ch0>;
+ clocks = <&nsscc NSS_CC_PORT1_MAC_CLK>,
+ <&nsscc NSS_CC_PORT1_RX_CLK>,
+ <&nsscc NSS_CC_PORT1_TX_CLK>;
+ clock-names = "mac",
+ "rx",
+ "tx";
+ resets = <&nsscc PORT1_MAC_ARES>,
+ <&nsscc PORT1_RX_ARES>,
+ <&nsscc PORT1_TX_ARES>;
+ reset-names = "mac",
+ "rx",
+ "tx";
+ };
+
+ ethernet-port@2 {
+ reg = <2>;
+ phy-mode = "qsgmii";
+ managed = "in-band-status";
+ phy-handle = <&phy1>;
+ pcs-handle = <&pcs0_ch1>;
+ clocks = <&nsscc NSS_CC_PORT2_MAC_CLK>,
+ <&nsscc NSS_CC_PORT2_RX_CLK>,
+ <&nsscc NSS_CC_PORT2_TX_CLK>;
+ clock-names = "mac",
+ "rx",
+ "tx";
+ resets = <&nsscc PORT2_MAC_ARES>,
+ <&nsscc PORT2_RX_ARES>,
+ <&nsscc PORT2_TX_ARES>;
+ reset-names = "mac",
+ "rx",
+ "tx";
+ };
+
+ ethernet-port@3 {
+ reg = <3>;
+ phy-mode = "qsgmii";
+ managed = "in-band-status";
+ phy-handle = <&phy2>;
+ pcs-handle = <&pcs0_ch2>;
+ clocks = <&nsscc NSS_CC_PORT3_MAC_CLK>,
+ <&nsscc NSS_CC_PORT3_RX_CLK>,
+ <&nsscc NSS_CC_PORT3_TX_CLK>;
+ clock-names = "mac",
+ "rx",
+ "tx";
+ resets = <&nsscc PORT3_MAC_ARES>,
+ <&nsscc PORT3_RX_ARES>,
+ <&nsscc PORT3_TX_ARES>;
+ reset-names = "mac",
+ "rx",
+ "tx";
+ };
+
+ ethernet-port@4 {
+ reg = <4>;
+ phy-mode = "qsgmii";
+ managed = "in-band-status";
+ phy-handle = <&phy3>;
+ pcs-handle = <&pcs0_ch3>;
+ clocks = <&nsscc NSS_CC_PORT4_MAC_CLK>,
+ <&nsscc NSS_CC_PORT4_RX_CLK>,
+ <&nsscc NSS_CC_PORT4_TX_CLK>;
+ clock-names = "mac",
+ "rx",
+ "tx";
+ resets = <&nsscc PORT4_MAC_ARES>,
+ <&nsscc PORT4_RX_ARES>,
+ <&nsscc PORT4_TX_ARES>;
+ reset-names = "mac",
+ "rx",
+ "tx";
+ };
+
+ ethernet-port@5 {
+ reg = <5>;
+ phy-mode = "usxgmii";
+ managed = "in-band-status";
+ phy-handle = <&phy4>;
+ pcs-handle = <&pcs1_ch0>;
+ clocks = <&nsscc NSS_CC_PORT5_MAC_CLK>,
+ <&nsscc NSS_CC_PORT5_RX_CLK>,
+ <&nsscc NSS_CC_PORT5_TX_CLK>;
+ clock-names = "mac",
+ "rx",
+ "tx";
+ resets = <&nsscc PORT5_MAC_ARES>,
+ <&nsscc PORT5_RX_ARES>,
+ <&nsscc PORT5_TX_ARES>;
+ reset-names = "mac",
+ "rx",
+ "tx";
+ };
+
+ ethernet-port@6 {
+ reg = <6>;
+ phy-mode = "usxgmii";
+ managed = "in-band-status";
+ phy-handle = <&phy5>;
+ pcs-handle = <&pcs2_ch0>;
+ clocks = <&nsscc NSS_CC_PORT6_MAC_CLK>,
+ <&nsscc NSS_CC_PORT6_RX_CLK>,
+ <&nsscc NSS_CC_PORT6_TX_CLK>;
+ clock-names = "mac",
+ "rx",
+ "tx";
+ resets = <&nsscc PORT6_MAC_ARES>,
+ <&nsscc PORT6_RX_ARES>,
+ <&nsscc PORT6_TX_ARES>;
+ reset-names = "mac",
+ "rx",
+ "tx";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qcom,qca807x.yaml b/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
new file mode 100644
index 000000000000..7290024024f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qcom,qca807x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCA807x Ethernet PHY
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+ - Robert Marko <robert.marko@sartura.hr>
+
+description: |
+ Qualcomm QCA8072/5 Ethernet PHY is PHY package of 2 or 5
+ IEEE 802.3 clause 22 compliant 10BASE-Te, 100BASE-TX and
+ 1000BASE-T PHY-s.
+
+ They feature 2 SerDes, one for PSGMII or QSGMII connection with
+ MAC, while second one is SGMII for connection to MAC or fiber.
+
+ Both models have a combo port that supports 1000BASE-X and
+ 100BASE-FX fiber.
+
+ Each PHY inside of QCA807x series has 4 digitally controlled
+ output only pins that natively drive LED-s for up to 2 attached
+ LEDs. Some vendor also use these 4 output for GPIO usage without
+ attaching LEDs.
+
+ Note that output pins can be set to drive LEDs OR GPIO, mixed
+ definition are not accepted.
+
+$ref: ethernet-phy-package.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,qca8072-package
+ - qcom,qca8075-package
+
+ qcom,package-mode:
+ description: |
+ PHY package can be configured in 3 mode following this table:
+
+ First Serdes mode Second Serdes mode
+ Option 1 PSGMII for copper Disabled
+ ports 0-4
+ Option 2 PSGMII for copper 1000BASE-X / 100BASE-FX
+ ports 0-4
+ Option 3 QSGMII for copper SGMII for
+ ports 0-3 copper port 4
+
+ PSGMII mode (option 1 or 2) is configured dynamically based on
+ the presence of a connected SFP device.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - qsgmii
+ - psgmii
+ default: psgmii
+
+ qcom,tx-drive-strength-milliwatt:
+ description: set the TX Amplifier value in mv.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [140, 160, 180, 200, 220,
+ 240, 260, 280, 300, 320,
+ 400, 500, 600]
+ default: 600
+
+patternProperties:
+ ^ethernet-phy@[a-f0-9]+$:
+ $ref: ethernet-phy.yaml#
+
+ properties:
+ qcom,dac-full-amplitude:
+ description:
+ Set Analog MDI driver amplitude to FULL.
+
+ With this not defined, amplitude is set to DSP.
+ (amplitude is adjusted based on cable length)
+
+ With this enabled and qcom,dac-full-bias-current
+ and qcom,dac-disable-bias-current-tweak disabled,
+ bias current is half.
+ type: boolean
+
+ qcom,dac-full-bias-current:
+ description:
+ Set Analog MDI driver bias current to FULL.
+
+ With this not defined, bias current is set to DSP.
+ (bias current is adjusted based on cable length)
+
+ Actual bias current might be different with
+ qcom,dac-disable-bias-current-tweak disabled.
+ type: boolean
+
+ qcom,dac-disable-bias-current-tweak:
+ description: |
+ Set Analog MDI driver bias current to disable tweak
+ to bias current.
+
+ With this not defined, bias current tweak are enabled
+ by default.
+
+ With this enabled the following tweak are NOT applied:
+ - With both FULL amplitude and FULL bias current: bias current
+ is set to half.
+ - With only DSP amplitude: bias current is set to half and
+ is set to 1/4 with cable < 10m.
+ - With DSP bias current (included both DSP amplitude and
+ DSP bias current): bias current is half the detected current
+ with cable < 10m.
+ type: boolean
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ if:
+ required:
+ - gpio-controller
+ then:
+ properties:
+ leds: false
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy-package@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "qcom,qca8075-package";
+ reg = <0>;
+
+ qcom,package-mode = "qsgmii";
+
+ ethernet-phy@0 {
+ reg = <0>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
+ };
+
+ ethernet-phy@1 {
+ reg = <1>;
+ };
+
+ ethernet-phy@2 {
+ reg = <2>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ ethernet-phy@3 {
+ reg = <3>;
+ };
+
+ ethernet-phy@4 {
+ reg = <4>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml
deleted file mode 100644
index f93c6e7a1b59..000000000000
--- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml
+++ /dev/null
@@ -1,183 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/net/qualcomm-bluetooth.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Bluetooth Chips
-
-maintainers:
- - Balakrishna Godavarthi <bgodavar@codeaurora.org>
- - Rocky Liao <rjliao@codeaurora.org>
-
-description:
- This binding describes Qualcomm UART-attached bluetooth chips.
-
-properties:
- compatible:
- enum:
- - qcom,qca6174-bt
- - qcom,qca9377-bt
- - qcom,wcn3990-bt
- - qcom,wcn3991-bt
- - qcom,wcn3998-bt
- - qcom,qca6390-bt
- - qcom,wcn6750-bt
-
- enable-gpios:
- maxItems: 1
- description: gpio specifier used to enable chip
-
- swctrl-gpios:
- maxItems: 1
- description: gpio specifier is used to find status
- of clock supply to SoC
-
- clocks:
- maxItems: 1
- description: clock provided to the controller (SUSCLK_32KHZ)
-
- vddio-supply:
- description: VDD_IO supply regulator handle
-
- vddxo-supply:
- description: VDD_XO supply regulator handle
-
- vddrf-supply:
- description: VDD_RF supply regulator handle
-
- vddch0-supply:
- description: VDD_CH0 supply regulator handle
-
- vddaon-supply:
- description: VDD_AON supply regulator handle
-
- vddbtcxmx-supply:
- description: VDD_BT_CXMX supply regulator handle
-
- vddrfacmn-supply:
- description: VDD_RFA_CMN supply regulator handle
-
- vddrfa0p8-supply:
- description: VDD_RFA_0P8 suppply regulator handle
-
- vddrfa1p7-supply:
- description: VDD_RFA_1P7 supply regulator handle
-
- vddrfa1p2-supply:
- description: VDD_RFA_1P2 supply regulator handle
-
- vddrfa2p2-supply:
- description: VDD_RFA_2P2 supply regulator handle
-
- vddasd-supply:
- description: VDD_ASD supply regulator handle
-
- max-speed:
- description: see Documentation/devicetree/bindings/serial/serial.yaml
-
- firmware-name:
- description: specify the name of nvm firmware to load
-
- local-bd-address:
- description: see Documentation/devicetree/bindings/net/bluetooth.txt
-
-
-required:
- - compatible
-
-additionalProperties: false
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,qca6174-bt
- then:
- required:
- - enable-gpios
- - clocks
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,wcn3990-bt
- - qcom,wcn3991-bt
- - qcom,wcn3998-bt
- then:
- required:
- - vddio-supply
- - vddxo-supply
- - vddrf-supply
- - vddch0-supply
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,wcn6750-bt
- then:
- required:
- - enable-gpios
- - swctrl-gpios
- - vddio-supply
- - vddaon-supply
- - vddbtcxmx-supply
- - vddrfacmn-supply
- - vddrfa0p8-supply
- - vddrfa1p7-supply
- - vddrfa1p2-supply
- - vddasd-supply
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- serial {
-
- bluetooth {
- compatible = "qcom,qca6174-bt";
- enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
- clocks = <&divclk4>;
- firmware-name = "nvm_00440302.bin";
- };
- };
- - |
- serial {
-
- bluetooth {
- compatible = "qcom,wcn3990-bt";
- vddio-supply = <&vreg_s4a_1p8>;
- vddxo-supply = <&vreg_l7a_1p8>;
- vddrf-supply = <&vreg_l17a_1p3>;
- vddch0-supply = <&vreg_l25a_3p3>;
- max-speed = <3200000>;
- firmware-name = "crnv21.bin";
- };
- };
- - |
- serial {
-
- bluetooth {
- compatible = "qcom,wcn6750-bt";
- pinctrl-names = "default";
- pinctrl-0 = <&bt_en_default>;
- enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
- swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>;
- vddio-supply = <&vreg_l19b_1p8>;
- vddaon-supply = <&vreg_s7b_0p9>;
- vddbtcxmx-supply = <&vreg_s7b_0p9>;
- vddrfacmn-supply = <&vreg_s7b_0p9>;
- vddrfa0p8-supply = <&vreg_s7b_0p9>;
- vddrfa1p7-supply = <&vreg_s1b_1p8>;
- vddrfa1p2-supply = <&vreg_s8b_1p2>;
- vddrfa2p2-supply = <&vreg_s1c_2p2>;
- vddasd-supply = <&vreg_l11c_2p8>;
- max-speed = <3200000>;
- firmware-name = "msnv11.bin";
- };
- };
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
index bb94a2388520..2b5697bd7c5d 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
@@ -14,23 +14,61 @@ maintainers:
description:
Bindings for Realtek RTL82xx PHYs
-allOf:
- - $ref: ethernet-phy.yaml#
-
properties:
+ compatible:
+ enum:
+ - ethernet-phy-id001c.c800
+ - ethernet-phy-id001c.c816
+ - ethernet-phy-id001c.c838
+ - ethernet-phy-id001c.c840
+ - ethernet-phy-id001c.c848
+ - ethernet-phy-id001c.c849
+ - ethernet-phy-id001c.c84a
+ - ethernet-phy-id001c.c862
+ - ethernet-phy-id001c.c878
+ - ethernet-phy-id001c.c880
+ - ethernet-phy-id001c.c910
+ - ethernet-phy-id001c.c912
+ - ethernet-phy-id001c.c913
+ - ethernet-phy-id001c.c914
+ - ethernet-phy-id001c.c915
+ - ethernet-phy-id001c.c916
+ - ethernet-phy-id001c.c942
+ - ethernet-phy-id001c.c961
+ - ethernet-phy-id001c.cad0
+ - ethernet-phy-id001c.cb00
+
+ leds: true
+
realtek,clkout-disable:
type: boolean
description:
Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
-
realtek,aldps-enable:
type: boolean
description:
Enable ALDPS mode, ALDPS mode default is disabled after hardware reset.
+ wakeup-source:
+ type: boolean
+ description:
+ Enable Wake-on-LAN support for the RTL8211F PHY.
+
unevaluatedProperties: false
+allOf:
+ - $ref: ethernet-phy.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: ethernet-phy-id001c.c916
+ then:
+ properties:
+ leds: false
+
examples:
- |
mdio {
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
new file mode 100644
index 000000000000..02e4e33e9969
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/realtek,rtl9301-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTL9300 MDIO Controller
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - realtek,rtl9302b-mdio
+ - realtek,rtl9302c-mdio
+ - realtek,rtl9303-mdio
+ - const: realtek,rtl9301-mdio
+ - const: realtek,rtl9301-mdio
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '^mdio-bus@[0-3]$':
+ $ref: mdio.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ patternProperties:
+ '^ethernet-phy@[a-f0-9]+$':
+ type: object
+ $ref: ethernet-phy.yaml#
+ unevaluatedProperties: false
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio-controller@ca00 {
+ compatible = "realtek,rtl9301-mdio";
+ reg = <0xca00 0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-bus@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ };
+ };
+
+ mdio-bus@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml
new file mode 100644
index 000000000000..80eabc170669
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/realtek,rtl9301-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek Switch with Internal CPU
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+description:
+ The RTL9300 is a series of is an Ethernet switches with an integrated CPU. A
+ number of different peripherals are accessed through a common register block,
+ represented here as a syscon node.
+
+$ref: ethernet-switch.yaml#/$defs/ethernet-ports
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - realtek,rtl9301-switch
+ - realtek,rtl9302b-switch
+ - realtek,rtl9302c-switch
+ - realtek,rtl9303-switch
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: switch
+ - const: nic
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ethernet-ports:
+ type: object
+
+patternProperties:
+ 'reboot@[0-9a-f]+$':
+ $ref: /schemas/power/reset/syscon-reboot.yaml#
+
+ 'i2c@[0-9a-f]+$':
+ $ref: /schemas/i2c/realtek,rtl9301-i2c.yaml#
+
+ 'mdio-controller@[0-9a-f]+$':
+ $ref: realtek,rtl9301-mdio.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ ethernet-switch@1b000000 {
+ compatible = "realtek,rtl9301-switch", "syscon", "simple-mfd";
+ reg = <0x1b000000 0x10000>;
+ interrupt-parent = <&intc>;
+ interrupts = <23>, <24>;
+ interrupt-names = "switch", "nic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ reboot@c {
+ compatible = "syscon-reboot";
+ reg = <0x0c 0x4>;
+ value = <0x01>;
+ };
+
+ i2c@36c {
+ compatible = "realtek,rtl9301-i2c";
+ reg = <0x36c 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+ };
+
+ i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+ };
+ };
+
+ i2c@388 {
+ compatible = "realtek,rtl9301-i2c";
+ reg = <0x388 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@7 {
+ reg = <7>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+ };
+ };
+
+ mdio-controller@ca00 {
+ compatible = "realtek,rtl9301-mdio";
+ reg = <0xca00 0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-bus@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy1: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ mdio-bus@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy2: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ phy-handle = <&phy1>;
+ };
+ port@1 {
+ reg = <1>;
+ phy-handle = <&phy2>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml
deleted file mode 100644
index 157d606bf9cb..000000000000
--- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml
+++ /dev/null
@@ -1,58 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/net/realtek-bluetooth.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: RTL8723BS/RTL8723CS/RTL8822CS Bluetooth Device Tree Bindings
-
-maintainers:
- - Vasily Khoruzhick <anarsoul@gmail.com>
- - Alistair Francis <alistair@alistair23.me>
-
-description:
- RTL8723CS/RTL8723CS/RTL8822CS is WiFi + BT chip. WiFi part is connected over
- SDIO, while BT is connected over serial. It speaks H5 protocol with few
- extra commands to upload firmware and change module speed.
-
-properties:
- compatible:
- enum:
- - realtek,rtl8723bs-bt
- - realtek,rtl8723cs-bt
- - realtek,rtl8822cs-bt
-
- device-wake-gpios:
- maxItems: 1
- description: GPIO specifier, used to wakeup the BT module
-
- enable-gpios:
- maxItems: 1
- description: GPIO specifier, used to enable the BT module
-
- host-wake-gpios:
- maxItems: 1
- description: GPIO specifier, used to wakeup the host processor
-
- max-speed: true
-
-required:
- - compatible
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
-
- uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
- uart-has-rtscts;
-
- bluetooth {
- compatible = "realtek,rtl8723bs-bt";
- device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
- host-wake-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
- };
- };
diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml
index 06b38c9bc6ec..f0a52f47f95a 100644
--- a/Documentation/devicetree/bindings/net/renesas,ether.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml
@@ -59,6 +59,9 @@ properties:
clocks:
maxItems: 1
+ iommus:
+ maxItems: 1
+
power-domains:
maxItems: 1
@@ -81,9 +84,8 @@ properties:
active-high
patternProperties:
- "^ethernet-phy@[0-9a-f]$":
+ "@[0-9a-f]$":
type: object
- $ref: ethernet-phy.yaml#
required:
- compatible
@@ -124,7 +126,6 @@ examples:
reg = <1>;
interrupt-parent = <&irqc0>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- micrel,led-mode = <1>;
reset-gpios = <&gpio5 31 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index 3f41294f5997..1e00ef5b3acd 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -46,6 +46,7 @@ properties:
- enum:
- renesas,etheravb-r8a779a0 # R-Car V3U
- renesas,etheravb-r8a779g0 # R-Car V4H
+ - renesas,etheravb-r8a779h0 # R-Car V4M
- const: renesas,etheravb-rcar-gen4 # R-Car Gen4
- items:
@@ -55,20 +56,33 @@ properties:
- items:
- enum:
- - renesas,r9a07g043-gbeth # RZ/G2UL
+ - renesas,r9a07g043-gbeth # RZ/G2UL and RZ/Five
- renesas,r9a07g044-gbeth # RZ/G2{L,LC}
- renesas,r9a07g054-gbeth # RZ/V2L
+ - renesas,r9a08g045-gbeth # RZ/G3S
- const: renesas,rzg2l-gbeth # RZ/{G2L,G2UL,V2L} family
- reg: true
+ reg:
+ minItems: 1
+ items:
+ - description: MAC register block
+ - description: Stream buffer
- interrupts: true
+ interrupts:
+ minItems: 1
+ maxItems: 29
- interrupt-names: true
+ interrupt-names:
+ minItems: 1
+ maxItems: 29
- clocks: true
+ clocks:
+ minItems: 1
+ maxItems: 3
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 3
iommus:
maxItems: 1
@@ -86,10 +100,16 @@ properties:
'#address-cells':
description: Number of address cells for the MDIO bus.
const: 1
+ deprecated: true
'#size-cells':
description: Number of size cells on the MDIO bus.
const: 0
+ deprecated: true
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
renesas,no-ether-link:
type: boolean
@@ -108,10 +128,13 @@ properties:
tx-internal-delay-ps:
enum: [0, 2000]
+# In older bindings there where no mdio child-node to describe the MDIO bus
+# and the PHY. To not fail older bindings accept any node with an address. New
+# users should describe the PHY inside the mdio child-node.
patternProperties:
- "^ethernet-phy@[0-9a-f]$":
+ "@[0-9a-f]$":
type: object
- $ref: ethernet-phy.yaml#
+ deprecated: true
required:
- compatible
@@ -122,8 +145,6 @@ required:
- resets
- phy-mode
- phy-handle
- - '#address-cells'
- - '#size-cells'
allOf:
- $ref: ethernet-controller.yaml#
@@ -141,14 +162,11 @@ allOf:
then:
properties:
reg:
- items:
- - description: MAC register block
- - description: Stream buffer
+ minItems: 2
else:
properties:
reg:
- items:
- - description: MAC register block
+ maxItems: 1
- if:
properties:
diff --git a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
new file mode 100644
index 000000000000..b4680a1d0a06
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,ethertsn.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Ethernet TSN End-station
+
+maintainers:
+ - Niklas Söderlund <niklas.soderlund@ragnatech.se>
+
+description:
+ The RTSN device provides Ethernet network using a 10 Mbps, 100 Mbps, or 1
+ Gbps full-duplex link via MII/GMII/RMII/RGMII. Depending on the connected PHY.
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a779g0-ethertsn # R-Car V4H
+ - const: renesas,rcar-gen4-ethertsn
+
+ reg:
+ items:
+ - description: TSN End Station target
+ - description: generalized Precision Time Protocol target
+
+ reg-names:
+ items:
+ - const: tsnes
+ - const: gptp
+
+ interrupts:
+ items:
+ - description: TX data interrupt
+ - description: RX data interrupt
+
+ interrupt-names:
+ items:
+ - const: tx
+ - const: rx
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ phy-mode:
+ contains:
+ enum:
+ - mii
+ - rgmii
+
+ phy-handle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Specifies a reference to a node representing a PHY device.
+
+ rx-internal-delay-ps:
+ enum: [0, 1800]
+ default: 0
+
+ tx-internal-delay-ps:
+ enum: [0, 2000]
+ default: 0
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - power-domains
+ - resets
+ - phy-mode
+ - phy-handle
+ - mdio
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779g0-sysc.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ tsn0: ethernet@e6460000 {
+ compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
+ reg = <0xe6460000 0x7000>,
+ <0xe6449000 0x500>;
+ reg-names = "tsnes", "gptp";
+ interrupts = <GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tx", "rx";
+ clocks = <&cpg CPG_MOD 2723>;
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 2723>;
+
+ phy-mode = "rgmii";
+ tx-internal-delay-ps = <2000>;
+ phy-handle = <&phy3>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
+ reset-post-delay-us = <4000>;
+
+ phy3: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/renesas,r8a779f0-ether-switch.yaml b/Documentation/devicetree/bindings/net/renesas,r8a779f0-ether-switch.yaml
new file mode 100644
index 000000000000..e933a1e48d67
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,r8a779f0-ether-switch.yaml
@@ -0,0 +1,262 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,r8a779f0-ether-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Ethernet Switch
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+properties:
+ compatible:
+ const: renesas,r8a779f0-ether-switch
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: base
+ - const: secure_base
+
+ interrupts:
+ maxItems: 47
+
+ interrupt-names:
+ items:
+ - const: mfwd_error
+ - const: race_error
+ - const: coma_error
+ - const: gwca0_error
+ - const: gwca1_error
+ - const: etha0_error
+ - const: etha1_error
+ - const: etha2_error
+ - const: gptp0_status
+ - const: gptp1_status
+ - const: mfwd_status
+ - const: race_status
+ - const: coma_status
+ - const: gwca0_status
+ - const: gwca1_status
+ - const: etha0_status
+ - const: etha1_status
+ - const: etha2_status
+ - const: rmac0_status
+ - const: rmac1_status
+ - const: rmac2_status
+ - const: gwca0_rxtx0
+ - const: gwca0_rxtx1
+ - const: gwca0_rxtx2
+ - const: gwca0_rxtx3
+ - const: gwca0_rxtx4
+ - const: gwca0_rxtx5
+ - const: gwca0_rxtx6
+ - const: gwca0_rxtx7
+ - const: gwca1_rxtx0
+ - const: gwca1_rxtx1
+ - const: gwca1_rxtx2
+ - const: gwca1_rxtx3
+ - const: gwca1_rxtx4
+ - const: gwca1_rxtx5
+ - const: gwca1_rxtx6
+ - const: gwca1_rxtx7
+ - const: gwca0_rxts0
+ - const: gwca0_rxts1
+ - const: gwca1_rxts0
+ - const: gwca1_rxts1
+ - const: rmac0_mdio
+ - const: rmac1_mdio
+ - const: rmac2_mdio
+ - const: rmac0_phy
+ - const: rmac1_phy
+ - const: rmac2_phy
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ iommus:
+ maxItems: 16
+
+ power-domains:
+ maxItems: 1
+
+ ethernet-ports:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ description: Port number of ETHA (TSNA).
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^port@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/net/ethernet-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+ description:
+ Port number of ETHA (TSNA).
+
+ phys:
+ maxItems: 1
+ description:
+ Phandle of an Ethernet SERDES.
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - reg
+ - phy-handle
+ - phy-mode
+ - phys
+ - mdio
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - resets
+ - power-domains
+ - ethernet-ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ ethernet@e6880000 {
+ compatible = "renesas,r8a779f0-ether-switch";
+ reg = <0xe6880000 0x20000>, <0xe68c0000 0x20000>;
+ reg-names = "base", "secure_base";
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 258 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 273 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 274 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 276 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 280 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 281 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 283 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 284 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 285 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 291 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 293 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 294 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 295 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 296 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 297 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mfwd_error", "race_error",
+ "coma_error", "gwca0_error",
+ "gwca1_error", "etha0_error",
+ "etha1_error", "etha2_error",
+ "gptp0_status", "gptp1_status",
+ "mfwd_status", "race_status",
+ "coma_status", "gwca0_status",
+ "gwca1_status", "etha0_status",
+ "etha1_status", "etha2_status",
+ "rmac0_status", "rmac1_status",
+ "rmac2_status",
+ "gwca0_rxtx0", "gwca0_rxtx1",
+ "gwca0_rxtx2", "gwca0_rxtx3",
+ "gwca0_rxtx4", "gwca0_rxtx5",
+ "gwca0_rxtx6", "gwca0_rxtx7",
+ "gwca1_rxtx0", "gwca1_rxtx1",
+ "gwca1_rxtx2", "gwca1_rxtx3",
+ "gwca1_rxtx4", "gwca1_rxtx5",
+ "gwca1_rxtx6", "gwca1_rxtx7",
+ "gwca0_rxts0", "gwca0_rxts1",
+ "gwca1_rxts0", "gwca1_rxts1",
+ "rmac0_mdio", "rmac1_mdio",
+ "rmac2_mdio",
+ "rmac0_phy", "rmac1_phy",
+ "rmac2_phy";
+ clocks = <&cpg CPG_MOD 1505>;
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 1505>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phy-handle = <&eth_phy0>;
+ phy-mode = "sgmii";
+ phys = <&eth_serdes 0>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ phy-handle = <&eth_phy1>;
+ phy-mode = "sgmii";
+ phys = <&eth_serdes 1>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+ phy-handle = <&eth_phy2>;
+ phy-mode = "sgmii";
+ phys = <&eth_serdes 2>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
new file mode 100644
index 000000000000..16dd7a2631ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,rzn1-gmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas GMAC
+
+maintainers:
+ - Romain Gantois <romain.gantois@bootlin.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a06g032-gmac
+ - renesas,rzn1-gmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a06g032-gmac
+ - const: renesas,rzn1-gmac
+ - const: snps,dwmac
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: macirq
+ - const: eth_wake_irq
+ - const: eth_lpi
+
+ pcs-handle:
+ description:
+ phandle pointing to a PCS sub-node compatible with
+ renesas,rzn1-miic.yaml#
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@44000000 {
+ compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
+ reg = <0x44000000 0x2000>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ clock-names = "stmmaceth";
+ clocks = <&sysctrl R9A06G032_HCLK_GMAC0>;
+ power-domains = <&sysctrl>;
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ tx-fifo-depth = <2048>;
+ rx-fifo-depth = <4096>;
+ pcs-handle = <&mii_conv1>;
+ phy-mode = "mii";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/renesas,rzv2h-gbeth.yaml b/Documentation/devicetree/bindings/net/renesas,rzv2h-gbeth.yaml
new file mode 100644
index 000000000000..bd53ab300f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,rzv2h-gbeth.yaml
@@ -0,0 +1,303 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,rzv2h-gbeth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GBETH glue layer for Renesas RZ/V2H(P) (and similar SoCs)
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g047-gbeth
+ - renesas,r9a09g056-gbeth
+ - renesas,r9a09g057-gbeth
+ - renesas,r9a09g077-gbeth
+ - renesas,r9a09g087-gbeth
+ - renesas,rzv2h-gbeth
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a09g047-gbeth # RZ/G3E
+ - renesas,r9a09g056-gbeth # RZ/V2N
+ - renesas,r9a09g057-gbeth # RZ/V2H(P)
+ - const: renesas,rzv2h-gbeth
+ - const: snps,dwmac-5.20
+ - items:
+ - const: renesas,r9a09g077-gbeth # RZ/T2H
+ - const: snps,dwmac-5.20
+ - items:
+ - const: renesas,r9a09g087-gbeth # RZ/N2H
+ - const: renesas,r9a09g077-gbeth
+ - const: snps,dwmac-5.20
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ oneOf:
+ - items:
+ - description: CSR clock
+ - description: AXI system clock
+ - description: PTP clock
+ - description: TX clock
+ - description: RX clock
+ - description: TX clock phase-shifted by 180 degrees
+ - description: RX clock phase-shifted by 180 degrees
+ - items:
+ - description: CSR clock
+ - description: AXI system clock
+ - description: TX clock
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: stmmaceth
+ - const: pclk
+ - const: ptp_ref
+ - const: tx
+ - const: rx
+ - const: tx-180
+ - const: rx-180
+ - items:
+ - const: stmmaceth
+ - const: pclk
+ - const: tx
+
+ interrupt-names:
+ oneOf:
+ - items:
+ - const: macirq
+ - const: eth_wake_irq
+ - const: eth_lpi
+ - const: rx-queue-0
+ - const: rx-queue-1
+ - const: rx-queue-2
+ - const: rx-queue-3
+ - const: tx-queue-0
+ - const: tx-queue-1
+ - const: tx-queue-2
+ - const: tx-queue-3
+ - items:
+ - const: macirq
+ - const: eth_wake_irq
+ - const: eth_lpi
+ - const: rx-queue-0
+ - const: rx-queue-1
+ - const: rx-queue-2
+ - const: rx-queue-3
+ - const: rx-queue-4
+ - const: rx-queue-5
+ - const: rx-queue-6
+ - const: rx-queue-7
+ - const: tx-queue-0
+ - const: tx-queue-1
+ - const: tx-queue-2
+ - const: tx-queue-3
+ - const: tx-queue-4
+ - const: tx-queue-5
+ - const: tx-queue-6
+ - const: tx-queue-7
+
+ resets:
+ oneOf:
+ - items:
+ - description: AXI power-on system reset
+ - items:
+ - description: AXI power-on system reset
+ - description: AHB reset
+
+ pcs-handle:
+ description:
+ phandle pointing to a PCS sub-node compatible with
+ Documentation/devicetree/bindings/net/pcs/renesas,rzn1-miic.yaml#
+ (Refer RZ/T2H portion in the DT-binding file)
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - resets
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g077-gbeth
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ maxItems: 3
+
+ interrupts:
+ minItems: 19
+
+ interrupt-names:
+ minItems: 19
+
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
+
+ required:
+ - reset-names
+ else:
+ properties:
+ clocks:
+ minItems: 7
+
+ clock-names:
+ minItems: 7
+
+ interrupts:
+ minItems: 11
+ maxItems: 11
+
+ interrupt-names:
+ minItems: 11
+ maxItems: 11
+
+ resets:
+ maxItems: 1
+
+ pcs-handle: false
+
+ reset-names: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@15c30000 {
+ compatible = "renesas,r9a09g057-gbeth", "renesas,rzv2h-gbeth", "snps,dwmac-5.20";
+ reg = <0x15c30000 0x10000>;
+ clocks = <&cpg CPG_MOD 0xbd>, <&cpg CPG_MOD 0xbc>,
+ <&ptp_clock>, <&cpg CPG_MOD 0xb8>,
+ <&cpg CPG_MOD 0xb9>, <&cpg CPG_MOD 0xba>,
+ <&cpg CPG_MOD 0xbb>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "rx", "tx-180", "rx-180";
+ resets = <&cpg 0xb0>;
+ interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 767 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 772 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 745 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 768 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 770 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 771 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi",
+ "rx-queue-0", "rx-queue-1", "rx-queue-2",
+ "rx-queue-3", "tx-queue-0", "tx-queue-1",
+ "tx-queue-2", "tx-queue-3";
+ phy-mode = "rgmii-id";
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ rx-fifo-depth = <8192>;
+ tx-fifo-depth = <8192>;
+ snps,fixed-burst;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ snps,txpbl = <32>;
+ snps,rxpbl = <32>;
+ phy-handle = <&phy0>;
+
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,lpi_en;
+ snps,wr_osr_lmt = <0xf>;
+ snps,rd_osr_lmt = <0xf>;
+ snps,blen = <16 8 4 0 0 0 0>;
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <4>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ snps,map-to-dma-channel = <0>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ snps,map-to-dma-channel = <1>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ snps,map-to-dma-channel = <2>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ snps,map-to-dma-channel = <3>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <4>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/rfkill-gpio.yaml b/Documentation/devicetree/bindings/net/rfkill-gpio.yaml
new file mode 100644
index 000000000000..4a706a41ab38
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/rfkill-gpio.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/rfkill-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO controlled rfkill switch
+
+maintainers:
+ - Johannes Berg <johannes@sipsolutions.net>
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+properties:
+ compatible:
+ const: rfkill-gpio
+
+ label:
+ description: rfkill switch name, defaults to node name
+
+ radio-type:
+ description: rfkill radio type
+ enum:
+ - bluetooth
+ - fm
+ - gps
+ - nfc
+ - ultrawideband
+ - wimax
+ - wlan
+ - wwan
+
+ shutdown-gpios:
+ maxItems: 1
+
+ default-blocked:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: configure rfkill state as blocked at boot
+
+required:
+ - compatible
+ - radio-type
+ - shutdown-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ rfkill {
+ compatible = "rfkill-gpio";
+ label = "rfkill-pcie-wlan";
+ radio-type = "wlan";
+ shutdown-gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>;
+ default-blocked;
+ };
diff --git a/Documentation/devicetree/bindings/net/rockchip,emac.yaml b/Documentation/devicetree/bindings/net/rockchip,emac.yaml
index a6d4f14df442..364028b3bba4 100644
--- a/Documentation/devicetree/bindings/net/rockchip,emac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip,emac.yaml
@@ -61,7 +61,7 @@ required:
- mdio
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 42fb72b6909d..d17112527dab 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/rockchip-dwmac.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/rockchip-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip 10/100/1000 Ethernet driver(GMAC)
@@ -24,16 +24,16 @@ select:
- rockchip,rk3366-gmac
- rockchip,rk3368-gmac
- rockchip,rk3399-gmac
+ - rockchip,rk3506-gmac
+ - rockchip,rk3528-gmac
- rockchip,rk3568-gmac
+ - rockchip,rk3576-gmac
- rockchip,rk3588-gmac
- rockchip,rv1108-gmac
- rockchip,rv1126-gmac
required:
- compatible
-allOf:
- - $ref: "snps,dwmac.yaml#"
-
properties:
compatible:
oneOf:
@@ -49,15 +49,28 @@ properties:
- rockchip,rk3368-gmac
- rockchip,rk3399-gmac
- rockchip,rv1108-gmac
- - rockchip,rv1126-gmac
- items:
- enum:
+ - rockchip,rk3506-gmac
+ - rockchip,rk3528-gmac
- rockchip,rk3568-gmac
+ - rockchip,rk3576-gmac
- rockchip,rk3588-gmac
+ - rockchip,rv1126-gmac
- const: snps,dwmac-4.20a
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: macirq
+ - const: eth_wake_irq
+
clocks:
- minItems: 5
+ minItems: 4
maxItems: 8
clock-names:
@@ -80,6 +93,7 @@ properties:
"output" means GMAC provides the reference clock.
$ref: /schemas/types.yaml#/definitions/string
enum: [input, output]
+ default: input
rockchip,grf:
description: The phandle of the syscon node for the general register file.
@@ -91,12 +105,18 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
tx_delay:
- description: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default.
+ description: Delay value for TXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x7F
+ default: 0x30
rx_delay:
- description: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default.
+ description: Delay value for RXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x7F
+ default: 0x10
phy-supply:
description: PHY regulator
@@ -105,6 +125,37 @@ required:
- compatible
- clocks
- clock-names
+ - rockchip,grf
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-gmac
+ - rockchip,rk3588-gmac
+ then:
+ required:
+ - rockchip,php-grf
+ else:
+ properties:
+ rockchip,php-grf: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3506-gmac
+ - rockchip,rk3528-gmac
+ then:
+ properties:
+ clocks:
+ minItems: 5
unevaluatedProperties: false
@@ -130,8 +181,6 @@ examples:
assigned-clock-parents = <&ext_gmac>;
rockchip,grf = <&grf>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
clock_in_out = "input";
- tx_delay = <0x30>;
- rx_delay = <0x10>;
};
diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
index 2cff6d8a585a..b9381b761a27 100644
--- a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
+++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
@@ -5,10 +5,10 @@ Required properties:
- reg: Address and length of the register set for the device
- interrupts: Should contain the SXGBE interrupts
These interrupts are ordered by fixed and follows variable
- trasmit DMA interrupts, receive DMA interrupts and lpi interrupt.
+ transmit DMA interrupts, receive DMA interrupts and lpi interrupt.
index 0 - this is fixed common interrupt of SXGBE and it is always
available.
- index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts
+ index 1 to 25 - 8 variable transmit interrupts, variable 16 receive interrupts
and 1 optional lpi interrupt.
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "sgmii", "xgmii".
diff --git a/Documentation/devicetree/bindings/net/sff,sfp.yaml b/Documentation/devicetree/bindings/net/sff,sfp.yaml
index 06c66ab81c01..15616ad737f5 100644
--- a/Documentation/devicetree/bindings/net/sff,sfp.yaml
+++ b/Documentation/devicetree/bindings/net/sff,sfp.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/sff,sfp.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/sff,sfp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
Transceiver
@@ -22,45 +22,46 @@ properties:
phandle of an I2C bus controller for the SFP two wire serial
maximum-power-milliwatt:
- maxItems: 1
+ minimum: 1000
+ default: 1000
description:
Maximum module power consumption Specifies the maximum power consumption
allowable by a module in the slot, in milli-Watts. Presently, modules can
be up to 1W, 1.5W or 2W.
- "mod-def0-gpios":
+ mod-def0-gpios:
maxItems: 1
description:
GPIO phandle and a specifier of the MOD-DEF0 (AKA Mod_ABS) module
presence input gpio signal, active (module absent) high. Must not be
present for SFF modules
- "los-gpios":
+ los-gpios:
maxItems: 1
description:
GPIO phandle and a specifier of the Receiver Loss of Signal Indication
input gpio signal, active (signal lost) high
- "tx-fault-gpios":
+ tx-fault-gpios:
maxItems: 1
description:
GPIO phandle and a specifier of the Module Transmitter Fault input gpio
signal, active (fault condition) high
- "tx-disable-gpios":
+ tx-disable-gpios:
maxItems: 1
description:
GPIO phandle and a specifier of the Transmitter Disable output gpio
signal, active (Tx disable) high
- "rate-select0-gpios":
+ rate-select0-gpios:
maxItems: 1
description:
GPIO phandle and a specifier of the Rx Signaling Rate Select (AKA RS0)
output gpio signal, low - low Rx rate, high - high Rx rate Must not be
present for SFF modules
- "rate-select1-gpios":
+ rate-select1-gpios:
maxItems: 1
description:
GPIO phandle and a specifier of the Tx Signaling Rate Select (AKA RS1)
@@ -119,7 +120,7 @@ examples:
pinctrl-names = "default";
pinctrl-0 = <&cps_sfpp0_pins>;
tx-disable-gpios = <&cps_gpio1 29 GPIO_ACTIVE_HIGH>;
- tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpios = <&cps_gpio1 26 GPIO_ACTIVE_HIGH>;
};
mdio {
@@ -131,7 +132,7 @@ examples:
pinctrl-names = "default";
pinctrl-0 = <&cpm_phy0_pins &cps_phy0_pins>;
reg = <0>;
- interrupt = <&cpm_gpio2 18 IRQ_TYPE_EDGE_FALLING>;
+ interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
sfp = <&sfp2>;
};
};
diff --git a/Documentation/devicetree/bindings/net/smsc,lan9115.yaml b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml
index f86667cbcca8..42279ae8c2b9 100644
--- a/Documentation/devicetree/bindings/net/smsc,lan9115.yaml
+++ b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml
@@ -11,6 +11,7 @@ maintainers:
allOf:
- $ref: ethernet-controller.yaml#
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
properties:
compatible:
@@ -89,10 +90,7 @@ required:
- reg
- interrupts
-# There are lots of bus-specific properties ("qcom,*", "samsung,*", "fsl,*",
-# "gpmc,*", ...) to be found, that actually depend on the compatible value of
-# the parent node.
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
index ad3c6e109ce1..bb0224a3e826 100644
--- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
+++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
@@ -110,7 +110,7 @@ Optional properties:
It depends on the SoC configuration.
- snps,read-requests: Number of read requests that the AXI port can issue.
It depends on the SoC configuration.
-- snps,burst-map: Bitmap of allowed AXI burst lengts, with the LSB
+- snps,burst-map: Bitmap of allowed AXI burst lengths, with the LSB
representing 4, then 8 etc.
- snps,txpbl: DMA Programmable burst length for the TX DMA
- snps,rxpbl: DMA Programmable burst length for the RX DMA
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index f94a0a4320f1..dd3c72e8363e 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/snps,dwmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Synopsys DesignWare MAC Device Tree Bindings
+title: Synopsys DesignWare MAC
maintainers:
- Alexandre Torgue <alexandre.torgue@foss.st.com>
@@ -26,10 +26,14 @@ select:
- snps,dwmac-3.610
- snps,dwmac-3.70a
- snps,dwmac-3.710
+ - snps,dwmac-3.72a
- snps,dwmac-4.00
- snps,dwmac-4.10a
- snps,dwmac-4.20a
+ - snps,dwmac-5.00a
- snps,dwmac-5.10a
+ - snps,dwmac-5.20
+ - snps,dwmac-5.30a
- snps,dwxgmac
- snps,dwxgmac-2.10
@@ -65,30 +69,53 @@ properties:
- ingenic,x2000-mac
- loongson,ls2k-dwmac
- loongson,ls7a-dwmac
+ - nxp,s32g2-dwmac
+ - qcom,qcs404-ethqos
+ - qcom,sa8775p-ethqos
+ - qcom,sc8280xp-ethqos
+ - qcom,sm8150-ethqos
- renesas,r9a06g032-gmac
+ - renesas,r9a09g077-gbeth
- renesas,rzn1-gmac
+ - renesas,rzv2h-gbeth
- rockchip,px30-gmac
- rockchip,rk3128-gmac
- rockchip,rk3228-gmac
- rockchip,rk3288-gmac
+ - rockchip,rk3308-gmac
- rockchip,rk3328-gmac
- rockchip,rk3366-gmac
- rockchip,rk3368-gmac
- - rockchip,rk3588-gmac
- rockchip,rk3399-gmac
+ - rockchip,rk3506-gmac
+ - rockchip,rk3528-gmac
+ - rockchip,rk3568-gmac
+ - rockchip,rk3576-gmac
+ - rockchip,rk3588-gmac
- rockchip,rv1108-gmac
+ - rockchip,rv1126-gmac
- snps,dwmac
- snps,dwmac-3.40a
- snps,dwmac-3.50a
- snps,dwmac-3.610
- snps,dwmac-3.70a
- snps,dwmac-3.710
+ - snps,dwmac-3.72a
- snps,dwmac-4.00
- snps,dwmac-4.10a
- snps,dwmac-4.20a
+ - snps,dwmac-5.00a
- snps,dwmac-5.10a
+ - snps,dwmac-5.20
+ - snps,dwmac-5.30a
- snps,dwxgmac
- snps,dwxgmac-2.10
+ - sophgo,sg2042-dwmac
+ - sophgo,sg2044-dwmac
+ - starfive,jh7100-dwmac
+ - starfive,jh7110-dwmac
+ - tesla,fsd-ethqos
+ - thead,th1520-gmac
reg:
minItems: 1
@@ -96,21 +123,29 @@ properties:
interrupts:
minItems: 1
- items:
- - description: Combined signal for various interrupt events
- - description: The interrupt to manage the remote wake-up packet detection
- - description: The interrupt that occurs when Rx exits the LPI state
+ maxItems: 19
interrupt-names:
minItems: 1
+ maxItems: 19
items:
- - const: macirq
- - const: eth_wake_irq
- - const: eth_lpi
+ oneOf:
+ - description: Combined signal for various interrupt events
+ const: macirq
+ - description: The interrupt to manage the remote wake-up packet detection
+ const: eth_wake_irq
+ - description: The interrupt that occurs when Rx exits the LPI state
+ const: eth_lpi
+ - description: The interrupt that occurs when HW safety error triggered
+ const: sfty
+ - description: Per channel receive completion interrupt
+ pattern: '^rx-queue-[0-7]$'
+ - description: Per channel transmit completion interrupt
+ pattern: '^tx-queue-[0-7]$'
clocks:
minItems: 1
- maxItems: 8
+ maxItems: 10
additionalItems: true
items:
- description: GMAC main clock
@@ -122,7 +157,7 @@ properties:
clock-names:
minItems: 1
- maxItems: 8
+ maxItems: 10
additionalItems: true
contains:
enum:
@@ -131,12 +166,18 @@ properties:
- ptp_ref
resets:
- maxItems: 1
- description:
- MAC Reset signal.
+ minItems: 1
+ items:
+ - description: GMAC stmmaceth reset
+ - description: AHB reset
reset-names:
- const: stmmaceth
+ oneOf:
+ - items:
+ - enum: [stmmaceth, ahb]
+ - items:
+ - const: stmmaceth
+ - const: ahb
power-domains:
maxItems: 1
@@ -167,56 +208,231 @@ properties:
snps,mtl-rx-config:
$ref: /schemas/types.yaml#/definitions/phandle
description:
- Multiple RX Queues parameters. Phandle to a node that can
- contain the following properties
- * snps,rx-queues-to-use, number of RX queues to be used in the
- driver
- * Choose one of these RX scheduling algorithms
- * snps,rx-sched-sp, Strict priority
- * snps,rx-sched-wsp, Weighted Strict priority
- * For each RX queue
- * Choose one of these modes
- * snps,dcb-algorithm, Queue to be enabled as DCB
- * snps,avb-algorithm, Queue to be enabled as AVB
- * snps,map-to-dma-channel, Channel to map
- * Specifiy specific packet routing
- * snps,route-avcp, AV Untagged Control packets
- * snps,route-ptp, PTP Packets
- * snps,route-dcbcp, DCB Control Packets
- * snps,route-up, Untagged Packets
- * snps,route-multi-broad, Multicast & Broadcast Packets
- * snps,priority, bitmask of the tagged frames priorities assigned to
- the queue
+ Multiple RX Queues parameters. Phandle to a node that
+ implements the 'rx-queues-config' object described in
+ this binding.
+
+ rx-queues-config:
+ type: object
+ properties:
+ snps,rx-queues-to-use:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: number of RX queues to be used in the driver
+ snps,rx-sched-sp:
+ type: boolean
+ description: Strict priority
+ snps,rx-sched-wsp:
+ type: boolean
+ description: Weighted Strict priority
+ allOf:
+ - if:
+ required:
+ - snps,rx-sched-sp
+ then:
+ properties:
+ snps,rx-sched-wsp: false
+ - if:
+ required:
+ - snps,rx-sched-wsp
+ then:
+ properties:
+ snps,rx-sched-sp: false
+ patternProperties:
+ "^queue[0-9]$":
+ description: Each subnode represents a queue.
+ type: object
+ properties:
+ snps,dcb-algorithm:
+ type: boolean
+ description: Queue to be enabled as DCB
+ snps,avb-algorithm:
+ type: boolean
+ description: Queue to be enabled as AVB
+ snps,map-to-dma-channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: DMA channel id to map
+ snps,route-avcp:
+ type: boolean
+ description: AV Untagged Control packets
+ snps,route-ptp:
+ type: boolean
+ description: PTP Packets
+ snps,route-dcbcp:
+ type: boolean
+ description: DCB Control Packets
+ snps,route-up:
+ type: boolean
+ description: Untagged Packets
+ snps,route-multi-broad:
+ type: boolean
+ description: Multicast & Broadcast Packets
+ snps,priority:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
+ description: Bitmask of the tagged frames priorities assigned to the queue
+ allOf:
+ - if:
+ required:
+ - snps,dcb-algorithm
+ then:
+ properties:
+ snps,avb-algorithm: false
+ - if:
+ required:
+ - snps,avb-algorithm
+ then:
+ properties:
+ snps,dcb-algorithm: false
+ - if:
+ required:
+ - snps,route-avcp
+ then:
+ properties:
+ snps,route-ptp: false
+ snps,route-dcbcp: false
+ snps,route-up: false
+ snps,route-multi-broad: false
+ - if:
+ required:
+ - snps,route-ptp
+ then:
+ properties:
+ snps,route-avcp: false
+ snps,route-dcbcp: false
+ snps,route-up: false
+ snps,route-multi-broad: false
+ - if:
+ required:
+ - snps,route-dcbcp
+ then:
+ properties:
+ snps,route-avcp: false
+ snps,route-ptp: false
+ snps,route-up: false
+ snps,route-multi-broad: false
+ - if:
+ required:
+ - snps,route-up
+ then:
+ properties:
+ snps,route-avcp: false
+ snps,route-ptp: false
+ snps,route-dcbcp: false
+ snps,route-multi-broad: false
+ - if:
+ required:
+ - snps,route-multi-broad
+ then:
+ properties:
+ snps,route-avcp: false
+ snps,route-ptp: false
+ snps,route-dcbcp: false
+ snps,route-up: false
+ additionalProperties: false
+ additionalProperties: false
snps,mtl-tx-config:
$ref: /schemas/types.yaml#/definitions/phandle
description:
- Multiple TX Queues parameters. Phandle to a node that can
- contain the following properties
- * snps,tx-queues-to-use, number of TX queues to be used in the
- driver
- * Choose one of these TX scheduling algorithms
- * snps,tx-sched-wrr, Weighted Round Robin
- * snps,tx-sched-wfq, Weighted Fair Queuing
- * snps,tx-sched-dwrr, Deficit Weighted Round Robin
- * snps,tx-sched-sp, Strict priority
- * For each TX queue
- * snps,weight, TX queue weight (if using a DCB weight
- algorithm)
- * Choose one of these modes
- * snps,dcb-algorithm, TX queue will be working in DCB
- * snps,avb-algorithm, TX queue will be working in AVB
- [Attention] Queue 0 is reserved for legacy traffic
- and so no AVB is available in this queue.
- * Configure Credit Base Shaper (if AVB Mode selected)
- * snps,send_slope, enable Low Power Interface
- * snps,idle_slope, unlock on WoL
- * snps,high_credit, max write outstanding req. limit
- * snps,low_credit, max read outstanding req. limit
- * snps,priority, bitmask of the priorities assigned to the queue.
- When a PFC frame is received with priorities matching the bitmask,
- the queue is blocked from transmitting for the pause time specified
- in the PFC frame.
+ Multiple TX Queues parameters. Phandle to a node that
+ implements the 'tx-queues-config' object described in
+ this binding.
+
+ tx-queues-config:
+ type: object
+ properties:
+ snps,tx-queues-to-use:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: number of TX queues to be used in the driver
+ snps,tx-sched-wrr:
+ type: boolean
+ description: Weighted Round Robin
+ snps,tx-sched-wfq:
+ type: boolean
+ description: Weighted Fair Queuing
+ snps,tx-sched-dwrr:
+ type: boolean
+ description: Deficit Weighted Round Robin
+ allOf:
+ - if:
+ required:
+ - snps,tx-sched-wrr
+ then:
+ properties:
+ snps,tx-sched-wfq: false
+ snps,tx-sched-dwrr: false
+ - if:
+ required:
+ - snps,tx-sched-wfq
+ then:
+ properties:
+ snps,tx-sched-wrr: false
+ snps,tx-sched-dwrr: false
+ - if:
+ required:
+ - snps,tx-sched-dwrr
+ then:
+ properties:
+ snps,tx-sched-wrr: false
+ snps,tx-sched-wfq: false
+ patternProperties:
+ "^queue[0-9]$":
+ description: Each subnode represents a queue.
+ type: object
+ properties:
+ snps,weight:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TX queue weight (if using a DCB weight algorithm)
+ snps,dcb-algorithm:
+ type: boolean
+ description: TX queue will be working in DCB
+ snps,avb-algorithm:
+ type: boolean
+ description:
+ TX queue will be working in AVB.
+ Queue 0 is reserved for legacy traffic and so no AVB is
+ available in this queue.
+ snps,send_slope:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: enable Low Power Interface
+ snps,idle_slope:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: unlock on WoL
+ snps,high_credit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: max write outstanding req. limit
+ snps,low_credit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: max read outstanding req. limit
+ snps,priority:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
+ description:
+ Bitmask of the tagged frames priorities assigned to the queue.
+ When a PFC frame is received with priorities matching the bitmask,
+ the queue is blocked from transmitting for the pause time specified
+ in the PFC frame.
+
+ snps,coe-unsupported:
+ type: boolean
+ description: TX checksum offload is unsupported by the TX queue.
+
+ allOf:
+ - if:
+ required:
+ - snps,dcb-algorithm
+ then:
+ properties:
+ snps,avb-algorithm: false
+ - if:
+ required:
+ - snps,avb-algorithm
+ then:
+ properties:
+ snps,dcb-algorithm: false
+ snps,weight: false
+ additionalProperties: false
+ additionalProperties: false
snps,reset-gpio:
deprecated: true
@@ -244,6 +460,32 @@ properties:
description:
Use Address-Aligned Beats
+ snps,pbl:
+ description:
+ Programmable Burst Length (tx and rx)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4, 8, 16, 32]
+
+ snps,txpbl:
+ description:
+ Tx Programmable Burst Length. If set, DMA tx will use this
+ value rather than snps,pbl.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4, 8, 16, 32]
+
+ snps,rxpbl:
+ description:
+ Rx Programmable Burst Length. If set, DMA rx will use this
+ value rather than snps,pbl.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 4, 8, 16, 32]
+
+ snps,no-pbl-x8:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
+ rev < 3.50, don\'t multiply the values by 4.
+
snps,fixed-burst:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -267,6 +509,7 @@ properties:
snps,en-tx-lpi-clockgating:
$ref: /schemas/types.yaml#/definitions/flag
+ deprecated: true
description:
Enable gating of the MAC TX clock during TX low-power mode
@@ -294,6 +537,12 @@ properties:
description:
Frequency division factor for MDC clock.
+ snps,tso:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enables the TSO feature otherwise it will be managed by MAC HW capability
+ register.
+
mdio:
$ref: mdio.yaml#
unevaluatedProperties: false
@@ -335,7 +584,7 @@ properties:
max read outstanding req. limit
snps,kbbe:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/flag
description:
do not cross 1KiB boundary.
@@ -370,134 +619,52 @@ required:
dependencies:
snps,reset-active-low: ["snps,reset-gpio"]
- snps,reset-delay-us: ["snps,reset-gpio"]
+ snps,reset-delays-us: ["snps,reset-gpio"]
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
- if:
properties:
compatible:
- contains:
- enum:
- - allwinner,sun7i-a20-gmac
- - allwinner,sun8i-a83t-emac
- - allwinner,sun8i-h3-emac
- - allwinner,sun8i-r40-gmac
- - allwinner,sun8i-v3s-emac
- - allwinner,sun50i-a64-emac
- - ingenic,jz4775-mac
- - ingenic,x1000-mac
- - ingenic,x1600-mac
- - ingenic,x1830-mac
- - ingenic,x2000-mac
- - snps,dwmac-3.50a
- - snps,dwmac-4.10a
- - snps,dwmac-4.20a
- - snps,dwxgmac
- - snps,dwxgmac-2.10
- - st,spear600-gmac
+ not:
+ contains:
+ enum:
+ - allwinner,sun7i-a20-gmac
+ - allwinner,sun8i-a83t-emac
+ - allwinner,sun8i-h3-emac
+ - allwinner,sun8i-r40-gmac
+ - allwinner,sun8i-v3s-emac
+ - allwinner,sun50i-a64-emac
+ - loongson,ls2k-dwmac
+ - loongson,ls7a-dwmac
+ - ingenic,jz4775-mac
+ - ingenic,x1000-mac
+ - ingenic,x1600-mac
+ - ingenic,x1830-mac
+ - ingenic,x2000-mac
+ - qcom,qcs404-ethqos
+ - qcom,sa8775p-ethqos
+ - qcom,sc8280xp-ethqos
+ - qcom,sm8150-ethqos
+ - snps,dwmac-4.00
+ - snps,dwmac-4.10a
+ - snps,dwmac-4.20a
+ - snps,dwmac-5.00a
+ - snps,dwmac-5.10a
+ - snps,dwmac-5.20
+ - snps,dwmac-5.30a
+ - snps,dwxgmac
+ - snps,dwxgmac-2.10
+ - st,spear600-gmac
then:
properties:
- snps,pbl:
- description:
- Programmable Burst Length (tx and rx)
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 4, 8, 16, 32]
-
- snps,txpbl:
- description:
- Tx Programmable Burst Length. If set, DMA tx will use this
- value rather than snps,pbl.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 4, 8, 16, 32]
-
- snps,rxpbl:
- description:
- Rx Programmable Burst Length. If set, DMA rx will use this
- value rather than snps,pbl.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 4, 8, 16, 32]
-
- snps,no-pbl-x8:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core
- rev < 3.50, don\'t multiply the values by 4.
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - allwinner,sun7i-a20-gmac
- - allwinner,sun8i-a83t-emac
- - allwinner,sun8i-h3-emac
- - allwinner,sun8i-r40-gmac
- - allwinner,sun8i-v3s-emac
- - allwinner,sun50i-a64-emac
- - loongson,ls2k-dwmac
- - loongson,ls7a-dwmac
- - ingenic,jz4775-mac
- - ingenic,x1000-mac
- - ingenic,x1600-mac
- - ingenic,x1830-mac
- - ingenic,x2000-mac
- - snps,dwmac-4.00
- - snps,dwmac-4.10a
- - snps,dwmac-4.20a
- - snps,dwmac-5.10a
- - snps,dwxgmac
- - snps,dwxgmac-2.10
- - st,spear600-gmac
-
- then:
- properties:
- snps,tso:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Enables the TSO feature otherwise it will be managed by
- MAC HW capability register.
+ snps,tso: false
additionalProperties: true
examples:
- |
- stmmac_axi_setup: stmmac-axi-config {
- snps,wr_osr_lmt = <0xf>;
- snps,rd_osr_lmt = <0xf>;
- snps,blen = <256 128 64 32 0 0 0>;
- };
-
- mtl_rx_setup: rx-queues-config {
- snps,rx-queues-to-use = <1>;
- snps,rx-sched-sp;
- queue0 {
- snps,dcb-algorithm;
- snps,map-to-dma-channel = <0x0>;
- snps,priority = <0x0>;
- };
- };
-
- mtl_tx_setup: tx-queues-config {
- snps,tx-queues-to-use = <2>;
- snps,tx-sched-wrr;
- queue0 {
- snps,weight = <0x10>;
- snps,dcb-algorithm;
- snps,priority = <0x0>;
- };
-
- queue1 {
- snps,avb-algorithm;
- snps,send_slope = <0x1000>;
- snps,idle_slope = <0x1000>;
- snps,high_credit = <0x3E800>;
- snps,low_credit = <0xFFC18000>;
- snps,priority = <0x1>;
- };
- };
-
gmac0: ethernet@e0800000 {
compatible = "snps,dwxgmac-2.10", "snps,dwxgmac";
reg = <0xe0800000 0x8000>;
@@ -516,7 +683,43 @@ examples:
snps,axi-config = <&stmmac_axi_setup>;
snps,mtl-rx-config = <&mtl_rx_setup>;
snps,mtl-tx-config = <&mtl_tx_setup>;
- mdio0 {
+
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,wr_osr_lmt = <0xf>;
+ snps,rd_osr_lmt = <0xf>;
+ snps,blen = <256 128 64 32 0 0 0>;
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <1>;
+ snps,rx-sched-sp;
+ queue0 {
+ snps,dcb-algorithm;
+ snps,map-to-dma-channel = <0x0>;
+ snps,priority = <0x0>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <2>;
+ snps,tx-sched-wrr;
+ queue0 {
+ snps,weight = <0x10>;
+ snps,dcb-algorithm;
+ snps,priority = <0x0>;
+ };
+
+ queue1 {
+ snps,avb-algorithm;
+ snps,send_slope = <0x1000>;
+ snps,idle_slope = <0x1000>;
+ snps,high_credit = <0x3E800>;
+ snps,low_credit = <0xFFC18000>;
+ snps,priority = <0x1>;
+ };
+ };
+
+ mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,dwmac-mdio";
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
deleted file mode 100644
index 612a8e8abc88..000000000000
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Altera SOCFPGA SoC DWMAC controller
-
-This is a variant of the dwmac/stmmac driver an inherits all descriptions
-present in Documentation/devicetree/bindings/net/stmmac.txt.
-
-The device node has additional properties:
-
-Required properties:
- - compatible : For Cyclone5/Arria5 SoCs it should contain
- "altr,socfpga-stmmac". For Arria10/Agilex/Stratix10 SoCs
- "altr,socfpga-stmmac-a10-s10".
- Along with "snps,dwmac" and any applicable more detailed
- designware version numbers documented in stmmac.txt
- - altr,sysmgr-syscon : Should be the phandle to the system manager node that
- encompasses the glue register, the register offset, and the register shift.
- On Cyclone5/Arria5, the register shift represents the PHY mode bits, while
- on the Arria10/Stratix10/Agilex platforms, the register shift represents
- bit for each emac to enable/disable signals from the FPGA fabric to the
- EMAC modules.
- - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock
- for ptp ref clk. This affects all emacs as the clock is common.
-
-Optional properties:
-altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
- DWMAC controller is connected emac splitter.
-phy-mode: The phy mode the ethernet operates in
-altr,sgmii-to-sgmii-converter: phandle to the TSE SGMII converter
-
-This device node has additional phandle dependency, the sgmii converter:
-
-Required properties:
- - compatible : Should be altr,gmii-to-sgmii-2.0
- - reg-names : Should be "eth_tse_control_port"
-
-Example:
-
-gmii_to_sgmii_converter: phy@100000240 {
- compatible = "altr,gmii-to-sgmii-2.0";
- reg = <0x00000001 0x00000240 0x00000008>,
- <0x00000001 0x00000200 0x00000040>;
- reg-names = "eth_tse_control_port";
- clocks = <&sgmii_1_clk_0 &emac1 1 &sgmii_clk_125 &sgmii_clk_125>;
- clock-names = "tse_pcs_ref_clk_clock_connection", "tse_rx_cdr_refclk";
-};
-
-gmac0: ethernet@ff700000 {
- compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
- altr,sysmgr-syscon = <&sysmgr 0x60 0>;
- reg = <0xff700000 0x2000>;
- interrupts = <0 115 4>;
- interrupt-names = "macirq";
- mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
- clocks = <&emac_0_clk>;
- clock-names = "stmmaceth";
- phy-mode = "sgmii";
- altr,gmii-to-sgmii-converter = <&gmii_to_sgmii_converter>;
-};
diff --git a/Documentation/devicetree/bindings/net/socionext,synquacer-netsec.yaml b/Documentation/devicetree/bindings/net/socionext,synquacer-netsec.yaml
new file mode 100644
index 000000000000..a65e6aa215a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socionext,synquacer-netsec.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/socionext,synquacer-netsec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext NetSec Ethernet Controller IP
+
+maintainers:
+ - Jassi Brar <jaswinder.singh@linaro.org>
+ - Ilias Apalodimas <ilias.apalodimas@linaro.org>
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ const: socionext,synquacer-netsec
+
+ reg:
+ items:
+ - description: control register area
+ - description: EEPROM holding the MAC address and microengine firmware
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: phy_ref_clk
+
+ dma-coherent: true
+
+ interrupts:
+ maxItems: 1
+
+ mdio:
+ $ref: mdio.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - mdio
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@522d0000 {
+ compatible = "socionext,synquacer-netsec";
+ reg = <0x522d0000 0x10000>, <0x10000000 0x10000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_netsec>;
+ clock-names = "phy_ref_clk";
+ phy-mode = "rgmii";
+ max-speed = <1000>;
+ max-frame-size = <9000>;
+ phy-handle = <&phy1>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
index b0ebcef6801c..4eb63b303cff 100644
--- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
+++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
@@ -41,13 +41,17 @@ properties:
minItems: 1
maxItems: 4
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 4
resets:
minItems: 1
maxItems: 2
- reset-names: true
+ reset-names:
+ minItems: 1
+ maxItems: 2
socionext,syscon-phy-mode:
$ref: /schemas/types.yaml#/definitions/phandle-array
diff --git a/Documentation/devicetree/bindings/net/socionext-netsec.txt b/Documentation/devicetree/bindings/net/socionext-netsec.txt
deleted file mode 100644
index a3c1dffaa4bb..000000000000
--- a/Documentation/devicetree/bindings/net/socionext-netsec.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Socionext NetSec Ethernet Controller IP
-
-Required properties:
-- compatible: Should be "socionext,synquacer-netsec"
-- reg: Address and length of the control register area, followed by the
- address and length of the EEPROM holding the MAC address and
- microengine firmware
-- interrupts: Should contain ethernet controller interrupt
-- clocks: phandle to the PHY reference clock
-- clock-names: Should be "phy_ref_clk"
-- phy-mode: See ethernet.txt file in the same directory
-- phy-handle: See ethernet.txt in the same directory.
-
-- mdio device tree subnode: When the Netsec has a phy connected to its local
- mdio, there must be device tree subnode with the following
- required properties:
-
- - #address-cells: Must be <1>.
- - #size-cells: Must be <0>.
-
- For each phy on the mdio bus, there must be a node with the following
- fields:
- - compatible: Refer to phy.txt
- - reg: phy id used to communicate to phy.
-
-Optional properties: (See ethernet.txt file in the same directory)
-- dma-coherent: Boolean property, must only be present if memory
- accesses performed by the device are cache coherent.
-- max-speed: See ethernet.txt in the same directory.
-- max-frame-size: See ethernet.txt in the same directory.
-
-The MAC address will be determined using the optional properties
-defined in ethernet.txt. The 'phy-mode' property is required, but may
-be set to the empty string if the PHY configuration is programmed by
-the firmware or set by hardware straps, and needs to be preserved.
-
-Example:
- eth0: ethernet@522d0000 {
- compatible = "socionext,synquacer-netsec";
- reg = <0 0x522d0000 0x0 0x10000>, <0 0x10000000 0x0 0x10000>;
- interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_netsec>;
- clock-names = "phy_ref_clk";
- phy-mode = "rgmii";
- max-speed = <1000>;
- max-frame-size = <9000>;
- phy-handle = <&phy1>;
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml b/Documentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml
new file mode 100644
index 000000000000..b89456f0ef83
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/sophgo,cv1800b-dwmac.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/sophgo,cv1800b-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800B DWMAC glue layer
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sophgo,cv1800b-dwmac
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: sophgo,cv1800b-dwmac
+ - const: snps,dwmac-3.70a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: PTP clock
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: ptp_ref
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ethernet@4070000 {
+ compatible = "sophgo,cv1800b-dwmac", "snps,dwmac-3.70a";
+ reg = <0x04070000 0x10000>;
+ clocks = <&clk 35>, <&clk 36>;
+ clock-names = "stmmaceth", "ptp_ref";
+ interrupts = <31 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "internal";
+ resets = <&rst 12>;
+ reset-names = "stmmaceth";
+ rx-fifo-depth = <8192>;
+ tx-fifo-depth = <8192>;
+ snps,multicast-filter-bins = <0>;
+ snps,perfect-filter-entries = <1>;
+ snps,aal;
+ snps,txpbl = <8>;
+ snps,rxpbl = <8>;
+ snps,mtl-rx-config = <&gmac0_mtl_rx_setup>;
+ snps,mtl-tx-config = <&gmac0_mtl_tx_setup>;
+ snps,axi-config = <&gmac0_stmmac_axi_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ gmac0_mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <1>;
+ queue0 {};
+ };
+
+ gmac0_mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <1>;
+ queue0 {};
+ };
+
+ gmac0_stmmac_axi_setup: stmmac-axi-config {
+ snps,blen = <16 8 4 0 0 0 0>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml b/Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml
new file mode 100644
index 000000000000..e8d3814db0e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/sophgo,sg2044-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2044 DWMAC glue layer
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - sophgo,sg2044-dwmac
+ - sophgo,sg2042-dwmac
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: sophgo,sg2042-dwmac
+ - const: snps,dwmac-5.00a
+ - items:
+ - const: sophgo,sg2044-dwmac
+ - const: snps,dwmac-5.30a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: PTP clock
+ - description: TX clock
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: ptp_ref
+ - const: tx
+
+ dma-noncoherent: true
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: sophgo,sg2042-dwmac
+ then:
+ properties:
+ phy-mode:
+ enum:
+ - rgmii-rxid
+ - rgmii-id
+ else:
+ properties:
+ phy-mode:
+ enum:
+ - rgmii
+ - rgmii-rxid
+ - rgmii-txid
+ - rgmii-id
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ethernet@30006000 {
+ compatible = "sophgo,sg2044-dwmac", "snps,dwmac-5.30a";
+ reg = <0x30006000 0x4000>;
+ clocks = <&clk 151>, <&clk 152>, <&clk 154>;
+ clock-names = "stmmaceth", "ptp_ref", "tx";
+ interrupt-parent = <&intc>;
+ interrupts = <296 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ phy-handle = <&phy0>;
+ phy-mode = "rgmii-id";
+ resets = <&rst 30>;
+ reset-names = "stmmaceth";
+ snps,multicast-filter-bins = <0>;
+ snps,perfect-filter-entries = <1>;
+ snps,aal;
+ snps,tso;
+ snps,txpbl = <32>;
+ snps,rxpbl = <32>;
+ snps,mtl-rx-config = <&gmac0_mtl_rx_setup>;
+ snps,mtl-tx-config = <&gmac0_mtl_tx_setup>;
+ snps,axi-config = <&gmac0_stmmac_axi_setup>;
+
+ gmac0_mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <8>;
+ snps,rx-sched-wsp;
+ queue0 {};
+ queue1 {};
+ queue2 {};
+ queue3 {};
+ queue4 {};
+ queue5 {};
+ queue6 {};
+ queue7 {};
+ };
+
+ gmac0_mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <8>;
+ queue0 {};
+ queue1 {};
+ queue2 {};
+ queue3 {};
+ queue4 {};
+ queue5 {};
+ queue6 {};
+ queue7 {};
+ };
+
+ gmac0_stmmac_axi_setup: stmmac-axi-config {
+ snps,blen = <16 8 4 0 0 0 0>;
+ snps,wr_osr_lmt = <1>;
+ snps,rd_osr_lmt = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/spacemit,k1-emac.yaml b/Documentation/devicetree/bindings/net/spacemit,k1-emac.yaml
new file mode 100644
index 000000000000..500a3e1daa23
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/spacemit,k1-emac.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/spacemit,k1-emac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 Ethernet MAC
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+maintainers:
+ - Vivian Wang <wangruikang@iscas.ac.cn>
+
+properties:
+ compatible:
+ const: spacemit,k1-emac
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ mdio-bus:
+ $ref: mdio.yaml#
+ unevaluatedProperties: false
+
+ resets:
+ maxItems: 1
+
+ spacemit,apmu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscon that controls this MAC
+ - description: offset of control registers
+ description:
+ A phandle to syscon with byte offset to control registers for this MAC
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - resets
+ - spacemit,apmu
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+
+ ethernet@cac80000 {
+ compatible = "spacemit,k1-emac";
+ reg = <0xcac80000 0x00000420>;
+ clocks = <&syscon_apmu CLK_EMAC0_BUS>;
+ interrupts = <131>;
+ mac-address = [ 00 00 00 00 00 00 ];
+ phy-handle = <&rgmii0>;
+ phy-mode = "rgmii-id";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_cfg>;
+ resets = <&syscon_apmu RESET_EMAC0>;
+ rx-internal-delay-ps = <0>;
+ tx-internal-delay-ps = <0>;
+ spacemit,apmu = <&syscon_apmu 0x3e4>;
+
+ mdio-bus {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ rgmii0: phy@1 {
+ reg = <0x1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
new file mode 100644
index 000000000000..313a15331661
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 StarFive Technology Co., Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/starfive,jh7110-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 DWMAC glue layer
+
+maintainers:
+ - Emil Renner Berthing <kernel@esmil.dk>
+ - Samin Guo <samin.guo@starfivetech.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - starfive,jh7100-dwmac
+ - starfive,jh7110-dwmac
+ required:
+ - compatible
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: starfive,jh7100-dwmac
+ - const: snps,dwmac
+ - items:
+ - const: starfive,jh7110-dwmac
+ - const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jh8100-dwmac
+ - const: starfive,jh7110-dwmac
+ - const: snps,dwmac-5.20
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: GMAC AHB clock
+ - description: PTP clock
+ - description: TX clock
+ - description: GTX clock
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: pclk
+ - const: ptp_ref
+ - const: tx
+ - const: gtx
+
+ starfive,tx-use-rgmii-clk:
+ description:
+ Tx clock is provided by external rgmii clock.
+ type: boolean
+
+ starfive,syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscon that configures phy mode
+ - description: Offset of phy mode selection
+ - description: Shift of phy mode selection
+ description:
+ A phandle to syscon with two arguments that configure phy mode.
+ The argument one is the offset of phy mode selection, the
+ argument two is the shift of phy mode selection.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7100-dwmac
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 2
+ maxItems: 2
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: ahb
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-dwmac
+ then:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 3
+ maxItems: 3
+
+ if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh8100-dwmac
+ then:
+ properties:
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+ else:
+ properties:
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@16030000 {
+ compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
+ reg = <0x16030000 0x10000>;
+ clocks = <&clk 3>, <&clk 2>, <&clk 109>,
+ <&clk 6>, <&clk 111>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "gtx";
+ resets = <&rst 1>, <&rst 2>;
+ reset-names = "stmmaceth", "ahb";
+ interrupts = <7>, <6>, <5>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ phy-mode = "rgmii-id";
+ snps,multicast-filter-bins = <64>;
+ snps,perfect-filter-entries = <8>;
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ snps,fixed-burst;
+ snps,no-pbl-x8;
+ snps,tso;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,en-tx-lpi-clockgating;
+ snps,txpbl = <16>;
+ snps,rxpbl = <16>;
+ starfive,syscon = <&aon_syscon 0xc 0x12>;
+ phy-handle = <&phy0>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,lpi_en;
+ snps,wr_osr_lmt = <4>;
+ snps,rd_osr_lmt = <4>;
+ snps,blen = <256 128 64 32 0 0 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/sti-dwmac.txt b/Documentation/devicetree/bindings/net/sti-dwmac.txt
index 062c5174add3..e16287c06e5e 100644
--- a/Documentation/devicetree/bindings/net/sti-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/sti-dwmac.txt
@@ -7,8 +7,7 @@ and what is needed on STi platforms to program the stmmac glue logic.
The device node has following properties.
Required properties:
- - compatible : Can be "st,stih415-dwmac", "st,stih416-dwmac",
- "st,stih407-dwmac", "st,stid127-dwmac".
+ - compatible : "st,stih407-dwmac"
- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
encompases the glue register, and the offset of the control register.
- st,gmac_en: this is to enable the gmac into a dedicated sysctl control
@@ -22,7 +21,7 @@ Optional properties:
MAC can generate it.
- st,tx-retime-src: This specifies which clk is wired up to the mac for
retimeing tx lines. This is totally board dependent and can take one of the
- posssible values from "txclk", "clk_125" or "clkgen".
+ possible values from "txclk", "clk_125" or "clkgen".
If not passed, the internal clock will be used by default.
- sti-ethclk: this is the phy clock.
- sti-clkconf: this is an extra sysconfig register, available in new SoCs,
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index 5c93167b3b41..987254900d0d 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/stm32-dwmac.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/stm32-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 / MCU DWMAC glue layer controller
@@ -22,18 +22,22 @@ select:
enum:
- st,stm32-dwmac
- st,stm32mp1-dwmac
+ - st,stm32mp13-dwmac
+ - st,stm32mp25-dwmac
required:
- compatible
-allOf:
- - $ref: "snps,dwmac.yaml#"
-
properties:
compatible:
oneOf:
- items:
- enum:
+ - st,stm32mp25-dwmac
+ - const: snps,dwmac-5.20
+ - items:
+ - enum:
- st,stm32mp1-dwmac
+ - st,stm32mp13-dwmac
- const: snps,dwmac-4.20a
- items:
- enum:
@@ -50,6 +54,16 @@ properties:
items:
- const: stmmaceth
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: macirq
+ - const: eth_wake_irq
+
clocks:
minItems: 3
items:
@@ -73,14 +87,24 @@ properties:
- ptp_ref
st,syscon:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- - items:
+ - minItems: 2
+ items:
- description: phandle to the syscon node which encompases the glue register
- description: offset of the control register
+ - description: field to set mask in register
description:
Should be phandle/offset pair. The phandle to the syscon node which
- encompases the glue register, and the offset of the control register
+ encompases the glue register, the offset of the control register and
+ the mask to set bitfield in control register
+
+ st,ext-phyclk:
+ description:
+ set this property in RMII mode when you have PHY without crystal 50MHz and want to
+ select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
+ RCC clock instead of ETH_CLK125.
+ type: boolean
st,eth-clk-sel:
description:
@@ -93,6 +117,10 @@ properties:
select RCC clock instead of ETH_REF_CLK.
type: boolean
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- clocks
@@ -101,63 +129,91 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: snps,dwmac.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32-dwmac
+ - st,stm32mp1-dwmac
+ - st,stm32mp25-dwmac
+ then:
+ properties:
+ st,syscon:
+ items:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp13-dwmac
+ then:
+ properties:
+ st,syscon:
+ items:
+ minItems: 3
+ maxItems: 3
+
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
- #include <dt-bindings/reset/stm32mp1-resets.h>
- #include <dt-bindings/mfd/stm32h7-rcc.h>
//Example 1
- ethernet0: ethernet@5800a000 {
- compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
- reg = <0x5800a000 0x2000>;
- reg-names = "stmmaceth";
- interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "macirq";
- clock-names = "stmmaceth",
- "mac-clk-tx",
- "mac-clk-rx",
- "ethstp",
- "eth-ck";
- clocks = <&rcc ETHMAC>,
- <&rcc ETHTX>,
- <&rcc ETHRX>,
- <&rcc ETHSTP>,
- <&rcc ETHCK_K>;
- st,syscon = <&syscfg 0x4>;
- snps,pbl = <2>;
- snps,axi-config = <&stmmac_axi_config_0>;
- snps,tso;
- phy-mode = "rgmii";
- };
+ ethernet0: ethernet@5800a000 {
+ compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a";
+ reg = <0x5800a000 0x2000>;
+ reg-names = "stmmaceth";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clock-names = "stmmaceth",
+ "mac-clk-tx",
+ "mac-clk-rx",
+ "ethstp",
+ "eth-ck";
+ clocks = <&rcc ETHMAC>,
+ <&rcc ETHTX>,
+ <&rcc ETHRX>,
+ <&rcc ETHSTP>,
+ <&rcc ETHCK_K>;
+ st,syscon = <&syscfg 0x4>;
+ snps,pbl = <2>;
+ snps,axi-config = <&stmmac_axi_config_0>;
+ snps,tso;
+ phy-mode = "rgmii";
+ };
- |
//Example 2 (MCU example)
- ethernet1: ethernet@40028000 {
- compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
- reg = <0x40028000 0x8000>;
- reg-names = "stmmaceth";
- interrupts = <0 61 0>, <0 62 0>;
- interrupt-names = "macirq", "eth_wake_irq";
- clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
- clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
- st,syscon = <&syscfg 0x4>;
- snps,pbl = <8>;
- snps,mixed-burst;
- phy-mode = "mii";
- };
+ ethernet1: ethernet@40028000 {
+ compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+ reg = <0x40028000 0x8000>;
+ reg-names = "stmmaceth";
+ interrupts = <0 61 0>, <0 62 0>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
+ clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+ st,syscon = <&syscfg 0x4>;
+ snps,pbl = <8>;
+ snps,mixed-burst;
+ phy-mode = "mii";
+ };
- |
//Example 3
- ethernet2: ethernet@40027000 {
- compatible = "st,stm32-dwmac", "snps,dwmac-4.10a";
- reg = <0x40028000 0x8000>;
- reg-names = "stmmaceth";
- interrupts = <61>;
- interrupt-names = "macirq";
- clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
- clocks = <&rcc 62>, <&rcc 61>, <&rcc 60>;
- st,syscon = <&syscfg 0x4>;
- snps,pbl = <8>;
- phy-mode = "mii";
- };
+ ethernet2: ethernet@40027000 {
+ compatible = "st,stm32-dwmac", "snps,dwmac-4.10a";
+ reg = <0x40028000 0x8000>;
+ reg-names = "stmmaceth";
+ interrupts = <61>;
+ interrupt-names = "macirq";
+ clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
+ clocks = <&rcc 62>, <&rcc 61>, <&rcc 60>;
+ st,syscon = <&syscfg 0x4>;
+ snps,pbl = <8>;
+ phy-mode = "mii";
+ };
diff --git a/Documentation/devicetree/bindings/net/sunplus,sp7021-emac.yaml b/Documentation/devicetree/bindings/net/sunplus,sp7021-emac.yaml
index 8e51dcdb4796..5b130097449b 100644
--- a/Documentation/devicetree/bindings/net/sunplus,sp7021-emac.yaml
+++ b/Documentation/devicetree/bindings/net/sunplus,sp7021-emac.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/net/sunplus,sp7021-emac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Sunplus SP7021 Dual Ethernet MAC Device Tree Bindings
+title: Sunplus SP7021 Dual Ethernet MAC
maintainers:
- Wells Lu <wellslutw@gmail.com>
diff --git a/Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml b/Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml
new file mode 100644
index 000000000000..dd7481bb16e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/tesla,fsd-ethqos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FSD Ethernet Quality of Service
+
+maintainers:
+ - Swathi K S <swathi.ks@samsung.com>
+
+description:
+ Tesla ethernet devices based on dwmmac support Gigabit ethernet.
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ const: tesla,fsd-ethqos
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: macirq
+
+ clocks:
+ minItems: 5
+ items:
+ - description: PTP clock
+ - description: Master bus clock
+ - description: Slave bus clock
+ - description: MAC TX clock
+ - description: MAC RX clock
+ - description: Master2 bus clock
+ - description: Slave2 bus clock
+ - description: RX MUX clock
+ - description: PHY RX clock
+ - description: PERIC RGMII clock
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: ptp_ref
+ - const: master_bus
+ - const: slave_bus
+ - const: tx
+ - const: rx
+ - const: master2_bus
+ - const: slave2_bus
+ - const: eqos_rxclk_mux
+ - const: eqos_phyrxclk
+ - const: dout_peric_rgmii_clk
+
+ iommus:
+ maxItems: 1
+
+ phy-mode:
+ enum:
+ - rgmii
+ - rgmii-id
+ - rgmii-rxid
+ - rgmii-txid
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - iommus
+ - phy-mode
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/fsd-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ethernet1: ethernet@14300000 {
+ compatible = "tesla,fsd-ethqos";
+ reg = <0x0 0x14300000 0x0 0x10000>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clocks = <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_CLK_PTP_REF_I>,
+ <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_ACLK_I>,
+ <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_HCLK_I>,
+ <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_RGMII_CLK_I>,
+ <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_CLK_RX_I>,
+ <&clock_peric PERIC_BUS_D_PERIC_IPCLKPORT_EQOSCLK>,
+ <&clock_peric PERIC_BUS_P_PERIC_IPCLKPORT_EQOSCLK>,
+ <&clock_peric PERIC_EQOS_PHYRXCLK_MUX>,
+ <&clock_peric PERIC_EQOS_PHYRXCLK>,
+ <&clock_peric PERIC_DOUT_RGMII_CLK>;
+ clock-names = "ptp_ref", "master_bus", "slave_bus","tx",
+ "rx", "master2_bus", "slave2_bus", "eqos_rxclk_mux",
+ "eqos_phyrxclk","dout_peric_rgmii_clk";
+ assigned-clocks = <&clock_peric PERIC_EQOS_PHYRXCLK_MUX>,
+ <&clock_peric PERIC_EQOS_PHYRXCLK>;
+ assigned-clock-parents = <&clock_peric PERIC_EQOS_PHYRXCLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&eth1_tx_clk>, <&eth1_tx_data>, <&eth1_tx_ctrl>,
+ <&eth1_phy_intr>, <&eth1_rx_clk>, <&eth1_rx_data>,
+ <&eth1_rx_ctrl>, <&eth1_mdio>;
+ iommus = <&smmu_peric 0x0 0x1>;
+ phy-mode = "rgmii-id";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/thead,th1520-gmac.yaml b/Documentation/devicetree/bindings/net/thead,th1520-gmac.yaml
new file mode 100644
index 000000000000..b3492a9aa4ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/thead,th1520-gmac.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/thead,th1520-gmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD TH1520 GMAC Ethernet controller
+
+maintainers:
+ - Drew Fustini <dfustini@tenstorrent.com>
+
+description: |
+ The TH1520 GMAC is described in the TH1520 Peripheral Interface User Manual
+ https://git.beagleboard.org/beaglev-ahead/beaglev-ahead/-/tree/main/docs
+
+ Features include
+ - Compliant with IEEE802.3 Specification
+ - IEEE 1588-2008 standard for precision networked clock synchronization
+ - Supports 10/100/1000Mbps data transfer rate
+ - Supports RGMII/MII interface
+ - Preamble and start of frame data (SFD) insertion in Transmit path
+ - Preamble and SFD deletion in the Receive path
+ - Automatic CRC and pad generation options for receive frames
+ - MDIO master interface for PHY device configuration and management
+
+ The GMAC Registers consists of two parts
+ - APB registers are used to configure clock frequency/clock enable/clock
+ direction/PHY interface type.
+ - AHB registers are use to configure GMAC core (DesignWare Core part).
+ GMAC core register consists of DMA registers and GMAC registers.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - thead,th1520-gmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - thead,th1520-gmac
+ - const: snps,dwmac-3.70a
+
+ reg:
+ items:
+ - description: DesignWare GMAC IP core registers
+ - description: GMAC APB registers
+
+ reg-names:
+ items:
+ - const: dwmac
+ - const: apb
+
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: Peripheral registers interface clock
+ - description: APB glue registers interface clock
+
+ clock-names:
+ items:
+ - const: stmmaceth
+ - const: pclk
+ - const: apb
+
+ interrupts:
+ items:
+ - description: Combined signal for various interrupt events
+
+ interrupt-names:
+ items:
+ - const: macirq
+
+required:
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gmac0: ethernet@e7070000 {
+ compatible = "thead,th1520-gmac", "snps,dwmac-3.70a";
+ reg = <0xe7070000 0x2000>, <0xec003000 0x1000>;
+ reg-names = "dwmac", "apb";
+ clocks = <&clk 1>, <&clk 2>, <&clk 3>;
+ clock-names = "stmmaceth", "pclk", "apb";
+ interrupts = <66>;
+ interrupt-names = "macirq";
+ phy-mode = "rgmii-id";
+ snps,fixed-burst;
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,pbl = <32>;
+ phy-handle = <&phy0>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml b/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml
new file mode 100644
index 000000000000..4f4253441547
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,cc1352p7.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,cc1352p7.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments Simplelink CC1352P7 wireless MCU
+
+description:
+ The CC1352P7 MCU can be connected via SPI or UART.
+
+maintainers:
+ - Ayush Singh <ayushdevel1325@gmail.com>
+
+properties:
+ compatible:
+ const: ti,cc1352p7
+
+ clocks:
+ items:
+ - description: high-frequency main system (MCU and peripherals) clock
+ - description: low-frequency system clock
+
+ clock-names:
+ items:
+ - const: sclk_hf
+ - const: sclk_lf
+
+ reset-gpios:
+ maxItems: 1
+
+ bootloader-backdoor-gpios:
+ maxItems: 1
+ description: |
+ gpios to enable bootloader backdoor in cc1352p7 bootloader to allow
+ flashing new firmware.
+
+ vdds-supply: true
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ serial {
+ mcu {
+ compatible = "ti,cc1352p7";
+ clocks = <&sclk_hf 0>, <&sclk_lf 25>;
+ clock-names = "sclk_hf", "sclk_lf";
+ reset-gpios = <&pio 35 GPIO_ACTIVE_LOW>;
+ bootloader-backdoor-gpios = <&pio 36 GPIO_ACTIVE_LOW>;
+ vdds-supply = <&vdds>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
index 46e330f45768..8b5da602a2e8 100644
--- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
+++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/net/ti,cpsw-switch.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI SoC Ethernet Switch Controller (CPSW) Device Tree Bindings
+title: TI SoC Ethernet Switch Controller (CPSW)
maintainers:
- - Grygorii Strashko <grygorii.strashko@ti.com>
- - Sekhar Nori <nsekhar@ti.com>
+ - Siddharth Vadapalli <s-vadapalli@ti.com>
+ - Roger Quadros <rogerq@kernel.org>
description:
The 3-port switch gigabit ethernet subsystem provides ethernet packet
@@ -62,10 +62,10 @@ properties:
interrupt-names:
items:
- - const: "rx_thresh"
- - const: "rx"
- - const: "tx"
- - const: "misc"
+ - const: rx_thresh
+ - const: rx
+ - const: tx
+ - const: misc
pinctrl-names: true
@@ -86,7 +86,7 @@ properties:
const: 0
patternProperties:
- "^port@[0-9]+$":
+ "^port@[12]$":
type: object
description: CPSW external ports
@@ -154,8 +154,7 @@ patternProperties:
type: object
description:
CPSW MDIO bus.
- $ref: "ti,davinci-mdio.yaml#"
-
+ $ref: ti,davinci-mdio.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml
index a339202c5e8e..08119b6880ee 100644
--- a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml
+++ b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml
@@ -13,7 +13,7 @@ description:
TI SoC Davinci/Keystone2 MDIO Controller
allOf:
- - $ref: "mdio.yaml#"
+ - $ref: mdio.yaml#
properties:
compatible:
@@ -72,9 +72,9 @@ unevaluatedProperties: false
examples:
- |
davinci_mdio: mdio@4a101000 {
- compatible = "ti,davinci_mdio";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x4a101000 0x1000>;
- bus_freq = <1000000>;
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a101000 0x1000>;
+ bus_freq = <1000000>;
};
diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml
index f2489a9c852f..28a0bddb9af9 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2020 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/ti,dp83822.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/ti,dp83822.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI DP83822 ethernet PHY
@@ -21,7 +21,7 @@ description: |
http://www.ti.com/lit/ds/symlink/dp83822i.pdf
allOf:
- - $ref: "ethernet-phy.yaml#"
+ - $ref: ethernet-phy.yaml#
properties:
reg:
@@ -62,6 +62,69 @@ properties:
for the PHY. The internal delay for the PHY is fixed to 3.5ns relative
to transmit data.
+ ti,cfg-dac-minus-one-bp:
+ description: |
+ DP83826 PHY only.
+ Sets the voltage ratio (with respect to the nominal value)
+ of the logical level -1 for the MLT-3 encoded TX data.
+ enum: [5000, 5625, 6250, 6875, 7500, 8125, 8750, 9375, 10000,
+ 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000]
+ default: 10000
+
+ ti,cfg-dac-plus-one-bp:
+ description: |
+ DP83826 PHY only.
+ Sets the voltage ratio (with respect to the nominal value)
+ of the logical level +1 for the MLT-3 encoded TX data.
+ enum: [5000, 5625, 6250, 6875, 7500, 8125, 8750, 9375, 10000,
+ 10625, 11250, 11875, 12500, 13125, 13750, 14375, 15000]
+ default: 10000
+
+ ti,rmii-mode:
+ description: |
+ If present, select the RMII operation mode. Two modes are
+ available:
+ - RMII master, where the PHY outputs a 50MHz reference clock which can
+ be connected to the MAC.
+ - RMII slave, where the PHY expects a 50MHz reference clock input
+ shared with the MAC.
+ The RMII operation mode can also be configured by its straps.
+ If the strap pin is not set correctly or not set at all, then this can be
+ used to configure it.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - master
+ - slave
+
+ ti,gpio2-clk-out:
+ description: |
+ DP83822 PHY only.
+ The GPIO2 pin on the DP83822 can be configured as clock output. When
+ omitted, the PHY's default will be left as is.
+
+ - 'mac-if': In MII mode the clock frequency is 25-MHz, in RMII Mode the
+ clock frequency is 50-MHz and in RGMII Mode the clock frequency is
+ 25-MHz.
+ - 'xi': XI clock(pass-through clock from XI pin).
+ - 'int-ref': Internal reference clock 25-MHz.
+ - 'rmii-master-mode-ref': RMII master mode reference clock 50-MHz. RMII
+ master mode reference clock is identical to MAC IF clock in RMII master
+ mode.
+ - 'free-running': Free running clock 125-MHz.
+ - 'recovered': Recovered clock is a 125-MHz recovered clock from a
+ connected link partner.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - mac-if
+ - xi
+ - int-ref
+ - rmii-master-mode-ref
+ - free-running
+ - recovered
+
+ mac-termination-ohms:
+ enum: [43, 44, 46, 48, 50, 53, 55, 58, 61, 65, 69, 73, 78, 84, 91, 99]
+
required:
- reg
@@ -76,6 +139,8 @@ examples:
reg = <0>;
rx-internal-delay-ps = <1>;
tx-internal-delay-ps = <1>;
+ ti,gpio2-clk-out = "xi";
+ mac-termination-ohms = <43>;
};
};
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
index b8c0e4b5b494..4bc1f98fd9fe 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -2,13 +2,13 @@
# Copyright (C) 2019 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/ti,dp83867.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/ti,dp83867.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI DP83867 ethernet PHY
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: ethernet-controller.yaml#
maintainers:
- Andrew Davis <afd@ti.com>
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
index b04ff0014a59..fb6725df4668 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -2,13 +2,13 @@
# Copyright (C) 2019 Texas Instruments Incorporated
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/ti,dp83869.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/ti,dp83869.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI DP83869 ethernet PHY
allOf:
- - $ref: "ethernet-phy.yaml#"
+ - $ref: ethernet-phy.yaml#
maintainers:
- Andrew Davis <afd@ti.com>
diff --git a/Documentation/devicetree/bindings/net/ti,icss-iep.yaml b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml
new file mode 100644
index 000000000000..ea2659d90a52
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,icss-iep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ICSS Industrial Ethernet Peripheral (IEP) module
+
+maintainers:
+ - Md Danish Anwar <danishanwar@ti.com>
+ - Parvathi Pudi <parvathi@couthit.com>
+ - Basharath Hussain Khaja <basharath@couthit.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - ti,am642-icss-iep
+ - ti,j721e-icss-iep
+ - const: ti,am654-icss-iep
+ - enum:
+ - ti,am654-icss-iep
+ - ti,am5728-icss-iep
+ - ti,am4376-icss-iep
+ - ti,am3356-icss-iep
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: phandle to the IEP source clock
+
+ interrupts:
+ maxItems: 1
+ description:
+ Interrupt specifier for capture/compare IRQ.
+
+ interrupt-names:
+ items:
+ - const: iep_cap_cmp
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ /* AM65x */
+ icssg0_iep0: iep@2e000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2e000 0x1000>;
+ clocks = <&icssg0_iepclk_mux>;
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
new file mode 100644
index 000000000000..c296e5711848
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
@@ -0,0 +1,233 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ICSSG PRUSS Ethernet
+
+maintainers:
+ - Md Danish Anwar <danishanwar@ti.com>
+
+description:
+ Ethernet based on the Programmable Real-Time Unit and Industrial
+ Communication Subsystem.
+
+properties:
+ compatible:
+ enum:
+ - ti,am642-icssg-prueth # for AM64x SoC family
+ - ti,am654-icssg-prueth # for AM65x SoC family
+ - ti,am654-sr1-icssg-prueth # for AM65x SoC family, SR1.0
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to MSMC SRAM node
+
+ dmas:
+ minItems: 10
+ maxItems: 12
+
+ dma-names:
+ minItems: 10
+ items:
+ - const: tx0-0
+ - const: tx0-1
+ - const: tx0-2
+ - const: tx0-3
+ - const: tx1-0
+ - const: tx1-1
+ - const: tx1-2
+ - const: tx1-3
+ - const: rx0
+ - const: rx1
+ - const: rxmgm0
+ - const: rxmgm1
+
+ ti,mii-g-rt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to MII_G_RT module's syscon regmap.
+
+ ti,mii-rt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to MII_RT module's syscon regmap
+
+ ti,pa-stats:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to PA_STATS module's syscon regmap. PA_STATS is a set of
+ registers where different statistics related to ICSSG, are dumped by
+ ICSSG firmware. PA_STATS module's syscon regmap will help the device to
+ access/read/write those statistics.
+
+ ti,iep:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 2
+ items:
+ maxItems: 1
+ description:
+ phandle to IEP (Industrial Ethernet Peripheral) for ICSSG
+
+ interrupts:
+ maxItems: 2
+ description:
+ Interrupt specifiers to TX timestamp IRQ.
+
+ interrupt-names:
+ items:
+ - const: tx_ts0
+ - const: tx_ts1
+
+ ethernet-ports:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ ^port@[0-1]$:
+ type: object
+ description: ICSSG PRUETH external ports
+ $ref: ethernet-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ items:
+ - enum: [0, 1]
+ description: ICSSG PRUETH port number
+
+ interrupts:
+ maxItems: 1
+
+ ti,syscon-rgmii-delay:
+ items:
+ - items:
+ - description: phandle to system controller node
+ - description: The offset to ICSSG control register
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ phandle to system controller node and register offset
+ to ICSSG control register for RGMII transmit delay
+
+ ti,half-duplex-capable:
+ type: boolean
+ description:
+ Indicates that the PHY output pin COL is routed to ICSSG GPIO pin
+ (PRGx_PRU0/1_GPIO10) as input so that the ICSSG MII port is
+ capable of half duplex operations.
+
+ required:
+ - reg
+ anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+
+required:
+ - compatible
+ - sram
+ - dmas
+ - dma-names
+ - ethernet-ports
+ - ti,mii-g-rt
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: /schemas/remoteproc/ti,pru-consumer.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,am654-sr1-icssg-prueth
+ then:
+ properties:
+ dmas:
+ minItems: 12
+ dma-names:
+ minItems: 12
+ else:
+ properties:
+ dmas:
+ maxItems: 10
+ dma-names:
+ maxItems: 10
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* Example k3-am654 base board SR2.0, dual-emac */
+ pruss2_eth: ethernet {
+ compatible = "ti,am654-icssg-prueth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&icssg2_rgmii_pins_default>;
+ sram = <&msmc_ram>;
+
+ ti,prus = <&pru2_0>, <&rtu2_0>, <&tx_pru2_0>,
+ <&pru2_1>, <&rtu2_1>, <&tx_pru2_1>;
+ firmware-name = "ti-pruss/am65x-pru0-prueth-fw.elf",
+ "ti-pruss/am65x-rtu0-prueth-fw.elf",
+ "ti-pruss/am65x-txpru0-prueth-fw.elf",
+ "ti-pruss/am65x-pru1-prueth-fw.elf",
+ "ti-pruss/am65x-rtu1-prueth-fw.elf",
+ "ti-pruss/am65x-txpru1-prueth-fw.elf";
+ ti,pruss-gp-mux-sel = <2>, /* MII mode */
+ <2>,
+ <2>,
+ <2>, /* MII mode */
+ <2>,
+ <2>;
+ dmas = <&main_udmap 0xc300>, /* egress slice 0 */
+ <&main_udmap 0xc301>, /* egress slice 0 */
+ <&main_udmap 0xc302>, /* egress slice 0 */
+ <&main_udmap 0xc303>, /* egress slice 0 */
+ <&main_udmap 0xc304>, /* egress slice 1 */
+ <&main_udmap 0xc305>, /* egress slice 1 */
+ <&main_udmap 0xc306>, /* egress slice 1 */
+ <&main_udmap 0xc307>, /* egress slice 1 */
+ <&main_udmap 0x4300>, /* ingress slice 0 */
+ <&main_udmap 0x4301>; /* ingress slice 1 */
+ dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+ "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+ "rx0", "rx1";
+ ti,mii-g-rt = <&icssg2_mii_g_rt>;
+ ti,pa-stats = <&icssg2_pa_stats>;
+ ti,iep = <&icssg2_iep0>, <&icssg2_iep1>;
+ interrupt-parent = <&icssg2_intc>;
+ interrupts = <24 0 2>, <25 1 3>;
+ interrupt-names = "tx_ts0", "tx_ts1";
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss2_emac0: port@0 {
+ reg = <0>;
+ phy-handle = <&pruss2_eth0_phy>;
+ phy-mode = "rgmii-id";
+ interrupts-extended = <&icssg2_intc 24>;
+ ti,syscon-rgmii-delay = <&scm_conf 0x4120>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss2_emac1: port@1 {
+ reg = <1>;
+ phy-handle = <&pruss2_eth1_phy>;
+ phy-mode = "rgmii-id";
+ interrupts-extended = <&icssg2_intc 25>;
+ ti,syscon-rgmii-delay = <&scm_conf 0x4124>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,icssm-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssm-prueth.yaml
new file mode 100644
index 000000000000..a98ad45ca66f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,icssm-prueth.yaml
@@ -0,0 +1,233 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,icssm-prueth.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments ICSSM PRUSS Ethernet
+
+maintainers:
+ - Roger Quadros <rogerq@ti.com>
+ - Andrew F. Davis <afd@ti.com>
+ - Parvathi Pudi <parvathi@couthit.com>
+ - Basharath Hussain Khaja <basharath@couthit.com>
+
+description:
+ Ethernet based on the Programmable Real-Time Unit and Industrial
+ Communication Subsystem.
+
+properties:
+ compatible:
+ enum:
+ - ti,am57-prueth # for AM57x SoC family
+ - ti,am4376-prueth # for AM43x SoC family
+ - ti,am3359-prueth # for AM33x SoC family
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to OCMC SRAM node
+
+ ti,mii-rt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the MII_RT peripheral for ICSS
+
+ ti,iep:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to IEP (Industrial Ethernet Peripheral) for ICSS
+
+ ti,ecap:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to Enhanced Capture (eCAP) event for ICSS
+
+ interrupts:
+ items:
+ - description: High priority Rx Interrupt specifier.
+ - description: Low priority Rx Interrupt specifier.
+
+ interrupt-names:
+ items:
+ - const: rx_hp
+ - const: rx_lp
+
+ ethernet-ports:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ ^ethernet-port@[0-1]$:
+ type: object
+ description: ICSSM PRUETH external ports
+ $ref: ethernet-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ items:
+ - enum: [0, 1]
+ description: ICSSM PRUETH port number
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: rx
+ - const: emac_ptp_tx
+ - const: hsr_ptp_tx
+
+ required:
+ - reg
+
+ anyOf:
+ - required:
+ - ethernet-port@0
+ - required:
+ - ethernet-port@1
+
+required:
+ - compatible
+ - sram
+ - ti,mii-rt
+ - ti,iep
+ - ti,ecap
+ - ethernet-ports
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: /schemas/remoteproc/ti,pru-consumer.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* Dual-MAC Ethernet application node on PRU-ICSS2 */
+ pruss2_eth: pruss2-eth {
+ compatible = "ti,am57-prueth";
+ ti,prus = <&pru2_0>, <&pru2_1>;
+ sram = <&ocmcram1>;
+ ti,mii-rt = <&pruss2_mii_rt>;
+ ti,iep = <&pruss2_iep>;
+ ti,ecap = <&pruss2_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss2_intc>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss2_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss2_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx", "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss2_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss2_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
+ interrupt-names = "rx", "emac_ptp_tx", "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+ - |
+ /* Dual-MAC Ethernet application node on PRU-ICSS1 */
+ pruss1_eth: pruss1-eth {
+ compatible = "ti,am4376-prueth";
+ ti,prus = <&pru1_0>, <&pru1_1>;
+ sram = <&ocmcram>;
+ ti,mii-rt = <&pruss1_mii_rt>;
+ ti,iep = <&pruss1_iep>;
+ ti,ecap = <&pruss1_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss1_intc>;
+
+ pinctrl-0 = <&pruss1_eth_default>;
+ pinctrl-names = "default";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss1_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss1_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss1_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss1_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+ - |
+ /* Dual-MAC Ethernet application node on PRU-ICSS */
+ pruss_eth: pruss-eth {
+ compatible = "ti,am3359-prueth";
+ ti,prus = <&pru0>, <&pru1>;
+ sram = <&ocmcram>;
+ ti,mii-rt = <&pruss_mii_rt>;
+ ti,iep = <&pruss_iep>;
+ ti,ecap = <&pruss_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss_intc>;
+
+ pinctrl-0 = <&pruss_eth_default>;
+ pinctrl-names = "default";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index 7d90beaccc60..a959c1d7e643 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/net/ti,k3-am654-cpsw-nuss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: The TI AM654x/J721E/AM642x SoC Gigabit Ethernet MAC (Media Access Controller) Device Tree Bindings
+title: The TI AM654x/J721E/AM642x SoC Gigabit Ethernet MAC (Media Access Controller)
maintainers:
- - Grygorii Strashko <grygorii.strashko@ti.com>
- - Sekhar Nori <nsekhar@ti.com>
+ - Siddharth Vadapalli <s-vadapalli@ti.com>
+ - Roger Quadros <rogerq@kernel.org>
description:
The TI AM654x/J721E SoC Gigabit Ethernet MAC (CPSW2G NUSS) has two ports
@@ -54,10 +54,12 @@ properties:
compatible:
enum:
+ - ti,am642-cpsw-nuss
- ti,am654-cpsw-nuss
- ti,j7200-cpswxg-nuss
- ti,j721e-cpsw-nuss
- - ti,am642-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
reg:
maxItems: 1
@@ -111,7 +113,7 @@ properties:
const: 0
patternProperties:
- "^port@[1-4]$":
+ "^port@[1-8]$":
type: object
description: CPSWxG NUSS external ports
@@ -121,16 +123,28 @@ properties:
properties:
reg:
minimum: 1
- maximum: 4
+ maximum: 8
description: CPSW port number
phys:
- maxItems: 1
- description: phandle on phy-gmii-sel PHY
+ minItems: 1
+ items:
+ - description: CPSW MAC's PHY.
+ - description: Serdes PHY. Serdes PHY is required only if
+ the Serdes has to be configured in the
+ Single-Link configuration.
+
+ phy-names:
+ minItems: 1
+ items:
+ - const: mac
+ - const: serdes
label:
description: label associated with this port
+ fixed-link: true
+
ti,mac-only:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -156,14 +170,14 @@ properties:
patternProperties:
"^mdio@[0-9a-f]+$":
type: object
- $ref: "ti,davinci-mdio.yaml#"
+ $ref: ti,davinci-mdio.yaml#
description:
CPSW MDIO bus.
"^cpts@[0-9a-f]+":
type: object
- $ref: "ti,k3-am654-cpts.yaml#"
+ $ref: ti,k3-am654-cpts.yaml#
description:
CPSW Common Platform Time Sync (CPTS) module.
@@ -186,18 +200,44 @@ allOf:
properties:
compatible:
contains:
- const: ti,j7200-cpswxg-nuss
+ enum:
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ then:
+ properties:
+ ethernet-ports:
+ patternProperties:
+ "^port@[5-8]$": false
+ "^port@[1-4]$":
+ properties:
+ reg:
+ minimum: 1
+ maximum: 4
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
then:
properties:
ethernet-ports:
patternProperties:
- "^port@[3-4]$": false
+ "^port@[3-8]$": false
+ "^port@[1-2]$":
+ properties:
+ reg:
+ minimum: 1
+ maximum: 2
additionalProperties: false
examples:
- |
- #include <dt-bindings/pinctrl/k3.h>
#include <dt-bindings/soc/ti,sci_pm_domain.h>
#include <dt-bindings/net/ti-dp83867.h>
#include <dt-bindings/interrupt-controller/irq.h>
@@ -244,7 +284,7 @@ examples:
ti,syscon-efuse = <&mcu_conf 0x200>;
phys = <&phy_gmii_sel 1>;
- phy-mode = "rgmii-rxid";
+ phy-mode = "rgmii-id";
phy-handle = <&phy0>;
};
};
@@ -264,16 +304,16 @@ examples:
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
};
};
- };
- cpts@3d000 {
- compatible = "ti,am65-cpts";
- reg = <0x0 0x3d000 0x0 0x400>;
- clocks = <&k3_clks 18 2>;
- clock-names = "cpts";
- interrupts-extended = <&gic500 GIC_SPI 858 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "cpts";
- ti,cpts-ext-ts-inputs = <4>;
- ti,cpts-periodic-outputs = <2>;
+ cpts@3d000 {
+ compatible = "ti,am65-cpts";
+ reg = <0x0 0x3d000 0x0 0x400>;
+ clocks = <&k3_clks 18 2>;
+ clock-names = "cpts";
+ interrupts-extended = <&gic500 GIC_SPI 858 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "cpts";
+ ti,cpts-ext-ts-inputs = <4>;
+ ti,cpts-periodic-outputs = <2>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
index e9f78cef6b7f..3572749147fb 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/net/ti,k3-am654-cpts.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: The TI AM654x/J721E Common Platform Time Sync (CPTS) module Device Tree Bindings
+title: The TI AM654x/J721E Common Platform Time Sync (CPTS) module
maintainers:
- - Grygorii Strashko <grygorii.strashko@ti.com>
- - Sekhar Nori <nsekhar@ti.com>
+ - Siddharth Vadapalli <s-vadapalli@ti.com>
+ - Roger Quadros <rogerq@kernel.org>
description: |+
The TI AM654x/J721E CPTS module is used to facilitate host control of time
@@ -93,6 +93,14 @@ properties:
description:
Number of timestamp Generator function outputs (TS_GENFx)
+ ti,pps:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+ description: |
+ The pair of HWx_TS_PUSH input and TS_GENFy output indexes used for
+ PPS events generation. Platform/board specific.
+
refclk-mux:
type: object
additionalProperties: false
@@ -123,23 +131,23 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
cpts@310d0000 {
- compatible = "ti,am65-cpts";
- reg = <0x310d0000 0x400>;
- reg-names = "cpts";
- clocks = <&main_cpts_mux>;
- clock-names = "cpts";
- interrupts-extended = <&k3_irq 163 0 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "cpts";
- ti,cpts-periodic-outputs = <6>;
- ti,cpts-ext-ts-inputs = <8>;
-
- main_cpts_mux: refclk-mux {
- #clock-cells = <0>;
- clocks = <&k3_clks 118 5>, <&k3_clks 118 11>,
- <&k3_clks 157 91>, <&k3_clks 157 77>,
- <&k3_clks 157 102>, <&k3_clks 157 80>,
- <&k3_clks 120 3>, <&k3_clks 121 3>;
- assigned-clocks = <&main_cpts_mux>;
- assigned-clock-parents = <&k3_clks 118 11>;
- };
+ compatible = "ti,am65-cpts";
+ reg = <0x310d0000 0x400>;
+ reg-names = "cpts";
+ clocks = <&main_cpts_mux>;
+ clock-names = "cpts";
+ interrupts-extended = <&k3_irq 163 0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "cpts";
+ ti,cpts-periodic-outputs = <6>;
+ ti,cpts-ext-ts-inputs = <8>;
+
+ main_cpts_mux: refclk-mux {
+ #clock-cells = <0>;
+ clocks = <&k3_clks 118 5>, <&k3_clks 118 11>,
+ <&k3_clks 157 91>, <&k3_clks 157 77>,
+ <&k3_clks 157 102>, <&k3_clks 157 80>,
+ <&k3_clks 120 3>, <&k3_clks 121 3>;
+ assigned-clocks = <&main_cpts_mux>;
+ assigned-clock-parents = <&k3_clks 118 11>;
+ };
};
diff --git a/Documentation/devicetree/bindings/net/ti,pruss-ecap.yaml b/Documentation/devicetree/bindings/net/ti,pruss-ecap.yaml
new file mode 100644
index 000000000000..42f217099b2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,pruss-ecap.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,pruss-ecap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PRU-ICSS Enhanced Capture (eCAP) event module
+
+maintainers:
+ - Murali Karicheri <m-karicheri2@ti.com>
+ - Parvathi Pudi <parvathi@couthit.com>
+ - Basharath Hussain Khaja <basharath@couthit.com>
+
+properties:
+ compatible:
+ const: ti,pruss-ecap
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pruss2_ecap: ecap@30000 {
+ compatible = "ti,pruss-ecap";
+ reg = <0x30000 0x60>;
+ };
diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
index 0988ed8d1c12..f0f32e18fc85 100644
--- a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba Visconti DWMAC Ethernet controller
@@ -19,7 +19,7 @@ select:
- compatible
allOf:
- - $ref: "snps,dwmac.yaml#"
+ - $ref: snps,dwmac.yaml#
properties:
compatible:
@@ -42,6 +42,12 @@ properties:
- const: stmmaceth
- const: phy_ref_clk
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml b/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml
index 304757bf9281..8359de7ad272 100644
--- a/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml
+++ b/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/net/vertexcom-mse102x.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/net/vertexcom-mse102x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: The Vertexcom MSE102x (SPI) Device Tree Bindings
+title: The Vertexcom MSE102x (SPI)
maintainers:
- Stefan Wahren <stefan.wahren@chargebyte.com>
@@ -55,7 +55,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -63,7 +63,7 @@ examples:
compatible = "vertexcom,mse1021";
reg = <0>;
interrupt-parent = <&gpio>;
- interrupts = <23 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
spi-cpha;
spi-cpol;
spi-max-frequency = <7142857>;
diff --git a/Documentation/devicetree/bindings/net/via,vt8500-rhine.yaml b/Documentation/devicetree/bindings/net/via,vt8500-rhine.yaml
new file mode 100644
index 000000000000..e663d5a2f014
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via,vt8500-rhine.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/via,vt8500-rhine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA Rhine 10/100 Network Controller
+
+description:
+ VIA's Ethernet controller integrated into VIA VT8500,
+ WonderMedia WM8950 and related SoCs
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+allOf:
+ - $ref: ethernet-controller.yaml#
+
+properties:
+ compatible:
+ const: via,vt8500-rhine
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ethernet@d8004000 {
+ compatible = "via,vt8500-rhine";
+ reg = <0xd8004000 0x100>;
+ interrupts = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt
deleted file mode 100644
index 334eca2bf937..000000000000
--- a/Documentation/devicetree/bindings/net/via-rhine.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* VIA Rhine 10/100 Network Controller
-
-Required properties:
-- compatible : Should be "via,vt8500-rhine" for integrated
- Rhine controllers found in VIA VT8500, WonderMedia WM8950
- and similar. These are listed as 1106:3106 rev. 0x84 on the
- virtual PCI bus under vendor-provided kernels
-- reg : Address and length of the io space
-- interrupts : Should contain the controller interrupt line
-
-Examples:
-
-ethernet@d8004000 {
- compatible = "via,vt8500-rhine";
- reg = <0xd8004000 0x100>;
- interrupts = <10>;
-};
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
index fec1cc9b9a08..3be757678764 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
@@ -15,6 +15,9 @@ description:
These chips also have a Bluetooth portion described in a separate
binding.
+allOf:
+ - $ref: /schemas/net/wireless/wireless-controller.yaml#
+
properties:
compatible:
oneOf:
@@ -38,8 +41,10 @@ properties:
- brcm,bcm4354-fmac
- brcm,bcm4356-fmac
- brcm,bcm4359-fmac
+ - brcm,bcm4366-fmac
- cypress,cyw4373-fmac
- cypress,cyw43012-fmac
+ - infineon,cyw43439-fmac
- const: brcm,bcm4329-fmac
- enum:
- brcm,bcm4329-fmac
@@ -48,6 +53,8 @@ properties:
- pci14e4,4488 # BCM4377
- pci14e4,4425 # BCM4378
- pci14e4,4433 # BCM4387
+ - pci14e4,4434 # BCM4388
+ - pci14e4,449d # BCM43752
reg:
description: SDIO function number for the device (for most cases
@@ -116,11 +123,19 @@ properties:
NVRAM. This would normally be filled in by the bootloader from platform
configuration data.
+ clocks:
+ items:
+ - description: External Low Power Clock input (32.768KHz)
+
+ clock-names:
+ items:
+ - const: lpo
+
required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
index 284ef45add99..0ea84d6fe73e 100644
--- a/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/wireless/esp,esp8089.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Espressif ESP8089 Device Tree Bindings
+title: Espressif ESP8089
maintainers:
- Hans de Goede <hdegoede@redhat.com>
@@ -29,15 +29,15 @@ additionalProperties: false
examples:
- |
- mmc {
- #address-cells = <1>;
- #size-cells = <0>;
-
- wifi@1 {
- compatible = "esp,esp8089";
- reg = <1>;
- esp,crystal-26M-en = <2>;
- };
- };
+ mmc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wifi@1 {
+ compatible = "esp,esp8089";
+ reg = <1>;
+ esp,crystal-26M-en = <2>;
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
index d58e1571df9b..d89f7a3f88a7 100644
--- a/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.yaml
@@ -1,12 +1,11 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/ieee80211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common IEEE 802.11 Binding
+title: Common IEEE 802.11
maintainers:
- Lorenzo Bianconi <lorenzo@kernel.org>
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
new file mode 100644
index 000000000000..930b700b73d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/marvell,sd8787.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/marvell,sd8787.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell 8787/8897/8978/8997 (sd8787/sd8897/sd8978/sd8997/pcie8997) SDIO/PCIE devices
+
+maintainers:
+ - Brian Norris <briannorris@chromium.org>
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ This node provides properties for describing the Marvell SDIO/PCIE wireless device.
+ The node is expected to be specified as a child node to the SDIO/PCIE controller that
+ connects the device to the system.
+
+properties:
+ compatible:
+ enum:
+ - marvell,sd8787
+ - marvell,sd8897
+ - marvell,sd8978
+ - marvell,sd8997
+ - nxp,iw416
+ - pci11ab,2b42
+ - pci1b4b,2b42
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ marvell,caldata-txpwrlimit-2g:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: Calibration data for the 2GHz band.
+ maxItems: 566
+
+ marvell,caldata-txpwrlimit-5g-sub0:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: Calibration data for sub-band 0 in the 5GHz band.
+ maxItems: 502
+
+ marvell,caldata-txpwrlimit-5g-sub1:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: Calibration data for sub-band 1 in the 5GHz band.
+ maxItems: 688
+
+ marvell,caldata-txpwrlimit-5g-sub2:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: Calibration data for sub-band 2 in the 5GHz band.
+ maxItems: 750
+
+ marvell,caldata-txpwrlimit-5g-sub3:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: Calibration data for sub-band 3 in the 5GHz band.
+ maxItems: 502
+
+ marvell,wakeup-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Provides the pin number for the wakeup pin from the device's point of
+ view. The wakeup pin is used for the device to wake the host system
+ from sleep. This property is only necessary if the wakeup pin is
+ wired in a non-standard way, such that the default pin assignments
+ are invalid.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mmc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wifi@1 {
+ compatible = "marvell,sd8897";
+ reg = <1>;
+ interrupt-parent = <&pio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
deleted file mode 100644
index 9bf9bbac16e2..000000000000
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
-------
-
-This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
-The node is expected to be specified as a child node to the SDIO/PCIE controller that
-connects the device to the system.
-
-Required properties:
-
- - compatible : should be one of the following:
- * "marvell,sd8787"
- * "marvell,sd8897"
- * "marvell,sd8997"
- * "pci11ab,2b42"
- * "pci1b4b,2b42"
-
-Optional properties:
-
- - marvell,caldata* : A series of properties with marvell,caldata prefix,
- represent calibration data downloaded to the device during
- initialization. This is an array of unsigned 8-bit values.
- the properties should follow below property name and
- corresponding array length:
- "marvell,caldata-txpwrlimit-2g" (length = 566).
- "marvell,caldata-txpwrlimit-5g-sub0" (length = 502).
- "marvell,caldata-txpwrlimit-5g-sub1" (length = 688).
- "marvell,caldata-txpwrlimit-5g-sub2" (length = 750).
- "marvell,caldata-txpwrlimit-5g-sub3" (length = 502).
- - marvell,wakeup-pin : a wakeup pin number of wifi chip which will be configured
- to firmware. Firmware will wakeup the host using this pin
- during suspend/resume.
- - interrupts : interrupt pin number to the cpu. driver will request an irq based on
- this interrupt number. during system suspend, the irq will be enabled
- so that the wifi chip can wakeup host platform under certain condition.
- during system resume, the irq will be disabled to make sure
- unnecessary interrupt is not received.
- - vmmc-supply: a phandle of a regulator, supplying VCC to the card
- - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
- for documentation of MMC power sequence bindings.
-
-Example:
-
-Tx power limit calibration data is configured in below example.
-The calibration data is an array of unsigned values, the length
-can vary between hw versions.
-IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is configured
-so that firmware can wakeup host using this device side pin.
-
-&mmc3 {
- vmmc-supply = <&wlan_en_reg>;
- mmc-pwrseq = <&wifi_pwrseq>;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
-
- #address-cells = <1>;
- #size-cells = <0>;
- mwifiex: wifi@1 {
- compatible = "marvell,sd8897";
- reg = <1>;
- interrupt-parent = <&pio>;
- interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
-
- marvell,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
- 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01>;
- marvell,wakeup-pin = <3>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
index 70e328589cfb..ae6b97cdc44b 100644
--- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml
@@ -1,12 +1,11 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/mediatek,mt76.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek mt76 wireless devices Generic Binding
+title: MediaTek mt76 wireless devices
maintainers:
- Felix Fietkau <nbd@nbd.name>
@@ -20,15 +19,13 @@ description: |
Alternatively, it can specify the wireless part of the MT7628/MT7688
or MT7622/MT7986 SoC.
-allOf:
- - $ref: ieee80211.yaml#
-
properties:
compatible:
enum:
- mediatek,mt76
- mediatek,mt7628-wmac
- mediatek,mt7622-wmac
+ - mediatek,mt7981-wmac
- mediatek,mt7986-wmac
reg:
@@ -38,7 +35,12 @@ properties:
MT7986 should contain 3 regions consys, dcm, and sku, in this order.
interrupts:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: major interrupt for rings
+ - description: additional interrupt for ring 19
+ - description: additional interrupt for ring 4
+ - description: additional interrupt for ring 5
power-domains:
maxItems: 1
@@ -72,6 +74,14 @@ properties:
ieee80211-freq-limit: true
+ nvmem-cells:
+ items:
+ - description: NVMEM cell with EEPROM
+
+ nvmem-cell-names:
+ items:
+ - const: eeprom
+
mediatek,eeprom-data:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
@@ -85,6 +95,7 @@ properties:
- description: offset containing EEPROM data
description:
Phandle to a MTD partition + offset containing EEPROM data
+ deprecated: true
big-endian:
$ref: /schemas/types.yaml#/definitions/flag
@@ -112,6 +123,11 @@ properties:
$ref: /schemas/leds/common.yaml#
additionalProperties: false
properties:
+ led-active-low:
+ description:
+ LED is enabled with ground signal.
+ type: boolean
+
led-sources:
maxItems: 1
@@ -135,6 +151,12 @@ properties:
- ETSI
- JP
+ country:
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: '^[A-Z]{2}$'
+ description:
+ ISO 3166-1 alpha-2 country code for power limits
+
patternProperties:
"^txpower-[256]g$":
type: object
@@ -194,6 +216,66 @@ properties:
minItems: 13
maxItems: 13
+ paths-cck:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 4
+ maxItems: 4
+ description:
+ 4 half-dBm backoff values (1 - 4 antennas, single spacial
+ stream)
+
+ paths-ofdm:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 4
+ maxItems: 4
+ description:
+ 4 half-dBm backoff values (1 - 4 antennas, single spacial
+ stream)
+
+ paths-ofdm-bf:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 4
+ maxItems: 4
+ description:
+ 4 half-dBm backoff values for beamforming
+ (1 - 4 antennas, single spacial stream)
+
+ paths-ru:
+ $ref: /schemas/types.yaml#/definitions/uint8-matrix
+ description:
+ Sets of half-dBm backoff values for 802.11ax rates for
+ 1T1ss (aka 1 transmitting antenna with 1 spacial stream),
+ 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss
+ and 4T4ss.
+ Each set starts with the number of channel bandwidth or
+ resource unit settings for which the rate set applies,
+ followed by 10 power limit values. The order of the
+ channel resource unit settings is RU26, RU52, RU106,
+ RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
+ minItems: 1
+ maxItems: 7
+ items:
+ minItems: 11
+ maxItems: 11
+
+ paths-ru-bf:
+ $ref: /schemas/types.yaml#/definitions/uint8-matrix
+ description:
+ Sets of half-dBm backoff (beamforming) values for 802.11ax
+ rates for 1T1ss (aka 1 transmitting antenna with 1 spacial
+ stream), 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss,
+ 4T3ss and 4T4ss.
+ Each set starts with the number of channel bandwidth or
+ resource unit settings for which the rate set applies,
+ followed by 10 power limit values. The order of the
+ channel resource unit settings is RU26, RU52, RU106,
+ RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
+ minItems: 1
+ maxItems: 7
+ items:
+ minItems: 11
+ maxItems: 11
+
txs-delta:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
@@ -203,6 +285,24 @@ required:
- compatible
- reg
+allOf:
+ - $ref: ieee80211.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7981-wmac
+ - mediatek,mt7986-wmac
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
unevaluatedProperties: false
examples:
@@ -254,7 +354,8 @@ examples:
interrupt-parent = <&cpuintc>;
interrupts = <6>;
- mediatek,mtd-eeprom = <&factory 0x0>;
+ nvmem-cells = <&eeprom>;
+ nvmem-cell-names = "eeprom";
};
- |
@@ -278,7 +379,10 @@ examples:
reg = <0x18000000 0x1000000>,
<0x10003000 0x1000>,
<0x11d10000 0x1000>;
- interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&topckgen 50>,
<&topckgen 62>;
clock-names = "mcu", "ap2conn";
diff --git a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml
index b3405f284580..5d40f22765bb 100644
--- a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/wireless/microchip,wilc1000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip WILC wireless devicetree bindings
+title: Microchip WILC wireless
maintainers:
- Adham Abozaeid <adham.abozaeid@microchip.com>
@@ -16,7 +16,11 @@ description:
properties:
compatible:
- const: microchip,wilc1000
+ oneOf:
+ - items:
+ - const: microchip,wilc3000
+ - const: microchip,wilc1000
+ - const: microchip,wilc1000
reg: true
diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml
index 7029cb1f38ff..d16ca8e0a25d 100644
--- a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/net/wireless/qca,ath9k.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Atheros ath9k wireless devices Generic Binding
+title: Qualcomm Atheros ath9k wireless devices
maintainers:
- Toke Høiland-Jørgensen <toke@toke.dk>
@@ -12,7 +12,7 @@ maintainers:
description: |
This node provides properties for configuring the ath9k wireless device.
The node is expected to be specified as a child node of the PCI controller
- to which the wireless chip is connected.
+ or AHB bus to which the wireless chip is connected.
allOf:
- $ref: ieee80211.yaml#
@@ -35,6 +35,12 @@ properties:
- pci168c,0034 # AR9462
- pci168c,0036 # AR9565
- pci168c,0037 # AR1111 and AR9485
+ - qca,ar9130-wifi
+ - qca,ar9330-wifi
+ - qca,ar9340-wifi
+ - qca,qca9530-wifi
+ - qca,qca9550-wifi
+ - qca,qca9560-wifi
reg:
maxItems: 1
@@ -88,3 +94,13 @@ examples:
nvmem-cell-names = "mac-address", "calibration";
};
};
+ - |
+ ahb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ wifi@180c0000 {
+ compatible = "qca,ar9130-wifi";
+ reg = <0x180c0000 0x230000>;
+ interrupts = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
deleted file mode 100644
index b61c2d5a0ff7..000000000000
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ /dev/null
@@ -1,215 +0,0 @@
-* Qualcomm Atheros ath10k wireless devices
-
-Required properties:
-- compatible: Should be one of the following:
- * "qcom,ath10k"
- * "qcom,ipq4019-wifi"
- * "qcom,wcn3990-wifi"
-
-PCI based devices uses compatible string "qcom,ath10k" and takes calibration
-data along with board specific data via "qcom,ath10k-calibration-data".
-Rest of the properties are not applicable for PCI based devices.
-
-AHB based devices (i.e. ipq4019) uses compatible string "qcom,ipq4019-wifi"
-and also uses most of the properties defined in this doc (except
-"qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data"
-to carry pre calibration data.
-
-In general, entry "qcom,ath10k-pre-calibration-data" and
-"qcom,ath10k-calibration-data" conflict with each other and only one
-can be provided per device.
-
-SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
-
-- reg: Address and length of the register set for the device.
-- reg-names: Must include the list of following reg names,
- "membase"
-- interrupts: reference to the list of 17 interrupt numbers for "qcom,ipq4019-wifi"
- compatible target.
- reference to the list of 12 interrupt numbers for "qcom,wcn3990-wifi"
- compatible target.
- Must contain interrupt-names property per entry for
- "qcom,ath10k", "qcom,ipq4019-wifi" compatible targets.
-
-- interrupt-names: Must include the entries for MSI interrupt
- names ("msi0" to "msi15") and legacy interrupt
- name ("legacy") for "qcom,ath10k", "qcom,ipq4019-wifi"
- compatible targets.
-
-Optional properties:
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reseti.txt for details.
-- reset-names: Must include the list of following reset names,
- "wifi_cpu_init"
- "wifi_radio_srif"
- "wifi_radio_warm"
- "wifi_radio_cold"
- "wifi_core_warm"
- "wifi_core_cold"
-- clocks: List of clock specifiers, must contain an entry for each required
- entry in clock-names.
-- clock-names: Should contain the clock names "wifi_wcss_cmd", "wifi_wcss_ref",
- "wifi_wcss_rtc" for "qcom,ipq4019-wifi" compatible target and
- "cxo_ref_clk_pin" and optionally "qdss" for "qcom,wcn3990-wifi"
- compatible target.
-- qcom,msi_addr: MSI interrupt address.
-- qcom,msi_base: Base value to add before writing MSI data into
- MSI address register.
-- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
- variant list with the same bus and device
- specific ids
-- qcom,ath10k-calibration-data : calibration data + board specific data
- as an array, the length can vary between
- hw versions.
-- qcom,ath10k-pre-calibration-data : pre calibration data as an array,
- the length can vary between hw versions.
-- <supply-name>-supply: handle to the regulator device tree node
- optional "supply-name" are "vdd-0.8-cx-mx",
- "vdd-1.8-xo", "vdd-1.3-rfa", "vdd-3.3-ch0",
- and "vdd-3.3-ch1".
-- memory-region:
- Usage: optional
- Value type: <phandle>
- Definition: reference to the reserved-memory for the msa region
- used by the wifi firmware running in Q6.
-- iommus:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: A list of phandle and IOMMU specifier pairs.
-- ext-fem-name:
- Usage: Optional
- Value type: string
- Definition: Name of external front end module used. Some valid FEM names
- for example: "microsemi-lx5586", "sky85703-11"
- and "sky85803" etc.
-- qcom,snoc-host-cap-8bit-quirk:
- Usage: Optional
- Value type: <empty>
- Definition: Quirk specifying that the firmware expects the 8bit version
- of the host capability QMI request
-- qcom,xo-cal-data: xo cal offset to be configured in xo trim register.
-
-- qcom,msa-fixed-perm: Boolean context flag to disable SCM call for statically
- mapped msa region.
-
-- qcom,coexist-support : should contain eithr "0" or "1" to indicate coex
- support by the hardware.
-- qcom,coexist-gpio-pin : gpio pin number information to support coex
- which will be used by wifi firmware.
-
-* Subnodes
-The ath10k wifi node can contain one optional firmware subnode.
-Firmware subnode is needed when the platform does not have TustZone.
-The firmware subnode must have:
-
-- iommus:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A list of phandle and IOMMU specifier pairs.
-
-
-Example (to supply PCI based wifi block details):
-
-In this example, the node is defined as child node of the PCI controller.
-
-pci {
- pcie@0 {
- reg = <0 0 0 0 0>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
-
- wifi@0,0 {
- reg = <0 0 0 0 0>;
- qcom,ath10k-calibration-data = [ 01 02 03 ... ];
- ext-fem-name = "microsemi-lx5586";
- };
- };
-};
-
-Example (to supply ipq4019 SoC wifi block details):
-
-wifi0: wifi@a000000 {
- compatible = "qcom,ipq4019-wifi";
- reg = <0xa000000 0x200000>;
- resets = <&gcc WIFI0_CPU_INIT_RESET>,
- <&gcc WIFI0_RADIO_SRIF_RESET>,
- <&gcc WIFI0_RADIO_WARM_RESET>,
- <&gcc WIFI0_RADIO_COLD_RESET>,
- <&gcc WIFI0_CORE_WARM_RESET>,
- <&gcc WIFI0_CORE_COLD_RESET>;
- reset-names = "wifi_cpu_init",
- "wifi_radio_srif",
- "wifi_radio_warm",
- "wifi_radio_cold",
- "wifi_core_warm",
- "wifi_core_cold";
- clocks = <&gcc GCC_WCSS2G_CLK>,
- <&gcc GCC_WCSS2G_REF_CLK>,
- <&gcc GCC_WCSS2G_RTC_CLK>;
- clock-names = "wifi_wcss_cmd",
- "wifi_wcss_ref",
- "wifi_wcss_rtc";
- interrupts = <0 0x20 0x1>,
- <0 0x21 0x1>,
- <0 0x22 0x1>,
- <0 0x23 0x1>,
- <0 0x24 0x1>,
- <0 0x25 0x1>,
- <0 0x26 0x1>,
- <0 0x27 0x1>,
- <0 0x28 0x1>,
- <0 0x29 0x1>,
- <0 0x2a 0x1>,
- <0 0x2b 0x1>,
- <0 0x2c 0x1>,
- <0 0x2d 0x1>,
- <0 0x2e 0x1>,
- <0 0x2f 0x1>,
- <0 0xa8 0x0>;
- interrupt-names = "msi0", "msi1", "msi2", "msi3",
- "msi4", "msi5", "msi6", "msi7",
- "msi8", "msi9", "msi10", "msi11",
- "msi12", "msi13", "msi14", "msi15",
- "legacy";
- qcom,msi_addr = <0x0b006040>;
- qcom,msi_base = <0x40>;
- qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
- qcom,coexist-support = <1>;
- qcom,coexist-gpio-pin = <0x33>;
-};
-
-Example (to supply wcn3990 SoC wifi block details):
-
-wifi@18000000 {
- compatible = "qcom,wcn3990-wifi";
- reg = <0x18800000 0x800000>;
- reg-names = "membase";
- clocks = <&clock_gcc clk_rf_clk2_pin>;
- clock-names = "cxo_ref_clk_pin";
- interrupts =
- <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>;
- vdd-0.8-cx-mx-supply = <&pm8998_l5>;
- vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
- vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
- vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
- vdd-3.3-ch1-supply = <&vreg_l26a_3p3>;
- memory-region = <&wifi_msa_mem>;
- iommus = <&apps_smmu 0x0040 0x1>;
- qcom,msa-fixed-perm;
- wifi-firmware {
- iommus = <&apps_iommu 0xc22 0x1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
new file mode 100644
index 000000000000..f2440d39b7eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -0,0 +1,394 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/qcom,ath10k.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies ath10k wireless devices
+
+maintainers:
+ - Jeff Johnson <jjohnson@kernel.org>
+
+description:
+ Qualcomm Technologies, Inc. IEEE 802.11ac devices.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ath10k # SDIO-based devices
+ - qcom,ipq4019-wifi
+ - qcom,wcn3990-wifi # SNoC-based devices
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: membase
+
+ interrupts:
+ minItems: 12
+ maxItems: 17
+
+ interrupt-names:
+ minItems: 12
+ maxItems: 17
+
+ memory-region:
+ maxItems: 1
+ description:
+ Reference to the MSA memory region used by the Wi-Fi firmware
+ running on the Q6 core.
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ resets:
+ maxItems: 6
+
+ reset-names:
+ items:
+ - const: wifi_cpu_init
+ - const: wifi_radio_srif
+ - const: wifi_radio_warm
+ - const: wifi_radio_cold
+ - const: wifi_core_warm
+ - const: wifi_core_cold
+
+ ext-fem-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Name of external front end module used.
+ enum:
+ - microsemi-lx5586
+ - sky85703-11
+ - sky85803
+
+ firmware-name:
+ maxItems: 1
+ description:
+ If present, a board or platform specific string used to lookup firmware
+ files for the device.
+
+ wifi-firmware:
+ type: object
+ additionalProperties: false
+ description: |
+ The ath10k Wi-Fi node can contain one optional firmware subnode.
+ Firmware subnode is needed when the platform does not have Trustzone.
+ properties:
+ iommus:
+ maxItems: 1
+ required:
+ - iommus
+
+ ieee80211-freq-limit: true
+
+ qcom,calibration-data:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Calibration data + board-specific data as a byte array. The length
+ can vary between hardware versions.
+
+ qcom,ath10k-calibration-data:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ deprecated: true
+ description:
+ Calibration data + board-specific data as a byte array. The length
+ can vary between hardware versions.
+
+ qcom,calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Unique variant identifier of the calibration data in board-2.bin
+ for designs with colliding bus and device specific ids
+
+ qcom,ath10k-calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
+ description:
+ Unique variant identifier of the calibration data in board-2.bin
+ for designs with colliding bus and device specific ids
+
+ qcom,pre-calibration-data:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Pre-calibration data as a byte array. The length can vary between
+ hardware versions.
+
+ qcom,ath10k-pre-calibration-data:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ deprecated: true
+ description:
+ Pre-calibration data as a byte array. The length can vary between
+ hardware versions.
+
+ qcom,coexist-support:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ enum: [0, 1]
+ description:
+ Indicate coex support by the hardware.
+
+ qcom,coexist-gpio-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ COEX GPIO number provided to the Wi-Fi firmware.
+
+ qcom,msa-fixed-perm:
+ type: boolean
+ description:
+ Whether to skip executing an SCM call that reassigns the memory
+ region ownership.
+
+ qcom,no-msa-ready-indicator:
+ type: boolean
+ description:
+ Don't wait for MSA_READY indicator to complete init.
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: State bits used by the AP to signal the WLAN Q6.
+ items:
+ - description: Signal bits used to enable/disable low power mode
+ on WCN in the case of WoW (Wake on Wireless).
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output.
+ items:
+ - const: wlan-smp2p-out
+
+ qcom,snoc-host-cap-8bit-quirk:
+ type: boolean
+ description:
+ Quirk specifying that the firmware expects the 8bit version
+ of the host capability QMI request
+
+ qcom,xo-cal-data:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ XO cal offset to be configured in XO trim register.
+
+ vdd-0.8-cx-mx-supply:
+ description: Main logic power rail
+
+ vdd-1.8-xo-supply:
+ description: Crystal oscillator supply
+
+ vdd-1.3-rfa-supply:
+ description: RFA supply
+
+ vdd-3.3-ch0-supply:
+ description: Primary Wi-Fi antenna supply
+
+ vdd-3.3-ch1-supply:
+ description: Secondary Wi-Fi antenna supply
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+allOf:
+ - $ref: ieee80211.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq4019-wifi
+ then:
+ properties:
+ interrupts:
+ minItems: 17
+ maxItems: 17
+
+ interrupt-names:
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: msi8
+ - const: msi9
+ - const: msi10
+ - const: msi11
+ - const: msi12
+ - const: msi13
+ - const: msi14
+ - const: msi15
+ - const: legacy
+
+ clocks:
+ items:
+ - description: Wi-Fi command clock
+ - description: Wi-Fi reference clock
+ - description: Wi-Fi RTC clock
+
+ clock-names:
+ items:
+ - const: wifi_wcss_cmd
+ - const: wifi_wcss_ref
+ - const: wifi_wcss_rtc
+
+ required:
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,wcn3990-wifi
+
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ items:
+ - description: XO reference clock
+ - description: Qualcomm Debug Subsystem clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: cxo_ref_clk_pin
+ - const: qdss
+
+ interrupts:
+ items:
+ - description: CE0
+ - description: CE1
+ - description: CE2
+ - description: CE3
+ - description: CE4
+ - description: CE5
+ - description: CE6
+ - description: CE7
+ - description: CE8
+ - description: CE9
+ - description: CE10
+ - description: CE11
+
+ interrupt-names: false
+
+ required:
+ - interrupts
+
+examples:
+ # SNoC
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ wifi@18800000 {
+ compatible = "qcom,wcn3990-wifi";
+ reg = <0x18800000 0x800000>;
+ reg-names = "membase";
+ memory-region = <&wlan_msa_mem>;
+ clocks = <&rpmcc RPM_SMD_RF_CLK2_PIN>;
+ clock-names = "cxo_ref_clk_pin";
+ interrupts = <GIC_SPI 413 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>;
+ iommus = <&anoc2_smmu 0x1900>,
+ <&anoc2_smmu 0x1901>;
+ qcom,snoc-host-cap-8bit-quirk;
+ vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
+ vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
+ vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
+ vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
+ vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
+
+ wifi-firmware {
+ iommus = <&apps_smmu 0x1c02 0x1>;
+ };
+ };
+
+ # AHB
+ - |
+ #include <dt-bindings/clock/qcom,gcc-ipq4019.h>
+
+ wifi@a000000 {
+ compatible = "qcom,ipq4019-wifi";
+ reg = <0xa000000 0x200000>;
+ resets = <&gcc WIFI0_CPU_INIT_RESET>,
+ <&gcc WIFI0_RADIO_SRIF_RESET>,
+ <&gcc WIFI0_RADIO_WARM_RESET>,
+ <&gcc WIFI0_RADIO_COLD_RESET>,
+ <&gcc WIFI0_CORE_WARM_RESET>,
+ <&gcc WIFI0_CORE_COLD_RESET>;
+ reset-names = "wifi_cpu_init",
+ "wifi_radio_srif",
+ "wifi_radio_warm",
+ "wifi_radio_cold",
+ "wifi_core_warm",
+ "wifi_core_cold";
+ clocks = <&gcc GCC_WCSS2G_CLK>,
+ <&gcc GCC_WCSS2G_REF_CLK>,
+ <&gcc GCC_WCSS2G_RTC_CLK>;
+ clock-names = "wifi_wcss_cmd",
+ "wifi_wcss_ref",
+ "wifi_wcss_rtc";
+ interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 37 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 38 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 39 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 40 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 41 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 42 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 43 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 44 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 45 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 46 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 47 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "msi8",
+ "msi9",
+ "msi10",
+ "msi11",
+ "msi12",
+ "msi13",
+ "msi14",
+ "msi15",
+ "legacy";
+ ieee80211-freq-limit = <5470000 5875000>;
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
new file mode 100644
index 000000000000..e34d42a30192
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Linaro Limited
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/qcom,ath11k-pci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies ath11k wireless devices (PCIe)
+
+maintainers:
+ - Jeff Johnson <jjohnson@kernel.org>
+
+description: |
+ Qualcomm Technologies IEEE 802.11ax PCIe devices
+
+properties:
+ compatible:
+ enum:
+ - pci17cb,1101 # QCA6390
+ - pci17cb,1103 # WCN6855
+
+ reg:
+ maxItems: 1
+
+ qcom,calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ string to uniquely identify variant of the calibration data for designs
+ with colliding bus and device ids
+
+ qcom,ath11k-calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
+ description: |
+ string to uniquely identify variant of the calibration data for designs
+ with colliding bus and device ids
+
+ firmware-name:
+ maxItems: 1
+ description:
+ If present, a board or platform specific string used to lookup
+ usecase-specific firmware files for the device.
+
+ vddrfacmn-supply:
+ description: VDD_RFA_CMN supply regulator handle
+
+ vddaon-supply:
+ description: VDD_AON supply regulator handle
+
+ vddwlcx-supply:
+ description: VDD_WL_CX supply regulator handle
+
+ vddwlmx-supply:
+ description: VDD_WL_MX supply regulator handle
+
+ vddrfa0p8-supply:
+ description: VDD_RFA_0P8 supply regulator handle
+
+ vddrfa1p2-supply:
+ description: VDD_RFA_1P2 supply regulator handle
+
+ vddrfa1p7-supply:
+ description: VDD_RFA_1P7 supply regulator handle
+
+ vddrfa1p8-supply:
+ description: VDD_RFA_1P8 supply regulator handle
+
+ vddpcie0p9-supply:
+ description: VDD_PCIE_0P9 supply regulator handle
+
+ vddpcie1p8-supply:
+ description: VDD_PCIE_1P8 supply regulator handle
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: pci17cb,1101
+ then:
+ required:
+ - vddrfacmn-supply
+ - vddaon-supply
+ - vddwlcx-supply
+ - vddwlmx-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p7-supply
+ - vddpcie0p9-supply
+ - vddpcie1p8-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: pci17cb,1103
+ then:
+ required:
+ - vddrfacmn-supply
+ - vddaon-supply
+ - vddwlcx-supply
+ - vddwlmx-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p8-supply
+ - vddpcie0p9-supply
+ - vddpcie1p8-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ bus-range = <0x01 0xff>;
+
+ wifi@0 {
+ compatible = "pci17cb,1103";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
+ vddaon-supply = <&vreg_pmu_aon_0p8>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
+
+ qcom,calibration-variant = "LE_X13S";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
index f7cf135aa37f..c089677702cf 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
@@ -1,15 +1,14 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
-
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/qcom,ath11k.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies ath11k wireless devices Generic Binding
+title: Qualcomm Technologies ath11k wireless devices
maintainers:
- - Kalle Valo <kvalo@kernel.org>
+ - Jeff Johnson <jjohnson@kernel.org>
description: |
These are dt entries for Qualcomm Technologies, Inc. IEEE 802.11ax
@@ -21,6 +20,7 @@ properties:
- qcom,ipq8074-wifi
- qcom,ipq6018-wifi
- qcom,wcn6750-wifi
+ - qcom,ipq5018-wifi
reg:
maxItems: 1
@@ -41,8 +41,15 @@ properties:
* reg
* reg-names
+ qcom,calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ string to uniquely identify variant of the calibration data in the
+ board-2.bin for designs with colliding bus and device specific ids
+
qcom,ath11k-calibration-variant:
$ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
description:
string to uniquely identify variant of the calibration data in the
board-2.bin for designs with colliding bus and device specific ids
@@ -58,6 +65,8 @@ properties:
minItems: 1
maxItems: 2
+ ieee80211-freq-limit: true
+
wifi-firmware:
type: object
description: |
@@ -87,6 +96,7 @@ required:
additionalProperties: false
allOf:
+ - $ref: ieee80211.yaml#
- if:
properties:
compatible:
@@ -261,15 +271,6 @@ allOf:
examples:
- |
-
- q6v5_wcss: q6v5_wcss@CD00000 {
- compatible = "qcom,ipq8074-wcss-pil";
- reg = <0xCD00000 0x4040>,
- <0x4AB000 0x20>;
- reg-names = "qdsp6",
- "rmb";
- };
-
wifi0: wifi@c000000 {
compatible = "qcom,ipq8074-wifi";
reg = <0xc000000 0x2000000>;
@@ -386,7 +387,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
- qcn9074_0: qcn9074_0@51100000 {
+ qcn9074_0: wifi@51100000 {
no-map;
reg = <0x0 0x51100000 0x0 0x03500000>;
};
@@ -463,6 +464,6 @@ examples:
qcom,smem-states = <&wlan_smp2p_out 0>;
qcom,smem-state-names = "wlan-smp2p-out";
wifi-firmware {
- iommus = <&apps_smmu 0x1c02 0x1>;
+ iommus = <&apps_smmu 0x1c02 0x1>;
};
};
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
new file mode 100644
index 000000000000..589960144fe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
@@ -0,0 +1,210 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k-wsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies ath12k wireless devices (PCIe) with WSI interface
+
+maintainers:
+ - Jeff Johnson <jjohnson@kernel.org>
+
+description: |
+ Qualcomm Technologies IEEE 802.11be PCIe devices with WSI interface.
+
+ The ath12k devices (QCN9274) feature WSI support. WSI stands for
+ WLAN Serial Interface. It is used for the exchange of specific
+ control information across radios based on the doorbell mechanism.
+ This WSI connection is essential to exchange control information
+ among these devices.
+
+ The WSI interface includes TX and RX ports, which are used to connect
+ multiple WSI-supported devices together, forming a WSI group.
+
+ Diagram to represent one WSI connection (one WSI group) among
+ three devices.
+
+ +-------+ +-------+ +-------+
+ | pcie1 | | pcie2 | | pcie3 |
+ | | | | | |
+ +----->| wsi |------->| wsi |------->| wsi |-----+
+ | | grp 0 | | grp 0 | | grp 0 | |
+ | +-------+ +-------+ +-------+ |
+ +------------------------------------------------------+
+
+ Diagram to represent two WSI connections (two separate WSI groups)
+ among four devices.
+
+ +-------+ +-------+ +-------+ +-------+
+ | pcie0 | | pcie1 | | pcie2 | | pcie3 |
+ | | | | | | | |
+ +-->| wsi |--->| wsi |--+ +-->| wsi |--->| wsi |--+
+ | | grp 0 | | grp 0 | | | | grp 1 | | grp 1 | |
+ | +-------+ +-------+ | | +-------+ +-------+ |
+ +---------------------------+ +---------------------------+
+
+properties:
+ compatible:
+ enum:
+ - pci17cb,1109 # QCN9274
+
+ reg:
+ maxItems: 1
+
+ qcom,calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ String to uniquely identify variant of the calibration data for designs
+ with colliding bus and device ids
+
+ qcom,ath12k-calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
+ description:
+ String to uniquely identify variant of the calibration data for designs
+ with colliding bus and device ids
+
+ qcom,wsi-controller:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The WSI controller device in the WSI group aids (is capable) to
+ synchronize the Timing Synchronization Function (TSF) clock across
+ all devices in the WSI group.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ This is the TX port of WSI interface. It is attached to the RX
+ port of the next device in the WSI connection.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ This is the RX port of WSI interface. It is attached to the TX
+ port of the previous device in the WSI connection.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ wifi@0 {
+ compatible = "pci17cb,1109";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+
+ qcom,calibration-variant = "RDP433_1";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ wifi1_wsi_tx: endpoint {
+ remote-endpoint = <&wifi2_wsi_rx>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ wifi1_wsi_rx: endpoint {
+ remote-endpoint = <&wifi3_wsi_tx>;
+ };
+ };
+ };
+ };
+ };
+
+ pcie@1 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x1 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ wifi@0 {
+ compatible = "pci17cb,1109";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+
+ qcom,calibration-variant = "RDP433_2";
+ qcom,wsi-controller;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ wifi2_wsi_tx: endpoint {
+ remote-endpoint = <&wifi3_wsi_rx>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ wifi2_wsi_rx: endpoint {
+ remote-endpoint = <&wifi1_wsi_tx>;
+ };
+ };
+ };
+ };
+ };
+
+ pcie@2 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x2 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ wifi@0 {
+ compatible = "pci17cb,1109";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+
+ qcom,calibration-variant = "RDP433_3";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ wifi3_wsi_tx: endpoint {
+ remote-endpoint = <&wifi1_wsi_rx>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ wifi3_wsi_rx: endpoint {
+ remote-endpoint = <&wifi2_wsi_tx>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
new file mode 100644
index 000000000000..dc68dd59988f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2024 Linaro Limited
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies ath12k wireless devices (PCIe)
+
+maintainers:
+ - Jeff Johnson <quic_jjohnson@quicinc.com>
+
+description:
+ Qualcomm Technologies IEEE 802.11be PCIe devices.
+
+properties:
+ compatible:
+ enum:
+ - pci17cb,1107 # WCN7850
+
+ reg:
+ maxItems: 1
+
+ firmware-name:
+ maxItems: 1
+ description:
+ If present, a board or platform specific string used to lookup
+ usecase-specific firmware files for the device.
+
+ vddaon-supply:
+ description: VDD_AON supply regulator handle
+
+ vddwlcx-supply:
+ description: VDD_WLCX supply regulator handle
+
+ vddwlmx-supply:
+ description: VDD_WLMX supply regulator handle
+
+ vddrfacmn-supply:
+ description: VDD_RFA_CMN supply regulator handle
+
+ vddrfa0p8-supply:
+ description: VDD_RFA_0P8 supply regulator handle
+
+ vddrfa1p2-supply:
+ description: VDD_RFA_1P2 supply regulator handle
+
+ vddrfa1p8-supply:
+ description: VDD_RFA_1P8 supply regulator handle
+
+ vddpcie0p9-supply:
+ description: VDD_PCIE_0P9 supply regulator handle
+
+ vddpcie1p8-supply:
+ description: VDD_PCIE_1P8 supply regulator handle
+
+required:
+ - compatible
+ - reg
+ - vddaon-supply
+ - vddwlcx-supply
+ - vddwlmx-supply
+ - vddrfacmn-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p8-supply
+ - vddpcie0p9-supply
+ - vddpcie1p8-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ bus-range = <0x01 0xff>;
+
+ wifi@0 {
+ compatible = "pci17cb,1107";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
new file mode 100644
index 000000000000..363a0ecb6ad9
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
@@ -0,0 +1,315 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2024-2025 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/qcom,ipq5332-wifi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies ath12k wireless devices (AHB)
+
+maintainers:
+ - Jeff Johnson <jjohnson@kernel.org>
+
+description:
+ Qualcomm Technologies IEEE 802.11be AHB devices.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5332-wifi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock used for copy engine
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ items:
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Spawn acknowledge interrupt
+ - description: Stop acknowledge interrupt
+ - description: misc-pulse1 interrupt events
+ - description: misc-latch interrupt events
+ - description: sw exception interrupt events
+ - description: interrupt event for ring CE0
+ - description: interrupt event for ring CE1
+ - description: interrupt event for ring CE2
+ - description: interrupt event for ring CE3
+ - description: interrupt event for ring CE4
+ - description: interrupt event for ring CE5
+ - description: interrupt event for ring CE6
+ - description: interrupt event for ring CE7
+ - description: interrupt event for ring CE8
+ - description: interrupt event for ring CE9
+ - description: interrupt event for ring CE10
+ - description: interrupt event for ring CE11
+ - description: interrupt event for ring host2wbm-desc-feed
+ - description: interrupt event for ring host2reo-re-injection
+ - description: interrupt event for ring host2reo-command
+ - description: interrupt event for ring host2rxdma-monitor-ring1
+ - description: interrupt event for ring reo2ost-exception
+ - description: interrupt event for ring wbm2host-rx-release
+ - description: interrupt event for ring reo2host-status
+ - description: interrupt event for ring reo2host-destination-ring4
+ - description: interrupt event for ring reo2host-destination-ring3
+ - description: interrupt event for ring reo2host-destination-ring2
+ - description: interrupt event for ring reo2host-destination-ring1
+ - description: interrupt event for ring rxdma2host-monitor-destination-mac3
+ - description: interrupt event for ring rxdma2host-monitor-destination-mac2
+ - description: interrupt event for ring rxdma2host-monitor-destination-mac1
+ - description: interrupt event for ring host2rxdma-host-buf-ring-mac3
+ - description: interrupt event for ring host2rxdma-host-buf-ring-mac2
+ - description: interrupt event for ring host2rxdma-host-buf-ring-mac1
+ - description: interrupt event for ring host2tcl-input-ring4
+ - description: interrupt event for ring host2tcl-input-ring3
+ - description: interrupt event for ring host2tcl-input-ring2
+ - description: interrupt event for ring host2tcl-input-ring1
+ - description: interrupt event for ring wbm2host-tx-completions-ring4
+ - description: interrupt event for ring wbm2host-tx-completions-ring3
+ - description: interrupt event for ring wbm2host-tx-completions-ring2
+ - description: interrupt event for ring wbm2host-tx-completions-ring1
+ - description: interrupt event for ring host2tx-monitor-ring1
+ - description: interrupt event for ring txmon2host-monitor-destination-mac3
+ - description: interrupt event for ring txmon2host-monitor-destination-mac2
+ - description: interrupt event for ring txmon2host-monitor-destination-mac1
+ - description: interrupt event for umac-reset
+
+ interrupt-names:
+ items:
+ - const: fatal
+ - const: ready
+ - const: spawn
+ - const: stop-ack
+ - const: misc-pulse1
+ - const: misc-latch
+ - const: sw-exception
+ - const: ce0
+ - const: ce1
+ - const: ce2
+ - const: ce3
+ - const: ce4
+ - const: ce5
+ - const: ce6
+ - const: ce7
+ - const: ce8
+ - const: ce9
+ - const: ce10
+ - const: ce11
+ - const: host2wbm-desc-feed
+ - const: host2reo-re-injection
+ - const: host2reo-command
+ - const: host2rxdma-monitor-ring1
+ - const: reo2ost-exception
+ - const: wbm2host-rx-release
+ - const: reo2host-status
+ - const: reo2host-destination-ring4
+ - const: reo2host-destination-ring3
+ - const: reo2host-destination-ring2
+ - const: reo2host-destination-ring1
+ - const: rxdma2host-monitor-destination-mac3
+ - const: rxdma2host-monitor-destination-mac2
+ - const: rxdma2host-monitor-destination-mac1
+ - const: host2rxdma-host-buf-ring-mac3
+ - const: host2rxdma-host-buf-ring-mac2
+ - const: host2rxdma-host-buf-ring-mac1
+ - const: host2tcl-input-ring4
+ - const: host2tcl-input-ring3
+ - const: host2tcl-input-ring2
+ - const: host2tcl-input-ring1
+ - const: wbm2host-tx-completions-ring4
+ - const: wbm2host-tx-completions-ring3
+ - const: wbm2host-tx-completions-ring2
+ - const: wbm2host-tx-completions-ring1
+ - const: host2tx-monitor-ring1
+ - const: txmon2host-monitor-destination-mac3
+ - const: txmon2host-monitor-destination-mac2
+ - const: txmon2host-monitor-destination-mac1
+ - const: umac-reset
+
+ memory-region:
+ description:
+ Memory regions used by the ath12k firmware.
+ items:
+ - description: Q6 memory region
+ - description: m3 dump memory region
+ - description: Q6 caldata memory region
+ - description: Multi Link Operation (MLO) Global memory region
+
+ memory-region-names:
+ items:
+ - const: q6-region
+ - const: m3-dump
+ - const: q6-caldb
+ - const: mlo-global-mem
+
+ qcom,calibration-variant:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ String to uniquely identify variant of the calibration data for designs
+ with colliding bus and device ids
+
+ qcom,rproc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the Qualcomm Hexagon DSP(q6 remote processor), which is utilized
+ for offloading WiFi processing tasks, this q6 remote processor operates in
+ conjunction with WiFi.
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the remote processor
+ items:
+ - description: Shutdown WCSS pd
+ - description: Stop WCSS pd
+ - description: Spawn WCSS pd
+
+ qcom,smem-state-names:
+ description:
+ Names of the states used by the AP to signal the remote processor
+ items:
+ - const: shutdown
+ - const: stop
+ - const: spawn
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - memory-region
+ - memory-region-names
+ - qcom,rproc
+ - qcom,smem-states
+ - qcom,smem-state-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
+
+ wifi0: wifi@c000000 {
+ compatible = "qcom,ipq5332-wifi";
+ reg = <0x0c000000 0x1000000>;
+ clocks = <&gcc GCC_XO_CLK>;
+ clock-names = "xo";
+ interrupts-extended = <&wcss_smp2p_in 8 IRQ_TYPE_NONE>,
+ <&wcss_smp2p_in 9 IRQ_TYPE_NONE>,
+ <&wcss_smp2p_in 12 IRQ_TYPE_NONE>,
+ <&wcss_smp2p_in 11 IRQ_TYPE_NONE>,
+ <&intc GIC_SPI 559 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 560 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 561 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 422 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 423 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 424 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 425 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 426 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 427 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 428 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 429 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 430 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 432 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 491 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 495 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 493 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 544 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 497 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 454 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 453 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 452 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 451 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 488 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 488 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 484 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 554 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 554 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 549 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 507 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 500 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 499 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 498 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 450 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 449 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 447 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 543 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 486 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 486 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 482 IRQ_TYPE_EDGE_RISING>,
+ <&intc GIC_SPI 419 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "fatal",
+ "ready",
+ "spawn",
+ "stop-ack",
+ "misc-pulse1",
+ "misc-latch",
+ "sw-exception",
+ "ce0",
+ "ce1",
+ "ce2",
+ "ce3",
+ "ce4",
+ "ce5",
+ "ce6",
+ "ce7",
+ "ce8",
+ "ce9",
+ "ce10",
+ "ce11",
+ "host2wbm-desc-feed",
+ "host2reo-re-injection",
+ "host2reo-command",
+ "host2rxdma-monitor-ring1",
+ "reo2ost-exception",
+ "wbm2host-rx-release",
+ "reo2host-status",
+ "reo2host-destination-ring4",
+ "reo2host-destination-ring3",
+ "reo2host-destination-ring2",
+ "reo2host-destination-ring1",
+ "rxdma2host-monitor-destination-mac3",
+ "rxdma2host-monitor-destination-mac2",
+ "rxdma2host-monitor-destination-mac1",
+ "host2rxdma-host-buf-ring-mac3",
+ "host2rxdma-host-buf-ring-mac2",
+ "host2rxdma-host-buf-ring-mac1",
+ "host2tcl-input-ring4",
+ "host2tcl-input-ring3",
+ "host2tcl-input-ring2",
+ "host2tcl-input-ring1",
+ "wbm2host-tx-completions-ring4",
+ "wbm2host-tx-completions-ring3",
+ "wbm2host-tx-completions-ring2",
+ "wbm2host-tx-completions-ring1",
+ "host2tx-monitor-ring1",
+ "txmon2host-monitor-destination-mac3",
+ "txmon2host-monitor-destination-mac2",
+ "txmon2host-monitor-destination-mac1",
+ "umac-reset";
+
+ memory-region = <&q6_region>, <&m3_dump>, <&q6_caldb>, <&mlo_mem>;
+ memory-region-names = "q6-region", "m3-dump", "q6-caldb", "mlo-global-mem";
+ qcom,calibration-variant = "RDP441_1";
+ qcom,rproc = <&q6v5_wcss>;
+ qcom,smem-states = <&wcss_smp2p_out 8>,
+ <&wcss_smp2p_out 9>,
+ <&wcss_smp2p_out 10>;
+ qcom,smem-state-names = "shutdown",
+ "stop",
+ "spawn";
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/ralink,rt2880.yaml b/Documentation/devicetree/bindings/net/wireless/ralink,rt2880.yaml
new file mode 100644
index 000000000000..04dc5bb2edcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ralink,rt2880.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/ralink,rt2880.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink RT2880 wireless device
+
+maintainers:
+ - Stanislaw Gruszka <stf_xl@wp.pl>
+
+description: |
+ This node provides properties for configuring RT2880 SOC wifi devices.
+ The node is expected to be specified as a root node of the device.
+
+allOf:
+ - $ref: ieee80211.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ralink,rt2880-wifi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ wifi@110180000 {
+ compatible = "ralink,rt2880-wifi";
+ reg = <0x10180000 0x40000>;
+ clocks = <&sysc 16>;
+ interrupt-parent = <&cpuintc>;
+ interrupts = <6>;
+ };
diff --git a/Documentation/devicetree/bindings/net/wireless/realtek,rtl8188e.yaml b/Documentation/devicetree/bindings/net/wireless/realtek,rtl8188e.yaml
new file mode 100644
index 000000000000..2769731e0708
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/realtek,rtl8188e.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/realtek,rtl8188e.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTL8188E USB WiFi
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+description:
+ Realtek RTL8188E is a family of USB-connected 2.4 GHz WiFi modules.
+
+allOf:
+ - $ref: /schemas/usb/usb-device.yaml#
+
+properties:
+ compatible:
+ const: usbbda,179 # RTL8188ETV
+
+ reg: true
+
+ vdd-supply:
+ description:
+ Regulator for the 3V3 supply.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wifi: wifi@1 {
+ compatible = "usbbda,179";
+ reg = <1>;
+ vdd-supply = <&vcc3v3>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
index b35d2f3ad1ad..6c0888ae4c4e 100644
--- a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
@@ -2,11 +2,10 @@
# Copyright (c) 2020, Silicon Laboratories, Inc.
%YAML 1.2
---
-
$id: http://devicetree.org/schemas/net/wireless/silabs,wfx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Silicon Labs WFxxx devicetree bindings
+title: Silicon Labs WFxxx
maintainers:
- Jérôme Pouiller <jerome.pouiller@silabs.com>
@@ -72,15 +71,12 @@ properties:
"Platform Data Set" in Silabs jargon). Default depends of "compatible"
string. For "silabs,wf200", the default is 'wf200.pds'.
- local-mac-address: true
-
- mac-address: true
-
required:
- compatible
- reg
allOf:
+ - $ref: /schemas/net/wireless/wireless-controller.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml
index e31456730e9f..9de5fdefcbcc 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml
@@ -50,7 +50,6 @@ properties:
Points to the node of the regulator that powers/enable the wl12xx/wl18xx
chip. This is required when connected via SPI.
-
ref-clock-frequency:
$ref: /schemas/types.yaml#/definitions/uint32
description: Reference clock frequency.
@@ -89,48 +88,54 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
// For wl12xx family:
- spi1 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- wlcore1: wlcore@1 {
- compatible = "ti,wl1271";
- reg = <1>;
- spi-max-frequency = <48000000>;
- interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
- vwlan-supply = <&vwlan_fixed>;
- clock-xtal;
- ref-clock-frequency = <38400000>;
- };
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wlcore1: wlcore@1 {
+ compatible = "ti,wl1271";
+ reg = <1>;
+ spi-max-frequency = <48000000>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ vwlan-supply = <&vwlan_fixed>;
+ clock-xtal;
+ ref-clock-frequency = <38400000>;
+ };
};
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
// For wl18xx family:
- spi2 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- wlcore2: wlcore@0 {
- compatible = "ti,wl1835";
- reg = <0>;
- spi-max-frequency = <48000000>;
- interrupts = <27 IRQ_TYPE_EDGE_RISING>;
- vwlan-supply = <&vwlan_fixed>;
- };
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wlcore2: wlcore@0 {
+ compatible = "ti,wl1835";
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ vwlan-supply = <&vwlan_fixed>;
+ };
};
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
// SDIO example:
mmc3 {
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- wlcore3: wlcore@2 {
- compatible = "ti,wl1835";
- reg = <2>;
- interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
- };
+ vmmc-supply = <&wlan_en_reg>;
+ bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wlcore3: wlcore@2 {
+ compatible = "ti,wl1835";
+ reg = <2>;
+ interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
diff --git a/Documentation/devicetree/bindings/net/wireless/wireless-controller.yaml b/Documentation/devicetree/bindings/net/wireless/wireless-controller.yaml
new file mode 100644
index 000000000000..7379f6c1aa05
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/wireless-controller.yaml
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/wireless-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wireless Controller Common Properties
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+properties:
+ $nodename:
+ pattern: "^wifi(@.*)?$"
+
+allOf:
+ - $ref: ieee80211.yaml#
+ - $ref: /schemas/net/network-class.yaml#
+
+additionalProperties: true
+
+...
+
diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
deleted file mode 100644
index 1aa4c6006cd0..000000000000
--- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-XILINX AXI ETHERNET Device Tree Bindings
---------------------------------------------------------
-
-Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
-provides connectivity to an external ethernet PHY supporting different
-interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
-segments of memory for buffering TX and RX, as well as the capability of
-offloading TX/RX checksum calculation off the processor.
-
-Management configuration is done through the AXI interface, while payload is
-sent and received through means of an AXI DMA controller. This driver
-includes the DMA driver code, so this driver is incompatible with AXI DMA
-driver.
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible : Must be one of "xlnx,axi-ethernet-1.00.a",
- "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a"
-- reg : Address and length of the IO space, as well as the address
- and length of the AXI DMA controller IO space, unless
- axistream-connected is specified, in which case the reg
- attribute of the node referenced by it is used.
-- interrupts : Should be a list of 2 or 3 interrupts: TX DMA, RX DMA,
- and optionally Ethernet core. If axistream-connected is
- specified, the TX/RX DMA interrupts should be on that node
- instead, and only the Ethernet core interrupt is optionally
- specified here.
-- phy-handle : Should point to the external phy device if exists. Pointing
- this to the PCS/PMA PHY is deprecated and should be avoided.
- See ethernet.txt file in the same directory.
-- xlnx,rxmem : Set to allocated memory buffer for Rx/Tx in the hardware
-
-Optional properties:
-- phy-mode : See ethernet.txt
-- xlnx,phy-type : Deprecated, do not use, but still accepted in preference
- to phy-mode.
-- xlnx,txcsum : 0 or empty for disabling TX checksum offload,
- 1 to enable partial TX checksum offload,
- 2 to enable full TX checksum offload
-- xlnx,rxcsum : Same values as xlnx,txcsum but for RX checksum offload
-- xlnx,switch-x-sgmii : Boolean to indicate the Ethernet core is configured to
- support both 1000BaseX and SGMII modes. If set, the phy-mode
- should be set to match the mode selected on core reset (i.e.
- by the basex_or_sgmii core input line).
-- clock-names: Tuple listing input clock names. Possible clocks:
- s_axi_lite_clk: Clock for AXI register slave interface
- axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces
- ref_clk: Ethernet reference clock, used by signal delay
- primitives and transceivers
- mgt_clk: MGT reference clock (used by optional internal
- PCS/PMA PHY)
-
- Note that if s_axi_lite_clk is not specified by name, the
- first clock of any name is used for this. If that is also not
- specified, the clock rate is auto-detected from the CPU clock
- (but only on platforms where this is possible). New device
- trees should specify all applicable clocks by name - the
- fallbacks to an unnamed clock or to CPU clock are only for
- backward compatibility.
-- clocks: Phandles to input clocks matching clock-names. Refer to common
- clock bindings.
-- axistream-connected: Reference to another node which contains the resources
- for the AXI DMA controller used by this device.
- If this is specified, the DMA-related resources from that
- device (DMA registers and DMA TX/RX interrupts) rather
- than this one will be used.
- - mdio : Child node for MDIO bus. Must be defined if PHY access is
- required through the core's MDIO interface (i.e. always,
- unless the PHY is accessed through a different bus).
-
- - pcs-handle: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X
- modes, where "pcs-handle" should be used to point
- to the PCS/PMA PHY, and "phy-handle" should point to an
- external PHY if exists.
-
-Example:
- axi_ethernet_eth: ethernet@40c00000 {
- compatible = "xlnx,axi-ethernet-1.00.a";
- device_type = "network";
- interrupt-parent = <&microblaze_0_axi_intc>;
- interrupts = <2 0 1>;
- clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
- clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
- phy-mode = "mii";
- reg = <0x40c00000 0x40000 0x50c00000 0x40000>;
- xlnx,rxcsum = <0x2>;
- xlnx,rxmem = <0x800>;
- xlnx,txcsum = <0x2>;
- phy-handle = <&phy0>;
- axi_ethernetlite_0_mdio: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- phy0: phy@0 {
- device_type = "ethernet-phy";
- reg = <1>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
deleted file mode 100644
index 038dda48b8e6..000000000000
--- a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-XILINX GMIITORGMII Converter Driver Device Tree Bindings
---------------------------------------------------------
-
-The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
-Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
-Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
-This core can be used in all three modes of operation(10/100/1000 Mb/s).
-The Management Data Input/Output (MDIO) interface is used to configure the
-Speed of operation. This core can switch dynamically between the three
-Different speed modes by configuring the conveter register through mdio write.
-
-This converter sits between the ethernet MAC and the external phy.
-MAC <==> GMII2RGMII <==> RGMII_PHY
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible : Should be "xlnx,gmii-to-rgmii-1.0"
-- reg : The ID number for the phy, usually a small integer
-- phy-handle : Should point to the external phy device.
- See ethernet.txt file in the same directory.
-
-Example:
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- phy: ethernet-phy@0 {
- ......
- };
- gmiitorgmii: gmiitorgmii@8 {
- compatible = "xlnx,gmii-to-rgmii-1.0";
- reg = <8>;
- phy-handle = <&phy>;
- };
- };
diff --git a/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
new file mode 100644
index 000000000000..fb02e579463c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
@@ -0,0 +1,200 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/xlnx,axi-ethernet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AXI 1G/2.5G Ethernet Subsystem
+
+description: |
+ Also called AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
+ provides connectivity to an external ethernet PHY supporting different
+ interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
+ segments of memory for buffering TX and RX, as well as the capability of
+ offloading TX/RX checksum calculation off the processor.
+
+ Management configuration is done through the AXI interface, while payload is
+ sent and received through means of an AXI DMA controller. This driver
+ includes the DMA driver code, so this driver is incompatible with AXI DMA
+ driver.
+
+maintainers:
+ - Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
+
+properties:
+ compatible:
+ enum:
+ - xlnx,axi-ethernet-1.00.a
+ - xlnx,axi-ethernet-1.01.a
+ - xlnx,axi-ethernet-2.01.a
+
+ reg:
+ description:
+ Address and length of the IO space, as well as the address
+ and length of the AXI DMA controller IO space, unless
+ axistream-connected is specified, in which case the reg
+ attribute of the node referenced by it is used.
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: Ethernet core interrupt
+ - description: Tx DMA interrupt
+ - description: Rx DMA interrupt
+ description:
+ Ethernet core interrupt is optional. If axistream-connected property is
+ present DMA node should contains TX/RX DMA interrupts else DMA interrupt
+ resources are mentioned on ethernet node.
+ minItems: 1
+
+ phy-handle: true
+
+ xlnx,rxmem:
+ description:
+ Set to allocated memory buffer for Rx/Tx in the hardware.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ phy-mode:
+ enum:
+ - mii
+ - gmii
+ - rgmii
+ - sgmii
+ - 1000base-x
+
+ xlnx,phy-type:
+ description:
+ Do not use, but still accepted in preference to phy-mode.
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ xlnx,txcsum:
+ description:
+ TX checksum offload. 0 or empty for disabling TX checksum offload,
+ 1 to enable partial TX checksum offload and 2 to enable full TX
+ checksum offload.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ xlnx,rxcsum:
+ description:
+ RX checksum offload. 0 or empty for disabling RX checksum offload,
+ 1 to enable partial RX checksum offload and 2 to enable full RX
+ checksum offload.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ xlnx,switch-x-sgmii:
+ type: boolean
+ description:
+ Indicate the Ethernet core is configured to support both 1000BaseX and
+ SGMII modes. If set, the phy-mode should be set to match the mode
+ selected on core reset (i.e. by the basex_or_sgmii core input line).
+
+ clocks:
+ items:
+ - description: Clock for AXI register slave interface.
+ - description: AXI4-Stream clock for TXD RXD TXC and RXS interfaces.
+ - description: Ethernet reference clock, used by signal delay primitives
+ and transceivers.
+ - description: MGT reference clock (used by optional internal PCS/PMA PHY)
+
+ clock-names:
+ items:
+ - const: s_axi_lite_clk
+ - const: axis_clk
+ - const: ref_clk
+ - const: mgt_clk
+
+ axistream-connected:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of AXI DMA controller which contains the resources
+ used by this device. If this is specified, the DMA-related resources
+ from that device (DMA registers and DMA TX/RX interrupts) rather than
+ this one will be used.
+
+ mdio:
+ type: object
+
+ pcs-handle:
+ description: Phandle to the internal PCS/PMA PHY in SGMII or 1000Base-X
+ modes, where "pcs-handle" should be used to point to the PCS/PMA PHY,
+ and "phy-handle" should point to an external PHY if exists.
+ maxItems: 1
+
+ dmas:
+ minItems: 2
+ maxItems: 32
+ description: TX and RX DMA channel phandle
+
+ dma-names:
+ items:
+ pattern: "^[tr]x_chan([0-9]|1[0-5])$"
+ description:
+ Should be "tx_chan0", "tx_chan1" ... "tx_chan15" for DMA Tx channel
+ Should be "rx_chan0", "rx_chan1" ... "rx_chan15" for DMA Rx channel
+ minItems: 2
+ maxItems: 32
+
+required:
+ - compatible
+ - interrupts
+ - reg
+ - xlnx,rxmem
+ - phy-handle
+
+allOf:
+ - $ref: /schemas/net/ethernet-controller.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ axi_ethernet_eth: ethernet@40c00000 {
+ compatible = "xlnx,axi-ethernet-1.00.a";
+ interrupts = <2 0 1>;
+ clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
+ clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
+ phy-mode = "mii";
+ reg = <0x40c00000 0x40000>,<0x50c00000 0x40000>;
+ dmas = <&xilinx_dma 0>, <&xilinx_dma 1>;
+ dma-names = "tx_chan0", "rx_chan0";
+ xlnx,rxcsum = <0x2>;
+ xlnx,rxmem = <0x800>;
+ xlnx,txcsum = <0x2>;
+ phy-handle = <&phy0>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
+ };
+ };
+
+ - |
+ axi_ethernet_eth1: ethernet@40000000 {
+ compatible = "xlnx,axi-ethernet-1.00.a";
+ interrupts = <0>;
+ clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
+ clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
+ phy-mode = "mii";
+ reg = <0x40000000 0x40000>;
+ xlnx,rxcsum = <0x2>;
+ xlnx,rxmem = <0x800>;
+ xlnx,txcsum = <0x2>;
+ phy-handle = <&phy1>;
+ axistream-connected = <&dma>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy1: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml b/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml
index 92d8ade988f6..e16384aff557 100644
--- a/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml
+++ b/Documentation/devicetree/bindings/net/xlnx,emaclite.yaml
@@ -29,6 +29,9 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 1
+
phy-handle: true
local-mac-address: true
@@ -45,6 +48,7 @@ required:
- compatible
- reg
- interrupts
+ - clocks
- phy-handle
additionalProperties: false
@@ -56,6 +60,7 @@ examples:
reg = <0x40e00000 0x10000>;
interrupt-parent = <&axi_intc_1>;
interrupts = <1>;
+ clocks = <&dummy>;
local-mac-address = [00 00 00 00 00 00];
phy-handle = <&phy0>;
xlnx,rx-ping-pong;
diff --git a/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml
new file mode 100644
index 000000000000..eb803ddd13e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/xlnx,gmii-to-rgmii.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx GMII to RGMII Converter
+
+maintainers:
+ - Harini Katakam <harini.katakam@amd.com>
+
+description:
+ The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media
+ Independent Interface (RGMII) core provides the RGMII between RGMII-compliant
+ ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
+ This core can be used in all three modes of operation(10/100/1000 Mb/s).
+ The Management Data Input/Output (MDIO) interface is used to configure the
+ speed of operation. This core can switch dynamically between the three
+ different speed modes by configuring the converter register through mdio write.
+ The core cannot function without an external phy connected to it.
+
+properties:
+ compatible:
+ const: xlnx,gmii-to-rgmii-1.0
+
+ reg:
+ minimum: 0
+ maximum: 31
+ description: The ID number for the phy.
+
+ phy-handle:
+ $ref: ethernet-controller.yaml#/properties/phy-handle
+
+ clocks:
+ items:
+ - description: 200/375 MHz free-running clock is used as input clock.
+
+required:
+ - compatible
+ - reg
+ - phy-handle
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+ gmiitorgmii@8 {
+ compatible = "xlnx,gmii-to-rgmii-1.0";
+ reg = <8>;
+ phy-handle = <&phy>;
+ clocks = <&dummy>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nios2/nios2.txt b/Documentation/devicetree/bindings/nios2/nios2.txt
index b95e831bcba3..3e9cabe667b3 100644
--- a/Documentation/devicetree/bindings/nios2/nios2.txt
+++ b/Documentation/devicetree/bindings/nios2/nios2.txt
@@ -23,7 +23,7 @@ Required properties:
- altr,tlb-num-ways: Specifies the number of set-associativity ways in the TLB.
- altr,tlb-num-entries: Specifies the number of entries in the TLB.
- altr,tlb-ptr-sz: Specifies size of TLB pointer.
-- altr,has-mul: Specifies CPU hardware multipy support, should be 1.
+- altr,has-mul: Specifies CPU hardware multiply support, should be 1.
- altr,has-mmu: Specifies CPU support MMU support, should be 1.
- altr,has-initda: Specifies CPU support initda instruction, should be 1.
- altr,reset-addr: Specifies CPU reset address
diff --git a/Documentation/devicetree/bindings/npu/arm,ethos.yaml b/Documentation/devicetree/bindings/npu/arm,ethos.yaml
new file mode 100644
index 000000000000..716c4997f976
--- /dev/null
+++ b/Documentation/devicetree/bindings/npu/arm,ethos.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/npu/arm,ethos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Ethos U65/U85
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+description: >
+ The Arm Ethos-U NPUs are designed for IoT inference applications. The NPUs
+ can accelerate 8-bit and 16-bit integer quantized networks:
+
+ Transformer networks (U85 only)
+ Convolutional Neural Networks (CNN)
+ Recurrent Neural Networks (RNN)
+
+ Further documentation is available here:
+
+ U65 TRM: https://developer.arm.com/documentation/102023/
+ U85 TRM: https://developer.arm.com/documentation/102685/
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx93-npu
+ - const: arm,ethos-u65
+ - items:
+ - {}
+ - const: arm,ethos-u85
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: apb
+
+ power-domains:
+ maxItems: 1
+
+ sram:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx93-clock.h>
+
+ npu@4a900000 {
+ compatible = "fsl,imx93-npu", "arm,ethos-u65";
+ reg = <0x4a900000 0x1000>;
+ interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&mlmix>;
+ clocks = <&clk IMX93_CLK_ML>, <&clk IMX93_CLK_ML_APB>;
+ clock-names = "core", "apb";
+ sram = <&sram>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
new file mode 100644
index 000000000000..caca2a4903cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/npu/rockchip,rk3588-rknn-core.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Neural Processing Unit IP from Rockchip
+
+maintainers:
+ - Tomeu Vizoso <tomeu@tomeuvizoso.net>
+
+description:
+ Rockchip IP for accelerating inference of neural networks.
+
+ There is to be a node per each NPU core in the SoC, and each core should reference all the
+ resources that it needs to function, such as clocks, power domains, and resets.
+
+properties:
+ $nodename:
+ pattern: '^npu@[a-f0-9]+$'
+
+ compatible:
+ enum:
+ - rockchip,rk3588-rknn-core
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: pc # Program Control-related registers
+ - const: cna # Convolution Neural Network Accelerator registers
+ - const: core # Main NPU core processing unit registers
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: hclk
+ - const: npu
+ - const: pclk
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ npu-supply: true
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: srst_a
+ - const: srst_h
+
+ sram-supply: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - iommus
+ - power-domains
+ - resets
+ - reset-names
+ - npu-supply
+ - sram-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/rk3588-power.h>
+ #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ npu@fdab0000 {
+ compatible = "rockchip,rk3588-rknn-core";
+ reg = <0x0 0xfdab0000 0x0 0x1000>,
+ <0x0 0xfdab1000 0x0 0x1000>,
+ <0x0 0xfdab3000 0x0 0x1000>;
+ reg-names = "pc", "cna", "core";
+ clocks = <&cru ACLK_NPU0>, <&cru HCLK_NPU0>,
+ <&scmi_clk SCMI_CLK_NPU>, <&cru PCLK_NPU_ROOT>;
+ clock-names = "aclk", "hclk", "npu", "pclk";
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+ iommus = <&rknn_mmu_0>;
+ npu-supply = <&vdd_npu_s0>;
+ power-domains = <&power RK3588_PD_NPUTOP>;
+ resets = <&cru SRST_A_RKNN0>, <&cru SRST_H_RKNN0>;
+ reset-names = "srst_a", "srst_h";
+ sram-supply = <&vdd_npu_mem_s0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt
deleted file mode 100644
index 42f282c2f3cc..000000000000
--- a/Documentation/devicetree/bindings/numa.txt
+++ /dev/null
@@ -1,319 +0,0 @@
-==============================================================================
-NUMA binding description.
-==============================================================================
-
-==============================================================================
-1 - Introduction
-==============================================================================
-
-Systems employing a Non Uniform Memory Access (NUMA) architecture contain
-collections of hardware resources including processors, memory, and I/O buses,
-that comprise what is commonly known as a NUMA node.
-Processor accesses to memory within the local NUMA node is generally faster
-than processor accesses to memory outside of the local NUMA node.
-DT defines interfaces that allow the platform to convey NUMA node
-topology information to OS.
-
-==============================================================================
-2 - numa-node-id
-==============================================================================
-
-For the purpose of identification, each NUMA node is associated with a unique
-token known as a node id. For the purpose of this binding
-a node id is a 32-bit integer.
-
-A device node is associated with a NUMA node by the presence of a
-numa-node-id property which contains the node id of the device.
-
-Example:
- /* numa node 0 */
- numa-node-id = <0>;
-
- /* numa node 1 */
- numa-node-id = <1>;
-
-==============================================================================
-3 - distance-map
-==============================================================================
-
-The optional device tree node distance-map describes the relative
-distance (memory latency) between all numa nodes.
-
-- compatible : Should at least contain "numa-distance-map-v1".
-
-- distance-matrix
- This property defines a matrix to describe the relative distances
- between all numa nodes.
- It is represented as a list of node pairs and their relative distance.
-
- Note:
- 1. Each entry represents distance from first node to second node.
- The distances are equal in either direction.
- 2. The distance from a node to self (local distance) is represented
- with value 10 and all internode distance should be represented with
- a value greater than 10.
- 3. distance-matrix should have entries in lexicographical ascending
- order of nodes.
- 4. There must be only one device node distance-map which must
- reside in the root node.
- 5. If the distance-map node is not present, a default
- distance-matrix is used.
-
-Example:
- 4 nodes connected in mesh/ring topology as below,
-
- 0_______20______1
- | |
- | |
- 20 20
- | |
- | |
- |_______________|
- 3 20 2
-
- if relative distance for each hop is 20,
- then internode distance would be,
- 0 -> 1 = 20
- 1 -> 2 = 20
- 2 -> 3 = 20
- 3 -> 0 = 20
- 0 -> 2 = 40
- 1 -> 3 = 40
-
- and dt presentation for this distance matrix is,
-
- distance-map {
- compatible = "numa-distance-map-v1";
- distance-matrix = <0 0 10>,
- <0 1 20>,
- <0 2 40>,
- <0 3 20>,
- <1 0 20>,
- <1 1 10>,
- <1 2 20>,
- <1 3 40>,
- <2 0 40>,
- <2 1 20>,
- <2 2 10>,
- <2 3 20>,
- <3 0 20>,
- <3 1 40>,
- <3 2 20>,
- <3 3 10>;
- };
-
-==============================================================================
-4 - Empty memory nodes
-==============================================================================
-
-Empty memory nodes, which no memory resides in, are allowed. There are no
-device nodes for these empty memory nodes. However, the NUMA node IDs and
-distance maps are still valid and memory may be added into them through
-hotplug afterwards.
-
-Example:
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- numa-node-id = <0>;
- };
-
- memory@80000000 {
- device_type = "memory";
- reg = <0x0 0x80000000 0x0 0x80000000>;
- numa-node-id = <1>;
- };
-
- /* Empty memory node 2 and 3 */
- distance-map {
- compatible = "numa-distance-map-v1";
- distance-matrix = <0 0 10>,
- <0 1 20>,
- <0 2 40>,
- <0 3 20>,
- <1 0 20>,
- <1 1 10>,
- <1 2 20>,
- <1 3 40>,
- <2 0 40>,
- <2 1 20>,
- <2 2 10>,
- <2 3 20>,
- <3 0 20>,
- <3 1 40>,
- <3 2 20>,
- <3 3 10>;
- };
-
-==============================================================================
-5 - Example dts
-==============================================================================
-
-Dual socket system consists of 2 boards connected through ccn bus and
-each board having one socket/soc of 8 cpus, memory and pci bus.
-
- memory@c00000 {
- device_type = "memory";
- reg = <0x0 0xc00000 0x0 0x80000000>;
- /* node 0 */
- numa-node-id = <0>;
- };
-
- memory@10000000000 {
- device_type = "memory";
- reg = <0x100 0x0 0x0 0x80000000>;
- /* node 1 */
- numa-node-id = <1>;
- };
-
- cpus {
- #address-cells = <2>;
- #size-cells = <0>;
-
- cpu@0 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x0>;
- enable-method = "psci";
- /* node 0 */
- numa-node-id = <0>;
- };
- cpu@1 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x1>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@2 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x2>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@3 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x3>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@4 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x4>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@5 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x5>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@6 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x6>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@7 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x7>;
- enable-method = "psci";
- numa-node-id = <0>;
- };
- cpu@8 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x8>;
- enable-method = "psci";
- /* node 1 */
- numa-node-id = <1>;
- };
- cpu@9 {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0x9>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- cpu@a {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0xa>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- cpu@b {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0xb>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- cpu@c {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0xc>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- cpu@d {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0xd>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- cpu@e {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0xe>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- cpu@f {
- device_type = "cpu";
- compatible = "arm,armv8";
- reg = <0x0 0xf>;
- enable-method = "psci";
- numa-node-id = <1>;
- };
- };
-
- pcie0: pcie0@848000000000 {
- compatible = "arm,armv8";
- device_type = "pci";
- bus-range = <0 255>;
- #size-cells = <2>;
- #address-cells = <3>;
- reg = <0x8480 0x00000000 0 0x10000000>; /* Configuration space */
- ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
- /* node 0 */
- numa-node-id = <0>;
- };
-
- pcie1: pcie1@948000000000 {
- compatible = "arm,armv8";
- device_type = "pci";
- bus-range = <0 255>;
- #size-cells = <2>;
- #address-cells = <3>;
- reg = <0x9480 0x00000000 0 0x10000000>; /* Configuration space */
- ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
- /* node 1 */
- numa-node-id = <1>;
- };
-
- distance-map {
- compatible = "numa-distance-map-v1";
- distance-matrix = <0 0 10>,
- <0 1 20>,
- <1 1 10>;
- };
diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
index 34dd1cc67124..4c0b1f90aff8 100644
--- a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
+++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml
@@ -11,11 +11,18 @@ maintainers:
properties:
compatible:
- items:
- - enum:
- - apple,t8103-nvme-ans2
- - apple,t6000-nvme-ans2
- - const: apple,nvme-ans2
+ oneOf:
+ - const: apple,t8015-nvme-ans2
+ - items:
+ - const: apple,t6020-nvme-ans2
+ - const: apple,t8103-nvme-ans2
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,t8103-nvme-ans2
+ - apple,t8112-nvme-ans2
+ - apple,t6000-nvme-ans2
+ - const: apple,nvme-ans2
reg:
items:
@@ -65,19 +72,21 @@ if:
properties:
compatible:
contains:
- const: apple,t8103-nvme-ans2
+ enum:
+ - apple,t6000-nvme-ans2
+ - apple,t6020-nvme-ans2
then:
properties:
power-domains:
- maxItems: 2
+ minItems: 3
power-domain-names:
- maxItems: 2
+ minItems: 3
else:
properties:
power-domains:
- minItems: 3
+ maxItems: 2
power-domain-names:
- minItems: 3
+ maxItems: 2
required:
- compatible
diff --git a/Documentation/devicetree/bindings/nvmem/airoha,an8855-efuse.yaml b/Documentation/devicetree/bindings/nvmem/airoha,an8855-efuse.yaml
new file mode 100644
index 000000000000..9802d9ea2176
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/airoha,an8855-efuse.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/airoha,an8855-efuse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha AN8855 Switch EFUSE
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ Airoha AN8855 EFUSE used to calibrate internal PHYs and store additional
+ configuration info.
+
+$ref: nvmem.yaml#
+
+properties:
+ compatible:
+ const: airoha,an8855-efuse
+
+ '#nvmem-cell-cells':
+ const: 0
+
+required:
+ - compatible
+ - '#nvmem-cell-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ efuse {
+ compatible = "airoha,an8855-efuse";
+
+ #nvmem-cell-cells = <0>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ shift_sel_port0_tx_a: shift-sel-port0-tx-a@c {
+ reg = <0xc 0x4>;
+ };
+
+ shift_sel_port0_tx_b: shift-sel-port0-tx-b@10 {
+ reg = <0x10 0x4>;
+ };
+
+ shift_sel_port0_tx_c: shift-sel-port0-tx-c@14 {
+ reg = <0x14 0x4>;
+ };
+
+ shift_sel_port0_tx_d: shift-sel-port0-tx-d@18 {
+ reg = <0x18 0x4>;
+ };
+
+ shift_sel_port1_tx_a: shift-sel-port1-tx-a@1c {
+ reg = <0x1c 0x4>;
+ };
+
+ shift_sel_port1_tx_b: shift-sel-port1-tx-b@20 {
+ reg = <0x20 0x4>;
+ };
+
+ shift_sel_port1_tx_c: shift-sel-port1-tx-c@24 {
+ reg = <0x24 0x4>;
+ };
+
+ shift_sel_port1_tx_d: shift-sel-port1-tx-d@28 {
+ reg = <0x28 0x4>;
+ };
+
+ shift_sel_port2_tx_a: shift-sel-port2-tx-a@2c {
+ reg = <0x2c 0x4>;
+ };
+
+ shift_sel_port2_tx_b: shift-sel-port2-tx-b@30 {
+ reg = <0x30 0x4>;
+ };
+
+ shift_sel_port2_tx_c: shift-sel-port2-tx-c@34 {
+ reg = <0x34 0x4>;
+ };
+
+ shift_sel_port2_tx_d: shift-sel-port2-tx-d@38 {
+ reg = <0x38 0x4>;
+ };
+
+ shift_sel_port3_tx_a: shift-sel-port3-tx-a@4c {
+ reg = <0x4c 0x4>;
+ };
+
+ shift_sel_port3_tx_b: shift-sel-port3-tx-b@50 {
+ reg = <0x50 0x4>;
+ };
+
+ shift_sel_port3_tx_c: shift-sel-port3-tx-c@54 {
+ reg = <0x54 0x4>;
+ };
+
+ shift_sel_port3_tx_d: shift-sel-port3-tx-d@58 {
+ reg = <0x58 0x4>;
+ };
+
+ shift_sel_port4_tx_a: shift-sel-port4-tx-a@5c {
+ reg = <0x5c 0x4>;
+ };
+
+ shift_sel_port4_tx_b: shift-sel-port4-tx-b@60 {
+ reg = <0x60 0x4>;
+ };
+
+ shift_sel_port4_tx_c: shift-sel-port4-tx-c@64 {
+ reg = <0x64 0x4>;
+ };
+
+ shift_sel_port4_tx_d: shift-sel-port4-tx-d@68 {
+ reg = <0x68 0x4>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
index e558587ff885..f67470b8a2ed 100644
--- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
@@ -4,14 +4,15 @@
$id: http://devicetree.org/schemas/nvmem/allwinner,sun4i-a10-sid.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Security ID Device Tree Bindings
+title: Allwinner A10 Security ID
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
@@ -23,7 +24,10 @@ properties:
- const: allwinner,sun20i-d1-sid
- const: allwinner,sun50i-a64-sid
- items:
- - const: allwinner,sun50i-a100-sid
+ - enum:
+ - allwinner,sun50i-a100-sid
+ - allwinner,sun50i-h616-sid
+ - allwinner,sun55i-a523-sid
- const: allwinner,sun50i-a64-sid
- const: allwinner,sun50i-h5-sid
- const: allwinner,sun50i-h6-sid
diff --git a/Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml b/Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml
new file mode 100644
index 000000000000..99ddc9a4af05
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/amlogic,meson-gxbb-efuse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson GX eFuse
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,meson-gxbb-efuse
+ - items:
+ - const: amlogic,meson-gx-efuse
+ - const: amlogic,meson-gxbb-efuse
+
+ clocks:
+ maxItems: 1
+
+ secure-monitor:
+ description: phandle to the secure-monitor node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - secure-monitor
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ efuse: efuse {
+ compatible = "amlogic,meson-gxbb-efuse";
+ clocks = <&clk_efuse>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ secure-monitor = <&sm>;
+
+ sn: sn@14 {
+ reg = <0x14 0x10>;
+ };
+
+ eth_mac: mac@34 {
+ reg = <0x34 0x10>;
+ };
+
+ bid: bid@46 {
+ reg = <0x46 0x30>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml b/Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml
new file mode 100644
index 000000000000..9879d521842e
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/amlogic,meson6-efuse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson6 eFuse
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson6-efuse
+ - amlogic,meson8-efuse
+ - amlogic,meson8b-efuse
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: core
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ efuse: efuse@0 {
+ compatible = "amlogic,meson6-efuse";
+ reg = <0x0 0x2000>;
+ clocks = <&clk_efuse>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ethernet_mac_address: mac@1b4 {
+ reg = <0x1b4 0x6>;
+ };
+
+ temperature_calib: calib@1f4 {
+ reg = <0x1f4 0x4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
deleted file mode 100644
index f7b3ed74db54..000000000000
--- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-= Amlogic Meson GX eFuse device tree bindings =
-
-Required properties:
-- compatible: should be "amlogic,meson-gxbb-efuse"
-- clocks: phandle to the efuse peripheral clock provided by the
- clock controller.
-- secure-monitor: phandle to the secure-monitor node
-
-= Data cells =
-Are child nodes of eFuse, bindings of which as described in
-bindings/nvmem/nvmem.txt
-
-Example:
-
- efuse: efuse {
- compatible = "amlogic,meson-gxbb-efuse";
- clocks = <&clkc CLKID_EFUSE>;
- #address-cells = <1>;
- #size-cells = <1>;
- secure-monitor = <&sm>;
-
- sn: sn@14 {
- reg = <0x14 0x10>;
- };
-
- eth_mac: eth_mac@34 {
- reg = <0x34 0x10>;
- };
-
- bid: bid@46 {
- reg = <0x46 0x30>;
- };
- };
-
- sm: secure-monitor {
- compatible = "amlogic,meson-gxbb-sm";
- };
-
-= Data consumers =
-Are device nodes which consume nvmem data cells.
-
-For example:
-
- eth_mac {
- ...
- nvmem-cells = <&eth_mac>;
- nvmem-cell-names = "eth_mac";
- };
diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt
deleted file mode 100644
index a3c63954a1a4..000000000000
--- a/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Amlogic Meson6/Meson8/Meson8b efuse
-
-Required Properties:
-- compatible: depending on the SoC this should be one of:
- - "amlogic,meson6-efuse"
- - "amlogic,meson8-efuse"
- - "amlogic,meson8b-efuse"
-- reg: base address and size of the efuse registers
-- clocks: a reference to the efuse core gate clock
-- clock-names: must be "core"
-
-All properties and sub-nodes as well as the consumer bindings
-defined in nvmem.txt in this directory are also supported.
-
-
-Example:
- efuse: nvmem@0 {
- compatible = "amlogic,meson8-efuse";
- reg = <0x0 0x2000>;
- clocks = <&clkc CLKID_EFUSE>;
- clock-names = "core";
- };
diff --git a/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml b/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml
index 5ec8f2bdb3a5..d3abdafdbca0 100644
--- a/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml
+++ b/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml
@@ -15,7 +15,8 @@ maintainers:
- Sven Peter <sven@svenpeter.dev>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
new file mode 100644
index 000000000000..80b5a6cdcec9
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/apple,spmi-nvmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SPMI NVMEM
+
+description: Exports a series of SPMI registers as NVMEM cells
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,maverick-pmic
+ - apple,sera-pmic
+ - apple,stowe-pmic
+ - const: apple,spmi-nvmem
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@f {
+ compatible = "apple,maverick-pmic", "apple,spmi-nvmem";
+ reg = <0xf SPMI_USID>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ boot_stage: boot-stage@6001 {
+ reg = <0x6001 0x1>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
index 25033de3ef6b..13412af7f046 100644
--- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
+++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
@@ -20,7 +20,7 @@ maintainers:
- Rafał Miłecki <rafal@milecki.pl>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
properties:
compatible:
@@ -36,14 +36,29 @@ properties:
et0macaddr:
type: object
description: First Ethernet interface's MAC address
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ additionalProperties: false
et1macaddr:
type: object
description: Second Ethernet interface's MAC address
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ additionalProperties: false
et2macaddr:
type: object
description: Third Ethernet interface's MAC address
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ additionalProperties: false
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
deleted file mode 100644
index 0415265c215a..000000000000
--- a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Broadcom OTP memory controller
-
-Required Properties:
-- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used
- in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second
- generation Broadcom OTPC which is used in SoC's such as Stingray and supports
- 64-bit read/write.
-- reg: Base address of the OTP controller.
-- brcm,ocotp-size: Amount of memory available, in 32 bit words
-
-Example:
-
-otp: otp@301c800 {
- compatible = "brcm,ocotp";
- reg = <0x0301c800 0x2c>;
- brcm,ocotp-size = <2048>;
-};
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.yaml b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.yaml
new file mode 100644
index 000000000000..ffad28417488
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/brcm,ocotp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom OTP memory controller
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+properties:
+ compatible:
+ enum:
+ - brcm,ocotp
+ - brcm,ocotp-v2
+
+ reg:
+ maxItems: 1
+
+ brcm,ocotp-size:
+ description: Amount of memory available, in 32-bit words
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - brcm,ocotp-size
+
+additionalProperties: false
+
+examples:
+ - |
+ otp@301c800 {
+ compatible = "brcm,ocotp";
+ reg = <0x0301c800 0x2c>;
+ brcm,ocotp-size = <2048>;
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
index 3b4e6e94cb81..1b20b49eee79 100644
--- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
@@ -14,7 +14,8 @@ description: |
unique identifier per part.
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml
index 682688299b26..f0a49283649d 100644
--- a/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/nvmem/fsl,scu-ocotp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - OCOTP bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - OCOTP Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
new file mode 100644
index 000000000000..df826b40d8ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP QorIQ eFuse support
+
+maintainers:
+ - Richard Alpe <richard@bit42.se>
+
+description:
+ Read support for the eFuses (SFP) on NXP QorIQ series SoC's.
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ const: fsl,t1023-sfp
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ efuse@e8000 {
+ compatible = "fsl,t1023-sfp";
+ reg = <0xe8000 0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,vf610-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,vf610-ocotp.yaml
new file mode 100644
index 000000000000..5aef86a752a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/fsl,vf610-ocotp.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/fsl,vf610-ocotp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: On-Chip OTP Memory for Freescale Vybrid
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,vf610-ocotp
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ipg clock we associate with the OCOTP peripheral
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/vf610-clock.h>
+
+ ocotp@400a5000 {
+ compatible = "fsl,vf610-ocotp", "syscon";
+ reg = <0x400a5000 0xcf0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&clks VF610_CLK_OCOTP>;
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/imx-iim.yaml b/Documentation/devicetree/bindings/nvmem/imx-iim.yaml
index 9cc43e7a4b38..bb37d72c9eaa 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-iim.yaml
+++ b/Documentation/devicetree/bindings/nvmem/imx-iim.yaml
@@ -4,17 +4,19 @@
$id: http://devicetree.org/schemas/nvmem/imx-iim.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX IC Identification Module (IIM) device tree bindings
+title: Freescale i.MX IC Identification Module (IIM)
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
description: |
This binding represents the IC Identification Module (IIM) found on
i.MX25, i.MX27, i.MX31, i.MX35, i.MX51 and i.MX53 SoCs.
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
index 8a43dc1283fe..a8076d0e2737 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
@@ -4,18 +4,22 @@
$id: http://devicetree.org/schemas/nvmem/imx-ocotp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
+title: Freescale i.MX On-Chip OTP Controller (OCOTP)
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
description: |
This binding represents the on-chip eFuse OTP controller found on
i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL,
- i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN and i.MX8MP SoCs.
+ i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN i.MX8MP, i.MX93, i.MX94,
+ and i.MX95.
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
@@ -32,6 +36,9 @@ properties:
- fsl,imx7ulp-ocotp
- fsl,imx8mq-ocotp
- fsl,imx8mm-ocotp
+ - fsl,imx93-ocotp
+ - fsl,imx94-ocotp
+ - fsl,imx95-ocotp
- const: syscon
- items:
- enum:
@@ -46,12 +53,6 @@ properties:
reg:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
clocks:
maxItems: 1
@@ -61,21 +62,6 @@ required:
- compatible
- reg
-patternProperties:
- "^.*@[0-9a-f]+$":
- type: object
-
- properties:
- reg:
- maxItems: 1
- description:
- Offset and size in bytes within the storage device.
-
- required:
- - reg
-
- additionalProperties: false
-
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml
index bf84768228f5..e89fd879c968 100644
--- a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/nvmem/ingenic,jz4780-efuse.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic JZ EFUSE driver bindings
+title: Ingenic JZ EFUSE driver
maintainers:
- PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
new file mode 100644
index 000000000000..38e3ad50ff4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/fixed-cell.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fixed offset & size NVMEM cell
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: mac-base
+ description: >
+ Cell with base MAC address to be used for calculating extra relative
+ addresses.
+ It can be stored in a plain binary format (cell length 6) or as an
+ ASCII text like "00:11:22:33:44:55" (cell length 17).
+
+ reg:
+ maxItems: 1
+
+ bits:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - minimum: 0
+ maximum: 31
+ description:
+ Offset in bit within the address range specified by reg.
+ - minimum: 1
+ description:
+ Size in bit within the address range specified by reg.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mac-base
+ required: [ compatible ]
+ then:
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+ required:
+ - "#nvmem-cell-cells"
+
+required:
+ - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
new file mode 100644
index 000000000000..b01567f99284
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-layout.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/fixed-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout for fixed NVMEM cells
+
+description:
+ Many NVMEM devices have hardcoded cells layout (offset and size of defined
+ NVMEM content doesn't change).
+
+ This binding allows defining such NVMEM layout with its cells. It can be used
+ on top of any NVMEM device.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ const: fixed-layout
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+patternProperties:
+ "@[a-f0-9]+(,[0-7])?$":
+ type: object
+ $ref: fixed-cell.yaml
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac@100 {
+ compatible = "mac-base";
+ reg = <0x100 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ mac@110 {
+ compatible = "mac-base";
+ reg = <0x110 0x11>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ calibration@4000 {
+ reg = <0x4000 0x100>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
new file mode 100644
index 000000000000..afd1919c6b1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the Kontron SMARC-sAL28 vital product data
+
+maintainers:
+ - Michael Walle <michael@walle.cc>
+
+description:
+ The vital product data (VPD) of the sl28 boards contains a serial
+ number and a base MAC address. The actual MAC addresses for the
+ on-board ethernet devices are derived from this base MAC address by
+ adding an offset.
+
+select: false
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - kontron,sa67-vpd
+ - const: kontron,sl28-vpd
+ - const: kontron,sl28-vpd
+
+ serial-number:
+ type: object
+ description: The board's serial number
+
+ additionalProperties: false
+
+ base-mac-address:
+ type: object
+ description:
+ Base MAC address for all on-module network interfaces. The first
+ argument of the phandle will be treated as an offset.
+
+ properties:
+ "#nvmem-cell-cells":
+ const: 1
+
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ otp-1 {
+ compatible = "user-otp";
+
+ nvmem-layout {
+ compatible = "kontron,sl28-vpd";
+
+ serial_number: serial-number {
+ };
+
+ base_mac_address: base-mac-address {
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
new file mode 100644
index 000000000000..382507060651
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/nvmem-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM (Non Volatile Memory) layouts
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ - Michael Walle <michael@walle.cc>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: |
+ Most NVMEM layouts are static and thus do not require additional description
+ besides the bytes/bits offset and length. Other layouts can be less statically
+ define and might require dynamic reading of the NVMEM device in order to
+ perform their parsing. The nvmem-layout container is here to describe these.
+
+oneOf:
+ - $ref: fixed-layout.yaml
+ - $ref: kontron,sl28-vpd.yaml
+ - $ref: onie,tlv-layout.yaml
+ - $ref: u-boot,env.yaml
+
+properties:
+ compatible: true
+
+required:
+ - compatible
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
new file mode 100644
index 000000000000..ee8ac322332d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/onie,tlv-layout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the ONIE tlv table
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description:
+ Modern networking hardware implementing the Open Compute Project ONIE
+ infrastructure shall provide a non-volatile memory with a table whose the
+ content is well specified and gives many information about the manufacturer
+ (name, country of manufacture, etc) as well as device caracteristics (serial
+ number, hardware version, mac addresses, etc). The underlying device type
+ (flash, EEPROM,...) is not specified. The exact location of each value is also
+ dynamic and should be discovered at run time because it depends on the
+ parameters the manufacturer decided to embed.
+
+select: false
+
+properties:
+ compatible:
+ const: onie,tlv-layout
+
+ product-name:
+ type: object
+ additionalProperties: false
+
+ part-number:
+ type: object
+ additionalProperties: false
+
+ serial-number:
+ type: object
+ additionalProperties: false
+
+ mac-address:
+ type: object
+ description:
+ Base MAC address for all on-module network interfaces. The first
+ argument of the phandle will be treated as an offset.
+
+ properties:
+ "#nvmem-cell-cells":
+ const: 1
+
+ additionalProperties: false
+
+ manufacture-date:
+ type: object
+ additionalProperties: false
+
+ device-version:
+ type: object
+ additionalProperties: false
+
+ label-revision:
+ type: object
+ additionalProperties: false
+
+ platform-name:
+ type: object
+ additionalProperties: false
+
+ onie-version:
+ type: object
+ additionalProperties: false
+
+ num-macs:
+ type: object
+ additionalProperties: false
+
+ manufacturer:
+ type: object
+ additionalProperties: false
+
+ country-code:
+ type: object
+ additionalProperties: false
+
+ vendor:
+ type: object
+ additionalProperties: false
+
+ diag-version:
+ type: object
+ additionalProperties: false
+
+ service-tag:
+ type: object
+ additionalProperties: false
+
+ vendor-extension:
+ type: object
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ read-only;
+ reg = <0x56>;
+
+ nvmem-layout {
+ compatible = "onie,tlv-layout";
+
+ serial-number {
+ };
+ };
+ };
+ };
+
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "m25p80", "jedec,spi-nor";
+ reg = <0>;
+
+ otp {
+ compatible = "user-otp";
+
+ nvmem-layout {
+ compatible = "onie,tlv-layout";
+
+ mac-address {
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
new file mode 100644
index 000000000000..e9e75c38bd11
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/u-boot,env.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/u-boot,env.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-Boot environment variables layout
+
+description: |
+ U-Boot uses environment variables to store device parameters and
+ configuration. They may be used for booting process, setup or keeping end user
+ info.
+
+ Data is stored using U-Boot specific formats (variant specific header and NUL
+ separated key-value pairs).
+
+ Environment data can be stored on various storage entities, e.g.:
+ 1. Raw flash partition
+ 2. UBI volume
+
+ This binding allows marking storage device (as containing env data) and
+ specifying used format.
+
+ Variables can be defined as NVMEM device subnodes.
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ oneOf:
+ - description: A standalone env data block
+ const: u-boot,env
+ - description: Two redundant blocks with active one flagged
+ const: u-boot,env-redundant-bool
+ - description: Two redundant blocks with active having higher counter
+ const: u-boot,env-redundant-count
+ - description: Broadcom's variant with custom header
+ const: brcm,env
+
+ reg:
+ description: Partition offset and size for env on top of MTD
+ maxItems: 1
+
+ bootcmd:
+ type: object
+ description: Command to use for automatic booting
+
+ env-size:
+ description:
+ Size in bytes of the environment data used by U-Boot for CRC
+ calculation. If omitted, the full NVMEM region size is used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ethaddr:
+ type: object
+ description: Ethernet interfaces base MAC address.
+ additionalProperties: false
+
+ properties:
+ "#nvmem-cell-cells":
+ description: The first argument is a MAC address offset.
+ const: 1
+
+allOf:
+ - if:
+ properties:
+ $nodename:
+ not:
+ contains:
+ pattern: "^partition@[0-9a-f]+$"
+ then:
+ properties:
+ reg: false
+
+additionalProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ reg = <0x0 0x40000>;
+ label = "u-boot";
+ read-only;
+ };
+
+ env: partition@40000 {
+ compatible = "u-boot,env";
+ reg = <0x40000 0x10000>;
+
+ mac: ethaddr {
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ reg = <0x0 0x100000>;
+ compatible = "brcm,u-boot";
+ label = "u-boot";
+
+ partition-u-boot-env {
+ compatible = "brcm,env";
+ env-size = <0x20000>;
+
+ ethaddr {
+ };
+ };
+ };
+ };
+ - |
+ partition@0 {
+ reg = <0x0 0x100000>;
+ label = "ubi";
+ compatible = "linux,ubi";
+
+ volumes {
+ ubi-volume-u-boot-env {
+ volname = "env";
+
+ nvmem-layout {
+ compatible = "u-boot,env";
+
+ ethaddr {
+ #nvmem-cell-cells = <1>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt b/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
deleted file mode 100644
index 809df68f6e14..000000000000
--- a/Documentation/devicetree/bindings/nvmem/lpc1857-eeprom.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* NXP LPC18xx EEPROM memory NVMEM driver
-
-Required properties:
- - compatible: Should be "nxp,lpc1857-eeprom"
- - reg: Must contain an entry with the physical base address and length
- for each entry in reg-names.
- - reg-names: Must include the following entries.
- - reg: EEPROM registers.
- - mem: EEPROM address space.
- - clocks: Must contain an entry for each entry in clock-names.
- - clock-names: Must include the following entries.
- - eeprom: EEPROM operating clock.
- - resets: Should contain a reference to the reset controller asserting
- the EEPROM in reset.
- - interrupts: Should contain EEPROM interrupt.
-
-Example:
-
- eeprom: eeprom@4000e000 {
- compatible = "nxp,lpc1857-eeprom";
- reg = <0x4000e000 0x1000>,
- <0x20040000 0x4000>;
- reg-names = "reg", "mem";
- clocks = <&ccu1 CLK_CPU_EEPROM>;
- clock-names = "eeprom";
- resets = <&rgu 27>;
- interrupts = <4>;
- };
diff --git a/Documentation/devicetree/bindings/nvmem/maxim,max77759-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/maxim,max77759-nvmem.yaml
new file mode 100644
index 000000000000..1e3bd4433007
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/maxim,max77759-nvmem.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/maxim,max77759-nvmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX77759 Non Volatile Memory
+
+maintainers:
+ - André Draszik <andre.draszik@linaro.org>
+
+description: |
+ This module is part of the MAX77759 PMIC. For additional information, see
+ Documentation/devicetree/bindings/mfd/maxim,max77759.yaml.
+
+ The MAX77759 is a PMIC integrating, amongst others, Non Volatile Memory
+ (NVMEM) with 30 bytes of storage which can be used by software to store
+ information or communicate with a boot loader.
+
+properties:
+ compatible:
+ const: maxim,max77759-nvmem
+
+ wp-gpios: false
+
+required:
+ - compatible
+
+allOf:
+ - $ref: nvmem.yaml#
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
index b5a1109f2ee1..c9bf34ee0efb 100644
--- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
@@ -15,7 +15,8 @@ maintainers:
- Lala Lin <lala.lin@mediatek.com>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
$nodename:
@@ -25,11 +26,31 @@ properties:
oneOf:
- items:
- enum:
+ - mediatek,mt8188-efuse
+ - mediatek,mt8189-efuse
+ - const: mediatek,mt8186-efuse
+ - const: mediatek,mt8186-efuse
+
+ - items:
+ - enum:
+ - mediatek,mt8186-efuse
+ - mediatek,mt8188-efuse
+ - const: mediatek,efuse
+ deprecated: true
+ description: Some compatibles also imply a decoding scheme for the
+ "gpu-speedbin" cell, and thus are not backward compatible to the
+ generic "mediatek,efuse" compatible.
+
+ - items:
+ - enum:
- mediatek,mt7622-efuse
- mediatek,mt7623-efuse
+ - mediatek,mt7981-efuse
+ - mediatek,mt7986-efuse
+ - mediatek,mt7988-efuse
- mediatek,mt8173-efuse
- mediatek,mt8183-efuse
- - mediatek,mt8186-efuse
+ - mediatek,mt8189-efuse
- mediatek,mt8192-efuse
- mediatek,mt8195-efuse
- mediatek,mt8516-efuse
diff --git a/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
new file mode 100644
index 000000000000..f97c6beb4766
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/microchip,lan9662-otpc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/microchip,lan9662-otpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN9662 OTP Controller (OTPC)
+
+maintainers:
+ - Horatiu Vultur <horatiu.vultur@microchip.com>
+
+description: |
+ OTP controller drives a NVMEM memory where system specific data
+ (e.g. hardware configuration settings, chip identifiers) or
+ user specific data could be stored.
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: microchip,lan9668-otpc
+ - const: microchip,lan9662-otpc
+ - enum:
+ - microchip,lan9662-otpc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ otpc: otp@e0021000 {
+ compatible = "microchip,lan9662-otpc";
+ reg = <0xe0021000 0x300>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
index c3c96fd0baac..cc25f2927682 100644
--- a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
+++ b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
@@ -15,7 +15,8 @@ description: |
settings, chip identifiers) or user specific data could be stored.
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
index ff317fd7c15b..95121dd6311c 100644
--- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml
@@ -7,22 +7,21 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: On-Chip OTP Memory for Freescale i.MX23/i.MX28
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
- enum:
- - fsl,imx23-ocotp
- - fsl,imx28-ocotp
-
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
+ items:
+ - enum:
+ - fsl,imx23-ocotp
+ - fsl,imx28-ocotp
+ - const: fsl,ocotp
reg:
maxItems: 1
@@ -35,12 +34,12 @@ required:
- reg
- clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
ocotp: efuse@8002c000 {
- compatible = "fsl,imx28-ocotp";
+ compatible = "fsl,imx28-ocotp", "fsl,ocotp";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x8002c000 0x2000>;
diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
index dbe4ffdd644c..6c26800f8b79 100644
--- a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/nvmem/nintendo-otp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Nintendo Wii and Wii U OTP Device Tree Bindings
+title: Nintendo Wii and Wii U OTP
description: |
This binding represents the OTP memory as found on a Nintendo Wii or Wii U,
@@ -17,7 +17,7 @@ maintainers:
- Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml b/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
index b1da238c8bcb..a26633bf52db 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/nvmem/nvmem-consumer.yaml#
$schema: http://devicetree.org/meta-schemas/base.yaml#
-title: NVMEM (Non Volatile Memory) Consumer Device Tree Bindings
+title: NVMEM (Non Volatile Memory) Consumer
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem-deprecated-cells.yaml b/Documentation/devicetree/bindings/nvmem/nvmem-deprecated-cells.yaml
new file mode 100644
index 000000000000..951af28bbfb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nvmem-deprecated-cells.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/nvmem-deprecated-cells.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM old syntax for fixed cells
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Before introducing NVMEM layouts all NVMEM (fixed) cells were defined
+ as direct device subnodes. That syntax was replaced by "fixed-layout"
+ and is deprecated now. No new bindings should use it.
+
+patternProperties:
+ "@[0-9a-f]+(,[0-7])?$":
+ type: object
+ allOf:
+ - $ref: layouts/fixed-cell.yaml
+ - properties:
+ compatible: false
+ deprecated: true
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem-provider.yaml b/Documentation/devicetree/bindings/nvmem/nvmem-provider.yaml
new file mode 100644
index 000000000000..4009a9a03841
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nvmem-provider.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/nvmem-provider.yaml#
+$schema: http://devicetree.org/meta-schemas/base.yaml#
+
+title: NVMEM (Non Volatile Memory) Provider
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+select: true
+
+properties:
+ '#nvmem-cell-cells':
+ enum: [0, 1]
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 3bb349c634cb..4fd015d402ce 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/nvmem/nvmem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVMEM (Non Volatile Memory) Device Tree Bindings
+title: NVMEM (Non Volatile Memory)
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -39,26 +39,12 @@ properties:
when it's driven low (logical '0') to allow writing.
maxItems: 1
-patternProperties:
- "@[0-9a-f]+(,[0-7])?$":
- type: object
-
- properties:
- reg:
- maxItems: 1
- description:
- Offset and size in bytes within the storage device.
-
- bits:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- - minimum: 0
- maximum: 7
- description:
- Offset in bit within the address range specified by reg.
- - minimum: 1
- description:
- Size in bit within the address range specified by reg.
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+ description:
+ Alternative to the statically defined nvmem cells, this
+ container may reference more advanced (dynamic) layout
+ parsers.
additionalProperties: true
@@ -67,6 +53,7 @@ examples:
#include <dt-bindings/gpio/gpio.h>
qfprom: eeprom@700000 {
+ compatible = "qcom,msm8974-qfprom", "qcom,qfprom";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x00700000 0x100000>;
@@ -75,24 +62,30 @@ examples:
/* ... */
- /* Data cells */
- tsens_calibration: calib@404 {
- reg = <0x404 0x10>;
- };
-
- tsens_calibration_bckp: calib_bckp@504 {
- reg = <0x504 0x11>;
- bits = <6 128>;
- };
-
- pvs_version: pvs-version@6 {
- reg = <0x6 0x2>;
- bits = <7 2>;
- };
-
- speed_bin: speed-bin@c{
- reg = <0xc 0x1>;
- bits = <2 3>;
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
+
+ tsens_calibration_bckp: calib_bckp@504 {
+ reg = <0x504 0x11>;
+ bits = <6 128>;
+ };
+
+ pvs_version: pvs-version@6 {
+ reg = <0x6 0x2>;
+ bits = <7 2>;
+ };
+
+ speed_bin: speed-bin@c{
+ reg = <0xc 0x1>;
+ bits = <2 3>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/nvmem/nxp,lpc1857-eeprom.yaml b/Documentation/devicetree/bindings/nvmem/nxp,lpc1857-eeprom.yaml
new file mode 100644
index 000000000000..24c71252846f
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nxp,lpc1857-eeprom.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/nxp,lpc1857-eeprom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC18xx EEPROM memory
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1857-eeprom
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: reg
+ - const: mem
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: eeprom
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ eeprom@4000e000 {
+ compatible = "nxp,lpc1857-eeprom";
+ reg = <0x4000e000 0x1000>,
+ <0x20040000 0x4000>;
+ reg-names = "reg", "mem";
+ clocks = <&ccu1 CLK_CPU_EEPROM>;
+ clock-names = "eeprom";
+ resets = <&rgu 27>;
+ interrupts = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/nxp,s32g-ocotp-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nxp,s32g-ocotp-nvmem.yaml
new file mode 100644
index 000000000000..8d46e7d28da6
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nxp,s32g-ocotp-nvmem.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/nxp,s32g-ocotp-nvmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP S32G OCOTP NVMEM driver
+
+maintainers:
+ - Ciprian Costea <ciprianmarian.costea@nxp.com>
+
+description:
+ The drivers provides an interface to access One Time
+ Programmable memory pages, such as TMU fuse values.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nxp,s32g2-ocotp
+ - items:
+ - enum:
+ - nxp,s32g3-ocotp
+ - nxp,s32r45-ocotp
+ - const: nxp,s32g2-ocotp
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: nvmem.yaml#
+
+examples:
+ - |
+ nvmem@400a4000 {
+ compatible = "nxp,s32g2-ocotp";
+ reg = <0x400a4000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index dede8892ee01..7d1612acca48 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -4,13 +4,14 @@
$id: http://devicetree.org/schemas/nvmem/qcom,qfprom.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies Inc, QFPROM Efuse bindings
+title: Qualcomm Technologies Inc, QFPROM Efuse
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
@@ -18,14 +19,43 @@ properties:
- enum:
- qcom,apq8064-qfprom
- qcom,apq8084-qfprom
- - qcom,msm8974-qfprom
+ - qcom,ipq5018-qfprom
+ - qcom,ipq5332-qfprom
+ - qcom,ipq5424-qfprom
+ - qcom,ipq6018-qfprom
+ - qcom,ipq8064-qfprom
+ - qcom,ipq8074-qfprom
+ - qcom,ipq9574-qfprom
+ - qcom,msm8226-qfprom
- qcom,msm8916-qfprom
+ - qcom,msm8917-qfprom
+ - qcom,msm8937-qfprom
+ - qcom,msm8960-qfprom
+ - qcom,msm8974-qfprom
+ - qcom,msm8976-qfprom
- qcom,msm8996-qfprom
- qcom,msm8998-qfprom
+ - qcom,qcm2290-qfprom
- qcom,qcs404-qfprom
+ - qcom,qcs615-qfprom
+ - qcom,qcs8300-qfprom
+ - qcom,sa8775p-qfprom
+ - qcom,sar2130p-qfprom
- qcom,sc7180-qfprom
- qcom,sc7280-qfprom
+ - qcom,sc8280xp-qfprom
+ - qcom,sdm630-qfprom
+ - qcom,sdm670-qfprom
- qcom,sdm845-qfprom
+ - qcom,sm6115-qfprom
+ - qcom,sm6350-qfprom
+ - qcom,sm6375-qfprom
+ - qcom,sm8150-qfprom
+ - qcom,sm8250-qfprom
+ - qcom,sm8450-qfprom
+ - qcom,sm8550-qfprom
+ - qcom,sm8650-qfprom
+ - qcom,x1e80100-qfprom
- const: qcom,qfprom
reg:
@@ -54,12 +84,6 @@ properties:
power-domains:
maxItems: 1
- # Needed if any child nodes are present.
- "#address-cells":
- const: 1
- "#size-cells":
- const: 1
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml
new file mode 100644
index 000000000000..2ada2099946d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/qcom,sec-qfprom.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/qcom,sec-qfprom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies Inc, Secure QFPROM Efuse
+
+maintainers:
+ - Komal Bajaj <quic_kbajaj@quicinc.com>
+
+description:
+ For some of the Qualcomm SoC's, it is possible that the qfprom region is
+ protected from non-secure access. In such situations, the OS have to use
+ secure calls to read the region.
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,qdu1000-sec-qfprom
+ - const: qcom,sec-qfprom
+
+ reg:
+ items:
+ - description: The secure qfprom corrected region.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ efuse@221c8000 {
+ compatible = "qcom,qdu1000-sec-qfprom", "qcom,sec-qfprom";
+ reg = <0 0x221c8000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ multi_chan_ddr: multi-chan-ddr@12b {
+ reg = <0x12b 0x1>;
+ bits = <0 2>;
+ };
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml
index ee79e13b5fe0..5d7be0b34536 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/nvmem/qcom,spmi-sdam.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. SPMI SDAM DT bindings
+title: Qualcomm Technologies, Inc. SPMI SDAM
maintainers:
- - Shyam Kumar Thella <sthella@codeaurora.org>
+ - David Collins <quic_collinsd@quicinc.com>
description: |
The SDAM provides scratch register space for the PMIC clients. This
@@ -15,7 +15,8 @@ description: |
to/from the PBUS.
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
@@ -25,12 +26,6 @@ properties:
reg:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
ranges: true
required:
@@ -42,17 +37,22 @@ unevaluatedProperties: false
examples:
- |
- sdam_1: nvram@b000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,spmi-sdam";
- reg = <0xb000 0x100>;
- ranges = <0 0xb000 0x100>;
-
- /* Data cells */
- restart_reason: restart@50 {
- reg = <0x50 0x1>;
- bits = <6 2>;
- };
- };
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sdam_1: nvram@b000 {
+ compatible = "qcom,spmi-sdam";
+ reg = <0xb000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xb000 0x100>;
+
+ /* Data cells */
+ restart_reason: restart@50 {
+ reg = <0x50 0x1>;
+ bits = <6 2>;
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/nvmem/renesas,rcar-efuse.yaml b/Documentation/devicetree/bindings/nvmem/renesas,rcar-efuse.yaml
new file mode 100644
index 000000000000..ce7d65afa460
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/renesas,rcar-efuse.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/renesas,rcar-efuse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: R-Car E-FUSE connected to PFC
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+description:
+ The E-FUSE is a type of non-volatile memory, which is accessible through the
+ Pin Function Controller (PFC) on some R-Car Gen4 SoCs.
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ enum:
+ - renesas,r8a779a0-efuse # R-Car V3U
+ - renesas,r8a779f0-efuse # R-Car S4-8
+
+ reg:
+ maxItems: 1
+ description: PFC System Group Fuse Control and Monitor register block
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ fuse@e6078800 {
+ compatible = "renesas,r8a779f0-efuse";
+ reg = <0xe6078800 0x200>;
+ clocks = <&cpg CPG_MOD 915>;
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 915>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ calib@144 {
+ reg = <0x144 0x08>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/renesas,rcar-otp.yaml b/Documentation/devicetree/bindings/nvmem/renesas,rcar-otp.yaml
new file mode 100644
index 000000000000..3313c03ea68d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/renesas,rcar-otp.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/renesas,rcar-otp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: R-Car E-FUSE connected to OTP_MEM
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+description:
+ The E-FUSE is a type of non-volatile memory, which is accessible through the
+ One-Time Programmable Memory (OTP_MEM) module on some R-Car Gen4 SoCs.
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ enum:
+ - renesas,r8a779g0-otp # R-CarV4H
+ - renesas,r8a779h0-otp # R-CarV4M
+
+ reg:
+ items:
+ - description: OTP_MEM_0
+ - description: OTP_MEM_1.
+ The addresses of cells defined under the optional nvmem-layout
+ subnode are relative to this register bank.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ otp@e61be000 {
+ compatible = "renesas,r8a779g0-otp";
+ reg = <0xe61be000 0x1000>, <0xe61bf000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml
index a4a755dcfc43..85f9f5de3906 100644
--- a/Documentation/devicetree/bindings/nvmem/rmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml
@@ -10,13 +10,15 @@ maintainers:
- Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
properties:
compatible:
items:
- enum:
+ - mobileye,eyeq5-bootloader-config
- raspberrypi,bootloader-config
+ - raspberrypi,bootloader-public-key
- const: nvmem-rmem
reg:
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
new file mode 100644
index 000000000000..dc89020b0950
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/rockchip,otp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip internal OTP (One Time Programmable) memory
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,px30-otp
+ - rockchip,rk3308-otp
+ - rockchip,rk3576-otp
+ - rockchip,rk3588-otp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 4
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: otp
+ - const: apb_pclk
+ - const: phy
+ - const: arb
+
+ resets:
+ minItems: 1
+ maxItems: 3
+
+ reset-names:
+ minItems: 1
+ maxItems: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-otp
+ - rockchip,rk3308-otp
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ maxItems: 3
+ resets:
+ maxItems: 1
+ reset-names:
+ items:
+ - const: phy
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-otp
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ maxItems: 3
+ resets:
+ minItems: 2
+ maxItems: 2
+ reset-names:
+ items:
+ - const: otp
+ - const: apb
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3588-otp
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+ resets:
+ minItems: 3
+ reset-names:
+ items:
+ - const: otp
+ - const: apb
+ - const: arb
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/px30-cru.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ otp: efuse@ff290000 {
+ compatible = "rockchip,px30-otp";
+ reg = <0x0 0xff290000 0x0 0x4000>;
+ clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>,
+ <&cru PCLK_OTP_PHY>;
+ clock-names = "otp", "apb_pclk", "phy";
+ resets = <&cru SRST_OTP_PHY>;
+ reset-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpu_id: id@7 {
+ reg = <0x07 0x10>;
+ };
+
+ cpu_leakage: cpu-leakage@17 {
+ reg = <0x17 0x1>;
+ };
+
+ performance: performance@1e {
+ reg = <0x1e 0x1>;
+ bits = <4 3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
index 104dd508565e..b80fd8d1ae5b 100644
--- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
@@ -4,13 +4,14 @@
$id: http://devicetree.org/schemas/nvmem/rockchip-efuse.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip eFuse device tree bindings
+title: Rockchip eFuse
maintainers:
- Heiko Stuebner <heiko@sntech.de>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt b/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt
deleted file mode 100644
index 40f649f7c2e5..000000000000
--- a/Documentation/devicetree/bindings/nvmem/rockchip-otp.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Rockchip internal OTP (One Time Programmable) memory device tree bindings
-
-Required properties:
-- compatible: Should be one of the following.
- - "rockchip,px30-otp" - for PX30 SoCs.
- - "rockchip,rk3308-otp" - for RK3308 SoCs.
-- reg: Should contain the registers location and size
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Should be "otp", "apb_pclk" and "phy".
-- resets: Must contain an entry for each entry in reset-names.
- See ../../reset/reset.txt for details.
-- reset-names: Should be "phy".
-
-See nvmem.txt for more information.
-
-Example:
- otp: otp@ff290000 {
- compatible = "rockchip,px30-otp";
- reg = <0x0 0xff290000 0x0 0x4000>;
- #address-cells = <1>;
- #size-cells = <1>;
- clocks = <&cru SCLK_OTP_USR>, <&cru PCLK_OTP_NS>,
- <&cru PCLK_OTP_PHY>;
- clock-names = "otp", "apb_pclk", "phy";
- };
diff --git a/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt b/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
deleted file mode 100644
index 586c08286aa9..000000000000
--- a/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-= Spreadtrum SC27XX PMIC eFuse device tree bindings =
-
-Required properties:
-- compatible: Should be one of the following.
- "sprd,sc2720-efuse"
- "sprd,sc2721-efuse"
- "sprd,sc2723-efuse"
- "sprd,sc2730-efuse"
- "sprd,sc2731-efuse"
-- reg: Specify the address offset of efuse controller.
-- hwlocks: Reference to a phandle of a hwlock provider node.
-
-= Data cells =
-Are child nodes of eFuse, bindings of which as described in
-bindings/nvmem/nvmem.txt
-
-Example:
-
- sc2731_pmic: pmic@0 {
- compatible = "sprd,sc2731";
- reg = <0>;
- spi-max-frequency = <26000000>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- efuse@380 {
- compatible = "sprd,sc2731-efuse";
- reg = <0x380>;
- #address-cells = <1>;
- #size-cells = <1>;
- hwlocks = <&hwlock 12>;
-
- /* Data cells */
- thermal_calib: calib@10 {
- reg = <0x10 0x2>;
- };
- };
- };
-
-= Data consumers =
-Are device nodes which consume nvmem data cells.
-
-Example:
-
- thermal {
- ...
- nvmem-cells = <&thermal_calib>;
- nvmem-cell-names = "calibration";
- };
diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml
index e374aa7891ae..ec20e33d9b8f 100644
--- a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.yaml
@@ -11,14 +11,18 @@ maintainers:
properties:
compatible:
- enum:
- - fsl,imx6q-snvs-lpgpr
- - fsl,imx6ul-snvs-lpgpr
- - fsl,imx7d-snvs-lpgpr
- - fsl,imx8mm-snvs-lpgpr
- - fsl,imx8mn-snvs-lpgpr
- - fsl,imx8mp-snvs-lpgpr
- - fsl,imx8mq-snvs-lpgpr
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx8mm-snvs-lpgpr
+ - fsl,imx8mn-snvs-lpgpr
+ - fsl,imx8mp-snvs-lpgpr
+ - fsl,imx8mq-snvs-lpgpr
+ - const: fsl,imx7d-snvs-lpgpr
+ - enum:
+ - fsl,imx6q-snvs-lpgpr
+ - fsl,imx6ul-snvs-lpgpr
+ - fsl,imx7d-snvs-lpgpr
required:
- compatible
diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
index 2578e39deda9..e27cbae2d63a 100644
--- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
@@ -4,19 +4,17 @@
$id: http://devicetree.org/schemas/nvmem/socionext,uniphier-efuse.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Socionext UniPhier eFuse bindings
+title: Socionext UniPhier eFuse
maintainers:
- Keiji Hayashibara <hayashibara.keiji@socionext.com>
- Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
const: socionext,uniphier-efuse
@@ -31,65 +29,56 @@ unevaluatedProperties: false
examples:
- |
- // The UniPhier eFuse should be a subnode of a "soc-glue" node.
+ efuse@100 {
+ compatible = "socionext,uniphier-efuse";
+ reg = <0x100 0x28>;
+ };
- soc-glue@5f900000 {
- compatible = "simple-mfd";
+ efuse@200 {
+ compatible = "socionext,uniphier-efuse";
+ reg = <0x200 0x68>;
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x5f900000 0x2000>;
- efuse@100 {
- compatible = "socionext,uniphier-efuse";
- reg = <0x100 0x28>;
+ /* Data cells */
+ usb_rterm0: trim@54,4 {
+ reg = <0x54 1>;
+ bits = <4 2>;
};
-
- efuse@200 {
- compatible = "socionext,uniphier-efuse";
- reg = <0x200 0x68>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- /* Data cells */
- usb_rterm0: trim@54,4 {
- reg = <0x54 1>;
- bits = <4 2>;
- };
- usb_rterm1: trim@55,4 {
- reg = <0x55 1>;
- bits = <4 2>;
- };
- usb_rterm2: trim@58,4 {
- reg = <0x58 1>;
- bits = <4 2>;
- };
- usb_rterm3: trim@59,4 {
- reg = <0x59 1>;
- bits = <4 2>;
- };
- usb_sel_t0: trim@54,0 {
- reg = <0x54 1>;
- bits = <0 4>;
- };
- usb_sel_t1: trim@55,0 {
- reg = <0x55 1>;
- bits = <0 4>;
- };
- usb_sel_t2: trim@58,0 {
- reg = <0x58 1>;
- bits = <0 4>;
- };
- usb_sel_t3: trim@59,0 {
- reg = <0x59 1>;
- bits = <0 4>;
- };
- usb_hs_i0: trim@56,0 {
- reg = <0x56 1>;
- bits = <0 4>;
- };
- usb_hs_i2: trim@5a,0 {
- reg = <0x5a 1>;
- bits = <0 4>;
- };
+ usb_rterm1: trim@55,4 {
+ reg = <0x55 1>;
+ bits = <4 2>;
+ };
+ usb_rterm2: trim@58,4 {
+ reg = <0x58 1>;
+ bits = <4 2>;
+ };
+ usb_rterm3: trim@59,4 {
+ reg = <0x59 1>;
+ bits = <4 2>;
+ };
+ usb_sel_t0: trim@54,0 {
+ reg = <0x54 1>;
+ bits = <0 4>;
+ };
+ usb_sel_t1: trim@55,0 {
+ reg = <0x55 1>;
+ bits = <0 4>;
+ };
+ usb_sel_t2: trim@58,0 {
+ reg = <0x58 1>;
+ bits = <0 4>;
+ };
+ usb_sel_t3: trim@59,0 {
+ reg = <0x59 1>;
+ bits = <0 4>;
+ };
+ usb_hs_i0: trim@56,0 {
+ reg = <0x56 1>;
+ bits = <0 4>;
+ };
+ usb_hs_i2: trim@5a,0 {
+ reg = <0x5a 1>;
+ bits = <0 4>;
};
};
diff --git a/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml b/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml
new file mode 100644
index 000000000000..8672bde24a9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/sprd,sc2731-efuse.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/sprd,sc2731-efuse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC27XX PMIC eFuse
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - sprd,sc2720-efuse
+ - sprd,sc2721-efuse
+ - sprd,sc2723-efuse
+ - sprd,sc2730-efuse
+ - sprd,sc2731-efuse
+
+ reg:
+ maxItems: 1
+
+ hwlocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - hwlocks
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+unevaluatedProperties: false
+...
diff --git a/Documentation/devicetree/bindings/nvmem/sprd,ums312-efuse.yaml b/Documentation/devicetree/bindings/nvmem/sprd,ums312-efuse.yaml
new file mode 100644
index 000000000000..00e0fd1353a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/sprd,ums312-efuse.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/sprd,ums312-efuse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum UMS312 eFuse
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,ums312-efuse
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: enable
+
+ hwlocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - hwlocks
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sprd,ums512-clk.h>
+
+ efuse@32240000 {
+ compatible = "sprd,ums312-efuse";
+ reg = <0x32240000 0x10000>;
+ clocks = <&aonapb_gate CLK_EFUSE_EB>;
+ clock-names = "enable";
+ hwlocks = <&hwlock 8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Data cells */
+ thermal_calib: calib@10 {
+ reg = <0x10 0x2>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/sprd-efuse.txt b/Documentation/devicetree/bindings/nvmem/sprd-efuse.txt
deleted file mode 100644
index 96b6feec27f0..000000000000
--- a/Documentation/devicetree/bindings/nvmem/sprd-efuse.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-= Spreadtrum eFuse device tree bindings =
-
-Required properties:
-- compatible: Should be "sprd,ums312-efuse".
-- reg: Specify the address offset of efuse controller.
-- clock-names: Should be "enable".
-- clocks: The phandle and specifier referencing the controller's clock.
-- hwlocks: Reference to a phandle of a hwlock provider node.
-
-= Data cells =
-Are child nodes of eFuse, bindings of which as described in
-bindings/nvmem/nvmem.txt
-
-Example:
-
- ap_efuse: efuse@32240000 {
- compatible = "sprd,ums312-efuse";
- reg = <0 0x32240000 0 0x10000>;
- clock-names = "enable";
- hwlocks = <&hwlock 8>;
- clocks = <&aonapb_gate CLK_EFUSE_EB>;
-
- /* Data cells */
- thermal_calib: calib@10 {
- reg = <0x10 0x2>;
- };
- };
-
-= Data consumers =
-Are device nodes which consume nvmem data cells.
-
-Example:
-
- thermal {
- ...
-
- nvmem-cells = <&thermal_calib>;
- nvmem-cell-names = "calibration";
- };
diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
index 448a2678dc62..ab4cdc4e3614 100644
--- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/nvmem/st,stm32-romem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Factory-programmed data bindings
+title: STMicroelectronics STM32 Factory-programmed data
description: |
This represents STM32 Factory-programmed read only non-volatile area: locked
@@ -16,20 +16,25 @@ maintainers:
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
enum:
- st,stm32f4-otp
+ - st,stm32mp13-bsec
- st,stm32mp15-bsec
+ - st,stm32mp25-bsec
reg:
maxItems: 1
patternProperties:
- "^.*@[0-9a-f]+$":
+ "@[0-9a-f]+$":
type: object
+ $ref: layouts/fixed-cell.yaml
+ unevaluatedProperties: false
properties:
st,non-secure-otp:
diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml
index a7644ebbc2ca..af97eeb8316c 100644
--- a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml
@@ -11,7 +11,8 @@ maintainers:
- Vincent Shih <vincent.sunplus@gmail.com>
allOf:
- - $ref: "nvmem.yaml#"
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
properties:
compatible:
@@ -28,12 +29,6 @@ properties:
clocks:
maxItems: 1
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 1
-
thermal-calibration:
type: object
description: thermal calibration values
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
deleted file mode 100644
index e70b2a60cb9a..000000000000
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ /dev/null
@@ -1,62 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: U-Boot environment variables
-
-description: |
- U-Boot uses environment variables to store device parameters and
- configuration. They may be used for booting process, setup or keeping end user
- info.
-
- Data is stored using U-Boot specific formats (variant specific header and NUL
- separated key-value pairs).
-
- Environment data can be stored on various storage entities, e.g.:
- 1. Raw flash partition
- 2. UBI volume
-
- This binding allows marking storage device (as containing env data) and
- specifying used format.
-
- Right now only flash partition case is covered but it may be extended to e.g.
- UBI volumes in the future.
-
-maintainers:
- - Rafał Miłecki <rafal@milecki.pl>
-
-properties:
- compatible:
- oneOf:
- - description: A standalone env data block
- const: u-boot,env
- - description: Two redundant blocks with active one flagged
- const: u-boot,env-redundant-bool
- - description: Two redundant blocks with active having higher counter
- const: u-boot,env-redundant-count
-
- reg:
- maxItems: 1
-
-additionalProperties: false
-
-examples:
- - |
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- reg = <0x0 0x40000>;
- label = "u-boot";
- read-only;
- };
-
- env: partition@40000 {
- compatible = "u-boot,env";
- reg = <0x40000 0x10000>;
- };
- };
diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
deleted file mode 100644
index 72ba628f6d0b..000000000000
--- a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-On-Chip OTP Memory for Freescale Vybrid
-
-Required Properties:
- compatible:
- - "fsl,vf610-ocotp", "syscon" for VF5xx/VF6xx
- #address-cells : Should be 1
- #size-cells : Should be 1
- reg : Address and length of OTP controller and fuse map registers
- clocks : ipg clock we associate with the OCOTP peripheral
-
-Example for Vybrid VF5xx/VF6xx:
-
- ocotp: ocotp@400a5000 {
- compatible = "fsl,vf610-ocotp", "syscon";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x400a5000 0xCF0>;
- clocks = <&clks VF610_CLK_OCOTP>;
- };
diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
deleted file mode 100644
index 4881561b3a02..000000000000
--- a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
+++ /dev/null
@@ -1,46 +0,0 @@
---------------------------------------------------------------------------
-= Zynq UltraScale+ MPSoC nvmem firmware driver binding =
---------------------------------------------------------------------------
-The nvmem_firmware node provides access to the hardware related data
-like soc revision, IDCODE... etc, By using the firmware interface.
-
-Required properties:
-- compatible: should be "xlnx,zynqmp-nvmem-fw"
-
-= Data cells =
-Are child nodes of silicon id, bindings of which as described in
-bindings/nvmem/nvmem.txt
-
--------
- Example
--------
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- compatible = "xlnx,zynqmp-firmware";
- method = "smc";
-
- nvmem_firmware {
- compatible = "xlnx,zynqmp-nvmem-fw";
- #address-cells = <1>;
- #size-cells = <1>;
-
- /* Data cells */
- soc_revision: soc_revision {
- reg = <0x0 0x4>;
- };
- };
- };
-};
-
-= Data consumers =
-Are device nodes which consume nvmem data cells.
-
-For example:
- pcap {
- ...
-
- nvmem-cells = <&soc_revision>;
- nvmem-cell-names = "soc_revision";
-
- ...
- };
diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.yaml b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.yaml
new file mode 100644
index 000000000000..1cbe44ab23b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/xlnx,zynqmp-nvmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zynq UltraScale+ MPSoC Non Volatile Memory interface
+
+description: |
+ The ZynqMP MPSoC provides access to the hardware related data
+ like SOC revision, IDCODE and specific purpose efuses.
+
+maintainers:
+ - Kalyani Akula <kalyani.akula@amd.com>
+ - Praveen Teja Kundanala <praveen.teja.kundanala@amd.com>
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+ const: xlnx,zynqmp-nvmem-fw
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc-nvmem {
+ compatible = "xlnx,zynqmp-nvmem-fw";
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ soc_revision: soc-revision@0 {
+ reg = <0x0 0x4>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt b/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt
deleted file mode 100644
index 0df79d9e07ec..000000000000
--- a/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Zodiac Inflight Innovations RAVE EEPROM Bindings
-
-RAVE SP EEPROM device is a "MFD cell" device exposing physical EEPROM
-attached to RAVE Supervisory Processor. It is expected that its Device
-Tree node is specified as a child of the node corresponding to the
-parent RAVE SP device (as documented in
-Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
-
-Required properties:
-
-- compatible: Should be "zii,rave-sp-eeprom"
-
-Optional properties:
-
-- zii,eeprom-name: Unique EEPROM identifier describing its function in the
- system. Will be used as created NVMEM deivce's name.
-
-Data cells:
-
-Data cells are child nodes of eerpom node, bindings for which are
-documented in Documentation/devicetree/bindings/nvmem/nvmem.txt
-
-Example:
-
- rave-sp {
- compatible = "zii,rave-sp-rdu1";
- current-speed = <38400>;
-
- eeprom@a4 {
- compatible = "zii,rave-sp-eeprom";
- reg = <0xa4 0x4000>;
- #address-cells = <1>;
- #size-cells = <1>;
- zii,eeprom-name = "main-eeprom";
-
- wdt_timeout: wdt-timeout@81 {
- reg = <0x81 2>;
- };
- };
- }
diff --git a/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.yaml b/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.yaml
new file mode 100644
index 000000000000..d073c51c2b9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/zii,rave-sp-eeprom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zodiac Inflight Innovations RAVE EEPROM
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ RAVE SP EEPROM device is a "MFD cell" device exposing physical EEPROM
+ attached to RAVE Supervisory Processor. It is expected that its Device
+ Tree node is specified as a child of the node corresponding to the
+ parent RAVE SP device (as documented in
+ Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml)
+
+properties:
+ compatible:
+ const: zii,rave-sp-eeprom
+
+ reg:
+ maxItems: 1
+
+ zii,eeprom-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Unique EEPROM identifier describing its function in the
+ system. Will be used as created NVMEM deivce's name.
+
+required:
+ - compatible
+
+allOf:
+ - $ref: nvmem.yaml#
+ - $ref: nvmem-deprecated-cells.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ eeprom@a4 {
+ compatible = "zii,rave-sp-eeprom";
+ reg = <0xa4 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ zii,eeprom-name = "main-eeprom";
+
+ wdt-timeout@81 {
+ reg = <0x81 2>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
index 729ae97b63d9..75ab552f6ecd 100644
--- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
+++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/opp/allwinner,sun50i-h6-operating-points.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner H6 CPU OPP Device Tree Bindings
+title: Allwinner H6 CPU OPP
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -13,25 +13,26 @@ maintainers:
description: |
For some SoCs, the CPU frequency subset and voltage value of each
OPP varies based on the silicon variant in use. Allwinner Process
- Voltage Scaling Tables defines the voltage and frequency value based
- on the speedbin blown in the efuse combination. The
- sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
- provide the OPP framework with required information.
+ Voltage Scaling Tables define the voltage and frequency values based
+ on the speedbin blown in the efuse combination.
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
- const: allwinner,sun50i-h6-operating-points
+ enum:
+ - allwinner,sun50i-a100-operating-points
+ - allwinner,sun50i-h6-operating-points
+ - allwinner,sun50i-h616-operating-points
nvmem-cells:
description: |
A phandle pointing to a nvmem-cells node representing the efuse
- registers that has information about the speedbin that is used
+ register that has information about the speedbin that is used
to select the right frequency/voltage value pair. Please refer
- the for nvmem-cells bindings
- Documentation/devicetree/bindings/nvmem/nvmem.txt and also
+ to the nvmem-cells bindings in
+ Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the
examples below.
opp-shared: true
@@ -41,21 +42,24 @@ required:
- nvmem-cells
patternProperties:
- "opp-[0-9]+":
+ "^opp-[0-9]+$":
type: object
properties:
opp-hz: true
clock-latency-ns: true
+ opp-microvolt: true
+ opp-supported-hw:
+ maxItems: 1
+ description:
+ A single 32 bit bitmap value, representing compatible HW, one
+ bit per speed bin index.
patternProperties:
- "opp-microvolt-.*": true
+ "^opp-microvolt-speed[0-9]$": true
required:
- opp-hz
- - opp-microvolt-speed0
- - opp-microvolt-speed1
- - opp-microvolt-speed2
unevaluatedProperties: false
@@ -77,58 +81,54 @@ examples:
opp-microvolt-speed2 = <800000>;
};
- opp-720000000 {
+ opp-1080000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <720000000>;
+ opp-hz = /bits/ 64 <1080000000>;
- opp-microvolt-speed0 = <880000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
+ opp-microvolt-speed0 = <1060000>;
+ opp-microvolt-speed1 = <880000>;
+ opp-microvolt-speed2 = <840000>;
};
- opp-816000000 {
+ opp-1488000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <816000000>;
+ opp-hz = /bits/ 64 <1488000000>;
- opp-microvolt-speed0 = <880000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
+ opp-microvolt-speed0 = <1160000>;
+ opp-microvolt-speed1 = <1000000>;
+ opp-microvolt-speed2 = <960000>;
};
+ };
- opp-888000000 {
- clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <888000000>;
-
- opp-microvolt-speed0 = <940000>;
- opp-microvolt-speed1 = <820000>;
- opp-microvolt-speed2 = <800000>;
- };
+ - |
+ opp-table {
+ compatible = "allwinner,sun50i-h616-operating-points";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
- opp-1080000000 {
+ opp-480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1080000000>;
+ opp-hz = /bits/ 64 <480000000>;
- opp-microvolt-speed0 = <1060000>;
- opp-microvolt-speed1 = <880000>;
- opp-microvolt-speed2 = <840000>;
+ opp-microvolt = <900000>;
+ opp-supported-hw = <0x1f>;
};
- opp-1320000000 {
+ opp-792000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1320000000>;
+ opp-hz = /bits/ 64 <792000000>;
- opp-microvolt-speed0 = <1160000>;
- opp-microvolt-speed1 = <940000>;
- opp-microvolt-speed2 = <900000>;
+ opp-microvolt-speed1 = <900000>;
+ opp-microvolt-speed4 = <940000>;
+ opp-supported-hw = <0x12>;
};
- opp-1488000000 {
+ opp-1512000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
- opp-hz = /bits/ 64 <1488000000>;
+ opp-hz = /bits/ 64 <1512000000>;
- opp-microvolt-speed0 = <1160000>;
- opp-microvolt-speed1 = <1000000>;
- opp-microvolt-speed2 = <960000>;
+ opp-microvolt = <1100000>;
+ opp-supported-hw = <0x0a>;
};
};
diff --git a/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
new file mode 100644
index 000000000000..624d1f3f1382
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/operating-points-v2-ti-cpu.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/opp/operating-points-v2-ti-cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI CPU OPP (Operating Performance Points)
+
+description:
+ TI SoCs, like those in the AM335x, AM437x, AM57xx, AM62x, and DRA7xx
+ families, the CPU frequencies subset and the voltage value of each
+ OPP vary based on the silicon variant used. The data sheet sections
+ corresponding to "Operating Performance Points" describe the frequency
+ and voltage values based on device type and speed bin information
+ blown in corresponding eFuse bits as referred to by the Technical
+ Reference Manual.
+
+ This document extends the operating-points-v2 binding by providing
+ the hardware description for the scheme mentioned above.
+
+maintainers:
+ - Dhruva Gole <d-gole@ti.com>
+
+allOf:
+ - $ref: opp-v2-base.yaml#
+
+properties:
+ compatible:
+ const: operating-points-v2-ti-cpu
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ points to syscon node representing the control module
+ register space of the SoC.
+
+ opp-shared: true
+
+patternProperties:
+ '^opp(-?[0-9]+)*$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ clock-latency-ns: true
+ opp-hz: true
+ opp-microvolt: true
+ opp-supported-hw:
+ items:
+ items:
+ - description:
+ The revision of the SoC the OPP is supported by.
+ This can be easily obtained from the datasheet of the
+ part being ordered/used. For example, it will be 0x01 for SR1.0
+
+ - description:
+ The eFuse bits that indicate the particular OPP is available.
+ The device datasheet has a table talking about Device Speed Grades.
+ This table is to be sorted with only the unique elements of the
+ MAXIMUM OPERATING FREQUENCY starting from the first row which
+ tells the lowest OPP, to the highest. The corresponding bits
+ need to be set based on N elements of speed grade the device supports.
+ So, if there are 3 possible unique MAXIMUM OPERATING FREQUENCY
+ in the table, then BIT(0) | (1) | (2) will be set, which means
+ the value shall be 0x7.
+
+ opp-suspend: true
+ turbo-mode: true
+
+ required:
+ - opp-hz
+ - opp-supported-hw
+
+required:
+ - compatible
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0020>;
+ opp-suspend;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0040>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1325000 1298500 1351500>;
+ opp-supported-hw = <0x04 0x0200>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/opp/opp-v1.yaml b/Documentation/devicetree/bindings/opp/opp-v1.yaml
index d585d536a3fb..61c080e50859 100644
--- a/Documentation/devicetree/bindings/opp/opp-v1.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v1.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/opp/opp-v1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic OPP (Operating Performance Points) v1 Bindings
+title: Generic OPP (Operating Performance Points) v1
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
@@ -18,9 +18,21 @@ description: |+
This binding only supports voltage-frequency pairs.
-select: true
+deprecated: true
properties:
+ clock-latency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The latency in nanoseconds for clock changes. Use OPP tables for new
+ designs instead.
+
+ voltage-tolerance:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 10
+ description:
+ The voltage tolerance in percent. Use OPP tables for new designs instead.
+
operating-points:
$ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
@@ -28,8 +40,12 @@ properties:
- description: Frequency in kHz
- description: Voltage for OPP in uV
+dependencies:
+ clock-latency: [ operating-points ]
+ voltage-tolerance: [ operating-points ]
additionalProperties: true
+
examples:
- |
cpus {
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
index 66d0ec763f0b..b1bb87c865ed 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/opp/opp-v2-base.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic OPP (Operating Performance Points) Common Binding
+title: Generic OPP (Operating Performance Points) Common Properties
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
@@ -56,9 +56,7 @@ patternProperties:
need to be configured and that is left for the implementation
specific binding.
minItems: 1
- maxItems: 16
- items:
- maxItems: 1
+ maxItems: 32
opp-microvolt:
description: |
@@ -108,7 +106,7 @@ patternProperties:
The power for the OPP in micro-Watts.
Entries for multiple regulators shall be provided in the same field
- separated by angular brackets <>. If current values aren't required
+ separated by angular brackets <>. If power values aren't required
for a regulator, then it shall be filled with 0. If power values
aren't required for any of the regulators, then this field is not
required. The OPP binding doesn't provide any provisions to relate the
@@ -230,9 +228,9 @@ patternProperties:
minItems: 1
maxItems: 8 # Should be enough regulators
- '^opp-microwatt':
+ '^opp-microwatt-':
description:
- Named opp-microwatt property. Similar to opp-microamp property,
+ Named opp-microwatt property. Similar to opp-microamp-<name> property,
but for microwatt instead.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
index a202b6c6561d..fd04d060c1de 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/opp/opp-v2-kryo-cpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. NVMEM OPP bindings
+title: Qualcomm Technologies, Inc. NVMEM OPP
maintainers:
- Ilia Lin <ilia.lin@kernel.org>
@@ -26,7 +26,9 @@ description: |
properties:
compatible:
- const: operating-points-v2-kryo-cpu
+ enum:
+ - operating-points-v2-krait-cpu
+ - operating-points-v2-kryo-cpu
nvmem-cells:
description: |
@@ -47,20 +49,40 @@ patternProperties:
opp-microvolt: true
+ opp-peak-kBps: true
+
opp-supported-hw:
description: |
A single 32 bit bitmap value, representing compatible HW.
- Bitmap:
+ Bitmap for MSM8996 format:
0: MSM8996, speedbin 0
1: MSM8996, speedbin 1
2: MSM8996, speedbin 2
+ 3: MSM8996, speedbin 3
+ 4-31: unused
+
+ Bitmap for MSM8996SG format (speedbin shifted of 4 left):
+ 0-3: unused
+ 4: MSM8996SG, speedbin 0
+ 5: MSM8996SG, speedbin 1
+ 6: MSM8996SG, speedbin 2
+ 7-31: unused
+
+ Bitmap for IPQ806x SoC:
+ 0: IPQ8062
+ 1: IPQ8064/IPQ8066/IPQ8068
+ 2: IPQ8065/IPQ8069
3-31: unused
- maximum: 0x7
+
+ Other platforms use bits directly corresponding to speedbin index.
clock-latency-ns: true
required-opps: true
+ patternProperties:
+ '^opp-microvolt-speed[0-9]+-pvs[0-9]+$': true
+
required:
- opp-hz
@@ -106,6 +128,7 @@ examples:
L2_0: l2-cache {
compatible = "cache";
cache-level = <2>;
+ cache-unified;
};
};
@@ -140,6 +163,7 @@ examples:
L2_1: l2-cache {
compatible = "cache";
cache-level = <2>;
+ cache-unified;
};
};
@@ -244,6 +268,22 @@ examples:
};
};
+ /* Dummy opp table to give example for named opp-microvolt */
+ opp-table-2 {
+ compatible = "operating-points-v2-krait-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt-speed0-pvs0 = <1000000 950000 1050000>;
+ opp-microvolt-speed0-pvs1 = <925000 878750 971250>;
+ opp-microvolt-speed0-pvs2 = <875000 831250 918750>;
+ opp-microvolt-speed0-pvs3 = <800000 760000 840000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <100000>;
+ };
+ };
+
smem {
compatible = "qcom,smem";
memory-region = <&smem_mem>;
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
new file mode 100644
index 000000000000..0bd7d6b69755
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-adreno.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/opp/opp-v2-qcom-adreno.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Adreno compatible OPP supply
+
+description:
+ Adreno GPUs present in Qualcomm's Snapdragon chipsets uses an OPP specific
+ ACD related information tailored for the specific chipset. This binding
+ provides the information needed to describe such a hardware value.
+
+maintainers:
+ - Rob Clark <robdclark@gmail.com>
+
+allOf:
+ - $ref: opp-v2-base.yaml#
+
+properties:
+ compatible:
+ contains:
+ const: operating-points-v2-adreno
+
+patternProperties:
+ '^opp(-[0-9]+){1,2}$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ opp-hz: true
+
+ opp-level: true
+
+ opp-peak-kBps: true
+
+ opp-supported-hw: true
+
+ qcom,opp-acd-level:
+ description: |
+ A positive value representing the ACD (Adaptive Clock Distribution,
+ a fancy name for clk throttling during voltage droop) level associated
+ with this OPP node. This value is shared to a co-processor inside GPU
+ (called Graphics Management Unit a.k.a GMU) during wake up. It may not
+ be present for some OPPs and GMU will disable ACD while transitioning
+ to that OPP. This value encodes a voltage threshold, delay cycles &
+ calibration margins which are identified by characterization of the
+ SoC. So, it doesn't have any unit. This data is passed to GMU firmware
+ via 'HFI_H2F_MSG_ACD' packet.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - opp-hz
+ - opp-level
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2-adreno", "operating-points-v2";
+
+ opp-687000000 {
+ opp-hz = /bits/ 64 <687000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
+ opp-peak-kBps = <8171875>;
+ qcom,opp-acd-level = <0x882e5ffd>;
+ };
+
+ opp-550000000 {
+ opp-hz = /bits/ 64 <550000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
+ opp-peak-kBps = <6074219>;
+ qcom,opp-acd-level = <0xc0285ffd>;
+ };
+
+ opp-390000000 {
+ opp-hz = /bits/ 64 <390000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
+ opp-peak-kBps = <3000000>;
+ qcom,opp-acd-level = <0xc0285ffd>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
+ opp-peak-kBps = <2136719>;
+ /* Intentionally left out qcom,opp-acd-level property here */
+ };
+
+ };
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
index df8442fb11f0..a30ef93213c0 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/opp/opp-v2-qcom-level.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm OPP bindings to describe OPP nodes.
+title: Qualcomm OPP
maintainers:
- Niklas Cassel <nks@flawful.org>
@@ -30,7 +30,9 @@ patternProperties:
this OPP node. Sometimes several corners/levels shares a certain fuse
corner/level. A fuse corner/level contains e.g. ref uV, min uV,
and max uV.
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
required:
- opp-level
diff --git a/Documentation/devicetree/bindings/opp/opp-v2.yaml b/Documentation/devicetree/bindings/opp/opp-v2.yaml
index eaf8fba2c691..6972d76233aa 100644
--- a/Documentation/devicetree/bindings/opp/opp-v2.yaml
+++ b/Documentation/devicetree/bindings/opp/opp-v2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/opp/opp-v2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic OPP (Operating Performance Points) Bindings
+title: Generic OPP (Operating Performance Points)
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
@@ -155,7 +155,7 @@ examples:
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
- lock-latency-ns = <290000>;
+ clock-latency-ns = <290000>;
turbo-mode;
};
};
diff --git a/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml b/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml
new file mode 100644
index 000000000000..693f22539606
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/ti,omap-opp-supply.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/opp/ti,omap-opp-supply.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments OMAP compatible OPP supply
+
+description:
+ OMAP5, DRA7, and AM57 families of SoCs have Class 0 AVS eFuse
+ registers, which contain OPP-specific voltage information tailored
+ for the specific device. This binding provides the information
+ needed to describe such a hardware values and relate them to program
+ the primary regulator during an OPP transition.
+
+ Also, some supplies may have an associated vbb-supply, an Adaptive
+ Body Bias regulator, which must transition in a specific sequence
+ w.r.t the vdd-supply and clk when making an OPP transition. By
+ supplying two regulators to the device that will undergo OPP
+ transitions, we can use the multi-regulator support implemented by
+ the OPP core to describe both regulators the platform needs. The
+ OPP core binding Documentation/devicetree/bindings/opp/opp-v2.yaml
+ provides further information (refer to Example 4 Handling multiple
+ regulators).
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+
+properties:
+ $nodename:
+ pattern: '^opp-supply(@[0-9a-f]+)?$'
+
+ compatible:
+ oneOf:
+ - description: Basic OPP supply controlling VDD and VBB
+ const: ti,omap-opp-supply
+ - description: OMAP5+ optimized voltages in efuse(Class 0) VDD along with
+ VBB.
+ const: ti,omap5-opp-supply
+ - description: OMAP5+ optimized voltages in efuse(class0) VDD but no VBB
+ const: ti,omap5-core-opp-supply
+
+ reg:
+ maxItems: 1
+
+ ti,absolute-max-voltage-uv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Absolute maximum voltage for the OPP supply in micro-volts.
+ minimum: 750000
+ maximum: 1500000
+
+ ti,efuse-settings:
+ description: An array of u32 tuple items providing information about
+ optimized efuse configuration.
+ minItems: 1
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: Reference voltage in micro-volts (OPP Voltage)
+ minimum: 750000
+ maximum: 1500000
+ multipleOf: 10000
+ - description: efuse offset where the optimized voltage is located
+ multipleOf: 4
+ maximum: 256
+
+required:
+ - compatible
+ - ti,absolute-max-voltage-uv
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: ti,omap-opp-supply
+ then:
+ required:
+ - reg
+ - ti,efuse-settings
+
+additionalProperties: false
+
+examples:
+ - |
+ opp-supply {
+ compatible = "ti,omap-opp-supply";
+ ti,absolute-max-voltage-uv = <1375000>;
+ };
+ - |
+ opp-supply@4a003b20 {
+ compatible = "ti,omap5-opp-supply";
+ reg = <0x4a003b20 0x8>;
+ ti,efuse-settings =
+ /* uV offset */
+ <1060000 0x0>,
+ <1160000 0x4>,
+ <1210000 0x8>;
+ ti,absolute-max-voltage-uv = <1500000>;
+ };
diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
deleted file mode 100644
index b70d326117cd..000000000000
--- a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Texas Instruments OMAP compatible OPP supply description
-
-OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
-contain data that can be used to adjust voltages programmed for some of their
-supplies for more efficient operation. This binding provides the information
-needed to read these values and use them to program the main regulator during
-an OPP transitions.
-
-Also, some supplies may have an associated vbb-supply which is an Adaptive Body
-Bias regulator which much be transitioned in a specific sequence with regards
-to the vdd-supply and clk when making an OPP transition. By supplying two
-regulators to the device that will undergo OPP transitions we can make use
-of the multi regulator binding that is part of the OPP core described here [1]
-to describe both regulators needed by the platform.
-
-[1] Documentation/devicetree/bindings/opp/opp-v2.yaml
-
-Required Properties for Device Node:
-- vdd-supply: phandle to regulator controlling VDD supply
-- vbb-supply: phandle to regulator controlling Body Bias supply
- (Usually Adaptive Body Bias regulator)
-
-Required Properties for opp-supply node:
-- compatible: Should be one of:
- "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
- "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
- along with VBB
- "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
- but no VBB.
-- reg: Address and length of the efuse register set for the device (mandatory
- only for "ti,omap5-opp-supply")
-- ti,efuse-settings: An array of u32 tuple items providing information about
- optimized efuse configuration. Each item consists of the following:
- volt: voltage in uV - reference voltage (OPP voltage)
- efuse_offseet: efuse offset from reg where the optimized voltage is stored.
-- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
-
-Example:
-
-/* Device Node (CPU) */
-cpus {
- cpu0: cpu@0 {
- device_type = "cpu";
-
- ...
-
- vdd-supply = <&vcc>;
- vbb-supply = <&abb_mpu>;
- };
-};
-
-/* OMAP OPP Supply with Class0 registers */
-opp_supply_mpu: opp_supply@4a003b20 {
- compatible = "ti,omap5-opp-supply";
- reg = <0x4a003b20 0x8>;
- ti,efuse-settings = <
- /* uV offset */
- 1060000 0x0
- 1160000 0x4
- 1210000 0x8
- >;
- ti,absolute-max-voltage-uv = <1500000>;
-};
diff --git a/Documentation/devicetree/bindings/pci/83xx-512x-pci.txt b/Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
deleted file mode 100644
index 3abeecf4983f..000000000000
--- a/Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-* Freescale 83xx and 512x PCI bridges
-
-Freescale 83xx and 512x SOCs include the same PCI bridge core.
-
-83xx/512x specific notes:
-- reg: should contain two address length tuples
- The first is for the internal PCI bridge registers
- The second is for the PCI config space access registers
-
-Example (MPC8313ERDB)
- pci0: pci@e0008500 {
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
- interrupt-map = <
- /* IDSEL 0x0E -mini PCI */
- 0x7000 0x0 0x0 0x1 &ipic 18 0x8
- 0x7000 0x0 0x0 0x2 &ipic 18 0x8
- 0x7000 0x0 0x0 0x3 &ipic 18 0x8
- 0x7000 0x0 0x0 0x4 &ipic 18 0x8
-
- /* IDSEL 0x0F - PCI slot */
- 0x7800 0x0 0x0 0x1 &ipic 17 0x8
- 0x7800 0x0 0x0 0x2 &ipic 18 0x8
- 0x7800 0x0 0x0 0x3 &ipic 17 0x8
- 0x7800 0x0 0x0 0x4 &ipic 18 0x8>;
- interrupt-parent = <&ipic>;
- interrupts = <66 0x8>;
- bus-range = <0x0 0x0>;
- ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
- 0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
- 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
- clock-frequency = <66666666>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- reg = <0xe0008500 0x100 /* internal registers */
- 0xe0008300 0x8>; /* config space access registers */
- compatible = "fsl,mpc8349-pci";
- device_type = "pci";
- };
diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
deleted file mode 100644
index 2b8ca920a7fa..000000000000
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Aardvark PCIe controller
-
-This PCIe controller is used on the Marvell Armada 3700 ARM64 SoC.
-
-The Device Tree node describing an Aardvark PCIe controller must
-contain the following properties:
-
- - compatible: Should be "marvell,armada-3700-pcie"
- - reg: range of registers for the PCIe controller
- - interrupts: the interrupt line of the PCIe controller
- - #address-cells: set to <3>
- - #size-cells: set to <2>
- - device_type: set to "pci"
- - ranges: ranges for the PCI memory and I/O regions
- - #interrupt-cells: set to <1>
- - msi-controller: indicates that the PCIe controller can itself
- handle MSI interrupts
- - msi-parent: pointer to the MSI controller to be used
- - interrupt-map-mask and interrupt-map: standard PCI properties to
- define the mapping of the PCIe interface to interrupt numbers.
- - bus-range: PCI bus numbers covered
- - phys: the PCIe PHY handle
- - max-link-speed: see pci.txt
- - reset-gpios: see pci.txt
-
-In addition, the Device Tree describing an Aardvark PCIe controller
-must include a sub-node that describes the legacy interrupt controller
-built into the PCIe controller. This sub-node must have the following
-properties:
-
- - interrupt-controller
- - #interrupt-cells: set to <1>
-
-Example:
-
- pcie0: pcie@d0070000 {
- compatible = "marvell,armada-3700-pcie";
- device_type = "pci";
- reg = <0 0xd0070000 0 0x20000>;
- #address-cells = <3>;
- #size-cells = <2>;
- bus-range = <0x00 0xff>;
- interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
- #interrupt-cells = <1>;
- msi-controller;
- msi-parent = <&pcie0>;
- ranges = <0x82000000 0 0xe8000000 0 0xe8000000 0 0x1000000 /* Port 0 MEM */
- 0x81000000 0 0xe9000000 0 0xe9000000 0 0x10000>; /* Port 0 IO*/
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc 0>,
- <0 0 0 2 &pcie_intc 1>,
- <0 0 0 3 &pcie_intc 2>,
- <0 0 0 4 &pcie_intc 3>;
- phys = <&comphy1 0>;
- pcie_intc: interrupt-controller {
- interrupt-controller;
- #interrupt-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
deleted file mode 100644
index 9514c327d31b..000000000000
--- a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Altera PCIe MSI controller
-
-Required properties:
-- compatible: should contain "altr,msi-1.0"
-- reg: specifies the physical base address of the controller and
- the length of the memory mapped region.
-- reg-names: must include the following entries:
- "csr": CSR registers
- "vector_slave": vectors slave port region
-- interrupts: specifies the interrupt source of the parent interrupt
- controller. The format of the interrupt specifier depends on the
- parent interrupt controller.
-- num-vectors: number of vectors, range 1 to 32.
-- msi-controller: indicates that this is MSI controller node
-
-
-Example
-msi0: msi@0xFF200000 {
- compatible = "altr,msi-1.0";
- reg = <0xFF200000 0x00000010
- 0xFF200010 0x00000080>;
- reg-names = "csr", "vector_slave";
- interrupt-parent = <&hps_0_arm_gic_0>;
- interrupts = <0 42 4>;
- msi-controller;
- num-vectors = <32>;
-};
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt b/Documentation/devicetree/bindings/pci/altera-pcie.txt
deleted file mode 100644
index 816b244a221e..000000000000
--- a/Documentation/devicetree/bindings/pci/altera-pcie.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Altera PCIe controller
-
-Required properties:
-- compatible : should contain "altr,pcie-root-port-1.0" or "altr,pcie-root-port-2.0"
-- reg: a list of physical base address and length for TXS and CRA.
- For "altr,pcie-root-port-2.0", additional HIP base address and length.
-- reg-names: must include the following entries:
- "Txs": TX slave port region
- "Cra": Control register access region
- "Hip": Hard IP region (if "altr,pcie-root-port-2.0")
-- interrupts: specifies the interrupt source of the parent interrupt
- controller. The format of the interrupt specifier depends
- on the parent interrupt controller.
-- device_type: must be "pci"
-- #address-cells: set to <3>
-- #size-cells: set to <2>
-- #interrupt-cells: set to <1>
-- ranges: describes the translation of addresses for root ports and
- standard PCI regions.
-- interrupt-map-mask and interrupt-map: standard PCI properties to define the
- mapping of the PCIe interface to interrupt numbers.
-
-Optional properties:
-- msi-parent: Link to the hardware entity that serves as the MSI controller
- for this PCIe controller.
-- bus-range: PCI bus numbers covered
-
-Example
- pcie_0: pcie@c00000000 {
- compatible = "altr,pcie-root-port-1.0";
- reg = <0xc0000000 0x20000000>,
- <0xff220000 0x00004000>;
- reg-names = "Txs", "Cra";
- interrupt-parent = <&hps_0_arm_gic_0>;
- interrupts = <0 40 4>;
- interrupt-controller;
- #interrupt-cells = <1>;
- bus-range = <0x0 0xFF>;
- device_type = "pci";
- msi-parent = <&msi_to_gic_gen_0>;
- #address-cells = <3>;
- #size-cells = <2>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_0 1>,
- <0 0 0 2 &pcie_0 2>,
- <0 0 0 3 &pcie_0 3>,
- <0 0 0 4 &pcie_0 4>;
- ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000
- 0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>;
- };
diff --git a/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml b/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml
new file mode 100644
index 000000000000..f516db47ab20
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2015, 2019, 2024, Intel Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/altr,pcie-root-port.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera PCIe Root Port
+
+maintainers:
+ - Matthew Gerlach <matthew.gerlach@linux.intel.com>
+
+properties:
+ compatible:
+ description: Each family of socfpga has its own implementation of the
+ PCI controller. The altr,pcie-root-port-1.0 is used for the Cyclone5
+ family of chips. The Stratix10 family of chips is supported by the
+ altr,pcie-root-port-2.0. The Agilex family of chips has three,
+ non-register compatible, variants of PCIe Hard IP referred to as the
+ F-Tile, P-Tile, and R-Tile, depending on the specific chip instance.
+
+ enum:
+ - altr,pcie-root-port-1.0
+ - altr,pcie-root-port-2.0
+ - altr,pcie-root-port-3.0-f-tile
+ - altr,pcie-root-port-3.0-p-tile
+ - altr,pcie-root-port-3.0-r-tile
+
+ reg:
+ items:
+ - description: TX slave port region
+ - description: Control register access region
+ - description: Hard IP region
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: Txs
+ - const: Cra
+ - const: Hip
+ minItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ interrupt-map-mask:
+ items:
+ - const: 0
+ - const: 0
+ - const: 0
+ - const: 7
+
+ interrupt-map:
+ maxItems: 4
+
+ "#interrupt-cells":
+ const: 1
+
+ msi-parent: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupt-map
+ - interrupt-map-mask
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - altr,pcie-root-port-1.0
+ then:
+ properties:
+ reg:
+ maxItems: 2
+
+ reg-names:
+ maxItems: 2
+
+ else:
+ properties:
+ reg:
+ minItems: 3
+
+ reg-names:
+ minItems: 3
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pcie_0: pcie@c00000000 {
+ compatible = "altr,pcie-root-port-1.0";
+ reg = <0xc0000000 0x20000000>,
+ <0xff220000 0x00004000>;
+ reg-names = "Txs", "Cra";
+ interrupt-parent = <&hps_0_arm_gic_0>;
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ bus-range = <0x0 0xff>;
+ device_type = "pci";
+ msi-parent = <&msi_to_gic_gen_0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_0 0 0 0 1>,
+ <0 0 0 2 &pcie_0 0 0 0 2>,
+ <0 0 0 3 &pcie_0 0 0 0 3>,
+ <0 0 0 4 &pcie_0 0 0 0 4>;
+ ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000>,
+ <0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>;
+ };
diff --git a/Documentation/devicetree/bindings/pci/amazon,al-alpine-v3-pcie.yaml b/Documentation/devicetree/bindings/pci/amazon,al-alpine-v3-pcie.yaml
new file mode 100644
index 000000000000..45244cad5f30
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/amazon,al-alpine-v3-pcie.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/amazon,al-alpine-v3-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amazon Annapurna Labs Alpine v3 PCIe Host Bridge
+
+maintainers:
+ - Jonathan Chocron <jonnyc@amazon.com>
+
+description:
+ Amazon's Annapurna Labs PCIe Host Controller is based on the Synopsys
+ DesignWare PCI controller.
+
+allOf:
+ - $ref: snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amazon,al-alpine-v2-pcie
+ - amazon,al-alpine-v3-pcie
+
+ reg:
+ items:
+ - description: PCIe ECAM space
+ - description: AL proprietary registers
+ - description: Designware PCIe registers
+
+ reg-names:
+ items:
+ - const: config
+ - const: controller
+ - const: dbi
+
+ interrupts:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@fb600000 {
+ compatible = "amazon,al-alpine-v3-pcie";
+ reg = <0x0 0xfb600000 0x0 0x00100000
+ 0x0 0xfd800000 0x0 0x00010000
+ 0x0 0xfd810000 0x0 0x00001000>;
+ reg-names = "config", "controller", "dbi";
+ bus-range = <0 255>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x00 0 0 7>;
+ interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; /* INTa */
+ ranges = <0x02000000 0x0 0xc0010000 0x0 0xc0010000 0x0 0x07ff0000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml b/Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml
new file mode 100644
index 000000000000..406c15e1dee1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/amd,versal2-mdb-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Versal2 MDB(Multimedia DMA Bridge) Host Controller
+
+maintainers:
+ - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ const: amd,versal2-mdb-host
+
+ reg:
+ items:
+ - description: MDB System Level Control and Status Register (SLCR) Base
+ - description: configuration region
+ - description: data bus interface
+ - description: address translation unit register
+
+ reg-names:
+ items:
+ - const: slcr
+ - const: config
+ - const: dbi
+ - const: atu
+
+ ranges:
+ maxItems: 2
+
+ msi-map:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-map-mask:
+ items:
+ - const: 0
+ - const: 0
+ - const: 0
+ - const: 7
+
+ interrupt-map:
+ maxItems: 4
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller:
+ description: identifies the node as an interrupt controller
+ type: object
+ additionalProperties: false
+ properties:
+ interrupt-controller: true
+
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ const: 1
+
+ required:
+ - interrupt-controller
+ - "#address-cells"
+ - "#interrupt-cells"
+
+patternProperties:
+ '^pcie@[0-2],0$':
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ unevaluatedProperties: false
+
+required:
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-map
+ - interrupt-map-mask
+ - msi-map
+ - "#interrupt-cells"
+ - interrupt-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@ed931000 {
+ compatible = "amd,versal2-mdb-host";
+ reg = <0x0 0xed931000 0x0 0x2000>,
+ <0x1000 0x100000 0x0 0xff00000>,
+ <0x1000 0x0 0x0 0x1000>,
+ <0x0 0xed860000 0x0 0x2000>;
+ reg-names = "slcr", "config", "dbi", "atu";
+ ranges = <0x2000000 0x00 0xa0000000 0x00 0xa0000000 0x00 0x10000000>,
+ <0x43000000 0x1100 0x00 0x1100 0x00 0x00 0x1000000>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
+ <0 0 0 2 &pcie_intc_0 1>,
+ <0 0 0 3 &pcie_intc_0 2>,
+ <0 0 0 4 &pcie_intc_0 3>;
+ msi-map = <0x0 &gic_its 0x00 0x10000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+
+ pcie@0,0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ reset-gpios = <&tca6416_u37 7 GPIO_ACTIVE_LOW>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+
+ pcie_intc_0: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml b/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml
new file mode 100644
index 000000000000..d67cb7a850a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/amlogic,axg-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson AXG DWC PCIe SoC controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core.
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: /schemas/pci/snps,dw-pcie-common.yaml#
+
+# We need a select here so we don't match all nodes with 'snps,dw-pcie'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,axg-pcie
+ - amlogic,g12a-pcie
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - amlogic,axg-pcie
+ - amlogic,g12a-pcie
+ - const: snps,dw-pcie
+
+ reg:
+ items:
+ - description: Data Bus Interface registers
+ - description: Meson designed configuration registers
+ - description: PCIe configuration space
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: cfg
+ - const: config
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PCIe PHY clock
+ - description: PCIe GEN 100M PLL clock
+ - description: PCIe RC clock gate
+
+ clock-names:
+ items:
+ - const: general
+ - const: pclk
+ - const: port
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: pcie
+
+ resets:
+ items:
+ - description: Port Reset
+ - description: Shared APB reset
+
+ reset-names:
+ items:
+ - const: port
+ - const: apb
+
+ num-lanes:
+ const: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - "#address-cells"
+ - "#size-cells"
+ - "#interrupt-cells"
+ - interrupt-map
+ - interrupt-map-mask
+ - ranges
+ - bus-range
+ - device_type
+ - num-lanes
+ - phys
+ - phy-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pcie: pcie@f9800000 {
+ compatible = "amlogic,axg-pcie", "snps,dw-pcie";
+ reg = <0xf9800000 0x400000>, <0xff646000 0x2000>, <0xf9f00000 0x100000>;
+ reg-names = "dbi", "cfg", "config";
+ interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clk_phy>, <&pclk>, <&clk_port>;
+ clock-names = "general", "pclk", "port";
+ resets = <&reset_pcie_port>, <&reset_pcie_apb>;
+ reset-names = "port", "apb";
+ phys = <&pcie_phy>;
+ phy-names = "pcie";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 179 IRQ_TYPE_EDGE_RISING>;
+ bus-range = <0x0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ num-lanes = <1>;
+ ranges = <0x82000000 0 0 0xf9c00000 0 0x00300000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
deleted file mode 100644
index c3a75ac6e59d..000000000000
--- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Amlogic Meson AXG DWC PCIE SoC controller
-
-Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core.
-It shares common functions with the PCIe DesignWare core driver and
-inherits common properties defined in
-Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml.
-
-Additional properties are described here:
-
-Required properties:
-- compatible:
- should contain :
- - "amlogic,axg-pcie" for AXG SoC Family
- - "amlogic,g12a-pcie" for G12A SoC Family
- to identify the core.
-- reg:
- should contain the configuration address space.
-- reg-names: Must be
- - "elbi" External local bus interface registers
- - "cfg" Meson specific registers
- - "config" PCIe configuration space
-- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal.
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must include the following entries:
- - "pclk" PCIe GEN 100M PLL clock
- - "port" PCIe_x(A or B) RC clock gate
- - "general" PCIe Phy clock
-- resets: phandle to the reset lines.
-- reset-names: must contain "port" and "apb"
- - "port" Port A or B reset
- - "apb" Share APB reset
-- phys: should contain a phandle to the PCIE phy
-- phy-names: must contain "pcie"
-
-- device_type:
- should be "pci". As specified in snps,dw-pcie.yaml
-
-
-Example configuration:
-
- pcie: pcie@f9800000 {
- compatible = "amlogic,axg-pcie", "snps,dw-pcie";
- reg = <0x0 0xf9800000 0x0 0x400000
- 0x0 0xff646000 0x0 0x2000
- 0x0 0xf9f00000 0x0 0x100000>;
- reg-names = "elbi", "cfg", "config";
- reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
- interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 179 IRQ_TYPE_EDGE_RISING>;
- bus-range = <0x0 0xff>;
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x82000000 0 0 0x0 0xf9c00000 0 0x00300000>;
-
- clocks = <&clkc CLKID_USB
- &clkc CLKID_PCIE_A
- &clkc CLKID_PCIE_CML_EN0>;
- clock-names = "general",
- "pclk",
- "port";
- resets = <&reset RESET_PCIE_A>,
- <&reset RESET_PCIE_APB>;
- reset-names = "port",
- "apb";
- phys = <&pcie_phy>;
- phy-names = "pcie";
- };
diff --git a/Documentation/devicetree/bindings/pci/apm,xgene-pcie.yaml b/Documentation/devicetree/bindings/pci/apm,xgene-pcie.yaml
new file mode 100644
index 000000000000..2504b8235889
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/apm,xgene-pcie.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/apm,xgene-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AppliedMicro X-Gene PCIe interface
+
+maintainers:
+ - Toan Le <toan@os.amperecomputing.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: apm,xgene-storm-pcie
+ - const: apm,xgene-pcie
+ - items:
+ - const: apm,xgene-pcie
+
+ reg:
+ items:
+ - description: Controller configuration registers
+ - description: PCI configuration space registers
+
+ reg-names:
+ items:
+ - const: csr
+ - const: cfg
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pcie
+
+ dma-coherent: true
+
+ msi-parent:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#interrupt-cells'
+ - interrupt-map-mask
+ - interrupt-map
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1f2b0000 {
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0x00 0x1f2b0000 0x0 0x00010000>, /* Controller registers */
+ <0xe0 0xd0000000 0x0 0x00040000>; /* PCI config space */
+ reg-names = "csr", "cfg";
+ ranges = <0x01000000 0x00 0x00000000 0xe0 0x10000000 0x00 0x00010000>, /* io */
+ <0x02000000 0x00 0x80000000 0xe1 0x80000000 0x00 0x80000000>; /* mem */
+ dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000>,
+ <0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1>,
+ <0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1>,
+ <0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1>,
+ <0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
+ dma-coherent;
+ clocks = <&pcie0clk 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
index aa38680aaaca..c0852be04f6d 100644
--- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
@@ -17,6 +17,10 @@ description: |
implements its root ports. But the ATU found on most DesignWare
PCIe host bridges is absent.
+ On systems derived from T602x, the PHY registers are in a region
+ separate from the port registers. In that case, there is one PHY
+ register range per port register range.
+
All root ports share a single ECAM space, but separate GPIOs are
used to take the PCI devices on those ports out of reset. Therefore
the standard "reset-gpios" and "max-link-speed" properties appear on
@@ -30,15 +34,18 @@ description: |
properties:
compatible:
- items:
- - enum:
- - apple,t8103-pcie
- - apple,t6000-pcie
- - const: apple,pcie
+ oneOf:
+ - items:
+ - enum:
+ - apple,t8103-pcie
+ - apple,t8112-pcie
+ - apple,t6000-pcie
+ - const: apple,pcie
+ - const: apple,t6020-pcie
reg:
minItems: 3
- maxItems: 6
+ maxItems: 10
reg-names:
minItems: 3
@@ -49,6 +56,10 @@ properties:
- const: port1
- const: port2
- const: port3
+ - const: phy0
+ - const: phy1
+ - const: phy2
+ - const: phy3
ranges:
minItems: 2
@@ -84,7 +95,7 @@ required:
unevaluatedProperties: false
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
- $ref: /schemas/interrupt-controller/msi-controller.yaml#
- if:
properties:
@@ -97,6 +108,15 @@ allOf:
maxItems: 5
interrupts:
maxItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: apple,t6020-pcie
+ then:
+ properties:
+ reg-names:
+ minItems: 10
examples:
- |
diff --git a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
deleted file mode 100644
index cc6dcdb676b9..000000000000
--- a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* Axis ARTPEC-6 PCIe interface
-
-This PCIe host controller is based on the Synopsys DesignWare PCIe IP
-and thus inherits all the common properties defined in snps,dw-pcie.yaml.
-
-Required properties:
-- compatible: "axis,artpec6-pcie", "snps,dw-pcie" for ARTPEC-6 in RC mode;
- "axis,artpec6-pcie-ep", "snps,dw-pcie" for ARTPEC-6 in EP mode;
- "axis,artpec7-pcie", "snps,dw-pcie" for ARTPEC-7 in RC mode;
- "axis,artpec7-pcie-ep", "snps,dw-pcie" for ARTPEC-7 in EP mode;
-- reg: base addresses and lengths of the PCIe controller (DBI),
- the PHY controller, and configuration address space.
-- reg-names: Must include the following entries:
- - "dbi"
- - "phy"
- - "config"
-- interrupts: A list of interrupt outputs of the controller. Must contain an
- entry for each entry in the interrupt-names property.
-- interrupt-names: Must include the following entries:
- - "msi": The interrupt that is asserted when an MSI is received
-- axis,syscon-pcie: A phandle pointing to the ARTPEC-6 system controller,
- used to enable and control the Synopsys IP.
-
-Example:
-
- pcie@f8050000 {
- compatible = "axis,artpec6-pcie", "snps,dw-pcie";
- reg = <0xf8050000 0x2000
- 0xf8040000 0x1000
- 0xc0000000 0x2000>;
- reg-names = "dbi", "phy", "config";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- /* downstream I/O */
- ranges = <0x81000000 0 0 0xc0002000 0 0x00010000
- /* non-prefetchable memory */
- 0x82000000 0 0xc0012000 0xc0012000 0 0x1ffee000>;
- num-lanes = <2>;
- bus-range = <0x00 0xff>;
- interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi";
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
- axis,syscon-pcie = <&syscon>;
- };
diff --git a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.yaml b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.yaml
new file mode 100644
index 000000000000..dcc5661aa004
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Axis AB
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/axis,artpec6-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axis ARTPEC-6 PCIe host controller
+
+maintainers:
+ - Jesper Nilsson <jesper.nilsson@axis.com>
+
+description:
+ This PCIe host controller is based on the Synopsys DesignWare PCIe IP.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - axis,artpec6-pcie
+ - axis,artpec6-pcie-ep
+ - axis,artpec7-pcie
+ - axis,artpec7-pcie-ep
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - axis,artpec6-pcie
+ - axis,artpec6-pcie-ep
+ - axis,artpec7-pcie
+ - axis,artpec7-pcie-ep
+ - const: snps,dw-pcie
+
+ reg:
+ minItems: 3
+ maxItems: 4
+
+ reg-names:
+ minItems: 3
+ maxItems: 4
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: msi
+
+ axis,syscon-pcie:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ System controller phandle used to enable and control the Synopsys IP.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - axis,syscon-pcie
+
+oneOf:
+ - $ref: snps,dw-pcie.yaml#
+ properties:
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: phy
+ - const: config
+
+ - $ref: snps,dw-pcie-ep.yaml#
+ properties:
+ reg:
+ minItems: 4
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: phy
+ - const: addr_space
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie@f8050000 {
+ compatible = "axis,artpec6-pcie", "snps,dw-pcie";
+ device_type = "pci";
+ reg = <0xf8050000 0x2000
+ 0xf8040000 0x1000
+ 0xc0000000 0x2000>;
+ reg-names = "dbi", "phy", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x81000000 0 0 0xc0002000 0 0x00010000>,
+ <0x82000000 0 0xc0012000 0xc0012000 0 0x1ffee000>;
+ num-lanes = <2>;
+ bus-range = <0x00 0xff>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
+ axis,syscon-pcie = <&syscon>;
+ };
diff --git a/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml b/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml
new file mode 100644
index 000000000000..8eaa07ae9774
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/baikal,bt1-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Baikal-T1 PCIe Root Port Controller
+
+maintainers:
+ - Serge Semin <fancer.lancer@gmail.com>
+
+description:
+ Embedded into Baikal-T1 SoC Root Complex controller with a single port
+ activated. It's based on the DWC RC PCIe v4.60a IP-core, which is configured
+ to have just a single Root Port function and is capable of establishing the
+ link up to Gen.3 speed on x4 lanes. It doesn't have embedded clock and reset
+ control module, so the proper interface initialization is supposed to be
+ performed by software. There four in- and four outbound iATU regions
+ which can be used to emit all required TLP types on the PCIe bus.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ const: baikal,bt1-pcie
+
+ reg:
+ description:
+ DBI, DBI2 and at least 4KB outbound iATU-capable region for the
+ peripheral devices CFG-space access.
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: config
+
+ interrupts:
+ description:
+ MSI, AER, PME, Hot-plug, Link Bandwidth Management, Link Equalization
+ request and eight Read/Write eDMA IRQ lines are available.
+ maxItems: 14
+
+ interrupt-names:
+ items:
+ - const: dma0
+ - const: dma1
+ - const: dma2
+ - const: dma3
+ - const: dma4
+ - const: dma5
+ - const: dma6
+ - const: dma7
+ - const: msi
+ - const: aer
+ - const: pme
+ - const: hp
+ - const: bw_mg
+ - const: l_eq
+
+ clocks:
+ description:
+ DBI (attached to the APB bus), AXI-bus master and slave interfaces
+ are fed up by the dedicated application clocks. A common reference
+ clock signal is supposed to be attached to the corresponding Ref-pad
+ of the SoC. It will be redistributed amongst the controller core
+ sub-modules (pipe, core, aux, etc).
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: dbi
+ - const: mstr
+ - const: slv
+ - const: ref
+
+ resets:
+ description:
+ A comprehensive controller reset logic is supposed to be implemented
+ by software, so almost all the possible application and core reset
+ signals are exposed via the system CCU module.
+ maxItems: 9
+
+ reset-names:
+ items:
+ - const: mstr
+ - const: slv
+ - const: pwr
+ - const: hot
+ - const: phy
+ - const: core
+ - const: pipe
+ - const: sticky
+ - const: non-sticky
+
+ baikal,bt1-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the Baikal-T1 System Controller DT node. It's required to
+ access some additional PM, Reset-related and LTSSM signals.
+
+ num-lanes:
+ maximum: 4
+
+ max-link-speed:
+ maximum: 3
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ pcie@1f052000 {
+ compatible = "baikal,bt1-pcie";
+ device_type = "pci";
+ reg = <0x1f052000 0x1000>, <0x1f053000 0x1000>, <0x1bdbf000 0x1000>;
+ reg-names = "dbi", "dbi2", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x81000000 0 0x00000000 0x1bdb0000 0 0x00008000>,
+ <0x82000000 0 0x20000000 0x08000000 0 0x13db0000>;
+ bus-range = <0x0 0xff>;
+
+ interrupts = <GIC_SHARED 80 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 81 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 82 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 83 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 84 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 85 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 86 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 87 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 88 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 89 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 91 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 92 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 93 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dma0", "dma1", "dma2", "dma3",
+ "dma4", "dma5", "dma6", "dma7",
+ "msi", "aer", "pme", "hp", "bw_mg",
+ "l_eq";
+
+ clocks = <&ccu_sys 1>, <&ccu_axi 6>, <&ccu_axi 7>, <&clk_pcie>;
+ clock-names = "dbi", "mstr", "slv", "ref";
+
+ resets = <&ccu_axi 6>, <&ccu_axi 7>, <&ccu_sys 7>, <&ccu_sys 10>,
+ <&ccu_sys 4>, <&ccu_sys 6>, <&ccu_sys 5>, <&ccu_sys 8>,
+ <&ccu_sys 9>;
+ reset-names = "mstr", "slv", "pwr", "hot", "phy", "core", "pipe",
+ "sticky", "non-sticky";
+
+ reset-gpios = <&port0 0 GPIO_ACTIVE_LOW>;
+
+ num-lanes = <4>;
+ max-link-speed = <3>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml
index 0972868735fc..18e7981241b5 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml
@@ -11,8 +11,7 @@ maintainers:
- Scott Branden <scott.branden@broadcom.com>
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
- - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -34,13 +33,6 @@ properties:
description: >
Base address and length of the PCIe controller I/O register space
- interrupt-map: true
-
- interrupt-map-mask: true
-
- "#interrupt-cells":
- const: 1
-
ranges:
minItems: 1
maxItems: 2
@@ -54,16 +46,8 @@ properties:
items:
- const: pcie-phy
- bus-range: true
-
dma-coherent: true
- "#address-cells": true
-
- "#size-cells": true
-
- device_type: true
-
brcm,pcie-ob:
type: boolean
description: >
@@ -78,20 +62,24 @@ properties:
msi:
type: object
+ $ref: /schemas/interrupt-controller/msi-controller.yaml#
+ unevaluatedProperties: false
+
properties:
compatible:
items:
- const: brcm,iproc-msi
- msi-parent: true
+ interrupts:
+ maxItems: 4
- msi-controller: true
+ brcm,pcie-msi-inten:
+ type: boolean
+ description:
+ Needs to be present for some older iProc platforms that require the
+ interrupt enable registers to be set explicitly to enable MSI
- brcm,pcie-msi-inten:
- type: boolean
- description: >
- Needs to be present for some older iProc platforms that require the
- interrupt enable registers to be set explicitly to enable MSI
+ msi-parent: true
dependencies:
brcm,pcie-ob-axi-offset: ["brcm,pcie-ob"]
@@ -117,68 +105,70 @@ unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- bus {
- #address-cells = <1>;
- #size-cells = <1>;
- pcie0: pcie@18012000 {
- compatible = "brcm,iproc-pcie";
- reg = <0x18012000 0x1000>;
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
-
- linux,pci-domain = <0>;
-
- bus-range = <0x00 0xff>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x81000000 0 0 0x28000000 0 0x00010000>,
- <0x82000000 0 0x20000000 0x20000000 0 0x04000000>;
-
- phys = <&phy 0 5>;
- phy-names = "pcie-phy";
-
- brcm,pcie-ob;
- brcm,pcie-ob-axi-offset = <0x00000000>;
-
- msi-parent = <&msi0>;
-
- /* iProc event queue based MSI */
- msi0: msi {
- compatible = "brcm,iproc-msi";
- msi-controller;
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>,
- <GIC_SPI 97 IRQ_TYPE_NONE>,
- <GIC_SPI 98 IRQ_TYPE_NONE>,
- <GIC_SPI 99 IRQ_TYPE_NONE>;
- };
- };
-
- pcie1: pcie@18013000 {
- compatible = "brcm,iproc-pcie";
- reg = <0x18013000 0x1000>;
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
-
- linux,pci-domain = <1>;
-
- bus-range = <0x00 0xff>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x81000000 0 0 0x48000000 0 0x00010000>,
- <0x82000000 0 0x40000000 0x40000000 0 0x04000000>;
-
- phys = <&phy 1 6>;
- phy-names = "pcie-phy";
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gic: interrupt-controller {
+ #address-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ pcie@18012000 {
+ compatible = "brcm,iproc-pcie";
+ reg = <0x18012000 0x1000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+
+ linux,pci-domain = <0>;
+
+ bus-range = <0x00 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x28000000 0 0x00010000>,
+ <0x82000000 0 0x20000000 0x20000000 0 0x04000000>;
+
+ phys = <&phy 0 5>;
+ phy-names = "pcie-phy";
+
+ brcm,pcie-ob;
+ brcm,pcie-ob-axi-offset = <0x00000000>;
+
+ msi-parent = <&msi0>;
+
+ /* iProc event queue based MSI */
+ msi0: msi {
+ compatible = "brcm,iproc-msi";
+ msi-controller;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>,
+ <GIC_SPI 97 IRQ_TYPE_NONE>,
+ <GIC_SPI 98 IRQ_TYPE_NONE>,
+ <GIC_SPI 99 IRQ_TYPE_NONE>;
+ };
+ };
+ - |
+ pcie@18013000 {
+ compatible = "brcm,iproc-pcie";
+ reg = <0x18013000 0x1000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+
+ linux,pci-domain = <1>;
+
+ bus-range = <0x00 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x48000000 0 0x00010000>,
+ <0x82000000 0 0x40000000 0x40000000 0 0x04000000>;
+
+ phys = <&phy 1 6>;
+ phy-names = "pcie-phy";
};
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 0f064e4222f3..812ef5957cfc 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -4,23 +4,25 @@
$id: http://devicetree.org/schemas/pci/brcm,stb-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Brcmstb PCIe Host Controller Device Tree Bindings
+title: Brcmstb PCIe Host Controller
maintainers:
- - Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+ - Jim Quinlan <james.quinlan@broadcom.com>
properties:
compatible:
items:
- enum:
- brcm,bcm2711-pcie # The Raspberry Pi 4
+ - brcm,bcm2712-pcie # Raspberry Pi 5
- brcm,bcm4908-pcie
- brcm,bcm7211-pcie # Broadcom STB version of RPi4
- - brcm,bcm7278-pcie # Broadcom 7278 Arm
- brcm,bcm7216-pcie # Broadcom 7216 Arm
- - brcm,bcm7445-pcie # Broadcom 7445 Arm
+ - brcm,bcm7278-pcie # Broadcom 7278 Arm
- brcm,bcm7425-pcie # Broadcom 7425 MIPs
- brcm,bcm7435-pcie # Broadcom 7435 MIPs
+ - brcm,bcm7445-pcie # Broadcom 7445 Arm
+ - brcm,bcm7712-pcie # Broadcom STB sibling of Rpi 5
reg:
maxItems: 1
@@ -64,6 +66,24 @@ properties:
aspm-no-l0s: true
+ brcm,clkreq-mode:
+ description: A string that determines the operating
+ clkreq mode of the PCIe RC HW with respect to controlling the refclk
+ signal. There are three different modes -- "safe", which drives the
+ refclk signal unconditionally and will work for all devices but does
+ not provide any power savings; "no-l1ss" -- which provides Clock
+ Power Management, L0s, and L1, but cannot provide L1 substate (L1SS)
+ power savings. If the downstream device connected to the RC is L1SS
+ capable AND the OS enables L1SS, all PCIe traffic may abruptly halt,
+ potentially hanging the system; "default" -- which provides L0s, L1,
+ and L1SS, but not compliant to provide Clock Power Management;
+ specifically, may not be able to meet the T_CLRon max timing of 400ns
+ as specified in "Dynamic Clock Control", section 3.2.5.2.2 PCI
+ Express Mini CEM 2.1 specification. This situation is atypical and
+ should happen only with older devices.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ safe, no-l1ss, default ]
+
brcm,scb-sizes:
description: u64 giving the 64bit PCIe memory
viewport size of a memory controller. There may be up to
@@ -73,9 +93,23 @@ properties:
may have two component regions -- base and extended -- so
this information cannot be deduced from the dma-ranges.
$ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 1
+ maxItems: 3
+
+ resets:
+ minItems: 1
+ maxItems: 3
+
+ reset-names:
+ minItems: 1
items:
- minItems: 1
- maxItems: 3
+ - enum: [perst, rescal]
+ - const: bridge
+ - const: swinit
+
+ num-lanes:
+ default: 1
+ maximum: 4
required:
- compatible
@@ -90,7 +124,7 @@ required:
- msi-controller
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
- $ref: /schemas/interrupt-controller/msi-controller.yaml#
- if:
properties:
@@ -100,8 +134,7 @@ allOf:
then:
properties:
resets:
- items:
- - description: reset controller handling the PERST# signal
+ maxItems: 1
reset-names:
items:
@@ -118,12 +151,32 @@ allOf:
then:
properties:
resets:
+ maxItems: 1
+
+ reset-names:
items:
- - description: phandle pointing to the RESCAL reset controller
+ - const: rescal
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm7712-pcie
+ then:
+ properties:
+ resets:
+ minItems: 3
+ maxItems: 3
reset-names:
items:
- const: rescal
+ - const: bridge
+ - const: swinit
required:
- resets
@@ -137,49 +190,48 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
scb {
- #address-cells = <2>;
- #size-cells = <1>;
- pcie0: pcie@7d500000 {
- compatible = "brcm,bcm2711-pcie";
- reg = <0x0 0x7d500000 0x9310>;
- device_type = "pci";
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "pcie", "msi";
- interrupt-map-mask = <0x0 0x0 0x0 0x7>;
- interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH
- 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH
- 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH
- 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
-
- msi-parent = <&pcie0>;
- msi-controller;
- ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
- dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
- <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
- brcm,enable-ssc;
- brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>;
-
- /* PCIe bridge, Root Port */
- pci@0,0 {
- #address-cells = <3>;
- #size-cells = <2>;
- reg = <0x0 0x0 0x0 0x0 0x0>;
- compatible = "pciclass,0604";
- device_type = "pci";
- vpcie3v3-supply = <&vreg7>;
- ranges;
-
- /* PCIe endpoint */
- pci-ep@0,0 {
- assigned-addresses =
- <0x82010000 0x0 0xf8000000 0x6 0x00000000 0x0 0x2000>;
- reg = <0x0 0x0 0x0 0x0 0x0>;
- compatible = "pci14e4,1688";
- };
- };
+ #address-cells = <2>;
+ #size-cells = <1>;
+ pcie0: pcie@7d500000 {
+ compatible = "brcm,bcm2711-pcie";
+ reg = <0x0 0x7d500000 0x9310>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie", "msi";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+
+ msi-parent = <&pcie0>;
+ msi-controller;
+ ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
+ dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
+ <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
+ brcm,enable-ssc;
+ brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>;
+
+ /* PCIe bridge, Root Port */
+ pci@0,0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ vpcie3v3-supply = <&vreg7>;
+ ranges;
+
+ /* PCIe endpoint */
+ pci-ep@0,0 {
+ assigned-addresses = <0x82010000 0x0 0xf8000000 0x6 0x00000000 0x0 0x2000>;
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ compatible = "pci14e4,1688";
+ };
};
+ };
};
diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml
index e6ef1012a580..8735293962ee 100644
--- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml
@@ -10,7 +10,7 @@ maintainers:
- Tom Joseph <tjoseph@cadence.com>
allOf:
- - $ref: "cdns-pcie-ep.yaml#"
+ - $ref: cdns-pcie-ep.yaml#
properties:
compatible:
@@ -37,14 +37,14 @@ examples:
#size-cells = <2>;
pcie-ep@fc000000 {
- compatible = "cdns,cdns-pcie-ep";
- reg = <0x0 0xfc000000 0x0 0x01000000>,
- <0x0 0x80000000 0x0 0x40000000>;
- reg-names = "reg", "mem";
- cdns,max-outbound-regions = <16>;
- max-functions = /bits/ 8 <8>;
- phys = <&pcie_phy0>;
- phy-names = "pcie-phy";
+ compatible = "cdns,cdns-pcie-ep";
+ reg = <0x0 0xfc000000 0x0 0x01000000>,
+ <0x0 0x80000000 0x0 0x40000000>;
+ reg-names = "reg", "mem";
+ cdns,max-outbound-regions = <16>;
+ max-functions = /bits/ 8 <8>;
+ phys = <&pcie_phy0>;
+ phy-names = "pcie-phy";
};
};
...
diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
index 293b8ec318bc..a8190d9b100f 100644
--- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml
@@ -10,8 +10,7 @@ maintainers:
- Tom Joseph <tjoseph@cadence.com>
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
- - $ref: "cdns-pcie-host.yaml#"
+ - $ref: cdns-pcie-host.yaml#
properties:
compatible:
@@ -25,8 +24,6 @@ properties:
- const: reg
- const: cfg
- msi-parent: true
-
required:
- reg
- reg-names
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
index baeafda36ebe..47a302ba4ac9 100644
--- a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/cdns-pcie-ep.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/cdns-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence PCIe Device
@@ -10,8 +10,8 @@ maintainers:
- Tom Joseph <tjoseph@cadence.com>
allOf:
- - $ref: "cdns-pcie.yaml#"
- - $ref: "pci-ep.yaml#"
+ - $ref: cdns-pcie.yaml#
+ - $ref: pci-ep.yaml#
properties:
cdns,max-outbound-regions:
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
index a944f9bfffff..f4eb82e684bd 100644
--- a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/cdns-pcie-host.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/cdns-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence PCIe Host
@@ -10,8 +10,8 @@ maintainers:
- Tom Joseph <tjoseph@cadence.com>
allOf:
- - $ref: "/schemas/pci/pci-bus.yaml#"
- - $ref: "cdns-pcie.yaml#"
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: cdns-pcie.yaml#
properties:
cdns,max-outbound-regions:
diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie.yaml
index df4fe28222b0..2e14f422e829 100644
--- a/Documentation/devicetree/bindings/pci/cdns-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/cdns-pcie.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/cdns-pcie.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/cdns-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence PCIe Core
diff --git a/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml
new file mode 100644
index 000000000000..b910a42e0843
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/cix,sky1-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CIX Sky1 PCIe Root Complex
+
+maintainers:
+ - Hans Zhang <hans.zhang@cixtech.com>
+
+description:
+ PCIe root complex controller based on the Cadence PCIe core.
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ const: cix,sky1-pcie-host
+
+ reg:
+ items:
+ - description: PCIe controller registers.
+ - description: ECAM registers.
+ - description: Remote CIX System Unit strap registers.
+ - description: Remote CIX System Unit status registers.
+ - description: Region for sending messages registers.
+
+ reg-names:
+ items:
+ - const: reg
+ - const: cfg
+ - const: rcsu_strap
+ - const: rcsu_status
+ - const: msg
+
+ ranges:
+ maxItems: 3
+
+required:
+ - compatible
+ - ranges
+ - bus-range
+ - device_type
+ - interrupt-map
+ - interrupt-map-mask
+ - msi-map
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@a010000 {
+ compatible = "cix,sky1-pcie-host";
+ reg = <0x00 0x0a010000 0x00 0x10000>,
+ <0x00 0x2c000000 0x00 0x4000000>,
+ <0x00 0x0a000300 0x00 0x100>,
+ <0x00 0x0a000400 0x00 0x100>,
+ <0x00 0x60000000 0x00 0x00100000>;
+ reg-names = "reg", "cfg", "rcsu_strap", "rcsu_status", "msg";
+ ranges = <0x01000000 0x00 0x60100000 0x00 0x60100000 0x00 0x00100000>,
+ <0x02000000 0x00 0x60200000 0x00 0x60200000 0x00 0x1fe00000>,
+ <0x43000000 0x18 0x00000000 0x18 0x00000000 0x04 0x00000000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0xc0 0xff>;
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH 0>,
+ <0 0 0 2 &gic 0 0 GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH 0>,
+ <0 0 0 3 &gic 0 0 GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH 0>,
+ <0 0 0 4 &gic 0 0 GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH 0>;
+ msi-map = <0xc000 &gic_its 0xc000 0x4000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
index 92efbf0f1297..378dd1c8e2ee 100644
--- a/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
+++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml
@@ -51,7 +51,7 @@ description: |
<0x6000 0 0 4 &pci_intc 2>;
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
new file mode 100644
index 000000000000..cddbe21f99f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
@@ -0,0 +1,255 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/fsl,imx6q-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX6 PCIe RC/EP controller
+
+maintainers:
+ - Lucas Stach <l.stach@pengutronix.de>
+ - Richard Zhu <hongxing.zhu@nxp.com>
+
+description:
+ Generic Freescale i.MX PCIe Root Port and Endpoint controller
+ properties.
+
+properties:
+ clocks:
+ minItems: 3
+ maxItems: 5
+
+ clock-names:
+ minItems: 3
+ maxItems: 5
+
+ num-lanes:
+ const: 1
+
+ fsl,imx7d-pcie-phy:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to an fsl,imx7d-pcie-phy node. Additional
+ required properties for imx7d-pcie, imx7d-pcie-ep, imx8mq-pcie,
+ and imx8mq-pcie-ep.
+
+ power-domains:
+ minItems: 1
+ items:
+ - description: The phandle pointing to the DISPLAY domain for
+ imx6sx-pcie, imx6sx-pcie-ep, to PCIE_PHY power domain for
+ imx7d-pcie, imx7d-pcie-ep, imx8mq-pcie and imx8mq-pcie-ep.
+ - description: The phandle pointing to the PCIE_PHY power domains
+ for imx6sx-pcie and imx6sx-pcie-ep.
+
+ power-domain-names:
+ minItems: 1
+ items:
+ - const: pcie
+ - const: pcie_phy
+
+ resets:
+ minItems: 2
+ maxItems: 3
+ description: Phandles to PCIe-related reset lines exposed by SRC
+ IP block. Additional required by imx7d-pcie, imx7d-pcie-ep,
+ imx8mq-pcie, and imx8mq-pcie-ep.
+
+ reset-names:
+ minItems: 2
+ maxItems: 3
+
+ fsl,tx-deemph-gen1:
+ description: Gen1 De-emphasis value (optional required).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ fsl,tx-deemph-gen2-3p5db:
+ description: Gen2 (3.5db) De-emphasis value (optional required).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+
+ fsl,tx-deemph-gen2-6db:
+ description: Gen2 (6db) De-emphasis value (optional required).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 20
+
+ fsl,tx-swing-full:
+ description: Gen2 TX SWING FULL value (optional required).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 127
+
+ fsl,tx-swing-low:
+ description: TX launch amplitude swing_low value (optional required).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 127
+
+ fsl,max-link-speed:
+ description: Specify PCI Gen for link capability (optional required).
+ Note that the IMX6 LVDS clock outputs do not meet gen2 jitter
+ requirements and thus for gen2 capability a gen2 compliant clock
+ generator should be used and configured.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3, 4]
+ default: 1
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: pcie-phy
+
+ vpcie-supply:
+ description: Should specify the regulator in charge of PCIe port power.
+ The regulator will be enabled when initializing the PCIe host and
+ disabled either as part of the init process or when shutting down
+ the host (optional required).
+
+ vph-supply:
+ description: Should specify the regulator in charge of VPH one of
+ the three PCIe PHY powers. This regulator can be supplied by both
+ 1.8v and 3.3v voltage supplies (optional required).
+
+required:
+ - clocks
+ - clock-names
+ - num-lanes
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sx-pcie
+ - fsl,imx6sx-pcie-ep
+ then:
+ properties:
+ clock-names:
+ items:
+ - {}
+ - {}
+ - const: pcie_phy
+ - const: pcie_inbound_axi
+ power-domains:
+ minItems: 2
+ power-domain-names:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mq-pcie
+ - fsl,imx8mq-pcie-ep
+ then:
+ properties:
+ clock-names:
+ items:
+ - {}
+ - {}
+ - const: pcie_phy
+ - const: pcie_aux
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6q-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx7d-pcie
+ - fsl,imx6q-pcie-ep
+ - fsl,imx6qp-pcie-ep
+ - fsl,imx7d-pcie-ep
+ then:
+ properties:
+ clock-names:
+ maxItems: 3
+ contains:
+ const: pcie_phy
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mm-pcie
+ - fsl,imx8mp-pcie
+ - fsl,imx8mm-pcie-ep
+ - fsl,imx8mp-pcie-ep
+ then:
+ properties:
+ clock-names:
+ maxItems: 3
+ contains:
+ const: pcie_aux
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6q-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx6q-pcie-ep
+ - fsl,imx6qp-pcie-ep
+ then:
+ properties:
+ power-domains: false
+ power-domain-names: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6sx-pcie
+ - fsl,imx6q-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx95-pcie
+ - fsl,imx6sx-pcie-ep
+ - fsl,imx6q-pcie-ep
+ - fsl,imx6qp-pcie-ep
+ then:
+ properties:
+ power-domains:
+ maxItems: 1
+ power-domain-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6q-pcie
+ - fsl,imx6sx-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx7d-pcie
+ - fsl,imx8mq-pcie
+ - fsl,imx6q-pcie-ep
+ - fsl,imx6sx-pcie-ep
+ - fsl,imx6qp-pcie-ep
+ - fsl,imx7d-pcie-ep
+ - fsl,imx8mq-pcie-ep
+ then:
+ properties:
+ resets:
+ minItems: 3
+ reset-names:
+ items:
+ - const: pciephy
+ - const: apps
+ - const: turnoff
+ else:
+ properties:
+ resets:
+ maxItems: 2
+ reset-names:
+ items:
+ - const: apps
+ - const: turnoff
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
new file mode 100644
index 000000000000..0b3526de1d62
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/fsl,imx6q-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX6 PCIe Endpoint controller
+
+maintainers:
+ - Lucas Stach <l.stach@pengutronix.de>
+ - Richard Zhu <hongxing.zhu@nxp.com>
+
+description: |+
+ This PCIe controller is based on the Synopsys DesignWare PCIe IP and
+ thus inherits all the common properties defined in snps,dw-pcie-ep.yaml.
+ The controller instances are dual mode where in they can work either in
+ Root Port mode or Endpoint mode but one at a time.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8mm-pcie-ep
+ - fsl,imx8mq-pcie-ep
+ - fsl,imx8mp-pcie-ep
+ - fsl,imx8q-pcie-ep
+ - fsl,imx95-pcie-ep
+
+ clocks:
+ minItems: 3
+ items:
+ - description: PCIe bridge clock.
+ - description: PCIe bus clock.
+ - description: PCIe PHY clock.
+ - description: Additional required clock entry for imx6sx-pcie,
+ imx6sx-pcie-ep, imx8mq-pcie, imx8mq-pcie-ep.
+
+ clock-names:
+ minItems: 3
+ maxItems: 4
+
+ interrupts:
+ items:
+ - description: builtin eDMA interrupter.
+
+ interrupt-names:
+ items:
+ - const: dma
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
+ - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8mm-pcie-ep
+ - fsl,imx8mq-pcie-ep
+ - fsl,imx8mp-pcie-ep
+ then:
+ properties:
+ reg:
+ minItems: 4
+ maxItems: 4
+ reg-names:
+ items:
+ - const: dbi
+ - const: addr_space
+ - const: dbi2
+ - const: atu
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8q-pcie-ep
+ then:
+ properties:
+ reg:
+ maxItems: 2
+ reg-names:
+ items:
+ - const: dbi
+ - const: addr_space
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx95-pcie-ep
+ then:
+ properties:
+ reg:
+ minItems: 6
+ maxItems: 6
+ reg-names:
+ items:
+ - const: dbi
+ - const: atu
+ - const: dbi2
+ - const: app
+ - const: dma
+ - const: addr_space
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8mq-pcie-ep
+ - fsl,imx95-pcie-ep
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_phy
+ - const: pcie_aux
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8mm-pcie-ep
+ - fsl,imx8mp-pcie-ep
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_aux
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imxq-pcie-ep
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: dbi
+ - const: mstr
+ - const: slv
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/power/imx8mp-power.h>
+ #include <dt-bindings/reset/imx8mp-reset.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie_ep: pcie-ep@33800000 {
+ compatible = "fsl,imx8mp-pcie-ep";
+ reg = <0x33800000 0x100000>,
+ <0x18000000 0x8000000>,
+ <0x33900000 0x100000>,
+ <0x33b00000 0x100000>;
+ reg-names = "dbi", "addr_space", "dbi2", "atu";
+ clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
+ <&clk IMX8MP_CLK_HSIO_AXI>,
+ <&clk IMX8MP_CLK_PCIE_ROOT>;
+ clock-names = "pcie", "pcie_bus", "pcie_aux";
+ assigned-clocks = <&clk IMX8MP_CLK_PCIE_AUX>;
+ assigned-clock-rates = <10000000>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_50M>;
+ num-lanes = <1>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; /* eDMA */
+ interrupt-names = "dma";
+ fsl,max-link-speed = <3>;
+ power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_PCIE>;
+ resets = <&src IMX8MP_RESET_PCIE_CTRL_APPS_EN>,
+ <&src IMX8MP_RESET_PCIE_CTRL_APPS_TURNOFF>;
+ reset-names = "apps", "turnoff";
+ phys = <&pcie_phy>;
+ phy-names = "pcie-phy";
+ num-ib-windows = <4>;
+ num-ob-windows = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 376e739bcad4..ca5f2970f217 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -13,9 +13,11 @@ maintainers:
description: |+
This PCIe host controller is based on the Synopsys DesignWare PCIe IP
and thus inherits all the common properties defined in snps,dw-pcie.yaml.
+ The controller instances are dual mode where in they can work either in
+ Root Port mode or Endpoint mode but one at a time.
-allOf:
- - $ref: /schemas/pci/snps,dw-pcie.yaml#
+ See fsl,imx6q-pcie-ep.yaml for details on the Endpoint mode device tree
+ bindings.
properties:
compatible:
@@ -27,24 +29,8 @@ properties:
- fsl,imx8mq-pcie
- fsl,imx8mm-pcie
- fsl,imx8mp-pcie
-
- reg:
- items:
- - description: Data Bus Interface (DBI) registers.
- - description: PCIe configuration space region.
-
- reg-names:
- items:
- - const: dbi
- - const: config
-
- interrupts:
- items:
- - description: builtin MSI controller.
-
- interrupt-names:
- items:
- - const: msi
+ - fsl,imx95-pcie
+ - fsl,imx8q-pcie
clocks:
minItems: 3
@@ -53,87 +39,24 @@ properties:
- description: PCIe bus clock.
- description: PCIe PHY clock.
- description: Additional required clock entry for imx6sx-pcie,
- imx8mq-pcie.
+ imx6sx-pcie-ep, imx8mq-pcie, imx8mq-pcie-ep.
+ - description: PCIe reference clock.
clock-names:
minItems: 3
- items:
- - const: pcie
- - const: pcie_bus
- - const: pcie_phy
- - const: pcie_inbound_axi for imx6sx-pcie, pcie_aux for imx8mq-pcie
+ maxItems: 5
- num-lanes:
- const: 1
-
- fsl,imx7d-pcie-phy:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: A phandle to an fsl,imx7d-pcie-phy node. Additional
- required properties for imx7d-pcie and imx8mq-pcie.
-
- power-domains:
- items:
- - description: The phandle pointing to the DISPLAY domain for
- imx6sx-pcie, to PCIE_PHY power domain for imx7d-pcie and
- imx8mq-pcie.
- - description: The phandle pointing to the PCIE_PHY power domains
- for imx6sx-pcie.
-
- power-domain-names:
+ interrupts:
+ minItems: 1
items:
- - const: pcie
- - const: pcie_phy
-
- resets:
- maxItems: 3
- description: Phandles to PCIe-related reset lines exposed by SRC
- IP block. Additional required by imx7d-pcie and imx8mq-pcie.
+ - description: builtin MSI controller.
+ - description: builtin DMA controller.
- reset-names:
+ interrupt-names:
+ minItems: 1
items:
- - const: pciephy
- - const: apps
- - const: turnoff
-
- fsl,tx-deemph-gen1:
- description: Gen1 De-emphasis value (optional required).
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 0
-
- fsl,tx-deemph-gen2-3p5db:
- description: Gen2 (3.5db) De-emphasis value (optional required).
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 0
-
- fsl,tx-deemph-gen2-6db:
- description: Gen2 (6db) De-emphasis value (optional required).
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 20
-
- fsl,tx-swing-full:
- description: Gen2 TX SWING FULL value (optional required).
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 127
-
- fsl,tx-swing-low:
- description: TX launch amplitude swing_low value (optional required).
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 127
-
- fsl,max-link-speed:
- description: Specify PCI Gen for link capability (optional required).
- Note that the IMX6 LVDS clock outputs do not meet gen2 jitter
- requirements and thus for gen2 capability a gen2 compliant clock
- generator should be used and configured.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 3, 4]
- default: 1
-
- phys:
- maxItems: 1
-
- phy-names:
- const: pcie-phy
+ - const: msi
+ - const: dma
reset-gpio:
description: Should specify the GPIO for controlling the PCI bus device
@@ -146,17 +69,6 @@ properties:
L=operation state) (optional required).
type: boolean
- vpcie-supply:
- description: Should specify the regulator in charge of PCIe port power.
- The regulator will be enabled when initializing the PCIe host and
- disabled either as part of the init process or when shutting down
- the host (optional required).
-
- vph-supply:
- description: Should specify the regulator in charge of VPH one of
- the three PCIe PHY powers. This regulator can be supplied by both
- 1.8v and 3.3v voltage supplies (optional required).
-
required:
- compatible
- reg
@@ -166,14 +78,148 @@ required:
- device_type
- bus-range
- ranges
- - num-lanes
- interrupts
- interrupt-names
- "#interrupt-cells"
- interrupt-map-mask
- interrupt-map
- - clocks
- - clock-names
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+ - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx6q-pcie
+ - fsl,imx6sx-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx7d-pcie
+ - fsl,imx8mq-pcie
+ - fsl,imx8mm-pcie
+ - fsl,imx8mp-pcie
+ then:
+ properties:
+ reg:
+ maxItems: 2
+ reg-names:
+ items:
+ - const: dbi
+ - const: config
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx95-pcie
+ then:
+ properties:
+ reg:
+ minItems: 4
+ maxItems: 4
+ reg-names:
+ items:
+ - const: dbi
+ - const: config
+ - const: atu
+ - const: app
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx6sx-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_phy
+ - const: pcie_inbound_axi
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8mq-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_phy
+ - const: pcie_aux
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx6q-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx7d-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_phy
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8mm-pcie
+ - fsl,imx8mp-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_aux
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8q-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: dbi
+ - const: mstr
+ - const: slv
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx95-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+ - const: pcie_phy
+ - const: pcie_aux
+ - const: ref
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml
new file mode 100644
index 000000000000..d78a6d1f7198
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/fsl,layerscape-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape PCIe Endpoint(EP) controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ This PCIe EP controller is based on the Synopsys DesignWare PCIe IP.
+
+ This controller derives its clocks from the Reset Configuration Word (RCW)
+ which is used to describe the PLL settings at the time of chip-reset.
+
+ Also as per the available Reference Manuals, there is no specific 'version'
+ register available in the Freescale PCIe controller register set,
+ which can allow determining the underlying DesignWare PCIe controller version
+ information.
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls2088a-pcie-ep
+ - fsl,ls1088a-pcie-ep
+ - fsl,ls1046a-pcie-ep
+ - fsl,ls1028a-pcie-ep
+ - fsl,lx2160ar2-pcie-ep
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: regs
+ - const: addr_space
+
+ fsl,pcie-scfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the SCFG device node. The second entry is the
+ physical PCIe controller index starting from '0'. This is used to get
+ SCFG PEXN registers.
+
+ big-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: If the PEX_LUT and PF register block is in big-endian, specify
+ this property.
+
+ dma-coherent: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,ls1028a-pcie-ep
+ - fsl,ls1046a-pcie-ep
+ - fsl,ls1088a-pcie-ep
+ then:
+ properties:
+ interrupt-names:
+ items:
+ - const: pme
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie_ep1: pcie-ep@3400000 {
+ compatible = "fsl,ls1028a-pcie-ep";
+ reg = <0x00 0x03400000 0x0 0x00100000
+ 0x80 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* PME interrupt */
+ interrupt-names = "pme";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml
new file mode 100644
index 000000000000..be79712836c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml
@@ -0,0 +1,182 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/fsl,layerscape-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape PCIe Root Complex(RC) controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ This PCIe RC controller is based on the Synopsys DesignWare PCIe IP
+
+ This controller derives its clocks from the Reset Configuration Word (RCW)
+ which is used to describe the PLL settings at the time of chip-reset.
+
+ Also as per the available Reference Manuals, there is no specific 'version'
+ register available in the Freescale PCIe controller register set,
+ which can allow determining the underlying DesignWare PCIe controller version
+ information.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,ls1012a-pcie
+ - fsl,ls1021a-pcie
+ - fsl,ls1028a-pcie
+ - fsl,ls1043a-pcie
+ - fsl,ls1046a-pcie
+ - fsl,ls1088a-pcie
+ - fsl,ls2080a-pcie
+ - fsl,ls2085a-pcie
+ - fsl,ls2088a-pcie
+ - items:
+ - const: fsl,lx2160ar2-pcie
+ - const: fsl,ls2088a-pcie
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: regs
+ - const: config
+
+ fsl,pcie-scfg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A phandle to the SCFG device node. The second entry is the
+ physical PCIe controller index starting from '0'. This is used to get
+ SCFG PEXN registers.
+ items:
+ items:
+ - description: A phandle to the SCFG device node
+ - description: PCIe controller index starting from '0'
+ maxItems: 1
+
+ big-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: If the PEX_LUT and PF register block is in big-endian, specify
+ this property.
+
+ dma-coherent: true
+
+ msi-parent: true
+
+ iommu-map: true
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+
+ num-viewport:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Number of outbound view ports configured in hardware. It's the same as
+ the number of outbound AT windows.
+ maximum: 256
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#address-cells"
+ - "#size-cells"
+ - device_type
+ - bus-range
+ - ranges
+ - interrupts
+ - interrupt-names
+ - "#interrupt-cells"
+ - interrupt-map-mask
+ - interrupt-map
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,ls1028a-pcie
+ - fsl,ls1046a-pcie
+ - fsl,ls1043a-pcie
+ - fsl,ls1012a-pcie
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+ interrupt-names:
+ items:
+ - const: pme
+ - const: aer
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,ls2080a-pcie
+ - fsl,ls2085a-pcie
+ - fsl,ls2088a-pcie
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names:
+ items:
+ - const: intr
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,ls1088a-pcie
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names:
+ items:
+ - const: aer
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@3400000 {
+ compatible = "fsl,ls1088a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
+ <0x20 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+ interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+ interrupt-names = "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ dma-coherent;
+ device_type = "pci";
+ bus-range = <0x0 0xff>;
+ ranges = <0x81000000 0x0 0x00000000 0x20 0x00010000 0x0 0x00010000 /* downstream I/O */
+ 0x82000000 0x0 0x40000000 0x20 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 0 109 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 0 110 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 0 111 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 0 112 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml b/Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml
new file mode 100644
index 000000000000..28759ab1caaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/pci/fsl,mpc8xxx-pci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MPC83xx PCI/PCI-X/PCIe controllers
+
+description:
+ Binding for the PCI/PCI-X/PCIe host bridges on MPC8xxx SoCs
+
+maintainers:
+ - J. Neuschäfer <j.neuschaefer@gmx.net>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,mpc8314-pcie
+ - fsl,mpc8349-pci
+ - fsl,mpc8540-pci
+ - fsl,mpc8548-pcie
+ - fsl,mpc8641-pcie
+ - items:
+ - enum:
+ - fsl,mpc8308-pcie
+ - fsl,mpc8315-pcie
+ - fsl,mpc8377-pcie
+ - fsl,mpc8378-pcie
+ - const: fsl,mpc8314-pcie
+ - items:
+ - const: fsl,mpc8360-pci
+ - const: fsl,mpc8349-pci
+ - items:
+ - const: fsl,mpc8540-pcix
+ - const: fsl,mpc8540-pci
+
+ reg:
+ minItems: 1
+ items:
+ - description: internal registers
+ - description: config space access registers
+
+ clock-frequency: true
+
+ interrupts:
+ items:
+ - description: Consolidated PCI interrupt
+
+ fsl,pci-agent-force-enum:
+ type: boolean
+ description:
+ Typically any Freescale PCI-X bridge hardware strapped into Agent mode is
+ prevented from enumerating the bus. The PrPMC form-factor requires all
+ mezzanines to be PCI-X Agents, but one per system may still enumerate the
+ bus.
+
+ This property allows a PCI-X bridge to be used for bus enumeration
+ despite being strapped into Agent mode.
+
+required:
+ - reg
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pcie@e0009000 {
+ compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie";
+ reg = <0xe0009000 0x00001000>;
+ ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xb1000000 0 0x00800000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ bus-range = <0 255>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0 0 0 1 &ipic 1 IRQ_TYPE_LEVEL_LOW
+ 0 0 0 2 &ipic 1 IRQ_TYPE_LEVEL_LOW
+ 0 0 0 3 &ipic 1 IRQ_TYPE_LEVEL_LOW
+ 0 0 0 4 &ipic 1 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <0>;
+ };
+
+ - |
+ pci@ef008000 {
+ compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
+ reg = <0xef008000 0x1000>;
+ ranges = <0x02000000 0 0x80000000 0x80000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xd0000000 0 0x01000000>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ clock-frequency = <33333333>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = </* IDSEL */
+ 0xe000 0 0 1 &mpic 2 1
+ 0xe000 0 0 2 &mpic 3 1>;
+ interrupts-extended = <&mpic 24 2>;
+ bus-range = <0 0>;
+ fsl,pci-agent-force-enum;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pci/fsl,pci.txt b/Documentation/devicetree/bindings/pci/fsl,pci.txt
deleted file mode 100644
index d8ac4a768e7e..000000000000
--- a/Documentation/devicetree/bindings/pci/fsl,pci.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Bus Enumeration by Freescale PCI-X Agent
-
-Typically any Freescale PCI-X bridge hardware strapped into Agent mode
-is prevented from enumerating the bus. The PrPMC form-factor requires
-all mezzanines to be PCI-X Agents, but one per system may still
-enumerate the bus.
-
-The property defined below will allow a PCI-X bridge to be used for bus
-enumeration despite being strapped into Agent mode.
-
-Required properties:
-- fsl,pci-agent-force-enum : There is no value associated with this
- property. The property itself is treated as a boolean.
-
-Example:
-
- /* PCI-X bridge known to be PrPMC Monarch */
- pci0: pci@ef008000 {
- fsl,pci-agent-force-enum;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
- device_type = "pci";
- ...
- ...
- };
diff --git a/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml b/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml
index c9f04999c9cf..e863519f3161 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml
@@ -37,7 +37,8 @@ properties:
minItems: 3
maxItems: 4
- clocks: true
+ clocks:
+ maxItems: 5
clock-names:
items:
diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
index d25423aa7167..420d551e9af9 100644
--- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
@@ -102,21 +102,25 @@ properties:
As described in IEEE Std 1275-1994, but must provide at least a
definition of non-prefetchable memory. One or both of prefetchable Memory
and IO Space may also be provided.
- minItems: 1
- maxItems: 3
dma-coherent: true
iommu-map: true
iommu-map-mask: true
msi-parent: true
+ ats-supported:
+ description:
+ Indicates that a PCIe host controller supports ATS, and can handle Memory
+ Requests with Address Type (AT).
+ type: boolean
+
required:
- compatible
- reg
- ranges
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml b/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
index debfb54a8042..3cae2e0f7f5e 100644
--- a/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
+++ b/Documentation/devicetree/bindings/pci/intel,ixp4xx-pci.yaml
@@ -12,7 +12,7 @@ maintainers:
description: PCI host controller found in the Intel IXP4xx SoC series.
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml
index e87ff27526ff..b19f61ae72fb 100644
--- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/intel,keembay-pcie-ep.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/intel,keembay-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel Keem Bay PCIe controller Endpoint mode
@@ -53,17 +53,17 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
pcie-ep@37000000 {
- compatible = "intel,keembay-pcie-ep";
- reg = <0x37000000 0x00001000>,
- <0x37100000 0x00001000>,
- <0x37300000 0x00001000>,
- <0x36000000 0x01000000>,
- <0x37800000 0x00000200>;
- reg-names = "dbi", "dbi2", "atu", "addr_space", "apb";
- interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 108 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "pcie", "pcie_ev", "pcie_err", "pcie_mem_access";
- num-lanes = <2>;
+ compatible = "intel,keembay-pcie-ep";
+ reg = <0x37000000 0x00001000>,
+ <0x37100000 0x00001000>,
+ <0x37300000 0x00001000>,
+ <0x36000000 0x01000000>,
+ <0x37800000 0x00000200>;
+ reg-names = "dbi", "dbi2", "atu", "addr_space", "apb";
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 108 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie", "pcie_ev", "pcie_err", "pcie_mem_access";
+ num-lanes = <2>;
};
diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml
index ed4400c9ac09..dd71e3d6bf94 100644
--- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/intel,keembay-pcie.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/intel,keembay-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel Keem Bay PCIe controller Root Complex mode
@@ -11,7 +11,7 @@ maintainers:
- Srikanth Thokala <srikanth.thokala@intel.com>
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -75,23 +75,23 @@ examples:
#define KEEM_BAY_A53_PCIE
#define KEEM_BAY_A53_AUX_PCIE
pcie@37000000 {
- compatible = "intel,keembay-pcie";
- reg = <0x37000000 0x00001000>,
- <0x37300000 0x00001000>,
- <0x36e00000 0x00200000>,
- <0x37800000 0x00000200>;
- reg-names = "dbi", "atu", "config", "apb";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x02000000 0 0x36000000 0x36000000 0 0x00e00000>;
- interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "pcie", "pcie_ev", "pcie_err";
- clocks = <&scmi_clk KEEM_BAY_A53_PCIE>,
- <&scmi_clk KEEM_BAY_A53_AUX_PCIE>;
- clock-names = "master", "aux";
- reset-gpios = <&pca2 9 GPIO_ACTIVE_LOW>;
- num-lanes = <2>;
+ compatible = "intel,keembay-pcie";
+ reg = <0x37000000 0x00001000>,
+ <0x37300000 0x00001000>,
+ <0x36e00000 0x00200000>,
+ <0x37800000 0x00000200>;
+ reg-names = "dbi", "atu", "config", "apb";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0x36000000 0x36000000 0 0x00e00000>;
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie", "pcie_ev", "pcie_err";
+ clocks = <&scmi_clk KEEM_BAY_A53_PCIE>,
+ <&scmi_clk KEEM_BAY_A53_AUX_PCIE>;
+ clock-names = "master", "aux";
+ reset-gpios = <&pca2 9 GPIO_ACTIVE_LOW>;
+ num-lanes = <2>;
};
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
deleted file mode 100644
index ee8a4791a78b..000000000000
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Freescale Layerscape PCIe controller
-
-This PCIe host controller is based on the Synopsys DesignWare PCIe IP
-and thus inherits all the common properties defined in snps,dw-pcie.yaml.
-
-This controller derives its clocks from the Reset Configuration Word (RCW)
-which is used to describe the PLL settings at the time of chip-reset.
-
-Also as per the available Reference Manuals, there is no specific 'version'
-register available in the Freescale PCIe controller register set,
-which can allow determining the underlying DesignWare PCIe controller version
-information.
-
-Required properties:
-- compatible: should contain the platform identifier such as:
- RC mode:
- "fsl,ls1021a-pcie"
- "fsl,ls2080a-pcie", "fsl,ls2085a-pcie"
- "fsl,ls2088a-pcie"
- "fsl,ls1088a-pcie"
- "fsl,ls1046a-pcie"
- "fsl,ls1043a-pcie"
- "fsl,ls1012a-pcie"
- "fsl,ls1028a-pcie"
- EP mode:
- "fsl,ls1028a-pcie-ep", "fsl,ls-pcie-ep"
- "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
- "fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep"
- "fsl,ls2088a-pcie-ep", "fsl,ls-pcie-ep"
- "fsl,lx2160ar2-pcie-ep", "fsl,ls-pcie-ep"
-- reg: base addresses and lengths of the PCIe controller register blocks.
-- interrupts: A list of interrupt outputs of the controller. Must contain an
- entry for each entry in the interrupt-names property.
-- interrupt-names: It could include the following entries:
- "aer": Used for interrupt line which reports AER events when
- non MSI/MSI-X/INTx mode is used
- "pme": Used for interrupt line which reports PME events when
- non MSI/MSI-X/INTx mode is used
- "intr": Used for SoCs(like ls2080a, lx2160a, ls2080a, ls2088a, ls1088a)
- which has a single interrupt line for miscellaneous controller
- events(could include AER and PME events).
-- fsl,pcie-scfg: Must include two entries.
- The first entry must be a link to the SCFG device node
- The second entry is the physical PCIe controller index starting from '0'.
- This is used to get SCFG PEXN registers
-- dma-coherent: Indicates that the hardware IP block can ensure the coherency
- of the data transferred from/to the IP block. This can avoid the software
- cache flush/invalid actions, and improve the performance significantly.
-
-Optional properties:
-- big-endian: If the PEX_LUT and PF register block is in big-endian, specify
- this property.
-
-Example:
-
- pcie@3400000 {
- compatible = "fsl,ls1088a-pcie";
- reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
- <0x20 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
- interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
- interrupt-names = "aer";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- num-viewport = <256>;
- bus-range = <0x0 0xff>;
- ranges = <0x81000000 0x0 0x00000000 0x20 0x00010000 0x0 0x00010000 /* downstream I/O */
- 0x82000000 0x0 0x40000000 0x20 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 0 109 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 0 110 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 0 111 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 0 112 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- };
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
deleted file mode 100644
index b40fb5d15d3d..000000000000
--- a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-NXP Layerscape PCIe Gen4 controller
-
-This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all
-the common properties defined in mobiveil-pcie.txt.
-
-Required properties:
-- compatible: should contain the platform identifier such as:
- "fsl,lx2160a-pcie"
-- reg: base addresses and lengths of the PCIe controller register blocks.
- "csr_axi_slave": Bridge config registers
- "config_axi_slave": PCIe controller registers
-- interrupts: A list of interrupt outputs of the controller. Must contain an
- entry for each entry in the interrupt-names property.
-- interrupt-names: It could include the following entries:
- "intr": The interrupt that is asserted for controller interrupts
- "aer": Asserted for aer interrupt when chip support the aer interrupt with
- none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
- "pme": Asserted for pme interrupt when chip support the pme interrupt with
- none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
-- dma-coherent: Indicates that the hardware IP block can ensure the coherency
- of the data transferred from/to the IP block. This can avoid the software
- cache flush/invalid actions, and improve the performance significantly.
-- msi-parent : See the generic MSI binding described in
- Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-Example:
-
- pcie@3400000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
- 0x80 0x00000000 0x0 0x00001000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- apio-wins = <8>;
- ppio-wins = <8>;
- dma-coherent;
- bus-range = <0x0 0xff>;
- msi-parent = <&its>;
- ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml
index a8324a9bd002..e5bba63aa947 100644
--- a/Documentation/devicetree/bindings/pci/loongson.yaml
+++ b/Documentation/devicetree/bindings/pci/loongson.yaml
@@ -13,7 +13,7 @@ description: |+
PCI host controller found on Loongson PCHs and SoCs.
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -32,7 +32,6 @@ properties:
minItems: 1
maxItems: 3
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/pci/marvell,armada-3700-pcie.yaml b/Documentation/devicetree/bindings/pci/marvell,armada-3700-pcie.yaml
new file mode 100644
index 000000000000..8403c79634ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/marvell,armada-3700-pcie.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/marvell,armada-3700-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 3700 (Aardvark) PCIe Controller
+
+maintainers:
+ - Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+ - Pali Rohár <pali@kernel.org>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ const: marvell,armada-3700-pcie
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ msi-controller: true
+
+ msi-parent:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ reset-gpios:
+ description: PCIe reset GPIO signals.
+
+ interrupt-controller:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ required:
+ - interrupt-controller
+ - '#interrupt-cells'
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#interrupt-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@d0070000 {
+ compatible = "marvell,armada-3700-pcie";
+ device_type = "pci";
+ reg = <0 0xd0070000 0 0x20000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ msi-controller;
+ msi-parent = <&pcie0>;
+ ranges = <0x82000000 0 0xe8000000 0 0xe8000000 0 0x1000000>,
+ <0x81000000 0 0xe9000000 0 0xe9000000 0 0x10000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc 0>,
+ <0 0 0 2 &pcie_intc 1>,
+ <0 0 0 3 &pcie_intc 2>,
+ <0 0 0 4 &pcie_intc 3>;
+ phys = <&comphy1 0>;
+ max-link-speed = <2>;
+ reset-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+
+ pcie_intc: interrupt-controller {
+ #address-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml b/Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml
new file mode 100644
index 000000000000..f3ba9230ce2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/marvell,armada8k-pcie.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/marvell,armada8k-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 7K/8K PCIe interface
+
+maintainers:
+ - Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+
+description:
+ This PCIe host controller is based on the Synopsys DesignWare PCIe IP.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,armada8k-pcie
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - marvell,armada8k-pcie
+ - const: snps,dw-pcie
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: ctrl
+ - const: config
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: reg
+
+ interrupts:
+ maxItems: 1
+
+ msi-parent:
+ maxItems: 1
+
+ phys:
+ minItems: 1
+ maxItems: 4
+
+ phy-names:
+ minItems: 1
+ maxItems: 4
+
+ marvell,reset-gpio:
+ maxItems: 1
+ deprecated: true
+
+required:
+ - interrupt-map
+ - clocks
+ - msi-parent
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pcie@f2600000 {
+ compatible = "marvell,armada8k-pcie", "snps,dw-pcie";
+ reg = <0xf2600000 0x10000>, <0xf6f00000 0x80000>;
+ reg-names = "ctrl", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ dma-coherent;
+ msi-parent = <&gic_v2m0>;
+
+ ranges = <0x81000000 0 0xf9000000 0xf9000000 0 0x10000>, /* downstream I/O */
+ <0x82000000 0 0xf6000000 0xf6000000 0 0xf00000>; /* non-prefetchable memory */
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ num-lanes = <1>;
+ clocks = <&cpm_syscon0 1 13>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml b/Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml
new file mode 100644
index 000000000000..3d68bfbe6feb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/marvell,kirkwood-pcie.yaml
@@ -0,0 +1,280 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/marvell,kirkwood-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell EBU PCIe interfaces
+
+maintainers:
+ - Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+ - Pali Rohár <pali@kernel.org>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-370-pcie
+ - marvell,armada-xp-pcie
+ - marvell,dove-pcie
+ - marvell,kirkwood-pcie
+
+ ranges:
+ description: >
+ The ranges describing the MMIO registers have the following layout:
+
+ 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+ where:
+
+ * r is a 32-bits value that gives the offset of the MMIO registers of
+ this PCIe interface, from the base of the internal registers.
+
+ * s is a 32-bits value that give the size of this MMIO registers area.
+ This range entry translates the '0x82000000 0 r' PCI address into the
+ 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part of the internal
+ register window (as identified by MBUS_ID(0xf0, 0x01)).
+
+ The ranges describing the MBus windows have the following layout:
+
+ 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0
+
+ where:
+
+ * t is the type of the MBus window (as defined by the standard PCI DT
+ bindings), 1 for I/O and 2 for memory.
+
+ * s is the PCI slot that corresponds to this PCIe interface
+
+ * w is the 'target ID' value for the MBus window
+
+ * a the 'attribute' value for the MBus window.
+
+ Since the location and size of the different MBus windows is not fixed in
+ hardware, and only determined in runtime, those ranges cover the full first
+ 4 GB of the physical address space, and do not translate into a valid CPU
+ address.
+
+ msi-parent:
+ maxItems: 1
+
+patternProperties:
+ '^pcie@':
+ type: object
+ allOf:
+ - $ref: /schemas/pci/pci-bus-common.yaml#
+ - $ref: /schemas/pci/pci-device.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: intx
+ - const: error
+
+ reset-delay-us:
+ default: 100000
+ description: todo
+
+ marvell,pcie-port:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+ description: todo
+
+ marvell,pcie-lane:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 3
+ description: todo
+
+ interrupt-controller:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ required:
+ - assigned-addresses
+ - clocks
+ - interrupt-map
+ - marvell,pcie-port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@f001000000000000 {
+ compatible = "marvell,armada-xp-pcie";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ bus-range = <0x00 0xff>;
+ msi-parent = <&mpic>;
+
+ ranges =
+ <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
+ 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */
+ 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */
+ 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */
+ 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */
+ 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */
+ 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */
+ 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */
+ 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */
+ 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */
+ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+ 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */
+ 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+ 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */
+ 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+ 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */
+
+ 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+ 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */
+ 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+ 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */
+ 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+ 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */
+ 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+ 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */
+
+ 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+ 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */
+
+ 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+ 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>;
+
+ pcie@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+ 0x81000000 0 0 0x81000000 0x1 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 58>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <0>;
+ num-lanes = <1>;
+ /* low-active PERST# reset on GPIO 25 */
+ reset-gpios = <&gpio0 25 1>;
+ /* wait 20ms for device settle after reset deassertion */
+ reset-delay-us = <20000>;
+ clocks = <&gateclk 5>;
+ };
+
+ pcie@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+ 0x81000000 0 0 0x81000000 0x2 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 59>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <1>;
+ num-lanes = <1>;
+ clocks = <&gateclk 6>;
+ };
+
+ pcie@3,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+ reg = <0x1800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+ 0x81000000 0 0 0x81000000 0x3 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 60>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <2>;
+ num-lanes = <1>;
+ clocks = <&gateclk 7>;
+ };
+
+ pcie@4,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+ reg = <0x2000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+ 0x81000000 0 0 0x81000000 0x4 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 61>;
+ marvell,pcie-port = <0>;
+ marvell,pcie-lane = <3>;
+ num-lanes = <1>;
+ clocks = <&gateclk 8>;
+ };
+
+ pcie@5,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+ reg = <0x2800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+ 0x81000000 0 0 0x81000000 0x5 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 62>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <0>;
+ num-lanes = <1>;
+ clocks = <&gateclk 9>;
+ };
+
+ pcie@6,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+ reg = <0x3000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+ 0x81000000 0 0 0x81000000 0x6 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 63>;
+ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <1>;
+ num-lanes = <1>;
+ clocks = <&gateclk 10>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml b/Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml
new file mode 100644
index 000000000000..d286b77921e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mbvl,gpex40-pcie.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/mbvl,gpex40-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mobiveil AXI PCIe Host Bridge
+
+maintainers:
+ - Frank Li <Frank Li@nxp.com>
+
+description:
+ Mobiveil's GPEX 4.0 is a PCIe Gen4 host bridge IP. This configurable IP
+ has up to 8 outbound and inbound windows for address translation.
+
+ NXP Layerscape PCIe Gen4 controller (Deprecated) base on Mobiveil's GPEX 4.0.
+
+properties:
+ compatible:
+ enum:
+ - fsl,lx2160a-pcie
+ - mbvl,gpex40-pcie
+
+ reg:
+ items:
+ - description: PCIe controller registers
+ - description: Bridge config registers
+ - description: GPIO registers to control slot power
+ - description: MSI registers
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: csr_axi_slave
+ - const: config_axi_slave
+ - const: gpio_slave
+ - const: apb_csr
+ minItems: 2
+
+ apio-wins:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ number of requested APIO outbound windows
+ 1. Config window
+ 2. Memory window
+ default: 2
+ maximum: 256
+
+ ppio-wins:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: number of requested PPIO inbound windows
+ default: 1
+ maximum: 256
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 3
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 3
+
+ dma-coherent: true
+
+ msi-parent: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,lx2160a-pcie
+ then:
+ properties:
+ reg:
+ maxItems: 2
+
+ reg-names:
+ maxItems: 2
+
+ interrupts:
+ minItems: 3
+
+ interrupt-names:
+ items:
+ - const: aer
+ - const: pme
+ - const: intr
+ else:
+ properties:
+ dma-coherent: false
+ msi-parent: false
+ interrupts:
+ maxItems: 1
+ interrupt-names: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie@b0000000 {
+ compatible = "mbvl,gpex40-pcie";
+ reg = <0xb0000000 0x00010000>,
+ <0xa0000000 0x00001000>,
+ <0xff000000 0x00200000>,
+ <0xb0010000 0x00001000>;
+ reg-names = "csr_axi_slave",
+ "config_axi_slave",
+ "gpio_slave",
+ "apb_csr";
+ ranges = <0x83000000 0 0x00000000 0xa8000000 0 0x8000000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ apio-wins = <2>;
+ ppio-wins = <1>;
+ bus-range = <0x00 0xff>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 0 &pci_express 0>,
+ <0 0 0 1 &pci_express 1>,
+ <0 0 0 2 &pci_express 2>,
+ <0 0 0 3 &pci_express 3>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@3400000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
+ 0x80 0x00000000 0x0 0x00001000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ msi-parent = <&its>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
index d60f43fd9c5a..c41608863d6c 100644
--- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml
@@ -13,8 +13,37 @@ description: |+
MediaTek MT7621 PCIe subsys supports a single Root Complex (RC)
with 3 Root Ports. Each Root Port supports a Gen1 1-lane Link
+ MT7621 PCIe HOST Topology
+
+ .-------.
+ | |
+ | CPU |
+ | |
+ '-------'
+ |
+ |
+ |
+ v
+ .------------------.
+ .-----------| HOST/PCI Bridge |------------.
+ | '------------------' | Type1
+ BUS0 | | | Access
+ v v v On Bus0
+ .-------------. .-------------. .-------------.
+ | VIRTUAL P2P | | VIRTUAL P2P | | VIRTUAL P2P |
+ | BUS0 | | BUS0 | | BUS0 |
+ | DEV0 | | DEV1 | | DEV2 |
+ '-------------' '-------------' '-------------'
+ Type0 | Type0 | Type0 |
+ Access BUS1 | Access BUS2| Access BUS3|
+ On Bus1 v On Bus2 v On Bus3 v
+ .----------. .----------. .----------.
+ | Device 0 | | Device 0 | | Device 0 |
+ | Func 0 | | Func 0 | | Func 0 |
+ '----------' '----------' '----------'
+
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -31,11 +60,14 @@ properties:
maxItems: 2
patternProperties:
- 'pcie@[0-2],0':
+ '^pcie@[0-2],0$':
type: object
- $ref: /schemas/pci/pci-bus.yaml#
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
properties:
+ reg:
+ maxItems: 1
+
resets:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
index 0499b94627ae..0278845701ce 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -43,12 +43,22 @@ description: |+
each set has its own address for MSI message, and supports 32 MSI vectors
to generate interrupt.
-allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
-
properties:
compatible:
- const: mediatek,mt8192-pcie
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt7986-pcie
+ - mediatek,mt8188-pcie
+ - mediatek,mt8195-pcie
+ - const: mediatek,mt8192-pcie
+ - items:
+ - enum:
+ - mediatek,mt6991-pcie
+ - const: mediatek,mt8196-pcie
+ - const: mediatek,mt8192-pcie
+ - const: mediatek,mt8196-pcie
+ - const: airoha,en7581-pcie
reg:
maxItems: 1
@@ -64,27 +74,29 @@ properties:
minItems: 1
maxItems: 8
+ iommu-map:
+ maxItems: 1
+
+ iommu-map-mask:
+ const: 0
+
resets:
minItems: 1
- maxItems: 2
+ maxItems: 3
reset-names:
minItems: 1
+ maxItems: 3
items:
- - const: phy
- - const: mac
+ enum: [ phy, mac, phy-lane0, phy-lane1, phy-lane2 ]
clocks:
+ minItems: 1
maxItems: 6
clock-names:
- items:
- - const: pl_250m
- - const: tl_26m
- - const: tl_96m
- - const: tl_32k
- - const: peri_26m
- - const: top_133m
+ minItems: 1
+ maxItems: 6
assigned-clocks:
maxItems: 1
@@ -99,6 +111,20 @@ properties:
items:
- const: pcie-phy
+ power-domains:
+ maxItems: 1
+
+ mediatek,pbus-csr:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to pbus-csr syscon
+ - description: offset of pbus-csr base address register
+ - description: offset of pbus-csr base address mask register
+ description:
+ Phandle with two arguments to the syscon node used to detect if
+ a given address is accessible on PCIe controller.
+
'#interrupt-cells':
const: 1
@@ -126,9 +152,152 @@ required:
- interrupts
- ranges
- clocks
+ - clock-names
- '#interrupt-cells'
- interrupt-controller
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - if:
+ properties:
+ compatible:
+ const: mediatek,mt8192-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 6
+
+ clock-names:
+ items:
+ - const: pl_250m
+ - const: tl_26m
+ - const: tl_96m
+ - const: tl_32k
+ - const: peri_26m
+ - const: top_133m
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+
+ mediatek,pbus-csr: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8188-pcie
+ - mediatek,mt8195-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 6
+
+ clock-names:
+ items:
+ - const: pl_250m
+ - const: tl_26m
+ - const: tl_96m
+ - const: tl_32k
+ - const: peri_26m
+ - const: peri_mem
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+
+ mediatek,pbus-csr: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8196-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 6
+
+ clock-names:
+ items:
+ - const: pl_250m
+ - const: tl_26m
+ - const: bus
+ - const: low_power
+ - const: peri_26m
+ - const: peri_mem
+
+ resets:
+ minItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: mac
+
+ mediatek,pbus-csr: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt7986-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: pl_250m
+ - const: tl_26m
+ - const: peri_26m
+ - const: top_133m
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+
+ mediatek,pbus-csr: false
+
+ - if:
+ properties:
+ compatible:
+ const: airoha,en7581-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: sys-ck
+
+ resets:
+ minItems: 3
+
+ reset-names:
+ items:
+ - const: phy-lane0
+ - const: phy-lane1
+ - const: phy-lane2
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-mt7623.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-mt7623.yaml
new file mode 100644
index 000000000000..e33bcc216e30
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-mt7623.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/mediatek-pcie-mt7623.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCIe controller on MediaTek SoCs
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-pcie
+ - mediatek,mt7623-pcie
+
+ reg:
+ minItems: 4
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: subsys
+ - const: port0
+ - const: port1
+ - const: port2
+
+ clocks:
+ minItems: 4
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: free_ck
+ - const: sys_ck0
+ - const: sys_ck1
+ - const: sys_ck2
+
+ resets:
+ minItems: 3
+ maxItems: 3
+
+ reset-names:
+ items:
+ - const: pcie-rst0
+ - const: pcie-rst1
+ - const: pcie-rst2
+
+ phys:
+ minItems: 3
+ maxItems: 3
+
+ phy-names:
+ items:
+ - const: pcie-phy0
+ - const: pcie-phy1
+ - const: pcie-phy2
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ranges
+ - clocks
+ - clock-names
+ - '#interrupt-cells'
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - power-domains
+ - pcie@0,0
+ - pcie@1,0
+ - pcie@2,0
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ # MT7623
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/mt2701-clk.h>
+ #include <dt-bindings/reset/mt2701-resets.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/power/mt2701-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1a140000 {
+ compatible = "mediatek,mt7623-pcie";
+ device_type = "pci";
+ reg = <0 0x1a140000 0 0x1000>, /* PCIe shared registers */
+ <0 0x1a142000 0 0x1000>, /* Port0 registers */
+ <0 0x1a143000 0 0x1000>, /* Port1 registers */
+ <0 0x1a144000 0 0x1000>; /* Port2 registers */
+ reg-names = "subsys", "port0", "port1", "port2";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0xf800 0 0 0>;
+ interrupt-map = <0x0000 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>,
+ <0x0800 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>,
+ <0x1000 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+ <&hifsys CLK_HIFSYS_PCIE0>,
+ <&hifsys CLK_HIFSYS_PCIE1>,
+ <&hifsys CLK_HIFSYS_PCIE2>;
+ clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
+ resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>,
+ <&hifsys MT2701_HIFSYS_PCIE1_RST>,
+ <&hifsys MT2701_HIFSYS_PCIE2_RST>;
+ reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
+ phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>,
+ <&pcie2_phy PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000>, /* I/O space */
+ <0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>; /* memory space */
+
+ pcie@0,0 {
+ device_type = "pci";
+ reg = <0x0000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>;
+ ranges;
+ };
+
+ pcie@1,0 {
+ device_type = "pci";
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
+ ranges;
+ };
+
+ pcie@2,0 {
+ device_type = "pci";
+ reg = <0x1000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
+ ranges;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
deleted file mode 100644
index 684227522267..000000000000
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ /dev/null
@@ -1,289 +0,0 @@
-MediaTek Gen2 PCIe controller
-
-Required properties:
-- compatible: Should contain one of the following strings:
- "mediatek,mt2701-pcie"
- "mediatek,mt2712-pcie"
- "mediatek,mt7622-pcie"
- "mediatek,mt7623-pcie"
- "mediatek,mt7629-pcie"
- "airoha,en7523-pcie"
-- device_type: Must be "pci"
-- reg: Base addresses and lengths of the root ports.
-- reg-names: Names of the above areas to use during resource lookup.
-- #address-cells: Address representation for root ports (must be 3)
-- #size-cells: Size representation for root ports (must be 2)
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names:
- Mandatory entries:
- - sys_ckN :transaction layer and data link layer clock
- Required entries for MT2701/MT7623:
- - free_ck :for reference clock of PCIe subsys
- Required entries for MT2712/MT7622:
- - ahb_ckN :AHB slave interface operating clock for CSR access and RC
- initiated MMIO access
- Required entries for MT7622:
- - axi_ckN :application layer MMIO channel operating clock
- - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
- pcie_mac_ck/pcie_pipe_ck is turned off
- - obff_ckN :OBFF functional block operating clock
- - pipe_ckN :LTSSM and PHY/MAC layer operating clock
- where N starting from 0 to one less than the number of root ports.
-- phys: List of PHY specifiers (used by generic PHY framework).
-- phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
- number of PHYs as specified in *phys* property.
-- power-domains: A phandle and power domain specifier pair to the power domain
- which is responsible for collapsing and restoring power to the peripheral.
-- bus-range: Range of bus numbers associated with this controller.
-- ranges: Ranges for the PCI memory and I/O regions.
-
-Required properties for MT7623/MT2701:
-- #interrupt-cells: Size representation for interrupts (must be 1)
-- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
- Please refer to the standard PCI bus binding document for a more detailed
- explanation.
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
- number of root ports.
-
-Required properties for MT2712/MT7622/MT7629:
--interrupts: A list of interrupt outputs of the controller, must have one
- entry for each PCIe port
-- interrupt-names: Must include the following entries:
- - "pcie_irq": The interrupt that is asserted when an MSI/INTX is received
-- linux,pci-domain: PCI domain ID. Should be unique for each host controller
-
-In addition, the device tree node must have sub-nodes describing each
-PCIe port interface, having the following mandatory properties:
-
-Required properties:
-- device_type: Must be "pci"
-- reg: Only the first four bytes are used to refer to the correct bus number
- and device number.
-- #address-cells: Must be 3
-- #size-cells: Must be 2
-- #interrupt-cells: Must be 1
-- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
- Please refer to the standard PCI bus binding document for a more detailed
- explanation.
-- ranges: Sub-ranges distributed from the PCIe controller node. An empty
- property is sufficient.
-
-Examples for MT7623:
-
- hifsys: syscon@1a000000 {
- compatible = "mediatek,mt7623-hifsys",
- "mediatek,mt2701-hifsys",
- "syscon";
- reg = <0 0x1a000000 0 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
-
- pcie: pcie@1a140000 {
- compatible = "mediatek,mt7623-pcie";
- device_type = "pci";
- reg = <0 0x1a140000 0 0x1000>, /* PCIe shared registers */
- <0 0x1a142000 0 0x1000>, /* Port0 registers */
- <0 0x1a143000 0 0x1000>, /* Port1 registers */
- <0 0x1a144000 0 0x1000>; /* Port2 registers */
- reg-names = "subsys", "port0", "port1", "port2";
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0xf800 0 0 0>;
- interrupt-map = <0x0000 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>,
- <0x0800 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>,
- <0x1000 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
- <&hifsys CLK_HIFSYS_PCIE0>,
- <&hifsys CLK_HIFSYS_PCIE1>,
- <&hifsys CLK_HIFSYS_PCIE2>;
- clock-names = "free_ck", "sys_ck0", "sys_ck1", "sys_ck2";
- resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>,
- <&hifsys MT2701_HIFSYS_PCIE1_RST>,
- <&hifsys MT2701_HIFSYS_PCIE2_RST>;
- reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
- phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>,
- <&pcie2_phy PHY_TYPE_PCIE>;
- phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_HIF>;
- bus-range = <0x00 0xff>;
- ranges = <0x81000000 0 0x1a160000 0 0x1a160000 0 0x00010000 /* I/O space */
- 0x83000000 0 0x60000000 0 0x60000000 0 0x10000000>; /* memory space */
-
- pcie@0,0 {
- reg = <0x0000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &sysirq GIC_SPI 193 IRQ_TYPE_LEVEL_LOW>;
- ranges;
- };
-
- pcie@1,0 {
- reg = <0x0800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &sysirq GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
- ranges;
- };
-
- pcie@2,0 {
- reg = <0x1000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &sysirq GIC_SPI 195 IRQ_TYPE_LEVEL_LOW>;
- ranges;
- };
- };
-
-Examples for MT2712:
-
- pcie1: pcie@112ff000 {
- compatible = "mediatek,mt2712-pcie";
- device_type = "pci";
- reg = <0 0x112ff000 0 0x1000>;
- reg-names = "port1";
- linux,pci-domain = <1>;
- #address-cells = <3>;
- #size-cells = <2>;
- interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "pcie_irq";
- clocks = <&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
- <&pericfg CLK_PERI_PCIE1>;
- clock-names = "sys_ck1", "ahb_ck1";
- phys = <&u3port1 PHY_TYPE_PCIE>;
- phy-names = "pcie-phy1";
- bus-range = <0x00 0xff>;
- ranges = <0x82000000 0 0x11400000 0x0 0x11400000 0 0x300000>;
- status = "disabled";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc1 0>,
- <0 0 0 2 &pcie_intc1 1>,
- <0 0 0 3 &pcie_intc1 2>,
- <0 0 0 4 &pcie_intc1 3>;
- pcie_intc1: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
- };
-
- pcie0: pcie@11700000 {
- compatible = "mediatek,mt2712-pcie";
- device_type = "pci";
- reg = <0 0x11700000 0 0x1000>;
- reg-names = "port0";
- linux,pci-domain = <0>;
- #address-cells = <3>;
- #size-cells = <2>;
- interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "pcie_irq";
- clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
- <&pericfg CLK_PERI_PCIE0>;
- clock-names = "sys_ck0", "ahb_ck0";
- phys = <&u3port0 PHY_TYPE_PCIE>;
- phy-names = "pcie-phy0";
- bus-range = <0x00 0xff>;
- ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
- status = "disabled";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc0 0>,
- <0 0 0 2 &pcie_intc0 1>,
- <0 0 0 3 &pcie_intc0 2>,
- <0 0 0 4 &pcie_intc0 3>;
- pcie_intc0: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
- };
-
-Examples for MT7622:
-
- pcie0: pcie@1a143000 {
- compatible = "mediatek,mt7622-pcie";
- device_type = "pci";
- reg = <0 0x1a143000 0 0x1000>;
- reg-names = "port0";
- linux,pci-domain = <0>;
- #address-cells = <3>;
- #size-cells = <2>;
- interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>;
- interrupt-names = "pcie_irq";
- clocks = <&pciesys CLK_PCIE_P0_MAC_EN>,
- <&pciesys CLK_PCIE_P0_AHB_EN>,
- <&pciesys CLK_PCIE_P0_AUX_EN>,
- <&pciesys CLK_PCIE_P0_AXI_EN>,
- <&pciesys CLK_PCIE_P0_OBFF_EN>,
- <&pciesys CLK_PCIE_P0_PIPE_EN>;
- clock-names = "sys_ck0", "ahb_ck0", "aux_ck0",
- "axi_ck0", "obff_ck0", "pipe_ck0";
-
- power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
- bus-range = <0x00 0xff>;
- ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x8000000>;
- status = "disabled";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc0 0>,
- <0 0 0 2 &pcie_intc0 1>,
- <0 0 0 3 &pcie_intc0 2>,
- <0 0 0 4 &pcie_intc0 3>;
- pcie_intc0: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
- };
-
- pcie1: pcie@1a145000 {
- compatible = "mediatek,mt7622-pcie";
- device_type = "pci";
- reg = <0 0x1a145000 0 0x1000>;
- reg-names = "port1";
- linux,pci-domain = <1>;
- #address-cells = <3>;
- #size-cells = <2>;
- interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
- interrupt-names = "pcie_irq";
- clocks = <&pciesys CLK_PCIE_P1_MAC_EN>,
- /* designer has connect RC1 with p0_ahb clock */
- <&pciesys CLK_PCIE_P0_AHB_EN>,
- <&pciesys CLK_PCIE_P1_AUX_EN>,
- <&pciesys CLK_PCIE_P1_AXI_EN>,
- <&pciesys CLK_PCIE_P1_OBFF_EN>,
- <&pciesys CLK_PCIE_P1_PIPE_EN>;
- clock-names = "sys_ck1", "ahb_ck1", "aux_ck1",
- "axi_ck1", "obff_ck1", "pipe_ck1";
-
- power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
- bus-range = <0x00 0xff>;
- ranges = <0x82000000 0 0x28000000 0x0 0x28000000 0 0x8000000>;
- status = "disabled";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc1 0>,
- <0 0 0 2 &pcie_intc1 1>,
- <0 0 0 3 &pcie_intc1 2>,
- <0 0 0 4 &pcie_intc1 3>;
- pcie_intc1: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml
new file mode 100644
index 000000000000..0b8c78ec4f91
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.yaml
@@ -0,0 +1,438 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/mediatek-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCIe controller on MediaTek SoCs
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - airoha,an7583-pcie
+ - mediatek,mt2712-pcie
+ - mediatek,mt7622-pcie
+ - mediatek,mt7629-pcie
+ - items:
+ - const: airoha,en7523-pcie
+ - const: mediatek,mt7622-pcie
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ enum: [ port0, port1 ]
+
+ clocks:
+ minItems: 1
+ maxItems: 6
+
+ clock-names:
+ minItems: 1
+ items:
+ - enum: [ sys_ck0, sys_ck1 ]
+ - enum: [ ahb_ck0, ahb_ck1 ]
+ - enum: [ aux_ck0, aux_ck1 ]
+ - enum: [ axi_ck0, axi_ck1 ]
+ - enum: [ obff_ck0, obff_ck1 ]
+ - enum: [ pipe_ck0, pipe_ck1 ]
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: pcie-rst1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: pcie_irq
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ enum: [ pcie-phy0, pcie-phy1 ]
+
+ power-domains:
+ maxItems: 1
+
+ mediatek,pbus-csr:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to pbus-csr syscon
+ - description: offset of pbus-csr base address register
+ - description: offset of pbus-csr base address mask register
+ description:
+ Phandle with two arguments to the syscon node used to detect if
+ a given address is accessible on PCIe controller.
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller:
+ description: Interrupt controller node for handling legacy PCI interrupts.
+ type: object
+ properties:
+ '#address-cells':
+ const: 0
+ '#interrupt-cells':
+ const: 1
+ interrupt-controller: true
+
+ required:
+ - '#address-cells'
+ - '#interrupt-cells'
+ - interrupt-controller
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ranges
+ - clocks
+ - clock-names
+ - '#interrupt-cells'
+ - interrupts
+ - interrupt-names
+ - interrupt-controller
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+ - if:
+ properties:
+ compatible:
+ const: airoha,an7583-pcie
+ then:
+ properties:
+ reg-names:
+ const: port1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: sys_ck1
+
+ phy-names:
+ const: pcie-phy1
+
+ power-domain: false
+
+ required:
+ - resets
+ - reset-names
+ - phys
+ - phy-names
+ - mediatek,pbus-csr
+
+ - if:
+ properties:
+ compatible:
+ const: mediatek,mt2712-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ minItems: 2
+ maxItems: 2
+
+ reset: false
+
+ reset-names: false
+
+ power-domains: false
+
+ mediatek,pbus-csr: false
+
+ required:
+ - phys
+ - phy-names
+
+ - if:
+ properties:
+ compatible:
+ const: mediatek,mt7622-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 6
+
+ reset: false
+
+ reset-names: false
+
+ phys: false
+
+ phy-names: false
+
+ mediatek,pbus-csr: false
+
+ required:
+ - power-domains
+
+ - if:
+ properties:
+ compatible:
+ const: mediatek,mt7629-pcie
+ then:
+ properties:
+ clocks:
+ minItems: 6
+
+ reset: false
+
+ reset-names: false
+
+ mediatek,pbus-csr: false
+
+ required:
+ - power-domains
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: airoha,en7523-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ reset: false
+
+ reset-names: false
+
+ phys: false
+
+ phy-names: false
+
+ power-domain: false
+
+ mediatek,pbus-csr: false
+
+unevaluatedProperties: false
+
+examples:
+ # MT2712
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/phy/phy.h>
+
+ soc_1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@112ff000 {
+ compatible = "mediatek,mt2712-pcie";
+ device_type = "pci";
+ reg = <0 0x112ff000 0 0x1000>;
+ reg-names = "port1";
+ linux,pci-domain = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie_irq";
+ clocks = <&topckgen>, /* CLK_TOP_PE2_MAC_P1_SEL */
+ <&pericfg>; /* CLK_PERI_PCIE1 */
+ clock-names = "sys_ck1", "ahb_ck1";
+ phys = <&u3port1 PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy1";
+ bus-range = <0x00 0xff>;
+ ranges = <0x82000000 0 0x11400000 0x0 0x11400000 0 0x300000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+ <0 0 0 2 &pcie_intc1 1>,
+ <0 0 0 3 &pcie_intc1 2>,
+ <0 0 0 4 &pcie_intc1 3>;
+ pcie_intc1: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ pcie@11700000 {
+ compatible = "mediatek,mt2712-pcie";
+ device_type = "pci";
+ reg = <0 0x11700000 0 0x1000>;
+ reg-names = "port0";
+ linux,pci-domain = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie_irq";
+ clocks = <&topckgen>, /* CLK_TOP_PE2_MAC_P0_SEL */
+ <&pericfg>; /* CLK_PERI_PCIE0 */
+ clock-names = "sys_ck0", "ahb_ck0";
+ phys = <&u3port0 PHY_TYPE_PCIE>;
+ phy-names = "pcie-phy0";
+ bus-range = <0x00 0xff>;
+ ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+ <0 0 0 2 &pcie_intc0 1>,
+ <0 0 0 3 &pcie_intc0 2>,
+ <0 0 0 4 &pcie_intc0 3>;
+ pcie_intc0: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
+
+ # MT7622
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/mt7622-power.h>
+
+ soc_2 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1a143000 {
+ compatible = "mediatek,mt7622-pcie";
+ device_type = "pci";
+ reg = <0 0x1a143000 0 0x1000>;
+ reg-names = "port0";
+ linux,pci-domain = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "pcie_irq";
+ clocks = <&pciesys>, /* CLK_PCIE_P0_MAC_EN */
+ <&pciesys>, /* CLK_PCIE_P0_AHB_EN */
+ <&pciesys>, /* CLK_PCIE_P0_AUX_EN */
+ <&pciesys>, /* CLK_PCIE_P0_AXI_EN */
+ <&pciesys>, /* CLK_PCIE_P0_OBFF_EN */
+ <&pciesys>; /* CLK_PCIE_P0_PIPE_EN */
+ clock-names = "sys_ck0", "ahb_ck0", "aux_ck0",
+ "axi_ck0", "obff_ck0", "pipe_ck0";
+
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x8000000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc0_1 0>,
+ <0 0 0 2 &pcie_intc0_1 1>,
+ <0 0 0 3 &pcie_intc0_1 2>,
+ <0 0 0 4 &pcie_intc0_1 3>;
+ pcie_intc0_1: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ pcie@1a145000 {
+ compatible = "mediatek,mt7622-pcie";
+ device_type = "pci";
+ reg = <0 0x1a145000 0 0x1000>;
+ reg-names = "port1";
+ linux,pci-domain = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "pcie_irq";
+ clocks = <&pciesys>, /* CLK_PCIE_P1_MAC_EN */
+ /* designer has connect RC1 with p0_ahb clock */
+ <&pciesys>, /* CLK_PCIE_P0_AHB_EN */
+ <&pciesys>, /* CLK_PCIE_P1_AUX_EN */
+ <&pciesys>, /* CLK_PCIE_P1_AXI_EN */
+ <&pciesys>, /* CLK_PCIE_P1_OBFF_EN */
+ <&pciesys>; /* CLK_PCIE_P1_PIPE_EN */
+ clock-names = "sys_ck1", "ahb_ck1", "aux_ck1",
+ "axi_ck1", "obff_ck1", "pipe_ck1";
+
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x82000000 0 0x28000000 0x0 0x28000000 0 0x8000000>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc1_1 0>,
+ <0 0 0 2 &pcie_intc1_1 1>,
+ <0 0 0 3 &pcie_intc1_1 2>,
+ <0 0 0 4 &pcie_intc1_1 3>;
+ pcie_intc1_1: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
+
+ # AN7583
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/en7523-clk.h>
+
+ soc_3 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1fa92000 {
+ compatible = "airoha,an7583-pcie";
+ device_type = "pci";
+ linux,pci-domain = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ reg = <0x0 0x1fa92000 0x0 0x1670>;
+ reg-names = "port1";
+
+ clocks = <&scuclk EN7523_CLK_PCIE>;
+ clock-names = "sys_ck1";
+
+ phys = <&pciephy>;
+ phy-names = "pcie-phy1";
+
+ ranges = <0x02000000 0 0x24000000 0x0 0x24000000 0 0x4000000>;
+
+ resets = <&scuclk>; /* AN7583_PCIE1_RST */
+ reset-names = "pcie-rst1";
+
+ mediatek,pbus-csr = <&pbus_csr 0x8 0xc>;
+
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie_irq";
+ bus-range = <0x00 0xff>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+ <0 0 0 2 &pcie_intc1 1>,
+ <0 0 0 3 &pcie_intc1 2>,
+ <0 0 0 4 &pcie_intc1 3>;
+
+ pcie_intc1_4: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
index edb4f81253c8..47b0bad690d5 100644
--- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
+++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/pci/microchip,pcie-host.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip PCIe Root Port Bridge Controller Device Tree Bindings
+title: Microchip PCIe Root Port Bridge Controller
maintainers:
- Daire McNamara <daire.mcnamara@microchip.com>
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: plda,xpressrich3-axi-common.yaml#
- $ref: /schemas/interrupt-controller/msi-controller.yaml#
properties:
@@ -18,92 +18,80 @@ properties:
const: microchip,pcie-host-1.0 # PolarFire
reg:
- maxItems: 2
+ minItems: 3
reg-names:
- items:
- - const: cfg
- - const: apb
-
- interrupts:
+ minItems: 3
+
+ clocks:
+ description:
+ Fabric Interface Controllers, FICs, are the interface between the FPGA
+ fabric and the core complex on PolarFire SoC. The FICs require two clocks,
+ one from each side of the interface. The "FIC clocks" described by this
+ property are on the core complex side & communication through a FIC is not
+ possible unless it's corresponding clock is enabled. A clock must be
+ enabled for each of the interfaces the root port is connected through.
+ This could in theory be all 4 interfaces, one interface or any combination
+ in between.
minItems: 1
items:
- - description: PCIe host controller
- - description: builtin MSI controller
-
- interrupt-names:
+ - description: FIC0's clock
+ - description: FIC1's clock
+ - description: FIC2's clock
+ - description: FIC3's clock
+
+ clock-names:
+ description:
+ As any FIC connection combination is possible, the names should match the
+ order in the clocks property and take the form "ficN" where N is a number
+ 0-3
minItems: 1
+ maxItems: 4
items:
- - const: pcie
- - const: msi
-
- ranges:
- maxItems: 1
-
- msi-controller:
- description: Identifies the node as an MSI controller.
-
- msi-parent:
- description: MSI controller the device is capable of using.
+ pattern: '^fic[0-3]$'
- interrupt-controller:
- type: object
- properties:
- '#address-cells':
- const: 0
+ dma-noncoherent: true
- '#interrupt-cells':
- const: 1
-
- interrupt-controller: true
-
- required:
- - '#address-cells'
- - '#interrupt-cells'
- - interrupt-controller
-
- additionalProperties: false
+ ranges:
+ minItems: 1
+ maxItems: 3
-required:
- - reg
- - reg-names
- - "#interrupt-cells"
- - interrupts
- - interrupt-map-mask
- - interrupt-map
- - msi-controller
+ dma-ranges:
+ minItems: 1
+ maxItems: 6
unevaluatedProperties: false
examples:
- |
soc {
- #address-cells = <2>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie0: pcie@2030000000 {
+ compatible = "microchip,pcie-host-1.0";
+ reg = <0x0 0x70000000 0x0 0x08000000>,
+ <0x0 0x43008000 0x0 0x00002000>,
+ <0x0 0x4300a000 0x0 0x00002000>;
+ reg-names = "cfg", "bridge", "ctrl";
+ device_type = "pci";
+ #address-cells = <3>;
#size-cells = <2>;
- pcie0: pcie@2030000000 {
- compatible = "microchip,pcie-host-1.0";
- reg = <0x0 0x70000000 0x0 0x08000000>,
- <0x0 0x43000000 0x0 0x00010000>;
- reg-names = "cfg", "apb";
- device_type = "pci";
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupts = <119>;
- interrupt-map-mask = <0x0 0x0 0x0 0x7>;
- interrupt-map = <0 0 0 1 &pcie_intc0 0>,
- <0 0 0 2 &pcie_intc0 1>,
- <0 0 0 3 &pcie_intc0 2>,
- <0 0 0 4 &pcie_intc0 3>;
- interrupt-parent = <&plic0>;
- msi-parent = <&pcie0>;
- msi-controller;
- bus-range = <0x00 0x7f>;
- ranges = <0x03000000 0x0 0x78000000 0x0 0x78000000 0x0 0x04000000>;
- pcie_intc0: interrupt-controller {
- #address-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- };
+ #interrupt-cells = <1>;
+ interrupts = <119>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+ <0 0 0 2 &pcie_intc0 1>,
+ <0 0 0 3 &pcie_intc0 2>,
+ <0 0 0 4 &pcie_intc0 3>;
+ interrupt-parent = <&plic0>;
+ msi-parent = <&pcie0>;
+ msi-controller;
+ bus-range = <0x00 0x7f>;
+ ranges = <0x03000000 0x0 0x78000000 0x0 0x78000000 0x0 0x04000000>;
+ pcie_intc0: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
};
+ };
};
diff --git a/Documentation/devicetree/bindings/pci/mobiveil-pcie.txt b/Documentation/devicetree/bindings/pci/mobiveil-pcie.txt
deleted file mode 100644
index 64156993e052..000000000000
--- a/Documentation/devicetree/bindings/pci/mobiveil-pcie.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-* Mobiveil AXI PCIe Root Port Bridge DT description
-
-Mobiveil's GPEX 4.0 is a PCIe Gen4 root port bridge IP. This configurable IP
-has up to 8 outbound and inbound windows for the address translation.
-
-Required properties:
-- #address-cells: Address representation for root ports, set to <3>
-- #size-cells: Size representation for root ports, set to <2>
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- compatible: Should contain "mbvl,gpex40-pcie"
-- reg: Should contain PCIe registers location and length
- Mandatory:
- "config_axi_slave": PCIe controller registers
- "csr_axi_slave" : Bridge config registers
- Optional:
- "gpio_slave" : GPIO registers to control slot power
- "apb_csr" : MSI registers
-
-- device_type: must be "pci"
-- apio-wins : number of requested apio outbound windows
- default 2 outbound windows are configured -
- 1. Config window
- 2. Memory window
-- ppio-wins : number of requested ppio inbound windows
- default 1 inbound memory window is configured.
-- bus-range: PCI bus numbers covered
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- interrupts: The interrupt line of the PCIe controller
- last cell of this field is set to 4 to
- denote it as IRQ_TYPE_LEVEL_HIGH type interrupt.
-- interrupt-map-mask,
- interrupt-map: standard PCI properties to define the mapping of the
- PCI interface to interrupt numbers.
-- ranges: ranges for the PCI memory regions (I/O space region is not
- supported by hardware)
- Please refer to the standard PCI bus binding document for a more
- detailed explanation
-
-
-Example:
-++++++++
- pcie0: pcie@a0000000 {
- #address-cells = <3>;
- #size-cells = <2>;
- compatible = "mbvl,gpex40-pcie";
- reg = <0xa0000000 0x00001000>,
- <0xb0000000 0x00010000>,
- <0xff000000 0x00200000>,
- <0xb0010000 0x00001000>;
- reg-names = "config_axi_slave",
- "csr_axi_slave",
- "gpio_slave",
- "apb_csr";
- device_type = "pci";
- apio-wins = <2>;
- ppio-wins = <1>;
- bus-range = <0x00000000 0x000000ff>;
- interrupt-controller;
- interrupt-parent = <&gic>;
- #interrupt-cells = <1>;
- interrupts = < 0 89 4 >;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 0 &pci_express 0>,
- <0 0 0 1 &pci_express 1>,
- <0 0 0 2 &pci_express 2>,
- <0 0 0 3 &pci_express 3>;
- ranges = < 0x83000000 0 0x00000000 0xa8000000 0 0x8000000>;
-
- };
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
deleted file mode 100644
index 6d022a9d36ee..000000000000
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ /dev/null
@@ -1,310 +0,0 @@
-* Marvell EBU PCIe interfaces
-
-Mandatory properties:
-
-- compatible: one of the following values:
- marvell,armada-370-pcie
- marvell,armada-xp-pcie
- marvell,dove-pcie
- marvell,kirkwood-pcie
-- #address-cells, set to <3>
-- #size-cells, set to <2>
-- #interrupt-cells, set to <1>
-- bus-range: PCI bus numbers covered
-- device_type, set to "pci"
-- ranges: ranges describing the MMIO registers to control the PCIe
- interfaces, and ranges describing the MBus windows needed to access
- the memory and I/O regions of each PCIe interface.
-- msi-parent: Link to the hardware entity that serves as the Message
- Signaled Interrupt controller for this PCI controller.
-
-The ranges describing the MMIO registers have the following layout:
-
- 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
-
-where:
-
- * r is a 32-bits value that gives the offset of the MMIO
- registers of this PCIe interface, from the base of the internal
- registers.
-
- * s is a 32-bits value that give the size of this MMIO
- registers area. This range entry translates the '0x82000000 0 r' PCI
- address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
- of the internal register window (as identified by MBUS_ID(0xf0,
- 0x01)).
-
-The ranges describing the MBus windows have the following layout:
-
- 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0
-
-where:
-
- * t is the type of the MBus window (as defined by the standard PCI DT
- bindings), 1 for I/O and 2 for memory.
-
- * s is the PCI slot that corresponds to this PCIe interface
-
- * w is the 'target ID' value for the MBus window
-
- * a the 'attribute' value for the MBus window.
-
-Since the location and size of the different MBus windows is not fixed in
-hardware, and only determined in runtime, those ranges cover the full first
-4 GB of the physical address space, and do not translate into a valid CPU
-address.
-
-In addition, the device tree node must have sub-nodes describing each
-PCIe interface, having the following mandatory properties:
-
-- reg: used only for interrupt mapping, so only the first four bytes
- are used to refer to the correct bus number and device number.
-- assigned-addresses: reference to the MMIO registers used to control
- this PCIe interface.
-- clocks: the clock associated to this PCIe interface
-- marvell,pcie-port: the physical PCIe port number
-- status: either "disabled" or "okay"
-- device_type, set to "pci"
-- #address-cells, set to <3>
-- #size-cells, set to <2>
-- #interrupt-cells, set to <1>
-- ranges, translating the MBus windows ranges of the parent node into
- standard PCI addresses.
-- interrupt-map-mask and interrupt-map, standard PCI properties to
- define the mapping of the PCIe interface to interrupt numbers.
-
-and the following optional properties:
-- marvell,pcie-lane: the physical PCIe lane number, for ports having
- multiple lanes. If this property is not found, we assume that the
- value is 0.
-- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
-- reset-gpios: optional GPIO to PERST#
-- reset-delay-us: delay in us to wait after reset de-assertion, if not
- specified will default to 100ms, as required by the PCIe specification.
-- interrupt-names: list of interrupt names, supported are:
- - "intx" - interrupt line triggered by one of the legacy interrupt
-- interrupts or interrupts-extended: List of the interrupt sources which
- corresponding to the "interrupt-names". If non-empty then also additional
- 'interrupt-controller' subnode must be defined.
-
-Example:
-
-pcie-controller {
- compatible = "marvell,armada-xp-pcie";
- device_type = "pci";
-
- #address-cells = <3>;
- #size-cells = <2>;
-
- bus-range = <0x00 0xff>;
- msi-parent = <&mpic>;
-
- ranges =
- <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
- 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */
- 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */
- 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */
- 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */
- 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */
- 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */
- 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */
- 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */
- 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */
- 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
- 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
- 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
- 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */
- 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
- 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */
- 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
- 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */
-
- 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
- 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */
- 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
- 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */
- 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
- 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */
- 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
- 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */
-
- 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
- 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */
-
- 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
- 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>;
-
- pcie@1,0 {
- device_type = "pci";
- assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
- reg = <0x0800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
- 0x81000000 0 0 0x81000000 0x1 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 58>;
- marvell,pcie-port = <0>;
- marvell,pcie-lane = <0>;
- num-lanes = <1>;
- /* low-active PERST# reset on GPIO 25 */
- reset-gpios = <&gpio0 25 1>;
- /* wait 20ms for device settle after reset deassertion */
- reset-delay-us = <20000>;
- clocks = <&gateclk 5>;
- };
-
- pcie@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
- reg = <0x1000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
- 0x81000000 0 0 0x81000000 0x2 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 59>;
- marvell,pcie-port = <0>;
- marvell,pcie-lane = <1>;
- num-lanes = <1>;
- clocks = <&gateclk 6>;
- };
-
- pcie@3,0 {
- device_type = "pci";
- assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
- reg = <0x1800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
- 0x81000000 0 0 0x81000000 0x3 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 60>;
- marvell,pcie-port = <0>;
- marvell,pcie-lane = <2>;
- num-lanes = <1>;
- clocks = <&gateclk 7>;
- };
-
- pcie@4,0 {
- device_type = "pci";
- assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
- reg = <0x2000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
- 0x81000000 0 0 0x81000000 0x4 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 61>;
- marvell,pcie-port = <0>;
- marvell,pcie-lane = <3>;
- num-lanes = <1>;
- clocks = <&gateclk 8>;
- };
-
- pcie@5,0 {
- device_type = "pci";
- assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
- reg = <0x2800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
- 0x81000000 0 0 0x81000000 0x5 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 62>;
- marvell,pcie-port = <1>;
- marvell,pcie-lane = <0>;
- num-lanes = <1>;
- clocks = <&gateclk 9>;
- };
-
- pcie@6,0 {
- device_type = "pci";
- assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
- reg = <0x3000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
- 0x81000000 0 0 0x81000000 0x6 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 63>;
- marvell,pcie-port = <1>;
- marvell,pcie-lane = <1>;
- num-lanes = <1>;
- clocks = <&gateclk 10>;
- };
-
- pcie@7,0 {
- device_type = "pci";
- assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
- reg = <0x3800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
- 0x81000000 0 0 0x81000000 0x7 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 64>;
- marvell,pcie-port = <1>;
- marvell,pcie-lane = <2>;
- num-lanes = <1>;
- clocks = <&gateclk 11>;
- };
-
- pcie@8,0 {
- device_type = "pci";
- assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
- reg = <0x4000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
- 0x81000000 0 0 0x81000000 0x8 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 65>;
- marvell,pcie-port = <1>;
- marvell,pcie-lane = <3>;
- num-lanes = <1>;
- clocks = <&gateclk 12>;
- };
-
- pcie@9,0 {
- device_type = "pci";
- assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
- reg = <0x4800 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
- 0x81000000 0 0 0x81000000 0x9 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 99>;
- marvell,pcie-port = <2>;
- marvell,pcie-lane = <0>;
- num-lanes = <1>;
- clocks = <&gateclk 26>;
- };
-
- pcie@a,0 {
- device_type = "pci";
- assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
- reg = <0x5000 0 0 0 0>;
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
- 0x81000000 0 0 0x81000000 0xa 0 1 0>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &mpic 103>;
- marvell,pcie-port = <3>;
- marvell,pcie-lane = <0>;
- num-lanes = <1>;
- clocks = <&gateclk 27>;
- };
-};
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml
index a24fb8307d29..6d6052a2748f 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml
@@ -74,7 +74,7 @@ properties:
reset-gpios:
description: Must contain a phandle to a GPIO controller followed by GPIO
- that is being used as PERST input signal. Please refer to pci.txt.
+ that is being used as PERST input signal.
phys:
minItems: 1
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml
index 75da3e8eecb9..fe81d52c7277 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml
@@ -27,6 +27,7 @@ properties:
- nvidia,tegra234-pcie
reg:
+ minItems: 4
items:
- description: controller's application logic registers
- description: configuration registers
@@ -35,13 +36,16 @@ properties:
available for software access.
- description: aperture where the Root Port's own configuration
registers are available.
+ - description: aperture to access the configuration space through ECAM.
reg-names:
+ minItems: 4
items:
- const: appl
- const: config
- const: atu_dma
- const: dbi
+ - const: ecam
interrupts:
items:
@@ -202,6 +206,31 @@ properties:
allOf:
- $ref: /schemas/pci/snps,dw-pcie.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-pcie
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ reg-names:
+ maxItems: 4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra234-pcie
+ then:
+ properties:
+ reg:
+ minItems: 5
+ reg-names:
+ minItems: 5
unevaluatedProperties: false
@@ -305,8 +334,9 @@ examples:
reg = <0x00 0x14160000 0x0 0x00020000>, /* appl registers (128K) */
<0x00 0x36000000 0x0 0x00040000>, /* configuration space (256K) */
<0x00 0x36040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */
- <0x00 0x36080000 0x0 0x00040000>; /* DBI reg space (256K) */
- reg-names = "appl", "config", "atu_dma", "dbi";
+ <0x00 0x36080000 0x0 0x00040000>, /* DBI reg space (256K) */
+ <0x24 0x30000000 0x0 0x10000000>; /* ECAM (256MB) */
+ reg-names = "appl", "config", "atu_dma", "dbi", "ecam";
#address-cells = <3>;
#size-cells = <2>;
diff --git a/Documentation/devicetree/bindings/pci/nxp,s32g-pcie.yaml b/Documentation/devicetree/bindings/pci/nxp,s32g-pcie.yaml
new file mode 100644
index 000000000000..66a050028278
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/nxp,s32g-pcie.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/nxp,s32g-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP S32G2xxx/S32G3xxx PCIe Root Complex controller
+
+maintainers:
+ - Bogdan Hamciuc <bogdan.hamciuc@nxp.com>
+ - Ionut Vicovan <ionut.vicovan@nxp.com>
+
+description:
+ This PCIe controller is based on the Synopsys DesignWare PCIe IP.
+ The S32G SoC family has two PCIe controllers, which can be configured as
+ either Root Complex or Endpoint.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nxp,s32g2-pcie
+ - items:
+ - const: nxp,s32g3-pcie
+ - const: nxp,s32g2-pcie
+
+ reg:
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: atu
+ - const: dma
+ - const: ctrl
+ - const: config
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: msi
+ - const: dma
+ minItems: 1
+
+ pcie@0:
+ description:
+ Describe the S32G Root Port.
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ required:
+ - reg
+ - phys
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - ranges
+ - pcie@0
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@40400000 {
+ compatible = "nxp,s32g3-pcie", "nxp,s32g2-pcie";
+ reg = <0x00 0x40400000 0x0 0x00001000>, /* dbi registers */
+ <0x00 0x40420000 0x0 0x00001000>, /* dbi2 registers */
+ <0x00 0x40460000 0x0 0x00001000>, /* atu registers */
+ <0x00 0x40470000 0x0 0x00001000>, /* dma registers */
+ <0x00 0x40481000 0x0 0x000000f8>, /* ctrl registers */
+ <0x5f 0xffffe000 0x0 0x00002000>; /* config space */
+ reg-names = "dbi", "dbi2", "atu", "dma", "ctrl", "config";
+ dma-coherent;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges =
+ <0x01000000 0x0 0x00000000 0x5f 0xfffe0000 0x0 0x00010000>,
+ <0x02000000 0x0 0x00000000 0x58 0x00000000 0x0 0x80000000>,
+ <0x02000000 0x1 0x00000000 0x59 0x00000000 0x6 0xfffe0000>;
+
+ bus-range = <0x0 0xff>;
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic 0 0 GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic 0 0 GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic 0 0 GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ device_type = "pci";
+ phys = <&serdes0 PHY_TYPE_PCIE 0 0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
deleted file mode 100644
index ff25a134befa..000000000000
--- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-* Marvell Armada 7K/8K PCIe interface
-
-This PCIe host controller is based on the Synopsys DesignWare PCIe IP
-and thus inherits all the common properties defined in snps,dw-pcie.yaml.
-
-Required properties:
-- compatible: "marvell,armada8k-pcie"
-- reg: must contain two register regions
- - the control register region
- - the config space region
-- reg-names:
- - "ctrl" for the control register region
- - "config" for the config space region
-- interrupts: Interrupt specifier for the PCIe controller
-- clocks: reference to the PCIe controller clocks
-- clock-names: mandatory if there is a second clock, in this case the
- name must be "core" for the first clock and "reg" for the second
- one
-
-Optional properties:
-- phys: phandle(s) to PHY node(s) following the generic PHY bindings.
- Either 1, 2 or 4 PHYs might be needed depending on the number of
- PCIe lanes.
-- phy-names: names of the PHYs corresponding to the number of lanes.
- Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for
- 2 PHYs.
-
-Example:
-
- pcie@f2600000 {
- compatible = "marvell,armada8k-pcie", "snps,dw-pcie";
- reg = <0 0xf2600000 0 0x10000>, <0 0xf6f00000 0 0x80000>;
- reg-names = "ctrl", "config";
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- device_type = "pci";
- dma-coherent;
-
- bus-range = <0 0xff>;
- ranges = <0x81000000 0 0xf9000000 0 0xf9000000 0 0x10000 /* downstream I/O */
- 0x82000000 0 0xf6000000 0 0xf6000000 0 0xf00000>; /* non-prefetchable memory */
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- num-lanes = <1>;
- clocks = <&cpm_syscon0 1 13>;
- };
diff --git a/Documentation/devicetree/bindings/pci/pci-ep-bus.yaml b/Documentation/devicetree/bindings/pci/pci-ep-bus.yaml
new file mode 100644
index 000000000000..a2cd7905f5bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-ep-bus.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/pci-ep-bus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Properties for PCI MFD EP with Peripherals Addressable from BARs
+
+maintainers:
+ - A. della Porta <andrea.porta@suse.com>
+
+description:
+ Define a generic node representing a PCI endpoint which contains several sub-
+ peripherals. The peripherals can be accessed through one or more BARs.
+ This common schema is intended to be referenced from device tree bindings and
+ does not represent a device tree binding by itself.
+
+properties:
+ '#address-cells':
+ const: 3
+
+ '#size-cells':
+ const: 2
+
+ ranges:
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 8
+ additionalItems: true
+ items:
+ - maximum: 5 # The BAR number
+ - const: 0
+ - const: 0
+
+patternProperties:
+ '^pci-ep-bus@[0-5]$':
+ type: object
+ description:
+ One node for each BAR used by peripherals contained in the PCI endpoint.
+ Each node represents a bus on which peripherals are connected.
+ This allows for some segmentation, e.g., one peripheral is accessible
+ through BAR0 and another through BAR1, and you don't want the two
+ peripherals to be able to act on the other BAR. Alternatively, when
+ different peripherals need to share BARs, you can define only one node
+ and use a 'ranges' property to map all the used BARs.
+
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: simple-bus
+
+ required:
+ - compatible
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/pci/pci-ep.yaml b/Documentation/devicetree/bindings/pci/pci-ep.yaml
index ccec51ab5247..baeb583e0bcd 100644
--- a/Documentation/devicetree/bindings/pci/pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/pci-ep.yaml
@@ -4,18 +4,37 @@
$id: http://devicetree.org/schemas/pci/pci-ep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: PCI Endpoint Controller Schema
+title: PCI Endpoint Controller
description: |
Common properties for PCI Endpoint Controller Nodes.
maintainers:
- - Kishon Vijay Abraham I <kishon@ti.com>
+ - Kishon Vijay Abraham I <kishon@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
properties:
$nodename:
pattern: "^pcie-ep@"
+ iommu-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: Device ID (see msi-map) base
+ maximum: 0x7ffff
+ - description: phandle to IOMMU
+ - description: IOMMU specifier base (currently always 1 cell)
+ - description: Number of Device IDs
+ maximum: 0x80000
+
+ iommu-map-mask:
+ description:
+ A mask to be applied to each Device ID prior to being mapped to an
+ IOMMU specifier per the iommu-map property.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 0x7ffff
+
max-functions:
description: Maximum number of functions that can be configured
$ref: /schemas/types.yaml#/definitions/uint8
@@ -32,7 +51,57 @@ properties:
max-link-speed:
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 1, 2, 3, 4 ]
+ enum: [ 1, 2, 3, 4, 5, 6 ]
+
+ msi-map:
+ description: |
+ Maps a Device ID to an MSI and associated MSI specifier data.
+
+ A PCI Endpoint (EP) can use MSI as a doorbell function. This is achieved by
+ mapping the MSI controller's address into PCI BAR<n>. The PCI Root Complex
+ can write to this BAR<n>, triggering the EP to generate IRQ. This notifies
+ the EP-side driver of an event, eliminating the need for the driver to
+ continuously poll for status changes.
+
+ However, the EP cannot rely on Requester ID (RID) because the RID is
+ determined by the PCI topology of the host system. Since the EP may be
+ connected to different PCI hosts, the RID can vary between systems and is
+ therefore not a reliable identifier.
+
+ Each EP can support up to 8 physical functions and up to 65,536 virtual
+ functions. To uniquely identify each child device, a device ID is defined
+ as
+ - Bits [2:0] for the function number (func)
+ - Bits [18:3] for the virtual function index (vfunc)
+
+ The resulting device ID is computed as:
+
+ (func & 0x7) | (vfunc << 3)
+
+ The property is an arbitrary number of tuples of
+ (device-id-base, msi, msi-base,length).
+
+ Any Device ID id in the interval [id-base, id-base + length) is
+ associated with the listed MSI, with the MSI specifier
+ (id - id-base + msi-base).
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: The Device ID base matched by the entry
+ maximum: 0x7ffff
+ - description: phandle to msi-controller node
+ - description: (optional) The msi-specifier produced for the first
+ Device ID matched by the entry. Currently, msi-specifier is 0 or
+ 1 cells.
+ - description: The length of consecutive Device IDs following the
+ Device ID base
+ maximum: 0x80000
+
+ msi-map-mask:
+ description: A mask to be applied to each Device ID prior to being
+ mapped to an msi-specifier per the msi-map property.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 0x7ffff
num-lanes:
description: maximum number of lanes
@@ -41,6 +110,17 @@ properties:
default: 1
maximum: 16
+ linux,pci-domain:
+ description:
+ If present this property assigns a fixed PCI domain number to a PCI
+ Endpoint Controller, otherwise an unstable (across boots) unique number
+ will be assigned. It is required to either not set this property at all
+ or set it for all PCI endpoint controllers in the system, otherwise
+ potentially conflicting domain numbers may be assigned to endpoint
+ controllers. The domain number for each endpoint controller in the system
+ must be unique.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
deleted file mode 100644
index 0def586fdcdf..000000000000
--- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-This document describes the generic device tree binding for describing the
-relationship between PCI(e) devices and IOMMU(s).
-
-Each PCI(e) device under a root complex is uniquely identified by its Requester
-ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
-Function number.
-
-For the purpose of this document, when treated as a numeric value, a RID is
-formatted such that:
-
-* Bits [15:8] are the Bus number.
-* Bits [7:3] are the Device number.
-* Bits [2:0] are the Function number.
-* Any other bits required for padding must be zero.
-
-IOMMUs may distinguish PCI devices through sideband data derived from the
-Requester ID. While a given PCI device can only master through one IOMMU, a
-root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per
-bus).
-
-The generic 'iommus' property is insufficient to describe this relationship,
-and a mechanism is required to map from a PCI device to its IOMMU and sideband
-data.
-
-For generic IOMMU bindings, see
-Documentation/devicetree/bindings/iommu/iommu.txt.
-
-
-PCI root complex
-================
-
-Optional properties
--------------------
-
-- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
- data.
-
- The property is an arbitrary number of tuples of
- (rid-base,iommu,iommu-base,length).
-
- Any RID r in the interval [rid-base, rid-base + length) is associated with
- the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base).
-
-- iommu-map-mask: A mask to be applied to each Requester ID prior to being
- mapped to an IOMMU specifier per the iommu-map property.
-
-
-Example (1)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the IOMMU is the RID,
- * identity-mapped.
- */
- iommu-map = <0x0 &iommu 0x0 0x10000>;
- };
-};
-
-
-Example (2)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the IOMMU is the RID with the
- * function bits masked out.
- */
- iommu-map = <0x0 &iommu 0x0 0x10000>;
- iommu-map-mask = <0xfff8>;
- };
-};
-
-
-Example (3)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the IOMMU is the RID,
- * but the high bits of the bus number are flipped.
- */
- iommu-map = <0x0000 &iommu 0x8000 0x8000>,
- <0x8000 &iommu 0x0000 0x8000>;
- };
-};
-
-
-Example (4)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu_a: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- iommu_b: iommu@b {
- reg = <0xb 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- iommu_c: iommu@c {
- reg = <0xc 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * Devices with bus number 0-127 are mastered via IOMMU
- * a, with sideband data being RID[14:0].
- * Devices with bus number 128-255 are mastered via
- * IOMMU b, with sideband data being RID[14:0].
- * No devices master via IOMMU c.
- */
- iommu-map = <0x0000 &iommu_a 0x0000 0x8000>,
- <0x8000 &iommu_b 0x0000 0x8000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt
deleted file mode 100644
index b73d839657b6..000000000000
--- a/Documentation/devicetree/bindings/pci/pci-msi.txt
+++ /dev/null
@@ -1,220 +0,0 @@
-This document describes the generic device tree binding for describing the
-relationship between PCI devices and MSI controllers.
-
-Each PCI device under a root complex is uniquely identified by its Requester ID
-(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
-Function number.
-
-For the purpose of this document, when treated as a numeric value, a RID is
-formatted such that:
-
-* Bits [15:8] are the Bus number.
-* Bits [7:3] are the Device number.
-* Bits [2:0] are the Function number.
-* Any other bits required for padding must be zero.
-
-MSIs may be distinguished in part through the use of sideband data accompanying
-writes. In the case of PCI devices, this sideband data may be derived from the
-Requester ID. A mechanism is required to associate a device with both the MSI
-controllers it can address, and the sideband data that will be associated with
-its writes to those controllers.
-
-For generic MSI bindings, see
-Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-
-PCI root complex
-================
-
-Optional properties
--------------------
-
-- msi-map: Maps a Requester ID to an MSI controller and associated
- msi-specifier data. The property is an arbitrary number of tuples of
- (rid-base,msi-controller,msi-base,length), where:
-
- * rid-base is a single cell describing the first RID matched by the entry.
-
- * msi-controller is a single phandle to an MSI controller
-
- * msi-base is an msi-specifier describing the msi-specifier produced for the
- first RID matched by the entry.
-
- * length is a single cell describing how many consecutive RIDs are matched
- following the rid-base.
-
- Any RID r in the interval [rid-base, rid-base + length) is associated with
- the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
-
-- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
- to an msi-specifier per the msi-map property.
-
-- msi-parent: Describes the MSI parent of the root complex itself. Where
- the root complex and MSI controller do not pass sideband data with MSI
- writes, this property may be used to describe the MSI controller(s)
- used by PCI devices under the root complex, if defined as such in the
- binding for the root complex.
-
-
-Example (1)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- msi: msi-controller@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the MSI controller is
- * the RID, identity-mapped.
- */
- msi-map = <0x0 &msi_a 0x0 0x10000>,
- };
-};
-
-
-Example (2)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- msi: msi-controller@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the MSI controller is
- * the RID, masked to only the device and function bits.
- */
- msi-map = <0x0 &msi_a 0x0 0x100>,
- msi-map-mask = <0xff>
- };
-};
-
-
-Example (3)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- msi: msi-controller@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the MSI controller is
- * the RID, but the high bit of the bus number is
- * ignored.
- */
- msi-map = <0x0000 &msi 0x0000 0x8000>,
- <0x8000 &msi 0x0000 0x8000>;
- };
-};
-
-
-Example (4)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- msi: msi-controller@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the MSI controller is
- * the RID, but the high bit of the bus number is
- * negated.
- */
- msi-map = <0x0000 &msi 0x8000 0x8000>,
- <0x8000 &msi 0x0000 0x8000>;
- };
-};
-
-
-Example (5)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- msi_a: msi-controller@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- msi_b: msi-controller@b {
- reg = <0xb 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- msi_c: msi-controller@c {
- reg = <0xc 0x1>;
- compatible = "vendor,some-controller";
- msi-controller;
- #msi-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to MSI controller a is the
- * RID, but the high bit of the bus number is negated.
- * The sideband data provided to MSI controller b is the
- * RID, identity-mapped.
- * MSI controller c is not addressable.
- */
- msi-map = <0x0000 &msi_a 0x8000 0x08000>,
- <0x8000 &msi_a 0x0000 0x08000>,
- <0x0000 &msi_b 0x0000 0x10000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
deleted file mode 100644
index 6a8f2874a24d..000000000000
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-PCI bus bridges have standardized Device Tree bindings:
-
-PCI Bus Binding to: IEEE Std 1275-1994
-https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
-
-And for the interrupt mapping part:
-
-Open Firmware Recommended Practice: Interrupt Mapping
-https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf
-
-Additionally to the properties specified in the above standards a host bridge
-driver implementation may support the following properties:
-
-- linux,pci-domain:
- If present this property assigns a fixed PCI domain number to a host bridge,
- otherwise an unstable (across boots) unique number will be assigned.
- It is required to either not set this property at all or set it for all
- host bridges in the system, otherwise potentially conflicting domain numbers
- may be assigned to root buses behind different host bridges. The domain
- number for each host bridge in the system must be unique.
-- max-link-speed:
- If present this property specifies PCI gen for link capability. Host
- drivers could add this as a strategy to avoid unnecessary operation for
- unsupported link speed, for instance, trying to do training for
- unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2'
- for gen2, and '1' for gen1. Any other values are invalid.
-- reset-gpios:
- If present this property specifies PERST# GPIO. Host drivers can parse the
- GPIO and apply fundamental reset to endpoints.
-- supports-clkreq:
- If present this property specifies that CLKREQ signal routing exists from
- root port to downstream device and host bridge drivers can do programming
- which depends on CLKREQ signal existence. For example, programming root port
- not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
-
-PCI-PCI Bridge properties
--------------------------
-
-PCIe root ports and switch ports may be described explicitly in the device
-tree, as children of the host bridge node. Even though those devices are
-discoverable by probing, it might be necessary to describe properties that
-aren't provided by standard PCIe capabilities.
-
-Required properties:
-
-- reg:
- Identifies the PCI-PCI bridge. As defined in the IEEE Std 1275-1994
- document, it is a five-cell address encoded as (phys.hi phys.mid
- phys.lo size.hi size.lo). phys.hi should contain the device's BDF as
- 0b00000000 bbbbbbbb dddddfff 00000000. The other cells should be zero.
-
- The bus number is defined by firmware, through the standard bridge
- configuration mechanism. If this port is a switch port, then firmware
- allocates the bus number and writes it into the Secondary Bus Number
- register of the bridge directly above this port. Otherwise, the bus
- number of a root port is the first number in the bus-range property,
- defaulting to zero.
-
- If firmware leaves the ARI Forwarding Enable bit set in the bridge
- above this port, then phys.hi contains the 8-bit function number as
- 0b00000000 bbbbbbbb ffffffff 00000000. Note that the PCIe specification
- recommends that firmware only leaves ARI enabled when it knows that the
- OS is ARI-aware.
-
-Optional properties:
-
-- external-facing:
- When present, the port is external-facing. All bridges and endpoints
- downstream of this port are external to the machine. The OS can, for
- example, use this information to identify devices that cannot be
- trusted with relaxed DMA protection, as users could easily attach
- malicious devices to this port.
-
-Example:
-
-pcie@10000000 {
- compatible = "pci-host-ecam-generic";
- ...
- pcie@0008 {
- /* Root port 00:01.0 is external-facing */
- reg = <0x00000800 0 0 0 0>;
- external-facing;
- };
-};
diff --git a/Documentation/devicetree/bindings/pci/pcie-al.txt b/Documentation/devicetree/bindings/pci/pcie-al.txt
deleted file mode 100644
index 2ad1fe466eab..000000000000
--- a/Documentation/devicetree/bindings/pci/pcie-al.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Amazon Annapurna Labs PCIe host bridge
-
-Amazon's Annapurna Labs PCIe Host Controller is based on the Synopsys DesignWare
-PCI core. It inherits common properties defined in
-Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml.
-
-Properties of the host controller node that differ from it are:
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: Value should contain
- - "amazon,al-alpine-v2-pcie" for alpine_v2
- - "amazon,al-alpine-v3-pcie" for alpine_v3
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Register ranges as listed in the reg-names property
-
-- reg-names:
- Usage: required
- Value type: <stringlist>
- Definition: Must include the following entries
- - "config" PCIe ECAM space
- - "controller" AL proprietary registers
- - "dbi" Designware PCIe registers
-
-Example:
-
- pcie-external0: pcie@fb600000 {
- compatible = "amazon,al-alpine-v3-pcie";
- reg = <0x0 0xfb600000 0x0 0x00100000
- 0x0 0xfd800000 0x0 0x00010000
- 0x0 0xfd810000 0x0 0x00001000>;
- reg-names = "config", "controller", "dbi";
- bus-range = <0 255>;
- device_type = "pci";
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-map-mask = <0x00 0 0 7>;
- interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; /* INTa */
- ranges = <0x02000000 0x0 0xc0010000 0x0 0xc0010000 0x0 0x07ff0000>;
- };
diff --git a/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi-common.yaml b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi-common.yaml
new file mode 100644
index 000000000000..fe2e8beb5bab
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi-common.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/plda,xpressrich3-axi-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PLDA XpressRICH PCIe host common properties
+
+maintainers:
+ - Daire McNamara <daire.mcnamara@microchip.com>
+ - Kevin Xie <kevin.xie@starfivetech.com>
+
+description:
+ Generic PLDA XpressRICH PCIe host common properties.
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ reg:
+ maxItems: 3
+ minItems: 2
+
+ reg-names:
+ oneOf:
+ - items:
+ - const: cfg
+ - const: apb
+ - items:
+ - const: cfg
+ - const: bridge
+ - const: ctrl
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: PCIe host controller
+ - description: builtin MSI controller
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: pcie
+ - const: msi
+
+ msi-controller:
+ description: Identifies the node as an MSI controller.
+
+ msi-parent:
+ description: MSI controller the device is capable of using.
+
+ interrupt-controller:
+ type: object
+ properties:
+ '#address-cells':
+ const: 0
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+ required:
+ - '#address-cells'
+ - '#interrupt-cells'
+ - interrupt-controller
+
+ additionalProperties: false
+
+required:
+ - reg
+ - reg-names
+ - interrupts
+ - msi-controller
+ - '#interrupt-cells'
+ - interrupt-map-mask
+ - interrupt-map
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml
new file mode 100644
index 000000000000..77f8faf54737
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-common.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PCI Express Root Complex Common Properties
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+properties:
+ reg:
+ minItems: 4
+ maxItems: 6
+
+ reg-names:
+ minItems: 4
+ maxItems: 6
+
+ interrupts:
+ minItems: 1
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 9
+
+ iommu-map:
+ minItems: 1
+ maxItems: 16
+
+ clocks:
+ minItems: 3
+ maxItems: 13
+
+ clock-names:
+ minItems: 3
+ maxItems: 13
+
+ dma-coherent: true
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: pcie-mem
+ - const: cpu-pcie
+
+ phys:
+ maxItems: 1
+ deprecated: true
+ description:
+ This property is deprecated, instead of referencing this property from
+ the host bridge node, use the property from the PCIe root port node.
+
+ phy-names:
+ items:
+ - const: pciephy
+ deprecated: true
+ description:
+ Phandle to the register map node. This property is deprecated, and not
+ required to add in the root port also, as the root port has only one phy.
+
+ power-domains:
+ maxItems: 1
+
+ required-opps:
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 12
+
+ reset-names:
+ minItems: 1
+ maxItems: 12
+
+ perst-gpios:
+ description: GPIO controlled connection to PERST# signal. This property is
+ deprecated, instead of referencing this property from the host bridge node,
+ use the reset-gpios property from the root port node.
+ maxItems: 1
+ deprecated: true
+
+ wake-gpios:
+ description: GPIO controlled connection to WAKE# signal. This property is
+ deprecated, instead of referencing this property from the host bridge node,
+ use the property from the PCIe root port node.
+ maxItems: 1
+ deprecated: true
+
+ vddpe-3v3-supply:
+ description: PCIe endpoint power supply
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+patternProperties:
+ "^pcie@":
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ unevaluatedProperties: false
+
+required:
+ - reg
+ - reg-names
+ - interrupt-map-mask
+ - interrupt-map
+ - clocks
+ - clock-names
+
+anyOf:
+ - required:
+ - interrupts
+ - interrupt-names
+ - "#interrupt-cells"
+ - required:
+ - msi-map
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
index 3d23599e5e91..bed9a40b186b 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
@@ -4,19 +4,25 @@
$id: http://devicetree.org/schemas/pci/qcom,pcie-ep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm PCIe Endpoint Controller binding
+title: Qualcomm PCIe Endpoint Controller
maintainers:
- - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
-
-allOf:
- - $ref: "pci-ep.yaml#"
+ - Manivannan Sadhasivam <mani@kernel.org>
properties:
compatible:
- const: qcom,sdx55-pcie-ep
+ oneOf:
+ - enum:
+ - qcom,sa8775p-pcie-ep
+ - qcom,sar2130p-pcie-ep
+ - qcom,sdx55-pcie-ep
+ - qcom,sm8450-pcie-ep
+ - items:
+ - const: qcom,sdx65-pcie-ep
+ - const: qcom,sdx55-pcie-ep
reg:
+ minItems: 6
items:
- description: Qualcomm-specific PARF configuration registers
- description: DesignWare PCIe registers
@@ -24,8 +30,10 @@ properties:
- description: Address Translation Unit (ATU) registers
- description: Memory region used to map remote RC address space
- description: BAR memory region
+ - description: DMA register space
reg-names:
+ minItems: 6
items:
- const: parf
- const: dbi
@@ -33,45 +41,43 @@ properties:
- const: atu
- const: addr_space
- const: mmio
+ - const: dma
clocks:
- items:
- - description: PCIe Auxiliary clock
- - description: PCIe CFG AHB clock
- - description: PCIe Master AXI clock
- - description: PCIe Slave AXI clock
- - description: PCIe Slave Q2A AXI clock
- - description: PCIe Sleep clock
- - description: PCIe Reference clock
+ minItems: 5
+ maxItems: 9
clock-names:
- items:
- - const: aux
- - const: cfg
- - const: bus_master
- - const: bus_slave
- - const: slave_q2a
- - const: sleep
- - const: ref
+ minItems: 5
+ maxItems: 9
qcom,perst-regs:
description: Reference to a syscon representing TCSR followed by the two
offsets within syscon for Perst enable and Perst separation
enable registers
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- minItems: 3
- maxItems: 3
+ - items:
+ - description: Syscon to TCSR system registers
+ - description: Perst enable offset
+ - description: Perst separation enable offset
interrupts:
+ minItems: 2
items:
- description: PCIe Global interrupt
- description: PCIe Doorbell interrupt
+ - description: DMA interrupt
interrupt-names:
+ minItems: 2
items:
- const: global
- const: doorbell
+ - const: dma
+
+ iommus:
+ maxItems: 1
reset-gpios:
description: GPIO used as PERST# input signal
@@ -81,6 +87,16 @@ properties:
description: GPIO used as WAKE# output signal
maxItems: 1
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: pcie-mem
+ - const: cpu-pcie
+
+ dma-coherent: true
+
resets:
maxItems: 1
@@ -105,22 +121,176 @@ required:
- reg-names
- clocks
- clock-names
- - qcom,perst-regs
- interrupts
- interrupt-names
- reset-gpios
+ - interconnects
+ - interconnect-names
- resets
- reset-names
- power-domains
+allOf:
+ - $ref: pci-ep.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-pcie-ep
+ then:
+ properties:
+ clocks:
+ items:
+ - description: PCIe Auxiliary clock
+ - description: PCIe CFG AHB clock
+ - description: PCIe Master AXI clock
+ - description: PCIe Slave AXI clock
+ - description: PCIe Slave Q2A AXI clock
+ - description: PCIe DDRSS SF TBU clock
+ - description: PCIe AGGRE NOC AXI clock
+ - description: PCIe CFG NOC AXI clock
+ - description: PCIe QMIP AHB clock
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg
+ - const: bus_master
+ - const: bus_slave
+ - const: slave_q2a
+ - const: ddrss_sf_tbu
+ - const: aggre_noc_axi
+ - const: cnoc_sf_axi
+ - const: qmip_pcie_ahb
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdx55-pcie-ep
+ then:
+ properties:
+ reg:
+ minItems: 6
+ maxItems: 6
+ reg-names:
+ minItems: 6
+ maxItems: 6
+ interrupts:
+ minItems: 2
+ maxItems: 2
+ interrupt-names:
+ minItems: 2
+ maxItems: 2
+ iommus: false
+ else:
+ properties:
+ reg:
+ minItems: 7
+ maxItems: 7
+ reg-names:
+ minItems: 7
+ maxItems: 7
+ interrupts:
+ minItems: 3
+ maxItems: 3
+ interrupt-names:
+ minItems: 3
+ maxItems: 3
+ required:
+ - iommus
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdx55-pcie-ep
+ then:
+ properties:
+ clocks:
+ items:
+ - description: PCIe Auxiliary clock
+ - description: PCIe CFG AHB clock
+ - description: PCIe Master AXI clock
+ - description: PCIe Slave AXI clock
+ - description: PCIe Slave Q2A AXI clock
+ - description: PCIe Sleep clock
+ - description: PCIe Reference clock
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg
+ - const: bus_master
+ - const: bus_slave
+ - const: slave_q2a
+ - const: sleep
+ - const: ref
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-pcie-ep
+ then:
+ properties:
+ clocks:
+ items:
+ - description: PCIe Auxiliary clock
+ - description: PCIe CFG AHB clock
+ - description: PCIe Master AXI clock
+ - description: PCIe Slave AXI clock
+ - description: PCIe Slave Q2A AXI clock
+ - description: PCIe Reference clock
+ - description: PCIe DDRSS SF TBU clock
+ - description: PCIe AGGRE NOC AXI clock
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg
+ - const: bus_master
+ - const: bus_slave
+ - const: slave_q2a
+ - const: ref
+ - const: ddrss_sf_tbu
+ - const: aggre_noc_axi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-pcie-ep
+ then:
+ properties:
+ clocks:
+ items:
+ - description: PCIe Auxiliary clock
+ - description: PCIe CFG AHB clock
+ - description: PCIe Master AXI clock
+ - description: PCIe Slave AXI clock
+ - description: PCIe Slave Q2A AXI clock
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg
+ - const: bus_master
+ - const: bus_slave
+ - const: slave_q2a
+
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sdx55.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sdx55.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- pcie_ep: pcie-ep@40000000 {
+
+ pcie_ep: pcie-ep@1c00000 {
compatible = "qcom,sdx55-pcie-ep";
reg = <0x01c00000 0x3000>,
<0x40000000 0xf1d>,
@@ -146,6 +316,9 @@ examples:
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "global", "doorbell";
+ interconnects = <&system_noc MASTER_PCIE &mc_virt SLAVE_EBI_CH0>,
+ <&mem_noc MASTER_AMPSS_M0 &system_noc SLAVE_PCIE_0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
reset-gpios = <&tlmm 57 GPIO_ACTIVE_LOW>;
wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>;
resets = <&gcc GCC_PCIE_BCR>;
@@ -155,4 +328,5 @@ examples:
phy-names = "pciephy";
max-link-speed = <3>;
num-lanes = <2>;
+ linux,pci-domain = <0>;
};
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sa8255p.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sa8255p.yaml
new file mode 100644
index 000000000000..1f2d098b8638
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sa8255p.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sa8255p.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SA8255p based firmware managed and ECAM compliant PCIe Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SA8255p SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP which is managed by firmware, and configured in ECAM mode.
+
+properties:
+ compatible:
+ const: qcom,pcie-sa8255p
+
+ reg:
+ description:
+ The base address and size of the ECAM area for accessing PCI
+ Configuration Space, as accessed from the parent bus. The base
+ address corresponds to the first bus in the "bus-range" property. If
+ no "bus-range" is specified, this will be bus 0 (the default).
+ maxItems: 1
+
+ ranges:
+ description:
+ As described in IEEE Std 1275-1994, but must provide at least a
+ definition of non-prefetchable memory. One or both of prefetchable Memory
+ may also be provided.
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ minItems: 8
+ maxItems: 8
+
+ interrupt-names:
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+
+ power-domains:
+ maxItems: 1
+
+ dma-coherent: true
+ iommu-map: true
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - power-domains
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pci@1c00000 {
+ compatible = "qcom,pcie-sa8255p";
+ reg = <0x4 0x00000000 0 0x10000000>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0x0 0x40100000 0x0 0x40100000 0x0 0x1ff00000>,
+ <0x43000000 0x4 0x10100000 0x4 0x10100000 0x0 0x40000000>;
+ bus-range = <0x00 0xff>;
+ dma-coherent;
+ linux,pci-domain = <0>;
+ power-domains = <&scmi5_pd 0>;
+ iommu-map = <0x0 &pcie_smmu 0x0000 0x1>,
+ <0x100 &pcie_smmu 0x0001 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml
new file mode 100644
index 000000000000..63630a814f28
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sa8775p.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SA8775p PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SA8775p SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,pcie-sa8775p
+ - items:
+ - enum:
+ - qcom,pcie-qcs8300
+ - const: qcom,pcie-sa8775p
+
+ reg:
+ minItems: 6
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ items:
+ - description: PCIe controller reset
+ - description: PCIe link down reset
+
+ reset-names:
+ items:
+ - const: pci
+ - const: link_down
+
+required:
+ - interconnects
+ - interconnect-names
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,sa8775p-rpmh.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sa8775p";
+ reg = <0x0 0x01c00000 0x0 0x3000>,
+ <0x0 0x40000000 0x0 0xf20>,
+ <0x0 0x40000f20 0x0 0xa8>,
+ <0x0 0x40001000 0x0 0x4000>,
+ <0x0 0x40100000 0x0 0x100000>,
+ <0x0 0x01c03000 0x0 0x1000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
+ <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <2>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ assigned-clocks = <&gcc GCC_PCIE_0_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 434 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 435 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 438 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 439 IRQ_TYPE_LEVEL_HIGH>;
+
+ interconnects = <&pcie_anoc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_0 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ iommu-map = <0x0 &pcie_smmu 0x0000 0x1>,
+ <0x100 &pcie_smmu 0x0001 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>,
+ <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
+ reset-names = "pci",
+ "link_down";
+
+ perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml
new file mode 100644
index 000000000000..1f942b3075f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sc7280.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7280 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SC7280 SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ const: qcom,pcie-sc7280
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 13
+ maxItems: 13
+
+ clock-names:
+ items:
+ - const: pipe # PIPE clock
+ - const: pipe_mux # PIPE MUX
+ - const: phy_pipe # PIPE output clock
+ - const: ref # REFERENCE clock
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: tbu # PCIe TBU clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - const: aggre0 # Aggre NoC PCIe CENTER SF AXI clock
+ - const: aggre1 # Aggre NoC PCIe1 AXI clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c08000 {
+ compatible = "qcom,pcie-sc7280";
+ reg = <0 0x01c08000 0 0x3000>,
+ <0 0x40000000 0 0xf1d>,
+ <0 0x40000f20 0 0xa8>,
+ <0 0x40001000 0 0x1000>,
+ <0 0x40100000 0 0x100000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
+ <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <1>;
+ num-lanes = <2>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ assigned-clocks = <&gcc GCC_PCIE_1_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
+ <&gcc GCC_PCIE_1_PIPE_CLK_SRC>,
+ <&pcie1_phy>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_PCIE_1_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>,
+ <&gcc GCC_DDRSS_PCIE_SF_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_CENTER_SF_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_1_AXI_CLK>;
+
+ clock-names = "pipe",
+ "pipe_mux",
+ "phy_pipe",
+ "ref",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "tbu",
+ "ddrss_sf_tbu",
+ "aggre0",
+ "aggre1";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 0 434 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 0 435 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 0 438 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 0 439 IRQ_TYPE_LEVEL_HIGH>;
+
+ iommu-map = <0x0 &apps_smmu 0x1c80 0x1>,
+ <0x100 &apps_smmu 0x1c81 0x1>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_clkreq_n>;
+
+ power-domains = <&gcc GCC_PCIE_1_GDSC>;
+
+ resets = <&gcc GCC_PCIE_1_BCR>;
+ reset-names = "pci";
+
+ vddpe-3v3-supply = <&pp3300_ssd>;
+ pcie1_port0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ phys = <&pcie1_phy>;
+
+ reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml
new file mode 100644
index 000000000000..6a7c410c9fc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sc8180x.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sc8180x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8180x PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SC8180x SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ const: qcom,pcie-sc8180x
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: pipe # PIPE clock
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8180x.h>
+ #include <dt-bindings/interconnect/qcom,sc8180x.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sc8180x";
+ reg = <0 0x01c00000 0 0x3000>,
+ <0 0x60000000 0 0xf1d>,
+ <0 0x60000f20 0 0xa8>,
+ <0 0x60001000 0 0x1000>,
+ <0 0x60100000 0 0x100000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config";
+ ranges = <0x01000000 0x0 0x60200000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <2>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ assigned-clocks = <&gcc GCC_PCIE_0_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>,
+ <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
+ clock-names = "pipe",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ interconnects = <&aggre2_noc MASTER_PCIE 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_PCIE_0 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ iommu-map = <0x0 &apps_smmu 0x1d80 0x1>,
+ <0x100 &apps_smmu 0x1d81 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "pci";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml
new file mode 100644
index 000000000000..bc0e71dc06a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sc8280xp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SC8280XP SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ enum:
+ - qcom,pcie-sa8540p
+ - qcom,pcie-sc8280xp
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 8
+ maxItems: 9
+
+ clock-names:
+ minItems: 8
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - const: noc_aggr_4 # NoC aggregate 4 clock
+ - const: noc_aggr_south_sf # NoC aggregate South SF clock
+ - const: cnoc_qx # Configuration NoC QX clock
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+required:
+ - interconnects
+ - interconnect-names
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pcie-sc8280xp
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ maxItems: 4
+ interrupt-names:
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names:
+ items:
+ - const: msi
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sc8280xp.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c20000 {
+ compatible = "qcom,pcie-sc8280xp";
+ reg = <0x0 0x01c20000 0x0 0x3000>,
+ <0x0 0x3c000000 0x0 0xf1d>,
+ <0x0 0x3c000f20 0x0 0xa8>,
+ <0x0 0x3c001000 0x0 0x1000>,
+ <0x0 0x3c100000 0x0 0x100000>,
+ <0x0 0x01c23000 0x0 0x1000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x3c200000 0x0 0x100000>,
+ <0x02000000 0x0 0x3c300000 0x0 0x3c300000 0x0 0x1d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <2>;
+ num-lanes = <4>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ assigned-clocks = <&gcc GCC_PCIE_2A_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+ clocks = <&gcc GCC_PCIE_2A_AUX_CLK>,
+ <&gcc GCC_PCIE_2A_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_2A_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_2A_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_2A_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_DDRSS_PCIE_SF_TBU_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_4_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_SOUTH_SF_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "ddrss_sf_tbu",
+ "noc_aggr_4",
+ "noc_aggr_south_sf";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 523 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 524 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 525 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 530 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 531 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 532 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 533 IRQ_TYPE_LEVEL_HIGH>;
+
+ interconnects = <&aggre2_noc MASTER_PCIE_2A 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_PCIE_2A 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ phys = <&pcie2a_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie2a_default>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc PCIE_2A_GDSC>;
+
+ resets = <&gcc GCC_PCIE_2A_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
+ vddpe-3v3-supply = <&vreg_nvme>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml
new file mode 100644
index 000000000000..6a5421e4f19d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml
@@ -0,0 +1,165 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sm8150.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SM8150 SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,pcie-sm8150
+ - items:
+ - enum:
+ - qcom,pcie-qcs615
+ - const: qcom,pcie-sm8150
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: pipe # PIPE clock
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sm8150.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sm8150";
+ reg = <0 0x01c00000 0 0x3000>,
+ <0 0x60000000 0 0xf1d>,
+ <0 0x60000f20 0 0xa8>,
+ <0 0x60001000 0 0x1000>,
+ <0 0x60100000 0 0x100000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <1>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>,
+ <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>;
+ clock-names = "pipe",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a";
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ iommu-map = <0x0 &apps_smmu 0x1d80 0x1>,
+ <0x100 &apps_smmu 0x1d81 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 35 GPIO_ACTIVE_HIGH>;
+ wake-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml
new file mode 100644
index 000000000000..adbeaa8f2c13
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sm8250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8250 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SM8250 SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ const: qcom,pcie-sm8250
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 8
+ maxItems: 9
+
+ clock-names:
+ # Unfortunately the "optional" ref clock is used in the middle of the list
+ oneOf:
+ - items:
+ - const: pipe # PIPE clock
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: ref # REFERENCE clock
+ - const: tbu # PCIe TBU clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - items:
+ - const: pipe # PIPE clock
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: tbu # PCIe TBU clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sm8250";
+ reg = <0 0x01c00000 0 0x3000>,
+ <0 0x60000000 0 0xf1d>,
+ <0 0x60000f20 0 0xa8>,
+ <0 0x60001000 0 0x1000>,
+ <0 0x60100000 0 0x100000>,
+ <0 0x01c03000 0 0x1000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <1>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>,
+ <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>,
+ <&gcc GCC_DDRSS_PCIE_SF_TBU_CLK>;
+ clock-names = "pipe",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "tbu",
+ "ddrss_sf_tbu";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
+ <0x100 &apps_smmu 0x1c01 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 79 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml
new file mode 100644
index 000000000000..5744d5e969fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sm8350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SM8350 SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ const: qcom,pcie-sm8350
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 8
+ maxItems: 9
+
+ clock-names:
+ minItems: 8
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: tbu # PCIe TBU clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - const: aggre1 # Aggre NoC PCIe1 AXI clock
+ - const: aggre0 # Aggre NoC PCIe0 AXI clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8350.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sm8350.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sm8350";
+ reg = <0 0x01c00000 0 0x3000>,
+ <0 0x60000000 0 0xf1d>,
+ <0 0x60000f20 0 0xa8>,
+ <0 0x60001000 0 0x1000>,
+ <0 0x60100000 0 0x100000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <1>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_TBU_CLK>,
+ <&gcc GCC_DDRSS_PCIE_SF_TBU_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_1_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_0_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "tbu",
+ "ddrss_sf_tbu",
+ "aggre1",
+ "aggre0";
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
+ <0x100 &apps_smmu 0x1c01 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
new file mode 100644
index 000000000000..28b8ffb74124
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
@@ -0,0 +1,185 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sm8450.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8450 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SM8450 SoC PCIe root complex controller is based on the Synopsys
+ DesignWare PCIe IP.
+
+properties:
+ compatible:
+ enum:
+ - qcom,pcie-sm8450-pcie0
+ - qcom,pcie-sm8450-pcie1
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 11
+ maxItems: 12
+
+ clock-names:
+ minItems: 11
+ items:
+ - const: pipe # PIPE clock
+ - const: pipe_mux # PIPE MUX
+ - const: phy_pipe # PIPE output clock
+ - const: ref # REFERENCE clock
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - enum: [aggre0, aggre1] # Aggre NoC PCIe0/1 AXI clock
+ - const: aggre1 # Aggre NoC PCIe1 AXI clock
+
+ interrupts:
+ minItems: 9
+ maxItems: 9
+
+ interrupt-names:
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pci
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sm8450.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sm8450-pcie0";
+ reg = <0 0x01c00000 0 0x3000>,
+ <0 0x60000000 0 0xf1d>,
+ <0 0x60000f20 0 0xa8>,
+ <0 0x60001000 0 0x1000>,
+ <0 0x60100000 0 0x100000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ max-link-speed = <2>;
+ num-lanes = <1>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>,
+ <&gcc GCC_PCIE_0_PIPE_CLK_SRC>,
+ <&pcie0_phy>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_DDRSS_PCIE_SF_TBU_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_0_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_1_AXI_CLK>;
+ clock-names = "pipe",
+ "pipe_mux",
+ "phy_pipe",
+ "ref",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "ddrss_sf_tbu",
+ "aggre0",
+ "aggre1";
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+ msi-map = <0x0 &gic_its 0x5981 0x1>,
+ <0x100 &gic_its 0x5980 0x1>;
+ msi-map-mask = <0xff00>;
+
+ iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
+ <0x100 &apps_smmu 0x1c01 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml
new file mode 100644
index 000000000000..3a94a9c1bb15
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-sm8550.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm SM8550 SoC (and compatible) PCIe root complex controller is based on
+ the Synopsys DesignWare PCIe IP.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,pcie-sm8550
+ - items:
+ - enum:
+ - qcom,kaanapali-pcie
+ - qcom,sar2130p-pcie
+ - qcom,pcie-sm8650
+ - qcom,pcie-sm8750
+ - const: qcom,pcie-sm8550
+
+ reg:
+ minItems: 5
+ maxItems: 6
+
+ reg-names:
+ minItems: 5
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 7
+ maxItems: 9
+
+ clock-names:
+ minItems: 7
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: ddrss_sf_tbu # PCIe SF TBU clock
+ - const: noc_aggr # Aggre NoC PCIe AXI clock
+ - const: cnoc_sf_axi # Config NoC PCIe1 AXI clock
+ - const: qmip_pcie_ahb # QMIP PCIe AHB clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: pci # PCIe core reset
+ - const: link_down # PCIe link down reset
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c00000 {
+ compatible = "qcom,pcie-sm8550";
+ reg = <0 0x01c00000 0 0x3000>,
+ <0 0x60000000 0 0xf1d>,
+ <0 0x60000f20 0 0xa8>,
+ <0 0x60001000 0 0x1000>,
+ <0 0x60100000 0 0x100000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <2>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "ddrss_sf_tbu",
+ "noc_aggr";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ interconnects = <&pcie_noc MASTER_PCIE_0 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &cnoc_main SLAVE_PCIE_0 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
+ <0x100 &apps_smmu 0x1401 0x1>;
+
+ phys = <&pcie0_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc PCIE_0_GDSC>;
+
+ resets = <&gcc GCC_PCIE_0_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml
new file mode 100644
index 000000000000..62c674ca0cf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-x1e80100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 PCI Express Root Complex
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+description:
+ Qualcomm X1E80100 SoC (and compatible) PCIe root complex controller is based on
+ the Synopsys DesignWare PCIe IP.
+
+properties:
+ compatible:
+ const: qcom,pcie-x1e80100
+
+ reg:
+ minItems: 6
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: parf # Qualcomm specific registers
+ - const: dbi # DesignWare PCIe registers
+ - const: elbi # External local bus interface registers
+ - const: atu # ATU address space
+ - const: config # PCIe configuration space
+ - const: mhi # MHI registers
+
+ clocks:
+ minItems: 6
+ maxItems: 7
+
+ clock-names:
+ minItems: 6
+ items:
+ - const: aux # Auxiliary clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
+ - const: slave_q2a # Slave Q2A clock
+ - const: noc_aggr # Aggre NoC PCIe AXI clock
+ - const: cnoc_sf_axi # Config NoC PCIe1 AXI clock
+
+ interrupts:
+ minItems: 8
+ maxItems: 9
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: pci # PCIe core reset
+ - const: link_down # PCIe link down reset
+
+required:
+ - power-domains
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,pcie-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@1c08000 {
+ compatible = "qcom,pcie-x1e80100";
+ reg = <0 0x01c08000 0 0x3000>,
+ <0 0x7c000000 0 0xf1d>,
+ <0 0x7c000f40 0 0xa8>,
+ <0 0x7c001000 0 0x1000>,
+ <0 0x7c100000 0 0x100000>,
+ <0 0x01c0b000 0 0x1000>;
+ reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
+ <0x02000000 0x0 0x60300000 0x0 0x60300000 0x0 0x3d00000>;
+
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ num-lanes = <2>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ clocks = <&gcc GCC_PCIE_4_AUX_CLK>,
+ <&gcc GCC_PCIE_4_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_4_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_4_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_4_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_CFG_NOC_PCIE_ANOC_NORTH_AHB_CLK>,
+ <&gcc GCC_CNOC_PCIE_NORTH_SF_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "noc_aggr",
+ "cnoc_sf_axi";
+
+ dma-coherent;
+
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7", "global";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ interconnects = <&pcie_noc MASTER_PCIE_4 0 &mc_virt SLAVE_EBI1 0>,
+ <&gem_noc MASTER_APPSS_PROC 0 &cnoc_main SLAVE_PCIE_4 0>;
+ interconnect-names = "pcie-mem", "cpu-pcie";
+
+ iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
+ <0x100 &apps_smmu 0x1401 0x1>;
+
+ phys = <&pcie4_phy>;
+ phy-names = "pciephy";
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ power-domains = <&gcc GCC_PCIE_4_GDSC>;
+
+ resets = <&gcc GCC_PCIE_4_BCR>;
+ reset-names = "pci";
+
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
index dd84f1487bed..c61930441be0 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml
@@ -8,7 +8,7 @@ title: Qualcomm PCI express root complex
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Stanimir Varbanov <svarbanov@mm-sol.com>
+ - Manivannan Sadhasivam <mani@kernel.org>
description: |
Qualcomm PCIe root complex controller is based on the Synopsys DesignWare
@@ -16,39 +16,50 @@ description: |
properties:
compatible:
- enum:
- - qcom,pcie-ipq8064
- - qcom,pcie-ipq8064-v2
- - qcom,pcie-apq8064
- - qcom,pcie-apq8084
- - qcom,pcie-msm8996
- - qcom,pcie-ipq4019
- - qcom,pcie-ipq8074
- - qcom,pcie-qcs404
- - qcom,pcie-sc7280
- - qcom,pcie-sc8180x
- - qcom,pcie-sdm845
- - qcom,pcie-sm8150
- - qcom,pcie-sm8250
- - qcom,pcie-sm8450-pcie0
- - qcom,pcie-sm8450-pcie1
- - qcom,pcie-ipq6018
+ oneOf:
+ - enum:
+ - qcom,pcie-apq8064
+ - qcom,pcie-apq8084
+ - qcom,pcie-ipq4019
+ - qcom,pcie-ipq5018
+ - qcom,pcie-ipq6018
+ - qcom,pcie-ipq8064
+ - qcom,pcie-ipq8064-v2
+ - qcom,pcie-ipq8074
+ - qcom,pcie-ipq8074-gen3
+ - qcom,pcie-ipq9574
+ - qcom,pcie-msm8996
+ - qcom,pcie-qcs404
+ - qcom,pcie-sdm845
+ - qcom,pcie-sdx55
+ - items:
+ - enum:
+ - qcom,pcie-ipq5332
+ - qcom,pcie-ipq5424
+ - const: qcom,pcie-ipq9574
+ - items:
+ - const: qcom,pcie-msm8998
+ - const: qcom,pcie-msm8996
reg:
minItems: 4
- maxItems: 5
+ maxItems: 6
reg-names:
minItems: 4
- maxItems: 5
+ maxItems: 6
interrupts:
minItems: 1
- maxItems: 8
+ maxItems: 9
interrupt-names:
minItems: 1
- maxItems: 8
+ maxItems: 9
+
+ iommu-map:
+ minItems: 1
+ maxItems: 16
# Common definitions for clocks, clock-names and reset.
# Platform constraints are described later.
@@ -60,11 +71,21 @@ properties:
minItems: 3
maxItems: 13
+ dma-coherent: true
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: pcie-mem
+ - const: cpu-pcie
+
resets:
minItems: 1
maxItems: 12
- resets-names:
+ reset-names:
minItems: 1
maxItems: 12
@@ -94,6 +115,9 @@ properties:
description: GPIO controlled connection to PERST# signal
maxItems: 1
+ required-opps:
+ maxItems: 1
+
wake-gpios:
description: GPIO controlled connection to WAKE# signal
maxItems: 1
@@ -102,16 +126,21 @@ required:
- compatible
- reg
- reg-names
- - interrupts
- - interrupt-names
- - "#interrupt-cells"
- interrupt-map-mask
- interrupt-map
- clocks
- clock-names
+anyOf:
+ - required:
+ - interrupts
+ - interrupt-names
+ - "#interrupt-cells"
+ - required:
+ - msi-map
+
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
- if:
properties:
compatible:
@@ -140,19 +169,24 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pcie-ipq5018
- qcom,pcie-ipq6018
+ - qcom,pcie-ipq8074-gen3
+ - qcom,pcie-ipq9574
then:
properties:
reg:
minItems: 5
- maxItems: 5
+ maxItems: 6
reg-names:
+ minItems: 5
items:
- const: dbi # DesignWare PCIe registers
- const: elbi # External local bus interface registers
- const: atu # ATU address space
- const: parf # Qualcomm specific registers
- const: config # PCIe configuration space
+ - const: mhi # MHI registers
- if:
properties:
@@ -166,36 +200,36 @@ allOf:
properties:
reg:
minItems: 4
- maxItems: 4
+ maxItems: 5
reg-names:
+ minItems: 4
items:
- const: parf # Qualcomm specific registers
- const: dbi # DesignWare PCIe registers
- const: elbi # External local bus interface registers
- const: config # PCIe configuration space
+ - const: mhi # MHI registers
- if:
properties:
compatible:
contains:
enum:
- - qcom,pcie-sc7280
- - qcom,pcie-sc8180x
- - qcom,pcie-sm8250
- - qcom,pcie-sm8450-pcie0
- - qcom,pcie-sm8450-pcie1
+ - qcom,pcie-sdx55
then:
properties:
reg:
minItems: 5
- maxItems: 5
+ maxItems: 6
reg-names:
+ minItems: 5
items:
- const: parf # Qualcomm specific registers
- const: dbi # DesignWare PCIe registers
- const: elbi # External local bus interface registers
- const: atu # ATU address space
- const: config # PCIe configuration space
+ - const: mhi # MHI registers
- if:
properties:
@@ -297,29 +331,66 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pcie-ipq5018
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
+ clock-names:
+ items:
+ - const: iface # PCIe to SysNOC BIU clock
+ - const: axi_m # AXI Master clock
+ - const: axi_s # AXI Slave clock
+ - const: ahb # AHB clock
+ - const: aux # Auxiliary clock
+ - const: axi_bridge # AXI bridge clock
+ resets:
+ minItems: 8
+ maxItems: 8
+ reset-names:
+ items:
+ - const: pipe # PIPE reset
+ - const: sleep # Sleep reset
+ - const: sticky # Core sticky reset
+ - const: axi_m # AXI master reset
+ - const: axi_s # AXI slave reset
+ - const: ahb # AHB reset
+ - const: axi_m_sticky # AXI master sticky reset
+ - const: axi_s_sticky # AXI slave sticky reset
+ interrupts:
+ minItems: 9
+ maxItems: 9
+ interrupt-names:
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pcie-msm8996
then:
- oneOf:
- - properties:
- clock-names:
- items:
- - const: pipe # Pipe Clock driving internal logic
- - const: aux # Auxiliary (AUX) clock
- - const: cfg # Configuration clock
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - properties:
- clock-names:
- items:
- - const: pipe # Pipe Clock driving internal logic
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - const: cfg # Configuration clock
- - const: aux # Auxiliary (AUX) clock
properties:
clocks:
minItems: 5
maxItems: 5
+ clock-names:
+ items:
+ - const: pipe # Pipe Clock driving internal logic
+ - const: aux # Auxiliary (AUX) clock
+ - const: cfg # Configuration clock
+ - const: bus_master # Master AXI clock
+ - const: bus_slave # Slave AXI clock
resets: false
reset-names: false
@@ -360,6 +431,7 @@ allOf:
contains:
enum:
- qcom,pcie-ipq6018
+ - qcom,pcie-ipq8074-gen3
then:
properties:
clocks:
@@ -391,61 +463,78 @@ allOf:
compatible:
contains:
enum:
- - qcom,pcie-qcs404
+ - qcom,pcie-ipq9574
then:
properties:
clocks:
- minItems: 4
- maxItems: 4
+ minItems: 6
+ maxItems: 6
clock-names:
items:
- - const: iface # AHB clock
- - const: aux # Auxiliary clock
- - const: master_bus # AXI Master clock
- - const: slave_bus # AXI Slave clock
+ - const: axi_m # AXI Master clock
+ - const: axi_s # AXI Slave clock
+ - const: axi_bridge
+ - const: rchng
+ - const: ahb
+ - const: aux
+
resets:
- minItems: 6
- maxItems: 6
+ minItems: 8
+ maxItems: 8
reset-names:
items:
- - const: axi_m # AXI Master reset
+ - const: pipe # PIPE reset
+ - const: sticky # Core Sticky reset
+ - const: axi_s_sticky # AXI Slave Sticky reset
- const: axi_s # AXI Slave reset
- const: axi_m_sticky # AXI Master Sticky reset
- - const: pipe_sticky # PIPE sticky reset
- - const: pwr # PWR reset
- - const: ahb # AHB reset
+ - const: axi_m # AXI Master reset
+ - const: aux # AUX Reset
+ - const: ahb # AHB Reset
+
+ interrupts:
+ minItems: 8
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: msi0
+ - const: msi1
+ - const: msi2
+ - const: msi3
+ - const: msi4
+ - const: msi5
+ - const: msi6
+ - const: msi7
+ - const: global
- if:
properties:
compatible:
contains:
enum:
- - qcom,pcie-sc7280
+ - qcom,pcie-qcs404
then:
properties:
clocks:
- minItems: 13
- maxItems: 13
+ minItems: 4
+ maxItems: 4
clock-names:
items:
- - const: pipe # PIPE clock
- - const: pipe_mux # PIPE MUX
- - const: phy_pipe # PIPE output clock
- - const: ref # REFERENCE clock
+ - const: iface # AHB clock
- const: aux # Auxiliary clock
- - const: cfg # Configuration clock
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - const: slave_q2a # Slave Q2A clock
- - const: tbu # PCIe TBU clock
- - const: ddrss_sf_tbu # PCIe SF TBU clock
- - const: aggre0 # Aggre NoC PCIe CENTER SF AXI clock
- - const: aggre1 # Aggre NoC PCIe1 AXI clock
+ - const: master_bus # AXI Master clock
+ - const: slave_bus # AXI Slave clock
resets:
- maxItems: 1
+ minItems: 6
+ maxItems: 6
reset-names:
items:
- - const: pci # PCIe core reset
+ - const: axi_m # AXI Master reset
+ - const: axi_s # AXI Slave reset
+ - const: axi_m_sticky # AXI Master Sticky reset
+ - const: pipe_sticky # PIPE sticky reset
+ - const: pwr # PWR reset
+ - const: ahb # AHB reset
- if:
properties:
@@ -495,103 +584,21 @@ allOf:
compatible:
contains:
enum:
- - qcom,pcie-sc8180x
- - qcom,pcie-sm8150
- - qcom,pcie-sm8250
- then:
- oneOf:
- # Unfortunately the "optional" ref clock is used in the middle of the list
- - properties:
- clocks:
- minItems: 9
- maxItems: 9
- clock-names:
- items:
- - const: pipe # PIPE clock
- - const: aux # Auxiliary clock
- - const: cfg # Configuration clock
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - const: slave_q2a # Slave Q2A clock
- - const: ref # REFERENCE clock
- - const: tbu # PCIe TBU clock
- - const: ddrss_sf_tbu # PCIe SF TBU clock
- - properties:
- clocks:
- minItems: 8
- maxItems: 8
- clock-names:
- items:
- - const: pipe # PIPE clock
- - const: aux # Auxiliary clock
- - const: cfg # Configuration clock
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - const: slave_q2a # Slave Q2A clock
- - const: tbu # PCIe TBU clock
- - const: ddrss_sf_tbu # PCIe SF TBU clock
- properties:
- resets:
- maxItems: 1
- reset-names:
- items:
- - const: pci # PCIe core reset
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,pcie-sm8450-pcie0
+ - qcom,pcie-sdx55
then:
properties:
clocks:
- minItems: 12
- maxItems: 12
- clock-names:
- items:
- - const: pipe # PIPE clock
- - const: pipe_mux # PIPE MUX
- - const: phy_pipe # PIPE output clock
- - const: ref # REFERENCE clock
- - const: aux # Auxiliary clock
- - const: cfg # Configuration clock
- - const: bus_master # Master AXI clock
- - const: bus_slave # Slave AXI clock
- - const: slave_q2a # Slave Q2A clock
- - const: ddrss_sf_tbu # PCIe SF TBU clock
- - const: aggre0 # Aggre NoC PCIe0 AXI clock
- - const: aggre1 # Aggre NoC PCIe1 AXI clock
- resets:
- maxItems: 1
- reset-names:
- items:
- - const: pci # PCIe core reset
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,pcie-sm8450-pcie1
- then:
- properties:
- clocks:
- minItems: 11
- maxItems: 11
+ minItems: 7
+ maxItems: 7
clock-names:
items:
- const: pipe # PIPE clock
- - const: pipe_mux # PIPE MUX
- - const: phy_pipe # PIPE output clock
- - const: ref # REFERENCE clock
- const: aux # Auxiliary clock
- const: cfg # Configuration clock
- const: bus_master # Master AXI clock
- const: bus_slave # Slave AXI clock
- const: slave_q2a # Slave Q2A clock
- - const: ddrss_sf_tbu # PCIe SF TBU clock
- - const: aggre1 # Aggre NoC PCIe1 AXI clock
+ - const: sleep # PCIe Sleep clock
resets:
maxItems: 1
reset-names:
@@ -606,9 +613,12 @@ allOf:
enum:
- qcom,pcie-apq8064
- qcom,pcie-ipq4019
+ - qcom,pcie-ipq5018
- qcom,pcie-ipq8064
- qcom,pcie-ipq8064v2
- qcom,pcie-ipq8074
+ - qcom,pcie-ipq8074-gen3
+ - qcom,pcie-ipq9574
- qcom,pcie-qcs404
then:
required:
@@ -626,21 +636,17 @@ allOf:
- resets
- reset-names
- # Newer chipsets support either 1 or 8 MSI vectors
- # On older chipsets it's always 1 MSI vector
- if:
properties:
compatible:
contains:
enum:
+ - qcom,pcie-ipq6018
+ - qcom,pcie-ipq8074
+ - qcom,pcie-ipq8074-gen3
- qcom,pcie-msm8996
- - qcom,pcie-sc7280
- - qcom,pcie-sc8180x
+ - qcom,pcie-msm8998
- qcom,pcie-sdm845
- - qcom,pcie-sm8150
- - qcom,pcie-sm8250
- - qcom,pcie-sm8450-pcie0
- - qcom,pcie-sm8450-pcie1
then:
oneOf:
- properties:
@@ -652,7 +658,9 @@ allOf:
- properties:
interrupts:
minItems: 8
+ maxItems: 9
interrupt-names:
+ minItems: 8
items:
- const: msi0
- const: msi1
@@ -662,7 +670,20 @@ allOf:
- const: msi5
- const: msi6
- const: msi7
- else:
+ - const: global
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pcie-apq8064
+ - qcom,pcie-apq8084
+ - qcom,pcie-ipq4019
+ - qcom,pcie-ipq8064
+ - qcom,pcie-ipq8064-v2
+ - qcom,pcie-qcs404
+ then:
properties:
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
new file mode 100644
index 000000000000..b23293314a6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rcar-gen4-pci-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen4 PCIe Endpoint
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+allOf:
+ - $ref: snps,dw-pcie-ep.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - renesas,r8a779g0-pcie-ep # R-Car V4H
+ - renesas,r8a779h0-pcie-ep # R-Car V4M
+ - const: renesas,rcar-gen4-pcie-ep # R-Car Gen4
+
+ reg:
+ maxItems: 7
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: atu
+ - const: dma
+ - const: app
+ - const: phy
+ - const: addr_space
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: dma
+ - const: sft_ce
+ - const: app
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: ref
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pwr
+
+ max-link-speed:
+ maximum: 4
+
+ num-lanes:
+ maximum: 4
+
+ max-functions:
+ maximum: 2
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie0_ep: pcie-ep@e65d0000 {
+ compatible = "renesas,r8a779f0-pcie-ep", "renesas,rcar-gen4-pcie-ep";
+ reg = <0 0xe65d0000 0 0x2000>, <0 0xe65d2000 0 0x1000>,
+ <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
+ <0 0xe65d6200 0 0x0e00>, <0 0xe65d7000 0 0x0400>,
+ <0 0xfe000000 0 0x400000>;
+ reg-names = "dbi", "dbi2", "atu", "dma", "app", "phy", "addr_space";
+ interrupts = <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dma", "sft_ce", "app";
+ clocks = <&cpg CPG_MOD 624>, <&pcie0_clkref>;
+ clock-names = "core", "ref";
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 624>;
+ reset-names = "pwr";
+ max-link-speed = <4>;
+ num-lanes = <2>;
+ max-functions = /bits/ 8 <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
new file mode 100644
index 000000000000..bb3f843c59d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rcar-gen4-pci-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen4 PCIe Host
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+allOf:
+ - $ref: snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a779f0-pcie # R-Car S4-8
+ - renesas,r8a779g0-pcie # R-Car V4H
+ - renesas,r8a779h0-pcie # R-Car V4M
+ - const: renesas,rcar-gen4-pcie # R-Car Gen4
+
+ reg:
+ maxItems: 7
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: atu
+ - const: dma
+ - const: app
+ - const: phy
+ - const: config
+
+ interrupts:
+ maxItems: 4
+
+ interrupt-names:
+ items:
+ - const: msi
+ - const: dma
+ - const: sft_ce
+ - const: app
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: ref
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: pwr
+
+ max-link-speed:
+ maximum: 4
+
+ num-lanes:
+ maximum: 4
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie: pcie@e65d0000 {
+ compatible = "renesas,r8a779f0-pcie", "renesas,rcar-gen4-pcie";
+ reg = <0 0xe65d0000 0 0x1000>, <0 0xe65d2000 0 0x0800>,
+ <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
+ <0 0xe65d6200 0 0x0e00>, <0 0xe65d7000 0 0x0400>,
+ <0 0xfe000000 0 0x400000>;
+ reg-names = "dbi", "dbi2", "atu", "dma", "app", "phy", "config";
+ interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma", "sft_ce", "app";
+ clocks = <&cpg CPG_MOD 624>, <&pcie0_clkref>;
+ clock-names = "core", "ref";
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 624>;
+ reset-names = "pwr";
+ max-link-speed = <4>;
+ num-lanes = <2>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x01000000 0 0x00000000 0 0xfe000000 0 0x00400000>,
+ <0x02000000 0 0x30000000 0 0x30000000 0 0x10000000>;
+ dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>;
+ snps,enable-cdm-check;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
index 32a3b7665ff5..6b91581c30ae 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml
@@ -73,21 +73,21 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a774c0-sysc.h>
- pcie0_ep: pcie-ep@fe000000 {
- compatible = "renesas,r8a774c0-pcie-ep",
- "renesas,rcar-gen3-pcie-ep";
- reg = <0xfe000000 0x80000>,
- <0xfe100000 0x100000>,
- <0xfe200000 0x200000>,
- <0x30000000 0x8000000>,
- <0x38000000 0x8000000>;
- reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
- interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- resets = <&cpg 319>;
- power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>;
- clocks = <&cpg CPG_MOD 319>;
- clock-names = "pcie";
- max-functions = /bits/ 8 <1>;
+ pcie0_ep: pcie-ep@fe000000 {
+ compatible = "renesas,r8a774c0-pcie-ep",
+ "renesas,rcar-gen3-pcie-ep";
+ reg = <0xfe000000 0x80000>,
+ <0xfe100000 0x100000>,
+ <0xfe200000 0x200000>,
+ <0x30000000 0x8000000>,
+ <0x38000000 0x8000000>;
+ reg-names = "apb-base", "memory0", "memory1", "memory2", "memory3";
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&cpg 319>;
+ power-domains = <&sysc R8A774C0_PD_ALWAYS_ON>;
+ clocks = <&cpg CPG_MOD 319>;
+ clock-names = "pcie";
+ max-functions = /bits/ 8 <1>;
};
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
index 8fdfbc763d70..7896576920aa 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-pci-host.yaml
@@ -12,7 +12,7 @@ maintainers:
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
allOf:
- - $ref: pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -68,6 +68,18 @@ properties:
phy-names:
const: pcie
+ vpcie1v5-supply:
+ description: The 1.5v regulator to use for PCIe.
+
+ vpcie3v3-supply:
+ description: The 3.3v regulator to use for PCIe.
+
+ vpcie12v-supply:
+ description: The 12v regulator to use for PCIe.
+
+ iommu-map: true
+ iommu-map-mask: true
+
required:
- compatible
- reg
@@ -101,25 +113,27 @@ examples:
pcie: pcie@fe000000 {
compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2";
reg = <0 0xfe000000 0 0x80000>;
- #address-cells = <3>;
- #size-cells = <2>;
- bus-range = <0x00 0xff>;
- device_type = "pci";
- ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000>,
- <0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000>,
- <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>,
- <0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
- dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>,
- <0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
- interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>;
- clock-names = "pcie", "pcie_bus";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
- resets = <&cpg 319>;
- };
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000>,
+ <0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000>,
+ <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>,
+ <0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+ dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>,
+ <0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 319>, <&pcie_bus_clk>;
+ clock-names = "pcie", "pcie_bus";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 319>;
+ vpcie3v3-supply = <&pcie_3v3>;
+ vpcie12v-supply = <&pcie_12v>;
+ };
};
diff --git a/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml b/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml
index 0f18cceba3d5..065b7508d288 100644
--- a/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml
+++ b/Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml
@@ -42,9 +42,13 @@ properties:
interrupts:
maxItems: 1
- clocks: true
+ clocks:
+ minItems: 1
+ maxItems: 3
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 3
resets:
maxItems: 1
@@ -65,7 +69,7 @@ properties:
maxItems: 1
patternProperties:
- 'usb@[0-1],0':
+ '^usb@[0-1],0$':
type: object
description:
@@ -110,7 +114,7 @@ required:
- "#interrupt-cells"
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
- if:
properties:
diff --git a/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml b/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml
new file mode 100644
index 000000000000..d668782546a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml
@@ -0,0 +1,249 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/renesas,r9a08g045-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G3S PCIe host controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+
+description:
+ Renesas RZ/G3S PCIe host controller complies with PCIe Base Specification
+ 4.0 and supports up to 5 GT/s (Gen2).
+
+properties:
+ compatible:
+ const: renesas,r9a08g045-pcie # RZ/G3S
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: System error interrupt
+ - description: System error on correctable error interrupt
+ - description: System error on non-fatal error interrupt
+ - description: System error on fatal error interrupt
+ - description: AXI error interrupt
+ - description: INTA interrupt
+ - description: INTB interrupt
+ - description: INTC interrupt
+ - description: INTD interrupt
+ - description: MSI interrupt
+ - description: Link bandwidth interrupt
+ - description: PME interrupt
+ - description: DMA interrupt
+ - description: PCIe event interrupt
+ - description: Message interrupt
+ - description: All interrupts
+
+ interrupt-names:
+ items:
+ - description: serr
+ - description: ser_cor
+ - description: serr_nonfatal
+ - description: serr_fatal
+ - description: axi_err
+ - description: inta
+ - description: intb
+ - description: intc
+ - description: intd
+ - description: msi
+ - description: link_bandwidth
+ - description: pm_pme
+ - description: dma
+ - description: pcie_evt
+ - description: msg
+ - description: all
+
+ interrupt-controller: true
+
+ clocks:
+ items:
+ - description: System clock
+ - description: PM control clock
+
+ clock-names:
+ items:
+ - description: aclk
+ - description: pm
+
+ resets:
+ items:
+ - description: AXI2PCIe Bridge reset
+ - description: Data link layer/transaction layer reset
+ - description: Transaction layer (ACLK domain) reset
+ - description: Transaction layer (PCLK domain) reset
+ - description: Physical layer reset
+ - description: Configuration register reset
+ - description: Configuration register reset
+
+ reset-names:
+ items:
+ - description: aresetn
+ - description: rst_b
+ - description: rst_gp_b
+ - description: rst_ps_b
+ - description: rst_rsm_b
+ - description: rst_cfg_b
+ - description: rst_load_b
+
+ power-domains:
+ maxItems: 1
+
+ dma-ranges:
+ description:
+ A single range for the inbound memory region.
+ maxItems: 1
+
+ renesas,sysc:
+ description: |
+ System controller registers control and monitor various PCIe
+ functionalities.
+
+ Control:
+ - transition to L1 state
+ - receiver termination settings
+ - RST_RSM_B signal
+
+ Monitor:
+ - clkl1pm clock request state
+ - power off information in L2 state
+ - errors (fatal, non-fatal, correctable)
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+patternProperties:
+ "^pcie@0,[0-0]$":
+ type: object
+ allOf:
+ - $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ vendor-id:
+ const: 0x1912
+
+ device-id:
+ const: 0x0033
+
+ clocks:
+ items:
+ - description: Reference clock
+
+ clock-names:
+ items:
+ - const: ref
+
+ required:
+ - device_type
+ - vendor-id
+ - device-id
+ - clocks
+ - clock-names
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - interrupts
+ - interrupt-names
+ - interrupt-map
+ - interrupt-map-mask
+ - interrupt-controller
+ - power-domains
+ - "#address-cells"
+ - "#size-cells"
+ - "#interrupt-cells"
+ - renesas,sysc
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a08g045-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@11e40000 {
+ compatible = "renesas,r9a08g045-pcie";
+ reg = <0 0x11e40000 0 0x10000>;
+ ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>;
+ /* Map all possible DRAM ranges (4 GB). */
+ dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 1 0x00000000>;
+ bus-range = <0x0 0xff>;
+ interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "serr", "serr_cor", "serr_nonfatal",
+ "serr_fatal", "axi_err", "inta",
+ "intb", "intc", "intd", "msi",
+ "link_bandwidth", "pm_pme", "dma",
+ "pcie_evt", "msg", "all";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie 0 0 0 0>, /* INTA */
+ <0 0 0 2 &pcie 0 0 0 1>, /* INTB */
+ <0 0 0 3 &pcie 0 0 0 2>, /* INTC */
+ <0 0 0 4 &pcie 0 0 0 3>; /* INTD */
+ clocks = <&cpg CPG_MOD R9A08G045_PCI_ACLK>,
+ <&cpg CPG_MOD R9A08G045_PCI_CLKL1PM>;
+ clock-names = "aclk", "pm";
+ resets = <&cpg R9A08G045_PCI_ARESETN>,
+ <&cpg R9A08G045_PCI_RST_B>,
+ <&cpg R9A08G045_PCI_RST_GP_B>,
+ <&cpg R9A08G045_PCI_RST_PS_B>,
+ <&cpg R9A08G045_PCI_RST_RSM_B>,
+ <&cpg R9A08G045_PCI_RST_CFG_B>,
+ <&cpg R9A08G045_PCI_RST_LOAD_B>;
+ reset-names = "aresetn", "rst_b", "rst_gp_b", "rst_ps_b",
+ "rst_rsm_b", "rst_cfg_b", "rst_load_b";
+ power-domains = <&cpg>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ renesas,sysc = <&sysc>;
+
+ pcie@0,0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ ranges;
+ clocks = <&versa3 5>;
+ clock-names = "ref";
+ device_type = "pci";
+ vendor-id = <0x1912>;
+ device-id = <0x0033>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml
new file mode 100644
index 000000000000..a8574f8a84a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-common.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip,rk3399-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip AXI PCIe Bridge Common Properties
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+properties:
+ reg:
+ maxItems: 2
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: aclk-perf
+ - const: hclk
+ - const: pm
+
+ num-lanes:
+ maximum: 4
+
+ phys:
+ oneOf:
+ - maxItems: 1
+ - maxItems: 4
+
+ phy-names:
+ oneOf:
+ - const: pcie-phy
+ - items:
+ - const: pcie-phy-0
+ - const: pcie-phy-1
+ - const: pcie-phy-2
+ - const: pcie-phy-3
+
+ resets:
+ maxItems: 7
+
+ reset-names:
+ items:
+ - const: core
+ - const: mgmt
+ - const: mgmt-sticky
+ - const: pipe
+ - const: pm
+ - const: pclk
+ - const: aclk
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - phys
+ - phy-names
+ - resets
+ - reset-names
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
new file mode 100644
index 000000000000..6b62f6f58efe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie-ep.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip,rk3399-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip AXI PCIe Endpoint
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-ep.yaml#
+ - $ref: rockchip,rk3399-pcie-common.yaml#
+
+properties:
+ compatible:
+ const: rockchip,rk3399-pcie-ep
+
+ reg: true
+
+ reg-names:
+ items:
+ - const: apb-base
+ - const: mem-base
+
+ rockchip,max-outbound-regions:
+ description: Maximum number of outbound regions
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 32
+ default: 32
+
+required:
+ - rockchip,max-outbound-regions
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/rk3399-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie-ep@f8000000 {
+ compatible = "rockchip,rk3399-pcie-ep";
+ reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0xfa000000 0x0 0x2000000>;
+ reg-names = "apb-base", "mem-base";
+ clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
+ <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
+ clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+ max-functions = /bits/ 8 <8>;
+ num-lanes = <4>;
+ resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
+ <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
+ <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
+ reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+ "pm", "pclk", "aclk";
+ phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
+ phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
+ rockchip,max-outbound-regions = <16>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreqnb_cpm>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
new file mode 100644
index 000000000000..720a5f945a4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip,rk3399-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip AXI PCIe Root Port Bridge Host
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: rockchip,rk3399-pcie-common.yaml#
+
+properties:
+ compatible:
+ const: rockchip,rk3399-pcie
+
+ reg: true
+
+ reg-names:
+ items:
+ - const: axi-base
+ - const: apb-base
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: sys
+ - const: legacy
+ - const: client
+
+ aspm-no-l0s:
+ description: This property is needed if using 24MHz OSC for RC's PHY.
+
+ ep-gpios:
+ maxItems: 1
+ description: pre-reset GPIO
+
+ vpcie12v-supply:
+ description: The 12v regulator to use for PCIe.
+
+ vpcie3v3-supply:
+ description: The 3.3v regulator to use for PCIe.
+
+ vpcie1v8-supply:
+ description: The 1.8v regulator to use for PCIe.
+
+ vpcie0v9-supply:
+ description: The 0.9v regulator to use for PCIe.
+
+ interrupt-controller:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 0
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupt-controller: true
+
+required:
+ - ranges
+ - "#interrupt-cells"
+ - interrupts
+ - interrupt-controller
+ - interrupt-map
+ - interrupt-map-mask
+ - msi-map
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/rk3399-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@f8000000 {
+ compatible = "rockchip,rk3399-pcie";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
+ <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
+ clock-names = "aclk", "aclk-perf",
+ "hclk", "pm";
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "sys", "legacy", "client";
+ ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
+ 0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
+ num-lanes = <4>;
+ msi-map = <0x0 &its 0x0 0x1000>;
+ reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
+ reg-names = "axi-base", "apb-base";
+ resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
+ <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
+ <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
+ reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+ "pm", "pclk", "aclk";
+ /* deprecated legacy PHY model */
+ phys = <&pcie_phy>;
+ phy-names = "pcie-phy";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreq>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie0_intc 0>,
+ <0 0 0 2 &pcie0_intc 1>,
+ <0 0 0 3 &pcie0_intc 2>,
+ <0 0 0 4 &pcie0_intc 3>;
+
+ pcie0_intc: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml
new file mode 100644
index 000000000000..fde9b87508b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-common.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip-dw-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DesignWare based PCIe RC/EP controller on Rockchip SoCs
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+ - Simon Xue <xxm@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+description: |+
+ Generic properties for the DesignWare based PCIe RC/EP controller on Rockchip
+ SoCs.
+
+properties:
+ clocks:
+ minItems: 5
+ items:
+ - description: AHB clock for PCIe master
+ - description: AHB clock for PCIe slave
+ - description: AHB clock for PCIe dbi
+ - description: APB clock for PCIe
+ - description: Auxiliary clock for PCIe
+ - description: PIPE clock
+ - description: Reference clock for PCIe
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: aclk_mst
+ - const: aclk_slv
+ - const: aclk_dbi
+ - const: pclk
+ - const: aux
+ - const: pipe
+ - const: ref
+
+ interrupts:
+ minItems: 5
+ items:
+ - description:
+ Combined system interrupt, which is used to signal the following
+ interrupts - phy_link_up, dll_link_up, link_req_rst_not, hp_pme,
+ hp, hp_msi, link_auto_bw, link_auto_bw_msi, bw_mgt, bw_mgt_msi,
+ edma_wr, edma_rd, dpa_sub_upd, rbar_update, link_eq_req, ep_elbi_app
+ - description:
+ Combined PM interrupt, which is used to signal the following
+ interrupts - linkst_in_l1sub, linkst_in_l1, linkst_in_l2,
+ linkst_in_l0s, linkst_out_l1sub, linkst_out_l1, linkst_out_l2,
+ linkst_out_l0s, pm_dstate_update
+ - description:
+ Combined message interrupt, which is used to signal the following
+ interrupts - ven_msg, unlock_msg, ltr_msg, cfg_pme, cfg_pme_msi,
+ pm_pme, pm_to_ack, pm_turnoff, obff_idle, obff_obff, obff_cpu_active
+ - description:
+ Combined legacy interrupt, which is used to signal the following
+ interrupts - inta, intb, intc, intd, tx_inta, tx_intb, tx_intc,
+ tx_intd
+ - description:
+ Combined error interrupt, which is used to signal the following
+ interrupts - aer_rc_err, aer_rc_err_msi, rx_cpl_timeout,
+ tx_cpl_timeout, cor_err_sent, nf_err_sent, f_err_sent, cor_err_rx,
+ nf_err_rx, f_err_rx, radm_qoverflow
+ - description:
+ If the matching interrupt name is "msi", then this is the combined
+ MSI line interrupt, which is to support MSI interrupts output to GIC
+ controller via GIC SPI interrupt instead of GIC ITS interrupt.
+ If the matching interrupt name is "dma0", then this is the eDMA write
+ channel 0 interrupt.
+ - description:
+ eDMA write channel 1 interrupt
+ - description:
+ eDMA read channel 0 interrupt
+ - description:
+ eDMA read channel 1 interrupt
+
+ interrupt-names:
+ minItems: 5
+ items:
+ - const: sys
+ - const: pmc
+ - const: msg
+ - const: legacy
+ - const: err
+ - enum:
+ - msi
+ - dma0
+ - const: dma1
+ - const: dma2
+ - const: dma3
+
+ num-lanes: true
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: pcie-phy
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ oneOf:
+ - const: pipe
+ - items:
+ - const: pwr
+ - const: pipe
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - num-lanes
+ - phys
+ - phy-names
+ - power-domains
+ - resets
+ - reset-names
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-ep.yaml
new file mode 100644
index 000000000000..f2d1137aff50
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie-ep.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rockchip-dw-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DesignWare based PCIe Endpoint controller on Rockchip SoCs
+
+maintainers:
+ - Niklas Cassel <cassel@kernel.org>
+
+description: |+
+ RK3588 SoC PCIe Endpoint controller is based on the Synopsys DesignWare
+ PCIe IP and thus inherits all the common properties defined in
+ snps,dw-pcie-ep.yaml.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
+ - $ref: /schemas/pci/rockchip-dw-pcie-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3568-pcie-ep
+ - rockchip,rk3588-pcie-ep
+
+ reg:
+ items:
+ - description: Data Bus Interface (DBI) registers
+ - description: Data Bus Interface (DBI) shadow registers
+ - description: Rockchip designed configuration registers
+ - description: Memory region used to map remote RC address space
+ - description: Internal Address Translation Unit (iATU) registers
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: apb
+ - const: addr_space
+ - const: atu
+
+required:
+ - interrupts
+ - interrupt-names
+
+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>;
+
+ pcie3x4_ep: pcie-ep@fe150000 {
+ compatible = "rockchip,rk3588-pcie-ep";
+ reg = <0xa 0x40000000 0x0 0x00100000>,
+ <0xa 0x40100000 0x0 0x00100000>,
+ <0x0 0xfe150000 0x0 0x00010000>,
+ <0x9 0x00000000 0x0 0x40000000>,
+ <0xa 0x40300000 0x0 0x00100000>;
+ reg-names = "dbi", "dbi2", "apb", "addr_space", "atu";
+ clocks = <&cru ACLK_PCIE_4L_MSTR>, <&cru ACLK_PCIE_4L_SLV>,
+ <&cru ACLK_PCIE_4L_DBI>, <&cru PCLK_PCIE_4L>,
+ <&cru CLK_PCIE_AUX0>, <&cru CLK_PCIE4L_PIPE>;
+ clock-names = "aclk_mst", "aclk_slv",
+ "aclk_dbi", "pclk",
+ "aux", "pipe";
+ interrupts = <GIC_SPI 263 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 259 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "sys", "pmc", "msg", "legacy", "err",
+ "dma0", "dma1", "dma2", "dma3";
+ max-link-speed = <3>;
+ num-lanes = <4>;
+ phys = <&pcie30phy>;
+ phy-names = "pcie-phy";
+ power-domains = <&power RK3588_PD_PCIE>;
+ resets = <&cru SRST_PCIE0_POWER_UP>, <&cru SRST_P_PCIE0>;
+ reset-names = "pwr", "pipe";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
index bc0a9d1db750..355c4a46bd31 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pci/rockchip-dw-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DesignWare based PCIe controller on Rockchip SoCs
+title: DesignWare based PCIe Root Complex controller on Rockchip SoCs
maintainers:
- Shawn Lin <shawn.lin@rock-chips.com>
@@ -12,17 +12,21 @@ maintainers:
- Heiko Stuebner <heiko@sntech.de>
description: |+
- RK3568 SoC PCIe host controller is based on the Synopsys DesignWare
+ RK3568 SoC PCIe Root Complex controller is based on the Synopsys DesignWare
PCIe IP and thus inherits all the common properties defined in
- designware-pcie.txt.
-
-allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ snps,dw-pcie.yaml.
properties:
compatible:
- items:
+ oneOf:
- const: rockchip,rk3568-pcie
+ - items:
+ - enum:
+ - rockchip,rk3528-pcie
+ - rockchip,rk3562-pcie
+ - rockchip,rk3576-pcie
+ - rockchip,rk3588-pcie
+ - const: rockchip,rk3568-pcie
reg:
items:
@@ -36,64 +40,95 @@ properties:
- const: apb
- const: config
- clocks:
- items:
- - description: AHB clock for PCIe master
- - description: AHB clock for PCIe slave
- - description: AHB clock for PCIe dbi
- - description: APB clock for PCIe
- - description: Auxiliary clock for PCIe
+ legacy-interrupt-controller:
+ description: Interrupt controller node for handling legacy PCI interrupts.
+ type: object
+ additionalProperties: false
+ properties:
+ "#address-cells":
+ const: 0
- clock-names:
- items:
- - const: aclk_mst
- - const: aclk_slv
- - const: aclk_dbi
- - const: pclk
- - const: aux
-
- msi-map: true
+ "#interrupt-cells":
+ const: 1
- num-lanes: true
+ interrupt-controller: true
- phys:
- maxItems: 1
+ interrupts:
+ items:
+ - description: combined legacy interrupt
+ required:
+ - "#address-cells"
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupts
- phy-names:
- const: pcie-phy
-
- power-domains:
- maxItems: 1
+ msi-map: true
ranges:
- maxItems: 2
-
- resets:
- maxItems: 1
-
- reset-names:
- const: pipe
+ minItems: 2
+ maxItems: 3
vpcie3v3-supply: true
-required:
- - compatible
- - reg
- - reg-names
- - clocks
- - clock-names
- - msi-map
- - num-lanes
- - phys
- - phy-names
- - power-domains
- - resets
- - reset-names
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+ - $ref: /schemas/pci/rockchip-dw-pcie-common.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3528-pcie
+ - rockchip,rk3562-pcie
+ - rockchip,rk3576-pcie
+ then:
+ required:
+ - msi-map
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3528-pcie
+ - rockchip,rk3562-pcie
+ - rockchip,rk3576-pcie
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ maxItems: 6
+ interrupt-names:
+ items:
+ - const: sys
+ - const: pmc
+ - const: msg
+ - const: legacy
+ - const: err
+ - const: msi
+ else:
+ properties:
+ interrupts:
+ minItems: 5
+ interrupt-names:
+ minItems: 5
+ items:
+ - const: sys
+ - const: pmc
+ - const: msg
+ - const: legacy
+ - const: err
+ - const: dma0
+ - const: dma1
+ - const: dma2
+ - const: dma3
unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
bus {
#address-cells = <2>;
@@ -113,6 +148,12 @@ examples:
"aclk_dbi", "pclk",
"aux";
device_type = "pci";
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "sys", "pmc", "msg", "legacy", "err";
linux,pci-domain = <2>;
max-link-speed = <2>;
msi-map = <0x2000 &its 0x2000 0x1000>;
@@ -126,6 +167,14 @@ examples:
reset-names = "pipe";
#address-cells = <3>;
#size-cells = <2>;
+
+ legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt
deleted file mode 100644
index 778467307a93..000000000000
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie-ep.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* Rockchip AXI PCIe Endpoint Controller DT description
-
-Required properties:
-- compatible: Should contain "rockchip,rk3399-pcie-ep"
-- reg: Two register ranges as listed in the reg-names property
-- reg-names: Must include the following names
- - "apb-base"
- - "mem-base"
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - "aclk"
- - "aclk-perf"
- - "hclk"
- - "pm"
-- resets: Must contain seven entries for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following names
- - "core"
- - "mgmt"
- - "mgmt-sticky"
- - "pipe"
- - "pm"
- - "aclk"
- - "pclk"
-- pinctrl-names : The pin control state names
-- pinctrl-0: The "default" pinctrl state
-- phys: Must contain an phandle to a PHY for each entry in phy-names.
-- phy-names: Must include 4 entries for all 4 lanes even if some of
- them won't be used for your cases. Entries are of the form "pcie-phy-N":
- where N ranges from 0 to 3.
- (see example below and you MUST also refer to ../phy/rockchip-pcie-phy.txt
- for changing the #phy-cells of phy node to support it)
-- rockchip,max-outbound-regions: Maximum number of outbound regions
-
-Optional Property:
-- num-lanes: number of lanes to use
-- max-functions: Maximum number of functions that can be configured (default 1).
-
-pcie0-ep: pcie@f8000000 {
- compatible = "rockchip,rk3399-pcie-ep";
- #address-cells = <3>;
- #size-cells = <2>;
- rockchip,max-outbound-regions = <16>;
- clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
- <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
- clock-names = "aclk", "aclk-perf",
- "hclk", "pm";
- max-functions = /bits/ 8 <8>;
- num-lanes = <4>;
- reg = <0x0 0xfd000000 0x0 0x1000000>, <0x0 0x80000000 0x0 0x20000>;
- reg-names = "apb-base", "mem-base";
- resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
- <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
- <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
- reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
- "pm", "pclk", "aclk";
- phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
- phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
- pinctrl-names = "default";
- pinctrl-0 = <&pcie_clkreq>;
-};
diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt
deleted file mode 100644
index af34c65773fd..000000000000
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie-host.txt
+++ /dev/null
@@ -1,135 +0,0 @@
-* Rockchip AXI PCIe Root Port Bridge DT description
-
-Required properties:
-- #address-cells: Address representation for root ports, set to <3>
-- #size-cells: Size representation for root ports, set to <2>
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- compatible: Should contain "rockchip,rk3399-pcie"
-- reg: Two register ranges as listed in the reg-names property
-- reg-names: Must include the following names
- - "axi-base"
- - "apb-base"
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - "aclk"
- - "aclk-perf"
- - "hclk"
- - "pm"
-- msi-map: Maps a Requester ID to an MSI controller and associated
- msi-specifier data. See ./pci-msi.txt
-- interrupts: Three interrupt entries must be specified.
-- interrupt-names: Must include the following names
- - "sys"
- - "legacy"
- - "client"
-- resets: Must contain seven entries for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following names
- - "core"
- - "mgmt"
- - "mgmt-sticky"
- - "pipe"
- - "pm"
- - "aclk"
- - "pclk"
-- pinctrl-names : The pin control state names
-- pinctrl-0: The "default" pinctrl state
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- interrupt-map-mask and interrupt-map: standard PCI properties
-
-Required properties for legacy PHY model (deprecated):
-- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
-- phy-names: MUST be "pcie-phy".
-
-Required properties for per-lane PHY model (preferred):
-- phys: Must contain an phandle to a PHY for each entry in phy-names.
-- phy-names: Must include 4 entries for all 4 lanes even if some of
- them won't be used for your cases. Entries are of the form "pcie-phy-N":
- where N ranges from 0 to 3.
- (see example below and you MUST also refer to ../phy/rockchip-pcie-phy.txt
- for changing the #phy-cells of phy node to support it)
-
-Optional Property:
-- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if
- using 24MHz OSC for RC's PHY.
-- ep-gpios: contain the entry for pre-reset GPIO
-- num-lanes: number of lanes to use
-- vpcie12v-supply: The phandle to the 12v regulator to use for PCIe.
-- vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe.
-- vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe.
-- vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe.
-
-*Interrupt controller child node*
-The core controller provides a single interrupt for legacy INTx. The PCIe node
-should contain an interrupt controller node as a target for the PCI
-'interrupt-map' property. This node represents the domain at which the four
-INTx interrupts are decoded and routed.
-
-
-Required properties for Interrupt controller child node:
-- interrupt-controller: identifies the node as an interrupt controller
-- #address-cells: specifies the number of cells needed to encode an
- address. The value must be 0.
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-
-Example:
-
-pcie0: pcie@f8000000 {
- compatible = "rockchip,rk3399-pcie";
- #address-cells = <3>;
- #size-cells = <2>;
- clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
- <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
- clock-names = "aclk", "aclk-perf",
- "hclk", "pm";
- bus-range = <0x0 0x1>;
- interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "sys", "legacy", "client";
- assigned-clocks = <&cru SCLK_PCIEPHY_REF>;
- assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>;
- assigned-clock-rates = <100000000>;
- ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
- ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
- 0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
- num-lanes = <4>;
- msi-map = <0x0 &its 0x0 0x1000>;
- reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>;
- reg-names = "axi-base", "apb-base";
- resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
- <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE> ,
- <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>, <&cru SRST_A_PCIE>;
- reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
- "pm", "pclk", "aclk";
- /* deprecated legacy PHY model */
- phys = <&pcie_phy>;
- phy-names = "pcie-phy";
- pinctrl-names = "default";
- pinctrl-0 = <&pcie_clkreq>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie0_intc 0>,
- <0 0 0 2 &pcie0_intc 1>,
- <0 0 0 3 &pcie0_intc 2>,
- <0 0 0 4 &pcie0_intc 3>;
- pcie0_intc: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
-};
-
-pcie0: pcie@f8000000 {
- ...
-
- /* preferred per-lane PHY model */
- phys = <&pcie_phy 0>, <&pcie_phy 1>, <&pcie_phy 2>, <&pcie_phy 3>;
- phy-names = "pcie-phy-0", "pcie-phy-1", "pcie-phy-2", "pcie-phy-3";
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
index 445eed94b53f..f20ed7e709f7 100644
--- a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pci/samsung,exynos-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Samsung SoC series PCIe Host Controller Device Tree Bindings
+title: Samsung SoC series PCIe Host Controller
maintainers:
- Marek Szyprowski <m.szyprowski@samsung.com>
diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
index 195e6afeb169..d35ff807936b 100644
--- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
@@ -51,6 +51,12 @@ properties:
description: A phandle to the PCIe power up reset line.
maxItems: 1
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: pcie_aux
+
pwren-gpios:
description: Should specify the GPIO for controlling the PCI bus device power on.
maxItems: 1
@@ -66,6 +72,7 @@ required:
- interrupt-map-mask
- interrupt-map
- clocks
+ - clock-names
- resets
- pwren-gpios
- reset-gpios
@@ -74,10 +81,10 @@ unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/sifive-fu740-prci.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
- #include <dt-bindings/clock/sifive-fu740-prci.h>
pcie@e00000000 {
compatible = "sifive,fu740-pcie";
@@ -104,6 +111,7 @@ examples:
<0x0 0x0 0x0 0x2 &plic0 58>,
<0x0 0x0 0x0 0x3 &plic0 59>,
<0x0 0x0 0x0 0x4 &plic0 60>;
+ clock-names = "pcie_aux";
clocks = <&prci FU740_PRCI_CLK_PCIE_AUX>;
resets = <&prci 4>;
pwren-gpios = <&gpio 5 0>;
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
new file mode 100644
index 000000000000..6339a76499b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
@@ -0,0 +1,267 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/snps,dw-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DWC PCIe RP/EP controller
+
+maintainers:
+ - Jingoo Han <jingoohan1@gmail.com>
+ - Gustavo Pimentel <gustavo.pimentel@synopsys.com>
+
+description:
+ Generic Synopsys DesignWare PCIe Root Port and Endpoint controller
+ properties.
+
+select: false
+
+properties:
+ reg:
+ description:
+ DWC PCIe CSR space is normally accessed over the dedicated Data Bus
+ Interface - DBI. In accordance with the reference manual the register
+ configuration space belongs to the Configuration-Dependent Module (CDM)
+ and is split up into several sub-parts Standard PCIe configuration
+ space, Port Logic Registers (PL), Shadow Config-space Registers,
+ iATU/eDMA registers. The particular sub-space is selected by the
+ CDM/ELBI (dbi_cs) and CS2 (dbi_cs2) signals (selector bits). Such
+ configuration provides a flexible interface for the system engineers to
+ either map the particular space at a desired MMIO address or just leave
+ them in a contiguous memory space if pure Native or AXI Bridge DBI access
+ is selected. Note the PCIe CFG-space, PL and Shadow registers are
+ specific for each activated function, while the rest of the sub-spaces
+ are common for all of them (if there are more than one).
+ minItems: 2
+ maxItems: 7
+
+ reg-names:
+ minItems: 2
+ maxItems: 7
+
+ interrupts:
+ description:
+ There are two main sub-blocks which are normally capable of
+ generating interrupts. It's System Information Interface and MSI
+ interface. While the former one has some common for the Host and
+ Endpoint controllers IRQ-signals, the later interface is obviously
+ Root Complex specific since it's responsible for the incoming MSI
+ messages signalling. The System Information IRQ signals are mainly
+ responsible for reporting the generic PCIe hierarchy and Root
+ Complex events like VPD IO request, general AER, PME, Hot-plug, link
+ bandwidth change, link equalization request, INTx asserted/deasserted
+ Message detection, embedded DMA Tx/Rx/Error.
+ minItems: 1
+ maxItems: 26
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 26
+
+ clocks:
+ description:
+ DWC PCIe reference manual explicitly defines a set of the clocks required
+ to get the controller working correctly. In general all of them can
+ be divided into two groups':' application and core clocks. Note the
+ platforms may have some of the clock sources unspecified in case if the
+ corresponding domains are fed up from a common clock source.
+ minItems: 1
+ maxItems: 7
+
+ clock-names:
+ minItems: 1
+ maxItems: 7
+ items:
+ oneOf:
+ - description:
+ Data Bus Interface (DBI) clock. Clock signal for the AXI-bus
+ interface of the Configuration-Dependent Module, which is
+ basically the set of the controller CSRs.
+ const: dbi
+ - description:
+ Application AXI-bus Master interface clock. Basically this is
+ a clock for the controller DMA interface (PCI-to-CPU).
+ const: mstr
+ - description:
+ Application AXI-bus Slave interface clock. This is a clock for
+ the CPU-to-PCI memory IO interface.
+ const: slv
+ - description:
+ Controller Core-PCS PIPE interface clock. It's normally
+ supplied by an external PCS-PHY.
+ const: pipe
+ - description:
+ Controller Primary clock. It's assumed that all controller input
+ signals (except resets) are synchronous to this clock.
+ const: core
+ - description:
+ Auxiliary clock for the controller PMC domain. The controller
+ partitioning implies having some parts to operate with this
+ clock in some power management states.
+ const: aux
+ - description:
+ Generic reference clock. In case if there are several
+ interfaces fed up with a common clock source it's advisable to
+ define it with this name (for instance pipe, core and aux can
+ be connected to a single source of the periodic signal).
+ const: ref
+ - description:
+ Clock for the PHY registers interface. Originally this is
+ a PHY-viewport-based interface, but some platform may have
+ specifically designed one.
+ const: phy_reg
+ - description:
+ Vendor-specific clock names. Consider using the generic names
+ above for new bindings.
+ oneOf:
+ - description: See native 'dbi' clock for details
+ enum: [ pcie, pcie_apb_sys, aclk_dbi, reg, port ]
+ - description: See native 'mstr/slv' clock for details
+ enum: [ pcie_bus, pcie_inbound_axi, pcie_aclk, aclk_mst, aclk_slv ]
+ - description: See native 'pipe' clock for details
+ enum: [ pcie_phy, pcie_phy_ref, link, general ]
+ - description: See native 'aux' clock for details
+ enum: [ pcie_aux ]
+ - description: See native 'ref' clock for details.
+ enum: [ gio ]
+ - description: See nativs 'phy_reg' clock for details
+ enum: [ pcie_apb_phy, pclk ]
+
+ resets:
+ description:
+ DWC PCIe reference manual explicitly defines a set of the reset
+ signals required to be de-asserted to properly activate the controller
+ sub-parts. All of these signals can be divided into two sub-groups':'
+ application and core resets with respect to the main sub-domains they
+ are supposed to reset. Note the platforms may have some of these signals
+ unspecified in case if they are automatically handled or aggregated into
+ a comprehensive control module.
+ minItems: 1
+ maxItems: 10
+
+ reset-names:
+ minItems: 1
+ maxItems: 10
+ items:
+ oneOf:
+ - description: Data Bus Interface (DBI) domain reset
+ const: dbi
+ - description: AXI-bus Master interface reset
+ const: mstr
+ - description: AXI-bus Slave interface reset
+ const: slv
+ - description: Application-dependent interface reset
+ const: app
+ - description: Controller Non-sticky CSR flags reset
+ const: non-sticky
+ - description: Controller sticky CSR flags reset
+ const: sticky
+ - description: PIPE-interface (Core-PCS) logic reset
+ const: pipe
+ - description:
+ Controller primary reset (resets everything except PMC module)
+ const: core
+ - description: PCS/PHY block reset
+ const: phy
+ - description: PMC hot reset signal
+ const: hot
+ - description: Cold reset signal
+ const: pwr
+ - description:
+ Vendor-specific reset names. Consider using the generic names
+ above for new bindings.
+ oneOf:
+ - description: See native 'app' reset for details
+ enum: [ apps, gio, apb ]
+ - description: See native 'phy' reset for details
+ enum: [ pciephy, link ]
+ - description: See native 'pwr' reset for details
+ enum: [ turnoff, port ]
+
+ phys:
+ description:
+ There can be up to the number of possible lanes PHYs specified placed in
+ the phandle array in the line-based order. Obviously each the specified
+ PHYs are supposed to be able to work in the PCIe mode with a speed
+ implied by the DWC PCIe controller they are attached to.
+ minItems: 1
+ maxItems: 16
+
+ phy-names:
+ minItems: 1
+ maxItems: 16
+ oneOf:
+ - description: Generic PHY names
+ items:
+ pattern: '^pcie[0-9]+$'
+ - description:
+ Vendor-specific PHY names. Consider using the generic
+ names above for new bindings.
+ items:
+ oneOf:
+ - pattern: '^pcie(-?phy[0-9]*)?$'
+ - pattern: '^p2u-[0-7]$'
+ - pattern: '^cp[01]-pcie[0-2]-x[124](-lane[0-3])?-phy$' # marvell,armada8k-pcie
+
+ reset-gpio:
+ deprecated: true
+ description:
+ Reference to the GPIO-controlled PERST# signal. It is used to reset all
+ the peripheral devices available on the PCIe bus.
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ Reference to the GPIO-controlled PERST# signal. It is used to reset all
+ the peripheral devices available on the PCIe bus.
+ maxItems: 1
+
+ max-link-speed:
+ maximum: 5
+
+ num-lanes:
+ description:
+ Number of PCIe link lanes to use. Can be omitted if the already brought
+ up link is supposed to be preserved.
+ maximum: 16
+
+ num-ob-windows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Number of outbound address translation windows. This parameter can be
+ auto-detected based on the iATU memory writability. So there is no
+ point in having a dedicated DT-property for it.
+ maximum: 256
+
+ num-ib-windows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Number of inbound address translation windows. In the same way as
+ for the outbound AT windows, this parameter can be auto-detected based
+ on the iATU memory writability. There is no point having a dedicated
+ DT-property for it either.
+ maximum: 256
+
+ num-viewport:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description:
+ Number of outbound view ports configured in hardware. It's the same as
+ the number of outbound AT windows.
+ maximum: 256
+
+ snps,enable-cdm-check:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable automatic checking of CDM (Configuration Dependent Module)
+ registers for data corruption. CDM registers include standard PCIe
+ configuration space registers, Port Logic registers, DMA and iATU
+ registers. This feature has been available since DWC PCIe v4.80a.
+
+ dma-coherent: true
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
index b78535040f04..f474b9e3fc7e 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
@@ -13,76 +13,191 @@ maintainers:
description: |
Synopsys DesignWare PCIe host controller endpoint
+# Please create a separate DT-schema for your DWC PCIe Endpoint controller
+# and make sure it's assigned with the vendor-specific compatible string.
+select:
+ properties:
+ compatible:
+ const: snps,dw-pcie-ep
+ required:
+ - compatible
+
allOf:
- $ref: /schemas/pci/pci-ep.yaml#
+ - $ref: /schemas/pci/snps,dw-pcie-common.yaml#
properties:
- compatible:
- anyOf:
- - {}
- - const: snps,dw-pcie-ep
-
reg:
- description: |
- It should contain Data Bus Interface (dbi) and config registers for all
- versions.
- For designware core version >= 4.80, it may contain ATU address space.
+ description:
+ DBI, DBI2 reg-spaces and outbound memory window are required for the
+ normal controller functioning. iATU memory IO region is also required
+ if the space is unrolled (IP-core version >= 4.80a).
minItems: 2
- maxItems: 4
+ maxItems: 7
reg-names:
minItems: 2
- maxItems: 4
+ maxItems: 7
items:
- enum: [dbi, dbi2, config, atu, addr_space, link, atu_dma, appl]
-
- reset-gpio:
- description: GPIO pin number of PERST# signal
- maxItems: 1
- deprecated: true
-
- reset-gpios:
- description: GPIO controlled connection to PERST# signal
- maxItems: 1
-
- snps,enable-cdm-check:
- type: boolean
- description: |
- This is a boolean property and if present enables
- automatic checking of CDM (Configuration Dependent Module) registers
- for data corruption. CDM registers include standard PCIe configuration
- space registers, Port Logic registers, DMA and iATU (internal Address
- Translation Unit) registers.
-
- num-ib-windows:
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 256
- description: number of inbound address translation windows
- deprecated: true
-
- num-ob-windows:
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 256
- description: number of outbound address translation windows
- deprecated: true
+ oneOf:
+ - description:
+ Basic DWC PCIe controller configuration-space accessible over
+ the DBI interface. This memory space is either activated with
+ CDM/ELBI = 0 and CS2 = 0 or is a contiguous memory region
+ with all spaces. Note iATU/eDMA CSRs are indirectly accessible
+ via the PL viewports on the DWC PCIe controllers older than
+ v4.80a.
+ const: dbi
+ - description:
+ Shadow DWC PCIe config-space registers. This space is selected
+ by setting CDM/ELBI = 0 and CS2 = 1. This is an intermix of
+ the PCI-SIG PCIe CFG-space with the shadow registers for some
+ PCI Header space, PCI Standard and Extended Structures. It's
+ mainly relevant for the end-point controller configuration,
+ but still there are some shadow registers available for the
+ Root Port mode too.
+ const: dbi2
+ - description:
+ External Local Bus registers. It's an application-dependent
+ registers normally defined by the platform engineers. The space
+ can be selected by setting CDM/ELBI = 1 and CS2 = 0 wires or can
+ be accessed over some platform-specific means (for instance
+ as a part of a system controller).
+ enum: [ elbi, app ]
+ - description:
+ iATU/eDMA registers common for all device functions. It's an
+ unrolled memory space with the internal Address Translation
+ Unit and Enhanced DMA, which is selected by setting CDM/ELBI = 1
+ and CS2 = 1. For IP-core releases prior v4.80a, these registers
+ have been programmed via an indirect addressing scheme using a
+ set of viewport CSRs mapped into the PL space. Note iATU is
+ normally mapped to the 0x0 address of this region, while eDMA
+ is available at 0x80000 base address.
+ const: atu
+ - description:
+ Platform-specific eDMA registers. Some platforms may have eDMA
+ CSRs mapped in a non-standard base address. The registers offset
+ can be changed or the MS/LS-bits of the address can be attached
+ in an additional RTL block before the MEM-IO transactions reach
+ the DW PCIe slave interface.
+ const: dma
+ - description:
+ PHY/PCS configuration registers. Some platforms can have the
+ PCS and PHY CSRs accessible over a dedicated memory mapped
+ region, but mainly these registers are indirectly accessible
+ either by means of the embedded PHY viewport schema or by some
+ platform-specific method.
+ const: phy
+ - description:
+ Outbound iATU-capable memory-region which will be used to
+ generate various application-specific traffic on the PCIe bus
+ hierarchy. It's usage scenario depends on the endpoint
+ functionality, for instance it can be used to create MSI(X)
+ messages.
+ const: addr_space
+ - description:
+ Vendor-specific CSR names. Consider using the generic names above
+ for new bindings.
+ oneOf:
+ - description: See native 'elbi/app' CSR region for details.
+ enum: [ apb, link, appl ]
+ - description: See native 'atu' CSR region for details.
+ enum: [ atu_dma ]
+ allOf:
+ - contains:
+ const: dbi
+ - contains:
+ const: addr_space
+
+ interrupts:
+ description:
+ There is no mandatory IRQ signals for the normal controller functioning,
+ but in addition to the native set the platforms may have a link- or
+ PM-related IRQs specified.
+ minItems: 1
+ maxItems: 20
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 20
+ items:
+ oneOf:
+ - description:
+ Controller request to read or write virtual product data
+ from/to the VPD capability registers.
+ const: vpd
+ - description:
+ Link Equalization Request flag is set in the Link Status 2
+ register (applicable if the corresponding IRQ is enabled in
+ the Link Control 3 register).
+ const: l_eq
+ - description:
+ Indicates that the eDMA Tx/Rx transfer is complete or that an
+ error has occurred on the corresponding channel. eDMA can have
+ eight Tx (Write) and Rx (Read) eDMA channels thus supporting up
+ to 16 IRQ signals all together. Write eDMA channels shall go
+ first in the ordered row as per default edma_int[*] bus setup.
+ pattern: '^dma([0-9]|1[0-5])?$'
+ - description:
+ PCIe protocol correctable error or a Data Path protection
+ correctable error is detected by the automotive/safety
+ feature.
+ const: sft_ce
+ - description:
+ Indicates that the internal safety mechanism has detected an
+ uncorrectable error.
+ const: sft_ue
+ - description:
+ Application-specific IRQ raised depending on the vendor-specific
+ events basis.
+ const: app
+ - description:
+ Interrupts triggered when the controller itself (in Endpoint mode)
+ has sent an Assert_INT{A,B,C,D}/Desassert_INT{A,B,C,D} message to
+ the upstream device.
+ pattern: "^tx_int(a|b|c|d)$"
+ - description:
+ Combined interrupt signal raised when the controller has sent an
+ Assert_INT{A,B,C,D} message. See "^tx_int(a|b|c|d)$" for details.
+ const: legacy
+ - description:
+ Vendor-specific IRQ names. Consider using the generic names above
+ for new bindings.
+ oneOf:
+ - description: See native "app" IRQ for details
+ enum: [ intr, sys, pmc, msg, err ]
+
+ max-functions:
+ maximum: 32
required:
+ - compatible
- reg
- reg-names
- - compatible
additionalProperties: true
examples:
- |
- bus {
- #address-cells = <1>;
- #size-cells = <1>;
- pcie-ep@dfd00000 {
- compatible = "snps,dw-pcie-ep";
- reg = <0xdfc00000 0x0001000>, /* IP registers 1 */
- <0xdfc01000 0x0001000>, /* IP registers 2 */
- <0xd0000000 0x2000000>; /* Configuration space */
- reg-names = "dbi", "dbi2", "addr_space";
- };
+ pcie-ep@dfd00000 {
+ compatible = "snps,dw-pcie-ep";
+ reg = <0xdfc00000 0x0001000>, /* IP registers 1 */
+ <0xdfc01000 0x0001000>, /* IP registers 2 */
+ <0xd0000000 0x2000000>; /* Configuration space */
+ reg-names = "dbi", "dbi2", "addr_space";
+
+ interrupts = <23>, <24>;
+ interrupt-names = "dma0", "dma1";
+
+ clocks = <&sys_clk 12>, <&sys_clk 24>;
+ clock-names = "dbi", "ref";
+
+ resets = <&sys_rst 12>, <&sys_rst 24>;
+ reset-names = "dbi", "phy";
+
+ phys = <&pcie_phy0>, <&pcie_phy1>, <&pcie_phy2>, <&pcie_phy3>;
+ phy-names = "pcie0", "pcie1", "pcie2", "pcie3";
+
+ max-link-speed = <3>;
+ max-functions = /bits/ 8 <4>;
};
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
index 7287d395e1b6..b3216141881c 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
@@ -13,92 +13,233 @@ maintainers:
description: |
Synopsys DesignWare PCIe host controller
+# Please create a separate DT-schema for your DWC PCIe Root Port controller
+# and make sure it's assigned with the vendor-specific compatible string.
+select:
+ properties:
+ compatible:
+ const: snps,dw-pcie
+ required:
+ - compatible
+
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: /schemas/pci/snps,dw-pcie-common.yaml#
+ - if:
+ not:
+ required:
+ - msi-map
+ then:
+ properties:
+ interrupt-names:
+ contains:
+ const: msi
properties:
- compatible:
- anyOf:
- - {}
- - const: snps,dw-pcie
-
reg:
- description: |
- It should contain Data Bus Interface (dbi) and config registers for all
- versions.
- For designware core version >= 4.80, it may contain ATU address space.
+ description:
+ At least DBI reg-space and peripheral devices CFG-space outbound window
+ are required for the normal controller work. iATU memory IO region is
+ also required if the space is unrolled (IP-core version >= 4.80a).
minItems: 2
- maxItems: 5
+ maxItems: 7
reg-names:
minItems: 2
- maxItems: 5
+ maxItems: 7
+ items:
+ oneOf:
+ - description:
+ Basic DWC PCIe controller configuration-space accessible over
+ the DBI interface. This memory space is either activated with
+ CDM/ELBI = 0 and CS2 = 0 or is a contiguous memory region
+ with all spaces. Note iATU/eDMA CSRs are indirectly accessible
+ via the PL viewports on the DWC PCIe controllers older than
+ v4.80a.
+ const: dbi
+ - description:
+ Shadow DWC PCIe config-space registers. This space is selected
+ by setting CDM/ELBI = 0 and CS2 = 1. This is an intermix of
+ the PCI-SIG PCIe CFG-space with the shadow registers for some
+ PCI Header space, PCI Standard and Extended Structures. It's
+ mainly relevant for the end-point controller configuration,
+ but still there are some shadow registers available for the
+ Root Port mode too.
+ const: dbi2
+ - description:
+ External Local Bus registers. It's an application-dependent
+ registers normally defined by the platform engineers. The space
+ can be selected by setting CDM/ELBI = 1 and CS2 = 0 wires or can
+ be accessed over some platform-specific means (for instance
+ as a part of a system controller).
+ enum: [ elbi, app ]
+ - description:
+ iATU/eDMA registers common for all device functions. It's an
+ unrolled memory space with the internal Address Translation
+ Unit and Enhanced DMA, which is selected by setting CDM/ELBI = 1
+ and CS2 = 1. For IP-core releases prior v4.80a, these registers
+ have been programmed via an indirect addressing scheme using a
+ set of viewport CSRs mapped into the PL space. Note iATU is
+ normally mapped to the 0x0 address of this region, while eDMA
+ is available at 0x80000 base address.
+ const: atu
+ - description:
+ Platform-specific eDMA registers. Some platforms may have eDMA
+ CSRs mapped in a non-standard base address. The registers offset
+ can be changed or the MS/LS-bits of the address can be attached
+ in an additional RTL block before the MEM-IO transactions reach
+ the DW PCIe slave interface.
+ const: dma
+ - description:
+ PHY/PCS configuration registers. Some platforms can have the
+ PCS and PHY CSRs accessible over a dedicated memory mapped
+ region, but mainly these registers are indirectly accessible
+ either by means of the embedded PHY viewport schema or by some
+ platform-specific method.
+ const: phy
+ - description:
+ Outbound iATU-capable memory-region which will be used to access
+ the peripheral PCIe devices configuration space.
+ const: config
+ - description:
+ Vendor-specific CSR names. Consider using the generic names above
+ for new bindings.
+ oneOf:
+ - description: See native 'dbi' CSR region for details.
+ enum: [ ctrl ]
+ - description: See native 'elbi/app' CSR region for details.
+ enum: [ apb, mgmt, link, ulreg, appl, controller ]
+ - description: See native 'atu' CSR region for details.
+ enum: [ atu_dma ]
+ - description: Syscon-related CSR regions.
+ enum: [ smu, mpu ]
+ - description: Tegra234 aperture
+ enum: [ ecam ]
+ - description: AMD MDB PCIe SLCR region
+ const: slcr
+ allOf:
+ - contains:
+ enum: [ dbi, ctrl ]
+ - contains:
+ const: config
+
+ interrupts:
+ description:
+ DWC PCIe Root Port/Complex specific IRQ signals. At least MSI interrupt
+ signal is supposed to be specified for the host controller.
+ minItems: 1
+ maxItems: 26
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 26
items:
- enum: [ dbi, dbi2, config, atu, atu_dma, app, appl, elbi, mgmt, ctrl,
- parf, cfg, link, ulreg, smu, mpu, apb, phy ]
-
- num-lanes:
- description: |
- number of lanes to use (this property should be specified unless
- the link is brought already up in firmware)
- maximum: 16
-
- reset-gpio:
- description: GPIO pin number of PERST# signal
- maxItems: 1
- deprecated: true
-
- reset-gpios:
- description: GPIO controlled connection to PERST# signal
- maxItems: 1
-
- interrupts: true
-
- interrupt-names: true
-
- clocks: true
-
- snps,enable-cdm-check:
- type: boolean
- description: |
- This is a boolean property and if present enables
- automatic checking of CDM (Configuration Dependent Module) registers
- for data corruption. CDM registers include standard PCIe configuration
- space registers, Port Logic registers, DMA and iATU (internal Address
- Translation Unit) registers.
-
- num-viewport:
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 256
- description: |
- number of view ports configured in hardware. If a platform
- does not specify it, the driver autodetects it.
- deprecated: true
+ oneOf:
+ - description:
+ Controller request to read or write virtual product data
+ from/to the VPD capability registers.
+ const: vpd
+ - description:
+ Link Equalization Request flag is set in the Link Status 2
+ register (applicable if the corresponding IRQ is enabled in
+ the Link Control 3 register).
+ const: l_eq
+ - description:
+ Indicates that the eDMA Tx/Rx transfer is complete or that an
+ error has occurred on the corresponding channel. eDMA can have
+ eight Tx (Write) and Rx (Read) eDMA channels thus supporting up
+ to 16 IRQ signals all together. Write eDMA channels shall go
+ first in the ordered row as per default edma_int[*] bus setup.
+ pattern: '^dma([0-9]|1[0-5])?$'
+ - description:
+ PCIe protocol correctable error or a Data Path protection
+ correctable error is detected by the automotive/safety
+ feature.
+ const: sft_ce
+ - description:
+ Indicates that the internal safety mechanism has detected an
+ uncorrectable error.
+ const: sft_ue
+ - description:
+ Application-specific IRQ raised depending on the vendor-specific
+ events basis.
+ const: app
+ - description:
+ DSP AXI MSI Interrupt detected. It gets de-asserted when there is
+ no more MSI interrupt pending. The interrupt is relevant to the
+ iMSI-RX - Integrated MSI Receiver (AXI bridge).
+ const: msi
+ - description:
+ Legacy A/B/C/D interrupt signal. Basically it's triggered by
+ receiving a Assert_INT{A,B,C,D}/Desassert_INT{A,B,C,D} message
+ from the downstream device.
+ pattern: "^int(a|b|c|d)$"
+ - description:
+ Error condition detected and a flag is set in the Root Error Status
+ register of the AER capability. It's asserted when the RC
+ internally generated an error or an error message is received by
+ the RC.
+ const: aer
+ - description:
+ PME message is received by the port. That means having the PME
+ status bit set in the Root Status register (the event is
+ supposed to be unmasked in the Root Control register).
+ const: pme
+ - description:
+ Hot-plug event is detected. That is a bit has been set in the
+ Slot Status register and the corresponding event is enabled in
+ the Slot Control register.
+ const: hp
+ - description:
+ Link Autonomous Bandwidth Status flag has been set in the Link
+ Status register (the event is supposed to be unmasked in the
+ Link Control register).
+ const: bw_au
+ - description:
+ Bandwidth Management Status flag has been set in the Link
+ Status register (the event is supposed to be unmasked in the
+ Link Control register).
+ const: bw_mg
+ - description:
+ Combined Legacy A/B/C/D interrupt signal. See "^int(a|b|c|d)$" for
+ details.
+ const: legacy
+ - description:
+ Vendor-specific IRQ names. Consider using the generic names above
+ for new bindings.
+ oneOf:
+ - description: See native "app" IRQ for details
+ enum: [ intr, sys, pmc, msg, err ]
additionalProperties: true
required:
+ - compatible
- reg
- reg-names
- - compatible
examples:
- |
- bus {
- #address-cells = <1>;
- #size-cells = <1>;
- pcie@dfc00000 {
- device_type = "pci";
- compatible = "snps,dw-pcie";
- reg = <0xdfc00000 0x0001000>, /* IP registers */
- <0xd0000000 0x0002000>; /* Configuration space */
- reg-names = "dbi", "config";
- #address-cells = <3>;
- #size-cells = <2>;
- ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000>,
- <0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>;
- interrupts = <25>, <24>;
- #interrupt-cells = <1>;
- num-lanes = <1>;
- };
+ pcie@dfc00000 {
+ compatible = "snps,dw-pcie";
+ device_type = "pci";
+ reg = <0xdfc00000 0x0001000>, /* IP registers */
+ <0xd0000000 0x0002000>; /* Configuration space */
+ reg-names = "dbi", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000>,
+ <0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>;
+ bus-range = <0x0 0xff>;
+
+ interrupts = <25>, <24>;
+ interrupt-names = "msi", "hp";
+
+ reset-gpios = <&port0 0 1>;
+
+ phys = <&pcie_phy>;
+ phy-names = "pcie";
+
+ num-lanes = <1>;
+ max-link-speed = <3>;
};
diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
index 437e61618d06..93f3d0f4bb94 100644
--- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
@@ -15,9 +15,6 @@ description: |
maintainers:
- Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
-allOf:
- - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
-
properties:
compatible:
enum:
@@ -29,40 +26,29 @@ properties:
maxItems: 5
reg-names:
- oneOf:
- - items:
- - const: dbi
- - const: dbi2
- - const: link
- - const: addr_space
- - items:
- - const: dbi
- - const: dbi2
- - const: link
- - const: addr_space
- - const: atu
+ minItems: 4
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: link
+ - const: addr_space
+ - const: atu
clocks:
minItems: 1
maxItems: 2
clock-names:
- oneOf:
- - items: # for Pro5
- - const: gio
- - const: link
- - const: link # for NX1
+ minItems: 1
+ maxItems: 2
resets:
minItems: 1
maxItems: 2
reset-names:
- oneOf:
- - items: # for Pro5
- - const: gio
- - const: link
- - const: link # for NX1
+ minItems: 1
+ maxItems: 2
num-ib-windows:
const: 16
@@ -78,6 +64,46 @@ properties:
phy-names:
const: pcie-phy
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-pro5-pcie-ep
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ reg-names:
+ maxItems: 4
+ clocks:
+ minItems: 2
+ clock-names:
+ items:
+ - const: gio
+ - const: link
+ resets:
+ minItems: 2
+ reset-names:
+ items:
+ - const: gio
+ - const: link
+ else:
+ properties:
+ reg:
+ minItems: 5
+ reg-names:
+ minItems: 5
+ clocks:
+ maxItems: 1
+ clock-names:
+ const: link
+ resets:
+ maxItems: 1
+ reset-names:
+ const: link
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml
index 638b99db0433..c07b0ed51613 100644
--- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie.yaml
@@ -56,6 +56,9 @@ properties:
additionalProperties: false
properties:
+ '#address-cells':
+ const: 0
+
interrupt-controller: true
'#interrupt-cells':
@@ -109,6 +112,7 @@ examples:
<0 0 0 4 &pcie_intc 3>;
pcie_intc: interrupt-controller {
+ #address-cells = <0>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gic>;
diff --git a/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml b/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml
new file mode 100644
index 000000000000..f8b7ca57fff1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/sophgo,sg2042-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 PCIe Host (Cadence PCIe Wrapper)
+
+description:
+ Sophgo SG2042 PCIe host controller is based on the Cadence PCIe core.
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+properties:
+ compatible:
+ const: sophgo,sg2042-pcie-host
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: reg
+ - const: cfg
+
+ vendor-id:
+ const: 0x1f1c
+
+ device-id:
+ const: 0x2042
+
+ msi-parent: true
+
+allOf:
+ - $ref: cdns-pcie-host.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pcie@62000000 {
+ compatible = "sophgo,sg2042-pcie-host";
+ device_type = "pci";
+ reg = <0x62000000 0x00800000>,
+ <0x48000000 0x00001000>;
+ reg-names = "reg", "cfg";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000>,
+ <0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>;
+ bus-range = <0x00 0xff>;
+ vendor-id = <0x1f1c>;
+ device-id = <0x2042>;
+ cdns,no-bar-match-nbits = <48>;
+ msi-parent = <&msi>;
+ };
diff --git a/Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml b/Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml
new file mode 100644
index 000000000000..ff1133bae3ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sophgo,sg2044-pcie.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/sophgo,sg2044-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DesignWare based PCIe Root Complex controller on Sophgo SoCs
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+description:
+ SG2044 SoC PCIe Root Complex controller is based on the Synopsys DesignWare
+ PCIe IP and thus inherits all the common properties defined in
+ snps,dw-pcie.yaml.
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ const: sophgo,sg2044-pcie
+
+ reg:
+ items:
+ - description: Data Bus Interface (DBI) registers
+ - description: iATU registers
+ - description: Config registers
+ - description: Sophgo designed configuration registers
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: atu
+ - const: config
+ - const: app
+
+ clocks:
+ items:
+ - description: core clk
+
+ clock-names:
+ items:
+ - const: core
+
+ interrupt-controller:
+ description: Interrupt controller node for handling legacy PCI interrupts.
+ type: object
+
+ properties:
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ items:
+ - description: combined legacy interrupt
+
+ required:
+ - "#address-cells"
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupts
+
+ additionalProperties: false
+
+ msi-parent: true
+
+ ranges:
+ maxItems: 5
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@6c00400000 {
+ compatible = "sophgo,sg2044-pcie";
+ reg = <0x6c 0x00400000 0x0 0x00001000>,
+ <0x6c 0x00700000 0x0 0x00004000>,
+ <0x40 0x00000000 0x0 0x00001000>,
+ <0x6c 0x00780c00 0x0 0x00000400>;
+ reg-names = "dbi", "atu", "config", "app";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ clocks = <&clk 0>;
+ clock-names = "core";
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ msi-parent = <&msi>;
+ ranges = <0x01000000 0x0 0x00000000 0x40 0x10000000 0x0 0x00200000>,
+ <0x42000000 0x0 0x00000000 0x0 0x00000000 0x0 0x04000000>,
+ <0x02000000 0x0 0x04000000 0x0 0x04000000 0x0 0x04000000>,
+ <0x43000000 0x42 0x00000000 0x42 0x00000000 0x2 0x00000000>,
+ <0x03000000 0x41 0x00000000 0x41 0x00000000 0x1 0x00000000>;
+
+ interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupt-parent = <&intc>;
+ interrupts = <64 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml b/Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml
new file mode 100644
index 000000000000..c4c00b5fcdc0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/spacemit,k1-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 PCI Express Host Controller
+
+maintainers:
+ - Alex Elder <elder@riscstar.com>
+
+description: >
+ The SpacemiT K1 SoC PCIe host controller is based on the Synopsys DesignWare
+ PCIe IP. The controller uses the DesignWare built-in MSI interrupt
+ controller, and supports 256 MSIs.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-pcie
+
+ reg:
+ items:
+ - description: DesignWare PCIe registers
+ - description: ATU address space
+ - description: PCIe configuration space
+ - description: Link control registers
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: atu
+ - const: config
+ - const: link
+
+ clocks:
+ items:
+ - description: DWC PCIe Data Bus Interface (DBI) clock
+ - description: DWC PCIe application AXI-bus master interface clock
+ - description: DWC PCIe application AXI-bus slave interface clock
+
+ clock-names:
+ items:
+ - const: dbi
+ - const: mstr
+ - const: slv
+
+ resets:
+ items:
+ - description: DWC PCIe Data Bus Interface (DBI) reset
+ - description: DWC PCIe application AXI-bus master interface reset
+ - description: DWC PCIe application AXI-bus slave interface reset
+
+ reset-names:
+ items:
+ - const: dbi
+ - const: mstr
+ - const: slv
+
+ interrupts:
+ items:
+ - description: Interrupt used for MSIs
+
+ interrupt-names:
+ const: msi
+
+ spacemit,apmu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ A phandle that refers to the APMU system controller, whose regmap is
+ used in managing resets and link state, along with and offset of its
+ reset control register.
+ items:
+ - items:
+ - description: phandle to APMU system controller
+ - description: register offset
+
+patternProperties:
+ '^pcie@':
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ phys:
+ maxItems: 1
+
+ vpcie3v3-supply:
+ description:
+ A phandle for 3.3v regulator to use for PCIe
+
+ required:
+ - phys
+ - vpcie3v3-supply
+
+ unevaluatedProperties: false
+
+required:
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - interrupts
+ - interrupt-names
+ - spacemit,apmu
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+ pcie@ca400000 {
+ device_type = "pci";
+ compatible = "spacemit,k1-pcie";
+ reg = <0xca400000 0x00001000>,
+ <0xca700000 0x0001ff24>,
+ <0x9f000000 0x00002000>,
+ <0xc0c20000 0x00001000>;
+ reg-names = "dbi",
+ "atu",
+ "config",
+ "link";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x9f002000 0x0 0x00100000>,
+ <0x02000000 0x0 0x90000000 0x90000000 0x0 0x0f000000>;
+ interrupts = <142>;
+ interrupt-names = "msi";
+ clocks = <&syscon_apmu CLK_PCIE1_DBI>,
+ <&syscon_apmu CLK_PCIE1_MASTER>,
+ <&syscon_apmu CLK_PCIE1_SLAVE>;
+ clock-names = "dbi",
+ "mstr",
+ "slv";
+ resets = <&syscon_apmu RESET_PCIE1_DBI>,
+ <&syscon_apmu RESET_PCIE1_MASTER>,
+ <&syscon_apmu RESET_PCIE1_SLAVE>;
+ reset-names = "dbi",
+ "mstr",
+ "slv";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_3_cfg>;
+ spacemit,apmu = <&syscon_apmu 0x3d4>;
+
+ pcie@0 {
+ device_type = "pci";
+ compatible = "pciclass,0604";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ phys = <&pcie1_phy>;
+ vpcie3v3-supply = <&pcie_vcc_3v3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt b/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt
deleted file mode 100644
index d5a14f5dad46..000000000000
--- a/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-SPEAr13XX PCIe DT detail:
-================================
-
-SPEAr13XX uses the Synopsys DesignWare PCIe controller and ST MiPHY as PHY
-controller.
-
-Required properties:
-- compatible : should be "st,spear1340-pcie", "snps,dw-pcie".
-- phys : phandle to PHY node associated with PCIe controller
-- phy-names : must be "pcie-phy"
-- All other definitions as per generic PCI bindings
-
- Optional properties:
-- st,pcie-is-gen1 indicates that forced gen1 initialization is needed.
diff --git a/Documentation/devicetree/bindings/pci/st,spear1340-pcie.yaml b/Documentation/devicetree/bindings/pci/st,spear1340-pcie.yaml
new file mode 100644
index 000000000000..784f97b3cb7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st,spear1340-pcie.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/st,spear1340-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST SPEAr1340 PCIe controller
+
+maintainers:
+ - Pratyush Anand <pratyush.anand@gmail.com>
+
+description:
+ SPEAr13XX uses the Synopsys DesignWare PCIe controller and ST MiPHY as PHY
+ controller.
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: st,spear1340-pcie
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: st,spear1340-pcie
+ - const: snps,dw-pcie
+
+ phys:
+ maxItems: 1
+
+ st,pcie-is-gen1:
+ type: boolean
+ description: Indicates forced gen1 initialization is needed.
+
+required:
+ - compatible
+ - phys
+ - phy-names
+
+allOf:
+ - $ref: snps,dw-pcie.yaml#
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
new file mode 100644
index 000000000000..5adbff259204
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-common.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/st,stm32-pcie-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32MP25 PCIe RC/EP controller
+
+maintainers:
+ - Christian Bruel <christian.bruel@foss.st.com>
+
+description:
+ STM32MP25 PCIe RC/EP common properties
+
+properties:
+ clocks:
+ maxItems: 1
+ description: PCIe system clock
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ access-controllers:
+ maxItems: 1
+
+required:
+ - clocks
+ - resets
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-ep.yaml
new file mode 100644
index 000000000000..b076ada4f332
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-ep.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/st,stm32-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 PCIe Endpoint
+
+maintainers:
+ - Christian Bruel <christian.bruel@foss.st.com>
+
+description:
+ PCIe endpoint controller based on the Synopsys DesignWare PCIe core.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
+ - $ref: /schemas/pci/st,stm32-pcie-common.yaml#
+
+properties:
+ compatible:
+ const: st,stm32mp25-pcie-ep
+
+ reg:
+ items:
+ - description: Data Bus Interface (DBI) registers.
+ - description: Data Bus Interface (DBI) shadow registers.
+ - description: Internal Address Translation Unit (iATU) registers.
+ - description: PCIe configuration registers.
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: atu
+ - const: addr_space
+
+ reset-gpios:
+ description: GPIO controlled connection to PERST# signal
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+required:
+ - phys
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+ pcie-ep@48400000 {
+ compatible = "st,stm32mp25-pcie-ep";
+ reg = <0x48400000 0x400000>,
+ <0x48500000 0x100000>,
+ <0x48700000 0x80000>,
+ <0x10000000 0x10000000>;
+ reg-names = "dbi", "dbi2", "atu", "addr_space";
+ clocks = <&rcc CK_BUS_PCIE>;
+ phys = <&combophy PHY_TYPE_PCIE>;
+ resets = <&rcc PCIE_R>;
+ pinctrl-names = "default", "init";
+ pinctrl-0 = <&pcie_pins_a>;
+ pinctrl-1 = <&pcie_init_pins_a>;
+ reset-gpios = <&gpioj 8 GPIO_ACTIVE_LOW>;
+ access-controllers = <&rifsc 68>;
+ power-domains = <&CLUSTER_PD>;
+ };
diff --git a/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
new file mode 100644
index 000000000000..443bfe2cdc98
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st,stm32-pcie-host.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/st,stm32-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 PCIe Root Complex
+
+maintainers:
+ - Christian Bruel <christian.bruel@foss.st.com>
+
+description:
+ PCIe root complex controller based on the Synopsys DesignWare PCIe core.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+ - $ref: /schemas/pci/st,stm32-pcie-common.yaml#
+
+properties:
+ compatible:
+ const: st,stm32mp25-pcie-rc
+
+ reg:
+ items:
+ - description: Data Bus Interface (DBI) registers.
+ - description: PCIe configuration registers.
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: config
+
+ msi-parent:
+ maxItems: 1
+
+patternProperties:
+ '^pcie@[0-2],0$':
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO controlled connection to PERST# signal
+ maxItems: 1
+
+ wake-gpios:
+ description: GPIO used as WAKE# input signal
+ maxItems: 1
+
+ required:
+ - phys
+ - ranges
+
+ unevaluatedProperties: false
+
+required:
+ - interrupt-map
+ - interrupt-map-mask
+ - ranges
+ - dma-ranges
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+ pcie@48400000 {
+ compatible = "st,stm32mp25-pcie-rc";
+ device_type = "pci";
+ reg = <0x48400000 0x400000>,
+ <0x10000000 0x10000>;
+ reg-names = "dbi", "config";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 264 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x10010000 0x0 0x10000>,
+ <0x02000000 0x0 0x10020000 0x10020000 0x0 0x7fe0000>,
+ <0x42000000 0x0 0x18000000 0x18000000 0x0 0x8000000>;
+ dma-ranges = <0x42000000 0x0 0x80000000 0x80000000 0x0 0x80000000>;
+ clocks = <&rcc CK_BUS_PCIE>;
+ resets = <&rcc PCIE_R>;
+ msi-parent = <&v2m0>;
+ access-controllers = <&rifsc 68>;
+ power-domains = <&CLUSTER_PD>;
+
+ pcie@0,0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ phys = <&combophy PHY_TYPE_PCIE>;
+ wake-gpios = <&gpioh 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ reset-gpios = <&gpioj 8 GPIO_ACTIVE_LOW>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml b/Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml
new file mode 100644
index 000000000000..33c80626e8ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/starfive,jh7110-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 PCIe host controller
+
+maintainers:
+ - Kevin Xie <kevin.xie@starfivetech.com>
+
+allOf:
+ - $ref: plda,xpressrich3-axi-common.yaml#
+
+properties:
+ compatible:
+ const: starfive,jh7110-pcie
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ maxItems: 2
+
+ clocks:
+ items:
+ - description: NOC bus clock
+ - description: Transport layer clock
+ - description: AXI MST0 clock
+ - description: APB clock
+
+ clock-names:
+ items:
+ - const: noc
+ - const: tl
+ - const: axi_mst0
+ - const: apb
+
+ resets:
+ items:
+ - description: AXI MST0 reset
+ - description: AXI SLAVE0 reset
+ - description: AXI SLAVE reset
+ - description: PCIE BRIDGE reset
+ - description: PCIE CORE reset
+ - description: PCIE APB reset
+
+ reset-names:
+ items:
+ - const: mst0
+ - const: slv0
+ - const: slv
+ - const: brg
+ - const: core
+ - const: apb
+
+ starfive,stg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ The phandle to System Register Controller syscon node.
+
+ perst-gpios:
+ description: GPIO controlled connection to PERST# signal
+ maxItems: 1
+
+ phys:
+ description:
+ Specified PHY is attached to PCIe controller.
+ maxItems: 1
+
+required:
+ - clocks
+ - resets
+ - starfive,stg-syscon
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@940000000 {
+ compatible = "starfive,jh7110-pcie";
+ reg = <0x9 0x40000000 0x0 0x10000000>,
+ <0x0 0x2b000000 0x0 0x1000000>;
+ reg-names = "cfg", "apb";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ ranges = <0x82000000 0x0 0x30000000 0x0 0x30000000 0x0 0x08000000>,
+ <0xc3000000 0x9 0x00000000 0x9 0x00000000 0x0 0x40000000>;
+ starfive,stg-syscon = <&stg_syscon>;
+ bus-range = <0x0 0xff>;
+ interrupt-parent = <&plic>;
+ interrupts = <56>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc0 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc0 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc0 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc0 0x4>;
+ msi-controller;
+ clocks = <&syscrg 86>,
+ <&stgcrg 10>,
+ <&stgcrg 8>,
+ <&stgcrg 9>;
+ clock-names = "noc", "tl", "axi_mst0", "apb";
+ resets = <&stgcrg 11>,
+ <&stgcrg 12>,
+ <&stgcrg 13>,
+ <&stgcrg 14>,
+ <&stgcrg 15>,
+ <&stgcrg 16>;
+ perst-gpios = <&gpios 26 GPIO_ACTIVE_LOW>;
+ phys = <&pciephy0>;
+
+ pcie_intc0: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
index a20dccbafd94..98f6c7f1b1a6 100644
--- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
@@ -11,7 +11,7 @@ maintainers:
- Kishon Vijay Abraham I <kishon@ti.com>
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -20,14 +20,18 @@ properties:
- ti,keystone-pcie
reg:
- maxItems: 4
+ minItems: 4
+ maxItems: 6
reg-names:
+ minItems: 4
items:
- const: app
- const: dbics
- const: config
- const: atu
+ - const: vmap_lp
+ - const: vmap_hp
interrupts:
maxItems: 1
@@ -55,6 +59,29 @@ properties:
dma-coherent: true
+ num-viewport:
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ phys:
+ description: per-lane PHYs
+ minItems: 1
+ maxItems: 2
+
+ phy-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ pattern: '^pcie-phy[0-1]$'
+
+ memory-region:
+ maxItems: 1
+ description: |
+ phandle to a restricted DMA pool to be used for all devices behind
+ this controller. The regions should be defined according to
+ reserved-memory/shared-dma-pool.yaml.
+ Note that enforcement via the PVU will only be available to
+ ti,am654-pcie-rc devices.
+
required:
- compatible
- reg
@@ -74,6 +101,14 @@ then:
- dma-coherent
- power-domains
- msi-map
+ - num-viewport
+else:
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ maxItems: 4
unevaluatedProperties: false
@@ -81,6 +116,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/phy/phy.h>
#include <dt-bindings/soc/ti,sci_pm_domain.h>
pcie0_rc: pcie@5500000 {
@@ -88,8 +124,10 @@ examples:
reg = <0x5500000 0x1000>,
<0x5501000 0x1000>,
<0x10000000 0x2000>,
- <0x5506000 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ <0x5506000 0x1000>,
+ <0x2900000 0x1000>,
+ <0x2908000 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
@@ -98,9 +136,13 @@ examples:
ti,syscon-pcie-id = <&scm_conf 0x0210>;
ti,syscon-pcie-mode = <&scm_conf 0x4060>;
bus-range = <0x0 0xff>;
+ num-viewport = <16>;
max-link-speed = <2>;
dma-coherent;
interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>;
msi-map = <0x0 &gic_its 0x0 0x10000>;
device_type = "pci";
+ num-lanes = <1>;
+ phys = <&serdes0 PHY_TYPE_PCIE 0>;
+ phy-names = "pcie-phy0";
};
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
index aed437dac363..29580cbd1767 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
@@ -2,21 +2,19 @@
# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-ep.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/ti,j721e-pci-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI J721E PCI EP (PCIe Wrapper)
maintainers:
- Kishon Vijay Abraham I <kishon@ti.com>
-allOf:
- - $ref: "cdns-pcie-ep.yaml#"
-
properties:
compatible:
oneOf:
- const: ti,j721e-pcie-ep
+ - const: ti,j784s4-pcie-ep
- description: PCIe EP controller in AM64
items:
- const: ti,am64-pcie-ep
@@ -58,6 +56,48 @@ properties:
dma-coherent:
description: Indicates that the PCIe IP block can ensure the coherency
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: link_state
+
+allOf:
+ - $ref: cdns-pcie-ep.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,am64-pcie-ep
+ then:
+ properties:
+ num-lanes:
+ const: 1
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,j7200-pcie-ep
+ - ti,j721e-pcie-ep
+ then:
+ properties:
+ num-lanes:
+ minimum: 1
+ maximum: 2
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,j784s4-pcie-ep
+ then:
+ properties:
+ num-lanes:
+ minimum: 1
+ maximum: 4
+
required:
- compatible
- reg
@@ -83,21 +123,21 @@ examples:
#size-cells = <2>;
pcie0_ep: pcie-ep@d000000 {
- compatible = "ti,j721e-pcie-ep";
- reg = <0x00 0x02900000 0x00 0x1000>,
- <0x00 0x02907000 0x00 0x400>,
- <0x00 0x0d000000 0x00 0x00800000>,
- <0x00 0x10000000 0x00 0x08000000>;
- reg-names = "intd_cfg", "user_cfg", "reg", "mem";
- ti,syscon-pcie-ctrl = <&pcie0_ctrl 0x4070>;
- max-link-speed = <3>;
- num-lanes = <2>;
- power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
- clocks = <&k3_clks 239 1>;
- clock-names = "fck";
- max-functions = /bits/ 8 <6>;
- dma-coherent;
- phys = <&serdes0_pcie_link>;
- phy-names = "pcie-phy";
- };
+ compatible = "ti,j721e-pcie-ep";
+ reg = <0x00 0x02900000 0x00 0x1000>,
+ <0x00 0x02907000 0x00 0x400>,
+ <0x00 0x0d000000 0x00 0x00800000>,
+ <0x00 0x10000000 0x00 0x08000000>;
+ reg-names = "intd_cfg", "user_cfg", "reg", "mem";
+ ti,syscon-pcie-ctrl = <&pcie0_ctrl 0x4070>;
+ max-link-speed = <3>;
+ num-lanes = <2>;
+ power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 239 1>;
+ clock-names = "fck";
+ max-functions = /bits/ 8 <6>;
+ dma-coherent;
+ phys = <&serdes0_pcie_link>;
+ phy-names = "pcie-phy";
+ };
};
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
index 2115d5a3f0e1..c704099f134b 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
@@ -2,21 +2,19 @@
# Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-host.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/pci/ti,j721e-pci-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI J721E PCI Host (PCIe Wrapper)
maintainers:
- Kishon Vijay Abraham I <kishon@ti.com>
-allOf:
- - $ref: "cdns-pcie-host.yaml#"
-
properties:
compatible:
oneOf:
- const: ti,j721e-pcie-host
+ - const: ti,j784s4-pcie-host
- description: PCIe controller in AM64
items:
- const: ti,am64-pcie-host
@@ -25,6 +23,10 @@ properties:
items:
- const: ti,j7200-pcie-host
- const: ti,j721e-pcie-host
+ - description: PCIe controller in J722S
+ items:
+ - const: ti,j722s-pcie-host
+ - const: ti,j721e-pcie-host
reg:
maxItems: 4
@@ -36,6 +38,16 @@ properties:
- const: reg
- const: cfg
+ ti,syscon-acspcie-proxy-ctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to the ACSPCIE Proxy Control Register
+ - description: Bitmask corresponding to the PAD IO Buffer
+ output enable fields (Active Low).
+ description: Specifier for enabling the ACSPCIE PAD outputs to drive
+ the reference clock to the Endpoint device.
+
ti,syscon-pcie-ctrl:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
@@ -66,16 +78,73 @@ properties:
const: 0x104c
device-id:
- oneOf:
- - items:
- - const: 0xb00d
- - items:
- - const: 0xb00f
- - items:
- - const: 0xb010
+ enum:
+ - 0xb00d
+ - 0xb00f
+ - 0xb010
+ - 0xb012
+ - 0xb013
msi-map: true
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: link_state
+
+ interrupt-controller:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#address-cells':
+ const: 0
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ interrupts:
+ maxItems: 1
+
+allOf:
+ - $ref: cdns-pcie-host.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,am64-pcie-host
+ then:
+ properties:
+ num-lanes:
+ const: 1
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,j7200-pcie-host
+ - ti,j721e-pcie-host
+ then:
+ properties:
+ num-lanes:
+ minimum: 1
+ maximum: 2
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,j784s4-pcie-host
+ then:
+ properties:
+ num-lanes:
+ minimum: 1
+ maximum: 4
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
new file mode 100644
index 000000000000..fae466064780
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
@@ -0,0 +1,179 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/toshiba,tc9563.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC9563 PCIe switch
+
+maintainers:
+ - Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
+
+description: |
+ Toshiba TC9563 PCIe switch has one upstream and three downstream ports.
+ The 3rd downstream port has integrated endpoint device of Ethernet MAC.
+ Other two downstream ports are supposed to connect to external device.
+
+ The TC9563 PCIe switch can be configured through I2C interface before
+ PCIe link is established to change FTS, ASPM related entry delays,
+ tx amplitude etc for better power efficiency and functionality.
+
+properties:
+ compatible:
+ enum:
+ - pci1179,0623
+
+ reg:
+ maxItems: 1
+
+ resx-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the RESX# pin.
+
+ vdd18-supply: true
+
+ vdd09-supply: true
+
+ vddc-supply: true
+
+ vddio1-supply: true
+
+ vddio2-supply: true
+
+ vddio18-supply: true
+
+ i2c-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ A phandle to the parent I2C node and the slave address of the device
+ used to configure tc9563 to change FTS, tx amplitude etc.
+ items:
+ - description: Phandle to the I2C controller node
+ - description: I2C slave address
+
+patternProperties:
+ "^pcie@[1-3],0$":
+ description:
+ child nodes describing the internal downstream ports of
+ the tc9563 switch.
+ type: object
+ allOf:
+ - $ref: "#/$defs/tc9563-node"
+ - $ref: /schemas/pci/pci-pci-bridge.yaml#
+ unevaluatedProperties: false
+
+$defs:
+ tc9563-node:
+ type: object
+
+ properties:
+ toshiba,tx-amplitude-microvolt:
+ description:
+ Change Tx Margin setting for low power consumption.
+
+ toshiba,no-dfe-support:
+ type: boolean
+ description:
+ Disable DFE (Decision Feedback Equalizer), which mitigates
+ intersymbol interference and some reflections caused by
+ impedance mismatches.
+
+required:
+ - resx-gpios
+ - vdd18-supply
+ - vdd09-supply
+ - vddc-supply
+ - vddio1-supply
+ - vddio2-supply
+ - vddio18-supply
+ - i2c-parent
+
+allOf:
+ - $ref: "#/$defs/tc9563-node"
+ - $ref: /schemas/pci/pci-bus-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ bus-range = <0x01 0xff>;
+
+ pcie@0,0 {
+ compatible = "pci1179,0623";
+
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ bus-range = <0x02 0xff>;
+
+ i2c-parent = <&qup_i2c 0x77>;
+
+ vdd18-supply = <&vdd>;
+ vdd09-supply = <&vdd>;
+ vddc-supply = <&vdd>;
+ vddio1-supply = <&vdd>;
+ vddio2-supply = <&vdd>;
+ vddio18-supply = <&vdd>;
+
+ resx-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+
+ pcie@1,0 {
+ compatible = "pciclass,0604";
+ reg = <0x20800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ bus-range = <0x03 0xff>;
+
+ toshiba,no-dfe-support;
+ };
+
+ pcie@2,0 {
+ compatible = "pciclass,0604";
+ reg = <0x21000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ bus-range = <0x04 0xff>;
+ };
+
+ pcie@3,0 {
+ compatible = "pciclass,0604";
+ reg = <0x21800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ bus-range = <0x05 0xff>;
+
+ toshiba,tx-amplitude-microvolt = <10>;
+
+ ethernet@0,0 {
+ reg = <0x50000 0x0 0x0 0x0 0x0>;
+ };
+
+ ethernet@0,1 {
+ reg = <0x50100 0x0 0x0 0x0 0x0>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
index 30b6396d83c8..120e3bb1e545 100644
--- a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings
+title: Toshiba Visconti5 SoC PCIe Host Controller
maintainers:
- Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
@@ -36,7 +36,7 @@ properties:
- const: mpu
interrupts:
- maxItems: 1
+ maxItems: 2
clocks:
items:
@@ -83,7 +83,7 @@ examples:
<0x0 0x28050000 0x0 0x00010000>,
<0x0 0x24200000 0x0 0x00002000>,
<0x0 0x24162000 0x0 0x00001000>;
- reg-names = "dbi", "config", "ulreg", "smu", "mpu";
+ reg-names = "dbi", "config", "ulreg", "smu", "mpu";
device_type = "pci";
bus-range = <0x00 0xff>;
num-lanes = <2>;
@@ -94,8 +94,9 @@ examples:
#interrupt-cells = <1>;
ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>,
<0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>;
- interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
+ interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "intr";
interrupt-map-mask = <0 0 0 7>;
interrupt-map =
<0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
diff --git a/Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml b/Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml
new file mode 100644
index 000000000000..38cac88f17bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/v3,v360epc-pci.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/v3,v360epc-pci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: V3 Semiconductor V360 EPC PCI bridge
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ This bridge is found in the ARM Integrator/AP (Application Platform)
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: arm,integrator-ap-pci
+ - const: v3,v360epc-pci
+
+ reg:
+ items:
+ - description: V3 host bridge controller
+ - description: Configuration space
+
+ clocks:
+ maxItems: 1
+
+ dma-ranges:
+ maxItems: 2
+ description:
+ The inbound ranges must be aligned to a 1MB boundary, and may be 1MB, 2MB,
+ 4MB, 8MB, 16MB, 32MB, 64MB, 128MB, 256MB, 512MB, 1GB or 2GB in size. The
+ memory should be marked as pre-fetchable.
+
+ interrupts:
+ description: Bus Error IRQ
+ maxItems: 1
+
+ ranges:
+ description:
+ The non-prefetchable and prefetchable memory windows must each be exactly
+ 256MB (0x10000000) in size. The prefetchable memory window must be
+ immediately adjacent to the non-prefetchable memory window.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dma-ranges
+ - "#interrupt-cells"
+ - interrupt-map
+ - interrupt-map-mask
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pci@62000000 {
+ compatible = "arm,integrator-ap-pci", "v3,v360epc-pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0x62000000 0x10000>, <0x61000000 0x01000000>;
+ device_type = "pci";
+ interrupt-parent = <&pic>;
+ interrupts = <17>; /* Bus error IRQ */
+ clocks = <&pciclk>;
+ ranges = <0x01000000 0 0x00000000 0x60000000 0 0x01000000>, /* 16 MiB @ LB 60000000 */
+ <0x02000000 0 0x40000000 0x40000000 0 0x10000000>, /* 256 MiB @ LB 40000000 1:1 */
+ <0x42000000 0 0x50000000 0x50000000 0 0x10000000>; /* 256 MiB @ LB 50000000 1:1 */
+ dma-ranges = <0x02000000 0 0x20000000 0x20000000 0 0x20000000>, /* EBI: 512 MB @ LB 20000000 1:1 */
+ <0x02000000 0 0x80000000 0x80000000 0 0x40000000>; /* CM alias: 1GB @ LB 80000000 */
+ interrupt-map-mask = <0xf800 0 0 0x7>;
+ interrupt-map =
+ /* IDSEL 9 */
+ <0x4800 0 0 1 &pic 13>, /* INT A on slot 9 is irq 13 */
+ <0x4800 0 0 2 &pic 14>, /* INT B on slot 9 is irq 14 */
+ <0x4800 0 0 3 &pic 15>, /* INT C on slot 9 is irq 15 */
+ <0x4800 0 0 4 &pic 16>, /* INT D on slot 9 is irq 16 */
+ /* IDSEL 10 */
+ <0x5000 0 0 1 &pic 14>, /* INT A on slot 10 is irq 14 */
+ <0x5000 0 0 2 &pic 15>, /* INT B on slot 10 is irq 15 */
+ <0x5000 0 0 3 &pic 16>, /* INT C on slot 10 is irq 16 */
+ <0x5000 0 0 4 &pic 13>, /* INT D on slot 10 is irq 13 */
+ /* IDSEL 11 */
+ <0x5800 0 0 1 &pic 15>, /* INT A on slot 11 is irq 15 */
+ <0x5800 0 0 2 &pic 16>, /* INT B on slot 11 is irq 16 */
+ <0x5800 0 0 3 &pic 13>, /* INT C on slot 11 is irq 13 */
+ <0x5800 0 0 4 &pic 14>, /* INT D on slot 11 is irq 14 */
+ /* IDSEL 12 */
+ <0x6000 0 0 1 &pic 16>, /* INT A on slot 12 is irq 16 */
+ <0x6000 0 0 2 &pic 13>, /* INT B on slot 12 is irq 13 */
+ <0x6000 0 0 3 &pic 14>, /* INT C on slot 12 is irq 14 */
+ <0x6000 0 0 4 &pic 15>; /* INT D on slot 12 is irq 15 */
+ };
+...
diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
deleted file mode 100644
index 11063293f761..000000000000
--- a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-V3 Semiconductor V360 EPC PCI bridge
-
-This bridge is found in the ARM Integrator/AP (Application Platform)
-
-Required properties:
-- compatible: should be one of:
- "v3,v360epc-pci"
- "arm,integrator-ap-pci", "v3,v360epc-pci"
-- reg: should contain two register areas:
- first the base address of the V3 host bridge controller, 64KB
- second the configuration area register space, 16MB
-- interrupts: should contain a reference to the V3 error interrupt
- as routed on the system.
-- bus-range: see pci.txt
-- ranges: this follows the standard PCI bindings in the IEEE Std
- 1275-1994 (see pci.txt) with the following restriction:
- - The non-prefetchable and prefetchable memory windows must
- each be exactly 256MB (0x10000000) in size.
- - The prefetchable memory window must be immediately adjacent
- to the non-prefetcable memory window
-- dma-ranges: three ranges for the inbound memory region. The ranges must
- be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB,
- 64MB, 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked
- as pre-fetchable. Two ranges are supported by the hardware.
-
-Integrator-specific required properties:
-- syscon: should contain a link to the syscon device node, since
- on the Integrator, some registers in the syscon are required to
- operate the V3 host bridge.
-
-Example:
-
-pci: pciv3@62000000 {
- compatible = "arm,integrator-ap-pci", "v3,v360epc-pci";
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- reg = <0x62000000 0x10000>, <0x61000000 0x01000000>;
- interrupt-parent = <&pic>;
- interrupts = <17>; /* Bus error IRQ */
- clocks = <&pciclk>;
- bus-range = <0x00 0xff>;
- ranges = 0x01000000 0 0x00000000 /* I/O space @00000000 */
- 0x60000000 0 0x01000000 /* 16 MiB @ LB 60000000 */
- 0x02000000 0 0x40000000 /* non-prefectable memory @40000000 */
- 0x40000000 0 0x10000000 /* 256 MiB @ LB 40000000 1:1 */
- 0x42000000 0 0x50000000 /* prefetchable memory @50000000 */
- 0x50000000 0 0x10000000>; /* 256 MiB @ LB 50000000 1:1 */
- dma-ranges = <0x02000000 0 0x20000000 /* EBI memory space */
- 0x20000000 0 0x20000000 /* 512 MB @ LB 20000000 1:1 */
- 0x02000000 0 0x80000000 /* Core module alias memory */
- 0x80000000 0 0x40000000>; /* 1GB @ LB 80000000 */
- interrupt-map-mask = <0xf800 0 0 0x7>;
- interrupt-map = <
- /* IDSEL 9 */
- 0x4800 0 0 1 &pic 13 /* INT A on slot 9 is irq 13 */
- 0x4800 0 0 2 &pic 14 /* INT B on slot 9 is irq 14 */
- 0x4800 0 0 3 &pic 15 /* INT C on slot 9 is irq 15 */
- 0x4800 0 0 4 &pic 16 /* INT D on slot 9 is irq 16 */
- /* IDSEL 10 */
- 0x5000 0 0 1 &pic 14 /* INT A on slot 10 is irq 14 */
- 0x5000 0 0 2 &pic 15 /* INT B on slot 10 is irq 15 */
- 0x5000 0 0 3 &pic 16 /* INT C on slot 10 is irq 16 */
- 0x5000 0 0 4 &pic 13 /* INT D on slot 10 is irq 13 */
- /* IDSEL 11 */
- 0x5800 0 0 1 &pic 15 /* INT A on slot 11 is irq 15 */
- 0x5800 0 0 2 &pic 16 /* INT B on slot 11 is irq 16 */
- 0x5800 0 0 3 &pic 13 /* INT C on slot 11 is irq 13 */
- 0x5800 0 0 4 &pic 14 /* INT D on slot 11 is irq 14 */
- /* IDSEL 12 */
- 0x6000 0 0 1 &pic 16 /* INT A on slot 12 is irq 16 */
- 0x6000 0 0 2 &pic 13 /* INT B on slot 12 is irq 13 */
- 0x6000 0 0 3 &pic 14 /* INT C on slot 12 is irq 14 */
- 0x6000 0 0 4 &pic 15 /* INT D on slot 12 is irq 15 */
- >;
-};
diff --git a/Documentation/devicetree/bindings/pci/versatile.yaml b/Documentation/devicetree/bindings/pci/versatile.yaml
index 09748ef6b94f..d30b8849db91 100644
--- a/Documentation/devicetree/bindings/pci/versatile.yaml
+++ b/Documentation/devicetree/bindings/pci/versatile.yaml
@@ -13,7 +13,7 @@ description: |+
PCI host controller found on the ARM Versatile PB board's FPGA.
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
@@ -90,5 +90,4 @@ examples:
<0x0000 0 0 4 &sic 28>;
};
-
...
diff --git a/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt b/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
deleted file mode 100644
index 85d9b95234f7..000000000000
--- a/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-* AppliedMicro X-Gene v1 PCIe MSI controller
-
-Required properties:
-
-- compatible: should be "apm,xgene1-msi" to identify
- X-Gene v1 PCIe MSI controller block.
-- msi-controller: indicates that this is an X-Gene v1 PCIe MSI controller node
-- reg: physical base address (0x79000000) and length (0x900000) for controller
- registers. These registers include the MSI termination address and data
- registers as well as the MSI interrupt status registers.
-- reg-names: not required
-- interrupts: A list of 16 interrupt outputs of the controller, starting from
- interrupt number 0x10 to 0x1f.
-- interrupt-names: not required
-
-Each PCIe node needs to have property msi-parent that points to an MSI
-controller node
-
-Examples:
-
-SoC DTSI:
-
- + MSI node:
- msi@79000000 {
- compatible = "apm,xgene1-msi";
- msi-controller;
- reg = <0x00 0x79000000 0x0 0x900000>;
- interrupts = <0x0 0x10 0x4>
- <0x0 0x11 0x4>
- <0x0 0x12 0x4>
- <0x0 0x13 0x4>
- <0x0 0x14 0x4>
- <0x0 0x15 0x4>
- <0x0 0x16 0x4>
- <0x0 0x17 0x4>
- <0x0 0x18 0x4>
- <0x0 0x19 0x4>
- <0x0 0x1a 0x4>
- <0x0 0x1b 0x4>
- <0x0 0x1c 0x4>
- <0x0 0x1d 0x4>
- <0x0 0x1e 0x4>
- <0x0 0x1f 0x4>;
- };
-
- + PCIe controller node with msi-parent property pointing to MSI node:
- pcie0: pcie@1f2b0000 {
- device_type = "pci";
- compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */
- 0xe0 0xd0000000 0x0 0x00040000>; /* PCI config space */
- reg-names = "csr", "cfg";
- ranges = <0x01000000 0x00 0x00000000 0xe0 0x10000000 0x00 0x00010000 /* io */
- 0x02000000 0x00 0x80000000 0xe1 0x80000000 0x00 0x80000000>; /* mem */
- dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
- 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
- interrupt-map-mask = <0x0 0x0 0x0 0x7>;
- interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
- 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
- 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
- 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
- dma-coherent;
- clocks = <&pcie0clk 0>;
- msi-parent= <&msi>;
- };
diff --git a/Documentation/devicetree/bindings/pci/xgene-pci.txt b/Documentation/devicetree/bindings/pci/xgene-pci.txt
deleted file mode 100644
index 92490330dc1c..000000000000
--- a/Documentation/devicetree/bindings/pci/xgene-pci.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-* AppliedMicro X-Gene PCIe interface
-
-Required properties:
-- device_type: set to "pci"
-- compatible: should contain "apm,xgene-pcie" to identify the core.
-- reg: A list of physical base address and length for each set of controller
- registers. Must contain an entry for each entry in the reg-names
- property.
-- reg-names: Must include the following entries:
- "csr": controller configuration registers.
- "cfg": PCIe configuration space registers.
-- #address-cells: set to <3>
-- #size-cells: set to <2>
-- ranges: ranges for the outbound memory, I/O regions.
-- dma-ranges: ranges for the inbound memory regions.
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map: standard PCI properties
- to define the mapping of the PCIe interface to interrupt
- numbers.
-- clocks: from common clock binding: handle to pci clock.
-
-Optional properties:
-- status: Either "ok" or "disabled".
-- dma-coherent: Present if DMA operations are coherent
-
-Example:
-
- pcie0: pcie@1f2b0000 {
- status = "disabled";
- device_type = "pci";
- compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */
- 0xe0 0xd0000000 0x0 0x00040000>; /* PCI config space */
- reg-names = "csr", "cfg";
- ranges = <0x01000000 0x00 0x00000000 0xe0 0x10000000 0x00 0x00010000 /* io */
- 0x02000000 0x00 0x80000000 0xe1 0x80000000 0x00 0x80000000>; /* mem */
- dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000
- 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>;
- interrupt-map-mask = <0x0 0x0 0x0 0x7>;
- interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1
- 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1
- 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1
- 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>;
- dma-coherent;
- clocks = <&pcie0clk 0>;
- };
-
diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
deleted file mode 100644
index f56f8c58c5d9..000000000000
--- a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-* Xilinx NWL PCIe Root Port Bridge DT description
-
-Required properties:
-- compatible: Should contain "xlnx,nwl-pcie-2.11"
-- #address-cells: Address representation for root ports, set to <3>
-- #size-cells: Size representation for root ports, set to <2>
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- reg: Should contain Bridge, PCIe Controller registers location,
- configuration space, and length
-- reg-names: Must include the following entries:
- "breg": bridge registers
- "pcireg": PCIe controller registers
- "cfg": configuration space region
-- device_type: must be "pci"
-- interrupts: Should contain NWL PCIe interrupt
-- interrupt-names: Must include the following entries:
- "msi1, msi0": interrupt asserted when an MSI is received
- "intx": interrupt asserted when a legacy interrupt is received
- "misc": interrupt asserted when miscellaneous interrupt is received
-- interrupt-map-mask and interrupt-map: standard PCI properties to define the
- mapping of the PCI interface to interrupt numbers.
-- ranges: ranges for the PCI memory regions (I/O space region is not
- supported by hardware)
- Please refer to the standard PCI bus binding document for a more
- detailed explanation
-- msi-controller: indicates that this is MSI controller node
-- msi-parent: MSI parent of the root complex itself
-- legacy-interrupt-controller: Interrupt controller device node for Legacy
- interrupts
- - interrupt-controller: identifies the node as an interrupt controller
- - #interrupt-cells: should be set to 1
- - #address-cells: specifies the number of cells needed to encode an
- address. The value must be 0.
-
-Optional properties:
-- dma-coherent: present if DMA operations are coherent
-- clocks: Input clock specifier. Refer to common clock bindings
-
-Example:
-++++++++
-
-nwl_pcie: pcie@fd0e0000 {
- #address-cells = <3>;
- #size-cells = <2>;
- compatible = "xlnx,nwl-pcie-2.11";
- #interrupt-cells = <1>;
- msi-controller;
- device_type = "pci";
- interrupt-parent = <&gic>;
- interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
- interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
- interrupt-map-mask = <0x0 0x0 0x0 0x7>;
- interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
- <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
- <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
- <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
-
- msi-parent = <&nwl_pcie>;
- reg = <0x0 0xfd0e0000 0x0 0x1000>,
- <0x0 0xfd480000 0x0 0x1000>,
- <0x80 0x00000000 0x0 0x1000000>;
- reg-names = "breg", "pcireg", "cfg";
- ranges = <0x02000000 0x00000000 0xe0000000 0x00000000 0xe0000000 0x00000000 0x10000000 /* non-prefetchable memory */
- 0x43000000 0x00000006 0x00000000 0x00000006 0x00000000 0x00000002 0x00000000>;/* prefetchable memory */
-
- pcie_intc: legacy-interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
-
-};
diff --git a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
deleted file mode 100644
index fd57a81180a4..000000000000
--- a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-* Xilinx AXI PCIe Root Port Bridge DT description
-
-Required properties:
-- #address-cells: Address representation for root ports, set to <3>
-- #size-cells: Size representation for root ports, set to <2>
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-- compatible: Should contain "xlnx,axi-pcie-host-1.00.a"
-- reg: Should contain AXI PCIe registers location and length
-- device_type: must be "pci"
-- interrupts: Should contain AXI PCIe interrupt
-- interrupt-map-mask,
- interrupt-map: standard PCI properties to define the mapping of the
- PCI interface to interrupt numbers.
-- ranges: ranges for the PCI memory regions (I/O space region is not
- supported by hardware)
- Please refer to the standard PCI bus binding document for a more
- detailed explanation
-
-Optional properties for Zynq/Microblaze:
-- bus-range: PCI bus numbers covered
-
-Interrupt controller child node
-+++++++++++++++++++++++++++++++
-Required properties:
-- interrupt-controller: identifies the node as an interrupt controller
-- #address-cells: specifies the number of cells needed to encode an
- address. The value must be 0.
-- #interrupt-cells: specifies the number of cells needed to encode an
- interrupt source. The value must be 1.
-
-NOTE:
-The core provides a single interrupt for both INTx/MSI messages. So,
-created a interrupt controller node to support 'interrupt-map' DT
-functionality. The driver will create an IRQ domain for this map, decode
-the four INTx interrupts in ISR and route them to this domain.
-
-
-Example:
-++++++++
-Zynq:
- pci_express: axi-pcie@50000000 {
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- compatible = "xlnx,axi-pcie-host-1.00.a";
- reg = < 0x50000000 0x1000000 >;
- device_type = "pci";
- interrupts = < 0 52 4 >;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc 1>,
- <0 0 0 2 &pcie_intc 2>,
- <0 0 0 3 &pcie_intc 3>,
- <0 0 0 4 &pcie_intc 4>;
- ranges = < 0x02000000 0 0x60000000 0x60000000 0 0x10000000 >;
-
- pcie_intc: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
- };
-
-
-Microblaze:
- pci_express: axi-pcie@10000000 {
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- compatible = "xlnx,axi-pcie-host-1.00.a";
- reg = <0x10000000 0x4000000>;
- device_type = "pci";
- interrupt-parent = <&microblaze_0_intc>;
- interrupts = <1 2>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc 1>,
- <0 0 0 2 &pcie_intc 2>,
- <0 0 0 3 &pcie_intc 3>,
- <0 0 0 4 &pcie_intc 4>;
- ranges = <0x02000000 0x00000000 0x80000000 0x80000000 0x00000000 0x10000000>;
-
- pcie_intc: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
-
- };
diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
index 24ddc2855b94..9823456addea 100644
--- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
+++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml
@@ -7,16 +7,18 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: CPM Host Controller device tree for Xilinx Versal SoCs
maintainers:
- - Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
+ - Bharat Kumar Gogada <bharat.kumar.gogada@amd.com>
allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
properties:
compatible:
enum:
- xlnx,versal-cpm-host-1.00
- xlnx,versal-cpm5-host
+ - xlnx,versal-cpm5-host1
+ - xlnx,versal-cpm5nc-host
reg:
items:
@@ -48,13 +50,16 @@ properties:
interrupt-controller:
description: Interrupt controller node for handling legacy PCI interrupts.
type: object
+ additionalProperties: false
+
properties:
"#address-cells":
const: 0
+
"#interrupt-cells":
const: 1
- "interrupt-controller": true
- additionalProperties: false
+
+ interrupt-controller: true
required:
- reg
@@ -71,64 +76,62 @@ unevaluatedProperties: false
examples:
- |
-
versal {
- #address-cells = <2>;
- #size-cells = <2>;
- cpm_pcie: pcie@fca10000 {
- compatible = "xlnx,versal-cpm-host-1.00";
- device_type = "pci";
- #address-cells = <3>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- interrupts = <0 72 4>;
- interrupt-parent = <&gic>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
- <0 0 0 2 &pcie_intc_0 1>,
- <0 0 0 3 &pcie_intc_0 2>,
- <0 0 0 4 &pcie_intc_0 3>;
- bus-range = <0x00 0xff>;
- ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>,
- <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>;
- msi-map = <0x0 &its_gic 0x0 0x10000>;
- reg = <0x0 0xfca10000 0x0 0x1000>,
- <0x6 0x00000000 0x0 0x10000000>;
- reg-names = "cpm_slcr", "cfg";
- pcie_intc_0: interrupt-controller {
- #address-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- };
- };
-
- cpm5_pcie: pcie@fcdd0000 {
- compatible = "xlnx,versal-cpm5-host";
- device_type = "pci";
- #address-cells = <3>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- interrupts = <0 72 4>;
- interrupt-parent = <&gic>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 &pcie_intc_1 0>,
- <0 0 0 2 &pcie_intc_1 1>,
- <0 0 0 3 &pcie_intc_1 2>,
- <0 0 0 4 &pcie_intc_1 3>;
- bus-range = <0x00 0xff>;
- ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>,
- <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>;
- msi-map = <0x0 &its_gic 0x0 0x10000>;
- reg = <0x00 0xfcdd0000 0x00 0x1000>,
- <0x06 0x00000000 0x00 0x1000000>,
- <0x00 0xfce20000 0x00 0x1000000>;
- reg-names = "cpm_slcr", "cfg", "cpm_csr";
-
- pcie_intc_1: interrupt-controller {
- #address-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- };
- };
-
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@fca10000 {
+ compatible = "xlnx,versal-cpm-host-1.00";
+ device_type = "pci";
+ #address-cells = <3>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ interrupts = <0 72 4>;
+ interrupt-parent = <&gic>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
+ <0 0 0 2 &pcie_intc_0 1>,
+ <0 0 0 3 &pcie_intc_0 2>,
+ <0 0 0 4 &pcie_intc_0 3>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x02000000 0x0 0xe0010000 0x0 0xe0010000 0x0 0x10000000>,
+ <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>;
+ msi-map = <0x0 &its_gic 0x0 0x10000>;
+ reg = <0x0 0xfca10000 0x0 0x1000>,
+ <0x6 0x00000000 0x0 0x10000000>;
+ reg-names = "cpm_slcr", "cfg";
+ pcie_intc_0: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+
+ pcie@fcdd0000 {
+ compatible = "xlnx,versal-cpm5-host";
+ device_type = "pci";
+ #address-cells = <3>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ interrupts = <0 72 4>;
+ interrupt-parent = <&gic>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc_1 0>,
+ <0 0 0 2 &pcie_intc_1 1>,
+ <0 0 0 3 &pcie_intc_1 2>,
+ <0 0 0 4 &pcie_intc_1 3>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>,
+ <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>;
+ msi-map = <0x0 &its_gic 0x0 0x10000>;
+ reg = <0x00 0xfcdd0000 0x00 0x1000>,
+ <0x06 0x00000000 0x00 0x1000000>,
+ <0x00 0xfce20000 0x00 0x1000000>;
+ reg-names = "cpm_slcr", "cfg", "cpm_csr";
+
+ pcie_intc_1: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml b/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml
new file mode 100644
index 000000000000..fb87b960a250
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xlnx,axi-pcie-host.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/xlnx,axi-pcie-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx AXI PCIe Root Port Bridge
+
+maintainers:
+ - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ const: xlnx,axi-pcie-host-1.00.a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ranges:
+ items:
+ - description: |
+ ranges for the PCI memory regions (I/O space region is not
+ supported by hardware)
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller:
+ description: identifies the node as an interrupt controller
+ type: object
+ properties:
+ interrupt-controller: true
+
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ const: 1
+
+ required:
+ - interrupt-controller
+ - "#address-cells"
+ - "#interrupt-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - interrupts
+ - interrupt-map
+ - "#interrupt-cells"
+ - interrupt-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pcie@50000000 {
+ compatible = "xlnx,axi-pcie-host-1.00.a";
+ reg = <0x50000000 0x1000000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc 1>,
+ <0 0 0 2 &pcie_intc 2>,
+ <0 0 0 3 &pcie_intc 3>,
+ <0 0 0 4 &pcie_intc 4>;
+ ranges = <0x02000000 0 0x60000000 0x60000000 0 0x10000000>;
+ pcie_intc: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml b/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
new file mode 100644
index 000000000000..9de3c09efb6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xlnx,nwl-pcie.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/xlnx,nwl-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx NWL PCIe Root Port Bridge
+
+maintainers:
+ - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+ - $ref: /schemas/interrupt-controller/msi-controller.yaml#
+
+properties:
+ compatible:
+ const: xlnx,nwl-pcie-2.11
+
+ reg:
+ items:
+ - description: PCIe bridge registers location.
+ - description: PCIe Controller registers location.
+ - description: PCIe Configuration space region.
+
+ reg-names:
+ items:
+ - const: breg
+ - const: pcireg
+ - const: cfg
+
+ interrupts:
+ items:
+ - description: interrupt asserted when miscellaneous interrupt is received
+ - description: unused interrupt(dummy)
+ - description: interrupt asserted when a legacy interrupt is received
+ - description: msi1 interrupt asserted when an MSI is received
+ - description: msi0 interrupt asserted when an MSI is received
+
+ interrupt-names:
+ items:
+ - const: misc
+ - const: dummy
+ - const: intx
+ - const: msi1
+ - const: msi0
+
+ interrupt-map-mask:
+ items:
+ - const: 0
+ - const: 0
+ - const: 0
+ - const: 7
+
+ "#interrupt-cells":
+ const: 1
+
+ msi-parent:
+ description: MSI controller the device is capable of using.
+
+ interrupt-map:
+ maxItems: 4
+
+ phys:
+ minItems: 1
+ maxItems: 4
+ description: One phy per logical lane, in order
+
+ power-domains:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent:
+ description: optional, only needed if DMA operations are coherent.
+
+ clocks:
+ maxItems: 1
+ description: optional, input clock specifier.
+
+ legacy-interrupt-controller:
+ description: Interrupt controller node for handling legacy PCI interrupts.
+ type: object
+ properties:
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller: true
+
+ required:
+ - "#address-cells"
+ - "#interrupt-cells"
+ - interrupt-controller
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - "#interrupt-cells"
+ - interrupt-map
+ - interrupt-map-mask
+ - msi-controller
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ nwl_pcie: pcie@fd0e0000 {
+ compatible = "xlnx,nwl-pcie-2.11";
+ reg = <0x0 0xfd0e0000 0x0 0x1000>,
+ <0x0 0xfd480000 0x0 0x1000>,
+ <0x80 0x00000000 0x0 0x10000000>;
+ reg-names = "breg", "pcireg", "cfg";
+ ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>,
+ <0x43000000 0x00000006 0x0 0x00000006 0x0 0x00000002 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ msi-controller;
+ device_type = "pci";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 116 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 115 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "misc", "dummy", "intx", "msi1", "msi0";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+ msi-parent = <&nwl_pcie>;
+ phys = <&psgtr 0 PHY_TYPE_PCIE 0 0>;
+ power-domains = <&zynqmp_firmware PD_PCIE>;
+ iommus = <&smmu 0x4d0>;
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml b/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml
new file mode 100644
index 000000000000..f1efd919c351
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xlnx,xdma-host.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/xlnx,xdma-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx XDMA PL PCIe Root Port Bridge
+
+maintainers:
+ - Thippeswamy Havalige <thippeswamy.havalige@amd.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-host-bridge.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,xdma-host-3.00
+ - xlnx,qdma-host-3.00
+
+ reg:
+ items:
+ - description: configuration region and XDMA bridge register.
+ - description: QDMA bridge register.
+ minItems: 1
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: breg
+ minItems: 1
+
+ ranges:
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: interrupt asserted when miscellaneous interrupt is received.
+ - description: msi0 interrupt asserted when an MSI is received.
+ - description: msi1 interrupt asserted when an MSI is received.
+
+ interrupt-names:
+ items:
+ - const: misc
+ - const: msi0
+ - const: msi1
+
+ interrupt-map-mask:
+ items:
+ - const: 0
+ - const: 0
+ - const: 0
+ - const: 7
+
+ interrupt-map:
+ maxItems: 4
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-controller:
+ description: identifies the node as an interrupt controller
+ type: object
+ properties:
+ interrupt-controller: true
+
+ "#address-cells":
+ const: 0
+
+ "#interrupt-cells":
+ const: 1
+
+ required:
+ - interrupt-controller
+ - "#address-cells"
+ - "#interrupt-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ranges
+ - interrupts
+ - interrupt-map
+ - interrupt-map-mask
+ - "#interrupt-cells"
+ - interrupt-controller
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,qdma-host-3.00
+then:
+ properties:
+ reg:
+ minItems: 2
+ reg-names:
+ minItems: 2
+ required:
+ - reg-names
+else:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@a0000000 {
+ compatible = "xlnx,xdma-host-3.00";
+ reg = <0x0 0xa0000000 0x0 0x10000000>;
+ ranges = <0x2000000 0x0 0xb0000000 0x0 0xb0000000 0x0 0x1000000>,
+ <0x43000000 0x5 0x0 0x5 0x0 0x0 0x1000000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "misc", "msi0", "msi1";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0 0 0 1 &pcie_intc_0 0>,
+ <0 0 0 2 &pcie_intc_0 1>,
+ <0 0 0 3 &pcie_intc_0 2>,
+ <0 0 0 4 &pcie_intc_0 3>;
+ pcie_intc_0: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml b/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml
new file mode 100644
index 000000000000..087e02a9ade3
--- /dev/null
+++ b/Documentation/devicetree/bindings/peci/nuvoton,npcm-peci.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/peci/nuvoton,npcm-peci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton PECI Bus
+
+maintainers:
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+allOf:
+ - $ref: peci-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-peci
+ - nuvoton,npcm845-peci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description:
+ Clock source for PECI controller. Should reference the APB clock.
+ maxItems: 1
+
+ cmd-timeout-ms:
+ minimum: 1
+ maximum: 1000
+ default: 1000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ peci-controller@f0100000 {
+ compatible = "nuvoton,npcm750-peci";
+ reg = <0xf0100000 0x200>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM7XX_CLK_APB3>;
+ cmd-timeout-ms = <1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.yaml b/Documentation/devicetree/bindings/peci/peci-aspeed.yaml
index 1e68a801a92a..b01e0c8b963d 100644
--- a/Documentation/devicetree/bindings/peci/peci-aspeed.yaml
+++ b/Documentation/devicetree/bindings/peci/peci-aspeed.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/peci/peci-aspeed.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Aspeed PECI Bus Device Tree Bindings
+title: Aspeed PECI Bus
maintainers:
- Iwona Winiarska <iwona.winiarska@intel.com>
diff --git a/Documentation/devicetree/bindings/peci/peci-controller.yaml b/Documentation/devicetree/bindings/peci/peci-controller.yaml
index bbc3d3f3a929..d7853291b060 100644
--- a/Documentation/devicetree/bindings/peci/peci-controller.yaml
+++ b/Documentation/devicetree/bindings/peci/peci-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/peci/peci-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic Device Tree Bindings for PECI
+title: Generic for PECI
maintainers:
- Iwona Winiarska <iwona.winiarska@intel.com>
diff --git a/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
new file mode 100644
index 000000000000..4adab0149108
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/amlogic,g12-ddr-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic G12 DDR performance monitor
+
+maintainers:
+ - Jiucheng Xu <jiucheng.xu@amlogic.com>
+
+description: |
+ Amlogic G12 series SoC integrate DDR bandwidth monitor.
+ A timer is inside and can generate interrupt when timeout.
+ The bandwidth is counted in the timer ISR. Different platform
+ has different subset of event format attribute.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,g12a-ddr-pmu
+ - amlogic,g12b-ddr-pmu
+ - amlogic,sm1-ddr-pmu
+
+ reg:
+ items:
+ - description: DMC bandwidth register space.
+ - description: DMC PLL register space.
+
+ interrupts:
+ items:
+ - description: The IRQ of the inside timer timeout.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pmu {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pmu@ff638000 {
+ compatible = "amlogic,g12a-ddr-pmu";
+ reg = <0x0 0xff638000 0x0 0x100>,
+ <0x0 0xff638c00 0x0 0x100>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/perf/apm,xgene-pmu.yaml b/Documentation/devicetree/bindings/perf/apm,xgene-pmu.yaml
new file mode 100644
index 000000000000..314048a2a134
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/apm,xgene-pmu.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/apm,xgene-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene SoC PMU
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+description: |
+ This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
+ The following PMU devices are supported:
+
+ L3C - L3 cache controller
+ IOB - IO bridge
+ MCB - Memory controller bridge
+ MC - Memory controller
+
+properties:
+ compatible:
+ enum:
+ - apm,xgene-pmu
+ - apm,xgene-pmu-v2
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges: true
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regmap-csw:
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ regmap-mcba:
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ regmap-mcbb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - regmap-csw
+ - regmap-mcba
+ - regmap-mcbb
+ - reg
+ - interrupts
+
+additionalProperties:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - apm,xgene-pmu-l3c
+ - apm,xgene-pmu-iob
+ - apm,xgene-pmu-mcb
+ - apm,xgene-pmu-mc
+
+ reg:
+ maxItems: 1
+
+ enable-bit-index:
+ description:
+ Specifies which bit enables the associated resource in MCB or MC subnodes.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 31
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pmu@78810000 {
+ compatible = "apm,xgene-pmu-v2";
+ reg = <0x0 0x78810000 0x0 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ regmap-csw = <&csw>;
+ regmap-mcba = <&mcba>;
+ regmap-mcbb = <&mcbb>;
+ interrupts = <0x0 0x22 0x4>;
+
+ pmul3c@7e610000 {
+ compatible = "apm,xgene-pmu-l3c";
+ reg = <0x0 0x7e610000 0x0 0x1000>;
+ };
+
+ pmuiob@7e940000 {
+ compatible = "apm,xgene-pmu-iob";
+ reg = <0x0 0x7e940000 0x0 0x1000>;
+ };
+
+ pmucmcb@7e710000 {
+ compatible = "apm,xgene-pmu-mcb";
+ reg = <0x0 0x7e710000 0x0 0x1000>;
+ enable-bit-index = <0>;
+ };
+
+ pmucmcb@7e730000 {
+ compatible = "apm,xgene-pmu-mcb";
+ reg = <0x0 0x7e730000 0x0 0x1000>;
+ enable-bit-index = <1>;
+ };
+
+ pmucmc@7e810000 {
+ compatible = "apm,xgene-pmu-mc";
+ reg = <0x0 0x7e810000 0x0 0x1000>;
+ enable-bit-index = <0>;
+ };
+
+ pmucmc@7e850000 {
+ compatible = "apm,xgene-pmu-mc";
+ reg = <0x0 0x7e850000 0x0 0x1000>;
+ enable-bit-index = <1>;
+ };
+
+ pmucmc@7e890000 {
+ compatible = "apm,xgene-pmu-mc";
+ reg = <0x0 0x7e890000 0x0 0x1000>;
+ enable-bit-index = <2>;
+ };
+
+ pmucmc@7e8d0000 {
+ compatible = "apm,xgene-pmu-mc";
+ reg = <0x0 0x7e8d0000 0x0 0x1000>;
+ enable-bit-index = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
deleted file mode 100644
index afb11cf693c0..000000000000
--- a/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-* APM X-Gene SoC PMU bindings
-
-This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
-The following PMU devices are supported:
-
- L3C - L3 cache controller
- IOB - IO bridge
- MCB - Memory controller bridge
- MC - Memory controller
-
-The following section describes the SoC PMU DT node binding.
-
-Required properties:
-- compatible : Shall be "apm,xgene-pmu" for revision 1 or
- "apm,xgene-pmu-v2" for revision 2.
-- regmap-csw : Regmap of the CPU switch fabric (CSW) resource.
-- regmap-mcba : Regmap of the MCB-A (memory bridge) resource.
-- regmap-mcbb : Regmap of the MCB-B (memory bridge) resource.
-- reg : First resource shall be the CPU bus PMU resource.
-- interrupts : Interrupt-specifier for PMU IRQ.
-
-Required properties for L3C subnode:
-- compatible : Shall be "apm,xgene-pmu-l3c".
-- reg : First resource shall be the L3C PMU resource.
-
-Required properties for IOB subnode:
-- compatible : Shall be "apm,xgene-pmu-iob".
-- reg : First resource shall be the IOB PMU resource.
-
-Required properties for MCB subnode:
-- compatible : Shall be "apm,xgene-pmu-mcb".
-- reg : First resource shall be the MCB PMU resource.
-- enable-bit-index : The bit indicates if the according MCB is enabled.
-
-Required properties for MC subnode:
-- compatible : Shall be "apm,xgene-pmu-mc".
-- reg : First resource shall be the MC PMU resource.
-- enable-bit-index : The bit indicates if the according MC is enabled.
-
-Example:
- csw: csw@7e200000 {
- compatible = "apm,xgene-csw", "syscon";
- reg = <0x0 0x7e200000 0x0 0x1000>;
- };
-
- mcba: mcba@7e700000 {
- compatible = "apm,xgene-mcb", "syscon";
- reg = <0x0 0x7e700000 0x0 0x1000>;
- };
-
- mcbb: mcbb@7e720000 {
- compatible = "apm,xgene-mcb", "syscon";
- reg = <0x0 0x7e720000 0x0 0x1000>;
- };
-
- pmu: pmu@78810000 {
- compatible = "apm,xgene-pmu-v2";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- regmap-csw = <&csw>;
- regmap-mcba = <&mcba>;
- regmap-mcbb = <&mcbb>;
- reg = <0x0 0x78810000 0x0 0x1000>;
- interrupts = <0x0 0x22 0x4>;
-
- pmul3c@7e610000 {
- compatible = "apm,xgene-pmu-l3c";
- reg = <0x0 0x7e610000 0x0 0x1000>;
- };
-
- pmuiob@7e940000 {
- compatible = "apm,xgene-pmu-iob";
- reg = <0x0 0x7e940000 0x0 0x1000>;
- };
-
- pmucmcb@7e710000 {
- compatible = "apm,xgene-pmu-mcb";
- reg = <0x0 0x7e710000 0x0 0x1000>;
- enable-bit-index = <0>;
- };
-
- pmucmcb@7e730000 {
- compatible = "apm,xgene-pmu-mcb";
- reg = <0x0 0x7e730000 0x0 0x1000>;
- enable-bit-index = <1>;
- };
-
- pmucmc@7e810000 {
- compatible = "apm,xgene-pmu-mc";
- reg = <0x0 0x7e810000 0x0 0x1000>;
- enable-bit-index = <0>;
- };
-
- pmucmc@7e850000 {
- compatible = "apm,xgene-pmu-mc";
- reg = <0x0 0x7e850000 0x0 0x1000>;
- enable-bit-index = <1>;
- };
-
- pmucmc@7e890000 {
- compatible = "apm,xgene-pmu-mc";
- reg = <0x0 0x7e890000 0x0 0x1000>;
- enable-bit-index = <2>;
- };
-
- pmucmc@7e8d0000 {
- compatible = "apm,xgene-pmu-mc";
- reg = <0x0 0x7e8d0000 0x0 0x1000>;
- enable-bit-index = <3>;
- };
- };
diff --git a/Documentation/devicetree/bindings/perf/arm,cmn.yaml b/Documentation/devicetree/bindings/perf/arm,cmn.yaml
index 2e51072e794a..0e9d665584e6 100644
--- a/Documentation/devicetree/bindings/perf/arm,cmn.yaml
+++ b/Documentation/devicetree/bindings/perf/arm,cmn.yaml
@@ -16,6 +16,7 @@ properties:
- arm,cmn-600
- arm,cmn-650
- arm,cmn-700
+ - arm,cmn-s3
- arm,ci-700
reg:
diff --git a/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
new file mode 100644
index 000000000000..985b62990f80
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,coresight-pmu.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,coresight-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Coresight Performance Monitoring Unit Architecture
+
+maintainers:
+ - Robin Murphy <robin.murphy@arm.com>
+
+properties:
+ compatible:
+ const: arm,coresight-pmu
+
+ reg:
+ items:
+ - description: Register page 0
+ - description: Register page 1, if the PMU implements the dual-page extension
+ minItems: 1
+
+ interrupts:
+ items:
+ - description: Overflow interrupt
+
+ cpus:
+ description: If the PMU is associated with a particular CPU or subset of CPUs,
+ array of phandles to the appropriate CPU node(s)
+
+ reg-io-width:
+ description: Granularity at which PMU register accesses are single-copy atomic
+ default: 4
+ enum: [4, 8]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml
index c87821be158b..a740378ed592 100644
--- a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml
+++ b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml
@@ -32,11 +32,8 @@ properties:
- description: nCLUSTERPMUIRQ interrupt
cpus:
- $ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
maxItems: 12
- items:
- maxItems: 1
description: List of phandles for the CPUs connected to this DSU instance.
required:
diff --git a/Documentation/devicetree/bindings/perf/arm,ni.yaml b/Documentation/devicetree/bindings/perf/arm,ni.yaml
new file mode 100644
index 000000000000..d66fffa256d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,ni.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,ni.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm NI (Network-on-Chip Interconnect) Performance Monitors
+
+maintainers:
+ - Robin Murphy <robin.murphy@arm.com>
+
+properties:
+ compatible:
+ const: arm,ni-700
+
+ reg:
+ items:
+ - description: Complete configuration register space
+
+ interrupts:
+ minItems: 1
+ maxItems: 32
+ description: Overflow interrupts, one per clock domain, in order of domain ID
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
index 80a92385367e..103e4aec2439 100644
--- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
+++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/perf/fsl-imx-ddr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale(NXP) IMX8 DDR performance monitor
+title: Freescale(NXP) IMX8/9 DDR performance monitor
maintainers:
- Frank Li <frank.li@nxp.com>
@@ -14,11 +14,13 @@ properties:
oneOf:
- enum:
- fsl,imx8-ddr-pmu
+ - fsl,imx8dxl-db-pmu
- fsl,imx8m-ddr-pmu
- fsl,imx8mq-ddr-pmu
- fsl,imx8mm-ddr-pmu
- fsl,imx8mn-ddr-pmu
- fsl,imx8mp-ddr-pmu
+ - fsl,imx93-ddr-pmu
- items:
- enum:
- fsl,imx8mm-ddr-pmu
@@ -26,6 +28,18 @@ properties:
- fsl,imx8mq-ddr-pmu
- fsl,imx8mp-ddr-pmu
- const: fsl,imx8m-ddr-pmu
+ - items:
+ - enum:
+ - fsl,imx8dxl-ddr-pmu
+ - fsl,imx8qm-ddr-pmu
+ - fsl,imx8qxp-ddr-pmu
+ - const: fsl,imx8-ddr-pmu
+ - items:
+ - enum:
+ - fsl,imx91-ddr-pmu
+ - fsl,imx94-ddr-pmu
+ - fsl,imx95-ddr-pmu
+ - const: fsl,imx93-ddr-pmu
reg:
maxItems: 1
@@ -33,6 +47,14 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: cnt
+
required:
- compatible
- reg
@@ -40,6 +62,21 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8dxl-db-pmu
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
new file mode 100644
index 000000000000..d01c677ad3c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/riscv,pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V SBI PMU events
+
+maintainers:
+ - Atish Patra <atishp@rivosinc.com>
+
+description: |
+ The SBI PMU extension allows supervisor software to configure, start and
+ stop any performance counter at anytime. Thus, a user can leverage all
+ capabilities of performance analysis tools, such as perf, if the SBI PMU
+ extension is enabled. The following constraints apply:
+
+ The platform must provide information about PMU event to counter mappings
+ either via device tree or another way, specific to the platform.
+ Without the event to counter mappings, the SBI PMU extension cannot be used.
+
+ Platforms should provide information about the PMU event selector values
+ that should be encoded in the expected value of MHPMEVENTx while configuring
+ MHPMCOUNTERx for that specific event. The can either be done via device tree
+ or another way, specific to the platform.
+ The exact value to be written to MHPMEVENTx is completely dependent on the
+ platform.
+
+ For information on the SBI specification see the section "Performance
+ Monitoring Unit Extension" of:
+ https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc
+
+properties:
+ compatible:
+ const: riscv,pmu
+
+ riscv,event-to-mhpmevent:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Represents an ONE-to-ONE mapping between a PMU event and the event
+ selector value that the platform expects to be written to the MHPMEVENTx
+ CSR for that event.
+ The mapping is encoded in an matrix format where each element represents
+ an event.
+ This property shouldn't encode any raw hardware event.
+ items:
+ items:
+ - description: event_idx, a 20-bit wide encoding of the event type and
+ code. Refer to the SBI specification for a complete description of
+ the event types and codes.
+ - description: upper 32 bits of the event selector value for MHPMEVENTx
+ - description: lower 32 bits of the event selector value for MHPMEVENTx
+
+ riscv,event-to-mhpmcounters:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Represents a MANY-to-MANY mapping between a range of events and all the
+ MHPMCOUNTERx in a bitmap format that can be used to monitor these range
+ of events. The information is encoded in an matrix format where each
+ element represents a certain range of events and corresponding counters.
+ This property shouldn't encode any raw event.
+ items:
+ items:
+ - description: first event_idx of the range of events
+ - description: last event_idx of the range of events
+ - description: bitmap of MHPMCOUNTERx for this event
+
+ riscv,raw-event-to-mhpmcounters:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Represents an ONE-to-MANY or MANY-to-MANY mapping between the rawevent(s)
+ and all the MHPMCOUNTERx in a bitmap format that can be used to monitor
+ that raw event.
+ The encoding of the raw events are platform specific. The information is
+ encoded in a matrix format where each element represents the specific raw
+ event(s).
+ If a platform directly encodes each raw PMU event as a unique ID, the
+ value of variant must be 0xffffffff_ffffffff.
+ items:
+ items:
+ - description:
+ upper 32 invariant bits for the range of events
+ - description:
+ lower 32 invariant bits for the range of events
+ - description:
+ upper 32 bits of the variant bit mask for the range of events
+ - description:
+ lower 32 bits of the variant bit mask for the range of events
+ - description:
+ bitmap of all MHPMCOUNTERx that can monitor the range of events
+
+dependencies:
+ riscv,event-to-mhpmevent: [ "riscv,event-to-mhpmcounters" ]
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pmu {
+ compatible = "riscv,pmu";
+ riscv,event-to-mhpmevent = <0x0000B 0x0000 0x0001>;
+ riscv,event-to-mhpmcounters = <0x00001 0x00001 0x00000001>,
+ <0x00002 0x00002 0x00000004>,
+ <0x00003 0x0000A 0x00000ff8>,
+ <0x10000 0x10033 0x000ff000>;
+ riscv,raw-event-to-mhpmcounters =
+ /* For event ID 0x0002 */
+ <0x0000 0x0002 0xffffffff 0xffffffff 0x00000f8>,
+ /* For event ID 0-4 */
+ <0x0 0x0 0xffffffff 0xfffffff0 0x00000ff0>,
+ /* For event ID 0xffffffff0000000f - 0xffffffff000000ff */
+ <0xffffffff 0x0 0xffffffff 0xffffff0f 0x00000ff0>;
+ };
+
+ - |
+ /*
+ * For HiFive Unmatched board the encodings can be found here
+ * https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf
+ *
+ * This example also binds standard SBI PMU hardware IDs to U74 PMU event
+ * codes, U74 uses a bitfield for events encoding, so several U74 events
+ * can be bound to a single perf ID.
+ * See SBI PMU hardware IDs in arch/riscv/include/asm/sbi.h
+ */
+ pmu {
+ compatible = "riscv,pmu";
+ riscv,event-to-mhpmevent =
+ /* SBI_PMU_HW_CACHE_REFERENCES -> Instruction or Data cache/ITIM busy */
+ <0x00003 0x00000000 0x1801>,
+ /* SBI_PMU_HW_CACHE_MISSES -> Instruction or Data cache miss or MMIO access */
+ <0x00004 0x00000000 0x0302>,
+ /* SBI_PMU_HW_BRANCH_INSTRUCTIONS -> Conditional branch retired */
+ <0x00005 0x00000000 0x4000>,
+ /* SBI_PMU_HW_BRANCH_MISSES -> Branch or jump misprediction */
+ <0x00006 0x00000000 0x6001>,
+ /* L1D_READ_MISS -> Data cache miss or MMIO access */
+ <0x10001 0x00000000 0x0202>,
+ /* L1D_WRITE_ACCESS -> Data cache write-back */
+ <0x10002 0x00000000 0x0402>,
+ /* L1I_READ_ACCESS -> Instruction cache miss */
+ <0x10009 0x00000000 0x0102>,
+ /* LL_READ_MISS -> UTLB miss */
+ <0x10011 0x00000000 0x2002>,
+ /* DTLB_READ_MISS -> Data TLB miss */
+ <0x10019 0x00000000 0x1002>,
+ /* ITLB_READ_MISS-> Instruction TLB miss */
+ <0x10021 0x00000000 0x0802>;
+ riscv,event-to-mhpmcounters = <0x00003 0x00006 0x18>,
+ <0x10001 0x10002 0x18>,
+ <0x10009 0x10009 0x18>,
+ <0x10011 0x10011 0x18>,
+ <0x10019 0x10019 0x18>,
+ <0x10021 0x10021 0x18>;
+ riscv,raw-event-to-mhpmcounters = <0x0 0x0 0xffffffff 0xfc0000ff 0x18>,
+ <0x0 0x1 0xffffffff 0xfff800ff 0x18>,
+ <0x0 0x2 0xffffffff 0xffffe0ff 0x18>;
+ };
diff --git a/Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml b/Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml
new file mode 100644
index 000000000000..915c6b814026
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/starfive,jh8100-starlink-pmu.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/starfive,jh8100-starlink-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH8100 StarLink PMU
+
+maintainers:
+ - Ji Sheng Teoh <jisheng.teoh@starfivetech.com>
+
+description:
+ StarFive's JH8100 StarLink PMU integrates one or more CPU cores with a
+ shared L3 memory system. The PMU support overflow interrupt, up to
+ 16 programmable 64bit event counters, and an independent 64bit cycle
+ counter. StarFive's JH8100 StarLink PMU is accessed via MMIO.
+
+properties:
+ compatible:
+ const: starfive,jh8100-starlink-pmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pmu@12900000 {
+ compatible = "starfive,jh8100-starlink-pmu";
+ reg = <0x0 0x12900000 0x0 0x10000>;
+ interrupts = <34>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml
new file mode 100644
index 000000000000..98fcb1b364de
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/airoha,en7581-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 PCI-Express PHY
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The PCIe PHY supports physical layer functionality for PCIe Gen2/Gen3 port.
+
+properties:
+ compatible:
+ const: airoha,en7581-pcie-phy
+
+ reg:
+ items:
+ - description: PCIE analog base address
+ - description: PCIE lane0 base address
+ - description: PCIE lane1 base address
+ - description: PCIE lane0 detection time base address
+ - description: PCIE lane1 detection time base address
+ - description: PCIE Rx AEQ base address
+
+ reg-names:
+ items:
+ - const: csr-2l
+ - const: pma0
+ - const: pma1
+ - const: p0-xr-dtime
+ - const: p1-xr-dtime
+ - const: rx-aeq
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/phy/phy.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ phy@11e80000 {
+ compatible = "airoha,en7581-pcie-phy";
+ #phy-cells = <0>;
+ reg = <0x0 0x1fa5a000 0x0 0xfff>,
+ <0x0 0x1fa5b000 0x0 0xfff>,
+ <0x0 0x1fa5c000 0x0 0xfff>,
+ <0x0 0x1fc10044 0x0 0x4>,
+ <0x0 0x1fc30044 0x0 0x4>,
+ <0x0 0x1fc15030 0x0 0x104>;
+ reg-names = "csr-2l", "pma0", "pma1",
+ "p0-xr-dtime", "p1-xr-dtime",
+ "rx-aeq";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun4i-a10-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun4i-a10-usb-phy.yaml
index 77606c899fe2..4fff091bd534 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun4i-a10-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun4i-a10-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun4i-a10-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 USB PHY Device Tree Bindings
+title: Allwinner A10 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml
index 0fa4b32b097e..580c3296a18d 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun50i-a64-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A64 USB PHY Device Tree Bindings
+title: Allwinner A64 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -15,9 +15,15 @@ properties:
const: 1
compatible:
- enum:
- - allwinner,sun20i-d1-usb-phy
- - allwinner,sun50i-a64-usb-phy
+ oneOf:
+ - enum:
+ - allwinner,sun20i-d1-usb-phy
+ - allwinner,sun50i-a64-usb-phy
+ - items:
+ - enum:
+ - allwinner,sun50i-a100-usb-phy
+ - allwinner,sun55i-a523-usb-phy
+ - const: allwinner,sun20i-d1-usb-phy
reg:
items:
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb-phy.yaml
index e632140722a2..4480fdedd669 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun50i-h6-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner H6 USB PHY Device Tree Bindings
+title: Allwinner H6 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml
index c03b83103e87..cf4eed230565 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Ondrej Jirman <megous@megous.com>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/allwinner,sun50i-h6-usb3-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/allwinner,sun50i-h6-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner H6 USB3 PHY
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun5i-a13-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun5i-a13-usb-phy.yaml
index 5bad9b06e2e7..1563e3df3052 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun5i-a13-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun5i-a13-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun5i-a13-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A13 USB PHY Device Tree Bindings
+title: Allwinner A13 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
index 22636c9fdab8..6a4fd4929959 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun6i-a31-mipi-dphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 MIPI D-PHY Controller Device Tree Bindings
+title: Allwinner A31 MIPI D-PHY Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -17,13 +17,20 @@ properties:
compatible:
oneOf:
- const: allwinner,sun6i-a31-mipi-dphy
+ - const: allwinner,sun50i-a100-mipi-dphy
- items:
- const: allwinner,sun50i-a64-mipi-dphy
- const: allwinner,sun6i-a31-mipi-dphy
+ - items:
+ - const: allwinner,sun20i-d1-mipi-dphy
+ - const: allwinner,sun50i-a100-mipi-dphy
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
clocks:
items:
- description: Bus Clock
@@ -38,7 +45,7 @@ properties:
maxItems: 1
allwinner,direction:
- $ref: '/schemas/types.yaml#/definitions/string'
+ $ref: /schemas/types.yaml#/definitions/string
description: |
Direction of the D-PHY:
- "rx" for receiving (e.g. when used with MIPI CSI-2);
@@ -53,6 +60,7 @@ required:
- "#phy-cells"
- compatible
- reg
+ - interrupts
- clocks
- clock-names
- resets
@@ -61,9 +69,12 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
dphy0: d-phy@1ca1000 {
compatible = "allwinner,sun6i-a31-mipi-dphy";
reg = <0x01ca1000 0x1000>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu 23>, <&ccu 97>;
clock-names = "bus", "mod";
resets = <&ccu 4>;
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-usb-phy.yaml
index 922b4665e00d..4897a3d2fbc3 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun6i-a31-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 USB PHY Device Tree Bindings
+title: Allwinner A31 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-a23-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-a23-usb-phy.yaml
index a94019efc2f3..99de9c6889a0 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-a23-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-a23-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun8i-a23-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A23 USB PHY Device Tree Bindings
+title: Allwinner A23 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-a83t-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-a83t-usb-phy.yaml
index 33f3ddc0492d..73438d84de50 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-a83t-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-a83t-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun8i-a83t-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A83t USB PHY Device Tree Bindings
+title: Allwinner A83t USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
index e288450e0844..2df012d13655 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun8i-h3-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner H3 USB PHY Device Tree Bindings
+title: Allwinner H3 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -36,18 +36,22 @@ properties:
- const: pmu3
clocks:
+ minItems: 4
items:
- description: USB OTG PHY bus clock
- description: USB Host 0 PHY bus clock
- description: USB Host 1 PHY bus clock
- description: USB Host 2 PHY bus clock
+ - description: PMU clock for host port 2
clock-names:
+ minItems: 4
items:
- const: usb0_phy
- const: usb1_phy
- const: usb2_phy
- const: usb3_phy
+ - const: pmu2_clk
resets:
items:
@@ -96,6 +100,28 @@ required:
- resets
- reset-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun50i-h616-usb-phy
+ then:
+ properties:
+ clocks:
+ minItems: 5
+
+ clock-names:
+ minItems: 5
+ else:
+ properties:
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ maxItems: 4
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-r40-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-r40-usb-phy.yaml
index d947e50a49d2..2dd31630c13e 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-r40-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-r40-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun8i-r40-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner R40 USB PHY Device Tree Bindings
+title: Allwinner R40 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-v3s-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-v3s-usb-phy.yaml
index a2836c296cc4..395d33855d48 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-v3s-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-v3s-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun8i-v3s-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner V3s USB PHY Device Tree Bindings
+title: Allwinner V3s USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun9i-a80-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun9i-a80-usb-phy.yaml
index 2eb493fa64fd..bd9445f6f130 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun9i-a80-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun9i-a80-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/allwinner,sun9i-a80-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A80 USB PHY Device Tree Bindings
+title: Allwinner A80 USB PHY
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml
new file mode 100644
index 000000000000..948839499235
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-phy.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/allwinner,suniv-f1c100s-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner F1C100s USB PHY
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <mripard@kernel.org>
+
+properties:
+ "#phy-cells":
+ const: 1
+
+ compatible:
+ const: allwinner,suniv-f1c100s-usb-phy
+
+ reg:
+ maxItems: 1
+ description: PHY Control registers
+
+ reg-names:
+ const: phy_ctrl
+
+ clocks:
+ maxItems: 1
+ description: USB OTG PHY bus clock
+
+ clock-names:
+ const: usb0_phy
+
+ resets:
+ maxItems: 1
+ description: USB OTG reset
+
+ reset-names:
+ const: usb0_reset
+
+ usb0_id_det-gpios:
+ maxItems: 1
+ description: GPIO to the USB OTG ID pin
+
+ usb0_vbus_det-gpios:
+ maxItems: 1
+ description: GPIO to the USB OTG VBUS detect pin
+
+ usb0_vbus_power-supply:
+ description: Power supply to detect the USB OTG VBUS
+
+ usb0_vbus-supply:
+ description: Regulator controlling USB OTG VBUS
+
+required:
+ - "#phy-cells"
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - reg-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/suniv-ccu-f1c100s.h>
+ #include <dt-bindings/reset/suniv-ccu-f1c100s.h>
+
+ phy@1c13400 {
+ compatible = "allwinner,suniv-f1c100s-usb-phy";
+ reg = <0x01c13400 0x10>;
+ reg-names = "phy_ctrl";
+ clocks = <&ccu CLK_USB_PHY0>;
+ clock-names = "usb0_phy";
+ resets = <&ccu RST_USB_PHY0>;
+ reset-names = "usb0_reset";
+ #phy-cells = <1>;
+ usb0_id_det-gpios = <&pio 4 2 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml
index 5eddaed3d853..64795f170f32 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/amlogic,axg-mipi-dphy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/amlogic,axg-mipi-dphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic AXG MIPI D-PHY
diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
index 7aa0c05d6ce4..81c2654b7e57 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic G12A MIPI analog PHY
@@ -16,20 +16,8 @@ properties:
"#phy-cells":
const: 0
- reg:
- maxItems: 1
-
required:
- compatible
- - reg
- "#phy-cells"
additionalProperties: false
-
-examples:
- - |
- phy@0 {
- compatible = "amlogic,g12a-mipi-dphy-analog";
- reg = <0x0 0xc>;
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml
new file mode 100644
index 000000000000..1a0c436b87a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/amlogic,g12a-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic G12A USB2 PHY
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,g12a-usb2-phy
+ - amlogic,a1-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xtal
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 0
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-a1-usb-ctrl
+
+then:
+ properties:
+ power-domains:
+ maxItems: 1
+ required:
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@36000 {
+ compatible = "amlogic,g12a-usb2-phy";
+ reg = <0x36000 0x2000>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml
new file mode 100644
index 000000000000..1a5a12adb72b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/amlogic,g12a-usb3-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic G12A USB3 + PCIE Combo PHY
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,g12a-usb3-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref_clk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 1
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@46000 {
+ compatible = "amlogic,g12a-usb3-pcie-phy";
+ reg = <0x46000 0x2000>;
+ clocks = <&ref_clk>;
+ clock-names = "ref_clk";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
index a90fa1baadab..70def36e5688 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
@@ -1,24 +1,14 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic AXG shared MIPI/PCIE analog PHY
maintainers:
- Remi Pommarel <repk@triplefau.lt>
-description: |+
- The Everything-Else Power Domains node should be the child of a syscon
- node with the required property:
-
- - compatible: Should be the following:
- "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"
-
- Refer to the bindings described in
- Documentation/devicetree/bindings/mfd/syscon.yaml
-
properties:
compatible:
const: amlogic,axg-mipi-pcie-analog-phy
@@ -31,10 +21,3 @@ required:
- "#phy-cells"
additionalProperties: false
-
-examples:
- - |
- mpphy: phy {
- compatible = "amlogic,axg-mipi-pcie-analog-phy";
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml
index 45f3d72b1cca..40fbf8ac3271 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/amlogic,meson-axg-pcie.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/amlogic,meson-axg-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic AXG PCIE PHY
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
deleted file mode 100644
index f3a5fbabbbb5..000000000000
--- a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
+++ /dev/null
@@ -1,78 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-# Copyright 2019 BayLibre, SAS
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb2-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Amlogic G12A USB2 PHY
-
-maintainers:
- - Neil Armstrong <neil.armstrong@linaro.org>
-
-properties:
- compatible:
- enum:
- - amlogic,meson-g12a-usb2-phy
- - amlogic,meson-a1-usb2-phy
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- clock-names:
- items:
- - const: xtal
-
- resets:
- maxItems: 1
-
- reset-names:
- items:
- - const: phy
-
- "#phy-cells":
- const: 0
-
- phy-supply:
- description:
- Phandle to a regulator that provides power to the PHY. This
- regulator will be managed during the PHY power on/off sequence.
-
-required:
- - compatible
- - reg
- - clocks
- - clock-names
- - resets
- - reset-names
- - "#phy-cells"
-
-if:
- properties:
- compatible:
- enum:
- - amlogic,meson-a1-usb-ctrl
-
-then:
- properties:
- power-domains:
- maxItems: 1
- required:
- - power-domains
-
-additionalProperties: false
-
-examples:
- - |
- phy@36000 {
- compatible = "amlogic,meson-g12a-usb2-phy";
- reg = <0x36000 0x2000>;
- clocks = <&xtal>;
- clock-names = "xtal";
- resets = <&phy_reset>;
- reset-names = "phy";
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
deleted file mode 100644
index 868b4e6fde71..000000000000
--- a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
+++ /dev/null
@@ -1,59 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-# Copyright 2019 BayLibre, SAS
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Amlogic G12A USB3 + PCIE Combo PHY
-
-maintainers:
- - Neil Armstrong <neil.armstrong@linaro.org>
-
-properties:
- compatible:
- enum:
- - amlogic,meson-g12a-usb3-pcie-phy
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- clock-names:
- items:
- - const: ref_clk
-
- resets:
- maxItems: 1
-
- reset-names:
- items:
- - const: phy
-
- "#phy-cells":
- const: 1
-
-required:
- - compatible
- - reg
- - clocks
- - clock-names
- - resets
- - reset-names
- - "#phy-cells"
-
-additionalProperties: false
-
-examples:
- - |
- phy@46000 {
- compatible = "amlogic,meson-g12a-usb3-pcie-phy";
- reg = <0x46000 0x2000>;
- clocks = <&ref_clk>;
- clock-names = "ref_clk";
- resets = <&phy_reset>;
- reset-names = "phy";
- #phy-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml
new file mode 100644
index 000000000000..c2f5c9d2fce6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-gxl-usb2-phy.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/amlogic,meson-gxl-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson GXL USB2 PHY
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ const: amlogic,meson-gxl-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: phy
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 0
+
+ phy-supply: true
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@78000 {
+ compatible = "amlogic,meson-gxl-usb2-phy";
+ reg = <0x78000 0x20>;
+ clocks = <&xtal>;
+ clock-names = "phy";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ phy-supply = <&usb2_supply>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml
index 1f085cdd1c85..6f9fd1c953f0 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/amlogic,meson8-hdmi-tx-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/amlogic,meson8-hdmi-tx-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson8, Meson8b and Meson8m2 HDMI TX PHY
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml
index 03c4809dbe8d..df68bfe5f407 100644
--- a/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/amlogic,meson8b-usb2-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/amlogic,meson8b-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson8, Meson8b, Meson8m2 and GXBB USB2 PHY
diff --git a/Documentation/devicetree/bindings/phy/apm,xgene-phy.yaml b/Documentation/devicetree/bindings/phy/apm,xgene-phy.yaml
new file mode 100644
index 000000000000..0674391feeae
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/apm,xgene-phy.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/apm,xgene-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene 15Gbps Multi-purpose PHY
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+description:
+ PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each
+ PHY (pair of lanes) has its own node.
+
+properties:
+ compatible:
+ items:
+ - const: apm,xgene-phy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ description:
+ Possible values are 0 (SATA), 1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI).
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ apm,tx-eye-tuning:
+ description:
+ Manual control to fine tune the capture of the serial bit lines from the
+ automatic calibrated position. Two set of 3-tuple setting for each
+ supported link speed on the host. Range from 0 to 127 in unit of one bit
+ period.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 127
+ default: 10
+
+ apm,tx-eye-direction:
+ description:
+ Eye tuning manual control direction. 0 means sample data earlier than the
+ nominal sampling point. 1 means sample data later than the nominal
+ sampling point. Two set of 3-tuple setting for each supported link speed
+ on the host.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ enum: [0, 1]
+ default: 0
+
+ apm,tx-boost-gain:
+ description:
+ Frequency boost AC (LSB 3-bit) and DC (2-bit) gain control. Two set of
+ 3-tuple setting for each supported link speed on the host. Range is
+ between 0 to 31 in unit of dB. Default is 3.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 31
+
+ apm,tx-amplitude:
+ description:
+ Amplitude control. Two set of 3-tuple setting for each supported link
+ speed on the host. Range is between 0 to 199500 in unit of uV.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 199500
+ default: 199500
+
+ apm,tx-pre-cursor1:
+ description:
+ 1st pre-cursor emphasis taps control. Two set of 3-tuple setting for
+ each supported link speed on the host. Range is 0 to 273000 in unit of
+ uV.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 273000
+ default: 0
+
+ apm,tx-pre-cursor2:
+ description:
+ 2nd pre-cursor emphasis taps control. Two set of 3-tuple setting for
+ each supported link speed on the host. Range is 0 to 127400 in unit uV.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 127400
+ default: 0
+
+ apm,tx-post-cursor:
+ description: |
+ Post-cursor emphasis taps control. Two set of 3-tuple setting for Gen1,
+ Gen2, and Gen3 link speeds. Range is between 0 to 31 in unit of 18.2mV.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 2
+ maxItems: 2
+ items:
+ minItems: 3
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 31
+ default: 0xf
+
+ apm,tx-speed:
+ description: >
+ Tx operating speed. One set of 3-tuple for each supported link speed on
+ the host:
+
+ 0 = 1-2Gbps
+ 1 = 2-4Gbps (1st tuple default)
+ 2 = 4-8Gbps
+ 3 = 8-15Gbps (2nd tuple default)
+ 4 = 2.5-4Gbps
+ 5 = 4-5Gbps
+ 6 = 5-6Gbps
+ 7 = 6-16Gbps (3rd tuple default).
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 3
+ items:
+ maximum: 7
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@1f21a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x1f21a000 0x100>;
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
deleted file mode 100644
index e1bb12711fbf..000000000000
--- a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-* APM X-Gene 15Gbps Multi-purpose PHY nodes
-
-PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each
-PHY (pair of lanes) has its own node.
-
-Required properties:
-- compatible : Shall be "apm,xgene-phy".
-- reg : PHY memory resource is the SDS PHY access resource.
-- #phy-cells : Shall be 1 as it expects one argument for setting
- the mode of the PHY. Possible values are 0 (SATA),
- 1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI).
-
-Optional properties:
-- status : Shall be "ok" if enabled or "disabled" if disabled.
- Default is "ok".
-- clocks : Reference to the clock entry.
-- apm,tx-eye-tuning : Manual control to fine tune the capture of the serial
- bit lines from the automatic calibrated position.
- Two set of 3-tuple setting for each (up to 3)
- supported link speed on the host. Range from 0 to
- 127 in unit of one bit period. Default is 10.
-- apm,tx-eye-direction : Eye tuning manual control direction. 0 means sample
- data earlier than the nominal sampling point. 1 means
- sample data later than the nominal sampling point.
- Two set of 3-tuple setting for each (up to 3)
- supported link speed on the host. Default is 0.
-- apm,tx-boost-gain : Frequency boost AC (LSB 3-bit) and DC (2-bit)
- gain control. Two set of 3-tuple setting for each
- (up to 3) supported link speed on the host. Range is
- between 0 to 31 in unit of dB. Default is 3.
-- apm,tx-amplitude : Amplitude control. Two set of 3-tuple setting for
- each (up to 3) supported link speed on the host.
- Range is between 0 to 199500 in unit of uV.
- Default is 199500 uV.
-- apm,tx-pre-cursor1 : 1st pre-cursor emphasis taps control. Two set of
- 3-tuple setting for each (up to 3) supported link
- speed on the host. Range is 0 to 273000 in unit of
- uV. Default is 0.
-- apm,tx-pre-cursor2 : 2st pre-cursor emphasis taps control. Two set of
- 3-tuple setting for each (up to 3) supported link
- speed on the host. Range is 0 to 127400 in unit uV.
- Default is 0x0.
-- apm,tx-post-cursor : Post-cursor emphasis taps control. Two set of
- 3-tuple setting for Gen1, Gen2, and Gen3. Range is
- between 0 to 0x1f in unit of 18.2mV. Default is 0xf.
-- apm,tx-speed : Tx operating speed. One set of 3-tuple for each
- supported link speed on the host.
- 0 = 1-2Gbps
- 1 = 2-4Gbps (1st tuple default)
- 2 = 4-8Gbps
- 3 = 8-15Gbps (2nd tuple default)
- 4 = 2.5-4Gbps
- 5 = 4-5Gbps
- 6 = 5-6Gbps
- 7 = 6-16Gbps (3rd tuple default)
-
-NOTE: PHY override parameters are board specific setting.
-
-Example:
- phy1: phy@1f21a000 {
- compatible = "apm,xgene-phy";
- reg = <0x0 0x1f21a000 0x0 0x100>;
- #phy-cells = <1>;
- };
-
- phy2: phy@1f22a000 {
- compatible = "apm,xgene-phy";
- reg = <0x0 0x1f22a000 0x0 0x100>;
- #phy-cells = <1>;
- };
-
- phy3: phy@1f23a000 {
- compatible = "apm,xgene-phy";
- reg = <0x0 0x1f23a000 0x0 0x100>;
- #phy-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
index 426101530a21..d72c02ab55ae 100644
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
@@ -18,16 +18,8 @@ properties:
const: brcm,ns-usb2-phy
reg:
- anyOf:
- - maxItems: 1
- description: PHY control register
- - maxItems: 1
- description: iomem address range of DMU (Device Management Unit)
- deprecated: true
-
- reg-names:
- items:
- - const: dmu
+ maxItems: 1
+ description: PHY control register
brcm,syscon-clkset:
description: phandle to syscon for clkset register
@@ -50,12 +42,7 @@ required:
- clocks
- clock-names
- "#phy-cells"
-
-oneOf:
- - required:
- - brcm,syscon-clkset
- - required:
- - reg-names
+ - brcm,syscon-clkset
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
deleted file mode 100644
index c0155f842f62..000000000000
--- a/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Berlin SATA PHY
----------------
-
-Required properties:
-- compatible: should be one of
- "marvell,berlin2-sata-phy"
- "marvell,berlin2q-sata-phy"
-- address-cells: should be 1
-- size-cells: should be 0
-- phy-cells: from the generic PHY bindings, must be 1
-- reg: address and length of the register
-- clocks: reference to the clock entry
-
-Sub-nodes:
-Each PHY should be represented as a sub-node.
-
-Sub-nodes required properties:
-- reg: the PHY number
-
-Example:
- sata_phy: phy@f7e900a0 {
- compatible = "marvell,berlin2q-sata-phy";
- reg = <0xf7e900a0 0x200>;
- clocks = <&chip CLKID_SATA>;
- #address-cells = <1>;
- #size-cells = <0>;
- #phy-cells = <1>;
-
- sata-phy@0 {
- reg = <0>;
- };
-
- sata-phy@1 {
- reg = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt b/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
deleted file mode 100644
index be33780f668e..000000000000
--- a/Documentation/devicetree/bindings/phy/berlin-usb-phy.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* Marvell Berlin USB PHY
-
-Required properties:
-- compatible: "marvell,berlin2-usb-phy" or "marvell,berlin2cd-usb-phy"
-- reg: base address and length of the registers
-- #phys-cells: should be 0
-- resets: reference to the reset controller
-
-Example:
-
- usb-phy@f774000 {
- compatible = "marvell,berlin2-usb-phy";
- reg = <0xf774000 0x128>;
- #phy-cells = <0>;
- resets = <&chip 0x104 14>;
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml
index 0f0bcde9eb88..bd527f566c3b 100644
--- a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/brcm,bcm63xx-usbh-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/brcm,bcm63xx-usbh-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: BCM63xx USBH PHY
diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
index 43a4b880534c..843d04027c30 100644
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml
@@ -18,6 +18,7 @@ properties:
- brcm,bcm4908-usb-phy
- brcm,bcm7211-usb-phy
- brcm,bcm7216-usb-phy
+ - brcm,bcm74110-usb-phy
- brcm,brcmstb-usb-phy
reg:
@@ -115,8 +116,8 @@ allOf:
compatible:
contains:
enum:
- - const: brcm,bcm4908-usb-phy
- - const: brcm,brcmstb-usb-phy
+ - brcm,bcm4908-usb-phy
+ - brcm,brcmstb-usb-phy
then:
properties:
reg:
@@ -139,7 +140,9 @@ allOf:
properties:
compatible:
contains:
- const: brcm,bcm7216-usb-phy
+ enum:
+ - brcm,bcm7216-usb-phy
+ - brcm,bcm74110-usb-phy
then:
properties:
reg:
diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml
index 045699c65779..808e90b2465d 100644
--- a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml
@@ -32,6 +32,7 @@ properties:
patternProperties:
"^pcie-phy@[0-9]+$":
type: object
+ additionalProperties: false
description: >
PCIe PHY child nodes
diff --git a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt
deleted file mode 100644
index 3dc8b3d2ffbb..000000000000
--- a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-BROADCOM KONA USB2 PHY
-
-Required properties:
- - compatible: brcm,kona-usb2-phy
- - reg: offset and length of the PHY registers
- - #phy-cells: must be 0
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
-
- usbphy: usb-phy@3f130000 {
- compatible = "brcm,kona-usb2-phy";
- reg = <0x3f130000 0x28>;
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml
new file mode 100644
index 000000000000..d7faeb81f7a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,kona-usb2-phy.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,kona-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family USB 2.0 PHY
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,kona-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@3f130000 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f130000 0x28>;
+ #phy-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
deleted file mode 100644
index 04f063aa7883..000000000000
--- a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
-
-Required properties:
- - compatible: brcm,ns2-drd-phy
- - reg: offset and length of the NS2 PHY related registers.
- - reg-names
- The below registers must be provided.
- icfg - for DRD ICFG configurations
- rst-ctrl - for DRD IDM reset
- crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
- usb2-strap - for port over current polarity reversal
- - #phy-cells: Must be 0. No args required.
- - vbus-gpios: vbus gpio binding
- - id-gpios: id gpio binding
-
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
- usbdrd_phy: phy@66000960 {
- #phy-cells = <0>;
- compatible = "brcm,ns2-drd-phy";
- reg = <0x66000960 0x24>,
- <0x67012800 0x4>,
- <0x6501d148 0x4>,
- <0x664d0700 0x4>;
- reg-names = "icfg", "rst-ctrl",
- "crmu-ctrl", "usb2-strap";
- id-gpios = <&gpio_g 30 0>;
- vbus-gpios = <&gpio_g 31 0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.yaml
new file mode 100644
index 000000000000..1fab97de5c0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,ns2-drd-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar2 USB2 Dual Role Device PHY
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Hauke Mehrtens <hauke@hauke-m.de>
+ - Rafał Miłecki <zajec5@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,ns2-drd-phy
+
+ reg:
+ items:
+ - description: DRD ICFG configurations
+ - description: DRD IDM reset
+ - description: CRMU core vdd, PHY and PHY PLL reset
+ - description: Port over current polarity reversal
+
+ reg-names:
+ items:
+ - const: icfg
+ - const: rst-ctrl
+ - const: crmu-ctrl
+ - const: usb2-strap
+
+ '#phy-cells':
+ const: 0
+
+ id-gpios:
+ maxItems: 1
+ description: ID GPIO line
+
+ vbus-gpios:
+ maxItems: 1
+ description: VBUS GPIO line
+
+required:
+ - '#phy-cells'
+ - compatible
+ - reg
+ - reg-names
+ - id-gpios
+ - vbus-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@66000960 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x66000960 0x24>, <0x67012800 0x4>, <0x6501d148 0x4>, <0x664d0700 0x4>;
+ reg-names = "icfg", "rst-ctrl", "crmu-ctrl", "usb2-strap";
+ id-gpios = <&gpio_g 30 0>;
+ vbus-gpios = <&gpio_g 31 0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml
index 70eb48b391c9..527010702f5e 100644
--- a/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/brcm,ns2-pcie-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom NS2 PCIe PHY binding document
+title: Broadcom NS2 PCIe PHY
maintainers:
- Ray Jui <ray.jui@broadcom.com>
diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
index 435b971dfd9b..439bda142764 100644
--- a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/brcm,sata-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/brcm,sata-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom SATA3 PHY
@@ -59,14 +59,14 @@ patternProperties:
"#phy-cells":
const: 0
- "brcm,enable-ssc":
+ brcm,enable-ssc:
$ref: /schemas/types.yaml#/definitions/flag
description: |
Use spread spectrum clocking (SSC) on this port
This property is not applicable for "brcm,iproc-ns2-sata-phy",
"brcm,iproc-nsp-sata-phy" and "brcm,iproc-sr-sata-phy".
- "brcm,rxaeq-mode":
+ brcm,rxaeq-mode:
$ref: /schemas/types.yaml#/definitions/string
description:
String that indicates the desired RX equalizer mode.
@@ -75,7 +75,7 @@ patternProperties:
- auto
- manual
- "brcm,rxaeq-value":
+ brcm,rxaeq-value:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
When 'brcm,rxaeq-mode' is set to "manual", provides the RX
@@ -83,7 +83,7 @@ patternProperties:
minimum: 0
maximum: 63
- "brcm,tx-amplitude-millivolt":
+ brcm,tx-amplitude-millivolt:
description: |
Transmit amplitude voltage in millivolt.
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt b/Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt
deleted file mode 100644
index e8d82286beb9..000000000000
--- a/Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Broadcom Stingray PCIe PHY
-
-Required properties:
-- compatible: must be "brcm,sr-pcie-phy"
-- reg: base address and length of the PCIe SS register space
-- brcm,sr-cdru: phandle to the CDRU syscon node
-- brcm,sr-mhb: phandle to the MHB syscon node
-- #phy-cells: Must be 1, denotes the PHY index
-
-For PAXB based root complex, one can have a configuration of up to 8 PHYs
-PHY index goes from 0 to 7
-
-For the internal PAXC based root complex, PHY index is always 8
-
-Example:
- mhb: syscon@60401000 {
- compatible = "brcm,sr-mhb", "syscon";
- reg = <0 0x60401000 0 0x38c>;
- };
-
- cdru: syscon@6641d000 {
- compatible = "brcm,sr-cdru", "syscon";
- reg = <0 0x6641d000 0 0x400>;
- };
-
- pcie_phy: phy@40000000 {
- compatible = "brcm,sr-pcie-phy";
- reg = <0 0x40000000 0 0x800>;
- brcm,sr-cdru = <&cdru>;
- brcm,sr-mhb = <&mhb>;
- #phy-cells = <1>;
- };
-
- /* users of the PCIe PHY */
-
- pcie0: pcie@48000000 {
- ...
- ...
- phys = <&pcie_phy 0>;
- phy-names = "pcie-phy";
- };
diff --git a/Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.yaml
new file mode 100644
index 000000000000..60ccc0813ed5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,sr-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Stingray PCIe PHY
+
+maintainers:
+ - Ray Jui <ray.jui@broadcom.com>
+
+description: >
+ For PAXB based root complex, one can have a configuration of up to 8 PHYs.
+ PHY index goes from 0 to 7.
+
+ For the internal PAXC based root complex, PHY index is always 8.
+
+properties:
+ compatible:
+ const: brcm,sr-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 1
+
+ brcm,sr-cdru:
+ description: phandle to the CDRU syscon node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ brcm,sr-mhb:
+ description: phandle to the MHB syscon node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@40000000 {
+ compatible = "brcm,sr-pcie-phy";
+ reg = <0x40000000 0x800>;
+ brcm,sr-cdru = <&cdru>;
+ brcm,sr-mhb = <&mhb>;
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/brcm,sr-usb-combo-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sr-usb-combo-phy.yaml
new file mode 100644
index 000000000000..6224ba0f2990
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,sr-usb-combo-phy.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/brcm,sr-usb-combo-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Stingray USB PHY
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+properties:
+ compatible:
+ enum:
+ - brcm,sr-usb-combo-phy
+ - brcm,sr-usb-hs-phy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ description: PHY cell count indicating PHY type
+ enum: [ 0, 1 ]
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,sr-usb-combo-phy
+ then:
+ properties:
+ '#phy-cells':
+ const: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,sr-usb-hs-phy
+ then:
+ properties:
+ '#phy-cells':
+ const: 0
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x00000000 0x100>;
+ #phy-cells = <1>;
+ };
+ - |
+ usb-phy@20000 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x00020000 0x100>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
deleted file mode 100644
index 4ba298966af9..000000000000
--- a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Broadcom Stingray USB PHY
-
-Required properties:
- - compatible : should be one of the listed compatibles
- - "brcm,sr-usb-combo-phy" is combo PHY has two PHYs, one SS and one HS.
- - "brcm,sr-usb-hs-phy" is a single HS PHY.
- - reg: offset and length of the PHY blocks registers
- - #phy-cells:
- - Must be 1 for brcm,sr-usb-combo-phy as it expects one argument to indicate
- the PHY number of two PHYs. 0 for HS PHY and 1 for SS PHY.
- - Must be 0 for brcm,sr-usb-hs-phy.
-
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
- usbphy0: usb-phy@0 {
- compatible = "brcm,sr-usb-combo-phy";
- reg = <0x00000000 0x100>;
- #phy-cells = <1>;
- };
-
- usbphy1: usb-phy@10000 {
- compatible = "brcm,sr-usb-combo-phy";
- reg = <0x00010000 0x100>,
- #phy-cells = <1>;
- };
-
- usbphy2: usb-phy@20000 {
- compatible = "brcm,sr-usb-hs-phy";
- reg = <0x00020000 0x100>,
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml b/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml
index 41ee16e21f8d..d05a7c793035 100644
--- a/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml
+++ b/Documentation/devicetree/bindings/phy/calxeda-combophy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/calxeda-combophy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Calxeda Highbank Combination PHYs binding for SATA
+title: Calxeda Highbank Combination PHYs for SATA
description: |
The Calxeda Combination PHYs connect the SoC to the internal fabric
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml
index 07be031d82e6..6fdd46ad5a78 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/phy/cdns,dphy-rx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence DPHY Rx Device Tree Bindings
+title: Cadence DPHY Rx
maintainers:
- - Pratyush Yadav <p.yadav@ti.com>
+ - Pratyush Yadav <pratyush@kernel.org>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index f0e9ca8427bb..6cd9b0f388a4 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/phy/cdns,dphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence DPHY Device Tree Bindings
+title: Cadence DPHY
maintainers:
- - Pratyush Yadav <p.yadav@ti.com>
+ - Pratyush Yadav <pratyush@kernel.org>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
index 3a07285b5470..c7281a7c8244 100644
--- a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml
@@ -2,8 +2,8 @@
# Copyright (c) 2020 NXP
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/cdns,salvo-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/cdns,salvo-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence SALVO PHY
@@ -31,6 +31,12 @@ properties:
"#phy-cells":
const: 0
+ cdns,usb2-disconnect-threshold-microvolt:
+ description: The microvolt threshold value utilized for detecting
+ USB disconnection event.
+ enum: [575, 610, 645]
+ default: 575
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/phy/dm816x-phy.txt b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
deleted file mode 100644
index 2fe3d11d063d..000000000000
--- a/Documentation/devicetree/bindings/phy/dm816x-phy.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Device tree binding documentation for am816x USB PHY
-=========================
-
-Required properties:
-- compatible : should be "ti,dm816x-usb-phy"
-- reg : offset and length of the PHY register set.
-- reg-names : name for the phy registers
-- clocks : phandle to the clock
-- clock-names : name of the clock
-- syscon: phandle for the syscon node to access misc registers
-- #phy-cells : from the generic PHY bindings, must be 1
-- syscon: phandle for the syscon node to access misc registers
-
-Example:
-
-usb_phy0: usb-phy@20 {
- compatible = "ti,dm8168-usb-phy";
- reg = <0x20 0x8>;
- reg-names = "phy";
- clocks = <&main_fapll 6>;
- clock-names = "refclk";
- #phy-cells = <0>;
- syscon = <&scm_conf>;
-};
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
index b6421eedece3..182a219387b0 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/fsl,imx8-pcie-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX8 SoC series PCIe PHY Device Tree Bindings
+title: Freescale i.MX8 SoC series PCIe PHY
maintainers:
- Richard Zhu <hongxing.zhu@nxp.com>
@@ -16,6 +16,7 @@ properties:
compatible:
enum:
- fsl,imx8mm-pcie-phy
+ - fsl,imx8mp-pcie-phy
reg:
maxItems: 1
@@ -28,11 +29,16 @@ properties:
- const: ref
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
reset-names:
- items:
- - const: pciephy
+ oneOf:
+ - items: # for iMX8MM
+ - const: pciephy
+ - items: # for IMX8MP
+ - const: pciephy
+ - const: perst
fsl,refclk-pad-mode:
description: |
@@ -60,6 +66,10 @@ properties:
description: A boolean property indicating the CLKREQ# signal is
not supported in the board design (optional)
+ power-domains:
+ description: PCIe PHY power domain (optional).
+ maxItems: 1
+
required:
- "#phy-cells"
- compatible
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
new file mode 100644
index 000000000000..c43e86a8c2e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI PHY
+
+maintainers:
+ - Lucas Stach <l.stach@pengutronix.de>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8mp-hdmi-phy
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: apb
+ - const: ref
+
+ "#phy-cells":
+ const: 0
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+ - clock-names
+ - "#phy-cells"
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/power/imx8mp-power.h>
+
+ phy@32fdff00 {
+ compatible = "fsl,imx8mp-hdmi-phy";
+ reg = <0x32fdff00 0x100>;
+ clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+ <&clk IMX8MP_CLK_HDMI_24M>;
+ clock-names = "apb", "ref";
+ power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX_PHY>;
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
index 2936f3510a6a..8a00a6c58edd 100644
--- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml
@@ -4,34 +4,92 @@
$id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale i.MX8MQ USB3 PHY binding
+title: Freescale i.MX8MQ USB3 PHY
maintainers:
- Li Jun <jun.li@nxp.com>
properties:
compatible:
- enum:
- - fsl,imx8mq-usb-phy
- - fsl,imx8mp-usb-phy
+ oneOf:
+ - enum:
+ - fsl,imx8mq-usb-phy
+ - fsl,imx8mp-usb-phy
+ - items:
+ - const: fsl,imx95-usb-phy
+ - const: fsl,imx8mp-usb-phy
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
"#phy-cells":
const: 0
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: PHY configuration clock
+ - description: Alternate PHY reference clock
clock-names:
+ minItems: 1
items:
- const: phy
+ - const: alt
+
+ power-domains:
+ maxItems: 1
vbus-supply:
description:
A phandle to the regulator for USB VBUS.
+ fsl,phy-tx-vref-tune-percent:
+ description:
+ Tunes the HS DC level relative to the nominal level
+ minimum: 90
+ maximum: 124
+
+ fsl,phy-tx-rise-tune-percent:
+ description:
+ Adjusts the rise/fall time duration of the HS waveform relative to
+ its nominal value
+ minimum: 90
+ maximum: 120
+
+ fsl,phy-tx-preemp-amp-tune-microamp:
+ description:
+ Adjust amount of current sourced to DPn and DMn after a J-to-K
+ or K-to-J transition. Default is 0 (disabled).
+ minimum: 0
+ maximum: 1800
+
+ fsl,phy-tx-vboost-level-microvolt:
+ description:
+ Adjust the boosted transmit launch pk-pk differential amplitude
+ enum: [844, 1008, 1156]
+
+ fsl,phy-comp-dis-tune-percent:
+ description:
+ Adjust the voltage level used to detect a disconnect event at the host
+ relative to the nominal value
+ minimum: 91
+ maximum: 115
+
+ fsl,phy-pcs-tx-deemph-3p5db-attenuation-db:
+ description:
+ Adjust TX de-emphasis attenuation in dB at nominal
+ 3.5dB point as per USB specification
+ minimum: 0
+ maximum: 36
+
+ fsl,phy-pcs-tx-swing-full-percent:
+ description:
+ Scaling of the voltage defined by fsl,phy-tx-vboost-level-microvolt
+ minimum: 0
+ maximum: 100
+
required:
- compatible
- reg
@@ -39,7 +97,61 @@ required:
- clocks
- clock-names
-additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx95-usb-phy
+ then:
+ properties:
+ reg:
+ items:
+ - description: USB PHY Control range
+ - description: USB PHY TCA Block range
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8mq-usb-phy
+ - fsl,imx8mp-usb-phy
+ then:
+ properties:
+ fsl,phy-tx-vref-tune-percent:
+ minimum: 94
+ fsl,phy-tx-rise-tune-percent:
+ minimum: 97
+ maximum: 103
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx95-usb-phy
+ then:
+ properties:
+ fsl,phy-tx-vref-tune-percent:
+ maximum: 108
+ fsl,phy-comp-dis-tune-percent:
+ minimum: 94
+ maximum: 104
+
+ - if:
+ required:
+ - orientation-switch
+ then:
+ allOf:
+ - $ref: /schemas/usb/usb-switch.yaml#
+ - $ref: /schemas/usb/usb-switch-ports.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8qm-hsio.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8qm-hsio.yaml
new file mode 100644
index 000000000000..147bbfd2cd5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8qm-hsio.yaml
@@ -0,0 +1,164 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8qm-hsio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8QM SoC series High Speed IO(HSIO) SERDES PHY
+
+maintainers:
+ - Richard Zhu <hongxing.zhu@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qm-hsio
+ - fsl,imx8qxp-hsio
+ reg:
+ items:
+ - description: Base address and length of the PHY block
+ - description: HSIO control and status registers(CSR) of the PHY
+ - description: HSIO CSR of the controller bound to the PHY
+ - description: HSIO CSR for MISC
+
+ reg-names:
+ items:
+ - const: reg
+ - const: phy
+ - const: ctrl
+ - const: misc
+
+ "#phy-cells":
+ const: 3
+ description:
+ The first defines lane index.
+ The second defines the type of the PHY refer to the include phy.h.
+ The third defines the controller index, indicated which controller
+ is bound to the lane.
+
+ clocks:
+ minItems: 5
+ maxItems: 14
+
+ clock-names:
+ minItems: 5
+ maxItems: 14
+
+ fsl,hsio-cfg:
+ description: |
+ Specifies the use case of the HSIO module in the hardware design.
+ Regarding the design of i.MX8QM HSIO subsystem, HSIO module can be
+ confiured as following three use cases.
+ +---------------------------------------+
+ | | i.MX8QM |
+ |------------------|--------------------|
+ | | Lane0| Lane1| Lane2|
+ |------------------|------|------|------|
+ | pciea-x2-sata | PCIEA| PCIEA| SATA |
+ |------------------|------|------|------|
+ | pciea-x2-pcieb | PCIEA| PCIEA| PCIEB|
+ |------------------|------|------|------|
+ | pciea-pcieb-sata | PCIEA| PCIEB| SATA |
+ +---------------------------------------+
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pciea-x2-sata, pciea-x2-pcieb, pciea-pcieb-sata]
+ default: pciea-pcieb-sata
+
+ fsl,refclk-pad-mode:
+ description:
+ Specifies the mode of the refclk pad used. INPUT(PHY refclock is
+ provided externally via the refclk pad) or OUTPUT(PHY refclock is
+ derived from SoC internal source and provided on the refclk pad).
+ This property not exists means unused(PHY refclock is derived from
+ SoC internal source).
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ input, output, unused ]
+ default: unused
+
+ power-domains:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#phy-cells"
+ - clocks
+ - clock-names
+ - fsl,hsio-cfg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-hsio
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: pclk0
+ - const: apb_pclk0
+ - const: phy0_crr
+ - const: ctl0_crr
+ - const: misc_crr
+ power-domains:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-hsio
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: pclk0
+ - const: pclk1
+ - const: apb_pclk0
+ - const: apb_pclk1
+ - const: pclk2
+ - const: epcs_tx
+ - const: epcs_rx
+ - const: apb_pclk2
+ - const: phy0_crr
+ - const: phy1_crr
+ - const: ctl0_crr
+ - const: ctl1_crr
+ - const: ctl2_crr
+ - const: misc_crr
+ power-domains:
+ minItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ #include <dt-bindings/phy/phy-imx8-pcie.h>
+
+ phy@5f1a0000 {
+ compatible = "fsl,imx8qxp-hsio";
+ reg = <0x5f1a0000 0x10000>,
+ <0x5f120000 0x10000>,
+ <0x5f140000 0x10000>,
+ <0x5f160000 0x10000>;
+ reg-names = "reg", "phy", "ctrl", "misc";
+ clocks = <&phyx1_lpcg IMX_LPCG_CLK_0>,
+ <&phyx1_lpcg IMX_LPCG_CLK_4>,
+ <&phyx1_crr1_lpcg IMX_LPCG_CLK_4>,
+ <&pcieb_crr3_lpcg IMX_LPCG_CLK_4>,
+ <&misc_crr5_lpcg IMX_LPCG_CLK_4>;
+ clock-names = "pclk0", "apb_pclk0", "phy0_crr", "ctl0_crr", "misc_crr";
+ power-domains = <&pd IMX_SC_R_SERDES_1>;
+ #phy-cells = <3>;
+ fsl,hsio-cfg = "pciea-pcieb-sata";
+ fsl,refclk-pad-mode = "input";
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
index 4d91e2f4f247..ff9f9ca0f19c 100644
--- a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
+++ b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/fsl,lynx-28g.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Freescale Lynx 28G SerDes PHY binding
+title: Freescale Lynx 28G SerDes PHY
maintainers:
- Ioana Ciornei <ioana.ciornei@nxp.com>
diff --git a/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
new file mode 100644
index 000000000000..d01b7d187040
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,mxs-usbphy.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,mxs-usbphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS USB Phy Device
+
+maintainers:
+ - Xu Yang <xu.yang_2@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx23-usbphy
+ - fsl,imx7ulp-usbphy
+ - fsl,vf610-usbphy
+ - items:
+ - enum:
+ - fsl,imx28-usbphy
+ - fsl,imx6ul-usbphy
+ - fsl,imx6sl-usbphy
+ - fsl,imx6sx-usbphy
+ - fsl,imx6q-usbphy
+ - const: fsl,imx23-usbphy
+ - items:
+ - const: fsl,imx6sll-usbphy
+ - const: fsl,imx6ul-usbphy
+ - const: fsl,imx23-usbphy
+ - items:
+ - enum:
+ - fsl,imx8dxl-usbphy
+ - fsl,imx8qm-usbphy
+ - fsl,imx8qxp-usbphy
+ - fsl,imx8ulp-usbphy
+ - const: fsl,imx7ulp-usbphy
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+ power-domains:
+ maxItems: 1
+
+ fsl,anatop:
+ description:
+ phandle for anatop register, it is only for imx6 SoC series.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ phy-3p0-supply:
+ description:
+ One of USB PHY's power supply. Can be used to keep a good signal
+ quality.
+
+ fsl,tx-cal-45-dn-ohms:
+ description:
+ Resistance (in ohms) of switchable high-speed trimming resistor
+ connected in parallel with the 45 ohm resistor that terminates
+ the DN output signal.
+ minimum: 35
+ maximum: 54
+ default: 45
+
+ fsl,tx-cal-45-dp-ohms:
+ description:
+ Resistance (in ohms) of switchable high-speed trimming resistor
+ connected in parallel with the 45 ohm resistor that terminates
+ the DP output signal.
+ minimum: 35
+ maximum: 54
+ default: 45
+
+ fsl,tx-d-cal:
+ description:
+ Current trimming value (as a percentage) of the 17.78 mA TX
+ reference current.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 79
+ maximum: 119
+ default: 100
+
+ nxp,sim:
+ description:
+ The system integration module (SIM) provides system control and chip
+ configuration registers.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx6q-usbphy
+ - fsl,imx6sl-usbphy
+ - fsl,imx6sx-usbphy
+ - fsl,imx6sll-usbphy
+ - fsl,vf610-usbphy
+ - items:
+ - const: fsl,imx6ul-usbphy
+ - const: fsl,imx23-usbphy
+ then:
+ required:
+ - fsl,anatop
+
+ - if:
+ properties:
+ compatible:
+ const: fsl,imx7ulp-usbphy
+ then:
+ required:
+ - nxp,sim
+ else:
+ properties:
+ nxp,sim: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+
+ usbphy1: usb-phy@20c9000 {
+ compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
+ reg = <0x020c9000 0x1000>;
+ clocks = <&clks IMX6QDL_CLK_USBPHY1>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,anatop = <&anatop>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
index c2e073e26190..405c6b0b88c0 100644
--- a/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml
@@ -19,15 +19,16 @@ properties:
const: 0
hisilicon,pericrg-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle of syscon used to control iso refclk.
hisilicon,pctrl-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle of syscon used to control usb tcxo.
hisilicon,eye-diagram-param:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: Eye diagram for phy.
required:
@@ -41,20 +42,10 @@ additionalProperties: false
examples:
- |
- bus {
- #address-cells = <2>;
- #size-cells = <2>;
-
- usb3_otg_bc: usb3_otg_bc@ff200000 {
- compatible = "syscon", "simple-mfd";
- reg = <0x0 0xff200000 0x0 0x1000>;
-
- usb-phy {
- compatible = "hisilicon,hi3660-usb-phy";
- #phy-cells = <0>;
- hisilicon,pericrg-syscon = <&crg_ctrl>;
- hisilicon,pctrl-syscon = <&pctrl>;
- hisilicon,eye-diagram-param = <0x22466e4>;
- };
- };
+ usb-phy {
+ compatible = "hisilicon,hi3660-usb-phy";
+ #phy-cells = <0>;
+ hisilicon,pericrg-syscon = <&crg_ctrl>;
+ hisilicon,pctrl-syscon = <&pctrl>;
+ hisilicon,eye-diagram-param = <0x22466e4>;
};
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
index ebd78acfe2de..a1a8a84dfc54 100644
--- a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml
@@ -20,19 +20,20 @@ properties:
const: 0
hisilicon,pericrg-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle of syscon used to control iso refclk.
hisilicon,pctrl-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle of syscon used to control usb tcxo.
hisilicon,sctrl-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle of syscon used to control phy deep sleep.
hisilicon,eye-diagram-param:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: Eye diagram for phy.
hisilicon,tx-vboost-lvl:
@@ -52,22 +53,12 @@ additionalProperties: false
examples:
- |
- bus {
- #address-cells = <2>;
- #size-cells = <2>;
-
- usb3_otg_bc: usb3_otg_bc@ff200000 {
- compatible = "syscon", "simple-mfd";
- reg = <0x0 0xff200000 0x0 0x1000>;
-
- usb_phy {
- compatible = "hisilicon,hi3670-usb-phy";
- #phy-cells = <0>;
- hisilicon,pericrg-syscon = <&crg_ctrl>;
- hisilicon,pctrl-syscon = <&pctrl>;
- hisilicon,sctrl-syscon = <&sctrl>;
- hisilicon,eye-diagram-param = <0xfdfee4>;
- hisilicon,tx-vboost-lvl = <0x5>;
- };
- };
+ usb-phy {
+ compatible = "hisilicon,hi3670-usb-phy";
+ #phy-cells = <0>;
+ hisilicon,pericrg-syscon = <&crg_ctrl>;
+ hisilicon,pctrl-syscon = <&pctrl>;
+ hisilicon,sctrl-syscon = <&sctrl>;
+ hisilicon,eye-diagram-param = <0xfdfee4>;
+ hisilicon,tx-vboost-lvl = <0x5>;
};
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3798cv200-combphy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3798cv200-combphy.yaml
new file mode 100644
index 000000000000..81001966f657
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3798cv200-combphy.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/hisilicon,hi3798cv200-combphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon STB PCIE/SATA/USB3 PHY
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+properties:
+ compatible:
+ const: hisilicon,hi3798cv200-combphy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ description: The cell contains the PHY mode
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ hisilicon,fixed-mode:
+ description: If the phy device doesn't support mode select but a fixed mode
+ setting, the property should be present to specify the particular mode.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1, 2, 4] # SATA, PCIE, USB3
+
+ hisilicon,mode-select-bits:
+ description: If the phy device support mode select, this property should be
+ present to specify the register bits in peripheral controller.
+ items:
+ - description: register_offset
+ - description: bit shift
+ - description: bit mask
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+ - clocks
+ - resets
+
+oneOf:
+ - required: ['hisilicon,fixed-mode']
+ - required: ['hisilicon,mode-select-bits']
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi6220-usb-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi6220-usb-phy.yaml
new file mode 100644
index 000000000000..376586a666e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hi6220-usb-phy.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/hisilicon,hi6220-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon hi6220 USB PHY
+
+maintainers:
+ - Zhangfei Gao <zhangfei.gao@linaro.org>
+
+properties:
+ compatible:
+ const: hisilicon,hi6220-usb-phy
+
+ '#phy-cells':
+ const: 0
+
+ phy-supply:
+ description: PHY power supply.
+
+ hisilicon,peripheral-syscon:
+ description: Phandle to the system controller for PHY control.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+additionalProperties: false
+
+examples:
+ - |
+ usbphy {
+ compatible = "hisilicon,hi6220-usb-phy";
+ #phy-cells = <0>;
+ phy-supply = <&fixed_5v_hub>;
+ hisilicon,peripheral-syscon = <&sys_ctrl>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hix5hd2-sata-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hix5hd2-sata-phy.yaml
new file mode 100644
index 000000000000..2993dd6b40a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/hisilicon,hix5hd2-sata-phy.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/hisilicon,hix5hd2-sata-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon hix5hd2 SATA PHY
+
+maintainers:
+ - Jiancheng Xue <xuejiancheng@huawei.com>
+
+properties:
+ compatible:
+ const: hisilicon,hix5hd2-sata-phy
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+ hisilicon,peripheral-syscon:
+ description: Phandle of syscon used to control peripheral
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ hisilicon,power-reg:
+ description: Offset and bit number within peripheral-syscon register controlling SATA power supply
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: Offset within peripheral-syscon register
+ - description: Bit number controlling SATA power supply
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@f9900000 {
+ compatible = "hisilicon,hix5hd2-sata-phy";
+ reg = <0xf9900000 0x10000>;
+ #phy-cells = <0>;
+ hisilicon,peripheral-syscon = <&peripheral_ctrl>;
+ hisilicon,power-reg = <0x8 10>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
new file mode 100644
index 000000000000..51ea0e54ce35
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/hisilicon,inno-usb2-phy.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/hisilicon,inno-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon INNO USB2 PHY
+
+maintainers:
+ - Pengcheng Li <lpc.li@hisilicon.com>
+
+description:
+ The INNO USB2 PHY device should be a child node of peripheral controller that
+ contains the PHY configuration register, and each device supports up to 2 PHY
+ ports which are represented as child nodes of INNO USB2 PHY device.
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,hi3798cv200-usb2-phy
+ - hisilicon,hi3798mv100-usb2-phy
+ - hisilicon,inno-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^phy@[0-1]$":
+ description: PHY port subnode
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maximum: 1
+
+ "#phy-cells":
+ const: 0
+
+ resets:
+ maxItems: 1
+
+ required:
+ - reg
+ - "#phy-cells"
+ - resets
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/histb-clock.h>
+
+ usb2-phy@120 {
+ compatible = "hisilicon,hi3798cv200-usb2-phy";
+ reg = <0x120 0x4>;
+ clocks = <&crg HISTB_USB2_PHY1_REF_CLK>;
+ resets = <&crg 0xbc 4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ resets = <&crg 0xbc 8>;
+ };
+
+ phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ resets = <&crg 0xbc 9>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt b/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt
deleted file mode 100644
index 296168b74d24..000000000000
--- a/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Hisilicon hix5hd2 SATA PHY
------------------------
-
-Required properties:
-- compatible: should be "hisilicon,hix5hd2-sata-phy"
-- reg: offset and length of the PHY registers
-- #phy-cells: must be 0
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Optional Properties:
-- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral.
-- hisilicon,power-reg: offset and bit number within peripheral-syscon,
- register of controlling sata power supply.
-
-Example:
- sata_phy: phy@f9900000 {
- compatible = "hisilicon,hix5hd2-sata-phy";
- reg = <0xf9900000 0x10000>;
- #phy-cells = <0>;
- hisilicon,peripheral-syscon = <&peripheral_ctrl>;
- hisilicon,power-reg = <0x8 10>;
- };
diff --git a/Documentation/devicetree/bindings/phy/img,pistachio-usb-phy.yaml b/Documentation/devicetree/bindings/phy/img,pistachio-usb-phy.yaml
new file mode 100644
index 000000000000..bcc19bc68297
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/img,pistachio-usb-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/img,pistachio-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Pistachio USB PHY
+
+maintainers:
+ - Andrew Bresticker <abrestic@chromium.org>
+
+properties:
+ compatible:
+ const: img,pistachio-usb-phy
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: usb_phy
+
+ '#phy-cells':
+ const: 0
+
+ phy-supply:
+ description: USB VBUS supply. Must supply 5.0V.
+
+ img,refclk:
+ description:
+ Reference clock source for the USB PHY. See
+ <dt-bindings/phy/phy-pistachio-usb.h> for valid values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ img,cr-top:
+ description: CR_TOP syscon phandle.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - '#phy-cells'
+ - img,refclk
+ - img,cr-top
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/phy/phy-pistachio-usb.h>
+ #include <dt-bindings/clock/pistachio-clk.h>
+
+ usb-phy {
+ compatible = "img,pistachio-usb-phy";
+ clocks = <&clk_core CLK_USB_PHY>;
+ clock-names = "usb_phy";
+ #phy-cells = <0>;
+ phy-supply = <&usb_vbus>;
+ img,refclk = <REFCLK_CLK_CORE>;
+ img,cr-top = <&cr_top>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
index 5cab21648632..30b42008db06 100644
--- a/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
+++ b/Documentation/devicetree/bindings/phy/ingenic,phy-usb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/ingenic,phy-usb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs USB PHY devicetree bindings
+title: Ingenic SoCs USB PHY
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
index 5d54b0a0e873..7dd6a4d94b48 100644
--- a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml
@@ -15,7 +15,7 @@ description: |
properties:
$nodename:
- pattern: "combophy(@.*|-[0-9a-f])*$"
+ pattern: "combophy(@.*|-([0-9]|[1-9][0-9]+))?$"
compatible:
items:
diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml
index 52815b6c2b88..5cee4c85ff8b 100644
--- a/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml
+++ b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/intel,keembay-phy-usb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Keem Bay USB PHY bindings
+title: Intel Keem Bay USB PHY
maintainers:
- Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
index 954e67571dfd..ca818f83579b 100644
--- a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/intel,lgm-emmc-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Lightning Mountain(LGM) eMMC PHY Device Tree Bindings
+title: Intel Lightning Mountain(LGM) eMMC PHY
maintainers:
- Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
index ce62c0b94daf..653a12286637 100644
--- a/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/intel,lgm-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel LGM USB PHY Device Tree Bindings
+title: Intel LGM USB PHY
maintainers:
- Vadivel Murugan Ramuthevar <vadivel.muruganx.ramuthevar@linux.intel.com>
diff --git a/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml b/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml
deleted file mode 100644
index 34bdb5c4cae8..000000000000
--- a/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/phy/intel,phy-thunderbay-emmc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Intel Thunder Bay eMMC PHY bindings
-
-maintainers:
- - Srikandan Nandhini <nandhini.srikandan@intel.com>
-
-properties:
- compatible:
- const: intel,thunderbay-emmc-phy
-
- "#phy-cells":
- const: 0
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- clock-names:
- items:
- - const: emmcclk
-
-required:
- - "#phy-cells"
- - compatible
- - reg
- - clocks
-
-additionalProperties: false
-
-examples:
- - |
- mmc_phy@80440800 {
- #phy-cells = <0x0>;
- compatible = "intel,thunderbay-emmc-phy";
- status = "okay";
- reg = <0x80440800 0x100>;
- clocks = <&emmc>;
- clock-names = "emmcclk";
- };
diff --git a/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt b/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt
deleted file mode 100644
index 300830dda0bf..000000000000
--- a/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-TI Keystone USB PHY
-
-Required properties:
- - compatible: should be "ti,keystone-usbphy".
- - #address-cells, #size-cells : should be '1' if the device has sub-nodes
- with 'reg' property.
- - reg : Address and length of the usb phy control register set.
-
-The main purpose of this PHY driver is to enable the USB PHY reference clock
-gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just
-an NOP PHY driver. Hence this node is referenced as both the usb2 and usb3
-phy node in the USB Glue layer driver node.
-
-usb_phy: usb_phy@2620738 {
- compatible = "ti,keystone-usbphy";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x2620738 32>;
-};
diff --git a/Documentation/devicetree/bindings/phy/lantiq,ase-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/lantiq,ase-usb2-phy.yaml
new file mode 100644
index 000000000000..99b5da705ca4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/lantiq,ase-usb2-phy.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/lantiq,ase-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq XWAY SoC RCU USB 1.1/2.0 PHY
+
+maintainers:
+ - Hauke Mehrtens <hauke@hauke-m.de>
+
+description:
+ This node has to be a sub node of the Lantiq RCU block.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - lantiq,ase-usb2-phy
+ - lantiq,danube-usb2-phy
+ - lantiq,xrx100-usb2-phy
+ - lantiq,xrx200-usb2-phy
+ - lantiq,xrx300-usb2-phy
+
+ reg:
+ items:
+ - description: Offset of the USB PHY configuration register
+ - description: Offset of the USB Analog configuration register
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: phy
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - enum: [ phy, ctrl ]
+ - const: ctrl
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ usb2-phy@18 {
+ compatible = "lantiq,xrx200-usb2-phy";
+ reg = <0x18 4>, <0x38 4>;
+ clocks = <&pmu 1>;
+ clock-names = "phy";
+ resets = <&reset1 4 4>, <&reset0 4 4>;
+ reset-names = "phy", "ctrl";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml
index a97482179cf5..711de06bb0fc 100644
--- a/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/lantiq,vrx200-pcie-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/lantiq,vrx200-pcie-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Lantiq VRX200 and ARX300 PCIe PHY Device Tree Bindings
+title: Lantiq VRX200 and ARX300 PCIe PHY
maintainers:
- Martin Blumenstingl <martin.blumenstingl@googlemail.com>
diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml
index 632d61c07f40..3aa1a46796dd 100644
--- a/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml
@@ -2,8 +2,8 @@
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/marvell,armada-3700-utmi-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/marvell,armada-3700-utmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell Armada UTMI/UTMI+ PHY
diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-375-usb-cluster.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-375-usb-cluster.yaml
new file mode 100644
index 000000000000..1706c31644e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,armada-375-usb-cluster.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,armada-375-usb-cluster.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Armada 375 USB Cluster
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description:
+ Control register for the Armada 375 USB cluster, managing USB2 and USB3 features.
+
+properties:
+ compatible:
+ const: marvell,armada-375-usb-cluster
+
+ reg:
+ maxItems: 1
+
+ '#phy-cells':
+ description: Number of PHY cells in specifier. 1 for USB2, 2 for USB3.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ usbcluster: usb-cluster@18400 {
+ compatible = "marvell,armada-375-usb-cluster";
+ reg = <0x18400 0x4>;
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-380-comphy.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-380-comphy.yaml
new file mode 100644
index 000000000000..dcb4c0007832
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,armada-380-comphy.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,armada-380-comphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x COMPHY controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+description:
+ This comphy controller can be found on Marvell Armada 38x. It provides a
+ number of shared PHYs used by various interfaces (network, sata, usb,
+ PCIe...).
+
+properties:
+ compatible:
+ items:
+ - const: marvell,armada-380-comphy
+
+ reg:
+ items:
+ - description: COMPHY register location and length
+ - description: Configuration register location and length
+
+ reg-names:
+ items:
+ - const: comphy
+ - const: conf
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^phy@[0-5]$':
+ description: A COMPHY lane
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maximum: 1
+
+ '#phy-cells':
+ description: Input port index for the PHY lane
+ const: 1
+
+ required:
+ - reg
+ - '#phy-cells'
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ comphy: phy@18300 {
+ compatible = "marvell,armada-380-comphy";
+ reg = <0x18300 0x100>, <0x18460 4>;
+ reg-names = "comphy", "conf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpm_comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ cpm_comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml
index 30f3b5f32a95..2ef02aac042a 100644
--- a/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml
@@ -2,8 +2,8 @@
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/marvell,armada-cp110-utmi-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/marvell,armada-cp110-utmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell Armada CP110/CP115 UTMI PHY
@@ -41,7 +41,13 @@ properties:
Phandle to the system controller node
$ref: /schemas/types.yaml#/definitions/phandle
-#Required child nodes:
+ swap-dx-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Specifies the ports which will swap the differential-pair (D+/D-),
+ default is not-swapped.
+
+# Required child nodes:
patternProperties:
"^usb-phy@[0|1]$":
diff --git a/Documentation/devicetree/bindings/phy/marvell,berlin2-sata-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,berlin2-sata-phy.yaml
new file mode 100644
index 000000000000..6fc9ff96e682
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,berlin2-sata-phy.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,berlin2-sata-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Berlin SATA PHY
+
+maintainers:
+ - Antoine Tenart <atenart@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - marvell,berlin2-sata-phy
+ - marvell,berlin2q-sata-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#phy-cells':
+ const: 1
+
+patternProperties:
+ '^sata-phy@[0-1]$':
+ description: A SATA PHY sub-node.
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ maximum: 1
+ description: PHY index number.
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#address-cells'
+ - '#size-cells'
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/berlin2q.h>
+
+ phy@f7e900a0 {
+ compatible = "marvell,berlin2q-sata-phy";
+ reg = <0xf7e900a0 0x200>;
+ clocks = <&chip CLKID_SATA>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+
+ sata-phy@0 {
+ reg = <0>;
+ };
+
+ sata-phy@1 {
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,berlin2-usb-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,berlin2-usb-phy.yaml
new file mode 100644
index 000000000000..b401e12a600c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,berlin2-usb-phy.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,berlin2-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Berlin USB PHY
+
+maintainers:
+ - Antoine Tenart <atenart@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - marvell,berlin2-usb-phy
+ - marvell,berlin2cd-usb-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@f774000 {
+ compatible = "marvell,berlin2-usb-phy";
+ reg = <0xf774000 0x128>;
+ #phy-cells = <0>;
+ resets = <&chip 0x104 14>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,comphy-cp110.yaml b/Documentation/devicetree/bindings/phy/marvell,comphy-cp110.yaml
new file mode 100644
index 000000000000..c35d31642805
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,comphy-cp110.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,comphy-cp110.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MVEBU COMPHY Controller
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: >
+ COMPHY controllers can be found on the following Marvell MVEBU SoCs:
+
+ * Armada 7k/8k (on the CP110)
+ * Armada 3700
+
+ It provides a number of shared PHYs used by various interfaces (network, SATA,
+ USB, PCIe...).
+
+properties:
+ compatible:
+ enum:
+ - marvell,comphy-cp110
+ - marvell,comphy-a3700
+
+ reg:
+ minItems: 1
+ items:
+ - description: Generic COMPHY registers
+ - description: Lane 1 (PCIe/GbE) registers (Armada 3700)
+ - description: Lane 0 (USB3/GbE) registers (Armada 3700)
+ - description: Lane 2 (SATA/USB3) registers (Armada 3700)
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: comphy
+ - const: lane1_pcie_gbe
+ - const: lane0_usb3_gbe
+ - const: lane2_sata_usb3
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ marvell,system-controller:
+ description: Phandle to the Marvell system controller (CP110 only)
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+patternProperties:
+ '^phy@[0-5]$':
+ description: A COMPHY lane child node
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ description: COMPHY lane number
+ maximum: 5
+
+ '#phy-cells':
+ const: 1
+
+ connector:
+ type: object
+
+ required:
+ - reg
+ - '#phy-cells'
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: marvell,comphy-a3700
+
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ const: xtal
+
+ required:
+ - reg-names
+
+ else:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ items:
+ - const: mg_clk
+ - const: mg_core_clk
+ - const: axi_clk
+
+ required:
+ - marvell,system-controller
+
+examples:
+ - |
+ phy@120000 {
+ compatible = "marvell,comphy-cp110";
+ reg = <0x120000 0x6000>;
+ clocks = <&clk 1 5>, <&clk 1 6>, <&clk 1 18>;
+ clock-names = "mg_clk", "mg_core_clk", "axi_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ marvell,system-controller = <&syscon0>;
+
+ phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+ };
+
+ - |
+ phy@18300 {
+ compatible = "marvell,comphy-a3700";
+ reg = <0x18300 0x300>,
+ <0x1F000 0x400>,
+ <0x5C000 0x400>,
+ <0xe0178 0x8>;
+ reg-names = "comphy",
+ "lane1_pcie_gbe",
+ "lane0_usb3_gbe",
+ "lane2_sata_usb3";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ comphy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+
+ comphy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <1>;
+ };
+
+ comphy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp2-usb-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp2-usb-phy.yaml
new file mode 100644
index 000000000000..af1ae2406f65
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,mmp2-usb-phy.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,mmp2-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MMP2/PXA USB PHY
+
+maintainers:
+ - Lubomir Rintel <lkundrak@v3.sk>
+
+properties:
+ compatible:
+ enum:
+ - marvell,mmp2-usb-phy
+ - marvell,pxa910-usb-phy
+ - marvell,pxa168-usb-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ usbphy@d4207000 {
+ compatible = "marvell,mmp2-usb-phy";
+ reg = <0xd4207000 0x40>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
index ff255aa4cc10..bd3bd2f8b1cd 100644
--- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Lubomir Rintel <lkundrak@v3.sk>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/marvell,mmp3-hsic-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/marvell,mmp3-hsic-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell MMP3 HSIC PHY
diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-usb-phy.yaml
index c97043eaa8fb..be13113f7b47 100644
--- a/Documentation/devicetree/bindings/phy/marvell,mmp3-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-usb-phy.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/phy/marvell,mmp3-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell MMP3 USB PHY bindings
+title: Marvell MMP3 USB PHY
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
diff --git a/Documentation/devicetree/bindings/phy/marvell,mvebu-sata-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mvebu-sata-phy.yaml
new file mode 100644
index 000000000000..81e942428911
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,mvebu-sata-phy.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,mvebu-sata-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell MVEBU SATA PHY
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ const: marvell,mvebu-sata-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: sata
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ sata-phy@84000 {
+ compatible = "marvell,mvebu-sata-phy";
+ reg = <0x84000 0x0334>;
+ clocks = <&gate_clk 15>;
+ clock-names = "sata";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/marvell,pxa1928-usb-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,pxa1928-usb-phy.yaml
new file mode 100644
index 000000000000..be33f036cda8
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/marvell,pxa1928-usb-phy.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/marvell,pxa1928-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell PXA1928 USB/HSIC PHY
+
+maintainers:
+ - Duje Mihanović <duje.mihanovic@skole.hr>
+
+properties:
+ compatible:
+ enum:
+ - marvell,pxa1928-usb-phy
+ - marvell,pxa1928-hsic-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/marvell,pxa1928.h>
+
+ usbphy: phy@7000 {
+ compatible = "marvell,pxa1928-usb-phy";
+ reg = <0x7000 0xe0>;
+ clocks = <&apmu PXA1928_CLK_USB>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
index 9c2a7345955d..acdbce937b0a 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
+title: MediaTek MIPI Display Serial Interface (DSI) PHY
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
@@ -26,6 +26,13 @@ properties:
- const: mediatek,mt2701-mipi-tx
- items:
- enum:
+ - mediatek,mt6795-mipi-tx
+ - const: mediatek,mt8173-mipi-tx
+ - items:
+ - enum:
+ - mediatek,mt6893-mipi-tx
+ - mediatek,mt8188-mipi-tx
+ - mediatek,mt8195-mipi-tx
- mediatek,mt8365-mipi-tx
- const: mediatek,mt8183-mipi-tx
- const: mediatek,mt2701-mipi-tx
@@ -83,7 +90,7 @@ examples:
clocks = <&clk26m>;
clock-output-names = "mipi_tx0_pll";
drive-strength-microamp = <4000>;
- nvmem-cells= <&mipi_tx_calibration>;
+ nvmem-cells = <&mipi_tx_calibration>;
nvmem-cell-names = "calibration-data";
#clock-cells = <0>;
#phy-cells = <0>;
diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
index 0d94950b84ca..f3a8b0b745d1 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
+title: MediaTek High Definition Multimedia Interface (HDMI) PHY
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
@@ -28,6 +28,7 @@ properties:
- const: mediatek,mt2701-hdmi-phy
- const: mediatek,mt2701-hdmi-phy
- const: mediatek,mt8173-hdmi-phy
+ - const: mediatek,mt8195-hdmi-phy
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
index 29d4123323c2..99eac888ae03 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/mediatek,mt7621-pci-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/mediatek,mt7621-pci-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek Mt7621 PCIe PHY Device Tree Bindings
+title: Mediatek Mt7621 PCIe PHY
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7628-usbphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7628-usbphy.yaml
new file mode 100644
index 000000000000..ce2c228e3216
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt7628-usbphy.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt7628-usbphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek/Ralink USB PHY
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7620-usbphy
+ - mediatek,mt7628-usbphy
+ - ralink,rt3352-usbphy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ ralink,sysctl:
+ description:
+ phandle to a ralink syscon register region.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ resets:
+ items:
+ - description: USB Host reset controller
+ - description: USB Device reset controller
+
+ reset-names:
+ items:
+ - const: host
+ - const: device
+
+required:
+ - compatible
+ - "#phy-cells"
+ - ralink,sysctl
+ - resets
+ - reset-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7628-usbphy
+ then:
+ required:
+ - reg
+ else:
+ properties:
+ reg: false
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@10120000 {
+ compatible = "mediatek,mt7628-usbphy";
+ reg = <0x10120000 0x1000>;
+ #phy-cells = <0>;
+ ralink,sysctl = <&sysc>;
+ resets = <&rstctrl 22>,
+ <&rstctrl 25>;
+ reset-names = "host", "device";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7988-xfi-tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7988-xfi-tphy.yaml
new file mode 100644
index 000000000000..cc9d0d4eeeeb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt7988-xfi-tphy.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt7988-xfi-tphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 XFI T-PHY
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ The MediaTek XFI SerDes T-PHY provides the physical SerDes lanes
+ used by the (10G/5G) USXGMII PCS and (1G/2.5G) LynxI PCS found in
+ MediaTek's 10G-capabale MT7988 SoC.
+ In MediaTek's SDK sources, this unit is referred to as "pextp".
+
+properties:
+ compatible:
+ const: mediatek,mt7988-xfi-tphy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XFI PHY clock
+ - description: XFI register clock
+
+ clock-names:
+ items:
+ - const: xfipll
+ - const: topxtal
+
+ resets:
+ items:
+ - description: Reset controller corresponding to the phy instance.
+
+ mediatek,usxgmii-performance-errata:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ One instance of the T-PHY on MT7988 suffers from a performance
+ problem in 10GBase-R mode which needs a work-around in the driver.
+ This flag enables a work-around adjusting an analog phy setting and
+ is required for XFI Port0 of the MT7988 SoC to be in compliance with
+ the SFP specification.
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mediatek,mt7988-clk.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ phy@11f20000 {
+ compatible = "mediatek,mt7988-xfi-tphy";
+ reg = <0 0x11f20000 0 0x10000>;
+ clocks = <&xfi_pll CLK_XFIPLL_PLL_EN>,
+ <&topckgen CLK_TOP_XFI_PHY_0_XTAL_SEL>;
+ clock-names = "xfipll", "topxtal";
+ resets = <&watchdog 14>;
+ mediatek,usxgmii-performance-errata;
+ #phy-cells = <0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
new file mode 100644
index 000000000000..2127a5732f73
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek, BayLibre
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt8365-csi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Sensor Interface MIPI CSI CD-PHY
+
+maintainers:
+ - Julien Stephan <jstephan@baylibre.com>
+ - Andy Hsieh <andy.hsieh@mediatek.com>
+
+description:
+ The SENINF CD-PHY is a set of CD-PHY connected to the SENINF CSI-2
+ receivers. The number of PHYs depends on the SoC model.
+ Depending on the SoC model, each PHYs can be either CD-PHY or D-PHY only
+ capable.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8365-csi-rx
+
+ reg:
+ maxItems: 1
+
+ num-lanes:
+ enum: [2, 3, 4]
+
+ '#phy-cells':
+ enum: [0, 1]
+ description: |
+ If the PHY doesn't support mode selection then #phy-cells must be 0 and
+ PHY mode is described using phy-type property.
+ If the PHY supports mode selection, then #phy-cells must be 1 and mode
+ is set in the PHY cells. Supported modes are:
+ - PHY_TYPE_DPHY
+ - PHY_TYPE_CPHY
+ See include/dt-bindings/phy/phy.h for constants.
+
+ phy-type:
+ description:
+ If the PHY doesn't support mode selection then this set the operating mode.
+ See include/dt-bindings/phy/phy.h for constants.
+ const: 10
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - num-lanes
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/phy/phy.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ csi0_rx: phy@11c10000 {
+ compatible = "mediatek,mt8365-csi-rx";
+ reg = <0 0x11c10000 0 0x2000>;
+ num-lanes = <2>;
+ #phy-cells = <1>;
+ };
+
+ csi1_rx: phy@11c12000 {
+ compatible = "mediatek,mt8365-csi-rx";
+ reg = <0 0x11c12000 0 0x2000>;
+ phy-type = <PHY_TYPE_DPHY>;
+ num-lanes = <2>;
+ #phy-cells = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index b3e409988c17..ff5c77ef1176 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek T-PHY Controller Device Tree Bindings
+title: MediaTek T-PHY Controller
maintainers:
- Chunfeng Yun <chunfeng.yun@mediatek.com>
@@ -64,7 +64,7 @@ description: |
properties:
$nodename:
- pattern: "^t-phy@[0-9a-f]+$"
+ pattern: "^t-phy(@[0-9a-f]+)?$"
compatible:
oneOf:
@@ -78,7 +78,10 @@ properties:
- items:
- enum:
- mediatek,mt2712-tphy
+ - mediatek,mt6893-tphy
- mediatek,mt7629-tphy
+ - mediatek,mt7981-tphy
+ - mediatek,mt7986-tphy
- mediatek,mt8183-tphy
- mediatek,mt8186-tphy
- mediatek,mt8192-tphy
@@ -124,6 +127,16 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
default: 28
+ power-domains:
+ description:
+ The TPHY of MediaTek should exist within a power domain. The
+ developer should be aware that the hardware design of MediaTek TPHY
+ does not require the addition of MTCMOS. If the power to the TPHY
+ is turned off, it will impact other functions. From the current
+ perspective of USB hardware design, even if MTCMOS is added to the
+ TPHY, it should remain always on.
+ maxItems: 1
+
# Required child node:
patternProperties:
"^(usb|pcie|sata)-phy@[0-9a-f]+$":
@@ -163,6 +176,7 @@ patternProperties:
- PHY_TYPE_USB3
- PHY_TYPE_PCIE
- PHY_TYPE_SATA
+ - PHY_TYPE_SGMII
nvmem-cells:
items:
@@ -218,11 +232,30 @@ patternProperties:
minimum: 1
maximum: 15
+ mediatek,pre-emphasis:
+ description:
+ The level of pre-emphasis which used to widen the eye opening and
+ boost eye swing, the unit step is about 4.16% increment; e.g. the
+ level 1 means amplitude increases about 4.16%, the level 2 is about
+ 8.3% etc. (U2 phy)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 3
+
mediatek,bc12:
description:
Specify the flag to enable BC1.2 if support it
type: boolean
+ mediatek,force-mode:
+ description:
+ The force mode is used to manually switch the shared phy mode between
+ USB3 and PCIe, when USB3 phy type is selected by the consumer, and
+ force-mode is set, will cause phy's power and pipe toggled and force
+ phy as USB3 mode which switched from default PCIe mode. But prefer to
+ use the property "mediatek,syscon-type" for newer SoCs that support it.
+ type: boolean
+
mediatek,syscon-type:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
index 74cc32c1d2e8..6e2edd43fc2a 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
@@ -5,11 +5,12 @@
$id: http://devicetree.org/schemas/phy/mediatek,ufs-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek Universal Flash Storage (UFS) M-PHY binding
+title: MediaTek Universal Flash Storage (UFS) M-PHY
maintainers:
- - Stanley Chu <stanley.chu@mediatek.com>
- Chunfeng Yun <chunfeng.yun@mediatek.com>
+ - Peter Wang <peter.wang@mediatek.com>
+ - Chaotian Jing <chaotian.jing@mediatek.com>
description: |
UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
index 598fd2b95c29..0bed847bb4ad 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/phy/mediatek,xsphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek XS-PHY Controller Device Tree Bindings
+title: MediaTek XS-PHY Controller
maintainers:
- Chunfeng Yun <chunfeng.yun@mediatek.com>
@@ -49,6 +49,7 @@ properties:
- enum:
- mediatek,mt3611-xsphy
- mediatek,mt3612-xsphy
+ - mediatek,mt7988-xsphy
- const: mediatek,xsphy
reg:
@@ -150,6 +151,21 @@ patternProperties:
minimum: 1
maximum: 31
+ mediatek,syscon-type:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ A phandle to syscon used to access the register of type switch,
+ the field should always be 3 cells long.
+ items:
+ - items:
+ - description:
+ Phandle to phy type configuration system controller
+ - description:
+ Phy type configuration register offset
+ - description:
+ Index of config segment
+ enum: [0, 1, 2, 3]
+
required:
- reg
- clocks
diff --git a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
deleted file mode 100644
index b84a02ebffdf..000000000000
--- a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Amlogic Meson GXL and GXM USB2 PHY binding
-
-Required properties:
-- compatible: Should be "amlogic,meson-gxl-usb2-phy"
-- reg: The base address and length of the registers
-- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
-
-Optional properties:
-- clocks: a phandle to the clock of this PHY
-- clock-names: must be "phy"
-- resets: a phandle to the reset line of this PHY
-- reset-names: must be "phy"
-- phy-supply: see phy-bindings.txt in this directory
-
-
-Example:
- usb2_phy0: phy@78000 {
- compatible = "amlogic,meson-gxl-usb2-phy";
- #phy-cells = <0>;
- reg = <0x0 0x78000 0x0 0x20>;
- };
diff --git a/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml b/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
index bdbdb3bbddbe..fa0b02916dac 100644
--- a/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
+++ b/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
@@ -8,6 +8,7 @@ title: Microchip Sparx5 Serdes controller
maintainers:
- Steen Hegelund <steen.hegelund@microchip.com>
+ - Daniel Machon <daniel.machon@microchip.com>
description: |
The Sparx5 SERDES interfaces share the same basic functionality, but
@@ -62,12 +63,26 @@ description: |
* 10.3125 Gbps (10GBASE-R/10GBASE-KR/USXGMII)
* 25.78125 Gbps (25GBASE-KR/25GBASE-CR/25GBASE-SR/25GBASE-LR/25GBASE-ER)
+ lan969x has ten SERDES10G interfaces that share the same features, operating
+ modes and data rates as the equivalent Sparx5 SERDES10G interfaces.
+
properties:
$nodename:
pattern: "^serdes@[0-9a-f]+$"
compatible:
- const: microchip,sparx5-serdes
+ oneOf:
+ - enum:
+ - microchip,sparx5-serdes
+ - microchip,lan9691-serdes
+ - items:
+ - enum:
+ - microchip,lan9698-serdes
+ - microchip,lan9696-serdes
+ - microchip,lan9694-serdes
+ - microchip,lan9693-serdes
+ - microchip,lan9692-serdes
+ - const: microchip,lan9691-serdes
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
index 786cfd71cb7e..286a4fcc977d 100644
--- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
@@ -32,15 +32,6 @@ properties:
clock-names:
const: phy_ref
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-parents:
- maxItems: 1
-
- assigned-clock-rates:
- maxItems: 1
-
"#phy-cells":
const: 0
@@ -81,11 +72,6 @@ allOf:
contains:
const: fsl,imx8qxp-mipi-dphy
then:
- properties:
- assigned-clocks: false
- assigned-clock-parents: false
- assigned-clock-rates: false
-
required:
- fsl,syscon
diff --git a/Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml b/Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
new file mode 100644
index 000000000000..dd345cbd0a0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/motorola,cpcap-usb-phy.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/motorola,cpcap-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola CPCAP PMIC USB PHY
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ enum:
+ - motorola,cpcap-usb-phy
+ - motorola,mapphone-cpcap-usb-phy
+
+ '#phy-cells':
+ const: 0
+
+ interrupts:
+ description: CPCAP PMIC interrupts used by the USB PHY
+ items:
+ - description: id_ground interrupt
+ - description: id_float interrupt
+ - description: se0conn interrupt
+ - description: vbusvld interrupt
+ - description: sessvld interrupt
+ - description: sessend interrupt
+ - description: se1 interrupt
+ - description: dm interrupt
+ - description: dp interrupt
+
+ interrupt-names:
+ description: Interrupt names
+ items:
+ - const: id_ground
+ - const: id_float
+ - const: se0conn
+ - const: vbusvld
+ - const: sessvld
+ - const: sessend
+ - const: se1
+ - const: dm
+ - const: dp
+
+ io-channels:
+ description: IIO ADC channels used by the USB PHY
+ items:
+ - description: vbus channel
+ - description: id channel
+
+ io-channel-names:
+ items:
+ - const: vbus
+ - const: id
+
+ vusb-supply: true
+
+ pinctrl-names:
+ items:
+ - const: default
+ - const: ulpi
+ - const: utmi
+ - const: uart
+
+ mode-gpios:
+ description: Optional GPIOs for configuring alternate modes
+ items:
+ - description: mode selection GPIO#0
+ - description: mode selection GPIO#1
+
+required:
+ - compatible
+ - '#phy-cells'
+ - interrupts-extended
+ - interrupt-names
+ - io-channels
+ - io-channel-names
+ - vusb-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ phy {
+ compatible = "motorola,mapphone-cpcap-usb-phy";
+ #phy-cells = <0>;
+ interrupts-extended = <
+ &cpcap 15 0 &cpcap 14 0 &cpcap 28 0 &cpcap 19 0
+ &cpcap 18 0 &cpcap 17 0 &cpcap 16 0 &cpcap 49 0
+ &cpcap 48 1
+ >;
+ interrupt-names = "id_ground", "id_float", "se0conn", "vbusvld",
+ "sessvld", "sessend", "se1", "dm", "dp";
+ io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
+ io-channel-names = "vbus", "id";
+ vusb-supply = <&vusb>;
+ pinctrl-0 = <&usb_gpio_mux_sel1 &usb_gpio_mux_sel2>;
+ pinctrl-1 = <&usb_ulpi_pins>;
+ pinctrl-2 = <&usb_utmi_pins>;
+ pinctrl-3 = <&uart3_pins>;
+ pinctrl-names = "default", "ulpi", "utmi", "uart";
+ mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/motorola,mapphone-mdm6600.yaml b/Documentation/devicetree/bindings/phy/motorola,mapphone-mdm6600.yaml
new file mode 100644
index 000000000000..cb6544b3478d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/motorola,mapphone-mdm6600.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/motorola,mapphone-mdm6600.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola Mapphone MDM6600 USB PHY
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ items:
+ - const: motorola,mapphone-mdm6600
+
+ enable-gpios:
+ description: GPIO to enable the USB PHY
+ maxItems: 1
+
+ power-gpios:
+ description: GPIO to power on the device
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO to reset the device
+ maxItems: 1
+
+ motorola,mode-gpios:
+ description: Two GPIOs to configure MDM6600 USB start-up mode for normal mode versus USB flashing mode
+ items:
+ - description: normal mode select GPIO
+ - description: USB flashing mode select GPIO
+
+ motorola,cmd-gpios:
+ description: Three GPIOs to control the power state of the MDM6600
+ items:
+ - description: power state control GPIO 0
+ - description: power state control GPIO 1
+ - description: power state control GPIO 2
+
+ motorola,status-gpios:
+ description: Three GPIOs to read the power state of the MDM6600
+ items:
+ - description: power state read GPIO 0
+ - description: power state read GPIO 1
+ - description: power state read GPIO 2
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - enable-gpios
+ - power-gpios
+ - reset-gpios
+ - motorola,mode-gpios
+ - motorola,cmd-gpios
+ - motorola,status-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb-phy {
+ compatible = "motorola,mapphone-mdm6600";
+ enable-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
+ power-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio2 17 GPIO_ACTIVE_HIGH>;
+ motorola,mode-gpios = <&gpio5 20 GPIO_ACTIVE_HIGH>,
+ <&gpio5 21 GPIO_ACTIVE_HIGH>;
+ motorola,cmd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>,
+ <&gpio4 8 GPIO_ACTIVE_HIGH>,
+ <&gpio5 14 GPIO_ACTIVE_HIGH>;
+ motorola,status-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>,
+ <&gpio2 21 GPIO_ACTIVE_HIGH>,
+ <&gpio2 23 GPIO_ACTIVE_HIGH>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/mscc,vsc7514-serdes.yaml b/Documentation/devicetree/bindings/phy/mscc,vsc7514-serdes.yaml
new file mode 100644
index 000000000000..3169b873231e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mscc,vsc7514-serdes.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mscc,vsc7514-serdes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microsemi Ocelot SerDes muxing
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+ - UNGLinuxDriver@microchip.com
+
+description: |
+ On Microsemi Ocelot, there is a handful of registers in HSIO address
+ space for setting up the SerDes to switch port muxing.
+
+ A SerDes X can be "muxed" to work with switch port Y or Z for example.
+ One specific SerDes can also be used as a PCIe interface.
+
+ Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one.
+
+ There are two kinds of SerDes: SERDES1G supports 10/100Mbps in
+ half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports
+ 10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode.
+
+ Also, SERDES6G number (aka "macro") 0 is the only interface supporting
+ QSGMII.
+
+ This is a child of the HSIO syscon ("mscc,ocelot-hsio", see
+ Documentation/devicetree/bindings/mips/mscc.txt) on the Microsemi Ocelot.
+
+properties:
+ compatible:
+ enum:
+ - mscc,vsc7514-serdes
+
+ "#phy-cells":
+ const: 2
+ description: |
+ The first number defines the input port to use for a given SerDes macro.
+ The second defines the macro to use. They are defined in
+ dt-bindings/phy/phy-ocelot-serdes.h
+
+required:
+ - compatible
+ - "#phy-cells"
+
+additionalProperties:
+ false
+
+examples:
+ - |
+ serdes: serdes {
+ compatible = "mscc,vsc7514-serdes";
+ #phy-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
deleted file mode 100644
index c9e392c64a7c..000000000000
--- a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Freescale MXS USB Phy Device
-
-Required properties:
-- compatible: should contain:
- * "fsl,imx23-usbphy" for imx23 and imx28
- * "fsl,imx6q-usbphy" for imx6dq and imx6dl
- * "fsl,imx6sl-usbphy" for imx6sl
- * "fsl,vf610-usbphy" for Vybrid vf610
- * "fsl,imx6sx-usbphy" for imx6sx
- * "fsl,imx7ulp-usbphy" for imx7ulp
- * "fsl,imx8dxl-usbphy" for imx8dxl
- "fsl,imx23-usbphy" is still a fallback for other strings
-- reg: Should contain registers location and length
-- interrupts: Should contain phy interrupt
-- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series
-
-Optional properties:
-- fsl,tx-cal-45-dn-ohms: Integer [30-55]. Resistance (in ohms) of switchable
- high-speed trimming resistor connected in parallel with the 45 ohm resistor
- that terminates the DN output signal. Default: 45
-- fsl,tx-cal-45-dp-ohms: Integer [30-55]. Resistance (in ohms) of switchable
- high-speed trimming resistor connected in parallel with the 45 ohm resistor
- that terminates the DP output signal. Default: 45
-- fsl,tx-d-cal: Integer [79-119]. Current trimming value (as a percentage) of
- the 17.78mA TX reference current. Default: 100
-
-Example:
-usbphy1: usb-phy@20c9000 {
- compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
- reg = <0x020c9000 0x1000>;
- interrupts = <0 44 0x04>;
- fsl,anatop = <&anatop>;
-};
diff --git a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
new file mode 100644
index 000000000000..fff858c909a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nuvoton,ma35d1-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 USB2 phy
+
+maintainers:
+ - Hui-Ping Chen <hpchen0nvt@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,ma35d1-usb2-phy
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ nuvoton,sys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to syscon for checking the PHY clock status.
+
+required:
+ - compatible
+ - "#phy-cells"
+ - clocks
+ - nuvoton,sys
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+ usb_phy: usb-phy {
+ compatible = "nuvoton,ma35d1-usb2-phy";
+ clocks = <&clk USBD_GATE>;
+ nuvoton,sys = <&sys>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
deleted file mode 100644
index b62397d2bb0c..000000000000
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
+++ /dev/null
@@ -1,779 +0,0 @@
-Device tree binding for NVIDIA Tegra XUSB pad controller
-========================================================
-
-The Tegra XUSB pad controller manages a set of I/O lanes (with differential
-signals) which connect directly to pins/pads on the SoC package. Each lane
-is controlled by a HW block referred to as a "pad" in the Tegra hardware
-documentation. Each such "pad" may control either one or multiple lanes,
-and thus contains any logic common to all its lanes. Each lane can be
-separately configured and powered up.
-
-Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
-super-speed USB. Other lanes are for various types of low-speed, full-speed
-or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
-contains a software-configurable mux that sits between the I/O controller
-ports (e.g. PCIe) and the lanes.
-
-In addition to per-lane configuration, USB 3.0 ports may require additional
-settings on a per-board basis.
-
-Pads will be represented as children of the top-level XUSB pad controller
-device tree node. Each lane exposed by the pad will be represented by its
-own subnode and can be referenced by users of the lane using the standard
-PHY bindings, as described by the phy-bindings.txt file in this directory.
-
-The Tegra hardware documentation refers to the connection between the XUSB
-pad controller and the XUSB controller as "ports". This is confusing since
-"port" is typically used to denote the physical USB receptacle. The device
-tree binding in this document uses the term "port" to refer to the logical
-abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
-for the USB signal, the VBUS power supply, the USB 2.0 companion port for
-USB 3.0 receptacles, ...).
-
-Required properties:
---------------------
-- compatible: Must be:
- - Tegra124: "nvidia,tegra124-xusb-padctl"
- - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
- - Tegra210: "nvidia,tegra210-xusb-padctl"
- - Tegra186: "nvidia,tegra186-xusb-padctl"
- - Tegra194: "nvidia,tegra194-xusb-padctl"
-- reg: Physical base address and length of the controller's registers.
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must include the following entries:
- - "padctl"
-
-For Tegra124:
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- avdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
-
-For Tegra210:
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V.
-- nvidia,pmc: phandle and specifier referring to the Tegra210 PMC node.
-
-For Tegra186:
-- avdd-pll-erefeut-supply: UPHY brick and reference clock as well as UTMI PHY
- power supply. Must supply 1.8 V.
-- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
- 3.3 V.
-- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
-- vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V.
-
-For Tegra194:
-- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
- 3.3 V.
-- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
-
-Pad nodes:
-==========
-
-A required child node named "pads" contains a list of subnodes, one for each
-of the pads exposed by the XUSB pad controller. Each pad may need additional
-resources that can be referenced in its pad node.
-
-The "status" property is used to enable or disable the use of a pad. If set
-to "disabled", the pad will not be used on the given board. In order to use
-the pad and any of its lanes, this property must be set to "okay".
-
-For Tegra124 and Tegra132, the following pads exist: usb2, ulpi, hsic, pcie
-and sata. No extra resources are required for operation of these pads.
-
-For Tegra210, the following pads exist: usb2, hsic, pcie and sata. Below is
-a description of the properties of each pad.
-
-UTMI pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "trk": phandle and specifier referring to the USB2 tracking clock
-
-HSIC pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "trk": phandle and specifier referring to the HSIC tracking clock
-
-PCIe pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "pll": phandle and specifier referring to the PLLE
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must contain the following entries:
- - "phy": reset for the PCIe UPHY block
-
-SATA pad:
----------
-
-Required properties:
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must contain the following entries:
- - "phy": reset for the SATA UPHY block
-
-
-PHY nodes:
-==========
-
-Each pad node has a child named "lanes" that contains one or more children of
-its own, each representing one of the lanes controlled by the pad.
-
-Required properties:
---------------------
-- status: Defines the operation status of the PHY. Valid values are:
- - "disabled": the PHY is disabled
- - "okay": the PHY is enabled
-- #phy-cells: Should be 0. Since each lane represents a single PHY, there is
- no need for an additional specifier.
-- nvidia,function: The output function of the PHY. See below for a list of
- valid functions per SoC generation.
-
-For Tegra124 and Tegra132, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2
- - functions: "snps", "xusb", "uart"
-- ulpi: ulpi-0
- - functions: "snps", "xusb"
-- hsic: hsic-0, hsic-1
- - functions: "snps", "xusb"
-- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4
- - functions: "pcie", "usb3-ss"
-- sata: sata-0
- - functions: "usb3-ss", "sata"
-
-For Tegra210, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2, usb2-3
- - functions: "snps", "xusb", "uart"
-- hsic: hsic-0, hsic-1
- - functions: "snps", "xusb"
-- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6
- - functions: "pcie-x1", "usb3-ss", "pcie-x4"
-- sata: sata-0
- - functions: "usb3-ss", "sata"
-
-For Tegra194, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2, usb2-3
- - functions: "xusb"
-- usb3: usb3-0, usb3-1, usb3-2, usb3-3
- - functions: "xusb"
-
-Port nodes:
-===========
-
-A required child node named "ports" contains a list of all the ports exposed
-by the XUSB pad controller. Per-port configuration is only required for USB.
-
-USB2 ports:
------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- mode: A string that determines the mode in which to run the port. Valid
- values are:
- - "host": for USB host mode
- - "device": for USB device mode
- - "otg": for USB OTG mode
-
-Required properties for OTG/Peripheral capable USB2 ports:
-- usb-role-switch: Boolean property to indicate that the port support OTG or
- peripheral mode. If present, the port supports switching between USB host
- and peripheral roles. Connector should be added as subnode.
- See usb/usb-conn-gpio.txt.
-
-Optional properties:
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-ULPI ports:
------------
-
-Optional properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-HSIC ports:
------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-
-Optional properties:
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-Super-speed USB ports:
-----------------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- nvidia,usb2-companion: A single cell that specifies the physical port number
- to map this super-speed USB port to. The range of valid port numbers varies
- with the SoC generation:
- - 0-2: for Tegra124 and Tegra132
- - 0-3: for Tegra210
-
-Optional properties:
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-
-- maximum-speed: Only for Tegra194. A string property that specifies maximum
- supported speed of a usb3 port. Valid values are:
- - "super-speed-plus": default, the usb3 port supports USB 3.1 Gen 2 speed.
- - "super-speed": the usb3 port supports USB 3.1 Gen 1 speed only.
-
-For Tegra124 and Tegra132, the XUSB pad controller exposes the following
-ports:
-- 3x USB2: usb2-0, usb2-1, usb2-2
-- 1x ULPI: ulpi-0
-- 2x HSIC: hsic-0, hsic-1
-- 2x super-speed USB: usb3-0, usb3-1
-
-For Tegra210, the XUSB pad controller exposes the following ports:
-- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
-- 2x HSIC: hsic-0, hsic-1
-- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
-
-For Tegra194, the XUSB pad controller exposes the following ports:
-- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
-- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
-
-Examples:
-=========
-
-Tegra124 and Tegra132:
-----------------------
-
-SoC include:
-
- padctl@7009f000 {
- /* for Tegra124 */
- compatible = "nvidia,tegra124-xusb-padctl";
- /* for Tegra132 */
- compatible = "nvidia,tegra132-xusb-padctl",
- "nvidia,tegra124-xusb-padctl";
- reg = <0x0 0x7009f000 0x0 0x1000>;
- resets = <&tegra_car 142>;
- reset-names = "padctl";
-
- pads {
- usb2 {
- status = "disabled";
-
- lanes {
- usb2-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- ulpi {
- status = "disabled";
-
- lanes {
- ulpi-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- hsic {
- status = "disabled";
-
- lanes {
- hsic-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- hsic-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- pcie {
- status = "disabled";
-
- lanes {
- pcie-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-4 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- sata {
- status = "disabled";
-
- lanes {
- sata-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "disabled";
- };
-
- usb2-1 {
- status = "disabled";
- };
-
- usb2-2 {
- status = "disabled";
- };
-
- ulpi-0 {
- status = "disabled";
- };
-
- hsic-0 {
- status = "disabled";
- };
-
- hsic-1 {
- status = "disabled";
- };
-
- usb3-0 {
- status = "disabled";
- };
-
- usb3-1 {
- status = "disabled";
- };
- };
- };
-
-Board file:
-
- padctl@7009f000 {
- status = "okay";
-
- pads {
- usb2 {
- status = "okay";
-
- lanes {
- usb2-0 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-1 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-2 {
- nvidia,function = "xusb";
- status = "okay";
- };
- };
- };
-
- pcie {
- status = "okay";
-
- lanes {
- pcie-0 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
-
- pcie-2 {
- nvidia,function = "pcie";
- status = "okay";
- };
-
- pcie-4 {
- nvidia,function = "pcie";
- status = "okay";
- };
- };
- };
-
- sata {
- status = "okay";
-
- lanes {
- sata-0 {
- nvidia,function = "sata";
- status = "okay";
- };
- };
- };
- };
-
- ports {
- /* Micro A/B */
- usb2-0 {
- status = "okay";
- mode = "otg";
- };
-
- /* Mini PCIe */
- usb2-1 {
- status = "okay";
- mode = "host";
- };
-
- /* USB3 */
- usb2-2 {
- status = "okay";
- mode = "host";
-
- vbus-supply = <&vdd_usb3_vbus>;
- };
-
- usb3-0 {
- nvidia,port = <2>;
- status = "okay";
- };
- };
- };
-
-Tegra210:
----------
-
-SoC include:
-
- padctl@7009f000 {
- compatible = "nvidia,tegra210-xusb-padctl";
- reg = <0x0 0x7009f000 0x0 0x1000>;
- resets = <&tegra_car 142>;
- reset-names = "padctl";
-
- status = "disabled";
-
- pads {
- usb2 {
- clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>;
- clock-names = "trk";
- status = "disabled";
-
- lanes {
- usb2-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- hsic {
- clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>;
- clock-names = "trk";
- status = "disabled";
-
- lanes {
- hsic-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- hsic-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- pcie {
- clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
- clock-names = "pll";
- resets = <&tegra_car 205>;
- reset-names = "phy";
- status = "disabled";
-
- lanes {
- pcie-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-4 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-5 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-6 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- sata {
- clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
- clock-names = "pll";
- resets = <&tegra_car 204>;
- reset-names = "phy";
- status = "disabled";
-
- lanes {
- sata-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "disabled";
- };
-
- usb2-1 {
- status = "disabled";
- };
-
- usb2-2 {
- status = "disabled";
- };
-
- usb2-3 {
- status = "disabled";
- };
-
- hsic-0 {
- status = "disabled";
- };
-
- hsic-1 {
- status = "disabled";
- };
-
- usb3-0 {
- status = "disabled";
- };
-
- usb3-1 {
- status = "disabled";
- };
-
- usb3-2 {
- status = "disabled";
- };
-
- usb3-3 {
- status = "disabled";
- };
- };
- };
-
-Board file:
-
- padctl@7009f000 {
- status = "okay";
-
- pads {
- usb2 {
- status = "okay";
-
- lanes {
- usb2-0 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-1 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-2 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-3 {
- nvidia,function = "xusb";
- status = "okay";
- };
- };
- };
-
- pcie {
- status = "okay";
-
- lanes {
- pcie-0 {
- nvidia,function = "pcie-x1";
- status = "okay";
- };
-
- pcie-1 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-2 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-3 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-4 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-5 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
-
- pcie-6 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
- };
- };
-
- sata {
- status = "okay";
-
- lanes {
- sata-0 {
- nvidia,function = "sata";
- status = "okay";
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "okay";
- mode = "otg";
- };
-
- usb2-1 {
- status = "okay";
- vbus-supply = <&vdd_5v0_rtl>;
- mode = "host";
- };
-
- usb2-2 {
- status = "okay";
- vbus-supply = <&vdd_usb_vbus>;
- mode = "host";
- };
-
- usb2-3 {
- status = "okay";
- mode = "host";
- };
-
- usb3-0 {
- status = "okay";
- nvidia,lanes = "pcie-6";
- nvidia,port = <1>;
- };
-
- usb3-1 {
- status = "okay";
- nvidia,lanes = "pcie-5";
- nvidia,port = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
new file mode 100644
index 000000000000..33b41b6b2fd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
@@ -0,0 +1,654 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra124-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra124 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra124-xusb-padctl
+
+ - items:
+ - const: nvidia,tegra132-xusb-padctl
+ - const: nvidia,tegra124-xusb-padctl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-erefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ avdd-pex-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 3.3 V.
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or be absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ ulpi:
+ type: object
+ additionalProperties: false
+ properties:
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ ulpi-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ hsic:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ pcie:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: PLLE clock
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: reset for the PCIe UPHY block
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ pcie-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ pcie-4:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie, usb3-ss ]
+
+ sata:
+ type: object
+ additionalProperties: false
+ properties:
+ resets:
+ items:
+ - description: reset for the SATA UPHY block
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ sata-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ sata, usb3-ss ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ ulpi-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - avdd-pll-utmip-supply
+ - avdd-pll-erefe-supply
+ - avdd-pex-pll-supply
+ - hvdd-pex-pll-e-supply
+
+examples:
+ # Tegra124 and Tegra132
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ padctl@7009f000 {
+ compatible = "nvidia,tegra124-xusb-padctl";
+ reg = <0x7009f000 0x1000>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&tegra_car 142>;
+ reset-names = "padctl";
+
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-pex-pll-supply = <&vdd_1v05_run>;
+ hvdd-pex-pll-e-supply = <&vdd_3v3_lp0>;
+
+ pads {
+ usb2 {
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ ulpi {
+ lanes {
+ ulpi-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ hsic-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ pcie {
+ lanes {
+ pcie-0 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+
+ pcie-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ pcie-2 {
+ nvidia,function = "pcie";
+ #phy-cells = <0>;
+ };
+
+ pcie-3 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ pcie-4 {
+ nvidia,function = "pcie";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ sata {
+ lanes {
+ sata-0 {
+ nvidia,function = "sata";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ /* Micro A/B */
+ usb2-0 {
+ mode = "otg";
+ };
+
+ /* Mini PCIe */
+ usb2-1 {
+ mode = "host";
+ };
+
+ /* USB3 */
+ usb2-2 {
+ vbus-supply = <&vdd_usb3_vbus>;
+ mode = "host";
+ };
+
+ ulpi-0 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ hsic-1 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <2>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml
new file mode 100644
index 000000000000..8b1d5a8529e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml
@@ -0,0 +1,544 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra186-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra186 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ const: nvidia,tegra186-xusb-padctl
+
+ reg:
+ items:
+ - description: pad controller registers
+ - description: AO registers
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ reg-names:
+ items:
+ - const: padctl
+ - const: ao
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-pll-erefeut-supply:
+ description: UPHY brick and reference clock as well as UTMI PHY
+ power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must
+ supply 3.3 V.
+
+ vclamp-usb-supply:
+ description: Bias rail for USB pad. Must supply 1.8 V.
+
+ vddio-hsic-supply:
+ description: HSIC PHY power supply. Must supply 1.2 V.
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or be absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ hsic:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3:
+ type: object
+ additionalProperties: false
+ properties:
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ hsic-0:
+ type: object
+ additionalProperties: false
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - avdd-pll-erefeut-supply
+ - avdd-usb-supply
+ - vclamp-usb-supply
+ - vddio-hsic-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra186-clock.h>
+ #include <dt-bindings/gpio/tegra186-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+
+ padctl@3520000 {
+ compatible = "nvidia,tegra186-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+
+ resets = <&bpmp TEGRA186_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ avdd-pll-erefeut-supply = <&vdd_1v8_pll>;
+ avdd-usb-supply = <&vdd_3v3_sys>;
+ vclamp-usb-supply = <&vdd_1v8>;
+ vddio-hsic-supply = <&gnd>;
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA186_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = <&bpmp TEGRA186_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ mode = "otg";
+ vbus-supply = <&vdd_usb0>;
+ usb-role-switch;
+
+ connector {
+ compatible = "gpio-usb-b-connector",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpios = <&gpio TEGRA186_MAIN_GPIO(X, 7) GPIO_ACTIVE_LOW>;
+ id-gpios = <&pmic 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_usb1>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
new file mode 100644
index 000000000000..6e3398399628
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
@@ -0,0 +1,632 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra194-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra194 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra194-xusb-padctl
+ - nvidia,tegra234-xusb-padctl
+
+ reg:
+ items:
+ - description: pad controller registers
+ - description: AO registers
+
+ reg-names:
+ items:
+ - const: padctl
+ - const: ao
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-usb-supply:
+ description: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must
+ supply 3.3 V.
+
+ vclamp-usb-supply:
+ description: Bias rail for USB pad. Must supply 1.8 V.
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3:
+ type: object
+ additionalProperties: false
+ properties:
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ usb3-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ xusb ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-3:
+ type: object
+ additionalProperties: false
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - avdd-usb-supply
+ - vclamp-usb-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra194-clock.h>
+ #include <dt-bindings/gpio/tegra194-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/tegra194-reset.h>
+
+ padctl@3520000 {
+ compatible = "nvidia,tegra194-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+
+ resets = <&bpmp TEGRA194_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ avdd-usb-supply = <&vdd_usb_3v3>;
+ vclamp-usb-supply = <&vdd_1v8ao>;
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA194_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ status = "disabled";
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_sys>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ usb2-3 {
+ vbus-supply = <&vdd_5v_sata>;
+ mode = "host";
+ };
+
+ usb3-0 {
+ vbus-supply = <&vdd_5v0_sys>;
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ maximum-speed = "super-speed";
+ vbus-supply = <&vdd_5v0_sys>;
+ nvidia,usb2-companion = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
new file mode 100644
index 000000000000..e9237c58ce45
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
@@ -0,0 +1,786 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra210-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra210 XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ const: nvidia,tegra210-xusb-padctl
+
+ reg:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ interrupts:
+ items:
+ - description: XUSB pad controller interrupt
+
+ reset-names:
+ items:
+ - const: padctl
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-uerefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ dvdd-pex-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 1.8 V.
+
+ nvidia,pmc:
+ description: phandle to the Tegra Power Management Controller (PMC) node
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay" or be absent.
+ type: object
+ additionalProperties: false
+ properties:
+ usb2:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb, uart ]
+
+ hsic:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ snps, xusb ]
+
+ pcie:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: PCIe PLL clock source
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: PCIe PHY reset
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ pcie-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-1:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-2:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-3:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-4:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-5:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ pcie-6:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ sata:
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ items:
+ - description: SATA PLL clock source
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: SATA PHY reset
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ additionalProperties: false
+ properties:
+ sata-0:
+ type: object
+ additionalProperties: false
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ description: Function selection for this lane.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ usb3-ss, sata ]
+
+ ports:
+ description: A required child node named "ports" contains a list of
+ subnodes, one for each of the ports exposed by the XUSB pad controller.
+ Each port may need additional resources that can be referenced in its
+ port node.
+
+ The "status" property is used to enable or disable the use of a port.
+ If set to "disabled", the port will not be used on the given board. In
+ order to use the port, this property must be set to "okay".
+ type: object
+ additionalProperties: false
+ properties:
+ usb2-0:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-1:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-2:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ usb2-3:
+ type: object
+ additionalProperties: false
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ hsic-0:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ hsic-1:
+ type: object
+ additionalProperties: false
+ properties:
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-0:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-3:
+ type: object
+ additionalProperties: false
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+additionalProperties: false
+
+required:
+ - avdd-pll-utmip-supply
+ - avdd-pll-uerefe-supply
+ - dvdd-pex-pll-supply
+ - hvdd-pex-pll-e-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ padctl@7009f000 {
+ compatible = "nvidia,tegra210-xusb-padctl";
+ reg = <0x7009f000 0x1000>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&tegra_car 142>;
+ reset-names = "padctl";
+
+ avdd-pll-utmip-supply = <&vdd_1v8>;
+ avdd-pll-uerefe-supply = <&vdd_pex_1v05>;
+ dvdd-pex-pll-supply = <&vdd_pex_1v05>;
+ hvdd-pex-pll-e-supply = <&vdd_1v8>;
+
+ pads {
+ usb2 {
+ clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ hsic-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ pcie {
+ clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "pll";
+ resets = <&tegra_car 205>;
+ reset-names = "phy";
+
+ lanes {
+ pcie-0 {
+ nvidia,function = "pcie-x1";
+ #phy-cells = <0>;
+ };
+
+ pcie-1 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-2 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-3 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-4 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-5 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+
+ pcie-6 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ sata {
+ clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "pll";
+ resets = <&tegra_car 204>;
+ reset-names = "phy";
+
+ lanes {
+ sata-0 {
+ nvidia,function = "sata";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ mode = "peripheral";
+ usb-role-switch;
+
+ connector {
+ compatible = "gpio-usb-b-connector",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpios = <&gpio TEGRA_GPIO(CC, 4) GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_rtl>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ vbus-supply = <&vdd_usb_vbus>;
+ mode = "host";
+ };
+
+ usb2-3 {
+ mode = "host";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ hsic-1 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ nvidia,usb2-companion = <2>;
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ status = "disabled";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
new file mode 100644
index 000000000000..acec5bb2391d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nxp,ptn3222.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nxp,ptn3222.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PTN3222 1-port eUSB2 to USB2 redriver
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - nxp,ptn3222
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ vdd1v8-supply:
+ description: power supply (1.8V)
+
+ vdd3v3-supply:
+ description: power supply (3.3V)
+
+ reset-gpios: true
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ redriver@4f {
+ compatible = "nxp,ptn3222";
+ reg = <0x4f>;
+ #phy-cells = <0>;
+ vdd3v3-supply = <&vreg_3p3>;
+ vdd1v8-supply = <&vreg_1p8>;
+ reset-gpios = <&gpio_reset GPIO_ACTIVE_LOW>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt
deleted file mode 100644
index 8b5a7a28a35b..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-mvebu armada 38x comphy driver
-------------------------------
-
-This comphy controller can be found on Marvell Armada 38x. It provides a
-number of shared PHYs used by various interfaces (network, sata, usb,
-PCIe...).
-
-Required properties:
-
-- compatible: should be "marvell,armada-380-comphy"
-- reg: should contain the comphy register location and length.
-- #address-cells: should be 1.
-- #size-cells: should be 0.
-
-Optional properties:
-
-- reg-names: must be "comphy" as the first name, and "conf".
-- reg: must contain the comphy register location and length as the first
- pair, followed by an optional configuration register address and
- length pair.
-
-A sub-node is required for each comphy lane provided by the comphy.
-
-Required properties (child nodes):
-
-- reg: comphy lane number.
-- #phy-cells : from the generic phy bindings, must be 1. Defines the
- input port to use for a given comphy lane.
-
-Example:
-
- comphy: phy@18300 {
- compatible = "marvell,armada-380-comphy";
- reg-names = "comphy", "conf";
- reg = <0x18300 0x100>, <0x18460 4>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpm_comphy0: phy@0 {
- reg = <0>;
- #phy-cells = <1>;
- };
-
- cpm_comphy1: phy@1 {
- reg = <1>;
- #phy-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt b/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
deleted file mode 100644
index c3a29c5feea3..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-ath79-usb.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Atheros AR71XX/9XXX USB PHY
-
-Required properties:
-- compatible: "qca,ar7100-usb-phy"
-- #phys-cells: should be 0
-- reset-names: "phy"[, "suspend-override"]
-- resets: references to the reset controllers
-
-Example:
-
- usb-phy {
- compatible = "qca,ar7100-usb-phy";
-
- reset-names = "phy", "suspend-override";
- resets = <&rst 4>, <&rst 3>;
-
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
index a9e227d8b076..137ac5703853 100644
--- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/phy-cadence-sierra.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/phy-cadence-sierra.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence Sierra PHY binding
+title: Cadence Sierra PHY
description:
This binding describes the Cadence Sierra PHY. Sierra PHY supports multilink
@@ -61,14 +61,6 @@ properties:
- const: pll0_refclk
- const: pll1_refclk
- assigned-clocks:
- minItems: 1
- maxItems: 2
-
- assigned-clock-parents:
- minItems: 1
- maxItems: 2
-
cdns,autoconf:
type: boolean
description:
@@ -104,7 +96,7 @@ patternProperties:
Specifies the type of PHY for which the group of PHY lanes is used.
Refer include/dt-bindings/phy/phy.h. Constants from the header should be used.
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [2, 4]
+ enum: [2, 4, 8, 9]
cdns,num-lanes:
description:
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
index 2fec9e54ad0e..9af39b33646a 100644
--- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence Torrent SD0801 PHY binding
+title: Cadence Torrent SD0801 PHY
description:
This binding describes the Cadence SD0801 PHY (also known as Torrent PHY)
@@ -20,6 +20,7 @@ properties:
compatible:
enum:
- cdns,torrent-phy
+ - ti,j7200-serdes-10g
- ti,j721e-serdes-10g
'#address-cells':
@@ -35,20 +36,18 @@ properties:
minItems: 1
maxItems: 2
description:
- PHY reference clock for 1 item. Must contain an entry in clock-names.
- Optional Parent to enable output reference clock.
+ PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
+ pll1_refclk is optional and used for multi-protocol configurations requiring
+ separate reference clock for each protocol.
+ Same refclk is used for both PLL0 and PLL1 if no separate pll1_refclk is used.
+ Optional parent clock (phy_en_refclk) to enable a reference clock output feature
+ on some platforms to output either derived or received reference clock.
clock-names:
minItems: 1
items:
- const: refclk
- - const: phy_en_refclk
-
- assigned-clocks:
- maxItems: 3
-
- assigned-clock-parents:
- maxItems: 3
+ - enum: [ pll1_refclk, phy_en_refclk ]
reg:
minItems: 1
@@ -100,8 +99,7 @@ patternProperties:
Specifies the type of PHY for which the group of PHY lanes is used.
Refer include/dt-bindings/phy/phy.h. Constants from the header should be used.
$ref: /schemas/types.yaml#/definitions/uint32
- minimum: 1
- maximum: 9
+ enum: [1, 2, 3, 4, 5, 6, 7, 8, 9, 12]
cdns,num-lanes:
description:
diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
deleted file mode 100644
index 2eb9b2b69037..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Motorola CPCAP PMIC USB PHY binding
-
-Required properties:
-compatible: Shall be either "motorola,cpcap-usb-phy" or
- "motorola,mapphone-cpcap-usb-phy"
-#phy-cells: Shall be 0
-interrupts: CPCAP PMIC interrupts used by the USB PHY
-interrupt-names: Interrupt names
-io-channels: IIO ADC channels used by the USB PHY
-io-channel-names: IIO ADC channel names
-vusb-supply: Regulator for the PHY
-
-Optional properties:
-pinctrl: Optional alternate pin modes for the PHY
-pinctrl-names: Names for optional pin modes
-mode-gpios: Optional GPIOs for configuring alternate modes
-
-Example:
-cpcap_usb2_phy: phy {
- compatible = "motorola,mapphone-cpcap-usb-phy";
- pinctrl-0 = <&usb_gpio_mux_sel1 &usb_gpio_mux_sel2>;
- pinctrl-1 = <&usb_ulpi_pins>;
- pinctrl-2 = <&usb_utmi_pins>;
- pinctrl-3 = <&uart3_pins>;
- pinctrl-names = "default", "ulpi", "utmi", "uart";
- #phy-cells = <0>;
- interrupts-extended = <
- &cpcap 15 0 &cpcap 14 0 &cpcap 28 0 &cpcap 19 0
- &cpcap 18 0 &cpcap 17 0 &cpcap 16 0 &cpcap 49 0
- &cpcap 48 1
- >;
- interrupt-names =
- "id_ground", "id_float", "se0conn", "vbusvld",
- "sessvld", "sessend", "se1", "dm", "dp";
- mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH
- &gpio1 0 GPIO_ACTIVE_HIGH>;
- io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
- io-channel-names = "vbus", "id";
- vusb-supply = <&vusb>;
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
deleted file mode 100644
index c26478be391b..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-TI DA8xx/OMAP-L1xx/AM18xx USB PHY
-
-Required properties:
- - compatible: must be "ti,da830-usb-phy".
- - #phy-cells: must be 1.
-
-This device controls the PHY for both the USB 1.1 OHCI and USB 2.0 OTG
-controllers on DA8xx SoCs. Consumers of this device should use index 0 for
-the USB 2.0 phy device and index 1 for the USB 1.1 phy device.
-
-It also requires a "syscon" node with compatible = "ti,da830-cfgchip", "syscon"
-to access the CFGCHIP2 register.
-
-Example:
-
- cfgchip: cfgchip@1417c {
- compatible = "ti,da830-cfgchip", "syscon";
- reg = <0x1417c 0x14>;
- };
-
- usb_phy: usb-phy {
- compatible = "ti,da830-usb-phy";
- #phy-cells = <1>;
- };
-
- usb20: usb@200000 {
- compatible = "ti,da830-musb";
- reg = <0x200000 0x1000>;
- interrupts = <58>;
- phys = <&usb_phy 0>;
- phy-names = "usb-phy";
- };
-
- usb11: usb@225000 {
- compatible = "ti,da830-ohci";
- reg = <0x225000 0x1000>;
- interrupts = <59>;
- phys = <&usb_phy 1>;
- phy-names = "usb-phy";
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt b/Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt
deleted file mode 100644
index 17b0c761370a..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-hi3798cv200-combphy.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-HiSilicon STB PCIE/SATA/USB3 PHY
-
-Required properties:
-- compatible: Should be "hisilicon,hi3798cv200-combphy"
-- reg: Should be the address space for COMBPHY configuration and state
- registers in peripheral controller, e.g. PERI_COMBPHY0_CFG and
- PERI_COMBPHY0_STATE for COMBPHY0 Hi3798CV200 SoC.
-- #phy-cells: Should be 1. The cell number is used to select the phy mode
- as defined in <dt-bindings/phy/phy.h>.
-- clocks: The phandle to clock provider and clock specifier pair.
-- resets: The phandle to reset controller and reset specifier pair.
-
-Refer to phy/phy-bindings.txt for the generic PHY binding properties.
-
-Optional properties:
-- hisilicon,fixed-mode: If the phy device doesn't support mode select
- but a fixed mode setting, the property should be present to specify
- the particular mode.
-- hisilicon,mode-select-bits: If the phy device support mode select,
- this property should be present to specify the register bits in
- peripheral controller, as a 3 integers tuple:
- <register_offset bit_shift bit_mask>.
-
-Notes:
-- Between hisilicon,fixed-mode and hisilicon,mode-select-bits, one and only
- one of them should be present.
-- The device node should be a child of peripheral controller that contains
- COMBPHY configuration/state and PERI_CTRL register used to select PHY mode.
- Refer to arm/hisilicon/hisilicon.txt for the parent peripheral controller
- bindings.
-
-Examples:
-
-perictrl: peripheral-controller@8a20000 {
- compatible = "hisilicon,hi3798cv200-perictrl", "syscon",
- "simple-mfd";
- reg = <0x8a20000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x8a20000 0x1000>;
-
- combphy0: phy@850 {
- compatible = "hisilicon,hi3798cv200-combphy";
- reg = <0x850 0x8>;
- #phy-cells = <1>;
- clocks = <&crg HISTB_COMBPHY0_CLK>;
- resets = <&crg 0x188 4>;
- hisilicon,fixed-mode = <PHY_TYPE_USB3>;
- };
-
- combphy1: phy@858 {
- compatible = "hisilicon,hi3798cv200-combphy";
- reg = <0x858 0x8>;
- #phy-cells = <1>;
- clocks = <&crg HISTB_COMBPHY1_CLK>;
- resets = <&crg 0x188 12>;
- hisilicon,mode-select-bits = <0x0008 11 (0x3 << 11)>;
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
deleted file mode 100644
index f17a56e2152f..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Hisilicon hi6220 usb PHY
------------------------
-
-Required properties:
-- compatible: should be "hisilicon,hi6220-usb-phy"
-- #phy-cells: must be 0
-- hisilicon,peripheral-syscon: phandle of syscon used to control phy.
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
- usb_phy: usbphy {
- compatible = "hisilicon,hi6220-usb-phy";
- #phy-cells = <0>;
- phy-supply = <&fixed_5v_hub>;
- hisilicon,peripheral-syscon = <&sys_ctrl>;
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
deleted file mode 100644
index 0d70c8341095..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-Device tree bindings for HiSilicon INNO USB2 PHY
-
-Required properties:
-- compatible: Should be one of the following strings:
- "hisilicon,inno-usb2-phy",
- "hisilicon,hi3798cv200-usb2-phy".
-- reg: Should be the address space for PHY configuration register in peripheral
- controller, e.g. PERI_USB0 for USB 2.0 PHY01 on Hi3798CV200 SoC.
-- clocks: The phandle and clock specifier pair for INNO USB2 PHY device
- reference clock.
-- resets: The phandle and reset specifier pair for INNO USB2 PHY device reset
- signal.
-- #address-cells: Must be 1.
-- #size-cells: Must be 0.
-
-The INNO USB2 PHY device should be a child node of peripheral controller that
-contains the PHY configuration register, and each device suppports up to 2 PHY
-ports which are represented as child nodes of INNO USB2 PHY device.
-
-Required properties for PHY port node:
-- reg: The PHY port instance number.
-- #phy-cells: Defined by generic PHY bindings. Must be 0.
-- resets: The phandle and reset specifier pair for PHY port reset signal.
-
-Refer to phy/phy-bindings.txt for the generic PHY binding properties
-
-Example:
-
-perictrl: peripheral-controller@8a20000 {
- compatible = "hisilicon,hi3798cv200-perictrl", "simple-mfd";
- reg = <0x8a20000 0x1000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x8a20000 0x1000>;
-
- usb2_phy1: usb2-phy@120 {
- compatible = "hisilicon,hi3798cv200-usb2-phy";
- reg = <0x120 0x4>;
- clocks = <&crg HISTB_USB2_PHY1_REF_CLK>;
- resets = <&crg 0xbc 4>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb2_phy1_port0: phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- resets = <&crg 0xbc 8>;
- };
-
- usb2_phy1_port1: phy@1 {
- reg = <1>;
- #phy-cells = <0>;
- resets = <&crg 0xbc 9>;
- };
- };
-
- usb2_phy2: usb2-phy@124 {
- compatible = "hisilicon,hi3798cv200-usb2-phy";
- reg = <0x124 0x4>;
- clocks = <&crg HISTB_USB2_PHY2_REF_CLK>;
- resets = <&crg 0xbc 6>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb2_phy2_port0: phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- resets = <&crg 0xbc 10>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
deleted file mode 100644
index 643948b6b576..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Lantiq XWAY SoC RCU USB 1.1/2.0 PHY binding
-===========================================
-
-This binding describes the USB PHY hardware provided by the RCU module on the
-Lantiq XWAY SoCs.
-
-This node has to be a sub node of the Lantiq RCU block.
-
--------------------------------------------------------------------------------
-Required properties (controller (parent) node):
-- compatible : Should be one of
- "lantiq,ase-usb2-phy"
- "lantiq,danube-usb2-phy"
- "lantiq,xrx100-usb2-phy"
- "lantiq,xrx200-usb2-phy"
- "lantiq,xrx300-usb2-phy"
-- reg : Defines the following sets of registers in the parent
- syscon device
- - Offset of the USB PHY configuration register
- - Offset of the USB Analog configuration
- register (only for xrx200 and xrx200)
-- clocks : References to the (PMU) "phy" clk gate.
-- clock-names : Must be "phy"
-- resets : References to the RCU USB configuration reset bits.
-- reset-names : Must be one of the following:
- "phy" (optional)
- "ctrl" (shared)
-
--------------------------------------------------------------------------------
-Example for the USB PHYs on an xRX200 SoC:
- usb_phy0: usb2-phy@18 {
- compatible = "lantiq,xrx200-usb2-phy";
- reg = <0x18 4>, <0x38 4>;
-
- clocks = <&pmu PMU_GATE_USB0_PHY>;
- clock-names = "phy";
- resets = <&reset1 4 4>, <&reset0 4 4>;
- reset-names = "phy", "ctrl";
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-lpc18xx-usb-otg.txt b/Documentation/devicetree/bindings/phy/phy-lpc18xx-usb-otg.txt
deleted file mode 100644
index 3bb821cd6a7f..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-lpc18xx-usb-otg.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-NXP LPC18xx/43xx internal USB OTG PHY binding
----------------------------------------------
-
-This file contains documentation for the internal USB OTG PHY found
-in NXP LPC18xx and LPC43xx SoCs.
-
-Required properties:
-- compatible : must be "nxp,lpc1850-usb-otg-phy"
-- clocks : must be exactly one entry
-See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-- #phy-cells : must be 0 for this phy
-See: Documentation/devicetree/bindings/phy/phy-bindings.txt
-
-The phy node must be a child of the creg syscon node.
-
-Example:
-creg: syscon@40043000 {
- compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
- reg = <0x40043000 0x1000>;
-
- usb0_otg_phy: phy {
- compatible = "nxp,lpc1850-usb-otg-phy";
- clocks = <&ccu1 CLK_USB0>;
- #phy-cells = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
deleted file mode 100644
index 29427d4f047a..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
-
-Required properties:
-- compatible Must be "motorola,mapphone-mdm6600"
-- enable-gpios GPIO to enable the USB PHY
-- power-gpios GPIO to power on the device
-- reset-gpios GPIO to reset the device
-- motorola,mode-gpios Two GPIOs to configure MDM6600 USB start-up mode for
- normal mode versus USB flashing mode
-- motorola,cmd-gpios Three GPIOs to control the power state of the MDM6600
-- motorola,status-gpios Three GPIOs to read the power state of the MDM6600
-
-Example:
-
-usb-phy {
- compatible = "motorola,mapphone-mdm6600";
- enable-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
- power-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
- reset-gpios = <&gpio2 17 GPIO_ACTIVE_HIGH>;
- motorola,mode-gpios = <&gpio5 20 GPIO_ACTIVE_HIGH>,
- <&gpio5 21 GPIO_ACTIVE_HIGH>;
- motorola,cmd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>,
- <&gpio4 8 GPIO_ACTIVE_HIGH>,
- <&gpio5 14 GPIO_ACTIVE_HIGH>;
- motorola,status-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>,
- <&gpio2 21 GPIO_ACTIVE_HIGH>,
- <&gpio2 23 GPIO_ACTIVE_HIGH>;
- #phy-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
deleted file mode 100644
index 5ffd0f55d010..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-MVEBU comphy drivers
---------------------
-
-COMPHY controllers can be found on the following Marvell MVEBU SoCs:
-* Armada 7k/8k (on the CP110)
-* Armada 3700
-It provides a number of shared PHYs used by various interfaces (network, SATA,
-USB, PCIe...).
-
-Required properties:
-
-- compatible: should be one of:
- * "marvell,comphy-cp110" for Armada 7k/8k
- * "marvell,comphy-a3700" for Armada 3700
-- reg: should contain the COMPHY register(s) location(s) and length(s).
- * 1 entry for Armada 7k/8k
- * 4 entries for Armada 3700 along with the corresponding reg-names
- properties, memory areas are:
- * Generic COMPHY registers
- * Lane 1 (PCIe/GbE)
- * Lane 0 (USB3/GbE)
- * Lane 2 (SATA/USB3)
-- marvell,system-controller: should contain a phandle to the system
- controller node (only for Armada 7k/8k)
-- #address-cells: should be 1.
-- #size-cells: should be 0.
-
-Optional properlties:
-
-- clocks: pointers to the reference clocks for this device (CP110 only),
- consequently: MG clock, MG Core clock, AXI clock.
-- clock-names: names of used clocks for CP110 only, must be :
- "mg_clk", "mg_core_clk" and "axi_clk".
-
-A sub-node is required for each comphy lane provided by the comphy.
-
-Required properties (child nodes):
-
-- reg: COMPHY lane number.
-- #phy-cells : from the generic PHY bindings, must be 1. Defines the
- input port to use for a given comphy lane.
-
-Examples:
-
- CP11X_LABEL(comphy): phy@120000 {
- compatible = "marvell,comphy-cp110";
- reg = <0x120000 0x6000>;
- marvell,system-controller = <&CP11X_LABEL(syscon0)>;
- clocks = <&CP11X_LABEL(clk) 1 5>, <&CP11X_LABEL(clk) 1 6>,
- <&CP11X_LABEL(clk) 1 18>;
- clock-names = "mg_clk", "mg_core_clk", "axi_clk";
- #address-cells = <1>;
- #size-cells = <0>;
-
- CP11X_LABEL(comphy0): phy@0 {
- reg = <0>;
- #phy-cells = <1>;
- };
-
- CP11X_LABEL(comphy1): phy@1 {
- reg = <1>;
- #phy-cells = <1>;
- };
- };
-
- comphy: phy@18300 {
- compatible = "marvell,comphy-a3700";
- reg = <0x18300 0x300>,
- <0x1F000 0x400>,
- <0x5C000 0x400>,
- <0xe0178 0x8>;
- reg-names = "comphy",
- "lane1_pcie_gbe",
- "lane0_usb3_gbe",
- "lane2_sata_usb3";
- #address-cells = <1>;
- #size-cells = <0>;
-
-
- comphy0: phy@0 {
- reg = <0>;
- #phy-cells = <1>;
- };
-
- comphy1: phy@1 {
- reg = <1>;
- #phy-cells = <1>;
- };
-
- comphy2: phy@2 {
- reg = <2>;
- #phy-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-mvebu.txt b/Documentation/devicetree/bindings/phy/phy-mvebu.txt
deleted file mode 100644
index 64afdd13d91d..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-mvebu.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* Marvell MVEBU SATA PHY
-
-Power control for the SATA phy found on Marvell MVEBU SoCs.
-
-This document extends the binding described in phy-bindings.txt
-
-Required properties :
-
- - reg : Offset and length of the register set for the SATA device
- - compatible : Should be "marvell,mvebu-sata-phy"
- - clocks : phandle of clock and specifier that supplies the device
- - clock-names : Should be "sata"
-
-Example:
- sata-phy@84000 {
- compatible = "marvell,mvebu-sata-phy";
- reg = <0x84000 0x0334>;
- clocks = <&gate_clk 15>;
- clock-names = "sata";
- #phy-cells = <0>;
- };
-
-Armada 375 USB cluster
-----------------------
-
-Armada 375 comes with an USB2 host and device controller and an USB3
-controller. The USB cluster control register allows to manage common
-features of both USB controllers.
-
-Required properties:
-
-- compatible: "marvell,armada-375-usb-cluster"
-- reg: Should contain usb cluster register location and length.
-- #phy-cells : from the generic phy bindings, must be 1. Possible
-values are 1 (USB2), 2 (USB3).
-
-Example:
- usbcluster: usb-cluster@18400 {
- compatible = "marvell,armada-375-usb-cluster";
- reg = <0x18400 0x4>;
- #phy-cells = <1>
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt b/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
deleted file mode 100644
index 332219860187..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Microsemi Ocelot SerDes muxing driver
--------------------------------------
-
-On Microsemi Ocelot, there is a handful of registers in HSIO address
-space for setting up the SerDes to switch port muxing.
-
-A SerDes X can be "muxed" to work with switch port Y or Z for example.
-One specific SerDes can also be used as a PCIe interface.
-
-Hence, a SerDes represents an interface, be it an Ethernet or a PCIe one.
-
-There are two kinds of SerDes: SERDES1G supports 10/100Mbps in
-half/full-duplex and 1000Mbps in full-duplex mode while SERDES6G supports
-10/100Mbps in half/full-duplex and 1000/2500Mbps in full-duplex mode.
-
-Also, SERDES6G number (aka "macro") 0 is the only interface supporting
-QSGMII.
-
-This is a child of the HSIO syscon ("mscc,ocelot-hsio", see
-Documentation/devicetree/bindings/mips/mscc.txt) on the Microsemi Ocelot.
-
-Required properties:
-
-- compatible: should be "mscc,vsc7514-serdes"
-- #phy-cells : from the generic phy bindings, must be 2.
- The first number defines the input port to use for a given
- SerDes macro. The second defines the macro to use. They are
- defined in dt-bindings/phy/phy-ocelot-serdes.h
-
-Example:
-
- serdes: serdes {
- compatible = "mscc,vsc7514-serdes";
- #phy-cells = <2>;
- };
-
- ethernet {
- port1 {
- phy-handle = <&phy_foo>;
- /* Link SERDES1G_5 to port1 */
- phys = <&serdes 1 SERDES1G_5>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-pxa-usb.txt b/Documentation/devicetree/bindings/phy/phy-pxa-usb.txt
deleted file mode 100644
index d80e36a77ec5..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-pxa-usb.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Marvell PXA USB PHY
--------------------
-
-Required properties:
-- compatible: one of: "marvell,mmp2-usb-phy", "marvell,pxa910-usb-phy",
- "marvell,pxa168-usb-phy",
-- #phy-cells: must be 0
-
-Example:
- usb-phy: usbphy@d4207000 {
- compatible = "marvell,mmp2-usb-phy";
- reg = <0xd4207000 0x40>;
- #phy-cells = <0>;
- status = "okay";
- };
-
-This document explains the device tree binding. For general
-information about PHY subsystem refer to Documentation/driver-api/phy/phy.rst
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt
deleted file mode 100644
index 710cccd5ee56..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-ROCKCHIP HDMI PHY WITH INNO IP BLOCK
-
-Required properties:
- - compatible : should be one of the listed compatibles:
- * "rockchip,rk3228-hdmi-phy",
- * "rockchip,rk3328-hdmi-phy";
- - reg : Address and length of the hdmi phy control register set
- - clocks : phandle + clock specifier for the phy clocks
- - clock-names : string, clock name, must contain "sysclk" for system
- control and register configuration, "refoclk" for crystal-
- oscillator reference PLL clock input and "refpclk" for pclk-
- based refeference PLL clock input.
- - #clock-cells: should be 0.
- - clock-output-names : shall be the name for the output clock.
- - interrupts : phandle + interrupt specified for the hdmiphy interrupt
- - #phy-cells : must be 0. See ./phy-bindings.txt for details.
-
-Optional properties for rk3328-hdmi-phy:
- - nvmem-cells = phandle + nvmem specifier for the cpu-version efuse
- - nvmem-cell-names : "cpu-version" to read the chip version, required
- for adjustment to some frequency settings
-
-Example:
- hdmi_phy: hdmi-phy@12030000 {
- compatible = "rockchip,rk3228-hdmi-phy";
- reg = <0x12030000 0x10000>;
- #phy-cells = <0>;
- clocks = <&cru PCLK_HDMI_PHY>, <&xin24m>, <&cru DCLK_HDMIPHY>;
- clock-names = "sysclk", "refoclk", "refpclk";
- #clock-cells = <0>;
- clock-output-names = "hdmi_phy";
- status = "disabled";
- };
-
-Then the PHY can be used in other nodes such as:
-
- hdmi: hdmi@200a0000 {
- compatible = "rockchip,rk3228-dw-hdmi";
- ...
- phys = <&hdmi_phy>;
- phy-names = "hdmi";
- ...
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
deleted file mode 100644
index 4b75289735eb..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
+++ /dev/null
@@ -1,187 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/phy/phy-rockchip-inno-usb2.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Rockchip USB2.0 phy with inno IP block
-
-maintainers:
- - Heiko Stuebner <heiko@sntech.de>
-
-properties:
- compatible:
- enum:
- - rockchip,px30-usb2phy
- - rockchip,rk3228-usb2phy
- - rockchip,rk3308-usb2phy
- - rockchip,rk3328-usb2phy
- - rockchip,rk3366-usb2phy
- - rockchip,rk3399-usb2phy
- - rockchip,rk3568-usb2phy
- - rockchip,rv1108-usb2phy
-
- reg:
- maxItems: 1
-
- clock-output-names:
- description:
- The usb 480m output clock name.
-
- "#clock-cells":
- const: 0
-
- clocks:
- maxItems: 1
-
- clock-names:
- const: phyclk
-
- assigned-clocks:
- description:
- Phandle of the usb 480m clock.
-
- assigned-clock-parents:
- description:
- Parent of the usb 480m clock.
- Select between usb-phy output 480m and xin24m.
- Refer to clk/clock-bindings.txt for generic clock consumer properties.
-
- extcon:
- description:
- Phandle to the extcon device providing the cable state for the otg phy.
-
- interrupts:
- description: Muxed interrupt for both ports
- maxItems: 1
-
- rockchip,usbgrf:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- Phandle to the syscon managing the 'usb general register files'.
- When set the driver will request its phandle as one companion-grf
- for some special SoCs (e.g rv1108).
-
- host-port:
- type: object
- additionalProperties: false
-
- properties:
- "#phy-cells":
- const: 0
-
- interrupts:
- description: host linestate interrupt
- maxItems: 1
-
- interrupt-names:
- const: linestate
-
- phy-supply:
- description:
- Phandle to a regulator that provides power to VBUS.
- See ./phy-bindings.txt for details.
-
- required:
- - "#phy-cells"
-
- otg-port:
- type: object
- additionalProperties: false
-
- properties:
- "#phy-cells":
- const: 0
-
- interrupts:
- minItems: 1
- maxItems: 3
-
- interrupt-names:
- oneOf:
- - const: linestate
- - const: otg-mux
- - items:
- - const: otg-bvalid
- - const: otg-id
- - const: linestate
-
- phy-supply:
- description:
- Phandle to a regulator that provides power to VBUS.
- See ./phy-bindings.txt for details.
-
- required:
- - "#phy-cells"
-
-required:
- - compatible
- - reg
- - clock-output-names
- - "#clock-cells"
- - host-port
- - otg-port
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- const: rockchip,rk3568-usb2phy
-
- then:
- properties:
- host-port:
- properties:
- interrupts: false
-
- otg-port:
- properties:
- interrupts: false
-
- required:
- - interrupts
-
- else:
- properties:
- interrupts: false
-
- host-port:
- required:
- - interrupts
- - interrupt-names
-
- otg-port:
- required:
- - interrupts
- - interrupt-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/rk3399-cru.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- u2phy0: usb2phy@e450 {
- compatible = "rockchip,rk3399-usb2phy";
- reg = <0xe450 0x10>;
- clocks = <&cru SCLK_USB2PHY0_REF>;
- clock-names = "phyclk";
- clock-output-names = "clk_usbphy0_480m";
- #clock-cells = <0>;
-
- u2phy0_host: host-port {
- interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "linestate";
- #phy-cells = <0>;
- };
-
- u2phy0_otg: otg-port {
- interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
- <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>;
- interrupt-names = "otg-bvalid", "otg-id", "linestate";
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
index f14454401419..379b08bd9e97 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/phy-rockchip-naneng-combphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip SoC Naneng Combo Phy Device Tree Bindings
+title: Rockchip SoC Naneng Combo Phy
maintainers:
- Heiko Stuebner <heiko@sntech.de>
@@ -12,7 +12,11 @@ maintainers:
properties:
compatible:
enum:
+ - rockchip,rk3528-naneng-combphy
+ - rockchip,rk3562-naneng-combphy
- rockchip,rk3568-naneng-combphy
+ - rockchip,rk3576-naneng-combphy
+ - rockchip,rk3588-naneng-combphy
reg:
maxItems: 1
@@ -30,8 +34,20 @@ properties:
- const: pipe
resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
items:
- - description: exclusive PHY reset line
+ - const: phy
+ - const: apb
+
+ phy-supply:
+ description: Single PHY regulator
+
+ power-domains:
+ maxItems: 1
rockchip,enable-ssc:
type: boolean
@@ -77,6 +93,34 @@ required:
- rockchip,pipe-phy-grf
- "#phy-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-naneng-combphy
+ then:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3528-naneng-combphy
+ - rockchip,rk3588-naneng-combphy
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+ required:
+ - reset-names
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
deleted file mode 100644
index 960da7fcaa9e..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-* ROCKCHIP type-c PHY
----------------------
-
-Required properties:
- - compatible : must be "rockchip,rk3399-typec-phy"
- - reg: Address and length of the usb phy control register set
- - rockchip,grf : phandle to the syscon managing the "general
- register files"
- - clocks : phandle + clock specifier for the phy clocks
- - clock-names : string, clock name, must be "tcpdcore", "tcpdphy-ref";
- - assigned-clocks: main clock, should be <&cru SCLK_UPHY0_TCPDCORE> or
- <&cru SCLK_UPHY1_TCPDCORE>;
- - assigned-clock-rates : the phy core clk frequency, shall be: 50000000
- - resets : a list of phandle + reset specifier pairs
- - reset-names : string reset name, must be:
- "uphy", "uphy-pipe", "uphy-tcphy"
-
-Optional properties:
- - extcon : extcon specifier for the Power Delivery
-
-Required nodes : a sub-node is required for each port the phy provides.
- The sub-node name is used to identify dp or usb3 port,
- and shall be the following entries:
- * "dp-port" : the name of DP port.
- * "usb3-port" : the name of USB3 port.
-
-Required properties (port (child) node):
-- #phy-cells : must be 0, See ./phy-bindings.txt for details.
-
-Deprecated properties, do not use in new device tree sources, these
-properties are determined by the compatible value:
- - rockchip,typec-conn-dir
- - rockchip,usb3tousb2-en
- - rockchip,external-psm
- - rockchip,pipe-status
-
-Example:
- tcphy0: phy@ff7c0000 {
- compatible = "rockchip,rk3399-typec-phy";
- reg = <0x0 0xff7c0000 0x0 0x40000>;
- rockchip,grf = <&grf>;
- extcon = <&fusb0>;
- clocks = <&cru SCLK_UPHY0_TCPDCORE>,
- <&cru SCLK_UPHY0_TCPDPHY_REF>;
- clock-names = "tcpdcore", "tcpdphy-ref";
- assigned-clocks = <&cru SCLK_UPHY0_TCPDCORE>;
- assigned-clock-rates = <50000000>;
- resets = <&cru SRST_UPHY0>,
- <&cru SRST_UPHY0_PIPE_L00>,
- <&cru SRST_P_UPHY0_TCPHY>;
- reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
-
- tcphy0_dp: dp-port {
- #phy-cells = <0>;
- };
-
- tcphy0_usb3: usb3-port {
- #phy-cells = <0>;
- };
- };
-
- tcphy1: phy@ff800000 {
- compatible = "rockchip,rk3399-typec-phy";
- reg = <0x0 0xff800000 0x0 0x40000>;
- rockchip,grf = <&grf>;
- extcon = <&fusb1>;
- clocks = <&cru SCLK_UPHY1_TCPDCORE>,
- <&cru SCLK_UPHY1_TCPDPHY_REF>;
- clock-names = "tcpdcore", "tcpdphy-ref";
- assigned-clocks = <&cru SCLK_UPHY1_TCPDCORE>;
- assigned-clock-rates = <50000000>;
- resets = <&cru SRST_UPHY1>,
- <&cru SRST_UPHY1_PIPE_L00>,
- <&cru SRST_P_UPHY1_TCPHY>;
- reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
-
- tcphy1_dp: dp-port {
- #phy-cells = <0>;
- };
-
- tcphy1_usb3: usb3-port {
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
new file mode 100644
index 000000000000..8b7059d5b182
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/phy-rockchip-usbdp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip USBDP Combo PHY with Samsung IP block
+
+maintainers:
+ - Frank Wang <frank.wang@rock-chips.com>
+ - Zhang Yubing <yubing.zhang@rock-chips.com>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3576-usbdp-phy
+ - rockchip,rk3588-usbdp-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ description: |
+ Cell allows setting the type of the PHY. Possible values are:
+ - PHY_TYPE_USB3
+ - PHY_TYPE_DP
+ const: 1
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: refclk
+ - const: immortal
+ - const: pclk
+ - const: utmi
+
+ resets:
+ maxItems: 5
+
+ reset-names:
+ items:
+ - const: init
+ - const: cmn
+ - const: lane
+ - const: pcs_apb
+ - const: pma_apb
+
+ phy-supply:
+ description: Single PHY regulator
+
+ rockchip,dp-lane-mux:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 4
+ items:
+ maximum: 3
+ description:
+ An array of physical Type-C lanes indexes. Position of an entry
+ determines the DisplayPort (DP) lane index, while the value of an entry
+ indicates physical Type-C lane. The supported DP lanes number are 2 or 4.
+ e.g. for 2 lanes DP lanes map, we could have "rockchip,dp-lane-mux = <2,
+ 3>;", assuming DP lane0 on Type-C phy lane2, DP lane1 on Type-C phy
+ lane3. For 4 lanes DP lanes map, we could have "rockchip,dp-lane-mux =
+ <0, 1, 2, 3>;", assuming DP lane0 on Type-C phy lane0, DP lane1 on Type-C
+ phy lane1, DP lane2 on Type-C phy lane2, DP lane3 on Type-C phy lane3. If
+ DP lanes are mapped by DisplayPort Alt mode, this property is not needed.
+
+ rockchip,u2phy-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'usb2 phy general register files'.
+
+ rockchip,usb-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'usb general register files'.
+
+ rockchip,usbdpphy-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'usbdp phy general register files'.
+
+ rockchip,vo-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'video output general register files'.
+ When select the DP lane mapping will request its phandle.
+
+ sbu1-dc-gpios:
+ description:
+ GPIO connected to the SBU1 line of the USB-C connector via a big resistor
+ (~100K) to apply a DC offset for signalling the connector orientation.
+ maxItems: 1
+
+ sbu2-dc-gpios:
+ description:
+ GPIO connected to the SBU2 line of the USB-C connector via a big resistor
+ (~100K) to apply a DC offset for signalling the connector orientation.
+ maxItems: 1
+
+ orientation-switch:
+ description: Flag the port as possible handler of orientation switching
+ type: boolean
+
+ mode-switch:
+ description: Flag the port as possible handler of altmode switching
+ type: boolean
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the PHY to a TypeC controller for the purpose of
+ handling orientation switching.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+
+ usbdp_phy0: phy@fed80000 {
+ compatible = "rockchip,rk3588-usbdp-phy";
+ reg = <0xfed80000 0x10000>;
+ #phy-cells = <1>;
+ clocks = <&cru CLK_USBDPPHY_MIPIDCPPHY_REF>,
+ <&cru CLK_USBDP_PHY0_IMMORTAL>,
+ <&cru PCLK_USBDPPHY0>,
+ <&u2phy0>;
+ clock-names = "refclk", "immortal", "pclk", "utmi";
+ resets = <&cru SRST_USBDP_COMBO_PHY0_INIT>,
+ <&cru SRST_USBDP_COMBO_PHY0_CMN>,
+ <&cru SRST_USBDP_COMBO_PHY0_LANE>,
+ <&cru SRST_USBDP_COMBO_PHY0_PCS>,
+ <&cru SRST_P_USBDPPHY0>;
+ reset-names = "init", "cmn", "lane", "pcs_apb", "pma_apb";
+ rockchip,u2phy-grf = <&usb2phy0_grf>;
+ rockchip,usb-grf = <&usb_grf>;
+ rockchip,usbdpphy-grf = <&usbdpphy0_grf>;
+ rockchip,vo-grf = <&vo0_grf>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/phy-stih407-usb.txt b/Documentation/devicetree/bindings/phy/phy-stih407-usb.txt
deleted file mode 100644
index 35f03df00130..000000000000
--- a/Documentation/devicetree/bindings/phy/phy-stih407-usb.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-ST STiH407 USB PHY controller
-
-This file documents the dt bindings for the usb picoPHY driver which is the PHY for both USB2 and USB3
-host controllers (when controlling usb2/1.1 devices) available on STiH407 SoC family from STMicroelectronics.
-
-Required properties:
-- compatible : should be "st,stih407-usb2-phy"
-- st,syscfg : phandle of sysconfig bank plus integer array containing phyparam and phyctrl register offsets
-- resets : list of phandle and reset specifier pairs. There should be two entries, one
- for the whole phy and one for the port
-- reset-names : list of reset signal names. Should be "global" and "port"
-See: Documentation/devicetree/bindings/reset/st,stih407-powerdown.yaml
-See: Documentation/devicetree/bindings/reset/reset.txt
-
-Example:
-
-usb2_picophy0: usbpicophy@f8 {
- compatible = "st,stih407-usb2-phy";
- #phy-cells = <0>;
- st,syscfg = <&syscfg_core 0x100 0xf4>;
- resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
- <&picophyreset STIH407_PICOPHY0_RESET>;
- reset-names = "global", "port";
-};
diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
index dc287d428e49..ceea122ae1a6 100644
--- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/phy-stm32-usbphyc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 USB HS PHY controller binding
+title: STMicroelectronics STM32 USB HS PHY controller
description:
@@ -55,7 +55,11 @@ properties:
description: number of clock cells for ck_usbo_48m consumer
const: 0
-#Required child nodes:
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
+# Required child nodes:
patternProperties:
"^usb-phy@[0|1]$":
@@ -77,6 +81,8 @@ patternProperties:
connector:
type: object
$ref: /schemas/connector/usb-connector.yaml
+ unevaluatedProperties: false
+
properties:
vbus-supply: true
diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml
index 4dc5205d893b..4790c6238a40 100644
--- a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/phy-tegra194-p2u.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/phy-tegra194-p2u.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra194 & Tegra234 P2U binding
+title: NVIDIA Tegra194 & Tegra234 P2U
maintainers:
- Thierry Reding <treding@nvidia.com>
diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
deleted file mode 100644
index afbc7e24a3de..000000000000
--- a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-IMG Pistachio USB PHY
-=====================
-
-Required properties:
---------------------
- - compatible: Must be "img,pistachio-usb-phy".
- - #phy-cells: Must be 0. See ./phy-bindings.txt for details.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clock/clock-bindings.txt for details.
- - clock-names: Must include "usb_phy".
- - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
- - img,refclk: Indicates the reference clock source for the USB PHY.
- See <dt-bindings/phy/phy-pistachio-usb.h> for a list of valid values.
-
-Optional properties:
---------------------
- - phy-supply: USB VBUS supply. Must supply 5.0V.
-
-Example:
---------
-usb_phy: usb-phy {
- compatible = "img,pistachio-usb-phy";
- clocks = <&clk_core CLK_USB_PHY>;
- clock-names = "usb_phy";
- phy-supply = <&usb_vbus>;
- img,refclk = <REFCLK_CLK_CORE>;
- img,cr-top = <&cr_top>;
- #phy-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt b/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt
deleted file mode 100644
index 660a13ca90b3..000000000000
--- a/Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Marvell PXA1928 USB and HSIC PHYs
-
-Required properties:
-- compatible: "marvell,pxa1928-usb-phy" or "marvell,pxa1928-hsic-phy"
-- reg: base address and length of the registers
-- clocks - A single clock. From common clock binding.
-- #phys-cells: should be 0. From commmon phy binding.
-- resets: reference to the reset controller
-
-Example:
-
- usbphy: phy@7000 {
- compatible = "marvell,pxa1928-usb-phy";
- reg = <0x7000 0xe0>;
- clocks = <&apmu_clocks PXA1928_CLK_USB>;
- #phy-cells = <0>;
- };
-
diff --git a/Documentation/devicetree/bindings/phy/qca,ar7100-usb-phy.yaml b/Documentation/devicetree/bindings/phy/qca,ar7100-usb-phy.yaml
new file mode 100644
index 000000000000..029665530829
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qca,ar7100-usb-phy.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qca,ar7100-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atheros AR71XX/9XXX USB PHY
+
+maintainers:
+ - Alban Bedel <albeu@free.fr>
+
+properties:
+ compatible:
+ items:
+ - const: qca,ar7100-usb-phy
+
+ reset-names:
+ description: Names of reset lines in order.
+ minItems: 1
+ items:
+ - const: phy
+ - const: suspend-override
+
+ resets:
+ description: References to the reset controllers.
+ minItems: 1
+ items:
+ - description: Reset controller for phy
+ - description: Reset controller for suspend-override
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reset-names
+ - resets
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy {
+ compatible = "qca,ar7100-usb-phy";
+ reset-names = "phy", "suspend-override";
+ resets = <&rst 4>, <&rst 3>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
index cf9e9b8011cb..eb97181cbb95 100644
--- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
@@ -2,8 +2,8 @@
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/qcom,edp-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/qcom,edp-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm eDP PHY
@@ -16,9 +16,18 @@ description:
properties:
compatible:
- enum:
- - qcom,sc7280-edp-phy
- - qcom,sc8180x-edp-phy
+ oneOf:
+ - enum:
+ - qcom,sa8775p-edp-phy
+ - qcom,sc7280-edp-phy
+ - qcom,sc8180x-edp-phy
+ - qcom,sc8280xp-dp-phy
+ - qcom,sc8280xp-edp-phy
+ - qcom,x1e80100-dp-phy
+ - items:
+ - enum:
+ - qcom,qcs8300-edp-phy
+ - const: qcom,sa8775p-edp-phy
reg:
items:
@@ -41,6 +50,9 @@ properties:
"#phy-cells":
const: 0
+ power-domains:
+ maxItems: 1
+
vdda-phy-supply: true
vdda-pll-supply: true
diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml
index fdb277edebeb..0c8f03b78608 100644
--- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-other.yaml
@@ -43,6 +43,9 @@ properties:
vddio-supply:
description: phandle to VDD I/O supply regulator
+ '#clock-cells':
+ const: 0
+
'#phy-cells':
const: 0
@@ -53,7 +56,6 @@ allOf:
contains:
enum:
- qcom,hdmi-phy-8660
- - qcom,hdmi-phy-8960
then:
properties:
clocks:
@@ -68,6 +70,24 @@ allOf:
compatible:
contains:
enum:
+ - qcom,hdmi-phy-8960
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+ clock-names:
+ minItems: 1
+ items:
+ - const: slave_iface
+ - const: pxo
+ vddio-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,hdmi-phy-8084
- qcom,hdmi-phy-8974
then:
@@ -96,9 +116,10 @@ examples:
"hdmi_pll";
reg = <0x4a00400 0x60>,
<0x4a00500 0x100>;
+ #clock-cells = <0>;
#phy-cells = <0>;
power-domains = <&mmcc 1>;
- clock-names = "slave_iface";
- clocks = <&clk 21>;
+ clock-names = "slave_iface", "pxo";
+ clocks = <&clk 21>, <&pxo_board>;
core-vdda-supply = <&pm8921_hdmi_mvs>;
};
diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
index 83fe4b39b56f..78607ee3e2e8 100644
--- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
@@ -14,6 +14,7 @@ properties:
compatible:
enum:
- qcom,hdmi-phy-8996
+ - qcom,hdmi-phy-8998
reg:
maxItems: 6
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml
new file mode 100644
index 000000000000..6e9df81441e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq5332-uniphy-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm UNIPHY PCIe 28LP PHY
+
+maintainers:
+ - Nitheesh Sekar <quic_nsekar@quicinc.com>
+ - Varadarajan Narayanan <quic_varada@quicinc.com>
+
+description:
+ PCIe and USB combo PHY found in Qualcomm IPQ5018 & IPQ5332 SoCs
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5018-uniphy-pcie-phy
+ - qcom,ipq5332-uniphy-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ resets:
+ minItems: 2
+ maxItems: 3
+
+ "#phy-cells":
+ const: 0
+
+ "#clock-cells":
+ const: 0
+
+ num-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - "#phy-cells"
+ - "#clock-cells"
+ - num-lanes
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5018-uniphy-pcie-phy
+ then:
+ properties:
+ clocks:
+ items:
+ - description: pcie pipe clock
+ resets:
+ items:
+ - description: phy reset
+ - description: cfg reset
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5332-uniphy-pcie-phy
+ then:
+ properties:
+ clocks:
+ items:
+ - description: pcie pipe clock
+ - description: pcie ahb clock
+ resets:
+ items:
+ - description: phy reset
+ - description: ahb reset
+ - description: cfg reset
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
+
+ pcie0_phy: phy@4b0000 {
+ compatible = "qcom,ipq5332-uniphy-pcie-phy";
+ reg = <0x004b0000 0x800>;
+
+ clocks = <&gcc GCC_PCIE3X1_0_PIPE_CLK>,
+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK>;
+
+ resets = <&gcc GCC_PCIE3X1_0_PHY_BCR>,
+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK_ARES>,
+ <&gcc GCC_PCIE3X1_0_PHY_PHY_BCR>;
+
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ num-lanes = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml
new file mode 100644
index 000000000000..e77576d06c0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq5332-usb-hsphy.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq5332-usb-hsphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: M31 USB PHY
+
+maintainers:
+ - Sricharan Ramabadhran <quic_srichara@quicinc.com>
+ - Varadarajan Narayanan <quic_varada@quicinc.com>
+
+description:
+ USB M31 PHY (https://www.m31tech.com) found in Qualcomm
+ IPQ5018, IPQ5332 SoCs.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,ipq5018-usb-hsphy
+ - qcom,ipq5332-usb-hsphy
+
+ "#phy-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: cfg_ahb
+
+ resets:
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Phandle to 5V regulator supply to PHY digital circuit.
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
+ usb-phy@7b000 {
+ compatible = "qcom,ipq5332-usb-hsphy";
+ reg = <0x0007b000 0x12c>;
+
+ clocks = <&gcc GCC_USB0_PHY_CFG_AHB_CLK>;
+ clock-names = "cfg_ahb";
+
+ #phy-cells = <0>;
+
+ resets = <&gcc GCC_QUSB2_0_PHY_BCR>;
+
+ vdd-supply = <&regulator_fixed_5p0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
new file mode 100644
index 000000000000..f60804687412
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,ipq8074-qmp-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (PCIe, IPQ8074)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,ipq6018-qmp-pcie-phy
+ - qcom,ipq8074-qmp-gen3-pcie-phy
+ - qcom,ipq8074-qmp-pcie-phy
+ - qcom,ipq9574-qmp-gen3x1-pcie-phy
+ - qcom,ipq9574-qmp-gen3x2-pcie-phy
+ - items:
+ - enum:
+ - qcom,ipq5424-qmp-gen3x1-pcie-phy
+ - const: qcom,ipq9574-qmp-gen3x1-pcie-phy
+ - items:
+ - enum:
+ - qcom,ipq5424-qmp-gen3x2-pcie-phy
+ - const: qcom,ipq9574-qmp-gen3x2-pcie-phy
+
+ reg:
+ items:
+ - description: serdes
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: pipe
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: common
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-ipq6018.h>
+ #include <dt-bindings/reset/qcom,gcc-ipq6018.h>
+
+ phy@84000 {
+ compatible = "qcom,ipq6018-qmp-pcie-phy";
+ reg = <0x00084000 0x1000>;
+
+ clocks = <&gcc GCC_PCIE0_AUX_CLK>,
+ <&gcc GCC_PCIE0_AHB_CLK>,
+ <&gcc GCC_PCIE0_PIPE_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "pipe";
+
+ clock-output-names = "gcc_pcie0_pipe_clk_src";
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ resets = <&gcc GCC_PCIE0_PHY_BCR>,
+ <&gcc GCC_PCIE0PHY_PHY_BCR>;
+ reset-names = "phy",
+ "common";
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,m31-eusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,m31-eusb2-phy.yaml
new file mode 100644
index 000000000000..c84c62d0e8cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,m31-eusb2-phy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,m31-eusb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm M31 eUSB2 phy
+
+maintainers:
+ - Wesley Cheng <quic_wcheng@quicinc.com>
+
+description:
+ M31 based eUSB2 controller, which supports LS/FS/HS usb connectivity
+ on Qualcomm chipsets. It is paired with a eUSB2 repeater.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,sm8750-m31-eusb2-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: reference clock
+
+ clock-names:
+ items:
+ - const: ref
+
+ resets:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+ description:
+ Phandle to eUSB2 repeater
+
+ vdd-supply:
+ description:
+ Phandle to 0.88V regulator supply to PHY digital circuit.
+
+ vdda12-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+ - resets
+ - vdd-supply
+ - vdda12-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ usb_1_hsphy: phy@88e3000 {
+ compatible = "qcom,sm8750-m31-eusb2-phy";
+ reg = <0x88e3000 0x29c>;
+
+ clocks = <&tcsrcc_usb2_clkref_en>;
+ clock-names = "ref";
+
+ resets = <&gcc_qusb2phy_prim_bcr>;
+
+ #phy-cells = <0>;
+
+ vdd-supply = <&vreg_l2d_0p88>;
+ vdda12-supply = <&vreg_l3g_1p2>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml
new file mode 100644
index 000000000000..4e710ef75523
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8996-qmp-pcie-phy.yaml
@@ -0,0 +1,189 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,msm8996-qmp-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (MSM8996 PCIe)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ const: qcom,msm8996-qmp-pcie-phy
+
+ reg:
+ items:
+ - description: serdes
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+
+ resets:
+ maxItems: 3
+
+ reset-names:
+ items:
+ - const: phy
+ - const: common
+ - const: cfg
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ vddp-ref-clk-supply: true
+
+patternProperties:
+ "^phy@[0-9a-f]+$":
+ type: object
+ description: one child node per PHY provided by this block
+ properties:
+ reg:
+ items:
+ - description: TX
+ - description: RX
+ - description: PCS
+
+ clocks:
+ items:
+ - description: PIPE clock
+
+ clock-names:
+ deprecated: true
+ items:
+ - enum:
+ - pipe0
+ - pipe1
+ - pipe2
+
+ resets:
+ items:
+ - description: PHY reset
+
+ reset-names:
+ deprecated: true
+ items:
+ - enum:
+ - lane0
+ - lane1
+ - lane2
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ required:
+ - reg
+ - clocks
+ - resets
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8996.h>
+ pcie_phy: phy-wrapper@34000 {
+ compatible = "qcom,msm8996-qmp-pcie-phy";
+ reg = <0x34000 0x488>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x34000 0x4000>;
+
+ clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
+ <&gcc GCC_PCIE_PHY_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_CLKREF_CLK>;
+ clock-names = "aux", "cfg_ahb", "ref";
+
+ resets = <&gcc GCC_PCIE_PHY_BCR>,
+ <&gcc GCC_PCIE_PHY_COM_BCR>,
+ <&gcc GCC_PCIE_PHY_COM_NOCSR_BCR>;
+ reset-names = "phy", "common", "cfg";
+
+ vdda-phy-supply = <&vreg_l28a_0p925>;
+ vdda-pll-supply = <&vreg_l12a_1p8>;
+
+ pciephy_0: phy@1000 {
+ reg = <0x1000 0x130>,
+ <0x1200 0x200>,
+ <0x1400 0x1dc>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
+ resets = <&gcc GCC_PCIE_0_PHY_BCR>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_0_pipe_clk_src";
+
+ #phy-cells = <0>;
+ };
+
+ pciephy_1: phy@2000 {
+ reg = <0x2000 0x130>,
+ <0x2200 0x200>,
+ <0x2400 0x1dc>;
+
+ clocks = <&gcc GCC_PCIE_1_PIPE_CLK>;
+ resets = <&gcc GCC_PCIE_1_PHY_BCR>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_1_pipe_clk_src";
+
+ #phy-cells = <0>;
+ };
+
+ pciephy_2: phy@3000 {
+ reg = <0x3000 0x130>,
+ <0x3200 0x200>,
+ <0x3400 0x1dc>;
+
+ clocks = <&gcc GCC_PCIE_2_PIPE_CLK>;
+ resets = <&gcc GCC_PCIE_2_PHY_BCR>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_2_pipe_clk_src";
+
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml
new file mode 100644
index 000000000000..d05eef0e1ccd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-pcie-phy.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,msm8998-qmp-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (PCIe, MSM8998)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ const: qcom,msm8998-qmp-pcie-phy
+
+ reg:
+ items:
+ - description: serdes
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+ - const: pipe
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: common
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8998.h>
+
+ phy@1c18000 {
+ compatible = "qcom,msm8998-qmp-pcie-phy";
+ reg = <0x01c06000 0x1000>;
+
+ clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
+ <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_CLKREF_CLK>,
+ <&gcc GCC_PCIE_0_PIPE_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "pipe";
+
+ clock-output-names = "pcie_0_pipe_clk_src";
+ #clock-cells = <0>;
+
+ #phy-cells = <0>;
+
+ resets = <&gcc GCC_PCIE_0_PHY_BCR>, <&gcc GCC_PCIE_PHY_BCR>;
+ reset-names = "phy", "common";
+
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l2a_1p2>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml
new file mode 100644
index 000000000000..1636285fbe53
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml
@@ -0,0 +1,186 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,msm8998-qmp-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (USB, MSM8998)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for USB-C on
+ several Qualcomm chipsets.
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8998-qmp-usb3-phy
+ - qcom,qcm2290-qmp-usb3-phy
+ - qcom,qcs615-qmp-usb3-phy
+ - qcom,sdm660-qmp-usb3-phy
+ - qcom,sm6115-qmp-usb3-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ maxItems: 4
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: phy_phy
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ orientation-switch:
+ description:
+ Flag the PHY as possible handler of USB Type-C orientation switching
+ type: boolean
+
+ qcom,tcsr-reg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to TCSR hardware block
+ - description: offset of the VLS CLAMP register
+ description: Clamp register present in the TCSR
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output endpoint of the PHY
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+ - qcom,tcsr-reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-qmp-usb3-phy
+ - qcom,qcs615-qmp-usb3-phy
+ - qcom,sdm660-qmp-usb3-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: aux
+ - const: ref
+ - const: cfg_ahb
+ - const: pipe
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcm2290-qmp-usb3-phy
+ - qcom,sm6115-qmp-usb3-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: cfg_ahb
+ - const: ref
+ - const: com_aux
+ - const: pipe
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8998.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ phy@c010000 {
+ compatible = "qcom,msm8998-qmp-usb3-phy";
+ reg = <0x0c010000 0x1000>;
+
+ clocks = <&gcc GCC_USB3_PHY_AUX_CLK>,
+ <&gcc GCC_USB3_CLKREF_CLK>,
+ <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+ <&gcc GCC_USB3_PHY_PIPE_CLK>;
+ clock-names = "aux",
+ "ref",
+ "cfg_ahb",
+ "pipe";
+ clock-output-names = "usb3_phy_pipe_clk_src";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+
+ resets = <&gcc GCC_USB3_PHY_BCR>,
+ <&gcc GCC_USB3PHY_PHY_BCR>;
+ reset-names = "phy",
+ "phy_phy";
+
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l2a_1p2>;
+
+ orientation-switch;
+
+ qcom,tcsr-reg = <&tcsr_regs_1 0x6b244>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&pmic_typec_mux_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&usb_dwc3_ss>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml
new file mode 100644
index 000000000000..dbc4a4c71f05
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,pcie2-phy.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,pcie2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PCIe2 PHY controller
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The Qualcomm PCIe2 PHY is a Synopsys based phy found in a number of Qualcomm
+ platforms.
+
+properties:
+ compatible:
+ items:
+ - const: qcom,qcs404-pcie2-phy
+ - const: qcom,pcie2-phy
+
+ reg:
+ items:
+ - description: PHY register set
+
+ clocks:
+ items:
+ - description: a clock-specifier pair for the "pipe" clock
+
+ clock-output-names:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ "#phy-cells":
+ const: 0
+
+ vdda-vp-supply:
+ description: low voltage regulator
+
+ vdda-vph-supply:
+ description: high voltage regulator
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: pipe
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-output-names
+ - "#clock-cells"
+ - "#phy-cells"
+ - vdda-vp-supply
+ - vdda-vph-supply
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-qcs404.h>
+ phy@7786000 {
+ compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
+ reg = <0x07786000 0xb8>;
+
+ clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
+ resets = <&gcc GCC_PCIEPHY_0_PHY_BCR>,
+ <&gcc GCC_PCIE_0_PIPE_ARES>;
+ reset-names = "phy", "pipe";
+
+ vdda-vp-supply = <&vreg_l3_1p05>;
+ vdda-vph-supply = <&vreg_l5_1p8>;
+
+ clock-output-names = "pcie_0_pipe_clk";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
deleted file mode 100644
index 220788ce215f..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
+++ /dev/null
@@ -1,502 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/phy/qcom,qmp-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Qualcomm QMP PHY controller
-
-maintainers:
- - Vinod Koul <vkoul@kernel.org>
-
-description:
- QMP phy controller supports physical layer functionality for a number of
- controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
-
-properties:
- compatible:
- enum:
- - qcom,ipq6018-qmp-pcie-phy
- - qcom,ipq6018-qmp-usb3-phy
- - qcom,ipq8074-qmp-gen3-pcie-phy
- - qcom,ipq8074-qmp-pcie-phy
- - qcom,ipq8074-qmp-usb3-phy
- - qcom,msm8996-qmp-pcie-phy
- - qcom,msm8996-qmp-ufs-phy
- - qcom,msm8996-qmp-usb3-phy
- - qcom,msm8998-qmp-pcie-phy
- - qcom,msm8998-qmp-ufs-phy
- - qcom,msm8998-qmp-usb3-phy
- - qcom,qcm2290-qmp-usb3-phy
- - qcom,sc7180-qmp-usb3-phy
- - qcom,sc8180x-qmp-pcie-phy
- - qcom,sc8180x-qmp-ufs-phy
- - qcom,sc8180x-qmp-usb3-phy
- - qcom,sc8280xp-qmp-ufs-phy
- - qcom,sdm845-qhp-pcie-phy
- - qcom,sdm845-qmp-pcie-phy
- - qcom,sdm845-qmp-ufs-phy
- - qcom,sdm845-qmp-usb3-phy
- - qcom,sdm845-qmp-usb3-uni-phy
- - qcom,sm6115-qmp-ufs-phy
- - qcom,sm6350-qmp-ufs-phy
- - qcom,sm8150-qmp-ufs-phy
- - qcom,sm8150-qmp-usb3-phy
- - qcom,sm8150-qmp-usb3-uni-phy
- - qcom,sm8250-qmp-ufs-phy
- - qcom,sm8250-qmp-gen3x1-pcie-phy
- - qcom,sm8250-qmp-gen3x2-pcie-phy
- - qcom,sm8250-qmp-modem-pcie-phy
- - qcom,sm8250-qmp-usb3-phy
- - qcom,sm8250-qmp-usb3-uni-phy
- - qcom,sm8350-qmp-ufs-phy
- - qcom,sm8350-qmp-usb3-phy
- - qcom,sm8350-qmp-usb3-uni-phy
- - qcom,sm8450-qmp-gen3x1-pcie-phy
- - qcom,sm8450-qmp-gen4x2-pcie-phy
- - qcom,sm8450-qmp-ufs-phy
- - qcom,sm8450-qmp-usb3-phy
- - qcom,sdx55-qmp-pcie-phy
- - qcom,sdx55-qmp-usb3-uni-phy
- - qcom,sdx65-qmp-usb3-uni-phy
-
- reg:
- minItems: 1
- items:
- - description: Address and length of PHY's common serdes block.
- - description: Address and length of PHY's DP_COM control block.
-
- "#clock-cells":
- enum: [ 1, 2 ]
-
- "#address-cells":
- enum: [ 1, 2 ]
-
- "#size-cells":
- enum: [ 1, 2 ]
-
- ranges: true
-
- clocks:
- minItems: 1
- maxItems: 4
-
- clock-names:
- minItems: 1
- maxItems: 4
-
- resets:
- minItems: 1
- maxItems: 3
-
- reset-names:
- minItems: 1
- maxItems: 3
-
- vdda-phy-supply:
- description:
- Phandle to a regulator supply to PHY core block.
-
- vdda-pll-supply:
- description:
- Phandle to 1.8V regulator supply to PHY refclk pll block.
-
- vddp-ref-clk-supply:
- description:
- Phandle to a regulator supply to any specific refclk pll block.
-
-#Required nodes:
-patternProperties:
- "^phy@[0-9a-f]+$":
- type: object
- description:
- Each device node of QMP phy is required to have as many child nodes as
- the number of lanes the PHY has.
-
-required:
- - compatible
- - reg
- - "#clock-cells"
- - "#address-cells"
- - "#size-cells"
- - ranges
- - clocks
- - clock-names
- - resets
- - reset-names
-
-additionalProperties: false
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sdm845-qmp-usb3-uni-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- - description: Phy common block aux clock.
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: com_aux
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sdx55-qmp-usb3-uni-phy
- - qcom,sdx65-qmp-usb3-uni-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8996-qmp-pcie-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- - description: phy's ahb cfg block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- - const: cfg
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,ipq8074-qmp-usb3-phy
- - qcom,msm8996-qmp-usb3-phy
- - qcom,msm8998-qmp-pcie-phy
- - qcom,msm8998-qmp-usb3-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8996-qmp-ufs-phy
- then:
- properties:
- clocks:
- items:
- - description: 19.2 MHz ref clk.
- clock-names:
- items:
- - const: ref
- resets:
- items:
- - description: PHY reset in the UFS controller.
- reset-names:
- items:
- - const: ufsphy
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8998-qmp-ufs-phy
- - qcom,sdm845-qmp-ufs-phy
- - qcom,sm6350-qmp-ufs-phy
- - qcom,sm8150-qmp-ufs-phy
- - qcom,sm8250-qmp-ufs-phy
- - qcom,sc8180x-qmp-ufs-phy
- - qcom,sc8280xp-qmp-ufs-phy
- then:
- properties:
- clocks:
- items:
- - description: 19.2 MHz ref clk.
- - description: Phy reference aux clock.
- clock-names:
- items:
- - const: ref
- - const: ref_aux
- resets:
- items:
- - description: PHY reset in the UFS controller.
- reset-names:
- items:
- - const: ufsphy
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,ipq6018-qmp-pcie-phy
- - qcom,ipq8074-qmp-gen3-pcie-phy
- - qcom,ipq8074-qmp-pcie-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8180x-qmp-pcie-phy
- - qcom,sdm845-qhp-pcie-phy
- - qcom,sdm845-qmp-pcie-phy
- - qcom,sdx55-qmp-pcie-phy
- - qcom,sm8250-qmp-gen3x1-pcie-phy
- - qcom,sm8250-qmp-gen3x2-pcie-phy
- - qcom,sm8250-qmp-modem-pcie-phy
- - qcom,sm8450-qmp-gen3x1-pcie-phy
- - qcom,sm8450-qmp-gen4x2-pcie-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- - description: Phy refgen clk.
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: refgen
- resets:
- items:
- - description: reset of phy block.
- reset-names:
- items:
- - const: phy
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm8150-qmp-usb3-phy
- - qcom,sm8150-qmp-usb3-uni-phy
- - qcom,sm8250-qmp-usb3-uni-phy
- - qcom,sm8350-qmp-usb3-uni-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: 19.2 MHz ref clk source.
- - description: 19.2 MHz ref clk.
- - description: Phy common block aux clock.
- clock-names:
- items:
- - const: aux
- - const: ref_clk_src
- - const: ref
- - const: com_aux
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm8250-qmp-usb3-phy
- - qcom,sm8350-qmp-usb3-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy aux clock.
- - description: 19.2 MHz ref clk.
- - description: Phy common block aux clock.
- clock-names:
- items:
- - const: aux
- - const: ref_clk_src
- - const: com_aux
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
- reset-names:
- items:
- - const: phy
- - const: common
- required:
- - vdda-phy-supply
- - vdda-pll-supply
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,qcm2290-qmp-usb3-phy
- then:
- properties:
- clocks:
- items:
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- - description: Phy common block aux clock.
- clock-names:
- items:
- - const: cfg_ahb
- - const: ref
- - const: com_aux
- resets:
- items:
- - description: phy_phy reset.
- - description: reset of phy block.
- reset-names:
- items:
- - const: phy_phy
- - const: phy
- required:
- - vdda-phy-supply
- - vdda-pll-supply
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sdm845.h>
- usb_2_qmpphy: phy-wrapper@88eb000 {
- compatible = "qcom,sdm845-qmp-usb3-uni-phy";
- reg = <0x088eb000 0x18c>;
- #clock-cells = <1>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x088eb000 0x2000>;
-
- clocks = <&gcc GCC_USB3_SEC_PHY_AUX_CLK >,
- <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
- <&gcc GCC_USB3_SEC_CLKREF_CLK>,
- <&gcc GCC_USB3_SEC_PHY_COM_AUX_CLK>;
- clock-names = "aux", "cfg_ahb", "ref", "com_aux";
-
- resets = <&gcc GCC_USB3PHY_PHY_SEC_BCR>,
- <&gcc GCC_USB3_PHY_SEC_BCR>;
- reset-names = "phy", "common";
-
- vdda-phy-supply = <&vdda_usb2_ss_1p2>;
- vdda-pll-supply = <&vdda_usb2_ss_core>;
-
- usb_2_ssphy: phy@200 {
- reg = <0x200 0x128>,
- <0x400 0x1fc>,
- <0x800 0x218>,
- <0x600 0x70>;
- #clock-cells = <0>;
- #phy-cells = <0>;
- clocks = <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>;
- clock-names = "pipe0";
- clock-output-names = "usb3_uni_phy_pipe_clk_src";
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
deleted file mode 100644
index b078009ed509..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
+++ /dev/null
@@ -1,213 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/phy/qcom,qmp-usb3-dp-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Qualcomm QMP USB3 DP PHY controller
-
-maintainers:
- - Wesley Cheng <quic_wcheng@quicinc.com>
-
-properties:
- compatible:
- enum:
- - qcom,sc7180-qmp-usb3-dp-phy
- - qcom,sc7280-qmp-usb3-dp-phy
- - qcom,sc8180x-qmp-usb3-dp-phy
- - qcom,sdm845-qmp-usb3-dp-phy
- - qcom,sm8250-qmp-usb3-dp-phy
- reg:
- items:
- - description: Address and length of PHY's USB serdes block.
- - description: Address and length of the DP_COM control block.
- - description: Address and length of PHY's DP serdes block.
-
- reg-names:
- items:
- - const: usb
- - const: dp_com
- - const: dp
-
- "#clock-cells":
- enum: [ 1, 2 ]
-
- "#address-cells":
- enum: [ 1, 2 ]
-
- "#size-cells":
- enum: [ 1, 2 ]
-
- ranges: true
-
- clocks:
- items:
- - description: Phy aux clock.
- - description: Phy config clock.
- - description: 19.2 MHz ref clk.
- - description: Phy common block aux clock.
-
- clock-names:
- items:
- - const: aux
- - const: cfg_ahb
- - const: ref
- - const: com_aux
-
- resets:
- items:
- - description: reset of phy block.
- - description: phy common block reset.
-
- reset-names:
- items:
- - const: phy
- - const: common
-
- vdda-phy-supply:
- description:
- Phandle to a regulator supply to PHY core block.
-
- vdda-pll-supply:
- description:
- Phandle to 1.8V regulator supply to PHY refclk pll block.
-
- vddp-ref-clk-supply:
- description:
- Phandle to a regulator supply to any specific refclk pll block.
-
-#Required nodes:
-patternProperties:
- "^usb3-phy@[0-9a-f]+$":
- type: object
- description:
- The USB3 PHY.
-
- properties:
- reg:
- items:
- - description: Address and length of TX.
- - description: Address and length of RX.
- - description: Address and length of PCS.
- - description: Address and length of TX2.
- - description: Address and length of RX2.
- - description: Address and length of pcs_misc.
-
- clocks:
- items:
- - description: pipe clock
-
- clock-names:
- items:
- - const: pipe0
-
- clock-output-names:
- items:
- - const: usb3_phy_pipe_clk_src
-
- '#clock-cells':
- const: 0
-
- '#phy-cells':
- const: 0
-
- required:
- - reg
- - clocks
- - clock-names
- - '#clock-cells'
- - '#phy-cells'
-
- "^dp-phy@[0-9a-f]+$":
- type: object
- description:
- The DP PHY.
-
- properties:
- reg:
- items:
- - description: Address and length of TX.
- - description: Address and length of RX.
- - description: Address and length of PCS.
- - description: Address and length of TX2.
- - description: Address and length of RX2.
-
- '#clock-cells':
- const: 1
-
- '#phy-cells':
- const: 0
-
- required:
- - reg
- - '#clock-cells'
- - '#phy-cells'
-
-required:
- - compatible
- - reg
- - "#clock-cells"
- - "#address-cells"
- - "#size-cells"
- - ranges
- - clocks
- - clock-names
- - resets
- - reset-names
- - vdda-phy-supply
- - vdda-pll-supply
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/qcom,gcc-sdm845.h>
- usb_1_qmpphy: phy-wrapper@88e9000 {
- compatible = "qcom,sdm845-qmp-usb3-dp-phy";
- reg = <0x088e9000 0x18c>,
- <0x088e8000 0x10>,
- <0x088ea000 0x40>;
- reg-names = "usb", "dp_com", "dp";
- #clock-cells = <1>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x088e9000 0x2000>;
-
- clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
- <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
- <&gcc GCC_USB3_PRIM_CLKREF_CLK>,
- <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
- clock-names = "aux", "cfg_ahb", "ref", "com_aux";
-
- resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
- <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
- reset-names = "phy", "common";
-
- vdda-phy-supply = <&vdda_usb2_ss_1p2>;
- vdda-pll-supply = <&vdda_usb2_ss_core>;
-
- usb3-phy@200 {
- reg = <0x200 0x128>,
- <0x400 0x200>,
- <0xc00 0x218>,
- <0x600 0x128>,
- <0x800 0x200>,
- <0xa00 0x100>;
- #clock-cells = <0>;
- #phy-cells = <0>;
- clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
- clock-names = "pipe0";
- clock-output-names = "usb3_phy_pipe_clk_src";
- };
-
- dp-phy@88ea200 {
- reg = <0xa200 0x200>,
- <0xa400 0x200>,
- <0xaa00 0x200>,
- <0xa600 0x200>,
- <0xa800 0x200>;
- #clock-cells = <1>;
- #phy-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index d68ab49345b8..39851ba9de43 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -2,8 +2,8 @@
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm QUSB2 phy controller
@@ -18,18 +18,22 @@ properties:
oneOf:
- items:
- enum:
+ - qcom,ipq5424-qusb2-phy
+ - qcom,ipq6018-qusb2-phy
- qcom,ipq8074-qusb2-phy
+ - qcom,ipq9574-qusb2-phy
- qcom,msm8953-qusb2-phy
- qcom,msm8996-qusb2-phy
- qcom,msm8998-qusb2-phy
- qcom,qcm2290-qusb2-phy
+ - qcom,qcs615-qusb2-phy
- qcom,sdm660-qusb2-phy
- - qcom,ipq6018-qusb2-phy
- qcom,sm4250-qusb2-phy
- qcom,sm6115-qusb2-phy
- items:
- enum:
- qcom,sc7180-qusb2-phy
+ - qcom,sdm670-qusb2-phy
- qcom,sdm845-qusb2-phy
- qcom,sm6350-qusb2-phy
- const: qcom,qusb2-v2-phy
@@ -81,81 +85,74 @@ properties:
Phandle to TCSR syscon register region.
$ref: /schemas/types.yaml#/definitions/phandle
-if:
- properties:
- compatible:
- contains:
- const: qcom,qusb2-v2-phy
-then:
- properties:
- qcom,imp-res-offset-value:
- description:
- It is a 6 bit value that specifies offset to be
- added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
- tuning parameter that may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 63
- default: 0
-
- qcom,bias-ctrl-value:
- description:
- It is a 6 bit value that specifies bias-ctrl-value. It is a PHY
- tuning parameter that may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 63
- default: 32
-
- qcom,charge-ctrl-value:
- description:
- It is a 2 bit value that specifies charge-ctrl-value. It is a PHY
- tuning parameter that may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 3
- default: 0
-
- qcom,hstx-trim-value:
- description:
- It is a 4 bit value that specifies tuning for HSTX
- output current.
- Possible range is - 15mA to 24mA (stepsize of 600 uA).
- See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 15
- default: 3
-
- qcom,preemphasis-level:
- description:
- It is a 2 bit value that specifies pre-emphasis level.
- Possible range is 0 to 15% (stepsize of 5%).
- See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 3
- default: 2
-
- qcom,preemphasis-width:
- description:
- It is a 1 bit value that specifies how long the HSTX
- pre-emphasis (specified using qcom,preemphasis-level) must be in
- effect. Duration could be half-bit of full-bit.
- See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 1
- default: 0
-
- qcom,hsdisc-trim-value:
- description:
- It is a 2 bit value tuning parameter that control disconnect
- threshold and may vary for different boards of same SOC.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 3
- default: 0
+ qcom,imp-res-offset-value:
+ description:
+ It is a 6 bit value that specifies offset to be
+ added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
+ tuning parameter that may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 63
+ default: 0
+
+ qcom,bias-ctrl-value:
+ description:
+ It is a 6 bit value that specifies bias-ctrl-value. It is a PHY
+ tuning parameter that may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 63
+ default: 32
+
+ qcom,charge-ctrl-value:
+ description:
+ It is a 2 bit value that specifies charge-ctrl-value. It is a PHY
+ tuning parameter that may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 0
+
+ qcom,hstx-trim-value:
+ description:
+ It is a 4 bit value that specifies tuning for HSTX
+ output current.
+ Possible range is - 15mA to 24mA (stepsize of 600 uA).
+ See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 3
+
+ qcom,preemphasis-level:
+ description:
+ It is a 2 bit value that specifies pre-emphasis level.
+ Possible range is 0 to 15% (stepsize of 5%).
+ See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 2
+
+ qcom,preemphasis-width:
+ description:
+ It is a 1 bit value that specifies how long the HSTX
+ pre-emphasis (specified using qcom,preemphasis-level) must be in
+ effect. Duration could be half-bit of full-bit.
+ See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 0
+
+ qcom,hsdisc-trim-value:
+ description:
+ It is a 2 bit value tuning parameter that control disconnect
+ threshold and may vary for different boards of same SOC.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 0
required:
- compatible
@@ -168,6 +165,23 @@ required:
- vdda-phy-dpdm-supply
- resets
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: qcom,qusb2-v2-phy
+ then:
+ properties:
+ qcom,imp-res-offset-value: false
+ qcom,bias-ctrl-value: false
+ qcom,charge-ctrl-value: false
+ qcom,hstx-trim-value: false
+ qcom,preemphasis-level: false
+ qcom,preemphasis-width: false
+ qcom,hsdisc-trim-value: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml
new file mode 100644
index 000000000000..90fc8c039219
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SerDes/SGMII ethernet PHY controller
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+ The SerDes PHY sits between the MAC and the external PHY and provides
+ separate Rx Tx lines.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcs8300-dwmac-sgmii-phy
+ - const: qcom,sa8775p-dwmac-sgmii-phy
+ - const: qcom,sa8775p-dwmac-sgmii-phy
+
+ reg:
+ items:
+ - description: serdes
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: sgmi_ref
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to the PHY.
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
+ serdes_phy: phy@8901000 {
+ compatible = "qcom,sa8775p-dwmac-sgmii-phy";
+ reg = <0x08901000 0xe10>;
+ clocks = <&gcc GCC_SGMI_CLKREF_EN>;
+ clock-names = "sgmi_ref";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sata-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sata-phy.yaml
new file mode 100644
index 000000000000..0bf18d32c133
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sata-phy.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sata-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SATA PHY Controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konrad.dybcio@linaro.org>
+
+description:
+ The Qualcomm SATA PHY describes on-chip SATA Physical layer controllers.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq806x-sata-phy
+ - qcom,apq8064-sata-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: cfg
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-ipq806x.h>
+ sata_phy: sata-phy@1b400000 {
+ compatible = "qcom,ipq806x-sata-phy";
+ reg = <0x1b400000 0x200>;
+
+ clocks = <&gcc SATA_PHY_CFG_CLK>;
+ clock-names = "cfg";
+
+ #phy-cells = <0>;
+ };
+
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
new file mode 100644
index 000000000000..48bd11410e8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -0,0 +1,314 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (PCIe, SC8280XP)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ enum:
+ - qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,qcs615-qmp-gen3x1-pcie-phy
+ - qcom,qcs8300-qmp-gen4x2-pcie-phy
+ - qcom,sa8775p-qmp-gen4x2-pcie-phy
+ - qcom,sa8775p-qmp-gen4x4-pcie-phy
+ - qcom,sar2130p-qmp-gen3x2-pcie-phy
+ - qcom,sc8180x-qmp-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x1-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x2-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+ - qcom,sdm845-qhp-pcie-phy
+ - qcom,sdm845-qmp-pcie-phy
+ - qcom,sdx55-qmp-pcie-phy
+ - qcom,sdx65-qmp-gen4x2-pcie-phy
+ - qcom,sm8150-qmp-gen3x1-pcie-phy
+ - qcom,sm8150-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-gen3x1-pcie-phy
+ - qcom,sm8250-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-modem-pcie-phy
+ - qcom,sm8350-qmp-gen3x1-pcie-phy
+ - qcom,sm8350-qmp-gen3x2-pcie-phy
+ - qcom,sm8450-qmp-gen3x1-pcie-phy
+ - qcom,sm8450-qmp-gen4x2-pcie-phy
+ - qcom,sm8550-qmp-gen3x2-pcie-phy
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
+ - qcom,sm8650-qmp-gen3x2-pcie-phy
+ - qcom,sm8650-qmp-gen4x2-pcie-phy
+ - qcom,sm8750-qmp-gen3x2-pcie-phy
+ - qcom,x1e80100-qmp-gen3x2-pcie-phy
+ - qcom,x1e80100-qmp-gen4x2-pcie-phy
+ - qcom,x1e80100-qmp-gen4x4-pcie-phy
+ - qcom,x1e80100-qmp-gen4x8-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ minItems: 5
+ maxItems: 7
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+ - enum: [rchng, refgen]
+ - const: pipe
+ - const: pipediv2
+ - const: phy_aux
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: phy
+ - const: phy_nocsr
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ vdda-qref-supply: true
+
+ qcom,4ln-config-sel:
+ description: PCIe 4-lane configuration
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle of TCSR syscon
+ - description: offset of PCIe 4-lane configuration register
+ - description: offset of configuration bit for this PHY
+
+ "#clock-cells": true
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-qmp-gen3x4-pcie-phy
+ - qcom,x1e80100-qmp-gen4x4-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
+ then:
+ properties:
+ reg:
+ items:
+ - description: port a
+ - description: port b
+ required:
+ - qcom,4ln-config-sel
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs615-qmp-gen3x1-pcie-phy
+ - qcom,sar2130p-qmp-gen3x2-pcie-phy
+ - qcom,sc8180x-qmp-pcie-phy
+ - qcom,sdm845-qhp-pcie-phy
+ - qcom,sdm845-qmp-pcie-phy
+ - qcom,sdx55-qmp-pcie-phy
+ - qcom,sm8150-qmp-gen3x1-pcie-phy
+ - qcom,sm8150-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-gen3x1-pcie-phy
+ - qcom,sm8250-qmp-gen3x2-pcie-phy
+ - qcom,sm8250-qmp-modem-pcie-phy
+ - qcom,sm8350-qmp-gen3x1-pcie-phy
+ - qcom,sm8350-qmp-gen3x2-pcie-phy
+ - qcom,sm8450-qmp-gen3x1-pcie-phy
+ - qcom,sm8450-qmp-gen3x2-pcie-phy
+ - qcom,sm8550-qmp-gen3x2-pcie-phy
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
+ - qcom,sm8650-qmp-gen3x2-pcie-phy
+ - qcom,sm8650-qmp-gen4x2-pcie-phy
+ - qcom,sm8750-qmp-gen3x2-pcie-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ maxItems: 5
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,sa8775p-qmp-gen4x2-pcie-phy
+ - qcom,sa8775p-qmp-gen4x4-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x1-pcie-phy
+ - qcom,sc8280xp-qmp-gen3x2-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-gen4x8-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ clock-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-qmp-gen4x2-pcie-phy
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ clock-names:
+ minItems: 7
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
+ - qcom,sm8650-qmp-gen4x2-pcie-phy
+ - qcom,x1e80100-qmp-gen3x2-pcie-phy
+ - qcom,x1e80100-qmp-gen4x2-pcie-phy
+ - qcom,x1e80100-qmp-gen4x4-pcie-phy
+ - qcom,x1e80100-qmp-gen4x8-pcie-phy
+ - qcom,x1p42100-qmp-gen4x4-pcie-phy
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8450-qmp-gen4x2-pcie-phy
+ - qcom,sm8550-qmp-gen4x2-pcie-phy
+ - qcom,sm8650-qmp-gen4x2-pcie-phy
+ then:
+ properties:
+ "#clock-cells":
+ const: 1
+ else:
+ properties:
+ "#clock-cells":
+ const: 0
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+
+ pcie2b_phy: phy@1c18000 {
+ compatible = "qcom,sc8280xp-qmp-gen3x2-pcie-phy";
+ reg = <0x01c18000 0x2000>;
+
+ clocks = <&gcc GCC_PCIE_2B_AUX_CLK>,
+ <&gcc GCC_PCIE_2B_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_2A2B_CLKREF_CLK>,
+ <&gcc GCC_PCIE2B_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_2B_PIPE_CLK>,
+ <&gcc GCC_PCIE_2B_PIPEDIV2_CLK>;
+ clock-names = "aux", "cfg_ahb", "ref", "rchng",
+ "pipe", "pipediv2";
+
+ power-domains = <&gcc PCIE_2B_GDSC>;
+
+ resets = <&gcc GCC_PCIE_2B_PHY_BCR>;
+ reset-names = "phy";
+
+ vdda-phy-supply = <&vreg_l6d>;
+ vdda-pll-supply = <&vreg_l4d>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_2b_pipe_clk";
+
+ #phy-cells = <0>;
+ };
+
+ pcie2a_phy: phy@1c24000 {
+ compatible = "qcom,sc8280xp-qmp-gen3x4-pcie-phy";
+ reg = <0x01c24000 0x2000>, <0x01c26000 0x2000>;
+
+ clocks = <&gcc GCC_PCIE_2A_AUX_CLK>,
+ <&gcc GCC_PCIE_2A_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_2A2B_CLKREF_CLK>,
+ <&gcc GCC_PCIE2A_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_2A_PIPE_CLK>,
+ <&gcc GCC_PCIE_2A_PIPEDIV2_CLK>;
+ clock-names = "aux", "cfg_ahb", "ref", "rchng",
+ "pipe", "pipediv2";
+
+ power-domains = <&gcc PCIE_2A_GDSC>;
+
+ resets = <&gcc GCC_PCIE_2A_PHY_BCR>;
+ reset-names = "phy";
+
+ vdda-phy-supply = <&vreg_l6d>;
+ vdda-pll-supply = <&vreg_l4d>;
+
+ qcom,4ln-config-sel = <&tcsr 0xa044 0>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie_2a_pipe_clk";
+
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
new file mode 100644
index 000000000000..fba7b2549dde
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -0,0 +1,187 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-ufs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (UFS, SC8280XP)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcs615-qmp-ufs-phy
+ - const: qcom,sm6115-qmp-ufs-phy
+ - items:
+ - enum:
+ - qcom,qcs8300-qmp-ufs-phy
+ - const: qcom,sa8775p-qmp-ufs-phy
+ - items:
+ - enum:
+ - qcom,kaanapali-qmp-ufs-phy
+ - const: qcom,sm8750-qmp-ufs-phy
+ - enum:
+ - qcom,msm8996-qmp-ufs-phy
+ - qcom,msm8998-qmp-ufs-phy
+ - qcom,sa8775p-qmp-ufs-phy
+ - qcom,sc7180-qmp-ufs-phy
+ - qcom,sc7280-qmp-ufs-phy
+ - qcom,sc8180x-qmp-ufs-phy
+ - qcom,sc8280xp-qmp-ufs-phy
+ - qcom,sdm845-qmp-ufs-phy
+ - qcom,sm6115-qmp-ufs-phy
+ - qcom,sm6125-qmp-ufs-phy
+ - qcom,sm6350-qmp-ufs-phy
+ - qcom,sm7150-qmp-ufs-phy
+ - qcom,sm8150-qmp-ufs-phy
+ - qcom,sm8250-qmp-ufs-phy
+ - qcom,sm8350-qmp-ufs-phy
+ - qcom,sm8450-qmp-ufs-phy
+ - qcom,sm8475-qmp-ufs-phy
+ - qcom,sm8550-qmp-ufs-phy
+ - qcom,sm8650-qmp-ufs-phy
+ - qcom,sm8750-qmp-ufs-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: ufsphy
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ "#clock-cells":
+ const: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#phy-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-qmp-ufs-phy
+ - qcom,sa8775p-qmp-ufs-phy
+ - qcom,sc7180-qmp-ufs-phy
+ - qcom,sc7280-qmp-ufs-phy
+ - qcom,sc8180x-qmp-ufs-phy
+ - qcom,sc8280xp-qmp-ufs-phy
+ - qcom,sdm845-qmp-ufs-phy
+ - qcom,sm6115-qmp-ufs-phy
+ - qcom,sm6125-qmp-ufs-phy
+ - qcom,sm6350-qmp-ufs-phy
+ - qcom,sm7150-qmp-ufs-phy
+ - qcom,sm8150-qmp-ufs-phy
+ - qcom,sm8250-qmp-ufs-phy
+ - qcom,sm8350-qmp-ufs-phy
+ - qcom,sm8450-qmp-ufs-phy
+ - qcom,sm8475-qmp-ufs-phy
+ - qcom,sm8550-qmp-ufs-phy
+ - qcom,sm8650-qmp-ufs-phy
+ - qcom,sm8750-qmp-ufs-phy
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: ref
+ - const: ref_aux
+ - const: qref
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-qmp-ufs-phy
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: ref
+ - const: qref
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-qmp-ufs-phy
+ - qcom,msm8998-qmp-ufs-phy
+ then:
+ properties:
+ power-domains:
+ false
+ else:
+ required:
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ ufs_mem_phy: phy@1d87000 {
+ compatible = "qcom,sc8280xp-qmp-ufs-phy";
+ reg = <0x01d87000 0x1000>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
+ <&gcc GCC_UFS_REF_CLKREF_CLK>;
+
+ clock-names = "ref", "ref_aux", "qref";
+
+ power-domains = <&gcc UFS_PHY_GDSC>;
+
+ resets = <&ufs_mem_hc 0>;
+ reset-names = "ufsphy";
+
+ vdda-phy-supply = <&vreg_l6b>;
+ vdda-pll-supply = <&vreg_l3b>;
+
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
new file mode 100644
index 000000000000..863a1a446739
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
@@ -0,0 +1,197 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP PHY controller (USB, SC8280XP)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+properties:
+ compatible:
+ enum:
+ - qcom,ipq5424-qmp-usb3-phy
+ - qcom,ipq6018-qmp-usb3-phy
+ - qcom,ipq8074-qmp-usb3-phy
+ - qcom,ipq9574-qmp-usb3-phy
+ - qcom,msm8996-qmp-usb3-phy
+ - qcom,qcs8300-qmp-usb3-uni-phy
+ - qcom,qdu1000-qmp-usb3-uni-phy
+ - qcom,sa8775p-qmp-usb3-uni-phy
+ - qcom,sc8180x-qmp-usb3-uni-phy
+ - qcom,sc8280xp-qmp-usb3-uni-phy
+ - qcom,sdm845-qmp-usb3-uni-phy
+ - qcom,sdx55-qmp-usb3-uni-phy
+ - qcom,sdx65-qmp-usb3-uni-phy
+ - qcom,sdx75-qmp-usb3-uni-phy
+ - qcom,sm8150-qmp-usb3-uni-phy
+ - qcom,sm8250-qmp-usb3-uni-phy
+ - qcom,sm8350-qmp-usb3-uni-phy
+ - qcom,x1e80100-qmp-usb3-uni-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ maxItems: 5
+
+ clock-names:
+ minItems: 4
+ maxItems: 5
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: phy_phy
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - clock-output-names
+ - "#phy-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5424-qmp-usb3-phy
+ - qcom,ipq6018-qmp-usb3-phy
+ - qcom,ipq8074-qmp-usb3-phy
+ - qcom,ipq9574-qmp-usb3-phy
+ - qcom,msm8996-qmp-usb3-phy
+ - qcom,sdx55-qmp-usb3-uni-phy
+ - qcom,sdx65-qmp-usb3-uni-phy
+ - qcom,sdx75-qmp-usb3-uni-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: aux
+ - const: ref
+ - const: cfg_ahb
+ - const: pipe
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs8300-qmp-usb3-uni-phy
+ - qcom,qdu1000-qmp-usb3-uni-phy
+ - qcom,sa8775p-qmp-usb3-uni-phy
+ - qcom,sc8180x-qmp-usb3-uni-phy
+ - qcom,sc8280xp-qmp-usb3-uni-phy
+ - qcom,sm8150-qmp-usb3-uni-phy
+ - qcom,sm8250-qmp-usb3-uni-phy
+ - qcom,sm8350-qmp-usb3-uni-phy
+ - qcom,x1e80100-qmp-usb3-uni-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: aux
+ - const: ref
+ - const: com_aux
+ - const: pipe
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdm845-qmp-usb3-uni-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ items:
+ - const: aux
+ - const: cfg_ahb
+ - const: ref
+ - const: com_aux
+ - const: pipe
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-qmp-usb3-uni-phy
+ - qcom,sc8180x-qmp-usb3-uni-phy
+ - qcom,sc8280xp-qmp-usb3-uni-phy
+ - qcom,x1e80100-qmp-usb3-uni-phy
+ then:
+ required:
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+
+ phy@88ef000 {
+ compatible = "qcom,sc8280xp-qmp-usb3-uni-phy";
+ reg = <0x088ef000 0x2000>;
+
+ clocks = <&gcc GCC_USB3_MP_PHY_AUX_CLK>,
+ <&gcc GCC_USB3_MP0_CLKREF_CLK>,
+ <&gcc GCC_USB3_MP_PHY_COM_AUX_CLK>,
+ <&gcc GCC_USB3_MP_PHY_PIPE_0_CLK>;
+ clock-names = "aux", "ref", "com_aux", "pipe";
+
+ power-domains = <&gcc USB30_MP_GDSC>;
+
+ resets = <&gcc GCC_USB3_UNIPHY_MP0_BCR>,
+ <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>;
+ reset-names = "phy", "phy_phy";
+
+ vdda-phy-supply = <&vreg_l3a>;
+ vdda-pll-supply = <&vreg_l5a>;
+
+ #clock-cells = <0>;
+ clock-output-names = "usb2_phy0_pipe_clk";
+
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
new file mode 100644
index 000000000000..e0ec45b96bf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -0,0 +1,270 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QMP USB4-USB3-DP PHY controller (SC8280XP)
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ The QMP PHY controller supports physical layer functionality for a number of
+ controllers on Qualcomm chipsets, such as, PCIe, UFS and USB.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sar2130p-qmp-usb3-dp-phy
+ - qcom,sc7180-qmp-usb3-dp-phy
+ - qcom,sc7280-qmp-usb3-dp-phy
+ - qcom,sc8180x-qmp-usb3-dp-phy
+ - qcom,sc8280xp-qmp-usb43dp-phy
+ - qcom,sdm845-qmp-usb3-dp-phy
+ - qcom,sm6350-qmp-usb3-dp-phy
+ - qcom,sm8150-qmp-usb3-dp-phy
+ - qcom,sm8250-qmp-usb3-dp-phy
+ - qcom,sm8350-qmp-usb3-dp-phy
+ - qcom,sm8450-qmp-usb3-dp-phy
+ - qcom,sm8550-qmp-usb3-dp-phy
+ - qcom,sm8650-qmp-usb3-dp-phy
+ - qcom,sm8750-qmp-usb3-dp-phy
+ - qcom,x1e80100-qmp-usb3-dp-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 4
+ maxItems: 5
+
+ clock-names:
+ minItems: 4
+ items:
+ - const: aux
+ - const: ref
+ - const: com_aux
+ - const: usb3_pipe
+ - const: cfg_ahb
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: common
+
+ vdda-phy-supply: true
+
+ vdda-pll-supply: true
+
+ "#clock-cells":
+ const: 1
+ description:
+ See include/dt-bindings/phy/phy-qcom-qmp.h
+
+ "#phy-cells":
+ const: 1
+ description:
+ See include/dt-bindings/phy/phy-qcom-qmp.h
+
+ mode-switch: true
+ orientation-switch: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: Output endpoint of the PHY
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description: Display Port Output lanes of the PHY when used with static mapping,
+ The entry index is the DP lanes index, and the number is the PHY
+ signal in the order RX0, TX0, TX1, RX1.
+ unevaluatedProperties: false
+
+ properties:
+ # Static lane mappings are mutually exclusive with typec-mux/orientation-mux
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 4
+ oneOf:
+ - items: # DisplayPort 1 lane, normal orientation
+ - const: 3
+ - items: # DisplayPort 1 lane, flipped orientation
+ - const: 0
+ - items: # DisplayPort 2 lanes, normal orientation
+ - const: 3
+ - const: 2
+ - items: # DisplayPort 2 lanes, flipped orientation
+ - const: 0
+ - const: 1
+ - items: # DisplayPort 4 lanes, normal orientation
+ - const: 3
+ - const: 2
+ - const: 1
+ - const: 0
+ - items: # DisplayPort 4 lanes, flipped orientation
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+ required:
+ - data-lanes
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description: USB Output lanes of the PHY when used with static mapping.
+ The entry index is the USB3 lane in the order TX then RX, and the
+ number is the PHY signal in the order RX0, TX0, TX1, RX1.
+ unevaluatedProperties: false
+
+ properties:
+ # Static lane mappings are mutually exclusive with typec-mux/orientation-mux
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ oneOf:
+ - items: # USB3, normal orientation
+ - const: 1
+ - const: 0
+ - items: # USB3, flipped orientation
+ - const: 2
+ - const: 3
+
+ required:
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the DisplayPort controller
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - "#phy-cells"
+
+allOf:
+ - $ref: /schemas/usb/usb-switch.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-qmp-usb3-dp-phy
+ - qcom,sdm845-qmp-usb3-dp-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ maxItems: 5
+ else:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ maxItems: 4
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sar2130p-qmp-usb3-dp-phy
+ - qcom,sc8280xp-qmp-usb43dp-phy
+ - qcom,sm6350-qmp-usb3-dp-phy
+ - qcom,sm8550-qmp-usb3-dp-phy
+ - qcom,sm8650-qmp-usb3-dp-phy
+ - qcom,sm8750-qmp-usb3-dp-phy
+ - qcom,x1e80100-qmp-usb3-dp-phy
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sc8280xp.h>
+
+ phy@88eb000 {
+ compatible = "qcom,sc8280xp-qmp-usb43dp-phy";
+ reg = <0x088eb000 0x4000>;
+
+ clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
+ <&gcc GCC_USB4_EUD_CLKREF_CLK>,
+ <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+ <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+ clock-names = "aux", "ref", "com_aux", "usb3_pipe";
+
+ power-domains = <&gcc USB30_PRIM_GDSC>;
+
+ resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
+ <&gcc GCC_USB4_DP_PHY_PRIM_BCR>;
+ reset-names = "phy", "common";
+
+ vdda-phy-supply = <&vreg_l9d>;
+ vdda-pll-supply = <&vreg_l4d>;
+
+ orientation-switch;
+
+ #clock-cells = <1>;
+ #phy-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&typec_connector_ss>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&dwc3_ss_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&mdss_dp_out>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
new file mode 100644
index 000000000000..854f70af0a6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,snps-eusb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SNPS eUSB2 phy controller
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ eUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,milos-snps-eusb2-phy
+ - qcom,sar2130p-snps-eusb2-phy
+ - qcom,sdx75-snps-eusb2-phy
+ - qcom,sm8650-snps-eusb2-phy
+ - qcom,x1e80100-snps-eusb2-phy
+ - const: qcom,sm8550-snps-eusb2-phy
+ - const: qcom,sm8550-snps-eusb2-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: ref
+
+ clock-names:
+ items:
+ - const: ref
+
+ resets:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+ description:
+ Phandle to eUSB2 to USB 2.0 repeater
+
+ vdd-supply:
+ description:
+ Phandle to 0.88V regulator supply to PHY digital circuit.
+
+ vdda12-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+ - vdd-supply
+ - vdda12-supply
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm8550-tcsr.h>
+
+ usb_1_hsphy: phy@88e3000 {
+ compatible = "qcom,sm8550-snps-eusb2-phy";
+ reg = <0x88e3000 0x154>;
+ #phy-cells = <0>;
+
+ clocks = <&tcsrcc TCSR_USB2_CLKREF_EN>;
+ clock-names = "ref";
+
+ vdd-supply = <&vreg_l1e_0p88>;
+ vdda12-supply = <&vreg_l3e_1p2>;
+
+ resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
new file mode 100644
index 000000000000..5bf0d6c9c025
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,snps-eusb2-repeater.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,snps-eusb2-repeater.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Synopsis eUSB2 to USB 2.0 repeater
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ eUSB2 repeater converts between eUSB2 and USB 2.0 signaling levels and
+ allows a eUSB2 PHY to connect to legacy USB 2.0 products
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm7550ba-eusb2-repeater
+ - const: qcom,pm8550b-eusb2-repeater
+ - enum:
+ - qcom,pm8550b-eusb2-repeater
+ - qcom,pmiv0104-eusb2-repeater
+ - qcom,smb2360-eusb2-repeater
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ vdd18-supply: true
+
+ vdd3-supply: true
+
+ qcom,tune-usb2-disc-thres:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: High-Speed disconnect threshold
+ minimum: 0
+ maximum: 7
+
+ qcom,tune-usb2-amplitude:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: High-Speed transmit amplitude
+ minimum: 0
+ maximum: 15
+
+ qcom,tune-usb2-preem:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: High-Speed TX pre-emphasis tuning
+ minimum: 0
+ maximum: 7
+
+ qcom,tune-res-fsdif:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: FS Differential TX Output Resistance Tuning
+ minimum: 0
+ maximum: 7
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@7 {
+ reg = <0x7 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8550b_eusb2_repeater: phy@fd00 {
+ compatible = "qcom,pm8550b-eusb2-repeater";
+ reg = <0xfd00>;
+ #phy-cells = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt
deleted file mode 100644
index 2cb2168cef41..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-Qualcomm's APQ8016/MSM8916 USB transceiver controller
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Should contain "qcom,usb-8x16-phy".
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: USB PHY base address and length of the register map
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: See clock-bindings.txt section "consumers". List of
- two clock specifiers for interface and core controller
- clocks.
-
-- clock-names:
- Usage: required
- Value type: <string>
- Definition: Must contain "iface" and "core" strings.
-
-- vddcx-supply:
- Usage: required
- Value type: <phandle>
- Definition: phandle to the regulator VDCCX supply node.
-
-- v1p8-supply:
- Usage: required
- Value type: <phandle>
- Definition: phandle to the regulator 1.8V supply node.
-
-- v3p3-supply:
- Usage: required
- Value type: <phandle>
- Definition: phandle to the regulator 3.3V supply node.
-
-- resets:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: See reset.txt section "consumers". PHY reset specifier.
-
-- reset-names:
- Usage: required
- Value type: <string>
- Definition: Must contain "phy" string.
-
-- switch-gpio:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: Some boards are using Dual SPDT USB Switch, witch is
- controlled by GPIO to de/multiplex D+/D- USB lines
- between connectors.
-
-Example:
- usb_phy: phy@78d9000 {
- compatible = "qcom,usb-8x16-phy";
- reg = <0x78d9000 0x400>;
-
- vddcx-supply = <&pm8916_s1_corner>;
- v1p8-supply = <&pm8916_l7>;
- v3p3-supply = <&pm8916_l13>;
-
- clocks = <&gcc GCC_USB_HS_AHB_CLK>,
- <&gcc GCC_USB_HS_SYSTEM_CLK>;
- clock-names = "iface", "core";
-
- resets = <&gcc GCC_USB2A_PHY_BCR>;
- reset-names = "phy";
-
- // D+/D- lines: 1 - Routed to HUB, 0 - Device connector
- switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
- };
-
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
index abcc4373f39e..6c99e02b2b4f 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/qcom,usb-hs-28nm.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/qcom,usb-hs-28nm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Synopsys DesignWare Core 28nm High-Speed PHY
@@ -16,7 +16,6 @@ properties:
compatible:
enum:
- qcom,usb-hs-28nm-femtophy
- - qcom,usb-hs-28nm-mdm9607
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml
index 0655e485b260..e03b516c698c 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/qcom,usb-hs-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm's USB HS PHY binding description
+title: Qualcomm's USB HS PHY
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
@@ -13,7 +13,10 @@ if:
properties:
compatible:
contains:
- const: qcom,usb-hs-phy-apq8064
+ enum:
+ - qcom,usb-hs-phy-apq8064
+ - qcom,usb-hs-phy-msm8660
+ - qcom,usb-hs-phy-msm8960
then:
properties:
resets:
@@ -39,7 +42,9 @@ properties:
- enum:
- qcom,usb-hs-phy-apq8064
- qcom,usb-hs-phy-msm8226
+ - qcom,usb-hs-phy-msm8660
- qcom,usb-hs-phy-msm8916
+ - qcom,usb-hs-phy-msm8960
- qcom,usb-hs-phy-msm8974
- const: qcom,usb-hs-phy
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
deleted file mode 100644
index 3c7cb2be4b12..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Qualcomm's USB HSIC PHY
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Should contain "qcom,usb-hsic-phy" and more specifically one of the
- following:
-
- "qcom,usb-hsic-phy-mdm9615"
- "qcom,usb-hsic-phy-msm8974"
-
-- #phy-cells:
- Usage: required
- Value type: <u32>
- Definition: Should contain 0
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Should contain clock specifier for phy, calibration and
- a calibration sleep clock
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: Should contain "phy, "cal" and "cal_sleep"
-
-- pinctrl-names:
- Usage: required
- Value type: <stringlist>
- Definition: Should contain "init" and "default" in that order
-
-- pinctrl-0:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: List of pinctrl settings to apply to keep HSIC pins in a glitch
- free state
-
-- pinctrl-1:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: List of pinctrl settings to apply to mux out the HSIC pins
-
-EXAMPLE
-
-usb-controller {
- ulpi {
- phy {
- compatible = "qcom,usb-hsic-phy-msm8974",
- "qcom,usb-hsic-phy";
- #phy-cells = <0>;
- pinctrl-names = "init", "default";
- pinctrl-0 = <&hsic_sleep>;
- pinctrl-1 = <&hsic_default>;
- clocks = <&gcc GCC_USB_HSIC_CLK>,
- <&gcc GCC_USB_HSIC_IO_CAL_CLK>,
- <&gcc GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
- clock-names = "phy", "cal", "cal_sleep";
- assigned-clocks = <&gcc GCC_USB_HSIC_IO_CAL_CLK>;
- assigned-clock-rates = <960000>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml
new file mode 100644
index 000000000000..077e13a94448
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/qcom,usb-hsic-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm USB HSIC PHY Controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Vinod Koul <vkoul@kernel.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,usb-hsic-phy-mdm9615
+ - qcom,usb-hsic-phy-msm8974
+ - const: qcom,usb-hsic-phy
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: phy
+ - const: cal
+ - const: cal_sleep
+
+ "#phy-cells":
+ const: 0
+
+ pinctrl-0: true
+ pinctrl-1: true
+
+ pinctrl-names:
+ items:
+ - const: init
+ - const: default
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - "#phy-cells"
+ - pinctrl-0
+ - pinctrl-1
+ - pinctrl-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8974.h>
+
+ phy {
+ compatible = "qcom,usb-hsic-phy-msm8974",
+ "qcom,usb-hsic-phy";
+ clocks = <&gcc GCC_USB_HSIC_CLK>,
+ <&gcc GCC_USB_HSIC_IO_CAL_CLK>,
+ <&gcc GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
+ clock-names = "phy", "cal", "cal_sleep";
+ #phy-cells = <0>;
+ pinctrl-names = "init", "default";
+ pinctrl-0 = <&hsic_sleep>;
+ pinctrl-1 = <&hsic_default>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
index 7a0e6a9854da..661759b25064 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Synopsys Femto High-Speed USB PHY V2
@@ -14,17 +14,26 @@ description: |
properties:
compatible:
- enum:
- - qcom,usb-snps-hs-5nm-phy
- - qcom,usb-snps-hs-7nm-phy
- - qcom,sc7280-usb-hs-phy
- - qcom,sc8180x-usb-hs-phy
- - qcom,sc8280xp-usb-hs-phy
- - qcom,sm8150-usb-hs-phy
- - qcom,sm8250-usb-hs-phy
- - qcom,sm8350-usb-hs-phy
- - qcom,sm8450-usb-hs-phy
- - qcom,usb-snps-femto-v2-phy
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sa8775p-usb-hs-phy
+ - qcom,sc8280xp-usb-hs-phy
+ - const: qcom,usb-snps-hs-5nm-phy
+ - items:
+ - enum:
+ - qcom,qcs8300-usb-hs-phy
+ - qcom,qdu1000-usb-hs-phy
+ - qcom,sc7280-usb-hs-phy
+ - qcom,sc8180x-usb-hs-phy
+ - qcom,sdx55-usb-hs-phy
+ - qcom,sdx65-usb-hs-phy
+ - qcom,sm6375-usb-hs-phy
+ - qcom,sm8150-usb-hs-phy
+ - qcom,sm8250-usb-hs-phy
+ - qcom,sm8350-usb-hs-phy
+ - qcom,sm8450-usb-hs-phy
+ - const: qcom,usb-snps-hs-7nm-phy
reg:
maxItems: 1
@@ -53,6 +62,94 @@ properties:
vdda33-supply:
description: phandle to the regulator 3.3V supply node.
+ qcom,hs-disconnect-bp:
+ description:
+ This adjusts the voltage level for the threshold used to
+ detect a disconnect event at the host.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: -272
+ maximum: 2156
+
+ qcom,squelch-detector-bp:
+ description:
+ This adjusts the voltage level for the threshold used to
+ detect valid high-speed data.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: -2090
+ maximum: 1590
+
+ qcom,hs-amplitude-bp:
+ description:
+ This adjusts the high-speed DC level voltage.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: -660
+ maximum: 2670
+
+ qcom,pre-emphasis-duration-bp:
+ description:
+ This signal controls the duration for which the
+ HS pre-emphasis current is sourced onto DP<#> or DM<#>.
+ The HS Transmitter pre-emphasis duration is defined in terms of
+ unit amounts. One unit of pre-emphasis duration is approximately
+ 650 ps and is defined as 1X pre-emphasis duration.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: 10000
+ maximum: 20000
+
+ qcom,pre-emphasis-amplitude-bp:
+ description:
+ This signal controls the amount of current sourced to
+ DP<#> and DM<#> after a J-to-K or K-to-J transition.
+ The HS Transmitter pre-emphasis current is defined in terms of unit
+ amounts. One unit amount is approximately 2 mA and is defined as
+ 1X pre-emphasis current.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: 10000
+ maximum: 40000
+
+ qcom,hs-rise-fall-time-bp:
+ description:
+ This adjusts the rise/fall times of the high-speed waveform.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: -4100
+ maximum: 5430
+
+ qcom,hs-crossover-voltage-microvolt:
+ description:
+ This adjusts the voltage at which the DP<#> and DM<#>
+ signals cross while transmitting in HS mode.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: -31000
+ maximum: 28000
+
+ qcom,hs-output-impedance-micro-ohms:
+ description:
+ In some applications, there can be significant series resistance
+ on the D+ and D- paths between the transceiver and cable. This adjusts
+ the driver source impedance to compensate for added series
+ resistance on the USB. The hardware accepts only discrete values. The
+ value closest to the provided input will be chosen as the override value
+ for this param.
+ minimum: -2300000
+ maximum: 6100000
+
+ qcom,ls-fs-output-impedance-bp:
+ description:
+ This adjusts the low- and full-speed single-ended source
+ impedance while driving high. The following adjustment values are based
+ on nominal process, voltage, and temperature.
+ The hardware accepts only discrete values. The value closest to the
+ provided input will be chosen as the override value for this param.
+ minimum: -1053
+ maximum: 1310
+
required:
- compatible
- reg
@@ -71,7 +168,7 @@ examples:
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sm8150.h>
phy@88e2000 {
- compatible = "qcom,sm8150-usb-hs-phy";
+ compatible = "qcom,sm8150-usb-hs-phy", "qcom,usb-snps-hs-7nm-phy";
reg = <0x088e2000 0x400>;
#phy-cells = <0>;
diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml
index bd1388d62ce0..6e4254ff1cd7 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/qcom,usb-ss.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/qcom,usb-ss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Synopsys 1.0.0 SuperSpeed USB PHY
diff --git a/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt b/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt
deleted file mode 100644
index 952f6c96bab9..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Qualcomm APQ8064 SATA PHY Controller
-------------------------------------
-
-SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
-Each SATA PHY controller should have its own node.
-
-Required properties:
-- compatible: compatible list, contains "qcom,apq8064-sata-phy".
-- reg: offset and length of the SATA PHY register set;
-- #phy-cells: must be zero
-- clocks: a list of phandles and clock-specifier pairs, one for each entry in
- clock-names.
-- clock-names: must be "cfg" for phy config clock.
-
-Example:
- sata_phy: sata-phy@1b400000 {
- compatible = "qcom,apq8064-sata-phy";
- reg = <0x1b400000 0x200>;
-
- clocks = <&gcc SATA_PHY_CFG_CLK>;
- clock-names = "cfg";
-
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt b/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt
deleted file mode 100644
index 76bfbd056202..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Qualcomm IPQ806x SATA PHY Controller
-------------------------------------
-
-SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
-Each SATA PHY controller should have its own node.
-
-Required properties:
-- compatible: compatible list, contains "qcom,ipq806x-sata-phy"
-- reg: offset and length of the SATA PHY register set;
-- #phy-cells: must be zero
-- clocks: must be exactly one entry
-- clock-names: must be "cfg"
-
-Example:
- sata_phy: sata-phy@1b400000 {
- compatible = "qcom,ipq806x-sata-phy";
- reg = <0x1b400000 0x200>;
-
- clocks = <&gcc SATA_PHY_CFG_CLK>;
- clock-names = "cfg";
-
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt b/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
deleted file mode 100644
index 30064253f290..000000000000
--- a/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Qualcomm PCIe2 PHY controller
-=============================
-
-The Qualcomm PCIe2 PHY is a Synopsys based phy found in a number of Qualcomm
-platforms.
-
-Required properties:
- - compatible: compatible list, should be:
- "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy"
-
- - reg: offset and length of the PHY register set.
- - #phy-cells: must be 0.
-
- - clocks: a clock-specifier pair for the "pipe" clock
-
- - vdda-vp-supply: phandle to low voltage regulator
- - vdda-vph-supply: phandle to high voltage regulator
-
- - resets: reset-specifier pairs for the "phy" and "pipe" resets
- - reset-names: list of resets, should contain:
- "phy" and "pipe"
-
- - clock-output-names: name of the outgoing clock signal from the PHY PLL
- - #clock-cells: must be 0
-
-Example:
- phy@7786000 {
- compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
- reg = <0x07786000 0xb8>;
-
- clocks = <&gcc GCC_PCIE_0_PIPE_CLK>;
- resets = <&gcc GCC_PCIEPHY_0_PHY_BCR>,
- <&gcc GCC_PCIE_0_PIPE_ARES>;
- reset-names = "phy", "pipe";
-
- vdda-vp-supply = <&vreg_l3_1p05>;
- vdda-vph-supply = <&vreg_l5_1p8>;
-
- clock-output-names = "pcie_0_pipe_clk";
- #clock-cells = <0>;
- #phy-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml
index 3e7191b168fb..09c614952fea 100644
--- a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/qcom-usb-ipq4019-phy.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/qcom-usb-ipq4019-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcom IPQ40xx Dakota HS/SS USB PHY
diff --git a/Documentation/devicetree/bindings/phy/ralink-usb-phy.txt b/Documentation/devicetree/bindings/phy/ralink-usb-phy.txt
deleted file mode 100644
index 9d2868a437ab..000000000000
--- a/Documentation/devicetree/bindings/phy/ralink-usb-phy.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Mediatek/Ralink USB PHY
-
-Required properties:
- - compatible: "ralink,rt3352-usbphy"
- "mediatek,mt7620-usbphy"
- "mediatek,mt7628-usbphy"
- - reg: required for "mediatek,mt7628-usbphy", unused otherwise
- - #phy-cells: should be 0
- - ralink,sysctl: a phandle to a ralink syscon register region
- - resets: the two reset controllers for host and device
- - reset-names: the names of the 2 reset controllers
-
-Example:
-
-usbphy: phy {
- compatible = "mediatek,mt7628-usbphy";
- reg = <0x10120000 0x1000>;
- #phy-cells = <0>;
-
- ralink,sysctl = <&sysc>;
- resets = <&rstctrl 22 &rstctrl 25>;
- reset-names = "host", "device";
-};
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
deleted file mode 100644
index a3bd1c4499b7..000000000000
--- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-* Renesas R-Car generation 2 USB PHY
-
-This file provides information on what the device node for the R-Car generation
-2 USB PHY contains.
-
-Required properties:
-- compatible: "renesas,usb-phy-r8a7742" if the device is a part of R8A7742 SoC.
- "renesas,usb-phy-r8a7743" if the device is a part of R8A7743 SoC.
- "renesas,usb-phy-r8a7744" if the device is a part of R8A7744 SoC.
- "renesas,usb-phy-r8a7745" if the device is a part of R8A7745 SoC.
- "renesas,usb-phy-r8a77470" if the device is a part of R8A77470 SoC.
- "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
- "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
- "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
- "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 or
- RZ/G1 compatible device.
-
- When compatible with the generic version, nodes must list the
- SoC-specific version corresponding to the platform first
- followed by the generic version.
-
-- reg: offset and length of the register block.
-- #address-cells: number of address cells for the USB channel subnodes, must
- be <1>.
-- #size-cells: number of size cells for the USB channel subnodes, must be <0>.
-- clocks: clock phandle and specifier pair.
-- clock-names: string, clock input name, must be "usbhs".
-
-The USB PHY device tree node should have the subnodes corresponding to the USB
-channels. These subnodes must contain the following properties:
-- reg: the USB controller selector; see the table below for the values.
-- #phy-cells: see phy-bindings.txt in the same directory, must be <1>.
-
-The phandle's argument in the PHY specifier is the USB controller selector for
-the USB channel other than r8a77470 SoC; see the selector meanings below:
-
-+-----------+---------------+---------------+
-|\ Selector | | |
-+ --------- + 0 | 1 |
-| Channel \| | |
-+-----------+---------------+---------------+
-| 0 | PCI EHCI/OHCI | HS-USB |
-| 2 | PCI EHCI/OHCI | xHCI |
-+-----------+---------------+---------------+
-
-For r8a77470 SoC;see the selector meaning below:
-
-+-----------+---------------+---------------+
-|\ Selector | | |
-+ --------- + 0 | 1 |
-| Channel \| | |
-+-----------+---------------+---------------+
-| 0 | EHCI/OHCI | HS-USB |
-+-----------+---------------+---------------+
-
-Example (Lager board):
-
- usb-phy@e6590100 {
- compatible = "renesas,usb-phy-r8a7790", "renesas,rcar-gen2-usb-phy";
- reg = <0 0xe6590100 0 0x100>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&cpg CPG_MOD 704>;
- clock-names = "usbhs";
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 704>;
-
- usb0: usb-channel@0 {
- reg = <0>;
- #phy-cells = <1>;
- };
- usb2: usb-channel@2 {
- reg = <2>;
- #phy-cells = <1>;
- };
- };
-
-Example (iWave RZ/G1C sbc):
-
- usbphy0: usb-phy0@e6590100 {
- compatible = "renesas,usb-phy-r8a77470",
- "renesas,rcar-gen2-usb-phy";
- reg = <0 0xe6590100 0 0x100>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&cpg CPG_MOD 704>;
- clock-names = "usbhs";
- power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
- resets = <&cpg 704>;
-
- usb0: usb-channel@0 {
- reg = <0>;
- #phy-cells = <1>;
- };
- };
-
- usbphy1: usb-phy@e6598100 {
- compatible = "renesas,usb-phy-r8a77470",
- "renesas,rcar-gen2-usb-phy";
- reg = <0 0xe6598100 0 0x100>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&cpg CPG_MOD 706>;
- clock-names = "usbhs";
- power-domains = <&sysc R8A77470_PD_ALWAYS_ON>;
- resets = <&cpg 706>;
-
- usb1: usb-channel@0 {
- reg = <0>;
- #phy-cells = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml b/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml
new file mode 100644
index 000000000000..9911ada39ee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/realtek,usb2phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC SoCs USB 2.0 PHY
+
+maintainers:
+ - Stanley Chang <stanley_chang@realtek.com>
+
+description: |
+ Realtek USB 2.0 PHY support the digital home center (DHC) RTD series SoCs.
+ The USB 2.0 PHY driver is designed to support the XHCI controller. The SoCs
+ support multiple XHCI controllers. One PHY device node maps to one XHCI
+ controller.
+
+ RTD1295/RTD1619 SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some
+ controllers.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1395 SoCs USB
+ The USB architecture includes two XHCI controllers.
+ The controller#0 has one USB 2.0 PHY. The controller#1 includes two USB 2.0
+ PHY.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ |- phy#1
+
+ RTD1319/RTD1619b SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1319d SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+
+ RTD1312c/RTD1315e SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1295-usb2phy
+ - realtek,rtd1312c-usb2phy
+ - realtek,rtd1315e-usb2phy
+ - realtek,rtd1319-usb2phy
+ - realtek,rtd1319d-usb2phy
+ - realtek,rtd1395-usb2phy
+ - realtek,rtd1395-usb2phy-2port
+ - realtek,rtd1619-usb2phy
+ - realtek,rtd1619b-usb2phy
+
+ reg:
+ items:
+ - description: PHY data registers
+ - description: PHY control registers
+
+ "#phy-cells":
+ const: 0
+
+ nvmem-cells:
+ maxItems: 2
+ description:
+ Phandles to nvmem cell that contains the trimming data.
+ If unspecified, default value is used.
+
+ nvmem-cell-names:
+ items:
+ - const: usb-dc-cal
+ - const: usb-dc-dis
+ description:
+ The following names, which correspond to each nvmem-cells.
+ usb-dc-cal is the driving level for each phy specified via efuse.
+ usb-dc-dis is the disconnection level for each phy specified via efuse.
+
+ realtek,inverse-hstx-sync-clock:
+ description:
+ For one of the phys of RTD1619b SoC, the synchronous clock of the
+ high-speed tx must be inverted.
+ type: boolean
+
+ realtek,driving-level:
+ description:
+ Control the magnitude of High speed Dp/Dm output swing (mV).
+ For a different board or port, the original magnitude maybe not meet
+ the specification. In this situation we can adjust the value to meet
+ the specification.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 8
+ minimum: 0
+ maximum: 31
+
+ realtek,driving-level-compensate:
+ description:
+ For RTD1315e SoC, the driving level can be adjusted by reading the
+ efuse table. This property provides drive compensation.
+ If the magnitude of High speed Dp/Dm output swing still not meet the
+ specification, then we can set this value to meet the specification.
+ $ref: /schemas/types.yaml#/definitions/int32
+ default: 0
+ minimum: -8
+ maximum: 8
+
+ realtek,disconnection-compensate:
+ description:
+ This adjusts the disconnection level compensation for the different
+ boards with different disconnection level.
+ $ref: /schemas/types.yaml#/definitions/int32
+ default: 0
+ minimum: -8
+ maximum: 8
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - realtek,rtd1619b-usb2phy
+ then:
+ properties:
+ realtek,inverse-hstx-sync-clock: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - realtek,rtd1315e-usb2phy
+ then:
+ properties:
+ realtek,driving-level-compensate: false
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@13214 {
+ compatible = "realtek,rtd1619b-usb2phy";
+ reg = <0x13214 0x4>, <0x28280 0x4>;
+ #phy-cells = <0>;
+ nvmem-cells = <&otp_usb_port0_dc_cal>, <&otp_usb_port0_dc_dis>;
+ nvmem-cell-names = "usb-dc-cal", "usb-dc-dis";
+
+ realtek,inverse-hstx-sync-clock;
+ realtek,driving-level = <0xa>;
+ realtek,disconnection-compensate = <(-1)>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml b/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml
new file mode 100644
index 000000000000..dfe2bb4e59e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/realtek,usb3phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC SoCs USB 3.0 PHY
+
+maintainers:
+ - Stanley Chang <stanley_chang@realtek.com>
+
+description: |
+ Realtek USB 3.0 PHY support the digital home center (DHC) RTD series SoCs.
+ The USB 3.0 PHY driver is designed to support the XHCI controller. The SoCs
+ support multiple XHCI controllers. One PHY device node maps to one XHCI
+ controller.
+
+ RTD1295/RTD1619 SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some
+ controllers.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1319/RTD1619b SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2.
+ XHCI controller#0 -- usb2phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+
+ RTD1319d SoCs USB
+ The USB architecture includes three XHCI controllers.
+ Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0.
+ XHCI controller#0 -- usb2phy -- phy#0
+ |- usb3phy -- phy#0
+ XHCI controller#1 -- usb2phy -- phy#0
+ XHCI controller#2 -- usb2phy -- phy#0
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1295-usb3phy
+ - realtek,rtd1319-usb3phy
+ - realtek,rtd1319d-usb3phy
+ - realtek,rtd1619-usb3phy
+ - realtek,rtd1619b-usb3phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ nvmem-cells:
+ maxItems: 1
+ description: A phandle to the tx lfps swing trim data provided by
+ a nvmem device, if unspecified, default values shall be used.
+
+ nvmem-cell-names:
+ items:
+ - const: usb_u3_tx_lfps_swing_trim
+
+ realtek,amplitude-control-coarse-tuning:
+ description:
+ This adjusts the signal amplitude for normal operation and beacon LFPS.
+ This value is a parameter for coarse tuning.
+ For different boards, if the default value is inappropriate, this
+ property can be assigned to adjust.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 255
+ minimum: 0
+ maximum: 255
+
+ realtek,amplitude-control-fine-tuning:
+ description:
+ This adjusts the signal amplitude for normal operation and beacon LFPS.
+ This value is used for fine-tuning parameters.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 65535
+ minimum: 0
+ maximum: 65535
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@13e10 {
+ compatible = "realtek,rtd1319d-usb3phy";
+ reg = <0x13e10 0x4>;
+ #phy-cells = <0>;
+
+ nvmem-cells = <&otp_usb_u3_tx_lfps_swing_trim>;
+ nvmem-cell-names = "usb_u3_tx_lfps_swing_trim";
+
+ realtek,amplitude-control-coarse-tuning = <0x77>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/renesas,r8a779f0-ether-serdes.yaml b/Documentation/devicetree/bindings/phy/renesas,r8a779f0-ether-serdes.yaml
new file mode 100644
index 000000000000..93ab72874228
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/renesas,r8a779f0-ether-serdes.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/renesas,r8a779f0-ether-serdes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Ethernet SERDES
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+properties:
+ compatible:
+ const: renesas,r8a779f0-ether-serdes
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ '#phy-cells':
+ description: Port number of SERDES.
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - power-domains
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ phy@e6444000 {
+ compatible = "renesas,r8a779f0-ether-serdes";
+ reg = <0xe6444000 0xc00>;
+ clocks = <&cpg CPG_MOD 1506>;
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 1506>;
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/renesas,rcar-gen2-usb-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,rcar-gen2-usb-phy.yaml
new file mode 100644
index 000000000000..afc09f39b02b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/renesas,rcar-gen2-usb-phy.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/renesas,rcar-gen2-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen2 USB PHY
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,usb-phy-r8a7742 # RZ/G1H
+ - renesas,usb-phy-r8a7743 # RZ/G1M
+ - renesas,usb-phy-r8a7744 # RZ/G1N
+ - renesas,usb-phy-r8a7745 # RZ/G1E
+ - renesas,usb-phy-r8a77470 # RZ/G1C
+ - renesas,usb-phy-r8a7790 # R-Car H2
+ - renesas,usb-phy-r8a7791 # R-Car M2-W
+ - renesas,usb-phy-r8a7794 # R-Car E2
+ - const: renesas,rcar-gen2-usb-phy # R-Car Gen2 or RZ/G1
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: usbhs
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ "^usb-phy@[02]$":
+ type: object
+ description: Subnode corresponding to a USB channel.
+
+ properties:
+ reg:
+ description: FIXME RZ/G1C supports channel 0 only
+ enum: [0, 2]
+
+ '#phy-cells':
+ description: |
+ The phandle's argument in the PHY specifier is the USB controller
+ selector for the USB channel.
+ For RZ/G1C:
+ - 0 for EHCI/OHCI
+ - 1 for HS-USB
+ For all other SoCS:
+ - 0 for PCI EHCI/OHCI
+ - 1 for HS-USB (channel 0) or xHCI (channel 2)
+ const: 1
+
+ required:
+ - reg
+ - '#phy-cells'
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - usb-phy@0
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,usb-phy-r8a77470
+then:
+ properties:
+ usb-phy@2: false
+else:
+ required:
+ - usb-phy@2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7790-cpg-mssr.h>
+ #include <dt-bindings/power/r8a7790-sysc.h>
+ usb-phy-controller@e6590100 {
+ compatible = "renesas,usb-phy-r8a7790", "renesas,rcar-gen2-usb-phy";
+ reg = <0xe6590100 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cpg CPG_MOD 704>;
+ clock-names = "usbhs";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 704>;
+
+ usb0: usb-phy@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-phy@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/renesas,rzg3e-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,rzg3e-usb3-phy.yaml
new file mode 100644
index 000000000000..b86dc7a291a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/renesas,rzg3e-usb3-phy.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/renesas,rzg3e-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G3E USB 3.0 PHY
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+properties:
+ compatible:
+ const: renesas,r9a09g047-usb3-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: APB bus clock
+ - description: USB 2.0 PHY reference clock
+ - description: USB 3.0 PHY reference clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: core
+ - const: ref_alt_clk_p
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g047-cpg.h>
+
+ usb-phy@15870000 {
+ compatible = "renesas,r9a09g047-usb3-phy";
+ reg = <0x15870000 0x10000>;
+ clocks = <&cpg CPG_MOD 0xb0>, <&cpg CPG_CORE 13>, <&cpg CPG_CORE 12>;
+ clock-names = "pclk", "core", "ref_alt_clk_p";
+ power-domains = <&cpg>;
+ resets = <&cpg 0xaa>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index f82649a55e91..2bbec8702a1e 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -13,7 +13,10 @@ properties:
compatible:
oneOf:
- items:
- - const: renesas,usb2-phy-r8a77470 # RZ/G1C
+ - enum:
+ - renesas,usb2-phy-r8a77470 # RZ/G1C
+ - renesas,usb2-phy-r9a08g045 # RZ/G3S
+ - renesas,usb2-phy-r9a09g057 # RZ/V2H(P)
- items:
- enum:
@@ -37,6 +40,16 @@ properties:
- renesas,usb2-phy-r9a07g054 # RZ/V2L
- const: renesas,rzg2l-usb2-phy
+ - items:
+ - const: renesas,usb2-phy-r9a09g056 # RZ/V2N
+ - const: renesas,usb2-phy-r9a09g057
+
+ - const: renesas,usb2-phy-r9a09g077 # RZ/T2H
+
+ - items:
+ - const: renesas,usb2-phy-r9a09g087 # RZ/N2H
+ - const: renesas,usb2-phy-r9a09g077
+
reg:
maxItems: 1
@@ -103,11 +116,28 @@ allOf:
properties:
compatible:
contains:
- const: renesas,rzg2l-usb2-phy
+ enum:
+ - renesas,usb2-phy-r9a09g057
+ - renesas,usb2-phy-r9a08g045
+ - renesas,rzg2l-usb2-phy
then:
+ properties:
+ clocks:
+ minItems: 2
required:
- resets
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,usb2-phy-r9a09g077
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ resets: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
new file mode 100644
index 000000000000..58e735b5dd05
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
@@ -0,0 +1,248 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,inno-usb2phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip USB2.0 phy with inno IP block
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,px30-usb2phy
+ - rockchip,rk3036-usb2phy
+ - rockchip,rk3128-usb2phy
+ - rockchip,rk3228-usb2phy
+ - rockchip,rk3308-usb2phy
+ - rockchip,rk3328-usb2phy
+ - rockchip,rk3366-usb2phy
+ - rockchip,rk3399-usb2phy
+ - rockchip,rk3562-usb2phy
+ - rockchip,rk3568-usb2phy
+ - rockchip,rk3576-usb2phy
+ - rockchip,rk3588-usb2phy
+ - rockchip,rv1108-usb2phy
+
+ reg:
+ maxItems: 1
+
+ clock-output-names:
+ description:
+ The usb 480m output clock name.
+
+ "#clock-cells":
+ const: 0
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: phyclk
+ - const: aclk
+ - const: aclk_slv
+
+ assigned-clocks:
+ description:
+ Phandle of the usb 480m clock.
+
+ assigned-clock-parents:
+ description:
+ Parent of the usb 480m clock.
+ Select between usb-phy output 480m and xin24m.
+ Refer to clk/clock-bindings.txt for generic clock consumer properties.
+
+ extcon:
+ description:
+ Phandle to the extcon device providing the cable state for the otg phy.
+
+ interrupts:
+ description: Muxed interrupt for both ports
+ maxItems: 1
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: phy
+ - const: apb
+
+ rockchip,usbgrf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'usb general register files'.
+ When set the driver will request its phandle as one companion-grf
+ for some special SoCs (e.g rv1108).
+
+ host-port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#phy-cells":
+ const: 0
+
+ interrupts:
+ description: host linestate interrupt
+ maxItems: 1
+
+ interrupt-names:
+ const: linestate
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to VBUS.
+ See ./phy-bindings.txt for details.
+
+ required:
+ - "#phy-cells"
+
+ otg-port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#phy-cells":
+ const: 0
+
+ interrupts:
+ minItems: 1
+ maxItems: 3
+
+ interrupt-names:
+ oneOf:
+ - const: linestate
+ - const: otg-mux
+ - items:
+ - const: otg-bvalid
+ - const: otg-id
+ - const: linestate
+
+ phy-supply:
+ description:
+ Phandle to a regulator that provides power to VBUS.
+ See ./phy-bindings.txt for details.
+
+ required:
+ - "#phy-cells"
+
+required:
+ - compatible
+ - reg
+ - clock-output-names
+ - "#clock-cells"
+
+anyOf:
+ - required:
+ - otg-port
+ - required:
+ - host-port
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-usb2phy
+ - rockchip,rk3588-usb2phy
+
+ then:
+ properties:
+ host-port:
+ properties:
+ interrupts: false
+
+ otg-port:
+ properties:
+ interrupts: false
+
+ required:
+ - interrupts
+
+ else:
+ properties:
+ interrupts: false
+
+ host-port:
+ required:
+ - interrupts
+ - interrupt-names
+
+ otg-port:
+ required:
+ - interrupts
+ - interrupt-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-usb2phy
+ - rockchip,rk3036-usb2phy
+ - rockchip,rk3128-usb2phy
+ - rockchip,rk3228-usb2phy
+ - rockchip,rk3308-usb2phy
+ - rockchip,rk3328-usb2phy
+ - rockchip,rk3366-usb2phy
+ - rockchip,rk3399-usb2phy
+ - rockchip,rk3562-usb2phy
+ - rockchip,rk3568-usb2phy
+ - rockchip,rk3588-usb2phy
+ - rockchip,rv1108-usb2phy
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-usb2phy
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ minItems: 3
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ u2phy0: usb2phy@e450 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0xe450 0x10>;
+ clocks = <&cru SCLK_USB2PHY0_REF>;
+ clock-names = "phyclk";
+ clock-output-names = "clk_usbphy0_480m";
+ #clock-cells = <0>;
+
+ u2phy0_host: host-port {
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "linestate";
+ #phy-cells = <0>;
+ };
+
+ u2phy0_otg: otg-port {
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "otg-bvalid", "otg-id", "linestate";
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
new file mode 100644
index 000000000000..d7de8b527c5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,pcie3-phy.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,pcie3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PCIe v3 phy
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3568-pcie3-phy
+ - rockchip,rk3588-pcie3-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ data-lanes:
+ description: which lanes (by position) should be mapped to which
+ controller (value). 0 means lane disabled, higher value means used.
+ (controller-number +1 )
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 16
+ items:
+ minimum: 0
+ maximum: 16
+
+ "#phy-cells":
+ const: 0
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: phy
+
+ phy-supply:
+ description: Single PHY regulator
+
+ rockchip,phy-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the syscon managing the phy "general register files"
+
+ rockchip,pipe-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the syscon managing the pipe "general register files"
+
+ rockchip,rx-common-refclk-mode:
+ description: which lanes (by position) should be configured to run in
+ RX common reference clock mode. 0 means disabled, 1 means enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 16
+ items:
+ minimum: 0
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+ - rockchip,phy-grf
+ - "#phy-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - rockchip,rk3588-pcie3-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: pclk
+ else:
+ properties:
+ clocks:
+ minItems: 3
+
+ clock-names:
+ items:
+ - const: refclk_m
+ - const: refclk_n
+ - const: pclk
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3568-cru.h>
+ pcie30phy: phy@fe8c0000 {
+ compatible = "rockchip,rk3568-pcie3-phy";
+ reg = <0xfe8c0000 0x20000>;
+ #phy-cells = <0>;
+ clocks = <&pmucru CLK_PCIE30PHY_REF_M>,
+ <&pmucru CLK_PCIE30PHY_REF_N>,
+ <&cru PCLK_PCIE30PHY>;
+ clock-names = "refclk_m", "refclk_n", "pclk";
+ resets = <&cru SRST_PCIE30PHY>;
+ reset-names = "phy";
+ rockchip,phy-grf = <&pcie30_phy_grf>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
index 8a3032a3bd73..83e7c825860c 100644
--- a/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip,px30-dsi-dphy.yaml
@@ -18,6 +18,9 @@ properties:
- rockchip,px30-dsi-dphy
- rockchip,rk3128-dsi-dphy
- rockchip,rk3368-dsi-dphy
+ - rockchip,rk3506-dsi-dphy
+ - rockchip,rk3568-dsi-dphy
+ - rockchip,rv1126-dsi-dphy
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3228-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3228-hdmi-phy.yaml
new file mode 100644
index 000000000000..ac15bf857ef9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3228-hdmi-phy.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3228-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip HDMI PHY with Innosilicon IP block
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3228-hdmi-phy
+ - rockchip,rk3328-hdmi-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: sysclk
+ - const: refoclk
+ - const: refpclk
+
+ clock-output-names:
+ description:
+ The hdmiphy output clock name, that gets fed back to the CRU.
+
+ "#clock-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ nvmem-cells:
+ maxItems: 1
+ description: A phandle + nvmem specifier for the cpu-version efuse
+ for adjustment to some frequency settings, depending on cpu-version
+
+ nvmem-cell-names:
+ items:
+ - const: cpu-version
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-output-names
+ - '#clock-cells'
+ - '#phy-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3228-hdmi-phy
+
+ then:
+ properties:
+ interrupts: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3328-hdmi-phy
+
+ then:
+ required:
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+
+ #include <dt-bindings/clock/rk3228-cru.h>
+ hdmi_phy: phy@12030000 {
+ compatible = "rockchip,rk3228-hdmi-phy";
+ reg = <0x12030000 0x10000>;
+ #phy-cells = <0>;
+ clocks = <&cru PCLK_HDMI_PHY>, <&xin24m>, <&cru DCLK_HDMI_PHY>;
+ clock-names = "sysclk", "refoclk", "refpclk";
+ #clock-cells = <0>;
+
+ clock-output-names = "hdmi_phy";
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml
new file mode 100644
index 000000000000..2538235c5ac6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3288-dp-phy.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3288-dp-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip specific extensions to the Analogix Display Port PHY
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3288-dp-phy
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: 24m
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3288-cru.h>
+ edp-phy {
+ compatible = "rockchip,rk3288-dp-phy";
+ clocks = <&cru SCLK_EDP_24M>;
+ clock-names = "24m";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3399-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3399-emmc-phy.yaml
new file mode 100644
index 000000000000..3e3729b1c799
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3399-emmc-phy.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3399-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip EMMC PHY
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-emmc-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: emmcclk
+
+ drive-impedance-ohm:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Specifies the drive impedance in Ohm.
+ enum: [33, 40, 50, 66, 100]
+ default: 50
+
+ rockchip,enable-strobe-pulldown:
+ type: boolean
+ description: |
+ Enable internal pull-down for the strobe
+ line. If not set, pull-down is not used.
+
+ rockchip,output-tapdelay-select:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Specifies the phyctrl_otapdlysec register.
+ default: 0x4
+ maximum: 0xf
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@f780 {
+ compatible = "rockchip,rk3399-emmc-phy";
+ reg = <0xf780 0x20>;
+ clocks = <&sdhci>;
+ clock-names = "emmcclk";
+ drive-impedance-ohm = <50>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3399-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3399-pcie-phy.yaml
new file mode 100644
index 000000000000..f46f065e5dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3399-pcie-phy.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3399-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3399 PCIE PHY
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-pcie-phy
+
+ '#phy-cells':
+ oneOf:
+ - const: 0
+ deprecated: true
+ - const: 1
+ description: One lane per phy mode
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: refclk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: phy
+
+required:
+ - compatible
+ - '#phy-cells'
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3399-typec-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3399-typec-phy.yaml
new file mode 100644
index 000000000000..91c011f68cd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3399-typec-phy.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3399-typec-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Type-C PHY
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-typec-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: tcpdcore
+ - const: tcpdphy-ref
+
+ extcon: true
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 3
+
+ reset-names:
+ items:
+ - const: uphy
+ - const: uphy-pipe
+ - const: uphy-tcphy
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the "general register files" (GRF).
+
+ dp-port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#phy-cells':
+ const: 0
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to USB Type-C connector
+
+ required:
+ - '#phy-cells'
+
+ usb3-port:
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#phy-cells':
+ const: 0
+
+ orientation-switch: true
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to USB Type-C connector SS port
+
+ required:
+ - '#phy-cells'
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - dp-port
+ - usb3-port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+
+ phy@ff7c0000 {
+ compatible = "rockchip,rk3399-typec-phy";
+ reg = <0xff7c0000 0x40000>;
+ rockchip,grf = <&grf>;
+ extcon = <&fusb0>;
+ clocks = <&cru SCLK_UPHY0_TCPDCORE>,
+ <&cru SCLK_UPHY0_TCPDPHY_REF>;
+ clock-names = "tcpdcore", "tcpdphy-ref";
+ resets = <&cru SRST_UPHY0>,
+ <&cru SRST_UPHY0_PIPE_L00>,
+ <&cru SRST_P_UPHY0_TCPHY>;
+ reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+
+ dp-port {
+ #phy-cells = <0>;
+ };
+
+ usb3-port {
+ #phy-cells = <0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml
new file mode 100644
index 000000000000..7a307f45cdec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3588-hdptx-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC HDMI/eDP Transmitter Combo PHY
+
+maintainers:
+ - Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - rockchip,rk3588-hdptx-phy
+ - items:
+ - enum:
+ - rockchip,rk3576-hdptx-phy
+ - const: rockchip,rk3588-hdptx-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Reference clock
+ - description: APB clock
+
+ clock-names:
+ items:
+ - const: ref
+ - const: apb
+
+ "#clock-cells":
+ const: 0
+
+ "#phy-cells":
+ const: 0
+
+ resets:
+ minItems: 4
+ maxItems: 7
+
+ reset-names:
+ minItems: 4
+ maxItems: 7
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Some PHY related data is accessed through GRF regs.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#phy-cells"
+ - resets
+ - reset-names
+ - rockchip,grf
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-hdptx-phy
+ then:
+ properties:
+ resets:
+ minItems: 4
+ maxItems: 4
+ reset-names:
+ items:
+ - const: apb
+ - const: init
+ - const: cmn
+ - const: lane
+ else:
+ properties:
+ resets:
+ minItems: 7
+ maxItems: 7
+ reset-names:
+ items:
+ - const: phy
+ - const: apb
+ - const: init
+ - const: cmn
+ - const: lane
+ - const: ropll
+ - const: lcpll
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ phy@fed60000 {
+ compatible = "rockchip,rk3588-hdptx-phy";
+ reg = <0x0 0xfed60000 0x0 0x2000>;
+ clocks = <&cru CLK_USB2PHY_HDPTXRXPHY_REF>, <&cru PCLK_HDPTX0>;
+ clock-names = "ref", "apb";
+ #phy-cells = <0>;
+ resets = <&cru SRST_HDPTX0>, <&cru SRST_P_HDPTX0>,
+ <&cru SRST_HDPTX0_INIT>, <&cru SRST_HDPTX0_CMN>,
+ <&cru SRST_HDPTX0_LANE>, <&cru SRST_HDPTX0_ROPLL>,
+ <&cru SRST_HDPTX0_LCPLL>;
+ reset-names = "phy", "apb", "init", "cmn", "lane", "ropll", "lcpll";
+ rockchip,grf = <&hdptxphy_grf>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml
new file mode 100644
index 000000000000..c8ff5ba22a86
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/rockchip,rk3588-mipi-dcphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip MIPI D-/C-PHY with Samsung IP block
+
+maintainers:
+ - Guochun Huang <hero.huang@rock-chips.com>
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3576-mipi-dcphy
+ - rockchip,rk3588-mipi-dcphy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 1
+ description: |
+ Argument is mode to operate in. Supported modes are:
+ - PHY_TYPE_DPHY
+ - PHY_TYPE_CPHY
+ See include/dt-bindings/phy/phy.h for constants.
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: ref
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: m_phy
+ - const: apb
+ - const: grf
+ - const: s_phy
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the 'mipi dcphy general register files'.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ phy@feda0000 {
+ compatible = "rockchip,rk3588-mipi-dcphy";
+ reg = <0x0 0xfeda0000 0x0 0x10000>;
+ clocks = <&cru PCLK_MIPI_DCPHY0>,
+ <&cru CLK_USBDPPHY_MIPIDCPPHY_REF>;
+ clock-names = "pclk", "ref";
+ resets = <&cru SRST_M_MIPI_DCPHY0>,
+ <&cru SRST_P_MIPI_DCPHY0>,
+ <&cru SRST_P_MIPI_DCPHY0_GRF>,
+ <&cru SRST_S_MIPI_DCPHY0>;
+ reset-names = "m_phy", "apb", "grf", "s_phy";
+ rockchip,grf = <&mipidcphy0_grf>;
+ #phy-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
deleted file mode 100644
index e3b4809fbe82..000000000000
--- a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Rockchip specific extensions to the Analogix Display Port PHY
-------------------------------------
-
-Required properties:
-- compatible : should be one of the following supported values:
- - "rockchip.rk3288-dp-phy"
-- clocks: from common clock binding: handle to dp clock.
- of memory mapped region.
-- clock-names: from common clock binding:
- Required elements: "24m"
-- #phy-cells : from the generic PHY bindings, must be 0;
-
-Example:
-
-grf: syscon@ff770000 {
- compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
-
-...
-
- edp_phy: edp-phy {
- compatible = "rockchip,rk3288-dp-phy";
- clocks = <&cru SCLK_EDP_24M>;
- clock-names = "24m";
- #phy-cells = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
deleted file mode 100644
index 57d28c0d5696..000000000000
--- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Rockchip EMMC PHY
------------------------
-
-Required properties:
- - compatible: rockchip,rk3399-emmc-phy
- - #phy-cells: must be 0
- - reg: PHY register address offset and length in "general
- register files"
-
-Optional properties:
- - clock-names: Should contain "emmcclk". Although this is listed as optional
- (because most boards can get basic functionality without having
- access to it), it is strongly suggested.
- See ../clock/clock-bindings.txt for details.
- - clocks: Should have a phandle to the card clock exported by the SDHCI driver.
- - drive-impedance-ohm: Specifies the drive impedance in Ohm.
- Possible values are 33, 40, 50, 66 and 100.
- If not set, the default value of 50 will be applied.
- - rockchip,enable-strobe-pulldown: Enable internal pull-down for the strobe
- line. If not set, pull-down is not used.
- - rockchip,output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
- If not set, the register defaults to 0x4.
- Maximum value 0xf.
-
-Example:
-
-
-grf: syscon@ff770000 {
- compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
-
-...
-
- emmcphy: phy@f780 {
- compatible = "rockchip,rk3399-emmc-phy";
- reg = <0xf780 0x20>;
- clocks = <&sdhci>;
- clock-names = "emmcclk";
- drive-impedance-ohm = <50>;
- #phy-cells = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index bb4a2e4b8ab0..03950b3cad08 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/phy/rockchip-inno-csi-dphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip SoC MIPI RX0 D-PHY Device Tree Bindings
+title: Rockchip SoC MIPI RX0 D-PHY
maintainers:
- Heiko Stuebner <heiko@sntech.de>
description: |
- The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP wich
+ The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP which
connects to the ISP1 (Image Signal Processing unit v1.0) for CSI cameras.
properties:
@@ -20,6 +20,8 @@ properties:
- rockchip,rk1808-csi-dphy
- rockchip,rk3326-csi-dphy
- rockchip,rk3368-csi-dphy
+ - rockchip,rk3568-csi-dphy
+ - rockchip,rk3588-csi-dphy
reg:
maxItems: 1
@@ -39,11 +41,15 @@ properties:
resets:
items:
- - description: exclusive PHY reset line
+ - description: APB reset line
+ - description: PHY reset line
+ minItems: 1
reset-names:
items:
- const: apb
+ - const: phy
+ minItems: 1
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -56,11 +62,48 @@ required:
- clocks
- clock-names
- '#phy-cells'
- - power-domains
- resets
- reset-names
- rockchip,grf
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-csi-dphy
+ - rockchip,rk1808-csi-dphy
+ - rockchip,rk3326-csi-dphy
+ - rockchip,rk3368-csi-dphy
+ then:
+ required:
+ - power-domains
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-csi-dphy
+ - rockchip,rk1808-csi-dphy
+ - rockchip,rk3326-csi-dphy
+ - rockchip,rk3368-csi-dphy
+ - rockchip,rk3568-csi-dphy
+ then:
+ properties:
+ resets:
+ maxItems: 1
+
+ reset-names:
+ maxItems: 1
+ else:
+ properties:
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
+
additionalProperties: false
examples:
@@ -77,3 +120,22 @@ examples:
reset-names = "apb";
rockchip,grf = <&grf>;
};
+ - |
+ #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+ #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ phy@fedc0000 {
+ compatible = "rockchip,rk3588-csi-dphy";
+ reg = <0x0 0xfedc0000 0x0 0x8000>;
+ clocks = <&cru PCLK_CSIPHY0>;
+ clock-names = "pclk";
+ #phy-cells = <0>;
+ resets = <&cru SRST_P_CSIPHY0>, <&cru SRST_CSIPHY0>;
+ reset-names = "apb", "phy";
+ rockchip,grf = <&csidphy0_grf>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml b/Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml
index 7d888d358823..5114e99b0035 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/rockchip-mipi-dphy-rx0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip SoC MIPI RX0 D-PHY Device Tree Bindings
+title: Rockchip SoC MIPI RX0 D-PHY
maintainers:
- Helen Koike <helen.koike@collabora.com>
diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
deleted file mode 100644
index b496042f1f44..000000000000
--- a/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Rockchip PCIE PHY
------------------------
-
-Required properties:
- - compatible: rockchip,rk3399-pcie-phy
- - clocks: Must contain an entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must be "refclk"
- - resets: Must contain an entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must be "phy"
-
-Required properties for legacy PHY mode (deprecated):
- - #phy-cells: must be 0
-
-Required properties for per-lane PHY mode (preferred):
- - #phy-cells: must be 1
-
-Example:
-
-grf: syscon@ff770000 {
- compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
-
- ...
-
- pcie_phy: pcie-phy {
- compatible = "rockchip,rk3399-pcie-phy";
- #phy-cells = <0>;
- clocks = <&cru SCLK_PCIEPHY_REF>;
- clock-names = "refclk";
- resets = <&cru SRST_PCIEPHY>;
- reset-names = "phy";
- };
-};
diff --git a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml
index b03b2f00cc5b..3bee3f8733f7 100644
--- a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml
@@ -22,13 +22,13 @@ properties:
samsung,pmu-syscon:
$ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
description:
- Phandle to PMU system controller interface.
+ Phandle to PMU system controller interface (if not a child of PMU).
required:
- compatible
- "#phy-cells"
- - samsung,pmu-syscon
additionalProperties: false
@@ -36,6 +36,5 @@ examples:
- |
phy {
compatible = "samsung,exynos5420-dp-video-phy";
- samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
index ac0af40be52d..41df8bb08ff7 100644
--- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/samsung,exynos-pcie-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Samsung SoC series PCIe PHY Device Tree Bindings
+title: Samsung SoC series PCIe PHY
maintainers:
- Marek Szyprowski <m.szyprowski@samsung.com>
@@ -21,12 +21,12 @@ properties:
maxItems: 1
samsung,pmu-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle for PMU system controller interface, used to
control PMU registers bits for PCIe PHY
samsung,fsys-sysreg:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle for FSYS sysreg interface, used to control
sysreg registers bits for PCIe PHY
diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos2200-eusb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos2200-eusb2-phy.yaml
new file mode 100644
index 000000000000..5e7e1bc2e39a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos2200-eusb2-phy.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/samsung,exynos2200-eusb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos2200 eUSB2 phy controller
+
+maintainers:
+ - Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+
+description:
+ Samsung Exynos2200 eUSB2 phy, based on Synopsys eUSB2 IP block, supports
+ LS/FS/HS usb connectivity.
+
+properties:
+ compatible:
+ enum:
+ - samsung,exynos2200-eusb2-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Reference clock
+ - description: Bus (APB) clock
+ - description: Control clock
+
+ clock-names:
+ items:
+ - const: ref
+ - const: bus
+ - const: ctrl
+
+ resets:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+ description:
+ Phandle to eUSB2 to USB 2.0 repeater
+
+ vdd-supply:
+ description:
+ Phandle to 0.88V regulator supply to PHY digital circuit.
+
+ vdda12-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+ - vdd-supply
+ - vdda12-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ usb_hsphy: phy@10ab0000 {
+ compatible = "samsung,exynos2200-eusb2-phy";
+ reg = <0x10ab0000 0x10000>;
+ #phy-cells = <0>;
+
+ clocks = <&cmu_hsi0 7>,
+ <&cmu_hsi0 5>,
+ <&cmu_hsi0 8>;
+ clock-names = "ref", "bus", "ctrl";
+
+ vdd-supply = <&vreg_0p88>;
+ vdda12-supply = <&vreg_1p2>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
index 415440aaad89..16967ef8e9ec 100644
--- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
@@ -29,33 +29,38 @@ properties:
- samsung,s5pv210-mipi-video-phy
- samsung,exynos5420-mipi-video-phy
- samsung,exynos5433-mipi-video-phy
+ - samsung,exynos7870-mipi-video-phy
"#phy-cells":
const: 1
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
description:
Phandle to PMU system controller interface, valid only for
- samsung,s5pv210-mipi-video-phy and samsung,exynos5420-mipi-video-phy.
+ samsung,s5pv210-mipi-video-phy and samsung,exynos5420-mipi-video-phy (if
+ not a child of PMU).
samsung,pmu-syscon:
$ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
description:
Phandle to PMU system controller interface, valid for
- samsung,exynos5433-mipi-video-phy.
+ samsung,exynos5433-mipi-video-phy and samsung,exynos7870-mipi-video-phy
+ (if not a child of PMU).
samsung,disp-sysreg:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to DISP system controller interface, valid for
- samsung,exynos5433-mipi-video-phy.
+ samsung,exynos5433-mipi-video-phy and samsung,exynos7870-mipi-video-phy.
samsung,cam0-sysreg:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to CAM0 system controller interface, valid for
- samsung,exynos5433-mipi-video-phy.
+ samsung,exynos5433-mipi-video-phy and samsung,exynos7870-mipi-video-phy.
samsung,cam1-sysreg:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -81,17 +86,33 @@ allOf:
samsung,disp-sysreg: false
samsung,cam0-sysreg: false
samsung,cam1-sysreg: false
- required:
- - syscon
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos5433-mipi-video-phy
+ then:
properties:
syscon: false
required:
- - samsung,pmu-syscon
- samsung,disp-sysreg
- samsung,cam0-sysreg
- samsung,cam1-sysreg
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-mipi-video-phy
+ then:
+ properties:
+ syscon: false
+ samsung,cam1-sysreg: false
+ required:
+ - samsung,disp-sysreg
+ - samsung,cam0-sysreg
+
additionalProperties: false
examples:
@@ -99,7 +120,6 @@ examples:
phy {
compatible = "samsung,exynos5433-mipi-video-phy";
#phy-cells = <1>;
- samsung,pmu-syscon = <&pmu_system_controller>;
samsung,cam0-sysreg = <&syscon_cam0>;
samsung,cam1-sysreg = <&syscon_cam1>;
samsung,disp-sysreg = <&syscon_disp>;
diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
index 8da99461e817..d70ffeb6e824 100644
--- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/samsung,ufs-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Samsung SoC series UFS PHY Device Tree Bindings
+title: Samsung SoC series UFS PHY
maintainers:
- Alim Akhtar <alim.akhtar@samsung.com>
@@ -15,8 +15,10 @@ properties:
compatible:
enum:
+ - google,gs101-ufs-phy
- samsung,exynos7-ufs-phy
- samsung,exynosautov9-ufs-phy
+ - samsung,exynosautov920-ufs-phy
- tesla,fsd-ufs-phy
reg:
@@ -27,21 +29,15 @@ properties:
- const: phy-pma
clocks:
- items:
- - description: PLL reference clock
- - description: symbol clock for input symbol ( rx0-ch0 symbol clock)
- - description: symbol clock for input symbol ( rx1-ch1 symbol clock)
- - description: symbol clock for output symbol ( tx0 symbol clock)
+ minItems: 1
+ maxItems: 4
clock-names:
- items:
- - const: ref_clk
- - const: rx1_symbol_clk
- - const: rx0_symbol_clk
- - const: tx0_symbol_clk
+ minItems: 1
+ maxItems: 4
samsung,pmu-syscon:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
items:
minItems: 1
@@ -62,6 +58,39 @@ required:
- clock-names
- samsung,pmu-syscon
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7-ufs-phy
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: PLL reference clock
+ - description: symbol clock for input symbol (rx0-ch0 symbol clock)
+ - description: symbol clock for input symbol (rx1-ch1 symbol clock)
+ - description: symbol clock for output symbol (tx0 symbol clock)
+
+ clock-names:
+ items:
+ - const: ref_clk
+ - const: rx1_symbol_clk
+ - const: rx0_symbol_clk
+ - const: tx0_symbol_clk
+
+ else:
+ properties:
+ clocks:
+ items:
+ - description: PLL reference clock
+
+ clock-names:
+ items:
+ - const: ref_clk
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
index 5ba55f9f20cc..ea1135c91fb7 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
@@ -25,30 +25,43 @@ description: |
properties:
compatible:
enum:
+ - google,gs101-usb31drd-phy
+ - samsung,exynos2200-usb32drd-phy
- samsung,exynos5250-usbdrd-phy
- samsung,exynos5420-usbdrd-phy
- samsung,exynos5433-usbdrd-phy
- samsung,exynos7-usbdrd-phy
+ - samsung,exynos7870-usbdrd-phy
+ - samsung,exynos850-usbdrd-phy
+ - samsung,exynos990-usbdrd-phy
clocks:
- minItems: 2
+ minItems: 1
maxItems: 5
clock-names:
- minItems: 2
+ minItems: 1
maxItems: 5
description: |
- At least two clocks::
+ Typically two clocks:
- Main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), used
for register access.
- PHY reference clock (usually crystal clock), used for PHY operations,
associated by phy name. It is used to determine bit values for clock
settings register. For Exynos5420 this is given as 'sclk_usbphy30'
- in the CMU.
+ in the CMU. It's not needed for Exynos2200.
"#phy-cells":
const: 1
+ phys:
+ maxItems: 1
+ description:
+ USBDRD-underlying high-speed PHY
+
+ phy-names:
+ const: hs
+
port:
$ref: /schemas/graph.yaml#/properties/port
description:
@@ -56,7 +69,15 @@ properties:
the OF graph bindings specified.
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: phy
+ - const: pcs
+ - const: pma
samsung,pmu-syscon:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -71,6 +92,24 @@ properties:
description:
VBUS Boost 5V power source.
+ pll-supply:
+ description: Power supply for the USB PLL.
+
+ dvdd-usb20-supply:
+ description: DVDD power supply for the USB 2.0 phy.
+
+ vddh-usb20-supply:
+ description: VDDh power supply for the USB 2.0 phy.
+
+ vdd33-usb20-supply:
+ description: 3.3V power supply for the USB 2.0 phy.
+
+ vdda-usbdp-supply:
+ description: VDDa power supply for the USB DP phy.
+
+ vddh-usbdp-supply:
+ description: VDDh power supply for the USB DP phy.
+
required:
- compatible
- clocks
@@ -84,6 +123,71 @@ allOf:
properties:
compatible:
contains:
+ const: google,gs101-usb31drd-phy
+ then:
+ allOf:
+ - $ref: /schemas/usb/usb-switch.yaml#
+ - $ref: /schemas/usb/usb-switch-ports.yaml#
+
+ properties:
+ clocks:
+ items:
+ - description: Gate of main PHY clock
+ - description: Gate of PHY reference clock
+ - description: Gate of control interface AXI clock
+ - description: Gate of control interface APB clock
+ - description: Gate of SCL APB clock
+
+ clock-names:
+ items:
+ - const: phy
+ - const: ref
+ - const: ctrl_aclk
+ - const: ctrl_pclk
+ - const: scl_pclk
+
+ reg:
+ minItems: 3
+
+ reg-names:
+ minItems: 3
+
+ required:
+ - reg-names
+ - orientation-switch
+ - port
+ - pll-supply
+ - dvdd-usb20-supply
+ - vddh-usb20-supply
+ - vdd33-usb20-supply
+ - vdda-usbdp-supply
+ - vddh-usbdp-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos2200-usb32drd-phy
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: phy
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
+ required:
+ - phys
+ - phy-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
enum:
- samsung,exynos5433-usbdrd-phy
- samsung,exynos7-usbdrd-phy
@@ -92,6 +196,7 @@ allOf:
clocks:
minItems: 5
maxItems: 5
+
clock-names:
items:
- const: phy
@@ -99,17 +204,41 @@ allOf:
- const: phy_utmi
- const: phy_pipe
- const: itp
- else:
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5250-usbdrd-phy
+ - samsung,exynos5420-usbdrd-phy
+ - samsung,exynos7870-usbdrd-phy
+ - samsung,exynos850-usbdrd-phy
+ - samsung,exynos990-usbdrd-phy
+ then:
properties:
clocks:
minItems: 2
maxItems: 2
+
clock-names:
items:
- const: phy
- const: ref
-additionalProperties: false
+ reg:
+ maxItems: 1
+
+ reg-names:
+ maxItems: 1
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
index a3cd45acea28..e34b875a1bb8 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml
@@ -30,13 +30,17 @@ properties:
minItems: 1
maxItems: 2
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 6
resets:
minItems: 2
maxItems: 6
- reset-names: true
+ reset-names:
+ minItems: 2
+ maxItems: 6
allOf:
- if:
@@ -117,20 +121,12 @@ additionalProperties: false
examples:
- |
- ahci-glue@65700000 {
- compatible = "socionext,uniphier-pxs3-ahci-glue",
- "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65700000 0x100>;
-
- ahci_phy: phy@10 {
- compatible = "socionext,uniphier-pxs3-ahci-phy";
- reg = <0x10 0x10>;
- #phy-cells = <0>;
- clock-names = "link", "phy";
- clocks = <&sys_clk 28>, <&sys_clk 30>;
- reset-names = "link", "phy";
- resets = <&sys_rst 28>, <&sys_rst 30>;
- };
+ ahci_phy: phy@10 {
+ compatible = "socionext,uniphier-pxs3-ahci-phy";
+ reg = <0x10 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 28>, <&sys_clk 30>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 28>, <&sys_rst 30>;
};
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
index b3ed2f74a414..9fc0e87c508e 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml
@@ -31,13 +31,17 @@ properties:
minItems: 1
maxItems: 2
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 2
resets:
minItems: 1
maxItems: 2
- reset-names: true
+ reset-names:
+ minItems: 1
+ maxItems: 2
socionext,syscon:
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
index 63dab914a48d..19522c54f448 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb2-phy.yaml
@@ -61,28 +61,23 @@ examples:
- |
// The UniPhier usb2-phy should be a subnode of a "syscon" compatible node.
- soc-glue@5f800000 {
- compatible = "socionext,uniphier-ld11-soc-glue", "simple-mfd", "syscon";
- reg = <0x5f800000 0x2000>;
-
- usb-controller {
- compatible = "socionext,uniphier-ld11-usb2-phy";
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb_phy0: phy@0 {
- reg = <0>;
- #phy-cells = <0>;
- };
-
- usb_phy1: phy@1 {
- reg = <1>;
- #phy-cells = <0>;
- };
-
- usb_phy2: phy@2 {
- reg = <2>;
- #phy-cells = <0>;
- };
+ usb-hub {
+ compatible = "socionext,uniphier-ld11-usb2-phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ usb_phy2: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
index 21e4414eea60..25c4159f86e4 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml
@@ -34,12 +34,15 @@ properties:
minItems: 2
maxItems: 3
- clock-names: true
+ clock-names:
+ minItems: 2
+ maxItems: 3
resets:
maxItems: 2
- reset-names: true
+ reset-names:
+ maxItems: 2
vbus-supply:
description: A phandle to the regulator for USB VBUS
@@ -146,22 +149,15 @@ additionalProperties: false
examples:
- |
- usb-glue@65b00000 {
- compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_hsphy0: hs-phy@200 {
- compatible = "socionext,uniphier-ld20-usb3-hsphy";
- reg = <0x200 0x10>;
- #phy-cells = <0>;
- clock-names = "link", "phy";
- clocks = <&sys_clk 14>, <&sys_clk 16>;
- reset-names = "link", "phy";
- resets = <&sys_rst 14>, <&sys_rst 16>;
- vbus-supply = <&usb_vbus0>;
- nvmem-cell-names = "rterm", "sel_t", "hs_i";
- nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, <&usb_hs_i0>;
- };
+ usb_hsphy0: phy@200 {
+ compatible = "socionext,uniphier-ld20-usb3-hsphy";
+ reg = <0x200 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 16>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 16>;
+ vbus-supply = <&usb_vbus0>;
+ nvmem-cell-names = "rterm", "sel_t", "hs_i";
+ nvmem-cells = <&usb_rterm0>, <&usb_sel_t0>, <&usb_hs_i0>;
};
diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
index 4c26d2d2303d..1f663e9901da 100644
--- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml
@@ -35,12 +35,15 @@ properties:
minItems: 2
maxItems: 3
- clock-names: true
+ clock-names:
+ minItems: 2
+ maxItems: 3
resets:
maxItems: 2
- reset-names: true
+ reset-names:
+ maxItems: 2
vbus-supply:
description: A phandle to the regulator for USB VBUS, only for USB host
@@ -131,21 +134,13 @@ additionalProperties: false
examples:
- |
- usb-glue@65b00000 {
- compatible = "socionext,uniphier-ld20-dwc3-glue",
- "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_ssphy0: ss-phy@300 {
- compatible = "socionext,uniphier-ld20-usb3-ssphy";
- reg = <0x300 0x10>;
- #phy-cells = <0>;
- clock-names = "link", "phy";
- clocks = <&sys_clk 14>, <&sys_clk 16>;
- reset-names = "link", "phy";
- resets = <&sys_rst 14>, <&sys_rst 16>;
- vbus-supply = <&usb_vbus0>;
- };
+ usb_ssphy0: phy@300 {
+ compatible = "socionext,uniphier-ld20-usb3-ssphy";
+ reg = <0x300 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 16>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 16>;
+ vbus-supply = <&usb_vbus0>;
};
diff --git a/Documentation/devicetree/bindings/phy/sophgo,cv1800b-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/sophgo,cv1800b-usb2-phy.yaml
new file mode 100644
index 000000000000..2ff8f85d0282
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sophgo,cv1800b-usb2-phy.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/sophgo,cv1800b-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV18XX/SG200X USB 2.0 PHY
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+properties:
+ compatible:
+ const: sophgo,cv1800b-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: PHY app clock
+ - description: PHY stb clock
+ - description: PHY lpm clock
+
+ clock-names:
+ items:
+ - const: app
+ - const: stb
+ - const: lpm
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@48 {
+ compatible = "sophgo,cv1800b-usb2-phy";
+ reg = <0x48 0x4>;
+ #phy-cells = <0>;
+ clocks = <&clk 93>, <&clk 94>, <&clk 95>;
+ clock-names = "app", "stb", "lpm";
+ resets = <&rst 58>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/st,spear1310-miphy.yaml b/Documentation/devicetree/bindings/phy/st,spear1310-miphy.yaml
new file mode 100644
index 000000000000..32f81615ddad
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,spear1310-miphy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,spear1310-miphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST SPEAr miphy
+
+maintainers:
+ - Pratyush Anand <pratyush.anand@gmail.com>
+
+description:
+ ST Microelectronics SPEAr miphy is a phy controller supporting PCIe and SATA.
+
+properties:
+ compatible:
+ enum:
+ - st,spear1310-miphy
+ - st,spear1340-miphy
+
+ reg:
+ maxItems: 1
+
+ misc:
+ description: Phandle for the syscon node to access misc registers.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ '#phy-cells':
+ description: >
+ Cell[0] indicates interface type: 0 = SATA, 1 = PCIe.
+ const: 1
+
+ phy-id:
+ description: Instance id of the phy. Required when multiple PHYs are present.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - misc
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ miphy@1000 {
+ compatible = "st,spear1310-miphy";
+ reg = <0x1000 0x100>;
+ misc = <&syscon>;
+ #phy-cells = <1>;
+ phy-id = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/st,stih407-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/st,stih407-usb2-phy.yaml
new file mode 100644
index 000000000000..e45cdd98aab2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,stih407-usb2-phy.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,stih407-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STiH407 USB PHY controller
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+description:
+ The USB picoPHY device is the PHY for both USB2 and USB3 host controllers
+ (when controlling usb2/1.1 devices) available on STiH407 SoC family from
+ STMicroelectronics.
+
+properties:
+ compatible:
+ const: st,stih407-usb2-phy
+
+ st,syscfg:
+ description: Phandle to the syscfg bank
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to syscfg
+ - description: phyparam register offset
+ - description: phyctrl register offset
+
+ resets:
+ items:
+ - description: Phandle and reset specifier pair for the whole phy.
+ - description: Phandle and reset specifier pair for the port.
+
+ reset-names:
+ items:
+ - const: global
+ - const: port
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - st,syscfg
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/stih407-resets.h>
+ usb-phy {
+ compatible = "st,stih407-usb2-phy";
+ #phy-cells = <0>;
+ st,syscfg = <&syscfg_core 0x100 0xf4>;
+ resets = <&softreset STIH407_PICOPHY_SOFTRESET>,
+ <&picophyreset STIH407_PICOPHY0_RESET>;
+ reset-names = "global", "port";
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
new file mode 100644
index 000000000000..a2e82c0bb56b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/st,stm32mp25-combophy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32MP25 USB3/PCIe COMBOPHY
+
+maintainers:
+ - Christian Bruel <christian.bruel@foss.st.com>
+
+description:
+ Single lane PHY shared (exclusive) between the USB3 and PCIe controllers.
+ Supports 5Gbit/s for USB3 and PCIe gen2 or 2.5Gbit/s for PCIe gen1.
+
+properties:
+ compatible:
+ const: st,stm32mp25-combophy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 1
+
+ clocks:
+ minItems: 2
+ items:
+ - description: apb Bus clock mandatory to access registers.
+ - description: ker Internal RCC reference clock for USB3 or PCIe
+ - description: pad Optional on board clock input for PCIe only. Typically an
+ external 100Mhz oscillator wired on dedicated CLKIN pad. Used as reference
+ clock input instead of the ker
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: apb
+ - const: ker
+ - const: pad
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: phy
+
+ power-domains:
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+ description: interrupt used for wakeup
+
+ access-controllers:
+ maxItems: 1
+ description: Phandle to the rifsc device to check access right.
+
+ st,ssc-on:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ A property whose presence indicates that the Spread Spectrum Clocking is active.
+
+ st,rx-equalizer:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ default: 2
+ description:
+ A 3 bit value to tune the RX fixed equalizer setting for optimal eye compliance
+
+ st,output-micro-ohms:
+ minimum: 3999000
+ maximum: 6090000
+ default: 4968000
+ description:
+ A value property to tune the Single Ended Output Impedance, simulations results
+ at 25C for a VDDP=0.8V. The hardware accepts discrete values in this range.
+
+ st,output-vswing-microvolt:
+ minimum: 442000
+ maximum: 803000
+ default: 803000
+ description:
+ A value property in microvolt to tune the Single Ended Output Voltage Swing to change the
+ Vlo, Vhi for a VDDP = 0.8V. The hardware accepts discrete values in this range.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+ phy@480c0000 {
+ compatible = "st,stm32mp25-combophy";
+ reg = <0x480c0000 0x1000>;
+ #phy-cells = <1>;
+ clocks = <&rcc CK_BUS_USB3PCIEPHY>, <&rcc CK_KER_USB3PCIEPHY>;
+ clock-names = "apb", "ker";
+ resets = <&rcc USB3PCIEPHY_R>;
+ reset-names = "phy";
+ access-controllers = <&rifsc 67>;
+ power-domains = <&CLUSTER_PD>;
+ wakeup-source;
+ interrupts-extended = <&exti1 45 IRQ_TYPE_EDGE_FALLING>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/st-spear-miphy.txt b/Documentation/devicetree/bindings/phy/st-spear-miphy.txt
deleted file mode 100644
index 2a6bfdcc09b3..000000000000
--- a/Documentation/devicetree/bindings/phy/st-spear-miphy.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-ST SPEAr miphy DT details
-=========================
-
-ST Microelectronics SPEAr miphy is a phy controller supporting PCIe and SATA.
-
-Required properties:
-- compatible : should be "st,spear1310-miphy" or "st,spear1340-miphy"
-- reg : offset and length of the PHY register set.
-- misc: phandle for the syscon node to access misc registers
-- #phy-cells : from the generic PHY bindings, must be 1.
- - cell[1]: 0 if phy used for SATA, 1 for PCIe.
-
-Optional properties:
-- phy-id: Instance id of the phy. Only required when there are multiple phys
- present on a implementation.
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml
new file mode 100644
index 000000000000..7224cde6fce0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-rx.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/starfive,jh7110-dphy-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive SoC JH7110 MIPI D-PHY Rx Controller
+
+maintainers:
+ - Jack Zhu <jack.zhu@starfivetech.com>
+ - Changhuang Liang <changhuang.liang@starfivetech.com>
+
+description:
+ StarFive SoCs contain a MIPI CSI D-PHY based on M31 IP, used to
+ transfer CSI camera data.
+
+properties:
+ compatible:
+ const: starfive,jh7110-dphy-rx
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: config clock
+ - description: reference clock
+ - description: escape mode transmit clock
+
+ clock-names:
+ items:
+ - const: cfg
+ - const: ref
+ - const: tx
+
+ resets:
+ items:
+ - description: DPHY_HW reset
+ - description: DPHY_B09_ALWAYS_ON reset
+
+ power-domains:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@19820000 {
+ compatible = "starfive,jh7110-dphy-rx";
+ reg = <0x19820000 0x10000>;
+ clocks = <&ispcrg 3>,
+ <&ispcrg 4>,
+ <&ispcrg 5>;
+ clock-names = "cfg", "ref", "tx";
+ resets = <&ispcrg 2>,
+ <&ispcrg 3>;
+ power-domains = <&aon_syscon 1>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-tx.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-tx.yaml
new file mode 100644
index 000000000000..4a06a2642b4a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-dphy-tx.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/starfive,jh7110-dphy-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Starfive SoC MIPI D-PHY Tx Controller
+
+maintainers:
+ - Keith Zhao <keith.zhao@starfivetech.com>
+ - Shengyang Chen <shengyang.chen@starfivetech.com>
+
+description:
+ The Starfive SoC uses the MIPI DSI D-PHY based on M31 IP to transfer
+ DSI data.
+
+properties:
+ compatible:
+ const: starfive,jh7110-dphy-tx
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: txesc
+
+ resets:
+ items:
+ - description: MIPITX_DPHY_SYS reset
+
+ reset-names:
+ items:
+ - const: sys
+
+ power-domains:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@295e0000 {
+ compatible = "starfive,jh7110-dphy-tx";
+ reg = <0x295e0000 0x10000>;
+ clocks = <&voutcrg 14>;
+ clock-names = "txesc";
+ resets = <&syscrg 10>;
+ reset-names = "sys";
+ power-domains = <&aon_syscon 0>;
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml
new file mode 100644
index 000000000000..2e83a6164cd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-pcie-phy.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/starfive,jh7110-pcie-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 PCIe 2.0 PHY
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ starfive,sys-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller sys_syscon node.
+ - description: PHY connect offset of SYS_SYSCONSAIF__SYSCFG register for USB PHY.
+ description:
+ The phandle to System Register Controller syscon node and the PHY connect offset
+ of SYS_SYSCONSAIF__SYSCFG register. Connect PHY to USB3 controller.
+
+ starfive,stg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller stg_syscon node.
+ - description: PHY mode offset of STG_SYSCONSAIF__SYSCFG register.
+ - description: PHY enable for USB offset of STG_SYSCONSAIF__SYSCFG register.
+ description:
+ The phandle to System Register Controller syscon node and the offset
+ of STG_SYSCONSAIF__SYSCFG register for PCIe PHY. Total 2 regsisters offset.
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@10210000 {
+ compatible = "starfive,jh7110-pcie-phy";
+ reg = <0x10210000 0x10000>;
+ #phy-cells = <0>;
+ starfive,sys-syscon = <&sys_syscon 0x18>;
+ starfive,stg-syscon = <&stg_syscon 0x148 0x1f4>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
new file mode 100644
index 000000000000..269e9f9f12b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/starfive,jh7110-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 USB 2.0 PHY
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-usb-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: PHY 125m
+ - description: app 125m
+
+ clock-names:
+ items:
+ - const: 125m
+ - const: app_125m
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@10200000 {
+ compatible = "starfive,jh7110-usb-phy";
+ reg = <0x10200000 0x10000>;
+ clocks = <&syscrg 95>,
+ <&stgcrg 6>;
+ clock-names = "125m", "app_125m";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml
new file mode 100644
index 000000000000..57914f214e06
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) Sunplus Co., Ltd. 2021
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/sunplus,sp7021-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sunplus SP7021 USB 2.0 PHY Controller
+
+maintainers:
+ - Vincent Shih <vincent.sunplus@gmail.com>
+
+properties:
+ compatible:
+ const: sunplus,sp7021-usb2-phy
+
+ reg:
+ items:
+ - description: UPHY register region
+ - description: MOON4 register region
+
+ reg-names:
+ items:
+ - const: phy
+ - const: moon4
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+ nvmem-cell-names:
+ description: names corresponding to the nvmem cells of disconnect voltage
+ const: disc_vol
+
+ nvmem-cells:
+ description: nvmem cell address of disconnect voltage
+ maxItems: 1
+
+ sunplus,disc-vol-addr-off:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: the otp address offset of disconnect voltage
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - resets
+ - "#phy-cells"
+ - nvmem-cell-names
+ - nvmem-cells
+ - sunplus,disc-vol-addr-off
+
+additionalProperties: false
+
+examples:
+ - |
+ sp_uphy0: usb-phy@9c004a80 {
+ compatible = "sunplus,sp7021-usb2-phy";
+ reg = <0x9c004a80 0x80>, <0x9c000248 0x10>;
+ reg-names = "phy", "moon4";
+ clocks = <&clkc 0x3d>;
+ resets = <&rstc 0x2d>;
+ #phy-cells = <0>;
+ nvmem-cell-names = "disc_vol";
+ nvmem-cells = <&disc_vol>;
+ sunplus,disc-vol-addr-off = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/ti,da830-usb-phy.yaml b/Documentation/devicetree/bindings/phy/ti,da830-usb-phy.yaml
new file mode 100644
index 000000000000..e168cbce8fd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,da830-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,da830-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DA8xx/OMAP-L1xx/AM18xx USB PHY
+
+maintainers:
+ - David Lechner <david@lechnology.com>
+
+description: >
+ This device controls the PHY for both the USB 1.1 OHCI and USB 2.0 OTG
+ controllers on DA8xx SoCs.
+
+ It also requires a "syscon" node with compatible = "ti,da830-cfgchip", "syscon"
+ to access the CFGCHIP2 register.
+
+properties:
+ compatible:
+ items:
+ - const: ti,da830-usb-phy
+
+ '#phy-cells':
+ const: 1
+ description:
+ Consumers of this device should use index 0 for the USB 2.0 phy device and
+ index 1 for the USB 1.1 phy device.
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: usb0_clk48
+ - const: usb1_clk48
+
+required:
+ - compatible
+ - '#phy-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ clocks = <&usb_phy_clk 0>, <&usb_phy_clk 1>;
+ clock-names = "usb0_clk48", "usb1_clk48";
+ };
diff --git a/Documentation/devicetree/bindings/phy/ti,dm8168-usb-phy.yaml b/Documentation/devicetree/bindings/phy/ti,dm8168-usb-phy.yaml
new file mode 100644
index 000000000000..673dc1d37dcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,dm8168-usb-phy.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,dm8168-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DM8168 USB PHY
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+properties:
+ compatible:
+ const: ti,dm8168-usb-phy
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: phy
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: refclk
+
+ '#phy-cells':
+ const: 0
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle for the syscon node to access misc registers.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - '#phy-cells'
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@20 {
+ compatible = "ti,dm8168-usb-phy";
+ reg = <0x20 0x8>;
+ reg-names = "phy";
+ clocks = <&main_fapll 6>;
+ clock-names = "refclk";
+ #phy-cells = <0>;
+ syscon = <&scm_conf>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml b/Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml
new file mode 100644
index 000000000000..08dc18e7feea
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,keystone-usbphy.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,keystone-usbphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Keystone USB PHY
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+ - Santosh Shilimkar <ssantosh@kernel.org>
+
+description:
+ The main purpose of this PHY driver is to enable the USB PHY reference clock
+ gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just
+ an NOP PHY driver. Hence this node is referenced as both the usb2 and usb3
+ phy node in the USB Glue layer driver node.
+
+properties:
+ compatible:
+ const: ti,keystone-usbphy
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ usb-phy@2620738 {
+ compatible = "ti,keystone-usbphy";
+ reg = <0x2620738 32>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml
index 62dcb84c08aa..854e554eae67 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/ti,phy-am654-serdes.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI AM654 SERDES binding
+title: TI AM654 SERDES
description:
This binding describes the TI AM654 SERDES. AM654 SERDES can be configured
@@ -34,11 +34,6 @@ properties:
Three input clocks referring to left input reference clock, refclk and right input reference
clock.
- assigned-clocks:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
- assigned-clock-parents:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
-
'#phy-cells':
const: 2
description:
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index ff8a6d9eb153..be41b4547ec6 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -2,10 +2,10 @@
# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/ti,phy-gmii-sel.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/ti,phy-gmii-sel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: CPSW Port's Interface Mode Selection PHY Tree Bindings
+title: CPSW Port's Interface Mode Selection PHY
maintainers:
- Kishon Vijay Abraham I <kishon@ti.com>
@@ -53,12 +53,30 @@ properties:
- ti,am43xx-phy-gmii-sel
- ti,dm814-phy-gmii-sel
- ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
reg:
maxItems: 1
'#phy-cells': true
+ ti,qsgmii-main-ports:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Required only for QSGMII mode. Array to select the port/s for QSGMII
+ main mode. The size of the array corresponds to the number of QSGMII
+ interfaces and thus, the number of distinct QSGMII main ports,
+ supported by the device. If the device supports two QSGMII interfaces
+ but only one QSGMII interface is desired, repeat the QSGMII main port
+ value corresponding to the QSGMII interface in the array.
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 1
+ maximum: 8
+
allOf:
- if:
properties:
@@ -68,11 +86,58 @@ allOf:
- ti,dra7xx-phy-gmii-sel
- ti,dm814-phy-gmii-sel
- ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
then:
properties:
'#phy-cells':
const: 1
description: CPSW port number (starting from 1)
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ then:
+ properties:
+ ti,qsgmii-main-ports:
+ maxItems: 1
+ items:
+ minimum: 1
+ maximum: 4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ then:
+ properties:
+ ti,qsgmii-main-ports:
+ minItems: 2
+ maxItems: 2
+ items:
+ minimum: 1
+ maximum: 8
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ then:
+ properties:
+ ti,qsgmii-main-ports: false
+
- if:
properties:
compatible:
@@ -97,7 +162,7 @@ additionalProperties: false
examples:
- |
- phy_gmii_sel: phy-gmii-sel@650 {
+ phy_gmii_sel: phy@650 {
compatible = "ti,am3352-phy-gmii-sel";
reg = <0x650 0x4>;
#phy-cells = <2>;
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index dcd63908aeae..3f16ff14484d 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/ti,phy-j721e-wiz.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/ti,phy-j721e-wiz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI J721E WIZ (SERDES Wrapper)
@@ -15,20 +15,26 @@ properties:
enum:
- ti,j721e-wiz-16g
- ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
- ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
power-domains:
maxItems: 1
clocks:
- maxItems: 3
+ minItems: 3
+ maxItems: 4
description: clock-specifier to represent input to the WIZ
clock-names:
+ minItems: 3
items:
- const: fck
- const: core_ref_clk
- const: ext_ref_clk
+ - const: core_ref1_clk
num-lanes:
minimum: 1
@@ -48,24 +54,12 @@ properties:
ranges: true
- assigned-clocks:
- minItems: 1
- maxItems: 2
-
- assigned-clock-parents:
- minItems: 1
- maxItems: 2
-
- assigned-clock-rates:
- minItems: 1
- maxItems: 2
-
typec-dir-gpios:
maxItems: 1
description:
GPIO to signal Type-C cable orientation for lane swap.
If GPIO is active, lane 0 and lane 1 of SERDES will be swapped to
- achieve the funtionality of an external type-C plug flip mux.
+ achieve the functionality of an external type-C plug flip mux.
typec-dir-debounce-ms:
minimum: 100
@@ -79,10 +73,12 @@ properties:
refclk-dig:
type: object
+ additionalProperties: false
description: |
WIZ node should have subnode for refclk_dig to select the reference
clock source for the reference clock used in the PHY and PMA digital
logic.
+ deprecated: true
properties:
clocks:
minItems: 2
@@ -93,6 +89,9 @@ properties:
"#clock-cells":
const: 0
+ clock-output-names:
+ maxItems: 1
+
assigned-clocks:
maxItems: 1
@@ -105,12 +104,19 @@ properties:
- assigned-clocks
- assigned-clock-parents
+ ti,scm:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ phandle to System Control Module for syscon regmap access.
+
patternProperties:
"^pll[0|1]-refclk$":
type: object
+ additionalProperties: false
description: |
WIZ node should have subnodes for each of the PLLs present in
the SERDES.
+ deprecated: true
properties:
clocks:
maxItems: 2
@@ -119,6 +125,9 @@ patternProperties:
"#clock-cells":
const: 0
+ clock-output-names:
+ maxItems: 1
+
assigned-clocks:
maxItems: 1
@@ -133,9 +142,11 @@ patternProperties:
"^cmn-refclk1?-dig-div$":
type: object
+ additionalProperties: false
description:
WIZ node should have subnodes for each of the PMA common refclock
provided by the SERDES.
+ deprecated: true
properties:
clocks:
maxItems: 1
@@ -145,6 +156,9 @@ patternProperties:
"#clock-cells":
const: 0
+ clock-output-names:
+ maxItems: 1
+
required:
- clocks
- "#clock-cells"
@@ -170,6 +184,16 @@ required:
- "#reset-cells"
- ranges
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,j7200-wiz-10g
+ then:
+ required:
+ - ti,scm
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 02b76f15e717..c686d06f5f56 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TCAN104x CAN TRANSCEIVER PHY
@@ -14,18 +14,35 @@ properties:
pattern: "^can-phy"
compatible:
- enum:
- - ti,tcan1042
- - ti,tcan1043
+ oneOf:
+ - items:
+ - enum:
+ - microchip,ata6561
+ - ti,tcan1051
+ - const: ti,tcan1042
+ - enum:
+ - ti,tcan1042
+ - ti,tcan1043
+ - nxp,tja1048
+ - nxp,tja1051
+ - nxp,tja1057
+ - nxp,tjr1443
'#phy-cells':
- const: 0
+ enum: [0, 1]
- standby-gpios:
+ silent-gpios:
description:
- gpio node to toggle standby signal on transceiver
+ gpio node to toggle silent signal on transceiver
maxItems: 1
+ standby-gpios:
+ description:
+ gpio node to toggle standby signal on transceiver. For two Items, item 1
+ is for stbn1, item 2 is for stbn2.
+ minItems: 1
+ maxItems: 2
+
enable-gpios:
description:
gpio node to toggle enable signal on transceiver
@@ -47,6 +64,59 @@ required:
- compatible
- '#phy-cells'
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - nxp,tjr1443
+ - ti,tcan1042
+ - ti,tcan1043
+ then:
+ properties:
+ '#phy-cells':
+ const: 0
+ silent-gpios: false
+ standby-gpios:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,tja1048
+ then:
+ properties:
+ '#phy-cells':
+ const: 1
+ enable-gpios: false
+ silent-gpios: false
+ standby-gpios:
+ minItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,tja1051
+ then:
+ properties:
+ '#phy-cells':
+ const: 0
+ standby-gpios: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,tja1057
+ then:
+ properties:
+ '#phy-cells':
+ const: 0
+ enable-gpios: false
+ standby-gpios: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 60c9d0ac75e6..7c7936b89f2c 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -62,7 +62,7 @@ Deprecated properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
the PHY.
-Recommended properies:
+Recommended properties:
- syscon-phy-power : phandle/offset pair. Phandle to the system control
module and the register offset to power on/off the PHY.
diff --git a/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml b/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
index 51492fe738ec..617f3c0b3dfb 100644
--- a/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
+++ b/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/transmit-amplitude.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common PHY and network PCS transmit amplitude property binding
+title: Common PHY and network PCS transmit amplitude property
description:
Binding describing the peak-to-peak transmit amplitude for common PHYs
diff --git a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
index 79906519c652..cefbc8b53a83 100644
--- a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
+++ b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/phy/xlnx,zynqmp-psgtr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx ZynqMP Gigabit Transceiver PHY Device Tree Bindings
+title: Xilinx ZynqMP Gigabit Transceiver PHY
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml
index fb0f69ce9c16..7cb8a747feee 100644
--- a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml
@@ -185,7 +185,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.txt
deleted file mode 100644
index d13ff82f8518..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.txt
+++ /dev/null
@@ -1,170 +0,0 @@
-Actions Semi S700 Pin Controller
-
-This binding describes the pin controller found in the S700 SoC.
-
-Required Properties:
-
-- compatible: Should be "actions,s700-pinctrl"
-- reg: Should contain the register base address and size of
- the pin controller.
-- clocks: phandle of the clock feeding the pin controller
-- gpio-controller: Marks the device node as a GPIO controller.
-- gpio-ranges: Specifies the mapping between gpio controller and
- pin-controller pins.
-- #gpio-cells: Should be two. The first cell is the gpio pin number
- and the second cell is used for optional parameters.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt. Shall be set to 2. The first cell
- defines the interrupt number, the second encodes
- the trigger flags described in
- bindings/interrupt-controller/interrupts.txt
-- interrupts: The interrupt outputs from the controller. There is one GPIO
- interrupt per GPIO bank. The number of interrupts listed depends
- on the number of GPIO banks on the SoC. The interrupts must be
- ordered by bank, starting with bank 0.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-Pinmux functions are available only for the pin groups while pinconf
-parameters are available for both pin groups and individual pins.
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-Required Properties:
-
-- pins: An array of strings, each string containing the name of a pin.
- These pins are used for selecting the pull control and schmitt
- trigger parameters. The following are the list of pins
- available:
-
- eth_txd0, eth_txd1, eth_txd2, eth_txd3, eth_txen, eth_rxer,
- eth_crs_dv, eth_rxd1, eth_rxd0, eth_rxd2, eth_rxd3, eth_ref_clk,
- eth_mdc, eth_mdio, sirq0, sirq1, sirq2, i2s_d0, i2s_bclk0,
- i2s_lrclk0, i2s_mclk0, i2s_d1, i2s_bclk1, i2s_lrclk1, i2s_mclk1,
- pcm1_in, pcm1_clk, pcm1_sync, pcm1_out, ks_in0, ks_in1, ks_in2,
- ks_in3, ks_out0, ks_out1, ks_out2, lvds_oep, lvds_oen, lvds_odp,
- lvds_odn, lvds_ocp, lvds_ocn, lvds_obp, lvds_obn, lvds_oap,
- lvds_oan, lvds_eep, lvds_een, lvds_edp, lvds_edn, lvds_ecp,
- lvds_ecn, lvds_ebp, lvds_ebn, lvds_eap, lvds_ean, lcd0_d18,
- lcd0_d2, dsi_dp3, dsi_dn3, dsi_dp1, dsi_dn1, dsi_cp, dsi_cn,
- dsi_dp0, dsi_dn0, dsi_dp2, dsi_dn2, sd0_d0, sd0_d1, sd0_d2,
- sd0_d3, sd1_d0, sd1_d1, sd1_d2, sd1_d3, sd0_cmd, sd0_clk,
- sd1_cmd, sd1_clk, spi0_ss, spi0_miso, uart0_rx, uart0_tx,
- uart2_rx, uart2_tx, uart2_rtsb, uart2_ctsb, uart3_rx, uart3_tx,
- uart3_rtsb, uart3_ctsb, i2c0_sclk, i2c0_sdata, i2c1_sclk,
- i2c1_sdata, i2c2_sdata, csi_dn0, csi_dp0, csi_dn1, csi_dp1,
- csi_cn, csi_cp, csi_dn2, csi_dp2, csi_dn3, csi_dp3,
- sensor0_pclk, sensor0_ckout, dnand_d0, dnand_d1, dnand_d2,
- dnand_d3, dnand_d4, dnand_d5, dnand_d6, dnand_d7, dnand_wrb,
- dnand_rdb, dnand_rdbn, dnand_dqs, dnand_dqsn, dnand_rb0,
- dnand_ale, dnand_cle, dnand_ceb0, dnand_ceb1, dnand_ceb2,
- dnand_ceb3, porb, clko_25m, bsel, pkg0, pkg1, pkg2, pkg3
-
-- groups: An array of strings, each string containing the name of a pin
- group. These pin groups are used for selecting the pinmux
- functions.
- rgmii_txd23_mfp, rgmii_rxd2_mfp, rgmii_rxd3_mfp, lcd0_d18_mfp,
- rgmii_txd01_mfp, rgmii_txd0_mfp, rgmii_txd1_mfp, rgmii_txen_mfp,
- rgmii_rxen_mfp, rgmii_rxd1_mfp, rgmii_rxd0_mfp, rgmii_ref_clk_mfp,
- i2s_d0_mfp, i2s_pcm1_mfp, i2s0_pcm0_mfp, i2s1_pcm0_mfp,
- i2s_d1_mfp, ks_in2_mfp, ks_in1_mfp, ks_in0_mfp, ks_in3_mfp,
- ks_out0_mfp, ks_out1_mfp, ks_out2_mfp, lvds_o_pn_mfp, dsi_dn0_mfp,
- dsi_dp2_mfp, lcd0_d2_mfp, dsi_dp3_mfp, dsi_dn3_mfp, dsi_dp0_mfp,
- lvds_ee_pn_mfp, uart2_rx_tx_mfp, spi0_i2c_pcm_mfp, dsi_dnp1_cp_d2_mfp,
- dsi_dnp1_cp_d17_mfp, lvds_e_pn_mfp, dsi_dn2_mfp, uart2_rtsb_mfp,
- uart2_ctsb_mfp, uart3_rtsb_mfp, uart3_ctsb_mfp, sd0_d0_mfp, sd0_d1_mfp,
- sd0_d2_d3_mfp, sd1_d0_d3_mfp, sd0_cmd_mfp, sd0_clk_mfp, sd1_cmd_mfp,
- uart0_rx_mfp, clko_25m_mfp, csi_cn_cp_mfp, sens0_ckout_mfp, uart0_tx_mfp,
- i2c0_mfp, csi_dn_dp_mfp, sen0_pclk_mfp, pcm1_in_mfp, pcm1_clk_mfp,
- pcm1_sync_mfp, pcm1_out_mfp, dnand_data_wr_mfp, dnand_acle_ce0_mfp,
- nand_ceb2_mfp, nand_ceb3_mfp
-
- These pin groups are used for selecting the drive strength
- parameters.
-
- sirq_drv, rgmii_txd23_drv, rgmii_rxd23_drv, rgmii_txd01_txen_drv,
- rgmii_rxer_drv, rgmii_crs_drv, rgmii_rxd10_drv, rgmii_ref_clk_drv,
- smi_mdc_mdio_drv, i2s_d0_drv, i2s_bclk0_drv, i2s3_drv, i2s13_drv,
- pcm1_drv, ks_in_drv, ks_out_drv, lvds_all_drv, lcd_d18_d2_drv,
- dsi_all_drv, sd0_d0_d3_drv, sd0_cmd_drv, sd0_clk_drv, spi0_all_drv,
- uart0_rx_drv, uart0_tx_drv, uart2_all_drv, i2c0_all_drv, i2c12_all_drv,
- sens0_pclk_drv, sens0_ckout_drv, uart3_all_drv
-
-- function: An array of strings, each string containing the name of the
- pinmux functions. These functions can only be selected by
- the corresponding pin groups. The following are the list of
- pinmux functions available:
-
- nor, eth_rgmii, eth_sgmii, spi0, spi1, spi2, spi3, seNs0, sens1,
- uart0, uart1, uart2, uart3, uart4, uart5, uart6, i2s0, i2s1,
- pcm1, pcm0, ks, jtag, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, p0,
- sd0, sd1, sd2, i2c0, i2c1, i2c2, i2c3, dsi, lvds, usb30,
- clko_25m, mipi_csi, nand, spdif, sirq0, sirq1, sirq2, bt, lcd0
-
-Optional Properties:
-
-- bias-pull-down: No arguments. The specified pins should be configured as
- pull down.
-- bias-pull-up: No arguments. The specified pins should be configured as
- pull up.
-- input-schmitt-enable: No arguments: Enable schmitt trigger for the specified
- pins
-- input-schmitt-disable: No arguments: Disable schmitt trigger for the specified
- pins
-- drive-strength: Integer. Selects the drive strength for the specified
- pins in mA.
- Valid values are:
- <2>
- <4>
- <8>
- <12>
-
-Example:
-
- pinctrl: pinctrl@e01b0000 {
- compatible = "actions,s700-pinctrl";
- reg = <0x0 0xe01b0000 0x0 0x1000>;
- clocks = <&cmu CLK_GPIO>;
- gpio-controller;
- gpio-ranges = <&pinctrl 0 0 136>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
-
- uart3-default: uart3-default {
- pinmux {
- groups = "uart3_rtsb_mfp", "uart3_ctsb_mfp";
- function = "uart3";
- };
- pinconf {
- groups = "uart3_all_drv";
- drive-strength = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.yaml
new file mode 100644
index 000000000000..9597b983c332
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s700-pinctrl.yaml
@@ -0,0 +1,204 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/actions,s700-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi S700 Pin Controller
+
+maintainers:
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+properties:
+ compatible:
+ const: actions,s700-pinctrl
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ gpio-controller: true
+
+ gpio-line-names:
+ maxItems: 136
+
+ gpio-ranges: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 5
+ description:
+ The interrupt outputs from the controller. There is one GPIO interrupt per
+ GPIO bank. The interrupts must be ordered by bank, starting with
+ bank 0.
+
+additionalProperties:
+ type: object
+ description: Pin configuration subnode
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ description: Configure pin multiplexing.
+ type: object
+ $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ groups:
+ items:
+ enum: [
+ rgmii_txd23_mfp, rgmii_rxd2_mfp, rgmii_rxd3_mfp, lcd0_d18_mfp,
+ rgmii_txd01_mfp, rgmii_txd0_mfp, rgmii_txd1_mfp, rgmii_txen_mfp,
+ rgmii_rxen_mfp, rgmii_rxd1_mfp, rgmii_rxd0_mfp, rgmii_ref_clk_mfp,
+ i2c1_dummy, i2c2_dummy, i2s_d0_mfp, i2s_pcm1_mfp, i2s0_pcm0_mfp, i2s1_pcm0_mfp,
+ i2s_d1_mfp, ks_in2_mfp, ks_in1_mfp, ks_in0_mfp, ks_in3_mfp,
+ ks_out0_mfp, ks_out1_mfp, ks_out2_mfp, lvds_o_pn_mfp, dsi_dn0_mfp,
+ dsi_dp2_mfp, lcd0_d2_mfp, dsi_dp3_mfp, dsi_dn3_mfp, dsi_dp0_mfp,
+ lvds_ee_pn_mfp, uart2_rx_tx_mfp, spi0_i2c_pcm_mfp,
+ dsi_dnp1_cp_d2_mfp, dsi_dnp1_cp_d17_mfp, lvds_e_pn_mfp,
+ dsi_dn2_mfp, uart2_rtsb_mfp, uart2_ctsb_mfp, uart3_rtsb_mfp,
+ uart3_ctsb_mfp, sd0_d0_mfp, sd0_d1_mfp, sd0_d2_d3_mfp,
+ sd1_d0_d3_mfp, sd0_cmd_mfp, sd0_clk_mfp, sd1_cmd_mfp,
+ uart0_rx_mfp, clko_25m_mfp, csi_cn_cp_mfp, sens0_ckout_mfp,
+ uart0_tx_mfp, i2c0_mfp, csi_dn_dp_mfp, sen0_pclk_mfp, pcm1_in_mfp,
+ pcm1_clk_mfp, pcm1_sync_mfp, pcm1_out_mfp, dnand_data_wr_mfp,
+ dnand_acle_ce0_mfp, nand_ceb2_mfp, nand_ceb3_mfp
+ ]
+
+ function:
+ items:
+ enum: [
+ nor, eth_rgmii, eth_sgmii, spi0, spi1, spi2, spi3, seNs0, sens1,
+ uart0, uart1, uart2, uart3, uart4, uart5, uart6, i2s0, i2s1, pcm1,
+ pcm0, ks, jtag, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, p0, sd0, sd1,
+ sd2, i2c0, i2c1, i2c2, i2c3, dsi, lvds, usb30, clko_25m, mipi_csi,
+ nand, spdif, sirq0, sirq1, sirq2, bt, lcd0
+ ]
+
+ required:
+ - groups
+ - function
+
+ pinconf:
+ description: Configure pin-specific parameters.
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ groups:
+ items:
+ enum: [
+ sirq_drv, rgmii_txd23_drv, rgmii_rxd23_drv, rgmii_txd01_txen_drv,
+ rgmii_rxer_drv, rgmii_crs_drv, rgmii_rxd10_drv, rgmii_ref_clk_drv,
+ smi_mdc_mdio_drv, i2s_d0_drv, i2s_bclk0_drv, i2s3_drv, i2s13_drv,
+ pcm1_drv, ks_in_drv, ks_out_drv, lvds_all_drv, lcd_d18_d2_drv,
+ dsi_all_drv, sd0_d0_d3_drv, sd0_cmd_drv, sd0_clk_drv,
+ spi0_all_drv, uart0_rx_drv, uart0_tx_drv, uart2_all_drv,
+ i2c0_all_drv, i2c12_all_drv, sens0_pclk_drv, sens0_ckout_drv,
+ uart3_all_drv
+ ]
+
+ pins:
+ items:
+ enum: [
+ eth_txd0, eth_txd1, eth_txd2, eth_txd3, eth_txen, eth_rxer,
+ eth_crs_dv, eth_rxd1, eth_rxd0, eth_rxd2, eth_rxd3, eth_ref_clk,
+ eth_mdc, eth_mdio, sirq0, sirq1, sirq2, i2s_d0, i2s_bclk0,
+ i2s_lrclk0, i2s_mclk0, i2s_d1, i2s_bclk1, i2s_lrclk1, i2s_mclk1,
+ pcm1_in, pcm1_clk, pcm1_sync, pcm1_out, ks_in0, ks_in1, ks_in2,
+ ks_in3, ks_out0, ks_out1, ks_out2, lvds_oep, lvds_oen, lvds_odp,
+ lvds_odn, lvds_ocp, lvds_ocn, lvds_obp, lvds_obn, lvds_oap,
+ lvds_oan, lvds_eep, lvds_een, lvds_edp, lvds_edn, lvds_ecp,
+ lvds_ecn, lvds_ebp, lvds_ebn, lvds_eap, lvds_ean, lcd0_d18,
+ lcd0_d2, dsi_dp3, dsi_dn3, dsi_dp1, dsi_dn1, dsi_cp, dsi_cn,
+ dsi_dp0, dsi_dn0, dsi_dp2, dsi_dn2, sd0_d0, sd0_d1, sd0_d2,
+ sd0_d3, sd1_d0, sd1_d1, sd1_d2, sd1_d3, sd0_cmd, sd0_clk, sd1_cmd,
+ sd1_clk, spi0_ss, spi0_miso, uart0_rx, uart0_tx, uart2_rx,
+ uart2_tx, uart2_rtsb, uart2_ctsb, uart3_rx, uart3_tx, uart3_rtsb,
+ uart3_ctsb, i2c0_sclk, i2c0_sdata, i2c1_sclk, i2c1_sdata,
+ i2c2_sclk, i2c2_sdata, csi_dn0, csi_dp0, csi_dn1, csi_dp1, csi_cn, csi_cp,
+ csi_dn2, csi_dp2, csi_dn3, csi_dp3, sensor0_pclk, sensor0_ckout,
+ dnand_d0, dnand_d1, dnand_d2, dnand_d3, dnand_d4, dnand_d5,
+ dnand_d6, dnand_d7, dnand_wrb, dnand_rdb, dnand_rdbn, dnand_dqs,
+ dnand_dqsn, dnand_rb0, dnand_ale, dnand_cle, dnand_ceb0,
+ dnand_ceb1, dnand_ceb2, dnand_ceb3, porb, clko_25m, bsel, pkg0,
+ pkg1, pkg2, pkg3
+ ]
+
+ bias-pull-down:
+ type: boolean
+
+ bias-pull-up:
+ type: boolean
+
+ drive-strength:
+ description: Selects the drive strength for the specified pins in mA.
+ enum: [2, 4, 8, 12]
+
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+
+ oneOf:
+ - required:
+ - groups
+ - required:
+ - pins
+
+ anyOf:
+ - required: [ pinmux ]
+ - required: [ pinconf ]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - gpio-controller
+ - gpio-ranges
+ - '#gpio-cells'
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl: pinctrl@e01b0000 {
+ compatible = "actions,s700-pinctrl";
+ reg = <0xe01b0000 0x1000>;
+ clocks = <&cmu 1>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 136>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart3-default {
+ pinmux {
+ groups = "uart3_rtsb_mfp", "uart3_ctsb_mfp";
+ function = "uart3";
+ };
+ pinconf {
+ groups = "uart3_all_drv";
+ drive-strength = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
deleted file mode 100644
index 81b58dddd3ed..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
+++ /dev/null
@@ -1,204 +0,0 @@
-Actions Semi S900 Pin Controller
-
-This binding describes the pin controller found in the S900 SoC.
-
-Required Properties:
-
-- compatible: Should be "actions,s900-pinctrl"
-- reg: Should contain the register base address and size of
- the pin controller.
-- clocks: phandle of the clock feeding the pin controller
-- gpio-controller: Marks the device node as a GPIO controller.
-- gpio-ranges: Specifies the mapping between gpio controller and
- pin-controller pins.
-- #gpio-cells: Should be two. The first cell is the gpio pin number
- and the second cell is used for optional parameters.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt. Shall be set to 2. The first cell
- defines the interrupt number, the second encodes
- the trigger flags described in
- bindings/interrupt-controller/interrupts.txt
-- interrupts: The interrupt outputs from the controller. There is one GPIO
- interrupt per GPIO bank. The number of interrupts listed depends
- on the number of GPIO banks on the SoC. The interrupts must be
- ordered by bank, starting with bank 0.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-Pinmux functions are available only for the pin groups while pinconf
-parameters are available for both pin groups and individual pins.
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-Required Properties:
-
-- pins: An array of strings, each string containing the name of a pin.
- These pins are used for selecting the pull control and schmitt
- trigger parameters. The following are the list of pins
- available:
-
- eth_txd0, eth_txd1, eth_txen, eth_rxer, eth_crs_dv,
- eth_rxd1, eth_rxd0, eth_ref_clk, eth_mdc, eth_mdio,
- sirq0, sirq1, sirq2, i2s_d0, i2s_bclk0, i2s_lrclk0,
- i2s_mclk0, i2s_d1, i2s_bclk1, i2s_lrclk1, i2s_mclk1,
- pcm1_in, pcm1_clk, pcm1_sync, pcm1_out, eram_a5,
- eram_a6, eram_a7, eram_a8, eram_a9, eram_a10, eram_a11,
- lvds_oep, lvds_oen, lvds_odp, lvds_odn, lvds_ocp,
- lvds_ocn, lvds_obp, lvds_obn, lvds_oap, lvds_oan,
- lvds_eep, lvds_een, lvds_edp, lvds_edn, lvds_ecp,
- lvds_ecn, lvds_ebp, lvds_ebn, lvds_eap, lvds_ean,
- sd0_d0, sd0_d1, sd0_d2, sd0_d3, sd1_d0, sd1_d1,
- sd1_d2, sd1_d3, sd0_cmd, sd0_clk, sd1_cmd, sd1_clk,
- spi0_sclk, spi0_ss, spi0_miso, spi0_mosi, uart0_rx,
- uart0_tx, uart2_rx, uart2_tx, uart2_rtsb, uart2_ctsb,
- uart3_rx, uart3_tx, uart3_rtsb, uart3_ctsb, uart4_rx,
- uart4_tx, i2c0_sclk, i2c0_sdata, i2c1_sclk, i2c1_sdata,
- i2c2_sclk, i2c2_sdata, csi0_dn0, csi0_dp0, csi0_dn1,
- csi0_dp1, csi0_cn, csi0_cp, csi0_dn2, csi0_dp2, csi0_dn3,
- csi0_dp3, dsi_dp3, dsi_dn3, dsi_dp1, dsi_dn1, dsi_cp,
- dsi_cn, dsi_dp0, dsi_dn0, dsi_dp2, dsi_dn2, sensor0_pclk,
- csi1_dn0,csi1_dp0,csi1_dn1, csi1_dp1, csi1_cn, csi1_cp,
- sensor0_ckout, nand0_d0, nand0_d1, nand0_d2, nand0_d3,
- nand0_d4, nand0_d5, nand0_d6, nand0_d7, nand0_dqs,
- nand0_dqsn, nand0_ale, nand0_cle, nand0_ceb0, nand0_ceb1,
- nand0_ceb2, nand0_ceb3, nand1_d0, nand1_d1, nand1_d2,
- nand1_d3, nand1_d4, nand1_d5, nand1_d6, nand1_d7, nand1_dqs,
- nand1_dqsn, nand1_ale, nand1_cle, nand1_ceb0, nand1_ceb1,
- nand1_ceb2, nand1_ceb3, sgpio0, sgpio1, sgpio2, sgpio3
-
-- groups: An array of strings, each string containing the name of a pin
- group. These pin groups are used for selecting the pinmux
- functions.
-
- lvds_oxx_uart4_mfp, rmii_mdc_mfp, rmii_mdio_mfp, sirq0_mfp,
- sirq1_mfp, rmii_txd0_mfp, rmii_txd1_mfp, rmii_txen_mfp,
- rmii_rxer_mfp, rmii_crs_dv_mfp, rmii_rxd1_mfp, rmii_rxd0_mfp,
- rmii_ref_clk_mfp, i2s_d0_mfp, i2s_d1_mfp, i2s_lr_m_clk0_mfp,
- i2s_bclk0_mfp, i2s_bclk1_mclk1_mfp, pcm1_in_out_mfp,
- pcm1_clk_mfp, pcm1_sync_mfp, eram_a5_mfp, eram_a6_mfp,
- eram_a7_mfp, eram_a8_mfp, eram_a9_mfp, eram_a10_mfp,
- eram_a11_mfp, lvds_oep_odn_mfp, lvds_ocp_obn_mfp,
- lvds_oap_oan_mfp, lvds_e_mfp, spi0_sclk_mosi_mfp, spi0_ss_mfp,
- spi0_miso_mfp, uart2_rtsb_mfp, uart2_ctsb_mfp, uart3_rtsb_mfp,
- uart3_ctsb_mfp, sd0_d0_mfp, sd0_d1_mfp, sd0_d2_d3_mfp,
- sd1_d0_d3_mfp, sd0_cmd_mfp, sd0_clk_mfp, sd1_cmd_clk_mfp,
- uart0_rx_mfp, nand0_d0_ceb3_mfp, uart0_tx_mfp, i2c0_mfp,
- csi0_cn_cp_mfp, csi0_dn0_dp3_mfp, csi1_dn0_cp_mfp,
- dsi_dp3_dn1_mfp, dsi_cp_dn0_mfp, dsi_dp2_dn2_mfp,
- nand1_d0_ceb1_mfp, nand1_ceb3_mfp, nand1_ceb0_mfp,
- csi1_dn0_dp0_mfp, uart4_rx_tx_mfp
-
-
- These pin groups are used for selecting the drive strength
- parameters.
-
- sgpio3_drv, sgpio2_drv, sgpio1_drv, sgpio0_drv,
- rmii_tx_d0_d1_drv, rmii_txen_rxer_drv, rmii_crs_dv_drv,
- rmii_rx_d1_d0_drv, rmii_ref_clk_drv, rmii_mdc_mdio_drv,
- sirq_0_1_drv, sirq2_drv, i2s_d0_d1_drv, i2s_lr_m_clk0_drv,
- i2s_blk1_mclk1_drv, pcm1_in_out_drv, lvds_oap_oan_drv,
- lvds_oep_odn_drv, lvds_ocp_obn_drv, lvds_e_drv, sd0_d3_d0_drv,
- sd1_d3_d0_drv, sd0_sd1_cmd_clk_drv, spi0_sclk_mosi_drv,
- spi0_ss_miso_drv, uart0_rx_tx_drv, uart4_rx_tx_drv, uart2_drv,
- uart3_drv, i2c0_drv, i2c1_drv, i2c2_drv, sensor0_drv
-
- These pin groups are used for selecting the slew rate
- parameters.
-
- sgpio3_sr, sgpio2_sr, sgpio1_sr, sgpio0_sr, rmii_tx_d0_d1_sr,
- rmii_txen_rxer_sr, rmii_crs_dv_sr, rmii_rx_d1_d0_sr,
- rmii_ref_clk_sr, rmii_mdc_mdio_sr, sirq_0_1_sr, sirq2_sr,
- i2s_do_d1_sr, i2s_lr_m_clk0_sr, i2s_bclk0_mclk1_sr,
- pcm1_in_out_sr, sd1_d3_d0_sr, sd0_sd1_clk_cmd_sr,
- spi0_sclk_mosi_sr, spi0_ss_miso_sr, uart0_rx_tx_sr,
- uart4_rx_tx_sr, uart2_sr, uart3_sr, i2c0_sr, i2c1_sr, i2c2_sr,
- sensor0_sr
-
-- function: An array of strings, each string containing the name of the
- pinmux functions. These functions can only be selected by
- the corresponding pin groups. The following are the list of
- pinmux functions available:
-
- eram, eth_rmii, eth_smii, spi0, spi1, spi2, spi3, sens0,
- uart0, uart1, uart2, uart3, uart4, uart5, uart6, i2s0, i2s1,
- pcm0, pcm1, jtag, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, sd0,
- sd1, sd2, sd3, i2c0, i2c1, i2c2, i2c3, i2c4, i2c5, lvds,
- usb30, usb20, gpu, mipi_csi0, mipi_csi1, mipi_dsi, nand0,
- nand1, spdif, sirq0, sirq1, sirq2
-
-Optional Properties:
-
-- bias-bus-hold: No arguments. The specified pins should retain the previous
- state value.
-- bias-high-impedance: No arguments. The specified pins should be configured
- as high impedance.
-- bias-pull-down: No arguments. The specified pins should be configured as
- pull down.
-- bias-pull-up: No arguments. The specified pins should be configured as
- pull up.
-- input-schmitt-enable: No arguments: Enable schmitt trigger for the specified
- pins
-- input-schmitt-disable: No arguments: Disable schmitt trigger for the specified
- pins
-- slew-rate: Integer. Sets slew rate for the specified pins.
- Valid values are:
- <0> - Slow
- <1> - Fast
-- drive-strength: Integer. Selects the drive strength for the specified
- pins in mA.
- Valid values are:
- <2>
- <4>
- <8>
- <12>
-
-Example:
-
- pinctrl: pinctrl@e01b0000 {
- compatible = "actions,s900-pinctrl";
- reg = <0x0 0xe01b0000 0x0 0x1000>;
- clocks = <&cmu CLK_GPIO>;
- gpio-controller;
- gpio-ranges = <&pinctrl 0 0 146>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
-
- uart2-default: uart2-default {
- pinmux {
- groups = "lvds_oep_odn_mfp";
- function = "uart2";
- };
- pinconf {
- groups = "lvds_oep_odn_drv";
- drive-strength = <12>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.yaml
new file mode 100644
index 000000000000..5c7b9f13226d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.yaml
@@ -0,0 +1,219 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/actions,s900-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi S900 Pin Controller
+
+maintainers:
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+properties:
+ compatible:
+ const: actions,s900-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 6
+ description: The interrupt outputs from the controller. There is one GPIO
+ interrupt per GPIO bank. The number of interrupts listed depends on the
+ number of GPIO banks on the SoC. The interrupts must be ordered by bank,
+ starting with bank 0.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ clocks:
+ maxItems: 1
+
+ gpio-controller: true
+
+ gpio-line-names:
+ maxItems: 146
+
+ gpio-ranges: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
+ - clocks
+ - gpio-controller
+ - gpio-ranges
+ - "#gpio-cells"
+
+additionalProperties:
+ type: object
+ description: Pin configuration subnode
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ type: object
+ description: Pin mux configuration
+ $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ groups:
+ items:
+ enum: [
+ lvds_oxx_uart4_mfp, rmii_mdc_mfp, rmii_mdio_mfp, sirq0_mfp,
+ sirq1_mfp, rmii_txd0_mfp, rmii_txd1_mfp, rmii_txen_mfp,
+ rmii_rxer_mfp, rmii_crs_dv_mfp, rmii_rxd1_mfp, rmii_rxd0_mfp,
+ rmii_ref_clk_mfp, i2s_d0_mfp, i2s_d1_mfp, i2s_lr_m_clk0_mfp,
+ i2s_bclk0_mfp, i2s_bclk1_mclk1_mfp, pcm1_in_out_mfp, pcm1_clk_mfp,
+ pcm1_sync_mfp, eram_a5_mfp, eram_a6_mfp, eram_a7_mfp, eram_a8_mfp,
+ eram_a9_mfp, eram_a10_mfp, eram_a11_mfp, lvds_oep_odn_mfp,
+ lvds_ocp_obn_mfp, lvds_oap_oan_mfp, lvds_e_mfp,
+ spi0_sclk_mosi_mfp, spi0_ss_mfp, spi0_miso_mfp, uart2_rtsb_mfp,
+ uart2_ctsb_mfp, uart3_rtsb_mfp, uart3_ctsb_mfp, sd0_d0_mfp,
+ sd0_d1_mfp, sd0_d2_d3_mfp, sd1_d0_d3_mfp, sd0_cmd_mfp,
+ sd0_clk_mfp, sd1_cmd_clk_mfp, uart0_rx_mfp, nand0_d0_ceb3_mfp,
+ uart0_tx_mfp, i2c0_mfp, csi0_cn_cp_mfp, csi0_dn0_dp3_mfp,
+ csi1_dn0_cp_mfp, dsi_dp3_dn1_mfp, dsi_cp_dn0_mfp, dsi_dp2_dn2_mfp,
+ nand1_d0_ceb1_mfp, nand1_ceb3_mfp, nand1_ceb0_mfp,
+ csi1_dn0_dp0_mfp, uart4_rx_tx_mfp
+ ]
+
+ function:
+ items:
+ enum: [
+ eram, eth_rmii, eth_smii, spi0, spi1, spi2, spi3, sens0,
+ uart0, uart1, uart2, uart3, uart4, uart5, uart6, i2s0, i2s1,
+ pcm0, pcm1, jtag, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, sd0,
+ sd1, sd2, sd3, i2c0, i2c1, i2c2, i2c3, i2c4, i2c5, lvds,
+ usb30, usb20, gpu, mipi_csi0, mipi_csi1, mipi_dsi, nand0,
+ nand1, spdif, sirq0, sirq1, sirq2
+ ]
+
+ required:
+ - groups
+ - function
+
+ pinconf:
+ type: object
+ description: Pin configuration parameters
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+
+ additionalProperties: false
+
+ properties:
+ groups:
+ items:
+ enum: [
+ # pin groups for drive strength
+ sgpio3_drv, sgpio2_drv, sgpio1_drv, sgpio0_drv, rmii_tx_d0_d1_drv,
+ rmii_txen_rxer_drv, rmii_crs_dv_drv, rmii_rx_d1_d0_drv,
+ rmii_ref_clk_drv, rmii_mdc_mdio_drv, sirq_0_1_drv, sirq2_drv,
+ i2s_d0_d1_drv, i2s_lr_m_clk0_drv, i2s_blk1_mclk1_drv,
+ pcm1_in_out_drv, lvds_oap_oan_drv, lvds_oep_odn_drv,
+ lvds_ocp_obn_drv, lvds_e_drv, sd0_d3_d0_drv, sd1_d3_d0_drv,
+ sd0_sd1_cmd_clk_drv, spi0_sclk_mosi_drv, spi0_ss_miso_drv,
+ uart0_rx_tx_drv, uart4_rx_tx_drv, uart2_drv, uart3_drv, i2c0_drv,
+ i2c1_drv, i2c2_drv, sensor0_drv,
+ # pin groups for slew rate
+ sgpio3_sr, sgpio2_sr, sgpio1_sr, sgpio0_sr, rmii_tx_d0_d1_sr,
+ rmii_txen_rxer_sr, rmii_crs_dv_sr, rmii_rx_d1_d0_sr,
+ rmii_ref_clk_sr, rmii_mdc_mdio_sr, sirq_0_1_sr, sirq2_sr,
+ i2s_do_d1_sr, i2s_lr_m_clk0_sr, i2s_bclk0_mclk1_sr,
+ pcm1_in_out_sr, sd1_d3_d0_sr, sd0_sd1_clk_cmd_sr,
+ spi0_sclk_mosi_sr, spi0_ss_miso_sr, uart0_rx_tx_sr,
+ uart4_rx_tx_sr, uart2_sr, uart3_sr, i2c0_sr, i2c1_sr, i2c2_sr,
+ sensor0_sr
+ ]
+
+ pins:
+ items:
+ enum: [
+ eth_txd0, eth_txd1, eth_txen, eth_rxer, eth_crs_dv, eth_rxd1,
+ eth_rxd0, eth_ref_clk, eth_mdc, eth_mdio, sirq0, sirq1, sirq2,
+ i2s_d0, i2s_bclk0, i2s_lrclk0, i2s_mclk0, i2s_d1, i2s_bclk1,
+ i2s_lrclk1, i2s_mclk1, pcm1_in, pcm1_clk, pcm1_sync, pcm1_out,
+ eram_a5, eram_a6, eram_a7, eram_a8, eram_a9, eram_a10, eram_a11,
+ lvds_oep, lvds_oen, lvds_odp, lvds_odn, lvds_ocp, lvds_ocn,
+ lvds_obp, lvds_obn, lvds_oap, lvds_oan, lvds_eep, lvds_een,
+ lvds_edp, lvds_edn, lvds_ecp, lvds_ecn, lvds_ebp, lvds_ebn,
+ lvds_eap, lvds_ean, sd0_d0, sd0_d1, sd0_d2, sd0_d3, sd1_d0,
+ sd1_d1, sd1_d2, sd1_d3, sd0_cmd, sd0_clk, sd1_cmd, sd1_clk,
+ spi0_sclk, spi0_ss, spi0_miso, spi0_mosi, uart0_rx, uart0_tx,
+ uart2_rx, uart2_tx, uart2_rtsb, uart2_ctsb, uart3_rx, uart3_tx,
+ uart3_rtsb, uart3_ctsb, uart4_rx, uart4_tx, i2c0_sclk, i2c0_sdata,
+ i2c1_sclk, i2c1_sdata, i2c2_sclk, i2c2_sdata, csi0_dn0, csi0_dp0,
+ csi0_dn1, csi0_dp1, csi0_cn, csi0_cp, csi0_dn2, csi0_dp2,
+ csi0_dn3, csi0_dp3, dsi_dp3, dsi_dn3, dsi_dp1, dsi_dn1, dsi_cp,
+ dsi_cn, dsi_dp0, dsi_dn0, dsi_dp2, dsi_dn2, sensor0_pclk,
+ csi1_dn0, csi1_dp0, csi1_dn1, csi1_dp1, csi1_cn, csi1_cp,
+ sensor0_ckout, nand0_d0, nand0_d1, nand0_d2, nand0_d3, nand0_d4,
+ nand0_d5, nand0_d6, nand0_d7, nand0_dqs, nand0_dqsn, nand0_ale,
+ nand0_cle, nand0_ceb0, nand0_ceb1, nand0_ceb2, nand0_ceb3,
+ nand1_d0, nand1_d1, nand1_d2, nand1_d3, nand1_d4, nand1_d5,
+ nand1_d6, nand1_d7, nand1_dqs, nand1_dqsn, nand1_ale, nand1_cle,
+ nand1_ceb0, nand1_ceb1, nand1_ceb2, nand1_ceb3, sgpio0, sgpio1,
+ sgpio2, sgpio3
+ ]
+
+ bias-bus-hold: true
+ bias-high-impedance: true
+
+ bias-pull-down:
+ type: boolean
+
+ bias-pull-up:
+ type: boolean
+
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+ slew-rate: true
+ drive-strength: true
+
+ oneOf:
+ - required:
+ - groups
+ - required:
+ - pins
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl: pinctrl@e01b0000 {
+ compatible = "actions,s900-pinctrl";
+ reg = <0xe01b0000 0x1000>;
+ clocks = <&cmu 1>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl 0 0 146>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart2-default {
+ pinmux {
+ groups = "lvds_oep_odn_mfp";
+ function = "uart2";
+ };
+
+ pinconf {
+ groups = "lvds_oep_odn_drv";
+ drive-strength = <12>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/airoha,an7583-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/airoha,an7583-pinctrl.yaml
new file mode 100644
index 000000000000..79910214d9b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/airoha,an7583-pinctrl.yaml
@@ -0,0 +1,402 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/airoha,an7583-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha AN7583 Pin Controller
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The Airoha's AN7583 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: airoha,an7583-pinctrl
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - interrupts
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+
+patternProperties:
+ '-pins$':
+ type: object
+
+ patternProperties:
+ '^mux(-|$)':
+ type: object
+
+ description:
+ pinmux configuration nodes.
+
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [pon, tod_1pps, sipo, mdio, uart, i2c, jtag, pcm, spi,
+ pcm_spi, i2s, emmc, pnand, pcie_reset, pwm, phy1_led0,
+ phy2_led0, phy3_led0, phy4_led0, phy1_led1, phy2_led1,
+ phy3_led1, phy4_led1]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+
+ required:
+ - function
+ - groups
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: pon
+ then:
+ properties:
+ groups:
+ enum: [pon]
+ - if:
+ properties:
+ function:
+ const: tod_1pps
+ then:
+ properties:
+ groups:
+ enum: [pon_tod_1pps, gsw_tod_1pps]
+ - if:
+ properties:
+ function:
+ const: sipo
+ then:
+ properties:
+ groups:
+ enum: [sipo, sipo_rclk]
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+ - if:
+ properties:
+ function:
+ const: uart
+ then:
+ properties:
+ groups:
+ items:
+ enum: [uart2, uart2_cts_rts, hsuart, hsuart_cts_rts,
+ uart4, uart5]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c1]
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag_udi, jtag_dfd]
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [pcm1, pcm2]
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [spi_quad, spi_cs1]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: pcm_spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pcm_spi, pcm_spi_int, pcm_spi_rst, pcm_spi_cs1,
+ pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4]
+ maxItems: 7
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+ - if:
+ properties:
+ function:
+ const: emmc
+ then:
+ properties:
+ groups:
+ enum: [emmc]
+ - if:
+ properties:
+ function:
+ const: pnand
+ then:
+ properties:
+ groups:
+ enum: [pnand]
+ - if:
+ properties:
+ function:
+ const: pcie_reset
+ then:
+ properties:
+ groups:
+ enum: [pcie_reset0, pcie_reset1]
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ enum: [gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6,
+ gpio7, gpio8, gpio9, gpio10, gpio11, gpio12, gpio13,
+ gpio14, gpio15, gpio16, gpio17, gpio18, gpio19,
+ gpio20, gpio21, gpio22, gpio23, gpio24, gpio25,
+ gpio26, gpio27, gpio28, gpio29, gpio30, gpio31,
+ gpio36, gpio37, gpio38, gpio39, gpio40, gpio41,
+ gpio42, gpio43, gpio44, gpio45, gpio46, gpio47]
+ - if:
+ properties:
+ function:
+ const: phy1_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio1, gpio2, gpio3, gpio4]
+ - if:
+ properties:
+ function:
+ const: phy2_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio1, gpio2, gpio3, gpio4]
+ - if:
+ properties:
+ function:
+ const: phy3_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio1, gpio2, gpio3, gpio4]
+ - if:
+ properties:
+ function:
+ const: phy4_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio1, gpio2, gpio3, gpio4]
+ - if:
+ properties:
+ function:
+ const: phy1_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio8, gpio9, gpio10, gpio11]
+ - if:
+ properties:
+ function:
+ const: phy2_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio8, gpio9, gpio10, gpio11]
+ - if:
+ properties:
+ function:
+ const: phy3_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio8, gpio9, gpio10, gpio11]
+ - if:
+ properties:
+ function:
+ const: phy4_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio8, gpio9, gpio10, gpio11]
+
+ additionalProperties: false
+
+ '^conf(-|$)':
+ type: object
+
+ description:
+ pinconf configuration nodes.
+
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ An array of strings. Each string contains the name of a pin.
+ items:
+ enum: [uart1_txd, uart1_rxd, i2c_scl, i2c_sda, spi_cs0, spi_clk,
+ spi_mosi, spi_miso, gpio0, gpio1, gpio2, gpio3, gpio4,
+ gpio5, gpio6, gpio7, gpio8, gpio9, gpio10, gpio11, gpio12,
+ gpio13, gpio14, gpio15, gpio16, gpio17, gpio18, gpio19,
+ gpio20, gpio21, gpio22, gpio23, gpio24, gpio25, gpio26,
+ gpio27, gpio28, gpio29, gpio30, gpio31, gpio32, gpio33,
+ gpio34, gpio35, gpio36, gpio37, gpio38, gpio39, gpio40,
+ gpio41, gpio42, gpio43, gpio44, gpio45, gpio46,
+ pcie_reset0, pcie_reset1, pcie_reset2]
+ minItems: 1
+ maxItems: 58
+
+ bias-disable: true
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ input-enable: true
+
+ output-enable: true
+
+ output-low: true
+
+ output-high: true
+
+ drive-open-drain: true
+
+ drive-strength:
+ description:
+ Selects the drive strength for MIO pins, in mA.
+ enum: [2, 4, 6, 8]
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl {
+ compatible = "airoha,an7583-pinctrl";
+
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ pcie1-rst-pins {
+ conf {
+ pins = "pcie_reset1";
+ drive-open-drain = <1>;
+ };
+ };
+
+ pwm-pins {
+ mux {
+ function = "pwm";
+ groups = "gpio18";
+ };
+ };
+
+ spi-pins {
+ mux {
+ function = "spi";
+ groups = "spi_quad", "spi_cs1";
+ };
+ };
+
+ uart2-pins {
+ mux {
+ function = "uart";
+ groups = "uart2", "uart2_cts_rts";
+ };
+ };
+
+ uar5-pins {
+ mux {
+ function = "uart";
+ groups = "uart5";
+ };
+ };
+
+ mmc-pins {
+ mux {
+ function = "emmc";
+ groups = "emmc";
+ };
+ };
+
+ mdio-pins {
+ mux {
+ function = "mdio";
+ groups = "mdio";
+ };
+
+ conf {
+ pins = "gpio2";
+ output-enable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml
new file mode 100644
index 000000000000..21fd4f1ba78b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml
@@ -0,0 +1,403 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/airoha,en7581-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 Pin Controller
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+description:
+ The Airoha's EN7581 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: airoha,en7581-pinctrl
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - interrupts
+ - gpio-controller
+ - "#gpio-cells"
+ - interrupt-controller
+ - "#interrupt-cells"
+
+patternProperties:
+ '-pins$':
+ type: object
+
+ patternProperties:
+ '^mux(-|$)':
+ type: object
+
+ description:
+ pinmux configuration nodes.
+
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [pon, tod_1pps, sipo, mdio, uart, i2c, jtag, pcm, spi,
+ pcm_spi, i2s, emmc, pnand, pcie_reset, pwm, phy1_led0,
+ phy2_led0, phy3_led0, phy4_led0, phy1_led1, phy2_led1,
+ phy3_led1, phy4_led1]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+
+ required:
+ - function
+ - groups
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: pon
+ then:
+ properties:
+ groups:
+ enum: [pon]
+ - if:
+ properties:
+ function:
+ const: tod_1pps
+ then:
+ properties:
+ groups:
+ enum: [pon_tod_1pps, gsw_tod_1pps]
+ - if:
+ properties:
+ function:
+ const: sipo
+ then:
+ properties:
+ groups:
+ enum: [sipo, sipo_rclk]
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+ - if:
+ properties:
+ function:
+ const: uart
+ then:
+ properties:
+ groups:
+ items:
+ enum: [uart2, uart2_cts_rts, hsuart, hsuart_cts_rts,
+ uart4, uart5]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c1]
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag_udi, jtag_dfd]
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [pcm1, pcm2]
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [spi_quad, spi_cs1]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: pcm_spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pcm_spi, pcm_spi_int, pcm_spi_rst, pcm_spi_cs1,
+ pcm_spi_cs2_p156, pcm_spi_cs2_p128, pcm_spi_cs3,
+ pcm_spi_cs4]
+ maxItems: 7
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+ - if:
+ properties:
+ function:
+ const: emmc
+ then:
+ properties:
+ groups:
+ enum: [emmc]
+ - if:
+ properties:
+ function:
+ const: pnand
+ then:
+ properties:
+ groups:
+ enum: [pnand]
+ - if:
+ properties:
+ function:
+ const: pcie_reset
+ then:
+ properties:
+ groups:
+ enum: [pcie_reset0, pcie_reset1, pcie_reset2]
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ enum: [gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6,
+ gpio7, gpio8, gpio9, gpio10, gpio11, gpio12, gpio13,
+ gpio14, gpio15, gpio16, gpio17, gpio18, gpio19,
+ gpio20, gpio21, gpio22, gpio23, gpio24, gpio25,
+ gpio26, gpio27, gpio28, gpio29, gpio30, gpio31,
+ gpio36, gpio37, gpio38, gpio39, gpio40, gpio41,
+ gpio42, gpio43, gpio44, gpio45, gpio46, gpio47]
+ - if:
+ properties:
+ function:
+ const: phy1_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio33, gpio34, gpio35, gpio42]
+ - if:
+ properties:
+ function:
+ const: phy2_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio33, gpio34, gpio35, gpio42]
+ - if:
+ properties:
+ function:
+ const: phy3_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio33, gpio34, gpio35, gpio42]
+ - if:
+ properties:
+ function:
+ const: phy4_led0
+ then:
+ properties:
+ groups:
+ enum: [gpio33, gpio34, gpio35, gpio42]
+ - if:
+ properties:
+ function:
+ const: phy1_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio43, gpio44, gpio45, gpio46]
+ - if:
+ properties:
+ function:
+ const: phy2_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio43, gpio44, gpio45, gpio46]
+ - if:
+ properties:
+ function:
+ const: phy3_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio43, gpio44, gpio45, gpio46]
+ - if:
+ properties:
+ function:
+ const: phy4_led1
+ then:
+ properties:
+ groups:
+ enum: [gpio43, gpio44, gpio45, gpio46]
+
+ additionalProperties: false
+
+ '^conf(-|$)':
+ type: object
+
+ description:
+ pinconf configuration nodes.
+
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ An array of strings. Each string contains the name of a pin.
+ items:
+ enum: [uart1_txd, uart1_rxd, i2c_scl, i2c_sda, spi_cs0, spi_clk,
+ spi_mosi, spi_miso, gpio0, gpio1, gpio2, gpio3, gpio4,
+ gpio5, gpio6, gpio7, gpio8, gpio9, gpio10, gpio11, gpio12,
+ gpio13, gpio14, gpio15, gpio16, gpio17, gpio18, gpio19,
+ gpio20, gpio21, gpio22, gpio23, gpio24, gpio25, gpio26,
+ gpio27, gpio28, gpio29, gpio30, gpio31, gpio32, gpio33,
+ gpio34, gpio35, gpio36, gpio37, gpio38, gpio39, gpio40,
+ gpio41, gpio42, gpio43, gpio44, gpio45, gpio46,
+ pcie_reset0, pcie_reset1, pcie_reset2]
+ minItems: 1
+ maxItems: 58
+
+ bias-disable: true
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ input-enable: true
+
+ output-enable: true
+
+ output-low: true
+
+ output-high: true
+
+ drive-open-drain: true
+
+ drive-strength:
+ description:
+ Selects the drive strength for MIO pins, in mA.
+ enum: [2, 4, 6, 8]
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl {
+ compatible = "airoha,en7581-pinctrl";
+
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ pcie1-rst-pins {
+ conf {
+ pins = "pcie_reset1";
+ drive-open-drain = <1>;
+ };
+ };
+
+ pwm-pins {
+ mux {
+ function = "pwm";
+ groups = "gpio18";
+ };
+ };
+
+ spi-pins {
+ mux {
+ function = "spi";
+ groups = "spi_quad", "spi_cs1";
+ };
+ };
+
+ uart2-pins {
+ mux {
+ function = "uart";
+ groups = "uart2", "uart2_cts_rts";
+ };
+ };
+
+ uar5-pins {
+ mux {
+ function = "uart";
+ groups = "uart5";
+ };
+ };
+
+ mmc-pins {
+ mux {
+ function = "emmc";
+ groups = "emmc";
+ };
+ };
+
+ mdio-pins {
+ mux {
+ function = "mdio";
+ groups = "mdio";
+ };
+
+ conf {
+ pins = "gpio2";
+ output-enable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
index d19d65c870aa..990b78765427 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/allwinner,sun4i-a10-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Pin Controller Device Tree Bindings
+title: Allwinner A10 Pin Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -44,6 +44,7 @@ properties:
- allwinner,sun8i-r40-pinctrl
- allwinner,sun8i-v3-pinctrl
- allwinner,sun8i-v3s-pinctrl
+ - allwinner,sun8i-v853-pinctrl
- allwinner,sun9i-a80-pinctrl
- allwinner,sun9i-a80-r-pinctrl
- allwinner,sun20i-d1-pinctrl
@@ -97,7 +98,7 @@ patternProperties:
# It's pretty scary, but the basic idea is that:
# - One node name can start with either s- or r- for PRCM nodes,
# - Then, the name itself can be any repetition of <string>- (to
- # accomodate with nodes like uart4-rts-cts-pins), where each
+ # accommodate with nodes like uart4-rts-cts-pins), where each
# string can be either starting with 'p' but in a string longer
# than 3, or something that doesn't start with 'p',
# - Then, the bank name is optional and will be between pa and pg,
@@ -142,7 +143,7 @@ allOf:
# boards are defining it at the moment so it would generate a lot of
# warnings.
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
- if:
not:
properties:
@@ -183,6 +184,18 @@ allOf:
properties:
compatible:
enum:
+ - allwinner,sun8i-v853-pinctrl
+
+ then:
+ properties:
+ interrupts:
+ minItems: 8
+ maxItems: 8
+
+ - if:
+ properties:
+ compatible:
+ enum:
- allwinner,sun20i-d1-pinctrl
then:
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml
new file mode 100644
index 000000000000..154e03da8ce9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/allwinner,sun55i-a523-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A523 Pin Controller
+
+maintainers:
+ - Andre Przywara <andre.przywara@arm.com>
+
+properties:
+ "#gpio-cells":
+ const: 3
+ description:
+ GPIO consumers must use three arguments, first the number of the
+ bank, then the pin number inside that bank, and finally the GPIO
+ flags.
+
+ "#interrupt-cells":
+ const: 3
+ description:
+ Interrupts consumers must use three arguments, first the number
+ of the bank, then the pin number inside that bank, and finally
+ the interrupts flags.
+
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-pinctrl
+ - allwinner,sun55i-a523-r-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 2
+ maxItems: 10
+ description:
+ One interrupt per external interrupt bank supported on the
+ controller, sorted by bank number ascending order.
+
+ clocks:
+ items:
+ - description: Bus Clock
+ - description: High Frequency Oscillator
+ - description: Low Frequency Oscillator
+
+ clock-names:
+ items:
+ - const: apb
+ - const: hosc
+ - const: losc
+
+ gpio-controller: true
+ interrupt-controller: true
+ gpio-line-names: true
+
+ input-debounce:
+ description:
+ Debouncing periods in microseconds, one period per interrupt
+ bank found in the controller
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 10
+
+patternProperties:
+ # It's pretty scary, but the basic idea is that:
+ # - One node name can start with either s- or r- for PRCM nodes,
+ # - Then, the name itself can be any repetition of <string>- (to
+ # accommodate with nodes like uart4-rts-cts-pins), where each
+ # string can be either starting with 'p' but in a string longer
+ # than 3, or something that doesn't start with 'p',
+ # - Then, the bank name is optional and will be between pa and pm.
+ # Some pins groups that have several options will have the pin
+ # numbers then,
+ # - Finally, the name will end with either -pin or pins.
+
+ "^([rs]-)?(([a-z0-9]{3,}|[a-oq-z][a-z0-9]*?)?-)+?(p[a-m][0-9]*?-)??pins?$":
+ type: object
+
+ properties:
+ pins: true
+ function: true
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+
+ drive-strength:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [10, 20, 30, 40]
+
+ allwinner,pinmux:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Pinmux selector value, for each pin. Almost every time this value
+ is the same for all pins, so any array shorter than the number of
+ pins will repeat the last value, to allow just specifying a single
+ cell, for all cells.
+
+ required:
+ - pins
+ - allwinner,pinmux
+ - function
+
+ additionalProperties: false
+
+ "^vcc-p[a-m]-supply$":
+ description:
+ Power supplies for pin banks.
+
+required:
+ - "#gpio-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - gpio-controller
+ - "#interrupt-cells"
+ - interrupts
+ - interrupt-controller
+
+allOf:
+ - $ref: pinctrl.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-pinctrl
+
+ then:
+ properties:
+ interrupts:
+ minItems: 10
+ maxItems: 10
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,sun55i-a523-r-pinctrl
+
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ r_pio: pinctrl@7022000 {
+ compatible = "allwinner,sun55i-a523-r-pinctrl";
+ reg = <0x7022000 0x800>;
+ interrupts = <0 159 4>, <0 161 4>;
+ clocks = <&r_ccu 1>, <&osc24M>, <&osc32k>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ r_i2c_pins: r-i2c-pins {
+ pins = "PL0", "PL1";
+ allwinner,pinmux = <2>;
+ function = "r_i2c0";
+ bias-pull-up;
+ };
+
+ r_spi_pins: r-spi-pins {
+ pins = "PL11" ,"PL12", "PL13";
+ allwinner,pinmux = <6>;
+ function = "r_spi";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml
new file mode 100644
index 000000000000..d9e0b2c48e84
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-a1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson A1 pinmux controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: amlogic,meson-pinctrl-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,c3-periphs-pinctrl
+ - amlogic,t7-periphs-pinctrl
+ - amlogic,meson-a1-periphs-pinctrl
+ - amlogic,meson-s4-periphs-pinctrl
+
+required:
+ - compatible
+
+patternProperties:
+ "^bank@[0-9a-f]+$":
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: mux
+ - const: gpio
+
+ gpio-line-names:
+ minItems: 62 # A1
+ maxItems: 82 # S4
+
+unevaluatedProperties:
+ type: object
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
+
+examples:
+ - |
+ periphs_pinctrl: pinctrl {
+ compatible = "amlogic,meson-a1-periphs-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ bank@400 {
+ reg = <0x0400 0x003c>,
+ <0x0480 0x0118>;
+ reg-names = "mux", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&periphs_pinctrl 0 0 62>;
+ };
+
+ cec_ao_a_h_pins: cec_ao_a_h {
+ mux {
+ groups = "cec_ao_a_h";
+ function = "cec_ao_a_h";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml
new file mode 100644
index 000000000000..e707c222a07f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson pinmux controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ ranges: true
+
+ "#address-cells":
+ enum: [1, 2]
+
+ "#size-cells":
+ enum: [1, 2]
+
+required:
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: true
+
+$defs:
+ meson-gpio:
+ type: object
+
+ properties:
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ patternProperties:
+ "^.+-hog(-[0-9]+)?$":
+ type: object
+
+ required:
+ - gpio-hog
+
+ required:
+ - reg
+ - reg-names
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+
+ meson-pins:
+ type: object
+ additionalProperties:
+ type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml
new file mode 100644
index 000000000000..108719bde0d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson G12 AOBUS pinmux controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: amlogic,meson-pinctrl-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-aobus-pinctrl
+
+required:
+ - compatible
+
+patternProperties:
+ "^bank@[0-9a-f]+$":
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: mux
+ - const: ds
+ - const: gpio
+
+ gpio-line-names:
+ maxItems: 15
+
+unevaluatedProperties:
+ type: object
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
+
+examples:
+ - |
+ ao_pinctrl: pinctrl {
+ compatible = "amlogic,meson-g12a-aobus-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ bank@14 {
+ reg = <0x14 0x8>,
+ <0x1c 0x8>,
+ <0x24 0x14>;
+ reg-names = "mux", "ds", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ao_pinctrl 0 0 15>;
+ };
+
+ cec_ao_a_h_pins: cec_ao_a_h {
+ mux {
+ groups = "cec_ao_a_h";
+ function = "cec_ao_a_h";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml
new file mode 100644
index 000000000000..dc277f2e2edf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson G12 PERIPHS pinmux controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: amlogic,meson-pinctrl-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-periphs-pinctrl
+
+required:
+ - compatible
+
+patternProperties:
+ "^bank@[0-9a-f]+$":
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 5
+
+ reg-names:
+ items:
+ - const: gpio
+ - const: pull
+ - const: pull-enable
+ - const: mux
+ - const: ds
+
+ gpio-line-names:
+ maxItems: 85
+
+unevaluatedProperties:
+ type: object
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
+
+examples:
+ - |
+ periphs_pinctrl: pinctrl {
+ compatible = "amlogic,meson-g12a-periphs-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ bank@40 {
+ reg = <0x40 0x4c>,
+ <0xe8 0x18>,
+ <0x120 0x18>,
+ <0x2c0 0x40>,
+ <0x340 0x1c>;
+ reg-names = "gpio", "pull", "pull-enable", "mux", "ds";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&periphs_pinctrl 0 0 86>;
+ };
+
+ cec_ao_a_h_pins: cec_ao_a_h {
+ mux {
+ groups = "cec_ao_a_h";
+ function = "cec_ao_a_h";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml
new file mode 100644
index 000000000000..add83c676327
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,meson8-pinctrl-aobus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson8 AOBUS pinmux controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: amlogic,meson-pinctrl-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson8-aobus-pinctrl
+ - amlogic,meson8b-aobus-pinctrl
+ - amlogic,meson-gxbb-aobus-pinctrl
+ - amlogic,meson-gxl-aobus-pinctrl
+ - amlogic,meson-axg-aobus-pinctrl
+ - items:
+ - const: amlogic,meson8m2-aobus-pinctrl
+ - const: amlogic,meson8-aobus-pinctrl
+
+required:
+ - compatible
+
+patternProperties:
+ "^bank@[0-9a-f]+$":
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: mux
+ - const: pull
+ - const: gpio
+
+ gpio-line-names:
+ minItems: 11 # GXL
+ maxItems: 16 # Meson8
+
+unevaluatedProperties:
+ type: object
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
+
+examples:
+ - |
+ pinctrl_aobus: pinctrl {
+ compatible = "amlogic,meson8-aobus-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ bank@14 {
+ reg = <0x14 0x4>,
+ <0x2c 0x4>,
+ <0x24 0x8>;
+ reg-names = "mux", "pull", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_aobus 0 0 16>;
+ };
+
+ cec_ao_a_h_pins: cec_ao_a_h {
+ mux {
+ groups = "cec_ao_a_h";
+ function = "cec_ao_a_h";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml
new file mode 100644
index 000000000000..c954761e0150
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,meson8-pinctrl-cbus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson8 CBUS pinmux controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: amlogic,meson-pinctrl-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson8-cbus-pinctrl
+ - amlogic,meson8b-cbus-pinctrl
+ - amlogic,meson-gxbb-periphs-pinctrl
+ - amlogic,meson-gxl-periphs-pinctrl
+ - amlogic,meson-axg-periphs-pinctrl
+ - items:
+ - const: amlogic,meson8m2-cbus-pinctrl
+ - const: amlogic,meson8-cbus-pinctrl
+
+required:
+ - compatible
+
+patternProperties:
+ "^bank@[0-9a-f]+$":
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio
+
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: mux
+ - const: pull
+ - const: pull-enable
+ - const: gpio
+
+ gpio-line-names:
+ minItems: 83 # Meson8b
+ maxItems: 120 # Meson8
+
+unevaluatedProperties:
+ type: object
+ $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins
+
+examples:
+ - |
+ pinctrl_cbus: pinctrl {
+ compatible = "amlogic,meson8-cbus-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ bank@80b0 {
+ reg = <0x80b0 0x28>,
+ <0x80e8 0x18>,
+ <0x8120 0x18>,
+ <0x8030 0x30>;
+ reg-names = "mux", "pull", "pull-enable", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_cbus 0 0 120>;
+ };
+
+ cec_ao_a_h_pins: cec_ao_a_h {
+ mux {
+ groups = "cec_ao_a_h";
+ function = "cec_ao_a_h";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
new file mode 100644
index 000000000000..6ba66c2033b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/amlogic,pinctrl-a4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic pinmux controller
+
+maintainers:
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,pinctrl-a4
+ - amlogic,pinctrl-s6
+ - amlogic,pinctrl-s7
+ - items:
+ - enum:
+ - amlogic,pinctrl-a5
+ - const: amlogic,pinctrl-a4
+ - items:
+ - enum:
+ - amlogic,pinctrl-s7d
+ - const: amlogic,pinctrl-s7
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges: true
+
+patternProperties:
+ "^gpio@[0-9a-f]+$":
+ type: object
+
+ additionalProperties: false
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: pin config register
+ - description: pin mux setting register (some special pin fixed function)
+ - description: pin drive strength register (optional)
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: gpio
+ - const: mux
+ - const: ds
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ required:
+ - reg
+ - reg-names
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+
+ "^func-[0-9a-z-]+$":
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^group-[0-9a-z-]+$":
+ type: object
+ unevaluatedProperties: false
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/amlogic,pinctrl.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ periphs_pinctrl: pinctrl {
+ compatible = "amlogic,pinctrl-a4";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gpio@4240 {
+ reg = <0 0x4240 0 0x40>, <0 0x4000 0 0x8>;
+ reg-names = "gpio", "mux";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&periphs_pinctrl 0 8 10>;
+ };
+
+ func-uart-b {
+ group-default {
+ pinmux = <AML_PINMUX(AMLOGIC_GPIO_B, 1, 4)>;
+ bias-pull-up;
+ drive-strength-microamp = <4000>;
+ };
+
+ group-pins1 {
+ pinmux = <AML_PINMUX(AMLOGIC_GPIO_B, 5, 2)>;
+ bias-pull-up;
+ drive-strength-microamp = <4000>;
+ };
+ };
+
+ func-uart-c {
+ group-default {
+ pinmux = <AML_PINMUX(AMLOGIC_GPIO_B, 3, 1)>,
+ <AML_PINMUX(AMLOGIC_GPIO_B, 2, 1)>;
+ bias-pull-up;
+ drive-strength-microamp = <4000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
index d3b11351ca45..665ec79a69f1 100644
--- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
@@ -16,11 +16,22 @@ description: |
properties:
compatible:
- items:
- - enum:
- - apple,t8103-pinctrl
- - apple,t6000-pinctrl
- - const: apple,pinctrl
+ oneOf:
+ - items:
+ - const: apple,t6020-pinctrl
+ - const: apple,t8103-pinctrl
+ - items:
+ # Do not add additional SoC to this list.
+ - enum:
+ - apple,s5l8960x-pinctrl
+ - apple,t7000-pinctrl
+ - apple,s8000-pinctrl
+ - apple,t8010-pinctrl
+ - apple,t8015-pinctrl
+ - apple,t8103-pinctrl
+ - apple,t8112-pinctrl
+ - apple,t6000-pinctrl
+ - const: apple,pinctrl
reg:
maxItems: 1
@@ -73,7 +84,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
index d3a8911728d0..23ed9a8b6689 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -25,44 +25,187 @@ properties:
reg:
maxItems: 2
-patternProperties:
- '^.*$':
- if:
- type: object
- then:
- patternProperties:
- "^function|groups$":
- $ref: "/schemas/types.yaml#/definitions/string"
- enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
- ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT,
- EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0,
- GPIE2, GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4,
- I2C5, I2C6, I2C7, I2C8, I2C9, LPCPD, LPCPME, LPCRST, LPCSMI, MAC1LINK,
- MAC2LINK, MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2,
- NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4,
- NDTS4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, OSCCLK, PWM0,
- PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1,
- RMII2, ROM16, ROM8, ROMCS1, ROMCS2, ROMCS3, ROMCS4, RXD1, RXD2, RXD3,
- RXD4, SALT1, SALT2, SALT3, SALT4, SD1, SD2, SGPMCK, SGPMI, SGPMLD,
- SGPMO, SGPSCK, SGPSI0, SGPSI1, SGPSLD, SIOONCTRL, SIOPBI, SIOPBO,
- SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1DEBUG, SPI1PASSTHRU,
- SPICS1, TIMER3, TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2,
- TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM,
- VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2]
+additionalProperties:
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins: true
+ bias-disable: true
+
+ patternProperties:
+ "^function|groups$":
+ enum:
+ - ACPI
+ - ADC0
+ - ADC1
+ - ADC10
+ - ADC11
+ - ADC12
+ - ADC13
+ - ADC14
+ - ADC15
+ - ADC2
+ - ADC3
+ - ADC4
+ - ADC5
+ - ADC6
+ - ADC7
+ - ADC8
+ - ADC9
+ - BMCINT
+ - DDCCLK
+ - DDCDAT
+ - EXTRST
+ - FLACK
+ - FLBUSY
+ - FLWP
+ - GPID
+ - GPID0
+ - GPID2
+ - GPID4
+ - GPID6
+ - GPIE0
+ - GPIE2
+ - GPIE4
+ - GPIE6
+ - I2C10
+ - I2C11
+ - I2C12
+ - I2C13
+ - I2C14
+ - I2C3
+ - I2C4
+ - I2C5
+ - I2C6
+ - I2C7
+ - I2C8
+ - I2C9
+ - LPCPD
+ - LPCPME
+ - LPCRST
+ - LPCSMI
+ - MAC1LINK
+ - MAC2LINK
+ - MDIO1
+ - MDIO2
+ - NCTS1
+ - NCTS2
+ - NCTS3
+ - NCTS4
+ - NDCD1
+ - NDCD2
+ - NDCD3
+ - NDCD4
+ - NDSR1
+ - NDSR2
+ - NDSR3
+ - NDSR4
+ - NDTR1
+ - NDTR2
+ - NDTR3
+ - NDTR4
+ - NDTS4
+ - NRI1
+ - NRI2
+ - NRI3
+ - NRI4
+ - NRTS1
+ - NRTS2
+ - NRTS3
+ - OSCCLK
+ - PWM0
+ - PWM1
+ - PWM2
+ - PWM3
+ - PWM4
+ - PWM5
+ - PWM6
+ - PWM7
+ - RGMII1
+ - RGMII2
+ - RMII1
+ - RMII2
+ - ROM16
+ - ROM8
+ - ROMCS1
+ - ROMCS2
+ - ROMCS3
+ - ROMCS4
+ - RXD1
+ - RXD2
+ - RXD3
+ - RXD4
+ - SALT1
+ - SALT2
+ - SALT3
+ - SALT4
+ - SD1
+ - SD2
+ - SGPMCK
+ - SGPMI
+ - SGPMLD
+ - SGPMO
+ - SGPSCK
+ - SGPSI0
+ - SGPSI1
+ - SGPSLD
+ - SIOONCTRL
+ - SIOPBI
+ - SIOPBO
+ - SIOPWREQ
+ - SIOPWRGD
+ - SIOS3
+ - SIOS5
+ - SIOSCI
+ - SPI1
+ - SPI1DEBUG
+ - SPI1PASSTHRU
+ - SPICS1
+ - TIMER3
+ - TIMER4
+ - TIMER5
+ - TIMER6
+ - TIMER7
+ - TIMER8
+ - TXD1
+ - TXD2
+ - TXD3
+ - TXD4
+ - UART6
+ - USB11D1
+ - USB11H2
+ - USB2D1
+ - USB2H1
+ - USBCKI
+ - VGABIOS_ROM
+ - VGAHS
+ - VGAVS
+ - VPI18
+ - VPI24
+ - VPI30
+ - VPO12
+ - VPO24
+ - WDTRST1
+ - WDTRST2
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
-additionalProperties: false
-
examples:
- |
syscon: scu@1e6e2000 {
compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
reg = <0x1e6e2000 0x1a8>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1e6e2000 0x1000>;
pinctrl: pinctrl {
compatible = "aspeed,ast2400-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
index 5d2c1b1fb7fd..35bd0e1eadae 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
@@ -35,44 +35,194 @@ properties:
description: |
A cell of phandles to external controller nodes:
0: compatible with "aspeed,ast2500-gfx", "syscon"
- 1: compatible with "aspeed,ast2500-lhc", "syscon"
-
-patternProperties:
- '^.*$':
- if:
- type: object
- then:
- patternProperties:
- "^function|groups$":
- $ref: "/schemas/types.yaml#/definitions/string"
- enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
- ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT,
- ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2,
- GPIE4, GPIE6, I2C10, I2C11, I2C12, I2C13, I2C14, I2C3, I2C4, I2C5,
- I2C6, I2C7, I2C8, I2C9, LAD0, LAD1, LAD2, LAD3, LCLK, LFRAME, LPCHC,
- LPCPD, LPCPLUS, LPCPME, LPCRST, LPCSMI, LSIRQ, MAC1LINK, MAC2LINK,
- MDIO1, MDIO2, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4,
- NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2,
- NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PNOR, PWM0,
- PWM1, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, RGMII1, RGMII2, RMII1,
- RMII2, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13,
- SALT14, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, SALT9, SCL1,
- SCL2, SD1, SD2, SDA1, SDA2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO,
- SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1CS1, SPI1DEBUG,
- SPI1PASSTHRU, SPI2CK, SPI2CS0, SPI2CS1, SPI2MISO, SPI2MOSI, TIMER3,
- TIMER4, TIMER5, TIMER6, TIMER7, TIMER8, TXD1, TXD2, TXD3, TXD4, UART6,
- USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS,
- VGAVS, VPI24, VPO, WDTRST1, WDTRST2]
+ 1: compatible with "aspeed,ast2500-lpc", "syscon"
+
+additionalProperties:
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins: true
+ bias-disable: true
+
+ patternProperties:
+ "^function|groups$":
+ enum:
+ - ACPI
+ - ADC0
+ - ADC1
+ - ADC10
+ - ADC11
+ - ADC12
+ - ADC13
+ - ADC14
+ - ADC15
+ - ADC2
+ - ADC3
+ - ADC4
+ - ADC5
+ - ADC6
+ - ADC7
+ - ADC8
+ - ADC9
+ - BMCINT
+ - DDCCLK
+ - DDCDAT
+ - ESPI
+ - FWSPICS1
+ - FWSPICS2
+ - GPID0
+ - GPID2
+ - GPID4
+ - GPID6
+ - GPIE0
+ - GPIE2
+ - GPIE4
+ - GPIE6
+ - I2C10
+ - I2C11
+ - I2C12
+ - I2C13
+ - I2C14
+ - I2C3
+ - I2C4
+ - I2C5
+ - I2C6
+ - I2C7
+ - I2C8
+ - I2C9
+ - LAD0
+ - LAD1
+ - LAD2
+ - LAD3
+ - LCLK
+ - LFRAME
+ - LPCHC
+ - LPCPD
+ - LPCPLUS
+ - LPCPME
+ - LPCRST
+ - LPCSMI
+ - LSIRQ
+ - MAC1LINK
+ - MAC2LINK
+ - MDIO1
+ - MDIO2
+ - NCTS1
+ - NCTS2
+ - NCTS3
+ - NCTS4
+ - NDCD1
+ - NDCD2
+ - NDCD3
+ - NDCD4
+ - NDSR1
+ - NDSR2
+ - NDSR3
+ - NDSR4
+ - NDTR1
+ - NDTR2
+ - NDTR3
+ - NDTR4
+ - NRI1
+ - NRI2
+ - NRI3
+ - NRI4
+ - NRTS1
+ - NRTS2
+ - NRTS3
+ - NRTS4
+ - OSCCLK
+ - PEWAKE
+ - PNOR
+ - PWM0
+ - PWM1
+ - PWM2
+ - PWM3
+ - PWM4
+ - PWM5
+ - PWM6
+ - PWM7
+ - RGMII1
+ - RGMII2
+ - RMII1
+ - RMII2
+ - RXD1
+ - RXD2
+ - RXD3
+ - RXD4
+ - SALT1
+ - SALT10
+ - SALT11
+ - SALT12
+ - SALT13
+ - SALT14
+ - SALT2
+ - SALT3
+ - SALT4
+ - SALT5
+ - SALT6
+ - SALT7
+ - SALT8
+ - SALT9
+ - SCL1
+ - SCL2
+ - SD1
+ - SD2
+ - SDA1
+ - SDA2
+ - SGPM
+ - SGPS1
+ - SGPS2
+ - SIOONCTRL
+ - SIOPBI
+ - SIOPBO
+ - SIOPWREQ
+ - SIOPWRGD
+ - SIOS3
+ - SIOS5
+ - SIOSCI
+ - SPI1
+ - SPI1CS1
+ - SPI1DEBUG
+ - SPI1PASSTHRU
+ - SPI2CK
+ - SPI2CS0
+ - SPI2CS1
+ - SPI2MISO
+ - SPI2MOSI
+ - TIMER3
+ - TIMER4
+ - TIMER5
+ - TIMER6
+ - TIMER7
+ - TIMER8
+ - TXD1
+ - TXD2
+ - TXD3
+ - TXD4
+ - UART6
+ - USB11BHID
+ - USB2AD
+ - USB2AH
+ - USB2BD
+ - USB2BH
+ - USBCKI
+ - VGABIOSROM
+ - VGAHS
+ - VGAVS
+ - VPI24
+ - VPO
+ - WDTRST1
+ - WDTRST2
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
- aspeed,external-nodes
-additionalProperties: false
-
examples:
- |
#include <dt-bindings/clock/aspeed-clock.h>
@@ -82,6 +232,10 @@ examples:
#clock-cells = <1>;
#reset-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1e6e2000 0x1000>;
+
pinctrl: pinctrl {
compatible = "aspeed,ast2500-pinctrl";
aspeed,external-nodes = <&gfx>, <&lhc>;
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
index e92686d2f062..af8979af9b45 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
@@ -19,83 +19,507 @@ description: |+
Refer to the bindings described in
Documentation/devicetree/bindings/mfd/syscon.yaml
+ Note: According to the NCSI specification, the reference clock output pin
+ (RMIIXRCLKO) is not required on the management controller side. To optimize
+ pin usage, add "NCSI" pin groups that are equivalent to the RMII pin groups,
+ but without the RMIIXRCLKO pin.
+
properties:
compatible:
const: aspeed,ast2600-pinctrl
-patternProperties:
- '^.*$':
- if:
- type: object
- then:
- properties:
- function:
- $ref: "/schemas/types.yaml#/definitions/string"
- enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2,
- ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT,
- FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3,
- GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2, GPIU3, GPIU4, GPIU5,
- GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16,
- I2C2, I2C3, I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5,
- I3C6, JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ,
- MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4,
- NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2,
- NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4,
- NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11,
- PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7, PWM8,
- PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4,
- RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14,
- SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8,
- SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO,
- SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2,
- SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14,
- TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0,
- THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12,
- UART13, UART6, UART7, UART8, UART9, USBAD, USBADP, USB2AH, USB2AHP,
- USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4 ]
-
- groups:
- $ref: "/schemas/types.yaml#/definitions/string"
- enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2,
- ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4,
- EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP,
- GPIT0, GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1,
- GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1, I2C10,
- I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5,
- I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ,
- LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2, MACLINK3,
- MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2, NCTS3, NCTS4,
- NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2,
- NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4,
- OSCCLK, PEWAKE, PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0,
- PWM12G1, PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2,
- PWM3, PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1,
- QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4,
- RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1,
- SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0,
- SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6,
- SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2,
- SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1,
- SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11,
- TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6,
- TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3,
- TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6,
- UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2,
- WDTRST3, WDTRST4]
+additionalProperties:
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ enum:
+ - ADC0
+ - ADC1
+ - ADC10
+ - ADC11
+ - ADC12
+ - ADC13
+ - ADC14
+ - ADC15
+ - ADC2
+ - ADC3
+ - ADC4
+ - ADC5
+ - ADC6
+ - ADC7
+ - ADC8
+ - ADC9
+ - BMCINT
+ - EMMC
+ - ESPI
+ - ESPIALT
+ - FSI1
+ - FSI2
+ - FWQSPI
+ - FWSPIABR
+ - FWSPID
+ - FWSPIWP
+ - GPIT0
+ - GPIT1
+ - GPIT2
+ - GPIT3
+ - GPIT4
+ - GPIT5
+ - GPIT6
+ - GPIT7
+ - GPIU0
+ - GPIU1
+ - GPIU2
+ - GPIU3
+ - GPIU4
+ - GPIU5
+ - GPIU6
+ - GPIU7
+ - I2C1
+ - I2C10
+ - I2C11
+ - I2C12
+ - I2C13
+ - I2C14
+ - I2C15
+ - I2C16
+ - I2C2
+ - I2C3
+ - I2C4
+ - I2C5
+ - I2C6
+ - I2C7
+ - I2C8
+ - I2C9
+ - I3C1
+ - I3C2
+ - I3C3
+ - I3C4
+ - I3C5
+ - I3C6
+ - JTAGM
+ - LHPD
+ - LHSIRQ
+ - LPC
+ - LPCHC
+ - LPCPD
+ - LPCPME
+ - LPCSMI
+ - LSIRQ
+ - MACLINK1
+ - MACLINK2
+ - MACLINK3
+ - MACLINK4
+ - MDIO1
+ - MDIO2
+ - MDIO3
+ - MDIO4
+ - NCTS1
+ - NCTS2
+ - NCTS3
+ - NCTS4
+ - NDCD1
+ - NDCD2
+ - NDCD3
+ - NDCD4
+ - NDSR1
+ - NDSR2
+ - NDSR3
+ - NDSR4
+ - NDTR1
+ - NDTR2
+ - NDTR3
+ - NDTR4
+ - NRI1
+ - NRI2
+ - NRI3
+ - NRI4
+ - NRTS1
+ - NRTS2
+ - NRTS3
+ - NRTS4
+ - OSCCLK
+ - PCIERC1
+ - PEWAKE
+ - PWM0
+ - PWM1
+ - PWM10
+ - PWM11
+ - PWM12
+ - PWM13
+ - PWM14
+ - PWM15
+ - PWM2
+ - PWM3
+ - PWM4
+ - PWM5
+ - PWM6
+ - PWM7
+ - PWM8
+ - PWM9
+ - RGMII1
+ - RGMII2
+ - RGMII3
+ - RGMII4
+ - RMII1
+ - RMII2
+ - RMII3
+ - RMII4
+ - RXD1
+ - RXD2
+ - RXD3
+ - RXD4
+ - SALT1
+ - SALT10
+ - SALT11
+ - SALT12
+ - SALT13
+ - SALT14
+ - SALT15
+ - SALT16
+ - SALT2
+ - SALT3
+ - SALT4
+ - SALT5
+ - SALT6
+ - SALT7
+ - SALT8
+ - SALT9
+ - SD1
+ - SD2
+ - SGPM1
+ - SGPM2
+ - SGPS1
+ - SGPS2
+ - SIOONCTRL
+ - SIOPBI
+ - SIOPBO
+ - SIOPWREQ
+ - SIOPWRGD
+ - SIOS3
+ - SIOS5
+ - SIOSCI
+ - SPI1
+ - SPI1ABR
+ - SPI1CS1
+ - SPI1WP
+ - SPI2
+ - SPI2CS1
+ - SPI2CS2
+ - TACH0
+ - TACH1
+ - TACH10
+ - TACH11
+ - TACH12
+ - TACH13
+ - TACH14
+ - TACH15
+ - TACH2
+ - TACH3
+ - TACH4
+ - TACH5
+ - TACH6
+ - TACH7
+ - TACH8
+ - TACH9
+ - THRU0
+ - THRU1
+ - THRU2
+ - THRU3
+ - TXD1
+ - TXD2
+ - TXD3
+ - TXD4
+ - UART10
+ - UART11
+ - UART12
+ - UART13
+ - UART6
+ - UART7
+ - UART8
+ - UART9
+ - USB11BHID
+ - USB2AD
+ - USB2AH
+ - USB2AHP
+ - USB2BD
+ - USB2BH
+ - USBAD
+ - USBADP
+ - VB
+ - VGAHS
+ - VGAVS
+ - WDTRST1
+ - WDTRST2
+ - WDTRST3
+ - WDTRST4
+
+ groups:
+ enum:
+ - ADC0
+ - ADC1
+ - ADC10
+ - ADC11
+ - ADC12
+ - ADC13
+ - ADC14
+ - ADC15
+ - ADC2
+ - ADC3
+ - ADC4
+ - ADC5
+ - ADC6
+ - ADC7
+ - ADC8
+ - ADC9
+ - BMCINT
+ - EMMCG1
+ - EMMCG4
+ - EMMCG8
+ - ESPI
+ - ESPIALT
+ - FSI1
+ - FSI2
+ - FWQSPI
+ - FWSPIABR
+ - FWSPID
+ - FWSPIWP
+ - GPIT0
+ - GPIT1
+ - GPIT2
+ - GPIT3
+ - GPIT4
+ - GPIT5
+ - GPIT6
+ - GPIT7
+ - GPIU0
+ - GPIU1
+ - GPIU2
+ - GPIU3
+ - GPIU4
+ - GPIU5
+ - GPIU6
+ - GPIU7
+ - HVI3C3
+ - HVI3C4
+ - I2C1
+ - I2C10
+ - I2C11
+ - I2C12
+ - I2C13
+ - I2C14
+ - I2C15
+ - I2C16
+ - I2C2
+ - I2C3
+ - I2C4
+ - I2C5
+ - I2C6
+ - I2C7
+ - I2C8
+ - I2C9
+ - I3C1
+ - I3C2
+ - I3C3
+ - I3C4
+ - I3C5
+ - I3C6
+ - JTAGM
+ - LHPD
+ - LHSIRQ
+ - LPC
+ - LPCHC
+ - LPCPD
+ - LPCPME
+ - LPCSMI
+ - LSIRQ
+ - MACLINK1
+ - MACLINK2
+ - MACLINK3
+ - MACLINK4
+ - MDIO1
+ - MDIO2
+ - MDIO3
+ - MDIO4
+ - NCSI3
+ - NCSI4
+ - NCTS1
+ - NCTS2
+ - NCTS3
+ - NCTS4
+ - NDCD1
+ - NDCD2
+ - NDCD3
+ - NDCD4
+ - NDSR1
+ - NDSR2
+ - NDSR3
+ - NDSR4
+ - NDTR1
+ - NDTR2
+ - NDTR3
+ - NDTR4
+ - NRI1
+ - NRI2
+ - NRI3
+ - NRI4
+ - NRTS1
+ - NRTS2
+ - NRTS3
+ - NRTS4
+ - OSCCLK
+ - PCIERC1
+ - PEWAKE
+ - PWM0
+ - PWM1
+ - PWM10G0
+ - PWM10G1
+ - PWM11G0
+ - PWM11G1
+ - PWM12G0
+ - PWM12G1
+ - PWM13G0
+ - PWM13G1
+ - PWM14G0
+ - PWM14G1
+ - PWM15G0
+ - PWM15G1
+ - PWM2
+ - PWM3
+ - PWM4
+ - PWM5
+ - PWM6
+ - PWM7
+ - PWM8G0
+ - PWM8G1
+ - PWM9G0
+ - PWM9G1
+ - QSPI1
+ - QSPI2
+ - RGMII1
+ - RGMII2
+ - RGMII3
+ - RGMII4
+ - RMII1
+ - RMII2
+ - RMII3
+ - RMII4
+ - RXD1
+ - RXD2
+ - RXD3
+ - RXD4
+ - SALT1
+ - SALT10G0
+ - SALT10G1
+ - SALT11G0
+ - SALT11G1
+ - SALT12G0
+ - SALT12G1
+ - SALT13G0
+ - SALT13G1
+ - SALT14G0
+ - SALT14G1
+ - SALT15G0
+ - SALT15G1
+ - SALT16G0
+ - SALT16G1
+ - SALT2
+ - SALT3
+ - SALT4
+ - SALT5
+ - SALT6
+ - SALT7
+ - SALT8
+ - SALT9G0
+ - SALT9G1
+ - SD1
+ - SD2
+ - SD3
+ - SGPM1
+ - SGPM2
+ - SGPS1
+ - SGPS2
+ - SIOONCTRL
+ - SIOPBI
+ - SIOPBO
+ - SIOPWREQ
+ - SIOPWRGD
+ - SIOS3
+ - SIOS5
+ - SIOSCI
+ - SPI1
+ - SPI1ABR
+ - SPI1CS1
+ - SPI1WP
+ - SPI2
+ - SPI2CS1
+ - SPI2CS2
+ - TACH0
+ - TACH1
+ - TACH10
+ - TACH11
+ - TACH12
+ - TACH13
+ - TACH14
+ - TACH15
+ - TACH2
+ - TACH3
+ - TACH4
+ - TACH5
+ - TACH6
+ - TACH7
+ - TACH8
+ - TACH9
+ - THRU0
+ - THRU1
+ - THRU2
+ - THRU3
+ - TXD1
+ - TXD2
+ - TXD3
+ - TXD4
+ - UART10
+ - UART11
+ - UART12G0
+ - UART12G1
+ - UART13G0
+ - UART13G1
+ - UART6
+ - UART7
+ - UART8
+ - UART9
+ - USBA
+ - USBB
+ - VB
+ - VGAHS
+ - VGAVS
+ - WDTRST1
+ - WDTRST2
+ - WDTRST3
+ - WDTRST4
+
+ pins: true
+ bias-disable: true
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
-additionalProperties: false
-
examples:
- |
syscon: scu@1e6e2000 {
compatible = "aspeed,ast2600-scu", "syscon", "simple-mfd";
reg = <0x1e6e2000 0xf6c>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x1e6e2000 0x1000>;
pinctrl: pinctrl {
compatible = "aspeed,ast2600-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
deleted file mode 100644
index e8abbdad7b5d..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ /dev/null
@@ -1,176 +0,0 @@
-* Atmel AT91 Pinmux Controller
-
-The AT91 Pinmux Controller, enables the IC
-to share one PAD to several functional blocks. The sharing is done by
-multiplexing the PAD input/output signals. For each PAD there are up to
-8 muxing options (called periph modes). Since different modules require
-different PAD settings (like pull up, keeper, etc) the controller controls
-also the PAD settings parameters.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Atmel AT91 pin configuration node is a node of a group of pins which can be
-used for a specific device or function. This node represents both mux and config
-of the pins in that group. The 'pins' selects the function mode(also named pin
-mode) this pin can work on and the 'config' configures various pad settings
-such as pull-up, multi drive, etc.
-
-Required properties for iomux controller:
-- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl"
- or "atmel,sama5d3-pinctrl" or "microchip,sam9x60-pinctrl"
-- atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be
- configured in this periph mode. All the periph and bank need to be describe.
-
-How to create such array:
-
-Each column will represent the possible peripheral of the pinctrl
-Each line will represent a pio bank
-
-Take an example on the 9260
-Peripheral: 2 ( A and B)
-Bank: 3 (A, B and C)
-=>
-
- /* A B */
- 0xffffffff 0xffc00c3b /* pioA */
- 0xffffffff 0x7fff3ccf /* pioB */
- 0xffffffff 0x007fffff /* pioC */
-
-For each peripheral/bank we will describe in a u32 if a pin can be
-configured in it by putting 1 to the pin bit (1 << pin)
-
-Let's take the pioA on peripheral B
-From the datasheet Table 10-2.
-Peripheral B
-PA0 MCDB0
-PA1 MCCDB
-PA2
-PA3 MCDB3
-PA4 MCDB2
-PA5 MCDB1
-PA6
-PA7
-PA8
-PA9
-PA10 ETX2
-PA11 ETX3
-PA12
-PA13
-PA14
-PA15
-PA16
-PA17
-PA18
-PA19
-PA20
-PA21
-PA22 ETXER
-PA23 ETX2
-PA24 ETX3
-PA25 ERX2
-PA26 ERX3
-PA27 ERXCK
-PA28 ECRS
-PA29 ECOL
-PA30 RXD4
-PA31 TXD4
-
-=> 0xffc00c3b
-
-Required properties for pin configuration node:
-- atmel,pins: 4 integers array, represents a group of pins mux and config
- setting. The format is atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
- The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
- PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
-
-Bits used for CONFIG:
-PULL_UP (1 << 0): indicate this pin needs a pull up.
-MULTIDRIVE (1 << 1): indicate this pin needs to be configured as multi-drive.
- Multi-drive is equivalent to open-drain type output.
-DEGLITCH (1 << 2): indicate this pin needs deglitch.
-PULL_DOWN (1 << 3): indicate this pin needs a pull down.
-DIS_SCHMIT (1 << 4): indicate this pin needs to the disable schmitt trigger.
-DRIVE_STRENGTH (3 << 5): indicate the drive strength of the pin using the
- following values:
- 00 - No change (reset state value kept)
- 01 - Low
- 10 - Medium
- 11 - High
-OUTPUT (1 << 7): indicate this pin need to be configured as an output.
-OUTPUT_VAL (1 << 8): output val (1 = high, 0 = low)
-SLEWRATE (1 << 9): slew rate of the pin: 0 = disable, 1 = enable
-DEBOUNCE (1 << 16): indicate this pin needs debounce.
-DEBOUNCE_VAL (0x3fff << 17): debounce value.
-
-NOTE:
-Some requirements for using atmel,at91rm9200-pinctrl binding:
-1. We have pin function node defined under at91 controller node to represent
- what pinmux functions this SoC supports.
-2. The driver can use the function node's name and pin configuration node's
- name describe the pin function and group hierarchy.
- For example, Linux at91 pinctrl driver takes the function node's name
- as the function name and pin configuration node's name as group name to
- create the map table.
-3. Each pin configuration node should have a phandle, devices can set pins
- configurations by referring to the phandle of that pin configuration node.
-4. The gpio controller must be describe in the pinctrl simple-bus.
-
-For each bank the required properties are:
-- compatible: "atmel,at91sam9x5-gpio" or "atmel,at91rm9200-gpio" or
- "microchip,sam9x60-gpio"
-- reg: physical base address and length of the controller's registers
-- interrupts: interrupt outputs from the controller
-- interrupt-controller: marks the device node as an interrupt controller
-- #interrupt-cells: should be 2; refer to ../interrupt-controller/interrupts.txt
- for more details.
-- gpio-controller
-- #gpio-cells: should be 2; the first cell is the GPIO number and the second
- cell specifies GPIO flags as defined in <dt-bindings/gpio/gpio.h>.
-- clocks: bank clock
-
-Examples:
-
-pinctrl@fffff400 {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
- compatible = "atmel,at91rm9200-pinctrl", "simple-bus";
- reg = <0xfffff400 0x600>;
-
- pioA: gpio@fffff400 {
- compatible = "atmel,at91sam9x5-gpio";
- reg = <0xfffff400 0x200>;
- interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupt-controller;
- #interrupt-cells = <2>;
- clocks = <&pmc PMC_TYPE_PERIPHERAL 2>;
- };
-
- atmel,mux-mask = <
- /* A B */
- 0xffffffff 0xffc00c3b /* pioA */
- 0xffffffff 0x7fff3ccf /* pioB */
- 0xffffffff 0x007fffff /* pioC */
- >;
-
- /* shared pinctrl settings */
- dbgu {
- pinctrl_dbgu: dbgu-0 {
- atmel,pins =
- <1 14 0x1 0x0 /* PB14 periph A */
- 1 15 0x1 0x1>; /* PB15 periph A with pullup */
- };
- };
-};
-
-dbgu: serial@fffff200 {
- compatible = "atmel,at91sam9260-usart";
- reg = <0xfffff200 0x200>;
- interrupts = <1 4 7>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_dbgu>;
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
index e2b861ce16d8..81a05a09f19f 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt
@@ -6,6 +6,7 @@ configure it.
Required properties:
- compatible:
"atmel,sama5d2-pinctrl"
+ "microchip,sama7d65-pinctrl", "microchip,sama7g5-pinctrl"
"microchip,sama7g5-pinctrl"
- reg: base address and length of the PIO controller.
- interrupts: interrupt outputs from the controller, one for each bank.
@@ -37,7 +38,8 @@ right representation of the pin.
Optional properties:
- GENERIC_PINCONFIG: generic pinconfig options to use:
- bias-disable, bias-pull-down, bias-pull-up, drive-open-drain,
- input-schmitt-enable, input-debounce, output-low, output-high.
+ drive-push-pull input-schmitt-enable, input-debounce, output-low,
+ output-high.
- for microchip,sama7g5-pinctrl only:
- slew-rate: 0 - disabled, 1 - enabled (default)
- atmel,drive-strength: 0 or 1 for low drive, 2 for medium drive and 3 for
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml
new file mode 100644
index 000000000000..a7ede29c1444
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91rm9200-pinctrl.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/atmel,at91rm9200-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIO3 Pinmux Controller
+
+maintainers:
+ - Manikandan Muralidharan <manikandan.m@microchip.com>
+
+description:
+ The AT91 Pinmux Controller, enables the IC to share one PAD to several
+ functional blocks. The sharing is done by multiplexing the PAD input/output
+ signals. For each PAD there are up to 8 muxing options (called periph modes).
+ Since different modules require different PAD settings (like pull up, keeper,
+ etc) the controller controls also the PAD settings parameters.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at91rm9200-pinctrl
+ - atmel,at91sam9x5-pinctrl
+ - atmel,sama5d3-pinctrl
+ - microchip,sam9x60-pinctrl
+ - const: simple-mfd
+ - items:
+ - enum:
+ - microchip,sam9x7-pinctrl
+ - const: microchip,sam9x60-pinctrl
+ - const: simple-mfd
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
+
+ atmel,mux-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ Array of mask (periph per bank) to describe if a pin can be
+ configured in this periph mode. All the periph and bank need to
+ be described.
+
+ #How to create such array:
+
+ Each column will represent the possible peripheral of the pinctrl
+ Each line will represent a pio bank
+
+ #Example:
+
+ In at91sam9260.dtsi,
+ Peripheral: 2 ( A and B)
+ Bank: 3 (A, B and C)
+
+ # A B
+ 0xffffffff 0xffc00c3b # pioA
+ 0xffffffff 0x7fff3ccf # pioB
+ 0xffffffff 0x007fffff # pioC
+
+ For each peripheral/bank we will describe in a u32 if a pin can be
+ configured in it by putting 1 to the pin bit (1 << pin)
+
+ Let's take the pioA on peripheral B whose value is 0xffc00c3b
+ From the datasheet Table 10-2.
+ Peripheral B
+ PA0 MCDB0
+ PA1 MCCDB
+ PA2
+ PA3 MCDB3
+ PA4 MCDB2
+ PA5 MCDB1
+ PA6
+ PA7
+ PA8
+ PA9
+ PA10 ETX2
+ PA11 ETX3
+ PA12
+ PA13
+ PA14
+ PA15
+ PA16
+ PA17
+ PA18
+ PA19
+ PA20
+ PA21
+ PA22 ETXER
+ PA23 ETX2
+ PA24 ETX3
+ PA25 ERX2
+ PA26 ERX3
+ PA27 ERXCK
+ PA28 ECRS
+ PA29 ECOL
+ PA30 RXD4
+ PA31 TXD4
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+ - atmel,mux-mask
+
+patternProperties:
+ 'gpio@[0-9a-f]+$':
+ $ref: /schemas/gpio/atmel,at91rm9200-gpio.yaml
+ unevaluatedProperties: false
+
+additionalProperties:
+ type: object
+ additionalProperties:
+ type: object
+ additionalProperties: false
+
+ properties:
+ atmel,pins:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ Each entry consists of 4 integers and represents the pins
+ mux and config setting.The format is
+ atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
+ Supported pin number and mux varies for different SoCs, and
+ are defined in <include/dt-bindings/pinctrl/at91.h>.
+ items:
+ items:
+ - description:
+ Pin bank
+ - description:
+ Pin bank index
+ - description:
+ Peripheral function
+ - description:
+ Pad configuration
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/pinctrl/at91.h>
+
+ pinctrl@fffff400 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "atmel,at91rm9200-pinctrl", "simple-mfd";
+ ranges = <0xfffff400 0xfffff400 0x600>;
+
+ atmel,mux-mask = <
+ /* A B */
+ 0xffffffff 0xffc00c3b /* pioA */
+ 0xffffffff 0x7fff3ccf /* pioB */
+ 0xffffffff 0x007fffff /* pioC */
+ >;
+
+ dbgu {
+ dbgu-0 {
+ atmel,pins =
+ <AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
+ AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+ };
+ };
+
+ gpio@fffff400 {
+ compatible = "atmel,at91rm9200-gpio";
+ reg = <0xfffff400 0x200>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 2>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml
new file mode 100644
index 000000000000..98c310a3c63c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/awinic,aw9523-pinctrl.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/awinic,aw9523-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW9523/AW9523B I2C GPIO Expander
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
+
+description: |
+ The Awinic AW9523/AW9523B I2C GPIO Expander featuring 16 multi-function
+ I/O, 256 steps PWM mode and interrupt support.
+
+properties:
+ compatible:
+ const: awinic,aw9523-pinctrl
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ description: |
+ Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-controller: true
+
+ gpio-ranges:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+ description: Specifies the INTN pin IRQ.
+
+ '#interrupt-cells':
+ description:
+ Specifies the PIN numbers and Flags, as defined in defined in
+ include/dt-bindings/interrupt-controller/irq.h
+ const: 2
+
+ reset-gpios:
+ maxItems: 1
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in
+ this subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-5])$"
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the
+ specified pins.
+
+ enum: [ gpio, pwm ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-open-drain: true
+ drive-push-pull: true
+ input-enable: true
+ input-disable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ # Example configuration to drive pins for a keyboard matrix
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ aw9523: gpio-expander@58 {
+ compatible = "awinic,aw9523-pinctrl";
+ reg = <0x58>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <50 IRQ_TYPE_EDGE_FALLING>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 16>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reset-gpios = <&tlmm 51 GPIO_ACTIVE_HIGH>;
+
+ keyboard-matrix-col-pins {
+ pins = "gpio8", "gpio9", "gpio10", "gpio11",
+ "gpio12", "gpio13", "gpio14", "gpio15";
+ function = "gpio";
+ input-disable;
+ output-low;
+ };
+
+ keyboard-matrix-row-pins {
+ pins = "gpio0", "gpio1", "gpio2", "gpio3",
+ "gpio4", "gpio5", "gpio6", "gpio7";
+ function = "gpio";
+ bias-pull-up;
+ drive-open-drain;
+ input-enable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
deleted file mode 100644
index 0a2d5516e1f3..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Pin-controller driver for the Marvell Berlin SoCs
-
-Pin control registers are part of both chip controller and system
-controller register sets. Pin controller nodes should be a sub-node of
-either the chip controller or system controller node. The pins
-controlled are organized in groups, so no actual pin information is
-needed.
-
-A pin-controller node should contain subnodes representing the pin group
-configurations, one per function. Each subnode has the group name and
-the muxing function used.
-
-Be aware the Marvell Berlin datasheets use the keyword 'mode' for what
-is called a 'function' in the pin-controller subsystem.
-
-Required properties:
-- compatible: should be one of:
- "marvell,berlin2-soc-pinctrl",
- "marvell,berlin2-system-pinctrl",
- "marvell,berlin2cd-soc-pinctrl",
- "marvell,berlin2cd-system-pinctrl",
- "marvell,berlin2q-soc-pinctrl",
- "marvell,berlin2q-system-pinctrl",
- "marvell,berlin4ct-avio-pinctrl",
- "marvell,berlin4ct-soc-pinctrl",
- "marvell,berlin4ct-system-pinctrl",
- "syna,as370-soc-pinctrl"
-
-Required subnode-properties:
-- groups: a list of strings describing the group names.
-- function: a string describing the function used to mux the groups.
-
-Example:
-
-sys_pinctrl: pin-controller {
- compatible = "marvell,berlin2q-system-pinctrl";
-
- uart0_pmux: uart0-pmux {
- groups = "GSM12";
- function = "uart0";
- };
-};
-
-&uart0 {
- pinctrl-0 = <&uart0_pmux>;
- pinctrl-names = "default";
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt
deleted file mode 100644
index 4980776122cc..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-Bitmain BM1880 Pin Controller
-
-This binding describes the pin controller found in the BM1880 SoC.
-
-Required Properties:
-
-- compatible: Should be "bitmain,bm1880-pinctrl"
-- reg: Offset and length of pinctrl space in SCTRL.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration for BM1880 SoC
-includes pinmux and various pin configuration parameters, such as pull-up,
-slew rate etc...
-
-Each configuration node can consist of multiple nodes describing the pinmux
-options. The name of each subnode is not important; all subnodes should be
-enumerated and processed purely based on their content.
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pinmux subnode:
-
-Required Properties:
-
-- pins: An array of strings, each string containing the name of a pin.
- Valid values for pins are:
-
- MIO0 - MIO111
-
-- groups: An array of strings, each string containing the name of a pin
- group. Valid values for groups are:
-
- nand_grp, spi_grp, emmc_grp, sdio_grp, eth0_grp, pwm0_grp,
- pwm1_grp, pwm2_grp, pwm3_grp, pwm4_grp, pwm5_grp, pwm6_grp,
- pwm7_grp, pwm8_grp, pwm9_grp, pwm10_grp, pwm11_grp, pwm12_grp,
- pwm13_grp, pwm14_grp, pwm15_grp, pwm16_grp, pwm17_grp,
- pwm18_grp, pwm19_grp, pwm20_grp, pwm21_grp, pwm22_grp,
- pwm23_grp, pwm24_grp, pwm25_grp, pwm26_grp, pwm27_grp,
- pwm28_grp, pwm29_grp, pwm30_grp, pwm31_grp, pwm32_grp,
- pwm33_grp, pwm34_grp, pwm35_grp, pwm36_grp, i2c0_grp,
- i2c1_grp, i2c2_grp, i2c3_grp, i2c4_grp, uart0_grp, uart1_grp,
- uart2_grp, uart3_grp, uart4_grp, uart5_grp, uart6_grp,
- uart7_grp, uart8_grp, uart9_grp, uart10_grp, uart11_grp,
- uart12_grp, uart13_grp, uart14_grp, uart15_grp, gpio0_grp,
- gpio1_grp, gpio2_grp, gpio3_grp, gpio4_grp, gpio5_grp,
- gpio6_grp, gpio7_grp, gpio8_grp, gpio9_grp, gpio10_grp,
- gpio11_grp, gpio12_grp, gpio13_grp, gpio14_grp, gpio15_grp,
- gpio16_grp, gpio17_grp, gpio18_grp, gpio19_grp, gpio20_grp,
- gpio21_grp, gpio22_grp, gpio23_grp, gpio24_grp, gpio25_grp,
- gpio26_grp, gpio27_grp, gpio28_grp, gpio29_grp, gpio30_grp,
- gpio31_grp, gpio32_grp, gpio33_grp, gpio34_grp, gpio35_grp,
- gpio36_grp, gpio37_grp, gpio38_grp, gpio39_grp, gpio40_grp,
- gpio41_grp, gpio42_grp, gpio43_grp, gpio44_grp, gpio45_grp,
- gpio46_grp, gpio47_grp, gpio48_grp, gpio49_grp, gpio50_grp,
- gpio51_grp, gpio52_grp, gpio53_grp, gpio54_grp, gpio55_grp,
- gpio56_grp, gpio57_grp, gpio58_grp, gpio59_grp, gpio60_grp,
- gpio61_grp, gpio62_grp, gpio63_grp, gpio64_grp, gpio65_grp,
- gpio66_grp, gpio67_grp, eth1_grp, i2s0_grp, i2s0_mclkin_grp,
- i2s1_grp, i2s1_mclkin_grp, spi0_grp
-
-- function: An array of strings, each string containing the name of the
- pinmux functions. The following are the list of pinmux
- functions available:
-
- nand, spi, emmc, sdio, eth0, pwm0, pwm1, pwm2, pwm3, pwm4,
- pwm5, pwm6, pwm7, pwm8, pwm9, pwm10, pwm11, pwm12, pwm13,
- pwm14, pwm15, pwm16, pwm17, pwm18, pwm19, pwm20, pwm21, pwm22,
- pwm23, pwm24, pwm25, pwm26, pwm27, pwm28, pwm29, pwm30, pwm31,
- pwm32, pwm33, pwm34, pwm35, pwm36, i2c0, i2c1, i2c2, i2c3,
- i2c4, uart0, uart1, uart2, uart3, uart4, uart5, uart6, uart7,
- uart8, uart9, uart10, uart11, uart12, uart13, uart14, uart15,
- gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8,
- gpio9, gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, gpio16,
- gpio17, gpio18, gpio19, gpio20, gpio21, gpio22, gpio23,
- gpio24, gpio25, gpio26, gpio27, gpio28, gpio29, gpio30,
- gpio31, gpio32, gpio33, gpio34, gpio35, gpio36, gpio37,
- gpio38, gpio39, gpio40, gpio41, gpio42, gpio43, gpio44,
- gpio45, gpio46, gpio47, gpio48, gpio49, gpio50, gpio51,
- gpio52, gpio53, gpio54, gpio55, gpio56, gpio57, gpio58,
- gpio59, gpio60, gpio61, gpio62, gpio63, gpio64, gpio65,
- gpio66, gpio67, eth1, i2s0, i2s0_mclkin, i2s1, i2s1_mclkin,
- spi0
-
-Optional Properties:
-
-- bias-disable: No arguments. Disable pin bias.
-- bias-pull-down: No arguments. The specified pins should be configured as
- pull down.
-- bias-pull-up: No arguments. The specified pins should be configured as
- pull up.
-- input-schmitt-enable: No arguments: Enable schmitt trigger for the specified
- pins
-- input-schmitt-disable: No arguments: Disable schmitt trigger for the specified
- pins
-- slew-rate: Integer. Sets slew rate for the specified pins.
- Valid values are:
- <0> - Slow
- <1> - Fast
-- drive-strength: Integer. Selects the drive strength for the specified
- pins in mA.
- Valid values are:
- <4>
- <8>
- <12>
- <16>
- <20>
- <24>
- <28>
- <32>
-
-Example:
- pinctrl: pinctrl@400 {
- compatible = "bitmain,bm1880-pinctrl";
- reg = <0x400 0x120>;
-
- pinctrl_uart0_default: uart0-default {
- pinmux {
- groups = "uart0_grp";
- function = "uart0";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.yaml
new file mode 100644
index 000000000000..542be9870838
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/bitmain,bm1880-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bitmain BM1880 Pin Controller
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+properties:
+ compatible:
+ const: bitmain,bm1880-pinctrl
+
+ reg:
+ maxItems: 1
+
+additionalProperties:
+ description: A pin configuration node.
+ type: object
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ type: object
+ description: Pin multiplexing parameters.
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins:
+ items:
+ pattern: '^MIO[0-9]+$'
+
+ groups:
+ items:
+ enum: [
+ nand_grp, spi_grp, emmc_grp, sdio_grp, eth0_grp, pwm0_grp,
+ pwm1_grp, pwm2_grp, pwm3_grp, pwm4_grp, pwm5_grp, pwm6_grp,
+ pwm7_grp, pwm8_grp, pwm9_grp, pwm10_grp, pwm11_grp, pwm12_grp,
+ pwm13_grp, pwm14_grp, pwm15_grp, pwm16_grp, pwm17_grp,
+ pwm18_grp, pwm19_grp, pwm20_grp, pwm21_grp, pwm22_grp,
+ pwm23_grp, pwm24_grp, pwm25_grp, pwm26_grp, pwm27_grp,
+ pwm28_grp, pwm29_grp, pwm30_grp, pwm31_grp, pwm32_grp,
+ pwm33_grp, pwm34_grp, pwm35_grp, pwm36_grp, i2c0_grp,
+ i2c1_grp, i2c2_grp, i2c3_grp, i2c4_grp, uart0_grp, uart1_grp,
+ uart2_grp, uart3_grp, uart4_grp, uart5_grp, uart6_grp,
+ uart7_grp, uart8_grp, uart9_grp, uart10_grp, uart11_grp,
+ uart12_grp, uart13_grp, uart14_grp, uart15_grp, gpio0_grp,
+ gpio1_grp, gpio2_grp, gpio3_grp, gpio4_grp, gpio5_grp,
+ gpio6_grp, gpio7_grp, gpio8_grp, gpio9_grp, gpio10_grp,
+ gpio11_grp, gpio12_grp, gpio13_grp, gpio14_grp, gpio15_grp,
+ gpio16_grp, gpio17_grp, gpio18_grp, gpio19_grp, gpio20_grp,
+ gpio21_grp, gpio22_grp, gpio23_grp, gpio24_grp, gpio25_grp,
+ gpio26_grp, gpio27_grp, gpio28_grp, gpio29_grp, gpio30_grp,
+ gpio31_grp, gpio32_grp, gpio33_grp, gpio34_grp, gpio35_grp,
+ gpio36_grp, gpio37_grp, gpio38_grp, gpio39_grp, gpio40_grp,
+ gpio41_grp, gpio42_grp, gpio43_grp, gpio44_grp, gpio45_grp,
+ gpio46_grp, gpio47_grp, gpio48_grp, gpio49_grp, gpio50_grp,
+ gpio51_grp, gpio52_grp, gpio53_grp, gpio54_grp, gpio55_grp,
+ gpio56_grp, gpio57_grp, gpio58_grp, gpio59_grp, gpio60_grp,
+ gpio61_grp, gpio62_grp, gpio63_grp, gpio64_grp, gpio65_grp,
+ gpio66_grp, gpio67_grp, eth1_grp, i2s0_grp, i2s0_mclkin_grp,
+ i2s1_grp, i2s1_mclkin_grp, spi0_grp
+ ]
+
+ function:
+ items:
+ enum: [
+ nand, spi, emmc, sdio, eth0, pwm0, pwm1, pwm2, pwm3, pwm4,
+ pwm5, pwm6, pwm7, pwm8, pwm9, pwm10, pwm11, pwm12, pwm13,
+ pwm14, pwm15, pwm16, pwm17, pwm18, pwm19, pwm20, pwm21, pwm22,
+ pwm23, pwm24, pwm25, pwm26, pwm27, pwm28, pwm29, pwm30, pwm31,
+ pwm32, pwm33, pwm34, pwm35, pwm36, i2c0, i2c1, i2c2, i2c3,
+ i2c4, uart0, uart1, uart2, uart3, uart4, uart5, uart6, uart7,
+ uart8, uart9, uart10, uart11, uart12, uart13, uart14, uart15,
+ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8,
+ gpio9, gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, gpio16,
+ gpio17, gpio18, gpio19, gpio20, gpio21, gpio22, gpio23,
+ gpio24, gpio25, gpio26, gpio27, gpio28, gpio29, gpio30,
+ gpio31, gpio32, gpio33, gpio34, gpio35, gpio36, gpio37,
+ gpio38, gpio39, gpio40, gpio41, gpio42, gpio43, gpio44,
+ gpio45, gpio46, gpio47, gpio48, gpio49, gpio50, gpio51,
+ gpio52, gpio53, gpio54, gpio55, gpio56, gpio57, gpio58,
+ gpio59, gpio60, gpio61, gpio62, gpio63, gpio64, gpio65,
+ gpio66, gpio67, eth1, i2s0, i2s0_mclkin, i2s1, i2s1_mclkin,
+ spi0
+ ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+
+ slew-rate:
+ description: >
+ Sets slew rate. Valid values: 0 = Slow, 1 = Fast.
+ enum: [0, 1]
+
+ drive-strength:
+ enum: [4, 8, 12, 16, 20, 24, 28, 32]
+
+ oneOf:
+ - required:
+ - pins
+ - required:
+ - groups
+
+ required:
+ - function
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ pinctrl@400 {
+ compatible = "bitmain,bm1880-pinctrl";
+ reg = <0x400 0x120>;
+
+ uart0-default {
+ pinmux {
+ groups = "uart0_grp";
+ function = "uart0";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
deleted file mode 100644
index e047a198db38..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
+++ /dev/null
@@ -1,461 +0,0 @@
-Broadcom BCM281xx Pin Controller
-
-This is a pin controller for the Broadcom BCM281xx SoC family, which includes
-BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs.
-
-=== Pin Controller Node ===
-
-Required Properties:
-
-- compatible: Must be "brcm,bcm11351-pinctrl"
-- reg: Base address of the PAD Controller register block and the size
- of the block.
-
-For example, the following is the bare minimum node:
-
- pinctrl@35004800 {
- compatible = "brcm,bcm11351-pinctrl";
- reg = <0x35004800 0x430>;
- };
-
-As a pin controller device, in addition to the required properties, this node
-should also contain the pin configuration nodes that client devices reference,
-if any.
-
-=== Pin Configuration Node ===
-
-Each pin configuration node is a sub-node of the pin controller node and is a
-container of an arbitrary number of subnodes, called pin group nodes in this
-document.
-
-Please refer to the pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the definition of a
-"pin configuration node".
-
-=== Pin Group Node ===
-
-A pin group node specifies the desired pin mux and/or pin configuration for an
-arbitrary number of pins. The name of the pin group node is optional and not
-used.
-
-A pin group node only affects the properties specified in the node, and has no
-effect on any properties that are omitted.
-
-The pin group node accepts a subset of the generic pin config properties. For
-details generic pin config properties, please refer to pinctrl-bindings.txt
-and <include/linux/pinctrl/pinconfig-generic.h>.
-
-Each pin controlled by this pin controller belong to one of three types:
-Standard, I2C, and HDMI. Each type accepts a different set of pin config
-properties. A list of pins and their types is provided below.
-
-Required Properties (applicable to all pins):
-
-- pins: Multiple strings. Specifies the name(s) of one or more pins to
- be configured by this node.
-
-Optional Properties (for standard pins):
-
-- function: String. Specifies the pin mux selection. Values
- must be one of: "alt1", "alt2", "alt3", "alt4"
-- input-schmitt-enable: No arguments. Enable schmitt-trigger mode.
-- input-schmitt-disable: No arguments. Disable schmitt-trigger mode.
-- bias-pull-up: No arguments. Pull up on pin.
-- bias-pull-down: No arguments. Pull down on pin.
-- bias-disable: No arguments. Disable pin bias.
-- slew-rate: Integer. Meaning depends on configured pin mux:
- *_SCL or *_SDA:
- 0: Standard(100kbps)& Fast(400kbps) mode
- 1: Highspeed (3.4Mbps) mode
- IC_DM or IC_DP:
- 0: normal slew rate
- 1: fast slew rate
- Otherwise:
- 0: fast slew rate
- 1: normal slew rate
-- input-enable: No arguments. Enable input (does not affect
- output.)
-- input-disable: No arguments. Disable input (does not affect
- output.)
-- drive-strength: Integer. Drive strength in mA. Valid values are
- 2, 4, 6, 8, 10, 12, 14, 16 mA.
-
-Optional Properties (for I2C pins):
-
-- function: String. Specifies the pin mux selection. Values
- must be one of: "alt1", "alt2", "alt3", "alt4"
-- bias-pull-up: Integer. Pull up strength in Ohm. There are 3
- pull-up resistors (1.2k, 1.8k, 2.7k) available
- in parallel for I2C pins, so the valid values
- are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm.
-- bias-disable: No arguments. Disable pin bias.
-- slew-rate: Integer. Meaning depends on configured pin mux:
- *_SCL or *_SDA:
- 0: Standard(100kbps)& Fast(400kbps) mode
- 1: Highspeed (3.4Mbps) mode
- IC_DM or IC_DP:
- 0: normal slew rate
- 1: fast slew rate
- Otherwise:
- 0: fast slew rate
- 1: normal slew rate
-- input-enable: No arguments. Enable input (does not affect
- output.)
-- input-disable: No arguments. Disable input (does not affect
- output.)
-
-Optional Properties (for HDMI pins):
-
-- function: String. Specifies the pin mux selection. Values
- must be one of: "alt1", "alt2", "alt3", "alt4"
-- slew-rate: Integer. Controls slew rate.
- 0: Standard(100kbps)& Fast(400kbps) mode
- 1: Highspeed (3.4Mbps) mode
-- input-enable: No arguments. Enable input (does not affect
- output.)
-- input-disable: No arguments. Disable input (does not affect
- output.)
-
-Example:
-// pin controller node
-pinctrl@35004800 {
- compatible = "brcm,bcm11351-pinctrl";
- reg = <0x35004800 0x430>;
-
- // pin configuration node
- dev_a_default: dev_a_active {
- //group node defining 1 standard pin
- grp_1 {
- pins = "std_pin1";
- function = "alt1";
- input-schmitt-enable;
- bias-disable;
- slew-rate = <1>;
- drive-strength = <4>;
- };
-
- // group node defining 2 I2C pins
- grp_2 {
- pins = "i2c_pin1", "i2c_pin2";
- function = "alt2";
- bias-pull-up = <720>;
- input-enable;
- };
-
- // group node defining 2 HDMI pins
- grp_3 {
- pins = "hdmi_pin1", "hdmi_pin2";
- function = "alt3";
- slew-rate = <1>;
- };
-
- // other pin group nodes
- ...
- };
-
- // other pin configuration nodes
- ...
-};
-
-In the example above, "dev_a_active" is a pin configuration node with a number
-of sub-nodes. In the pin group node "grp_1", one pin, "std_pin1", is defined in
-the "pins" property. Thus, the remaining properties in the "grp_1" node applies
-only to this pin, including the following settings:
- - setting pinmux to "alt1"
- - enabling schmitt-trigger (hystersis) mode
- - disabling pin bias
- - setting the slew-rate to 1
- - setting the drive strength to 4 mA
-Note that neither "input-enable" nor "input-disable" was specified - the pinctrl
-subsystem will therefore leave this property unchanged from whatever state it
-was in before applying these changes.
-
-The "pins" property in the pin group node "grp_2" specifies two pins -
-"i2c_pin1" and "i2c_pin2"; the remaining properties in this pin group node,
-therefore, applies to both of these pins. The properties include:
- - setting pinmux to "alt2"
- - setting pull-up resistance to 720 Ohm (ie. enabling 1.2k and 1.8k resistors
- in parallel)
- - enabling both pins' input
-"slew-rate" is not specified in this pin group node, so the slew-rate for these
-pins are left as-is.
-
-Finally, "grp_3" defines two HDMI pins. The following properties are applied to
-both pins:
- - setting pinmux to "alt3"
- - setting slew-rate to 1; for HDMI pins, this corresponds to the 3.4 Mbps
- Highspeed mode
-The input is neither enabled or disabled, and is left untouched.
-
-=== Pin Names and Type ===
-
-The following are valid pin names and their pin types:
-
- "adcsync", Standard
- "bat_rm", Standard
- "bsc1_scl", I2C
- "bsc1_sda", I2C
- "bsc2_scl", I2C
- "bsc2_sda", I2C
- "classgpwr", Standard
- "clk_cx8", Standard
- "clkout_0", Standard
- "clkout_1", Standard
- "clkout_2", Standard
- "clkout_3", Standard
- "clkreq_in_0", Standard
- "clkreq_in_1", Standard
- "cws_sys_req1", Standard
- "cws_sys_req2", Standard
- "cws_sys_req3", Standard
- "digmic1_clk", Standard
- "digmic1_dq", Standard
- "digmic2_clk", Standard
- "digmic2_dq", Standard
- "gpen13", Standard
- "gpen14", Standard
- "gpen15", Standard
- "gpio00", Standard
- "gpio01", Standard
- "gpio02", Standard
- "gpio03", Standard
- "gpio04", Standard
- "gpio05", Standard
- "gpio06", Standard
- "gpio07", Standard
- "gpio08", Standard
- "gpio09", Standard
- "gpio10", Standard
- "gpio11", Standard
- "gpio12", Standard
- "gpio13", Standard
- "gpio14", Standard
- "gps_pablank", Standard
- "gps_tmark", Standard
- "hdmi_scl", HDMI
- "hdmi_sda", HDMI
- "ic_dm", Standard
- "ic_dp", Standard
- "kp_col_ip_0", Standard
- "kp_col_ip_1", Standard
- "kp_col_ip_2", Standard
- "kp_col_ip_3", Standard
- "kp_row_op_0", Standard
- "kp_row_op_1", Standard
- "kp_row_op_2", Standard
- "kp_row_op_3", Standard
- "lcd_b_0", Standard
- "lcd_b_1", Standard
- "lcd_b_2", Standard
- "lcd_b_3", Standard
- "lcd_b_4", Standard
- "lcd_b_5", Standard
- "lcd_b_6", Standard
- "lcd_b_7", Standard
- "lcd_g_0", Standard
- "lcd_g_1", Standard
- "lcd_g_2", Standard
- "lcd_g_3", Standard
- "lcd_g_4", Standard
- "lcd_g_5", Standard
- "lcd_g_6", Standard
- "lcd_g_7", Standard
- "lcd_hsync", Standard
- "lcd_oe", Standard
- "lcd_pclk", Standard
- "lcd_r_0", Standard
- "lcd_r_1", Standard
- "lcd_r_2", Standard
- "lcd_r_3", Standard
- "lcd_r_4", Standard
- "lcd_r_5", Standard
- "lcd_r_6", Standard
- "lcd_r_7", Standard
- "lcd_vsync", Standard
- "mdmgpio0", Standard
- "mdmgpio1", Standard
- "mdmgpio2", Standard
- "mdmgpio3", Standard
- "mdmgpio4", Standard
- "mdmgpio5", Standard
- "mdmgpio6", Standard
- "mdmgpio7", Standard
- "mdmgpio8", Standard
- "mphi_data_0", Standard
- "mphi_data_1", Standard
- "mphi_data_2", Standard
- "mphi_data_3", Standard
- "mphi_data_4", Standard
- "mphi_data_5", Standard
- "mphi_data_6", Standard
- "mphi_data_7", Standard
- "mphi_data_8", Standard
- "mphi_data_9", Standard
- "mphi_data_10", Standard
- "mphi_data_11", Standard
- "mphi_data_12", Standard
- "mphi_data_13", Standard
- "mphi_data_14", Standard
- "mphi_data_15", Standard
- "mphi_ha0", Standard
- "mphi_hat0", Standard
- "mphi_hat1", Standard
- "mphi_hce0_n", Standard
- "mphi_hce1_n", Standard
- "mphi_hrd_n", Standard
- "mphi_hwr_n", Standard
- "mphi_run0", Standard
- "mphi_run1", Standard
- "mtx_scan_clk", Standard
- "mtx_scan_data", Standard
- "nand_ad_0", Standard
- "nand_ad_1", Standard
- "nand_ad_2", Standard
- "nand_ad_3", Standard
- "nand_ad_4", Standard
- "nand_ad_5", Standard
- "nand_ad_6", Standard
- "nand_ad_7", Standard
- "nand_ale", Standard
- "nand_cen_0", Standard
- "nand_cen_1", Standard
- "nand_cle", Standard
- "nand_oen", Standard
- "nand_rdy_0", Standard
- "nand_rdy_1", Standard
- "nand_wen", Standard
- "nand_wp", Standard
- "pc1", Standard
- "pc2", Standard
- "pmu_int", Standard
- "pmu_scl", I2C
- "pmu_sda", I2C
- "rfst2g_mtsloten3g", Standard
- "rgmii_0_rx_ctl", Standard
- "rgmii_0_rxc", Standard
- "rgmii_0_rxd_0", Standard
- "rgmii_0_rxd_1", Standard
- "rgmii_0_rxd_2", Standard
- "rgmii_0_rxd_3", Standard
- "rgmii_0_tx_ctl", Standard
- "rgmii_0_txc", Standard
- "rgmii_0_txd_0", Standard
- "rgmii_0_txd_1", Standard
- "rgmii_0_txd_2", Standard
- "rgmii_0_txd_3", Standard
- "rgmii_1_rx_ctl", Standard
- "rgmii_1_rxc", Standard
- "rgmii_1_rxd_0", Standard
- "rgmii_1_rxd_1", Standard
- "rgmii_1_rxd_2", Standard
- "rgmii_1_rxd_3", Standard
- "rgmii_1_tx_ctl", Standard
- "rgmii_1_txc", Standard
- "rgmii_1_txd_0", Standard
- "rgmii_1_txd_1", Standard
- "rgmii_1_txd_2", Standard
- "rgmii_1_txd_3", Standard
- "rgmii_gpio_0", Standard
- "rgmii_gpio_1", Standard
- "rgmii_gpio_2", Standard
- "rgmii_gpio_3", Standard
- "rtxdata2g_txdata3g1", Standard
- "rtxen2g_txdata3g2", Standard
- "rxdata3g0", Standard
- "rxdata3g1", Standard
- "rxdata3g2", Standard
- "sdio1_clk", Standard
- "sdio1_cmd", Standard
- "sdio1_data_0", Standard
- "sdio1_data_1", Standard
- "sdio1_data_2", Standard
- "sdio1_data_3", Standard
- "sdio4_clk", Standard
- "sdio4_cmd", Standard
- "sdio4_data_0", Standard
- "sdio4_data_1", Standard
- "sdio4_data_2", Standard
- "sdio4_data_3", Standard
- "sim_clk", Standard
- "sim_data", Standard
- "sim_det", Standard
- "sim_resetn", Standard
- "sim2_clk", Standard
- "sim2_data", Standard
- "sim2_det", Standard
- "sim2_resetn", Standard
- "sri_c", Standard
- "sri_d", Standard
- "sri_e", Standard
- "ssp_extclk", Standard
- "ssp0_clk", Standard
- "ssp0_fs", Standard
- "ssp0_rxd", Standard
- "ssp0_txd", Standard
- "ssp2_clk", Standard
- "ssp2_fs_0", Standard
- "ssp2_fs_1", Standard
- "ssp2_fs_2", Standard
- "ssp2_fs_3", Standard
- "ssp2_rxd_0", Standard
- "ssp2_rxd_1", Standard
- "ssp2_txd_0", Standard
- "ssp2_txd_1", Standard
- "ssp3_clk", Standard
- "ssp3_fs", Standard
- "ssp3_rxd", Standard
- "ssp3_txd", Standard
- "ssp4_clk", Standard
- "ssp4_fs", Standard
- "ssp4_rxd", Standard
- "ssp4_txd", Standard
- "ssp5_clk", Standard
- "ssp5_fs", Standard
- "ssp5_rxd", Standard
- "ssp5_txd", Standard
- "ssp6_clk", Standard
- "ssp6_fs", Standard
- "ssp6_rxd", Standard
- "ssp6_txd", Standard
- "stat_1", Standard
- "stat_2", Standard
- "sysclken", Standard
- "traceclk", Standard
- "tracedt00", Standard
- "tracedt01", Standard
- "tracedt02", Standard
- "tracedt03", Standard
- "tracedt04", Standard
- "tracedt05", Standard
- "tracedt06", Standard
- "tracedt07", Standard
- "tracedt08", Standard
- "tracedt09", Standard
- "tracedt10", Standard
- "tracedt11", Standard
- "tracedt12", Standard
- "tracedt13", Standard
- "tracedt14", Standard
- "tracedt15", Standard
- "txdata3g0", Standard
- "txpwrind", Standard
- "uartb1_ucts", Standard
- "uartb1_urts", Standard
- "uartb1_urxd", Standard
- "uartb1_utxd", Standard
- "uartb2_urxd", Standard
- "uartb2_utxd", Standard
- "uartb3_ucts", Standard
- "uartb3_urts", Standard
- "uartb3_urxd", Standard
- "uartb3_utxd", Standard
- "uartb4_ucts", Standard
- "uartb4_urts", Standard
- "uartb4_urxd", Standard
- "uartb4_utxd", Standard
- "vc_cam1_scl", I2C
- "vc_cam1_sda", I2C
- "vc_cam2_scl", I2C
- "vc_cam2_sda", I2C
- "vc_cam3_scl", I2C
- "vc_cam3_sda", I2C
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml
new file mode 100644
index 000000000000..90c275295199
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.yaml
@@ -0,0 +1,259 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,bcm11351-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM281xx pin controller
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm11351-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '-grp[0-9]$':
+ type: object
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ Specifies the name(s) of one or more pins to be configured by
+ this node.
+ items:
+ enum: [ adcsync, bat_rm, bsc1_scl, bsc1_sda, bsc2_scl, bsc2_sda,
+ classgpwr, clk_cx8, clkout_0, clkout_1, clkout_2,
+ clkout_3, clkreq_in_0, clkreq_in_1, cws_sys_req1,
+ cws_sys_req2, cws_sys_req3, digmic1_clk, digmic1_dq,
+ digmic2_clk, digmic2_dq, gpen13, gpen14, gpen15, gpio00,
+ gpio01, gpio02, gpio03, gpio04, gpio05, gpio06, gpio07,
+ gpio08, gpio09, gpio10, gpio11, gpio12, gpio13, gpio14,
+ gps_pablank, gps_tmark, hdmi_scl, hdmi_sda, ic_dm, ic_dp,
+ kp_col_ip_0, kp_col_ip_1, kp_col_ip_2, kp_col_ip_3,
+ kp_row_op_0, kp_row_op_1, kp_row_op_2, kp_row_op_3,
+ lcd_b_0, lcd_b_1, lcd_b_2, lcd_b_3, lcd_b_4, lcd_b_5,
+ lcd_b_6, lcd_b_7, lcd_g_0, lcd_g_1, lcd_g_2, lcd_g_3,
+ lcd_g_4, lcd_g_5, lcd_g_6, lcd_g_7, lcd_hsync, lcd_oe,
+ lcd_pclk, lcd_r_0, lcd_r_1, lcd_r_2, lcd_r_3, lcd_r_4,
+ lcd_r_5, lcd_r_6, lcd_r_7, lcd_vsync, mdmgpio0, mdmgpio1,
+ mdmgpio2, mdmgpio3, mdmgpio4, mdmgpio5, mdmgpio6,
+ mdmgpio7, mdmgpio8, mphi_data_0, mphi_data_1, mphi_data_2,
+ mphi_data_3, mphi_data_4, mphi_data_5, mphi_data_6,
+ mphi_data_7, mphi_data_8, mphi_data_9, mphi_data_10,
+ mphi_data_11, mphi_data_12, mphi_data_13, mphi_data_14,
+ mphi_data_15, mphi_ha0, mphi_hat0, mphi_hat1, mphi_hce0_n,
+ mphi_hce1_n, mphi_hrd_n, mphi_hwr_n, mphi_run0, mphi_run1,
+ mtx_scan_clk, mtx_scan_data, nand_ad_0, nand_ad_1,
+ nand_ad_2, nand_ad_3, nand_ad_4, nand_ad_5, nand_ad_6,
+ nand_ad_7, nand_ale, nand_cen_0, nand_cen_1, nand_cle,
+ nand_oen, nand_rdy_0, nand_rdy_1, nand_wen, nand_wp, pc1,
+ pc2, pmu_int, pmu_scl, pmu_sda, rfst2g_mtsloten3g,
+ rgmii_0_rx_ctl, rgmii_0_rxc, rgmii_0_rxd_0, rgmii_0_rxd_1,
+ rgmii_0_rxd_2, rgmii_0_rxd_3, rgmii_0_tx_ctl, rgmii_0_txc,
+ rgmii_0_txd_0, rgmii_0_txd_1, rgmii_0_txd_2,
+ rgmii_0_txd_3, rgmii_1_rx_ctl, rgmii_1_rxc, rgmii_1_rxd_0,
+ rgmii_1_rxd_1, rgmii_1_rxd_2, rgmii_1_rxd_3,
+ rgmii_1_tx_ctl, rgmii_1_txc, rgmii_1_txd_0, rgmii_1_txd_1,
+ rgmii_1_txd_2, rgmii_1_txd_3, rgmii_gpio_0, rgmii_gpio_1,
+ rgmii_gpio_2, rgmii_gpio_3, rtxdata2g_txdata3g1,
+ rtxen2g_txdata3g2, rxdata3g0, rxdata3g1, rxdata3g2,
+ sdio1_clk, sdio1_cmd, sdio1_data_0, sdio1_data_1,
+ sdio1_data_2, sdio1_data_3, sdio4_clk, sdio4_cmd,
+ sdio4_data_0, sdio4_data_1, sdio4_data_2, sdio4_data_3,
+ sim_clk, sim_data, sim_det, sim_resetn, sim2_clk,
+ sim2_data, sim2_det, sim2_resetn, sri_c, sri_d, sri_e,
+ ssp_extclk, ssp0_clk, ssp0_fs, ssp0_rxd, ssp0_txd,
+ ssp2_clk, ssp2_fs_0, ssp2_fs_1, ssp2_fs_2, ssp2_fs_3,
+ ssp2_rxd_0, ssp2_rxd_1, ssp2_txd_0, ssp2_txd_1, ssp3_clk,
+ ssp3_fs, ssp3_rxd, ssp3_txd, ssp4_clk, ssp4_fs, ssp4_rxd,
+ ssp4_txd, ssp5_clk, ssp5_fs, ssp5_rxd, ssp5_txd, ssp6_clk,
+ ssp6_fs, ssp6_rxd, ssp6_txd, stat_1, stat_2, sysclken,
+ traceclk, tracedt00, tracedt01, tracedt02, tracedt03,
+ tracedt04, tracedt05, tracedt06, tracedt07, tracedt08
+ tracedt09, tracedt10, tracedt11, tracedt12, tracedt13
+ tracedt14, tracedt15, txdata3g0, txpwrind, uartb1_ucts,
+ uartb1_urts, uartb1_urxd, uartb1_utxd, uartb2_urxd,
+ uartb2_utxd, uartb3_ucts, uartb3_urts, uartb3_urxd,
+ uartb3_utxd, uartb4_ucts, uartb4_urts, uartb4_urxd,
+ uartb4_utxd, vc_cam1_scl, vc_cam1_sda, vc_cam2_scl,
+ vc_cam2_sda, vc_cam3_scl, vc_cam3_sda ]
+
+ function:
+ description:
+ Specifies the pin mux selection.
+ enum: [ alt1, alt2, alt3, alt4 ]
+
+ slew-rate:
+ description: |
+ Meaning depends on configured pin mux:
+ *_scl or *_sda:
+ 0: Standard (100 kbps) & Fast (400 kbps) mode
+ 1: Highspeed (3.4 Mbps) mode
+ ic_dm or ic_dp:
+ 0: normal slew rate
+ 1: fast slew rate
+ Otherwise:
+ 0: fast slew rate
+ 1: normal slew rate
+
+ bias-disable: true
+ input-disable: true
+ input-enable: true
+
+ required:
+ - pins
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+
+ # Optional properties for standard pins
+ - if:
+ properties:
+ pins:
+ contains:
+ enum: [ adcsync, bat_rm, classgpwr, clk_cx8, clkout_0,
+ clkout_1, clkout_2, clkout_3, clkreq_in_0,
+ clkreq_in_1, cws_sys_req1, cws_sys_req2,
+ cws_sys_req3, digmic1_clk, digmic1_dq, digmic2_clk,
+ digmic2_dq, gpen13, gpen14, gpen15, gpio00, gpio01,
+ gpio02, gpio03, gpio04, gpio05, gpio06, gpio07,
+ gpio08, gpio09, gpio10, gpio11, gpio12, gpio13,
+ gpio14, gps_pablank, gps_tmark, ic_dm, ic_dp,
+ kp_col_ip_0, kp_col_ip_1, kp_col_ip_2, kp_col_ip_3,
+ kp_row_op_0, kp_row_op_1, kp_row_op_2, kp_row_op_3,
+ lcd_b_0, lcd_b_1, lcd_b_2, lcd_b_3, lcd_b_4, lcd_b_5,
+ lcd_b_6, lcd_b_7, lcd_g_0, lcd_g_1, lcd_g_2, lcd_g_3,
+ lcd_g_4, lcd_g_5, lcd_g_6, lcd_g_7, lcd_hsync,
+ lcd_oe, lcd_pclk, lcd_r_0, lcd_r_1, lcd_r_2,
+ lcd_r_3, lcd_r_4, lcd_r_5, lcd_r_6, lcd_r_7,
+ lcd_vsync, mdmgpio0, mdmgpio1, mdmgpio2, mdmgpio3,
+ mdmgpio4, mdmgpio5, mdmgpio6, mdmgpio7, mdmgpio8,
+ mphi_data_0, mphi_data_1, mphi_data_2, mphi_data_3,
+ mphi_data_4, mphi_data_5, mphi_data_6, mphi_data_7,
+ mphi_data_8, mphi_data_9, mphi_data_10,
+ mphi_data_11, mphi_data_12, mphi_data_13,
+ mphi_data_14, mphi_data_15, mphi_ha0, mphi_hat0,
+ mphi_hat1, mphi_hce0_n, mphi_hce1_n, mphi_hrd_n,
+ mphi_hwr_n, mphi_run0, mphi_run1, mtx_scan_clk,
+ mtx_scan_data, nand_ad_0, nand_ad_1, nand_ad_2,
+ nand_ad_3, nand_ad_4, nand_ad_5, nand_ad_6,
+ nand_ad_7, nand_ale, nand_cen_0, nand_cen_1,
+ nand_cle, nand_oen, nand_rdy_0, nand_rdy_1,
+ nand_wen, nand_wp, pc1, pc2, pmu_int,
+ rfst2g_mtsloten3g, rgmii_0_rx_ctl, rgmii_0_rxc,
+ rgmii_0_rxd_0, rgmii_0_rxd_1, rgmii_0_rxd_2,
+ rgmii_0_rxd_3, rgmii_0_tx_ctl, rgmii_0_txc,
+ rgmii_0_txd_0, rgmii_0_txd_1, rgmii_0_txd_2,
+ rgmii_0_txd_3, rgmii_1_rx_ctl, rgmii_1_rxc,
+ rgmii_1_rxd_0, rgmii_1_rxd_1, rgmii_1_rxd_2,
+ rgmii_1_rxd_3, rgmii_1_tx_ctl, rgmii_1_txc,
+ rgmii_1_txd_0, rgmii_1_txd_1, rgmii_1_txd_2,
+ rgmii_1_txd_3, rgmii_gpio_0, rgmii_gpio_1,
+ rgmii_gpio_2, rgmii_gpio_3, rtxdata2g_txdata3g1,
+ rtxen2g_txdata3g2, rxdata3g0, rxdata3g1, rxdata3g2,
+ sdio1_clk, sdio1_cmd, sdio1_data_0, sdio1_data_1,
+ sdio1_data_2, sdio1_data_3, sdio4_clk, sdio4_cmd,
+ sdio4_data_0, sdio4_data_1, sdio4_data_2,
+ sdio4_data_3, sim_clk, sim_data, sim_det,
+ sim_resetn, sim2_clk, sim2_data, sim2_det,
+ sim2_resetn, sri_c, sri_d, sri_e, ssp_extclk,
+ ssp0_clk, ssp0_fs, ssp0_rxd, ssp0_txd, ssp2_clk,
+ ssp2_fs_0, ssp2_fs_1, ssp2_fs_2, ssp2_fs_3,
+ ssp2_rxd_0, ssp2_rxd_1, ssp2_txd_0, ssp2_txd_1,
+ ssp3_clk, ssp3_fs, ssp3_rxd, ssp3_txd, ssp4_clk,
+ ssp4_fs, ssp4_rxd, ssp4_txd, ssp5_clk, ssp5_fs,
+ ssp5_rxd, ssp5_txd, ssp6_clk, ssp6_fs, ssp6_rxd,
+ ssp6_txd, stat_1, stat_2, sysclken, traceclk,
+ tracedt00, tracedt01, tracedt02, tracedt03,
+ tracedt04, tracedt05, tracedt06, tracedt07,
+ tracedt08, tracedt09, tracedt10, tracedt11,
+ tracedt12, tracedt13, tracedt14, tracedt15,
+ txdata3g0, txpwrind, uartb1_ucts, uartb1_urts,
+ uartb1_urxd, uartb1_utxd, uartb2_urxd, uartb2_utxd,
+ uartb3_ucts, uartb3_urts, uartb3_urxd, uartb3_utxd,
+ uartb4_ucts, uartb4_urts, uartb4_urxd, uartb4_utxd ]
+ then:
+ properties:
+ drive-strength:
+ enum: [ 2, 4, 6, 8, 10, 12, 14, 16 ]
+
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+
+ # Optional properties for I2C pins
+ - if:
+ properties:
+ pins:
+ contains:
+ enum: [ bsc1_scl, bsc1_sda, bsc2_scl, bsc2_sda, pmu_scl,
+ pmu_sda, vc_cam1_scl, vc_cam1_sda, vc_cam2_scl,
+ vc_cam2_sda, vc_cam3_scl, vc_cam3_sda ]
+ then:
+ properties:
+ bias-pull-up:
+ description:
+ There are 3 pull-up resistors (1.2k, 1.8k, 2.7k) available
+ in parallel for I2C pins.
+ enum: [ 568, 720, 831, 1080, 1200, 1800, 2700 ]
+
+ bias-disable: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pinctrl@35004800 {
+ compatible = "brcm,bcm11351-pinctrl";
+ reg = <0x35004800 0x430>;
+
+ dev-a-active-pins {
+ /* group node defining 1 standard pin */
+ std-grp0 {
+ pins = "gpio00";
+ function = "alt1";
+ input-schmitt-enable;
+ bias-disable;
+ slew-rate = <1>;
+ drive-strength = <4>;
+ };
+
+ /* group node defining 2 I2C pins */
+ i2c-grp0 {
+ pins = "bsc1_scl", "bsc1_sda";
+ function = "alt2";
+ bias-pull-up = <720>;
+ input-enable;
+ };
+
+ /* group node defining 2 HDMI pins */
+ hdmi-grp0 {
+ pins = "hdmi_scl", "hdmi_sda";
+ function = "alt3";
+ slew-rate = <1>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml
new file mode 100644
index 000000000000..a2e609b066ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,bcm21664-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM21664 pin controller
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm21664-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '-grp[0-9]$':
+ type: object
+
+ properties:
+ pins:
+ description:
+ Specifies the name(s) of one or more pins to be configured by
+ this node.
+ items:
+ enum: [ adcsyn, batrm, bsc1clk, bsc1dat, camcs0, camcs1, clk32k,
+ clk_cx8, dclk1, dclk4, dclkreq1, dclkreq4, dmic0clk,
+ dmic0dq, dsi0te, gpio00, gpio01, gpio02, gpio03, gpio04,
+ gpio05, gpio06, gpio07, gpio08, gpio09, gpio10, gpio11,
+ gpio12, gpio13, gpio14, gpio15, gpio16, gpio17, gpio18,
+ gpio19, gpio20, gpio21, gpio22, gpio23, gpio24, gpio25,
+ gpio26, gpio27, gpio28, gpio32, gpio33, gpio34, gpio93,
+ gpio94, gps_calreq, gps_hostreq, gps_pablank, gps_tmark,
+ icusbdm, icusbdp, lcdcs0, lcdres, lcdscl, lcdsda, lcdte,
+ mdmgpio00, mdmgpio01, mdmgpio02, mdmgpio03, mdmgpio04,
+ mdmgpio05, mdmgpio06, mdmgpio07, mdmgpio08, mmc0ck,
+ mmc0cmd, mmc0dat0, mmc0dat1, mmc0dat2, mmc0dat3, mmc0dat4,
+ mmc0dat5, mmc0dat6, mmc0dat7, mmc0rst, mmc1ck, mmc1cmd,
+ mmc1dat0, mmc1dat1, mmc1dat2, mmc1dat3, mmc1dat4,
+ mmc1dat5, mmc1dat6, mmc1dat7, mmc1rst, pc1, pc2, pmbscclk,
+ pmbscdat, pmuint, resetn, rfst2g_mtsloten3g,
+ rtxdata2g_txdata3g1, rtxen2g_txdata3g2, rxdata3g0,
+ rxdata3g1, rxdata3g2, sdck, sdcmd, sddat0, sddat1, sddat2,
+ sddat3, simclk, simdat, simdet, simrst, spi0clk, spi0fss,
+ spi0rxd, spi0txd, sri_c, sri_d, sri_e, sspck, sspdi,
+ sspdo, sspsyn, stat1, stat2, swclktck, swdiotms, sysclken,
+ tdi, tdo, testmode, traceclk, tracedt00, tracedt01,
+ tracedt02, tracedt03, tracedt04, tracedt05, tracedt06,
+ tracedt07, tracedt08, tracedt09, tracedt10, tracedt11,
+ tracedt12, tracedt13, tracedt14, tracedt15, trstb,
+ txdata3g0, ubctsn, ubrtsn, ubrx, ubtx ]
+
+ function:
+ description:
+ Specifies the pin mux selection.
+ enum: [ alt1, alt2, alt3, alt4, alt5, alt6 ]
+
+ bias-disable: true
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ slew-rate:
+ description: |
+ Meaning depends on configured pin mux:
+ bsc*clk/pmbscclk or bsc*dat/pmbscdat or gpio16/gpio17:
+ 0: Standard (100 kbps) & Fast (400 kbps) mode
+ 1: Highspeed (3.4 Mbps) mode
+ Otherwise:
+ 0: fast slew rate
+ 1: normal slew rate
+
+ drive-strength:
+ enum: [ 2, 4, 6, 8, 10, 12, 14, 16 ]
+
+ input-enable: true
+ input-disable: true
+
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ # Limitations for I2C pins
+ - if:
+ properties:
+ pins:
+ contains:
+ enum: [ bsc1clk, bsc1dat, gpio16, gpio17, pmbscclk,
+ pmbscdat ]
+ then:
+ properties:
+ drive-strength: false
+ bias-pull-down: false
+ input-schmitt-enable: false
+ input-schmitt-disable: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pinctrl@35004800 {
+ compatible = "brcm,bcm21664-pinctrl";
+ reg = <0x35004800 0x7f0>;
+
+ dev-a-active-pins {
+ /* group node defining 1 standard pin */
+ std-grp0 {
+ pins = "gpio00";
+ function = "alt1";
+ input-schmitt-enable;
+ bias-disable;
+ slew-rate = <1>;
+ drive-strength = <4>;
+ };
+
+ /* group node defining 2 I2C pins */
+ i2c-grp0 {
+ pins = "bsc1clk", "bsc1dat";
+ function = "alt2";
+ bias-pull-up;
+ input-enable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2712c0-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2712c0-pinctrl.yaml
new file mode 100644
index 000000000000..ae6c13a746b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2712c0-pinctrl.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,bcm2712c0-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom STB family pin controller
+
+maintainers:
+ - Ivan T. Ivanov <iivanov@suse.de>
+ - A. della Porta <andrea.porta@suse.com>
+
+description: >
+ Broadcom's STB family of memory-mapped pin controllers.
+
+ This includes the pin controllers inside the BCM2712 SoC which
+ are instances of the STB family and has two silicon variants,
+ C0 and D0, which differs slightly in terms of registers layout.
+
+ The -aon- (Always On) variant is the same IP block but differs
+ in the number of pins that are associated and the pinmux functions
+ for each of those pins.
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2712c0-pinctrl
+ - brcm,bcm2712c0-aon-pinctrl
+ - brcm,bcm2712d0-pinctrl
+ - brcm,bcm2712d0-aon-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-state$':
+ oneOf:
+ - $ref: '#/$defs/brcmstb-pinctrl-state'
+ - patternProperties:
+ '-pins$':
+ $ref: '#/$defs/brcmstb-pinctrl-state'
+ additionalProperties: false
+
+$defs:
+ brcmstb-pinctrl-state:
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ description: >
+ Pin controller client devices use pin configuration subnodes (children
+ and grandchildren) for desired pin configuration.
+
+ Client device subnodes use below standard properties.
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode (either this or "groups" must be specified).
+ items:
+ pattern: '^((aon_)?s?gpio[0-6]?[0-9])|(emmc_(clk|cmd|dat[0-7]|ds))$'
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, alt1, alt2, alt3, alt4, alt5, alt6, alt7, alt8,
+ aon_cpu_standbyb, aon_fp_4sec_resetb, aon_gpclk, aon_pwm,
+ arm_jtag, aud_fs_clk0, avs_pmu_bsc, bsc_m0, bsc_m1, bsc_m2,
+ bsc_m3, clk_observe, ctl_hdmi_5v, enet0, enet0_mii, enet0_rgmii,
+ ext_sc_clk, fl0, fl1, gpclk0, gpclk1, gpclk2, hdmi_tx0_auto_i2c,
+ hdmi_tx0_bsc, hdmi_tx1_auto_i2c, hdmi_tx1_bsc, i2s_in, i2s_out,
+ ir_in, mtsif, mtsif_alt, mtsif_alt1, pdm, pkt, pm_led_out, sc0,
+ sd0, sd2, sd_card_a, sd_card_b, sd_card_c, sd_card_d, sd_card_e,
+ sd_card_f, sd_card_g, spdif_out, spi_m, spi_s, sr_edm_sense, te0,
+ te1, tsio, uart0, uart1, uart2, usb_pwr, usb_vbus, uui, vc_i2c0,
+ vc_i2c3, vc_i2c4, vc_i2c5, vc_i2csl, vc_pcm, vc_pwm0, vc_pwm1,
+ vc_spi0, vc_spi3, vc_spi4, vc_spi5, vc_uart0, vc_uart2, vc_uart3,
+ vc_uart4 ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+
+ required:
+ - pins
+
+ if:
+ properties:
+ pins:
+ not:
+ contains:
+ pattern: "^emmc_(clk|cmd|dat[0-7]|ds)$"
+ then:
+ required:
+ - function
+ else:
+ properties:
+ function: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pinctrl@7d504100 {
+ compatible = "brcm,bcm2712c0-pinctrl";
+ reg = <0x7d504100 0x30>;
+
+ bt-shutdown-default-state {
+ function = "gpio";
+ pins = "gpio29";
+ };
+
+ uarta-default-state {
+ rts-tx-pins {
+ function = "uart0";
+ pins = "gpio24", "gpio26";
+ bias-disable;
+ };
+
+ cts-rx-pins {
+ function = "uart0";
+ pins = "gpio25", "gpio27";
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
deleted file mode 100644
index 5682b2010e50..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-Broadcom BCM2835 GPIO (and pinmux) controller
-
-The BCM2835 GPIO module is a combined GPIO controller, (GPIO) interrupt
-controller, and pinmux/control device.
-
-Required properties:
-- compatible: "brcm,bcm2835-gpio"
-- compatible: should be one of:
- "brcm,bcm2835-gpio" - BCM2835 compatible pinctrl
- "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
- "brcm,bcm2711-gpio" - BCM2711 compatible pinctrl
- "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
-- reg: Should contain the physical address of the GPIO module's registers.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted)
-- interrupts : The interrupt outputs from the controller. One interrupt per
- individual bank followed by the "all banks" interrupt. For BCM7211, an
- additional set of per-bank interrupt line and an "all banks" wake-up
- interrupt may be specified.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells : Should be 2.
- The first cell is the GPIO number.
- The second cell is used to specify flags:
- bits[3:0] trigger type and level flags:
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 4 = active high level-sensitive.
- 8 = active low level-sensitive.
- Valid combinations are 1, 2, 3, 4, 8.
-
-Please refer to ../gpio/gpio.txt for a general description of GPIO bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Each pin configuration node lists the pin(s) to which it applies, and one or
-more of the mux function to select on those pin(s), and pull-up/down
-configuration. Each subnode only affects those parameters that are explicitly
-listed. In other words, a subnode that lists only a mux function implies no
-information about any pull configuration. Similarly, a subnode that lists only
-a pul parameter implies no information about the mux function.
-
-The BCM2835 pin configuration and multiplexing supports the generic bindings.
-For details on each properties, you can refer to ./pinctrl-bindings.txt.
-
-Required sub-node properties:
- - pins
- - function
-
-Optional sub-node properties:
- - bias-disable
- - bias-pull-up
- - bias-pull-down
- - output-high
- - output-low
-
-Legacy pin configuration and multiplexing binding:
-*** (Its use is deprecated, use generic multiplexing and configuration
-bindings instead)
-
-Required subnode-properties:
-- brcm,pins: An array of cells. Each cell contains the ID of a pin. Valid IDs
- are the integer GPIO IDs; 0==GPIO0, 1==GPIO1, ... 53==GPIO53.
-
-Optional subnode-properties:
-- brcm,function: Integer, containing the function to mux to the pin(s):
- 0: GPIO in
- 1: GPIO out
- 2: alt5
- 3: alt4
- 4: alt0
- 5: alt1
- 6: alt2
- 7: alt3
-- brcm,pull: Integer, representing the pull-down/up to apply to the pin(s):
- 0: none
- 1: down
- 2: up
-
-Each of brcm,function and brcm,pull may contain either a single value which
-will be applied to all pins in brcm,pins, or 1 value for each entry in
-brcm,pins.
-
-Example:
-
- gpio: gpio {
- compatible = "brcm,bcm2835-gpio";
- reg = <0x2200000 0xb4>;
- interrupts = <2 17>, <2 19>, <2 18>, <2 20>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.yaml
new file mode 100644
index 000000000000..6514f347f6bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,bcm2835-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 GPIO (and pinmux) controller
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+description: >
+ The BCM2835 GPIO module is a combined GPIO controller, (GPIO) interrupt
+ controller, and pinmux/control device.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-gpio
+ - brcm,bcm2711-gpio
+ - brcm,bcm7211-gpio
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+ gpio-ranges: true
+ gpio-line-names: true
+
+ interrupts:
+ description: >
+ Interrupt outputs: one per bank, then the combined “all banks” line.
+ BCM7211 may specify up to four per-bank wake-up lines and one combined
+ wake-up interrupt.
+ minItems: 4
+ maxItems: 10
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+additionalProperties:
+ oneOf:
+ - type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^pins?-':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins: true
+ function: true
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ - type: object
+ additionalProperties: false
+ deprecated: true
+
+ properties:
+ brcm,pins:
+ description:
+ GPIO pin numbers for legacy configuration.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ brcm,function:
+ description:
+ Legacy mux function for the pins (0=input, 1=output, 2–7=alt functions).
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maximum: 7
+
+ brcm,pull:
+ description: >
+ Legacy pull setting for the pins (0=none, 1=pull-down, 2=pull-up).
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maximum: 2
+
+ required:
+ - brcm,pins
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm2835-gpio
+ - brcm,bcm2711-gpio
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+
+examples:
+ - |
+ gpio@2200000 {
+ compatible = "brcm,bcm2835-gpio";
+ reg = <0x2200000 0xb4>;
+ interrupts = <2 17>, <2 19>, <2 18>, <2 20>, <2 21>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml
index 175a992f15e1..8a9fb9b433ca 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml
@@ -23,6 +23,7 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ additionalProperties: false
properties:
function:
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml
index ab019a1998e8..62890a0aead1 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml
@@ -24,6 +24,7 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ additionalProperties: false
properties:
function:
@@ -37,8 +38,12 @@ patternProperties:
enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7,
gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio40 ]
+ patternProperties:
+ '-pins$':
+ $ref: '#/patternProperties/-pins$'
+
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml
index 8c9d4668c8c4..7cc0e1650835 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml
@@ -24,6 +24,7 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ unevaluatedProperties: false
properties:
function:
@@ -36,13 +37,17 @@ patternProperties:
pins:
enum: [ gpio0, gpio1, gpio16, gpio17, gpio8, gpio9, gpio18, gpio19,
- gpio22, gpio23, gpio30, gpio31, nand_grp, gpio35
+ gpio22, gpio23, gpio30, gpio31, nand_grp, gpio35,
dectpd_grp, vdsl_phy_override_0_grp,
vdsl_phy_override_1_grp, vdsl_phy_override_2_grp,
vdsl_phy_override_3_grp, dsl_gpio8, dsl_gpio9 ]
+ patternProperties:
+ '-pins$':
+ $ref: '#/patternProperties/-pins$'
+
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -122,46 +127,46 @@ examples:
pinctrl_nand: nand-pins {
function = "nand";
- group = "nand_grp";
+ pins = "nand_grp";
};
pinctrl_gpio35_alt: gpio35_alt-pins {
function = "gpio35_alt";
- pin = "gpio35";
+ pins = "gpio35";
};
pinctrl_dectpd: dectpd-pins {
function = "dectpd";
- group = "dectpd_grp";
+ pins = "dectpd_grp";
};
pinctrl_vdsl_phy_override_0: vdsl_phy_override_0-pins {
function = "vdsl_phy_override_0";
- group = "vdsl_phy_override_0_grp";
+ pins = "vdsl_phy_override_0_grp";
};
pinctrl_vdsl_phy_override_1: vdsl_phy_override_1-pins {
function = "vdsl_phy_override_1";
- group = "vdsl_phy_override_1_grp";
+ pins = "vdsl_phy_override_1_grp";
};
pinctrl_vdsl_phy_override_2: vdsl_phy_override_2-pins {
function = "vdsl_phy_override_2";
- group = "vdsl_phy_override_2_grp";
+ pins = "vdsl_phy_override_2_grp";
};
pinctrl_vdsl_phy_override_3: vdsl_phy_override_3-pins {
function = "vdsl_phy_override_3";
- group = "vdsl_phy_override_3_grp";
+ pins = "vdsl_phy_override_3_grp";
};
pinctrl_dsl_gpio8: dsl_gpio8-pins {
function = "dsl_gpio8";
- group = "dsl_gpio8";
+ pins = "dsl_gpio8";
};
pinctrl_dsl_gpio9: dsl_gpio9-pins {
function = "dsl_gpio9";
- group = "dsl_gpio9";
+ pins = "dsl_gpio9";
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml
index a8e22ec02215..f57bb34c3130 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml
@@ -24,6 +24,7 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ unevaluatedProperties: false
properties:
function:
@@ -36,8 +37,12 @@ patternProperties:
gpio20, gpio25, gpio26, gpio27, gpio28, hsspi_cs1,
usb_port1 ]
+ patternProperties:
+ '-pins$':
+ $ref: '#/patternProperties/-pins$'
+
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml
index 35867355a47a..ce6fc5380c52 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml
@@ -24,18 +24,19 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ unevaluatedProperties: false
properties:
function:
enum: [ ebi_cs, uart1, serial_led, legacy_led, led, spi_cs, utopia,
pwm_syn_clk, sys_irq ]
- pins:
+ groups:
enum: [ ebi_cs_grp, uart1_grp, serial_led_grp, legacy_led_grp,
- led_grp, spi_cs_grp, utopia_grp, pwm_syn_clk, sys_irq_grp ]
+ led_grp, spi_cs_grp, utopia_grp, pwm_syn_clk_grp, sys_irq_grp ]
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml
index b584d4b27223..5f7ed7d3dd49 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml
@@ -24,6 +24,7 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ unevaluatedProperties: false
properties:
function:
@@ -41,8 +42,12 @@ patternProperties:
gpio15, gpio16, gpio17, gpio18, gpio19, gpio20, gpio21,
gpio22, gpio23, gpio24, gpio25, gpio26, gpio27, nand_grp ]
+ patternProperties:
+ '-pins$':
+ $ref: '#/patternProperties/-pins$'
+
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -204,6 +209,6 @@ examples:
pinctrl_nand: nand-pins {
function = "nand";
- group = "nand_grp";
+ pins = "nand_grp";
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml
index 229323d9237d..d549e945505b 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml
@@ -24,6 +24,7 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ unevaluatedProperties: false
properties:
function:
@@ -42,8 +43,12 @@ patternProperties:
gpio24, gpio25, gpio26, gpio27, gpio28, gpio29, gpio30,
gpio31, uart1_grp ]
+ patternProperties:
+ '-pins$':
+ $ref: '#/patternProperties/-pins$'
+
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -215,6 +220,6 @@ examples:
pinctrl_uart1: uart1-pins {
function = "uart1";
- group = "uart1_grp";
+ pins = "uart1_grp";
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
deleted file mode 100644
index a73cbeb0f309..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
+++ /dev/null
@@ -1,123 +0,0 @@
-Broadcom iProc GPIO/PINCONF Controller
-
-Required properties:
-
-- compatible:
- "brcm,iproc-gpio" for the generic iProc based GPIO controller IP that
- supports full-featured pinctrl and GPIO functions used in various iProc
- based SoCs
-
- May contain an SoC-specific compatibility string to accommodate any
- SoC-specific features
-
- "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", or
- "brcm,cygnus-crmu-gpio" for Cygnus SoCs
-
- "brcm,iproc-nsp-gpio" for the iProc NSP SoC that has drive strength support
- disabled
-
- "brcm,iproc-stingray-gpio" for the iProc Stingray SoC that has the general
- pinctrl support completely disabled in this IP block. In Stingray, a
- different IP block is used to handle pinctrl related functions
-
-- reg:
- Define the base and range of the I/O address space that contains SoC
-GPIO/PINCONF controller registers
-
-- ngpios:
- Total number of in-use slots in GPIO controller
-
-- #gpio-cells:
- Must be two. The first cell is the GPIO pin number (within the
-controller's pin space) and the second cell is used for the following:
- bit[0]: polarity (0 for active high and 1 for active low)
-
-- gpio-controller:
- Specifies that the node is a GPIO controller
-
-Optional properties:
-
-- interrupts:
- Interrupt ID
-
-- interrupt-controller:
- Specifies that the node is an interrupt controller
-
-- gpio-ranges:
- Specifies the mapping between gpio controller and pin-controllers pins.
- This requires 4 fields in cells defined as -
- 1. Phandle of pin-controller.
- 2. GPIO base pin offset.
- 3 Pin-control base pin offset.
- 4. number of gpio pins which are linearly mapped from pin base.
-
-Supported generic PINCONF properties in child nodes:
-
-- pins:
- The list of pins (within the controller's own pin space) that properties
-in the node apply to. Pin names are "gpio-<pin>"
-
-- bias-disable:
- Disable pin bias
-
-- bias-pull-up:
- Enable internal pull up resistor
-
-- bias-pull-down:
- Enable internal pull down resistor
-
-- drive-strength:
- Valid drive strength values include 2, 4, 6, 8, 10, 12, 14, 16 (mA)
-
-Example:
- gpio_ccm: gpio@1800a000 {
- compatible = "brcm,cygnus-ccm-gpio";
- reg = <0x1800a000 0x50>,
- <0x0301d164 0x20>;
- ngpios = <24>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
-
- touch_pins: touch_pins {
- pwr: pwr {
- pins = "gpio-0";
- drive-strength = <16>;
- };
-
- event: event {
- pins = "gpio-1";
- bias-pull-up;
- };
- };
- };
-
- gpio_asiu: gpio@180a5000 {
- compatible = "brcm,cygnus-asiu-gpio";
- reg = <0x180a5000 0x668>;
- ngpios = <146>;
- #gpio-cells = <2>;
- gpio-controller;
- interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- gpio-ranges = <&pinctrl 0 42 1>,
- <&pinctrl 1 44 3>;
- };
-
- /*
- * Touchscreen that uses the CCM GPIO 0 and 1
- */
- tsc {
- ...
- ...
- gpio-pwr = <&gpio_ccm 0 0>;
- gpio-event = <&gpio_ccm 1 0>;
- };
-
- /* Bluetooth that uses the ASIU GPIO 5, with polarity inverted */
- bluetooth {
- ...
- ...
- bcm,rfkill-bank-sel = <&gpio_asiu 5 1>
- }
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.yaml
new file mode 100644
index 000000000000..a0ed308b7fc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,iproc-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom iProc GPIO/PINCONF Controller
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - brcm,cygnus-asiu-gpio
+ - brcm,cygnus-ccm-gpio
+ - brcm,cygnus-crmu-gpio
+ - brcm,iproc-gpio
+ - brcm,iproc-stingray-gpio
+ - items:
+ - enum:
+ - brcm,iproc-hr2-gpio
+ - brcm,iproc-nsp-gpio
+ - const: brcm,iproc-gpio
+
+ reg:
+ minItems: 1
+ items:
+ - description: GPIO Bank registers
+ - description: IO Ctrl registers
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-controller: true
+
+ gpio-ranges: true
+
+ ngpios: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+required:
+ - compatible
+ - reg
+ - "#gpio-cells"
+ - gpio-controller
+ - ngpios
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties:
+ description: Pin configuration child nodes.
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins:
+ items:
+ pattern: '^gpio-'
+
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+
+ drive-strength:
+ enum: [ 2, 4, 6, 8, 10, 12, 14, 16 ]
+
+ required:
+ - pins
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpio@1800a000 {
+ compatible = "brcm,cygnus-ccm-gpio";
+ reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+ ngpios = <24>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+
+ touch-pins {
+ pwr {
+ pins = "gpio-0";
+ drive-strength = <16>;
+ };
+
+ event {
+ pins = "gpio-1";
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml
index 8d1e5b1cdd5f..0a39dd26ee1a 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml
@@ -53,7 +53,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt
deleted file mode 100644
index 40e0a9a19525..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt
+++ /dev/null
@@ -1,102 +0,0 @@
-Broadcom Northstar2 IOMUX Controller
-
-The Northstar2 IOMUX controller supports group based mux configuration. There
-are some individual pins that support modifying the pinconf parameters.
-
-Required properties:
-
-- compatible:
- Must be "brcm,ns2-pinmux"
-
-- reg:
- Define the base and range of the I/O address space that contains the
- Northstar2 IOMUX and pin configuration registers.
-
-Properties in sub nodes:
-
-- function:
- The mux function to select
-
-- groups:
- The list of groups to select with a given function
-
-- pins:
- List of pin names to change configuration
-
-The generic properties bias-disable, bias-pull-down, bias-pull-up,
-drive-strength, slew-rate, input-enable, input-disable are supported
-for some individual pins listed at the end.
-
-For more details, refer to
-Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-For example:
-
- pinctrl: pinctrl@6501d130 {
- compatible = "brcm,ns2-pinmux";
- reg = <0x6501d130 0x08>,
- <0x660a0028 0x04>,
- <0x660009b0 0x40>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&nand_sel>, <&uart3_rx>, <&sdio0_d4>;
-
- /* Select nand function */
- nand_sel: nand_sel {
- function = "nand";
- groups = "nand_grp";
- };
-
- /* Pull up the uart3 rx pin */
- uart3_rx: uart3_rx {
- pins = "uart3_sin";
- bias-pull-up;
- };
-
- /* Set the drive strength of sdio d4 pin */
- sdio0_d4: sdio0_d4 {
- pins = "sdio0_data4";
- drive-strength = <8>;
- };
- };
-
-List of supported functions and groups in Northstar2:
-
-"nand": "nand_grp"
-
-"nor": "nor_data_grp", "nor_adv_grp", "nor_addr_0_3_grp", "nor_addr_4_5_grp",
- "nor_addr_6_7_grp", "nor_addr_8_9_grp", "nor_addr_10_11_grp",
- "nor_addr_12_15_grp"
-
-"gpio": "gpio_0_1_grp", "gpio_2_5_grp", "gpio_6_7_grp", "gpio_8_9_grp",
- "gpio_10_11_grp", "gpio_12_13_grp", "gpio_14_17_grp", "gpio_18_19_grp",
- "gpio_20_21_grp", "gpio_22_23_grp", "gpio_24_25_grp", "gpio_26_27_grp",
- "gpio_28_29_grp", "gpio_30_31_grp"
-
-"pcie": "pcie_ab1_clk_wak_grp", "pcie_a3_clk_wak_grp", "pcie_b3_clk_wak_grp",
- "pcie_b2_clk_wak_grp", "pcie_a2_clk_wak_grp"
-
-"uart0": "uart0_modem_grp", "uart0_rts_cts_grp", "uart0_in_out_grp"
-
-"uart1": "uart1_ext_clk_grp", "uart1_dcd_dsr_grp", "uart1_ri_dtr_grp",
- "uart1_rts_cts_grp", "uart1_in_out_grp"
-
-"uart2": "uart2_rts_cts_grp"
-
-"pwm": "pwm_0_grp", "pwm_1_grp", "pwm_2_grp", "pwm_3_grp"
-
-
-List of pins that support pinconf parameters:
-
-"qspi_wp", "qspi_hold", "qspi_cs", "qspi_sck", "uart3_sin", "uart3_sout",
-"qspi_mosi", "qspi_miso", "spi0_fss", "spi0_rxd", "spi0_txd", "spi0_sck",
-"spi1_fss", "spi1_rxd", "spi1_txd", "spi1_sck", "sdio0_data7",
-"sdio0_emmc_rst", "sdio0_led_on", "sdio0_wp", "sdio0_data3", "sdio0_data4",
-"sdio0_data5", "sdio0_data6", "sdio0_cmd", "sdio0_data0", "sdio0_data1",
-"sdio0_data2", "sdio1_led_on", "sdio1_wp", "sdio0_cd_l", "sdio0_clk",
-"sdio1_data5", "sdio1_data6", "sdio1_data7", "sdio1_emmc_rst", "sdio1_data1",
-"sdio1_data2", "sdio1_data3", "sdio1_data4", "sdio1_cd_l", "sdio1_clk",
-"sdio1_cmd", "sdio1_data0", "ext_mdio_0", "ext_mdc_0", "usb3_p1_vbus_ppc",
-"usb3_p1_overcurrent", "usb3_p0_vbus_ppc", "usb3_p0_overcurrent",
-"usb2_presence_indication", "usb2_vbus_present", "usb2_vbus_ppc",
-"usb2_overcurrent", "sata_led1", "sata_led0"
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.yaml
new file mode 100644
index 000000000000..1de23c06fa49
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/brcm,ns2-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar2 IOMUX Controller
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+properties:
+ compatible:
+ const: brcm,ns2-pinmux
+
+ reg:
+ maxItems: 3
+
+additionalProperties:
+ description: Pin group node properties
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ description: The mux function to select
+ $ref: /schemas/types.yaml#/definitions/string
+
+ groups:
+ items:
+ enum: [
+ nand_grp, nor_data_grp, nor_adv_grp, nor_addr_0_3_grp,
+ nor_addr_4_5_grp, nor_addr_6_7_grp, nor_addr_8_9_grp,
+ nor_addr_10_11_grp, nor_addr_12_15_grp, gpio_0_1_grp, gpio_2_5_grp,
+ gpio_6_7_grp, gpio_8_9_grp, gpio_10_11_grp, gpio_12_13_grp,
+ gpio_14_17_grp, gpio_18_19_grp, gpio_20_21_grp, gpio_22_23_grp,
+ gpio_24_25_grp, gpio_26_27_grp, gpio_28_29_grp, gpio_30_31_grp,
+ pcie_ab1_clk_wak_grp, pcie_a3_clk_wak_grp, pcie_b3_clk_wak_grp,
+ pcie_b2_clk_wak_grp, pcie_a2_clk_wak_grp, uart0_modem_grp,
+ uart0_rts_cts_grp, uart0_in_out_grp, uart1_ext_clk_grp,
+ uart1_dcd_dsr_grp, uart1_ri_dtr_grp, uart1_rts_cts_grp,
+ uart1_in_out_grp, uart2_rts_cts_grp, pwm_0_grp, pwm_1_grp, pwm_2_grp,
+ pwm_3_grp
+ ]
+
+ pins:
+ items:
+ enum: [
+ qspi_wp, qspi_hold, qspi_cs, qspi_sck, uart3_sin, uart3_sout,
+ qspi_mosi, qspi_miso, spi0_fss, spi0_rxd, spi0_txd, spi0_sck,
+ spi1_fss, spi1_rxd, spi1_txd, spi1_sck, sdio0_data7, sdio0_emmc_rst,
+ sdio0_led_on, sdio0_wp, sdio0_data3, sdio0_data4, sdio0_data5,
+ sdio0_data6, sdio0_cmd, sdio0_data0, sdio0_data1, sdio0_data2,
+ sdio1_led_on, sdio1_wp, sdio0_cd_l, sdio0_clk, sdio1_data5,
+ sdio1_data6, sdio1_data7, sdio1_emmc_rst, sdio1_data1, sdio1_data2,
+ sdio1_data3, sdio1_data4, sdio1_cd_l, sdio1_clk, sdio1_cmd,
+ sdio1_data0, ext_mdio_0, ext_mdc_0, usb3_p1_vbus_ppc,
+ usb3_p1_overcurrent, usb3_p0_vbus_ppc, usb3_p0_overcurrent,
+ usb2_presence_indication, usb2_vbus_present, usb2_vbus_ppc,
+ usb2_overcurrent, sata_led1, sata_led0
+ ]
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ slew-rate: true
+ input-enable: true
+ input-disable: true
+
+ oneOf:
+ - required:
+ - groups
+ - function
+ - required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ pinctrl@6501d130 {
+ compatible = "brcm,ns2-pinmux";
+ reg = <0x6501d130 0x08>,
+ <0x660a0028 0x04>,
+ <0x660009b0 0x40>;
+
+ /* Select nand function */
+ nand-sel {
+ function = "nand";
+ groups = "nand_grp";
+ };
+
+ /* Pull up the uart3 rx pin */
+ uart3-rx {
+ pins = "uart3_sin";
+ bias-pull-up;
+ };
+
+ /* Set the drive strength of sdio d4 pin */
+ sdio0-d4 {
+ pins = "sdio0_data4";
+ drive-strength = <8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
index 533b4cfe33d2..beb769e887c7 100644
--- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/pinctrl/canaan,k210-fpioa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Canaan Kendryte K210 FPIOA Device Tree Bindings
+title: Canaan Kendryte K210 FPIOA
maintainers:
- - Damien Le Moal <damien.lemoal@wdc.com>
+ - Damien Le Moal <dlemoal@kernel.org>
description:
The Canaan Kendryte K210 SoC Fully Programmable IO Array (FPIOA)
- controller allows assiging any of 256 possible functions to any of
+ controller allows assigning any of 256 possible functions to any of
48 IO pins of the SoC. Pin function configuration is performed on
a per-pin basis.
@@ -144,7 +144,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k230-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k230-pinctrl.yaml
new file mode 100644
index 000000000000..0b462eb6dfe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/canaan,k230-pinctrl.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/canaan,k230-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan Kendryte K230 Pin Controller
+
+maintainers:
+ - Ze Huang <18771902331@163.com>
+
+description:
+ The Canaan Kendryte K230 platform includes 64 IO pins, each capable of
+ multiplexing up to 5 different functions. Pin function configuration is
+ performed on a per-pin basis.
+
+properties:
+ compatible:
+ const: canaan,k230-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine.
+
+ patternProperties:
+ '-cfg$':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ additionalProperties: false
+ description:
+ Each subnode will list the pins it needs, and how they should
+ be configured, with regard to muxer configuration, bias, input
+ enable/disable, input schmitt trigger, slew-rate enable/disable,
+ slew-rate, drive strength.
+
+ properties:
+ pinmux:
+ description:
+ The list of GPIOs and their mux settings that properties in
+ the node apply to. This should be set with the macro
+ 'K230_PINMUX(pin, mode)'
+
+ bias-disable: true
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ drive-strength:
+ minimum: 0
+ maximum: 15
+
+ input-enable: true
+
+ output-enable: true
+
+ input-schmitt-enable: true
+
+ slew-rate:
+ description: |
+ slew rate control enable
+ 0: disable
+ 1: enable
+
+ enum: [0, 1]
+
+ power-source:
+ description: |
+ Specifies the power source voltage for the IO bank that the
+ pin belongs to. Each bank of IO pins operate at a specific,
+ fixed voltage levels. Incorrect voltage configuration can
+ damage the chip. The defined constants represent the
+ possible voltage configurations:
+
+ - K230_MSC_3V3 (value 0): 3.3V power supply
+ - K230_MSC_1V8 (value 1): 1.8V power supply
+
+ The following banks have the corresponding voltage
+ configurations:
+
+ - bank IO0 to IO1: Fixed at 1.8V
+ - bank IO2 to IO13: Fixed at 1.8V
+ - bank IO14 to IO25: Fixed at 1.8V
+ - bank IO26 to IO37: Fixed at 1.8V
+ - bank IO38 to IO49: Fixed at 1.8V
+ - bank IO50 to IO61: Fixed at 3.3V
+ - bank IO62 to IO63: Fixed at 1.8V
+
+ enum: [0, 1]
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@91105000 {
+ compatible = "canaan,k230-pinctrl";
+ reg = <0x91105000 0x100>;
+
+ uart2-pins {
+ uart2-pins-cfg {
+ pinmux = <0x503>, /* uart2 txd */
+ <0x603>; /* uart2 rxd */
+ slew-rate = <0>;
+ drive-strength = <4>;
+ power-source = <1>;
+ input-enable;
+ output-enable;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml
index 5cd512b7d5ba..5e000b3fadde 100644
--- a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml
@@ -173,7 +173,7 @@ properties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml
index 6bd42e43cdab..482acda88e73 100644
--- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml
@@ -40,8 +40,8 @@ properties:
'-pins$':
type: object
allOf:
- - $ref: "pincfg-node.yaml#"
- - $ref: "pinmux-node.yaml#"
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
properties:
groups:
description:
@@ -93,7 +93,8 @@ properties:
input-schmitt-disable: true
- input-debounce: true
+ input-debounce:
+ maxItems: 1
output-low: true
diff --git a/Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml
new file mode 100644
index 000000000000..8ed53496c386
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/cix,sky1-pinctrl.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/cix,sky1-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cix Sky1 Soc Pin Controller
+
+maintainers:
+ - Gary Yang <gary.yang@cixtech.com>
+
+description:
+ The pin-controller is used to control Soc pins. There are two pin-controllers
+ on Cix Sky1 platform. one is used under S0 state, the other one is used under
+ S0 and S5 state.
+
+properties:
+ compatible:
+ enum:
+ - cix,sky1-pinctrl
+ - cix,sky1-pinctrl-s5
+
+ reg:
+ items:
+ - description: gpio base
+
+patternProperties:
+ '-cfg$':
+ type: object
+ additionalProperties: false
+
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine.
+
+ patternProperties:
+ 'pins$':
+ type: object
+ additionalProperties: false
+
+ description:
+ Each subnode will list the pins it needs, and how they should
+ be configured, with regard to muxer configuration, bias pull,
+ and drive strength.
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pinmux:
+ description:
+ Values are constructed from pin number and mux setting, pin
+ number is left shifted by 8 bits, then ORed with mux setting
+
+ bias-disable: true
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ drive-strength:
+ description:
+ typical current when output high level.
+ enum: [ 2, 3, 5, 6, 8, 9, 11, 12, 13, 14, 17, 18, 20, 21, 23,
+ 24 ]
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #define CIX_PAD_GPIO012_FUNC_GPIO012 (11 << 8 | 0x0)
+ pinctrl@4170000 {
+ compatible = "cix,sky1-pinctrl";
+ reg = <0x4170000 0x1000>;
+
+ wifi_vbat_gpio: wifi-vbat-gpio-cfg {
+ pins {
+ pinmux = <CIX_PAD_GPIO012_FUNC_GPIO012>;
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml
new file mode 100644
index 000000000000..700ac86c26b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/cypress,cy8c95x0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress CY8C95X0 I2C GPIO expander
+
+maintainers:
+ - Patrick Rudolph <patrick.rudolph@9elements.com>
+
+description: |
+ This supports the 20/40/60 pin Cypress CYC95x0 GPIO I2C expanders.
+ Pin function configuration is performed on a per-pin basis.
+
+properties:
+ compatible:
+ enum:
+ - cypress,cy8c9520
+ - cypress,cy8c9540
+ - cypress,cy8c9560
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ The first cell is the GPIO number and the second cell specifies GPIO
+ flags, as defined in <dt-bindings/gpio/gpio.h>.
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-line-names: true
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 60
+
+ vdd-supply:
+ description:
+ Optional power supply.
+
+ reset-gpios:
+ description: GPIO connected to the XRES pin
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: pincfg-node.yaml#
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: '^gp([0-7][0-7])$'
+ minItems: 1
+ maxItems: 60
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, pwm ]
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ input-enable: true
+
+ output-high: true
+
+ output-low: true
+
+ drive-push-pull: true
+
+ drive-open-drain: true
+
+ drive-open-source: true
+
+ required:
+ - pins
+ - function
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl@20 {
+ compatible = "cypress,cy8c9520";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ vdd-supply = <&p3v3>;
+ gpio-reserved-ranges = <1 2>, <6 1>, <10 1>, <15 1>;
+
+ pinctrl-0 = <&U62160_pins>, <&U62160_ipins>;
+ pinctrl-names = "default";
+
+ U62160_pins: cfg-pins {
+ pins = "gp03", "gp16", "gp20", "gp50", "gp51";
+ function = "gpio";
+ input-enable;
+ bias-pull-up;
+ };
+
+ U62160_ipins: icfg-pins {
+ pins = "gp04", "gp17", "gp21", "gp52", "gp53";
+ function = "gpio";
+ input-enable;
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml
new file mode 100644
index 000000000000..d46e7ee6372d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/eswin,eic7700-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Eswin Eic7700 Pinctrl
+
+maintainers:
+ - Yulin Lu <luyulin@eswincomputing.com>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+description: |
+ eic7700 pin configuration nodes act as a container for an arbitrary number of
+ subnodes. Each of these subnodes represents some desired configuration for one or
+ more pins. This configuration can include the mux function to select on those pin(s),
+ and various pin configuration parameters, such as input-enable, pull-up, etc.
+
+properties:
+ compatible:
+ const: eswin,eic7700-pinctrl
+
+ reg:
+ maxItems: 1
+
+ vrgmii-supply:
+ description:
+ Regulator supply for the RGMII interface IO power domain.
+ This property should reference a regulator that provides either 1.8V or 3.3V,
+ depending on the board-level voltage configuration required by the RGMII interface.
+
+patternProperties:
+ '-grp$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '-pins$':
+ type: object
+
+ properties:
+ pins:
+ description:
+ For eic7700, specifies the name(s) of one or more pins to be configured by
+ this node.
+ items:
+ enum: [ chip_mode, mode_set0, mode_set1, mode_set2, mode_set3, xin,
+ rst_out_n, key_reset_n, gpio0, por_sel, jtag0_tck, jtag0_tms,
+ jtag0_tdi, jtag0_tdo, gpio5, spi2_cs0_n, jtag1_tck, jtag1_tms,
+ jtag1_tdi, jtag1_tdo, gpio11, spi2_cs1_n, pcie_clkreq_n,
+ pcie_wake_n, pcie_perst_n, hdmi_scl, hdmi_sda, hdmi_cec,
+ jtag2_trst, rgmii0_clk_125, rgmii0_txen, rgmii0_txclk,
+ rgmii0_txd0, rgmii0_txd1, rgmii0_txd2, rgmii0_txd3, i2s0_bclk,
+ i2s0_wclk, i2s0_sdi, i2s0_sdo, i2s_mclk, rgmii0_rxclk,
+ rgmii0_rxdv, rgmii0_rxd0, rgmii0_rxd1, rgmii0_rxd2, rgmii0_rxd3,
+ i2s2_bclk, i2s2_wclk, i2s2_sdi, i2s2_sdo, gpio27, gpio28, gpio29,
+ rgmii0_mdc, rgmii0_mdio, rgmii0_intb, rgmii1_clk_125, rgmii1_txen,
+ rgmii1_txclk, rgmii1_txd0, rgmii1_txd1, rgmii1_txd2, rgmii1_txd3,
+ i2s1_bclk, i2s1_wclk, i2s1_sdi, i2s1_sdo, gpio34, rgmii1_rxclk,
+ rgmii1_rxdv, rgmii1_rxd0, rgmii1_rxd1, rgmii1_rxd2, rgmii1_rxd3,
+ spi1_cs0_n, spi1_clk, spi1_d0, spi1_d1, spi1_d2, spi1_d3, spi1_cs1_n,
+ rgmii1_mdc, rgmii1_mdio, rgmii1_intb, usb0_pwren, usb1_pwren,
+ i2c0_scl, i2c0_sda, i2c1_scl, i2c1_sda, i2c2_scl, i2c2_sda,
+ i2c3_scl, i2c3_sda, i2c4_scl, i2c4_sda, i2c5_scl, i2c5_sda,
+ uart0_tx, uart0_rx, uart1_tx, uart1_rx, uart1_cts, uart1_rts,
+ uart2_tx, uart2_rx, jtag2_tck, jtag2_tms, jtag2_tdi, jtag2_tdo,
+ fan_pwm, fan_tach, mipi_csi0_xvs, mipi_csi0_xhs, mipi_csi0_mclk,
+ mipi_csi1_xvs, mipi_csi1_xhs, mipi_csi1_mclk, mipi_csi2_xvs,
+ mipi_csi2_xhs, mipi_csi2_mclk, mipi_csi3_xvs, mipi_csi3_xhs,
+ mipi_csi3_mclk, mipi_csi4_xvs, mipi_csi4_xhs, mipi_csi4_mclk,
+ mipi_csi5_xvs, mipi_csi5_xhs, mipi_csi5_mclk, spi3_cs_n, spi3_clk,
+ spi3_di, spi3_do, gpio92, gpio93, s_mode, gpio95, spi0_cs_n,
+ spi0_clk, spi0_d0, spi0_d1, spi0_d2, spi0_d3, i2c10_scl,
+ i2c10_sda, i2c11_scl, i2c11_sda, gpio106, boot_sel0, boot_sel1,
+ boot_sel2, boot_sel3, gpio111, lpddr_ref_clk ]
+
+ function:
+ description:
+ Specify the alternative function to be configured for the
+ given pins.
+ enum: [ disabled, boot_sel, chip_mode, emmc, fan_tach,
+ gpio, hdmi, i2c, i2s, jtag, ddr_ref_clk_sel,
+ lpddr_ref_clk, mipi_csi, osc, pcie, pwm,
+ rgmii, reset, sata, sdio, spi, s_mode, uart, usb ]
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ bias-disable: true
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ input-enable: true
+
+ input-disable: true
+
+ drive-strength-microamp: true
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ - if:
+ properties:
+ pins:
+ anyOf:
+ - pattern: '^rgmii'
+ - const: lpddr_ref_clk
+ then:
+ properties:
+ drive-strength-microamp:
+ enum: [3000, 6000, 9000, 12000, 15000, 18000, 21000, 24000]
+ else:
+ properties:
+ drive-strength-microamp:
+ enum: [6000, 9000, 12000, 15000, 18000, 21000, 24000, 27000]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pinctrl@51600080 {
+ compatible = "eswin,eic7700-pinctrl";
+ reg = <0x51600080 0x1fff80>;
+ vrgmii-supply = <&vcc_1v8>;
+
+ dev-active-grp {
+ /* group node defining 1 standard pin */
+ gpio10-pins {
+ pins = "jtag1_tdo";
+ function = "gpio";
+ input-enable;
+ bias-pull-up;
+ };
+
+ /* group node defining 2 I2C pins */
+ i2c6-pins {
+ pins = "uart1_cts", "uart1_rts";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
deleted file mode 100644
index c083dfd25db9..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-* Freescale IMX35 IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx35-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx35 datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_DRIVE_VOLAGAGE_18 (1 << 13)
-PAD_CTL_DRIVE_VOLAGAGE_33 (0 << 13)
-PAD_CTL_HYS (1 << 8)
-PAD_CTL_PKE (1 << 7)
-PAD_CTL_PUE (1 << 6)
-PAD_CTL_PUS_100K_DOWN (0 << 4)
-PAD_CTL_PUS_47K_UP (1 << 4)
-PAD_CTL_PUS_100K_UP (2 << 4)
-PAD_CTL_PUS_22K_UP (3 << 4)
-PAD_CTL_ODE_CMOS (0 << 3)
-PAD_CTL_ODE_OPENDRAIN (1 << 3)
-PAD_CTL_DSE_NOMINAL (0 << 1)
-PAD_CTL_DSE_HIGH (1 << 1)
-PAD_CTL_DSE_MAX (2 << 1)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx35-pinfunc.h in device tree source folder for all available
-imx35 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml
new file mode 100644
index 000000000000..265c43ab76f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/fsl,imx35-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IMX35/IMX5x/IMX6 IOMUX Controller
+
+maintainers:
+ - Dong Aisheng <aisheng.dong@nxp.com>
+
+description:
+ Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
+ for common binding part and usage.
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx35-iomuxc
+ - fsl,imx51-iomuxc
+ - fsl,imx53-iomuxc
+ - fsl,imx6dl-iomuxc
+ - fsl,imx6q-iomuxc
+ - fsl,imx6sl-iomuxc
+ - fsl,imx6sll-iomuxc
+ - fsl,imx6sx-iomuxc
+ - fsl,imx6ul-iomuxc
+ - fsl,imx6ull-iomuxc-snvs
+ - items:
+ - const: fsl,imx50-iomuxc
+ - const: fsl,imx53-iomuxc
+
+ reg:
+ maxItems: 1
+
+# Client device subnode's properties
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ each entry consists of 6 integers and represents the mux and config
+ setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+ mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+ be found in <arch/arm/boot/dts/nxp/imx/imx*-pinfunc.h>. The last integer
+ CONFIG is the pad setting value like pull-up on this pin. Please
+ refer to matching i.MX Reference Manual for detailed CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_reg" indicates the offset of mux register.
+ - description: |
+ "conf_reg" indicates the offset of pad configuration register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_val" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ "pad_setting" indicates the pad configuration value to be applied.
+ Common i.MX35
+ PAD_CTL_DRIVE_VOLAGAGE_18 (1 << 13)
+ PAD_CTL_DRIVE_VOLAGAGE_33 (0 << 13)
+ PAD_CTL_HYS (1 << 8)
+ PAD_CTL_PKE (1 << 7)
+ PAD_CTL_PUE (1 << 6)
+ PAD_CTL_PUS_100K_DOWN (0 << 4)
+ PAD_CTL_PUS_47K_UP (1 << 4)
+ PAD_CTL_PUS_100K_UP (2 << 4)
+ PAD_CTL_PUS_22K_UP (3 << 4)
+ PAD_CTL_ODE_CMOS (0 << 3)
+ PAD_CTL_ODE_OPENDRAIN (1 << 3)
+ PAD_CTL_DSE_NOMINAL (0 << 1)
+ PAD_CTL_DSE_HIGH (1 << 1)
+ PAD_CTL_DSE_MAX (2 << 1)
+ PAD_CTL_SRE_FAST (1 << 0)
+ PAD_CTL_SRE_SLOW (0 << 0)
+ Common i.MX50/i.MX51/i.MX53 bits
+ PAD_CTL_HVE (1 << 13)
+ PAD_CTL_HYS (1 << 8)
+ PAD_CTL_PKE (1 << 7)
+ PAD_CTL_PUE (1 << 6)
+ PAD_CTL_PUS_100K_DOWN (0 << 4)
+ PAD_CTL_PUS_47K_UP (1 << 4)
+ PAD_CTL_PUS_100K_UP (2 << 4)
+ PAD_CTL_PUS_22K_UP (3 << 4)
+ PAD_CTL_ODE (1 << 3)
+ PAD_CTL_DSE_LOW (0 << 1)
+ PAD_CTL_DSE_MED (1 << 1)
+ PAD_CTL_DSE_HIGH (2 << 1)
+ PAD_CTL_DSE_MAX (3 << 1)
+ PAD_CTL_SRE_FAST (1 << 0)
+ PAD_CTL_SRE_SLOW (0 << 0)
+ Common i.MX6 bits
+ PAD_CTL_HYS (1 << 16)
+ PAD_CTL_PUS_100K_DOWN (0 << 14)
+ PAD_CTL_PUS_47K_UP (1 << 14)
+ PAD_CTL_PUS_100K_UP (2 << 14)
+ PAD_CTL_PUS_22K_UP (3 << 14)
+ PAD_CTL_PUE (1 << 13)
+ PAD_CTL_PKE (1 << 12)
+ PAD_CTL_ODE (1 << 11)
+ PAD_CTL_SPEED_LOW (0 << 6)
+ PAD_CTL_SPEED_MED (1 << 6)
+ PAD_CTL_SPEED_HIGH (3 << 6)
+ PAD_CTL_DSE_DISABLE (0 << 3)
+ PAD_CTL_SRE_FAST (1 << 0)
+ PAD_CTL_SRE_SLOW (0 << 0)
+ i.MX6SL/MX6SLL specific bits
+ PAD_CTL_LVE (1 << 22) (MX6SL/SLL only)
+ i.MX6SLL/i.MX6SX/i.MX6UL/i.MX6ULL specific bits
+ PAD_CTL_DSE_260ohm (1 << 3)
+ PAD_CTL_DSE_130ohm (2 << 3)
+ PAD_CTL_DSE_87ohm (3 << 3)
+ PAD_CTL_DSE_65ohm (4 << 3)
+ PAD_CTL_DSE_52ohm (5 << 3)
+ PAD_CTL_DSE_43ohm (6 << 3)
+ PAD_CTL_DSE_37ohm (7 << 3)
+ i.MX6DL/i.MX6Q/i.MX6SL specific bits
+ PAD_CTL_DSE_240ohm (1 << 3)
+ PAD_CTL_DSE_120ohm (2 << 3)
+ PAD_CTL_DSE_80ohm (3 << 3)
+ PAD_CTL_DSE_60ohm (4 << 3)
+ PAD_CTL_DSE_48ohm (5 << 3)
+ PAD_CTL_DSE_40ohm (6 << 3)
+ PAD_CTL_DSE_34ohm (7 << 3)
+
+ required:
+ - fsl,pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ iomuxc: pinctrl@20e0000 {
+ compatible = "fsl,imx6ul-iomuxc";
+ reg = <0x020e0000 0x4000>;
+
+ mux_uart: uartgrp {
+ fsl,pins = <
+ 0x0084 0x0310 0x0000 0 0 0x1b0b1
+ 0x0088 0x0314 0x0624 0 3 0x1b0b1
+ >;
+ };
+ };
+ - |
+ iomuxc_snvs: pinctrl@2290000 {
+ compatible = "fsl,imx6ull-iomuxc-snvs";
+ reg = <0x02290000 0x4000>;
+
+ pinctrl_snvs_usbc_det: snvsusbcdetgrp {
+ fsl,pins = <
+ 0x0010 0x0054 0x0000 0x5 0x0 0x130b0
+ >;
+ };
+ };
+ - |
+ iomuxc_mx6q: pinctrl@20e0000 {
+ compatible = "fsl,imx6q-iomuxc";
+ reg = <0x20e0000 0x4000>;
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins =
+ <0x288 0x658 0x000 0x3 0x0 0x140>,
+ <0x28c 0x65c 0x938 0x3 0x3 0x140>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx50-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx50-pinctrl.txt
deleted file mode 100644
index 6da01d619d33..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx50-pinctrl.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* Freescale IMX50 IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx50-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx50 datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_HVE (1 << 13)
-PAD_CTL_HYS (1 << 8)
-PAD_CTL_PKE (1 << 7)
-PAD_CTL_PUE (1 << 6)
-PAD_CTL_PUS_100K_DOWN (0 << 4)
-PAD_CTL_PUS_47K_UP (1 << 4)
-PAD_CTL_PUS_100K_UP (2 << 4)
-PAD_CTL_PUS_22K_UP (3 << 4)
-PAD_CTL_ODE (1 << 3)
-PAD_CTL_DSE_LOW (0 << 1)
-PAD_CTL_DSE_MED (1 << 1)
-PAD_CTL_DSE_HIGH (2 << 1)
-PAD_CTL_DSE_MAX (3 << 1)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx50-pinfunc.h in device tree source folder for all available
-imx50 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
deleted file mode 100644
index 4d1408fcc99c..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* Freescale IMX51 IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx51-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx51 datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_HVE (1 << 13)
-PAD_CTL_HYS (1 << 8)
-PAD_CTL_PKE (1 << 7)
-PAD_CTL_PUE (1 << 6)
-PAD_CTL_PUS_100K_DOWN (0 << 4)
-PAD_CTL_PUS_47K_UP (1 << 4)
-PAD_CTL_PUS_100K_UP (2 << 4)
-PAD_CTL_PUS_22K_UP (3 << 4)
-PAD_CTL_ODE (1 << 3)
-PAD_CTL_DSE_LOW (0 << 1)
-PAD_CTL_DSE_MED (1 << 1)
-PAD_CTL_DSE_HIGH (2 << 1)
-PAD_CTL_DSE_MAX (3 << 1)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx51-pinfunc.h in device tree source folder for all available
-imx51 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
deleted file mode 100644
index 25dcb77cfaf7..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* Freescale IMX53 IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx53-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx53 datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_HVE (1 << 13)
-PAD_CTL_HYS (1 << 8)
-PAD_CTL_PKE (1 << 7)
-PAD_CTL_PUE (1 << 6)
-PAD_CTL_PUS_100K_DOWN (0 << 4)
-PAD_CTL_PUS_47K_UP (1 << 4)
-PAD_CTL_PUS_100K_UP (2 << 4)
-PAD_CTL_PUS_22K_UP (3 << 4)
-PAD_CTL_ODE (1 << 3)
-PAD_CTL_DSE_LOW (0 << 1)
-PAD_CTL_DSE_MED (1 << 1)
-PAD_CTL_DSE_HIGH (2 << 1)
-PAD_CTL_DSE_MAX (3 << 1)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx53-pinfunc.h in device tree source folder for all available
-imx53 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
deleted file mode 100644
index 0ac5bee87505..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-* Freescale IMX6 DualLite/Solo IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx6dl-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx6dl datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_HYS (1 << 16)
-PAD_CTL_PUS_100K_DOWN (0 << 14)
-PAD_CTL_PUS_47K_UP (1 << 14)
-PAD_CTL_PUS_100K_UP (2 << 14)
-PAD_CTL_PUS_22K_UP (3 << 14)
-PAD_CTL_PUE (1 << 13)
-PAD_CTL_PKE (1 << 12)
-PAD_CTL_ODE (1 << 11)
-PAD_CTL_SPEED_LOW (1 << 6)
-PAD_CTL_SPEED_MED (2 << 6)
-PAD_CTL_SPEED_HIGH (3 << 6)
-PAD_CTL_DSE_DISABLE (0 << 3)
-PAD_CTL_DSE_240ohm (1 << 3)
-PAD_CTL_DSE_120ohm (2 << 3)
-PAD_CTL_DSE_80ohm (3 << 3)
-PAD_CTL_DSE_60ohm (4 << 3)
-PAD_CTL_DSE_48ohm (5 << 3)
-PAD_CTL_DSE_40ohm (6 << 3)
-PAD_CTL_DSE_34ohm (7 << 3)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx6dl-pinfunc.h in device tree source folder for all available
-imx6dl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
deleted file mode 100644
index 546610cf2ae7..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-* Freescale IMX6Q IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx6q-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx6q datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_HYS (1 << 16)
-PAD_CTL_PUS_100K_DOWN (0 << 14)
-PAD_CTL_PUS_47K_UP (1 << 14)
-PAD_CTL_PUS_100K_UP (2 << 14)
-PAD_CTL_PUS_22K_UP (3 << 14)
-PAD_CTL_PUE (1 << 13)
-PAD_CTL_PKE (1 << 12)
-PAD_CTL_ODE (1 << 11)
-PAD_CTL_SPEED_LOW (1 << 6)
-PAD_CTL_SPEED_MED (2 << 6)
-PAD_CTL_SPEED_HIGH (3 << 6)
-PAD_CTL_DSE_DISABLE (0 << 3)
-PAD_CTL_DSE_240ohm (1 << 3)
-PAD_CTL_DSE_120ohm (2 << 3)
-PAD_CTL_DSE_80ohm (3 << 3)
-PAD_CTL_DSE_60ohm (4 << 3)
-PAD_CTL_DSE_48ohm (5 << 3)
-PAD_CTL_DSE_40ohm (6 << 3)
-PAD_CTL_DSE_34ohm (7 << 3)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx6q-pinfunc.h in device tree source folder for all available
-imx6q PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
deleted file mode 100644
index e5f6d1f065a4..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-* Freescale IMX6 SoloLite IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx6sl-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up for this pin. Please refer to imx6sl datasheet for the valid pad
- config settings.
-
-CONFIG bits definition:
-PAD_CTL_LVE (1 << 22)
-PAD_CTL_HYS (1 << 16)
-PAD_CTL_PUS_100K_DOWN (0 << 14)
-PAD_CTL_PUS_47K_UP (1 << 14)
-PAD_CTL_PUS_100K_UP (2 << 14)
-PAD_CTL_PUS_22K_UP (3 << 14)
-PAD_CTL_PUE (1 << 13)
-PAD_CTL_PKE (1 << 12)
-PAD_CTL_ODE (1 << 11)
-PAD_CTL_SPEED_LOW (1 << 6)
-PAD_CTL_SPEED_MED (2 << 6)
-PAD_CTL_SPEED_HIGH (3 << 6)
-PAD_CTL_DSE_DISABLE (0 << 3)
-PAD_CTL_DSE_240ohm (1 << 3)
-PAD_CTL_DSE_120ohm (2 << 3)
-PAD_CTL_DSE_80ohm (3 << 3)
-PAD_CTL_DSE_60ohm (4 << 3)
-PAD_CTL_DSE_48ohm (5 << 3)
-PAD_CTL_DSE_40ohm (6 << 3)
-PAD_CTL_DSE_34ohm (7 << 3)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx6sl-pinfunc.h in device tree source folder for all available
-imx6sl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
deleted file mode 100644
index 175e8939a301..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-* Freescale i.MX6 SLL IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx6sll-iomuxc"
-- fsl,pins: each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
- input_val> are specified using a PIN_FUNC_ID macro, which can be found in
- imx6sll-pinfunc.h under device tree source folder. The last integer CONFIG is
- the pad setting value like pull-up on this pin. Please refer to i.MX6SLL
- Reference Manual for detailed CONFIG settings.
-
-CONFIG bits definition:
-PAD_CTL_LVE (1 << 22)
-PAD_CTL_HYS (1 << 16)
-PAD_CTL_PUS_100K_DOWN (0 << 14)
-PAD_CTL_PUS_47K_UP (1 << 14)
-PAD_CTL_PUS_100K_UP (2 << 14)
-PAD_CTL_PUS_22K_UP (3 << 14)
-PAD_CTL_PUE (1 << 13)
-PAD_CTL_PKE (1 << 12)
-PAD_CTL_ODE (1 << 11)
-PAD_CTL_SPEED_LOW (0 << 6)
-PAD_CTL_SPEED_MED (1 << 6)
-PAD_CTL_SPEED_HIGH (3 << 6)
-PAD_CTL_DSE_DISABLE (0 << 3)
-PAD_CTL_DSE_260ohm (1 << 3)
-PAD_CTL_DSE_130ohm (2 << 3)
-PAD_CTL_DSE_87ohm (3 << 3)
-PAD_CTL_DSE_65ohm (4 << 3)
-PAD_CTL_DSE_52ohm (5 << 3)
-PAD_CTL_DSE_43ohm (6 << 3)
-PAD_CTL_DSE_37ohm (7 << 3)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
-
-Refer to imx6sll-pinfunc.h in device tree source folder for all available
-imx6sll PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt
deleted file mode 100644
index b1b595220f1b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Freescale i.MX6 SoloX IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx6sx-iomuxc"
-- fsl,pins: each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
- input_val> are specified using a PIN_FUNC_ID macro, which can be found in
- imx6sx-pinfunc.h under device tree source folder. The last integer CONFIG is
- the pad setting value like pull-up on this pin. Please refer to i.MX6 SoloX
- Reference Manual for detailed CONFIG settings.
-
-CONFIG bits definition:
-PAD_CTL_HYS (1 << 16)
-PAD_CTL_PUS_100K_DOWN (0 << 14)
-PAD_CTL_PUS_47K_UP (1 << 14)
-PAD_CTL_PUS_100K_UP (2 << 14)
-PAD_CTL_PUS_22K_UP (3 << 14)
-PAD_CTL_PUE (1 << 13)
-PAD_CTL_PKE (1 << 12)
-PAD_CTL_ODE (1 << 11)
-PAD_CTL_SPEED_LOW (0 << 6)
-PAD_CTL_SPEED_MED (1 << 6)
-PAD_CTL_SPEED_HIGH (3 << 6)
-PAD_CTL_DSE_DISABLE (0 << 3)
-PAD_CTL_DSE_260ohm (1 << 3)
-PAD_CTL_DSE_130ohm (2 << 3)
-PAD_CTL_DSE_87ohm (3 << 3)
-PAD_CTL_DSE_65ohm (4 << 3)
-PAD_CTL_DSE_52ohm (5 << 3)
-PAD_CTL_DSE_43ohm (6 << 3)
-PAD_CTL_DSE_37ohm (7 << 3)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
deleted file mode 100644
index 7ca4f6118d9a..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-* Freescale i.MX6 UltraLite IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,imx6ul-iomuxc" for main IOMUX controller or
- "fsl,imx6ull-iomuxc-snvs" for i.MX 6ULL's SNVS IOMUX controller.
-- fsl,pins: each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
- input_val> are specified using a PIN_FUNC_ID macro, which can be found in
- imx6ul-pinfunc.h under device tree source folder. The last integer CONFIG is
- the pad setting value like pull-up on this pin. Please refer to i.MX6 UltraLite
- Reference Manual for detailed CONFIG settings.
-
-CONFIG bits definition:
-PAD_CTL_HYS (1 << 16)
-PAD_CTL_PUS_100K_DOWN (0 << 14)
-PAD_CTL_PUS_47K_UP (1 << 14)
-PAD_CTL_PUS_100K_UP (2 << 14)
-PAD_CTL_PUS_22K_UP (3 << 14)
-PAD_CTL_PUE (1 << 13)
-PAD_CTL_PKE (1 << 12)
-PAD_CTL_ODE (1 << 11)
-PAD_CTL_SPEED_LOW (0 << 6)
-PAD_CTL_SPEED_MED (1 << 6)
-PAD_CTL_SPEED_HIGH (3 << 6)
-PAD_CTL_DSE_DISABLE (0 << 3)
-PAD_CTL_DSE_260ohm (1 << 3)
-PAD_CTL_DSE_130ohm (2 << 3)
-PAD_CTL_DSE_87ohm (3 << 3)
-PAD_CTL_DSE_65ohm (4 << 3)
-PAD_CTL_DSE_52ohm (5 << 3)
-PAD_CTL_DSE_43ohm (6 << 3)
-PAD_CTL_DSE_37ohm (7 << 3)
-PAD_CTL_SRE_FAST (1 << 0)
-PAD_CTL_SRE_SLOW (0 << 0)
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml
index 621038662188..7bd723ab1281 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml
@@ -68,7 +68,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-iomuxc1.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-iomuxc1.yaml
new file mode 100644
index 000000000000..957918b73a93
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-iomuxc1.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/fsl,imx7ulp-iomuxc1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX7ULP IOMUX Controller
+
+description: |
+ i.MX 7ULP has three IOMUXC instances: IOMUXC0 for M4 ports, IOMUXC1 for A7
+ ports and IOMUXC DDR for DDR interface.
+
+ Note: This binding doc is only for the IOMUXC1 support in A7 Domain and it
+ only supports generic pin config.
+
+ Please refer to fsl,imx-pinctrl.txt in this directory for common binding
+ part and usage.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx7ulp-iomuxc1
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ Each entry consists of 5 integers which represents the mux
+ and config setting for one pin. The first 4 integers
+ <mux_conf_reg input_reg mux_mode input_val> are specified
+ using a PIN_FUNC_ID macro, which can be found in
+ imx7ulp-pinfunc.h in the device tree source folder.
+ The last integer CONFIG is the pad setting value like
+ pull-up on this pin.
+
+ Please refer to i.MX7ULP Reference Manual for detailed
+ CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_conf_reg" indicates the offset of mux register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_mode" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ CONFIG bits definition:
+ PAD_CTL_OBE (1 << 17)
+ PAD_CTL_IBE (1 << 16)
+ PAD_CTL_LK (1 << 16)
+ PAD_CTL_DSE_HI (1 << 6)
+ PAD_CTL_DSE_STD (0 << 6)
+ PAD_CTL_ODE (1 << 5)
+ PAD_CTL_PUSH_PULL (0 << 5)
+ PAD_CTL_SRE_SLOW (1 << 2)
+ PAD_CTL_SRE_STD (0 << 2)
+ PAD_CTL_PE (1 << 0)
+
+ required:
+ - fsl,pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pinctrl@40ac0000 {
+ compatible = "fsl,imx7ulp-iomuxc1";
+ reg = <0x40ac0000 0x1000>;
+
+ lpuart4grp {
+ fsl,pins = <
+ 0x000c 0x0248 0x4 0x1 0x1
+ 0x0008 0x024c 0x4 0x1 0x1
+ >;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt
deleted file mode 100644
index bfa3703a7446..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Freescale i.MX7ULP IOMUX Controller
-
-i.MX 7ULP has three IOMUXC instances: IOMUXC0 for M4 ports, IOMUXC1 for A7
-ports and IOMUXC DDR for DDR interface.
-
-Note:
-This binding doc is only for the IOMUXC1 support in A7 Domain and it only
-supports generic pin config.
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding
-part and usage.
-
-Required properties:
-- compatible: "fsl,imx7ulp-iomuxc1".
-- fsl,pins: Each entry consists of 5 integers which represents the mux
- and config setting for one pin. The first 4 integers
- <mux_conf_reg input_reg mux_mode input_val> are specified
- using a PIN_FUNC_ID macro, which can be found in
- imx7ulp-pinfunc.h in the device tree source folder.
- The last integer CONFIG is the pad setting value like
- pull-up on this pin.
-
- Please refer to i.MX7ULP Reference Manual for detailed
- CONFIG settings.
-
-CONFIG bits definition:
-PAD_CTL_OBE (1 << 17)
-PAD_CTL_IBE (1 << 16)
-PAD_CTL_LK (1 << 16)
-PAD_CTL_DSE_HI (1 << 6)
-PAD_CTL_DSE_STD (0 << 6)
-PAD_CTL_ODE (1 << 5)
-PAD_CTL_PUSH_PULL (0 << 5)
-PAD_CTL_SRE_SLOW (1 << 2)
-PAD_CTL_SRE_STD (0 << 2)
-PAD_CTL_PE (1 << 0)
-
-Examples:
-#include "imx7ulp-pinfunc.h"
-
-/* Pin Controller Node */
-iomuxc1: pinctrl@40ac0000 {
- compatible = "fsl,imx7ulp-iomuxc1";
- reg = <0x40ac0000 0x1000>;
-
- /* Pin Configuration Node */
- pinctrl_lpuart4: lpuart4grp {
- fsl,pins = <
- IMX7ULP_PAD_PTC3__LPUART4_RX 0x1
- IMX7ULP_PAD_PTC2__LPUART4_TX 0x1
- >;
- };
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml
new file mode 100644
index 000000000000..6068be11dfe2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/fsl,imx8m-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IMX8M IOMUX Controller
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description:
+ Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
+ for common binding part and usage.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8mm-iomuxc
+ - fsl,imx8mn-iomuxc
+ - fsl,imx8mp-iomuxc
+ - fsl,imx8mq-iomuxc
+
+ reg:
+ maxItems: 1
+
+# Client device subnode's properties
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ each entry consists of 6 integers and represents the mux and config
+ setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+ mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+ be found in <arch/arm64/boot/dts/freescale/imx8m[m,n,p,q]-pinfunc.h>.
+ The last integer CONFIG is the pad setting value like pull-up on this
+ pin. Please refer to i.MX8M Mini/Nano/Plus/Quad Reference Manual for
+ detailed CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_reg" indicates the offset of mux register.
+ - description: |
+ "conf_reg" indicates the offset of pad configuration register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_val" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ "pad_setting" indicates the pad configuration value to be
+ applied.
+
+ required:
+ - fsl,pins
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ # Pinmux controller node
+ - |
+ iomuxc: pinctrl@30330000 {
+ compatible = "fsl,imx8mm-iomuxc";
+ reg = <0x30330000 0x10000>;
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins =
+ <0x23C 0x4A4 0x4FC 0x0 0x0 0x140>,
+ <0x240 0x4A8 0x000 0x0 0x0 0x140>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml
deleted file mode 100644
index 6717f163390b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mm-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MM IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mm-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Mini Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mm-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart2: uart2grp {
- fsl,pins =
- <0x23C 0x4A4 0x4FC 0x0 0x0 0x140>,
- <0x240 0x4A8 0x000 0x0 0x0 0x140>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml
deleted file mode 100644
index b1cdbb56d4e4..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mn-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MN IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mn-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mn-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Nano Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mn-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart2: uart2grp {
- fsl,pins =
- <0x23C 0x4A4 0x4FC 0x0 0x0 0x140>,
- <0x240 0x4A8 0x000 0x0 0x0 0x140>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml
deleted file mode 100644
index 4eed3a4e153a..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mp-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MP IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mp-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Plus Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mp-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart2: uart2grp {
- fsl,pins =
- <0x228 0x488 0x5F0 0x0 0x6 0x49>,
- <0x228 0x488 0x000 0x0 0x0 0x49>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml
deleted file mode 100644
index d4a8ea5551a5..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml
+++ /dev/null
@@ -1,84 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx8mq-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX8MQ IOMUX Controller
-
-maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-properties:
- compatible:
- const: fsl,imx8mq-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mq-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Quad Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@30330000 {
- compatible = "fsl,imx8mq-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart1: uart1grp {
- fsl,pins =
- <0x234 0x49C 0x4F4 0x0 0x0 0x49>,
- <0x238 0x4A0 0x4F4 0x0 0x0 0x49>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml
index 693398d88223..7dcf681271d3 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml
@@ -57,7 +57,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx9-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx9-pinctrl.yaml
new file mode 100644
index 000000000000..96e7b6995273
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx9-pinctrl.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/fsl,imx9-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IMX9 IOMUX Controller
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description:
+ Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
+ for common binding part and usage.
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx91-iomuxc
+ - fsl,imx93-iomuxc
+
+ reg:
+ maxItems: 1
+
+# Client device subnode's properties
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ each entry consists of 6 integers and represents the mux and config
+ setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
+ mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
+ be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last
+ integer CONFIG is the pad setting value like pull-up on this pin. Please
+ refer to i.MX8M Plus Reference Manual for detailed CONFIG settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: |
+ "mux_reg" indicates the offset of mux register.
+ - description: |
+ "conf_reg" indicates the offset of pad configuration register.
+ - description: |
+ "input_reg" indicates the offset of select input register.
+ - description: |
+ "mux_val" indicates the mux value to be applied.
+ - description: |
+ "input_val" indicates the select input value to be applied.
+ - description: |
+ "pad_setting" indicates the pad configuration value to be applied.
+
+ required:
+ - fsl,pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ # Pinmux controller node
+ - |
+ iomuxc: pinctrl@443c0000 {
+ compatible = "fsl,imx93-iomuxc";
+ reg = <0x30330000 0x10000>;
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins =
+ <0x48 0x1f8 0x41c 0x1 0x0 0x49>,
+ <0x4c 0x1fc 0x418 0x1 0x0 0x49>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml
deleted file mode 100644
index 66baa6082a4f..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml
+++ /dev/null
@@ -1,85 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/fsl,imx93-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale IMX93 IOMUX Controller
-
-maintainers:
- - Peng Fan <peng.fan@nxp.com>
-
-description:
- Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory
- for common binding part and usage.
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-properties:
- compatible:
- const: fsl,imx93-iomuxc
-
- reg:
- maxItems: 1
-
-# Client device subnode's properties
-patternProperties:
- 'grp$':
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
-
- properties:
- fsl,pins:
- description:
- each entry consists of 6 integers and represents the mux and config
- setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
- mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last
- integer CONFIG is the pad setting value like pull-up on this pin. Please
- refer to i.MX8M Plus Reference Manual for detailed CONFIG settings.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: |
- "mux_reg" indicates the offset of mux register.
- - description: |
- "conf_reg" indicates the offset of pad configuration register.
- - description: |
- "input_reg" indicates the offset of select input register.
- - description: |
- "mux_val" indicates the mux value to be applied.
- - description: |
- "input_val" indicates the select input value to be applied.
- - description: |
- "pad_setting" indicates the pad configuration value to be applied.
-
-
- required:
- - fsl,pins
-
- additionalProperties: false
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- iomuxc: pinctrl@443c0000 {
- compatible = "fsl,imx93-iomuxc";
- reg = <0x30330000 0x10000>;
-
- pinctrl_uart3: uart3grp {
- fsl,pins =
- <0x48 0x1f8 0x41c 0x1 0x0 0x49>,
- <0x4c 0x1fc 0x418 0x1 0x0 0x49>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml
index 1278f7293560..db5fe66ad873 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml
@@ -35,7 +35,7 @@ patternProperties:
each entry consists of 6 integers and represents the mux and config
setting for one pin. The first 5 integers <mux_reg conf_reg input_reg
mux_val input_val> are specified using a PIN_FUNC_ID macro, which can
- be found in <include/dt-bindings/pinctrl/pins-imxrt1050.h>. The last
+ be found in <arch/arm/boot/dts/imxrt1050-pinfunc.h>. The last
integer CONFIG is the pad setting value like pull-up on this pin. Please
refer to i.MXRT1050 Reference Manual for detailed CONFIG settings.
$ref: /schemas/types.yaml#/definitions/uint32-matrix
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
deleted file mode 100644
index 1e70a8aff260..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-* Freescale MXS Pin Controller
-
-The pins controlled by mxs pin controller are organized in banks, each bank
-has 32 pins. Each pin has 4 multiplexing functions, and generally, the 4th
-function is GPIO. The configuration on the pins includes drive strength,
-voltage and pull-up.
-
-Required properties:
-- compatible: "fsl,imx23-pinctrl" or "fsl,imx28-pinctrl"
-- reg: Should contain the register physical address and length for the
- pin controller.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices.
-
-The node of mxs pin controller acts as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for
-a group of pins, and only affects those parameters that are explicitly listed.
-In other words, a subnode that describes a drive strength parameter implies no
-information about pull-up. For this reason, even seemingly boolean values are
-actually tristates in this binding: unspecified, off, or on. Unspecified is
-represented as an absent property, and off/on are represented as integer
-values 0 and 1.
-
-Those subnodes under mxs pin controller node will fall into two categories.
-One is to set up a group of pins for a function, both mux selection and pin
-configurations, and it's called group node in the binding document. The other
-one is to adjust the pin configuration for some particular pins that need a
-different configuration than what is defined in group node. The binding
-document calls this type of node config node.
-
-On mxs, there is no hardware pin group. The pin group in this binding only
-means a group of pins put together for particular peripheral to work in
-particular function, like SSP0 functioning as mmc0-8bit. That said, the
-group node should include all the pins needed for one function rather than
-having these pins defined in several group nodes. It also means each of
-"pinctrl-*" phandle in client device node should only have one group node
-pointed in there, while the phandle can have multiple config node referenced
-there to adjust configurations for some pins in the group.
-
-Required subnode-properties:
-- fsl,pinmux-ids: An integer array. Each integer in the array specify a pin
- with given mux function, with bank, pin and mux packed as below.
-
- [15..12] : bank number
- [11..4] : pin number
- [3..0] : mux selection
-
- This integer with mux selection packed is used as an entity by both group
- and config nodes to identify a pin. The mux selection in the integer takes
- effects only on group node, and will get ignored by driver with config node,
- since config node is only meant to set up pin configurations.
-
- Valid values for these integers are listed below.
-
-- reg: Should be the index of the group nodes for same function. This property
- is required only for group nodes, and should not be present in any config
- nodes.
-
-Optional subnode-properties:
-- fsl,drive-strength: Integer.
- 0: MXS_DRIVE_4mA
- 1: MXS_DRIVE_8mA
- 2: MXS_DRIVE_12mA
- 3: MXS_DRIVE_16mA
-- fsl,voltage: Integer.
- 0: MXS_VOLTAGE_LOW - 1.8 V
- 1: MXS_VOLTAGE_HIGH - 3.3 V
-- fsl,pull-up: Integer.
- 0: MXS_PULL_DISABLE - Disable the internal pull-up
- 1: MXS_PULL_ENABLE - Enable the internal pull-up
-
-Note that when enabling the pull-up, the internal pad keeper gets disabled.
-Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
-will only disable the internal pad keeper.
-
-Examples:
-
-pinctrl@80018000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx28-pinctrl";
- reg = <0x80018000 2000>;
-
- mmc0_8bit_pins_a: mmc0-8bit@0 {
- reg = <0>;
- fsl,pinmux-ids = <
- MX28_PAD_SSP0_DATA0__SSP0_D0
- MX28_PAD_SSP0_DATA1__SSP0_D1
- MX28_PAD_SSP0_DATA2__SSP0_D2
- MX28_PAD_SSP0_DATA3__SSP0_D3
- MX28_PAD_SSP0_DATA4__SSP0_D4
- MX28_PAD_SSP0_DATA5__SSP0_D5
- MX28_PAD_SSP0_DATA6__SSP0_D6
- MX28_PAD_SSP0_DATA7__SSP0_D7
- MX28_PAD_SSP0_CMD__SSP0_CMD
- MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT
- MX28_PAD_SSP0_SCK__SSP0_SCK
- >;
- fsl,drive-strength = <MXS_DRIVE_4mA>;
- fsl,voltage = <MXS_VOLTAGE_HIGH>;
- fsl,pull-up = <MXS_PULL_ENABLE>;
- };
-
- mmc_cd_cfg: mmc-cd-cfg {
- fsl,pinmux-ids = <MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT>;
- fsl,pull-up = <MXS_PULL_DISABLE>;
- };
-
- mmc_sck_cfg: mmc-sck-cfg {
- fsl,pinmux-ids = <MX28_PAD_SSP0_SCK__SSP0_SCK>;
- fsl,drive-strength = <MXS_DRIVE_12mA>;
- fsl,pull-up = <MXS_PULL_DISABLE>;
- };
-};
-
-In this example, group node mmc0-8bit defines a group of pins for mxs SSP0
-to function as a 8-bit mmc device, with 8mA, 3.3V and pull-up configurations
-applied on all these pins. And config nodes mmc-cd-cfg and mmc-sck-cfg are
-adjusting the configuration for pins card-detection and clock from what group
-node mmc0-8bit defines. Only the configuration properties to be adjusted need
-to be listed in the config nodes.
-
-Valid values for i.MX28/i.MX23 pinmux-id are defined in
-arch/arm/boot/dts/imx28-pinfunc.h and arch/arm/boot/dts/imx23-pinfunc.h.
-The definitions for the padconfig properties can be found in
-arch/arm/boot/dts/mxs-pinfunc.h.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml
index 45ea565ce238..fcd729afeee1 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/fsl,scu-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - Pinctrl bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - Pinctrl Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,vf610-iomuxc.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-iomuxc.yaml
new file mode 100644
index 000000000000..3e13587df310
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-iomuxc.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/fsl,vf610-iomuxc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Vybrid VF610 IOMUX Controller
+
+description:
+ Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+ and usage.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,vf610-iomuxc
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ 'grp$':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ fsl,pins:
+ description:
+ two integers array, represents a group of pins mux and config setting.
+ The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a pin
+ working on a specific function, CONFIG is the pad setting value such
+ as pull-up, speed, ode for this pin. Please refer to Vybrid VF610
+ datasheet for the valid pad config settings.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description:
+ PIN_FUN_ID refer to vf610-pinfunc.h in device tree source folder
+ for all available PIN_FUNC_ID for Vybrid VF610.
+ - description: |
+ CONFIG bits definition is
+ PAD_CTL_SPEED_LOW (1 << 12)
+ PAD_CTL_SPEED_MED (2 << 12)
+ PAD_CTL_SPEED_HIGH (3 << 12)
+ PAD_CTL_SRE_FAST (1 << 11)
+ PAD_CTL_SRE_SLOW (0 << 11)
+ PAD_CTL_ODE (1 << 10)
+ PAD_CTL_HYS (1 << 9)
+ PAD_CTL_DSE_DISABLE (0 << 6)
+ PAD_CTL_DSE_150ohm (1 << 6)
+ PAD_CTL_DSE_75ohm (2 << 6)
+ PAD_CTL_DSE_50ohm (3 << 6)
+ PAD_CTL_DSE_37ohm (4 << 6)
+ PAD_CTL_DSE_30ohm (5 << 6)
+ PAD_CTL_DSE_25ohm (6 << 6)
+ PAD_CTL_DSE_20ohm (7 << 6)
+ PAD_CTL_PUS_100K_DOWN (0 << 4)
+ PAD_CTL_PUS_47K_UP (1 << 4)
+ PAD_CTL_PUS_100K_UP (2 << 4)
+ PAD_CTL_PUS_22K_UP (3 << 4)
+ PAD_CTL_PKE (1 << 3)
+ PAD_CTL_PUE (1 << 2)
+ PAD_CTL_OBE_ENABLE (1 << 1)
+ PAD_CTL_IBE_ENABLE (1 << 0)
+ PAD_CTL_OBE_IBE_ENABLE (3 << 0)
+
+ required:
+ - fsl,pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt
deleted file mode 100644
index ddcdeb697c29..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Freescale Vybrid VF610 IOMUX Controller
-
-Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: "fsl,vf610-iomuxc"
-- fsl,pins: two integers array, represents a group of pins mux and config
- setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is
- a pin working on a specific function, CONFIG is the pad setting value
- such as pull-up, speed, ode for this pin. Please refer to Vybrid VF610
- datasheet for the valid pad config settings.
-
-CONFIG bits definition:
-PAD_CTL_SPEED_LOW (1 << 12)
-PAD_CTL_SPEED_MED (2 << 12)
-PAD_CTL_SPEED_HIGH (3 << 12)
-PAD_CTL_SRE_FAST (1 << 11)
-PAD_CTL_SRE_SLOW (0 << 11)
-PAD_CTL_ODE (1 << 10)
-PAD_CTL_HYS (1 << 9)
-PAD_CTL_DSE_DISABLE (0 << 6)
-PAD_CTL_DSE_150ohm (1 << 6)
-PAD_CTL_DSE_75ohm (2 << 6)
-PAD_CTL_DSE_50ohm (3 << 6)
-PAD_CTL_DSE_37ohm (4 << 6)
-PAD_CTL_DSE_30ohm (5 << 6)
-PAD_CTL_DSE_25ohm (6 << 6)
-PAD_CTL_DSE_20ohm (7 << 6)
-PAD_CTL_PUS_100K_DOWN (0 << 4)
-PAD_CTL_PUS_47K_UP (1 << 4)
-PAD_CTL_PUS_100K_UP (2 << 4)
-PAD_CTL_PUS_22K_UP (3 << 4)
-PAD_CTL_PKE (1 << 3)
-PAD_CTL_PUE (1 << 2)
-PAD_CTL_OBE_ENABLE (1 << 1)
-PAD_CTL_IBE_ENABLE (1 << 0)
-PAD_CTL_OBE_IBE_ENABLE (3 << 0)
-
-Please refer to vf610-pinfunc.h in device tree source folder
-for all available PIN_FUNC_ID for Vybrid VF610.
diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
index c2c370448b81..84e960255a36 100644
--- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/ingenic,pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs pin controller devicetree bindings
+title: Ingenic SoCs pin controller
description: >
Please refer to pinctrl-bindings.txt in this directory for details of the
@@ -42,6 +42,7 @@ properties:
- ingenic,jz4780-pinctrl
- ingenic,x1000-pinctrl
- ingenic,x1500-pinctrl
+ - ingenic,x1600-pinctrl
- ingenic,x1830-pinctrl
- ingenic,x2000-pinctrl
- ingenic,x2100-pinctrl
@@ -81,6 +82,7 @@ patternProperties:
- ingenic,jz4780-gpio
- ingenic,x1000-gpio
- ingenic,x1500-gpio
+ - ingenic,x1600-gpio
- ingenic,x1830-gpio
- ingenic,x2000-gpio
- ingenic,x2100-gpio
@@ -119,7 +121,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -135,7 +137,6 @@ additionalProperties:
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -147,8 +148,6 @@ additionalProperties:
additionalProperties: false
- type: object
- properties:
- phandle: true
additionalProperties:
type: object
allOf:
@@ -156,7 +155,6 @@ additionalProperties:
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
diff --git a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml
index b42548350188..1144ca2896e3 100644
--- a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/intel,lgm-io.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Lightning Mountain SoC pinmux & GPIO controller binding
+title: Intel Lightning Mountain SoC pinmux & GPIO controller
maintainers:
- Rahul Tanwar <rahul.tanwar@linux.intel.com>
@@ -48,7 +48,7 @@ patternProperties:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml
index 5e99d79499b4..005d95a9e4d6 100644
--- a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/intel,pinctrl-keembay.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Keem Bay pin controller Device Tree Bindings
+title: Intel Keem Bay pin controller
maintainers:
- Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
@@ -44,6 +44,7 @@ properties:
patternProperties:
'^gpio@[0-9a-f]*$':
type: object
+ additionalProperties: false
description:
Child nodes can be specified to contain pin configuration information,
diff --git a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml
deleted file mode 100644
index 0ec476248f21..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml
+++ /dev/null
@@ -1,119 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/intel,pinctrl-thunderbay.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Intel Thunder Bay pin controller Device Tree Bindings
-
-maintainers:
- - Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
-
-description: |
- Intel Thunder Bay SoC integrates a pin controller which enables control
- of pin directions, input/output values and configuration
- for a total of 67 pins.
-
-properties:
- compatible:
- const: intel,thunderbay-pinctrl
-
- reg:
- maxItems: 1
-
- gpio-controller: true
-
- '#gpio-cells':
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- interrupts:
- description:
- Specifies the interrupt lines to be used by the controller.
- maxItems: 2
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
-
-patternProperties:
- '^gpio@[0-9a-f]*$':
- type: object
-
- description:
- Child nodes can be specified to contain pin configuration information,
- which can then be utilized by pinctrl client devices.
- The following properties are supported.
-
- properties:
- pins:
- description: |
- The name(s) of the pins to be configured in the child node.
- Supported pin names are "GPIO0" up to "GPIO66".
-
- bias-disable: true
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- drive-strength:
- description: Drive strength for the pad.
- enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
-
- bias-bus-hold:
- type: boolean
-
- input-schmitt-enable:
- type: boolean
-
- slew-rate:
- description: GPIO slew rate control.
- 0 - Slow
- 1 - Fast
- enum: [0, 1]
-
-additionalProperties: false
-
-required:
- - compatible
- - reg
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- // Example 1
- pinctrl0: gpio@0 {
- compatible = "intel,thunderbay-pinctrl";
- reg = <0x600b0000 0x88>;
- gpio-controller;
- #gpio-cells = <0x2>;
- gpio-ranges = <&pinctrl0 0 0 67>;
- interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- // Example 2
- pinctrl1: gpio@1 {
- compatible = "intel,thunderbay-pinctrl";
- reg = <0x600c0000 0x88>;
- gpio-controller;
- #gpio-cells = <0x2>;
- gpio-ranges = <&pinctrl1 0 0 53>;
- interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt b/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt
index 4658f105fa09..6bd9bc61becb 100644
--- a/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt
+++ b/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt
@@ -1,11 +1,7 @@
Lantiq XWAY pinmux controller
Required properties:
-- compatible: "lantiq,pinctrl-xway", (DEPRECATED: Use "lantiq,pinctrl-danube")
- "lantiq,pinctrl-xr9", (DEPRECATED: Use "lantiq,xrx100-pinctrl" or
- "lantiq,xrx200-pinctrl")
- "lantiq,pinctrl-ase", (DEPRECATED: Use "lantiq,ase-pinctrl")
- "lantiq,<chip>-pinctrl", where <chip> is:
+- compatible: "lantiq,<chip>-pinctrl", where <chip> is:
"ase" (XWAY AMAZON Family)
"danube" (XWAY DANUBE Family)
"xrx100" (XWAY xRX100 Family)
@@ -45,29 +41,6 @@ Required subnode-properties:
Valid values for group and function names:
-XWAY: (DEPRECATED: Use DANUBE)
- mux groups:
- exin0, exin1, exin2, jtag, ebu a23, ebu a24, ebu a25, ebu clk, ebu cs1,
- ebu wait, nand ale, nand cs1, nand cle, spi, spi_cs1, spi_cs2, spi_cs3,
- spi_cs4, spi_cs5, spi_cs6, asc0, asc0 cts rts, stp, nmi, gpt1, gpt2,
- gpt3, clkout0, clkout1, clkout2, clkout3, gnt1, gnt2, gnt3, req1, req2,
- req3
-
- functions:
- spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu
-
-XR9: ( DEPRECATED: Use xRX100/xRX200)
- mux groups:
- exin0, exin1, exin2, exin3, exin4, jtag, ebu a23, ebu a24, ebu a25,
- ebu clk, ebu cs1, ebu wait, nand ale, nand cs1, nand cle, nand rdy,
- nand rd, spi, spi_cs1, spi_cs2, spi_cs3, spi_cs4, spi_cs5, spi_cs6,
- asc0, asc0 cts rts, stp, nmi, gpt1, gpt2, gpt3, clkout0, clkout1,
- clkout2, clkout3, gnt1, gnt2, gnt3, gnt4, req1, req2, req3, req4, mdio,
- gphy0 led0, gphy0 led1, gphy0 led2, gphy1 led0, gphy1 led1, gphy1 led2
-
- functions:
- spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu, mdio, gphy
-
AMAZON:
mux groups:
exin0, exin1, exin2, jtag, spi_di, spi_do, spi_clk, spi_cs1, spi_cs2,
@@ -139,12 +112,6 @@ Optional subnode-properties:
0: none, 1: down, 2: up.
- lantiq,open-drain: Boolean, enables open-drain on the defined pin.
-Valid values for XWAY pin names: (DEPRECATED: Use DANUBE)
- Pinconf pins can be referenced via the names io0-io31.
-
-Valid values for XR9 pin names: (DEPRECATED: Use xrX100/xRX200)
- Pinconf pins can be referenced via the names io0-io55.
-
Valid values for AMAZON pin names:
Pinconf pins can be referenced via the names io0-io31.
diff --git a/Documentation/devicetree/bindings/pinctrl/loongson,ls2k-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k-pinctrl.yaml
new file mode 100644
index 000000000000..bd8a45843566
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/loongson,ls2k-pinctrl.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/loongson,ls2k-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 SoC Pinctrl Controller
+
+maintainers:
+ - zhanghongchen <zhanghongchen@loongson.cn>
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ const: loongson,ls2k-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+
+ additionalProperties: false
+
+ patternProperties:
+ 'pinmux$':
+ type: object
+ description: node for pinctrl.
+ $ref: pinmux-node.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ groups:
+ description:
+ One or more groups of pins to mux to a certain function
+ items:
+ enum: [gpio, sdio, can1, can0, pwm3, pwm2, pwm1, pwm0, i2c1, i2c0,
+ nand, sata_led, i2s, hda]
+ function:
+ description:
+ The function that a group of pins is muxed to
+ enum: [gpio, sdio, can1, can0, pwm3, pwm2, pwm1, pwm0, i2c1, i2c0,
+ nand, sata_led, i2s, hda]
+
+ required:
+ - groups
+ - function
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pctrl: pinctrl@1fe00420 {
+ compatible = "loongson,ls2k-pinctrl";
+ reg = <0x1fe00420 0x18>;
+ sdio_pins_default: sdio-pins {
+ sdio-pinmux {
+ groups = "sdio";
+ function = "sdio";
+ };
+
+ sdio-det-pinmux {
+ groups = "pwm2";
+ function = "gpio";
+ };
+ };
+
+ pwm1_pins_default: pwm1-pins {
+ pinmux {
+ groups = "pwm1";
+ function = "pwm1";
+ };
+ };
+
+ pwm0_pins_default: pwm0-pins {
+ pinmux {
+ groups = "pwm0";
+ function = "pwm0";
+ };
+ };
+
+ i2c1_pins_default: i2c1-pins {
+ pinmux {
+ groups = "i2c1";
+ function = "i2c1";
+ };
+ };
+
+ i2c0_pins_default: i2c0-pins {
+ pinmux {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+ };
+
+ nand_pins_default: nand-pins {
+ pinmux {
+ groups = "nand";
+ function = "nand";
+ };
+ };
+
+ hda_pins_default: hda-pins {
+ grp0-pinmux {
+ groups = "hda";
+ function = "hda";
+ };
+
+ grp1-pinmux {
+ groups = "i2s";
+ function = "gpio";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml
index a651b2744caf..afea9424c7e1 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml
@@ -24,10 +24,11 @@ patternProperties:
'-pins$':
type: object
$ref: pinmux-node.yaml#
+ additionalProperties: false
properties:
marvell,function:
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
description:
Indicates the function to select.
enum: [ dev_init_done, ge, gpio, i2c0, i2c1, int_out, led, nand, pcie, ptp, sdio,
@@ -46,7 +47,7 @@ patternProperties:
mpp40, mpp41, mpp42, mpp43, mpp44, mpp45 ]
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,ap806-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,ap806-pinctrl.yaml
new file mode 100644
index 000000000000..00a7e358a8c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,ap806-pinctrl.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/marvell,ap806-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell AP806 pin controller
+
+maintainers:
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ const: marvell,ap806-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ marvell,function:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Indicates the function to select.
+ enum: [ gpio, i2c0, sdio, spi0, uart0, uart1 ]
+
+ marvell,pins:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ Array of MPP pins to be used for the given function.
+ minItems: 1
+ maxItems: 20
+ items:
+ enum: [
+ mpp0, mpp1, mpp2, mpp3, mpp4, mpp5, mpp6, mpp7, mpp8, mpp9, mpp10,
+ mpp11, mpp12, mpp13, mpp14, mpp15, mpp16, mpp17, mpp18, mpp19
+ ]
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "marvell,ap806-pinctrl";
+
+ uart0_pins: uart0-pins {
+ marvell,pins = "mpp11", "mpp19";
+ marvell,function = "uart0";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
deleted file mode 100644
index ecec514b3155..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
+++ /dev/null
@@ -1,195 +0,0 @@
-* Marvell Armada 37xx SoC pin and gpio controller
-
-Each Armada 37xx SoC come with two pin and gpio controller one for the
-south bridge and the other for the north bridge.
-
-Inside this set of register the gpio latch allows exposing some
-configuration of the SoC and especially the clock frequency of the
-xtal. Hence, this node is a represent as syscon allowing sharing the
-register between multiple hardware block.
-
-GPIO and pin controller:
-------------------------
-
-Main node:
-
-Refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning
-of the phrase "pin configuration node".
-
-Required properties for pinctrl driver:
-
-- compatible: "marvell,armada3710-sb-pinctrl", "syscon, "simple-mfd"
- for the south bridge
- "marvell,armada3710-nb-pinctrl", "syscon, "simple-mfd"
- for the north bridge
-- reg: The first set of register are for pinctrl/gpio and the second
- set for the interrupt controller
-- interrupts: list of the interrupt use by the gpio
-
-Available groups and functions for the North bridge:
-
-group: jtag
- - pins 20-24
- - functions jtag, gpio
-
-group sdio0
- - pins 8-10
- - functions sdio, gpio
-
-group emmc_nb
- - pins 27-35
- - functions emmc, gpio
-
-group pwm0
- - pin 11 (GPIO1-11)
- - functions pwm, led, gpio
-
-group pwm1
- - pin 12
- - functions pwm, led, gpio
-
-group pwm2
- - pin 13
- - functions pwm, led, gpio
-
-group pwm3
- - pin 14
- - functions pwm, led, gpio
-
-group pmic1
- - pin 7
- - functions pmic, gpio
-
-group pmic0
- - pin 6
- - functions pmic, gpio
-
-group i2c2
- - pins 2-3
- - functions i2c, gpio
-
-group i2c1
- - pins 0-1
- - functions i2c, gpio
-
-group spi_cs1
- - pin 17
- - functions spi, gpio
-
-group spi_cs2
- - pin 18
- - functions spi, gpio
-
-group spi_cs3
- - pin 19
- - functions spi, gpio
-
-group onewire
- - pin 4
- - functions onewire, gpio
-
-group uart1
- - pins 25-26
- - functions uart, gpio
-
-group spi_quad
- - pins 15-16
- - functions spi, gpio
-
-group uart2
- - pins 9-10 and 18-19
- - functions uart, gpio
-
-Available groups and functions for the South bridge:
-
-group usb32_drvvbus0
- - pin 36
- - functions drvbus, gpio
-
-group usb2_drvvbus1
- - pin 37
- - functions drvbus, gpio
-
-group sdio_sb
- - pins 60-65
- - functions sdio, gpio
-
-group rgmii
- - pins 42-53
- - functions mii, gpio
-
-group pcie1
- - pins 39
- - functions pcie, gpio
-
-group pcie1_clkreq
- - pins 40
- - functions pcie, gpio
-
-group pcie1_wakeup
- - pins 41
- - functions pcie, gpio
-
-group smi
- - pins 54-55
- - functions smi, gpio
-
-group ptp
- - pins 56
- - functions ptp, gpio
-
-group ptp_clk
- - pin 57
- - functions ptp, mii
-
-group ptp_trig
- - pin 58
- - functions ptp, mii
-
-group mii_col
- - pin 59
- - functions mii, mii_err
-
-GPIO subnode:
-
-Please refer to gpio.txt in this directory for details of gpio-ranges property
-and the common GPIO bindings used by client devices.
-
-Required properties for gpio driver under the gpio subnode:
-- interrupts: List of interrupt specifier for the controllers interrupt.
-- gpio-controller: Marks the device node as a gpio controller.
-- #gpio-cells: Should be 2. The first cell is the GPIO number and the
- second cell specifies GPIO flags, as defined in
- <dt-bindings/gpio/gpio.h>. Only the GPIO_ACTIVE_HIGH and
- GPIO_ACTIVE_LOW flags are supported.
-- gpio-ranges: Range of pins managed by the GPIO controller.
-
-Xtal Clock bindings for Marvell Armada 37xx SoCs
-------------------------------------------------
-
-see Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
-
-
-Example:
-pinctrl_sb: pinctrl-sb@18800 {
- compatible = "marvell,armada3710-sb-pinctrl", "syscon", "simple-mfd";
- reg = <0x18800 0x100>, <0x18C00 0x20>;
- gpio {
- #gpio-cells = <2>;
- gpio-ranges = <&pinctrl_sb 0 0 29>;
- gpio-controller;
- interrupts =
- <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- rgmii_pins: mii-pins {
- groups = "rgmii";
- function = "mii";
- };
-
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-7k-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,armada-7k-pinctrl.yaml
new file mode 100644
index 000000000000..88910ad170e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-7k-pinctrl.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/marvell,armada-7k-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 7K/8K pin controller
+
+maintainers:
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-7k-pinctrl
+ - marvell,armada-8k-cpm-pinctrl
+ - marvell,armada-8k-cps-pinctrl
+ - marvell,cp115-standalone-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins(-.+)?$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ marvell,function:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Indicates the function to select.
+ enum: [
+ au, dev, ge, ge0, ge1, gpio, i2c0, i2c1, led, link, mii, mss_gpio0,
+ mss_gpio1, mss_gpio2, mss_gpio3, mss_gpio4, mss_gpio5, mss_gpio6,
+ mss_gpio7, mss_i2c, mss_spi, mss_uart, nf, pcie, pcie0, pcie1, pcie2,
+ ptp, rei, sata0, sata1, sdio, sdio_cd, sdio_wp, sei, spi0, spi1,
+ synce1, synce2, tdm, uart0, uart1, uart2, uart3, wakeup, xg
+ ]
+
+ marvell,pins:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ Array of MPP pins to be used for the given function.
+ minItems: 1
+ maxItems: 63
+ items:
+ pattern: '^mpp([1-5]?[0-9]|6[0-2])$'
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "marvell,armada-7k-pinctrl";
+
+ nand_pins: nand-pins {
+ marvell,pins =
+ "mpp15", "mpp16", "mpp17", "mpp18",
+ "mpp19", "mpp20", "mpp21", "mpp22",
+ "mpp23", "mpp24", "mpp25", "mpp26",
+ "mpp27";
+ marvell,function = "dev";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml
new file mode 100644
index 000000000000..51bad2e8d6f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/marvell,armada3710-xb-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 37xx SoC pin and gpio controller
+
+maintainers:
+ - Gregory CLEMENT <gregory.clement@bootlin.com>
+ - Marek Behún <kabel@kernel.org>
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+description: >
+ Each Armada 37xx SoC come with two pin and gpio controller one for the south
+ bridge and the other for the north bridge.
+
+ Inside this set of register the gpio latch allows exposing some configuration
+ of the SoC and especially the clock frequency of the xtal. Hence, this node is
+ a represent as syscon allowing sharing the register between multiple hardware
+ block.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - marvell,armada3710-sb-pinctrl
+ - marvell,armada3710-nb-pinctrl
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ items:
+ - description: pinctrl and GPIO controller registers
+ - description: interrupt controller registers
+
+ gpio:
+ description: GPIO controller subnode
+ type: object
+ additionalProperties: false
+
+ properties:
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ gpio-ranges:
+ description: Range of pins managed by the GPIO controller
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ interrupts:
+ description: List of interrupt specifiers for the GPIO controller
+
+ required:
+ - '#gpio-cells'
+ - gpio-ranges
+ - gpio-controller
+ - '#interrupt-cells'
+ - interrupt-controller
+ - interrupts
+
+ xtal-clk:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: marvell,armada-3700-xtal-clock
+
+ '#clock-cells':
+ const: 0
+
+ clock-output-names: true
+
+patternProperties:
+ '-pins$':
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ groups:
+ enum: [ emmc_nb, i2c1, i2c2, jtag, mii_col, onewire, pcie1,
+ pcie1_clkreq, pcie1_wakeup, pmic0, pmic1, ptp, ptp_clk,
+ ptp_trig, pwm0, pwm1, pwm2, pwm3, rgmii, sdio0, sdio_sb, smi,
+ spi_cs1, spi_cs2, spi_cs3, spi_quad, uart1, uart2,
+ usb2_drvvbus1, usb32_drvvbus ]
+
+ function:
+ enum: [ drvbus, emmc, gpio, i2c, jtag, led, mii, mii_err, onewire,
+ pcie, pmic, ptp, pwm, sdio, smi, spi, uart ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl_sb: pinctrl@18800 {
+ compatible = "marvell,armada3710-sb-pinctrl", "syscon", "simple-mfd";
+ reg = <0x18800 0x100>, <0x18C00 0x20>;
+
+ gpio {
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_sb 0 0 29>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupts =
+ <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,berlin2-soc-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,berlin2-soc-pinctrl.yaml
new file mode 100644
index 000000000000..6ace3bf5433b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,berlin2-soc-pinctrl.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/marvell,berlin2-soc-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Berlin pin-controller driver
+
+maintainers:
+ - Antoine Tenart <atenart@kernel.org>
+ - Jisheng Zhang <jszhang@kernel.org>
+
+description: >
+ Pin control registers are part of both chip controller and system controller
+ register sets. Pin controller nodes should be a sub-node of either the chip
+ controller or system controller node. The pins controlled are organized in
+ groups, so no actual pin information is needed.
+
+ A pin-controller node should contain subnodes representing the pin group
+ configurations, one per function. Each subnode has the group name and the
+ muxing function used.
+
+ Be aware the Marvell Berlin datasheets use the keyword 'mode' for what is
+ called a 'function' in the pin-controller subsystem.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - marvell,berlin2-soc-pinctrl
+ - marvell,berlin2-system-pinctrl
+ - marvell,berlin2cd-soc-pinctrl
+ - marvell,berlin2cd-system-pinctrl
+ - marvell,berlin2q-soc-pinctrl
+ - marvell,berlin2q-system-pinctrl
+ - marvell,berlin4ct-avio-pinctrl
+ - marvell,berlin4ct-soc-pinctrl
+ - marvell,berlin4ct-system-pinctrl
+ - syna,as370-soc-pinctrl
+
+ reg:
+ maxItems: 1
+
+additionalProperties:
+ description: Pin group configuration subnodes.
+ type: object
+ $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ groups:
+ description: List of pin group names.
+ $ref: /schemas/types.yaml#/definitions/string-array
+
+ function:
+ description: Function used to mux the group.
+ $ref: /schemas/types.yaml#/definitions/string
+
+ required:
+ - groups
+ - function
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,berlin4ct-avio-pinctrl
+ - marvell,berlin4ct-soc-pinctrl
+ - marvell,berlin4ct-system-pinctrl
+ - syna,as370-soc-pinctrl
+ then:
+ required:
+ - reg
+
+examples:
+ - |
+ pinctrl {
+ compatible = "marvell,berlin2q-system-pinctrl";
+
+ uart0-pmux {
+ groups = "GSM12";
+ function = "uart0";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
index 161088a8be33..aa71398cf522 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT65xx Pin Controller Device Tree Bindings
+title: MediaTek MT65xx Pin Controller
maintainers:
- Sean Wang <sean.wang@kernel.org>
-description: |+
- The Mediatek's Pin controller is used to control SoC pins.
+description:
+ The MediaTek's MT65xx Pin controller is used to control SoC pins.
properties:
compatible:
@@ -30,17 +30,20 @@ properties:
pins-are-numbered:
$ref: /schemas/types.yaml#/definitions/flag
- description: |
- Specify the subnodes are using numbered pinmux to specify pins.
+ description:
+ Specify the subnodes are using numbered pinmux to specify pins. (UNUSED)
+ deprecated: true
gpio-controller: true
"#gpio-cells":
const: 2
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+
+ gpio-line-names: true
mediatek,pctl-regmap:
$ref: /schemas/types.yaml#/definitions/phandle-array
@@ -48,7 +51,7 @@ properties:
maxItems: 1
minItems: 1
maxItems: 2
- description: |
+ description:
Should be phandles of the syscfg node.
interrupt-controller: true
@@ -62,40 +65,39 @@ properties:
required:
- compatible
- - pins-are-numbered
- gpio-controller
- "#gpio-cells"
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
patternProperties:
- '-[0-9]+$':
+ 'pins$':
type: object
additionalProperties: false
patternProperties:
- 'pins':
+ '(^pins|pins?$)':
type: object
additionalProperties: false
- description: |
+ description:
A pinctrl node should contain at least one subnodes representing the
pinctrl groups available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
configuration, pullups, drive strength, input enable/disable and input
schmitt.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: /schemas/pinctrl/pincfg-node.yaml
properties:
pinmux:
description:
- integer array, represents gpio pin number and mux setting.
+ Integer array, represents gpio pin number and mux setting.
Supported pin number and mux varies for different SoCs, and are
- defined as macros in <soc>-pinfunc.h directly.
+ defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
bias-disable: true
bias-pull-up:
- description: |
+ description:
Besides generic pinconfig options, it can be used as the pull up
settings for 2 pull resistors, R0 and R1. User can configure those
special pins. Some macros have been defined for this usage, such
@@ -117,7 +119,7 @@ patternProperties:
input-schmitt-disable: true
drive-strength:
- description: |
+ description:
Can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA,
etc. See dt-bindings/pinctrl/mt65xx.h for valid arguments.
@@ -136,76 +138,44 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
- syscfg_pctl_a: syscfg-pctl-a@10005000 {
- compatible = "mediatek,mt8135-pctl-a-syscfg", "syscon";
- reg = <0 0x10005000 0 0x1000>;
- };
-
- syscfg_pctl_b: syscfg-pctl-b@1020c020 {
- compatible = "mediatek,mt8135-pctl-b-syscfg", "syscon";
- reg = <0 0x1020C020 0 0x1000>;
- };
-
pinctrl@1c20800 {
- compatible = "mediatek,mt8135-pinctrl";
- reg = <0 0x1000B000 0 0x1000>;
- mediatek,pctl-regmap = <&syscfg_pctl_a>, <&syscfg_pctl_b>;
- pins-are-numbered;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
-
- i2c0_pins_a: i2c0-0 {
- pins1 {
- pinmux = <MT8135_PIN_100_SDA0__FUNC_SDA0>,
- <MT8135_PIN_101_SCL0__FUNC_SCL0>;
- bias-disable;
+ compatible = "mediatek,mt8135-pinctrl";
+ reg = <0 0x1000B000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl_a>, <&syscfg_pctl_b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+
+ i2c0_pins_a: i2c0-pins {
+ pins1 {
+ pinmux = <MT8135_PIN_100_SDA0__FUNC_SDA0>,
+ <MT8135_PIN_101_SCL0__FUNC_SCL0>;
+ bias-disable;
+ };
};
- };
- i2c1_pins_a: i2c1-0 {
- pins {
- pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>,
- <MT8135_PIN_196_SCL1__FUNC_SCL1>;
- bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ i2c1_pins_a: i2c1-pins {
+ pins {
+ pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>,
+ <MT8135_PIN_196_SCL1__FUNC_SCL1>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
};
- };
- i2c2_pins_a: i2c2-0 {
- pins1 {
- pinmux = <MT8135_PIN_193_SDA2__FUNC_SDA2>;
- bias-pull-down;
- };
-
- pins2 {
- pinmux = <MT8135_PIN_49_WATCHDOG__FUNC_GPIO49>;
- bias-pull-up;
- };
- };
-
- i2c3_pins_a: i2c3-0 {
- pins1 {
- pinmux = <MT8135_PIN_40_DAC_CLK__FUNC_GPIO40>,
- <MT8135_PIN_41_DAC_WS__FUNC_GPIO41>;
- bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
- };
-
- pins2 {
- pinmux = <MT8135_PIN_35_SCL3__FUNC_SCL3>,
- <MT8135_PIN_36_SDA3__FUNC_SDA3>;
- output-low;
- bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
- };
+ i2c2_pins_a: i2c2-pins {
+ pins1 {
+ pinmux = <MT8135_PIN_193_SDA2__FUNC_SDA2>;
+ bias-pull-down;
+ };
- pins3 {
- pinmux = <MT8135_PIN_57_JTCK__FUNC_GPIO57>,
- <MT8135_PIN_60_JTDI__FUNC_JTDI>;
- drive-strength = <32>;
+ pins2 {
+ pinmux = <MT8135_PIN_49_WATCHDOG__FUNC_GPIO49>;
+ bias-pull-up;
+ };
};
- };
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
index e7601c0f5a69..f4bab7a132d3 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
@@ -4,94 +4,134 @@
$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6779-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT6779 Pin Controller Device Tree Bindings
+title: MediaTek MT6779 Pin Controller
maintainers:
- Andy Teng <andy.teng@mediatek.com>
+ - Sean Wang <sean.wang@kernel.org>
-description: |+
- The pin controller node should be the child of a syscon node with the
- required property:
- - compatible: "syscon"
+description:
+ The MediaTek pin controller on MT6779 is used to control pin functions, pull
+ up/down resistance and drive strength options.
properties:
compatible:
- const: mediatek,mt6779-pinctrl
+ enum:
+ - mediatek,mt6779-pinctrl
+ - mediatek,mt6797-pinctrl
reg:
- minItems: 9
- maxItems: 9
-
- reg-names:
- items:
- - const: "gpio"
- - const: "iocfg_rm"
- - const: "iocfg_br"
- - const: "iocfg_lm"
- - const: "iocfg_lb"
- - const: "iocfg_rt"
- - const: "iocfg_lt"
- - const: "iocfg_tl"
- - const: "eint"
+ description: Physical addresses for GPIO base(s) and EINT registers.
+
+ reg-names: true
gpio-controller: true
"#gpio-cells":
const: 2
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
gpio-ranges:
minItems: 1
maxItems: 5
- description: |
+ description:
GPIO valid number range.
interrupt-controller: true
interrupts:
maxItems: 1
- description: |
+ description:
Specifies the summary IRQ.
"#interrupt-cells":
const: 2
-allOf:
- - $ref: "pinctrl.yaml#"
-
required:
- compatible
- reg
- reg-names
- gpio-controller
- "#gpio-cells"
- - gpio-ranges
- - interrupt-controller
- - interrupts
- - "#interrupt-cells"
+
+allOf:
+ - $ref: pinctrl.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt6779-pinctrl
+ then:
+ properties:
+ reg:
+ minItems: 9
+ maxItems: 9
+
+ reg-names:
+ items:
+ - const: gpio
+ - const: iocfg_rm
+ - const: iocfg_br
+ - const: iocfg_lm
+ - const: iocfg_lb
+ - const: iocfg_rt
+ - const: iocfg_lt
+ - const: iocfg_tl
+ - const: eint
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt6797-pinctrl
+ then:
+ properties:
+ reg:
+ minItems: 5
+ maxItems: 5
+
+ reg-names:
+ items:
+ - const: gpio
+ - const: iocfgl
+ - const: iocfgb
+ - const: iocfgr
+ - const: iocfgt
+ - if:
+ properties:
+ reg-names:
+ contains:
+ const: eint
+ then:
+ required:
+ - interrupts
+ - interrupt-controller
+ - "#interrupt-cells"
patternProperties:
'-[0-9]*$':
type: object
+ additionalProperties: false
+
patternProperties:
'-pins*$':
type: object
- description: |
+ description:
A pinctrl node should contain at least one subnodes representing the
pinctrl groups available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
- configuration, pullups, drive strength, input enable/disable and input schmitt.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
properties:
pinmux:
description:
- integer array, represents gpio pin number and mux setting.
- Supported pin number and mux varies for different SoCs, and are defined
- as macros in boot/dts/<soc>-pinfunc.h directly.
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
bias-disable: true
@@ -111,10 +151,17 @@ patternProperties:
input-schmitt-disable: true
+ drive-strength:
+ enum: [2, 4, 8, 12, 16]
+
+ slew-rate:
+ enum: [0, 1]
+
mediatek,pull-up-adv:
description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
+ Pull up settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as
+ below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
@@ -125,7 +172,8 @@ patternProperties:
mediatek,pull-down-adv:
description: |
Pull down settings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
+ configure those special pins. Valid arguments are described as
+ below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
@@ -197,9 +245,4 @@ examples:
};
};
};
-
- mmc0 {
- pinctrl-0 = <&mmc0_pins_default>;
- pinctrl-names = "default";
- };
};
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
new file mode 100644
index 000000000000..68e91c05f122
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml
@@ -0,0 +1,228 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6795-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6795 Pin Controller
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - Sean Wang <sean.wang@kernel.org>
+
+description:
+ The MediaTek's MT6795 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt6795-pinctrl
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+ const: 2
+
+ gpio-ranges:
+ description: GPIO valid number range.
+ maxItems: 1
+
+ reg:
+ description:
+ Physical address base for GPIO base and eint registers.
+ minItems: 2
+
+ reg-names:
+ items:
+ - const: base
+ - const: eint
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description: Interrupt outputs to the system interrupt controller (sysirq).
+ minItems: 1
+ items:
+ - description: EINT interrupt
+ - description: EINT event_b interrupt
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '^pins':
+ type: object
+ additionalProperties: false
+ description: |
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ An example of using macro:
+ pincontroller {
+ /* GPIO0 set as multifunction GPIO0 */
+ gpio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ }
+ };
+ /* GPIO45 set as multifunction SDA0 */
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO45__FUNC_SDA0>;
+ }
+ };
+ };
+ $ref: pinmux-node.yaml
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt6795 pull down PUPD/R0/R1 type define value.
+ description:
+ For normal pull down type, it is not necessary to specify R1R0
+ values; When pull down type is PUPD/R0/R1, adding R1R0 defines
+ will set different resistance values.
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt6795 pull up PUPD/R0/R1 type define value.
+ description:
+ For normal pull up type, it is not necessary to specify R1R0
+ values; When pull up type is PUPD/R0/R1, adding R1R0 defines will
+ set different resistance values.
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ mediatek,pull-up-adv:
+ description: |
+ Pull up settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as
+ below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ description: |
+ Pull down settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as
+ below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ required:
+ - pinmux
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/pinctrl/mt6795-pinfunc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt6795-pinctrl";
+ reg = <0 0x10005000 0 0x1000>, <0 0x1000b000 0 0x1000>;
+ reg-names = "base", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 196>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+
+ i2c0-pins {
+ pins-sda-scl {
+ pinmux = <PINMUX_GPIO45__FUNC_SDA0>,
+ <PINMUX_GPIO46__FUNC_SCL0>;
+ };
+ };
+
+ mmc0-pins {
+ pins-cmd-dat {
+ pinmux = <PINMUX_GPIO154__FUNC_MSDC0_DAT0>,
+ <PINMUX_GPIO155__FUNC_MSDC0_DAT1>,
+ <PINMUX_GPIO156__FUNC_MSDC0_DAT2>,
+ <PINMUX_GPIO157__FUNC_MSDC0_DAT3>,
+ <PINMUX_GPIO158__FUNC_MSDC0_DAT4>,
+ <PINMUX_GPIO159__FUNC_MSDC0_DAT5>,
+ <PINMUX_GPIO160__FUNC_MSDC0_DAT6>,
+ <PINMUX_GPIO161__FUNC_MSDC0_DAT7>,
+ <PINMUX_GPIO162__FUNC_MSDC0_CMD>;
+ input-enable;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
+ };
+
+ pins-clk {
+ pinmux = <PINMUX_GPIO163__FUNC_MSDC0_CLK>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+ };
+
+ pins-rst {
+ pinmux = <PINMUX_GPIO165__FUNC_MSDC0_RSTB>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml
deleted file mode 100644
index d42215f59afd..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml
+++ /dev/null
@@ -1,176 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6797-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mediatek MT6797 Pin Controller Device Tree Bindings
-
-maintainers:
- - Sean Wang <sean.wang@kernel.org>
-
-description: |+
- The MediaTek's MT6797 Pin controller is used to control SoC pins.
-
-properties:
- compatible:
- const: mediatek,mt6797-pinctrl
-
- reg:
- minItems: 5
- maxItems: 5
-
- reg-names:
- items:
- - const: gpio
- - const: iocfgl
- - const: iocfgb
- - const: iocfgr
- - const: iocfgt
-
- gpio-controller: true
-
- "#gpio-cells":
- const: 2
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
-
- interrupt-controller: true
-
- interrupts:
- maxItems: 1
-
- "#interrupt-cells":
- const: 2
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - reg-names
- - gpio-controller
- - "#gpio-cells"
-
-patternProperties:
- '-[0-9]+$':
- type: object
- additionalProperties: false
- patternProperties:
- 'pins':
- type: object
- additionalProperties: false
- description: |
- A pinctrl node should contain at least one subnodes representing the
- pinctrl groups available on the machine. Each subnode will list the
- pins it needs, and how they should be configured, with regard to muxer
- configuration, pullups, drive strength, input enable/disable and input
- schmitt.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
-
- properties:
- pinmux:
- description:
- integer array, represents gpio pin number and mux setting.
- Supported pin number and mux varies for different SoCs, and are
- defined as macros in <soc>-pinfunc.h directly.
-
- bias-disable: true
-
- bias-pull-up: true
-
- bias-pull-down: true
-
- input-enable: true
-
- input-disable: true
-
- output-enable: true
-
- output-low: true
-
- output-high: true
-
- input-schmitt-enable: true
-
- input-schmitt-disable: true
-
- drive-strength:
- enum: [2, 4, 8, 12, 16]
-
- slew-rate:
- enum: [0, 1]
-
- mediatek,pull-up-adv:
- description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
- 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
- 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
- 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
- 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2, 3]
-
- mediatek,pull-down-adv:
- description: |
- Pull down settings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
- 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
- 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
- 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
- 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2, 3]
-
- mediatek,tdsel:
- description: |
- An integer describing the steps for output level shifter duty
- cycle when asserted (high pulse width adjustment). Valid arguments
- are from 0 to 15.
- $ref: /schemas/types.yaml#/definitions/uint32
-
- mediatek,rdsel:
- description: |
- An integer describing the steps for input level shifter duty cycle
- when asserted (high pulse width adjustment). Valid arguments are
- from 0 to 63.
- $ref: /schemas/types.yaml#/definitions/uint32
-
- required:
- - pinmux
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/pinctrl/mt6797-pinfunc.h>
-
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
-
- pio: pinctrl@10005000 {
- compatible = "mediatek,mt6797-pinctrl";
- reg = <0 0x10005000 0 0x1000>,
- <0 0x10002000 0 0x400>,
- <0 0x10002400 0 0x400>,
- <0 0x10002800 0 0x400>,
- <0 0x10002C00 0 0x400>;
- reg-names = "gpio", "iocfgl", "iocfgb", "iocfgr", "iocfgt";
- gpio-controller;
- #gpio-cells = <2>;
-
- uart_pins_a: uart-0 {
- pins1 {
- pinmux = <MT6797_GPIO232__FUNC_URXD1>,
- <MT6797_GPIO233__FUNC_UTXD1>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6878-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6878-pinctrl.yaml
new file mode 100644
index 000000000000..8d44194a7938
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6878-pinctrl.yaml
@@ -0,0 +1,211 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6878-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6878 Pin Controller
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - Igor Belwon <igor.belwon@mentallysanemainliners.org>
+
+description:
+ The MediaTek MT6878 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt6878-pinctrl
+
+ reg:
+ items:
+ - description: pin controller base
+ - description: bl group IO
+ - description: bm group IO
+ - description: br group IO
+ - description: bl1 group IO
+ - description: br1 group IO
+ - description: lm group IO
+ - description: lt group IO
+ - description: rm group IO
+ - description: rt group IO
+ - description: EINT controller E block
+ - description: EINT controller S block
+ - description: EINT controller W block
+ - description: EINT controller C block
+
+ reg-names:
+ items:
+ - const: base
+ - const: bl
+ - const: bm
+ - const: br
+ - const: bl1
+ - const: br1
+ - const: lm
+ - const: lt
+ - const: rm
+ - const: rt
+ - const: eint-e
+ - const: eint-s
+ - const: eint-w
+ - const: eint-c
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names:
+ maxItems: 216
+
+ interrupts:
+ description: The interrupt outputs to sysirq
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^pins':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ description:
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux are defined as macros in
+ arch/arm64/boot/dts/mediatek/mt8196-pinfunc.h for this SoC.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [75000, 5000]
+ description: Pull down RSEL type resistance values (in ohms)
+ description:
+ For normal pull down type there is no need to specify a resistance
+ value, hence this can be specified as a boolean property.
+ For RSEL pull down type a resistance value (in ohms) can be added.
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [10000, 5000, 4000, 3000]
+ description: Pull up RSEL type resistance values (in ohms)
+ description:
+ For normal pull up type there is no need to specify a resistance
+ value, hence this can be specified as a boolean property.
+ For RSEL pull up type a resistance value (in ohms) can be added.
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt65xx.h>
+ #define PINMUX_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+ #define PINMUX_GPIO99__FUNC_SCL0 (MTK_PIN_NO(99) | 1)
+ #define PINMUX_GPIO100__FUNC_SDA0 (MTK_PIN_NO(100) | 1)
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt6878-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x11d10000 0x1000>,
+ <0x11d30000 0x1000>,
+ <0x11d40000 0x1000>,
+ <0x11d50000 0x1000>,
+ <0x11d60000 0x1000>,
+ <0x11e20000 0x1000>,
+ <0x11e30000 0x1000>,
+ <0x11eb0000 0x1000>,
+ <0x11ec0000 0x1000>,
+ <0x11ce0000 0x1000>,
+ <0x11de0000 0x1000>,
+ <0x11e60000 0x1000>,
+ <0x1c01e000 0x1000>;
+ reg-names = "base", "bl", "bm", "br", "bl1", "br1",
+ "lm", "lt", "rm", "rt", "eint-e", "eint-s",
+ "eint-w", "eint-c";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 220>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ gpio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ bias-pull-up = <4000>;
+ drive-strength = <6>;
+ };
+ };
+
+ i2c0-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO99__FUNC_SCL0>,
+ <PINMUX_GPIO100__FUNC_SDA0>;
+ bias-pull-down = <75000>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6893-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6893-pinctrl.yaml
new file mode 100644
index 000000000000..fa189fe00624
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6893-pinctrl.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6893-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6893 Pin Controller
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek's MT6893 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt6893-pinctrl
+
+ reg:
+ items:
+ - description: pin controller base
+ - description: rm group IO
+ - description: bm group IO
+ - description: lm group IO
+ - description: lb group IO
+ - description: rt group IO
+ - description: lt group IO
+ - description: tm group IO
+ - description: External Interrupt (EINT) controller base
+
+ reg-names:
+ items:
+ - const: base
+ - const: rm
+ - const: bm
+ - const: lm
+ - const: lb
+ - const: rt
+ - const: lt
+ - const: tm
+ - const: eint
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names: true
+
+ interrupts:
+ description: The interrupt outputs to sysirq
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^pins':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ description:
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux are defined as macros in
+ arch/arm64/boot/dts/mediatek/mt8196-pinfunc.h for this SoC.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [75000, 5000]
+ description: Pull down RSEL type resistance values (in ohms)
+ description:
+ For normal pull down type there is no need to specify a resistance
+ value, hence this can be specified as a boolean property.
+ For RSEL pull down type a resistance value (in ohms) can be added.
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [10000, 5000, 4000, 3000]
+ description: Pull up RSEL type resistance values (in ohms)
+ description:
+ For normal pull up type there is no need to specify a resistance
+ value, hence this can be specified as a boolean property.
+ For RSEL pull up type a resistance value (in ohms) can be added.
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt65xx.h>
+ #define PINMUX_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+ #define PINMUX_GPIO99__FUNC_SCL0 (MTK_PIN_NO(99) | 1)
+ #define PINMUX_GPIO100__FUNC_SDA0 (MTK_PIN_NO(100) | 1)
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt6893-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x11c20000 0x0200>,
+ <0x11d10000 0x0200>,
+ <0x11e20000 0x0200>,
+ <0x11e70000 0x0200>,
+ <0x11ea0000 0x0200>,
+ <0x11f20000 0x0200>,
+ <0x11f30000 0x0200>,
+ <0x1100b000 0x1000>;
+ reg-names = "base", "rm", "bm", "lm", "lb", "rt",
+ "lt", "tm", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 220>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ gpio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ bias-pull-up = <4000>;
+ drive-strength = <6>;
+ };
+ };
+
+ i2c0-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO99__FUNC_SCL0>,
+ <PINMUX_GPIO100__FUNC_SDA0>;
+ bias-pull-down = <75000>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml
new file mode 100644
index 000000000000..591bc0664ec6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml
@@ -0,0 +1,298 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7620-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7620 Pin Controller
+
+maintainers:
+ - Arınç ÜNAL <arinc.unal@arinc9.com>
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ MediaTek MT7620 pin controller for MT7620 SoC.
+ The pin controller can only set the muxing of pin groups. Muxing individual
+ pins is not supported. There is no pinconf support.
+
+properties:
+ compatible:
+ const: ralink,mt7620-pinctrl
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^(.*-)?pinmux$':
+ type: object
+ description: node for pinctrl.
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [ephy, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, mdio, nand,
+ pa, pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf,
+ refclk, rgmii1, rgmii2, sd, spi, spi refclk, uartf, uartlite,
+ wdt refclk, wdt rst, wled]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
+ required:
+ - groups
+ - function
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: ephy
+ then:
+ properties:
+ groups:
+ enum: [ephy]
+
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [ephy, i2c, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, spi,
+ spi refclk, uartf, uartlite, wdt, wled]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: nand
+ then:
+ properties:
+ groups:
+ enum: [nd_sd]
+
+ - if:
+ properties:
+ function:
+ const: pa
+ then:
+ properties:
+ groups:
+ enum: [pa]
+
+ - if:
+ properties:
+ function:
+ const: pcie refclk
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcie rst
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: refclk
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: rgmii1
+ then:
+ properties:
+ groups:
+ enum: [rgmii1]
+
+ - if:
+ properties:
+ function:
+ const: rgmii2
+ then:
+ properties:
+ groups:
+ enum: [rgmii2]
+
+ - if:
+ properties:
+ function:
+ const: sd
+ then:
+ properties:
+ groups:
+ enum: [nd_sd]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: spi refclk
+ then:
+ properties:
+ groups:
+ enum: [spi refclk]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: wdt refclk
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wdt rst
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wled
+ then:
+ properties:
+ groups:
+ enum: [wled]
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "ralink,mt7620-pinctrl";
+
+ i2c_pins: i2c0-pins {
+ pinmux {
+ groups = "i2c";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml
new file mode 100644
index 000000000000..e568b9c13727
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml
@@ -0,0 +1,261 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7621-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7621 Pin Controller
+
+maintainers:
+ - Arınç ÜNAL <arinc.unal@arinc9.com>
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ MediaTek MT7621 pin controller for MT7621 SoC.
+ The pin controller can only set the muxing of pin groups. Muxing individual
+ pins is not supported. There is no pinconf support.
+
+properties:
+ compatible:
+ const: ralink,mt7621-pinctrl
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^(.*-)?pinmux$':
+ type: object
+ description: node for pinctrl.
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk,
+ pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, spi,
+ uart1, uart2, uart3, wdt refclk, wdt rst]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
+ required:
+ - groups
+ - function
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi,
+ uart1, uart2, uart3, wdt]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s
+ then:
+ properties:
+ groups:
+ enum: [uart3]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: nand1
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: nand2
+ then:
+ properties:
+ groups:
+ enum: [sdhci]
+
+ - if:
+ properties:
+ function:
+ const: pcie refclk
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcie rst
+ then:
+ properties:
+ groups:
+ enum: [pcie]
+
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: rgmii1
+ then:
+ properties:
+ groups:
+ enum: [rgmii1]
+
+ - if:
+ properties:
+ function:
+ const: rgmii2
+ then:
+ properties:
+ groups:
+ enum: [rgmii2]
+
+ - if:
+ properties:
+ function:
+ const: sdhci
+ then:
+ properties:
+ groups:
+ enum: [sdhci]
+
+ - if:
+ properties:
+ function:
+ const: spdif2
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: spdif3
+ then:
+ properties:
+ groups:
+ enum: [uart3]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uart1
+ then:
+ properties:
+ groups:
+ enum: [uart1]
+
+ - if:
+ properties:
+ function:
+ const: uart2
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: uart3
+ then:
+ properties:
+ groups:
+ enum: [uart3]
+
+ - if:
+ properties:
+ function:
+ const: wdt refclk
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wdt rst
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "ralink,mt7621-pinctrl";
+
+ i2c_pins: i2c0-pins {
+ pinmux {
+ groups = "i2c";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index 78a0175cecc7..6b925c5099cc 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -4,12 +4,12 @@
$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT7622 Pin Controller Device Tree Bindings
+title: MediaTek MT7622 Pin Controller
maintainers:
- Sean Wang <sean.wang@kernel.org>
-description: |+
+description:
The MediaTek's MT7622 Pin controller is used to control SoC pins.
properties:
@@ -19,20 +19,24 @@ properties:
- mediatek,mt7629-pinctrl
reg:
- maxItems: 1
+ maxItems: 2
reg-names:
items:
+ - const: base
- const: eint
gpio-controller: true
"#gpio-cells":
const: 2
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+
+ gpio-ranges:
+ maxItems: 1
interrupt-controller: true
@@ -43,7 +47,7 @@ properties:
const: 2
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -61,25 +65,25 @@ then:
- "#interrupt-cells"
patternProperties:
- '-[0-9]+$':
+ '-pins(-[a-z]+)?$':
type: object
additionalProperties: false
patternProperties:
- 'mux':
+ '^mux(-|$)':
type: object
additionalProperties: false
- description: |
+ description:
pinmux configuration nodes.
- $ref: "/schemas/pinctrl/pinmux-node.yaml"
+ $ref: /schemas/pinctrl/pinmux-node.yaml
properties:
function:
- description: |
+ description:
A string containing the name of the function to mux to the group.
- enum: [emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm, sd,
- spi, tdm, uart, watchdog, wifi]
+ enum: [antsel, emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm,
+ sd, spi, tdm, uart, watchdog, wifi]
groups:
- description: |
+ description:
An array of strings. Each string contains the name of a group.
drive-strength:
@@ -93,11 +97,26 @@ patternProperties:
- if:
properties:
function:
+ const: antsel
+ then:
+ properties:
+ groups:
+ items:
+ enum: [antsel0, antsel1, antsel2, antsel3, antsel4, antsel5,
+ antsel6, antsel7, antsel8, antsel9, antsel10,
+ antsel11, antsel12, antsel13, antsel14, antsel15,
+ antsel16, antsel17, antsel18, antsel19, antsel20,
+ antsel21, antsel22, antsel23, antsel24, antsel25,
+ antsel26, antsel27, antsel28, antsel29]
+ - if:
+ properties:
+ function:
const: emmc
then:
properties:
groups:
- enum: [emmc, emmc_rst]
+ items:
+ enum: [emmc, emmc_rst]
- if:
properties:
function:
@@ -105,8 +124,9 @@ patternProperties:
then:
properties:
groups:
- enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw,
- rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio]
+ items:
+ enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw,
+ rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio]
- if:
properties:
function:
@@ -123,10 +143,11 @@ patternProperties:
then:
properties:
groups:
- enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data,
- i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws,
- i2s1_out_data, i2s2_out_data, i2s3_out_data,
- i2s4_out_data]
+ items:
+ enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data,
+ i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws,
+ i2s1_out_data, i2s2_out_data, i2s3_out_data,
+ i2s4_out_data]
- if:
properties:
function:
@@ -159,10 +180,11 @@ patternProperties:
then:
properties:
groups:
- enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken,
- pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq,
- pcie0_pad_perst, pcie1_pad_perst, pcie_pereset,
- pcie_wake, pcie_clkreq]
+ items:
+ enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken,
+ pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq,
+ pcie0_pad_perst, pcie1_pad_perst, pcie_pereset,
+ pcie_wake, pcie_clkreq]
- if:
properties:
function:
@@ -178,11 +200,12 @@ patternProperties:
then:
properties:
groups:
- enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1,
- pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0,
- pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1,
- pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3,
- pwm_ch7_0, pwm_0, pwm_1]
+ items:
+ enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1,
+ pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0,
+ pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1,
+ pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3,
+ pwm_ch7_0, pwm_ch7_2, pwm_0, pwm_1]
- if:
properties:
function:
@@ -244,49 +267,50 @@ patternProperties:
groups:
enum: [wf0_2g, wf0_5g]
- 'conf':
+ '^conf(-|$)':
type: object
additionalProperties: false
- description: |
+ description:
pinconf configuration nodes.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: /schemas/pinctrl/pincfg-node.yaml
properties:
groups:
- description: |
+ description:
An array of strings. Each string contains the name of a group.
Valid values are the same as the pinmux node.
pins:
- description: |
+ description:
An array of strings. Each string contains the name of a pin.
- enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0,
- RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS,
- I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT,
- I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1,
- G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2,
- G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6,
- NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0,
- MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1,
- MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2,
- MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3,
- MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL,
- PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS,
- GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N,
- PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2,
- AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4,
- PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA,
- WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4,
- WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG,
- EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS,
- EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N,
- WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD,
- UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD,
- UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N,
- PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5,
- GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK,
- TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3,
- WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6]
+ items:
+ enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0,
+ RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS,
+ I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT,
+ I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1,
+ G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2,
+ G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6,
+ NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0,
+ MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1,
+ MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2,
+ MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3,
+ MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL,
+ PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS,
+ GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N,
+ PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2,
+ AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4,
+ PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA,
+ WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4,
+ WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG,
+ EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS,
+ EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N,
+ WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD,
+ UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD,
+ UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N,
+ PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5,
+ GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK,
+ TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3,
+ WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6]
bias-disable: true
@@ -315,14 +339,14 @@ patternProperties:
enum: [0, 1]
mediatek,tdsel:
- description: |
+ description:
An integer describing the steps for output level shifter duty
cycle when asserted (high pulse width adjustment). Valid arguments
are from 0 to 15.
$ref: /schemas/types.yaml#/definitions/uint32
mediatek,rdsel:
- description: |
+ description:
An integer describing the steps for input level shifter duty cycle
when asserted (high pulse width adjustment). Valid arguments are
from 0 to 63.
@@ -343,34 +367,35 @@ examples:
#size-cells = <2>;
pio: pinctrl@10211000 {
- compatible = "mediatek,mt7622-pinctrl";
- reg = <0 0x10211000 0 0x1000>;
- gpio-controller;
- #gpio-cells = <2>;
-
- pinctrl_eth_default: eth-0 {
- mux-mdio {
- groups = "mdc_mdio";
- function = "eth";
- drive-strength = <12>;
- };
-
- mux-gmac2 {
- groups = "rgmii_via_gmac2";
- function = "eth";
- drive-strength = <12>;
- };
-
- mux-esw {
- groups = "esw";
- function = "eth";
- drive-strength = <8>;
- };
-
- conf-mdio {
- pins = "MDC";
- bias-pull-up;
+ compatible = "mediatek,mt7622-pinctrl";
+ reg = <0 0x10211000 0 0x1000>,
+ <0 0x10005000 0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ pinctrl_eth_default: eth-pins {
+ mux-mdio {
+ groups = "mdc_mdio";
+ function = "eth";
+ drive-strength = <12>;
+ };
+
+ mux-gmac2 {
+ groups = "rgmii_via_gmac2";
+ function = "eth";
+ drive-strength = <12>;
+ };
+
+ mux-esw {
+ groups = "esw";
+ function = "eth";
+ drive-strength = <8>;
+ };
+
+ conf-mdio {
+ pins = "MDC";
+ bias-pull-up;
+ };
};
- };
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt76x8-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt76x8-pinctrl.yaml
new file mode 100644
index 000000000000..31849dd5940b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt76x8-pinctrl.yaml
@@ -0,0 +1,450 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt76x8-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT76X8 Pin Controller
+
+maintainers:
+ - Arınç ÜNAL <arinc.unal@arinc9.com>
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ MediaTek MT76X8 pin controller for MT7628 and MT7688 SoCs.
+ The pin controller can only set the muxing of pin groups. Muxing individual
+ pins is not supported. There is no pinconf support.
+
+properties:
+ compatible:
+ const: ralink,mt76x8-pinctrl
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^(.*-)?pinmux$':
+ type: object
+ description: node for pinctrl.
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [antenna, debug, gpio, i2c, i2s, jtag, p0led_an, p0led_kn,
+ p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn,
+ p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1,
+ pwm_uart2, refclk, rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7,
+ spi, spi cs1, spis, sw_r, uart0, uart1, uart2, utif, wdt,
+ wled_an, wled_kn, -]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
+ required:
+ - groups
+ - function
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: antenna
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+
+ - if:
+ properties:
+ function:
+ const: debug
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [gpio, i2c, i2s, p0led_an, p0led_kn, p1led_an, p1led_kn,
+ p2led_an, p2led_kn, p3led_an, p3led_kn, p4led_an,
+ p4led_kn, perst, pwm0, pwm1, refclk, sdmode, spi,
+ spi cs1, spis, uart0, uart1, uart2, wdt, wled_an,
+ wled_kn]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [p0led_an, p0led_kn, p1led_an, p1led_kn, p2led_an,
+ p2led_kn, p3led_an, p3led_kn, p4led_an, p4led_kn,
+ sdmode]
+
+ - if:
+ properties:
+ function:
+ const: p0led_an
+ then:
+ properties:
+ groups:
+ enum: [p0led_an]
+
+ - if:
+ properties:
+ function:
+ const: p0led_kn
+ then:
+ properties:
+ groups:
+ enum: [p0led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p1led_an
+ then:
+ properties:
+ groups:
+ enum: [p1led_an]
+
+ - if:
+ properties:
+ function:
+ const: p1led_kn
+ then:
+ properties:
+ groups:
+ enum: [p1led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p2led_an
+ then:
+ properties:
+ groups:
+ enum: [p2led_an]
+
+ - if:
+ properties:
+ function:
+ const: p2led_kn
+ then:
+ properties:
+ groups:
+ enum: [p2led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p3led_an
+ then:
+ properties:
+ groups:
+ enum: [p3led_an]
+
+ - if:
+ properties:
+ function:
+ const: p3led_kn
+ then:
+ properties:
+ groups:
+ enum: [p3led_kn]
+
+ - if:
+ properties:
+ function:
+ const: p4led_an
+ then:
+ properties:
+ groups:
+ enum: [p4led_an]
+
+ - if:
+ properties:
+ function:
+ const: p4led_kn
+ then:
+ properties:
+ groups:
+ enum: [p4led_kn]
+
+ - if:
+ properties:
+ function:
+ const: pcie
+ then:
+ properties:
+ groups:
+ enum: [gpio]
+
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [i2s]
+
+ - if:
+ properties:
+ function:
+ const: perst
+ then:
+ properties:
+ groups:
+ enum: [perst]
+
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ enum: [uart1, uart2]
+
+ - if:
+ properties:
+ function:
+ const: pwm0
+ then:
+ properties:
+ groups:
+ enum: [pwm0]
+
+ - if:
+ properties:
+ function:
+ const: pwm1
+ then:
+ properties:
+ groups:
+ enum: [pwm1]
+
+ - if:
+ properties:
+ function:
+ const: pwm_uart2
+ then:
+ properties:
+ groups:
+ enum: [spis]
+
+ - if:
+ properties:
+ function:
+ const: refclk
+ then:
+ properties:
+ groups:
+ enum: [gpio, refclk, spi cs1]
+
+ - if:
+ properties:
+ function:
+ const: rsvd
+ then:
+ properties:
+ groups:
+ enum: [p0led_an, p0led_kn, wled_an, wled_kn]
+
+ - if:
+ properties:
+ function:
+ const: sdxc
+ then:
+ properties:
+ groups:
+ enum: [sdmode]
+
+ - if:
+ properties:
+ function:
+ const: sdxc d5 d4
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: sdxc d6
+ then:
+ properties:
+ groups:
+ enum: [pwm1]
+
+ - if:
+ properties:
+ function:
+ const: sdxc d7
+ then:
+ properties:
+ groups:
+ enum: [pwm0]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: spi cs1
+ then:
+ properties:
+ groups:
+ enum: [spi cs1]
+
+ - if:
+ properties:
+ function:
+ const: spis
+ then:
+ properties:
+ groups:
+ enum: [spis]
+
+ - if:
+ properties:
+ function:
+ const: sw_r
+ then:
+ properties:
+ groups:
+ enum: [uart1]
+
+ - if:
+ properties:
+ function:
+ const: uart0
+ then:
+ properties:
+ groups:
+ enum: [uart0]
+
+ - if:
+ properties:
+ function:
+ const: uart1
+ then:
+ properties:
+ groups:
+ enum: [uart1]
+
+ - if:
+ properties:
+ function:
+ const: uart2
+ then:
+ properties:
+ groups:
+ enum: [uart2]
+
+ - if:
+ properties:
+ function:
+ const: utif
+ then:
+ properties:
+ groups:
+ enum: [p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an,
+ p3led_kn, p4led_an, p4led_kn, pwm0, pwm1, sdmode, spis]
+
+ - if:
+ properties:
+ function:
+ const: wdt
+ then:
+ properties:
+ groups:
+ enum: [wdt]
+
+ - if:
+ properties:
+ function:
+ const: wled_an
+ then:
+ properties:
+ groups:
+ enum: [wled_an]
+
+ - if:
+ properties:
+ function:
+ const: wled_kn
+ then:
+ properties:
+ groups:
+ enum: [wled_kn]
+
+ - if:
+ properties:
+ function:
+ const: "-"
+ then:
+ properties:
+ groups:
+ enum: [i2c, spi cs1, uart0]
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "ralink,mt76x8-pinctrl";
+
+ i2c_pins: i2c0-pins {
+ pinmux {
+ groups = "i2c";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
new file mode 100644
index 000000000000..74d52a741f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml
@@ -0,0 +1,480 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7981-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7981 Pin Controller
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ The MediaTek's MT7981 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7981-pinctrl
+
+ reg:
+ minItems: 9
+ maxItems: 9
+
+ reg-names:
+ items:
+ - const: gpio
+ - const: iocfg_rt
+ - const: iocfg_rm
+ - const: iocfg_rb
+ - const: iocfg_lb
+ - const: iocfg_bl
+ - const: iocfg_tm
+ - const: iocfg_tl
+ - const: eint
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+
+ gpio-ranges:
+ minItems: 1
+ maxItems: 5
+ description: GPIO valid number range.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - "#gpio-cells"
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^.*mux.*$':
+ type: object
+ additionalProperties: false
+ description: |
+ pinmux configuration nodes.
+
+ The following table shows the effective values of "group", "function"
+ properties and chip pinout pins
+
+ groups function pins (in pin#)
+ ---------------------------------------------------------------------
+ "wa_aice1" "wa_aice" 0, 1
+ "wa_aice2" "wa_aice" 0, 1
+ "wm_uart_0" "uart" 0, 1
+ "dfd" "dfd" 0, 1, 4, 5
+ "watchdog" "watchdog" 2
+ "pcie_pereset" "pcie" 3
+ "jtag" "jtag" 4, 5, 6, 7, 8
+ "wm_jtag_0" "jtag" 4, 5, 6, 7, 8
+ "wo0_jtag_0" "jtag" 9, 10, 11, 12, 13
+ "uart2_0" "uart" 4, 5, 6, 7
+ "gbe_led0" "led" 8
+ "pta_ext_0" "pta" 4, 5, 6
+ "pwm2" "pwm" 7
+ "net_wo0_uart_txd_0" "uart" 8
+ "spi1_0" "spi" 4, 5, 6, 7
+ "i2c0_0" "i2c" 6, 7
+ "dfd_ntrst" "dfd" 8
+ "wm_aice1" "wa_aice" 9, 10
+ "pwm0_0" "pwm" 13
+ "pwm0_1" "pwm" 15
+ "pwm1_0" "pwm" 14
+ "pwm1_1" "pwm" 15
+ "net_wo0_uart_txd_1" "uart" 14
+ "net_wo0_uart_txd_2" "uart" 15
+ "gbe_led1" "led" 13
+ "pcm" "pcm" 9, 10, 11, 12, 13, 25
+ "watchdog1" "watchdog" 13
+ "udi" "udi" 9, 10, 11, 12, 13
+ "drv_vbus" "usb" 14
+ "emmc_45" "flash" 15, 16, 17, 18, 19, 20, 21, 22, 23,
+ 24, 25
+
+ "snfi" "flash" 16, 17, 18, 19, 20, 21
+ "spi0" "spi" 16, 17, 18, 19
+ "spi0_wp_hold" "spi" 20, 21
+ "spi1_1" "spi" 22, 23, 24, 25
+ "spi2" "spi" 26, 27, 28, 29
+ "spi2_wp_hold" "spi" 30, 31
+ "uart1_0" "uart" 16, 17, 18, 19
+ "uart1_1" "uart" 26, 27, 28, 29
+ "uart2_1" "uart" 22, 23, 24, 25
+ "pta_ext_1" "pta" 22, 23, 24
+ "wm_aurt_1" "uart" 20, 21
+ "wm_aurt_2" "uart" 30, 31
+ "wm_jtag_1" "jtag" 20, 21, 22, 23, 24
+ "wo0_jtag_1" "jtag" 25, 26, 27, 28, 29
+ "wa_aice3" "wa_aice" 28, 20
+ "wm_aice2" "wa_aice" 30, 31
+ "i2c0_1" "i2c" 30, 31
+ "u2_phy_i2c" "i2c" 30, 31
+ "uart0" "uart" 32, 33
+ "sgmii1_phy_i2c" "i2c" 32, 33
+ "u3_phy_i2c" "i2c" 32, 33
+ "sgmii0_phy_i2c" "i2c" 32, 33
+ "pcie_clk" "pcie" 34
+ "pcie_wake" "pcie" 35
+ "i2c0_2" "i2c" 36, 37
+ "smi_mdc_mdio" "eth" 36, 37
+ "gbe_ext_mdc_mdio" "eth" 36, 37
+ "wf0_mode1" "eth" 40, 41, 42, 43, 44, 45, 46, 47, 48,
+ 49, 50, 51, 52, 53, 54, 55, 56
+
+ "wf0_mode3" "eth" 45, 46, 47, 48, 49, 51
+ "wf2g_led0" "led" 30
+ "wf2g_led1" "led" 34
+ "wf5g_led0" "led" 31
+ "wf5g_led1" "led" 35
+ "mt7531_int" "eth" 38
+ "ant_sel" "ant" 14, 15, 16, 17, 18, 19, 20, 21, 22,
+ 23, 24, 25, 34, 35
+
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [wa_aice, dfd, jtag, pta, pcm, udi, usb, ant, eth, i2c, led,
+ pwm, spi, uart, watchdog, flash, pcie]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+
+ required:
+ - function
+ - groups
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: wa_aice
+ then:
+ properties:
+ groups:
+ enum: [wa_aice1, wa_aice2, wm_aice1_1, wa_aice3, wm_aice1_2]
+ - if:
+ properties:
+ function:
+ const: dfd
+ then:
+ properties:
+ groups:
+ enum: [dfd, dfd_ntrst]
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag, wm_jtag_0, wo0_jtag_0, wo0_jtag_1, wm_jtag_1]
+ - if:
+ properties:
+ function:
+ const: pta
+ then:
+ properties:
+ groups:
+ enum: [pta_ext_0, pta_ext_1]
+ - if:
+ properties:
+ function:
+ const: pcm
+ then:
+ properties:
+ groups:
+ enum: [pcm]
+ - if:
+ properties:
+ function:
+ const: udi
+ then:
+ properties:
+ groups:
+ enum: [udi]
+ - if:
+ properties:
+ function:
+ const: usb
+ then:
+ properties:
+ groups:
+ enum: [drv_vbus]
+ - if:
+ properties:
+ function:
+ const: ant
+ then:
+ properties:
+ groups:
+ enum: [ant_sel]
+ - if:
+ properties:
+ function:
+ const: eth
+ then:
+ properties:
+ groups:
+ enum: [smi_mdc_mdio, gbe_ext_mdc_mdio, wf0_mode1, wf0_mode3,
+ mt7531_int]
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c0_0, i2c0_1, u2_phy_i2c, sgmii1_phy_i2c, u3_phy_i2c,
+ sgmii0_phy_i2c, i2c0_2]
+ - if:
+ properties:
+ function:
+ const: led
+ then:
+ properties:
+ groups:
+ enum: [gbe_led0, gbe_led1, wf2g_led0, wf2g_led1, wf5g_led0,
+ wf5g_led1]
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pwm2, pwm0_0, pwm0_1, pwm1_0, pwm1_1]
+ maxItems: 3
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [spi1_0, spi0, spi0_wp_hold, spi1_1, spi2,
+ spi2_wp_hold]
+ maxItems: 4
+ - if:
+ properties:
+ function:
+ const: uart
+ then:
+ properties:
+ groups:
+ items:
+ enum: [wm_uart_0, uart2_0, net_wo0_uart_txd_0,
+ net_wo0_uart_txd_1, net_wo0_uart_txd_2, uart1_0,
+ uart1_1, uart2_1, wm_aurt_1, wm_aurt_2, uart0]
+ - if:
+ properties:
+ function:
+ const: watchdog
+ then:
+ properties:
+ groups:
+ enum: [watchdog]
+ - if:
+ properties:
+ function:
+ const: flash
+ then:
+ properties:
+ groups:
+ items:
+ enum: [emmc_45, snfi]
+ maxItems: 1
+ - if:
+ properties:
+ function:
+ const: pcie
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pcie_clk, pcie_wake, pcie_pereset]
+ maxItems: 3
+
+ '^.*conf.*$':
+ type: object
+ additionalProperties: false
+ description: pinconf configuration nodes.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ An array of strings. Each string contains the name of a pin.
+ items:
+ enum: [GPIO_WPS, GPIO_RESET, SYS_WATCHDOG, PCIE_PERESET_N,
+ JTAG_JTDO, JTAG_JTDI, JTAG_JTMS, JTAG_JTCLK, JTAG_JTRST_N,
+ WO_JTAG_JTDO, WO_JTAG_JTDI, WO_JTAG_JTMS, WO_JTAG_JTCLK,
+ WO_JTAG_JTRST_N, USB_VBUS, PWM0, SPI0_CLK, SPI0_MOSI,
+ SPI0_MISO, SPI0_CS, SPI0_HOLD, SPI0_WP, SPI1_CLK,
+ SPI1_MOSI, SPI1_MISO, SPI1_CS, SPI2_CLK, SPI2_MOSI,
+ SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP, UART0_RXD,
+ UART0_TXD, PCIE_CLK_REQ, PCIE_WAKE_N, SMI_MDC, SMI_MDIO,
+ GBE_INT, GBE_RESET, WF_DIG_RESETB, WF_CBA_RESETB,
+ WF_XO_REQ, WF_TOP_CLK, WF_TOP_DATA, WF_HB1, WF_HB2, WF_HB3,
+ WF_HB4, WF_HB0, WF_HB0_B, WF_HB5, WF_HB6, WF_HB7, WF_HB8,
+ WF_HB9, WF_HB10]
+ maxItems: 57
+
+ bias-disable: true
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ description: normal pull up.
+ - enum: [100, 101, 102, 103]
+ description:
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ description: normal pull down.
+ - enum: [100, 101, 102, 103]
+ description:
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ input-enable: true
+
+ input-disable: true
+
+ output-enable: true
+
+ output-low: true
+
+ output-high: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ mediatek,pull-up-adv:
+ description: |
+ Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
+ Pull up settings for 2 pull resistors, R0 and R1. Valid arguments
+ are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ description: |
+ Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
+ Pull down settings for 2 pull resistors, R0 and R1. Valid arguments
+ are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ required:
+ - pins
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt65xx.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pio: pinctrl@11d00000 {
+ compatible = "mediatek,mt7981-pinctrl";
+ reg = <0 0x11d00000 0 0x1000>,
+ <0 0x11c00000 0 0x1000>,
+ <0 0x11c10000 0 0x1000>,
+ <0 0x11d20000 0 0x1000>,
+ <0 0x11e00000 0 0x1000>,
+ <0 0x11e20000 0 0x1000>,
+ <0 0x11f00000 0 0x1000>,
+ <0 0x11f10000 0 0x1000>,
+ <0 0x1000b000 0 0x1000>;
+ reg-names = "gpio", "iocfg_rt", "iocfg_rm",
+ "iocfg_rb", "iocfg_lb", "iocfg_bl",
+ "iocfg_tm", "iocfg_tl", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 56>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ #interrupt-cells = <2>;
+
+ mdio_pins: mdio-pins {
+ mux {
+ function = "eth";
+ groups = "smi_mdc_mdio";
+ };
+ };
+
+ spi0_flash_pins: spi0-pins {
+ mux {
+ function = "spi";
+ groups = "spi0", "spi0_wp_hold";
+ };
+
+ conf-pu {
+ pins = "SPI0_CS", "SPI0_HOLD", "SPI0_WP";
+ drive-strength = <MTK_DRIVE_8mA>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_11>;
+ };
+
+ conf-pd {
+ pins = "SPI0_CLK", "SPI0_MOSI", "SPI0_MISO";
+ drive-strength = <MTK_DRIVE_8mA>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_11>;
+ };
+ };
+
+ pcie_pins: pcie-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_clk", "pcie_wake", "pcie_pereset";
+ };
+ };
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml
index 4eadea55df10..5ad65135fe1c 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml
@@ -4,12 +4,12 @@
$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7986-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT7986 Pin Controller Device Tree Bindings
+title: MediaTek MT7986 Pin Controller
maintainers:
- Sean Wang <sean.wang@kernel.org>
-description: |+
+description:
The MediaTek's MT7986 Pin controller is used to control SoC pins.
properties:
@@ -37,15 +37,15 @@ properties:
"#gpio-cells":
const: 2
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
gpio-ranges:
minItems: 1
maxItems: 5
- description: |
+ description:
GPIO valid number range.
interrupt-controller: true
@@ -57,7 +57,7 @@ properties:
const: 2
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -72,7 +72,7 @@ patternProperties:
additionalProperties: false
patternProperties:
- '.*mux.*':
+ '^.*mux.*$':
type: object
additionalProperties: false
description: |
@@ -81,12 +81,14 @@ patternProperties:
The following table shows the effective values of "group", "function"
properties and chip pinout pins
- groups function pins (in pin#)
+ groups function pins (in pin#)
---------------------------------------------------------------------
"watchdog" "watchdog" 0
"wifi_led" "led" 1, 2
"i2c" "i2c" 3, 4
"uart1_0" "uart" 7, 8, 9, 10
+ "uart1_rx_tx" "uart" 42, 43
+ "uart1_cts_rts" "uart" 44, 45
"pcie_clk" "pcie" 9
"pcie_wake" "pcie" 10
"spi1_0" "spi" 11, 12, 13, 14
@@ -95,12 +97,15 @@ patternProperties:
"pwm1_0" "pwm" 22,
"snfi" "flash" 23, 24, 25, 26, 27, 28
"spi1_2" "spi" 29, 30, 31, 32
- "emmc_45" "emmc" 22, 23, 24, 25, 26, 27, 28, 29, 30,
- 31, 32
+ "emmc_45" "emmc" 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 32
+
"spi1_1" "spi" 23, 24, 25, 26
- "uart1_2" "uart" 29, 30, 31, 32
+ "uart1_2_rx_tx" "uart" 29, 30
+ "uart1_2_cts_rts" "uart" 31, 32
"uart1_1" "uart" 23, 24, 25, 26
- "uart2_0" "uart" 29, 30, 31, 32
+ "uart2_0_rx_tx" "uart" 29, 30
+ "uart2_0_cts_rts" "uart" 31, 32
"spi0" "spi" 33, 34, 35, 36
"spi0_wp_hold" "spi" 37, 38
"uart1_3_rx_tx" "uart" 35, 36
@@ -111,28 +116,32 @@ patternProperties:
"pcie_pereset" "pcie" 41
"uart1" "uart" 42, 43, 44, 45
"uart2" "uart" 46, 47, 48, 49
- "emmc_51" "emmc" 50, 51, 52, 53, 54, 55, 56, 57, 57,
- 59, 60, 61
+ "emmc_51" "emmc" 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61
+
"pcm" "audio" 62, 63, 64, 65
"i2s" "audio" 62, 63, 64, 65
"switch_int" "eth" 66
"mdc_mdio" "eth" 67
+ "wf_2g" "wifi" 74, 75, 76, 77, 78, 79, 80, 81, 82, 83
+ "wf_5g" "wifi" 91, 92, 93, 94, 95, 96, 97, 98, 99, 100
+ "wf_dbdc" "wifi" 74, 75, 76, 77, 78, 79, 80, 81, 82, 83,
+ 84, 85
- $ref: "/schemas/pinctrl/pinmux-node.yaml"
+ $ref: /schemas/pinctrl/pinmux-node.yaml
properties:
function:
- description: |
+ description:
A string containing the name of the function to mux to the group.
There is no "audio", "pcie" functions on mt7986b, you can only use
those functions on mt7986a.
enum: [audio, emmc, eth, i2c, led, flash, pcie, pwm, spi, uart,
watchdog, wifi]
groups:
- description: |
+ description:
An array of strings. Each string contains the name of a group.
- There is no "pcie_pereset", "uart1", "uart2" "emmc_51", "pcm",
- and "i2s" groups on mt7986b, you can only use those groups on
- mt7986a.
+ There is no "pcie_pereset", "uart1", "uart2" "emmc_51", "pcm", and
+ "i2s" groups on mt7986b, you can only use those groups on mt7986a.
required:
- function
- groups
@@ -153,7 +162,7 @@ patternProperties:
then:
properties:
groups:
- enum: [emmc, emmc_rst]
+ enum: [emmc_45, emmc_51]
- if:
properties:
function:
@@ -193,7 +202,9 @@ patternProperties:
then:
properties:
groups:
- enum: [pcie_clk, pcie_wake, pcie_pereset]
+ items:
+ enum: [pcie_clk, pcie_wake, pcie_pereset]
+ maxItems: 3
- if:
properties:
function:
@@ -201,7 +212,9 @@ patternProperties:
then:
properties:
groups:
- enum: [pwm0, pwm1_0, pwm1_1]
+ items:
+ enum: [pwm0, pwm1_0, pwm1_1]
+ maxItems: 2
- if:
properties:
function:
@@ -209,7 +222,9 @@ patternProperties:
then:
properties:
groups:
- enum: [spi0, spi0_wp_hold, spi1_0, spi1_1, spi1_2, spi1_3]
+ items:
+ enum: [spi0, spi0_wp_hold, spi1_0, spi1_1, spi1_2, spi1_3]
+ maxItems: 2
- if:
properties:
function:
@@ -217,8 +232,12 @@ patternProperties:
then:
properties:
groups:
- enum: [uart1_0, uart1_1, uart1_2, uart1_3_rx_tx,
- uart1_3_cts_rts, uart2_0, uart2_1, uart0, uart1, uart2]
+ items:
+ enum: [uart1_0, uart1_rx_tx, uart1_cts_rts, uart1_1,
+ uart1_2_rx_tx, uart1_2_cts_rts, uart1_3_rx_tx,
+ uart1_3_cts_rts, uart2_0_rx_tx, uart2_0_cts_rts,
+ uart2_1, uart0, uart1, uart2]
+ maxItems: 2
- if:
properties:
function:
@@ -234,45 +253,64 @@ patternProperties:
then:
properties:
groups:
- enum: [wf_2g, wf_5g, wf_dbdc]
- '.*conf.*':
+ items:
+ enum: [wf_2g, wf_5g, wf_dbdc]
+ maxItems: 3
+ '^.*conf.*$':
type: object
additionalProperties: false
- description: |
+ description:
pinconf configuration nodes.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: /schemas/pinctrl/pincfg-node.yaml
properties:
pins:
- description: |
- An array of strings. Each string contains the name of a pin.
- There is no PIN 41 to PIN 65 above on mt7686b, you can only use
- those pins on mt7986a.
- enum: [SYS_WATCHDOG, WF2G_LED, WF5G_LED, I2C_SCL, I2C_SDA, GPIO_0,
- GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5, GPIO_6, GPIO_7,
- GPIO_8, GPIO_9, GPIO_10, GPIO_11, GPIO_12, GPIO_13, GPIO_14,
- GPIO_15, PWM0, PWM1, SPI0_CLK, SPI0_MOSI, SPI0_MISO, SPI0_CS,
- SPI0_HOLD, SPI0_WP, SPI1_CLK, SPI1_MOSI, SPI1_MISO, SPI1_CS,
- SPI2_CLK, SPI2_MOSI, SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP,
- UART0_RXD, UART0_TXD, PCIE_PERESET_N, UART1_RXD, UART1_TXD,
- UART1_CTS, UART1_RTS, UART2_RXD, UART2_TXD, UART2_CTS,
- UART2_RTS, EMMC_DATA_0, EMMC_DATA_1, EMMC_DATA_2,
- EMMC_DATA_3, EMMC_DATA_4, EMMC_DATA_5, EMMC_DATA_6,
- EMMC_DATA_7, EMMC_CMD, EMMC_CK, EMMC_DSL, EMMC_RSTB, PCM_DTX,
- PCM_DRX, PCM_CLK, PCM_FS, MT7531_INT, SMI_MDC, SMI_MDIO,
- WF0_DIG_RESETB, WF0_CBA_RESETB, WF0_XO_REQ, WF0_TOP_CLK,
- WF0_TOP_DATA, WF0_HB1, WF0_HB2, WF0_HB3, WF0_HB4, WF0_HB0,
- WF0_HB0_B, WF0_HB5, WF0_HB6, WF0_HB7, WF0_HB8, WF0_HB9,
- WF0_HB10, WF1_DIG_RESETB, WF1_CBA_RESETB, WF1_XO_REQ,
- WF1_TOP_CLK, WF1_TOP_DATA, WF1_HB1, WF1_HB2, WF1_HB3,
- WF1_HB4, WF1_HB0, WF1_HB0_B, WF1_HB5, WF1_HB6, WF1_HB7,
- WF1_HB8]
+ description:
+ An array of strings. Each string contains the name of a pin. There
+ is no PIN 41 to PIN 65 above on mt7686b, you can only use those
+ pins on mt7986a.
+ items:
+ enum: [SYS_WATCHDOG, WF2G_LED, WF5G_LED, I2C_SCL, I2C_SDA, GPIO_0,
+ GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5, GPIO_6, GPIO_7,
+ GPIO_8, GPIO_9, GPIO_10, GPIO_11, GPIO_12, GPIO_13,
+ GPIO_14, GPIO_15, PWM0, PWM1, SPI0_CLK, SPI0_MOSI,
+ SPI0_MISO, SPI0_CS, SPI0_HOLD, SPI0_WP, SPI1_CLK,
+ SPI1_MOSI, SPI1_MISO, SPI1_CS, SPI2_CLK, SPI2_MOSI,
+ SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP, UART0_RXD,
+ UART0_TXD, PCIE_PERESET_N, UART1_RXD, UART1_TXD, UART1_CTS,
+ UART1_RTS, UART2_RXD, UART2_TXD, UART2_CTS, UART2_RTS,
+ EMMC_DATA_0, EMMC_DATA_1, EMMC_DATA_2, EMMC_DATA_3,
+ EMMC_DATA_4, EMMC_DATA_5, EMMC_DATA_6, EMMC_DATA_7,
+ EMMC_CMD, EMMC_CK, EMMC_DSL, EMMC_RSTB, PCM_DTX, PCM_DRX,
+ PCM_CLK, PCM_FS, MT7531_INT, SMI_MDC, SMI_MDIO,
+ WF0_DIG_RESETB, WF0_CBA_RESETB, WF0_XO_REQ, WF0_TOP_CLK,
+ WF0_TOP_DATA, WF0_HB1, WF0_HB2, WF0_HB3, WF0_HB4, WF0_HB0,
+ WF0_HB0_B, WF0_HB5, WF0_HB6, WF0_HB7, WF0_HB8, WF0_HB9,
+ WF0_HB10, WF1_DIG_RESETB, WF1_CBA_RESETB, WF1_XO_REQ,
+ WF1_TOP_CLK, WF1_TOP_DATA, WF1_HB1, WF1_HB2, WF1_HB3,
+ WF1_HB4, WF1_HB0, WF1_HB0_B, WF1_HB5, WF1_HB6, WF1_HB7,
+ WF1_HB8]
+ maxItems: 101
bias-disable: true
- bias-pull-up: true
-
- bias-pull-down: true
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ description: normal pull up.
+ - enum: [100, 101, 102, 103]
+ description:
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ description: normal pull down.
+ - enum: [100, 101, 102, 103]
+ description:
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
input-enable: true
@@ -294,7 +332,7 @@ patternProperties:
mediatek,pull-up-adv:
description: |
Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
- Pull up setings for 2 pull resistors, R0 and R1. Valid arguments
+ Pull up settings for 2 pull resistors, R0 and R1. Valid arguments
are described as below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
@@ -306,7 +344,7 @@ patternProperties:
mediatek,pull-down-adv:
description: |
Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
- Pull down setings for 2 pull resistors, R0 and R1. Valid arguments
+ Pull down settings for 2 pull resistors, R0 and R1. Valid arguments
are described as below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
@@ -324,6 +362,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt65xx.h>
soc {
#address-cells = <2>;
@@ -348,6 +387,27 @@ examples:
interrupt-parent = <&gic>;
#interrupt-cells = <2>;
+ pcie_pins: pcie-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_clk", "pcie_wake", "pcie_pereset";
+ };
+ };
+
+ pwm_pins: pwm-pins {
+ mux {
+ function = "pwm";
+ groups = "pwm0", "pwm1_0";
+ };
+ };
+
+ spi0_pins: spi0-pins {
+ mux {
+ function = "spi";
+ groups = "spi0", "spi0_wp_hold";
+ };
+ };
+
uart1_pins: uart1-pins {
mux {
function = "uart";
@@ -355,6 +415,13 @@ examples:
};
};
+ uart1_3_pins: uart1-3-pins {
+ mux {
+ function = "uart";
+ groups = "uart1_3_rx_tx", "uart1_3_cts_rts";
+ };
+ };
+
uart2_pins: uart2-pins {
mux {
function = "uart";
@@ -362,5 +429,34 @@ examples:
};
};
+ mmc0_pins_default: mmc0-pins {
+ mux {
+ function = "emmc";
+ groups = "emmc_51";
+ };
+ conf-cmd-dat {
+ pins = "EMMC_DATA_0", "EMMC_DATA_1", "EMMC_DATA_2",
+ "EMMC_DATA_3", "EMMC_DATA_4", "EMMC_DATA_5",
+ "EMMC_DATA_6", "EMMC_DATA_7", "EMMC_CMD";
+ input-enable;
+ drive-strength = <4>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>; /* pull-up 10K */
+ };
+ conf-clk {
+ pins = "EMMC_CK";
+ drive-strength = <6>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>; /* pull-down 50K */
+ };
+ conf-ds {
+ pins = "EMMC_DSL";
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>; /* pull-down 50K */
+ };
+ conf-rst {
+ pins = "EMMC_RSTB";
+ drive-strength = <4>;
+ bias-pull-up = <MTK_PUPD_SET_R1R0_01>; /* pull-up 10K */
+ };
+ };
+
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml
new file mode 100644
index 000000000000..1f31b520cb43
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7988-pinctrl.yaml
@@ -0,0 +1,580 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7988-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7988 Pin Controller
+
+maintainers:
+ - Sean Wang <sean.wang@kernel.org>
+
+description:
+ The MediaTek's MT7988 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7988-pinctrl
+
+ reg:
+ minItems: 7
+ maxItems: 7
+
+ reg-names:
+ items:
+ - const: gpio
+ - const: iocfg_tr
+ - const: iocfg_br
+ - const: iocfg_rb
+ - const: iocfg_lb
+ - const: iocfg_tl
+ - const: eint
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ minItems: 1
+ maxItems: 5
+ description:
+ GPIO valid number range.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - "#gpio-cells"
+
+patternProperties:
+ "-hog(-[0-9]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ properties:
+ mux:
+ type: object
+ additionalProperties: false
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+ description: |
+ pinmux configuration nodes.
+
+ The following table shows the effective values of "group", "function"
+ properties and chip pinout pins
+
+ groups function pins (in pin#)
+ ---------------------------------------------------------------------
+ "tops_jtag0_0" "jtag" 0, 1, 2, 3, 4
+ "wo0_jtag" "jtag" 50, 51, 52, 53, 54
+ "wo1_jtag" "jtag" 50, 51, 52, 53, 54
+ "wo2_jtag" "jtag" 50, 51, 52, 53, 54
+ "jtag" "jtag" 58, 59, 60, 61, 62
+ "tops_jtag0_1" "jtag" 58, 59, 60, 61, 62
+ "int_usxgmii" "int_usxgmii" 2, 3
+ "pwm0" "pwm" 57
+ "pwm1" "pwm" 21
+ "pwm2" "pwm" 80
+ "pwm2_0" "pwm" 58
+ "pwm3" "pwm" 81
+ "pwm3_0" "pwm" 59
+ "pwm4" "pwm" 82
+ "pwm4_0" "pwm" 60
+ "pwm5" "pwm" 83
+ "pwm5_0" "pwm" 61
+ "pwm6" "pwm" 69
+ "pwm6_0" "pwm" 62
+ "pwm7" "pwm" 70
+ "pwm7_0" "pwm" 4
+ "dfd" "dfd" 0, 1, 2, 3, 4
+ "xfi_phy0_i2c0" "i2c" 0, 1
+ "xfi_phy1_i2c0" "i2c" 0, 1
+ "xfi_phy_pll_i2c0" "i2c" 3, 4
+ "xfi_phy_pll_i2c1" "i2c" 3, 4
+ "i2c0_0" "i2c" 5, 6
+ "i2c1_sfp" "i2c" 5, 6
+ "xfi_pextp_phy0_i2c" "i2c" 5, 6
+ "xfi_pextp_phy1_i2c" "i2c" 5, 6
+ "i2c0_1" "i2c" 15, 16
+ "u30_phy_i2c0" "i2c" 15, 16
+ "u32_phy_i2c0" "i2c" 15, 16
+ "xfi_phy0_i2c1" "i2c" 15, 16
+ "xfi_phy1_i2c1" "i2c" 15, 16
+ "xfi_phy_pll_i2c2" "i2c" 15, 16
+ "i2c1_0" "i2c" 17, 18
+ "u30_phy_i2c1" "i2c" 17, 18
+ "u32_phy_i2c1" "i2c" 17, 18
+ "xfi_phy_pll_i2c3" "i2c" 17, 18
+ "sgmii0_i2c" "i2c" 17, 18
+ "sgmii1_i2c" "i2c" 17, 18
+ "i2c1_2" "i2c" 69, 70
+ "i2c2_0" "i2c" 69, 70
+ "i2c2_1" "i2c" 71, 72
+ "mdc_mdio0" "eth" 5, 6
+ "2p5g_ext_mdio" "eth" 28, 29
+ "gbe_ext_mdio" "eth" 30, 31
+ "mdc_mdio1" "eth" 69, 70
+ "pcie_wake_n0_0" "pcie" 7
+ "pcie_clk_req_n0_0" "pcie" 8
+ "pcie_wake_n3_0" "pcie" 9
+ "pcie_clk_req_n3" "pcie" 10
+ "pcie_clk_req_n0_1" "pcie" 10
+ "pcie_p0_phy_i2c" "pcie" 7, 8
+ "pcie_p1_phy_i2c" "pcie" 7, 8
+ "pcie_p3_phy_i2c" "pcie" 9, 10
+ "pcie_p2_phy_i2c" "pcie" 7, 8
+ "ckm_phy_i2c" "pcie" 9, 10
+ "pcie_wake_n0_1" "pcie" 13
+ "pcie_wake_n3_1" "pcie" 14
+ "pcie_2l_0_pereset" "pcie" 19
+ "pcie_1l_1_pereset" "pcie" 20
+ "pcie_clk_req_n2_1" "pcie" 63
+ "pcie_2l_1_pereset" "pcie" 73
+ "pcie_1l_0_pereset" "pcie" 74
+ "pcie_wake_n1_0" "pcie" 75
+ "pcie_clk_req_n1" "pcie" 76
+ "pcie_wake_n2_0" "pcie" 77
+ "pcie_clk_req_n2_0" "pcie" 78
+ "pcie_wake_n2_1" "pcie" 79
+ "pmic" "pmic" 11
+ "watchdog" "watchdog" 12
+ "spi0_wp_hold" "spi" 22, 23
+ "spi0" "spi" 24, 25, 26, 27
+ "spi1" "spi" 28, 29, 30, 31
+ "spi2" "spi" 32, 33, 34, 35
+ "spi2_wp_hold" "spi" 36, 37
+ "snfi" "flash" 22, 23, 24, 25, 26, 27
+ "emmc_45" "flash" 21, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37
+ "sdcard" "flash" 32, 33, 34, 35, 36, 37
+ "emmc_51" "flash" 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49
+ "uart2" "uart" 0, 1, 2, 3
+ "tops_uart0_0" "uart" 22, 23
+ "uart2_0" "uart" 28, 29, 30, 31
+ "uart1_0" "uart" 32, 33, 34, 35
+ "uart2_1" "uart" 32, 33, 34, 35
+ "net_wo0_uart_txd_0" "uart" 28
+ "net_wo1_uart_txd_0" "uart" 29
+ "net_wo2_uart_txd_0" "uart" 30
+ "tops_uart1_0" "uart" 28, 29
+ "tops_uart0_1" "uart" 30, 31
+ "tops_uart1_1" "uart" 36, 37
+ "uart0" "uart" 55, 56
+ "tops_uart0_2" "uart" 55, 56
+ "uart2_2" "uart" 50, 51, 52, 53
+ "uart1_1" "uart" 58, 59, 60, 61
+ "uart2_3" "uart" 58, 59, 60, 61
+ "uart1_2" "uart" 80, 81, 82, 83
+ "uart1_2_lite" "uart" 80, 81
+ "tops_uart1_2" "uart" 80, 81
+ "net_wo0_uart_txd_1" "uart" 80
+ "net_wo1_uart_txd_1" "uart" 81
+ "net_wo2_uart_txd_1" "uart" 82
+ "udi" "udi" 32, 33, 34, 35, 36
+ "i2s" "audio" 50, 51, 52, 53, 54
+ "pcm" "audio" 50, 51, 52, 53
+ "gbe0_led1" "led" 58
+ "gbe1_led1" "led" 59
+ "gbe2_led1" "led" 60
+ "gbe3_led1" "led" 61
+ "2p5gbe_led1" "led" 62
+ "gbe0_led0" "led" 64
+ "gbe1_led0" "led" 65
+ "gbe2_led0" "led" 66
+ "gbe3_led0" "led" 67
+ "2p5gbe_led0" "led" 68
+ "drv_vbus_p1" "usb" 63
+ "drv_vbus" "usb" 79
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [audio, dfd, eth, flash, i2c, int_usxgmii, jtag, led, pcie, pmic, pwm, spi,
+ uart, udi, usb, watchdog]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+
+ required:
+ - function
+ - groups
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: audio
+ then:
+ properties:
+ groups:
+ enum: [i2s, pcm]
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag, tops_jtag0_0, tops_jtag0_1, wo0_jtag, wo1_jtag, wo2_jtag]
+ - if:
+ properties:
+ function:
+ const: int_usxgmii
+ then:
+ properties:
+ groups:
+ const: int_usxgmii
+ - if:
+ properties:
+ function:
+ const: dfd
+ then:
+ properties:
+ groups:
+ const: dfd
+ - if:
+ properties:
+ function:
+ const: flash
+ then:
+ properties:
+ groups:
+ enum: [emmc_45, emmc_51, sdcard, snfi]
+ - if:
+ properties:
+ function:
+ const: eth
+ then:
+ properties:
+ groups:
+ enum: [2p5g_ext_mdio, gbe_ext_mdio, mdc_mdio0, mdc_mdio1]
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [xfi_phy0_i2c0, xfi_phy1_i2c0, xfi_phy_pll_i2c0,
+ xfi_phy_pll_i2c1, i2c0_0, i2c1_sfp, xfi_pextp_phy0_i2c,
+ xfi_pextp_phy1_i2c, i2c0_1, u30_phy_i2c0, u32_phy_i2c0,
+ xfi_phy0_i2c1, xfi_phy1_i2c1, xfi_phy_pll_i2c2, i2c1_0,
+ u30_phy_i2c1, u32_phy_i2c1, xfi_phy_pll_i2c3, sgmii0_i2c,
+ sgmii1_i2c, i2c1_2, i2c2_0, i2c2_1]
+ - if:
+ properties:
+ function:
+ const: led
+ then:
+ properties:
+ groups:
+ enum: [2p5gbe_led0, 2p5gbe_led1, gbe0_led0, gbe0_led1, gbe1_led0, gbe1_led1,
+ gbe2_led0, gbe2_led1, gbe3_led0, gbe3_led1, wf5g_led0, wf5g_led1]
+ - if:
+ properties:
+ function:
+ const: pcie
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pcie_wake_n0_0, pcie_clk_req_n0_0, pcie_wake_n3_0,
+ pcie_clk_req_n3, pcie_p0_phy_i2c, pcie_p1_phy_i2c,
+ pcie_p3_phy_i2c, pcie_p2_phy_i2c, ckm_phy_i2c,
+ pcie_wake_n0_1, pcie_wake_n3_1, pcie_2l_0_pereset,
+ pcie_1l_1_pereset, pcie_clk_req_n2_1, pcie_2l_1_pereset,
+ pcie_1l_0_pereset, pcie_wake_n1_0, pcie_clk_req_n1,
+ pcie_wake_n2_0, pcie_clk_req_n2_0, pcie_wake_n2_1,
+ pcie_clk_req_n0_1]
+ maxItems: 3
+ - if:
+ properties:
+ function:
+ const: pmic
+ then:
+ properties:
+ groups:
+ const: pmic
+ - if:
+ properties:
+ function:
+ const: pwm
+ then:
+ properties:
+ groups:
+ items:
+ enum: [pwm0, pwm1, pwm2, pwm2_0, pwm3, pwm3_0, pwm4, pwm4_0, pwm5, pwm5_0,
+ pwm6, pwm6_0, pwm7, pwm7_0]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ items:
+ enum: [spi0, spi0_wp_hold, spi1, spi2, spi2_wp_hold]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: uart
+ then:
+ properties:
+ groups:
+ items:
+ enum: [net_wo0_uart_txd_0, net_wo0_uart_txd_1, net_wo1_uart_txd_0,
+ net_wo1_uart_txd_1, net_wo2_uart_txd_0, net_wo2_uart_txd_1,
+ tops_uart0_0, tops_uart0_1, tops_uart0_2, tops_uart1_0,
+ tops_uart1_1, tops_uart1_2, uart0, uart1_0, uart1_1, uart1_2,
+ uart1_2_lite, uart2, uart2_0, uart2_1, uart2_3]
+ maxItems: 2
+ - if:
+ properties:
+ function:
+ const: watchdog
+ then:
+ properties:
+ groups:
+ const: watchdog
+ - if:
+ properties:
+ function:
+ const: udi
+ then:
+ properties:
+ groups:
+ const: udi
+ - if:
+ properties:
+ function:
+ const: usb
+ then:
+ properties:
+ groups:
+ items:
+ enum: [drv_vbus, drv_vbus_p1]
+ maxItems: 1
+
+ patternProperties:
+ '^conf(-[-a-z]*)?$':
+ type: object
+ additionalProperties: false
+ description:
+ pinconf configuration nodes.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pins:
+ description:
+ An array of strings. Each string contains the name of a pin.
+ items:
+ enum: [UART2_RXD, UART2_TXD, UART2_CTS, UART2_RTS, GPIO_A, SMI_0_MDC,
+ SMI_0_MDIO, PCIE30_2L_0_WAKE_N, PCIE30_2L_0_CLKREQ_N,
+ PCIE30_1L_1_WAKE_N, PCIE30_1L_1_CLKREQ_N, GPIO_P, WATCHDOG,
+ GPIO_RESET, GPIO_WPS, PMIC_I2C_SCL, PMIC_I2C_SDA, I2C_1_SCL,
+ I2C_1_SDA, PCIE30_2L_0_PRESET_N, PCIE30_1L_1_PRESET_N, PWMD1,
+ SPI0_WP, SPI0_HOLD, SPI0_CSB, SPI0_MISO, SPI0_MOSI, SPI0_CLK,
+ SPI1_CSB, SPI1_MISO, SPI1_MOSI, SPI1_CLK, SPI2_CLK, SPI2_MOSI,
+ SPI2_MISO, SPI2_CSB, SPI2_HOLD, SPI2_WP, EMMC_RSTB, EMMC_DSL,
+ EMMC_CK, EMMC_CMD, EMMC_DATA_7, EMMC_DATA_6, EMMC_DATA_5,
+ EMMC_DATA_4, EMMC_DATA_3, EMMC_DATA_2, EMMC_DATA_1,
+ EMMC_DATA_0, PCM_FS_I2S_LRCK, PCM_CLK_I2S_BCLK,
+ PCM_DRX_I2S_DIN, PCM_DTX_I2S_DOUT, PCM_MCK_I2S_MCLK,
+ UART0_RXD, UART0_TXD, PWMD0, JTAG_JTDI, JTAG_JTDO, JTAG_JTMS,
+ JTAG_JTCLK, JTAG_JTRST_N, USB_DRV_VBUS_P1, LED_A, LED_B, LED_C,
+ LED_D, LED_E, GPIO_B, GPIO_C, I2C_2_SCL, I2C_2_SDA,
+ PCIE30_2L_1_PRESET_N, PCIE30_1L_0_PRESET_N,
+ PCIE30_2L_1_WAKE_N, PCIE30_2L_1_CLKREQ_N,
+ PCIE30_1L_0_WAKE_N, PCIE30_1L_0_CLKREQ_N, USB_DRV_VBUS_P0,
+ UART1_RXD, UART1_TXD, UART1_CTS, UART1_RTS]
+ maxItems: 84
+
+ bias-disable: true
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ description: normal pull up.
+ - enum: [100, 101, 102, 103]
+ description:
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ description: normal pull down.
+ - enum: [100, 101, 102, 103]
+ description:
+ PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in
+ dt-bindings/pinctrl/mt65xx.h.
+
+ input-enable: true
+
+ input-disable: true
+
+ output-enable: true
+
+ output-low: true
+
+ output-high: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ mediatek,pull-up-adv:
+ description: |
+ Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
+ Pull up settings for 2 pull resistors, R0 and R1. Valid arguments
+ are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ description: |
+ Valid arguments for 'mediatek,pull-up-adv' are '0', '1', '2', '3'
+ Pull down settings for 2 pull resistors, R0 and R1. Valid arguments
+ are described as below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ required:
+ - pins
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt65xx.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pio: pinctrl@1001f000 {
+ compatible = "mediatek,mt7988-pinctrl";
+ reg = <0 0x1001f000 0 0x1000>,
+ <0 0x11c10000 0 0x1000>,
+ <0 0x11d00000 0 0x1000>,
+ <0 0x11d20000 0 0x1000>,
+ <0 0x11e00000 0 0x1000>,
+ <0 0x11f00000 0 0x1000>,
+ <0 0x1000b000 0 0x1000>;
+ reg-names = "gpio", "iocfg_tr",
+ "iocfg_br", "iocfg_rb",
+ "iocfg_lb", "iocfg_tl", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 84>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ #interrupt-cells = <2>;
+
+ i2c0_pins: i2c0-g0-pins {
+ mux {
+ function = "i2c";
+ groups = "i2c0_1";
+ };
+ };
+
+ mdio0_pins: mdio0-pins {
+ mux {
+ function = "eth";
+ groups = "mdc_mdio0";
+ };
+
+ conf {
+ pins = "SMI_0_MDC", "SMI_0_MDIO";
+ drive-strength = <8>;
+ };
+ };
+
+ mmc0_pins_emmc_51: mmc0-emmc-51-pins {
+ mux {
+ function = "flash";
+ groups = "emmc_51";
+ };
+ };
+
+ mmc0_pins_sdcard: mmc0-sdcard-pins {
+ mux {
+ function = "flash";
+ groups = "sdcard";
+ };
+ };
+
+ pcie0_pins: pcie0-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_2l_0_pereset", "pcie_clk_req_n0_0",
+ "pcie_wake_n0_0";
+ };
+ };
+
+ pcie1_pins: pcie1-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_2l_1_pereset", "pcie_clk_req_n1",
+ "pcie_wake_n1_0";
+ };
+ };
+
+ pcie2_pins: pcie2-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_1l_0_pereset", "pcie_clk_req_n2_0",
+ "pcie_wake_n2_0";
+ };
+ };
+
+ pcie3_pins: pcie3-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie_1l_1_pereset", "pcie_clk_req_n3",
+ "pcie_wake_n3_0";
+ };
+ };
+
+ uart0_pins: uart0-pins {
+ mux {
+ function = "uart";
+ groups = "uart0";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
index 2d13a57b8961..3db2438fadc7 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml
@@ -4,12 +4,12 @@
$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT8183 Pin Controller Device Tree Bindings
+title: MediaTek MT8183 Pin Controller
maintainers:
- Sean Wang <sean.wang@kernel.org>
-description: |+
+description:
The MediaTek's MT8183 Pin controller is used to control SoC pins.
properties:
@@ -37,17 +37,19 @@ properties:
"#gpio-cells":
const: 2
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO
- binding is used, the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
gpio-ranges:
minItems: 1
maxItems: 5
- description: |
+ description:
GPIO valid number range.
+ gpio-line-names: true
+
interrupt-controller: true
interrupts:
@@ -57,7 +59,7 @@ properties:
const: 2
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -67,25 +69,25 @@ required:
- gpio-ranges
patternProperties:
- '-[0-9]+$':
+ '-pins(-[a-z]+)?$':
type: object
additionalProperties: false
patternProperties:
- 'pins':
+ '^pins':
type: object
additionalProperties: false
- description: |
+ description:
A pinctrl node should contain at least one subnodes representing the
pinctrl groups available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
configuration, pullups, drive strength, input enable/disable and input
schmitt.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: /schemas/pinctrl/pincfg-node.yaml
properties:
pinmux:
description:
- integer array, represents gpio pin number and mux setting.
+ Integer array, represents gpio pin number and mux setting.
Supported pin number and mux varies for different SoCs, and are
defined as macros in <soc>-pinfunc.h directly.
@@ -110,8 +112,13 @@ patternProperties:
drive-strength:
enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
mediatek,drive-strength-adv:
+ deprecated: true
description: |
+ DEPRECATED: Please use drive-strength-microamp instead.
Describe the specific driving setup property.
For I2C pins, the existing generic driving setup can only support
2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they
@@ -138,8 +145,9 @@ patternProperties:
mediatek,pull-up-adv:
description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
+ Pull up settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as
+ below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
@@ -150,7 +158,8 @@ patternProperties:
mediatek,pull-down-adv:
description: |
Pull down settings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
+ configure those special pins. Valid arguments are described as
+ below:
0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
@@ -159,14 +168,14 @@ patternProperties:
enum: [0, 1, 2, 3]
mediatek,tdsel:
- description: |
+ description:
An integer describing the steps for output level shifter duty
cycle when asserted (high pulse width adjustment). Valid arguments
are from 0 to 15.
$ref: /schemas/types.yaml#/definitions/uint32
mediatek,rdsel:
- description: |
+ description:
An integer describing the steps for input level shifter duty cycle
when asserted (high pulse width adjustment). Valid arguments are
from 0 to 63.
@@ -188,44 +197,43 @@ examples:
#size-cells = <2>;
pio: pinctrl@10005000 {
- compatible = "mediatek,mt8183-pinctrl";
- reg = <0 0x10005000 0 0x1000>,
- <0 0x11f20000 0 0x1000>,
- <0 0x11e80000 0 0x1000>,
- <0 0x11e70000 0 0x1000>,
- <0 0x11e90000 0 0x1000>,
- <0 0x11d30000 0 0x1000>,
- <0 0x11d20000 0 0x1000>,
- <0 0x11c50000 0 0x1000>,
- <0 0x11f30000 0 0x1000>,
- <0 0x1000b000 0 0x1000>;
- reg-names = "iocfg0", "iocfg1", "iocfg2",
- "iocfg3", "iocfg4", "iocfg5",
- "iocfg6", "iocfg7", "iocfg8",
- "eint";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pio 0 0 192>;
- interrupt-controller;
- interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
- #interrupt-cells = <2>;
-
- i2c0_pins_a: i2c-0 {
- pins1 {
- pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
- <PINMUX_GPIO49__FUNC_SDA5>;
- mediatek,pull-up-adv = <3>;
- mediatek,drive-strength-adv = <7>;
+ compatible = "mediatek,mt8183-pinctrl";
+ reg = <0 0x10005000 0 0x1000>,
+ <0 0x11f20000 0 0x1000>,
+ <0 0x11e80000 0 0x1000>,
+ <0 0x11e70000 0 0x1000>,
+ <0 0x11e90000 0 0x1000>,
+ <0 0x11d30000 0 0x1000>,
+ <0 0x11d20000 0 0x1000>,
+ <0 0x11c50000 0 0x1000>,
+ <0 0x11f30000 0 0x1000>,
+ <0 0x1000b000 0 0x1000>;
+ reg-names = "iocfg0", "iocfg1", "iocfg2",
+ "iocfg3", "iocfg4", "iocfg5",
+ "iocfg6", "iocfg7", "iocfg8",
+ "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 192>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+
+ i2c0_pins_a: i2c0-pins {
+ pins1 {
+ pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
+ <PINMUX_GPIO49__FUNC_SDA5>;
+ mediatek,pull-up-adv = <3>;
+ drive-strength-microamp = <1000>;
+ };
};
- };
-
- i2c1_pins_a: i2c-1 {
- pins {
- pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
- <PINMUX_GPIO51__FUNC_SDA3>;
- mediatek,pull-down-adv = <2>;
- mediatek,drive-strength-adv = <4>;
+
+ i2c1_pins_a: i2c1-pins {
+ pins {
+ pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
+ <PINMUX_GPIO51__FUNC_SDA3>;
+ mediatek,pull-down-adv = <2>;
+ };
};
- };
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8186-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8186-pinctrl.yaml
new file mode 100644
index 000000000000..69136ddd0bbc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8186-pinctrl.yaml
@@ -0,0 +1,275 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8186-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8186 Pin Controller
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+description:
+ The MediaTek's MT8186 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8186-pinctrl
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names: true
+
+ reg:
+ description:
+ Physical address base for GPIO base registers. There are 8 different GPIO
+ physical address base in mt8186.
+ maxItems: 8
+
+ reg-names:
+ description:
+ GPIO base register names.
+ items:
+ - const: iocfg0
+ - const: iocfg_lt
+ - const: iocfg_lm
+ - const: iocfg_lb
+ - const: iocfg_bl
+ - const: iocfg_rb
+ - const: iocfg_rt
+ - const: eint
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description: The interrupt outputs to sysirq
+ maxItems: 1
+
+ mediatek,rsel-resistance-in-si-unit:
+ type: boolean
+ description:
+ Identifying i2c pins pull up/down type which is RSEL. It can support RSEL
+ define or si unit value(ohm) to set different resistance.
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '^pins':
+ type: object
+ additionalProperties: false
+ description: |
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ An example of using macro:
+ pincontroller {
+ /* GPIO0 set as multifunction GPIO0 */
+ gpio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ }
+ };
+ /* GPIO128 set as multifunction SDA0 */
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
+ }
+ };
+ };
+ $ref: pinmux-node.yaml
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8186 pull down PUPD/R0/R1 type define value.
+ - enum: [200, 201, 202, 203]
+ description: mt8186 pull down RSEL type define value.
+ - enum: [75000, 5000]
+ description: mt8186 pull down RSEL type si unit value(ohm).
+ description: |
+ For pull down type is normal, it don't need add RSEL & R1R0 define
+ and resistance value.
+ For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8186.
+ For pull down type is RSEL, it can add RSEL define & resistance
+ value(ohm) to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit".
+ It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" &
+ "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" define in
+ mt8186. It can also support resistance value(ohm) "75000" & "5000"
+ in mt8186.
+ An example of using RSEL define:
+ pincontroller {
+ i2c0_pin {
+ pins {
+ pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
+ bias-pull-down = <MTK_PULL_SET_RSEL_001>;
+ }
+ };
+ };
+ An example of using si unit resistance value(ohm):
+ &pio {
+ mediatek,rsel-resistance-in-si-unit;
+ }
+ pincontroller {
+ i2c0_pin {
+ pins {
+ pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
+ bias-pull-down = <75000>;
+ }
+ };
+ };
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8186 pull up PUPD/R0/R1 type define value.
+ - enum: [200, 201, 202, 203]
+ description: mt8186 pull up RSEL type define value.
+ - enum: [1000, 5000, 10000, 75000]
+ description: mt8186 pull up RSEL type si unit value(ohm).
+ description: |
+ For pull up type is normal, it don't need add RSEL & R1R0 define
+ and resistance value.
+ For pull up type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8186.
+ For pull up type is RSEL, it can add RSEL define & resistance
+ value(ohm) to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit".
+ It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" &
+ "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" define in
+ mt8186. It can also support resistance value(ohm) "1000" & "5000"
+ & "10000" & "75000" in mt8186.
+ An example of using si unit resistance value(ohm):
+ &pio {
+ mediatek,rsel-resistance-in-si-unit;
+ }
+ pincontroller {
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
+ bias-pull-up = <1000>;
+ }
+ };
+ };
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/mt8186-pinfunc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8186-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x10002000 0x0200>,
+ <0x10002200 0x0200>,
+ <0x10002400 0x0200>,
+ <0x10002600 0x0200>,
+ <0x10002A00 0x0200>,
+ <0x10002c00 0x0200>,
+ <0x1000b000 0x1000>;
+ reg-names = "iocfg0", "iocfg_lt", "iocfg_lm",
+ "iocfg_lb", "iocfg_bl", "iocfg_rb",
+ "iocfg_rt", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 185>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ pio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ output-low;
+ };
+ };
+
+ spi0-pins {
+ pins-spi {
+ pinmux = <PINMUX_GPIO0__FUNC_SPI0_CLK_B>,
+ <PINMUX_GPIO1__FUNC_SPI0_CSB_B>,
+ <PINMUX_GPIO2__FUNC_SPI0_MO_B>;
+ bias-disable;
+ };
+ pins-spi-mi {
+ pinmux = <PINMUX_GPIO3__FUNC_SPI0_MI_B>;
+ bias-pull-down;
+ };
+ };
+
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO127__FUNC_SCL0>,
+ <PINMUX_GPIO128__FUNC_SDA0>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_001>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml
new file mode 100644
index 000000000000..e994b0c70dbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml
@@ -0,0 +1,232 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8188-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8188 Pin Controller
+
+maintainers:
+ - Hui Liu <hui.liu@mediatek.com>
+
+description:
+ The MediaTek's MT8188 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8188-pinctrl
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier, should be two. The first cell is the
+ pin number, the second cell is used to specify optional parameters which
+ are defined in <dt-bindings/gpio/gpio.h>.
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names: true
+
+ reg:
+ items:
+ - description: gpio registers base address
+ - description: rm group io configuration registers base address
+ - description: lt group io configuration registers base address
+ - description: lm group io configuration registers base address
+ - description: rt group io configuration registers base address
+ - description: eint registers base address
+
+ reg-names:
+ items:
+ - const: iocfg0
+ - const: iocfg_rm
+ - const: iocfg_lt
+ - const: iocfg_lm
+ - const: iocfg_rt
+ - const: eint
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description: The interrupt outputs to sysirq.
+ maxItems: 1
+
+ mediatek,rsel-resistance-in-si-unit:
+ type: boolean
+ description:
+ We provide two methods to select the resistance for I2C when pull up or
+ pull down. The first is by RSEL definition value, another one is by
+ resistance value(ohm). This flag is used to identify if the method is
+ resistance(si unit) value.
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^pins':
+ type: object
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+ additionalProperties: false
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in dt-bindings/pinctrl/mediatek,mt8188-pinfunc.h
+ directly, for this SoC.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8188 pull down PUPD/R0/R1 type define value.
+ - enum: [200, 201, 202, 203, 204, 205, 206, 207]
+ description: mt8188 pull down RSEL type define value.
+ - enum: [75000, 5000]
+ description: mt8188 pull down RSEL type si unit value(ohm).
+ description: |
+ For pull down type is normal, it doesn't need add RSEL & R1R0
+ define and resistance value.
+ For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8188.
+ For pull down type is RSEL, it can add RSEL define & resistance
+ value(ohm) to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit". It can support
+ "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" &
+ "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" &
+ "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" &
+ "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" define in
+ mt8188. It can also support resistance value(ohm) "75000" & "5000"
+ in mt8188.
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8188 pull up PUPD/R0/R1 type define value.
+ - enum: [200, 201, 202, 203, 204, 205, 206, 207]
+ description: mt8188 pull up RSEL type define value.
+ - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000]
+ description: mt8188 pull up RSEL type si unit value(ohm).
+ description: |
+ For pull up type is normal, it don't need add RSEL & R1R0 define
+ and resistance value.
+ For pull up type is PUPD/R0/R1 type, it can add R1R0 define to set
+ different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8188.
+ For pull up type is RSEL, it can add RSEL define & resistance
+ value(ohm) to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit". It can support
+ "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" &
+ "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" &
+ "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" &
+ "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" define in
+ mt8188. It can also support resistance value(ohm) "1000" & "1500"
+ & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8188.
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/mediatek,mt8188-pinfunc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8188-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x11c00000 0x1000>,
+ <0x11e10000 0x1000>,
+ <0x11e20000 0x1000>,
+ <0x11ea0000 0x1000>,
+ <0x1000b000 0x1000>;
+ reg-names = "iocfg0", "iocfg_rm",
+ "iocfg_lt", "iocfg_lm", "iocfg_rt",
+ "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 176>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ pio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_B_GPIO0>;
+ output-low;
+ };
+ };
+
+ spi0-pins {
+ pins-spi {
+ pinmux = <PINMUX_GPIO75__FUNC_O_SPIM1_CSB>,
+ <PINMUX_GPIO76__FUNC_O_SPIM1_CLK>,
+ <PINMUX_GPIO77__FUNC_B0_SPIM1_MOSI>;
+ drive-strength = <6>;
+ };
+ pins-spi-mi {
+ pinmux = <PINMUX_GPIO78__FUNC_B0_SPIM1_MISO>;
+ bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
+ };
+ };
+
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO55__FUNC_B1_SCL0>,
+ <PINMUX_GPIO56__FUNC_B1_SDA0>;
+ bias-disable;
+ drive-strength-microamp = <1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8189-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8189-pinctrl.yaml
new file mode 100644
index 000000000000..32e4653da5db
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8189-pinctrl.yaml
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8189-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8189 Pin Controller
+
+maintainers:
+ - Lei Xue <lei.xue@mediatek.com>
+ - Cathy Xu <ot_cathy.xu@mediatek.com>
+
+description:
+ The MediaTek's MT8189 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8189-pinctrl
+
+ reg:
+ items:
+ - description: gpio base
+ - description: lm group IO
+ - description: rb0 group IO
+ - description: rb1 group IO
+ - description: bm0 group IO
+ - description: bm1 group IO
+ - description: bm2 group IO
+ - description: lt0 group IO
+ - description: lt1 group IO
+ - description: rt group IO
+ - description: eint0 group IO
+ - description: eint1 group IO
+ - description: eint2 group IO
+ - description: eint3 group IO
+ - description: eint4 group IO
+
+ reg-names:
+ items:
+ - const: base
+ - const: lm
+ - const: rb0
+ - const: rb1
+ - const: bm0
+ - const: bm1
+ - const: bm2
+ - const: lt0
+ - const: lt1
+ - const: rt
+ - const: eint0
+ - const: eint1
+ - const: eint2
+ - const: eint3
+ - const: eint4
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names: true
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^pins':
+ type: object
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+ additionalProperties: false
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in arch/arm64/boot/dts/mediatek/mt8189-pinfunc.h
+ directly, for this SoC.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8189 pull down PUPD/R0/R1 type define value.
+ - enum: [75000, 5000]
+ description: mt8189 pull down RSEL type si unit value(ohm).
+ description: |
+ For pull down type is normal, it doesn't need add R1R0 define
+ and resistance value.
+
+ For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8189.
+
+ For pull down type is PD/RSEL, it can add resistance value(ohm)
+ to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit".
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8189 pull up PUPD/R0/R1 type define value.
+ - enum: [1000, 1500, 2000, 3000, 4000, 5000, 75000]
+ description: mt8189 pull up RSEL type si unit value(ohm).
+ description: |
+ For pull up type is normal, it don't need add R1R0 define
+ and resistance value.
+
+ For pull up type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8189.
+
+ For pull up type is PU/RSEL, it can add resistance value(ohm)
+ to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit".
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/mt65xx.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #define PINMUX_GPIO51__FUNC_SCL0 (MTK_PIN_NO(51) | 2)
+ #define PINMUX_GPIO52__FUNC_SDA0 (MTK_PIN_NO(52) | 2)
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8189-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x11b50000 0x1000>,
+ <0x11c50000 0x1000>,
+ <0x11c60000 0x1000>,
+ <0x11d20000 0x1000>,
+ <0x11d30000 0x1000>,
+ <0x11d40000 0x1000>,
+ <0x11e20000 0x1000>,
+ <0x11e30000 0x1000>,
+ <0x11f20000 0x1000>,
+ <0x11ce0000 0x1000>,
+ <0x11de0000 0x1000>,
+ <0x11e60000 0x1000>,
+ <0x1c01e000 0x1000>,
+ <0x11f00000 0x1000>;
+ reg-names = "base", "lm", "rb0", "rb1", "bm0" , "bm1",
+ "bm2", "lt0", "lt1", "rt", "eint0", "eint1",
+ "eint2", "eint3", "eint4";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 182>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO51__FUNC_SCL0>,
+ <PINMUX_GPIO52__FUNC_SDA0>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8192-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8192-pinctrl.yaml
new file mode 100644
index 000000000000..949dcd6fd847
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8192-pinctrl.yaml
@@ -0,0 +1,184 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8192-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8192 Pin Controller
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+description:
+ The MediaTek's MT8192 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8192-pinctrl
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+ const: 2
+
+ gpio-ranges:
+ description: GPIO valid number range.
+ maxItems: 1
+
+ gpio-line-names: true
+
+ reg:
+ description:
+ Physical address base for GPIO base registers. There are 11 GPIO physical
+ address base in mt8192.
+ maxItems: 11
+
+ reg-names:
+ description:
+ GPIO base register names.
+ maxItems: 11
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description: The interrupt outputs to sysirq.
+ maxItems: 1
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '^pins':
+ type: object
+ description:
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ $ref: pinmux-node.yaml
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+
+ drive-strength:
+ description:
+ It can support some arguments, such as MTK_DRIVE_4mA,
+ MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h. It can only
+ support 2/4/6/8/10/12/14/16mA in mt8192.
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ description: normal pull down.
+ - enum: [100, 101, 102, 103]
+ description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0_
+ defines in dt-bindings/pinctrl/mt65xx.h.
+ - enum: [200, 201, 202, 203]
+ description: RSEL pull down type. See MTK_PULL_SET_RSEL_ defines
+ in dt-bindings/pinctrl/mt65xx.h.
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ description: normal pull up.
+ - enum: [100, 101, 102, 103]
+ description: PUPD/R1/R0 pull up type. See MTK_PUPD_SET_R1R0_
+ defines in dt-bindings/pinctrl/mt65xx.h.
+ - enum: [200, 201, 202, 203]
+ description: RSEL pull up type. See MTK_PULL_SET_RSEL_ defines
+ in dt-bindings/pinctrl/mt65xx.h.
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/mt8192-pinfunc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8192-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x11c20000 0x1000>,
+ <0x11d10000 0x1000>,
+ <0x11d30000 0x1000>,
+ <0x11d40000 0x1000>,
+ <0x11e20000 0x1000>,
+ <0x11e70000 0x1000>,
+ <0x11ea0000 0x1000>,
+ <0x11f20000 0x1000>,
+ <0x11f30000 0x1000>,
+ <0x1000b000 0x1000>;
+ reg-names = "iocfg0", "iocfg_rm", "iocfg_bm",
+ "iocfg_bl", "iocfg_br", "iocfg_lm",
+ "iocfg_lb", "iocfg_rt", "iocfg_lt",
+ "iocfg_tl", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 220>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ spi1-default-pins {
+ pins-cs-mosi-clk {
+ pinmux = <PINMUX_GPIO157__FUNC_SPI1_A_CSB>,
+ <PINMUX_GPIO159__FUNC_SPI1_A_MO>,
+ <PINMUX_GPIO156__FUNC_SPI1_A_CLK>;
+ bias-disable;
+ };
+
+ pins-miso {
+ pinmux = <PINMUX_GPIO158__FUNC_SPI1_A_MI>;
+ bias-pull-down;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8195-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8195-pinctrl.yaml
new file mode 100644
index 000000000000..33cb71775db9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8195-pinctrl.yaml
@@ -0,0 +1,286 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8195-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8195 Pin Controller
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+description:
+ The MediaTek's MT8195 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8195-pinctrl
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+ const: 2
+
+ gpio-ranges:
+ description: GPIO valid number range.
+ maxItems: 1
+
+ gpio-line-names: true
+
+ reg:
+ description:
+ Physical address base for GPIO base registers. There are 8 GPIO physical
+ address base in mt8195.
+ maxItems: 8
+
+ reg-names:
+ description:
+ GPIO base register names.
+ maxItems: 8
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description: The interrupt outputs to sysirq.
+ maxItems: 1
+
+ mediatek,rsel-resistance-in-si-unit:
+ type: boolean
+ description:
+ Identifying i2c pins pull up/down type which is RSEL. It can support RSEL
+ define or si unit value(ohm) to set different resistance.
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '^pins':
+ type: object
+ additionalProperties: false
+ description: |
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ An example of using macro:
+ pincontroller {
+ /* GPIO0 set as multifunction GPIO0 */
+ gpio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ }
+ };
+ /* GPIO8 set as multifunction SDA0 */
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+ }
+ };
+ };
+ $ref: pinmux-node.yaml
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8195 pull down PUPD/R0/R1 type define value.
+ - enum: [200, 201, 202, 203, 204, 205, 206, 207]
+ description: mt8195 pull down RSEL type define value.
+ - enum: [75000, 5000]
+ description: mt8195 pull down RSEL type si unit value(ohm).
+ description: |
+ For pull down type is normal, it don't need add RSEL & R1R0 define
+ and resistance value.
+ For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8195.
+ For pull down type is RSEL, it can add RSEL define & resistance
+ value(ohm) to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit".
+ It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001"
+ & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011"
+ & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101"
+ & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111"
+ define in mt8195. It can also support resistance value(ohm)
+ "75000" & "5000" in mt8195.
+
+ An example of using RSEL define:
+ pincontroller {
+ i2c0_pin {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+ bias-pull-down = <MTK_PULL_SET_RSEL_001>;
+ }
+ };
+ };
+ An example of using si unit resistance value(ohm):
+ &pio {
+ mediatek,rsel-resistance-in-si-unit;
+ }
+ pincontroller {
+ i2c0_pin {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+ bias-pull-down = <75000>;
+ }
+ };
+ };
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8195 pull up PUPD/R0/R1 type define value.
+ - enum: [200, 201, 202, 203, 204, 205, 206, 207]
+ description: mt8195 pull up RSEL type define value.
+ - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000]
+ description: mt8195 pull up RSEL type si unit value(ohm).
+ description: |
+ For pull up type is normal, it don't need add RSEL & R1R0 define
+ and resistance value.
+ For pull up type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8195.
+ For pull up type is RSEL, it can add RSEL define & resistance
+ value(ohm) to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit".
+ It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001"
+ & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011"
+ & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101"
+ & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111"
+ define in mt8195. It can also support resistance value(ohm) "1000"
+ & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000"
+ in mt8195.
+ An example of using RSEL define:
+ pincontroller {
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+ bias-pull-up = <MTK_PULL_SET_RSEL_001>;
+ }
+ };
+ };
+ An example of using si unit resistance value(ohm):
+ &pio {
+ mediatek,rsel-resistance-in-si-unit;
+ }
+ pincontroller {
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+ bias-pull-up = <1000>;
+ }
+ };
+ };
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/mt8195-pinfunc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt8195-pinctrl";
+ reg = <0x10005000 0x1000>,
+ <0x11d10000 0x1000>,
+ <0x11d30000 0x1000>,
+ <0x11d40000 0x1000>,
+ <0x11e20000 0x1000>,
+ <0x11eb0000 0x1000>,
+ <0x11f40000 0x1000>,
+ <0x1000b000 0x1000>;
+ reg-names = "iocfg0", "iocfg_bm", "iocfg_bl",
+ "iocfg_br", "iocfg_lm", "iocfg_rb",
+ "iocfg_tl", "eint";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 144>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ pio-pins {
+ pins {
+ pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+ output-low;
+ };
+ };
+
+ spi0-pins {
+ pins-spi {
+ pinmux = <PINMUX_GPIO132__FUNC_SPIM0_CSB>,
+ <PINMUX_GPIO134__FUNC_SPIM0_MO>,
+ <PINMUX_GPIO133__FUNC_SPIM0_CLK>;
+ bias-disable;
+ };
+ pins-spi-mi {
+ pinmux = <PINMUX_GPIO135__FUNC_SPIM0_MI>;
+ bias-pull-down;
+ };
+ };
+
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO8__FUNC_SDA0>,
+ <PINMUX_GPIO9__FUNC_SCL0>;
+ bias-disable;
+ drive-strength-microamp = <1000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8196-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8196-pinctrl.yaml
new file mode 100644
index 000000000000..9082bd625e2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8196-pinctrl.yaml
@@ -0,0 +1,236 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8196-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8196 Pin Controller
+
+maintainers:
+ - Lei Xue <lei.xue@mediatek.com>
+ - Cathy Xu <ot_cathy.xu@mediatek.com>
+
+description:
+ The MediaTek's MT8196 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8196-pinctrl
+
+ reg:
+ items:
+ - description: gpio base
+ - description: rt group IO
+ - description: rm1 group IO
+ - description: rm2 group IO
+ - description: rb group IO
+ - description: bm1 group IO
+ - description: bm2 group IO
+ - description: bm3 group IO
+ - description: lt group IO
+ - description: lm1 group IO
+ - description: lm2 group IO
+ - description: lb1 group IO
+ - description: lb2 group IO
+ - description: tm1 group IO
+ - description: tm2 group IO
+ - description: tm3 group IO
+ - description: eint0 group IO
+ - description: eint1 group IO
+ - description: eint2 group IO
+ - description: eint3 group IO
+ - description: eint4 group IO
+
+ reg-names:
+ items:
+ - const: base
+ - const: rt
+ - const: rm1
+ - const: rm2
+ - const: rb
+ - const: bm1
+ - const: bm2
+ - const: bm3
+ - const: lt
+ - const: lm1
+ - const: lm2
+ - const: lb1
+ - const: lb2
+ - const: tm1
+ - const: tm2
+ - const: tm3
+ - const: eint0
+ - const: eint1
+ - const: eint2
+ - const: eint3
+ - const: eint4
+
+ interrupts:
+ description: The interrupt outputs to sysirq.
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ description:
+ Number of cells in GPIO specifier, should be two. The first cell is the
+ pin number, the second cell is used to specify optional parameters which
+ are defined in <dt-bindings/gpio/gpio.h>.
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names: true
+
+# PIN CONFIGURATION NODES
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^pins':
+ type: object
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+ additionalProperties: false
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in arch/arm64/boot/dts/mediatek/mt8196-pinfunc.h
+ directly, for this SoC.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8196 pull down PUPD/R0/R1 type define value.
+ - enum: [75000, 5000]
+ description: mt8196 pull down RSEL type si unit value(ohm).
+ description: |
+ For pull down type is normal, it doesn't need add R1R0 define
+ and resistance value.
+ For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8196.
+ For pull down type is PD/RSEL, it can add resistance value(ohm)
+ to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit". It can support resistance
+ value(ohm) "75000" & "5000" in mt8196.
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: mt8196 pull up PUPD/R0/R1 type define value.
+ - enum: [1000, 1500, 2000, 3000, 4000, 5000, 75000]
+ description: mt8196 pull up RSEL type si unit value(ohm).
+ description: |
+ For pull up type is normal, it don't need add R1R0 define
+ and resistance value.
+ For pull up type is PUPD/R0/R1 type, it can add R1R0 define to
+ set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
+ "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
+ "MTK_PUPD_SET_R1R0_11" define in mt8196.
+ For pull up type is PU/RSEL, it can add resistance value(ohm)
+ to set different resistance by identifying property
+ "mediatek,rsel-resistance-in-si-unit". It can support resistance
+ value(ohm) "1000" & "1500" & "2000" & "3000" & "4000" & "5000" &
+ "75000" in mt8196.
+
+ bias-disable: true
+
+ output-high: true
+
+ output-low: true
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/mt65xx.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #define PINMUX_GPIO99__FUNC_SCL0 (MTK_PIN_NO(99) | 1)
+ #define PINMUX_GPIO100__FUNC_SDA0 (MTK_PIN_NO(100) | 1)
+
+ pio: pinctrl@1002d000 {
+ compatible = "mediatek,mt8196-pinctrl";
+ reg = <0x1002d000 0x1000>,
+ <0x12000000 0x1000>,
+ <0x12020000 0x1000>,
+ <0x12040000 0x1000>,
+ <0x12060000 0x1000>,
+ <0x12820000 0x1000>,
+ <0x12840000 0x1000>,
+ <0x12860000 0x1000>,
+ <0x13000000 0x1000>,
+ <0x13020000 0x1000>,
+ <0x13040000 0x1000>,
+ <0x130f0000 0x1000>,
+ <0x13110000 0x1000>,
+ <0x13800000 0x1000>,
+ <0x13820000 0x1000>,
+ <0x13860000 0x1000>,
+ <0x12080000 0x1000>,
+ <0x12880000 0x1000>,
+ <0x13080000 0x1000>,
+ <0x13880000 0x1000>,
+ <0x1c54a000 0x1000>;
+ reg-names = "base", "rt", "rm1", "rm2", "rb" , "bm1",
+ "bm2", "bm3", "lt", "lm1", "lm2", "lb1",
+ "lb2", "tm1", "tm2", "tm3", "eint0", "eint1",
+ "eint2", "eint3", "eint4";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pio 0 0 271>;
+ interrupt-controller;
+ interrupts = <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH 0>;
+ #interrupt-cells = <2>;
+
+ i2c0-pins {
+ pins {
+ pinmux = <PINMUX_GPIO99__FUNC_SCL0>,
+ <PINMUX_GPIO100__FUNC_SDA0>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
new file mode 100644
index 000000000000..7b43e7857281
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml
@@ -0,0 +1,230 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8365-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8365 Pin Controller
+
+maintainers:
+ - Zhiyong Tao <zhiyong.tao@mediatek.com>
+ - Bernhard Rosenkränzer <bero@baylibre.com>
+
+description:
+ The MediaTek's MT8365 Pin controller is used to control SoC pins.
+
+properties:
+ compatible:
+ const: mediatek,mt8365-pinctrl
+
+ reg:
+ maxItems: 1
+
+ mediatek,pctl-regmap:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
+ minItems: 1
+ maxItems: 2
+ description:
+ Should be phandles of the syscfg node.
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+ the amount of cells must be specified as 2. See the below mentioned gpio
+ binding representation for description of particular cells.
+
+ interrupt-controller: true
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+patternProperties:
+ "-pins$":
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "pins$":
+ type: object
+ additionalProperties: false
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ pinmux:
+ description:
+ Integer array, represents gpio pin number and mux setting.
+ Supported pin number and mux varies for different SoCs, and are
+ defined as macros in <soc>-pinfunc.h directly.
+
+ bias-disable: true
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: Pull up R1/R0 type define value.
+ description: |
+ For pull up type is normal, it don't need add R1/R0 define.
+ For pull up type is R1/R0 type, it can add value to set different
+ resistance. Valid arguments are described as below:
+ 100: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 101: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 102: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 103: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - enum: [100, 101, 102, 103]
+ description: Pull down R1/R0 type define value.
+ description: |
+ For pull down type is normal, it don't need add R1/R0 define.
+ For pull down type is R1/R0 type, it can add value to set
+ different resistance. Valid arguments are described as below:
+ 100: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 101: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 102: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 103: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+
+ input-enable: true
+
+ input-disable: true
+
+ output-low: true
+
+ output-high: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-strength-microamp:
+ enum: [125, 250, 500, 1000]
+
+ mediatek,drive-strength-adv:
+ deprecated: true
+ description: |
+ DEPRECATED: Please use drive-strength-microamp instead.
+ Describe the specific driving setup property.
+ For I2C pins, the existing generic driving setup can only support
+ 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they
+ can support 0.125/0.25/0.5/1mA adjustment. If we enable specific
+ driving setup, the existing generic setup will be disabled.
+ The specific driving setup is controlled by E1E0EN.
+ When E1=0/E0=0, the strength is 0.125mA.
+ When E1=0/E0=1, the strength is 0.25mA.
+ When E1=1/E0=0, the strength is 0.5mA.
+ When E1=1/E0=1, the strength is 1mA.
+ EN is used to enable or disable the specific driving setup.
+ Valid arguments are described as below:
+ 0: (E1, E0, EN) = (0, 0, 0)
+ 1: (E1, E0, EN) = (0, 0, 1)
+ 2: (E1, E0, EN) = (0, 1, 0)
+ 3: (E1, E0, EN) = (0, 1, 1)
+ 4: (E1, E0, EN) = (1, 0, 0)
+ 5: (E1, E0, EN) = (1, 0, 1)
+ 6: (E1, E0, EN) = (1, 1, 0)
+ 7: (E1, E0, EN) = (1, 1, 1)
+ So the valid arguments are from 0 to 7.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ mediatek,pull-up-adv:
+ deprecated: true
+ description: |
+ DEPRECATED: Please use bias-pull-up instead.
+ Pull up settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as
+ below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,pull-down-adv:
+ deprecated: true
+ description: |
+ DEPRECATED: Please use bias-pull-down instead.
+ Pull down settings for 2 pull resistors, R0 and R1. User can
+ configure those special pins. Valid arguments are described as
+ below:
+ 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
+ 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
+ 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
+ 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+
+ mediatek,tdsel:
+ description:
+ An integer describing the steps for output level shifter duty
+ cycle when asserted (high pulse width adjustment). Valid arguments
+ are from 0 to 15.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ mediatek,rdsel:
+ description:
+ An integer describing the steps for input level shifter duty cycle
+ when asserted (high pulse width adjustment). Valid arguments are
+ from 0 to 63.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/mt8365-pinfunc.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pio: pinctrl@1000b000 {
+ compatible = "mediatek,mt8365-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+
+ pio-pins {
+ pins {
+ pinmux = <MT8365_PIN_59_SDA1__FUNC_SDA1_0>, <MT8365_PIN_60_SCL1__FUNC_SCL1_0>;
+ mediatek,pull-up-adv = <3>;
+ bias-pull-up;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml
deleted file mode 100644
index 73ae6e11410b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml
+++ /dev/null
@@ -1,224 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/mediatek,pinctrl-mt6795.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mediatek MT6795 Pin Controller
-
-maintainers:
- - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
- - Sean Wang <sean.wang@kernel.org>
-
-description: |
- The Mediatek's Pin controller is used to control SoC pins.
-
-properties:
- compatible:
- const: mediatek,mt6795-pinctrl
-
- gpio-controller: true
-
- '#gpio-cells':
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO binding is used,
- the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
- const: 2
-
- gpio-ranges:
- description: GPIO valid number range.
- maxItems: 1
-
- reg:
- description:
- Physical address base for gpio base and eint registers.
- minItems: 2
-
- reg-names:
- items:
- - const: base
- - const: eint
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
-
- interrupts:
- description: The interrupt outputs to sysirq.
- maxItems: 1
-
-# PIN CONFIGURATION NODES
-patternProperties:
- '-pins$':
- type: object
- additionalProperties: false
- patternProperties:
- '^pins':
- type: object
- additionalProperties: false
- description: |
- A pinctrl node should contain at least one subnodes representing the
- pinctrl groups available on the machine. Each subnode will list the
- pins it needs, and how they should be configured, with regard to muxer
- configuration, pullups, drive strength, input enable/disable and
- input schmitt.
- An example of using macro:
- pincontroller {
- /* GPIO0 set as multifunction GPIO0 */
- gpio-pins {
- pins {
- pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
- }
- };
- /* GPIO45 set as multifunction SDA0 */
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO45__FUNC_SDA0>;
- }
- };
- };
- $ref: "pinmux-node.yaml"
-
- properties:
- pinmux:
- description: |
- Integer array, represents gpio pin number and mux setting.
- Supported pin number and mux varies for different SoCs, and are
- defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h
- directly.
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
-
- bias-pull-down:
- oneOf:
- - type: boolean
- - enum: [100, 101, 102, 103]
- description: mt6795 pull down PUPD/R0/R1 type define value.
- description: |
- For normal pull down type, it is not necessary to specify R1R0
- values; When pull down type is PUPD/R0/R1, adding R1R0 defines
- will set different resistance values.
-
- bias-pull-up:
- oneOf:
- - type: boolean
- - enum: [100, 101, 102, 103]
- description: mt6795 pull up PUPD/R0/R1 type define value.
- description: |
- For normal pull up type, it is not necessary to specify R1R0
- values; When pull up type is PUPD/R0/R1, adding R1R0 defines
- will set different resistance values.
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- input-enable: true
-
- input-disable: true
-
- input-schmitt-enable: true
-
- input-schmitt-disable: true
-
- mediatek,pull-up-adv:
- description: |
- Pull up setings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
- 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
- 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
- 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
- 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2, 3]
-
- mediatek,pull-down-adv:
- description: |
- Pull down settings for 2 pull resistors, R0 and R1. User can
- configure those special pins. Valid arguments are described as below:
- 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled.
- 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled.
- 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled.
- 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled.
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2, 3]
-
- required:
- - pinmux
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - reg-names
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/pinctrl/mt6795-pinfunc.h>
-
- soc {
- #address-cells = <2>;
- #size-cells = <2>;
-
- pio: pinctrl@10005000 {
- compatible = "mediatek,mt6795-pinctrl";
- reg = <0 0x10005000 0 0x1000>, <0 0x1000b000 0 0x1000>;
- reg-names = "base", "eint";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pio 0 0 196>;
- interrupt-controller;
- interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
- #interrupt-cells = <2>;
-
- i2c0-pins {
- pins-sda-scl {
- pinmux = <PINMUX_GPIO45__FUNC_SDA0>,
- <PINMUX_GPIO46__FUNC_SCL0>;
- };
- };
-
- mmc0-pins {
- pins-cmd-dat {
- pinmux = <PINMUX_GPIO154__FUNC_MSDC0_DAT0>,
- <PINMUX_GPIO155__FUNC_MSDC0_DAT1>,
- <PINMUX_GPIO156__FUNC_MSDC0_DAT2>,
- <PINMUX_GPIO157__FUNC_MSDC0_DAT3>,
- <PINMUX_GPIO158__FUNC_MSDC0_DAT4>,
- <PINMUX_GPIO159__FUNC_MSDC0_DAT5>,
- <PINMUX_GPIO160__FUNC_MSDC0_DAT6>,
- <PINMUX_GPIO161__FUNC_MSDC0_DAT7>,
- <PINMUX_GPIO162__FUNC_MSDC0_CMD>;
- input-enable;
- bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
- };
-
- pins-clk {
- pinmux = <PINMUX_GPIO163__FUNC_MSDC0_CLK>;
- bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
- };
-
- pins-rst {
- pinmux = <PINMUX_GPIO165__FUNC_MSDC0_RSTB>;
- bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
deleted file mode 100644
index 8146193bd8ac..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-== Amlogic Meson pinmux controller ==
-
-Required properties for the root node:
- - compatible: one of "amlogic,meson8-cbus-pinctrl"
- "amlogic,meson8b-cbus-pinctrl"
- "amlogic,meson8m2-cbus-pinctrl"
- "amlogic,meson8-aobus-pinctrl"
- "amlogic,meson8b-aobus-pinctrl"
- "amlogic,meson8m2-aobus-pinctrl"
- "amlogic,meson-gxbb-periphs-pinctrl"
- "amlogic,meson-gxbb-aobus-pinctrl"
- "amlogic,meson-gxl-periphs-pinctrl"
- "amlogic,meson-gxl-aobus-pinctrl"
- "amlogic,meson-axg-periphs-pinctrl"
- "amlogic,meson-axg-aobus-pinctrl"
- "amlogic,meson-g12a-periphs-pinctrl"
- "amlogic,meson-g12a-aobus-pinctrl"
- "amlogic,meson-a1-periphs-pinctrl"
- "amlogic,meson-s4-periphs-pinctrl"
- - reg: address and size of registers controlling irq functionality
-
-=== GPIO sub-nodes ===
-
-The GPIO bank for the controller is represented as a sub-node and it acts as a
-GPIO controller.
-
-Required properties for sub-nodes are:
- - reg: should contain a list of address and size, one tuple for each entry
- in reg-names.
- - reg-names: an array of strings describing the "reg" entries.
- Must contain "mux" and "gpio".
- May contain "pull", "pull-enable" and "ds" when appropriate.
- - gpio-controller: identifies the node as a gpio controller
- - #gpio-cells: must be 2
-
-=== Other sub-nodes ===
-
-Child nodes without the "gpio-controller" represent some desired
-configuration for a pin or a group. Those nodes can be pinmux nodes or
-configuration nodes.
-
-Required properties for pinmux nodes are:
- - groups: a list of pinmux groups. The list of all available groups
- depends on the SoC and can be found in driver sources.
- - function: the name of a function to activate for the specified set
- of groups. The list of all available functions depends on the SoC
- and can be found in driver sources.
-
-Required properties for configuration nodes:
- - pins: a list of pin names
-
-Configuration nodes support the following generic properties, as
-described in file pinctrl-bindings.txt:
- - "bias-disable"
- - "bias-pull-up"
- - "bias-pull-down"
- - "output-enable"
- - "output-disable"
- - "output-low"
- - "output-high"
-
-Optional properties :
- - drive-strength-microamp: Drive strength for the specified pins in uA.
- This property is only valid for G12A and newer.
-
-=== Example ===
-
- pinctrl: pinctrl@c1109880 {
- compatible = "amlogic,meson8-cbus-pinctrl";
- reg = <0xc1109880 0x10>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- gpio: banks@c11080b0 {
- reg = <0xc11080b0 0x28>,
- <0xc11080e8 0x18>,
- <0xc1108120 0x18>,
- <0xc1108030 0x30>;
- reg-names = "mux", "pull", "pull-enable", "gpio";
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- nand {
- mux {
- groups = "nand_io", "nand_io_ce0", "nand_io_ce1",
- "nand_io_rb0", "nand_ale", "nand_cle",
- "nand_wen_clk", "nand_ren_clk", "nand_dqs",
- "nand_ce2", "nand_ce3";
- function = "nand";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
new file mode 100644
index 000000000000..e07f4723de17
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,mcp23s08.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/microchip,mcp23s08.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip I/O expander with serial interface (I2C/SPI)
+
+maintainers:
+ - Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>
+
+description:
+ Microchip MCP23008, MCP23017, MCP23S08, MCP23S17, MCP23S18 GPIO expander
+ chips.These chips provide 8 or 16 GPIO pins with either I2C or SPI interface.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - microchip,mcp23s08
+ - microchip,mcp23s17
+ - microchip,mcp23s18
+ - microchip,mcp23008
+ - microchip,mcp23017
+ - microchip,mcp23018
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO specifier for active-low reset pin.
+ maxItems: 1
+
+ microchip,spi-present-mask:
+ description:
+ Multiple SPI chips can share the same SPI chipselect. Set a bit in
+ bit0-7 in this mask to 1 if there is a chip connected with the
+ corresponding spi address set. For example if you have a chip with
+ address 3 connected, you have to set bit3 to 1, which is 0x08. mcp23s08
+ chip variant only supports bits 0-3. It is not possible to mix mcp23s08
+ and mcp23s17 on the same chipselect. Set at least one bit to 1 for SPI
+ chips.
+ $ref: /schemas/types.yaml#/definitions/uint8
+
+ microchip,irq-mirror:
+ type: boolean
+ description:
+ Sets the mirror flag in the IOCON register. Devices with two interrupt
+ outputs (these are the devices ending with 17 and those that have 16 IOs)
+ have two IO banks IO 0-7 form bank 1 and IO 8-15 are bank 2. These chips
+ have two different interrupt outputs One for bank 1 and another for
+ bank 2. If irq-mirror is set, both interrupts are generated regardless of
+ the bank that an input change occurred on. If it is not set,the interrupt
+ are only generated for the bank they belong to.
+
+ microchip,irq-active-high:
+ type: boolean
+ description:
+ Sets the INTPOL flag in the IOCON register.This configures the IRQ output
+ polarity as active high.
+
+ drive-open-drain:
+ type: boolean
+ description:
+ Sets the ODR flag in the IOCON register. This configures the IRQ output as
+ open drain active low.
+
+ pinmux:
+ type: object
+ properties:
+ pins:
+ description:
+ The list of GPIO pins controlled by this node. Each pin name
+ corresponds to a physical pin on the GPIO expander.
+ items:
+ pattern: '^gpio([0-9]|[1][0-5])$'
+ maxItems: 16
+
+ bias-pull-up:
+ type: boolean
+ description:
+ Configures pull-up resistors for the GPIO pins. Absence of this
+ property will leave the configuration in its default state.
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@21 {
+ compatible = "microchip,mcp23017";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ microchip,irq-mirror;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c_gpio0>, <&gpiopullups>;
+ reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
+
+ gpiopullups: pinmux {
+ pins = "gpio0", "gpio1", "gpio2", "gpio3",
+ "gpio4", "gpio5", "gpio6", "gpio7",
+ "gpio8", "gpio9", "gpio10", "gpio11",
+ "gpio12", "gpio13", "gpio14", "gpio15";
+ bias-pull-up;
+ };
+ };
+ };
+
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@0 {
+ compatible = "microchip,mcp23s17";
+ reg = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ spi-max-frequency = <1000000>;
+ microchip,spi-present-mask = /bits/ 8 <0x01>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml
new file mode 100644
index 000000000000..3c98eb35fb82
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC iomux0
+
+maintainers:
+ - Conor Dooley <conor.dooley@microchip.com>
+
+description:
+ iomux0 is responsible for routing some functions to either the FPGA fabric,
+ or to MSSIOs. It only performs muxing, and has no IO configuration role, as
+ fabric IOs are configured separately and just routing a function to MSSIOs is
+ not sufficient for it to actually get mapped to an MSSIO, just makes it
+ possible.
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,mpfs-pinctrl-iomux0
+ - items:
+ - const: microchip,pic64gx-pinctrl-iomux0
+ - const: microchip,mpfs-pinctrl-iomux0
+
+ reg:
+ maxItems: 1
+
+ pinctrl-use-default: true
+
+patternProperties:
+ '^mux-':
+ type: object
+ $ref: pinmux-node.yaml
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [ spi0, spi1, i2c0, i2c1, can0, can1, qspi, uart0, uart1, uart2,
+ uart3, uart4, mdio0, mdio1 ]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ items:
+ enum: [ spi0_fabric, spi0_mssio, spi1_fabric, spi1_mssio, i2c0_fabric,
+ i2c0_mssio, i2c1_fabric, i2c1_mssio, can0_fabric, can0_mssio,
+ can1_fabric, can1_mssio, qspi_fabric, qspi_mssio,
+ uart0_fabric, uart0_mssio, uart1_fabric, uart1_mssio,
+ uart2_fabric, uart2_mssio, uart3_fabric, uart3_mssio,
+ uart4_fabric, uart4_mssio, mdio0_fabric, mdio0_mssio,
+ mdio1_fabric, mdio1_mssio ]
+
+ required:
+ - function
+ - groups
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #size-cells = <1>;
+ #address-cells = <1>;
+
+ pinctrl@200 {
+ compatible = "microchip,mpfs-pinctrl-iomux0";
+ reg = <0x200 0x4>;
+
+ mux-spi0-fabric {
+ function = "spi0";
+ groups = "spi0_fabric";
+ };
+
+ mux-spi1-mssio {
+ function = "spi1";
+ groups = "spi1_mssio";
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml
new file mode 100644
index 000000000000..e3792679de58
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/microchip,pic64gx-pinctrl-gpio2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC64GX GPIO2 Mux
+
+maintainers:
+ - Conor Dooley <conor.dooley@microchip.com>
+
+description:
+ The "GPIO2 Mux" determines whether GPIO2 or select other functions are
+ available on package pins on PIC64GX. Some of these functions must be
+ mapped to this mux via iomux0 for settings here to have any impact.
+
+properties:
+ compatible:
+ const: microchip,pic64gx-pinctrl-gpio2
+
+ reg:
+ maxItems: 1
+
+ pinctrl-use-default: true
+
+patternProperties:
+ '^mux-':
+ type: object
+ $ref: pinmux-node.yaml
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [ mdio0, mdio1, spi0, can0, pcie, qspi, uart3, uart4, can1, uart2, gpio ]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ items:
+ enum: [ mdio0, mdio1, spi0, can0, pcie, qspi, uart3, uart4, can1, uart2,
+ gpio_mdio0, gpio_mdio1, gpio_spi0, gpio_can0, gpio_pcie,
+ gpio_qspi, gpio_uart3, gpio_uart4, gpio_can1, gpio_uart2 ]
+
+ required:
+ - function
+ - groups
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@41000000 {
+ compatible = "microchip,pic64gx-pinctrl-gpio2";
+ reg = <0x41000000 0x4>;
+ pinctrl-use-default;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio0_gpio2>, <&mdio1_gpio2>, <&spi0_gpio2>, <&qspi_gpio2>,
+ <&uart3_gpio2>, <&uart4_gpio2>, <&can1_gpio2>, <&can0_gpio2>,
+ <&uart2_gpio2>;
+
+ mux-gpio2 {
+ function = "gpio";
+ groups = "gpio_mdio1", "gpio_spi0", "gpio_can0", "gpio_pcie",
+ "gpio_qspi", "gpio_uart3", "gpio_uart4", "gpio_can1";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
index 0df4e114fdd6..fa47732d7cef 100644
--- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml
@@ -18,7 +18,7 @@ description: |
properties:
$nodename:
- pattern: "^gpio@[0-9a-f]+$"
+ pattern: '^gpio@[0-9a-f]+$'
compatible:
enum:
@@ -26,10 +26,10 @@ properties:
- mscc,ocelot-sgpio
- mscc,luton-sgpio
- "#address-cells":
+ '#address-cells':
const: 1
- "#size-cells":
+ '#size-cells':
const: 0
reg:
@@ -76,7 +76,7 @@ properties:
- const: switch
patternProperties:
- "^gpio@[0-1]$":
+ '^gpio@[0-1]$':
type: object
properties:
compatible:
@@ -132,8 +132,8 @@ required:
- reg
- clocks
- microchip,sgpio-port-ranges
- - "#address-cells"
- - "#size-cells"
+ - '#address-cells'
+ - '#size-cells'
examples:
- |
diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml
index 98d547c34ef3..31bc30a81752 100644
--- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml
@@ -12,14 +12,24 @@ maintainers:
properties:
compatible:
- enum:
- - microchip,lan966x-pinctrl
- - microchip,sparx5-pinctrl
- - mscc,jaguar2-pinctrl
- - mscc,luton-pinctrl
- - mscc,ocelot-pinctrl
- - mscc,serval-pinctrl
- - mscc,servalt-pinctrl
+ oneOf:
+ - enum:
+ - microchip,lan966x-pinctrl
+ - microchip,lan9691-pinctrl
+ - microchip,sparx5-pinctrl
+ - mscc,jaguar2-pinctrl
+ - mscc,luton-pinctrl
+ - mscc,ocelot-pinctrl
+ - mscc,serval-pinctrl
+ - mscc,servalt-pinctrl
+ - items:
+ - enum:
+ - microchip,lan9698-pinctrl
+ - microchip,lan9696-pinctrl
+ - microchip,lan9694-pinctrl
+ - microchip,lan9693-pinctrl
+ - microchip,lan9692-pinctrl
+ - const: microchip,lan9691-pinctrl
reg:
items:
@@ -54,8 +64,8 @@ patternProperties:
'-pins$':
type: object
allOf:
- - $ref: "pinmux-node.yaml"
- - $ref: "pincfg-node.yaml"
+ - $ref: pinmux-node.yaml
+ - $ref: pincfg-node.yaml
properties:
function: true
@@ -78,13 +88,14 @@ required:
- gpio-ranges
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
- if:
properties:
compatible:
contains:
enum:
- microchip,lan966x-pinctrl
+ - microchip,lan9691-pinctrl
- microchip,sparx5-pinctrl
then:
properties:
diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml
new file mode 100644
index 000000000000..763a49bd07dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,ma35d1-pinctrl.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nuvoton,ma35d1-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 pin control and GPIO
+
+maintainers:
+ - Shan-Chun Hung <schung@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,ma35d1-pinctrl
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ nuvoton,sys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle of the system-management node.
+
+ ranges: true
+
+patternProperties:
+ "^gpio@[0-9a-f]+$":
+ type: object
+ properties:
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupts:
+ description:
+ The interrupt outputs to sysirq.
+ maxItems: 1
+
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+ - reg
+ - clocks
+ - interrupt-controller
+ - '#interrupt-cells'
+ - interrupts
+
+ additionalProperties: false
+
+ "-grp$":
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ patternProperties:
+ "-pins$":
+ type: object
+ description:
+ A pinctrl node should contain at least one subnodes representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to muxer
+ configuration, pullups, drive strength, input enable/disable and input
+ schmitt.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
+ properties:
+ nuvoton,pins:
+ description:
+ Each entry consists of 4 parameters and represents the mux and config
+ setting for one pin.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ items:
+ - minimum: 0
+ maximum: 13
+ description:
+ Pin bank.
+ - minimum: 0
+ maximum: 15
+ description:
+ Pin bank index.
+ - minimum: 0
+ maximum: 15
+ description:
+ Mux 0 means GPIO and mux 1 to 15 means the specific device function.
+
+ power-source:
+ description: |
+ Valid arguments are described as below:
+ 0: power supply of 1.8V
+ 1: power supply of 3.3V
+ enum: [0, 1]
+
+ drive-strength-microamp:
+ oneOf:
+ - enum: [ 2900, 4400, 5800, 7300, 8600, 10100, 11500, 13000 ]
+ description: 1.8V I/O driving strength
+ - enum: [ 17100, 25600, 34100, 42800, 48000, 56000, 77000, 82000 ]
+ description: 3.3V I/O driving strength
+
+ bias-disable: true
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ input-schmitt-disable: true
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - nuvoton,sys
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+ pinctrl@40040000 {
+ compatible = "nuvoton,ma35d1-pinctrl";
+ reg = <0x40040000 0xc00>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nuvoton,sys = <&sys>;
+ ranges = <0x0 0x40040000 0x400>;
+
+ gpio@0 {
+ reg = <0x0 0x40>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk GPA_GATE>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart-grp {
+ uart11-pins {
+ nuvoton,pins = <11 0 2>,
+ <11 1 2>,
+ <11 2 2>,
+ <11 3 2>;
+ power-source = <1>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml
new file mode 100644
index 000000000000..8cd1f442240e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm845-pinctrl.yaml
@@ -0,0 +1,215 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nuvoton,npcm845-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM845 Pin Controller and GPIO
+
+maintainers:
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+description:
+ The Nuvoton BMC NPCM8XX Pin Controller multi-function routed through
+ the multiplexing block, Each pin supports GPIO functionality (GPIOx)
+ and multiple functions that directly connect the pin to different
+ hardware blocks.
+
+properties:
+ compatible:
+ const: nuvoton,npcm845-pinctrl
+
+ ranges:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ nuvoton,sysgcr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to access GCR registers.
+
+patternProperties:
+ '^gpio@':
+ type: object
+ additionalProperties: false
+
+ description:
+ Eight GPIO banks that each contain 32 GPIOs.
+
+ properties:
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-ranges:
+ maxItems: 1
+
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+ - reg
+ - interrupts
+ - gpio-ranges
+
+ '-mux$':
+ $ref: pinmux-node.yaml#
+
+ properties:
+ groups:
+ description:
+ One or more groups of pins to mux to a certain function
+ items:
+ enum: [ iox1, iox2, smb1d, smb2d, lkgpo1, lkgpo2, ioxh, gspi,
+ smb5b, smb5c, lkgpo0, pspi, jm1, jm2, smb4b, smb4c, smb15,
+ smb16, smb17, smb18, smb19, smb20, smb21, smb22, smb23,
+ smb23b, smb4d, smb14, smb5, smb4, smb3, spi0cs1, spi0cs2,
+ spi0cs3, spi1cs0, spi1cs1, spi1cs2, spi1cs3, spi1cs23, smb3c,
+ smb3b, bmcuart0a, uart1, jtag2, bmcuart1, uart2, sg1mdio,
+ bmcuart0b, r1err, r1md, r1oen, r2oen, rmii3, r3oen, smb3d,
+ fanin0, fanin1, fanin2, fanin3, fanin4, fanin5, fanin6,
+ fanin7, fanin8, fanin9, fanin10, fanin11, fanin12, fanin13,
+ fanin14, fanin15, pwm0, pwm1, pwm2, pwm3, r2, r2err, r2md,
+ r3rxer, ga20kbc, smb5d, lpc, espi, rg2, ddr, i3c0, i3c1,
+ i3c2, i3c3, i3c4, i3c5, smb0, smb1, smb2, smb2c, smb2b, smb1c,
+ smb1b, smb8, smb9, smb10, smb11, sd1, sd1pwr, pwm4, pwm5,
+ pwm6, pwm7, pwm8, pwm9, pwm10, pwm11, mmc8, mmc, mmcwp, mmccd,
+ mmcrst, clkout, serirq, scipme, smi, smb6, smb6b, smb6c,
+ smb6d, smb7, smb7b, smb7c, smb7d, spi1, faninx, r1, spi3,
+ spi3cs1, spi3quad, spi3cs2, spi3cs3, nprd_smi, smb0b, smb0c,
+ smb0den, smb0d, ddc, rg2mdio, wdog1, wdog2, smb12, smb13,
+ spix, spixcs1, clkreq, hgpio0, hgpio1, hgpio2, hgpio3, hgpio4,
+ hgpio5, hgpio6, hgpio7, bu4, bu4b, bu5, bu5b, bu6, gpo187 ]
+
+ function:
+ description:
+ The function that a group of pins is muxed to
+ enum: [ iox1, iox2, smb1d, smb2d, lkgpo1, lkgpo2, ioxh, gspi, smb5b,
+ smb5c, lkgpo0, pspi, jm1, jm2, smb4b, smb4c, smb15, smb16,
+ smb17, smb18, smb19, smb20, smb21, smb22, smb23, smb23b, smb4d,
+ smb14, smb5, smb4, smb3, spi0cs1, spi0cs2, spi0cs3, spi1cs0,
+ spi1cs1, spi1cs2, spi1cs3, spi1cs23, smb3c, smb3b, bmcuart0a,
+ uart1, jtag2, bmcuart1, uart2, sg1mdio, bmcuart0b, r1err, r1md,
+ r1oen, r2oen, rmii3, r3oen, smb3d, fanin0, fanin1, fanin2,
+ fanin3, fanin4, fanin5, fanin6, fanin7, fanin8, fanin9, fanin10,
+ fanin11, fanin12, fanin13, fanin14, fanin15, pwm0, pwm1, pwm2,
+ pwm3, r2, r2err, r2md, r3rxer, ga20kbc, smb5d, lpc, espi, rg2,
+ ddr, i3c0, i3c1, i3c2, i3c3, i3c4, i3c5, smb0, smb1, smb2,
+ smb2c, smb2b, smb1c, smb1b, smb8, smb9, smb10, smb11, sd1,
+ sd1pwr, pwm4, pwm5, pwm6, pwm7, pwm8, pwm9, pwm10, pwm11,
+ mmc8, mmc, mmcwp, mmccd, mmcrst, clkout, serirq, scipme, smi,
+ smb6, smb6b, smb6c, smb6d, smb7, smb7b, smb7c, smb7d, spi1,
+ faninx, r1, spi3, spi3cs1, spi3quad, spi3cs2, spi3cs3, nprd_smi,
+ smb0b, smb0c, smb0den, smb0d, ddc, rg2mdio, wdog1, wdog2,
+ smb12, smb13, spix, spixcs1, clkreq, hgpio0, hgpio1, hgpio2,
+ hgpio3, hgpio4, hgpio5, hgpio6, hgpio7, bu4, bu4b, bu5, bu5b,
+ bu6, gpo187 ]
+
+ dependencies:
+ groups: [ function ]
+ function: [ groups ]
+
+ additionalProperties: false
+
+ '^pin':
+ $ref: pincfg-node.yaml#
+
+ properties:
+ pins:
+ description:
+ A list of pins to configure in certain ways, such as enabling
+ debouncing
+ items:
+ pattern: '^GPIO([0-9]|[0-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-6])'
+
+ bias-disable: true
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ input-enable: true
+
+ output-low: true
+
+ output-high: true
+
+ drive-push-pull: true
+
+ drive-open-drain: true
+
+ input-debounce:
+ description:
+ Debouncing periods in microseconds, one period per interrupt
+ bank found in the controller
+ minItems: 1
+ maxItems: 4
+
+ slew-rate:
+ description: |
+ 0: Low rate
+ 1: High rate
+ enum: [0, 1]
+
+ drive-strength:
+ enum: [ 0, 1, 2, 4, 8, 12 ]
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - ranges
+ - '#address-cells'
+ - '#size-cells'
+ - nuvoton,sysgcr
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pinctrl: pinctrl@f0010000 {
+ compatible = "nuvoton,npcm845-pinctrl";
+ ranges = <0x0 0x0 0xf0010000 0x8000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nuvoton,sysgcr = <&gcr>;
+
+ gpio0: gpio@0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x0 0xb0>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-ranges = <&pinctrl 0 0 32>;
+ };
+
+ fanin0_pin: fanin0-mux {
+ groups = "fanin0";
+ function = "fanin0";
+ };
+
+ pin34_slew: pin34-slew {
+ pins = "GPIO34/I3C4_SDA";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml
index 7a11beb8f222..08442c880f07 100644
--- a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml
@@ -30,6 +30,7 @@ patternProperties:
"^gpio@[0-7]$":
type: object
+ additionalProperties: false
description:
Eight GPIO banks (gpio@0 to gpio@7), that each contain between 14 and 18
@@ -102,7 +103,8 @@ patternProperties:
items:
pattern: "^gpio1?[0-9]{1,2}$"
- input-debounce: true
+ input-debounce:
+ maxItems: 1
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml
new file mode 100644
index 000000000000..96c608bcb87e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-pinmux-common.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra-pinmux-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jonathan Hunter <jonathanh@nvidia.com>
+
+description: |
+ Please refer to pinctrl-bindings.txt in this directory for details of the
+ common pinctrl bindings used by client devices, including the meaning of
+ the phrase "pin configuration node".
+
+ Tegra's pin configuration nodes act as a container for an arbitrary number
+ of subnodes. Each of these subnodes represents some desired configuration
+ for a pin, a group, or a list of pins or groups. This configuration can
+ include the mux function to select on those pin(s)/ group(s), and various
+ pin configuration parameters, such as pull-up, tristate, drive strength,
+ etc.
+
+ The name of each subnode is not important; all subnodes should be
+ enumerated and processed purely based on their content.
+
+ Each subnode only affects those parameters that are explicitly listed. In
+ other words, a subnode that lists a mux function but no pin configuration
+ parameters implies no information about any pin configuration parameters.
+
+ Similarly, a pin subnode that describes a pullup parameter implies no
+ information about e.g. the mux function or tristate parameter. For this
+ reason, even seemingly boolean values are actually tristates in this
+ binding: unspecified, off, or on. Unspecified is represented as an absent
+ property, and off/on are represented as integer values 0 and 1.
+
+ Note that many of these properties are only valid for certain specific pins
+ or groups. See the Tegra TRM and various pinmux spreadsheets for complete
+ details regarding which groups support which functionality. The Linux
+ pinctrl driver may also be a useful reference, since it consolidates,
+ disambiguates, and corrects data from all those sources.
+
+properties:
+ nvidia,pins:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: An array of strings. Each string contains the name of a pin
+ or group. Valid values for these names are listed below.
+
+ nvidia,function:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: A string containing the name of the function to mux to the
+ pin or group. Valid values for function names are listed below. See the
+ Tegra TRM to determine which are valid for each pin or group.
+
+ nvidia,pull:
+ description: Pull-down/up setting to apply to the pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: none
+ const: 0
+ - description: down
+ const: 1
+ - description: up
+ const: 2
+
+ nvidia,tristate:
+ description: Tristate setting to apply to the pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: drive
+ const: 0
+ - description: tristate
+ const: 1
+
+ nvidia,schmitt:
+ description: Enable Schmitt trigger on the input.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: disable Schmitt trigger on the input
+ const: 0
+ - description: enable Schmitt trigger on the input
+ const: 1
+
+ nvidia,pull-down-strength:
+ description: Controls drive strength. 0 is weakest. The range of valid
+ values depends on the pingroup. See "CAL_DRVDN" in the Tegra TRM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ nvidia,pull-up-strength:
+ description: Controls drive strength. 0 is weakest. The range of valid
+ values depends on the pingroup. See "CAL_DRVUP" in the Tegra TRM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ nvidia,high-speed-mode:
+ description: Enable high speed mode the pins.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: normal speed mode
+ const: 0
+ - description: high speed mode
+ const: 1
+
+ nvidia,low-power-mode:
+ description: Controls the drive power or current. Valid values are from 0
+ through 3, where 0 specifies the least power and 3 specifies the most
+ power. See "Low Power Mode" or "LPMD1" and "LPMD0" in the Tegra TRM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ nvidia,enable-input:
+ description: Enable the pin's input path.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: disable input (i.e. output only)
+ const: 0
+ - description: enable input
+ const: 1
+
+ nvidia,open-drain:
+ description: Open-drain configuration for the pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: disable open-drain
+ const: 0
+ - description: enable open-drain
+ const: 1
+
+ nvidia,lock:
+ description: Lock the pin configuration against further changes until
+ reset.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: disable pin configuration lock
+ const: 0
+ - description: enable pin configuration lock
+ const: 1
+
+ nvidia,io-reset:
+ description: reset the I/O path
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+
+ nvidia,rcv-sel:
+ description: select VIL/VIH receivers
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: normal receivers
+ const: 0
+ - description: high-voltage receivers
+ const: 1
+
+ nvidia,drive-type:
+ description: Drive type to configure for the pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ nvidia,io-hv:
+ description: Select high-voltage receivers.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - description: Use normal receivers.
+ const: 0
+ - description: Use high-voltage receivers.
+ const: 1
+
+ nvidia,slew-rate-rising:
+ description: Controls rising signal slew rate. 0 is fastest. The range of
+ valid values depends on the pingroup. See "DRVDN_SLWR" in the Tegra TRM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ nvidia,slew-rate-falling:
+ description: Controls falling signal slew rate. 0 is fastest. The range of
+ valid values depends on the pingroup. See "DRVUP_SLWF" in the Tegra TRM.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt
deleted file mode 100644
index fb70856c5b51..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt
+++ /dev/null
@@ -1,131 +0,0 @@
-NVIDIA Tegra114 pinmux controller
-
-The Tegra114 pinctrl binding is very similar to the Tegra20 and Tegra30
-pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
-nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
-a baseline, and only documents the differences between the two bindings.
-
-Required properties:
-- compatible: "nvidia,tegra114-pinmux"
-- reg: Should contain the register physical address and length for each of
- the pad control and mux registers. The first bank of address must be the
- driver strength pad control register address and second bank address must
- be pinmux register address.
-
-Tegra114 adds the following optional properties for pin configuration subnodes:
-- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes.
-- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes.
-- nvidia,lock: Integer. Lock the pin configuration against further changes
- until reset. 0: no, 1: yes.
-- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes.
-- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high.
-- nvidia,drive-type: Integer. Valid range 0...3.
-
-As with Tegra20 and Terga30, see the Tegra TRM for complete details regarding
-which groups support which functionality.
-
-Valid values for pin and group names are:
-
- per-pin mux groups:
-
- These all support nvidia,function, nvidia,tristate, nvidia,pull,
- nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain,
- nvidia,io-reset and nvidia,rcv-sel.
-
- ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
- ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
- ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
- dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
- sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
- sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
- ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
- uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
- uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_sda_pc5,
- gen1_i2c_scl_pc4, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7,
- clk3_out_pee0, clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7,
- gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, gmi_cs2_n_pk3,
- gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, gmi_cs7_n_pi6, gmi_ad0_pg0,
- gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5,
- gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
- gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7,
- gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, gmi_a19_pk7, gmi_wr_n_pi0,
- gmi_oe_n_pi1, gmi_dqs_p_pj3, gmi_rst_n_pi4, gen2_i2c_scl_pt5,
- gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0,
- sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
- sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, cam_mclk_pcc0,
- pcc1, pbb0, cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
- pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1,
- kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6,
- kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_col0_pq0,
- kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
- kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, core_pwr_req,
- cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
- dap1_sclk_pn3, clk1_req_pee2, clk1_out_pw4, spdif_in_pk6, spdif_out_pk5,
- dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0,
- gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, gpio_x4_aud_px4,
- gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, sdmmc3_clk_pa6,
- sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5,
- sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2,
- gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, usb_vbus_en1_pn5,
- sdmmc3_clk_lb_in_pee5, sdmmc3_clk_lb_out_pee4, reset_out_n.
-
- drive groups:
-
- These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
- nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
- support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode
- and nvidia,drive-type.
-
- ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4,
- dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg,
- gmh, owr, uda.
-
-Valid values for nvidia,functions are:
-
- blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya,
- displaya_alt, displayb, dtv, emc_dll, extperiph1, extperiph2,
- extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr,
- i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc, nand, nand_alt, owr, pmi,
- pwm0, pwm1, pwm2, pwm3, pwron, reset_out_n, rsvd1, rsvd2, rsvd3,
- rsvd4, sdmmc1, sdmmc2, sdmmc3, sdmmc4, soc, spdif, spi1, spi2, spi3,
- spi4, spi5, spi6, sysclk, trace, uarta, uartb, uartc, uartd, ulpi,
- usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt3
-
-Example:
-
- pinmux: pinmux {
- compatible = "nvidia,tegra114-pinmux";
- reg = <0x70000868 0x148 /* Pad control registers */
- 0x70003000 0x40c>; /* PinMux registers */
- };
-
-Example board file extract:
-
- pinctrl {
- sdmmc4_default: pinmux {
- sdmmc4_clk_pcc4 {
- nvidia,pins = "sdmmc4_clk_pcc4",
- nvidia,function = "sdmmc4";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- };
- sdmmc4_dat0_paa0 {
- nvidia,pins = "sdmmc4_dat0_paa0",
- "sdmmc4_dat1_paa1",
- "sdmmc4_dat2_paa2",
- "sdmmc4_dat3_paa3",
- "sdmmc4_dat4_paa4",
- "sdmmc4_dat5_paa5",
- "sdmmc4_dat6_paa6",
- "sdmmc4_dat7_paa7";
- nvidia,function = "sdmmc4";
- nvidia,pull = <2>;
- nvidia,tristate = <0>;
- };
- };
- };
-
- sdhci@78000400 {
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc4_default>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml
new file mode 100644
index 000000000000..1690c0ef553a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra114-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra114 pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra114-pinmux
+
+ reg:
+ items:
+ - description: pad control registers
+ - description: mux registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ additionalProperties: false
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3,
+ ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6,
+ ulpi_data6_po7, ulpi_data7_po0, ulpi_clk_py0, ulpi_dir_py1,
+ ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, dap3_din_pp1,
+ dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
+ sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5,
+ sdmmc1_dat1_py6, sdmmc1_dat0_py7, clk2_out_pw5,
+ clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, ddc_sda_pv5,
+ uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
+ uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7,
+ uart3_cts_n_pa1, uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4,
+ pu5, pu6, gen1_i2c_sda_pc5, gen1_i2c_scl_pc4, dap4_fs_pp4,
+ dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, clk3_out_pee0,
+ clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7,
+ gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2,
+ gmi_cs2_n_pk3, gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3,
+ gmi_cs7_n_pi6, gmi_ad0_pg0, gmi_ad1_pg1, gmi_ad2_pg2,
+ gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, gmi_ad6_pg6,
+ gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
+ gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6,
+ gmi_ad15_ph7, gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1,
+ gmi_a19_pk7, gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_p_pj3,
+ gmi_rst_n_pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6,
+ sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0,
+ sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3,
+ sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6,
+ sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0,
+ cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
+ pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0,
+ kb_row1_pr1, kb_row2_pr2, kb_row3_pr3, kb_row4_pr4,
+ kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, kb_row8_ps0,
+ kb_row9_ps1, kb_row10_ps2, kb_col0_pq0, kb_col1_pq1,
+ kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
+ kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5,
+ core_pwr_req, cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0,
+ dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, clk1_req_pee2,
+ clk1_out_pw4, spdif_in_pk6, spdif_out_pk5, dap2_fs_pa2,
+ dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0,
+ gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2,
+ gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6,
+ gpio_x7_aud_px7, sdmmc3_clk_pa6, sdmmc3_cmd_pa7,
+ sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5,
+ sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3,
+ sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3,
+ usb_vbus_en0_pn4, usb_vbus_en1_pn5, sdmmc3_clk_lb_in_pee5,
+ sdmmc3_clk_lb_out_pee4, reset_out_n,
+ # drive groups
+ drive_ao1, drive_ao2, drive_at1, drive_at2, drive_at3,
+ drive_at4, drive_at5, drive_cdev1, drive_cdev2, drive_dap1,
+ drive_dap2, drive_dap3, drive_dap4, drive_dbg, drive_sdio3,
+ drive_spi, drive_uaa, drive_uab, drive_uart2, drive_uart3,
+ drive_sdio1, drive_ddc, drive_gma, drive_gme, drive_gmf,
+ drive_gmg, drive_gmh, drive_owr, drive_uda ]
+
+ nvidia,function:
+ enum: [ blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3,
+ displaya, displaya_alt, displayb, dtv, emc_dll, extperiph1,
+ extperiph2, extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2,
+ i2c3, i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc,
+ nand, nand_alt, owr, pmi, pwm0, pwm1, pwm2, pwm3, pwron,
+ reset_out_n, rsvd1, rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2,
+ sdmmc3, sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5,
+ spi6, sysclk, trace, uarta, uartb, uartc, uartd, ulpi, usb,
+ vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt3 ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,pull-down-strength: true
+ nvidia,pull-up-strength: true
+ nvidia,high-speed-mode: true
+ nvidia,low-power-mode: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,io-reset: true
+ nvidia,rcv-sel: true
+ nvidia,drive-type: true
+ nvidia,slew-rate-rising: true
+ nvidia,slew-rate-falling: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ pinmux@70000868 {
+ compatible = "nvidia,tegra114-pinmux";
+ reg = <0x70000868 0x148>, /* Pad control registers */
+ <0x70003000 0x40c>; /* PinMux registers */
+
+ pinmux {
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = "sdmmc4_clk_pcc4";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <0>;
+ nvidia,tristate = <0>;
+ };
+
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = "sdmmc4_dat0_paa0",
+ "sdmmc4_dat1_paa1",
+ "sdmmc4_dat2_paa2",
+ "sdmmc4_dat3_paa3",
+ "sdmmc4_dat4_paa4",
+ "sdmmc4_dat5_paa5",
+ "sdmmc4_dat6_paa6",
+ "sdmmc4_dat7_paa7";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <2>;
+ nvidia,tristate = <0>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
deleted file mode 100644
index f4d06bb0b55a..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
+++ /dev/null
@@ -1,153 +0,0 @@
-NVIDIA Tegra124 pinmux controller
-
-The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30
-pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
-nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
-a baseline, and only documents the differences between the two bindings.
-
-Required properties:
-- compatible: For Tegra124, must contain "nvidia,tegra124-pinmux". For
- Tegra132, must contain '"nvidia,tegra132-pinmux", "nvidia-tegra124-pinmux"'.
-- reg: Should contain a list of base address and size pairs for:
- -- first entry - the drive strength and pad control registers.
- -- second entry - the pinmux registers
- -- third entry - the MIPI_PAD_CTRL register
-
-Tegra124 adds the following optional properties for pin configuration subnodes.
-The macros for options are defined in the
- include/dt-binding/pinctrl/pinctrl-tegra.h.
-- nvidia,enable-input: Integer. Enable the pin's input path.
- enable :TEGRA_PIN_ENABLE and
- disable or output only: TEGRA_PIN_DISABLE.
-- nvidia,open-drain: Integer.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,lock: Integer. Lock the pin configuration against further changes
- until reset.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,io-reset: Integer. Reset the IO path.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,rcv-sel: Integer. Select VIL/VIH receivers.
- normal: TEGRA_PIN_DISABLE
- high: TEGRA_PIN_ENABLE
-
-Please refer the Tegra TRM for complete details regarding which groups
-support which functionality.
-
-Valid values for pin and group names are:
-
- per-pin mux groups:
-
- These all support nvidia,function, nvidia,tristate, nvidia,pull,
- nvidia,enable-input. Some support nvidia,lock nvidia,open-drain,
- nvidia,io-reset and nvidia,rcv-sel.
-
- ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
- ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
- ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
- dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
- sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
- sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
- ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
- uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
- uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_scl_pc4,
- gen1_i2c_sda_pc5, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6,
- dap4_sclk_pp7, clk3_out_pee0, clk3_req_pee1, pc7, pi5, pi7, pk0, pk1,
- pj0, pj2, pk3, pk4, pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6,
- pg7, ph0, ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0,
- pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, sdmmc4_clk_pcc4,
- sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, sdmmc4_dat2_paa2,
- sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6,
- sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, cam_i2c_scl_pbb1,
- cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, pcc2, jtag_rtck,
- pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2,
- kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7,
- kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4,
- kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, kb_col0_pq0, kb_col1_pq1,
- kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, kb_col6_pq6,
- kb_col7_pq7, clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n,
- clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
- dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, spdif_in_pk6,
- spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3,
- dvfs_pwm_px0, gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2,
- gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7,
- sdmmc3_clk_pa6, sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6,
- sdmmc3_dat2_pb5, sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1,
- pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3, pex_l1_rst_n_pdd5,
- pex_l1_clkreq_n_pdd6, hdmi_cec_pee3, sdmmc1_wp_n_pv3,
- sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4,
- usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4, sdmmc3_clk_lb_in_pee5,
- gmi_clk_lb, reset_out_n, kb_row16_pt0, kb_row17_pt1, usb_vbus_en2_pff1,
- pff2, dp_hpd_pff0,
-
- drive groups:
-
- These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
- nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
- support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode
- and nvidia,drive-type.
-
- ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4,
- dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg,
- gmh, owr, uda, gpv, dev3, cec, usb_vbus_en, ao3, ao0, hv0, sdio4, ao4.
-
- MIPI pad control groups:
-
- These support only the nvidia,function property.
-
- dsi_b
-
-Valid values for nvidia,functions are:
-
- blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya,
- displaya_alt, displayb, dtv, extperiph1, extperiph2, extperiph3,
- gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, i2s0,
- i2s1, i2s2, i2s3, i2s4, irda, kbc, owr, pmi, pwm0, pwm1, pwm2, pwm3,
- pwron, reset_out_n, rsvd1, rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, sdmmc3,
- sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta,
- uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6,
- vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla, pe0, pe, pe1,
- dp, rtck, sys, clk tmds, csi, dsi_b
-
-Example:
-
- pinmux: pinmux {
- compatible = "nvidia,tegra124-pinmux";
- reg = <0x0 0x70000868 0x0 0x164>, /* Pad control registers */
- <0x0 0x70003000 0x0 0x434>, /* Mux registers */
- <0x0 0x70000820 0x0 0x8>; /* MIPI pad control */
- };
-
-Example pinmux entries:
-
- pinctrl {
- sdmmc4_default: pinmux {
- sdmmc4_clk_pcc4 {
- nvidia,pins = "sdmmc4_clk_pcc4",
- nvidia,function = "sdmmc4";
- nvidia,pull = <TEGRA_PIN_PULL_NONE>;
- nvidia,tristate = <TEGRA_PIN_DISABLE>;
- };
-
- sdmmc4_dat0_paa0 {
- nvidia,pins = "sdmmc4_dat0_paa0",
- "sdmmc4_dat1_paa1",
- "sdmmc4_dat2_paa2",
- "sdmmc4_dat3_paa3",
- "sdmmc4_dat4_paa4",
- "sdmmc4_dat5_paa5",
- "sdmmc4_dat6_paa6",
- "sdmmc4_dat7_paa7";
- nvidia,function = "sdmmc4";
- nvidia,pull = <TEGRA_PIN_PULL_UP>;
- nvidia,tristate = <TEGRA_PIN_DISABLE>;
- };
- };
- };
-
- sdhci@78000400 {
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc4_default>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml
new file mode 100644
index 000000000000..9b7368bd3862
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.yaml
@@ -0,0 +1,174 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra124-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra124 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The Tegra124 pinctrl binding is very similar to the Tegra20 and
+ Tegra30 pinctrl binding, as described in nvidia,tegra20-pinmux.yaml and
+ nvidia,tegra30-pinmux.yaml. In fact, this document assumes that binding as a
+ baseline, and only documents the differences between the two bindings.
+
+properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra124-pinmux
+ - items:
+ - const: nvidia,tegra132-pinmux
+ - const: nvidia,tegra124-pinmux
+
+ reg:
+ items:
+ - description: driver strength and pad control registers
+ - description: pinmux registers
+ - description: MIPI_PAD_CTRL registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ additionalProperties: false
+ properties:
+ nvidia,pins:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ enum: [ ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3,
+ ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6,
+ ulpi_data6_po7, ulpi_data7_po0, ulpi_clk_py0, ulpi_dir_py1,
+ ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, dap3_din_pp1,
+ dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
+ sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5,
+ sdmmc1_dat1_py6, sdmmc1_dat0_py7, clk2_out_pw5,
+ clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, ddc_sda_pv5,
+ uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
+ uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7,
+ uart3_cts_n_pa1, uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4,
+ pu5, pu6, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, dap4_fs_pp4,
+ dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, clk3_out_pee0,
+ clk3_req_pee1, pc7, pi5, pi7, pk0, pk1, pj0, pj2, pk3, pk4,
+ pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6, pg7, ph0,
+ ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0,
+ pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6,
+ sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0,
+ sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3,
+ sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6,
+ sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0,
+ cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
+ pbb7, pcc2, jtag_rtck, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7,
+ kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, kb_row3_pr3,
+ kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7,
+ kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3,
+ kb_row12_ps4, kb_row13_ps5, kb_row14_ps6, kb_row15_ps7,
+ kb_col0_pq0, kb_col1_pq1, kb_col2_pq2, kb_col3_pq3,
+ kb_col4_pq4, kb_col5_pq5, kb_col6_pq6, kb_col7_pq7,
+ clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n,
+ clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
+ dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4,
+ spdif_in_pk6, spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4,
+ dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0,
+ gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2,
+ gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6,
+ gpio_x7_aud_px7, sdmmc3_clk_pa6, sdmmc3_cmd_pa7,
+ sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5,
+ sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2,
+ pex_wake_n_pdd3, pex_l1_rst_n_pdd5, pex_l1_clkreq_n_pdd6,
+ hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2,
+ gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4,
+ usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4,
+ sdmmc3_clk_lb_in_pee5, gmi_clk_lb, reset_out_n,
+ kb_row16_pt0, kb_row17_pt1, usb_vbus_en2_pff1, pff2,
+ dp_hpd_pff0,
+ # drive groups
+ drive_ao1, drive_ao2, drive_at1, drive_at2, drive_at3,
+ drive_at4, drive_at5, drive_cdev1, drive_cdev2, drive_dap1,
+ drive_dap2, drive_dap3, drive_dap4, drive_dbg, drive_sdio3,
+ drive_spi, drive_uaa, drive_uab, drive_uart2, drive_uart3,
+ drive_sdio1, drive_ddc, drive_gma, drive_gme, drive_gmf,
+ drive_gmg, drive_gmh, drive_owr, drive_uda, drive_gpv,
+ drive_dev3, drive_cec, drive_usb_vbus_en, drive_ao3,
+ drive_ao0, drive_hv0, drive_sdio4, drive_ao4,
+ # MIPI pad control groups
+ mipi_pad_ctrl_dsi_b ]
+
+ nvidia,function:
+ enum: [ blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3,
+ displaya, displaya_alt, displayb, dtv, extperiph1,
+ extperiph2, extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2,
+ i2c3, i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc,
+ owr, pmi, pwm0, pwm1, pwm2, pwm3, pwron, reset_out_n, rsvd1,
+ rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, sdmmc3, sdmmc4, soc,
+ spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta,
+ uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5,
+ vgp6, vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla,
+ pe0, pe, pe1, dp, rtck, sys, clk, tmds, csi, dsi_b ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,pull-down-strength: true
+ nvidia,pull-up-strength: true
+ nvidia,high-speed-mode: true
+ nvidia,low-power-mode: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,io-reset: true
+ nvidia,rcv-sel: true
+ nvidia,drive-type: true
+ nvidia,slew-rate-rising: true
+ nvidia,slew-rate-falling: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@70000868 {
+ compatible = "nvidia,tegra124-pinmux";
+ reg = <0x70000868 0x164>, /* Pad control registers */
+ <0x70003000 0x434>, /* Mux registers */
+ <0x70000820 0x8>; /* MIPI pad control */
+
+ sdmmc4_default: pinmux {
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = "sdmmc4_clk_pcc4";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ };
+
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = "sdmmc4_dat0_paa0",
+ "sdmmc4_dat1_paa1",
+ "sdmmc4_dat2_paa2",
+ "sdmmc4_dat3_paa3",
+ "sdmmc4_dat4_paa4",
+ "sdmmc4_dat5_paa5",
+ "sdmmc4_dat6_paa6",
+ "sdmmc4_dat7_paa7";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra186-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra186-pinmux.yaml
new file mode 100644
index 000000000000..ac764d0ac4b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra186-pinmux.yaml
@@ -0,0 +1,285 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra186-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra186 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra186-pinmux
+ - nvidia,tegra186-pinmux-aon
+
+ reg:
+ items:
+ - description: pinmux registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ unevaluatedProperties: false
+ properties:
+ nvidia,function:
+ enum: [ aud, can0, can1, ccla, dca, dcb, dcc, directdc, directdc1,
+ displaya, displayb, dmic1, dmic2, dmic3, dmic4, dmic5, dp,
+ dspk0, dspk1, dtv, eqos, extperiph1, extperiph2, extperiph3,
+ extperiph4, gp, gpio, hdmi, i2c1, i2c2, i2c3, i2c5, i2c7,
+ i2c8, i2c9, i2s1, i2s2, i2s3, i2s4, i2s5, i2s6, iqc0, iqc1,
+ nv, pe, pe0, pe1, pe2, qspi, rsvd0, rsvd1, rsvd2, rsvd3,
+ sata, sce, sdmmc1, sdmmc2, sdmmc3, sdmmc4, soc, spdif, spi1,
+ spi2, spi3, spi4, touch, uarta, uartb, uartc, uartd, uarte,
+ uartf, uartg, ufs0, usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6,
+ wdt ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,drive-type: true
+ nvidia,io-hv: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra186-pinmux
+ then:
+ patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+ additionalProperties:
+ properties:
+ nvidia,pins:
+ description: An array of strings. Each string contains the name
+ of a pin or group. Valid values for these names are listed
+ below.
+ items:
+ enum: [ pex_l0_rst_n_pa0, pex_l0_clkreq_n_pa1,
+ pex_wake_n_pa2, pex_l1_rst_n_pa3,
+ pex_l1_clkreq_n_pa4, pex_l2_rst_n_pa5,
+ pex_l2_clkreq_n_pa6, uart4_tx_pb0, uart4_rx_pb1,
+ uart4_rts_pb2, uart4_cts_pb3, gpio_wan1_pb4,
+ gpio_wan2_pb5, gpio_wan3_pb6, gpio_wan4_pc0,
+ dap2_sclk_pc1, dap2_dout_pc2, dap2_din_pc3,
+ dap2_fs_pc4, gen1_i2c_scl_pc5, gen1_i2c_sda_pc6,
+ sdmmc1_clk_pd0, sdmmc1_cmd_pd1, sdmmc1_dat0_pd2,
+ sdmmc1_dat1_pd3, sdmmc1_dat2_pd4, sdmmc1_dat3_pd5,
+ eqos_txc_pe0, eqos_td0_pe1, eqos_td1_pe2,
+ eqos_td2_pe3, eqos_td3_pe4, eqos_tx_ctl_pe5,
+ eqos_rd0_pe6, eqos_rd1_pe7, eqos_rd2_pf0,
+ eqos_rd3_pf1, eqos_rx_ctl_pf2, eqos_rxc_pf3,
+ eqos_mdio_pf4, eqos_mdc_pf5, sdmmc3_clk_pg0,
+ sdmmc3_cmd_pg1, sdmmc3_dat0_pg2, sdmmc3_dat1_pg3,
+ sdmmc3_dat2_pg4, sdmmc3_dat3_pg5, gpio_wan5_ph0,
+ gpio_wan6_ph1, gpio_wan7_ph2, gpio_wan8_ph3,
+ bcpu_pwr_req_ph4, mcpu_pwr_req_ph5, gpu_pwr_req_ph6,
+ gpio_pq0_pi0, gpio_pq1_pi1, gpio_pq2_pi2,
+ gpio_pq3_pi3, gpio_pq4_pi4, gpio_pq5_pi5,
+ gpio_pq6_pi6, gpio_pq7_pi7, dap1_sclk_pj0,
+ dap1_dout_pj1, dap1_din_pj2, dap1_fs_pj3,
+ aud_mclk_pj4, gpio_aud0_pj5, gpio_aud1_pj6,
+ gpio_aud2_pj7, gpio_aud3_pk0, gen7_i2c_scl_pl0,
+ gen7_i2c_sda_pl1, gen9_i2c_scl_pl2, gen9_i2c_sda_pl3,
+ usb_vbus_en0_pl4, usb_vbus_en1_pl5, gp_pwm6_pl6,
+ gp_pwm7_pl7, dmic1_dat_pm0, dmic1_clk_pm1,
+ dmic2_dat_pm2, dmic2_clk_pm3, dmic4_dat_pm4,
+ dmic4_clk_pm5, gpio_cam1_pn0, gpio_cam2_pn1,
+ gpio_cam3_pn2, gpio_cam4_pn3, gpio_cam6_pn5,
+ gpio_cam7_pn6, extperiph1_clk_po0,
+ extperiph2_clk_po1, cam_i2c_scl_po2, cam_i2c_sda_po3,
+ dp_aux_ch0_hpd_pp0, dp_aux_ch1_hpd_pp1, hdmi_cec_pp2,
+ gpio_edp0_pp3, gpio_edp1_pp4, gpio_edp2_pp5,
+ gpio_edp3_pp6, directdc1_clk_pq0, directdc1_in_pq1,
+ directdc1_out0_pq2, directdc1_out1_pq3,
+ directdc1_out2_pq4, directdc1_out3_pq5,
+ qspi_sck_pr0, qspi_io0_pr1, qspi_io1_pr2,
+ qspi_io2_pr3, qspi_io3_pr4, qspi_cs_n_pr5,
+ uart1_tx_pt0, uart1_rx_pt1, uart1_rts_pt2,
+ uart1_cts_pt3, uart2_tx_px0, uart2_rx_px1,
+ uart2_rts_px2, uart2_cts_px3, uart5_tx_px4,
+ uart5_rx_px5, uart5_rts_px6, uart5_cts_px7,
+ gpio_mdm1_py0, gpio_mdm2_py1, gpio_mdm3_py2,
+ gpio_mdm4_py3, gpio_mdm5_py4, gpio_mdm6_py5,
+ gpio_mdm7_py6, ufs0_ref_clk_pbb0, ufs0_rst_pbb1,
+ dap4_sclk_pcc0, dap4_dout_pcc1, dap4_din_pcc2,
+ dap4_fs_pcc3, directdc_comp, sdmmc1_comp, eqos_comp,
+ sdmmc3_comp, qspi_comp,
+ # drive groups
+ drive_gpio_aud3_pk0, drive_gpio_aud2_pj7,
+ drive_gpio_aud1_pj6, drive_gpio_aud0_pj5,
+ drive_aud_mclk_pj4, drive_dap1_fs_pj3,
+ drive_dap1_din_pj2, drive_dap1_dout_pj1,
+ drive_dap1_sclk_pj0, drive_dmic1_clk_pm1,
+ drive_dmic1_dat_pm0, drive_dmic2_dat_pm2,
+ drive_dmic2_clk_pm3, drive_dmic4_dat_pm4,
+ drive_dmic4_clk_pm5, drive_dap4_fs_pcc3,
+ drive_dap4_din_pcc2, drive_dap4_dout_pcc1,
+ drive_dap4_sclk_pcc0, drive_extperiph2_clk_po1,
+ drive_extperiph1_clk_po0, drive_cam_i2c_sda_po3,
+ drive_cam_i2c_scl_po2, drive_gpio_cam1_pn0,
+ drive_gpio_cam2_pn1, drive_gpio_cam3_pn2,
+ drive_gpio_cam4_pn3, drive_gpio_cam5_pn4,
+ drive_gpio_cam6_pn5, drive_gpio_cam7_pn6,
+ drive_dap2_din_pc3, drive_dap2_dout_pc2,
+ drive_dap2_fs_pc4, drive_dap2_sclk_pc1,
+ drive_uart4_cts_pb3, drive_uart4_rts_pb2,
+ drive_uart4_rx_pb1, drive_uart4_tx_pb0,
+ drive_gpio_wan4_pc0, drive_gpio_wan3_pb6,
+ drive_gpio_wan2_pb5, drive_gpio_wan1_pb4,
+ drive_gen1_i2c_scl_pc5, drive_gen1_i2c_sda_pc6,
+ drive_uart1_cts_pt3, drive_uart1_rts_pt2,
+ drive_uart1_rx_pt1, drive_uart1_tx_pt0,
+ drive_directdc1_out3_pq5, drive_directdc1_out2_pq4,
+ drive_directdc1_out1_pq3, drive_directdc1_out0_pq2,
+ drive_directdc1_in_pq1, drive_directdc1_clk_pq0,
+ drive_gpio_pq0_pi0, drive_gpio_pq1_pi1,
+ drive_gpio_pq2_pi2, drive_gpio_pq3_pi3,
+ drive_gpio_pq4_pi4, drive_gpio_pq5_pi5,
+ drive_gpio_pq6_pi6, drive_gpio_pq7_pi7,
+ drive_gpio_edp2_pp5, drive_gpio_edp3_pp6,
+ drive_gpio_edp0_pp3, drive_gpio_edp1_pp4,
+ drive_dp_aux_ch0_hpd_pp0, drive_dp_aux_ch1_hpd_pp1,
+ drive_hdmi_cec_pp2, drive_pex_l2_clkreq_n_pa6,
+ drive_pex_wake_n_pa2, drive_pex_l1_clkreq_n_pa4,
+ drive_pex_l1_rst_n_pa3, drive_pex_l0_clkreq_n_pa1,
+ drive_pex_l0_rst_n_pa0, drive_pex_l2_rst_n_pa5,
+ drive_sdmmc1_clk_pd0, drive_sdmmc1_cmd_pd1,
+ drive_sdmmc1_dat3_pd5, drive_sdmmc1_dat2_pd4,
+ drive_sdmmc1_dat1_pd3, drive_sdmmc1_dat0_pd2,
+ drive_eqos_td3_pe4, drive_eqos_td2_pe3,
+ drive_eqos_td1_pe2, drive_eqos_td0_pe1,
+ drive_eqos_rd3_pf1, drive_eqos_rd2_pf0,
+ drive_eqos_rd1_pe7, drive_eqos_mdio_pf4,
+ drive_eqos_rd0_pe6, drive_eqos_mdc_pf5,
+ drive_eqos_txc_pe0, drive_eqos_rxc_pf3,
+ drive_eqos_tx_ctl_pe5, drive_eqos_rx_ctl_pf2,
+ drive_sdmmc3_dat3_pg5, drive_sdmmc3_dat2_pg4,
+ drive_sdmmc3_dat1_pg3, drive_sdmmc3_dat0_pg2,
+ drive_sdmmc3_cmd_pg1, drive_sdmmc3_clk_pg0,
+ drive_qspi_io3_pr4, drive_qspi_io2_pr3,
+ drive_qspi_io1_pr2, drive_qspi_io0_pr1,
+ drive_qspi_sck_pr0, drive_qspi_cs_n_pr5,
+ drive_gpio_wan8_ph3, drive_gpio_wan7_ph2,
+ drive_gpio_wan6_ph1, drive_gpio_wan5_ph0,
+ drive_uart2_tx_px0, drive_uart2_rx_px1,
+ drive_uart2_rts_px2, drive_uart2_cts_px3,
+ drive_uart5_rx_px5, drive_uart5_tx_px4,
+ drive_uart5_rts_px6, drive_uart5_cts_px7,
+ drive_gpio_mdm1_py0, drive_gpio_mdm2_py1,
+ drive_gpio_mdm3_py2, drive_gpio_mdm4_py3,
+ drive_gpio_mdm5_py4, drive_gpio_mdm6_py5,
+ drive_gpio_mdm7_py6, drive_bcpu_pwr_req_ph4,
+ drive_mcpu_pwr_req_ph5, drive_gpu_pwr_req_ph6,
+ drive_gen7_i2c_scl_pl0, drive_gen7_i2c_sda_pl1,
+ drive_gen9_i2c_sda_pl3, drive_gen9_i2c_scl_pl2,
+ drive_usb_vbus_en0_pl4, drive_usb_vbus_en1_pl5,
+ drive_gp_pwm7_pl7, drive_gp_pwm6_pl6,
+ drive_ufs0_rst_pbb1, drive_ufs0_ref_clk_pbb0,
+ drive_directdc_comp, drive_sdmmc1_comp,
+ drive_eqos_comp, drive_sdmmc3_comp, drive_sdmmc4_clk,
+ drive_sdmmc4_cmd, drive_sdmmc4_dqs,
+ drive_sdmmc4_dat7, drive_sdmmc4_dat6,
+ drive_sdmmc4_dat5, drive_sdmmc4_dat4,
+ drive_sdmmc4_dat3, drive_sdmmc4_dat2,
+ drive_sdmmc4_dat1, drive_sdmmc4_dat0,
+ drive_qspi_comp ]
+
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra186-pinmux-aon
+ then:
+ patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+ additionalProperties:
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ pwr_i2c_scl_ps0, pwr_i2c_sda_ps1, batt_oc_ps2,
+ safe_state_ps3, vcomp_alert_ps4, gpio_dis0_pu0,
+ gpio_dis1_pu1, gpio_dis2_pu2, gpio_dis3_pu3,
+ gpio_dis4_pu4, gpio_dis5_pu5, gpio_sen0_pv0,
+ gpio_sen1_pv1, gpio_sen2_pv2, gpio_sen3_pv3,
+ gpio_sen4_pv4, gpio_sen5_pv5, gpio_sen6_pv6,
+ gpio_sen7_pv7, gen8_i2c_scl_pw0, gen8_i2c_sda_pw1,
+ uart3_tx_pw2, uart3_rx_pw3, uart3_rts_pw4,
+ uart3_cts_pw5, uart7_tx_pw6, uart7_rx_pw7,
+ can1_dout_pz0, can1_din_pz1, can0_dout_pz2,
+ can0_din_pz3, can_gpio0_paa0, can_gpio1_paa1,
+ can_gpio2_paa2, can_gpio3_paa3, can_gpio4_paa4,
+ can_gpio5_paa5, can_gpio6_paa6, can_gpio7_paa7,
+ gpio_sen8_pee0, gpio_sen9_pee1, touch_clk_pee2,
+ power_on_pff0, gpio_sw1_pff1, gpio_sw2_pff2,
+ gpio_sw3_pff3, gpio_sw4_pff4, shutdown, pmu_int,
+ soc_pwr_req, clk_32k_in,
+ # drive groups
+ drive_touch_clk_pee2, drive_uart3_cts_pw5,
+ drive_uart3_rts_pw4, drive_uart3_rx_pw3,
+ drive_uart3_tx_pw2, drive_gen8_i2c_sda_pw1,
+ drive_gen8_i2c_scl_pw0, drive_uart7_rx_pw7,
+ drive_uart7_tx_pw6, drive_gpio_sen0_pv0,
+ drive_gpio_sen1_pv1, drive_gpio_sen2_pv2,
+ drive_gpio_sen3_pv3, drive_gpio_sen4_pv4,
+ drive_gpio_sen5_pv5, drive_gpio_sen6_pv6,
+ drive_gpio_sen7_pv7, drive_gpio_sen8_pee0,
+ drive_gpio_sen9_pee1, drive_can_gpio7_paa7,
+ drive_can1_dout_pz0, drive_can1_din_pz1,
+ drive_can0_dout_pz2, drive_can0_din_pz3,
+ drive_can_gpio0_paa0, drive_can_gpio1_paa1,
+ drive_can_gpio2_paa2, drive_can_gpio3_paa3,
+ drive_can_gpio4_paa4, drive_can_gpio5_paa5,
+ drive_can_gpio6_paa6, drive_gpio_sw1_pff1,
+ drive_gpio_sw2_pff2, drive_gpio_sw3_pff3,
+ drive_gpio_sw4_pff4, drive_shutdown, drive_pmu_int,
+ drive_safe_state_ps3, drive_vcomp_alert_ps4,
+ drive_soc_pwr_req, drive_batt_oc_ps2,
+ drive_clk_32k_in, drive_power_on_pff0,
+ drive_pwr_i2c_scl_ps0, drive_pwr_i2c_sda_ps1,
+ drive_gpio_dis0_pu0, drive_gpio_dis1_pu1,
+ drive_gpio_dis2_pu2, drive_gpio_dis3_pu3,
+ drive_gpio_dis4_pu4, drive_gpio_dis5_pu5 ]
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@2430000 {
+ compatible = "nvidia,tegra186-pinmux";
+ reg = <0x2430000 0x15000>;
+
+ pinctrl-names = "jetson_io";
+ pinctrl-0 = <&jetson_io_pinmux>;
+
+ jetson_io_pinmux: pinmux {
+ hdr40-pin7 {
+ nvidia,pins = "aud_mclk_pj4";
+ nvidia,function = "aud";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt
deleted file mode 100644
index 90d38f710635..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-NVIDIA Tegra194 pinmux controller
-
-Required properties:
-- compatible: "nvidia,tegra194-pinmux"
-- reg: Should contain a list of base address and size pairs for:
- - first entry: The APB_MISC_GP_*_PADCTRL registers (pad control)
- - second entry: The PINMUX_AUX_* registers (pinmux)
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Tegra's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, tristate, drive strength, etc.
-
-See the TRM to determine which properties and values apply to each pin/group.
-Macro values for property values are defined in
-include/dt-binding/pinctrl/pinctrl-tegra.h.
-
-Required subnode-properties:
-- nvidia,pins : An array of strings. Each string contains the name of a pin or
- group. Valid values for these names are listed below.
-
-Optional subnode-properties:
-- nvidia,function: A string containing the name of the function to mux to the
- pin or group.
-- nvidia,pull: Integer, representing the pull-down/up to apply to the pin.
- 0: none, 1: down, 2: up.
-- nvidia,tristate: Integer.
- 0: drive, 1: tristate.
-- nvidia,enable-input: Integer. Enable the pin's input path.
- enable :TEGRA_PIN_ENABLE and
- disable or output only: TEGRA_PIN_DISABLE.
-- nvidia,open-drain: Integer.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,lock: Integer. Lock the pin configuration against further changes
- until reset.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,io-hv: Integer. Select high-voltage receivers.
- normal: TEGRA_PIN_DISABLE
- high: TEGRA_PIN_ENABLE
-- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input.
- normal: TEGRA_PIN_DISABLE
- high: TEGRA_PIN_ENABLE
-- nvidia,drive-type: Integer. Valid range 0...3.
-- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest.
- The range of valid values depends on the pingroup. See "CAL_DRVDN" in the
- Tegra TRM.
-- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest.
- The range of valid values depends on the pingroup. See "CAL_DRVUP" in the
- Tegra TRM.
-
-Valid values for pin and group names (nvidia,pin) are:
-
- These correspond to Tegra PADCTL_* (pinmux) registers.
-
- Mux groups:
-
- These correspond to Tegra PADCTL_* (pinmux) registers. Any property
- that exists in those registers may be set for the following pin names.
-
- pex_l5_clkreq_n_pgg0, pex_l5_rst_n_pgg1
-
- Drive groups:
-
- These registers controls a single pin for which a mux group exists.
- See the list above for the pin name to use when configuring the pinmux.
-
- pex_l5_clkreq_n_pgg0, pex_l5_rst_n_pgg1
-
-Valid values for nvidia,functions are:
-
- pe5
-
-Power Domain:
- pex_l5_clkreq_n_pgg0 and pex_l5_rst_n_pgg1 are part of PCIE C5 power
- partition. Client devices must enable this partition before accessing
- these pins here.
-
-
-Example:
-
- tegra_pinctrl: pinmux: pinmux@2430000 {
- compatible = "nvidia,tegra194-pinmux";
- reg = <0x2430000 0x17000
- 0xc300000 0x4000>;
-
- pinctrl-names = "pex_rst";
- pinctrl-0 = <&pex_rst_c5_out_state>;
-
- pex_rst_c5_out_state: pex_rst_c5_out {
- pex_rst {
- nvidia,pins = "pex_l5_rst_n_pgg1";
- nvidia,schmitt = <TEGRA_PIN_DISABLE>;
- nvidia,lpdr = <TEGRA_PIN_ENABLE>;
- nvidia,enable-input = <TEGRA_PIN_DISABLE>;
- nvidia,io-hv = <TEGRA_PIN_ENABLE>;
- nvidia,tristate = <TEGRA_PIN_DISABLE>;
- nvidia,pull = <TEGRA_PIN_PULL_NONE>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml
new file mode 100644
index 000000000000..87b6f4f42f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra194-pinmux.yaml
@@ -0,0 +1,282 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra194-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra194 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra194-pinmux
+ - nvidia,tegra194-pinmux-aon
+
+ reg:
+ items:
+ - description: pinmux registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ unevaluatedProperties: false
+ properties:
+ nvidia,function:
+ enum: [ aud, can0, can1, ccla, dca, dcb, dgpu, directdc, directdc1,
+ displaya, displayb, dmic1, dmic2, dmic3, dmic4, dmic5, dp,
+ dspk0, dspk1, eqos, extperiph1, extperiph2, extperiph3,
+ extperiph4, gp, gpio, hdmi, i2c1, i2c2, i2c3, i2c5, i2c8,
+ i2s1, i2s2, i2s3, i2s4, i2s5, i2s6, igpu, iqc1, iqc2, mipi,
+ nv, pe0, pe1, pe2, pe3, pe4, pe5, qspi, qspi0, qspi1, rsvd0,
+ rsvd1, rsvd2, rsvd3, sata, sce, sdmmc1, sdmmc3, sdmmc4, slvs,
+ soc, spdif, spi1, spi2, spi3, touch, uarta, uartb, uartc,
+ uartd, uarte, uartg, ufs0, usb, vgp1, vgp2, vgp3, vgp4, vgp5,
+ vgp6, wdt ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,drive-type: true
+ nvidia,io-hv: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra194-pinmux
+ then:
+ patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+ additionalProperties:
+ properties:
+ nvidia,pins:
+ description: An array of strings. Each string contains the name
+ of a pin or group. Valid values for these names are listed
+ below.
+
+ Note that the pex_l5_clkreq_n_pgg0 and pex_l5_rst_n_pgg1 pins
+ are part of PCIE C5 power partition. Client devices must
+ enable this partition before accessing the configuration for
+ these pins.
+ items:
+ enum: [ dap6_sclk_pa0, dap6_dout_pa1, dap6_din_pa2,
+ dap6_fs_pa3, dap4_sclk_pa4, dap4_dout_pa5,
+ dap4_din_pa6, dap4_fs_pa7, cpu_pwr_req_0_pb0,
+ cpu_pwr_req_1_pb1, qspi0_sck_pc0, qspi0_cs_n_pc1,
+ qspi0_io0_pc2, qspi0_io1_pc3, qspi0_io2_pc4,
+ qspi0_io3_pc5, qspi1_sck_pc6, qspi1_cs_n_pc7,
+ qspi1_io0_pd0, qspi1_io1_pd1, qspi1_io2_pd2,
+ qspi1_io3_pd3, eqos_txc_pe0, eqos_td0_pe1,
+ eqos_td1_pe2, eqos_td2_pe3, eqos_td3_pe4,
+ eqos_tx_ctl_pe5, eqos_rd0_pe6, eqos_rd1_pe7,
+ eqos_rd2_pf0, eqos_rd3_pf1, eqos_rx_ctl_pf2,
+ eqos_rxc_pf3, eqos_sma_mdio_pf4, eqos_sma_mdc_pf5,
+ soc_gpio00_pg0, soc_gpio01_pg1, soc_gpio02_pg2,
+ soc_gpio03_pg3, soc_gpio08_pg4, soc_gpio09_pg5,
+ soc_gpio10_pg6, soc_gpio11_pg7, soc_gpio12_ph0,
+ soc_gpio13_ph1, soc_gpio14_ph2, uart4_tx_ph3,
+ uart4_rx_ph4, uart4_rts_ph5, uart4_cts_ph6,
+ dap2_sclk_ph7, dap2_dout_pi0, dap2_din_pi1,
+ dap2_fs_pi2, gen1_i2c_scl_pi3, gen1_i2c_sda_pi4,
+ sdmmc1_clk_pj0, sdmmc1_cmd_pj1, sdmmc1_dat0_pj2,
+ sdmmc1_dat1_pj3, sdmmc1_dat2_pj4, sdmmc1_dat3_pj5,
+ pex_l0_clkreq_n_pk0, pex_l0_rst_n_pk1,
+ pex_l1_clkreq_n_pk2, pex_l1_rst_n_pk3,
+ pex_l2_clkreq_n_pk4, pex_l2_rst_n_pk5,
+ pex_l3_clkreq_n_pk6, pex_l3_rst_n_pk7,
+ pex_l4_clkreq_n_pl0, pex_l4_rst_n_pl1,
+ pex_wake_n_pl2, sata_dev_slp_pl3, dp_aux_ch0_hpd_pm0,
+ dp_aux_ch1_hpd_pm1, dp_aux_ch2_hpd_pm2,
+ dp_aux_ch3_hpd_pm3, hdmi_cec_pm4, soc_gpio50_pm5,
+ soc_gpio51_pm6, soc_gpio52_pm7, soc_gpio53_pn0,
+ soc_gpio54_pn1, soc_gpio55_pn2, sdmmc3_clk_po0,
+ sdmmc3_cmd_po1, sdmmc3_dat0_po2, sdmmc3_dat1_po3,
+ sdmmc3_dat2_po4, sdmmc3_dat3_po5, extperiph1_clk_pp0,
+ extperiph2_clk_pp1, cam_i2c_scl_pp2, cam_i2c_sda_pp3,
+ soc_gpio04_pp4, soc_gpio05_pp5, soc_gpio06_pp6,
+ soc_gpio07_pp7, soc_gpio20_pq0, soc_gpio21_pq1,
+ soc_gpio22_pq2, soc_gpio23_pq3, soc_gpio40_pq4,
+ soc_gpio41_pq5, soc_gpio42_pq6, soc_gpio43_pq7,
+ soc_gpio44_pr0, soc_gpio45_pr1, uart1_tx_pr2,
+ uart1_rx_pr3, uart1_rts_pr4, uart1_cts_pr5,
+ dap1_sclk_ps0, dap1_dout_ps1, dap1_din_ps2,
+ dap1_fs_ps3, aud_mclk_ps4, soc_gpio30_ps5,
+ soc_gpio31_ps6, soc_gpio32_ps7, soc_gpio33_pt0,
+ dap3_sclk_pt1, dap3_dout_pt2, dap3_din_pt3,
+ dap3_fs_pt4, dap5_sclk_pt5, dap5_dout_pt6,
+ dap5_din_pt7, dap5_fs_pu0, directdc1_clk_pv0,
+ directdc1_in_pv1, directdc1_out0_pv2,
+ directdc1_out1_pv3, directdc1_out2_pv4,
+ directdc1_out3_pv5, directdc1_out4_pv6,
+ directdc1_out5_pv7, directdc1_out6_pw0,
+ directdc1_out7_pw1, gpu_pwr_req_px0, cv_pwr_req_px1,
+ gp_pwm2_px2, gp_pwm3_px3, uart2_tx_px4, uart2_rx_px5,
+ uart2_rts_px6, uart2_cts_px7, spi3_sck_py0,
+ spi3_miso_py1, spi3_mosi_py2, spi3_cs0_py3,
+ spi3_cs1_py4, uart5_tx_py5, uart5_rx_py6,
+ uart5_rts_py7, uart5_cts_pz0, usb_vbus_en0_pz1,
+ usb_vbus_en1_pz2, spi1_sck_pz3, spi1_miso_pz4,
+ spi1_mosi_pz5, spi1_cs0_pz6, spi1_cs1_pz7,
+ ufs0_ref_clk_pff0, ufs0_rst_pff1,
+ pex_l5_clkreq_n_pgg0, pex_l5_rst_n_pgg1,
+ directdc_comp, sdmmc4_clk, sdmmc4_cmd, sdmmc4_dqs,
+ sdmmc4_dat7, sdmmc4_dat6, sdmmc4_dat5, sdmmc4_dat4,
+ sdmmc4_dat3, sdmmc4_dat2, sdmmc4_dat1, sdmmc4_dat0,
+ sdmmc1_comp, sdmmc1_hv_trim, sdmmc3_comp,
+ sdmmc3_hv_trim, eqos_comp, qspi_comp,
+ # drive groups
+ drive_soc_gpio33_pt0, drive_soc_gpio32_ps7,
+ drive_soc_gpio31_ps6, drive_soc_gpio30_ps5,
+ drive_aud_mclk_ps4, drive_dap1_fs_ps3,
+ drive_dap1_din_ps2, drive_dap1_dout_ps1,
+ drive_dap1_sclk_ps0, drive_dap3_fs_pt4,
+ drive_dap3_din_pt3, drive_dap3_dout_pt2,
+ drive_dap3_sclk_pt1, drive_dap5_fs_pu0,
+ drive_dap5_din_pt7, drive_dap5_dout_pt6,
+ drive_dap5_sclk_pt5, drive_dap6_fs_pa3,
+ drive_dap6_din_pa2, drive_dap6_dout_pa1,
+ drive_dap6_sclk_pa0, drive_dap4_fs_pa7,
+ drive_dap4_din_pa6, drive_dap4_dout_pa5,
+ drive_dap4_sclk_pa4, drive_extperiph2_clk_pp1,
+ drive_extperiph1_clk_pp0, drive_cam_i2c_sda_pp3,
+ drive_cam_i2c_scl_pp2, drive_soc_gpio40_pq4,
+ drive_soc_gpio41_pq5, drive_soc_gpio42_pq6,
+ drive_soc_gpio43_pq7, drive_soc_gpio44_pr0,
+ drive_soc_gpio45_pr1, drive_soc_gpio20_pq0,
+ drive_soc_gpio21_pq1, drive_soc_gpio22_pq2,
+ drive_soc_gpio23_pq3, drive_soc_gpio04_pp4,
+ drive_soc_gpio05_pp5, drive_soc_gpio06_pp6,
+ drive_soc_gpio07_pp7, drive_uart1_cts_pr5,
+ drive_uart1_rts_pr4, drive_uart1_rx_pr3,
+ drive_uart1_tx_pr2, drive_dap2_din_pi1,
+ drive_dap2_dout_pi0, drive_dap2_fs_pi2,
+ drive_dap2_sclk_ph7, drive_uart4_cts_ph6,
+ drive_uart4_rts_ph5, drive_uart4_rx_ph4,
+ drive_uart4_tx_ph3, drive_soc_gpio03_pg3,
+ drive_soc_gpio02_pg2, drive_soc_gpio01_pg1,
+ drive_soc_gpio00_pg0, drive_gen1_i2c_scl_pi3,
+ drive_gen1_i2c_sda_pi4, drive_soc_gpio08_pg4,
+ drive_soc_gpio09_pg5, drive_soc_gpio10_pg6,
+ drive_soc_gpio11_pg7, drive_soc_gpio12_ph0,
+ drive_soc_gpio13_ph1, drive_soc_gpio14_ph2,
+ drive_soc_gpio50_pm5, drive_soc_gpio51_pm6,
+ drive_soc_gpio52_pm7, drive_soc_gpio53_pn0,
+ drive_soc_gpio54_pn1, drive_soc_gpio55_pn2,
+ drive_dp_aux_ch0_hpd_pm0, drive_dp_aux_ch1_hpd_pm1,
+ drive_dp_aux_ch2_hpd_pm2, drive_dp_aux_ch3_hpd_pm3,
+ drive_hdmi_cec_pm4, drive_pex_l2_clkreq_n_pk4,
+ drive_pex_wake_n_pl2, drive_pex_l1_clkreq_n_pk2,
+ drive_pex_l1_rst_n_pk3, drive_pex_l0_clkreq_n_pk0,
+ drive_pex_l0_rst_n_pk1, drive_pex_l2_rst_n_pk5,
+ drive_pex_l3_clkreq_n_pk6, drive_pex_l3_rst_n_pk7,
+ drive_pex_l4_clkreq_n_pl0, drive_pex_l4_rst_n_pl1,
+ drive_sata_dev_slp_pl3, drive_pex_l5_clkreq_n_pgg0,
+ drive_pex_l5_rst_n_pgg1, drive_cpu_pwr_req_1_pb1,
+ drive_cpu_pwr_req_0_pb0, drive_sdmmc1_clk_pj0,
+ drive_sdmmc1_cmd_pj1, drive_sdmmc1_dat3_pj5,
+ drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3,
+ drive_sdmmc1_dat0_pj2, drive_sdmmc3_dat3_po5,
+ drive_sdmmc3_dat2_po4, drive_sdmmc3_dat1_po3,
+ drive_sdmmc3_dat0_po2, drive_sdmmc3_cmd_po1,
+ drive_sdmmc3_clk_po0, drive_gpu_pwr_req_px0,
+ drive_spi3_miso_py1, drive_spi1_cs0_pz6,
+ drive_spi3_cs0_py3, drive_spi1_miso_pz4,
+ drive_spi3_cs1_py4, drive_gp_pwm3_px3,
+ drive_gp_pwm2_px2, drive_spi1_sck_pz3,
+ drive_spi3_sck_py0, drive_spi1_cs1_pz7,
+ drive_spi1_mosi_pz5, drive_spi3_mosi_py2,
+ drive_cv_pwr_req_px1, drive_uart2_tx_px4,
+ drive_uart2_rx_px5, drive_uart2_rts_px6,
+ drive_uart2_cts_px7, drive_uart5_rx_py6,
+ drive_uart5_tx_py5, drive_uart5_rts_py7,
+ drive_uart5_cts_pz0, drive_usb_vbus_en0_pz1,
+ drive_usb_vbus_en1_pz2, drive_ufs0_rst_pff1,
+ drive_ufs0_ref_clk_pff0 ]
+
+ - if:
+ properties:
+ compatible:
+ const: nvidia,tegra194-pinmux-aon
+ then:
+ patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+ additionalProperties:
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ can1_dout_paa0, can1_din_paa1, can0_dout_paa2,
+ can0_din_paa3, can0_stb_paa4, can0_en_paa5,
+ can0_wake_paa6, can0_err_paa7, can1_stb_pbb0,
+ can1_en_pbb1, can1_wake_pbb2, can1_err_pbb3,
+ spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
+ spi2_cs0_pcc3, touch_clk_pcc4, uart3_tx_pcc5,
+ uart3_rx_pcc6, gen2_i2c_scl_pcc7, gen2_i2c_sda_pdd0,
+ gen8_i2c_scl_pdd1, gen8_i2c_sda_pdd2,
+ safe_state_pee0, vcomp_alert_pee1,
+ ao_retention_n_pee2, batt_oc_pee3, power_on_pee4,
+ pwr_i2c_scl_pee5, pwr_i2c_sda_pee6, sys_reset_n,
+ shutdown_n, pmu_int_n, soc_pwr_req, clk_32k_in,
+ # drive groups
+ drive_shutdown_n, drive_pmu_int_n,
+ drive_safe_state_pee0, drive_vcomp_alert_pee1,
+ drive_soc_pwr_req, drive_batt_oc_pee3,
+ drive_clk_32k_in, drive_power_on_pee4,
+ drive_pwr_i2c_scl_pee5, drive_pwr_i2c_sda_pee6,
+ drive_ao_retention_n_pee2, drive_touch_clk_pcc4,
+ drive_uart3_rx_pcc6, drive_uart3_tx_pcc5,
+ drive_gen8_i2c_sda_pdd2, drive_gen8_i2c_scl_pdd1,
+ drive_spi2_mosi_pcc2, drive_gen2_i2c_scl_pcc7,
+ drive_spi2_cs0_pcc3, drive_gen2_i2c_sda_pdd0,
+ drive_spi2_sck_pcc0, drive_spi2_miso_pcc1,
+ drive_can1_dout_paa0, drive_can1_din_paa1,
+ drive_can0_dout_paa2, drive_can0_din_paa3,
+ drive_can0_stb_paa4, drive_can0_en_paa5,
+ drive_can0_wake_paa6, drive_can0_err_paa7,
+ drive_can1_stb_pbb0, drive_can1_en_pbb1,
+ drive_can1_wake_pbb2, drive_can1_err_pbb3 ]
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@2430000 {
+ compatible = "nvidia,tegra194-pinmux";
+ reg = <0x2430000 0x17000>;
+
+ pinctrl-names = "pex_rst";
+ pinctrl-0 = <&pex_rst_c5_out_state>;
+
+ pex_rst_c5_out_state: pinmux-pex-rst-c5-out {
+ pex_rst {
+ nvidia,pins = "pex_l5_rst_n_pgg1";
+ nvidia,schmitt = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,io-hv = <TEGRA_PIN_ENABLE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt
deleted file mode 100644
index 3c8ce28baad6..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt
+++ /dev/null
@@ -1,143 +0,0 @@
-NVIDIA Tegra20 pinmux controller
-
-Required properties:
-- compatible: "nvidia,tegra20-pinmux"
-- reg: Should contain the register physical address and length for each of
- the tri-state, mux, pull-up/down, and pad control register sets.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Tegra's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, tristate, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function or tristate parameter. For this
-reason, even seemingly boolean values are actually tristates in this binding:
-unspecified, off, or on. Unspecified is represented as an absent property,
-and off/on are represented as integer values 0 and 1.
-
-Required subnode-properties:
-- nvidia,pins : An array of strings. Each string contains the name of a pin or
- group. Valid values for these names are listed below.
-
-Optional subnode-properties:
-- nvidia,function: A string containing the name of the function to mux to the
- pin or group. Valid values for function names are listed below. See the Tegra
- TRM to determine which are valid for each pin or group.
-- nvidia,pull: Integer, representing the pull-down/up to apply to the pin.
- 0: none, 1: down, 2: up.
-- nvidia,tristate: Integer.
- 0: drive, 1: tristate.
-- nvidia,high-speed-mode: Integer. Enable high speed mode the pins.
- 0: no, 1: yes.
-- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input.
- 0: no, 1: yes.
-- nvidia,low-power-mode: Integer. Valid values 0-3. 0 is least power, 3 is
- most power. Controls the drive power or current. See "Low Power Mode"
- or "LPMD1" and "LPMD0" in the Tegra TRM.
-- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest.
- The range of valid values depends on the pingroup. See "CAL_DRVDN" in the
- Tegra TRM.
-- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest.
- The range of valid values depends on the pingroup. See "CAL_DRVUP" in the
- Tegra TRM.
-- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is
- fastest. The range of valid values depends on the pingroup. See
- "DRVDN_SLWR" in the Tegra TRM.
-- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is
- fastest. The range of valid values depends on the pingroup. See
- "DRVUP_SLWF" in the Tegra TRM.
-
-Note that many of these properties are only valid for certain specific pins
-or groups. See the Tegra TRM and various pinmux spreadsheets for complete
-details regarding which groups support which functionality. The Linux pinctrl
-driver may also be a useful reference, since it consolidates, disambiguates,
-and corrects data from all those sources.
-
-Valid values for pin and group names are:
-
- mux groups:
-
- These all support nvidia,function, nvidia,tristate, and many support
- nvidia,pull.
-
- ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1, dap2, dap3, dap4,
- ddc, dta, dtb, dtc, dtd, dte, dtf, gma, gmb, gmc, gmd, gme, gpu, gpu7,
- gpv, hdint, i2cp, irrx, irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn,
- ld0, ld1, ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12, ld13,
- ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2, lhs, lm0, lm1, lpp,
- lpw0, lpw1, lpw2, lsc0, lsc1, lsck, lsda, lsdi, lspi, lvp0, lvp1, lvs,
- owc, pmc, pta, rm, sdb, sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi,
- spdo, spia, spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac, uad,
- uca, ucb, uda.
-
- tristate groups:
-
- These only support nvidia,pull.
-
- ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls, lc, ld17_0,
- ld19_18, ld21_20, ld23_22.
-
- drive groups:
-
- With some exceptions, these support nvidia,high-speed-mode,
- nvidia,schmitt, nvidia,low-power-mode, nvidia,pull-down-strength,
- nvidia,pull-up-strength, nvidia,slew-rate-rising, nvidia,slew-rate-falling.
-
- drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, drive_cdev2,
- drive_csus, drive_dap1, drive_dap2, drive_dap3, drive_dap4, drive_dbg,
- drive_lcd1, drive_lcd2, drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa,
- drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2, drive_xm2a,
- drive_xm2c, drive_xm2d, drive_xm2clk, drive_sdio1, drive_crt, drive_ddc,
- drive_gma, drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_owr,
- drive_uda.
-
-Valid values for nvidia,functions are:
-
- ahb_clk, apb_clk, audio_sync, crt, dap1, dap2, dap3, dap4, dap5,
- displaya, displayb, emc_test0_dll, emc_test1_dll, gmi, gmi_int,
- hdmi, i2cp, i2c1, i2c2, i2c3, ide, irda, kbc, mio, mipi_hs, nand,
- osc, owr, pcie, plla_out, pllc_out1, pllm_out1, pllp_out2, pllp_out3,
- pllp_out4, pwm, pwr_intr, pwr_on, rsvd1, rsvd2, rsvd3, rsvd4, rtck,
- sdio1, sdio2, sdio3, sdio4, sflash, spdif, spi1, spi2, spi2_alt,
- spi3, spi4, trace, twc, uarta, uartb, uartc, uartd, uarte, ulpi,
- vi, vi_sensor_clk, xio
-
-Example:
-
- pinctrl@70000000 {
- compatible = "nvidia,tegra20-pinmux";
- reg = < 0x70000014 0x10 /* Tri-state registers */
- 0x70000080 0x20 /* Mux registers */
- 0x700000a0 0x14 /* Pull-up/down registers */
- 0x70000868 0xa8 >; /* Pad control registers */
- };
-
-Example board file extract:
-
- pinctrl@70000000 {
- sdio4_default: sdio4_default {
- atb {
- nvidia,pins = "atb", "gma", "gme";
- nvidia,function = "sdio4";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- };
- };
- };
-
- sdhci@c8000600 {
- pinctrl-names = "default";
- pinctrl-0 = <&sdio4_default>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml
new file mode 100644
index 000000000000..63cd743a30e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra20-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra20-pinmux
+
+ reg:
+ items:
+ - description: tri-state registers
+ - description: mux register
+ - description: pull-up/down registers
+ - description: pad control registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ additionalProperties: false
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1,
+ dap2, dap3, dap4, ddc, dta, dtb, dtc, dtd, dte, dtf, gma,
+ gmb, gmc, gmd, gme, gpu, gpu7, gpv, hdint, i2cp, irrx,
+ irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn, ld0, ld1,
+ ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12,
+ ld13, ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2,
+ lhs, lm0, lm1, lpp, lpw0, lpw1, lpw2, lsc0, lsc1, lsck,
+ lsda, lsdi, lspi, lvp0, lvp1, lvs, owc, pmc, pta, rm, sdb,
+ sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi, spdo, spia,
+ spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac,
+ uad, uca, ucb, uda,
+ # tristate groups
+ ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls,
+ lc, ld17_0, ld19_18, ld21_20, ld23_22,
+ # drive groups
+ drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1,
+ drive_cdev2, drive_csus, drive_dap1, drive_dap2,
+ drive_dap3, drive_dap4, drive_dbg, drive_lcd1, drive_lcd2,
+ drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa,
+ drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2,
+ drive_xm2a, drive_xm2c, drive_xm2d, drive_xm2clk,
+ drive_sdio1, drive_crt, drive_ddc, drive_gma, drive_gmb,
+ drive_gmc, drive_gmd, drive_gme, drive_owr, drive_uda ]
+
+ nvidia,function:
+ enum: [ ahb_clk, apb_clk, audio_sync, crt, dap1, dap2, dap3, dap4,
+ dap5, displaya, displayb, emc_test0_dll, emc_test1_dll, gmi,
+ gmi_int, hdmi, i2cp, i2c1, i2c2, i2c3, ide, irda, kbc, mio,
+ mipi_hs, nand, osc, owr, pcie, plla_out, pllc_out1,
+ pllm_out1, pllp_out2, pllp_out3, pllp_out4, pwm, pwr_intr,
+ pwr_on, rsvd1, rsvd2, rsvd3, rsvd4, rtck, sdio1, sdio2,
+ sdio3, sdio4, sflash, spdif, spi1, spi2, spi2_alt, spi3,
+ spi4, trace, twc, uarta, uartb, uartc, uartd, uarte, ulpi,
+ vi, vi_sensor_clk, xio ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,pull-down-strength: true
+ nvidia,pull-up-strength: true
+ nvidia,high-speed-mode: true
+ nvidia,low-power-mode: true
+ nvidia,slew-rate-rising: true
+ nvidia,slew-rate-falling: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl@70000000 {
+ compatible = "nvidia,tegra20-pinmux";
+ reg = <0x70000014 0x10>, /* Tri-state registers */
+ <0x70000080 0x20>, /* Mux registers */
+ <0x700000a0 0x14>, /* Pull-up/down registers */
+ <0x70000868 0xa8>; /* Pad control registers */
+
+ pinmux {
+ atb {
+ nvidia,pins = "atb", "gma", "gme";
+ nvidia,function = "sdio4";
+ nvidia,pull = <0>;
+ nvidia,tristate = <0>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt
deleted file mode 100644
index 85f211436b8e..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt
+++ /dev/null
@@ -1,166 +0,0 @@
-NVIDIA Tegra210 pinmux controller
-
-Required properties:
-- compatible: "nvidia,tegra210-pinmux"
-- reg: Should contain a list of base address and size pairs for:
- - first entry: The APB_MISC_GP_*_PADCTRL registers (pad control)
- - second entry: The PINMUX_AUX_* registers (pinmux)
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Tegra's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, tristate, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function or tristate parameter. For this
-reason, even seemingly boolean values are actually tristates in this binding:
-unspecified, off, or on. Unspecified is represented as an absent property,
-and off/on are represented as integer values 0 and 1.
-
-See the TRM to determine which properties and values apply to each pin/group.
-Macro values for property values are defined in
-include/dt-binding/pinctrl/pinctrl-tegra.h.
-
-Required subnode-properties:
-- nvidia,pins : An array of strings. Each string contains the name of a pin or
- group. Valid values for these names are listed below.
-
-Optional subnode-properties:
-- nvidia,function: A string containing the name of the function to mux to the
- pin or group.
-- nvidia,pull: Integer, representing the pull-down/up to apply to the pin.
- 0: none, 1: down, 2: up.
-- nvidia,tristate: Integer.
- 0: drive, 1: tristate.
-- nvidia,enable-input: Integer. Enable the pin's input path.
- enable :TEGRA_PIN_ENABLE and
- disable or output only: TEGRA_PIN_DISABLE.
-- nvidia,open-drain: Integer.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,lock: Integer. Lock the pin configuration against further changes
- until reset.
- enable: TEGRA_PIN_ENABLE.
- disable: TEGRA_PIN_DISABLE.
-- nvidia,io-hv: Integer. Select high-voltage receivers.
- normal: TEGRA_PIN_DISABLE
- high: TEGRA_PIN_ENABLE
-- nvidia,high-speed-mode: Integer. Enable high speed mode the pins.
- normal: TEGRA_PIN_DISABLE
- high: TEGRA_PIN_ENABLE
-- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input.
- normal: TEGRA_PIN_DISABLE
- high: TEGRA_PIN_ENABLE
-- nvidia,drive-type: Integer. Valid range 0...3.
-- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest.
- The range of valid values depends on the pingroup. See "CAL_DRVDN" in the
- Tegra TRM.
-- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest.
- The range of valid values depends on the pingroup. See "CAL_DRVUP" in the
- Tegra TRM.
-- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is
- fastest. The range of valid values depends on the pingroup. See
- "DRVDN_SLWR" in the Tegra TRM.
-- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is
- fastest. The range of valid values depends on the pingroup. See
- "DRVUP_SLWF" in the Tegra TRM.
-
-Valid values for pin and group names (nvidia,pin) are:
-
- Mux groups:
-
- These correspond to Tegra PINMUX_AUX_* (pinmux) registers. Any property
- that exists in those registers may be set for the following pin names.
-
- In Tegra210, many pins also have a dedicated APB_MISC_GP_*_PADCTRL
- register. Where that is true, and property that exists in that register
- may also be set on the following pin names.
-
- als_prox_int_px3, ap_ready_pv5, ap_wake_bt_ph3, ap_wake_nfc_ph7,
- aud_mclk_pbb0, batt_bcl, bt_rst_ph4, bt_wake_ap_ph5, button_home_py1,
- button_power_on_px5, button_slide_sw_py0, button_vol_down_px7,
- button_vol_up_px6, cam1_mclk_ps0, cam1_pwdn_ps7, cam1_strobe_pt1,
- cam2_mclk_ps1, cam2_pwdn_pt0, cam_af_en_ps5, cam_flash_en_ps6,
- cam_i2c_scl_ps2, cam_i2c_sda_ps3, cam_rst_ps4cam_rst_ps4, clk_32k_in,
- clk_32k_out_py5, clk_req, core_pwr_req, cpu_pwr_req, dap1_din_pb1,
- dap1_dout_pb2, dap1_fs_pb0, dap1_sclk_pb3, dap2_din_paa2, dap2_dout_paa3,
- dap2_fs_paa0, dap2_sclk_paa1, dap4_din_pj5, dap4_dout_pj6, dap4_fs_pj4,
- dap4_sclk_pj7, dmic1_clk_pe0, dmic1_dat_pe1, dmic2_clk_pe2, dmic2_dat_pe3,
- dmic3_clk_pe4, dmic3_dat_pe5, dp_hpd0_pcc6, dvfs_clk_pbb2, dvfs_pwm_pbb1,
- gen1_i2c_scl_pj1, gen1_i2c_sda_pj0, gen2_i2c_scl_pj2, gen2_i2c_sda_pj3,
- gen3_i2c_scl_pf0, gen3_i2c_sda_pf1, gpio_x1_aud_pbb3, gpio_x3_aud_pbb4,
- gps_en_pi2, gps_rst_pi3, hdmi_cec_pcc0, hdmi_int_dp_hpd_pcc1, jtag_rtck,
- lcd_bl_en_pv1, lcd_bl_pwm_pv0, lcd_gpio1_pv3, lcd_gpio2_pv4, lcd_rst_pv2,
- lcd_te_py2, modem_wake_ap_px0, motion_int_px2, nfc_en_pi0, nfc_int_pi1,
- pa6, pcc7, pe6, pe7, pex_l0_clkreq_n_pa1, pex_l0_rst_n_pa0,
- pex_l1_clkreq_n_pa4, pex_l1_rst_n_pa3, pex_wake_n_pa2, ph6, pk0, pk1, pk2,
- pk3, pk4, pk5, pk6, pk7, pl0, pl1, pwr_i2c_scl_py3, pwr_i2c_sda_py4,
- pwr_int_n, pz0, pz1, pz2, pz3, pz4, pz5, qspi_cs_n_pee1, qspi_io0_pee2,
- qspi_io1_pee3, qspi_io2_pee4, qspi_io3_pee5, qspi_sck_pee0,
- sata_led_active_pa5, sdmmc1_clk_pm0, sdmmc1_cmd_pm1, sdmmc1_dat0_pm5,
- sdmmc1_dat1_pm4, sdmmc1_dat2_pm3, sdmmc1_dat3_pm2, sdmmc3_clk_pp0,
- sdmmc3_cmd_pp1, sdmmc3_dat0_pp5, sdmmc3_dat1_pp4, sdmmc3_dat2_pp3,
- sdmmc3_dat3_pp2, shutdown, spdif_in_pcc3, spdif_out_pcc2, spi1_cs0_pc3,
- spi1_cs1_pc4, spi1_miso_pc1, spi1_mosi_pc0, spi1_sck_pc2, spi2_cs0_pb7,
- spi2_cs1_pdd0, spi2_miso_pb5, spi2_mosi_pb4, spi2_sck_pb6, spi4_cs0_pc6,
- spi4_miso_pd0, spi4_mosi_pc7, spi4_sck_pc5, temp_alert_px4, touch_clk_pv7,
- touch_int_px1, touch_rst_pv6, uart1_cts_pu3, uart1_rts_pu2, uart1_rx_pu1,
- uart1_tx_pu0, uart2_cts_pg3, uart2_rts_pg2, uart2_rx_pg1, uart2_tx_pg0,
- uart3_cts_pd4, uart3_rts_pd3, uart3_rx_pd2, uart3_tx_pd1, uart4_cts_pi7,
- uart4_rts_pi6, uart4_rx_pi5, uart4_tx_pi4, usb_vbus_en0_pcc4,
- usb_vbus_en1_pcc5, wifi_en_ph0, wifi_rst_ph1, wifi_wake_ap_ph2
-
- Drive groups:
-
- These correspond to the Tegra APB_MISC_GP_*_PADCTRL (pad control)
- registers. Note that where one of these registers controls a single pin
- for which a PINMUX_AUX_* exists, see the list above for the pin name to
- use when configuring the pinmux.
-
- pa6, pcc7, pe6, pe7, ph6, pk0, pk1, pk2, pk3, pk4, pk5, pk6, pk7, pl0, pl1,
- pz0, pz1, pz2, pz3, pz4, pz5, sdmmc1, sdmmc2, sdmmc3, sdmmc4
-
-Valid values for nvidia,functions are:
-
- aud, bcl, blink, ccla, cec, cldvfs, clk, core, cpu, displaya, displayb,
- dmic1, dmic2, dmic3, dp, dtv, extperiph3, i2c1, i2c2, i2c3, i2cpmu, i2cvi,
- i2s1, i2s2, i2s3, i2s4a, i2s4b, i2s5a, i2s5b, iqc0, iqc1, jtag, pe, pe0,
- pe1, pmi, pwm0, pwm1, pwm2, pwm3, qspi, rsvd0, rsvd1, rsvd2, rsvd3, sata,
- sdmmc1, sdmmc3, shutdown, soc, sor0, sor1, spdif, spi1, spi2, spi3, spi4,
- sys, touch, uart, uarta, uartb, uartc, uartd, usb, vgp1, vgp2, vgp3, vgp4,
- vgp5, vgp6, vimclk, vimclk2
-
-Example:
-
- pinmux: pinmux@70000800 {
- compatible = "nvidia,tegra210-pinmux";
- reg = <0x0 0x700008d4 0x0 0x2a8>, /* Pad control registers */
- <0x0 0x70003000 0x0 0x1000>; /* Mux registers */
-
- pinctrl-names = "boot";
- pinctrl-0 = <&state_boot>;
-
- state_boot: pinmux {
- gen1_i2c_scl_pj1 {
- nvidia,pins = "gen1_i2c_scl_pj1",
- nvidia,function = "i2c1";
- nvidia,pull = <TEGRA_PIN_PULL_NONE>;
- nvidia,tristate = <TEGRA_PIN_DISABLE>;
- nvidia,enable-input = <TEGRA_PIN_ENABLE>;
- nvidia,open-drain = <TEGRA_PIN_ENABLE>;
- nvidia,io-hv = <TEGRA_PIN_ENABLE>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
new file mode 100644
index 000000000000..e99387a6da5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra210-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra210 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra210-pinmux
+
+ reg:
+ items:
+ - description: APB_MISC_GP_*_PADCTRL register (pad control)
+ - description: PINMUX_AUX_* registers (pinmux)
+
+patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ additionalProperties: false
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ als_prox_int_px3, ap_ready_pv5, ap_wake_bt_ph3,
+ ap_wake_nfc_ph7, aud_mclk_pbb0, batt_bcl, bt_rst_ph4,
+ bt_wake_ap_ph5, button_home_py1, button_power_on_px5,
+ button_slide_sw_py0, button_vol_down_px7,
+ button_vol_up_px6, cam1_mclk_ps0, cam1_pwdn_ps7,
+ cam1_strobe_pt1, cam2_mclk_ps1, cam2_pwdn_pt0,
+ cam_af_en_ps5, cam_flash_en_ps6, cam_i2c_scl_ps2,
+ cam_i2c_sda_ps3, cam_rst_ps4, clk_32k_in, clk_32k_out_py5,
+ clk_req, core_pwr_req, cpu_pwr_req, dap1_din_pb1,
+ dap1_dout_pb2, dap1_fs_pb0, dap1_sclk_pb3, dap2_din_paa2,
+ dap2_dout_paa3, dap2_fs_paa0, dap2_sclk_paa1, dap4_din_pj5,
+ dap4_dout_pj6, dap4_fs_pj4, dap4_sclk_pj7, dmic1_clk_pe0,
+ dmic1_dat_pe1, dmic2_clk_pe2, dmic2_dat_pe3, dmic3_clk_pe4,
+ dmic3_dat_pe5, dp_hpd0_pcc6, dvfs_clk_pbb2, dvfs_pwm_pbb1,
+ gen1_i2c_scl_pj1, gen1_i2c_sda_pj0, gen2_i2c_scl_pj2,
+ gen2_i2c_sda_pj3, gen3_i2c_scl_pf0, gen3_i2c_sda_pf1,
+ gpio_x1_aud_pbb3, gpio_x3_aud_pbb4, gps_en_pi2,
+ gps_rst_pi3, hdmi_cec_pcc0, hdmi_int_dp_hpd_pcc1,
+ jtag_rtck, lcd_bl_en_pv1, lcd_bl_pwm_pv0, lcd_gpio1_pv3,
+ lcd_gpio2_pv4, lcd_rst_pv2, lcd_te_py2, modem_wake_ap_px0,
+ motion_int_px2, nfc_en_pi0, nfc_int_pi1, pa6, pcc7, pe6,
+ pe7, pex_l0_clkreq_n_pa1, pex_l0_rst_n_pa0,
+ pex_l1_clkreq_n_pa4, pex_l1_rst_n_pa3, pex_wake_n_pa2, ph6,
+ pk0, pk1, pk2, pk3, pk4, pk5, pk6, pk7, pl0, pl1,
+ pwr_i2c_scl_py3, pwr_i2c_sda_py4, pwr_int_n, pz0, pz1, pz2,
+ pz3, pz4, pz5, qspi_cs_n_pee1, qspi_io0_pee2,
+ qspi_io1_pee3, qspi_io2_pee4, qspi_io3_pee5, qspi_sck_pee0,
+ sata_led_active_pa5, sdmmc1_clk_pm0, sdmmc1_cmd_pm1,
+ sdmmc1_dat0_pm5, sdmmc1_dat1_pm4, sdmmc1_dat2_pm3,
+ sdmmc1_dat3_pm2, sdmmc3_clk_pp0, sdmmc3_cmd_pp1,
+ sdmmc3_dat0_pp5, sdmmc3_dat1_pp4, sdmmc3_dat2_pp3,
+ sdmmc3_dat3_pp2, shutdown, spdif_in_pcc3, spdif_out_pcc2,
+ spi1_cs0_pc3, spi1_cs1_pc4, spi1_miso_pc1, spi1_mosi_pc0,
+ spi1_sck_pc2, spi2_cs0_pb7, spi2_cs1_pdd0, spi2_miso_pb5,
+ spi2_mosi_pb4, spi2_sck_pb6, spi4_cs0_pc6, spi4_miso_pd0,
+ spi4_mosi_pc7, spi4_sck_pc5, temp_alert_px4, touch_clk_pv7,
+ touch_int_px1, touch_rst_pv6, uart1_cts_pu3, uart1_rts_pu2,
+ uart1_rx_pu1, uart1_tx_pu0, uart2_cts_pg3, uart2_rts_pg2,
+ uart2_rx_pg1, uart2_tx_pg0, uart3_cts_pd4, uart3_rts_pd3,
+ uart3_rx_pd2, uart3_tx_pd1, uart4_cts_pi7, uart4_rts_pi6,
+ uart4_rx_pi5, uart4_tx_pi4, usb_vbus_en0_pcc4,
+ usb_vbus_en1_pcc5, wifi_en_ph0, wifi_rst_ph1,
+ wifi_wake_ap_ph2,
+ # drive groups
+ drive_pa6, drive_pcc7, drive_pe6, drive_pe7, drive_ph6,
+ drive_pk0, drive_pk1, drive_pk2, drive_pk3, drive_pk4,
+ drive_pk5, drive_pk6, drive_pk7, drive_pl0, drive_pl1,
+ drive_pz0, drive_pz1, drive_pz2, drive_pz3, drive_pz4,
+ drive_pz5, drive_sdmmc1, drive_sdmmc2, drive_sdmmc3,
+ drive_sdmmc4 ]
+
+ nvidia,function:
+ enum: [ aud, bcl, blink, ccla, cec, cldvfs, clk, core, cpu, displaya,
+ displayb, dmic1, dmic2, dmic3, dp, dtv, extperiph3, i2c1,
+ i2c2, i2c3, i2cpmu, i2cvi, i2s1, i2s2, i2s3, i2s4a, i2s4b,
+ i2s5a, i2s5b, iqc0, iqc1, jtag, pe, pe0, pe1, pmi, pwm0,
+ pwm1, pwm2, pwm3, qspi, rsvd0, rsvd1, rsvd2, rsvd3, sata,
+ sdmmc1, sdmmc3, shutdown, soc, sor0, sor1, spdif, spi1, spi2,
+ spi3, spi4, sys, touch, uart, uarta, uartb, uartc, uartd,
+ usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vimclk, vimclk2 ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,pull-down-strength: true
+ nvidia,pull-up-strength: true
+ nvidia,high-speed-mode: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,drive-type: true
+ nvidia,io-hv: true
+ nvidia,slew-rate-rising: true
+ nvidia,slew-rate-falling: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux: pinmux@70000800 {
+ compatible = "nvidia,tegra210-pinmux";
+ reg = <0x700008d4 0x02a8>, /* Pad control registers */
+ <0x70003000 0x1000>; /* Mux registers */
+
+ pinctrl-names = "boot";
+ pinctrl-0 = <&state_boot>;
+
+ state_boot: pinmux {
+ gen1_i2c_scl_pj1 {
+ nvidia,pins = "gen1_i2c_scl_pj1";
+ nvidia,function = "i2c1";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ nvidia,open-drain = <TEGRA_PIN_ENABLE>;
+ nvidia,io-hv = <TEGRA_PIN_ENABLE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
new file mode 100644
index 000000000000..db8224dfba2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-aon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 AON Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra234-pinmux-aon
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra234-pinmux-common.yaml
+
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ can0_dout_paa0, can0_din_paa1, can1_dout_paa2,
+ can1_din_paa3, can0_stb_paa4, can0_en_paa5,
+ soc_gpio49_paa6, can0_err_paa7, can1_stb_pbb0,
+ can1_en_pbb1, soc_gpio50_pbb2, can1_err_pbb3,
+ spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
+ spi2_cs0_pcc3, touch_clk_pcc4, uart3_tx_pcc5,
+ uart3_rx_pcc6, gen2_i2c_scl_pcc7, gen2_i2c_sda_pdd0,
+ gen8_i2c_scl_pdd1, gen8_i2c_sda_pdd2,
+ sce_error_pee0, vcomp_alert_pee1,
+ ao_retention_n_pee2, batt_oc_pee3, power_on_pee4,
+ soc_gpio26_pee5, soc_gpio27_pee6, bootv_ctl_n_pee7,
+ hdmi_cec_pgg0,
+ # drive groups
+ drive_touch_clk_pcc4, drive_uart3_rx_pcc6,
+ drive_uart3_tx_pcc5, drive_gen8_i2c_sda_pdd2,
+ drive_gen8_i2c_scl_pdd1, drive_spi2_mosi_pcc2,
+ drive_gen2_i2c_scl_pcc7, drive_spi2_cs0_pcc3,
+ drive_gen2_i2c_sda_pdd0, drive_spi2_sck_pcc0,
+ drive_spi2_miso_pcc1, drive_can1_dout_paa2,
+ drive_can1_din_paa3, drive_can0_dout_paa0,
+ drive_can0_din_paa1, drive_can0_stb_paa4,
+ drive_can0_en_paa5, drive_soc_gpio49_paa6,
+ drive_can0_err_paa7, drive_can1_stb_pbb0,
+ drive_can1_en_pbb1, drive_soc_gpio50_pbb2,
+ drive_can1_err_pbb3, drive_sce_error_pee0,
+ drive_batt_oc_pee3, drive_bootv_ctl_n_pee7,
+ drive_power_on_pee4, drive_soc_gpio26_pee5,
+ drive_soc_gpio27_pee6, drive_ao_retention_n_pee2,
+ drive_vcomp_alert_pee1, drive_hdmi_cec_pgg0 ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@c300000 {
+ compatible = "nvidia,tegra234-pinmux-aon";
+ reg = <0xc300000 0x4000>;
+
+ pinctrl-names = "cec";
+ pinctrl-0 = <&cec_state>;
+
+ cec_state: pinmux-cec {
+ cec {
+ nvidia,pins = "hdmi_cec_pgg0";
+ nvidia,function = "gp";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml
new file mode 100644
index 000000000000..8cf9e4c915ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-common.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+$ref: nvidia,tegra-pinmux-common.yaml
+
+properties:
+ nvidia,function:
+ enum: [ gp, uartc, i2c8, spi2, i2c2, can1, can0, rsvd0, eth0, eth2,
+ eth1, dp, eth3, i2c4, i2c7, i2c9, eqos, pe2, pe1, pe0, pe3,
+ pe4, pe5, pe6, pe7, pe8, pe9, pe10, qspi0, qspi1, qpsi,
+ sdmmc1, sce, soc, gpio, hdmi, ufs0, spi3, spi1, uartb, uarte,
+ usb, extperiph2, extperiph1, i2c3, vi0, i2c5, uarta, uartd,
+ i2c1, i2s4, i2s6, aud, spi5, touch, uartj, rsvd1, wdt, tsc,
+ dmic3, led, vi0_alt, i2s5, nv, extperiph3, extperiph4, spi4,
+ ccla, i2s1, i2s2, i2s3, i2s8, rsvd2, dmic5, dca, displayb,
+ displaya, vi1, dcb, dmic1, dmic4, i2s7, dmic2, dspk0, rsvd3,
+ tsc_alt, istctrl, vi1_alt, dspk1, igpu ]
+
+ # out of the common properties, only these are allowed for Tegra234
+ nvidia,pins: true
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,drive-type: true
+ nvidia,io-hv: true
+
+required:
+ - nvidia,pins
+
+# We would typically use unevaluatedProperties here but that has the
+# downside that all the properties in the common bindings become valid
+# for all chip generations. In this case, however, we want the per-SoC
+# bindings to be able to override which of the common properties are
+# allowed, since not all pinmux generations support the same sets of
+# properties. This way, the common bindings define the format of the
+# properties but the per-SoC bindings define which of them apply to a
+# given chip.
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
new file mode 100644
index 000000000000..f5a3a881dec4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra234-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 Pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra234-pinmux
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^pinmux(-[a-z0-9-]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra234-pinmux-common.yaml
+
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ dap6_sclk_pa0, dap6_dout_pa1, dap6_din_pa2,
+ dap6_fs_pa3, dap4_sclk_pa4, dap4_dout_pa5,
+ dap4_din_pa6, dap4_fs_pa7, soc_gpio08_pb0,
+ qspi0_sck_pc0, qspi0_cs_n_pc1,
+ qspi0_io0_pc2, qspi0_io1_pc3, qspi0_io2_pc4,
+ qspi0_io3_pc5, qspi1_sck_pc6, qspi1_cs_n_pc7,
+ qspi1_io0_pd0, qspi1_io1_pd1, qspi1_io2_pd2,
+ qspi1_io3_pd3, eqos_txc_pe0, eqos_td0_pe1,
+ eqos_td1_pe2, eqos_td2_pe3, eqos_td3_pe4,
+ eqos_tx_ctl_pe5, eqos_rd0_pe6, eqos_rd1_pe7,
+ eqos_rd2_pf0, eqos_rd3_pf1, eqos_rx_ctl_pf2,
+ eqos_rxc_pf3, eqos_sma_mdio_pf4, eqos_sma_mdc_pf5,
+ soc_gpio13_pg0, soc_gpio14_pg1, soc_gpio15_pg2,
+ soc_gpio16_pg3, soc_gpio17_pg4, soc_gpio18_pg5,
+ soc_gpio19_pg6, soc_gpio20_pg7, soc_gpio21_ph0,
+ soc_gpio22_ph1, soc_gpio06_ph2, uart4_tx_ph3,
+ uart4_rx_ph4, uart4_rts_ph5, uart4_cts_ph6,
+ soc_gpio41_ph7, soc_gpio42_pi0, soc_gpio43_pi1,
+ soc_gpio44_pi2, gen1_i2c_scl_pi3, gen1_i2c_sda_pi4,
+ cpu_pwr_req_pi5, soc_gpio07_pi6,
+ sdmmc1_clk_pj0, sdmmc1_cmd_pj1, sdmmc1_dat0_pj2,
+ sdmmc1_dat1_pj3, sdmmc1_dat2_pj4, sdmmc1_dat3_pj5,
+ pex_l0_clkreq_n_pk0, pex_l0_rst_n_pk1,
+ pex_l1_clkreq_n_pk2, pex_l1_rst_n_pk3,
+ pex_l2_clkreq_n_pk4, pex_l2_rst_n_pk5,
+ pex_l3_clkreq_n_pk6, pex_l3_rst_n_pk7,
+ pex_l4_clkreq_n_pl0, pex_l4_rst_n_pl1,
+ pex_wake_n_pl2, soc_gpio34_pl3, dp_aux_ch0_hpd_pm0,
+ dp_aux_ch1_hpd_pm1, dp_aux_ch2_hpd_pm2,
+ dp_aux_ch3_hpd_pm3, soc_gpio55_pm4, soc_gpio36_pm5,
+ soc_gpio53_pm6, soc_gpio38_pm7, dp_aux_ch3_n_pn0,
+ soc_gpio39_pn1, soc_gpio40_pn2, dp_aux_ch1_p_pn3,
+ dp_aux_ch1_n_pn4, dp_aux_ch2_p_pn5, dp_aux_ch2_n_pn6,
+ dp_aux_ch3_p_pn7, extperiph1_clk_pp0,
+ extperiph2_clk_pp1, cam_i2c_scl_pp2, cam_i2c_sda_pp3,
+ soc_gpio23_pp4, soc_gpio24_pp5, soc_gpio25_pp6,
+ pwr_i2c_scl_pp7, pwr_i2c_sda_pq0, soc_gpio28_pq1,
+ soc_gpio29_pq2, soc_gpio30_pq3, soc_gpio31_pq4,
+ soc_gpio32_pq5, soc_gpio33_pq6, soc_gpio35_pq7,
+ soc_gpio37_pr0, soc_gpio56_pr1, uart1_tx_pr2,
+ uart1_rx_pr3, uart1_rts_pr4, uart1_cts_pr5,
+ soc_gpio61_pw0, soc_gpio62_pw1, gpu_pwr_req_px0,
+ cv_pwr_req_px1, gp_pwm2_px2, gp_pwm3_px3, uart2_tx_px4,
+ uart2_rx_px5, uart2_rts_px6, uart2_cts_px7, spi3_sck_py0,
+ spi3_miso_py1, spi3_mosi_py2, spi3_cs0_py3,
+ spi3_cs1_py4, uart5_tx_py5, uart5_rx_py6,
+ uart5_rts_py7, uart5_cts_pz0, usb_vbus_en0_pz1,
+ usb_vbus_en1_pz2, spi1_sck_pz3, spi1_miso_pz4,
+ spi1_mosi_pz5, spi1_cs0_pz6, spi1_cs1_pz7,
+ spi5_sck_pac0, spi5_miso_pac1, spi5_mosi_pac2,
+ spi5_cs0_pac3, soc_gpio57_pac4, soc_gpio58_pac5,
+ soc_gpio59_pac6, soc_gpio60_pac7, soc_gpio45_pad0,
+ soc_gpio46_pad1, soc_gpio47_pad2, soc_gpio48_pad3,
+ ufs0_ref_clk_pae0, ufs0_rst_n_pae1,
+ pex_l5_clkreq_n_paf0, pex_l5_rst_n_paf1,
+ pex_l6_clkreq_n_paf2, pex_l6_rst_n_paf3,
+ pex_l7_clkreq_n_pag0, pex_l7_rst_n_pag1,
+ pex_l8_clkreq_n_pag2, pex_l8_rst_n_pag3,
+ pex_l9_clkreq_n_pag4, pex_l9_rst_n_pag5,
+ pex_l10_clkreq_n_pag6, pex_l10_rst_n_pag7,
+ sdmmc1_comp, eqos_comp, qspi_comp,
+ # drive groups
+ drive_soc_gpio08_pb0, drive_soc_gpio36_pm5,
+ drive_soc_gpio53_pm6, drive_soc_gpio55_pm4,
+ drive_soc_gpio38_pm7, drive_soc_gpio39_pn1,
+ drive_soc_gpio40_pn2, drive_dp_aux_ch0_hpd_pm0,
+ drive_dp_aux_ch1_hpd_pm1, drive_dp_aux_ch2_hpd_pm2,
+ drive_dp_aux_ch3_hpd_pm3, drive_dp_aux_ch1_p_pn3,
+ drive_dp_aux_ch1_n_pn4, drive_dp_aux_ch2_p_pn5,
+ drive_dp_aux_ch2_n_pn6, drive_dp_aux_ch3_p_pn7,
+ drive_dp_aux_ch3_n_pn0, drive_pex_l2_clkreq_n_pk4,
+ drive_pex_wake_n_pl2, drive_pex_l1_clkreq_n_pk2,
+ drive_pex_l1_rst_n_pk3, drive_pex_l0_clkreq_n_pk0,
+ drive_pex_l0_rst_n_pk1, drive_pex_l2_rst_n_pk5,
+ drive_pex_l3_clkreq_n_pk6, drive_pex_l3_rst_n_pk7,
+ drive_pex_l4_clkreq_n_pl0, drive_pex_l4_rst_n_pl1,
+ drive_soc_gpio34_pl3, drive_pex_l5_clkreq_n_paf0,
+ drive_pex_l5_rst_n_paf1, drive_pex_l6_clkreq_n_paf2,
+ drive_pex_l6_rst_n_paf3, drive_pex_l10_clkreq_n_pag6,
+ drive_pex_l10_rst_n_pag7, drive_pex_l7_clkreq_n_pag0,
+ drive_pex_l7_rst_n_pag1, drive_pex_l8_clkreq_n_pag2,
+ drive_pex_l8_rst_n_pag3, drive_pex_l9_clkreq_n_pag4,
+ drive_pex_l9_rst_n_pag5, drive_sdmmc1_clk_pj0,
+ drive_sdmmc1_cmd_pj1, drive_sdmmc1_dat3_pj5,
+ drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3,
+ drive_sdmmc1_dat0_pj2 ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-tegra.h>
+
+ pinmux@2430000 {
+ compatible = "nvidia,tegra234-pinmux";
+ reg = <0x2430000 0x17000>;
+
+ pinctrl-names = "pex_rst";
+ pinctrl-0 = <&pex_rst_c5_out_state>;
+
+ pex_rst_c5_out_state: pinmux-pex-rst-c5-out {
+ pexrst {
+ nvidia,pins = "pex_l5_rst_n_paf1";
+ nvidia,schmitt = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,io-hv = <TEGRA_PIN_ENABLE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt
deleted file mode 100644
index 0e6354c11e6d..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt
+++ /dev/null
@@ -1,144 +0,0 @@
-NVIDIA Tegra30 pinmux controller
-
-The Tegra30 pinctrl binding is very similar to the Tegra20 pinctrl binding,
-as described in nvidia,tegra20-pinmux.txt. In fact, this document assumes
-that binding as a baseline, and only documents the differences between the
-two bindings.
-
-Required properties:
-- compatible: "nvidia,tegra30-pinmux"
-- reg: Should contain the register physical address and length for each of
- the pad control and mux registers.
-
-Tegra30 adds the following optional properties for pin configuration subnodes:
-- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes.
-- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes.
-- nvidia,lock: Integer. Lock the pin configuration against further changes
- until reset. 0: no, 1: yes.
-- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes.
-
-As with Tegra20, see the Tegra TRM for complete details regarding which groups
-support which functionality.
-
-Valid values for pin and group names are:
-
- per-pin mux groups:
-
- These all support nvidia,function, nvidia,tristate, nvidia,pull,
- nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain,
- nvidia,io-reset.
-
- clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2, dap2_sclk_pa3,
- dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, gmi_a17_pb0,
- gmi_a18_pb1, lcd_pwr0_pb2, lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5,
- sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0, lcd_pwr1_pc1,
- uart2_txd_pc2, uart2_rxd_pc3, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5,
- lcd_pwr2_pc6, gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1, lcd_dc1_pd2,
- sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5, vi_vsync_pd6, vi_hsync_pd7,
- lcd_d0_pe0, lcd_d1_pe1, lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5,
- lcd_d6_pe6, lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2, lcd_d11_pf3,
- lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6, lcd_d15_pf7, gmi_ad0_pg0,
- gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5,
- gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
- gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7,
- gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2, gmi_cs6_n_pi3, gmi_rst_n_pi4,
- gmi_iordy_pi5, gmi_cs7_n_pi6, gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1,
- gmi_cs1_n_pj2, lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5,
- uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs4_n_pk2,
- gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5, spdif_in_pk6, gmi_a19_pk7,
- vi_d2_pl0, vi_d3_pl1, vi_d4_pl2, vi_d5_pl3, vi_d6_pl4, vi_d7_pl5,
- vi_d8_pl6, vi_d9_pl7, lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3,
- lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7, dap1_fs_pn0,
- dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, lcd_cs0_n_pn4, lcd_sdout_pn5,
- lcd_dc0_pn6, hdmi_int_pn7, ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2,
- ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6,
- ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3,
- dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0,
- kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
- kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2,
- kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7,
- kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4,
- kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1,
- vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6,
- sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4, pu5, pu6, jtag_rtck_pu7, pv0,
- pv1, pv2, pv3, ddc_scl_pv4, ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7,
- lcd_cs1_n_pw0, lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4,
- clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0, spi2_miso_px1,
- spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4, spi1_sck_px5, spi1_cs0_n_px6,
- spi1_miso_px7, ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3,
- sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7,
- sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3, lcd_sck_pz4,
- sys_clk_req_pz5, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, sdmmc4_dat0_paa0,
- sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
- sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0,
- cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7,
- cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3, sdmmc4_clk_pcc4,
- clk2_req_pcc5, pex_l2_rst_n_pcc6, pex_l2_clkreq_n_pcc7,
- pex_l0_prsnt_n_pdd0, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2,
- pex_wake_n_pdd3, pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5,
- pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0, clk3_req_pee1,
- clk1_req_pee2, hdmi_cec_pee3, clk_32k_in, core_pwr_req, cpu_pwr_req, owr,
- pwr_int_n.
-
- drive groups:
-
- These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
- nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
- support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode.
-
- ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, cec, crt, csus, dap1,
- dap2, dap3, dap4, dbg, ddc, dev3, gma, gmb, gmc, gmd, gme, gmf, gmg,
- gmh, gpv, lcd1, lcd2, owr, sdio1, sdio2, sdio3, spi, uaa, uab, uart2,
- uart3, uda, vi1.
-
-Valid values for nvidia,functions are:
-
- blink, cec, clk_12m_out, clk_32k_in, core_pwr_req, cpu_pwr_req, crt,
- dap, ddr, dev3, displaya, displayb, dtv, extperiph1, extperiph2,
- extperiph3, gmi, gmi_alt, hda, hdcp, hdmi, hsi, i2c1, i2c2, i2c3,
- i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, invalid, kbc, mio, nand,
- nand_alt, owr, pcie, pwm0, pwm1, pwm2, pwm3, pwr_int_n, rsvd1, rsvd2,
- rsvd3, rsvd4, rtck, sata, sdmmc1, sdmmc2, sdmmc3, sdmmc4, spdif, spi1,
- spi2, spi2_alt, spi3, spi4, spi5, spi6, sysclk, test, trace, uarta,
- uartb, uartc, uartd, uarte, ulpi, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6,
- vi, vi_alt1, vi_alt2, vi_alt3
-
-Example:
-
- pinctrl@70000000 {
- compatible = "nvidia,tegra30-pinmux";
- reg = < 0x70000868 0xd0 /* Pad control registers */
- 0x70003000 0x3e0 >; /* Mux registers */
- };
-
-Example board file extract:
-
- pinctrl@70000000 {
- sdmmc4_default: pinmux {
- sdmmc4_clk_pcc4 {
- nvidia,pins = "sdmmc4_clk_pcc4",
- "sdmmc4_rst_n_pcc3";
- nvidia,function = "sdmmc4";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- };
- sdmmc4_dat0_paa0 {
- nvidia,pins = "sdmmc4_dat0_paa0",
- "sdmmc4_dat1_paa1",
- "sdmmc4_dat2_paa2",
- "sdmmc4_dat3_paa3",
- "sdmmc4_dat4_paa4",
- "sdmmc4_dat5_paa5",
- "sdmmc4_dat6_paa6",
- "sdmmc4_dat7_paa7";
- nvidia,function = "sdmmc4";
- nvidia,pull = <2>;
- nvidia,tristate = <0>;
- };
- };
- };
-
- sdhci@78000400 {
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc4_default>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml
new file mode 100644
index 000000000000..36c8f3301a8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.yaml
@@ -0,0 +1,174 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nvidia,tegra30-pinmux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra30 pinmux Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra30-pinmux
+
+ reg:
+ items:
+ - description: pad control registers
+ - description: mux registers
+
+patternProperties:
+ "^pinmux(-[a-z0-9-_]+)?$":
+ type: object
+
+ # pin groups
+ additionalProperties:
+ $ref: nvidia,tegra-pinmux-common.yaml
+ additionalProperties: false
+ properties:
+ nvidia,pins:
+ items:
+ enum: [ clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2,
+ dap2_sclk_pa3, dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6,
+ sdmmc3_cmd_pa7, gmi_a17_pb0, gmi_a18_pb1, lcd_pwr0_pb2,
+ lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5,
+ sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0,
+ lcd_pwr1_pc1, uart2_txd_pc2, uart2_rxd_pc3,
+ gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, lcd_pwr2_pc6,
+ gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1,
+ lcd_dc1_pd2, sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5,
+ vi_vsync_pd6, vi_hsync_pd7, lcd_d0_pe0, lcd_d1_pe1,
+ lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5, lcd_d6_pe6,
+ lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2,
+ lcd_d11_pf3, lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6,
+ lcd_d15_pf7, gmi_ad0_pg0, gmi_ad1_pg1, gmi_ad2_pg2,
+ gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, gmi_ad6_pg6,
+ gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
+ gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6,
+ gmi_ad15_ph7, gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2,
+ gmi_cs6_n_pi3, gmi_rst_n_pi4, gmi_iordy_pi5, gmi_cs7_n_pi6,
+ gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1, gmi_cs1_n_pj2,
+ lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5,
+ uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1,
+ gmi_cs4_n_pk2, gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5,
+ spdif_in_pk6, gmi_a19_pk7, vi_d2_pl0, vi_d3_pl1, vi_d4_pl2,
+ vi_d5_pl3, vi_d6_pl4, vi_d7_pl5, vi_d8_pl6, vi_d9_pl7,
+ lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3,
+ lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7,
+ dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3,
+ lcd_cs0_n_pn4, lcd_sdout_pn5, lcd_dc0_pn6, hdmi_int_pn7,
+ ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2,
+ ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5,
+ ulpi_data5_po6, ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1,
+ dap3_dout_pp2, dap3_sclk_pp3, dap4_fs_pp4, dap4_din_pp5,
+ dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0, kb_col1_pq1,
+ kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
+ kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1,
+ kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5,
+ kb_row6_pr6, kb_row7_pr7, kb_row8_ps0, kb_row9_ps1,
+ kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, kb_row13_ps5,
+ kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1,
+ vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5,
+ gen2_i2c_sda_pt6, sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4,
+ pu5, pu6, jtag_rtck_pu7, pv0, pv1, pv2, pv3, ddc_scl_pv4,
+ ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7, lcd_cs1_n_pw0,
+ lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4,
+ clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0,
+ spi2_miso_px1, spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4,
+ spi1_sck_px5, spi1_cs0_n_px6, spi1_miso_px7, ulpi_clk_py0,
+ ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, sdmmc1_dat3_py4,
+ sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7,
+ sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3,
+ lcd_sck_pz4, sys_clk_req_pz5, pwr_i2c_scl_pz6,
+ pwr_i2c_sda_pz7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1,
+ sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
+ sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0,
+ cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
+ pbb7, cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3,
+ sdmmc4_clk_pcc4, clk2_req_pcc5, pex_l2_rst_n_pcc6,
+ pex_l2_clkreq_n_pcc7, pex_l0_prsnt_n_pdd0,
+ pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3,
+ pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5,
+ pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0,
+ clk3_req_pee1, clk1_req_pee2, hdmi_cec_pee3, clk_32k_in,
+ core_pwr_req, cpu_pwr_req, owr, pwr_int_n,
+ # drive groups
+ drive_ao1, drive_ao2, drive_at1, drive_at2, drive_at3,
+ drive_at4, drive_at5, drive_cdev1, drive_cdev2, drive_cec,
+ drive_crt, drive_csus, drive_dap1, drive_dap2, drive_dap3,
+ drive_dap4, drive_dbg, drive_ddc, drive_dev3, drive_gma,
+ drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_gmf,
+ drive_gmg, drive_gmh, drive_gpv, drive_lcd1, drive_lcd2,
+ drive_owr, drive_sdio1, drive_sdio2, drive_sdio3,
+ drive_spi, drive_uaa, drive_uab, drive_uart2, drive_uart3,
+ drive_uda, drive_vi1 ]
+
+ nvidia,function:
+ enum: [ blink, cec, clk_12m_out, clk_32k_in, core_pwr_req,
+ cpu_pwr_req, crt, dap, ddr, dev3, displaya, displayb, dtv,
+ extperiph1, extperiph2, extperiph3, gmi, gmi_alt, hda, hdcp,
+ hdmi, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, i2s0, i2s1, i2s2,
+ i2s3, i2s4, invalid, kbc, mio, nand, nand_alt, owr, pcie,
+ pwm0, pwm1, pwm2, pwm3, pwr_int_n, rsvd1, rsvd2, rsvd3,
+ rsvd4, rtck, sata, sdmmc1, sdmmc2, sdmmc3, sdmmc4, spdif,
+ spi1, spi2, spi2_alt, spi3, spi4, spi5, spi6, sysclk, test,
+ trace, uarta, uartb, uartc, uartd, uarte, ulpi, vgp1, vgp2,
+ vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt2, vi_alt3 ]
+
+ nvidia,pull: true
+ nvidia,tristate: true
+ nvidia,schmitt: true
+ nvidia,pull-down-strength: true
+ nvidia,pull-up-strength: true
+ nvidia,high-speed-mode: true
+ nvidia,low-power-mode: true
+ nvidia,enable-input: true
+ nvidia,open-drain: true
+ nvidia,lock: true
+ nvidia,io-reset: true
+ nvidia,slew-rate-rising: true
+ nvidia,slew-rate-falling: true
+
+ required:
+ - nvidia,pins
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ pinctrl@70000000 {
+ compatible = "nvidia,tegra30-pinmux";
+ reg = <0x70000868 0x0d0>, /* Pad control registers */
+ <0x70003000 0x3e0>; /* Mux registers */
+
+ pinmux {
+ sdmmc4_clk_pcc4 {
+ nvidia,pins = "sdmmc4_clk_pcc4",
+ "sdmmc4_rst_n_pcc3";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <0>;
+ nvidia,tristate = <0>;
+ };
+
+ sdmmc4_dat0_paa0 {
+ nvidia,pins = "sdmmc4_dat0_paa0",
+ "sdmmc4_dat1_paa1",
+ "sdmmc4_dat2_paa2",
+ "sdmmc4_dat3_paa3",
+ "sdmmc4_dat4_paa4",
+ "sdmmc4_dat5_paa5",
+ "sdmmc4_dat6_paa6",
+ "sdmmc4_dat7_paa7";
+ nvidia,function = "sdmmc4";
+ nvidia,pull = <2>;
+ nvidia,tristate = <0>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt b/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt
deleted file mode 100644
index bd8b0c69fa44..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-NXP LPC18xx/43xx SCU pin controller Device Tree Bindings
---------------------------------------------------------
-
-Required properties:
-- compatible : Should be "nxp,lpc1850-scu"
-- reg : Address and length of the register set for the device
-- clocks : Clock specifier (see clock bindings for details)
-
-The lpc1850-scu driver uses the generic pin multiplexing and generic pin
-configuration documented in pinctrl-bindings.txt.
-
-The following generic nodes are supported:
- - function
- - pins
- - bias-disable
- - bias-pull-up
- - bias-pull-down
- - drive-strength
- - input-enable
- - input-disable
- - input-schmitt-enable
- - input-schmitt-disable
- - slew-rate
-
-NXP specific properties:
- - nxp,gpio-pin-interrupt : Assign pin to gpio pin interrupt controller
- irq number 0 to 7. See example below.
-
-Not all pins support all properties so either refer to the NXP 1850/4350
-user manual or the pin table in the pinctrl-lpc18xx driver for supported
-pin properties.
-
-Example:
-pinctrl: pinctrl@40086000 {
- compatible = "nxp,lpc1850-scu";
- reg = <0x40086000 0x1000>;
- clocks = <&ccu1 CLK_CPU_SCU>;
-
- i2c0_pins: i2c0-pins {
- i2c0_pins_cfg {
- pins = "i2c0_scl", "i2c0_sda";
- function = "i2c0";
- input-enable;
- };
- };
-
- uart0_pins: uart0-pins {
- uart0_rx_cfg {
- pins = "pf_11";
- function = "uart0";
- bias-disable;
- input-enable;
- };
-
- uart0_tx_cfg {
- pins = "pf_10";
- function = "uart0";
- bias-disable;
- };
- };
-
- gpio_joystick_pins: gpio-joystick-pins {
- gpio_joystick_1_cfg {
- pins = "p9_0";
- function = "gpio";
- nxp,gpio-pin-interrupt = <0>;
- input-enable;
- bias-disable;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.yaml
new file mode 100644
index 000000000000..11f41359b5c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nxp,lpc1850-scu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC18xx/43xx SCU pin controller
+
+description:
+ Not all pins support all pin generic node properties so either refer to
+ the NXP 1850/4350 user manual or the pin table in the pinctrl-lpc18xx
+ driver for supported pin properties.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-scu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '_cfg$':
+ type: object
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ unevaluatedProperties: false
+
+ properties:
+ nxp,gpio-pin-interrupt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ description:
+ Assign pin to gpio pin interrupt controller
+ irq number 0 to 7. See example below.
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ pinctrl@40086000 {
+ compatible = "nxp,lpc1850-scu";
+ reg = <0x40086000 0x1000>;
+ clocks = <&ccu1 CLK_CPU_SCU>;
+
+ gpio-joystick-pins {
+ gpio-joystick-1_cfg {
+ pins = "p9_0";
+ function = "gpio";
+ nxp,gpio-pin-interrupt = <0>;
+ input-enable;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml
new file mode 100644
index 000000000000..a24286e4def6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2022 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/nxp,s32g2-siul2-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP S32G2 pin controller
+
+maintainers:
+ - Ghennadi Procopciuc <Ghennadi.Procopciuc@oss.nxp.com>
+ - Chester Lin <chester62515@gmail.com>
+
+description: |
+ S32G2 pinmux is implemented in SIUL2 (System Integration Unit Lite2),
+ whose memory map is split into two regions:
+ SIUL2_0 @ 0x4009c000
+ SIUL2_1 @ 0x44010000
+
+ Every SIUL2 region has multiple register types, and here only MSCR and
+ IMCR registers need to be revealed for kernel to configure pinmux.
+
+ Please note that some register indexes are reserved in S32G2, such as
+ MSCR102-MSCR111, MSCR123-MSCR143, IMCR84-IMCR118 and IMCR398-IMCR429.
+
+properties:
+ compatible:
+ enum:
+ - nxp,s32g2-siul2-pinctrl
+
+ reg:
+ description: |
+ A list of MSCR/IMCR register regions to be reserved.
+ - MSCR (Multiplexed Signal Configuration Register)
+ An MSCR register can configure the associated pin as either a GPIO pin
+ or a function output pin depends on the selected signal source.
+ - IMCR (Input Multiplexed Signal Configuration Register)
+ An IMCR register can configure the associated pin as function input
+ pin depends on the selected signal source.
+ items:
+ - description: MSCR registers group 0 in SIUL2_0
+ - description: MSCR registers group 1 in SIUL2_1
+ - description: MSCR registers group 2 in SIUL2_1
+ - description: IMCR registers group 0 in SIUL2_0
+ - description: IMCR registers group 1 in SIUL2_1
+ - description: IMCR registers group 2 in SIUL2_1
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '-grp[0-9]$':
+ type: object
+ allOf:
+ - $ref: pinmux-node.yaml#
+ - $ref: pincfg-node.yaml#
+ description: |
+ Pinctrl node's client devices specify pin muxes using subnodes,
+ which in turn use the standard properties below.
+
+ properties:
+ bias-disable: true
+ bias-high-impedance: true
+ bias-pull-up: true
+ bias-pull-down: true
+ drive-open-drain: true
+ input-enable: true
+ output-enable: true
+
+ pinmux:
+ description: |
+ An integer array for representing pinmux configurations of
+ a device. Each integer consists of a PIN_ID and a 4-bit
+ selected signal source(SSS) as IOMUX setting, which is
+ calculated as: pinmux = (PIN_ID << 4 | SSS)
+
+ slew-rate:
+ description: Supported slew rate based on Fmax values (MHz)
+ enum: [83, 133, 150, 166, 208]
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@4009c240 {
+ compatible = "nxp,s32g2-siul2-pinctrl";
+
+ /* MSCR0-MSCR101 registers on siul2_0 */
+ reg = <0x4009c240 0x198>,
+ /* MSCR112-MSCR122 registers on siul2_1 */
+ <0x44010400 0x2c>,
+ /* MSCR144-MSCR190 registers on siul2_1 */
+ <0x44010480 0xbc>,
+ /* IMCR0-IMCR83 registers on siul2_0 */
+ <0x4009ca40 0x150>,
+ /* IMCR119-IMCR397 registers on siul2_1 */
+ <0x44010c1c 0x45c>,
+ /* IMCR430-IMCR495 registers on siul2_1 */
+ <0x440110f8 0x108>;
+
+ llce-can0-pins {
+ llce-can0-grp0 {
+ pinmux = <0x2b0>;
+ input-enable;
+ slew-rate = <208>;
+ };
+
+ llce-can0-grp1 {
+ pinmux = <0x2c2>;
+ output-enable;
+ slew-rate = <208>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt
deleted file mode 100644
index b1159434f593..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/oxnas,pinctrl.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Oxford Semiconductor OXNAS SoC Family Pin Controller
-
-Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
-../interrupt-controller/interrupts.txt for generic information regarding
-pin controller, GPIO, and interrupt bindings.
-
-OXNAS 'pin configuration node' is a node of a group of pins which can be
-used for a specific device or function. This node represents configurations of
-pins, optional function, and optional mux related configuration.
-
-Required properties for pin controller node:
- - compatible: "oxsemi,ox810se-pinctrl" or "oxsemi,ox820-pinctrl"
- - oxsemi,sys-ctrl: a phandle to the system controller syscon node
-
-Required properties for pin configuration sub-nodes:
- - pins: List of pins to which the configuration applies.
-
-Optional properties for pin configuration sub-nodes:
-----------------------------------------------------
- - function: Mux function for the specified pins.
- - bias-pull-up: Enable weak pull-up.
-
-Example:
-
-pinctrl: pinctrl {
- compatible = "oxsemi,ox810se-pinctrl";
-
- /* Regmap for sys registers */
- oxsemi,sys-ctrl = <&sys>;
-
- pinctrl_uart2: pinctrl_uart2 {
- uart2a {
- pins = "gpio31";
- function = "fct3";
- };
- uart2b {
- pins = "gpio32";
- function = "fct3";
- };
- };
-};
-
-uart2: serial@900000 {
- compatible = "ns16550a";
- reg = <0x900000 0x100000>;
- clocks = <&sysclk>;
- interrupts = <29>;
- reg-shift = <0>;
- fifo-size = <16>;
- reg-io-width = <1>;
- current-speed = <115200>;
- no-loopback-test;
- resets = <&reset 22>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml
index f5a121311f61..d1bc389e0a6d 100644
--- a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/pincfg-node.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic pin configuration node schema
+title: Generic Pin Configuration Node
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -96,8 +96,11 @@ properties:
type: boolean
description: disable schmitt-trigger mode
+ input-schmitt-microvolt:
+ description: threshold strength for schmitt-trigger
+
input-debounce:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: Takes the debounce time in usec as argument or 0 to disable
debouncing
@@ -150,4 +153,21 @@ properties:
pin. Typically indicates how many double-inverters are
used to delay the signal.
+ skew-delay-input-ps:
+ description:
+ this affects the expected clock skew in ps on an input pin.
+
+ skew-delay-output-ps:
+ description:
+ this affects the expected delay in ps before latching a value to
+ an output pin.
+
+if:
+ required:
+ - skew-delay
+then:
+ properties:
+ skew-delay-input-ps: false
+ skew-delay-output-ps: false
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
index 511fc234558b..28fbca180068 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
@@ -38,7 +38,7 @@ Valid values for function properties are:
gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
reference-out
-Theres is also customised properties for the GPIO1, GPIO2 and GPIO3. These
+There are also customised properties for the GPIO1, GPIO2 and GPIO3. These
customised properties are required to configure FPS configuration parameters
of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
detail of Flexible Power Sequence (FPS).
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
deleted file mode 100644
index 2fa5edac7a35..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
+++ /dev/null
@@ -1,148 +0,0 @@
-Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
-8-/16-bit I/O expander with serial interface (I2C/SPI)
-
-Required properties:
-- compatible : Should be
- - "mcp,mcp23s08" (DEPRECATED) for 8 GPIO SPI version
- - "mcp,mcp23s17" (DEPRECATED) for 16 GPIO SPI version
- - "mcp,mcp23008" (DEPRECATED) for 8 GPIO I2C version or
- - "mcp,mcp23017" (DEPRECATED) for 16 GPIO I2C version of the chip
-
- - "microchip,mcp23s08" for 8 GPIO SPI version
- - "microchip,mcp23s17" for 16 GPIO SPI version
- - "microchip,mcp23s18" for 16 GPIO SPI version
- - "microchip,mcp23008" for 8 GPIO I2C version or
- - "microchip,mcp23017" for 16 GPIO I2C version of the chip
- - "microchip,mcp23018" for 16 GPIO I2C version
- NOTE: Do not use the old mcp prefix any more. It is deprecated and will be
- removed.
-- #gpio-cells : Should be two.
- - first cell is the pin number
- - second cell is used to specify flags as described in
- 'Documentation/devicetree/bindings/gpio/gpio.txt'. Allowed values defined by
- 'include/dt-bindings/gpio/gpio.h' (e.g. GPIO_ACTIVE_LOW).
-- gpio-controller : Marks the device node as a GPIO controller.
-- reg : For an address on its bus. I2C uses this a the I2C address of the chip.
- SPI uses this to specify the chipselect line which the chip is
- connected to. The driver and the SPI variant of the chip support
- multiple chips on the same chipselect. Have a look at
- microchip,spi-present-mask below.
-
-Required device specific properties (only for SPI chips):
-- mcp,spi-present-mask (DEPRECATED)
-- microchip,spi-present-mask : This is a present flag, that makes only sense for SPI
- chips - as the name suggests. Multiple SPI chips can share the same
- SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a
- chip connected with the corresponding spi address set. For example if
- you have a chip with address 3 connected, you have to set bit3 to 1,
- which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not
- possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at
- least one bit to 1 for SPI chips.
- NOTE: Do not use the old mcp prefix any more. It is deprecated and will be
- removed.
-- spi-max-frequency = The maximum frequency this chip is able to handle
-
-Optional properties:
-- #interrupt-cells : Should be two.
- - first cell is the pin number
- - second cell is used to specify flags.
-- interrupt-controller: Marks the device node as a interrupt controller.
-- drive-open-drain: Sets the ODR flag in the IOCON register. This configures
- the IRQ output as open drain active low.
-- reset-gpios: Corresponds to the active-low RESET# pin for the chip
-
-Optional device specific properties:
-- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices
- with two interrupt outputs (these are the devices ending with 17 and
- those that have 16 IOs) have two IO banks: IO 0-7 form bank 1 and
- IO 8-15 are bank 2. These chips have two different interrupt outputs:
- One for bank 1 and another for bank 2. If irq-mirror is set, both
- interrupts are generated regardless of the bank that an input change
- occurred on. If it is not set, the interrupt are only generated for the
- bank they belong to.
- On devices with only one interrupt output this property is useless.
-- microchip,irq-active-high: Sets the INTPOL flag in the IOCON register. This
- configures the IRQ output polarity as active high.
-
-Example I2C (with interrupt):
-gpiom1: gpio@20 {
- compatible = "microchip,mcp23017";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <0x20>;
-
- interrupt-parent = <&gpio1>;
- interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
- interrupt-controller;
- #interrupt-cells=<2>;
- microchip,irq-mirror;
-};
-
-Example SPI:
-gpiom1: gpio@0 {
- compatible = "microchip,mcp23s17";
- gpio-controller;
- #gpio-cells = <2>;
- microchip,spi-present-mask = <0x01>;
- reg = <0>;
- spi-max-frequency = <1000000>;
-};
-
-Pull-up configuration
-=====================
-
-If pins are used as output, they can also be configured with pull-ups. This is
-done with pinctrl.
-
-Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt>
-for details of the common pinctrl bindings used by client devices,
-including the meaning of the phrase "pin configuration node".
-
-Optional Pinmux properties:
---------------------------
-Following properties are required if default setting of pins are required
-at boot.
-- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
-- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
- <pinctrl-bindings.txt>.
-
-The pin configurations are defined as child of the pinctrl states node. Each
-sub-node have following properties:
-
-Required properties:
-------------------
-- pins: List of pins. Valid values of pins properties are:
- gpio0 ... gpio7 for the devices with 8 GPIO pins and
- gpio0 ... gpio15 for the devices with 16 GPIO pins.
-
-Optional properties:
--------------------
-The following optional property is defined in the pinmux DT binding document
-<pinctrl-bindings.txt>. Absence of this property will leave the configuration
-in its default state.
- bias-pull-up
-
-Example with pinctrl to pull-up output pins:
-gpio21: gpio@21 {
- compatible = "microchip,mcp23017";
- gpio-controller;
- #gpio-cells = <0x2>;
- reg = <0x21>;
- interrupt-parent = <&socgpio>;
- interrupts = <0x17 0x8>;
- interrupt-names = "mcp23017@21 irq";
- interrupt-controller;
- #interrupt-cells = <0x2>;
- microchip,irq-mirror;
- pinctrl-names = "default";
- pinctrl-0 = <&i2cgpio0irq>, <&gpio21pullups>;
- reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
-
- gpio21pullups: pinmux {
- pins = "gpio0", "gpio1", "gpio2", "gpio3",
- "gpio4", "gpio5", "gpio6", "gpio7",
- "gpio8", "gpio9", "gpio10", "gpio11",
- "gpio12", "gpio13", "gpio14", "gpio15";
- bias-pull-up;
- };
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml
deleted file mode 100644
index 1eeb885ce0c6..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml
+++ /dev/null
@@ -1,276 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8186.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mediatek MT8186 Pin Controller
-
-maintainers:
- - Sean Wang <sean.wang@mediatek.com>
-
-description: |
- The Mediatek's Pin controller is used to control SoC pins.
-
-properties:
- compatible:
- const: mediatek,mt8186-pinctrl
-
- gpio-controller: true
-
- '#gpio-cells':
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO binding is used,
- the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- gpio-line-names: true
-
- reg:
- description: |
- Physical address base for gpio base registers. There are 8 different GPIO
- physical address base in mt8186.
- maxItems: 8
-
- reg-names:
- description: |
- Gpio base register names.
- items:
- - const: iocfg0
- - const: iocfg_bm
- - const: iocfg_bl
- - const: iocfg_br
- - const: iocfg_lm
- - const: iocfg_rb
- - const: iocfg_tl
- - const: eint
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
-
- interrupts:
- description: The interrupt outputs to sysirq
- maxItems: 1
-
- mediatek,rsel-resistance-in-si-unit:
- type: boolean
- description: |
- Identifying i2c pins pull up/down type which is RSEL. It can support
- RSEL define or si unit value(ohm) to set different resistance.
-
-# PIN CONFIGURATION NODES
-patternProperties:
- '-pins$':
- type: object
- additionalProperties: false
- patternProperties:
- '^pins':
- type: object
- additionalProperties: false
- description: |
- A pinctrl node should contain at least one subnodes representing the
- pinctrl groups available on the machine. Each subnode will list the
- pins it needs, and how they should be configured, with regard to muxer
- configuration, pullups, drive strength, input enable/disable and
- input schmitt.
- An example of using macro:
- pincontroller {
- /* GPIO0 set as multifunction GPIO0 */
- gpio-pins {
- pins {
- pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
- }
- };
- /* GPIO128 set as multifunction SDA0 */
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
- }
- };
- };
- $ref: "pinmux-node.yaml"
-
- properties:
- pinmux:
- description: |
- Integer array, represents gpio pin number and mux setting.
- Supported pin number and mux varies for different SoCs, and are
- defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h
- directly.
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
-
- drive-strength-microamp:
- enum: [125, 250, 500, 1000]
-
- bias-pull-down:
- oneOf:
- - type: boolean
- - enum: [100, 101, 102, 103]
- description: mt8186 pull down PUPD/R0/R1 type define value.
- - enum: [200, 201, 202, 203]
- description: mt8186 pull down RSEL type define value.
- - enum: [75000, 5000]
- description: mt8186 pull down RSEL type si unit value(ohm).
- description: |
- For pull down type is normal, it don't need add RSEL & R1R0 define
- and resistance value.
- For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
- set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
- "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
- "MTK_PUPD_SET_R1R0_11" define in mt8186.
- For pull down type is RSEL, it can add RSEL define & resistance
- value(ohm) to set different resistance by identifying property
- "mediatek,rsel-resistance-in-si-unit".
- It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001"
- & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011"
- define in mt8186. It can also support resistance value(ohm)
- "75000" & "5000" in mt8186.
- An example of using RSEL define:
- pincontroller {
- i2c0_pin {
- pins {
- pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
- bias-pull-down = <MTK_PULL_SET_RSEL_001>;
- }
- };
- };
- An example of using si unit resistance value(ohm):
- &pio {
- mediatek,rsel-resistance-in-si-unit;
- }
- pincontroller {
- i2c0_pin {
- pins {
- pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
- bias-pull-down = <75000>;
- }
- };
- };
-
- bias-pull-up:
- oneOf:
- - type: boolean
- - enum: [100, 101, 102, 103]
- description: mt8186 pull up PUPD/R0/R1 type define value.
- - enum: [200, 201, 202, 203]
- description: mt8186 pull up RSEL type define value.
- - enum: [1000, 5000, 10000, 75000]
- description: mt8186 pull up RSEL type si unit value(ohm).
- description: |
- For pull up type is normal, it don't need add RSEL & R1R0 define
- and resistance value.
- For pull up type is PUPD/R0/R1 type, it can add R1R0 define to
- set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
- "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
- "MTK_PUPD_SET_R1R0_11" define in mt8186.
- For pull up type is RSEL, it can add RSEL define & resistance
- value(ohm) to set different resistance by identifying property
- "mediatek,rsel-resistance-in-si-unit".
- It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001"
- & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011"
- define in mt8186. It can also support resistance value(ohm)
- "1000" & "5000" & "10000" & "75000" in mt8186.
- An example of using si unit resistance value(ohm):
- &pio {
- mediatek,rsel-resistance-in-si-unit;
- }
- pincontroller {
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO128__FUNC_SDA0>;
- bias-pull-up = <1000>;
- }
- };
- };
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- input-enable: true
-
- input-disable: true
-
- input-schmitt-enable: true
-
- input-schmitt-disable: true
-
- required:
- - pinmux
-
-required:
- - compatible
- - reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/pinctrl/mt8186-pinfunc.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- pio: pinctrl@10005000 {
- compatible = "mediatek,mt8186-pinctrl";
- reg = <0x10005000 0x1000>,
- <0x10002000 0x0200>,
- <0x10002200 0x0200>,
- <0x10002400 0x0200>,
- <0x10002600 0x0200>,
- <0x10002A00 0x0200>,
- <0x10002c00 0x0200>,
- <0x1000b000 0x1000>;
- reg-names = "iocfg0", "iocfg_bm", "iocfg_bl",
- "iocfg_br", "iocfg_lm", "iocfg_rb",
- "iocfg_tl", "eint";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pio 0 0 185>;
- interrupt-controller;
- interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH 0>;
- #interrupt-cells = <2>;
-
- pio-pins {
- pins {
- pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
- output-low;
- };
- };
-
- spi0-pins {
- pins-spi {
- pinmux = <PINMUX_GPIO0__FUNC_SPI0_CLK_B>,
- <PINMUX_GPIO1__FUNC_SPI0_CSB_B>,
- <PINMUX_GPIO2__FUNC_SPI0_MO_B>;
- bias-disable;
- };
- pins-spi-mi {
- pinmux = <PINMUX_GPIO3__FUNC_SPI0_MI_B>;
- bias-pull-down;
- };
- };
-
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO127__FUNC_SCL0>,
- <PINMUX_GPIO128__FUNC_SDA0>;
- bias-pull-up = <MTK_PULL_SET_RSEL_001>;
- drive-strength-microamp = <1000>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml
deleted file mode 100644
index e0e943e5b874..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml
+++ /dev/null
@@ -1,183 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8192.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mediatek MT8192 Pin Controller
-
-maintainers:
- - Sean Wang <sean.wang@mediatek.com>
-
-description: |
- The Mediatek's Pin controller is used to control SoC pins.
-
-properties:
- compatible:
- const: mediatek,mt8192-pinctrl
-
- gpio-controller: true
-
- '#gpio-cells':
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO binding is used,
- the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
- const: 2
-
- gpio-ranges:
- description: gpio valid number range.
- maxItems: 1
-
- gpio-line-names: true
-
- reg:
- description: |
- Physical address base for gpio base registers. There are 11 GPIO
- physical address base in mt8192.
- maxItems: 11
-
- reg-names:
- description: |
- Gpio base register names.
- maxItems: 11
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
-
- interrupts:
- description: The interrupt outputs to sysirq.
- maxItems: 1
-
-#PIN CONFIGURATION NODES
-patternProperties:
- '-pins$':
- type: object
- additionalProperties: false
- patternProperties:
- '^pins':
- type: object
- description: |
- A pinctrl node should contain at least one subnodes representing the
- pinctrl groups available on the machine. Each subnode will list the
- pins it needs, and how they should be configured, with regard to muxer
- configuration, pullups, drive strength, input enable/disable and
- input schmitt.
- $ref: "pinmux-node.yaml"
-
- properties:
- pinmux:
- description: |
- Integer array, represents gpio pin number and mux setting.
- Supported pin number and mux varies for different SoCs, and are defined
- as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
-
- drive-strength:
- description: |
- It can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See
- dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192.
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
-
- drive-strength-microamp:
- enum: [125, 250, 500, 1000]
-
- bias-pull-down:
- oneOf:
- - type: boolean
- description: normal pull down.
- - enum: [100, 101, 102, 103]
- description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0_
- defines in dt-bindings/pinctrl/mt65xx.h.
- - enum: [200, 201, 202, 203]
- description: RSEL pull down type. See MTK_PULL_SET_RSEL_
- defines in dt-bindings/pinctrl/mt65xx.h.
-
- bias-pull-up:
- oneOf:
- - type: boolean
- description: normal pull up.
- - enum: [100, 101, 102, 103]
- description: PUPD/R1/R0 pull up type. See MTK_PUPD_SET_R1R0_
- defines in dt-bindings/pinctrl/mt65xx.h.
- - enum: [200, 201, 202, 203]
- description: RSEL pull up type. See MTK_PULL_SET_RSEL_
- defines in dt-bindings/pinctrl/mt65xx.h.
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- input-enable: true
-
- input-disable: true
-
- input-schmitt-enable: true
-
- input-schmitt-disable: true
-
- required:
- - pinmux
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/pinctrl/mt8192-pinfunc.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pio: pinctrl@10005000 {
- compatible = "mediatek,mt8192-pinctrl";
- reg = <0x10005000 0x1000>,
- <0x11c20000 0x1000>,
- <0x11d10000 0x1000>,
- <0x11d30000 0x1000>,
- <0x11d40000 0x1000>,
- <0x11e20000 0x1000>,
- <0x11e70000 0x1000>,
- <0x11ea0000 0x1000>,
- <0x11f20000 0x1000>,
- <0x11f30000 0x1000>,
- <0x1000b000 0x1000>;
- reg-names = "iocfg0", "iocfg_rm", "iocfg_bm",
- "iocfg_bl", "iocfg_br", "iocfg_lm",
- "iocfg_lb", "iocfg_rt", "iocfg_lt",
- "iocfg_tl", "eint";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pio 0 0 220>;
- interrupt-controller;
- interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH 0>;
- #interrupt-cells = <2>;
-
- spi1-default-pins {
- pins-cs-mosi-clk {
- pinmux = <PINMUX_GPIO157__FUNC_SPI1_A_CSB>,
- <PINMUX_GPIO159__FUNC_SPI1_A_MO>,
- <PINMUX_GPIO156__FUNC_SPI1_A_CLK>;
- bias-disable;
- };
-
- pins-miso {
- pinmux = <PINMUX_GPIO158__FUNC_SPI1_A_MI>;
- bias-pull-down;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
deleted file mode 100644
index 66fe17e9e4d3..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
+++ /dev/null
@@ -1,287 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8195.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mediatek MT8195 Pin Controller
-
-maintainers:
- - Sean Wang <sean.wang@mediatek.com>
-
-description: |
- The Mediatek's Pin controller is used to control SoC pins.
-
-properties:
- compatible:
- const: mediatek,mt8195-pinctrl
-
- gpio-controller: true
-
- '#gpio-cells':
- description: |
- Number of cells in GPIO specifier. Since the generic GPIO binding is used,
- the amount of cells must be specified as 2. See the below
- mentioned gpio binding representation for description of particular cells.
- const: 2
-
- gpio-ranges:
- description: gpio valid number range.
- maxItems: 1
-
- gpio-line-names: true
-
- reg:
- description: |
- Physical address base for gpio base registers. There are 8 GPIO
- physical address base in mt8195.
- maxItems: 8
-
- reg-names:
- description: |
- Gpio base register names.
- maxItems: 8
-
- interrupt-controller: true
-
- '#interrupt-cells':
- const: 2
-
- interrupts:
- description: The interrupt outputs to sysirq.
- maxItems: 1
-
- mediatek,rsel-resistance-in-si-unit:
- type: boolean
- description: |
- Identifying i2c pins pull up/down type which is RSEL. It can support
- RSEL define or si unit value(ohm) to set different resistance.
-
-# PIN CONFIGURATION NODES
-patternProperties:
- '-pins$':
- type: object
- additionalProperties: false
- patternProperties:
- '^pins':
- type: object
- additionalProperties: false
- description: |
- A pinctrl node should contain at least one subnodes representing the
- pinctrl groups available on the machine. Each subnode will list the
- pins it needs, and how they should be configured, with regard to muxer
- configuration, pullups, drive strength, input enable/disable and
- input schmitt.
- An example of using macro:
- pincontroller {
- /* GPIO0 set as multifunction GPIO0 */
- gpio-pins {
- pins {
- pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
- }
- };
- /* GPIO8 set as multifunction SDA0 */
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
- }
- };
- };
- $ref: "pinmux-node.yaml"
-
- properties:
- pinmux:
- description: |
- Integer array, represents gpio pin number and mux setting.
- Supported pin number and mux varies for different SoCs, and are
- defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h
- directly.
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
-
- drive-strength-microamp:
- enum: [125, 250, 500, 1000]
-
- bias-pull-down:
- oneOf:
- - type: boolean
- - enum: [100, 101, 102, 103]
- description: mt8195 pull down PUPD/R0/R1 type define value.
- - enum: [200, 201, 202, 203, 204, 205, 206, 207]
- description: mt8195 pull down RSEL type define value.
- - enum: [75000, 5000]
- description: mt8195 pull down RSEL type si unit value(ohm).
- description: |
- For pull down type is normal, it don't need add RSEL & R1R0 define
- and resistance value.
- For pull down type is PUPD/R0/R1 type, it can add R1R0 define to
- set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
- "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
- "MTK_PUPD_SET_R1R0_11" define in mt8195.
- For pull down type is RSEL, it can add RSEL define & resistance
- value(ohm) to set different resistance by identifying property
- "mediatek,rsel-resistance-in-si-unit".
- It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001"
- & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011"
- & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101"
- & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111"
- define in mt8195. It can also support resistance value(ohm)
- "75000" & "5000" in mt8195.
-
- An example of using RSEL define:
- pincontroller {
- i2c0_pin {
- pins {
- pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
- bias-pull-down = <MTK_PULL_SET_RSEL_001>;
- }
- };
- };
- An example of using si unit resistance value(ohm):
- &pio {
- mediatek,rsel-resistance-in-si-unit;
- }
- pincontroller {
- i2c0_pin {
- pins {
- pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
- bias-pull-down = <75000>;
- }
- };
- };
-
- bias-pull-up:
- oneOf:
- - type: boolean
- - enum: [100, 101, 102, 103]
- description: mt8195 pull up PUPD/R0/R1 type define value.
- - enum: [200, 201, 202, 203, 204, 205, 206, 207]
- description: mt8195 pull up RSEL type define value.
- - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000]
- description: mt8195 pull up RSEL type si unit value(ohm).
- description: |
- For pull up type is normal, it don't need add RSEL & R1R0 define
- and resistance value.
- For pull up type is PUPD/R0/R1 type, it can add R1R0 define to
- set different resistance. It can support "MTK_PUPD_SET_R1R0_00" &
- "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" &
- "MTK_PUPD_SET_R1R0_11" define in mt8195.
- For pull up type is RSEL, it can add RSEL define & resistance
- value(ohm) to set different resistance by identifying property
- "mediatek,rsel-resistance-in-si-unit".
- It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001"
- & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011"
- & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101"
- & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111"
- define in mt8195. It can also support resistance value(ohm)
- "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" &
- "75000" in mt8195.
- An example of using RSEL define:
- pincontroller {
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
- bias-pull-up = <MTK_PULL_SET_RSEL_001>;
- }
- };
- };
- An example of using si unit resistance value(ohm):
- &pio {
- mediatek,rsel-resistance-in-si-unit;
- }
- pincontroller {
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
- bias-pull-up = <1000>;
- }
- };
- };
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- input-enable: true
-
- input-disable: true
-
- input-schmitt-enable: true
-
- input-schmitt-disable: true
-
- required:
- - pinmux
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/pinctrl/mt8195-pinfunc.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #
- pio: pinctrl@10005000 {
- compatible = "mediatek,mt8195-pinctrl";
- reg = <0x10005000 0x1000>,
- <0x11d10000 0x1000>,
- <0x11d30000 0x1000>,
- <0x11d40000 0x1000>,
- <0x11e20000 0x1000>,
- <0x11eb0000 0x1000>,
- <0x11f40000 0x1000>,
- <0x1000b000 0x1000>;
- reg-names = "iocfg0", "iocfg_bm", "iocfg_bl",
- "iocfg_br", "iocfg_lm", "iocfg_rb",
- "iocfg_tl", "eint";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pio 0 0 144>;
- interrupt-controller;
- interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
- #interrupt-cells = <2>;
-
- pio-pins {
- pins {
- pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
- output-low;
- };
- };
-
- spi0-pins {
- pins-spi {
- pinmux = <PINMUX_GPIO132__FUNC_SPIM0_CSB>,
- <PINMUX_GPIO134__FUNC_SPIM0_MO>,
- <PINMUX_GPIO133__FUNC_SPIM0_CLK>;
- bias-disable;
- };
- pins-spi-mi {
- pinmux = <PINMUX_GPIO135__FUNC_SPIM0_MI>;
- bias-pull-down;
- };
- };
-
- i2c0-pins {
- pins {
- pinmux = <PINMUX_GPIO8__FUNC_SDA0>,
- <PINMUX_GPIO9__FUNC_SCL0>;
- bias-disable;
- drive-strength-microamp = <1000>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
index 939cb5b6ffea..6ad49e51c72e 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
@@ -40,7 +40,7 @@ on default.
Valid values for function properties are: gpio.
-Theres is also not customised properties for any GPIO.
+There are also not customised properties for any GPIO.
Example:
--------
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
deleted file mode 100644
index bfd222b05495..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ /dev/null
@@ -1,262 +0,0 @@
-One-register-per-pin type device tree based pinctrl driver
-
-Required properties:
-- compatible : "pinctrl-single" or "pinconf-single".
- "pinctrl-single" means that pinconf isn't supported.
- "pinconf-single" means that generic pinconf is supported.
-
-- reg : offset and length of the register set for the mux registers
-
-- #pinctrl-cells : number of cells in addition to the index, set to 1
- or 2 for pinctrl-single,pins and set to 2 for pinctrl-single,bits
-
-- pinctrl-single,register-width : pinmux register access width in bits
-
-- pinctrl-single,function-mask : mask of allowed pinmux function bits
- in the pinmux register
-
-Optional properties:
-- pinctrl-single,function-off : function off mode for disabled state if
- available and same for all registers; if not specified, disabling of
- pin functions is ignored
-
-- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
- more than one pin, for which "pinctrl-single,function-mask" property specifies
- position mask of pin.
-
-- pinctrl-single,drive-strength : array of value that are used to configure
- drive strength in the pinmux register. They're value of drive strength
- current and drive strength mask.
-
- /* drive strength current, mask */
- pinctrl-single,power-source = <0x30 0xf0>;
-
-- pinctrl-single,bias-pullup : array of value that are used to configure the
- input bias pullup in the pinmux register.
-
- /* input, enabled pullup bits, disabled pullup bits, mask */
- pinctrl-single,bias-pullup = <0 1 0 1>;
-
-- pinctrl-single,bias-pulldown : array of value that are used to configure the
- input bias pulldown in the pinmux register.
-
- /* input, enabled pulldown bits, disabled pulldown bits, mask */
- pinctrl-single,bias-pulldown = <2 2 0 2>;
-
- * Two bits to control input bias pullup and pulldown: User should use
- pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
- pullup, and the other one bit means pulldown.
- * Three bits to control input bias enable, pullup and pulldown. User should
- use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
- enable bit should be included in pullup or pulldown bits.
- * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
- pinctrl-single,bias-disable. Because pinctrl single driver could implement
- it by calling pulldown, pullup disabled.
-
-- pinctrl-single,input-schmitt : array of value that are used to configure
- input schmitt in the pinmux register. In some silicons, there're two input
- schmitt value (rising-edge & falling-edge) in the pinmux register.
-
- /* input schmitt value, mask */
- pinctrl-single,input-schmitt = <0x30 0x70>;
-
-- pinctrl-single,input-schmitt-enable : array of value that are used to
- configure input schmitt enable or disable in the pinmux register.
-
- /* input, enable bits, disable bits, mask */
- pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
-
-- pinctrl-single,low-power-mode : array of value that are used to configure
- low power mode of this pin. For some silicons, the low power mode will
- control the output of the pin when the pad including the pin enter low
- power mode.
- /* low power mode value, mask */
- pinctrl-single,low-power-mode = <0x288 0x388>;
-
-- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
- range. They're value of subnode phandle, pin base in pinctrl device, pin
- number in this range, GPIO function value of this GPIO range.
- The number of parameters is depend on #pinctrl-single,gpio-range-cells
- property.
-
- /* pin base, nr pins & gpio function */
- pinctrl-single,gpio-range = <&range 0 3 0>, <&range 3 9 1>;
-
-- interrupt-controller : standard interrupt controller binding if using
- interrupts for wake-up events for example. In this case pinctrl-single
- is set up as a chained interrupt controller and the wake-up interrupts
- can be requested by the drivers using request_irq().
-
-- #interrupt-cells : standard interrupt binding if using interrupts
-
-This driver assumes that there is only one register for each pin (unless the
-pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
-specified in the pinctrl-bindings.txt document in this directory.
-
-The pin configuration nodes for pinctrl-single are specified as pinctrl
-register offset and values using pinctrl-single,pins. Only the bits specified
-in pinctrl-single,function-mask are updated.
-
-When #pinctrl-cells = 1, then setting a pin for a device could be done with:
-
- pinctrl-single,pins = <0xdc 0x118>;
-
-Where 0xdc is the offset from the pinctrl register base address for the device
-pinctrl register, and 0x118 contains the desired value of the pinctrl register.
-
-When #pinctrl-cells = 2, then setting a pin for a device could be done with:
-
- pinctrl-single,pins = <0xdc 0x30 0x07>;
-
-Where 0x30 is the pin configuration value and 0x07 is the pin mux mode value.
-These two values are OR'd together to produce the value stored at offset 0xdc.
-See the device example and static board pins example below for more information.
-
-In case when one register changes more than one pin's mux the
-pinctrl-single,bits need to be used which takes three parameters:
-
- pinctrl-single,bits = <0xdc 0x18 0xff>;
-
-Where 0xdc is the offset from the pinctrl register base address for the
-device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
-be used when applying this change to the register.
-
-
-Optional sub-node: In case some pins could be configured as GPIO in the pinmux
-register, those pins could be defined as a GPIO range. This sub-node is required
-by pinctrl-single,gpio-range property.
-
-Required properties in sub-node:
-- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
- pinctrl-single,gpio-range property.
-
- range: gpio-range {
- #pinctrl-single,gpio-range-cells = <3>;
- };
-
-
-Example:
-
-/* SoC common file */
-
-/* first controller instance for pins in core domain */
-pmx_core: pinmux@4a100040 {
- compatible = "pinctrl-single";
- reg = <0x4a100040 0x0196>;
- #address-cells = <1>;
- #size-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- pinctrl-single,register-width = <16>;
- pinctrl-single,function-mask = <0xffff>;
-};
-
-/* second controller instance for pins in wkup domain */
-pmx_wkup: pinmux@4a31e040 {
- compatible = "pinctrl-single";
- reg = <0x4a31e040 0x0038>;
- #address-cells = <1>;
- #size-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- pinctrl-single,register-width = <16>;
- pinctrl-single,function-mask = <0xffff>;
-};
-
-control_devconf0: pinmux@48002274 {
- compatible = "pinctrl-single";
- reg = <0x48002274 4>; /* Single register */
- #address-cells = <1>;
- #size-cells = <0>;
- pinctrl-single,bit-per-mux;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x5F>;
-};
-
-/* third controller instance for pins in gpio domain */
-pmx_gpio: pinmux@d401e000 {
- compatible = "pinconf-single";
- reg = <0xd401e000 0x0330>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <7>;
-
- /* sparse GPIO range could be supported */
- pinctrl-single,gpio-range = <&range 0 3 0>, <&range 3 9 1>,
- <&range 12 1 0>, <&range 13 29 1>,
- <&range 43 1 0>, <&range 44 49 1>,
- <&range 94 1 1>, <&range 96 2 1>;
-
- range: gpio-range {
- #pinctrl-single,gpio-range-cells = <3>;
- };
-};
-
-
-/* board specific .dts file */
-
-&pmx_core {
-
- /*
- * map all board specific static pins enabled by the pinctrl driver
- * itself during the boot (or just set them up in the bootloader)
- */
- pinctrl-names = "default";
- pinctrl-0 = <&board_pins>;
-
- board_pins: pinmux_board_pins {
- pinctrl-single,pins = <
- 0x6c 0xf
- 0x6e 0xf
- 0x70 0xf
- 0x72 0xf
- >;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins = <
- 0x208 0 /* UART0_RXD (IOCFG138) */
- 0x20c 0 /* UART0_TXD (IOCFG139) */
- >;
- pinctrl-single,bias-pulldown = <0 2 2>;
- pinctrl-single,bias-pullup = <0 1 1>;
- };
-
- /* map uart2 pins */
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- 0xd8 0x118
- 0xda 0
- 0xdc 0x118
- 0xde 0
- >;
- };
-};
-
-&control_devconf0 {
- mcbsp1_pins: pinmux_mcbsp1_pins {
- pinctrl-single,bits = <
- 0x00 0x18 0x18 /* FSR/CLKR signal from FSX/CLKX pin */
- >;
- };
-
- mcbsp2_clks_pins: pinmux_mcbsp2_clks_pins {
- pinctrl-single,bits = <
- 0x00 0x40 0x40 /* McBSP2 CLKS from McBSP_CLKS pin */
- >;
- };
-
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_pins>;
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
new file mode 100644
index 000000000000..9135788cf62e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
@@ -0,0 +1,220 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Pin Controller with a Single Register for One or More Pins
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description:
+ Some pin controller devices use a single register for one or more pins. The
+ range of pin control registers can vary from one to many for each controller
+ instance. Some SoCs from Altera, Broadcom, HiSilicon, Ralink, and TI have this
+ kind of pin controller instances.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - pinctrl-single
+ - pinconf-single
+ - items:
+ - enum:
+ - ti,am437-padconf
+ - ti,am62l-padconf
+ - ti,am654-padconf
+ - ti,dra7-padconf
+ - ti,omap2420-padconf
+ - ti,omap2430-padconf
+ - ti,omap3-padconf
+ - ti,omap4-padconf
+ - ti,omap5-padconf
+ - ti,j7200-padconf
+ - const: pinctrl-single
+ - items:
+ - enum:
+ - marvell,pxa1908-padconf
+ - const: pinconf-single
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ '#pinctrl-cells':
+ description:
+ Number of cells. Usually 2, consisting of register offset, pin configuration
+ value, and pinmux mode. Some controllers may use 1 for just offset and value.
+ enum: [ 1, 2 ]
+
+ pinctrl-single,bit-per-mux:
+ description: Optional flag to indicate register controls more than one pin
+ type: boolean
+
+ pinctrl-single,function-mask:
+ description: Mask of the allowed register bits
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pinctrl-single,function-off:
+ description: Optional function off mode for disabled state
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ pinctrl-single,register-width:
+ description: Width of pin specific bits in the register
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 8, 16, 32 ]
+
+ pinctrl-single,gpio-range:
+ description: Optional list of pin base, nr pins & gpio function
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle of a gpio-range node
+ - description: pin base
+ - description: number of pins
+ - description: gpio function
+
+ '#gpio-range-cells':
+ description: No longer needed, may exist in older files for gpio-ranges
+ deprecated: true
+ const: 3
+
+ gpio-range:
+ description: Optional node for gpio range cells
+ type: object
+ additionalProperties: false
+ properties:
+ '#pinctrl-single,gpio-range-cells':
+ description: Number of gpio range cells
+ const: 3
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+patternProperties:
+ '-pins(-[0-9]+)?$|-pin$':
+ description:
+ Pin group node name using naming ending in -pins followed by an optional
+ instance number
+ type: object
+ additionalProperties: false
+
+ properties:
+ pinctrl-single,pins:
+ description:
+ Array of pins as described in pinmux-node.yaml for pinctrl-pin-array
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ pinctrl-single,bits:
+ description: Register bit configuration for pinctrl-single,bit-per-mux
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: register offset
+ - description: value
+ - description: pin bitmask in the register
+
+ pinctrl-single,bias-pullup:
+ description: Optional bias pull up configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: input
+ - description: enabled pull up bits
+ - description: disabled pull up bits
+ - description: bias pull up mask
+
+ pinctrl-single,bias-pulldown:
+ description: Optional bias pull down configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: input
+ - description: enabled pull down bits
+ - description: disabled pull down bits
+ - description: bias pull down mask
+
+ pinctrl-single,drive-strength:
+ description: Optional drive strength configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: drive strength current
+ - description: drive strength mask
+
+ pinctrl-single,input-schmitt:
+ description: Optional schmitt strength configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: schmitt strength current
+ - description: schmitt strength mask
+
+ pinctrl-single,input-schmitt-enable:
+ description: Optional input schmitt configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: input
+ - description: enable bits
+ - description: disable bits
+ - description: input schmitt mask
+
+ pinctrl-single,low-power-mode:
+ description: Optional low power mode configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: low power mode value
+ - description: low power mode mask
+
+ pinctrl-single,slew-rate:
+ description: Optional slew rate configuration
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: slew rate
+ - description: slew rate mask
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - pinctrl-single,register-width
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pinmux@4a100040 {
+ compatible = "pinctrl-single";
+ reg = <0x4a100040 0x0196>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pinctrl-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0xffff>;
+ pinctrl-single,gpio-range = <&range 0 3 0>;
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+
+ uart2-pins {
+ pinctrl-single,pins =
+ <0xd8 0x118>,
+ <0xda 0>,
+ <0xdc 0x118>,
+ <0xde 0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
deleted file mode 100644
index 4023bad2fe39..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-SEMTECH SX150x GPIO expander bindings
-
-Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
-../interrupt-controller/interrupts.txt for generic information regarding
-pin controller, GPIO, and interrupt bindings.
-
-Required properties:
-- compatible: should be one of :
- "semtech,sx1501q",
- "semtech,sx1502q",
- "semtech,sx1503q",
- "semtech,sx1504q",
- "semtech,sx1505q",
- "semtech,sx1506q",
- "semtech,sx1507q",
- "semtech,sx1508q",
- "semtech,sx1509q".
-
-- reg: The I2C slave address for this device.
-
-- #gpio-cells: Should be 2. The first cell is the GPIO number and the
- second cell is used to specify optional parameters:
- bit 0: polarity (0: normal, 1: inverted)
-
-- gpio-controller: Marks the device as a GPIO controller.
-
-Optional properties :
-- interrupts: Interrupt specifier for the controllers interrupt.
-
-- interrupt-controller: Marks the device as a interrupt controller.
-
-- semtech,probe-reset: Will trigger a reset of the GPIO expander on probe,
- only for sx1507q, sx1508q and sx1509q
-
-The GPIO expander can optionally be used as an interrupt controller, in
-which case it uses the default two cell specifier.
-
-Required properties for pin configuration sub-nodes:
- - pins: List of pins to which the configuration applies.
-
-Optional properties for pin configuration sub-nodes:
-----------------------------------------------------
- - bias-disable: disable any pin bias, except the OSCIO pin
- - bias-pull-up: pull up the pin, except the OSCIO pin
- - bias-pull-down: pull down the pin, except the OSCIO pin
- - bias-pull-pin-default: use pin-default pull state, except the OSCIO pin
- - drive-push-pull: drive actively high and low
- - drive-open-drain: drive with open drain only for sx1507q, sx1508q and sx1509q and except the OSCIO pin
- - output-low: set the pin to output mode with low level
- - output-high: set the pin to output mode with high level
-
-Example:
-
- i2c0gpio-expander@20{
- #gpio-cells = <2>;
- #interrupt-cells = <2>;
- compatible = "semtech,sx1506q";
- reg = <0x20>;
- interrupt-parent = <&gpio_1>;
- interrupts = <16 0>;
-
- gpio-controller;
- interrupt-controller;
-
- pinctrl-names = "default";
- pinctrl-0 = <&gpio1_cfg_pins>;
-
- gpio1_cfg_pins: gpio1-cfg {
- pins = "gpio1";
- bias-pull-up;
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml b/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
index 551df3d9b809..ca9d246d46fe 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/pinmux-node.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic pin multiplexing node schema
+title: Generic Pin Multiplexing Node
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
@@ -31,7 +31,7 @@ description: |
};
};
state_1_node_a {
- spi0 {
+ spi {
function = "spi0";
groups = "spi0pins";
};
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
deleted file mode 100644
index 4e90ddd77784..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-Qualcomm APQ8064 TLMM block
-
-Required properties:
-- compatible: "qcom,apq8064-pinctrl"
-- reg: Should be the base address and length of the TLMM block.
-- interrupts: Should be the parent IRQ of the TLMM block.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two.
- The first cell is the gpio pin number and the
- second cell is used for optional parameters.
-- gpio-ranges: see ../gpio/gpio.txt
-
-Optional properties:
-
-- gpio-reserved-ranges: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Qualcomm's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
- pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength,
- output-low, output-high.
-
-Non-empty subnodes must specify the 'pins' property.
-
-Valid values for pins are:
- gpio0-gpio89
-
-Valid values for function are:
- cam_mclk, codec_mic_i2s, codec_spkr_i2s, gp_clk_0a, gp_clk_0b, gp_clk_1a,
- gp_clk_1b, gp_clk_2a, gp_clk_2b, gpio, gsbi1, gsbi2, gsbi3, gsbi4,
- gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6,
- gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1,
- gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm,
- riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, ps_hold
-
-Example:
-
- msmgpio: pinctrl@800000 {
- compatible = "qcom,apq8064-pinctrl";
- reg = <0x800000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 16 0x4>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&gsbi5_uart_default>;
- gpio-ranges = <&msmgpio 0 0 90>;
-
- gsbi5_uart_default: gsbi5_uart_default {
- mux {
- pins = "gpio51", "gpio52";
- function = "gsbi5";
- };
-
- tx {
- pins = "gpio51";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio52";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.yaml
new file mode 100644
index 000000000000..f251dcd4bb7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,apq8064-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. APQ8064 TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm APQ8064 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,apq8064-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-apq8064-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-apq8064-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-apq8064-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-8][0-9])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc3_clk, sdc3_cmd, sdc3_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ cam_mclk, codec_mic_i2s, codec_spkr_i2s, gp_clk_0a,
+ gp_clk_0b, gp_clk_1a, gp_clk_1b, gp_clk_2a, gp_clk_2b,
+ gpio, gsbi1, gsbi2, gsbi3, gsbi4, gsbi4_cam_i2c,
+ gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3,
+ gsbi6, gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3,
+ gsbi7, gsbi7_spi_cs1, gsbi7_spi_cs2, gsbi7_spi_cs3,
+ gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, riva_wlan,
+ sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic,
+ ps_hold ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@800000 {
+ compatible = "qcom,apq8064-pinctrl";
+ reg = <0x800000 0x4000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 90>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart-state {
+ rx-pins {
+ pins = "gpio52";
+ function = "gsbi5";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio51";
+ function = "gsbi5";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
deleted file mode 100644
index c9782397ff14..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
+++ /dev/null
@@ -1,188 +0,0 @@
-Qualcomm APQ8084 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8960 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,apq8084-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode. Valid pins are:
- gpio0-gpio146,
- sdc1_clk,
- sdc1_cmd,
- sdc1_data
- sdc2_clk,
- sdc2_cmd,
- sdc2_data
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
- adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3,
- blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8,
- blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
- blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5,
- blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10,
- blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2, blsp_uart3,
- blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8,
- blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12,
- blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5,
- blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10,
- blsp_uim11, blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2,
- cam_mclk3, cci_async, cci_async_in0, cci_i2c0, cci_i2c1,
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
- edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3, gcc_obt, gcc_vtt,i
- gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk, gp1_clk, gpio,
- hdmi_cec, hdmi_ddc, hdmi_dtest, hdmi_hpd, hdmi_rcv, hsic,
- ldo_en, ldo_update, mdp_vsync, pci_e0, pci_e0_n, pci_e0_rst,
- pci_e1, pci_e1_rst, pci_e1_rst_n, pci_e1_clkreq_n, pri_mi2s,
- qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n,
- sd_write, sdc_emmc_mode, sdc3, sdc4, sec_mi2s, slimbus,
- spdif_tx, spkr_i2s, spkr_i2s_ws, spss_geni, ter_mi2s, tsif1,
- tsif2, uim, uim_batt_alarm
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@fd510000 {
- compatible = "qcom,apq8084-pinctrl";
- reg = <0xfd510000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 147>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 208 0>;
-
- uart2: uart2-default {
- mux {
- pins = "gpio4", "gpio5";
- function = "blsp_uart2";
- };
-
- tx {
- pins = "gpio4";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio5";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml
new file mode 100644
index 000000000000..38877d8b97ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,apq8084-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. APQ8084 TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm APQ8084 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,apq8084-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-apq8084-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-apq8084-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-apq8084-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-6])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
+ sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3,
+ blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8,
+ blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
+ blsp_spi1, blsp_spi1_cs1, blsp_spi1_cs2, blsp_spi1_cs3,
+ blsp_spi2, blsp_spi3, blsp_spi3_cs1, blsp_spi3_cs2,
+ blsp_spi3_cs3, blsp_spi4, blsp_spi5, blsp_spi6,
+ blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10,
+ blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3,
+ blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2,
+ blsp_uart3, blsp_uart4, blsp_uart5, blsp_uart6,
+ blsp_uart7, blsp_uart8, blsp_uart9, blsp_uart10,
+ blsp_uart11, blsp_uart12, blsp_uim1, blsp_uim2,
+ blsp_uim3, blsp_uim4, blsp_uim5, blsp_uim6, blsp_uim7,
+ blsp_uim8, blsp_uim9, blsp_uim10, blsp_uim11,
+ blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2, cam_mclk3,
+ cci_async, cci_async_in0, cci_i2c0, cci_i2c1,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+ cci_timer4, edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3,
+ gcc_obt, gcc_vtt, gp_mn, gp_pdm0, gp_pdm1, gp_pdm2,
+ gp0_clk, gp1_clk, gpio, hdmi_cec, hdmi_ddc, hdmi_dtest,
+ hdmi_hpd, hdmi_rcv, hsic, ldo_en, ldo_update,
+ mdp_vsync, pci_e0, pci_e0_n, pci_e0_rst, pci_e1,
+ pci_e1_rst, pci_e1_rst_n, pci_e1_clkreq_n, pri_mi2s,
+ qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n,
+ sd_write, sdc_emmc_mode, sdc3, sdc4, sec_mi2s, slimbus,
+ spdif_tx, spkr_i2s, spkr_i2s_ws, spss_geni, ter_mi2s,
+ tsif1, tsif2, uim, uim_batt_alarm ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@fd510000 {
+ compatible = "qcom,apq8084-pinctrl";
+ reg = <0xfd510000 0x4000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 147>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart-state {
+ rx-pins {
+ pins = "gpio5";
+ function = "blsp_uart2";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio4";
+ function = "blsp_uart2";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml
new file mode 100644
index 000000000000..d2b0cfeffb50
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,glymur-tlmm.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,glymur-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Glymur TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm Glymur SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,glymur-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 125
+
+ gpio-line-names:
+ maxItems: 250
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-glymur-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-glymur-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-glymur-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, resout_gpio_n, aoss_cti, asc_cci, atest_char, atest_usb,
+ audio_ext_mclk0, audio_ext_mclk1, audio_ref_clk, cam_asc_mclk4,
+ cam_mclk, cci_async_in, cci_i2c_scl, cci_i2c_sda, cci_timer,
+ cmu_rng, cri_trng, dbg_out_clk, ddr_bist_complete,
+ ddr_bist_fail, ddr_bist_start, ddr_bist_stop, ddr_pxi,
+ edp0_hot, edp0_lcd, edp1_lcd, egpio, eusb0_ac_en, eusb1_ac_en,
+ eusb2_ac_en, eusb3_ac_en, eusb5_ac_en, eusb6_ac_en, gcc_gp1,
+ gcc_gp2, gcc_gp3, host2wlan_sol, i2c0_s_scl, i2c0_s_sda,
+ i2s0_data, i2s0_sck, i2s0_ws, i2s1_data, i2s1_sck, i2s1_ws,
+ ibi_i3c, jitter_bist, mdp_vsync_out, mdp_vsync_e, mdp_vsync_p,
+ mdp_vsync_s, pcie3a_clk, pcie3a_rst_n, pcie3b_clk,
+ pcie4_clk_req_n, pcie5_clk_req_n, pcie6_clk_req_n, phase_flag,
+ pll_bist_sync, pll_clk_aux, pmc_oca_n, pmc_uva_n, prng_rosc,
+ qdss_cti, qdss_gpio, qspi, qup0_se0, qup0_se1, qup0_se2,
+ qup0_se3_l0, qup0_se3, qup0_se4, qup0_se5, qup0_se6, qup0_se7,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4, qup1_se5,
+ qup1_se6, qup1_se7, qup2_se0, qup2_se1, qup2_se2, qup2_se3,
+ qup2_se4, qup2_se5, qup2_se6, qup2_se7, qup3_se0, qup3_se1,
+ sd_write_protect, sdc4_clk, sdc4_cmd, sdc4_data, smb_acok_n,
+ sys_throttle, tb_trig_sdc2, tb_trig_sdc4, tmess_prng,
+ tsense_pwm, tsense_therm, usb0_dp, usb0_phy_ps, usb0_sbrx,
+ usb0_sbtx, usb0_tmu, usb1_dbg, usb1_dp, usb1_phy_ps, usb1_sbrx,
+ usb1_sbtx, usb1_tmu, usb2_dp, usb2_phy_ps, usb2_sbrx, usb2_sbtx,
+ usb2_tmu, vsense_trigger_mirnat, wcn_sw, wcn_sw_ctrl ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,glymur-tlmm";
+ reg = <0x0f100000 0xf00000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 249>;
+ wakeup-parent = <&pdc>;
+ gpio-reserved-ranges = <4 4>, <10 2>, <33 3>, <44 4>;
+ qup_uart21_default: qup-uart21-default-state {
+ tx-pins {
+ pins = "gpio86";
+ function = "qup2_se5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ rx-pins {
+ pins = "gpio87";
+ function = "qup2_se5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt
deleted file mode 100644
index 97858a7c07a2..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt
+++ /dev/null
@@ -1,85 +0,0 @@
-Qualcomm Atheros IPQ4019 TLMM block
-
-This is the Top Level Mode Multiplexor block found on the Qualcomm IPQ8019
-platform, it provides pinctrl, pinmux, pinconf, and gpiolib facilities.
-
-Required properties:
-- compatible: "qcom,ipq4019-pinctrl"
-- reg: Should be the base address and length of the TLMM block.
-- interrupts: Should be the parent IRQ of the TLMM block.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two.
- The first cell is the gpio pin number and the
- second cell is used for optional parameters.
-- gpio-ranges: see ../gpio/gpio.txt
-
-Optional properties:
-
-- gpio-reserved-ranges: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
- pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-open-drain,
- drive-strength.
-
-Non-empty subnodes must specify the 'pins' property.
-Note that not all properties are valid for all pins.
-
-
-Valid values for qcom,pins are:
- gpio0-gpio99
- Supports mux, bias and drive-strength
-
-Valid values for qcom,function are:
-aud_pin, audio_pwm, blsp_i2c0, blsp_i2c1, blsp_spi0, blsp_spi1, blsp_uart0,
-blsp_uart1, chip_rst, gpio, i2s_rx, i2s_spdif_in, i2s_spdif_out, i2s_td, i2s_tx,
-jtag, led0, led1, led2, led3, led4, led5, led6, led7, led8, led9, led10, led11,
-mdc, mdio, pcie, pmu, prng_rosc, qpic, rgmii, rmii, sdio, smart0, smart1,
-smart2, smart3, tm, wifi0, wifi1
-
-Example:
-
- tlmm: pinctrl@1000000 {
- compatible = "qcom,ipq4019-pinctrl";
- reg = <0x1000000 0x300000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 100>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 208 0>;
-
- serial_pins: serial_pinmux {
- mux {
- pins = "gpio60", "gpio61";
- function = "blsp_uart0";
- bias-disable;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.yaml
new file mode 100644
index 000000000000..cc5de9f77680
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq4019-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. IPQ4019 TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ4019 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,ipq4019-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq4019-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq4019-tlmm-state"
+ additionalProperties: false
+
+ "-hog(-[0-9]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+$defs:
+ qcom-ipq4019-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-9][0-9])$"
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ aud_pin, audio_pwm, blsp_i2c0, blsp_i2c1, blsp_spi0,
+ blsp_spi1, blsp_uart0, blsp_uart1, chip_rst, gpio,
+ i2s_rx, i2s_spdif_in, i2s_spdif_out, i2s_td, i2s_tx,
+ jtag, led0, led1, led2, led3, led4, led5, led6, led7,
+ led8, led9, led10, led11, mdc, mdio, pcie, pmu,
+ prng_rosc, qpic, rgmii, rmii, sdio, smart0, smart1,
+ smart2, smart3, tm, wifi0, wifi1 ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq4019-pinctrl";
+ reg = <0x01000000 0x300000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 100>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart-state {
+ pins = "gpio16", "gpio17";
+ function = "blsp_uart0";
+ bias-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml
new file mode 100644
index 000000000000..96635b2f6a27
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5018-tlmm.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5018-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ5018 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ5018 SoC.
+
+properties:
+ compatible:
+ const: qcom,ipq5018-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 24
+
+ gpio-line-names:
+ maxItems: 47
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq5018-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq5018-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq5018-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-3][0-9]|4[0-6])$"
+ minItems: 1
+ maxItems: 8
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, audio_pdm0, audio_pdm1, audio_rxbclk, audio_rxd,
+ audio_rxfsync, audio_rxmclk, audio_txbclk, audio_txd,
+ audio_txfsync, audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart0,
+ blsp0_uart1, blsp1_i2c0, blsp1_i2c1, blsp1_spi0, blsp1_spi1,
+ blsp1_uart0, blsp1_uart1, blsp1_uart2, blsp2_i2c0, blsp2_i2c1,
+ blsp2_spi, blsp2_spi0, blsp2_spi1, btss, burn0, burn1, cri_trng,
+ cri_trng0, cri_trng1, cxc_clk, cxc_data, dbg_out, eud_gpio,
+ gcc_plltest, gcc_tlmm, gpio, led0, led2, mac0, mac1, mdc, mdio,
+ pcie0_clk, pcie0_wake, pcie1_clk, pcie1_wake, pll_test,
+ prng_rosc, pwm0, pwm1, pwm2, pwm3, qdss_cti_trig_in_a0,
+ qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
+ qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
+ qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a,
+ qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
+ qdss_tracedata_a, qdss_tracedata_b, qspi_clk, qspi_cs,
+ qspi_data, reset_out, sdc1_clk, sdc1_cmd, sdc1_data, wci_txd,
+ wci_rxd, wsa_swrm, wsi_clk3, wsi_data3, wsis_reset, xfem ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq5018-tlmm";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 47>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio33";
+ function = "blsp1_uart1";
+ bias-pull-down;
+ };
+
+ tx-pins {
+ pins = "gpio34";
+ function = "blsp1_uart1";
+ bias-pull-down;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml
new file mode 100644
index 000000000000..22685c479983
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5332-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ5332 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ5332 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,ipq5332-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 27
+
+ gpio-line-names:
+ maxItems: 53
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq5332-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq5332-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq5332-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-4][0-9]|5[0-2])$"
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_char0, atest_char1, atest_char2, atest_char3,
+ atest_tic, audio_pri, audio_pri0, audio_pri1, audio_sec,
+ audio_sec0, audio_sec1, blsp0_i2c, blsp0_spi, blsp0_uart0,
+ blsp0_uart1, blsp1_i2c0, blsp1_i2c1, blsp1_spi0, blsp1_spi1,
+ blsp1_uart0, blsp1_uart1, blsp1_uart2, blsp2_i2c0, blsp2_i2c1,
+ blsp2_spi, blsp2_spi0, blsp2_spi1, core_voltage, cri_trng0,
+ cri_trng1, cri_trng2, cri_trng3, cxc_clk, cxc_data, dbg_out,
+ gcc_plltest, gcc_tlmm, gpio, lock_det, mac0, mac1, mdc0, mdc1,
+ mdio0, mdio1, pc, pcie0_clk, pcie0_wake, pcie1_clk, pcie1_wake,
+ pcie2_clk, pcie2_wake, pll_test, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, pta, pwm0, pwm1, pwm2, pwm3,
+ qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, qdss_cti_trig_in_b0,
+ qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
+ qdss_cti_trig_out_a1, qdss_cti_trig_out_b0,
+ qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_traceclk_b,
+ qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a,
+ qdss_tracedata_b, qspi_data, qspi_clk, qspi_cs, resout, rx0,
+ rx1, sdc_data, sdc_clk, sdc_cmd, tsens_max, wci_txd, wci_rxd,
+ wsi_clk, wsi_clk3, wsi_data, wsi_data3, wsis_reset, xfem ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq5332-tlmm";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ gpio-ranges = <&tlmm 0 0 53>;
+ interrupts = <GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+
+ serial0-state {
+ pins = "gpio18", "gpio19";
+ function = "blsp0_uart0";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml
new file mode 100644
index 000000000000..df284d3645c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5424-tlmm.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5424-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ5424 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ5424 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,ipq5424-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 25
+
+ gpio-line-names:
+ maxItems: 50
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq5424-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq5424-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq5424-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-4][0-9])$"
+ minItems: 1
+ maxItems: 50
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_char0, atest_char1, atest_char2, atest_char3,
+ atest_tic, audio_pri, audio_pri0, audio_pri1, audio_sec,
+ audio_sec0, audio_sec1, core_voltage, cri_trng0, cri_trng1,
+ cri_trng2, cri_trng3, cxc_clk, cxc_data, dbg_out, gcc_plltest,
+ gcc_tlmm, gpio, i2c0_scl, i2c0_sda, i2c1_scl, i2c1_sda, i2c11,
+ mac0, mac1, mdc_mst, mdc_slv, mdio_mst, mdio_slv, pcie0_clk,
+ pcie0_wake, pcie1_clk, pcie1_wake, pcie2_clk, pcie2_wake,
+ pcie3_clk, pcie3_wake, pll_test, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, PTA0_0, PTA0_1, PTA0_2, PTA10, PTA11,
+ pwm0, pwm1, pwm2, qdss_cti_trig_in_a0, qdss_cti_trig_out_a0,
+ qdss_cti_trig_in_a1, qdss_cti_trig_out_a1, qdss_cti_trig_in_b0,
+ qdss_cti_trig_out_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_b1,
+ qdss_traceclk_a, qdss_tracectl_a, qdss_tracedata_a, qspi_clk,
+ qspi_cs, qspi_data, resout, rx0, rx1, rx2, sdc_clk, sdc_cmd,
+ sdc_data, spi0_cs, spi0_clk, spi0_miso, spi0_mosi, spi1, spi10,
+ spi11, tsens_max, uart0, uart1, wci_txd, wci_rxd, wsi_clk, wsi_data ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq5424-tlmm";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ gpio-ranges = <&tlmm 0 0 50>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+
+ uart1_pins: uart1-state {
+ pins = "gpio43", "gpio44";
+ function = "uart1";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
index 931e5c190ead..ed00fbaec11b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml
@@ -7,11 +7,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. IPQ6018 TLMM block
maintainers:
- - Sricharan R <sricharan@codeaurora.org>
+ - Bjorn Andersson <andersson@kernel.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- IPQ6018 platform.
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ6018 SoC.
properties:
compatible:
@@ -21,35 +20,24 @@ properties:
maxItems: 1
interrupts:
- description: Specifies the TLMM summary IRQ
maxItems: 1
- interrupt-controller: true
-
- '#interrupt-cells':
- description:
- Specifies the PIN numbers and Flags, as defined in defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
-#PIN CONFIGURATION NODES
patternProperties:
- '-pinmux$':
- type: object
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq6018-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq6018-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq6018-tlmm-state:
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -63,7 +51,7 @@ patternProperties:
sdc2_data, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2,
qdsd_data3 ]
minItems: 1
- maxItems: 4
+ maxItems: 16
function:
description:
@@ -72,12 +60,12 @@ patternProperties:
enum: [ adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char,
atest_char0, atest_char1, atest_char2, atest_char3, atest_combodac,
atest_gpsadc0, atest_gpsadc1, atest_tsens, atest_wlan0,
- atest_wlan1, backlight_en, bimc_dte0, bimc_dte1, blsp1_i2c,
- blsp2_i2c, blsp3_i2c, blsp4_i2c, blsp5_i2c, blsp6_i2c, blsp1_spi,
+ atest_wlan1, backlight_en, bimc_dte0, bimc_dte1, blsp0_i2c, blsp1_i2c,
+ blsp2_i2c, blsp3_i2c, blsp4_i2c, blsp5_i2c, blsp0_spi, blsp1_spi,
blsp1_spi_cs1, blsp1_spi_cs2, blsp1_spi_cs3, blsp2_spi,
blsp2_spi_cs1, blsp2_spi_cs2, blsp2_spi_cs3, blsp3_spi,
blsp3_spi_cs1, blsp3_spi_cs2, blsp3_spi_cs3, blsp4_spi, blsp5_spi,
- blsp6_spi, blsp1_uart, blsp2_uart, blsp1_uim, blsp2_uim, cam1_rst,
+ blsp0_uart, blsp1_uart, blsp2_uart, blsp1_uim, blsp2_uim, cam1_rst,
cam1_standby, cam_mclk0, cam_mclk1, cci_async, cci_i2c, cci_timer0,
cci_timer1, cci_timer2, cdc_pdm0, codec_mad, dbg_out, display_5v,
dmic0_clk, dmic0_data, dsi_rst, ebi0_wrcdc, euro_us, ext_lpass,
@@ -92,64 +80,39 @@ patternProperties:
qdss_ctitrig_in_b0, qdss_ctitrig_in_b1, qdss_ctitrig_out_a0,
qdss_ctitrig_out_a1, qdss_ctitrig_out_b0, qdss_ctitrig_out_b1,
qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
- qdss_tracedata_a, qdss_tracedata_b, reset_n, sd_card, sd_write,
- sec_mi2s, smb_int, ssbi_wtr0, ssbi_wtr1, uim1, uim2, uim3,
- uim_batt, wcss_bt, wcss_fm, wcss_wlan, webcam1_rst ]
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
+ qdss_tracedata_a, qdss_tracedata_b, qpic_pad, reset_n, sd_card,
+ sd_write, sec_mi2s, smb_int, ssbi_wtr0, ssbi_wtr1, uim1, uim2,
+ uim3, uim_batt, wcss_bt, wcss_fm, wcss_wlan, webcam1_rst ]
required:
- pins
- - function
-
- additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@1000000 {
- compatible = "qcom,ipq6018-pinctrl";
- reg = <0x01000000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 80>;
-
- serial3-pinmux {
- pins = "gpio44", "gpio45";
- function = "blsp2_uart";
- drive-strength = <8>;
- bias-pull-down;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq6018-pinctrl";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 80>;
+
+ serial3-state {
+ pins = "gpio44", "gpio45";
+ function = "blsp2_uart";
+ drive-strength = <8>;
+ bias-pull-down;
};
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
deleted file mode 100644
index a7aaaa7db83b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-Qualcomm IPQ8064 TLMM block
-
-Required properties:
-- compatible: "qcom,ipq8064-pinctrl"
-- reg: Should be the base address and length of the TLMM block.
-- interrupts: Should be the parent IRQ of the TLMM block.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two.
- The first cell is the gpio pin number and the
- second cell is used for optional parameters.
-- gpio-ranges: see ../gpio/gpio.txt
-
-Optional properties:
-
-- gpio-reserved-ranges: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Qualcomm's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
- pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength,
- output-low, output-high.
-
-Non-empty subnodes must specify the 'pins' property.
-
-Valid values for qcom,pins are:
- gpio0-gpio68
- Supports mux, bias, and drive-strength
-
- sdc3_clk, sdc3_cmd, sdc3_data
- Supports bias and drive-strength
-
-
-Valid values for function are:
- mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gpio, gsbi1, gsbi2, gsbi4, gsbi5,
- gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1,
- spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata,
- pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt,
- pcie1_clk_req, pcie2_rst, pcie2_prsnt, pcie2_pwren_n, pcie2_pwren,
- pcie2_pwrflt, pcie2_clk_req, pcie3_rst, pcie3_prsnt, pcie3_pwren_n,
- pcie3_pwren, pcie3_pwrflt, pcie3_clk_req, ps_hold
-
-Example:
-
- pinmux: pinctrl@800000 {
- compatible = "qcom,ipq8064-pinctrl";
- reg = <0x800000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pinmux 0 0 69>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 32 0x4>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&gsbi5_uart_default>;
-
- gsbi5_uart_default: gsbi5_uart_default {
- mux {
- pins = "gpio18", "gpio19";
- function = "gsbi5";
- };
-
- tx {
- pins = "gpio18";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio19";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.yaml
new file mode 100644
index 000000000000..58f11e1bdd4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq8064-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. IPQ8064 TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ8064 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,ipq8064-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq8064-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq8064-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq8064-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-5][0-9]|6[0-8])$"
+ - enum: [ sdc3_clk, sdc3_cmd, sdc3_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gpio, gsbi1, gsbi2, gsbi4, gsbi5,
+ gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1,
+ spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata,
+ pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt,
+ pcie1_clk_req, pcie2_rst, pcie2_prsnt, pcie2_pwren_n, pcie2_pwren,
+ pcie2_pwrflt, pcie2_clk_req, pcie3_rst, pcie3_prsnt, pcie3_pwren_n,
+ pcie3_pwren, pcie3_pwrflt, pcie3_clk_req, ps_hold ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@800000 {
+ compatible = "qcom,ipq8064-pinctrl";
+ reg = <0x00800000 0x4000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 69>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+ uart-state {
+ rx-pins {
+ pins = "gpio19";
+ function = "gsbi5";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio18";
+ function = "gsbi5";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt
deleted file mode 100644
index 7b151894f5a0..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt
+++ /dev/null
@@ -1,181 +0,0 @@
-Qualcomm Technologies, Inc. IPQ8074 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-IPQ8074 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,ipq8074-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode. Valid pins are:
- gpio0-gpio69
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
- atest_char, atest_char0, atest_char1, atest_char2,
- atest_char3, audio_rxbclk, audio_rxd, audio_rxfsync,
- audio_rxmclk, audio_txbclk, audio_txd, audio_txfsync,
- audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart, blsp1_i2c,
- blsp1_spi, blsp1_uart, blsp2_i2c, blsp2_spi, blsp2_uart,
- blsp3_i2c, blsp3_spi, blsp3_spi0, blsp3_spi1, blsp3_spi2,
- blsp3_spi3, blsp3_uart, blsp4_i2c0, blsp4_i2c1, blsp4_spi0,
- blsp4_spi1, blsp4_uart0, blsp4_uart1, blsp5_i2c, blsp5_spi,
- blsp5_uart, burn0, burn1, cri_trng, cri_trng0, cri_trng1,
- cxc0, cxc1, dbg_out, gcc_plltest, gcc_tlmm, gpio, ldo_en,
- ldo_update, led0, led1, led2, mac0_sa0, mac0_sa1, mac1_sa0,
- mac1_sa1, mac1_sa2, mac1_sa3, mac2_sa0, mac2_sa1, mdc,
- mdio, pcie0_clk, pcie0_rst, pcie0_wake, pcie1_clk,
- pcie1_rst, pcie1_wake, pcm_drx, pcm_dtx, pcm_fsync,
- pcm_pclk, pcm_zsi0, pcm_zsi1, prng_rosc, pta1_0, pta1_1,
- pta1_2, pta2_0, pta2_1, pta2_2, pwm0, pwm1, pwm2, pwm3,
- qdss_cti_trig_in_a0, qdss_cti_trig_in_a1,
- qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
- qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
- qdss_cti_trig_out_b0, qdss_cti_trig_out_b1,
- qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a,
- qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b,
- qpic, rx0, rx1, rx2, sd_card, sd_write, tsens_max, wci2a,
- wci2b, wci2c, wci2d
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@1000000 {
- compatible = "qcom,ipq8074-pinctrl";
- reg = <0x1000000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 70>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- uart2: uart2-default {
- mux {
- pins = "gpio23", "gpio24";
- function = "blsp4_uart1";
- };
-
- rx {
- pins = "gpio23";
- drive-strength = <4>;
- bias-disable;
- };
-
- tx {
- pins = "gpio24";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml
new file mode 100644
index 000000000000..40def3ac3bf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq8074-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm IPQ8074 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ8074 SoC.
+
+properties:
+ compatible:
+ const: qcom,ipq8074-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 35
+
+ gpio-line-names:
+ maxItems: 70
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq8074-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq8074-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq8074-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-6][0-9]|70)$"
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, atest_char, atest_char0, atest_char1, atest_char2,
+ atest_char3, audio_rxbclk, audio_rxd, audio_rxfsync,
+ audio_rxmclk, audio_txbclk, audio_txd, audio_txfsync,
+ audio_txmclk, blsp0_i2c, blsp0_spi, blsp0_uart, blsp1_i2c,
+ blsp1_spi, blsp1_uart, blsp2_i2c, blsp2_spi, blsp2_uart,
+ blsp3_i2c, blsp3_spi, blsp3_spi0, blsp3_spi1, blsp3_spi2,
+ blsp3_spi3, blsp3_uart, blsp4_i2c0, blsp4_i2c1, blsp4_spi0,
+ blsp4_spi1, blsp4_uart0, blsp4_uart1, blsp5_i2c, blsp5_spi,
+ blsp5_uart, burn0, burn1, cri_trng, cri_trng0, cri_trng1, cxc0,
+ cxc1, dbg_out, gcc_plltest, gcc_tlmm, ldo_en, ldo_update, led0,
+ led1, led2, mac0_sa0, mac0_sa1, mac1_sa0, mac1_sa1, mac1_sa2,
+ mac1_sa3, mac2_sa0, mac2_sa1, mdc, mdio, pcie0_clk, pcie0_rst,
+ pcie0_wake, pcie1_clk, pcie1_rst, pcie1_wake, pcm_drx, pcm_dtx,
+ pcm_fsync, pcm_pclk, pcm_zsi0, pcm_zsi1, prng_rosc, pta1_0,
+ pta1_1, pta1_2, pta2_0, pta2_1, pta2_2, pwm0, pwm1, pwm2, pwm3,
+ qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, qdss_cti_trig_in_b0,
+ qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
+ qdss_cti_trig_out_a1, qdss_cti_trig_out_b0,
+ qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_traceclk_b,
+ qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a,
+ qdss_tracedata_b, qpic, rx0, rx1, rx2, sd_card, sd_write,
+ tsens_max, wci2a, wci2b, wci2c, wci2d ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq8074-pinctrl";
+ reg = <0x01000000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ gpio-ranges = <&tlmm 0 0 70>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+
+ serial4-state {
+ pins = "gpio23", "gpio24";
+ function = "blsp4_uart1";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml
new file mode 100644
index 000000000000..7afec315b63e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,ipq9574-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. IPQ9574 TLMM block
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm IPQ9574 SoC.
+
+properties:
+ compatible:
+ const: qcom,ipq9574-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 33
+
+ gpio-line-names:
+ maxItems: 65
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-ipq9574-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-ipq9574-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-ipq9574-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-5][0-9]|6[0-4])$"
+ minItems: 1
+ maxItems: 8
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_char0, atest_char1, atest_char2, atest_char3,
+ audio_pdm0, audio_pdm1, audio_pri, audio_sec, blsp0_spi, blsp0_uart,
+ blsp1_i2c, blsp1_spi, blsp1_uart, blsp2_i2c, blsp2_spi,
+ blsp2_uart, blsp3_i2c, blsp3_spi, blsp3_uart, blsp4_i2c,
+ blsp4_spi, blsp4_uart, blsp5_i2c, blsp5_uart, cri_trng0,
+ cri_trng1, cri_trng2, cri_trng3, cxc0, cxc1, dbg_out, dwc_ddrphy,
+ gcc_plltest, gcc_tlmm, gpio, mac, mdc, mdio, pcie0_clk, pcie0_wake,
+ pcie1_clk, pcie1_wake, pcie2_clk, pcie2_wake, pcie3_clk, pcie3_wake,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, pta, pwm,
+ qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, qdss_cti_trig_in_b0,
+ qdss_cti_trig_in_b1, qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
+ qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a,
+ qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a,
+ qdss_tracedata_b, qspi_clk, qspi_cs, qspi_data,
+ rx0, rx1, sdc_clk, sdc_cmd, sdc_data, sdc_rclk, tsens_max,
+ wci20, wci21, wsa_swrm ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,ipq9574-tlmm";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 65>;
+
+ uart2-state {
+ pins = "gpio34", "gpio35";
+ function = "blsp2_uart";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,kaanapali-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,kaanapali-tlmm.yaml
new file mode 100644
index 000000000000..53534a07a1f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,kaanapali-tlmm.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,kaanapali-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Kaanapali TLMM block
+
+maintainers:
+ - Jingyi Wang <jingyi.wang@oss.qualcomm.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm Kaanapali SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,kaanapali-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 109
+
+ gpio-line-names:
+ maxItems: 217
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-kaanapali-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-kaanapali-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-kaanapali-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9]|21[0-6])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0,
+ audio_ext_mclk1, audio_ref_clk, cam_asc_mclk2, cam_asc_mclk4,
+ cam_mclk, cci_async_in, cci_i2c_scl, cci_i2c_sda, cci_timer,
+ cmu_rng, coex_uart1_rx, coex_uart1_tx, coex_uart2_rx,
+ coex_uart2_tx, dbg_out_clk, ddr_bist_complete, ddr_bist_fail,
+ ddr_bist_start, ddr_bist_stop, ddr_pxi0, ddr_pxi1, ddr_pxi2,
+ ddr_pxi3, dp_hot, egpio, gcc_gp1, gcc_gp2, gcc_gp3, gnss_adc0,
+ gnss_adc1, i2chub0_se0, i2chub0_se1, i2chub0_se2, i2chub0_se3,
+ i2chub0_se4, i2s0_data0, i2s0_data1, i2s0_sck, i2s0_ws,
+ i2s1_data0, i2s1_data1, i2s1_sck, i2s1_ws, ibi_i3c, jitter_bist,
+ mdp_esync0_out, mdp_esync1_out, mdp_vsync, mdp_vsync0_out,
+ mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out, mdp_vsync5_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2, nav_gpio3,
+ pcie0_clk_req_n, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio_traceclk, qdss_gpio_tracectl, qdss_gpio_tracedata,
+ qlink_big_enable, qlink_big_request, qlink_little_enable,
+ qlink_little_request, qlink_wmss, qspi0, qspi1, qspi2, qspi3,
+ qspi_clk, qspi_cs, qup1_se0, qup1_se1, qup1_se2, qup1_se3,
+ qup1_se4, qup1_se5, qup1_se6, qup1_se7, qup2_se0, qup2_se1,
+ qup2_se2, qup2_se3, qup2_se4, qup3_se0, qup3_se1, qup3_se2,
+ qup3_se3, qup3_se4, qup3_se5, qup4_se0, qup4_se1, qup4_se2,
+ qup4_se3, qup4_se4, sd_write_protect, sdc40, sdc41, sdc42, sdc43,
+ sdc4_clk, sdc4_cmd, sys_throttle, tb_trig_sdc2, tb_trig_sdc4,
+ tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3, tsense_pwm1,
+ tsense_pwm2, tsense_pwm3, tsense_pwm4, tsense_pwm5, tsense_pwm6,
+ tsense_pwm7, uim0_clk, uim0_data, uim0_present, uim0_reset, uim1_clk,
+ uim1_data, uim1_present, uim1_reset, usb0_hs, usb_phy, vfr_0, vfr_1,
+ vsense_trigger_mirnat, wcn_sw, wcn_sw_ctrl ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,kaanapali-tlmm";
+ reg = <0x0f100000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 218>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ qup-uart7-state {
+ pins = "gpio62", "gpio63";
+ function = "qup1_se7";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
new file mode 100644
index 000000000000..619341dd637c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,lpass-lpi-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoC LPASS LPI TLMM Common Properties
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Common properties for the Top Level Mode Multiplexer pin controllers in the
+ Low Power Audio SubSystem (LPASS) Low Power Island (LPI) of Qualcomm SoCs.
+
+properties:
+ gpio-controller: true
+
+ "#gpio-cells":
+ description:
+ Specifying the pin number and flags, as defined in
+ include/dt-bindings/gpio/gpio.h
+ const: 2
+
+ gpio-ranges:
+ maxItems: 1
+
+required:
+ - gpio-controller
+ - "#gpio-cells"
+ - gpio-ranges
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+additionalProperties: true
+
+$defs:
+ qcom-tlmm-state:
+ properties:
+ drive-strength:
+ enum: [2, 4, 6, 8, 10, 12, 14, 16]
+ default: 2
+ description:
+ Selects the drive strength for the specified pins, in mA.
+
+ slew-rate:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ 0: No adjustments
+ 1: Higher Slew rate (faster edges)
+ 2: Lower Slew rate (slower edges)
+ 3: Reserved (No adjustments)
+
+ bias-bus-hold: true
+ bias-pull-down: true
+ bias-pull-up: true
+ bias-disable: true
+ input-enable: true
+ output-high: true
+ output-low: true
+
+ required:
+ - pins
+ - function
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ additionalProperties: true
+
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml
deleted file mode 100644
index f7bd4be1739e..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml
+++ /dev/null
@@ -1,134 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,mdm9607-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. MDM9607 TLMM block
-
-maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- MDM9607 platform.
-
-allOf:
- - $ref: "pinctrl.yaml#"
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,mdm9607-tlmm
-
- reg:
- maxItems: 1
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-mdm9607-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-mdm9607-tlmm-state"
-
-'$defs':
- qcom-mdm9607-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([1-9]|[1-7][0-9]|80)$"
- - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
- sdc2_data, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2,
- qdsd_data3 ]
- minItems: 1
- maxItems: 16
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ adsp_ext, atest_bbrx0, atest_bbrx1, atest_char, atest_char0,
- atest_char1, atest_char2, atest_char3,
- atest_combodac_to_gpio_native, atest_gpsadc_dtest0_native,
- atest_gpsadc_dtest1_native, atest_tsens, backlight_en_b,
- bimc_dte0, bimc_dte1, blsp1_spi, blsp2_spi, blsp3_spi,
- blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
- blsp_i2c6, blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4,
- blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uart3,
- blsp_uart4, blsp_uart5, blsp_uart6, blsp_uim1, blsp_uim2,
- codec_int, codec_rst, coex_uart, cri_trng, cri_trng0,
- cri_trng1, dbg_out, ebi0_wrcdc, ebi2_a, ebi2_a_d_8_b,
- ebi2_lcd, ebi2_lcd_cs_n_b, ebi2_lcd_te_b, eth_irq, eth_rst,
- gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b,
- gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gmac_mdio,
- gpio, gsm0_tx, lcd_rst, ldo_en, ldo_update, m_voc, modem_tsync,
- nav_ptp_pps_in_a, nav_ptp_pps_in_b, nav_tsync_out_a,
- nav_tsync_out_b, pa_indicator, pbs0, pbs1, pbs2,
- pri_mi2s_data0_a, pri_mi2s_data1_a, pri_mi2s_mclk_a,
- pri_mi2s_sck_a, pri_mi2s_ws_a, prng_rosc, ptp_pps_out_a,
- ptp_pps_out_b, pwr_crypto_enabled_a, pwr_crypto_enabled_b,
- pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a,
- pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1,
- qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
- qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, qdss_cti_trig_out_b1,
- qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a,
- qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b, rcm_marker1,
- rcm_marker2, sd_write, sec_mi2s, sensor_en, sensor_int2,
- sensor_int3, sensor_rst, ssbi1, ssbi2, touch_rst, ts_int,
- uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
- uim2_data, uim2_present, uim2_reset, uim_batt, wlan_en1, ]
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@1000000 {
- compatible = "qcom,mdm9607-tlmm";
- reg = <0x01000000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- gpio-ranges = <&msmgpio 0 0 80>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml
new file mode 100644
index 000000000000..e75393b3d196
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,mdm9607-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. MDM9607 TLMM block
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MDM9607 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,mdm9607-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-mdm9607-tlmm-state"
+ - additionalProperties: false
+ patternProperties:
+ ".*":
+ $ref: "#/$defs/qcom-mdm9607-tlmm-state"
+
+$defs:
+ qcom-mdm9607-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([1-9]|[1-7][0-9]|80)$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
+ sdc2_data, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2,
+ qdsd_data3 ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, atest_bbrx0, atest_bbrx1, atest_char, atest_char0,
+ atest_char1, atest_char2, atest_char3,
+ atest_combodac_to_gpio_native, atest_gpsadc_dtest0_native,
+ atest_gpsadc_dtest1_native, atest_tsens, backlight_en_b,
+ bimc_dte0, bimc_dte1, blsp1_spi, blsp2_spi, blsp3_spi,
+ blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
+ blsp_i2c6, blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4,
+ blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uart3,
+ blsp_uart4, blsp_uart5, blsp_uart6, blsp_uim1, blsp_uim2,
+ codec_int, codec_rst, coex_uart, cri_trng, cri_trng0,
+ cri_trng1, dbg_out, ebi0_wrcdc, ebi2_a, ebi2_a_d_8_b,
+ ebi2_lcd, ebi2_lcd_cs_n_b, ebi2_lcd_te_b, eth_irq, eth_rst,
+ gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b,
+ gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gmac_mdio,
+ gpio, gsm0_tx, lcd_rst, ldo_en, ldo_update, m_voc, modem_tsync,
+ nav_ptp_pps_in_a, nav_ptp_pps_in_b, nav_tsync_out_a,
+ nav_tsync_out_b, pa_indicator, pbs0, pbs1, pbs2,
+ pri_mi2s_data0_a, pri_mi2s_data1_a, pri_mi2s_mclk_a,
+ pri_mi2s_sck_a, pri_mi2s_ws_a, prng_rosc, ptp_pps_out_a,
+ ptp_pps_out_b, pwr_crypto_enabled_a, pwr_crypto_enabled_b,
+ pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a,
+ pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1,
+ qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, qdss_cti_trig_out_a0,
+ qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, qdss_cti_trig_out_b1,
+ qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a,
+ qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b, rcm_marker1,
+ rcm_marker2, sd_write, sec_mi2s, sensor_en, sensor_int2,
+ sensor_int3, sensor_rst, ssbi1, ssbi2, touch_rst, ts_int,
+ uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
+ uim2_data, uim2_present, uim2_reset, uim_batt, wlan_en1, ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,mdm9607-tlmm";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&msmgpio 0 0 80>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.txt
deleted file mode 100644
index d46973968873..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.txt
+++ /dev/null
@@ -1,161 +0,0 @@
-Qualcomm MDM9615 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MDM9615 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,mdm9615-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode. Valid pins are:
- gpio0-gpio87
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins.
- Valid values are:
- gpio, gsbi2_i2c, gsbi3, gsbi4, gsbi5_i2c, gsbi5_uart,
- sdc2, ebi2_lcdc, ps_hold, prim_audio, sec_audio,
- cdc_mclk
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- msmgpio: pinctrl@800000 {
- compatible = "qcom,mdm9615-pinctrl";
- reg = <0x800000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&msmgpio 0 0 88>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 16 0x4>;
-
- gsbi8_uart: gsbi8-uart {
- mux {
- pins = "gpio34", "gpio35";
- function = "gsbi8";
- };
-
- tx {
- pins = "gpio34";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio35";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml
new file mode 100644
index 000000000000..299e0b4b0ab4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,mdm9615-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. MDM9615 TLMM block
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description: Top Level Mode Multiplexer pin controller in Qualcomm MDM9615 SoC.
+
+$ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,mdm9615-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-mdm9615-pinctrl-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-mdm9615-pinctrl-state"
+ additionalProperties: false
+
+$defs:
+ qcom-mdm9615-pinctrl-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-7][0-9]|8[0-7])$"
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, gsbi2_i2c, gsbi3, gsbi4, gsbi5_i2c, gsbi5_uart,
+ sdc2, ebi2_lcdc, ps_hold, prim_audio, sec_audio, cdc_mclk, ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,mdm9615-pinctrl";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&msmgpio 0 0 88>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gsbi3-state {
+ pins = "gpio8", "gpio9", "gpio10", "gpio11";
+ function = "gsbi3";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ gsbi5-i2c-state {
+ sda-pins {
+ pins = "gpio16";
+ function = "gsbi5_i2c";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ scl-pins {
+ pins = "gpio17";
+ function = "gsbi5_i2c";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
new file mode 100644
index 000000000000..0091204df20a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-tlmm.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,milos-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Milos TLMM block
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm Milos SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,milos-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 84
+
+ gpio-line-names:
+ maxItems: 167
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-milos-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-milos-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-milos-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-5][0-9]|16[0-7])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0,
+ audio_ext_mclk1, audio_ref_clk, cam_mclk, cci_async_in0,
+ cci_i2c_scl, cci_i2c_sda, cci_timer, coex_uart1_rx,
+ coex_uart1_tx, dbg_out_clk, ddr_bist_complete, ddr_bist_fail,
+ ddr_bist_start, ddr_bist_stop, ddr_pxi0, ddr_pxi1, dp0_hot,
+ egpio, gcc_gp1, gcc_gp2, gcc_gp3, host2wlan_sol, i2s0_data0,
+ i2s0_data1, i2s0_sck, i2s0_ws, ibi_i3c, jitter_bist, mdp_vsync,
+ mdp_vsync0_out, mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2, pcie0_clk_req_n,
+ pcie1_clk_req_n, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio, qlink0_enable, qlink0_request, qlink0_wmss,
+ qlink1_enable, qlink1_request, qlink1_wmss, qspi0, qup0_se0,
+ qup0_se1, qup0_se2, qup0_se3, qup0_se4, qup0_se5, qup0_se6,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4, qup1_se5,
+ qup1_se6, resout_gpio_n, sd_write_protect, sdc1_clk, sdc1_cmd,
+ sdc1_data, sdc1_rclk, sdc2_clk, sdc2_cmd, sdc2_data,
+ sdc2_fb_clk, tb_trig_sdc1, tb_trig_sdc2, tgu_ch0_trigout,
+ tgu_ch1_trigout, tmess_prng0, tmess_prng1, tmess_prng2,
+ tmess_prng3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data,
+ uim0_present, uim0_reset, uim1_clk_mira, uim1_clk_mirb,
+ uim1_data_mira, uim1_data_mirb, uim1_present_mira,
+ uim1_present_mirb, uim1_reset_mira, uim1_reset_mirb, usb0_hs,
+ usb0_phy_ps, vfr_0, vfr_1, vsense_trigger_mirnat, wcn_sw,
+ wcn_sw_ctrl ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,milos-tlmm";
+ reg = <0x0f100000 0x300000>;
+
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-ranges = <&tlmm 0 0 168>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ qup-uart5-default-state {
+ pins = "gpio25", "gpio26";
+ function = "qup0_se5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
index ab4a2b4cfda2..68d3fa2105b8 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml
@@ -9,9 +9,8 @@ title: Qualcomm Technologies, Inc. MSM8226 TLMM block
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- MSM8226 platform.
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8226 SoC.
properties:
compatible:
@@ -22,37 +21,28 @@ properties:
maxItems: 1
interrupts:
- description: Specifies the TLMM summary IRQ
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- description: Specifies the PIN numbers and Flags, as defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
maxItems: 1
gpio-reserved-ranges:
maxItems: 1
-#PIN CONFIGURATION NODES
patternProperties:
- '-pins$':
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8226-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8226-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8226-tlmm-state:
type: object
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -61,7 +51,7 @@ patternProperties:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-6])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
minItems: 1
maxItems: 36
@@ -71,65 +61,41 @@ patternProperties:
Specify the alternative function to be configured for the specified
pins. Functions are only valid for gpio pins.
enum: [ gpio, cci_i2c0, blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim5,
- blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c5, blsp_spi1,
- blsp_spi2, blsp_spi3, blsp_spi5, blsp_uart1, blsp_uart2,
- blsp_uart3, blsp_uart5, cam_mclk0, cam_mclk1, wlan ]
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
+ blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6,
+ blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi5, blsp_uart1, blsp_uart2,
+ blsp_uart3, blsp_uart4, blsp_uart5, cam_mclk0, cam_mclk1,
+ gp0_clk, gp1_clk, sdc3, wlan ]
required:
- pins
- - function
-
- additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- msmgpio: pinctrl@fd510000 {
- compatible = "qcom,msm8226-pinctrl";
- reg = <0xfd510000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&msmgpio 0 0 117>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
-
- serial-pins {
- pins = "gpio8", "gpio9";
- function = "blsp_uart3";
- drive-strength = <8>;
- bias-disable;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ msmgpio: pinctrl@fd510000 {
+ compatible = "qcom,msm8226-pinctrl";
+ reg = <0xfd510000 0x4000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&msmgpio 0 0 117>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ serial-state {
+ pins = "gpio8", "gpio9";
+ function = "blsp_uart3";
+ drive-strength = <8>;
+ bias-disable;
};
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt
deleted file mode 100644
index f095209848c8..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt
+++ /dev/null
@@ -1,96 +0,0 @@
-Qualcomm MSM8660 TLMM block
-
-Required properties:
-- compatible: "qcom,msm8660-pinctrl"
-- reg: Should be the base address and length of the TLMM block.
-- interrupts: Should be the parent IRQ of the TLMM block.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two.
- The first cell is the gpio pin number and the
- second cell is used for optional parameters.
-- gpio-ranges: see ../gpio/gpio.txt
-
-Optional properties:
-
-- gpio-reserved-ranges: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Qualcomm's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
- pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength,
- output-low, output-high.
-
-Non-empty subnodes must specify the 'pins' property.
-
-Valid values for pins are:
- gpio0-gpio172, sdc3_clk, sdc3_cmd, sdc3_data sdc4_clk, sdc4_cmd, sdc4_data
-
-Valid values for function are:
- gpio, cam_mclk, dsub, ext_gps, gp_clk_0a, gp_clk_0b, gp_clk_1a, gp_clk_1b,
- gp_clk_2a, gp_clk_2b, gp_mn, gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n,
- gsbi1_spi_cs2b_n, gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n,
- gsbi2_spi_cs3_n, gsbi3, gsbi3_spi_cs1_n, gsbi3_spi_cs2_n, gsbi3_spi_cs3_n,
- gsbi4, gsbi5, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, gsbi11, gsbi12, hdmi, i2s,
- lcdc, mdp_vsync, mi2s, pcm, ps_hold, sdc1, sdc2, sdc5, tsif1, tsif2, usb_fs1,
- usb_fs1_oe_n, usb_fs2, usb_fs2_oe_n, vfe, vsens_alarm, ebi2, ebi2cs
-
-Example:
-
- msmgpio: pinctrl@800000 {
- compatible = "qcom,msm8660-pinctrl";
- reg = <0x800000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&msmgpio 0 0 173>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 16 0x4>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&gsbi12_uart>;
-
- gsbi12_uart: gsbi12-uart {
- mux {
- pins = "gpio117", "gpio118";
- function = "gsbi12";
- };
-
- tx {
- pins = "gpio118";
- drive-strength = <8>;
- bias-disable;
- };
-
- rx {
- pins = "gpio117";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml
new file mode 100644
index 000000000000..203ad69e99e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8660-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8660 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8660 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8660-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 86
+
+ gpio-line-names:
+ maxItems: 173
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8660-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8660-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8660-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-6][0-9]|17[0-2])$"
+ - enum: [ sdc3_clk, sdc3_cmd, sdc3_data, sdc4_clk, sdc4_cmd, sdc4_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, cam_mclk, dsub, ext_gps, gp_clk_0a, gp_clk_0b, gp_clk_1a,
+ gp_clk_1b, gp_clk_2a, gp_clk_2b, gp_mn, gsbi1, gsbi1_spi_cs1_n,
+ gsbi1_spi_cs2a_n, gsbi1_spi_cs2b_n, gsbi1_spi_cs3_n, gsbi2,
+ gsbi2_spi_cs1_n, gsbi2_spi_cs2_n, gsbi2_spi_cs3_n, gsbi3,
+ gsbi3_spi_cs1_n, gsbi3_spi_cs2_n, gsbi3_spi_cs3_n, gsbi4,
+ gsbi5, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, gsbi11, gsbi12,
+ hdmi, i2s, lcdc, mdp_vsync, mi2s, pcm, ps_hold, sdc1, sdc2,
+ sdc5, tsif1, tsif2, usb_fs1, usb_fs1_oe_n, usb_fs2,
+ usb_fs2_oe_n, vfe, vsens_alarm, ebi2, ebi2cs ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@800000 {
+ compatible = "qcom,msm8660-pinctrl";
+ reg = <0x800000 0x4000>;
+
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 173>;
+ #gpio-cells = <2>;
+ interrupts = <0 16 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gsbi3-i2c-state {
+ pins = "gpio43", "gpio44";
+ function = "gsbi3";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml
index e03530091478..295dd5fcf4c3 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml
@@ -10,8 +10,7 @@ maintainers:
- Stephan Gerhold <stephan@gerhold.net>
description: |
- This binding describes the Top Level Mode Multiplexer (TLMM) block found
- in the MSM8909 platform.
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8909 SoC.
allOf:
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
@@ -23,28 +22,19 @@ properties:
reg:
maxItems: 1
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
+ interrupts:
+ maxItems: 1
-additionalProperties: false
+ gpio-reserved-ranges: true
patternProperties:
- '-state$':
+ "-state$":
oneOf:
- $ref: "#/$defs/qcom-msm8909-tlmm-state"
- patternProperties:
- ".*":
+ "-pins$":
$ref: "#/$defs/qcom-msm8909-tlmm-state"
+ additionalProperties: false
$defs:
qcom-msm8909-tlmm-state:
@@ -52,7 +42,8 @@ $defs:
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -61,7 +52,7 @@ $defs:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-7])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-2])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, qdsd_data1,
qdsd_data2, qdsd_data3 ]
@@ -102,51 +93,46 @@ $defs:
uim3_clk, uim3_data, uim3_present, uim3_reset, uim_batt,
wcss_bt, wcss_fm, wcss_wlan ]
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
required:
- pins
- - function
- additionalProperties: false
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- pinctrl@1000000 {
- compatible = "qcom,msm8909-tlmm";
- reg = <0x1000000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 117>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio4";
- function = "blsp_uart1";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio5";
- function = "blsp_uart1";
- bias-disable;
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl@1000000 {
+ compatible = "qcom,msm8909-tlmm";
+ reg = <0x1000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 113>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio4";
+ function = "blsp_uart1";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio5";
+ function = "blsp_uart1";
+ bias-disable;
+ };
};
+ };
...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
deleted file mode 100644
index 3354a63296d9..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt
+++ /dev/null
@@ -1,195 +0,0 @@
-Qualcomm MSM8916 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8916 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,msm8916-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode. Valid pins are:
- gpio0-gpio121,
- sdc1_clk,
- sdc1_cmd,
- sdc1_data
- sdc2_clk,
- sdc2_cmd,
- sdc2_data,
- qdsd_cmd,
- qdsd_data0,
- qdsd_data1,
- qdsd_data2,
- qdsd_data3
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
- adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char, atest_char0,
- atest_char1, atest_char2, atest_char3, atest_combodac, atest_gpsadc0,
- atest_gpsadc1, atest_tsens, atest_wlan0, atest_wlan1, backlight_en,
- bimc_dte0,bimc_dte1, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4,
- blsp_i2c5, blsp_i2c6, blsp_spi1, blsp_spi1_cs1, blsp_spi1_cs2,
- blsp_spi1_cs3, blsp_spi2, blsp_spi2_cs1, blsp_spi2_cs2, blsp_spi2_cs3,
- blsp_spi3, blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi3_cs3, blsp_spi4,
- blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uim1, blsp_uim2,
- cam1_rst, cam1_standby, cam_mclk0, cam_mclk1, cci_async, cci_i2c,
- cci_timer0, cci_timer1, cci_timer2, cdc_pdm0, codec_mad, dbg_out,
- display_5v, dmic0_clk, dmic0_data, dsi_rst, ebi0_wrcdc, euro_us,
- ext_lpass, flash_strobe, gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a,
- gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b, gpio, gsm0_tx0, gsm0_tx1,
- gsm1_tx0, gsm1_tx1, gyro_accl, kpsns0, kpsns1, kpsns2, ldo_en,
- ldo_update, mag_int, mdp_vsync, modem_tsync, m_voc, nav_pps, nav_tsync,
- pa_indicator, pbs0, pbs1, pbs2, pri_mi2s, pri_mi2s_ws, prng_rosc,
- pwr_crypto_enabled_a, pwr_crypto_enabled_b, pwr_modem_enabled_a,
- pwr_modem_enabled_b, pwr_nav_enabled_a, pwr_nav_enabled_b,
- qdss_ctitrig_in_a0, qdss_ctitrig_in_a1, qdss_ctitrig_in_b0,
- qdss_ctitrig_in_b1, qdss_ctitrig_out_a0, qdss_ctitrig_out_a1,
- qdss_ctitrig_out_b0, qdss_ctitrig_out_b1, qdss_traceclk_a,
- qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a,
- qdss_tracedata_b, reset_n, sd_card, sd_write, sec_mi2s, smb_int,
- ssbi_wtr0, ssbi_wtr1, uim1, uim2, uim3, uim_batt, wcss_bt, wcss_fm,
- wcss_wlan, webcam1_rst
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@1000000 {
- compatible = "qcom,msm8916-pinctrl";
- reg = <0x1000000 0x300000>;
- interrupts = <0 208 0>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 122>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- uart2: uart2-default {
- mux {
- pins = "gpio4", "gpio5";
- function = "blsp_uart2";
- };
-
- tx {
- pins = "gpio4";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio5";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml
new file mode 100644
index 000000000000..9bf098cf18ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8916-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8916 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8916 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8916-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 61
+
+ gpio-line-names:
+ maxItems: 122
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8916-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8916-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8916-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-9]|12[01])$"
+ - enum: [ qdsd_clk, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2,
+ qdsd_data3, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
+ sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char,
+ atest_char0, atest_char1, atest_char2, atest_char3,
+ atest_combodac, atest_gpsadc0, atest_gpsadc1, atest_tsens,
+ atest_wlan0, atest_wlan1, backlight_en, bimc_dte0, bimc_dte1,
+ blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
+ blsp_i2c6, blsp_spi1, blsp_spi1_cs1, blsp_spi1_cs2,
+ blsp_spi1_cs3, blsp_spi2, blsp_spi2_cs1, blsp_spi2_cs2,
+ blsp_spi2_cs3, blsp_spi3, blsp_spi3_cs1, blsp_spi3_cs2,
+ blsp_spi3_cs3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_uart1,
+ blsp_uart2, blsp_uim1, blsp_uim2, cam1_rst, cam1_standby,
+ cam_mclk0, cam_mclk1, cci_async, cci_i2c, cci_timer0,
+ cci_timer1, cci_timer2, cdc_pdm0, codec_mad, dbg_out,
+ display_5v, dmic0_clk, dmic0_data, dsi_rst, ebi0_wrcdc,
+ euro_us, ext_lpass, flash_strobe, gcc_gp1_clk_a, gcc_gp1_clk_b,
+ gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b,
+ gsm0_tx0, gsm0_tx1, gsm1_tx0, gsm1_tx1, gyro_accl, kpsns0,
+ kpsns1, kpsns2, ldo_en, ldo_update, mag_int, mdp_vsync,
+ modem_tsync, m_voc, nav_pps, nav_tsync, pa_indicator, pbs0,
+ pbs1, pbs2, pri_mi2s, pri_mi2s_ws, prng_rosc,
+ pwr_crypto_enabled_a, pwr_crypto_enabled_b,
+ pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a,
+ pwr_nav_enabled_b, qdss_ctitrig_in_a0, qdss_ctitrig_in_a1,
+ qdss_ctitrig_in_b0, qdss_ctitrig_in_b1, qdss_ctitrig_out_a0,
+ qdss_ctitrig_out_a1, qdss_ctitrig_out_b0, qdss_ctitrig_out_b1,
+ qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a,
+ qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b, reset_n,
+ sd_card, sd_write, sec_mi2s, smb_int, ssbi_wtr0, ssbi_wtr1,
+ uim1, uim2, uim3, uim_batt, wcss_bt, wcss_fm, wcss_wlan,
+ webcam1_rst ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ msmgpio: pinctrl@1000000 {
+ compatible = "qcom,msm8916-pinctrl";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&msmgpio 0 0 122>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-uart2-sleep-state {
+ pins = "gpio4", "gpio5";
+ function = "gpio";
+
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ spi1-default-state {
+ spi-pins {
+ pins = "gpio0", "gpio1", "gpio3";
+ function = "blsp_spi1";
+
+ drive-strength = <12>;
+ bias-disable;
+ };
+
+ cs-pins {
+ pins = "gpio2";
+ function = "gpio";
+
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml
new file mode 100644
index 000000000000..16d0c010e581
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8917-pinctrl.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8917-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8917 TLMM pin controller
+
+maintainers:
+ - Barnabas Czeman <barnabas.czeman@mainlining.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8917 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8917-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 66
+
+ gpio-line-names:
+ maxItems: 134
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8917-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8917-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8917-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-3])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
+ sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0,
+ qdsd_data1, qdsd_data2, qdsd_data3 ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ accel_int, adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1,
+ atest_char, atest_char0, atest_char1, atest_char2,
+ atest_char3, atest_combodac_to_gpio_native,
+ atest_gpsadc_dtest0_native, atest_gpsadc_dtest1_native,
+ atest_tsens, atest_wlan0, atest_wlan1, audio_ref,
+ audio_reset, bimc_dte0, bimc_dte1, blsp6_spi, blsp8_spi,
+ blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
+ blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_spi1, blsp_spi2,
+ blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7,
+ blsp_spi8, blsp_uart1, blsp_uart2, blsp_uart3, blsp_uart4,
+ blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8, cam0_ldo,
+ cam1_rst, cam1_standby, cam2_rst, cam2_standby, cam_mclk,
+ cci_async, cci_i2c, cci_timer0, cci_timer1, cdc_pdm0,
+ codec_int1, codec_int2, codec_mad, coex_uart, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, dmic0_clk, dmic0_data,
+ ebi_cdc, ebi_ch0, ext_lpass, forced_usb, fp_gpio, fp_int,
+ gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b,
+ gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gpio,
+ gsm0_tx, key_focus, key_snapshot, key_volp, ldo_en,
+ ldo_update, lpass_slimbus, lpass_slimbus0, lpass_slimbus1,
+ m_voc, mag_int, mdp_vsync, mipi_dsi0, modem_tsync, nav_pps,
+ nav_pps_in_a, nav_pps_in_b, nav_tsync, nfc_pwr, ov_ldo,
+ pa_indicator, pbs0, pbs1, pbs2, pri_mi2s, pri_mi2s_mclk_a,
+ pri_mi2s_mclk_b, pri_mi2s_ws, prng_rosc,
+ pwr_crypto_enabled_a, pwr_crypto_enabled_b,
+ pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a,
+ pwr_nav_enabled_b, qdss_cti_trig_in_a0, qdss_cti_trig_in_a1,
+ qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
+ qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
+ qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a,
+ qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
+ qdss_tracedata_a, qdss_tracedata_b, sd_write, sdcard_det,
+ sec_mi2s, sec_mi2s_mclk_a, sec_mi2s_mclk_b, sensor_rst,
+ smb_int, ssbi_wtr1, ts_resout, ts_sample, uim1_clk,
+ uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
+ uim2_present, uim2_reset, uim_batt, us_emitter, us_euro,
+ wcss_bt, wcss_fm, wcss_wlan, wcss_wlan0, wcss_wlan1,
+ wcss_wlan2, webcam_rst, webcam_standby, wsa_io, wsa_irq ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,msm8917-pinctrl";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 134>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-uart2-sleep-state {
+ pins = "gpio4", "gpio5";
+ function = "gpio";
+
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ spi1-default-state {
+ spi-pins {
+ pins = "gpio0", "gpio1", "gpio3";
+ function = "blsp_spi1";
+
+ drive-strength = <12>;
+ bias-disable;
+ };
+
+ cs-pins {
+ pins = "gpio2";
+ function = "gpio";
+
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
index d4da558cde54..8a3a962f6c00 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
@@ -9,9 +9,8 @@ title: Qualcomm Technologies, Inc. MSM8953 TLMM block
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- MSM8953 platform.
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8953 SoC.
properties:
compatible:
@@ -21,37 +20,27 @@ properties:
maxItems: 1
interrupts:
- description: Specifies the TLMM summary IRQ
maxItems: 1
- interrupt-controller: true
-
- '#interrupt-cells':
- description:
- Specifies the PIN numbers and Flags, as defined in defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
gpio-reserved-ranges: true
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
-#PIN CONFIGURATION NODES
patternProperties:
- '-pins$':
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8953-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8953-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8953-tlmm-state:
type: object
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -60,7 +49,7 @@ patternProperties:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[01])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0,
qdsd_data1, qdsd_data2, qdsd_data3 ]
@@ -113,60 +102,35 @@ patternProperties:
uim_batt, us_emitter, us_euro, wcss_bt, wcss_fm, wcss_wlan,
wcss_wlan0, wcss_wlan1, wcss_wlan2, wsa_en, wsa_io, wsa_irq ]
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
required:
- pins
- - function
-
- additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@1000000 {
- compatible = "qcom,msm8953-pinctrl";
- reg = <0x01000000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 142>;
-
- serial_default: serial-pins {
- pins = "gpio4", "gpio5";
- function = "blsp_uart2";
- drive-strength = <2>;
- bias-disable;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,msm8953-pinctrl";
+ reg = <0x01000000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 142>;
+
+ serial_default: serial-state {
+ pins = "gpio4", "gpio5";
+ function = "blsp_uart2";
+ drive-strength = <2>;
+ bias-disable;
};
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
deleted file mode 100644
index a7dd213c77c6..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
+++ /dev/null
@@ -1,190 +0,0 @@
-Qualcomm MSM8960 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8960 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,msm8960-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode. Valid pins are:
- gpio0-gpio151,
- sdc1_clk,
- sdc1_cmd,
- sdc1_data
- sdc3_clk,
- sdc3_cmd,
- sdc3_data
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
- audio_pcm, bt, cam_mclk0, cam_mclk1, cam_mclk2,
- codec_mic_i2s, codec_spkr_i2s, ext_gps, fm, gps_blanking,
- gps_pps_in, gps_pps_out, gp_clk_0a, gp_clk_0b, gp_clk_1a,
- gp_clk_1b, gp_clk_2a, gp_clk_2b, gp_mn, gp_pdm_0a,
- gp_pdm_0b, gp_pdm_1a, gp_pdm_1b, gp_pdm_2a, gp_pdm_2b, gpio,
- gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n, gsbi1_spi_cs2b_n,
- gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n,
- gsbi2_spi_cs3_n, gsbi3, gsbi4, gsbi4_3d_cam_i2c_l,
- gsbi4_3d_cam_i2c_r, gsbi5, gsbi5_3d_cam_i2c_l,
- gsbi5_3d_cam_i2c_r, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10,
- gsbi11, gsbi11_spi_cs1a_n, gsbi11_spi_cs1b_n,
- gsbi11_spi_cs2a_n, gsbi11_spi_cs2b_n, gsbi11_spi_cs3_n,
- gsbi12, hdmi_cec, hdmi_ddc_clock, hdmi_ddc_data,
- hdmi_hot_plug_detect, hsic, mdp_vsync, mi2s, mic_i2s,
- pmb_clk, pmb_ext_ctrl, ps_hold, rpm_wdog, sdc2, sdc4, sdc5,
- slimbus1, slimbus2, spkr_i2s, ssbi1, ssbi2, ssbi_ext_gps,
- ssbi_pmic2, ssbi_qpa1, ssbi_ts, tsif1, tsif2, ts_eoc,
- usb_fs1, usb_fs1_oe, usb_fs1_oe_n, usb_fs2, usb_fs2_oe,
- usb_fs2_oe_n, vfe_camif_timer1_a, vfe_camif_timer1_b,
- vfe_camif_timer2, vfe_camif_timer3_a, vfe_camif_timer3_b,
- vfe_camif_timer4_a, vfe_camif_timer4_b, vfe_camif_timer4_c,
- vfe_camif_timer5_a, vfe_camif_timer5_b, vfe_camif_timer6_a,
- vfe_camif_timer6_b, vfe_camif_timer6_c, vfe_camif_timer7_a,
- vfe_camif_timer7_b, vfe_camif_timer7_c, wlan
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- msmgpio: pinctrl@800000 {
- compatible = "qcom,msm8960-pinctrl";
- reg = <0x800000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&msmgpio 0 0 152>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 16 0x4>;
-
- gsbi8_uart: gsbi8-uart {
- mux {
- pins = "gpio34", "gpio35";
- function = "gsbi8";
- };
-
- tx {
- pins = "gpio34";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio35";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml
new file mode 100644
index 000000000000..7301318094c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8960-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8960 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8960 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8960-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 76
+
+ gpio-line-names:
+ maxItems: 152
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8960-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8960-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8960-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-1])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc3_clk, sdc3_cmd,
+ sdc3_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, audio_pcm, bt, cam_mclk0, cam_mclk1, cam_mclk2,
+ codec_mic_i2s, codec_spkr_i2s, ext_gps, fm, gps_blanking,
+ gps_pps_in, gps_pps_out, gp_clk_0a, gp_clk_0b, gp_clk_1a,
+ gp_clk_1b, gp_clk_2a, gp_clk_2b, gp_mn, gp_pdm_0a, gp_pdm_0b,
+ gp_pdm_1a, gp_pdm_1b, gp_pdm_2a, gp_pdm_2b, gsbi1,
+ gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n, gsbi1_spi_cs2b_n,
+ gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n,
+ gsbi2_spi_cs3_n, gsbi3, gsbi4, gsbi4_3d_cam_i2c_l,
+ gsbi4_3d_cam_i2c_r, gsbi5, gsbi5_3d_cam_i2c_l,
+ gsbi5_3d_cam_i2c_r, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, gsbi11,
+ gsbi11_spi_cs1a_n, gsbi11_spi_cs1b_n, gsbi11_spi_cs2a_n,
+ gsbi11_spi_cs2b_n, gsbi11_spi_cs3_n, gsbi12, hdmi_cec,
+ hdmi_ddc_clock, hdmi_ddc_data, hdmi_hot_plug_detect, hsic,
+ mdp_vsync, mi2s, mic_i2s, pmb_clk, pmb_ext_ctrl, ps_hold,
+ rpm_wdog, sdc2, sdc4, sdc5, slimbus1, slimbus2, spkr_i2s,
+ ssbi1, ssbi2, ssbi_ext_gps, ssbi_pmic2, ssbi_qpa1, ssbi_ts,
+ tsif1, tsif2, ts_eoc, usb_fs1, usb_fs1_oe, usb_fs1_oe_n,
+ usb_fs2, usb_fs2_oe, usb_fs2_oe_n, vfe_camif_timer1_a,
+ vfe_camif_timer1_b, vfe_camif_timer2, vfe_camif_timer3_a,
+ vfe_camif_timer3_b, vfe_camif_timer4_a, vfe_camif_timer4_b,
+ vfe_camif_timer4_c, vfe_camif_timer5_a, vfe_camif_timer5_b,
+ vfe_camif_timer6_a, vfe_camif_timer6_b, vfe_camif_timer6_c,
+ vfe_camif_timer7_a, vfe_camif_timer7_b, vfe_camif_timer7_c,
+ wlan ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@800000 {
+ compatible = "qcom,msm8960-pinctrl";
+ reg = <0x800000 0x4000>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 152>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ spi1-default-state {
+ mosi-pins {
+ pins = "gpio6";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
+
+ miso-pins {
+ pins = "gpio7";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
+
+ cs-pins {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <12>;
+ bias-disable;
+ output-low;
+ };
+
+ clk-pins {
+ pins = "gpio9";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
deleted file mode 100644
index 004056506679..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-Qualcomm MSM8974 TLMM block
-
-Required properties:
-- compatible: "qcom,msm8974-pinctrl"
-- reg: Should be the base address and length of the TLMM block.
-- interrupts: Should be the parent IRQ of the TLMM block.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: Should be two.
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells : Should be two.
- The first cell is the gpio pin number and the
- second cell is used for optional parameters.
-- gpio-ranges: see ../gpio/gpio.txt
-
-Optional properties:
-
-- gpio-reserved-ranges: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-Qualcomm's pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
- pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength.
-
-Non-empty subnodes must specify the 'pins' property.
-Note that not all properties are valid for all pins.
-
-
-Valid values for pins are:
- gpio0-gpio145
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data
- Supports bias and drive-strength
-
- hsic_data, hsic_strobe
- Supports only mux
-
-Valid values for function are:
- cci_i2c0, cci_i2c1, uim1, uim2, uim_batt_alarm,
- blsp_uim1, blsp_uart1, blsp_i2c1, blsp_spi1,
- blsp_uim2, blsp_uart2, blsp_i2c2, blsp_spi2,
- blsp_uim3, blsp_uart3, blsp_i2c3, blsp_spi3,
- blsp_uim4, blsp_uart4, blsp_i2c4, blsp_spi4,
- blsp_uim5, blsp_uart5, blsp_i2c5, blsp_spi5,
- blsp_uim6, blsp_uart6, blsp_i2c6, blsp_spi6,
- blsp_uim7, blsp_uart7, blsp_i2c7, blsp_spi7,
- blsp_uim8, blsp_uart8, blsp_i2c8, blsp_spi8,
- blsp_uim9, blsp_uart9, blsp_i2c9, blsp_spi9,
- blsp_uim10, blsp_uart10, blsp_i2c10, blsp_spi10,
- blsp_uim11, blsp_uart11, blsp_i2c11, blsp_spi11,
- blsp_uim12, blsp_uart12, blsp_i2c12, blsp_spi12,
- blsp_spi1_cs1, blsp_spi2_cs2, blsp_spi_cs3, blsp_spi2_cs1, blsp_spi2_cs2
- blsp_spi2_cs3, blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3,
- sdc3, sdc4, gcc_gp_clk1, gcc_gp_clk2, gcc_gp_clk3, cci_timer0, cci_timer1,
- cci_timer2, cci_timer3, cci_async_in0, cci_async_in1, cci_async_in2,
- cam_mckl0, cam_mclk1, cam_mclk2, cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc,
- hdmi_hpd, edp_hpd, gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk,
- gp_mn, tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s, spkr_mi2s,
- ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus, hsic_ctl, gpio
-
- (Note that this is not yet the complete list of functions)
-
-
-
-Example:
-
- msmgpio: pinctrl@fd510000 {
- compatible = "qcom,msm8974-pinctrl";
- reg = <0xfd510000 0x4000>;
-
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&msmgpio 0 0 146>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <0 208 0>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_default>;
-
- uart2_default: uart2_default {
- mux {
- pins = "gpio4", "gpio5";
- function = "blsp_uart2";
- };
-
- tx {
- pins = "gpio4";
- drive-strength = <4>;
- bias-disable;
- };
-
- rx {
- pins = "gpio5";
- drive-strength = <2>;
- bias-pull-up;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml
new file mode 100644
index 000000000000..a9aff442824c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml
@@ -0,0 +1,165 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8974-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8974 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8974 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8974-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 73
+
+ gpio-line-names:
+ maxItems: 146
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8974-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8974-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8974-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-5])$"
+ - enum: [ hsic_data, hsic_strobe, sdc1_clk, sdc1_cmd, sdc1_data,
+ sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, cci_i2c0, cci_i2c1, uim1, uim2, uim_batt_alarm,
+ blsp_uim1, blsp_uart1, blsp_i2c1, blsp_spi1, blsp_uim2,
+ blsp_uart2, blsp_i2c2, blsp_spi2, blsp_uim3, blsp_uart3,
+ blsp_i2c3, blsp_spi3, blsp_uim4, blsp_uart4, blsp_i2c4,
+ blsp_spi4, blsp_uim5, blsp_uart5, blsp_i2c5, blsp_spi5,
+ blsp_uim6, blsp_uart6, blsp_i2c6, blsp_spi6, blsp_uim7,
+ blsp_uart7, blsp_i2c7, blsp_spi7, blsp_uim8, blsp_uart8,
+ blsp_i2c8, blsp_spi8, blsp_uim9, blsp_uart9, blsp_i2c9,
+ blsp_spi9, blsp_uim10, blsp_uart10, blsp_i2c10, blsp_spi10,
+ blsp_uim11, blsp_uart11, blsp_i2c11, blsp_spi11, blsp_uim12,
+ blsp_uart12, blsp_i2c12, blsp_spi12, blsp_spi1_cs1,
+ blsp_spi2_cs2, blsp_spi_cs3, blsp_spi2_cs1, blsp_spi2_cs2
+ blsp_spi2_cs3, blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3,
+ sdc3, sdc4, gcc_gp_clk1, gcc_gp_clk2, gcc_gp_clk3, cci_timer0,
+ cci_timer1, cci_timer2, cci_timer3, cci_async_in0,
+ cci_async_in1, cci_async_in2, cam_mckl0, cam_mclk1, cam_mclk2,
+ cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc, hdmi_hpd, edp_hpd,
+ gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk, gp_mn,
+ tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s,
+ spkr_mi2s, ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus, hsic_ctl ]
+
+ required:
+ - pins
+
+ allOf:
+ - if:
+ properties:
+ pins:
+ contains:
+ enum:
+ - hsic_data
+ - hsic_strobe
+ required:
+ - pins
+ then:
+ properties:
+ bias-pull-down: false
+ bias-pull-up: false
+ bias-disable: false
+ drive-strength: false
+ input-enable: false
+ output-high: false
+ output-low: false
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@fd510000 {
+ compatible = "qcom,msm8974-pinctrl";
+ reg = <0xfd510000 0x4000>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 146>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ sdc1-off-state {
+ clk-pins {
+ pins = "sdc1_clk";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ cmd-pins {
+ pins = "sdc1_cmd";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
+ data-pins {
+ pins = "sdc1_data";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+ };
+
+ blsp2-uart1-sleep-state {
+ pins = "gpio41", "gpio42", "gpio43", "gpio44";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ hsic-state {
+ pins = "hsic_data", "hsic_strobe";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.txt
deleted file mode 100644
index 70d04d12f136..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.txt
+++ /dev/null
@@ -1,183 +0,0 @@
-Qualcomm MSM8976 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8956 and MSM8976 platforms.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,msm8976-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio145
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data,
- sdc2_clk, sdc2_cmd, sdc2_data,
- sdc3_clk, sdc3_cmd, sdc3_data
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- gpio, blsp_uart1, blsp_spi1, smb_int, blsp_i2c1, blsp_spi2,
- blsp_uart2, blsp_i2c2, gcc_gp1_clk_b, blsp_spi3,
- qdss_tracedata_b, blsp_i2c3, gcc_gp2_clk_b, gcc_gp3_clk_b,
- blsp_spi4, cap_int, blsp_i2c4, blsp_spi5, blsp_uart5,
- qdss_traceclk_a, m_voc, blsp_i2c5, qdss_tracectl_a,
- qdss_tracedata_a, blsp_spi6, blsp_uart6, qdss_tracectl_b,
- blsp_i2c6, qdss_traceclk_b, mdp_vsync, pri_mi2s_mclk_a,
- sec_mi2s_mclk_a, cam_mclk, cci0_i2c, cci1_i2c, blsp1_spi,
- blsp3_spi, gcc_gp1_clk_a, gcc_gp2_clk_a, gcc_gp3_clk_a,
- uim_batt, sd_write, uim1_data, uim1_clk, uim1_reset,
- uim1_present, uim2_data, uim2_clk, uim2_reset,
- uim2_present, ts_xvdd, mipi_dsi0, us_euro, ts_resout,
- ts_sample, sec_mi2s_mclk_b, pri_mi2s, codec_reset,
- cdc_pdm0, us_emitter, pri_mi2s_mclk_b, pri_mi2s_mclk_c,
- lpass_slimbus, lpass_slimbus0, lpass_slimbus1, codec_int1,
- codec_int2, wcss_bt, sdc3, wcss_wlan2, wcss_wlan1,
- wcss_wlan0, wcss_wlan, wcss_fm, key_volp, key_snapshot,
- key_focus, key_home, pwr_down, dmic0_clk, hdmi_int,
- dmic0_data, wsa_vi, wsa_en, blsp_spi8, wsa_irq, blsp_i2c8,
- pa_indicator, modem_tsync, ssbi_wtr1, gsm1_tx, gsm0_tx,
- sdcard_det, sec_mi2s, ss_switch,
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@1000000 {
- compatible = "qcom,msm8976-pinctrl";
- reg = <0x1000000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 145>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- blsp1_uart2_active: blsp1_uart2_active {
- mux {
- pins = "gpio4", "gpio5", "gpio6", "gpio7";
- function = "blsp_uart2";
- };
-
- config {
- pins = "gpio4", "gpio5", "gpio6", "gpio7";
- drive-strength = <2>;
- bias-disable;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml
new file mode 100644
index 000000000000..501329bff905
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8976-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8976 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8976 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8976-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 73
+
+ gpio-line-names:
+ maxItems: 145
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8976-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8976-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8976-tlmm-state:
+ type: object
+ description:
+ Desired pin configuration for a device or its specific state (like sleep
+ or active).
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this state.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-4])$"
+ - enum: [ qdsd_clk, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2,
+ qdsd_data3, sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk,
+ sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, blsp_uart1, blsp_spi1, smb_int, blsp_i2c1, blsp_spi2,
+ blsp_uart2, blsp_i2c2, gcc_gp1_clk_b, blsp_spi3,
+ qdss_tracedata_b, blsp_i2c3, gcc_gp2_clk_b, gcc_gp3_clk_b,
+ blsp_spi4, cap_int, blsp_i2c4, blsp_spi5, blsp_uart5,
+ qdss_traceclk_a, m_voc, blsp_i2c5, qdss_tracectl_a,
+ qdss_tracedata_a, blsp_spi6, blsp_uart6, qdss_tracectl_b,
+ blsp_i2c6, qdss_traceclk_b, mdp_vsync, pri_mi2s_mclk_a,
+ sec_mi2s_mclk_a, cam_mclk, cci0_i2c, cci1_i2c, blsp1_spi,
+ blsp3_spi, gcc_gp1_clk_a, gcc_gp2_clk_a, gcc_gp3_clk_a,
+ uim_batt, sd_write, uim1_data, uim1_clk, uim1_reset,
+ uim1_present, uim2_data, uim2_clk, uim2_reset, uim2_present,
+ ts_xvdd, mipi_dsi0, us_euro, ts_resout, ts_sample,
+ sec_mi2s_mclk_b, pri_mi2s, codec_reset, cdc_pdm0, us_emitter,
+ pri_mi2s_mclk_b, pri_mi2s_mclk_c, lpass_slimbus,
+ lpass_slimbus0, lpass_slimbus1, codec_int1, codec_int2,
+ wcss_bt, sdc3, wcss_wlan2, wcss_wlan1, wcss_wlan0, wcss_wlan,
+ wcss_fm, key_volp, key_snapshot, key_focus, key_home, pwr_down,
+ dmic0_clk, hdmi_int, dmic0_data, wsa_vi, wsa_en, blsp_spi8,
+ wsa_irq, blsp_i2c8, pa_indicator, modem_tsync, ssbi_wtr1,
+ gsm1_tx, gsm0_tx, sdcard_det, sec_mi2s, ss_switch ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,msm8976-pinctrl";
+ reg = <0x1000000 0x300000>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 145>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-uart2-active-state {
+ pins = "gpio4", "gpio5", "gpio6", "gpio7";
+ function = "blsp_uart2";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt
deleted file mode 100644
index da52df6273bc..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt
+++ /dev/null
@@ -1,186 +0,0 @@
-Qualcomm MSM8994 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8994 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: Should contain one of:
- "qcom,msm8992-pinctrl",
- "qcom,msm8994-pinctrl".
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio145
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data sdc1_rclk, sdc2_clk,
- sdc2_cmd, sdc2_data
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- audio_ref_clk, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
- blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_i2c9, blsp_i2c10, blsp_i2c11,
- blsp_i2c12, blsp_spi1, blsp_spi1_cs1, blsp_spi1_cs2, blsp_spi1_cs3,
- blsp_spi2, blsp_spi2_cs1, blsp_spi2_cs2, blsp_spi2_cs3, blsp_spi3,
- blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9,
- blsp_spi10, blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3, blsp_spi11,
- blsp_spi12, blsp_uart1, blsp_uart2, blsp_uart3, blsp_uart4, blsp_uart5,
- blsp_uart6, blsp_uart7, blsp_uart8, blsp_uart9, blsp_uart10, blsp_uart11,
- blsp_uart12, blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5,
- blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10, blsp_uim11,
- blsp_uim12, blsp11_i2c_scl_b, blsp11_i2c_sda_b, blsp11_uart_rx_b,
- blsp11_uart_tx_b, cam_mclk0, cam_mclk1, cam_mclk2, cam_mclk3,
- cci_async_in0, cci_async_in1, cci_async_in2, cci_i2c0, cci_i2c1,
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
- gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a,
- gcc_gp3_clk_b, gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk,
- gp1_clk, gps_tx, gsm_tx, hdmi_cec, hdmi_ddc, hdmi_hpd, hdmi_rcv,
- mdp_vsync, mss_lte, nav_pps, nav_tsync, qdss_cti_trig_in_a,
- qdss_cti_trig_in_b, qdss_cti_trig_in_c, qdss_cti_trig_in_d,
- qdss_cti_trig_out_a, qdss_cti_trig_out_b, qdss_cti_trig_out_c,
- qdss_cti_trig_out_d, qdss_traceclk_a, qdss_traceclk_b, qdss_tracectl_a,
- qdss_tracectl_b, qdss_tracedata_a, qdss_tracedata_b, qua_mi2s, pci_e0,
- pci_e1, pri_mi2s, sdc4, sec_mi2s, slimbus, spkr_i2s, ter_mi2s, tsif1,
- tsif2, uim_batt_alarm, uim1, uim2, uim3, uim4, gpio
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- msmgpio: pinctrl@fd510000 {
- compatible = "qcom,msm8994-pinctrl";
- reg = <0xfd510000 0x4000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&msmgpio 0 0 146>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- blsp1_uart2_default: blsp1_uart2_default {
- pinmux {
- pins = "gpio4", "gpio5";
- function = "blsp_uart2";
- };
- pinconf {
- pins = "gpio4", "gpio5";
- drive-strength = <16>;
- bias-disable;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml
new file mode 100644
index 000000000000..2ec10908d556
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8994-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8994 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8994 SoC.
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8992-pinctrl
+ - qcom,msm8994-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 73
+
+ gpio-line-names:
+ maxItems: 146
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8994-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8994-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8994-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-5])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
+ sdc2_cmd, sdc2_data, sdc3_clk, sdc3_cmd, sdc3_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, audio_ref_clk, blsp_i2c1, blsp_i2c2, blsp_i2c3,
+ blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8,
+ blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12, blsp_spi1,
+ blsp_spi1_cs1, blsp_spi1_cs2, blsp_spi1_cs3, blsp_spi2,
+ blsp_spi2_cs1, blsp_spi2_cs2, blsp_spi2_cs3, blsp_spi3,
+ blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7, blsp_spi8,
+ blsp_spi9, blsp_spi10, blsp_spi10_cs1, blsp_spi10_cs2,
+ blsp_spi10_cs3, blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2,
+ blsp_uart3, blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7,
+ blsp_uart8, blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12,
+ blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5,
+ blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10,
+ blsp_uim11, blsp_uim12, blsp11_i2c_scl_b, blsp11_i2c_sda_b,
+ blsp11_uart_rx_b, blsp11_uart_tx_b, cam_mclk0, cam_mclk1,
+ cam_mclk2, cam_mclk3, cci_async_in0, cci_async_in1,
+ cci_async_in2, cci_i2c0, cci_i2c1, cci_timer0, cci_timer1,
+ cci_timer2, cci_timer3, cci_timer4, gcc_gp1_clk_a,
+ gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a,
+ gcc_gp3_clk_b, gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk,
+ gp1_clk, gps_tx, gsm_tx, hdmi_cec, hdmi_ddc, hdmi_hpd,
+ hdmi_rcv, mdp_vsync, mss_lte, nav_pps, nav_tsync,
+ qdss_cti_trig_in_a, qdss_cti_trig_in_b, qdss_cti_trig_in_c,
+ qdss_cti_trig_in_d, qdss_cti_trig_out_a, qdss_cti_trig_out_b,
+ qdss_cti_trig_out_c, qdss_cti_trig_out_d, qdss_traceclk_a,
+ qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
+ qdss_tracedata_a, qdss_tracedata_b, qua_mi2s, pci_e0, pci_e1,
+ pri_mi2s, sdc4, sec_mi2s, slimbus, spkr_i2s, ter_mi2s, tsif1,
+ tsif2, uim_batt_alarm, uim1, uim2, uim3, uim4 ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@fd510000 {
+ compatible = "qcom,msm8994-pinctrl";
+ reg = <0xfd510000 0x4000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 146>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-uart2-default-state {
+ function = "blsp_uart2";
+ pins = "gpio4", "gpio5";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ blsp1-spi1-default-state {
+ default-pins {
+ pins = "gpio0", "gpio1", "gpio3";
+ function = "blsp_spi1";
+ drive-strength = <10>;
+ bias-pull-down;
+ };
+
+ cs-pins {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt
deleted file mode 100644
index a56cb882830c..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt
+++ /dev/null
@@ -1,208 +0,0 @@
-Qualcomm MSM8996 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8996 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,msm8996-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio149
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd,
- sdc2_data sdc1_rclk
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens,
- bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8,
- qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b,
- dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10,
- blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12,
- mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11,
- atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char,
- cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b,
- pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c,
- qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4,
- qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5,
- atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6,
- atest_usb20, atest_char0, dac_calib10, qdss_stm10,
- qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6,
- blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11,
- qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1,
- qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11,
- dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6,
- qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14,
- dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem,
- dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto,
- dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0,
- dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25,
- sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2,
- qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3,
- uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9,
- blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7,
- qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11,
- blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0,
- cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4,
- blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4,
- qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus,
- isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s,
- qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b,
- sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b,
- gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12,
- qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29,
- tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27,
- qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk,
- sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b,
- sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b,
- ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b,
- blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt,
- pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11,
- qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx,
- qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3,
- gpio
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@1010000 {
- compatible = "qcom,msm8996-pinctrl";
- reg = <0x01010000 0x300000>;
- interrupts = <0 208 0>;
- gpio-controller;
- gpio-ranges = <&tlmm 0 0 150>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- uart_console_active: uart_console_active {
- mux {
- pins = "gpio4", "gpio5";
- function = "blsp_uart8";
- };
-
- config {
- pins = "gpio4", "gpio5";
- drive-strength = <2>;
- bias-disable;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml
new file mode 100644
index 000000000000..496f38009c7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8996-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8996 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8996 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8996-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 75
+
+ gpio-line-names:
+ maxItems: 150
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8996-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8996-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8996-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
+ sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens,
+ bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8,
+ qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b,
+ dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10,
+ blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12,
+ mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11,
+ atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio,
+ atest_char, cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8,
+ qdss_tracedata_b, pll_reset, qdss_stm6, qdss_stm5, qdss_stm4,
+ atest_usb2, cci_i2c, qdss_stm3, dac_calib3, atest_usb23,
+ atest_char3, dac_calib4, qdss_stm2, atest_usb22, atest_char2,
+ qdss_stm1, dac_calib5, atest_usb21, atest_char1, dbg_out,
+ qdss_stm0, dac_calib6, atest_usb20, atest_char0, dac_calib10,
+ qdss_stm10, qdss_cti_trig_in_a, cci_timer4, blsp_spi6,
+ blsp_uart6, blsp_uim6, blsp2_spi, qdss_stm9,
+ qdss_cti_trig_out_a, dac_calib11, qdss_stm8, cci_timer0,
+ qdss_stm13, dac_calib7, cci_timer1, qdss_stm12, dac_calib8,
+ cci_timer2, blsp1_spi, qdss_stm11, dac_calib9, cci_timer3,
+ cci_async, dac_calib12, blsp_i2c6, qdss_tracectl_a,
+ dac_calib13, qdss_traceclk_a, dac_calib14, dac_calib15,
+ hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, dac_calib17,
+ hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, dac_calib19,
+ hdmi_hot, dac_calib20, dac_calib21, pci_e0, dac_calib22,
+ dac_calib23, dac_calib24, tsif1_sync, dac_calib25, sd_write,
+ tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, qdss_cti,
+ blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3, uim3,
+ blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9,
+ blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7,
+ qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11,
+ blsp_uart11, blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a,
+ blsp_i2c11, cri_trng0, cri_trng1, cri_trng, qdss_stm18,
+ pri_mi2s, qdss_stm17, blsp_spi4, blsp_uart4, blsp_uim4,
+ qdss_stm16, qdss_stm15, blsp_i2c4, qdss_stm14, dac_calib26,
+ spkr_i2s, audio_ref, lpass_slimbus, isense_dbg, tsense_pwm1,
+ tsense_pwm2, btfm_slimbus, ter_mi2s, qdss_stm22, qdss_stm21,
+ qdss_stm20, qdss_stm19, gcc_gp1_clk_b, sec_mi2s, blsp_spi5,
+ blsp_uart5, blsp_uim5, gcc_gp2_clk_b, gcc_gp3_clk_b, blsp_i2c5,
+ blsp_spi12, blsp_uart12, blsp_uim12, qdss_stm25, qdss_stm31,
+ blsp_i2c12, qdss_stm30, qdss_stm29, tsif1_clk, qdss_stm28,
+ tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27, qdss_traceclk_b,
+ tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk, sdc4_clk,
+ qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b,
+ sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b,
+ ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b,
+ blsp11_uart_rx_b, blsp11_i2c_sda_b, prng_rosc,
+ blsp11_i2c_scl_b, uim2, uim1, uim_batt, pci_e2, pa_indicator,
+ adsp_ext, ddr_bist, qdss_tracedata_11, qdss_tracedata_12,
+ modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx, qspi_cs, ssbi2,
+ ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3 ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1010000 {
+ compatible = "qcom,msm8996-pinctrl";
+ reg = <0x01010000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 150>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-spi1-default-state {
+ spi-pins {
+ pins = "gpio0", "gpio1", "gpio3";
+ function = "blsp_spi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
+
+ cs-pins {
+ pins = "gpio2";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ output-high;
+ };
+ };
+
+ blsp1-spi1-sleep-state {
+ pins = "gpio0", "gpio1", "gpio2", "gpio3";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt
deleted file mode 100644
index c4de930f2406..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-Qualcomm MSM8998 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-MSM8998 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,msm8998-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio149
- Supports mux, bias and drive-strength
-
- sdc2_clk, sdc2_cmd, sdc2_data
- Supports bias and drive-strength
-
- ufs_reset
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- gpio, adsp_ext, agera_pll, atest_char, atest_gpsadc0,
- atest_gpsadc1, atest_tsens, atest_tsens2, atest_usb1,
- atest_usb10, atest_usb11, atest_usb12, atest_usb13,
- audio_ref, bimc_dte0, bimc_dte1, blsp10_spi, blsp10_spi_a,
- blsp10_spi_b, blsp11_i2c, blsp1_spi, blsp1_spi_a,
- blsp1_spi_b, blsp2_spi, blsp9_spi, blsp_i2c1, blsp_i2c2,
- blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7,
- blsp_i2c8, blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
- blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5,
- blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10,
- blsp_spi11, blsp_spi12, blsp_uart1_a, blsp_uart1_b,
- blsp_uart2_a, blsp_uart2_b, blsp_uart3_a, blsp_uart3_b,
- blsp_uart7_a, blsp_uart7_b, blsp_uart8, blsp_uart8_a,
- blsp_uart8_b, blsp_uart9_a, blsp_uart9_b, blsp_uim1_a,
- blsp_uim1_b, blsp_uim2_a, blsp_uim2_b, blsp_uim3_a,
- blsp_uim3_b, blsp_uim7_a, blsp_uim7_b, blsp_uim8_a,
- blsp_uim8_b, blsp_uim9_a, blsp_uim9_b, bt_reset,
- btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0,
- cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, edp_hot, edp_lcd,
- gcc_gp1_a, gcc_gp1_b, gcc_gp2_a, gcc_gp2_b, gcc_gp3_a,
- gcc_gp3_b, hdmi_cec, hdmi_ddc, hdmi_hot, hdmi_rcv,
- isense_dbg, jitter_bist, ldo_en, ldo_update, lpass_slimbus,
- m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2,
- mdp_vsync3, mdp_vsync_a, mdp_vsync_b, modem_tsync, mss_lte,
- nav_dr, nav_pps, pa_indicator, pci_e0, phase_flag,
- pll_bypassnl, pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc,
- pwr_crypto, pwr_modem, pwr_nav, qdss_cti0_a, qdss_cti0_b,
- qdss_cti1_a, qdss_cti1_b, qdss, qlink_enable,
- qlink_request, qua_mi2s, sd_card, sd_write, sdc40, sdc41,
- sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu,
- spkr_i2s, ssbi1, ssc_irq, ter_mi2s, tgu_ch0, tgu_ch1,
- tsense_pwm1, tsense_pwm2, tsif0, tsif1,
- uim1_clk, uim1_data, uim1_present,
- uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset,
- uim_batt, usb_phy, vfr_1, vsense_clkout, vsense_data0,
- vsense_data1, vsense_mode, wlan1_adc0, wlan1_adc1,
- wlan2_adc0, wlan2_adc1,
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@03400000 {
- compatible = "qcom,msm8998-pinctrl";
- reg = <0x03400000 0xc00000>;
- interrupts = <0 208 0>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 175>;
- gpio-reserved-ranges = <0 4>, <81 4>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- uart_console_active: uart_console_active {
- mux {
- pins = "gpio4", "gpio5";
- function = "blsp_uart8_a";
- };
-
- config {
- pins = "gpio4", "gpio5";
- drive-strength = <2>;
- bias-disable;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml
new file mode 100644
index 000000000000..3b098a226a67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,msm8998-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8998 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm MSM8998 SoC.
+
+properties:
+ compatible:
+ const: qcom,msm8998-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 75
+
+ gpio-line-names:
+ maxItems: 150
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-msm8998-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-msm8998-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-msm8998-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9])$"
+ - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, adsp_ext, agera_pll, atest_char, atest_gpsadc0,
+ atest_gpsadc1, atest_tsens, atest_tsens2, atest_usb1,
+ atest_usb10, atest_usb11, atest_usb12, atest_usb13, audio_ref,
+ bimc_dte0, bimc_dte1, blsp10_spi, blsp10_spi_a, blsp10_spi_b,
+ blsp11_i2c, blsp1_spi, blsp1_spi_a, blsp1_spi_b, blsp2_spi,
+ blsp9_spi, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4,
+ blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_i2c9,
+ blsp_i2c10, blsp_i2c11, blsp_i2c12, blsp_spi1, blsp_spi2,
+ blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7,
+ blsp_spi8, blsp_spi9, blsp_spi10, blsp_spi11, blsp_spi12,
+ blsp_uart1_a, blsp_uart1_b, blsp_uart2_a, blsp_uart2_b,
+ blsp_uart3_a, blsp_uart3_b, blsp_uart7_a, blsp_uart7_b,
+ blsp_uart8, blsp_uart8_a, blsp_uart8_b, blsp_uart9_a,
+ blsp_uart9_b, blsp_uim1_a, blsp_uim1_b, blsp_uim2_a,
+ blsp_uim2_b, blsp_uim3_a, blsp_uim3_b, blsp_uim7_a,
+ blsp_uim7_b, blsp_uim8_a, blsp_uim8_b, blsp_uim9_a,
+ blsp_uim9_b, bt_reset, btfm_slimbus, cam_mclk, cci_async,
+ cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+ cci_timer4, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist,
+ edp_hot, edp_lcd, gcc_gp1_a, gcc_gp1_b, gcc_gp2_a, gcc_gp2_b,
+ gcc_gp3_a, gcc_gp3_b, hdmi_cec, hdmi_ddc, hdmi_hot, hdmi_rcv,
+ isense_dbg, jitter_bist, ldo_en, ldo_update, lpass_slimbus,
+ m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2,
+ mdp_vsync3, mdp_vsync_a, mdp_vsync_b, modem_tsync, mss_lte,
+ nav_dr, nav_pps, pa_indicator, pci_e0, phase_flag,
+ pll_bypassnl, pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc,
+ pwr_crypto, pwr_modem, pwr_nav, qdss_cti0_a, qdss_cti0_b,
+ qdss_cti1_a, qdss_cti1_b, qdss, qlink_enable, qlink_request,
+ qua_mi2s, sd_card, sd_write, sdc40, sdc41, sdc42, sdc43,
+ sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, spkr_i2s, ssbi1, ssc_irq,
+ ter_mi2s, tgu_ch0, tgu_ch1, tsense_pwm1, tsense_pwm2, tsif0,
+ tsif1, uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
+ uim2_data, uim2_present, uim2_reset, uim_batt, usb_phy, vfr_1,
+ vsense_clkout, vsense_data0, vsense_data1, vsense_mode,
+ wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1 ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@3400000 {
+ compatible = "qcom,msm8998-pinctrl";
+ reg = <0x03400000 0xc00000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-ranges = <&tlmm 0 0 150>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-reserved-ranges = <0 4>, <81 4>;
+
+ sdc2-off-state {
+ clk-pins {
+ pins = "sdc2_clk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cmd-pins {
+ pins = "sdc2_cmd";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ data-pins {
+ pins = "sdc2_data";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ sdc2-cd-state {
+ pins = "gpio95";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index 694898f382be..386c31e9c52b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -24,9 +24,12 @@ properties:
- qcom,pm6150-gpio
- qcom,pm6150l-gpio
- qcom,pm6350-gpio
+ - qcom,pm6450-gpio
+ - qcom,pm7250b-gpio
- qcom,pm7325-gpio
+ - qcom,pm7550-gpio
+ - qcom,pm7550ba-gpio
- qcom,pm8005-gpio
- - qcom,pm8008-gpio
- qcom,pm8018-gpio
- qcom,pm8019-gpio
- qcom,pm8038-gpio
@@ -39,25 +42,48 @@ properties:
- qcom,pm8350b-gpio
- qcom,pm8350c-gpio
- qcom,pm8450-gpio
+ - qcom,pm8550-gpio
+ - qcom,pm8550b-gpio
+ - qcom,pm8550ve-gpio
+ - qcom,pm8550vs-gpio
- qcom,pm8916-gpio
- qcom,pm8917-gpio
- qcom,pm8921-gpio
+ - qcom,pm8937-gpio
- qcom,pm8941-gpio
- qcom,pm8950-gpio
+ - qcom,pm8953-gpio
- qcom,pm8994-gpio
- qcom,pm8998-gpio
- qcom,pma8084-gpio
+ - qcom,pmc8180-gpio
+ - qcom,pmc8180c-gpio
+ - qcom,pmc8380-gpio
+ - qcom,pmcx0102-gpio
+ - qcom,pmd8028-gpio
+ - qcom,pmh0101-gpio
+ - qcom,pmh0104-gpio
+ - qcom,pmh0110-gpio
+ - qcom,pmi632-gpio
- qcom,pmi8950-gpio
- qcom,pmi8994-gpio
- qcom,pmi8998-gpio
+ - qcom,pmih0108-gpio
+ - qcom,pmiv0104-gpio
- qcom,pmk8350-gpio
+ - qcom,pmk8550-gpio
+ - qcom,pmk8850-gpio
- qcom,pmm8155au-gpio
+ - qcom,pmm8654au-gpio
- qcom,pmp8074-gpio
- qcom,pmr735a-gpio
- qcom,pmr735b-gpio
+ - qcom,pmr735d-gpio
- qcom,pms405-gpio
- qcom,pmx55-gpio
- qcom,pmx65-gpio
+ - qcom,pmx75-gpio
+ - qcom,pmxr2230-gpio
- enum:
- qcom,spmi-gpio
@@ -108,8 +134,8 @@ allOf:
compatible:
contains:
enum:
- - qcom,pm8008-gpio
- qcom,pmi8950-gpio
+ - qcom,pmr735d-gpio
then:
properties:
gpio-line-names:
@@ -126,6 +152,7 @@ allOf:
- qcom,pm8005-gpio
- qcom,pm8450-gpio
- qcom,pm8916-gpio
+ - qcom,pmd8028-gpio
- qcom,pmk8350-gpio
- qcom,pmr735a-gpio
- qcom,pmr735b-gpio
@@ -145,6 +172,8 @@ allOf:
enum:
- qcom,pm8018-gpio
- qcom,pm8019-gpio
+ - qcom,pm8550vs-gpio
+ - qcom,pmk8550-gpio
then:
properties:
gpio-line-names:
@@ -159,9 +188,16 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pm7550ba-gpio
- qcom,pm8226-gpio
- qcom,pm8350b-gpio
+ - qcom,pm8550ve-gpio
+ - qcom,pm8937-gpio
- qcom,pm8950-gpio
+ - qcom,pm8953-gpio
+ - qcom,pmi632-gpio
+ - qcom,pmh0104-gpio
+ - qcom,pmk8850-gpio
then:
properties:
gpio-line-names:
@@ -177,6 +213,7 @@ allOf:
contains:
enum:
- qcom,pm6350-gpio
+ - qcom,pm6450-gpio
- qcom,pm8350c-gpio
then:
properties:
@@ -198,7 +235,9 @@ allOf:
- qcom,pm8150-gpio
- qcom,pm8350-gpio
- qcom,pmc8180-gpio
+ - qcom,pmc8380-gpio
- qcom,pmi8994-gpio
+ - qcom,pmiv0104-gpio
- qcom,pmm8155au-gpio
then:
properties:
@@ -231,12 +270,17 @@ allOf:
enum:
- qcom,pm660l-gpio
- qcom,pm6150l-gpio
+ - qcom,pm7250b-gpio
+ - qcom,pm7550-gpio
- qcom,pm8038-gpio
- qcom,pm8150b-gpio
- qcom,pm8150l-gpio
+ - qcom,pm8550-gpio
+ - qcom,pm8550b-gpio
- qcom,pmc8180c-gpio
- qcom,pmp8074-gpio
- qcom,pms405-gpio
+ - qcom,pmxr2230-gpio
then:
properties:
gpio-line-names:
@@ -266,6 +310,8 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pmcx0102-gpio
+ - qcom,pmh0110-gpio
- qcom,pmi8998-gpio
then:
properties:
@@ -281,7 +327,24 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pmh0101-gpio
+ - qcom,pmih0108-gpio
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 18
+ maxItems: 18
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 9
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pmx65-gpio
+ - qcom,pmx75-gpio
then:
properties:
gpio-line-names:
@@ -371,18 +434,23 @@ allOf:
patternProperties:
'-state$':
oneOf:
- - $ref: "#/$defs/qcom-pmic-gpio-state"
+ - $ref: '#/$defs/qcom-pmic-gpio-state'
- patternProperties:
- "(pinconf|-pins)$":
- $ref: "#/$defs/qcom-pmic-gpio-state"
+ '(pinconf|-pins)$':
+ $ref: '#/$defs/qcom-pmic-gpio-state'
additionalProperties: false
+ '-hog(-[0-9]+)?$':
+ type: object
+ required:
+ - gpio-hog
+
$defs:
qcom-pmic-gpio-state:
type: object
allOf:
- - $ref: "pinmux-node.yaml"
- - $ref: "pincfg-node.yaml"
+ - $ref: pinmux-node.yaml
+ - $ref: pincfg-node.yaml
properties:
pins:
description:
@@ -392,9 +460,11 @@ $defs:
- gpio1-gpio10 for pm6150
- gpio1-gpio12 for pm6150l
- gpio1-gpio9 for pm6350
+ - gpio1-gpio9 for pm6450
+ - gpio1-gpio12 for pm7250b
- gpio1-gpio10 for pm7325
+ - gpio1-gpio8 for pm7550ba
- gpio1-gpio4 for pm8005
- - gpio1-gpio2 for pm8008
- gpio1-gpio6 for pm8018
- gpio1-gpio12 for pm8038
- gpio1-gpio40 for pm8058
@@ -407,28 +477,48 @@ $defs:
- gpio1-gpio10 for pm8350
- gpio1-gpio8 for pm8350b
- gpio1-gpio9 for pm8350c
+ - gpio1-gpio4 for pm8450
+ - gpio1-gpio12 for pm8550
+ - gpio1-gpio12 for pm8550b
+ - gpio1-gpio8 for pm8550ve
+ - gpio1-gpio6 for pm8550vs
- gpio1-gpio38 for pm8917
- gpio1-gpio44 for pm8921
+ - gpio1-gpio8 for pm8937 (hole on gpio3, gpio4 and gpio6)
- gpio1-gpio36 for pm8941
- gpio1-gpio8 for pm8950 (hole on gpio3)
+ - gpio1-gpio8 for pm8953 (hole on gpio3 and gpio6)
- gpio1-gpio22 for pm8994
- gpio1-gpio26 for pm8998
- gpio1-gpio22 for pma8084
+ - gpio1-gpio14 for pmcx0102
+ - gpio1-gpio4 for pmd8028
+ - gpio1-gpio18 for pmh0101
+ - gpio1-gpio8 for pmh0104
+ - gpio1-gpio14 for pmh0110
+ - gpio1-gpio8 for pmi632
- gpio1-gpio2 for pmi8950
- gpio1-gpio10 for pmi8994
+ - gpio1-gpio18 for pmih0108
- gpio1-gpio4 for pmk8350
+ - gpio1-gpio6 for pmk8550
+ - gpio1-gpio8 for pmk8850
- gpio1-gpio10 for pmm8155au
+ - gpio1-gpio12 for pmm8654au
- gpio1-gpio12 for pmp8074 (holes on gpio1 and gpio12)
- gpio1-gpio4 for pmr735a
- gpio1-gpio4 for pmr735b
+ - gpio1-gpio2 for pmr735d
- gpio1-gpio12 for pms405 (holes on gpio1, gpio9
and gpio10)
- gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10
and gpio11)
- gpio1-gpio16 for pmx65
+ - gpio1-gpio16 for pmx75
+ - gpio1-gpio12 for pmxr2230
items:
- pattern: "^gpio([0-9]+)$"
+ pattern: '^gpio([0-9]+)$'
function:
items:
@@ -507,6 +597,7 @@ $defs:
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
pm8921_gpio: gpio@150 {
@@ -530,5 +621,12 @@ examples:
power-source = <PM8921_GPIO_S4>;
};
};
+
+ otg-hog {
+ gpio-hog;
+ gpios = <35 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "otg-gpio";
+ };
};
...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
index df79274d0ec3..daf4c1c03712 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml
@@ -15,28 +15,31 @@ description:
properties:
compatible:
- items:
- - enum:
- - qcom,pm8018-mpp
- - qcom,pm8019-mpp
- - qcom,pm8038-mpp
- - qcom,pm8058-mpp
- - qcom,pm8226-mpp
- - qcom,pm8821-mpp
- - qcom,pm8841-mpp
- - qcom,pm8916-mpp
- - qcom,pm8917-mpp
- - qcom,pm8921-mpp
- - qcom,pm8941-mpp
- - qcom,pm8950-mpp
- - qcom,pmi8950-mpp
- - qcom,pm8994-mpp
- - qcom,pma8084-mpp
- - qcom,pmi8994-mpp
-
- - enum:
- - qcom,spmi-mpp
- - qcom,ssbi-mpp
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm8019-mpp
+ - qcom,pm8226-mpp
+ - qcom,pm8841-mpp
+ - qcom,pm8916-mpp
+ - qcom,pm8937-mpp
+ - qcom,pm8941-mpp
+ - qcom,pm8950-mpp
+ - qcom,pmi8950-mpp
+ - qcom,pm8994-mpp
+ - qcom,pma8084-mpp
+ - qcom,pmi8994-mpp
+ - const: qcom,spmi-mpp
+ - items:
+ - enum:
+ - qcom,pm8018-mpp
+ - qcom,pm8038-mpp
+ - qcom,pm8058-mpp
+ - qcom,pm8821-mpp
+ - qcom,pm8901-mpp
+ - qcom,pm8917-mpp
+ - qcom,pm8921-mpp
+ - const: qcom,ssbi-mpp
reg:
maxItems: 1
@@ -71,18 +74,18 @@ required:
patternProperties:
'-state$':
oneOf:
- - $ref: "#/$defs/qcom-pmic-mpp-state"
+ - $ref: '#/$defs/qcom-pmic-mpp-state'
- patternProperties:
- "mpp":
- $ref: "#/$defs/qcom-pmic-mpp-state"
+ '-pins$':
+ $ref: '#/$defs/qcom-pmic-mpp-state'
additionalProperties: false
$defs:
qcom-pmic-mpp-state:
type: object
allOf:
- - $ref: "pinmux-node.yaml"
- - $ref: "pincfg-node.yaml"
+ - $ref: pinmux-node.yaml
+ - $ref: pincfg-node.yaml
properties:
pins:
description:
@@ -90,13 +93,14 @@ $defs:
this subnode. Valid pins are
- mpp1-mpp4 for pm8841
- mpp1-mpp4 for pm8916
+ - mpp1-mpp4 for pm8937
- mpp1-mpp8 for pm8941
- mpp1-mpp4 for pm8950
- mpp1-mpp4 for pmi8950
- mpp1-mpp4 for pma8084
items:
- pattern: "^mpp([0-9]+)$"
+ pattern: '^mpp([0-9]+)$'
function:
items:
@@ -143,8 +147,9 @@ $defs:
enum: [0, 1, 2, 3, 4, 5, 6, 7]
qcom,paired:
- - description:
- Indicates that the pin should be operating in paired mode.
+ type: boolean
+ description:
+ Indicates that the pin should be operating in paired mode.
required:
- pins
@@ -156,34 +161,40 @@ examples:
- |
#include <dt-bindings/pinctrl/qcom,pmic-mpp.h>
- pm8841_mpp: mpps@a000 {
- compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
- reg = <0xa000 0>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pm8841_mpp 0 0 4>;
- gpio-line-names = "VDD_PX_BIAS", "WLAN_LED_CTRL",
- "BT_LED_CTRL", "GPIO-F";
- interrupt-controller;
- #interrupt-cells = <2>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&pm8841_default>;
-
- mpp1-state {
- pins = "mpp1";
- function = "digital";
- input-enable;
- power-source = <PM8841_MPP_S3>;
- };
-
- default-state {
- gpio-mpp {
- pins = "mpp1", "mpp2", "mpp3", "mpp4";
- function = "digital";
- input-enable;
- power-source = <PM8841_MPP_S3>;
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8841_mpp: mpps@a000 {
+ compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp";
+ reg = <0xa000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8841_mpp 0 0 4>;
+ gpio-line-names = "VDD_PX_BIAS", "WLAN_LED_CTRL",
+ "BT_LED_CTRL", "GPIO-F";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pm8841_default>;
+
+ mpp1-state {
+ pins = "mpp1";
+ function = "digital";
+ input-enable;
+ power-source = <PM8841_MPP_S3>;
+ };
+
+ default-state {
+ gpio-pins {
+ pins = "mpp1", "mpp2", "mpp3", "mpp4";
+ function = "digital";
+ input-enable;
+ power-source = <PM8841_MPP_S3>;
+ };
+ };
};
- };
};
...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml
deleted file mode 100644
index 3f4f1c0360b5..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml
+++ /dev/null
@@ -1,167 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,qcm2290-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. QCM2290 TLMM block
-
-maintainers:
- - Shawn Guo <shawn.guo@linaro.org>
-
-description:
- This binding describes the Top Level Mode Multiplexer block found in the
- QCM2290 platform.
-
-properties:
- compatible:
- const: qcom,qcm2290-tlmm
-
- reg:
- maxItems: 1
-
- interrupts:
- description: Specifies the TLMM summary IRQ
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- description:
- Specifies the PIN numbers and Flags, as defined in defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- wakeup-parent: true
-
-#PIN CONFIGURATION NODES
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-qcm2290-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-qcm2290-tlmm-state"
-
-'$defs':
- qcom-qcm2290-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-9]|12[0-6])$"
- - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data,
- sdc2_clk, sdc2_cmd, sdc2_data ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c,
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, char_exec,
- cri_trng, cri_trng0, cri_trng1, dac_calib, dbg_out, ddr_bist,
- ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2,
- gcc_gp3, gpio, gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx,
- jitter_bist, mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1,
- mpm_pwr, mss_lte, m_voc, nav_gpio, pa_indicator, pbs0, pbs1,
- pbs2, pbs3, pbs4, pbs5, pbs6, pbs7, pbs8, pbs9, pbs10, pbs11,
- pbs12, pbs13, pbs14, pbs15, pbs_out, phase_flag, pll_bist,
- pll_bypassnl, pll_reset, prng_rosc, pwm_0, pwm_1, pwm_2, pwm_3,
- pwm_4, pwm_5, pwm_6, pwm_7, pwm_8, pwm_9, qdss_cti, qdss_gpio,
- qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb, sdc2_tb, sd_write,
- ssbi_wtr1, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm,
- uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
- uim2_data, uim2_present, uim2_reset, usb_phy, vfr_1,
- vsense_trigger, wlan1_adc0, wlan1_adc1 ]
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- required:
- - pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@500000 {
- compatible = "qcom,qcm2290-tlmm";
- reg = <0x500000 0x300000>;
- interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 127>;
-
- sdc2_on_state: sdc2-on-state {
- clk {
- pins = "sdc2_clk";
- bias-disable;
- drive-strength = <16>;
- };
-
- cmd {
- pins = "sdc2_cmd";
- bias-pull-up;
- drive-strength = <10>;
- };
-
- data {
- pins = "sdc2_data";
- bias-pull-up;
- drive-strength = <10>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
new file mode 100644
index 000000000000..e123beb33aef
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,qcm2290-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QCM2290 TLMM block
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm QCM2290 SoC.
+
+properties:
+ compatible:
+ const: qcom,qcm2290-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-qcm2290-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-qcm2290-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-qcm2290-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-9]|12[0-6])$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data,
+ sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, char_exec,
+ cri_trng, cri_trng0, cri_trng1, dac_calib, dbg_out, ddr_bist,
+ ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2,
+ gcc_gp3, gpio, gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx,
+ jitter_bist, mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1,
+ mpm_pwr, mss_lte, m_voc, nav_gpio, pa_indicator, pbs0, pbs1,
+ pbs2, pbs3, pbs4, pbs5, pbs6, pbs7, pbs8, pbs9, pbs10, pbs11,
+ pbs12, pbs13, pbs14, pbs15, pbs_out, phase_flag, pll_bist,
+ pll_bypassnl, pll_reset, prng_rosc, pwm_0, pwm_1, pwm_2, pwm_3,
+ pwm_4, pwm_5, pwm_6, pwm_7, pwm_8, pwm_9, qdss_cti, qdss_gpio,
+ qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb, sdc2_tb, sd_write,
+ ssbi_wtr1, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm,
+ uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
+ uim2_data, uim2_present, uim2_reset, usb_phy, vfr_1,
+ vsense_trigger, wlan1_adc0, wlan1_adc1 ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@500000 {
+ compatible = "qcom,qcm2290-tlmm";
+ reg = <0x500000 0x300000>;
+ interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 127>;
+
+ sdc2_on_state: sdc2-on-state {
+ clk-pins {
+ pins = "sdc2_clk";
+ bias-disable;
+ drive-strength = <16>;
+ };
+
+ cmd-pins {
+ pins = "sdc2_cmd";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ data-pins {
+ pins = "sdc2_data";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.txt
deleted file mode 100644
index a50e74684195..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.txt
+++ /dev/null
@@ -1,199 +0,0 @@
-Qualcomm QCS404 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-QCS404 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,qcs404-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the north, south and east TLMM
- tiles.
-
-- reg-names:
- Usage: required
- Value type: <stringlist>
- Defintiion: names for the cells of reg, must contain "north", "south"
- and "east".
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio119
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd,
- sdc2_data
- Supports bias and drive-strength
-
- ufs_reset
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- gpio, hdmi_tx, hdmi_ddc, blsp_uart_tx_a2, blsp_spi2, m_voc,
- qdss_cti_trig_in_a0, blsp_uart_rx_a2, qdss_tracectl_a,
- blsp_uart2, aud_cdc, blsp_i2c_sda_a2, qdss_tracedata_a,
- blsp_i2c_scl_a2, qdss_tracectl_b, qdss_cti_trig_in_b0,
- blsp_uart1, blsp_spi_mosi_a1, blsp_spi_miso_a1,
- qdss_tracedata_b, blsp_i2c1, blsp_spi_cs_n_a1, gcc_plltest,
- blsp_spi_clk_a1, rgb_data0, blsp_uart5, blsp_spi5,
- adsp_ext, rgb_data1, prng_rosc, rgb_data2, blsp_i2c5,
- gcc_gp1_clk_b, rgb_data3, gcc_gp2_clk_b, blsp_spi0,
- blsp_uart0, gcc_gp3_clk_b, blsp_i2c0, qdss_traceclk_b,
- pcie_clk, nfc_irq, blsp_spi4, nfc_dwl, audio_ts, rgb_data4,
- spi_lcd, blsp_uart_tx_b2, gcc_gp3_clk_a, rgb_data5,
- blsp_uart_rx_b2, blsp_i2c_sda_b2, blsp_i2c_scl_b2,
- pwm_led11, i2s_3_data0_a, ebi2_lcd, i2s_3_data1_a,
- i2s_3_data2_a, atest_char, pwm_led3, i2s_3_data3_a,
- pwm_led4, i2s_4, ebi2_a, dsd_clk_b, pwm_led5, pwm_led6,
- pwm_led7, pwm_led8, pwm_led24, spkr_dac0, blsp_i2c4,
- pwm_led9, pwm_led10, spdifrx_opt, pwm_led12, pwm_led13,
- pwm_led14, wlan1_adc1, rgb_data_b0, pwm_led15,
- blsp_spi_mosi_b1, wlan1_adc0, rgb_data_b1, pwm_led16,
- blsp_spi_miso_b1, qdss_cti_trig_out_b0, wlan2_adc1,
- rgb_data_b2, pwm_led17, blsp_spi_cs_n_b1, wlan2_adc0,
- rgb_data_b3, pwm_led18, blsp_spi_clk_b1, rgb_data_b4,
- pwm_led19, ext_mclk1_b, qdss_traceclk_a, rgb_data_b5,
- pwm_led20, atest_char3, i2s_3_sck_b, ldo_update, bimc_dte0,
- rgb_hsync, pwm_led21, i2s_3_ws_b, dbg_out, rgb_vsync,
- i2s_3_data0_b, ldo_en, hdmi_dtest, rgb_de, i2s_3_data1_b,
- hdmi_lbk9, rgb_clk, atest_char1, i2s_3_data2_b, ebi_cdc,
- hdmi_lbk8, rgb_mdp, atest_char0, i2s_3_data3_b, hdmi_lbk7,
- rgb_data_b6, rgb_data_b7, hdmi_lbk6, rgmii_int, cri_trng1,
- rgmii_wol, cri_trng0, gcc_tlmm, rgmii_ck, rgmii_tx,
- hdmi_lbk5, hdmi_pixel, hdmi_rcv, hdmi_lbk4, rgmii_ctl,
- ext_lpass, rgmii_rx, cri_trng, hdmi_lbk3, hdmi_lbk2,
- qdss_cti_trig_out_b1, rgmii_mdio, hdmi_lbk1, rgmii_mdc,
- hdmi_lbk0, ir_in, wsa_en, rgb_data6, rgb_data7,
- atest_char2, ebi_ch0, blsp_uart3, blsp_spi3, sd_write,
- blsp_i2c3, gcc_gp1_clk_a, qdss_cti_trig_in_b1,
- gcc_gp2_clk_a, ext_mclk0, mclk_in1, i2s_1, dsd_clk_a,
- qdss_cti_trig_in_a1, rgmi_dll1, pwm_led22, pwm_led23,
- qdss_cti_trig_out_a0, rgmi_dll2, pwm_led1,
- qdss_cti_trig_out_a1, pwm_led2, i2s_2, pll_bist,
- ext_mclk1_a, mclk_in2, bimc_dte1, i2s_3_sck_a, i2s_3_ws_a
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@1000000 {
- compatible = "qcom,qcs404-pinctrl";
- reg = <0x01000000 0x200000>,
- <0x01300000 0x200000>,
- <0x07b00000 0x200000>;
- reg-names = "south", "north", "east";
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 120>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml
new file mode 100644
index 000000000000..91b8dcec3f08
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,qcs404-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCS404 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm QCS404 SoC.
+
+properties:
+ compatible:
+ const: qcom,qcs404-pinctrl
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: south
+ - const: north
+ - const: east
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 60
+
+ gpio-line-names:
+ maxItems: 120
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-qcs404-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-qcs404-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-qcs404-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-9])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
+ sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, adsp_ext, atest_char, atest_char0, atest_char1,
+ atest_char2, atest_char3, aud_cdc, audio_ts, bimc_dte0,
+ bimc_dte1, blsp_i2c0, blsp_i2c1, blsp_i2c3, blsp_i2c4,
+ blsp_i2c5, blsp_i2c_scl_a2, blsp_i2c_scl_b2, blsp_i2c_sda_a2,
+ blsp_i2c_sda_b2, blsp_spi0, blsp_spi2, blsp_spi3, blsp_spi4,
+ blsp_spi5, blsp_spi_clk_a1, blsp_spi_clk_b1, blsp_spi_cs_n_a1,
+ blsp_spi_cs_n_b1, blsp_spi_miso_a1, blsp_spi_miso_b1,
+ blsp_spi_mosi_a1, blsp_spi_mosi_b1, blsp_uart0, blsp_uart1,
+ blsp_uart2, blsp_uart3, blsp_uart5, blsp_uart_rx_a2,
+ blsp_uart_rx_b2, blsp_uart_tx_a2, blsp_uart_tx_b2, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, dsd_clk_a, dsd_clk_b, ebi2_a,
+ ebi2_lcd, ebi_cdc, ebi_ch0, ext_lpass, ext_mclk0, ext_mclk1_a,
+ ext_mclk1_b, gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a,
+ gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest,
+ gcc_tlmm, hdmi_ddc, hdmi_dtest, hdmi_lbk0, hdmi_lbk1,
+ hdmi_lbk2, hdmi_lbk3, hdmi_lbk4, hdmi_lbk5, hdmi_lbk6,
+ hdmi_lbk7, hdmi_lbk8, hdmi_lbk9, hdmi_pixel, hdmi_rcv, hdmi_tx,
+ i2s_1, i2s_2, i2s_3_data0_a, i2s_3_data0_b, i2s_3_data1_a,
+ i2s_3_data1_b, i2s_3_data2_a, i2s_3_data2_b, i2s_3_data3_a,
+ i2s_3_data3_b, i2s_3_sck_a, i2s_3_sck_b, i2s_3_ws_a,
+ i2s_3_ws_b, i2s_4, ir_in, ldo_en, ldo_update, mclk_in1,
+ mclk_in2, m_voc, nfc_dwl, nfc_irq, pcie_clk, pll_bist,
+ prng_rosc, pwm_led1, pwm_led10, pwm_led11, pwm_led12,
+ pwm_led13, pwm_led14, pwm_led15, pwm_led16, pwm_led17,
+ pwm_led18, pwm_led19, pwm_led2, pwm_led20, pwm_led21,
+ pwm_led22, pwm_led23, pwm_led24, pwm_led3, pwm_led4, pwm_led5,
+ pwm_led6, pwm_led7, pwm_led8, pwm_led9, qdss_cti_trig_in_a0,
+ qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_b1,
+ qdss_cti_trig_out_a0, qdss_cti_trig_out_a1,
+ qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a,
+ qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b,
+ qdss_tracedata_a, qdss_tracedata_b, rgb_clk, rgb_data0,
+ rgb_data1, rgb_data2, rgb_data3, rgb_data4, rgb_data5,
+ rgb_data6, rgb_data7, rgb_data_b0, rgb_data_b1, rgb_data_b2,
+ rgb_data_b3, rgb_data_b4, rgb_data_b5, rgb_data_b6,
+ rgb_data_b7, rgb_de, rgb_hsync, rgb_mdp, rgb_vsync, rgmi_dll1,
+ rgmi_dll2, rgmii_ck, rgmii_ctl, rgmii_int, rgmii_mdc,
+ rgmii_mdio, rgmii_rx, rgmii_tx, rgmii_wol, sd_write,
+ spdifrx_opt, spi_lcd, spkr_dac0, wlan1_adc0, wlan1_adc1,
+ wlan2_adc0, wlan2_adc1, wsa_en ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@1000000 {
+ compatible = "qcom,qcs404-pinctrl";
+ reg = <0x01000000 0x200000>,
+ <0x01300000 0x200000>,
+ <0x07b00000 0x200000>;
+ reg-names = "south", "north", "east";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-ranges = <&tlmm 0 0 120>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-i2c1-default-state {
+ pins = "gpio24", "gpio25";
+ function = "blsp_i2c1";
+ };
+
+ blsp1-i2c2-default-state {
+ sda-pins {
+ pins = "gpio19";
+ function = "blsp_i2c_sda_a2";
+ };
+
+ scl-pins {
+ pins = "gpio20";
+ function = "blsp_i2c_scl_a2";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcs615-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcs615-tlmm.yaml
new file mode 100644
index 000000000000..2791e578c1de
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcs615-tlmm.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,qcs615-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QCS615 TLMM block
+
+maintainers:
+ - Lijuan Gao <quic_lijuang@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm QCS615 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qcs615-tlmm
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: east
+ - const: west
+ - const: south
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 62
+
+ gpio-line-names:
+ maxItems: 123
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-qcs615-tlmm-state"
+ - type: object
+ patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-qcs615-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-qcs615-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-9]|12[0-2])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk,
+ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, adsp_ext, agera_pll, aoss_cti, atest_char, atest_tsens,
+ atest_usb, cam_mclk, cci_async, cci_i2c, cci_timer, copy_gp,
+ copy_phase, cri_trng, dbg_out_clk, ddr_bist, ddr_pxi, dp_hot,
+ edp_hot, edp_lcd, emac_gcc, emac_phy_intr, forced_usb, gcc_gp,
+ gp_pdm, gps_tx, hs0_mi2s, hs1_mi2s, jitter_bist, ldo_en,
+ ldo_update, m_voc, mclk1, mclk2, mdp_vsync, mdp_vsync0_out,
+ mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out, mdp_vsync4_out,
+ mdp_vsync5_out, mi2s_1, mss_lte, nav_pps_in, nav_pps_out,
+ pa_indicator_or, pcie_clk_req, pcie_ep_rst, phase_flag, pll_bist,
+ pll_bypassnl, pll_reset_n, prng_rosc, qdss_cti, qdss_gpio,
+ qlink_enable, qlink_request, qspi, qup0, qup1, rgmii,
+ sd_write_protect, sp_cmu, ter_mi2s, tgu_ch, uim1, uim2, usb0_hs,
+ usb1_hs, usb_phy_ps, vfr_1, vsense_trigger_mirnat, wlan, wsa_clk,
+ wsa_data ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@3000000 {
+ compatible = "qcom,qcs615-tlmm";
+ reg = <0x03100000 0x300000>,
+ <0x03500000 0x300000>,
+ <0x03c00000 0x300000>;
+ reg-names = "east", "west", "south";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-ranges = <&tlmm 0 0 124>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ qup3-uart2-state {
+ pins ="gpio16", "gpio17";
+ function = "qup0";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcs8300-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcs8300-tlmm.yaml
new file mode 100644
index 000000000000..489b41dcc179
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcs8300-tlmm.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,qcs8300-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QCS8300 TLMM block
+
+maintainers:
+ - Jingyi Wang <quic_jingyw@quicinc.com>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm QCS8300 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qcs8300-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 67
+
+ gpio-line-names:
+ maxItems: 133
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-qcs8300-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-qcs8300-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-qcs8300-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2])$"
+ - enum: [ ufs_reset, sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ aoss_cti, atest_char, atest_usb2, audio_ref, cam_mclk,
+ cci_async, cci_i2c_scl, cci_i2c_sda, cci_timer, cri_trng,
+ dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3,
+ edp0_hot, edp0_lcd, edp1_lcd, egpio, emac0_mcg0, emac0_mcg1,
+ emac0_mcg2, emac0_mcg3, emac0_mdc, emac0_mdio, emac0_ptp_aux,
+ emac0_ptp_pps, gcc_gp1, gcc_gp2, gcc_gp3, gcc_gp4, gcc_gp5,
+ gpio, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c, jitter_bist,
+ mdp0_vsync0, mdp0_vsync1, mdp0_vsync3, mdp0_vsync6, mdp0_vsync7,
+ mdp_vsync, mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws,
+ mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, mi2s_mclk0,
+ mi2s_mclk1, pcie0_clkreq, pcie1_clkreq, phase_flag, pll_bist,
+ pll_clk, prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3,
+ qdss_cti, qdss_gpio, qup0_se0, qup0_se1, qup0_se2, qup0_se3,
+ qup0_se4, qup0_se5, qup0_se6, qup0_se7, qup1_se0, qup1_se1,
+ qup1_se2, qup1_se3, qup1_se4, qup1_se5, qup1_se6, qup1_se7,
+ qup2_se0, sailss_emac0, sailss_ospi, sail_top, sgmii_phy,
+ tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1,
+ tsense_pwm2, tsense_pwm3, tsense_pwm4, usb2phy_ac,
+ vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,qcs8300-tlmm";
+ reg = <0x0f100000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 134>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ qup-uart7-state {
+ pins = "gpio43", "gpio44";
+ function = "qup0_se7";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml
new file mode 100644
index 000000000000..88afeae530c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,qdu1000-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QDU1000/QRU1000 TLMM block
+
+maintainers:
+ - Melody Olvera <quic_molvera@quicinc.com>
+
+description: |
+ Top Level Mode Multiplexer pin controller found in the QDU1000 and
+ QRU1000 SoCs.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,qdu1000-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 76
+
+ gpio-line-names:
+ maxItems: 151
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-qdu1000-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-qdu1000-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-qdu1000-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|150)$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ atest_char, atest_usb, char_exec, CMO_PRI, cmu_rng,
+ dbg_out_clk, ddr_bist, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4,
+ ddr_pxi5, ddr_pxi6, ddr_pxi7, eth012_int_n, eth345_int_n,
+ gcc_gp1, gcc_gp2, gcc_gp3, gpio, gps_pps_in, hardsync_pps_in,
+ intr_c, jitter_bist_ref, pcie_clkreqn, phase_flag, pll_bist,
+ pll_clk, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable,
+ qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
+ qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss,
+ qlink3_enable, qlink3_request, qlink3_wmss, qlink4_enable,
+ qlink4_request, qlink4_wmss, qlink5_enable, qlink5_request,
+ qlink5_wmss, qlink6_enable, qlink6_request, qlink6_wmss,
+ qlink7_enable, qlink7_request, qlink7_wmss, qspi_clk, qspi_cs,
+ qspi0, qspi1, qspi2, qspi3, qup00, qup01, qup02, qup03, qup04,
+ qup05, qup06, qup07, qup08, qup10, qup11, qup12, qup13, qup14,
+ qup15, qup16, qup17, qup20, qup21, qup22, SI5518_INT, smb_alert,
+ smb_clk, smb_dat, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3,
+ tgu_ch4, tgu_ch5, tgu_ch6, tgu_ch7, tmess_prng0, tmess_prng1,
+ tmess_prng2, tmess_prng3, tod_pps_in, tsense_pwm1, tsense_pwm2,
+ usb2phy_ac, usb_con_det, usb_dfp_en, usb_phy, vfr_0, vfr_1,
+ vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl@f000000 {
+ compatible = "qcom,qdu1000-tlmm";
+ reg = <0xf000000 0x1000000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 151>;
+ wakeup-parent = <&pdc>;
+
+ uart0-default-state {
+ pins = "gpio6", "gpio7", "gpio8", "gpio9";
+ function = "qup00";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
new file mode 100644
index 000000000000..7a156b9bfaf3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sa8775p-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SA8775P TLMM block
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm SA8775P SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sa8255p-tlmm
+ - const: qcom,sa8775p-tlmm
+ - items:
+ - const: qcom,sa8775p-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 74
+
+ gpio-line-names:
+ maxItems: 148
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sa8775p-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sa8775p-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sa8775p-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-3][0-9]|14[0-7])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, ufs_reset ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_usb2, audio_ref, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cci_timer5, cci_timer6, cci_timer7, cci_timer8, cci_timer9,
+ cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5, edp0_hot,
+ edp0_lcd, edp1_hot, edp1_lcd, edp2_hot, edp2_lcd, edp3_hot,
+ edp3_lcd, egpio, emac0_mcg0, emac0_mcg1, emac0_mcg2, emac0_mcg3,
+ emac0_mdc, emac0_mdio, emac0_ptp_aux, emac0_ptp_pps, emac1_mcg0,
+ emac1_mcg1, emac1_mcg2, emac1_mcg3, emac1_mdc, emac1_mdio,
+ emac1_ptp_aux, emac1_ptp_pps, gcc_gp1, gcc_gp2, gcc_gp3,
+ gcc_gp4, gcc_gp5, gpio, hs0_mi2s, hs1_mi2s, hs2_mi2s, ibi_i3c,
+ jitter_bist, mdp0_vsync0, mdp0_vsync1, mdp0_vsync2, mdp0_vsync3,
+ mdp0_vsync4, mdp0_vsync5, mdp0_vsync6, mdp0_vsync7, mdp0_vsync8,
+ mdp1_vsync0, mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4,
+ mdp1_vsync5, mdp1_vsync6, mdp1_vsync7, mdp1_vsync8, mdp_vsync,
+ mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws, mi2s2_data0,
+ mi2s2_data1, mi2s2_sck, mi2s2_ws, mi2s_mclk0, mi2s_mclk1,
+ pcie0_clkreq, pcie1_clkreq, phase_flag, pll_bist, pll_clk,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio, qup0_se0, qup0_se1, qup0_se2, qup0_se3, qup0_se4,
+ qup0_se5, qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4,
+ qup1_se5, qup1_se6, qup2_se0, qup2_se1, qup2_se2, qup2_se3,
+ qup2_se4, qup2_se5, qup2_se6, qup3_se0, sailss_emac0,
+ sailss_ospi, sail_top, sgmii_phy, tb_trig, tgu_ch0, tgu_ch1,
+ tgu_ch2, tgu_ch3, tgu_ch4, tgu_ch5, tsense_pwm1, tsense_pwm2,
+ tsense_pwm3, tsense_pwm4, usb2phy_ac, vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@f000000 {
+ compatible = "qcom,sa8775p-tlmm";
+ reg = <0xf000000 0x1000000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 148>;
+
+ qup-uart10-state {
+ pins = "gpio46", "gpio47";
+ function = "qup1_se3";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sar2130p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sar2130p-tlmm.yaml
new file mode 100644
index 000000000000..b388380b1ce0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sar2130p-tlmm.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sar2130p-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SAR2130P TLMM block
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SAR2130P SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sar2130p-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 78
+
+ gpio-line-names:
+ maxItems: 156
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sar2130p-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sar2130p-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sar2130p-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-5])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ aoss_cti, atest_char, atest_char0, atest_char1, atest_char2,
+ atest_char3, atest_usb0, atest_usb00, atest_usb01, atest_usb02,
+ atest_usb03, audio_ref, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, dp0_hot, ext_mclk0, ext_mclk1,
+ gcc_gp1, gcc_gp2, gcc_gp3, gpio, host2wlan_sol, i2s0_data0,
+ i2s0_data1, i2s0_sck, i2s0_ws, ibi_i3c, jitter_bist, mdp_vsync,
+ mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, pcie0_clkreqn,
+ pcie1_clkreqn, phase_flag0, phase_flag1, phase_flag10,
+ phase_flag11, phase_flag12, phase_flag13, phase_flag14,
+ phase_flag15, phase_flag16, phase_flag17, phase_flag18,
+ phase_flag19, phase_flag2, phase_flag20, phase_flag21,
+ phase_flag22, phase_flag23, phase_flag24, phase_flag25,
+ phase_flag26, phase_flag27, phase_flag28, phase_flag29,
+ phase_flag3, phase_flag30, phase_flag31, phase_flag4,
+ phase_flag5, phase_flag6, phase_flag7, phase_flag8,
+ phase_flag9, pll_bist, pll_clk, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio, qdss_gpio0,
+ qdss_gpio1, qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13,
+ qdss_gpio14, qdss_gpio15, qdss_gpio2, qdss_gpio3, qdss_gpio4,
+ qdss_gpio5, qdss_gpio6, qdss_gpio7, qdss_gpio8, qdss_gpio9,
+ qspi0, qspi1, qspi2, qspi3, qspi_clk, qspi_cs0, qspi_cs1, qup0,
+ qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup10,
+ qup11, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3,
+ tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3,
+ tsense_pwm1, tsense_pwm2, usb0_phy, vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@f100000 {
+ compatible = "qcom,sar2130p-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 156>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio26";
+ function = "qup7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio27";
+ function = "qup7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt
deleted file mode 100644
index 6ffeac9801df..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt
+++ /dev/null
@@ -1,187 +0,0 @@
-Qualcomm Technologies, Inc. SC7180 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-SC7180 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,sc7180-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the north, south and west
- TLMM tiles
-
-- reg-names:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: names for the cells of reg, must contain "north", "south"
- and "west".
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio118
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd,
- sdc2_data sdc1_rclk
- Supports bias and drive-strength
-
- ufs_reset
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- adsp_ext, agera_pll, aoss_cti, atest_char, atest_char0,
- atest_char1, atest_char2, atest_char3, atest_tsens,
- atest_tsens2, atest_usb1, atest_usb10, atest_usb11,
- atest_usb12, atest_usb13, atest_usb2, atest_usb20,
- atest_usb21, atest_usb22, atest_usb23, audio_ref,
- btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0,
- cci_timer1, cci_timer2, cci_timer3, cci_timer4,
- cri_trng, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
- ddr_pxi2, ddr_pxi3, dp_hot, edp_lcd, gcc_gp1, gcc_gp2,
- gcc_gp3, gpio, gp_pdm0, gp_pdm1, gp_pdm2, gps_tx,
- jitter_bist, ldo_en, ldo_update, lpass_ext, mdp_vsync,
- mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s_0,
- mi2s_1, mi2s_2, mss_lte, m_voc, pa_indicator, phase_flag,
- PLL_BIST, pll_bypassnl, pll_reset, prng_rosc, qdss,
- qdss_cti, qlink_enable, qlink_request, qspi_clk, qspi_cs,
- qspi_data, qup00, qup01, qup02_i2c, qup02_uart, qup03,
- qup04_i2c, qup04_uart, qup05, qup10, qup11_i2c, qup11_uart,
- qup12, qup13_i2c, qup13_uart, qup14, qup15, sdc1_tb,
- sdc2_tb, sd_write, sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2,
- tgu_ch3, tsense_pwm1, tsense_pwm2, uim1, uim2, uim_batt,
- usb_phy, vfr_1, _V_GPIO, _V_PPS_IN, _V_PPS_OUT,
- vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0,
- wlan2_adc1,
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@3500000 {
- compatible = "qcom,sc7180-pinctrl";
- reg = <0x3500000 0x300000>,
- <0x3900000 0x300000>,
- <0x3D00000 0x300000>;
- reg-names = "west", "north", "south";
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 119>;
- gpio-reserved-ranges = <0 4>, <106 4>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml
new file mode 100644
index 000000000000..ec0bf4fdfa4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sc7180-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7180 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SC7180 SoC.
+
+properties:
+ compatible:
+ const: qcom,sc7180-pinctrl
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: west
+ - const: north
+ - const: south
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 60
+
+ gpio-line-names:
+ maxItems: 119
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sc7180-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sc7180-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sc7180-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-8])$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
+ sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, aoss_cti, atest_char, atest_char0,
+ atest_char1, atest_char2, atest_char3, atest_tsens,
+ atest_tsens2, atest_usb1, atest_usb10, atest_usb11,
+ atest_usb12, atest_usb13, atest_usb2, atest_usb20, atest_usb21,
+ atest_usb22, atest_usb23, audio_ref, btfm_slimbus, cam_mclk,
+ cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2,
+ cci_timer3, cci_timer4, cri_trng, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, dp_hot, edp_lcd, gcc_gp1,
+ gcc_gp2, gcc_gp3, gpio, gp_pdm0, gp_pdm1, gp_pdm2, gps_tx,
+ jitter_bist, ldo_en, ldo_update, lpass_ext, mdp_vsync,
+ mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s_0, mi2s_1,
+ mi2s_2, mss_lte, m_voc, pa_indicator, phase_flag, PLL_BIST,
+ pll_bypassnl, pll_reset, prng_rosc, qdss, qdss_cti,
+ qlink_enable, qlink_request, qspi_clk, qspi_cs, qspi_data,
+ qup00, qup01, qup02_i2c, qup02_uart, qup03, qup04_i2c,
+ qup04_uart, qup05, qup10, qup11_i2c, qup11_uart, qup12,
+ qup13_i2c, qup13_uart, qup14, qup15, sdc1_tb, sdc2_tb,
+ sd_write, sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3,
+ tsense_pwm1, tsense_pwm2, uim1, uim2, uim_batt, usb_phy, vfr_1,
+ _V_GPIO, _V_PPS_IN, _V_PPS_OUT, vsense_trigger, wlan1_adc0,
+ wlan1_adc1, wlan2_adc0, wlan2_adc1 ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@3500000 {
+ compatible = "qcom,sc7180-pinctrl";
+ reg = <0x03500000 0x300000>,
+ <0x03900000 0x300000>,
+ <0x03d00000 0x300000>;
+ reg-names = "west", "north", "south";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 120>;
+ wakeup-parent = <&pdc>;
+
+ dp_hot_plug_det: dp-hot-plug-det-state {
+ pins = "gpio117";
+ function = "dp_hot";
+ };
+
+ qup_spi11_cs_gpio: qup-spi11-cs-gpio-state {
+ spi-pins {
+ pins = "gpio53", "gpio54", "gpio55";
+ function = "qup15";
+ };
+
+ cs-pins {
+ pins = "gpio56";
+ function = "gpio";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
index 624e14f00790..bc7b8dda8837 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml
@@ -4,47 +4,49 @@
$id: http://devicetree.org/schemas/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS)
- Low Power Island (LPI) TLMM block
+title: Qualcomm SC7280 SoC LPASS LPI TLMM
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- LPASS LPI IP on most Qualcomm SoCs
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SC7280 SoC.
properties:
compatible:
const: qcom,sc7280-lpass-lpi-pinctrl
- qcom,adsp-bypass-mode:
- description:
- Tells ADSP is in bypass mode.
- type: boolean
-
reg:
- minItems: 2
maxItems: 2
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
- gpio-ranges:
- maxItems: 1
+ clock-names:
+ items:
+ - const: core
+ - const: audio
-#PIN CONFIGURATION NODES
patternProperties:
- '-pins$':
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sc7280-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sc7280-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sc7280-lpass-state:
type: object
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -53,7 +55,7 @@ patternProperties:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9])$"
+ - pattern: "^gpio([0-9]|1[0-4])$"
minItems: 1
maxItems: 15
@@ -67,53 +69,45 @@ patternProperties:
Specify the alternative function to be configured for the specified
pins.
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- slew-rate:
- enum: [0, 1, 2, 3]
- default: 0
- description: |
- 0: No adjustments
- 1: Higher Slew rate (faster edges)
- 2: Lower Slew rate (slower edges)
- 3: Reserved (No adjustments)
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
required:
- compatible
- reg
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/sound/qcom,q6afe.h>
lpass_tlmm: pinctrl@33c0000 {
compatible = "qcom,sc7280-lpass-lpi-pinctrl";
reg = <0x33c0000 0x20000>,
<0x3550000 0x10000>;
+
+ clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&lpass_tlmm 0 0 15>;
+
+ dmic01-state {
+ dmic01-clk-pins {
+ pins = "gpio6";
+ function = "dmic1_clk";
+ };
+
+ dmic01-clk-sleep-pins {
+ pins = "gpio6";
+ function = "dmic1_clk";
+ };
+ };
+
+ tx-swr-data-sleep-state {
+ pins = "gpio1", "gpio2", "gpio14";
+ function = "swr_tx_data";
+ };
};
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml
index 2bd60c49a442..5329fe2a4397 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml
@@ -9,9 +9,8 @@ title: Qualcomm Technologies, Inc. SC7280 TLMM block
maintainers:
- Bjorn Andersson <andersson@kernel.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- SC7280 platform.
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SC7280 SoC.
properties:
compatible:
@@ -24,34 +23,30 @@ properties:
description: Specifies the TLMM summary IRQ
maxItems: 1
- interrupt-controller: true
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 88
- '#interrupt-cells':
- description:
- Specifies the PIN numbers and Flags, as defined in defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
+ gpio-line-names:
+ maxItems: 175
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- wakeup-parent: true
-
-#PIN CONFIGURATION NODES
patternProperties:
- '-pins$':
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sc7280-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sc7280-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sc7280-tlmm-state:
type: object
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -60,7 +55,7 @@ patternProperties:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-4])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-6][0-9]|17[0-4])$"
- enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
sdc2_cmd, sdc2_data, ufs_reset ]
minItems: 1
@@ -100,61 +95,36 @@ patternProperties:
uim1_clk, uim1_data, uim1_present, uim1_reset, usb2phy_ac,
usb_phy, vfr_0, vfr_1, vsense_trigger ]
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
required:
- pins
- - function
-
- additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@f000000 {
- compatible = "qcom,sc7280-pinctrl";
- reg = <0xf000000 0x1000000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 175>;
- wakeup-parent = <&pdc>;
-
- qup_uart5_default: qup-uart5-pins {
- pins = "gpio46", "gpio47";
- function = "qup13";
- drive-strength = <2>;
- bias-disable;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f000000 {
+ compatible = "qcom,sc7280-pinctrl";
+ reg = <0xf000000 0x1000000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 175>;
+ wakeup-parent = <&pdc>;
+
+ qup_uart5_default: qup-uart5-state {
+ pins = "gpio46", "gpio47";
+ function = "qup13";
+ drive-strength = <2>;
+ bias-disable;
};
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml
deleted file mode 100644
index 86509172603d..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml
+++ /dev/null
@@ -1,153 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sc8180x-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SC8180X TLMM block
-
-maintainers:
- - Bjorn Andersson <bjorn.andersson@linaro.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- SC8180X platform.
-
-allOf:
- - $ref: "pinctrl.yaml#"
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,sc8180x-tlmm
-
- reg:
- maxItems: 3
-
- reg-names:
- items:
- - const: "west"
- - const: "east"
- - const: "south"
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
- - reg-names
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sc8180x-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sc8180x-tlmm-state"
-
-'$defs':
- qcom-sc8180x-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-8][0-9])$"
- - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
- minItems: 1
- maxItems: 16
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ adsp_ext, agera_pll, aoss_cti, atest_char, atest_tsens,
- atest_tsens2, atest_usb0, atest_usb1, atest_usb2, atest_usb3,
- atest_usb4, audio_ref, btfm_slimbus, cam_mclk, cci_async,
- cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
- cci_timer4, cci_timer5, cci_timer6, cci_timer7, cci_timer8,
- cci_timer9, cri_trng, dbg_out, ddr_bist, ddr_pxi, debug_hot,
- dp_hot, edp_hot, edp_lcd, emac_phy, emac_pps, gcc_gp1, gcc_gp2,
- gcc_gp3, gcc_gp4, gcc_gp5, gpio, gps, grfc, hs1_mi2s, hs2_mi2s,
- hs3_mi2s, jitter_bist, lpass_slimbus, m_voc, mdp_vsync,
- mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mdp_vsync4,
- mdp_vsync5, mss_lte, nav_pps, pa_indicator, pci_e0, pci_e1,
- pci_e2, pci_e3, phase_flag, pll_bist, pll_bypassnl, pll_reset,
- pri_mi2s, pri_mi2s_ws, prng_rosc, qdss_cti, qdss_gpio, qlink,
- qspi0, qspi0_clk, qspi0_cs, qspi1, qspi1_clk, qspi1_cs,
- qua_mi2s, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8,
- qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17,
- qup18, qup19, qup_l4, qup_l5, qup_l6, rgmii, sd_write, sdc4,
- sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, spkr_i2s, ter_mi2s, tgu,
- tsense_pwm1, tsense_pwm2, tsif1, tsif2, uim1, uim2, uim_batt,
- usb0_phy, usb1_phy, usb2phy_ac, vfr_1, vsense_trigger,
- wlan1_adc, wlan2_adc, wmss_reset ]
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@3100000 {
- compatible = "qcom,sc8180x-tlmm";
- reg = <0x03100000 0x300000>,
- <0x03500000 0x700000>,
- <0x03d00000 0x300000>;
- reg-names = "west", "east", "south";
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 190>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio4";
- function = "qup6";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio5";
- function = "qup6";
- bias-disable;
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml
new file mode 100644
index 000000000000..c122bb849f0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sc8180x-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SC8180X TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SC8180X SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc8180x-tlmm
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: west
+ - const: east
+ - const: south
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sc8180x-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sc8180x-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sc8180x-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-8][0-9])$"
+ - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, aoss_cti, atest_char, atest_tsens,
+ atest_tsens2, atest_usb0, atest_usb1, atest_usb2, atest_usb3,
+ atest_usb4, audio_ref, btfm_slimbus, cam_mclk, cci_async,
+ cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+ cci_timer4, cci_timer5, cci_timer6, cci_timer7, cci_timer8,
+ cci_timer9, cri_trng, dbg_out, ddr_bist, ddr_pxi, debug_hot,
+ dp_hot, edp_hot, edp_lcd, emac_phy, emac_pps, gcc_gp1, gcc_gp2,
+ gcc_gp3, gcc_gp4, gcc_gp5, gpio, gps, grfc, hs1_mi2s, hs2_mi2s,
+ hs3_mi2s, jitter_bist, lpass_slimbus, m_voc, mdp_vsync,
+ mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mdp_vsync4,
+ mdp_vsync5, mss_lte, nav_pps, pa_indicator, pci_e0, pci_e1,
+ pci_e2, pci_e3, phase_flag, pll_bist, pll_bypassnl, pll_reset,
+ pri_mi2s, pri_mi2s_ws, prng_rosc, qdss_cti, qdss_gpio, qlink,
+ qspi0, qspi0_clk, qspi0_cs, qspi1, qspi1_clk, qspi1_cs,
+ qua_mi2s, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8,
+ qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17,
+ qup18, qup19, qup_l4, qup_l5, qup_l6, rgmii, sd_write, sdc4,
+ sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, spkr_i2s, ter_mi2s, tgu,
+ tsense_pwm1, tsense_pwm2, tsif1, tsif2, uim1, uim2, uim_batt,
+ usb0_phy, usb1_phy, usb2phy_ac, vfr_1, vsense_trigger,
+ wlan1_adc, wlan2_adc, wmss_reset ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@3100000 {
+ compatible = "qcom,sc8180x-tlmm";
+ reg = <0x03100000 0x300000>,
+ <0x03500000 0x700000>,
+ <0x03d00000 0x300000>;
+ reg-names = "west", "east", "south";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 190>;
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio4";
+ function = "qup6";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio5";
+ function = "qup6";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..240e6d45cc95
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP SoC LPASS LPI TLMM
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SC8280XP SoC.
+
+properties:
+ compatible:
+ const: qcom,sc8280xp-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sc8280xp-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sc8280xp-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sc8280xp-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-8])$"
+
+ function:
+ enum: [ swr_tx_clk, swr_tx_data, swr_rx_clk, swr_rx_data,
+ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic4_clk,
+ dmic4_data, i2s2_clk, i2s2_ws, dmic3_clk, dmic3_data,
+ qua_mi2s_sclk, qua_mi2s_ws, qua_mi2s_data, i2s1_clk, i2s1_ws,
+ i2s1_data, wsa_swr_clk, wsa_swr_data, wsa2_swr_clk,
+ wsa2_swr_data, i2s2_data, i2s3_clk, i2s3_ws, i2s3_data,
+ ext_mclk1_c, ext_mclk1_b, ext_mclk1_a ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ pinctrl@33c0000 {
+ compatible = "qcom,sc8280xp-lpass-lpi-pinctrl";
+ reg = <0x33c0000 0x20000>,
+ <0x3550000 0x10000>;
+ clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 19>;
+
+ dmic01-state {
+ dmic01-clk-pins {
+ pins = "gpio16";
+ function = "dmic1_clk";
+ };
+
+ dmic01-clk-sleep-pins {
+ pins = "gpio16";
+ function = "dmic1_clk";
+ };
+ };
+
+ tx-swr-data-sleep-state {
+ pins = "gpio0", "gpio1";
+ function = "swr_tx_data";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml
deleted file mode 100644
index 87a381c9a19d..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml
+++ /dev/null
@@ -1,151 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sc8280xp-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SC8280XP TLMM block
-
-maintainers:
- - Bjorn Andersson <bjorn.andersson@linaro.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- SC8280XP platform.
-
-allOf:
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,sc8280xp-tlmm
-
- reg:
- maxItems: 1
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sc8280xp-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sc8280xp-tlmm-state"
-
-'$defs':
- qcom-sc8280xp-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-1][0-9]|22[0-7])$"
- - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset, ufs1_reset ]
- minItems: 1
- maxItems: 16
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async, cci_i2c,
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
- cci_timer5, cci_timer6, cci_timer7, cci_timer8, cci_timer9,
- cmu_rng, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist,
- ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5,
- ddr_pxi6, ddr_pxi7, dp2_hot, dp3_hot, edp0_lcd, edp1_lcd,
- edp2_lcd, edp3_lcd, edp_hot, emac0_dll, emac0_mcg0, emac0_mcg1,
- emac0_mcg2, emac0_mcg3, emac0_phy, emac0_ptp, emac1_dll0,
- emac1_dll1, emac1_mcg0, emac1_mcg1, emac1_mcg2, emac1_mcg3,
- emac1_phy, emac1_ptp, gcc_gp1, gcc_gp2, gcc_gp3, gcc_gp4,
- gcc_gp5, gpio, hs1_mi2s, hs2_mi2s, hs3_mi2s, ibi_i3c,
- jitter_bist, lpass_slimbus, mdp0_vsync0, mdp0_vsync1,
- mdp0_vsync2, mdp0_vsync3, mdp0_vsync4, mdp0_vsync5,
- mdp0_vsync6, mdp0_vsync7, mdp0_vsync8, mdp1_vsync0,
- mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4,
- mdp1_vsync5, mdp1_vsync6, mdp1_vsync7, mdp1_vsync8, mdp_vsync,
- mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws, mi2s1_data0,
- mi2s1_data1, mi2s1_sck, mi2s1_ws, mi2s2_data0, mi2s2_data1,
- mi2s2_sck, mi2s2_ws, mi2s_mclk1, mi2s_mclk2, pcie2a_clkreq,
- pcie2b_clkreq, pcie3a_clkreq, pcie3b_clkreq, pcie4_clkreq,
- phase_flag, pll_bist, pll_clk, prng_rosc0, prng_rosc1,
- prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio, qspi, qspi_clk,
- qspi_cs, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8,
- qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17,
- qup18, qup19, qup20, qup21, qup22, qup23, rgmii_0, rgmii_1,
- sd_write, sdc40, sdc42, sdc43, sdc4_clk, sdc4_cmd, tb_trig,
- tgu, tsense_pwm1, tsense_pwm2, tsense_pwm3, tsense_pwm4,
- usb0_dp, usb0_phy, usb0_sbrx, usb0_sbtx, usb0_usb4, usb1_dp,
- usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac,
- vsense_trigger ]
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@f100000 {
- compatible = "qcom,sc8280xp-tlmm";
- reg = <0x0f100000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 230>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio4";
- function = "qup14";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio5";
- function = "qup14";
- bias-disable;
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
new file mode 100644
index 000000000000..ed344deaf8b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sc8280xp-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SC8280XP TLMM block
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ Top Level Mode Multiplexer pin controller in Qualcomm SC8280XP SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sc8280xp-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sc8280xp-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sc8280xp-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sc8280xp-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-1][0-9]|22[0-7])$"
+ - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset, ufs1_reset ]
+ minItems: 1
+ maxItems: 16
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cci_timer5, cci_timer6, cci_timer7, cci_timer8, cci_timer9,
+ cmu_rng, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist,
+ ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5,
+ ddr_pxi6, ddr_pxi7, dp2_hot, dp3_hot, edp0_lcd, edp1_lcd,
+ edp2_lcd, edp3_lcd, edp_hot, emac0_dll, emac0_mcg0, emac0_mcg1,
+ emac0_mcg2, emac0_mcg3, emac0_phy, emac0_ptp, emac1_dll0,
+ emac1_dll1, emac1_mcg0, emac1_mcg1, emac1_mcg2, emac1_mcg3,
+ emac1_phy, emac1_ptp, gcc_gp1, gcc_gp2, gcc_gp3, gcc_gp4,
+ gcc_gp5, gpio, hs1_mi2s, hs2_mi2s, hs3_mi2s, ibi_i3c,
+ jitter_bist, lpass_slimbus, mdp0_vsync0, mdp0_vsync1,
+ mdp0_vsync2, mdp0_vsync3, mdp0_vsync4, mdp0_vsync5,
+ mdp0_vsync6, mdp0_vsync7, mdp0_vsync8, mdp1_vsync0,
+ mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4,
+ mdp1_vsync5, mdp1_vsync6, mdp1_vsync7, mdp1_vsync8, mdp_vsync,
+ mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws, mi2s1_data0,
+ mi2s1_data1, mi2s1_sck, mi2s1_ws, mi2s2_data0, mi2s2_data1,
+ mi2s2_sck, mi2s2_ws, mi2s_mclk1, mi2s_mclk2, pcie2a_clkreq,
+ pcie2b_clkreq, pcie3a_clkreq, pcie3b_clkreq, pcie4_clkreq,
+ phase_flag, pll_bist, pll_clk, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio, qspi, qspi_clk,
+ qspi_cs, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8,
+ qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17,
+ qup18, qup19, qup20, qup21, qup22, qup23, rgmii_0, rgmii_1,
+ sd_write, sdc40, sdc42, sdc43, sdc4_clk, sdc4_cmd, tb_trig,
+ tgu, tsense_pwm1, tsense_pwm2, tsense_pwm3, tsense_pwm4,
+ usb0_dp, usb0_phy, usb0_sbrx, usb0_sbtx, usb0_usb4, usb1_dp,
+ usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac,
+ vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@f100000 {
+ compatible = "qcom,sc8280xp-tlmm";
+ reg = <0x0f100000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 230>;
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio4";
+ function = "qup14";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio5";
+ function = "qup14";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml
new file mode 100644
index 000000000000..80627a1ad663
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm630-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM630 and SDM660 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SDM630 and SDM660 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdm630-pinctrl
+ - qcom,sdm660-pinctrl
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: south
+ - const: center
+ - const: north
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 57
+
+ gpio-line-names:
+ maxItems: 114
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm630-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm630-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdm630-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-3])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk,
+ sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1,
+ atest_char2, atest_char3, atest_gpsadc0, atest_gpsadc1,
+ atest_tsens, atest_tsens2, atest_usb1, atest_usb10,
+ atest_usb11, atest_usb12, atest_usb13, atest_usb2, atest_usb20,
+ atest_usb21, atest_usb22, atest_usb23, audio_ref, bimc_dte0,
+ bimc_dte1, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4,
+ blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8_a, blsp_i2c8_b,
+ blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi3_cs1, blsp_spi3_cs2,
+ blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7, blsp_spi8_a,
+ blsp_spi8_b, blsp_spi8_cs1, blsp_spi8_cs2, blsp_uart1,
+ blsp_uart2, blsp_uart5, blsp_uart6_a, blsp_uart6_b, blsp_uim1,
+ blsp_uim2, blsp_uim5, blsp_uim6, cam_mclk, cci_async, cci_i2c,
+ cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, gcc_gp1,
+ gcc_gp2, gcc_gp3, gpio, gps_tx_a, gps_tx_b, gps_tx_c,
+ isense_dbg, jitter_bist, ldo_en, ldo_update, m_voc, mdp_vsync,
+ mdss_vsync0, mdss_vsync1, mdss_vsync2, mdss_vsync3, mss_lte,
+ nav_pps_a, nav_pps_b, nav_pps_c, pa_indicator, phase_flag0,
+ phase_flag1, phase_flag10, phase_flag11, phase_flag12,
+ phase_flag13, phase_flag14, phase_flag15, phase_flag16,
+ phase_flag17, phase_flag18, phase_flag19, phase_flag2,
+ phase_flag20, phase_flag21, phase_flag22, phase_flag23,
+ phase_flag24, phase_flag25, phase_flag26, phase_flag27,
+ phase_flag28, phase_flag29, phase_flag3, phase_flag30,
+ phase_flag31, phase_flag4, phase_flag5, phase_flag6,
+ phase_flag7, phase_flag8, phase_flag9, pll_bypassnl, pll_reset,
+ pri_mi2s, pri_mi2s_ws, prng_rosc, pwr_crypto, pwr_modem,
+ pwr_nav, qdss_cti0_a, qdss_cti0_b, qdss_cti1_a, qdss_cti1_b,
+ qdss_gpio, qdss_gpio0, qdss_gpio1, qdss_gpio10, qdss_gpio11,
+ qdss_gpio12, qdss_gpio13, qdss_gpio14, qdss_gpio15, qdss_gpio2,
+ qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6, qdss_gpio7,
+ qdss_gpio8, qdss_gpio9, qlink_enable, qlink_request, qspi_clk,
+ qspi_cs, qspi_data0, qspi_data1, qspi_data2, qspi_data3,
+ qspi_resetn, sec_mi2s, sndwire_clk, sndwire_data, sp_cmu,
+ ssc_irq, tgu_ch0, tgu_ch1, tsense_pwm1, tsense_pwm2, uim1_clk,
+ uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
+ uim2_present, uim2_reset, uim_batt, vfr_1, vsense_clkout,
+ vsense_data0, vsense_data1, vsense_mode, wlan1_adc0,
+ wlan1_adc1, wlan2_adc0, wlan2_adc1 ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@3100000 {
+ compatible = "qcom,sdm630-pinctrl";
+ reg = <0x03100000 0x400000>,
+ <0x03500000 0x400000>,
+ <0x03900000 0x400000>;
+ reg-names = "south", "center", "north";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 114>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ blsp1-uart1-default-state {
+ pins = "gpio0", "gpio1", "gpio2", "gpio3";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ blsp2_uart1_default: blsp2-uart1-active-state {
+ tx-rts-pins {
+ pins = "gpio16", "gpio19";
+ function = "blsp_uart5";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ rx-pins {
+ pins = "gpio17";
+ function = "blsp_uart5";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ cts-pins {
+ pins = "gpio18";
+ function = "blsp_uart5";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..409e5a4d4da9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm660-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM660 SoC LPASS LPI TLMM
+
+maintainers:
+ - Nickolay Goppen <setotau@mainlining.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SDM660 SoC.
+
+properties:
+ compatible:
+ const: qcom,sdm660-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm660-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm660-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdm660-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|[1-2][0-9]|3[0-1])$"
+
+ function:
+ enum: [ gpio, comp_rx, dmic1_clk, dmic1_data, dmic2_clk, dmic2_data,
+ mclk0, pdm_tx, pdm_clk, pdm_rx, pdm_sync ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ lpi_tlmm: pinctrl@15070000 {
+ compatible = "qcom,sdm660-lpass-lpi-pinctrl";
+ reg = <0x15070000 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_pdm_default: cdc-pdm-default-state {
+ clk-pins {
+ pins = "gpio18";
+ function = "pdm_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ sync-pins{
+ pins = "gpio19";
+ function = "pdm_sync";
+ drive-strength = <4>;
+ output-high;
+ };
+
+ tx-pins {
+ pins = "gpio20";
+ function = "pdm_tx";
+ drive-strength = <8>;
+ };
+
+ rx-pins {
+ pins = "gpio21", "gpio23", "gpio25";
+ function = "pdm_rx";
+ drive-strength = <4>;
+ output-high;
+ };
+ };
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt
deleted file mode 100644
index be034d329e10..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt
+++ /dev/null
@@ -1,191 +0,0 @@
-Qualcomm Technologies, Inc. SDM660 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-SDM660 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,sdm660-pinctrl" or
- "qcom,sdm630-pinctrl".
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the north, center and south
- TLMM tiles.
-
-- reg-names:
- Usage: required
- Value type: <stringlist>
- Definition: names for the cells of reg, must contain "north", "center"
- and "south".
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- gpio-ranges:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Specifies the mapping between gpio controller and
- pin-controller pins.
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode. Valid pins are:
- gpio0-gpio113,
- Supports mux, bias and drive-strength
- sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data sdc1_rclk,
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
- adsp_ext, agera_pll, atest_char, atest_char0, atest_char1,
- atest_char2, atest_char3, atest_gpsadc0, atest_gpsadc1,
- atest_tsens, atest_tsens2, atest_usb1, atest_usb10,
- atest_usb11, atest_usb12, atest_usb13, atest_usb2,
- atest_usb20, atest_usb21, atest_usb22, atest_usb23,
- audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1, blsp_i2c2,
- blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7,
- blsp_i2c8_a, blsp_i2c8_b, blsp_spi1, blsp_spi2, blsp_spi3,
- blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi4, blsp_spi5,
- blsp_spi6, blsp_spi7, blsp_spi8_a, blsp_spi8_b,
- blsp_spi8_cs1, blsp_spi8_cs2, blsp_uart1, blsp_uart2,
- blsp_uart5, blsp_uart6_a, blsp_uart6_b, blsp_uim1,
- blsp_uim2, blsp_uim5, blsp_uim6, cam_mclk, cci_async,
- cci_i2c, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist,
- gcc_gp1, gcc_gp2, gcc_gp3, gpio, gps_tx_a, gps_tx_b, gps_tx_c,
- isense_dbg, jitter_bist, ldo_en, ldo_update, m_voc, mdp_vsync,
- mdss_vsync0, mdss_vsync1, mdss_vsync2, mdss_vsync3, mss_lte,
- nav_pps_a, nav_pps_b, nav_pps_c, pa_indicator, phase_flag0,
- phase_flag1, phase_flag10, phase_flag11, phase_flag12,
- phase_flag13, phase_flag14, phase_flag15, phase_flag16,
- phase_flag17, phase_flag18, phase_flag19, phase_flag2,
- phase_flag20, phase_flag21, phase_flag22, phase_flag23,
- phase_flag24, phase_flag25, phase_flag26, phase_flag27,
- phase_flag28, phase_flag29, phase_flag3, phase_flag30,
- phase_flag31, phase_flag4, phase_flag5, phase_flag6,
- phase_flag7, phase_flag8, phase_flag9, pll_bypassnl,
- pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc, pwr_crypto,
- pwr_modem, pwr_nav, qdss_cti0_a, qdss_cti0_b, qdss_cti1_a,
- qdss_cti1_b, qdss_gpio, qdss_gpio0, qdss_gpio1, qdss_gpio10,
- qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14, qdss_gpio15,
- qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6,
- qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink_enable, qlink_request,
- qspi_clk, qspi_cs, qspi_data0, qspi_data1, qspi_data2,
- qspi_data3, qspi_resetn, sec_mi2s, sndwire_clk, sndwire_data,
- sp_cmu, ssc_irq, tgu_ch0, tgu_ch1, tsense_pwm1, tsense_pwm2,
- uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
- uim2_data, uim2_present, uim2_reset, uim_batt, vfr_1,
- vsense_clkout, vsense_data0, vsense_data1, vsense_mode,
- wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@3100000 {
- compatible = "qcom,sdm660-pinctrl";
- reg = <0x3100000 0x200000>,
- <0x3500000 0x200000>,
- <0x3900000 0x200000>;
- reg-names = "south", "center", "north";
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- gpio-ranges = <&tlmm 0 0 114>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml
new file mode 100644
index 000000000000..b56e717aa28e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm670-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SDM670 TLMM block
+
+maintainers:
+ - Richard Acayan <mailingradian@gmail.com>
+
+description: |
+ The Top Level Mode Multiplexer (TLMM) block found in the SDM670 platform.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sdm670-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 75
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm670-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm670-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdm670-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9])$"
+ - enum: [ ufs_reset, sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data,
+ sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, atest_char, atest_tsens, atest_tsens2, atest_usb1, atest_usb10,
+ atest_usb11, atest_usb12, atest_usb13, atest_usb2, atest_usb20, atest_usb21,
+ atest_usb22, atest_usb23, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1,
+ cci_timer2, cci_timer3, cci_timer4, copy_gp, copy_phase, dbg_out, ddr_bist,
+ ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
+ gp_pdm0, gp_pdm1, gp_pdm2, gpio, gps_tx, jitter_bist, ldo_en, ldo_update,
+ lpass_slimbus, m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3,
+ mss_lte, nav_pps, pa_indicator, pci_e0, pci_e1, phase_flag, pll_bist, pll_bypassnl,
+ pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc, qdss_cti, qdss, qlink_enable,
+ qlink_request, qua_mi2s, qup0, qup1, qup10, qup11, qup12, qup13, qup14, qup15, qup2,
+ qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5, qup_l6, sdc4_clk,
+ sdc4_cmd, sdc4_data, sd_write, sec_mi2s, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2,
+ tgu_ch3, tsif1_clk, tsif1_data, tsif1_en, tsif1_error, tsif1_sync, tsif2_clk,
+ tsif2_data, tsif2_en, tsif2_error, tsif2_sync, uim1_clk, uim1_data, uim1_present,
+ uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, uim_batt, usb_phy, vfr_1,
+ vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data, ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@3400000 {
+ compatible = "qcom,sdm670-tlmm";
+ reg = <0x03400000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 151>;
+
+ qup-i2c9-state {
+ pins = "gpio6", "gpio7";
+ function = "qup9";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
deleted file mode 100644
index 7462e3743c68..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.txt
+++ /dev/null
@@ -1,176 +0,0 @@
-Qualcomm SDM845 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-SDM845 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,sdm845-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the TLMM register space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio149
- Supports mux, bias and drive-strength
-
- sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- gpio, adsp_ext, agera_pll, atest_char, atest_tsens,
- atest_tsens2, atest_usb1, atest_usb10, atest_usb11,
- atest_usb12, atest_usb13, atest_usb2, atest_usb20,
- atest_usb21, atest_usb22, atest_usb23, audio_ref,
- btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0,
- cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
- ddr_pxi1, ddr_pxi2, ddr_pxi3, edp_hot, edp_lcd, gcc_gp1,
- gcc_gp2, gcc_gp3, jitter_bist, ldo_en, ldo_update,
- lpass_slimbus, m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1,
- mdp_vsync2, mdp_vsync3, mss_lte, nav_pps, pa_indicator,
- pci_e0, pci_e1, phase_flag, pll_bist, pll_bypassnl,
- pll_reset, pri_mi2s, pri_mi2s_ws, prng_rosc, qdss_cti,
- qdss, qlink_enable, qlink_request, qua_mi2s, qup0, qup1,
- qup10, qup11, qup12, qup13, qup14, qup15, qup2, qup3, qup4,
- qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5, qup_l6,
- qspi_clk, qspi_cs, qspi_data, sd_write, sdc4_clk, sdc4_cmd,
- sdc4_data, sec_mi2s, sp_cmu, spkr_i2s, ter_mi2s, tgu_ch0,
- tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1, tsense_pwm2,
- tsif1_clk, tsif1_data, tsif1_en, tsif1_error, tsif1_sync,
- tsif2_clk, tsif2_data, tsif2_en, tsif2_error, tsif2_sync,
- uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk,
- uim2_data, uim2_present, uim2_reset, uim_batt, usb_phy,
- vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0,
- wlan2_adc1,
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configured as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@3400000 {
- compatible = "qcom,sdm845-pinctrl";
- reg = <0x03400000 0xc00000>;
- interrupts = <GIC_SPI 208 0>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-
- qup9_active: qup9-active {
- mux {
- pins = "gpio4", "gpio5";
- function = "qup9";
- };
-
- config {
- pins = "gpio4", "gpio5";
- drive-strength = <2>;
- bias-disable;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml
new file mode 100644
index 000000000000..4fcac2e55b55
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm845-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM845 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SDM845 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sdm845-pinctrl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 75
+
+ gpio-line-names:
+ maxItems: 150
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm845-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm845-tlmm-state"
+ additionalProperties: false
+
+ "-hog(-[0-9]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+$defs:
+ qcom-sdm845-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ adsp_ext, agera_pll, atest_char, atest_tsens, atest_tsens2,
+ atest_usb1, atest_usb10, atest_usb11, atest_usb12, atest_usb13,
+ atest_usb2, atest_usb20, atest_usb21, atest_usb22, atest_usb23,
+ audio_ref, btfm_slimbus, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, edp_hot, edp_lcd, gcc_gp1,
+ gcc_gp2, gcc_gp3, gpio, jitter_bist, ldo_en, ldo_update,
+ lpass_slimbus, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2,
+ mdp_vsync3, mss_lte, m_voc, nav_pps, pa_indicator, pci_e0,
+ pci_e1, phase_flag, pll_bist, pll_bypassnl, pll_reset,
+ pri_mi2s, pri_mi2s_ws, prng_rosc, qdss, qdss_cti, qlink_enable,
+ qlink_request, qspi_clk, qspi_cs, qspi_data, qua_mi2s, qup0,
+ qup1, qup10, qup11, qup12, qup13, qup14, qup15, qup2, qup3,
+ qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5, qup_l6,
+ sdc4_clk, sdc4_cmd, sdc4_data, sd_write, sec_mi2s, sp_cmu,
+ spkr_i2s, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3,
+ tsense_pwm1, tsense_pwm2, tsif1_clk, tsif1_data, tsif1_en,
+ tsif1_error, tsif1_sync, tsif2_clk, tsif2_data, tsif2_en,
+ tsif2_error, tsif2_sync, uim1_clk, uim1_data, uim1_present,
+ uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset,
+ uim_batt, usb_phy, vfr_1, vsense_trigger, wlan1_adc0,
+ wlan1_adc1, wlan2_adc0, wlan2_adc1]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pinctrl@3400000 {
+ compatible = "qcom,sdm845-pinctrl";
+ reg = <0x03400000 0xc00000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 151>;
+ wakeup-parent = <&pdc_intc>;
+
+ ap-suspend-l-hog {
+ gpio-hog;
+ gpios = <126 GPIO_ACTIVE_LOW>;
+ output-low;
+ };
+
+ cci0-default-state {
+ pins = "gpio17", "gpio18";
+ function = "cci_i2c";
+
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+
+ cam0-default-state {
+ rst-pins {
+ pins = "gpio9";
+ function = "gpio";
+
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ mclk0-pins {
+ pins = "gpio13";
+ function = "cam_mclk";
+
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
index a38090b14aab..edbcff92bbf9 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml
@@ -9,9 +9,8 @@ title: Qualcomm Technologies, Inc. SDX55 TLMM block
maintainers:
- Vinod Koul <vkoul@kernel.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- SDX55 platform.
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SDX55 SoC.
properties:
compatible:
@@ -22,37 +21,28 @@ properties:
maxItems: 1
interrupts:
- description: Specifies the TLMM summary IRQ
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- description: Specifies the PIN numbers and Flags, as defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
maxItems: 1
gpio-reserved-ranges:
maxItems: 1
-#PIN CONFIGURATION NODES
patternProperties:
- '-pins$':
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdx55-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdx55-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdx55-tlmm-state:
type: object
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -60,7 +50,7 @@ patternProperties:
List of gpio pins affected by the properties specified in this subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-7])$"
- enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
minItems: 1
maxItems: 36
@@ -96,62 +86,37 @@ patternProperties:
uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present,
uim2_reset, usb2phy_ac, vsense_trigger ]
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
required:
- pins
- - function
-
- additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
required:
- compatible
- reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@1f00000 {
- compatible = "qcom,sdx55-pinctrl";
- reg = <0x0f100000 0x300000>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 108>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
-
- serial-pins {
- pins = "gpio8", "gpio9";
- function = "blsp_uart3";
- drive-strength = <8>;
- bias-disable;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@1f00000 {
+ compatible = "qcom,sdx55-pinctrl";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 108>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+
+ serial-state {
+ pins = "gpio8", "gpio9";
+ function = "blsp_uart3";
+ drive-strength = <8>;
+ bias-disable;
};
+ };
...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml
deleted file mode 100644
index cdfcf29dffee..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml
+++ /dev/null
@@ -1,191 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sdx65-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SDX65 TLMM block
-
-maintainers:
- - Vamsi krishna Lanka <quic_vamslank@quicinc.com>
-
-description:
- This binding describes the Top Level Mode Multiplexer block found in the
- SDX65 platform.
-
-properties:
- compatible:
- const: qcom,sdx65-tlmm
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- description: Specifies the PIN numbers and Flags, as defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- gpio-reserved-ranges:
- maxItems: 1
-
-#PIN CONFIGURATION NODES
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sdx65-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sdx65-tlmm-state"
-'$defs':
- qcom-sdx65-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-7])$"
- - enum: [ ufs_reset, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data, sdc1_rclk ]
- minItems: 1
- maxItems: 150
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins. Functions are only valid for gpio pins.
- enum: [ blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens,
- bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8,
- qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b,
- dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10,
- blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12,
- mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11,
- atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char,
- cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b,
- pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c,
- qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4,
- qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5,
- atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6,
- atest_usb20, atest_char0, dac_calib10, qdss_stm10,
- qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6,
- blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11,
- qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1,
- qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11,
- dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6,
- qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14,
- dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem,
- dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto,
- dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0,
- dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25,
- sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2,
- qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3,
- uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9,
- blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7,
- qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11,
- blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0,
- cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4,
- blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4,
- qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus,
- isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s,
- qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b,
- sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b,
- gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12,
- qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29,
- tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27,
- qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk,
- sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b,
- sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b,
- ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b,
- blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt,
- pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11,
- qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx,
- qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3,
- gpio ]
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-required:
- - compatible
- - reg
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@f100000 {
- compatible = "qcom,sdx65-tlmm";
- reg = <0x03000000 0xdc2000>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 109>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio4";
- function = "blsp_uart1";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio5";
- function = "blsp_uart1";
- bias-disable;
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
new file mode 100644
index 000000000000..a31b638c456d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdx65-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SDX65 TLMM block
+
+maintainers:
+ - Vamsi krishna Lanka <quic_vamslank@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SDX65 SoC.
+
+properties:
+ compatible:
+ const: qcom,sdx65-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ maxItems: 1
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdx65-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdx65-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdx65-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-7])$"
+ - enum: [ ufs_reset, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data, sdc1_rclk ]
+ minItems: 1
+ maxItems: 150
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins. Functions are only valid for gpio pins.
+ enum: [ blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens,
+ bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8,
+ qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b,
+ dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10,
+ blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12,
+ mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11,
+ atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char,
+ cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b,
+ pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c,
+ qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4,
+ qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5,
+ atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6,
+ atest_usb20, atest_char0, dac_calib10, qdss_stm10,
+ qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6,
+ blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11,
+ qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1,
+ qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11,
+ dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6,
+ qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14,
+ dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem,
+ dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto,
+ dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, pcie_clkreq,
+ dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25,
+ sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2,
+ qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3,
+ uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9,
+ blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7,
+ qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11,
+ blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0,
+ cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4,
+ blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4,
+ qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus,
+ isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s,
+ qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b,
+ sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b,
+ gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12,
+ qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29,
+ tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27,
+ qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk,
+ sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b,
+ sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b,
+ ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b,
+ blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt,
+ pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11,
+ qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx,
+ qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3,
+ gpio ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sdx65-tlmm";
+ reg = <0x03000000 0xdc2000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 109>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio4";
+ function = "blsp_uart1";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio5";
+ function = "blsp_uart1";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml
new file mode 100644
index 000000000000..cb1d978d02c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx75-tlmm.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdx75-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SDX75 TLMM block
+
+maintainers:
+ - Rohit Agarwal <quic_rohiagar@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SDX75 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sdx75-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 67
+
+ gpio-line-names:
+ maxItems: 133
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdx75-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdx75-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdx75-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ adsp_ext, atest_char, audio_ref_clk, bimc_dte, char_exec, coex_uart2,
+ coex_uart, cri_trng, cri_trng0, cri_trng1, dbg_out_clk, ddr_bist,
+ ddr_pxi0, ebi0_wrcdc, ebi2_a, ebi2_lcd, ebi2_lcd_te, emac0_mcg,
+ emac0_ptp, emac1_mcg, emac1_ptp, emac_cdc, emac_pps_in, eth0_mdc,
+ eth0_mdio, eth1_mdc, eth1_mdio, ext_dbg, gcc_125_clk, gcc_gp1_clk,
+ gcc_gp2_clk, gcc_gp3_clk, gcc_plltest, gpio, i2s_mclk, jitter_bist,
+ ldo_en, ldo_update, m_voc, mgpi_clk, native_char, native_tsens,
+ native_tsense, nav_dr_sync, nav_gpio, pa_indicator, pci_e,
+ pcie0_clkreq_n, pcie1_clkreq_n, pcie2_clkreq_n, pll_bist_sync,
+ pll_clk_aux, pll_ref_clk, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio,
+ qlink0_b_en, qlink0_b_req, qlink0_l_en, qlink0_l_req, qlink0_wmss,
+ qlink1_l_en, qlink1_l_req, qlink1_wmss, qup_se0, qup_se1_l2_mira,
+ qup_se1_l2_mirb, qup_se1_l3_mira, qup_se1_l3_mirb, qup_se2, qup_se3,
+ qup_se4, qup_se5, qup_se6, qup_se7, qup_se8, rgmii_rx_ctl, rgmii_rxc,
+ rgmii_rxd, rgmii_tx_ctl, rgmii_txc, rgmii_txd, sd_card, sdc1_tb,
+ sdc2_tb_trig, sec_mi2s, sgmii_phy_intr0_n, sgmii_phy_intr1_n,
+ spmi_coex, spmi_vgi, tgu_ch0_trigout, tmess_prng0, tmess_prng1,
+ tmess_prng2, tmess_prng3, tri_mi2s, uim1_clk, uim1_data, uim1_present,
+ uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset,
+ usb2phy_ac_en, vsense_trigger_mirnat]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sdx75-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 133>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio12";
+ function = "qup_se1_l2_mira";
+ bias-disable;
+ };
+
+ tx-pins {
+ pins = "gpio13";
+ function = "qup_se1_l3_mira";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm4250-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm4250-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..9612e21183fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm4250-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm4250-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM4250 SoC LPASS LPI TLMM
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM4250 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm4250-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm4250-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm4250-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm4250-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-6])$"
+
+ function:
+ enum: [ gpio, dmic01_clk, dmic01_data, dmic23_clk, dmic23_data,
+ dmic4_clk, dmic4_data, ext_mclk0_a, ext_mclk0_b, ext_mclk1_a,
+ ext_mclk1_b, ext_mclk1_c, i2s1_clk, i2s1_data, i2s1_ws,
+ i2s2_clk, i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws,
+ qua_mi2s_data, qua_mi2s_sclk, qua_mi2s_ws, slim_clk, slim_data,
+ swr_rx_clk, swr_rx_data, swr_tx_clk, swr_tx_data, swr_wsa_clk,
+ swr_wsa_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ lpi_tlmm: pinctrl@a7c0000 {
+ compatible = "qcom,sm4250-lpass-lpi-pinctrl";
+ reg = <0xa7c0000 0x20000>,
+ <0xa950000 0x10000>;
+ clocks = <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "audio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 19>;
+
+ i2s2-active-state {
+ clk-pins {
+ pins = "gpio10";
+ function = "i2s2_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio12";
+ function = "i2s2_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ };
+ };
+
+ i2s2-sleep-clk-state {
+ pins = "gpio10";
+ function = "i2s2_clk";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
new file mode 100644
index 000000000000..1b941b276b3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm4450-tlmm.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm4450-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM4450 TLMM block
+
+maintainers:
+ - Tengfei Fan <quic_tengfan@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM4450 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm4450-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts: true
+ interrupt-controller: true
+ "#interrupt-cells": true
+ gpio-controller: true
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 68
+
+ gpio-line-names:
+ maxItems: 136
+
+ "#gpio-cells": true
+ gpio-ranges: true
+ wakeup-parent: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm4450-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm4450-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm4450-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-5])$"
+ - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, atest_char, atest_usb0, audio_ref_clk, cam_mclk,
+ cci_async_in0, cci_i2c, cci, cmu_rng, coex_uart1_rx,
+ coex_uart1_tx, cri_trng, dbg_out_clk, ddr_bist,
+ ddr_pxi0_test, ddr_pxi1_test, gcc_gp1_clk, gcc_gp2_clk,
+ gcc_gp3_clk, host2wlan_sol, ibi_i3c_qup0, ibi_i3c_qup1,
+ jitter_bist_ref, mdp_vsync0_out, mdp_vsync1_out,
+ mdp_vsync2_out, mdp_vsync3_out, mdp_vsync, nav,
+ pcie0_clk_req, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc, qdss_cti_trig0, qdss_cti_trig1, qdss_gpio,
+ qlink0_enable, qlink0_request, qlink0_wmss_reset,
+ qup0_se0, qup0_se1, qup0_se2, qup0_se3, qup0_se4,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se2_l2, qup1_se3,
+ qup1_se4, sd_write_protect, tb_trig_sdc1, tb_trig_sdc2,
+ tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout,
+ tgu_ch3_trigout, tmess_prng, tsense_pwm1_out,
+ tsense_pwm2_out, uim0, uim1, usb0_hs_ac, usb0_phy_ps,
+ vfr_0_mira, vfr_0_mirb, vfr_1, vsense_trigger_mirnat,
+ wlan1_adc_dtest0, wlan1_adc_dtest1 ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sm4450-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 137>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio23";
+ function = "qup1_se2";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio22";
+ function = "qup1_se2";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..d2a036ead846
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6115 SoC LPASS LPI TLMM
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM6115 SoC.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,sm6115-lpass-lpi-pinctrl
+ - items:
+ - enum:
+ - qcom,qcm2290-lpass-lpi-pinctrl
+ - const: qcom,sm6115-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm6115-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm6115-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm6115-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-8])$"
+
+ function:
+ enum: [ dmic01_clk, dmic01_data, dmic23_clk, dmic23_data, gpio, i2s1_clk,
+ i2s1_data, i2s1_ws, i2s2_clk, i2s2_data, i2s2_ws, i2s3_clk,
+ i2s3_data, i2s3_ws, qua_mi2s_data, qua_mi2s_sclk, qua_mi2s_ws,
+ swr_rx_clk, swr_rx_data, swr_tx_clk, swr_tx_data, wsa_mclk ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+
+ lpass_tlmm: pinctrl@a7c0000 {
+ compatible = "qcom,sm6115-lpass-lpi-pinctrl";
+ reg = <0x0a7c0000 0x20000>,
+ <0x0a950000 0x10000>;
+ clocks = <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 19>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml
deleted file mode 100644
index a7a2bb8bff46..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml
+++ /dev/null
@@ -1,181 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SM6115, SM4250 TLMM block
-
-maintainers:
- - Iskren Chernev <iskren.chernev@gmail.com>
-
-description:
- This binding describes the Top Level Mode Multiplexer block found in the
- SM4250/6115 platforms.
-
-properties:
- compatible:
- const: qcom,sm6115-tlmm
-
- reg:
- minItems: 3
- maxItems: 3
-
- reg-names:
- items:
- - const: west
- - const: south
- - const: east
-
- interrupts:
- description: Specifies the TLMM summary IRQ
- maxItems: 1
-
- interrupt-controller: true
-
- '#interrupt-cells':
- description:
- Specifies the PIN numbers and Flags, as defined in defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- wakeup-parent: true
-
-#PIN CONFIGURATION NODES
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sm6115-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sm6115-tlmm-state"
-
-'$defs':
- qcom-sm6115-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-2])$"
- - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data,
- sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c,
- cci_timer, cri_trng, dac_calib, dbg_out, ddr_bist, ddr_pxi0,
- ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2, gcc_gp3, gpio,
- gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx, jitter_bist,
- mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1, mpm_pwr, mss_lte,
- m_voc, nav_gpio, pa_indicator, pbs, pbs_out, phase_flag,
- pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti,
- qdss_gpio, qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb,
- sdc2_tb, sd_write, ssbi_wtr1, tgu, tsense_pwm, uim1_clk,
- uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
- uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger,
- wlan1_adc0, elan1_adc1 ]
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- required:
- - pins
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - reg-names
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- tlmm: pinctrl@500000 {
- compatible = "qcom,sm6115-tlmm";
- reg = <0x500000 0x400000>,
- <0x900000 0x400000>,
- <0xd00000 0x400000>;
- reg-names = "west", "south", "east";
- interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 114>;
-
- sdc2_on_state: sdc2-on-state {
- clk {
- pins = "sdc2_clk";
- bias-disable;
- drive-strength = <16>;
- };
-
- cmd {
- pins = "sdc2_cmd";
- bias-pull-up;
- drive-strength = <10>;
- };
-
- data {
- pins = "sdc2_data";
- bias-pull-up;
- drive-strength = <10>;
- };
-
- sd-cd {
- pins = "gpio88";
- function = "gpio";
- bias-pull-up;
- drive-strength = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml
new file mode 100644
index 000000000000..7f36f9b93333
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM6115, SM4250 TLMM block
+
+maintainers:
+ - Iskren Chernev <iskren.chernev@gmail.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM4250 and SM6115
+ SoCs.
+
+properties:
+ compatible:
+ const: qcom,sm6115-tlmm
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: west
+ - const: south
+ - const: east
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm6115-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm6115-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm6115-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-2])$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data,
+ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c,
+ cci_timer, cri_trng, dac_calib, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2, gcc_gp3, gpio,
+ gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx, jitter_bist,
+ mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1, mpm_pwr, mss_lte,
+ m_voc, nav_gpio, pa_indicator, pbs, pbs_out, phase_flag,
+ pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti,
+ qdss_gpio, qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb,
+ sdc2_tb, sd_write, ssbi_wtr1, tgu, tsense_pwm, uim1_clk,
+ uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
+ uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger,
+ wlan1_adc0, elan1_adc1 ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@500000 {
+ compatible = "qcom,sm6115-tlmm";
+ reg = <0x500000 0x400000>,
+ <0x900000 0x400000>,
+ <0xd00000 0x400000>;
+ reg-names = "west", "south", "east";
+ interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 114>;
+
+ sdc2_on_state: sdc2-on-state {
+ clk-pins {
+ pins = "sdc2_clk";
+ bias-disable;
+ drive-strength = <16>;
+ };
+
+ cmd-pins {
+ pins = "sdc2_cmd";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ data-pins {
+ pins = "sdc2_data";
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ sd-cd-pins {
+ pins = "gpio88";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml
deleted file mode 100644
index c8eec845ade9..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml
+++ /dev/null
@@ -1,133 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sm6125-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. SM6125 TLMM block
-
-maintainers:
- - Martin Botka <martin.botka@somainline.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer (TLMM) block found
- in the SM6125 platform.
-
-allOf:
- - $ref: "pinctrl.yaml#"
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,sm6125-tlmm
-
- reg:
- minItems: 3
- maxItems: 3
-
- reg-names:
- items:
- - const: "west"
- - const: "south"
- - const: "east"
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
- - reg-names
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sm6125-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sm6125-tlmm-state"
-
-$defs:
- qcom-sm6125-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio[0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2]$"
- - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1,
- atest_char2, atest_char3, atest_tsens, atest_tsens2, atest_usb1,
- atest_usb10, atest_usb11, atest_usb12, atest_usb13, atest_usb2,
- atest_usb20, atest_usb21, atest_usb22, atest_usb23, aud_sb,
- audio_ref, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1,
- cci_timer2, cci_timer3, cci_timer4, copy_gp, copy_phase, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
- ddr_pxi2, ddr_pxi3, debug_hot, dmic0_clk, dmic0_data, dmic1_clk,
- dmic1_data, dp_hot, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
- gp_pdm0, gp_pdm1, gp_pdm2, gpio, gps_tx, jitter_bist, ldo_en,
- ldo_update, m_voc, mclk1, mclk2, mdp_vsync, mdp_vsync0, mdp_vsync1,
- mdp_vsync2, mdp_vsync3, mdp_vsync4, mdp_vsync5, mpm_pwr, mss_lte,
- nav_pps, pa_indicator, phase_flag, pll_bist, pll_bypassnl, pll_reset,
- pri_mi2s, pri_mi2s_ws, prng_rosc, qca_sb, qdss_cti, qdss, qlink_enable,
- qlink_request, qua_mi2s, qui_mi2s, qup00, qup01, qup02, qup03, qup04,
- qup10, qup11, qup12, qup13, qup14, sd_write, sec_mi2s, sp_cmu, swr_rx,
- swr_tx, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm,
- uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
- uim2_present, uim2_reset, unused1, unused2, usb_phy, vfr_1, vsense_trigger,
- wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ]
-
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@500000 {
- compatible = "qcom,sm6125-tlmm";
- reg = <0x00500000 0x400000>,
- <0x00900000 0x400000>,
- <0x00d00000 0x400000>;
- reg-names = "west", "south", "east";
- interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- gpio-ranges = <&tlmm 0 0 134>;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml
new file mode 100644
index 000000000000..5a57a59cc1e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm6125-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: Qualcomm Technologies, Inc. SM6125 TLMM block
+
+maintainers:
+ - Martin Botka <martin.botka@somainline.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM6125 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6125-tlmm
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: west
+ - const: south
+ - const: east
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges: true
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm6125-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm6125-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm6125-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio[0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2]$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1,
+ atest_char2, atest_char3, atest_tsens, atest_tsens2, atest_usb1,
+ atest_usb10, atest_usb11, atest_usb12, atest_usb13, atest_usb2,
+ atest_usb20, atest_usb21, atest_usb22, atest_usb23, aud_sb,
+ audio_ref, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1,
+ cci_timer2, cci_timer3, cci_timer4, copy_gp, copy_phase, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ ddr_pxi2, ddr_pxi3, debug_hot, dmic0_clk, dmic0_data, dmic1_clk,
+ dmic1_data, dp_hot, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
+ gp_pdm0, gp_pdm1, gp_pdm2, gpio, gps_tx, jitter_bist, ldo_en,
+ ldo_update, m_voc, mclk1, mclk2, mdp_vsync, mdp_vsync0, mdp_vsync1,
+ mdp_vsync2, mdp_vsync3, mdp_vsync4, mdp_vsync5, mpm_pwr, mss_lte,
+ nav_pps, pa_indicator, phase_flag, pll_bist, pll_bypassnl, pll_reset,
+ pri_mi2s, pri_mi2s_ws, prng_rosc, qca_sb, qdss_cti, qdss, qlink_enable,
+ qlink_request, qua_mi2s, qui_mi2s, qup00, qup01, qup02, qup03, qup04,
+ qup10, qup11, qup12, qup13, qup14, sd_write, sec_mi2s, sp_cmu, swr_rx,
+ swr_tx, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm,
+ uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
+ uim2_present, uim2_reset, unused1, unused2, usb_phy, vfr_1, vsense_trigger,
+ wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@500000 {
+ compatible = "qcom,sm6125-tlmm";
+ reg = <0x00500000 0x400000>,
+ <0x00900000 0x400000>,
+ <0x00d00000 0x400000>;
+ reg-names = "west", "south", "east";
+ interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ gpio-ranges = <&tlmm 0 0 134>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ sdc2-off-state {
+ clk-pins {
+ pins = "sdc2_clk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cmd-pins {
+ pins = "sdc2_cmd";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ data-pins {
+ pins = "sdc2_data";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml
deleted file mode 100644
index 898608671c4b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml
+++ /dev/null
@@ -1,149 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sm6350-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SM6350 TLMM block
-
-maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer (TLMM) block found
- in the SM6350 platform.
-
-allOf:
- - $ref: "pinctrl.yaml#"
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,sm6350-tlmm
-
- reg:
- maxItems: 1
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sm6350-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sm6350-tlmm-state"
-
-$defs:
- qcom-sm6350-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-7])$"
- - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, atest_char2,
- atest_char3, atest_tsens, atest_tsens2, atest_usb1, atest_usb10, atest_usb11,
- atest_usb12, atest_usb13, atest_usb2, atest_usb20, atest_usb21, atest_usb22,
- atest_usb23, audio_ref, btfm_slimbus, cam_mclk0, cam_mclk1, cam_mclk2, cam_mclk3,
- cam_mclk4, cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
- cci_timer4, cri_trng, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3,
- dp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0, gp_pdm1, gp_pdm2, gpio,
- gps_tx, ibi_i3c, jitter_bist, ldo_en, ldo_update, lpass_ext, m_voc, mclk,
- mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s_0, mi2s_1, mi2s_2,
- mss_lte, nav_gpio, nav_pps, pa_indicator, pcie0_clk, phase_flag0, phase_flag1,
- phase_flag10, phase_flag11, phase_flag12, phase_flag13, phase_flag14, phase_flag15,
- phase_flag16, phase_flag17, phase_flag18, phase_flag19, phase_flag2, phase_flag20,
- phase_flag21, phase_flag22, phase_flag23, phase_flag24, phase_flag25, phase_flag26,
- phase_flag27, phase_flag28, phase_flag29, phase_flag3, phase_flag30, phase_flag31,
- phase_flag4, phase_flag5, phase_flag6, phase_flag7, phase_flag8, phase_flag9,
- pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti, qdss_gpio, qdss_gpio0,
- qdss_gpio1, qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14,
- qdss_gpio15, qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6,
- qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink0_enable, qlink0_request, qlink0_wmss,
- qlink1_enable, qlink1_request, qlink1_wmss, qup00, qup01, qup02, qup10, qup11,
- qup12, qup13_f1, qup13_f2, qup14, rffe0_clk, rffe0_data, rffe1_clk, rffe1_data,
- rffe2_clk, rffe2_data, rffe3_clk, rffe3_data, rffe4_clk, rffe4_data, sd_write,
- sdc1_tb, sdc2_tb, sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1,
- tsense_pwm2, uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
- uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1,
- wlan2_adc0, wlan2_adc1, ]
-
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@f100000 {
- compatible = "qcom,sm6350-tlmm";
- reg = <0x0f100000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 157>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio25";
- function = "qup13_f2";
- bias-disable;
- };
-
- tx {
- pins = "gpio26";
- function = "qup13_f2";
- bias-disable;
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml
new file mode 100644
index 000000000000..b262af6be97d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm6350-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM6350 TLMM block
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM6350 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm6350-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 9
+ maxItems: 9
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 78
+
+ gpio-line-names:
+ maxItems: 156
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm6350-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm6350-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm6350-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-5])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, atest_char2,
+ atest_char3, atest_tsens, atest_tsens2, atest_usb1, atest_usb10, atest_usb11,
+ atest_usb12, atest_usb13, atest_usb2, atest_usb20, atest_usb21, atest_usb22,
+ atest_usb23, audio_ref, btfm_slimbus, cam_mclk0, cam_mclk1, cam_mclk2, cam_mclk3,
+ cam_mclk4, cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+ cci_timer4, cri_trng, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3,
+ dp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0, gp_pdm1, gp_pdm2, gpio,
+ gps_tx, ibi_i3c, jitter_bist, ldo_en, ldo_update, lpass_ext, m_voc, mclk,
+ mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s_0, mi2s_1, mi2s_2,
+ mss_lte, nav_gpio, nav_pps, pa_indicator, pcie0_clk, phase_flag0, phase_flag1,
+ phase_flag10, phase_flag11, phase_flag12, phase_flag13, phase_flag14, phase_flag15,
+ phase_flag16, phase_flag17, phase_flag18, phase_flag19, phase_flag2, phase_flag20,
+ phase_flag21, phase_flag22, phase_flag23, phase_flag24, phase_flag25, phase_flag26,
+ phase_flag27, phase_flag28, phase_flag29, phase_flag3, phase_flag30, phase_flag31,
+ phase_flag4, phase_flag5, phase_flag6, phase_flag7, phase_flag8, phase_flag9,
+ pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti, qdss_gpio, qdss_gpio0,
+ qdss_gpio1, qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14,
+ qdss_gpio15, qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6,
+ qdss_gpio7, qdss_gpio8, qdss_gpio9, qlink0_enable, qlink0_request, qlink0_wmss,
+ qlink1_enable, qlink1_request, qlink1_wmss, qup00, qup01, qup02, qup10, qup11,
+ qup12, qup13_f1, qup13_f2, qup14, rffe0_clk, rffe0_data, rffe1_clk, rffe1_data,
+ rffe2_clk, rffe2_data, rffe3_clk, rffe3_data, rffe4_clk, rffe4_data, sd_write,
+ sdc1_tb, sdc2_tb, sp_cmu, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1,
+ tsense_pwm2, uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data,
+ uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1,
+ wlan2_adc0, wlan2_adc1, ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@f100000 {
+ compatible = "qcom,sm6350-tlmm";
+ reg = <0x0f100000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 157>;
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio25";
+ function = "qup13_f2";
+ bias-disable;
+ };
+
+ tx-pins {
+ pins = "gpio26";
+ function = "qup13_f2";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml
index 3908807a8339..c11af09c3f5b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml
@@ -7,14 +7,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. SM6375 TLMM block
maintainers:
- - Konrad Dybcio <konrad.dybcio@somainline.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
-description: |
- This binding describes the Top Level Mode Multiplexer (TLMM) block found
- in the SM6375 platform.
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM6375 SoC.
allOf:
- - $ref: "pinctrl.yaml#"
- $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
properties:
@@ -24,28 +22,19 @@ properties:
reg:
maxItems: 1
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
+ interrupts:
+ maxItems: 1
-additionalProperties: false
+ gpio-reserved-ranges: true
patternProperties:
- '-state$':
+ "-state$":
oneOf:
- $ref: "#/$defs/qcom-sm6375-tlmm-state"
- patternProperties:
- ".*":
+ "-pins$":
$ref: "#/$defs/qcom-sm6375-tlmm-state"
+ additionalProperties: false
$defs:
qcom-sm6375-tlmm-state:
@@ -53,7 +42,8 @@ $defs:
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -62,7 +52,7 @@ $defs:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-6])$"
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-4][0-9]|15[0-5])$"
- enum: [ ufs_reset, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
sdc2_cmd, sdc2_data ]
minItems: 1
@@ -108,51 +98,45 @@ $defs:
usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1,
wlan2_adc0, wlan2_adc1 ]
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
required:
- pins
- - function
- additionalProperties: false
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@500000 {
- compatible = "qcom,sm6375-tlmm";
- reg = <0x00500000 0x800000>;
- interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 157>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio18";
- function = "qup13_f2";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio19";
- function = "qup13_f2";
- bias-disable;
- };
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@500000 {
+ compatible = "qcom,sm6375-tlmm";
+ reg = <0x00500000 0x800000>;
+ interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 157>; /* GPIOs + ufs_reset */
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio18";
+ function = "qup13_f2";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio19";
+ function = "qup13_f2";
+ bias-disable;
+ };
};
+ };
...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml
new file mode 100644
index 000000000000..7f23f939ad32
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm7150-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM7150 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Danila Tikhonov <danila@jiaxyga.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM7150 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm7150-tlmm
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: west
+ - const: north
+ - const: south
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 60
+
+ gpio-line-names:
+ maxItems: 119
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm7150-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm7150-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm7150-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-8])$"
+ - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk,
+ sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ gpio, adsp_ext, agera_pll, aoss_cti, atest_char, atest_tsens,
+ atest_tsens2, atest_usb1, atest_usb2, cam_mclk, cci_async,
+ cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+ cci_timer4, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2,
+ ddr_pxi3, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0,
+ gp_pdm1, gp_pdm2, gps_tx, jitter_bist, ldo_en, ldo_update,
+ m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2,
+ mdp_vsync3, mss_lte, nav_pps_in, nav_pps_out, pa_indicator,
+ pci_e, phase_flag, pll_bist, pll_bypassnl, pll_reset, pri_mi2s,
+ pri_mi2s_ws, prng_rosc, qdss, qdss_cti, qlink_enable,
+ qlink_request, qua_mi2s, qup00, qup01, qup02, qup03, qup04,
+ qup10, qup11, qup12, qup13, qup14, qup15, sd_write, sdc40,
+ sdc41, sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, ter_mi2s,
+ tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsif1_clk, tsif1_data,
+ tsif1_en, tsif1_error, tsif1_sync, tsif2_clk, tsif2_data,
+ tsif2_en, tsif2_error, tsif2_sync, uim1_clk, uim1_data,
+ uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present,
+ uim2_reset, uim_batt, usb_phy, vfr_1, vsense_trigger,
+ wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk,
+ wsa_data ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@3500000 {
+ compatible = "qcom,sm7150-tlmm";
+ reg = <0x03500000 0x300000>,
+ <0x03900000 0x300000>,
+ <0x03d00000 0x300000>;
+ reg-names = "west", "north", "south";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-ranges = <&tlmm 0 0 120>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ wakeup-parent = <&pdc>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio44";
+ function = "qup12";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio45";
+ function = "qup12";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.txt
deleted file mode 100644
index fa37733e5102..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.txt
+++ /dev/null
@@ -1,190 +0,0 @@
-Qualcomm SM8150 TLMM block
-
-This binding describes the Top Level Mode Multiplexer block found in the
-QCS404 platform.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be "qcom,sm8150-pinctrl"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of the north, south, west
- and east TLMM tiles.
-
-- reg-names:
- Usage: required
- Value type: <prop-encoded-array>
- Defintiion: names for the cells of reg, must contain "north", "south"
- "west" and "east".
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the TLMM summary IRQ.
-
-- interrupt-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as an interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/interrupt-controller/irq.h>
-
-- gpio-controller:
- Usage: required
- Value type: <none>
- Definition: identifies this node as a gpio controller
-
-- #gpio-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 2. Specifying the pin number and flags, as defined
- in <dt-bindings/gpio/gpio.h>
-
-- gpio-ranges:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: see ../gpio/gpio.txt
-
-- gpio-reserved-ranges:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: see ../gpio/gpio.txt
-
-Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
-a general description of GPIO and interrupt bindings.
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-The pin configuration nodes act as a container for an arbitrary number of
-subnodes. Each of these subnodes represents some desired configuration for a
-pin, a group, or a list of pins or groups. This configuration can include the
-mux function to select on those pin(s)/group(s), and various pin configuration
-parameters, such as pull-up, drive strength, etc.
-
-
-PIN CONFIGURATION NODES:
-
-The name of each subnode is not important; all subnodes should be enumerated
-and processed purely based on their content.
-
-Each subnode only affects those parameters that are explicitly listed. In
-other words, a subnode that lists a mux function but no pin configuration
-parameters implies no information about any pin configuration parameters.
-Similarly, a pin subnode that describes a pullup parameter implies no
-information about e.g. the mux function.
-
-
-The following generic properties as defined in pinctrl-bindings.txt are valid
-to specify in a pin configuration subnode:
-
-- pins:
- Usage: required
- Value type: <string-array>
- Definition: List of gpio pins affected by the properties specified in
- this subnode.
-
- Valid pins are:
- gpio0-gpio149
- Supports mux, bias and drive-strength
-
- sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd,
- sdc2_data sdc1_rclk
- Supports bias and drive-strength
-
- ufs_reset
- Supports bias and drive-strength
-
-- function:
- Usage: required
- Value type: <string>
- Definition: Specify the alternative function to be configured for the
- specified pins. Functions are only valid for gpio pins.
- Valid values are:
-
- adsp_ext, agera_pll, aoss_cti, ddr_pxi2, atest_char,
- atest_char0, atest_char1, atest_char2, atest_char3,
- audio_ref, atest_usb1, atest_usb2, atest_usb10,
- atest_usb11, atest_usb12, atest_usb13, atest_usb20,
- atest_usb21, atest_usb22, atest_usb2, atest_usb23,
- btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0,
- cci_timer1, cci_timer2, cci_timer3, cci_timer4,
- cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist,
- ddr_pxi0, ddr_pxi1, ddr_pxi3, edp_hot, edp_lcd,
- emac_phy, emac_pps, gcc_gp1, gcc_gp2, gcc_gp3, gpio,
- hs1_mi2s, hs2_mi2s, hs3_mi2s, jitter_bist,
- lpass_slimbus, mdp_vsync, mdp_vsync0, mdp_vsync1,
- mdp_vsync2, mdp_vsync3, mss_lte, m_voc, nav_pps,
- pa_indicator, pci_e0, phase_flag, pll_bypassnl,
- pll_bist, pci_e1, pll_reset, pri_mi2s, pri_mi2s_ws,
- prng_rosc, qdss, qdss_cti, qlink_request, qlink_enable,
- qspi0, qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qua_mi2s,
- qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8,
- qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16,
- qup17, qup18, qup19, qup_l4, qup_l5, qup_l6, rgmii,
- sdc4, sd_write, sec_mi2s, spkr_i2s, sp_cmu, ter_mi2s,
- tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1,
- tsense_pwm2, tsif1, tsif2, uim1, uim2, uim_batt,
- usb2phy_ac, usb_phy, vfr_1, vsense_trigger, wlan1_adc0,
- wlan1_adc1, wlan2_adc0, wlan2_adc1, wmss_reset
-
-- bias-disable:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configued as no pull.
-
-- bias-pull-down:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configued as pull down.
-
-- bias-pull-up:
- Usage: optional
- Value type: <none>
- Definition: The specified pins should be configued as pull up.
-
-- output-high:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- high.
- Not valid for sdc pins.
-
-- output-low:
- Usage: optional
- Value type: <none>
- Definition: The specified pins are configured in output mode, driven
- low.
- Not valid for sdc pins.
-
-- drive-strength:
- Usage: optional
- Value type: <u32>
- Definition: Selects the drive strength for the specified pins, in mA.
- Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16
-
-Example:
-
- tlmm: pinctrl@3000000 {
- compatible = "qcom,sm8150-pinctrl";
- reg = <0x03100000 0x300000>,
- <0x03500000 0x300000>,
- <0x03900000 0x300000>,
- <0x03D00000 0x300000>;
- reg-names = "west", "east", "north", "south";
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 175>;
- gpio-reserved-ranges = <0 4>, <126 4>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml
new file mode 100644
index 000000000000..c4542e2d7108
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8150-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150 TLMM pin controller
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8150 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm8150-pinctrl
+
+ reg:
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: west
+ - const: east
+ - const: north
+ - const: south
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 88
+
+ gpio-line-names:
+ maxItems: 175
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8150-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8150-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8150-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-6][0-9]|17[0-4])$"
+ - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ adsp_ext, agera_pll, aoss_cti, ddr_pxi2, atest_char,
+ atest_char0, atest_char1, atest_char2, atest_char3, audio_ref,
+ atest_usb1, atest_usb2, atest_usb10, atest_usb11, atest_usb12,
+ atest_usb13, atest_usb20, atest_usb21, atest_usb22,
+ atest_usb23, btfm_slimbus, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+ cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0,
+ ddr_pxi1, ddr_pxi3, edp_hot, edp_lcd, emac_phy, emac_pps,
+ gcc_gp1, gcc_gp2, gcc_gp3, gpio, hs1_mi2s, hs2_mi2s, hs3_mi2s,
+ jitter_bist, lpass_slimbus, mdp_vsync, mdp_vsync0, mdp_vsync1,
+ mdp_vsync2, mdp_vsync3, mss_lte, m_voc, nav_pps, pa_indicator,
+ pci_e0, phase_flag, pll_bypassnl, pll_bist, pci_e1, pll_reset,
+ pri_mi2s, pri_mi2s_ws, prng_rosc, qdss, qdss_cti,
+ qlink_request, qlink_enable, qspi0, qspi1, qspi2, qspi3,
+ qspi_clk, qspi_cs, qua_mi2s, qup0, qup1, qup2, qup3, qup4,
+ qup5, qup6, qup7, qup8, qup9, qup10, qup11, qup12, qup13,
+ qup14, qup15, qup16, qup17, qup18, qup19, qup_l4, qup_l5,
+ qup_l6, rgmii, sdc4, sd_write, sec_mi2s, spkr_i2s, sp_cmu,
+ ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm1,
+ tsense_pwm2, tsif1, tsif2, uim1, uim2, uim_batt, usb2phy_ac,
+ usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1,
+ wlan2_adc0, wlan2_adc1, wmss_reset ]
+
+ required:
+ - pins
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tlmm: pinctrl@3100000 {
+ compatible = "qcom,sm8150-pinctrl";
+ reg = <0x03100000 0x300000>,
+ <0x03500000 0x300000>,
+ <0x03900000 0x300000>,
+ <0x03d00000 0x300000>;
+ reg-names = "west", "east", "north", "south";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-ranges = <&tlmm 0 0 176>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ wakeup-parent = <&pdc>;
+
+ qup-spi0-default-state {
+ pins = "gpio0", "gpio1", "gpio2", "gpio3";
+ function = "qup0";
+ drive-strength = <6>;
+ bias-disable;
+ };
+
+ pcie1-default-state {
+ perst-pins {
+ pins = "gpio102";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ clkreq-pins {
+ pins = "gpio103";
+ function = "pci_e1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ wake-pins {
+ pins = "gpio104";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml
index 06efb1382876..750c996c10a7 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml
@@ -4,22 +4,20 @@
$id: http://devicetree.org/schemas/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS)
- Low Power Island (LPI) TLMM block
+title: Qualcomm SM8250 SoC LPASS LPI TLMM
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- LPASS LPI IP on most Qualcomm SoCs
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8250 SoC.
properties:
compatible:
const: qcom,sm8250-lpass-lpi-pinctrl
reg:
- minItems: 2
maxItems: 2
clocks:
@@ -32,24 +30,23 @@ properties:
- const: core
- const: audio
- gpio-controller: true
-
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
-#PIN CONFIGURATION NODES
patternProperties:
- '-pins$':
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8250-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8250-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8250-lpass-state:
type: object
description:
Pinctrl node's client devices use subnodes for desired pin configuration.
Client device subnodes use below standard properties.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
properties:
pins:
@@ -58,7 +55,7 @@ patternProperties:
subnode.
items:
oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9])$"
+ - pattern: "^gpio([0-9]|1[0-3])$"
minItems: 1
maxItems: 14
@@ -72,50 +69,16 @@ patternProperties:
Specify the alternative function to be configured for the specified
pins.
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- slew-rate:
- enum: [0, 1, 2, 3]
- default: 0
- description: |
- 0: No adjustments
- 1: Higher Slew rate (faster edges)
- 2: Lower Slew rate (slower edges)
- 3: Reserved (No adjustments)
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: qcom,lpass-lpi-common.yaml#
required:
- compatible
- reg
- clocks
- clock-names
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -130,4 +93,28 @@ examples:
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&lpi_tlmm 0 0 14>;
+
+ wsa-swr-active-state {
+ clk-pins {
+ pins = "gpio10";
+ function = "wsa_swr_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio11";
+ function = "wsa_swr_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ };
+ };
+
+ tx-swr-sleep-clk-state {
+ pins = "gpio0";
+ function = "swr_tx_clk";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
};
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
index 15bb1018cf21..b5d04347c064 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
@@ -9,141 +9,112 @@ title: Qualcomm Technologies, Inc. SM8250 TLMM block
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
-description: |
- This binding describes the Top Level Mode Multiplexer block found in the
- SM8250 platform.
+description:
+ Top Level Mode Multiplexer pin controller in the Qualcomm SM8250 SoC.
properties:
compatible:
const: qcom,sm8250-pinctrl
reg:
- minItems: 3
maxItems: 3
reg-names:
items:
- - const: "west"
- - const: "south"
- - const: "north"
+ - const: west
+ - const: south
+ - const: north
interrupts:
- description: Specifies the TLMM summary IRQ
maxItems: 1
- interrupt-controller: true
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 90
- '#interrupt-cells':
- description:
- Specifies the PIN numbers and Flags, as defined in defined in
- include/dt-bindings/interrupt-controller/irq.h
- const: 2
-
- gpio-controller: true
+ gpio-line-names:
+ maxItems: 180
- '#gpio-cells':
- description: Specifying the pin number and flags, as defined in
- include/dt-bindings/gpio/gpio.h
- const: 2
-
- gpio-ranges:
- maxItems: 1
-
- wakeup-parent: true
-
-#PIN CONFIGURATION NODES
patternProperties:
- '^.*$':
- if:
- type: object
- then:
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$"
- - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ aoss_cti, atest, audio_ref, cam_mclk, cci_async, cci_i2c,
- cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
- ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gpio,
- ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, mdp_vsync0,
- mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1,
- mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws,
- mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, pci_e0, pci_e1,
- pci_e2, phase_flag, pll_bist, pll_bypassnl, pll_clk, pll_reset,
- pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qspi0, qspi1, qspi2, qspi3,
- qspi_clk, qspi_cs, qup0, qup1, qup10, qup11, qup12, qup13, qup14,
- qup15, qup16, qup17, qup18, qup19, qup2, qup3, qup4, qup5, qup6,
- qup7, qup8, qup9, qup_l4, qup_l5, qup_l6, sd_write, sdc40, sdc41,
- sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, tgu_ch0, tgu_ch1,
- tgu_ch2, tgu_ch3, tsense_pwm1, tsense_pwm2, tsif0_clk, tsif0_data,
- tsif0_en, tsif0_error, tsif0_sync, tsif1_clk, tsif1_data, tsif1_en,
- tsif1_error, tsif1_sync, usb2phy_ac, usb_phy, vsense_trigger ]
-
- drive-strength:
- enum: [2, 4, 6, 8, 10, 12, 14, 16]
- default: 2
- description:
- Selects the drive strength for the specified pins, in mA.
-
- bias-pull-down: true
-
- bias-pull-up: true
-
- bias-disable: true
-
- output-high: true
-
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8250-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8250-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8250-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$"
+ - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ aoss_cti, atest, audio_ref, cam_mclk, cci_async, cci_i2c,
+ cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gpio,
+ ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, mdp_vsync0,
+ mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1,
+ mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck, mi2s1_ws,
+ mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, pci_e0, pci_e1,
+ pci_e2, phase_flag, pll_bist, pll_bypassnl, pll_clk, pll_reset,
+ pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qspi0, qspi1, qspi2, qspi3,
+ qspi_clk, qspi_cs, qup0, qup1, qup10, qup11, qup12, qup13, qup14,
+ qup15, qup16, qup17, qup18, qup19, qup2, qup3, qup4, qup5, qup6,
+ qup7, qup8, qup9, qup_l4, qup_l5, qup_l6, sd_write, sdc40, sdc41,
+ sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, sp_cmu, tgu_ch0, tgu_ch1,
+ tgu_ch2, tgu_ch3, tsense_pwm1, tsense_pwm2, tsif0_clk, tsif0_data,
+ tsif0_en, tsif0_error, tsif0_sync, tsif1_clk, tsif1_data, tsif1_en,
+ tsif1_error, tsif1_sync, usb2phy_ac, usb_phy, vsense_trigger ]
+
+ required:
+ - pins
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
required:
- compatible
- reg
- reg-names
- - interrupts
- - interrupt-controller
- - '#interrupt-cells'
- - gpio-controller
- - '#gpio-cells'
- - gpio-ranges
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@1f00000 {
- compatible = "qcom,sm8250-pinctrl";
- reg = <0x0f100000 0x300000>,
- <0x0f500000 0x300000>,
- <0x0f900000 0x300000>;
- reg-names = "west", "south", "north";
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 180>;
- wakeup-parent = <&pdc>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@1f00000 {
+ compatible = "qcom,sm8250-pinctrl";
+ reg = <0x0f100000 0x300000>,
+ <0x0f500000 0x300000>,
+ <0x0f900000 0x300000>;
+ reg-names = "west", "south", "north";
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 181>; /* GPIOs + ufs_reset */
+ wakeup-parent = <&pdc>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..46aec0713775
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350 SoC LPASS LPI TLMM
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8350 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm8350-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8350-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8350-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8350-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
+
+ function:
+ enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk,
+ dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b,
+ ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk,
+ i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk,
+ i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, i2s4_clk,
+ i2s4_data, i2s4_ws, slimbus_clk, slimbus_data, swr_rx_clk,
+ swr_rx_data, swr_tx_clk, swr_tx_data, wsa_swr_clk,
+ wsa_swr_data, wsa2_swr_clk, wsa2_swr_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+
+ lpass_tlmm: pinctrl@33c0000 {
+ compatible = "qcom,sm8350-lpass-lpi-pinctrl";
+ reg = <0x033c0000 0x20000>,
+ <0x03550000 0x10000>;
+
+ clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 15>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
deleted file mode 100644
index 6b7789db2f75..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
+++ /dev/null
@@ -1,146 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SM8350 TLMM block
-
-maintainers:
- - Vinod Koul <vkoul@kernel.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer (TLMM) block found
- in the SM8350 platform.
-
-allOf:
- - $ref: "pinctrl.yaml#"
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,sm8350-tlmm
-
- reg:
- maxItems: 1
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sm8350-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sm8350-tlmm-state"
-
-$defs:
- qcom-sm8350-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-3])$"
- - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
-
- enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async,
- cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
- ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
- gpio, ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, mdp_vsync0,
- mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1,
- mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck,
- mi2s1_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws,
- mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12,
- mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6,
- mss_grfc7, mss_grfc8, mss_grfc9, nav_gpio, pa_indicator,
- pcie0_clkreqn, pcie1_clkreqn, phase_flag, pll_bist, pll_clk,
- pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable,
- qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
- qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss, qspi0,
- qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10,
- qup11, qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19,
- qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5,
- qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
- sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2,
- tgu_ch3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data,
- uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_present,
- uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ]
-
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@f100000 {
- compatible = "qcom,sm8350-tlmm";
- reg = <0x0f100000 0x300000>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = <&tlmm 0 0 203>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio18";
- function = "qup3";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio19";
- function = "qup3";
- bias-disable;
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml
new file mode 100644
index 000000000000..ec5e09611d81
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8350-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8350 TLMM block
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8350 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8350-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 102
+
+ gpio-line-names:
+ maxItems: 203
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8350-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8350-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8350-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-2])$"
+ - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async,
+ cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ ddr_pxi2, ddr_pxi3, dp_hot, dp_lcd, gcc_gp1, gcc_gp2, gcc_gp3,
+ gpio, ibi_i3c, jitter_bist, lpass_slimbus, mdp_vsync, mdp_vsync0,
+ mdp_vsync1, mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1,
+ mi2s0_sck, mi2s0_ws, mi2s1_data0, mi2s1_data1, mi2s1_sck,
+ mi2s1_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws,
+ mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12,
+ mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6,
+ mss_grfc7, mss_grfc8, mss_grfc9, nav_gpio, pa_indicator,
+ pcie0_clkreqn, pcie1_clkreqn, phase_flag, pll_bist, pll_clk,
+ pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, qlink0_enable,
+ qlink0_request, qlink0_wmss, qlink1_enable, qlink1_request,
+ qlink1_wmss, qlink2_enable, qlink2_request, qlink2_wmss, qspi0,
+ qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10,
+ qup11, qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19,
+ qup2, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, qup_l5,
+ qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
+ sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2,
+ tgu_ch3, tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data,
+ uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_present,
+ uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@f100000 {
+ compatible = "qcom,sm8350-tlmm";
+ reg = <0x0f100000 0x300000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 204>; /* GPIOs + ufs_reset */
+
+ gpio-wo-subnode-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-subnodes-state {
+ rx-pins {
+ pins = "gpio18";
+ function = "qup3";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio19";
+ function = "qup3";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..e7565592da86
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8450 SoC LPASS LPI TLMM
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8450 SoC.
+
+properties:
+ compatible:
+ const: qcom,sm8450-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8450-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8450-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8450-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
+
+ function:
+ enum: [ swr_tx_clk, swr_tx_data, swr_rx_clk, swr_rx_data,
+ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic4_clk,
+ dmic4_data, i2s2_clk, i2s2_ws, dmic3_clk, dmic3_data,
+ qua_mi2s_sclk, qua_mi2s_ws, qua_mi2s_data, i2s1_clk, i2s1_ws,
+ i2s1_data, wsa_swr_clk, wsa_swr_data, wsa2_swr_clk,
+ wsa2_swr_data, i2s2_data, i2s4_ws, i2s4_clk, i2s4_data,
+ slimbus_clk, i2s3_clk, i2s3_ws, i2s3_data, slimbus_data,
+ ext_mclk1_c, ext_mclk1_b, ext_mclk1_a, ext_mclk1_d,
+ ext_mclk1_e ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ pinctrl@3440000 {
+ compatible = "qcom,sm8450-lpass-lpi-pinctrl";
+ reg = <0x3440000 0x20000>,
+ <0x34d0000 0x10000>;
+ clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 23>;
+
+ wsa-swr-active-state {
+ clk-pins {
+ pins = "gpio10";
+ function = "wsa_swr_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio11";
+ function = "wsa_swr_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ };
+ };
+
+ tx-swr-sleep-clk-state {
+ pins = "gpio0";
+ function = "swr_tx_clk";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml
deleted file mode 100644
index 9c891246245b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml
+++ /dev/null
@@ -1,143 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/qcom,sm8450-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm Technologies, Inc. SM8450 TLMM block
-
-maintainers:
- - Vinod Koul <vkoul@kernel.org>
-
-description: |
- This binding describes the Top Level Mode Multiplexer (TLMM) block found
- in the SM8450 platform.
-
-allOf:
- - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
-
-properties:
- compatible:
- const: qcom,sm8450-tlmm
-
- reg:
- maxItems: 1
-
- interrupts: true
- interrupt-controller: true
- '#interrupt-cells': true
- gpio-controller: true
- gpio-reserved-ranges: true
- '#gpio-cells': true
- gpio-ranges: true
- wakeup-parent: true
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-patternProperties:
- '-state$':
- oneOf:
- - $ref: "#/$defs/qcom-sm8450-tlmm-state"
- - patternProperties:
- ".*":
- $ref: "#/$defs/qcom-sm8450-tlmm-state"
-
-$defs:
- qcom-sm8450-tlmm-state:
- type: object
- description:
- Pinctrl node's client devices use subnodes for desired pin configuration.
- Client device subnodes use below standard properties.
- $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
-
- properties:
- pins:
- description:
- List of gpio pins affected by the properties specified in this
- subnode.
- items:
- oneOf:
- - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9])$"
- - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
- minItems: 1
- maxItems: 36
-
- function:
- description:
- Specify the alternative function to be configured for the specified
- pins.
- enum: [ aon_cam, atest_char, atest_usb, audio_ref, cam_mclk, cci_async,
- cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng,
- cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
- ddr_pxi2, ddr_pxi3, dp_hot, gcc_gp1, gcc_gp2, gcc_gp3,
- gpio, ibi_i3c, jitter_bist, mdp_vsync, mdp_vsync0, mdp_vsync1,
- mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1, mi2s0_sck,
- mi2s0_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws,
- mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12,
- mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6,
- mss_grfc7, mss_grfc8, mss_grfc9, nav, pcie0_clkreqn,
- pcie1_clkreqn, phase_flag, pll_bist, pll_clk, pri_mi2s,
- prng_rosc, qdss_cti, qdss_gpio, qlink0_enable, qlink0_request,
- qlink0_wmss, qlink1_enable, qlink1_request, qlink1_wmss,
- qlink2_enable, qlink2_request, qlink2_wmss, qspi0, qspi1,
- qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10, qup11,
- qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19, qup2,
- qup20, qup21, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4,
- qup_l5, qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
- sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2,
- tgu_ch3, tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3,
- tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data, uim0_present,
- uim0_reset, uim1_clk, uim1_data, uim1_present, uim1_reset,
- usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ]
-
- bias-disable: true
- bias-pull-down: true
- bias-pull-up: true
- drive-strength: true
- input-enable: true
- output-high: true
- output-low: true
-
- required:
- - pins
- - function
-
- additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- pinctrl@f100000 {
- compatible = "qcom,sm8450-tlmm";
- reg = <0x0f100000 0x300000>;
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&tlmm 0 0 211>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
-
- gpio-wo-subnode-state {
- pins = "gpio1";
- function = "gpio";
- };
-
- uart-w-subnodes-state {
- rx {
- pins = "gpio26";
- function = "qup7";
- bias-pull-up;
- };
-
- tx {
- pins = "gpio27";
- function = "qup7";
- bias-disable;
- };
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml
new file mode 100644
index 000000000000..16fd2c5e2339
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8450-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8450 TLMM block
+
+maintainers:
+ - Vinod Koul <vkoul@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8450 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8450-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 105
+
+ gpio-line-names:
+ maxItems: 210
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8450-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8450-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8450-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ aon_cam, atest_char, atest_usb, audio_ref, cam_mclk, cci_async,
+ cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng,
+ cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ ddr_pxi2, ddr_pxi3, dp_hot, gcc_gp1, gcc_gp2, gcc_gp3,
+ gpio, ibi_i3c, jitter_bist, mdp_vsync, mdp_vsync0, mdp_vsync1,
+ mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1, mi2s0_sck,
+ mi2s0_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws,
+ mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12,
+ mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6,
+ mss_grfc7, mss_grfc8, mss_grfc9, nav, pcie0_clkreqn,
+ pcie1_clkreqn, phase_flag, pll_bist, pll_clk, pri_mi2s,
+ prng_rosc, qdss_cti, qdss_gpio, qlink0_enable, qlink0_request,
+ qlink0_wmss, qlink1_enable, qlink1_request, qlink1_wmss,
+ qlink2_enable, qlink2_request, qlink2_wmss, qspi0, qspi1,
+ qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10, qup11,
+ qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19, qup2,
+ qup20, qup21, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4,
+ qup_l5, qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
+ sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2,
+ tgu_ch3, tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3,
+ tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data, uim0_present,
+ uim0_reset, uim1_clk, uim1_data, uim1_present, uim1_reset,
+ usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pinctrl@f100000 {
+ compatible = "qcom,sm8450-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 211>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio26";
+ function = "qup7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio27";
+ function = "qup7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..89821871c606
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 SoC LPASS LPI TLMM
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8550 SoC.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,sm8550-lpass-lpi-pinctrl
+ - items:
+ - const: qcom,x1e80100-lpass-lpi-pinctrl
+ - const: qcom,sm8550-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+ - description: LPASS LPI MCC registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8550-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8550-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8550-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
+
+ function:
+ enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk,
+ dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b,
+ ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk,
+ i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk,
+ i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, i2s4_clk,
+ i2s4_data, i2s4_ws, slimbus_clk, slimbus_data, swr_rx_clk,
+ swr_rx_data, swr_tx_clk, swr_tx_data, wsa_swr_clk,
+ wsa_swr_data, wsa2_swr_clk, wsa2_swr_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+
+ lpass_tlmm: pinctrl@6e80000 {
+ compatible = "qcom,sm8550-lpass-lpi-pinctrl";
+ reg = <0x06e80000 0x20000>,
+ <0x0725a000 0x10000>;
+
+ clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 23>;
+
+ tx-swr-sleep-clk-state {
+ pins = "gpio0";
+ function = "swr_tx_clk";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml
new file mode 100644
index 000000000000..c2ae79df424f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8550-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8550 TLMM block
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8550 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8550-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 105
+
+ gpio-line-names:
+ maxItems: 210
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8550-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8550-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8550-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ aon_cci, aoss_cti, atest_char, atest_usb,
+ audio_ext_mclk0, audio_ext_mclk1, audio_ref_clk,
+ cam_aon_mclk4, cam_mclk, cci_async_in, cci_i2c_scl,
+ cci_i2c_sda, cci_timer, cmu_rng, coex_uart1_rx,
+ coex_uart1_tx, coex_uart2_rx, coex_uart2_tx,
+ cri_trng, dbg_out_clk, ddr_bist_complete,
+ ddr_bist_fail, ddr_bist_start, ddr_bist_stop,
+ ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, dp_hot,
+ gcc_gp1, gcc_gp2, gcc_gp3, gpio, i2chub0_se0,
+ i2chub0_se1, i2chub0_se2, i2chub0_se3, i2chub0_se4,
+ i2chub0_se5, i2chub0_se6, i2chub0_se7, i2chub0_se8,
+ i2chub0_se9, i2s0_data0, i2s0_data1, i2s0_sck,
+ i2s0_ws, i2s1_data0, i2s1_data1, i2s1_sck, i2s1_ws,
+ ibi_i3c, jitter_bist, mdp_vsync, mdp_vsync0_out,
+ mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2,
+ pcie0_clk_req_n, pcie1_clk_req_n, phase_flag,
+ pll_bist_sync, pll_clk_aux, prng_rosc0, prng_rosc1,
+ prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio,
+ qlink0_enable, qlink0_request, qlink0_wmss,
+ qlink1_enable, qlink1_request, qlink1_wmss,
+ qlink2_enable, qlink2_request, qlink2_wmss,
+ qspi0, qspi1, qspi2, qspi3, qspi_clk, qspi_cs,
+ qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4,
+ qup1_se5, qup1_se6, qup1_se7, qup2_se0,
+ qup2_se0_l0_mira, qup2_se0_l0_mirb, qup2_se0_l1_mira,
+ qup2_se0_l1_mirb, qup2_se0_l2_mira, qup2_se0_l2_mirb,
+ qup2_se0_l3_mira, qup2_se0_l3_mirb, qup2_se1,
+ qup2_se2, qup2_se3, qup2_se4, qup2_se5, qup2_se6,
+ qup2_se7, sd_write_protect, sdc40, sdc41, sdc42,
+ sdc43, sdc4_clk, sdc4_cmd, tb_trig_sdc2, tb_trig_sdc4,
+ tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout,
+ tgu_ch3_trigout, tmess_prng0, tmess_prng1, tmess_prng2,
+ tmess_prng3, tsense_pwm1, tsense_pwm2, tsense_pwm3,
+ uim0_clk, uim0_data, uim0_present, uim0_reset,
+ uim1_clk, uim1_data, uim1_present, uim1_reset,
+ usb1_hs, usb_phy, vfr_0, vfr_1, vsense_trigger_mirnat ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sm8550-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 211>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio26";
+ function = "qup2_se7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio27";
+ function = "qup2_se7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..74df912e60ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8650 SoC LPASS LPI TLMM
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SM8650 SoC.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,sm8650-lpass-lpi-pinctrl
+ - items:
+ - const: qcom,sm8750-lpass-lpi-pinctrl
+ - const: qcom,sm8650-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+
+ clocks:
+ items:
+ - description: LPASS Core voting clock
+ - description: LPASS Audio voting clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: audio
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8650-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8650-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8650-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-2])$"
+
+ function:
+ enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk,
+ dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b,
+ ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk,
+ i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk,
+ i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, i2s4_clk,
+ i2s4_data, i2s4_ws, qca_swr_clk, qca_swr_data, slimbus_clk,
+ slimbus_data, swr_rx_clk, swr_rx_data, swr_tx_clk, swr_tx_data,
+ wsa_swr_clk, wsa_swr_data, wsa2_swr_clk, wsa2_swr_data ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+
+ lpass_tlmm: pinctrl@6e80000 {
+ compatible = "qcom,sm8650-lpass-lpi-pinctrl";
+ reg = <0x06e80000 0x20000>;
+
+ clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 23>;
+
+ tx-swr-sleep-clk-state {
+ pins = "gpio0";
+ function = "swr_tx_clk";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-tlmm.yaml
new file mode 100644
index 000000000000..c0a06abf851d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-tlmm.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8650-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8650 TLMM block
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8650 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8650-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 105
+
+ gpio-line-names:
+ maxItems: 210
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8650-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8650-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8650-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0,
+ audio_ext_mclk1, audio_ref_clk, cam_aon_mclk2, cam_aon_mclk4,
+ cam_mclk, cci_async_in, cci_i2c_scl, cci_i2c_sda, cci_timer,
+ cmu_rng, coex_uart1_rx, coex_uart1_tx, coex_uart2_rx,
+ coex_uart2_tx, cri_trng, dbg_out_clk, ddr_bist_complete,
+ ddr_bist_fail, ddr_bist_start, ddr_bist_stop, ddr_pxi0,
+ ddr_pxi1, ddr_pxi2, ddr_pxi3, do_not, dp_hot, gcc_gp1,
+ gcc_gp2, gcc_gp3, gnss_adc0, gnss_adc1, i2chub0_se0,
+ i2chub0_se1, i2chub0_se2, i2chub0_se3, i2chub0_se4,
+ i2chub0_se5, i2chub0_se6, i2chub0_se7, i2chub0_se8,
+ i2chub0_se9, i2s0_data0, i2s0_data1, i2s0_sck, i2s0_ws,
+ i2s1_data0, i2s1_data1, i2s1_sck, i2s1_ws, ibi_i3c,
+ jitter_bist, mdp_vsync, mdp_vsync0_out, mdp_vsync1_out,
+ mdp_vsync2_out, mdp_vsync3_out, mdp_vsync_e, nav_gpio0,
+ nav_gpio1, nav_gpio2, nav_gpio3, pcie0_clk_req_n,
+ pcie1_clk_req_n, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio, qlink_big_enable, qlink_big_request,
+ qlink_little_enable, qlink_little_request, qlink_wmss,
+ qspi0, qspi1, qspi2, qspi3, qspi_clk, qspi_cs, qup1_se0,
+ qup1_se1, qup1_se2, qup1_se3, qup1_se4, qup1_se5, qup1_se6,
+ qup1_se7, qup2_se0, qup2_se1, qup2_se2, qup2_se3, qup2_se4,
+ qup2_se5, qup2_se6, qup2_se7, sd_write_protect, sdc40, sdc41,
+ sdc42, sdc43, sdc4_clk, sdc4_cmd, tb_trig_sdc2, tb_trig_sdc4,
+ tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout,
+ tgu_ch3_trigout, tmess_prng0, tmess_prng1, tmess_prng2,
+ tmess_prng3, tsense_pwm1, tsense_pwm2, tsense_pwm3, uim0_clk,
+ uim0_data, uim0_present, uim0_reset, uim1_clk, uim1_data,
+ uim1_present, uim1_reset, usb1_hs, usb_phy, vfr_0, vfr_1,
+ vsense_trigger_mirnat ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sm8650-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 211>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio60";
+ function = "qup1_se7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio61";
+ function = "qup1_se7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8750-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8750-tlmm.yaml
new file mode 100644
index 000000000000..7aecc97745a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8750-tlmm.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sm8750-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. SM8750 TLMM block
+
+maintainers:
+ - Melody Olvera <quic_molvera@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm SM8750 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,sm8750-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 108
+
+ gpio-line-names:
+ maxItems: 215
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sm8750-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sm8750-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sm8750-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9]|21[0-4])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0,
+ audio_ext_mclk1, audio_ref_clk, cam_aon_mclk2, cam_aon_mclk4,
+ cam_mclk, cci_async_in, cci_i2c_scl, cci_i2c_sda, cci_timer,
+ cmu_rng, coex_uart1_rx, coex_uart1_tx, coex_uart2_rx,
+ coex_uart2_tx, dbg_out_clk, ddr_bist_complete, ddr_bist_fail,
+ ddr_bist_start, ddr_bist_stop, ddr_pxi0, ddr_pxi1, ddr_pxi2,
+ ddr_pxi3, dp_hot, egpio, gcc_gp1, gcc_gp2, gcc_gp3, gnss_adc0,
+ gnss_adc1, i2chub0_se0, i2chub0_se1, i2chub0_se2, i2chub0_se3,
+ i2chub0_se4, i2chub0_se5, i2chub0_se6, i2chub0_se7, i2chub0_se8,
+ i2chub0_se9, i2s0_data0, i2s0_data1, i2s0_sck, i2s0_ws,
+ i2s1_data0, i2s1_data1, i2s1_sck, i2s1_ws, ibi_i3c, jitter_bist,
+ mdp_esync0_out, mdp_esync1_out, mdp_vsync, mdp_vsync0_out,
+ mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out, mdp_vsync5_out,
+ mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2, nav_gpio3,
+ pcie0_clk_req_n, phase_flag, pll_bist_sync, pll_clk_aux,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qlink_big_enable, qlink_big_request, qlink_little_enable,
+ qlink_little_request, qlink_wmss, qspi0, qspi1, qspi2, qspi3,
+ qspi_clk, qspi_cs, qup1_se0, qup1_se1, qup1_se2, qup1_se3,
+ qup1_se4, qup1_se5, qup1_se6, qup1_se7, qup2_se0, qup2_se1,
+ qup2_se2, qup2_se3, qup2_se4, qup2_se5, qup2_se6, qup2_se7,
+ sd_write_protect, sdc40, sdc41, sdc42, sdc43, sdc4_clk,
+ sdc4_cmd, tb_trig_sdc2, tb_trig_sdc4, tmess_prng0, tmess_prng1,
+ tmess_prng2, tmess_prng3, tsense_pwm1, tsense_pwm2, tsense_pwm3,
+ tsense_pwm4, uim0_clk, uim0_data, uim0_present, uim0_reset,
+ uim1_clk, uim1_data, uim1_present, uim1_reset, usb1_hs, usb_phy,
+ vfr_0, vfr_1, vsense_trigger_mirnat, wcn_sw, wcn_sw_ctrl ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,sm8750-tlmm";
+ reg = <0x0f100000 0x300000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 216>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio60";
+ function = "qup1_se7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio61";
+ function = "qup1_se7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml
index c88c8dcb69d9..aae3dcf6cac8 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml
@@ -16,8 +16,9 @@ description:
properties:
interrupts:
description:
- Specifies the TLMM summary IRQ
- maxItems: 1
+ TLMM summary IRQ and dirconn interrupts.
+ minItems: 1
+ maxItems: 9
interrupt-controller: true
@@ -51,7 +52,7 @@ properties:
information.
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- interrupts
@@ -65,10 +66,6 @@ additionalProperties: true
$defs:
qcom-tlmm-state:
- allOf:
- - $ref: pincfg-node.yaml#
- - $ref: pinmux-node.yaml#
-
properties:
drive-strength:
enum: [2, 4, 6, 8, 10, 12, 14, 16]
@@ -78,9 +75,27 @@ $defs:
bias-pull-down: true
bias-pull-up: true
bias-disable: true
- input-enable: true
+ input-enable: false
+ output-disable: true
+ output-enable: true
output-high: true
output-low: true
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ - if:
+ properties:
+ pins:
+ items:
+ pattern: "^gpio"
+ then:
+ required:
+ - function
+ else:
+ properties:
+ function: false
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,x1e80100-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,x1e80100-tlmm.yaml
new file mode 100644
index 000000000000..a1333e0743a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,x1e80100-tlmm.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,x1e80100-tlmm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. X1E80100 TLMM block
+
+maintainers:
+ - Rajendra Nayak <quic_rjendra@quicinc.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in Qualcomm X1E80100 SoC.
+
+allOf:
+ - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,x1e80100-tlmm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 119
+
+ gpio-line-names:
+ maxItems: 238
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-x1e80100-tlmm-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-x1e80100-tlmm-state"
+ additionalProperties: false
+
+$defs:
+ qcom-x1e80100-tlmm-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ oneOf:
+ - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-2][0-9]|23[0-7])$"
+ - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ]
+ minItems: 1
+ maxItems: 36
+
+ function:
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+ enum: [ aon_cci, aoss_cti, atest_char, atest_char0,
+ atest_char1, atest_char2, atest_char3, atest_usb,
+ audio_ext, audio_ref, cam_aon, cam_mclk, cci_async,
+ cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3,
+ cci_timer4, cmu_rng0, cmu_rng1, cmu_rng2, cmu_rng3,
+ cri_trng, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1,
+ ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5, ddr_pxi6, ddr_pxi7,
+ edp0_hot, edp0_lcd, edp1_hot, edp1_lcd, eusb0_ac, eusb1_ac,
+ eusb2_ac, eusb3_ac, eusb5_ac, eusb6_ac, gcc_gp1, gcc_gp2,
+ gcc_gp3, gpio, i2s0_data0, i2s0_data1, i2s0_sck, i2s0_ws, i2s1_data0,
+ i2s1_data1, i2s1_sck, i2s1_ws, ibi_i3c, jitter_bist, mdp_vsync0,
+ mdp_vsync1, mdp_vsync2, mdp_vsync3, mdp_vsync4, mdp_vsync5,
+ mdp_vsync6, mdp_vsync7, mdp_vsync8, pcie3_clk, pcie4_clk,
+ pcie5_clk, pcie6a_clk, pcie6b_clk, phase_flag, pll_bist, pll_clk,
+ prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, qdss_cti,
+ qdss_gpio, qspi00, qspi01, qspi02, qspi03, qspi0_clk, qspi0_cs0,
+ qspi0_cs1, qup0_se0, qup0_se1, qup0_se2, qup0_se3, qup0_se4,
+ qup0_se5, qup0_se6, qup0_se7, qup1_se0, qup1_se1, qup1_se2, qup1_se3,
+ qup1_se4, qup1_se5, qup1_se6, qup1_se7, qup2_se0, qup2_se1, qup2_se2,
+ qup2_se3, qup2_se4, qup2_se5, qup2_se6, qup2_se7, sd_write, sdc4_clk,
+ sdc4_cmd, sdc4_data0, sdc4_data1, sdc4_data2, sdc4_data3, sys_throttle,
+ tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tgu_ch4, tgu_ch5,
+ tgu_ch6, tgu_ch7, tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3,
+ tsense_pwm1, tsense_pwm2, sense_pwm3, tsense_pwm4, usb0_dp, usb0_phy,
+ usb0_sbrx, usb0_sbtx, usb1_dp, usb1_phy, usb1_sbrx, usb1_sbtx,
+ usb2_dp, usb2_phy, usb2_sbrx, usb2_sbtx, vsense_trigger ]
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ tlmm: pinctrl@f100000 {
+ compatible = "qcom,x1e80100-tlmm";
+ reg = <0x0f100000 0xf00000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&tlmm 0 0 239>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+
+ gpio-wo-state {
+ pins = "gpio1";
+ function = "gpio";
+ };
+
+ uart-w-state {
+ rx-pins {
+ pins = "gpio26";
+ function = "qup2_se7";
+ bias-pull-up;
+ };
+
+ tx-pins {
+ pins = "gpio27";
+ function = "qup2_se7";
+ bias-disable;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml
deleted file mode 100644
index 6f17f3991640..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml
+++ /dev/null
@@ -1,97 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/ralink,mt7620-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Ralink MT7620 Pin Controller
-
-maintainers:
- - Arınç ÜNAL <arinc.unal@arinc9.com>
- - Sergio Paracuellos <sergio.paracuellos@gmail.com>
-
-description:
- Ralink MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs.
- The pin controller can only set the muxing of pin groups. Muxing individual
- pins is not supported. There is no pinconf support.
-
-properties:
- compatible:
- const: ralink,mt7620-pinctrl
-
-patternProperties:
- '-pins$':
- type: object
- patternProperties:
- '^(.*-)?pinmux$':
- type: object
- description: node for pinctrl.
- $ref: pinmux-node.yaml#
-
- properties:
- groups:
- description: The pin group to select.
- enum: [
- # common
- i2c, spi, wdt,
-
- # For MT7620 SoC
- ephy, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, spi refclk,
- uartf, uartlite, wled,
-
- # For MT7628 and MT7688 SoCs
- gpio, i2s, p0led_an, p0led_kn, p1led_an, p1led_kn, p2led_an,
- p2led_kn, p3led_an, p3led_kn, p4led_an, p4led_kn, perst, pwm0,
- pwm1, refclk, sdmode, spi cs1, spis, uart0, uart1, uart2,
- wled_an, wled_kn,
- ]
-
- function:
- description: The mux function to select.
- enum: [
- # common
- gpio, i2c, refclk, spi,
-
- # For MT7620 SoC
- ephy, gpio i2s, gpio uartf, i2s uartf, mdio, nand, pa,
- pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf,
- rgmii1, rgmii2, sd, spi refclk, uartf, uartlite, wdt refclk,
- wdt rst, wled,
-
- # For MT7628 and MT7688 SoCs
- antenna, debug, i2s, jtag, p0led_an, p0led_kn,
- p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn,
- p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, pwm_uart2,
- rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, spi cs1,
- spis, sw_r, uart0, uart1, uart2, utif, wdt, wled_an, wled_kn, -,
- ]
-
- required:
- - groups
- - function
-
- additionalProperties: false
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- pinctrl {
- compatible = "ralink,mt7620-pinctrl";
-
- i2c_pins: i2c0-pins {
- pinmux {
- groups = "i2c";
- function = "i2c";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml
deleted file mode 100644
index 61e5c847e8c8..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/ralink,mt7621-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Ralink MT7621 Pin Controller
-
-maintainers:
- - Arınç ÜNAL <arinc.unal@arinc9.com>
- - Sergio Paracuellos <sergio.paracuellos@gmail.com>
-
-description:
- Ralink MT7621 pin controller for MT7621 SoC.
- The pin controller can only set the muxing of pin groups. Muxing individual
- pins is not supported. There is no pinconf support.
-
-properties:
- compatible:
- const: ralink,mt7621-pinctrl
-
-patternProperties:
- '-pins$':
- type: object
- patternProperties:
- '^(.*-)?pinmux$':
- type: object
- description: node for pinctrl.
- $ref: pinmux-node.yaml#
-
- properties:
- groups:
- description: The pin group to select.
- enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, uart1,
- uart2, uart3, wdt]
-
- function:
- description: The mux function to select.
- enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk,
- pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, spi,
- uart1, uart2, uart3, wdt refclk, wdt rst]
-
- required:
- - groups
- - function
-
- additionalProperties: false
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
-
-additionalProperties: false
-
-examples:
- # Pinmux controller node
- - |
- pinctrl {
- compatible = "ralink,mt7621-pinctrl";
-
- i2c_pins: i2c0-pins {
- pinmux {
- groups = "i2c";
- function = "i2c";
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml
index 56e5becabcfd..43b33dbf115b 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml
@@ -10,7 +10,7 @@ maintainers:
- Arınç ÜNAL <arinc.unal@arinc9.com>
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
-description:
+description: |
Ralink RT2880 pin controller for RT2880 SoC.
The pin controller can only set the muxing of pin groups. Muxing individual
pins is not supported. There is no pinconf support.
@@ -22,31 +22,105 @@ properties:
patternProperties:
'-pins$':
type: object
+ additionalProperties: false
+
patternProperties:
'^(.*-)?pinmux$':
type: object
description: node for pinctrl.
$ref: pinmux-node.yaml#
+ additionalProperties: false
properties:
- groups:
- description: The pin group to select.
- enum: [i2c, spi, uartlite, jtag, mdio, sdram, pci]
-
function:
- description: The mux function to select.
+ description:
+ A string containing the name of the function to mux to the group.
enum: [gpio, i2c, spi, uartlite, jtag, mdio, sdram, pci]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
required:
- groups
- function
- additionalProperties: false
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, spi, uartlite, jtag, mdio, sdram, pci]
- additionalProperties: false
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: sdram
+ then:
+ properties:
+ groups:
+ enum: [sdram]
+
+ - if:
+ properties:
+ function:
+ const: pci
+ then:
+ properties:
+ groups:
+ enum: [pci]
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -54,7 +128,6 @@ required:
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,rt2880-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
index f602a5d6e13a..95a904273009 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
@@ -10,9 +10,8 @@ maintainers:
- Arınç ÜNAL <arinc.unal@arinc9.com>
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
-description:
- Ralink RT305X pin controller for RT3050, RT3052, RT3350, RT3352 and RT5350
- SoCs.
+description: |
+ Ralink RT305X pin controller for RT3050, RT3052, and RT3350 SoCs.
The pin controller can only set the muxing of pin groups. Muxing individual
pins is not supported. There is no pinconf support.
@@ -23,51 +22,170 @@ properties:
patternProperties:
'-pins$':
type: object
+ additionalProperties: false
+
patternProperties:
'^(.*-)?pinmux$':
type: object
description: node for pinctrl.
$ref: pinmux-node.yaml#
+ additionalProperties: false
properties:
- groups:
- description: The pin group to select.
- enum: [
- # common
- i2c, jtag, led, mdio, rgmii, spi, spi_cs1, uartf, uartlite,
-
- # For RT3050, RT3052 and RT3350 SoCs
- sdram,
-
- # For RT3352 SoC
- lna, pa
- ]
-
function:
- description: The mux function to select.
- enum: [
- # common
- gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, mdio,
- pcm gpio, pcm i2s, pcm uartf, rgmii, spi, spi_cs1, uartf,
- uartlite, wdg_cs1,
-
- # For RT3050, RT3052 and RT3350 SoCs
- sdram,
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, mdio,
+ pcm gpio, pcm i2s, pcm uartf, rgmii, sdram, spi, uartf,
+ uartlite]
- # For RT3352 SoC
- lna, pa
- ]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
required:
- groups
- function
- additionalProperties: false
-
- additionalProperties: false
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, jtag, mdio, rgmii, sdram, spi, uartf, uartlite]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: rgmii
+ then:
+ properties:
+ groups:
+ enum: [rgmii]
+
+ - if:
+ properties:
+ function:
+ const: sdram
+ then:
+ properties:
+ groups:
+ enum: [sdram]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -75,7 +193,6 @@ required:
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,rt305x-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml
new file mode 100644
index 000000000000..c9bc6cfd834c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml
@@ -0,0 +1,243 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/ralink,rt3352-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink RT3352 Pin Controller
+
+maintainers:
+ - Arınç ÜNAL <arinc.unal@arinc9.com>
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ Ralink RT3352 pin controller for RT3352 SoC.
+ The pin controller can only set the muxing of pin groups. Muxing individual
+ pins is not supported. There is no pinconf support.
+
+properties:
+ compatible:
+ const: ralink,rt3352-pinctrl
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^(.*-)?pinmux$':
+ type: object
+ description: node for pinctrl.
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, lna,
+ mdio, pa, pcm gpio, pcm i2s, pcm uartf, rgmii, spi, spi_cs1,
+ uartf, uartlite, wdg_cs1]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
+ required:
+ - groups
+ - function
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, jtag, led, lna, mdio, pa, rgmii, spi, spi_cs1,
+ uartf, uartlite]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: led
+ then:
+ properties:
+ groups:
+ enum: [led]
+
+ - if:
+ properties:
+ function:
+ const: lna
+ then:
+ properties:
+ groups:
+ enum: [lna]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: pa
+ then:
+ properties:
+ groups:
+ enum: [pa]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: rgmii
+ then:
+ properties:
+ groups:
+ enum: [rgmii]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: spi_cs1
+ then:
+ properties:
+ groups:
+ enum: [spi_cs1]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: wdg_cs1
+ then:
+ properties:
+ groups:
+ enum: [spi_cs1]
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "ralink,rt3352-pinctrl";
+
+ i2c_pins: i2c0-pins {
+ pinmux {
+ groups = "i2c";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml
index feb6e66dcb61..8d14e525b25e 100644
--- a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml
@@ -10,7 +10,7 @@ maintainers:
- Arınç ÜNAL <arinc.unal@arinc9.com>
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
-description:
+description: |
Ralink RT3883 pin controller for RT3883 SoC.
The pin controller can only set the muxing of pin groups. Muxing individual
pins is not supported. There is no pinconf support.
@@ -22,34 +22,225 @@ properties:
patternProperties:
'-pins$':
type: object
+ additionalProperties: false
+
patternProperties:
'^(.*-)?pinmux$':
type: object
description: node for pinctrl.
$ref: pinmux-node.yaml#
+ additionalProperties: false
properties:
- groups:
- description: The pin group to select.
- enum: [ge1, ge2, i2c, jtag, lna a, lna g, mdio, pci, spi, uartf,
- uartlite]
-
function:
- description: The mux function to select.
+ description:
+ A string containing the name of the function to mux to the group.
enum: [ge1, ge2, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag,
lna a, lna g, mdio, pci-dev, pci-fnc, pci-host1, pci-host2,
pcm gpio, pcm i2s, pcm uartf, spi, uartf, uartlite]
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
required:
- groups
- function
- additionalProperties: false
+ allOf:
+ - if:
+ properties:
+ function:
+ const: ge1
+ then:
+ properties:
+ groups:
+ enum: [ge1]
- additionalProperties: false
+ - if:
+ properties:
+ function:
+ const: ge2
+ then:
+ properties:
+ groups:
+ enum: [ge2]
+
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [ge1, ge2, i2c, jtag, lna a, lna g, mdio, pci, spi,
+ uartf, uartlite]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: lna a
+ then:
+ properties:
+ groups:
+ enum: [lna a]
+
+ - if:
+ properties:
+ function:
+ const: lna g
+ then:
+ properties:
+ groups:
+ enum: [lna g]
+
+ - if:
+ properties:
+ function:
+ const: mdio
+ then:
+ properties:
+ groups:
+ enum: [mdio]
+
+ - if:
+ properties:
+ function:
+ const: pci-dev
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pci-fnc
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pci-host1
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pci-host2
+ then:
+ properties:
+ groups:
+ enum: [pci]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -57,7 +248,6 @@ required:
additionalProperties: false
examples:
- # Pinmux controller node
- |
pinctrl {
compatible = "ralink,rt3883-pinctrl";
diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml
new file mode 100644
index 000000000000..f248202ce866
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml
@@ -0,0 +1,206 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/ralink,rt5350-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink RT5350 Pin Controller
+
+maintainers:
+ - Arınç ÜNAL <arinc.unal@arinc9.com>
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+description: |
+ Ralink RT5350 pin controller for RT5350 SoC.
+ The pin controller can only set the muxing of pin groups. Muxing individual
+ pins is not supported. There is no pinconf support.
+
+properties:
+ compatible:
+ const: ralink,rt5350-pinctrl
+
+patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '^(.*-)?pinmux$':
+ type: object
+ description: node for pinctrl.
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ function:
+ description:
+ A string containing the name of the function to mux to the group.
+ enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led,
+ pcm gpio, pcm i2s, pcm uartf, spi, spi_cs1, uartf, uartlite,
+ wdg_cs1]
+
+ groups:
+ description:
+ An array of strings. Each string contains the name of a group.
+ maxItems: 1
+
+ required:
+ - groups
+ - function
+
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ groups:
+ enum: [i2c, jtag, led, spi, spi_cs1, uartf, uartlite]
+
+ - if:
+ properties:
+ function:
+ const: gpio i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: gpio uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: i2c
+ then:
+ properties:
+ groups:
+ enum: [i2c]
+
+ - if:
+ properties:
+ function:
+ const: i2s uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: jtag
+ then:
+ properties:
+ groups:
+ enum: [jtag]
+
+ - if:
+ properties:
+ function:
+ const: led
+ then:
+ properties:
+ groups:
+ enum: [led]
+
+ - if:
+ properties:
+ function:
+ const: pcm gpio
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm i2s
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: pcm uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: spi
+ then:
+ properties:
+ groups:
+ enum: [spi]
+
+ - if:
+ properties:
+ function:
+ const: spi_cs1
+ then:
+ properties:
+ groups:
+ enum: [spi_cs1]
+
+ - if:
+ properties:
+ function:
+ const: uartf
+ then:
+ properties:
+ groups:
+ enum: [uartf]
+
+ - if:
+ properties:
+ function:
+ const: uartlite
+ then:
+ properties:
+ groups:
+ enum: [uartlite]
+
+ - if:
+ properties:
+ function:
+ const: wdg_cs1
+ then:
+ properties:
+ groups:
+ enum: [spi_cs1]
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl {
+ compatible = "ralink,rt5350-pinctrl";
+
+ i2c_pins: i2c0-pins {
+ pinmux {
+ groups = "i2c";
+ function = "i2c";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/raspberrypi,rp1-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/raspberrypi,rp1-gpio.yaml
new file mode 100644
index 000000000000..af6fbbd4feea
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/raspberrypi,rp1-gpio.yaml
@@ -0,0 +1,231 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/raspberrypi,rp1-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RaspberryPi RP1 GPIO/Pinconf/Pinmux Controller submodule
+
+maintainers:
+ - A. della Porta <andrea.porta@suse.com>
+
+description:
+ The RP1 chipset is a Multi Function Device containing, among other
+ sub-peripherals, a gpio/pinconf/mux controller whose 54 pins are grouped
+ into 3 banks.
+ It works also as an interrupt controller for those gpios.
+
+properties:
+ compatible:
+ const: raspberrypi,rp1-gpio
+
+ reg:
+ maxItems: 3
+ description: One reg specifier for each one of the 3 pin banks.
+
+ '#gpio-cells':
+ description: The first cell is the pin number and the second cell is used
+ to specify the flags (see include/dt-bindings/gpio/gpio.h).
+ const: 2
+
+ gpio-controller: true
+
+ gpio-ranges:
+ maxItems: 1
+
+ gpio-line-names:
+ maxItems: 54
+
+ interrupts:
+ maxItems: 3
+ description: One interrupt specifier for each one of the 3 pin banks.
+
+ '#interrupt-cells':
+ description:
+ Specifies the Bank number [0, 1, 2] and Flags as defined in
+ include/dt-bindings/interrupt-controller/irq.h.
+ const: 2
+
+ interrupt-controller: true
+
+patternProperties:
+ '-state$':
+ oneOf:
+ - $ref: '#/$defs/raspberrypi-rp1-state'
+ - patternProperties:
+ '-pins$':
+ $ref: '#/$defs/raspberrypi-rp1-state'
+ additionalProperties: false
+
+$defs:
+ raspberrypi-rp1-state:
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ description:
+ Pin controller client devices use pin configuration subnodes (children
+ and grandchildren) for desired pin configuration.
+ Client device subnodes use below standard properties.
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode (either this or "groups" must be specified).
+ items:
+ pattern: '^gpio([0-9]|[1-4][0-9]|5[0-3])$'
+
+ groups:
+ description:
+ List of groups affected by the properties specified in this
+ subnode (either this or "pins" must be specified).
+ items:
+ anyOf:
+ - pattern: '^gpio([0-9]|[1-4][0-9]|5[0-3])$'
+ - enum: [ uart0, uart0_ctrl, uart1, uart1_ctrl, uart2, uart2_ctrl,
+ uart3, uart3_ctrl, uart4, uart4_ctrl, uart5_0,
+ uart5_0_ctrl, uart5_1, uart5_1_ctrl, uart5_2,
+ uart5_2_ctrl, uart5_3,
+ sd0, sd1,
+ i2s0, i2s0_dual, i2s0_quad, i2s1, i2s1_dual, i2s1_quad,
+ i2s2_0, i2s2_0_dual, i2s2_1, i2s2_1_dual,
+ i2c4_0, i2c4_1, i2c4_2, i2c4_3, i2c6_0, i2c6_1, i2c5_0,
+ i2c5_1, i2c5_2, i2c5_3, i2c0_0, i2c0_1, i2c1_0, i2c1_1,
+ i2c2_0, i2c2_1, i2c3_0, i2c3_1, i2c3_2,
+ dpi_16bit, dpi_16bit_cpadhi, dpi_16bit_pad666,
+ dpi_18bit, dpi_18bit_cpadhi, dpi_24bit,
+ spi0, spi0_quad, spi1, spi2, spi3, spi4, spi5, spi6_0,
+ spi6_1, spi7_0, spi7_1, spi8_0, spi8_1,
+ aaud_0, aaud_1, aaud_2, aaud_3, aaud_4,
+ vbus0_0, vbus0_1, vbus1, vbus2, vbus3,
+ mic_0, mic_1, mic_2, mic_3,
+ ir ]
+
+ function:
+ enum: [ alt0, alt1, alt2, alt3, alt4, gpio, alt6, alt7, alt8, none,
+ aaud, dcd0, dpi, dsi0_te_ext, dsi1_te_ext, dsr0, dtr0, gpclk0,
+ gpclk1, gpclk2, gpclk3, gpclk4, gpclk5, i2c0, i2c1, i2c2, i2c3,
+ i2c4, i2c5, i2c6, i2s0, i2s1, i2s2, ir, mic, pcie_clkreq_n,
+ pio, proc_rio, pwm0, pwm1, ri0, sd0, sd1, spi0, spi1, spi2,
+ spi3, spi4, spi5, spi6, spi7, spi8, uart0, uart1, uart2, uart3,
+ uart4, uart5, vbus0, vbus1, vbus2, vbus3 ]
+
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ input-enable: true
+ input-schmitt-enable: true
+ output-enable: true
+ output-high: true
+ output-low: true
+ slew-rate:
+ description: 0 is slow slew rate, 1 is fast slew rate
+ enum: [ 0, 1 ]
+ drive-strength:
+ enum: [ 2, 4, 8, 12 ]
+
+ required:
+ - function
+
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - reg
+ - compatible
+ - '#gpio-cells'
+ - gpio-controller
+ - interrupts
+ - '#interrupt-cells'
+ - interrupt-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rp1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ rp1_gpio: pinctrl@c0400d0000 {
+ reg = <0xc0 0x400d0000 0x0 0xc000>,
+ <0xc0 0x400e0000 0x0 0xc000>,
+ <0xc0 0x400f0000 0x0 0xc000>;
+ compatible = "raspberrypi,rp1-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>,
+ <1 IRQ_TYPE_LEVEL_HIGH>,
+ <2 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-line-names =
+ "ID_SDA", // GPIO0
+ "ID_SCL", // GPIO1
+ "GPIO2", "GPIO3", "GPIO4", "GPIO5", "GPIO6",
+ "GPIO7", "GPIO8", "GPIO9", "GPIO10", "GPIO11",
+ "GPIO12", "GPIO13", "GPIO14", "GPIO15", "GPIO16",
+ "GPIO17", "GPIO18", "GPIO19", "GPIO20", "GPIO21",
+ "GPIO22", "GPIO23", "GPIO24", "GPIO25", "GPIO26",
+ "GPIO27",
+ "PCIE_RP1_WAKE", // GPIO28
+ "FAN_TACH", // GPIO29
+ "HOST_SDA", // GPIO30
+ "HOST_SCL", // GPIO31
+ "ETH_RST_N", // GPIO32
+ "", // GPIO33
+ "CD0_IO0_MICCLK", // GPIO34
+ "CD0_IO0_MICDAT0", // GPIO35
+ "RP1_PCIE_CLKREQ_N", // GPIO36
+ "", // GPIO37
+ "CD0_SDA", // GPIO38
+ "CD0_SCL", // GPIO39
+ "CD1_SDA", // GPIO40
+ "CD1_SCL", // GPIO41
+ "USB_VBUS_EN", // GPIO42
+ "USB_OC_N", // GPIO43
+ "RP1_STAT_LED", // GPIO44
+ "FAN_PWM", // GPIO45
+ "CD1_IO0_MICCLK", // GPIO46
+ "2712_WAKE", // GPIO47
+ "CD1_IO1_MICDAT1", // GPIO48
+ "EN_MAX_USB_CUR", // GPIO49
+ "", // GPIO50
+ "", // GPIO51
+ "", // GPIO52
+ ""; // GPIO53
+
+ rp1-i2s0-default-state {
+ function = "i2s0";
+ pins = "gpio18", "gpio19", "gpio20", "gpio21";
+ bias-disable;
+ };
+
+ rp1-uart0-default-state {
+ txd-pins {
+ function = "uart0";
+ pins = "gpio14";
+ bias-disable;
+ };
+
+ rxd-pins {
+ function = "uart0";
+ pins = "gpio15";
+ bias-pull-up;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml
new file mode 100644
index 000000000000..90bd49d87d2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml
@@ -0,0 +1,188 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/realtek,rtd1315e-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1315E Pin Controller
+
+maintainers:
+ - TY Chang <tychang@realtek.com>
+
+description:
+ The Realtek DHC RTD1315E is a high-definition media processor SoC. The
+ RTD1315E pin controller is used to control pin function, pull up/down
+ resistor, drive strength, schmitt trigger and power source.
+
+properties:
+ compatible:
+ const: realtek,rtd1315e-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pins:
+ items:
+ enum: [ gpio_0, gpio_1, emmc_rst_n, emmc_dd_sb, emmc_clk, emmc_cmd,
+ gpio_6, gpio_7, gpio_8, gpio_9, gpio_10, gpio_11, gpio_12,
+ gpio_13, gpio_14, gpio_15, gpio_16, gpio_17, gpio_18, gpio_19,
+ gpio_20, emmc_data_0, emmc_data_1, emmc_data_2, usb_cc2, gpio_25,
+ gpio_26, gpio_27, gpio_28, gpio_29, gpio_30, gpio_31, gpio_32,
+ gpio_33, gpio_34, gpio_35, hif_data, hif_en, hif_rdy, hif_clk,
+ gpio_dummy_40, gpio_dummy_41, gpio_dummy_42, gpio_dummy_43,
+ gpio_dummy_44, gpio_dummy_45, gpio_46, gpio_47, gpio_48, gpio_49,
+ gpio_50, usb_cc1, emmc_data_3, emmc_data_4, ir_rx, ur0_rx, ur0_tx,
+ gpio_57, gpio_58, gpio_59, gpio_60, gpio_61, gpio_62, gpio_dummy_63,
+ gpio_dummy_64, gpio_dummy_65, gpio_66, gpio_67, gpio_68, gpio_69,
+ gpio_70, gpio_71, gpio_72, gpio_dummy_73, emmc_data_5, emmc_data_6,
+ emmc_data_7, gpio_dummy_77, gpio_78, gpio_79, gpio_80, gpio_81,
+ ur2_loc, gspi_loc, hi_width, sf_en, arm_trace_dbg_en,
+ ejtag_aucpu_loc, ejtag_acpu_loc, ejtag_vcpu_loc, ejtag_scpu_loc,
+ dmic_loc, vtc_dmic_loc, vtc_tdm_loc, vtc_i2si_loc, tdm_ai_loc,
+ ai_loc, spdif_loc, hif_en_loc, scan_switch, wd_rset, boot_sel,
+ reset_n, testmode ]
+
+ function:
+ enum: [ gpio, nf, emmc, ao, gspi_loc0, gspi_loc1, uart0, uart1,
+ uart2_loc0, uart2_loc1, i2c0, i2c1, i2c4, i2c5, pcie1,
+ etn_led, etn_phy, spi, pwm0_loc0, pwm0_loc1, pwm1_loc0,
+ pwm1_loc1, pwm2_loc0, pwm2_loc1, pwm3_loc0, pwm3_loc1,
+ spdif_optical_loc0, spdif_optical_loc1, usb_cc1, usb_cc2,
+ sd, dmic_loc0, dmic_loc1, ai_loc0, ai_loc1, tdm_ai_loc0,
+ tdm_ai_loc1, hi_loc0, hi_m, vtc_i2so, vtc_i2si_loc0,
+ vtc_i2si_loc1, vtc_dmic_loc0, vtc_dmic_loc1, vtc_tdm_loc0,
+ vtc_tdm_loc1, dc_fan, pll_test_loc0, pll_test_loc1,
+ ir_rx, uart2_disable, gspi_disable, hi_width_disable,
+ hi_width_1bit, sf_disable, sf_enable, scpu_ejtag_loc0,
+ scpu_ejtag_loc1, scpu_ejtag_loc2, scpu_ejtag_loc3,
+ acpu_ejtag_loc0, acpu_ejtag_loc1, acpu_ejtag_loc2,
+ vcpu_ejtag_loc0, vcpu_ejtag_loc1, vcpu_ejtag_loc2,
+ aucpu_ejtag_loc0, aucpu_ejtag_loc1, aucpu_ejtag_loc2,
+ gpu_ejtag, iso_tristate, dbg_out0, dbg_out1, standby_dbg,
+ spdif, arm_trace_debug_disable, arm_trace_debug_enable,
+ aucpu_ejtag_disable, acpu_ejtag_disable, vcpu_ejtag_disable,
+ scpu_ejtag_disable, vtc_dmic_loc_disable, vtc_tdm_disable,
+ vtc_i2si_disable, tdm_ai_disable, ai_disable, spdif_disable,
+ hif_disable, hif_enable, test_loop, pmic_pwrup ]
+
+ drive-strength:
+ enum: [4, 8]
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-push-pull: true
+
+ power-source:
+ description: |
+ Valid arguments are described as below:
+ 0: power supply of 1.8V
+ 1: power supply of 3.3V
+ enum: [0, 1]
+
+ realtek,drive-strength-p:
+ description: |
+ Some of pins can be driven using the P-MOS and N-MOS transistor to
+ achieve finer adjustments. The block-diagram representation is as
+ follows:
+ VDD
+ |
+ ||--+
+ +-----o|| P-MOS-FET
+ | ||--+
+ IN --+ +----- out
+ | ||--+
+ +------|| N-MOS-FET
+ ||--+
+ |
+ GND
+ The driving strength of the P-MOS/N-MOS transistors impacts the
+ waveform's rise/fall times. Greater driving strength results in
+ shorter rise/fall times. Each P-MOS and N-MOS transistor offers
+ 8 configurable levels (0 to 7), with higher values indicating
+ greater driving strength, contributing to achieving the desired
+ speed.
+
+ The realtek,drive-strength-p is used to control the driving strength
+ of the P-MOS output.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ realtek,drive-strength-n:
+ description: |
+ Similar to the realtek,drive-strength-p, the realtek,drive-strength-n
+ is used to control the driving strength of the N-MOS output.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ realtek,duty-cycle:
+ description: |
+ An integer describing the level to adjust output duty cycle, controlling
+ the proportion of positive and negative waveforms in nanoseconds.
+ Valid arguments are described as below:
+ 0: 0ns
+ 2: + 0.25ns
+ 3: + 0.5ns
+ 4: -0.25ns
+ 5: -0.5ns
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 2, 3, 4, 5 ]
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@4e000 {
+ compatible = "realtek,rtd1315e-pinctrl";
+ reg = <0x4e000 0x130>;
+
+ emmc-hs200-pins {
+ pins = "emmc_clk",
+ "emmc_cmd",
+ "emmc_data_0",
+ "emmc_data_1",
+ "emmc_data_2",
+ "emmc_data_3",
+ "emmc_data_4",
+ "emmc_data_5",
+ "emmc_data_6",
+ "emmc_data_7";
+ function = "emmc";
+ realtek,drive-strength-p = <0x2>;
+ realtek,drive-strength-n = <0x2>;
+ };
+
+ i2c-0-pins {
+ pins = "gpio_12",
+ "gpio_13";
+ function = "i2c0";
+ drive-strength = <4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml
new file mode 100644
index 000000000000..b6211c8544ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml
@@ -0,0 +1,187 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/realtek,rtd1319d-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1319D Pin Controller
+
+maintainers:
+ - TY Chang <tychang@realtek.com>
+
+description:
+ The Realtek DHC RTD1319D is a high-definition media processor SoC. The
+ RTD1319D pin controller is used to control pin function, pull up/down
+ resistor, drive strength, schmitt trigger and power source.
+
+properties:
+ compatible:
+ const: realtek,rtd1319d-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pins:
+ items:
+ enum: [ gpio_0, gpio_1, gpio_2, gpio_3, gpio_4, gpio_5, gpio_6, gpio_7,
+ gpio_8, gpio_9, gpio_10, gpio_11, gpio_12, gpio_13, gpio_14,
+ gpio_15, gpio_16, gpio_17, gpio_18, gpio_19, gpio_20, gpio_21,
+ gpio_22, gpio_23, usb_cc2, gpio_25, gpio_26, gpio_27, gpio_28,
+ gpio_29, gpio_30, gpio_31, gpio_32, gpio_33, gpio_34, gpio_35,
+ hif_data, hif_en, hif_rdy, hif_clk, gpio_40, gpio_41, gpio_42,
+ gpio_43, gpio_44, gpio_45, gpio_46, gpio_47, gpio_48, gpio_49,
+ gpio_50, usb_cc1, gpio_52, gpio_53, ir_rx, ur0_rx, ur0_tx,
+ gpio_57, gpio_58, gpio_59, gpio_60, gpio_61, gpio_62, gpio_63,
+ gpio_64, emmc_rst_n, emmc_dd_sb, emmc_clk, emmc_cmd, emmc_data_0,
+ emmc_data_1, emmc_data_2, emmc_data_3, emmc_data_4, emmc_data_5,
+ emmc_data_6, emmc_data_7, dummy, gpio_78, gpio_79, gpio_80,
+ gpio_81, ur2_loc, gspi_loc, hi_width, sf_en, arm_trace_dbg_en,
+ ejtag_aucpu_loc, ejtag_acpu_loc, ejtag_vcpu_loc, ejtag_scpu_loc,
+ dmic_loc, ejtag_secpu_loc, vtc_dmic_loc, vtc_tdm_loc, vtc_i2si_loc,
+ tdm_ai_loc, ai_loc, spdif_loc, hif_en_loc, sc0_loc, sc1_loc,
+ scan_switch, wd_rset, boot_sel, reset_n, testmode ]
+
+ function:
+ enum: [ gpio, nf, emmc, tp0, tp1, sc0, sc0_data0, sc0_data1, sc0_data2,
+ sc1, sc1_data0, sc1_data1, sc1_data2, ao, gspi_loc0, gspi_loc1,
+ uart0, uart1, uart2_loc0, uart2_loc1, i2c0, i2c1, i2c3, i2c4,
+ i2c5, pcie1, sdio, etn_led, etn_phy, spi, pwm0_loc0, pwm0_loc1,
+ pwm1_loc0, pwm1_loc1, pwm2_loc0, pwm2_loc1, pwm3_loc0, pwm3_loc1,
+ qam_agc_if0, qam_agc_if1, spdif_optical_loc0, spdif_optical_loc1,
+ usb_cc1, usb_cc2, vfd, sd, dmic_loc0, dmic_loc1, ai_loc0, ai_loc1,
+ tdm_ai_loc0, tdm_ai_loc1, hi_loc0, hi_m, vtc_i2so, vtc_i2si_loc0,
+ vtc_i2si_loc1, vtc_dmic_loc0, vtc_dmic_loc1, vtc_tdm_loc0,
+ vtc_tdm_loc1, dc_fan, pll_test_loc0, pll_test_loc1, ir_rx,
+ uart2_disable, gspi_disable, hi_width_disable, hi_width_1bit,
+ sf_disable, sf_enable, scpu_ejtag_loc0, scpu_ejtag_loc1,
+ scpu_ejtag_loc2, acpu_ejtag_loc0, acpu_ejtag_loc1, acpu_ejtag_loc2,
+ vcpu_ejtag_loc0, vcpu_ejtag_loc1, vcpu_ejtag_loc2, secpu_ejtag_loc0,
+ secpu_ejtag_loc1, secpu_ejtag_loc2, aucpu_ejtag_loc0, aucpu_ejtag_loc1,
+ aucpu_ejtag_loc2, iso_tristate, dbg_out0, dbg_out1, standby_dbg,
+ spdif, arm_trace_debug_disable, arm_trace_debug_enable,
+ aucpu_ejtag_disable, acpu_ejtag_disable, vcpu_ejtag_disable,
+ scpu_ejtag_disable, secpu_ejtag_disable, vtc_dmic_loc_disable,
+ vtc_tdm_disable, vtc_i2si_disable, tdm_ai_disable, ai_disable,
+ spdif_disable, hif_disable, hif_enable, test_loop, pmic_pwrup ]
+
+ drive-strength:
+ enum: [4, 8]
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-push-pull: true
+
+ power-source:
+ description: |
+ Valid arguments are described as below:
+ 0: power supply of 1.8V
+ 1: power supply of 3.3V
+ enum: [0, 1]
+
+ realtek,drive-strength-p:
+ description: |
+ Some of pins can be driven using the P-MOS and N-MOS transistor to
+ achieve finer adjustments. The block-diagram representation is as
+ follows:
+ VDD
+ |
+ ||--+
+ +-----o|| P-MOS-FET
+ | ||--+
+ IN --+ +----- out
+ | ||--+
+ +------|| N-MOS-FET
+ ||--+
+ |
+ GND
+ The driving strength of the P-MOS/N-MOS transistors impacts the
+ waveform's rise/fall times. Greater driving strength results in
+ shorter rise/fall times. Each P-MOS and N-MOS transistor offers
+ 8 configurable levels (0 to 7), with higher values indicating
+ greater driving strength, contributing to achieving the desired
+ speed.
+
+ The realtek,drive-strength-p is used to control the driving strength
+ of the P-MOS output.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ realtek,drive-strength-n:
+ description: |
+ Similar to the realtek,drive-strength-p, the realtek,drive-strength-n
+ is used to control the driving strength of the N-MOS output.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ realtek,duty-cycle:
+ description: |
+ An integer describing the level to adjust output duty cycle, controlling
+ the proportion of positive and negative waveforms in nanoseconds.
+ Valid arguments are described as below:
+ 0: 0ns
+ 2: + 0.25ns
+ 3: + 0.5ns
+ 4: -0.25ns
+ 5: -0.5ns
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 2, 3, 4, 5 ]
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@4e000 {
+ compatible = "realtek,rtd1319d-pinctrl";
+ reg = <0x4e000 0x130>;
+
+ emmc-hs200-pins {
+ pins = "emmc_clk",
+ "emmc_cmd",
+ "emmc_data_0",
+ "emmc_data_1",
+ "emmc_data_2",
+ "emmc_data_3",
+ "emmc_data_4",
+ "emmc_data_5",
+ "emmc_data_6",
+ "emmc_data_7";
+ function = "emmc";
+ realtek,drive-strength-p = <0x2>;
+ realtek,drive-strength-n = <0x2>;
+ };
+
+ i2c-0-pins {
+ pins = "gpio_12",
+ "gpio_13";
+ function = "i2c0";
+ drive-strength = <4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml
new file mode 100644
index 000000000000..e88bc649cc73
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml
@@ -0,0 +1,186 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/realtek,rtd1619b-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1619B Pin Controller
+
+maintainers:
+ - TY Chang <tychang@realtek.com>
+
+description:
+ The Realtek DHC RTD1619B is a high-definition media processor SoC. The
+ RTD1619B pin controller is used to control pin function, pull up/down
+ resistor, drive strength, schmitt trigger and power source.
+
+properties:
+ compatible:
+ const: realtek,rtd1619b-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-pins$':
+ type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pins:
+ items:
+ enum: [ gpio_0, gpio_1, gpio_2, gpio_3, gpio_4, gpio_5, gpio_6, gpio_7,
+ gpio_8, gpio_9, gpio_10, gpio_11, gpio_12, gpio_13, gpio_14,
+ gpio_15, gpio_16, gpio_17, gpio_18, gpio_19, gpio_20, gpio_21,
+ gpio_22, gpio_23, usb_cc2, gpio_25, gpio_26, gpio_27, gpio_28,
+ gpio_29, gpio_30, gpio_31, gpio_32, gpio_33, gpio_34, gpio_35,
+ hif_data, hif_en, hif_rdy, hif_clk, gpio_40, gpio_41, gpio_42,
+ gpio_43, gpio_44, gpio_45, gpio_46, gpio_47, gpio_48, gpio_49,
+ gpio_50, usb_cc1, gpio_52, gpio_53, ir_rx, ur0_rx, ur0_tx,
+ gpio_57, gpio_58, gpio_59, gpio_60, gpio_61, gpio_62, gpio_63,
+ gpio_64, gpio_65, gpio_66, gpio_67, gpio_68, gpio_69, gpio_70,
+ gpio_71, gpio_72, gpio_73, gpio_74, gpio_75, gpio_76, emmc_cmd,
+ spi_ce_n, spi_sck, spi_so, spi_si, emmc_rst_n, emmc_dd_sb,
+ emmc_clk, emmc_data_0, emmc_data_1, emmc_data_2, emmc_data_3,
+ emmc_data_4, emmc_data_5, emmc_data_6, emmc_data_7, ur2_loc,
+ gspi_loc, sdio_loc, hi_loc, hi_width, sf_en, arm_trace_dbg_en,
+ pwm_01_open_drain_en_loc0, pwm_23_open_drain_en_loc0,
+ pwm_01_open_drain_en_loc1, pwm_23_open_drain_en_loc1,
+ ejtag_acpu_loc, ejtag_vcpu_loc, ejtag_scpu_loc, dmic_loc,
+ iso_gspi_loc, ejtag_ve3_loc, ejtag_aucpu0_loc, ejtag_aucpu1_loc ]
+
+ function:
+ enum: [ gpio, nf, nf_spi, spi, pmic, spdif, spdif_coaxial, spdif_optical_loc0,
+ spdif_optical_loc1, emmc_spi, emmc, sc1, uart0, uart1, uart2_loc0, uart2_loc1,
+ gspi_loc1, iso_gspi_loc1, i2c0, i2c1, i2c3, i2c4, i2c5, pwm0, pwm1, pwm2,
+ pwm3, etn_led, etn_phy, etn_clk, sc0, vfd, gspi_loc0, iso_gspi_loc0, pcie1,
+ pcie2, sd, sdio_loc0, sdio_loc1, hi, hi_m, dc_fan, pll_test_loc0, pll_test_loc1,
+ usb_cc1, usb_cc2, ir_rx, tdm_ai_loc0, tdm_ai_loc1, dmic_loc0, dmic_loc1,
+ ai_loc0, ai_loc1, tp0, tp1, ao, uart2_disable, gspi_disable, sdio_disable,
+ hi_loc_disable, hi_loc0, hi_width_disable, hi_width_1bit, vtc_i2si_loc0,
+ vtc_tdm_loc0, vtc_dmic_loc0, vtc_i2si_loc1, vtc_tdm_loc1, vtc_dmic_loc1,
+ vtc_i2so, ve3_ejtag_loc0, aucpu0_ejtag_loc0, aucpu1_ejtag_loc0, ve3_ejtag_loc1,
+ aucpu0_ejtag_loc1, aucpu1_ejtag_loc1, ve3_ejtag_loc2, aucpu0_ejtag_loc2,
+ aucpu1_ejtag_loc2, scpu_ejtag_loc0, acpu_ejtag_loc0, vcpu_ejtag_loc0,
+ scpu_ejtag_loc1, acpu_ejtag_loc1, vcpu_ejtag_loc1, scpu_ejtag_loc2,
+ acpu_ejtag_loc2, vcpu_ejtag_loc2, ve3_ejtag_disable, aucpu0_ejtag_disable,
+ aucpu1_ejtag_disable, acpu_ejtag_disable, vcpu_ejtag_disable,
+ scpu_ejtag_disable, iso_gspi_disable, sf_disable, sf_enable,
+ arm_trace_debug_disable, arm_trace_debug_enable, pwm_normal, pwm_open_drain,
+ standby_dbg, test_loop_dis ]
+
+ drive-strength:
+ enum: [4, 8]
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ bias-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ drive-push-pull: true
+
+ power-source:
+ description: |
+ Valid arguments are described as below:
+ 0: power supply of 1.8V
+ 1: power supply of 3.3V
+ enum: [0, 1]
+
+ realtek,drive-strength-p:
+ description: |
+ Some of pins can be driven using the P-MOS and N-MOS transistor to
+ achieve finer adjustments. The block-diagram representation is as
+ follows:
+ VDD
+ |
+ ||--+
+ +-----o|| P-MOS-FET
+ | ||--+
+ IN --+ +----- out
+ | ||--+
+ +------|| N-MOS-FET
+ ||--+
+ |
+ GND
+ The driving strength of the P-MOS/N-MOS transistors impacts the
+ waveform's rise/fall times. Greater driving strength results in
+ shorter rise/fall times. Each P-MOS and N-MOS transistor offers
+ 8 configurable levels (0 to 7), with higher values indicating
+ greater driving strength, contributing to achieving the desired
+ speed.
+
+ The realtek,drive-strength-p is used to control the driving strength
+ of the P-MOS output.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ realtek,drive-strength-n:
+ description: |
+ Similar to the realtek,drive-strength-p, the realtek,drive-strength-n
+ is used to control the driving strength of the N-MOS output.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ realtek,duty-cycle:
+ description: |
+ An integer describing the level to adjust output duty cycle, controlling
+ the proportion of positive and negative waveforms in nanoseconds.
+ Valid arguments are described as below:
+ 0: 0ns
+ 2: + 0.25ns
+ 3: + 0.5ns
+ 4: -0.25ns
+ 5: -0.5ns
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 2, 3, 4, 5 ]
+
+ required:
+ - pins
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@4e000 {
+ compatible = "realtek,rtd1619b-pinctrl";
+ reg = <0x4e000 0x130>;
+
+ emmc-hs200-pins {
+ pins = "emmc_clk",
+ "emmc_cmd",
+ "emmc_data_0",
+ "emmc_data_1",
+ "emmc_data_2",
+ "emmc_data_3",
+ "emmc_data_4",
+ "emmc_data_5",
+ "emmc_data_6",
+ "emmc_data_7";
+ function = "emmc";
+ realtek,drive-strength-p = <0x2>;
+ realtek,drive-strength-n = <0x2>;
+ };
+
+ i2c-0-pins {
+ pins = "gpio_12",
+ "gpio_13";
+ function = "i2c0";
+ drive-strength = <4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
index 4fc758fea7e6..075f3abdfbec 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
@@ -25,6 +25,7 @@ properties:
- renesas,pfc-r8a7745 # RZ/G1E
- renesas,pfc-r8a77470 # RZ/G1C
- renesas,pfc-r8a774a1 # RZ/G2M
+ - renesas,pfc-r8a774a3 # RZ/G2M v3.0
- renesas,pfc-r8a774b1 # RZ/G2N
- renesas,pfc-r8a774c0 # RZ/G2E
- renesas,pfc-r8a774e1 # RZ/G2H
@@ -46,6 +47,7 @@ properties:
- renesas,pfc-r8a779a0 # R-Car V3U
- renesas,pfc-r8a779f0 # R-Car S4-8
- renesas,pfc-r8a779g0 # R-Car V4H
+ - renesas,pfc-r8a779h0 # R-Car V4M
- renesas,pfc-sh73a0 # SH-Mobile AG5
reg:
@@ -73,7 +75,7 @@ properties:
maxItems: 1
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -107,7 +109,6 @@ additionalProperties:
Client device subnodes use below standard properties.
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -127,11 +128,8 @@ additionalProperties:
additionalProperties: false
- type: object
- properties:
- phandle: true
-
additionalProperties:
- $ref: "#/additionalProperties/anyOf/0"
+ $ref: '#/additionalProperties/anyOf/0'
examples:
- |
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml
new file mode 100644
index 000000000000..36d665971484
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/renesas,r9a09g077-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/T2H and RZ/N2H Pin and GPIO controller
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ The Renesas RZ/T2H and RZ/N2H SoCs feature a combined Pin and GPIO controller.
+ Pin multiplexing and GPIO configuration are performed on a per-pin basis.
+ Each port supports up to 8 pins, each configurable for either GPIO (port mode)
+ or alternate function mode. Each pin supports function mode values ranging from
+ 0x0 to 0x2A, allowing selection from up to 43 different functions.
+
+properties:
+ compatible:
+ enum:
+ - renesas,r9a09g077-pinctrl # RZ/T2H
+ - renesas,r9a09g087-pinctrl # RZ/N2H
+
+ reg:
+ minItems: 1
+ items:
+ - description: Non-safety I/O Port base
+ - description: Safety I/O Port safety region base
+ - description: Safety I/O Port Non-safety region base
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: nsr
+ - const: srs
+ - const: srn
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+ description:
+ The first cell contains the global GPIO port index, constructed using the
+ RZT2H_GPIO() helper macro from <dt-bindings/pinctrl/renesas,r9a09g077-pinctrl.h>
+ (e.g. "RZT2H_GPIO(3, 0)" for P03_0). The second cell represents the consumer
+ flag. Use the macros defined in include/dt-bindings/gpio/gpio.h.
+
+ gpio-ranges:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+definitions:
+ renesas-rzt2h-n2h-pins-node:
+ type: object
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+ properties:
+ pinmux:
+ description:
+ Values are constructed from I/O port number, pin number, and
+ alternate function configuration number using the RZT2H_PORT_PINMUX()
+ helper macro from <dt-bindings/pinctrl/renesas,r9a09g077-pinctrl.h>.
+ pins: true
+ phandle: true
+ input: true
+ input-enable: true
+ output-enable: true
+ oneOf:
+ - required: [pinmux]
+ - required: [pins]
+ additionalProperties: false
+
+patternProperties:
+ # Grouping nodes: allow multiple "-pins" subnodes within a "-group"
+ '.*-group$':
+ type: object
+ description:
+ Pin controller client devices can organize pin configuration entries into
+ grouping nodes ending in "-group". These group nodes may contain multiple
+ child nodes each ending in "-pins" to configure distinct sets of pins.
+ additionalProperties: false
+ patternProperties:
+ '-pins$':
+ $ref: '#/definitions/renesas-rzt2h-n2h-pins-node'
+
+ # Standalone "-pins" nodes under client devices or groups
+ '-pins$':
+ $ref: '#/definitions/renesas-rzt2h-n2h-pins-node'
+
+ '-hog$':
+ type: object
+ description: GPIO hog node
+ properties:
+ gpio-hog: true
+ gpios: true
+ input: true
+ output-high: true
+ output-low: true
+ line-name: true
+ required:
+ - gpio-hog
+ - gpios
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+ - clocks
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h>
+ #include <dt-bindings/pinctrl/renesas,r9a09g077-pinctrl.h>
+
+ pinctrl@802c0000 {
+ compatible = "renesas,r9a09g077-pinctrl";
+ reg = <0x802c0000 0x2000>,
+ <0x812c0000 0x2000>,
+ <0x802b0000 0x2000>;
+ reg-names = "nsr", "srs", "srn";
+ clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKM>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl 0 0 288>;
+ power-domains = <&cpg>;
+
+ serial0-pins {
+ pinmux = <RZT2H_PORT_PINMUX(38, 0, 1)>, /* Tx */
+ <RZT2H_PORT_PINMUX(38, 1, 1)>; /* Rx */
+ };
+
+ sd1-pwr-en-hog {
+ gpio-hog;
+ gpios = <RZT2H_GPIO(39, 2) 0>;
+ output-high;
+ line-name = "sd1_pwr_en";
+ };
+
+ i2c0-pins {
+ pins = "RIIC0_SDA", "RIIC0_SCL";
+ input-enable;
+ };
+
+ sd0-sd-group {
+ ctrl-pins {
+ pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
+ <RZT2H_PORT_PINMUX(12, 1, 0x29)>; /* SD0_CMD */
+ };
+
+ data-pins {
+ pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
+ <RZT2H_PORT_PINMUX(12, 1, 0x29)>; /* SD0_CMD */
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
index 8ed4b98a1628..8203c3c46cc7 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml
@@ -32,7 +32,7 @@ properties:
maxItems: 1
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -41,6 +41,7 @@ required:
patternProperties:
"^gpio-[0-9]*$":
type: object
+ additionalProperties: false
description:
Each port of the r7s72100 pin controller hardware is itself a GPIO
@@ -64,7 +65,6 @@ patternProperties:
- '#gpio-cells'
- gpio-ranges
-
additionalProperties:
anyOf:
- type: object
@@ -107,7 +107,6 @@ additionalProperties:
Integers values in "pinmux" argument list are assembled as:
((PORT * 16 + PIN) | MUX_FUNC << 16)
- phandle: true
input-enable: true
output-enable: true
@@ -117,11 +116,8 @@ additionalProperties:
additionalProperties: false
- type: object
- properties:
- phandle: true
-
additionalProperties:
- $ref: "#/additionalProperties/anyOf/0"
+ $ref: '#/additionalProperties/anyOf/0'
examples:
- |
@@ -153,7 +149,6 @@ examples:
pinmux = <RZA1_PINMUX(3, 0, 6)>, <RZA1_PINMUX(3, 2, 4)>;
};
-
/*
* I2c master: both SDA and SCL pins need bi-directional operations
* Pin #4 on port #1 is configured as alternate function #1.
@@ -165,7 +160,6 @@ examples:
pinmux = <RZA1_PINMUX(1, 4, 1)>, <RZA1_PINMUX(1, 5, 1)>;
};
-
/*
* Multi-function timer input and output compare pins.
*/
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml
index d761fddc2206..8b8e4e1a000f 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml
@@ -20,7 +20,7 @@ description:
properties:
compatible:
- const: "renesas,r7s9210-pinctrl" # RZ/A2M
+ const: renesas,r7s9210-pinctrl # RZ/A2M
reg:
maxItems: 1
@@ -37,43 +37,40 @@ properties:
gpio-ranges:
maxItems: 1
-patternProperties:
- "^.*$":
- if:
- type: object
- then:
- allOf:
- - $ref: pincfg-node.yaml#
- - $ref: pinmux-node.yaml#
- description:
- The child nodes of the pin controller designate pins to be used for
- specific peripheral functions or as GPIO.
+additionalProperties:
+ type: object
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
- A pin multiplexing sub-node describes how to configure a set of
- (or a single) pin in some desired alternate function mode.
- The values for the pinmux properties are a combination of port name,
- pin number and the desired function index. Use the RZA2_PINMUX macro
- located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily
- define these.
- For assigning GPIO pins, use the macro RZA2_PIN also in
- to express the desired port pin.
+ description:
+ The child nodes of the pin controller designate pins to be used for
+ specific peripheral functions or as GPIO.
- properties:
- phandle: true
+ A pin multiplexing sub-node describes how to configure a set of
+ (or a single) pin in some desired alternate function mode.
+ The values for the pinmux properties are a combination of port name,
+ pin number and the desired function index. Use the RZA2_PINMUX macro
+ located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily
+ define these.
+ For assigning GPIO pins, use the macro RZA2_PIN also in
+ to express the desired port pin.
- pinmux:
- description:
- Values are constructed from GPIO port number, pin number, and
- alternate function configuration number using the RZA2_PINMUX()
- helper macro in r7s9210-pinctrl.h.
+ properties:
+ pinmux:
+ description:
+ Values are constructed from GPIO port number, pin number, and
+ alternate function configuration number using the RZA2_PINMUX()
+ helper macro in r7s9210-pinctrl.h.
- required:
- - pinmux
+ required:
+ - pinmux
- additionalProperties: false
+ additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -82,8 +79,6 @@ required:
- '#gpio-cells'
- gpio-ranges
-additionalProperties: false
-
examples:
- |
#include <dt-bindings/pinctrl/r7s9210-pinctrl.h>
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
index 997b74639112..00c05243b9a4 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
@@ -23,8 +23,12 @@ properties:
oneOf:
- items:
- enum:
- - renesas,r9a07g043-pinctrl # RZ/G2UL{Type-1,Type-2}
+ - renesas,r9a07g043-pinctrl # RZ/G2UL{Type-1,Type-2} and RZ/Five
- renesas,r9a07g044-pinctrl # RZ/G2{L,LC}
+ - renesas,r9a08g045-pinctrl # RZ/G3S
+ - renesas,r9a09g047-pinctrl # RZ/G3E
+ - renesas,r9a09g056-pinctrl # RZ/V2N
+ - renesas,r9a09g057-pinctrl # RZ/V2H(P)
- items:
- enum:
@@ -65,14 +69,19 @@ properties:
maxItems: 1
resets:
- items:
- - description: GPIO_RSTN signal
- - description: GPIO_PORT_RESETN signal
- - description: GPIO_SPARE_RESETN signal
+ oneOf:
+ - items:
+ - description: GPIO_RSTN signal
+ - description: GPIO_PORT_RESETN signal
+ - description: GPIO_SPARE_RESETN signal
+ - items:
+ - description: PFC main reset
+ - description: Reset for the control register related to WDTUDFCA and WDTUDFFCM pins
additionalProperties:
anyOf:
- type: object
+ additionalProperties: false
allOf:
- $ref: pincfg-node.yaml#
- $ref: pinmux-node.yaml#
@@ -83,7 +92,6 @@ additionalProperties:
Client device subnodes use below standard properties.
properties:
- phandle: true
pinmux:
description:
Values are constructed from GPIO port number, pin number, and
@@ -92,6 +100,10 @@ additionalProperties:
pins: true
drive-strength:
enum: [ 2, 4, 8, 12 ]
+ drive-strength-microamp:
+ enum: [ 1900, 2200, 4000, 4400, 4500, 4700, 5200, 5300, 5700,
+ 5800, 6000, 6050, 6100, 6550, 6800, 7000, 8000, 9000,
+ 10000 ]
output-impedance-ohms:
enum: [ 33, 50, 66, 100 ]
power-source:
@@ -100,20 +112,50 @@ additionalProperties:
slew-rate: true
gpio-hog: true
gpios: true
+ input: true
input-enable: true
+ output-enable: true
output-high: true
output-low: true
line-name: true
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+ drive-open-drain: true
+ drive-push-pull: true
+ renesas,output-impedance:
+ description:
+ Output impedance for pins on the RZ/{G3E,V2H(P)} SoC. The value provided by this
+ property corresponds to register bit values that can be set in the PFC_IOLH_mn
+ register, which adjusts the drive strength value and is pin-dependent.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
- type: object
- properties:
- phandle: true
-
additionalProperties:
- $ref: "#/additionalProperties/anyOf/0"
+ $ref: '#/additionalProperties/anyOf/0'
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g047-pinctrl
+ - renesas,r9a09g056-pinctrl
+ - renesas,r9a09g057-pinctrl
+ then:
+ properties:
+ resets:
+ maxItems: 2
+ else:
+ properties:
+ resets:
+ minItems: 3
required:
- compatible
@@ -168,17 +210,17 @@ examples:
sd1_mux {
pinmux = <RZG2L_PORT_PINMUX(19, 0, 1)>, /* CD */
<RZG2L_PORT_PINMUX(19, 1, 1)>; /* WP */
- power-source = <3300>;
+ power-source = <3300>;
};
sd1_data {
pins = "SD1_DATA0", "SD1_DATA1", "SD1_DATA2", "SD1_DATA3";
- power-source = <3300>;
+ power-source = <3300>;
};
sd1_ctrl {
pins = "SD1_CLK", "SD1_CMD";
- power-source = <3300>;
+ power-source = <3300>;
};
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml
new file mode 100644
index 000000000000..ab2d456c93e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-poeg.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/renesas,rzg2l-poeg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Port Output Enable for GPT (POEG)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The output pins(GTIOCxA and GTIOCxB) of the general PWM timer (GPT) can be
+ disabled by using the port output enabling function for the GPT (POEG).
+ Specifically, either of the following ways can be used.
+ * Input level detection of the GTETRGA to GTETRGD pins.
+ * Output-disable request from the GPT.
+ * SSF bit setting(ie, by setting POEGGn.SSF to 1)
+
+ The state of the GTIOCxA and the GTIOCxB pins when the output is disabled,
+ are controlled by the GPT module.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a07g044-poeg # RZ/G2{L,LC}
+ - renesas,r9a07g054-poeg # RZ/V2L
+ - const: renesas,rzg2l-poeg
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ renesas,gpt:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to gpt instance that serves the pwm operation.
+
+ renesas,poeg-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ description: |
+ POEG group index. Valid values are:
+ <0> : POEG group A
+ <1> : POEG group B
+ <2> : POEG group C
+ <3> : POEG group D
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - power-domains
+ - resets
+ - renesas,poeg-id
+ - renesas,gpt
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ poeggd: poeg@10049400 {
+ compatible = "renesas,r9a07g044-poeg", "renesas,rzg2l-poeg";
+ reg = <0x10049400 0x400>;
+ interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A07G044_POEG_D_CLKP>;
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_POEG_D_RST>;
+ renesas,poeg-id = <3>;
+ renesas,gpt = <&gpt>;
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml
index 70b1788ab594..aa882b5bfe97 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml
@@ -7,15 +7,13 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1 Pin Controller
maintainers:
- - Gareth Williams <gareth.williams.jx@renesas.com>
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
compatible:
items:
- - enum:
- - renesas,r9a06g032-pinctrl # RZ/N1D
- - renesas,r9a06g033-pinctrl # RZ/N1S
+ - const: renesas,r9a06g032-pinctrl # RZ/N1D
- const: renesas,rzn1-pinctrl # Generic RZ/N1
reg:
@@ -32,7 +30,7 @@ properties:
The bus clock, sometimes described as pclk, for register accesses.
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -74,7 +72,6 @@ additionalProperties:
offset by 10. Additional identifiers are provided to specify the
MDIO source peripheral.
- phandle: true
bias-disable: true
bias-pull-up:
description: Pull up the pin with 50 kOhm
@@ -91,9 +88,6 @@ additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
- type: object
- properties:
- phandle: true
-
additionalProperties:
$ref: "#/additionalProperties/anyOf/0"
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml
index eac6245db7dc..88b2fa5e684d 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml
@@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/V2M combined Pin and GPIO controller
maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
- - Phil Edworthy <phil.edworthy@renesas.com>
description:
The Renesas RZ/V2M SoC features a combined Pin and GPIO controller.
@@ -53,6 +53,7 @@ properties:
additionalProperties:
anyOf:
- type: object
+ additionalProperties: false
allOf:
- $ref: pincfg-node.yaml#
- $ref: pinmux-node.yaml#
@@ -63,7 +64,6 @@ additionalProperties:
Client device subnodes use below standard properties.
properties:
- phandle: true
pinmux:
description:
Values are constructed from GPIO port number, pin number, and
@@ -87,14 +87,11 @@ additionalProperties:
line-name: true
- type: object
- properties:
- phandle: true
-
additionalProperties:
- $ref: "#/additionalProperties/anyOf/0"
+ $ref: '#/additionalProperties/anyOf/0'
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
index 677a285ca416..76e607281716 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
@@ -44,17 +44,22 @@ properties:
- rockchip,rk3328-pinctrl
- rockchip,rk3368-pinctrl
- rockchip,rk3399-pinctrl
+ - rockchip,rk3506-pinctrl
+ - rockchip,rk3528-pinctrl
+ - rockchip,rk3562-pinctrl
- rockchip,rk3568-pinctrl
+ - rockchip,rk3576-pinctrl
- rockchip,rk3588-pinctrl
- rockchip,rv1108-pinctrl
+ - rockchip,rv1126-pinctrl
rockchip,grf:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
The phandle of the syscon node for the GRF registers.
rockchip,pmu:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description:
The phandle of the syscon node for the PMU registers,
as some SoCs carry parts of the iomux controller registers there.
@@ -70,20 +75,18 @@ properties:
ranges: true
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
- rockchip,grf
- - "#address-cells"
- - "#size-cells"
- - ranges
patternProperties:
"gpio@[0-9a-f]+$":
type: object
- $ref: "/schemas/gpio/rockchip,gpio-bank.yaml#"
+ $ref: /schemas/gpio/rockchip,gpio-bank.yaml#
+ deprecated: true
unevaluatedProperties: false
@@ -116,9 +119,11 @@ additionalProperties:
type: object
additionalProperties:
type: object
+ additionalProperties: false
+
properties:
rockchip,pins:
- $ref: "/schemas/types.yaml#/definitions/uint32-matrix"
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
minItems: 1
items:
items:
@@ -131,7 +136,7 @@ additionalProperties:
description:
Pin bank index.
- minimum: 0
- maximum: 10
+ maximum: 14
description:
Mux 0 means GPIO and mux 1 to N means
the specific device function.
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml
index 9869d4dceddb..f796f27bf0e6 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml
@@ -20,7 +20,6 @@ description: |
The values used for config properties should be derived from the hardware
manual and these values are programmed as-is into the pin pull up/down and
driver strength register of the pin-controller.
- See also include/dt-bindings/pinctrl/samsung.h with useful constants.
See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for
additional information and example.
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 1de91a51234d..f3c433015b12 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -28,21 +28,37 @@ description: |
properties:
compatible:
- enum:
- - samsung,s3c2410-wakeup-eint
- - samsung,s3c2412-wakeup-eint
- - samsung,s3c64xx-wakeup-eint
- - samsung,s5pv210-wakeup-eint
- - samsung,exynos4210-wakeup-eint
- - samsung,exynos7-wakeup-eint
- - samsung,exynos850-wakeup-eint
- - samsung,exynosautov9-wakeup-eint
+ oneOf:
+ - enum:
+ - samsung,s3c64xx-wakeup-eint
+ - samsung,s5pv210-wakeup-eint
+ - samsung,exynos4210-wakeup-eint
+ - samsung,exynos7-wakeup-eint
+ - samsung,exynosautov920-wakeup-eint
+ - items:
+ - enum:
+ - samsung,exynos5433-wakeup-eint
+ - samsung,exynos7870-wakeup-eint
+ - samsung,exynos7885-wakeup-eint
+ - samsung,exynos850-wakeup-eint
+ - samsung,exynos8890-wakeup-eint
+ - samsung,exynos8895-wakeup-eint
+ - const: samsung,exynos7-wakeup-eint
+ - items:
+ - enum:
+ - google,gs101-wakeup-eint
+ - samsung,exynos2200-wakeup-eint
+ - samsung,exynos9810-wakeup-eint
+ - samsung,exynos990-wakeup-eint
+ - samsung,exynosautov9-wakeup-eint
+ - const: samsung,exynos850-wakeup-eint
+ - const: samsung,exynos7-wakeup-eint
interrupts:
description:
Interrupt used by multiplexed external wake-up interrupts.
minItems: 1
- maxItems: 6
+ maxItems: 4
required:
- compatible
@@ -52,21 +68,6 @@ allOf:
properties:
compatible:
contains:
- enum:
- - samsung,s3c2410-wakeup-eint
- - samsung,s3c2412-wakeup-eint
- then:
- properties:
- interrupts:
- minItems: 6
- maxItems: 6
- required:
- - interrupts
-
- - if:
- properties:
- compatible:
- contains:
const: samsung,s3c64xx-wakeup-eint
then:
properties:
@@ -79,11 +80,19 @@ allOf:
- if:
properties:
compatible:
- contains:
- enum:
- - samsung,s5pv210-wakeup-eint
- - samsung,exynos4210-wakeup-eint
- - samsung,exynos7-wakeup-eint
+ oneOf:
+ # Match without "contains", to skip newer variants which are still
+ # compatible with samsung,exynos7-wakeup-eint
+ - enum:
+ - samsung,exynos4210-wakeup-eint
+ - samsung,exynos7-wakeup-eint
+ - samsung,s5pv210-wakeup-eint
+ - contains:
+ enum:
+ - samsung,exynos5433-wakeup-eint
+ - samsung,exynos7870-wakeup-eint
+ - samsung,exynos7885-wakeup-eint
+ - samsung,exynos8895-wakeup-eint
then:
properties:
interrupts:
@@ -98,7 +107,7 @@ allOf:
contains:
enum:
- samsung,exynos850-wakeup-eint
- - samsung,exynosautov9-wakeup-eint
+ - samsung,exynosautov920-wakeup-eint
then:
properties:
interrupts: false
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 3a65c66ca71d..ddc5e2efff21 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -15,9 +15,6 @@ description: |
This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin
controller.
- Pin group settings (like drive strength, pull up/down) are available as
- macros in include/dt-bindings/pinctrl/samsung.h.
-
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
@@ -38,12 +35,12 @@ properties:
compatible:
enum:
- - samsung,s3c2412-pinctrl
- - samsung,s3c2416-pinctrl
- - samsung,s3c2440-pinctrl
- - samsung,s3c2450-pinctrl
+ - axis,artpec8-pinctrl
+ - axis,artpec9-pinctrl
+ - google,gs101-pinctrl
- samsung,s3c64xx-pinctrl
- samsung,s5pv210-pinctrl
+ - samsung,exynos2200-pinctrl
- samsung,exynos3250-pinctrl
- samsung,exynos4210-pinctrl
- samsung,exynos4x12-pinctrl
@@ -53,9 +50,15 @@ properties:
- samsung,exynos5420-pinctrl
- samsung,exynos5433-pinctrl
- samsung,exynos7-pinctrl
+ - samsung,exynos7870-pinctrl
- samsung,exynos7885-pinctrl
- samsung,exynos850-pinctrl
+ - samsung,exynos8890-pinctrl
+ - samsung,exynos8895-pinctrl
+ - samsung,exynos9810-pinctrl
+ - samsung,exynos990-pinctrl
- samsung,exynosautov9-pinctrl
+ - samsung,exynosautov920-pinctrl
- tesla,fsd-pinctrl
interrupts:
@@ -74,6 +77,13 @@ properties:
minItems: 1
maxItems: 2
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pclk
+
wakeup-interrupt-controller:
$ref: samsung,pinctrl-wakeup-interrupt.yaml
@@ -97,6 +107,9 @@ patternProperties:
additionalProperties: false
"^(initial|sleep)-state$":
+ type: object
+ additionalProperties: false
+
patternProperties:
"^(pin-[a-z0-9-]+|[a-z0-9-]+-pin)$":
$ref: samsung,pinctrl-pins-cfg.yaml
@@ -117,7 +130,23 @@ required:
- reg
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-pinctrl
+ - samsung,exynos8890-pinctrl
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+
- if:
properties:
compatible:
@@ -138,8 +167,6 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/pinctrl/samsung.h>
-
pinctrl@7f008000 {
compatible = "samsung,s3c64xx-pinctrl";
reg = <0x7f008000 0x1000>;
@@ -166,8 +193,8 @@ examples:
uart0-data-pins {
samsung,pins = "gpa-0", "gpa-1";
- samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
- samsung,pin-pud = <S3C64XX_PIN_PULL_NONE>;
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
};
// ...
@@ -175,7 +202,6 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/pinctrl/samsung.h>
pinctrl@11400000 {
compatible = "samsung,exynos4210-pinctrl";
@@ -197,9 +223,9 @@ examples:
uart0-data-pins {
samsung,pins = "gpa0-0", "gpa0-1";
- samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
- samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
};
// ...
@@ -207,14 +233,14 @@ examples:
sleep0: sleep-state {
gpa0-0-pin {
samsung,pins = "gpa0-0";
- samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>;
- samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-con-pdn = <2>;
+ samsung,pin-pud-pdn = <0>;
};
gpa0-1-pin {
samsung,pins = "gpa0-1";
- samsung,pin-con-pdn = <EXYNOS_PIN_PDN_OUT0>;
- samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
+ samsung,pin-con-pdn = <0>;
+ samsung,pin-pud-pdn = <0>;
};
// ...
@@ -223,7 +249,6 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/pinctrl/samsung.h>
pinctrl@11000000 {
compatible = "samsung,exynos4210-pinctrl";
@@ -272,26 +297,26 @@ examples:
sd0-clk-pins {
samsung,pins = "gpk0-0";
- samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
- samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
};
sd4-bus-width8-pins {
part-1-pins {
samsung,pins = "gpk0-3", "gpk0-4",
"gpk0-5", "gpk0-6";
- samsung,pin-function = <EXYNOS_PIN_FUNC_3>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
- samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
};
part-2-pins {
samsung,pins = "gpk1-3", "gpk1-4",
"gpk1-5", "gpk1-6";
- samsung,pin-function = <EXYNOS_PIN_FUNC_4>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_UP>;
- samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>;
+ samsung,pin-function = <4>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
};
};
@@ -299,16 +324,15 @@ examples:
otg-gp-pins {
samsung,pins = "gpx3-3";
- samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
- samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
samsung,pin-val = <0>;
};
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/pinctrl/samsung.h>
pinctrl@10580000 {
compatible = "samsung,exynos5433-pinctrl";
@@ -318,7 +342,8 @@ examples:
pinctrl-0 = <&initial_alive>;
wakeup-interrupt-controller {
- compatible = "samsung,exynos7-wakeup-eint";
+ compatible = "samsung,exynos5433-wakeup-eint",
+ "samsung,exynos7-wakeup-eint";
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
};
@@ -352,9 +377,9 @@ examples:
initial_alive: initial-state {
gpa0-0-pin {
samsung,pins = "gpa0-0";
- samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>;
- samsung,pin-drv = <EXYNOS5433_PIN_DRV_FAST_SR1>;
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
};
// ...
@@ -363,7 +388,6 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/pinctrl/samsung.h>
pinctrl@114b0000 {
compatible = "samsung,exynos5433-pinctrl";
@@ -384,9 +408,9 @@ examples:
i2s0-bus-pins {
samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
"gpz0-4", "gpz0-5", "gpz0-6";
- samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
- samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
- samsung,pin-drv = <EXYNOS5433_PIN_DRV_FAST_SR1>;
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
};
// ...
diff --git a/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml b/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml
new file mode 100644
index 000000000000..39d7dad3313b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml
@@ -0,0 +1,251 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2022 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/semtech,sx1501q.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech SX150x GPIO expander
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - semtech,sx1501q
+ - semtech,sx1502q
+ - semtech,sx1503q
+ - semtech,sx1504q
+ - semtech,sx1505q
+ - semtech,sx1506q
+ - semtech,sx1507q
+ - semtech,sx1508q
+ - semtech,sx1509q
+
+ reg:
+ maxItems: 1
+
+ gpio-line-names:
+ minItems: 5
+ maxItems: 17
+
+ interrupts:
+ maxItems: 1
+
+ '#interrupt-cells':
+ const: 2
+
+ interrupt-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ semtech,probe-reset:
+ description: Will trigger a reset of the GPIO expander on probe
+ type: boolean
+
+patternProperties:
+ '-cfg$':
+ type: object
+ properties:
+ pins: true
+
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+ bias-pull-pin-default: true
+ drive-push-pull: true
+ output-low: true
+ output-high: true
+ drive-open-drain: true
+
+ required:
+ - pins
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+ - if:
+ properties:
+ pins:
+ contains:
+ const: oscio
+ then:
+ properties:
+ bias-disable: false
+ bias-pull-up: false
+ bias-pull-down: false
+ bias-pull-pin-default: false
+ drive-open-drain: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+
+allOf:
+ - $ref: pinctrl.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1501q
+ - semtech,sx1504q
+ - semtech,sx1507q
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 5
+ maxItems: 5
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1502q
+ - semtech,sx1505q
+ - semtech,sx1508q
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 9
+ maxItems: 9
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1503q
+ - semtech,sx1506q
+ - semtech,sx1509q
+ then:
+ properties:
+ gpio-line-names:
+ minItems: 17
+ maxItems: 17
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1507q
+ - semtech,sx1508q
+ - semtech,sx1509q
+ then:
+ properties:
+ semtech,probe-reset: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1501q
+ - semtech,sx1504q
+ then:
+ patternProperties:
+ '-cfg$':
+ properties:
+ pins:
+ items:
+ pattern: '^gpio[0-3]$'
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1502q
+ - semtech,sx1505q
+ then:
+ patternProperties:
+ '-cfg$':
+ properties:
+ pins:
+ items:
+ pattern: '^gpio[0-7]$'
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - semtech,sx1503q
+ - semtech,sx1506q
+ then:
+ patternProperties:
+ '-cfg$':
+ properties:
+ pins:
+ items:
+ pattern: '^(gpio[0-9]|gpio1[0-5])$'
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: semtech,sx1507q
+ then:
+ patternProperties:
+ '-cfg$':
+ properties:
+ pins:
+ items:
+ pattern: '^(oscio|gpio[0-3])$'
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: semtech,sx1508q
+ then:
+ patternProperties:
+ '-cfg$':
+ properties:
+ pins:
+ items:
+ pattern: '^(oscio|gpio[0-7])$'
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: semtech,sx1509q
+ then:
+ patternProperties:
+ '-cfg$':
+ properties:
+ pins:
+ items:
+ pattern: '^(oscio|gpio[0-9]|gpio1[0-5])$'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c@1000 {
+ reg = <0x1000 0x80>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl@20 {
+ compatible = "semtech,sx1501q";
+ reg = <0x20>;
+
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+
+ gpio-controller;
+ interrupt-controller;
+
+ gpio1-cfg {
+ pins = "gpio1";
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
index 14a8c0215cc6..880da721a927 100644
--- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
%YAML 1.2
---
$id: http://devicetree.org/schemas/pinctrl/socionext,uniphier-pinctrl.yaml#
@@ -31,7 +32,6 @@ additionalProperties:
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -48,7 +48,6 @@ additionalProperties:
- $ref: pinmux-node.yaml#
properties:
- phandle: true
function: true
groups: true
pins: true
@@ -60,7 +59,7 @@ additionalProperties:
unevaluatedProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -69,11 +68,17 @@ examples:
- |
// The UniPhier pinctrl should be a subnode of a "syscon" compatible node.
- soc-glue@5f800000 {
- compatible = "socionext,uniphier-pro4-soc-glue", "simple-mfd", "syscon";
- reg = <0x5f800000 0x2000>;
+ pinctrl {
+ compatible = "socionext,uniphier-ld20-pinctrl";
+
+ pinctrl_ether_rgmii: ether-rgmii {
+ groups = "ether_rgmii";
+ function = "ether_rgmii";
- pinctrl: pinctrl {
- compatible = "socionext,uniphier-pro4-pinctrl";
+ tx {
+ pins = "RGMII_TXCLK", "RGMII_TXD0", "RGMII_TXD1",
+ "RGMII_TXD2", "RGMII_TXD3", "RGMII_TXCTL";
+ drive-strength = <9>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/pinctrl/sophgo,cv1800-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sophgo,cv1800-pinctrl.yaml
new file mode 100644
index 000000000000..feb4785a3fac
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/sophgo,cv1800-pinctrl.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/sophgo,cv1800-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800 Pin Controller
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+properties:
+ compatible:
+ enum:
+ - sophgo,cv1800b-pinctrl
+ - sophgo,cv1812h-pinctrl
+ - sophgo,sg2000-pinctrl
+ - sophgo,sg2002-pinctrl
+
+ reg:
+ items:
+ - description: pinctrl for system domain
+ - description: pinctrl for rtc domain
+
+ reg-names:
+ items:
+ - const: sys
+ - const: rtc
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ '-cfg$':
+ type: object
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine.
+
+ additionalProperties: false
+
+ patternProperties:
+ '-pins$':
+ type: object
+ description: |
+ Each subnode will list the pins it needs, and how they should
+ be configured, with regard to muxer configuration, bias, input
+ enable/disable, input schmitt trigger, slew-rate, drive strength
+ and bus hold state. In addition, all pins in the same subnode
+ should have the same power domain. For configuration detail,
+ refer to https://github.com/sophgo/sophgo-doc/.
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the PINMUX or PINMUX2
+ macro.
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ drive-strength-microamp:
+ description: typical current when output high level.
+
+ input-schmitt-microvolt:
+ description: typical threshold for schmitt trigger.
+
+ power-source:
+ description: power supplies at X mV.
+ enum: [ 1800, 3300 ]
+
+ slew-rate:
+ description: slew rate for output buffer (0 is fast, 1 is slow)
+ enum: [ 0, 1 ]
+
+ bias-bus-hold: true
+
+ required:
+ - pinmux
+ - power-source
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-cv1800b.h>
+
+ pinctrl@3001000 {
+ compatible = "sophgo,cv1800b-pinctrl";
+ reg = <0x03001000 0x1000>,
+ <0x05027000 0x1000>;
+ reg-names = "sys", "rtc";
+
+ uart0_cfg: uart0-cfg {
+ uart0-pins {
+ pinmux = <PINMUX(PIN_UART0_TX, 0)>,
+ <PINMUX(PIN_UART0_RX, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ input-schmitt-microvolt = <0>;
+ power-source = <3300>;
+ slew-rate = <0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml
new file mode 100644
index 000000000000..924dfe1404a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/sophgo,sg2042-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 Pin Controller
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+properties:
+ compatible:
+ enum:
+ - sophgo,sg2042-pinctrl
+ - sophgo,sg2044-pinctrl
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-cfg$':
+ type: object
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine.
+
+ additionalProperties: false
+
+ patternProperties:
+ '-pins$':
+ type: object
+ description: |
+ Each subnode will list the pins it needs, and how they should
+ be configured, with regard to muxer configuration, bias input
+ enable/disable, input schmitt trigger enable, drive strength
+ output enable/disable state. For configuration detail,
+ refer to https://github.com/sophgo/sophgo-doc/.
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the PINMUX macro.
+
+ bias-disable: true
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ drive-strength-microamp:
+ description: typical current when output low level.
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ required:
+ - pinmux
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: sophgo,sg2042-pinctrl
+ then:
+ patternProperties:
+ '-cfg$':
+ patternProperties:
+ '-pins$':
+ properties:
+ drive-strength-microamp:
+ enum: [ 5400, 8100, 10700, 13400,
+ 16100, 18800, 21400, 24100,
+ 26800, 29400, 32100, 34800,
+ 37400, 40100, 42800, 45400 ]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: sophgo,sg2044-pinctrl
+ then:
+ patternProperties:
+ '-cfg$':
+ patternProperties:
+ '-pins$':
+ properties:
+ drive-strength-microamp:
+ enum: [ 3200, 6400, 9600, 12700,
+ 15900, 19100, 22200, 25300,
+ 29500, 32700, 35900, 39000,
+ 42000, 45200, 48300, 51400]
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-sg2042.h>
+
+ pinctrl@30011000 {
+ compatible = "sophgo,sg2042-pinctrl";
+ reg = <30011000 0x1000>;
+
+ uart0_cfg: uart0-cfg {
+ uart0-pins {
+ pinmux = <PINMUX(PIN_UART0_TX, 0)>,
+ <PINMUX(PIN_UART0_RX, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <13400>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/spacemit,k1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/spacemit,k1-pinctrl.yaml
new file mode 100644
index 000000000000..d80e88aa07b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/spacemit,k1-pinctrl.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/spacemit,k1-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 SoC Pin Controller
+
+maintainers:
+ - Yixun Lan <dlan@gentoo.org>
+
+properties:
+ compatible:
+ const: spacemit,k1-pinctrl
+
+ reg:
+ items:
+ - description: pinctrl io memory base
+
+ clocks:
+ items:
+ - description: Functional Clock
+ - description: Bus Clock
+
+ clock-names:
+ items:
+ - const: func
+ - const: bus
+
+ resets:
+ maxItems: 1
+
+patternProperties:
+ '-cfg$':
+ type: object
+ additionalProperties: false
+
+ description:
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine.
+
+ patternProperties:
+ '-pins$':
+ type: object
+ additionalProperties: false
+
+ description:
+ Each subnode will list the pins it needs, and how they should
+ be configured, with regard to muxer configuration, bias pull,
+ drive strength, input schmitt trigger, slew rate, power source.
+
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: pinmux-node.yaml#
+
+ properties:
+ pinmux:
+ description:
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the K1_PADCONF macro to
+ construct the value.
+
+ bias-disable: true
+
+ bias-pull-down: true
+
+ bias-pull-up:
+ description: |
+ typical value for selecting bias pull up or strong pull up.
+ 0: normal bias pull up
+ 1: strong bias pull up
+ enum: [ 0, 1 ]
+
+ drive-strength:
+ description: |
+ typical current when output high level.
+ 1.8V output: 11, 21, 32, 42 (mA)
+ 3.3V output: 7, 10, 13, 16, 19, 23, 26, 29 (mA)
+
+ input-schmitt:
+ description: |
+ typical threshold for schmitt trigger.
+ 0: buffer mode
+ 1: trigger mode
+ 2, 3: trigger mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ power-source:
+ description: external power supplies at 1.8v or 3.3v.
+ enum: [ 1800, 3300 ]
+
+ slew-rate:
+ description: |
+ slew rate for output buffer.
+ 0: disable it
+ 1: enable it (via bundled value from drive strength)
+ 2: slow speed 0
+ 3: slow speed 1
+ 4: medium speed
+ 5: fast speed
+ enum: [ 0, 1, 2, 3, 4, 5 ]
+
+ required:
+ - pinmux
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #define K1_PADCONF(pin, func) (((pin) << 16) | (func))
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pinctrl@d401e000 {
+ compatible = "spacemit,k1-pinctrl";
+ reg = <0x0 0xd401e000 0x0 0x400>;
+ clocks = <&syscon_apbc 42>,
+ <&syscon_apbc 94>;
+ clock-names = "func", "bus";
+
+ uart0_2_cfg: uart0-2-cfg {
+ uart0-2-pins {
+ pinmux = <K1_PADCONF(68, 2)>,
+ <K1_PADCONF(69, 2)>;
+
+ bias-pull-up = <0>;
+ drive-strength = <32>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
deleted file mode 100644
index b1cea7a3a071..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/sprd,pinctrl.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-* Spreadtrum Pin Controller
-
-The Spreadtrum pin controller are organized in 3 blocks (types).
-
-The first block comprises some global control registers, and each
-register contains several bit fields with one bit or several bits
-to configure for some global common configuration, such as domain
-pad driving level, system control select and so on ("domain pad
-driving level": One pin can output 3.0v or 1.8v, depending on the
-related domain pad driving selection, if the related domain pad
-slect 3.0v, then the pin can output 3.0v. "system control" is used
-to choose one function (like: UART0) for which system, since we
-have several systems (AP/CP/CM4) on one SoC.).
-
-There are too much various configuration that we can not list all
-of them, so we can not make every Spreadtrum-special configuration
-as one generic configuration, and maybe it will add more strange
-global configuration in future. Then we add one "sprd,control" to
-set these various global control configuration, and we need use
-magic number for this property.
-
-Moreover we recognise every fields comprising one bit or several
-bits in one global control register as one pin, thus we should
-record every pin's bit offset, bit width and register offset to
-configure this field (pin).
-
-The second block comprises some common registers which have unified
-register definition, and each register described one pin is used
-to configure the pin sleep mode, function select and sleep related
-configuration.
-
-Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
-PUBCP system, TGLDSP system and AGDSP system. And the pin sleep
-related configuration are:
-- input-enable
-- input-disable
-- output-high
-- output-low
-- bias-pull-up
-- bias-pull-down
-
-In some situation we need set the pin sleep mode and pin sleep related
-configuration, to set the pin sleep related configuration automatically
-by hardware when the system specified by sleep mode goes into deep
-sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP
-and set the pin sleep related configuration as "input-enable", which
-means when PUBCP system goes into deep sleep mode, this pin will be set
-input enable automatically.
-
-Moreover we can not use the "sleep" state, since some systems (like:
-PUBCP system) do not run linux kernel OS (only AP system run linux
-kernel on SC9860 platform), then we can not select "sleep" state
-when the PUBCP system goes into deep sleep mode. Thus we introduce
-"sprd,sleep-mode" property to set pin sleep mode.
-
-The last block comprises some misc registers which also have unified
-register definition, and each register described one pin is used to
-configure drive strength, pull up/down and so on. Especially for pull
-up, we have two kind pull up resistor: 20K and 4.7K.
-
-Required properties for Spreadtrum pin controller:
-- compatible: "sprd,<soc>-pinctrl"
- Please refer to each sprd,<soc>-pinctrl.txt binding doc for supported SoCs.
-- reg: The register address of pin controller device.
-- pins : An array of pin names.
-
-Optional properties:
-- function: Specified the function name.
-- drive-strength: Drive strength in mA.
-- input-schmitt-disable: Enable schmitt-trigger mode.
-- input-schmitt-enable: Disable schmitt-trigger mode.
-- bias-disable: Disable pin bias.
-- bias-pull-down: Pull down on pin.
-- bias-pull-up: Pull up on pin.
-- input-enable: Enable pin input.
-- input-disable: Enable pin output.
-- output-high: Set the pin as an output level high.
-- output-low: Set the pin as an output level low.
-- sleep-hardware-state: Indicate these configs in this state are sleep related.
-- sprd,control: Control values referring to databook for global control pins.
-- sprd,sleep-mode: Sleep mode selection.
-
-Please refer to each sprd,<soc>-pinctrl.txt binding doc for supported values.
diff --git a/Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.txt
deleted file mode 100644
index 5a628333d52f..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-* Spreadtrum SC9860 Pin Controller
-
-Please refer to sprd,pinctrl.txt in this directory for common binding part
-and usage.
-
-Required properties:
-- compatible: Must be "sprd,sc9860-pinctrl".
-- reg: The register address of pin controller device.
-- pins : An array of strings, each string containing the name of a pin.
-
-Optional properties:
-- function: A string containing the name of the function, values must be
- one of: "func1", "func2", "func3" and "func4".
-- drive-strength: Drive strength in mA. Supported values: 2, 4, 6, 8, 10,
- 12, 14, 16, 20, 21, 24, 25, 27, 29, 31 and 33.
-- input-schmitt-disable: Enable schmitt-trigger mode.
-- input-schmitt-enable: Disable schmitt-trigger mode.
-- bias-disable: Disable pin bias.
-- bias-pull-down: Pull down on pin.
-- bias-pull-up: Pull up on pin. Supported values: 20000 for pull-up resistor
- is 20K and 4700 for pull-up resistor is 4.7K.
-- input-enable: Enable pin input.
-- input-disable: Enable pin output.
-- output-high: Set the pin as an output level high.
-- output-low: Set the pin as an output level low.
-- sleep-hardware-state: Indicate these configs in this state are sleep related.
-- sprd,control: Control values referring to databook for global control pins.
-- sprd,sleep-mode: Choose the pin sleep mode, and supported values are:
- AP_SLEEP, PUBCP_SLEEP, TGLDSP_SLEEP and AGDSP_SLEEP.
-
-Pin sleep mode definition:
-enum pin_sleep_mode {
- AP_SLEEP = BIT(0),
- PUBCP_SLEEP = BIT(1),
- TGLDSP_SLEEP = BIT(2),
- AGDSP_SLEEP = BIT(3),
-};
-
-Example:
-pin_controller: pinctrl@402a0000 {
- compatible = "sprd,sc9860-pinctrl";
- reg = <0x402a0000 0x10000>;
-
- grp1: sd0 {
- pins = "SC9860_VIO_SD2_IRTE", "SC9860_VIO_SD0_IRTE";
- sprd,control = <0x1>;
- };
-
- grp2: rfctl_33 {
- pins = "SC9860_RFCTL33";
- function = "func2";
- sprd,sleep-mode = <AP_SLEEP | PUBCP_SLEEP>;
- grp2_sleep_mode: rfctl_33_sleep {
- pins = "SC9860_RFCTL33";
- sleep-hardware-state;
- output-low;
- }
- };
-
- grp3: rfctl_misc_20 {
- pins = "SC9860_RFCTL20_MISC";
- drive-strength = <10>;
- bias-pull-up = <4700>;
- grp3_sleep_mode: rfctl_misc_sleep {
- pins = "SC9860_RFCTL20_MISC";
- sleep-hardware-state;
- bias-pull-up;
- }
- };
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.yaml
new file mode 100644
index 000000000000..59d23eb8aa97
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/sprd,sc9860-pinctrl.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/sprd,sc9860-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC9860 Pin Controller
+
+maintainers:
+ - Baolin Wang <baolin.wang@linux.alibaba.com>
+
+description: >
+ The Spreadtrum pin controller are organized in 3 blocks (types).
+
+ The first block comprises some global control registers, and each
+ register contains several bit fields with one bit or several bits
+ to configure for some global common configuration, such as domain
+ pad driving level, system control select and so on ("domain pad
+ driving level": One pin can output 3.0v or 1.8v, depending on the
+ related domain pad driving selection, if the related domain pad
+ select 3.0v, then the pin can output 3.0v. "system control" is used
+ to choose one function (like: UART0) for which system, since we
+ have several systems (AP/CP/CM4) on one SoC.).
+
+ There are too much various configuration that we can not list all
+ of them, so we can not make every Spreadtrum-special configuration
+ as one generic configuration, and maybe it will add more strange
+ global configuration in future. Then we add one "sprd,control" to
+ set these various global control configuration, and we need use
+ magic number for this property.
+
+ Moreover we recognize every fields comprising one bit or several
+ bits in one global control register as one pin, thus we should
+ record every pin's bit offset, bit width and register offset to
+ configure this field (pin).
+
+ The second block comprises some common registers which have unified
+ register definition, and each register described one pin is used
+ to configure the pin sleep mode, function select and sleep related
+ configuration.
+
+ Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
+ PUBCP system, TGLDSP system and AGDSP system. And the pin sleep
+ related configuration are:
+ - input-enable
+ - input-disable
+ - output-high
+ - output-low
+ - bias-pull-up
+ - bias-pull-down
+
+ In some situation we need set the pin sleep mode and pin sleep related
+ configuration, to set the pin sleep related configuration automatically
+ by hardware when the system specified by sleep mode goes into deep
+ sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP
+ and set the pin sleep related configuration as "input-enable", which
+ means when PUBCP system goes into deep sleep mode, this pin will be set
+ input enable automatically.
+
+ Moreover we can not use the "sleep" state, since some systems (like:
+ PUBCP system) do not run linux kernel OS (only AP system run linux
+ kernel on SC9860 platform), then we can not select "sleep" state
+ when the PUBCP system goes into deep sleep mode. Thus we introduce
+ "sprd,sleep-mode" property to set pin sleep mode.
+
+ The last block comprises some misc registers which also have unified
+ register definition, and each register described one pin is used to
+ configure drive strength, pull up/down and so on. Especially for pull
+ up, we have two kind pull up resistor: 20K and 4.7K.
+
+properties:
+ compatible:
+ const: sprd,sc9860-pinctrl
+
+ reg:
+ maxItems: 1
+
+additionalProperties:
+ $ref: '#/$defs/pin-node'
+ unevaluatedProperties: false
+
+ properties:
+ function:
+ description: Function to assign to the pins.
+ enum:
+ - func1
+ - func2
+ - func3
+ - func4
+
+ drive-strength:
+ description: Drive strength in mA.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [2, 4, 6, 8, 10, 12, 14, 16, 20, 21, 24, 25, 27, 29, 31, 33]
+
+ input-schmitt-disable: true
+
+ input-schmitt-enable: true
+
+ bias-pull-up:
+ enum: [20000, 4700]
+
+ sprd,sleep-mode:
+ description: Pin sleep mode selection.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 0x1f
+
+ sprd,control:
+ description: Control values referring to databook for global control pins.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ patternProperties:
+ 'sleep$':
+ $ref: '#/$defs/pin-node'
+ unevaluatedProperties: false
+
+ properties:
+ bias-pull-up:
+ type: boolean
+
+ sleep-hardware-state:
+ description: Indicate these configs in sleep related state.
+ type: boolean
+
+$defs:
+ pin-node:
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+
+ properties:
+ pins:
+ description: Names of pins to configure.
+ $ref: /schemas/types.yaml#/definitions/string-array
+
+ bias-disable:
+ description: Disable pin bias.
+ type: boolean
+
+ bias-pull-down:
+ description: Pull down on pin.
+ type: boolean
+
+ bias-pull-up: true
+
+ input-enable:
+ description: Enable pin input.
+ type: boolean
+
+ input-disable:
+ description: Enable pin output.
+ type: boolean
+
+ output-high:
+ description: Set the pin as an output level high.
+ type: boolean
+
+ output-low:
+ description: Set the pin as an output level low.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ pin_controller: pinctrl@402a0000 {
+ compatible = "sprd,sc9860-pinctrl";
+ reg = <0x402a0000 0x10000>;
+
+ grp1: sd0 {
+ pins = "SC9860_VIO_SD2_IRTE", "SC9860_VIO_SD0_IRTE";
+ sprd,control = <0x1>;
+ };
+
+ grp2: rfctl_33 {
+ pins = "SC9860_RFCTL33";
+ function = "func2";
+ sprd,sleep-mode = <3>;
+ grp2_sleep_mode: rfctl_33_sleep {
+ pins = "SC9860_RFCTL33";
+ sleep-hardware-state;
+ output-low;
+ };
+ };
+
+ grp3: rfctl_misc_20 {
+ pins = "SC9860_RFCTL20_MISC";
+ drive-strength = <10>;
+ bias-pull-up = <4700>;
+ grp3_sleep_mode: rfctl_misc_sleep {
+ pins = "SC9860_RFCTL20_MISC";
+ sleep-hardware-state;
+ bias-pull-up;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml
new file mode 100644
index 000000000000..845b6b7b7552
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml
@@ -0,0 +1,187 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) STMicroelectronics 2025.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/st,stm32-hdp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Hardware Debug Port Mux/Config
+
+maintainers:
+ - Clément LE GOFFIC <legoffic.clement@gmail.com>
+
+description:
+ STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP).
+ It allows to output internal signals on SoC's GPIO.
+
+properties:
+ compatible:
+ enum:
+ - st,stm32mp131-hdp
+ - st,stm32mp151-hdp
+ - st,stm32mp251-hdp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+patternProperties:
+ "^hdp[0-7]-pins$":
+ type: object
+ $ref: pinmux-node.yaml#
+ additionalProperties: false
+
+ properties:
+ pins:
+ pattern: '^HDP[0-7]$'
+
+ function: true
+
+ required:
+ - function
+ - pins
+
+allOf:
+ - $ref: pinctrl.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp131-hdp
+ then:
+ patternProperties:
+ "^hdp[0-7]-pins$":
+ properties:
+ function:
+ enum: [ pwr_pwrwake_sys, pwr_stop_forbidden, pwr_stdby_wakeup, pwr_encomp_vddcore,
+ bsec_out_sec_niden, aiec_sys_wakeup, none, ddrctrl_lp_req,
+ pwr_ddr_ret_enable_n, dts_clk_ptat, sram3ctrl_tamp_erase_act, gpoval0,
+ pwr_sel_vth_vddcpu, pwr_mpu_ram_lowspeed, ca7_naxierrirq, pwr_okin_mr,
+ bsec_out_sec_dbgen, aiec_c1_wakeup, rcc_pwrds_mpu, ddrctrl_dfi_ctrlupd_req,
+ ddrctrl_cactive_ddrc_asr, sram3ctrl_hw_erase_act, nic400_s0_bready, gpoval1,
+ pwr_pwrwake_mpu, pwr_mpu_clock_disable_ack, ca7_ndbgreset_i,
+ bsec_in_rstcore_n, bsec_out_sec_bsc_dis, ddrctrl_dfi_init_complete,
+ ddrctrl_perf_op_is_refresh, ddrctrl_gskp_dfi_lp_req, sram3ctrl_sw_erase_act,
+ nic400_s0_bvalid, gpoval2, pwr_sel_vth_vddcore, pwr_mpu_clock_disable_req,
+ ca7_npmuirq0, ca7_nfiqout0, bsec_out_sec_dftlock, bsec_out_sec_jtag_dis,
+ rcc_pwrds_sys, sram3ctrl_tamp_erase_req, ddrctrl_stat_ddrc_reg_selfref_type0,
+ dts_valobus1_0, dts_valobus2_0, tamp_potential_tamp_erfcfg, nic400_s0_wready,
+ nic400_s0_rready, gpoval3, pwr_stop2_active, ca7_nl2reset_i,
+ ca7_npreset_varm_i, bsec_out_sec_dften, bsec_out_sec_dbgswenable,
+ eth1_out_pmt_intr_o, eth2_out_pmt_intr_o, ddrctrl_stat_ddrc_reg_selfref_type1,
+ ddrctrl_cactive_0, dts_valobus1_1, dts_valobus2_1, tamp_nreset_sram_ercfg,
+ nic400_s0_wlast, nic400_s0_rlast, gpoval4, ca7_standbywfil2,
+ pwr_vth_vddcore_ack, ca7_ncorereset_i, ca7_nirqout0, bsec_in_pwrok,
+ bsec_out_sec_deviceen, eth1_out_lpi_intr_o, eth2_out_lpi_intr_o,
+ ddrctrl_cactive_ddrc, ddrctrl_wr_credit_cnt, dts_valobus1_2, dts_valobus2_2,
+ pka_pka_itamp_out, nic400_s0_wvalid, nic400_s0_rvalid, gpoval5,
+ ca7_standbywfe0, pwr_vth_vddcpu_ack, ca7_evento, bsec_in_tamper_det,
+ bsec_out_sec_spniden, eth1_out_mac_speed_o1, eth2_out_mac_speed_o1,
+ ddrctrl_csysack_ddrc, ddrctrl_lpr_credit_cnt, dts_valobus1_3, dts_valobus2_3,
+ saes_tamper_out, nic400_s0_awready, nic400_s0_arready, gpoval6,
+ ca7_standbywfi0, pwr_rcc_vcpu_rdy, ca7_eventi, ca7_dbgack0, bsec_out_fuse_ok,
+ bsec_out_sec_spiden, eth1_out_mac_speed_o0, eth2_out_mac_speed_o0,
+ ddrctrl_csysreq_ddrc, ddrctrl_hpr_credit_cnt, dts_valobus1_4, dts_valobus2_4,
+ rng_tamper_out, nic400_s0_awavalid, nic400_s0_aravalid, gpoval7 ]
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp151-hdp
+ then:
+ patternProperties:
+ "^hdp[0-7]-pins$":
+ properties:
+ function:
+ enum: [ pwr_pwrwake_sys, cm4_sleepdeep, pwr_stdby_wkup, pwr_encomp_vddcore,
+ bsec_out_sec_niden, none, rcc_cm4_sleepdeep, gpu_dbg7, ddrctrl_lp_req,
+ pwr_ddr_ret_enable_n, dts_clk_ptat, gpoval0, pwr_pwrwake_mcu, cm4_halted,
+ ca7_naxierrirq, pwr_okin_mr, bsec_out_sec_dbgen, exti_sys_wakeup,
+ rcc_pwrds_mpu, gpu_dbg6, ddrctrl_dfi_ctrlupd_req, ddrctrl_cactive_ddrc_asr,
+ gpoval1, pwr_pwrwake_mpu, cm4_rxev, ca7_npmuirq1, ca7_nfiqout1,
+ bsec_in_rstcore_n, exti_c2_wakeup, rcc_pwrds_mcu, gpu_dbg5,
+ ddrctrl_dfi_init_complete, ddrctrl_perf_op_is_refresh,
+ ddrctrl_gskp_dfi_lp_req, gpoval2, pwr_sel_vth_vddcore, cm4_txev, ca7_npmuirq0,
+ ca7_nfiqout0, bsec_out_sec_dftlock, exti_c1_wakeup, rcc_pwrds_sys, gpu_dbg4,
+ ddrctrl_stat_ddrc_reg_selfref_type0, ddrctrl_cactive_1, dts_valobus1_0,
+ dts_valobus2_0, gpoval3, pwr_mpu_pdds_not_cstbydis, cm4_sleeping, ca7_nreset1,
+ ca7_nirqout1, bsec_out_sec_dften, bsec_out_sec_dbgswenable,
+ eth_out_pmt_intr_o, gpu_dbg3, ddrctrl_stat_ddrc_reg_selfref_type1,
+ ddrctrl_cactive_0, dts_valobus1_1, dts_valobus2_1, gpoval4, ca7_standbywfil2,
+ pwr_vth_vddcore_ack, ca7_nreset0, ca7_nirqout0, bsec_in_pwrok,
+ bsec_out_sec_deviceen, eth_out_lpi_intr_o, gpu_dbg2, ddrctrl_cactive_ddrc,
+ ddrctrl_wr_credit_cnt, dts_valobus1_2, dts_valobus2_2, gpoval5,
+ ca7_standbywfi1, ca7_standbywfe1, ca7_evento, ca7_dbgack1,
+ bsec_out_sec_spniden, eth_out_mac_speed_o1, gpu_dbg1, ddrctrl_csysack_ddrc,
+ ddrctrl_lpr_credit_cnt, dts_valobus1_3, dts_valobus2_3, gpoval6,
+ ca7_standbywfi0, ca7_standbywfe0, ca7_dbgack0, bsec_out_fuse_ok,
+ bsec_out_sec_spiden, eth_out_mac_speed_o0, gpu_dbg0, ddrctrl_csysreq_ddrc,
+ ddrctrl_hpr_credit_cnt, dts_valobus1_4, dts_valobus2_4, gpoval7 ]
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp251-hdp
+ then:
+ patternProperties:
+ "^hdp[0-7]-pins$":
+ properties:
+ function:
+ enum: [ pwr_pwrwake_sys, cpu2_sleep_deep, bsec_out_tst_sdr_unlock_or_disable_scan,
+ bsec_out_nidenm, bsec_out_nidena, cpu2_state_0, rcc_pwrds_sys, gpu_dbg7,
+ ddrss_csysreq_ddrc, ddrss_dfi_phyupd_req, cpu3_sleep_deep,
+ d2_gbl_per_clk_bus_req, pcie_usb_cxpl_debug_info_ei_0,
+ pcie_usb_cxpl_debug_info_ei_8, d3_state_0, gpoval0, pwr_pwrwake_cpu2,
+ cpu2_halted, cpu2_state_1, bsec_out_dbgenm, bsec_out_dbgena, exti1_sys_wakeup,
+ rcc_pwrds_cpu2, gpu_dbg6, ddrss_csysack_ddrc, ddrss_dfi_phymstr_req,
+ cpu3_halted, d2_gbl_per_dma_req, pcie_usb_cxpl_debug_info_ei_1,
+ pcie_usb_cxpl_debug_info_ei_9, d3_state_1, gpoval1, pwr_pwrwake_cpu1,
+ cpu2_rxev, cpu1_npumirq1, cpu1_nfiqout1, bsec_out_shdbgen, exti1_cpu2_wakeup,
+ rcc_pwrds_cpu1, gpu_dbg5, ddrss_cactive_ddrc, ddrss_dfi_lp_req, cpu3_rxev,
+ hpdma1_clk_bus_req, pcie_usb_cxpl_debug_info_ei_2,
+ pcie_usb_cxpl_debug_info_ei_10, d3_state_2, gpoval2, pwr_sel_vth_vddcpu,
+ cpu2_txev, cpu1_npumirq0, cpu1_nfiqout0, bsec_out_ddbgen, exti1_cpu1_wakeup,
+ cpu3_state_0, gpu_dbg4, ddrss_mcdcg_en, ddrss_dfi_freq_0, cpu3_txev,
+ hpdma2_clk_bus_req, pcie_usb_cxpl_debug_info_ei_3,
+ pcie_usb_cxpl_debug_info_ei_11, d1_state_0, gpoval3, pwr_sel_vth_vddcore,
+ cpu2_sleeping, cpu1_evento, cpu1_nirqout1, bsec_out_spnidena, exti2_d3_wakeup,
+ eth1_out_pmt_intr_o, gpu_dbg3, ddrss_dphycg_en, ddrss_obsp0, cpu3_sleeping,
+ hpdma3_clk_bus_req, pcie_usb_cxpl_debug_info_ei_4,
+ pcie_usb_cxpl_debug_info_ei_12, d1_state_1, gpoval4, cpu1_standby_wfil2,
+ none, cpu1_nirqout0, bsec_out_spidena, exti2_cpu3_wakeup, eth1_out_lpi_intr_o,
+ gpu_dbg2, ddrctrl_dfi_init_start, ddrss_obsp1, cpu3_state_1,
+ d3_gbl_per_clk_bus_req, pcie_usb_cxpl_debug_info_ei_5,
+ pcie_usb_cxpl_debug_info_ei_13, d1_state_2, gpoval5, cpu1_standby_wfi1,
+ cpu1_standby_wfe1, cpu1_halted1, cpu1_naxierrirq, bsec_out_spnidenm,
+ exti2_cpu2_wakeup, eth2_out_pmt_intr_o, gpu_dbg1, ddrss_dfi_init_complete,
+ ddrss_obsp2, d2_state_0, d3_gbl_per_dma_req, pcie_usb_cxpl_debug_info_ei_6,
+ pcie_usb_cxpl_debug_info_ei_14, cpu1_state_0, gpoval6, cpu1_standby_wfi0,
+ cpu1_standby_wfe0, cpu1_halted0, bsec_out_spidenm, exti2_cpu1__wakeup,
+ eth2_out_lpi_intr_o, gpu_dbg0, ddrss_dfi_ctrlupd_req, ddrss_obsp3, d2_state_1,
+ lpdma1_clk_bus_req, pcie_usb_cxpl_debug_info_ei_7,
+ pcie_usb_cxpl_debug_info_ei_15, cpu1_state_1, gpoval7 ]
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/stm32mp1-clks.h>
+
+ pinctrl@54090000 {
+ compatible = "st,stm32mp151-hdp";
+ reg = <0x54090000 0x400>;
+ clocks = <&rcc HDP>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdp2_gpo>;
+ hdp2_gpo: hdp2-pins {
+ function = "gpoval2";
+ pins = "HDP2";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
index d35dcc4f0242..76d956b4a537 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
@@ -11,7 +11,7 @@ maintainers:
- Alexandre TORGUE <alexandre.torgue@foss.st.com>
description: |
- STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware
+ STMicroelectronics's STM32 MCUs integrate a GPIO and Pin mux/config hardware
controller. It controls the input/output settings on the available pins and
also provides ability to multiplex and configure the output of various
on-chip controllers onto these pads.
@@ -27,14 +27,21 @@ properties:
- st,stm32mp135-pinctrl
- st,stm32mp157-pinctrl
- st,stm32mp157-z-pinctrl
+ - st,stm32mp257-pinctrl
+ - st,stm32mp257-z-pinctrl
'#address-cells':
const: 1
+
'#size-cells':
const: 1
ranges: true
- pins-are-numbered: true
+
+ pins-are-numbered:
+ $ref: /schemas/types.yaml#/definitions/flag
+ deprecated: true
+
hwlocks: true
interrupts:
@@ -42,9 +49,10 @@ properties:
st,syscfg:
description: Phandle+args to the syscon node which includes IRQ mux selection.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- - items:
+ - minItems: 2
+ items:
- description: syscon node which includes IRQ mux selection
- description: The offset of the IRQ mux selection register
- description: The field mask of IRQ mux, needed if different of 0xf
@@ -54,7 +62,7 @@ properties:
Indicates the SOC package used.
More details in include/dt-bindings/pinctrl/stm32-pinfunc.h
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 4, 8]
+ enum: [0x1, 0x2, 0x4, 0x8, 0x100, 0x400, 0x800]
patternProperties:
'^gpio@[0-9a-f]*$':
@@ -62,18 +70,29 @@ patternProperties:
additionalProperties: false
properties:
gpio-controller: true
+
'#gpio-cells':
const: 2
+ interrupt-controller: true
+ '#interrupt-cells':
+ const: 2
+
reg:
maxItems: 1
+
clocks:
maxItems: 1
+
resets:
maxItems: 1
+
+ gpio-line-names: true
+
gpio-ranges:
minItems: 1
maxItems: 16
+
ngpios:
description:
Number of available gpios in a bank.
@@ -83,7 +102,7 @@ patternProperties:
st,bank-name:
description:
Should be a name string for this bank as specified in the datasheet.
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- GPIOA
- GPIOB
@@ -102,10 +121,16 @@ patternProperties:
description:
Should correspond to the EXTI IOport selection (EXTI line used
to select GPIOs as interrupts).
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 11
+ patternProperties:
+ "^(.+-hog(-[0-9]+)?)$":
+ type: object
+ required:
+ - gpio-hog
+
required:
- gpio-controller
- '#gpio-cells'
@@ -115,17 +140,22 @@ patternProperties:
'-[0-9]*$':
type: object
+ additionalProperties: false
+
patternProperties:
'^pins':
type: object
+ additionalProperties: false
description: |
A pinctrl node should contain at least one subnode representing the
pinctrl group available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
configuration, pullups, drive, output high/low and output speed.
+ $ref: /schemas/pinctrl/pincfg-node.yaml
+
properties:
pinmux:
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Integer array, represents gpio pin number and mux setting.
Supported pin number and mux varies for different SoCs, and are
@@ -142,11 +172,15 @@ patternProperties:
* ...
* 16 : Alternate Function 15
* 17 : Analog
+ * 18 : Reserved
To simplify the usage, macro is available to generate "pinmux" field.
This macro is available here:
- include/dt-bindings/pinctrl/stm32-pinfunc.h
+ Setting the pinmux's function to the Reserved (RSVD) value is used to inform
+ the driver that it shall not apply the mux setting. This can be used to
+ reserve some pins, for example to a co-processor not running Linux.
Some examples of using macro:
- /* GPIO A9 set as alernate function 2 */
+ /* GPIO A9 set as alternate function 2 */
... {
pinmux = <STM32_PINMUX('A', 9, AF2)>;
};
@@ -158,42 +192,98 @@ patternProperties:
... {
pinmux = <STM32_PINMUX('A', 9, ANALOG)>;
};
+ /* GPIO A9 reserved for co-processor */
+ ... {
+ pinmux = <STM32_PINMUX('A', 9, RSVD)>;
+ };
+
+ bias-disable: true
+
+ bias-pull-down: true
+
+ bias-pull-up: true
+
+ drive-push-pull: true
+
+ drive-open-drain: true
+
+ output-low: true
+
+ output-high: true
- bias-disable:
- type: boolean
- bias-pull-down:
- type: boolean
- bias-pull-up:
- type: boolean
- drive-push-pull:
- type: boolean
- drive-open-drain:
- type: boolean
- output-low:
- type: boolean
- output-high:
- type: boolean
slew-rate:
description: |
0: Low speed
1: Medium speed
2: Fast speed
3: High speed
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2, 3]
+ minimum: 0
+ maximum: 3
+
+ skew-delay-input-ps:
+ description: |
+ IO synchronization skew rate applied to the input path
+ enum: [0, 300, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, 3250]
+
+ skew-delay-output-ps:
+ description: |
+ IO synchronization latch delay applied to the output path
+ enum: [0, 300, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, 3250]
+
+ st,io-sync:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - pass-through
+ - clock inverted
+ - data on rising edge
+ - data on falling edge
+ - data on both edges
+ description: |
+ IO synchronization through re-sampling or inversion
+ "pass-through" - data or clock GPIO pass-through
+ "clock inverted" - clock GPIO inverted
+ "data on rising edge" - data GPIO re-sampled on clock rising edge
+ "data on falling edge" - data GPIO re-sampled on clock falling edge
+ "data on both edges" - data GPIO re-sampled on both clock edges
+ default: pass-through
required:
- pinmux
+ # Not allowed both skew-delay-input-ps and skew-delay-output-ps
+ if:
+ required:
+ - skew-delay-input-ps
+ then:
+ properties:
+ skew-delay-output-ps: false
+
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32mp257-pinctrl
+ - st,stm32mp257-z-pinctrl
+ then:
+ patternProperties:
+ '-[0-9]*$':
+ patternProperties:
+ '^pins':
+ properties:
+ skew-delay-input-ps: false
+ skew-delay-output-ps: false
+ st,io-sync: false
required:
- compatible
- '#address-cells'
- '#size-cells'
- ranges
- - pins-are-numbered
additionalProperties: false
@@ -207,7 +297,6 @@ examples:
#size-cells = <1>;
compatible = "st,stm32f429-pinctrl";
ranges = <0 0x40020000 0x3000>;
- pins-are-numbered;
gpioa: gpio@0 {
gpio-controller;
@@ -225,7 +314,6 @@ examples:
#size-cells = <1>;
compatible = "st,stm32f429-pinctrl";
ranges = <0 0x50020000 0x3000>;
- pins-are-numbered;
gpiob: gpio@1000 {
gpio-controller;
@@ -271,4 +359,25 @@ examples:
pinctrl-names = "default";
};
+ - |
+ #include <dt-bindings/pinctrl/stm32-pinfunc.h>
+ //Example 4 skew-delay and st,io-sync
+ pinctrl: pinctrl@44240000 {
+ compatible = "st,stm32mp257-pinctrl";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x44240000 0xa0400>;
+
+ eth3_rgmii_pins_a: eth3-rgmii-0 {
+ pins1 {
+ pinmux = <STM32_PINMUX('A', 6, AF14)>;
+ st,io-sync = "data on both edges";
+ };
+ pins2 {
+ pinmux = <STM32_PINMUX('H', 2, AF14)>;
+ skew-delay-output-ps = <500>;
+ };
+ };
+ };
+
...
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml
index 92963604422f..3f14eab01c54 100644
--- a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pinctrl/starfive,jh7100-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: StarFive JH7100 Pin Controller Device Tree Bindings
+title: StarFive JH7100 Pin Controller
description: |
Bindings for the JH7100 RISC-V SoC from StarFive Ltd.
@@ -32,7 +32,6 @@ description: |
| | | | | | -------
UART0 UART1 --
-
The big MUX in the diagram only has 7 different ways of mapping peripherals
on the left to pins on the right. StarFive calls the 7 configurations "signal
groups".
@@ -111,7 +110,7 @@ patternProperties:
pins it needs, and how they should be configured, with regard to
muxer configuration, bias, input enable/disable, input schmitt
trigger enable/disable, slew-rate and drive strength.
- $ref: "/schemas/pinctrl/pincfg-node.yaml"
+ $ref: /schemas/pinctrl/pincfg-node.yaml
properties:
pins:
@@ -120,14 +119,14 @@ patternProperties:
This should be set using either the PAD_GPIO or PAD_FUNC_SHARE
macros.
Either this or "pinmux" has to be specified, but not both.
- $ref: "/schemas/pinctrl/pinmux-node.yaml#/properties/pins"
+ $ref: /schemas/pinctrl/pinmux-node.yaml#/properties/pins
pinmux:
description: |
The list of GPIOs and their mux settings that properties in the
node apply to. This should be set using the GPIOMUX macro.
Either this or "pins" has to be specified, but not both.
- $ref: "/schemas/pinctrl/pinmux-node.yaml#/properties/pinmux"
+ $ref: /schemas/pinctrl/pinmux-node.yaml#/properties/pinmux
bias-disable: true
@@ -165,7 +164,7 @@ examples:
- |
#include <dt-bindings/clock/starfive-jh7100.h>
#include <dt-bindings/reset/starfive-jh7100.h>
- #include <dt-bindings/pinctrl/pinctrl-starfive.h>
+ #include <dt-bindings/pinctrl/pinctrl-starfive-jh7100.h>
soc {
#address-cells = <2>;
@@ -293,7 +292,7 @@ examples:
pinctrl-names = "default";
};
- i2c0 {
+ i2c {
pinctrl-0 = <&i2c0_pins_default>;
pinctrl-names = "default";
};
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml
new file mode 100644
index 000000000000..4dbef86bd958
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-aon-pinctrl.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh7110-aon-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 AON Pin Controller
+
+description: |
+ Bindings for the JH7110 RISC-V SoC from StarFive Technology Ltd.
+
+ Out of the SoC's many pins only the ones named PAD_RGPIO0 to PAD_RGPIO3
+ can be multiplexed and have configurable bias, drive strength,
+ schmitt trigger etc.
+ Some peripherals such as PWM have their I/O go through the 4 "GPIOs".
+
+maintainers:
+ - Hal Feng <hal.feng@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-aon-pinctrl
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+patternProperties:
+ '-[0-9]+$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '-pins$':
+ type: object
+ description: |
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to
+ muxer configuration, bias, input enable/disable, input schmitt
+ trigger enable/disable, slew-rate and drive strength.
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the GPIOMUX macro.
+
+ bias-disable: true
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ drive-strength:
+ enum: [ 2, 4, 8, 12 ]
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ slew-rate:
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@17020000 {
+ compatible = "starfive,jh7110-aon-pinctrl";
+ reg = <0x17020000 0x10000>;
+ resets = <&aoncrg 2>;
+ interrupts = <85>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ pwm-0 {
+ pwm-pins {
+ pinmux = <0xff030802>;
+ bias-disable;
+ drive-strength = <12>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml
new file mode 100644
index 000000000000..e2a25a20f6a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7110-sys-pinctrl.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/starfive,jh7110-sys-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 SYS Pin Controller
+
+description: |
+ Bindings for the JH7110 RISC-V SoC from StarFive Technology Ltd.
+
+ Out of the SoC's many pins only the ones named PAD_GPIO0 to PAD_GPIO63
+ can be multiplexed and have configurable bias, drive strength,
+ schmitt trigger etc.
+ Some peripherals have their I/O go through the 64 "GPIOs". This also
+ includes a number of other UARTs, I2Cs, SPIs, PWMs etc.
+ All these peripherals are connected to all 64 GPIOs such that
+ any GPIO can be set up to be controlled by any of the peripherals.
+
+maintainers:
+ - Hal Feng <hal.feng@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-sys-pinctrl
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+patternProperties:
+ '-[0-9]+$':
+ type: object
+ additionalProperties: false
+ patternProperties:
+ '-pins$':
+ type: object
+ description: |
+ A pinctrl node should contain at least one subnode representing the
+ pinctrl groups available on the machine. Each subnode will list the
+ pins it needs, and how they should be configured, with regard to
+ muxer configuration, bias, input enable/disable, input schmitt
+ trigger enable/disable, slew-rate and drive strength.
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+ additionalProperties: false
+
+ properties:
+ pinmux:
+ description: |
+ The list of GPIOs and their mux settings that properties in the
+ node apply to. This should be set using the GPIOMUX or PINMUX
+ macros.
+
+ bias-disable: true
+
+ bias-pull-up:
+ type: boolean
+
+ bias-pull-down:
+ type: boolean
+
+ drive-strength:
+ enum: [ 2, 4, 8, 12 ]
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ slew-rate:
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@13040000 {
+ compatible = "starfive,jh7110-sys-pinctrl";
+ reg = <0x13040000 0x10000>;
+ clocks = <&syscrg 112>;
+ resets = <&syscrg 2>;
+ interrupts = <86>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ uart0-0 {
+ tx-pins {
+ pinmux = <0xff140005>;
+ bias-disable;
+ drive-strength = <12>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+
+ rx-pins {
+ pinmux = <0x0E000406>;
+ bias-pull-up;
+ drive-strength = <2>;
+ input-enable;
+ input-schmitt-enable;
+ slew-rate = <0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml
index 15092fdd4b5b..94b868c7ceb1 100644
--- a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/pinctrl/sunplus,sp7021-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Sunplus SP7021 Pin Controller Device Tree Bindings
+title: Sunplus SP7021 Pin Controller
maintainers:
- Dvorkin Dmitry <dvorkin@tibbo.com>
@@ -138,7 +138,7 @@ patternProperties:
description: |
Define pin-function which is used by pinctrl node's client device.
The name should be one of string in the following enumeration.
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum: [ SPI_FLASH, SPI_FLASH_4BIT, SPI_NAND, CARD0_EMMC, SD_CARD,
UA0, FPGA_IFX, HDMI_TX, LCDIF, USB0_OTG, USB1_OTG ]
@@ -146,7 +146,7 @@ patternProperties:
description: |
Define pin-group in a specified pin-function.
The name should be one of string in the following enumeration.
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum: [ SPI_FLASH1, SPI_FLASH2, SPI_FLASH_4BIT1, SPI_FLASH_4BIT2,
SPI_NAND, CARD0_EMMC, SD_CARD, UA0, FPGA_IFX, HDMI_TX1,
HDMI_TX2, HDMI_TX3, LCDIF, USB0_OTG, USB1_OTG ]
@@ -289,7 +289,7 @@ required:
additionalProperties: false
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
examples:
- |
diff --git a/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml
new file mode 100644
index 000000000000..21f86740a63d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/thead,th1520-pinctrl.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/thead,th1520-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-Head TH1520 SoC pin controller
+
+maintainers:
+ - Emil Renner Berthing <emil.renner.berthing@canonical.com>
+
+description: |
+ Pinmux and pinconf controller in the T-Head TH1520 RISC-V SoC.
+
+ The TH1520 has 3 groups of pads each controlled from different memory ranges.
+ Confusingly the memory ranges are named
+ PADCTRL_AOSYS -> PAD Group 1
+ PADCTRL1_APSYS -> PAD Group 2
+ PADCTRL0_APSYS -> PAD Group 3
+
+ Each pad can be muxed individually to up to 6 different functions. For most
+ pads only a few of those 6 configurations are valid though, and a few pads in
+ group 1 does not support muxing at all.
+
+ Pinconf is fairly regular except for a few pads in group 1 that either can't
+ be configured or has some special functions. The rest have configurable drive
+ strength, input enable, schmitt trigger, slew rate, pull-up and pull-down in
+ addition to a special strong pull up.
+
+ Certain pads in group 1 can be muxed to AUDIO_PA0 - AUDIO_PA30 functions and
+ are then meant to be used by the audio co-processor. Each such pad can then
+ be further muxed to either audio GPIO or one of 4 functions such as UART, I2C
+ and I2S. If the audio pad is muxed to one of the 4 functions then pinconf is
+ also configured in different registers. All of this is done from a different
+ AUDIO_IOCTRL memory range and is left to the audio co-processor for now.
+
+properties:
+ compatible:
+ enum:
+ - thead,th1520-pinctrl
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ thead,pad-group:
+ description: |
+ Select the pad group that is associated with the pin controller instance.
+
+ Base Address Name Group
+ 0xFF_FFF4_A000 PADCTRL_AOSYS 1
+ 0xFF_E7F3_C000 PADCTRL1_APSYS 2
+ 0xFF_EC00_7000 PADCTRL0_APSYS 3
+
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3]
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+patternProperties:
+ '-[0-9]+$':
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ '-pins$':
+ type: object
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+
+ additionalProperties: false
+
+ description:
+ A pinctrl node should contain at least one subnode describing one
+ or more pads and their associated pinmux and pinconf settings.
+
+ properties:
+ pins:
+ description: List of pads that properties in the node apply to.
+
+ function:
+ enum: [ gpio, pwm, uart, ir, i2c, spi, qspi, sdio, audio, i2s,
+ gmac0, gmac1, dpu0, dpu1, isp, hdmi, bootsel, debug,
+ clock, jtag, iso7816, efuse, reset ]
+ description: The mux function to select for the given pins.
+
+ bias-disable: true
+
+ bias-pull-up:
+ oneOf:
+ - type: boolean
+ description: Enable the regular 48kOhm pull-up
+ - enum: [ 2100, 48000 ]
+ description: Enable the strong 2.1kOhm pull-up or regular 48kOhm pull-up
+
+ bias-pull-down:
+ oneOf:
+ - type: boolean
+ - const: 44000
+ description: Enable the regular 44kOhm pull-down
+
+ drive-strength:
+ enum: [ 1, 2, 3, 5, 7, 8, 10, 12, 13, 15, 16, 18, 20, 21, 23, 25 ]
+ description: Drive strength in mA
+
+ input-enable: true
+
+ input-disable: true
+
+ input-schmitt-enable: true
+
+ input-schmitt-disable: true
+
+ slew-rate:
+ maximum: 1
+
+ required:
+ - pins
+
+additionalProperties: false
+
+examples:
+ - |
+ padctrl0_apsys: pinctrl@ec007000 {
+ compatible = "thead,th1520-pinctrl";
+ reg = <0xec007000 0x1000>;
+ clocks = <&apb_clk>;
+ thead,pad-group = <3>;
+
+ uart0_pins: uart0-0 {
+ tx-pins {
+ pins = "UART0_TXD";
+ function = "uart";
+ bias-disable;
+ drive-strength = <3>;
+ input-disable;
+ input-schmitt-disable;
+ slew-rate = <0>;
+ };
+
+ rx-pins {
+ pins = "UART0_RXD";
+ function = "uart";
+ bias-disable;
+ drive-strength = <1>;
+ input-enable;
+ input-schmitt-enable;
+ slew-rate = <0>;
+ };
+ };
+ };
+
+ padctrl1_apsys: pinctrl@e7f3c000 {
+ compatible = "thead,th1520-pinctrl";
+ reg = <0xe7f3c000 0x1000>;
+ clocks = <&apb_clk>;
+ thead,pad-group = <2>;
+
+ i2c5_pins: i2c5-0 {
+ i2c-pins {
+ pins = "QSPI1_CSN0", /* I2C5_SCL */
+ "QSPI1_D0_MOSI"; /* I2C5_SDA */
+ function = "i2c";
+ bias-pull-up = <2100>;
+ drive-strength = <7>;
+ input-enable;
+ input-schmitt-enable;
+ slew-rate = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt
deleted file mode 100644
index 88c80273da91..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-OMAP Pinctrl definitions
-
-Required properties:
-- compatible : Should be one of:
- "ti,omap2420-padconf" - OMAP2420 compatible pinctrl
- "ti,omap2430-padconf" - OMAP2430 compatible pinctrl
- "ti,omap3-padconf" - OMAP3 compatible pinctrl
- "ti,omap4-padconf" - OMAP4 compatible pinctrl
- "ti,omap5-padconf" - OMAP5 compatible pinctrl
- "ti,dra7-padconf" - DRA7 compatible pinctrl
- "ti,am437-padconf" - AM437x compatible pinctrl
-
-See Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt for further details.
diff --git a/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml
index 306524885a2b..0eff0a0ee9e9 100644
--- a/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml
@@ -21,7 +21,7 @@ properties:
maxItems: 1
allOf:
- - $ref: "pinctrl.yaml#"
+ - $ref: pinctrl.yaml#
required:
- compatible
@@ -35,13 +35,13 @@ patternProperties:
pinctrl groups available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
configuration, pullups, drive strength.
- $ref: "pinmux-node.yaml"
+ $ref: pinmux-node.yaml
+ additionalProperties: false
properties:
function:
description:
Function to mux.
- $ref: "/schemas/types.yaml#/definitions/string"
enum: [i2c0, i2c1, i2c2, i2c3, i2c4, i2c5, i2c6, i2c7, i2c8,
spi0, spi1, spi2, spi3, spi4, spi5, spi6,
uart0, uart1, uart2, uart3, pwm, pcmif_out, pcmif_in]
@@ -49,18 +49,20 @@ patternProperties:
groups:
description:
Name of the pin group to use for the functions.
- $ref: "/schemas/types.yaml#/definitions/string"
- enum: [i2c0_grp, i2c1_grp, i2c2_grp, i2c3_grp, i2c4_grp,
- i2c5_grp, i2c6_grp, i2c7_grp, i2c8_grp,
- spi0_grp, spi0_cs0_grp, spi0_cs1_grp, spi0_cs2_grp,
- spi1_grp, spi2_grp, spi3_grp, spi4_grp, spi5_grp, spi6_grp,
- uart0_grp, uart1_grp, uart2_grp, uart3_grp,
- pwm0_gpio4_grp, pwm0_gpio8_grp, pwm0_gpio12_grp,
- pwm0_gpio16_grp, pwm1_gpio5_grp, pwm1_gpio9_grp,
- pwm1_gpio13_grp, pwm1_gpio17_grp, pwm2_gpio6_grp,
- pwm2_gpio10_grp, pwm2_gpio14_grp, pwm2_gpio18_grp,
- pwm3_gpio7_grp, pwm3_gpio11_grp, pwm3_gpio15_grp,
- pwm3_gpio19_grp, pcmif_out_grp, pcmif_in_grp]
+ items:
+ enum: [i2c0_grp, i2c1_grp, i2c2_grp, i2c3_grp, i2c4_grp,
+ i2c5_grp, i2c6_grp, i2c7_grp, i2c8_grp,
+ spi0_grp, spi0_cs0_grp, spi0_cs1_grp, spi0_cs2_grp,
+ spi1_grp, spi2_grp, spi3_grp, spi4_grp, spi5_grp, spi6_grp,
+ uart0_grp, uart1_grp, uart2_grp, uart3_grp,
+ pwm0_gpio4_grp, pwm0_gpio8_grp, pwm0_gpio12_grp,
+ pwm0_gpio16_grp, pwm1_gpio5_grp, pwm1_gpio9_grp,
+ pwm1_gpio13_grp, pwm1_gpio17_grp, pwm2_gpio6_grp,
+ pwm2_gpio10_grp, pwm2_gpio14_grp, pwm2_gpio18_grp,
+ pwm3_gpio7_grp, pwm3_gpio11_grp, pwm3_gpio15_grp,
+ pwm3_gpio19_grp, pcmif_out_grp, pcmif_in_grp]
+ minItems: 1
+ maxItems: 8
drive-strength:
enum: [2, 4, 6, 8, 16, 24, 32]
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml
new file mode 100644
index 000000000000..70548cb37ada
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml
@@ -0,0 +1,210 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,pinctrl-zynq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynq Pinctrl
+
+maintainers:
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+description: |
+ Please refer to pinctrl-bindings.txt in this directory for details of the
+ common pinctrl bindings used by client devices, including the meaning of the
+ phrase "pin configuration node".
+
+ Zynq's pin configuration nodes act as a container for an arbitrary number of
+ subnodes. Each of these subnodes represents some desired configuration for a
+ pin, a group, or a list of pins or groups. This configuration can include the
+ mux function to select on those pin(s)/group(s), and various pin configuration
+ parameters, such as pull-up, slew rate, etc.
+
+ Each configuration node can consist of multiple nodes describing the pinmux and
+ pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+ The name of each subnode is not important; all subnodes should be enumerated
+ and processed purely based on their content.
+
+properties:
+ compatible:
+ const: xlnx,pinctrl-zynq
+
+ reg:
+ description: Specifies the base address and size of the SLCR space.
+ maxItems: 1
+
+ syscon:
+ description:
+ phandle to the SLCR.
+
+patternProperties:
+ '^(.*-)?(default|gpio-grp)$':
+ type: object
+ patternProperties:
+ '^mux':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for pin muxes,
+ which in turn use below standard properties.
+ $ref: pinmux-node.yaml#
+
+ properties:
+ groups:
+ description:
+ List of groups to select (either this or "pins" must be
+ specified), available groups for this subnode.
+ items:
+ enum: [ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp,
+ mdio1_0_grp, qspi0_0_grp, qspi1_0_grp, qspi_fbclk,
+ qspi_cs1_grp, spi0_0_grp, spi0_1_grp, spi0_2_grp,
+ spi0_0_ss0, spi0_0_ss1, spi0_0_ss2, spi0_1_ss0,
+ spi0_1_ss1, spi0_1_ss2, spi0_2_ss0, spi0_2_ss1,
+ spi0_2_ss2, spi1_0_grp, spi1_1_grp, spi1_2_grp,
+ spi1_3_grp, spi1_0_ss0, spi1_0_ss1, spi1_0_ss2,
+ spi1_1_ss0, spi1_1_ss1, spi1_1_ss2, spi1_2_ss0,
+ spi1_2_ss1, spi1_2_ss2, spi1_3_ss0, spi1_3_ss1,
+ spi1_3_ss2, sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio1_0_grp, sdio1_1_grp, sdio1_2_grp, sdio1_3_grp,
+ sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp,
+ sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp,
+ smc0_nor_addr25_grp, smc0_nand, can0_0_grp, can0_1_grp,
+ can0_2_grp, can0_3_grp, can0_4_grp, can0_5_grp,
+ can0_6_grp, can0_7_grp, can0_8_grp, can0_9_grp,
+ can0_10_grp, can1_0_grp, can1_1_grp, can1_2_grp,
+ can1_3_grp, can1_4_grp, can1_5_grp, can1_6_grp,
+ can1_7_grp, can1_8_grp, can1_9_grp, can1_10_grp,
+ can1_11_grp, uart0_0_grp, uart0_1_grp, uart0_2_grp,
+ uart0_3_grp, uart0_4_grp, uart0_5_grp, uart0_6_grp,
+ uart0_7_grp, uart0_8_grp, uart0_9_grp, uart0_10_grp,
+ uart1_0_grp, uart1_1_grp, uart1_2_grp, uart1_3_grp,
+ uart1_4_grp, uart1_5_grp, uart1_6_grp, uart1_7_grp,
+ uart1_8_grp, uart1_9_grp, uart1_10_grp, uart1_11_grp,
+ i2c0_0_grp, i2c0_1_grp, i2c0_2_grp, i2c0_3_grp,
+ i2c0_4_grp, i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
+ i2c0_8_grp, i2c0_9_grp, i2c0_10_grp, i2c1_0_grp,
+ i2c1_1_grp, i2c1_2_grp, i2c1_3_grp, i2c1_4_grp,
+ i2c1_5_grp, i2c1_6_grp, i2c1_7_grp, i2c1_8_grp,
+ i2c1_9_grp, i2c1_10_grp, ttc0_0_grp, ttc0_1_grp,
+ ttc0_2_grp, ttc1_0_grp, ttc1_1_grp, ttc1_2_grp,
+ swdt0_0_grp, swdt0_1_grp, swdt0_2_grp, swdt0_3_grp,
+ swdt0_4_grp, gpio0_0_grp, gpio0_1_grp, gpio0_2_grp,
+ gpio0_3_grp, gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
+ gpio0_7_grp, gpio0_8_grp, gpio0_9_grp, gpio0_10_grp,
+ gpio0_11_grp, gpio0_12_grp, gpio0_13_grp, gpio0_14_grp,
+ gpio0_15_grp, gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
+ gpio0_19_grp, gpio0_20_grp, gpio0_21_grp, gpio0_22_grp,
+ gpio0_23_grp, gpio0_24_grp, gpio0_25_grp, gpio0_26_grp,
+ gpio0_27_grp, gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
+ gpio0_31_grp, gpio0_32_grp, gpio0_33_grp, gpio0_34_grp,
+ gpio0_35_grp, gpio0_36_grp, gpio0_37_grp, gpio0_38_grp,
+ gpio0_39_grp, gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
+ gpio0_43_grp, gpio0_44_grp, gpio0_45_grp, gpio0_46_grp,
+ gpio0_47_grp, gpio0_48_grp, gpio0_49_grp, gpio0_50_grp,
+ gpio0_51_grp, gpio0_52_grp, gpio0_53_grp, usb0_0_grp,
+ usb1_0_grp]
+ maxItems: 54
+
+ function:
+ description:
+ Specify the alternative function to be configured for the
+ given pin groups.
+ enum: [ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk,
+ qspi_cs1, spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc,
+ sdio0_cd, sdio0_wp, sdio1, sdio1_pc, sdio1_cd, sdio1_wp,
+ smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0,
+ can1, uart0, uart1, i2c0, i2c1, ttc0, ttc1, swdt0, gpio0,
+ usb0, usb1]
+
+ required:
+ - groups
+ - function
+
+ additionalProperties: false
+
+ '^conf':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for pin configurations,
+ which in turn use the standard properties below.
+ $ref: pincfg-node.yaml#
+
+ properties:
+ groups:
+ description:
+ List of pin groups as mentioned above.
+
+ pins:
+ description:
+ List of pin names to select in this subnode.
+ items:
+ pattern: '^MIO([0-9]|[1-4][0-9]|5[0-3])$'
+ maxItems: 54
+
+ bias-pull-up: true
+
+ bias-pull-down: true
+
+ bias-disable: true
+
+ bias-high-impedance: true
+
+ low-power-enable: true
+
+ low-power-disable: true
+
+ slew-rate:
+ enum: [0, 1]
+
+ power-source:
+ enum: [1, 2, 3, 4]
+
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+ - reg
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-zynq.h>
+ pinctrl@700 {
+ compatible = "xlnx,pinctrl-zynq";
+ reg = <0x700 0x200>;
+ syscon = <&slcr>;
+
+ uart1-default {
+ mux {
+ groups = "uart1_10_grp";
+ function = "uart1";
+ };
+
+ conf {
+ groups = "uart1_10_grp";
+ slew-rate = <0>;
+ power-source = <IO_STANDARD_LVCMOS18>;
+ };
+
+ conf-rx {
+ pins = "MIO49";
+ bias-high-impedance;
+ };
+
+ conf-tx {
+ pins = "MIO48";
+ bias-disable;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,versal-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,versal-pinctrl.yaml
new file mode 100644
index 000000000000..81e2164ea98f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,versal-pinctrl.yaml
@@ -0,0 +1,279 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,versal-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal Pinctrl
+
+maintainers:
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+description: |
+ Please refer to pinctrl-bindings.txt in this directory for details of the
+ common pinctrl bindings used by client devices, including the meaning of the
+ phrase "pin configuration node".
+
+ Versal's pin configuration nodes act as a container for an arbitrary number of
+ subnodes. Each of these subnodes represents some desired configuration for a
+ pin, a group, or a list of pins or groups. This configuration can include the
+ mux function to select on those pin(s)/group(s), and various pin configuration
+ parameters, such as pull-up, slew rate, etc.
+
+ Each configuration node can consist of multiple nodes describing the pinmux and
+ pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+properties:
+ compatible:
+ const: xlnx,versal-pinctrl
+
+patternProperties:
+ '^(.*-)?(default|gpio-grp)$':
+ type: object
+ patternProperties:
+ '^mux':
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for pin muxes,
+ which in turn use below standard properties.
+ $ref: pinmux-node.yaml#
+
+ properties:
+ pins:
+ description:
+ List of pins to select (either this or "groups" must be specified)
+ $ref: "#/$defs/pins/properties/pins"
+
+ groups:
+ description:
+ List of groups to select (either this or "pins" must be
+ specified), available groups for this subnode.
+ anyOf:
+ - pattern: '^((LPD|PMC)_)MIO([0-9]|[1-6][0-9]|7[0-7])$'
+ - $ref: "#/$defs/pins/properties/groups"
+
+ function:
+ description:
+ Specify the alternative function to be configured for the
+ given pin groups.
+ enum: [spi0, spi0_ss, spi1, spi1_ss, can0, can1, i2c0, i2c1, i2c_pmc, ttc0_clk,
+ ttc0_wav, ttc1_clk, ttc1_wav, ttc2_clk, ttc2_wav, ttc3_clk, ttc3_wav, wwdt0,
+ wwdt1, sysmon_i2c0, sysmon_i2c0_alrt, uart0, uart0_ctrl, uart1, uart1_ctrl,
+ gpio0, gpio1, gpio2, emio0, gem0, gem1, trace0, trace0_clk, mdio0, mdio1, gem_tsu0,
+ pcie0, smap0, usb0, sd0, sd0_pc, sd0_cd, sd0_wp, sd1, sd1_pc, sd1_wp, sd1_cd,
+ ospi0, ospi0_ss, qspi0, qspi0_fbclk, qspi0_ss, test_clk, test_scan, tamper_trigger]
+
+ required:
+ - function
+
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
+ additionalProperties: false
+
+ '^conf':
+ type: object
+ unevaluatedProperties: false
+ description:
+ Pinctrl node's client devices use subnodes for pin configurations,
+ which in turn use the standard properties below.
+ allOf:
+ - $ref: pincfg-node.yaml#
+ - $ref: "#/$defs/pins"
+
+ additionalProperties: false
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+$defs:
+ pins:
+ properties:
+ groups:
+ description:
+ List of pin groups to select in this subnode.
+ items:
+ enum: [spi0_0_grp, spi0_1_grp, spi0_2_grp, spi0_3_grp, spi0_4_grp, spi0_5_grp,
+ spi0_ss_0_grp, spi0_ss_1_grp, spi0_ss_2_grp, spi0_ss_3_grp, spi0_ss_4_grp,
+ spi0_ss_5_grp, spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp, spi0_ss_9_grp,
+ spi0_ss_10_grp, spi0_ss_11_grp, spi0_ss_12_grp, spi0_ss_13_grp, spi0_ss_14_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp, spi1_0_grp, spi1_1_grp,
+ spi1_2_grp, spi1_3_grp, spi1_4_grp, spi1_5_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_ss_3_grp, spi1_ss_4_grp, spi1_ss_5_grp, spi1_ss_6_grp,
+ spi1_ss_7_grp, spi1_ss_8_grp, spi1_ss_9_grp, spi1_ss_10_grp, spi1_ss_11_grp,
+ spi1_ss_12_grp, spi1_ss_13_grp, spi1_ss_14_grp, spi1_ss_15_grp, spi1_ss_16_grp
+ spi1_ss_17_grp, can0_0_grp, can0_1_grp, can0_2_grp, can0_3_grp, can0_4_grp,
+ can0_5_grp, can0_6_grp, can0_7_grp, can0_8_grp, can0_9_grp, can0_10_grp,
+ can0_11_grp, can0_12_grp, can0_13_grp, can0_14_grp, can0_15_grp, can0_16_grp,
+ can0_17_grp, can1_0_grp, can1_1_grp, can1_2_grp, can1_3_grp, can1_4_grp,
+ can1_5_grp, can1_6_grp, can1_7_grp, can1_8_grp, can1_9_grp, can1_10_grp,
+ can1_11_grp, can1_12_grp, can1_13_grp, can1_14_grp, can1_15_grp, can1_16_grp,
+ can1_17_grp, can1_18_grp, i2c0_0_grp, i2c0_1_grp, i2c0_2_grp, i2c0_3_grp,
+ i2c0_4_grp, i2c0_5_grp, i2c0_6_grp, i2c0_7_grp, i2c0_8_grp, i2c0_9_grp,
+ i2c0_10_grp, i2c0_11_grp, i2c0_12_grp, i2c0_13_grp, i2c0_14_grp, i2c0_15_grp,
+ i2c0_16_grp, i2c0_17_grp, i2c1_0_grp, i2c1_1_grp, i2c1_2_grp, i2c1_3_grp,
+ i2c1_4_grp, i2c1_5_grp, i2c1_6_grp, i2c1_7_grp, i2c1_8_grp, i2c1_9_grp,
+ i2c1_10_grp, i2c1_11_grp, i2c1_12_grp, i2c1_13_grp, i2c1_14_grp, i2c1_15_grp,
+ i2c1_16_grp, i2c1_17_grp, i2c1_18_grp, i2c_pmc_0_grp, i2c_pmc_1_grp,
+ i2c_pmc_2_grp, i2c_pmc_3_grp, i2c_pmc_4_grp, i2c_pmc_5_grp, i2c_pmc_6_grp,
+ i2c_pmc_7_grp, i2c_pmc_8_grp, i2c_pmc_9_grp, i2c_pmc_10_grp, i2c_pmc_11_grp,
+ i2c_pmc_12_grp, ttc0_clk_0_grp, ttc0_clk_1_grp, ttc0_clk_2_grp, ttc0_clk_3_grp,
+ ttc0_clk_4_grp, ttc0_clk_5_grp, ttc0_clk_6_grp, ttc0_clk_7_grp, ttc0_clk_8_grp,
+ ttc0_wav_0_grp, ttc0_wav_1_grp, ttc0_wav_2_grp, ttc0_wav_3_grp, ttc0_wav_4_grp,
+ ttc0_wav_5_grp, ttc0_wav_6_grp, ttc0_wav_7_grp, ttc0_wav_8_grp, ttc1_clk_0_grp,
+ ttc1_clk_1_grp, ttc1_clk_2_grp, ttc1_clk_3_grp, ttc1_clk_4_grp, ttc1_clk_5_grp,
+ ttc1_clk_6_grp, ttc1_clk_7_grp, ttc1_clk_8_grp, ttc1_wav_0_grp, ttc1_wav_1_grp,
+ ttc1_wav_2_grp, ttc1_wav_3_grp, ttc1_wav_4_grp, ttc1_wav_5_grp, ttc1_wav_6_grp,
+ ttc1_wav_7_grp, ttc1_wav_8_grp, ttc2_clk_0_grp, ttc2_clk_1_grp, ttc2_clk_2_grp,
+ ttc2_clk_3_grp, ttc2_clk_4_grp, ttc2_clk_5_grp, ttc2_clk_6_grp, ttc2_clk_7_grp,
+ ttc2_clk_8_grp, ttc2_wav_0_grp, ttc2_wav_1_grp, ttc2_wav_2_grp, ttc2_wav_3_grp,
+ ttc2_wav_4_grp, ttc2_wav_5_grp, ttc2_wav_6_grp, ttc2_wav_7_grp, ttc2_wav_8_grp,
+ ttc3_clk_0_grp, ttc3_clk_1_grp, ttc3_clk_2_grp, ttc3_clk_3_grp, ttc3_clk_4_grp,
+ ttc3_clk_5_grp, ttc3_clk_6_grp, ttc3_clk_7_grp, ttc3_clk_8_grp, ttc3_wav_0_grp,
+ ttc3_wav_1_grp, ttc3_wav_2_grp, ttc3_wav_3_grp, ttc3_wav_4_grp, ttc3_wav_5_grp,
+ ttc3_wav_6_grp, ttc3_wav_7_grp, ttc3_wav_8_grp, wwdt0_0_grp, wwdt0_1_grp,
+ wwdt0_2_grp, wwdt0_3_grp, wwdt0_4_grp, wwdt0_5_grp, wwdt1_0_grp, wwdt1_1_grp,
+ wwdt1_2_grp, wwdt1_3_grp, wwdt1_4_grp, wwdt1_5_grp, sysmon_i2c0_0_grp,
+ sysmon_i2c0_1_grp, sysmon_i2c0_2_grp, sysmon_i2c0_3_grp, sysmon_i2c0_4_grp,
+ sysmon_i2c0_5_grp, sysmon_i2c0_6_grp, sysmon_i2c0_7_grp, sysmon_i2c0_8_grp,
+ sysmon_i2c0_9_grp, sysmon_i2c0_10_grp, sysmon_i2c0_11_grp, sysmon_i2c0_12_grp,
+ sysmon_i2c0_13_grp, sysmon_i2c0_14_grp, sysmon_i2c0_15_grp,
+ sysmon_i2c0_16_grp, sysmon_i2c0_17_grp, sysmon_i2c0_alrt_0_grp,
+ sysmon_i2c0_alrt_1_grp, sysmon_i2c0_alrt_2_grp, sysmon_i2c0_alrt_3_grp,
+ sysmon_i2c0_alrt_4_grp, sysmon_i2c0_alrt_5_grp, sysmon_i2c0_alrt_6_grp,
+ sysmon_i2c0_alrt_7_grp, sysmon_i2c0_alrt_8_grp, sysmon_i2c0_alrt_9_grp,
+ sysmon_i2c0_alrt_10_grp, sysmon_i2c0_alrt_11_grp, sysmon_i2c0_alrt_12_grp,
+ sysmon_i2c0_alrt_13_grp, sysmon_i2c0_alrt_14_grp, sysmon_i2c0_alrt_15_grp,
+ sysmon_i2c0_alrt_16_grp, sysmon_i2c0_alrt_17_grp, uart0_0_grp, uart0_1_grp,
+ uart0_2_grp, uart0_3_grp, uart0_4_grp, uart0_5_grp, uart0_6_grp, uart0_7_grp,
+ uart0_8_grp, uart0_ctrl_0_grp, uart0_ctrl_1_grp, uart0_ctrl_2_grp,
+ uart0_ctrl_3_grp, uart0_ctrl_4_grp, uart0_ctrl_5_grp, uart0_ctrl_6_grp,
+ uart0_ctrl_7_grp, uart0_ctrl_8_grp, uart1_0_grp, uart1_1_grp, uart1_2_grp,
+ uart1_3_grp, uart1_4_grp, uart1_5_grp, uart1_6_grp, uart1_7_grp, uart1_8_grp,
+ uart1_ctrl_0_grp, uart1_ctrl_1_grp, uart1_ctrl_2_grp, uart1_ctrl_3_grp,
+ uart1_ctrl_4_grp, uart1_ctrl_5_grp, uart1_ctrl_6_grp, uart1_ctrl_7_grp,
+ uart1_ctrl_8_grp, gpio0_0_grp, gpio0_1_grp, gpio0_2_grp, gpio0_3_grp,
+ gpio0_4_grp, gpio0_5_grp, gpio0_6_grp, gpio0_7_grp, gpio0_8_grp, gpio0_9_grp,
+ gpio0_10_grp, gpio0_11_grp, gpio0_12_grp, gpio0_13_grp, gpio0_14_grp,
+ gpio0_15_grp, gpio0_16_grp, gpio0_17_grp, gpio0_18_grp, gpio0_19_grp,
+ gpio0_20_grp, gpio0_21_grp, gpio0_22_grp, gpio0_23_grp, gpio0_24_grp,
+ gpio0_25_grp, gpio1_0_grp, gpio1_1_grp, gpio1_2_grp, gpio1_3_grp, gpio1_4_grp,
+ gpio1_5_grp, gpio1_6_grp, gpio1_7_grp, gpio1_8_grp, gpio1_9_grp,
+ gpio1_10_grp, gpio1_11_grp, gpio1_12_grp, gpio1_13_grp, gpio1_14_grp,
+ gpio1_15_grp, gpio1_16_grp, gpio1_17_grp, gpio1_18_grp, gpio1_19_grp,
+ gpio1_20_grp, gpio1_21_grp, gpio1_22_grp, gpio1_23_grp, gpio1_24_grp,
+ gpio1_25_grp, gpio2_0_grp, gpio2_1_grp, gpio2_2_grp, gpio2_3_grp, gpio2_4_grp,
+ gpio2_5_grp, gpio2_6_grp, gpio2_7_grp, gpio2_8_grp, gpio2_9_grp, gpio2_10_grp,
+ gpio2_11_grp, gpio2_12_grp, gpio2_13_grp, gpio2_14_grp, gpio2_15_grp,
+ gpio2_16_grp, gpio2_17_grp, gpio2_18_grp, gpio2_19_grp, gpio2_20_grp,
+ gpio2_21_grp, gpio2_22_grp, gpio2_23_grp, gpio2_24_grp, gpio2_25_grp,
+ emio0_0_grp, emio0_1_grp, emio0_2_grp, emio0_3_grp, emio0_4_grp, emio0_5_grp,
+ emio0_6_grp, emio0_7_grp, emio0_8_grp, emio0_9_grp, emio0_10_grp,
+ emio0_11_grp, emio0_12_grp, emio0_13_grp, emio0_14_grp, emio0_15_grp,
+ emio0_16_grp, emio0_17_grp, emio0_18_grp, emio0_19_grp, emio0_20_grp,
+ emio0_21_grp, emio0_22_grp, emio0_23_grp, emio0_24_grp, emio0_25_grp,
+ emio0_26_grp, emio0_27_grp, emio0_28_grp, emio0_29_grp, emio0_30_grp,
+ emio0_31_grp, emio0_32_grp, emio0_33_grp, emio0_34_grp, emio0_35_grp,
+ emio0_36_grp, emio0_37_grp, emio0_38_grp, emio0_39_grp, emio0_40_grp,
+ emio0_41_grp, emio0_42_grp, emio0_43_grp, emio0_44_grp, emio0_45_grp,
+ emio0_46_grp, emio0_47_grp, emio0_48_grp, emio0_49_grp, emio0_50_grp,
+ emio0_51_grp, emio0_52_grp, emio0_53_grp, emio0_54_grp, emio0_55_grp,
+ emio0_56_grp, emio0_57_grp, emio0_58_grp, emio0_59_grp, emio0_60_grp,
+ emio0_61_grp, emio0_62_grp, emio0_63_grp, emio0_64_grp, emio0_65_grp,
+ emio0_66_grp, emio0_67_grp, emio0_68_grp, emio0_69_grp, emio0_70_grp,
+ emio0_71_grp, emio0_72_grp, emio0_73_grp, emio0_74_grp, emio0_75_grp,
+ emio0_76_grp, emio0_77_grp, gem0_0_grp, gem0_1_grp, gem1_0_grp, gem1_1_grp,
+ trace0_0_grp, trace0_1_grp, trace0_2_grp, trace0_clk_0_grp, trace0_clk_1_grp,
+ trace0_clk_2_grp, mdio0_0_grp, mdio0_1_grp, mdio1_0_grp, mdio1_1_grp,
+ gem_tsu0_0_grp, gem_tsu0_1_grp, gem_tsu0_2_grp, gem_tsu0_3_grp, pcie0_0_grp,
+ pcie0_1_grp, pcie0_2_grp, smap0_0_grp, usb0_0_grp, sd0_0_grp, sd0_1_grp,
+ sd0_2_grp, sd0_3_grp, sd0_4_grp, sd0_5_grp, sd0_6_grp, sd0_7_grp, sd0_8_grp,
+ sd0_9_grp, sd0_10_grp, sd0_11_grp, sd0_12_grp, sd0_13_grp, sd0_14_grp,
+ sd0_15_grp, sd0_16_grp, sd0_17_grp, sd0_18_grp, sd0_19_grp, sd0_20_grp,
+ sd0_21_grp, sd0_pc_0_grp, sd0_pc_1_grp, sd0_cd_0_grp, sd0_cd_1_grp,
+ sd0_wp_0_grp, sd0_wp_1_grp, sd1_0_grp, sd1_1_grp, sd1_2_grp, sd1_3_grp,
+ sd1_4_grp, sd1_5_grp, sd1_6_grp, sd1_7_grp, sd1_8_grp, sd1_9_grp, sd1_10_grp,
+ sd1_11_grp, sd1_12_grp, sd1_13_grp, sd1_14_grp, sd1_15_grp, sd1_16_grp,
+ sd1_17_grp, sd1_18_grp, sd1_19_grp, sd1_20_grp, sd1_21_grp, sd1_pc_0_grp,
+ sd1_pc_1_grp, sd1_cd_0_grp, sd1_cd_1_grp, sd1_wp_0_grp, sd1_wp_1_grp,
+ ospi0_0_grp, ospi0_ss_0_grp, qspi0_0_grp, qspi0_fbclk_0_grp, qspi0_ss_0_grp,
+ test_clk_0_grp, test_scan_0_grp, tamper_trigger_0_grp]
+ minItems: 1
+ maxItems: 78
+
+ pins:
+ description:
+ List of pin names to select in this subnode.
+ items:
+ pattern: '^((LPD|PMC)_)MIO([0-9]|[1-6][0-9]|7[0-7])$'
+ minItems: 1
+ maxItems: 78
+
+ bias-pull-up: true
+ bias-pull-down: true
+ bias-disable: true
+ input-schmitt-enable: true
+ input-schmitt-disable: true
+ bias-high-impedance: true
+ low-power-enable: true
+ low-power-disable: true
+
+ slew-rate:
+ enum: [0, 1]
+
+ output-enable:
+ description:
+ This will internally disable the tri-state for MIO pins.
+
+ drive-strength:
+ description:
+ Selects the drive strength for MIO pins, in mA.
+ enum: [2, 4, 8, 12]
+
+ power-source:
+ enum: [0, 1]
+
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
+ additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
+ pinctrl {
+ compatible = "xlnx,versal-pinctrl";
+
+ uart0-default {
+ mux {
+ groups = "uart0_4_grp", "uart0_5_grp";
+ function = "uart0";
+ };
+
+ conf {
+ groups = "uart0_4_grp";
+ slew-rate = <SLEW_RATE_SLOW>;
+ power-source = <IO_STANDARD_LVCMOS18>;
+ };
+
+ conf-rx {
+ pins = "PMC_MIO42";
+ bias-pull-up;
+ };
+
+ conf-tx {
+ pins = "PMC_MIO43";
+ bias-disable;
+ input-schmitt-disable;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
deleted file mode 100644
index cfd0cc549a7b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml
+++ /dev/null
@@ -1,217 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/pinctrl/xlnx,zynq-pinctrl.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Xilinx Zynq Pinctrl
-
-maintainers:
- - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
-
-description: |
- Please refer to pinctrl-bindings.txt in this directory for details of the
- common pinctrl bindings used by client devices, including the meaning of the
- phrase "pin configuration node".
-
- Zynq's pin configuration nodes act as a container for an arbitrary number of
- subnodes. Each of these subnodes represents some desired configuration for a
- pin, a group, or a list of pins or groups. This configuration can include the
- mux function to select on those pin(s)/group(s), and various pin configuration
- parameters, such as pull-up, slew rate, etc.
-
- Each configuration node can consist of multiple nodes describing the pinmux and
- pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
-
- The name of each subnode is not important; all subnodes should be enumerated
- and processed purely based on their content.
-
-properties:
- compatible:
- const: xlnx,zynq-pinctrl
-
- reg:
- description: Specifies the base address and size of the SLCR space.
- maxItems: 1
-
- syscon:
- description:
- phandle to the SLCR.
-
-patternProperties:
- '^(.*-)?(default|gpio)$':
- type: object
- patternProperties:
- '^mux':
- type: object
- description:
- Pinctrl node's client devices use subnodes for pin muxes,
- which in turn use below standard properties.
- $ref: pinmux-node.yaml#
-
- properties:
- groups:
- description:
- List of groups to select (either this or "pins" must be
- specified), available groups for this subnode.
- items:
- enum: [ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp,
- mdio1_0_grp, qspi0_0_grp, qspi1_0_grp, qspi_fbclk,
- qspi_cs1_grp, spi0_0_grp, spi0_1_grp, spi0_2_grp,
- spi0_0_ss0, spi0_0_ss1, spi0_0_ss2, spi0_1_ss0,
- spi0_1_ss1, spi0_1_ss2, spi0_2_ss0, spi0_2_ss1,
- spi0_2_ss2, spi1_0_grp, spi1_1_grp, spi1_2_grp,
- spi1_3_grp, spi1_0_ss0, spi1_0_ss1, spi1_0_ss2,
- spi1_1_ss0, spi1_1_ss1, spi1_1_ss2, spi1_2_ss0,
- spi1_2_ss1, spi1_2_ss2, spi1_3_ss0, spi1_3_ss1,
- spi1_3_ss2, sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
- sdio1_0_grp, sdio1_1_grp, sdio1_2_grp, sdio1_3_grp,
- sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp,
- sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp,
- smc0_nor_addr25_grp, smc0_nand, can0_0_grp, can0_1_grp,
- can0_2_grp, can0_3_grp, can0_4_grp, can0_5_grp,
- can0_6_grp, can0_7_grp, can0_8_grp, can0_9_grp,
- can0_10_grp, can1_0_grp, can1_1_grp, can1_2_grp,
- can1_3_grp, can1_4_grp, can1_5_grp, can1_6_grp,
- can1_7_grp, can1_8_grp, can1_9_grp, can1_10_grp,
- can1_11_grp, uart0_0_grp, uart0_1_grp, uart0_2_grp,
- uart0_3_grp, uart0_4_grp, uart0_5_grp, uart0_6_grp,
- uart0_7_grp, uart0_8_grp, uart0_9_grp, uart0_10_grp,
- uart1_0_grp, uart1_1_grp, uart1_2_grp, uart1_3_grp,
- uart1_4_grp, uart1_5_grp, uart1_6_grp, uart1_7_grp,
- uart1_8_grp, uart1_9_grp, uart1_10_grp, uart1_11_grp,
- i2c0_0_grp, i2c0_1_grp, i2c0_2_grp, i2c0_3_grp,
- i2c0_4_grp, i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
- i2c0_8_grp, i2c0_9_grp, i2c0_10_grp, i2c1_0_grp,
- i2c1_1_grp, i2c1_2_grp, i2c1_3_grp, i2c1_4_grp,
- i2c1_5_grp, i2c1_6_grp, i2c1_7_grp, i2c1_8_grp,
- i2c1_9_grp, i2c1_10_grp, ttc0_0_grp, ttc0_1_grp,
- ttc0_2_grp, ttc1_0_grp, ttc1_1_grp, ttc1_2_grp,
- swdt0_0_grp, swdt0_1_grp, swdt0_2_grp, swdt0_3_grp,
- swdt0_4_grp, gpio0_0_grp, gpio0_1_grp, gpio0_2_grp,
- gpio0_3_grp, gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
- gpio0_7_grp, gpio0_8_grp, gpio0_9_grp, gpio0_10_grp,
- gpio0_11_grp, gpio0_12_grp, gpio0_13_grp, gpio0_14_grp,
- gpio0_15_grp, gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
- gpio0_19_grp, gpio0_20_grp, gpio0_21_grp, gpio0_22_grp,
- gpio0_23_grp, gpio0_24_grp, gpio0_25_grp, gpio0_26_grp,
- gpio0_27_grp, gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
- gpio0_31_grp, gpio0_32_grp, gpio0_33_grp, gpio0_34_grp,
- gpio0_35_grp, gpio0_36_grp, gpio0_37_grp, gpio0_38_grp,
- gpio0_39_grp, gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
- gpio0_43_grp, gpio0_44_grp, gpio0_45_grp, gpio0_46_grp,
- gpio0_47_grp, gpio0_48_grp, gpio0_49_grp, gpio0_50_grp,
- gpio0_51_grp, gpio0_52_grp, gpio0_53_grp, usb0_0_grp,
- usb1_0_grp]
- maxItems: 54
-
- function:
- description:
- Specify the alternative function to be configured for the
- given pin groups.
- enum: [ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk,
- qspi_cs1, spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc,
- sdio0_cd, sdio0_wp, sdio1, sdio1_pc, sdio1_cd, sdio1_wp,
- smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0,
- can1, uart0, uart1, i2c0, i2c1, ttc0, ttc1, swdt0, gpio0,
- usb0, usb1]
-
- required:
- - groups
- - function
-
- additionalProperties: false
-
- '^conf':
- type: object
- description:
- Pinctrl node's client devices use subnodes for pin configurations,
- which in turn use the standard properties below.
- $ref: pincfg-node.yaml#
-
- properties:
- groups:
- description:
- List of pin groups as mentioned above.
-
- pins:
- description:
- List of pin names to select in this subnode.
- items:
- pattern: '^MIO([0-9]|[1-4][0-9]|5[0-3])$'
- maxItems: 54
-
- bias-pull-up: true
-
- bias-pull-down: true
-
- bias-disable: true
-
- bias-high-impedance: true
-
- low-power-enable: true
-
- low-power-disable: true
-
- slew-rate:
- enum: [0, 1]
-
- power-source:
- enum: [1, 2, 3, 4]
-
- oneOf:
- - required: [ groups ]
- - required: [ pins ]
-
- additionalProperties: false
-
- additionalProperties: false
-
-allOf:
- - $ref: "pinctrl.yaml#"
-
-required:
- - compatible
- - reg
- - syscon
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/pinctrl/pinctrl-zynq.h>
- pinctrl0: pinctrl@700 {
- compatible = "xlnx,zynq-pinctrl";
- reg = <0x700 0x200>;
- syscon = <&slcr>;
-
- pinctrl_uart1_default: uart1-default {
- mux {
- groups = "uart1_10_grp";
- function = "uart1";
- };
-
- conf {
- groups = "uart1_10_grp";
- slew-rate = <0>;
- power-source = <IO_STANDARD_LVCMOS18>;
- };
-
- conf-rx {
- pins = "MIO49";
- bias-high-impedance;
- };
-
- conf-tx {
- pins = "MIO48";
- bias-disable;
- };
- };
- };
-
- uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart1_default>;
- };
-
-...
diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
index 1e2b9b627b12..ce66fd15ff9c 100644
--- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx ZynqMP Pinctrl
maintainers:
- - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
- - Rajan Vaja <rajan.vaja@xilinx.com>
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
description: |
Please refer to pinctrl-bindings.txt in this directory for details of the
@@ -32,7 +31,7 @@ properties:
const: xlnx,zynqmp-pinctrl
patternProperties:
- '^(.*-)?(default|gpio)$':
+ '^(.*-)?(default|gpio-grp)$':
type: object
patternProperties:
'^mux':
@@ -43,179 +42,187 @@ patternProperties:
$ref: pinmux-node.yaml#
properties:
+ pins:
+ description:
+ List of pins to select (either this or "groups" must be specified)
+ items:
+ pattern: '^MIO([0-9]|[1-6][0-9]|7[0-7])$'
+
groups:
description:
List of groups to select (either this or "pins" must be
specified), available groups for this subnode.
items:
- enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
- ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
- gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
- mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
- qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
- spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
- spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
- spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
- spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
- spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
- spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
- spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
- spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
- spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
- spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
- spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
- spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
- spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
- spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
- spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
- spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
- sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
- sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
- sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
- sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
- sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
- sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
- sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
- sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
- sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
- sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
- sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
- sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
- sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
- sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
- sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
- sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
- sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
- sdio1_9_grp, sdio1_10_grp, sdio1_11_grp,
- sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
- sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
- sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
- sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
- nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
- nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
- can0_1_grp, can0_2_grp, can0_3_grp,
- can0_4_grp, can0_5_grp, can0_6_grp,
- can0_7_grp, can0_8_grp, can0_9_grp,
- can0_10_grp, can0_11_grp, can0_12_grp,
- can0_13_grp, can0_14_grp, can0_15_grp,
- can0_16_grp, can0_17_grp, can0_18_grp,
- can1_0_grp, can1_1_grp, can1_2_grp,
- can1_3_grp, can1_4_grp, can1_5_grp,
- can1_6_grp, can1_7_grp, can1_8_grp,
- can1_9_grp, can1_10_grp, can1_11_grp,
- can1_12_grp, can1_13_grp, can1_14_grp,
- can1_15_grp, can1_16_grp, can1_17_grp,
- can1_18_grp, can1_19_grp, uart0_0_grp,
- uart0_1_grp, uart0_2_grp, uart0_3_grp,
- uart0_4_grp, uart0_5_grp, uart0_6_grp,
- uart0_7_grp, uart0_8_grp, uart0_9_grp,
- uart0_10_grp, uart0_11_grp, uart0_12_grp,
- uart0_13_grp, uart0_14_grp, uart0_15_grp,
- uart0_16_grp, uart0_17_grp, uart0_18_grp,
- uart1_0_grp, uart1_1_grp, uart1_2_grp,
- uart1_3_grp, uart1_4_grp, uart1_5_grp,
- uart1_6_grp, uart1_7_grp, uart1_8_grp,
- uart1_9_grp, uart1_10_grp, uart1_11_grp,
- uart1_12_grp, uart1_13_grp, uart1_14_grp,
- uart1_15_grp, uart1_16_grp, uart1_17_grp,
- uart1_18_grp, i2c0_0_grp, i2c0_1_grp,
- i2c0_2_grp, i2c0_3_grp, i2c0_4_grp,
- i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
- i2c0_8_grp, i2c0_9_grp, i2c0_10_grp,
- i2c0_11_grp, i2c0_12_grp, i2c0_13_grp,
- i2c0_14_grp, i2c0_15_grp, i2c0_16_grp,
- i2c0_17_grp, i2c0_18_grp, i2c1_0_grp,
- i2c1_1_grp, i2c1_2_grp, i2c1_3_grp,
- i2c1_4_grp, i2c1_5_grp, i2c1_6_grp,
- i2c1_7_grp, i2c1_8_grp, i2c1_9_grp,
- i2c1_10_grp, i2c1_11_grp, i2c1_12_grp,
- i2c1_13_grp, i2c1_14_grp, i2c1_15_grp,
- i2c1_16_grp, i2c1_17_grp, i2c1_18_grp,
- i2c1_19_grp, ttc0_clk_0_grp, ttc0_wav_0_grp,
- ttc0_clk_1_grp, ttc0_wav_1_grp, ttc0_clk_2_grp,
- ttc0_wav_2_grp, ttc0_clk_3_grp, ttc0_wav_3_grp,
- ttc0_clk_4_grp, ttc0_wav_4_grp, ttc0_clk_5_grp,
- ttc0_wav_5_grp, ttc0_clk_6_grp, ttc0_wav_6_grp,
- ttc0_clk_7_grp, ttc0_wav_7_grp, ttc0_clk_8_grp,
- ttc0_wav_8_grp, ttc1_clk_0_grp, ttc1_wav_0_grp,
- ttc1_clk_1_grp, ttc1_wav_1_grp, ttc1_clk_2_grp,
- ttc1_wav_2_grp, ttc1_clk_3_grp, ttc1_wav_3_grp,
- ttc1_clk_4_grp, ttc1_wav_4_grp, ttc1_clk_5_grp,
- ttc1_wav_5_grp, ttc1_clk_6_grp, ttc1_wav_6_grp,
- ttc1_clk_7_grp, ttc1_wav_7_grp, ttc1_clk_8_grp,
- ttc1_wav_8_grp, ttc2_clk_0_grp, ttc2_wav_0_grp,
- ttc2_clk_1_grp, ttc2_wav_1_grp, ttc2_clk_2_grp,
- ttc2_wav_2_grp, ttc2_clk_3_grp, ttc2_wav_3_grp,
- ttc2_clk_4_grp, ttc2_wav_4_grp, ttc2_clk_5_grp,
- ttc2_wav_5_grp, ttc2_clk_6_grp, ttc2_wav_6_grp,
- ttc2_clk_7_grp, ttc2_wav_7_grp, ttc2_clk_8_grp,
- ttc2_wav_8_grp, ttc3_clk_0_grp, ttc3_wav_0_grp,
- ttc3_clk_1_grp, ttc3_wav_1_grp, ttc3_clk_2_grp,
- ttc3_wav_2_grp, ttc3_clk_3_grp, ttc3_wav_3_grp,
- ttc3_clk_4_grp, ttc3_wav_4_grp, ttc3_clk_5_grp,
- ttc3_wav_5_grp, ttc3_clk_6_grp, ttc3_wav_6_grp,
- ttc3_clk_7_grp, ttc3_wav_7_grp, ttc3_clk_8_grp,
- ttc3_wav_8_grp, swdt0_clk_0_grp, swdt0_rst_0_grp,
- swdt0_clk_1_grp, swdt0_rst_1_grp, swdt0_clk_2_grp,
- swdt0_rst_2_grp, swdt0_clk_3_grp, swdt0_rst_3_grp,
- swdt0_clk_4_grp, swdt0_rst_4_grp, swdt0_clk_5_grp,
- swdt0_rst_5_grp, swdt0_clk_6_grp, swdt0_rst_6_grp,
- swdt0_clk_7_grp, swdt0_rst_7_grp, swdt0_clk_8_grp,
- swdt0_rst_8_grp, swdt0_clk_9_grp, swdt0_rst_9_grp,
- swdt0_clk_10_grp, swdt0_rst_10_grp, swdt0_clk_11_grp,
- swdt0_rst_11_grp, swdt0_clk_12_grp, swdt0_rst_12_grp,
- swdt1_clk_0_grp, swdt1_rst_0_grp, swdt1_clk_1_grp,
- swdt1_rst_1_grp, swdt1_clk_2_grp, swdt1_rst_2_grp,
- swdt1_clk_3_grp, swdt1_rst_3_grp, swdt1_clk_4_grp,
- swdt1_rst_4_grp, swdt1_clk_5_grp, swdt1_rst_5_grp,
- swdt1_clk_6_grp, swdt1_rst_6_grp, swdt1_clk_7_grp,
- swdt1_rst_7_grp, swdt1_clk_8_grp, swdt1_rst_8_grp,
- swdt1_clk_9_grp, swdt1_rst_9_grp, swdt1_clk_10_grp,
- swdt1_rst_10_grp, swdt1_clk_11_grp, swdt1_rst_11_grp,
- swdt1_clk_12_grp, swdt1_rst_12_grp, gpio0_0_grp,
- gpio0_1_grp, gpio0_2_grp, gpio0_3_grp,
- gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
- gpio0_7_grp, gpio0_8_grp, gpio0_9_grp,
- gpio0_10_grp, gpio0_11_grp, gpio0_12_grp,
- gpio0_13_grp, gpio0_14_grp, gpio0_15_grp,
- gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
- gpio0_19_grp, gpio0_20_grp, gpio0_21_grp,
- gpio0_22_grp, gpio0_23_grp, gpio0_24_grp,
- gpio0_25_grp, gpio0_26_grp, gpio0_27_grp,
- gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
- gpio0_31_grp, gpio0_32_grp, gpio0_33_grp,
- gpio0_34_grp, gpio0_35_grp, gpio0_36_grp,
- gpio0_37_grp, gpio0_38_grp, gpio0_39_grp,
- gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
- gpio0_43_grp, gpio0_44_grp, gpio0_45_grp,
- gpio0_46_grp, gpio0_47_grp, gpio0_48_grp,
- gpio0_49_grp, gpio0_50_grp, gpio0_51_grp,
- gpio0_52_grp, gpio0_53_grp, gpio0_54_grp,
- gpio0_55_grp, gpio0_56_grp, gpio0_57_grp,
- gpio0_58_grp, gpio0_59_grp, gpio0_60_grp,
- gpio0_61_grp, gpio0_62_grp, gpio0_63_grp,
- gpio0_64_grp, gpio0_65_grp, gpio0_66_grp,
- gpio0_67_grp, gpio0_68_grp, gpio0_69_grp,
- gpio0_70_grp, gpio0_71_grp, gpio0_72_grp,
- gpio0_73_grp, gpio0_74_grp, gpio0_75_grp,
- gpio0_76_grp, gpio0_77_grp, usb0_0_grp,
- usb1_0_grp, pmu0_0_grp, pmu0_1_grp,
- pmu0_2_grp, pmu0_3_grp, pmu0_4_grp,
- pmu0_5_grp, pmu0_6_grp, pmu0_7_grp,
- pmu0_8_grp, pmu0_9_grp, pmu0_10_grp,
- pmu0_11_grp, pcie0_0_grp, pcie0_1_grp,
- pcie0_2_grp, pcie0_3_grp, pcie0_4_grp,
- pcie0_5_grp, pcie0_6_grp, pcie0_7_grp,
- csu0_0_grp, csu0_1_grp, csu0_2_grp,
- csu0_3_grp, csu0_4_grp, csu0_5_grp,
- csu0_6_grp, csu0_7_grp, csu0_8_grp,
- csu0_9_grp, csu0_10_grp, csu0_11_grp,
- dpaux0_0_grp, dpaux0_1_grp, dpaux0_2_grp,
- dpaux0_3_grp, pjtag0_0_grp, pjtag0_1_grp,
- pjtag0_2_grp, pjtag0_3_grp, pjtag0_4_grp,
- pjtag0_5_grp, trace0_0_grp, trace0_clk_0_grp,
- trace0_1_grp, trace0_clk_1_grp, trace0_2_grp,
- trace0_clk_2_grp, testscan0_0_grp]
+ anyOf:
+ - pattern: '^MIO([0-9]|[1-6][0-9]|7[0-7])$'
+ - enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+ ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+ gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+ mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+ qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+ spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+ spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+ spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+ spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+ spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+ spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+ spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+ spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+ spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+ spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+ spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+ spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+ spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+ spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+ spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+ spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+ sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+ sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+ sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+ sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+ sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+ sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+ sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+ sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+ sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+ sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+ sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+ sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+ sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+ sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+ sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+ sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
+ sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
+ sdio1_9_grp, sdio1_10_grp, sdio1_11_grp,
+ sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+ sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+ sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+ sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+ nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+ nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+ can0_1_grp, can0_2_grp, can0_3_grp,
+ can0_4_grp, can0_5_grp, can0_6_grp,
+ can0_7_grp, can0_8_grp, can0_9_grp,
+ can0_10_grp, can0_11_grp, can0_12_grp,
+ can0_13_grp, can0_14_grp, can0_15_grp,
+ can0_16_grp, can0_17_grp, can0_18_grp,
+ can1_0_grp, can1_1_grp, can1_2_grp,
+ can1_3_grp, can1_4_grp, can1_5_grp,
+ can1_6_grp, can1_7_grp, can1_8_grp,
+ can1_9_grp, can1_10_grp, can1_11_grp,
+ can1_12_grp, can1_13_grp, can1_14_grp,
+ can1_15_grp, can1_16_grp, can1_17_grp,
+ can1_18_grp, can1_19_grp, uart0_0_grp,
+ uart0_1_grp, uart0_2_grp, uart0_3_grp,
+ uart0_4_grp, uart0_5_grp, uart0_6_grp,
+ uart0_7_grp, uart0_8_grp, uart0_9_grp,
+ uart0_10_grp, uart0_11_grp, uart0_12_grp,
+ uart0_13_grp, uart0_14_grp, uart0_15_grp,
+ uart0_16_grp, uart0_17_grp, uart0_18_grp,
+ uart1_0_grp, uart1_1_grp, uart1_2_grp,
+ uart1_3_grp, uart1_4_grp, uart1_5_grp,
+ uart1_6_grp, uart1_7_grp, uart1_8_grp,
+ uart1_9_grp, uart1_10_grp, uart1_11_grp,
+ uart1_12_grp, uart1_13_grp, uart1_14_grp,
+ uart1_15_grp, uart1_16_grp, uart1_17_grp,
+ uart1_18_grp, i2c0_0_grp, i2c0_1_grp,
+ i2c0_2_grp, i2c0_3_grp, i2c0_4_grp,
+ i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
+ i2c0_8_grp, i2c0_9_grp, i2c0_10_grp,
+ i2c0_11_grp, i2c0_12_grp, i2c0_13_grp,
+ i2c0_14_grp, i2c0_15_grp, i2c0_16_grp,
+ i2c0_17_grp, i2c0_18_grp, i2c1_0_grp,
+ i2c1_1_grp, i2c1_2_grp, i2c1_3_grp,
+ i2c1_4_grp, i2c1_5_grp, i2c1_6_grp,
+ i2c1_7_grp, i2c1_8_grp, i2c1_9_grp,
+ i2c1_10_grp, i2c1_11_grp, i2c1_12_grp,
+ i2c1_13_grp, i2c1_14_grp, i2c1_15_grp,
+ i2c1_16_grp, i2c1_17_grp, i2c1_18_grp,
+ i2c1_19_grp, ttc0_clk_0_grp, ttc0_wav_0_grp,
+ ttc0_clk_1_grp, ttc0_wav_1_grp, ttc0_clk_2_grp,
+ ttc0_wav_2_grp, ttc0_clk_3_grp, ttc0_wav_3_grp,
+ ttc0_clk_4_grp, ttc0_wav_4_grp, ttc0_clk_5_grp,
+ ttc0_wav_5_grp, ttc0_clk_6_grp, ttc0_wav_6_grp,
+ ttc0_clk_7_grp, ttc0_wav_7_grp, ttc0_clk_8_grp,
+ ttc0_wav_8_grp, ttc1_clk_0_grp, ttc1_wav_0_grp,
+ ttc1_clk_1_grp, ttc1_wav_1_grp, ttc1_clk_2_grp,
+ ttc1_wav_2_grp, ttc1_clk_3_grp, ttc1_wav_3_grp,
+ ttc1_clk_4_grp, ttc1_wav_4_grp, ttc1_clk_5_grp,
+ ttc1_wav_5_grp, ttc1_clk_6_grp, ttc1_wav_6_grp,
+ ttc1_clk_7_grp, ttc1_wav_7_grp, ttc1_clk_8_grp,
+ ttc1_wav_8_grp, ttc2_clk_0_grp, ttc2_wav_0_grp,
+ ttc2_clk_1_grp, ttc2_wav_1_grp, ttc2_clk_2_grp,
+ ttc2_wav_2_grp, ttc2_clk_3_grp, ttc2_wav_3_grp,
+ ttc2_clk_4_grp, ttc2_wav_4_grp, ttc2_clk_5_grp,
+ ttc2_wav_5_grp, ttc2_clk_6_grp, ttc2_wav_6_grp,
+ ttc2_clk_7_grp, ttc2_wav_7_grp, ttc2_clk_8_grp,
+ ttc2_wav_8_grp, ttc3_clk_0_grp, ttc3_wav_0_grp,
+ ttc3_clk_1_grp, ttc3_wav_1_grp, ttc3_clk_2_grp,
+ ttc3_wav_2_grp, ttc3_clk_3_grp, ttc3_wav_3_grp,
+ ttc3_clk_4_grp, ttc3_wav_4_grp, ttc3_clk_5_grp,
+ ttc3_wav_5_grp, ttc3_clk_6_grp, ttc3_wav_6_grp,
+ ttc3_clk_7_grp, ttc3_wav_7_grp, ttc3_clk_8_grp,
+ ttc3_wav_8_grp, swdt0_clk_0_grp, swdt0_rst_0_grp,
+ swdt0_clk_1_grp, swdt0_rst_1_grp, swdt0_clk_2_grp,
+ swdt0_rst_2_grp, swdt0_clk_3_grp, swdt0_rst_3_grp,
+ swdt0_clk_4_grp, swdt0_rst_4_grp, swdt0_clk_5_grp,
+ swdt0_rst_5_grp, swdt0_clk_6_grp, swdt0_rst_6_grp,
+ swdt0_clk_7_grp, swdt0_rst_7_grp, swdt0_clk_8_grp,
+ swdt0_rst_8_grp, swdt0_clk_9_grp, swdt0_rst_9_grp,
+ swdt0_clk_10_grp, swdt0_rst_10_grp, swdt0_clk_11_grp,
+ swdt0_rst_11_grp, swdt0_clk_12_grp, swdt0_rst_12_grp,
+ swdt1_clk_0_grp, swdt1_rst_0_grp, swdt1_clk_1_grp,
+ swdt1_rst_1_grp, swdt1_clk_2_grp, swdt1_rst_2_grp,
+ swdt1_clk_3_grp, swdt1_rst_3_grp, swdt1_clk_4_grp,
+ swdt1_rst_4_grp, swdt1_clk_5_grp, swdt1_rst_5_grp,
+ swdt1_clk_6_grp, swdt1_rst_6_grp, swdt1_clk_7_grp,
+ swdt1_rst_7_grp, swdt1_clk_8_grp, swdt1_rst_8_grp,
+ swdt1_clk_9_grp, swdt1_rst_9_grp, swdt1_clk_10_grp,
+ swdt1_rst_10_grp, swdt1_clk_11_grp, swdt1_rst_11_grp,
+ swdt1_clk_12_grp, swdt1_rst_12_grp, gpio0_0_grp,
+ gpio0_1_grp, gpio0_2_grp, gpio0_3_grp,
+ gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
+ gpio0_7_grp, gpio0_8_grp, gpio0_9_grp,
+ gpio0_10_grp, gpio0_11_grp, gpio0_12_grp,
+ gpio0_13_grp, gpio0_14_grp, gpio0_15_grp,
+ gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
+ gpio0_19_grp, gpio0_20_grp, gpio0_21_grp,
+ gpio0_22_grp, gpio0_23_grp, gpio0_24_grp,
+ gpio0_25_grp, gpio0_26_grp, gpio0_27_grp,
+ gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
+ gpio0_31_grp, gpio0_32_grp, gpio0_33_grp,
+ gpio0_34_grp, gpio0_35_grp, gpio0_36_grp,
+ gpio0_37_grp, gpio0_38_grp, gpio0_39_grp,
+ gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
+ gpio0_43_grp, gpio0_44_grp, gpio0_45_grp,
+ gpio0_46_grp, gpio0_47_grp, gpio0_48_grp,
+ gpio0_49_grp, gpio0_50_grp, gpio0_51_grp,
+ gpio0_52_grp, gpio0_53_grp, gpio0_54_grp,
+ gpio0_55_grp, gpio0_56_grp, gpio0_57_grp,
+ gpio0_58_grp, gpio0_59_grp, gpio0_60_grp,
+ gpio0_61_grp, gpio0_62_grp, gpio0_63_grp,
+ gpio0_64_grp, gpio0_65_grp, gpio0_66_grp,
+ gpio0_67_grp, gpio0_68_grp, gpio0_69_grp,
+ gpio0_70_grp, gpio0_71_grp, gpio0_72_grp,
+ gpio0_73_grp, gpio0_74_grp, gpio0_75_grp,
+ gpio0_76_grp, gpio0_77_grp, usb0_0_grp,
+ usb1_0_grp, pmu0_0_grp, pmu0_1_grp,
+ pmu0_2_grp, pmu0_3_grp, pmu0_4_grp,
+ pmu0_5_grp, pmu0_6_grp, pmu0_7_grp,
+ pmu0_8_grp, pmu0_9_grp, pmu0_10_grp,
+ pmu0_11_grp, pcie0_0_grp, pcie0_1_grp,
+ pcie0_2_grp, pcie0_3_grp, pcie0_4_grp,
+ pcie0_5_grp, pcie0_6_grp, pcie0_7_grp,
+ csu0_0_grp, csu0_1_grp, csu0_2_grp,
+ csu0_3_grp, csu0_4_grp, csu0_5_grp,
+ csu0_6_grp, csu0_7_grp, csu0_8_grp,
+ csu0_9_grp, csu0_10_grp, csu0_11_grp,
+ dpaux0_0_grp, dpaux0_1_grp, dpaux0_2_grp,
+ dpaux0_3_grp, pjtag0_0_grp, pjtag0_1_grp,
+ pjtag0_2_grp, pjtag0_3_grp, pjtag0_4_grp,
+ pjtag0_5_grp, trace0_0_grp, trace0_clk_0_grp,
+ trace0_1_grp, trace0_clk_1_grp, trace0_2_grp,
+ trace0_clk_2_grp, testscan0_0_grp]
maxItems: 78
function:
@@ -231,9 +238,12 @@ patternProperties:
pcie0, csu0, dpaux0, pjtag0, trace0, trace0_clk, testscan0]
required:
- - groups
- function
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
additionalProperties: false
'^conf':
diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.txt b/Documentation/devicetree/bindings/pmem/pmem-region.txt
deleted file mode 100644
index 5cfa4f016a00..000000000000
--- a/Documentation/devicetree/bindings/pmem/pmem-region.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Device-tree bindings for persistent memory regions
------------------------------------------------------
-
-Persistent memory refers to a class of memory devices that are:
-
- a) Usable as main system memory (i.e. cacheable), and
- b) Retain their contents across power failure.
-
-Given b) it is best to think of persistent memory as a kind of memory mapped
-storage device. To ensure data integrity the operating system needs to manage
-persistent regions separately to the normal memory pool. To aid with that this
-binding provides a standardised interface for discovering where persistent
-memory regions exist inside the physical address space.
-
-Bindings for the region nodes:
------------------------------
-
-Required properties:
- - compatible = "pmem-region"
-
- - reg = <base, size>;
- The reg property should specificy an address range that is
- translatable to a system physical address range. This address
- range should be mappable as normal system memory would be
- (i.e cacheable).
-
- If the reg property contains multiple address ranges
- each address range will be treated as though it was specified
- in a separate device node. Having multiple address ranges in a
- node implies no special relationship between the two ranges.
-
-Optional properties:
- - Any relevant NUMA assocativity properties for the target platform.
-
- - volatile; This property indicates that this region is actually
- backed by non-persistent memory. This lets the OS know that it
- may skip the cache flushes required to ensure data is made
- persistent after a write.
-
- If this property is absent then the OS must assume that the region
- is backed by non-volatile memory.
-
-Examples:
---------------------
-
- /*
- * This node specifies one 4KB region spanning from
- * 0x5000 to 0x5fff that is backed by non-volatile memory.
- */
- pmem@5000 {
- compatible = "pmem-region";
- reg = <0x00005000 0x00001000>;
- };
-
- /*
- * This node specifies two 4KB regions that are backed by
- * volatile (normal) memory.
- */
- pmem@6000 {
- compatible = "pmem-region";
- reg = < 0x00006000 0x00001000
- 0x00008000 0x00001000 >;
- volatile;
- };
-
diff --git a/Documentation/devicetree/bindings/pmem/pmem-region.yaml b/Documentation/devicetree/bindings/pmem/pmem-region.yaml
new file mode 100644
index 000000000000..bd0f0c793f03
--- /dev/null
+++ b/Documentation/devicetree/bindings/pmem/pmem-region.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pmem-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+maintainers:
+ - Oliver O'Halloran <oohall@gmail.com>
+
+title: Persistent Memory Regions
+
+description: |
+ Persistent memory refers to a class of memory devices that are:
+
+ a) Usable as main system memory (i.e. cacheable), and
+ b) Retain their contents across power failure.
+
+ Given b) it is best to think of persistent memory as a kind of memory mapped
+ storage device. To ensure data integrity the operating system needs to manage
+ persistent regions separately to the normal memory pool. To aid with that this
+ binding provides a standardised interface for discovering where persistent
+ memory regions exist inside the physical address space.
+
+properties:
+ compatible:
+ const: pmem-region
+
+ reg:
+ maxItems: 1
+
+ volatile:
+ description:
+ Indicates the region is volatile (non-persistent) and the OS can skip
+ cache flushes for writes
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pmem@5000 {
+ compatible = "pmem-region";
+ reg = <0x00005000 0x00001000>;
+ };
diff --git a/Documentation/devicetree/bindings/power/actions,owl-sps.txt b/Documentation/devicetree/bindings/power/actions,owl-sps.txt
deleted file mode 100644
index a3571937b019..000000000000
--- a/Documentation/devicetree/bindings/power/actions,owl-sps.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Actions Semi Owl Smart Power System (SPS)
-
-Required properties:
-- compatible : "actions,s500-sps" for S500
- "actions,s700-sps" for S700
- "actions,s900-sps" for S900
-- reg : Offset and length of the register set for the device.
-- #power-domain-cells : Must be 1.
- See macros in:
- include/dt-bindings/power/owl-s500-powergate.h for S500
- include/dt-bindings/power/owl-s700-powergate.h for S700
- include/dt-bindings/power/owl-s900-powergate.h for S900
-
-
-Example:
-
- sps: power-controller@b01b0100 {
- compatible = "actions,s500-sps";
- reg = <0xb01b0100 0x100>;
- #power-domain-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/power/actions,s500-sps.yaml b/Documentation/devicetree/bindings/power/actions,s500-sps.yaml
new file mode 100644
index 000000000000..bb942817b3db
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/actions,s500-sps.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/actions,s500-sps.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl Smart Power System (SPS)
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+ - Manivannan Sadhasivam <mani@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - actions,s500-sps
+ - actions,s700-sps
+ - actions,s900-sps
+
+ reg:
+ maxItems: 1
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ power-controller@b01b0100 {
+ compatible = "actions,s500-sps";
+ reg = <0xb01b0100 0x100>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml
new file mode 100644
index 000000000000..a28e75a9cb6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/allwinner,sun20i-d1-ppu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner SoCs PPU power domain controller
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ D1 and related SoCs contain a power domain controller for the CPUs, GPU, and
+ video-related hardware.
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun8i-v853-ppu
+ - allwinner,sun20i-d1-ppu
+ - allwinner,sun55i-a523-pck-600
+ - allwinner,sun55i-a523-ppu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: Bus Clock
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sun20i-d1-r-ccu.h>
+ #include <dt-bindings/reset/sun20i-d1-r-ccu.h>
+
+ ppu: power-controller@7001000 {
+ compatible = "allwinner,sun20i-d1-ppu";
+ reg = <0x7001000 0x1000>;
+ clocks = <&r_ccu CLK_BUS_R_PPU>;
+ resets = <&r_ccu RST_BUS_R_PPU>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/allwinner,sun50i-h6-prcm-ppu.yaml b/Documentation/devicetree/bindings/power/allwinner,sun50i-h6-prcm-ppu.yaml
new file mode 100644
index 000000000000..73a9b4d6220e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/allwinner,sun50i-h6-prcm-ppu.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/allwinner,sun50i-h6-prcm-ppu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner SoCs PRCM power domain controller
+
+maintainers:
+ - Andre Przywara <andre.przywara@arm.com>
+
+description:
+ The Allwinner Power Reset Clock Management (PRCM) unit contains bits to
+ control a few power domains.
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun50i-h6-prcm-ppu
+ - allwinner,sun50i-h616-prcm-ppu
+ - allwinner,sun55i-a523-prcm-ppu
+
+ reg:
+ maxItems: 1
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ prcm_ppu: power-controller@7010210 {
+ compatible = "allwinner,sun50i-h616-prcm-ppu";
+ reg = <0x7010210 0x10>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
index 99b5b10cda31..ba5865ae6bfe 100644
--- a/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
+++ b/Documentation/devicetree/bindings/power/amlogic,meson-gx-pwrc.txt
@@ -1,5 +1,5 @@
-Amlogic Meson Power Controller
-==============================
+Amlogic Meson Power Controller (deprecated)
+===========================================
The Amlogic Meson SoCs embeds an internal Power domain controller.
diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
index eab21bb2050a..12b71688dd34 100644
--- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
+++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml
@@ -12,7 +12,7 @@ maintainers:
- Jianxin Pan <jianxin.pan@amlogic.com>
description: |+
- Secure Power Domains used in Meson A1/C1/S4 SoCs, and should be the child node
+ Secure Power Domains used in Meson A1/C1/S4 & C3/T7 SoCs, and should be the child node
of secure-monitor.
properties:
@@ -20,6 +20,13 @@ properties:
enum:
- amlogic,meson-a1-pwrc
- amlogic,meson-s4-pwrc
+ - amlogic,a4-pwrc
+ - amlogic,a5-pwrc
+ - amlogic,c3-pwrc
+ - amlogic,t7-pwrc
+ - amlogic,s6-pwrc
+ - amlogic,s7-pwrc
+ - amlogic,s7d-pwrc
"#power-domain-cells":
const: 1
diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
index 94d369eb85de..caf151880999 100644
--- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
+++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
@@ -29,11 +29,22 @@ description: |
properties:
compatible:
- items:
- - enum:
- - apple,t8103-pmgr-pwrstate
- - apple,t6000-pmgr-pwrstate
- - const: apple,pmgr-pwrstate
+ oneOf:
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,s5l8960x-pmgr-pwrstate
+ - apple,t7000-pmgr-pwrstate
+ - apple,s8000-pmgr-pwrstate
+ - apple,t8010-pmgr-pwrstate
+ - apple,t8015-pmgr-pwrstate
+ - apple,t8103-pmgr-pwrstate
+ - apple,t8112-pmgr-pwrstate
+ - apple,t6000-pmgr-pwrstate
+ - const: apple,pmgr-pwrstate
+ - items:
+ - const: apple,t6020-pmgr-pwrstate
+ - const: apple,t8103-pmgr-pwrstate
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml b/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml
index 301db7daf870..2fd2178d1fa5 100644
--- a/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml
+++ b/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/avs/qcom,cpr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Core Power Reduction (CPR) bindings
+title: Qualcomm Core Power Reduction (CPR)
maintainers:
- Niklas Cassel <nks@flawful.org>
diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.yaml b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
index 6a12efdf436a..4dd4f59bbbec 100644
--- a/Documentation/devicetree/bindings/power/domain-idle-state.yaml
+++ b/Documentation/devicetree/bindings/power/domain-idle-state.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/domain-idle-state.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: PM Domain Idle States binding description
+title: PM Domain Idle States
maintainers:
- Ulf Hansson <ulf.hansson@linaro.org>
@@ -20,6 +20,7 @@ properties:
patternProperties:
"^(cpu|cluster|domain)-":
type: object
+ additionalProperties: false
description:
Each state node represents a domain idle state description.
@@ -44,6 +45,20 @@ patternProperties:
state will yield power benefits, after overcoming the overhead while
entering the idle state.
+ arm,psci-suspend-param:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ power_state parameter to pass to the ARM PSCI suspend call.
+
+ Device tree nodes that require usage of PSCI CPU_SUSPEND function
+ (i.e. idle states node with entry-method property is set to "psci")
+ must specify this property.
+
+ idle-state-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ A string used as a descriptive name for the idle state.
+
required:
- compatible
- entry-latency-us
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
index a055b3e819d8..9de3fe73c1eb 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
@@ -23,11 +23,17 @@ description: |
properties:
compatible:
- enum:
- - fsl,imx6q-gpc
- - fsl,imx6qp-gpc
- - fsl,imx6sl-gpc
- - fsl,imx6sx-gpc
+ oneOf:
+ - enum:
+ - fsl,imx6q-gpc
+ - items:
+ - enum:
+ - fsl,imx6qp-gpc
+ - fsl,imx6sl-gpc
+ - fsl,imx6sll-gpc
+ - fsl,imx6sx-gpc
+ - fsl,imx6ul-gpc
+ - const: fsl,imx6q-gpc
reg:
maxItems: 1
@@ -35,6 +41,10 @@ properties:
interrupts:
maxItems: 1
+ interrupt-controller: true
+ '#interrupt-cells':
+ const: 3
+
clocks:
maxItems: 1
@@ -43,11 +53,21 @@ properties:
pgc:
type: object
+ additionalProperties: false
description: list of power domains provided by this controller.
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
patternProperties:
"power-domain@[0-9]$":
type: object
+ additionalProperties: false
+
properties:
'#power-domain-cells':
@@ -78,6 +98,10 @@ properties:
- '#power-domain-cells'
- reg
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
index 747622bdc57b..dfdb8dfb6b65 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -42,11 +42,21 @@ properties:
pgc:
type: object
+ additionalProperties: false
description: list of power domains provided by this controller.
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
patternProperties:
- "power-domain@[0-9]$":
+ "power-domain@[0-9a-f]+$":
type: object
+ additionalProperties: false
+
properties:
'#power-domain-cells':
@@ -71,6 +81,9 @@ properties:
power-supply: true
+ power-domains:
+ maxItems: 1
+
resets:
description: |
A number of phandles to resets that need to be asserted during
@@ -85,6 +98,10 @@ properties:
- '#power-domain-cells'
- reg
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml b/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml
index 1f72b18ca0fc..7a0f1a400868 100644
--- a/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,scu-pd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/fsl,scu-pd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - Power domain bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - Power Domain Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
@@ -20,6 +20,7 @@ properties:
compatible:
items:
- enum:
+ - fsl,imx8dl-scu-pd
- fsl,imx8qm-scu-pd
- fsl,imx8qxp-scu-pd
- const: fsl,scu-pd
diff --git a/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml b/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml
new file mode 100644
index 000000000000..b9e43abaf8a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/mediatek,mt8196-gpufreq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MFlexGraphics Power and Frequency Controller
+
+maintainers:
+ - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+description:
+ A special-purpose embedded MCU to control power and frequency of GPU devices
+ using MediaTek Flexible Graphics integration hardware.
+
+properties:
+ $nodename:
+ pattern: '^power-controller@[a-f0-9]+$'
+
+ compatible:
+ enum:
+ - mediatek,mt8196-gpufreq
+
+ reg:
+ items:
+ - description: GPR memory area
+ - description: RPC memory area
+ - description: SoC variant ID register
+
+ reg-names:
+ items:
+ - const: gpr
+ - const: rpc
+ - const: hw-revision
+
+ clocks:
+ items:
+ - description: main clock of the embedded controller (EB)
+ - description: core PLL
+ - description: stack 0 PLL
+ - description: stack 1 PLL
+
+ clock-names:
+ items:
+ - const: eb
+ - const: core
+ - const: stack0
+ - const: stack1
+
+ mboxes:
+ items:
+ - description: FastDVFS events
+ - description: frequency control
+ - description: sleep control
+ - description: timer control
+ - description: frequency hopping control
+ - description: hardware voter control
+ - description: FastDVFS control
+
+ mbox-names:
+ items:
+ - const: fast-dvfs-event
+ - const: gpufreq
+ - const: sleep
+ - const: timer
+ - const: fhctl
+ - const: ccf
+ - const: fast-dvfs
+
+ memory-region:
+ items:
+ - description: phandle to the GPUEB shared memory
+
+ "#clock-cells":
+ const: 1
+
+ "#power-domain-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - mboxes
+ - mbox-names
+ - memory-region
+ - "#clock-cells"
+ - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mediatek,mt8196-clock.h>
+
+ power-controller@4b09fd00 {
+ compatible = "mediatek,mt8196-gpufreq";
+ reg = <0x4b09fd00 0x80>,
+ <0x4b800000 0x1000>,
+ <0x4b860128 0x4>;
+ reg-names = "gpr", "rpc", "hw-revision";
+ clocks = <&topckgen CLK_TOP_MFG_EB>,
+ <&mfgpll CLK_MFG_AO_MFGPLL>,
+ <&mfgpll_sc0 CLK_MFGSC0_AO_MFGPLL_SC0>,
+ <&mfgpll_sc1 CLK_MFGSC1_AO_MFGPLL_SC1>;
+ clock-names = "eb", "core", "stack0", "stack1";
+ mboxes = <&gpueb_mbox 0>, <&gpueb_mbox 1>, <&gpueb_mbox 2>,
+ <&gpueb_mbox 3>, <&gpueb_mbox 4>, <&gpueb_mbox 5>,
+ <&gpueb_mbox 7>;
+ mbox-names = "fast-dvfs-event", "gpufreq", "sleep", "timer", "fhctl",
+ "ccf", "fast-dvfs";
+ memory-region = <&gpueb_shared_memory>;
+ #clock-cells = <1>;
+ #power-domain-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
index 605ec7ab5f63..f8a13928f615 100644
--- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -23,13 +23,20 @@ properties:
compatible:
enum:
+ - mediatek,mt6735-power-controller
- mediatek,mt6795-power-controller
+ - mediatek,mt6893-power-controller
- mediatek,mt8167-power-controller
- mediatek,mt8173-power-controller
- mediatek,mt8183-power-controller
- mediatek,mt8186-power-controller
+ - mediatek,mt8188-power-controller
- mediatek,mt8192-power-controller
- mediatek,mt8195-power-controller
+ - mediatek,mt8196-hwv-hfrp-power-controller
+ - mediatek,mt8196-hwv-scp-power-controller
+ - mediatek,mt8196-power-controller
+ - mediatek,mt8365-power-controller
'#power-domain-cells':
const: 1
@@ -40,6 +47,15 @@ properties:
'#size-cells':
const: 0
+ access-controllers:
+ description:
+ A number of phandles to external blocks to set and clear the required
+ bits to enable or disable bus protection, necessary to avoid any bus
+ faults while enabling or disabling a power domain.
+ For example, this may hold phandles to INFRACFG and SMI.
+ minItems: 1
+ maxItems: 3
+
patternProperties:
"^power-domain@[0-9a-f]+$":
$ref: "#/$defs/power-domain-node"
@@ -52,6 +68,10 @@ patternProperties:
patternProperties:
"^power-domain@[0-9a-f]+$":
$ref: "#/$defs/power-domain-node"
+ patternProperties:
+ "^power-domain@[0-9a-f]+$":
+ $ref: "#/$defs/power-domain-node"
+ unevaluatedProperties: false
unevaluatedProperties: false
unevaluatedProperties: false
unevaluatedProperties: false
@@ -81,11 +101,14 @@ $defs:
description: |
Power domain index. Valid values are defined in:
"include/dt-bindings/power/mt6795-power.h" - for MT8167 type power domain.
+ "include/dt-bindings/power/mediatek,mt6893-power.h" - for MT6893 type power domain.
"include/dt-bindings/power/mt8167-power.h" - for MT8167 type power domain.
"include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain.
"include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain.
+ "include/dt-bindings/power/mediatek,mt8188-power.h" - for MT8188 type power domain.
"include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain.
"include/dt-bindings/power/mt8195-power.h" - for MT8195 type power domain.
+ "include/dt-bindings/power/mediatek,mt8365-power.h" - for MT8365 type power domain.
maxItems: 1
clocks:
@@ -112,10 +135,17 @@ $defs:
mediatek,infracfg:
$ref: /schemas/types.yaml#/definitions/phandle
description: phandle to the device containing the INFRACFG register range.
+ deprecated: true
+
+ mediatek,infracfg-nao:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the device containing the INFRACFG-NAO register range.
+ deprecated: true
mediatek,smi:
$ref: /schemas/types.yaml#/definitions/phandle
description: phandle to the device containing the SMI register range.
+ deprecated: true
required:
- reg
@@ -123,6 +153,32 @@ $defs:
required:
- compatible
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8183-power-controller
+ - mediatek,mt8196-power-controller
+ then:
+ properties:
+ access-controllers:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8365-power-controller
+ then:
+ properties:
+ access-controllers:
+ minItems: 3
+ maxItems: 3
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index 889091b9814f..b1147dbf2e73 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -7,14 +7,15 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic PM domains
maintainers:
- - Rafael J. Wysocki <rjw@rjwysocki.net>
+ - Rafael J. Wysocki <rafael@kernel.org>
- Kevin Hilman <khilman@kernel.org>
- Ulf Hansson <ulf.hansson@linaro.org>
description: |+
System on chip designs are often divided into multiple PM domains that can be
- used for power gating of selected IP blocks for power saving by reduced leakage
- current.
+ used for power gating of selected IP blocks for power saving by reduced
+ leakage current. Moreover, in some cases the similar PM domains may also be
+ capable of scaling performance for a group of IP blocks.
This device tree binding can be used to bind PM domain consumer devices with
their PM domains provided by PM domain providers. A PM domain provider can be
@@ -25,7 +26,7 @@ description: |+
properties:
$nodename:
- pattern: "^(power-controller|power-domain)([@-].*)?$"
+ pattern: "^(power-controller|power-domain|performance-domain)([@-].*)?$"
domain-idle-states:
$ref: /schemas/types.yaml#/definitions/phandle-array
@@ -43,15 +44,12 @@ properties:
domain would be considered as capable of being powered-on or powered-off.
operating-points-v2:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- maxItems: 1
description:
- Phandles to the OPP tables of power domains provided by a power domain
- provider. If the provider provides a single power domain only or all
- the power domains provided by the provider have identical OPP tables,
- then this shall contain a single phandle. Refer to ../opp/opp-v2-base.yaml
- for more information.
+ Phandles to the OPP tables of power domains that are capable of scaling
+ performance, provided by a power domain provider. If the provider provides
+ a single power domain only or all the power domains provided by the
+ provider have identical OPP tables, then this shall contain a single
+ phandle. Refer to ../opp/opp-v2-base.yaml for more information.
"#power-domain-cells":
description:
diff --git a/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml b/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml
new file mode 100644
index 000000000000..3fa77fe14c87
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/qcom,kpss-acc-v2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) v2
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+description:
+ The KPSS ACC provides clock, power manager, and reset control to a Krait CPU.
+ There is one ACC register region per CPU within the KPSS remapped region as
+ well as an alias register region that remaps accesses to the ACC associated
+ with the CPU accessing the region. ACC v2 is currently used as a
+ power-manager for enabling the cpu.
+
+properties:
+ compatible:
+ enum:
+ - qcom,kpss-acc-v2
+ - qcom,msm8916-acc
+
+ reg:
+ items:
+ - description: Base address and size of the register region
+ - description: Optional base address and size of the alias register region
+ minItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ power-manager@f9088000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0xf9088000 0x1000>,
+ <0xf9008000 0x1000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 5b4eda919911..27af5b8aa134 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -15,36 +15,62 @@ description:
properties:
compatible:
- enum:
- - qcom,mdm9607-rpmpd
- - qcom,msm8226-rpmpd
- - qcom,msm8909-rpmpd
- - qcom,msm8916-rpmpd
- - qcom,msm8939-rpmpd
- - qcom,msm8953-rpmpd
- - qcom,msm8976-rpmpd
- - qcom,msm8994-rpmpd
- - qcom,msm8996-rpmpd
- - qcom,msm8998-rpmpd
- - qcom,qcm2290-rpmpd
- - qcom,qcs404-rpmpd
- - qcom,sa8540p-rpmhpd
- - qcom,sdm660-rpmpd
- - qcom,sc7180-rpmhpd
- - qcom,sc7280-rpmhpd
- - qcom,sc8180x-rpmhpd
- - qcom,sc8280xp-rpmhpd
- - qcom,sdm845-rpmhpd
- - qcom,sdx55-rpmhpd
- - qcom,sdx65-rpmhpd
- - qcom,sm6115-rpmpd
- - qcom,sm6125-rpmpd
- - qcom,sm6350-rpmhpd
- - qcom,sm6375-rpmpd
- - qcom,sm8150-rpmhpd
- - qcom,sm8250-rpmhpd
- - qcom,sm8350-rpmhpd
- - qcom,sm8450-rpmhpd
+ oneOf:
+ - enum:
+ - qcom,glymur-rpmhpd
+ - qcom,kaanapali-rpmhpd
+ - qcom,mdm9607-rpmpd
+ - qcom,milos-rpmhpd
+ - qcom,msm8226-rpmpd
+ - qcom,msm8909-rpmpd
+ - qcom,msm8916-rpmpd
+ - qcom,msm8917-rpmpd
+ - qcom,msm8939-rpmpd
+ - qcom,msm8953-rpmpd
+ - qcom,msm8974-rpmpd
+ - qcom,msm8974pro-pma8084-rpmpd
+ - qcom,msm8976-rpmpd
+ - qcom,msm8994-rpmpd
+ - qcom,msm8996-rpmpd
+ - qcom,msm8998-rpmpd
+ - qcom,qcm2290-rpmpd
+ - qcom,qcs404-rpmpd
+ - qcom,qcs615-rpmhpd
+ - qcom,qcs8300-rpmhpd
+ - qcom,qdu1000-rpmhpd
+ - qcom,qm215-rpmpd
+ - qcom,sa8155p-rpmhpd
+ - qcom,sa8540p-rpmhpd
+ - qcom,sa8775p-rpmhpd
+ - qcom,sar2130p-rpmhpd
+ - qcom,sc7180-rpmhpd
+ - qcom,sc7280-rpmhpd
+ - qcom,sc8180x-rpmhpd
+ - qcom,sc8280xp-rpmhpd
+ - qcom,sdm660-rpmpd
+ - qcom,sdm670-rpmhpd
+ - qcom,sdm845-rpmhpd
+ - qcom,sdx55-rpmhpd
+ - qcom,sdx65-rpmhpd
+ - qcom,sdx75-rpmhpd
+ - qcom,sm4450-rpmhpd
+ - qcom,sm6115-rpmpd
+ - qcom,sm6125-rpmpd
+ - qcom,sm6350-rpmhpd
+ - qcom,sm6375-rpmpd
+ - qcom,sm7150-rpmhpd
+ - qcom,sm8150-rpmhpd
+ - qcom,sm8250-rpmhpd
+ - qcom,sm8350-rpmhpd
+ - qcom,sm8450-rpmhpd
+ - qcom,sm8550-rpmhpd
+ - qcom,sm8650-rpmhpd
+ - qcom,sm8750-rpmhpd
+ - qcom,x1e80100-rpmhpd
+ - items:
+ - enum:
+ - qcom,msm8937-rpmpd
+ - const: qcom,msm8917-rpmpd
'#power-domain-cells':
const: 1
diff --git a/Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml b/Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml
new file mode 100644
index 000000000000..57579f70264c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/raspberrypi,bcm2835-power.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/raspberrypi,bcm2835-power.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 power domain
+
+maintainers:
+ - Alexander Aring <alex.aring@gmail.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+description:
+ The Raspberry Pi power domain manages power for various subsystems
+ in the Raspberry Pi BCM2835 SoC.
+
+properties:
+ compatible:
+ enum:
+ - raspberrypi,bcm2835-power
+
+ firmware:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the RPi firmware device node
+
+ "#power-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - firmware
+ - "#power-domain-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ power-controller {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml b/Documentation/devicetree/bindings/power/renesas,apmu.yaml
index f2cc89e7f4e4..2b4d802ef4b2 100644
--- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml
@@ -34,10 +34,8 @@ properties:
maxItems: 1
cpus:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- minItems: 1
- maxItems: 4
+ minItems: 1
+ maxItems: 4
description: |
Array of phandles pointing to CPU cores, which should match the order of
CPU cores used by the WUPCR and PSTR registers in the Advanced Power
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
index 0720b54881c2..347571e2545a 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
@@ -25,6 +25,7 @@ properties:
- renesas,r8a7745-sysc # RZ/G1E
- renesas,r8a77470-sysc # RZ/G1C
- renesas,r8a774a1-sysc # RZ/G2M
+ - renesas,r8a774a3-sysc # RZ/G2M v3.0
- renesas,r8a774b1-sysc # RZ/G2N
- renesas,r8a774c0-sysc # RZ/G2E
- renesas,r8a774e1-sysc # RZ/G2H
@@ -45,6 +46,7 @@ properties:
- renesas,r8a779a0-sysc # R-Car V3U
- renesas,r8a779f0-sysc # R-Car S4-8
- renesas,r8a779g0-sysc # R-Car V4H
+ - renesas,r8a779h0-sysc # R-Car V4M
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml
index 559718997de7..948a9da111df 100644
--- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml
@@ -45,7 +45,7 @@ properties:
const: 0
additionalProperties:
- $ref: "#/$defs/pd-node"
+ $ref: '#/$defs/pd-node'
required:
- compatible
@@ -58,7 +58,7 @@ $defs:
pd-node:
type: object
description:
- PM domain node representing a PM domain. This node hould be named by
+ PM domain node representing a PM domain. This node should be named by
the real power area name, and thus its name should be unique.
properties:
@@ -83,7 +83,7 @@ $defs:
- '#power-domain-cells'
additionalProperties:
- $ref: "#/$defs/pd-node"
+ $ref: '#/$defs/pd-node'
examples:
- |
diff --git a/Documentation/devicetree/bindings/power/reset/apple,smc-reboot.yaml b/Documentation/devicetree/bindings/power/reset/apple,smc-reboot.yaml
new file mode 100644
index 000000000000..ce5ed88493cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/apple,smc-reboot.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/apple,smc-reboot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SMC Reboot Controller
+
+description:
+ The Apple System Management Controller (SMC) provides reboot functionality
+ on Apple Silicon SoCs. It uses NVMEM cells to store and track various
+ system state information related to boot, shutdown, and panic events.
+
+maintainers:
+ - Sven Peter <sven@kernel.org>
+
+properties:
+ compatible:
+ const: apple,smc-reboot
+
+ nvmem-cells:
+ items:
+ - description: Flag indicating shutdown (as opposed to reboot)
+ - description: Stage at which the boot process stopped (0x30 for normal boot)
+ - description: Counter for boot errors
+ - description: Counter for system panics
+
+ nvmem-cell-names:
+ items:
+ - const: shutdown_flag
+ - const: boot_stage
+ - const: boot_error_count
+ - const: panic_count
+
+required:
+ - compatible
+ - nvmem-cells
+ - nvmem-cell-names
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml
new file mode 100644
index 000000000000..f559a2cfd82e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/atmel,at91sam9260-shdwc.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/atmel,at91sam9260-shdwc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 SHDWC Shutdown Controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description: |
+ Microchip AT91 SHDWC shutdown controller controls the power supplies VDDIO
+ and VDDCORE and the wake-up detection on debounced input lines.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91sam9260-shdwc
+ - atmel,at91sam9rl-shdwc
+ - atmel,at91sam9x5-shdwc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ atmel,wakeup-mode:
+ description: operation mode of the wakeup mode
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ none, high, low, any ]
+
+ atmel,wakeup-counter:
+ description: counter on wake-up 0
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+
+ atmel,wakeup-rtt-timer:
+ description: enable real-time timer wake-up
+ type: boolean
+
+ atmel,wakeup-rtc-timer:
+ description: enable real-time clock wake-up
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91sam9x5-shdwc
+ then:
+ properties:
+ atmel,wakeup-rtt-timer: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91sam9260-shdwc
+ then:
+ properties:
+ atmel,wakeup-rtc-timer: false
+
+additionalProperties: false
+
+examples:
+ - |
+ shdwc: poweroff@fffffd10 {
+ compatible = "atmel,at91sam9260-shdwc";
+ reg = <0xfffffd10 0x10>;
+ clocks = <&clk32k>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml
new file mode 100644
index 000000000000..9c34249b2d6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/atmel,sama5d2-shdwc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip AT91 SAMA5D2 SHDWC Shutdown Controller
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea@microchip.com>
+
+description: |
+ Microchip AT91 SHDWC shutdown controller controls the power supplies VDDIO
+ and VDDCORE and the wake-up detection on debounced input lines.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - microchip,sama7d65-shdwc
+ - const: microchip,sama7g5-shdwc
+ - const: syscon
+ - items:
+ - const: microchip,sama7g5-shdwc
+ - const: syscon
+ - enum:
+ - atmel,sama5d2-shdwc
+ - microchip,sam9x60-shdwc
+ - items:
+ - const: microchip,sam9x7-shdwc
+ - const: microchip,sam9x60-shdwc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ debounce-delay-us:
+ description:
+ Minimum wake-up inputs debouncer period in microseconds. It is usually a
+ board-related property.
+
+ atmel,wakeup-rtc-timer:
+ description: enable real-time clock wake-up
+ type: boolean
+
+ atmel,wakeup-rtt-timer:
+ description: enable real-time timer wake-up
+ type: boolean
+
+patternProperties:
+ "^input@[0-15]$":
+ description:
+ Wake-up input nodes. These are usually described in the "board" part of
+ the Device Tree. Note also that input 0 is linked to the wake-up pin and
+ is frequently used.
+ type: object
+ properties:
+ reg:
+ description: contains the wake-up input index
+ minimum: 0
+ maximum: 15
+
+ atmel,wakeup-active-high:
+ description:
+ The corresponding wake-up input described by the child forces the
+ wake-up of the core power supply on a high level. The default is to
+ be active low.
+ type: boolean
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,sama5d2-shdwc
+ then:
+ properties:
+ atmel,wakeup-rtt-timer: false
+
+additionalProperties: false
+
+examples:
+ - |
+ shdwc: poweroff@f8048010 {
+ compatible = "atmel,sama5d2-shdwc";
+ reg = <0xf8048010 0x10>;
+ clocks = <&clk32k>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,wakeup-rtc-timer;
+ debounce-delay-us = <976>;
+
+ input@0 {
+ reg = <0>;
+ };
+
+ input@1 {
+ reg = <1>;
+ atmel,wakeup-active-high;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt
deleted file mode 100644
index 93f31ca1ef4b..000000000000
--- a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Broadcom Kona Family Reset Manager
-----------------------------------
-
-The reset manager is used on the Broadcom BCM21664 SoC.
-
-Required properties:
- - compatible: brcm,bcm21664-resetmgr
- - reg: memory address & range
-
-Example:
- brcm,resetmgr@35001f00 {
- compatible = "brcm,bcm21664-resetmgr";
- reg = <0x35001f00 0x24>;
- };
diff --git a/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml
new file mode 100644
index 000000000000..3e28a59d718f
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/brcm,bcm21664-resetmgr.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/brcm,bcm21664-resetmgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family reset manager
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,bcm21664-resetmgr
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ reset-controller@35001f00 {
+ compatible = "brcm,bcm21664-resetmgr";
+ reg = <0x35001f00 0x24>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
index 45d66c775115..a4b437fce37c 100644
--- a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
+++ b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/reset/gpio-poweroff.yaml#
@@ -18,6 +18,9 @@ description: >
Finally the operating system assumes the power off failed if
the system is still running after waiting some time (timeout-ms).
+allOf:
+ - $ref: restart-handler.yaml#
+
properties:
compatible:
const: gpio-poweroff
@@ -40,6 +43,9 @@ properties:
default: 100
description: Delay to wait after driving gpio inactive
+ priority:
+ default: 0
+
timeout-ms:
default: 3000
description: Time to wait before assuming the power off sequence failed.
diff --git a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
index a72d5c721516..53535de0d41c 100644
--- a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
+++ b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/reset/gpio-restart.yaml#
@@ -25,6 +25,9 @@ description: >
inactive-delay, the GPIO is driven active again. After a delay specified by wait-delay, the
restart handler completes allowing other restart handlers to be attempted.
+allOf:
+ - $ref: restart-handler.yaml#
+
properties:
compatible:
const: gpio-restart
@@ -41,16 +44,6 @@ properties:
in its inactive state.
priority:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- A priority ranging from 0 to 255 (default 129) according to the following guidelines:
-
- 0: Restart handler of last resort, with limited restart capabilities.
- 128: Default restart handler; use if no other restart handler is expected to be available,
- and/or if restart functionality is sufficient to restart the entire system.
- 255: Highest priority restart handler, will preempt all other restart handlers.
- minimum: 0
- maximum: 255
default: 129
active-delay:
diff --git a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
deleted file mode 100644
index 933f0c48e887..000000000000
--- a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Device Tree Bindings for Power Controller on MediaTek PMIC
-
-The power controller which could be found on PMIC is responsible for externally
-powering off or on the remote MediaTek SoC through the circuit BBPU.
-
-Required properties:
-- compatible: Should be one of follows
- "mediatek,mt6323-pwrc": for MT6323 PMIC
-
-Example:
-
- pmic {
- compatible = "mediatek,mt6323";
-
- ...
-
- power-controller {
- compatible = "mediatek,mt6323-pwrc";
- };
- }
diff --git a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt
deleted file mode 100644
index 752d6126d5da..000000000000
--- a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-NVMEM reboot mode driver
-
-This driver gets reboot mode magic value from reboot-mode driver
-and stores it in a NVMEM cell named "reboot-mode". Then the bootloader
-can read it and take different action according to the magic
-value stored.
-
-Required properties:
-- compatible: should be "nvmem-reboot-mode".
-- nvmem-cells: A phandle to the reboot mode provided by a nvmem device.
-- nvmem-cell-names: Should be "reboot-mode".
-
-The rest of the properties should follow the generic reboot-mode description
-found in reboot-mode.txt
-
-Example:
- reboot-mode {
- compatible = "nvmem-reboot-mode";
- nvmem-cells = <&reboot_mode>;
- nvmem-cell-names = "reboot-mode";
-
- mode-normal = <0xAAAA5501>;
- mode-bootloader = <0xBBBB5500>;
- mode-recovery = <0xCCCC5502>;
- mode-test = <0xDDDD5503>;
- };
diff --git a/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml
new file mode 100644
index 000000000000..7f5f94673e9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/nvmem-reboot-mode.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/nvmem-reboot-mode.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic NVMEM reboot mode
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+ This driver gets the reboot mode magic value from the reboot-mode driver
+ and stores it in the NVMEM cell named "reboot-mode". The bootloader can
+ then read it and take different action according to the value.
+
+properties:
+ compatible:
+ const: nvmem-reboot-mode
+
+ nvmem-cells:
+ description:
+ A phandle pointing to the nvmem-cells node where the vendor-specific
+ magic value representing the reboot mode is stored.
+ maxItems: 1
+
+ nvmem-cell-names:
+ items:
+ - const: reboot-mode
+
+allOf:
+ - $ref: reboot-mode.yaml#
+
+patternProperties:
+ "^mode-.*$":
+ maxItems: 1
+
+required:
+ - compatible
+ - nvmem-cells
+ - nvmem-cell-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ reboot-mode {
+ compatible = "nvmem-reboot-mode";
+ nvmem-cells = <&reboot_reason>;
+ nvmem-cell-names = "reboot-mode";
+ mode-recovery = <0x01>;
+ mode-bootloader = <0x02>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
index e7b436d2e757..979a377cb4ff 100644
--- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
+++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
@@ -15,18 +15,28 @@ description: |
This DT node has pwrkey and resin as sub nodes.
-allOf:
- - $ref: reboot-mode.yaml#
-
properties:
compatible:
enum:
- qcom,pm8916-pon
+ - qcom,pm8941-pon
- qcom,pms405-pon
- qcom,pm8998-pon
+ - qcom,pmk8350-pon
reg:
- maxItems: 1
+ description: |
+ Specifies the SPMI base address for the PON (power-on) peripheral. For
+ PMICs that have the PON peripheral (GEN3) split into PON_HLOS and PON_PBS
+ (e.g. PMK8350), this can hold addresses of both PON_HLOS and PON_PBS
+ peripherals. In that case, the PON_PBS address needs to be specified to
+ facilitate software debouncing on some PMIC.
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
pwrkey:
type: object
@@ -44,41 +54,101 @@ required:
- compatible
- reg
+patternProperties:
+ "^mode-.*$":
+ maxItems: 1
+
unevaluatedProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pm8916-pon
+ - qcom,pms405-pon
+ - qcom,pm8998-pon
+ then:
+ allOf:
+ - $ref: reboot-mode.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ items:
+ - const: pon
+ else:
+ patternProperties:
+ "^mode-.*$": false
+
+ # Special case for pm8941, which doesn't store reset mode
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,pm8941-pon
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ items:
+ - const: pon
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,pmk8350-pon
+ then:
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 2
+ reg-names:
+ minItems: 1
+ items:
+ - const: hlos
+ - const: pbs
+
examples:
- |
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/input/linux-event-codes.h>
- #include <dt-bindings/spmi/spmi.h>
- spmi_bus: spmi@c440000 {
- reg = <0x0c440000 0x1100>;
- #address-cells = <2>;
- #size-cells = <0>;
- pmk8350: pmic@0 {
- reg = <0x0 SPMI_USID>;
- #address-cells = <1>;
- #size-cells = <0>;
- pmk8350_pon: pon_hlos@1300 {
- reg = <0x1300>;
- compatible = "qcom,pm8998-pon";
-
- pwrkey {
- compatible = "qcom,pm8941-pwrkey";
- interrupts = < 0x0 0x8 0 IRQ_TYPE_EDGE_BOTH >;
- debounce = <15625>;
- bias-pull-up;
- linux,code = <KEY_POWER>;
- };
-
- resin {
- compatible = "qcom,pm8941-resin";
- interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
- debounce = <15625>;
- bias-pull-up;
- linux,code = <KEY_VOLUMEDOWN>;
- };
- };
- };
- };
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/input/linux-event-codes.h>
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi@c440000 {
+ reg = <0x0c440000 0x1100>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@0 {
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pon@800 {
+ compatible = "qcom,pm8998-pon";
+ reg = <0x800>;
+
+ pwrkey {
+ compatible = "qcom,pm8941-pwrkey";
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ linux,code = <KEY_POWER>;
+ };
+
+ resin {
+ compatible = "qcom,pm8941-resin";
+ interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ linux,code = <KEY_VOLUMEDOWN>;
+ };
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
index ad0a0b95cec1..3ddac06cec72 100644
--- a/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
+++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
@@ -28,13 +28,13 @@ description: |
properties:
mode-normal:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description:
Default value to set on a reboot if no command was provided.
patternProperties:
"^mode-.*$":
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
new file mode 100644
index 000000000000..965a834a3dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/restart-handler.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Restart and shutdown handler Common Properties
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description:
+ Restart and shutdown handler device is responsible for powering off the
+ system, e.g. my cutting off the power. System might have several restart
+ handlers, which usually are tried from most precise to last resort.
+
+properties:
+ priority:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ A priority ranging from 0 to 255 according to the following guidelines::
+ 0:: Restart handler of last resort, with limited restart capabilities.
+ 128:: Typical, default restart handler; use if no other restart handler
+ is expected to be available, and/or if restart functionality is
+ sufficient to restart the entire system.
+ 255:: Highest priority restart handler, will preempt all other restart handlers.
+ minimum: 0
+ maximum: 255
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/syscon-poweroff.yaml
index 3412fe7e1e80..d342b113fca2 100644
--- a/Documentation/devicetree/bindings/power/reset/syscon-poweroff.yaml
+++ b/Documentation/devicetree/bindings/power/reset/syscon-poweroff.yaml
@@ -15,6 +15,9 @@ description: |+
defined by the register map pointed by syscon reference plus the offset
with the value and mask defined in the poweroff node.
Default will be little endian mode, 32 bit access only.
+ The SYSCON register map is normally retrieved from the parental dt-node. So
+ the SYSCON poweroff node should be represented as a sub-node of a "syscon",
+ "simple-mfd" node.
properties:
compatible:
@@ -30,7 +33,10 @@ properties:
regmap:
$ref: /schemas/types.yaml#/definitions/phandle
- description: Phandle to the register map node.
+ deprecated: true
+ description:
+ Phandle to the register map node. This property is deprecated in favor of
+ the syscon-poweroff node being a child of a system controller node.
value:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -38,7 +44,6 @@ properties:
required:
- compatible
- - regmap
- offset
additionalProperties: false
@@ -56,7 +61,6 @@ examples:
- |
poweroff {
compatible = "syscon-poweroff";
- regmap = <&regmapnode>;
offset = <0x0>;
mask = <0x7a>;
};
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
index 9b1ffceefe3d..79ffc78b23ea 100644
--- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
@@ -29,12 +29,14 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description: Offset in the register map for the mode register (in bytes)
+allOf:
+ - $ref: reboot-mode.yaml#
+
patternProperties:
- "^mode-.+":
- $ref: /schemas/types.yaml#/definitions/uint32
- description: Vendor-specific mode value written to the mode register
+ "^mode-.*$":
+ maxItems: 1
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
index da2509724812..ccd555870094 100644
--- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml
@@ -21,7 +21,9 @@ description: |+
properties:
compatible:
- const: syscon-reboot
+ enum:
+ - syscon-reboot
+ - google,gs101-reboot
mask:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -31,6 +33,10 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description: Offset in the register map for the reboot register (in bytes).
+ reg:
+ maxItems: 1
+ description: Base address and size for the reboot register.
+
regmap:
$ref: /schemas/types.yaml#/definitions/phandle
deprecated: true
@@ -42,20 +48,40 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description: The reset value written to the reboot register (32 bit access).
+ priority:
+ default: 192
+
required:
- compatible
- - offset
additionalProperties: false
allOf:
+ - $ref: restart-handler.yaml#
- if:
- not:
- required:
- - mask
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-reboot
then:
- required:
- - value
+ properties:
+ mask: false
+ offset: false
+ reg: false
+ value: false
+
+ else:
+ if:
+ not:
+ required:
+ - mask
+ then:
+ required:
+ - value
+
+ oneOf:
+ - required: [offset]
+ - required: [reg]
examples:
- |
@@ -65,3 +91,8 @@ examples:
offset = <0x0>;
mask = <0x1>;
};
+
+ - |
+ reboot {
+ compatible = "google,gs101-reboot";
+ };
diff --git a/Documentation/devicetree/bindings/power/reset/toradex,smarc-ec.yaml b/Documentation/devicetree/bindings/power/reset/toradex,smarc-ec.yaml
new file mode 100644
index 000000000000..ffcd5f2c2bf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/toradex,smarc-ec.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/toradex,smarc-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toradex Embedded Controller
+
+maintainers:
+ - Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
+ - Francesco Dolcini <francesco.dolcini@toradex.com>
+
+description: |
+ The Toradex Embedded Controller (EC) is used on Toradex SMARC modules,
+ primarily to manage power and reset functionalities.
+
+ The EC provides the following functions:
+ - Reads the SMARC POWER_BTN# and RESET_IN# signals and controls the PMIC accordingly.
+ - Controls the SoC boot mode signals based on the SMARC BOOT_SEL# and FORCE_RECOV# inputs.
+ - Manages the CARRIER_STDBY# signal in response to relevant SoC signals.
+
+ The EC runs a small firmware, factory programmed into its internal flash, and communicates over I2C.
+ It allows software to control power-off and reset functionalities of the module.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - toradex,smarc-imx95-ec
+ - toradex,smarc-imx8mp-ec
+ - const: toradex,smarc-ec
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-controller@28 {
+ compatible = "toradex,smarc-imx95-ec", "toradex,smarc-ec";
+ reg = <0x28>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
index 46de35861738..079ad977b907 100644
--- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
+++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/power/reset/xlnx,zynqmp-power.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx Zynq MPSoC Power Management Device Tree Bindings
+title: Xilinx Zynq MPSoC Power Management
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
description: |
The zynqmp-power node describes the power management configurations.
@@ -46,7 +46,6 @@ properties:
required:
- compatible
- - interrupts
additionalProperties: false
@@ -57,7 +56,7 @@ examples:
firmware {
zynqmp-firmware {
- zynqmp-power {
+ power-management {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};
@@ -70,7 +69,7 @@ examples:
firmware {
zynqmp-firmware {
- zynqmp-power {
+ power-management {
compatible = "xlnx,zynqmp-power";
interrupt-parent = <&gic>;
interrupts = <0 35 4>;
diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
index 0d5e999a58f1..b41db576f95d 100644
--- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -40,9 +40,13 @@ properties:
- rockchip,rk3366-power-controller
- rockchip,rk3368-power-controller
- rockchip,rk3399-power-controller
+ - rockchip,rk3528-power-controller
+ - rockchip,rk3562-power-controller
- rockchip,rk3568-power-controller
+ - rockchip,rk3576-power-controller
- rockchip,rk3588-power-controller
- rockchip,rv1126-power-controller
+ - rockchip,rv1126b-power-controller
"#power-domain-cells":
const: 1
@@ -123,6 +127,7 @@ $defs:
"include/dt-bindings/power/rk3568-power.h"
"include/dt-bindings/power/rk3588-power.h"
"include/dt-bindings/power/rockchip,rv1126-power.h"
+ "include/dt-bindings/power/rockchip,rv1126b-power-controller.h"
clocks:
minItems: 1
@@ -131,6 +136,9 @@ $defs:
A number of phandles to clocks that need to be enabled
while power domain switches state.
+ domain-supply:
+ description: domain regulator supply.
+
pm_qos:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
index d71fc72d4464..c434277218ea 100644
--- a/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
+++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml
@@ -50,6 +50,7 @@ properties:
- rockchip,rk3188-io-voltage-domain
- rockchip,rk3228-io-voltage-domain
- rockchip,rk3288-io-voltage-domain
+ - rockchip,rk3308-io-voltage-domain
- rockchip,rk3328-io-voltage-domain
- rockchip,rk3368-io-voltage-domain
- rockchip,rk3368-pmu-io-voltage-domain
@@ -71,6 +72,7 @@ allOf:
- $ref: "#/$defs/rk3188"
- $ref: "#/$defs/rk3228"
- $ref: "#/$defs/rk3288"
+ - $ref: "#/$defs/rk3308"
- $ref: "#/$defs/rk3328"
- $ref: "#/$defs/rk3368"
- $ref: "#/$defs/rk3368-pmu"
@@ -194,6 +196,28 @@ $defs:
wifi-supply:
description: The supply connected to APIO3_VDD. Also known as SDIO0.
+ rk3308:
+ if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3308-io-voltage-domain
+
+ then:
+ properties:
+ vccio0-supply:
+ description: The supply connected to VCCIO0.
+ vccio1-supply:
+ description: The supply connected to VCCIO1.
+ vccio2-supply:
+ description: The supply connected to VCCIO2.
+ vccio3-supply:
+ description: The supply connected to VCCIO3.
+ vccio4-supply:
+ description: The supply connected to VCCIO4.
+ vccio5-supply:
+ description: The supply connected to VCCIO5.
+
rk3328:
if:
properties:
diff --git a/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml
new file mode 100644
index 000000000000..98eb8b4110e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/starfive,jh7110-pmu.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/starfive,jh7110-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 Power Management Unit
+
+maintainers:
+ - Walker Chen <walker.chen@starfivetech.com>
+
+description: |
+ StarFive JH7110 SoC includes support for multiple power domains which can be
+ powered on/off by software based on different application scenes to save power.
+
+properties:
+ compatible:
+ enum:
+ - starfive,jh7110-pmu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#power-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ pwrc: power-controller@17030000 {
+ compatible = "starfive,jh7110-pmu";
+ reg = <0x17030000 0x10000>;
+ interrupts = <111>;
+ #power-domain-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml b/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml
deleted file mode 100644
index 5220d9cb16d8..000000000000
--- a/Documentation/devicetree/bindings/power/supply/active-semi,act8945a-charger.yaml
+++ /dev/null
@@ -1,76 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/power/supply/active-semi,act8945a-charger.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Active-semi ACT8945A Charger Function
-
-maintainers:
- - Sebastian Reichel <sre@kernel.org>
-
-allOf:
- - $ref: power-supply.yaml#
-
-properties:
- compatible:
- const: active-semi,act8945a-charger
-
- interrupts:
- maxItems: 1
-
- active-semi,chglev-gpios:
- maxItems: 1
- description: charge current level GPIO
-
- active-semi,lbo-gpios:
- maxItems: 1
- description: low battery voltage detect GPIO
-
- active-semi,input-voltage-threshold-microvolt:
- description: |
- Specifies the charger's input over-voltage threshold value.
- Despite the name, specified values are in millivolt (mV).
- Defaults to 6.6 V
- enum: [ 6600, 7000, 7500, 8000 ]
-
- active-semi,precondition-timeout:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- Specifies the charger's PRECONDITION safety timer setting value in minutes.
- If 0, it means to disable this timer.
- Defaults to 40 minutes.
- enum: [ 0, 40, 60, 80 ]
-
- active-semi,total-timeout:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- Specifies the charger's total safety timer setting value in hours;
- If 0, it means to disable this timer;
- Defaults to 3 hours.
- enum: [ 0, 3, 4, 5 ]
-
-required:
- - compatible
- - interrupts
- - active-semi,chglev-gpios
- - active-semi,lbo-gpios
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- pmic {
- charger {
- compatible = "active-semi,act8945a-charger";
- interrupt-parent = <&pioA>;
- interrupts = <45 IRQ_TYPE_LEVEL_LOW>;
- active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>;
- active-semi,lbo-gpios = <&pioA 72 GPIO_ACTIVE_LOW>;
- active-semi,input-voltage-threshold-microvolt = <6600>;
- active-semi,precondition-timeout = <40>;
- active-semi,total-timeout = <3>;
- };
- };
diff --git a/Documentation/devicetree/bindings/power/supply/adc-battery.yaml b/Documentation/devicetree/bindings/power/supply/adc-battery.yaml
new file mode 100644
index 000000000000..ed9702caedff
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/adc-battery.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/adc-battery.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADC battery
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description:
+ Basic battery capacity meter, which only reports basic battery data
+ via ADC channels and optionally indicate that the battery is full by
+ polling a GPIO line.
+
+ The voltage is expected to be measured between the battery terminals
+ and mandatory. The optional current/power channel is expected to
+ monitor the current/power flowing out of the battery. Last but not
+ least the temperature channel is supposed to measure the battery
+ temperature.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: adc-battery
+
+ charged-gpios:
+ description:
+ GPIO which signals that the battery is fully charged. The GPIO is
+ often provided by charger ICs, that are not software controllable.
+ maxItems: 1
+
+ io-channels:
+ minItems: 1
+ maxItems: 4
+
+ io-channel-names:
+ minItems: 1
+ items:
+ - const: voltage
+ - enum: [ current, power, temperature ]
+ - enum: [ power, temperature ]
+ - const: temperature
+
+ monitored-battery: true
+
+required:
+ - compatible
+ - io-channels
+ - io-channel-names
+ - monitored-battery
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ fuel-gauge {
+ compatible = "adc-battery";
+ charged-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
+ io-channels = <&adc 13>, <&adc 37>;
+ io-channel-names = "voltage", "current";
+
+ power-supplies = <&charger>;
+ monitored-battery = <&battery>;
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml
index a3c00e078918..13822346e708 100644
--- a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/power/supply/bq2415x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for TI bq2415x Li-Ion Charger
+title: TI bq2415x Li-Ion Charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -77,7 +77,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/bq24190.yaml b/Documentation/devicetree/bindings/power/supply/bq24190.yaml
index 4884ec90e2b8..938554a9fb02 100644
--- a/Documentation/devicetree/bindings/power/supply/bq24190.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq24190.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/power/supply/bq24190.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for TI BQ2419x Li-Ion Battery Charger
+title: TI BQ2419x Li-Ion Battery Charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -19,7 +19,10 @@ properties:
- ti,bq24190
- ti,bq24192
- ti,bq24192i
+ - ti,bq24193
- ti,bq24196
+ - ti,bq24296
+ - ti,bq24297
reg:
maxItems: 1
@@ -27,6 +30,12 @@ properties:
interrupts:
maxItems: 1
+ ce-gpios:
+ description:
+ Active low Charge Enable pin. Battery charging is enabled when
+ REG01[5:4] = 01 and CE pin is Low. CE pin must be pulled high or low.
+ maxItems: 1
+
usb-otg-vbus:
$ref: /schemas/regulator/regulator.yaml#
description: |
@@ -45,7 +54,6 @@ properties:
battery device.
monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
description: |
phandle to a "simple-battery" compatible node.
@@ -75,7 +83,7 @@ examples:
charge-term-current-microamp = <128000>;
};
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/bq24257.yaml b/Documentation/devicetree/bindings/power/supply/bq24257.yaml
index c7406bef0fa8..eb064bbf876c 100644
--- a/Documentation/devicetree/bindings/power/supply/bq24257.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq24257.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/power/supply/bq24257.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for bq24250, bq24251 and bq24257 Li-Ion Charger
+title: Bq24250, bq24251 and bq24257 Li-Ion Charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -84,7 +84,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -104,7 +104,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/bq24735.yaml b/Documentation/devicetree/bindings/power/supply/bq24735.yaml
index dd9176ce71b3..af41e7ccd784 100644
--- a/Documentation/devicetree/bindings/power/supply/bq24735.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq24735.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/power/supply/bq24735.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for TI BQ24735 Li-Ion Battery Charger
+title: TI BQ24735 Li-Ion Battery Charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -77,7 +77,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
index 1a1b240034ef..0e99a218e662 100644
--- a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
@@ -53,15 +53,16 @@ properties:
minimum: 50000
maximum: 500000
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to the battery node being monitored
+ monitored-battery: true
required:
- compatible
- reg
- monitored-battery
+allOf:
+ - $ref: power-supply.yaml#
+
additionalProperties: false
examples:
@@ -73,7 +74,7 @@ examples:
constant-charge-voltage-max-microvolt = <4000000>;
};
#include <dt-bindings/gpio/gpio.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
index 82f382a7ffb3..8cee37b9879e 100644
--- a/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq256xx.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
%YAML 1.2
---
@@ -58,9 +58,7 @@ properties:
minimum: 100000
maximum: 3200000
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to the battery node being monitored
+ monitored-battery: true
interrupts:
maxItems: 1
@@ -68,11 +66,30 @@ properties:
Interrupt sends an active low, 256 μs pulse to host to report the charger
device status and faults.
+ ti,no-thermistor:
+ type: boolean
+ description: Indicates that no thermistor is connected to the TS pin
+
required:
- compatible
- reg
- monitored-battery
+allOf:
+ - $ref: power-supply.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,bq25600
+ - ti,bq25601
+ - ti,bq25600d
+ - ti,bq25601d
+ then:
+ properties:
+ ti,no-thermistor: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/power/supply/bq25890.yaml b/Documentation/devicetree/bindings/power/supply/bq25890.yaml
index 204c0147188f..0ad302ab2bcc 100644
--- a/Documentation/devicetree/bindings/power/supply/bq25890.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq25890.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/power/supply/bq25890.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for bq25890, bq25892, bq25895 and bq25896 Li-Ion Charger
+title: Bq25890, bq25892, bq25895 and bq25896 Li-Ion Charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -15,11 +15,15 @@ allOf:
properties:
compatible:
- enum:
- - ti,bq25890
- - ti,bq25892
- - ti,bq25895
- - ti,bq25896
+ oneOf:
+ - enum:
+ - ti,bq25890
+ - items:
+ - enum:
+ - ti,bq25892
+ - ti,bq25895
+ - ti,bq25896
+ - const: ti,bq25890
reg:
maxItems: 1
@@ -93,12 +97,12 @@ required:
- ti,boost-voltage
- ti,boost-max-current
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/bq25980.yaml b/Documentation/devicetree/bindings/power/supply/bq25980.yaml
index b687b8bcd705..0b5d005dc780 100644
--- a/Documentation/devicetree/bindings/power/supply/bq25980.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq25980.yaml
@@ -73,9 +73,7 @@ properties:
description: |
Indicates that the device state has changed.
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to the battery node being monitored
+ monitored-battery: true
required:
- compatible
@@ -87,28 +85,28 @@ unevaluatedProperties: false
examples:
- |
bat: battery {
- compatible = "simple-battery";
- constant-charge-current-max-microamp = <4000000>;
- constant-charge-voltage-max-microvolt = <8400000>;
- precharge-current-microamp = <160000>;
- charge-term-current-microamp = <160000>;
+ compatible = "simple-battery";
+ constant-charge-current-max-microamp = <4000000>;
+ constant-charge-voltage-max-microvolt = <8400000>;
+ precharge-current-microamp = <160000>;
+ charge-term-current-microamp = <160000>;
};
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- bq25980: charger@65 {
- compatible = "ti,bq25980";
- reg = <0x65>;
- interrupt-parent = <&gpio1>;
- interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
- ti,watchdog-timeout-ms = <0>;
- ti,sc-ocp-limit-microamp = <2000000>;
- ti,sc-ovp-limit-microvolt = <17800000>;
- monitored-battery = <&bat>;
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bq25980: charger@65 {
+ compatible = "ti,bq25980";
+ reg = <0x65>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ ti,watchdog-timeout-ms = <0>;
+ ti,sc-ocp-limit-microamp = <2000000>;
+ ti,sc-ovp-limit-microvolt = <17800000>;
+ monitored-battery = <&bat>;
+ };
};
...
diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
index 65fc6049efc1..bc05400186cf 100644
--- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
@@ -16,9 +16,6 @@ description: |
Support various Texas Instruments fuel gauge devices that share similar
register maps and power supply properties
-allOf:
- - $ref: power-supply.yaml#
-
properties:
compatible:
enum:
@@ -58,18 +55,50 @@ properties:
maxItems: 1
description: integer, I2C address of the fuel gauge.
+ interrupts:
+ maxItems: 1
+ description: the SOC_INT or GPOUT pin
+
monitored-battery:
description: |
- phandle of battery characteristics node.
The fuel gauge uses the following battery properties:
- energy-full-design-microwatt-hours
- charge-full-design-microamp-hours
- voltage-min-design-microvolt
Both or neither of the *-full-design-*-hours properties must be set.
- See Documentation/devicetree/bindings/power/supply/battery.yaml
power-supplies: true
+allOf:
+ - $ref: power-supply.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,bq27200
+ - ti,bq27210
+ - ti,bq27500 # deprecated, use revision specific property below
+ - ti,bq27510 # deprecated, use revision specific property below
+ - ti,bq27520 # deprecated, use revision specific property below
+ - ti,bq27500-1
+ - ti,bq27510g1
+ - ti,bq27510g2
+ - ti,bq27521
+ - ti,bq27541
+ - ti,bq27542
+ - ti,bq27546
+ - ti,bq27742
+ - ti,bq27545
+ - ti,bq27411
+ - ti,bq27z561
+ - ti,bq28z610
+ - ti,bq34z100
+ - ti,bq78z100
+ then:
+ properties:
+ interrupts: false
+
required:
- compatible
- reg
@@ -77,15 +106,16 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ bat: battery {
+ compatible = "simple-battery";
+ voltage-min-design-microvolt = <3200000>;
+ energy-full-design-microwatt-hours = <5290000>;
+ charge-full-design-microamp-hours = <1430000>;
+ };
+
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
- bat: battery {
- compatible = "simple-battery";
- voltage-min-design-microvolt = <3200000>;
- energy-full-design-microwatt-hours = <5290000>;
- charge-full-design-microamp-hours = <1430000>;
- };
bq27510g3: fuel-gauge@55 {
compatible = "ti,bq27510g3";
diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
index dc697b6147b2..f7bde324153d 100644
--- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
+++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml
@@ -43,10 +43,7 @@ properties:
minItems: 1
maxItems: 8 # Should be enough
- monitored-battery:
- description:
- Specifies the phandle of a simple-battery connected to this gauge
- $ref: /schemas/types.yaml#/definitions/phandle
+ monitored-battery: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml b/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml
index b289388952bf..85bebebb285b 100644
--- a/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/dlg,da9150-charger.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/dlg,da9150-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dialog Semiconductor DA9150 Charger Power Supply bindings
+title: Dialog Semiconductor DA9150 Charger Power Supply
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml b/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml
index d47caf59d204..7cc94b872937 100644
--- a/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml
+++ b/Documentation/devicetree/bindings/power/supply/dlg,da9150-fuel-gauge.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/dlg,da9150-fuel-gauge.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Dialog Semiconductor DA9150 Fuel-Gauge Power Supply bindings
+title: Dialog Semiconductor DA9150 Fuel-Gauge Power Supply
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
index 89f8e2bcb2d7..25826bfc289c 100644
--- a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml
@@ -58,6 +58,10 @@ properties:
charge-current-limit-gpios property. Bit 1 second to last
GPIO and so on.
+ charge-current-limit-default-microamp:
+ description: Default charge current limit. Must be listed in
+ charge-current-limit-mapping.
+
required:
- compatible
@@ -72,6 +76,7 @@ anyOf:
dependencies:
charge-current-limit-gpios: [ charge-current-limit-mapping ]
charge-current-limit-mapping: [ charge-current-limit-gpios ]
+ charge-current-limit-default-microamp: [charge-current-limit-mapping]
additionalProperties: false
@@ -91,4 +96,5 @@ examples:
charge-current-limit-mapping = <2500000 0x00>, // 2.5 A => both GPIOs low
<700000 0x01>, // 700 mA => GPIO A.12 high
<0 0x02>; // 0 mA => GPIO A.11 high
+ charge-current-limit-default-microamp = <700000>;
};
diff --git a/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml b/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml
index 46527038bf22..cb04fb25d8ac 100644
--- a/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml
+++ b/Documentation/devicetree/bindings/power/supply/ingenic,battery.yaml
@@ -5,11 +5,13 @@
$id: http://devicetree.org/schemas/power/supply/ingenic,battery.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic JZ47xx battery bindings
+title: Ingenic JZ47xx battery
maintainers:
- Artur Rojek <contact@artur-rojek.eu>
+$ref: power-supply.yaml#
+
properties:
compatible:
oneOf:
@@ -28,8 +30,6 @@ properties:
monitored-battery:
description: >
- phandle to a "simple-battery" compatible node.
-
This property must be a phandle to a node using the format described
in battery.yaml, with the following properties being required:
- voltage-min-design-microvolt: drained battery voltage,
@@ -48,14 +48,14 @@ examples:
#include <dt-bindings/iio/adc/ingenic,adc.h>
simple_battery: battery {
- compatible = "simple-battery";
- voltage-min-design-microvolt = <3600000>;
- voltage-max-design-microvolt = <4200000>;
+ compatible = "simple-battery";
+ voltage-min-design-microvolt = <3600000>;
+ voltage-max-design-microvolt = <4200000>;
};
ingenic-battery {
- compatible = "ingenic,jz4740-battery";
- io-channels = <&adc INGENIC_ADC_BATTERY>;
- io-channel-names = "battery";
- monitored-battery = <&simple_battery>;
+ compatible = "ingenic,jz4740-battery";
+ io-channels = <&adc INGENIC_ADC_BATTERY>;
+ io-channel-names = "battery";
+ monitored-battery = <&simple_battery>;
};
diff --git a/Documentation/devicetree/bindings/power/supply/isp1704.yaml b/Documentation/devicetree/bindings/power/supply/isp1704.yaml
index 7e3449ed70d4..fb3a812aa5a9 100644
--- a/Documentation/devicetree/bindings/power/supply/isp1704.yaml
+++ b/Documentation/devicetree/bindings/power/supply/isp1704.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/power/supply/isp1704.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for NXP ISP1704 USB Charger Detection
+title: NXP ISP1704 USB Charger Detection
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml b/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml
index 76cedf95a12c..d26ed5eabe28 100644
--- a/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/lltc,lt3651-charger.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/lltc,lt3651-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices LT3651 Charger Power Supply bindings
+title: Analog Devices LT3651 Charger Power Supply
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml b/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml
index 109b41a0d56c..e68a97cb49fe 100644
--- a/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml
+++ b/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/lltc,ltc294x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for LTC2941, LTC2942, LTC2943 and LTC2944 battery fuel gauges
+title: LTC2941, LTC2942, LTC2943 and LTC2944 battery fuel gauges
description: |
All chips measure battery capacity.
@@ -54,7 +54,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
battery@64 {
diff --git a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml
index cfffaeef8b09..bc7ed7b22085 100644
--- a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml
+++ b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml
@@ -17,12 +17,18 @@ description: |
panels, etc., and a rechargeable Lithium-Ion/Polymer battery.
Specifications about the charger can be found at:
+ https://www.analog.com/en/products/ltc4162-l.html
+ https://www.analog.com/en/products/ltc4162-f.html
https://www.analog.com/en/products/ltc4162-s.html
+ https://www.analog.com/en/products/ltc4015.html
properties:
compatible:
enum:
+ - lltc,ltc4015
+ - lltc,ltc4162-f
- lltc,ltc4162-l
+ - lltc,ltc4162-s
reg:
maxItems: 1
@@ -54,14 +60,14 @@ additionalProperties: false
examples:
- |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- charger: battery-charger@68 {
- compatible = "lltc,ltc4162-l";
- reg = <0x68>;
- lltc,rsnsb-micro-ohms = <10000>;
- lltc,rsnsi-micro-ohms = <16000>;
- lltc,cell-count = <2>;
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ charger: battery-charger@68 {
+ compatible = "lltc,ltc4162-l";
+ reg = <0x68>;
+ lltc,rsnsb-micro-ohms = <10000>;
+ lltc,rsnsi-micro-ohms = <16000>;
+ lltc,cell-count = <2>;
+ };
};
diff --git a/Documentation/devicetree/bindings/power/supply/max8925_battery.txt b/Documentation/devicetree/bindings/power/supply/max8925_battery.txt
deleted file mode 100644
index d7e3e0c0f71d..000000000000
--- a/Documentation/devicetree/bindings/power/supply/max8925_battery.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-max8925-battery bindings
-~~~~~~~~~~~~~~~~
-
-Optional properties :
- - batt-detect: whether support battery detect
- - topoff-threshold: set charging current in topoff mode
- - fast-charge: set charging current in fast mode
- - no-temp-support: whether support temperature protection detect
- - no-insert-detect: whether support insert detect
-
-Example:
- charger {
- batt-detect = <0>;
- topoff-threshold = <1>;
- fast-charge = <7>;
- no-temp-support = <0>;
- no-insert-detect = <0>;
- };
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml b/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml
index c838efcf7e16..5faa2418fe2f 100644
--- a/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml
+++ b/Documentation/devicetree/bindings/power/supply/maxim,ds2760.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/maxim,ds2760.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Maxim DS2760 DT bindings
+title: Maxim DS2760
maintainers:
- Sebastian Reichel <sre@kernel.org>
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml
index 070ef6f96e60..b444b799848e 100644
--- a/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/maxim,max14656.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Maxim MAX14656 DT bindings
+title: Maxim MAX14656
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -32,7 +32,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml
index 3a529326ecbd..377cbb2c2c1f 100644
--- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml
@@ -55,6 +55,14 @@ properties:
interrupts:
maxItems: 1
+ io-channels:
+ items:
+ - description: battery temperature
+
+ io-channel-names:
+ items:
+ - const: temp
+
wakeup-source:
type: boolean
description: |
@@ -68,7 +76,7 @@ unevaluatedProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -82,7 +90,7 @@ examples:
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -95,3 +103,26 @@ examples:
wakeup-source;
};
};
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fuel-gauge@36 {
+ compatible = "maxim,max17043";
+ reg = <0x36>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <144 IRQ_TYPE_EDGE_FALLING>;
+
+ monitored-battery = <&battery>;
+ power-supplies = <&charger>;
+
+ io-channels = <&adc 8>;
+ io-channel-names = "temp";
+
+ maxim,alert-low-soc-level = <10>;
+ wakeup-source;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml
index aff5d0792e0f..14242de7fc08 100644
--- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml
@@ -19,6 +19,7 @@ properties:
- maxim,max17047
- maxim,max17050
- maxim,max17055
+ - maxim,max77705-battery
- maxim,max77849-battery
reg:
@@ -59,6 +60,8 @@ properties:
Voltage threshold to report battery as over voltage (in mV).
Default is not to report over-voltage events.
+ power-supplies: true
+
required:
- compatible
- reg
@@ -67,7 +70,7 @@ additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17201.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17201.yaml
new file mode 100644
index 000000000000..fe3dd9bd5585
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max17201.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/maxim,max17201.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX17201 fuel gauge
+
+maintainers:
+ - Dimitri Fedrau <dima.fedrau@gmail.com>
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: maxim,max17201
+ - items:
+ - enum:
+ - maxim,max17205
+ - const: maxim,max17201
+
+ reg:
+ items:
+ - description: ModelGauge m5 registers
+ - description: Nonvolatile registers
+
+ reg-names:
+ items:
+ - const: m5
+ - const: nvmem
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fuel-gauge@36 {
+ compatible = "maxim,max17201";
+ reg = <0x36>, <0xb>;
+ reg-names = "m5", "nvmem";
+ interrupt-parent = <&gpio0>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml
new file mode 100644
index 000000000000..e3b84068993b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/maxim,max77705.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX777705 charger
+
+maintainers:
+ - Dzmitry Sankouski <dsankouski@gmail.com>
+
+description: |
+ This is a device tree bindings for charger found in Maxim MAX77705 chip.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: maxim,max77705-charger
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - monitored-battery
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@69 {
+ compatible = "maxim,max77705-charger";
+ reg = <0x69>;
+ monitored-battery = <&battery>;
+ interrupt-parent = <&pm8998_gpios>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml
index a8d625f285f1..86af38378999 100644
--- a/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max8903.yaml
@@ -34,7 +34,7 @@ properties:
flt-gpios:
maxItems: 1
- description: Fault pin (active low, output)
+ description: Fault pin (active low, input)
dcm-gpios:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml
new file mode 100644
index 000000000000..2244cc3d45a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/maxim,max8971.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX8971 IC charger
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ The MAX8971 is a compact, high-frequency, high-efficiency switch-mode charger
+ for a one-cell lithium-ion (Li+) battery.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: maxim,max8971
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ monitored-battery: true
+
+ port:
+ description:
+ An optional port node to link the extcon device to detect type of plug.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@35 {
+ compatible = "maxim,max8971";
+ reg = <0x35>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <74 IRQ_TYPE_LEVEL_LOW>;
+
+ monitored-battery = <&battery>;
+
+ port {
+ charger_input: endpoint {
+ remote-endpoint = <&extcon_output>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
new file mode 100644
index 000000000000..fd491c598a00
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/mediatek,mt6370-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6370 Battery Charger
+
+maintainers:
+ - ChiaEn Wu <chiaen_wu@richtek.com>
+
+description: |
+ This module is part of the MT6370 MFD device.
+ Provides Battery Charger, Boost for OTG devices and BC1.2 detection.
+
+properties:
+ compatible:
+ const: mediatek,mt6370-charger
+
+ interrupts:
+ description: |
+ Specify what irqs are needed to be handled by MT6370 Charger driver.
+ We need to use the IRQ "MT6370_IRQ_OVPCTRL_UVP_D" to know when USB
+ is plugged in, and then the driver will enable BC1.2 detection.
+ After the hardware of MT6370 completes the BC1.2 detection,
+ IRQ "MT6370_IRQ_ATTACH" will be triggered, and the driver will know
+ the result of BC1.2 detection.
+ When the IRQ "MT6370_IRQ_CHG_MIVR" is triggered, it means that the
+ hardware enters the "Minimum Input Voltage Regulation loop" and
+ a workaround needs to be applied at this time.
+ In summary, "MT6370_IRQ_OVPCTRL_UVP_D", "MT6370_IRQ_ATTACH" and
+ "MT6370_IRQ_CHG_MIVR" are required in this charger driver.
+ items:
+ - description: irq of "USB is plugged in"
+ - description: irq of "BC1.2 is done"
+ - description: irq of "Minimum Input Voltage Regulation loop is active"
+
+ interrupt-names:
+ items:
+ - const: uvp_d_evt
+ - const: attach_i
+ - const: mivr
+
+ io-channels:
+ description: |
+ Use ADC channel to read VBUS, IBUS, IBAT, etc., info.
+ minItems: 1
+ items:
+ - description: |
+ VBUS voltage with lower accuracy (+-75mV) but higher measure
+ range (1~22V)
+ - description: |
+ VBUS voltage with higher accuracy (+-30mV) but lower measure
+ range (1~9.76V)
+ - description: the main system input voltage
+ - description: battery voltage
+ - description: battery temperature-sense input voltage
+ - description: IBUS current (required)
+ - description: battery current
+ - description: |
+ regulated output voltage to supply for the PWM low-side gate driver
+ and the bootstrap capacitor
+ - description: IC junction temperature
+
+ io-channel-names:
+ minItems: 1
+ items:
+ - const: vbusdiv5
+ - const: vbusdiv2
+ - const: vsys
+ - const: vbat
+ - const: ts_bat
+ - const: ibus
+ - const: ibat
+ - const: chg_vddp
+ - const: temp_jc
+
+ usb-otg-vbus-regulator:
+ type: object
+ description: OTG boost regulator.
+ unevaluatedProperties: false
+ $ref: /schemas/regulator/regulator.yaml#
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+ - interrupt-names
+ - io-channels
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/power/supply/mitsumi,mm8013.yaml b/Documentation/devicetree/bindings/power/supply/mitsumi,mm8013.yaml
new file mode 100644
index 000000000000..6865640cbdfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/mitsumi,mm8013.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/mitsumi,mm8013.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mitsumi MM8013 fuel gauge
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: mitsumi,mm8013
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fuel-gauge@55 {
+ compatible = "mitsumi,mm8013";
+ reg = <0x55>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
index b89b15a5bfa4..3e8689019251 100644
--- a/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
@@ -21,11 +21,11 @@ properties:
description: Maximum CHGIN regulation voltage in uV.
enum: [ 5500000, 6500000, 11000000, 14500000 ]
-
usb-otg-vbus-regulator:
type: object
description: OTG boost regulator.
$ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
@@ -39,7 +39,6 @@ examples:
richtek,vinovp-microvolt = <14500000>;
otg_vbus_regulator: usb-otg-vbus-regulator {
- regulator-compatible = "usb-otg-vbus";
regulator-name = "usb-otg-vbus";
regulator-min-microvolt = <4425000>;
regulator-max-microvolt = <5825000>;
diff --git a/Documentation/devicetree/bindings/power/supply/pegatron,chagall-ec.yaml b/Documentation/devicetree/bindings/power/supply/pegatron,chagall-ec.yaml
new file mode 100644
index 000000000000..defb0861e268
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/pegatron,chagall-ec.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/pegatron,chagall-ec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Pegatron Chagall EC
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ Pegatron Chagall EC is based on an 8-bit programmable microcontroller from
+ Infineon/Cypress Semiconductor, it communicates over I2C and is used in the
+ Pegatron Chagall tablet for fuel gauge and battery control functions.
+
+$ref: /schemas/power/supply/power-supply.yaml
+
+properties:
+ compatible:
+ const: pegatron,chagall-ec
+
+ reg:
+ maxItems: 1
+
+ monitored-battery: true
+ power-supplies: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@10 {
+ compatible = "pegatron,chagall-ec";
+ reg = <0x10>;
+
+ monitored-battery = <&battery>;
+ power-supplies = <&mains>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml b/Documentation/devicetree/bindings/power/supply/power-supply.yaml
index 2f672e6e8d72..4e54c937973e 100644
--- a/Documentation/devicetree/bindings/power/supply/power-supply.yaml
+++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml
@@ -18,4 +18,10 @@ properties:
This property is added to a supply in order to list the devices which
supply it power, referenced by their phandles.
+ monitored-battery:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The battery (with "simple-battery" compatible) being monitored by this
+ power supply.
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8916-bms-vm.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8916-bms-vm.yaml
new file mode 100644
index 000000000000..ad764e69ab57
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8916-bms-vm.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/qcom,pm8916-bms-vm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Voltage Mode BMS
+
+maintainers:
+ - Nikita Travkin <nikita@trvn.ru>
+
+description:
+ Voltage Mode BMS is a hardware block found in some Qualcomm PMICs
+ such as pm8916. This block performs battery voltage monitoring.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: qcom,pm8916-bms-vm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: BMS FSM left S3 mode
+ - description: BMS FSM entered S2 mode
+ - description: OCV measured in S3 mode
+ - description: OCV below threshold
+ - description: FIFO update done
+ - description: BMS FSM switched state
+
+ interrupt-names:
+ items:
+ - const: cv_leave
+ - const: cv_enter
+ - const: ocv_good
+ - const: ocv_thr
+ - const: fifo
+ - const: state_chg
+
+ monitored-battery: true
+
+ power-supplies: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - monitored-battery
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ battery@4000 {
+ compatible = "qcom,pm8916-bms-vm";
+ reg = <0x4000>;
+ interrupts = <0x0 0x40 0 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x40 1 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x40 2 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x40 3 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x40 4 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x40 5 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "cv_leave",
+ "cv_enter",
+ "ocv_good",
+ "ocv_thr",
+ "fifo",
+ "state_chg";
+
+ monitored-battery = <&battery>;
+ power-supplies = <&pm8916_charger>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8916-lbc.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8916-lbc.yaml
new file mode 100644
index 000000000000..cdf14e5ed119
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8916-lbc.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/qcom,pm8916-lbc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Linear Battery Charger
+
+maintainers:
+ - Nikita Travkin <nikita@trvn.ru>
+
+description:
+ Linear Battery Charger hardware block, found in some Qualcomm PMICs
+ such as pm8916. Implements a simple, autonomous CC/CV charger.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: qcom,pm8916-lbc
+
+ reg:
+ items:
+ - description: Charger
+ - description: Battery
+ - description: USB
+ - description: MISC
+
+ reg-names:
+ items:
+ - const: chgr
+ - const: bat_if
+ - const: usb
+ - const: misc
+
+ interrupts:
+ items:
+ - description: Battery detection
+ - description: Fast charging
+ - description: Charging failed
+ - description: Charging done
+ - description: Battery present
+ - description: Battery temperature OK
+ - description: USB coarse detection
+ - description: USB IN valid
+ - description: Charger gone
+ - description: Overtemperature
+
+ interrupt-names:
+ items:
+ - const: vbat_det
+ - const: fast_chg
+ - const: chg_fail
+ - const: chg_done
+ - const: bat_pres
+ - const: temp_ok
+ - const: coarse_det
+ - const: usb_vbus
+ - const: chg_gone
+ - const: overtemp
+
+ qcom,fast-charge-safe-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 4000000
+ maximum: 4775000
+ description:
+ Maximum safe battery voltage in uV; May be pre-set by bootloader,
+ in which case, setting this will harmlessly fail.
+
+ qcom,fast-charge-safe-current:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 90000
+ maximum: 1440000
+ description:
+ Maximum safe battery charge current in uA; May be pre-set by
+ bootloader, in which case setting this will harmlessly fail.
+
+ monitored-battery: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - qcom,fast-charge-safe-voltage
+ - qcom,fast-charge-safe-current
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@1000 {
+ compatible = "qcom,pm8916-lbc";
+ reg = <0x1000>, <0x1200>, <0x1300>, <0x1600>;
+ reg-names = "chgr", "bat_if", "usb", "misc";
+
+ interrupts = <0x0 0x10 0 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x10 5 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x10 6 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x10 7 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x12 0 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x12 1 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x13 0 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x13 1 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x13 2 IRQ_TYPE_EDGE_BOTH>,
+ <0x0 0x13 4 IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "vbat_det",
+ "fast_chg",
+ "chg_fail",
+ "chg_done",
+ "bat_pres",
+ "temp_ok",
+ "coarse_det",
+ "usb_vbus",
+ "chg_gone",
+ "overtemp";
+ monitored-battery = <&battery>;
+
+ qcom,fast-charge-safe-current = <900000>;
+ qcom,fast-charge-safe-voltage = <4300000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml
index 0450f4dd4e51..1d2405bea109 100644
--- a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml
+++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-coincell.yaml
@@ -16,18 +16,30 @@ maintainers:
properties:
compatible:
- const: qcom,pm8941-coincell
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm8998-coincell
+ - const: qcom,pm8941-coincell
+
+ - const: qcom,pm8941-coincell
reg:
maxItems: 1
qcom,rset-ohms:
- description: resistance (in ohms) for current-limiting resistor
+ description: |
+ Resistance (in ohms) for current-limiting resistor. If unspecified,
+ inherit the previous configuration (e.g. from bootloader or hardware
+ default value).
enum: [ 800, 1200, 1700, 2100 ]
qcom,vset-millivolts:
$ref: /schemas/types.yaml#/definitions/uint32
- description: voltage (in millivolts) to apply for charging
+ description: |
+ Voltage (in millivolts) to apply for charging. If unspecified, inherit
+ the previous configuration (e.g. from bootloader or hardware default
+ value).
enum: [ 2500, 3000, 3100, 3200 ]
qcom,charger-disable:
@@ -37,8 +49,6 @@ properties:
required:
- compatible
- reg
- - qcom,rset-ohms
- - qcom,vset-millivolts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml
new file mode 100644
index 000000000000..70f5cd6eaeab
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/qcom,pmi8998-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PMI8998/PM660 Switch-Mode Battery Charger "2"
+
+maintainers:
+ - Casey Connolly <casey.connolly@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,pmi8998-charger
+ - qcom,pm660-charger
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 4
+
+ interrupt-names:
+ items:
+ - const: usb-plugin
+ - const: bat-ov
+ - const: wdog-bark
+ - const: usbin-icl-change
+
+ io-channels:
+ items:
+ - description: USB in current in uA
+ - description: USB in voltage in uV
+
+ io-channel-names:
+ items:
+ - const: usbin_i
+ - const: usbin_v
+
+ monitored-battery: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - io-channels
+ - io-channel-names
+ - monitored-battery
+
+allOf:
+ - $ref: power-supply.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@1000 {
+ compatible = "qcom,pmi8998-charger";
+ reg = <0x1000>;
+
+ interrupts = <0x2 0x12 0x2 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x13 0x4 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x13 0x6 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x16 0x1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "usb-plugin", "bat-ov", "wdog-bark", "usbin-icl-change";
+
+ io-channels = <&pmi8998_rradc 3>,
+ <&pmi8998_rradc 4>;
+ io-channel-names = "usbin_i",
+ "usbin_v";
+
+ monitored-battery = <&battery>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml
index 756c16d1727d..b5d8888d03d2 100644
--- a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml
@@ -26,7 +26,7 @@ required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
new file mode 100644
index 000000000000..d91eced9f5fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-charger.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt5033-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5033 PMIC Battery Charger
+
+maintainers:
+ - Jakob Hauser <jahau@rocketmail.com>
+
+description:
+ The battery charger of the multifunction device RT5033 has to be instantiated
+ under sub-node named "charger" using the following format.
+
+properties:
+ compatible:
+ const: richtek,rt5033-charger
+
+ monitored-battery:
+ description: |
+ Phandle to the monitored battery according to battery.yaml. The battery
+ node needs to contain five parameters.
+
+ precharge-current-microamp:
+ Current of pre-charge mode. The pre-charge current levels are 350 mA
+ to 650 mA programmed by I2C per 100 mA.
+
+ constant-charge-current-max-microamp:
+ Current of fast-charge mode. The fast-charge current levels are 700 mA
+ to 2000 mA programmed by I2C per 100 mA.
+
+ charge-term-current-microamp:
+ This property is end of charge current. Its level ranges from 150 mA
+ to 600 mA. Between 150 mA and 300 mA in 50 mA steps, between 300 mA and
+ 600 mA in 100 mA steps.
+
+ precharge-upper-limit-microvolt:
+ Voltage of pre-charge mode. If the battery voltage is below the pre-charge
+ threshold voltage, the charger is in pre-charge mode with pre-charge
+ current. Its levels are 2.3 V to 3.8 V programmed by I2C per 0.1 V.
+
+ constant-charge-voltage-max-microvolt:
+ Battery regulation voltage of constant voltage mode. This voltage levels
+ from 3.65 V to 4.4 V by I2C per 0.025 V.
+
+ richtek,usb-connector:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to a USB connector according to usb-connector.yaml. The connector
+ should be a child of the extcon device.
+
+required:
+ - monitored-battery
+
+allOf:
+ - $ref: power-supply.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ charger {
+ compatible = "richtek,rt5033-charger";
+ monitored-battery = <&battery>;
+ richtek,usb-connector = <&usb_con>;
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml
index bce15101318e..89f9603499b4 100644
--- a/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/richtek,rt9455.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for Richtek rt9455 battery charger
+title: Richtek rt9455 battery charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -68,7 +68,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -79,10 +79,10 @@ examples:
interrupt-parent = <&gpio1>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- richtek,output-charge-current = <500000>;
- richtek,end-of-charge-percentage = <10>;
- richtek,battery-regulation-voltage = <4200000>;
- richtek,boost-output-voltage = <5050000>;
+ richtek,output-charge-current = <500000>;
+ richtek,end-of-charge-percentage = <10>;
+ richtek,battery-regulation-voltage = <4200000>;
+ richtek,boost-output-voltage = <5050000>;
richtek,min-input-voltage-regulation = <4500000>;
richtek,avg-input-current-regulation = <500000>;
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml
new file mode 100644
index 000000000000..3723717dc1f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9467.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt9467.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9467 Switching Battery Charger with Power Path Management
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+ - ChiaEn Wu <chiaen_wu@richtek.com>
+
+description: |
+ RT9467 is a switch-mode single cell Li-Ion/Li-Polymer battery charger for
+ portable applications. It integrates a synchronous PWM controller, power
+ MOSFETs, input current sensing and regulation, high-accuracy voltage
+ regulation, and charge termination. The charge current is regulated through
+ integrated sensing resistors.
+
+ The RT9467 also features USB On-The-Go (OTG) support. It also integrates
+ D+/D- pin for USB host/charging port detection.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT9467/DS9467-01.pdf
+
+properties:
+ compatible:
+ const: richtek,rt9467
+
+ reg:
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ charge-enable-gpios:
+ description: GPIO is used to turn on and off charging.
+ maxItems: 1
+
+ usb-otg-vbus-regulator:
+ type: object
+ description: OTG boost regulator.
+ unevaluatedProperties: false
+ $ref: /schemas/regulator/regulator.yaml#
+
+ properties:
+ enable-gpios: true
+
+required:
+ - compatible
+ - reg
+ - wakeup-source
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@5b {
+ compatible = "richtek,rt9467";
+ reg = <0x5b>;
+ wakeup-source;
+ interrupts-extended = <&gpio_intc 32 IRQ_TYPE_LEVEL_LOW>;
+ charge-enable-gpios = <&gpio26 1 GPIO_ACTIVE_LOW>;
+
+ rt9467_otg_vbus: usb-otg-vbus-regulator {
+ regulator-name = "rt9467-usb-otg-vbus";
+ regulator-min-microvolt = <4425000>;
+ regulator-max-microvolt = <5825000>;
+ regulator-min-microamp = <500000>;
+ regulator-max-microamp = <3000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml
new file mode 100644
index 000000000000..fbb54cfeca08
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9471.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt9471.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9471 3A Single Cell Switching Battery charger
+
+maintainers:
+ - Alina Yu <alina_yu@richtek.com>
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ RT9471 is a switch-mode single cell Li-Ion/Li-Polymer battery charger for
+ portable applications. It supports USB BC1.2 port detection, current and
+ voltage regulations in both charging and boost mode.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT9471=RT9471D/DS9471D-02.pdf
+
+properties:
+ compatible:
+ const: richtek,rt9471
+
+ reg:
+ maxItems: 1
+
+ charge-enable-gpios:
+ description: GPIO used to turn on and off charging.
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ usb-otg-vbus-regulator:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - wakeup-source
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@53 {
+ compatible = "richtek,rt9471";
+ reg = <0x53>;
+ charge-enable-gpios = <&gpio26 1 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ interrupts-extended = <&gpio_intc 32 IRQ_TYPE_EDGE_FALLING>;
+
+ usb-otg-vbus-regulator {
+ regulator-name = "usb-otg-vbus";
+ regulator-min-microvolt = <4850000>;
+ regulator-max-microvolt = <5300000>;
+ regulator-min-microamp = <500000>;
+ regulator-max-microamp = <1200000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9756.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9756.yaml
new file mode 100644
index 000000000000..a88bf6cd1927
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9756.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/richtek,rt9756.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9756 Smart Cap Divider Charger
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ The RT9756/RT9757 is a high efficiency and high charge current charger.
+
+ The efficiency is up to 98.2% when VBAT = 4V, IBAT = 2A in DIV2 mode and 99.1%
+ when VBAT=4V, IBAT=1A in bypass mode. The maximum charger current is up to 8A
+ in DIV2 mode and 5A in bypass mode. The device integrates smart cap divider
+ topology, direct charging mode, external over-voltage protection control, an
+ input reverse blocking NFET and 2-way regulation, a dual phase charge pump
+ core, 8-Channel high speed ADCs and USB BC 1.2 detection.
+
+ RT9770 is almost the same with RT9756/57, only BC 1.2 detection function is
+ removed to shrink the die size.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - richtek,rt9756
+ - richtek,rt9770
+ - items:
+ - enum:
+ - richtek,rt9757
+ - const: richtek,rt9756
+
+ reg:
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ shunt-resistor-micro-ohms:
+ description: Battery current sense resistor mounted.
+ default: 2000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@6f {
+ compatible = "richtek,rt9756";
+ reg = <0x6f>;
+ wakeup-source;
+ interrupts-extended = <&gpio_intc 32 IRQ_TYPE_EDGE_FALLING>;
+ shunt-resistor-micro-ohms = <5000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
index 24b06957b4ca..b2c229ed2423 100644
--- a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
+++ b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD99954 Battery charger
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
- Markus Laine <markus.laine@fi.rohmeurope.com>
- Mikko Mutanen <mikko.mutanen@fi.rohmeurope.com>
@@ -18,6 +18,7 @@ description: |
provides a Dual-source Battery Charger, two port BC1.2 detection and a
Battery Monitor.
+$ref: power-supply.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml
index 99f506d6b0a0..2e21846463ba 100644
--- a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml
+++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/sbs,sbs-manager.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SBS compliant manger
+title: SBS compliant manager
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -47,6 +47,12 @@ patternProperties:
"^i2c@[1-4]$":
type: object
$ref: /schemas/i2c/i2c-controller.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 1
+ maximum: 4
examples:
- |
diff --git a/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml b/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml
index eeb043f9bb4f..f5aa72502b4e 100644
--- a/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/sc2731-charger.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/sc2731-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Spreadtrum SC2731 PMICs battery charger binding
+title: Spreadtrum SC2731 PMICs battery charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -28,26 +28,6 @@ properties:
The charger uses the following battery properties
- charge-term-current-microamp: current for charge termination phase.
- constant-charge-voltage-max-microvolt: maximum constant input voltage.
- See Documentation/devicetree/bindings/power/supply/battery.yaml
additionalProperties: false
-
-examples:
- - |
- bat: battery {
- compatible = "simple-battery";
- charge-term-current-microamp = <120000>;
- constant-charge-voltage-max-microvolt = <4350000>;
- };
-
- pmic {
- #address-cells = <1>;
- #size-cells = <0>;
-
- battery@a00 {
- compatible = "sprd,sc2731-charger";
- reg = <0x0>;
- phys = <&ssphy>;
- monitored-battery = <&bat>;
- };
- };
+...
diff --git a/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml
index d90a838a1744..c1de2c80291d 100644
--- a/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml
+++ b/Documentation/devicetree/bindings/power/supply/sc27xx-fg.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/sc27xx-fg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Spreadtrum SC27XX PMICs Fuel Gauge Unit Power Supply Bindings
+title: Spreadtrum SC27XX PMICs Fuel Gauge Unit Power Supply
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -27,6 +27,14 @@ properties:
battery-detect-gpios:
maxItems: 1
+ bat-detect-gpio:
+ maxItems: 1
+ deprecated: true
+ description: use battery-detect-gpios instead
+
+ interrupts:
+ maxItems: 1
+
io-channels:
items:
- description: Battery Temperature ADC
@@ -53,6 +61,7 @@ required:
- compatible
- reg
- battery-detect-gpios
+ - interrupts
- io-channels
- io-channel-names
- nvmem-cells
@@ -61,38 +70,4 @@ required:
- monitored-battery
additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- bat: battery {
- compatible = "simple-battery";
- charge-full-design-microamp-hours = <1900000>;
- constant-charge-voltage-max-microvolt = <4350000>;
- ocv-capacity-celsius = <20>;
- ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>,
- <4022000 85>, <3983000 80>, <3949000 75>,
- <3917000 70>, <3889000 65>, <3864000 60>,
- <3835000 55>, <3805000 50>, <3787000 45>,
- <3777000 40>, <3773000 35>, <3770000 30>,
- <3765000 25>, <3752000 20>, <3724000 15>,
- <3680000 10>, <3605000 5>, <3400000 0>;
- // ...
- };
-
- pmic {
- #address-cells = <1>;
- #size-cells = <0>;
-
- battery@a00 {
- compatible = "sprd,sc2731-fgu";
- reg = <0xa00>;
- battery-detect-gpios = <&pmic_eic 9 GPIO_ACTIVE_HIGH>;
- io-channels = <&pmic_adc 5>, <&pmic_adc 14>;
- io-channel-names = "bat-temp", "charge-vol";
- nvmem-cells = <&fgu_calib>;
- nvmem-cell-names = "fgu_calib";
- monitored-battery = <&bat>;
- sprd,calib-resistance-micro-ohms = <21500>;
- };
- };
+...
diff --git a/Documentation/devicetree/bindings/power/supply/st,stc3117.yaml b/Documentation/devicetree/bindings/power/supply/st,stc3117.yaml
new file mode 100644
index 000000000000..e486131a27a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/st,stc3117.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/st,stc3117.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STC3117 Fuel Gauge Unit Power Supply
+
+maintainers:
+ - Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io>
+ - Bhavin Sharma <bhavin.sharma@siliconsignals.io>
+
+description: |
+ The STC3117 includes the STMicroelectronics OptimGauge algorithm.
+ It provides accurate battery state-of-charge (SOC) monitoring, tracks
+ battery parameter changes with operation conditions, temperature,
+ and aging, and allows the application to get a battery state-of-health
+ (SOH) indication.
+
+ An alarm output signals low SOC or low voltage conditions and also
+ indicates fault conditions like a missing or swapped battery.
+
+ Datasheet is available at
+ https://www.st.com/resource/en/datasheet/stc3117.pdf
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ enum:
+ - st,stc3117
+
+ reg:
+ maxItems: 1
+
+ monitored-battery:
+ description: |
+ The fuel gauge uses the following battery properties:
+ - charge-full-design-microamp-hours
+ - voltage-min-design-microvolt
+ - voltage-max-design-microvolt
+
+ shunt-resistor-micro-ohms:
+ description: Current sense resistor
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - monitored-battery
+ - shunt-resistor-micro-ohms
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ battery@70 {
+ compatible = "st,stc3117";
+ reg = <0x70>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ monitored-battery = <&bat>;
+ shunt-resistor-micro-ohms = <10000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-battery.txt b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-battery.txt
deleted file mode 100644
index ee125cb0e46d..000000000000
--- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-battery.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-AB85000 PMIC contains a node, which contains shared
-information about the battery connected to the PMIC.
-The node has no compatible property.
-
-Properties of this node are:
-
-thermistor-on-batctrl:
- A boolean value indicating thermistor interface to battery
-
- Note:
- 'btemp' and 'batctrl' are the pins interfaced for battery temperature
- measurement, 'btemp' signal is used when NTC(negative temperature
- coefficient) resister is interfaced external to battery whereas
- 'batctrl' pin is used when NTC resister is internal to battery.
-
- Example:
- ab8500_battery: ab8500_battery {
- thermistor-on-batctrl;
- };
- indicates: NTC resister is internal to battery, 'batctrl' is used
- for thermal measurement.
-
- The absence of property 'thermal-on-batctrl' indicates
- NTC resister is external to battery and 'btemp' signal is used
- for thermal measurement.
-
-battery-type:
- This shall be the battery manufacturing technology type,
- allowed types are:
- "UNKNOWN" "NiMH" "LION" "LIPO" "LiFe" "NiCd" "LiMn"
- Example:
- ab8500_battery: ab8500_battery {
- stericsson,battery-type = "LIPO";
- }
diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml
index 525abdfb3e2d..c464aa82255a 100644
--- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml
+++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-btemp.yaml
@@ -17,9 +17,7 @@ properties:
compatible:
const: stericsson,ab8500-btemp
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to battery node
+ monitored-battery: true
battery:
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml
index 10bbdcfc87b6..39914b9e0cf5 100644
--- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml
+++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-chargalg.yaml
@@ -17,9 +17,7 @@ properties:
compatible:
const: stericsson,ab8500-chargalg
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to battery node
+ monitored-battery: true
battery:
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml
index e33329b3af61..4f19744844e9 100644
--- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-charger.yaml
@@ -17,9 +17,7 @@ properties:
compatible:
const: stericsson,ab8500-charger
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to battery node
+ monitored-battery: true
battery:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -67,7 +65,6 @@ properties:
- const: vbus_v
- const: usb_charger_c
-
required:
- compatible
- monitored-battery
diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml
index 6a724ca90e99..92e4eb08fd61 100644
--- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml
+++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml
@@ -17,9 +17,7 @@ properties:
compatible:
const: stericsson,ab8500-fg
- monitored-battery:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to battery node
+ monitored-battery: true
battery:
$ref: /schemas/types.yaml#/definitions/phandle
diff --git a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml
index 2d552becbfe6..65ed92bb05f3 100644
--- a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml
+++ b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml
@@ -23,9 +23,7 @@ properties:
interrupts:
maxItems: 1
- monitored-battery:
- description: phandle to the battery node
- $ref: /schemas/types.yaml#/definitions/phandle
+ monitored-battery: true
summit,enable-usb-charging:
type: boolean
@@ -94,6 +92,7 @@ properties:
unevaluatedProperties: false
allOf:
+ - $ref: power-supply.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml
index 93654e732cda..069422a8c90c 100644
--- a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml
+++ b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/power/supply/ti,lp8727.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for TI/National Semiconductor LP8727 Charger
+title: TI/National Semiconductor LP8727 Charger
maintainers:
- Sebastian Reichel <sre@kernel.org>
@@ -28,6 +28,7 @@ properties:
patternProperties:
'^(ac|usb)$':
type: object
+ additionalProperties: false
description: USB/AC charging parameters
properties:
charger-type:
@@ -61,7 +62,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/power/supply/ti,twl6030-charger.yaml b/Documentation/devicetree/bindings/power/supply/ti,twl6030-charger.yaml
new file mode 100644
index 000000000000..fc604d8a469d
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/ti,twl6030-charger.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/ti,twl6030-charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TWL6030/32 BCI (Battery Charger Interface)
+
+description:
+ The battery charger needs to be configured to do any charging besides of
+ precharging. The GPADC in the PMIC has to be used to get the related
+ voltages.
+
+maintainers:
+ - Andreas Kemnade <andreas@kemnade.info>
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: ti,twl6030-charger
+ - items:
+ - const: ti,twl6032-charger
+ - const: ti,twl6030-charger
+
+ interrupts:
+ items:
+ - description: Charger Control Interrupt
+ - description: Charger Fault Interrupt
+
+ io-channels:
+ items:
+ - description: VBUS Voltage Channel
+
+ io-channel-names:
+ items:
+ - const: vusb
+
+ monitored-battery: true
+
+required:
+ - compatible
+ - interrupts
+ - monitored-battery
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml
index e0b95ecbbebd..a90d558e7f86 100644
--- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml
+++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml
@@ -14,21 +14,38 @@ maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Sebastian Reichel <sre@kernel.org>
-allOf:
- - $ref: power-supply.yaml#
-
properties:
compatible:
oneOf:
- const: x-powers,axp202-battery-power-supply
- const: x-powers,axp209-battery-power-supply
- const: x-powers,axp221-battery-power-supply
+ - const: x-powers,axp717-battery-power-supply
- items:
- const: x-powers,axp803-battery-power-supply
- const: x-powers,axp813-battery-power-supply
- const: x-powers,axp813-battery-power-supply
+ monitored-battery: true
+
+ x-powers,no-thermistor:
+ type: boolean
+ description: Indicates that no thermistor is connected to the TS pin
+
required:
- compatible
+allOf:
+ - $ref: power-supply.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp717-battery-power-supply
+ then:
+ properties:
+ x-powers,no-thermistor: false
+
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml
index 3ce648dd91bd..2ec036405ae4 100644
--- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml
+++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml
@@ -15,23 +15,90 @@ maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Sebastian Reichel <sre@kernel.org>
-allOf:
- - $ref: power-supply.yaml#
-
properties:
compatible:
oneOf:
- enum:
+ - x-powers,axp192-usb-power-supply
- x-powers,axp202-usb-power-supply
- x-powers,axp221-usb-power-supply
- x-powers,axp223-usb-power-supply
+ - x-powers,axp717-usb-power-supply
- x-powers,axp813-usb-power-supply
- items:
- const: x-powers,axp803-usb-power-supply
- const: x-powers,axp813-usb-power-supply
+ input-current-limit-microamp:
+ description:
+ Optional value to clamp the maximum input current limit to for
+ the device. If omitted, the programmed value from the EFUSE will
+ be used.
+ minimum: 100000
+ maximum: 4000000
required:
- compatible
+allOf:
+ - $ref: power-supply.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp192-usb-power-supply
+ then:
+ properties:
+ input-current-limit-microamp:
+ enum: [100000, 500000]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp202-usb-power-supply
+ - x-powers,axp223-usb-power-supply
+ then:
+ properties:
+ input-current-limit-microamp:
+ enum: [100000, 500000, 900000]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp221-usb-power-supply
+ then:
+ properties:
+ input-current-limit-microamp:
+ enum: [500000, 900000]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp717-usb-power-supply
+ then:
+ properties:
+ input-current-limit-microamp:
+ description: Maximum input current in increments of 50000 uA.
+ minimum: 100000
+ maximum: 3250000
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - x-powers,axp813-usb-power-supply
+ then:
+ properties:
+ input-current-limit-microamp:
+ enum: [100000, 500000, 900000, 1500000, 2000000, 2500000,
+ 3000000, 3500000, 4000000]
+
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt
index cfd74659fbed..66bb016305f9 100644
--- a/Documentation/devicetree/bindings/power/wakeup-source.txt
+++ b/Documentation/devicetree/bindings/power/wakeup-source.txt
@@ -3,29 +3,32 @@ Specifying wakeup capability for devices
Any device nodes
----------------
-Nodes that describe devices which has wakeup capability must contain an
+Nodes that describe devices which have wakeup capability may contain a
"wakeup-source" boolean property.
-Also, if device is marked as a wakeup source, then all the primary
-interrupt(s) can be used as wakeup interrupt(s).
+If the device is marked as a wakeup-source, interrupt wake capability depends
+on the device specific "interrupt-names" property. If no interrupts are labeled
+as wake capable, then it is up to the device to determine which interrupts can
+wake the system.
-However if the devices have dedicated interrupt as the wakeup source
-then they need to specify/identify the same using device specific
-interrupt name. In such cases only that interrupt can be used as wakeup
-interrupt.
+However if a device has a dedicated interrupt as the wakeup source, then it
+needs to specify/identify it using a device specific interrupt name. In such
+cases only that interrupt can be used as a wakeup interrupt.
+
+While various legacy interrupt names exist, new devices should use "wakeup" as
+the canonical interrupt name.
List of legacy properties and respective binding document
---------------------------------------------------------
-1. "enable-sdio-wakeup" Documentation/devicetree/bindings/mmc/mmc.txt
-2. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt
-3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt
-4. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
+1. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt
+2. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt
+3. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml
Documentation/devicetree/bindings/mfd/tc3589x.txt
- Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
-5. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
-6. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt
-7. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
+ Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml
+4. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml
+5. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung,s3c6410-keypad.yaml
+6. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
Examples
--------
diff --git a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt b/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
deleted file mode 100644
index 54b9f9d0f90f..000000000000
--- a/Documentation/devicetree/bindings/power/xlnx,zynqmp-genpd.txt
+++ /dev/null
@@ -1,34 +0,0 @@
------------------------------------------------------------
-Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
------------------------------------------------------------
-The binding for zynqmp-power-controller follow the common
-generic PM domain binding[1].
-
-[1] Documentation/devicetree/bindings/power/power-domain.yaml
-
-== Zynq MPSoC Generic PM Domain Node ==
-
-Required property:
- - Below property should be in zynqmp-firmware node.
- - #power-domain-cells: Number of cells in a PM domain specifier. Must be 1.
-
-Power domain ID indexes are mentioned in
-include/dt-bindings/power/xlnx-zynqmp-power.h.
-
--------
-Example
--------
-
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- ...
- #power-domain-cells = <1>;
- ...
- };
-};
-
-sata {
- ...
- power-domains = <&zynqmp_firmware 28>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
index 801c66069121..4787db8de23f 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -28,6 +28,6 @@ PROPERTIES
Snoop ID Port Mapping registers, which are part of the CoreNet
Coherency fabric (CCF), provide a CoreNet Coherency Subdomain
ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from
- these registers should be set if the coresponding CPU should be
+ these registers should be set if the corresponding CPU should be
snooped. This property defines a bitmask which selects the bit
that should be set if this cpu should be snooped.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
index 4b01e1afafda..62744afb5b75 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
@@ -185,10 +185,10 @@ PROPERTIES
with distinct functionality.
The first register range describes the CoreNet Debug Controller
- functionalty to perform transaction and transaction attribute matches.
+ functionality to perform transaction and transaction attribute matches.
The second register range describes the CoreNet Debug Controller
- functionalty to trigger event notifications and debug traces.
+ functionality to trigger event notifications and debug traces.
EXAMPLE
dcsr-corenet {
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
deleted file mode 100644
index c11ad5c6db21..000000000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ /dev/null
@@ -1,204 +0,0 @@
-* Freescale DMA Controllers
-
-** Freescale Elo DMA Controller
- This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
- series chips such as mpc8315, mpc8349, mpc8379 etc.
-
-Required properties:
-
-- compatible : must include "fsl,elo-dma"
-- reg : DMA General Status Register, i.e. DGSR which contains
- status for all the 4 DMA channels
-- ranges : describes the mapping between the address space of the
- DMA channels and the address space of the DMA controller
-- cell-index : controller index. 0 for controller @ 0x8100
-- interrupts : interrupt specifier for DMA IRQ
-
-- DMA channel nodes:
- - compatible : must include "fsl,elo-dma-channel"
- However, see note below.
- - reg : DMA channel specific registers
- - cell-index : DMA channel index starts at 0.
-
-Optional properties:
- - interrupts : interrupt specifier for DMA channel IRQ
- (on 83xx this is expected to be identical to
- the interrupts property of the parent node)
-
-Example:
- dma@82a8 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
- reg = <0x82a8 4>;
- ranges = <0 0x8100 0x1a4>;
- interrupt-parent = <&ipic>;
- interrupts = <71 8>;
- cell-index = <0>;
- dma-channel@0 {
- compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
- cell-index = <0>;
- reg = <0 0x80>;
- interrupt-parent = <&ipic>;
- interrupts = <71 8>;
- };
- dma-channel@80 {
- compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
- cell-index = <1>;
- reg = <0x80 0x80>;
- interrupt-parent = <&ipic>;
- interrupts = <71 8>;
- };
- dma-channel@100 {
- compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
- cell-index = <2>;
- reg = <0x100 0x80>;
- interrupt-parent = <&ipic>;
- interrupts = <71 8>;
- };
- dma-channel@180 {
- compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
- cell-index = <3>;
- reg = <0x180 0x80>;
- interrupt-parent = <&ipic>;
- interrupts = <71 8>;
- };
- };
-
-** Freescale EloPlus DMA Controller
- This is a 4-channel DMA controller with extended addresses and chaining,
- mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as
- mpc8540, mpc8641 p4080, bsc9131 etc.
-
-Required properties:
-
-- compatible : must include "fsl,eloplus-dma"
-- reg : DMA General Status Register, i.e. DGSR which contains
- status for all the 4 DMA channels
-- cell-index : controller index. 0 for controller @ 0x21000,
- 1 for controller @ 0xc000
-- ranges : describes the mapping between the address space of the
- DMA channels and the address space of the DMA controller
-
-- DMA channel nodes:
- - compatible : must include "fsl,eloplus-dma-channel"
- However, see note below.
- - cell-index : DMA channel index starts at 0.
- - reg : DMA channel specific registers
- - interrupts : interrupt specifier for DMA channel IRQ
-
-Example:
- dma@21300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
- reg = <0x21300 4>;
- ranges = <0 0x21100 0x200>;
- cell-index = <0>;
- dma-channel@0 {
- compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
- reg = <0 0x80>;
- cell-index = <0>;
- interrupt-parent = <&mpic>;
- interrupts = <20 2>;
- };
- dma-channel@80 {
- compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
- reg = <0x80 0x80>;
- cell-index = <1>;
- interrupt-parent = <&mpic>;
- interrupts = <21 2>;
- };
- dma-channel@100 {
- compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
- reg = <0x100 0x80>;
- cell-index = <2>;
- interrupt-parent = <&mpic>;
- interrupts = <22 2>;
- };
- dma-channel@180 {
- compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
- reg = <0x180 0x80>;
- cell-index = <3>;
- interrupt-parent = <&mpic>;
- interrupts = <23 2>;
- };
- };
-
-** Freescale Elo3 DMA Controller
- DMA controller which has same function as EloPlus except that Elo3 has 8
- channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
- series chips, such as t1040, t4240, b4860.
-
-Required properties:
-
-- compatible : must include "fsl,elo3-dma"
-- reg : contains two entries for DMA General Status Registers,
- i.e. DGSR0 which includes status for channel 1~4, and
- DGSR1 for channel 5~8
-- ranges : describes the mapping between the address space of the
- DMA channels and the address space of the DMA controller
-
-- DMA channel nodes:
- - compatible : must include "fsl,eloplus-dma-channel"
- - reg : DMA channel specific registers
- - interrupts : interrupt specifier for DMA channel IRQ
-
-Example:
-dma@100300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,elo3-dma";
- reg = <0x100300 0x4>,
- <0x100600 0x4>;
- ranges = <0x0 0x100100 0x500>;
- dma-channel@0 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x0 0x80>;
- interrupts = <28 2 0 0>;
- };
- dma-channel@80 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x80 0x80>;
- interrupts = <29 2 0 0>;
- };
- dma-channel@100 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x100 0x80>;
- interrupts = <30 2 0 0>;
- };
- dma-channel@180 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x180 0x80>;
- interrupts = <31 2 0 0>;
- };
- dma-channel@300 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x300 0x80>;
- interrupts = <76 2 0 0>;
- };
- dma-channel@380 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x380 0x80>;
- interrupts = <77 2 0 0>;
- };
- dma-channel@400 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x400 0x80>;
- interrupts = <78 2 0 0>;
- };
- dma-channel@480 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x480 0x80>;
- interrupts = <79 2 0 0>;
- };
-};
-
-Note on DMA channel compatible properties: The compatible property must say
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
-driver (fsldma). Any DMA channel used by fsldma cannot be used by another
-DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA
-channel that should be used for another driver should not use
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel". For the SSI drivers, for
-example, the compatible property should be "fsl,ssi-dma-channel". See ssi.txt
-for more information.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt b/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt
deleted file mode 100644
index 37f91fa57654..000000000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU)
-
-Required properties:
-- compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx".
-- reg : should specify I2C address (0x0a).
-- #gpio-cells : should be 2.
-- gpio-controller : should be present.
-
-Example:
-
-mcu@a {
- #gpio-cells = <2>;
- compatible = "fsl,mc9s08qg8-mpc8349emitx",
- "fsl,mcu-mpc8349emitx";
- reg = <0x0a>;
- gpio-controller;
-};
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
deleted file mode 100644
index dc5744636a57..000000000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
+++ /dev/null
@@ -1,231 +0,0 @@
-=====================================================================
-Freescale MPIC Interrupt Controller Node
-Copyright (C) 2010,2011 Freescale Semiconductor Inc.
-=====================================================================
-
-The Freescale MPIC interrupt controller is found on all PowerQUICC
-and QorIQ processors and is compatible with the Open PIC. The
-notable difference from Open PIC binding is the addition of 2
-additional cells in the interrupt specifier defining interrupt type
-information.
-
-PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: Shall include "fsl,mpic". Freescale MPIC
- controllers compatible with this binding have Block
- Revision Registers BRR1 and BRR2 at offset 0x0 and
- 0x10 in the MPIC.
-
- - reg
- Usage: required
- Value type: <prop-encoded-array>
- Definition: A standard property. Specifies the physical
- offset and length of the device's registers within the
- CCSR address space.
-
- - interrupt-controller
- Usage: required
- Value type: <empty>
- Definition: Specifies that this node is an interrupt
- controller
-
- - #interrupt-cells
- Usage: required
- Value type: <u32>
- Definition: Shall be 2 or 4. A value of 2 means that interrupt
- specifiers do not contain the interrupt-type or type-specific
- information cells.
-
- - #address-cells
- Usage: required
- Value type: <u32>
- Definition: Shall be 0.
-
- - pic-no-reset
- Usage: optional
- Value type: <empty>
- Definition: The presence of this property specifies that the
- MPIC must not be reset by the client program, and that
- the boot program has initialized all interrupt source
- configuration registers to a sane state-- masked or
- directed at other cores. This ensures that the client
- program will not receive interrupts for sources not belonging
- to the client. The presence of this property also mandates
- that any initialization related to interrupt sources shall
- be limited to sources explicitly referenced in the device tree.
-
- - big-endian
- Usage: optional
- Value type: <empty>
- If present the MPIC will be assumed to be big-endian. Some
- device-trees omit this property on MPIC nodes even when the MPIC is
- in fact big-endian, so certain boards override this property.
-
- - single-cpu-affinity
- Usage: optional
- Value type: <empty>
- If present the MPIC will be assumed to only be able to route
- non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC).
-
- - last-interrupt-source
- Usage: optional
- Value type: <u32>
- Some MPICs do not correctly report the number of hardware sources
- in the global feature registers. If specified, this field will
- override the value read from MPIC_GREG_FEATURE_LAST_SRC.
-
-INTERRUPT SPECIFIER DEFINITION
-
- Interrupt specifiers consists of 4 cells encoded as
- follows:
-
- <1st-cell> interrupt-number
-
- Identifies the interrupt source. The meaning
- depends on the type of interrupt.
-
- Note: If the interrupt-type cell is undefined
- (i.e. #interrupt-cells = 2), this cell
- should be interpreted the same as for
- interrupt-type 0-- i.e. an external or
- normal SoC device interrupt.
-
- <2nd-cell> level-sense information, encoded as follows:
- 0 = low-to-high edge triggered
- 1 = active low level-sensitive
- 2 = active high level-sensitive
- 3 = high-to-low edge triggered
-
- <3rd-cell> interrupt-type
-
- The following types are supported:
-
- 0 = external or normal SoC device interrupt
-
- The interrupt-number cell contains
- the SoC device interrupt number. The
- type-specific cell is undefined. The
- interrupt-number is derived from the
- MPIC a block of registers referred to as
- the "Interrupt Source Configuration Registers".
- Each source has 32-bytes of registers
- (vector/priority and destination) in this
- region. So interrupt 0 is at offset 0x0,
- interrupt 1 is at offset 0x20, and so on.
-
- 1 = error interrupt
-
- The interrupt-number cell contains
- the SoC device interrupt number for
- the error interrupt. The type-specific
- cell identifies the specific error
- interrupt number.
-
- 2 = MPIC inter-processor interrupt (IPI)
-
- The interrupt-number cell identifies
- the MPIC IPI number. The type-specific
- cell is undefined.
-
- 3 = MPIC timer interrupt
-
- The interrupt-number cell identifies
- the MPIC timer number. The type-specific
- cell is undefined.
-
- <4th-cell> type-specific information
-
- The type-specific cell is encoded as follows:
-
- - For interrupt-type 1 (error interrupt),
- the type-specific cell contains the
- bit number of the error interrupt in the
- Error Interrupt Summary Register.
-
-EXAMPLE 1
- /*
- * mpic interrupt controller with 4 cells per specifier
- */
- mpic: pic@40000 {
- compatible = "fsl,mpic";
- interrupt-controller;
- #interrupt-cells = <4>;
- #address-cells = <0>;
- reg = <0x40000 0x40000>;
- };
-
-EXAMPLE 2
- /*
- * The MPC8544 I2C controller node has an internal
- * interrupt number of 27. As per the reference manual
- * this corresponds to interrupt source configuration
- * registers at 0x5_0560.
- *
- * The interrupt source configuration registers begin
- * at 0x5_0000.
- *
- * To compute the interrupt specifier interrupt number
- *
- * 0x560 >> 5 = 43
- *
- * The interrupt source configuration registers begin
- * at 0x5_0000, and so the i2c vector/priority registers
- * are at 0x5_0560.
- */
- i2c@3000 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- compatible = "fsl-i2c";
- reg = <0x3000 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- dfsrr;
- };
-
-
-EXAMPLE 3
- /*
- * Definition of a node defining the 4
- * MPIC IPI interrupts. Note the interrupt
- * type of 2.
- */
- ipi@410a0 {
- compatible = "fsl,mpic-ipi";
- reg = <0x40040 0x10>;
- interrupts = <0 0 2 0
- 1 0 2 0
- 2 0 2 0
- 3 0 2 0>;
- };
-
-EXAMPLE 4
- /*
- * Definition of a node defining the MPIC
- * global timers. Note the interrupt
- * type of 3.
- */
- timer0: timer@41100 {
- compatible = "fsl,mpic-global-timer";
- reg = <0x41100 0x100 0x41300 4>;
- interrupts = <0 0 3 0
- 1 0 3 0
- 2 0 3 0
- 3 0 3 0>;
- };
-
-EXAMPLE 5
- /*
- * Definition of an error interrupt (interrupt type 1).
- * SoC interrupt number is 16 and the specific error
- * interrupt bit in the error interrupt summary register
- * is 23.
- */
- memory-controller@8000 {
- compatible = "fsl,p4080-memory-controller";
- reg = <0x8000 0x1000>;
- interrupts = <16 2 1 23>;
- };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
deleted file mode 100644
index f8d2b7fe06d6..000000000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
+++ /dev/null
@@ -1,111 +0,0 @@
-* Freescale MSI interrupt controller
-
-Required properties:
-- compatible : compatible list, may contain one or two entries
- The first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
- etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" or
- "fsl,mpic-msi-v4.3" depending on the parent type and version. If mpic
- version is 4.3, the number of MSI registers is increased to 16, MSIIR1 is
- provided to access these 16 registers, and compatible "fsl,mpic-msi-v4.3"
- should be used. The first entry is optional; the second entry is
- required.
-
-- reg : It may contain one or two regions. The first region should contain
- the address and the length of the shared message interrupt register set.
- The second region should contain the address of aliased MSIIR or MSIIR1
- register for platforms that have such an alias, if using MSIIR1, the second
- region must be added because different MSI group has different MSIIR1 offset.
-
-- interrupts : each one of the interrupts here is one entry per 32 MSIs,
- and routed to the host interrupt controller. the interrupts should
- be set as edge sensitive. If msi-available-ranges is present, only
- the interrupts that correspond to available ranges shall be present.
-
-Optional properties:
-- msi-available-ranges: use <start count> style section to define which
- msi interrupt can be used in the 256 msi interrupts. This property is
- optional, without this, all the MSI interrupts can be used.
- Each available range must begin and end on a multiple of 32 (i.e.
- no splitting an individual MSI register or the associated PIC interrupt).
- MPIC v4.3 does not support this property because the 32 interrupts of an
- individual register are not continuous when using MSIIR1.
-
-- msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register
- is used for MSI messaging. The address of MSIIR in PCI address space is
- the MSI message address.
-
- This property may be used in virtualized environments where the hypervisor
- has created an alternate mapping for the MSIR block. See below for an
- explanation.
-
-
-Example:
- msi@41600 {
- compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
- reg = <0x41600 0x80>;
- msi-available-ranges = <0 0x100>;
- interrupts = <
- 0xe0 0
- 0xe1 0
- 0xe2 0
- 0xe3 0
- 0xe4 0
- 0xe5 0
- 0xe6 0
- 0xe7 0>;
- interrupt-parent = <&mpic>;
- };
-
- msi@41600 {
- compatible = "fsl,mpic-msi-v4.3";
- reg = <0x41600 0x200 0x44148 4>;
- interrupts = <
- 0xe0 0 0 0
- 0xe1 0 0 0
- 0xe2 0 0 0
- 0xe3 0 0 0
- 0xe4 0 0 0
- 0xe5 0 0 0
- 0xe6 0 0 0
- 0xe7 0 0 0
- 0x100 0 0 0
- 0x101 0 0 0
- 0x102 0 0 0
- 0x103 0 0 0
- 0x104 0 0 0
- 0x105 0 0 0
- 0x106 0 0 0
- 0x107 0 0 0>;
- };
-
-The Freescale hypervisor and msi-address-64
--------------------------------------------
-Normally, PCI devices have access to all of CCSR via an ATMU mapping. The
-Freescale MSI driver calculates the address of MSIIR (in the MSI register
-block) and sets that address as the MSI message address.
-
-In a virtualized environment, the hypervisor may need to create an IOMMU
-mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement
-because of hardware limitations of the Peripheral Access Management Unit
-(PAMU), which is currently the only IOMMU that the hypervisor supports.
-The ATMU is programmed with the guest physical address, and the PAMU
-intercepts transactions and reroutes them to the true physical address.
-
-In the PAMU, each PCI controller is given only one primary window. The
-PAMU restricts DMA operations so that they can only occur within a window.
-Because PCI devices must be able to DMA to memory, the primary window must
-be used to cover all of the guest's memory space.
-
-PAMU primary windows can be divided into 256 subwindows, and each
-subwindow can have its own address mapping ("guest physical" to "true
-physical"). However, each subwindow has to have the same alignment, which
-means they cannot be located at just any address. Because of these
-restrictions, it is usually impossible to create a 4KB subwindow that
-covers MSIIR where it's normally located.
-
-Therefore, the hypervisor has to create a subwindow inside the same
-primary window used for memory, but mapped to the MSIR block (where MSIIR
-lives). The first subwindow after the end of guest memory is used for
-this. The address specified in the msi-address-64 property is the PCI
-address of MSIIR. The hypervisor configures the PAMU to map that address to
-the true physical address of MSIIR.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
deleted file mode 100644
index 07256b7ffcaa..000000000000
--- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-* Power Management Controller
-
-Properties:
-- compatible: "fsl,<chip>-pmc".
-
- "fsl,mpc8349-pmc" should be listed for any chip whose PMC is
- compatible. "fsl,mpc8313-pmc" should also be listed for any chip
- whose PMC is compatible, and implies deep-sleep capability.
-
- "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
- compatible. "fsl,mpc8536-pmc" should also be listed for any chip
- whose PMC is compatible, and implies deep-sleep capability.
-
- "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
- compatible; all statements below that apply to "fsl,mpc8548-pmc" also
- apply to "fsl,mpc8641d-pmc".
-
- Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these
- bit assignments are indicated via the sleep specifier in each device's
- sleep property.
-
-- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource
- is the PMC block, and the second resource is the Clock Configuration
- block.
-
- For devices compatible with "fsl,mpc8548-pmc", the first resource
- is a 32-byte block beginning with DEVDISR.
-
-- interrupts: For "fsl,mpc8349-pmc"-compatible devices, the first
- resource is the PMC block interrupt.
-
-- fsl,mpc8313-wakeup-timer: For "fsl,mpc8313-pmc"-compatible devices,
- this is a phandle to an "fsl,gtm" node on which timer 4 can be used as
- a wakeup source from deep sleep.
-
-Sleep specifiers:
-
- fsl,mpc8349-pmc: Sleep specifiers consist of one cell. For each bit
- that is set in the cell, the corresponding bit in SCCR will be saved
- and cleared on suspend, and restored on resume. This sleep controller
- supports disabling and resuming devices at any time.
-
- fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of
- which will be ORed into PMCDR upon suspend, and cleared from PMCDR
- upon resume. The first two cells are as described for fsl,mpc8578-pmc.
- This sleep controller only supports disabling devices during system
- sleep, or permanently.
-
- fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the
- first of which will be ORed into DEVDISR (and the second into
- DEVDISR2, if present -- this cell should be zero or absent if the
- hardware does not have DEVDISR2) upon a request for permanent device
- disabling. This sleep controller does not support configuring devices
- to disable during system sleep (unless supported by another compatible
- match), or dynamically.
-
-Example:
-
- power@b00 {
- compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc";
- reg = <0xb00 0x100 0xa00 0x100>;
- interrupts = <80 8>;
- };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.yaml b/Documentation/devicetree/bindings/powerpc/fsl/pmc.yaml
new file mode 100644
index 000000000000..276ece7f01db
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/powerpc/fsl/pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Power Management Controller
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+description: |
+ The Power Management Controller in several MPC8xxx SoCs helps save power by
+ controlling chip-wide low-power states as well as peripheral clock gating.
+
+ Sleep of peripheral devices is configured by the `sleep` property, for
+ example `sleep = <&pmc 0x00000030>`. Any cells after the &pmc phandle are
+ called a sleep specifier.
+
+ For "fsl,mpc8349-pmc", sleep specifiers consist of one cell. For each bit that
+ is set in the cell, the corresponding bit in SCCR will be saved and cleared
+ on suspend, and restored on resume. This sleep controller supports disabling
+ and resuming devices at any time.
+
+ For "fsl,mpc8536-pmc", sleep specifiers consist of three cells, the third of
+ which will be ORed into PMCDR upon suspend, and cleared from PMCDR upon
+ resume. The first two cells are as described for fsl,mpc8548-pmc. This
+ sleep controller only supports disabling devices during system sleep, or
+ permanently.
+
+ For "fsl,mpc8548-pmc" or "fsl,mpc8641d-pmc", Sleep specifiers consist of one
+ or two cells, the first of which will be ORed into DEVDISR (and the second
+ into DEVDISR2, if present -- this cell should be zero or absent if the
+ hardware does not have DEVDISR2) upon a request for permanent device
+ disabling. This sleep controller does not support configuring devices to
+ disable during system sleep (unless supported by another compatible match),
+ or dynamically.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: fsl,mpc8315-pmc
+ - const: fsl,mpc8313-pmc
+ - const: fsl,mpc8349-pmc
+
+ - items:
+ - enum:
+ - fsl,mpc8313-pmc
+ - fsl,mpc8323-pmc
+ - fsl,mpc8360-pmc
+ - fsl,mpc8377-pmc
+ - fsl,mpc8378-pmc
+ - fsl,mpc8379-pmc
+ - const: fsl,mpc8349-pmc
+
+ - items:
+ - const: fsl,p1022-pmc
+ - const: fsl,mpc8536-pmc
+ - const: fsl,mpc8548-pmc
+
+ - items:
+ - enum:
+ - fsl,mpc8536-pmc
+ - fsl,mpc8568-pmc
+ - fsl,mpc8569-pmc
+ - const: fsl,mpc8548-pmc
+
+ - enum:
+ - fsl,mpc8548-pmc
+ - fsl,mpc8641d-pmc
+
+ description: |
+ "fsl,mpc8349-pmc" should be listed for any chip whose PMC is
+ compatible. "fsl,mpc8313-pmc" should also be listed for any chip
+ whose PMC is compatible, and implies deep-sleep capability.
+
+ "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
+ compatible. "fsl,mpc8536-pmc" should also be listed for any chip
+ whose PMC is compatible, and implies deep-sleep capability.
+
+ "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
+ compatible; all statements below that apply to "fsl,mpc8548-pmc" also
+ apply to "fsl,mpc8641d-pmc".
+
+ Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these
+ bit assignments are indicated via the sleep specifier in each device's
+ sleep property.
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ fsl,mpc8313-wakeup-timer:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ For "fsl,mpc8313-pmc"-compatible devices, this is a phandle to an
+ "fsl,gtm" node on which timer 4 can be used as a wakeup source from deep
+ sleep.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,mpc8349-pmc
+ then:
+ properties:
+ reg:
+ items:
+ - description: PMC block
+ - description: Clock Configuration block
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,mpc8548-pmc
+ - fsl,mpc8641d-pmc
+ then:
+ properties:
+ reg:
+ items:
+ - description: 32-byte block beginning with DEVDISR
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmc: power@b00 {
+ compatible = "fsl,mpc8377-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100>, <0xa00 0x100>;
+ interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ - |
+ power@e0070 {
+ compatible = "fsl,mpc8548-pmc";
+ reg = <0xe0070 0x20>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
index 4ad29b9ac2ac..ea902bc5873d 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
@@ -60,7 +60,7 @@ Optional property:
- fsl,liodn: Specifies the LIODN to be used for Job Ring. This
property is normally set by firmware. Value
is of 12-bits which is the LIODN number for this JR.
- This property is used by the IOMMU (PAMU) to distinquish
+ This property is used by the IOMMU (PAMU) to distinguish
transactions from this JR and than be able to do address
translation & protection accordingly.
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt
index b558585b1aaf..3826bd1219d1 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt
@@ -42,7 +42,7 @@ Nintendo GameCube device tree
- compatible : should be "nintendo,flipper-pic"
-1.c) The Digital Signal Procesor (DSP) node
+1.c) The Digital Signal Processor (DSP) node
Represents the digital signal processor interface, designed to offload
audio related tasks.
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index c4d78f28d23c..df060a0d7d4a 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -53,7 +53,7 @@ Nintendo Wii device tree
- compatible : should be "nintendo,flipper-pic"
- interrupt-controller
-1.c) The Digital Signal Procesor (DSP) node
+1.c) The Digital Signal Processor (DSP) node
Represents the digital signal processor interface, designed to offload
audio related tasks.
@@ -97,16 +97,6 @@ Nintendo Wii device tree
- reg : should contain the EXI registers location and length
- interrupts : should contain the EXI interrupt
-1.g) The Open Host Controller Interface (OHCI) nodes
-
- Represent the USB 1.x Open Host Controller Interfaces.
-
- Required properties:
-
- - compatible : should be "nintendo,hollywood-usb-ohci","usb-ohci"
- - reg : should contain the OHCI registers location and length
- - interrupts : should contain the OHCI interrupt
-
1.h) The Enhanced Host Controller Interface (EHCI) node
Represents the USB 2.0 Enhanced Host Controller Interface.
@@ -149,10 +139,6 @@ Nintendo Wii device tree
- interrupt-controller
- interrupts : should contain the cascade interrupt of the "flipper" pic
-1.l) The General Purpose I/O (GPIO) controller node
-
- see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
-
1.m) The control node
Represents the control interface used to setup several miscellaneous
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt
deleted file mode 100644
index 9012a2a02e14..000000000000
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Device-Tree Bindings for a PPS Signal on GPIO
-
-These properties describe a PPS (pulse-per-second) signal connected to
-a GPIO pin.
-
-Required properties:
-- compatible: should be "pps-gpio"
-- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
-
-Additional required properties for the PPS ECHO functionality:
-- echo-gpios: one PPS ECHO GPIO in the format described by ../gpio/gpio.txt
-- echo-active-ms: duration in ms of the active portion of the echo pulse
-
-Optional properties:
-- assert-falling-edge: when present, assert is indicated by a falling edge
- (instead of by a rising edge)
-
-Example:
- pps {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pps>;
-
- gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
- assert-falling-edge;
-
- echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
- echo-active-ms = <100>;
-
- compatible = "pps-gpio";
- };
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.yaml b/Documentation/devicetree/bindings/pps/pps-gpio.yaml
new file mode 100644
index 000000000000..383a838744eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pps/pps-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PPS Signal via GPIO
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+properties:
+ compatible:
+ const: pps-gpio
+
+ gpios:
+ description: The GPIO that provides the PPS signal.
+ maxItems: 1
+
+ echo-gpios:
+ description: The GPIO that provides the PPS ECHO signal.
+ maxItems: 1
+
+ echo-active-ms:
+ description: Duration in ms of the active portion of the echo pulse.
+
+ assert-falling-edge:
+ description: Indicates a falling edge assert, when present. Rising edge if absent.
+ type: boolean
+
+required:
+ - compatible
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ pps {
+ compatible = "pps-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pps>;
+ gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ assert-falling-edge;
+ echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+ echo-active-ms = <100>;
+ };
diff --git a/Documentation/devicetree/bindings/ptp/fsl,ptp.yaml b/Documentation/devicetree/bindings/ptp/fsl,ptp.yaml
new file mode 100644
index 000000000000..42ca895f3c4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/fsl,ptp.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ptp/fsl,ptp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QorIQ 1588 timer based PTP clock
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,etsec-ptp
+ - fsl,fman-ptp-timer
+ - fsl,dpaa2-ptp
+ - items:
+ - const: pci1957,ee02
+ - const: fsl,enetc-ptp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ fsl,cksel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Timer reference clock source.
+
+ Reference clock source is determined by the value, which is holded
+ in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the
+ value, which will be directly written in those bits, that is why,
+ according to reference manual, the next clock sources can be used:
+
+ For eTSEC,
+ <0> - external high precision timer reference clock (TSEC_TMR_CLK
+ input is used for this purpose);
+ <1> - eTSEC system clock;
+ <2> - eTSEC1 transmit clock;
+ <3> - RTC clock input.
+
+ For DPAA FMan,
+ <0> - external high precision timer reference clock (TMR_1588_CLK)
+ <1> - MAC system clock (1/2 FMan clock)
+ <2> - reserved
+ <3> - RTC clock oscillator
+
+ fsl,tclk-period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Timer reference clock period in nanoseconds.
+
+ fsl,tmr-prsc:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Prescaler, divides the output clock.
+
+ fsl,tmr-add:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Frequency compensation value.
+
+ fsl,tmr-fiper1:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Fixed interval period pulse generator.
+
+ fsl,tmr-fiper2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Fixed interval period pulse generator.
+
+ fsl,tmr-fiper3:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Fixed interval period pulse generator.
+ Supported only on DPAA2 and ENETC hardware.
+
+ fsl,max-adj:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Maximum frequency adjustment in parts per billion.
+
+ These properties set the operational parameters for the PTP
+ clock. You must choose these carefully for the clock to work right.
+ Here is how to figure good values:
+
+ TimerOsc = selected reference clock MHz
+ tclk_period = desired clock period nanoseconds
+ NominalFreq = 1000 / tclk_period MHz
+ FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
+ tmr_add = ceil(2^32 / FreqDivRatio)
+ OutputClock = NominalFreq / tmr_prsc MHz
+ PulseWidth = 1 / OutputClock microseconds
+ FiperFreq1 = desired frequency in Hz
+ FiperDiv1 = 1000000 * OutputClock / FiperFreq1
+ tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
+ max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1
+
+ The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
+ driver expects that tmr_fiper1 will be correctly set to produce a 1
+ Pulse Per Second (PPS) signal, since this will be offered to the PPS
+ subsystem to synchronize the Linux clock.
+
+ When this attribute is not used, the IEEE 1588 timer reference clock
+ will use the eTSEC system clock (for Gianfar) or the MAC system
+ clock (for DPAA).
+
+ fsl,extts-fifo:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The presence of this property indicates hardware
+ support for the external trigger stamp FIFO
+
+ little-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The presence of this property indicates the 1588 timer
+ support for the external trigger stamp FIFO.
+ IP block is little-endian mode. The default endian mode
+ is big-endian.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,enetc-ptp
+ then:
+ $ref: /schemas/pci/pci-device.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ phc@24e00 {
+ compatible = "fsl,etsec-ptp";
+ reg = <0x24e00 0xb0>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-parent = <&ipic>;
+ fsl,cksel = <1>;
+ fsl,tclk-period = <10>;
+ fsl,tmr-prsc = <100>;
+ fsl,tmr-add = <0x999999a4>;
+ fsl,tmr-fiper1 = <0x3b9ac9f6>;
+ fsl,tmr-fiper2 = <0x00018696>;
+ fsl,max-adj = <659999998>;
+ };
diff --git a/Documentation/devicetree/bindings/ptp/nxp,ptp-netc.yaml b/Documentation/devicetree/bindings/ptp/nxp,ptp-netc.yaml
new file mode 100644
index 000000000000..042de9d5a92b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/nxp,ptp-netc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ptp/nxp,ptp-netc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP NETC V4 Timer PTP clock
+
+description:
+ NETC V4 Timer provides current time with nanosecond resolution, precise
+ periodic pulse, pulse on timeout (alarm), and time capture on external
+ pulse support. And it supports time synchronization as required for
+ IEEE 1588 and IEEE 802.1AS-2020.
+
+maintainers:
+ - Wei Fang <wei.fang@nxp.com>
+ - Clark Wang <xiaoning.wang@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - pci1131,ee02
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ The reference clock of NETC Timer, can be selected between 3 different
+ clock sources using an integrated hardware mux TMR_CTRL[CK_SEL].
+ The "ccm" means the reference clock comes from CCM of SoC.
+ The "ext" means the reference clock comes from external IO pins.
+ If not present, indicates that the system clock of NETC IP is selected
+ as the reference clock.
+
+ clock-names:
+ enum:
+ - ccm
+ - ext
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/pci/pci-device.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ptp-timer@18,0 {
+ compatible = "pci1131,ee02";
+ reg = <0x00c000 0 0 0 0>;
+ clocks = <&scmi_clk 18>;
+ clock-names = "ccm";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/ptp/ptp-idt82p33.yaml b/Documentation/devicetree/bindings/ptp/ptp-idt82p33.yaml
index 9bc664f414a1..51381e4cbb1f 100644
--- a/Documentation/devicetree/bindings/ptp/ptp-idt82p33.yaml
+++ b/Documentation/devicetree/bindings/ptp/ptp-idt82p33.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ptp/ptp-idt82p33.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: IDT 82P33 PTP Clock Device Tree Bindings
+title: IDT 82P33 PTP Clock
description: |
IDT 82P33XXX Synchronization Management Unit (SMU) based PTP clock
diff --git a/Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml b/Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml
index 658cec67743e..7cf32663c806 100644
--- a/Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml
+++ b/Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ptp/ptp-idtcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: IDT ClockMatrix (TM) PTP Clock Device Tree Bindings
+title: IDT ClockMatrix (TM) PTP Clock
maintainers:
- Vincent Cheng <vincent.cheng.xh@renesas.com>
diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
deleted file mode 100644
index 743eda754e65..000000000000
--- a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-* Freescale QorIQ 1588 timer based PTP clock
-
-General Properties:
-
- - compatible Should be "fsl,etsec-ptp" for eTSEC
- Should be "fsl,fman-ptp-timer" for DPAA FMan
- Should be "fsl,dpaa2-ptp" for DPAA2
- Should be "fsl,enetc-ptp" for ENETC
- - reg Offset and length of the register set for the device
- - interrupts There should be at least two interrupts. Some devices
- have as many as four PTP related interrupts.
-
-Clock Properties:
-
- - fsl,cksel Timer reference clock source.
- - fsl,tclk-period Timer reference clock period in nanoseconds.
- - fsl,tmr-prsc Prescaler, divides the output clock.
- - fsl,tmr-add Frequency compensation value.
- - fsl,tmr-fiper1 Fixed interval period pulse generator.
- - fsl,tmr-fiper2 Fixed interval period pulse generator.
- - fsl,tmr-fiper3 Fixed interval period pulse generator.
- Supported only on DPAA2 and ENETC hardware.
- - fsl,max-adj Maximum frequency adjustment in parts per billion.
- - fsl,extts-fifo The presence of this property indicates hardware
- support for the external trigger stamp FIFO.
- - little-endian The presence of this property indicates the 1588 timer
- IP block is little-endian mode. The default endian mode
- is big-endian.
-
- These properties set the operational parameters for the PTP
- clock. You must choose these carefully for the clock to work right.
- Here is how to figure good values:
-
- TimerOsc = selected reference clock MHz
- tclk_period = desired clock period nanoseconds
- NominalFreq = 1000 / tclk_period MHz
- FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
- tmr_add = ceil(2^32 / FreqDivRatio)
- OutputClock = NominalFreq / tmr_prsc MHz
- PulseWidth = 1 / OutputClock microseconds
- FiperFreq1 = desired frequency in Hz
- FiperDiv1 = 1000000 * OutputClock / FiperFreq1
- tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
- max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1
-
- The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
- driver expects that tmr_fiper1 will be correctly set to produce a 1
- Pulse Per Second (PPS) signal, since this will be offered to the PPS
- subsystem to synchronize the Linux clock.
-
- Reference clock source is determined by the value, which is holded
- in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the
- value, which will be directly written in those bits, that is why,
- according to reference manual, the next clock sources can be used:
-
- For eTSEC,
- <0> - external high precision timer reference clock (TSEC_TMR_CLK
- input is used for this purpose);
- <1> - eTSEC system clock;
- <2> - eTSEC1 transmit clock;
- <3> - RTC clock input.
-
- For DPAA FMan,
- <0> - external high precision timer reference clock (TMR_1588_CLK)
- <1> - MAC system clock (1/2 FMan clock)
- <2> - reserved
- <3> - RTC clock oscillator
-
- When this attribute is not used, the IEEE 1588 timer reference clock
- will use the eTSEC system clock (for Gianfar) or the MAC system
- clock (for DPAA).
-
-Example:
-
- ptp_clock@24e00 {
- compatible = "fsl,etsec-ptp";
- reg = <0x24E00 0xB0>;
- interrupts = <12 0x8 13 0x8>;
- interrupt-parent = < &ipic >;
- fsl,cksel = <1>;
- fsl,tclk-period = <10>;
- fsl,tmr-prsc = <100>;
- fsl,tmr-add = <0x999999A4>;
- fsl,tmr-fiper1 = <0x3B9AC9F6>;
- fsl,tmr-fiper2 = <0x00018696>;
- fsl,max-adj = <659999998>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml b/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml
new file mode 100644
index 000000000000..e4c2d5186ded
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/adi,axi-pwmgen.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/adi,axi-pwmgen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AXI PWM generator
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+description:
+ The Analog Devices AXI PWM generator can generate PWM signals
+ with variable pulse width and period.
+
+ https://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.html
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: adi,axi-pwmgen-2.00.a
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: axi
+ - const: ext
+
+required:
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@44b00000 {
+ compatible = "adi,axi-pwmgen-2.00.a";
+ reg = <0x44b00000 0x1000>;
+ clocks = <&fpga_clk>, <&spi_clk>;
+ clock-names = "axi", "ext";
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/airoha,en7581-pwm.yaml b/Documentation/devicetree/bindings/pwm/airoha,en7581-pwm.yaml
new file mode 100644
index 000000000000..f36387572a97
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/airoha,en7581-pwm.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/airoha,en7581-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 PWM Controller
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: airoha,en7581-pwm
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - "#pwm-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm {
+ compatible = "airoha,en7581-pwm";
+
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
index e93e935564fb..1197858e431f 100644
--- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/pwm/allwinner,sun4i-a10-pwm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 PWM Device Tree Bindings
+title: Allwinner A10 PWM
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -25,7 +25,9 @@ properties:
- const: allwinner,sun8i-a83t-pwm
- const: allwinner,sun8i-h3-pwm
- items:
- - const: allwinner,sun8i-v3s-pwm
+ - enum:
+ - allwinner,suniv-f1c100s-pwm
+ - allwinner,sun8i-v3s-pwm
- const: allwinner,sun7i-a20-pwm
- items:
- const: allwinner,sun50i-a64-pwm
@@ -44,15 +46,15 @@ properties:
- description: Module Clock
- description: Bus Clock
- # Even though it only applies to subschemas under the conditionals,
- # not listing them here will trigger a warning because of the
- # additionalsProperties set to false.
- clock-names: true
+ clock-names:
+ minItems: 1
+ items:
+ - const: mod
+ - const: bus
resets:
maxItems: 1
-
allOf:
- $ref: pwm.yaml#
diff --git a/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
new file mode 100644
index 000000000000..04519b0c581d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/apple,s5l-fpwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple FPWM controller
+
+maintainers:
+ - asahi@lists.linux.dev
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+description: PWM controller used for keyboard backlight on ARM Macs
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - apple,t8103-fpwm
+ - apple,t8112-fpwm
+ - apple,t6000-fpwm
+ - apple,t6020-fpwm
+ - const: apple,s5l-fpwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm@235044000 {
+ compatible = "apple,t8103-fpwm", "apple,s5l-fpwm";
+ reg = <0x35044000 0x4000>;
+ power-domains = <&ps_fpwm1>;
+ clocks = <&clkref>;
+ #pwm-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/argon40,fan-hat.yaml b/Documentation/devicetree/bindings/pwm/argon40,fan-hat.yaml
new file mode 100644
index 000000000000..7dbc7c2cd802
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/argon40,fan-hat.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/argon40,fan-hat.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Argon40 Fan HAT PWM controller
+
+maintainers:
+ - Marek Vasut <marek.vasut+renesas@mailbox.org>
+
+description:
+ The trivial PWM on Argon40 Fan HAT, which is a RaspberryPi blower fan
+ hat which can be controlled over I2C, generates a fixed 30 kHz period
+ PWM signal with configurable 0..100% duty cycle to control the fan
+ speed.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: argon40,fan-hat
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pwm@1a {
+ compatible = "argon40,fan-hat";
+ reg = <0x1a>;
+ #pwm-cells = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml
index ab45df80345d..d20ad27657aa 100644
--- a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml
@@ -11,7 +11,7 @@ maintainers:
- Claudiu Beznea <claudiu.beznea@microchip.com>
allOf:
- - $ref: "pwm.yaml#"
+ - $ref: pwm.yaml#
properties:
compatible:
@@ -23,8 +23,13 @@ properties:
- atmel,sama5d2-pwm
- microchip,sam9x60-pwm
- items:
- - const: microchip,sama7g5-pwm
+ - enum:
+ - microchip,sama7d65-pwm
+ - microchip,sama7g5-pwm
- const: atmel,sama5d2-pwm
+ - items:
+ - const: microchip,sam9x7-pwm
+ - const: microchip,sam9x60-pwm
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml
new file mode 100644
index 000000000000..0e92868a2b68
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel,hlcdc-pwm.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/atmel,hlcdc-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel's HLCDC's PWM controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+ - Claudiu Beznea <claudiu.beznea@tuxon.dev>
+
+description:
+ The LCDC integrates a Pulse Width Modulation (PWM) Controller. This block
+ generates the LCD contrast control signal (LCD_PWM) that controls the
+ display's contrast by software. LCDC_PWM is an 8-bit PWM signal that can be
+ converted to an analog voltage with a simple passive filter. LCD display
+ panels have different backlight specifications in terms of minimum/maximum
+ values for PWM frequency. If the LCDC PWM frequency range does not match the
+ LCD display panel, it is possible to use the standalone PWM Controller to
+ drive the backlight.
+
+properties:
+ compatible:
+ const: atmel,hlcdc-pwm
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - "#pwm-cells"
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
deleted file mode 100644
index afa501bf7f94..000000000000
--- a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Device-Tree bindings for Atmel's HLCDC (High-end LCD Controller) PWM driver
-
-The Atmel HLCDC PWM is subdevice of the HLCDC MFD device.
-See ../mfd/atmel-hlcdc.txt for more details.
-
-Required properties:
- - compatible: value should be one of the following:
- "atmel,hlcdc-pwm"
- - pinctr-names: the pin control state names. Should contain "default".
- - pinctrl-0: should contain the pinctrl states described by pinctrl
- default.
- - #pwm-cells: should be set to 3. This PWM chip use the default 3 cells
- bindings defined in pwm.yaml in this directory.
-
-Example:
-
- hlcdc: hlcdc@f0030000 {
- compatible = "atmel,sama5d3-hlcdc";
- reg = <0xf0030000 0x2000>;
- clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
- clock-names = "periph_clk","sys_clk", "slow_clk";
-
- hlcdc_pwm: hlcdc-pwm {
- compatible = "atmel,hlcdc-pwm";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_lcd_pwm>;
- #pwm-cells = <3>;
- };
- };
diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml
index 119de3d7f9dd..44548a9da158 100644
--- a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml
@@ -35,8 +35,8 @@ additionalProperties: false
examples:
- |
pwm: pwm@f0408000 {
- compatible = "brcm,bcm7038-pwm";
- reg = <0xf0408000 0x28>;
- #pwm-cells = <2>;
- clocks = <&upg_fixed>;
+ compatible = "brcm,bcm7038-pwm";
+ reg = <0xf0408000 0x28>;
+ #pwm-cells = <2>;
+ clocks = <&upg_fixed>;
};
diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
deleted file mode 100644
index c42eecfc81ed..000000000000
--- a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Broadcom Kona PWM controller device tree bindings
-
-This controller has 6 channels.
-
-Required Properties :
-- compatible: should contain "brcm,kona-pwm"
-- reg: physical base address and length of the controller's registers
-- clocks: phandle + clock specifier pair for the external clock
-- #pwm-cells: Should be 3. See pwm.yaml in this directory for a
- description of the cells format.
-
-Refer to clocks/clock-bindings.txt for generic clock consumer properties.
-
-Example:
-
-pwm: pwm@3e01a000 {
- compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
- reg = <0x3e01a000 0xc4>;
- clocks = <&pwm_clk>;
- #pwm-cells = <3>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml
new file mode 100644
index 000000000000..fd785da5d3d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/brcm,kona-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family PWM controller
+
+description:
+ This controller has 6 channels.
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - brcm,bcm11351-pwm
+ - const: brcm,kona-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#pwm-cells':
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm281xx.h>
+
+ pwm@3e01a000 {
+ compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+ reg = <0x3e01a000 0xcc>;
+ clocks = <&slave_ccu BCM281XX_SLAVE_CCU_PWM>;
+ #pwm-cells = <3>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml b/Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml
new file mode 100644
index 000000000000..903210ef9c31
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/cirrus,ep9301-pwm.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/cirrus,ep9301-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic ep93xx PWM controller
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-pwm
+ - items:
+ - enum:
+ - cirrus,ep9302-pwm
+ - cirrus,ep9307-pwm
+ - cirrus,ep9312-pwm
+ - cirrus,ep9315-pwm
+ - const: cirrus,ep9301-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SoC PWM clock
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/cirrus,ep9301-syscon.h>
+ pwm@80910000 {
+ compatible = "cirrus,ep9301-pwm";
+ reg = <0x80910000 0x10>;
+ clocks = <&syscon EP93XX_CLK_PWM>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/fsl,vf610-ftm-pwm.yaml b/Documentation/devicetree/bindings/pwm/fsl,vf610-ftm-pwm.yaml
new file mode 100644
index 000000000000..c7a10180208e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/fsl,vf610-ftm-pwm.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/fsl,vf610-ftm-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale FlexTimer Module (FTM) PWM controller
+
+description: |
+ The same FTM PWM device can have a different endianness on different SoCs. The
+ device tree provides a property to describing this so that an operating system
+ device driver can handle all variants of the device. Refer to the table below
+ for the endianness of the FTM PWM block as integrated into the existing SoCs:
+
+ SoC | FTM-PWM endianness
+ --------+-------------------
+ Vybrid | LE
+ LS1 | BE
+ LS2 | LE
+
+ Please see ../regmap/regmap.txt for more detail about how to specify endian
+ modes in device tree.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,vf610-ftm-pwm
+ - fsl,imx8qm-ftm-pwm
+ - nxp,s32g2-ftm-pwm
+ - items:
+ - const: nxp,s32g3-ftm-pwm
+ - const: nxp,s32g2-ftm-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ minItems: 4
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: ftm_sys
+ - const: ftm_ext
+ - const: ftm_fix
+ - const: ftm_cnt_clk_en
+
+ pinctrl-0: true
+ pinctrl-1: true
+
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: sleep
+
+ big-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Boolean property, required if the FTM PWM registers use a big-
+ endian rather than little-endian layout.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: pwm.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/vf610-clock.h>
+
+ pwm@40038000 {
+ compatible = "fsl,vf610-ftm-pwm";
+ reg = <0x40038000 0x1000>;
+ #pwm-cells = <3>;
+ clocks = <&clks VF610_CLK_FTM0>,
+ <&clks VF610_CLK_FTM0_EXT_SEL>,
+ <&clks VF610_CLK_FTM0_FIX_SEL>,
+ <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
+ clock-names = "ftm_sys", "ftm_ext", "ftm_fix", "ftm_cnt_clk_en";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_1>;
+ big-endian;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
index c8577bdf6c94..8f5a468cfb91 100644
--- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
@@ -14,7 +14,7 @@ description: |
Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller
(EC) and controlled via a host-command interface.
An EC PWM node should be only found as a sub-node of the EC node (see
- Documentation/devicetree/bindings/mfd/google,cros-ec.yaml).
+ Documentation/devicetree/bindings/embedded-controller/google,cros-ec.yaml).
allOf:
- $ref: pwm.yaml#
@@ -35,7 +35,6 @@ properties:
required:
- compatible
- - '#pwm-cells'
additionalProperties: false
@@ -48,6 +47,7 @@ examples:
cros-ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
+ interrupts = <101 0>;
cros_ec_pwm: pwm {
compatible = "google,cros-ec-pwm";
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
index b3da4e629341..04148198e34d 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
@@ -14,12 +14,10 @@ allOf:
properties:
"#pwm-cells":
- description: |
- Should be 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.yaml
- in this directory for a description of the cells format.
- enum:
- - 2
- - 3
+ description:
+ The only third cell flag supported by this binding is
+ PWM_POLARITY_INVERTED. fsl,imx1-pwm does not support this flags.
+ const: 3
compatible:
oneOf:
@@ -43,6 +41,7 @@ properties:
- fsl,imx8mn-pwm
- fsl,imx8mp-pwm
- fsl,imx8mq-pwm
+ - fsl,imx8qxp-pwm
- const: fsl,imx27-pwm
reg:
@@ -61,12 +60,14 @@ properties:
interrupts:
maxItems: 1
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
- clocks
- clock-names
- - interrupts
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
index 8bef9dfeba9a..d5a9340ff920 100644
--- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml
@@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX TPM PWM controller
maintainers:
- - Anson Huang <anson.huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
description: |
The TPM counter and period counter are shared between multiple
@@ -21,8 +23,15 @@ properties:
const: 3
compatible:
- enum:
- - fsl,imx7ulp-pwm
+ oneOf:
+ - enum:
+ - fsl,imx7ulp-pwm
+ - items:
+ - enum:
+ - fsl,imx93-pwm
+ - fsl,imx94-pwm
+ - fsl,imx95-pwm
+ - const: fsl,imx7ulp-pwm
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml
index ec9f6bab798c..5b18a5913ed1 100644
--- a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/pwm/intel,keembay-pwm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel Keem Bay PWM Device Tree Bindings
+title: Intel Keem Bay PWM
maintainers:
- Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
diff --git a/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml b/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
index 981cfec53f37..19a9d2e15a96 100644
--- a/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
This module is part of the sl28cpld multi-function device. For more
- details see ../mfd/kontron,sl28cpld.yaml.
+ details see ../embedded-controller/kontron,sl28cpld.yaml.
The controller supports one PWM channel and supports only four distinct
frequencies (250Hz, 500Hz, 1kHz, 2kHz).
diff --git a/Documentation/devicetree/bindings/pwm/loongson,ls7a-pwm.yaml b/Documentation/devicetree/bindings/pwm/loongson,ls7a-pwm.yaml
new file mode 100644
index 000000000000..5d64fb40a0d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/loongson,ls7a-pwm.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/loongson,ls7a-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson PWM Controller
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+description:
+ The Loongson PWM has one pulse width output signal and one pulse input
+ signal to be measured.
+ It can be found on Loongson-2K series cpus and Loongson LS7A bridge chips.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls7a-pwm
+ - items:
+ - enum:
+ - loongson,ls2k0500-pwm
+ - loongson,ls2k1000-pwm
+ - loongson,ls2k2000-pwm
+ - const: loongson,ls7a-pwm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#pwm-cells':
+ description:
+ The first cell must have a value of 0, which specifies the PWM output signal;
+ The second cell is the period in nanoseconds;
+ The third cell flag supported by this binding is PWM_POLARITY_INVERTED.
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/loongson,ls2k-clk.h>
+
+ pwm@1fe22000 {
+ compatible = "loongson,ls2k1000-pwm", "loongson,ls7a-pwm";
+ reg = <0x1fe22000 0x10>;
+ interrupt-parent = <&liointc0>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LOONGSON2_APB_CLK>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/lpc1850-sct-pwm.txt b/Documentation/devicetree/bindings/pwm/lpc1850-sct-pwm.txt
deleted file mode 100644
index 43d9f4f08a2e..000000000000
--- a/Documentation/devicetree/bindings/pwm/lpc1850-sct-pwm.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* NXP LPC18xx State Configurable Timer - Pulse Width Modulator driver
-
-Required properties:
- - compatible: Should be "nxp,lpc1850-sct-pwm"
- - reg: Should contain physical base address and length of pwm registers.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clock/clock-bindings.txt for details.
- - clock-names: Must include the following entries.
- - pwm: PWM operating clock.
- - #pwm-cells: Should be 3. See pwm.yaml in this directory for the description
- of the cells format.
-
-Example:
- pwm: pwm@40000000 {
- compatible = "nxp,lpc1850-sct-pwm";
- reg = <0x40000000 0x1000>;
- clocks =<&ccu1 CLK_CPU_SCT>;
- clock-names = "pwm";
- #pwm-cells = <3>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
deleted file mode 100644
index 74b5bc5dd19a..000000000000
--- a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-LPC32XX PWM controller
-
-Required properties:
-- compatible: should be "nxp,lpc3220-pwm"
-- reg: physical base address and length of the controller's registers
-
-Examples:
-
-pwm@4005c000 {
- compatible = "nxp,lpc3220-pwm";
- reg = <0x4005c000 0x4>;
-};
-
-pwm@4005c004 {
- compatible = "nxp,lpc3220-pwm";
- reg = <0x4005c004 0x4>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml b/Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml
new file mode 100644
index 000000000000..091fec03df13
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/marvell,berlin-pwm.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/marvell,berlin-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Berlin PWM controller
+
+maintainers:
+ - Jisheng Zhang <jszhang@kernel.org>
+ - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+properties:
+ compatible:
+ const: marvell,berlin-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - $ref: pwm.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@f7f20000 {
+ compatible = "marvell,berlin-pwm";
+ reg = <0xf7f20000 0x40>;
+ clocks = <&chip_clk 12>;
+ #pwm-cells = <3>;
+ };
+
diff --git a/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml b/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml
new file mode 100644
index 000000000000..8df327e52810
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/marvell,pxa-pwm.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/marvell,pxa-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell PXA PWM
+
+maintainers:
+ - Duje Mihanović <duje.mihanovic@skole.hr>
+
+allOf:
+ - $ref: pwm.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: spacemit,k1-pwm
+ then:
+ properties:
+ "#pwm-cells":
+ const: 3
+ else:
+ properties:
+ "#pwm-cells":
+ const: 1
+ description: |
+ Used for specifying the period length in nanoseconds.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - marvell,pxa250-pwm
+ - marvell,pxa270-pwm
+ - marvell,pxa168-pwm
+ - marvell,pxa910-pwm
+ - items:
+ - const: spacemit,k1-pwm
+ - const: marvell,pxa910-pwm
+
+ reg:
+ # Length should be 0x10
+ maxItems: 1
+
+ "#pwm-cells":
+ description: Number of cells in a pwm specifier.
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/pxa-clock.h>
+
+ pwm0: pwm@40b00000 {
+ compatible = "marvell,pxa250-pwm";
+ reg = <0x40b00000 0x10>;
+ #pwm-cells = <1>;
+ clocks = <&clks CLK_PWM0>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
new file mode 100644
index 000000000000..fc31758a40b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/mediatek,mt2712-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek PWM Controller
+
+maintainers:
+ - John Crispin <john@phrozen.org>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2712-pwm
+ - mediatek,mt6795-pwm
+ - mediatek,mt6991-pwm
+ - mediatek,mt7622-pwm
+ - mediatek,mt7623-pwm
+ - mediatek,mt7628-pwm
+ - mediatek,mt7629-pwm
+ - mediatek,mt7981-pwm
+ - mediatek,mt7986-pwm
+ - mediatek,mt7988-pwm
+ - mediatek,mt8183-pwm
+ - mediatek,mt8365-pwm
+ - mediatek,mt8516-pwm
+ - items:
+ - enum:
+ - mediatek,mt8195-pwm
+ - const: mediatek,mt8183-pwm
+ - items:
+ - enum:
+ - mediatek,mt8196-pwm
+ - const: mediatek,mt6991-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ maxItems: 10
+
+ clock-names:
+ description:
+ This controller needs two input clocks for its core and one
+ clock for each PWM output.
+ minItems: 2
+ items:
+ - const: top
+ - const: main
+ - const: pwm1
+ - const: pwm2
+ - const: pwm3
+ - const: pwm4
+ - const: pwm5
+ - const: pwm6
+ - const: pwm7
+ - const: pwm8
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt2712-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pwm0: pwm@11006000 {
+ compatible = "mediatek,mt2712-pwm";
+ reg = <0x11006000 0x1000>;
+ #pwm-cells = <2>;
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_PWM_SEL>, <&pericfg CLK_PERI_PWM>,
+ <&pericfg CLK_PERI_PWM0>, <&pericfg CLK_PERI_PWM1>,
+ <&pericfg CLK_PERI_PWM2>, <&pericfg CLK_PERI_PWM3>,
+ <&pericfg CLK_PERI_PWM4>, <&pericfg CLK_PERI_PWM5>,
+ <&pericfg CLK_PERI_PWM6>, <&pericfg CLK_PERI_PWM7>;
+ clock-names = "top", "main",
+ "pwm1", "pwm2",
+ "pwm3", "pwm4",
+ "pwm5", "pwm6",
+ "pwm7", "pwm8";
+ };
diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
index e4fe2d1bfef5..68ef30414325 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
@@ -4,11 +4,10 @@
$id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek DISP_PWM Controller Device Tree Bindings
+title: MediaTek DISP_PWM Controller
maintainers:
- Jitao Shi <jitao.shi@mediatek.com>
- - Xinlei Lee <xinlei.lee@mediatek.com>
allOf:
- $ref: pwm.yaml#
@@ -22,13 +21,18 @@ properties:
- mediatek,mt8173-disp-pwm
- mediatek,mt8183-disp-pwm
- items:
- - const: mediatek,mt8167-disp-pwm
+ - enum:
+ - mediatek,mt6795-disp-pwm
+ - mediatek,mt8167-disp-pwm
- const: mediatek,mt8173-disp-pwm
- items:
- enum:
+ - mediatek,mt6893-disp-pwm
- mediatek,mt8186-disp-pwm
+ - mediatek,mt8188-disp-pwm
- mediatek,mt8192-disp-pwm
- mediatek,mt8195-disp-pwm
+ - mediatek,mt8365-disp-pwm
- const: mediatek,mt8183-disp-pwm
reg:
@@ -50,10 +54,12 @@ properties:
- const: main
- const: mm
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
- - "#pwm-cells"
- clocks
- clock-names
diff --git a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
index a7fae1772a81..70d563d44c35 100644
--- a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/pwm/microchip,corepwm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip IP corePWM controller bindings
+title: Microchip IP corePWM controller
maintainers:
- Conor Dooley <conor.dooley@microchip.com>
@@ -30,7 +30,9 @@ properties:
maxItems: 1
"#pwm-cells":
- const: 2
+ enum: [2, 3]
+ description:
+ The only flag supported by the controller is PWM_POLARITY_INVERTED.
microchip,sync-update-mask:
description: |
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
index a34cbc13f691..a9d3a41ac5b9 100644
--- a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
@@ -8,29 +8,36 @@ title: Freescale MXS PWM controller
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Anson Huang <anson.huang@nxp.com>
allOf:
- $ref: pwm.yaml#
properties:
compatible:
- enum:
- - fsl,imx23-pwm
+ oneOf:
+ - const: fsl,imx23-pwm
+ - items:
+ - enum:
+ - fsl,imx28-pwm
+ - const: fsl,imx23-pwm
reg:
maxItems: 1
+ clocks:
+ maxItems: 1
+
"#pwm-cells":
const: 3
fsl,pwm-number:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the number of PWM devices
required:
- compatible
- reg
+ - clocks
- fsl,pwm-number
additionalProperties: false
@@ -40,6 +47,7 @@ examples:
pwm@80064000 {
compatible = "fsl,imx23-pwm";
reg = <0x80064000 0x2000>;
+ clocks = <&clks 30>;
#pwm-cells = <3>;
fsl,pwm-number = <8>;
};
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
deleted file mode 100644
index 74c41e34c3b6..000000000000
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Tegra SoC PWFM controller
-
-Required properties:
-- compatible: Must be:
- - "nvidia,tegra20-pwm": for Tegra20
- - "nvidia,tegra30-pwm", "nvidia,tegra20-pwm": for Tegra30
- - "nvidia,tegra114-pwm", "nvidia,tegra20-pwm": for Tegra114
- - "nvidia,tegra124-pwm", "nvidia,tegra20-pwm": for Tegra124
- - "nvidia,tegra132-pwm", "nvidia,tegra20-pwm": for Tegra132
- - "nvidia,tegra210-pwm", "nvidia,tegra20-pwm": for Tegra210
- - "nvidia,tegra186-pwm": for Tegra186
- - "nvidia,tegra194-pwm": for Tegra194
-- reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-- clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - pwm
-
-Optional properties:
-============================
-In some of the interface like PWM based regulator device, it is required
-to configure the pins differently in different states, especially in suspend
-state of the system. The configuration of pin is provided via the pinctrl
-DT node as detailed in the pinctrl DT binding document
- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-The PWM node will have following optional properties.
-pinctrl-names: Pin state names. Must be "default" and "sleep".
-pinctrl-0: phandle for the default/active state of pin configurations.
-pinctrl-1: phandle for the sleep state of pin configurations.
-
-Example:
-
- pwm: pwm@7000a000 {
- compatible = "nvidia,tegra20-pwm";
- reg = <0x7000a000 0x100>;
- #pwm-cells = <2>;
- clocks = <&tegra_car 17>;
- resets = <&tegra_car 17>;
- reset-names = "pwm";
- };
-
-
-Example with the pin configuration for suspend and resume:
-=========================================================
-Suppose pin PE7 (On Tegra210) interfaced with the regulator device and
-it requires PWM output to be tristated when system enters suspend.
-Following will be DT binding to achieve this:
-
-#include <dt-bindings/pinctrl/pinctrl-tegra.h>
-
- pinmux@700008d4 {
- pwm_active_state: pwm_active_state {
- pe7 {
- nvidia,pins = "pe7";
- nvidia,tristate = <TEGRA_PIN_DISABLE>;
- };
- };
-
- pwm_sleep_state: pwm_sleep_state {
- pe7 {
- nvidia,pins = "pe7";
- nvidia,tristate = <TEGRA_PIN_ENABLE>;
- };
- };
- };
-
- pwm@7000a000 {
- /* Mandatory PWM properties */
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&pwm_active_state>;
- pinctrl-1 = <&pwm_sleep_state>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
new file mode 100644
index 000000000000..41cea4979132
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/nvidia,tegra20-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra PWFM controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-pwm
+ - nvidia,tegra186-pwm
+
+ - items:
+ - enum:
+ - nvidia,tegra30-pwm
+ - nvidia,tegra114-pwm
+ - nvidia,tegra124-pwm
+ - nvidia,tegra132-pwm
+ - nvidia,tegra210-pwm
+ - enum:
+ - nvidia,tegra20-pwm
+
+ - items:
+ - const: nvidia,tegra194-pwm
+ - const: nvidia,tegra186-pwm
+
+ - items:
+ - const: nvidia,tegra234-pwm
+ - const: nvidia,tegra194-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: pwm
+
+ "#pwm-cells":
+ const: 2
+
+ pinctrl-names:
+ items:
+ - const: default
+ - const: sleep
+
+ pinctrl-0:
+ description: configuration for the default/active state
+
+ pinctrl-1:
+ description: configuration for the sleep state
+
+ operating-points-v2: true
+
+ power-domains:
+ items:
+ - description: phandle to the core power domain
+
+allOf:
+ - $ref: pwm.yaml
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+
+ pwm: pwm@7000a000 {
+ compatible = "nvidia,tegra20-pwm";
+ reg = <0x7000a000 0x100>;
+ #pwm-cells = <2>;
+ clocks = <&tegra_car TEGRA20_CLK_PWM>;
+ resets = <&tegra_car 17>;
+ reset-names = "pwm";
+ };
diff --git a/Documentation/devicetree/bindings/pwm/nxp,lpc1850-sct-pwm.yaml b/Documentation/devicetree/bindings/pwm/nxp,lpc1850-sct-pwm.yaml
new file mode 100644
index 000000000000..920e0413d431
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nxp,lpc1850-sct-pwm.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/nxp,lpc1850-sct-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC18xx State Configurable Timer
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-sct-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pwm
+
+ '#pwm-cells':
+ const: 3
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#pwm-cells'
+
+allOf:
+ - $ref: pwm.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ pwm@40000000 {
+ compatible = "nxp,lpc1850-sct-pwm";
+ reg = <0x40000000 0x1000>;
+ clocks = <&ccu1 CLK_CPU_SCT>;
+ clock-names = "pwm";
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/nxp,lpc3220-pwm.yaml b/Documentation/devicetree/bindings/pwm/nxp,lpc3220-pwm.yaml
new file mode 100644
index 000000000000..d8ebb0735c96
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nxp,lpc3220-pwm.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/nxp,lpc3220-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32XX PWM controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,lpc3220-pwm
+ - nxp,lpc3220-motor-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#pwm-cells':
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - '#pwm-cells'
+
+allOf:
+ - $ref: pwm.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@4005c000 {
+ compatible = "nxp,lpc3220-pwm";
+ reg = <0x4005c000 0x4>;
+ #pwm-cells = <3>;
+ };
+
diff --git a/Documentation/devicetree/bindings/pwm/nxp,mc33xs2410.yaml b/Documentation/devicetree/bindings/pwm/nxp,mc33xs2410.yaml
new file mode 100644
index 000000000000..1729fe5c3dfb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nxp,mc33xs2410.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/nxp,mc33xs2410.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: High-side switch MC33XS2410
+
+maintainers:
+ - Dimitri Fedrau <dima.fedrau@gmail.com>
+
+allOf:
+ - $ref: pwm.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: nxp,mc33xs2410
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 10000000
+
+ spi-cpha: true
+
+ spi-cs-setup-delay-ns:
+ minimum: 100
+ default: 100
+
+ spi-cs-hold-delay-ns:
+ minimum: 10
+ default: 10
+
+ spi-cs-inactive-delay-ns:
+ minimum: 300
+ default: 300
+
+ reset-gpios:
+ description:
+ GPIO connected to the active low reset pin.
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ pwm-names:
+ items:
+ - const: di0
+ - const: di1
+ - const: di2
+ - const: di3
+
+ pwms:
+ description:
+ Direct inputs(di0-3) are used to directly turn-on or turn-off the
+ outputs.
+ maxItems: 4
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description:
+ The external clock can be used if the internal clock doesn't meet
+ timing requirements over temperature and voltage operating range.
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Logic supply voltage
+
+ vspi-supply:
+ description:
+ Supply voltage for SPI
+
+ vpwr-supply:
+ description:
+ Power switch supply
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pwm@0 {
+ compatible = "nxp,mc33xs2410";
+ reg = <0x0>;
+ spi-max-frequency = <4000000>;
+ spi-cpha;
+ spi-cs-setup-delay-ns = <100>;
+ spi-cs-hold-delay-ns = <10>;
+ spi-cs-inactive-delay-ns = <300>;
+ reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
+ #pwm-cells = <3>;
+ pwm-names = "di0", "di1", "di2", "di3";
+ pwms = <&pwm0 0 1000000>,
+ <&pwm1 0 1000000>,
+ <&pwm2 0 1000000>,
+ <&pwm3 0 1000000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk_ext_fixed>;
+ vdd-supply = <&reg_3v3>;
+ vspi-supply = <&reg_3v3>;
+ vpwr-supply = <&reg_24v0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
new file mode 100644
index 000000000000..52a59d245cdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/opencores,pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OpenCores PWM controller
+
+maintainers:
+ - William Qiu <william.qiu@starfivetech.com>
+
+description:
+ The OpenCores PTC ip core contains a PWM controller. When operating in PWM
+ mode, the PTC core generates binary signal with user-programmable low and
+ high periods. All PTC counters and registers are 32-bit.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - starfive,jh7100-pwm
+ - starfive,jh7110-pwm
+ - starfive,jh8100-pwm
+ - const: opencores,pwm-v1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm@12490000 {
+ compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
+ reg = <0x12490000 0x10000>;
+ clocks = <&clkgen 181>;
+ resets = <&rstgen 109>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml
new file mode 100644
index 000000000000..cc3ebd4deeb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-amlogic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic PWM
+
+maintainers:
+ - Heiner Kallweit <hkallweit1@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson8b-pwm
+ - amlogic,meson-gxbb-pwm
+ - amlogic,meson-gxbb-ao-pwm
+ - amlogic,meson-axg-ee-pwm
+ - amlogic,meson-axg-ao-pwm
+ - amlogic,meson-g12a-ee-pwm
+ - amlogic,meson-g12a-ao-pwm-ab
+ - amlogic,meson-g12a-ao-pwm-cd
+ deprecated: true
+ - items:
+ - const: amlogic,meson-gx-pwm
+ - const: amlogic,meson-gxbb-pwm
+ deprecated: true
+ - items:
+ - const: amlogic,meson-gx-ao-pwm
+ - const: amlogic,meson-gxbb-ao-pwm
+ deprecated: true
+ - items:
+ - const: amlogic,meson8-pwm
+ - const: amlogic,meson8b-pwm
+ deprecated: true
+ - enum:
+ - amlogic,meson8-pwm-v2
+ - amlogic,meson-s4-pwm
+ - items:
+ - enum:
+ - amlogic,c3-pwm
+ - amlogic,meson-a1-pwm
+ - const: amlogic,meson-s4-pwm
+ - items:
+ - enum:
+ - amlogic,meson8b-pwm-v2
+ - amlogic,meson-gxbb-pwm-v2
+ - amlogic,meson-axg-pwm-v2
+ - amlogic,meson-g12-pwm-v2
+ - const: amlogic,meson8-pwm-v2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 4
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ power-domains:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: pwm.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8-pwm
+ - amlogic,meson8b-pwm
+ - amlogic,meson-gxbb-pwm
+ - amlogic,meson-gxbb-ao-pwm
+ - amlogic,meson-axg-ee-pwm
+ - amlogic,meson-axg-ao-pwm
+ - amlogic,meson-g12a-ee-pwm
+ - amlogic,meson-g12a-ao-pwm-ab
+ - amlogic,meson-g12a-ao-pwm-cd
+ then:
+ # Obsolete historic bindings tied to the driver implementation
+ # The clocks provided here are meant to be matched with the input
+ # known (hard-coded) in the driver and used to select pwm clock
+ # source. Currently, the linux driver ignores this.
+ # This is kept to maintain ABI backward compatibility.
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ oneOf:
+ - items:
+ - enum: [clkin0, clkin1]
+ - items:
+ - const: clkin0
+ - const: clkin1
+
+ # Newer binding where clock describe the actual clock inputs of the pwm
+ # block. These are necessary but some inputs may be grounded.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8-pwm-v2
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ items:
+ - description: input clock 0 of the pwm block
+ - description: input clock 1 of the pwm block
+ - description: input clock 2 of the pwm block
+ - description: input clock 3 of the pwm block
+ clock-names: false
+ required:
+ - clocks
+
+ # Newer IP block take a single input per channel, instead of 4 inputs
+ # for both channels
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson-s4-pwm
+ then:
+ properties:
+ clocks:
+ items:
+ - description: input clock of PWM channel A
+ - description: input clock of PWM channel B
+ clock-names: false
+ required:
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson-a1-pwm
+ then:
+ required:
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm@8550 {
+ compatible = "amlogic,meson-gxbb-pwm";
+ reg = <0x08550 0x10>;
+ clocks = <&xtal>, <&xtal>;
+ clock-names = "clkin0", "clkin1";
+ #pwm-cells = <3>;
+ };
+ - |
+ pwm@2000 {
+ compatible = "amlogic,meson8-pwm-v2";
+ reg = <0x1000 0x10>;
+ clocks = <&xtal>, <0>, <&fdiv4>, <&fdiv5>;
+ #pwm-cells = <3>;
+ };
+ - |
+ pwm@1000 {
+ compatible = "amlogic,meson-s4-pwm";
+ reg = <0x1000 0x10>;
+ clocks = <&pwm_src_a>, <&pwm_src_b>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
deleted file mode 100644
index f5753b3f79df..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-BCM2835 PWM controller (Raspberry Pi controller)
-
-Required properties:
-- compatible: should be "brcm,bcm2835-pwm"
-- reg: physical base address and length of the controller's registers
-- clocks: This clock defines the base clock frequency of the PWM hardware
- system, the period and the duty_cycle of the PWM signal is a multiple of
- the base period.
-- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of
- the cells format.
-
-Examples:
-
-pwm@2020c000 {
- compatible = "brcm,bcm2835-pwm";
- reg = <0x2020c000 0x28>;
- clocks = <&clk_pwm>;
- #pwm-cells = <3>;
-};
-
-clocks {
- ....
- clk_pwm: pwm {
- compatible = "fixed-clock";
- reg = <3>;
- #clock-cells = <0>;
- clock-frequency = <9200000>;
- };
- ....
-};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml
new file mode 100644
index 000000000000..9dc25f38fb94
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-bcm2835.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 PWM controller (Raspberry Pi controller)
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: brcm,bcm2835-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm@2020c000 {
+ compatible = "brcm,bcm2835-pwm";
+ reg = <0x2020c000 0x28>;
+ clocks = <&clk_pwm>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt
deleted file mode 100644
index f01e993a498a..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Berlin PWM controller
-
-Required properties:
-- compatible: should be "marvell,berlin-pwm"
-- reg: physical base address and length of the controller's registers
-- clocks: phandle to the input clock
-- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of
- the cells format.
-
-Example:
-
-pwm: pwm@f7f20000 {
- compatible = "marvell,berlin-pwm";
- reg = <0xf7f20000 0x40>;
- clocks = <&chip_clk CLKID_CFG>;
- #pwm-cells = <3>;
-}
diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
deleted file mode 100644
index 36532cd5ab25..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Freescale FlexTimer Module (FTM) PWM controller
-
-The same FTM PWM device can have a different endianness on different SoCs. The
-device tree provides a property to describing this so that an operating system
-device driver can handle all variants of the device. Refer to the table below
-for the endianness of the FTM PWM block as integrated into the existing SoCs:
-
- SoC | FTM-PWM endianness
- --------+-------------------
- Vybrid | LE
- LS1 | BE
- LS2 | LE
-
-Please see ../regmap/regmap.txt for more detail about how to specify endian
-modes in device tree.
-
-
-Required properties:
-- compatible : should be "fsl,<soc>-ftm-pwm" and one of the following
- compatible strings:
- - "fsl,vf610-ftm-pwm" for PWM compatible with the one integrated on VF610
- - "fsl,imx8qm-ftm-pwm" for PWM compatible with the one integrated on i.MX8QM
-- reg: Physical base address and length of the controller's registers
-- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of
- the cells format.
-- clock-names: Should include the following module clock source entries:
- "ftm_sys" (module clock, also can be used as counter clock),
- "ftm_ext" (external counter clock),
- "ftm_fix" (fixed counter clock),
- "ftm_cnt_clk_en" (external and fixed counter clock enable/disable).
-- clocks: Must contain a phandle and clock specifier for each entry in
- clock-names, please see clock/clock-bindings.txt for details of the property
- values.
-- pinctrl-names: Must contain a "default" entry.
-- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
- See pinctrl/pinctrl-bindings.txt for details of the property values.
-- big-endian: Boolean property, required if the FTM PWM registers use a big-
- endian rather than little-endian layout.
-
-Example:
-
-pwm0: pwm@40038000 {
- compatible = "fsl,vf610-ftm-pwm";
- reg = <0x40038000 0x1000>;
- #pwm-cells = <3>;
- clock-names = "ftm_sys", "ftm_ext",
- "ftm_fix", "ftm_cnt_clk_en";
- clocks = <&clks VF610_CLK_FTM0>,
- <&clks VF610_CLK_FTM0_EXT_SEL>,
- <&clks VF610_CLK_FTM0_FIX_SEL>,
- <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pwm0_1>;
- big-endian;
-};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-gpio.yaml b/Documentation/devicetree/bindings/pwm/pwm-gpio.yaml
new file mode 100644
index 000000000000..1576c193f2ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-gpio.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic software PWM for modulating GPIOs
+
+maintainers:
+ - Stefan Wahren <wahrenst@gmx.net>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: pwm-gpio
+
+ "#pwm-cells":
+ const: 3
+ description:
+ See pwm.yaml in this directory for a description of the cells format.
+ The first cell which represents the PWM instance number must always
+ be zero.
+
+ gpios:
+ description:
+ GPIO to be modulated
+ maxItems: 1
+
+required:
+ - compatible
+ - "#pwm-cells"
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ pwm {
+ #pwm-cells = <3>;
+ compatible = "pwm-gpio";
+ gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
deleted file mode 100644
index 554c96b6d0c3..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-MediaTek PWM controller
-
-Required properties:
- - compatible: should be "mediatek,<name>-pwm":
- - "mediatek,mt2712-pwm": found on mt2712 SoC.
- - "mediatek,mt6795-pwm": found on mt6795 SoC.
- - "mediatek,mt7622-pwm": found on mt7622 SoC.
- - "mediatek,mt7623-pwm": found on mt7623 SoC.
- - "mediatek,mt7628-pwm": found on mt7628 SoC.
- - "mediatek,mt7629-pwm": found on mt7629 SoC.
- - "mediatek,mt8183-pwm": found on mt8183 SoC.
- - "mediatek,mt8195-pwm", "mediatek,mt8183-pwm": found on mt8195 SoC.
- - "mediatek,mt8365-pwm": found on mt8365 SoC.
- - "mediatek,mt8516-pwm": found on mt8516 SoC.
- - reg: physical base address and length of the controller's registers.
- - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of
- the cell format.
- - clocks: phandle and clock specifier of the PWM reference clock.
- - clock-names: must contain the following, except for MT7628 which
- has no clocks
- - "top": the top clock generator
- - "main": clock used by the PWM core
- - "pwm1-3": the three per PWM clocks for mt8365
- - "pwm1-8": the eight per PWM clocks for mt2712
- - "pwm1-6": the six per PWM clocks for mt7622
- - "pwm1-5": the five per PWM clocks for mt7623
- - "pwm1" : the PWM1 clock for mt7629
- - pinctrl-names: Must contain a "default" entry.
- - pinctrl-0: One property must exist for each entry in pinctrl-names.
- See pinctrl/pinctrl-bindings.txt for details of the property values.
-
-Optional properties:
-- assigned-clocks: Reference to the PWM clock entries.
-- assigned-clock-parents: The phandle of the parent clock of PWM clock.
-
-Example:
- pwm0: pwm@11006000 {
- compatible = "mediatek,mt7623-pwm";
- reg = <0 0x11006000 0 0x1000>;
- #pwm-cells = <2>;
- clocks = <&topckgen CLK_TOP_PWM_SEL>,
- <&pericfg CLK_PERI_PWM>,
- <&pericfg CLK_PERI_PWM1>,
- <&pericfg CLK_PERI_PWM2>,
- <&pericfg CLK_PERI_PWM3>,
- <&pericfg CLK_PERI_PWM4>,
- <&pericfg CLK_PERI_PWM5>;
- clock-names = "top", "main", "pwm1", "pwm2",
- "pwm3", "pwm4", "pwm5";
- pinctrl-names = "default";
- pinctrl-0 = <&pwm0_pins>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
deleted file mode 100644
index bd02b0a1496f..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-meson.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Amlogic Meson PWM Controller
-============================
-
-Required properties:
-- compatible: Shall contain "amlogic,meson8b-pwm"
- or "amlogic,meson-gxbb-pwm"
- or "amlogic,meson-gxbb-ao-pwm"
- or "amlogic,meson-axg-ee-pwm"
- or "amlogic,meson-axg-ao-pwm"
- or "amlogic,meson-g12a-ee-pwm"
- or "amlogic,meson-g12a-ao-pwm-ab"
- or "amlogic,meson-g12a-ao-pwm-cd"
-- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of
- the cells format.
-
-Optional properties:
-- clocks: Could contain one or two parents clocks phandle for each of the two
- PWM channels.
-- clock-names: Could contain at least the "clkin0" and/or "clkin1" names.
-
-Example:
-
- pwm_ab: pwm@8550 {
- compatible = "amlogic,meson-gxbb-pwm";
- reg = <0x0 0x08550 0x0 0x10>;
- #pwm-cells = <3>;
- clocks = <&xtal>, <&xtal>;
- clock-names = "clkin0", "clkin1";
- }
diff --git a/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
new file mode 100644
index 000000000000..3b40e271fe8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-nexus-node.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Nexus node properties
+
+description: >
+ Platforms can have a standardized connector/expansion slot that exposes PWMs
+ signals to expansion boards.
+
+ A nexus node allows to remap a phandle list in a consumer node through a
+ connector node in a generic way. With this remapping, the consumer node needs
+ to know only about the nexus node. Resources behind the nexus node are
+ decoupled by the nexus node itself.
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+select: true
+
+properties:
+ '#pwm-cells': true
+
+ pwm-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+ pwm-map-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ pwm-map-pass-thru:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+dependentRequired:
+ pwm-map: ['#pwm-cells']
+ pwm-map-mask: [ pwm-map ]
+ pwm-map-pass-thru: [ pwm-map ]
+
+additionalProperties: true
+
+examples:
+ - |
+ pwm1: pwm@100 {
+ reg = <0x100 0x10>;
+ #pwm-cells = <3>;
+ };
+
+ pwm2: pwm@200 {
+ reg = <0x200 0x10>;
+ #pwm-cells = <3>;
+ };
+
+ connector: connector {
+ #pwm-cells = <3>;
+ pwm-map = <0 0 0 &pwm1 1 0 0>,
+ <1 0 0 &pwm2 4 0 0>,
+ <2 0 0 &pwm1 3 0 0>;
+ pwm-map-mask = <0xffffffff 0x0 0x0>;
+ pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
+ };
+
+ device {
+ pwms = <&connector 1 57000 0>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
deleted file mode 100644
index 25ecfe14c698..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* OMAP PWM for dual-mode timers
-
-Required properties:
-- compatible: Shall contain "ti,omap-dmtimer-pwm".
-- ti,timers: phandle to PWM capable OMAP timer. See timer/ti,timer-dm.yaml for info
- about these timers.
-- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of
- the cells format.
-
-Optional properties:
-- ti,prescaler: Should be a value between 0 and 7, see the timers datasheet
-- ti,clock-source: Set dmtimer parent clock, values between 0 and 2:
- - 0x00 - high-frequency system clock (timer_sys_ck)
- - 0x01 - 32-kHz always-on clock (timer_32k_ck)
- - 0x02 - external clock (timer_ext_ck, OMAP2 only)
-
-Example:
- pwm9: dmtimer-pwm@9 {
- compatible = "ti,omap-dmtimer-pwm";
- ti,timers = <&timer9>;
- #pwm-cells = <3>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
index a336ff9364a9..c8cdfb723336 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -21,6 +21,7 @@ properties:
- const: rockchip,rk2928-pwm
- items:
- enum:
+ - rockchip,rk3128-pwm
- rockchip,rk3368-pwm
- rockchip,rk3399-pwm
- rockchip,rv1108-pwm
@@ -29,7 +30,11 @@ properties:
- enum:
- rockchip,px30-pwm
- rockchip,rk3308-pwm
+ - rockchip,rk3528-pwm
+ - rockchip,rk3562-pwm
- rockchip,rk3568-pwm
+ - rockchip,rk3588-pwm
+ - rockchip,rv1126-pwm
- const: rockchip,rk3328-pwm
reg:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
index fe603fb1b2cc..97acbdec39f1 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
@@ -20,12 +20,22 @@ description: |+
properties:
compatible:
- enum:
- - samsung,s3c2410-pwm # 16-bit, S3C24xx
- - samsung,s3c6400-pwm # 32-bit, S3C64xx
- - samsung,s5p6440-pwm # 32-bit, S5P64x0
- - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs
- - samsung,exynos4210-pwm # 32-bit, Exynos
+ oneOf:
+ - enum:
+ - samsung,s3c2410-pwm # 16-bit, S3C24xx
+ - samsung,s3c6400-pwm # 32-bit, S3C64xx
+ - samsung,s5p6440-pwm # 32-bit, S5P64x0
+ - samsung,s5pc100-pwm # 32-bit, S5PC100, S5PV210, Exynos4210 rev0 SoCs
+ - samsung,exynos4210-pwm # 32-bit, Exynos
+ - items:
+ - enum:
+ - samsung,exynos5433-pwm
+ - samsung,exynos7-pwm
+ - samsung,exynos8890-pwm
+ - samsung,exynosautov9-pwm
+ - samsung,exynosautov920-pwm
+ - tesla,fsd-pwm
+ - const: samsung,exynos4210-pwm
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
index 605c1766dba8..bae993128981 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
@@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: SiFive PWM controller
maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- Paul Walmsley <paul.walmsley@sifive.com>
description:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sprd.txt b/Documentation/devicetree/bindings/pwm/pwm-sprd.txt
deleted file mode 100644
index 87b206fd0618..000000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-sprd.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Spreadtrum PWM controller
-
-Spreadtrum SoCs PWM controller provides 4 PWM channels.
-
-Required properties:
-- compatible : Should be "sprd,ums512-pwm".
-- reg: Physical base address and length of the controller's registers.
-- clocks: The phandle and specifier referencing the controller's clocks.
-- clock-names: Should contain following entries:
- "pwmn": used to derive the functional clock for PWM channel n (n range: 0 ~ 3).
- "enablen": for PWM channel n enable clock (n range: 0 ~ 3).
-- #pwm-cells: Should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-
-Optional properties:
-- assigned-clocks: Reference to the PWM clock entries.
-- assigned-clock-parents: The phandle of the parent clock of PWM clock.
-
-Example:
- pwms: pwm@32260000 {
- compatible = "sprd,ums512-pwm";
- reg = <0 0x32260000 0 0x10000>;
- clock-names = "pwm0", "enable0",
- "pwm1", "enable1",
- "pwm2", "enable2",
- "pwm3", "enable3";
- clocks = <&aon_clk CLK_PWM0>, <&aonapb_gate CLK_PWM0_EB>,
- <&aon_clk CLK_PWM1>, <&aonapb_gate CLK_PWM1_EB>,
- <&aon_clk CLK_PWM2>, <&aonapb_gate CLK_PWM2_EB>,
- <&aon_clk CLK_PWM3>, <&aonapb_gate CLK_PWM3_EB>;
- assigned-clocks = <&aon_clk CLK_PWM0>,
- <&aon_clk CLK_PWM1>,
- <&aon_clk CLK_PWM2>,
- <&aon_clk CLK_PWM3>;
- assigned-clock-parents = <&ext_26m>,
- <&ext_26m>,
- <&ext_26m>,
- <&ext_26m>;
- #pwm-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml
index 3c01f85029e5..f2206ec3c7c4 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm.yaml
@@ -13,11 +13,13 @@ select: false
properties:
$nodename:
- pattern: "^pwm(@.*|-[0-9a-f])*$"
+ pattern: "^pwm(@.*|-([0-9]|[1-9][0-9]+))?$"
"#pwm-cells":
- description:
- Number of cells in a PWM specifier.
+ description: |
+ Number of cells in a PWM specifier. Typically the cells represent, in
+ order: the chip-relative PWM number, the PWM period in nanoseconds and
+ optionally a number of flags (defined in <dt-bindings/pwm/pwm.h>).
required:
- "#pwm-cells"
diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
deleted file mode 100644
index 5ae9f1e3c338..000000000000
--- a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Marvell PWM controller
-
-Required properties:
-- compatible: should be one or more of:
- - "marvell,pxa250-pwm"
- - "marvell,pxa270-pwm"
- - "marvell,pxa168-pwm"
- - "marvell,pxa910-pwm"
-- reg: Physical base address and length of the registers used by the PWM channel
- Note that one device instance must be created for each PWM that is used, so the
- length covers only the register window for one PWM output, not that of the
- entire PWM controller. Currently length is 0x10 for all supported devices.
-- #pwm-cells: Should be 1. This cell is used to specify the period in
- nanoseconds.
-
-Example PWM device node:
-
-pwm0: pwm@40b00000 {
- compatible = "marvell,pxa250-pwm";
- reg = <0x40b00000 0x10>;
- #pwm-cells = <1>;
-};
-
-Example PWM client node:
-
-backlight {
- compatible = "pwm-backlight";
- pwms = <&pwm0 5000000>;
- ...
-}
diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
index 1c94acbc2b4a..2fe1992e2908 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
+++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
@@ -35,6 +35,9 @@ properties:
- renesas,pwm-r8a77980 # R-Car V3H
- renesas,pwm-r8a77990 # R-Car E3
- renesas,pwm-r8a77995 # R-Car D3
+ - renesas,pwm-r8a779a0 # R-Car V3U
+ - renesas,pwm-r8a779g0 # R-Car V4H
+ - renesas,pwm-r8a779h0 # R-Car V4M
- const: renesas,pwm-rcar
reg:
diff --git a/Documentation/devicetree/bindings/pwm/renesas,rzg2l-gpt.yaml b/Documentation/devicetree/bindings/pwm/renesas,rzg2l-gpt.yaml
new file mode 100644
index 000000000000..13b807765a30
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/renesas,rzg2l-gpt.yaml
@@ -0,0 +1,378 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/renesas,rzg2l-gpt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L General PWM Timer (GPT)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ RZ/G2L General PWM Timer (GPT) composed of 8 channels with 32-bit timer
+ (GPT32E). It supports the following functions
+ * 32 bits x 8 channels.
+ * Up-counting or down-counting (saw waves) or up/down-counting
+ (triangle waves) for each counter.
+ * Clock sources independently selectable for each channel.
+ * Two I/O pins per channel.
+ * Two output compare/input capture registers per channel.
+ * For the two output compare/input capture registers of each channel,
+ four registers are provided as buffer registers and are capable of
+ operating as comparison registers when buffering is not in use.
+ * In output compare operation, buffer switching can be at crests or
+ troughs, enabling the generation of laterally asymmetric PWM waveforms.
+ * Registers for setting up frame cycles in each channel (with capability
+ for generating interrupts at overflow or underflow)
+ * Generation of dead times in PWM operation.
+ * Synchronous starting, stopping and clearing counters for arbitrary
+ channels.
+ * Starting, stopping, clearing and up/down counters in response to input
+ level comparison.
+ * Starting, clearing, stopping and up/down counters in response to a
+ maximum of four external triggers.
+ * Output pin disable function by dead time error and detected
+ short-circuits between output pins.
+ * A/D converter start triggers can be generated (GPT32E0 to GPT32E3)
+ * Enables the noise filter for input capture and external trigger
+ operation.
+
+ The below pwm channels are supported.
+ pwm0 - GPT32E0.GTIOC0A channel
+ pwm1 - GPT32E0.GTIOC0B channel
+ pwm2 - GPT32E1.GTIOC1A channel
+ pwm3 - GPT32E1.GTIOC1B channel
+ pwm4 - GPT32E2.GTIOC2A channel
+ pwm5 - GPT32E2.GTIOC2B channel
+ pwm6 - GPT32E3.GTIOC3A channel
+ pwm7 - GPT32E3.GTIOC3B channel
+ pwm8 - GPT32E4.GTIOC4A channel
+ pwm9 - GPT32E4.GTIOC4B channel
+ pwm10 - GPT32E5.GTIOC5A channel
+ pwm11 - GPT32E5.GTIOC5B channel
+ pwm12 - GPT32E6.GTIOC6A channel
+ pwm13 - GPT32E6.GTIOC6B channel
+ pwm14 - GPT32E7.GTIOC7A channel
+ pwm15 - GPT32E7.GTIOC7B channel
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a07g044-gpt # RZ/G2{L,LC}
+ - renesas,r9a07g054-gpt # RZ/V2L
+ - const: renesas,rzg2l-gpt
+
+ reg:
+ maxItems: 1
+
+ '#pwm-cells':
+ const: 3
+
+ interrupts:
+ items:
+ - description: GPT32E0.GTCCRA input capture/compare match
+ - description: GPT32E0.GTCCRB input capture/compare
+ - description: GPT32E0.GTCCRC compare match
+ - description: GPT32E0.GTCCRD compare match
+ - description: GPT32E0.GTCCRE compare match
+ - description: GPT32E0.GTCCRF compare match
+ - description: GPT32E0.GTADTRA compare match
+ - description: GPT32E0.GTADTRB compare match
+ - description: GPT32E0.GTCNT overflow/GTPR compare match
+ - description: GPT32E0.GTCNT underflow
+ - description: GPT32E1.GTCCRA input capture/compare match
+ - description: GPT32E1.GTCCRB input capture/compare
+ - description: GPT32E1.GTCCRC compare match
+ - description: GPT32E1.GTCCRD compare match
+ - description: GPT32E1.GTCCRE compare match
+ - description: GPT32E1.GTCCRF compare match
+ - description: GPT32E1.GTADTRA compare match
+ - description: GPT32E1.GTADTRB compare match
+ - description: GPT32E1.GTCNT overflow/GTPR compare match
+ - description: GPT32E1.GTCNT underflow
+ - description: GPT32E2.GTCCRA input capture/compare match
+ - description: GPT32E2.GTCCRB input capture/compare
+ - description: GPT32E2.GTCCRC compare match
+ - description: GPT32E2.GTCCRD compare match
+ - description: GPT32E2.GTCCRE compare match
+ - description: GPT32E2.GTCCRF compare match
+ - description: GPT32E2.GTADTRA compare match
+ - description: GPT32E2.GTADTRB compare match
+ - description: GPT32E2.GTCNT overflow/GTPR compare match
+ - description: GPT32E2.GTCNT underflow
+ - description: GPT32E3.GTCCRA input capture/compare match
+ - description: GPT32E3.GTCCRB input capture/compare
+ - description: GPT32E3.GTCCRC compare match
+ - description: GPT32E3.GTCCRD compare match
+ - description: GPT32E3.GTCCRE compare match
+ - description: GPT32E3.GTCCRF compare match
+ - description: GPT32E3.GTADTRA compare match
+ - description: GPT32E3.GTADTRB compare match
+ - description: GPT32E3.GTCNT overflow/GTPR compare match
+ - description: GPT32E3.GTCNT underflow
+ - description: GPT32E4.GTCCRA input capture/compare match
+ - description: GPT32E4.GTCCRB input capture/compare
+ - description: GPT32E4.GTCCRC compare match
+ - description: GPT32E4.GTCCRD compare match
+ - description: GPT32E4.GTCCRE compare match
+ - description: GPT32E4.GTCCRF compare match
+ - description: GPT32E4.GTADTRA compare match
+ - description: GPT32E4.GTADTRB compare match
+ - description: GPT32E4.GTCNT overflow/GTPR compare match
+ - description: GPT32E4.GTCNT underflow
+ - description: GPT32E5.GTCCRA input capture/compare match
+ - description: GPT32E5.GTCCRB input capture/compare
+ - description: GPT32E5.GTCCRC compare match
+ - description: GPT32E5.GTCCRD compare match
+ - description: GPT32E5.GTCCRE compare match
+ - description: GPT32E5.GTCCRF compare match
+ - description: GPT32E5.GTADTRA compare match
+ - description: GPT32E5.GTADTRB compare match
+ - description: GPT32E5.GTCNT overflow/GTPR compare match
+ - description: GPT32E5.GTCNT underflow
+ - description: GPT32E6.GTCCRA input capture/compare match
+ - description: GPT32E6.GTCCRB input capture/compare
+ - description: GPT32E6.GTCCRC compare match
+ - description: GPT32E6.GTCCRD compare match
+ - description: GPT32E6.GTCCRE compare match
+ - description: GPT32E6.GTCCRF compare match
+ - description: GPT32E6.GTADTRA compare match
+ - description: GPT32E6.GTADTRB compare match
+ - description: GPT32E6.GTCNT overflow/GTPR compare match
+ - description: GPT32E6.GTCNT underflow
+ - description: GPT32E7.GTCCRA input capture/compare match
+ - description: GPT32E7.GTCCRB input capture/compare
+ - description: GPT32E7.GTCCRC compare match
+ - description: GPT32E7.GTCCRD compare match
+ - description: GPT32E7.GTCCRE compare match
+ - description: GPT32E7.GTCCRF compare match
+ - description: GPT32E7.GTADTRA compare match
+ - description: GPT32E7.GTADTRB compare match
+ - description: GPT32E7.GTCNT overflow/GTPR compare match
+ - description: GPT32E7.GTCNT underflow
+
+ interrupt-names:
+ items:
+ - const: ccmpa0
+ - const: ccmpb0
+ - const: cmpc0
+ - const: cmpd0
+ - const: cmpe0
+ - const: cmpf0
+ - const: adtrga0
+ - const: adtrgb0
+ - const: ovf0
+ - const: unf0
+ - const: ccmpa1
+ - const: ccmpb1
+ - const: cmpc1
+ - const: cmpd1
+ - const: cmpe1
+ - const: cmpf1
+ - const: adtrga1
+ - const: adtrgb1
+ - const: ovf1
+ - const: unf1
+ - const: ccmpa2
+ - const: ccmpb2
+ - const: cmpc2
+ - const: cmpd2
+ - const: cmpe2
+ - const: cmpf2
+ - const: adtrga2
+ - const: adtrgb2
+ - const: ovf2
+ - const: unf2
+ - const: ccmpa3
+ - const: ccmpb3
+ - const: cmpc3
+ - const: cmpd3
+ - const: cmpe3
+ - const: cmpf3
+ - const: adtrga3
+ - const: adtrgb3
+ - const: ovf3
+ - const: unf3
+ - const: ccmpa4
+ - const: ccmpb4
+ - const: cmpc4
+ - const: cmpd4
+ - const: cmpe4
+ - const: cmpf4
+ - const: adtrga4
+ - const: adtrgb4
+ - const: ovf4
+ - const: unf4
+ - const: ccmpa5
+ - const: ccmpb5
+ - const: cmpc5
+ - const: cmpd5
+ - const: cmpe5
+ - const: cmpf5
+ - const: adtrga5
+ - const: adtrgb5
+ - const: ovf5
+ - const: unf5
+ - const: ccmpa6
+ - const: ccmpb6
+ - const: cmpc6
+ - const: cmpd6
+ - const: cmpe6
+ - const: cmpf6
+ - const: adtrga6
+ - const: adtrgb6
+ - const: ovf6
+ - const: unf6
+ - const: ccmpa7
+ - const: ccmpb7
+ - const: cmpc7
+ - const: cmpd7
+ - const: cmpe7
+ - const: cmpf7
+ - const: adtrga7
+ - const: adtrgb7
+ - const: ovf7
+ - const: unf7
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - power-domains
+ - resets
+
+allOf:
+ - $ref: pwm.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpt: pwm@10048000 {
+ compatible = "renesas,r9a07g044-gpt", "renesas,rzg2l-gpt";
+ reg = <0x10048000 0x800>;
+ interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 219 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 220 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 221 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 222 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 223 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 224 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 225 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 226 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 227 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 231 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 232 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 233 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 234 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 235 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 236 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 237 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 238 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 239 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 240 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 244 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 245 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 246 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 247 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 248 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 249 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 250 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 251 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 252 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 253 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 257 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 258 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 259 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 260 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 261 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 262 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 263 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 264 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 265 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 270 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 271 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 272 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 273 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 274 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 275 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 276 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 278 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 279 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 283 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 284 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 285 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 286 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 287 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 288 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 289 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 290 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 291 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 292 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 296 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 297 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 298 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 299 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 300 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 301 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 302 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 303 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 304 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 305 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 309 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 310 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 311 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 312 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 313 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 314 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 315 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 316 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 317 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 318 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ccmpa0", "ccmpb0", "cmpc0", "cmpd0",
+ "cmpe0", "cmpf0", "adtrga0", "adtrgb0",
+ "ovf0", "unf0",
+ "ccmpa1", "ccmpb1", "cmpc1", "cmpd1",
+ "cmpe1", "cmpf1", "adtrga1", "adtrgb1",
+ "ovf1", "unf1",
+ "ccmpa2", "ccmpb2", "cmpc2", "cmpd2",
+ "cmpe2", "cmpf2", "adtrga2", "adtrgb2",
+ "ovf2", "unf2",
+ "ccmpa3", "ccmpb3", "cmpc3", "cmpd3",
+ "cmpe3", "cmpf3", "adtrga3", "adtrgb3",
+ "ovf3", "unf3",
+ "ccmpa4", "ccmpb4", "cmpc4", "cmpd4",
+ "cmpe4", "cmpf4", "adtrga4", "adtrgb4",
+ "ovf4", "unf4",
+ "ccmpa5", "ccmpb5", "cmpc5", "cmpd5",
+ "cmpe5", "cmpf5", "adtrga5", "adtrgb5",
+ "ovf5", "unf5",
+ "ccmpa6", "ccmpb6", "cmpc6", "cmpd6",
+ "cmpe6", "cmpf6", "adtrga6", "adtrgb6",
+ "ovf6", "unf6",
+ "ccmpa7", "ccmpb7", "cmpc7", "cmpd7",
+ "cmpe7", "cmpf7", "adtrga7", "adtrgb7",
+ "ovf7", "unf7";
+ clocks = <&cpg CPG_MOD R9A07G044_GPT_PCLK>;
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_GPT_RST_C>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
index c6b2ab56b7fe..f85ee5d20ccb 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
@@ -9,15 +9,6 @@ title: Renesas R-Car Timer Pulse Unit PWM Controller
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-select:
- properties:
- compatible:
- contains:
- const: renesas,tpu
- required:
- - compatible
- - '#pwm-cells'
-
properties:
compatible:
items:
@@ -40,6 +31,8 @@ properties:
- renesas,tpu-r8a77970 # R-Car V3M
- renesas,tpu-r8a77980 # R-Car V3H
- renesas,tpu-r8a779a0 # R-Car V3U
+ - renesas,tpu-r8a779g0 # R-Car V4H
+ - renesas,tpu-r8a779h0 # R-Car V4M
- const: renesas,tpu
reg:
diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
new file mode 100644
index 000000000000..7523a89a1773
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/snps,dw-apb-timers-pwm2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DW-APB timers PWM controller
+
+maintainers:
+ - Ben Dooks <ben.dooks@sifive.com>
+
+description:
+ This describes the DesignWare APB timers module when used in the PWM
+ mode. The IP core can be generated with various options which can
+ control the functionality, the number of PWMs available and other
+ internal controls the designer requires.
+
+ The IP block has a version register so this can be used for detection
+ instead of having to encode the IP version number in the device tree
+ compatible.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: snps,dw-apb-timers-pwm2
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ items:
+ - description: Interface bus clock
+ - description: PWM reference clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: timer
+
+ snps,pwm-number:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The number of PWM channels configured for this instance
+ enum: [1, 2, 3, 4, 5, 6, 7, 8]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm: pwm@180000 {
+ compatible = "snps,dw-apb-timers-pwm2";
+ reg = <0x180000 0x200>;
+ #pwm-cells = <3>;
+ clocks = <&bus>, <&timer>;
+ clock-names = "bus", "timer";
+ };
diff --git a/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml b/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml
new file mode 100644
index 000000000000..e0e91aa237ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/sophgo,sg2042-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 PWM controller
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+description:
+ This controller contains 4 channels which can generate PWM waveforms.
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ enum:
+ - sophgo,sg2042-pwm
+ - sophgo,sg2044-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: apb
+
+ resets:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/sophgo,sg2042-reset.h>
+
+ pwm@7f006000 {
+ compatible = "sophgo,sg2042-pwm";
+ reg = <0x7f006000 0x1000>;
+ #pwm-cells = <3>;
+ clocks = <&clock 67>;
+ clock-names = "apb";
+ resets = <&rstgen RST_PWM>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml b/Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml
new file mode 100644
index 000000000000..c806b6768087
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/sprd,ums512-pwm.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/sprd,ums512-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum/Unisoc UMS512 PWM Controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang@linux.alibaba.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,ums512-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 8
+
+ clock-names:
+ items:
+ - const: pwm0
+ - const: enable0
+ - const: pwm1
+ - const: enable1
+ - const: pwm2
+ - const: enable2
+ - const: pwm3
+ - const: enable3
+
+ '#pwm-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: pwm.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sprd,ums512-clk.h>
+
+ pwm@32260000 {
+ compatible = "sprd,ums512-pwm";
+ reg = <0x32260000 0x10000>;
+ clocks = <&aon_clk CLK_PWM0>, <&aonapb_gate CLK_PWM0_EB>,
+ <&aon_clk CLK_PWM1>, <&aonapb_gate CLK_PWM1_EB>,
+ <&aon_clk CLK_PWM2>, <&aonapb_gate CLK_PWM2_EB>,
+ <&aon_clk CLK_PWM3>, <&aonapb_gate CLK_PWM3_EB>;
+ clock-names = "pwm0", "enable0",
+ "pwm1", "enable1",
+ "pwm2", "enable2",
+ "pwm3", "enable3";
+ #pwm-cells = <2>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/pwm/thead,th1520-pwm.yaml b/Documentation/devicetree/bindings/pwm/thead,th1520-pwm.yaml
new file mode 100644
index 000000000000..855aec59ac53
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/thead,th1520-pwm.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/thead,th1520-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD TH1520 PWM controller
+
+maintainers:
+ - Michal Wilczynski <m.wilczynski@samsung.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: thead,th1520-pwm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SoC PWM clock
+
+ "#pwm-cells":
+ const: 3
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/thead,th1520-clk-ap.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pwm@ffec01c000 {
+ compatible = "thead,th1520-pwm";
+ reg = <0xff 0xec01c000 0x0 0x4000>;
+ clocks = <&clk CLK_PWM>;
+ #pwm-cells = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pwm/ti,omap-dmtimer-pwm.yaml b/Documentation/devicetree/bindings/pwm/ti,omap-dmtimer-pwm.yaml
new file mode 100644
index 000000000000..1e8e094aad74
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,omap-dmtimer-pwm.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/ti,omap-dmtimer-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI dual mode timer PWM controller
+
+maintainers:
+ - Tony Lindgren <tony@atomide.com>
+
+description:
+ TI dual mode timer instances have an IO pin for PWM capability
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ const: ti,omap-dmtimer-pwm
+
+ "#pwm-cells":
+ const: 3
+
+ ti,timers:
+ description: Timer instance phandle for the PWM
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ ti,prescaler:
+ description: |
+ Legacy clock prescaler for timer. The timer counter is prescaled
+ with 2^n where n is the prescaler.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+ deprecated: true
+
+ ti,clock-source:
+ description: |
+ Legacy clock for timer, please use assigned-clocks instead.
+ 0x00 - high-frequency system clock (timer_sys_ck)
+ 0x01 - 32-kHz always-on clock (timer_32k_ck)
+ 0x02 - external clock (timer_ext_ck, OMAP2 only)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2 ]
+ deprecated: true
+
+required:
+ - compatible
+ - ti,timers
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm9: pwm {
+ compatible = "ti,omap-dmtimer-pwm";
+ ti,timers = <&timer9>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
deleted file mode 100644
index d97ca1964e94..000000000000
--- a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Texas Instruments TWL series PWM drivers
-
-Supported PWMs:
-On TWL4030 series: PWM1 and PWM2
-On TWL6030 series: PWM0 and PWM1
-
-Required properties:
-- compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm"
-- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-
-Example:
-
-twl_pwm: pwm {
- compatible = "ti,twl6030-pwm";
- #pwm-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
deleted file mode 100644
index 31ca1b032ef0..000000000000
--- a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Texas Instruments TWL series PWM drivers connected to LED terminals
-
-Supported PWMs:
-On TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
-On TWL6030 series: LED PWM (mainly used as charging indicator LED)
-
-Required properties:
-- compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled"
-- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-
-Example:
-
-twl_pwmled: pwmled {
- compatible = "ti,twl6030-pwmled";
- #pwm-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml b/Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml
new file mode 100644
index 000000000000..d9146ad715ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/via,vt8500-pwm.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/via,vt8500-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: via,vt8500-pwm
+
+ reg:
+ maxItems: 1
+
+ '#pwm-cells':
+ const: 3
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pwm1: pwm@d8220000 {
+ compatible = "via,vt8500-pwm";
+ reg = <0xd8220000 0x1000>;
+ #pwm-cells = <3>;
+ clocks = <&clkpwm>;
+ };
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
deleted file mode 100644
index 4fba93ce1985..000000000000
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
-
-Required properties:
-- compatible: should be "via,vt8500-pwm"
-- reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 3. See pwm.yaml in this directory for a description of
- the cells format. The only third cell flag supported by this binding is
- PWM_POLARITY_INVERTED.
-- clocks: phandle to the PWM source clock
-
-Example:
-
-pwm1: pwm@d8220000 {
- #pwm-cells = <3>;
- compatible = "via,vt8500-pwm";
- reg = <0xd8220000 0x1000>;
- clocks = <&clkpwm>;
-};
diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
deleted file mode 100644
index b9f58e480349..000000000000
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-ACT88xx regulators
--------------------
-
-Required properties:
-- compatible: "active-semi,act8846" or "active-semi,act8865" or "active-semi,act8600"
-- reg: I2C slave address
-
-Optional properties:
-- system-power-controller: Telling whether or not this pmic is controlling
- the system power. See Documentation/devicetree/bindings/power/power-controller.txt .
-- active-semi,vsel-high: Indicates the VSEL pin is high.
- If this property is missing, assume the VSEL pin is low(0).
-
-Optional input supply properties:
-- for act8600:
- - vp1-supply: The input supply for DCDC_REG1
- - vp2-supply: The input supply for DCDC_REG2
- - vp3-supply: The input supply for DCDC_REG3
- - inl-supply: The input supply for LDO_REG5, LDO_REG6, LDO_REG7 and LDO_REG8
- SUDCDC_REG4, LDO_REG9 and LDO_REG10 do not have separate supplies.
-- for act8846:
- - vp1-supply: The input supply for REG1
- - vp2-supply: The input supply for REG2
- - vp3-supply: The input supply for REG3
- - vp4-supply: The input supply for REG4
- - inl1-supply: The input supply for REG5, REG6 and REG7
- - inl2-supply: The input supply for REG8 and LDO_REG9
- - inl3-supply: The input supply for REG10, REG11 and REG12
-- for act8865:
- - vp1-supply: The input supply for DCDC_REG1
- - vp2-supply: The input supply for DCDC_REG2
- - vp3-supply: The input supply for DCDC_REG3
- - inl45-supply: The input supply for LDO_REG1 and LDO_REG2
- - inl67-supply: The input supply for LDO_REG3 and LDO_REG4
-
-Any standard regulator properties can be used to configure the single regulator.
-regulator-initial-mode, regulator-allowed-modes and regulator-mode could be specified
-for act8865 using mode values from dt-bindings/regulator/active-semi,8865-regulator.h
-file.
-
-The valid names for regulators are:
- - for act8846:
- REG1, REG2, REG3, REG4, REG5, REG6, REG7, REG8, REG9, REG10, REG11, REG12
- - for act8865:
- DCDC_REG1, DCDC_REG2, DCDC_REG3, LDO_REG1, LDO_REG2, LDO_REG3, LDO_REG4.
- - for act8600:
- DCDC_REG1, DCDC_REG2, DCDC_REG3, SUDCDC_REG4, LDO_REG5, LDO_REG6, LDO_REG7,
- LDO_REG8, LDO_REG9, LDO_REG10,
-
-Example:
---------
-
-#include <dt-bindings/regulator/active-semi,8865-regulator.h>
-
- i2c1: i2c@f0018000 {
- pmic: act8865@5b {
- compatible = "active-semi,act8865";
- reg = <0x5b>;
- active-semi,vsel-high;
-
- regulators {
- vcc_1v8_reg: DCDC_REG1 {
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- vcc_1v2_reg: DCDC_REG2 {
- regulator-name = "VCC_1V2";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8865_REGULATOR_MODE_FIXED>,
- <ACT8865_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8865_REGULATOR_MODE_FIXED>;
-
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-min-microvolt = <1150000>;
- regulator-suspend-max-microvolt = <1150000>;
- regulator-changeable-in-suspend;
- regulator-mode = <ACT8865_REGULATOR_MODE_LOWPOWER>;
- };
- };
-
- vcc_3v3_reg: DCDC_REG3 {
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vddana_reg: LDO_REG1 {
- regulator-name = "VDDANA";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8865_REGULATOR_MODE_NORMAL>,
- <ACT8865_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8865_REGULATOR_MODE_NORMAL>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vddfuse_reg: LDO_REG2 {
- regulator-name = "FUSE_2V5";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt b/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
deleted file mode 100644
index 4017527619ab..000000000000
--- a/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
+++ /dev/null
@@ -1,113 +0,0 @@
-Device-Tree bindings for regulators of Active-semi ACT8945A Multi-Function Device
-
-Required properties:
- - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt.
-
-Optional properties:
-- active-semi,vsel-high: Indicates if the VSEL pin is set to logic-high.
- If this property is missing, assume the VSEL pin is set to logic-low.
-
-Optional input supply properties:
- - vp1-supply: The input supply for REG_DCDC1
- - vp2-supply: The input supply for REG_DCDC2
- - vp3-supply: The input supply for REG_DCDC3
- - inl45-supply: The input supply for REG_LDO1 and REG_LDO2
- - inl67-supply: The input supply for REG_LDO3 and REG_LDO4
-
-Any standard regulator properties can be used to configure the single regulator.
-regulator-initial-mode, regulator-allowed-modes and regulator-mode could be
-specified using mode values from dt-bindings/regulator/active-semi,8945a-regulator.h
-file.
-
-The valid names for regulators are:
- REG_DCDC1, REG_DCDC2, REG_DCDC3, REG_LDO1, REG_LDO2, REG_LDO3, REG_LDO4.
-
-Example:
-
-#include <dt-bindings/regulator/active-semi,8945a-regulator.h>
-
- pmic@5b {
- compatible = "active-semi,act8945a";
- reg = <0x5b>;
-
- active-semi,vsel-high;
-
- regulators {
- vdd_1v35_reg: REG_DCDC1 {
- regulator-name = "VDD_1V35";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
- <ACT8945A_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
-
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-min-microvolt=<1400000>;
- regulator-suspend-max-microvolt=<1400000>;
- regulator-changeable-in-suspend;
- regulator-mode=<ACT8945A_REGULATOR_MODE_LOWPOWER>;
- };
- };
-
- vdd_1v2_reg: REG_DCDC2 {
- regulator-name = "VDD_1V2";
- regulator-min-microvolt = <1100000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
- <ACT8945A_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_3v3_reg: REG_DCDC3 {
- regulator-name = "VDD_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_fuse_reg: REG_LDO1 {
- regulator-name = "VDD_FUSE";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- regulator-always-on;
-
- regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
- <ACT8945A_REGULATOR_MODE_LOWPOWER>;
- regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_3v3_lp_reg: REG_LDO2 {
- regulator-name = "VDD_3V3_LP";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_led_reg: REG_LDO3 {
- regulator-name = "VDD_LED";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- vdd_sdhc_1v8_reg: REG_LDO4 {
- regulator-name = "VDD_SDHC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
new file mode 100644
index 000000000000..b8ca967bc83d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8600.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8600.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8600 regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8600
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8600 is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ DCDC1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ DCDC2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ DCDC3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ patternProperties:
+ "^(SUDCDC_REG4|LDO_REG9|LDO_REG10)$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^LDO[5-8]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl-supply:
+ description: Handle to the INL input supply
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5a {
+ compatible = "active-semi,act8600";
+ reg = <0x5a>;
+
+ regulators {
+ SUDCDC_REG4 {
+ regulator-min-microvolt = <5300000>;
+ regulator-max-microvolt = <5300000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO5 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO6 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO7 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ inl-supply = <&vcc>;
+ };
+
+ LDO8 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ inl-supply = <&vcc>;
+ };
+
+ LDO_REG9 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ inl-supply = <&vcc>;
+ };
+
+ LDO_REG10 {
+ inl-supply = <&vcc>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
new file mode 100644
index 000000000000..02f45b5834d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8846.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8846.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8846 regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8846
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8846 is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ inl1-supply:
+ description: Handle to the INL1 input supply (REG5-7)
+
+ inl2-supply:
+ description: Handle to the INL2 input supply (REG8-9)
+
+ inl3-supply:
+ description: Handle to the INL3 input supply (REG10-12)
+
+ vp1-supply:
+ description: Handle to the VP1 input supply (REG1)
+
+ vp2-supply:
+ description: Handle to the VP2 input supply (REG2)
+
+ vp3-supply:
+ description: Handle to the VP3 input supply (REG3)
+
+ vp4-supply:
+ description: Handle to the VP4 input supply (REG4)
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^REG([1-9]|1[0-2])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5a {
+ compatible = "active-semi,act8846";
+ reg = <0x5a>;
+
+ system-power-controller;
+
+ regulators {
+ REG1 {
+ regulator-name = "VCC_DDR";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ };
+
+ REG2 {
+ regulator-name = "VCC_IO";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG3 {
+ regulator-name = "VDD_LOG";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ REG4 {
+ regulator-name = "VCC_20";
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-always-on;
+ };
+
+ REG5 {
+ regulator-name = "VCCIO_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG6 {
+ regulator-name = "VDD10_LCD";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ REG7 {
+ regulator-name = "VCC_WL";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG8 {
+ regulator-name = "VCCA_33";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG9 {
+ regulator-name = "VCC_LAN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ REG10 {
+ regulator-name = "VDD_10";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ };
+
+ REG11 {
+ regulator-name = "VCC_18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ REG12 {
+ regulator-name = "VCC18_LCD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
new file mode 100644
index 000000000000..afe1abc2d727
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8865.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8865 regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8865
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8865 is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ DCDC_REG1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ DCDC_REG2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ DCDC_REG3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ patternProperties:
+ "^LDO_REG[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl45-supply:
+ description: Handle to the INL45 input supply
+
+ "^LDO_REG[3-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl67-supply:
+ description: Handle to the INL67 input supply
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ #include <dt-bindings/regulator/active-semi,8865-regulator.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ active-semi,vsel-high;
+
+ regulators {
+ DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+
+ regulator-allowed-modes = <ACT8865_REGULATOR_MODE_FIXED>,
+ <ACT8865_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8865_REGULATOR_MODE_FIXED>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-min-microvolt = <1150000>;
+ regulator-suspend-max-microvolt = <1150000>;
+ regulator-changeable-in-suspend;
+ regulator-mode = <ACT8865_REGULATOR_MODE_LOWPOWER>;
+ };
+ };
+
+ DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+
+ regulator-allowed-modes = <ACT8865_REGULATOR_MODE_NORMAL>,
+ <ACT8865_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8865_REGULATOR_MODE_NORMAL>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
new file mode 100644
index 000000000000..a8d579844dc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/active-semi,act8945a.yaml
@@ -0,0 +1,271 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/active-semi,act8945a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Active-semi ACT8945a regulator
+
+maintainers:
+ - Paul Cercueil <paul@crapouillou.net>
+
+properties:
+ compatible:
+ const: active-semi,act8945a
+
+ reg:
+ maxItems: 1
+
+ system-power-controller:
+ description:
+ Indicates that the ACT8945a is responsible for powering OFF
+ the system.
+ type: boolean
+
+ active-semi,vsel-high:
+ description:
+ Indicates the VSEL pin is high. If this property is missing,
+ the VSEL pin is assumed to be low.
+ type: boolean
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ REG_DCDC1:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp1-supply:
+ description: Handle to the VP1 input supply
+
+ REG_DCDC2:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp2-supply:
+ description: Handle to the VP2 input supply
+
+ REG_DCDC3:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ vp3-supply:
+ description: Handle to the VP3 input supply
+
+ patternProperties:
+ "^REG_LDO[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl45-supply:
+ description: Handle to the INL45 input supply
+
+ "^REG_LDO[3-4]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ inl67-supply:
+ description: Handle to the INL67 input supply
+
+ charger:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: active-semi,act8945a-charger
+
+ interrupts:
+ maxItems: 1
+
+ active-semi,chglev-gpios:
+ description: charge current level GPIO
+ maxItems: 1
+
+ active-semi,lbo-gpios:
+ description: low battery voltage detect GPIO
+ maxItems: 1
+
+ active-semi,input-voltage-threshold-microvolt:
+ description:
+ Specifies the charger's input over-voltage threshold value. Despite
+ the name, specified values are in millivolt (mV).
+ enum: [ 6600, 7000, 7500, 8000 ]
+ default: 6600
+
+ active-semi,precondition-timeout:
+ description:
+ Specifies the charger's PRECONDITION safety timer setting value in
+ minutes. If 0, it means to disable this timer.
+ enum: [ 0, 40, 60, 80 ]
+ default: 40
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ active-semi,total-timeout:
+ description:
+ Specifies the charger's total safety timer setting value in hours; If
+ 0, it means to disable this timer;
+ enum: [ 0, 3, 4, 5 ]
+ default: 3
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - compatible
+ - interrupts
+ - active-semi,chglev-gpios
+ - active-semi,lbo-gpios
+
+additionalProperties: false
+
+required:
+ - reg
+ - compatible
+ - regulators
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/atmel-flexcom.h>
+ #include <dt-bindings/regulator/active-semi,8945a-regulator.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5b {
+ compatible = "active-semi,act8945a";
+ reg = <0x5b>;
+ active-semi,vsel-high;
+
+ regulators {
+ REG_DCDC1 {
+ regulator-name = "VDD_1V35";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-min-microvolt = <1400000>;
+ regulator-suspend-max-microvolt = <1400000>;
+ regulator-changeable-in-suspend;
+ regulator-mode = <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ };
+ };
+
+ REG_DCDC2 {
+ regulator-name = "VDD_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_DCDC3 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_FIXED>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_FIXED>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO1 {
+ regulator-name = "VDD_FUSE";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO2 {
+ regulator-name = "VDD_3V3_LP";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO3 {
+ regulator-name = "VDD_LED";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ REG_LDO4 {
+ regulator-name = "VDD_SDHC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allowed-modes = <ACT8945A_REGULATOR_MODE_NORMAL>,
+ <ACT8945A_REGULATOR_MODE_LOWPOWER>;
+ regulator-initial-mode = <ACT8945A_REGULATOR_MODE_NORMAL>;
+ regulator-always-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+
+ charger {
+ compatible = "active-semi,act8945a-charger";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>;
+ interrupt-parent = <&pioA>;
+ interrupts = <45 IRQ_TYPE_EDGE_RISING>;
+
+ active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>;
+ active-semi,lbo-gpios = <&pioA 72 GPIO_ACTIVE_LOW>;
+ active-semi,input-voltage-threshold-microvolt = <6600>;
+ active-semi,precondition-timeout = <40>;
+ active-semi,total-timeout = <3>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml b/Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml
new file mode 100644
index 000000000000..9c4ead4c9fd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/adi,adp5055-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADP5055 Triple Buck Regulator
+
+maintainers:
+ - Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
+
+description: |
+ The ADP5055 combines three high performance buck regulator. The device enables
+ direct connection to high input voltages up to 18 V with no preregulators.
+ https://www.analog.com/media/en/technical-documentation/data-sheets/adp5055.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,adp5055
+
+ reg:
+ enum:
+ - 0x70
+ - 0x71
+
+ adi,tset-us:
+ description:
+ Setting time used by the device. This is changed via soldering specific
+ resistor values on the CFG2 pin.
+ enum: [2600, 20800]
+ default: 2600
+
+ adi,ocp-blanking:
+ description:
+ If present, overcurrent protection (OCP) blanking for all regulator is on.
+ type: boolean
+
+ adi,delay-power-good:
+ description:
+ Configures delay timer of the power good (PWRGD) pin. Delay is based on
+ Tset which can be 2.6 ms or 20.8 ms.
+ type: boolean
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^buck[0-2]$':
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier to enable the GPIO control for each regulator. The
+ driver supports two modes of enable, hardware only (GPIOs) or software
+ only (Registers). Pure hardware enabling requires each regulator to
+ contain this property. If at least one regulator does not have this,
+ the driver automatically switches to software only mode.
+
+ adi,dvs-limit-upper-microvolt:
+ description:
+ Configure the allowable upper side limit of the voltage output of each
+ regulator in microvolt. Relative to the default Vref trimming value.
+ Vref = 600 mV. Voltages are in 12 mV steps, value is autoadjusted.
+ Vout_high = Vref_trim + dvs-limit-upper.
+ minimum: 12000
+ maximum: 192000
+ default: 192000
+
+ adi,dvs-limit-lower-microvolt:
+ description:
+ Configure the allowable lower side limit of the voltage output of each
+ regulator in microvolt. Relative to the default Vref trimming value.
+ Vref = 600 mV. Voltages are in 12 mV steps, value is autoadjusted.
+ Vout_low = Vref_trim + dvs-limit-lower.
+ minimum: -190500
+ maximum: -10500
+ default: -190500
+
+ adi,fast-transient:
+ description:
+ Configures the fast transient sensitivity for each regulator.
+ "none" - No fast transient.
+ "3G_1.5%" - 1.5% window with 3*350uA/V
+ "5G_1.5%" - 1.5% window with 5*350uA/V
+ "5G_2.5%" - 2.5% window with 5*350uA/V
+ enum: [none, 3G_1.5%, 5G_1.5%, 5G_2.5%]
+ default: 5G_2.5%
+
+ adi,mask-power-good:
+ description:
+ If present, masks individual regulators PWRGD signal to the external
+ PWRGD hardware pin.
+ type: boolean
+
+ required:
+ - regulator-name
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@70 {
+ compatible = "adi,adp5055";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adi,tset-us = <2600>;
+ adi,ocp-blanking;
+ adi,delay-power-good;
+
+ buck0 {
+ regulator-name = "buck0";
+ enable-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ adi,dvs-limit-upper-microvolt = <192000>;
+ adi,dvs-limit-lower-microvolt = <(-190500)>;
+ adi,fast-transient = "5G_2.5%";
+ adi,mask-power-good;
+ };
+
+ buck1 {
+ regulator-name = "buck1";
+ enable-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;
+ adi,dvs-limit-upper-microvolt = <192000>;
+ adi,dvs-limit-lower-microvolt = <(-190500)>;
+ adi,fast-transient = "5G_2.5%";
+ adi,mask-power-good;
+ };
+
+ buck2 {
+ regulator-name = "buck2";
+ enable-gpios = <&gpio 19 GPIO_ACTIVE_HIGH>;
+ adi,dvs-limit-upper-microvolt = <192000>;
+ adi,dvs-limit-lower-microvolt = <(-190500)>;
+ adi,fast-transient = "5G_2.5%";
+ adi,mask-power-good;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/adi,max77503-regulator.yaml b/Documentation/devicetree/bindings/regulator/adi,max77503-regulator.yaml
new file mode 100644
index 000000000000..aa581e550be2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/adi,max77503-regulator.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2023 Analog Devices, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/adi,max77503-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX77503 Buck Converter
+
+maintainers:
+ - Gokhan Celik <Gokhan.Celik@analog.com>
+
+description: |
+ The Analog Devices MAX77503 is a single channel 14V input, 1.5A
+ high-efficiency buck converter. This converter has 94% efficiency
+ for 2-Cell/3-Cell battery applications.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,max77503
+
+ reg:
+ description: I2C address of the device
+ items:
+ - enum: [0x1e, 0x24, 0x37]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@1e {
+ compatible = "adi,max77503";
+ reg = <0x1e>;
+
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <5000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml b/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml
new file mode 100644
index 000000000000..9e36d5467b56
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/adi,max77541-regulator.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/adi,max77541-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Buck Converter for MAX77540/MAX77541
+
+maintainers:
+ - Okan Sahin <okan.sahin@analog.com>
+
+description: |
+ This is a part of device tree bindings for ADI MAX77540/MAX77541
+
+ The buck converter is represented as a sub-node of the PMIC node on the device tree.
+
+ The device has two buck regulators.
+ See also Documentation/devicetree/bindings/mfd/adi,max77541.yaml for
+ additional information and example.
+
+patternProperties:
+ "^buck[12]$":
+ type: object
+ $ref: regulator.yaml#
+ additionalProperties: false
+ description: |
+ Buck regulator.
+
+ properties:
+ regulator-name: true
+ regulator-always-on: true
+ regulator-boot-on: true
+ regulator-min-microvolt:
+ minimum: 300000
+ regulator-max-microvolt:
+ maximum: 5200000
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/adi,max77857.yaml b/Documentation/devicetree/bindings/regulator/adi,max77857.yaml
new file mode 100644
index 000000000000..d1fa74aca721
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/adi,max77857.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2022 Analog Devices Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/adi,max77857.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX77857 Buck-Boost Converter
+
+maintainers:
+ - Ibrahim Tilki <Ibrahim.Tilki@analog.com>
+ - Okan Sahin <Okan.Sahin@analog.com>
+
+description: Analog Devices MAX77857 Buck-Boost Converter
+
+properties:
+ compatible:
+ enum:
+ - adi,max77831
+ - adi,max77857
+ - adi,max77859
+ - adi,max77859a
+
+ reg:
+ description: I2C address of the device
+ items:
+ - enum: [0x66, 0x67, 0x6E, 0x6F]
+
+ interrupts:
+ maxItems: 1
+
+ adi,switch-frequency-hz:
+ description: Switching frequency of the Buck-Boost converter in Hz.
+ items:
+ - enum: [1200000, 1500000, 1800000, 2100000]
+
+ adi,rtop-ohms:
+ description: Top feedback resistor value in ohms for external feedback.
+ minimum: 150000
+ maximum: 330000
+
+ adi,rbot-ohms:
+ description: Bottom feedback resistor value in ohms for external feedback.
+
+dependencies:
+ adi,rtop-ohms: [ 'adi,rbot-ohms' ]
+ adi,rbot-ohms: [ 'adi,rtop-ohms' ]
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: regulator.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - adi,max77831
+
+ then:
+ properties:
+ adi,switch-frequency-hz:
+ items:
+ enum: [1200000, 1500000, 1800000]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@66 {
+ reg = <0x66>;
+ compatible = "adi,max77857";
+ interrupt-parent = <&gpio>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,rtop-ohms = <312000>;
+ adi,rbot-ohms = <12000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
new file mode 100644
index 000000000000..ec6695c8d2e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1 System LDOs
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ Allwinner D1 contains a pair of general-purpose LDOs which are designed to
+ supply power inside and outside the SoC. They are controlled by a register
+ within the system control MMIO space.
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun20i-d1-system-ldos
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^ldo[ab]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
index 0a66338c7e5a..17250378542a 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml
@@ -10,7 +10,7 @@ maintainers:
- Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
@@ -19,43 +19,43 @@ properties:
regulator-name: true
anatop-reg-offset:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the anatop MFD register offset.
anatop-vol-bit-shift:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the bit shift for the register.
anatop-vol-bit-width:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the number of bits used in the register.
anatop-min-bit-val:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the minimum value of this register.
anatop-min-voltage:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the minimum voltage of this regulator.
anatop-max-voltage:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the maximum voltage of this regulator.
anatop-delay-reg-offset:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the anatop MFD step time register offset.
anatop-delay-bit-shift:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the bit shift for the step time register.
anatop-delay-bit-width:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing the number of bits used in the step time register.
anatop-enable-bit:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32
description: u32 value representing regulator enable bit offset.
vin-supply:
diff --git a/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml b/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml
new file mode 100644
index 000000000000..c92a881ed60e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/awinic,aw37503.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/awinic,aw37503.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW37503 Voltage Regulator
+
+maintainers:
+ - Alec Li <like@awinic.com>
+
+description:
+ The AW37503 are dual voltage regulator, designed to support positive/negative
+ supply for driving TFT-LCD panels. It support software-configurable output
+ switching and monitoring. The output voltages can be programmed via an I2C
+ compatible interface.
+
+properties:
+ compatible:
+ const: awinic,aw37503
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^out[pn]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single regulator.
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier to enable the GPIO control (on/off) for regulator.
+
+ required:
+ - regulator-name
+
+required:
+ - compatible
+ - reg
+ - outp
+ - outn
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@3e {
+ compatible = "awinic,aw37503";
+ reg = <0x3e>;
+
+ outp {
+ regulator-name = "outp";
+ regulator-boot-on;
+ regulator-always-on;
+ enable-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ };
+
+ outn {
+ regulator-name = "outn";
+ regulator-boot-on;
+ regulator-always-on;
+ enable-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml b/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml
new file mode 100644
index 000000000000..5b46d7fca05e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/brcm,bcm59054.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/brcm,bcm59054.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM59054 Power Management Unit regulators
+
+description: |
+ This is a part of device tree bindings for the BCM59054 power
+ management unit.
+
+ See Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml for
+ additional information and example.
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+patternProperties:
+ "^(cam|sim|mmc)ldo[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^(rf|sd|sdx|aud|mic|usb|vib|tcx)ldo$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^(c|mm|v)sr$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^(io|sd)sr[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^gpldo[1-3]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^lvldo[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+properties:
+ vbus:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml b/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml
new file mode 100644
index 000000000000..7a5e36394d21
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/brcm,bcm59056.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/brcm,bcm59056.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM59056 Power Management Unit regulators
+
+description: |
+ This is a part of device tree bindings for the BCM59056 power
+ management unit.
+
+ See Documentation/devicetree/bindings/mfd/brcm,bcm59056.yaml for
+ additional information and example.
+
+maintainers:
+ - Artur Weber <aweber.kernel@gmail.com>
+
+patternProperties:
+ "^(cam|sim|mmc)ldo[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^(rf|sd|sdx|aud|mic|usb|vib)ldo$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^(c|m|v)sr$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^(io|sd)sr[1-2]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ "^gpldo[1-6]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+properties:
+ vbus:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/da9210.txt b/Documentation/devicetree/bindings/regulator/da9210.txt
deleted file mode 100644
index 58065ca9e3b4..000000000000
--- a/Documentation/devicetree/bindings/regulator/da9210.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Dialog Semiconductor DA9210 Multi-phase 12A DCDC BUCK Converter
-
-Required properties:
-
-- compatible: must be "dlg,da9210"
-- reg: the i2c slave address of the regulator. It should be 0x68.
-
-Optional properties:
-
-- interrupts: a reference to the DA9210 interrupt, if available.
-
-Any standard regulator properties can be used to configure the single da9210
-DCDC.
-
-Example:
-
- da9210@68 {
- compatible = "dlg,da9210";
- reg = <0x68>;
-
- interrupt-parent = <...>;
- interrupts = <...>;
-
- regulator-min-microvolt = <300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <1600000>;
- regulator-max-microamp = <4600000>;
- regulator-boot-on;
- };
diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt b/Documentation/devicetree/bindings/regulator/da9211.txt
deleted file mode 100644
index eb871447d508..000000000000
--- a/Documentation/devicetree/bindings/regulator/da9211.txt
+++ /dev/null
@@ -1,205 +0,0 @@
-* Dialog Semiconductor DA9211/DA9212/DA9213/DA9223/DA9214/DA9224/DA9215/DA9225
- Voltage Regulator
-
-Required properties:
-- compatible: "dlg,da9211" or "dlg,da9212" or "dlg,da9213" or "dlg,da9223"
- or "dlg,da9214" or "dlg,da9224" or "dlg,da9215" or "dlg,da9225"
-- reg: I2C slave address, usually 0x68.
-- interrupts: the interrupt outputs of the controller
-- regulators: A node that houses a sub-node for each regulator within the
- device. Each sub-node is identified using the node's name, with valid
- values listed below. The content of each sub-node is defined by the
- standard binding for regulators; see regulator.txt.
- BUCKA and BUCKB.
-
-Optional properties:
-- enable-gpios: platform gpio for control of BUCKA/BUCKB.
-- Any optional property defined in regulator.txt
- - regulator-initial-mode and regulator-allowed-modes may be specified using
- mode values from dt-bindings/regulator/dlg,da9211-regulator.h
-
-Example 1) DA9211
- pmic: da9211@68 {
- compatible = "dlg,da9211";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <2000000>;
- regulator-max-microamp = <5000000>;
- enable-gpios = <&gpio 27 0>;
- regulator-allowed-modes = <DA9211_BUCK_MODE_SYNC
- DA9211_BUCK_MODE_AUTO>;
- };
- };
- };
-
-Example 2) DA9212
- pmic: da9212@68 {
- compatible = "dlg,da9212";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <2000000>;
- regulator-max-microamp = <5000000>;
- enable-gpios = <&gpio 27 0>;
- };
- BUCKB {
- regulator-name = "VBUCKB";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <2000000>;
- regulator-max-microamp = <5000000>;
- enable-gpios = <&gpio 17 0>;
- };
- };
- };
-
-Example 3) DA9213
- pmic: da9213@68 {
- compatible = "dlg,da9213";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <3000000>;
- regulator-max-microamp = <6000000>;
- enable-gpios = <&gpio 27 0>;
- };
- };
- };
-
-Example 4) DA9223
- pmic: da9223@68 {
- compatible = "dlg,da9223";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <3000000>;
- regulator-max-microamp = <6000000>;
- enable-gpios = <&gpio 27 0>;
- };
- };
- };
-
-Example 5) DA9214
- pmic: da9214@68 {
- compatible = "dlg,da9214";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <3000000>;
- regulator-max-microamp = <6000000>;
- enable-gpios = <&gpio 27 0>;
- };
- BUCKB {
- regulator-name = "VBUCKB";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <3000000>;
- regulator-max-microamp = <6000000>;
- enable-gpios = <&gpio 17 0>;
- };
- };
- };
-
-Example 6) DA9224
- pmic: da9224@68 {
- compatible = "dlg,da9224";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <3000000>;
- regulator-max-microamp = <6000000>;
- enable-gpios = <&gpio 27 0>;
- };
- BUCKB {
- regulator-name = "VBUCKB";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <3000000>;
- regulator-max-microamp = <6000000>;
- enable-gpios = <&gpio 17 0>;
- };
- };
- };
-
-Example 7) DA9215
- pmic: da9215@68 {
- compatible = "dlg,da9215";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <4000000>;
- regulator-max-microamp = <7000000>;
- enable-gpios = <&gpio 27 0>;
- };
- BUCKB {
- regulator-name = "VBUCKB";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <4000000>;
- regulator-max-microamp = <7000000>;
- enable-gpios = <&gpio 17 0>;
- };
- };
- };
-
-Example 8) DA9225
- pmic: da9225@68 {
- compatible = "dlg,da9225";
- reg = <0x68>;
- interrupts = <3 27>;
-
- regulators {
- BUCKA {
- regulator-name = "VBUCKA";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <4000000>;
- regulator-max-microamp = <7000000>;
- enable-gpios = <&gpio 27 0>;
- };
- BUCKB {
- regulator-name = "VBUCKB";
- regulator-min-microvolt = < 300000>;
- regulator-max-microvolt = <1570000>;
- regulator-min-microamp = <4000000>;
- regulator-max-microamp = <7000000>;
- enable-gpios = <&gpio 17 0>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
index 63e1161a87de..13b3f75f8e5e 100644
--- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
+++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
@@ -95,11 +95,6 @@ properties:
Properties for a single BUCK regulator
properties:
- regulator-name:
- pattern: "^BUCK([1-2])$"
- description: |
- BUCK2 present in DA9122, DA9220, DA9131, DA9132 only
-
regulator-initial-mode:
enum: [ 0, 1, 2, 3 ]
description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
@@ -109,7 +104,7 @@ properties:
description: Specify a valid GPIO for platform control of the regulator
dlg,ripple-cancel:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3 ]
description: |
Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h
@@ -122,6 +117,23 @@ required:
- reg
- regulators
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - dlg,da9122
+ - dlg,da9131
+ - dlg,da9132
+ - dlg,da9220
+ then:
+ properties:
+ regulators:
+ properties:
+ buck2: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9210.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9210.yaml
new file mode 100644
index 000000000000..81f23de36de4
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/dlg,da9210.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/dlg,da9210.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA9210 Multi-Phase 12A DC-DC Buck Converter
+
+maintainers:
+ - Support Opensource <support.opensource@diasemi.com>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ const: dlg,da9210
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@68 {
+ compatible = "dlg,da9210";
+ reg = <0x68>;
+
+ interrupt-parent = <&irqc0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1570000>;
+ regulator-min-microamp = <1600000>;
+ regulator-max-microamp = <4600000>;
+ regulator-boot-on;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9211.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9211.yaml
new file mode 100644
index 000000000000..4d7e495a6f59
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/dlg,da9211.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/dlg,da9211.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Dialog Semiconductor DA9211-9215, DA9223-9225 Voltage Regulators
+
+maintainers:
+ - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
+
+properties:
+ compatible:
+ enum:
+ - dlg,da9211
+ - dlg,da9212
+ - dlg,da9213
+ - dlg,da9214
+ - dlg,da9215
+ - dlg,da9223
+ - dlg,da9224
+ - dlg,da9225
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description:
+ List of regulators provided by the device
+
+ patternProperties:
+ "^BUCK([AB])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for a single BUCK regulator
+
+ properties:
+ regulator-initial-mode:
+ items:
+ enum: [ 1, 2, 3 ]
+ description:
+ Defined in include/dt-bindings/regulator/dlg,da9211-regulator.h
+
+ regulator-allowed-modes:
+ items:
+ enum: [ 1, 2, 3 ]
+ description:
+ Defined in include/dt-bindings/regulator/dlg,da9211-regulator.h
+
+ enable-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/regulator/dlg,da9211-regulator.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@68 {
+ compatible = "dlg,da9212";
+ reg = <0x68>;
+ interrupts = <3 27>;
+
+ regulators {
+ BUCKA {
+ regulator-name = "VBUCKA";
+ regulator-min-microvolt = < 300000>;
+ regulator-max-microvolt = <1570000>;
+ regulator-min-microamp = <2000000>;
+ regulator-max-microamp = <5000000>;
+ enable-gpios = <&gpio 27 0>;
+ };
+ BUCKB {
+ regulator-name = "VBUCKB";
+ regulator-min-microvolt = < 300000>;
+ regulator-max-microvolt = <1570000>;
+ regulator-min-microamp = <2000000>;
+ regulator-max-microamp = <5000000>;
+ enable-gpios = <&gpio 17 0>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml b/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml
new file mode 100644
index 000000000000..bad140418e49
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/dlg,slg51000.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/dlg,slg51000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor SLG51000 Voltage Regulator
+
+maintainers:
+ - Eric Jeong <eric.jeong.opensource@diasemi.com>
+ - Support Opensource <support.opensource@diasemi.com>
+
+properties:
+ compatible:
+ const: dlg,slg51000
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dlg,cs-gpios:
+ maxItems: 1
+ description:
+ GPIO for chip select
+
+ vin3-supply:
+ description:
+ Input supply for ldo3, required if regulator is enabled
+
+ vin4-supply:
+ description:
+ Input supply for ldo4, required if regulator is enabled
+
+ vin5-supply:
+ description:
+ Input supply for ldo5, required if regulator is enabled
+
+ vin6-supply:
+ description:
+ Input supply for ldo6, required if regulator is enabled
+
+ vin7-supply:
+ description:
+ Input supply for ldo7, required if regulator is enabled
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^ldo[1-7]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+
+ required:
+ - regulator-name
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/dlg,da9121-regulator.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@75 {
+ compatible = "dlg,slg51000";
+ reg = <0x75>;
+ dlg,cs-gpios = <&tlmm 69 GPIO_ACTIVE_HIGH>;
+ vin5-supply = <&vreg_s1f_1p2>;
+ vin6-supply = <&vreg_s1f_1p2>;
+
+ regulators {
+ ldo1 {
+ regulator-name = "slg51000_b_ldo1";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo2 {
+ regulator-name = "slg51000_b_ldo2";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo3 {
+ regulator-name = "slg51000_b_ldo3";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ };
+
+ ldo4 {
+ regulator-name = "slg51000_b_ldo4";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ };
+
+ ldo5 {
+ regulator-name = "slg51000_b_ldo5";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ ldo6 {
+ regulator-name = "slg51000_b_ldo6";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ ldo7 {
+ regulator-name = "slg51000_b_ldo7";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3750000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/fan53555.txt b/Documentation/devicetree/bindings/regulator/fan53555.txt
deleted file mode 100644
index 013f096ac0aa..000000000000
--- a/Documentation/devicetree/bindings/regulator/fan53555.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Binding for Fairchild FAN53555 regulators
-
-Required properties:
- - compatible: one of "fcs,fan53555", "fcs,fan53526", "silergy,syr827",
- "silergy,syr828" or "tcs,tcs4525".
- - reg: I2C address
-
-Optional properties:
- - fcs,suspend-voltage-selector: declare which of the two available
- voltage selector registers should be used for the suspend
- voltage. The other one is used for the runtime voltage setting
- Possible values are either <0> or <1>
- - vin-supply: regulator supplying the vin pin
-
-Example:
-
- regulator@40 {
- compatible = "fcs,fan53555";
- regulator-name = "fan53555";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&parent_reg>;
- fcs,suspend-voltage-selector = <1>;
- };
diff --git a/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml
new file mode 100644
index 000000000000..69bae90fc4b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/fcs,fan53555.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fairchild FAN53555 regulators
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fcs,fan53555
+ - fcs,fan53526
+ - rockchip,rk8600
+ - rockchip,rk8602
+ - silergy,syr827
+ - silergy,syr828
+ - tcs,tcs4525
+ - items:
+ - const: rockchip,rk8601
+ - const: rockchip,rk8600
+ - items:
+ - const: rockchip,rk8603
+ - const: rockchip,rk8602
+
+ reg:
+ maxItems: 1
+
+ fcs,suspend-voltage-selector:
+ description: Declares which of the two available voltage selector
+ registers should be used for the suspend voltage. The other one is used
+ for the runtime voltage setting.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+
+ vin-supply:
+ description: Supply for the vin pin
+
+ vsel-gpios:
+ description: Voltage Select. When this pin is LOW, VOUT is set by the
+ VSEL0 register. When this pin is HIGH, VOUT is set by the VSEL1 register.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@40 {
+ compatible = "fcs,fan53555";
+ reg = <0x40>;
+ regulator-name = "fan53555";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&parent_reg>;
+ fcs,suspend-voltage-selector = <1>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml b/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml
new file mode 100644
index 000000000000..c6585e3bacbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/fitipower,fp9931.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FitiPower FP9931/JD9930 Power Management Integrated Circuit
+
+maintainers:
+ - Andreas Kemnade <andreas@kemnade.info>
+
+description:
+ FP9931 is a Power Management IC to provide Power for EPDs with one 3.3V
+ switch, 2 symmetric LDOs behind 2 DC/DC converters, and one unsymmetric
+ regulator for a compensation voltage.
+ JD9930 has in addition some kind of night mode.
+
+properties:
+ compatible:
+ oneOf:
+ - const: fitipower,fp9931
+
+ - items:
+ - const: fitipower,jd9930
+ - const: fitipower,fp9931
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+
+ pg-gpios:
+ maxItems: 1
+
+ en-ts-gpios:
+ maxItems: 1
+
+ xon-gpios:
+ maxItems: 1
+
+ vin-supply:
+ description:
+ Supply for the whole chip. Some vendor kernels and devicetrees
+ declare this as a non-existing GPIO named "pwrall".
+
+ fitipower,tdly-ms:
+ description:
+ Power up soft start delay settings tDLY1-4 bitfields in the
+ POWERON_DELAY register
+ items:
+ - enum: [0, 1, 2, 4]
+ - enum: [0, 1, 2, 4]
+ - enum: [0, 1, 2, 4]
+ - enum: [0, 1, 2, 4]
+
+ regulators:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^(vcom|vposneg|v3p3)$":
+ unevaluatedProperties: false
+ type: object
+ $ref: /schemas/regulator/regulator.yaml
+
+required:
+ - compatible
+ - reg
+ - pg-gpios
+ - enable-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@18 {
+ compatible = "fitipower,fp9931";
+ reg = <0x18>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fp9931_gpio>;
+ vin-supply = <&epd_pmic_supply>;
+ pg-gpios = <&gpio2 7 GPIO_ACTIVE_HIGH>;
+ en-ts-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
+ fitipower,tdly-ms = <2 2 4 4>;
+
+ regulators {
+ vcom {
+ regulator-name = "vcom";
+ regulator-min-microvolt = <2352840>;
+ regulator-max-microvolt = <2352840>;
+ };
+
+ vposneg {
+ regulator-name = "vposneg";
+ regulator-min-microvolt = <15060000>;
+ regulator-max-microvolt = <15060000>;
+ };
+
+ v3p3 {
+ regulator-name = "v3p3";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
index 84eeaef179a5..51e2f6fb7a5a 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
@@ -17,7 +17,7 @@ description:
to be the same.
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
- if:
properties:
compatible:
@@ -35,8 +35,19 @@ allOf:
required:
- power-domains
- required-opps
+ - not:
+ required:
+ - gpio
+ - gpios
properties:
+ $nodename:
+ anyOf:
+ - description: Preferred name is 'regulator-[0-9]v[0-9]'
+ pattern: '^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$'
+ - description: Any name allowed
+ deprecated: true
+
compatible:
enum:
- regulator-fixed
@@ -49,6 +60,9 @@ properties:
description: gpio to use for enable control
maxItems: 1
+ gpios:
+ maxItems: 1
+
clocks:
description:
clock to use for enable control. This binding is only available if
@@ -93,6 +107,13 @@ properties:
vin-supply:
description: Input supply phandle.
+ interrupts:
+ maxItems: 1
+ description:
+ Interrupt signaling a critical under-voltage event.
+
+ system-critical-regulator: true
+
required:
- compatible
- regulator-name
diff --git a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
index 69e5402da761..5a6491a81fda 100644
--- a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
@@ -14,7 +14,7 @@ description:
regulator.yaml, can also be used.
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
@@ -32,7 +32,7 @@ unevaluatedProperties: false
examples:
- |
- spi0 {
+ spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -41,6 +41,7 @@ examples:
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ interrupts = <99 0>;
regulator@0 {
compatible = "google,cros-ec-regulator";
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
index 6c3371d706bb..a34e85754658 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
@@ -15,7 +15,7 @@ description:
regulator.txt, can also be used.
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
@@ -47,6 +47,7 @@ properties:
1: HIGH
Default is LOW if nothing else is specified.
$ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
maxItems: 8
items:
enum: [0, 1]
@@ -57,7 +58,8 @@ properties:
regulator and matching GPIO configurations to achieve them. If there are
no states in the "states" array, use a fixed regulator instead.
$ref: /schemas/types.yaml#/definitions/uint32-matrix
- maxItems: 8
+ minItems: 2
+ maxItems: 256
items:
items:
- description: Voltage in microvolts
diff --git a/Documentation/devicetree/bindings/regulator/infineon,ir38060.yaml b/Documentation/devicetree/bindings/regulator/infineon,ir38060.yaml
new file mode 100644
index 000000000000..57ff6bf1e188
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/infineon,ir38060.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/infineon,ir38060.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon Buck Regulators with PMBUS interfaces
+
+maintainers:
+ - Guenter Roeck <linux@roeck-us.net>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - infineon,ir38060
+ - infineon,ir38064
+ - infineon,ir38164
+ - infineon,ir38263
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@34 {
+ compatible = "infineon,ir38060";
+ reg = <0x34>;
+
+ regulator-min-microvolt = <437500>;
+ regulator-max-microvolt = <1387500>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/lltc,ltc3676.yaml b/Documentation/devicetree/bindings/regulator/lltc,ltc3676.yaml
new file mode 100644
index 000000000000..f47eacf96cd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/lltc,ltc3676.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/lltc,ltc3676.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linear Technology LTC3676 8-output regulators
+
+maintainers:
+ - Tim Harvey <tharvey@gateworks.com>
+
+description: |
+ LTC3676 contains eight regulators, 4 switching SW1..SW4 and four LDO1..4 .
+
+properties:
+ compatible:
+ const: lltc,ltc3676
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description: |
+ List of regulators provided by this controller, must be named
+ after their hardware counterparts (SW|LDO)[1-4].
+
+ patternProperties:
+ "^(sw[1-4]|ldo[24])$":
+ type: object
+ unevaluatedProperties: false
+ $ref: regulator.yaml#
+ description:
+ Properties for single SW or LDO regulator. Regulators SW1..SW4 can
+ regulate the feedback reference from 412.5mV to 800mV in 12.5 mV
+ steps. The output voltage thus ranges between 0.4125 * (1 + R1/R2) V
+ and 0.8 * (1 + R1/R2) V.
+ Regulators LDO1, LDO2, LDO4 have a fixed 0.725 V reference and thus
+ output 0.725 * (1 + R1/R2) V.
+ The LDO1 standby regulator can not be disabled and thus should have
+ the regulator-always-on property set.
+
+ properties:
+ lltc,fb-voltage-divider:
+ description:
+ An array of two integers containing the resistor values
+ R1 and R2 of the feedback voltage divider in ohms.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+
+ required:
+ - lltc,fb-voltage-divider
+
+ properties:
+ ldo1:
+ type: object
+ unevaluatedProperties: false
+ $ref: regulator.yaml#
+ description:
+ The LDO1 standby regulator can not be disabled and thus should
+ have the regulator-always-on property set. See patternProperties
+ description above for the rest of the details.
+
+ properties:
+ lltc,fb-voltage-divider:
+ description:
+ An array of two integers containing the resistor values
+ R1 and R2 of the feedback voltage divider in ohms.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+
+ required:
+ - lltc,fb-voltage-divider
+ - regulator-always-on
+
+ ldo3:
+ type: object
+ unevaluatedProperties: false
+ $ref: regulator.yaml#
+ description:
+ The LDO3 regulator is fixed to 1.8 V. See patternProperties
+ description above for the rest of the details.
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3c {
+ compatible = "lltc,ltc3676";
+ reg = <0x3c>;
+
+ regulators {
+ sw1_reg: sw1 {
+ regulator-min-microvolt = <674400>;
+ regulator-max-microvolt = <1308000>;
+ lltc,fb-voltage-divider = <127000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <1033310>;
+ regulator-max-microvolt = <200400>;
+ lltc,fb-voltage-divider = <301000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3_reg: sw3 {
+ regulator-min-microvolt = <674400>;
+ regulator-max-microvolt = <130800>;
+ lltc,fb-voltage-divider = <127000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <868310>;
+ regulator-max-microvolt = <168400>;
+ lltc,fb-voltage-divider = <221000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = <2490375>;
+ regulator-max-microvolt = <2490375>;
+ lltc,fb-voltage-divider = <487000 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = <3023250>;
+ regulator-max-microvolt = <3023250>;
+ lltc,fb-voltage-divider = <634000 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/ltc3676.txt b/Documentation/devicetree/bindings/regulator/ltc3676.txt
deleted file mode 100644
index d4eb366ce18c..000000000000
--- a/Documentation/devicetree/bindings/regulator/ltc3676.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Linear Technology LTC3676 8-output regulators
-
-Required properties:
-- compatible: "lltc,ltc3676"
-- reg: I2C slave address
-
-Required child node:
-- regulators: Contains eight regulator child nodes sw1, sw2, sw3, sw4,
- ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as
- documented in Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Each regulator is defined using the standard binding for regulators. The
-nodes for sw1, sw2, sw3, sw4, ldo1, ldo2 and ldo4 additionally need to specify
-the resistor values of their external feedback voltage dividers:
-
-Required properties (not on ldo3):
-- lltc,fb-voltage-divider: An array of two integers containing the resistor
- values R1 and R2 of the feedback voltage divider in ohms.
-
-Regulators sw1, sw2, sw3, sw4 can regulate the feedback reference from:
-412.5mV to 800mV in 12.5 mV steps. The output voltage thus ranges between
-0.4125 * (1 + R1/R2) V and 0.8 * (1 + R1/R2) V.
-
-Regulators ldo1, ldo2, and ldo4 have a fixed 0.725 V reference and thus output
-0.725 * (1 + R1/R2) V. The ldo3 regulator is fixed to 1.8 V. The ldo1 standby
-regulator can not be disabled and thus should have the regulator-always-on
-property set.
-
-Example:
-
- ltc3676: pmic@3c {
- compatible = "lltc,ltc3676";
- reg = <0x3c>;
-
- regulators {
- sw1_reg: sw1 {
- regulator-min-microvolt = <674400>;
- regulator-max-microvolt = <1308000>;
- lltc,fb-voltage-divider = <127000 200000>;
- regulator-ramp-delay = <7000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- sw2_reg: sw2 {
- regulator-min-microvolt = <1033310>;
- regulator-max-microvolt = <200400>;
- lltc,fb-voltage-divider = <301000 200000>;
- regulator-ramp-delay = <7000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- sw3_reg: sw3 {
- regulator-min-microvolt = <674400>;
- regulator-max-microvolt = <130800>;
- lltc,fb-voltage-divider = <127000 200000>;
- regulator-ramp-delay = <7000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- sw4_reg: sw4 {
- regulator-min-microvolt = <868310>;
- regulator-max-microvolt = <168400>;
- lltc,fb-voltage-divider = <221000 200000>;
- regulator-ramp-delay = <7000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo2_reg: ldo2 {
- regulator-min-microvolt = <2490375>;
- regulator-max-microvolt = <2490375>;
- lltc,fb-voltage-divider = <487000 200000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo3_reg: ldo3 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-boot-on;
- };
-
- ldo4_reg: ldo4 {
- regulator-min-microvolt = <3023250>;
- regulator-max-microvolt = <3023250>;
- lltc,fb-voltage-divider = <634000 200000>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml
index ce0a4021ae7f..27d5e9c2bb93 100644
--- a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml
@@ -25,7 +25,8 @@ properties:
patternProperties:
"^regulator-(ldo|sbb[0-2])$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/regulator/max8660.yaml b/Documentation/devicetree/bindings/regulator/max8660.yaml
index 9c038698f880..f05f4644c8ee 100644
--- a/Documentation/devicetree/bindings/regulator/max8660.yaml
+++ b/Documentation/devicetree/bindings/regulator/max8660.yaml
@@ -24,8 +24,9 @@ properties:
type: object
patternProperties:
- "regulator-.+":
- $ref: "regulator.yaml#"
+ "^regulator-.+$":
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
additionalProperties: false
@@ -43,31 +44,26 @@ examples:
regulators {
regulator-V3 {
- regulator-compatible= "V3(DCDC)";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <1800000>;
};
regulator-V4 {
- regulator-compatible= "V4(DCDC)";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <1800000>;
};
regulator-V5 {
- regulator-compatible= "V5(LDO)";
regulator-min-microvolt = <1700000>;
regulator-max-microvolt = <2000000>;
};
regulator-V6 {
- regulator-compatible= "V6(LDO)";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
};
regulator-V7 {
- regulator-compatible= "V7(LDO)";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
};
diff --git a/Documentation/devicetree/bindings/regulator/max8893.yaml b/Documentation/devicetree/bindings/regulator/max8893.yaml
index 2b5e977bf409..e40ee798e198 100644
--- a/Documentation/devicetree/bindings/regulator/max8893.yaml
+++ b/Documentation/devicetree/bindings/regulator/max8893.yaml
@@ -25,7 +25,7 @@ properties:
patternProperties:
"^(ldo[1-5]|buck)$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml b/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml
index 05f72391185e..7394c0a339c5 100644
--- a/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml
+++ b/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml
@@ -43,6 +43,7 @@ properties:
"^OUT[1-4]$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max20411.yaml b/Documentation/devicetree/bindings/regulator/maxim,max20411.yaml
new file mode 100644
index 000000000000..5b3a42d24e51
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/maxim,max20411.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/maxim,max20411.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX20411 Step-Down DC-DC Converter
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ The MAX20411 is a high-efficiency, DC-DC step-down converter. It provides
+ configurable output voltage in the range of 0.5V to 1.275V, configurable over
+ I2C.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ const: maxim,max20411
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO connected to the EN pin, active high
+
+ vdd-supply:
+ description: Input supply for the device (VDD pin, 3.0V to 5.5V)
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@39 {
+ compatible = "maxim,max20411";
+ reg = <0x39>;
+
+ enable-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1000000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
index 71138c611b6c..b704f05ea454 100644
--- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
@@ -77,7 +77,7 @@ patternProperties:
regulator-initial-mode: false
patternProperties:
- regulator-state-(standby|mem|disk):
+ "^regulator-state-(standby|mem|disk)$":
type: object
additionalProperties: true
properties:
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml
index 78c0b63243f7..6d6bbfbd26d4 100644
--- a/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77826.yaml
@@ -30,10 +30,12 @@ properties:
"^LDO([1-9]|1[0-5])$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
"^BUCK|BUCKBOOST$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77838.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77838.yaml
new file mode 100644
index 000000000000..bed36af5493d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77838.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/maxim,max77838.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX77838 PMIC
+
+maintainers:
+ - Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
+
+properties:
+ $nodename:
+ pattern: "pmic@[0-9a-f]{1,2}"
+ compatible:
+ enum:
+ - maxim,max77838
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+ $ref: regulator.yaml#
+ description: |
+ list of regulators provided by this controller, must be named
+ after their hardware counterparts ldo[1-4] and buck
+
+ properties:
+ buck:
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ patternProperties:
+ "^ldo([1-4])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@60 {
+ compatible = "maxim,max77838";
+ reg = <0x60>;
+
+ regulators {
+ ldo2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
deleted file mode 100644
index 451cc4e86b01..000000000000
--- a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
+++ /dev/null
@@ -1,144 +0,0 @@
-MCP16502 PMIC
-
-Required properties:
-- compatible: "microchip,mcp16502"
-- reg: I2C slave address
-- lpm-gpios: GPIO for LPM pin. Note that this GPIO *must* remain high during
- suspend-to-ram, keeping the PMIC into HIBERNATE mode; this
- property is optional;
-- regulators: A node that houses a sub-node for each regulator within
- the device. Each sub-node is identified using the node's
- name. The content of each sub-node is defined by the
- standard binding for regulators; see regulator.txt.
-
-Regulators of MCP16502 PMIC:
-1) VDD_IO - Buck (1.2 - 3.7 V)
-2) VDD_DDR - Buck (0.6 - 1.85 V)
-3) VDD_CORE - Buck (0.6 - 1.85 V)
-4) VDD_OTHER - BUCK (0.6 - 1.85 V)
-5) LDO1 - LDO (1.2 - 3.7 V)
-6) LDO2 - LDO (1.2 - 3.7 V)
-
-Regulator modes:
-2 - FPWM: higher precision, higher consumption
-4 - AutoPFM: lower precision, lower consumption
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-mcp16502@5b {
- compatible = "microchip,mcp16502";
- reg = <0x5b>;
- status = "okay";
- lpm-gpios = <&pioBU 7 GPIO_ACTIVE_HIGH>;
-
- regulators {
- VDD_IO {
- regulator-name = "VDD_IO";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3700000>;
- regulator-initial-mode = <2>;
- regulator-allowed-modes = <2>, <4>;
- regulator-always-on;
-
- regulator-state-standby {
- regulator-on-in-suspend;
- regulator-mode = <4>;
- };
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-mode = <4>;
- };
- };
-
- VDD_DDR {
- regulator-name = "VDD_DDR";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1850000>;
- regulator-initial-mode = <2>;
- regulator-allowed-modes = <2>, <4>;
- regulator-always-on;
-
- regulator-state-standby {
- regulator-on-in-suspend;
- regulator-mode = <4>;
- };
-
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-mode = <4>;
- };
- };
-
- VDD_CORE {
- regulator-name = "VDD_CORE";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1850000>;
- regulator-initial-mode = <2>;
- regulator-allowed-modes = <2>, <4>;
- regulator-always-on;
-
- regulator-state-standby {
- regulator-on-in-suspend;
- regulator-mode = <4>;
- };
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-mode = <4>;
- };
- };
-
- VDD_OTHER {
- regulator-name = "VDD_OTHER";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1850000>;
- regulator-initial-mode = <2>;
- regulator-allowed-modes = <2>, <4>;
- regulator-always-on;
-
- regulator-state-standby {
- regulator-on-in-suspend;
- regulator-mode = <4>;
- };
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-mode = <4>;
- };
- };
-
- LDO1 {
- regulator-name = "LDO1";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3700000>;
- regulator-always-on;
-
- regulator-state-standby {
- regulator-on-in-suspend;
- };
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- LDO2 {
- regulator-name = "LDO2";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3700000>;
- regulator-always-on;
-
- regulator-state-standby {
- regulator-on-in-suspend;
- };
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- };
-};
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6316b-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6316b-regulator.yaml
new file mode 100644
index 000000000000..ea595935f4c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6316b-regulator.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6316b-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6316 BP/VP SPMI PMIC Regulators
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek MT6316BP/VP PMICs are fully controlled by SPMI interface, both
+ feature four step-down DC/DC (buck) converters, and provides 2+2 Phases,
+ joining Buck 1+2 for the first phase, and Buck 3+4 for the second phase.
+
+properties:
+ compatible:
+ const: mediatek,mt6316b-regulator
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^vbuck(12|34)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed Buck regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 1 - Forced Continuous Conduction mode (FCCM) for improved voltage
+ regulation accuracy with constant switching frequency but lower
+ regulator efficiency
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, will shut down unnecessary IP
+ blocks and secondary phases to reduce quiescent current.
+ This mode does not limit the maximum output current but unless
+ only a light load is applied, there will be regulation accuracy
+ and efficiency losses.
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [ 0, 1, 2 ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "mediatek,mt6316b-regulator";
+ reg = <0x8 SPMI_USID>;
+
+ vbuck12 {
+ regulator-name = "dvdd_core";
+ regulator-min-microvolt = <450000>;
+ regulator-max-microvolt = <965000>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-enable-ramp-delay = <256>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6316c-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6316c-regulator.yaml
new file mode 100644
index 000000000000..186dcd3f11ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6316c-regulator.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6316c-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6316 CP/HP/KP SPMI PMIC Regulators
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek MT6316CP/HP/KP PMICs are fully controlled by SPMI interface,
+ features four step-down DC/DC (buck) converters, and provides 3+1 Phases,
+ joining Buck 1+2+4 for the first phase, and uses Buck 3 for the second.
+
+properties:
+ compatible:
+ const: mediatek,mt6316c-regulator
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^vbuck(124|3)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed Buck regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 1 - Forced Continuous Conduction mode (FCCM) for improved voltage
+ regulation accuracy with constant switching frequency but lower
+ regulator efficiency
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, will shut down unnecessary IP
+ blocks and secondary phases to reduce quiescent current.
+ This mode does not limit the maximum output current but unless
+ only a light load is applied, there will be regulation accuracy
+ and efficiency losses.
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [ 0, 1, 2 ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@6 {
+ compatible = "mediatek,mt6316c-regulator";
+ reg = <0x6 SPMI_USID>;
+
+ vbuck124 {
+ regulator-name = "dvdd_proc_m";
+ regulator-min-microvolt = <450000>;
+ regulator-max-microvolt = <1277500>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-enable-ramp-delay = <256>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6316d-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6316d-regulator.yaml
new file mode 100644
index 000000000000..aa9e9ef3b52d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6316d-regulator.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6316d-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6316 DP/TP SPMI PMIC Regulators
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek MT6316DP/TP PMICs are fully controlled by SPMI interface, both
+ feature four step-down DC/DC (buck) converters, and provides a single Phase,
+ joining Buck 1+2+3+4.
+
+properties:
+ compatible:
+ const: mediatek,mt6316d-regulator
+
+ reg:
+ maxItems: 1
+
+ vbuck1234:
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed Buck regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 1 - Forced Continuous Conduction mode (FCCM) for improved voltage
+ regulation accuracy with constant switching frequency but lower
+ regulator efficiency
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, will shut down unnecessary IP
+ blocks and secondary phases to reduce quiescent current.
+ This mode does not limit the maximum output current but unless
+ only a light load is applied, there will be regulation accuracy
+ and efficiency losses.
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [ 0, 1, 2 ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@7 {
+ compatible = "mediatek,mt6316d-regulator";
+ reg = <0x7 SPMI_USID>;
+
+ vbuck1234 {
+ regulator-name = "dvdd_gpustack";
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1277500>;
+ regulator-allowed-modes = <0 1 2>;
+ regulator-enable-ramp-delay = <256>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml
index 771cc134393c..c654acf13768 100644
--- a/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml
@@ -15,10 +15,14 @@ description: |
buck-<name> and ldo-<name>.
MT6331 regulators node should be sub node of the MT6397 MFD node.
+properties:
+ compatible:
+ const: mediatek,mt6331-regulator
+
patternProperties:
"^buck-v(core2|io18|dvfs11|dvfs12|dvfs13|dvfs14)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -26,39 +30,39 @@ patternProperties:
unevaluatedProperties: false
- "^ldo-v(avdd32aud|auxa32)$":
+ "^ldo-(avdd32aud|vauxa32)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
- pattern: "^v(avdd32aud|auxa32)$"
+ pattern: "^(avdd32_aud|vauxa32)$"
unevaluatedProperties: false
- "^ldo-v(dig18|emc33|ibr|mc|mch|mipi|rtc|sram|usb10)$":
+ "^ldo-v(dig18|emc33|ibr|mc|mch|mipi|rtc|sim1|sim2|sram|usb10)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
- pattern: "^v(dig18|emc33|ibr|mc|mch|mipi|rtc|sram|usb10)$"
+ pattern: "^v(dig18|emc33|ibr|mc|mch|mipi|rtc|sim1|sim2|sram|usb)$"
unevaluatedProperties: false
"^ldo-vcam(a|af|d|io)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
- pattern: "^vcam(a|af|d|io)$"
+ pattern: "^vcam(a|_af|d|io)$"
unevaluatedProperties: false
"^ldo-vtcxo[12]$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -71,17 +75,20 @@ patternProperties:
"^ldo-vgp[1234]$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
- pattern: "^vgp[12]$"
+ pattern: "^vgp[1234]$"
required:
- regulator-name
unevaluatedProperties: false
+required:
+ - compatible
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml
index 3218f43e6957..475f18d4f261 100644
--- a/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml
@@ -15,10 +15,14 @@ description: |
buck-<name> and ldo-<name>.
MT6332 regulators node should be sub node of the MT6397 MFD node.
+properties:
+ compatible:
+ const: mediatek,mt6332-regulator
+
patternProperties:
"^buck-v(dram|dvfs2|pa|rf18a|rf18b|sbst)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -28,7 +32,7 @@ patternProperties:
"^ldo-v(bif28|dig18|sram|usb33)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -36,6 +40,9 @@ patternProperties:
unevaluatedProperties: false
+required:
+ - compatible
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
new file mode 100644
index 000000000000..698266c09e25
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6357-regulator.yaml
@@ -0,0 +1,284 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6357-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6357 Regulators
+
+maintainers:
+ - Chen Zhong <chen.zhong@mediatek.com>
+ - Fabien Parent <fabien.parent@linaro.org>
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+description: |
+ The MT6357 PMIC provides 5 BUCK and 29 LDO.
+ Regulators and nodes are named according to the regulator type:
+ - buck-<name>
+ - ldo-<name>.
+ MT6357 regulators node should be sub node of the MT6397 MFD node.
+
+patternProperties:
+ "^buck-v(core|modem|pa|proc|s1)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single BUCK regulator.
+
+ required:
+ - regulator-name
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+ "^ldo-v(camio18|aud28|aux18|io18|io28|rf12|rf18|cn18|cn28|fe28)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single fixed LDO regulator.
+
+ required:
+ - regulator-name
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+ "^ldo-v(efuse|ibr|ldo28|mch|cama|camd|cn33-bt|cn33-wifi)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single LDO regulator.
+
+ required:
+ - regulator-name
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+ "^ldo-v(xo22|emc|mc|sim1|sim2|sram-others|sram-proc|dram|usb33)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single LDO regulator.
+
+ required:
+ - regulator-name
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+additionalProperties: false
+
+examples:
+ - |
+ pmic {
+ regulators {
+ mt6357_vproc_reg: buck-vproc {
+ regulator-name = "vproc";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+ mt6357_vcore_reg: buck-vcore {
+ regulator-name = "vcore";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+ mt6357_vmodem_reg: buck-vmodem {
+ regulator-name = "vmodem";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1193750>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <220>;
+ };
+ mt6357_vs1_reg: buck-vs1 {
+ regulator-name = "vs1";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <2200000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <220>;
+ regulator-always-on;
+ };
+ mt6357_vpa_reg: buck-vpa {
+ regulator-name = "vpa";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3650000>;
+ regulator-ramp-delay = <50000>;
+ regulator-enable-ramp-delay = <220>;
+ };
+ mt6357_vfe28_reg: ldo-vfe28 {
+ regulator-name = "vfe28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vxo22_reg: ldo-vxo22 {
+ regulator-name = "vxo22";
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <2400000>;
+ regulator-enable-ramp-delay = <110>;
+ };
+ mt6357_vrf18_reg: ldo-vrf18 {
+ regulator-name = "vrf18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <110>;
+ };
+ mt6357_vrf12_reg: ldo-vrf12 {
+ regulator-name = "vrf12";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-enable-ramp-delay = <110>;
+ };
+ mt6357_vefuse_reg: ldo-vefuse {
+ regulator-name = "vefuse";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcn33_bt_reg: ldo-vcn33-bt {
+ regulator-name = "vcn33-bt";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3500000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcn33_wifi_reg: ldo-vcn33-wifi {
+ regulator-name = "vcn33-wifi";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3500000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcn28_reg: ldo-vcn28 {
+ regulator-name = "vcn28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcn18_reg: ldo-vcn18 {
+ regulator-name = "vcn18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcama_reg: ldo-vcama {
+ regulator-name = "vcama";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcamd_reg: ldo-vcamd {
+ regulator-name = "vcamd";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vcamio_reg: ldo-vcamio18 {
+ regulator-name = "vcamio";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vldo28_reg: ldo-vldo28 {
+ regulator-name = "vldo28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vsram_others_reg: ldo-vsram-others {
+ regulator-name = "vsram-others";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <110>;
+ regulator-always-on;
+ };
+ mt6357_vsram_proc_reg: ldo-vsram-proc {
+ regulator-name = "vsram-proc";
+ regulator-min-microvolt = <518750>;
+ regulator-max-microvolt = <1312500>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <110>;
+ regulator-always-on;
+ };
+ mt6357_vaux18_reg: ldo-vaux18 {
+ regulator-name = "vaux18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vaud28_reg: ldo-vaud28 {
+ regulator-name = "vaud28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vio28_reg: ldo-vio28 {
+ regulator-name = "vio28";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vio18_reg: ldo-vio18 {
+ regulator-name = "vio18";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <264>;
+ regulator-always-on;
+ };
+ mt6357_vdram_reg: ldo-vdram {
+ regulator-name = "vdram";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-enable-ramp-delay = <3300>;
+ };
+ mt6357_vmc_reg: ldo-vmc {
+ regulator-name = "vmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <44>;
+ };
+ mt6357_vmch_reg: ldo-vmch {
+ regulator-name = "vmch";
+ regulator-min-microvolt = <2900000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <44>;
+ };
+ mt6357_vemc_reg: ldo-vemc {
+ regulator-name = "vemc";
+ regulator-min-microvolt = <2900000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <44>;
+ regulator-always-on;
+ };
+ mt6357_vsim1_reg: ldo-vsim1 {
+ regulator-name = "vsim1";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vsim2_reg: ldo-vsim2 {
+ regulator-name = "vsim2";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ mt6357_vibr_reg: ldo-vibr {
+ regulator-name = "vibr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <44>;
+ };
+ mt6357_vusb33_reg: ldo-vusb33 {
+ regulator-name = "vusb33";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-enable-ramp-delay = <264>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
new file mode 100644
index 000000000000..c50402fcba72
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
@@ -0,0 +1,250 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6358-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6358 Regulator
+
+maintainers:
+ - Zhiyong Tao <zhiyong.tao@mediatek.com>
+
+description:
+ Regulator node of the PMIC. This node should under the PMIC's device node.
+ All voltage regulators provided by the PMIC are described as sub-nodes of
+ this node.
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt6358-regulator
+ - items:
+ - const: mediatek,mt6366-regulator
+ - const: mediatek,mt6358-regulator
+
+ vsys-ldo1-supply:
+ description: Supply for LDOs vfe28, vxo22, vcn28, vaux18, vaud28, vsim1, vusb, vbif28
+ vsys-ldo2-supply:
+ description: Supply for LDOs vldo28 (MT6358 only), vio28, vmc, vmch, vsim2
+ vsys-ldo3-supply:
+ description: Supply for LDOs vcn33, vcama[12] (MT6358 only), vemc, vibr
+ vsys-vcore-supply:
+ description: Supply for buck regulator vcore
+ vsys-vdram1-supply:
+ description: Supply for buck regulator vdram1
+ vsys-vgpu-supply:
+ description: Supply for buck regulator vgpu
+ vsys-vmodem-supply:
+ description: Supply for buck regulator vmodem
+ vsys-vpa-supply:
+ description: Supply for buck regulator vpa
+ vsys-vproc11-supply:
+ description: Supply for buck regulator vproc11
+ vsys-vproc12-supply:
+ description: Supply for buck regulator vproc12
+ vsys-vs1-supply:
+ description: Supply for buck regulator vs1
+ vsys-vs2-supply:
+ description: Supply for buck regulator vs2
+ vs1-ldo1-supply:
+ description:
+ Supply for LDOs vrf18, vefuse, vcn18, vcamio (MT6358 only), vio18, vm18 (MT6366 only)
+ vs2-ldo1-supply:
+ description: Supply for LDOs vdram2, vmddr (MT6366 only)
+ vs2-ldo2-supply:
+ description: Supply for LDOs vrf12, va12
+ vs2-ldo3-supply:
+ description:
+ Supply for LDOs vsram-core (MT6366 only), vsram-gpu, vsram-others, vsram-proc11, vsram-proc12
+ vs2-ldo4-supply:
+ description: Supply for LDO vcamd
+
+patternProperties:
+ "^(buck_)?v(core|dram1|gpu|modem|pa|proc1[12]|s[12])$":
+ description: Buck regulators
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Buck regulatpr operating modes allowed. Valid values below.
+ Users should use the macros from dt-bindings/regulator/mediatek,mt6397-regulator.h
+ 0 (MT6397_BUCK_MODE_AUTO): Auto PFM/PWM mode
+ 1 (MT6397_BUCK_MODE_FORCE_PWM): Forced PWM mode
+ items:
+ enum: [0, 1]
+ unevaluatedProperties: false
+
+ "^(ldo_)?v(a|rf)12$":
+ description: LDOs with fixed 1.2V output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?v((aux|cn|io|rf)18|camio)$":
+ description:
+ LDOs with fixed 1.8V output and 0~100/10mV tuning (vcn18 on MT6366 has variable output)
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?vxo22$":
+ description: LDOs with fixed 2.2V output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?v(aud|bif|cn|fe|io)28$":
+ description: LDOs with fixed 2.8V output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?vusb$":
+ description: LDOs with fixed 3.0V output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?vsram[_-](core|gpu|others|proc1[12])$":
+ description: LDOs with variable output
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?v(cama[12]|camd|cn33|dram2|efuse|emc|ibr|ldo28|m18|mc|mch|mddr|sim[12])$":
+ description: LDOs with variable output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: mediatek,mt6358-regulator
+ then:
+ patternProperties:
+ # Old regulator node name scheme (with prefix and underscores) only
+ # ([^y-] is used to avoid matching -supply
+ "^(?<!buck_)(?<!ldo_)v.*[^y-](?!-supply)$": false
+ "^ldo_vsram-": false
+ # vsram_core regulator doesn't exist on MT6358
+ "^ldo_vsram[-_]core$": false
+
+ properties:
+ # vm18 and vmddr regulators don't exist on MT6358
+ ldo_vm18: false
+ ldo_vmddr: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt6366-regulator
+ then:
+ patternProperties:
+ # Prefer cleaned up regulator node names
+ "^(buck|ldo)_": false
+ # Don't allow underscores
+ "^vsram_": false
+ # vcam* regulators don't exist on MT6366
+ "^vcam": false
+
+ properties:
+ # vldo28 regulator doesn't exist on MT6366
+ vldo28: false
+ # vs2_ldo4 supply pin doesn't exist on MT6366
+ vs2-ldo4-supply: false
+
+examples:
+ - |
+ #include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
+
+ regulator {
+ compatible = "mediatek,mt6358-regulator";
+
+ buck_vgpu {
+ regulator-name = "vgpu";
+ regulator-min-microvolt = <625000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <200>;
+ regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+ MT6397_BUCK_MODE_FORCE_PWM>;
+ };
+
+ ldo_vsram_gpu {
+ regulator-name = "vsram_gpu";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <240>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/regulator/mediatek,mt6397-regulator.h>
+
+ regulator {
+ compatible = "mediatek,mt6366-regulator", "mediatek,mt6358-regulator";
+
+ vdram1 {
+ regulator-name = "pp1125_emi_vdd2";
+ regulator-min-microvolt = <1125000>;
+ regulator-max-microvolt = <1125000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <0>;
+ regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+ MT6397_BUCK_MODE_FORCE_PWM>;
+ regulator-always-on;
+ };
+
+ vproc11 {
+ regulator-name = "ppvar_dvdd_proc_bc_mt6366";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <200>;
+ regulator-allowed-modes = <MT6397_BUCK_MODE_AUTO
+ MT6397_BUCK_MODE_FORCE_PWM>;
+ regulator-always-on;
+ };
+
+ vmddr {
+ regulator-name = "pm0750_emi_vmddr";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <750000>;
+ regulator-enable-ramp-delay = <325>;
+ regulator-always-on;
+ };
+
+ vsram-proc11 {
+ regulator-name = "pp0900_dvdd_sram_bc";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-ramp-delay = <6250>;
+ regulator-enable-ramp-delay = <240>;
+ regulator-always-on;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6363-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6363-regulator.yaml
new file mode 100644
index 000000000000..4f79d4f81d49
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6363-regulator.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6363-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6363 PMIC Regulators
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MT6363 SPMI PMIC provides 10 BUCK and 25 LDO (Low DropOut) regulators
+ and can optionally provide overcurrent warnings with one ocp interrupt
+ for each voltage regulator.
+
+properties:
+ compatible:
+ const: mediatek,mt6363-regulator
+
+ reg:
+ maxItems: 1
+
+ vsys-vbuck1-supply:
+ description: Input supply for vbuck1
+
+ vsys-vbuck2-supply:
+ description: Input supply for vbuck2
+
+ vsys-vbuck3-supply:
+ description: Input supply for vbuck3
+
+ vsys-vbuck4-supply:
+ description: Input supply for vbuck4
+
+ vsys-vbuck5-supply:
+ description: Input supply for vbuck5
+
+ vsys-vbuck6-supply:
+ description: Input supply for vbuck6
+
+ vsys-vbuck7-supply:
+ description: Input supply for vbuck7
+
+ vsys-vs1-supply:
+ description: Input supply for vs1
+
+ vsys-vs2-supply:
+ description: Input supply for vs2
+
+ vsys-vs3-supply:
+ description: Input supply for vs3
+
+ vs1-ldo1-supply:
+ description: Input supply for va15, vio0p75, vm18, vrf18, vrf-io18
+
+ vs1-ldo2-supply:
+ description: Input supply for vcn15, vio18, vufs18
+
+ vs2-ldo1-supply:
+ description: Input supply for vsram-cpub, vsram-cpum, vrf12, vrf13, vufs12
+
+ vs2-ldo2-supply:
+ description: Input supply for va12-1, va12-2, vcn13, vsram-cpul
+
+ vs3-ldo1-supply:
+ description: Input supply for vsram-apu, vsram-digrf, vsram-mdfe
+
+ vs3-ldo2-supply:
+ description: Input supply for vsram-modem, vrf0p9
+
+ vsys-ldo1-supply:
+ description: Input supply for vaux18, vemc, vtref18
+
+patternProperties:
+ "^v(buck[1-7]|s[1-3])$":
+ description: Buck regulators
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed Buck regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 1 - Forced Continuous Conduction mode (FCCM) for improved voltage
+ regulation accuracy with constant switching frequency but lower
+ regulator efficiency
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, does not limit the maximum out
+ current but unless only a light load is applied, there will be
+ regulation accuracy and efficiency losses.
+ 3 - Forced Ultra Low Power mode for ultra low load, this greatly
+ reduces the maximum output power, makes the regulator to be
+ efficient only for ultra light load, and greatly reduces the
+ quiescent current (Iq) of the buck.
+ maxItems: 3
+ items:
+ enum: [ 0, 1, 2, 3 ]
+
+ "^va(12-1|12-2|15)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^v(aux|m|rf-io|tref)18$":
+ $ref: "#/$defs/ldo-common"
+
+ "^v(cn13|cn15|emc)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vio(0p75|18)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vrf(0p9|12|13|18)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vsram-(apu|cpub|cpum|cpul|digrf|mdfe|modem)$":
+ $ref: "#/$defs/ldo-common"
+
+ "^vufs(12|18)$":
+ $ref: "#/$defs/ldo-common"
+
+$defs:
+ ldo-common:
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ regulator-allowed-modes:
+ description: |
+ Allowed LDO regulator operating modes allowed. Valid values below.
+ 0 - Normal mode with automatic power saving, reducing the switching
+ frequency when light load conditions are detected
+ 2 - Forced Low Power mode for improved regulator efficiency, used
+ when no heavy load is expected, does not limit the maximum out
+ current but unless only a light load is applied, there will be
+ regulation accuracy and efficiency losses.
+ maxItems: 2
+ items:
+ enum: [ 0, 2 ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6397-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6397-regulator.yaml
new file mode 100644
index 000000000000..50db6782a090
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6397-regulator.yaml
@@ -0,0 +1,238 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6397-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6397 Regulator
+
+maintainers:
+ - Sen Chu <sen.chu@mediatek.com>
+ - Macpaul Lin <macpaul.lin@mediatek.com>
+
+description:
+ Regulator node of the PMIC. This node should under the PMIC's device node.
+ All voltage regulators provided by the PMIC are described as sub-nodes of
+ this node.
+
+properties:
+ compatible:
+ items:
+ - const: mediatek,mt6397-regulator
+
+patternProperties:
+ "^(buck_)?v(core|drm|gpu|io18|pca(7|15)|sramca(7|15))$":
+ description: Buck regulators
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes:
+ description: |
+ BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
+ values specified in dt-bindings/regulator/mediatek,mt6397-regulator.h
+ items:
+ enum: [0, 1]
+ unevaluatedProperties: false
+
+ "^(ldo_)?v(tcxo|(a|io)28)$":
+ description: LDOs with fixed 2.8V output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?vusb$":
+ description: LDOs with fixed 3.0V output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+ "^(ldo_)?v(cama|emc3v3|gp[123456]|ibr|mc|mch)$":
+ description: LDOs with variable output and 0~100/10mV tuning
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mt6397_regulators: regulators {
+ compatible = "mediatek,mt6397-regulator";
+
+ mt6397_vpca15_reg: buck_vpca15 {
+ regulator-name = "vpca15";
+ regulator-min-microvolt = < 850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <200>;
+ };
+
+ mt6397_vpca7_reg: buck_vpca7 {
+ regulator-name = "vpca7";
+ regulator-min-microvolt = < 850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <115>;
+ };
+
+ mt6397_vsramca15_reg: buck_vsramca15 {
+ regulator-name = "vsramca15";
+ regulator-min-microvolt = < 850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <115>;
+ };
+
+ mt6397_vsramca7_reg: buck_vsramca7 {
+ regulator-name = "vsramca7";
+ regulator-min-microvolt = < 850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <115>;
+ };
+
+ mt6397_vcore_reg: buck_vcore {
+ regulator-name = "vcore";
+ regulator-min-microvolt = < 850000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <115>;
+ };
+
+ mt6397_vgpu_reg: buck_vgpu {
+ regulator-name = "vgpu";
+ regulator-min-microvolt = < 700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <115>;
+ };
+
+ mt6397_vdrm_reg: buck_vdrm {
+ regulator-name = "vdrm";
+ regulator-min-microvolt = < 800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <500>;
+ };
+
+ mt6397_vio18_reg: buck_vio18 {
+ regulator-name = "vio18";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <2120000>;
+ regulator-ramp-delay = <12500>;
+ regulator-enable-ramp-delay = <500>;
+ };
+
+ mt6397_vtcxo_reg: ldo_vtcxo {
+ regulator-name = "vtcxo";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <90>;
+ };
+
+ mt6397_va28_reg: ldo_va28 {
+ regulator-name = "va28";
+ /* fixed output 2.8 V */
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vcama_reg: ldo_vcama {
+ regulator-name = "vcama";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vio28_reg: ldo_vio28 {
+ regulator-name = "vio28";
+ /* fixed output 2.8 V */
+ regulator-enable-ramp-delay = <240>;
+ };
+
+ mt6397_usb_reg: ldo_vusb {
+ regulator-name = "vusb";
+ /* fixed output 3.3 V */
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vmc_reg: ldo_vmc {
+ regulator-name = "vmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vmch_reg: ldo_vmch {
+ regulator-name = "vmch";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vemc_3v3_reg: ldo_vemc3v3 {
+ regulator-name = "vemc_3v3";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vgp1_reg: ldo_vgp1 {
+ regulator-name = "vcamd";
+ regulator-min-microvolt = <1220000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <240>;
+ };
+
+ mt6397_vgp2_reg: ldo_vgp2 {
+ regulator-name = "vcamio";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vgp3_reg: ldo_vgp3 {
+ regulator-name = "vcamaf";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vgp4_reg: ldo_vgp4 {
+ regulator-name = "vgp4";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vgp5_reg: ldo_vgp5 {
+ regulator-name = "vgp5";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vgp6_reg: ldo_vgp6 {
+ regulator-name = "vgp6";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+
+ mt6397_vibr_reg: ldo_vibr {
+ regulator-name = "vibr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <218>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6873-dvfsrc-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6873-dvfsrc-regulator.yaml
new file mode 100644
index 000000000000..685ccf9cf4d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6873-dvfsrc-regulator.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6873-dvfsrc-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek DVFSRC-controlled Regulators
+
+description:
+ The Dynamic Voltage and Frequency Scaling Resource Collector Regulators
+ are controlled with votes to the DVFSRC hardware.
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6873-dvfsrc-regulator
+ - mediatek,mt6893-dvfsrc-regulator
+ - mediatek,mt8183-dvfsrc-regulator
+ - mediatek,mt8192-dvfsrc-regulator
+ - mediatek,mt8195-dvfsrc-regulator
+ - mediatek,mt8196-dvfsrc-regulator
+
+ dvfsrc-vcore:
+ description: DVFSRC-controlled SoC Vcore regulator
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ dvfsrc-vscp:
+ description: DVFSRC-controlled System Control Processor regulator
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+anyOf:
+ - required:
+ - dvfsrc-vcore
+ - required:
+ - dvfsrc-vscp
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
new file mode 100644
index 000000000000..c3e1fc6e260e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
@@ -0,0 +1,200 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/microchip,mcp16502.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MCP16502 - High-Performance PMIC
+
+maintainers:
+ - Andrei Simion <andrei.simion@microchip.com>
+
+description:
+ The MCP16502 is an optimally integrated PMIC compatible
+ with Microchip's eMPUs(Embedded Microprocessor Units),
+ requiring Dynamic Voltage Scaling (DVS) with the use
+ of High-Performance mode (HPM).
+
+properties:
+ compatible:
+ const: microchip,mcp16502
+
+ lpm-gpios:
+ maxItems: 1
+ description: GPIO for LPM pin.
+ Note that this GPIO must remain high during
+ suspend-to-ram, keeping the PMIC into HIBERNATE mode.
+
+ reg:
+ maxItems: 1
+
+ lvin-supply:
+ description: Input supply phandle for LDO1 and LDO2
+
+ pvin1-supply:
+ description: Input supply phandle for VDD_IO (BUCK1)
+
+ pvin2-supply:
+ description: Input supply phandle for VDD_DDR (BUCK2)
+
+ pvin3-supply:
+ description: Input supply phandle for VDD_CORE (BUCK3)
+
+ pvin4-supply:
+ description: Input supply phandle for VDD_OTHER (BUCK4)
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description: List of regulators and its properties.
+
+ patternProperties:
+ "^(VDD_(IO|CORE|DDR|OTHER)|LDO[1-2])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ regulator-initial-mode:
+ enum: [2, 4]
+ default: 2
+ description: Initial operating mode
+
+ regulator-allowed-modes:
+ items:
+ enum: [2, 4]
+ description: Supported modes
+ 2 - FPWM higher precision, higher consumption
+ 4 - AutoPFM lower precision, lower consumption
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@5b {
+ compatible = "microchip,mcp16502";
+ reg = <0x5b>;
+ lvin-supply = <&reg_5v>;
+ pvin1-supply = <&reg_5v>;
+ pvin2-supply = <&reg_5v>;
+ pvin3-supply = <&reg_5v>;
+ pvin4-supply = <&reg_5v>;
+
+ regulators {
+ VDD_IO {
+ regulator-name = "VDD_IO";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ VDD_DDR {
+ regulator-name = "VDD_DDR";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ VDD_CORE {
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ VDD_OTHER {
+ regulator-name = "VDD_OTHER";
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-initial-mode = <2>;
+ regulator-allowed-modes = <2>, <4>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ regulator-mode = <4>;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-mode = <4>;
+ };
+ };
+
+ LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3700000>;
+ regulator-always-on;
+
+ regulator-state-standby {
+ regulator-on-in-suspend;
+ };
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
index 7023c597c3ed..f825ee9efd81 100644
--- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
+++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml
@@ -28,11 +28,13 @@ properties:
patternProperties:
"^buck[1-4]$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
type: object
"^ldo[1-4]$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
type: object
additionalProperties: false
@@ -60,8 +62,8 @@ examples:
regulator-name = "buck1";
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <2187500>;
- regulator-min-microamp = <3800000>;
- regulator-max-microamp = <6800000>;
+ regulator-min-microamp = <3800000>;
+ regulator-max-microamp = <6800000>;
regulator-boot-on;
};
diff --git a/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml b/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml
index 9245b7199439..374a4f6b1e23 100644
--- a/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml
+++ b/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml
@@ -28,7 +28,7 @@ properties:
mps,fb-voltage-divider:
description: An array of two integers containing the resistor
values R1 and R2 of the feedback voltage divider in kilo ohms.
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
maxItems: 2
mps,switch-frequency-hz:
diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq2286.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq2286.yaml
new file mode 100644
index 000000000000..1296f9b30862
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mps,mpq2286.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mps,mpq2286.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Monolithic Power System MPQ2286 PMIC
+
+maintainers:
+ - Saravanan Sekar <saravanan@linumiz.com>
+
+properties:
+ compatible:
+ enum:
+ - mps,mpq2286
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+
+ properties:
+ buck:
+ type: object
+ $ref: regulator.yaml#
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3 {
+ compatible = "mps,mpq2286";
+ reg = <0x3>;
+
+ regulators {
+ buck {
+ regulator-name = "buck";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
index c2e8c54e5311..0d34af98403f 100644
--- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
+++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml
@@ -21,7 +21,6 @@ properties:
regulators:
type: object
- $ref: regulator.yaml#
description: |
list of regulators provided by this controller, must be named
@@ -29,7 +28,7 @@ properties:
properties:
mps,switch-freq:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2, 3]
default: 2
description: |
@@ -39,11 +38,13 @@ properties:
ldortc:
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
patternProperties:
"^ldo[1-4]$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
"^buck[1-4]$":
type: object
@@ -51,14 +52,14 @@ properties:
properties:
mps,buck-softstart:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2, 3]
description: |
defines the soft start time of this buck, must be one of the following
corresponding values 150us, 300us, 610us, 920us
mps,buck-phase-delay:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2, 3]
description: |
defines the phase delay of this buck, must be one of the following
@@ -97,8 +98,8 @@ examples:
regulator-name = "buck1";
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <3587500>;
- regulator-min-microamp = <460000>;
- regulator-max-microamp = <7600000>;
+ regulator-min-microamp = <460000>;
+ regulator-max-microamp = <7600000>;
regulator-boot-on;
mps,buck-ovp-disable;
mps,buck-phase-delay = /bits/ 8 <2>;
diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml
new file mode 100644
index 000000000000..2185cd011c46
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mps,mpq7932.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mps,mpq7932.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Monolithic Power System MPQ7932 PMIC
+
+maintainers:
+ - Saravanan Sekar <saravanan@linumiz.com>
+
+properties:
+ compatible:
+ enum:
+ - mps,mpq7932
+
+ reg:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: |
+ list of regulators provided by this controller, must be named
+ after their hardware counterparts BUCK[1-6]
+
+ patternProperties:
+ "^buck[1-6]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3 {
+ compatible = "mps,mpq7932";
+ reg = <0x3>;
+
+ regulators {
+ buck1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+
+ buck2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
index 364b58730be2..fa6743bb269d 100644
--- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
@@ -16,7 +16,11 @@ description: |
properties:
compatible:
- const: mediatek,mt6315-regulator
+ oneOf:
+ - items:
+ - const: mediatek,mt6319-regulator
+ - const: mediatek,mt6315-regulator
+ - const: mediatek,mt6315-regulator
reg:
maxItems: 1
@@ -28,13 +32,9 @@ properties:
patternProperties:
"^vbuck[1-4]$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
unevaluatedProperties: false
- properties:
- regulator-compatible:
- pattern: "^vbuck[1-4]$"
-
additionalProperties: false
required:
@@ -52,7 +52,6 @@ examples:
regulators {
vbuck1 {
- regulator-compatible = "vbuck1";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1193750>;
regulator-enable-ramp-delay = <256>;
@@ -60,7 +59,6 @@ examples:
};
vbuck3 {
- regulator-compatible = "vbuck3";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1193750>;
regulator-enable-ramp-delay = <256>;
diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
deleted file mode 100644
index 7034cdca54e0..000000000000
--- a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
+++ /dev/null
@@ -1,370 +0,0 @@
-MediaTek MT6358 Regulator
-
-All voltage regulators provided by the MT6358 PMIC are described as the
-subnodes of the MT6358 regulators node. Each regulator is named according
-to its regulator type, buck_<name> and ldo_<name>. The definition for each
-of these nodes is defined using the standard binding for regulators at
-Documentation/devicetree/bindings/regulator/regulator.txt.
-
-The valid names for regulators are::
-BUCK:
- buck_vdram1, buck_vcore, buck_vcore_sshub, buck_vpa, buck_vproc11,
- buck_vproc12, buck_vgpu, buck_vs2, buck_vmodem, buck_vs1
-LDO:
- ldo_vdram2, ldo_vsim1, ldo_vibr, ldo_vrf12, ldo_vio18, ldo_vusb, ldo_vcamio,
- ldo_vcamd, ldo_vcn18, ldo_vfe28, ldo_vsram_proc11, ldo_vcn28, ldo_vsram_others,
- ldo_vsram_others_sshub, ldo_vsram_gpu, ldo_vxo22, ldo_vefuse, ldo_vaux18,
- ldo_vmch, ldo_vbif28, ldo_vsram_proc12, ldo_vcama1, ldo_vemc, ldo_vio28, ldo_va12,
- ldo_vrf18, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_vcama2, ldo_vmc, ldo_vldo28, ldo_vaud28,
- ldo_vsim2
-
-Example:
-
- pmic {
- compatible = "mediatek,mt6358";
-
- mt6358regulator: mt6358regulator {
- compatible = "mediatek,mt6358-regulator";
-
- mt6358_vdram1_reg: buck_vdram1 {
- regulator-compatible = "buck_vdram1";
- regulator-name = "vdram1";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <2087500>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <0>;
- regulator-always-on;
- };
-
- mt6358_vcore_reg: buck_vcore {
- regulator-name = "vcore";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <200>;
- regulator-always-on;
- };
-
- mt6358_vpa_reg: buck_vpa {
- regulator-name = "vpa";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <3650000>;
- regulator-ramp-delay = <50000>;
- regulator-enable-ramp-delay = <250>;
- };
-
- mt6358_vproc11_reg: buck_vproc11 {
- regulator-name = "vproc11";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <200>;
- regulator-always-on;
- };
-
- mt6358_vproc12_reg: buck_vproc12 {
- regulator-name = "vproc12";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <200>;
- regulator-always-on;
- };
-
- mt6358_vgpu_reg: buck_vgpu {
- regulator-name = "vgpu";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <200>;
- };
-
- mt6358_vs2_reg: buck_vs2 {
- regulator-name = "vs2";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <2087500>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <0>;
- regulator-always-on;
- };
-
- mt6358_vmodem_reg: buck_vmodem {
- regulator-name = "vmodem";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <900>;
- regulator-always-on;
- };
-
- mt6358_vs1_reg: buck_vs1 {
- regulator-name = "vs1";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <2587500>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <0>;
- regulator-always-on;
- };
-
- mt6358_vdram2_reg: ldo_vdram2 {
- regulator-name = "vdram2";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <3300>;
- };
-
- mt6358_vsim1_reg: ldo_vsim1 {
- regulator-name = "vsim1";
- regulator-min-microvolt = <1700000>;
- regulator-max-microvolt = <3100000>;
- regulator-enable-ramp-delay = <540>;
- };
-
- mt6358_vibr_reg: ldo_vibr {
- regulator-name = "vibr";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <60>;
- };
-
- mt6358_vrf12_reg: ldo_vrf12 {
- compatible = "regulator-fixed";
- regulator-name = "vrf12";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-enable-ramp-delay = <120>;
- };
-
- mt6358_vio18_reg: ldo_vio18 {
- compatible = "regulator-fixed";
- regulator-name = "vio18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <2700>;
- regulator-always-on;
- };
-
- mt6358_vusb_reg: ldo_vusb {
- regulator-name = "vusb";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3100000>;
- regulator-enable-ramp-delay = <270>;
- regulator-always-on;
- };
-
- mt6358_vcamio_reg: ldo_vcamio {
- compatible = "regulator-fixed";
- regulator-name = "vcamio";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vcamd_reg: ldo_vcamd {
- regulator-name = "vcamd";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vcn18_reg: ldo_vcn18 {
- compatible = "regulator-fixed";
- regulator-name = "vcn18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vfe28_reg: ldo_vfe28 {
- compatible = "regulator-fixed";
- regulator-name = "vfe28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vsram_proc11_reg: ldo_vsram_proc11 {
- regulator-name = "vsram_proc11";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <240>;
- regulator-always-on;
- };
-
- mt6358_vcn28_reg: ldo_vcn28 {
- compatible = "regulator-fixed";
- regulator-name = "vcn28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vsram_others_reg: ldo_vsram_others {
- regulator-name = "vsram_others";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <240>;
- regulator-always-on;
- };
-
- mt6358_vsram_gpu_reg: ldo_vsram_gpu {
- regulator-name = "vsram_gpu";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <240>;
- };
-
- mt6358_vxo22_reg: ldo_vxo22 {
- compatible = "regulator-fixed";
- regulator-name = "vxo22";
- regulator-min-microvolt = <2200000>;
- regulator-max-microvolt = <2200000>;
- regulator-enable-ramp-delay = <120>;
- regulator-always-on;
- };
-
- mt6358_vefuse_reg: ldo_vefuse {
- regulator-name = "vefuse";
- regulator-min-microvolt = <1700000>;
- regulator-max-microvolt = <1900000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vaux18_reg: ldo_vaux18 {
- compatible = "regulator-fixed";
- regulator-name = "vaux18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vmch_reg: ldo_vmch {
- regulator-name = "vmch";
- regulator-min-microvolt = <2900000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <60>;
- };
-
- mt6358_vbif28_reg: ldo_vbif28 {
- compatible = "regulator-fixed";
- regulator-name = "vbif28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vsram_proc12_reg: ldo_vsram_proc12 {
- regulator-name = "vsram_proc12";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- regulator-ramp-delay = <6250>;
- regulator-enable-ramp-delay = <240>;
- regulator-always-on;
- };
-
- mt6358_vcama1_reg: ldo_vcama1 {
- regulator-name = "vcama1";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vemc_reg: ldo_vemc {
- regulator-name = "vemc";
- regulator-min-microvolt = <2900000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <60>;
- regulator-always-on;
- };
-
- mt6358_vio28_reg: ldo_vio28 {
- compatible = "regulator-fixed";
- regulator-name = "vio28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_va12_reg: ldo_va12 {
- compatible = "regulator-fixed";
- regulator-name = "va12";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-enable-ramp-delay = <270>;
- regulator-always-on;
- };
-
- mt6358_vrf18_reg: ldo_vrf18 {
- compatible = "regulator-fixed";
- regulator-name = "vrf18";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-enable-ramp-delay = <120>;
- };
-
- mt6358_vcn33_bt_reg: ldo_vcn33_bt {
- regulator-name = "vcn33_bt";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3500000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vcn33_wifi_reg: ldo_vcn33_wifi {
- regulator-name = "vcn33_wifi";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3500000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vcama2_reg: ldo_vcama2 {
- regulator-name = "vcama2";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vmc_reg: ldo_vmc {
- regulator-name = "vmc";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <60>;
- };
-
- mt6358_vldo28_reg: ldo_vldo28 {
- regulator-name = "vldo28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <3000000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vaud28_reg: ldo_vaud28 {
- compatible = "regulator-fixed";
- regulator-name = "vaud28";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <270>;
- };
-
- mt6358_vsim2_reg: ldo_vsim2 {
- regulator-name = "vsim2";
- regulator-min-microvolt = <1700000>;
- regulator-max-microvolt = <3100000>;
- regulator-enable-ramp-delay = <540>;
- };
-
- mt6358_vcore_sshub_reg: buck_vcore_sshub {
- regulator-name = "vcore_sshub";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- };
-
- mt6358_vsram_others_sshub_reg: ldo_vsram_others_sshub {
- regulator-name = "vsram_others_sshub";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1293750>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
index 8cc413eb482d..d6b3b5a5c0b3 100644
--- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
@@ -17,7 +17,7 @@ description: |
patternProperties:
"^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -27,7 +27,7 @@ patternProperties:
"^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -37,7 +37,7 @@ patternProperties:
"^ldo_v(rfck|emc|a12|a09|ufs|bbck)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -47,7 +47,7 @@ patternProperties:
"^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -57,7 +57,7 @@ patternProperties:
"^ldo_vsram_(proc2|others|md|proc1|others_sshub)$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -67,7 +67,7 @@ patternProperties:
"^ldo_v(fe|bif|io)28$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -77,7 +77,7 @@ patternProperties:
"^ldo_v(aud|io|aux|rf|m)18$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
@@ -87,7 +87,7 @@ patternProperties:
"^ldo_vsim[12]$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
regulator-name:
diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
index a462d99a25cc..9c879bc3c360 100644
--- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
@@ -26,10 +26,12 @@ properties:
patternProperties:
"^buck[12]$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
"^ldo[123567]$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
@@ -44,7 +46,6 @@ examples:
compatible = "mediatek,mt6360-regulator";
LDO_VIN3-supply = <&BUCK2>;
buck1 {
- regulator-compatible = "BUCK1";
regulator-name = "mt6360,buck1";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1300000>;
@@ -53,7 +54,6 @@ examples:
MT6360_OPMODE_ULP>;
};
BUCK2: buck2 {
- regulator-compatible = "BUCK2";
regulator-name = "mt6360,buck2";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1300000>;
@@ -62,7 +62,6 @@ examples:
MT6360_OPMODE_ULP>;
};
ldo6 {
- regulator-compatible = "LDO6";
regulator-name = "mt6360,ldo6";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2100000>;
@@ -70,7 +69,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo7 {
- regulator-compatible = "LDO7";
regulator-name = "mt6360,ldo7";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2100000>;
@@ -78,15 +76,13 @@ examples:
MT6360_OPMODE_LP>;
};
ldo1 {
- regulator-compatible = "LDO1";
regulator-name = "mt6360,ldo1";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
regulator-allowed-modes = <MT6360_OPMODE_NORMAL
MT6360_OPMODE_LP>;
};
- ldo2 {
- regulator-compatible = "LDO2";
+ ldo2 {
regulator-name = "mt6360,ldo2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
@@ -94,7 +90,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo3 {
- regulator-compatible = "LDO3";
regulator-name = "mt6360,ldo3";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
@@ -102,7 +97,6 @@ examples:
MT6360_OPMODE_LP>;
};
ldo5 {
- regulator-compatible = "LDO5";
regulator-name = "mt6360,ldo5";
regulator-min-microvolt = <2700000>;
regulator-max-microvolt = <3600000>;
diff --git a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
deleted file mode 100644
index c080086d3e62..000000000000
--- a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
+++ /dev/null
@@ -1,220 +0,0 @@
-Mediatek MT6397 Regulator
-
-Required properties:
-- compatible: "mediatek,mt6397-regulator"
-- mt6397regulator: List of regulators provided by this controller. It is named
- according to its regulator type, buck_<name> and ldo_<name>.
- The definition for each of these nodes is defined using the standard binding
- for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
-
-The valid names for regulators are::
-BUCK:
- buck_vpca15, buck_vpca7, buck_vsramca15, buck_vsramca7, buck_vcore, buck_vgpu,
- buck_vdrm, buck_vio18
-LDO:
- ldo_vtcxo, ldo_va28, ldo_vcama, ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch,
- ldo_vemc3v3, ldo_vgp1, ldo_vgp2, ldo_vgp3, ldo_vgp4, ldo_vgp5, ldo_vgp6,
- ldo_vibr
-
-BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
-values specified in dt-bindings/regulator/mediatek,mt6397-regulator.h
-
-Example:
- pmic {
- compatible = "mediatek,mt6397";
-
- mt6397regulator: mt6397regulator {
- compatible = "mediatek,mt6397-regulator";
-
- mt6397_vpca15_reg: buck_vpca15 {
- regulator-compatible = "buck_vpca15";
- regulator-name = "vpca15";
- regulator-min-microvolt = < 850000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <200>;
- };
-
- mt6397_vpca7_reg: buck_vpca7 {
- regulator-compatible = "buck_vpca7";
- regulator-name = "vpca7";
- regulator-min-microvolt = < 850000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <115>;
- };
-
- mt6397_vsramca15_reg: buck_vsramca15 {
- regulator-compatible = "buck_vsramca15";
- regulator-name = "vsramca15";
- regulator-min-microvolt = < 850000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <115>;
-
- };
-
- mt6397_vsramca7_reg: buck_vsramca7 {
- regulator-compatible = "buck_vsramca7";
- regulator-name = "vsramca7";
- regulator-min-microvolt = < 850000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <115>;
-
- };
-
- mt6397_vcore_reg: buck_vcore {
- regulator-compatible = "buck_vcore";
- regulator-name = "vcore";
- regulator-min-microvolt = < 850000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <115>;
- };
-
- mt6397_vgpu_reg: buck_vgpu {
- regulator-compatible = "buck_vgpu";
- regulator-name = "vgpu";
- regulator-min-microvolt = < 700000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <115>;
- };
-
- mt6397_vdrm_reg: buck_vdrm {
- regulator-compatible = "buck_vdrm";
- regulator-name = "vdrm";
- regulator-min-microvolt = < 800000>;
- regulator-max-microvolt = <1400000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <500>;
- };
-
- mt6397_vio18_reg: buck_vio18 {
- regulator-compatible = "buck_vio18";
- regulator-name = "vio18";
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <2120000>;
- regulator-ramp-delay = <12500>;
- regulator-enable-ramp-delay = <500>;
- };
-
- mt6397_vtcxo_reg: ldo_vtcxo {
- regulator-compatible = "ldo_vtcxo";
- regulator-name = "vtcxo";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <90>;
- };
-
- mt6397_va28_reg: ldo_va28 {
- regulator-compatible = "ldo_va28";
- regulator-name = "va28";
- /* fixed output 2.8 V */
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vcama_reg: ldo_vcama {
- regulator-compatible = "ldo_vcama";
- regulator-name = "vcama";
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <2800000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vio28_reg: ldo_vio28 {
- regulator-compatible = "ldo_vio28";
- regulator-name = "vio28";
- /* fixed output 2.8 V */
- regulator-enable-ramp-delay = <240>;
- };
-
- mt6397_usb_reg: ldo_vusb {
- regulator-compatible = "ldo_vusb";
- regulator-name = "vusb";
- /* fixed output 3.3 V */
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vmc_reg: ldo_vmc {
- regulator-compatible = "ldo_vmc";
- regulator-name = "vmc";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vmch_reg: ldo_vmch {
- regulator-compatible = "ldo_vmch";
- regulator-name = "vmch";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vemc_3v3_reg: ldo_vemc3v3 {
- regulator-compatible = "ldo_vemc3v3";
- regulator-name = "vemc_3v3";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vgp1_reg: ldo_vgp1 {
- regulator-compatible = "ldo_vgp1";
- regulator-name = "vcamd";
- regulator-min-microvolt = <1220000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <240>;
- };
-
- mt6397_vgp2_reg: ldo_vgp2 {
- egulator-compatible = "ldo_vgp2";
- regulator-name = "vcamio";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vgp3_reg: ldo_vgp3 {
- regulator-compatible = "ldo_vgp3";
- regulator-name = "vcamaf";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vgp4_reg: ldo_vgp4 {
- regulator-compatible = "ldo_vgp4";
- regulator-name = "vgp4";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vgp5_reg: ldo_vgp5 {
- regulator-compatible = "ldo_vgp5";
- regulator-name = "vgp5";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3000000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vgp6_reg: ldo_vgp6 {
- regulator-compatible = "ldo_vgp6";
- regulator-name = "vgp6";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
-
- mt6397_vibr_reg: ldo_vibr {
- regulator-compatible = "ldo_vibr";
- regulator-name = "vibr";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3300000>;
- regulator-enable-ramp-delay = <218>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
index 835b53302db8..ec04adfb9d1c 100644
--- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
@@ -17,10 +17,13 @@ description: |
Datasheet is available at
https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf
-#The valid names for PCA9450 regulator nodes are:
-#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6,
-#LDO1, LDO2, LDO3, LDO4, LDO5
-#Note: Buck3 removed on PCA9450B and connect with Buck1 on PCA9450C.
+ Support PF9453, Datasheet is available at
+ https://www.nxp.com/docs/en/data-sheet/PF9453_SDS.pdf
+
+# The valid names for PCA9450 regulator nodes are:
+# BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6,
+# LDO1, LDO2, LDO3, LDO4, LDO5
+# Note: Buck3 removed on PCA9450B and connect with Buck1 on PCA9450C.
properties:
compatible:
@@ -28,6 +31,9 @@ properties:
- nxp,pca9450a
- nxp,pca9450b
- nxp,pca9450c
+ - nxp,pca9451a
+ - nxp,pca9452
+ - nxp,pf9453
reg:
maxItems: 1
@@ -35,13 +41,50 @@ properties:
interrupts:
maxItems: 1
+ inl1-supply:
+ description: Regulator supply for the INL1 pin group, powering LDOx
+
+ inb13-supply:
+ description:
+ Regulator supply for the INB13 pin group, powering BUCK1 and BUCK3.
+
+ inb26-supply:
+ description:
+ Regulator supply for the INB26 pin group, powering BUCK2 and BUCK6.
+
+ inb45-supply:
+ description:
+ Regulator supply for the INB45 pin group, powering BUCK4 and BUCK5.
+
regulators:
type: object
description: |
list of regulators provided by this controller
+ properties:
+ LDO5:
+ type: object
+ $ref: regulator.yaml#
+ description:
+ Properties for single LDO5 regulator.
+
+ properties:
+ nxp,sd-vsel-fixed-low:
+ type: boolean
+ description:
+ Let the driver know that SD_VSEL is hardwired to low level and
+ there is no GPIO to get the actual value from.
+
+ sd-vsel-gpios:
+ description:
+ GPIO that can be used to read the current status of the SD_VSEL
+ signal in order for the driver to know if LDO5CTRL_L or LDO5CTRL_H
+ is used by the hardware.
+
+ unevaluatedProperties: false
+
patternProperties:
- "^LDO[1-5]$":
+ "^LDO([1-4]|-SNVS)$":
type: object
$ref: regulator.yaml#
description:
@@ -57,7 +100,7 @@ properties:
properties:
nxp,dvs-run-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 600000
maximum: 2187500
description:
@@ -65,22 +108,26 @@ properties:
dvs(dynamic voltage scaling) property.
nxp,dvs-standby-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 600000
maximum: 2187500
description:
PMIC default "STANDBY" state voltage in uV. Only Buck1~3 have such
dvs(dynamic voltage scaling) property.
+ regulator-allowed-modes:
+ description: |
+ Buck regulator operating modes allowed. Valid values below.
+ Users should use the macros from dt-bindings/regulator/nxp,pca9450-regulator.h
+ 0 (PCA9450_BUCK_MODE_AUTO): Auto PFM/PWM mode
+ 1 (PCA9450_BUCK_MODE_FORCE_PWM): Forced PWM mode
+ items:
+ enum: [ 0, 1 ]
+
unevaluatedProperties: false
additionalProperties: false
- sd-vsel-gpios:
- description: GPIO that is used to switch LDO5 between being configured by
- LDO5CTRL_L or LDO5CTRL_H register. Use this if the SD_VSEL signal is
- connected to a host GPIO.
-
nxp,i2c-lt-enable:
type: boolean
description:
@@ -92,17 +139,59 @@ properties:
When WDOG_B signal is asserted a warm reset will be done instead of cold
reset.
+ nxp,pmic-on-req-on-debounce-us:
+ enum: [ 120, 20000, 100000, 750000 ]
+ description: Debounce time for PMIC_ON_REQ high.
+
+ nxp,pmic-on-req-off-debounce-us:
+ enum: [ 120, 2000 ]
+ description: Debounce time for PMIC_ON_REQ is asserted low
+
+ nxp,power-on-step-ms:
+ enum: [ 1, 2, 4, 8]
+ description: Time step configuration during power on sequence
+
+ nxp,power-down-step-ms:
+ enum: [ 2, 4, 8, 16 ]
+ description: Time step configuration during power down sequence
+
+ nxp,restart-ms:
+ enum: [ 250, 500 ]
+ description: Time to stay off regulators during Cold reset
+
+ npx,pmic-rst-b-debounce-ms:
+ enum: [ 10, 50, 100, 500, 1000, 2000, 4000, 8000 ]
+ description: PMIC_RST_B debounce time
+
required:
- compatible
- reg
- - interrupts
- regulators
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,pf9453
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^LDO[3-4]$": false
+ "^BUCK[5-6]$": false
+ else:
+ properties:
+ regulators:
+ properties:
+ LDO-SNVS: false
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/regulator/nxp,pca9450-regulator.h>
i2c {
#address-cells = <1>;
@@ -139,6 +228,8 @@ examples:
regulator-max-microvolt = <3400000>;
regulator-boot-on;
regulator-always-on;
+ regulator-initial-mode = <PCA9450_BUCK_MODE_FORCE_PWM>;
+ regulator-allowed-modes = <PCA9450_BUCK_MODE_FORCE_PWM>;
};
buck5: BUCK5 {
regulator-name = "BUCK5";
@@ -146,6 +237,8 @@ examples:
regulator-max-microvolt = <3400000>;
regulator-boot-on;
regulator-always-on;
+ regulator-allowed-modes = <PCA9450_BUCK_MODE_AUTO
+ PCA9450_BUCK_MODE_FORCE_PWM>;
};
buck6: BUCK6 {
regulator-name = "BUCK6";
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf0900.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf0900.yaml
new file mode 100644
index 000000000000..8c8fc2cd4ced
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/nxp,pf0900.yaml
@@ -0,0 +1,163 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/nxp,pf0900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PF0900 Power Management Integrated Circuit regulators
+
+maintainers:
+ - Joy Zou <joy.zou@nxp.com>
+
+description:
+ The PF0900 is a power management integrated circuit (PMIC) optimized
+ for high performance i.MX9x based applications. It features five high
+ efficiency buck converters, three linear and one vaon regulators. It
+ provides low quiescent current in Standby and low power off Modes.
+
+properties:
+ compatible:
+ enum:
+ - nxp,pf0900
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ vaon:
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ patternProperties:
+ "^ldo[1-3]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ "^sw[1-5]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ nxp,i2c-crc-enable:
+ type: boolean
+ description:
+ The CRC enabled during register read/write. Controlled by customer
+ unviewable fuse bits OTP_I2C_CRC_EN. Check chip part number.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@8 {
+ compatible = "nxp,pf0900";
+ reg = <0x08>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <89 IRQ_TYPE_LEVEL_LOW>;
+ nxp,i2c-crc-enable;
+
+ regulators {
+ vaon {
+ regulator-name = "VAON";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw1 {
+ regulator-name = "SW1";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1950>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-max-microvolt = <650000>;
+ regulator-suspend-min-microvolt = <650000>;
+ };
+ };
+
+ sw2 {
+ regulator-name = "SW2";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1950>;
+ };
+
+ sw3 {
+ regulator-name = "SW3";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1950>;
+ };
+
+ sw4 {
+ regulator-name = "SW4";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1950>;
+ };
+
+ sw5 {
+ regulator-name = "SW5";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1950>;
+ };
+
+ ldo1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf5300.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf5300.yaml
new file mode 100644
index 000000000000..5b9d5d4e48d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/nxp,pf5300.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/nxp,pf5300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PF5300/PF5301/PF5302 PMIC regulators
+
+maintainers:
+ - Woodrow Douglass <wdouglass@carnegierobotics.com>
+
+description: |
+ The PF5300, PF5301, and PF5302 integrate high-performance buck converters,
+ 12 A, 8 A, and 15 A, respectively, to power high-end automotive and industrial
+ processors. With adaptive voltage positioning and a high-bandwidth loop, they
+ offer transient regulation to minimize capacitor requirements.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: nxp,pf5300
+ - items:
+ - enum:
+ - nxp,pf5301
+ - nxp,pf5302
+ - const: nxp,pf5300
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@28 {
+ compatible = "nxp,pf5302", "nxp,pf5300";
+ reg = <0x28>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <500000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
index aabf50f5b39e..894bdbca78a2 100644
--- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
@@ -38,12 +38,6 @@ properties:
description:
Properties for single LDO regulator.
- properties:
- regulator-name:
- pattern: "^ldo[1-4]$"
- description:
- should be "ldo1", ..., "ldo4"
-
unevaluatedProperties: false
"^buck[1-7]$":
@@ -53,13 +47,8 @@ properties:
Properties for single BUCK regulator.
properties:
- regulator-name:
- pattern: "^buck[1-7]$"
- description:
- should be "buck1", ..., "buck7"
-
nxp,ilim-ma:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 2100
maximum: 4500
deprecated: true
@@ -75,7 +64,7 @@ properties:
4500
nxp,phase-shift:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 0
enum: [ 0, 45, 90, 135, 180, 225, 270, 315 ]
description:
@@ -90,12 +79,6 @@ properties:
description:
Properties for single VSNVS regulator.
- properties:
- regulator-name:
- pattern: "^vsnvs$"
- description:
- should be "vsnvs"
-
unevaluatedProperties: false
additionalProperties: false
@@ -109,7 +92,7 @@ additionalProperties: false
examples:
- |
- i2c1 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
index eb61e04ef852..b5181719daa1 100644
--- a/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
+++ b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml
@@ -48,10 +48,12 @@ properties:
"^LDO[1-4]$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
"^BUCK|BOOST$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml
index a26bbd68b729..0eda44752cdd 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml
@@ -36,6 +36,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
fsl,pfuze-support-disable-sw:
$ref: /schemas/types.yaml#/definitions/flag
description: |
@@ -63,20 +66,24 @@ properties:
patternProperties:
"^sw([1-4]|[1-4][a-c]|[1-4][a-c][a-c])$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
"^vgen[1-6]$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
"^vldo[1-4]$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
"^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$":
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml
index 82b6f2fde422..80ecf938b749 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/regulator/pwm-regulator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for the Generic PWM Regulator
+title: Generic PWM Regulator
maintainers:
- Brian Norris <briannorris@chromium.org>
@@ -64,6 +64,7 @@ properties:
defined, <100> is assumed, meaning that
pwm-dutycycle-range contains values expressed in
percent.
+ $ref: /schemas/types.yaml#/definitions/uint32
default: 100
pwm-dutycycle-range:
diff --git a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
new file mode 100644
index 000000000000..47c425c9fff1
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
@@ -0,0 +1,244 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,qca6390-pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. QCA6390 PMU Regulators
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+ The QCA6390 package contains discrete modules for WLAN and Bluetooth. They
+ are powered by the Power Management Unit (PMU) that takes inputs from the
+ host and provides LDO outputs. This document describes this module.
+
+properties:
+ compatible:
+ enum:
+ - qcom,qca6390-pmu
+ - qcom,wcn6750-pmu
+ - qcom,wcn6855-pmu
+ - qcom,wcn7850-pmu
+
+ vdd-supply:
+ description: VDD supply regulator handle
+
+ vddaon-supply:
+ description: VDD_AON supply regulator handle
+
+ vddasd-supply:
+ description: VDD_ASD supply regulator handle
+
+ vdddig-supply:
+ description: VDD_DIG supply regulator handle
+
+ vddpmu-supply:
+ description: VDD_PMU supply regulator handle
+
+ vddpmumx-supply:
+ description: VDD_PMU_MX supply regulator handle
+
+ vddpmucx-supply:
+ description: VDD_PMU_CX supply regulator handle
+
+ vddio1p2-supply:
+ description: VDD_IO_1P2 supply regulator handle
+
+ vddrfa0p8-supply:
+ description: VDD_RFA_0P8 supply regulator handle
+
+ vddrfa0p95-supply:
+ description: VDD_RFA_0P95 supply regulator handle
+
+ vddrfa1p2-supply:
+ description: VDD_RFA_1P2 supply regulator handle
+
+ vddrfa1p3-supply:
+ description: VDD_RFA_1P3 supply regulator handle
+
+ vddrfa1p7-supply:
+ description: VDD_RFA_1P7 supply regulator handle
+
+ vddrfa1p8-supply:
+ description: VDD_RFA_1P8 supply regulator handle
+
+ vddrfa1p9-supply:
+ description: VDD_RFA_1P9 supply regulator handle
+
+ vddrfa2p2-supply:
+ description: VDD_RFA_2P2 supply regulator handle
+
+ vddpcie1p3-supply:
+ description: VDD_PCIE_1P3 supply regulator handle
+
+ vddpcie1p9-supply:
+ description: VDD_PCIE_1P9 supply regulator handle
+
+ vddio-supply:
+ description: VDD_IO supply regulator handle
+
+ wlan-enable-gpios:
+ maxItems: 1
+ description: GPIO line enabling the ATH11K WLAN module supplied by the PMU
+
+ bt-enable-gpios:
+ maxItems: 1
+ description: GPIO line enabling the Bluetooth module supplied by the PMU
+
+ swctrl-gpios:
+ maxItems: 1
+ description: GPIO line indicating the state of the clock supply to the BT module
+
+ xo-clk-gpios:
+ maxItems: 1
+ description: GPIO line allowing to select the XO clock configuration for the module
+
+ clocks:
+ maxItems: 1
+ description: Reference clock handle
+
+ regulators:
+ type: object
+ description:
+ LDO outputs of the PMU
+
+ patternProperties:
+ "^ldo[0-9]$":
+ $ref: regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - regulators
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,qca6390-pmu
+ then:
+ required:
+ - vddaon-supply
+ - vddpmu-supply
+ - vddrfa0p95-supply
+ - vddrfa1p3-supply
+ - vddrfa1p9-supply
+ - vddpcie1p3-supply
+ - vddpcie1p9-supply
+ - vddio-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,wcn6750-pmu
+ then:
+ required:
+ - vddaon-supply
+ - vddasd-supply
+ - vddpmu-supply
+ - vddrfa0p8-supply
+ - vddrfa1p2-supply
+ - vddrfa1p7-supply
+ - vddrfa2p2-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,wcn6855-pmu
+ then:
+ required:
+ - vddio-supply
+ - vddaon-supply
+ - vddpmu-supply
+ - vddpmumx-supply
+ - vddpmucx-supply
+ - vddrfa0p95-supply
+ - vddrfa1p3-supply
+ - vddrfa1p9-supply
+ - vddpcie1p3-supply
+ - vddpcie1p9-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,wcn7850-pmu
+ then:
+ required:
+ - vdd-supply
+ - vddio-supply
+ - vddaon-supply
+ - vdddig-supply
+ - vddrfa1p2-supply
+ - vddrfa1p8-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ pmu {
+ compatible = "qcom,qca6390-pmu";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+ vddaon-supply = <&vreg_s6a_0p95>;
+ vddpmu-supply = <&vreg_s2f_0p95>;
+ vddrfa0p95-supply = <&vreg_s2f_0p95>;
+ vddrfa1p3-supply = <&vreg_s8c_1p3>;
+ vddrfa1p9-supply = <&vreg_s5a_1p9>;
+ vddpcie1p3-supply = <&vreg_s8c_1p3>;
+ vddpcie1p9-supply = <&vreg_s5a_1p9>;
+ vddio-supply = <&vreg_s4a_1p8>;
+
+ wlan-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
new file mode 100644
index 000000000000..b4eb4001eb3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpm-regulator.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,rpm-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm RPM regulator
+
+description:
+ The Qualcomm RPM regulator is modelled as a subdevice of the RPM.
+
+ Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml
+ for information regarding the RPM node.
+
+ The regulator node houses sub-nodes for each regulator within the device.
+ Each sub-node is identified using the node's name, with valid values listed
+ for each of the pmics below.
+
+ For pm8058 l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15,
+ l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4,
+ lvs0, lvs1, ncp
+
+ For pm8901 l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3,
+ mvs
+
+ For pm8921 s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
+ l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28,
+ l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch,
+ ncp
+
+ For pm8018 s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
+ l12, l14, lvs1
+
+ For smb208 s1a, s1b, s2a, s2b
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,rpm-pm8058-regulators
+ - qcom,rpm-pm8901-regulators
+ - qcom,rpm-pm8921-regulators
+ - qcom,rpm-pm8018-regulators
+ - qcom,rpm-smb208-regulators
+
+patternProperties:
+ ".*-supply$":
+ description: Input supply phandle(s) for this node
+
+ "^((s|l|lvs)[0-9]*|s[1-2][a-b]|ncp|mvs|usb-switch|hdmi-switch)$":
+ description: List of regulators and its properties
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ properties:
+ bias-pull-down:
+ description: enable pull down of the regulator when inactive
+ type: boolean
+
+ qcom,switch-mode-frequency:
+ description: Frequency (Hz) of the switch-mode power supply
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 19200000
+ - 9600000
+ - 6400000
+ - 4800000
+ - 3840000
+ - 3200000
+ - 2740000
+ - 2400000
+ - 2130000
+ - 1920000
+ - 1750000
+ - 1600000
+ - 1480000
+ - 1370000
+ - 1280000
+ - 1200000
+
+ qcom,force-mode:
+ description: Indicates that the regulator should be forced to a particular mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # QCOM_RPM_FORCE_MODE_NONE do not force any mode
+ - 1 # QCOM_RPM_FORCE_MODE_LPM force into low power mode
+ - 2 # QCOM_RPM_FORCE_MODE_HPM force into high power mode
+ - 3 # QCOM_RPM_FORCE_MODE_AUTO allow regulator to automatically select its own mode
+ # based on realtime current draw, only for pm8921 smps and ftsmps
+
+ qcom,power-mode-hysteretic:
+ description: select that the power supply should operate in hysteretic mode,
+ instead of the default pwm mode
+ type: boolean
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |
+ #include <dt-bindings/mfd/qcom-rpm.h>
+ regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+ vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+
+ s1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+
+ bias-pull-down;
+
+ qcom,switch-mode-frequency = <3200000>;
+ };
+
+ pm8921_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+
+ qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
index 90c3bda31c23..58bb0ad5dda4 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
@@ -8,7 +8,7 @@ title: Qualcomm Technologies, Inc. RPMh Regulators
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description: |
rpmh-regulator devices support PMIC regulator management via the Voltage
@@ -40,18 +40,29 @@ description: |
For PM660, smps1 - smps6, ldo1 - ldo3, ldo5 - ldo19
For PM660L, smps1 - smps3, smps5, ldo1 - ldo8, bob
For PM7325, smps1 - smps8, ldo1 - ldo19
+ For PM7550, smps1 - smps6, ldo1 - ldo23, bob
For PM8005, smps1 - smps4
For PM8009, smps1 - smps2, ldo1 - ldo7
+ For PM8010, ldo1 - ldo7
For PM8150, smps1 - smps10, ldo1 - ldo18
For PM8150L, smps1 - smps8, ldo1 - ldo11, bob, flash, rgb
For PM8350, smps1 - smps12, ldo1 - ldo10
For PM8350C, smps1 - smps10, ldo1 - ldo13, bob
For PM8450, smps1 - smps6, ldo1 - ldo4
+ For PM8550, smps1 - smps6, ldo1 - ldo17, bob1 - bob2
For PM8998, smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+ For PMH0101, ldo1 - ldo18, bob1 - bob2
+ For PMH0104, smps1 - smps4
+ For PMH0110, smps1 - smps10, ldo1 - ldo4
For PMI8998, bob
+ For PMC8380, smps1 - smps8, ldo1 - lodo3
+ For PMCX0102, smps1 - smps10, ldo1 - ldo4
For PMR735A, smps1 - smps3, ldo1 - ldo7
+ For PMR735B, ldo1 - ldo12
+ For PMR735D, ldo1 - ldo7
For PMX55, smps1 - smps7, ldo1 - ldo16
For PMX65, smps1 - smps8, ldo1 - ldo21
+ For PMX75, smps1 - smps10, ldo1 - ldo21
properties:
compatible:
@@ -62,28 +73,44 @@ properties:
- qcom,pm660-rpmh-regulators
- qcom,pm660l-rpmh-regulators
- qcom,pm7325-rpmh-regulators
+ - qcom,pm7550-rpmh-regulators
- qcom,pm8005-rpmh-regulators
- qcom,pm8009-rpmh-regulators
- qcom,pm8009-1-rpmh-regulators
+ - qcom,pm8010-rpmh-regulators
- qcom,pm8150-rpmh-regulators
- qcom,pm8150l-rpmh-regulators
- qcom,pm8350-rpmh-regulators
- qcom,pm8350c-rpmh-regulators
- qcom,pm8450-rpmh-regulators
+ - qcom,pm8550-rpmh-regulators
+ - qcom,pm8550ve-rpmh-regulators
+ - qcom,pm8550vs-rpmh-regulators
- qcom,pm8998-rpmh-regulators
+ - qcom,pmc8180-rpmh-regulators
+ - qcom,pmc8180c-rpmh-regulators
+ - qcom,pmc8380-rpmh-regulators
+ - qcom,pmcx0102-rpmh-regulators
- qcom,pmg1110-rpmh-regulators
+ - qcom,pmh0101-rpmh-regulators
+ - qcom,pmh0104-rpmh-regulators
+ - qcom,pmh0110-rpmh-regulators
- qcom,pmi8998-rpmh-regulators
- qcom,pmm8155au-rpmh-regulators
+ - qcom,pmm8654au-rpmh-regulators
- qcom,pmr735a-rpmh-regulators
+ - qcom,pmr735b-rpmh-regulators
+ - qcom,pmr735d-rpmh-regulators
- qcom,pmx55-rpmh-regulators
- qcom,pmx65-rpmh-regulators
+ - qcom,pmx75-rpmh-regulators
qcom,pmic-id:
description: |
RPMh resource name suffix used for the regulators found
on this PMIC.
$ref: /schemas/types.yaml#/definitions/string
- enum: [a, b, c, d, e, f, h, k]
+ pattern: "^[a-n]|[A-N]_E[0-3]+$"
qcom,always-wait-for-ack:
description: |
@@ -101,18 +128,20 @@ properties:
bob:
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
description: BOB regulator node.
dependencies:
- regulator-allow-set-load: ["regulator-allowed-modes"]
+ regulator-allow-set-load: [ regulator-allowed-modes ]
patternProperties:
- "^(smps|ldo|lvs)[0-9]+$":
+ "^(smps|ldo|lvs|bob)[0-9]+$":
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
description: smps/ldo regulator nodes(s).
dependencies:
- regulator-allow-set-load: ["regulator-allowed-modes"]
+ regulator-allow-set-load: [ regulator-allowed-modes ]
required:
- compatible
@@ -140,6 +169,8 @@ allOf:
compatible:
enum:
- qcom,pm6150l-rpmh-regulators
+ - qcom,pm8150l-rpmh-regulators
+ - qcom,pmc8180c-rpmh-regulators
then:
properties:
vdd-bob-supply:
@@ -205,7 +236,27 @@ allOf:
properties:
compatible:
enum:
+ - qcom,pm7550-rpmh-regulators
+ then:
+ properties:
+ vdd-bob-supply:
+ description: BOB regulator parent supply phandle.
+ vdd-l2-l3-supply: true
+ vdd-l4-l5-supply: true
+ vdd-l9-l10-supply: true
+ vdd-l12-l14-supply: true
+ vdd-l13-l16-supply: true
+ vdd-l15-l17-l18-l19-l20-l21-l22-l23-supply: true
+ patternProperties:
+ "^vdd-l(1|[6-8]|11)-supply$": true
+ "^vdd-s[1-6]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
- qcom,pm8005-rpmh-regulators
+ - qcom,pmh0104-rpmh-regulators
then:
patternProperties:
"^vdd-s[1-4]-supply$": true
@@ -227,7 +278,20 @@ allOf:
properties:
compatible:
enum:
+ - qcom,pm8010-rpmh-regulators
+ then:
+ properties:
+ vdd-l1-l2-supply: true
+ vdd-l3-l4-supply: true
+ patternProperties:
+ "^vdd-l[5-7]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
- qcom,pm8150-rpmh-regulators
+ - qcom,pmc8180-rpmh-regulators
- qcom,pmm8155au-rpmh-regulators
then:
properties:
@@ -244,18 +308,17 @@ allOf:
properties:
compatible:
enum:
- - qcom,pm8150l-rpmh-regulators
+ - qcom,pmm8654au-rpmh-regulators
then:
properties:
- vdd-bob-supply:
- description: BOB regulator parent supply phandle.
- vdd-l1-l8-supply: true
+ vdd-l1-supply: true
vdd-l2-l3-supply: true
- vdd-l4-l5-l6-supply: true
- vdd-l7-l11-supply: true
- vdd-l9-l10-supply: true
+ vdd-l4-supply: true
+ vdd-l5-supply: true
+ vdd-l6-l7-supply: true
+ vdd-l8-l9-supply: true
patternProperties:
- "^vdd-s[1-8]-supply$": true
+ "^vdd-s[1-9]-supply$": true
- if:
properties:
@@ -303,6 +366,33 @@ allOf:
properties:
compatible:
enum:
+ - qcom,pm8550-rpmh-regulators
+ then:
+ properties:
+ vdd-l1-l4-l10-supply: true
+ vdd-l2-l13-l14-supply: true
+ vdd-l5-l16-supply: true
+ vdd-l6-l7-supply: true
+ vdd-l8-l9-supply: true
+ patternProperties:
+ "^vdd-l(3|1[1-7])-supply$": true
+ "^vdd-s[1-6]-supply$": true
+ "^vdd-bob[1-2]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,pm8550vs-rpmh-regulators
+ then:
+ patternProperties:
+ "^vdd-l[1-3]-supply$": true
+ "^vdd-s[1-6]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
- qcom,pm8998-rpmh-regulators
then:
properties:
@@ -327,6 +417,17 @@ allOf:
properties:
compatible:
enum:
+ - qcom,pmc8380-rpmh-regulators
+ - qcom,pm8550ve-rpmh-regulators
+ then:
+ patternProperties:
+ "^vdd-l[1-3]-supply$": true
+ "^vdd-s[1-8]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
- qcom,pmg1110-rpmh-regulators
then:
properties:
@@ -336,6 +437,34 @@ allOf:
properties:
compatible:
enum:
+ - qcom,pmh0101-rpmh-regulators
+ then:
+ properties:
+ vdd-l1-l4-l10-supply: true
+ vdd-l2-l13-l14-supply: true
+ vdd-l3-l11-supply: true
+ vdd-l5-l16-supply: true
+ vdd-l6-l7-supply: true
+ vdd-l8-l9-supply: true
+ patternProperties:
+ "^vdd-l(1[2578])-supply$": true
+ "^vdd-bob[1-2]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,pmcx0102-rpmh-regulators
+ - qcom,pmh0110-rpmh-regulators
+ then:
+ patternProperties:
+ "^vdd-l[1-4]-supply$": true
+ "^vdd-s([1-9]|10)-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
- qcom,pmi8998-rpmh-regulators
then:
properties:
@@ -361,6 +490,30 @@ allOf:
properties:
compatible:
enum:
+ - qcom,pmr735b-rpmh-regulators
+ then:
+ properties:
+ vdd-l1-l2-supply: true
+ vdd-l7-l8-supply: true
+ patternProperties:
+ "^vdd-l([3-6]|9|1[0-2])-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,pmr735d-rpmh-regulators
+ then:
+ properties:
+ vdd-l1-l2-l5-supply: true
+ vdd-l3-l4-supply: true
+ patternProperties:
+ "^vdd-l[6-7]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ enum:
- qcom,pmx55-rpmh-regulators
then:
properties:
@@ -387,10 +540,28 @@ allOf:
vdd-l11-l13-supply: true
patternProperties:
"^vdd-l[1347]-supply$": true
- "^vdd-l1[0245789]-supply$": true
+ "^vdd-l1[024579]-supply$": true
"^vdd-l2[01]-supply$": true
"^vdd-s[1-8]-supply$": true
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,pmx75-rpmh-regulators
+ then:
+ properties:
+ vdd-l2-l18-supply: true
+ vdd-l4-l16-supply: true
+ vdd-l5-l6-supply: true
+ vdd-l8-l9-supply: true
+ vdd-l11-l13-supply: true
+ vdd-l20-l21-supply: true
+ patternProperties:
+ "^vdd-l[137]-supply$": true
+ "^vdd-l1[024579]-supply$": true
+ "^vdd-s([1-9]|10)-supply$": true
+
unevaluatedProperties: false
examples:
@@ -412,9 +583,8 @@ examples:
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
- regulator-allowed-modes =
- <RPMH_REGULATOR_MODE_LPM
- RPMH_REGULATOR_MODE_HPM>;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
regulator-allow-set-load;
};
@@ -431,9 +601,8 @@ examples:
bob {
regulator-min-microvolt = <3312000>;
regulator-max-microvolt = <3600000>;
- regulator-allowed-modes =
- <RPMH_REGULATOR_MODE_AUTO
- RPMH_REGULATOR_MODE_HPM>;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_AUTO
+ RPMH_REGULATOR_MODE_HPM>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
};
};
diff --git a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
new file mode 100644
index 000000000000..40f9223d4c27
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. REFGEN Regulator
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The REFGEN (reference voltage generator) regulator provides reference
+ voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sc7180-refgen-regulator
+ - qcom,sc8180x-refgen-regulator
+ - qcom,sdm670-refgen-regulator
+ - qcom,sm8150-refgen-regulator
+ - const: qcom,sdm845-refgen-regulator
+
+ - items:
+ - enum:
+ - qcom,qcs8300-refgen-regulator
+ - qcom,sa8775p-refgen-regulator
+ - qcom,sc7280-refgen-regulator
+ - qcom,sc8280xp-refgen-regulator
+ - qcom,sm6350-refgen-regulator
+ - qcom,sm6375-refgen-regulator
+ - qcom,sm8350-refgen-regulator
+ - const: qcom,sm8250-refgen-regulator
+
+ - enum:
+ - qcom,sdm845-refgen-regulator
+ - qcom,sm8250-refgen-regulator
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ regulator@162f000 {
+ compatible = "qcom,sm8250-refgen-regulator";
+ reg = <0x0162f000 0x84>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
index 961eed51912c..b7241ce975b9 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml
@@ -22,7 +22,7 @@ description:
Each sub-node is identified using the node's name, with valid values listed
for each of the pmics below.
- For mp5496, s2
+ For mp5496, s1, s2, l2, l5
For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22
@@ -47,6 +47,9 @@ description:
For pm8916, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
l12, l13, l14, l15, l16, l17, l18
+ For pm8937, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10,
+ l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23
+
For pm8941, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
lvs3, 5vs1, 5vs2
@@ -71,6 +74,8 @@ description:
For pmi8998, bob
+ For pmr735a, s1, s2, s3, l1, l2, l3, l4, l5, l6, l7
+
For pms405, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
l12, l13
@@ -90,6 +95,7 @@ properties:
- qcom,rpm-pm8841-regulators
- qcom,rpm-pm8909-regulators
- qcom,rpm-pm8916-regulators
+ - qcom,rpm-pm8937-regulators
- qcom,rpm-pm8941-regulators
- qcom,rpm-pm8950-regulators
- qcom,rpm-pm8953-regulators
@@ -98,6 +104,7 @@ properties:
- qcom,rpm-pma8084-regulators
- qcom,rpm-pmi8994-regulators
- qcom,rpm-pmi8998-regulators
+ - qcom,rpm-pmr735a-regulators
- qcom,rpm-pms405-regulators
patternProperties:
@@ -107,6 +114,7 @@ patternProperties:
"^((s|l|lvs|5vs)[0-9]*)|(boost-bypass)|(bob)$":
description: List of regulators and its properties
$ref: regulator.yaml#
+ unevaluatedProperties: false
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml
index bdf34c2de96b..aea849e8eadf 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.yaml
@@ -17,12 +17,16 @@ properties:
- qcom,pm660l-regulators
- qcom,pm8004-regulators
- qcom,pm8005-regulators
+ - qcom,pm8019-regulators
- qcom,pm8226-regulators
- qcom,pm8841-regulators
+ - qcom,pm8909-regulators
- qcom,pm8916-regulators
+ - qcom,pm8937-regulators
- qcom,pm8941-regulators
- qcom,pm8950-regulators
- qcom,pm8994-regulators
+ - qcom,pma8084-regulators
- qcom,pmi8994-regulators
- qcom,pmp8074-regulators
- qcom,pms405-regulators
@@ -32,7 +36,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
patternProperties:
- "^(5vs[1-2]|(l|s)[1-9][0-9]?|lvs[1-3])$":
+ "^(5vs[1-2]|(l|s)[1-9][0-9]?|lvs[1-4])$":
description: List of regulators and its properties
type: object
$ref: regulator.yaml#
@@ -181,6 +185,25 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pm8019-regulators
+ then:
+ properties:
+ vdd_l1-supply: true
+ vdd_l2_l3-supply: true
+ vdd_l4_l5_l6-supply: true
+ vdd_l7_l8_l11-supply: true
+ vdd_l9-supply: true
+ vdd_l10-supply: true
+ vdd_l12-supply: true
+ vdd_l13_l14-supply: true
+ patternProperties:
+ "^vdd_s[1-4]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pm8226-regulators
then:
properties:
@@ -211,6 +234,24 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pm8909-regulators
+ then:
+ properties:
+ vdd_s1-supply: true
+ vdd_s2-supply: true
+ vdd_l1-supply: true
+ vdd_l2_l5-supply: true
+ vdd_l3_l6_l10-supply: true
+ vdd_l4_l7-supply: true
+ vdd_l8_l11_l15_l18-supply: true
+ vdd_l9_l12_l14_l17-supply: true
+ vdd_l13-supply: true
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pm8916-regulators
then:
properties:
@@ -256,6 +297,24 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pm8937-regulators
+ then:
+ properties:
+ vdd_l1_l19-supply: true
+ vdd_l20_l21-supply: true
+ vdd_l2_l23-supply: true
+ vdd_l3-supply: true
+ vdd_l4_l5_l6_l7_l16-supply: true
+ vdd_l8_l11_l12_l17_l22-supply: true
+ vdd_l9_l10_l13_l14_l15_l18-supply: true
+ patternProperties:
+ "^vdd_s[1-6]-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pm8950-regulators
then:
properties:
@@ -300,6 +359,32 @@ allOf:
compatible:
contains:
enum:
+ - qcom,pma8084-regulators
+ then:
+ properties:
+ vdd_l1_l11-supply: true
+ vdd_l2_l3_l4_l27-supply: true
+ vdd_l5_l7-supply: true
+ vdd_l6_l12_l14_l15_l26-supply: true
+ vdd_l8-supply: true
+ vdd_l9_l10_l13_l20_l23_l24-supply: true
+ vdd_l16_l25-supply: true
+ vdd_l17-supply: true
+ vdd_l18-supply: true
+ vdd_l19-supply: true
+ vdd_l21-supply: true
+ vdd_l22-supply: true
+ vdd_lvs1_2-supply: true
+ vdd_lvs3_4-supply: true
+ vdd_5vs1-supply: true
+ patternProperties:
+ "^vdd_s([1-9]|1[0-2])-supply$": true
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
- qcom,pmi8994-regulators
then:
properties:
diff --git a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
index dbe78cd4adba..fcefc722ee2a 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -14,10 +14,21 @@ description: |
regulator will be enabled in situations where the device is required to
provide power to the connected peripheral.
+allOf:
+ - $ref: regulator.yaml#
+
properties:
compatible:
- enum:
- - qcom,pm8150b-vbus-reg
+ oneOf:
+ - enum:
+ - qcom,pm8150b-vbus-reg
+ - items:
+ - enum:
+ - qcom,pm4125-vbus-reg
+ - qcom,pm6150-vbus-reg
+ - qcom,pm7250b-vbus-reg
+ - qcom,pmi632-vbus-reg
+ - const: qcom,pm8150b-vbus-reg
reg:
maxItems: 1
@@ -25,17 +36,23 @@ properties:
required:
- compatible
+ - reg
+ - regulator-min-microamp
+ - regulator-max-microamp
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- pm8150b {
+ pmic {
#address-cells = <1>;
#size-cells = <0>;
- pm8150b_vbus: dcdc@1100 {
+
+ usb-vbus-regulator@1100 {
compatible = "qcom,pm8150b-vbus-reg";
reg = <0x1100>;
+ regulator-min-microamp = <500000>;
+ regulator-max-microamp = <3000000>;
};
};
...
diff --git a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
index f97b8083678f..83965076d6ab 100644
--- a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -16,11 +16,17 @@ description:
properties:
compatible:
- const: qcom,pmi8998-lab-ibb
+ oneOf:
+ - const: qcom,pmi8998-lab-ibb
+ - items:
+ - enum:
+ - qcom,pmi8950-lab-ibb
+ - const: qcom,pmi8998-lab-ibb
lab:
type: object
- additionalProperties: false
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
properties:
qcom,soft-start-us:
@@ -46,7 +52,8 @@ properties:
ibb:
type: object
- additionalProperties: false
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
properties:
qcom,discharge-resistor-kohms:
diff --git a/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator-v2.yaml b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator-v2.yaml
new file mode 100644
index 000000000000..37b9ed371b67
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator-v2.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/raspberrypi,7inch-touchscreen-panel-regulator-v2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RaspberryPi 5" and 7" display V2 MCU-based regulator/backlight controller
+
+maintainers:
+ - Marek Vasut <marek.vasut+renesas@mailbox.org>
+
+description: |
+ The RaspberryPi 5" and 7" display 2 has an MCU-based regulator, PWM
+ backlight and GPIO controller on the PCB, which is used to turn the
+ display unit on/off and control the backlight.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ const: raspberrypi,touchscreen-panel-regulator-v2
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+ "#gpio-cells":
+ const: 2
+ description:
+ The first cell is the pin number, and the second cell is used to
+ specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
+
+ "#pwm-cells":
+ const: 3
+ description: See ../../pwm/pwm.yaml for description of the cell formats.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+ - "#pwm-cells"
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ regulator@45 {
+ compatible = "raspberrypi,touchscreen-panel-regulator-v2";
+ reg = <0x45>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #pwm-cells = <3>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml
index 0ae25d119b6f..41678400e63f 100644
--- a/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml
@@ -15,7 +15,7 @@ description: |
and control the backlight.
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
index 1c4bfe786736..bcf788897e44 100644
--- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
@@ -35,7 +35,7 @@ information for that regulator. The definition for each of these
nodes is defined using the standard binding for regulators found at
<Documentation/devicetree/bindings/regulator/regulator.txt>.
-Theres are also additional properties for SD/LDOs. These additional properties
+There are also additional properties for SD/LDOs. These additional properties
are required to configure FPS configuration parameters for SDs and LDOs.
Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible
Power Sequence (FPS).
diff --git a/Documentation/devicetree/bindings/regulator/regulator-output.yaml b/Documentation/devicetree/bindings/regulator/regulator-output.yaml
new file mode 100644
index 000000000000..078b37a1a71a
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator-output.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/regulator/regulator-output.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator output connector
+
+maintainers:
+ - Zev Weiss <zev@bewilderbeest.net>
+
+description: |
+ This describes a power output connector supplied by a regulator,
+ such as a power outlet on a power distribution unit (PDU). The
+ connector may be standalone or merely one channel or set of pins
+ within a ganged physical connector carrying multiple independent
+ power outputs.
+
+properties:
+ compatible:
+ const: regulator-output
+
+ vout-supply:
+ description:
+ Phandle of the regulator supplying the output.
+
+required:
+ - compatible
+ - vout-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ output {
+ compatible = "regulator-output";
+ vout-supply = <&output_reg>;
+ };
diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml
index 6e8aa9eed3aa..77573bcb6b79 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/regulator.yaml
@@ -13,7 +13,7 @@ maintainers:
properties:
regulator-name:
description: A string used as a descriptive name for regulator outputs
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
regulator-min-microvolt:
description: smallest voltage consumers may set
@@ -23,7 +23,7 @@ properties:
regulator-microvolt-offset:
description: Offset applied to voltages to compensate for voltage drops
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
regulator-min-microamp:
description: smallest current consumers may set
@@ -34,6 +34,9 @@ properties:
regulator-input-current-limit-microamp:
description: maximum input current regulator allows
+ regulator-power-budget-milliwatt:
+ description: power budget of the regulator
+
regulator-always-on:
description: boolean, regulator should never be disabled
type: boolean
@@ -59,7 +62,7 @@ properties:
description: ramp delay for regulator(in uV/us) For hardware which supports
disabling ramp rate, it should be explicitly initialised to zero (regulator-ramp-delay
= <0>) for disabling ramp delay.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
regulator-enable-ramp-delay:
description: The time taken, in microseconds, for the supply rail to
@@ -68,7 +71,7 @@ properties:
required due to the combination of internal ramping of the regulator
itself, and board design issues such as trace capacitance and load
on the supply.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
regulator-settling-time-us:
description: Settling time, in microseconds, for voltage change if regulator
@@ -95,7 +98,7 @@ properties:
description: initial operating mode. The set of possible operating modes
depends on the capabilities of every hardware so each device binding
documentation explains which values the regulator supports.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
regulator-allowed-modes:
description: list of operating modes that software is allowed to configure
@@ -103,17 +106,22 @@ properties:
The set of possible operating modes depends on the capabilities of
every hardware so each device binding document explains which values
the regulator supports.
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
regulator-system-load:
description: Load in uA present on regulator that is not captured by
any consumer request.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
regulator-pull-down:
description: Enable pull down resistor when the regulator is disabled.
type: boolean
+ system-critical-regulator:
+ description: Set if the regulator is critical to system stability or
+ functionality.
+ type: boolean
+
regulator-over-current-protection:
description: Enable over current protection.
type: boolean
@@ -126,7 +134,7 @@ properties:
regulator-oc-error-microamp:
description: Set over current error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested.
+ the hardware probably is malfunctional and damage prevention is requested.
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted.
@@ -146,7 +154,7 @@ properties:
regulator-ov-error-microvolt:
description: Set over voltage error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested
+ the hardware probably is malfunctional and damage prevention is requested
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted. Limit
is given as microvolt offset from voltage set to regulator.
@@ -168,7 +176,7 @@ properties:
regulator-uv-error-microvolt:
description: Set under voltage error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested
+ the hardware probably is malfunctional and damage prevention is requested
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted. Limit
is given as microvolt offset from voltage set to regulator.
@@ -181,6 +189,14 @@ properties:
be enabled but limit setting can be omitted. Limit is given as microvolt
offset from voltage set to regulator.
+ regulator-uv-less-critical-window-ms:
+ description: Specifies the time window (in milliseconds) following a
+ critical under-voltage event during which the system can continue to
+ operate safely while performing less critical operations. This property
+ provides a defined duration before a more severe reaction to the
+ under-voltage event is needed, allowing for certain non-urgent actions to
+ be carried out in preparation for potential power loss.
+
regulator-temp-protection-kelvin:
description: Set over temperature protection limit. This is a limit where
hardware performs emergency shutdown. Zero can be passed to disable
@@ -189,7 +205,7 @@ properties:
regulator-temp-error-kelvin:
description: Set over temperature error limit. This is a limit where part of
- the hardware propably is malfunctional and damage prevention is requested
+ the hardware probably is malfunctional and damage prevention is requested
Zero can be passed to disable error detection and value '1' indicates
that detection should be enabled but limit setting can be omitted.
@@ -206,14 +222,14 @@ properties:
0: Disable active discharge.
1: Enable active discharge.
Absence of this property will leave configuration to default.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
regulator-coupled-with:
description: Regulators with which the regulator is coupled. The linkage
is 2-way - all coupled regulators should be linked with each other.
A regulator should not be coupled with its supplier.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
maxItems: 1
@@ -221,7 +237,7 @@ properties:
description: Array of maximum spread between voltages of coupled regulators
in microvolts, each value in the array relates to the corresponding
couple specified by the regulator-coupled-with property.
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
regulator-max-step-microvolt:
description: Maximum difference between current and target voltages
@@ -231,7 +247,7 @@ patternProperties:
".*-supply$":
description: Input supply phandle(s) for this node
- regulator-state-(standby|mem|disk):
+ "^regulator-state-(standby|mem|disk)$":
type: object
description:
sub-nodes for regulator state in Standby, Suspend-to-RAM, and
@@ -269,7 +285,7 @@ patternProperties:
of possible operating modes depends on the capabilities of every
hardware so the valid modes are documented on each regulator device
tree binding document.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml b/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml
new file mode 100644
index 000000000000..97cff71d2967
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/renesas,raa215300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RAA215300 Power Management Integrated Circuit (PMIC)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The RAA215300 is a high-performance, low-cost 9-channel PMIC designed for
+ 32-bit and 64-bit MCU and MPU applications. It supports DDR3, DDR3L, DDR4,
+ and LPDDR4 memory power requirements. The internally compensated regulators,
+ built-in Real-Time Clock (RTC), 32kHz crystal oscillator, and coin cell
+ battery charger provide a highly integrated, small footprint power solution
+ ideal for System-On-Module (SOM) applications. A spread spectrum feature
+ provides an ease-of-use solution for noise-sensitive audio or RF applications.
+
+ This device exposes two devices via I2C. One for the integrated RTC IP, and
+ one for everything else.
+
+ Link to datasheet:
+ https://www.renesas.com/in/en/products/power-power-management/multi-channel-power-management-ics-pmics/ssdsoc-power-management-ics-pmic-and-pmus/raa215300-high-performance-9-channel-pmic-supporting-ddr-memory-built-charger-and-rtc
+
+properties:
+ compatible:
+ enum:
+ - renesas,raa215300
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: main
+ - const: rtc
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description: |
+ The clocks are optional. The RTC is disabled, if no clocks are
+ provided(either xin or clkin).
+ maxItems: 1
+
+ clock-names:
+ description: |
+ Use xin, if connected to an external crystal.
+ Use clkin, if connected to an external clock signal.
+ enum:
+ - xin
+ - clkin
+
+required:
+ - compatible
+ - reg
+ - reg-names
+
+additionalProperties: false
+
+examples:
+ - |
+ /* 32.768kHz crystal */
+ x2: x2-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ raa215300: pmic@12 {
+ compatible = "renesas,raa215300";
+ reg = <0x12>, <0x6f>;
+ reg-names = "main", "rtc";
+
+ clocks = <&x2>;
+ clock-names = "xin";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml
new file mode 100644
index 000000000000..6ceba022e550
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt4803.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT4803 Boost Regulator
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ RT4803 is a boost regulator that's designed to provide the minimum output
+ voltage, even if the input voltage is lower than the required voltage. It
+ supports boost and auto bypass mode that depends on the difference between the
+ input and output voltage. If the input is lower than the output, mode will
+ transform to boost mode. Otherwise, turn on bypass switch to enter bypass mode.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT4803/DS4803-03.pdf
+ https://www.richtek.com/assets/product_file/RT4803A/DS4803A-06.pdf
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt4803
+
+ reg:
+ maxItems: 1
+
+ richtek,vsel-active-high:
+ type: boolean
+ description: Specify the VSEL register group is using when system is active
+
+ regulator-allowed-modes:
+ description: |
+ Available operating mode
+ 1: Auto PFM/PWM
+ 2: Force PWM
+ items:
+ enum: [1, 2]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@75 {
+ compatible = "richtek,rt4803";
+ reg = <0x75>;
+ richtek,vsel-active-high;
+ regulator-name = "rt4803-regulator";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <4400000>;
+ regulator-allowed-modes = <1 2>;
+ regulator-always-on;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml
index d9c23333e157..cd06e957b9db 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt4831-regulator.yaml
@@ -29,6 +29,7 @@ patternProperties:
"^DSV(LCM|P|N)$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
description:
Properties for single Display Bias Voltage regulator.
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5133.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5133.yaml
new file mode 100644
index 000000000000..d2e007fee6ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt5133.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt5133.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5133 PMIC Regulator
+
+maintainers:
+ - ShihChia Chang <jeff_chang@richtek.com>
+
+description:
+ The RT5133 is an integrated Power Management IC for portable devices,
+ featuring 8 LDOs and 3 GPOs. It allows programmable output voltages,
+ soft-start times, and protections via I2C. GPO operation depends on LDO1
+ voltage.
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt5133
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ richtek,oc-shutdown-all:
+ type: boolean
+ description:
+ Controls the behavior when any LDO (Low Dropout Regulator) enters an
+ Over Current state.
+ If set to true, all LDO channels will be shut down.
+ If set to false, only the affected LDO channel will shut down itself.
+
+ richtek,pgb-shutdown-all:
+ type: boolean
+ description:
+ Controls the behavior when any LDO enters a Power Good Bad state.
+ If set to true, all LDO channels will be shut down.
+ If set to false, only the affected LDO channel will shut down itself.
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ properties:
+ base:
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for the base regulator, which is the top-level supply for
+ LDO1 to LDO6. It functions merely as an on/off switch rather than
+ regulating voltages. If none of LDO1 to LDO6 are in use, switching
+ off the base will reduce the quiescent current.
+
+ required:
+ - regulator-name
+
+ patternProperties:
+ "^ldo([1-6])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single LDO regulator
+
+ required:
+ - regulator-name
+
+ "^ldo([7-8])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single LDO regulator
+
+ properties:
+ vin-supply: true
+
+ required:
+ - regulator-name
+ - vin-supply
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@18 {
+ compatible = "richtek,rt5133";
+ reg = <0x18>;
+ wakeup-source;
+ interrupts-extended = <&gpio 0 IRQ_TYPE_EDGE_FALLING>;
+ enable-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ richtek,oc-shutdown-all;
+ richtek,pgb-shutdown-all;
+ regulators {
+ base {
+ regulator-name = "base";
+ };
+ pvin78: ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3199998>;
+ regulator-active-discharge = <1>;
+ };
+ ldo2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3200000>;
+ regulator-active-discharge = <1>;
+ };
+ ldo3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-active-discharge = <1>;
+ };
+ ldo4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-active-discharge = <1>;
+ };
+ ldo5 {
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-active-discharge = <1>;
+ };
+ ldo6 {
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-active-discharge = <1>;
+ };
+ ldo7 {
+ regulator-name = "ldo7";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-active-discharge = <1>;
+ vin-supply = <&pvin78>;
+ };
+ ldo8 {
+ regulator-name = "ldo8";
+ regulator-min-microvolt = <855000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-active-discharge = <1>;
+ vin-supply = <&pvin78>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml
index edb411be0390..89341fdaa3af 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml
@@ -11,7 +11,7 @@ maintainers:
description: |
The RT5190A integrates 1 channel buck controller, 3 channels high efficiency
- synchronous buck converters, 1 LDO, I2C control interface and peripherial
+ synchronous buck converters, 1 LDO, I2C control interface and peripheral
logical control.
It also supports mute AC OFF depop sound and quick setting storage while
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
new file mode 100644
index 000000000000..e95e046e9ed6
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT5739 Step-Down Buck Converter
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ The RT5739 is a step-down switching buck converter that can deliver the
+ programmable output voltage from 300mV to 1300mV with wide input voltage
+ supply of 2.5V to 5.5V. It can provide up to 3.5A continuous current
+ capability at over 80% high efficiency.
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt5733
+ - richtek,rt5739
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+
+ richtek,vsel-active-high:
+ description: |
+ If property is present, use the 'VSEL1' register group for buck control.
+ Else, use the 'VSEL0' register group. This depends on external hardware
+ 'VSEL' pin connection.
+ type: boolean
+
+ regulator-allowed-modes:
+ description: |
+ buck allowed operating mode
+ 0: Auto PFM/PWM mode
+ 1: Forced PWM mode
+ items:
+ enum: [0, 1]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@50 {
+ compatible = "richtek,rt5739";
+ reg = <0x50>;
+ enable-gpios = <&gpio26 1 GPIO_ACTIVE_HIGH>;
+ richtek,vsel-active-high;
+ regulator-name = "richtek,rt5739-buck";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-boot-on;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6190.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6190.yaml
new file mode 100644
index 000000000000..29f7d3d5d658
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt6190.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt6190.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT6190 4-Switch BuckBoost controller
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ The RT6190 is 4-Switch BuckBoost controller designed for converting input
+ voltage to output voltage that can be equal to, higher or lower than input
+ voltage. It operates with wide input voltage range from 4.5V to 36V, and
+ the output voltage can be set from 3V to 36V by external FB pin. It's commonly
+ used for the application like as BuckBoost bus supply, docking station and USB
+ power delivery product.
+
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT6190/DS6190-02.pdf
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt6190
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+
+ wakeup-source: true
+
+ interrupts:
+ maxItems: 1
+
+ regulator-allowed-modes:
+ description: |
+ buck allowed operating mode
+ 0: PSM mode (light load Power Saving Mode)
+ 1: FCCM mode (Forced-CCM mode)
+ maxItems: 2
+ items:
+ enum: [0, 1]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@2c {
+ compatible = "richtek,rt6190";
+ reg = <0x2c>;
+ wakeup-source;
+ interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
+ enable-gpios = <&gpio26 1 GPIO_ACTIVE_HIGH>;
+ regulator-name = "richtek,rt6190-buckboost";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <32000000>;
+ regulator-min-microamp = <306000>;
+ regulator-max-microamp = <12114000>;
+ regulator-allowed-modes = <0 1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml
index e983d0e70c9b..84546fec3b18 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml
@@ -32,7 +32,7 @@ properties:
maxItems: 1
richtek,oc-level-select:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2, 3]
description: |
Over current level selection. Each respective value means the current
@@ -40,7 +40,7 @@ properties:
in chip default.
richtek,ot-level-select:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2]
description: |
Over temperature level selection. Each respective value means the degree
@@ -48,16 +48,15 @@ properties:
default.
richtek,pgdly-time-select:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2, 3]
description: |
Power good signal delay time selection. Each respective value means the
delay time 0us, 10us, 20us, 40us. If this property is missing then keep
in chip default.
-
richtek,switch-freq-select:
- $ref: "/schemas/types.yaml#/definitions/uint8"
+ $ref: /schemas/types.yaml#/definitions/uint8
enum: [0, 1, 2]
description: |
Buck switch frequency selection. Each respective value means 400KHz,
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml
index a8ccb5cb8d77..fec3d396ca50 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml
@@ -120,7 +120,8 @@ properties:
lsw:
description: load switch current regulator description.
type: object
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
new file mode 100644
index 000000000000..022c1f197364
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -0,0 +1,207 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rtq2208.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RTQ2208 SubPMIC Regulator
+
+maintainers:
+ - Alina Yu <alina_yu@richtek.com>
+
+description: |
+ RTQ2208 is a highly integrated power converter that offers functional safety dual
+ multi-configurable synchronous buck converters and two LDOs.
+
+ Bucks support "regulator-allowed-modes" and "regulator-mode". The former defines the permitted
+ switching operation in normal mode; the latter defines the operation in suspend to RAM mode.
+
+ No matter the RTQ2208 is configured to normal or suspend to RAM mode, there are two switching
+ operation modes for all buck rails, automatic power saving mode (Auto mode) and forced continuous
+ conduction mode (FCCM).
+
+ The definition of modes is in the datasheet which is available in below link
+ and their meaning is::
+ 0 - Auto mode for power saving, which reducing the switching frequency at light load condition
+ to maintain high frequency.
+ 1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
+
+ Datasheet will be available soon at
+ https://www.richtek.com/assets/Products
+
+properties:
+ compatible:
+ enum:
+ - richtek,rtq2208
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ richtek,mtp-sel-high:
+ type: boolean
+ description:
+ vout register selection based on this boolean value.
+ false - Using DVS0 register setting to adjust vout
+ true - Using DVS1 register setting to adjust vout
+
+ regulators:
+ type: object
+ additionalProperties: false
+
+ patternProperties:
+ "^buck-[a-h]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ description for buck-[a-h] regulator.
+
+ properties:
+ regulator-allowed-modes:
+ description:
+ two buck modes in different switching accuracy.
+ 0 - Auto mode
+ 1 - FCCM
+ items:
+ enum: [0, 1]
+
+ "^ldo[1-2]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ regulator description for ldo[1-2].
+
+ properties:
+ richtek,fixed-microvolt:
+ deprecated: true
+ description: |
+ This property can be used to set a fixed operating voltage that lies outside
+ the range of the regulator's adjustable mode.
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@10 {
+ compatible = "richtek,rtq2208";
+ reg = <0x10>;
+ interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
+ richtek,mtp-sel-high;
+
+ regulators {
+ buck-a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-c {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-d {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-e {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-f {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-g {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ buck-h {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <2050000>;
+ regulator-allowed-modes = <0 1>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-mode = <1>;
+ };
+ };
+ ldo1 {
+ /* Fixed LDO VOUT */
+ richtek,fixed-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ ldo2 {
+ /* Adjustable LDO VOUT */
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml
index e6e5a9a7d940..ef62c618de67 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml
@@ -35,6 +35,7 @@ properties:
"^(p|n)avdd$":
type: object
$ref: regulator.yaml#
+ unevaluatedProperties: false
description: |
regulator description for pavdd and navdd.
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml
index d61e8675f067..cc4ceb32e9d6 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD71815 Power Management Integrated Circuit regulators
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
This module is part of the ROHM BD718215 MFD device. For more details
@@ -56,7 +56,7 @@ patternProperties:
PMIC "RUN" state voltage in uV when PMIC HW states are used. See
comments below for bucks/LDOs which support this. 0 means
regulator should be disabled at RUN state.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
@@ -67,7 +67,7 @@ patternProperties:
keeps regulator enabled. BD71815 does not change voltage level
when PMIC transitions to SNVS.SNVS voltage depends on the previous
state (from which the PMIC transitioned to SNVS).
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
@@ -76,7 +76,7 @@ patternProperties:
PMIC "SUSPEND" state voltage in uV when PMIC HW states are used. See
comments below for bucks/LDOs which support this. 0 means
regulator should be disabled at SUSPEND state.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
@@ -85,7 +85,7 @@ patternProperties:
PMIC "LPSR" state voltage in uV when PMIC HW states are used. See
comments below for bucks/LDOs which support this. 0 means
regulator should be disabled at LPSR state.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
index 5ce587fff961..d898800d6bca 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD71828 Power Management Integrated Circuit regulators
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
This module is part of the ROHM BD71828 MFD device. For more details
@@ -52,7 +52,7 @@ patternProperties:
description:
PMIC default "RUN" state voltage in uV. See below table for
bucks which support this. 0 means disabled.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
@@ -60,7 +60,7 @@ patternProperties:
description:
PMIC default "IDLE" state voltage in uV. See below table for
bucks which support this. 0 means disabled.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
@@ -68,7 +68,7 @@ patternProperties:
description:
PMIC default "SUSPEND" state voltage in uV. See below table for
bucks which support this. 0 means disabled.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
@@ -76,26 +76,26 @@ patternProperties:
description:
PMIC default "LPSR" state voltage in uV. See below table for
bucks which support this. 0 means disabled.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3300000
# Supported default DVS states:
# buck | run | idle | suspend | lpsr
- #--------------------------------------------------------------
+ # --------------------------------------------------------------
# 1, 2, 6, and 7 | supported | supported | supported (*)
- #--------------------------------------------------------------
+ # --------------------------------------------------------------
# 3, 4, and 5 | supported (**)
- #--------------------------------------------------------------
+ # --------------------------------------------------------------
#
- #(*) LPSR and SUSPEND states use same voltage but both states have own
- # enable /
- # disable settings. Voltage 0 can be specified for a state to make
- # regulator disabled on that state.
+ # (*) LPSR and SUSPEND states use same voltage but both states have own
+ # enable /
+ # disable settings. Voltage 0 can be specified for a state to make
+ # regulator disabled on that state.
#
- #(**) All states use same voltage but have own enable / disable
- # settings. Voltage 0 can be specified for a state to make
- # regulator disabled on that state.
+ # (**) All states use same voltage but have own enable / disable
+ # settings. Voltage 0 can be specified for a state to make
+ # regulator disabled on that state.
required:
- regulator-name
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
index 1941b36cf1ef..29b350a4f88a 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD71837 Power Management Integrated Circuit regulators
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
List of regulators provided by this controller. BD71837 regulators node
@@ -23,9 +23,9 @@ description: |
if they are disabled at startup the voltage monitoring for LDO5/LDO6 will
cause PMIC to reset.
-#The valid names for BD71837 regulator nodes are:
-#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8
-#LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7
+# The valid names for BD71837 regulator nodes are:
+# BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8
+# LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7
patternProperties:
"^LDO[1-7]$":
@@ -55,7 +55,7 @@ patternProperties:
should be "buck1", ..., "buck8"
rohm,dvs-run-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1300000
description:
@@ -63,7 +63,7 @@ patternProperties:
bucks which support this. 0 means disabled.
rohm,dvs-idle-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1300000
description:
@@ -71,7 +71,7 @@ patternProperties:
bucks which support this. 0 means disabled.
rohm,dvs-suspend-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1300000
description:
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
index a1b806373853..7ba4ccf723d8 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD71847 and BD71850 Power Management Integrated Circuit regulators
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
List of regulators provided by this controller. BD71847 regulators node
@@ -22,9 +22,9 @@ description: |
not be disabled by driver at startup. If BUCK5 is disabled at startup the
voltage monitoring for LDO5/LDO6 can cause PMIC to reset.
-#The valid names for BD71847 regulator nodes are:
-#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6
-#LDO1, LDO2, LDO3, LDO4, LDO5, LDO6
+# The valid names for BD71847 regulator nodes are:
+# BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6
+# LDO1, LDO2, LDO3, LDO4, LDO5, LDO6
patternProperties:
"^LDO[1-6]$":
@@ -54,7 +54,7 @@ patternProperties:
should be "buck1", ..., "buck6"
rohm,dvs-run-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1300000
description:
@@ -62,7 +62,7 @@ patternProperties:
bucks which support this. 0 means disabled.
rohm,dvs-idle-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1300000
description:
@@ -70,7 +70,7 @@ patternProperties:
bucks which support this. 0 means disabled.
rohm,dvs-suspend-voltage:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1300000
description:
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml
index 7cb74cc8c5d9..f573128da06f 100644
--- a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BD9576 and BD9573 Power Management Integrated Circuit regulators
maintainers:
- - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+ - Matti Vaittinen <mazziesaccount@gmail.com>
description: |
This module is part of the ROHM BD9576 MFD device. For more details
@@ -21,11 +21,11 @@ description: |
regulator-voutl1, regulator-vouts1
patternProperties:
- "regulator-.+":
+ "^regulator-.+$":
type: object
description:
Properties for single regulator.
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
properties:
rohm,ocw-fet-ron-micro-ohms:
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml
new file mode 100644
index 000000000000..b3d2d7d583ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd96801-regulator.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/rohm,bd96801-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD96801 Power Management Integrated Circuit regulators
+
+maintainers:
+ - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+
+description:
+ This module is part of the ROHM BD96801 MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/rohm,bd96801-pmic.yaml.
+
+ The regulator controller is represented as a sub-node of the PMIC node
+ on the device tree.
+
+ Regulator nodes should be named to buck_<number> and ldo_<number>.
+ The valid names for BD96801 regulator nodes are
+ buck1, buck2, buck3, buck4, ldo5, ldo6, ldo7
+
+patternProperties:
+ "^ldo[5-7]$":
+ type: object
+ description:
+ Properties for single LDO regulator.
+ $ref: regulator.yaml#
+
+ properties:
+ rohm,initial-voltage-microvolt:
+ description:
+ Initial voltage for regulator. Voltage can be tuned +/-150 mV from
+ this value. NOTE, This can be modified via I2C only when PMIC is in
+ STBY state.
+ minimum: 300000
+ maximum: 3300000
+
+ unevaluatedProperties: false
+
+ "^buck[1-4]$":
+ type: object
+ description:
+ Properties for single BUCK regulator.
+ $ref: regulator.yaml#
+
+ properties:
+ rohm,initial-voltage-microvolt:
+ description:
+ Initial voltage for regulator. Voltage can be tuned +/-150 mV from
+ this value. NOTE, This can be modified via I2C only when PMIC is in
+ STBY state.
+ minimum: 500000
+ maximum: 3300000
+
+ rohm,keep-on-stby:
+ description:
+ Keep the regulator powered when PMIC transitions to STBY state.
+ type: boolean
+
+ unevaluatedProperties: false
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml
new file mode 100644
index 000000000000..671eaf1096d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd96802-regulator.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/rohm,bd96802-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD96802 Power Management Integrated Circuit regulators
+
+maintainers:
+ - Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+
+description:
+ This module is part of the ROHM BD96802 MFD device. For more details
+ see Documentation/devicetree/bindings/mfd/rohm,bd96802-pmic.yaml.
+
+ The regulator controller is represented as a sub-node of the PMIC node
+ on the device tree.
+
+ Regulator nodes should be named to buck1 and buck2.
+
+patternProperties:
+ "^buck[1-2]$":
+ type: object
+ description:
+ Properties for single BUCK regulator.
+ $ref: regulator.yaml#
+
+ properties:
+ rohm,initial-voltage-microvolt:
+ description:
+ Initial voltage for regulator. Voltage can be tuned +/-150 mV from
+ this value. NOTE, This can be modified via I2C only when PMIC is in
+ STBY state.
+ minimum: 500000
+ maximum: 3300000
+
+ rohm,keep-on-stby:
+ description:
+ Keep the regulator powered when PMIC transitions to STBY state.
+ type: boolean
+
+ unevaluatedProperties: false
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml
index 01f9d4e236e9..a7feb497eb89 100644
--- a/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml
+++ b/Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml
@@ -19,8 +19,8 @@ description: |
additional information and example.
patternProperties:
- # 25 LDOs
- "^LDO([1-9]|[1][0-9]|2[0-5])$":
+ # 25 LDOs, without LDO10-12
+ "^LDO([1-9]|1[3-9]|2[0-5])$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
@@ -30,6 +30,23 @@ patternProperties:
required:
- regulator-name
+ "^LDO(1[0-2])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single LDO regulator.
+
+ properties:
+ samsung,ext-control-gpios:
+ maxItems: 1
+ description:
+ LDO10, LDO11 and LDO12 can be configured to external control over
+ GPIO.
+
+ required:
+ - regulator-name
+
# 5 bucks
"^BUCK[1-5]$":
type: object
diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml
new file mode 100644
index 000000000000..378518a5a7f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/samsung,s2mpu05.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung S2MPU05 Power Management IC regulators
+
+maintainers:
+ - Kaustabh Chakraborty <kauschluss@disroot.org>
+
+description: |
+ This is a part of device tree bindings for S2M and S5M family of Power
+ Management IC (PMIC).
+
+ The S2MPU05 provides buck and LDO regulators.
+
+ See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
+ additional information and example.
+
+patternProperties:
+ # 21 LDOs
+ "^ldo([1-9]|10|2[5-9]|3[0-5])$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single LDO regulator.
+
+ LDOs 11-24 are used for CP, and they're left unimplemented due to lack
+ of documentation on these regulators.
+
+ required:
+ - regulator-name
+
+ # 5 bucks
+ "^buck[1-5]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single buck regulator.
+
+ required:
+ - regulator-name
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
index a52a67c869b5..c3a902e11b5d 100644
--- a/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
+++ b/Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Silergy SY8106A Voltage Regulator Device Tree Bindings
+title: Silergy SY8106A Voltage Regulator
maintainers:
- Ondrej Jirman <megous@megous.com>
diff --git a/Documentation/devicetree/bindings/regulator/slg51000.txt b/Documentation/devicetree/bindings/regulator/slg51000.txt
deleted file mode 100644
index aa0733e49b90..000000000000
--- a/Documentation/devicetree/bindings/regulator/slg51000.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-* Dialog Semiconductor SLG51000 Voltage Regulator
-
-Required properties:
-- compatible : Should be "dlg,slg51000" for SLG51000
-- reg : Specifies the I2C slave address.
-- xxx-supply: Input voltage supply regulator for ldo3 to ldo7.
- These entries are required if regulators are enabled for a device.
- An absence of these properties can cause the regulator registration to fail.
- If some of input supply is powered through battery or always-on supply then
- also it is required to have these parameters with proper node handle of always
- on power supply.
- vin3-supply: Input supply for ldo3
- vin4-supply: Input supply for ldo4
- vin5-supply: Input supply for ldo5
- vin6-supply: Input supply for ldo6
- vin7-supply: Input supply for ldo7
-
-Optional properties:
-- interrupt-parent : Specifies the reference to the interrupt controller.
-- interrupts : IRQ line information.
-- dlg,cs-gpios : Specify a valid GPIO for chip select
-
-Sub-nodes:
-- regulators : This node defines the settings for the regulators.
- The content of the sub-node is defined by the standard binding
- for regulators; see regulator.txt.
-
- The SLG51000 regulators are bound using their names listed below:
- ldo1
- ldo2
- ldo3
- ldo4
- ldo5
- ldo6
- ldo7
-
-Optional properties for regulators:
-- enable-gpios : Specify a valid GPIO for platform control of the regulator.
-
-Example:
- pmic: slg51000@75 {
- compatible = "dlg,slg51000";
- reg = <0x75>;
-
- regulators {
- ldo1 {
- regulator-name = "ldo1";
- regulator-min-microvolt = <2400000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo2 {
- regulator-name = "ldo2";
- regulator-min-microvolt = <2400000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo3 {
- regulator-name = "ldo3";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- };
-
- ldo4 {
- regulator-name = "ldo4";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- };
-
- ldo5 {
- regulator-name = "ldo5";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1200000>;
- };
-
- ldo6 {
- regulator-name = "ldo6";
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1200000>;
- };
-
- ldo7 {
- regulator-name = "ldo7";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml
index c0acf949753d..ddaa112252e5 100644
--- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml
@@ -42,7 +42,7 @@ properties:
reset-names: true
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
- if:
properties:
compatible:
@@ -89,18 +89,11 @@ required:
examples:
- |
- usb-glue@65b00000 {
- compatible = "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_vbus0: regulators@100 {
- compatible = "socionext,uniphier-ld20-usb3-regulator";
- reg = <0x100 0x10>;
- clock-names = "link";
- clocks = <&sys_clk 14>;
- reset-names = "link";
- resets = <&sys_rst 14>;
- };
+ usb_vbus0: regulators@100 {
+ compatible = "socionext,uniphier-ld20-usb3-regulator";
+ reg = <0x100 0x10>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
};
diff --git a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
deleted file mode 100644
index 63dc07877cd6..000000000000
--- a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Spreadtrum SC2731 Voltage regulators
-
-The SC2731 integrates low-voltage and low quiescent current DCDC/LDO.
-14 LDO and 3 DCDCs are designed for external use. All DCDCs/LDOs have
-their own bypass (power-down) control signals. External tantalum or MLCC
-ceramic capacitors are recommended to use with these LDOs.
-
-Required properties:
- - compatible: should be "sprd,sc27xx-regulator".
-
-List of regulators provided by this controller. It is named according to
-its regulator type, BUCK_<name> and LDO_<name>. The definition for each
-of these nodes is defined using the standard binding for regulators at
-Documentation/devicetree/bindings/regulator/regulator.txt.
-
-The valid names for regulators are:
-BUCK:
- BUCK_CPU0, BUCK_CPU1, BUCK_RF
-LDO:
- LDO_CAMA0, LDO_CAMA1, LDO_CAMMOT, LDO_VLDO, LDO_EMMCCORE, LDO_SDCORE,
- LDO_SDIO, LDO_WIFIPA, LDO_USB33, LDO_CAMD0, LDO_CAMD1, LDO_CON,
- LDO_CAMIO, LDO_SRAM
-
-Example:
- regulators {
- compatible = "sprd,sc27xx-regulator";
-
- vddarm0: BUCK_CPU0 {
- regulator-name = "vddarm0";
- regulator-min-microvolt = <400000>;
- regulator-max-microvolt = <1996875>;
- regulator-ramp-delay = <25000>;
- regulator-always-on;
- };
-
- vddcama0: LDO_CAMA0 {
- regulator-name = "vddcama0";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <3750000>;
- regulator-enable-ramp-delay = <100>;
- };
- ...
- };
diff --git a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml
new file mode 100644
index 000000000000..9bd752bab68e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/sprd,sc2731-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC2731 Power Management IC regulators
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description: |
+ The SC2731 integrates low-voltage and low quiescent current DCDC/LDO.
+ 14 LDO and 3 DCDCs are designed for external use. All DCDCs/LDOs have
+ their own bypass (power-down) control signals. It is recommended to use
+ external tantalum or MLCC ceramic capacitors with these LDOs.
+ Valid names for the regulators are:
+ BUCK:
+ BUCK_CPU0, BUCK_CPU1, BUCK_RF
+ LDO:
+ LDO_CAMA0, LDO_CAMA1, LDO_CAMD0, LDO_CAMD1, LDO_CAMIO, LDO_CAMMOT,
+ LDO_CON, LDO_EMMCCORE, LDO_SDCORE, LDO_SDIO, LDO_SRAM, LDO_USB33,
+ LDO_VLDO, LDO_WIFIPA
+
+properties:
+ compatible:
+ const: sprd,sc2731-regulator
+
+patternProperties:
+ "^BUCK_(CPU[0-1]|RF)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ "^LDO_(CAM(A0|A1|D0|D1|IO|MOT)|CON|EMMCCORE|SD(CORE|IO)|SRAM|USB33|VLDO|WIFIPA)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+...
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml
index 38bdaef4fa39..c863100f6e7d 100644
--- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml
+++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/regulator/st,stm32-booster.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 booster for ADC analog input switches bindings
+title: STMicroelectronics STM32 booster for ADC analog input switches
maintainers:
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
@@ -14,7 +14,7 @@ description: |
to supply ADC analog input switches.
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
@@ -23,7 +23,7 @@ properties:
- st,stm32mp1-booster
st,syscfg:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: phandle to system configuration controller.
vdda-supply:
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
index a5a27ee0a9e6..6ceaffb45dc9 100644
--- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
+++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/regulator/st,stm32-vrefbuf.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Voltage reference buffer bindings
+title: STMicroelectronics STM32 Voltage reference buffer
description: |
Some STM32 devices embed a voltage reference buffer which can be used as
@@ -15,7 +15,7 @@ maintainers:
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
@@ -30,6 +30,10 @@ properties:
vdda-supply:
description: phandle to the vdda input analog voltage.
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
index bd07b9c81570..3cb2dad18781 100644
--- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
+++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml
@@ -11,7 +11,12 @@ maintainers:
properties:
compatible:
- const: st,stm32mp1,pwr-reg
+ oneOf:
+ - items:
+ - const: st,stm32mp1,pwr-reg
+ - items:
+ - const: st,stm32mp13-pwr-reg
+ - const: st,stm32mp1,pwr-reg
reg:
maxItems: 1
@@ -25,8 +30,8 @@ properties:
patternProperties:
"^(reg11|reg18|usb33)$":
type: object
-
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml
index 12aeddedde05..90c39275c150 100644
--- a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml
+++ b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml
@@ -19,7 +19,7 @@ description: |
https://www.ti.com/lit/gpn/tps62360
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml
index 0f29c75f42ea..dddea27596e9 100644
--- a/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml
+++ b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml
@@ -24,7 +24,7 @@ properties:
type: object
properties:
- "SW":
+ SW:
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml
new file mode 100644
index 000000000000..386989544dac
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti,tps62870.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/ti,tps62870.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS62870/TPS62871/TPS62872/TPS62873 voltage regulator
+
+maintainers:
+ - Mårten Lindahl <marten.lindahl@axis.com>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tps62870
+ - ti,tps62871
+ - ti,tps62872
+ - ti,tps62873
+
+ reg:
+ maxItems: 1
+
+ regulator-initial-mode:
+ enum: [ 1, 2 ]
+ description: 1 - Forced PWM mode, 2 - Low power mode
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@41 {
+ compatible = "ti,tps62873";
+ reg = <0x41>;
+ regulator-name = "+0.75V";
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1675000>;
+ regulator-initial-mode = <1>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps65132.yaml b/Documentation/devicetree/bindings/regulator/ti,tps65132.yaml
new file mode 100644
index 000000000000..873d92738eb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti,tps65132.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/ti,tps65132.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS65132 Dual Output Power Regulators
+
+maintainers:
+ - devicetree@vger.kernel.org
+
+description: |
+ The TPS65132 is designed to supply positive/negative driven applications.
+
+ Datasheet is available at:
+ https://www.ti.com/lit/gpn/tps65132
+
+properties:
+ compatible:
+ enum:
+ - ti,tps65132
+
+ reg:
+ maxItems: 1
+
+ vin-supply: true
+
+patternProperties:
+ "^out[pn]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ Properties for single regulator.
+
+ properties:
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier to enable the GPIO control (on/off) for regulator.
+
+ active-discharge-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier to actively discharge the delay mechanism.
+
+ ti,active-discharge-time-us:
+ description: Regulator active discharge time in microseconds.
+
+ dependencies:
+ active-discharge-gpios: [ 'ti,active-discharge-time-us' ]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@3e {
+ compatible = "ti,tps65132";
+ reg = <0x3e>;
+ vin-supply = <&supply>;
+
+ outp {
+ regulator-name = "outp";
+ regulator-boot-on;
+ regulator-always-on;
+ enable-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ outn {
+ regulator-name = "outn";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-active-discharge = <0>;
+ enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml
index 78be79930fda..7c64e588a8b5 100644
--- a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml
+++ b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/regulator/ti,tps65219.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI tps65219 Power Management Integrated Circuit regulators
+title: TI TPS65214/TPS65215/TPS65219 Power Management Integrated Circuit
maintainers:
- Jerome Neanne <jerome.neanne@baylibre.com>
@@ -12,9 +12,20 @@ maintainers:
description: |
Regulator nodes should be named to buck<number> and ldo<number>.
+ TI TPS65219 is a Power Management IC with 3 Buck regulators, 4 Low
+ Drop-out Regulators (LDOs), 1 GPIO, 2 GPOs, and power-button.
+
+ TI TPS65215 is a derivative of TPS65219 with 3 Buck regulators, 2 Low
+ Drop-out Regulators (LDOs), 1 GPIO, 1 GPO, and power-button.
+
+ TI TPS65214 is a derivative of TPS65219 with 3 Buck regulators, 2 Low
+ Drop-out Regulators (LDOs), 1 GPIO, 1 GPO, and power-button.
+
properties:
compatible:
enum:
+ - ti,tps65214
+ - ti,tps65215
- ti,tps65219
reg:
@@ -51,13 +62,6 @@ properties:
where the board has a button wired to the pin and triggers
an interrupt on pressing it.
-patternProperties:
- "^buck[1-3]-supply$":
- description: Input supply phandle of one regulator.
-
- "^ldo[1-4]-supply$":
- description: Input supply phandle of one regulator.
-
regulators:
type: object
description: |
@@ -82,6 +86,13 @@ patternProperties:
additionalProperties: false
+patternProperties:
+ "^buck[1-3]-supply$":
+ description: Input supply phandle of one regulator.
+
+ "^ldo[1-4]-supply$":
+ description: Input supply phandle of one regulator.
+
required:
- compatible
- reg
@@ -90,6 +101,20 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tps65214
+ - ti,tps65215
+ then:
+ properties:
+ regulators:
+ patternProperties:
+ "^ldo[3-4]$": false
+
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt b/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt
deleted file mode 100644
index 3a3505520c69..000000000000
--- a/Documentation/devicetree/bindings/regulator/tps65132-regulator.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-TPS65132 regulators
-
-Required properties:
-- compatible: "ti,tps65132"
-- reg: I2C slave address
-
-Optional Subnode:
-Device supports two regulators OUTP and OUTN. A sub node within the
- device node describe the properties of these regulators. The sub-node
- names must be as follows:
- -For regulator outp, the sub node name should be "outp".
- -For regulator outn, the sub node name should be "outn".
-
--enable-gpios:(active high, output) Regulators are controlled by the input pins.
- If it is connected to GPIO through host system then provide the
- gpio number as per gpio.txt.
--active-discharge-gpios: (active high, output) Some configurations use delay mechanisms
- on the enable pin, to keep the regulator enabled for some time after
- the enable signal goes low. This GPIO is used to actively discharge
- the delay mechanism. Requires specification of ti,active-discharge-time-us
--ti,active-discharge-time-us: how long the active discharge gpio should be
- asserted for during active discharge, in microseconds.
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
- tps65132@3e {
- compatible = "ti,tps65132";
- reg = <0x3e>;
-
- outp {
- regulator-name = "outp";
- regulator-boot-on;
- regulator-always-on;
- enable-gpios = <&gpio 23 0>;
- };
-
- outn {
- regulator-name = "outn";
- regulator-boot-on;
- regulator-always-on;
- regulator-active-discharge = <0>;
- enable-gpios = <&gpio 40 0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
deleted file mode 100644
index 549f80436deb..000000000000
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-TWL family of regulators
-
-Required properties:
-For twl6030 regulators/LDOs
-- compatible:
- - "ti,twl6030-vaux1" for VAUX1 LDO
- - "ti,twl6030-vaux2" for VAUX2 LDO
- - "ti,twl6030-vaux3" for VAUX3 LDO
- - "ti,twl6030-vmmc" for VMMC LDO
- - "ti,twl6030-vpp" for VPP LDO
- - "ti,twl6030-vusim" for VUSIM LDO
- - "ti,twl6030-vana" for VANA LDO
- - "ti,twl6030-vcxio" for VCXIO LDO
- - "ti,twl6030-vdac" for VDAC LDO
- - "ti,twl6030-vusb" for VUSB LDO
- - "ti,twl6030-v1v8" for V1V8 LDO
- - "ti,twl6030-v2v1" for V2V1 LDO
- - "ti,twl6030-vdd1" for VDD1 SMPS
- - "ti,twl6030-vdd2" for VDD2 SMPS
- - "ti,twl6030-vdd3" for VDD3 SMPS
-For twl6032 regulators/LDOs
-- compatible:
- - "ti,twl6032-ldo1" for LDO1 LDO
- - "ti,twl6032-ldo2" for LDO2 LDO
- - "ti,twl6032-ldo3" for LDO3 LDO
- - "ti,twl6032-ldo4" for LDO4 LDO
- - "ti,twl6032-ldo5" for LDO5 LDO
- - "ti,twl6032-ldo6" for LDO6 LDO
- - "ti,twl6032-ldo7" for LDO7 LDO
- - "ti,twl6032-ldoln" for LDOLN LDO
- - "ti,twl6032-ldousb" for LDOUSB LDO
- - "ti,twl6032-smps3" for SMPS3 SMPS
- - "ti,twl6032-smps4" for SMPS4 SMPS
- - "ti,twl6032-vio" for VIO SMPS
-For twl4030 regulators/LDOs
-- compatible:
- - "ti,twl4030-vaux1" for VAUX1 LDO
- - "ti,twl4030-vaux2" for VAUX2 LDO
- - "ti,twl5030-vaux2" for VAUX2 LDO
- - "ti,twl4030-vaux3" for VAUX3 LDO
- - "ti,twl4030-vaux4" for VAUX4 LDO
- - "ti,twl4030-vmmc1" for VMMC1 LDO
- - "ti,twl4030-vmmc2" for VMMC2 LDO
- - "ti,twl4030-vpll1" for VPLL1 LDO
- - "ti,twl4030-vpll2" for VPLL2 LDO
- - "ti,twl4030-vsim" for VSIM LDO
- - "ti,twl4030-vdac" for VDAC LDO
- - "ti,twl4030-vintana2" for VINTANA2 LDO
- - "ti,twl4030-vio" for VIO LDO
- - "ti,twl4030-vdd1" for VDD1 SMPS
- - "ti,twl4030-vdd2" for VDD2 SMPS
- - "ti,twl4030-vintana1" for VINTANA1 LDO
- - "ti,twl4030-vintdig" for VINTDIG LDO
- - "ti,twl4030-vusb1v5" for VUSB1V5 LDO
- - "ti,twl4030-vusb1v8" for VUSB1V8 LDO
- - "ti,twl4030-vusb3v1" for VUSB3V1 LDO
-
-Optional properties:
-- Any optional property defined in bindings/regulator/regulator.txt
-For twl4030 regulators/LDOs:
- - regulator-initial-mode:
- - 0x08 - Sleep mode, the nominal output voltage is maintained with low power
- consumption with low load current capability.
- - 0x0e - Active mode, the regulator can deliver its nominal output voltage
- with full-load current capability.
-
-Example:
-
- xyz: regulator@0 {
- compatible = "ti,twl6030-vaux1";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <3000000>;
- };
-
-For twl6030 regulators/LDOs:
-
- - ti,retain-on-reset: Does not turn off the supplies during warm
- reset. Could be needed for VMMC, as TWL6030
- reset sequence for this signal does not comply
- with the SD specification.
diff --git a/Documentation/devicetree/bindings/regulator/vctrl-regulator.yaml b/Documentation/devicetree/bindings/regulator/vctrl-regulator.yaml
new file mode 100644
index 000000000000..6132b8e5b498
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/vctrl-regulator.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/vctrl-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Voltage controlled regulators
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+allOf:
+ - $ref: regulator.yaml#
+
+properties:
+ compatible:
+ const: vctrl-regulator
+
+ ctrl-supply:
+ description: Regulator supplying the control voltage
+
+ ctrl-voltage-range:
+ description:
+ Array of two integer values describing the range (min/max) of the
+ control voltage. The values specify the control voltage needed to
+ generate the corresponding regulator-min/max-microvolt output
+ voltage.
+ minItems: 2
+ maxItems: 2
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ min-slew-down-rate:
+ description:
+ Describes how slowly the regulator voltage will decay down in the
+ worst case (lightest expected load). Specified in uV / us (like
+ main regulator ramp rate). This value is required when
+ ovp-threshold-percent is specified.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ovp-threshold-percent:
+ description:
+ Overvoltage protection (OVP) threshold of the regulator in percent.
+ Some regulators have an OVP circuitry which shuts down the regulator
+ when the actual output voltage deviates beyond a certain margin from
+ the expected value for a given control voltage. On larger voltage
+ decreases this can occur undesiredly since the output voltage does
+ not adjust immediately to changes in the control voltage. To avoid
+ this situation the vctrl driver breaks down larger voltage decreases
+ into multiple steps, where each step is within the OVP threshold.
+ minimum: 0
+ maximum: 100
+
+unevaluatedProperties: false
+
+dependencies:
+ ovp-threshold-percent: [ min-slew-down-rate ]
+
+required:
+ - compatible
+ - ctrl-supply
+ - ctrl-voltage-range
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+examples:
+ - |
+ vctrl-reg {
+ compatible = "vctrl-regulator";
+ regulator-name = "vctrl_reg";
+
+ ctrl-supply = <&ctrl_reg>;
+ ctrl-voltage-range = <200000 500000>;
+
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1500000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/vctrl.txt b/Documentation/devicetree/bindings/regulator/vctrl.txt
deleted file mode 100644
index 601328d7fdbb..000000000000
--- a/Documentation/devicetree/bindings/regulator/vctrl.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Bindings for Voltage controlled regulators
-==========================================
-
-Required properties:
---------------------
-- compatible : must be "vctrl-regulator".
-- regulator-min-microvolt : smallest voltage consumers may set
-- regulator-max-microvolt : largest voltage consumers may set
-- ctrl-supply : The regulator supplying the control voltage.
-- ctrl-voltage-range : an array of two integer values describing the range
- (min/max) of the control voltage. The values specify
- the control voltage needed to generate the corresponding
- regulator-min/max-microvolt output voltage.
-
-Optional properties:
---------------------
-- ovp-threshold-percent : overvoltage protection (OVP) threshold of the
- regulator in percent. Some regulators have an OVP
- circuitry which shuts down the regulator when the
- actual output voltage deviates beyond a certain
- margin from the expected value for a given control
- voltage. On larger voltage decreases this can occur
- undesiredly since the output voltage does not adjust
- inmediately to changes in the control voltage. To
- avoid this situation the vctrl driver breaks down
- larger voltage decreases into multiple steps, where
- each step is within the OVP threshold.
-- min-slew-down-rate : Describes how slowly the regulator voltage will decay
- down in the worst case (lightest expected load).
- Specified in uV / us (like main regulator ramp rate).
- This value is required when ovp-threshold-percent is
- specified.
-
-Example:
-
- vctrl-reg {
- compatible = "vctrl-regulator";
- regulator-name = "vctrl_reg";
-
- ctrl-supply = <&ctrl_reg>;
-
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1500000>;
-
- ctrl-voltage-range = <200000 500000>;
-
- min-slew-down-rate = <225>;
- ovp-threshold-percent = <16>;
- };
diff --git a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml
index dd7a2f92634c..3b16a25ba3b8 100644
--- a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml
@@ -15,7 +15,7 @@ description: |
controller is also embedded.
allOf:
- - $ref: "regulator.yaml#"
+ - $ref: regulator.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
index 7b4ae5d23351..11e378648b3f 100644
--- a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
+++ b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml
@@ -21,19 +21,21 @@ properties:
wlf,ldoena:
description:
GPIO specifier for the GPIO controlling LDOENA.
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
ldo1:
description:
Initial data for the LDO1 regulator.
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
micvdd:
description:
Initial data for the MICVDD regulator.
- $ref: "regulator.yaml#"
+ $ref: regulator.yaml#
type: object
+ unevaluatedProperties: false
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
index d892d29a656b..76e8ca44906a 100644
--- a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Amlogic Meson AO ARC Remote Processor bindings
+title: Amlogic Meson AO ARC Remote Processor
description:
Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC core
@@ -75,7 +75,7 @@ additionalProperties: false
examples:
- |
remoteproc@1c {
- compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+ compatible = "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
reg = <0x1c 0x8>, <0x38 0x8>;
reg-names = "remap", "cpu";
resets = <&media_cpu_reset>;
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 3a1f59ad79e2..57d75acb0b5e 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX Co-Processor Bindings
+title: NXP i.MX Co-Processor
description:
This binding provides support for ARM Cortex M4 Co-processor found on some NXP iMX SoCs.
@@ -20,8 +20,12 @@ properties:
- fsl,imx7ulp-cm4
- fsl,imx8mm-cm4
- fsl,imx8mn-cm7
+ - fsl,imx8mn-cm7-mmio
- fsl,imx8mp-cm7
+ - fsl,imx8mp-cm7-mmio
- fsl,imx8mq-cm4
+ - fsl,imx8qm-cm4
+ - fsl,imx8qxp-cm4
- fsl,imx8ulp-cm33
- fsl,imx93-cm33
@@ -54,15 +58,62 @@ properties:
minItems: 1
maxItems: 32
+ power-domains:
+ minItems: 2
+ maxItems: 8
+
fsl,auto-boot:
$ref: /schemas/types.yaml#/definitions/flag
description:
Indicate whether need to load the default firmware and start the remote
processor automatically.
+ fsl,entry-address:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Specify CPU entry address for SCU enabled processor.
+
+ fsl,iomuxc-gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to IOMUXC GPR block which provide access to CM7 CPUWAIT bit.
+
+ fsl,resource-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This property is to specify the resource id of the remote processor in SoC
+ which supports SCFW
+
required:
- compatible
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - fsl,imx8mn-cm7-mmio
+ - fsl,imx8mp-cm7-mmio
+ then:
+ properties:
+ fsl,iomuxc-gpr: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qxp-cm4
+ - fsl,imx8qm-cm4
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
additionalProperties: false
examples:
@@ -77,10 +128,10 @@ examples:
};
imx7d-cm4 {
- compatible = "fsl,imx7d-cm4";
- memory-region = <&m4_reserved_sysmem1>, <&m4_reserved_sysmem2>;
- syscon = <&src>;
- clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
+ compatible = "fsl,imx7d-cm4";
+ memory-region = <&m4_reserved_sysmem1>, <&m4_reserved_sysmem2>;
+ syscon = <&src>;
+ clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
};
- |
diff --git a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml
index aaaaabad46ea..8b55dbd909b0 100644
--- a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/remoteproc/ingenic,vpu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/remoteproc/ingenic,vpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic Video Processing Unit bindings
+title: Ingenic Video Processing Unit
description:
Inside the Video Processing Unit (VPU) of the recent JZ47xx SoCs from
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index 7e091eaffc18..179c98b33b4d 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/remoteproc/mtk,scp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek SCP Bindings
+title: Mediatek SCP
maintainers:
- Tinghan Shen <tinghan.shen@mediatek.com>
@@ -19,8 +19,10 @@ properties:
- mediatek,mt8183-scp
- mediatek,mt8186-scp
- mediatek,mt8188-scp
+ - mediatek,mt8188-scp-dual
- mediatek,mt8192-scp
- mediatek,mt8195-scp
+ - mediatek,mt8195-scp-dual
reg:
description:
@@ -31,10 +33,7 @@ properties:
reg-names:
minItems: 2
- items:
- - const: sram
- - const: cfg
- - const: l1tcm
+ maxItems: 3
clocks:
description:
@@ -49,7 +48,7 @@ properties:
maxItems: 1
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
description:
If present, name (or relative path) of the file within the
firmware search path containing the firmware image used when
@@ -58,6 +57,93 @@ properties:
memory-region:
maxItems: 1
+ cros-ec-rpmsg:
+ $ref: /schemas/embedded-controller/google,cros-ec.yaml
+ description:
+ This subnode represents the rpmsg device. The properties
+ of this node are defined by the individual bindings for
+ the rpmsg devices.
+
+ required:
+ - mediatek,rpmsg-name
+
+ unevaluatedProperties: false
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ranges:
+ description:
+ Standard ranges definition providing address translations for
+ local SCP SRAM address spaces to bus addresses.
+
+patternProperties:
+ "^scp@[a-f0-9]+$":
+ type: object
+ description:
+ The MediaTek SCP integrated to SoC might be a multi-core version.
+ The other cores are represented as child nodes of the boot core.
+ There are some integration differences for the IP like the usage of
+ address translator for translating SoC bus addresses into address space
+ for the processor.
+
+ Each SCP core has own cache memory. The SRAM and L1TCM are shared by
+ cores. The power of cache, SRAM and L1TCM power should be enabled
+ before booting SCP cores. The size of cache, SRAM, and L1TCM are varied
+ on different SoCs.
+
+ The SCP cores do not use an MMU, but has a set of registers to
+ control the translations between 32-bit CPU addresses into system bus
+ addresses. Cache and memory access settings are provided through a
+ Memory Protection Unit (MPU), programmable only from the SCP.
+
+ properties:
+ compatible:
+ enum:
+ - mediatek,scp-core
+
+ reg:
+ description: The base address and size of SRAM.
+ maxItems: 1
+
+ reg-names:
+ const: sram
+
+ interrupts:
+ maxItems: 1
+
+ firmware-name:
+ maxItems: 1
+ description:
+ If present, name (or relative path) of the file within the
+ firmware search path containing the firmware image used when
+ initializing sub cores of multi-core SCP.
+
+ memory-region:
+ maxItems: 1
+
+ cros-ec-rpmsg:
+ $ref: /schemas/embedded-controller/google,cros-ec.yaml
+ description:
+ This subnode represents the rpmsg device. The properties
+ of this node are defined by the individual bindings for
+ the rpmsg devices.
+
+ required:
+ - mediatek,rpmsg-name
+
+ unevaluatedProperties: false
+
+ required:
+ - compatible
+ - reg
+ - reg-names
+
+ additionalProperties: false
+
required:
- compatible
- reg
@@ -87,23 +173,40 @@ allOf:
reg:
maxItems: 2
reg-names:
+ items:
+ - const: sram
+ - const: cfg
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8192-scp
+ - mediatek,mt8195-scp
+ then:
+ properties:
+ reg:
+ maxItems: 3
+ reg-names:
+ items:
+ - const: sram
+ - const: cfg
+ - const: l1tcm
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-scp-dual
+ - mediatek,mt8195-scp-dual
+ then:
+ properties:
+ reg:
maxItems: 2
+ reg-names:
+ items:
+ - const: cfg
+ - const: l1tcm
-additionalProperties:
- type: object
- description:
- Subnodes of the SCP represent rpmsg devices. The names of the devices
- are not important. The properties of these nodes are defined by the
- individual bindings for the rpmsg devices.
- properties:
- mediatek,rpmsg-name:
- $ref: /schemas/types.yaml#/definitions/string-array
- description:
- Contains the name for the rpmsg device. Used to match
- the subnode to rpmsg device announced by SCP.
-
- required:
- - mediatek,rpmsg-name
+additionalProperties: false
examples:
- |
@@ -118,7 +221,42 @@ examples:
clocks = <&infracfg CLK_INFRA_SCPSYS>;
clock-names = "main";
- cros_ec {
+ cros-ec-rpmsg {
+ compatible = "google,cros-ec-rpmsg";
mediatek,rpmsg-name = "cros-ec-rpmsg";
};
};
+
+ - |
+ scp@10500000 {
+ compatible = "mediatek,mt8195-scp-dual";
+ reg = <0x10720000 0xe0000>,
+ <0x10700000 0x8000>;
+ reg-names = "cfg", "l1tcm";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x10500000 0x100000>;
+
+ scp@0 {
+ compatible = "mediatek,scp-core";
+ reg = <0x0 0xa0000>;
+ reg-names = "sram";
+
+ cros-ec-rpmsg {
+ compatible = "google,cros-ec-rpmsg";
+ mediatek,rpmsg-name = "cros-ec-rpmsg";
+ };
+ };
+
+ scp@a0000 {
+ compatible = "mediatek,scp-core";
+ reg = <0xa0000 0x20000>;
+ reg-names = "sram";
+
+ cros-ec-rpmsg {
+ compatible = "google,cros-ec-rpmsg";
+ mediatek,rpmsg-name = "cros-ec-rpmsg";
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
index 3072af5f9d79..137f95028313 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/remoteproc/qcom,adsp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm ADSP Peripheral Image Loader binding
+title: Qualcomm ADSP Peripheral Image Loader
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
@@ -17,279 +17,69 @@ properties:
compatible:
enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- qcom,msm8998-slpi-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-cdsp-pas
- - qcom,qcs404-wcss-pas
- - qcom,sc7180-mpss-pas
- - qcom,sc7280-mpss-pas
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8180x-mpss-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
- qcom,sdm660-adsp-pas
+ - qcom,sdm660-cdsp-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
- - qcom,sdx55-mpss-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm6350-cdsp-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-cdsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-cdsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-cdsp-pas
- - qcom,sm8450-mpss-pas
- - qcom,sm8450-slpi-pas
+ - qcom,sdm845-slpi-pas
reg:
maxItems: 1
- clocks:
- minItems: 1
- maxItems: 8
-
- clock-names:
- minItems: 1
- maxItems: 8
-
- interconnects:
- maxItems: 1
-
- interrupts:
- minItems: 5
- items:
- - description: Watchdog interrupt
- - description: Fatal interrupt
- - description: Ready interrupt
- - description: Handover interrupt
- - description: Stop acknowledge interrupt
- - description: Shutdown acknowledge interrupt
-
- interrupt-names:
- minItems: 5
- items:
- - const: wdog
- - const: fatal
- - const: ready
- - const: handover
- - const: stop-ack
- - const: shutdown-ack
-
- resets:
- minItems: 1
- maxItems: 3
-
- reset-names:
- minItems: 1
- maxItems: 3
-
- cx-supply:
- description: Phandle to the CX regulator
-
px-supply:
description: Phandle to the PX regulator
- power-domains:
- minItems: 1
- maxItems: 3
-
- power-domain-names:
- minItems: 1
- maxItems: 3
-
- firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
- description: Firmware name for the Hexagon core
-
- memory-region:
- maxItems: 1
- description: Reference to the reserved-memory for the Hexagon core
-
qcom,qmp:
$ref: /schemas/types.yaml#/definitions/phandle
description: Reference to the AOSS side-channel message RAM.
- qcom,smem-states:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: States used by the AP to signal the Hexagon core
- items:
- - description: Stop the modem
-
- qcom,smem-state-names:
- description: The names of the state bits used for SMP2P output
- items:
- - const: stop
-
- qcom,halt-regs:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- items:
- - items:
- - description: Phandle reference to a syscon representing TCSR
- - description: offsets within syscon for q6 halt registers
- - description: offsets within syscon for modem halt registers
- - description: offsets within syscon for nc halt registers
- description:
- Phandle reference to a syscon representing TCSR followed by the
- three offsets within syscon for q6, modem and nc halt registers.
-
- smd-edge:
- $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
- description:
- Qualcomm Shared Memory subnode which represents communication edge,
- channels and devices related to the ADSP.
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
- glink-edge:
- $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
- description:
- Qualcomm G-Link subnode which represents communication edge, channels
- and devices related to the ADSP.
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
required:
- compatible
- - clocks
- - clock-names
- - interrupts
- - interrupt-names
- memory-region
- - qcom,smem-states
- - qcom,smem-state-names
-additionalProperties: false
+unevaluatedProperties: false
allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-wcss-pas
- - qcom,sc7280-mpss-pas
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8180x-mpss-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
+ - qcom,msm8998-slpi-pas
+ - qcom,sdm660-adsp-pas
+ - qcom,sdm660-cdsp-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm6350-cdsp-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-cdsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-cdsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-cdsp-pas
- - qcom,sm8450-slpi-pas
- - qcom,sm8450-mpss-pas
- then:
- properties:
- clocks:
- items:
- - description: XO clock
- clock-names:
- items:
- - const: xo
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8998-slpi-pas
- then:
- properties:
- clocks:
- items:
- - description: XO clock
- - description: AGGRE2 clock
- clock-names:
- items:
- - const: xo
- - const: aggre2
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,qcs404-cdsp-pas
- then:
- properties:
- clocks:
- items:
- - description: XO clock
- - description: SWAY clock
- - description: TBU clock
- - description: BIMC clock
- - description: AHB AON clock
- - description: Q6SS SLAVE clock
- - description: Q6SS MASTER clock
- - description: Q6 AXIM clock
- clock-names:
- items:
- - const: xo
- - const: sway
- - const: tbu
- - const: bimc
- - const: ahb_aon
- - const: q6ss_slave
- - const: q6ss_master
- - const: q6_axim
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc7180-mpss-pas
+ - qcom,sdm845-slpi-pas
then:
properties:
clocks:
items:
- description: XO clock
- - description: IFACE clock
- - description: BUS clock
- - description: NAC clock
- - description: SNOC AXI clock
- - description: MNOC AXI clock
clock-names:
items:
- const: xo
- - const: iface
- - const: bus
- - const: nav
- - const: snoc_axi
- - const: mnoc_axi
- if:
properties:
@@ -297,35 +87,17 @@ allOf:
contains:
enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- qcom,msm8998-slpi-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-cdsp-pas
- - qcom,qcs404-wcss-pas
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
+ - qcom,sdm660-adsp-pas
+ - qcom,sdm660-cdsp-pas
- qcom,sdm845-adsp-pas
- qcom,sdm845-cdsp-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm6350-cdsp-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-cdsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-cdsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-cdsp-pas
- - qcom,sm8450-slpi-pas
+ - qcom,sdm845-slpi-pas
then:
properties:
interrupts:
@@ -338,41 +110,13 @@ allOf:
compatible:
contains:
enum:
- - qcom,sc7180-mpss-pas
- - qcom,sc7280-mpss-pas
- - qcom,sc8180x-mpss-pas
- - qcom,sdx55-mpss-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-mpss-pas
- then:
- properties:
- interrupts:
- minItems: 6
- interrupt-names:
- minItems: 6
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,msm8974-adsp-pil
- then:
- required:
- - cx-supply
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
+ - qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8998-adsp-pas
- - qcom,sm8150-adsp-pas
- - qcom,sm8150-cdsp-pas
+ - qcom,sdm660-adsp-pas
+ - qcom,sdm660-cdsp-pas
then:
properties:
power-domains:
@@ -403,77 +147,8 @@ allOf:
- if:
properties:
compatible:
- contains:
- enum:
- - qcom,sc7180-mpss-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MX power domain
- - description: MSS power domain
- power-domain-names:
- items:
- - const: cx
- - const: mx
- - const: mss
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sm6350-cdsp-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MX power domain
- power-domain-names:
- items:
- - const: cx
- - const: mx
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc7280-mpss-pas
- - qcom,sdx55-mpss-pas
- - qcom,sm6350-mpss-pas
- - qcom,sm8150-mpss-pas
- - qcom,sm8350-mpss-pas
- - qcom,sm8450-mpss-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MSS power domain
- power-domain-names:
- items:
- - const: cx
- - const: mss
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8180x-adsp-pas
- - qcom,sc8180x-cdsp-pas
- - qcom,sc8280xp-adsp-pas
- - qcom,sm6350-adsp-pas
- - qcom,sm8150-slpi-pas
- - qcom,sm8250-adsp-pas
- - qcom,sm8250-slpi-pas
- - qcom,sm8350-adsp-pas
- - qcom,sm8350-slpi-pas
- - qcom,sm8450-adsp-pas
- - qcom,sm8450-slpi-pas
+ enum:
+ - qcom,sdm845-slpi-pas
then:
properties:
power-domains:
@@ -490,84 +165,15 @@ allOf:
compatible:
contains:
enum:
- - qcom,sm8350-cdsp-pas
- - qcom,sm8450-cdsp-pas
- then:
- properties:
- power-domains:
- items:
- - description: CX power domain
- - description: MXC power domain
- power-domain-names:
- items:
- - const: cx
- - const: mxc
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc8280xp-nsp0-pas
- - qcom,sc8280xp-nsp1-pas
- then:
- properties:
- power-domains:
- items:
- - description: NSP power domain
- power-domain-names:
- items:
- - const: nsp
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,qcs404-cdsp-pas
- then:
- properties:
- resets:
- items:
- - description: CDSP restart
- reset-names:
- items:
- - const: restart
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,sc7180-mpss-pas
- - qcom,sc7280-mpss-pas
- then:
- properties:
- resets:
- items:
- - description: MSS restart
- - description: PDC reset
- reset-names:
- items:
- - const: mss_restart
- - const: pdc_reset
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- qcom,msm8226-adsp-pil
+ - qcom,msm8953-adsp-pil
- qcom,msm8974-adsp-pil
- qcom,msm8996-adsp-pil
- qcom,msm8996-slpi-pil
- qcom,msm8998-adsp-pas
- qcom,msm8998-slpi-pas
- - qcom,qcs404-adsp-pas
- - qcom,qcs404-cdsp-pas
- - qcom,qcs404-wcss-pas
- qcom,sdm660-adsp-pas
- - qcom,sdx55-mpss-pas
+ - qcom,sdm660-cdsp-pas
then:
properties:
qcom,qmp: false
@@ -577,6 +183,7 @@ examples:
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
adsp {
compatible = "qcom,msm8974-adsp-pil";
@@ -594,7 +201,8 @@ examples:
clocks = <&rpmcc RPM_CXO_CLK>;
clock-names = "xo";
- cx-supply = <&pm8841_s2>;
+ power-domains = <&rpmpd MSM8974_VDDCX>;
+ power-domain-names = "cx";
memory-region = <&adsp_region>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
index fa69f7b21eed..e78a89c9ec41 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml
@@ -14,24 +14,34 @@ description:
related to the remote processor.
properties:
- $nodename:
- const: "glink-edge"
-
apr:
$ref: /schemas/soc/qcom/qcom,apr.yaml#
+ required:
+ - qcom,glink-channels
description:
- Qualcomm APR/GPR (Asynchronous/Generic Packet Router)
+ Qualcomm APR (Asynchronous Packet Router)
fastrpc:
- type: object
+ $ref: /schemas/misc/qcom,fastrpc.yaml#
+ required:
+ - qcom,glink-channels
+ description:
+ Qualcomm FastRPC
+
+ gpr:
+ $ref: /schemas/soc/qcom/qcom,apr.yaml#
+ required:
+ - qcom,glink-channels
description:
- See Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
+ Qualcomm GPR (Generic Packet Router)
interrupts:
maxItems: 1
label:
- description: The names of the state bits used for SMP2P output
+ description:
+ Name of the edge, used for debugging and identification purposes. The
+ node name will be used if this is not present.
mboxes:
maxItems: 1
@@ -48,6 +58,21 @@ required:
- mboxes
- qcom,remote-pid
+allOf:
+ - if:
+ required:
+ - apr
+ then:
+ properties:
+ gpr: false
+
+ - if:
+ required:
+ - gpr
+ then:
+ properties:
+ apr: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
new file mode 100644
index 000000000000..c54234247ab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,glink-rpm-edge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm G-Link RPM edge
+
+description: |
+ Qualcomm G-Link edge, a FIFO based mechanism for communication with Resource
+ Power Manager (RPM) on various Qualcomm platforms.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ const: qcom,glink-rpm
+
+ label:
+ description:
+ Name of the edge, used for debugging and identification purposes. The
+ node name will be used if this is not present.
+
+ interrupts:
+ maxItems: 1
+
+ mboxes:
+ items:
+ - description: rpm_hlos mailbox in APCS
+
+ qcom,remote-pid:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The identifier for the remote processor as known by the rest of the
+ system.
+
+ qcom,rpm-msg-ram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ RPM message memory resource (compatible: qcom,rpm-msg-ram).
+
+ rpm-requests:
+ type: object
+ $ref: /schemas/soc/qcom/qcom,smd-rpm.yaml#
+ unevaluatedProperties: false
+ description:
+ Qualcomm Resource Power Manager (RPM) over G-Link
+
+ properties:
+ qcom,intents:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 32
+ items:
+ items:
+ - description: size of each intent to preallocate
+ - description: amount of intents to preallocate
+ minimum: 1
+ description:
+ List of (size, amount) pairs describing what intents should be
+ preallocated for this virtual channel. This can be used to tweak the
+ default intents available for the channel to meet expectations of the
+ remote.
+
+ required:
+ - qcom,glink-channels
+
+required:
+ - compatible
+ - interrupts
+ - mboxes
+
+anyOf:
+ - required:
+ - qcom,remote-pid
+ - required:
+ - qcom,rpm-msg-ram
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ glink-edge {
+ compatible = "qcom,glink-rpm";
+ interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 0>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-msm8996", "qcom,glink-smd-rpm";
+ qcom,glink-channels = "rpm_requests";
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml
new file mode 100644
index 000000000000..c47d97004b33
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml
@@ -0,0 +1,198 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,milos-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Milos SoC Peripheral Authentication Service
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+description:
+ Qualcomm Milos SoC Peripheral Authentication Service loads and boots firmware
+ on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,milos-adsp-pas
+ - qcom,milos-cdsp-pas
+ - qcom,milos-mpss-pas
+ - qcom,milos-wpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ minItems: 6
+ maxItems: 6
+
+ interrupt-names:
+ minItems: 6
+ maxItems: 6
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ minItems: 1
+ items:
+ - description: Firmware name of the Hexagon core
+ - description: Firmware name of the Hexagon Devicetree
+
+ memory-region:
+ minItems: 1
+ items:
+ - description: Memory region for core Firmware authentication
+ - description: Memory region for Devicetree Firmware authentication
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,milos-adsp-pas
+ - qcom,milos-cdsp-pas
+ then:
+ properties:
+ memory-region:
+ minItems: 2
+ firmware-name:
+ minItems: 2
+ else:
+ properties:
+ memory-region:
+ maxItems: 1
+ firmware-name:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,milos-cdsp-pas
+ - qcom,milos-wpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,milos-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,milos-rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,milos-adsp-pas";
+ reg = <0x03000000 0x10000>;
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack",
+ "shutdown-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ power-domains = <&rpmhpd RPMHPD_LCX>,
+ <&rpmhpd RPMHPD_LMX>;
+ power-domain-names = "lcx",
+ "lmx";
+
+ interconnects = <&lpass_ag_noc MASTER_LPASS_PROC QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+ memory-region = <&adspslpi_mem>, <&q6_adsp_dtb_mem>;
+
+ firmware-name = "qcom/milos/vendor/device/adsp.mbn",
+ "qcom/milos/vendor/device/adsp_dtb.mbn";
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
new file mode 100644
index 000000000000..c179b560572b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
@@ -0,0 +1,345 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,msm8916-mss-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8916 MSS Peripheral Image Loader (and similar)
+
+maintainers:
+ - Stephan Gerhold <stephan@gerhold.net>
+
+description:
+ This document describes the hardware for a component that loads and boots
+ firmware on the Qualcomm MSM8916 Modem Hexagon Core (and similar).
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,msm8226-mss-pil
+ - qcom,msm8909-mss-pil
+ - qcom,msm8916-mss-pil
+ - qcom,msm8926-mss-pil
+ - qcom,msm8953-mss-pil
+ - qcom,msm8974-mss-pil
+
+ - const: qcom,q6v5-pil
+ description: Deprecated, prefer using qcom,msm8916-mss-pil
+ deprecated: true
+
+ reg:
+ items:
+ - description: MSS QDSP6 registers
+ - description: RMB registers
+
+ reg-names:
+ items:
+ - const: qdsp6
+ - const: rmb
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+
+ clocks:
+ items:
+ - description: Configuration interface (AXI) clock
+ - description: Configuration bus (AHB) clock
+ - description: Boot ROM (AHB) clock
+ - description: XO proxy clock (control handed over after startup)
+
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: xo
+
+ power-domains:
+ items:
+ - description: CX proxy power domain (control handed over after startup)
+ - description: MX proxy power domain (control handed over after startup)
+ (not valid for qcom,msm8226-mss-pil, qcom,msm8926-mss-pil
+ and qcom,msm8974-mss-pil)
+ - description: MSS proxy power domain (control handed over after startup)
+ (only valid for qcom,msm8953-mss-pil)
+ minItems: 1
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx # not valid for qcom,msm8226-mss-pil, qcom-msm8926-mss-pil and qcom,msm8974-mss-pil
+ - const: mss # only valid for qcom,msm8953-mss-pil
+ minItems: 1
+
+ pll-supply:
+ description: PLL proxy supply (control handed over after startup)
+
+ mss-supply:
+ description: MSS power domain supply (only valid for qcom,msm8974-mss-pil)
+
+ resets:
+ items:
+ - description: MSS restart control
+
+ reset-names:
+ items:
+ - const: mss_restart
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop modem
+
+ qcom,smem-state-names:
+ description: Names of the states used by the AP to signal the Hexagon core
+ items:
+ - const: stop
+
+ qcom,ext-bhs-reg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: External power block headswitch (BHS) register
+ (only valid for qcom,msm8226-mss-pil)
+ items:
+ - items:
+ - description: phandle to external BHS syscon region
+ - description: offset to the external BHS register
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Halt registers are used to halt transactions of various sub-components
+ within MSS.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
+ - description: offset to the modem halt register
+ - description: offset to the nc halt register
+
+ memory-region:
+ items:
+ - description: MBA reserved region
+ - description: MPSS reserved region
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Name of MBA firmware
+ - description: Name of modem firmware
+
+ bam-dmux:
+ $ref: /schemas/net/qcom,bam-dmux.yaml#
+ description:
+ Qualcomm BAM Data Multiplexer (provides network interface to the modem)
+
+ smd-edge:
+ $ref: qcom,smd-edge.yaml#
+ description:
+ Qualcomm SMD subnode which represents communication edge, channels
+ and devices related to the DSP.
+ properties:
+ label:
+ enum:
+ - modem
+ - hexagon
+ unevaluatedProperties: false
+
+ # Deprecated properties
+ cx-supply:
+ description: CX power domain regulator supply (prefer using power-domains)
+ deprecated: true
+
+ mx-supply:
+ description: MX power domain regulator supply (prefer using power-domains)
+ deprecated: true
+
+ mba:
+ type: object
+ additionalProperties: false
+ description:
+ MBA reserved region (prefer using memory-region with two items)
+ properties:
+ memory-region: true
+ required:
+ - memory-region
+ deprecated: true
+
+ mpss:
+ type: object
+ additionalProperties: false
+ description:
+ MPSS reserved region (prefer using memory-region with two items)
+ properties:
+ memory-region: true
+ required:
+ - memory-region
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - pll-supply
+ - resets
+ - reset-names
+ - qcom,halt-regs
+ - qcom,smem-states
+ - qcom,smem-state-names
+ - smd-edge
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8953-mss-pil
+ then:
+ properties:
+ power-domains:
+ minItems: 3
+ power-domain-names:
+ minItems: 3
+ required:
+ - power-domains
+ - power-domain-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8909-mss-pil
+ - qcom,msm8916-mss-pil
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+ maxItems: 2
+ power-domain-names:
+ minItems: 2
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8226-mss-pil
+ - qcom,msm8926-mss-pil
+ - qcom,msm8974-mss-pil
+ then:
+ properties:
+ power-domains:
+ maxItems: 1
+ power-domain-names:
+ maxItems: 1
+ required:
+ - mx-supply
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8226-mss-pil
+ then:
+ required:
+ - qcom,ext-bhs-reg
+ else:
+ properties:
+ qcom,ext-bhs-reg: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8926-mss-pil
+ - qcom,msm8974-mss-pil
+ then:
+ required:
+ - mss-supply
+ else:
+ properties:
+ mss-supply: false
+
+ # Fallbacks for deprecated properties
+ - oneOf:
+ - required:
+ - memory-region
+ - required:
+ - mba
+ - mpss
+ - oneOf:
+ - required:
+ - power-domains
+ - power-domain-names
+ - required:
+ - cx-supply
+ - mx-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc_mpss: remoteproc@4080000 {
+ compatible = "qcom,msm8916-mss-pil";
+ reg = <0x04080000 0x100>, <0x04020000 0x40>;
+ reg-names = "qdsp6", "rmb";
+
+ interrupts-extended = <&intc GIC_SPI 24 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&hexagon_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+ qcom,smem-states = <&hexagon_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+ qcom,halt-regs = <&tcsr 0x18000 0x19000 0x1a000>;
+
+ clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+ <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
+ <&gcc GCC_BOOT_ROM_AHB_CLK>,
+ <&xo_board>;
+ clock-names = "iface", "bus", "mem", "xo";
+
+ power-domains = <&rpmpd MSM8916_VDDCX>, <&rpmpd MSM8916_VDDMX>;
+ power-domain-names = "cx", "mx";
+ pll-supply = <&pm8916_l7>;
+
+ resets = <&scm 0>;
+ reset-names = "mss_restart";
+
+ memory-region = <&mba_mem>, <&mpss_mem>;
+
+ smd-edge {
+ interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,smd-edge = <0>;
+ qcom,ipc = <&apcs 8 12>;
+ qcom,remote-pid = <1>;
+
+ label = "hexagon";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
new file mode 100644
index 000000000000..4d2055f283ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
@@ -0,0 +1,392 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,msm8996-mss-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8996 MSS Peripheral Image Loader (and similar)
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Sibi Sankar <quic_sibis@quicinc.com>
+
+description:
+ MSS Peripheral Image Loader loads and boots firmware on the
+ Qualcomm Technology Inc. MSM8996 Modem Hexagon Core (and similar).
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8996-mss-pil
+ - qcom,msm8998-mss-pil
+ - qcom,sdm660-mss-pil
+ - qcom,sdm845-mss-pil
+
+ reg:
+ items:
+ - description: MSS QDSP6 registers
+ - description: RMB registers
+
+ reg-names:
+ items:
+ - const: qdsp6
+ - const: rmb
+
+ iommus:
+ items:
+ - description: MSA Stream 1
+ - description: MSA Stream 2
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Shutdown acknowledge interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: shutdown-ack
+
+ clocks:
+ minItems: 8
+ maxItems: 9
+
+ clock-names:
+ minItems: 8
+ maxItems: 9
+
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ - description: MSS power domain (only valid for qcom,sdm845-mss-pil)
+ minItems: 2
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+ - const: mss # only valid for qcom,sdm845-mss-pil
+ minItems: 2
+
+ pll-supply:
+ description: PLL supply
+
+ resets:
+ items:
+ - description: AOSS restart
+ - description: PDC reset (only valid for qcom,sdm845-mss-pil)
+ minItems: 1
+
+ reset-names:
+ items:
+ - const: mss_restart
+ - const: pdc_reset # only valid for qcom,sdm845-mss-pil
+ minItems: 1
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop modem
+
+ qcom,smem-state-names:
+ description: Names of the states used by the AP to signal the Hexagon core
+ items:
+ - const: stop
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Halt registers are used to halt transactions of various sub-components
+ within MSS.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
+ - description: offset to the modem halt register
+ - description: offset to the nc halt register
+
+ memory-region:
+ items:
+ - description: MBA reserved region
+ - description: Modem reserved region
+ - description: Metadata reserved region
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Name of MBA firmware
+ - description: Name of modem firmware
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the Modem.
+ unevaluatedProperties: false
+
+ glink-edge:
+ $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
+ description:
+ Qualcomm G-Link subnode which represents communication edge, channels
+ and devices related to the Modem.
+ unevaluatedProperties: false
+
+ # Deprecated properties
+ mba:
+ type: object
+ description:
+ MBA reserved region
+
+ properties:
+ memory-region: true
+
+ required:
+ - memory-region
+
+ additionalProperties: false
+ deprecated: true
+
+ mpss:
+ type: object
+ description:
+ MPSS reserved region
+
+ properties:
+ memory-region: true
+
+ required:
+ - memory-region
+
+ additionalProperties: false
+ deprecated: true
+
+ metadata:
+ type: object
+ description:
+ Metadata reserved region
+
+ properties:
+ memory-region: true
+
+ required:
+ - memory-region
+
+ additionalProperties: false
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - power-domain-names
+ - resets
+ - reset-names
+ - qcom,halt-regs
+ - qcom,smem-states
+ - qcom,smem-state-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: qcom,msm8996-mss-pil
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GCC MSS IFACE clock
+ - description: GCC MSS BUS clock
+ - description: GCC MSS MEM clock
+ - description: RPM XO clock
+ - description: GCC MSS GPLL0 clock
+ - description: GCC MSS SNOC_AXI clock
+ - description: GCC MSS MNOC_AXI clock
+ - description: RPM QDSS clock
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: xo
+ - const: gpll0_mss
+ - const: snoc_axi
+ - const: mnoc_axi
+ - const: qdss
+ required:
+ - pll-supply
+ - smd-edge
+ else:
+ properties:
+ pll-supply: false
+ smd-edge: false
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,msm8998-mss-pil
+ - qcom,sdm660-mss-pil
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GCC MSS IFACE clock
+ - description: GCC MSS BUS clock
+ - description: GCC MSS MEM clock
+ - description: GCC MSS GPLL0 clock
+ - description: GCC MSS SNOC_AXI clock
+ - description: GCC MSS MNOC_AXI clock
+ - description: RPMH QDSS clock
+ - description: RPMH XO clock
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: gpll0_mss
+ - const: snoc_axi
+ - const: mnoc_axi
+ - const: qdss
+ - const: xo
+ required:
+ - glink-edge
+
+ - if:
+ properties:
+ compatible:
+ const: qcom,sdm845-mss-pil
+ then:
+ properties:
+ power-domains:
+ minItems: 3
+ power-domain-names:
+ minItems: 3
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+ clocks:
+ items:
+ - description: GCC MSS IFACE clock
+ - description: GCC MSS BUS clock
+ - description: GCC MSS MEM clock
+ - description: GCC MSS GPLL0 clock
+ - description: GCC MSS SNOC_AXI clock
+ - description: GCC MSS MNOC_AXI clock
+ - description: GCC MSS PRNG clock
+ - description: RPMH XO clock
+ clock-names:
+ items:
+ - const: iface
+ - const: bus
+ - const: mem
+ - const: gpll0_mss
+ - const: snoc_axi
+ - const: mnoc_axi
+ - const: prng
+ - const: xo
+ required:
+ - qcom,qmp
+ - glink-edge
+ else:
+ properties:
+ iommus: false
+ power-domains:
+ maxItems: 2
+ power-domain-names:
+ maxItems: 2
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+ qcom,qmp: false
+
+ # Fallbacks for deprecated properties
+ - oneOf:
+ - required:
+ - memory-region
+ - required:
+ - mba
+ - mpss
+ - metadata
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/reset/qcom,sdm845-aoss.h>
+ #include <dt-bindings/reset/qcom,sdm845-pdc.h>
+
+ remoteproc@4080000 {
+ compatible = "qcom,sdm845-mss-pil";
+ reg = <0x04080000 0x408>, <0x04180000 0x48>;
+ reg-names = "qdsp6", "rmb";
+
+ interrupts-extended = <&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack",
+ "shutdown-ack";
+
+ clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+ <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+ <&gcc GCC_BOOT_ROM_AHB_CLK>,
+ <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+ <&gcc GCC_MSS_SNOC_AXI_CLK>,
+ <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+ <&gcc GCC_PRNG_AHB_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "bus", "mem", "gpll0_mss",
+ "snoc_axi", "mnoc_axi", "prng", "xo";
+
+ power-domains = <&rpmhpd SDM845_CX>,
+ <&rpmhpd SDM845_MX>,
+ <&rpmhpd SDM845_MSS>;
+ power-domain-names = "cx", "mx", "mss";
+
+ memory-region = <&mba_mem>, <&mpss_mem>, <&mdata_mem>;
+
+ resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+ <&pdc_reset PDC_MODEM_SYNC_RESET>;
+ reset-names = "mss_restart", "pdc_reset";
+
+ qcom,halt-regs = <&tcsr_regs_1 0x3000 0x5000 0x4000>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&modem_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+ label = "modem";
+ qcom,remote-pid = <1>;
+ mboxes = <&apss_shared 12>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
new file mode 100644
index 000000000000..63a82e7a8bf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,pas-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Peripheral Authentication Service Common Properties
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Common properties of Qualcomm SoCs Peripheral Authentication Service.
+
+properties:
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ interconnects:
+ maxItems: 1
+
+ interrupts:
+ minItems: 5
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Shutdown acknowledge interrupt
+
+ interrupt-names:
+ minItems: 5
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: shutdown-ack
+
+ power-domains:
+ minItems: 1
+ maxItems: 3
+
+ power-domain-names:
+ minItems: 1
+ maxItems: 3
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop the modem
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output
+ items:
+ - const: stop
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the ADSP.
+ unevaluatedProperties: false
+
+ glink-edge:
+ $ref: /schemas/remoteproc/qcom,glink-edge.yaml#
+ description:
+ Qualcomm G-Link subnode which represents communication edge, channels
+ and devices related to the ADSP.
+ unevaluatedProperties: false
+
+required:
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - qcom,smem-states
+ - qcom,smem-state-names
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
index 9282837d64ba..22219d16df20 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/remoteproc/qcom,pil-info.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm peripheral image loader relocation info binding
+title: Qualcomm peripheral image loader relocation info
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
@@ -30,7 +30,7 @@ additionalProperties: false
examples:
- |
imem@146bf000 {
- compatible = "syscon", "simple-mfd";
+ compatible = "qcom,sdm630-imem", "syscon", "simple-mfd";
reg = <0x146bf000 0x1000>;
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index d0ebd16ee0e1..573a88b60677 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -7,14 +7,8 @@ on the Qualcomm Hexagon core.
Usage: required
Value type: <string>
Definition: must be one of:
- "qcom,q6v5-pil",
"qcom,ipq8074-wcss-pil"
"qcom,qcs404-wcss-pil"
- "qcom,msm8916-mss-pil",
- "qcom,msm8974-mss-pil"
- "qcom,msm8996-mss-pil"
- "qcom,msm8998-mss-pil"
- "qcom,sdm845-mss-pil"
- reg:
Usage: required
@@ -35,26 +29,7 @@ on the Qualcomm Hexagon core.
- interrupt-names:
Usage: required
Value type: <stringlist>
- Definition: The interrupts needed depends on the compatible
- string:
- qcom,q6v5-pil:
- qcom,ipq8074-wcss-pil:
- qcom,qcs404-wcss-pil:
- qcom,msm8916-mss-pil:
- qcom,msm8974-mss-pil:
- must be "wdog", "fatal", "ready", "handover", "stop-ack"
- qcom,msm8996-mss-pil:
- qcom,msm8998-mss-pil:
- qcom,sdm845-mss-pil:
- must be "wdog", "fatal", "ready", "handover", "stop-ack",
- "shutdown-ack"
-
-- firmware-name:
- Usage: optional
- Value type: <stringlist>
- Definition: must list the relative firmware image paths for mba and
- modem. They are used for booting and authenticating the
- Hexagon core.
+ Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
- clocks:
Usage: required
@@ -72,67 +47,23 @@ on the Qualcomm Hexagon core.
"gcc_axim_cbcr", "lcc_ahbfabric_cbc", "tcsr_lcc_cbc",
"lcc_abhs_cbc", "lcc_tcm_slave_cbc", "lcc_abhm_cbc",
"lcc_axim_cbc", "lcc_bcr_sleep"
- qcom,q6v5-pil:
- qcom,msm8916-mss-pil:
- qcom,msm8974-mss-pil:
- must be "iface", "bus", "mem", "xo"
- qcom,msm8996-mss-pil:
- must be "iface", "bus", "mem", "xo", "gpll0_mss",
- "snoc_axi", "mnoc_axi", "pnoc", "qdss"
- qcom,msm8998-mss-pil:
- must be "iface", "bus", "mem", "xo", "gpll0_mss",
- "snoc_axi", "mnoc_axi", "qdss"
- qcom,sdm845-mss-pil:
- must be "iface", "bus", "mem", "xo", "gpll0_mss",
- "snoc_axi", "mnoc_axi", "prng"
- resets:
Usage: required
Value type: <phandle>
- Definition: reference to the reset-controller for the modem sub-system
- reference to the list of 3 reset-controllers for the
+ Definition: reference to the list of 3 reset-controllers for the
wcss sub-system
- reference to the list of 2 reset-controllers for the modem
- sub-system on SDM845 SoCs
- reset-names:
Usage: required
Value type: <stringlist>
- Definition: must be "mss_restart" for the modem sub-system
- must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
+ Definition: must be "wcss_aon_reset", "wcss_reset", "wcss_q6_reset"
for the wcss sub-system
- must be "mss_restart", "pdc_reset" for the modem
- sub-system on SDM845 SoCs
-For devices where the mba and mpss sub-nodes are not specified, mba/mpss region
-should be referenced as follows:
- memory-region:
Usage: required
Value type: <phandle>
- Definition: reference to the reserved-memory for the mba region followed
- by the mpss region
-
-For the compatible strings below the following supplies are required:
- "qcom,q6v5-pil"
- "qcom,msm8916-mss-pil",
-- cx-supply: (deprecated, use power domain instead)
-- mx-supply: (deprecated, use power domain instead)
-- pll-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the Hexagon core
-
-For the compatible string below the following supplies are required:
- "qcom,msm8974-mss-pil"
-- cx-supply: (deprecated, use power domain instead)
-- mss-supply:
-- mx-supply: (deprecated, use power domain instead)
-- pll-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the Hexagon core
+ Definition: reference to wcss reserved-memory region.
For the compatible string below the following supplies are required:
"qcom,qcs404-wcss-pil"
@@ -142,39 +73,6 @@ For the compatible string below the following supplies are required:
Definition: reference to the regulators to be held on behalf of the
booting of the Hexagon core
-For the compatible string below the following supplies are required:
- "qcom,msm8996-mss-pil"
-- pll-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the Hexagon core
-
-- power-domains:
- Usage: required
- Value type: <phandle>
- Definition: reference to power-domains that match power-domain-names
-
-- power-domain-names:
- Usage: required
- Value type: <stringlist>
- Definition: The power-domains needed depend on the compatible string:
- qcom,ipq8074-wcss-pil:
- no power-domain names required
- qcom,q6v5-pil:
- qcom,msm8916-mss-pil:
- qcom,msm8974-mss-pil:
- qcom,msm8996-mss-pil:
- qcom,msm8998-mss-pil:
- must be "cx", "mx"
- qcom,sdm845-mss-pil:
- must be "cx", "mx", "mss"
-
-- qcom,qmp:
- Usage: optional
- Value type: <phandle>
- Definition: reference to the AOSS side-channel message RAM.
-
- qcom,smem-states:
Usage: required
Value type: <phandle>
@@ -190,16 +88,9 @@ For the compatible string below the following supplies are required:
Usage: required
Value type: <prop-encoded-array>
Definition: a phandle reference to a syscon representing TCSR followed
- by the three offsets within syscon for q6, modem and nc
+ by the three offsets within syscon for q6, wcss and nc
halt registers.
-The Hexagon node must contain iommus property as described in ../iommu/iommu.txt
-on platforms which do not have TrustZone.
-
-= SUBNODES:
-The Hexagon node must contain two subnodes, named "mba" and "mpss" representing
-the memory regions used by the Hexagon firmware. Each sub-node must contain:
-
- memory-region:
Usage: required
Value type: <phandle>
@@ -209,56 +100,3 @@ The Hexagon node may also have an subnode named either "smd-edge" or
"glink-edge" that describes the communication edge, channels and devices
related to the Hexagon. See ../soc/qcom/qcom,smd.yaml and
../soc/qcom/qcom,glink.txt for details on how to describe these.
-
-= EXAMPLE
-The following example describes the resources needed to boot control the
-Hexagon, as it is found on MSM8974 boards.
-
- remoteproc@fc880000 {
- compatible = "qcom,msm8974-mss-pil";
- reg = <0xfc880000 0x100>, <0xfc820000 0x020>;
- reg-names = "qdsp6", "rmb";
-
- interrupts-extended = <&intc GIC_SPI 24 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
- <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
-
- clocks = <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
- <&gcc GCC_MSS_CFG_AHB_CLK>,
- <&gcc GCC_BOOT_ROM_AHB_CLK>,
- <&xo_board>;
- clock-names = "iface", "bus", "mem", "xo";
-
- resets = <&gcc GCC_MSS_RESTART>;
- reset-names = "mss_restart";
-
- cx-supply = <&pm8841_s2>;
- mss-supply = <&pm8841_s3>;
- mx-supply = <&pm8841_s1>;
- pll-supply = <&pm8941_l12>;
-
- qcom,halt-regs = <&tcsr_mutex_block 0x1180 0x1200 0x1280>;
-
- qcom,smem-states = <&modem_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- mba {
- memory-region = <&mba_region>;
- };
-
- mpss {
- memory-region = <&mpss_region>;
- };
-
- smd-edge {
- interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
-
- qcom,ipc = <&apcs 8 12>;
- qcom,smd-edge = <0>;
-
- label = "modem";
- };
- };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
index 06f5f93f62a9..bca59394aef4 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
@@ -81,7 +81,11 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Phandle reference to a syscon representing TCSR followed by the
- three offsets within syscon for q6, modem and nc halt registers.
+ offset within syscon for q6 halt register.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
qcom,smem-states:
$ref: /schemas/types.yaml#/definitions/phandle-array
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
new file mode 100644
index 000000000000..ad45fd00ae34
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,qcs404-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCS404 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm QCS404 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,qcs404-adsp-pas
+ - qcom,qcs404-cdsp-pas
+ - qcom,qcs404-wcss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ maxItems: 5
+
+ interrupt-names:
+ maxItems: 5
+
+ power-domains: false
+ power-domain-names: false
+ smd-edge: false
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ remoteproc@c700000 {
+ compatible = "qcom,qcs404-adsp-pas";
+ reg = <0x0c700000 0x4040>;
+
+ clocks = <&xo_board>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 293 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_fw_mem>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 289 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,remote-pid = <2>;
+ mboxes = <&apcs_glb 8>;
+
+ label = "adsp";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
new file mode 100644
index 000000000000..540bdfca53d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,rpm-proc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Resource Power Manager (RPM) Processor/Subsystem
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+ - Stephan Gerhold <stephan@gerhold.net>
+
+description: |
+ Resource Power Manager (RPM) subsystem found in various Qualcomm platforms:
+
+ +--------------------------------------------+
+ | RPM subsystem (qcom,rpm-proc) |
+ | |
+ reset | +---------------+ +-----+ +-----+ |
+ --------->| | | MPM | | CPR | ... |
+ IPC interrupts | | ARM Cortex-M3 |--- +-----+ +-----+ |
+ ----------------->| | | | | |
+ | +---------------+ |---------------------- |
+ | +---------------+ | |
+ | | Code RAM |--| +------------------+ |
+ | +---------------+ | | | |
+ | +---------------+ |--| Message RAM | |
+ | | Data RAM |--| | | |
+ | +---------------+ | +------------------+ |
+ +--------------------|-----------------------+
+ v
+ NoC
+
+ The firmware running on the processor inside the RPM subsystem allows each
+ component in the system to vote for state of the system resources, such as
+ clocks, regulators and bus frequencies. It implements multiple separate
+ communication interfaces that are described in subnodes, e.g. SMD and MPM:
+
+ +------------------------------+
+ | ARM Cortex-M3 |
+ | | +------------------------------+
+ | +--------------------------+ | | Message RAM |
+ | | RPM firmware | | | |
+ IPC IRQ 0 | | +----------------------+ | | | +--------------------------+ |
+ -------------->| SMD server |<------->| SMD data structures | |
+ | | | +--------------+ | | | | | +--------------+ | |
+ | | | | rpm_requests | ... | | | | | | rpm_requests | ... | |
+ | | | +--------------+ | | | | | +--------------+ | |
+ IPC IRQ 1 | | +----------------------+ | | | +--------------------------+ |
+ -------------->| MPM virtualization |<--------| MPM register copy (vMPM) | |
+ | | +----------------------+ | | | +--------------------------+ |
+ | | ... | | | | ... |
+ | +--------------------|-----+ | +------------------------------+
+ +----------------------|-------+
+ v
+ +--------------+
+ | MPM Hardware |
+ +--------------+
+
+ The services provided by the firmware are only available after the firmware
+ has been loaded and the processor has been released from reset. Usually this
+ happens early in the boot process before the operating system is started.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,apq8084-rpm-proc
+ - qcom,ipq6018-rpm-proc
+ - qcom,ipq9574-rpm-proc
+ - qcom,mdm9607-rpm-proc
+ - qcom,msm8226-rpm-proc
+ - qcom,msm8610-rpm-proc
+ - qcom,msm8909-rpm-proc
+ - qcom,msm8916-rpm-proc
+ - qcom,msm8917-rpm-proc
+ - qcom,msm8936-rpm-proc
+ - qcom,msm8937-rpm-proc
+ - qcom,msm8952-rpm-proc
+ - qcom,msm8953-rpm-proc
+ - qcom,msm8974-rpm-proc
+ - qcom,msm8976-rpm-proc
+ - qcom,msm8994-rpm-proc
+ - qcom,msm8996-rpm-proc
+ - qcom,msm8998-rpm-proc
+ - qcom,qcm2290-rpm-proc
+ - qcom,qcs404-rpm-proc
+ - qcom,sdm660-rpm-proc
+ - qcom,sm6115-rpm-proc
+ - qcom,sm6125-rpm-proc
+ - qcom,sm6375-rpm-proc
+ - const: qcom,rpm-proc
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the RPM subsystem.
+
+ glink-edge:
+ $ref: /schemas/remoteproc/qcom,glink-rpm-edge.yaml#
+ description:
+ Qualcomm G-Link subnode which represents communication edge,
+ channels and devices related to the RPM subsystem.
+
+ interrupt-controller:
+ type: object
+ $ref: /schemas/interrupt-controller/qcom,mpm.yaml#
+ description:
+ MSM Power Manager (MPM) interrupt controller that monitors interrupts
+ when the system is asleep.
+
+ master-stats:
+ $ref: /schemas/soc/qcom/qcom,rpm-master-stats.yaml#
+ description:
+ Subsystem-level low-power mode statistics provided by RPM.
+
+required:
+ - compatible
+
+oneOf:
+ - required:
+ - smd-edge
+ - required:
+ - glink-edge
+
+additionalProperties: false
+
+examples:
+ # SMD
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ remoteproc {
+ compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc";
+
+ smd-edge {
+ interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+ qcom,ipc = <&apcs 8 0>;
+ qcom,smd-edge = <15>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
+ qcom,smd-channels = "rpm_requests";
+ /* ... */
+ };
+ };
+ };
+ # GLINK
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ remoteproc {
+ compatible = "qcom,qcm2290-rpm-proc", "qcom,rpm-proc";
+
+ glink-edge {
+ compatible = "qcom,glink-rpm";
+ interrupts = <GIC_SPI 194 IRQ_TYPE_EDGE_RISING>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+ mboxes = <&apcs_glb 0>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-qcm2290", "qcom,glink-smd-rpm";
+ qcom,glink-channels = "rpm_requests";
+ /* ... */
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml
new file mode 100644
index 000000000000..188a25194000
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sa8775p-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SA8775p Peripheral Authentication Service
+
+maintainers:
+ - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+description:
+ Qualcomm SA8775p SoC Peripheral Authentication Service loads and boots firmware
+ on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcs8300-adsp-pas
+ - const: qcom,sa8775p-adsp-pas
+ - items:
+ - enum:
+ - qcom,qcs8300-cdsp-pas
+ - const: qcom,sa8775p-cdsp0-pas
+ - items:
+ - enum:
+ - qcom,qcs8300-gpdsp-pas
+ - const: qcom,sa8775p-gpdsp0-pas
+ - enum:
+ - qcom,sa8775p-adsp-pas
+ - qcom,sa8775p-cdsp0-pas
+ - qcom,sa8775p-cdsp1-pas
+ - qcom,sa8775p-gpdsp0-pas
+ - qcom,sa8775p-gpdsp1-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Firmware name of the Hexagon core
+
+ memory-region:
+ items:
+ - description: Memory region for main Firmware authentication
+
+ interrupts:
+ maxItems: 5
+
+ interrupt-names:
+ maxItems: 5
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-cdsp0-pas
+ - qcom,sa8775p-cdsp1-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MXC power domain
+ - description: NSP0 power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mxc
+ - const: nsp
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8775p-gpdsp0-pas
+ - qcom,sa8775p-gpdsp1-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MXC power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mxc
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,sa8775p-rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ remoteproc@30000000 {
+ compatible = "qcom,sa8775p-adsp-pas";
+ reg = <0x30000000 0x100>;
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ power-domains = <&rpmhpd RPMHPD_LCX>, <&rpmhpd RPMHPD_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ interconnects = <&lpass_ag_noc MASTER_LPASS_PROC 0 &mc_virt SLAVE_EBI1 0>;
+
+ memory-region = <&pil_adsp_mem>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
index e76c861165dd..b1402bef0ebe 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
@@ -95,6 +95,7 @@ properties:
items:
- description: MBA reserved region
- description: modem reserved region
+ - description: metadata reserved region
firmware-name:
$ref: /schemas/types.yaml#/definitions/string-array
@@ -140,6 +141,7 @@ properties:
glink-edge:
$ref: qcom,glink-edge.yaml#
+ unevaluatedProperties: false
description:
Qualcomm G-Link subnode which represents communication edge, channels
and devices related to the DSP.
@@ -222,7 +224,7 @@ examples:
<&rpmhpd SC7180_MSS>;
power-domain-names = "cx", "mx", "mss";
- memory-region = <&mba_mem>, <&mpss_mem>;
+ memory-region = <&mba_mem>, <&mpss_mem>, <&mdata_mem>;
qcom,qmp = <&aoss_qmp>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
new file mode 100644
index 000000000000..66b455d0a8e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
@@ -0,0 +1,186 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc7180-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7180/SC7280 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SC7180/SC7280 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7180-adsp-pas
+ - qcom,sc7180-mpss-pas
+ - qcom,sc7280-adsp-pas
+ - qcom,sc7280-cdsp-pas
+ - qcom,sc7280-mpss-pas
+ - qcom,sc7280-wpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-adsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-adsp-pas
+ - qcom,sc7280-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7180-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+ - const: mss
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-cdsp-pas
+ - qcom,sc7280-wpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@4080000 {
+ compatible = "qcom,sc7180-mpss-pas";
+ reg = <0x04080000 0x4040>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ memory-region = <&mpss_mem>;
+
+ power-domains = <&rpmhpd SC7180_CX>,
+ <&rpmhpd SC7180_MX>,
+ <&rpmhpd SC7180_MSS>;
+ power-domain-names = "cx", "mx", "mss";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&modem_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+ label = "modem";
+ qcom,remote-pid = <1>;
+ mboxes = <&apss_shared 12>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
new file mode 100644
index 000000000000..94ca7a0cc203
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-adsp-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7280 ADSP Peripheral Image Loader
+
+maintainers:
+ - Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
+
+description:
+ This document describes the hardware for a component that loads and boots firmware
+ on the Qualcomm Technology Inc. ADSP.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc7280-adsp-pil
+
+ reg:
+ items:
+ - description: qdsp6ss register
+ - description: efuse q6ss register
+
+ iommus:
+ items:
+ - description: Phandle to apps_smmu node with sid mask
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Shutdown acknowledge interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: shutdown-ack
+
+ clocks:
+ items:
+ - description: XO clock
+ - description: GCC CFG NOC LPASS clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: gcc_cfg_noc_lpass
+
+ power-domains:
+ items:
+ - description: LCX power domain
+
+ resets:
+ items:
+ - description: PDC AUDIO SYNC RESET
+ - description: CC LPASS restart
+
+ reset-names:
+ items:
+ - const: pdc_sync
+ - const: cc_lpass
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Phandle reference to a syscon representing TCSR followed by the
+ four offsets within syscon for q6, modem, nc and qv6 halt registers.
+ items:
+ - items:
+ - description: phandle to TCSR_MUTEX registers
+ - description: offset to the Q6 halt register
+ - description: offset to the modem halt register
+ - description: offset to the nc halt register
+ - description: offset to the vq6 halt register
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: States used by the AP to signal the Hexagon core
+ items:
+ - description: Stop the modem
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output
+ const: stop
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ glink-edge:
+ $ref: qcom,glink-edge.yaml#
+ type: object
+ unevaluatedProperties: false
+ description: |
+ Qualcomm G-Link subnode which represents communication edge, channels
+ and devices related to the ADSP.
+
+ properties:
+ label:
+ const: lpass
+
+ gpr: true
+ apr: false
+ fastrpc: false
+
+ required:
+ - label
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+ - qcom,halt-regs
+ - memory-region
+ - qcom,smem-states
+ - qcom,smem-state-names
+ - qcom,qmp
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpass-sc7280.h>
+ #include <dt-bindings/reset/qcom,sdm845-aoss.h>
+ #include <dt-bindings/reset/qcom,sdm845-pdc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,sc7280-adsp-pil";
+ reg = <0x03000000 0x5000>,
+ <0x0355b000 0x10>;
+
+ interrupts-extended = <&pdc 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack", "shutdown-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_CFG_NOC_LPASS_CLK>;
+ clock-names = "xo", "gcc_cfg_noc_lpass";
+
+ power-domains = <&rpmhpd SC7280_LCX>;
+
+ resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>,
+ <&aoss_reset AOSS_CC_LPASS_RESTART>;
+ reset-names = "pdc_sync", "cc_lpass";
+
+ qcom,halt-regs = <&tcsr_mutex 0x23000 0x25000 0x28000 0x33000>;
+
+ memory-region = <&adsp_mem>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ qcom,qmp = <&aoss_qmp>;
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
index da1a5de3d38b..005cb21732af 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
@@ -95,6 +95,7 @@ properties:
items:
- description: MBA reserved region
- description: modem reserved region
+ - description: metadata reserved region
firmware-name:
$ref: /schemas/types.yaml#/definitions/string-array
@@ -154,6 +155,7 @@ properties:
glink-edge:
$ref: qcom,glink-edge.yaml#
+ unevaluatedProperties: false
description:
Qualcomm G-Link subnode which represents communication edge, channels
and devices related to the DSP.
@@ -239,7 +241,7 @@ examples:
<&rpmhpd SC7280_MSS>;
power-domain-names = "cx", "mss";
- memory-region = <&mba_mem>, <&mpss_mem>;
+ memory-region = <&mba_mem>, <&mpss_mem>, <&mdata_mem>;
qcom,qmp = <&aoss_qmp>;
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
index 3f06d66cbe47..f4118b2da5f6 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
@@ -80,7 +80,7 @@ properties:
description: Reference to the reserved-memory for the Hexagon core
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
description:
The name of the firmware which should be loaded for this remote
processor.
@@ -89,7 +89,11 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Phandle reference to a syscon representing TCSR followed by the
- three offsets within syscon for q6, modem and nc halt registers.
+ offset within syscon for q6 halt register.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
qcom,qmp:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -107,6 +111,7 @@ properties:
glink-edge:
$ref: qcom,glink-edge.yaml#
+ unevaluatedProperties: false
description:
Qualcomm G-Link subnode which represents communication edge, channels
and devices related to the ADSP.
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
new file mode 100644
index 000000000000..5dbda3a55047
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sc8280xp-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC8280XP Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SC8280XP SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-adsp-pas
+ - qcom,sc8280xp-nsp0-pas
+ - qcom,sc8280xp-nsp1-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-nsp0-pas
+ - qcom,sc8280xp-nsp1-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+ else:
+ properties:
+ power-domains:
+ items:
+ - description: NSP power domain
+ - description: CX power domain
+ - description: MXC power domain
+ power-domain-names:
+ items:
+ - const: nsp
+ - const: cx
+ - const: mxc
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,sc8280xp-adsp-pas";
+ reg = <0x03000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sc8280xp/qcadsp8280.mbn";
+
+ interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack", "shutdown-ack";
+
+ memory-region = <&pil_adsp_mem>;
+
+ power-domains = <&rpmhpd SC8280XP_LCX>,
+ <&rpmhpd SC8280XP_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
index 20df83a96ef3..a3c74871457f 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
@@ -81,7 +81,11 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Phandle reference to a syscon representing TCSR followed by the
- three offsets within syscon for q6, modem and nc halt registers.
+ offset within syscon for q6 halt register.
+ items:
+ - items:
+ - description: phandle to TCSR syscon region
+ - description: offset to the Q6 halt register
qcom,smem-states:
$ref: /schemas/types.yaml#/definitions/phandle-array
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
new file mode 100644
index 000000000000..5d463272165f
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sdx55-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDX55 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SDX55 SoC Peripheral Authentication Service loads and boots firmware
+ on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sdx55-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ interrupts:
+ minItems: 6
+
+ interrupt-names:
+ minItems: 6
+
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@4080000 {
+ compatible = "qcom,sdx55-mpss-pas";
+ reg = <0x04080000 0x4040>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 250 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ memory-region = <&mpss_adsp_mem>;
+
+ power-domains = <&rpmhpd SDX55_CX>, <&rpmhpd SDX55_MSS>;
+ power-domain-names = "cx", "mss";
+
+ qcom,smem-states = <&modem_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 114 IRQ_TYPE_EDGE_RISING>;
+ label = "mpss";
+ mboxes = <&apcs 15>;
+ qcom,remote-pid = <1>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
new file mode 100644
index 000000000000..eeb6a8aafeb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm6115-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6115 Peripheral Authentication Service
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ Qualcomm SM6115 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,sm6115-adsp-pas
+ - qcom,sm6115-cdsp-pas
+ - qcom,sm6115-mpss-pas
+
+ - items:
+ - const: qcom,qcm2290-adsp-pas
+ - const: qcom,sm6115-adsp-pas
+
+ - items:
+ - const: qcom,qcm2290-mpss-pas
+ - const: qcom,sm6115-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ smd-edge: false
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6115-adsp-pas
+ - qcom,sm6115-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6115-cdsp-pas
+ - qcom,sm6115-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ power-domain-names:
+ items:
+ - const: cx
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm6115-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LPI CX power domain
+ - description: LPI MX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@ab00000 {
+ compatible = "qcom,sm6115-adsp-pas";
+ reg = <0x0ab00000 0x100>;
+
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sm6115/adsp.mbn";
+
+ interrupts-extended = <&intc GIC_SPI 282 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&pil_adsp_mem>;
+
+ power-domains = <&rpmpd SM6115_VDD_LPI_CX>,
+ <&rpmpd SM6115_VDD_LPI_MX>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>;
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ mboxes = <&apcs_glb 8>;
+
+ /* ... */
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
new file mode 100644
index 000000000000..c1a3cc308bdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6350-pas.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm6350-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6350 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM6350 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6350-adsp-pas
+ - qcom,sm6350-cdsp-pas
+ - qcom,sm6350-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ smd-edge: false
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-adsp-pas
+ - qcom,sm6350-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6350-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@3000000 {
+ compatible = "qcom,sm6350-adsp-pas";
+ reg = <0x03000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_LEVEL_HIGH>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&pil_adsp_mem>;
+
+ power-domains = <&rpmhpd SM6350_LCX>,
+ <&rpmhpd SM6350_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6375-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6375-pas.yaml
new file mode 100644
index 000000000000..7286b2baa19f
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6375-pas.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm6375-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM6375 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM6375 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm6375-adsp-pas
+ - qcom,sm6375-cdsp-pas
+ - qcom,sm6375-mpss-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+ smd-edge: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6375-adsp-pas
+ - qcom,sm6375-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6375-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6375-cdsp-pas
+ - qcom,sm6375-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ power-domain-names:
+ items:
+ - const: cx
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc_adsp: remoteproc@a400000 {
+ compatible = "qcom,sm6375-adsp-pas";
+ reg = <0x0a400000 0x100>;
+
+ interrupts-extended = <&intc GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "xo";
+
+ power-domains = <&rpmpd SM6375_VDD_LPI_CX>,
+ <&rpmpd SM6375_VDD_LPI_MX>;
+ power-domain-names = "lcx", "lmx";
+
+ memory-region = <&pil_adsp_mem>;
+
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
new file mode 100644
index 000000000000..a8cddf7e2fe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm8150-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8150/SM8250 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM8150/SM8250 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcs615-adsp-pas
+ - const: qcom,sm8150-adsp-pas
+ - items:
+ - enum:
+ - qcom,qcs615-cdsp-pas
+ - const: qcom,sm8150-cdsp-pas
+ - enum:
+ - qcom,sc8180x-adsp-pas
+ - qcom,sc8180x-cdsp-pas
+ - qcom,sc8180x-slpi-pas
+ - qcom,sm8150-adsp-pas
+ - qcom,sm8150-cdsp-pas
+ - qcom,sm8150-mpss-pas
+ - qcom,sm8150-slpi-pas
+ - qcom,sm8250-adsp-pas
+ - qcom,sm8250-cdsp-pas
+ - qcom,sm8250-slpi-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ smd-edge: false
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8180x-adsp-pas
+ - qcom,sc8180x-cdsp-pas
+ - qcom,sc8180x-slpi-pas
+ - qcom,sm8150-adsp-pas
+ - qcom,sm8150-cdsp-pas
+ - qcom,sm8150-slpi-pas
+ - qcom,sm8250-adsp-pas
+ - qcom,sm8250-cdsp-pas
+ - qcom,sm8250-slpi-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8180x-adsp-pas
+ - qcom,sc8180x-cdsp-pas
+ - qcom,sm8150-adsp-pas
+ - qcom,sm8150-cdsp-pas
+ - qcom,sm8250-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ power-domain-names:
+ items:
+ - const: cx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-mpss-pas
+ - qcom,sm8150-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8180x-slpi-pas
+ - qcom,sm8150-slpi-pas
+ - qcom,sm8250-adsp-pas
+ - qcom,sm8250-slpi-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ remoteproc@17300000 {
+ compatible = "qcom,sm8150-adsp-pas";
+ reg = <0x17300000 0x4040>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sm8150/adsp.mbn";
+
+ interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_mem>;
+
+ power-domains = <&rpmhpd SM8150_CX>;
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>;
+ label = "lpass";
+ qcom,remote-pid = <2>;
+ mboxes = <&apss_shared 8>;
+
+ /* ... */
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
new file mode 100644
index 000000000000..6d09823153fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8350-pas.yaml
@@ -0,0 +1,192 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm8350-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8350/SM8450 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM8350/SM8450 SoC Peripheral Authentication Service loads and boots
+ firmware on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,sar2130p-adsp-pas
+ - qcom,sm8350-adsp-pas
+ - qcom,sm8350-cdsp-pas
+ - qcom,sm8350-slpi-pas
+ - qcom,sm8350-mpss-pas
+ - qcom,sm8450-adsp-pas
+ - qcom,sm8450-cdsp-pas
+ - qcom,sm8450-mpss-pas
+ - qcom,sm8450-slpi-pas
+ - items:
+ - const: qcom,sc8280xp-slpi-pas
+ - const: qcom,sm8350-slpi-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ memory-region:
+ maxItems: 1
+ description: Reference to the reserved-memory for the Hexagon core
+
+ firmware-name:
+ maxItems: 1
+ description: Firmware name for the Hexagon core
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-adsp-pas
+ - qcom,sm8350-adsp-pas
+ - qcom,sm8350-cdsp-pas
+ - qcom,sm8350-slpi-pas
+ - qcom,sm8450-adsp-pas
+ - qcom,sm8450-cdsp-pas
+ - qcom,sm8450-slpi-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ else:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8350-mpss-pas
+ - qcom,sm8450-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sar2130p-adsp-pas
+ - qcom,sm8350-adsp-pas
+ - qcom,sm8350-slpi-pas
+ - qcom,sm8450-adsp-pas
+ - qcom,sm8450-slpi-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8350-cdsp-pas
+ - qcom,sm8450-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MXC power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mxc
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ remoteproc@30000000 {
+ compatible = "qcom,sm8450-adsp-pas";
+ reg = <0x030000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ firmware-name = "qcom/sm8450/adsp.mbn";
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_mem>;
+
+ power-domains = <&rpmhpd RPMHPD_LCX>,
+ <&rpmhpd RPMHPD_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
new file mode 100644
index 000000000000..2dd479cf4821
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
@@ -0,0 +1,289 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,sm8550-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 Peripheral Authentication Service
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+description:
+ Qualcomm SM8550 SoC Peripheral Authentication Service loads and boots firmware
+ on the Qualcomm DSP Hexagon cores.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,sdx75-mpss-pas
+ - qcom,sm8550-adsp-pas
+ - qcom,sm8550-cdsp-pas
+ - qcom,sm8550-mpss-pas
+ - qcom,sm8650-adsp-pas
+ - qcom,sm8650-cdsp-pas
+ - qcom,sm8650-mpss-pas
+ - qcom,sm8750-mpss-pas
+ - qcom,x1e80100-adsp-pas
+ - qcom,x1e80100-cdsp-pas
+ - items:
+ - const: qcom,sm8750-adsp-pas
+ - const: qcom,sm8550-adsp-pas
+ - items:
+ - const: qcom,sm8750-cdsp-pas
+ - const: qcom,sm8650-cdsp-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM.
+
+ smd-edge: false
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - description: Firmware name of the Hexagon core
+ - description: Firmware name of the Hexagon Devicetree
+
+ memory-region:
+ minItems: 2
+ items:
+ - description: Memory region for main Firmware authentication
+ - description: Memory region for Devicetree Firmware authentication
+ - description: DSM Memory region
+ - description: DSM Memory region 2
+ - description: Memory region for Qlink Logging
+
+required:
+ - compatible
+ - reg
+ - memory-region
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8550-adsp-pas
+ - qcom,sm8550-cdsp-pas
+ - qcom,sm8650-adsp-pas
+ - qcom,x1e80100-adsp-pas
+ - qcom,x1e80100-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ memory-region:
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-adsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 6
+ interrupt-names:
+ maxItems: 6
+ memory-region:
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8650-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 5
+ interrupt-names:
+ maxItems: 5
+ memory-region:
+ minItems: 3
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8750-cdsp-pas
+ then:
+ properties:
+ interrupts:
+ maxItems: 6
+ interrupt-names:
+ maxItems: 6
+ memory-region:
+ minItems: 3
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8550-mpss-pas
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+ memory-region:
+ minItems: 3
+ maxItems: 3
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sdx75-mpss-pas
+ - qcom,sm8650-mpss-pas
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+ memory-region:
+ minItems: 5
+ maxItems: 5
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm8750-mpss-pas
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ interrupt-names:
+ minItems: 6
+ memory-region:
+ minItems: 4
+ maxItems: 4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-adsp-pas
+ - qcom,sm8650-adsp-pas
+ - qcom,sm8750-adsp-pas
+ - qcom,x1e80100-adsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: LCX power domain
+ - description: LMX power domain
+ power-domain-names:
+ items:
+ - const: lcx
+ - const: lmx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sdx75-mpss-pas
+ - qcom,sm8550-mpss-pas
+ - qcom,sm8650-mpss-pas
+ - qcom,sm8750-mpss-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MSS power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mss
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-cdsp-pas
+ - qcom,sm8650-cdsp-pas
+ - qcom,x1e80100-cdsp-pas
+ then:
+ properties:
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MXC power domain
+ - description: NSP power domain
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mxc
+ - const: nsp
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+
+ remoteproc@30000000 {
+ compatible = "qcom,sm8550-adsp-pas";
+ reg = <0x030000000 0x100>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_adsp_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ memory-region = <&adsp_mem>, <&dtb_adsp_mem>;
+
+ firmware-name = "qcom/sm8550/adsp.mbn",
+ "qcom/sm8550/adsp_dtb.mbn";
+
+ power-domains = <&rpmhpd_sm8550_lcx>,
+ <&rpmhpd_sm8550_lmx>;
+ power-domain-names = "lcx", "lmx";
+
+ qcom,qmp = <&aoss_qmp>;
+ qcom,smem-states = <&smp2p_adsp_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_LPASS IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml
index 06eebf791e32..63500b1a0f6f 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml
@@ -13,11 +13,29 @@ description:
Qualcomm SMD subnode represents a remote subsystem or a remote processor of
some sort - or in SMD language an "edge". The name of the edges are not
important.
+
+ In turn, subnodes of the "edges" represent devices tied to SMD channels on
+ that "edge". The names of the devices are not important. The properties of
+ these nodes are defined by the individual bindings for the SMD devices.
See also Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
properties:
$nodename:
- const: "smd-edge"
+ const: smd-edge
+
+ apr:
+ $ref: /schemas/soc/qcom/qcom,apr.yaml#
+ required:
+ - qcom,smd-channels
+ description:
+ Qualcomm APR/GPR (Asynchronous/Generic Packet Router)
+
+ fastrpc:
+ $ref: /schemas/misc/qcom,fastrpc.yaml#
+ required:
+ - qcom,smd-channels
+ description:
+ Qualcomm FastRPC
interrupts:
maxItems: 1
@@ -43,6 +61,7 @@ properties:
description:
Three entries specifying the outgoing ipc bit used for signaling the
remote processor.
+ deprecated: true
qcom,smd-edge:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -56,6 +75,20 @@ properties:
The identifier for the remote processor as known by the rest of the
system.
+ rpm-requests:
+ $ref: /schemas/soc/qcom/qcom,smd-rpm.yaml#
+ required:
+ - qcom,smd-channels
+ description:
+ Qualcomm Resource Power Manager (RPM) over SMD.
+
+ wcnss:
+ $ref: /schemas/soc/qcom/qcom,wcnss.yaml
+ required:
+ - qcom,smd-channels
+ description:
+ Qualcomm WCNSS for Bluetooth, WiFi and FM radio.
+
required:
- interrupts
- qcom,smd-edge
@@ -66,7 +99,7 @@ oneOf:
- required:
- qcom,ipc
-additionalProperties: true
+additionalProperties: false
examples:
- |
@@ -79,7 +112,7 @@ examples:
smd-edge {
interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>;
- qcom,ipc = <&apcs 8 8>;
+ mboxes = <&apcs 8>;
qcom,smd-edge = <1>;
};
};
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
deleted file mode 100644
index ac423f4c3f1b..000000000000
--- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
+++ /dev/null
@@ -1,177 +0,0 @@
-Qualcomm WCNSS Peripheral Image Loader
-
-This document defines the binding for a component that loads and boots firmware
-on the Qualcomm WCNSS core.
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,riva-pil",
- "qcom,pronto-v1-pil",
- "qcom,pronto-v2-pil"
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: must specify the base address and size of the CCU, DXE and
- PMU register blocks
-
-- reg-names:
- Usage: required
- Value type: <stringlist>
- Definition: must be "ccu", "dxe", "pmu"
-
-- interrupts-extended:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: must list the watchdog and fatal IRQs and may specify the
- ready, handover and stop-ack IRQs
-
-- interrupt-names:
- Usage: required
- Value type: <stringlist>
- Definition: should be "wdog", "fatal", optionally followed by "ready",
- "handover", "stop-ack"
-
-- firmware-name:
- Usage: optional
- Value type: <string>
- Definition: must list the relative firmware image path for the
- WCNSS core. Defaults to "wcnss.mdt".
-
-- vddmx-supply: (deprecated for qcom,pronto-v1/2-pil)
-- vddcx-supply: (deprecated for qcom,pronto-v1/2-pil)
-- vddpx-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the WCNSS core
-
-- power-domains:
- Usage: required (for qcom,pronto-v1/2-pil)
- Value type: <phandle>
- Definition: reference to the power domains to be held on behalf of the
- booting of the WCNSS core
-
-- power-domain-names:
- Usage: required (for qcom,pronto-v1/2-pil)
- Value type: <stringlist>
- Definition: must be "cx", "mx"
-
-- qcom,smem-states:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: reference to the SMEM state used to indicate to WCNSS that
- it should shut down
-
-- qcom,smem-state-names:
- Usage: optional
- Value type: <stringlist>
- Definition: should be "stop"
-
-- memory-region:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to reserved-memory node for the remote processor
- see ../reserved-memory/reserved-memory.txt
-
-= SUBNODES
-A required subnode of the WCNSS PIL is used to describe the attached rf module
-and its resource dependencies. It is described by the following properties:
-
-- compatible:
- Usage: required
- Value type: <string>
- Definition: must be one of:
- "qcom,wcn3620",
- "qcom,wcn3660",
- "qcom,wcn3660b",
- "qcom,wcn3680"
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the xo clock and optionally the rf clock
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: should be "xo", optionally followed by "rf"
-
-- vddxo-supply:
-- vddrfa-supply:
-- vddpa-supply:
-- vdddig-supply:
- Usage: required
- Value type: <phandle>
- Definition: reference to the regulators to be held on behalf of the
- booting of the WCNSS core
-
-
-The wcnss node can also have an subnode named "smd-edge" that describes the SMD
-edge, channels and devices related to the WCNSS.
-See ../soc/qcom/qcom,smd.yaml for details on how to describe the SMD edge.
-
-= EXAMPLE
-The following example describes the resources needed to boot control the WCNSS,
-with attached WCN3680, as it is commonly found on MSM8974 boards.
-
-pronto@fb204000 {
- compatible = "qcom,pronto-v2-pil";
- reg = <0xfb204000 0x2000>, <0xfb202000 0x1000>, <0xfb21b000 0x3000>;
- reg-names = "ccu", "dxe", "pmu";
-
- interrupts-extended = <&intc 0 149 1>,
- <&wcnss_smp2p_slave 0 0>,
- <&wcnss_smp2p_slave 1 0>,
- <&wcnss_smp2p_slave 2 0>,
- <&wcnss_smp2p_slave 3 0>;
- interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
-
- power-domains = <&rpmpd MSM8974_VDDCX>, <&rpmpd MSM8974_VDDMX>;
- power-domain-names = "cx", "mx";
-
- vddpx-supply = <&pm8941_s3>;
-
- qcom,smem-states = <&wcnss_smp2p_out 0>;
- qcom,smem-state-names = "stop";
-
- memory-region = <&wcnss_region>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&wcnss_pin_a>;
-
- iris {
- compatible = "qcom,wcn3680";
-
- clocks = <&rpmcc RPM_CXO_CLK_SRC>, <&rpmcc RPM_CXO_A2>;
- clock-names = "xo", "rf";
-
- vddxo-supply = <&pm8941_l6>;
- vddrfa-supply = <&pm8941_l11>;
- vddpa-supply = <&pm8941_l19>;
- vdddig-supply = <&pm8941_s3>;
- };
-
- smd-edge {
- interrupts = <0 142 1>;
-
- qcom,ipc = <&apcs 8 17>;
- qcom,smd-edge = <6>;
- qcom,remote-pid = <4>;
-
- label = "pronto";
-
- wcnss {
- compatible = "qcom,wcnss";
- qcom,smd-channels = "WCNSS_CTRL";
-
- qcom,mmio = <&pronto>;
-
- bt {
- compatible = "qcom,wcnss-bt";
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
new file mode 100644
index 000000000000..117fb4d0c4ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
@@ -0,0 +1,321 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,wcnss-pil.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WCNSS Peripheral Image Loader
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ This document defines the binding for a component that loads and boots
+ firmware on the Qualcomm WCNSS core.
+
+properties:
+ compatible:
+ description:
+ Append "qcom,pronto" if the device is actually pronto, and not riva
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pronto-v1-pil
+ - qcom,pronto-v2-pil
+ - qcom,pronto-v3-pil
+ - const: qcom,pronto
+ - const: qcom,riva-pil
+
+ reg:
+ maxItems: 3
+ description:
+ The base address and size of the CCU, DXE and PMU register blocks
+
+ reg-names:
+ items:
+ - const: ccu
+ - const: dxe
+ - const: pmu
+
+ interrupts:
+ minItems: 2
+ maxItems: 5
+
+ interrupt-names:
+ minItems: 2
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+
+ firmware-name:
+ maxItems: 1
+ description:
+ Relative firmware image path for the WCNSS core. Defaults to
+ "wcnss.mdt".
+
+ vddpx-supply:
+ description:
+ PX regulator to be held on behalf of the booting of the WCNSS core
+
+ vddmx-supply:
+ description:
+ MX regulator to be held on behalf of the booting of the WCNSS core.
+
+ vddcx-supply:
+ description:
+ CX regulator to be held on behalf of the booting of the WCNSS core.
+
+ power-domains:
+ minItems: 1
+ maxItems: 2
+
+ power-domain-names:
+ minItems: 1
+ items:
+ - const: cx
+ - const: mx
+
+ qcom,smem-states:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ States used by the AP to signal the WCNSS core that it should shutdown
+ items:
+ - description: Stop the modem
+
+ qcom,smem-state-names:
+ description: The names of the state bits used for SMP2P output
+ items:
+ - const: stop
+
+ memory-region:
+ maxItems: 1
+ description: reserved-memory for the WCNSS core
+
+ smd-edge:
+ $ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ description:
+ Qualcomm Shared Memory subnode which represents communication edge,
+ channels and devices related to the ADSP.
+
+ iris:
+ type: object
+ description:
+ The iris subnode of the WCNSS PIL is used to describe the attached RF module
+ and its resource dependencies.
+
+ properties:
+ compatible:
+ enum:
+ - qcom,wcn3620
+ - qcom,wcn3660
+ - qcom,wcn3660b
+ - qcom,wcn3680
+
+ clocks:
+ minItems: 1
+ items:
+ - description: XO clock
+ - description: RF clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: xo
+ - const: rf
+
+ vddxo-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ vddrfa-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ vddpa-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ vdddig-supply:
+ description:
+ Reference to the regulator to be held on behalf of the booting WCNSS
+ core
+
+ required:
+ - compatible
+ - clocks
+ - clock-names
+ - vddxo-supply
+ - vddrfa-supply
+ - vddpa-supply
+ - vdddig-supply
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - iris
+ - vddpx-supply
+ - memory-region
+ - smd-edge
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,riva-pil
+ then:
+ required:
+ - vddcx-supply
+ - vddmx-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pronto-v1-pil
+ - qcom,pronto-v2-pil
+ then:
+ # CX and MX must be present either as power domains or regulators
+ oneOf:
+ # Both CX and MX represented as power domains
+ - required:
+ - power-domains
+ - power-domain-names
+ properties:
+ power-domains:
+ minItems: 2
+ power-domain-names:
+ minItems: 2
+ vddmx-supply: false
+ vddcx-supply: false
+ # CX represented as power domain, MX as regulator
+ - required:
+ - power-domains
+ - power-domain-names
+ - vddmx-supply
+ properties:
+ power-domains:
+ maxItems: 1
+ power-domain-names:
+ maxItems: 1
+ vddcx-supply: false
+ # Both CX and MX represented as regulators
+ - required:
+ - vddmx-supply
+ - vddcx-supply
+ properties:
+ power-domains: false
+ power-domain-names: false
+ vddmx-supply:
+ deprecated: true
+ description: Deprecated for qcom,pronto-v1/2-pil
+ vddcx-supply:
+ deprecated: true
+ description: Deprecated for qcom,pronto-v1/2-pil
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pronto-v3-pil
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+ power-domain-names:
+ minItems: 2
+ vddmx-supply: false
+ vddcx-supply: false
+
+ required:
+ - power-domains
+ - power-domain-names
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ pronto@a21b000 {
+ compatible = "qcom,pronto-v2-pil", "qcom,pronto";
+ reg = <0x0a204000 0x2000>, <0x0a202000 0x1000>, <0x0a21b000 0x3000>;
+ reg-names = "ccu", "dxe", "pmu";
+
+ interrupts-extended = <&intc GIC_SPI 149 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+ power-domains = <&rpmpd MSM8916_VDDCX>, <&rpmpd MSM8916_VDDMX>;
+ power-domain-names = "cx", "mx";
+
+ vddpx-supply = <&pm8916_l7>;
+
+ qcom,smem-states = <&wcnss_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ memory-region = <&wcnss_region>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wcnss_pin_a>;
+
+ iris {
+ compatible = "qcom,wcn3620";
+ vddxo-supply = <&pm8916_l7>;
+ vddrfa-supply = <&pm8916_s3>;
+ vddpa-supply = <&pm8916_l9>;
+ vdddig-supply = <&pm8916_l5>;
+
+ clocks = <&rpmcc RPM_SMD_RF_CLK2>;
+ clock-names = "xo";
+ };
+
+ smd-edge {
+ interrupts = <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,ipc = <&apcs 8 17>;
+ qcom,smd-edge = <6>;
+ qcom,remote-pid = <4>;
+
+ label = "pronto";
+
+ wcnss_ctrl: wcnss {
+ compatible = "qcom,wcnss";
+ qcom,smd-channels = "WCNSS_CTRL";
+
+ qcom,mmio = <&pronto>;
+
+ bluetooth {
+ compatible = "qcom,wcnss-bt";
+ };
+
+ wifi {
+ compatible = "qcom,wcnss-wlan";
+
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tx", "rx";
+
+ qcom,smem-states = <&apps_smsm 10>, <&apps_smsm 9>;
+ qcom,smem-state-names = "tx-enable", "tx-rings-empty";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
index a7d25fa920e5..5c280117dc93 100644
--- a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas R-Car remote processor controller bindings
+title: Renesas R-Car remote processor controller
maintainers:
- Julien Massot <julien.massot@iot.bzh>
@@ -31,7 +31,7 @@ properties:
remoteproc device. This is variable and describes the memories shared with
the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
vrings, ...).
- (see ../reserved-memory/reserved-memory.yaml)
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
required:
- compatible
diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
index da50f0e99fe2..843679c557e7 100644
--- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/remoteproc/st,stm32-rproc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/remoteproc/st,stm32-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 remote processor controller bindings
+title: STMicroelectronics STM32 remote processor controller
description:
This document defines the binding for the remoteproc component that loads and
@@ -25,11 +25,18 @@ properties:
maxItems: 3
resets:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: mcu_rst
+ - const: hold_boot
+ minItems: 1
st,syscfg-holdboot:
description: remote processor reset hold boot
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: Phandle of syscon block
@@ -37,9 +44,10 @@ properties:
- description: The field mask of the hold boot
st,syscfg-tz:
+ deprecated: true
description:
Reference to the system configuration which holds the RCC trust zone mode
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: Phandle of syscon block
@@ -72,9 +80,9 @@ properties:
ready for shutdown
- description: |
A channel (d) used by the local proc to notify the remote proc that it
- has to stop interprocessor communnication.
+ has to stop interprocessor communication.
Unidirectional channel:
- - from local to remote, where ACK from the remote means that communnication
+ - from local to remote, where ACK from the remote means that communication
as been stopped on the remote side.
minItems: 1
@@ -95,7 +103,7 @@ properties:
(see ../reserved-memory/reserved-memory.txt)
st,syscfg-pdds:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description: |
Reference to the system configuration which holds the remote
items:
@@ -105,7 +113,7 @@ properties:
- description: The field mask of the PDDS selection
st,syscfg-m4-state:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description: |
Reference to the tamp register which exposes the Cortex-M4 state.
items:
@@ -115,7 +123,7 @@ properties:
- description: The field mask of the Cortex-M4 state
st,syscfg-rsc-tbl:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
description: |
Reference to the tamp register which references the Cortex-M4
resource table address.
@@ -131,26 +139,56 @@ properties:
If defined, when remoteproc is probed, it loads the default firmware and
starts the remote processor.
+ firmware-name:
+ maxItems: 1
+ description: Default name of the remote processor firmware.
+
required:
- compatible
- reg
- resets
- - st,syscfg-holdboot
- - st,syscfg-tz
+
+allOf:
+ - if:
+ properties:
+ reset-names:
+ not:
+ contains:
+ const: hold_boot
+ then:
+ required:
+ - st,syscfg-holdboot
+ else:
+ properties:
+ st,syscfg-holdboot: false
additionalProperties: false
examples:
- |
#include <dt-bindings/reset/stm32mp1-resets.h>
- m4_rproc: m4@10000000 {
+ m4@10000000 {
compatible = "st,stm32mp1-m4";
reg = <0x10000000 0x40000>,
<0x30000000 0x40000>,
<0x38000000 0x10000>;
resets = <&rcc MCU_R>;
+ reset-names = "mcu_rst";
+ /* Hold boot managed using system config*/
st,syscfg-holdboot = <&rcc 0x10C 0x1>;
- st,syscfg-tz = <&rcc 0x000 0x1>;
+ st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
+ st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
+ };
+ - |
+ #include <dt-bindings/reset/stm32mp1-resets.h>
+ m4@10000000 {
+ compatible = "st,stm32mp1-m4";
+ reg = <0x10000000 0x40000>,
+ <0x30000000 0x40000>,
+ <0x38000000 0x10000>;
+ /* Hold boot managed using SCMI reset controller */
+ resets = <&scmi MCU_R>, <&scmi MCU_HOLD_BOOT_R>;
+ reset-names = "mcu_rst", "hold_boot";
st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
};
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt
index 25f8658e216f..48a49c516b62 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt
+++ b/Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt
@@ -1,9 +1,6 @@
TI Davinci DSP devices
=======================
-Binding status: Unstable - Subject to changes for DT representation of clocks
- and resets
-
The TI Davinci family of SoCs usually contains a TI DSP Core sub-system that
is used to offload some of the processor-intensive tasks or algorithms, for
achieving various system level goals.
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index cedbc5efdc56..b51bb863d759 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
@@ -25,16 +25,15 @@ description: |
host processor (Arm CorePac) to perform the device management of the remote
processor and to communicate with the remote processor.
-allOf:
- - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
-
properties:
compatible:
enum:
+ - ti,am62a-c7xv-dsp
- ti,j721e-c66-dsp
- ti,j721e-c71-dsp
- ti,j721s2-c71-dsp
description:
+ Use "ti,am62a-c7xv-dsp" for AM62A Deep learning DSPs on K3 AM62A SoCs
Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs
Use "ti,j721s2-c71-dsp" for C71x DSPs on K3 J721S2 SoCs
@@ -87,40 +86,57 @@ properties:
should be defined as per the generic bindings in,
Documentation/devicetree/bindings/sram/sram.yaml
-if:
- properties:
- compatible:
- enum:
- - ti,j721e-c66-dsp
-then:
- properties:
- reg:
- items:
- - description: Address and Size of the L2 SRAM internal memory region
- - description: Address and Size of the L1 PRAM internal memory region
- - description: Address and Size of the L1 DRAM internal memory region
- reg-names:
- items:
- - const: l2sram
- - const: l1pram
- - const: l1dram
-else:
- if:
- properties:
- compatible:
- enum:
- - ti,j721e-c71-dsp
- - ti,j721s2-c71-dsp
- then:
- properties:
- reg:
- items:
- - description: Address and Size of the L2 SRAM internal memory region
- - description: Address and Size of the L1 DRAM internal memory region
- reg-names:
- items:
- - const: l2sram
- - const: l1dram
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,j721e-c66-dsp
+ then:
+ properties:
+ reg:
+ items:
+ - description: Address and Size of the L2 SRAM internal memory region
+ - description: Address and Size of the L1 PRAM internal memory region
+ - description: Address and Size of the L1 DRAM internal memory region
+ reg-names:
+ items:
+ - const: l2sram
+ - const: l1pram
+ - const: l1dram
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,j721e-c71-dsp
+ - ti,j721s2-c71-dsp
+ then:
+ properties:
+ reg:
+ items:
+ - description: Address and Size of the L2 SRAM internal memory region
+ - description: Address and Size of the L1 DRAM internal memory region
+ reg-names:
+ items:
+ - const: l2sram
+ - const: l1dram
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,am62a-c7xv-dsp
+ then:
+ properties:
+ reg:
+ items:
+ - description: Address and Size of the L2 SRAM internal memory region
+ reg-names:
+ items:
+ - const: l2sram
+
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
required:
- compatible
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 000000000000..2bd0752b6ba9
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+ - Hari Nagalla <hnagalla@ti.com>
+ - Mathieu Poirier <mathieu.poirier@linaro.org>
+
+description: |
+ Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+ family with a M4F core. Typically safety oriented applications may use
+ the M4F core in isolation without an IPC. Where as some industrial and
+ home automation applications, may use the M4F core as a remote processor
+ with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,am64-m4fss
+
+ power-domains:
+ maxItems: 1
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ reg:
+ items:
+ - description: IRAM internal memory region
+ - description: DRAM internal memory region
+
+ reg-names:
+ items:
+ - const: iram
+ - const: dram
+
+ resets:
+ maxItems: 1
+
+ firmware-name:
+ maxItems: 1
+ description: Name of firmware to load for the M4F core
+
+ mboxes:
+ description:
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image.
+ maxItems: 1
+
+ memory-region:
+ description:
+ phandle to the reserved memory nodes to be associated with the
+ remoteproc device. Optional memory regions available for firmware
+ specific purposes.
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
+ maxItems: 8
+ items:
+ - description: regions used for DMA allocations like vrings, vring buffers
+ and memory dedicated to firmware's specific purposes.
+ additionalItems: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cb00000 0x00 0x100000>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@9cc00000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cc00000 0x00 0xe00000>;
+ no-map;
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mailbox0_cluster0: mailbox-0 {
+ #mbox-cells = <1>;
+ };
+
+ remoteproc@5000000 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x5000000 0x00 0x30000>,
+ <0x00 0x5040000 0x00 0x10000>;
+ reg-names = "iram", "dram";
+ resets = <&k3_reset 9 1>;
+ firmware-name = "am62-mcu-m4f0_0-fw";
+ mboxes = <&mailbox0_cluster0>, <&mbox_m4_0>;
+ memory-region = <&mcu_m4fss_dma_memory_region>,
+ <&mcu_m4fss_memory_region>;
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
index fb9605f0655b..a927551356e6 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,k3-r5f-rproc.yaml#
@@ -21,6 +21,9 @@ description: |
called "Single-CPU" mode, where only Core0 is used, but with ability to use
Core1's TCMs as well.
+ AM62 SoC family support a single R5F core only which runs Device Manager
+ firmware and can also be used as a remote processor with IPC communication.
+
Each Dual-Core R5F sub-system is represented as a single DTS node
representing the cluster, with a pair of child DT nodes representing
the individual R5F cores. Each node has a number of required or optional
@@ -34,10 +37,11 @@ properties:
compatible:
enum:
+ - ti,am62-r5fss
+ - ti,am64-r5fss
- ti,am654-r5fss
- - ti,j721e-r5fss
- ti,j7200-r5fss
- - ti,am64-r5fss
+ - ti,j721e-r5fss
- ti,j721s2-r5fss
power-domains:
@@ -64,10 +68,16 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Configuration Mode for the Dual R5F cores within the R5F cluster.
- Should be either a value of 1 (LockStep mode) or 0 (Split mode) on
+ For most SoCs (AM65x, J721E, J7200, J721s2),
+ It should be either a value of 1 (LockStep mode) or 0 (Split mode) on
most SoCs (AM65x, J721E, J7200, J721s2), default is LockStep mode if
- omitted; and should be either a value of 0 (Split mode) or 2
- (Single-CPU mode) on AM64x SoCs, default is Split mode if omitted.
+ omitted.
+ For AM64x SoCs,
+ It should be either a value of 0 (Split mode) or 2 (Single-CPU mode) and
+ default is Split mode if omitted.
+ For AM62x SoCs,
+ It should be set as 3 (Single-Core mode) which is also the default if
+ omitted.
# R5F Processor Child Nodes:
# ==========================
@@ -80,7 +90,9 @@ patternProperties:
node representing a TI instantiation of the Arm Cortex R5F core. There
are some specific integration differences for the IP like the usage of
a Region Address Translator (RAT) for translating the larger SoC bus
- addresses into a 32-bit address space for the processor.
+ addresses into a 32-bit address space for the processor. For AM62x,
+ the R5F Sub-System device node should only define one R5F child node
+ as it has only one core available.
Each R5F core has an associated 64 KB of Tightly-Coupled Memory (TCM)
internal memories split between two banks - TCMA and TCMB (further
@@ -89,7 +101,7 @@ patternProperties:
caches. Each of the TCMs can be enabled or disabled independently and
either of them can be configured to appear at that R5F's address 0x0.
- The cores do not use an MMU, but has a Region Address Translater
+ The cores do not use an MMU, but has a Region Address Translator
(RAT) module that is accessible only from the R5Fs for providing
translations between 32-bit CPU addresses into larger system bus
addresses. Cache and memory access settings are provided through a
@@ -100,10 +112,11 @@ patternProperties:
properties:
compatible:
enum:
+ - ti,am62-r5f
+ - ti,am64-r5f
- ti,am654-r5f
- - ti,j721e-r5f
- ti,j7200-r5f
- - ti,am64-r5f
+ - ti,j721e-r5f
- ti,j721s2-r5f
reg:
@@ -153,7 +166,6 @@ patternProperties:
- description: region reserved for firmware image sections
additionalItems: true
-
# Optional properties:
# --------------------
# The following properties are optional properties for each of the R5F cores:
@@ -208,19 +220,39 @@ patternProperties:
unevaluatedProperties: false
-if:
- properties:
- compatible:
- enum:
- - ti,am64-r5fss
-then:
- properties:
- ti,cluster-mode:
- enum: [0, 2]
-else:
- properties:
- ti,cluster-mode:
- enum: [0, 1]
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,am64-r5fss
+ then:
+ properties:
+ ti,cluster-mode:
+ enum: [0, 2]
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,am654-r5fss
+ - ti,j7200-r5fss
+ - ti,j721e-r5fss
+ - ti,j721s2-r5fss
+ then:
+ properties:
+ ti,cluster-mode:
+ enum: [0, 1]
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - ti,am62-r5fss
+ then:
+ properties:
+ ti,cluster-mode:
+ enum: [3]
required:
- compatible
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
index 1fdc2741c36e..94eb2033e79c 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
new file mode 100644
index 000000000000..2811334515d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI PRU Consumer Common Properties
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+
+description: |
+ A PRU application/consumer/user node typically uses one or more PRU device
+ nodes to implement a PRU application/functionality. Each application/client
+ node would need a reference to at least a PRU node, and optionally define
+ some properties needed for hardware/firmware configuration. The below
+ properties are a list of common properties supported by the PRU remoteproc
+ infrastructure.
+
+ The application nodes shall define their own bindings like regular platform
+ devices, so below are in addition to each node's bindings.
+
+properties:
+ ti,prus:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: phandles to the PRU, RTU or Tx_PRU nodes used
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ minItems: 1
+ maxItems: 6
+ description: |
+ firmwares for the PRU cores, the default firmware for the core from
+ the PRU node will be used if not provided. The firmware names should
+ correspond to the PRU cores listed in the 'ti,prus' property
+
+ ti,pruss-gp-mux-sel:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 6
+ items:
+ enum: [0, 1, 2, 3, 4]
+ description: |
+ array of values for the GP_MUX_SEL under PRUSS_GPCFG register for a PRU.
+ This selects the internal muxing scheme for the PRU instance. Values
+ should correspond to the PRU cores listed in the 'ti,prus' property. The
+ GP_MUX_SEL setting is a per-slice setting (one setting for PRU0, RTU0,
+ and Tx_PRU0 on K3 SoCs). Use the same value for all cores within the
+ same slice in the associative array. If the array size is smaller than
+ the size of 'ti,prus' property, the default out-of-reset value (0) for the
+ PRU core is used.
+
+required:
+ - ti,prus
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
index cd55d80137f7..faf16cf14085 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
@@ -1,4 +1,4 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/remoteproc/ti,pru-rproc.yaml#
@@ -66,6 +66,17 @@ properties:
Should contain the name of the default firmware image
file located on the firmware search path.
+ interrupts:
+ maxItems: 1
+ description:
+ Interrupt specifiers enable the virtio/rpmsg communication between MPU
+ and the PRU/RTU cores. For the values of the interrupt cells please refer
+ to interrupt-controller/ti,pruss-intc.yaml schema.
+
+ interrupt-names:
+ items:
+ - const: vring
+
if:
properties:
compatible:
@@ -171,6 +182,9 @@ examples:
<0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am65x-pru0_0-fw";
+ interrupt-parent = <&icssg0_intc>;
+ interrupts = <16 2 2>;
+ interrupt-names = "vring";
};
rtu0_0: rtu@4000 {
@@ -180,6 +194,9 @@ examples:
<0x23400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am65x-rtu0_0-fw";
+ interrupt-parent = <&icssg0_intc>;
+ interrupts = <20 4 4>;
+ interrupt-names = "vring";
};
tx_pru0_0: txpru@a000 {
@@ -198,6 +215,9 @@ examples:
<0x24400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am65x-pru0_1-fw";
+ interrupt-parent = <&icssg0_intc>;
+ interrupts = <18 3 3>;
+ interrupt-names = "vring";
};
rtu0_1: rtu@6000 {
@@ -207,6 +227,9 @@ examples:
<0x23c00 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am65x-rtu0_1-fw";
+ interrupt-parent = <&icssg0_intc>;
+ interrupts = <22 5 5>;
+ interrupt-names = "vring";
};
tx_pru0_1: txpru@c000 {
diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
new file mode 100644
index 000000000000..ee63c03949c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
@@ -0,0 +1,371 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/xlnx,zynqmp-r5fss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx R5F processor subsystem
+
+maintainers:
+ - Ben Levinsky <ben.levinsky@amd.com>
+ - Tanmay Shah <tanmay.shah@amd.com>
+
+description: |
+ The Xilinx platforms include a pair of Cortex-R5F processors (RPU) for
+ real-time processing based on the Cortex-R5F processor core from ARM.
+ The Cortex-R5F processor implements the Arm v7-R architecture and includes a
+ floating-point unit that implements the Arm VFPv3 instruction set.
+
+properties:
+ compatible:
+ enum:
+ - xlnx,zynqmp-r5fss
+ - xlnx,versal-r5fss
+ - xlnx,versal-net-r52fss
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges:
+ description: |
+ Standard ranges definition providing address translations for
+ local R5F TCM address spaces to bus addresses.
+
+ xlnx,cluster-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ default: 1
+ description: |
+ The RPU MPCore can operate in split mode (Dual-processor performance), Safety
+ lock-step mode(Both RPU cores execute the same code in lock-step,
+ clock-for-clock) or Single CPU mode (RPU core 0 is held in reset while
+ core 1 runs normally). The processor does not support dynamic configuration.
+ Switching between modes is only permitted immediately after a processor reset.
+ If set to 1 then lockstep mode and if 0 then split mode.
+ If set to 2 then single CPU mode. When not defined, default will be lockstep mode.
+ In summary,
+ 0: split mode
+ 1: lockstep mode (default)
+ 2: single cpu mode
+
+ xlnx,tcm-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: |
+ Configure RPU TCM
+ 0: split mode
+ 1: lockstep mode
+
+patternProperties:
+ "^r(.*)@[0-9a-f]+$":
+ type: object
+ additionalProperties: false
+ description: |
+ The RPU is located in the Low Power Domain of the Processor Subsystem.
+ Each processor includes separate L1 instruction and data caches and
+ tightly coupled memories (TCM). System memory is cacheable, but the TCM
+ memory space is non-cacheable.
+
+ Each RPU contains one 64KB memory and two 32KB memories that
+ are accessed via the TCM A and B port interfaces, for a total of 128KB
+ per processor. In lock-step mode, the processor has access to 256KB of
+ TCM memory.
+
+ properties:
+ compatible:
+ enum:
+ - xlnx,zynqmp-r5f
+ - xlnx,versal-r5f
+ - xlnx,versal-net-r52f
+
+ reg:
+ minItems: 1
+ maxItems: 4
+
+ reg-names:
+ minItems: 1
+ maxItems: 4
+
+ power-domains:
+ minItems: 2
+ maxItems: 5
+
+ mboxes:
+ minItems: 1
+ items:
+ - description: mailbox channel to send data to RPU
+ - description: mailbox channel to receive data from RPU
+
+ mbox-names:
+ minItems: 1
+ items:
+ - const: tx
+ - const: rx
+
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 8
+ items:
+ maxItems: 1
+ description: |
+ phandles to one or more reserved on-chip SRAM regions. Other than TCM,
+ the RPU can execute instructions and access data from the OCM memory,
+ the main DDR memory, and other system memories.
+
+ The regions should be defined as child nodes of the respective SRAM
+ node, and should be defined as per the generic bindings in
+ Documentation/devicetree/bindings/sram/sram.yaml
+
+ memory-region:
+ description: |
+ List of phandles to the reserved memory regions associated with the
+ remoteproc device. This is variable and describes the memories shared with
+ the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
+ vrings, ...). This reserved memory region will be allocated in DDR memory.
+ minItems: 1
+ maxItems: 8
+ items:
+ - description: region used for RPU firmware image section
+ - description: vdev buffer
+ - description: vring0
+ - description: vring1
+ additionalItems: true
+
+ required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,versal-net-r52fss
+ then:
+ properties:
+ xlnx,tcm-mode: false
+
+ patternProperties:
+ "^r52f@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: ATCM internal memory
+ - description: BTCM internal memory
+ - description: CTCM internal memory
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: atcm0
+ - const: btcm0
+ - const: ctcm0
+
+ power-domains:
+ minItems: 2
+ items:
+ - description: RPU core power domain
+ - description: ATCM power domain
+ - description: BTCM power domain
+ - description: CTCM power domain
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,zynqmp-r5fss
+ - xlnx,versal-r5fss
+ then:
+ if:
+ properties:
+ xlnx,cluster-mode:
+ enum: [1, 2]
+ then:
+ properties:
+ xlnx,tcm-mode:
+ enum: [1]
+
+ patternProperties:
+ "^r5f@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: ATCM internal memory
+ - description: BTCM internal memory
+ - description: extra ATCM memory in lockstep mode
+ - description: extra BTCM memory in lockstep mode
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: atcm0
+ - const: btcm0
+ - const: atcm1
+ - const: btcm1
+
+ power-domains:
+ minItems: 2
+ items:
+ - description: RPU core power domain
+ - description: ATCM power domain
+ - description: BTCM power domain
+ - description: second ATCM power domain
+ - description: second BTCM power domain
+
+ required:
+ - xlnx,tcm-mode
+
+ else:
+ properties:
+ xlnx,tcm-mode:
+ enum: [0]
+
+ patternProperties:
+ "^r5f@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ minItems: 1
+ items:
+ - description: ATCM internal memory
+ - description: BTCM internal memory
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: atcm0
+ - const: btcm0
+
+ power-domains:
+ minItems: 2
+ items:
+ - description: RPU core power domain
+ - description: ATCM power domain
+ - description: BTCM power domain
+
+ required:
+ - xlnx,tcm-mode
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+
+ // Split mode configuration
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ remoteproc@ffe00000 {
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+ xlnx,tcm-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+ <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+ <0x1 0x0 0x0 0xffe90000 0x0 0x10000>,
+ <0x1 0x20000 0x0 0xffeb0000 0x0 0x10000>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x10000>, <0x0 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_0>,
+ <&zynqmp_firmware PD_R5_0_ATCM>,
+ <&zynqmp_firmware PD_R5_0_BTCM>;
+ memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>,
+ <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
+ mbox-names = "tx", "rx";
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_1>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+ <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+ mbox-names = "tx", "rx";
+ };
+ };
+ };
+
+ - |
+ //Lockstep configuration
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ remoteproc@ffe00000 {
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <1>;
+ xlnx,tcm-mode = <1>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xffe00000 0x0 0x10000>,
+ <0x0 0x20000 0x0 0xffe20000 0x0 0x10000>,
+ <0x0 0x10000 0x0 0xffe10000 0x0 0x10000>,
+ <0x0 0x30000 0x0 0xffe30000 0x0 0x10000>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x10000>,
+ <0x0 0x20000 0x0 0x10000>,
+ <0x0 0x10000 0x0 0x10000>,
+ <0x0 0x30000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <&zynqmp_firmware PD_RPU_0>,
+ <&zynqmp_firmware PD_R5_0_ATCM>,
+ <&zynqmp_firmware PD_R5_0_BTCM>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>,
+ <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
+ mbox-names = "tx", "rx";
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x10000>, <0x1 0x20000 0x0 0x10000>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <&zynqmp_firmware PD_RPU_1>,
+ <&zynqmp_firmware PD_R5_1_ATCM>,
+ <&zynqmp_firmware PD_R5_1_BTCM>;
+ memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>,
+ <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
+ mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
+ mbox-names = "tx", "rx";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
index 257a0b51994a..c591ec37d7e8 100644
--- a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/reserved-memory/google,open-dice.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Open Profile for DICE Device Tree Bindings
+title: Open Profile for DICE
description: |
This binding represents a reserved memory region containing data
@@ -16,7 +16,7 @@ maintainers:
- David Brazdil <dbrazdil@google.com>
allOf:
- - $ref: "reserved-memory.yaml"
+ - $ref: reserved-memory.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
deleted file mode 100644
index 83dfe499a259..000000000000
--- a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
+++ /dev/null
@@ -1,40 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Reserved Memory Region Device Tree Binding
-
-maintainers:
- - devicetree-spec@vger.kernel.org
-
-description: |
- Regions in the /reserved-memory node may be referenced by other device
- nodes by adding a memory-region property to the device node.
-
-select: true
-
-properties:
- memory-region:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: >
- Phandle to a /reserved-memory child node assigned to the device.
-
- memory-region-names:
- $ref: /schemas/types.yaml#/definitions/string-array
- description: >
- A list of names, one for each corresponding entry in the
- memory-region property
-
-additionalProperties: true
-
-examples:
- - |
- fb0: video@12300000 {
- /* ... */
- reg = <0x12300000 0x1000>;
- memory-region = <&display_reserved>;
- };
-
-...
diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml
index 035a50fe3ee4..e2ace3df942a 100644
--- a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra210-emc-table.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NVIDIA Tegra210 EMC Frequency Table Device Tree Bindings
+title: NVIDIA Tegra210 EMC Frequency Table
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
@@ -14,7 +14,7 @@ description: On Tegra210, firmware passes a binary representation of the
EMC frequency table via a reserved memory region.
allOf:
- - $ref: "reserved-memory.yaml"
+ - $ref: reserved-memory.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
new file mode 100644
index 000000000000..4380f622f9a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tegra CPU-NS - BPMP IPC reserved memory
+
+maintainers:
+ - Peter De Schrijver <pdeschrijver@nvidia.com>
+
+description: |
+ Define a memory region used for communication between CPU-NS and BPMP.
+ Typically this node is created by the bootloader as the physical address
+ has to be known to both CPU-NS and BPMP for correct IPC operation.
+ The memory region is defined using a child node under /reserved-memory.
+ The sub-node is named shmem@<address>.
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+ const: nvidia,tegra264-bpmp-shmem
+
+ reg:
+ description: The physical address and size of the shared SDRAM region
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - no-map
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ shmem@f1be0000 {
+ compatible = "nvidia,tegra264-bpmp-shmem";
+ reg = <0x0 0xf1be0000 0x0 0x2000>;
+ no-map;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/reserved-memory/phram.yaml b/Documentation/devicetree/bindings/reserved-memory/phram.yaml
index 6c4db28015f1..65c7cacf9be4 100644
--- a/Documentation/devicetree/bindings/reserved-memory/phram.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/phram.yaml
@@ -17,8 +17,8 @@ maintainers:
- Vincent Whitchurch <vincent.whitchurch@axis.com>
allOf:
- - $ref: "reserved-memory.yaml"
- - $ref: "/schemas/mtd/mtd.yaml"
+ - $ref: reserved-memory.yaml
+ - $ref: /schemas/mtd/mtd.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml
index df1b5e0ed3f4..610f8ef37e8d 100644
--- a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reserved-memory/qcom,cmd-db.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reserved-memory/qcom,cmd-db.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Command DB
@@ -20,7 +20,7 @@ maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
allOf:
- - $ref: "reserved-memory.yaml"
+ - $ref: reserved-memory.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
index 2998f1c8f0db..46407e9c1d4f 100644
--- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reserved-memory/qcom,rmtfs-mem.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reserved-memory/qcom,rmtfs-mem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Remote File System Memory
@@ -15,7 +15,7 @@ maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
allOf:
- - $ref: "reserved-memory.yaml"
+ - $ref: reserved-memory.yaml
properties:
compatible:
@@ -26,10 +26,23 @@ properties:
description: >
identifier of the client to use this region for buffers
+ qcom,use-guard-pages:
+ type: boolean
+ description: >
+ Indicates that the firmware, or hardware, does not gracefully handle
+ memory protection of this region when placed adjacent to other protected
+ memory regions, and that padding around the used portion of the memory
+ region is necessary.
+
+ When this is set, the first and last page should be left unused, and the
+ effective size of the region will thereby shrink with two pages.
+
qcom,vmid:
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: >
- vmid of the remote processor, to set up memory protection
+ Array of vmids of the remote processors, to set up memory protection
+ minItems: 1
+ maxItems: 2
required:
- qcom,client-id
diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
index 0391871cf44d..45cc39ecc9f8 100644
--- a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reserved-memory/ramoops.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reserved-memory/ramoops.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ramoops oops/panic logger
@@ -27,7 +27,7 @@ maintainers:
- Kees Cook <keescook@chromium.org>
allOf:
- - $ref: "reserved-memory.yaml"
+ - $ref: reserved-memory.yaml
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index 1810701a8509..8ce72996d500 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -1 +1 @@
-This file has been moved to reserved-memory.yaml.
+This file has been moved to reserved-memory.yaml in the dtschema repository.
diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
deleted file mode 100644
index 7a0744052ff6..000000000000
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
+++ /dev/null
@@ -1,100 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: /reserved-memory Child Node Common Device Tree Bindings
-
-maintainers:
- - devicetree-spec@vger.kernel.org
-
-description: >
- Reserved memory is specified as a node under the /reserved-memory node. The
- operating system shall exclude reserved memory from normal usage one can
- create child nodes describing particular reserved (excluded from normal use)
- memory regions. Such memory regions are usually designed for the special
- usage by various device drivers.
-
- Each child of the reserved-memory node specifies one or more regions
- of reserved memory. Each child node may either use a 'reg' property to
- specify a specific range of reserved memory, or a 'size' property with
- optional constraints to request a dynamically allocated block of
- memory.
-
- Following the generic-names recommended practice, node names should
- reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
- Unit address (@<address>) should be appended to the name if the node
- is a static allocation.
-
-properties:
- reg: true
-
- size:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 2
- description: >
- Length based on parent's \#size-cells. Size in bytes of memory to
- reserve.
-
- alignment:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 2
- description: >
- Length based on parent's \#size-cells. Address boundary for
- alignment of allocation.
-
- alloc-ranges:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: >
- Address and Length pairs. Specifies regions of memory that are
- acceptable to allocate from.
-
- no-map:
- type: boolean
- description: >
- Indicates the operating system must not create a virtual mapping
- of the region as part of its standard mapping of system memory,
- nor permit speculative access to it under any circumstances other
- than under the control of the device driver using the region.
-
- reusable:
- type: boolean
- description: >
- The operating system can use the memory in this region with the
- limitation that the device driver(s) owning the region need to be
- able to reclaim it back. Typically that means that the operating
- system can use that region to store volatile or cached data that
- can be otherwise regenerated or migrated elsewhere.
-
-allOf:
- - if:
- required:
- - no-map
-
- then:
- not:
- required:
- - reusable
-
- - if:
- required:
- - reusable
-
- then:
- not:
- required:
- - no-map
-
-oneOf:
- - required:
- - reg
-
- - required:
- - size
-
-additionalProperties: true
-
-...
diff --git a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
deleted file mode 100644
index 618105f079be..000000000000
--- a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
+++ /dev/null
@@ -1,97 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/reserved-memory/shared-dma-pool.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: /reserved-memory DMA pool node bindings
-
-maintainers:
- - devicetree-spec@vger.kernel.org
-
-allOf:
- - $ref: "reserved-memory.yaml"
-
-properties:
- compatible:
- oneOf:
- - const: shared-dma-pool
- description: >
- This indicates a region of memory meant to be used as a shared
- pool of DMA buffers for a set of devices. It can be used by an
- operating system to instantiate the necessary pool management
- subsystem if necessary.
-
- - const: restricted-dma-pool
- description: >
- This indicates a region of memory meant to be used as a pool
- of restricted DMA buffers for a set of devices. The memory
- region would be the only region accessible to those devices.
- When using this, the no-map and reusable properties must not
- be set, so the operating system can create a virtual mapping
- that will be used for synchronization. The main purpose for
- restricted DMA is to mitigate the lack of DMA access control
- on systems without an IOMMU, which could result in the DMA
- accessing the system memory at unexpected times and/or
- unexpected addresses, possibly leading to data leakage or
- corruption. The feature on its own provides a basic level of
- protection against the DMA overwriting buffer contents at
- unexpected times. However, to protect against general data
- leakage and system memory corruption, the system needs to
- provide way to lock down the memory access, e.g., MPU. Note
- that since coherent allocation needs remapping, one must set
- up another device coherent pool by shared-dma-pool and use
- dma_alloc_from_dev_coherent instead for atomic coherent
- allocation.
-
- linux,cma-default:
- type: boolean
- description: >
- If this property is present, then Linux will use the region for
- the default pool of the contiguous memory allocator.
-
- linux,dma-default:
- type: boolean
- description: >
- If this property is present, then Linux will use the region for
- the default pool of the consistent DMA allocator.
-
-if:
- properties:
- compatible:
- contains:
- const: restricted-dma-pool
-then:
- properties:
- no-map: false
- reusable: false
-
-unevaluatedProperties: false
-
-examples:
- - |
- reserved-memory {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- /* global autoconfigured region for contiguous allocations */
- linux,cma {
- compatible = "shared-dma-pool";
- reusable;
- size = <0x4000000>;
- alignment = <0x2000>;
- linux,cma-default;
- };
-
- display_reserved: framebuffer@78000000 {
- reg = <0x78000000 0x800000>;
- };
-
- restricted_dma_reserved: restricted-dma-pool@50000000 {
- compatible = "restricted-dma-pool";
- reg = <0x50000000 0x4000000>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/reset/allwinner,sun6i-a31-clock-reset.yaml b/Documentation/devicetree/bindings/reset/allwinner,sun6i-a31-clock-reset.yaml
index 001c0d2a8c1f..2a248e511c18 100644
--- a/Documentation/devicetree/bindings/reset/allwinner,sun6i-a31-clock-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/allwinner,sun6i-a31-clock-reset.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/reset/allwinner,sun6i-a31-clock-reset.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 Peripheral Reset Controller Device Tree Bindings
+title: Allwinner A31 Peripheral Reset Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
index 4379cec6b35a..761c70cf9ddf 100644
--- a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
+++ b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Altera SOCFPGA Reset Manager
maintainers:
- - Dinh Nguyen <dinguyen@altera.com>
+ - Dinh Nguyen <dinguyen@kernel.org>
properties:
compatible:
@@ -32,9 +32,17 @@ properties:
required:
- compatible
- reg
- - altr,modrst-offset
- '#reset-cells'
+if:
+ properties:
+ compatible:
+ contains:
+ const: altr,stratix10-rst-mgr
+then:
+ properties:
+ altr,modrst-offset: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
index 704a502adc5d..bc1d284785e1 100644
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/amlogic,meson-axg-audio-arb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/amlogic,meson-axg-audio-arb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic audio memory arbiter controller
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
index 98db2aa74dc8..150e95c0d9be 100644
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson SoC Reset Controller
@@ -12,12 +12,20 @@ maintainers:
properties:
compatible:
- enum:
- - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
- - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
- - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
- - amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs
- - amlogic,meson-s4-reset # Reset Controller on S4 and compatible SoCs
+ oneOf:
+ - enum:
+ - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
+ - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
+ - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
+ - amlogic,meson-a1-reset # Reset Controller on A1 and compatible SoCs
+ - amlogic,meson-s4-reset # Reset Controller on S4 and compatible SoCs
+ - amlogic,c3-reset # Reset Controller on C3 and compatible SoCs
+ - amlogic,t7-reset
+ - items:
+ - enum:
+ - amlogic,a4-reset
+ - amlogic,a5-reset
+ - const: amlogic,meson-s4-reset
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml
index 98465d26949e..84c4801df8d9 100644
--- a/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml
@@ -24,8 +24,15 @@ properties:
- microchip,sam9x60-rstc
- microchip,sama7g5-rstc
- items:
+ - const: microchip,sama7d65-rstc
+ - const: microchip,sama7g5-rstc
+ - items:
- const: atmel,sama5d3-rstc
- const: atmel,at91sam9g45-rstc
+ - items:
+ - enum:
+ - microchip,sam9x7-rstc
+ - const: microchip,sam9x60-rstc
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
index f0aca744388c..1f40b654f6a2 100644
--- a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Manivannan Sadhasivam <mani@kernel.org>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/bitmain,bm1880-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/bitmain,bm1880-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Bitmain BM1880 SoC Reset Controller
diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml
index 560cf6522cb8..b8a320bb1776 100644
--- a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/brcm,bcm6345-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/brcm,bcm6345-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: BCM6345 reset controller
@@ -13,7 +13,9 @@ maintainers:
properties:
compatible:
- const: brcm,bcm6345-reset
+ enum:
+ - brcm,bcm6345-reset
+ - brcm,bcm63xx-ephy-ctrl
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml b/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml
index dfce6738b033..34cfc642d808 100644
--- a/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml
+++ b/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 Broadcom
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/brcm,bcm7216-pcie-sata-rescal.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/brcm,bcm7216-pcie-sata-rescal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: BCM7216 RESCAL reset controller
diff --git a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml
index e00efa88a198..b115b86e2fe6 100644
--- a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/brcm,brcmstb-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/brcm,brcmstb-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom STB SW_INIT-style reset controller
diff --git a/Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml b/Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
index 53e4ede9c0bd..0c0135964b91 100644
--- a/Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
+++ b/Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/reset/canaan,k210-rst.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Canaan Kendryte K210 Reset Controller Device Tree Bindings
+title: Canaan Kendryte K210 Reset Controller
maintainers:
- - Damien Le Moal <damien.lemoal@wdc.com>
+ - Damien Le Moal <dlemoal@kernel.org>
description: |
Canaan Kendryte K210 reset controller driver which supports the SoC
diff --git a/Documentation/devicetree/bindings/reset/canaan,k230-rst.yaml b/Documentation/devicetree/bindings/reset/canaan,k230-rst.yaml
new file mode 100644
index 000000000000..d352d0e12d81
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/canaan,k230-rst.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/canaan,k230-rst.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan Kendryte K230 Reset Controller
+
+maintainers:
+ - Junhui Liu <junhui.liu@pigmoral.tech>
+
+description:
+ The Canaan Kendryte K230 reset controller is part of the SoC's system
+ controller and controls the reset registers for CPUs and various peripherals.
+
+properties:
+ compatible:
+ const: canaan,k230-rst
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ reset-controller@91101000 {
+ compatible = "canaan,k230-rst";
+ reg = <0x91101000 0x1000>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/eswin,eic7700-reset.yaml b/Documentation/devicetree/bindings/reset/eswin,eic7700-reset.yaml
new file mode 100644
index 000000000000..cf2fdb907571
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/eswin,eic7700-reset.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/eswin,eic7700-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESWIN EIC7700 SoC reset controller
+
+maintainers:
+ - Yifeng Huang <huangyifeng@eswincomputing.com>
+ - Xuyang Dong <dongxuyang@eswincomputing.com>
+
+description:
+ The system reset controller can be used to reset various peripheral
+ controllers in ESWIN eic7700 SoC.
+
+properties:
+ compatible:
+ const: eswin,eic7700-reset
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/eswin,eic7700-reset.h>
+
+ reset-controller@51828300 {
+ compatible = "eswin,eic7700-reset";
+ reg = <0x51828300 0x200>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
index b11ac533f914..f5ec1d54aa51 100644
--- a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
+++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml
@@ -28,28 +28,17 @@ description: |
properties:
compatible:
oneOf:
- - const: "fsl,imx51-src"
+ - const: fsl,imx51-src
- items:
- - const: "fsl,imx50-src"
- - const: "fsl,imx51-src"
- - items:
- - const: "fsl,imx53-src"
- - const: "fsl,imx51-src"
- - items:
- - const: "fsl,imx6q-src"
- - const: "fsl,imx51-src"
- - items:
- - const: "fsl,imx6sx-src"
- - const: "fsl,imx51-src"
- - items:
- - const: "fsl,imx6sl-src"
- - const: "fsl,imx51-src"
- - items:
- - const: "fsl,imx6ul-src"
- - const: "fsl,imx51-src"
- - items:
- - const: "fsl,imx6sll-src"
- - const: "fsl,imx51-src"
+ - enum:
+ - fsl,imx50-src
+ - fsl,imx53-src
+ - fsl,imx6q-src
+ - fsl,imx6sx-src
+ - fsl,imx6sl-src
+ - fsl,imx6ul-src
+ - fsl,imx6sll-src
+ - const: fsl,imx51-src
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml
index cdfcf32c53fa..e4de002d6903 100644
--- a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml
@@ -50,32 +50,9 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/irq.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/clock/hi3660-clock.h>
-
- iomcu: iomcu@ffd7e000 {
- compatible = "hisilicon,hi3660-iomcu", "syscon";
- reg = <0xffd7e000 0x1000>;
- };
-
- iomcu_rst: iomcu_rst_controller {
+ iomcu_rst_controller {
compatible = "hisilicon,hi3660-reset";
hisilicon,rst-syscon = <&iomcu>;
#reset-cells = <2>;
};
-
- /* Specifying reset lines connected to IP modules */
- i2c@ffd71000 {
- compatible = "snps,designware-i2c";
- reg = <0xffd71000 0x1000>;
- interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- clock-frequency = <400000>;
- clocks = <&crg_ctrl HI3660_CLK_GATE_I2C0>;
- resets = <&iomcu_rst 0x20 3>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>;
- };
...
diff --git a/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml b/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
index d71d0f0a13ee..dc86568bfd75 100644
--- a/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
@@ -2,8 +2,8 @@
# Copyright 2015 Antoine Tenart <atenart@kernel.org>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/marvell,berlin2-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/marvell,berlin2-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell Berlin reset controller
diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml
index 81cd8c837623..e190e526f3e9 100644
--- a/Documentation/devicetree/bindings/reset/microchip,rst.yaml
+++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/microchip,rst.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip Sparx5 Switch Reset Controller
@@ -20,9 +20,14 @@ properties:
pattern: "^reset-controller@[0-9a-f]+$"
compatible:
- enum:
- - microchip,sparx5-switch-reset
- - microchip,lan966x-switch-reset
+ oneOf:
+ - enum:
+ - microchip,sparx5-switch-reset
+ - microchip,lan966x-switch-reset
+ - items:
+ - enum:
+ - microchip,lan9691-switch-reset
+ - const: microchip,lan966x-switch-reset
reg:
items:
@@ -36,7 +41,7 @@ properties:
const: 1
cpu-syscon:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: syscon used to access CPU reset
required:
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
new file mode 100644
index 000000000000..3ce7dcecd87a
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Reset Controller
+
+maintainers:
+ - Chi-Fang Li <cfli0@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+description:
+ The system reset controller can be used to reset various peripheral
+ controllers in MA35D1 SoC.
+
+properties:
+ compatible:
+ items:
+ - const: nuvoton,ma35d1-reset
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ # system reset controller node:
+ - |
+
+ system-management@40460000 {
+ compatible = "nuvoton,ma35d1-reset", "syscon";
+ reg = <0x40460000 0x200>;
+ #reset-cells = <1>;
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
index d82e65e37cc0..72523f1bbc18 100644
--- a/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
@@ -21,6 +21,13 @@ properties:
'#reset-cells':
const: 2
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ items:
+ - description: specify external 25MHz reference clock.
+
nuvoton,sysgcr:
$ref: /schemas/types.yaml#/definitions/phandle
description: a phandle to access GCR registers.
@@ -39,6 +46,17 @@ required:
- '#reset-cells'
- nuvoton,sysgcr
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nuvoton,npcm845-reset
+then:
+ required:
+ - '#clock-cells'
+ - clocks
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.txt b/Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.txt
deleted file mode 100644
index 05d5be48dae4..000000000000
--- a/Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-NXP LPC1850 Reset Generation Unit (RGU)
-========================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: Should be "nxp,lpc1850-rgu"
-- reg: register base and length
-- clocks: phandle and clock specifier to RGU clocks
-- clock-names: should contain "delay" and "reg"
-- #reset-cells: should be 1
-
-See table below for valid peripheral reset numbers. Numbers not
-in the table below are either reserved or not applicable for
-normal operation.
-
-Reset Peripheral
- 9 System control unit (SCU)
- 12 ARM Cortex-M0 subsystem core (LPC43xx only)
- 13 CPU core
- 16 LCD controller
- 17 USB0
- 18 USB1
- 19 DMA
- 20 SDIO
- 21 External memory controller (EMC)
- 22 Ethernet
- 25 Flash bank A
- 27 EEPROM
- 28 GPIO
- 29 Flash bank B
- 32 Timer0
- 33 Timer1
- 34 Timer2
- 35 Timer3
- 36 Repetitive Interrupt timer (RIT)
- 37 State Configurable Timer (SCT)
- 38 Motor control PWM (MCPWM)
- 39 QEI
- 40 ADC0
- 41 ADC1
- 42 DAC
- 44 USART0
- 45 UART1
- 46 USART2
- 47 USART3
- 48 I2C0
- 49 I2C1
- 50 SSP0
- 51 SSP1
- 52 I2S0 and I2S1
- 53 Serial Flash Interface (SPIFI)
- 54 C_CAN1
- 55 C_CAN0
- 56 ARM Cortex-M0 application core (LPC4370 only)
- 57 SGPIO (LPC43xx only)
- 58 SPI (LPC43xx only)
- 60 ADCHS (12-bit ADC) (LPC4370 only)
-
-Refer to NXP LPC18xx or LPC43xx user manual for more details about
-the reset signals and the connected block/peripheral.
-
-Reset provider example:
-rgu: reset-controller@40053000 {
- compatible = "nxp,lpc1850-rgu";
- reg = <0x40053000 0x1000>;
- clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_BUS>;
- clock-names = "delay", "reg";
- #reset-cells = <1>;
-};
-
-Reset consumer example:
-mac: ethernet@40010000 {
- compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", "snps,dwmac";
- reg = <0x40010000 0x2000>;
- interrupts = <5>;
- interrupt-names = "macirq";
- clocks = <&ccu1 CLK_CPU_ETHERNET>;
- clock-names = "stmmaceth";
- resets = <&rgu 22>;
- reset-names = "stmmaceth";
-};
diff --git a/Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.yaml b/Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.yaml
new file mode 100644
index 000000000000..9c3c13c543c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/nxp,lpc1850-rgu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1850 Reset Generation Unit (RGU)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-rgu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: delay
+ - const: reg
+
+ '#reset-cells':
+ const: 1
+ description: |
+ See table below for valid peripheral reset numbers. Numbers not
+ in the table below are either reserved or not applicable for
+ normal operation.
+
+ Reset Peripheral
+ 9 System control unit (SCU)
+ 12 ARM Cortex-M0 subsystem core (LPC43xx only)
+ 13 CPU core
+ 16 LCD controller
+ 17 USB0
+ 18 USB1
+ 19 DMA
+ 20 SDIO
+ 21 External memory controller (EMC)
+ 22 Ethernet
+ 25 Flash bank A
+ 27 EEPROM
+ 28 GPIO
+ 29 Flash bank B
+ 32 Timer0
+ 33 Timer1
+ 34 Timer2
+ 35 Timer3
+ 36 Repetitive Interrupt timer (RIT)
+ 37 State Configurable Timer (SCT)
+ 38 Motor control PWM (MCPWM)
+ 39 QEI
+ 40 ADC0
+ 41 ADC1
+ 42 DAC
+ 44 USART0
+ 45 UART1
+ 46 USART2
+ 47 USART3
+ 48 I2C0
+ 49 I2C1
+ 50 SSP0
+ 51 SSP1
+ 52 I2S0 and I2S1
+ 53 Serial Flash Interface (SPIFI)
+ 54 C_CAN1
+ 55 C_CAN0
+ 56 ARM Cortex-M0 application core (LPC4370 only)
+ 57 SGPIO (LPC43xx only)
+ 58 SPI (LPC43xx only)
+ 60 ADCHS (12-bit ADC) (LPC4370 only)
+
+ Refer to NXP LPC18xx or LPC43xx user manual for more details about
+ the reset signals and the connected block/peripheral.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+ #include <dt-bindings/clock/lpc18xx-cgu.h>
+
+ reset-controller@40053000 {
+ compatible = "nxp,lpc1850-rgu";
+ reg = <0x40053000 0x1000>;
+ clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_BUS>;
+ clock-names = "delay", "reg";
+ #reset-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
deleted file mode 100644
index d27ccb5d04fc..000000000000
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Oxford Semiconductor OXNAS SoC Family RESET Controller
-================================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: For OX810SE, should be "oxsemi,ox810se-reset"
- For OX820, should be "oxsemi,ox820-reset"
-- #reset-cells: 1, see below
-
-Parent node should have the following properties :
-- compatible: For OX810SE, should be :
- "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
- For OX820, should be :
- "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-
-Reset indices are in dt-bindings include files :
-- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
-- For OX820: include/dt-bindings/reset/oxsemi,ox820.h
-
-example:
-
-sys: sys-ctrl@000000 {
- compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
- reg = <0x000000 0x100000>;
-
- reset: reset-controller {
- compatible = "oxsemi,ox810se-reset";
- #reset-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml b/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
index 9be60e55cd71..47f8525a9b38 100644
--- a/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
@@ -2,8 +2,8 @@
# Copyright 2015 Alban Bedel <albeu@free.fr>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/qca,ar7100-reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/qca,ar7100-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Atheros AR7xxx/AR9XXX reset controller
diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml
index d92e2b3cc83f..24beb712b56d 100644
--- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml
@@ -18,17 +18,17 @@ properties:
oneOf:
- description: on SC7180 SoCs the following compatibles must be specified
items:
- - const: "qcom,sc7180-aoss-cc"
- - const: "qcom,sdm845-aoss-cc"
+ - const: qcom,sc7180-aoss-cc
+ - const: qcom,sdm845-aoss-cc
- description: on SC7280 SoCs the following compatibles must be specified
items:
- - const: "qcom,sc7280-aoss-cc"
- - const: "qcom,sdm845-aoss-cc"
+ - const: qcom,sc7280-aoss-cc
+ - const: qcom,sdm845-aoss-cc
- description: on SDM845 SoCs the following compatibles must be specified
items:
- - const: "qcom,sdm845-aoss-cc"
+ - const: qcom,sdm845-aoss-cc
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml
index ca5d79332189..f514363aa474 100644
--- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml
+++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml
@@ -18,16 +18,16 @@ properties:
oneOf:
- description: on SC7180 SoCs the following compatibles must be specified
items:
- - const: "qcom,sc7180-pdc-global"
- - const: "qcom,sdm845-pdc-global"
+ - const: qcom,sc7180-pdc-global
+ - const: qcom,sdm845-pdc-global
- description: on SC7280 SoCs the following compatibles must be specified
items:
- - const: "qcom,sc7280-pdc-global"
+ - const: qcom,sc7280-pdc-global
- description: on SDM845 SoCs the following compatibles must be specified
items:
- - const: "qcom,sdm845-pdc-global"
+ - const: qcom,sdm845-pdc-global
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml
index 0d1b89e2fe9c..7a81491379b0 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/renesas,rst.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/renesas,rst.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car and RZ/G Reset Controller
@@ -29,6 +29,7 @@ properties:
- renesas,r8a7745-rst # RZ/G1E
- renesas,r8a77470-rst # RZ/G1C
- renesas,r8a774a1-rst # RZ/G2M
+ - renesas,r8a774a3-rst # RZ/G2M v3.0
- renesas,r8a774b1-rst # RZ/G2N
- renesas,r8a774c0-rst # RZ/G2E
- renesas,r8a774e1-rst # RZ/G2H
@@ -50,6 +51,7 @@ properties:
- renesas,r8a779a0-rst # R-Car V3U
- renesas,r8a779f0-rst # R-Car S4-8
- renesas,r8a779g0-rst # R-Car V4H
+ - renesas,r8a779h0-rst # R-Car V4M
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
index 731b8ce01525..c83469a1b379 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
@@ -15,12 +15,14 @@ description:
properties:
compatible:
- items:
- - enum:
- - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL
- - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
- - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
- - const: renesas,rzg2l-usbphy-ctrl
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
+ - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
+ - renesas,r9a07g054-usbphy-ctrl # RZ/V2L
+ - const: renesas,rzg2l-usbphy-ctrl
+ - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
reg:
maxItems: 1
@@ -42,6 +44,26 @@ properties:
0 = Port 1 Phy reset
1 = Port 2 Phy reset
+ regulator-vbus:
+ type: object
+ description: USB VBUS regulator
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ renesas,sysc-pwrrdy:
+ description:
+ The system controller PWRRDY indicates to the USB PHY if the power supply
+ is ready. PWRRDY needs to be set during power-on before applying any
+ other settings. It also needs to be set before powering off the USB.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description:
+ System controller phandle required by USB PHY CTRL driver to set
+ PWRRDY
+ - description: Register offset associated with PWRRDY
+ - description: Register bitmask associated with PWRRDY
+
required:
- compatible
- reg
@@ -49,6 +71,20 @@ required:
- resets
- power-domains
- '#reset-cells'
+ - regulator-vbus
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a08g045-usbphy-ctrl
+ then:
+ required:
+ - renesas,sysc-pwrrdy
+ else:
+ properties:
+ renesas,sysc-pwrrdy: false
additionalProperties: false
@@ -64,4 +100,7 @@ examples:
resets = <&cpg R9A07G044_USB_PRESETN>;
power-domains = <&cpg>;
#reset-cells = <1>;
+ regulator-vbus {
+ regulator-name = "vbus";
+ };
};
diff --git a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
new file mode 100644
index 000000000000..c1b800a10b53
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/renesas,rzv2h-usb2phy-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2H(P) USB2PHY Port reset Control
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+description:
+ The RZ/V2H(P) USB2PHY Control mainly controls Port reset and power down of the
+ USB2.0 PHY.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: renesas,r9a09g056-usb2phy-reset # RZ/V2N
+ - const: renesas,r9a09g057-usb2phy-reset
+
+ - const: renesas,r9a09g057-usb2phy-reset # RZ/V2H(P)
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - power-domains
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g057-cpg.h>
+
+ reset-controller@15830000 {
+ compatible = "renesas,r9a09g057-usb2phy-reset";
+ reg = <0x15830000 0x10000>;
+ clocks = <&cpg CPG_MOD 0xb6>;
+ resets = <&cpg 0xaf>;
+ power-domains = <&cpg>;
+ #reset-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
deleted file mode 100644
index 0c241d4aae76..000000000000
--- a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Synopsys DesignWare Reset controller
-=======================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-
-- compatible: should be one of the following.
- "snps,dw-high-reset" - for active high configuration
- "snps,dw-low-reset" - for active low configuration
-
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-- #reset-cells: must be 1.
-
-example:
-
- dw_rst_1: reset-controller@0000 {
- compatible = "snps,dw-high-reset";
- reg = <0x0000 0x4>;
- #reset-cells = <1>;
- };
-
- dw_rst_2: reset-controller@1000 {
- compatible = "snps,dw-low-reset";
- reg = <0x1000 0x8>;
- #reset-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
new file mode 100644
index 000000000000..1dde7b6e8623
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/snps,dw-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare Reset controller
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+properties:
+ compatible:
+ enum:
+ - snps,dw-high-reset
+ - snps,dw-low-reset
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+ reset-controller: true
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ reset-controller@0 {
+ compatible = "snps,dw-high-reset";
+ reg = <0x0000 0x4>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml
index 0a2c13e1e230..babc563ae61e 100644
--- a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml
@@ -38,13 +38,17 @@ properties:
minItems: 1
maxItems: 2
- clock-names: true
+ clock-names:
+ minItems: 1
+ maxItems: 2
resets:
minItems: 1
maxItems: 2
- reset-names: true
+ reset-names:
+ minItems: 1
+ maxItems: 2
allOf:
- if:
@@ -95,19 +99,12 @@ required:
examples:
- |
- usb-glue@65b00000 {
- compatible = "simple-mfd";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x65b00000 0x400>;
-
- usb_rst: reset@0 {
- compatible = "socionext,uniphier-ld20-usb3-reset";
- reg = <0x0 0x4>;
- #reset-cells = <1>;
- clock-names = "link";
- clocks = <&sys_clk 14>;
- reset-names = "link";
- resets = <&sys_rst 14>;
- };
+ usb_rst: reset-controller@0 {
+ compatible = "socionext,uniphier-ld20-usb3-reset";
+ reg = <0x0 0x4>;
+ #reset-cells = <1>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
};
diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
index 6566804ec567..033b252a3dfe 100644
--- a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
@@ -66,53 +66,7 @@ required:
examples:
- |
- sysctrl@61840000 {
- compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon";
- reg = <0x61840000 0x4000>;
-
- reset {
- compatible = "socionext,uniphier-ld11-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- mioctrl@59810000 {
- compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon";
- reg = <0x59810000 0x800>;
-
- reset {
- compatible = "socionext,uniphier-ld11-mio-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- perictrl@59820000 {
- compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon";
- reg = <0x59820000 0x200>;
-
- reset {
- compatible = "socionext,uniphier-ld11-peri-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
- };
-
- - |
- adamv@57920000 {
- compatible = "socionext,uniphier-ld11-adamv", "simple-mfd", "syscon";
- reg = <0x57920000 0x1000>;
-
- reset {
- compatible = "socionext,uniphier-ld11-adamv-reset";
- #reset-cells = <1>;
- };
-
- // other nodes ...
+ reset-controller {
+ compatible = "socionext,uniphier-ld11-reset";
+ #reset-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml b/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml
new file mode 100644
index 000000000000..08d28313b870
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/sophgo,sg2042-reset.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/sophgo,sg2042-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2042 SoC Reset Controller
+
+maintainers:
+ - Chen Wang <unicorn_wang@outlook.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sophgo,sg2044-reset
+ - const: sophgo,sg2042-reset
+ - enum:
+ - sophgo,cv1800b-reset
+ - sophgo,sg2042-reset
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ rstgen: reset-controller@c00 {
+ compatible = "sophgo,sg2042-reset";
+ reg = <0xc00 0xc>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
index 01db34375192..384035e8e60b 100644
--- a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -3,4 +3,4 @@ STMicroelectronics STM32 Peripheral Reset Controller
The RCC IP is both a reset and a clock controller.
-Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.yaml
diff --git a/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml b/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml
index 300359a5e14b..2f5bd616b7ae 100644
--- a/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/reset/starfive,jh7100-reset.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: StarFive JH7100 SoC Reset Controller Device Tree Bindings
+title: StarFive JH7100 SoC Reset Controller
maintainers:
- Emil Renner Berthing <kernel@esmil.dk>
diff --git a/Documentation/devicetree/bindings/reset/sunplus,reset.yaml b/Documentation/devicetree/bindings/reset/sunplus,reset.yaml
index f24646ba9761..205918ce324c 100644
--- a/Documentation/devicetree/bindings/reset/sunplus,reset.yaml
+++ b/Documentation/devicetree/bindings/reset/sunplus,reset.yaml
@@ -2,8 +2,8 @@
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/reset/sunplus,reset.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/reset/sunplus,reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus SoC Reset Controller
diff --git a/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml
new file mode 100644
index 000000000000..7b5053c177fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/thead,th1520-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD TH1520 SoC Reset Controller
+
+description:
+ The T-HEAD TH1520 reset controller is a hardware block that asserts/deasserts
+ resets for SoC subsystems.
+
+maintainers:
+ - Michal Wilczynski <m.wilczynski@samsung.com>
+
+properties:
+ compatible:
+ enum:
+ - thead,th1520-reset # Reset controller for VO subsystem
+ - thead,th1520-reset-ao
+ - thead,th1520-reset-ap
+ - thead,th1520-reset-dsp
+ - thead,th1520-reset-misc
+ - thead,th1520-reset-vi
+ - thead,th1520-reset-vp
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ rst: reset-controller@ffef528000 {
+ compatible = "thead,th1520-reset";
+ reg = <0xff 0xef528000 0x0 0x1000>;
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
index 4639d2cec557..68640abacd95 100644
--- a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI-SCI reset controller node bindings
+title: TI-SCI reset controller
maintainers:
- Nishanth Menon <nm@ti.com>
@@ -37,10 +37,9 @@ properties:
The second cell should contain the reset mask corresponding to the device
used by system controller.
- Please see http://processors.wiki.ti.com/index.php/TISCI for
+ Please see https://software-dl.ti.com/tisci/esd/latest/index.html for
protocol documentation for the values to be used for different devices.
-
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml
index afc835eda0ef..6063784f0352 100644
--- a/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/ti,tps380x-reset.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/reset/ti,tps380x-reset.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI TPS380x reset controller node bindings
+title: TI TPS380x reset controller
maintainers:
- Marco Felsch <kernel@pengutronix.de>
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 86945502ccb5..61a0ff33e89f 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -43,7 +43,7 @@ Required properties:
Cell #6 : bit position of the reset in the
reset status register
Cell #7 : Flags used to control reset behavior,
- availible flags defined in the DT include
+ available flags defined in the DT include
file <dt-bindings/reset/ti-syscon.h>
SysCon Reset Consumer Nodes
diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
deleted file mode 100644
index ed836868dbf1..000000000000
--- a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt
+++ /dev/null
@@ -1,55 +0,0 @@
---------------------------------------------------------------------------
- = Zynq UltraScale+ MPSoC and Versal reset driver binding =
---------------------------------------------------------------------------
-The Zynq UltraScale+ MPSoC and Versal has several different resets.
-
-See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information
-about zynqmp resets.
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required Properties:
-- compatible: "xlnx,zynqmp-reset" for Zynq UltraScale+ MPSoC platform
- "xlnx,versal-reset" for Versal platform
-- #reset-cells: Specifies the number of cells needed to encode reset
- line, should be 1
-
--------
-Example
--------
-
-firmware {
- zynqmp_firmware: zynqmp-firmware {
- compatible = "xlnx,zynqmp-firmware";
- method = "smc";
-
- zynqmp_reset: reset-controller {
- compatible = "xlnx,zynqmp-reset";
- #reset-cells = <1>;
- };
- };
-};
-
-Specifying reset lines connected to IP modules
-==============================================
-
-Device nodes that need access to reset lines should
-specify them as a reset phandle in their corresponding node as
-specified in reset.txt.
-
-For list of all valid reset indices for Zynq UltraScale+ MPSoC see
-<dt-bindings/reset/xlnx-zynqmp-resets.h>
-For list of all valid reset indices for Versal see
-<dt-bindings/reset/xlnx-versal-resets.h>
-
-Example:
-
-serdes: zynqmp_phy@fd400000 {
- ...
-
- resets = <&zynqmp_reset ZYNQMP_RESET_SATA>;
- reset-names = "sata_rst";
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
new file mode 100644
index 000000000000..1db85fc9966f
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/xlnx,zynqmp-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zynq UltraScale+ MPSoC and Versal reset
+
+maintainers:
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
+
+description: |
+ The Zynq UltraScale+ MPSoC and Versal has several different resets.
+
+ The PS reset subsystem is responsible for handling the external reset
+ input to the device and that all internal reset requirements are met
+ for the system (as a whole) and for the functional units.
+
+ Please also refer to reset.txt in this directory for common reset
+ controller binding usage. Device nodes that need access to reset
+ lines should specify them as a reset phandle in their corresponding
+ node as specified in reset.txt.
+
+ For list of all valid reset indices for Zynq UltraScale+ MPSoC
+ <dt-bindings/reset/xlnx-zynqmp-resets.h>
+
+ For list of all valid reset indices for Versal
+ <dt-bindings/reset/xlnx-versal-resets.h>
+
+properties:
+ compatible:
+ enum:
+ - xlnx,zynqmp-reset
+ - xlnx,versal-reset
+ - xlnx,versal-net-reset
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ zynqmp_reset: reset-controller {
+ compatible = "xlnx,zynqmp-reset";
+ #reset-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/andes.yaml b/Documentation/devicetree/bindings/riscv/andes.yaml
new file mode 100644
index 000000000000..aa1edf1fdec7
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/andes.yaml
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/andes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes SoC-based boards
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+description:
+ Andes SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - andestech,voyager
+ - const: andestech,qilai
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/riscv/anlogic.yaml b/Documentation/devicetree/bindings/riscv/anlogic.yaml
new file mode 100644
index 000000000000..91b1526c99aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/anlogic.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/anlogic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Anlogic SoC-based boards
+
+maintainers:
+ - Junhui Liu <junhui.liu@pigmoral.tech>
+
+description:
+ Anlogic SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - milianke,mlkpai-fs01
+ - const: anlogic,dr1v90
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
index f8f3f286bd55..41fd11f70a49 100644
--- a/Documentation/devicetree/bindings/riscv/canaan.yaml
+++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Canaan SoC-based boards
maintainers:
- - Damien Le Moal <damien.lemoal@wdc.com>
+ - Damien Le Moal <dlemoal@kernel.org>
description:
Canaan Kendryte K210 SoC-based boards
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 873dd12f6e89..d733c0bd534f 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -4,11 +4,12 @@
$id: http://devicetree.org/schemas/riscv/cpus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: RISC-V bindings for 'cpus' DT nodes
+title: RISC-V CPUs
maintainers:
- Paul Walmsley <paul.walmsley@sifive.com>
- Palmer Dabbelt <palmer@sifive.com>
+ - Conor Dooley <conor@kernel.org>
description: |
This document uses some terminology common to the RISC-V community
@@ -22,27 +23,55 @@ description: |
two cores, each of which has two hyperthreads, could be described as
having four harts.
+allOf:
+ - $ref: /schemas/cpu.yaml#
+ - $ref: extensions.yaml
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - thead,c906
+ - thead,c910
+ - thead,c920
+ then:
+ properties:
+ thead,vlenb: false
+
properties:
compatible:
oneOf:
- items:
- enum:
- - sifive,rocket0
+ - amd,mbv32
+ - amd,mbv64
+ - andestech,ax45mp
+ - canaan,k210
+ - nuclei,ux900
- sifive,bullet0
- sifive,e5
- sifive,e7
- sifive,e71
- - sifive,u74-mc
- - sifive,u54
- - sifive,u74
+ - sifive,p550
+ - sifive,rocket0
+ - sifive,s7
- sifive,u5
+ - sifive,u54
- sifive,u7
- - canaan,k210
+ - sifive,u74
+ - sifive,u74-mc
+ - spacemit,x60
+ - thead,c906
+ - thead,c908
+ - thead,c910
+ - thead,c920
- const: riscv
- items:
- enum:
- sifive,e51
- sifive,u54-mc
+ - sifive,x280
- const: sifive,rocket0
- const: riscv
- const: riscv # Simulator only
@@ -52,71 +81,82 @@ properties:
mmu-type:
description:
- Identifies the MMU address translation mode used on this
- hart. These values originate from the RISC-V Privileged
+ Identifies the largest MMU address translation mode supported by
+ this hart. These values originate from the RISC-V Privileged
Specification document, available from
https://riscv.org/specifications/
- $ref: "/schemas/types.yaml#/definitions/string"
+ $ref: /schemas/types.yaml#/definitions/string
enum:
- riscv,sv32
- riscv,sv39
- riscv,sv48
+ - riscv,sv57
- riscv,none
+ reg:
+ description:
+ The hart ID of this CPU node.
+
riscv,cbom-block-size:
$ref: /schemas/types.yaml#/definitions/uint32
description:
The blocksize in bytes for the Zicbom cache operations.
- riscv,isa:
+ riscv,cbop-block-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
description:
- Identifies the specific RISC-V instruction set architecture
- supported by the hart. These are documented in the RISC-V
- User-Level ISA document, available from
- https://riscv.org/specifications/
+ The blocksize in bytes for the Zicbop cache operations.
- While the isa strings in ISA specification are case
- insensitive, letters in the riscv,isa string must be all
- lowercase to simplify parsing.
- $ref: "/schemas/types.yaml#/definitions/string"
- enum:
- - rv64imac
- - rv64imafdc
+ riscv,cboz-block-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The blocksize in bytes for the Zicboz cache operations.
+
+ thead,vlenb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ VLEN/8, the vector register length in bytes. This property is required on
+ thead systems where the vector register length is not identical on all harts, or
+ the vlenb CSR is not available.
+ # RISC-V has multiple properties for cache op block sizes as the sizes
+ # differ between individual CBO extensions
+ cache-op-block-size: false
# RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
timebase-frequency: false
interrupt-controller:
type: object
- description: Describes the CPU's local interrupt controller
-
- properties:
- '#interrupt-cells':
- const: 1
-
- compatible:
- const: riscv,cpu-intc
-
- interrupt-controller: true
-
- required:
- - '#interrupt-cells'
- - compatible
- - interrupt-controller
+ $ref: /schemas/interrupt-controller/riscv,cpu-intc.yaml#
cpu-idle-states:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
maxItems: 1
description: |
List of phandles to idle state nodes supported
by this hart (see ./idle-states.yaml).
+ capacity-dmips-mhz:
+ description:
+ u32 value representing CPU capacity (see ../cpu/cpu-capacity.txt) in
+ DMIPS/MHz, relative to highest capacity-dmips-mhz
+ in the system.
+
+anyOf:
+ - required:
+ - riscv,isa
+ - required:
+ - riscv,isa-base
+
+dependencies:
+ riscv,isa-base: [ "riscv,isa-extensions" ]
+ riscv,isa-extensions: [ "riscv,isa-base" ]
+
required:
- - riscv,isa
- interrupt-controller
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
@@ -133,7 +173,9 @@ examples:
i-cache-sets = <128>;
i-cache-size = <16384>;
reg = <0>;
- riscv,isa = "rv64imac";
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "c";
+
cpu_intc0: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -156,8 +198,10 @@ examples:
i-tlb-size = <32>;
mmu-type = "riscv,sv39";
reg = <1>;
- riscv,isa = "rv64imafdc";
tlb-split;
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+
cpu_intc1: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -175,8 +219,10 @@ examples:
device_type = "cpu";
reg = <0>;
compatible = "riscv";
- riscv,isa = "rv64imafdc";
mmu-type = "riscv,sv48";
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+
interrupt-controller {
#interrupt-cells = <1>;
interrupt-controller;
diff --git a/Documentation/devicetree/bindings/riscv/eswin.yaml b/Documentation/devicetree/bindings/riscv/eswin.yaml
new file mode 100644
index 000000000000..c603c45eef22
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/eswin.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/eswin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESWIN SoC-based boards
+
+maintainers:
+ - Min Lin <linmin@eswincomputing.com>
+ - Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
+ - Pritesh Patel <pritesh.patel@einfochips.com>
+
+description:
+ ESWIN SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sifive,hifive-premier-p550
+ - const: eswin,eic7700
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
new file mode 100644
index 000000000000..565cb2cbb49b
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -0,0 +1,904 @@
+# SPDX-License-Identifier: (GPL-2.0 OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/extensions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V ISA extensions
+
+maintainers:
+ - Paul Walmsley <paul.walmsley@sifive.com>
+ - Palmer Dabbelt <palmer@sifive.com>
+ - Conor Dooley <conor@kernel.org>
+
+description: |
+ RISC-V has a large number of extensions, some of which are "standard"
+ extensions, meaning they are ratified by RISC-V International, and others
+ are "vendor" extensions.
+ This document defines properties that indicate whether a hart supports a
+ given extension.
+
+ Once a standard extension has been ratified, no changes in behaviour can be
+ made without the creation of a new extension.
+ The properties for standard extensions therefore map to their originally
+ ratified states, with the exception of the I, Zicntr & Zihpm extensions.
+ See the "i" property for more information.
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: riscv
+
+properties:
+ riscv,isa:
+ description:
+ Identifies the specific RISC-V instruction set architecture
+ supported by the hart. These are documented in the RISC-V
+ User-Level ISA document, available from
+ https://riscv.org/specifications/
+
+ Due to revisions of the ISA specification, some deviations
+ have arisen over time.
+ Notably, riscv,isa was defined prior to the creation of the
+ Zicntr, Zicsr, Zifencei and Zihpm extensions and thus "i"
+ implies "zicntr_zicsr_zifencei_zihpm".
+
+ While the isa strings in ISA specification are case
+ insensitive, letters in the riscv,isa string must be all
+ lowercase.
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[0-9a-z])+)?(?:_[hsxz](?:[0-9a-z])+)*$
+ deprecated: true
+
+ riscv,isa-base:
+ description:
+ The base ISA implemented by this hart, as described by the 20191213
+ version of the unprivileged ISA specification.
+ enum:
+ - rv32i
+ - rv64i
+
+ riscv,isa-extensions:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ minItems: 1
+ description: Extensions supported by the hart.
+ items:
+ anyOf:
+ # single letter extensions, in canonical order
+ - const: i
+ description: |
+ The base integer instruction set, as ratified in the 20191213
+ version of the unprivileged ISA specification.
+
+ This does not include Chapter 10, "Counters", which was moved into
+ the Zicntr and Zihpm extensions after the ratification of the
+ 20191213 version of the unprivileged specification.
+
+ - const: m
+ description:
+ The standard M extension for integer multiplication and division, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: a
+ description:
+ The standard A extension for atomic instructions, as ratified in the
+ 20191213 version of the unprivileged ISA specification.
+
+ - const: f
+ description:
+ The standard F extension for single-precision floating point, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: d
+ description:
+ The standard D extension for double-precision floating-point, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: q
+ description:
+ The standard Q extension for quad-precision floating-point, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: c
+ description:
+ The standard C extension for compressed instructions, as ratified in
+ the 20191213 version of the unprivileged ISA specification.
+
+ - const: v
+ description:
+ The standard V extension for vector operations, as ratified
+ in-and-around commit 7a6c8ae ("Fix text that describes vfmv.v.f
+ encoding") of the riscv-v-spec.
+
+ - const: h
+ description:
+ The standard H extension for hypervisors as ratified in the 20191213
+ version of the privileged ISA specification.
+
+ # multi-letter extensions, sorted alphanumerically
+ - const: smaia
+ description: |
+ The standard Smaia supervisor-level extension for the advanced
+ interrupt architecture for machine-mode-visible csr and behavioural
+ changes to interrupts as frozen at commit ccbddab ("Merge pull
+ request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
+
+ - const: smmpm
+ description: |
+ The standard Smmpm extension for M-mode pointer masking as
+ ratified at commit d70011dde6c2 ("Update to ratified state")
+ of riscv-j-extension.
+
+ - const: smnpm
+ description: |
+ The standard Smnpm extension for next-mode pointer masking as
+ ratified at commit d70011dde6c2 ("Update to ratified state")
+ of riscv-j-extension.
+
+ - const: smstateen
+ description: |
+ The standard Smstateen extension for controlling access to CSRs
+ added by other RISC-V extensions in H/S/VS/U/VU modes and as
+ ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable.
+
+ - const: ssaia
+ description: |
+ The standard Ssaia supervisor-level extension for the advanced
+ interrupt architecture for supervisor-mode-visible csr and
+ behavioural changes to interrupts as frozen at commit ccbddab
+ ("Merge pull request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
+
+ - const: sscofpmf
+ description: |
+ The standard Sscofpmf supervisor-level extension for count overflow
+ and mode-based filtering as ratified at commit 01d1df0 ("Add ability
+ to manually trigger workflow. (#2)") of riscv-count-overflow.
+
+ - const: ssnpm
+ description: |
+ The standard Ssnpm extension for next-mode pointer masking as
+ ratified at commit d70011dde6c2 ("Update to ratified state")
+ of riscv-j-extension.
+
+ - const: sstc
+ description: |
+ The standard Sstc supervisor-level extension for time compare as
+ ratified at commit 3f9ed34 ("Add ability to manually trigger
+ workflow. (#2)") of riscv-time-compare.
+
+ - const: svade
+ description: |
+ The standard Svade supervisor-level extension for SW-managed PTE A/D
+ bit updates as ratified in the 20240213 version of the privileged
+ ISA specification.
+
+ Both Svade and Svadu extensions control the hardware behavior when
+ the PTE A/D bits need to be set. The default behavior for the four
+ possible combinations of these extensions in the device tree are:
+ 1) Neither Svade nor Svadu present in DT => It is technically
+ unknown whether the platform uses Svade or Svadu. Supervisor
+ software should be prepared to handle either hardware updating
+ of the PTE A/D bits or page faults when they need updated.
+ 2) Only Svade present in DT => Supervisor must assume Svade to be
+ always enabled.
+ 3) Only Svadu present in DT => Supervisor must assume Svadu to be
+ always enabled.
+ 4) Both Svade and Svadu present in DT => Supervisor must assume
+ Svadu turned-off at boot time. To use Svadu, supervisor must
+ explicitly enable it using the SBI FWFT extension.
+
+ - const: svadu
+ description: |
+ The standard Svadu supervisor-level extension for hardware updating
+ of PTE A/D bits as ratified in the 20240528 version of the
+ privileged ISA specification. Please refer to Svade dt-binding
+ description for more details.
+
+ - const: svinval
+ description:
+ The standard Svinval supervisor-level extension for fine-grained
+ address-translation cache invalidation as ratified in the 20191213
+ version of the privileged ISA specification.
+
+ - const: svnapot
+ description:
+ The standard Svnapot supervisor-level extensions for napot
+ translation contiguity as ratified in the 20191213 version of the
+ privileged ISA specification.
+
+ - const: svpbmt
+ description:
+ The standard Svpbmt supervisor-level extensions for page-based
+ memory types as ratified in the 20191213 version of the privileged
+ ISA specification.
+
+ - const: svrsw60t59b
+ description:
+ The Svrsw60t59b extension for providing two more bits[60:59] to
+ PTE/PMD entry as ratified at commit 28bde925e7a7 ("PTE Reserved
+ for SW bits 60:59") of riscv-non-isa/riscv-iommu.
+
+ - const: svvptc
+ description:
+ The standard Svvptc supervisor-level extension for
+ address-translation cache behaviour with respect to invalid entries
+ as ratified at commit 4a69197e5617 ("Update to ratified state") of
+ riscv-svvptc.
+
+ - const: zaamo
+ description: |
+ The standard Zaamo extension for atomic memory operations as
+ ratified at commit e87412e621f1 ("integrate Zaamo and Zalrsc text
+ (#1304)") of the unprivileged ISA specification.
+
+ - const: zabha
+ description: |
+ The Zabha extension for Byte and Halfword Atomic Memory Operations
+ as ratified at commit 49f49c842ff9 ("Update to Rafified state") of
+ riscv-zabha.
+
+ - const: zacas
+ description: |
+ The Zacas extension for Atomic Compare-and-Swap (CAS) instructions
+ is supported as ratified at commit 5059e0ca641c ("update to
+ ratified") of the riscv-zacas.
+
+ - const: zalasr
+ description: |
+ The standard Zalasr extension for load-acquire/store-release as frozen
+ at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
+
+ - const: zalrsc
+ description: |
+ The standard Zalrsc extension for load-reserved/store-conditional as
+ ratified at commit e87412e621f1 ("integrate Zaamo and Zalrsc text
+ (#1304)") of the unprivileged ISA specification.
+
+ - const: zawrs
+ description: |
+ The Zawrs extension for entering a low-power state or for trapping
+ to a hypervisor while waiting on a store to a memory location, as
+ ratified in commit 98918c844281 ("Merge pull request #1217 from
+ riscv/zawrs") of riscv-isa-manual.
+
+ - const: zba
+ description: |
+ The standard Zba bit-manipulation extension for address generation
+ acceleration instructions as ratified at commit 6d33919 ("Merge pull
+ request #158 from hirooih/clmul-fix-loop-end-condition") of
+ riscv-bitmanip.
+
+ - const: zbb
+ description: |
+ The standard Zbb bit-manipulation extension for basic bit-manipulation
+ as ratified at commit 6d33919 ("Merge pull request #158 from
+ hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+
+ - const: zbc
+ description: |
+ The standard Zbc bit-manipulation extension for carry-less
+ multiplication as ratified at commit 6d33919 ("Merge pull request
+ #158 from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+
+ - const: zbkb
+ description:
+ The standard Zbkb bitmanip instructions for cryptography as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zbkc
+ description:
+ The standard Zbkc carry-less multiply instructions as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zbkx
+ description:
+ The standard Zbkx crossbar permutation instructions as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zbs
+ description: |
+ The standard Zbs bit-manipulation extension for single-bit
+ instructions as ratified at commit 6d33919 ("Merge pull request #158
+ from hirooih/clmul-fix-loop-end-condition") of riscv-bitmanip.
+
+ - const: zca
+ description: |
+ The Zca extension part of Zc* standard extensions for code size
+ reduction, as ratified in commit 8be3419c1c0 ("Zcf doesn't exist on
+ RV64 as it contains no instructions") of riscv-code-size-reduction,
+ merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed
+ of zc.adoc to src tree.").
+
+ - const: zcb
+ description: |
+ The Zcb extension part of Zc* standard extensions for code size
+ reduction, as ratified in commit 8be3419c1c0 ("Zcf doesn't exist on
+ RV64 as it contains no instructions") of riscv-code-size-reduction,
+ merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed
+ of zc.adoc to src tree.").
+
+ - const: zcd
+ description: |
+ The Zcd extension part of Zc* standard extensions for code size
+ reduction, as ratified in commit 8be3419c1c0 ("Zcf doesn't exist on
+ RV64 as it contains no instructions") of riscv-code-size-reduction,
+ merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed
+ of zc.adoc to src tree.").
+
+ - const: zcf
+ description: |
+ The Zcf extension part of Zc* standard extensions for code size
+ reduction, as ratified in commit 8be3419c1c0 ("Zcf doesn't exist on
+ RV64 as it contains no instructions") of riscv-code-size-reduction,
+ merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed
+ of zc.adoc to src tree.").
+
+ - const: zcmop
+ description:
+ The standard Zcmop extension version 1.0, as ratified in commit
+ c732a4f39a4 ("Zcmop is ratified/1.0") of the riscv-isa-manual.
+
+ - const: zfa
+ description:
+ The standard Zfa extension for additional floating point
+ instructions, as ratified in commit 056b6ff ("Zfa is ratified") of
+ riscv-isa-manual.
+
+ - const: zfbfmin
+ description:
+ The standard Zfbfmin extension which provides minimal support for
+ 16-bit half-precision brain floating-point instructions, as ratified
+ in commit 4dc23d62 ("Added Chapter title to BF16") of riscv-isa-manual.
+
+ - const: zfh
+ description:
+ The standard Zfh extension for 16-bit half-precision binary
+ floating-point instructions, as ratified in commit 64074bc ("Update
+ version numbers for Zfh/Zfinx") of riscv-isa-manual.
+
+ - const: zfhmin
+ description:
+ The standard Zfhmin extension which provides minimal support for
+ 16-bit half-precision binary floating-point instructions, as ratified
+ in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
+ riscv-isa-manual.
+
+ - const: ziccrse
+ description:
+ The standard Ziccrse extension which provides forward progress
+ guarantee on LR/SC sequences, as ratified in commit b1d806605f87
+ ("Updated to ratified state.") of the riscv profiles specification.
+
+ - const: zk
+ description:
+ The standard Zk Standard Scalar cryptography extension as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zkn
+ description:
+ The standard Zkn NIST algorithm suite extensions as ratified in
+ version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zknd
+ description: |
+ The standard Zknd for NIST suite: AES decryption instructions as
+ ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zkne
+ description: |
+ The standard Zkne for NIST suite: AES encryption instructions as
+ ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zknh
+ description: |
+ The standard Zknh for NIST suite: hash function instructions as
+ ratified in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zkr
+ description:
+ The standard Zkr entropy source extension as ratified in version
+ 1.0 of RISC-V Cryptography Extensions Volume I specification.
+ This string being present means that the CSR associated to this
+ extension is accessible at the privilege level to which that
+ device-tree has been provided.
+
+ - const: zks
+ description:
+ The standard Zks ShangMi algorithm suite extensions as ratified in
+ version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zksed
+ description: |
+ The standard Zksed for ShangMi suite: SM4 block cipher instructions
+ as ratified in version 1.0 of RISC-V Cryptography Extensions
+ Volume I specification.
+
+ - const: zksh
+ description: |
+ The standard Zksh for ShangMi suite: SM3 hash function instructions
+ as ratified in version 1.0 of RISC-V Cryptography Extensions
+ Volume I specification.
+
+ - const: zkt
+ description:
+ The standard Zkt for data independent execution latency as ratified
+ in version 1.0 of RISC-V Cryptography Extensions Volume I
+ specification.
+
+ - const: zicbom
+ description:
+ The standard Zicbom extension for base cache management operations as
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ - const: zicbop
+ description:
+ The standard Zicbop extension for cache-block prefetch instructions
+ as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
+ riscv-CMOs.
+
+ - const: zicboz
+ description:
+ The standard Zicboz extension for cache-block zeroing as ratified
+ in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ - const: zicntr
+ description:
+ The standard Zicntr extension for base counters and timers, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zicond
+ description:
+ The standard Zicond extension for conditional arithmetic and
+ conditional-select/move operations as ratified in commit 95cf1f9
+ ("Add changes requested by Ved during signoff") of riscv-zicond.
+
+ - const: zicsr
+ description: |
+ The standard Zicsr extension for control and status register
+ instructions, as ratified in the 20191213 version of the
+ unprivileged ISA specification.
+
+ This does not include Chapter 10, "Counters", which documents
+ special case read-only CSRs, that were moved into the Zicntr and
+ Zihpm extensions after the ratification of the 20191213 version of
+ the unprivileged specification.
+
+ - const: zifencei
+ description:
+ The standard Zifencei extension for instruction-fetch fence, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zihintpause
+ description:
+ The standard Zihintpause extension for pause hints, as ratified in
+ commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
+
+ - const: zihintntl
+ description:
+ The standard Zihintntl extension for non-temporal locality hints, as
+ ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
+ riscv-isa-manual.
+
+ - const: zihpm
+ description:
+ The standard Zihpm extension for hardware performance counters, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zimop
+ description:
+ The standard Zimop extension version 1.0, as ratified in commit
+ 58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual.
+
+ - const: ztso
+ description:
+ The standard Ztso extension for total store ordering, as ratified
+ in commit 2e5236 ("Ztso is now ratified.") of the
+ riscv-isa-manual.
+
+ - const: zvbb
+ description:
+ The standard Zvbb extension for vectored basic bit-manipulation
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvbc
+ description:
+ The standard Zvbc extension for vectored carryless multiplication
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zve32f
+ description:
+ The standard Zve32f extension for embedded processors, as ratified
+ in commit 6f702a2 ("Vector extensions are now ratified") of
+ riscv-v-spec.
+
+ - const: zve32x
+ description:
+ The standard Zve32x extension for embedded processors, as ratified
+ in commit 6f702a2 ("Vector extensions are now ratified") of
+ riscv-v-spec.
+
+ - const: zve64d
+ description:
+ The standard Zve64d extension for embedded processors, as ratified
+ in commit 6f702a2 ("Vector extensions are now ratified") of
+ riscv-v-spec.
+
+ - const: zve64f
+ description:
+ The standard Zve64f extension for embedded processors, as ratified
+ in commit 6f702a2 ("Vector extensions are now ratified") of
+ riscv-v-spec.
+
+ - const: zve64x
+ description:
+ The standard Zve64x extension for embedded processors, as ratified
+ in commit 6f702a2 ("Vector extensions are now ratified") of
+ riscv-v-spec.
+
+ - const: zvfbfmin
+ description:
+ The standard Zvfbfmin extension for minimal support for vectored
+ 16-bit half-precision brain floating-point instructions, as ratified
+ in commit 4dc23d62 ("Added Chapter title to BF16") of riscv-isa-manual.
+
+ - const: zvfbfwma
+ description:
+ The standard Zvfbfwma extension for vectored half-precision brain
+ floating-point widening multiply-accumulate instructions, as ratified
+ in commit 4dc23d62 ("Added Chapter title to BF16") of riscv-isa-manual.
+
+ - const: zvfh
+ description:
+ The standard Zvfh extension for vectored half-precision
+ floating-point instructions, as ratified in commit e2ccd05
+ ("Remove draft warnings from Zvfh[min]") of riscv-v-spec.
+
+ - const: zvfhmin
+ description:
+ The standard Zvfhmin extension for vectored minimal half-precision
+ floating-point instructions, as ratified in commit e2ccd05
+ ("Remove draft warnings from Zvfh[min]") of riscv-v-spec.
+
+ - const: zvkb
+ description:
+ The standard Zvkb extension for vector cryptography bit-manipulation
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkg
+ description:
+ The standard Zvkg extension for vector GCM/GMAC instructions, as
+ ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc")
+ of riscv-crypto.
+
+ - const: zvkn
+ description:
+ The standard Zvkn extension for NIST algorithm suite instructions, as
+ ratified in commit 56ed795 ("Update riscv-crypto-spec-vector.adoc")
+ of riscv-crypto.
+
+ - const: zvknc
+ description:
+ The standard Zvknc extension for NIST algorithm suite with carryless
+ multiply instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkned
+ description:
+ The standard Zvkned extension for Vector AES block cipher
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkng
+ description:
+ The standard Zvkng extension for NIST algorithm suite with GCM
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvknha
+ description: |
+ The standard Zvknha extension for NIST suite: vector SHA-2 secure,
+ hash (SHA-256 only) instructions, as ratified in commit
+ 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvknhb
+ description: |
+ The standard Zvknhb extension for NIST suite: vector SHA-2 secure,
+ hash (SHA-256 and SHA-512) instructions, as ratified in commit
+ 56ed795 ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvks
+ description:
+ The standard Zvks extension for ShangMi algorithm suite
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksc
+ description:
+ The standard Zvksc extension for ShangMi algorithm suite with
+ carryless multiplication instructions, as ratified in commit 56ed795
+ ("Update riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksed
+ description: |
+ The standard Zvksed extension for ShangMi suite: SM4 block cipher
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksh
+ description: |
+ The standard Zvksh extension for ShangMi suite: SM3 secure hash
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvksg
+ description:
+ The standard Zvksg extension for ShangMi algorithm suite with GCM
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ - const: zvkt
+ description:
+ The standard Zvkt extension for vector data-independent execution
+ latency, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
+ # vendor extensions, each extension sorted alphanumerically under the
+ # vendor they belong to. Vendors are sorted alphanumerically as well.
+
+ # Andes
+ - const: xandespmu
+ description:
+ The Andes Technology performance monitor extension for counter overflow
+ and privilege mode filtering. For more details, see Counter Related
+ Registers in the AX45MP datasheet.
+ https://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf
+
+ # MIPS
+ - const: xmipsexectl
+ description:
+ The MIPS extension for execution control as documented in
+ https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf
+
+ # SiFive
+ - const: xsfcease
+ description:
+ SiFive CEASE Instruction Extensions Specification.
+ See more details in
+ https://www.sifive.com/document-file/freedom-u740-c000-manual
+
+ - const: xsfcflushdlone
+ description:
+ SiFive L1D Cache Flush Instruction Extensions Specification.
+ See more details in
+ https://www.sifive.com/document-file/freedom-u740-c000-manual
+
+ - const: xsfpgflushdlone
+ description:
+ SiFive PGFLUSH Instruction Extensions for the power management. The
+ CPU will flush the L1D and enter the cease state after executing
+ the instruction.
+
+ - const: xsfvqmaccdod
+ description:
+ SiFive Int8 Matrix Multiplication Extensions Specification.
+ See more details in
+ https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification
+
+ - const: xsfvqmaccqoq
+ description:
+ SiFive Int8 Matrix Multiplication Extensions Specification.
+ See more details in
+ https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification
+
+ - const: xsfvfnrclipxfqf
+ description:
+ SiFive FP32-to-int8 Ranged Clip Instructions Extensions Specification.
+ See more details in
+ https://www.sifive.com/document-file/fp32-to-int8-ranged-clip-instructions
+
+ - const: xsfvfwmaccqqq
+ description:
+ SiFive Matrix Multiply Accumulate Instruction Extensions Specification.
+ See more details in
+ https://www.sifive.com/document-file/matrix-multiply-accumulate-instruction
+
+ # T-HEAD
+ - const: xtheadvector
+ description:
+ The T-HEAD specific 0.7.1 vector implementation as written in
+ https://github.com/T-head-Semi/thead-extension-spec/blob/95358cb2cca9489361c61d335e03d3134b14133f/xtheadvector.adoc.
+
+ allOf:
+ - if:
+ contains:
+ const: d
+ then:
+ contains:
+ const: f
+ # Zcb depends on Zca
+ - if:
+ contains:
+ const: zcb
+ then:
+ contains:
+ const: zca
+ # Zcd depends on Zca and D
+ - if:
+ contains:
+ const: zcd
+ then:
+ allOf:
+ - contains:
+ const: zca
+ - contains:
+ const: d
+ # Zcf depends on Zca and F
+ - if:
+ contains:
+ const: zcf
+ then:
+ allOf:
+ - contains:
+ const: zca
+ - contains:
+ const: f
+ # Zcmop depends on Zca
+ - if:
+ contains:
+ const: zcmop
+ then:
+ contains:
+ const: zca
+ # Zfbfmin depends on F
+ - if:
+ contains:
+ const: zfbfmin
+ then:
+ contains:
+ const: f
+ # Zvfbfmin depends on V or Zve32f
+ - if:
+ contains:
+ const: zvfbfmin
+ then:
+ oneOf:
+ - contains:
+ const: v
+ - contains:
+ const: zve32f
+ # Zvfbfwma depends on Zfbfmin and Zvfbfmin
+ - if:
+ contains:
+ const: zvfbfwma
+ then:
+ allOf:
+ - contains:
+ const: zfbfmin
+ - contains:
+ const: zvfbfmin
+ # Zacas depends on Zaamo
+ - if:
+ contains:
+ const: zacas
+ then:
+ contains:
+ const: zaamo
+
+ - if:
+ contains:
+ const: zve32x
+ then:
+ contains:
+ const: zicsr
+
+ - if:
+ contains:
+ const: zve32f
+ then:
+ allOf:
+ - contains:
+ const: f
+ - contains:
+ const: zve32x
+
+ - if:
+ contains:
+ const: zve64x
+ then:
+ contains:
+ const: zve32x
+
+ - if:
+ contains:
+ const: zve64f
+ then:
+ allOf:
+ - contains:
+ const: f
+ - contains:
+ const: zve32f
+ - contains:
+ const: zve64x
+
+ - if:
+ contains:
+ const: zve64d
+ then:
+ allOf:
+ - contains:
+ const: d
+ - contains:
+ const: zve64f
+
+ - if:
+ contains:
+ anyOf:
+ - const: zvbc
+ - const: zvkn
+ - const: zvknc
+ - const: zvkng
+ - const: zvknhb
+ - const: zvksc
+ then:
+ contains:
+ anyOf:
+ - const: v
+ - const: zve64x
+
+ - if:
+ contains:
+ anyOf:
+ - const: zvbb
+ - const: zvkb
+ - const: zvkg
+ - const: zvkned
+ - const: zvknha
+ - const: zvksed
+ - const: zvksh
+ - const: zvks
+ - const: zvkt
+ then:
+ contains:
+ anyOf:
+ - const: v
+ - const: zve32x
+
+allOf:
+ # Zcf extension does not exist on rv64
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zcf
+ riscv,isa-base:
+ contains:
+ const: rv64i
+ then:
+ properties:
+ riscv,isa-extensions:
+ not:
+ contains:
+ const: zcf
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml b/Documentation/devicetree/bindings/riscv/microchip.yaml
index 1aa7336a9672..381d6eb6672e 100644
--- a/Documentation/devicetree/bindings/riscv/microchip.yaml
+++ b/Documentation/devicetree/bindings/riscv/microchip.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/riscv/microchip.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip PolarFire SoC-based boards device tree bindings
+title: Microchip PolarFire SoC-based boards
maintainers:
- - Cyril Jean <Cyril.Jean@microchip.com>
- - Lewis Hanly <lewis.hanly@microchip.com>
+ - Conor Dooley <conor.dooley@microchip.com>
+ - Daire McNamara <daire.mcnamara@microchip.com>
description:
Microchip PolarFire SoC-based boards
@@ -17,12 +17,35 @@ properties:
$nodename:
const: '/'
compatible:
- items:
- - enum:
- - microchip,mpfs-icicle-kit
- - microchip,mpfs-icicle-reference-rtlv2203
- - sundance,polarberry
- - const: microchip,mpfs
+ oneOf:
+ - items:
+ - const: microchip,mpfs-icicle-prod-reference-rtl-v2507
+ - const: microchip,mpfs-icicle-kit-prod
+ - const: microchip,mpfs-icicle-kit
+ - const: microchip,mpfs-prod
+ - const: microchip,mpfs
+
+ - items:
+ - enum:
+ - microchip,mpfs-icicle-reference-rtlv2203
+ - microchip,mpfs-icicle-reference-rtlv2210
+ - microchip,mpfs-icicle-es-reference-rtl-v2507
+ - const: microchip,mpfs-icicle-kit
+ - const: microchip,mpfs
+
+ - items:
+ - const: microchip,mpfs-disco-kit-reference-rtl-v2507
+ - const: microchip,mpfs-disco-kit
+ - const: microchip,mpfs
+
+ - items:
+ - enum:
+ - aldec,tysom-m-mpfs250t-rev2
+ - aries,m100pfsevp
+ - beagle,beaglev-fire
+ - microchip,mpfs-sev-kit
+ - sundance,polarberry
+ - const: microchip,mpfs
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
deleted file mode 100644
index ca3b9be58058..000000000000
--- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
+++ /dev/null
@@ -1,146 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-# Copyright (C) 2020 SiFive, Inc.
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/riscv/sifive-l2-cache.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: SiFive L2 Cache Controller
-
-maintainers:
- - Sagar Kadam <sagar.kadam@sifive.com>
- - Paul Walmsley <paul.walmsley@sifive.com>
-
-description:
- The SiFive Level 2 Cache Controller is used to provide access to fast copies
- of memory for masters in a Core Complex. The Level 2 Cache Controller also
- acts as directory-based coherency manager.
- All the properties in ePAPR/DeviceTree specification applies for this platform.
-
-select:
- properties:
- compatible:
- contains:
- enum:
- - sifive,fu540-c000-ccache
- - sifive,fu740-c000-ccache
-
- required:
- - compatible
-
-properties:
- compatible:
- oneOf:
- - items:
- - enum:
- - sifive,fu540-c000-ccache
- - sifive,fu740-c000-ccache
- - const: cache
- - items:
- - const: microchip,mpfs-ccache
- - const: sifive,fu540-c000-ccache
- - const: cache
-
- cache-block-size:
- const: 64
-
- cache-level:
- const: 2
-
- cache-sets:
- enum: [1024, 2048]
-
- cache-size:
- const: 2097152
-
- cache-unified: true
-
- interrupts:
- minItems: 3
- items:
- - description: DirError interrupt
- - description: DataError interrupt
- - description: DataFail interrupt
- - description: DirFail interrupt
-
- reg:
- maxItems: 1
-
- next-level-cache: true
-
- memory-region:
- maxItems: 1
- description: |
- The reference to the reserved-memory for the L2 Loosely Integrated Memory region.
- The reserved memory node should be defined as per the bindings in reserved-memory.txt.
-
-allOf:
- - $ref: /schemas/cache-controller.yaml#
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - sifive,fu740-c000-ccache
- - microchip,mpfs-ccache
-
- then:
- properties:
- interrupts:
- description: |
- Must contain entries for DirError, DataError, DataFail, DirFail signals.
- minItems: 4
-
- else:
- properties:
- interrupts:
- description: |
- Must contain entries for DirError, DataError and DataFail signals.
- maxItems: 3
-
- - if:
- properties:
- compatible:
- contains:
- const: sifive,fu740-c000-ccache
-
- then:
- properties:
- cache-sets:
- const: 2048
-
- else:
- properties:
- cache-sets:
- const: 1024
-
-additionalProperties: false
-
-required:
- - compatible
- - cache-block-size
- - cache-level
- - cache-sets
- - cache-size
- - cache-unified
- - interrupts
- - reg
-
-examples:
- - |
- cache-controller@2010000 {
- compatible = "sifive,fu540-c000-ccache", "cache";
- cache-block-size = <64>;
- cache-level = <2>;
- cache-sets = <1024>;
- cache-size = <2097152>;
- cache-unified;
- reg = <0x2010000 0x1000>;
- interrupt-parent = <&plic0>;
- interrupts = <1>,
- <2>,
- <3>;
- next-level-cache = <&L25>;
- memory-region = <&l2_lim>;
- };
diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
new file mode 100644
index 000000000000..9c49482002f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/spacemit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT SoC-based boards
+
+maintainers:
+ - Yangyu Chen <cyy@cyyself.name>
+ - Yixun Lan <dlan@gentoo.org>
+
+description:
+ SpacemiT SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - bananapi,bpi-f3
+ - milkv,jupiter
+ - spacemit,musepi-pro
+ - xunlong,orangepi-r2s
+ - xunlong,orangepi-rv2
+ - const: spacemit,k1
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/starfive.yaml b/Documentation/devicetree/bindings/riscv/starfive.yaml
index 5b36243fd674..9253aab21518 100644
--- a/Documentation/devicetree/bindings/riscv/starfive.yaml
+++ b/Documentation/devicetree/bindings/riscv/starfive.yaml
@@ -19,9 +19,29 @@ properties:
compatible:
oneOf:
- items:
- - const: beagle,beaglev-starlight-jh7100-r0
+ - enum:
+ - beagle,beaglev-starlight-jh7100-r0
+ - starfive,visionfive-v1
- const: starfive,jh7100
+ - items:
+ - enum:
+ - deepcomputing,fml13v01
+ - milkv,mars
+ - milkv,marscm-emmc
+ - milkv,marscm-lite
+ - pine64,star64
+ - starfive,visionfive-2-v1.2a
+ - starfive,visionfive-2-v1.3b
+ - xunlong,orangepi-rv
+ - const: starfive,jh7110
+
+ - items:
+ - enum:
+ - starfive,visionfive-2-lite
+ - starfive,visionfive-2-lite-emmc
+ - const: starfive,jh7110s
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/riscv/sunxi.yaml b/Documentation/devicetree/bindings/riscv/sunxi.yaml
new file mode 100644
index 000000000000..b36e313e13a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sunxi.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sunxi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner RISC-V SoC-based boards
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Jernej Skrabec <jernej.skrabec@gmail.com>
+ - Samuel Holland <samuel@sholland.org>
+
+description:
+ Allwinner RISC-V SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Dongshan Nezha STU SoM
+ items:
+ - const: 100ask,dongshan-nezha-stu
+ - const: allwinner,sun20i-d1
+
+ - description: D1 Nezha board
+ items:
+ - const: allwinner,d1-nezha
+ - const: allwinner,sun20i-d1
+
+ - description: ClockworkPi R-01 SoM and v3.14 board
+ items:
+ - const: clockwork,r-01-clockworkpi-v3.14
+ - const: allwinner,sun20i-d1
+
+ - description: ClockworkPi R-01 SoM, v3.14 board, and DevTerm expansion
+ items:
+ - const: clockwork,r-01-devterm-v3.14
+ - const: clockwork,r-01-clockworkpi-v3.14
+ - const: allwinner,sun20i-d1
+
+ - description: Lichee RV SoM
+ items:
+ - const: sipeed,lichee-rv
+ - const: allwinner,sun20i-d1
+
+ - description: Carrier boards for the Lichee RV SoM
+ items:
+ - enum:
+ - sipeed,lichee-rv-86-panel-480p
+ - sipeed,lichee-rv-86-panel-720p
+ - sipeed,lichee-rv-dock
+ - const: sipeed,lichee-rv
+ - const: allwinner,sun20i-d1
+
+ - description: MangoPi MQ board
+ items:
+ - const: widora,mangopi-mq
+ - const: allwinner,sun20i-d1s
+
+ - description: MangoPi MQ Pro board
+ items:
+ - const: widora,mangopi-mq-pro
+ - const: allwinner,sun20i-d1
+
+ - description: MangoPi MQ-R board
+ items:
+ - const: widora,mangopi-mq-r-f133
+ - const: allwinner,sun20i-d1s
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/tenstorrent.yaml b/Documentation/devicetree/bindings/riscv/tenstorrent.yaml
new file mode 100644
index 000000000000..e15359b2aab6
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/tenstorrent.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/tenstorrent.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tenstorrent SoC-based boards
+
+maintainers:
+ - Drew Fustini <dfustini@oss.tenstorrent.com>
+ - Joel Stanley <jms@oss.tenstorrent.com>
+
+description:
+ Tenstorrent SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Tenstorrent Blackhole PCIe card
+ items:
+ - const: tenstorrent,blackhole-card
+ - const: tenstorrent,blackhole
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml
new file mode 100644
index 000000000000..301912dcd290
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/thead.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/thead.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: T-HEAD SoC-based boards
+
+maintainers:
+ - Jisheng Zhang <jszhang@kernel.org>
+
+description:
+ T-HEAD SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: BeagleV Ahead single board computer
+ items:
+ - const: beagle,beaglev-ahead
+ - const: thead,th1520
+ - description: Sipeed Lichee Pi 4A board for the Sipeed Lichee Module 4A
+ items:
+ - enum:
+ - sipeed,lichee-pi-4a
+ - const: sipeed,lichee-module-4a
+ - const: thead,th1520
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/rng/SUNW,n2-rng.yaml b/Documentation/devicetree/bindings/rng/SUNW,n2-rng.yaml
new file mode 100644
index 000000000000..6eafc532dc76
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/SUNW,n2-rng.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/SUNW,n2-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SUN UltraSPARC HWRNG
+
+maintainers:
+ - David S. Miller <davem@davemloft.net>
+
+properties:
+ compatible:
+ enum:
+ - SUNW,n2-rng # for Niagara 2 Platform (SUN UltraSPARC T2 CPU)
+ - SUNW,vf-rng # for Victoria Falls Platform (SUN UltraSPARC T2 Plus CPU)
+ # for Rainbow/Yosemite Falls Platform (SUN SPARC T3/T4),
+ # (UltraSPARC KT/Niagara 3 - development names)
+ # more recent systems (after Oracle acquisition of SUN)
+ - SUNW,kt-rng
+ - ORCL,m4-rng # for SPARC T5/M5
+ - ORCL,m7-rng # for SPARC T7/M7
+
+ reg:
+ maxItems: 1
+
+ "rng-#units":
+ description: Number of RNG units
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+# PS: see as well prtconfs.git by DaveM
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rng@e {
+ compatible = "ORCL,m4-rng";
+ reg = <0xe>;
+ rng-#units = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rng/airoha,en7581-trng.yaml b/Documentation/devicetree/bindings/rng/airoha,en7581-trng.yaml
new file mode 100644
index 000000000000..dfc6d24ee7d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/airoha,en7581-trng.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/airoha,en7581-trng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7851 True Random Number Generator
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+properties:
+ compatible:
+ const: airoha,en7581-trng
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rng@1faa1000 {
+ compatible = "airoha,en7581-trng";
+ reg = <0x1faa1000 0x1000>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
index 09c6c906b1f9..f03b87e1b01c 100644
--- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson Random number generator
@@ -14,6 +14,7 @@ properties:
compatible:
enum:
- amlogic,meson-rng
+ - amlogic,meson-s4-rng
reg:
maxItems: 1
@@ -25,6 +26,9 @@ properties:
items:
- const: core
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml
index 3ce45456d867..f78614100ea8 100644
--- a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml
+++ b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml
@@ -21,6 +21,11 @@ properties:
- enum:
- microchip,sama7g5-trng
- const: atmel,at91sam9g45-trng
+ - items:
+ - enum:
+ - microchip,sam9x7-trng
+ - microchip,sama7d65-trng
+ - const: microchip,sam9x60-trng
clocks:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm74110-rng.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm74110-rng.yaml
new file mode 100644
index 000000000000..8e89d4a70b53
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm74110-rng.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/brcm,bcm74110-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM74110 Random number generator
+
+description:
+ Random number generator used on the BCM74110.
+
+maintainers:
+ - Markus Mayer <mmayer@broadcom.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm74110-rng
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rng@83ba000 {
+ compatible = "brcm,bcm74110-rng";
+ reg = <0x83ba000 0x14>;
+ };
diff --git a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml
index a00e9bc8b609..817cbdaa2b2d 100644
--- a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml
+++ b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/rng/brcm,iproc-rng200.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/rng/brcm,iproc-rng200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HWRNG support for the iproc-rng200 driver
@@ -20,11 +20,17 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
additionalProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
rng@18032000 {
compatible = "brcm,iproc-rng200";
reg = <0x18032000 0x28>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
};
diff --git a/Documentation/devicetree/bindings/rng/hisi-rng.txt b/Documentation/devicetree/bindings/rng/hisi-rng.txt
deleted file mode 100644
index d04d55a6c2f5..000000000000
--- a/Documentation/devicetree/bindings/rng/hisi-rng.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Hisilicon Random Number Generator
-
-Required properties:
-- compatible : Should be "hisilicon,hip04-rng" or "hisilicon,hip05-rng"
-- reg : Offset and length of the register set of this block
-
-Example:
-
-rng@d1010000 {
- compatible = "hisilicon,hip05-rng";
- reg = <0xd1010000 0x100>;
-};
diff --git a/Documentation/devicetree/bindings/rng/hisi-rng.yaml b/Documentation/devicetree/bindings/rng/hisi-rng.yaml
new file mode 100644
index 000000000000..5406b2596f42
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/hisi-rng.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/hisi-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon Random Number Generator
+
+maintainers:
+ - Kefeng Wang <wangkefeng.wang@huawei>
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,hip04-rng
+ - hisilicon,hip05-rng
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rng@d1010000 {
+ compatible = "hisilicon,hip05-rng";
+ reg = <0xd1010000 0x100>;
+ };
diff --git a/Documentation/devicetree/bindings/rng/imx-rng.yaml b/Documentation/devicetree/bindings/rng/imx-rng.yaml
index 07f6ff89bcc1..252fa9a41abe 100644
--- a/Documentation/devicetree/bindings/rng/imx-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/imx-rng.yaml
@@ -14,8 +14,8 @@ properties:
oneOf:
- const: fsl,imx21-rnga
- const: fsl,imx25-rngb
+ - const: fsl,imx31-rnga
- items:
- - const: fsl,imx31-rnga
- const: fsl,imx21-rnga
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/rng/ingenic,rng.yaml b/Documentation/devicetree/bindings/rng/ingenic,rng.yaml
index b2e4a6a7f93a..79a023cbfdba 100644
--- a/Documentation/devicetree/bindings/rng/ingenic,rng.yaml
+++ b/Documentation/devicetree/bindings/rng/ingenic,rng.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rng/ingenic,rng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for RNG in Ingenic SoCs
+title: RNG in Ingenic SoCs
maintainers:
- 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
diff --git a/Documentation/devicetree/bindings/rng/ingenic,trng.yaml b/Documentation/devicetree/bindings/rng/ingenic,trng.yaml
index 044d9a065650..acaeb63caf24 100644
--- a/Documentation/devicetree/bindings/rng/ingenic,trng.yaml
+++ b/Documentation/devicetree/bindings/rng/ingenic,trng.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rng/ingenic,trng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for DTRNG in Ingenic SoCs
+title: DTRNG in Ingenic SoCs
maintainers:
- 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
diff --git a/Documentation/devicetree/bindings/rng/inside-secure,safexcel-eip76.yaml b/Documentation/devicetree/bindings/rng/inside-secure,safexcel-eip76.yaml
new file mode 100644
index 000000000000..f501fc7691c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/inside-secure,safexcel-eip76.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/inside-secure,safexcel-eip76.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Inside-Secure HWRNG Module
+
+maintainers:
+ - Jayesh Choudhary <j-choudhary@ti.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - ti,omap2-rng
+ - ti,omap4-rng
+ - inside-secure,safexcel-eip76
+ - items:
+ - enum:
+ - marvell,armada-8k-rng
+ - const: inside-secure,safexcel-eip76
+
+ ti,hwmods:
+ const: rng
+ deprecated: true
+ description: Name of the hwmod associated with the RNG module
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: EIP150 gateable clock
+ - description: Main gateable clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,omap4-rng
+ - inside-secure,safexcel-eip76
+
+ then:
+ required:
+ - interrupts
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ /* AM335x */
+ rng: rng@48310000 {
+ compatible = "ti,omap4-rng";
+ ti,hwmods = "rng";
+ reg = <0x48310000 0x2000>;
+ interrupts = <111>;
+ };
+ - |
+ /* SafeXcel IP-76 */
+ trng: rng@f2760000 {
+ compatible = "inside-secure,safexcel-eip76";
+ reg = <0xf2760000 0x7d>;
+ interrupts = <0 59 4>;
+ clocks = <&cpm_syscon0 1 25>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml b/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml
index 067e71e8ebe8..9f7590ce6b3d 100644
--- a/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/intel,ixp46x-rng.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rng/intel,ixp46x-rng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel IXP46x RNG bindings
+title: Intel IXP46x RNG
description: |
The Intel IXP46x has a random number generator at a fixed physical
diff --git a/Documentation/devicetree/bindings/rng/microchip,pic32-rng.txt b/Documentation/devicetree/bindings/rng/microchip,pic32-rng.txt
deleted file mode 100644
index c6d1003befb7..000000000000
--- a/Documentation/devicetree/bindings/rng/microchip,pic32-rng.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Microchip PIC32 Random Number Generator
-
-The PIC32 RNG provides a pseudo random number generator which can be seeded by
-another true random number generator.
-
-Required properties:
-- compatible : should be "microchip,pic32mzda-rng"
-- reg : Specifies base physical address and size of the registers.
-- clocks: clock phandle.
-
-Example:
-
- rng: rng@1f8e6000 {
- compatible = "microchip,pic32mzda-rng";
- reg = <0x1f8e6000 0x1000>;
- clocks = <&PBCLK5>;
- };
diff --git a/Documentation/devicetree/bindings/rng/microchip,pic32-rng.yaml b/Documentation/devicetree/bindings/rng/microchip,pic32-rng.yaml
new file mode 100644
index 000000000000..1f6f6fb81ddc
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/microchip,pic32-rng.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/microchip,pic32-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 Random Number Generator
+
+description: |
+ The PIC32 RNG provides a pseudo random number generator which can be seeded
+ by another true random number generator.
+
+maintainers:
+ - Joshua Henderson <joshua.henderson@microchip.com>
+
+properties:
+ compatible:
+ enum:
+ - microchip,pic32mzda-rng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ rng: rng@1f8e6000 {
+ compatible = "microchip,pic32mzda-rng";
+ reg = <0x1f8e6000 0x1000>;
+ clocks = <&PBCLK5>;
+ };
diff --git a/Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml b/Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml
new file mode 100644
index 000000000000..8f20dee93e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/microsoft,vmgenid.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/microsoft,vmgenid.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Virtual Machine Generation ID
+
+maintainers:
+ - Jason A. Donenfeld <Jason@zx2c4.com>
+
+description:
+ Firmwares or hypervisors can use this devicetree to describe an
+ interrupt and a shared resource to inject a Virtual Machine Generation ID.
+ Virtual Machine Generation ID is a globally unique identifier (GUID) and
+ the devicetree binding follows VMGenID specification defined in
+ http://go.microsoft.com/fwlink/?LinkId=260709.
+
+properties:
+ compatible:
+ const: microsoft,vmgenid
+
+ reg:
+ description:
+ Specifies a 16-byte VMGenID in endianness-agnostic hexadecimal format.
+ maxItems: 1
+
+ interrupts:
+ description:
+ Interrupt used to notify that a new VMGenID is available.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ rng@80000000 {
+ compatible = "microsoft,vmgenid";
+ reg = <0x80000000 0x1000>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
index bb32491ee8ae..7e8dc62e5d3a 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/rng/mtk-rng.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/rng/mtk-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Random number generator
diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml
index abd134c9d400..e8e4ab1e5b95 100644
--- a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml
@@ -16,7 +16,9 @@ maintainers:
properties:
compatible:
- const: nuvoton,npcm750-rng
+ enum:
+ - nuvoton,npcm750-rng
+ - nuvoton,npcm845-rng
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.yaml b/Documentation/devicetree/bindings/rng/omap_rng.yaml
deleted file mode 100644
index 010188cdbec8..000000000000
--- a/Documentation/devicetree/bindings/rng/omap_rng.yaml
+++ /dev/null
@@ -1,92 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/rng/omap_rng.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: OMAP SoC and Inside-Secure HWRNG Module
-
-maintainers:
- - Jayesh Choudhary <j-choudhary@ti.com>
-
-properties:
- compatible:
- enum:
- - ti,omap2-rng
- - ti,omap4-rng
- - inside-secure,safexcel-eip76
-
- ti,hwmods:
- const: rng
- deprecated: true
- description: Name of the hwmod associated with the RNG module
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- minItems: 1
- items:
- - description: EIP150 gatable clock
- - description: Main gatable clock
-
- clock-names:
- minItems: 1
- items:
- - const: core
- - const: reg
-
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - ti,omap4-rng
- - inside-secure,safexcel-eip76
-
- then:
- required:
- - interrupts
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - inside-secure,safexcel-eip76
-
- then:
- required:
- - clocks
-
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- /* AM335x */
- rng: rng@48310000 {
- compatible = "ti,omap4-rng";
- ti,hwmods = "rng";
- reg = <0x48310000 0x2000>;
- interrupts = <111>;
- };
- - |
- /* SafeXcel IP-76 */
- trng: rng@f2760000 {
- compatible = "inside-secure,safexcel-eip76";
- reg = <0xf2760000 0x7d>;
- interrupts = <0 59 4>;
- clocks = <&cpm_syscon0 1 25>;
- };
-
-...
diff --git a/Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml b/Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
new file mode 100644
index 000000000000..e0595814a6d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/rockchip,rk3568-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3568 TRNG
+
+description: True Random Number Generator on Rockchip RK3568 SoC
+
+maintainers:
+ - Aurelien Jarno <aurelien@aurel32.net>
+ - Daniel Golle <daniel@makrotopia.org>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3568-rng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TRNG clock
+ - description: TRNG AHB clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: ahb
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3568-cru.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ rng@fe388000 {
+ compatible = "rockchip,rk3568-rng";
+ reg = <0x0 0xfe388000 0x0 0x4000>;
+ clocks = <&cru CLK_TRNG_NS>, <&cru HCLK_TRNG_NS>;
+ clock-names = "core", "ahb";
+ resets = <&cru SRST_TRNG_NS>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml b/Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml
new file mode 100644
index 000000000000..fcc5be80142d
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/rockchip,rk3588-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3576/RK3588 TRNG
+
+description: True Random Number Generator on Rockchip RK3576/RK3588 SoCs
+
+maintainers:
+ - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3576-rng
+ - rockchip,rk3588-rng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TRNG AHB clock
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: 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/reset/rockchip,rk3588-cru.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ rng@fe378000 {
+ compatible = "rockchip,rk3588-rng";
+ reg = <0x0 0xfe378000 0x0 0x200>;
+ interrupts = <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&scmi_clk SCMI_HCLK_SECURE_NS>;
+ resets = <&scmi_reset SCMI_SRST_H_TRNG_NS>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml
index 765d9f9edd6e..1a71935d8a19 100644
--- a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml
+++ b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml
@@ -12,14 +12,17 @@ maintainers:
properties:
compatible:
- const: samsung,exynos5250-trng
+ enum:
+ - samsung,exynos5250-trng
+ - samsung,exynos850-trng
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
clock-names:
- items:
- - const: secss
+ minItems: 1
+ maxItems: 2
reg:
maxItems: 1
@@ -30,6 +33,35 @@ required:
- clock-names
- reg
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos850-trng
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: SSS (Security Sub System) operating clock
+ - description: SSS (Security Sub System) bus clock
+
+ clock-names:
+ items:
+ - const: secss
+ - const: pclk
+
+ else:
+ properties:
+ clocks:
+ items:
+ - description: SSS (Security Sub System) operating clock
+
+ clock-names:
+ items:
+ - const: secss
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml b/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
index 48ab82abf50e..4673d6160ad9 100644
--- a/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rng/silex-insight,ba431-rng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Silex Insight BA431 RNG bindings
+title: Silex Insight BA431 RNG
description: |
The BA431 hardware random number generator is an IP that is FIPS-140-2/3
diff --git a/Documentation/devicetree/bindings/rng/sparc_sun_oracle_rng.txt b/Documentation/devicetree/bindings/rng/sparc_sun_oracle_rng.txt
deleted file mode 100644
index b0b211194c71..000000000000
--- a/Documentation/devicetree/bindings/rng/sparc_sun_oracle_rng.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-HWRNG support for the n2_rng driver
-
-Required properties:
-- reg : base address to sample from
-- compatible : should contain one of the following
- RNG versions:
- - 'SUNW,n2-rng' for Niagara 2 Platform (SUN UltraSPARC T2 CPU)
- - 'SUNW,vf-rng' for Victoria Falls Platform (SUN UltraSPARC T2 Plus CPU)
- - 'SUNW,kt-rng' for Rainbow/Yosemite Falls Platform (SUN SPARC T3/T4), (UltraSPARC KT/Niagara 3 - development names)
- more recent systems (after Oracle acquisition of SUN)
- - 'ORCL,m4-rng' for SPARC T5/M5
- - 'ORCL,m7-rng' for SPARC T7/M7
-
-Examples:
-/* linux LDOM on SPARC T5-2 */
-Node 0xf029a4f4
- .node: f029a4f4
- rng-#units: 00000002
- compatible: 'ORCL,m4-rng'
- reg: 0000000e
- name: 'random-number-generator'
-
-/* solaris on SPARC M7-8 */
-Node 0xf028c08c
- rng-#units: 00000003
- compatible: 'ORCL,m7-rng'
- reg: 0000000e
- name: 'random-number-generator'
-
-PS: see as well prtconfs.git by DaveM
diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
index fcd86f822a9c..7db65f49773b 100644
--- a/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rng/st,stm32-rng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 RNG bindings
+title: STMicroelectronics STM32 RNG
description: |
The STM32 hardware random number generator is a simple fixed purpose
@@ -15,13 +15,22 @@ maintainers:
properties:
compatible:
- const: st,stm32-rng
+ enum:
+ - st,stm32-rng
+ - st,stm32mp13-rng
+ - st,stm32mp25-rng
reg:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
resets:
maxItems: 1
@@ -30,11 +39,50 @@ properties:
type: boolean
description: If set enable the clock detection management
+ st,rng-lock-conf:
+ type: boolean
+ description: If set, the RNG configuration in RNG_CR, RNG_HTCR and
+ RNG_NSCR will be locked.
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
- clocks
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32-rng
+ then:
+ properties:
+ st,rng-lock-conf: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - st,stm32-rng
+ - st,stm32mp13-rng
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names: false
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ required:
+ - clock-names
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml b/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
new file mode 100644
index 000000000000..4639247e9e51
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/starfive,jh7110-trng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive SoC TRNG Module
+
+maintainers:
+ - Jia Jie Ho <jiajie.ho@starfivetech.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: starfive,jh8100-trng
+ - const: starfive,jh7110-trng
+ - const: starfive,jh7110-trng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Hardware reference clock
+ - description: AHB reference clock
+
+ clock-names:
+ items:
+ - const: hclk
+ - const: ahb
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ rng: rng@1600C000 {
+ compatible = "starfive,jh7110-trng";
+ reg = <0x1600C000 0x4000>;
+ clocks = <&clk 15>, <&clk 16>;
+ clock-names = "hclk", "ahb";
+ resets = <&reset 3>;
+ interrupts = <30>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml b/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml
index e749818fc193..06a6791b3356 100644
--- a/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml
+++ b/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml
@@ -25,7 +25,7 @@ properties:
maxItems: 1
ti,syscon-sa-cfg:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Phandle to syscon node of the SA configuration registers. These
registers are shared between HWRNG and crypto drivers.
diff --git a/Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml b/Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml
index 1e17e55762f1..d83132291170 100644
--- a/Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml
+++ b/Documentation/devicetree/bindings/rng/xiphera,xip8001b-trng.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rng/xiphera,xip8001b-trng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xiphera XIP8001B-trng bindings
+title: Xiphera XIP8001B-trng
maintainers:
- Atte Tommiska <atte.tommiska@xiphera.com>
diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt
deleted file mode 100644
index 2405e35a1bc0..000000000000
--- a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Abracon ABX80X I2C ultra low power RTC/Alarm chip
-
-The Abracon ABX80X family consist of the ab0801, ab0803, ab0804, ab0805, ab1801,
-ab1803, ab1804 and ab1805. The ab0805 is the superset of ab080x and the ab1805
-is the superset of ab180x.
-
-Required properties:
-
- - "compatible": should one of:
- "abracon,abx80x"
- "abracon,ab0801"
- "abracon,ab0803"
- "abracon,ab0804"
- "abracon,ab0805"
- "abracon,ab1801"
- "abracon,ab1803"
- "abracon,ab1804"
- "abracon,ab1805"
- "microcrystal,rv1805"
- Using "abracon,abx80x" will enable chip autodetection.
- - "reg": I2C bus address of the device
-
-Optional properties:
-
-The abx804 and abx805 have a trickle charger that is able to charge the
-connected battery or supercap. Both the following properties have to be defined
-and valid to enable charging:
-
- - "abracon,tc-diode": should be "standard" (0.6V) or "schottky" (0.3V)
- - "abracon,tc-resistor": should be <0>, <3>, <6> or <11>. 0 disables the output
- resistor, the other values are in kOhm.
diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
new file mode 100644
index 000000000000..355b0598411a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Abracon ABX80X I2C ultra low power RTC/Alarm chip
+
+maintainers:
+ - linux-rtc@vger.kernel.org
+
+properties:
+ compatible:
+ description:
+ The wildcard 'abracon,abx80x' may be used to support a mix
+ of different abracon rtc`s. In this case the driver
+ must perform auto-detection from ID register.
+ enum:
+ - abracon,abx80x
+ - abracon,ab0801
+ - abracon,ab0803
+ - abracon,ab0804
+ - abracon,ab0805
+ - abracon,ab1801
+ - abracon,ab1803
+ - abracon,ab1804
+ - abracon,ab1805
+ - microcrystal,rv1805
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ abracon,tc-diode:
+ description:
+ Trickle-charge diode type.
+ Required to enable charging backup battery.
+
+ Supported are 'standard' diodes with a 0.6V drop
+ and 'schottky' diodes with a 0.3V drop.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - standard
+ - schottky
+
+ abracon,tc-resistor:
+ description:
+ Trickle-charge resistor value in kOhm.
+ Required to enable charging backup battery.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 3, 6, 11]
+
+dependentRequired:
+ abracon,tc-diode: ["abracon,tc-resistor"]
+ abracon,tc-resistor: ["abracon,tc-diode"]
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: rtc.yaml#
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - abracon,abx80x
+ - abracon,ab0804
+ - abracon,ab1804
+ - abracon,ab0805
+ - abracon,ab1805
+ then:
+ properties:
+ abracon,tc-diode: false
+ abracon,tc-resistor: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@69 {
+ compatible = "abracon,abx80x";
+ reg = <0x69>;
+ abracon,tc-diode = "schottky";
+ abracon,tc-resistor = <3>;
+ interrupts = <44 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/adi,max31335.yaml b/Documentation/devicetree/bindings/rtc/adi,max31335.yaml
new file mode 100644
index 000000000000..bce7558d0d87
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/adi,max31335.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/adi,max31335.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX31335 RTC
+
+maintainers:
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description:
+ Analog Devices MAX31335 I2C RTC ±2ppm Automotive Real-Time Clock with
+ Integrated MEMS Resonator.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,max31331
+ - adi,max31335
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#clock-cells":
+ description:
+ RTC can be used as a clock source through its clock output pin.
+ const: 0
+
+ adi,tc-diode:
+ description:
+ Select the diode configuration for the trickle charger.
+ schottky - Schottky diode in series.
+ standard+schottky - standard diode + Schottky diode in series.
+ enum: [schottky, standard+schottky]
+
+ trickle-resistor-ohms:
+ description:
+ Selected resistor for trickle charger. Should be specified if trickle
+ charger should be enabled.
+ enum: [3000, 6000, 11000]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@68 {
+ compatible = "adi,max31335";
+ reg = <0x68>;
+ pinctrl-0 = <&rtc_nint_pins>;
+ interrupts-extended = <&gpio1 16 IRQ_TYPE_LEVEL_HIGH>;
+ aux-voltage-chargeable = <1>;
+ trickle-resistor-ohms = <6000>;
+ adi,tc-diode = "schottky";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml
index 478b0234e8fa..054e1e397fc8 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/rtc/allwinner,sun4i-a10-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 RTC Device Tree Bindings
+title: Allwinner A10 RTC
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index 6b38bd7eb3b4..9df5cdb6f63f 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/allwinner,sun6i-a31-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 RTC Device Tree Bindings
+title: Allwinner A31 RTC
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -30,7 +30,9 @@ properties:
- const: allwinner,sun50i-a64-rtc
- const: allwinner,sun8i-h3-rtc
- items:
- - const: allwinner,sun20i-d1-rtc
+ - enum:
+ - allwinner,sun20i-d1-rtc
+ - allwinner,sun55i-a523-rtc
- const: allwinner,sun50i-r329-rtc
reg:
@@ -61,7 +63,7 @@ properties:
- the Internal Oscillator, at index 2.
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
- if:
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt
deleted file mode 100644
index 76ebca568db9..000000000000
--- a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Alphascale asm9260 SoC Real Time Clock
-
-Required properties:
-- compatible: Should be "alphascale,asm9260-rtc"
-- reg: Physical base address of the controller and length
- of memory mapped region.
-- interrupts: IRQ line for the RTC.
-- clocks: Reference to the clock entry.
-- clock-names: should contain:
- * "ahb" for the SoC RTC clock
-
-Example:
-rtc0: rtc@800a0000 {
- compatible = "alphascale,asm9260-rtc";
- reg = <0x800a0000 0x100>;
- clocks = <&acc CLKID_AHB_RTC>;
- clock-names = "ahb";
- interrupts = <2>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml
new file mode 100644
index 000000000000..f955a7f638ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/alphascale,asm9260-rtc.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/alphascale,asm9260-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Alphascale asm9260 SoC Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: alphascale,asm9260-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ahb
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/alphascale,asm9260.h>
+
+ rtc@800a0000 {
+ compatible = "alphascale,asm9260-rtc";
+ reg = <0x800a0000 0x100>;
+ clocks = <&acc CLKID_AHB_RTC>;
+ clock-names = "ahb";
+ interrupts = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/amlogic,a4-rtc.yaml b/Documentation/devicetree/bindings/rtc/amlogic,a4-rtc.yaml
new file mode 100644
index 000000000000..e61f22eca85b
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/amlogic,a4-rtc.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/amlogic,a4-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A4 and A5 RTC
+
+maintainers:
+ - Yiting Deng <yiting.deng@amlogic.com>
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,a4-rtc
+ - amlogic,a5-rtc
+ - items:
+ - enum:
+ - amlogic,c3-rtc
+ - const: amlogic,a5-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: RTC clock source, available 24M or 32K crystal
+ oscillator source. when using 24M, need to divide 24M into 32K.
+ - description: RTC module accesses the clock of the apb bus.
+
+ clock-names:
+ items:
+ - const: osc
+ - const: sys
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ apb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ rtc@8e600 {
+ compatible = "amlogic,a4-rtc";
+ reg = <0x0 0x8e600 0x0 0x38>;
+ clocks = <&xtal_32k>, <&clkc_periphs 1>;
+ clock-names = "osc", "sys";
+ interrupts = <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml b/Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml
new file mode 100644
index 000000000000..a89865fa676a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/amlogic,meson-vrtc.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/amlogic,meson-vrtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Virtual RTC (VRTC)
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ This is a Linux interface to an RTC managed by firmware, hence it's
+ virtual from a Linux perspective. The interface is 1 register where
+ an alarm time (in seconds) is to be written.
+ The alarm register is a simple scratch register shared between the
+ application processors (AP) and the secure co-processor (SCP.) When
+ the AP suspends, the SCP will use the value of this register to
+ program an always-on timer before going sleep. When the timer expires,
+ the SCP will wake up and will then wake the AP.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-vrtc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc@a8 {
+ compatible = "amlogic,meson-vrtc";
+ reg = <0x000a8 0x4>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/amlogic,meson6-rtc.yaml b/Documentation/devicetree/bindings/rtc/amlogic,meson6-rtc.yaml
new file mode 100644
index 000000000000..3a4551253e3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/amlogic,meson6-rtc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/amlogic,meson6-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson6, Meson8, Meson8b and Meson8m2 RTC
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+ - $ref: /schemas/nvmem/nvmem.yaml#
+ - $ref: /schemas/nvmem/nvmem-deprecated-cells.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson6-rtc
+ - amlogic,meson8-rtc
+ - amlogic,meson8b-rtc
+ - amlogic,meson8m2-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ vdd-supply: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ rtc: rtc@740 {
+ compatible = "amlogic,meson6-rtc";
+ reg = <0x740 0x14>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&rtc32k_xtal>;
+ vdd-supply = <&rtc_vdd>;
+ resets = <&reset_rtc>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac@0 {
+ reg = <0 6>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/apm,xgene-rtc.yaml b/Documentation/devicetree/bindings/rtc/apm,xgene-rtc.yaml
new file mode 100644
index 000000000000..b8f46536fd5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/apm,xgene-rtc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/apm,xgene-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: APM X-Gene Real Time Clock
+
+maintainers:
+ - Khuong Dinh <khuong@os.amperecomputing.com>
+
+properties:
+ compatible:
+ const: apm,xgene-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#clock-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc@10510000 {
+ compatible = "apm,xgene-rtc";
+ reg = <0x10510000 0x400>;
+ interrupts = <0x0 0x46 0x4>;
+ #clock-cells = <1>;
+ clocks = <&rtcclk 0>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt b/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
deleted file mode 100644
index c3c9a1226f9a..000000000000
--- a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Real Time Clock of the Armada 38x/7K/8K SoCs
-
-RTC controller for the Armada 38x, 7K and 8K SoCs
-
-Required properties:
-- compatible : Should be one of the following:
- "marvell,armada-380-rtc" for Armada 38x SoC
- "marvell,armada-8k-rtc" for Aramda 7K/8K SoCs
-- reg: a list of base address and size pairs, one for each entry in
- reg-names
-- reg names: should contain:
- * "rtc" for the RTC registers
- * "rtc-soc" for the SoC related registers and among them the one
- related to the interrupt.
-- interrupts: IRQ line for the RTC.
-
-Example:
-
-rtc@a3800 {
- compatible = "marvell,armada-380-rtc";
- reg = <0xa3800 0x20>, <0x184a0 0x0c>;
- reg-names = "rtc", "rtc-soc";
- interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml
index 994de43d17fa..7c5b13caa40b 100644
--- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml
@@ -4,23 +4,29 @@
$id: http://devicetree.org/schemas/rtc/atmel,at91rm9200-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Atmel AT91 RTC Device Tree Bindings
+title: Atmel AT91 RTC
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
properties:
compatible:
- enum:
- - atmel,at91rm9200-rtc
- - atmel,at91sam9x5-rtc
- - atmel,sama5d4-rtc
- - atmel,sama5d2-rtc
- - microchip,sam9x60-rtc
- - microchip,sama7g5-rtc
+ oneOf:
+ - enum:
+ - atmel,at91rm9200-rtc
+ - atmel,at91sam9x5-rtc
+ - atmel,sama5d4-rtc
+ - atmel,sama5d2-rtc
+ - microchip,sam9x60-rtc
+ - microchip,sama7g5-rtc
+ - items:
+ - enum:
+ - microchip,sam9x7-rtc
+ - microchip,sama7d65-rtc
+ - const: microchip,sam9x60-rtc
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml
index 0ef1b7ff4a77..9c9b981fe38b 100644
--- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml
@@ -5,10 +5,10 @@
$id: http://devicetree.org/schemas/rtc/atmel,at91sam9260-rtt.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Atmel AT91 RTT Device Tree Bindings
+title: Atmel AT91 RTT
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
@@ -19,7 +19,10 @@ properties:
- items:
- const: atmel,at91sam9260-rtt
- items:
- - const: microchip,sam9x60-rtt
+ - enum:
+ - microchip,sam9x60-rtt
+ - microchip,sam9x7-rtt
+ - microchip,sama7d65-rtt
- const: atmel,at91sam9260-rtt
- items:
- const: microchip,sama7g5-rtt
diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml
index 9fe079917a98..c5e5c5aec74e 100644
--- a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml
+++ b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml
@@ -11,10 +11,11 @@ maintainers:
description:
The Broadcom STB wake-up timer provides a 27Mhz resolution timer, with the
- ability to wake up the system from low-power suspend/standby modes.
+ ability to wake up the system from low-power suspend/standby modes and
+ optionally generate RTC alarm interrupts.
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
properties:
compatible:
@@ -24,8 +25,14 @@ properties:
maxItems: 1
interrupts:
- description: the TIMER interrupt
- maxItems: 1
+ minItems: 1
+ items:
+ - description: the TIMER interrupt
+ - description: the ALARM interrupt
+ description:
+ The TIMER interrupt wakes the system from low-power suspend/standby modes.
+ An ALARM interrupt may be specified to interrupt the CPU when an RTC alarm
+ is enabled.
clocks:
description: clock reference in the 27MHz domain
@@ -35,10 +42,10 @@ additionalProperties: false
examples:
- |
- rtc@f0411580 {
+ rtc@f041a080 {
compatible = "brcm,brcmstb-waketimer";
- reg = <0xf0411580 0x14>;
- interrupts = <0x3>;
- interrupt-parent = <&aon_pm_l2_intc>;
+ reg = <0xf041a080 0x14>;
+ interrupts-extended = <&aon_pm_l2_intc 0x04>,
+ <&upg_aux_aon_intr2_intc 0x08>;
clocks = <&upg_fixed>;
};
diff --git a/Documentation/devicetree/bindings/rtc/cirrus,ep9301-rtc.yaml b/Documentation/devicetree/bindings/rtc/cirrus,ep9301-rtc.yaml
new file mode 100644
index 000000000000..a95f6af2b1c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/cirrus,ep9301-rtc.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/cirrus,ep9301-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus EP93xx Real Time Clock controller
+
+maintainers:
+ - Hartley Sweeten <hsweeten@visionengravers.com>
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-rtc
+ - items:
+ - enum:
+ - cirrus,ep9302-rtc
+ - cirrus,ep9307-rtc
+ - cirrus,ep9312-rtc
+ - cirrus,ep9315-rtc
+ - const: cirrus,ep9301-rtc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@80920000 {
+ compatible = "cirrus,ep9301-rtc";
+ reg = <0x80920000 0x100>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt b/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt
deleted file mode 100644
index d464986012cd..000000000000
--- a/Documentation/devicetree/bindings/rtc/digicolor-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Conexant Digicolor Real Time Clock controller
-
-This binding currently supports the CX92755 SoC.
-
-Required properties:
-- compatible: should be "cnxt,cx92755-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: rtc alarm interrupt
-
-Example:
-
- rtc@f0000c30 {
- compatible = "cnxt,cx92755-rtc";
- reg = <0xf0000c30 0x18>;
- interrupts = <25>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/epson,rtc7301.txt b/Documentation/devicetree/bindings/rtc/epson,rtc7301.txt
deleted file mode 100644
index 5f9df3f1467c..000000000000
--- a/Documentation/devicetree/bindings/rtc/epson,rtc7301.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-EPSON TOYOCOM RTC-7301SF/DG
-
-Required properties:
-
-- compatible: Should be "epson,rtc7301sf" or "epson,rtc7301dg"
-- reg: Specifies base physical address and size of the registers.
-- interrupts: A single interrupt specifier.
-
-Example:
-
-rtc: rtc@44a00000 {
- compatible = "epson,rtc7301dg";
- reg = <0x44a00000 0x10000>;
- interrupt-parent = <&axi_intc_0>;
- interrupts = <3 2>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/epson,rtc7301.yaml b/Documentation/devicetree/bindings/rtc/epson,rtc7301.yaml
new file mode 100644
index 000000000000..bdb5cadb31cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/epson,rtc7301.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/epson,rtc7301.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Epson Toyocom RTC-7301SF/DG
+
+description:
+ The only difference between the two variants is the packaging.
+ The DG variant is a DIL package, and the SF variant is a flat
+ package.
+
+maintainers:
+ - Akinobu Mita <akinobu.mita@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - epson,rtc7301dg
+ - epson,rtc7301sf
+
+ reg:
+ maxItems: 1
+
+ reg-io-width:
+ description:
+ The size (in bytes) of the IO accesses that should be performed
+ on the device.
+ enum: [1, 4]
+ default: 4
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ rtc: rtc@44a00000 {
+ compatible = "epson,rtc7301dg";
+ reg = <0x44a00000 0x10000>;
+ reg-io-width = <4>;
+ interrupt-parent = <&axi_intc_0>;
+ interrupts = <3 2>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml b/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml
index d12855e7ffd7..b770149c5fd6 100644
--- a/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml
+++ b/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/epson,rx8900.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: EPSON RX8900 / Microcrystal RV8803 Real-Time Clock DT bindings
+title: EPSON RX8900 / Microcrystal RV8803 Real-Time Clock
maintainers:
- Marek Vasut <marex@denx.de>
@@ -29,6 +29,8 @@ properties:
trickle-diode-disable: true
+ wakeup-source: true
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
index 056d42daae06..b1c1a0e21318 100644
--- a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
+++ b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml
@@ -38,8 +38,8 @@ properties:
clock-names:
items:
- - const: "PCLK"
- - const: "EXTCLK"
+ - const: PCLK
+ - const: EXTCLK
required:
- compatible
diff --git a/Documentation/devicetree/bindings/rtc/fsl,ls-ftm-alarm.yaml b/Documentation/devicetree/bindings/rtc/fsl,ls-ftm-alarm.yaml
new file mode 100644
index 000000000000..3ec111f2fdc4
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/fsl,ls-ftm-alarm.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/fsl,ls-ftm-alarm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale FlexTimer Module (FTM) Alarm
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls1012a-ftm-alarm
+ - fsl,ls1021a-ftm-alarm
+ - fsl,ls1028a-ftm-alarm
+ - fsl,ls1043a-ftm-alarm
+ - fsl,ls1046a-ftm-alarm
+ - fsl,ls1088a-ftm-alarm
+ - fsl,ls208xa-ftm-alarm
+ - fsl,lx2160a-ftm-alarm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,rcpm-wakeup:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to rcpm node
+ - description: bit mask of IPPDEXPCR0
+ - description: bit mask of IPPDEXPCR1
+ - description: bit mask of IPPDEXPCR2
+ - description: bit mask of IPPDEXPCR3
+ - description: bit mask of IPPDEXPCR4
+ - description: bit mask of IPPDEXPCR5
+ - description: bit mask of IPPDEXPCR6
+ minItems: 1
+ description:
+ phandle to rcpm node, Please refer
+ Documentation/devicetree/bindings/soc/fsl/fsl,rcpm.yaml
+
+ big-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If the host controller is big-endian mode, specify this property.
+ The default endian mode is little-endian.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,rcpm-wakeup
+
+allOf:
+ - $ref: rtc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rtc@2800000 {
+ compatible = "fsl,ls1088a-ftm-alarm";
+ reg = <0x2800000 0x10000>;
+ fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml b/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml
index 8c102b70d735..dd1b1abf1e1b 100644
--- a/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/fsl,scu-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - RTC bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - RTC Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
diff --git a/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml
new file mode 100644
index 000000000000..534de4196a4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/fsl,stmp3xxx-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMP3xxx/i.MX28 Time Clock Controller
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx28-rtc
+ - fsl,imx23-rtc
+ - const: fsl,stmp3xxx-rtc
+ - const: fsl,stmp3xxx-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ stmp,crystal-freq:
+ description:
+ Override crystal frequency as determined from fuse bits.
+ Use <0> for "no crystal".
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 32000, 32768]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@80056000 {
+ compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc";
+ reg = <0x80056000 2000>;
+ interrupts = <29>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt b/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
deleted file mode 100644
index 634312dd95ca..000000000000
--- a/Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Android Goldfish RTC
-
-Android Goldfish RTC device used by Android emulator.
-
-Required properties:
-
-- compatible : should contain "google,goldfish-rtc"
-- reg : <registers mapping>
-- interrupts : <interrupt mapping>
-
-Example:
-
- goldfish_timer@9020000 {
- compatible = "google,goldfish-rtc";
- reg = <0x9020000 0x1000>;
- interrupts = <0x3>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
deleted file mode 100644
index a8934fe2ab4c..000000000000
--- a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Haoyu Microelectronics HYM8563 Real Time Clock
-
-The HYM8563 provides basic rtc and alarm functionality
-as well as a clock output of up to 32kHz.
-
-Required properties:
-- compatible: should be: "haoyu,hym8563"
-- reg: i2c address
-- #clock-cells: the value should be 0
-
-Optional properties:
-- clock-output-names: From common clock binding
-- interrupts: rtc alarm/event interrupt
-
-Example:
-
-hym8563: hym8563@51 {
- compatible = "haoyu,hym8563";
- reg = <0x51>;
-
- interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
-
- #clock-cells = <0>;
-};
-
-device {
-...
- clocks = <&hym8563>;
-...
-};
diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml
new file mode 100644
index 000000000000..0b9f39ef0edc
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/haoyu,hym8563.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Haoyu Microelectronics HYM8563 RTC
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ const: haoyu,hym8563
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ description: From common clock binding to override the default output clock name.
+ maxItems: 1
+
+ wakeup-source:
+ description: Enables wake up of host system on alarm.
+
+allOf:
+ - $ref: rtc.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ #clock-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
index b235b2441997..de9879bdb317 100644
--- a/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/ingenic,rtc.yaml
@@ -4,13 +4,24 @@
$id: http://devicetree.org/schemas/rtc/ingenic,rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs Real-Time Clock DT bindings
+title: Ingenic SoCs Real-Time Clock
maintainers:
- Paul Cercueil <paul@crapouillou.net>
allOf:
- $ref: rtc.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ingenic,jz4770-rtc
+ - ingenic,jz4780-rtc
+ then:
+ properties:
+ "#clock-cells": false
properties:
compatible:
@@ -39,6 +50,9 @@ properties:
clock-names:
const: rtc
+ "#clock-cells":
+ const: 0
+
system-power-controller:
description: |
Indicates that the RTC is responsible for powering OFF
@@ -83,3 +97,18 @@ examples:
clocks = <&cgu JZ4740_CLK_RTC>;
clock-names = "rtc";
};
+
+ - |
+ #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
+ rtc: rtc@10003000 {
+ compatible = "ingenic,jz4780-rtc", "ingenic,jz4760-rtc";
+ reg = <0x10003000 0x4c>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <32>;
+
+ clocks = <&cgu JZ4780_CLK_RTCLK>;
+ clock-names = "rtc";
+
+ #clock-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml b/Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml
new file mode 100644
index 000000000000..c2d1441ef273
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/intersil,isl12022.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/intersil,isl12022.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intersil ISL12022 Real-time Clock
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ const: isil,isl12022
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 0
+
+ isil,battery-trip-levels-microvolt:
+ description:
+ The battery voltages at which the first alarm and second alarm
+ should trigger (normally ~85% and ~75% of nominal V_BAT).
+ items:
+ - enum: [2125000, 2295000, 2550000, 2805000, 3060000, 4250000, 4675000]
+ - enum: [1875000, 2025000, 2250000, 2475000, 2700000, 3750000, 4125000]
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: rtc.yaml#
+ # If #clock-cells is present, interrupts must not be present
+ - if:
+ required:
+ - '#clock-cells'
+ then:
+ properties:
+ interrupts: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6f {
+ compatible = "isil,isl12022";
+ reg = <0x6f>;
+ interrupts-extended = <&gpio1 5 IRQ_TYPE_LEVEL_LOW>;
+ isil,battery-trip-levels-microvolt = <2550000>, <2250000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12057.txt b/Documentation/devicetree/bindings/rtc/isil,isl12057.txt
deleted file mode 100644
index ff7c43555199..000000000000
--- a/Documentation/devicetree/bindings/rtc/isil,isl12057.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Intersil ISL12057 I2C RTC/Alarm chip
-
-ISL12057 is a trivial I2C device (it has simple device tree bindings,
-consisting of a compatible field, an address and possibly an interrupt
-line).
-
-Nonetheless, it also supports an option boolean property
-("wakeup-source") to handle the specific use-case found
-on at least three in-tree users of the chip (NETGEAR ReadyNAS 102, 104
-and 2120 ARM-based NAS); On those devices, the IRQ#2 pin of the chip
-(associated with the alarm supported by the driver) is not connected
-to the SoC but to a PMIC. It allows the device to be powered up when
-RTC alarm rings. In order to mark the device has a wakeup source and
-get access to the 'wakealarm' sysfs entry, this specific property can
-be set when the IRQ#2 pin of the chip is not connected to the SoC but
-can wake up the device.
-
-Required properties supported by the device:
-
- - "compatible": must be "isil,isl12057"
- - "reg": I2C bus address of the device
-
-Optional properties:
-
- - "wakeup-source": mark the chip as a wakeup source, independently of
- the availability of an IRQ line connected to the SoC.
-
-
-Example isl12057 node without IRQ#2 pin connected (no alarm support):
-
- isl12057: isl12057@68 {
- compatible = "isil,isl12057";
- reg = <0x68>;
- };
-
-
-Example isl12057 node with IRQ#2 pin connected to main SoC via MPP6 (note
-that the pinctrl-related properties below are given for completeness and
-may not be required or may be different depending on your system or
-SoC, and the main function of the MPP used as IRQ line, i.e.
-"interrupt-parent" and "interrupts" are usually sufficient):
-
- pinctrl {
- ...
-
- rtc_alarm_pin: rtc_alarm_pin {
- marvell,pins = "mpp6";
- marvell,function = "gpio";
- };
-
- ...
-
- };
-
- ...
-
- isl12057: isl12057@68 {
- compatible = "isil,isl12057";
- reg = <0x68>;
- pinctrl-0 = <&rtc_alarm_pin>;
- pinctrl-names = "default";
- interrupt-parent = <&gpio0>;
- interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
- };
-
-
-Example isl12057 node without IRQ#2 pin connected to the SoC but to a
-PMIC, allowing the device to be started based on configured alarm:
-
- isl12057: isl12057@68 {
- compatible = "isil,isl12057";
- reg = <0x68>;
- wakeup-source;
- };
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1208.txt b/Documentation/devicetree/bindings/rtc/isil,isl1208.txt
deleted file mode 100644
index 51f003006f04..000000000000
--- a/Documentation/devicetree/bindings/rtc/isil,isl1208.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Intersil ISL1209/19 I2C RTC/Alarm chip with event in
-
-ISL12X9 have additional pins EVIN and #EVDET for tamper detection, while the
-ISL1208 and ISL1218 do not. They are all use the same driver with the bindings
-described here, with chip specific properties as noted.
-
-Required properties supported by the device:
- - "compatible": Should be one of the following:
- - "isil,isl1208"
- - "isil,isl1209"
- - "isil,isl1218"
- - "isil,isl1219"
- - "reg": I2C bus address of the device
-
-Optional properties:
- - "interrupt-names": list which may contains "irq" and "evdet"
- evdet applies to isl1209 and isl1219 only
- - "interrupts": list of interrupts for "irq" and "evdet"
- evdet applies to isl1209 and isl1219 only
- - "isil,ev-evienb": Enable or disable internal pull on EVIN pin
- Applies to isl1209 and isl1219 only
- Possible values are 0 and 1
- Value 0 enables internal pull-up on evin pin, 1 disables it.
- Default will leave the non-volatile configuration of the pullup
- as is.
-
-Example isl1219 node with #IRQ pin connected to SoC gpio1 pin12 and #EVDET pin
-connected to SoC gpio2 pin 24 and internal pull-up enabled in EVIN pin.
-
- isl1219: rtc@68 {
- compatible = "isil,isl1219";
- reg = <0x68>;
- interrupt-names = "irq", "evdet";
- interrupts-extended = <&gpio1 12 IRQ_TYPE_EDGE_FALLING>,
- <&gpio2 24 IRQ_TYPE_EDGE_FALLING>;
- isil,ev-evienb = <1>;
- };
-
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml b/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml
new file mode 100644
index 000000000000..11f7378d4997
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl1208.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/isil,isl1208.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intersil ISL1209/19 I2C RTC/Alarm chip with event in
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+ - Trent Piepho <tpiepho@gmail.com>
+
+description:
+ ISL12X9 have additional pins EVIN and EVDET for tamper detection, while the
+ ISL1208 and ISL1218 do not.
+
+properties:
+ compatible:
+ enum:
+ - isil,isl1208
+ - isil,isl1209
+ - isil,isl1218
+ - isil,isl1219
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: |
+ Use xin, if connected to an external crystal.
+ Use clkin, if connected to an external clock signal.
+ enum:
+ - xin
+ - clkin
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: irq
+ - const: evdet
+
+ isil,ev-evienb:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description: |
+ Enable or disable internal pull on EVIN pin
+ Default will leave the non-volatile configuration of the pullup
+ as is.
+ <0> : Enables internal pull-up on evin pin
+ <1> : Disables internal pull-up on evin pin
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: rtc.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - isil,isl1209
+ - isil,isl1219
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+ interrupt-names:
+ items:
+ - const: irq
+ - const: evdet
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names:
+ items:
+ - const: irq
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc_twi: rtc@6f {
+ compatible = "isil,isl1208";
+ reg = <0x6f>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
new file mode 100644
index 000000000000..f89c1f660aee
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/loongson,rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson Real-Time Clock
+
+description:
+ The Loongson family chips use an on-chip counter 0 (Time Of Year
+ counter) as the RTC.
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls1b-rtc
+ - loongson,ls1c-rtc
+ - loongson,ls7a-rtc
+ - loongson,ls2k1000-rtc
+ - items:
+ - enum:
+ - loongson,ls2k2000-rtc
+ - loongson,ls2k0500-rtc
+ - const: loongson,ls7a-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rtc@1fe27800 {
+ compatible = "loongson,ls2k1000-rtc";
+ reg = <0x1fe27800 0x100>;
+
+ interrupt-parent = <&liointc1>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
deleted file mode 100644
index a87a1e9bc060..000000000000
--- a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* NXP LPC32xx SoC Real Time Clock controller
-
-Required properties:
-- compatible: must be "nxp,lpc3220-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The RTC interrupt
-
-Example:
-
- rtc@40024000 {
- compatible = "nxp,lpc3220-rtc";
- reg = <0x40024000 0x1000>;
- interrupts = <52 0>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml b/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml
new file mode 100644
index 000000000000..adf3ba0cd09f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/marvell,armada-380-rtc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/marvell,armada-380-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RTC controller for the Armada 38x, 7K and 8K SoCs
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-380-rtc
+ - marvell,armada-8k-rtc
+
+ reg:
+ items:
+ - description: RTC base address size
+ - description: Base address and size of SoC related registers
+
+ reg-names:
+ items:
+ - const: rtc
+ - const: rtc-soc
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rtc@a3800 {
+ compatible = "marvell,armada-380-rtc";
+ reg = <0xa3800 0x20>, <0x184a0 0x0c>;
+ reg-names = "rtc", "rtc-soc";
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml b/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml
new file mode 100644
index 000000000000..43d68681a1bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/marvell,pxa-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PXA Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: marvell,pxa-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: 1 Hz
+ - description: Alarm
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@40900000 {
+ compatible = "marvell,pxa-rtc";
+ reg = <0x40900000 0x3c>;
+ interrupts = <30>, <31>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt b/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt
deleted file mode 100644
index d0f937c355b5..000000000000
--- a/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-* Maxim (Dallas) DS1742/DS1743 Real Time Clock
-
-Required properties:
-- compatible: Should contain "maxim,ds1742".
-- reg: Physical base address of the RTC and length of memory
- mapped region.
-
-Example:
- rtc: rtc@10000000 {
- compatible = "maxim,ds1742";
- reg = <0x10000000 0x800>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt b/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt
deleted file mode 100644
index 85be53a42180..000000000000
--- a/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-* Maxim DS3231 Real Time Clock
-
-Required properties:
-- compatible: Should contain "maxim,ds3231".
-- reg: I2C address for chip.
-
-Optional property:
-- #clock-cells: Should be 1.
-- clock-output-names:
- overwrite the default clock names "ds3231_clk_sqw" and "ds3231_clk_32khz".
-
-Each clock is assigned an identifier and client nodes can use this identifier
-to specify the clock which they consume. Following indices are allowed:
- - 0: square-wave output on the SQW pin
- - 1: square-wave output on the 32kHz pin
-
-- interrupts: rtc alarm/event interrupt. When this property is selected,
- clock on the SQW pin cannot be used.
-
-Example:
-
-ds3231: ds3231@51 {
- compatible = "maxim,ds3231";
- reg = <0x68>;
- #clock-cells = <1>;
-};
-
-device1 {
-...
- clocks = <&ds3231 0>;
-...
-};
-
-device2 {
-...
- clocks = <&ds3231 1>;
-...
-};
diff --git a/Documentation/devicetree/bindings/rtc/maxim,mcp795.txt b/Documentation/devicetree/bindings/rtc/maxim,mcp795.txt
deleted file mode 100644
index a59fdd8c236d..000000000000
--- a/Documentation/devicetree/bindings/rtc/maxim,mcp795.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* Maxim MCP795 SPI Serial Real-Time Clock
-
-Required properties:
-- compatible: Should contain "maxim,mcp795".
-- reg: SPI address for chip
-
-Example:
- mcp795: rtc@0 {
- compatible = "maxim,mcp795";
- reg = <0>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/mediatek,mt2712-rtc.yaml b/Documentation/devicetree/bindings/rtc/mediatek,mt2712-rtc.yaml
new file mode 100644
index 000000000000..75624ddf6d4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/mediatek,mt2712-rtc.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/mediatek,mt2712-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT2712 on-SoC RTC
+
+allOf:
+ - $ref: rtc.yaml#
+
+maintainers:
+ - Ran Bi <ran.bi@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt2712-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rtc@10011000 {
+ compatible = "mediatek,mt2712-rtc";
+ reg = <0x10011000 0x1000>;
+ interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/mediatek,mt7622-rtc.yaml b/Documentation/devicetree/bindings/rtc/mediatek,mt7622-rtc.yaml
new file mode 100644
index 000000000000..e74dfc161cfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/mediatek,mt7622-rtc.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/mediatek,mt7622-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7622 on-SoC RTC
+
+allOf:
+ - $ref: rtc.yaml#
+
+maintainers:
+ - Sean Wang <sean.wang@mediatek.com>
+
+properties:
+ compatible:
+ items:
+ - const: mediatek,mt7622-rtc
+ - const: mediatek,soc-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: rtc
+
+required:
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt7622-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ rtc@10212800 {
+ compatible = "mediatek,mt7622-rtc", "mediatek,soc-rtc";
+ reg = <0x10212800 0x200>;
+ interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_RTC>;
+ clock-names = "rtc";
+ };
diff --git a/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml
deleted file mode 100644
index 500c62becd6b..000000000000
--- a/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml
+++ /dev/null
@@ -1,67 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/rtc/microchip,mfps-rtc.yaml#
-
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip PolarFire Soc (MPFS) RTC Device Tree Bindings
-
-allOf:
- - $ref: rtc.yaml#
-
-maintainers:
- - Daire McNamara <daire.mcnamara@microchip.com>
- - Lewis Hanly <lewis.hanly@microchip.com>
-
-properties:
- compatible:
- enum:
- - microchip,mpfs-rtc
-
- reg:
- maxItems: 1
-
- interrupts:
- items:
- - description: |
- RTC_WAKEUP interrupt
- - description: |
- RTC_MATCH, asserted when the content of the Alarm register is equal
- to that of the RTC's count register.
-
- clocks:
- items:
- - description: |
- AHB clock
- - description: |
- Reference clock: divided by the prescaler to create a time-based
- strobe (typically 1 Hz) for the calendar counter. By default, the rtc
- on the PolarFire SoC shares it's reference with MTIMER so this will
- be a 1 MHz clock.
-
- clock-names:
- items:
- - const: rtc
- - const: rtcref
-
-required:
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
-
-additionalProperties: false
-
-examples:
- - |
- #include "dt-bindings/clock/microchip,mpfs-clock.h"
- rtc@20124000 {
- compatible = "microchip,mpfs-rtc";
- reg = <0x20124000 0x1000>;
- clocks = <&clkcfg CLK_RTC>, <&clkcfg CLK_RTCREF>;
- clock-names = "rtc", "rtcref";
- interrupts = <80>, <81>;
- };
-...
diff --git a/Documentation/devicetree/bindings/rtc/microchip,mpfs-rtc.yaml b/Documentation/devicetree/bindings/rtc/microchip,mpfs-rtc.yaml
new file mode 100644
index 000000000000..a3e60d9f8399
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/microchip,mpfs-rtc.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/microchip,mpfs-rtc.yaml#
+
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire Soc (MPFS) RTC
+
+allOf:
+ - $ref: rtc.yaml#
+
+maintainers:
+ - Daire McNamara <daire.mcnamara@microchip.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: microchip,pic64gx-rtc
+ - const: microchip,mpfs-rtc
+ - const: microchip,mpfs-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: |
+ RTC_WAKEUP interrupt
+ - description: |
+ RTC_MATCH, asserted when the content of the Alarm register is equal
+ to that of the RTC's count register.
+
+ clocks:
+ items:
+ - description: |
+ AHB clock
+ - description: |
+ Reference clock: divided by the prescaler to create a time-based
+ strobe (typically 1 Hz) for the calendar counter. By default, the rtc
+ on the PolarFire SoC shares it's reference with MTIMER so this will
+ be a 1 MHz clock.
+
+ clock-names:
+ items:
+ - const: rtc
+ - const: rtcref
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include "dt-bindings/clock/microchip,mpfs-clock.h"
+ rtc@20124000 {
+ compatible = "microchip,mpfs-rtc";
+ reg = <0x20124000 0x1000>;
+ clocks = <&clkcfg CLK_RTC>, <&clkcfg CLK_RTCREF>;
+ clock-names = "rtc", "rtcref";
+ interrupts = <80>, <81>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
new file mode 100644
index 000000000000..cda8ad7c1203
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/microcrystal,rv3028.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip RV-3028 RTC
+
+allOf:
+ - $ref: rtc.yaml#
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ const: microcrystal,rv3028
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ trickle-resistor-ohms:
+ enum:
+ - 3000
+ - 5000
+ - 9000
+ - 15000
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@51 {
+ compatible = "microcrystal,rv3028";
+ reg = <0x51>;
+ pinctrl-0 = <&rtc_nint_pins>;
+ interrupts-extended = <&gpio1 16 IRQ_TYPE_LEVEL_HIGH>;
+ trickle-resistor-ohms = <3000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
index 60f9027e8299..7680089d1d92 100644
--- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
+++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/rtc/microcrystal,rv3032.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip RV-3032 RTC Device Tree Bindings
+title: Microchip RV-3032 RTC
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
@@ -38,6 +38,8 @@ properties:
- 3000
- 4400
+ wakeup-source: true
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
index c9d3ac1477fe..1374df7bf9d6 100644
--- a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
@@ -3,15 +3,15 @@ MOXA ART real-time clock
Required properties:
- compatible : Should be "moxa,moxart-rtc"
-- gpio-rtc-sclk : RTC sclk gpio, with zero flags
-- gpio-rtc-data : RTC data gpio, with zero flags
-- gpio-rtc-reset : RTC reset gpio, with zero flags
+- rtc-sclk-gpios : RTC sclk gpio, with zero flags
+- rtc-data-gpios : RTC data gpio, with zero flags
+- rtc-reset-gpios : RTC reset gpio, with zero flags
Example:
rtc: rtc {
compatible = "moxa,moxart-rtc";
- gpio-rtc-sclk = <&gpio 5 0>;
- gpio-rtc-data = <&gpio 6 0>;
- gpio-rtc-reset = <&gpio 7 0>;
+ rtc-sclk-gpios = <&gpio 5 0>;
+ rtc-data-gpios = <&gpio 6 0>;
+ rtc-reset-gpios = <&gpio 7 0>;
};
diff --git a/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml
index 114199cf4d28..af4a31cd0954 100644
--- a/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/rtc/mstar,msc313-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mstar MSC313e RTC Device Tree Bindings
+title: Mstar MSC313e RTC
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Daniel Palmer <daniel@0x0f.com>
diff --git a/Documentation/devicetree/bindings/rtc/mstar,ssd202d-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,ssd202d-rtc.yaml
new file mode 100644
index 000000000000..4c1f22ef5a2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/mstar,ssd202d-rtc.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/mstar,ssd202d-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mstar SSD202D Real Time Clock
+
+maintainers:
+ - Daniel Palmer <daniel@0x0f.com>
+ - Romain Perier <romain.perier@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - mstar,ssd202d-rtc
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@6800 {
+ compatible = "mstar,ssd202d-rtc";
+ reg = <0x6800 0x200>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,ma35d1-rtc.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,ma35d1-rtc.yaml
new file mode 100644
index 000000000000..5e4ade803eed
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nuvoton,ma35d1-rtc.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nuvoton,ma35d1-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Real Time Clock
+
+maintainers:
+ - Min-Jen Chen <mjchen@nuvoton.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,ma35d1-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+ rtc@40410000 {
+ compatible = "nuvoton,ma35d1-rtc";
+ reg = <0x40410000 0x200>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clk RTC_GATE>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
index 7a1857f5caa8..4f9b5604acd9 100644
--- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
+++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: NUVOTON NCT3018Y Real Time Clock
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Medad CChien <ctcchien@nuvoton.com>
diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml
index 17d6280e5515..a86e926ae3d1 100644
--- a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml
@@ -28,6 +28,7 @@ properties:
- nvidia,tegra186-rtc
- nvidia,tegra194-rtc
- nvidia,tegra234-rtc
+ - nvidia,tegra264-rtc
- const: nvidia,tegra20-rtc
reg:
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
deleted file mode 100644
index 3c97bd180592..000000000000
--- a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-NXP LPC1788 real-time clock
-
-The LPC1788 RTC provides calendar and clock functionality
-together with periodic tick and alarm interrupt support.
-
-Required properties:
-- compatible : must contain "nxp,lpc1788-rtc"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : A single interrupt specifier.
-- clocks : Must contain clock specifiers for rtc and register clock
-- clock-names : Must contain "rtc" and "reg"
- See ../clocks/clock-bindings.txt for details.
-
-Example:
-rtc: rtc@40046000 {
- compatible = "nxp,lpc1788-rtc";
- reg = <0x40046000 0x1000>;
- interrupts = <47>;
- clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
- clock-names = "rtc", "reg";
-};
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml
new file mode 100644
index 000000000000..e896ba59302a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,lpc1788-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC1788 real-time clock
+
+description:
+ The LPC1788 RTC provides calendar and clock functionality
+ together with periodic tick and alarm interrupt support.
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - nxp,lpc1850-rtc
+ - const: nxp,lpc1788-rtc
+ - const: nxp,lpc1788-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: RTC clock
+ - description: Register clock
+
+ clock-names:
+ items:
+ - const: rtc
+ - const: reg
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ rtc@40046000 {
+ compatible = "nxp,lpc1788-rtc";
+ reg = <0x40046000 0x1000>;
+ clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
+ clock-names = "rtc", "reg";
+ interrupts = <47>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc3220-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,lpc3220-rtc.yaml
new file mode 100644
index 000000000000..53353de4cb37
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,lpc3220-rtc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,lpc3220-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx SoC Real-time Clock
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,lpc3220-rtc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ start-year: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: rtc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/lpc32xx-clock.h>
+
+ rtc@40024000 {
+ compatible = "nxp,lpc3220-rtc";
+ reg = <0x40024000 0x1000>;
+ interrupt-parent = <&sic1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LPC32XX_CLK_RTC>;
+ };
+
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2123.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2123.yaml
new file mode 100644
index 000000000000..96e377a4d1bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2123.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,pcf2123.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCF2123 SPI Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nxp,pcf2123
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@3 {
+ compatible = "nxp,pcf2123";
+ reg = <3>;
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_LOW>;
+ spi-cs-high;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
index cde7b1675ead..11fcf0ca1ae0 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
@@ -7,14 +7,19 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP PCF2127 Real Time Clock
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
properties:
compatible:
- const: nxp,pcf2127
+ enum:
+ - nxp,pca2129
+ - nxp,pcf2127
+ - nxp,pcf2129
+ - nxp,pcf2131
reg:
maxItems: 1
@@ -30,7 +35,7 @@ required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml
index 2f892f8640d1..f7013cd8fc20 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.yaml
@@ -12,6 +12,7 @@ maintainers:
properties:
compatible:
enum:
+ - microcrystal,rv8063
- microcrystal,rv8263
- nxp,pcf85063
- nxp,pcf85063a
@@ -44,13 +45,19 @@ properties:
wakeup-source: true
+ spi-cs-high: true
+
+ spi-3wire: true
+
allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
- $ref: rtc.yaml#
- if:
properties:
compatible:
contains:
enum:
+ - microcrystal,rv8063
- microcrystal,rv8263
then:
properties:
@@ -58,19 +65,20 @@ allOf:
- if:
properties:
compatible:
- contains:
- enum:
- - nxp,pcf85063
+ not:
+ contains:
+ enum:
+ - microcrystal,rv8063
then:
properties:
- quartz-load-femtofarads:
- const: 7000
+ spi-cs-high: false
+ spi-3wire: false
required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -90,3 +98,16 @@ examples:
};
};
};
+
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@0 {
+ compatible = "microcrystal,rv8063";
+ reg = <0>;
+ spi-cs-high;
+ spi-3wire;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.txt b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.txt
deleted file mode 100644
index 0b1080c60f63..000000000000
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* NXP PCF8523 Real Time Clock
-
-Required properties:
-- compatible: Should contain "nxp,pcf8523".
-- reg: I2C address for chip.
-
-Optional property:
-- quartz-load-femtofarads: The capacitive load of the quartz(x-tal),
- expressed in femto Farad (fF). Valid values are 7000 and 12500.
- Default value (if no value is specified) is 12500fF.
-
-Example:
-
-pcf8523: rtc@68 {
- compatible = "nxp,pcf8523";
- reg = <0x68>;
- quartz-load-femtofarads = <7000>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
new file mode 100644
index 000000000000..d11c8bc16bc0
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,pcf8523.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCF8523 Real Time Clock
+
+maintainers:
+ - Sam Ravnborg <sam@ravnborg.org>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: nxp,pcf8523
+
+ reg:
+ maxItems: 1
+
+ quartz-load-femtofarads:
+ description:
+ The capacitive load of the crystal, expressed in femto Farad (fF).
+ enum: [ 7000, 12500 ]
+ default: 12500
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@68 {
+ compatible = "nxp,pcf8523";
+ reg = <0x68>;
+ quartz-load-femtofarads = <7000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml
new file mode 100644
index 000000000000..52aa3e2091e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85363.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,pcf85363.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Philips PCF85263/PCF85363 Real Time Clock
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nxp,pcf85263
+ - nxp,pcf85363
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ clock-output-names:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ quartz-load-femtofarads:
+ description:
+ The capacitive load of the quartz(x-tal).
+ enum: [6000, 7000, 12500]
+ default: 7000
+
+ start-year: true
+ wakeup-source: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@51 {
+ compatible = "nxp,pcf85363";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ quartz-load-femtofarads = <12500>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml
index a98b72752349..22909a96123e 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml
@@ -19,8 +19,6 @@ properties:
- microcrystal,rv8564
- nxp,pca8565
- nxp,pcf8563
- - nxp,pcf85263
- - nxp,pcf85363
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt b/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt
deleted file mode 100644
index 7371f525a687..000000000000
--- a/Documentation/devicetree/bindings/rtc/nxp,rtc-2123.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-NXP PCF2123 SPI Real Time Clock
-
-Required properties:
-- compatible: should be: "nxp,pcf2123"
- or "microcrystal,rv2123"
-- reg: should be the SPI slave chipselect address
-
-Optional properties:
-- spi-cs-high: PCF2123 needs chipselect high
-
-Example:
-
-pcf2123: rtc@3 {
- compatible = "nxp,pcf2123"
- reg = <3>
- spi-cs-high;
-};
diff --git a/Documentation/devicetree/bindings/rtc/nxp,s32g-rtc.yaml b/Documentation/devicetree/bindings/rtc/nxp,s32g-rtc.yaml
new file mode 100644
index 000000000000..40fd2fa298fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/nxp,s32g-rtc.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/nxp,s32g-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP S32G2/S32G3 Real Time Clock (RTC)
+
+maintainers:
+ - Bogdan Hamciuc <bogdan.hamciuc@nxp.com>
+ - Ciprian Marian Costea <ciprianmarian.costea@nxp.com>
+
+description:
+ RTC hardware module present on S32G2/S32G3 SoCs is used as a wakeup source.
+ It is not kept alive during system reset and it is not battery-powered.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nxp,s32g2-rtc
+ - items:
+ - const: nxp,s32g3-rtc
+ - const: nxp,s32g2-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ipg clock drives the access to the RTC iomapped registers
+ - description: Clock source for the RTC module. Can be selected between
+ 4 different clock sources using an integrated hardware mux.
+ On S32G2/S32G3 SoCs, 'source0' is the SIRC clock (~32KHz) and it is
+ available during standby and runtime. 'source1' is reserved and cannot
+ be used. 'source2' is the FIRC clock and it is only available during
+ runtime providing a better resolution (~48MHz). 'source3' is an external
+ RTC clock source which can be additionally added in hardware.
+
+ clock-names:
+ items:
+ - const: ipg
+ - enum: [ source0, source1, source2, source3 ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rtc@40060000 {
+ compatible = "nxp,s32g3-rtc",
+ "nxp,s32g2-rtc";
+ reg = <0x40060000 0x1000>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 54>, <&clks 55>;
+ clock-names = "ipg", "source0";
+ };
diff --git a/Documentation/devicetree/bindings/rtc/orion-rtc.txt b/Documentation/devicetree/bindings/rtc/orion-rtc.txt
deleted file mode 100644
index 3bf63ffa5160..000000000000
--- a/Documentation/devicetree/bindings/rtc/orion-rtc.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Mvebu Real Time Clock
-
-RTC controller for the Kirkwood, the Dove, the Armada 370 and the
-Armada XP SoCs
-
-Required properties:
-- compatible : Should be "marvell,orion-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: IRQ line for the RTC.
-
-Example:
-
-rtc@10300 {
- compatible = "marvell,orion-rtc";
- reg = <0xd0010300 0x20>;
- interrupts = <50>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/pxa-rtc.txt b/Documentation/devicetree/bindings/rtc/pxa-rtc.txt
deleted file mode 100644
index 8c6672a1b7d7..000000000000
--- a/Documentation/devicetree/bindings/rtc/pxa-rtc.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* PXA RTC
-
-PXA specific RTC driver.
-
-Required properties:
-- compatible : Should be "marvell,pxa-rtc"
-
-Examples:
-
-rtc@40900000 {
- compatible = "marvell,pxa-rtc";
- reg = <0x40900000 0x3c>;
- interrupts = <30 31>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
index 23ab5bb4f395..7497dc3ac5b2 100644
--- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml
@@ -11,12 +11,16 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,pm8058-rtc
- - qcom,pm8921-rtc
- - qcom,pm8941-rtc
- - qcom,pm8018-rtc
- - qcom,pmk8350-rtc
+ oneOf:
+ - enum:
+ - qcom,pm8058-rtc
+ - qcom,pm8921-rtc
+ - qcom,pm8941-rtc
+ - qcom,pmk8350-rtc
+ - items:
+ - enum:
+ - qcom,pm8018-rtc
+ - const: qcom,pm8921-rtc
reg:
minItems: 1
@@ -36,6 +40,29 @@ properties:
description:
Indicates that the setting of RTC time is allowed by the host CPU.
+ nvmem-cells:
+ items:
+ - description:
+ four-byte nvmem cell holding a little-endian offset from the Unix
+ epoch representing the time when the RTC timer was last reset
+
+ nvmem-cell-names:
+ items:
+ - const: offset
+
+ qcom,no-alarm:
+ type: boolean
+ description:
+ RTC alarm is not owned by the OS
+
+ qcom,uefi-rtc-info:
+ type: boolean
+ description:
+ RTC offset is stored as a four-byte GPS time offset in a 12-byte UEFI
+ variable 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo
+
+ wakeup-source: true
+
required:
- compatible
- reg
@@ -45,25 +72,27 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/spmi/spmi.h>
- spmi_bus: spmi@c440000 {
- reg = <0x0c440000 0x1100>;
- #address-cells = <2>;
- #size-cells = <0>;
- pmicintc: pmic@0 {
- reg = <0x0 SPMI_USID>;
- compatible = "qcom,pm8921";
- interrupts = <104 8>;
- #interrupt-cells = <2>;
- interrupt-controller;
- #address-cells = <1>;
+
+ spmi {
+ #address-cells = <2>;
#size-cells = <0>;
- pm8921_rtc: rtc@11d {
- compatible = "qcom,pm8921-rtc";
- reg = <0x11d>;
- interrupts = <0x27 0>;
+ pmic@0 {
+ compatible = "qcom,pm8941", "qcom,spmi-pmic";
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6000 {
+ compatible = "qcom,pm8941-rtc";
+ reg = <0x6000>, <0x6100>;
+ reg-names = "rtc", "alarm";
+ interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
+ nvmem-cells = <&rtc_offset>;
+ nvmem-cell-names = "offset";
+ };
};
- };
};
...
diff --git a/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml b/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
new file mode 100644
index 000000000000..e70eeb66aa64
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/renesas,rz-rtca3.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/renesas,rz-rtca3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RTCA-3 Real Time Clock
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a08g045-rtca3 # RZ/G3S
+ - const: renesas,rz-rtca3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Alarm interrupt
+ - description: Periodic interrupt
+ - description: Carry interrupt
+
+ interrupt-names:
+ items:
+ - const: alarm
+ - const: period
+ - const: carry
+
+ clocks:
+ items:
+ - description: RTC bus clock
+ - description: RTC counter clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: counter
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: VBATTB module reset
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a08g045-cpg.h>
+ #include <dt-bindings/clock/renesas,r9a08g045-vbattb.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rtc@1004ec00 {
+ compatible = "renesas,r9a08g045-rtca3", "renesas,rz-rtca3";
+ reg = <0x1004ec00 0x400>;
+ interrupts = <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "alarm", "period", "carry";
+ clocks = <&cpg CPG_MOD R9A08G045_VBAT_BCLK>, <&vbattclk VBATTB_VBATTCLK>;
+ clock-names = "bus", "counter";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A08G045_VBAT_BRESETN>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
index 2d4741f51663..1860f0e4c31a 100644
--- a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/renesas,rzn1-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas RZ/N1 SoCs Real-Time Clock DT bindings
+title: Renesas RZ/N1 SoCs Real-Time Clock
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
@@ -33,10 +33,14 @@ properties:
- const: pps
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
clock-names:
- const: hclk
+ minItems: 1
+ items:
+ - const: hclk
+ - const: xtal
power-domains:
maxItems: 1
@@ -57,14 +61,14 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
rtc@40006000 {
- compatible = "renesas,r9a06g032-rtc", "renesas,rzn1-rtc";
- reg = <0x40006000 0x1000>;
- interrupts = <GIC_SPI 66 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 67 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 68 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "alarm", "timer", "pps";
- clocks = <&sysctrl R9A06G032_HCLK_RTC>;
- clock-names = "hclk";
- power-domains = <&sysctrl>;
- start-year = <2000>;
- };
+ compatible = "renesas,r9a06g032-rtc", "renesas,rzn1-rtc";
+ reg = <0x40006000 0x1000>;
+ interrupts = <GIC_SPI 66 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 67 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 68 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "alarm", "timer", "pps";
+ clocks = <&sysctrl R9A06G032_HCLK_RTC>;
+ clock-names = "hclk";
+ power-domains = <&sysctrl>;
+ start-year = <2000>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-aspeed.txt b/Documentation/devicetree/bindings/rtc/rtc-aspeed.txt
deleted file mode 100644
index 2e956b3dc276..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-aspeed.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ASPEED BMC RTC
-==============
-
-Required properties:
- - compatible: should be one of the following
- * aspeed,ast2400-rtc for the ast2400
- * aspeed,ast2500-rtc for the ast2500
- * aspeed,ast2600-rtc for the ast2600
-
- - reg: physical base address of the controller and length of memory mapped
- region
-
- - interrupts: The interrupt number
-
-Example:
-
- rtc@1e781000 {
- compatible = "aspeed,ast2400-rtc";
- reg = <0x1e781000 0x18>;
- interrupts = <22>;
- status = "disabled";
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
index b94b35f3600b..7d7b5f6bda65 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
@@ -10,7 +10,7 @@ Optional properties:
- ctrl-reg : Contains the initial value of the control register also
called "Register B".
- freq-reg : Contains the initial value of the frequency register also
- called "Regsiter A".
+ called "Register A".
"Register A" and "B" are usually initialized by the firmware (BIOS for
instance). If this is not done, it can be performed by the driver.
diff --git a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt b/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
deleted file mode 100644
index fffac74999da..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-fsl-ftm-alarm.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Freescale FlexTimer Module (FTM) Alarm
-
-Required properties:
-- compatible : Should be "fsl,<chip>-ftm-alarm", the
- supported chips include
- "fsl,ls1012a-ftm-alarm"
- "fsl,ls1021a-ftm-alarm"
- "fsl,ls1028a-ftm-alarm"
- "fsl,ls1043a-ftm-alarm"
- "fsl,ls1046a-ftm-alarm"
- "fsl,ls1088a-ftm-alarm"
- "fsl,ls208xa-ftm-alarm"
- "fsl,lx2160a-ftm-alarm"
-- reg : Specifies base physical address and size of the register sets for the
- FlexTimer Module.
-- interrupts : Should be the FlexTimer Module interrupt.
-- fsl,rcpm-wakeup property and rcpm node : Please refer
- Documentation/devicetree/bindings/soc/fsl/rcpm.txt
-
-Optional properties:
-- big-endian: If the host controller is big-endian mode, specify this property.
- The default endian mode is little-endian.
-
-Example:
-rcpm: rcpm@1e34040 {
- compatible = "fsl,ls1088a-rcpm", "fsl,qoriq-rcpm-2.1+";
- reg = <0x0 0x1e34040 0x0 0x18>;
- #fsl,rcpm-wakeup-cells = <6>;
-};
-
-ftm_alarm0: timer@2800000 {
- compatible = "fsl,ls1088a-ftm-alarm";
- reg = <0x0 0x2800000 0x0 0x10000>;
- fsl,rcpm-wakeup = <&rcpm 0x0 0x0 0x0 0x0 0x4000 0x0>;
- interrupts = <0 44 4>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
deleted file mode 100644
index cdd196b1e9bd..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-ST M41T80 family of RTC and compatible
-
-Required properties:
-- compatible: should be one of:
- "st,m41t62",
- "st,m41t65",
- "st,m41t80",
- "st,m41t81",
- "st,m41t81s",
- "st,m41t82",
- "st,m41t83",
- "st,m41t84",
- "st,m41t85",
- "st,m41t87",
- "microcrystal,rv4162",
-- reg: I2C bus address of the device
-
-Optional properties:
-- interrupts: rtc alarm interrupt.
-- clock-output-names: From common clock binding to override the default output
- clock name
-- wakeup-source: Enables wake up of host system on alarm
-
-Optional child node:
-- clock: Provide this if the square wave pin is used as boot-enabled fixed clock.
-
-Example:
- rtc@68 {
- compatible = "st,m41t80";
- reg = <0x68>;
- interrupt-parent = <&UIC0>;
- interrupts = <0x9 0x8>;
-
- clock {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- };
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
deleted file mode 100644
index c014f54a9853..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic Virtual RTC (VRTC)
-
-This is a Linux interface to an RTC managed by firmware, hence it's
-virtual from a Linux perspective. The interface is 1 register where
-an alarm time (in seconds) is to be written.
-
-Required properties:
-- compatible: should be "amlogic,meson-vrtc"
-- reg: physical address for the alarm register
-
-The alarm register is a simple scratch register shared between the
-application processors (AP) and the secure co-processor (SCP.) When
-the AP suspends, the SCP will use the value of this register to
-program an always-on timer before going sleep. When the timer expires,
-the SCP will wake up and will then wake the AP.
-
-Example:
-
- vrtc: rtc@0a8 {
- compatible = "amlogic,meson-vrtc";
- reg = <0x0 0x000a8 0x0 0x4>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-meson.txt b/Documentation/devicetree/bindings/rtc/rtc-meson.txt
deleted file mode 100644
index e921fe66a362..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-meson.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* Amlogic Meson6, Meson8, Meson8b and Meson8m2 RTC
-
-Required properties:
-- compatible: should be one of the following describing the hardware:
- * "amlogic,meson6-rtc"
- * "amlogic,meson8-rtc"
- * "amlogic,meson8b-rtc"
- * "amlogic,meson8m2-rtc"
-
-- reg: physical register space for the controller's memory mapped registers.
-- interrupts: the interrupt line of the RTC block.
-- clocks: reference to the external 32.768kHz crystal oscillator.
-- vdd-supply: reference to the power supply of the RTC block.
-- resets: reset controller reference to allow reset of the controller
-
-Optional properties for the battery-backed non-volatile memory:
-- #address-cells: should be 1 to address the battery-backed non-volatile memory
-- #size-cells: should be 1 to reference the battery-backed non-volatile memory
-
-Optional child nodes:
-- see ../nvmem/nvmem.txt
-
-Example:
-
- rtc: rtc@740 {
- compatible = "amlogic,meson6-rtc";
- reg = <0x740 0x14>;
- interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>;
- clocks = <&rtc32k_xtal>;
- vdd-supply = <&rtc_vdd>;
- resets = <&reset RESET_RTC>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt2712.txt b/Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
deleted file mode 100644
index c33d87e5e753..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Device-Tree bindings for MediaTek SoC based RTC
-
-Required properties:
-- compatible : Should be "mediatek,mt2712-rtc" : for MT2712 SoC
-- reg : Specifies base physical address and size of the registers;
-- interrupts : Should contain the interrupt for RTC alarm;
-
-Example:
-
-rtc: rtc@10011000 {
- compatible = "mediatek,mt2712-rtc";
- reg = <0 0x10011000 0 0x1000>;
- interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt b/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
deleted file mode 100644
index 7212076a8f1b..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Device-Tree bindings for MediaTek PMIC based RTC
-
-MediaTek PMIC based RTC is an independent function of MediaTek PMIC that works
-as a type of multi-function device (MFD). The RTC can be configured and set up
-with PMIC wrapper bus which is a common resource shared with the other
-functions found on the same PMIC.
-
-For MediaTek PMIC MFD bindings, see:
-../mfd/mt6397.txt
-
-For MediaTek PMIC wrapper bus bindings, see:
-../soc/mediatek/pwrap.txt
-
-Required properties:
-- compatible: Should be one of follows
- "mediatek,mt6323-rtc": for MT6323 PMIC
- "mediatek,mt6358-rtc": for MT6358 PMIC
- "mediatek,mt6366-rtc", "mediatek,mt6358-rtc": for MT6366 PMIC
- "mediatek,mt6397-rtc": for MT6397 PMIC
-
-Example:
-
- pmic {
- compatible = "mediatek,mt6323";
-
- ...
-
- rtc {
- compatible = "mediatek,mt6323-rtc";
- };
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt7622.txt b/Documentation/devicetree/bindings/rtc/rtc-mt7622.txt
deleted file mode 100644
index 09fe8f51476f..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-mt7622.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Device-Tree bindings for MediaTek SoC based RTC
-
-Required properties:
-- compatible : Should be
- "mediatek,mt7622-rtc", "mediatek,soc-rtc" : for MT7622 SoC
-- reg : Specifies base physical address and size of the registers;
-- interrupts : Should contain the interrupt for RTC alarm;
-- clocks : Specifies list of clock specifiers, corresponding to
- entries in clock-names property;
-- clock-names : Should contain "rtc" entries
-
-Example:
-
-rtc: rtc@10212800 {
- compatible = "mediatek,mt7622-rtc",
- "mediatek,soc-rtc";
- reg = <0 0x10212800 0 0x200>;
- interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&topckgen CLK_TOP_RTC>;
- clock-names = "rtc";
-};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml
index 4f263fa6fd0d..2599b847f406 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml
@@ -7,16 +7,20 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Real Time Clock of the i.MX SoCs
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Philippe Reynes <tremyfr@gmail.com>
properties:
compatible:
- enum:
- - fsl,imx1-rtc
- - fsl,imx21-rtc
+ oneOf:
+ - const: fsl,imx1-rtc
+ - const: fsl,imx21-rtc
+ - items:
+ - enum:
+ - fsl,imx31-rtc
+ - const: fsl,imx21-rtc
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml
index 2d1a30663d72..e50131c26dc6 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX53 Secure Real Time Clock (SRTC)
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
maintainers:
- Patrick Bruenn <p.bruenn@beckhoff.com>
diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml
index 0ec3551f12dd..efb66df82782 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: RTC Generic Binding
+title: Real Time Clock Common Properties
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
@@ -15,7 +15,7 @@ description: |
properties:
$nodename:
- pattern: "^rtc(@.*|-[0-9a-f])*$"
+ pattern: "^rtc(@.*|-([0-9]|[1-9][0-9]+))?$"
aux-voltage-chargeable:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
index d51b236939bf..338874e7ed7f 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
@@ -13,10 +13,12 @@ properties:
compatible:
oneOf:
- enum:
- - samsung,s3c2410-rtc
- - samsung,s3c2416-rtc
- - samsung,s3c2443-rtc
- samsung,s3c6410-rtc
+ - items:
+ - enum:
+ - samsung,exynos7-rtc
+ - samsung,exynos850-rtc
+ - const: samsung,s3c6410-rtc
- const: samsung,exynos3250-rtc
deprecated: true
@@ -24,19 +26,12 @@ properties:
maxItems: 1
clocks:
- description:
- Must contain a list of phandle and clock specifier for the rtc
- clock and in the case of a s3c6410 compatible controller, also
- a source clock.
- minItems: 1
maxItems: 2
clock-names:
- description:
- Must contain "rtc" and for a s3c6410 compatible controller
- also "rtc_src".
- minItems: 1
- maxItems: 2
+ items:
+ - const: rtc
+ - const: rtc_src
interrupts:
description:
@@ -49,30 +44,6 @@ properties:
allOf:
- $ref: rtc.yaml#
- - if:
- properties:
- compatible:
- contains:
- enum:
- - samsung,s3c6410-rtc
- - samsung,exynos3250-rtc
- then:
- properties:
- clocks:
- minItems: 2
- maxItems: 2
- clock-names:
- items:
- - const: rtc
- - const: rtc_src
- else:
- properties:
- clocks:
- minItems: 1
- maxItems: 1
- clock-names:
- items:
- - const: rtc
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml
index 482e5af215b3..fcf52d2cac9e 100644
--- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/sa1100-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell Real Time Clock controller bindings
+title: Marvell Real Time Clock controller
allOf:
- $ref: rtc.yaml#
@@ -12,7 +12,7 @@ allOf:
maintainers:
- Alessandro Zummo <a.zummo@towertech.it>
- Alexandre Belloni <alexandre.belloni@bootlin.com>
- - Rob Herring <robh+dt@kernel.org>
+ - Rob Herring <robh@kernel.org>
properties:
compatible:
@@ -34,8 +34,8 @@ properties:
interrupt-names:
items:
- - const: 'rtc 1Hz'
- - const: 'rtc alarm'
+ - const: rtc 1Hz
+ - const: rtc alarm
required:
- compatible
diff --git a/Documentation/devicetree/bindings/rtc/snvs-rtc.txt b/Documentation/devicetree/bindings/rtc/snvs-rtc.txt
deleted file mode 100644
index fb61ed77ada3..000000000000
--- a/Documentation/devicetree/bindings/rtc/snvs-rtc.txt
+++ /dev/null
@@ -1 +0,0 @@
-See Documentation/devicetree/bindings/crypto/fsl-sec4.txt for details.
diff --git a/Documentation/devicetree/bindings/rtc/sophgo,cv1800b-rtc.yaml b/Documentation/devicetree/bindings/rtc/sophgo,cv1800b-rtc.yaml
new file mode 100644
index 000000000000..c695d2ff9fcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sophgo,cv1800b-rtc.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/sophgo,cv1800b-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Real Time Clock of the Sophgo CV1800 SoC
+
+description:
+ The RTC (Real Time Clock) is an independently powered module in the chip. It
+ contains a 32KHz oscillator and a Power-On-Reset (POR) sub-module, which can
+ be used for time display and scheduled alarm produce. In addition, the
+ hardware state machine provides triggering and timing control for chip
+ power-on, power-off and reset.
+
+ Furthermore, the 8051 subsystem is located within RTCSYS and is independently
+ powered. System software can use the 8051 to manage wake conditions and wake
+ the system while the system is asleep, and communicate with external devices
+ through peripheral controllers.
+
+ Technical Reference Manual available at
+ https://github.com/sophgo/sophgo-doc/tree/main/SG200X/TRM
+
+maintainers:
+ - sophgo@lists.linux.dev
+
+allOf:
+ - $ref: /schemas/rtc/rtc.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: sophgo,cv1800b-rtc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: RTC Alarm
+ - description: RTC Longpress
+ - description: VBAT DET
+
+ interrupt-names:
+ items:
+ - const: alarm
+ - const: longpress
+ - const: vbat
+
+ clocks:
+ items:
+ - description: RTC clock source
+ - description: DW8051 MCU clock source
+
+ clock-names:
+ items:
+ - const: rtc
+ - const: mcu
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sophgo,cv1800.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rtc@5025000 {
+ compatible = "sophgo,cv1800b-rtc", "syscon";
+ reg = <0x5025000 0x2000>;
+ interrupts = <17 IRQ_TYPE_LEVEL_HIGH>,
+ <18 IRQ_TYPE_LEVEL_HIGH>,
+ <19 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "alarm", "longpress", "vbat";
+ clocks = <&clk CLK_RTC_25M>,
+ <&clk CLK_SRC_RTC_SYS_0>;
+ clock-names = "rtc", "mcu";
+ };
diff --git a/Documentation/devicetree/bindings/rtc/spear-rtc.txt b/Documentation/devicetree/bindings/rtc/spear-rtc.txt
deleted file mode 100644
index fecf8e4ad4b4..000000000000
--- a/Documentation/devicetree/bindings/rtc/spear-rtc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* SPEAr RTC
-
-Required properties:
-- compatible : "st,spear600-rtc"
-- reg : Address range of the rtc registers
-- interrupt: Should contain the rtc interrupt number
-
-Example:
-
- rtc@fc000000 {
- compatible = "st,spear600-rtc";
- reg = <0xfc000000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <12>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
new file mode 100644
index 000000000000..5756f617df36
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/sprd,sc2731-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC2731 Real Time Clock
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,sc2731-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: rtc.yaml#
+
+unevaluatedProperties: false
+...
diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt b/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt
deleted file mode 100644
index 1f5754299d31..000000000000
--- a/Documentation/devicetree/bindings/rtc/sprd,sc27xx-rtc.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Spreadtrum SC27xx Real Time Clock
-
-Required properties:
-- compatible: should be "sprd,sc2731-rtc".
-- reg: address offset of rtc register.
-- interrupts: rtc alarm interrupt.
-
-Example:
-
- sc2731_pmic: pmic@0 {
- compatible = "sprd,sc2731";
- reg = <0>;
- spi-max-frequency = <26000000>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-controller;
- #interrupt-cells = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- rtc@280 {
- compatible = "sprd,sc2731-rtc";
- reg = <0x280>;
- interrupt-parent = <&sc2731_pmic>;
- interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
- };
- };
diff --git a/Documentation/devicetree/bindings/rtc/st,m41t80.yaml b/Documentation/devicetree/bindings/rtc/st,m41t80.yaml
new file mode 100644
index 000000000000..fc9c6da6483f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/st,m41t80.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/st,m41t80.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST M41T80 family of RTC and compatible
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - st,m41t62
+ - st,m41t65
+ - st,m41t80
+ - st,m41t81
+ - st,m41t81s
+ - st,m41t82
+ - st,m41t83
+ - st,m41t84
+ - st,m41t85
+ - st,m41t87
+ - microcrystal,rv4162
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ maxItems: 1
+ description: From common clock binding to override the default output clock name.
+
+ clock:
+ type: object
+ $ref: /schemas/clock/fixed-clock.yaml#
+ properties:
+ clock-frequency:
+ const: 32768
+
+allOf:
+ - $ref: rtc.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rtc@68 {
+ compatible = "st,m41t80";
+ reg = <0x68>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x9 0x8>;
+
+ clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/st,m48t86.yaml b/Documentation/devicetree/bindings/rtc/st,m48t86.yaml
new file mode 100644
index 000000000000..e3e12fa23380
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/st,m48t86.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/st,m48t86.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST M48T86 / Dallas DS12887 RTC with SRAM
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: rtc.yaml
+
+properties:
+ compatible:
+ enum:
+ - st,m48t86
+
+ reg:
+ items:
+ - description: index register
+ - description: data register
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@10800000 {
+ compatible = "st,m48t86";
+ reg = <0x10800000 0x1>, <0x11700000 0x1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml
index 764717ce1873..aae06e570c22 100644
--- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/rtc/st,stm32-rtc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Real Time Clock Bindings
+title: STMicroelectronics STM32 Real Time Clock
maintainers:
- Gabriel Fernandez <gabriel.fernandez@foss.st.com>
@@ -15,6 +15,7 @@ properties:
- st,stm32-rtc
- st,stm32h7-rtc
- st,stm32mp1-rtc
+ - st,stm32mp25-rtc
reg:
maxItems: 1
@@ -32,7 +33,7 @@ properties:
maxItems: 1
st,syscfg:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ $ref: /schemas/types.yaml#/definitions/phandle-array
items:
minItems: 3
maxItems: 3
@@ -52,6 +53,28 @@ properties:
override default rtc_ck parent clock phandle of the new parent clock of rtc_ck
maxItems: 1
+patternProperties:
+ "^rtc-[a-z]+-[0-9]+$":
+ type: object
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+ description: |
+ Configuration of STM32 RTC pins description. STM32 RTC is able to output
+ some signals on specific pins:
+ - LSCO (Low Speed Clock Output) that allow to output LSE clock on a pin.
+ - Alarm out that allow to send a pulse on a pin when alarm A of the RTC
+ expires.
+ additionalProperties: false
+ properties:
+ function:
+ enum:
+ - lsco
+ - alarm-a
+ pins:
+ enum:
+ - out1
+ - out2
+ - out2_rmp
+
allOf:
- if:
properties:
@@ -67,6 +90,9 @@ allOf:
clock-names: false
+ patternProperties:
+ "^rtc-[a-z]+-[0-9]+$": false
+
required:
- st,syscfg
@@ -82,6 +108,9 @@ allOf:
minItems: 2
maxItems: 2
+ patternProperties:
+ "^rtc-[a-z]+-[0-9]+$": false
+
required:
- clock-names
- st,syscfg
@@ -90,7 +119,9 @@ allOf:
properties:
compatible:
contains:
- const: st,stm32mp1-rtc
+ enum:
+ - st,stm32mp1-rtc
+ - st,stm32mp25-rtc
then:
properties:
diff --git a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt b/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt
deleted file mode 100644
index fa6a94226669..000000000000
--- a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* STMP3xxx/i.MX28 Time Clock controller
-
-Required properties:
-- compatible: should be one of the following.
- * "fsl,stmp3xxx-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: rtc alarm interrupt
-
-Optional properties:
-- stmp,crystal-freq: override crystal frequency as determined from fuse bits.
- Only <32000> and <32768> are possible for the hardware. Use <0> for
- "no crystal".
-
-Example:
-
-rtc@80056000 {
- compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc";
- reg = <0x80056000 2000>;
- interrupts = <29>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml
index d995ef04a6eb..df5b4f77f6fb 100644
--- a/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml
@@ -13,7 +13,7 @@ description: |
This RTC appears in the AM62x family of SoCs.
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index d9fc120c61cc..b47822370d6f 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -15,7 +15,7 @@ description: |
possibly an interrupt line.
allOf:
- - $ref: "rtc.yaml#"
+ - $ref: rtc.yaml#
properties:
compatible:
@@ -24,39 +24,47 @@ properties:
- abracon,abb5zes3
# AB-RTCMC-32.768kHz-EOZ9: Real Time Clock/Calendar Module with I2C Interface
- abracon,abeoz9
+ # ASPEED BMC ast2400 Real-time Clock
+ - aspeed,ast2400-rtc
+ # ASPEED BMC ast2500 Real-time Clock
+ - aspeed,ast2500-rtc
+ # ASPEED BMC ast2600 Real-time Clock
+ - aspeed,ast2600-rtc
+ # Conexant Digicolor Real Time Clock Controller
+ - cnxt,cx92755-rtc
# I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
- dallas,ds1374
# Dallas DS1672 Real-time Clock
- dallas,ds1672
# Extremely Accurate I²C RTC with Integrated Crystal and SRAM
- dallas,ds3232
+ # Dallas m41t00 Real-time Clock
+ - dallas,m41t00
+ # SD2405AL Real-Time Clock
+ - dfrobot,sd2405al
# EM Microelectronic EM3027 RTC
- emmicro,em3027
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
- epson,rx8010
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
- - epson,rx8025
- epson,rx8035
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE with Battery Backed RAM
+ - epson,rx8111
- epson,rx8571
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
- epson,rx8581
- # Intersil ISL1208 Low Power RTC with Battery Backed SRAM
- - isil,isl1208
- # Intersil ISL1218 Low Power RTC with Battery Backed SRAM
- - isil,isl1218
- # Intersil ISL12022 Real-time Clock
- - isil,isl12022
- # Real Time Clock Module with I2C-Bus
- - microcrystal,rv3028
+ # Android Goldfish Real-time Clock
+ - google,goldfish-rtc
+ # Mvebu Real-time Clock
+ - marvell,orion-rtc
+ # Maxim DS1742/DS1743 Real-time Clock
+ - maxim,ds1742
+ # SPI-BUS INTERFACE REAL TIME CLOCK MODULE
+ - maxim,mcp795
# Real Time Clock Module with I2C-Bus
- microcrystal,rv3029
# Real Time Clock
- microcrystal,rv8523
- - nxp,pca2129
- - nxp,pcf2129
- # Real-time Clock Module
- - pericom,pt7c4338
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
- ricoh,r2025sd
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
@@ -71,10 +79,14 @@ properties:
- ricoh,rv5c387a
# 2-wire CMOS real-time clock
- sii,s35390a
+ # ST SPEAr Real-time Clock
+ - st,spear600-rtc
+ # VIA/Wondermedia VT8500 Real-time Clock
+ - via,vt8500-rtc
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
- whwave,sd3078
- # Xircom X1205 I2C RTC
- - xircom,x1205
+ # Xicor/Intersil X1205 I2C RTC
+ - xicor,x1205
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
deleted file mode 100644
index 8f9a94f2f896..000000000000
--- a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* Texas Instruments TWL4030/6030 RTC
-
-Required properties:
-- compatible : Should be "ti,twl4030-rtc"
-- interrupts : Should be the interrupt number.
-
-Example:
- rtc {
- compatible = "ti,twl4030-rtc";
- interrupts = <11>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt b/Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
deleted file mode 100644
index 3c0484c49582..000000000000
--- a/Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 Realtime Clock Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-rtc"
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : alarm interrupt
-
-Example:
-
- rtc@d8100000 {
- compatible = "via,vt8500-rtc";
- reg = <0xd8100000 0x10000>;
- interrupts = <48>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/xgene-rtc.txt b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt
deleted file mode 100644
index fd195c358446..000000000000
--- a/Documentation/devicetree/bindings/rtc/xgene-rtc.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* APM X-Gene Real Time Clock
-
-RTC controller for the APM X-Gene Real Time Clock
-
-Required properties:
-- compatible : Should be "apm,xgene-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: IRQ line for the RTC.
-- #clock-cells: Should be 1.
-- clocks: Reference to the clock entry.
-
-Example:
-
-rtcclk: rtcclk {
- compatible = "fixed-clock";
- #clock-cells = <1>;
- clock-frequency = <100000000>;
- clock-output-names = "rtcclk";
-};
-
-rtc: rtc@10510000 {
- compatible = "apm,xgene-rtc";
- reg = <0x0 0x10510000 0x0 0x400>;
- interrupts = <0x0 0x46 0x4>;
- #clock-cells = <1>;
- clocks = <&rtcclk 0>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml
index 7ed0230f6c67..01cc90fee81e 100644
--- a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml
@@ -11,14 +11,20 @@ description:
The RTC controller has separate IRQ lines for seconds and alarm.
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- $ref: rtc.yaml#
properties:
compatible:
- const: xlnx,zynqmp-rtc
+ oneOf:
+ - const: xlnx,zynqmp-rtc
+ - items:
+ - enum:
+ - xlnx,versal-rtc
+ - xlnx,versal-net-rtc
+ - const: xlnx,zynqmp-rtc
reg:
maxItems: 1
@@ -48,6 +54,9 @@ properties:
default: 0x198233
deprecated: true
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/security/tpm/google,cr50.txt b/Documentation/devicetree/bindings/security/tpm/google,cr50.txt
deleted file mode 100644
index cd69c2efdd37..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/google,cr50.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* H1 Secure Microcontroller with Cr50 Firmware on SPI Bus.
-
-H1 Secure Microcontroller running Cr50 firmware provides several
-functions, including TPM-like functionality. It communicates over
-SPI using the FIFO protocol described in the PTP Spec, section 6.
-
-Required properties:
-- compatible: Should be "google,cr50".
-- spi-max-frequency: Maximum SPI frequency.
-
-Example:
-
-&spi0 {
- tpm@0 {
- compatible = "google,cr50";
- reg = <0>;
- spi-max-frequency = <800000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt b/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
deleted file mode 100644
index d89f99971368..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Device Tree Bindings for IBM Virtual Trusted Platform Module(vtpm)
-
-Required properties:
-
-- compatible : property name that conveys the platform architecture
- identifiers, as 'IBM,vtpm'
-- device_type : specifies type of virtual device
-- interrupts : property specifying the interrupt source number and
- sense code associated with this virtual I/O Adapters
-- ibm,my-drc-index : integer index for the connector between the device
- and its parent - present only if Dynamic
- Reconfiguration(DR) Connector is enabled
-- ibm,#dma-address-cells: specifies the number of cells that are used to
- encode the physical address field of dma-window
- properties
-- ibm,#dma-size-cells : specifies the number of cells that are used to
- encode the size field of dma-window properties
-- ibm,my-dma-window : specifies DMA window associated with this virtual
- IOA
-- ibm,loc-code : specifies the unique and persistent location code
- associated with this virtual I/O Adapters
-- linux,sml-base : 64-bit base address of the reserved memory allocated
- for the firmware event log
-- linux,sml-size : size of the memory allocated for the firmware event log
-
-Example (IBM Virtual Trusted Platform Module)
----------------------------------------------
-
- vtpm@30000003 {
- ibm,#dma-size-cells = <0x2>;
- compatible = "IBM,vtpm";
- device_type = "IBM,vtpm";
- ibm,my-drc-index = <0x30000003>;
- ibm,#dma-address-cells = <0x2>;
- linux,sml-base = <0xc60e 0x0>;
- interrupts = <0xa0003 0x0>;
- ibm,my-dma-window = <0x10000003 0x0 0x0 0x0 0x10000000>;
- ibm,loc-code = "U8286.41A.10082DV-V3-C3";
- reg = <0x30000003>;
- linux,sml-size = <0xbce10200>;
- };
diff --git a/Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt b/Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt
deleted file mode 100644
index 0dc121b6eace..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/st33zp24-i2c.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* STMicroelectronics SAS. ST33ZP24 TPM SoC
-
-Required properties:
-- compatible: Should be "st,st33zp24-i2c".
-- clock-frequency: I²C work frequency.
-- reg: address on the bus
-
-Optional ST33ZP24 Properties:
-- interrupts: GPIO interrupt to which the chip is connected
-- lpcpd-gpios: Output GPIO pin used for ST33ZP24 power management D1/D2 state.
-If set, power must be present when the platform is going into sleep/hibernate mode.
-
-Optional SoC Specific Properties:
-- pinctrl-names: Contains only one value - "default".
-- pintctrl-0: Specifies the pin control groups used for this controller.
-
-Example (for ARM-based BeagleBoard xM with ST33ZP24 on I2C2):
-
-&i2c2 {
-
-
- st33zp24: st33zp24@13 {
-
- compatible = "st,st33zp24-i2c";
-
- reg = <0x13>;
- clock-frequency = <400000>;
-
- interrupt-parent = <&gpio5>;
- interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
-
- lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
- };
-};
diff --git a/Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt b/Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt
deleted file mode 100644
index 37198971f17b..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* STMicroelectronics SAS. ST33ZP24 TPM SoC
-
-Required properties:
-- compatible: Should be "st,st33zp24-spi".
-- spi-max-frequency: Maximum SPI frequency (<= 10000000).
-
-Optional ST33ZP24 Properties:
-- interrupts: GPIO interrupt to which the chip is connected
-- lpcpd-gpios: Output GPIO pin used for ST33ZP24 power management D1/D2 state.
-If set, power must be present when the platform is going into sleep/hibernate mode.
-
-Optional SoC Specific Properties:
-- pinctrl-names: Contains only one value - "default".
-- pintctrl-0: Specifies the pin control groups used for this controller.
-
-Example (for ARM-based BeagleBoard xM with ST33ZP24 on SPI4):
-
-&mcspi4 {
-
-
- st33zp24@0 {
-
- compatible = "st,st33zp24-spi";
-
- spi-max-frequency = <10000000>;
-
- interrupt-parent = <&gpio5>;
- interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
-
- lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
- };
-};
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
deleted file mode 100644
index a65d7b71e81a..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Device Tree Bindings for I2C based Trusted Platform Module(TPM)
-
-Required properties:
-
-- compatible : 'manufacturer,model', eg. nuvoton,npct650
-- label : human readable string describing the device, eg. "tpm"
-- linux,sml-base : 64-bit base address of the reserved memory allocated for
- the firmware event log
-- linux,sml-size : size of the memory allocated for the firmware event log
-
-Optional properties:
-
-- powered-while-suspended: present when the TPM is left powered on between
- suspend and resume (makes the suspend/resume
- callbacks do nothing).
-
-Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C)
-----------------------------------------------------------
-
-tpm@57 {
- reg = <0x57>;
- label = "tpm";
- compatible = "nuvoton,npct650", "nuvoton,npct601";
- linux,sml-base = <0x7f 0xfd450000>;
- linux,sml-size = <0x10000>;
-};
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt b/Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt
deleted file mode 100644
index 7c6304426da1..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/tpm_tis_mmio.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Trusted Computing Group MMIO Trusted Platform Module
-
-The TCG defines multi vendor standard for accessing a TPM chip, this
-is the standard protocol defined to access the TPM via MMIO. Typically
-this interface will be implemented over Intel's LPC bus.
-
-Refer to the 'TCG PC Client Specific TPM Interface Specification (TIS)' TCG
-publication for the specification.
-
-Required properties:
-
-- compatible: should contain a string below for the chip, followed by
- "tcg,tpm-tis-mmio". Valid chip strings are:
- * "atmel,at97sc3204"
-- reg: The location of the MMIO registers, should be at least 0x5000 bytes
-- interrupts: An optional interrupt indicating command completion.
-
-Example:
-
- tpm_tis@90000 {
- compatible = "atmel,at97sc3204", "tcg,tpm-tis-mmio";
- reg = <0x90000 0x5000>;
- interrupt-parent = <&EIC0>;
- interrupts = <1 2>;
- };
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt b/Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt
deleted file mode 100644
index b800667da92b..000000000000
--- a/Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Required properties:
-- compatible: should be one of the following
- "st,st33htpm-spi"
- "infineon,slb9670"
- "tcg,tpm_tis-spi"
-- spi-max-frequency: Maximum SPI frequency (depends on TPMs).
-
-Optional SoC Specific Properties:
-- pinctrl-names: Contains only one value - "default".
-- pintctrl-0: Specifies the pin control groups used for this controller.
-
-Example (for ARM-based BeagleBoard xM with TPM_TIS on SPI4):
-
-&mcspi4 {
-
-
- tpm_tis@0 {
-
- compatible = "tcg,tpm_tis-spi";
-
- spi-max-frequency = <10000000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 6258f5f59b19..167ddcbd8800 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -4,13 +4,14 @@
$id: http://devicetree.org/schemas/serial/8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: UART (Universal Asynchronous Receiver/Transmitter) bindings
+title: UART (Universal Asynchronous Receiver/Transmitter)
maintainers:
- devicetree@vger.kernel.org
allOf:
- $ref: serial.yaml#
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
- if:
anyOf:
- required:
@@ -44,9 +45,53 @@ allOf:
- ns16550
- ns16550a
then:
- anyOf:
+ oneOf:
- required: [ clock-frequency ]
- required: [ clocks ]
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nxp,lpc1850-uart
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: uartclk
+ - const: reg
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: spacemit,k1-uart
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - spacemit,k1-uart
+ - nxp,lpc1850-uart
+ then:
+ required:
+ - clocks
+ - clock-names
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
properties:
compatible:
@@ -62,7 +107,6 @@ properties:
- const: mrvl,pxa-uart
- const: nuvoton,wpcm450-uart
- const: nuvoton,npcm750-uart
- - const: nuvoton,npcm845-uart
- const: nvidia,tegra20-uart
- const: nxp,lpc3220-uart
- items:
@@ -77,15 +121,17 @@ properties:
- altr,16550-FIFO64
- altr,16550-FIFO128
- fsl,16550-FIFO64
- - fsl,ns16550
- andestech,uart16550
- nxp,lpc1850-uart
- opencores,uart16550-rtlsvn105
- ti,da830-uart
+ - loongson,ls2k0500-uart
+ - loongson,ls2k1500-uart
- const: ns16550a
- items:
- enum:
- ns16750
+ - fsl,ns16550
- cavium,octeon-3860-uart
- xlnx,xps-uart16550-2.00.b
- ralink,rt2880-uart
@@ -94,6 +140,10 @@ properties:
- ns16550a
- items:
- enum:
+ - nuvoton,npcm845-uart
+ - const: nuvoton,npcm750-uart
+ - items:
+ - enum:
- ralink,mt7620a-uart
- ralink,rt3052-uart
- ralink,rt3883-uart
@@ -107,7 +157,9 @@ properties:
- mediatek,mt7623-btif
- const: mediatek,mtk-btif
- items:
- - const: mrvl,mmp-uart
+ - enum:
+ - mrvl,mmp-uart
+ - spacemit,k1-uart
- const: intel,xscale-uart
- items:
- enum:
@@ -119,6 +171,18 @@ properties:
- nvidia,tegra194-uart
- nvidia,tegra234-uart
- const: nvidia,tegra20-uart
+ - items:
+ - enum:
+ - loongson,ls2k1000-uart
+ - const: loongson,ls2k0500-uart
+ - const: ns16550a
+ - items:
+ - enum:
+ - loongson,ls3a5000-uart
+ - loongson,ls3a6000-uart
+ - loongson,ls2k2000-uart
+ - const: loongson,ls2k1500-uart
+ - const: ns16550a
reg:
maxItems: 1
@@ -129,7 +193,32 @@ properties:
clock-frequency: true
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: The core function clock
+ - description: An optional bus clock
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+ oneOf:
+ - enum:
+ - main
+ - uart
+ - items:
+ - const: core
+ - const: bus
+ - items:
+ - const: uartclk
+ - const: reg
+
+ dmas:
+ minItems: 1
+ maxItems: 4
+
+ dma-names:
+ minItems: 1
+ maxItems: 4
resets:
maxItems: 1
@@ -200,12 +289,13 @@ properties:
deprecated: true
aspeed,lpc-io-reg:
- $ref: '/schemas/types.yaml#/definitions/uint32'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 1
description: |
The VUART LPC address. Only applicable to aspeed,ast2500-vuart.
aspeed,lpc-interrupts:
- $ref: "/schemas/types.yaml#/definitions/uint32-array"
+ $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
description: |
diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml
index 7b34ec8fa90e..aabacca2b2fa 100644
--- a/Documentation/devicetree/bindings/serial/8250_omap.yaml
+++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/serial/8250_omap.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for 8250 compliant UARTs on TI's OMAP2+ and K3 SoCs
+title: 8250 compliant UARTs on TI's OMAP2+ and K3 SoCs
maintainers:
- Vignesh Raghavendra <vigneshr@ti.com>
@@ -64,22 +64,28 @@ properties:
clock-names:
const: fclk
- rts-gpios: true
- cts-gpios: true
- dtr-gpios: true
- dsr-gpios: true
- rng-gpios: true
- dcd-gpios: true
- rs485-rts-delay: true
- rs485-rts-active-low: true
- rs485-rx-during-tx: true
rs485-rts-active-high: true
- linux,rs485-enabled-at-boot-time: true
- rts-gpio: true
power-domains: true
clock-frequency: true
current-speed: true
overrun-throttle-ms: true
+ wakeup-source: true
+
+ pinctrl-0:
+ description: Default pinctrl state
+
+ pinctrl-1:
+ description: Wakeup pinctrl state
+
+ pinctrl-names:
+ description:
+ When present should contain at least "default" describing the default pin
+ states. The second state called "wakeup" describes the pins in their
+ wakeup configuration required to exit sleep states.
+ minItems: 1
+ items:
+ - const: default
+ - const: wakeup
required:
- compatible
@@ -109,12 +115,12 @@ else:
examples:
- |
- serial@49042000 {
- compatible = "ti,omap3-uart";
- reg = <0x49042000 0x400>;
- interrupts = <80>;
- dmas = <&sdma 81 &sdma 82>;
- dma-names = "tx", "rx";
- ti,hwmods = "uart4";
- clock-frequency = <48000000>;
- };
+ serial@49042000 {
+ compatible = "ti,omap3-uart";
+ reg = <0x49042000 0x400>;
+ interrupts = <80>;
+ dmas = <&sdma 81 &sdma 82>;
+ dma-names = "tx", "rx";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt b/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
deleted file mode 100644
index aa873eada02d..000000000000
--- a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Actions Semi Owl UART
-
-Required properties:
-- compatible : "actions,s500-uart", "actions,owl-uart" for S500
- "actions,s900-uart", "actions,owl-uart" for S900
-- reg : Offset and length of the register set for the device.
-- interrupts : Should contain UART interrupt.
-
-
-Example:
-
- uart3: serial@b0126000 {
- compatible = "actions,s500-uart", "actions,owl-uart";
- reg = <0xb0126000 0x1000>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
new file mode 100644
index 000000000000..ab1c4514ae93
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/actions,owl-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl UART
+
+maintainers:
+ - Kanak Shilledar <kanakshilledar111@protonmail.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - actions,s500-uart
+ - actions,s900-uart
+ - const: actions,owl-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/actions,s500-cmu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ uart0: serial@b0126000 {
+ compatible = "actions,s500-uart", "actions,owl-uart";
+ reg = <0xb0126000 0x1000>;
+ clocks = <&cmu CLK_UART0>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/altera_jtaguart.txt b/Documentation/devicetree/bindings/serial/altera_jtaguart.txt
deleted file mode 100644
index 55a901051e8f..000000000000
--- a/Documentation/devicetree/bindings/serial/altera_jtaguart.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-Altera JTAG UART
-
-Required properties:
-- compatible : should be "ALTR,juart-1.0" <DEPRECATED>
-- compatible : should be "altr,juart-1.0"
diff --git a/Documentation/devicetree/bindings/serial/altera_uart.txt b/Documentation/devicetree/bindings/serial/altera_uart.txt
deleted file mode 100644
index 81bf7ffb1a81..000000000000
--- a/Documentation/devicetree/bindings/serial/altera_uart.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Altera UART
-
-Required properties:
-- compatible : should be "ALTR,uart-1.0" <DEPRECATED>
-- compatible : should be "altr,uart-1.0"
-
-Optional properties:
-- clock-frequency : frequency of the clock input to the UART
diff --git a/Documentation/devicetree/bindings/serial/altr,juart-1.0.yaml b/Documentation/devicetree/bindings/serial/altr,juart-1.0.yaml
new file mode 100644
index 000000000000..02e20fa591da
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/altr,juart-1.0.yaml
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/altr,juart-1.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera JTAG UART
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+
+properties:
+ compatible:
+ const: altr,juart-1.0
+
+required:
+ - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/serial/altr,uart-1.0.yaml b/Documentation/devicetree/bindings/serial/altr,uart-1.0.yaml
new file mode 100644
index 000000000000..72d4972e1e22
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/altr,uart-1.0.yaml
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/altr,uart-1.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera UART
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: altr,uart-1.0
+
+ clock-frequency:
+ description: Frequency of the clock input to the UART.
+
+required:
+ - compatible
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
index 7822705ad16c..d8ad1bb6172d 100644
--- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson SoC UART Serial Interface
@@ -19,6 +19,9 @@ description: |
is active since power-on and does not need any clock gating and is usable
as very early serial console.
+allOf:
+ - $ref: serial.yaml#
+
properties:
compatible:
oneOf:
@@ -30,6 +33,12 @@ properties:
- amlogic,meson8b-uart
- amlogic,meson-gx-uart
- amlogic,meson-s4-uart
+ - amlogic,meson-a1-uart
+ - const: amlogic,meson-ao-uart
+ - description: Always-on power domain UART controller on G12A SoCs
+ items:
+ - const: amlogic,meson-g12a-uart
+ - const: amlogic,meson-gx-uart
- const: amlogic,meson-ao-uart
- description: Everything-Else power domain UART controller
enum:
@@ -38,6 +47,20 @@ properties:
- amlogic,meson8b-uart
- amlogic,meson-gx-uart
- amlogic,meson-s4-uart
+ - amlogic,meson-a1-uart
+ - description: Everything-Else power domain UART controller on G12A SoCs
+ items:
+ - const: amlogic,meson-g12a-uart
+ - const: amlogic,meson-gx-uart
+ - description: UART controller on S4 compatible SoCs
+ items:
+ - enum:
+ - amlogic,a4-uart
+ - amlogic,s6-uart
+ - amlogic,s7-uart
+ - amlogic,s7d-uart
+ - amlogic,t7-uart
+ - const: amlogic,meson-s4-uart
reg:
maxItems: 1
@@ -69,14 +92,14 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
serial@84c0 {
- compatible = "amlogic,meson-gx-uart";
- reg = <0x84c0 0x14>;
- interrupts = <26>;
- clocks = <&xtal>, <&pclk>, <&xtal>;
- clock-names = "xtal", "pclk", "baud";
+ compatible = "amlogic,meson-gx-uart";
+ reg = <0x84c0 0x14>;
+ interrupts = <26>;
+ clocks = <&xtal>, <&pclk>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
diff --git a/Documentation/devicetree/bindings/serial/arc-uart.txt b/Documentation/devicetree/bindings/serial/arc-uart.txt
deleted file mode 100644
index 256cc150ca7e..000000000000
--- a/Documentation/devicetree/bindings/serial/arc-uart.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Synopsys ARC UART : Non standard UART used in some of the ARC FPGA boards
-
-Required properties:
-- compatible : "snps,arc-uart"
-- reg : offset and length of the register set for the device.
-- interrupts : device interrupt
-- clock-frequency : the input clock frequency for the UART
-- current-speed : baud rate for UART
-
-e.g.
-
-arcuart0: serial@c0fc1000 {
- compatible = "snps,arc-uart";
- reg = <0xc0fc1000 0x100>;
- interrupts = <5>;
- clock-frequency = <80000000>;
- current-speed = <115200>;
-};
-
-Note: Each port should have an alias correctly numbered in "aliases" node.
-
-e.g.
-aliases {
- serial0 = &arcuart0;
-};
diff --git a/Documentation/devicetree/bindings/serial/arm,dcc.yaml b/Documentation/devicetree/bindings/serial/arm,dcc.yaml
new file mode 100644
index 000000000000..fd0589356617
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/arm,dcc.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/arm,dcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM DCC (Data communication channel) serial emulation
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+
+description: |
+ ARM DCC (Data communication channel) serial emulation interface available
+ via JTAG can be also used as one of serial line tightly coupled with every
+ ARM CPU available in the system.
+
+properties:
+ compatible:
+ const: arm,dcc
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ serial {
+ compatible = "arm,dcc";
+ };
diff --git a/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
deleted file mode 100644
index 128cc6aed001..000000000000
--- a/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-ARM MPS2 UART
-
-Required properties:
-- compatible : Should be "arm,mps2-uart"
-- reg : Address and length of the register set
-- interrupts : Reference to the UART RX, TX and overrun interrupts
-
-Required clocking property:
-- clocks : The input clock of the UART
-
-
-Examples:
-
-uart0: serial@40004000 {
- compatible = "arm,mps2-uart";
- reg = <0x40004000 0x1000>;
- interrupts = <0 1 12>;
- clocks = <&sysclk>;
-};
diff --git a/Documentation/devicetree/bindings/serial/arm,mps2-uart.yaml b/Documentation/devicetree/bindings/serial/arm,mps2-uart.yaml
new file mode 100644
index 000000000000..4a8df078e6f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/arm,mps2-uart.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/arm,mps2-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm MPS2 UART
+
+maintainers:
+ - Vladimir Murzin <vladimir.murzin@arm.com>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: arm,mps2-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: RX interrupt
+ - description: TX interrupt
+ - description: Overrun interrupt
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@40004000 {
+ compatible = "arm,mps2-uart";
+ reg = <0x40004000 0x1000>;
+ interrupts = <0>, <1>, <12>;
+ clocks = <&sysclk>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/arm,sbsa-uart.yaml b/Documentation/devicetree/bindings/serial/arm,sbsa-uart.yaml
new file mode 100644
index 000000000000..68e3fd64b1d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/arm,sbsa-uart.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+---
+$id: http://devicetree.org/schemas/serial/arm,sbsa-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SBSA UART
+
+maintainers:
+ - Andre Przywara <andre.przywara@arm.com>
+
+description:
+ This UART uses a subset of the PL011 registers and consequently lives in the
+ PL011 driver. It's baudrate and other communication parameters cannot be
+ adjusted at runtime, so it lacks a clock specifier here.
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: arm,sbsa-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ current-speed:
+ description: fixed baud rate set by the firmware
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - current-speed
+
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
deleted file mode 100644
index 4163e7eb7763..000000000000
--- a/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-* ARM SBSA defined generic UART
-This UART uses a subset of the PL011 registers and consequently lives
-in the PL011 driver. It's baudrate and other communication parameters
-cannot be adjusted at runtime, so it lacks a clock specifier here.
-
-Required properties:
-- compatible: must be "arm,sbsa-uart"
-- reg: exactly one register range
-- interrupts: exactly one interrupt specifier
-- current-speed: the (fixed) baud rate set by the firmware
diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
new file mode 100644
index 000000000000..087a8926f8b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
@@ -0,0 +1,200 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/atmel,at91-usart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
+
+maintainers:
+ - Richard Genoud <richard.genoud@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91rm9200-usart
+ - atmel,at91sam9260-usart
+ - items:
+ - const: atmel,at91rm9200-dbgu
+ - const: atmel,at91rm9200-usart
+ - items:
+ - const: atmel,at91sam9260-dbgu
+ - const: atmel,at91sam9260-usart
+ - items:
+ - enum:
+ - microchip,sam9x60-usart
+ - microchip,sam9x7-usart
+ - microchip,sama7d65-usart
+ - const: atmel,at91sam9260-usart
+ - items:
+ - const: microchip,sam9x60-dbgu
+ - const: microchip,sam9x60-usart
+ - const: atmel,at91sam9260-dbgu
+ - const: atmel,at91sam9260-usart
+ - items:
+ - const: microchip,sam9x7-dbgu
+ - const: atmel,at91sam9260-dbgu
+ - const: microchip,sam9x7-usart
+ - const: atmel,at91sam9260-usart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: usart
+ - const: gclk
+
+ clocks:
+ minItems: 1
+ items:
+ - description: USART Peripheral Clock
+ - description: USART Generic Clock
+
+ dmas:
+ items:
+ - description: TX DMA Channel
+ - description: RX DMA Channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ atmel,usart-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Must be either <AT91_USART_MODE_SPI> for SPI or
+ <AT91_USART_MODE_SERIAL> for USART (found in dt-bindings/mfd/at91-usart.h).
+ enum: [ 0, 1 ]
+
+ atmel,use-dma-rx:
+ type: boolean
+ description: use of PDC or DMA for receiving data
+
+ atmel,use-dma-tx:
+ type: boolean
+ description: use of PDC or DMA for transmitting data
+
+ atmel,fifo-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum number of data the RX and TX FIFOs can store for FIFO
+ capable USARTS.
+ enum: [ 16, 32 ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clock-names
+ - clocks
+ - atmel,usart-mode
+
+allOf:
+ - if:
+ properties:
+ atmel,usart-mode:
+ const: 1
+ then:
+ allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+ properties:
+ atmel,use-dma-rx: false
+
+ atmel,use-dma-tx: false
+
+ atmel,fifo-size: false
+
+ "#size-cells":
+ const: 0
+
+ "#address-cells":
+ const: 1
+
+ required:
+ - "#size-cells"
+ - "#address-cells"
+
+ else:
+ allOf:
+ - $ref: /schemas/serial/serial.yaml#
+ - $ref: /schemas/serial/rs485.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/at91-usart.h>
+ #include <dt-bindings/dma/at91.h>
+
+ /* use PDC */
+ usart0: serial@fff8c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff8c000 0x4000>;
+ atmel,usart-mode = <AT91_USART_MODE_SERIAL>;
+ interrupts = <7>;
+ clocks = <&usart0_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>;
+ cts-gpios = <&pioD 16 GPIO_ACTIVE_LOW>;
+ dtr-gpios = <&pioD 17 GPIO_ACTIVE_LOW>;
+ dsr-gpios = <&pioD 18 GPIO_ACTIVE_LOW>;
+ dcd-gpios = <&pioD 20 GPIO_ACTIVE_LOW>;
+ rng-gpios = <&pioD 19 GPIO_ACTIVE_LOW>;
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/at91-usart.h>
+ #include <dt-bindings/dma/at91.h>
+
+ /* use DMA */
+ usart1: serial@f001c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xf001c000 0x100>;
+ atmel,usart-mode = <AT91_USART_MODE_SERIAL>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
+ clocks = <&usart0_clk>;
+ clock-names = "usart";
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
+ <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
+ dma-names = "tx", "rx";
+ atmel,fifo-size = <32>;
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/at91-usart.h>
+ #include <dt-bindings/dma/at91.h>
+
+ /* SPI mode */
+ spi0: spi@f001c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xf001c000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ atmel,usart-mode = <AT91_USART_MODE_SPI>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
+ clocks = <&usart0_clk>;
+ clock-names = "usart";
+ dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
+ <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
+ dma-names = "tx", "rx";
+ cs-gpios = <&pioB 3 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.txt b/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.txt
deleted file mode 100644
index b5cc6297cd1b..000000000000
--- a/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* BCM2835 AUXILIAR UART
-
-Required properties:
-
-- compatible: "brcm,bcm2835-aux-uart"
-- reg: The base address of the UART register bank.
-- interrupts: A single interrupt specifier.
-- clocks: Clock driving the hardware; used to figure out the baud rate
- divisor.
-
-Example:
-
- uart1: serial@7e215040 {
- compatible = "brcm,bcm2835-aux-uart";
- reg = <0x7e215040 0x40>;
- interrupts = <1 29>;
- clocks = <&aux BCM2835_AUX_CLOCK_UART>;
- };
diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.yaml
new file mode 100644
index 000000000000..6b72459f7dc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/brcm,bcm2835-aux-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 AUXILIARY UART
+
+maintainers:
+ - Pratik Farkase <pratikfarkase94@gmail.com>
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Stefan Wahren <wahrenst@gmx.net>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ const: brcm,bcm2835-aux-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835-aux.h>
+ serial@7e215040 {
+ compatible = "brcm,bcm2835-aux-uart";
+ reg = <0x7e215040 0x40>;
+ interrupts = <1 29>;
+ clocks = <&aux BCM2835_AUX_CLOCK_UART>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml
index 6d176588df47..8cc848ae11cb 100644
--- a/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/serial/brcm,bcm7271-uart.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom 8250 based serial port devicetree bindings
+title: Broadcom 8250 based serial port
maintainers:
- Al Cooper <alcooperx@gmail.com>
@@ -41,7 +41,7 @@ properties:
- const: dma_intr2
clocks:
- minItems: 1
+ maxItems: 1
clock-names:
const: sw_baud
diff --git a/Documentation/devicetree/bindings/serial/cavium-uart.txt b/Documentation/devicetree/bindings/serial/cavium-uart.txt
deleted file mode 100644
index 87a6c375cd44..000000000000
--- a/Documentation/devicetree/bindings/serial/cavium-uart.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* Universal Asynchronous Receiver/Transmitter (UART)
-
-- compatible: "cavium,octeon-3860-uart"
-
- Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
-
-- reg: The base address of the UART register bank.
-
-- interrupts: A single interrupt specifier.
-
-- current-speed: Optional, the current bit rate in bits per second.
-
-Example:
- uart1: serial@1180000000c00 {
- compatible = "cavium,octeon-3860-uart","ns16550";
- reg = <0x11800 0x00000c00 0x0 0x400>;
- current-speed = <115200>;
- interrupts = <0 35>;
- };
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
index fcdbe6f87e98..9d3e5c1d8502 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml
@@ -4,13 +4,10 @@
$id: http://devicetree.org/schemas/serial/cdns,uart.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence UART Controller Device Tree Bindings
+title: Cadence UART Controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
-
-allOf:
- - $ref: /schemas/serial.yaml#
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
@@ -19,9 +16,10 @@ properties:
items:
- const: xlnx,xuartps
- const: cdns,uart-r1p8
- - description: UART controller for Zynq Ultrascale+ MPSoC
- items:
- - const: xlnx,zynqmp-uart
+ - items:
+ - enum:
+ - axiado,ax3000-uart
+ - xlnx,zynqmp-uart
- const: cdns,uart-r1p12
reg:
@@ -46,6 +44,12 @@ properties:
port does not use this pin.
type: boolean
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -53,14 +57,26 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: serial.yaml#
+ - $ref: rs485.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: cdns,uart-r1p8
+ then:
+ properties:
+ power-domains: false
+
unevaluatedProperties: false
examples:
- |
uart0: serial@e0000000 {
- compatible = "xlnx,xuartps", "cdns,uart-r1p8";
- clocks = <&clkc 23>, <&clkc 40>;
- clock-names = "uart_clk", "pclk";
- reg = <0xE0000000 0x1000>;
- interrupts = <0 27 4>;
+ compatible = "xlnx,xuartps", "cdns,uart-r1p8";
+ clocks = <&clkc 23>, <&clkc 40>;
+ clock-names = "uart_clk", "pclk";
+ reg = <0xe0000000 0x1000>;
+ interrupts = <0 27 4>;
};
diff --git a/Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt b/Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt
deleted file mode 100644
index 07013fa60a48..000000000000
--- a/Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-* Cirrus Logic CLPS711X Universal Asynchronous Receiver/Transmitter (UART)
-
-Required properties:
-- compatible: Should be "cirrus,ep7209-uart".
-- reg: Address and length of the register set for the device.
-- interrupts: Should contain UART TX and RX interrupt.
-- clocks: Should contain UART core clock number.
-- syscon: Phandle to SYSCON node, which contain UART control bits.
-
-Optional properties:
-- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD
- line respectively.
-
-Note: Each UART port should have an alias correctly numbered
-in "aliases" node.
-
-Example:
- aliases {
- serial0 = &uart1;
- };
-
- uart1: uart@80000480 {
- compatible = "cirrus,ep7312-uart","cirrus,ep7209-uart";
- reg = <0x80000480 0x80>;
- interrupts = <12 13>;
- clocks = <&clks 11>;
- syscon = <&syscon1>;
- cts-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>;
- dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>;
- dcd-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/serial/cirrus,ep7209-uart.yaml b/Documentation/devicetree/bindings/serial/cirrus,ep7209-uart.yaml
new file mode 100644
index 000000000000..c9976e86872b
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/cirrus,ep7209-uart.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/cirrus,ep7209-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CLPS711X Universal Asynchronous Receiver/Transmitter (UART)
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: cirrus,ep7209-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: UART TX interrupt
+ - description: UART RX interrupt
+
+ clocks:
+ maxItems: 1
+
+ syscon:
+ description: Phandle to SYSCON node, which contains UART control bits.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - syscon
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ serial@80000480 {
+ compatible = "cirrus,ep7209-uart";
+ reg = <0x80000480 0x80>;
+ interrupts = <12>, <13>;
+ clocks = <&clks 11>;
+ syscon = <&syscon1>;
+ cts-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>;
+ dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>;
+ dcd-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/cnxt,cx92755-usart.yaml b/Documentation/devicetree/bindings/serial/cnxt,cx92755-usart.yaml
new file mode 100644
index 000000000000..720229455330
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/cnxt,cx92755-usart.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/cnxt,cx92755-usart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Conexant Digicolor USART
+
+maintainers:
+ - Baruch Siach <baruch@tkos.co.il>
+
+description: >
+ Note: this binding is only applicable for using the USART peripheral as UART.
+ USART also support synchronous serial protocols like SPI and I2S.
+ Use the binding that matches the wiring of your system.
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: cnxt,cx92755-usart
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@f0000740 {
+ compatible = "cnxt,cx92755-usart";
+ reg = <0xf0000740 0x20>;
+ clocks = <&main_clk>;
+ interrupts = <44>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/digicolor-usart.txt b/Documentation/devicetree/bindings/serial/digicolor-usart.txt
deleted file mode 100644
index 2d3ede66889d..000000000000
--- a/Documentation/devicetree/bindings/serial/digicolor-usart.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Binding for Conexant Digicolor USART
-
-Note: this binding is only applicable for using the USART peripheral as
-UART. USART also support synchronous serial protocols like SPI and I2S. Use
-the binding that matches the wiring of your system.
-
-Required properties:
-- compatible : should be "cnxt,cx92755-usart".
-- reg: Should contain USART controller registers location and length.
-- interrupts: Should contain a single USART controller interrupt.
-- clocks: Must contain phandles to the USART clock
- See ../clocks/clock-bindings.txt for details.
-
-Note: Each UART port should have an alias correctly numbered
-in "aliases" node.
-
-Example:
- aliases {
- serial0 = &uart0;
- };
-
- uart0: uart@f0000740 {
- compatible = "cnxt,cx92755-usart";
- reg = <0xf0000740 0x20>;
- clocks = <&main_clk>;
- interrupts = <44>;
- };
diff --git a/Documentation/devicetree/bindings/serial/esp,esp32-acm.yaml b/Documentation/devicetree/bindings/serial/esp,esp32-acm.yaml
new file mode 100644
index 000000000000..77fbb2c72171
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/esp,esp32-acm.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/esp,esp32-acm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESP32S3 ACM gadget controller
+
+maintainers:
+ - Max Filippov <jcmvbkbc@gmail.com>
+
+description:
+ Fixed function USB CDC-ACM gadget controller of the Espressif ESP32S3 SoC.
+
+allOf:
+ - $ref: serial.yaml#
+
+properties:
+ compatible:
+ const: esp,esp32s3-acm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ serial@60038000 {
+ compatible = "esp,esp32s3-acm";
+ reg = <0x60038000 0x1000>;
+ interrupts = <96 3 0>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/esp,esp32-uart.yaml b/Documentation/devicetree/bindings/serial/esp,esp32-uart.yaml
new file mode 100644
index 000000000000..2a80ca997a0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/esp,esp32-uart.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/esp,esp32-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESP32xx UART controllers
+
+maintainers:
+ - Max Filippov <jcmvbkbc@gmail.com>
+
+description:
+ ESP32 UART controller is a part of the ESP32 SoC.
+ ESP32S3 UART controller is a part of the ESP32S3 SoC.
+ Both SoCs are produced by Espressif Systems Co. Ltd.
+
+allOf:
+ - $ref: serial.yaml#
+
+properties:
+ compatible:
+ enum:
+ - esp,esp32-uart
+ - esp,esp32s3-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ serial@60000000 {
+ compatible = "esp,esp32s3-uart";
+ reg = <0x60000000 0x80>;
+ interrupts = <27 1 0>;
+ clocks = <&serial_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
index 8b643bae3c7b..4171f524a928 100644
--- a/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl,s32-linflexuart.yaml
@@ -13,17 +13,19 @@ description: |
https://www.nxp.com/webapp/Download?colCode=S32V234RM.
maintainers:
- - Chester Lin <clin@suse.com>
+ - Chester Lin <chester62515@gmail.com>
allOf:
- - $ref: "serial.yaml"
+ - $ref: serial.yaml#
properties:
compatible:
oneOf:
- const: fsl,s32v234-linflexuart
- items:
- - const: nxp,s32g2-linflexuart
+ - enum:
+ - nxp,s32g2-linflexuart
+ - nxp,s32g3-linflexuart
- const: fsl,s32v234-linflexuart
reg:
diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
index 9d949296a142..9c6dc16f88a6 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
@@ -9,10 +9,6 @@ title: Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART)
maintainers:
- Fabio Estevam <festevam@gmail.com>
-allOf:
- - $ref: "serial.yaml"
- - $ref: "rs485.yaml"
-
properties:
compatible:
oneOf:
@@ -49,8 +45,32 @@ properties:
reg:
maxItems: 1
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: per
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for RX
+ - description: DMA controller phandle and request line for TX
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
interrupts:
- maxItems: 1
+ items:
+ - description: UART RX Interrupt
+ - description: UART TX Interrupt
+ - description: UART RTS Interrupt
+ minItems: 1
+
+ wakeup-source: true
fsl,dte-mode:
$ref: /schemas/types.yaml#/definitions/flag
@@ -83,22 +103,38 @@ properties:
are sensible for most use cases. If you need low latency processing on
slow connections this needs to be configured appropriately.
- uart-has-rtscts: true
-
- rs485-rts-delay: true
- rs485-rts-active-low: true
- rs485-rx-during-tx: true
- linux,rs485-enabled-at-boot-time: true
-
required:
- compatible
- reg
+ - clocks
+ - clock-names
- interrupts
+allOf:
+ - $ref: serial.yaml#
+ - $ref: rs485.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx1-uart
+ then:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 3
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/imx5-clock.h>
+
aliases {
serial0 = &uart1;
};
@@ -107,6 +143,11 @@ examples:
compatible = "fsl,imx51-uart", "fsl,imx21-uart";
reg = <0x73fbc000 0x4000>;
interrupts = <31>;
+ clocks = <&clks IMX5_CLK_UART1_IPG_GATE>,
+ <&clks IMX5_CLK_UART1_PER_GATE>;
+ clock-names = "ipg", "per";
+ dmas = <&sdma 18 4 1>, <&sdma 19 4 2>;
+ dma-names = "rx", "tx";
uart-has-rtscts;
fsl,dte-mode;
};
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
index 30eaa62e1aed..c42261b5a80a 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
@@ -10,7 +10,8 @@ maintainers:
- Fugang Duan <fugang.duan@nxp.com>
allOf:
- - $ref: "rs485.yaml"
+ - $ref: rs485.yaml#
+ - $ref: serial.yaml#
properties:
compatible:
@@ -24,14 +25,23 @@ properties:
- fsl,imxrt1050-lpuart
- items:
- enum:
- - fsl,imx93-lpuart
- fsl,imx8ulp-lpuart
- const: fsl,imx7ulp-lpuart
- items:
- enum:
+ - fsl,imx93-lpuart
+ - fsl,imx94-lpuart
+ - fsl,imx95-lpuart
+ - const: fsl,imx8ulp-lpuart
+ - const: fsl,imx7ulp-lpuart
+ - items:
+ - enum:
- fsl,imx8qm-lpuart
- fsl,imx8dxl-lpuart
- const: fsl,imx8qxp-lpuart
+ - items:
+ - const: fsl,imxrt1050-lpuart
+ - const: fsl,imxrt1170-lpuart
reg:
maxItems: 1
@@ -61,8 +71,8 @@ properties:
- const: rx
- const: tx
- rs485-rts-active-low: true
- linux,rs485-enabled-at-boot-time: true
+ power-domains:
+ maxItems: 1
required:
- compatible
diff --git a/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml
index 14c7594c88c6..da032effffe6 100644
--- a/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.yaml
@@ -10,14 +10,17 @@ maintainers:
- Fabio Estevam <festevam@gmail.com>
allOf:
- - $ref: "serial.yaml"
+ - $ref: serial.yaml#
properties:
compatible:
- enum:
- - fsl,imx23-auart
- - fsl,imx28-auart
- - alphascale,asm9260-auart
+ oneOf:
+ - const: fsl,imx23-auart
+ - const: alphascale,asm9260-auart
+ - items:
+ - enum:
+ - fsl,imx28-auart
+ - const: fsl,imx23-auart
reg:
maxItems: 1
@@ -82,7 +85,7 @@ examples:
};
auart0: serial@8006a000 {
- compatible = "fsl,imx28-auart";
+ compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112>;
dmas = <&dma_apbx 8>, <&dma_apbx 9>;
diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml
index 9ca7a18ecd8b..d5f153bdeb0d 100644
--- a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/serial/ingenic,uart.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs UART controller devicetree bindings
+title: Ingenic SoCs UART controller
maintainers:
- Paul Cercueil <paul@crapouillou.net>
@@ -20,6 +20,7 @@ properties:
oneOf:
- enum:
- ingenic,jz4740-uart
+ - ingenic,jz4750-uart
- ingenic,jz4760-uart
- ingenic,jz4780-uart
- ingenic,x1000-uart
@@ -31,6 +32,9 @@ properties:
- items:
- const: ingenic,jz4725b-uart
- const: ingenic,jz4740-uart
+ - items:
+ - const: ingenic,jz4755-uart
+ - const: ingenic,jz4750-uart
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/serial/lantiq,asc.yaml b/Documentation/devicetree/bindings/serial/lantiq,asc.yaml
new file mode 100644
index 000000000000..96e8c79cb047
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/lantiq,asc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/lantiq,asc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq SoC ASC serial controller
+
+maintainers:
+ - John Crispin <john@phrozen.org>
+ - Songjun Wu <songjun.wu@linux.intel.com>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: lantiq,asc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: TX interrupt
+ - description: RX interrupt
+ - description: Error interrupt
+
+ clocks:
+ items:
+ - description: Frequency clock
+ - description: Gate clock
+
+ clock-names:
+ items:
+ - const: freq
+ - const: asc
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+
+ serial@16600000 {
+ compatible = "lantiq,asc";
+ reg = <0x16600000 0x100000>;
+ interrupts = <GIC_SHARED 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 105 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 106 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
deleted file mode 100644
index 40e81a5818f6..000000000000
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Lantiq SoC ASC serial controller
-
-Required properties:
-- compatible : Should be "lantiq,asc"
-- reg : Address and length of the register set for the device
-- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
- depends on the interrupt-parent interrupt controller.
-
-Optional properties:
-- clocks: Should contain frequency clock and gate clock
-- clock-names: Should be "freq" and "asc"
-
-Example:
-
-asc0: serial@16600000 {
- compatible = "lantiq,asc";
- reg = <0x16600000 0x100000>;
- interrupt-parent = <&gic>;
- interrupts = <GIC_SHARED 103 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SHARED 105 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SHARED 106 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cgu CLK_SSX4>, <&cgu GCLK_UART>;
- clock-names = "freq", "asc";
-};
-
-asc1: serial@e100c00 {
- compatible = "lantiq,asc";
- reg = <0xE100C00 0x400>;
- interrupt-parent = <&icu0>;
- interrupts = <112 113 114>;
-};
diff --git a/Documentation/devicetree/bindings/serial/marvell,armada-3700-uart.yaml b/Documentation/devicetree/bindings/serial/marvell,armada-3700-uart.yaml
new file mode 100644
index 000000000000..6c7fa3d19369
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/marvell,armada-3700-uart.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/marvell,armada-3700-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada-3700 UART
+
+maintainers:
+ - Pali Rohár <pali@kernel.org>
+
+description:
+ Marvell UART is a non standard UART used in some of Marvell EBU SoCs (e.g.
+ Armada-3700).
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-3700-uart
+ - marvell,armada-3700-uart-ext
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ UART reference clock used to derive the baud rate. If absent, only fixed
+ baud rate from the bootloader is supported.
+
+ interrupts:
+ minItems: 2
+ items:
+ - description: UART sum interrupt
+ - description: UART TX interrupt
+ - description: UART RX interrupt
+
+ interrupt-names:
+ minItems: 2
+ maxItems: 3
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+ - if:
+ properties:
+ compatible:
+ const: marvell,armada-3700-uart-ext
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: uart-tx
+ - const: uart-rx
+ else:
+ properties:
+ interrupts:
+ minItems: 3
+
+ interrupt-names:
+ items:
+ - const: uart-sum
+ - const: uart-tx
+ - const: uart-rx
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ serial@12000 {
+ compatible = "marvell,armada-3700-uart";
+ reg = <0x12000 0x18>;
+ clocks = <&uartclk 0>;
+ interrupts =
+ <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uart-sum", "uart-tx", "uart-rx";
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ serial@12200 {
+ compatible = "marvell,armada-3700-uart-ext";
+ reg = <0x12200 0x30>;
+ clocks = <&uartclk 1>;
+ interrupts =
+ <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "uart-tx", "uart-rx";
+ };
diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.txt b/Documentation/devicetree/bindings/serial/maxim,max310x.txt
deleted file mode 100644
index 79e10a05a96a..000000000000
--- a/Documentation/devicetree/bindings/serial/maxim,max310x.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-* Maxim MAX310X advanced Universal Asynchronous Receiver-Transmitter (UART)
-
-Required properties:
-- compatible: Should be one of the following:
- - "maxim,max3107" for Maxim MAX3107,
- - "maxim,max3108" for Maxim MAX3108,
- - "maxim,max3109" for Maxim MAX3109,
- - "maxim,max14830" for Maxim MAX14830.
-- reg: SPI chip select number.
-- interrupts: Specifies the interrupt source of the parent interrupt
- controller. The format of the interrupt specifier depends on the
- parent interrupt controller.
-- clocks: phandle to the IC source clock.
-- clock-names: Should be "xtal" if clock is an external crystal or
- "osc" if an external clock source is used.
-
-Optional properties:
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be two. The first cell is the GPIO number and
- the second cell is used to specify the GPIO polarity:
- 0 = active high,
- 1 = active low.
-
-Example:
-
-/ {
- clocks {
- spi_uart_clk: osc_max14830 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <3686400>;
- };
-
- };
-};
-
-&spi0 {
- max14830: max14830@0 {
- compatible = "maxim,max14830";
- reg = <0>;
- clocks = <&spi_uart_clk>;
- clock-names = "osc";
- interrupt-parent = <&gpio3>;
- interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-};
diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.yaml b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
new file mode 100644
index 000000000000..889eeaca64a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/maxim,max310x.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/maxim,max310x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX310X Advanced Universal Asynchronous Receiver-Transmitter (UART)
+
+maintainers:
+ - Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max3107
+ - maxim,max3108
+ - maxim,max3109
+ - maxim,max14830
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ enum:
+ - xtal # External crystal
+ - osc # External clock source
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 16
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: /schemas/serial/serial.yaml#
+ - $ref: /schemas/serial/rs485.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ serial@2c {
+ compatible = "maxim,max3107";
+ reg = <0x2c>;
+ clocks = <&xtal4m>;
+ clock-names = "xtal";
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml
index 4ff27d6d4d5b..5bd8a8853ae0 100644
--- a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml
+++ b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml
@@ -25,6 +25,7 @@ properties:
- enum:
- mediatek,mt2701-uart
- mediatek,mt2712-uart
+ - mediatek,mt6572-uart
- mediatek,mt6580-uart
- mediatek,mt6582-uart
- mediatek,mt6589-uart
@@ -33,17 +34,22 @@ properties:
- mediatek,mt6779-uart
- mediatek,mt6795-uart
- mediatek,mt6797-uart
+ - mediatek,mt6893-uart
- mediatek,mt7622-uart
- mediatek,mt7623-uart
- mediatek,mt7629-uart
+ - mediatek,mt7981-uart
- mediatek,mt7986-uart
+ - mediatek,mt7988-uart
- mediatek,mt8127-uart
- mediatek,mt8135-uart
- mediatek,mt8173-uart
- mediatek,mt8183-uart
- mediatek,mt8186-uart
+ - mediatek,mt8188-uart
- mediatek,mt8192-uart
- mediatek,mt8195-uart
+ - mediatek,mt8365-uart
- mediatek,mt8516-uart
- const: mediatek,mt6577-uart
diff --git a/Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt b/Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt
deleted file mode 100644
index c8dd440e9747..000000000000
--- a/Documentation/devicetree/bindings/serial/microchip,pic32-uart.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Microchip Universal Asynchronous Receiver Transmitter (UART)
-
-Required properties:
-- compatible: Should be "microchip,pic32mzda-uart"
-- reg: Should contain registers location and length
-- interrupts: Should contain interrupt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the UART peripheral.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-Optional properties:
-- cts-gpios: CTS pin for UART
-
-Example:
- uart1: serial@1f822000 {
- compatible = "microchip,pic32mzda-uart";
- reg = <0x1f822000 0x50>;
- interrupts = <112 IRQ_TYPE_LEVEL_HIGH>,
- <113 IRQ_TYPE_LEVEL_HIGH>,
- <114 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&rootclk PB2CLK>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart1
- &pinctrl_uart1_cts
- &pinctrl_uart1_rts>;
- cts-gpios = <&gpio1 15 0>;
- };
diff --git a/Documentation/devicetree/bindings/serial/microchip,pic32mzda-uart.yaml b/Documentation/devicetree/bindings/serial/microchip,pic32mzda-uart.yaml
new file mode 100644
index 000000000000..b176fd5b580e
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/microchip,pic32mzda-uart.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/microchip,pic32mzda-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 UART
+
+maintainers:
+ - Andrei Pistirica <andrei.pistirica@microchip.com>
+ - Purna Chandra Mandal <purna.mandal@microchip.com>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Fault
+ - description: RX
+ - description: TX
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+
+ serial@1f822000 {
+ compatible = "microchip,pic32mzda-uart";
+ reg = <0x1f822000 0x50>;
+ interrupts = <112 IRQ_TYPE_LEVEL_HIGH>,
+ <113 IRQ_TYPE_LEVEL_HIGH>,
+ <114 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rootclk PB2CLK>;
+ cts-gpios = <&gpio1 15 0>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/milbeaut-uart.txt b/Documentation/devicetree/bindings/serial/milbeaut-uart.txt
deleted file mode 100644
index 3d2fb1a7ba94..000000000000
--- a/Documentation/devicetree/bindings/serial/milbeaut-uart.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Socionext Milbeaut UART controller
-
-Required properties:
-- compatible: should be "socionext,milbeaut-usio-uart".
-- reg: offset and length of the register set for the device.
-- interrupts: two interrupts specifier.
-- interrupt-names: should be "rx", "tx".
-- clocks: phandle to the input clock.
-
-Optional properties:
-- auto-flow-control: flow control enable.
-
-Example:
- usio1: usio_uart@1e700010 {
- compatible = "socionext,milbeaut-usio-uart";
- reg = <0x1e700010 0x10>;
- interrupts = <0 141 0x4>, <0 149 0x4>;
- interrupt-names = "rx", "tx";
- clocks = <&clk 2>;
- auto-flow-control;
- };
diff --git a/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt b/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt
deleted file mode 100644
index d10cc06c0c37..000000000000
--- a/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-Device tree bindings for Marvell PXA SSP ports
-
-Required properties:
-
- - compatible: Must be one of
- mrvl,pxa25x-ssp
- mvrl,pxa25x-nssp
- mrvl,pxa27x-ssp
- mrvl,pxa3xx-ssp
- mvrl,pxa168-ssp
- mrvl,pxa910-ssp
- mrvl,ce4100-ssp
-
- - reg: The memory base
- - dmas: Two dma phandles, one for rx, one for tx
- - dma-names: Must be "rx", "tx"
-
-
-Example for PXA3xx:
-
- ssp0: ssp@41000000 {
- compatible = "mrvl,pxa3xx-ssp";
- reg = <0x41000000 0x40>;
- ssp-id = <1>;
- interrupts = <24>;
- clock-names = "pxa27x-ssp.0";
- dmas = <&dma 13
- &dma 14>;
- dma-names = "rx", "tx";
- };
-
- ssp1: ssp@41700000 {
- compatible = "mrvl,pxa3xx-ssp";
- reg = <0x41700000 0x40>;
- ssp-id = <2>;
- interrupts = <16>;
- clock-names = "pxa27x-ssp.1";
- dmas = <&dma 15
- &dma 16>;
- dma-names = "rx", "tx";
- };
-
- ssp2: ssp@41900000 {
- compatibl3 = "mrvl,pxa3xx-ssp";
- reg = <0x41900000 0x40>;
- ssp-id = <3>;
- interrupts = <0>;
- clock-names = "pxa27x-ssp.2";
- dmas = <&dma 66
- &dma 67>;
- dma-names = "rx", "tx";
- };
-
- ssp3: ssp@41a00000 {
- compatible = "mrvl,pxa3xx-ssp";
- reg = <0x41a00000 0x40>;
- ssp-id = <4>;
- interrupts = <13>;
- clock-names = "pxa27x-ssp.3";
- dmas = <&dma 2
- &dma 3>;
- dma-names = "rx", "tx";
- };
-
diff --git a/Documentation/devicetree/bindings/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/serial/mvebu-uart.txt
deleted file mode 100644
index a062bbca532c..000000000000
--- a/Documentation/devicetree/bindings/serial/mvebu-uart.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Marvell UART : Non standard UART used in some of Marvell EBU SoCs
- e.g., Armada-3700.
-
-Required properties:
-- compatible:
- - "marvell,armada-3700-uart" for the standard variant of the UART
- (32 bytes FIFO, no DMA, level interrupts, 8-bit access to the
- FIFO), called also UART1.
- - "marvell,armada-3700-uart-ext" for the extended variant of the
- UART (128 bytes FIFO, DMA, front interrupts, 8-bit or 32-bit
- accesses to the FIFO), called also UART2.
-- reg: offset and length of the register set for the device.
-- clocks: UART reference clock used to derive the baudrate. If no clock
- is provided (possible only with the "marvell,armada-3700-uart"
- compatible string for backward compatibility), it will only work
- if the baudrate was initialized by the bootloader and no baudrate
- change will then be possible. When provided it should be UART1-clk
- for standard variant of UART and UART2-clk for extended variant
- of UART. TBG clock (with UART TBG divisors d1=d2=1) or xtal clock
- should not be used and are supported only for backward compatibility.
-- interrupts:
- - Must contain three elements for the standard variant of the IP
- (marvell,armada-3700-uart): "uart-sum", "uart-tx" and "uart-rx",
- respectively the UART sum interrupt, the UART TX interrupt and
- UART RX interrupt. A corresponding interrupt-names property must
- be defined.
- - Must contain two elements for the extended variant of the IP
- (marvell,armada-3700-uart-ext): "uart-tx" and "uart-rx",
- respectively the UART TX interrupt and the UART RX interrupt. A
- corresponding interrupt-names property must be defined.
- - For backward compatibility reasons, a single element interrupts
- property is also supported for the standard variant of the IP,
- containing only the UART sum interrupt. This form is deprecated
- and should no longer be used.
-
-Example:
- uart0: serial@12000 {
- compatible = "marvell,armada-3700-uart";
- reg = <0x12000 0x18>;
- clocks = <&uartclk 0>;
- interrupts =
- <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uart-sum", "uart-tx", "uart-rx";
- };
-
- uart1: serial@12200 {
- compatible = "marvell,armada-3700-uart-ext";
- reg = <0x12200 0x30>;
- clocks = <&uartclk 1>;
- interrupts =
- <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "uart-tx", "uart-rx";
- };
diff --git a/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml b/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml
new file mode 100644
index 000000000000..a76af0f6009b
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nuvoton,ma35d1-serial.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nuvoton,ma35d1-serial.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 Universal Asynchronous Receiver/Transmitter (UART)
+
+maintainers:
+ - Min-Jen Chen <mjchen@nuvoton.com>
+ - Jacky Huang <ychuang3@nuvoton.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ const: nuvoton,ma35d1-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+
+ serial@40700000 {
+ compatible = "nuvoton,ma35d1-uart";
+ reg = <0x40700000 0x100>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk UART0_GATE>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
deleted file mode 100644
index f709304036c2..000000000000
--- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver.
-
-Required properties:
-- compatible : should be,
- "nvidia,tegra20-hsuart" for Tegra20,
- "nvidia,tegra30-hsuart" for Tegra30,
- "nvidia,tegra186-hsuart" for Tegra186,
- "nvidia,tegra194-hsuart" for Tegra194.
-
-- reg: Should contain UART controller registers location and length.
-- interrupts: Should contain UART controller interrupts.
-- clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - serial
-- dmas : Must contain an entry for each entry in dma-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-
-Optional properties:
-- nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
- only if all 8 lines of UART controller are pinmuxed.
-- nvidia,adjust-baud-rates: List of entries providing percentage of baud rate
- adjustment within a range.
- Each entry contains sets of 3 values. Range low/high and adjusted rate.
- <range_low range_high adjusted_rate>
- When baud rate set on controller falls within the range mentioned in this
- field, baud rate will be adjusted by percentage mentioned here.
- Ex: <9600 115200 200>
- Increase baud rate by 2% when set baud rate falls within range 9600 to 115200
-
-Baud Rate tolerance:
- Standard UART devices are expected to have tolerance for baud rate error by
- -4 to +4 %. All Tegra devices till Tegra210 had this support. However,
- Tegra186 chip has a known hardware issue. UART Rx baud rate tolerance level
- is 0% to +4% in 1-stop config. Otherwise, the received data will have
- corruption/invalid framing errors. Parker errata suggests adjusting baud
- rate to be higher than the deviations observed in Tx.
-
- Tx deviation of connected device can be captured over scope (or noted from
- its spec) for valid range and Tegra baud rate has to be set above actual
- Tx baud rate observed. To do this we use nvidia,adjust-baud-rates
-
- As an example, consider there is deviation observed in Tx for baud rates as
- listed below.
- 0 to 9600 has 1% deviation
- 9600 to 115200 2% deviation
- This slight deviation is expcted and Tegra UART is expected to handle it. Due
- to the issue stated above, baud rate on Tegra UART should be set equal to or
- above deviation observed for avoiding frame errors.
- Property should be set like this
- nvidia,adjust-baud-rates = <0 9600 100>,
- <9600 115200 200>;
-
-Example:
-
-serial@70006000 {
- compatible = "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart";
- reg = <0x70006000 0x40>;
- reg-shift = <2>;
- interrupts = <0 36 0x04>;
- nvidia,enable-modem-interrupt;
- clocks = <&tegra_car 6>;
- resets = <&tegra_car 6>;
- reset-names = "serial";
- dmas = <&apbdma 8>, <&apbdma 8>;
- dma-names = "rx", "tx";
- nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */
-};
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml
new file mode 100644
index 000000000000..29d48da81531
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nvidia,tegra20-hsuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-hsuart
+ - nvidia,tegra30-hsuart
+ - nvidia,tegra186-hsuart
+ - nvidia,tegra194-hsuart
+ - items:
+ - const: nvidia,tegra124-hsuart
+ - const: nvidia,tegra30-hsuart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: serial
+
+ dmas:
+ items:
+ - description: DMA channel used for reception
+ - description: DMA channel used for transmission
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ nvidia,enable-modem-interrupt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Enable modem interrupts. Should be enable only if all 8 lines of UART controller
+ are pinmuxed.
+
+ nvidia,adjust-baud-rates:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ List of entries providing percentage of baud rate adjustment within a range. Each entry
+ contains a set of 3 values: range low/high and adjusted rate. When the baud rate set on the
+ controller falls within the range mentioned in this field, the baud rate will be adjusted by
+ percentage mentioned here.
+
+ Example: <9600 115200 200>
+
+ Increase baud rate by 2% when set baud rate falls within range 9600 to 115200.
+
+ Standard UART devices are expected to have tolerance for baud rate error by -4 to +4 %. All
+ Tegra devices till Tegra210 had this support. However, Tegra186 chip has a known hardware
+ issue. UART RX baud rate tolerance level is 0% to +4% in 1-stop config. Otherwise, the
+ received data will have corruption/invalid framing errors. Parker errata suggests adjusting
+ baud rate to be higher than the deviations observed in TX.
+
+ TX deviation of connected device can be captured over scope (or noted from its spec) for
+ valid range and Tegra baud rate has to be set above actual TX baud rate observed. To do this
+ we use nvidia,adjust-baud-rates.
+
+ As an example, consider there is deviation observed in TX for baud rates as listed below. 0
+ to 9600 has 1% deviation 9600 to 115200 2% deviation. This slight deviation is expected and
+ Tegra UART is expected to handle it. Due to the issue stated above, baud rate on Tegra UART
+ should be set equal to or above deviation observed for avoiding frame errors. Property
+ should be set like this:
+
+ nvidia,adjust-baud-rates = <0 9600 100>,
+ <9600 115200 200>;
+ items:
+ items:
+ - description: range lower bound
+ - description: range upper bound
+ - description: adjustment (in permyriad, i.e. 0.01%)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+allOf:
+ - $ref: serial.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ serial@70006000 {
+ compatible = "nvidia,tegra30-hsuart";
+ reg = <0x70006000 0x40>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,enable-modem-interrupt;
+ clocks = <&tegra_car TEGRA30_CLK_UARTA>;
+ resets = <&tegra_car 6>;
+ reset-names = "serial";
+ dmas = <&apbdma 8>, <&apbdma 8>;
+ dma-names = "rx", "tx";
+ nvidia,adjust-baud-rates = <1000000 4000000 136>; /* 1.36% shift */
+ };
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml b/Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml
new file mode 100644
index 000000000000..572cc574da64
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nvidia,tegra264-utc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra UTC (UART Trace Controller) client
+
+maintainers:
+ - Kartik Rajput <kkartik@nvidia.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jonathan Hunter <jonathanh@nvidia.com>
+
+description:
+ Represents a client interface of the Tegra UTC (UART Trace Controller). The
+ Tegra UTC allows multiple clients within the Tegra SoC to share a physical
+ UART interface. It supports up to 16 clients. Each client operates as an
+ independent UART endpoint with a dedicated interrupt and 128-character TX/RX
+ FIFOs.
+
+ The Tegra UTC clients use 8-N-1 configuration and operates on a baudrate
+ configured by the bootloader at the controller level.
+
+allOf:
+ - $ref: serial.yaml#
+
+properties:
+ compatible:
+ const: nvidia,tegra264-utc
+
+ reg:
+ items:
+ - description: TX region.
+ - description: RX region.
+
+ reg-names:
+ items:
+ - const: tx
+ - const: rx
+
+ interrupts:
+ maxItems: 1
+
+ tx-threshold:
+ minimum: 1
+ maximum: 128
+
+ rx-threshold:
+ minimum: 1
+ maximum: 128
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - tx-threshold
+ - rx-threshold
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ tegra_utc: serial@c4e0000 {
+ compatible = "nvidia,tegra264-utc";
+ reg = <0xc4e0000 0x8000>, <0xc4e8000 0x8000>;
+ reg-names = "tx", "rx";
+ interrupts = <GIC_SPI 514 IRQ_TYPE_LEVEL_HIGH>;
+ tx-threshold = <4>;
+ rx-threshold = <4>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt b/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt
deleted file mode 100644
index 04e23e63ee4f..000000000000
--- a/Documentation/devicetree/bindings/serial/nxp,lpc1850-uart.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* NXP LPC1850 UART
-
-Required properties:
-- compatible : "nxp,lpc1850-uart", "ns16550a".
-- reg : offset and length of the register set for the device.
-- interrupts : should contain uart interrupt.
-- clocks : phandle to the input clocks.
-- clock-names : required elements: "uartclk", "reg".
-
-Optional properties:
-- dmas : Two or more DMA channel specifiers following the
- convention outlined in bindings/dma/dma.txt
-- dma-names : Names for the dma channels, if present. There must
- be at least one channel named "tx" for transmit
- and named "rx" for receive.
-
-Since it's also possible to also use the of_serial.c driver all
-parameters from 8250.txt also apply but are optional.
-
-Example:
-uart0: serial@40081000 {
- compatible = "nxp,lpc1850-uart", "ns16550a";
- reg = <0x40081000 0x1000>;
- reg-shift = <2>;
- interrupts = <24>;
- clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>;
- clock-names = "uartclk", "reg";
-};
diff --git a/Documentation/devicetree/bindings/serial/nxp,lpc3220-hsuart.yaml b/Documentation/devicetree/bindings/serial/nxp,lpc3220-hsuart.yaml
new file mode 100644
index 000000000000..ffa2ea59f256
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nxp,lpc3220-hsuart.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nxp,lpc3220-hsuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx SoC High Speed UART
+
+maintainers:
+ - Vladimir Zapolskiy <vz@mleia.com>
+ - Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: nxp,lpc3220-hsuart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@40014000 {
+ compatible = "nxp,lpc3220-hsuart";
+ reg = <0x40014000 0x1000>;
+ interrupts = <26 0>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
deleted file mode 100644
index 0fa8e3e43bf8..000000000000
--- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-* NXP SC16IS7xx advanced Universal Asynchronous Receiver-Transmitter (UART)
-* i2c as bus
-
-Required properties:
-- compatible: Should be one of the following:
- - "nxp,sc16is740" for NXP SC16IS740,
- - "nxp,sc16is741" for NXP SC16IS741,
- - "nxp,sc16is750" for NXP SC16IS750,
- - "nxp,sc16is752" for NXP SC16IS752,
- - "nxp,sc16is760" for NXP SC16IS760,
- - "nxp,sc16is762" for NXP SC16IS762.
-- reg: I2C address of the SC16IS7xx device.
-- interrupts: Should contain the UART interrupt
-- clocks: Reference to the IC source clock.
- OR (when there is no clock provider visible to the platform)
-- clock-frequency: The source clock frequency for the IC.
-
-Optional properties:
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be two. The first cell is the GPIO number and
- the second cell is used to specify the GPIO polarity:
- 0 = active high,
- 1 = active low.
-- irda-mode-ports: An array that lists the indices of the port that
- should operate in IrDA mode.
-
-Example:
- sc16is750: sc16is750@51 {
- compatible = "nxp,sc16is750";
- reg = <0x51>;
- clocks = <&clk20m>;
- interrupt-parent = <&gpio3>;
- interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
-* spi as bus
-
-Required properties:
-- compatible: Should be one of the following:
- - "nxp,sc16is740" for NXP SC16IS740,
- - "nxp,sc16is741" for NXP SC16IS741,
- - "nxp,sc16is750" for NXP SC16IS750,
- - "nxp,sc16is752" for NXP SC16IS752,
- - "nxp,sc16is760" for NXP SC16IS760,
- - "nxp,sc16is762" for NXP SC16IS762.
-- reg: SPI chip select number.
-- interrupts: Specifies the interrupt source of the parent interrupt
- controller. The format of the interrupt specifier depends on the
- parent interrupt controller.
-- clocks: phandle to the IC source clock.
-
-Optional properties:
-- gpio-controller: Marks the device node as a GPIO controller.
-- #gpio-cells: Should be two. The first cell is the GPIO number and
- the second cell is used to specify the GPIO polarity:
- 0 = active high,
- 1 = active low.
-- irda-mode-ports: An array that lists the indices of the port that
- should operate in IrDA mode.
-
-Example:
- sc16is750: sc16is750@0 {
- compatible = "nxp,sc16is750";
- reg = <0>;
- clocks = <&clk20m>;
- interrupt-parent = <&gpio3>;
- interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
- gpio-controller;
- #gpio-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml
new file mode 100644
index 000000000000..ab39b95dae40
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/nxp,sc16is7xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP SC16IS7xx Advanced Universal Asynchronous Receiver-Transmitter (UART)
+
+maintainers:
+ - Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,sc16is740
+ - nxp,sc16is741
+ - nxp,sc16is750
+ - nxp,sc16is752
+ - nxp,sc16is760
+ - nxp,sc16is762
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ When missing, device driver uses polling instead.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ clock-frequency:
+ description:
+ When there is no clock provider visible to the platform, this
+ is the source crystal or external clock frequency for the IC in Hz.
+ minimum: 1
+ maximum: 80000000
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names:
+ minItems: 1
+ maxItems: 8
+
+ irda-mode-ports:
+ description: |
+ An array that lists the indices of the port that should operate in IrDA
+ mode:
+ 0: port A
+ 1: port B
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 1
+
+ nxp,modem-control-line-ports:
+ description: |
+ An array that lists the indices of the port that should have shared GPIO
+ lines configured as modem control lines:
+ 0: port A
+ 1: port B
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: /schemas/serial/serial.yaml#
+ - $ref: /schemas/serial/rs485.yaml#
+
+oneOf:
+ - required:
+ - clocks
+ - required:
+ - clock-frequency
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ serial@51 {
+ compatible = "nxp,sc16is750";
+ reg = <0x51>;
+ clocks = <&clk20m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ serial@53 {
+ compatible = "nxp,sc16is752";
+ reg = <0x53>;
+ clocks = <&clk20m>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ nxp,modem-control-line-ports = <1>; /* Port 1 as modem control lines */
+ gpio-controller; /* Port 0 as GPIOs */
+ #gpio-cells = <2>;
+ };
+
+ serial@54 {
+ compatible = "nxp,sc16is752";
+ reg = <0x54>;
+ clocks = <&clk20m>;
+ reset-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ nxp,modem-control-line-ports = <0 1>; /* Ports 0 and 1 as modem control lines */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/serial/nxp-lpc32xx-hsuart.txt b/Documentation/devicetree/bindings/serial/nxp-lpc32xx-hsuart.txt
deleted file mode 100644
index 0d439dfc1aa5..000000000000
--- a/Documentation/devicetree/bindings/serial/nxp-lpc32xx-hsuart.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* NXP LPC32xx SoC High Speed UART
-
-Required properties:
-- compatible: Should be "nxp,lpc3220-hsuart"
-- reg: Should contain registers location and length
-- interrupts: Should contain interrupt
-
-Example:
-
- uart1: serial@40014000 {
- compatible = "nxp,lpc3220-hsuart";
- reg = <0x40014000 0x1000>;
- interrupts = <26 0>;
- };
diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml
index d8aed84abcd3..3fcf2d042372 100644
--- a/Documentation/devicetree/bindings/serial/pl011.yaml
+++ b/Documentation/devicetree/bindings/serial/pl011.yaml
@@ -10,6 +10,7 @@ maintainers:
- Rob Herring <robh@kernel.org>
allOf:
+ - $ref: /schemas/arm/primecell.yaml#
- $ref: serial.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
@@ -91,9 +92,18 @@ properties:
3000ms.
default: 3000
+ power-domains:
+ maxItems: 1
+
resets:
maxItems: 1
+ reg-io-width:
+ description:
+ The size (in bytes) of the IO accesses that should be performed
+ on the device.
+ enum: [1, 4]
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt b/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt
deleted file mode 100644
index ce8c90161959..000000000000
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* MSM Serial UART
-
-The MSM serial UART hardware is designed for low-speed use cases where a
-dma-engine isn't needed. From a software perspective it's mostly compatible
-with the MSM serial UARTDM except that it only supports reading and writing one
-character at a time.
-
-Required properties:
-- compatible: Should contain "qcom,msm-uart"
-- reg: Should contain UART register location and length.
-- interrupts: Should contain UART interrupt.
-- clocks: Should contain the core clock.
-- clock-names: Should be "core".
-
-Example:
-
-A uart device at 0xa9c00000 with interrupt 11.
-
-serial@a9c00000 {
- compatible = "qcom,msm-uart";
- reg = <0xa9c00000 0x1000>;
- interrupts = <11>;
- clocks = <&uart_cxc>;
- clock-names = "core";
-};
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml
new file mode 100644
index 000000000000..bc2e48754805
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uart.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/qcom,msm-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM SoC Serial UART
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ The MSM serial UART hardware is designed for low-speed use cases where a
+ dma-engine isn't needed. From a software perspective it's mostly compatible
+ with the MSM serial UARTDM except that it only supports reading and writing
+ one character at a time.
+
+properties:
+ compatible:
+ const: qcom,msm-uart
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: core
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clock-names
+ - clocks
+ - interrupts
+ - reg
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@a9c00000 {
+ compatible = "qcom,msm-uart";
+ reg = <0xa9c00000 0x1000>;
+ interrupts = <11>;
+ clocks = <&uart_cxc>;
+ clock-names = "core";
+ };
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
index 484b9a51f6a9..788ef5c1c446 100644
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
@@ -9,7 +9,7 @@ title: Qualcomm MSM Serial UARTDM
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description: |
The MSM serial UARTDM hardware is designed for high-speed use cases where the
@@ -48,9 +48,17 @@ properties:
- const: tx
- const: rx
+ interconnects:
+ maxItems: 1
+
interrupts:
maxItems: 1
+ operating-points-v2: true
+
+ power-domains:
+ maxItems: 1
+
qcom,rx-crci:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -78,8 +86,6 @@ required:
- interrupts
- reg
-unevaluatedProperties: false
-
allOf:
- $ref: /schemas/serial/serial.yaml#
@@ -97,9 +103,13 @@ allOf:
reg:
maxItems: 1
+unevaluatedProperties: false
+
examples:
- |
+ #include <dt-bindings/interconnect/qcom,msm8996.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
serial@f991e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
@@ -109,4 +119,7 @@ examples:
clock-names = "core", "iface";
dmas = <&dma0 0>, <&dma0 1>;
dma-names = "tx", "rx";
+ power-domains = <&rpmpd MSM8996_VDDCX>;
+ operating-points-v2 = <&uart_opp_table>;
+ interconnects = <&pnoc MASTER_BLSP_1 &bimc SLAVE_EBI_CH0>;
};
diff --git a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
new file mode 100644
index 000000000000..c8f01923cb25
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/qcom,sa8255p-geni-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Geni based QUP UART interface
+
+maintainers:
+ - Praveen Talari <quic_ptalari@quicinc.com>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: UART core irq
+ - description: Wakeup irq (RX GPIO)
+
+ interrupt-names:
+ description:
+ The UART interrupt and optionally the RX in-band wakeup interrupt
+ as not all UART instances have a wakeup-capable interrupt routed
+ via the PDC.
+ minItems: 1
+ items:
+ - const: uart
+ - const: wakeup
+
+ power-domains:
+ minItems: 2
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: power
+ - const: perf
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - power-domain-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ serial@990000 {
+ compatible = "qcom,sa8255p-geni-uart";
+ reg = <0x990000 0x4000>;
+ interrupts = <GIC_SPI 531 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&scmi0_pd 0>, <&scmi0_dvfs 0>;
+ power-domain-names = "power", "perf";
+ };
+...
diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml
index 05a6999808d1..ed7b3909d87d 100644
--- a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/qcom,serial-geni-qcom.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/qcom,serial-geni-qcom.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Geni based QUP UART interface
@@ -12,6 +12,7 @@ maintainers:
allOf:
- $ref: /schemas/serial/serial.yaml#
+ - $ref: /schemas/soc/qcom/qcom,se-common-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
index b25aca733b72..89f1eb0f2c5a 100644
--- a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/renesas,em-uart.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/renesas,em-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas EMMA Mobile UART Interface
@@ -38,6 +38,13 @@ properties:
- const: sclk
- const: pclk
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
allOf:
- $ref: serial.yaml#
@@ -53,22 +60,15 @@ allOf:
clock-names:
minItems: 2
-required:
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
-
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
uart0: serial@e1020000 {
- compatible = "renesas,em-uart";
- reg = <0xe1020000 0x38>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&usia_u0_sclk>;
- clock-names = "sclk";
+ compatible = "renesas,em-uart";
+ reg = <0xe1020000 0x38>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usia_u0_sclk>;
+ clock-names = "sclk";
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
index 1957b9d782e8..4b3f98a46cd9 100644
--- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/renesas,hscif.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/renesas,hscif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas High Speed Serial Communication Interface with FIFO (HSCIF)
@@ -59,9 +59,16 @@ properties:
- renesas,hscif-r8a779a0 # R-Car V3U
- renesas,hscif-r8a779f0 # R-Car S4-8
- renesas,hscif-r8a779g0 # R-Car V4H
+ - renesas,hscif-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-hscif # R-Car Gen4
- const: renesas,hscif # generic HSCIF compatible UART
+ - items:
+ - enum:
+ - renesas,hscif-r8a78000 # R-Car X5H
+ - const: renesas,rcar-gen5-hscif # R-Car Gen5
+ - const: renesas,hscif # generic HSCIF compatible UART
+
reg:
maxItems: 1
@@ -111,8 +118,6 @@ required:
- clock-names
- power-domains
-unevaluatedProperties: false
-
if:
properties:
compatible:
@@ -121,30 +126,33 @@ if:
- renesas,rcar-gen2-hscif
- renesas,rcar-gen3-hscif
- renesas,rcar-gen4-hscif
+ - renesas,rcar-gen5-hscif
then:
required:
- resets
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7795-sysc.h>
aliases {
- serial1 = &hscif1;
+ serial1 = &hscif1;
};
hscif1: serial@e6550000 {
- compatible = "renesas,hscif-r8a7795", "renesas,rcar-gen3-hscif",
- "renesas,hscif";
- reg = <0xe6550000 96>;
- interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 519>, <&cpg CPG_CORE R8A7795_CLK_S3D1>,
- <&scif_clk>;
- clock-names = "fck", "brg_int", "scif_clk";
- dmas = <&dmac1 0x33>, <&dmac1 0x32>, <&dmac2 0x33>, <&dmac2 0x32>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
- resets = <&cpg 519>;
- uart-has-rtscts;
+ compatible = "renesas,hscif-r8a7795", "renesas,rcar-gen3-hscif",
+ "renesas,hscif";
+ reg = <0xe6550000 96>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 519>, <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac1 0x33>, <&dmac1 0x32>, <&dmac2 0x33>, <&dmac2 0x32>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 519>;
+ uart-has-rtscts;
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,rsci.yaml b/Documentation/devicetree/bindings/serial/renesas,rsci.yaml
new file mode 100644
index 000000000000..6b1f827a335b
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/renesas,rsci.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/renesas,rsci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RSCI Serial Communication Interface
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+allOf:
+ - $ref: serial.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: renesas,r9a09g087-rsci # RZ/N2H
+ - const: renesas,r9a09g077-rsci # RZ/T2H
+
+ - items:
+ - const: renesas,r9a09g077-rsci # RZ/T2H
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Error interrupt
+ - description: Receive buffer full interrupt
+ - description: Transmit buffer empty interrupt
+ - description: Transmit end interrupt
+
+ interrupt-names:
+ items:
+ - const: eri
+ - const: rxi
+ - const: txi
+ - const: tei
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: operation
+ - const: bus
+ - const: sck # optional external clock input
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/renesas-cpg-mssr.h>
+
+ sci0: serial@80005000 {
+ compatible = "renesas,r9a09g077-rsci";
+ reg = <0x80005000 0x400>;
+ interrupts = <GIC_SPI 590 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 591 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 592 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 593 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "eri", "rxi", "txi", "tei";
+ clocks = <&cpg CPG_MOD 8>, <&cpg CPG_CORE 13>;
+ clock-names = "operation", "bus";
+ power-domains = <&cpg>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci.yaml b/Documentation/devicetree/bindings/serial/renesas,sci.yaml
index bf7708a7a2c0..64d3db6e54e5 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,sci.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/renesas,sci.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/renesas,sci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Serial Communication Interface
@@ -17,7 +17,7 @@ properties:
oneOf:
- items:
- enum:
- - renesas,r9a07g043-sci # RZ/G2UL
+ - renesas,r9a07g043-sci # RZ/G2UL and RZ/Five
- renesas,r9a07g044-sci # RZ/G2{L,LC}
- renesas,r9a07g054-sci # RZ/V2L
- const: renesas,sci # generic SCI compatible UART
@@ -91,19 +91,19 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
aliases {
- serial0 = &sci0;
+ serial0 = &sci0;
};
sci0: serial@1004d000 {
- compatible = "renesas,r9a07g044-sci", "renesas,sci";
- reg = <0x1004d000 0x400>;
- interrupts = <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "eri", "rxi", "txi", "tei";
- clocks = <&cpg CPG_MOD R9A07G044_SCI0_CLKP>;
- clock-names = "fck";
- power-domains = <&cpg>;
- resets = <&cpg R9A07G044_SCI0_RST>;
+ compatible = "renesas,r9a07g044-sci", "renesas,sci";
+ reg = <0x1004d000 0x400>;
+ interrupts = <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "eri", "rxi", "txi", "tei";
+ clocks = <&cpg CPG_MOD R9A07G044_SCI0_CLKP>;
+ clock-names = "fck";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_SCI0_RST>;
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index 90fe45265fbc..72483bc3274d 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -1,17 +1,14 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/renesas,scif.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/renesas,scif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Serial Communication Interface with FIFO (SCIF)
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
-allOf:
- - $ref: serial.yaml#
-
properties:
compatible:
oneOf:
@@ -49,6 +46,7 @@ properties:
- items:
- enum:
- renesas,scif-r8a774a1 # RZ/G2M
+ - renesas,scif-r8a774a3 # RZ/G2M v3.0
- renesas,scif-r8a774b1 # RZ/G2N
- renesas,scif-r8a774c0 # RZ/G2E
- renesas,scif-r8a774e1 # RZ/G2H
@@ -67,19 +65,36 @@ properties:
- enum:
- renesas,scif-r8a779a0 # R-Car V3U
- renesas,scif-r8a779f0 # R-Car S4-8
+ - renesas,scif-r8a779g0 # R-Car V4H
+ - renesas,scif-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-scif # R-Car Gen4
- const: renesas,scif # generic SCIF compatible UART
- items:
- enum:
+ - renesas,scif-r8a78000 # R-Car X5H
+ - const: renesas,rcar-gen5-scif # R-Car Gen5
+ - const: renesas,scif # generic SCIF compatible UART
+
+ - items:
+ - enum:
- renesas,scif-r9a07g044 # RZ/G2{L,LC}
- items:
- enum:
- - renesas,scif-r9a07g043 # RZ/G2UL
+ - renesas,scif-r9a07g043 # RZ/G2UL and RZ/Five
- renesas,scif-r9a07g054 # RZ/V2L
+ - renesas,scif-r9a08g045 # RZ/G3S
- const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback
+ - const: renesas,scif-r9a09g057 # RZ/V2H(P)
+
+ - items:
+ - enum:
+ - renesas,scif-r9a09g047 # RZ/G3E
+ - renesas,scif-r9a09g056 # RZ/V2N
+ - const: renesas,scif-r9a09g057 # RZ/V2H fallback
+
reg:
maxItems: 1
@@ -91,29 +106,26 @@ properties:
- description: Error interrupt
- description: Receive buffer full interrupt
- description: Transmit buffer empty interrupt
- - description: Transmit End interrupt
- - items:
- - description: Error interrupt
- - description: Receive buffer full interrupt
- - description: Transmit buffer empty interrupt
- description: Break interrupt
- description: Data Ready interrupt
- description: Transmit End interrupt
+ - description: Transmit End/Data Ready interrupt
+ - description: Receive buffer full interrupt (EDGE trigger)
+ - description: Transmit buffer empty interrupt (EDGE trigger)
+ minItems: 4
interrupt-names:
- oneOf:
- - items:
- - const: eri
- - const: rxi
- - const: txi
- - const: tei
- - items:
- - const: eri
- - const: rxi
- - const: txi
- - const: bri
- - const: dri
- - const: tei
+ minItems: 4
+ items:
+ - const: eri
+ - const: rxi
+ - const: txi
+ - const: bri
+ - const: dri
+ - const: tei
+ - const: tei-dri
+ - const: rxi-edge
+ - const: txi-edge
clocks:
minItems: 1
@@ -158,18 +170,94 @@ required:
- clock-names
- power-domains
-if:
- properties:
- compatible:
- contains:
- enum:
- - renesas,rcar-gen2-scif
- - renesas,rcar-gen3-scif
- - renesas,rcar-gen4-scif
- - renesas,scif-r9a07g044
-then:
- required:
- - resets
+allOf:
+ - $ref: serial.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rcar-gen2-scif
+ - renesas,rcar-gen3-scif
+ - renesas,rcar-gen4-scif
+ - renesas,rcar-gen5-scif
+ - renesas,scif-r9a07g044
+ - renesas,scif-r9a09g057
+ then:
+ required:
+ - resets
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rcar-gen1-scif
+ - renesas,rcar-gen2-scif
+ - renesas,rcar-gen3-scif
+ - renesas,rcar-gen4-scif
+ - renesas,rcar-gen5-scif
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names: false
+ else:
+ required:
+ - interrupt-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,scif-r7s72100
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ maxItems: 4
+
+ interrupt-names:
+ maxItems: 4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,scif-r7s9210
+ - renesas,scif-r9a07g044
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ maxItems: 6
+
+ interrupt-names:
+ minItems: 6
+ maxItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,scif-r9a09g057
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ maxItems: 1
+
+ interrupts:
+ minItems: 9
+
+ interrupt-names:
+ minItems: 9
unevaluatedProperties: false
@@ -179,19 +267,19 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7791-sysc.h>
aliases {
- serial0 = &scif0;
+ serial0 = &scif0;
};
scif0: serial@e6e60000 {
- compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
- "renesas,scif";
- reg = <0xe6e60000 64>;
- interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 721>, <&cpg CPG_CORE R8A7791_CLK_ZS>,
- <&scif_clk>;
- clock-names = "fck", "brg_int", "scif_clk";
- dmas = <&dmac0 0x29>, <&dmac0 0x2a>, <&dmac1 0x29>, <&dmac1 0x2a>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
- resets = <&cpg 721>;
+ compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+ "renesas,scif";
+ reg = <0xe6e60000 64>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 721>, <&cpg CPG_CORE R8A7791_CLK_ZS>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>, <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 721>;
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
index 3c67d3202e1b..c98657cf4666 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/renesas,scifa.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/renesas,scifa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Serial Communications Interface with FIFO A (SCIFA)
@@ -77,8 +77,6 @@ required:
- clock-names
- power-domains
-unevaluatedProperties: false
-
if:
properties:
compatible:
@@ -89,24 +87,26 @@ then:
required:
- resets
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/clock/r8a7790-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7790-sysc.h>
aliases {
- serial0 = &scifa0;
+ serial0 = &scifa0;
};
scifa0: serial@e6c40000 {
- compatible = "renesas,scifa-r8a7790", "renesas,rcar-gen2-scifa",
- "renesas,scifa";
- reg = <0xe6c40000 64>;
- interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 204>;
- clock-names = "fck";
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 204>;
- dmas = <&dmac0 0x21>, <&dmac0 0x22>, <&dmac1 0x21>, <&dmac1 0x22>;
- dma-names = "tx", "rx", "tx", "rx";
+ compatible = "renesas,scifa-r8a7790", "renesas,rcar-gen2-scifa",
+ "renesas,scifa";
+ reg = <0xe6c40000 64>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 204>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 204>;
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>, <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
};
diff --git a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
index d5571c7a4424..fb695b3111ac 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/renesas,scifb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/renesas,scifb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Serial Communications Interface with FIFO B (SCIFB)
@@ -77,8 +77,6 @@ required:
- clock-names
- power-domains
-unevaluatedProperties: false
-
if:
properties:
compatible:
@@ -89,15 +87,17 @@ then:
required:
- resets
+unevaluatedProperties: false
+
examples:
- |
#include <dt-bindings/clock/r8a7740-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
scifb: serial@e6c30000 {
- compatible = "renesas,scifb-r8a7740", "renesas,scifb";
- reg = <0xe6c30000 0x100>;
- interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
- clock-names = "fck";
- power-domains = <&pd_a3sp>;
+ compatible = "renesas,scifb-r8a7740", "renesas,scifb";
+ reg = <0xe6c30000 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
+ clock-names = "fck";
+ power-domains = <&pd_a3sp>;
};
diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
index 90a1bab40f05..b93254ad2a28 100644
--- a/Documentation/devicetree/bindings/serial/rs485.yaml
+++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/serial/rs485.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: RS485 serial communications Bindings
+title: RS485 serial communications
description: The RTS signal is capable of automatically controlling line
direction for the built-in half-duplex mode. The properties described
@@ -18,16 +18,19 @@ properties:
description: prop-encoded-array <a b>
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- items:
- - description: Delay between rts signal and beginning of data sent in
- milliseconds. It corresponds to the delay before sending data.
- default: 0
- maximum: 100
- - description: Delay between end of data sent and rts signal in milliseconds.
- It corresponds to the delay after sending data and actual release
- of the line.
- default: 0
- maximum: 100
+ - description: Delay between rts signal and beginning of data sent in
+ milliseconds. It corresponds to the delay before sending data.
+ default: 0
+ maximum: 100
+ - description: Delay between end of data sent and rts signal in milliseconds.
+ It corresponds to the delay after sending data and actual release
+ of the line.
+ default: 0
+ maximum: 100
+
+ rs485-rts-active-high:
+ description: drive RTS high when sending (this is the default).
+ $ref: /schemas/types.yaml#/definitions/flag
rs485-rts-active-low:
description: drive RTS low when sending (default is high).
@@ -51,6 +54,12 @@ properties:
description: GPIO pin to enable RS485 bus termination.
maxItems: 1
+ rs485-rx-during-tx-gpios:
+ description: Output GPIO pin that sets the state of rs485-rx-during-tx. This
+ signal can be used to control the RX part of an RS485 transceiver. Thereby
+ the active state enables RX during TX.
+ maxItems: 1
+
additionalProperties: true
...
diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 41d3b082eb72..75ac2a08f257 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -18,20 +18,40 @@ description: |+
properties:
compatible:
oneOf:
- - items:
- - const: samsung,exynosautov9-uart
- - const: samsung,exynos850-uart
- enum:
- apple,s5l-uart
- axis,artpec8-uart
- - samsung,s3c2410-uart
- - samsung,s3c2412-uart
- - samsung,s3c2440-uart
+ - google,gs101-uart
- samsung,s3c6400-uart
- samsung,s5pv210-uart
- samsung,exynos4210-uart
- samsung,exynos5433-uart
- samsung,exynos850-uart
+ - samsung,exynos8895-uart
+ - items:
+ - enum:
+ - samsung,exynos2200-uart
+ - const: google,gs101-uart
+ - items:
+ - enum:
+ - samsung,exynos7-uart
+ - tesla,fsd-uart
+ - const: samsung,exynos4210-uart
+ - items:
+ - enum:
+ - samsung,exynos7885-uart
+ - const: samsung,exynos5433-uart
+ - items:
+ - enum:
+ - samsung,exynosautov9-uart
+ - samsung,exynosautov920-uart
+ - const: samsung,exynos850-uart
+ - items:
+ - enum:
+ - axis,artpec9-uart
+ - samsung,exynos7870-uart
+ - samsung,exynos8890-uart
+ - const: samsung,exynos8895-uart
reg:
maxItems: 1
@@ -40,7 +60,6 @@ properties:
description: |
The size (in bytes) of the IO accesses that should be performed
on the device.
- $ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 4 ]
clocks:
@@ -48,14 +67,8 @@ properties:
maxItems: 5
clock-names:
- description: N = 0 is allowed for SoCs without internal baud clock mux.
minItems: 2
- items:
- - const: uart
- - pattern: '^clk_uart_baud[0-3]$'
- - pattern: '^clk_uart_baud[0-3]$'
- - pattern: '^clk_uart_baud[0-3]$'
- - pattern: '^clk_uart_baud[0-3]$'
+ maxItems: 5
dmas:
items:
@@ -72,6 +85,9 @@ properties:
minItems: 1
maxItems: 2
+ power-domains:
+ maxItems: 1
+
samsung,uart-fifosize:
description: The fifo size supported by the UART channel.
$ref: /schemas/types.yaml#/definitions/uint32
@@ -84,8 +100,6 @@ required:
- interrupts
- reg
-unevaluatedProperties: false
-
allOf:
- $ref: serial.yaml#
@@ -94,19 +108,45 @@ allOf:
compatible:
contains:
enum:
- - samsung,s3c2410-uart
- - samsung,s5pv210-uart
+ - samsung,s3c6400-uart
then:
properties:
clocks:
- minItems: 2
+ minItems: 3
maxItems: 3
+
+ clock-names:
+ items:
+ - const: uart
+ - const: clk_uart_baud2
+ - const: clk_uart_baud3
+
+ else:
+ properties:
clock-names:
minItems: 2
items:
- const: uart
- - pattern: '^clk_uart_baud[0-1]$'
- - pattern: '^clk_uart_baud[0-1]$'
+ - const: clk_uart_baud0
+ - const: clk_uart_baud1
+ - const: clk_uart_baud2
+ - const: clk_uart_baud3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,s5pv210-uart
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
- if:
properties:
@@ -121,10 +161,38 @@ allOf:
properties:
clocks:
maxItems: 2
+
clock-names:
- items:
- - const: uart
- - const: clk_uart_baud0
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-uart
+ - samsung,exynos8895-uart
+ then:
+ required:
+ - samsung,uart-fifosize
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-uart
+ then:
+ properties:
+ reg-io-width: false
+
+unevaluatedProperties: false
examples:
- |
@@ -141,3 +209,19 @@ examples:
<&clocks SCLK_UART>;
samsung,uart-fifosize = <16>;
};
+ - |
+ #include <dt-bindings/clock/google,gs101.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ serial_0: serial@10a00000 {
+ compatible = "google,gs101-uart";
+ reg = <0x10a00000 0xc0>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0>;
+ clock-names = "uart", "clk_uart_baud0";
+ interrupts = <GIC_SPI 634 IRQ_TYPE_LEVEL_HIGH 0>;
+ pinctrl-0 = <&uart0_bus>;
+ pinctrl-names = "default";
+ samsung,uart-fifosize = <256>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/serial-peripheral-props.yaml b/Documentation/devicetree/bindings/serial/serial-peripheral-props.yaml
new file mode 100644
index 000000000000..b4a73214d20d
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/serial-peripheral-props.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/serial-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Properties for Serial-attached Devices
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+ - Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+description:
+ Devices connected over serial/UART, expressed as children of a serial
+ controller, might need similar properties, e.g. for configuring the baud
+ rate.
+
+properties:
+ max-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The maximum baud rate the device operates at.
+ This should only be present if the maximum is less than the slave
+ device can support. For example, a particular board has some
+ signal quality issue or the host processor can't support higher
+ baud rates.
+
+ current-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ The current baud rate the device operates at.
+ This should only be present in case a driver has no chance to know
+ the baud rate of the slave device.
+ Examples:
+ * device supports auto-baud
+ * the rate is setup by a bootloader and there is no way to reset
+ the device
+ * device baud rate is configured by its firmware but there is no
+ way to request the actual settings
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index c75ba3fb6465..6aa9cfae417b 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/serial.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/serial.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Serial Interface Generic DT Bindings
+title: Serial Interface Generic
maintainers:
- Rob Herring <robh@kernel.org>
@@ -87,19 +87,13 @@ properties:
description:
TX FIFO threshold configuration (in bytes).
-if:
- required:
- - uart-has-rtscts
-then:
- properties:
- cts-gpios: false
- rts-gpios: false
-
patternProperties:
- ".*":
+ "^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$":
if:
type: object
then:
+ additionalProperties: true
+ $ref: serial-peripheral-props.yaml#
description:
Serial attached devices shall be a child node of the host UART device
the slave device is attached to. It is expected that the attached
@@ -111,43 +105,29 @@ patternProperties:
description:
Compatible of the device connected to the serial port.
- max-speed:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- The maximum baud rate the device operates at.
- This should only be present if the maximum is less than the slave
- device can support. For example, a particular board has some
- signal quality issue or the host processor can't support higher
- baud rates.
-
- current-speed:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: |
- The current baud rate the device operates at.
- This should only be present in case a driver has no chance to know
- the baud rate of the slave device.
- Examples:
- * device supports auto-baud
- * the rate is setup by a bootloader and there is no way to reset
- the device
- * device baud rate is configured by its firmware but there is no
- way to request the actual settings
-
required:
- compatible
+if:
+ required:
+ - uart-has-rtscts
+then:
+ properties:
+ cts-gpios: false
+ rts-gpios: false
+
additionalProperties: true
examples:
- |
serial@1234 {
- compatible = "ns16550a";
- reg = <0x1234 0x20>;
- interrupts = <1>;
-
- bluetooth {
- compatible = "brcm,bcm4330-bt";
- interrupt-parent = <&gpio>;
- interrupts = <10>;
- };
+ compatible = "ns16550a";
+ reg = <0x1234 0x20>;
+ interrupts = <1>;
+
+ bluetooth {
+ compatible = "brcm,bcm4330-bt";
+ interrupt-parent = <&gpio>;
+ interrupts = <10>;
+ };
};
diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
index b0a8871e3641..b0df1cac4968 100644
--- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
@@ -53,13 +53,13 @@ unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/sifive-fu540-prci.h>
- serial@10010000 {
+ #include <dt-bindings/clock/sifive-fu540-prci.h>
+ serial@10010000 {
compatible = "sifive,fu540-c000-uart", "sifive,uart0";
interrupt-parent = <&plic0>;
interrupts = <80>;
reg = <0x10010000 0x1000>;
clocks = <&prci FU540_PRCI_CLK_TLCLK>;
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/serial/snps,arc-uart.yaml b/Documentation/devicetree/bindings/serial/snps,arc-uart.yaml
new file mode 100644
index 000000000000..dd3096fbfb6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/snps,arc-uart.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/snps,arc-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys ARC UART
+
+maintainers:
+ - Vineet Gupta <vgupta@kernel.org>
+
+description:
+ Synopsys ARC UART is a non-standard UART used in some of the ARC FPGA boards.
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: snps,arc-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ description: the input clock frequency for the UART
+
+ current-speed:
+ description: baud rate for UART
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clock-frequency
+ - current-speed
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@c0fc1000 {
+ compatible = "snps,arc-uart";
+ reg = <0xc0fc1000 0x100>;
+ interrupts = <5>;
+ clock-frequency = <80000000>;
+ current-speed = <115200>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index dc74643ae72e..6efe43089a74 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -11,41 +11,72 @@ maintainers:
allOf:
- $ref: serial.yaml#
+ - $ref: rs485.yaml#
+
+ - if:
+ properties:
+ compatible:
+ items:
+ - {}
+ - const: renesas,rzn1-uart
+ - const: snps,dw-apb-uart
+ then:
+ properties:
+ dmas: false
+ dma-names: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-uart
+ then:
+ properties:
+ resets:
+ minItems: 2
+ else:
+ properties:
+ resets:
+ maxItems: 1
properties:
compatible:
oneOf:
- items:
- - enum:
- - renesas,r9a06g032-uart
- - renesas,r9a06g033-uart
+ - const: renesas,r9a06g032-uart
+ - const: renesas,rzn1-uart
+ - const: snps,dw-apb-uart
+ - items:
+ - const: renesas,r9a06g032-uart
- const: renesas,rzn1-uart
- items:
- enum:
+ - anlogic,dr1v90-uart
+ - brcm,bcm11351-dw-apb-uart
+ - brcm,bcm21664-dw-apb-uart
- rockchip,px30-uart
- rockchip,rk1808-uart
- rockchip,rk3036-uart
- rockchip,rk3066-uart
+ - rockchip,rk3128-uart
- rockchip,rk3188-uart
- rockchip,rk3288-uart
- rockchip,rk3308-uart
- rockchip,rk3328-uart
- rockchip,rk3368-uart
- rockchip,rk3399-uart
+ - rockchip,rk3506-uart
+ - rockchip,rk3528-uart
+ - rockchip,rk3562-uart
- rockchip,rk3568-uart
+ - rockchip,rk3576-uart
- rockchip,rk3588-uart
- rockchip,rv1108-uart
- rockchip,rv1126-uart
- - const: snps,dw-apb-uart
- - items:
- - enum:
- - brcm,bcm11351-dw-apb-uart
- - brcm,bcm21664-dw-apb-uart
- - const: snps,dw-apb-uart
- - items:
- - enum:
+ - sophgo,sg2044-uart
- starfive,jh7100-hsuart
- starfive,jh7100-uart
+ - starfive,jh7110-uart
- const: snps,dw-apb-uart
- const: snps,dw-apb-uart
@@ -66,14 +97,26 @@ properties:
- const: baudclk
- const: apb_pclk
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
snps,uart-16550-compatible:
description: reflects the value of UART_16550_COMPATIBLE configuration
parameter. Define this if your UART does not implement the busy functionality.
type: boolean
- resets:
+ power-domains:
maxItems: 1
+ resets:
+ minItems: 1
+ maxItems: 2
+
reg-shift: true
reg-io-width: true
@@ -108,7 +151,6 @@ properties:
required:
- compatible
- reg
- - interrupts
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/serial/socionext,milbeaut-usio-uart.yaml b/Documentation/devicetree/bindings/serial/socionext,milbeaut-usio-uart.yaml
new file mode 100644
index 000000000000..34a997ca2e11
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/socionext,milbeaut-usio-uart.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/socionext,milbeaut-usio-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext Milbeaut UART controller
+
+maintainers:
+ - Sugaya Taichi <sugaya.taichi@socionext.com>
+
+allOf:
+ - $ref: /schemas/serial/serial.yaml#
+
+properties:
+ compatible:
+ const: socionext,milbeaut-usio-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: RX interrupt specifier
+ - description: TX interrupt specifier
+
+ interrupt-names:
+ items:
+ - const: rx
+ - const: tx
+
+ clocks:
+ maxItems: 1
+
+ auto-flow-control:
+ description: Enable automatic flow control.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@1e700010 {
+ compatible = "socionext,milbeaut-usio-uart";
+ reg = <0x1e700010 0x10>;
+ interrupts = <0 141 0x4>, <0 149 0x4>;
+ interrupt-names = "rx", "tx";
+ clocks = <&clk 2>;
+ auto-flow-control;
+ };
diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.yaml b/Documentation/devicetree/bindings/serial/sprd-uart.yaml
index da0e2745b5fc..5bf2656afcfd 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 Unisoc Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/sprd-uart.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/sprd-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Spreadtrum serial UART
@@ -17,11 +17,18 @@ properties:
oneOf:
- items:
- enum:
+ - sprd,ums9632-uart
+ - const: sprd,sc9632-uart
+ - items:
+ - enum:
- sprd,sc9860-uart
- sprd,sc9863a-uart
- sprd,ums512-uart
+ - sprd,ums9620-uart
- const: sprd,sc9836-uart
- - const: sprd,sc9836-uart
+ - enum:
+ - sprd,sc9632-uart
+ - sprd,sc9836-uart
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/serial/st,asc.yaml b/Documentation/devicetree/bindings/serial/st,asc.yaml
new file mode 100644
index 000000000000..f2083388f36b
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/st,asc.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/st,asc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi SoCs Serial Port
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: serial.yaml#
+
+properties:
+ compatible:
+ const: st,asc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ st,hw-flow-ctrl:
+ description: When set, enable hardware flow control.
+ type: boolean
+
+ st,force-m1:
+ description: When set, force asc to be in Mode-1. This is recommended for
+ high bit rates above 19.2K.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/stih407-clks.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ serial@9830000 {
+ compatible = "st,asc";
+ reg = <0x9830000 0x2c>;
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 333dc42722d2..2ed526139269 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
maintainers:
- Erwan Le Ray <erwan.leray@foss.st.com>
-title: STMicroelectronics STM32 USART bindings
+title: STMicroelectronics STM32 USART
properties:
compatible:
@@ -35,8 +35,6 @@ properties:
description: enable hardware flow control (deprecated)
$ref: /schemas/types.yaml#/definitions/flag
- uart-has-rtscts: true
-
rx-tx-swap: true
dmas:
@@ -60,10 +58,8 @@ properties:
wakeup-source: true
- rs485-rts-delay: true
- rs485-rts-active-low: true
- linux,rs485-enabled-at-boot-time: true
- rs485-rx-during-tx: true
+ power-domains:
+ maxItems: 1
rx-threshold:
description:
@@ -77,6 +73,10 @@ properties:
enum: [1, 2, 4, 8, 12, 14, 16]
default: 8
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
allOf:
- $ref: rs485.yaml#
- $ref: serial.yaml#
diff --git a/Documentation/devicetree/bindings/serial/st-asc.txt b/Documentation/devicetree/bindings/serial/st-asc.txt
deleted file mode 100644
index 75d877f5968f..000000000000
--- a/Documentation/devicetree/bindings/serial/st-asc.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-*st-asc(Serial Port)
-
-Required properties:
-- compatible : Should be "st,asc".
-- reg, reg-names, interrupts, interrupt-names : Standard way to define device
- resources with names. look in
- Documentation/devicetree/bindings/resource-names.txt
-
-Optional properties:
-- st,hw-flow-ctrl bool flag to enable hardware flow control.
-- st,force-m1 bool flat to force asc to be in Mode-1 recommeded
- for high bit rates (above 19.2K)
-Example:
-serial@fe440000{
- compatible = "st,asc";
- reg = <0xfe440000 0x2c>;
- interrupts = <0 209 0>;
-};
diff --git a/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml
index 2e9b64abde70..7d0a4bcb88e9 100644
--- a/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml
@@ -2,10 +2,10 @@
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/serial/sunplus,sp7021-uart.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/serial/sunplus,sp7021-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Sunplus SoC SP7021 UART Controller Device Tree Bindings
+title: Sunplus SoC SP7021 UART Controller
maintainers:
- Hammer Hsieh <hammerh0314@gmail.com>
diff --git a/Documentation/devicetree/bindings/serial/via,vt8500-uart.yaml b/Documentation/devicetree/bindings/serial/via,vt8500-uart.yaml
new file mode 100644
index 000000000000..9c6819241a49
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/via,vt8500-uart.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/via,vt8500-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA VT8500 and WonderMedia WM8xxx UART Controller
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ enum:
+ - via,vt8500-uart # up to WM8850/WM8950
+ - wm,wm8880-uart # for WM8880 and later
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - interrupts
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial@d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ clocks = <&clkuart0>;
+ };
diff --git a/Documentation/devicetree/bindings/serial/vt8500-uart.txt b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
deleted file mode 100644
index 2b64e6107fb3..000000000000
--- a/Documentation/devicetree/bindings/serial/vt8500-uart.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* VIA VT8500 and WonderMedia WM8xxx UART Controller
-
-Required properties:
-- compatible: should be "via,vt8500-uart" (for VIA/WonderMedia chips up to and
- including WM8850/WM8950), or "wm,wm8880-uart" (for WM8880 and later)
-
-- reg: base physical address of the controller and length of memory mapped
- region.
-
-- interrupts: hardware interrupt number
-
-- clocks: shall be the input parent clock phandle for the clock. This should
- be the 24Mhz reference clock.
-
-Aliases may be defined to ensure the correct ordering of the uarts.
-
-Example:
- aliases {
- serial0 = &uart0;
- };
-
- uart0: serial@d8200000 {
- compatible = "via,vt8500-uart";
- reg = <0xd8200000 0x1040>;
- interrupts = <32>;
- clocks = <&clkuart0>;
- };
diff --git a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
index f7617b88c7c3..08dcb275d8e2 100644
--- a/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
+++ b/Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
@@ -63,12 +63,11 @@ required:
- xlnx,use-parity
allOf:
- - $ref: /schemas/serial.yaml#
+ - $ref: serial.yaml#
- if:
properties:
xlnx,use-parity:
- contains:
- const: 1
+ const: 1
then:
required:
- xlnx,odd-parity
@@ -77,7 +76,7 @@ unevaluatedProperties: false
examples:
- |
- serial@800c0000 {
+ serial@800c0000 {
compatible = "xlnx,xps-uartlite-1.00.a";
reg = <0x800c0000 0x10000>;
interrupts = <0x0 0x6e 0x1>;
@@ -85,5 +84,5 @@ examples:
current-speed = <115200>;
xlnx,data-bits = <8>;
xlnx,use-parity = <0>;
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/serio/allwinner,sun4i-a10-ps2.yaml b/Documentation/devicetree/bindings/serio/allwinner,sun4i-a10-ps2.yaml
index 2ecab8ed702a..7fa70fd1f291 100644
--- a/Documentation/devicetree/bindings/serio/allwinner,sun4i-a10-ps2.yaml
+++ b/Documentation/devicetree/bindings/serio/allwinner,sun4i-a10-ps2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/serio/allwinner,sun4i-a10-ps2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 PS2 Host Controller Device Tree Bindings
+title: Allwinner A10 PS2 Host Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.yaml b/Documentation/devicetree/bindings/serio/ps2-gpio.yaml
index a63d9172346f..99848bc34f6e 100644
--- a/Documentation/devicetree/bindings/serio/ps2-gpio.yaml
+++ b/Documentation/devicetree/bindings/serio/ps2-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/serio/ps2-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for GPIO based PS/2
+title: GPIO based PS/2
maintainers:
- Danilo Krummrich <danilokrummrich@dk-develop.de>
diff --git a/Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.txt b/Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.txt
deleted file mode 100644
index 55259cf39c25..000000000000
--- a/Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Eckelmann SIOX GPIO bus
-
-Required properties:
-- compatible : "eckelmann,siox-gpio"
-- din-gpios, dout-gpios, dclk-gpios, dld-gpios: references gpios for the
- corresponding bus signals.
-
-Examples:
-
- siox {
- compatible = "eckelmann,siox-gpio";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_siox>;
-
- din-gpios = <&gpio6 11 0>;
- dout-gpios = <&gpio6 8 0>;
- dclk-gpios = <&gpio6 9 0>;
- dld-gpios = <&gpio6 10 0>;
- };
diff --git a/Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.yaml b/Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.yaml
new file mode 100644
index 000000000000..2ff204109b93
--- /dev/null
+++ b/Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/siox/eckelmann,siox-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Eckelmann SIOX GPIO bus
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: eckelmann,siox-gpio
+
+ din-gpios:
+ maxItems: 1
+
+ dout-gpios:
+ maxItems: 1
+
+ dclk-gpios:
+ maxItems: 1
+
+ dld-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - din-gpios
+ - dout-gpios
+ - dclk-gpios
+ - dld-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ siox {
+ compatible = "eckelmann,siox-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_siox>;
+
+ din-gpios = <&gpio6 11 0>;
+ dout-gpios = <&gpio6 8 0>;
+ dclk-gpios = <&gpio6 9 0>;
+ dld-gpios = <&gpio6 10 0>;
+ };
diff --git a/Documentation/devicetree/bindings/slimbus/bus.txt b/Documentation/devicetree/bindings/slimbus/bus.txt
deleted file mode 100644
index bbe871f82a8b..000000000000
--- a/Documentation/devicetree/bindings/slimbus/bus.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-SLIM(Serial Low Power Interchip Media Bus) bus
-
-SLIMbus is a 2-wire bus, and is used to communicate with peripheral
-components like audio-codec.
-
-Required property for SLIMbus controller node:
-- compatible - name of SLIMbus controller
-
-Child nodes:
-Every SLIMbus controller node can contain zero or more child nodes
-representing slave devices on the bus. Every SLIMbus slave device is
-uniquely determined by the enumeration address containing 4 fields:
-Manufacturer ID, Product code, Device index, and Instance value for
-the device.
-If child node is not present and it is instantiated after device
-discovery (slave device reporting itself present).
-
-In some cases it may be necessary to describe non-probeable device
-details such as non-standard ways of powering up a device. In
-such cases, child nodes for those devices will be present as
-slaves of the SLIMbus controller, as detailed below.
-
-Required property for SLIMbus child node if it is present:
-- reg - Should be ('Device index', 'Instance ID') from SLIMbus
- Enumeration Address.
- Device Index Uniquely identifies multiple Devices within
- a single Component.
- Instance ID Is for the cases where multiple Devices of the
- same type or Class are attached to the bus.
-
-- compatible -"slimMID,PID". The textual representation of Manufacturer ID,
- Product Code, shall be in lower case hexadecimal with leading
- zeroes suppressed
-
-Optional property for SLIMbus child node if it is present:
-- slim-ifc-dev - Should be phandle to SLIMBus Interface device.
- Required for devices which deal with streams.
-
-SLIMbus example for Qualcomm's slimbus manager component:
-
- slim@28080000 {
- compatible = "qcom,apq8064-slim", "qcom,slim";
- reg = <0x28080000 0x2000>,
- interrupts = <0 33 0>;
- clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
- clock-names = "iface", "core";
- #address-cells = <2>;
- #size-cell = <0>;
-
- codec_ifd: ifd@0,0{
- compatible = "slim217,60";
- reg = <0 0>;
- };
-
- codec: wcd9310@1,0{
- compatible = "slim217,60";
- reg = <1 0>;
- slim-ifc-dev = <&codec_ifd>;
- };
- };
diff --git a/Documentation/devicetree/bindings/slimbus/qcom,slim-ngd.yaml b/Documentation/devicetree/bindings/slimbus/qcom,slim-ngd.yaml
new file mode 100644
index 000000000000..27a92b79c724
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/qcom,slim-ngd.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/slimbus/qcom,slim-ngd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoC SLIMBus Non Generic Device (NGD) Controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ SLIMBus NGD controller is a light-weight driver responsible for communicating
+ with SLIMBus slaves directly over the bus using messaging interface and
+ communicating with master component residing on ADSP for bandwidth and
+ data-channel management
+
+properties:
+ compatible:
+ enum:
+ - qcom,slim-ngd-v1.5.0 # for MSM8996
+ - qcom,slim-ngd-v2.1.0 # for SDM845
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+patternProperties:
+ "^slim@[0-9a-f]+$":
+ type: object
+ $ref: slimbus.yaml#
+ description:
+ Each subnode represents an instance of NGD
+
+ properties:
+ reg:
+ maxItems: 1
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - dmas
+ - dma-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ slim-ngd@171c0000 {
+ compatible = "qcom,slim-ngd-v2.1.0";
+ reg = <0x171c0000 0x2c000>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+
+ dmas = <&slimbam 3>, <&slimbam 4>;
+ dma-names = "rx", "tx";
+ iommus = <&apps_smmu 0x1806 0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ slim@1 {
+ reg = <1>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ codec@1,0 {
+ compatible = "slim217,250";
+ reg = <1 0>;
+ slim-ifc-dev = <&wcd9340_ifd>;
+
+ #sound-dai-cells = <1>;
+
+ interrupts-extended = <&tlmm 54 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ #clock-cells = <0>;
+ clock-frequency = <9600000>;
+ clock-output-names = "mclk";
+ qcom,micbias1-microvolt = <1800000>;
+ qcom,micbias2-microvolt = <1800000>;
+ qcom,micbias3-microvolt = <1800000>;
+ qcom,micbias4-microvolt = <1800000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ reset-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
+
+ /* Rest of the WCD9340 codec */
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
deleted file mode 100644
index e94a2ad3a710..000000000000
--- a/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-Qualcomm SLIMBus Non Generic Device (NGD) Controller binding
-
-SLIMBus NGD controller is a light-weight driver responsible for communicating
-with SLIMBus slaves directly over the bus using messaging interface and
-communicating with master component residing on ADSP for bandwidth and
-data-channel management
-
-Please refer to slimbus/bus.txt for details of the common SLIMBus bindings.
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: must be "qcom,slim-ngd-v<MAJOR>.<MINOR>.<STEP>"
- must be one of the following.
- "qcom,slim-ngd-v1.5.0" for MSM8996
- "qcom,slim-ngd-v2.1.0" for SDM845
-
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: must specify the base address and size of the controller
- register space.
-- dmas
- Usage: required
- Value type: <array of phandles>
- Definition: List of rx and tx dma channels
-
-- dma-names
- Usage: required
- Value type: <stringlist>
- Definition: must be "rx" and "tx".
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: must list controller IRQ.
-
-#address-cells
- Usage: required
- Value type: <u32>
- Definition: Should be 1, reflecting the instance id of ngd.
-
-#size-cells
- Usage: required
- Value type: <u32>
- Definition: Should be 0
-
-= NGD Devices
-Each subnode represents an instance of NGD, must contain the following
-properties:
-
-- reg:
- Usage: required
- Value type: <u32>
- Definition: Should be instance id of ngd.
-
-#address-cells
- Usage: required
- Refer to slimbus/bus.txt for details of the common SLIMBus bindings.
-
-#size-cells
- Usage: required
- Refer to slimbus/bus.txt for details of the common SLIMBus bindings.
-
-= EXAMPLE
-
-slim@91c0000 {
- compatible = "qcom,slim-ngd-v1.5.0";
- reg = <0x91c0000 0x2c000>;
- interrupts = <0 163 0>;
- dmas = <&slimbam 3>, <&slimbam 4>;
- dma-names = "rx", "tx";
- #address-cells = <1>;
- #size-cells = <0>;
- ngd@1 {
- reg = <1>;
- #address-cells = <1>;
- #size-cells = <1>;
- codec@1 {
- compatible = "slim217,1a0";
- reg = <1 0>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
deleted file mode 100644
index 922dcb8ff24a..000000000000
--- a/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Qualcomm SLIMbus controller
-This controller is used if applications processor driver controls SLIMbus
-master component.
-
-Required properties:
-
- - #address-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
- - #size-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
-
- - reg : Offset and length of the register region(s) for the device
- - reg-names : Register region name(s) referenced in reg above
- Required register resource entries are:
- "ctrl": Physical address of controller register blocks
- "slew": required for "qcom,apq8064-slim" SOC.
- - compatible : should be "qcom,<SOC-NAME>-slim" for SOC specific compatible
- followed by "qcom,slim" for fallback.
- - interrupts : Interrupt number used by this controller
- - clocks : Interface and core clocks used by this SLIMbus controller
- - clock-names : Required clock-name entries are:
- "iface" : Interface clock for this controller
- "core" : Interrupt for controller core's BAM
-
-Example:
-
- slim@28080000 {
- compatible = "qcom,apq8064-slim", "qcom,slim";
- reg = <0x28080000 0x2000>, <0x80207C 4>;
- reg-names = "ctrl", "slew";
- interrupts = <0 33 0>;
- clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
- clock-names = "iface", "core";
- #address-cells = <2>;
- #size-cell = <0>;
-
- wcd9310: audio-codec@1,0{
- compatible = "slim217,60";
- reg = <1 0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
new file mode 100644
index 000000000000..5a941610ce4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/slimbus/slimbus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SLIM (Serial Low Power Interchip Media) bus
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ SLIMbus is a 2-wire bus, and is used to communicate with peripheral
+ components like audio-codec.
+
+properties:
+ $nodename:
+ pattern: "^slim(@.*|-([0-9]|[1-9][0-9]+))?$"
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^.*@[0-9a-f]+,[0-9a-f]+$":
+ type: object
+ description: |
+ Every SLIMbus controller node can contain zero or more child nodes
+ representing slave devices on the bus. Every SLIMbus slave device is
+ uniquely determined by the enumeration address containing 4 fields::
+ Manufacturer ID, Product code, Device index, and Instance value for the
+ device.
+
+ If child node is not present and it is instantiated after device
+ discovery (slave device reporting itself present).
+
+ In some cases it may be necessary to describe non-probeable device
+ details such as non-standard ways of powering up a device. In such cases,
+ child nodes for those devices will be present as slaves of the SLIMbus
+ controller.
+
+ properties:
+ compatible:
+ pattern: "^slim[0-9a-f]+,[0-9a-f]+$"
+
+ reg:
+ maxItems: 1
+ description: |
+ Pair of (device index, instande ID), where::
+ - Device index, which uniquely identifies multiple devices within a
+ single component.
+ - Instance ID, can be used for the cases where multiple devices of
+ the same type or class are attached to the bus.
+
+ required:
+ - compatible
+ - reg
+
+ additionalProperties: true
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ controller@28080000 {
+ compatible = "qcom,slim-ngd-v1.5.0";
+ reg = <0x091c0000 0x2c000>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&slimbam 3>, <&slimbam 4>;
+ dma-names = "rx", "tx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ slim@1 {
+ reg = <1>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ codec@1,0 {
+ compatible = "slim217,1a0";
+ reg = <1 0>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml b/Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml
new file mode 100644
index 000000000000..d56ff4c05ae5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/altera/altr,sys-mgr.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/altera/altr,sys-mgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera SOCFPGA System Manager
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - description: Cyclone5/Arria5/Arria10
+ const: altr,sys-mgr
+ - description: Stratix10 SoC
+ items:
+ - const: altr,sys-mgr-s10
+ - const: altr,sys-mgr
+
+ reg:
+ maxItems: 1
+
+ cpu1-start-addr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: CPU1 start address in hex
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: altr,sys-mgr-s10
+ then:
+ properties:
+ cpu1-start-addr: false
+
+additionalProperties: false
+
+examples:
+ - |
+ sysmgr@ffd08000 {
+ compatible = "altr,sys-mgr";
+ reg = <0xffd08000 0x1000>;
+ cpu1-start-addr = <0xffd080c4>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml
index c3c599096353..cd06865e1f2a 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/amlogic/amlogic,canvas.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/amlogic/amlogic,canvas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Canvas Video Lookup Table
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
new file mode 100644
index 000000000000..39d4637c2d08
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-clk-measure.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Internal Clock Measurer
+
+description:
+ The Amlogic SoCs contains an IP to measure the internal clocks.
+ The precision is multiple of MHz, useful to debug the clock states.
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-clk-measure
+ - amlogic,meson8-clk-measure
+ - amlogic,meson8b-clk-measure
+ - amlogic,meson-axg-clk-measure
+ - amlogic,meson-g12a-clk-measure
+ - amlogic,meson-sm1-clk-measure
+ - amlogic,c3-clk-measure
+ - amlogic,s4-clk-measure
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ clock-measure@8758 {
+ compatible = "amlogic,meson-gx-clk-measure";
+ reg = <0x8758 0x10>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml
new file mode 100644
index 000000000000..f3a85c67ce8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml
@@ -0,0 +1,207 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson System Control registers
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - amlogic,meson-hhi-sysctrl
+ - amlogic,meson-gx-hhi-sysctrl
+ - amlogic,meson-gx-ao-sysctrl
+ - amlogic,meson-axg-hhi-sysctrl
+ - amlogic,meson-axg-ao-sysctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ type: object
+
+ power-controller:
+ $ref: /schemas/power/amlogic,meson-ee-pwrc.yaml
+
+ pinctrl:
+ type: object
+
+ phy:
+ type: object
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-hhi-sysctrl
+ then:
+ properties:
+ clock-controller:
+ $ref: /schemas/clock/amlogic,meson8-clkc.yaml#
+
+ pinctrl: false
+ phy: false
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-hhi-sysctrl
+ - amlogic,meson-axg-hhi-sysctrl
+ then:
+ properties:
+ clock-controller:
+ $ref: /schemas/clock/amlogic,gxbb-clkc.yaml#
+
+ required:
+ - power-controller
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-ao-sysctrl
+ - amlogic,meson-axg-ao-sysctrl
+ then:
+ properties:
+ clock-controller:
+ $ref: /schemas/clock/amlogic,gxbb-aoclkc.yaml#
+
+ power-controller: false
+ phy: false
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-hhi-sysctrl
+ then:
+ properties:
+ phy: false
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - amlogic,meson-axg-hhi-sysctrl
+ then:
+ properties:
+ phy:
+ oneOf:
+ - $ref: /schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml
+ - $ref: /schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml
+
+required:
+ - compatible
+ - reg
+ - clock-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ bus@c883c000 {
+ compatible = "simple-bus";
+ reg = <0xc883c000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xc883c000 0x2000>;
+
+ sysctrl: system-controller@0 {
+ compatible = "amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon";
+ reg = <0 0x400>;
+
+ clock-controller {
+ compatible = "amlogic,gxbb-clkc";
+ #clock-cells = <1>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ };
+
+ power-controller {
+ compatible = "amlogic,meson-gxbb-pwrc";
+ #power-domain-cells = <1>;
+ amlogic,ao-sysctrl = <&sysctrl_AO>;
+
+ resets = <&reset_viu>,
+ <&reset_venc>,
+ <&reset_vcbus>,
+ <&reset_bt656>,
+ <&reset_dvin>,
+ <&reset_rdma>,
+ <&reset_venci>,
+ <&reset_vencp>,
+ <&reset_vdac>,
+ <&reset_vdi6>,
+ <&reset_vencl>,
+ <&reset_vid_lock>;
+ reset-names = "viu", "venc", "vcbus", "bt656", "dvin",
+ "rdma", "venci", "vencp", "vdac", "vdi6",
+ "vencl", "vid_lock";
+ clocks = <&clk_vpu>, <&clk_vapb>;
+ clock-names = "vpu", "vapb";
+ };
+ };
+ };
+
+ bus@c8100000 {
+ compatible = "simple-bus";
+ reg = <0xc8100000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0xc8100000 0x100000>;
+
+ sysctrl_AO: system-controller@0 {
+ compatible = "amlogic,meson-gx-ao-sysctrl", "simple-mfd", "syscon";
+ reg = <0 0x100>;
+
+ clock-controller {
+ compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ clocks = <&xtal>, <&clk81>;
+ clock-names = "xtal", "mpeg-clk";
+ };
+ };
+ };
+
+ - |
+ system-controller@ff63c000 {
+ compatible = "amlogic,meson-axg-hhi-sysctrl", "simple-mfd", "syscon";
+ reg = <0xff63c000 0x400>;
+
+ clock-controller {
+ compatible = "amlogic,axg-clkc";
+ #clock-cells = <1>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ };
+
+ power-controller {
+ compatible = "amlogic,meson-axg-pwrc";
+ #power-domain-cells = <1>;
+ amlogic,ao-sysctrl = <&sysctrl_AO>;
+
+ resets = <&reset_viu>,
+ <&reset_venc>,
+ <&reset_vcbus>,
+ <&reset_vencl>,
+ <&reset_vid_lock>;
+ reset-names = "viu", "venc", "vcbus", "vencl", "vid_lock";
+ clocks = <&clk_vpu>, <&clk_vapb>;
+ clock-names = "vpu", "vapb";
+ };
+
+ phy {
+ compatible = "amlogic,axg-mipi-pcie-analog-phy";
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
deleted file mode 100644
index 3dd563cec794..000000000000
--- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Amlogic Internal Clock Measurer
-===============================
-
-The Amlogic SoCs contains an IP to measure the internal clocks.
-The precision is multiple of MHz, useful to debug the clock states.
-
-Required properties:
-- compatible: Shall contain one of the following :
- "amlogic,meson-gx-clk-measure" for GX SoCs
- "amlogic,meson8-clk-measure" for Meson8 SoCs
- "amlogic,meson8b-clk-measure" for Meson8b SoCs
- "amlogic,meson-axg-clk-measure" for AXG SoCs
- "amlogic,meson-g12a-clk-measure" for G12a SoCs
- "amlogic,meson-sm1-clk-measure" for SM1 SoCs
-- reg: base address and size of the Clock Measurer register space.
-
-Example:
- clock-measure@8758 {
- compatible = "amlogic,meson-gx-clk-measure";
- reg = <0x0 0x8758 0x0 0x10>;
- };
diff --git a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml
index 6876407124dc..51aaf34acb32 100644
--- a/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml
+++ b/Documentation/devicetree/bindings/soc/aspeed/uart-routing.yaml
@@ -3,8 +3,8 @@
# # Copyright (c) 2021 Aspeed Technology Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/aspeed/uart-routing.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aspeed UART Routing Controller
diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml
new file mode 100644
index 000000000000..1a952f569803
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm23550-cdc.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/bcm/brcm,bcm23550-cdc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM23550 Cluster Dormant Control
+
+description:
+ The Cluster Dormant Control block keeps the CPU in idle state. A command
+ needs to be sent to this block to bring the CPU into running state.
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,bcm23550-cdc
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ cdc@3fe0e000 {
+ compatible = "brcm,bcm23550-cdc";
+ reg = <0x3fe0e000 0x78>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2711-avs-monitor.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2711-avs-monitor.yaml
new file mode 100644
index 000000000000..e02d9d7e7d9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2711-avs-monitor.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/bcm/brcm,bcm2711-avs-monitor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom AVS Monitor
+
+maintainers:
+ - Stefan Wahren <wahrenst@gmx.net>
+
+properties:
+ compatible:
+ items:
+ - const: brcm,bcm2711-avs-monitor
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ thermal:
+ $ref: /schemas/thermal/brcm,avs-ro-thermal.yaml
+ description: Broadcom AVS ring oscillator thermal
+
+required:
+ - compatible
+ - reg
+ - thermal
+
+additionalProperties: false
+
+examples:
+ - |
+ avs-monitor@7d5d2000 {
+ compatible = "brcm,bcm2711-avs-monitor", "syscon", "simple-mfd";
+ reg = <0x7d5d2000 0xf00>;
+
+ thermal: thermal {
+ compatible = "brcm,bcm2711-thermal";
+ #thermal-sensor-cells = <0>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
index e28ef198a801..039c8e4a4c51 100644
--- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
@@ -13,23 +13,21 @@ description: |
maintainers:
- Nicolas Saenz Julienne <nsaenz@kernel.org>
-allOf:
- - $ref: /schemas/watchdog/watchdog.yaml#
-
properties:
compatible:
items:
- enum:
- brcm,bcm2835-pm
- brcm,bcm2711-pm
+ - brcm,bcm2712-pm
- const: brcm,bcm2835-pm-wdt
reg:
- minItems: 2
+ minItems: 1
maxItems: 3
reg-names:
- minItems: 2
+ minItems: 1
items:
- const: pm
- const: asb
@@ -62,7 +60,35 @@ required:
- reg
- "#power-domain-cells"
- "#reset-cells"
- - clocks
+
+allOf:
+ - $ref: /schemas/watchdog/watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm2835-pm
+ - brcm,bcm2711-pm
+ then:
+ required:
+ - clocks
+
+ properties:
+ reg:
+ minItems: 2
+
+ reg-names:
+ minItems: 2
+
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ reg-names:
+ maxItems: 1
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt b/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
deleted file mode 100644
index 30942cf7992b..000000000000
--- a/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Raspberry Pi power domain driver
-
-Required properties:
-
-- compatible: Should be "raspberrypi,bcm2835-power".
-- firmware: Reference to the RPi firmware device node.
-- #power-domain-cells: Should be <1>, we providing multiple power domains.
-
-The valid defines for power domain are:
-
- RPI_POWER_DOMAIN_I2C0
- RPI_POWER_DOMAIN_I2C1
- RPI_POWER_DOMAIN_I2C2
- RPI_POWER_DOMAIN_VIDEO_SCALER
- RPI_POWER_DOMAIN_VPU1
- RPI_POWER_DOMAIN_HDMI
- RPI_POWER_DOMAIN_USB
- RPI_POWER_DOMAIN_VEC
- RPI_POWER_DOMAIN_JPEG
- RPI_POWER_DOMAIN_H264
- RPI_POWER_DOMAIN_V3D
- RPI_POWER_DOMAIN_ISP
- RPI_POWER_DOMAIN_UNICAM0
- RPI_POWER_DOMAIN_UNICAM1
- RPI_POWER_DOMAIN_CCP2RX
- RPI_POWER_DOMAIN_CSI2
- RPI_POWER_DOMAIN_CPI
- RPI_POWER_DOMAIN_DSI0
- RPI_POWER_DOMAIN_DSI1
- RPI_POWER_DOMAIN_TRANSPOSER
- RPI_POWER_DOMAIN_CCP2TX
- RPI_POWER_DOMAIN_CDP
- RPI_POWER_DOMAIN_ARM
-
-Example:
-
-power: power {
- compatible = "raspberrypi,bcm2835-power";
- firmware = <&firmware>;
- #power-domain-cells = <1>;
-};
-
-Example for using power domain:
-
-&usb {
- power-domains = <&power RPI_POWER_DOMAIN_USB>;
-};
diff --git a/Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml b/Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml
new file mode 100644
index 000000000000..7cb1b4114985
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/cirrus/cirrus,ep9301-syscon.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/cirrus/cirrus,ep9301-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP93xx Platforms System Controller
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+description: |
+ Central resources are controlled by a set of software-locked registers,
+ which can be used to prevent accidental accesses. Syscon generates
+ the various bus and peripheral clocks and controls the system startup
+ configuration.
+
+ The System Controller (Syscon) provides:
+ - Clock control
+ - Power management
+ - System configuration management
+
+ Syscon registers are common for all EP93xx SoC's, through some actual peripheral
+ may be missing depending on actual SoC model.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - cirrus,ep9302-syscon
+ - cirrus,ep9307-syscon
+ - cirrus,ep9312-syscon
+ - cirrus,ep9315-syscon
+ - const: cirrus,ep9301-syscon
+ - const: syscon
+ - items:
+ - const: cirrus,ep9301-syscon
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ clocks:
+ items:
+ - description: reference clock
+
+patternProperties:
+ '^pins-':
+ type: object
+ description: pin node
+ $ref: /schemas/pinctrl/pinmux-node.yaml
+
+ properties:
+ function:
+ enum: [ spi, ac97, i2s, pwm, keypad, pata, lcd, gpio ]
+
+ groups:
+ enum: [ ssp, ac97, i2s_on_ssp, i2s_on_ac97, pwm1, gpio1agrp,
+ gpio2agrp, gpio3agrp, gpio4agrp, gpio6agrp, gpio7agrp,
+ rasteronsdram0grp, rasteronsdram3grp, keypadgrp, idegrp ]
+
+ required:
+ - function
+ - groups
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@80930000 {
+ compatible = "cirrus,ep9301-syscon", "syscon";
+ reg = <0x80930000 0x1000>;
+
+ #clock-cells = <1>;
+ clocks = <&xtali>;
+
+ spi_default_pins: pins-spi {
+ function = "spi";
+ groups = "ssp";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/bman-portals.txt b/Documentation/devicetree/bindings/soc/fsl/bman-portals.txt
deleted file mode 100644
index 2a00e14e11e0..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/bman-portals.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-QorIQ DPAA Buffer Manager Portals Device Tree Binding
-
-Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
-
-CONTENTS
-
- - BMan Portal
- - Example
-
-BMan Portal Node
-
-Portals are memory mapped interfaces to BMan that allow low-latency, lock-less
-interaction by software running on processor cores, accelerators and network
-interfaces with the BMan
-
-PROPERTIES
-
-- compatible
- Usage: Required
- Value type: <stringlist>
- Definition: Must include "fsl,bman-portal-<hardware revision>"
- May include "fsl,<SoC>-bman-portal" or "fsl,bman-portal"
-
-- reg
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Two regions. The first is the cache-enabled region of
- the portal. The second is the cache-inhibited region of
- the portal
-
-- interrupts
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Standard property
-
-EXAMPLE
-
-The example below shows a (P4080) BMan portals container/bus node with two portals
-
- bman-portals@ff4000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "simple-bus";
- ranges = <0 0xf 0xf4000000 0x200000>;
-
- bman-portal@0 {
- compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
- reg = <0x0 0x4000>, <0x100000 0x1000>;
- interrupts = <105 2 0 0>;
- };
- bman-portal@4000 {
- compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
- reg = <0x4000 0x4000>, <0x101000 0x1000>;
- interrupts = <107 2 0 0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/bman.txt b/Documentation/devicetree/bindings/soc/fsl/bman.txt
deleted file mode 100644
index 48eed140765b..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/bman.txt
+++ /dev/null
@@ -1,137 +0,0 @@
-QorIQ DPAA Buffer Manager Device Tree Bindings
-
-Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
-
-CONTENTS
-
- - BMan Node
- - BMan Private Memory Node
- - Example
-
-BMan Node
-
-The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
-BMan supports hardware allocation and deallocation of buffers belonging to pools
-originally created by software with configurable depletion thresholds. This
-binding covers the CCSR space programming model
-
-PROPERTIES
-
-- compatible
- Usage: Required
- Value type: <stringlist>
- Definition: Must include "fsl,bman"
- May include "fsl,<SoC>-bman"
-
-- reg
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Registers region within the CCSR address space
-
-The BMan revision information is located in the BMAN_IP_REV_1/2 registers which
-are located at offsets 0xbf8 and 0xbfc
-
-- interrupts
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Standard property. The error interrupt
-
-- fsl,bman-portals
- Usage: Required
- Value type: <phandle>
- Definition: Phandle to this BMan instance's portals
-
-- fsl,liodn
- Usage: See pamu.txt
- Value type: <prop-encoded-array>
- Definition: PAMU property used for static LIODN assignment
-
-- fsl,iommu-parent
- Usage: See pamu.txt
- Value type: <phandle>
- Definition: PAMU property used for dynamic LIODN assignment
-
- For additional details about the PAMU/LIODN binding(s) see pamu.txt
-
-Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
-to the respective BMan instance
-
-- fsl,bman
- Usage: Required
- Value type: <prop-encoded-array>
- Description: List of phandle and DCP index pairs, to the BMan instance
- to which this device is connected via the DCP
-
-BMan Private Memory Node
-
-BMan requires a contiguous range of physical memory used for the backing store
-for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated as
-a node under the /reserved-memory node.
-
-The BMan FBPR memory node must be named "bman-fbpr"
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: PPC platforms: Must include "fsl,bman-fbpr"
- ARM platforms: Must include "shared-dma-pool"
- as well as the "no-map" property
-
-The following constraints are relevant to the FBPR private memory:
- - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
- 16 GiB
- - The alignment must be a muliptle of the memory size
-
-The size of the FBPR must be chosen by observing the hardware features configured
-via the Reset Configuration Word (RCW) and that are relevant to a specific board
-(e.g. number of MAC(s) pinned-out, number of offline/host command FMan ports,
-etc.). The size configured in the DT must reflect the hardware capabilities and
-not the specific needs of an application
-
-For additional details about reserved memory regions see reserved-memory.txt
-
-EXAMPLE
-
-The example below shows a BMan FBPR dynamic allocation memory node
-
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- bman_fbpr: bman-fbpr {
- compatible = "shared-mem-pool";
- size = <0 0x1000000>;
- alignment = <0 0x1000000>;
- no-map;
- };
- };
-
-The example below shows a (P4080) BMan CCSR-space node
-
- bportals: bman-portals@ff4000000 {
- ...
- };
-
- crypto@300000 {
- ...
- fsl,bman = <&bman, 2>;
- ...
- };
-
- bman: bman@31a000 {
- compatible = "fsl,bman";
- reg = <0x31a000 0x1000>;
- interrupts = <16 2 1 2>;
- fsl,liodn = <0x17>;
- fsl,bman-portals = <&bportals>;
- memory-region = <&bman_fbpr>;
- };
-
- fman@400000 {
- ...
- fsl,bman = <&bman, 0>;
- ...
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
new file mode 100644
index 000000000000..e802e25923aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PowerQUICC CPM QUICC Multichannel Controller (QMC)
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The QMC (QUICC Multichannel Controller) emulates up to 64 channels within one
+ serial controller using the same TDM physical interface routed from TSA.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc885-scc-qmc
+ - fsl,mpc866-scc-qmc
+ - const: fsl,cpm1-scc-qmc
+
+ reg:
+ items:
+ - description: SCC (Serial communication controller) register base
+ - description: SCC parameter ram base
+ - description: Dual port ram base
+
+ reg-names:
+ items:
+ - const: scc_regs
+ - const: scc_pram
+ - const: dpram
+
+ interrupts:
+ maxItems: 1
+ description: SCC interrupt line in the CPM interrupt controller
+
+ fsl,tsa-serial:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to TSA node
+ - enum: [1, 2, 3]
+ description: |
+ TSA serial interface (dt-bindings/soc/cpm1-fsl,tsa.h defines these
+ values)
+ - 1: SCC2
+ - 2: SCC3
+ - 3: SCC4
+ description:
+ Should be a phandle/number pair. The phandle to TSA node and the TSA
+ serial interface to use.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^channel@([0-9]|[1-5][0-9]|6[0-3])$':
+ description:
+ A channel managed by this controller
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 63
+ description:
+ The channel number
+
+ fsl,operational-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [transparent, hdlc]
+ default: transparent
+ description: |
+ The channel operational mode
+ - hdlc: The channel handles HDLC frames
+ - transparent: The channel handles raw data without any processing
+
+ fsl,reverse-data:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The bit order as seen on the channels is reversed,
+ transmitting/receiving the MSB of each octet first.
+ This flag is used only in 'transparent' mode.
+
+ fsl,tx-ts-mask:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ Channel assigned Tx time-slots within the Tx time-slots routed by the
+ TSA to this cell.
+
+ fsl,rx-ts-mask:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ Channel assigned Rx time-slots within the Rx time-slots routed by the
+ TSA to this cell.
+
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc885-scc-qmc-hdlc
+ - fsl,mpc866-scc-qmc-hdlc
+ - const: fsl,cpm1-scc-qmc-hdlc
+ - const: fsl,qmc-hdlc
+
+ fsl,framer:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the framer node. The framer is in charge of an E1/T1 line
+ interface connected to the TDM bus. It can be used to get the E1/T1 line
+ status such as link up/down.
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: fsl,qmc-hdlc
+ then:
+ properties:
+ fsl,framer: false
+
+ required:
+ - reg
+ - fsl,tx-ts-mask
+ - fsl,rx-ts-mask
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - fsl,tsa-serial
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/cpm1-fsl,tsa.h>
+
+ qmc@a60 {
+ compatible = "fsl,mpc885-scc-qmc", "fsl,cpm1-scc-qmc";
+ reg = <0xa60 0x20>,
+ <0x3f00 0xc0>,
+ <0x2000 0x1000>;
+ reg-names = "scc_regs", "scc_pram", "dpram";
+ interrupts = <27>;
+ interrupt-parent = <&CPM_PIC>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fsl,tsa-serial = <&tsa FSL_CPM_TSA_SCC4>;
+
+ channel@16 {
+ /* Ch16 : First 4 even TS from all routed from TSA */
+ reg = <16>;
+ fsl,operational-mode = "transparent";
+ fsl,reverse-data;
+ fsl,tx-ts-mask = <0x00000000 0x000000aa>;
+ fsl,rx-ts-mask = <0x00000000 0x000000aa>;
+ };
+
+ channel@17 {
+ /* Ch17 : First 4 odd TS from all routed from TSA */
+ reg = <17>;
+ fsl,operational-mode = "transparent";
+ fsl,reverse-data;
+ fsl,tx-ts-mask = <0x00000000 0x00000055>;
+ fsl,rx-ts-mask = <0x00000000 0x00000055>;
+ };
+
+ channel@19 {
+ /* Ch19 : 8 TS (TS 8..15) from all routed from TSA */
+ compatible = "fsl,mpc885-scc-qmc-hdlc",
+ "fsl,cpm1-scc-qmc-hdlc",
+ "fsl,qmc-hdlc";
+ reg = <19>;
+ fsl,operational-mode = "hdlc";
+ fsl,tx-ts-mask = <0x00000000 0x0000ff00>;
+ fsl,rx-ts-mask = <0x00000000 0x0000ff00>;
+ fsl,framer = <&framer>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml
new file mode 100644
index 000000000000..7e51c639a79a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml
@@ -0,0 +1,205 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PowerQUICC CPM Time-slot assigner (TSA) controller
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The TSA is the time-slot assigner that can be found on some PowerQUICC SoC.
+ Its purpose is to route some TDM time-slots to other internal serial
+ controllers.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc885-tsa
+ - fsl,mpc866-tsa
+ - const: fsl,cpm1-tsa
+
+ reg:
+ items:
+ - description: SI (Serial Interface) register base
+ - description: SI RAM base
+
+ reg-names:
+ items:
+ - const: si_regs
+ - const: si_ram
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^tdm@[0-1]$':
+ description:
+ The TDM managed by this controller
+ type: object
+
+ additionalProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 1
+ description:
+ The TDM number for this TDM, 0 for TDMa and 1 for TDMb
+
+ fsl,common-rxtx-pins:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The hardware can use four dedicated pins for Tx clock, Tx sync, Rx
+ clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync.
+ Without the 'fsl,common-rxtx-pins' property, the four pins are used.
+ With the 'fsl,common-rxtx-pins' property, two pins are used.
+
+ clocks:
+ minItems: 2
+ items:
+ - description: External clock connected to L1RSYNC pin
+ - description: External clock connected to L1RCLK pin
+ - description: External clock connected to L1TSYNC pin
+ - description: External clock connected to L1TCLK pin
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: l1rsync
+ - const: l1rclk
+ - const: l1tsync
+ - const: l1tclk
+
+ fsl,rx-frame-sync-delay-bits:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ Receive frame sync delay in number of bits.
+ Indicates the delay between the Rx sync and the first bit of the Rx
+ frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay.
+
+ fsl,tx-frame-sync-delay-bits:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ Transmit frame sync delay in number of bits.
+ Indicates the delay between the Tx sync and the first bit of the Tx
+ frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay.
+
+ fsl,clock-falling-edge:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Data is sent on falling edge of the clock (and received on the rising
+ edge). If 'clock-falling-edge' is not present, data is sent on the
+ rising edge (and received on the falling edge).
+
+ fsl,fsync-rising-edge:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Frame sync pulses are sampled with the rising edge of the channel
+ clock. If 'fsync-rising-edge' is not present, pulses are sampled with
+ the falling edge.
+
+ fsl,double-speed-clock:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The channel clock is twice the data rate.
+
+ patternProperties:
+ '^fsl,[rt]x-ts-routes$':
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ A list of tuple that indicates the Tx or Rx time-slots routes.
+ items:
+ items:
+ - description:
+ The number of time-slots
+ minimum: 1
+ maximum: 64
+ - description: |
+ The source (Tx) or destination (Rx) serial interface
+ (dt-bindings/soc/cpm1-fsl,tsa.h defines these values)
+ - 0: No destination
+ - 1: SCC2
+ - 2: SCC3
+ - 3: SCC4
+ - 4: SMC1
+ - 5: SMC2
+ enum: [0, 1, 2, 3, 4, 5]
+ minItems: 1
+ maxItems: 64
+
+ allOf:
+ # If fsl,common-rxtx-pins is present, only 2 clocks are needed.
+ # Else, the 4 clocks must be present.
+ - if:
+ required:
+ - fsl,common-rxtx-pins
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+ else:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+
+ required:
+ - reg
+ - clocks
+ - clock-names
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/cpm1-fsl,tsa.h>
+
+ tsa@ae0 {
+ compatible = "fsl,mpc885-tsa", "fsl,cpm1-tsa";
+ reg = <0xae0 0x10>,
+ <0xc00 0x200>;
+ reg-names = "si_regs", "si_ram";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tdm@0 {
+ /* TDMa */
+ reg = <0>;
+
+ clocks = <&clk_l1rsynca>, <&clk_l1rclka>;
+ clock-names = "l1rsync", "l1rclk";
+
+ fsl,common-rxtx-pins;
+ fsl,fsync-rising-edge;
+
+ fsl,tx-ts-routes = <2 0>, /* TS 0..1 */
+ <24 FSL_CPM_TSA_SCC4>, /* TS 2..25 */
+ <1 0>, /* TS 26 */
+ <5 FSL_CPM_TSA_SCC3>; /* TS 27..31 */
+
+ fsl,rx-ts-routes = <2 0>, /* TS 0..1 */
+ <24 FSL_CPM_TSA_SCC4>, /* 2..25 */
+ <1 0>, /* TS 26 */
+ <5 FSL_CPM_TSA_SCC3>; /* TS 27..31 */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-firmware.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-firmware.yaml
new file mode 100644
index 000000000000..53b07d4edc77
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-firmware.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-firmware.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QUICC Engine module Firmware Node
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ This node defines a firmware binary that is embedded in the device tree, for
+ the purpose of passing the firmware from bootloader to the kernel, or from
+ the hypervisor to the guest.
+
+ The firmware node itself contains the firmware binary contents, a compatible
+ property, and any firmware-specific properties. The node should be placed
+ inside a QE node that needs it. Doing so eliminates the need for a
+ fsl,firmware-phandle property. Other QE nodes that need the same firmware
+ should define an fsl,firmware-phandle property that points to the firmware node
+ in the first QE node.
+
+ The fsl,firmware property can be specified in the DTS (possibly using incbin)
+ or can be inserted by the boot loader at boot time.
+
+properties:
+ compatible:
+ enum:
+ - fsl,qe-firmware
+
+ fsl,firmware:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ A standard property. This property contains the firmware binary "blob".
+
+required:
+ - compatible
+ - fsl,firmware
+
+additionalProperties: false
+
+examples:
+ - |
+ qe-firmware {
+ compatible = "fsl,qe-firmware";
+ fsl,firmware = <0x70 0xcd 0x00 0x00 0x01 0x46 0x45>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ic.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ic.yaml
new file mode 100644
index 000000000000..8267ad00727b
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ic.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QUICC Engine module Interrupt Controller (IC)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,qe-ic
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: QE interrupt
+ - description: QE critical
+ - description: QE error
+ minItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@80 {
+ compatible = "fsl,qe-ic";
+ reg = <0x80 0x80>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupts = <95 2 0 0 94 2 0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-muram.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-muram.yaml
new file mode 100644
index 000000000000..2c06d869fdb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-muram.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-muram.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QUICC Engine Multi-User RAM (MURAM)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: Multi-User RAM (MURAM)
+
+properties:
+ compatible:
+ items:
+ - const: fsl,qe-muram
+ - const: fsl,cpm-muram
+
+ ranges:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [host, slave]
+
+patternProperties:
+ '^data\-only@[a-f0-9]+$':
+ type: object
+ properties:
+ compatible:
+ items:
+ - const: fsl,qe-muram-data
+ - const: fsl,cpm-muram-data
+
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ muram@10000 {
+ compatible = "fsl,qe-muram", "fsl,cpm-muram";
+ ranges = <0 0x00010000 0x0000c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ data-only@0{
+ compatible = "fsl,qe-muram-data",
+ "fsl,cpm-muram-data";
+ reg = <0 0xc000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-si.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-si.yaml
new file mode 100644
index 000000000000..8e58ab58c063
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-si.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-si.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QUICC Engine module Serial Interface Block (SI)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The SI manages the routing of eight TDM lines to the QE block serial drivers,
+ the MCC and the UCCs, for receive and transmit.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,ls1043-qe-si
+ - const: fsl,t1040-qe-si
+ - enum:
+ - fsl,t1040-qe-si
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ si@700 {
+ compatible = "fsl,t1040-qe-si";
+ reg = <0x700 0x80>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-siram.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-siram.yaml
new file mode 100644
index 000000000000..cc4ed48d786c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-siram.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-siram.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QUICC Engine module Serial Interface Block RAM(SIRAM)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ store the routing entries of SI
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,ls1043-qe-siram
+ - const: fsl,t1040-qe-siram
+ - const: fsl,t1040-qe-siram
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ siram@1000 {
+ compatible = "fsl,t1040-qe-siram";
+ reg = <0x1000 0x800>;
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-tsa.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-tsa.yaml
new file mode 100644
index 000000000000..3b50e0a003ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-tsa.yaml
@@ -0,0 +1,210 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-tsa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PowerQUICC QE Time-slot assigner (TSA) controller
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The TSA is the time-slot assigner that can be found on some PowerQUICC SoC.
+ Its purpose is to route some TDM time-slots to other internal serial
+ controllers.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc8321-tsa
+ - const: fsl,qe-tsa
+
+ reg:
+ items:
+ - description: SI (Serial Interface) register base
+ - description: SI RAM base
+
+ reg-names:
+ items:
+ - const: si_regs
+ - const: si_ram
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^tdm@[0-3]$':
+ description:
+ The TDM managed by this controller
+ type: object
+
+ additionalProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 3
+ description:
+ The TDM number for this TDM, 0 for TDMa, 1 for TDMb, 2 for TDMc and 3
+ for TDMd.
+
+ fsl,common-rxtx-pins:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The hardware can use four dedicated pins for Tx clock, Tx sync, Rx
+ clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync.
+ Without the 'fsl,common-rxtx-pins' property, the four pins are used.
+ With the 'fsl,common-rxtx-pins' property, two pins are used.
+
+ clocks:
+ minItems: 2
+ items:
+ - description: Receive sync clock
+ - description: Receive data clock
+ - description: Transmit sync clock
+ - description: Transmit data clock
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: rsync
+ - const: rclk
+ - const: tsync
+ - const: tclk
+
+ fsl,rx-frame-sync-delay-bits:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ Receive frame sync delay in number of bits.
+ Indicates the delay between the Rx sync and the first bit of the Rx
+ frame.
+
+ fsl,tx-frame-sync-delay-bits:
+ enum: [0, 1, 2, 3]
+ default: 0
+ description: |
+ Transmit frame sync delay in number of bits.
+ Indicates the delay between the Tx sync and the first bit of the Tx
+ frame.
+
+ fsl,clock-falling-edge:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Data is sent on falling edge of the clock (and received on the rising
+ edge). If not present, data is sent on the rising edge (and received
+ on the falling edge).
+
+ fsl,fsync-rising-edge:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Frame sync pulses are sampled with the rising edge of the channel
+ clock. If not present, pulses are sampled with the falling edge.
+
+ fsl,fsync-active-low:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Frame sync signals are active on low logic level.
+ If not present, sync signals are active on high level.
+
+ fsl,double-speed-clock:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The channel clock is twice the data rate.
+
+ patternProperties:
+ '^fsl,[rt]x-ts-routes$':
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ A list of tuple that indicates the Tx or Rx time-slots routes.
+ items:
+ items:
+ - description:
+ The number of time-slots
+ minimum: 1
+ maximum: 64
+ - description: |
+ The source (Tx) or destination (Rx) serial interface
+ (dt-bindings/soc/qe-fsl,tsa.h defines these values)
+ - 0: No destination
+ - 1: UCC1
+ - 2: UCC2
+ - 3: UCC3
+ - 4: UCC4
+ - 5: UCC5
+ enum: [0, 1, 2, 3, 4, 5]
+ minItems: 1
+ maxItems: 64
+
+ allOf:
+ # If fsl,common-rxtx-pins is present, only 2 clocks are needed.
+ # Else, the 4 clocks must be present.
+ - if:
+ required:
+ - fsl,common-rxtx-pins
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+ else:
+ properties:
+ clocks:
+ minItems: 4
+ clock-names:
+ minItems: 4
+
+ required:
+ - reg
+ - clocks
+ - clock-names
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qe-fsl,tsa.h>
+
+ tsa@ae0 {
+ compatible = "fsl,mpc8321-tsa", "fsl,qe-tsa";
+ reg = <0xae0 0x10>,
+ <0xc00 0x200>;
+ reg-names = "si_regs", "si_ram";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tdm@0 {
+ /* TDMa */
+ reg = <0>;
+
+ clocks = <&clk_l1rsynca>, <&clk_l1rclka>;
+ clock-names = "rsync", "rclk";
+
+ fsl,common-rxtx-pins;
+ fsl,fsync-rising-edge;
+
+ fsl,tx-ts-routes = <2 0>, /* TS 0..1 */
+ <24 FSL_QE_TSA_UCC4>, /* TS 2..25 */
+ <1 0>, /* TS 26 */
+ <5 FSL_QE_TSA_UCC3>; /* TS 27..31 */
+
+ fsl,rx-ts-routes = <2 0>, /* TS 0..1 */
+ <24 FSL_QE_TSA_UCC4>, /* 2..25 */
+ <1 0>, /* TS 26 */
+ <5 FSL_QE_TSA_UCC3>; /* TS 27..31 */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ucc-qmc.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ucc-qmc.yaml
new file mode 100644
index 000000000000..71ae64cb8a4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe-ucc-qmc.yaml
@@ -0,0 +1,197 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe-ucc-qmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PowerQUICC QE QUICC Multichannel Controller (QMC)
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ The QMC (QUICC Multichannel Controller) emulates up to 64 channels within one
+ serial controller using the same TDM physical interface routed from TSA.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc8321-ucc-qmc
+ - const: fsl,qe-ucc-qmc
+
+ reg:
+ items:
+ - description: UCC (Unified communication controller) register base
+ - description: Dual port ram base
+
+ reg-names:
+ items:
+ - const: ucc_regs
+ - const: dpram
+
+ interrupts:
+ maxItems: 1
+ description: UCC interrupt line in the QE interrupt controller
+
+ fsl,tsa-serial:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to TSA node
+ - enum: [1, 2, 3, 4, 5]
+ description: |
+ TSA serial interface (dt-bindings/soc/qe-fsl,tsa.h defines these
+ values)
+ - 1: UCC1
+ - 2: UCC2
+ - 3: UCC3
+ - 4: UCC4
+ - 5: UCC5
+ description:
+ Should be a phandle/number pair. The phandle to TSA node and the TSA
+ serial interface to use.
+
+ fsl,soft-qmc:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Soft QMC firmware name to load. If this property is omitted, no firmware
+ are used.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ '^channel@([0-9]|[1-5][0-9]|6[0-3])$':
+ description:
+ A channel managed by this controller
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,mpc8321-ucc-qmc-hdlc
+ - const: fsl,qe-ucc-qmc-hdlc
+ - const: fsl,qmc-hdlc
+
+ reg:
+ minimum: 0
+ maximum: 63
+ description:
+ The channel number
+
+ fsl,operational-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [transparent, hdlc]
+ default: transparent
+ description: |
+ The channel operational mode
+ - hdlc: The channel handles HDLC frames
+ - transparent: The channel handles raw data without any processing
+
+ fsl,reverse-data:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ The bit order as seen on the channels is reversed,
+ transmitting/receiving the MSB of each octet first.
+ This flag is used only in 'transparent' mode.
+
+ fsl,tx-ts-mask:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ Channel assigned Tx time-slots within the Tx time-slots routed by the
+ TSA to this cell.
+
+ fsl,rx-ts-mask:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ Channel assigned Rx time-slots within the Rx time-slots routed by the
+ TSA to this cell.
+
+ fsl,framer:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the framer node. The framer is in charge of an E1/T1 line
+ interface connected to the TDM bus. It can be used to get the E1/T1 line
+ status such as link up/down.
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: fsl,qmc-hdlc
+ then:
+ properties:
+ fsl,framer: false
+
+ required:
+ - reg
+ - fsl,tx-ts-mask
+ - fsl,rx-ts-mask
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - fsl,tsa-serial
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qe-fsl,tsa.h>
+
+ qmc@a60 {
+ compatible = "fsl,mpc8321-ucc-qmc", "fsl,qe-ucc-qmc";
+ reg = <0x3200 0x200>,
+ <0x10000 0x1000>;
+ reg-names = "ucc_regs", "dpram";
+ interrupts = <35>;
+ interrupt-parent = <&qeic>;
+ fsl,soft-qmc = "fsl_qe_ucode_qmc_8321_11.bin";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fsl,tsa-serial = <&tsa FSL_QE_TSA_UCC4>;
+
+ channel@16 {
+ /* Ch16 : First 4 even TS from all routed from TSA */
+ reg = <16>;
+ fsl,operational-mode = "transparent";
+ fsl,reverse-data;
+ fsl,tx-ts-mask = <0x00000000 0x000000aa>;
+ fsl,rx-ts-mask = <0x00000000 0x000000aa>;
+ };
+
+ channel@17 {
+ /* Ch17 : First 4 odd TS from all routed from TSA */
+ reg = <17>;
+ fsl,operational-mode = "transparent";
+ fsl,reverse-data;
+ fsl,tx-ts-mask = <0x00000000 0x00000055>;
+ fsl,rx-ts-mask = <0x00000000 0x00000055>;
+ };
+
+ channel@19 {
+ /* Ch19 : 8 TS (TS 8..15) from all routed from TSA */
+ compatible = "fsl,mpc8321-ucc-qmc-hdlc",
+ "fsl,qe-ucc-qmc-hdlc",
+ "fsl,qmc-hdlc";
+ reg = <19>;
+ fsl,operational-mode = "hdlc";
+ fsl,tx-ts-mask = <0x00000000 0x0000ff00>;
+ fsl,rx-ts-mask = <0x00000000 0x0000ff00>;
+ fsl,framer = <&framer>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml
new file mode 100644
index 000000000000..89cdf5e1d0a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale QUICC Engine module (QE)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ This represents qe module that is installed on PowerQUICC II Pro.
+
+ NOTE: This is an interim binding; it should be updated to fit
+ in with the CPM binding later in this document.
+
+ Basically, it is a bus of devices, that could act more or less
+ as a complete entity (UCC, USB etc ). All of them should be siblings on
+ the "root" qe node, using the common properties from there.
+ The description below applies to the qe of MPC8360 and
+ more nodes and properties would be extended in the future.
+
+properties:
+ compatible:
+ items:
+ - const: fsl,qe
+ - const: simple-bus
+
+ reg:
+ maxItems: 1
+
+ ranges:
+ maxItems: 1
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [QE, CPM, CPM2]
+
+ bus-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: the clock frequency for QUICC Engine.
+
+ fsl,qe-num-riscs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: define how many RISC engines the QE has.
+
+ fsl,qe-snums:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ maxItems: 28
+ description:
+ defining the array of serial number (SNUM) values for the virtual
+ threads.
+
+ fsl,firmware-phandle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ required only if there is no fsl,qe-firmware child node
+
+ Points to a firmware node (see "QE Firmware Node" below)
+ that contains the firmware that should be uploaded for this QE.
+ The compatible property for the firmware node should say,
+ "fsl,qe-firmware".
+
+ brg-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ the internal clock source frequency for baud-rate
+ generators in Hz.
+
+ fsl,qe-num-snums:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: |
+ define how many serial number(SNUM) the QE can use
+ for the threads. Use fsl,qe-snums instead to not only specify the
+ number of snums, but also their values.
+
+patternProperties:
+ '^muram@[a-f0-9]+$':
+ $ref: fsl,qe-muram.yaml
+
+ '^interrupt-controller@[a-f0-9]+$':
+ $ref: fsl,qe-ic.yaml
+
+ '^si@[a-f0-9]+$':
+ $ref: fsl,qe-si.yaml
+
+ '^siram@[a-f0-9]+$':
+ $ref: fsl,qe-siram.yaml
+
+required:
+ - compatible
+ - reg
+ - bus-frequency
+
+allOf:
+ - $ref: /schemas/simple-bus.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ qe-bus@e0100000 {
+ compatible = "fsl,qe", "simple-bus";
+ reg = <0xe0100000 0x480>;
+ ranges = <0 0xe0100000 0x00100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ brg-frequency = <0>;
+ bus-frequency = <0x179a7b00>;
+ fsl,qe-snums = /bits/ 8 <
+ 0x04 0x05 0x0c 0x0d 0x14 0x15 0x1c 0x1d
+ 0x24 0x25 0x2c 0x2d 0x34 0x35 0x88 0x89
+ 0x98 0x99 0xa8 0xa9 0xb8 0xb9 0xc8 0xc9
+ 0xd8 0xd9 0xe8 0xe9>;
+
+ interrupt-controller@80 {
+ compatible = "fsl,qe-ic";
+ reg = <0x80 0x80>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ interrupts = <95 2 0 0 94 2 0 0>;
+ };
+
+ si@700 {
+ compatible = "fsl,t1040-qe-si";
+ reg = <0x700 0x80>;
+ };
+
+ siram@1000 {
+ compatible = "fsl,t1040-qe-siram";
+ reg = <0x1000 0x800>;
+ };
+
+ muram@10000 {
+ compatible = "fsl,qe-muram", "fsl,cpm-muram";
+ ranges = <0 0x00010000 0x0000c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ data-only@0{
+ compatible = "fsl,qe-muram-data",
+ "fsl,cpm-muram-data";
+ reg = <0 0xc000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,ucc-hdlc.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,ucc-hdlc.yaml
new file mode 100644
index 000000000000..64ffbf75dd9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,ucc-hdlc.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,ucc-hdlc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: High-Level Data Link Control(HDLC)
+
+description: HDLC part in Universal communication controllers (UCCs)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,ucc-hdlc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ rx-clock-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - pattern: "^brg([0-9]|1[0-6])$"
+ - pattern: "^clk([0-9]|1[0-9]|2[0-4])$"
+
+ tx-clock-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ oneOf:
+ - pattern: "^brg([0-9]|1[0-6])$"
+ - pattern: "^clk([0-9]|1[0-9]|2[0-4])$"
+
+ fsl,tdm-interface:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Specify that hdlc is based on tdm-interface
+
+ fsl,rx-sync-clock:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: rx-sync
+ enum:
+ - none
+ - rsync_pin
+ - brg9
+ - brg10
+ - brg11
+ - brg13
+ - brg14
+ - brg15
+
+ fsl,tx-sync-clock:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: tx-sync
+ enum:
+ - none
+ - tsync_pin
+ - brg9
+ - brg10
+ - brg11
+ - brg13
+ - brg14
+ - brg15
+
+ fsl,tdm-framer-type:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: required for tdm interface
+ enum: [e1, t1]
+
+ fsl,tdm-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: number of TDM ID
+
+ fsl,tx-timeslot-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ required for tdm interface.
+ time slot mask for TDM operation. Indicates which time
+ slots used for transmitting and receiving.
+
+ fsl,rx-timeslot-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ required for tdm interface.
+ time slot mask for TDM operation. Indicates which time
+ slots used for transmitting and receiving.
+
+ fsl,siram-entry-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ required for tdm interface
+ Must be 0,2,4...64. the number of TDM entry.
+
+ fsl,tdm-internal-loopback:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ optional for tdm interface
+ Internal loopback connecting on TDM layer.
+
+ fsl,hmask:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description: |
+ HDLC address recognition. Set to zero to disable
+ address filtering of packets:
+ fsl,hmask = /bits/ 16 <0x0000>;
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ communication@2000 {
+ compatible = "fsl,ucc-hdlc";
+ reg = <0x2000 0x200>;
+ rx-clock-name = "clk8";
+ tx-clock-name = "clk9";
+ fsl,rx-sync-clock = "rsync_pin";
+ fsl,tx-sync-clock = "tsync_pin";
+ fsl,tx-timeslot-mask = <0xfffffffe>;
+ fsl,rx-timeslot-mask = <0xfffffffe>;
+ fsl,tdm-framer-type = "e1";
+ fsl,tdm-id = <0>;
+ fsl,siram-entry-id = <0>;
+ fsl,tdm-interface;
+ };
+
+ - |
+ communication@2000 {
+ compatible = "fsl,ucc-hdlc";
+ reg = <0x2000 0x200>;
+ rx-clock-name = "brg1";
+ tx-clock-name = "brg1";
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
deleted file mode 100644
index 6d2dd8a31482..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
+++ /dev/null
@@ -1,130 +0,0 @@
-* Network
-
-Currently defined compatibles:
-- fsl,cpm1-scc-enet
-- fsl,cpm2-scc-enet
-- fsl,cpm1-fec-enet
-- fsl,cpm2-fcc-enet (third resource is GFEMR)
-- fsl,qe-enet
-
-Example:
-
- ethernet@11300 {
- compatible = "fsl,mpc8272-fcc-enet",
- "fsl,cpm2-fcc-enet";
- reg = <11300 20 8400 100 11390 1>;
- local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <20 8>;
- interrupt-parent = <&PIC>;
- phy-handle = <&PHY0>;
- fsl,cpm-command = <12000300>;
- };
-
-* MDIO
-
-Currently defined compatibles:
-fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-fsl,cpm2-mdio-bitbang (reg is port C registers)
-
-Properties for fsl,cpm2-mdio-bitbang:
-fsl,mdio-pin : pin of port C controlling mdio data
-fsl,mdc-pin : pin of port C controlling mdio clock
-
-Example:
- mdio@10d40 {
- compatible = "fsl,mpc8272ads-mdio-bitbang",
- "fsl,mpc8272-mdio-bitbang",
- "fsl,cpm2-mdio-bitbang";
- reg = <10d40 14>;
- #address-cells = <1>;
- #size-cells = <0>;
- fsl,mdio-pin = <12>;
- fsl,mdc-pin = <13>;
- };
-
-* HDLC
-
-Currently defined compatibles:
-- fsl,ucc-hdlc
-
-Properties for fsl,ucc-hdlc:
-- rx-clock-name
-- tx-clock-name
- Usage: required
- Value type: <string>
- Definition : Must be "brg1"-"brg16" for internal clock source,
- Must be "clk1"-"clk24" for external clock source.
-
-- fsl,tdm-interface
- Usage: optional
- Value type: <empty>
- Definition : Specify that hdlc is based on tdm-interface
-
-The property below is dependent on fsl,tdm-interface:
-- fsl,rx-sync-clock
- Usage: required
- Value type: <string>
- Definition : Must be "none", "rsync_pin", "brg9-11" and "brg13-15".
-
-- fsl,tx-sync-clock
- Usage: required
- Value type: <string>
- Definition : Must be "none", "tsync_pin", "brg9-11" and "brg13-15".
-
-- fsl,tdm-framer-type
- Usage: required for tdm interface
- Value type: <string>
- Definition : "e1" or "t1".Now e1 and t1 are used, other framer types
- are not supported.
-
-- fsl,tdm-id
- Usage: required for tdm interface
- Value type: <u32>
- Definition : number of TDM ID
-
-- fsl,tx-timeslot-mask
-- fsl,rx-timeslot-mask
- Usage: required for tdm interface
- Value type: <u32>
- Definition : time slot mask for TDM operation. Indicates which time
- slots used for transmitting and receiving.
-
-- fsl,siram-entry-id
- Usage: required for tdm interface
- Value type: <u32>
- Definition : Must be 0,2,4...64. the number of TDM entry.
-
-- fsl,tdm-internal-loopback
- usage: optional for tdm interface
- value type: <empty>
- Definition : Internal loopback connecting on TDM layer.
-- fsl,hmask
- usage: optional
- Value type: <u16>
- Definition: HDLC address recognition. Set to zero to disable
- address filtering of packets:
- fsl,hmask = /bits/ 16 <0x0000>;
-
-Example for tdm interface:
-
- ucc@2000 {
- compatible = "fsl,ucc-hdlc";
- rx-clock-name = "clk8";
- tx-clock-name = "clk9";
- fsl,rx-sync-clock = "rsync_pin";
- fsl,tx-sync-clock = "tsync_pin";
- fsl,tx-timeslot-mask = <0xfffffffe>;
- fsl,rx-timeslot-mask = <0xfffffffe>;
- fsl,tdm-framer-type = "e1";
- fsl,tdm-id = <0>;
- fsl,siram-entry-id = <0>;
- fsl,tdm-interface;
- };
-
-Example for hdlc without tdm interface:
-
- ucc@2000 {
- compatible = "fsl,ucc-hdlc";
- rx-clock-name = "brg1";
- tx-clock-name = "brg1";
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
deleted file mode 100644
index 05ec2a838c54..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
+++ /dev/null
@@ -1,178 +0,0 @@
-* Freescale QUICC Engine module (QE)
-This represents qe module that is installed on PowerQUICC II Pro.
-
-NOTE: This is an interim binding; it should be updated to fit
-in with the CPM binding later in this document.
-
-Basically, it is a bus of devices, that could act more or less
-as a complete entity (UCC, USB etc ). All of them should be siblings on
-the "root" qe node, using the common properties from there.
-The description below applies to the qe of MPC8360 and
-more nodes and properties would be extended in the future.
-
-i) Root QE device
-
-Required properties:
-- compatible : should be "fsl,qe";
-- model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
-- reg : offset and length of the device registers.
-- bus-frequency : the clock frequency for QUICC Engine.
-- fsl,qe-num-riscs: define how many RISC engines the QE has.
-- fsl,qe-snums: This property has to be specified as '/bits/ 8' value,
- defining the array of serial number (SNUM) values for the virtual
- threads.
-
-Optional properties:
-- fsl,firmware-phandle:
- Usage: required only if there is no fsl,qe-firmware child node
- Value type: <phandle>
- Definition: Points to a firmware node (see "QE Firmware Node" below)
- that contains the firmware that should be uploaded for this QE.
- The compatible property for the firmware node should say,
- "fsl,qe-firmware".
-
-Recommended properties
-- brg-frequency : the internal clock source frequency for baud-rate
- generators in Hz.
-
-Deprecated properties
-- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
- for the threads. Use fsl,qe-snums instead to not only specify the
- number of snums, but also their values.
-
-Example:
- qe@e0100000 {
- #address-cells = <1>;
- #size-cells = <1>;
- #interrupt-cells = <2>;
- compatible = "fsl,qe";
- ranges = <0 e0100000 00100000>;
- reg = <e0100000 480>;
- brg-frequency = <0>;
- bus-frequency = <179A7B00>;
- fsl,qe-snums = /bits/ 8 <
- 0x04 0x05 0x0C 0x0D 0x14 0x15 0x1C 0x1D
- 0x24 0x25 0x2C 0x2D 0x34 0x35 0x88 0x89
- 0x98 0x99 0xA8 0xA9 0xB8 0xB9 0xC8 0xC9
- 0xD8 0xD9 0xE8 0xE9>;
- }
-
-* Multi-User RAM (MURAM)
-
-Required properties:
-- compatible : should be "fsl,qe-muram", "fsl,cpm-muram".
-- mode : the could be "host" or "slave".
-- ranges : Should be defined as specified in 1) to describe the
- translation of MURAM addresses.
-- data-only : sub-node which defines the address area under MURAM
- bus that can be allocated as data/parameter
-
-Example:
-
- muram@10000 {
- compatible = "fsl,qe-muram", "fsl,cpm-muram";
- ranges = <0 00010000 0000c000>;
-
- data-only@0{
- compatible = "fsl,qe-muram-data",
- "fsl,cpm-muram-data";
- reg = <0 c000>;
- };
- };
-
-* Interrupt Controller (IC)
-
-Required properties:
-- compatible : should be "fsl,qe-ic".
-- reg : Address range of IC register set.
-- interrupts : interrupts generated by the device.
-- interrupt-controller : this device is a interrupt controller.
-
-Example:
-
- qeic: interrupt-controller@80 {
- interrupt-controller;
- compatible = "fsl,qe-ic";
- #address-cells = <0>;
- #interrupt-cells = <1>;
- reg = <0x80 0x80>;
- interrupts = <95 2 0 0 94 2 0 0>;
- };
-
-* Serial Interface Block (SI)
-
-The SI manages the routing of eight TDM lines to the QE block serial drivers
-, the MCC and the UCCs, for receive and transmit.
-
-Required properties:
-- compatible : must be "fsl,<chip>-qe-si". For t1040, must contain
- "fsl,t1040-qe-si".
-- reg : Address range of SI register set.
-
-Example:
-
- si1: si@700 {
- compatible = "fsl,t1040-qe-si";
- reg = <0x700 0x80>;
- };
-
-* Serial Interface Block RAM(SIRAM)
-
-store the routing entries of SI
-
-Required properties:
-- compatible : should be "fsl,<chip>-qe-siram". For t1040, must contain
- "fsl,t1040-qe-siram".
-- reg : Address range of SI RAM.
-
-Example:
-
- siram1: siram@1000 {
- compatible = "fsl,t1040-qe-siram";
- reg = <0x1000 0x800>;
- };
-
-* QE Firmware Node
-
-This node defines a firmware binary that is embedded in the device tree, for
-the purpose of passing the firmware from bootloader to the kernel, or from
-the hypervisor to the guest.
-
-The firmware node itself contains the firmware binary contents, a compatible
-property, and any firmware-specific properties. The node should be placed
-inside a QE node that needs it. Doing so eliminates the need for a
-fsl,firmware-phandle property. Other QE nodes that need the same firmware
-should define an fsl,firmware-phandle property that points to the firmware node
-in the first QE node.
-
-The fsl,firmware property can be specified in the DTS (possibly using incbin)
-or can be inserted by the boot loader at boot time.
-
-Required properties:
- - compatible
- Usage: required
- Value type: <string>
- Definition: A standard property. Specify a string that indicates what
- kind of firmware it is. For QE, this should be "fsl,qe-firmware".
-
- - fsl,firmware
- Usage: required
- Value type: <prop-encoded-array>, encoded as an array of bytes
- Definition: A standard property. This property contains the firmware
- binary "blob".
-
-Example:
- qe1@e0080000 {
- compatible = "fsl,qe";
- qe_firmware:qe-firmware {
- compatible = "fsl,qe-firmware";
- fsl,firmware = [0x70 0xcd 0x00 0x00 0x01 0x46 0x45 ...];
- };
- ...
- };
-
- qe2@e0090000 {
- compatible = "fsl,qe";
- fsl,firmware-phandle = <&qe_firmware>;
- ...
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,bman-portal.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,bman-portal.yaml
new file mode 100644
index 000000000000..8dce75bebff9
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,bman-portal.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,bman-portal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QorIQ DPAA Queue Manager Portals
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ QorIQ DPAA Buffer Manager Portal
+
+ Portals are memory mapped interfaces to BMan that allow low-latency, lock-less
+ interaction by software running on processor cores, accelerators and network
+ interfaces with the BMan
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,bman-portal
+ - items:
+ - enum:
+ - fsl,bman-portal-1.0.0
+ - fsl,ls1043a-bmap-portal
+ - fsl,ls1046a-bmap-portal
+ - const: fsl,bman-portal
+ reg:
+ items:
+ - description: the cache-enabled region of the portal
+ - description: the cache-inhibited region of the portal
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ bman-portal@0 {
+ compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
+ reg = <0x0 0x4000>, <0x100000 0x1000>;
+ interrupts = <105 IRQ_TYPE_EDGE_FALLING 0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,bman.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,bman.yaml
new file mode 100644
index 000000000000..e6f468264b8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,bman.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,bman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QorIQ DPAA Buffer Manager
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
+ BMan supports hardware allocation and deallocation of buffers belonging to
+ pools originally created by software with configurable depletion thresholds.
+ This binding covers the CCSR space programming model
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,bman
+ - items:
+ - enum:
+ - fsl,ls1043a-bman
+ - fsl,ls1046a-bman
+ - const: fsl,bman
+
+ reg:
+ items:
+ - description: |
+ Registers region within the CCSR address space
+
+ The BMan revision information is located in the BMAN_IP_REV_1/2
+ registers which are located at offsets 0xbf8 and 0xbfc
+
+ interrupts:
+ items:
+ - description: The error interrupt
+
+ memory-region:
+ minItems: 1
+ maxItems: 2
+ description:
+ List of phandles referencing the BMan private memory
+ nodes (described below). The bman-fqd node must be
+ first followed by bman-pfdr node. Only used on ARM
+
+ Devices connected to a BMan instance via Direct Connect Portals (DCP) must link
+ to the respective BMan instance
+
+ fsl,bman-portals:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: ref fsl,bman-port.yaml
+
+ fsl,liodn:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ See pamu.txt, PAMU property used for static LIODN assignment
+
+ fsl,iommu-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ See pamu.txt, PAMU property used for dynamic LIODN assignment
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ bman@31a000 {
+ compatible = "fsl,bman";
+ reg = <0x31a000 0x1000>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING 1 2>;
+ fsl,liodn = <0x17>;
+ fsl,bman-portals = <&bportals>;
+ memory-region = <&bman_fbpr>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,imx23-digctl.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,imx23-digctl.yaml
new file mode 100644
index 000000000000..3de135a70579
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,imx23-digctl.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,imx23-digctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale mxs digctrl for i.MX23/i.MX28
+
+description: |
+ The digital control block provides overall control of various items within
+ the top digital block of the chip, including:
+ - Default first-level page table (DFLPT) controls
+ - HCLK performance counter
+ - Free-running microseconds counter
+ - Entropy control
+ - BIST controls for ARM Core and On-Chip RAM
+ - Chip Revision register
+ - USB loop back congtrol
+ - Other miscellaneous controls
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx28-digctl
+ - const: fsl,imx23-digctl
+ - const: fsl,imx23-digctl
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ digctl@8001c000 {
+ compatible = "fsl,imx28-digctl", "fsl,imx23-digctl";
+ reg = <0x8001c000 0x2000>;
+ interrupts = <89>;
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
index 397f75909b20..3fb0534ea597 100644
--- a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
@@ -8,7 +8,6 @@ title: Freescale Layerscape Device Configuration Unit
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Li Yang <leoyang.li@nxp.com>
description: |
DCFG is the device configuration unit, that provides general purpose
@@ -51,7 +50,7 @@ properties:
ranges: true
patternProperties:
- "^clock-controller@[0-9a-z]+$":
+ "^clock-controller@[0-9a-f]+$":
$ref: /schemas/clock/fsl,flexspi-clock.yaml#
required:
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
index 8d088b5fe823..2958ef45b3e9 100644
--- a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
@@ -8,7 +8,6 @@ title: Freescale Layerscape Supplemental Configuration Unit
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Li Yang <leoyang.li@nxp.com>
description: |
SCFG is the supplemental configuration unit, that provides SoC specific
@@ -24,6 +23,9 @@ properties:
- fsl,ls1028a-scfg
- fsl,ls1043a-scfg
- fsl,ls1046a-scfg
+ - fsl,ls1088a-isc
+ - fsl,ls2080a-isc
+ - fsl,lx2160a-isc
- const: syscon
reg:
@@ -41,7 +43,7 @@ properties:
ranges: true
patternProperties:
- "^interrupt-controller@[a-z0-9]+$":
+ "^interrupt-controller@[a-f0-9]+$":
$ref: /schemas/interrupt-controller/fsl,ls-extirq.yaml#
required:
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,ls1028a-reset.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,ls1028a-reset.yaml
new file mode 100644
index 000000000000..b43df10c5ef4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,ls1028a-reset.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,ls1028a-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape Reset Registers Module
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ Reset Module includes chip reset, service processor control and Reset Control
+ Word (RCW) status.
+
+properties:
+ $nodename:
+ pattern: "^syscon@[0-9a-f]+$"
+
+ compatible:
+ items:
+ - enum:
+ - fsl,ls1028a-reset
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ little-endian: true
+
+ reboot:
+ $ref: /schemas/power/reset/syscon-reboot.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reboot
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@1e60000 {
+ compatible = "fsl,ls1028a-reset", "syscon", "simple-mfd";
+ reg = <0x1e60000 0x10000>;
+ little-endian;
+
+ reboot {
+ compatible = "syscon-reboot";
+ offset = <0>;
+ mask = <0x02>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,qman-fqd.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,qman-fqd.yaml
new file mode 100644
index 000000000000..a975bce59975
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,qman-fqd.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,qman-fqd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QMan Private Memory Nodes
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ QMan requires two contiguous range of physical memory used for the backing store
+ for QMan Frame Queue Descriptor (FQD) and Packed Frame Descriptor Record (PFDR).
+ This memory is reserved/allocated as a node under the /reserved-memory node.
+
+ BMan requires a contiguous range of physical memory used for the backing store
+ for BMan Free Buffer Proxy Records (FBPR). This memory is reserved/allocated as
+ a node under the /reserved-memory node.
+
+ The QMan FQD memory node must be named "qman-fqd"
+ The QMan PFDR memory node must be named "qman-pfdr"
+ The BMan FBPR memory node must be named "bman-fbpr"
+
+ The following constraints are relevant to the FQD and PFDR private memory:
+ - The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to
+ 1 GiB
+ - The alignment must be a muliptle of the memory size
+
+ The size of the FQD and PFDP must be chosen by observing the hardware features
+ configured via the Reset Configuration Word (RCW) and that are relevant to a
+ specific board (e.g. number of MAC(s) pinned-out, number of offline/host command
+ FMan ports, etc.). The size configured in the DT must reflect the hardware
+ capabilities and not the specific needs of an application
+
+ For additional details about reserved memory regions see
+ reserved-memory/reserved-memory.yaml in dtschema project.
+
+properties:
+ $nodename:
+ pattern: '^(qman-fqd|qman-pfdr|bman-fbpr)+$'
+
+ compatible:
+ enum:
+ - fsl,qman-fqd
+ - fsl,qman-pfdr
+ - fsl,bman-fbpr
+
+required:
+ - compatible
+
+allOf:
+ - $ref: /schemas/reserved-memory/reserved-memory.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ qman-fqd {
+ compatible = "fsl,qman-fqd";
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ no-map;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,qman-portal.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,qman-portal.yaml
new file mode 100644
index 000000000000..e459fec02ba8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,qman-portal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,qman-portal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QorIQ DPAA Queue Manager Portals
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ Portals are memory mapped interfaces to QMan that allow low-latency, lock-less
+ interaction by software running on processor cores, accelerators and network
+ interfaces with the QMan
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,qman-portal
+ - items:
+ - enum:
+ - fsl,ls1043-qman-portal
+ - fsl,ls1046-qman-portal
+ - fsl,qman-portal-1.2.0
+ - const: fsl,qman-portal
+
+ reg:
+ items:
+ - description: the cache-enabled region of the portal
+ - description: the cache-inhibited region of the portal
+
+ interrupts:
+ maxItems: 1
+
+ fsl,liodn:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ description: See pamu.txt. Two LIODN(s). DQRR LIODN (DLIODN) and Frame LIODN
+ (FLIODN)
+
+ fsl,iommu-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: See pamu.txt.
+
+ fsl,qman-channel-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: qman channel id.
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The hardware index of the channel. This can also be
+ determined by dividing any of the channel's 8 work queue
+ IDs by 8
+
+ In addition to these properties the qman-portals should have sub-nodes to
+ represent the HW devices/portals that are connected to the software portal
+ described here
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+patternProperties:
+ '^(fman0|fman1|pme|crypto)+$':
+ type: object
+ properties:
+ fsl,liodn:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: See pamu.txt, PAMU property used for static LIODN assignment
+
+ fsl,iommu-parent:
+ description: See pamu.txt, PAMU property used for dynamic LIODN assignment
+
+ dev-handle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle to the particular hardware device that this
+ portal is connected to.
+
+ additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ qman-portal@0 {
+ compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
+ reg = <0 0x4000>, <0x100000 0x1000>;
+ interrupts = <104 IRQ_TYPE_EDGE_FALLING 0 0>;
+ fsl,liodn = <1 2>;
+ fsl,qman-channel-id = <0>;
+
+ fman0 {
+ fsl,liodn = <0x21>;
+ dev-handle = <&fman0>;
+ };
+
+ fman1 {
+ fsl,liodn = <0xa1>;
+ dev-handle = <&fman1>;
+ };
+
+ crypto {
+ fsl,liodn = <0x41 0x66>;
+ dev-handle = <&crypto>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,qman.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,qman.yaml
new file mode 100644
index 000000000000..501f06e190c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,qman.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,qman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QorIQ DPAA Queue Manager
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA). QMan
+ supports queuing and QoS scheduling of frames to CPUs, network interfaces and
+ DPAA logic modules, maintains packet ordering within flows. Besides providing
+ flow-level queuing, is also responsible for congestion management functions such
+ as RED/WRED, congestion notifications and tail discards. This binding covers the
+ CCSR space programming model
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,qman
+ - items:
+ - enum:
+ - fsl,ls1043a-qman
+ - fsl,ls1046a-qman
+ - const: fsl,qman
+ reg:
+ items:
+ - description: |
+ Registers region within the CCSR address space
+
+ The QMan revision information is located in the QMAN_IP_REV_1/2
+ registers which are located at offsets 0xbf8 and 0xbfc
+
+ interrupts:
+ items:
+ - description: The error interrupt
+
+ fsl,qman-portals:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: ref fsl,qman-port.yaml
+
+ fsl,liodn:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ See pamu.txt, PAMU property used for static LIODN assignment
+
+ fsl,iommu-parent:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ See pamu.txt, PAMU property used for dynamic LIODN assignment
+
+ clocks:
+ maxItems: 1
+ description:
+ Reference input clock. Its frequency is half of the platform clock
+
+ memory-region:
+ maxItems: 2
+ description:
+ List of phandles referencing the QMan private memory nodes (described
+ below). The qman-fqd node must be first followed by qman-pfdr node.
+ Only used on ARM Devices connected to a QMan instance via Direct Connect
+ Portals (DCP) must link to the respective QMan instance.
+
+ fsl,qman:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ List of phandle and DCP index pairs, to the QMan instance
+ to which this device is connected via the DCP
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ qman: qman@318000 {
+ compatible = "fsl,qman";
+ reg = <0x318000 0x1000>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING 1 3>;
+ fsl,liodn = <0x16>;
+ fsl,qman-portals = <&qportals>;
+ memory-region = <&qman_fqd &qman_pfdr>;
+ clocks = <&platform_pll 1>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,rcpm.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,rcpm.yaml
new file mode 100644
index 000000000000..03d71ab930d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,rcpm.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,rcpm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Run Control and Power Management
+
+description:
+ The RCPM performs all device-level tasks associated with device run control
+ and power management.
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,p2041-rcpm
+ - fsl,p3041-rcpm
+ - fsl,p4080-rcpm
+ - fsl,p5020-rcpm
+ - fsl,p5040-rcpm
+ - const: fsl,qoriq-rcpm-1.0
+ - items:
+ - enum:
+ - fsl,b4420-rcpm
+ - fsl,b4860-rcpm
+ - fsl,t4240-rcpm
+ - const: fsl,qoriq-rcpm-2.0
+ - items:
+ - enum:
+ - fsl,t1040-rcpm
+ - const: fsl,qoriq-rcpm-2.1
+ - items:
+ - enum:
+ - fsl,ls1012a-rcpm
+ - fsl,ls1021a-rcpm
+ - fsl,ls1028a-rcpm
+ - fsl,ls1043a-rcpm
+ - fsl,ls1046a-rcpm
+ - fsl,ls1088a-rcpm
+ - fsl,ls208xa-rcpm
+ - fsl,lx2160a-rcpm
+ - const: fsl,qoriq-rcpm-2.1+
+
+ reg:
+ maxItems: 1
+
+ "#fsl,rcpm-wakeup-cells":
+ description: |
+ The number of IPPDEXPCR register cells in the
+ fsl,rcpm-wakeup property.
+
+ Freescale RCPM Wakeup Source Device Tree Bindings
+
+ Required fsl,rcpm-wakeup property should be added to a device node if
+ the device can be used as a wakeup source.
+
+ fsl,rcpm-wakeup: Consists of a phandle to the rcpm node and the IPPDEXPCR
+ register cells. The number of IPPDEXPCR register cells is defined in
+ "#fsl,rcpm-wakeup-cells" in the rcpm node. The first register cell is
+ the bit mask that should be set in IPPDEXPCR0, and the second register
+ cell is for IPPDEXPCR1, and so on.
+
+ Note: IPPDEXPCR(IP Powerdown Exception Control Register) provides a
+ mechanism for keeping certain blocks awake during STANDBY and MEM, in
+ order to use them as wake-up sources.
+
+ little-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ RCPM register block is Little Endian. Without it RCPM
+ will be Big Endian (default case).
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ global-utilities@e2000 {
+ compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ #fsl,rcpm-wakeup-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,vf610-src.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,vf610-src.yaml
new file mode 100644
index 000000000000..6fb93e8be929
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,vf610-src.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,vf610-src.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale vf610 System Reset Controller (SRC)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ IC reference manual calls it as SRC, but it is not module as reset
+ controller, which used to reset individual device. SRC works as reboot
+ controller, which reboots whole system. It provides a syscon interface to
+ syscon-reboot.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,vf610-src
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ syscon@4006e000 {
+ compatible = "fsl,vf610-src", "syscon";
+ reg = <0x4006e000 0x1000>;
+ interrupts = <96 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
deleted file mode 100644
index 5a34f3ab7bea..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt
+++ /dev/null
@@ -1,134 +0,0 @@
-QorIQ DPAA Queue Manager Portals Device Tree Binding
-
-Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
-
-CONTENTS
-
- - QMan Portal
- - Example
-
-QMan Portal Node
-
-Portals are memory mapped interfaces to QMan that allow low-latency, lock-less
-interaction by software running on processor cores, accelerators and network
-interfaces with the QMan
-
-PROPERTIES
-
-- compatible
- Usage: Required
- Value type: <stringlist>
- Definition: Must include "fsl,qman-portal-<hardware revision>"
- May include "fsl,<SoC>-qman-portal" or "fsl,qman-portal"
-
-- reg
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Two regions. The first is the cache-enabled region of
- the portal. The second is the cache-inhibited region of
- the portal
-
-- interrupts
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Standard property
-
-- fsl,liodn
- Usage: See pamu.txt
- Value type: <prop-encoded-array>
- Definition: Two LIODN(s). DQRR LIODN (DLIODN) and Frame LIODN
- (FLIODN)
-
-- fsl,iommu-parent
- Usage: See pamu.txt
- Value type: <phandle>
- Definition: PAMU property used for dynamic LIODN assignment
-
- For additional details about the PAMU/LIODN binding(s) see pamu.txt
-
-- cell-index
- Usage: Required
- Value type: <u32>
- Definition: The hardware index of the channel. This can also be
- determined by dividing any of the channel's 8 work queue
- IDs by 8
-
-In addition to these properties the qman-portals should have sub-nodes to
-represent the HW devices/portals that are connected to the software portal
-described here
-
-The currently supported sub-nodes are:
- * fman0
- * fman1
- * pme
- * crypto
-
-These subnodes should have the following properties:
-
-- fsl,liodn
- Usage: See pamu.txt
- Value type: <prop-encoded-array>
- Definition: PAMU property used for static LIODN assignment
-
-- fsl,iommu-parent
- Usage: See pamu.txt
- Value type: <phandle>
- Definition: PAMU property used for dynamic LIODN assignment
-
-- dev-handle
- Usage: Required
- Value type: <phandle>
- Definition: The phandle to the particular hardware device that this
- portal is connected to.
-
-EXAMPLE
-
-The example below shows a (P4080) QMan portals container/bus node with two portals
-
- qman-portals@ff4200000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "simple-bus";
- ranges = <0 0xf 0xf4200000 0x200000>;
-
- qman-portal@0 {
- compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
- reg = <0 0x4000>, <0x100000 0x1000>;
- interrupts = <104 2 0 0>;
- fsl,liodn = <1 2>;
- fsl,qman-channel-id = <0>;
-
- fman0 {
- fsl,liodn = <0x21>;
- dev-handle = <&fman0>;
- };
- fman1 {
- fsl,liodn = <0xa1>;
- dev-handle = <&fman1>;
- };
- crypto {
- fsl,liodn = <0x41 0x66>;
- dev-handle = <&crypto>;
- };
- };
- qman-portal@4000 {
- compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
- reg = <0x4000 0x4000>, <0x101000 0x1000>;
- interrupts = <106 2 0 0>;
- fsl,liodn = <3 4>;
- cell-index = <1>;
-
- fman0 {
- fsl,liodn = <0x22>;
- dev-handle = <&fman0>;
- };
- fman1 {
- fsl,liodn = <0xa2>;
- dev-handle = <&fman1>;
- };
- crypto {
- fsl,liodn = <0x42 0x67>;
- dev-handle = <&crypto>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/qman.txt b/Documentation/devicetree/bindings/soc/fsl/qman.txt
deleted file mode 100644
index ee96afd2af72..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/qman.txt
+++ /dev/null
@@ -1,187 +0,0 @@
-QorIQ DPAA Queue Manager Device Tree Binding
-
-Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
-
-CONTENTS
-
- - QMan Node
- - QMan Private Memory Nodes
- - Example
-
-QMan Node
-
-The Queue Manager is part of the Data-Path Acceleration Architecture (DPAA). QMan
-supports queuing and QoS scheduling of frames to CPUs, network interfaces and
-DPAA logic modules, maintains packet ordering within flows. Besides providing
-flow-level queuing, is also responsible for congestion management functions such
-as RED/WRED, congestion notifications and tail discards. This binding covers the
-CCSR space programming model
-
-PROPERTIES
-
-- compatible
- Usage: Required
- Value type: <stringlist>
- Definition: Must include "fsl,qman"
- May include "fsl,<SoC>-qman"
-
-- reg
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Registers region within the CCSR address space
-
-The QMan revision information is located in the QMAN_IP_REV_1/2 registers which
-are located at offsets 0xbf8 and 0xbfc
-
-- interrupts
- Usage: Required
- Value type: <prop-encoded-array>
- Definition: Standard property. The error interrupt
-
-- fsl,qman-portals
- Usage: Required
- Value type: <phandle>
- Definition: Phandle to this QMan instance's portals
-
-- fsl,liodn
- Usage: See pamu.txt
- Value type: <prop-encoded-array>
- Definition: PAMU property used for static LIODN assignment
-
-- fsl,iommu-parent
- Usage: See pamu.txt
- Value type: <phandle>
- Definition: PAMU property used for dynamic LIODN assignment
-
- For additional details about the PAMU/LIODN binding(s) see pamu.txt
-
-- clocks
- Usage: See clock-bindings.txt and qoriq-clock.txt
- Value type: <prop-encoded-array>
- Definition: Reference input clock. Its frequency is half of the
- platform clock
-- memory-regions
- Usage: Required for ARM
- Value type: <phandle array>
- Definition: List of phandles referencing the QMan private memory
- nodes (described below). The qman-fqd node must be
- first followed by qman-pfdr node. Only used on ARM
-
-Devices connected to a QMan instance via Direct Connect Portals (DCP) must link
-to the respective QMan instance
-
-- fsl,qman
- Usage: Required
- Value type: <prop-encoded-array>
- Description: List of phandle and DCP index pairs, to the QMan instance
- to which this device is connected via the DCP
-
-QMan Private Memory Nodes
-
-QMan requires two contiguous range of physical memory used for the backing store
-for QMan Frame Queue Descriptor (FQD) and Packed Frame Descriptor Record (PFDR).
-This memory is reserved/allocated as a node under the /reserved-memory node.
-
-For additional details about reserved memory regions see reserved-memory.txt
-
-The QMan FQD memory node must be named "qman-fqd"
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: PPC platforms: Must include "fsl,qman-fqd"
- ARM platforms: Must include "shared-dma-pool"
- as well as the "no-map" property
-
-The QMan PFDR memory node must be named "qman-pfdr"
-
-PROPERTIES
-
-- compatible
- Usage: required
- Value type: <stringlist>
- Definition: PPC platforms: Must include "fsl,qman-pfdr"
- ARM platforms: Must include "shared-dma-pool"
- as well as the "no-map" property
-
-The following constraints are relevant to the FQD and PFDR private memory:
- - The size must be 2^(size + 1), with size = 11..29. That is 4 KiB to
- 1 GiB
- - The alignment must be a muliptle of the memory size
-
-The size of the FQD and PFDP must be chosen by observing the hardware features
-configured via the Reset Configuration Word (RCW) and that are relevant to a
-specific board (e.g. number of MAC(s) pinned-out, number of offline/host command
-FMan ports, etc.). The size configured in the DT must reflect the hardware
-capabilities and not the specific needs of an application
-
-For additional details about reserved memory regions see reserved-memory.txt
-
-EXAMPLE
-
-The example below shows a QMan FQD and a PFDR dynamic allocation memory nodes
-
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- qman_fqd: qman-fqd {
- compatible = "shared-dma-pool";
- size = <0 0x400000>;
- alignment = <0 0x400000>;
- no-map;
- };
- qman_pfdr: qman-pfdr {
- compatible = "shared-dma-pool";
- size = <0 0x2000000>;
- alignment = <0 0x2000000>;
- no-map;
- };
- };
-
-The example below shows a (P4080) QMan CCSR-space node
-
- qportals: qman-portals@ff4200000 {
- ...
- };
-
- clockgen: global-utilities@e1000 {
- ...
- sysclk: sysclk {
- ...
- };
- ...
- platform_pll: platform-pll@c00 {
- #clock-cells = <1>;
- reg = <0xc00 0x4>;
- compatible = "fsl,qoriq-platform-pll-1.0";
- clocks = <&sysclk>;
- clock-output-names = "platform-pll", "platform-pll-div2";
- };
- ...
- };
-
- crypto@300000 {
- ...
- fsl,qman = <&qman, 2>;
- ...
- };
-
- qman: qman@318000 {
- compatible = "fsl,qman";
- reg = <0x318000 0x1000>;
- interrupts = <16 2 1 3>
- fsl,liodn = <0x16>;
- fsl,qman-portals = <&qportals>;
- memory-region = <&qman_fqd &qman_pfdr>;
- clocks = <&platform_pll 1>;
- };
-
- fman@400000 {
- ...
- fsl,qman = <&qman, 0>;
- ...
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
deleted file mode 100644
index 5a33619d881d..000000000000
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-* Run Control and Power Management
--------------------------------------------
-The RCPM performs all device-level tasks associated with device run control
-and power management.
-
-Required properites:
- - reg : Offset and length of the register set of the RCPM block.
- - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
- fsl,rcpm-wakeup property.
- - compatible : Must contain a chip-specific RCPM block compatible string
- and (if applicable) may contain a chassis-version RCPM compatible
- string. Chip-specific strings are of the form "fsl,<chip>-rcpm",
- such as:
- * "fsl,p2041-rcpm"
- * "fsl,p5020-rcpm"
- * "fsl,t4240-rcpm"
-
- Chassis-version strings are of the form "fsl,qoriq-rcpm-<version>",
- such as:
- * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
- * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
- * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
- * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm
-
-All references to "1.0" and "2.0" refer to the QorIQ chassis version to
-which the chip complies.
-Chassis Version Example Chips
---------------- -------------------------------
-1.0 p4080, p5020, p5040, p2041, p3041
-2.0 t4240, b4860, b4420
-2.1 t1040,
-2.1+ ls1021a, ls1012a, ls1043a, ls1046a
-
-Optional properties:
- - little-endian : RCPM register block is Little Endian. Without it RCPM
- will be Big Endian (default case).
-
-Example:
-The RCPM node for T4240:
- rcpm: global-utilities@e2000 {
- compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
- reg = <0xe2000 0x1000>;
- #fsl,rcpm-wakeup-cells = <2>;
- };
-
-* Freescale RCPM Wakeup Source Device Tree Bindings
--------------------------------------------
-Required fsl,rcpm-wakeup property should be added to a device node if the device
-can be used as a wakeup source.
-
- - fsl,rcpm-wakeup: Consists of a phandle to the rcpm node and the IPPDEXPCR
- register cells. The number of IPPDEXPCR register cells is defined in
- "#fsl,rcpm-wakeup-cells" in the rcpm node. The first register cell is
- the bit mask that should be set in IPPDEXPCR0, and the second register
- cell is for IPPDEXPCR1, and so on.
-
- Note: IPPDEXPCR(IP Powerdown Exception Control Register) provides a
- mechanism for keeping certain blocks awake during STANDBY and MEM, in
- order to use them as wake-up sources.
-
-Example:
- lpuart0: serial@2950000 {
- compatible = "fsl,ls1021a-lpuart";
- reg = <0x0 0x2950000 0x0 0x1000>;
- interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sysclk>;
- clock-names = "ipg";
- fsl,rcpm-wakeup = <&rcpm 0x0 0x40000000>;
- };
diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
new file mode 100644
index 000000000000..2be022ca6a7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/google/google,gs101-pmu-intr-gen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Power Management Unit (PMU) Interrupt Generation
+
+description: |
+ PMU interrupt generator for handshaking between PMU through interrupts.
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+properties:
+ compatible:
+ items:
+ - const: google,gs101-pmu-intr-gen
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pmu_intr_gen: syscon@17470000 {
+ compatible = "google,gs101-pmu-intr-gen", "syscon";
+ reg = <0x17470000 0x10000>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/hisilicon/hisilicon,hi3660-usb3-otg-bc.yaml b/Documentation/devicetree/bindings/soc/hisilicon/hisilicon,hi3660-usb3-otg-bc.yaml
new file mode 100644
index 000000000000..5c77c4925d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/hisilicon/hisilicon,hi3660-usb3-otg-bc.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/hisilicon/hisilicon,hi3660-usb3-otg-bc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hisilicon Kirin 960 USB OTG Battery Charging Syscon
+
+maintainers:
+ - Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+
+properties:
+ compatible:
+ items:
+ - const: hisilicon,hi3660-usb3-otg-bc
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ usb-phy:
+ $ref: /schemas/phy/hisilicon,hi3660-usb3.yaml
+ description: USB Phy node
+
+required:
+ - compatible
+ - reg
+ - usb-phy
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@ff200000 {
+ compatible = "hisilicon,hi3660-usb3-otg-bc", "syscon", "simple-mfd";
+ reg = <0xff200000 0x1000>;
+
+ usb-phy {
+ compatible = "hisilicon,hi3660-usb-phy";
+ #phy-cells = <0>;
+ hisilicon,pericrg-syscon = <&crg_ctrl>;
+ hisilicon,pctrl-syscon = <&pctrl>;
+ hisilicon,eye-diagram-param = <0x22466e4>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml
index 80d99861fec5..70a4af650110 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml
@@ -22,6 +22,9 @@ select:
required:
- compatible
+allOf:
+ - $ref: /schemas/simple-bus.yaml#
+
properties:
compatible:
items:
@@ -35,7 +38,7 @@ required:
- compatible
- reg
-additionalProperties: true
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-anatop.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-anatop.yaml
new file mode 100644
index 000000000000..f40c157908aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-anatop.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/imx/fsl,imx-anatop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ANATOP register
+
+maintainers:
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx6sl-anatop
+ - fsl,imx6sll-anatop
+ - fsl,imx6sx-anatop
+ - fsl,imx6ul-anatop
+ - fsl,imx7d-anatop
+ - const: fsl,imx6q-anatop
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - const: fsl,imx6q-anatop
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Temperature sensor event
+ - description: Brown-out event on either of the support regulators
+ - description: Brown-out event on either the core, gpu or soc regulators
+ minItems: 2
+
+ tempmon:
+ type: object
+ unevaluatedProperties: false
+ $ref: /schemas/thermal/imx-thermal.yaml
+
+patternProperties:
+ "regulator-((1p1)|(2p5)|(3p0)|(vdd1p0d)|(vdd1p2)|(vddcore)|(vddpcie)|(vddpu)|(vddsoc))$":
+ type: object
+ unevaluatedProperties: false
+ $ref: /schemas/regulator/anatop-regulator.yaml
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx7d-anatop
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+ else:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6ul-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ anatop: anatop@20c8000 {
+ compatible = "fsl,imx6ul-anatop", "fsl,imx6q-anatop",
+ "syscon", "simple-mfd";
+ reg = <0x020c8000 0x1000>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+
+ reg_3p0: regulator-3p0 {
+ compatible = "fsl,anatop-regulator";
+ regulator-name = "vdd3p0";
+ regulator-min-microvolt = <2625000>;
+ regulator-max-microvolt = <3400000>;
+ anatop-reg-offset = <0x120>;
+ anatop-vol-bit-shift = <8>;
+ anatop-vol-bit-width = <5>;
+ anatop-min-bit-val = <0>;
+ anatop-min-voltage = <2625000>;
+ anatop-max-voltage = <3400000>;
+ anatop-enable-bit = <0>;
+ };
+
+ reg_arm: regulator-vddcore {
+ compatible = "fsl,anatop-regulator";
+ regulator-name = "cpu";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-always-on;
+ anatop-reg-offset = <0x140>;
+ anatop-vol-bit-shift = <0>;
+ anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <24>;
+ anatop-delay-bit-width = <2>;
+ anatop-min-bit-val = <1>;
+ anatop-min-voltage = <725000>;
+ anatop-max-voltage = <1450000>;
+ };
+
+ reg_soc: regulator-vddsoc {
+ compatible = "fsl,anatop-regulator";
+ regulator-name = "vddsoc";
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-always-on;
+ anatop-reg-offset = <0x140>;
+ anatop-vol-bit-shift = <18>;
+ anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <28>;
+ anatop-delay-bit-width = <2>;
+ anatop-min-bit-val = <1>;
+ anatop-min-voltage = <725000>;
+ anatop-max-voltage = <1450000>;
+ };
+
+ tempmon: tempmon {
+ compatible = "fsl,imx6ul-tempmon", "fsl,imx6sx-tempmon";
+ interrupt-parent = <&gpc>;
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,tempmon = <&anatop>;
+ nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
+ nvmem-cell-names = "calib", "temp_grade";
+ clocks = <&clks IMX6UL_CLK_PLL3_USB_OTG>;
+ #thermal-sensor-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
new file mode 100644
index 000000000000..721a67e84c13
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/imx/fsl,imx-iomuxc-gpr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale IOMUX Controller General Purpose Registers
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description:
+ i.MX Processors have an IOMUXC General Purpose Register group for
+ various System Settings
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx6q-iomuxc-gpr
+ - fsl,imx8mq-iomuxc-gpr
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - fsl,imx6sl-iomuxc-gpr
+ - fsl,imx6sll-iomuxc-gpr
+ - fsl,imx6ul-iomuxc-gpr
+ - const: fsl,imx6q-iomuxc-gpr
+ - const: syscon
+ - items:
+ - enum:
+ - fsl,imx6sx-iomuxc-gpr
+ - fsl,imx7d-iomuxc-gpr
+ - const: fsl,imx6q-iomuxc-gpr
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - fsl,imx53-iomuxc-gpr
+ - fsl,imx8mm-iomuxc-gpr
+ - fsl,imx8mn-iomuxc-gpr
+ - fsl,imx8mp-iomuxc-gpr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ mux-controller:
+ type: object
+ $ref: /schemas/mux/reg-mux.yaml
+
+patternProperties:
+ "^ipu[12]_csi[01]_mux$":
+ type: object
+ $ref: /schemas/media/video-mux.yaml
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: fsl,imx6q-iomuxc-gpr
+ then:
+ patternProperties:
+ '^ipu[12]_csi[01]_mux$': false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ # Pinmux controller node
+ - |
+ iomuxc_gpr: syscon@30340000 {
+ compatible = "fsl,imx8mq-iomuxc-gpr", "syscon", "simple-mfd";
+ reg = <0x30340000 0x10000>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x34 0x00000004>; /* MIPI_MUX_SEL */
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml
index ecd86cfb3da4..a02a09d574a2 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml
@@ -70,7 +70,7 @@ examples:
#include <dt-bindings/clock/imx8mm-clock.h>
#include <dt-bindings/power/imx8mm-power.h>
- disp_blk_ctl: blk_ctrl@32e28000 {
+ blk-ctrl@32e28000 {
compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
reg = <0x32e28000 0x100>;
power-domains = <&pgc_dispmix>, <&pgc_dispmix>, <&pgc_dispmix>,
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml
index d71bb20d4907..25109376d7d4 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml
@@ -150,7 +150,7 @@ examples:
#include <dt-bindings/clock/imx8mm-clock.h>
#include <dt-bindings/power/imx8mm-power.h>
- vpu_blk_ctrl: blk-ctrl@38330000 {
+ blk-ctrl@38330000 {
compatible = "fsl,imx8mm-vpu-blk-ctrl", "syscon";
reg = <0x38330000 0x100>;
power-domains = <&pgc_vpumix>, <&pgc_vpu_g1>,
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml
index fbeaac399c50..eeec9965b091 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml
@@ -71,7 +71,7 @@ examples:
#include <dt-bindings/clock/imx8mn-clock.h>
#include <dt-bindings/power/imx8mn-power.h>
- disp_blk_ctl: blk_ctrl@32e28000 {
+ blk-ctrl@32e28000 {
compatible = "fsl,imx8mn-disp-blk-ctrl", "syscon";
reg = <0x32e28000 0x100>;
power-domains = <&pgc_dispmix>, <&pgc_dispmix>,
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml
index 1be4ce2a45e8..bd1cdaa4f54b 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml
@@ -27,8 +27,8 @@ properties:
const: 1
power-domains:
- minItems: 8
- maxItems: 8
+ minItems: 10
+ maxItems: 10
power-domain-names:
items:
@@ -40,10 +40,12 @@ properties:
- const: trng
- const: hdmi-tx
- const: hdmi-tx-phy
+ - const: hdcp
+ - const: hrv
clocks:
- minItems: 4
- maxItems: 4
+ minItems: 5
+ maxItems: 5
clock-names:
items:
@@ -51,6 +53,7 @@ properties:
- const: axi
- const: ref_266m
- const: ref_24m
+ - const: fdcc
interconnects:
maxItems: 3
@@ -82,12 +85,15 @@ examples:
clocks = <&clk IMX8MP_CLK_HDMI_APB>,
<&clk IMX8MP_CLK_HDMI_ROOT>,
<&clk IMX8MP_CLK_HDMI_REF_266M>,
- <&clk IMX8MP_CLK_HDMI_24M>;
- clock-names = "apb", "axi", "ref_266m", "ref_24m";
+ <&clk IMX8MP_CLK_HDMI_24M>,
+ <&clk IMX8MP_CLK_HDMI_FDCC_TST>;
+ clock-names = "apb", "axi", "ref_266m", "ref_24m", "fdcc";
power-domains = <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>,
<&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>,
- <&pgc_hdmimix>, <&pgc_hdmi_phy>;
+ <&pgc_hdmimix>, <&pgc_hdmi_phy>,
+ <&pgc_hdmimix>, <&pgc_hdmimix>;
power-domain-names = "bus", "irqsteer", "lcdif", "pai", "pvi", "trng",
- "hdmi-tx", "hdmi-tx-phy";
+ "hdmi-tx", "hdmi-tx-phy",
+ "hdcp", "hrv";
#power-domain-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml
index c29181a9745b..4214c1ab4971 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml
@@ -39,6 +39,9 @@ properties:
- const: pcie
- const: pcie-phy
+ '#clock-cells':
+ const: 0
+
clocks:
minItems: 2
maxItems: 2
@@ -73,7 +76,7 @@ examples:
#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/power/imx8mp-power.h>
- hsio_blk_ctrl: blk-ctrl@32f10000 {
+ blk-ctrl@32f10000 {
compatible = "fsl,imx8mp-hsio-blk-ctrl", "syscon";
reg = <0x32f10000 0x24>;
clocks = <&clk IMX8MP_CLK_USB_ROOT>,
@@ -85,4 +88,5 @@ examples:
power-domain-names = "bus", "usb", "usb-phy1",
"usb-phy2", "pcie", "pcie-phy";
#power-domain-cells = <1>;
+ #clock-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml
index dadb6108e321..ea9aa876ed13 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml
@@ -23,6 +23,12 @@ properties:
reg:
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
'#power-domain-cells':
const: 1
@@ -78,9 +84,16 @@ properties:
- const: isp1
- const: dwe
+ bridge@5c:
+ type: object
+ $ref: /schemas/display/bridge/fsl,ldb.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
+ - '#address-cells'
+ - '#size-cells'
- '#power-domain-cells'
- power-domains
- power-domain-names
@@ -94,7 +107,7 @@ examples:
#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/power/imx8mp-power.h>
- media_blk_ctl: blk-ctl@32ec0000 {
+ blk-ctrl@32ec0000 {
compatible = "fsl,imx8mp-media-blk-ctrl", "syscon";
reg = <0x32ec0000 0x138>;
power-domains = <&mediamix_pd>, <&mipi_phy1_pd>, <&mipi_phy1_pd>,
@@ -114,5 +127,43 @@ examples:
clock-names = "apb", "axi", "cam1", "cam2", "disp1", "disp2",
"isp", "phy";
#power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bridge@5c {
+ compatible = "fsl,imx8mp-ldb";
+ reg = <0x5c 0x4>, <0x128 0x4>;
+ reg-names = "ldb", "lvds";
+ clocks = <&clk IMX8MP_CLK_MEDIA_LDB>;
+ clock-names = "ldb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ ldb_from_lcdif2: endpoint {
+ remote-endpoint = <&lcdif2_to_ldb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&ldb_to_lvdsx4panel>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ldb_lvds_ch1: endpoint {
+ };
+ };
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml
index 7263ebedf09f..ea5c90c6a1b6 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml
@@ -59,7 +59,7 @@ examples:
#include <dt-bindings/clock/imx8mq-clock.h>
#include <dt-bindings/power/imx8mq-power.h>
- vpu_blk_ctrl: blk-ctrl@38320000 {
+ blk-ctrl@38320000 {
compatible = "fsl,imx8mq-vpu-blk-ctrl";
reg = <0x38320000 0x100>;
power-domains = <&pgc_vpu>, <&pgc_vpu>, <&pgc_vpu>;
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
index 792ebecec22d..34aea58094e5 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
@@ -18,7 +18,9 @@ description:
properties:
compatible:
items:
- - const: fsl,imx93-media-blk-ctrl
+ - enum:
+ - fsl,imx91-media-blk-ctrl
+ - fsl,imx93-media-blk-ctrl
- const: syscon
reg:
@@ -31,21 +33,54 @@ properties:
maxItems: 1
clocks:
+ minItems: 8
maxItems: 10
clock-names:
- items:
- - const: apb
- - const: axi
- - const: nic
- - const: disp
- - const: cam
- - const: pxp
- - const: lcdif
- - const: isi
- - const: csi
- - const: dsi
+ minItems: 8
+ maxItems: 10
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx91-media-blk-ctrl
+ then:
+ properties:
+ clocks:
+ maxItems: 8
+ clock-names:
+ items:
+ - const: apb
+ - const: axi
+ - const: nic
+ - const: disp
+ - const: cam
+ - const: lcdif
+ - const: isi
+ - const: csi
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx93-media-blk-ctrl
+ then:
+ properties:
+ clocks:
+ minItems: 10
+ clock-names:
+ items:
+ - const: apb
+ - const: axi
+ - const: nic
+ - const: disp
+ - const: cam
+ - const: pxp
+ - const: lcdif
+ - const: isi
+ - const: csi
+ - const: dsi
required:
- compatible
- reg
@@ -60,7 +95,7 @@ examples:
#include <dt-bindings/clock/imx93-clock.h>
#include <dt-bindings/power/fsl,imx93-power.h>
- media_blk_ctrl: system-controller@4ac10000 {
+ system-controller@4ac10000 {
compatible = "fsl,imx93-media-blk-ctrl", "syscon";
reg = <0x4ac10000 0x10000>;
power-domains = <&mediamix>;
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml
index c1cc69b51981..9ce8d8b427fa 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml
@@ -38,8 +38,9 @@ properties:
patternProperties:
"power-domain@[0-9a-f]+$":
-
type: object
+ additionalProperties: false
+
properties:
compatible:
items:
diff --git a/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml b/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml
index 8634865015cd..ceb81646fe75 100644
--- a/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml
+++ b/Documentation/devicetree/bindings/soc/intel/intel,hps-copy-engine.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2022, Intel Corporation
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/intel/intel,hps-copy-engine.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/intel/intel,hps-copy-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel HPS Copy Engine
diff --git a/Documentation/devicetree/bindings/soc/intel/intel,lgm-syscon.yaml b/Documentation/devicetree/bindings/soc/intel/intel,lgm-syscon.yaml
new file mode 100644
index 000000000000..6951d55356d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/intel/intel,lgm-syscon.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/intel/intel,lgm-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) Syscon
+
+maintainers:
+ - Chuanhua Lei <lchuanhua@maxlinear.com>
+ - Rahul Tanwar <rtanwar@maxlinear.com>
+
+properties:
+ compatible:
+ items:
+ - const: intel,lgm-syscon
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+patternProperties:
+ "^emmc-phy@[0-9a-f]+$":
+ $ref: /schemas/phy/intel,lgm-emmc-phy.yaml#
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ chiptop@e0200000 {
+ compatible = "intel,lgm-syscon", "syscon";
+ reg = <0xe0200000 0x100>;
+ ranges = <0x0 0xe0200000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ emmc-phy@a8 {
+ compatible = "intel,lgm-emmc-phy";
+ reg = <0x00a8 0x10>;
+ clocks = <&emmc>;
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
index ecae9fa8561b..a64406ca17b5 100644
--- a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 Antmicro <www.antmicro.com>
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LiteX SoC Controller driver
diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
new file mode 100644
index 000000000000..510f6cb0f084
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-pmc.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2 Power Manager controller
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: loongson,ls2k0500-pmc
+ - const: syscon
+ - items:
+ - enum:
+ - loongson,ls2k1000-pmc
+ - loongson,ls2k2000-pmc
+ - const: loongson,ls2k0500-pmc
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ loongson,suspend-address:
+ $ref: /schemas/types.yaml#/definitions/uint64
+ description:
+ The "loongson,suspend-address" is a deep sleep state (Suspend To
+ RAM) firmware entry address which was jumped from kernel and it's
+ value was dependent on specific platform firmware code. In
+ addition, the PM need according to it to indicate that current
+ SoC whether support Suspend To RAM.
+
+ syscon-poweroff:
+ $ref: /schemas/power/reset/syscon-poweroff.yaml#
+ type: object
+ description:
+ Node for power off method
+
+ syscon-reboot:
+ $ref: /schemas/power/reset/syscon-reboot.yaml#
+ type: object
+ description:
+ Node for reboot method
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ power-management@1fe27000 {
+ compatible = "loongson,ls2k1000-pmc", "loongson,ls2k0500-pmc", "syscon";
+ reg = <0x1fe27000 0x58>;
+ interrupt-parent = <&liointc1>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ loongson,suspend-address = <0x0 0x1c000500>;
+
+ syscon-reboot {
+ compatible = "syscon-reboot";
+ offset = <0x30>;
+ mask = <0x1>;
+ };
+
+ syscon-poweroff {
+ compatible = "syscon-poweroff";
+ regmap = <&pmc>;
+ offset = <0x14>;
+ mask = <0x3c00>;
+ value = <0x3c00>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
index d0a4bc3b03e9..99e2caafeadf 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -2,8 +2,8 @@
# # Copyright 2020 MediaTek Inc.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/mediatek/devapc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Device Access Permission Control driver
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml
new file mode 100644
index 000000000000..3b212f26abc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt7986-wo-ccif.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,mt7986-wo-ccif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Wireless Ethernet Dispatch (WED) WO controller interface for MT7986
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+ - Felix Fietkau <nbd@nbd.name>
+
+description:
+ The MediaTek wo-ccif provides a configuration interface for WED WO
+ controller used to perform offload rx packet processing (e.g. 802.11
+ aggregation packet reordering or rx header translation) on MT7986 soc.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt7986-wo-ccif
+ - mediatek,mt7988-wo-ccif
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ syscon@151a5000 {
+ compatible = "mediatek,mt7986-wo-ccif", "syscon";
+ reg = <0 0x151a5000 0 0x1000>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml
new file mode 100644
index 000000000000..4c96d4917967
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mt8183-dvfsrc.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,mt8183-dvfsrc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC)
+
+description:
+ The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a
+ Hardware module used to collect all the requests from both software and the
+ various remote processors embedded into the SoC and decide about a minimum
+ operating voltage and a minimum DRAM frequency to fulfill those requests in
+ an effort to provide the best achievable performance per watt.
+ This hardware IP is capable of transparently performing direct register R/W
+ on all of the DVFSRC-controlled regulators and SoC bandwidth knobs.
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - Henry Chen <henryc.chen@mediatek.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt6893-dvfsrc
+ - mediatek,mt8183-dvfsrc
+ - mediatek,mt8195-dvfsrc
+ - items:
+ - const: mediatek,mt8192-dvfsrc
+ - const: mediatek,mt8195-dvfsrc
+
+ reg:
+ maxItems: 1
+ description: DVFSRC common register address and length.
+
+ regulators:
+ type: object
+ $ref: /schemas/regulator/mediatek,mt6873-dvfsrc-regulator.yaml#
+
+ interconnect:
+ type: object
+ $ref: /schemas/interconnect/mediatek,mt8183-emi.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ system-controller@10012000 {
+ compatible = "mediatek,mt8195-dvfsrc";
+ reg = <0 0x10012000 0 0x1000>;
+
+ regulators {
+ compatible = "mediatek,mt8195-dvfsrc-regulator";
+
+ dvfsrc_vcore: dvfsrc-vcore {
+ regulator-name = "dvfsrc-vcore";
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <750000>;
+ regulator-always-on;
+ };
+
+ dvfsrc_vscp: dvfsrc-vscp {
+ regulator-name = "dvfsrc-vscp";
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <750000>;
+ regulator-always-on;
+ };
+ };
+
+ emi_icc: interconnect {
+ compatible = "mediatek,mt8195-emi";
+ #interconnect-cells = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
index 9241e5fc7cff..5267cfe92572 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
@@ -32,8 +32,12 @@ properties:
- mediatek,mt8183-disp-mutex
- mediatek,mt8186-disp-mutex
- mediatek,mt8186-mdp3-mutex
+ - mediatek,mt8188-disp-mutex
+ - mediatek,mt8188-vpp-mutex
- mediatek,mt8192-disp-mutex
- mediatek,mt8195-disp-mutex
+ - mediatek,mt8195-vpp-mutex
+ - mediatek,mt8365-disp-mutex
reg:
maxItems: 1
@@ -69,12 +73,29 @@ properties:
4 arguments defined in this property. Each GCE subsys id is mapping to
a client defined in the header include/dt-bindings/gce/<chip>-gce.h.
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt2701-disp-mutex
+ - mediatek,mt2712-disp-mutex
+ - mediatek,mt6795-disp-mutex
+ - mediatek,mt8173-disp-mutex
+ - mediatek,mt8186-disp-mutex
+ - mediatek,mt8186-mdp3-mutex
+ - mediatek,mt8192-disp-mutex
+ - mediatek,mt8195-disp-mutex
+ then:
+ required:
+ - clocks
+
required:
- compatible
- reg
- interrupts
- power-domains
- - clocks
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
new file mode 100644
index 000000000000..e7c4a3984c60
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,pwrap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek PMIC Wrapper
+
+maintainers:
+ - Flora Fu <flora.fu@mediatek.com>
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+description:
+ On MediaTek SoCs the PMIC is connected via SPI. The SPI master interface
+ is not directly visible to the CPU, but only through the PMIC wrapper
+ inside the SoC. The communication between the SoC and the PMIC can
+ optionally be encrypted. Also a non standard Dual IO SPI mode can be
+ used to increase speed.
+
+ IP Pairing
+
+ On MT8135 the pins of some SoC internal peripherals can be on the PMIC.
+ The signals of these pins are routed over the SPI bus using the pwrap
+ bridge. In the binding description below the properties needed for bridging
+ are marked with "IP Pairing". These are optional on SoCs which do not support
+ IP Pairing
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt2701-pwrap
+ - mediatek,mt6765-pwrap
+ - mediatek,mt6779-pwrap
+ - mediatek,mt6795-pwrap
+ - mediatek,mt6797-pwrap
+ - mediatek,mt6873-pwrap
+ - mediatek,mt7622-pwrap
+ - mediatek,mt8135-pwrap
+ - mediatek,mt8173-pwrap
+ - mediatek,mt8183-pwrap
+ - mediatek,mt8186-pwrap
+ - mediatek,mt8195-pwrap
+ - mediatek,mt8365-pwrap
+ - mediatek,mt8516-pwrap
+ - items:
+ - enum:
+ - mediatek,mt8186-pwrap
+ - mediatek,mt8195-pwrap
+ - const: syscon
+ - items:
+ - enum:
+ - mediatek,mt8188-pwrap
+ - mediatek,mt8189-pwrap
+ - const: mediatek,mt8195-pwrap
+ - const: syscon
+
+ reg:
+ minItems: 1
+ items:
+ - description: PMIC wrapper registers
+ - description: IP pairing registers
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: pwrap
+ - const: pwrap-bridge
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 2
+ items:
+ - description: SPI bus clock
+ - description: Main module clock
+ - description: System module clock
+ - description: Timer module clock
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: spi
+ - const: wrap
+ - const: sys
+ - const: tmr
+
+ resets:
+ minItems: 1
+ items:
+ - description: PMIC wrapper reset
+ - description: IP pairing reset
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: pwrap
+ - const: pwrap-bridge
+
+ power-domains:
+ maxItems: 1
+
+ pmic:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+
+dependentRequired:
+ resets: [reset-names]
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8365-pwrap
+ then:
+ properties:
+ clocks:
+ minItems: 4
+
+ clock-names:
+ minItems: 4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8173-pwrap
+ then:
+ properties:
+ power-domains: true
+ else:
+ properties:
+ power-domains: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/mt8135-resets.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pwrap@1000f000 {
+ compatible = "mediatek,mt8135-pwrap";
+ reg = <0 0x1000f000 0 0x1000>,
+ <0 0x11017000 0 0x1000>;
+ reg-names = "pwrap", "pwrap-bridge";
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk26m>, <&clk26m>;
+ clock-names = "spi", "wrap";
+ resets = <&infracfg MT8135_INFRA_PMIC_WRAP_RST>,
+ <&pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST>;
+ reset-names = "pwrap", "pwrap-bridge";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
index d911fa2d40ef..742b91d1d28e 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek Smart Voltage Scaling (SVS) Device Tree Bindings
+title: MediaTek Smart Voltage Scaling (SVS)
maintainers:
- Roger Lu <roger.lu@mediatek.com>
@@ -22,7 +22,10 @@ properties:
compatible:
enum:
- mediatek,mt8183-svs
+ - mediatek,mt8186-svs
+ - mediatek,mt8188-svs
- mediatek,mt8192-svs
+ - mediatek,mt8195-svs
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
deleted file mode 100644
index d24e2bc444be..000000000000
--- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-MediaTek PMIC Wrapper Driver
-
-This document describes the binding for the MediaTek PMIC wrapper.
-
-On MediaTek SoCs the PMIC is connected via SPI. The SPI master interface
-is not directly visible to the CPU, but only through the PMIC wrapper
-inside the SoC. The communication between the SoC and the PMIC can
-optionally be encrypted. Also a non standard Dual IO SPI mode can be
-used to increase speed.
-
-IP Pairing
-
-on MT8135 the pins of some SoC internal peripherals can be on the PMIC.
-The signals of these pins are routed over the SPI bus using the pwrap
-bridge. In the binding description below the properties needed for bridging
-are marked with "IP Pairing". These are optional on SoCs which do not support
-IP Pairing
-
-Required properties in pwrap device node.
-- compatible:
- "mediatek,mt2701-pwrap" for MT2701/7623 SoCs
- "mediatek,mt6765-pwrap" for MT6765 SoCs
- "mediatek,mt6779-pwrap" for MT6779 SoCs
- "mediatek,mt6797-pwrap" for MT6797 SoCs
- "mediatek,mt6873-pwrap" for MT6873/8192 SoCs
- "mediatek,mt7622-pwrap" for MT7622 SoCs
- "mediatek,mt8135-pwrap" for MT8135 SoCs
- "mediatek,mt8173-pwrap" for MT8173 SoCs
- "mediatek,mt8183-pwrap" for MT8183 SoCs
- "mediatek,mt8186-pwrap" for MT8186 SoCs
- "mediatek,mt8188-pwrap", "mediatek,mt8195-pwrap" for MT8188 SoCs
- "mediatek,mt8195-pwrap" for MT8195 SoCs
- "mediatek,mt8516-pwrap" for MT8516 SoCs
-- interrupts: IRQ for pwrap in SOC
-- reg-names: "pwrap" is required; "pwrap-bridge" is optional.
- "pwrap": Main registers base
- "pwrap-bridge": bridge base (IP Pairing)
-- reg: Must contain an entry for each entry in reg-names.
-- clock-names: Must include the following entries:
- "spi": SPI bus clock
- "wrap": Main module clock
-- clocks: Must contain an entry for each entry in clock-names.
-
-Optional properities:
-- reset-names: Some SoCs include the following entries:
- "pwrap"
- "pwrap-bridge" (IP Pairing)
-- resets: Must contain an entry for each entry in reset-names.
-- pmic: Using either MediaTek PMIC MFD as the child device of pwrap
- See the following for child node definitions:
- Documentation/devicetree/bindings/mfd/mt6397.txt
- or the regulator-only device as the child device of pwrap, such as MT6380.
- See the following definitions for such kinds of devices.
- Documentation/devicetree/bindings/regulator/mt6380-regulator.txt
-
-Example:
- pwrap: pwrap@1000f000 {
- compatible = "mediatek,mt8135-pwrap";
- reg = <0 0x1000f000 0 0x1000>,
- <0 0x11017000 0 0x1000>;
- reg-names = "pwrap", "pwrap-bridge";
- interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
- resets = <&infracfg MT8135_INFRA_PMIC_WRAP_RST>,
- <&pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST>;
- reset-names = "pwrap", "pwrap-bridge";
- clocks = <&clk26m>, <&clk26m>;
- clock-names = "spi", "wrap";
-
- pmic {
- compatible = "mediatek,mt6397";
- };
- };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 2bc367793aec..3530a6668b48 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -20,6 +20,7 @@ Required properties:
- compatible: Should be one of:
- "mediatek,mt2701-scpsys"
- "mediatek,mt2712-scpsys"
+ - "mediatek,mt6735-scpsys"
- "mediatek,mt6765-scpsys"
- "mediatek,mt6797-scpsys"
- "mediatek,mt7622-scpsys"
diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
index 33748a061898..668b943db173 100644
--- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
+++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
@@ -15,13 +15,19 @@ description: |
properties:
compatible:
- items:
- - enum:
- - atmel,at91rm9200-tcb
- - atmel,at91sam9x5-tcb
- - atmel,sama5d2-tcb
- - const: simple-mfd
- - const: syscon
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at91rm9200-tcb
+ - atmel,at91sam9x5-tcb
+ - atmel,sama5d2-tcb
+ - const: simple-mfd
+ - const: syscon
+ - items:
+ - const: microchip,sam9x7-tcb
+ - const: atmel,sama5d2-tcb
+ - const: simple-mfd
+ - const: syscon
reg:
maxItems: 1
@@ -51,9 +57,10 @@ properties:
const: 0
patternProperties:
- "^timer@[0-2]$":
+ '^timer@[0-2]$':
description: The timer block channels that are used as timers or counters.
type: object
+ additionalProperties: false
properties:
compatible:
items:
@@ -73,7 +80,7 @@ patternProperties:
- compatible
- reg
- "^pwm@[0-2]$":
+ '^pwm@[0-2]$':
description: The timer block channels that are used as PWMs.
$ref: /schemas/pwm/pwm.yaml#
type: object
@@ -85,7 +92,7 @@ patternProperties:
TCB channel to use for this PWM.
enum: [ 0, 1, 2 ]
- "#pwm-cells":
+ '#pwm-cells':
description:
The only third cell flag supported by this binding is
PWM_POLARITY_INVERTED.
@@ -94,11 +101,10 @@ patternProperties:
required:
- compatible
- reg
- - "#pwm-cells"
+ - '#pwm-cells'
additionalProperties: false
-
allOf:
- if:
properties:
diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
new file mode 100644
index 000000000000..39987f722411
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC Microprocessor Subsystem (MSS) sysreg register region
+
+maintainers:
+ - Conor Dooley <conor.dooley@microchip.com>
+
+description:
+ An wide assortment of registers that control elements of the MSS on PolarFire
+ SoC, including pinmuxing, resets and clocks among others.
+
+properties:
+ compatible:
+ items:
+ - const: microchip,mpfs-mss-top-sysreg
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ '#reset-cells':
+ description:
+ The AHB/AXI peripherals on the PolarFire SoC have reset support, so
+ from CLK_ENVM to CLK_CFM. The reset consumer should specify the
+ desired peripheral via the clock ID in its "resets" phandle cell.
+ See include/dt-bindings/clock/microchip,mpfs-clock.h for the full list
+ of PolarFire clock/reset IDs.
+ const: 1
+
+ pinctrl@200:
+ type: object
+ $ref: /schemas/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@20002000 {
+ compatible = "microchip,mpfs-mss-top-sysreg", "syscon", "simple-mfd";
+ reg = <0x20002000 0x1000>;
+ #reset-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
index 04ffee3a7c59..a3fa04f3a1bd 100644
--- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
PolarFire SoC devices include a microcontroller acting as the system controller,
which provides "services" to the main processor and to the FPGA fabric. These
- services include hardware rng, reprogramming of the FPGA and verfification of the
+ services include hardware rng, reprogramming of the FPGA and verification of the
eNVM contents etc. More information on these services can be found online, at
https://onlinedocs.microchip.com/pr/GUID-1409CF11-8EF9-4C24-A94E-70979A688632-en-US-1/index.html
@@ -26,6 +26,16 @@ properties:
compatible:
const: microchip,mpfs-sys-controller
+ microchip,bitstream-flash:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The SPI flash connected to the system controller's QSPI controller.
+ The system controller may retrieve FPGA bitstreams from this flash to
+ perform In-Application Programming (IAP) or during device initialisation
+ for Auto Update. The MSS and system controller have separate QSPI
+ controllers and this flash is connected to both. Software running in the
+ MSS can write bitstreams to the flash.
+
required:
- compatible
- mboxes
diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,sparx5-cpu-syscon.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,sparx5-cpu-syscon.yaml
new file mode 100644
index 000000000000..1f0b542d2296
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/microchip/microchip,sparx5-cpu-syscon.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/microchip/microchip,sparx5-cpu-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 CPU Syscon
+
+maintainers:
+ - Lars Povlsen <lars.povlsen@microchip.com>
+
+properties:
+ compatible:
+ items:
+ - const: microchip,sparx5-cpu-syscon
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ mux-controller:
+ $ref: /schemas/mux/reg-mux.yaml#
+
+required:
+ - compatible
+ - reg
+ - mux-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ syscon@600000000 {
+ compatible = "microchip,sparx5-cpu-syscon", "syscon",
+ "simple-mfd";
+ reg = <0x6 0x00000000 0xd0>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x88 0xf0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml b/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml
new file mode 100644
index 000000000000..6d11472ba5a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml
@@ -0,0 +1,352 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq5-olb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mobileye EyeQ SoC system controller
+
+maintainers:
+ - Grégory Clement <gregory.clement@bootlin.com>
+ - Théo Lebrun <theo.lebrun@bootlin.com>
+ - Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
+
+description:
+ OLB ("Other Logic Block") is a hardware block grouping smaller blocks. Clocks,
+ resets, pinctrl are being handled from here. EyeQ5 and EyeQ6L host a single
+ instance. EyeQ6H hosts seven instances.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mobileye,eyeq5-olb
+ - mobileye,eyeq6l-olb
+ - mobileye,eyeq6h-acc-olb
+ - mobileye,eyeq6h-central-olb
+ - mobileye,eyeq6h-east-olb
+ - mobileye,eyeq6h-west-olb
+ - mobileye,eyeq6h-south-olb
+ - mobileye,eyeq6h-ddr0-olb
+ - mobileye,eyeq6h-ddr1-olb
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ description:
+ First cell is domain and optional if compatible has a single reset domain.
+ Second cell is reset index inside that domain.
+ enum: [ 1, 2 ]
+
+ '#clock-cells':
+ const: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ Input parent clock to all PLLs. Expected to be the main crystal.
+
+ clock-names:
+ const: ref
+
+patternProperties:
+ '-pins?$':
+ type: object
+ description: Pin muxing configuration.
+ $ref: /schemas/pinctrl/pinmux-node.yaml#
+ additionalProperties: false
+ properties:
+ pins: true
+ function:
+ enum: [gpio,
+ # Bank A
+ timer0, timer1, timer2, timer5, uart0, uart1, can0, can1, spi0,
+ spi1, refclk0,
+ # Bank B
+ timer3, timer4, timer6, uart2, can2, spi2, spi3, mclk0]
+ bias-disable: true
+ bias-pull-down: true
+ bias-pull-up: true
+ drive-strength: true
+ required:
+ - pins
+ - function
+ allOf:
+ - if:
+ properties:
+ function:
+ const: gpio
+ then:
+ properties:
+ pins:
+ items: # PA0 - PA28, PB0 - PB22
+ pattern: '^(P(A|B)1?[0-9]|PA2[0-8]|PB2[0-2])$'
+ - if:
+ properties:
+ function:
+ const: timer0
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA0, PA1]
+ - if:
+ properties:
+ function:
+ const: timer1
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA2, PA3]
+ - if:
+ properties:
+ function:
+ const: timer2
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA4, PA5]
+ - if:
+ properties:
+ function:
+ const: timer5
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA6, PA7, PA8, PA9]
+ - if:
+ properties:
+ function:
+ const: uart0
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA10, PA11]
+ - if:
+ properties:
+ function:
+ const: uart1
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA12, PA13]
+ - if:
+ properties:
+ function:
+ const: can0
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA14, PA15]
+ - if:
+ properties:
+ function:
+ const: can1
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA16, PA17]
+ - if:
+ properties:
+ function:
+ const: spi0
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA18, PA19, PA20, PA21, PA22]
+ - if:
+ properties:
+ function:
+ const: spi1
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA23, PA24, PA25, PA26, PA27]
+ - if:
+ properties:
+ function:
+ const: refclk0
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PA28]
+ - if:
+ properties:
+ function:
+ const: timer3
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB0, PB1]
+ - if:
+ properties:
+ function:
+ const: timer4
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB2, PB3]
+ - if:
+ properties:
+ function:
+ const: timer6
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB4, PB5, PB6, PB7]
+ - if:
+ properties:
+ function:
+ const: uart2
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB8, PB9]
+ - if:
+ properties:
+ function:
+ const: can2
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB10, PB11]
+ - if:
+ properties:
+ function:
+ const: spi2
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB12, PB13, PB14, PB15, PB16]
+ - if:
+ properties:
+ function:
+ const: spi3
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB17, PB18, PB19, PB20, PB21]
+ - if:
+ properties:
+ function:
+ const: mclk0
+ then:
+ properties:
+ pins:
+ items:
+ enum: [PB22]
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+allOf:
+ # Compatibles exposing a single reset domain.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mobileye,eyeq6h-acc-olb
+ - mobileye,eyeq6h-east-olb
+ - mobileye,eyeq6h-west-olb
+ then:
+ properties:
+ '#reset-cells':
+ const: 1
+ required:
+ - '#reset-cells'
+
+ # Compatibles exposing two reset domains.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mobileye,eyeq5-olb
+ - mobileye,eyeq6l-olb
+ then:
+ properties:
+ '#reset-cells':
+ const: 2
+ required:
+ - '#reset-cells'
+
+ # Compatibles not exposing resets.
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mobileye,eyeq6h-central-olb
+ - mobileye,eyeq6h-south-olb
+ - mobileye,eyeq6h-ddr0-olb
+ - mobileye,eyeq6h-ddr1-olb
+ then:
+ properties:
+ '#reset-cells': false
+
+ # Only EyeQ5 has pinctrl in OLB.
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: mobileye,eyeq5-olb
+ then:
+ patternProperties:
+ '-pins?$': false
+
+examples:
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ system-controller@e00000 {
+ compatible = "mobileye,eyeq5-olb", "syscon";
+ reg = <0 0xe00000 0x0 0x400>;
+ #reset-cells = <2>;
+ #clock-cells = <1>;
+ clocks = <&xtal>;
+ clock-names = "ref";
+ };
+ };
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ system-controller@d2003000 {
+ compatible = "mobileye,eyeq6h-acc-olb", "syscon";
+ reg = <0x0 0xd2003000 0x0 0x1000>;
+ #reset-cells = <1>;
+ #clock-cells = <1>;
+ clocks = <&xtal>;
+ clock-names = "ref";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,gfxi.yaml b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,gfxi.yaml
new file mode 100644
index 000000000000..0222a43977ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,gfxi.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/nuvoton/nuvoton,gfxi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Graphics Core Information block in Nuvoton SoCs
+
+maintainers:
+ - Joseph Liu <kwliu@nuvoton.com>
+ - Marvin Lin <kflin@nuvoton.com>
+
+description:
+ The Graphics Core Information (GFXI) are a block of registers in Nuvoton SoCs
+ that analyzes Graphics core behavior and provides information in registers.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nuvoton,npcm750-gfxi
+ - nuvoton,npcm845-gfxi
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ gfxi: gfxi@e000 {
+ compatible = "nuvoton,npcm750-gfxi", "syscon";
+ reg = <0xe000 0x100>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml
new file mode 100644
index 000000000000..23e7e4ea01ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,npcm-gcr.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/nuvoton/nuvoton,npcm-gcr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Global Control Registers block in Nuvoton SoCs
+
+maintainers:
+ - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+description:
+ The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs
+ that expose misc functionality such as chip model and version information or
+ pinmux settings.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nuvoton,wpcm450-gcr
+ - nuvoton,npcm750-gcr
+ - nuvoton,npcm845-gcr
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ gcr: syscon@800000 {
+ compatible = "nuvoton,npcm750-gcr", "syscon", "simple-mfd";
+ reg = <0x800000 0x1000>;
+
+ mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x38 0x07>;
+ idle-states = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
index a4eeb7e158e5..c5c1bac2db01 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/soc/qcom/qcom,aoss-qmp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Always-On Subsystem side channel binding
+title: Qualcomm Always-On Subsystem side channel
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
@@ -25,15 +25,31 @@ properties:
compatible:
items:
- enum:
+ - qcom,glymur-aoss-qmp
+ - qcom,kaanapali-aoss-qmp
+ - qcom,milos-aoss-qmp
+ - qcom,qcs615-aoss-qmp
+ - qcom,qcs8300-aoss-qmp
+ - qcom,qdu1000-aoss-qmp
+ - qcom,sa8255p-aoss-qmp
+ - qcom,sa8775p-aoss-qmp
+ - qcom,sar2130p-aoss-qmp
- qcom,sc7180-aoss-qmp
- qcom,sc7280-aoss-qmp
- qcom,sc8180x-aoss-qmp
+ - qcom,sc8280xp-aoss-qmp
+ - qcom,sdx75-aoss-qmp
- qcom,sdm845-aoss-qmp
- qcom,sm6350-aoss-qmp
+ - qcom,sm7150-aoss-qmp
- qcom,sm8150-aoss-qmp
- qcom,sm8250-aoss-qmp
- qcom,sm8350-aoss-qmp
- qcom,sm8450-aoss-qmp
+ - qcom,sm8550-aoss-qmp
+ - qcom,sm8650-aoss-qmp
+ - qcom,sm8750-aoss-qmp
+ - qcom,x1e80100-aoss-qmp
- const: qcom,aoss-qmp
reg:
@@ -73,7 +89,7 @@ patternProperties:
description:
The AOSS side channel also provides the controls for three cooling devices,
these are expressed as subnodes of the QMP node. The name of the node is
- used to identify the resource and must therefor be "cx", "mx" or "ebi".
+ used to identify the resource and must therefore be "cx", "mx" or "ebi".
properties:
"#cooling-cells":
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
new file mode 100644
index 000000000000..bdf482db32aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,apr-services.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm APR/GPR services shared parts
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Common parts of a static service in Qualcomm APR/GPR (Asynchronous/Generic
+ Packet Router).
+
+properties:
+ reg:
+ minimum: 1
+ maximum: 13
+ description: |
+ APR Service ID
+ 3 = DSP Core Service
+ 4 = Audio Front End Service.
+ 5 = Voice Stream Manager Service.
+ 6 = Voice processing manager.
+ 7 = Audio Stream Manager Service.
+ 8 = Audio Device Manager Service.
+ 9 = Multimode voice manager.
+ 10 = Core voice stream.
+ 11 = Core voice processor.
+ 12 = Ultrasound stream manager.
+ 13 = Listen stream manager.
+ GPR Service ID
+ 1 = Audio Process Manager Service
+ 2 = Proxy Resource Manager Service.
+ 3 = AMDB Service.
+ 4 = Voice processing manager.
+
+ qcom,protection-domain:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: |
+ Protection domain service name and path for APR service (if supported).
+ Possible values are::
+ "avs/audio", "msm/adsp/audio_pd".
+ "kernel/elf_loader", "msm/modem/wlan_pd".
+ "tms/servreg", "msm/adsp/audio_pd".
+ "tms/servreg", "msm/modem/wlan_pd".
+ "tms/servreg", "msm/slpi/sensor_pd".
+
+required:
+ - reg
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml
index f47491aab3b1..e51acdcaafaf 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/qcom/qcom,apr.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/qcom/qcom,apr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm APR/GPR (Asynchronous/Generic Packet Router) binding
+title: Qualcomm APR/GPR (Asynchronous/Generic Packet Router)
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -17,6 +17,7 @@ description: |
properties:
compatible:
enum:
+ - qcom,apr
- qcom,apr-v2
- qcom,gpr
@@ -58,11 +59,17 @@ properties:
qcom,glink-channels:
$ref: /schemas/types.yaml#/definitions/string-array
description: Channel name used for the communication
- items:
- - const: apr_audio_svc
+ maxItems: 1
qcom,intents:
- $ref: /schemas/types.yaml#/definitions/uint32-array
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ maxItems: 32
+ items:
+ items:
+ - description: size of each intent to preallocate
+ - description: amount of intents to preallocate
+ minimum: 1
description:
List of (size, amount) pairs describing what intents should be
preallocated for this virtual channel. This can be used to tweak the
@@ -81,12 +88,13 @@ properties:
'#size-cells':
const: 0
-#APR/GPR Services
patternProperties:
"^service@[1-9a-d]$":
type: object
+ $ref: /schemas/soc/qcom/qcom,apr-services.yaml
+ additionalProperties: true
description:
- APR/GPR node's client devices use subnodes for desired static port services.
+ APR/GPR static port services.
properties:
compatible:
@@ -98,99 +106,6 @@ patternProperties:
- qcom,q6apm
- qcom,q6prm
- reg:
- minimum: 1
- maximum: 13
- description:
- APR Service ID
- 3 = DSP Core Service
- 4 = Audio Front End Service.
- 5 = Voice Stream Manager Service.
- 6 = Voice processing manager.
- 7 = Audio Stream Manager Service.
- 8 = Audio Device Manager Service.
- 9 = Multimode voice manager.
- 10 = Core voice stream.
- 11 = Core voice processor.
- 12 = Ultrasound stream manager.
- 13 = Listen stream manager.
- GPR Service ID
- 1 = Audio Process Manager Service
- 2 = Proxy Resource Manager Service.
- 3 = AMDB Service.
- 4 = Voice processing manager.
-
- clock-controller:
- $ref: /schemas/sound/qcom,q6dsp-lpass-clocks.yaml#
- description: Qualcomm DSP LPASS clock controller
- unevaluatedProperties: false
-
- dais:
- type: object
- oneOf:
- - $ref: /schemas/sound/qcom,q6apm-dai.yaml#
- - $ref: /schemas/sound/qcom,q6dsp-lpass-ports.yaml#
- - $ref: /schemas/sound/qcom,q6asm-dais.yaml#
- unevaluatedProperties: false
- description: Qualcomm DSP audio ports
-
- routing:
- type: object
- $ref: /schemas/sound/qcom,q6adm-routing.yaml#
- unevaluatedProperties: false
- description: Qualcomm DSP LPASS audio routing
-
- qcom,protection-domain:
- $ref: /schemas/types.yaml#/definitions/string-array
- description: protection domain service name and path for apr service
- possible values are
- "avs/audio", "msm/adsp/audio_pd".
- "kernel/elf_loader", "msm/modem/wlan_pd".
- "tms/servreg", "msm/adsp/audio_pd".
- "tms/servreg", "msm/modem/wlan_pd".
- "tms/servreg", "msm/slpi/sensor_pd".
-
- allOf:
- - if:
- properties:
- compatible:
- enum:
- - qcom,q6afe
- then:
- properties:
- dais:
- properties:
- compatible:
- const: qcom,q6afe-dais
-
- - if:
- properties:
- compatible:
- enum:
- - qcom,q6apm
- then:
- properties:
- dais:
- properties:
- compatible:
- enum:
- - qcom,q6apm-dais
- - qcom,q6apm-lpass-dais
-
- - if:
- properties:
- compatible:
- enum:
- - qcom,q6asm
- then:
- properties:
- dais:
- properties:
- compatible:
- const: qcom,q6asm-dais
-
- additionalProperties: false
-
required:
- compatible
- qcom,domain
@@ -203,7 +118,15 @@ allOf:
- qcom,gpr
then:
properties:
+ qcom,glink-channels:
+ items:
+ - const: adsp_apps
power-domains: false
+ else:
+ properties:
+ qcom,glink-channels:
+ items:
+ - const: apr_audio_svc
- if:
required:
@@ -227,31 +150,35 @@ examples:
apr {
compatible = "qcom,apr-v2";
qcom,domain = <APR_DOMAIN_ADSP>;
+ qcom,glink-channels = "apr_audio_svc";
+ qcom,intents = <512 20>;
#address-cells = <1>;
#size-cells = <0>;
q6core: service@3 {
- compatible = "qcom,q6core";
- reg = <APR_SVC_ADSP_CORE>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
- };
-
- q6afe: service@4 {
- compatible = "qcom,q6afe";
- reg = <APR_SVC_AFE>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
- };
-
- q6asm: service@7 {
- compatible = "qcom,q6asm";
- reg = <APR_SVC_ASM>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+ compatible = "qcom,q6core";
+ reg = <APR_SVC_ADSP_CORE>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
};
- q6adm: service@8 {
- compatible = "qcom,q6adm";
- reg = <APR_SVC_ADM>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+ service@4 {
+ compatible = "qcom,q6afe";
+ reg = <APR_SVC_AFE>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ clock-controller {
+ compatible = "qcom,q6afe-clocks";
+ #clock-cells = <2>;
+ };
+
+ dais {
+ compatible = "qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ /* ... */
+ };
+ /* ... */
};
};
@@ -260,12 +187,25 @@ examples:
gpr {
compatible = "qcom,gpr";
qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+ qcom,glink-channels = "adsp_apps";
+ qcom,intents = <512 20>;
#address-cells = <1>;
#size-cells = <0>;
service@1 {
- compatible = "qcom,q6apm";
- reg = <GPR_APM_MODULE_IID>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+ compatible = "qcom,q6apm";
+ reg = <GPR_APM_MODULE_IID>;
+ #sound-dai-cells = <0>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ dais {
+ compatible = "qcom,q6apm-dais";
+ iommus = <&apps_smmu 0x1801 0x0>;
+ };
+
+ bedais {
+ compatible = "qcom,q6apm-lpass-dais";
+ #sound-dai-cells = <1>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml
new file mode 100644
index 000000000000..fdc6fc17ed71
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,dcc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,dcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Data Capture and Compare
+
+maintainers:
+ - Souradeep Chowdhury <quic_schowdhu@quicinc.com>
+
+description: |
+ DCC (Data Capture and Compare) is a DMA engine which is used to save
+ configuration data or system memory contents during catastrophic failure
+ or SW trigger. DCC is used to capture and store data for debugging purpose
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,sm7150-dcc
+ - qcom,sm8150-dcc
+ - qcom,sc7280-dcc
+ - qcom,sc7180-dcc
+ - qcom,sdm845-dcc
+ - const: qcom,dcc
+
+ reg:
+ items:
+ - description: DCC base
+ - description: DCC RAM base
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ dma@10a2000{
+ compatible = "qcom,sm8150-dcc", "qcom,dcc";
+ reg = <0x010a2000 0x1000>,
+ <0x010ad000 0x2000>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
index c98aab209bc5..84218636c0d8 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Embedded USB Debugger
@@ -55,23 +55,25 @@ additionalProperties: false
examples:
- |
eud@88e0000 {
- compatible = "qcom,sc7280-eud","qcom,eud";
- reg = <0x88e0000 0x2000>,
- <0x88e2000 0x1000>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- eud_ep: endpoint {
- remote-endpoint = <&usb2_role_switch>;
- };
- };
- port@1 {
- reg = <1>;
- eud_con: endpoint {
- remote-endpoint = <&con_eud>;
- };
- };
- };
+ compatible = "qcom,sc7280-eud", "qcom,eud";
+ reg = <0x88e0000 0x2000>,
+ <0x88e2000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ eud_ep: endpoint {
+ remote-endpoint = <&usb2_role_switch>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ eud_con: endpoint {
+ remote-endpoint = <&con_eud>;
+ };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
index 2bf5293fc995..54cd585f19e3 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/qcom/qcom,geni-se.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/qcom/qcom,geni-se.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: GENI Serial Engine QUP Wrapper Controller
@@ -21,20 +21,19 @@ properties:
compatible:
enum:
- qcom,geni-se-qup
+ - qcom,geni-se-i2c-master-hub
reg:
description: QUP wrapper common register address and length.
maxItems: 1
clock-names:
- items:
- - const: m-ahb
- - const: s-ahb
+ minItems: 1
+ maxItems: 2
clocks:
- items:
- - description: Master AHB Clock
- - description: Slave AHB Clock
+ minItems: 1
+ maxItems: 2
"#address-cells":
const: 2
@@ -53,6 +52,12 @@ properties:
iommus:
maxItems: 1
+ dma-coherent: true
+
+ firmware-name:
+ maxItems: 1
+ description: Specify the name of the QUP firmware to load.
+
required:
- compatible
- reg
@@ -81,6 +86,39 @@ patternProperties:
description: GENI Serial Engine based UART Controller.
$ref: /schemas/serial/qcom,serial-geni-qcom.yaml#
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,geni-se-i2c-master-hub
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: s-ahb
+
+ clocks:
+ items:
+ - description: Slave AHB Clock
+
+ iommus: false
+
+ patternProperties:
+ "spi@[0-9a-f]+$": false
+ "serial@[0-9a-f]+$": false
+ else:
+ properties:
+ clock-names:
+ items:
+ - const: m-ahb
+ - const: s-ahb
+
+ clocks:
+ items:
+ - description: Master AHB Clock
+ - description: Slave AHB Clock
+
additionalProperties: false
examples:
@@ -101,6 +139,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ firmware-name = "qcom/sa8775p/qupv3fw.elf";
i2c0: i2c@a94000 {
compatible = "qcom,geni-i2c";
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
deleted file mode 100644
index 1214192847ac..000000000000
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Qualcomm GLINK edge binding
-
-This binding describes a Qualcomm GLINK edge, a fifo based mechanism for
-communication between subsystem-pairs on various Qualcomm platforms. Two types
-of edges can be described by the binding; the GLINK RPM edge and a SMEM based
-edge.
-
-- compatible:
- Usage: required for glink-rpm
- Value type: <stringlist>
- Definition: must be "qcom,glink-rpm"
-
-- label:
- Usage: optional
- Value type: <string>
- Definition: should specify the subsystem name this edge corresponds to.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the IRQ used by the remote processor to
- signal this processor about communication related events
-
-- qcom,remote-pid:
- Usage: required for glink-smem
- Value type: <u32>
- Definition: specifies the identifier of the remote endpoint of this edge
-
-- qcom,rpm-msg-ram:
- Usage: required for glink-rpm
- Value type: <prop-encoded-array>
- Definition: handle to RPM message memory resource
-
-- mboxes:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: reference to the "rpm_hlos" mailbox in APCS, as described
- in mailbox/mailbox.txt
-
-= GLINK DEVICES
-Each subnode of the GLINK node represent function tied to a virtual
-communication channel. The name of the nodes are not important. The properties
-of these nodes are defined by the individual bindings for the specific function
-- but must contain the following property:
-
-- qcom,glink-channels:
- Usage: required
- Value type: <stringlist>
- Definition: a list of channels tied to this function, used for matching
- the function to a set of virtual channels
-
-- qcom,intents:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: a list of size,amount pairs describing what intents should
- be preallocated for this virtual channel. This can be used
- to tweak the default intents available for the channel to
- meet expectations of the remote.
-
-= EXAMPLE
-The following example represents the GLINK RPM node on a MSM8996 device, with
-the function for the "rpm_request" channel defined, which is used for
-regulators and root clocks.
-
- apcs_glb: mailbox@9820000 {
- compatible = "qcom,msm8996-apcs-hmss-global";
- reg = <0x9820000 0x1000>;
-
- #mbox-cells = <1>;
- };
-
- rpm_msg_ram: memory@68000 {
- compatible = "qcom,rpm-msg-ram";
- reg = <0x68000 0x6000>;
- };
-
- rpm-glink {
- compatible = "qcom,glink-rpm";
-
- interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
-
- qcom,rpm-msg-ram = <&rpm_msg_ram>;
-
- mboxes = <&apcs_glb 0>;
-
- rpm-requests {
- compatible = "qcom,rpm-msm8996";
- qcom,glink-channels = "rpm_requests";
-
- qcom,intents = <0x400 5
- 0x800 1>;
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml
index c33704333e49..d9f6d34a61c6 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.yaml
@@ -9,7 +9,7 @@ title: Qualcomm General Serial Bus Interface (GSBI)
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description:
The GSBI controller is modeled as a node with zero or more child nodes, each
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml
new file mode 100644
index 000000000000..aae9cf7b8caf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,msm8976-ramp-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Ramp Controller
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The Ramp Controller is used to program the sequence ID for pulse
+ swallowing, enable sequences and link Sequence IDs (SIDs) for the
+ CPU cores on some Qualcomm SoCs.
+
+properties:
+ compatible:
+ enum:
+ - qcom,msm8976-ramp-controller
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ cpu-power-controller@b014000 {
+ compatible = "qcom,msm8976-ramp-controller";
+ reg = <0x0b014000 0x68>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml
new file mode 100644
index 000000000000..b502ca72266a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,pbs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. Programmable Boot Sequencer
+
+maintainers:
+ - Anjelique Melendez <quic_amelende@quicinc.com>
+
+description: |
+ The Qualcomm Technologies, Inc. Programmable Boot Sequencer (PBS)
+ supports triggering power up and power down sequences for clients
+ upon request.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,pmi632-pbs
+ - const: qcom,pbs
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@0 {
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pbs@7400 {
+ compatible = "qcom,pmi632-pbs", "qcom,pbs";
+ reg = <0x7400>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
new file mode 100644
index 000000000000..7085bf88afab
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,pmic-glink.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PMIC GLINK firmware interface for battery management, USB
+ Type-C and other things.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ The PMIC GLINK service, running on a coprocessor on some modern Qualcomm
+ platforms and implement USB Type-C handling and battery management. This
+ binding describes the component in the OS used to communicate with the
+ firmware and connect it's resources to those described in the Devicetree,
+ particularly the USB Type-C controllers relationship with USB and DisplayPort
+ components.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,qcm6490-pmic-glink
+ - qcom,sc8180x-pmic-glink
+ - qcom,sc8280xp-pmic-glink
+ - qcom,sm8350-pmic-glink
+ - qcom,sm8450-pmic-glink
+ - qcom,sm8550-pmic-glink
+ - const: qcom,pmic-glink
+ - items:
+ - enum:
+ - qcom,sm7325-pmic-glink
+ - const: qcom,qcm6490-pmic-glink
+ - const: qcom,pmic-glink
+ - items:
+ - enum:
+ - qcom,milos-pmic-glink
+ - qcom,sm8650-pmic-glink
+ - qcom,sm8750-pmic-glink
+ - qcom,x1e80100-pmic-glink
+ - const: qcom,sm8550-pmic-glink
+ - const: qcom,pmic-glink
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ orientation-gpios:
+ description: Array of input gpios for the Type-C connector orientation indication.
+ The GPIO indication is used to detect the orientation of the Type-C connector.
+ The array should contain a gpio entry for each PMIC Glink connector, in reg order.
+ It is defined that GPIO active level means "CC2" or Reversed/Flipped orientation.
+
+ nvmem-cells:
+ minItems: 3
+ maxItems: 3
+ description:
+ The nvmem cells contain the charge control settings, including the charge control
+ enable status, the battery state of charge (SoC) threshold for stopping charging,
+ and the battery SoC delta required to restart charging.
+
+ nvmem-cell-names:
+ items:
+ - const: charge_limit_en
+ - const: charge_limit_end
+ - const: charge_limit_delta
+
+patternProperties:
+ '^connector@\d$':
+ $ref: /schemas/connector/usb-connector.yaml#
+ required:
+ - reg
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |+
+ pmic-glink {
+ compatible = "qcom,sc8280xp-pmic-glink", "qcom,pmic-glink";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&usb_role>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&ss_phy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ endpoint {
+ remote-endpoint = <&sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+...
+
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml
new file mode 100644
index 000000000000..ad2dcc39a5f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,rpm-master-stats.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. (QTI) RPM Master Stats
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description: |
+ The Qualcomm RPM (Resource Power Manager) architecture includes a concept
+ of "RPM Masters". They can be thought of as "the local gang leaders", usually
+ spanning a single subsystem (e.g. APSS, ADSP, CDSP). All of the RPM decisions
+ (particularly around entering hardware-driven low power modes: XO shutdown
+ and total system-wide power collapse) are first made at Master-level, and
+ only then aggregated for the entire system.
+
+ The Master Stats provide a few useful bits that can be used to assess whether
+ our device has entered the desired low-power mode, how long it took to do so,
+ the duration of that residence, how long it took to come back online,
+ how many times a given sleep state was entered and which cores are actively
+ voting for staying awake.
+
+ This scheme has been used on various SoCs in the 2013-2023 era, with some
+ newer or higher-end designs providing this information through an SMEM query.
+
+properties:
+ compatible:
+ const: qcom,rpm-master-stats
+
+ qcom,rpm-msg-ram:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Phandle to an RPM MSG RAM slice containing the master stats
+ minItems: 1
+ maxItems: 5
+ items:
+ maxItems: 1
+
+ qcom,master-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ The name of the RPM Master which owns the MSG RAM slice where this
+ instance of Master Stats resides
+ minItems: 1
+ maxItems: 5
+
+required:
+ - compatible
+ - qcom,rpm-msg-ram
+ - qcom,master-names
+
+additionalProperties: false
+
+examples:
+ - |
+ stats {
+ compatible = "qcom,rpm-master-stats";
+ qcom,rpm-msg-ram = <&apss_master_stats>,
+ <&mpss_master_stats>,
+ <&adsp_master_stats>,
+ <&cdsp_master_stats>,
+ <&tz_master_stats>;
+ qcom,master-names = "APSS",
+ "MPSS",
+ "ADSP",
+ "CDSP",
+ "TZ";
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml
new file mode 100644
index 000000000000..3e8d99cb4dc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,rpm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Resource Power Manager (RPM)
+
+description:
+ This driver is used to interface with the Resource Power Manager (RPM) found
+ in various Qualcomm platforms. The RPM allows each component in the system
+ to vote for state of the system resources, such as clocks, regulators and bus
+ frequencies.
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - qcom,rpm-apq8064
+ - qcom,rpm-msm8660
+ - qcom,rpm-msm8960
+ - qcom,rpm-ipq8064
+ - qcom,rpm-mdm9615
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: ack
+ - const: err
+ - const: wakeup
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ram
+
+ qcom,ipc:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to a syscon node representing the APCS registers
+ - description: u32 representing offset to the register within the syscon
+ - description: u32 representing the ipc bit within the register
+ description:
+ Three entries specifying the outgoing ipc bit used for signaling the RPM.
+
+ clock-controller:
+ type: object
+ additionalProperties: true
+ properties:
+ compatible:
+ contains:
+ const: qcom,rpmcc
+
+patternProperties:
+ "^regulators(-[01])?$":
+ type: object
+ $ref: /schemas/regulator/qcom,rpm-regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - qcom,ipc
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/qcom-rpm.h>
+
+ rpm@108000 {
+ compatible = "qcom,rpm-msm8960";
+ reg = <0x108000 0x1000>;
+ qcom,ipc = <&apcs 0x8 2>;
+
+ interrupts = <GIC_SPI 19 IRQ_TYPE_NONE>, <GIC_SPI 21 IRQ_TYPE_NONE>, <GIC_SPI 22 IRQ_TYPE_NONE>;
+ interrupt-names = "ack", "err", "wakeup";
+
+ regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+ vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+
+ s1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+
+ bias-pull-down;
+
+ qcom,switch-mode-frequency = <3200000>;
+ };
+
+ pm8921_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+
+ qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
index 4a50f1d27724..26d9bc773ec5 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
@@ -28,7 +28,7 @@ description: |
SLEEP - Triggered by F/W
WAKE - Triggered by F/W
CONTROL - Triggered by F/W
- See also:: <dt-bindings/soc/qcom,rpmh-rsc.h>
+ See also: <dt-bindings/soc/qcom,rpmh-rsc.h>
The order in which they are described in the DT, should match the hardware
configuration.
@@ -44,7 +44,13 @@ description: |
properties:
compatible:
- const: qcom,rpmh-rsc
+ oneOf:
+ - items:
+ - enum:
+ - qcom,sc7180-rpmh-apps-rsc
+ - qcom,sdm845-rpmh-apps-rsc
+ - const: qcom,rpmh-rsc
+ - const: qcom,rpmh-rsc
interrupts:
minItems: 1
@@ -99,6 +105,9 @@ properties:
- const: drv-2
- const: drv-3
+ power-domains:
+ maxItems: 1
+
bcm-voter:
$ref: /schemas/interconnect/qcom,bcm-voter.yaml#
@@ -109,8 +118,9 @@ properties:
$ref: /schemas/power/qcom,rpmpd.yaml#
patternProperties:
- '-regulators$':
+ '^regulators(-[0-9])?$':
$ref: /schemas/regulator/qcom,rpmh-regulator.yaml#
+ unevaluatedProperties: false
required:
- compatible
@@ -121,6 +131,21 @@ required:
- reg
- reg-names
+allOf:
+ # Some platforms may lack a OSI-mode PSCI implementation, which implies the
+ # system power domain can't provide feedback about entering power collapse
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7180-rpmh-apps-rsc
+ - qcom,sdm845-rpmh-apps-rsc
+ then:
+ required:
+ - power-domains
+
additionalProperties: false
examples:
@@ -151,6 +176,7 @@ examples:
<SLEEP_TCS 3>,
<WAKE_TCS 3>,
<CONTROL_TCS 1>;
+ power-domains = <&CLUSTER_PD>;
};
- |
@@ -174,6 +200,7 @@ examples:
<SLEEP_TCS 1>,
<WAKE_TCS 1>,
<CONTROL_TCS 0>;
+ power-domains = <&CLUSTER_PD>;
};
- |
@@ -197,6 +224,7 @@ examples:
<SLEEP_TCS 3>,
<WAKE_TCS 3>,
<CONTROL_TCS 0>;
+ power-domains = <&CLUSTER_PD>;
clock-controller {
compatible = "qcom,sm8350-rpmh-clk";
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
new file mode 100644
index 000000000000..352af3426d34
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,sa8255p-geni-se-qup.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GENI Serial Engine QUP Wrapper Controller
+
+maintainers:
+ - Praveen Talari <quic_ptalari@quicinc.com>
+
+description:
+ Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper
+ is a programmable module for supporting a wide range of serial interfaces
+ like UART, SPI, I2C, I3C, etc. A single QUP module can provide up to 8 Serial
+ Interfaces, using its internal Serial Engines. The GENI Serial Engine QUP
+ Wrapper controller is modeled as a node with zero or more child nodes each
+ representing a serial engine.
+
+properties:
+ compatible:
+ const: qcom,sa8255p-geni-se-qup
+
+ reg:
+ description: QUP wrapper common register address and length.
+ maxItems: 1
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ ranges: true
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+patternProperties:
+ "spi@[0-9a-f]+$":
+ type: object
+ description: GENI serial engine based SPI controller. SPI in master mode
+ supports up to 50MHz, up to four chip selects, programmable
+ data path from 4 bits to 32 bits and numerous protocol
+ variants.
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sa8255p-geni-spi
+
+ "i2c@[0-9a-f]+$":
+ type: object
+ description: GENI serial engine based I2C controller.
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: qcom,sa8255p-geni-i2c
+
+ "serial@[0-9a-f]+$":
+ type: object
+ description: GENI Serial Engine based UART Controller.
+ additionalProperties: true
+
+ properties:
+ compatible:
+ enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ geniqup@9c0000 {
+ compatible = "qcom,sa8255p-geni-se-qup";
+ reg = <0 0x9c0000 0 0x6000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ serial@990000 {
+ compatible = "qcom,sa8255p-geni-uart";
+ reg = <0 0x990000 0 0x4000>;
+ interrupts = <GIC_SPI 531 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&scmi0_pd 0>, <&scmi0_dvfs 0>;
+ power-domain-names = "power", "perf";
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
new file mode 100644
index 000000000000..c2f1f5946cfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,saw2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Subsystem Power Manager / SPM AVS Wrapper 2 (SAW2)
+
+maintainers:
+ - Andy Gross <agross@kernel.org>
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+description: |
+ The Qualcomm Subsystem Power Manager is used to control the peripheral logic
+ surrounding the application cores in Qualcomm platforms.
+
+ The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
+ Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
+ power-controller that transitions a piece of hardware (like a processor or
+ subsystem) into and out of low power modes via a direct connection to
+ the PMIC. It can also be wired up to interact with other processors in the
+ system, notifying them when a low power state is entered or exited.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,ipq4019-saw2-cpu
+ - qcom,ipq4019-saw2-l2
+ - qcom,ipq8064-saw2-cpu
+ - qcom,sdm660-gold-saw2-v4.1-l2
+ - qcom,sdm660-silver-saw2-v4.1-l2
+ - qcom,msm8998-gold-saw2-v4.1-l2
+ - qcom,msm8998-silver-saw2-v4.1-l2
+ - qcom,msm8909-saw2-v3.0-cpu
+ - qcom,msm8916-saw2-v3.0-cpu
+ - qcom,msm8939-saw2-v3.0-cpu
+ - qcom,msm8226-saw2-v2.1-cpu
+ - qcom,msm8226-saw2-v2.1-l2
+ - qcom,msm8960-saw2-cpu
+ - qcom,msm8974-saw2-v2.1-cpu
+ - qcom,msm8974-saw2-v2.1-l2
+ - qcom,msm8976-gold-saw2-v2.3-l2
+ - qcom,msm8976-silver-saw2-v2.3-l2
+ - qcom,apq8084-saw2-v2.1-cpu
+ - qcom,apq8084-saw2-v2.1-l2
+ - qcom,apq8064-saw2-v1.1-cpu
+ - const: qcom,saw2
+
+ reg:
+ items:
+ - description: Base address and size of the SPM register region
+ - description: Base address and size of the alias register region
+ minItems: 1
+
+ regulator:
+ $ref: /schemas/regulator/regulator.yaml#
+ description: Indicates that this SPM device acts as a regulator device
+ device for the core (CPU or Cache) the SPM is attached to.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+
+ /* Example 1: SoC using SAW2 and kpss-acc-v2 CPUIdle */
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ enable-method = "qcom,kpss-acc-v2";
+ qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
+ reg = <0x0>;
+ operating-points-v2 = <&cpu_opp_table>;
+ };
+ };
+
+ saw0: power-manager@f9089000 {
+ compatible = "qcom,msm8974-saw2-v2.1-cpu", "qcom,saw2";
+ reg = <0xf9089000 0x1000>;
+ };
+
+ - |
+
+ /*
+ * Example 2: New-gen multi cluster SoC using SAW only for L2;
+ * This does not require any cpuidle driver, nor any cpu phandle.
+ */
+ power-manager@17812000 {
+ compatible = "qcom,msm8998-gold-saw2-v4.1-l2", "qcom,saw2";
+ reg = <0x17812000 0x1000>;
+ };
+
+ power-manager@17912000 {
+ compatible = "qcom,msm8998-silver-saw2-v4.1-l2", "qcom,saw2";
+ reg = <0x17912000 0x1000>;
+ };
+
+ - |
+ /*
+ * Example 3: SAW2 with the bundled regulator definition.
+ */
+ power-manager@2089000 {
+ compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
+ reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
+
+ regulator {
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1300000>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,se-common-props.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,se-common-props.yaml
new file mode 100644
index 000000000000..6a34f05a07e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,se-common-props.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,se-common-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QUP Peripheral-specific properties for I2C, SPI and SERIAL bus
+
+description:
+ The Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) is
+ a programmable module that supports a wide range of serial interfaces
+ such as UART, SPI, I2C, I3C, etc. This defines the common properties used
+ across QUP-supported peripherals.
+
+maintainers:
+ - Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
+ - Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
+
+properties:
+ qcom,enable-gsi-dma:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Configure the Serial Engine (SE) to transfer data in QCOM GPI DMA mode.
+ By default, FIFO mode (PIO/CPU DMA) will be selected.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
index 09d5bfa920f2..270bcd079f88 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Resource Power Manager (RPM) over SMD
+title: Qualcomm Resource Power Manager (RPM) over SMD/GLINK
description: |
This driver is used to interface with the Resource Power Manager (RPM) found
@@ -12,9 +12,9 @@ description: |
to vote for state of the system resources, such as clocks, regulators and bus
frequencies.
- The SMD information for the RPM edge should be filled out. See qcom,smd.yaml
- for the required edge properties. All SMD related properties will reside
- within the RPM node itself.
+ The SMD or GLINK information for the RPM edge should be filled out. See
+ qcom,smd.yaml for the required edge properties. All SMD/GLINK related
+ properties will reside within the RPM node itself.
The RPM exposes resources to its subnodes. The rpm_requests node must be
present and this subnode may contain children that designate regulator
@@ -30,23 +30,37 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,rpm-apq8084
- - qcom,rpm-ipq6018
- - qcom,rpm-msm8226
- - qcom,rpm-msm8909
- - qcom,rpm-msm8916
- - qcom,rpm-msm8936
- - qcom,rpm-msm8953
- - qcom,rpm-msm8974
- - qcom,rpm-msm8976
- - qcom,rpm-msm8996
- - qcom,rpm-msm8998
- - qcom,rpm-sdm660
- - qcom,rpm-sm6115
- - qcom,rpm-sm6125
- - qcom,rpm-qcm2290
- - qcom,rpm-qcs404
+ oneOf:
+ - items:
+ - enum:
+ - qcom,rpm-apq8084
+ - qcom,rpm-mdm9607
+ - qcom,rpm-msm8226
+ - qcom,rpm-msm8610
+ - qcom,rpm-msm8909
+ - qcom,rpm-msm8916
+ - qcom,rpm-msm8917
+ - qcom,rpm-msm8936
+ - qcom,rpm-msm8937
+ - qcom,rpm-msm8952
+ - qcom,rpm-msm8953
+ - qcom,rpm-msm8974
+ - qcom,rpm-msm8976
+ - qcom,rpm-msm8994
+ - const: qcom,smd-rpm
+ - items:
+ - enum:
+ - qcom,rpm-ipq6018
+ - qcom,rpm-ipq9574
+ - qcom,rpm-msm8996
+ - qcom,rpm-msm8998
+ - qcom,rpm-qcm2290
+ - qcom,rpm-qcs404
+ - qcom,rpm-sdm660
+ - qcom,rpm-sm6115
+ - qcom,rpm-sm6125
+ - qcom,rpm-sm6375
+ - const: qcom,glink-smd-rpm
clock-controller:
$ref: /schemas/clock/qcom,rpmcc.yaml#
@@ -55,24 +69,38 @@ properties:
power-controller:
$ref: /schemas/power/qcom,rpmpd.yaml#
+ qcom,glink-channels:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: Channel name used for the RPM communication
+ items:
+ - const: rpm_requests
+
qcom,smd-channels:
$ref: /schemas/types.yaml#/definitions/string-array
description: Channel name used for the RPM communication
items:
- const: rpm_requests
+patternProperties:
+ "^regulators(-[01])?$":
+ $ref: /schemas/regulator/qcom,smd-rpm-regulator.yaml#
+ unevaluatedProperties: false
+
if:
properties:
compatible:
contains:
- enum:
- - qcom,rpm-apq8084
- - qcom,rpm-msm8916
- - qcom,rpm-msm8974
- - qcom,rpm-msm8953
+ const: qcom,smd-rpm
then:
+ properties:
+ qcom,glink-channels: false
required:
- qcom,smd-channels
+else:
+ properties:
+ qcom,smd-channels: false
+ required:
+ - qcom,glink-channels
required:
- compatible
@@ -84,16 +112,16 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
- smd {
- compatible = "qcom,smd";
+ remoteproc {
+ compatible = "qcom,msm8916-rpm-proc", "qcom,rpm-proc";
- rpm {
+ smd-edge {
interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
qcom,ipc = <&apcs 8 0>;
qcom,smd-edge = <15>;
rpm-requests {
- compatible = "qcom,rpm-msm8916";
+ compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
clock-controller {
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
index 9b3efe97f47c..b667f4afdb55 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.yaml
@@ -9,50 +9,31 @@ title: Qualcomm Shared Memory Driver
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description:
The Qualcomm Shared Memory Driver is a FIFO based communication channel for
sending data between the various subsystems in Qualcomm platforms.
+ Using the top-level SMD node is deprecated. Instead, the SMD edges are defined
+ directly below the device node representing the respective remote subsystem
+ or remote processor.
+
+deprecated: true
+
properties:
compatible:
const: qcom,smd
patternProperties:
- "^.*-edge|rpm$":
+ "^smd-edge|rpm$":
$ref: /schemas/remoteproc/qcom,smd-edge.yaml#
+ unevaluatedProperties: false
description:
Each subnode of the SMD node represents a remote subsystem or a remote
processor of some sort - or in SMD language an "edge". The name of the
edges are not important.
- properties:
- rpm-requests:
- type: object
- description:
- In turn, subnodes of the "edges" represent devices tied to SMD
- channels on that "edge". The names of the devices are not
- important. The properties of these nodes are defined by the
- individual bindings for the SMD devices.
-
- properties:
- qcom,smd-channels:
- $ref: /schemas/types.yaml#/definitions/string-array
- minItems: 1
- maxItems: 32
- description:
- A list of channels tied to this device, used for matching the
- device to channels.
-
- required:
- - compatible
- - qcom,smd-channels
-
- additionalProperties: true
-
- unevaluatedProperties: false
-
required:
- compatible
@@ -62,6 +43,7 @@ examples:
# The following example represents a smd node, with one edge representing the
# "rpm" subsystem. For the "rpm" subsystem we have a device tied to the
# "rpm_request" channel.
+ # NOTE: This is deprecated, represent the RPM using "qcom,rpm-proc" instead.
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -74,7 +56,7 @@ examples:
qcom,smd-edge = <15>;
rpm-requests {
- compatible = "qcom,rpm-msm8974";
+ compatible = "qcom,rpm-msm8974", "qcom,smd-rpm";
qcom,smd-channels = "rpm_requests";
clock-controller {
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml
index 4149cf2b66be..bc7815d985e4 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/qcom/qcom,smem.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/qcom/qcom,smem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Shared Memory Manager binding
+title: Qualcomm Shared Memory Manager
maintainers:
- Andy Gross <agross@kernel.org>
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml
index 795bd8cd4104..f91276822858 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml
@@ -9,7 +9,7 @@ title: Qualcomm Shared Memory Point 2 Point
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description:
The Shared Memory Point to Point (SMP2P) protocol facilitates communication
@@ -41,6 +41,7 @@ properties:
description:
Three entries specifying the outgoing ipc bit used for signaling the
remote end of the smp2p edge.
+ deprecated: true
qcom,local-pid:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -54,13 +55,12 @@ properties:
qcom,smem:
$ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- maxItems: 2
+ maxItems: 2
description:
Two identifiers of the inbound and outbound smem items used for this edge.
patternProperties:
- "^master-kernel|slave-kernel|ipa-ap-to-modem|ipa-modem-to-ap$":
+ "^master-kernel|slave-kernel|ipa-ap-to-modem|ipa-modem-to-ap|wlan-ap-to-wpss|wlan-wpss-to-ap$":
type: object
description:
Each SMP2P pair contain a set of inbound and outbound entries, these are
@@ -128,7 +128,7 @@ examples:
compatible = "qcom,smp2p";
qcom,smem = <431>, <451>;
interrupts = <GIC_SPI 143 IRQ_TYPE_EDGE_RISING>;
- qcom,ipc = <&apcs 8 18>;
+ mboxes = <&apcs 18>;
qcom,local-pid = <0>;
qcom,remote-pid = <4>;
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
index db67cf043256..67d4a7cb9eeb 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
@@ -9,7 +9,7 @@ title: Qualcomm Shared Memory State Machine
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description:
The Shared Memory State Machine facilitates broadcasting of single bit state
@@ -33,6 +33,14 @@ properties:
specifier of the column in the subscription matrix representing the local
processor.
+ mboxes:
+ minItems: 1
+ maxItems: 5
+ description:
+ Reference to the mailbox representing the outgoing doorbell in APCS for
+ this client. Each entry represents the N:th remote processor by index
+ (0-indexed).
+
'#size-cells':
const: 0
@@ -47,6 +55,7 @@ patternProperties:
description:
Three entries specifying the outgoing ipc bit used for signaling the N:th
remote processor.
+ deprecated: true
"@[0-9a-f]$":
type: object
@@ -98,15 +107,18 @@ required:
- '#address-cells'
- '#size-cells'
-anyOf:
- - required:
- - qcom,ipc-1
- - required:
- - qcom,ipc-2
- - required:
- - qcom,ipc-3
+oneOf:
- required:
- - qcom,ipc-4
+ - mboxes
+ - anyOf:
+ - required:
+ - qcom,ipc-1
+ - required:
+ - qcom,ipc-2
+ - required:
+ - qcom,ipc-3
+ - required:
+ - qcom,ipc-4
additionalProperties: false
@@ -122,7 +134,7 @@ examples:
compatible = "qcom,smsm";
#address-cells = <1>;
#size-cells = <0>;
- qcom,ipc-3 = <&apcs 8 19>;
+ mboxes = <0>, <0>, <0>, <&apcs 19>;
apps_smsm: apps@0 {
reg = <0>;
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml
deleted file mode 100644
index f433e6e0a19f..000000000000
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml
+++ /dev/null
@@ -1,82 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/soc/qcom/qcom,spm.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Qualcomm Subsystem Power Manager binding
-
-maintainers:
- - Andy Gross <agross@kernel.org>
- - Bjorn Andersson <bjorn.andersson@linaro.org>
-
-description: |
- This binding describes the Qualcomm Subsystem Power Manager, used to control
- the peripheral logic surrounding the application cores in Qualcomm platforms.
-
-properties:
- compatible:
- items:
- - enum:
- - qcom,sdm660-gold-saw2-v4.1-l2
- - qcom,sdm660-silver-saw2-v4.1-l2
- - qcom,msm8998-gold-saw2-v4.1-l2
- - qcom,msm8998-silver-saw2-v4.1-l2
- - qcom,msm8909-saw2-v3.0-cpu
- - qcom,msm8916-saw2-v3.0-cpu
- - qcom,msm8226-saw2-v2.1-cpu
- - qcom,msm8974-saw2-v2.1-cpu
- - qcom,apq8084-saw2-v2.1-cpu
- - qcom,apq8064-saw2-v1.1-cpu
- - const: qcom,saw2
-
- reg:
- description: Base address and size of the SPM register region
- maxItems: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
-
- /* Example 1: SoC using SAW2 and kpss-acc-v2 CPUIdle */
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- compatible = "qcom,kryo";
- device_type = "cpu";
- enable-method = "qcom,kpss-acc-v2";
- qcom,saw = <&saw0>;
- reg = <0x0>;
- operating-points-v2 = <&cpu_opp_table>;
- };
- };
-
- saw0: power-manager@f9089000 {
- compatible = "qcom,msm8974-saw2-v2.1-cpu", "qcom,saw2";
- reg = <0xf9089000 0x1000>;
- };
-
- - |
-
- /*
- * Example 2: New-gen multi cluster SoC using SAW only for L2;
- * This does not require any cpuidle driver, nor any cpu phandle.
- */
- power-manager@17812000 {
- compatible = "qcom,msm8998-gold-saw2-v4.1-l2", "qcom,saw2";
- reg = <0x17812000 0x1000>;
- };
-
- power-manager@17912000 {
- compatible = "qcom,msm8998-silver-saw2-v4.1-l2", "qcom,saw2";
- reg = <0x17912000 0x1000>;
- };
-
-...
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
index 5320504bb5e0..4fcae6bedfff 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
@@ -20,7 +20,7 @@ properties:
firmware-name:
$ref: /schemas/types.yaml#/definitions/string
- default: "wlan/prima/WCNSS_qcom_wlan_nv.bin"
+ default: wlan/prima/WCNSS_qcom_wlan_nv.bin
description:
Relative firmware image path for the WLAN NV blob.
@@ -42,21 +42,19 @@ properties:
bluetooth:
type: object
additionalProperties: false
+ allOf:
+ - $ref: /schemas/net/bluetooth/bluetooth-controller.yaml#
properties:
compatible:
const: qcom,wcnss-bt
- local-bd-address:
- $ref: /schemas/types.yaml#/definitions/uint8-array
- maxItems: 6
- description:
- See Documentation/devicetree/bindings/net/bluetooth.txt
+ local-bd-address: true
required:
- compatible
wifi:
- additionalProperties: false
+ unevaluatedProperties: false
type: object
properties:
compatible:
@@ -90,6 +88,9 @@ properties:
- qcom,smem-states
- qcom,smem-state-names
+ allOf:
+ - $ref: /schemas/net/wireless/wireless-controller.yaml#
+
required:
- compatible
- qcom,mmio
@@ -118,8 +119,8 @@ examples:
bluetooth {
compatible = "qcom,wcnss-bt";
- /* BD address 00:11:22:33:44:55 */
- local-bd-address = [ 55 44 33 22 11 00 ];
+ /* Updated by boot firmware (little-endian order) */
+ local-bd-address = [ 00 00 00 00 00 00 ];
};
wifi {
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml
index 48eda4d0d391..686a7ef2f48a 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/soc/qcom/qcom-stats.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies, Inc. (QTI) Stats bindings
+title: Qualcomm Technologies, Inc. (QTI) Stats
maintainers:
- - Maulik Shah <mkshah@codeaurora.org>
+ - Maulik Shah <quic_mkshah@quicinc.com>
description:
Always On Processor/Resource Power Manager maintains statistics of the SoC
@@ -31,10 +31,24 @@ properties:
reg:
maxItems: 1
+ qcom,qmp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Reference to the AOSS side-channel message RAM
+
required:
- compatible
- reg
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ const: qcom,rpmh-stats
+ then:
+ properties:
+ qcom,qmp: false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml
new file mode 100644
index 000000000000..1cac3cb5226c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g011-sys.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas,r9a09g011-sys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M System Configuration (SYS)
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+description:
+ The RZ/V2M-alike SYS (System Configuration) controls the overall
+ configuration of the LSI and supports the following functions,
+ - Bank address settings for DMAC
+ - Bank address settings of the units for ICB
+ - ETHER AxCACHE[1] (C bit) control function
+ - RAMA initialization control
+ - MD[7:0] pin monitoring
+ - LSI version
+ - PCIe related settings
+ - WDT stop control
+ - Temperature sensor (TSU) monitor
+
+properties:
+ compatible:
+ const: renesas,r9a09g011-sys
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ sys: system-controller@a3f03000 {
+ compatible = "renesas,r9a09g011-sys";
+ reg = <0xa3f03000 0x400>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml
new file mode 100644
index 000000000000..c41dcaea568a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas,r9a09g057-sys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2H(P) System Controller (SYS)
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+description: |
+ The RZ/V2H(P) SYS (System Controller) controls the overall
+ configuration of the LSI and supports the following functions,
+ - Trust zone control
+ - Extend access by specific masters to address beyond 4GB space
+ - GBETH configuration
+ - Control of settings and states of SRAM/PCIe/CM33/CA55/CR8/xSPI/ADC/TSU
+ - LSI version
+ - WDT stop control
+ - General registers
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a09g047-sys # RZ/G3E
+ - renesas,r9a09g056-sys # RZ/V2N
+ - renesas,r9a09g057-sys # RZ/V2H
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ sys: system-controller@10430000 {
+ compatible = "renesas,r9a09g057-sys";
+ reg = <0x10430000 0x10000>;
+ clocks = <&cpg 1>;
+ resets = <&cpg 1>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
index 398663d21ab1..4386b2c3fa4d 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/renesas/renesas,rzg2l-sysc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/renesas/renesas,rzg2l-sysc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/{G2L,V2L} System Controller (SYSC)
@@ -23,6 +23,7 @@ properties:
- renesas,r9a07g043-sysc # RZ/G2UL and RZ/Five
- renesas,r9a07g044-sysc # RZ/G2{L,LC}
- renesas,r9a07g054-sysc # RZ/V2L
+ - renesas,r9a08g045-sysc # RZ/G3S
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml
new file mode 100644
index 000000000000..12df33f58484
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzv2m-pwc.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas,rzv2m-pwc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M External Power Sequence Controller (PWC)
+
+description: |+
+ The PWC IP found in the RZ/V2M family of chips comes with the below
+ capabilities
+ - external power supply on/off sequence generation
+ - on/off signal generation for the LPDDR4 core power supply (LPVDD)
+ - key input signals processing
+ - general-purpose output pins
+
+maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a09g011-pwc # RZ/V2M
+ - renesas,r9a09g055-pwc # RZ/V2MA
+ - const: renesas,rzv2m-pwc
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ renesas,rzv2m-pwc-power:
+ description: The PWC is used to control the system power supplies.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ pwc: pwc@a3700000 {
+ compatible = "renesas,r9a09g011-pwc", "renesas,rzv2m-pwc";
+ reg = <0xa3700000 0x800>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ renesas,rzv2m-pwc-power;
+ };
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
new file mode 100644
index 000000000000..5ddd31f30f26
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas-soc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SoC compatibles naming convention
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+ - Niklas Söderlund <niklas.soderlund@ragnatech.se>
+
+description: |
+ Guidelines for new compatibles for SoC blocks/components.
+ When adding new compatibles in new bindings, use the format::
+ renesas,SoC-IP
+
+ For example::
+ renesas,r8a77965-csi2
+
+ When adding new compatibles to existing bindings, use the format in the
+ existing binding, even if it contradicts the above.
+
+select:
+ properties:
+ compatible:
+ contains:
+ pattern: "^renesas,.+-.+$"
+ required:
+ - compatible
+
+properties:
+ compatible:
+ minItems: 1
+ maxItems: 4
+ items:
+ anyOf:
+ # Preferred naming style for compatibles of SoC components
+ - pattern: "^renesas,(emev2|r(7s|8a|9a)[a-z0-9]+|rcar|rmobile|rz[a-z0-9]*|sh(7[a-z0-9]+)?|mobile)-[a-z0-9-]+$"
+ - pattern: "^renesas,(condor|falcon|gr-peach|gray-hawk|salvator|sk-rz|smar(c(2)?)?|spider|white-hawk)(.*)?$"
+
+ # Legacy compatibles
+ #
+ # New compatibles are not allowed.
+ - pattern: "^renesas,(can|cpg|dmac|du|(g)?ether(avb)?|gpio|hscif|(r)?i[i2]c|imr|intc|ipmmu|irqc|jpu|mmcif|msiof|mtu2|pci(e)?|pfc|pwm|[rq]spi|rcar_sound|sata|scif[ab]*|sdhi|thermal|tmu|tpu|usb(2|hs)?|vin|xhci)-[a-z0-9-]+$"
+ - pattern: "^renesas,(d|s)?bsc(3)?-(r8a73a4|r8a7740|sh73a0)$"
+ - pattern: "^renesas,em-(gio|sti|uart)$"
+ - pattern: "^renesas,fsi2-(r8a7740|sh73a0)$"
+ - pattern: "^renesas,hspi-r8a777[89]$"
+ - pattern: "^renesas,sysc-(r8a73a4|r8a7740|rmobile|sh73a0)$"
+ - enum:
+ - renesas,imr-lx4
+ - renesas,mtu2-r7s72100
+
+ # None SoC component compatibles
+ #
+ # Compatibles with the Renesas vendor prefix that do not relate to any SoC
+ # component are OK. New compatibles are allowed.
+ - enum:
+ - renesas,smp-sram
+
+ # Do not fail compatibles not matching the select pattern
+ #
+ # Some SoC components in addition to a Renesas compatible list
+ # compatibles not related to Renesas. The select pattern for this
+ # schema hits all compatibles that have at lest one Renesas compatible
+ # and try to validate all values in that compatible array, allow all
+ # that don't match the schema select pattern. For example,
+ #
+ # compatible = "renesas,r9a07g044-mali", "arm,mali-bifrost";
+ - pattern: "^(?!renesas,.+-.+).+$"
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
new file mode 100644
index 000000000000..f4947ac65460
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
@@ -0,0 +1,630 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/renesas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH-Mobile, R-Mobile, and R-Car Platform
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Emma Mobile EV2
+ items:
+ - enum:
+ - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual
+ - const: renesas,emev2
+
+ - description: RZ/A1H (R7S72100)
+ items:
+ - enum:
+ - renesas,genmai # Genmai (RTK772100BC00000BR)
+ - renesas,gr-peach # GR-Peach (X28A-M01-E/F)
+ - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE)
+ - const: renesas,r7s72100
+
+ - description: RZ/A2 (R7S9210)
+ items:
+ - enum:
+ - renesas,rza2mevb # RZ/A2M Eval Board (RTK7921053S00000BE)
+ - const: renesas,r7s9210
+
+ - description: SH-Mobile AG5 (R8A73A00/SH73A0)
+ items:
+ - enum:
+ - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT
+ - const: renesas,sh73a0
+
+ - description: R-Mobile APE6 (R8A73A40)
+ items:
+ - enum:
+ - renesas,ape6evm
+ - const: renesas,r8a73a4
+
+ - description: R-Mobile A1 (R8A77400)
+ items:
+ - enum:
+ - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA
+ - const: renesas,r8a7740
+
+ - description: RZ/G1H (R8A77420)
+ items:
+ - enum:
+ # iWave Systems RZ/G1H Qseven System On Module (iW-RainboW-G21M-Qseven)
+ - iwave,g21m
+ - const: renesas,r8a7742
+
+ - items:
+ - enum:
+ # iWave Systems RZ/G1H Qseven Development Platform (iW-RainboW-G21D-Qseven)
+ - iwave,g21d
+ - const: iwave,g21m
+ - const: renesas,r8a7742
+
+ - description: RZ/G1M (R8A77430)
+ items:
+ - enum:
+ # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven)
+ - iwave,g20d
+ - const: iwave,g20m
+ - const: renesas,r8a7743
+
+ - items:
+ - enum:
+ # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
+ - iwave,g20m
+ - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE)
+ - const: renesas,r8a7743
+
+ - description: RZ/G1N (R8A77440)
+ items:
+ - enum:
+ # iWave Systems RZ/G1N Qseven Development Platform (iW-RainboW-G20D-Qseven)
+ - iwave,g20d
+ - const: iwave,g20m
+ - const: renesas,r8a7744
+
+ - items:
+ - enum:
+ # iWave Systems RZ/G1N Qseven System On Module (iW-RainboW-G20M-Qseven)
+ - iwave,g20m
+ - const: renesas,r8a7744
+
+ - description: RZ/G1E (R8A77450)
+ items:
+ - enum:
+ - iwave,g22m # iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM)
+ - renesas,sk-rzg1e # SK-RZG1E (YR8A77450S000BE)
+ - const: renesas,r8a7745
+
+ - description: iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D)
+ items:
+ - const: iwave,g22d
+ - const: iwave,g22m
+ - const: renesas,r8a7745
+
+ - description: RZ/G1C (R8A77470)
+ items:
+ - enum:
+ - iwave,g23s # iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S)
+ - const: renesas,r8a77470
+
+ - description: RZ/G2M (R8A774A1)
+ items:
+ - enum:
+ - hoperun,hihope-rzg2m # HopeRun HiHope RZ/G2M platform
+ - beacon,beacon-rzg2m # Beacon EmbeddedWorks RZ/G2M Kit
+ - const: renesas,r8a774a1
+
+ - items:
+ - enum:
+ - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
+ - const: hoperun,hihope-rzg2m
+ - const: renesas,r8a774a1
+
+ - description: RZ/G2M v3.0 (R8A774A3)
+ items:
+ - enum:
+ - hoperun,hihope-rzg2m # HopeRun HiHope RZ/G2M platform
+ - const: renesas,r8a774a3
+
+ - items:
+ - enum:
+ - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
+ - const: hoperun,hihope-rzg2m
+ - const: renesas,r8a774a3
+
+ - description: RZ/G2N (R8A774B1)
+ items:
+ - enum:
+ - beacon,beacon-rzg2n # Beacon EmbeddedWorks RZ/G2N Kit
+ - hoperun,hihope-rzg2n # HopeRun HiHope RZ/G2N platform
+ - const: renesas,r8a774b1
+
+ - items:
+ - enum:
+ - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
+ - const: hoperun,hihope-rzg2n
+ - const: renesas,r8a774b1
+
+ - description: RZ/G2E (R8A774C0)
+ items:
+ - enum:
+ - si-linux,cat874 # Silicon Linux RZ/G2E 96board platform (CAT874)
+ - const: renesas,r8a774c0
+
+ - items:
+ - enum:
+ - si-linux,cat875 # Silicon Linux sub board for CAT874 (CAT875)
+ - const: si-linux,cat874
+ - const: renesas,r8a774c0
+
+ - description: RZ/G2H (R8A774E1)
+ items:
+ - enum:
+ - beacon,beacon-rzg2h # Beacon EmbeddedWorks RZ/G2H Kit
+ - hoperun,hihope-rzg2h # HopeRun HiHope RZ/G2H platform
+ - const: renesas,r8a774e1
+
+ - items:
+ - enum:
+ - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
+ - const: hoperun,hihope-rzg2h
+ - const: renesas,r8a774e1
+
+ - description: R-Car M1A (R8A77781)
+ items:
+ - enum:
+ - renesas,bockw
+ - const: renesas,r8a7778
+
+ - description: R-Car H1 (R8A77790)
+ items:
+ - enum:
+ - renesas,marzen # Marzen (R0P7779A00010S)
+ - const: renesas,r8a7779
+
+ - description: R-Car H2 (R8A77900)
+ items:
+ - enum:
+ - renesas,lager # Lager (RTP0RC7790SEB00010S)
+ - renesas,stout # Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD)
+ - const: renesas,r8a7790
+
+ - description: R-Car M2-W (R8A77910)
+ items:
+ - enum:
+ - renesas,henninger
+ - renesas,koelsch # Koelsch (RTP0RC7791SEB00010S)
+ - renesas,porter # Porter (M2-LCDP)
+ - const: renesas,r8a7791
+
+ - description: R-Car V2H (R8A77920)
+ items:
+ - enum:
+ - renesas,blanche # Blanche (RTP0RC7792SEB00010S)
+ - renesas,wheat # Wheat (RTP0RC7792ASKB0000JE)
+ - const: renesas,r8a7792
+
+ - description: R-Car M2-N (R8A77930)
+ items:
+ - enum:
+ - renesas,gose # Gose (RTP0RC7793SEB00010S)
+ - const: renesas,r8a7793
+
+ - description: R-Car E2 (R8A77940)
+ items:
+ - enum:
+ - renesas,alt # Alt (RTP0RC7794SEB00010S)
+ - renesas,silk # SILK (RTP0RC7794LCB00011S)
+ - const: renesas,r8a7794
+
+ # Note: R-Car H3 ES1.* (R8A77950) is not supported upstream anymore!
+
+ - description: R-Car H3 ES2.0 and later (R8A77951)
+ items:
+ - enum:
+ - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0))
+ - renesas,salvator-x # Salvator-X (RTP0RC7795SIPB0010S)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
+ - const: renesas,r8a7795
+
+ - description: R-Car M3-W (R8A77960)
+ items:
+ - enum:
+ - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
+ - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
+ - const: renesas,r8a7796
+
+ - description: R-Car M3-W+ (R8A77961)
+ items:
+ - enum:
+ - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP8J77961ASKB0SK0SA05A (M3 ES3.0))
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012SA5A)
+ - const: renesas,r8a77961
+
+ - description: Kingfisher (SBEV-RCAR-KF-M03)
+ oneOf:
+ - items:
+ - const: shimafuji,kingfisher
+ - enum:
+ - renesas,h3ulcb
+ - renesas,m3ulcb
+ - renesas,m3nulcb
+ - enum:
+ - renesas,r8a7795
+ - renesas,r8a7796
+ - renesas,r8a77961
+ - renesas,r8a77965
+ - items:
+ - const: shimafuji,kingfisher
+ - enum:
+ - renesas,h3ulcb
+ - renesas,m3ulcb
+ - renesas,m3nulcb
+ - enum:
+ - renesas,r8a779m0
+ - renesas,r8a779m1
+ - renesas,r8a779m2
+ - renesas,r8a779m3
+ - renesas,r8a779m4
+ - renesas,r8a779m5
+ - renesas,r8a779m8
+ - renesas,r8a779mb
+ - enum:
+ - renesas,r8a7795
+ - renesas,r8a77961
+ - renesas,r8a77965
+
+ - description: R-Car M3-N (R8A77965)
+ items:
+ - enum:
+ - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
+ - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S (M3-N))
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S)
+ - const: renesas,r8a77965
+
+ - description: R-Car V3M (R8A77970)
+ items:
+ - enum:
+ - renesas,eagle # Eagle (RTP0RC77970SEB0010S)
+ - renesas,v3msk # V3MSK (Y-ASK-RCAR-V3M-WS10)
+ - const: renesas,r8a77970
+
+ - description: R-Car V3H (R8A77980)
+ items:
+ - enum:
+ - renesas,condor # Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01)
+ - renesas,v3hsk # V3HSK (Y-ASK-RCAR-V3H-WS10)
+ - const: renesas,r8a77980
+
+ - description: R-Car V3H2 (R8A77980A)
+ items:
+ - enum:
+ - renesas,condor-i # Condor-I (RTP0RC77980SEBS012SA01)
+ - const: renesas,r8a77980a
+ - const: renesas,r8a77980
+
+ - description: R-Car E3 (R8A77990)
+ items:
+ - enum:
+ - renesas,ebisu # Ebisu (RTP0RC77990SEB0010S), Ebisu-4D (RTP0RC77990SEB0020S)
+ - const: renesas,r8a77990
+
+ - description: R-Car D3 (R8A77995)
+ items:
+ - enum:
+ - renesas,draak # Draak (RTP0RC77995SEB0010S)
+ - const: renesas,r8a77995
+
+ - description: R-Car V3U (R8A779A0)
+ items:
+ - enum:
+ - renesas,falcon-cpu # Falcon CPU board (RTP0RC779A0CPB0010S)
+ - const: renesas,r8a779a0
+
+ - items:
+ - enum:
+ - renesas,falcon-breakout # Falcon BreakOut board (RTP0RC779A0BOB0010S)
+ - const: renesas,falcon-cpu
+ - const: renesas,r8a779a0
+
+ - description: R-Car S4-8 (R8A779F0)
+ items:
+ - enum:
+ - renesas,spider-cpu # Spider CPU board (RTP8A779F0ASKB0SC2S)
+ - const: renesas,r8a779f0
+
+ - items:
+ - enum:
+ - renesas,spider-breakout # Spider BreakOut board (RTP8A779F0ASKB0SB0S)
+ - const: renesas,spider-cpu
+ - const: renesas,r8a779f0
+
+ - description: R-Car S4-8 (R8A779F4)
+ items:
+ - enum:
+ - renesas,s4sk # R-Car S4 Starter Kit board (Y-ASK-RCAR-S4-1000BASE-T#WS12)
+ - const: renesas,r8a779f4
+ - const: renesas,r8a779f0
+
+ - description: R-Car V4H (R8A779G0)
+ items:
+ - enum:
+ - renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000)
+ - const: renesas,r8a779g0
+
+ - items:
+ - enum:
+ - renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000)
+ - const: renesas,white-hawk-cpu
+ - const: renesas,r8a779g0
+
+ - description: R-Car V4H (R8A779G[23])
+ items:
+ - enum:
+ - renesas,white-hawk-single # White Hawk Single board (RTP8A779G[23]ASKB0F10SA001)
+ - enum:
+ - renesas,r8a779g2 # ES2.x
+ - renesas,r8a779g3 # ES3.x
+ - const: renesas,r8a779g0
+
+ - description: R-Car V4H (R8A779G3)
+ items:
+ - enum:
+ - retronix,sparrow-hawk # Sparrow Hawk board
+ - const: renesas,r8a779g3 # ES3.x
+ - const: renesas,r8a779g0
+
+ - description: R-Car V4M (R8A779H0)
+ items:
+ - enum:
+ - renesas,gray-hawk-single # Gray Hawk Single board (RTP8A779H0ASKB0F10S)
+ - const: renesas,r8a779h0
+
+ - description: R-Car V4M-7 (R8A779H2)
+ items:
+ - enum:
+ - renesas,gray-hawk-single # Gray Hawk Single board (RTP8A779H2ASKB0F10SA001)
+ - const: renesas,r8a779h2 # ES2.x
+ - const: renesas,r8a779h0
+
+ - description: R-Car H3e (R8A779M0)
+ items:
+ - enum:
+ - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m0
+ - const: renesas,r8a7795
+
+ - description: R-Car H3e-2G (R8A779M1)
+ items:
+ - enum:
+ - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m1
+ - const: renesas,r8a7795
+
+ - description: R-Car M3e (R8A779M2)
+ items:
+ - enum:
+ - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m2
+ - const: renesas,r8a77961
+
+ - description: R-Car M3e-2G (R8A779M3)
+ items:
+ - enum:
+ - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m3
+ - const: renesas,r8a77961
+
+ - description: R-Car M3Ne (R8A779M4)
+ items:
+ - enum:
+ - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m4
+ - const: renesas,r8a77965
+
+ - description: R-Car M3Ne-2G (R8A779M5)
+ items:
+ - enum:
+ - renesas,m3nulcb # M3NULCB (R-Car Starter Kit Pro)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m5
+ - const: renesas,r8a77965
+
+ - description: R-Car E3e (R8A779M6)
+ items:
+ - enum:
+ - renesas,ebisu # Ebisu
+ - const: renesas,r8a779m6
+ - const: renesas,r8a77990
+
+ - description: R-Car D3e (R8A779M7)
+ items:
+ - enum:
+ - renesas,draak # Draak
+ - const: renesas,r8a779m7
+ - const: renesas,r8a77995
+
+ - description: R-Car H3Ne (R8A779M8)
+ items:
+ - enum:
+ - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779m8
+ - const: renesas,r8a7795
+
+ - description: R-Car H3Ne-1.7G (R8A779MB)
+ items:
+ - enum:
+ - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier)
+ - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
+ - const: renesas,r8a779mb
+ - const: renesas,r8a7795
+
+ - description: R-Car X5H (R8A78000)
+ items:
+ - enum:
+ - renesas,ironhide # Ironhide (RTP8A78000ASKB0F10S)
+ - const: renesas,r8a78000
+
+ - description: RZ/N1D (R9A06G032)
+ items:
+ - enum:
+ - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package)
+ - const: renesas,r9a06g032
+
+ - description: RZ/N1{D,S} EB
+ items:
+ - enum:
+ - renesas,rzn1d400-eb # RZN1D-EB (Expansion Board when using a RZN1D-DB)
+ - const: renesas,rzn1d400-db
+ - const: renesas,r9a06g032
+
+ - description: RZ/Five and RZ/G2UL (R9A07G043)
+ items:
+ - enum:
+ - renesas,smarc-evk # SMARC EVK
+ - enum:
+ - renesas,r9a07g043f01 # RZ/Five
+ - renesas,r9a07g043u11 # RZ/G2UL Type-1
+ - renesas,r9a07g043u12 # RZ/G2UL Type-2
+ - const: renesas,r9a07g043
+
+ - description: RZ/G2{L,LC} (R9A07G044)
+ items:
+ - enum:
+ - renesas,smarc-evk # SMARC EVK
+ - enum:
+ - renesas,r9a07g044c1 # Single Cortex-A55 RZ/G2LC
+ - renesas,r9a07g044c2 # Dual Cortex-A55 RZ/G2LC
+ - renesas,r9a07g044l1 # Single Cortex-A55 RZ/G2L
+ - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L
+ - const: renesas,r9a07g044
+
+ - items:
+ - enum:
+ # MYIR Remi Pi SBC (MYB-YG2LX-REMI)
+ - myir,remi-pi
+ - const: renesas,r9a07g044l2
+ - const: renesas,r9a07g044
+
+ - description: RZ/V2L (R9A07G054)
+ items:
+ - enum:
+ - renesas,smarc-evk # SMARC EVK
+ - enum:
+ - renesas,r9a07g054l1 # Single Cortex-A55 RZ/V2L
+ - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L
+ - const: renesas,r9a07g054
+
+ - description: RZ/G3S (R9A08G045)
+ items:
+ - enum:
+ - renesas,r9a08g045s33 # PCIe support
+ - const: renesas,r9a08g045
+
+ - description: RZ/G3S SMARC Module (SoM)
+ items:
+ - const: renesas,rzg3s-smarcm # RZ/G3S SMARC Module (SoM)
+ - const: renesas,r9a08g045s33 # PCIe support
+ - const: renesas,r9a08g045
+
+ - description: RZ SMARC Carrier-II Evaluation Kit
+ items:
+ - const: renesas,smarc2-evk # RZ SMARC Carrier-II EVK
+ - const: renesas,rzg3s-smarcm # RZ/G3S SMARC SoM
+ - const: renesas,r9a08g045s33 # PCIe support
+ - const: renesas,r9a08g045
+
+ - description: RZ/V2M (R9A09G011)
+ items:
+ - enum:
+ - renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0
+ - const: renesas,r9a09g011
+
+ - description: RZ/G3E (R9A09G047)
+ items:
+ - enum:
+ - renesas,smarc2-evk # RZ SMARC Carrier-II EVK
+ - enum:
+ - renesas,rzg3e-smarcm # RZ/G3E SMARC Module (SoM)
+ - enum:
+ - renesas,r9a09g047e27 # Dual Cortex-A55 + Cortex-M33 (15mm BGA)
+ - renesas,r9a09g047e28 # Dual Cortex-A55 + Cortex-M33 (21mm BGA)
+ - renesas,r9a09g047e37 # Dual Cortex-A55 + Cortex-M33 + Ethos-U55 (15mm BGA)
+ - renesas,r9a09g047e38 # Dual Cortex-A55 + Cortex-M33 + Ethos-U55 (21mm BGA)
+ - renesas,r9a09g047e47 # Quad Cortex-A55 + Cortex-M33 (15mm BGA)
+ - renesas,r9a09g047e48 # Quad Cortex-A55 + Cortex-M33 (21mm BGA)
+ - renesas,r9a09g047e57 # Quad Cortex-A55 + Cortex-M33 + Ethos-U55 (15mm BGA)
+ - renesas,r9a09g047e58 # Quad Cortex-A55 + Cortex-M33 + Ethos-U55 (21mm BGA)
+ - const: renesas,r9a09g047
+
+ - description: RZ/V2N (R9A09G056)
+ items:
+ - enum:
+ - renesas,rzv2n-evk # RZ/V2N EVK (RTK0EF0186C03000BJ)
+ - enum:
+ - renesas,r9a09g056n41 # RZ/V2N
+ - renesas,r9a09g056n42 # RZ/V2N with Mali-G31 support
+ - renesas,r9a09g056n43 # RZ/V2N with Mali-C55 support
+ - renesas,r9a09g056n44 # RZ/V2N with Mali-G31 + Mali-C55 support
+ - renesas,r9a09g056n45 # RZ/V2N with cryptographic extension support
+ - renesas,r9a09g056n46 # RZ/V2N with Mali-G31 + cryptographic extension support
+ - renesas,r9a09g056n47 # RZ/V2N with Mali-C55 + cryptographic extension support
+ - renesas,r9a09g056n48 # RZ/V2N with Mali-G31 + Mali-C55 + cryptographic extension support
+ - const: renesas,r9a09g056
+
+ - description: RZ/V2H(P) (R9A09G057)
+ items:
+ - enum:
+ - renesas,rzv2h-evk # RZ/V2H EVK (RTK0EF0168C06001BJ)
+ - enum:
+ - renesas,r9a09g057h41 # RZ/V2H
+ - renesas,r9a09g057h42 # RZ/V2H with Mali-G31 support
+ - renesas,r9a09g057h44 # RZ/V2HP with Mali-G31 + Mali-C55 support
+ - renesas,r9a09g057h45 # RZ/V2H with cryptographic extension support
+ - renesas,r9a09g057h46 # RZ/V2H with Mali-G31 + cryptographic extension support
+ - renesas,r9a09g057h48 # RZ/V2HP with Mali-G31 + Mali-C55 + cryptographic extension support
+ - const: renesas,r9a09g057
+
+ - description: Yuridenki-Shokai RZ/V2H Kakip
+ items:
+ - const: yuridenki,kakip
+ - const: renesas,r9a09g057h48
+ - const: renesas,r9a09g057
+
+ - description: RZ/T2H (R9A09G077)
+ items:
+ - enum:
+ - renesas,rzt2h-evk # RZ/T2H Evaluation Board (RTK9RZT2H0S00000BJ)
+ - enum:
+ - renesas,r9a09g077m04 # RZ/T2H with Single Cortex-A55 + Dual Cortex-R52 - no security
+ - renesas,r9a09g077m24 # RZ/T2H with Dual Cortex-A55 + Dual Cortex-R52 - no security
+ - renesas,r9a09g077m44 # RZ/T2H with Quad Cortex-A55 + Dual Cortex-R52 - no security
+ - const: renesas,r9a09g077
+
+ - description: RZ/N2H (R9A09G087)
+ items:
+ - enum:
+ - renesas,rzn2h-evk # RZ/N2H Evaluation Board (RTK9RZN2H0S00000BJ)
+ - enum:
+ - renesas,r9a09g087m04 # RZ/N2H with Single Cortex-A55 + Dual Cortex-R52 - no security
+ - renesas,r9a09g087m24 # RZ/N2H with Dual Cortex-A55 + Dual Cortex-R52 - no security
+ - renesas,r9a09g087m44 # RZ/N2H with Quad Cortex-A55 + Dual Cortex-R52 - no security
+ - const: renesas,r9a09g087
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
index 2ed8cca79b59..0b8e3294c83e 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -15,16 +15,62 @@ properties:
- items:
- enum:
- rockchip,rk3288-sgrf
+ - rockchip,rk3528-ioc-grf
+ - rockchip,rk3528-pipe-phy-grf
+ - rockchip,rk3528-vo-grf
+ - rockchip,rk3528-vpu-grf
+ - rockchip,rk3562-ioc-grf
+ - rockchip,rk3562-peri-grf
+ - rockchip,rk3562-pipephy-grf
+ - rockchip,rk3562-pmu-grf
+ - rockchip,rk3562-sys-grf
+ - rockchip,rk3562-usbphy-grf
- rockchip,rk3566-pipe-grf
- rockchip,rk3568-pcie3-phy-grf
- rockchip,rk3568-pipe-grf
- rockchip,rk3568-pipe-phy-grf
- rockchip,rk3568-usb2phy-grf
+ - rockchip,rk3576-bigcore-grf
+ - rockchip,rk3576-cci-grf
+ - rockchip,rk3576-dcphy-grf
+ - rockchip,rk3576-gpu-grf
+ - rockchip,rk3576-hdptxphy-grf
+ - rockchip,rk3576-litcore-grf
+ - rockchip,rk3576-npu-grf
+ - rockchip,rk3576-php-grf
+ - rockchip,rk3576-pipe-phy-grf
+ - rockchip,rk3576-pmu1-grf
+ - rockchip,rk3576-sdgmac-grf
+ - rockchip,rk3576-sys-grf
+ - rockchip,rk3576-usb-grf
+ - rockchip,rk3576-usbdpphy-grf
+ - rockchip,rk3576-vo0-grf
+ - rockchip,rk3576-vo1-grf
+ - rockchip,rk3576-vop-grf
+ - rockchip,rk3588-bigcore0-grf
+ - rockchip,rk3588-bigcore1-grf
+ - rockchip,rk3588-csidphy-grf
+ - rockchip,rk3588-dcphy-grf
+ - rockchip,rk3588-hdptxphy-grf
+ - rockchip,rk3588-ioc
+ - rockchip,rk3588-php-grf
+ - rockchip,rk3588-pipe-phy-grf
+ - rockchip,rk3588-sys-grf
- rockchip,rk3588-pcie3-phy-grf
- rockchip,rk3588-pcie3-pipe-grf
+ - rockchip,rk3588-usb-grf
+ - rockchip,rk3588-usbdpphy-grf
+ - rockchip,rk3588-vo0-grf
+ - rockchip,rk3588-vo1-grf
+ - rockchip,rk3588-vop-grf
- rockchip,rv1108-usbgrf
- const: syscon
- items:
+ - const: rockchip,rk3588-vo-grf
+ - const: syscon
+ deprecated: true
+ description: Use rockchip,rk3588-vo{0,1}-grf instead.
+ - items:
- enum:
- rockchip,px30-grf
- rockchip,px30-pmugrf
@@ -45,8 +91,13 @@ properties:
- rockchip,rk3368-pmugrf
- rockchip,rk3399-grf
- rockchip,rk3399-pmugrf
+ - rockchip,rk3562-pmu-grf
- rockchip,rk3568-grf
- rockchip,rk3568-pmugrf
+ - rockchip,rk3576-ioc-grf
+ - rockchip,rk3576-pmu0-grf
+ - rockchip,rk3576-usb2phy-grf
+ - rockchip,rk3588-usb2phy-grf
- rockchip,rv1108-grf
- rockchip,rv1108-pmugrf
- rockchip,rv1126-grf
@@ -57,6 +108,9 @@ properties:
reg:
maxItems: 1
+ clocks:
+ maxItems: 1
+
"#address-cells":
const: 1
@@ -75,13 +129,17 @@ allOf:
properties:
compatible:
contains:
- const: rockchip,px30-grf
+ enum:
+ - rockchip,px30-grf
then:
properties:
lvds:
- description:
- Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+ type: object
+
+ $ref: /schemas/display/rockchip/rockchip,lvds.yaml#
+
+ unevaluatedProperties: false
- if:
properties:
@@ -92,8 +150,9 @@ allOf:
then:
properties:
edp-phy:
- description:
- Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+ type: object
+ $ref: /schemas/phy/rockchip,rk3288-dp-phy.yaml#
+ unevaluatedProperties: false
- if:
properties:
@@ -109,7 +168,7 @@ allOf:
usbphy:
type: object
- $ref: "/schemas/phy/rockchip-usb-phy.yaml#"
+ $ref: /schemas/phy/rockchip-usb-phy.yaml#
unevaluatedProperties: false
@@ -123,15 +182,17 @@ allOf:
properties:
gpio:
type: object
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3328-grf-gpio
- $ref: "/schemas/gpio/rockchip,rk3328-grf-gpio.yaml#"
-
- unevaluatedProperties: false
+ additionalProperties: true
power-controller:
type: object
- $ref: "/schemas/power/rockchip,power-controller.yaml#"
+ $ref: /schemas/power/rockchip,power-controller.yaml#
unevaluatedProperties: false
@@ -146,18 +207,20 @@ allOf:
mipi-dphy-rx0:
type: object
- $ref: "/schemas/phy/rockchip-mipi-dphy-rx0.yaml#"
+ $ref: /schemas/phy/rockchip-mipi-dphy-rx0.yaml#
unevaluatedProperties: false
pcie-phy:
- description:
- Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
+ type: object
+ $ref: /schemas/phy/rockchip,rk3399-pcie-phy.yaml#
+ unevaluatedProperties: false
patternProperties:
- "phy@[0-9a-f]+$":
- description:
- Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
+ "^phy@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/phy/rockchip,rk3399-emmc-phy.yaml#
+ unevaluatedProperties: false
- if:
properties:
@@ -174,7 +237,7 @@ allOf:
reboot-mode:
type: object
- $ref: "/schemas/power/reset/syscon-reboot-mode.yaml#"
+ $ref: /schemas/power/reset/syscon-reboot-mode.yaml#
unevaluatedProperties: false
@@ -189,6 +252,8 @@ allOf:
- rockchip,rk3308-usb2phy-grf
- rockchip,rk3328-usb2phy-grf
- rockchip,rk3399-grf
+ - rockchip,rk3576-usb2phy-grf
+ - rockchip,rk3588-usb2phy-grf
- rockchip,rv1108-grf
then:
@@ -200,7 +265,7 @@ allOf:
"usb2phy@[0-9a-f]+$":
type: object
- $ref: "/schemas/phy/phy-rockchip-inno-usb2.yaml#"
+ $ref: /schemas/phy/rockchip,inno-usb2phy.yaml#
unevaluatedProperties: false
@@ -220,6 +285,7 @@ allOf:
- rockchip,rk3399-grf
- rockchip,rk3399-pmugrf
- rockchip,rk3568-pmugrf
+ - rockchip,rk3588-pmugrf
- rockchip,rv1108-grf
- rockchip,rv1108-pmugrf
@@ -228,10 +294,29 @@ allOf:
io-domains:
type: object
- $ref: "/schemas/power/rockchip-io-domain.yaml#"
+ $ref: /schemas/power/rockchip-io-domain.yaml#
unevaluatedProperties: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3576-dcphy-grf
+ - rockchip,rk3576-vo1-grf
+ - rockchip,rk3588-vo-grf
+ - rockchip,rk3588-vo0-grf
+ - rockchip,rk3588-vo1-grf
+
+ then:
+ required:
+ - clocks
+
+ else:
+ properties:
+ clocks: false
+
examples:
- |
#include <dt-bindings/clock/rk3399-cru.h>
@@ -253,6 +338,24 @@ examples:
#phy-cells = <0>;
};
+ pcie-phy {
+ compatible = "rockchip,rk3399-pcie-phy";
+ #phy-cells = <1>;
+ clocks = <&cru SCLK_PCIEPHY_REF>;
+ clock-names = "refclk";
+ resets = <&cru SRST_PCIEPHY>;
+ reset-names = "phy";
+ };
+
+ phy@f780 {
+ compatible = "rockchip,rk3399-emmc-phy";
+ reg = <0xf780 0x20>;
+ clocks = <&sdhci>;
+ clock-names = "emmcclk";
+ drive-impedance-ohm = <50>;
+ #phy-cells = <0>;
+ };
+
u2phy0: usb2phy@e450 {
compatible = "rockchip,rk3399-usb2phy";
reg = <0xe450 0x10>;
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 13bb8dfcefe6..6de47489ee42 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -15,8 +15,10 @@ select:
compatible:
contains:
enum:
+ - google,gs101-pmu
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5260-pmu
@@ -31,20 +33,48 @@ select:
properties:
compatible:
- items:
- - enum:
- - samsung,exynos3250-pmu
- - samsung,exynos4210-pmu
- - samsung,exynos4412-pmu
- - samsung,exynos5250-pmu
- - samsung,exynos5260-pmu
- - samsung,exynos5410-pmu
- - samsung,exynos5420-pmu
- - samsung,exynos5433-pmu
- - samsung,exynos7-pmu
- - samsung,exynos850-pmu
- - samsung-s5pv210-pmu
- - const: syscon
+ oneOf:
+ - items:
+ - enum:
+ - google,gs101-pmu
+ - samsung,exynos3250-pmu
+ - samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
+ - samsung,exynos4412-pmu
+ - samsung,exynos5250-pmu
+ - samsung,exynos5260-pmu
+ - samsung,exynos5410-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - samsung,exynos7-pmu
+ - samsung,exynos850-pmu
+ - samsung-s5pv210-pmu
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos2200-pmu
+ - samsung,exynos7870-pmu
+ - samsung,exynos7885-pmu
+ - samsung,exynos8890-pmu
+ - samsung,exynos8895-pmu
+ - samsung,exynos9810-pmu
+ - samsung,exynos990-pmu
+ - samsung,exynosautov9-pmu
+ - samsung,exynosautov920-pmu
+ - tesla,fsd-pmu
+ - const: samsung,exynos7-pmu
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos3250-pmu
+ - samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
+ - samsung,exynos4412-pmu
+ - samsung,exynos5250-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - const: simple-mfd
+ - const: syscon
reg:
maxItems: 1
@@ -64,6 +94,10 @@ properties:
minItems: 1
maxItems: 32
+ dp-phy:
+ $ref: /schemas/phy/samsung,dp-video-phy.yaml
+ unevaluatedProperties: false
+
interrupt-controller:
description:
Some PMUs are capable of behaving as an interrupt controller (mostly
@@ -74,6 +108,10 @@ properties:
Must be identical to the that of the parent interrupt controller.
const: 3
+ mipi-phy:
+ $ref: /schemas/phy/samsung,mipi-video-phy.yaml
+ unevaluatedProperties: false
+
reboot-mode:
$ref: /schemas/power/reset/syscon-reboot-mode.yaml
type: object
@@ -92,6 +130,11 @@ properties:
description:
Node for reboot method
+ google,pmu-intr-gen-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to PMU interrupt generation interface.
+
required:
- compatible
- reg
@@ -106,6 +149,7 @@ allOf:
enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5410-pmu
@@ -117,6 +161,54 @@ allOf:
- clock-names
- clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos3250-pmu
+ - samsung,exynos4210-pmu
+ - samsung,exynos4212-pmu
+ - samsung,exynos4412-pmu
+ - samsung,exynos5250-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ - samsung,exynos7870-pmu
+ then:
+ properties:
+ mipi-phy: true
+ else:
+ properties:
+ mipi-phy: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5250-pmu
+ - samsung,exynos5420-pmu
+ - samsung,exynos5433-pmu
+ then:
+ properties:
+ dp-phy: true
+ else:
+ properties:
+ dp-phy: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-pmu
+ then:
+ required:
+ - google,pmu-intr-gen-syscon
+ else:
+ properties:
+ google,pmu-intr-gen-syscon: false
+
examples:
- |
#include <dt-bindings/clock/exynos5250.h>
@@ -130,4 +222,14 @@ examples:
#clock-cells = <1>;
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
+
+ dp-phy {
+ compatible = "samsung,exynos5250-dp-video-phy";
+ #phy-cells = <0>;
+ };
+
+ mipi-phy {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ #phy-cells = <1>;
+ };
};
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
index 60b49562ff69..c694926e56ef 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
@@ -4,18 +4,28 @@
$id: http://devicetree.org/schemas/soc/samsung/exynos-usi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Samsung's Exynos USI (Universal Serial Interface) binding
+title: Samsung's Exynos USI (Universal Serial Interface)
maintainers:
- Sam Protsenko <semen.protsenko@linaro.org>
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- USI IP-core provides selectable serial protocol (UART, SPI or High-Speed I2C).
- USI shares almost all internal circuits within each protocol, so only one
- protocol can be chosen at a time. USI is modeled as a node with zero or more
- child nodes, each representing a serial sub-node device. The mode setting
- selects which particular function will be used.
+ The USI IP-core provides configurable support for serial protocols, enabling
+ different serial communication modes depending on the version.
+
+ In USIv1, configurations are available to enable either one or two protocols
+ simultaneously in select combinations - High-Speed I2C0, High-Speed
+ I2C1, SPI, UART, High-Speed I2C0 and I2C1 or both High-Speed
+ I2C1 and UART.
+
+ In USIv2, only one protocol can be active at a time, either UART, SPI, or
+ High-Speed I2C.
+
+ The USI core shares internal circuits across protocols, meaning only the
+ selected configuration is active at any given time. USI is modeled as a node
+ with zero or more child nodes, each representing a serial sub-node device. The
+ mode setting selects which particular function will be used.
properties:
$nodename:
@@ -24,16 +34,26 @@ properties:
compatible:
oneOf:
- items:
- - const: samsung,exynosautov9-usi
+ - enum:
+ - google,gs101-usi
+ - samsung,exynos2200-usi
+ - samsung,exynosautov9-usi
+ - samsung,exynosautov920-usi
- const: samsung,exynos850-usi
- enum:
- samsung,exynos850-usi
+ - samsung,exynos8895-usi
- reg: true
+ reg:
+ maxItems: 1
- clocks: true
+ clocks:
+ maxItems: 2
- clock-names: true
+ clock-names:
+ items:
+ - const: pclk
+ - const: ipclk
ranges: true
@@ -56,6 +76,7 @@ properties:
samsung,mode:
$ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4, 5, 6]
description:
Selects USI function (which serial protocol to use). Refer to
<include/dt-bindings/soc/samsung,exynos-usi.h> for valid USI mode values.
@@ -92,39 +113,59 @@ required:
- samsung,sysreg
- samsung,mode
-if:
- properties:
- compatible:
- contains:
- enum:
- - samsung,exynos850-usi
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos850-usi
+
+ then:
+ properties:
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Bus (APB) clock
+ - description: Operating clock for UART/SPI/I2C protocol
+
+ clock-names:
+ maxItems: 2
-then:
- properties:
- reg:
- maxItems: 1
-
- clocks:
- items:
- - description: Bus (APB) clock
- - description: Operating clock for UART/SPI/I2C protocol
-
- clock-names:
- items:
- - const: pclk
- - const: ipclk
-
- required:
- - reg
- - clocks
- - clock-names
-
-else:
- properties:
- reg: false
- clocks: false
- clock-names: false
- samsung,clkreq-on: false
+ samsung,mode:
+ enum: [0, 1, 2, 3]
+
+ required:
+ - reg
+ - clocks
+ - clock-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos8895-usi
+
+ then:
+ properties:
+ reg: false
+
+ clocks:
+ items:
+ - description: Bus (APB) clock
+ - description: Operating clock for UART/SPI protocol
+
+ clock-names:
+ maxItems: 2
+
+ samsung,clkreq-on: false
+
+ required:
+ - clocks
+ - clock-names
additionalProperties: false
@@ -137,7 +178,7 @@ examples:
compatible = "samsung,exynos850-usi";
reg = <0x138200c0 0x20>;
samsung,sysreg = <&sysreg_peri 0x1010>;
- samsung,mode = <USI_V2_UART>;
+ samsung,mode = <USI_MODE_UART>;
samsung,clkreq-on; /* needed for UART mode */
#address-cells = <1>;
#size-cells = <1>;
@@ -151,11 +192,10 @@ examples:
interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cmu_peri 32>, <&cmu_peri 31>;
clock-names = "uart", "clk_uart_baud0";
- status = "disabled";
};
hsi2c_0: i2c@13820000 {
- compatible = "samsung,exynosautov9-hsi2c";
+ compatible = "samsung,exynos850-hsi2c", "samsung,exynosautov9-hsi2c";
reg = <0x13820000 0xc0>;
interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
new file mode 100644
index 000000000000..5e1e155510b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/samsung/samsung,exynos-sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung Exynos SoC series System Registers (SYSREG)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - google,gs101-apm-sysreg
+ - google,gs101-hsi0-sysreg
+ - google,gs101-hsi2-sysreg
+ - google,gs101-misc-sysreg
+ - google,gs101-peric0-sysreg
+ - google,gs101-peric1-sysreg
+ - samsung,exynos2200-cmgp-sysreg
+ - samsung,exynos2200-peric0-sysreg
+ - samsung,exynos2200-peric1-sysreg
+ - samsung,exynos2200-peric2-sysreg
+ - samsung,exynos2200-ufs-sysreg
+ - samsung,exynos3-sysreg
+ - samsung,exynos4-sysreg
+ - samsung,exynos5-sysreg
+ - samsung,exynos7870-cam0-sysreg
+ - samsung,exynos7870-disp-sysreg
+ - samsung,exynos8895-fsys0-sysreg
+ - samsung,exynos8895-fsys1-sysreg
+ - samsung,exynos8895-peric0-sysreg
+ - samsung,exynos8895-peric1-sysreg
+ - samsung,exynos990-peric0-sysreg
+ - samsung,exynos990-peric1-sysreg
+ - samsung,exynosautov920-hsi2-sysreg
+ - samsung,exynosautov920-peric0-sysreg
+ - samsung,exynosautov920-peric1-sysreg
+ - tesla,fsd-cam-sysreg
+ - tesla,fsd-fsys0-sysreg
+ - tesla,fsd-fsys1-sysreg
+ - tesla,fsd-peric-sysreg
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos5433-cam0-sysreg
+ - samsung,exynos5433-cam1-sysreg
+ - samsung,exynos5433-disp-sysreg
+ - samsung,exynos5433-fsys-sysreg
+ - const: samsung,exynos5433-sysreg
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynos5433-sysreg
+ - samsung,exynos850-sysreg
+ - samsung,exynosautov9-sysreg
+ - const: syscon
+ deprecated: true
+ - items:
+ - enum:
+ - samsung,exynos850-cmgp-sysreg
+ - samsung,exynos850-peri-sysreg
+ - const: samsung,exynos850-sysreg
+ - const: syscon
+ - items:
+ - enum:
+ - samsung,exynosautov9-fsys2-sysreg
+ - samsung,exynosautov9-peric0-sysreg
+ - samsung,exynosautov9-peric1-sysreg
+ - const: samsung,exynosautov9-sysreg
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - google,gs101-hsi0-sysreg
+ - google,gs101-hsi2-sysreg
+ - google,gs101-misc-sysreg
+ - google,gs101-peric0-sysreg
+ - google,gs101-peric1-sysreg
+ - samsung,exynos850-cmgp-sysreg
+ - samsung,exynos850-peri-sysreg
+ - samsung,exynos850-sysreg
+ - samsung,exynos8895-fsys0-sysreg
+ - samsung,exynos8895-fsys1-sysreg
+ - samsung,exynos8895-peric0-sysreg
+ - samsung,exynos8895-peric1-sysreg
+ - samsung,exynos990-peric0-sysreg
+ - samsung,exynos990-peric1-sysreg
+ then:
+ required:
+ - clocks
+ else:
+ properties:
+ clocks: false
+
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ pattern: "^google,gs101-[^-]+-sysreg$"
+ then:
+ properties:
+ power-domains: false
+
+additionalProperties: false
+
+examples:
+ - |
+ system-controller@10010000 {
+ compatible = "samsung,exynos4-sysreg", "syscon";
+ reg = <0x10010000 0x400>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml
new file mode 100644
index 000000000000..32d9cc2d72a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-adamv.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-adamv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier ADAMV block
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ ADAMV block implemented on Socionext UniPhier SoCs is an analog signal
+ amplifier that is a part of the external video and audio I/O system.
+
+ This block is defined for controlling audio I/O reset only.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld11-adamv
+ - socionext,uniphier-ld20-adamv
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@57920000 {
+ compatible = "socionext,uniphier-ld20-adamv",
+ "simple-mfd", "syscon";
+ reg = <0x57920000 0x1000>;
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-adamv-reset";
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml
new file mode 100644
index 000000000000..09f861cc068f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-ahci-glue.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-ahci-glue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC AHCI glue layer
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ AHCI glue layer implemented on Socionext UniPhier SoCs is a sideband
+ logic handling signals to AHCI host controller inside AHCI component.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-pro4-ahci-glue
+ - socionext,uniphier-pxs2-ahci-glue
+ - socionext,uniphier-pxs3-ahci-glue
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^reset-controller@[0-9a-f]+$":
+ $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml#
+
+ "phy@[0-9a-f]+$":
+ $ref: /schemas/phy/socionext,uniphier-ahci-phy.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ sata-controller@65700000 {
+ compatible = "socionext,uniphier-pxs3-ahci-glue", "simple-mfd";
+ reg = <0x65b00000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x65700000 0x100>;
+
+ reset-controller@0 {
+ compatible = "socionext,uniphier-pxs3-ahci-reset";
+ reg = <0x0 0x4>;
+ clock-names = "link";
+ clocks = <&sys_clk 28>;
+ reset-names = "link";
+ resets = <&sys_rst 28>;
+ #reset-cells = <1>;
+ };
+
+ phy@10 {
+ compatible = "socionext,uniphier-pxs3-ahci-phy";
+ reg = <0x10 0x10>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 28>, <&sys_clk 30>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 28>, <&sys_rst 30>;
+ #phy-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml
new file mode 100644
index 000000000000..bd0def7236b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-dwc3-glue.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-dwc3-glue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC DWC3 USB3.0 glue layer
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ DWC3 USB3.0 glue layer implemented on Socionext UniPhier SoCs is
+ a sideband logic handling signals to DWC3 host controller inside
+ USB3.0 component.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-pro4-dwc3-glue
+ - socionext,uniphier-pro5-dwc3-glue
+ - socionext,uniphier-pxs2-dwc3-glue
+ - socionext,uniphier-ld20-dwc3-glue
+ - socionext,uniphier-pxs3-dwc3-glue
+ - socionext,uniphier-nx1-dwc3-glue
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^reset-controller@[0-9a-f]+$":
+ $ref: /schemas/reset/socionext,uniphier-glue-reset.yaml#
+
+ "^regulator@[0-9a-f]+$":
+ $ref: /schemas/regulator/socionext,uniphier-regulator.yaml#
+
+ "^phy@[0-9a-f]+$":
+ oneOf:
+ - $ref: /schemas/phy/socionext,uniphier-usb3hs-phy.yaml#
+ - $ref: /schemas/phy/socionext,uniphier-usb3ss-phy.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@65b00000 {
+ compatible = "socionext,uniphier-ld20-dwc3-glue", "simple-mfd";
+ reg = <0x65b00000 0x400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x65b00000 0x400>;
+
+ reset-controller@0 {
+ compatible = "socionext,uniphier-ld20-usb3-reset";
+ reg = <0x0 0x4>;
+ #reset-cells = <1>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
+ };
+
+ regulator@100 {
+ compatible = "socionext,uniphier-ld20-usb3-regulator";
+ reg = <0x100 0x10>;
+ clock-names = "link";
+ clocks = <&sys_clk 14>;
+ reset-names = "link";
+ resets = <&sys_rst 14>;
+ };
+
+ phy@200 {
+ compatible = "socionext,uniphier-ld20-usb3-hsphy";
+ reg = <0x200 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 16>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 16>;
+ };
+
+ phy@300 {
+ compatible = "socionext,uniphier-ld20-usb3-ssphy";
+ reg = <0x300 0x10>;
+ #phy-cells = <0>;
+ clock-names = "link", "phy";
+ clocks = <&sys_clk 14>, <&sys_clk 18>;
+ reset-names = "link", "phy";
+ resets = <&sys_rst 14>, <&sys_rst 18>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml
new file mode 100644
index 000000000000..2cc38bb5038e
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-mioctrl.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-mioctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier media I/O block (MIO) controller
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ Media I/O block implemented on Socionext UniPhier SoCs is a legacy
+ integrated component of the stream type peripherals including USB2.0,
+ SD/eMMC, and MIO-DMAC.
+ Media I/O block has a common logic to control the component.
+
+ Recent SoCs have SD interface logic specialized only for SD functions
+ as a subset of media I/O block. See socionext,uniphier-sdctrl.yaml.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-mioctrl
+ - socionext,uniphier-pro4-mioctrl
+ - socionext,uniphier-sld8-mioctrl
+ - socionext,uniphier-ld11-mioctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@5b3e0000 {
+ compatible = "socionext,uniphier-ld11-mioctrl",
+ "simple-mfd", "syscon";
+ reg = <0x5b3e0000 0x800>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld11-mio-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld11-mio-reset";
+ #reset-cells = <1>;
+ resets = <&sys_rst 7>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml
new file mode 100644
index 000000000000..0adcffe859ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-perictrl.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-perictrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier peripheral block controller
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ Peripheral block implemented on Socionext UniPhier SoCs is an integrated
+ component of the peripherals including UART, I2C/FI2C, and SCSSI.
+ Peripheral block controller is a logic to control the component.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-perictrl
+ - socionext,uniphier-pro4-perictrl
+ - socionext,uniphier-pro5-perictrl
+ - socionext,uniphier-pxs2-perictrl
+ - socionext,uniphier-sld8-perictrl
+ - socionext,uniphier-ld11-perictrl
+ - socionext,uniphier-ld20-perictrl
+ - socionext,uniphier-pxs3-perictrl
+ - socionext,uniphier-nx1-perictrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@59820000 {
+ compatible = "socionext,uniphier-ld20-perictrl",
+ "simple-mfd", "syscon";
+ reg = <0x59820000 0x200>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld20-peri-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-peri-reset";
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml
new file mode 100644
index 000000000000..cb3b0d42739f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sdctrl.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-sdctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SD interface logic
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ SD interface logic implemented on Socionext UniPhier SoCs is
+ attached outside SDHC, and has some SD related functions such as
+ clock control, reset control, mode switch, and so on.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-pro5-sdctrl
+ - socionext,uniphier-pxs2-sdctrl
+ - socionext,uniphier-ld11-sdctrl
+ - socionext,uniphier-ld20-sdctrl
+ - socionext,uniphier-pxs3-sdctrl
+ - socionext,uniphier-nx1-sdctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@59810000 {
+ compatible = "socionext,uniphier-ld20-sdctrl",
+ "simple-mfd", "syscon";
+ reg = <0x59810000 0x400>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld20-sd-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-sd-reset";
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml
new file mode 100644
index 000000000000..1341544d1df5
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue-debug.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue-debug.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC-glue logic debug part
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ SoC-glue logic debug part implemented on Socionext UniPhier SoCs is
+ a collection of miscellaneous function registers handling signals outside
+ system components for debug and monitor use.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-soc-glue-debug
+ - socionext,uniphier-pro4-soc-glue-debug
+ - socionext,uniphier-pro5-soc-glue-debug
+ - socionext,uniphier-pxs2-soc-glue-debug
+ - socionext,uniphier-sld8-soc-glue-debug
+ - socionext,uniphier-ld11-soc-glue-debug
+ - socionext,uniphier-ld20-soc-glue-debug
+ - socionext,uniphier-pxs3-soc-glue-debug
+ - socionext,uniphier-nx1-soc-glue-debug
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^efuse@[0-9a-f]+$":
+ $ref: /schemas/nvmem/socionext,uniphier-efuse.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@5f900000 {
+ compatible = "socionext,uniphier-pxs2-soc-glue-debug",
+ "simple-mfd", "syscon";
+ reg = <0x5f900000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x5f900000 0x2000>;
+
+ efuse@100 {
+ compatible = "socionext,uniphier-efuse";
+ reg = <0x100 0x28>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml
new file mode 100644
index 000000000000..7845dcfca986
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-soc-glue.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-soc-glue.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier SoC-glue logic
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ SoC-glue logic implemented on Socionext UniPhier SoCs is a collection of
+ miscellaneous function registers handling signals outside system components.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-soc-glue
+ - socionext,uniphier-pro4-soc-glue
+ - socionext,uniphier-pro5-soc-glue
+ - socionext,uniphier-pxs2-soc-glue
+ - socionext,uniphier-sld8-soc-glue
+ - socionext,uniphier-ld11-soc-glue
+ - socionext,uniphier-ld20-soc-glue
+ - socionext,uniphier-pxs3-soc-glue
+ - socionext,uniphier-nx1-soc-glue
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ pinctrl:
+ $ref: /schemas/pinctrl/socionext,uniphier-pinctrl.yaml#
+
+ usb-hub:
+ $ref: /schemas/phy/socionext,uniphier-usb2-phy.yaml#
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - socionext,uniphier-pro4-soc-glue
+ - socionext,uniphier-ld11-soc-glue
+ then:
+ properties:
+ usb-hub: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-pro4-soc-glue
+ then:
+ properties:
+ clock-controller: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@5f800000 {
+ compatible = "socionext,uniphier-pro4-soc-glue",
+ "simple-mfd", "syscon";
+ reg = <0x5f800000 0x2000>;
+
+ pinctrl {
+ compatible = "socionext,uniphier-pro4-pinctrl";
+ };
+
+ usb-hub {
+ compatible = "socionext,uniphier-pro4-usb2-phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ clock-controller {
+ compatible = "socionext,uniphier-pro4-sg-clock";
+ #clock-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml
new file mode 100644
index 000000000000..3acb14201d1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,uniphier-sysctrl.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/socionext/socionext,uniphier-sysctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier system controller
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+description: |+
+ System controller implemented on Socionext UniPhier SoCs has multiple
+ functions such as clock control, reset control, internal watchdog timer,
+ thermal management, and so on.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - socionext,uniphier-ld4-sysctrl
+ - socionext,uniphier-pro4-sysctrl
+ - socionext,uniphier-pro5-sysctrl
+ - socionext,uniphier-pxs2-sysctrl
+ - socionext,uniphier-sld8-sysctrl
+ - socionext,uniphier-ld11-sysctrl
+ - socionext,uniphier-ld20-sysctrl
+ - socionext,uniphier-pxs3-sysctrl
+ - socionext,uniphier-nx1-sysctrl
+ - const: simple-mfd
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/socionext,uniphier-clock.yaml#
+
+ reset-controller:
+ $ref: /schemas/reset/socionext,uniphier-reset.yaml#
+
+ watchdog:
+ $ref: /schemas/watchdog/socionext,uniphier-wdt.yaml#
+
+ thermal-sensor:
+ $ref: /schemas/thermal/socionext,uniphier-thermal.yaml#
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: socionext,uniphier-ld4-sysctrl
+ then:
+ properties:
+ watchdog: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - socionext,uniphier-ld4-sysctrl
+ - socionext,uniphier-pro4-sysctrl
+ - socionext,uniphier-sld8-sysctrl
+ - socionext,uniphier-ld11-sysctrl
+ then:
+ properties:
+ thermal-sensor: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ syscon@61840000 {
+ compatible = "socionext,uniphier-ld20-sysctrl",
+ "simple-mfd", "syscon";
+ reg = <0x61840000 0x4000>;
+
+ clock-controller {
+ compatible = "socionext,uniphier-ld20-clock";
+ #clock-cells = <1>;
+ };
+
+ reset-controller {
+ compatible = "socionext,uniphier-ld20-reset";
+ #reset-cells = <1>;
+ };
+
+ watchdog {
+ compatible = "socionext,uniphier-wdt";
+ };
+
+ thermal-sensor {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ #thermal-sensor-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-top-syscon.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-top-syscon.yaml
new file mode 100644
index 000000000000..b2e8e0cb4ea6
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,cv1800b-top-syscon.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/sophgo/sophgo,cv1800b-top-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV18XX/SG200X SoC top system controller
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+description:
+ The Sophgo CV18XX/SG200X SoC top misc system controller provides
+ register access to configure related modules.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: sophgo,cv1800b-top-syscon
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+ dma-router@154:
+ $ref: /schemas/dma/sophgo,cv1800b-dmamux.yaml#
+ unevaluatedProperties: false
+
+ phy@48:
+ $ref: /schemas/phy/sophgo,cv1800b-usb2-phy.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sophgo,cv1800.h>
+
+ syscon@3000000 {
+ compatible = "sophgo,cv1800b-top-syscon", "syscon", "simple-mfd";
+ reg = <0x03000000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ phy@48 {
+ compatible = "sophgo,cv1800b-usb2-phy";
+ reg = <0x48 0x4>;
+ #phy-cells = <0>;
+ clocks = <&clk CLK_USB_125M>,
+ <&clk CLK_USB_33K>,
+ <&clk CLK_USB_12M>;
+ clock-names = "app", "stb", "lpm";
+ resets = <&rst 58>;
+ };
+
+ dma-router@154 {
+ compatible = "sophgo,cv1800b-dmamux";
+ reg = <0x154 0x8>, <0x298 0x4>;
+ #dma-cells = <2>;
+ dma-masters = <&dmac>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2044-top-syscon.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2044-top-syscon.yaml
new file mode 100644
index 000000000000..a82cc3cae576
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo,sg2044-top-syscon.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/sophgo/sophgo,sg2044-top-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SG2044 SoC TOP system controller
+
+maintainers:
+ - Inochi Amaoto <inochiama@gmail.com>
+
+description:
+ The Sophgo SG2044 TOP system controller is a hardware block grouping
+ multiple small functions, such as clocks and some other internal
+ function.
+
+properties:
+ compatible:
+ items:
+ - const: sophgo,sg2044-top-syscon
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/sophgo,sg2044-pll.h> for valid clock.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@50000000 {
+ compatible = "sophgo,sg2044-top-syscon", "syscon";
+ reg = <0x50000000 0x1000>;
+ #clock-cells = <1>;
+ clocks = <&osc>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml b/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml
new file mode 100644
index 000000000000..1c502618de51
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sophgo/sophgo.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/sophgo/sophgo.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo SoC-based boards
+
+maintainers:
+ - Chao Wei <chao.wei@sophgo.com>
+ - Chen Wang <unicorn_wang@outlook.com>
+
+description:
+ Sophgo SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - milkv,duo
+ - const: sophgo,cv1800b
+ - items:
+ - enum:
+ - sophgo,huashan-pi
+ - const: sophgo,cv1812h
+ - items:
+ - enum:
+ - milkv,duo-module-01-evb
+ - const: milkv,duo-module-01
+ - const: sophgo,sg2000
+ - items:
+ - enum:
+ - sipeed,licheerv-nano-b
+ - const: sipeed,licheerv-nano
+ - const: sophgo,sg2002
+ - items:
+ - enum:
+ - milkv,pioneer
+ - sophgo,sg2042-evb-v1
+ - sophgo,sg2042-evb-v2
+ - const: sophgo,sg2042
+ - items:
+ - enum:
+ - sophgo,srd3-10
+ - const: sophgo,sg2044
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/soc/spacemit/spacemit,k1-syscon.yaml b/Documentation/devicetree/bindings/soc/spacemit/spacemit,k1-syscon.yaml
new file mode 100644
index 000000000000..133a391ee68c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/spacemit/spacemit,k1-syscon.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/spacemit/spacemit,k1-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 SoC System Controller
+
+maintainers:
+ - Haylen Chu <heylenay@4d2.org>
+
+description:
+ System controllers found on SpacemiT K1 SoC, which are capable of
+ clock, reset and power-management functions.
+
+properties:
+ compatible:
+ enum:
+ - spacemit,k1-syscon-apbc
+ - spacemit,k1-syscon-apmu
+ - spacemit,k1-syscon-mpmu
+ - spacemit,k1-syscon-rcpu
+ - spacemit,k1-syscon-rcpu2
+ - spacemit,k1-syscon-apbc2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: osc
+ - const: vctcxo_1m
+ - const: vctcxo_3m
+ - const: vctcxo_24m
+
+ "#clock-cells":
+ const: 1
+ description:
+ See <dt-bindings/clock/spacemit,k1-syscon.h> for valid indices.
+
+ "#power-domain-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - spacemit,k1-syscon-apmu
+ - spacemit,k1-syscon-mpmu
+ then:
+ required:
+ - "#power-domain-cells"
+ else:
+ properties:
+ "#power-domain-cells": false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - spacemit,k1-syscon-apbc
+ - spacemit,k1-syscon-apmu
+ - spacemit,k1-syscon-mpmu
+ then:
+ required:
+ - clocks
+ - clock-names
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ system-controller@d4050000 {
+ compatible = "spacemit,k1-syscon-mpmu";
+ reg = <0xd4050000 0x209c>;
+ clocks = <&osc>, <&vctcxo_1m>, <&vctcxo_3m>, <&vctcxo_24m>;
+ clock-names = "osc", "vctcxo_1m", "vctcxo_3m", "vctcxo_24m";
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/sprd/sprd,sc9863a-glbregs.yaml b/Documentation/devicetree/bindings/soc/sprd/sprd,sc9863a-glbregs.yaml
new file mode 100644
index 000000000000..49add564e5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sprd/sprd,sc9863a-glbregs.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/sprd/sprd,sc9863a-glbregs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SC9863A Syscon
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ items:
+ - const: sprd,sc9863a-glbregs
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+patternProperties:
+ "@[0-9a-f]+$":
+ $ref: /schemas/clock/sprd,sc9863a-clk.yaml
+ description: Clock controllers
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@20e00000 {
+ compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd";
+ reg = <0x20e00000 0x4000>;
+ ranges = <0 0x20e00000 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ apahb_gate: apahb-gate@0 {
+ compatible = "sprd,sc9863a-apahb-gate";
+ reg = <0x0 0x1020>;
+ #clock-cells = <1>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
new file mode 100644
index 000000000000..0039319e91fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/starfive/starfive,jh7110-syscon.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/starfive/starfive,jh7110-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 SoC system controller
+
+maintainers:
+ - William Qiu <william.qiu@starfivetech.com>
+
+description:
+ The StarFive JH7110 SoC system controller provides register information such
+ as offset, mask and shift to configure related modules such as MMC and PCIe.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: starfive,jh7110-sys-syscon
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - starfive,jh7110-aon-syscon
+ - starfive,jh7110-stg-syscon
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ clock-controller:
+ $ref: /schemas/clock/starfive,jh7110-pll.yaml#
+ type: object
+
+ "#power-domain-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-sys-syscon
+ then:
+ required:
+ - clock-controller
+ else:
+ properties:
+ clock-controller: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-aon-syscon
+ then:
+ required:
+ - "#power-domain-cells"
+ else:
+ properties:
+ "#power-domain-cells": false
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@10240000 {
+ compatible = "starfive,jh7110-stg-syscon", "syscon";
+ reg = <0x10240000 0x1000>;
+ };
+
+ syscon@13030000 {
+ compatible = "starfive,jh7110-sys-syscon", "syscon", "simple-mfd";
+ reg = <0x13030000 0x1000>;
+
+ clock-controller {
+ compatible = "starfive,jh7110-pll";
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
+ };
+
+ syscon@17010000 {
+ compatible = "starfive,jh7110-aon-syscon", "syscon";
+ reg = <0x17010000 0x1000>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/sti/st,sti-syscon.yaml b/Documentation/devicetree/bindings/soc/sti/st,sti-syscon.yaml
new file mode 100644
index 000000000000..fc933d70d138
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/sti/st,sti-syscon.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/sti/st,sti-syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi platform sysconfig
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+description: |
+ Binding for the various sysconfig nodes used within the STi
+ platform device-tree to point to some common configuration
+ registers used by other nodes.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - st,stih407-core-syscfg
+ - st,stih407-flash-syscfg
+ - st,stih407-front-syscfg
+ - st,stih407-lpm-syscfg
+ - st,stih407-rear-syscfg
+ - st,stih407-sbc-reg-syscfg
+ - st,stih407-sbc-syscfg
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ sti-sasg-codec:
+ description: STi internal audio codec
+ type: object
+ additionalProperties: true
+
+ properties:
+ compatible:
+ const: st,stih407-sas-codec
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ syscfg_sbc: syscon@9620000 {
+ compatible = "st,stih407-sbc-syscfg", "syscon";
+ reg = <0x9620000 0x1000>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml
new file mode 100644
index 000000000000..d5261ce3a619
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,nvec.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,nvec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA compliant embedded controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,nvec
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: divider clock
+ - description: fast clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: div-clk
+ - const: fast-clk
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: i2c
+
+ clock-frequency: true
+
+ request-gpios:
+ description: phandle to the GPIO used for EC request
+
+ slave-addr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: I2C address of the slave controller
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - clock-frequency
+ - request-gpios
+ - slave-addr
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c@7000c500 {
+ compatible = "nvidia,nvec";
+ reg = <0x7000c500 0x100>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <80000>;
+ request-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
+ slave-addr = <138>;
+ clocks = <&tegra_car TEGRA20_CLK_I2C3>,
+ <&tegra_car TEGRA20_CLK_PLL_P_OUT3>;
+ clock-names = "div-clk", "fast-clk";
+ resets = <&tegra_car 67>;
+ reset-names = "i2c";
+ };
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml
new file mode 100644
index 000000000000..2f7269a26b8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-ahb.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-ahb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+title: NVIDIA Tegra AHB
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-ahb
+ - nvidia,tegra30-ahb
+ - items:
+ - enum:
+ - nvidia,tegra114-ahb
+ - nvidia,tegra124-ahb
+ - nvidia,tegra210-ahb
+ - const: nvidia,tegra30-ahb
+
+ reg:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ ahb@6000c004 {
+ compatible = "nvidia,tegra20-ahb";
+ reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
+ };
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml
new file mode 100644
index 000000000000..705544b7f98f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-flowctrl.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-flowctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Flow Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-flowctrl
+ - nvidia,tegra30-flowctrl
+ - nvidia,tegra114-flowctrl
+ - nvidia,tegra124-flowctrl
+ - nvidia,tegra210-flowctrl
+
+ - items:
+ - const: nvidia,tegra132-flowctrl
+ - const: nvidia,tegra124-flowctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ flow-controller@60007000 {
+ compatible = "nvidia,tegra20-flowctrl";
+ reg = <0x60007000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml
new file mode 100644
index 000000000000..f516960dbbef
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra20-pmc.yaml
@@ -0,0 +1,416 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra20-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tegra Power Management Controller (PMC)
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jonathan Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-pmc
+ - nvidia,tegra30-pmc
+ - nvidia,tegra114-pmc
+ - nvidia,tegra124-pmc
+ - nvidia,tegra210-pmc
+
+ reg:
+ maxItems: 1
+
+ clock-names:
+ items:
+ # Tegra clock of the same name
+ - const: pclk
+ # 32 KHz clock input
+ - const: clk32k_in
+
+ clocks:
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+ description: |
+ Tegra PMC has clk_out_1, clk_out_2, and clk_out_3. PMC also has blink
+ control which allows 32Khz clock output to Tegra blink pad.
+
+ Consumer of PMC clock should specify the desired clock by having the
+ clock ID in its "clocks" phandle cell with PMC clock provider. See
+ include/dt-bindings/soc/tegra-pmc.h for the list of Tegra PMC clock IDs.
+
+ '#interrupt-cells':
+ const: 2
+ description: Specifies number of cells needed to encode an interrupt
+ source.
+
+ interrupt-controller: true
+
+ nvidia,invert-interrupt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Inverts the PMU interrupt signal. The PMU is an external Power
+ Management Unit, whose interrupt output signal is fed into the PMC. This
+ signal is optionally inverted, and then fed into the ARM GIC. The PMC is
+ not involved in the detection or handling of this interrupt signal,
+ merely its inversion.
+
+ nvidia,core-power-req-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: core power request active-high
+
+ nvidia,sys-clock-req-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: system clock request active-high
+
+ nvidia,combined-power-req:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: combined power request for CPU and core
+
+ nvidia,cpu-pwr-good-en:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: CPU power good signal from external PMIC to PMC is enabled
+
+ nvidia,suspend-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: the suspend mode that the platform should use
+ oneOf:
+ - description: LP0, CPU + Core voltage off and DRAM in self-refresh
+ const: 0
+ - description: LP1, CPU voltage off and DRAM in self-refresh
+ const: 1
+ - description: LP2, CPU voltage off
+ const: 2
+
+ nvidia,cpu-pwr-good-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: CPU power good time in microseconds
+
+ nvidia,cpu-pwr-off-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: CPU power off time in microseconds
+
+ nvidia,core-pwr-good-time:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: core power good time in microseconds
+ items:
+ - description: oscillator stable time
+ - description: power stable time
+
+ nvidia,core-pwr-off-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: core power off time in microseconds
+
+ nvidia,lp0-vec:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Starting address and length of LP0 vector. The LP0 vector contains the
+ warm boot code that is executed by AVP when resuming from the LP0 state.
+ The AVP (Audio-Video Processor) is an ARM7 processor and always being
+ the first boot processor when chip is power on or resume from deep sleep
+ mode. When the system is resumed from the deep sleep mode, the warm boot
+ code will restore some PLLs, clocks and then brings up CPU0 for resuming
+ the system.
+ items:
+ - description: starting address of LP0 vector
+ - description: length of LP0 vector
+
+ core-supply:
+ description: phandle to voltage regulator connected to the SoC core power
+ rail
+
+ core-domain:
+ type: object
+ description: The vast majority of hardware blocks of Tegra SoC belong to a
+ core power domain, which has a dedicated voltage rail that powers the
+ blocks.
+ additionalProperties: false
+ properties:
+ operating-points-v2:
+ description: Should contain level, voltages and opp-supported-hw
+ property. The supported-hw is a bitfield indicating SoC speedo or
+ process ID mask.
+
+ '#power-domain-cells':
+ const: 0
+
+ required:
+ - operating-points-v2
+ - '#power-domain-cells'
+
+ i2c-thermtrip:
+ type: object
+ description: On Tegra30, Tegra114 and Tegra124 if i2c-thermtrip subnode
+ exists, hardware-triggered thermal reset will be enabled.
+ additionalProperties: false
+ properties:
+ nvidia,i2c-controller-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: ID of I2C controller to send poweroff command to PMU.
+ Valid values are described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0"
+ of the Tegra K1 Technical Reference Manual.
+
+ nvidia,bus-addr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: bus address of the PMU on the I2C bus
+
+ nvidia,reg-addr:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: PMU I2C register address to issue poweroff command
+
+ nvidia,reg-data:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: power-off command to write to PMU
+
+ nvidia,pinmux-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Pinmux used by the hardware when issuing power-off command.
+ Defaults to 0. Valid values are described in section 12.5.2 "Pinmux
+ Support" of the Tegra4 Technical Reference Manual.
+
+ required:
+ - nvidia,i2c-controller-id
+ - nvidia,bus-addr
+ - nvidia,reg-addr
+ - nvidia,reg-data
+
+ powergates:
+ type: object
+ additionalProperties: false
+ description: |
+ This node contains a hierarchy of power domain nodes, which should match
+ the powergates on the Tegra SoC. Each powergate node represents a power-
+ domain on the Tegra SoC that can be power-gated by the Tegra PMC.
+
+ Hardware blocks belonging to a power domain should contain "power-domains"
+ property that is a phandle pointing to corresponding powergate node.
+
+ The name of the powergate node should be one of the below. Note that not
+ every powergate is applicable to all Tegra devices and the following list
+ shows which powergates are applicable to which devices.
+
+ Please refer to Tegra TRM for mode details on the powergate nodes to use
+ for each power-gate block inside Tegra.
+
+ Name Description Devices Applicable
+ --------------------------------------------------------------
+ 3d 3D Graphics Tegra20/114/124/210
+ 3d0 3D Graphics 0 Tegra30
+ 3d1 3D Graphics 1 Tegra30
+ aud Audio Tegra210
+ dfd Debug Tegra210
+ dis Display A Tegra114/124/210
+ disb Display B Tegra114/124/210
+ heg 2D Graphics Tegra30/114/124/210
+ iram Internal RAM Tegra124/210
+ mpe MPEG Encode All
+ nvdec NVIDIA Video Decode Engine Tegra210
+ nvjpg NVIDIA JPEG Engine Tegra210
+ pcie PCIE Tegra20/30/124/210
+ sata SATA Tegra30/124/210
+ sor Display interfaces Tegra124/210
+ ve2 Video Encode Engine 2 Tegra210
+ venc Video Encode Engine All
+ vdec Video Decode Engine Tegra20/30/114/124
+ vic Video Imaging Compositor Tegra124/210
+ xusba USB Partition A Tegra114/124/210
+ xusbb USB Partition B Tegra114/124/210
+ xusbc USB Partition C Tegra114/124/210
+
+ patternProperties:
+ '^[a-z0-9]+$':
+ type: object
+ additionalProperties: false
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 10
+
+ resets:
+ minItems: 1
+ maxItems: 8
+
+ power-domains:
+ maxItems: 1
+
+ '#power-domain-cells':
+ const: 0
+ description: Must be 0.
+
+ required:
+ - clocks
+ - resets
+ - '#power-domain-cells'
+
+ pinmux:
+ type: object
+ additionalProperties:
+ type: object
+ description: |
+ This is a pad configuration node. On Tegra SoCs a pad is a set of pins
+ which are configured as a group. The pin grouping is a fixed attribute
+ of the hardware. The PMC can be used to set pad power state and
+ signaling voltage. A pad can be either in active or power down mode.
+ The support for power state and signaling voltage configuration varies
+ depending on the pad in question. 3.3V and 1.8V signaling voltages are
+ supported on pins where software controllable signaling voltage
+ switching is available.
+
+ The pad configuration state nodes are placed under the pmc node and
+ they are referred to by the pinctrl client properties. For more
+ information see:
+
+ Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+ The pad name should be used as the value of the pins property in pin
+ configuration nodes.
+
+ The following pads are present on Tegra124 and Tegra132:
+
+ audio, bb, cam, comp, csia, csb, cse, dsi, dsib, dsic, dsid, hdmi,
+ hsic, hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2,
+ pex-cntrl, sdmmc1, sdmmc3, sdmmc4, sys_ddc, uart, usb0, usb1, usb2,
+ usb_bias
+
+ The following pads are present on Tegra210:
+
+ audio, audio-hv, cam, csia, csib, csic, csid, csie, csif, dbg,
+ debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2, gpio,
+ hdmi, hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2, pex-cntrl,
+ sdmmc1, sdmmc3, spi, spi-hv, uart, usb0, usb1, usb2, usb3, usb-bias
+ additionalProperties: false
+ properties:
+ pins:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description: Must contain name of the pad(s) to be configured.
+
+ low-power-enable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Configure the pad into power down mode.
+
+ low-power-disable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Configure the pad into active mode.
+
+ power-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or
+ TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages. The
+ values are defined in:
+
+ include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h
+
+ Power state can be configured on all Tegra124 and Tegra132 pads.
+ None of the Tegra124 or Tegra132 pads support signaling voltage
+ switching. All of the listed Tegra210 pads except pex-cntrl support
+ power state configuration. Signaling voltage switching is supported
+ on the following Tegra210 pads:
+
+ audio, audio-hv, cam, dbg, dmic, gpio, pex-cntrl, sdmmc1, sdmmc3,
+ spi, spi-hv, uart
+
+ required:
+ - pins
+
+required:
+ - compatible
+ - reg
+ - clock-names
+ - clocks
+ - '#clock-cells'
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra124-pmc
+ then:
+ properties:
+ pinmux:
+ additionalProperties:
+ type: object
+ properties:
+ pins:
+ items:
+ enum: [ audio, bb, cam, comp, csia, csb, cse, dsi, dsib,
+ dsic, dsid, hdmi, hsic, hv, lvds, mipi-bias, nand,
+ pex-bias, pex-clk1, pex-clk2, pex-cntrl, sdmmc1,
+ sdmmc3, sdmmc4, sys_ddc, uart, usb0, usb1, usb2,
+ usb_bias ]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra210-pmc
+ then:
+ properties:
+ pinmux:
+ additionalProperties:
+ type: object
+ properties:
+ pins:
+ items:
+ enum: [ audio, audio-hv, cam, csia, csib, csic, csid, csie,
+ csif, dbg, debug-nonao, dmic, dp, dsi, dsib, dsic,
+ dsid, emmc, emmc2, gpio, hdmi, hsic, lvds, mipi-bias,
+ pex-bias, pex-clk1, pex-clk2, pex-cntrl, sdmmc1,
+ sdmmc3, spi, spi-hv, uart, usb0, usb1, usb2, usb3,
+ usb-bias ]
+
+additionalProperties: false
+
+dependencies:
+ nvidia,suspend-mode: ['nvidia,core-pwr-off-time', 'nvidia,cpu-pwr-off-time']
+ nvidia,core-pwr-off-time: ['nvidia,core-pwr-good-time']
+ nvidia,cpu-pwr-off-time: ['nvidia,cpu-pwr-good-time']
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h>
+ #include <dt-bindings/soc/tegra-pmc.h>
+
+ pmc@7000e400 {
+ compatible = "nvidia,tegra210-pmc";
+ reg = <0x7000e400 0x400>;
+ core-supply = <&regulator>;
+ clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
+ clock-names = "pclk", "clk32k_in";
+ #clock-cells = <1>;
+
+ nvidia,invert-interrupt;
+ nvidia,suspend-mode = <0>;
+ nvidia,cpu-pwr-good-time = <0>;
+ nvidia,cpu-pwr-off-time = <0>;
+ nvidia,core-pwr-good-time = <4587 3876>;
+ nvidia,core-pwr-off-time = <39065>;
+ nvidia,core-power-req-active-high;
+ nvidia,sys-clock-req-active-high;
+
+ pd_core: core-domain {
+ operating-points-v2 = <&core_opp_table>;
+ #power-domain-cells = <0>;
+ };
+
+ powergates {
+ pd_audio: aud {
+ clocks = <&tegra_car TEGRA210_CLK_APE>,
+ <&tegra_car TEGRA210_CLK_APB2APE>;
+ resets = <&tegra_car 198>;
+ power-domains = <&pd_core>;
+ #power-domain-cells = <0>;
+ };
+
+ pd_xusbss: xusba {
+ clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>;
+ resets = <&tegra_car TEGRA210_CLK_XUSB_SS>;
+ power-domains = <&pd_core>;
+ #power-domain-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
index ddea3d41971d..158186610c53 100644
--- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml
@@ -2,8 +2,8 @@
# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 NavigatorSS Ring Accelerator
@@ -25,24 +25,31 @@ description: |
The Ring Accelerator is a hardware module that is responsible for accelerating
management of the packet queues. The K3 SoCs can have more than one RA instances
+allOf:
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
properties:
compatible:
items:
- const: ti,am654-navss-ringacc
reg:
+ minItems: 4
items:
- description: real time registers regions
- description: fifos registers regions
- description: proxy gcfg registers regions
- description: proxy target registers regions
+ - description: configuration registers region
reg-names:
+ minItems: 4
items:
- const: rt
- const: fifos
- const: proxy_gcfg
- const: proxy_target
+ - const: cfg
msi-parent: true
@@ -54,14 +61,6 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
description: TI-SCI RM subtype for GP ring range
- ti,sci:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: phandle on TI-SCI compatible System controller node
-
- ti,sci-dev-id:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TI-SCI device id of the ring accelerator
-
required:
- compatible
- reg
@@ -72,7 +71,7 @@ required:
- ti,sci
- ti,sci-dev-id
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -85,8 +84,9 @@ examples:
reg = <0x0 0x3c000000 0x0 0x400000>,
<0x0 0x38000000 0x0 0x400000>,
<0x0 0x31120000 0x0 0x100>,
- <0x0 0x33000000 0x0 0x40000>;
- reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
+ <0x0 0x33000000 0x0 0x40000>,
+ <0x0 0x31080000 0x0 0x40000>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
ti,num-rings = <818>;
ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
ti,sci = <&dmsc>;
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
index 9e6cb4ee9755..b6da72032151 100644
--- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI-SCI generic power domain node bindings
+title: TI-SCI generic power domain
maintainers:
- Nishanth Menon <nm@ti.com>
@@ -40,7 +40,7 @@ properties:
TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts.
Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions.
- Please see http://processors.wiki.ti.com/index.php/TISCI for
+ Please see https://software-dl.ti.com/tisci/esd/latest/index.html for
protocol documentation for the values to be used for different devices.
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,am654-serdes-ctrl.yaml b/Documentation/devicetree/bindings/soc/ti/ti,am654-serdes-ctrl.yaml
new file mode 100644
index 000000000000..94b36943a50f
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,am654-serdes-ctrl.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,am654-serdes-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM654 Serdes Control Syscon
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+
+properties:
+ compatible:
+ items:
+ - const: ti,am654-serdes-ctrl
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ mux-controller:
+ $ref: /schemas/mux/reg-mux.yaml#
+
+required:
+ - compatible
+ - reg
+ - mux-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ clock@4080 {
+ compatible = "ti,am654-serdes-ctrl", "syscon", "simple-mfd";
+ reg = <0x4080 0x4>;
+
+ mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x0 0x3>; /* lane select */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
new file mode 100644
index 000000000000..f3bd0be3b279
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,j721e-system-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI J721e System Controller Registers R/W
+
+description: |
+ This represents the Control Module registers (CTRL_MMR0) on the SoC.
+ System controller node represents a register region containing a set
+ of miscellaneous registers. The registers are not cohesive enough to
+ represent as any specific type of device. The typical use-case is
+ for some other node's driver, or platform-specific code, to acquire
+ a reference to the syscon node (e.g. by phandle, node path, or
+ search using a specific compatible value), interrogate the node (or
+ associated OS driver) to determine the location of the registers,
+ and access the registers directly.
+
+maintainers:
+ - Kishon Vijay Abraham I <kishon@kernel.org>
+ - Roger Quadros <rogerq@kernel.org>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ti,am654-system-controller
+ - ti,j7200-system-controller
+ - ti,j721e-system-controller
+ - ti,j721s2-system-controller
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ # Optional children
+ "^mux-controller@[0-9a-f]+$":
+ type: object
+ description:
+ This is the SERDES lane control mux.
+
+ "^clock-controller@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ description:
+ Clock provider for TI EHRPWM nodes.
+
+ "phy@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/phy/ti,phy-gmii-sel.yaml#
+ description:
+ The phy node corresponding to the ethernet MAC.
+
+ "^chipid@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/hwinfo/ti,k3-socinfo.yaml#
+ description:
+ The node corresponding to SoC chip identification.
+
+ "^pcie-ctrl@[0-9a-f]+$":
+ type: object
+ description:
+ The node corresponding to PCIe control register.
+
+ "^clock@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/soc/ti/ti,am654-serdes-ctrl.yaml#
+ description:
+ This is the Serdes Control region.
+
+ "^dss-oldi-io-ctrl@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/mfd/syscon.yaml#
+ description:
+ This is the DSS OLDI CTRL region.
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ scm_conf: scm-conf@100000 {
+ compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
+ reg = <0x00100000 0x1c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ serdes_ln_ctrl: mux-controller@4080 {
+ compatible = "mmio-mux";
+ reg = <0x00004080 0x50>;
+
+ #mux-control-cells = <1>;
+ mux-reg-masks =
+ <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
+ <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
+ <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
+ <0x40b0 0x3>, <0x40b4 0x3>, /* SERDES3 lane0/1 select */
+ <0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>;
+ /* SERDES4 lane0/1/2/3 select */
+ };
+
+ clock-controller@4140 {
+ compatible = "ti,am654-ehrpwm-tbclk";
+ reg = <0x4140 0x18>;
+ #clock-cells = <1>;
+ };
+
+ chipid@14 {
+ compatible = "ti,am654-chipid";
+ reg = <0x14 0x4>;
+ };
+
+ pcie0_ctrl: pcie-ctrl@4070 {
+ compatible = "ti,j784s4-pcie-ctrl", "syscon";
+ reg = <0x4070 0x4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j784s4-bist.yaml
new file mode 100644
index 000000000000..a73691cf5624
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j784s4-bist.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2025 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,j784s4-bist.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 BIST
+
+maintainers:
+ - Neha Malcom Francis <n-francis@ti.com>
+
+allOf:
+ - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+description:
+ The BIST (Built-In Self Test) module is an IP block present in K3 devices
+ that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
+ (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
+ is executed by hardware for the MCU domain automatically as part of HW POST.
+
+properties:
+ compatible:
+ const: ti,j784s4-bist
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: ctrl_mmr
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci-dev-id
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ safety-selftest@33c0000 {
+ compatible = "ti,j784s4-bist";
+ reg = <0x00 0x033c0000 0x00 0x400>,
+ <0x00 0x0010c1a0 0x00 0x01c>;
+ reg-names = "cfg", "ctrl_mmr";
+ clocks = <&k3_clks 237 7>;
+ power-domains = <&k3_pds 237 TI_SCI_PD_EXCLUSIVE>;
+ ti,sci-dev-id = <234>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
index 847873289f25..d97e88433d2f 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
@@ -11,7 +11,6 @@ maintainers:
- Suman Anna <s-anna@ti.com>
description: |+
-
The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS a.k.a. PRUSS) is present on various TI SoCs such as AM335x, AM437x,
Keystone 66AK2G, OMAP-L138/DA850 etc. A PRUSS consists of dual 32-bit RISC
@@ -44,7 +43,6 @@ description: |+
integration within the IP and the SoC. These nodes are described in the
following sections.
-
PRU-ICSS Node
==============
Each PRU-ICSS instance is represented as its own node with the individual PRU
@@ -54,7 +52,6 @@ description: |+
See ../../mfd/syscon.yaml for generic SysCon binding details.
-
properties:
$nodename:
pattern: "^(pruss|icssg)@[0-9a-f]+$"
@@ -92,6 +89,16 @@ properties:
description: |
This property is as per sci-pm-domain.txt.
+ clocks:
+ items:
+ - description: ICSSG_CORE Clock
+ - description: ICSSG_IEP Clock
+ - description: ICSSG_RGMII_MHZ_250 Clock
+ - description: ICSSG_RGMII_MHZ_50 Clock
+ - description: ICSSG_RGMII_MHZ_5 Clock
+ - description: ICSSG_UART Clock
+ - description: ICSSG_ICLK Clock
+
patternProperties:
memories@[a-f0-9]+$:
@@ -130,6 +137,7 @@ patternProperties:
PRU-ICSS configuration space. CFG sub-module represented as a SysCon.
type: object
+ additionalProperties: false
properties:
compatible:
@@ -240,6 +248,15 @@ patternProperties:
type: object
+ ecap@[a-f0-9]+$:
+ description:
+ PRU-ICSS has a Enhanced Capture (eCAP) event module which can generate
+ and capture periodic timer based events which will be used for features
+ like RX Pacing to rise interrupt when the timer event has occurred.
+ Each PRU-ICSS instance has one eCAP module irrespective of SOCs.
+ $ref: /schemas/net/ti,pruss-ecap.yaml#
+ type: object
+
mii-rt@[a-f0-9]+$:
description: |
Real-Time Ethernet to support multiple industrial communication protocols.
@@ -277,6 +294,26 @@ patternProperties:
additionalProperties: false
+ ^pa-stats@[a-f0-9]+$:
+ description: |
+ PA-STATS sub-module represented as a SysCon. PA_STATS is a set of
+ registers where different statistics related to ICSSG, are dumped by
+ ICSSG firmware. This syscon sub-module will help the device to
+ access/read/write those statistics.
+
+ type: object
+
+ additionalProperties: false
+
+ properties:
+ compatible:
+ items:
+ - const: ti,pruss-pa-st
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
interrupt-controller@[a-f0-9]+$:
description: |
PRUSS INTC Node. Each PRUSS has a single interrupt controller instance
@@ -313,7 +350,7 @@ additionalProperties: false
# Due to inability of correctly verifying sub-nodes with an @address through
# the "required" list, the required sub-nodes below are commented out for now.
-#required:
+# required:
# - memories
# - interrupt-controller
# - pru
diff --git a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml
index 0df41c4f60c1..56b16183c885 100644
--- a/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/wkup-m3-ipc.yaml
@@ -121,13 +121,13 @@ examples:
};
wkup_m3_ipc@1324 {
- compatible = "ti,am3352-wkup-m3-ipc";
- reg = <0x1324 0x24>;
- interrupts = <78>;
- ti,rproc = <&wkup_m3>;
- mboxes = <&am335x_mailbox &mbox_wkupm3>;
- ti,vtt-gpio-pin = <7>;
- firmware-name = "am335x-evm-scale-data.bin";
+ compatible = "ti,am3352-wkup-m3-ipc";
+ reg = <0x1324 0x24>;
+ interrupts = <78>;
+ ti,rproc = <&wkup_m3>;
+ mboxes = <&am335x_mailbox &mbox_wkupm3>;
+ ti,vtt-gpio-pin = <7>;
+ firmware-name = "am335x-evm-scale-data.bin";
};
};
@@ -155,20 +155,20 @@ examples:
pinctrl-0 = <&ddr3_vtt_toggle_default>;
ddr3_vtt_toggle_default: ddr_vtt_toggle_default {
- pinctrl-single,pins = <
+ pinctrl-single,pins = <
0x25C (DS0_PULL_UP_DOWN_EN | PIN_OUTPUT_PULLUP | DS0_FORCE_OFF_MODE | MUX_MODE7)
- >;
+ >;
};
};
wkup_m3_ipc@1324 {
- compatible = "ti,am4372-wkup-m3-ipc";
- reg = <0x1324 0x24>;
- interrupts = <78>;
- ti,rproc = <&wkup_m3>;
- mboxes = <&am437x_mailbox &mbox_wkupm3>;
- ti,set-io-isolation;
- firmware-name = "am43x-evm-scale-data.bin";
+ compatible = "ti,am4372-wkup-m3-ipc";
+ reg = <0x1324 0x24>;
+ interrupts = <78>;
+ ti,rproc = <&wkup_m3>;
+ mboxes = <&am437x_mailbox &mbox_wkupm3>;
+ ti,set-io-isolation;
+ firmware-name = "am43x-evm-scale-data.bin";
};
};
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
new file mode 100644
index 000000000000..c9f99e0df2b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
@@ -0,0 +1,280 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/xilinx/xilinx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynq Platforms
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+
+description:
+ AMD/Xilinx boards with ARM 32/64bits cores
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - adapteva,parallella
+ - digilent,zynq-zybo
+ - digilent,zynq-zybo-z7
+ - ebang,ebaz4205
+ - myir,zynq-zturn-v5
+ - myir,zynq-zturn
+ - xlnx,zynq-cc108
+ - xlnx,zynq-zc702
+ - xlnx,zynq-zc706
+ - xlnx,zynq-zc770-xm010
+ - xlnx,zynq-zc770-xm011
+ - xlnx,zynq-zc770-xm012
+ - xlnx,zynq-zc770-xm013
+ - const: xlnx,zynq-7000
+
+ - items:
+ - const: avnet,zynq-microzed
+ - const: xlnx,zynq-microzed
+ - const: xlnx,zynq-7000
+
+ - items:
+ - const: avnet,zynq-zed
+ - const: xlnx,zynq-zed
+ - const: xlnx,zynq-7000
+
+ - items:
+ - enum:
+ - xlnx,zynqmp-zc1751
+ - const: xlnx,zynqmp
+
+ - description: Xilinx internal board zc1232
+ items:
+ - const: xlnx,zynqmp-zc1232-revA
+ - const: xlnx,zynqmp-zc1232
+ - const: xlnx,zynqmp
+
+ - description: Xilinx internal board zc1254
+ items:
+ - const: xlnx,zynqmp-zc1254-revA
+ - const: xlnx,zynqmp-zc1254
+ - const: xlnx,zynqmp
+
+ - description: Xilinx evaluation board zcu1275
+ items:
+ - const: xlnx,zynqmp-zcu1275-revA
+ - const: xlnx,zynqmp-zcu1275
+ - const: xlnx,zynqmp
+
+ - description: Xilinx 96boards compatible board zcu100
+ items:
+ - const: xlnx,zynqmp-zcu100-revC
+ - const: xlnx,zynqmp-zcu100
+ - const: xlnx,zynqmp
+
+ - description: Xilinx 96boards compatible board Ultra96
+ items:
+ - const: avnet,ultra96-rev1
+ - const: avnet,ultra96
+ - const: xlnx,zynqmp-zcu100-revC
+ - const: xlnx,zynqmp-zcu100
+ - const: xlnx,zynqmp
+
+ - description: Xilinx evaluation board zcu102
+ items:
+ - enum:
+ - xlnx,zynqmp-zcu102-revA
+ - xlnx,zynqmp-zcu102-revB
+ - xlnx,zynqmp-zcu102-rev1.0
+ - xlnx,zynqmp-zcu102-rev1.1
+ - const: xlnx,zynqmp-zcu102
+ - const: xlnx,zynqmp
+
+ - description: Xilinx evaluation board zcu104
+ items:
+ - enum:
+ - xlnx,zynqmp-zcu104-revA
+ - xlnx,zynqmp-zcu104-revC
+ - xlnx,zynqmp-zcu104-rev1.0
+ - const: xlnx,zynqmp-zcu104
+ - const: xlnx,zynqmp
+
+ - description: Xilinx evaluation board zcu106
+ items:
+ - enum:
+ - xlnx,zynqmp-zcu106-revA
+ - xlnx,zynqmp-zcu106-rev1.0
+ - const: xlnx,zynqmp-zcu106
+ - const: xlnx,zynqmp
+
+ - description: Xilinx evaluation board zcu111
+ items:
+ - enum:
+ - xlnx,zynqmp-zcu111-revA
+ - xlnx,zynqmp-zcu111-rev1.0
+ - const: xlnx,zynqmp-zcu111
+ - const: xlnx,zynqmp
+
+ - description: Xilinx Kria SOMs K24
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sm-k24-rev1
+ - xlnx,zynqmp-sm-k24-revB
+ - xlnx,zynqmp-sm-k24-revA
+ - xlnx,zynqmp-sm-k24
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp
+ - contains:
+ const: xlnx,zynqmp-sm-k24
+
+ - description: Xilinx Kria SOMs K24 (starter)
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-smk-k24-rev1
+ - xlnx,zynqmp-smk-k24-revB
+ - xlnx,zynqmp-smk-k24-revA
+ - xlnx,zynqmp-smk-k24
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp
+ - contains:
+ const: xlnx,zynqmp-smk-k24
+
+ - description: Xilinx Kria SOMs
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sm-k26-rev2
+ - xlnx,zynqmp-sm-k26-rev1
+ - xlnx,zynqmp-sm-k26-revB
+ - xlnx,zynqmp-sm-k26-revA
+ - xlnx,zynqmp-sm-k26
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp
+ - contains:
+ const: xlnx,zynqmp-sm-k26
+
+ - description: Xilinx Kria SOMs (starter)
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-smk-k26-rev2
+ - xlnx,zynqmp-smk-k26-rev1
+ - xlnx,zynqmp-smk-k26-revB
+ - xlnx,zynqmp-smk-k26-revA
+ - xlnx,zynqmp-smk-k26
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp
+ - contains:
+ const: xlnx,zynqmp-smk-k26
+
+ - description: Xilinx Kria SOM KD240 revA/B/1
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sk-kd240-rev1
+ - xlnx,zynqmp-sk-kd240-revB
+ - xlnx,zynqmp-sk-kd240-revA
+ - xlnx,zynqmp-sk-kd240
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp-sk-kd240-revA
+ - contains:
+ const: xlnx,zynqmp-sk-kd240
+ - contains:
+ const: xlnx,zynqmp
+
+ - description: Xilinx Kria SOM KR260 revA/Y/Z
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sk-kr260-revA
+ - xlnx,zynqmp-sk-kr260-revY
+ - xlnx,zynqmp-sk-kr260-revZ
+ - xlnx,zynqmp-sk-kr260
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp-sk-kr260-revA
+ - contains:
+ const: xlnx,zynqmp-sk-kr260
+ - contains:
+ const: xlnx,zynqmp
+
+ - description: Xilinx Kria SOM KR260 rev2/1/B
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sk-kr260-rev2
+ - xlnx,zynqmp-sk-kr260-rev1
+ - xlnx,zynqmp-sk-kr260-revB
+ - xlnx,zynqmp-sk-kr260
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp-sk-kr260-revB
+ - contains:
+ const: xlnx,zynqmp-sk-kr260
+ - contains:
+ const: xlnx,zynqmp
+
+ - description: Xilinx Kria SOM KV260 revA/Y/Z
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sk-kv260-revA
+ - xlnx,zynqmp-sk-kv260-revY
+ - xlnx,zynqmp-sk-kv260-revZ
+ - xlnx,zynqmp-sk-kv260
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp-sk-kv260-revA
+ - contains:
+ const: xlnx,zynqmp-sk-kv260
+ - contains:
+ const: xlnx,zynqmp
+
+ - description: Xilinx Kria SOM KV260 rev2/1/B
+ minItems: 3
+ items:
+ enum:
+ - xlnx,zynqmp-sk-kv260-rev2
+ - xlnx,zynqmp-sk-kv260-rev1
+ - xlnx,zynqmp-sk-kv260-revB
+ - xlnx,zynqmp-sk-kv260
+ - xlnx,zynqmp
+ allOf:
+ - contains:
+ const: xlnx,zynqmp-sk-kv260-revB
+ - contains:
+ const: xlnx,zynqmp-sk-kv260
+ - contains:
+ const: xlnx,zynqmp
+
+ - description: AMD MicroBlaze V (QEMU)
+ items:
+ - const: qemu,mbv
+ - const: amd,mbv
+
+ - description: Xilinx Versal NET VN-X revA platform
+ items:
+ enum:
+ - xlnx,versal-net-vnx-revA
+ - xlnx,versal-net-vnx
+ - xlnx,versal-net
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
deleted file mode 100644
index 2417b13ba468..000000000000
--- a/Documentation/devicetree/bindings/soc/xilinx/xlnx,vcu.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-LogicoreIP designed compatible with Xilinx ZYNQ family.
--------------------------------------------------------
-
-General concept
----------------
-
-LogicoreIP design to provide the isolation between processing system
-and programmable logic. Also provides the list of register set to configure
-the frequency.
-
-Required properties:
-- compatible: shall be one of:
- "xlnx,vcu"
- "xlnx,vcu-logicoreip-1.0"
-- reg : The base offset and size of the VCU_PL_SLCR register space.
-- clocks: phandle for aclk and pll_ref clocksource
-- clock-names: The identification string, "aclk", is always required for
- the axi clock. "pll_ref" is required for pll.
-Example:
-
- xlnx_vcu: vcu@a0040000 {
- compatible = "xlnx,vcu-logicoreip-1.0";
- reg = <0x0 0xa0040000 0x0 0x1000>;
- clocks = <&si570_1>, <&clkc 71>;
- clock-names = "pll_ref", "aclk";
- };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
index 59f7c60a14ba..9a7ff50a0a22 100644
--- a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
+++ b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
@@ -4,16 +4,18 @@
$id: http://devicetree.org/schemas/sound/adi,adau1372.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-
title: Analog Devices ADAU1372 CODEC
maintainers:
- - Alexandre Belloni <alexandre.belloni@bootlin.om>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
description: |
Analog Devices ADAU1372 four inputs and two outputs codec.
https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -29,7 +31,7 @@ properties:
maxItems: 1
clock-names:
- const: "mclk"
+ const: mclk
powerdown-gpios:
description: GPIO used for hardware power-down.
@@ -42,7 +44,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1373.yaml b/Documentation/devicetree/bindings/sound/adi,adau1373.yaml
new file mode 100644
index 000000000000..97552bf5d951
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1373.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau1373.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADAU1373 CODEC
+
+maintainers:
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ Analog Devices ADAU1373 Low power codec with speaker and headphone amplifiers.
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1373.pdf
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,adau1373
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ powerdown-gpios:
+ description: GPIO used for hardware power-down.
+ maxItems: 1
+
+ adi,micbias1-microvolt:
+ description:
+ This property sets the microphone bias voltage for the first microphone.
+ enum: [1800000, 2200000, 2600000, 2900000]
+ default: 2900000
+
+ adi,micbias2-microvolt:
+ description:
+ This property sets the microphone bias voltage for the second microphone.
+ enum: [1800000, 2200000, 2600000, 2900000]
+ default: 2900000
+
+ adi,input1-differential:
+ description: This property sets the first analog input as differential.
+ type: boolean
+
+ adi,input2-differential:
+ description: This property sets the second analog input as differential.
+ type: boolean
+
+ adi,input3-differential:
+ description: This property sets the third analog input as differential.
+ type: boolean
+
+ adi,input4-differential:
+ description: This property sets the fourth analog input as differential.
+ type: boolean
+
+ adi,lineout-differential:
+ description: This property sets the line output as differential.
+ type: boolean
+
+ adi,lineout-gnd-sense:
+ description: This property enables the line output ground sense control.
+ type: boolean
+
+ adi,drc-settings:
+ description:
+ This setting is used to control the dynamic range of the signal. The
+ device provides a maximum of three full band DRCs with 13 entries each.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ oneOf:
+ - minItems: 13
+ maxItems: 13
+ - minItems: 26
+ maxItems: 26
+ - minItems: 39
+ maxItems: 39
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@1a {
+ compatible = "adi,adau1373";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ powerdown-gpios = <&gpio 100 GPIO_ACTIVE_LOW>;
+ adi,input2-differential;
+ adi,input1-differential;
+ adi,lineout-differential;
+ adi,micbias2-microvolt = <1800000>;
+ adi,drc-settings = /bits/ 8 <
+ 0xff 0xff 0x1 0x2 0xa 0xa 0xd 0x1 0xff 0xff 0x5 0xd 0xff
+ >;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/adi,adau17x1.txt b/Documentation/devicetree/bindings/sound/adi,adau17x1.txt
deleted file mode 100644
index 1447dec28125..000000000000
--- a/Documentation/devicetree/bindings/sound/adi,adau17x1.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Analog Devices ADAU1361/ADAU1461/ADAU1761/ADAU1961/ADAU1381/ADAU1781
-
-Required properties:
-
- - compatible: Should contain one of the following:
- "adi,adau1361"
- "adi,adau1461"
- "adi,adau1761"
- "adi,adau1961"
- "adi,adau1381"
- "adi,adau1781"
-
- - reg: The i2c address. Value depends on the state of ADDR0
- and ADDR1, as wired in hardware.
-
-Optional properties:
- - clock-names: If provided must be "mclk".
- - clocks: phandle + clock-specifiers for the clock that provides
- the audio master clock for the device.
-
-Examples:
-#include <dt-bindings/sound/adau17x1.h>
-
- i2c_bus {
- adau1361@38 {
- compatible = "adi,adau1761";
- reg = <0x38>;
-
- clock-names = "mclk";
- clocks = <&audio_clock>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau17x1.yaml b/Documentation/devicetree/bindings/sound/adi,adau17x1.yaml
new file mode 100644
index 000000000000..8ef1e7f6ec91
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau17x1.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau17x1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADAU1361/ADAU1461/ADAU1761/ADAU1961/ADAU1381/ADAU1781 Codec
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+properties:
+ compatible:
+ enum:
+ - adi,adau1361
+ - adi,adau1381
+ - adi,adau1461
+ - adi,adau1761
+ - adi,adau1781
+ - adi,adau1961
+
+ reg:
+ maxItems: 1
+ description:
+ The i2c address. Value depends on the state of ADDR0 and ADDR1,
+ as wired in hardware.
+
+ clock-names:
+ const: mclk
+
+ clocks:
+ items:
+ - description: provides the audio master clock for the device.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@38 {
+ compatible = "adi,adau1761";
+ reg = <0x38>;
+ clock-names = "mclk";
+ clocks = <&audio_clock>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.yaml b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
index 847b83398d3d..dba3023a45e5 100644
--- a/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
+++ b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
@@ -51,6 +51,7 @@ required:
- AVDD-supply
allOf:
+ - $ref: dai-common.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/sound/adi,adau7002.txt b/Documentation/devicetree/bindings/sound/adi,adau7002.txt
deleted file mode 100644
index f144ee1abf85..000000000000
--- a/Documentation/devicetree/bindings/sound/adi,adau7002.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Analog Devices ADAU7002 Stereo PDM-to-I2S/TDM Converter
-
-Required properties:
-
- - compatible: Must be "adi,adau7002"
-
-Optional properties:
-
- - IOVDD-supply: Phandle and specifier for the power supply providing the IOVDD
- supply as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
- If this property is not present it is assumed that the supply pin is
- hardwired to always on.
-
-Example:
- adau7002: pdm-to-i2s {
- compatible = "adi,adau7002";
- IOVDD-supply = <&supply>;
- };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau7002.yaml b/Documentation/devicetree/bindings/sound/adi,adau7002.yaml
new file mode 100644
index 000000000000..7858f3f8ec2f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau7002.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau7002.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADAU7002 Stereo PDM-to-I2S/TDM Converter
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: adi,adau7002
+
+ IOVDD-supply:
+ description:
+ IOVDD power supply, if skipped then it is assumed that the supply pin is
+ hardwired to always on.
+
+ wakeup-delay-ms:
+ description:
+ Delay after power up needed for device to settle.
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ audio-codec {
+ compatible = "adi,adau7002";
+ IOVDD-supply = <&pp1800_l15a>;
+ #sound-dai-cells = <0>;
+ wakeup-delay-ms = <80>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau7118.yaml b/Documentation/devicetree/bindings/sound/adi,adau7118.yaml
index fb78967ee17b..11f59c29b575 100644
--- a/Documentation/devicetree/bindings/sound/adi,adau7118.yaml
+++ b/Documentation/devicetree/bindings/sound/adi,adau7118.yaml
@@ -4,7 +4,6 @@
$id: http://devicetree.org/schemas/sound/adi,adau7118.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-
title: Analog Devices ADAU7118 8 Channel PDM to I2S/TDM Converter
maintainers:
@@ -15,6 +14,9 @@ description: |
standalone mode.
https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU7118.pdf
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -57,7 +59,7 @@ required:
- iovdd-supply
- dvdd-supply
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/adi,max98388.yaml b/Documentation/devicetree/bindings/sound/adi,max98388.yaml
new file mode 100644
index 000000000000..93ccd5905736
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,max98388.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,max98388.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX98388 Speaker Amplifier
+
+maintainers:
+ - Ryan Lee <ryans.lee@analog.com>
+
+description:
+ The MAX98388 is a mono Class-D speaker amplifier with I/V feedback.
+ The device provides a PCM interface for audio data and a standard
+ I2C interface for control data communication.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,max98388
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ adi,vmon-slot-no:
+ description: slot number of the voltage feedback monitor
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 0
+
+ adi,imon-slot-no:
+ description: slot number of the current feedback monitor
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ default: 1
+
+ adi,interleave-mode:
+ description:
+ For cases where a single combined channel for the I/V feedback data
+ is not sufficient, the device can also be configured to share
+ a single data output channel on alternating frames.
+ In this configuration, the current and voltage data will be frame
+ interleaved on a single output channel.
+ type: boolean
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ max98388: amplifier@39 {
+ compatible = "adi,max98388";
+ reg = <0x39>;
+ #sound-dai-cells = <0>;
+ adi,vmon-slot-no = <0>;
+ adi,imon-slot-no = <1>;
+ adi,interleave-mode;
+ reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/adi,max98396.yaml b/Documentation/devicetree/bindings/sound/adi,max98396.yaml
index 7985b1410017..bdc10d4204ec 100644
--- a/Documentation/devicetree/bindings/sound/adi,max98396.yaml
+++ b/Documentation/devicetree/bindings/sound/adi,max98396.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/adi,max98396.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices MAX98396 Speaker Amplifier Device Tree Bindings
+title: Analog Devices MAX98396 Speaker Amplifier
maintainers:
- Ryan Lee <ryans.lee@analog.com>
@@ -41,21 +41,21 @@ properties:
adi,vmon-slot-no:
description: slot number of the voltage sense monitor
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
default: 0
adi,imon-slot-no:
description: slot number of the current sense monitor
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
default: 1
adi,spkfb-slot-no:
description: slot number of speaker DSP monitor
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
default: 2
@@ -64,7 +64,7 @@ properties:
description:
Selects the PCM data input channel that is routed to the speaker
audio processing bypass path.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
default: 0
diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml
new file mode 100644
index 000000000000..f1beae84cad1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,ssm2518.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,ssm2518.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices SSM2518 audio amplifier
+
+maintainers:
+ - Lars-Peter Clausen <lars@metafoo.de>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: adi,ssm2518
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the device. This will either be 0x34 (ADDR pin low)
+ or 0x35 (ADDR pin high)
+
+ gpios:
+ maxItems: 1
+ description: |
+ GPIO connected to the nSD pin. If the property is not present
+ it is assumed that the nSD pin is hardwired to always on.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@34 {
+ compatible = "adi,ssm2518";
+ reg = <0x34>;
+ gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
deleted file mode 100644
index 3b3302fe399b..000000000000
--- a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Analog Devices SSM2602, SSM2603 and SSM2604 I2S audio CODEC devices
-
-SSM2602 support both I2C and SPI as the configuration interface,
-the selection is made by the MODE strap-in pin.
-SSM2603 and SSM2604 only support I2C as the configuration interface.
-
-Required properties:
-
- - compatible : One of "adi,ssm2602", "adi,ssm2603" or "adi,ssm2604"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
- Example:
-
- ssm2602: ssm2602@1a {
- compatible = "adi,ssm2602";
- reg = <0x1a>;
- };
diff --git a/Documentation/devicetree/bindings/sound/ak4104.txt b/Documentation/devicetree/bindings/sound/ak4104.txt
deleted file mode 100644
index ae5f7f057dc3..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4104.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-AK4104 S/PDIF transmitter
-
-This device supports SPI mode only.
-
-Required properties:
-
- - compatible : "asahi-kasei,ak4104"
-
- - reg : The chip select number on the SPI bus
-
- - vdd-supply : A regulator node, providing 2.7V - 3.6V
-
-Optional properties:
-
- - reset-gpios : a GPIO spec for the reset pin. If specified, it will be
- deasserted before communication to the device starts.
-
-Example:
-
-spdif: ak4104@0 {
- compatible = "asahi-kasei,ak4104";
- reg = <0>;
- spi-max-frequency = <5000000>;
- vdd-supply = <&vdd_3v3_reg>;
-};
diff --git a/Documentation/devicetree/bindings/sound/ak4375.yaml b/Documentation/devicetree/bindings/sound/ak4375.yaml
deleted file mode 100644
index f1d5074a024d..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4375.yaml
+++ /dev/null
@@ -1,57 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/ak4375.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: AK4375 DAC and headphones amplifier Device Tree Bindings
-
-maintainers:
- - Vincent Knecht <vincent.knecht@mailoo.org>
-
-properties:
- compatible:
- const: asahi-kasei,ak4375
-
- reg:
- maxItems: 1
-
- '#sound-dai-cells':
- const: 0
-
- avdd-supply:
- description: regulator phandle for the AVDD power supply.
-
- tvdd-supply:
- description: regulator phandle for the TVDD power supply.
-
- pdn-gpios:
- description: optional GPIO to set the PDN pin.
-
-required:
- - compatible
- - reg
- - '#sound-dai-cells'
- - avdd-supply
- - tvdd-supply
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- headphones: audio-codec@10 {
- compatible = "asahi-kasei,ak4375";
- reg = <0x10>;
- avdd-supply = <&reg_headphones_avdd>;
- tvdd-supply = <&pm8916_l6>;
- pdn-gpios = <&msmgpio 114 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&headphones_pdn_default>;
- #sound-dai-cells = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt b/Documentation/devicetree/bindings/sound/ak4458.txt
deleted file mode 100644
index 0416c14895d6..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4458.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-AK4458 audio DAC
-
-This device supports I2C mode.
-
-Required properties:
-
-- compatible : "asahi-kasei,ak4458" or "asahi-kasei,ak4497"
-- reg : The I2C address of the device for I2C
-
-Optional properties:
-- reset-gpios: A GPIO specifier for the power down & reset pin
-- mute-gpios: A GPIO specifier for the soft mute pin
-- AVDD-supply: Analog power supply
-- DVDD-supply: Digital power supply
-- dsd-path: Select DSD input pins for ak4497
- 0: select #16, #17, #19 pins
- 1: select #3, #4, #5 pins
-
-Example:
-
-&i2c {
- ak4458: dac@10 {
- compatible = "asahi-kasei,ak4458";
- reg = <0x10>;
- reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>
- mute-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/ak4554.txt b/Documentation/devicetree/bindings/sound/ak4554.txt
deleted file mode 100644
index 934fa02754b3..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4554.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-AK4554 ADC/DAC
-
-Required properties:
-
- - compatible : "asahi-kasei,ak4554"
-
-Example:
-
-ak4554-adc-dac {
- compatible = "asahi-kasei,ak4554";
-};
diff --git a/Documentation/devicetree/bindings/sound/ak4613.yaml b/Documentation/devicetree/bindings/sound/ak4613.yaml
deleted file mode 100644
index ef4055ef0ccd..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4613.yaml
+++ /dev/null
@@ -1,49 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/ak4613.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: AK4613 I2C transmitter Device Tree Bindings
-
-maintainers:
- - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
-
-properties:
- compatible:
- const: asahi-kasei,ak4613
-
- reg:
- maxItems: 1
-
- clocks:
- maxItems: 1
-
- "#sound-dai-cells":
- const: 0
-
-patternProperties:
- "^asahi-kasei,in[1-2]-single-end$":
- description: Input Pin 1 - 2.
- $ref: /schemas/types.yaml#/definitions/flag
-
- "^asahi-kasei,out[1-6]-single-end$":
- description: Output Pin 1 - 6.
- $ref: /schemas/types.yaml#/definitions/flag
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- ak4613: codec@10 {
- compatible = "asahi-kasei,ak4613";
- reg = <0x10>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/ak4642.yaml b/Documentation/devicetree/bindings/sound/ak4642.yaml
deleted file mode 100644
index 1e2caa29790e..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4642.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/ak4642.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: AK4642 I2C transmitter Device Tree Bindings
-
-maintainers:
- - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
-
-properties:
- compatible:
- enum:
- - asahi-kasei,ak4642
- - asahi-kasei,ak4643
- - asahi-kasei,ak4648
-
- reg:
- maxItems: 1
-
- "#clock-cells":
- const: 0
- "#sound-dai-cells":
- const: 0
-
- clocks:
- maxItems: 1
-
- clock-frequency:
- description: common clock binding; frequency of MCKO
-
- clock-output-names:
- description: common clock name
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- ak4643: codec@12 {
- compatible = "asahi-kasei,ak4643";
- #sound-dai-cells = <0>;
- reg = <0x12>;
- #clock-cells = <0>;
- clocks = <&audio_clock>;
- clock-frequency = <12288000>;
- clock-output-names = "ak4643_mcko";
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt b/Documentation/devicetree/bindings/sound/ak5558.txt
deleted file mode 100644
index e28708db6686..000000000000
--- a/Documentation/devicetree/bindings/sound/ak5558.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-AK5558 8 channel differential 32-bit delta-sigma ADC
-
-This device supports I2C mode only.
-
-Required properties:
-
-- compatible : "asahi-kasei,ak5558" or "asahi-kasei,ak5552".
-- reg : The I2C address of the device.
-
-Optional properties:
-
-- reset-gpios: A GPIO specifier for the power down & reset pin.
-- AVDD-supply: Analog power supply
-- DVDD-supply: Digital power supply
-
-Example:
-
-&i2c {
- ak5558: adc@10 {
- compatible = "asahi-kasei,ak5558";
- reg = <0x10>;
- reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/alc5623.txt b/Documentation/devicetree/bindings/sound/alc5623.txt
deleted file mode 100644
index 26c86c98d671..000000000000
--- a/Documentation/devicetree/bindings/sound/alc5623.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-ALC5621/ALC5622/ALC5623 audio Codec
-
-Required properties:
-
- - compatible: "realtek,alc5623"
- - reg: the I2C address of the device.
-
-Optional properties:
-
- - add-ctrl: Default register value for Reg-40h, Additional Control
- Register. If absent or has the value of 0, the
- register is untouched.
-
- - jack-det-ctrl: Default register value for Reg-5Ah, Jack Detect
- Control Register. If absent or has value 0, the
- register is untouched.
-
-Example:
-
- alc5621: alc5621@1a {
- compatible = "alc5621";
- reg = <0x1a>;
- add-ctrl = <0x3700>;
- jack-det-ctrl = <0x4810>;
- };
diff --git a/Documentation/devicetree/bindings/sound/alc5632.txt b/Documentation/devicetree/bindings/sound/alc5632.txt
deleted file mode 100644
index ffd886d110bd..000000000000
--- a/Documentation/devicetree/bindings/sound/alc5632.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-ALC5632 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "realtek,alc5632"
-
- - reg : the I2C address of the device.
-
- - gpio-controller : Indicates this device is a GPIO controller.
-
- - #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters (currently unused).
-
-Pins on the device (for linking into audio routes):
-
- * SPK_OUTP
- * SPK_OUTN
- * HP_OUT_L
- * HP_OUT_R
- * AUX_OUT_P
- * AUX_OUT_N
- * LINE_IN_L
- * LINE_IN_R
- * PHONE_P
- * PHONE_N
- * MIC1_P
- * MIC1_N
- * MIC2_P
- * MIC2_N
- * MICBIAS1
- * DMICDAT
-
-Example:
-
-alc5632: alc5632@1e {
- compatible = "realtek,alc5632";
- reg = <0x1a>;
-
- gpio-controller;
- #gpio-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
index 559aff13ae23..b4eca702febc 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/allwinner,sun4i-a10-codec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Codec Device Tree Bindings
+title: Allwinner A10 Codec
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -22,6 +22,8 @@ properties:
- allwinner,sun8i-a23-codec
- allwinner,sun8i-h3-codec
- allwinner,sun8i-v3s-codec
+ - allwinner,sun50i-h616-codec
+ - allwinner,suniv-f1c100s-codec
reg:
maxItems: 1
@@ -40,14 +42,20 @@ properties:
- const: codec
dmas:
- items:
- - description: RX DMA Channel
- - description: TX DMA Channel
+ oneOf:
+ - items:
+ - description: RX DMA Channel
+ - description: TX DMA Channel
+ - items:
+ - description: TX DMA Channel
dma-names:
- items:
- - const: rx
- - const: tx
+ oneOf:
+ - items:
+ - const: rx
+ - const: tx
+ - items:
+ - const: tx
resets:
maxItems: 1
@@ -70,6 +78,7 @@ properties:
- MIC1
- MIC2
- MIC3
+ - MIC
# Microphone Biases from the SoC
- HBIAS
@@ -80,6 +89,8 @@ properties:
- Headset Mic
- Line In
- Line Out
+ - Right FM In
+ - Left FM In
- Mic
- Speaker
@@ -91,6 +102,10 @@ properties:
maxItems: 1
description: GPIO to enable the external amplifier
+ hp-det-gpios:
+ maxItems: 1
+ description: GPIO for headphone/line-out detection
+
required:
- "#sound-dai-cells"
- compatible
@@ -102,6 +117,7 @@ required:
- dma-names
allOf:
+ - $ref: dai-common.yaml#
- if:
properties:
compatible:
@@ -228,7 +244,70 @@ allOf:
- Mic
- Speaker
-additionalProperties: false
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,sun50i-h616-codec
+
+ then:
+ properties:
+ allwinner,audio-routing:
+ items:
+ enum:
+ - Headphone
+ - LINEOUT
+ - Line Out
+ - Speaker
+
+ dmas:
+ items:
+ - description: TX DMA Channel
+
+ dma-names:
+ items:
+ - const: tx
+
+ else:
+ properties:
+ dmas:
+ items:
+ - description: RX DMA Channel
+ - description: TX DMA Channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - allwinner,suniv-f1c100s-codec
+
+ then:
+ properties:
+ allwinner,audio-routing:
+ items:
+ enum:
+ - HP
+ - HPCOM
+ - LINEIN
+ - LINEOUT
+ - MIC
+ - HBIAS
+ - MBIAS
+ - Headphone
+ - Headset Mic
+ - Line In
+ - Line Out
+ - Right FM In
+ - Left FM In
+ - Mic
+ - Speaker
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
index 34f6ee9de392..ae86cb5f0a74 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/allwinner,sun4i-a10-i2s.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 I2S Controller Device Tree Bindings
+title: Allwinner A10 I2S Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -33,7 +33,9 @@ properties:
- const: allwinner,sun50i-h6-i2s
- const: allwinner,sun50i-r329-i2s
- items:
- - const: allwinner,sun20i-d1-i2s
+ - enum:
+ - allwinner,sun20i-d1-i2s
+ - allwinner,sun55i-a523-i2s
- const: allwinner,sun50i-r329-i2s
reg:
@@ -61,6 +63,7 @@ properties:
maxItems: 1
allOf:
+ - $ref: dai-common.yaml#
- if:
properties:
compatible:
@@ -128,7 +131,7 @@ required:
- dmas
- dma-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml
index 444a432912bb..1d089ba70f45 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/allwinner,sun4i-a10-spdif.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 S/PDIF Controller Device Tree Bindings
+title: Allwinner A10 S/PDIF Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -22,6 +22,8 @@ properties:
- const: allwinner,sun6i-a31-spdif
- const: allwinner,sun8i-h3-spdif
- const: allwinner,sun50i-h6-spdif
+ - const: allwinner,sun50i-h616-spdif
+ - const: allwinner,sun55i-a523-spdif
- items:
- const: allwinner,sun8i-a83t-spdif
- const: allwinner,sun8i-h3-spdif
@@ -36,14 +38,12 @@ properties:
maxItems: 1
clocks:
- items:
- - description: Bus Clock
- - description: Module Clock
+ minItems: 2
+ maxItems: 3
clock-names:
- items:
- - const: apb
- - const: spdif
+ minItems: 2
+ maxItems: 3
# Even though it only applies to subschemas under the conditionals,
# not listing them here will trigger a warning because of the
@@ -54,6 +54,7 @@ properties:
maxItems: 1
allOf:
+ - $ref: dai-common.yaml#
- if:
properties:
compatible:
@@ -61,6 +62,9 @@ allOf:
enum:
- allwinner,sun6i-a31-spdif
- allwinner,sun8i-h3-spdif
+ - allwinner,sun50i-h6-spdif
+ - allwinner,sun50i-h616-spdif
+ - allwinner,sun55i-a523-spdif
then:
required:
@@ -72,7 +76,7 @@ allOf:
contains:
enum:
- allwinner,sun8i-h3-spdif
- - allwinner,sun50i-h6-spdif
+ - allwinner,sun50i-h616-spdif
then:
properties:
@@ -94,6 +98,38 @@ allOf:
- const: rx
- const: tx
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun55i-a523-spdif
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Bus Clock
+ - description: TX Clock
+ - description: RX Clock
+
+ clock-names:
+ items:
+ - const: apb
+ - const: tx
+ - const: rx
+ else:
+ properties:
+ clocks:
+ items:
+ - description: Bus Clock
+ - description: Module Clock
+
+ clock-names:
+ items:
+ - const: apb
+ - const: spdif
+
required:
- "#sound-dai-cells"
- compatible
@@ -104,7 +140,7 @@ required:
- dmas
- dma-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml
index 66859eb8f79a..5800de63fc84 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun50i-a64-codec-analog.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/allwinner,sun50i-a64-codec-analog.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A64 Analog Codec Device Tree Bindings
+title: Allwinner A64 Analog Codec
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml
index 2f12cabe4c71..763b876047c1 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml
@@ -9,9 +9,17 @@ title: Allwinner H6 DMIC
maintainers:
- Ban Tao <fengzheng923@gmail.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
- const: allwinner,sun50i-h6-dmic
+ oneOf:
+ - items:
+ - enum:
+ - allwinner,sun20i-d1-dmic
+ - const: allwinner,sun50i-h6-dmic
+ - const: allwinner,sun50i-h6-dmic
"#sound-dai-cells":
const: 0
@@ -54,7 +62,7 @@ required:
- dma-names
- resets
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml
index 26eca21e1f0f..1c21a1b390c7 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a23-codec-analog.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/allwinner,sun8i-a23-codec-analog.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A23 Analog Codec Device Tree Bindings
+title: Allwinner A23 Analog Codec
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
index 19f111f40225..63eadc4200ac 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
@@ -4,12 +4,15 @@
$id: http://devicetree.org/schemas/sound/allwinner,sun8i-a33-codec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A33 Codec Device Tree Bindings
+title: Allwinner A33 Codec
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
"#sound-dai-cells":
minimum: 0
@@ -49,7 +52,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml b/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml
index 0705f91199a0..6350dfc0a926 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml
@@ -10,7 +10,7 @@ maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt
deleted file mode 100644
index fa4545ed81ca..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* Amlogic Audio FIFO controllers
-
-Required properties:
-- compatible: 'amlogic,axg-toddr' or
- 'amlogic,axg-toddr' or
- 'amlogic,g12a-frddr' or
- 'amlogic,g12a-toddr' or
- 'amlogic,sm1-frddr' or
- 'amlogic,sm1-toddr'
-- reg: physical base address of the controller and length of memory
- mapped region.
-- interrupts: interrupt specifier for the fifo.
-- clocks: phandle to the fifo peripheral clock provided by the audio
- clock controller.
-- resets: list of reset phandle, one for each entry reset-names.
-- reset-names: should contain the following:
- * "arb" : memory ARB line (required)
- * "rst" : dedicated device reset line (optional)
-- #sound-dai-cells: must be 0.
-- amlogic,fifo-depth: The size of the controller's fifo in bytes. This
- is useful for determining certain configuration such
- as the flush threshold of the fifo
-
-Example of FRDDR A on the A113 SoC:
-
-frddr_a: audio-controller@1c0 {
- compatible = "amlogic,axg-frddr";
- reg = <0x0 0x1c0 0x0 0x1c>;
- #sound-dai-cells = <0>;
- interrupts = <GIC_SPI 88 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clkc_audio AUD_CLKID_FRDDR_A>;
- resets = <&arb AXG_ARB_FRDDR_A>;
- fifo-depth = <512>;
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml
new file mode 100644
index 000000000000..b1b48d683101
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-fifo.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-fifo.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic AXG Audio FIFO controllers
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,axg-toddr
+ - amlogic,axg-frddr
+ - items:
+ - enum:
+ - amlogic,g12a-toddr
+ - amlogic,sm1-toddr
+ - const: amlogic,axg-toddr
+ - items:
+ - enum:
+ - amlogic,g12a-frddr
+ - amlogic,sm1-frddr
+ - const: amlogic,axg-frddr
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+
+ amlogic,fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Size of the controller's fifo in bytes
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - interrupts
+ - resets
+ - amlogic,fifo-depth
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-toddr
+ - amlogic,sm1-toddr
+ - amlogic,g12a-frddr
+ - amlogic,sm1-frddr
+
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ items:
+ - const: arb
+ - const: rst
+ required:
+ - reset-names
+
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ const: arb
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/amlogic,meson-axg-audio-arb.h>
+ #include <dt-bindings/reset/amlogic,meson-g12a-audio-reset.h>
+
+ audio-controller@1c0 {
+ compatible = "amlogic,g12a-frddr", "amlogic,axg-frddr";
+ reg = <0x1c0 0x1c>;
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_FRDDR_A>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_EDGE_RISING>;
+ resets = <&arb>, <&clkc_audio AUD_RESET_FRDDR_A>;
+ reset-names = "arb", "rst";
+ amlogic,fifo-depth = <512>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt
deleted file mode 100644
index 716878107a24..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Amlogic Audio PDM input
-
-Required properties:
-- compatible: 'amlogic,axg-pdm' or
- 'amlogic,g12a-pdm' or
- 'amlogic,sm1-pdm'
-- reg: physical base address of the controller and length of memory
- mapped region.
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "dclk" : pdm digital clock
- * "sysclk" : dsp system clock
-- #sound-dai-cells: must be 0.
-
-Optional property:
-- resets: phandle to the dedicated reset line of the pdm input.
-
-Example of PDM on the A113 SoC:
-
-pdm: audio-controller@ff632000 {
- compatible = "amlogic,axg-pdm";
- reg = <0x0 0xff632000 0x0 0x34>;
- #sound-dai-cells = <0>;
- clocks = <&clkc_audio AUD_CLKID_PDM>,
- <&clkc_audio AUD_CLKID_PDM_DCLK>,
- <&clkc_audio AUD_CLKID_PDM_SYSCLK>;
- clock-names = "pclk", "dclk", "sysclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml
new file mode 100644
index 000000000000..df21dd72fc65
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-pdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG PDM input
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12a-pdm
+ - amlogic,sm1-pdm
+ - const: amlogic,axg-pdm
+ - const: amlogic,axg-pdm
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: PDM digital clock
+ - description: DSP system clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: dclk
+ - const: sysclk
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-pdm
+ - amlogic,sm1-pdm
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+
+ audio-controller@ff632000 {
+ compatible = "amlogic,axg-pdm";
+ reg = <0xff632000 0x34>;
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_PDM>,
+ <&clkc_audio AUD_CLKID_PDM_DCLK>,
+ <&clkc_audio AUD_CLKID_PDM_SYSCLK>;
+ clock-names = "pclk", "dclk", "sysclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt
deleted file mode 100644
index 80b411296480..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.txt
+++ /dev/null
@@ -1,124 +0,0 @@
-Amlogic AXG sound card:
-
-Required properties:
-
-- compatible: "amlogic,axg-sound-card"
-- model : User specified audio sound card name, one string
-
-Optional properties:
-
-- audio-aux-devs : List of phandles pointing to auxiliary devices
-- audio-widgets : Please refer to widgets.txt.
-- audio-routing : A list of the connections between audio components.
-
-Subnodes:
-
-- dai-link: Container for dai-link level properties and the CODEC
- sub-nodes. There should be at least one (and probably more)
- subnode of this type.
-
-Required dai-link properties:
-
-- sound-dai: phandle and port of the CPU DAI.
-
-Required TDM Backend dai-link properties:
-- dai-format : CPU/CODEC common audio format
-
-Optional TDM Backend dai-link properties:
-- dai-tdm-slot-rx-mask-{0,1,2,3}: Receive direction slot masks
-- dai-tdm-slot-tx-mask-{0,1,2,3}: Transmit direction slot masks
- When omitted, mask is assumed to have to no
- slots. A valid must have at one slot, so at
- least one these mask should be provided with
- an enabled slot.
-- dai-tdm-slot-num : Please refer to tdm-slot.txt.
- If omitted, slot number is set to accommodate the largest
- mask provided.
-- dai-tdm-slot-width : Please refer to tdm-slot.txt. default to 32 if omitted.
-- mclk-fs : Multiplication factor between stream rate and mclk
-
-Backend dai-link subnodes:
-
-- codec: dai-link representing backend links should have at least one subnode.
- One subnode for each codec of the dai-link.
- dai-link representing frontend links have no codec, therefore have no
- subnodes
-
-Required codec subnodes properties:
-
-- sound-dai: phandle and port of the CODEC DAI.
-
-Optional codec subnodes properties:
-
-- dai-tdm-slot-tx-mask : Please refer to tdm-slot.txt.
-- dai-tdm-slot-rx-mask : Please refer to tdm-slot.txt.
-
-Example:
-
-sound {
- compatible = "amlogic,axg-sound-card";
- model = "AXG-S420";
- audio-aux-devs = <&tdmin_a>, <&tdmout_c>;
- audio-widgets = "Line", "Lineout",
- "Line", "Linein",
- "Speaker", "Speaker1 Left",
- "Speaker", "Speaker1 Right";
- "Speaker", "Speaker2 Left",
- "Speaker", "Speaker2 Right";
- audio-routing = "TDMOUT_C IN 0", "FRDDR_A OUT 2",
- "SPDIFOUT IN 0", "FRDDR_A OUT 3",
- "TDM_C Playback", "TDMOUT_C OUT",
- "TDMIN_A IN 2", "TDM_C Capture",
- "TDMIN_A IN 5", "TDM_C Loopback",
- "TODDR_A IN 0", "TDMIN_A OUT",
- "Lineout", "Lineout AOUTL",
- "Lineout", "Lineout AOUTR",
- "Speaker1 Left", "SPK1 OUT_A",
- "Speaker2 Left", "SPK2 OUT_A",
- "Speaker1 Right", "SPK1 OUT_B",
- "Speaker2 Right", "SPK2 OUT_B",
- "Linein AINL", "Linein",
- "Linein AINR", "Linein";
-
- dai-link@0 {
- sound-dai = <&frddr_a>;
- };
-
- dai-link@1 {
- sound-dai = <&toddr_a>;
- };
-
- dai-link@2 {
- sound-dai = <&tdmif_c>;
- dai-format = "i2s";
- dai-tdm-slot-tx-mask-2 = <1 1>;
- dai-tdm-slot-tx-mask-3 = <1 1>;
- dai-tdm-slot-rx-mask-1 = <1 1>;
- mclk-fs = <256>;
-
- codec@0 {
- sound-dai = <&lineout>;
- };
-
- codec@1 {
- sound-dai = <&speaker_amp1>;
- };
-
- codec@2 {
- sound-dai = <&speaker_amp2>;
- };
-
- codec@3 {
- sound-dai = <&linein>;
- };
-
- };
-
- dai-link@3 {
- sound-dai = <&spdifout>;
-
- codec {
- sound-dai = <&spdif_dit>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
new file mode 100644
index 000000000000..4f13e8ab50b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-sound-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic AXG sound card
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+allOf:
+ - $ref: sound-card-common.yaml#
+
+properties:
+ compatible:
+ const: amlogic,axg-sound-card
+
+ audio-aux-devs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: list of auxiliary devices
+
+ audio-widgets:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list off component DAPM widget. Each entry is a pair of strings,
+ the first being the widget type, the second being the widget name
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+ description:
+ Base PLL clocks of audio susbsytem, used to configure base clock
+ frequencies for different audio use-cases.
+
+patternProperties:
+ "^dai-link-[0-9]+$":
+ type: object
+ additionalProperties: false
+ description:
+ Container for dai-link level properties and the CODEC sub-nodes.
+ There should be at least one (and probably more) subnode of this type
+
+ properties:
+ dai-format:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ i2s, left-j, dsp_a ]
+
+ dai-tdm-slot-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of slots in use. If omitted, slot number is set to
+ accommodate the largest mask provided.
+ maximum: 32
+
+ dai-tdm-slot-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Width in bits for each slot
+ enum: [ 8, 16, 20, 24, 32 ]
+ default: 32
+
+ mclk-fs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Multiplication factor between the frame rate and master clock
+ rate
+
+ sound-dai:
+ maxItems: 1
+ description: phandle of the CPU DAI
+
+ patternProperties:
+ "^dai-tdm-slot-(t|r)x-mask-[0-3]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 32
+ description:
+ Transmit and receive cpu slot masks of each TDM lane
+ When omitted, mask is assumed to have to no slots. A valid
+ interface must have at least one slot, so at least one these
+ mask should be provided with an enabled slot.
+
+ "^codec(-[0-9]+)?$":
+ type: object
+ additionalProperties: false
+ description:
+ dai-link representing backend links should have at least one subnode.
+ One subnode for each codec of the dai-link. dai-link representing
+ frontend links have no codec, therefore have no subnodes
+
+ properties:
+ sound-dai:
+ maxItems: 1
+ description: phandle of the codec DAI
+
+ patternProperties:
+ "^dai-tdm-slot-(t|r)x-mask$":
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 32
+ description: Transmit and receive codec slot masks
+
+ required:
+ - sound-dai
+
+ required:
+ - sound-dai
+
+required:
+ - dai-link-0
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "AXG-S420";
+ audio-aux-devs = <&tdmin_a>, <&tdmout_c>;
+ audio-widgets = "Line", "Lineout",
+ "Line", "Linein",
+ "Speaker", "Speaker1 Left",
+ "Speaker", "Speaker1 Right",
+ "Speaker", "Speaker2 Left",
+ "Speaker", "Speaker2 Right";
+ audio-routing = "TDMOUT_C IN 0", "FRDDR_A OUT 2",
+ "SPDIFOUT IN 0", "FRDDR_A OUT 3",
+ "TDM_C Playback", "TDMOUT_C OUT",
+ "TDMIN_A IN 2", "TDM_C Capture",
+ "TDMIN_A IN 5", "TDM_C Loopback",
+ "TODDR_A IN 0", "TDMIN_A OUT",
+ "Lineout", "Lineout AOUTL",
+ "Lineout", "Lineout AOUTR",
+ "Speaker1 Left", "SPK1 OUT_A",
+ "Speaker2 Left", "SPK2 OUT_A",
+ "Speaker1 Right", "SPK1 OUT_B",
+ "Speaker2 Right", "SPK2 OUT_B",
+ "Linein AINL", "Linein",
+ "Linein AINR", "Linein";
+
+ dai-link-0 {
+ sound-dai = <&frddr_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&toddr_a>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&tdmif_c>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ dai-tdm-slot-rx-mask-1 = <1 1>;
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&lineout>;
+ };
+
+ codec-1 {
+ sound-dai = <&speaker_amp1>;
+ };
+
+ codec-2 {
+ sound-dai = <&speaker_amp2>;
+ };
+
+ codec-3 {
+ sound-dai = <&linein>;
+ };
+ };
+
+ dai-link-3 {
+ sound-dai = <&spdifout>;
+
+ codec {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt
deleted file mode 100644
index df92a4ecf288..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Amlogic Audio SPDIF Input
-
-Required properties:
-- compatible: 'amlogic,axg-spdifin' or
- 'amlogic,g12a-spdifin' or
- 'amlogic,sm1-spdifin'
-- interrupts: interrupt specifier for the spdif input.
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "refclk" : spdif input reference clock
-- #sound-dai-cells: must be 0.
-
-Optional property:
-- resets: phandle to the dedicated reset line of the spdif input.
-
-Example on the A113 SoC:
-
-spdifin: audio-controller@400 {
- compatible = "amlogic,axg-spdifin";
- reg = <0x0 0x400 0x0 0x30>;
- #sound-dai-cells = <0>;
- interrupts = <GIC_SPI 87 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clkc_audio AUD_CLKID_SPDIFIN>,
- <&clkc_audio AUD_CLKID_SPDIFIN_CLK>;
- clock-names = "pclk", "refclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml
new file mode 100644
index 000000000000..a0bd7a5fb9b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifin.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-spdifin.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG SPDIF Input
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,axg-spdifin
+ - items:
+ - enum:
+ - amlogic,g12a-spdifin
+ - amlogic,sm1-spdifin
+ - const: amlogic,axg-spdifin
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: SPDIF input reference clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: refclk
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+ - interrupts
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-spdifin
+ - amlogic,sm1-spdifin
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ audio-controller@400 {
+ compatible = "amlogic,axg-spdifin";
+ reg = <0x400 0x30>;
+ #sound-dai-cells = <0>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc_audio AUD_CLKID_SPDIFIN>,
+ <&clkc_audio AUD_CLKID_SPDIFIN_CLK>;
+ clock-names = "pclk", "refclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt
deleted file mode 100644
index 28381dd1f633..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Amlogic Audio SPDIF Output
-
-Required properties:
-- compatible: 'amlogic,axg-spdifout' or
- 'amlogic,g12a-spdifout' or
- 'amlogic,sm1-spdifout'
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "mclk" : master clock
-- #sound-dai-cells: must be 0.
-
-Optional property:
-- resets: phandle to the dedicated reset line of the spdif output.
-
-Example on the A113 SoC:
-
-spdifout: audio-controller@480 {
- compatible = "amlogic,axg-spdifout";
- reg = <0x0 0x480 0x0 0x50>;
- #sound-dai-cells = <0>;
- clocks = <&clkc_audio AUD_CLKID_SPDIFOUT>,
- <&clkc_audio AUD_CLKID_SPDIFOUT_CLK>;
- clock-names = "pclk", "mclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml
new file mode 100644
index 000000000000..15be8dae9398
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-spdifout.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-spdifout.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG SPDIF Output
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: amlogic,axg-spdifout
+ - items:
+ - enum:
+ - amlogic,g12a-spdifout
+ - amlogic,sm1-spdifout
+ - const: amlogic,axg-spdifout
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: SPDIF output master clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: mclk
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-spdifout
+ - amlogic,sm1-spdifout
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+
+ audio-controller@480 {
+ compatible = "amlogic,axg-spdifout";
+ reg = <0x480 0x50>;
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_SPDIFOUT>,
+ <&clkc_audio AUD_CLKID_SPDIFOUT_CLK>;
+ clock-names = "pclk", "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt
deleted file mode 100644
index 5996c0cd89c2..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Amlogic Audio TDM formatters
-
-Required properties:
-- compatible: 'amlogic,axg-tdmin' or
- 'amlogic,axg-tdmout' or
- 'amlogic,g12a-tdmin' or
- 'amlogic,g12a-tdmout' or
- 'amlogic,sm1-tdmin' or
- 'amlogic,sm1-tdmout
-- reg: physical base address of the controller and length of memory
- mapped region.
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "pclk" : peripheral clock.
- * "sclk" : bit clock.
- * "sclk_sel" : bit clock input multiplexer.
- * "lrclk" : sample clock
- * "lrclk_sel": sample clock input multiplexer
-
-Optional property:
-- resets: phandle to the dedicated reset line of the tdm formatter.
-
-Example of TDMOUT_A on the S905X2 SoC:
-
-tdmout_a: audio-controller@500 {
- compatible = "amlogic,axg-tdmout";
- reg = <0x0 0x500 0x0 0x40>;
- resets = <&clkc_audio AUD_RESET_TDMOUT_A>;
- clocks = <&clkc_audio AUD_CLKID_TDMOUT_A>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK_SEL>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>,
- <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>;
- clock-names = "pclk", "sclk", "sclk_sel",
- "lrclk", "lrclk_sel";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml
new file mode 100644
index 000000000000..719ca8fc98c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-formatters.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-tdm-formatters.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio AXG TDM formatters
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,g12a-tdmout
+ - amlogic,sm1-tdmout
+ - amlogic,axg-tdmout
+ - amlogic,g12a-tdmin
+ - amlogic,sm1-tdmin
+ - amlogic,axg-tdmin
+
+ clocks:
+ items:
+ - description: Peripheral clock
+ - description: Bit clock
+ - description: Bit clock input multiplexer
+ - description: Sample clock
+ - description: Sample clock input multiplexer
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: sclk
+ - const: sclk_sel
+ - const: lrclk
+ - const: lrclk_sel
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: component-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-tdmin
+ - amlogic,sm1-tdmin
+ - amlogic,g12a-tdmout
+ - amlogic,sm1-tdmout
+ then:
+ required:
+ - resets
+
+ else:
+ properties:
+ resets: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ #include <dt-bindings/reset/amlogic,meson-g12a-audio-reset.h>
+
+ audio-controller@500 {
+ compatible = "amlogic,g12a-tdmout";
+ reg = <0x500 0x40>;
+ resets = <&clkc_audio AUD_RESET_TDMOUT_A>;
+ clocks = <&clkc_audio AUD_CLKID_TDMOUT_A>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_SCLK_SEL>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>,
+ <&clkc_audio AUD_CLKID_TDMOUT_A_LRCLK>;
+ clock-names = "pclk", "sclk", "sclk_sel",
+ "lrclk", "lrclk_sel";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt
deleted file mode 100644
index cabfb26a5f22..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic Audio TDM Interfaces
-
-Required properties:
-- compatible: 'amlogic,axg-tdm-iface'
-- clocks: list of clock phandle, one for each entry clock-names.
-- clock-names: should contain the following:
- * "sclk" : bit clock.
- * "lrclk": sample clock
- * "mclk" : master clock
- -> optional if the interface is in clock slave mode.
-- #sound-dai-cells: must be 0.
-
-Example of TDM_A on the A113 SoC:
-
-tdmif_a: audio-controller@0 {
- compatible = "amlogic,axg-tdm-iface";
- #sound-dai-cells = <0>;
- clocks = <&clkc_audio AUD_CLKID_MST_A_MCLK>,
- <&clkc_audio AUD_CLKID_MST_A_SCLK>,
- <&clkc_audio AUD_CLKID_MST_A_LRCLK>;
- clock-names = "mclk", "sclk", "lrclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml
new file mode 100644
index 000000000000..45955d8a26d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,axg-tdm-iface.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Audio TDM Interfaces
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: amlogic,axg-tdm-iface
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ minItems: 2
+ items:
+ - description: Bit clock
+ - description: Sample clock
+ - description: Master clock # optional
+
+ clock-names:
+ minItems: 2
+ items:
+ - const: sclk
+ - const: lrclk
+ - const: mclk
+
+required:
+ - compatible
+ - "#sound-dai-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+
+ audio-controller {
+ compatible = "amlogic,axg-tdm-iface";
+ #sound-dai-cells = <0>;
+ clocks = <&clkc_audio AUD_CLKID_MST_A_SCLK>,
+ <&clkc_audio AUD_CLKID_MST_A_LRCLK>,
+ <&clkc_audio AUD_CLKID_MST_A_MCLK>;
+ clock-names = "sclk", "lrclk", "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml
index 77469a45bb7a..23f82bb89750 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml
@@ -10,7 +10,7 @@ maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt
deleted file mode 100644
index 4e8cd7eb7cec..000000000000
--- a/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-* Amlogic HDMI Tx control glue
-
-Required properties:
-- compatible: "amlogic,g12a-tohdmitx" or
- "amlogic,sm1-tohdmitx"
-- reg: physical base address of the controller and length of memory
- mapped region.
-- #sound-dai-cells: should be 1.
-- resets: phandle to the dedicated reset line of the hdmitx glue.
-
-Example on the S905X2 SoC:
-
-tohdmitx: audio-controller@744 {
- compatible = "amlogic,g12a-tohdmitx";
- reg = <0x0 0x744 0x0 0x4>;
- #sound-dai-cells = <1>;
- resets = <&clkc_audio AUD_RESET_TOHDMITX>;
-};
-
-Example of an 'amlogic,axg-sound-card':
-
-sound {
- compatible = "amlogic,axg-sound-card";
-
-[...]
-
- dai-link-x {
- sound-dai = <&tdmif_a>;
- dai-format = "i2s";
- dai-tdm-slot-tx-mask-0 = <1 1>;
-
- codec-0 {
- sound-dai = <&tohdmitx TOHDMITX_I2S_IN_A>;
- };
-
- codec-1 {
- sound-dai = <&external_dac>;
- };
- };
-
- dai-link-y {
- sound-dai = <&tdmif_c>;
- dai-format = "i2s";
- dai-tdm-slot-tx-mask-0 = <1 1>;
-
- codec {
- sound-dai = <&tohdmitx TOHDMITX_I2S_IN_C>;
- };
- };
-
- dai-link-z {
- sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
-
- codec {
- sound-dai = <&hdmi_tx>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.yaml b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.yaml
new file mode 100644
index 000000000000..b4b78475c5b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/amlogic,g12a-tohdmitx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic G12a HDMI TX Control Glue
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ $nodename:
+ pattern: "^audio-controller@.*"
+
+ compatible:
+ oneOf:
+ - items:
+ - const: amlogic,g12a-tohdmitx
+ - items:
+ - enum:
+ - amlogic,sm1-tohdmitx
+ - const: amlogic,g12a-tohdmitx
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - resets
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/amlogic,meson-g12a-audio-reset.h>
+
+ tohdmitx: audio-controller@744 {
+ compatible = "amlogic,g12a-tohdmitx";
+ reg = <0x744 0x4>;
+ resets = <&clkc_audio AUD_RESET_TOHDMITX>;
+ #sound-dai-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
index 5b8d59245f82..413b47778181 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
@@ -9,6 +9,9 @@ title: Amlogic GX sound card
maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
items:
@@ -18,24 +21,18 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: list of auxiliary devices
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- minItems: 2
- description: |-
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source.
-
audio-widgets:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
- minItems: 2
description: |-
A list off component DAPM widget. Each entry is a pair of strings,
the first being the widget type, the second being the widget name
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
+ clocks:
+ minItems: 1
+ maxItems: 3
+ description:
+ Base PLL clocks of audio susbsytem, used to configure base clock
+ frequencies for different audio use-cases.
patternProperties:
"^dai-link-[0-9]+$":
@@ -62,7 +59,7 @@ patternProperties:
description: phandle of the CPU DAI
patternProperties:
- "^codec-[0-9]+$":
+ "^codec(-[0-9]+)?$":
type: object
additionalProperties: false
description: |-
@@ -86,7 +83,7 @@ required:
- model
- dai-link-0
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml
index 580a3d040abc..5f5cccdbeb34 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml
@@ -10,7 +10,7 @@ maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
diff --git a/Documentation/devicetree/bindings/sound/apple,mca.yaml b/Documentation/devicetree/bindings/sound/apple,mca.yaml
index d5dc92b5b654..2beb725118ad 100644
--- a/Documentation/devicetree/bindings/sound/apple,mca.yaml
+++ b/Documentation/devicetree/bindings/sound/apple,mca.yaml
@@ -14,13 +14,22 @@ description: |
maintainers:
- Martin Povišer <povik+lin@cutebit.org>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
- items:
- - enum:
- - apple,t6000-mca
- - apple,t8103-mca
- - const: apple,mca
+ oneOf:
+ - items:
+ - const: apple,t6020-mca
+ - const: apple,t8103-mca
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,t6000-mca
+ - apple,t8103-mca
+ - apple,t8112-mca
+ - const: apple,mca
reg:
items:
@@ -106,7 +115,7 @@ required:
- power-domains
- '#sound-dai-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4104.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4104.yaml
new file mode 100644
index 000000000000..86f6061d3c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4104.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4104.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4104 S/PDIF transmitter
+
+allOf:
+ - $ref: dai-common.yaml#
+
+maintainers:
+ - Daniel Mack <github@zonque.org>
+ - Xiaxi Shen <shenxiaxi26@gmail.com>
+
+properties:
+ compatible:
+ const: asahi-kasei,ak4104
+
+ reg:
+ description: Chip select number on the SPI bus
+ maxItems: 1
+
+ vdd-supply:
+ description: A regulator node providing between 2.7V and 3.6V.
+
+ reset-gpios:
+ maxItems: 1
+ description: Optional GPIO spec for the reset pin, deasserted
+ before communication starts.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@0 {
+ compatible = "asahi-kasei,ak4104";
+ reg = <0>;
+ vdd-supply = <&vdd_3v3_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4375.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4375.yaml
new file mode 100644
index 000000000000..bc07fcba535b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4375.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4375.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4375 DAC and headphones amplifier
+
+maintainers:
+ - Vincent Knecht <vincent.knecht@mailoo.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: asahi-kasei,ak4375
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ avdd-supply:
+ description: regulator phandle for the AVDD power supply.
+
+ tvdd-supply:
+ description: regulator phandle for the TVDD power supply.
+
+ pdn-gpios:
+ description: optional GPIO to set the PDN pin.
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - avdd-supply
+ - tvdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ headphones: audio-codec@10 {
+ compatible = "asahi-kasei,ak4375";
+ reg = <0x10>;
+ avdd-supply = <&reg_headphones_avdd>;
+ tvdd-supply = <&pm8916_l6>;
+ pdn-gpios = <&msmgpio 114 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&headphones_pdn_default>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml
new file mode 100644
index 000000000000..1fdbeecc5eff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4458.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4458 audio DAC
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - asahi-kasei,ak4458
+ - asahi-kasei,ak4497
+
+ "#sound-dai-cells":
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog power supply
+
+ dvdd-supply:
+ description: Digital power supply
+
+ reset-gpios:
+ maxItems: 1
+
+ mute-gpios:
+ maxItems: 1
+ description:
+ GPIO used to mute all the outputs
+
+ dsd-path:
+ description: Select DSD input pins for ak4497
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - const: 0
+ description: "select #16, #17, #19 pins"
+ - const: 1
+ description: "select #3, #4, #5 pins"
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: asahi-kasei,ak4458
+
+ then:
+ properties:
+ dsd-path: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@10 {
+ compatible = "asahi-kasei,ak4458";
+ reg = <0x10>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ mute-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4554.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4554.yaml
new file mode 100644
index 000000000000..c77d85df239e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4554.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4554.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4554 sound codec
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ - Liam Girdwood <lgirdwood@gmail.com>
+ - Mark Brown <broonie@kernel.org>
+
+properties:
+ compatible:
+ const: asahi-kasei,ak4554
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ codec {
+ compatible = "asahi-kasei,ak4554";
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4613.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4613.yaml
new file mode 100644
index 000000000000..b49a6cff9f1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4613.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4613.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4613 I2C transmitter
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: asahi-kasei,ak4613
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ ports:
+ $ref: audio-graph-port.yaml#/definitions/ports
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+patternProperties:
+ "^asahi-kasei,in[1-2]-single-end$":
+ description: Input Pin 1 - 2.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ "^asahi-kasei,out[1-6]-single-end$":
+ description: Output Pin 1 - 6.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ak4613: codec@10 {
+ compatible = "asahi-kasei,ak4613";
+ reg = <0x10>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4619.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4619.yaml
new file mode 100644
index 000000000000..d412531ef9a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4619.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4619.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4619 I2C transmitter
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ - Khanh Le <khanh.le.xr@renesas.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: asahi-kasei,ak4619
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
+ "#sound-dai-cells":
+ const: 0
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@10 {
+ compatible = "asahi-kasei,ak4619";
+ reg = <0x10>;
+
+ clocks = <&rcar_sound>;
+ clock-names = "mclk";
+
+ #sound-dai-cells = <0>;
+ port {
+ ak4619_endpoint: endpoint {
+ remote-endpoint = <&rsnd_endpoint>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4642.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4642.yaml
new file mode 100644
index 000000000000..fc03f0373a1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4642.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4642.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK4642 I2C transmitter
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - asahi-kasei,ak4642
+ - asahi-kasei,ak4643
+ - asahi-kasei,ak4648
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ description: common clock binding; frequency of MCKO
+
+ clock-output-names:
+ description: common clock name
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ak4643: codec@12 {
+ compatible = "asahi-kasei,ak4643";
+ #sound-dai-cells = <0>;
+ reg = <0x12>;
+ #clock-cells = <0>;
+ clocks = <&audio_clock>;
+ clock-frequency = <12288000>;
+ clock-output-names = "ak4643_mcko";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml
new file mode 100644
index 000000000000..d3d494ae8abf
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak5558.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AK5558 8 channel differential 32-bit delta-sigma ADC
+
+maintainers:
+ - Junichi Wakasugi <wakasugi.jb@om.asahi-kasei.co.jp>
+ - Mihai Serban <mihai.serban@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - asahi-kasei,ak5552
+ - asahi-kasei,ak5558
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: A 1.8V supply that powers up the AVDD pin.
+
+ dvdd-supply:
+ description: A 1.2V supply that powers up the DVDD pin.
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ak5558: codec@10 {
+ compatible = "asahi-kasei,ak5558";
+ reg = <0x10>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel,asoc-wm8904.yaml b/Documentation/devicetree/bindings/sound/atmel,asoc-wm8904.yaml
new file mode 100644
index 000000000000..89a67f8e33b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,asoc-wm8904.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,asoc-wm8904.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel wm8904 audio codec complex
+
+maintainers:
+ - Dharma Balasubiramani <dharma.b@microchip.com>
+
+description:
+ The ASoC audio complex configuration for Atmel with WM8904 audio codec.
+
+properties:
+ compatible:
+ const: atmel,asoc-wm8904
+
+ atmel,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: The user-visible name of this sound complex.
+
+ atmel,ssc-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the SSC controller.
+
+ atmel,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the WM8731 audio codec.
+
+ atmel,audio-routing:
+ description:
+ A list of the connections between audio components. Each entry is a pair
+ of strings, the first being the connection's sink, the second being the
+ connection's source.
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ items:
+ enum:
+ # Board Connectors
+ - Headphone Jack
+ - Line In Jack
+ - Mic
+ # WM8904 CODEC Pins
+ - IN1L
+ - IN1R
+ - IN2L
+ - IN2R
+ - IN3L
+ - IN3R
+ - HPOUTL
+ - HPOUTR
+ - LINEOUTL
+ - LINEOUTR
+ - MICBIAS
+
+required:
+ - compatible
+ - atmel,model
+ - atmel,audio-routing
+ - atmel,ssc-controller
+ - atmel,audio-codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_mck>;
+
+ atmel,model = "wm8904 @ AT91SAM9N12EK";
+
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml b/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml
new file mode 100644
index 000000000000..ce99c2d8c35d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,at91-ssc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Serial Synchronous Serial (SSC)
+
+maintainers:
+ - Andrei Simion <andrei.simion@microchip.com>
+
+description:
+ The Atmel Synchronous Serial Controller (SSC) provides a versatile
+ synchronous communication link for audio and telecom applications,
+ supporting protocols like I2S, Short Frame Sync, and Long Frame Sync.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91rm9200-ssc
+ - atmel,at91sam9g45-ssc
+ - items:
+ - enum:
+ - microchip,sam9x7-ssc
+ - const: atmel,at91sam9g45-ssc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pclk
+
+ dmas:
+ items:
+ - description: TX DMA Channel
+ - description: RX DMA Channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ atmel,clk-from-rk-pin:
+ description:
+ Specify the clock source for the SSC (Synchronous Serial Controller)
+ when operating in slave mode. By default, the clock is sourced from
+ the TK pin.
+ type: boolean
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,at91sam9g45-ssc
+ then:
+ required:
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ssc@100000 {
+ compatible = "atmel,at91sam9g45-ssc";
+ reg = <0x100000 0x4000>;
+ interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+ dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(38))>,
+ <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(39))>;
+ dma-names = "tx", "rx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 28>;
+ clock-names = "pclk";
+ #sound-dai-cells = <0>;
+ };
+
+ ssc@c00000 {
+ compatible = "atmel,at91rm9200-ssc";
+ reg = <0xc00000 0x4000>;
+ interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 14>;
+ clock-names = "pclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml b/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml
new file mode 100644
index 000000000000..627da2d890b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,at91sam9g20ek-wm8731.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel at91sam9g20ek wm8731 audio complex
+
+maintainers:
+ - Balakrishnan Sambath <balakrishnan.s@microchip.com>
+
+description:
+ The audio complex configuration for Atmel at91sam9g20ek with WM8731 audio codec.
+
+properties:
+ compatible:
+ const: atmel,at91sam9g20ek-wm8731-audio
+
+ atmel,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: The user-visible name of this sound complex.
+
+ atmel,audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: A list of the connections between audio components.
+ minItems: 2
+ maxItems: 4
+ items:
+ enum:
+ # Board Connectors
+ - Ext Spk
+ - Int Mic
+
+ # CODEC Pins
+ - LOUT
+ - ROUT
+ - LHPOUT
+ - RHPOUT
+ - LLINEIN
+ - RLINEIN
+ - MICIN
+
+ atmel,ssc-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the SSC controller.
+
+ atmel,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of WM8731 audio codec.
+
+required:
+ - compatible
+ - atmel,model
+ - atmel,audio-routing
+ - atmel,ssc-controller
+ - atmel,audio-codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "atmel,at91sam9g20ek-wm8731-audio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_mck>;
+ atmel,model = "wm8731 @ AT91SAMG20EK";
+ atmel,audio-routing =
+ "Ext Spk", "LHPOUT",
+ "Int Mic", "MICIN";
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8731>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml b/Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml
new file mode 100644
index 000000000000..33717b728f63
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,sam9x5-wm8731-audio.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,sam9x5-wm8731-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel at91sam9x5ek wm8731 audio complex
+
+maintainers:
+ - Dharma Balasubiramani <dharma.b@microchip.com>
+
+description:
+ The audio complex configuration for Atmel at91sam9x5ek with WM8731 audio codec.
+
+properties:
+ compatible:
+ const: atmel,sam9x5-wm8731-audio
+
+ atmel,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: The user-visible name of this sound complex.
+
+ atmel,ssc-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the SSC controller.
+
+ atmel,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the WM8731 audio codec.
+
+ atmel,audio-routing:
+ description:
+ A list of the connections between audio components. Each entry is a pair
+ of strings, the first being the connection's sink, the second being the
+ connection's source.
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ items:
+ enum:
+ # Board Connectors
+ - Headphone Jack
+ - Line In Jack
+
+ # CODEC Pins
+ - LOUT
+ - ROUT
+ - LHPOUT
+ - RHPOUT
+ - LLINEIN
+ - RLINEIN
+ - MICIN
+
+required:
+ - compatible
+ - atmel,model
+ - atmel,ssc-controller
+ - atmel,audio-codec
+ - atmel,audio-routing
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "atmel,sam9x5-wm8731-audio";
+
+ atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+ atmel,audio-routing =
+ "Headphone Jack", "RHPOUT",
+ "Headphone Jack", "LHPOUT",
+ "LLINEIN", "Line In Jack",
+ "RLINEIN", "Line In Jack";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8731>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml b/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml
index 43d04702ac2d..ae3162fcfe02 100644
--- a/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml
+++ b/Documentation/devicetree/bindings/sound/atmel,sama5d2-classd.yaml
@@ -18,7 +18,12 @@ description:
properties:
compatible:
- const: atmel,sama5d2-classd
+ oneOf:
+ - items:
+ - const: atmel,sama5d2-classd
+ - items:
+ - const: microchip,sam9x7-classd
+ - const: atmel,sama5d2-classd
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt
deleted file mode 100644
index 9c5a9947b64d..000000000000
--- a/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Atmel at91sam9g20ek wm8731 audio complex
-
-Required properties:
- - compatible: "atmel,at91sam9g20ek-wm8731-audio"
- - atmel,model: The user-visible name of this sound complex.
- - atmel,audio-routing: A list of the connections between audio components.
- - atmel,ssc-controller: The phandle of the SSC controller
- - atmel,audio-codec: The phandle of the WM8731 audio codec
-Optional properties:
- - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
-
-Example:
-sound {
- compatible = "atmel,at91sam9g20ek-wm8731-audio";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pck0_as_mck>;
-
- atmel,model = "wm8731 @ AT91SAMG20EK";
-
- atmel,audio-routing =
- "Ext Spk", "LHPOUT",
- "Int MIC", "MICIN";
-
- atmel,ssc-controller = <&ssc0>;
- atmel,audio-codec = <&wm8731>;
-};
diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
deleted file mode 100644
index 8facbce53db8..000000000000
--- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* Atmel at91sam9x5ek wm8731 audio complex
-
-Required properties:
- - compatible: "atmel,sam9x5-wm8731-audio"
- - atmel,model: The user-visible name of this sound complex.
- - atmel,ssc-controller: The phandle of the SSC controller
- - atmel,audio-codec: The phandle of the WM8731 audio codec
- - atmel,audio-routing: A list of the connections between audio components.
- Each entry is a pair of strings, the first being the connection's sink,
- the second being the connection's source.
-
-Available audio endpoints for the audio-routing table:
-
-Board connectors:
- * Headphone Jack
- * Line In Jack
-
-wm8731 pins:
-cf Documentation/devicetree/bindings/sound/wlf,wm8731.yaml
-
-Example:
-sound {
- compatible = "atmel,sam9x5-wm8731-audio";
-
- atmel,model = "wm8731 @ AT91SAM9X5EK";
-
- atmel,audio-routing =
- "Headphone Jack", "RHPOUT",
- "Headphone Jack", "LHPOUT",
- "LLINEIN", "Line In Jack",
- "RLINEIN", "Line In Jack";
-
- atmel,ssc-controller = <&ssc0>;
- atmel,audio-codec = <&wm8731>;
-};
diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
deleted file mode 100644
index 8bbe50c884b6..000000000000
--- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Atmel ASoC driver with wm8904 audio codec complex
-
-Required properties:
- - compatible: "atmel,asoc-wm8904"
- - atmel,model: The user-visible name of this sound complex.
- - atmel,audio-routing: A list of the connections between audio components.
- Each entry is a pair of strings, the first being the connection's sink,
- the second being the connection's source. Valid names for sources and
- sinks are the WM8904's pins, and the jacks on the board:
-
- WM8904 pins:
-
- * IN1L
- * IN1R
- * IN2L
- * IN2R
- * IN3L
- * IN3R
- * HPOUTL
- * HPOUTR
- * LINEOUTL
- * LINEOUTR
- * MICBIAS
-
- Board connectors:
-
- * Headphone Jack
- * Line In Jack
- * Mic
-
- - atmel,ssc-controller: The phandle of the SSC controller
- - atmel,audio-codec: The phandle of the WM8904 audio codec
-
-Optional properties:
- - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
-
-Example:
-sound {
- compatible = "atmel,asoc-wm8904";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pck0_as_mck>;
-
- atmel,model = "wm8904 @ AT91SAM9N12EK";
-
- atmel,audio-routing =
- "Headphone Jack", "HPOUTL",
- "Headphone Jack", "HPOUTR",
- "IN2L", "Line In Jack",
- "IN2R", "Line In Jack",
- "Mic", "MICBIAS",
- "IN1L", "Mic";
-
- atmel,ssc-controller = <&ssc0>;
- atmel,audio-codec = <&wm8904>;
-};
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card.yaml
index 109e55f9e597..274092ef36c5 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-card.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph-card.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/audio-graph-card.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Audio Graph Card Device Tree Bindings
+title: Audio Graph Card
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml
index 7416067c945e..40eb1d7d6cf1 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/audio-graph-card2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Audio Graph Card2 Device Tree Bindings
+title: Audio Graph Card2
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
@@ -18,11 +18,12 @@ properties:
label:
maxItems: 1
routing:
+ $ref: audio-graph.yaml#/properties/routing
+ aux-devs:
description: |
- A list of the connections between audio components.
- Each entry is a pair of strings, the first being the
- connection's sink, the second being the connection's source.
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ List of phandles pointing to auxiliary devices, such
+ as amplifiers, to be added to the sound card.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
multi:
type: object
description: Multi-CPU/Codec node
@@ -32,6 +33,12 @@ properties:
codec2codec:
type: object
description: Codec to Codec node
+ hp-det-gpios:
+ $ref: audio-graph.yaml#/properties/hp-det-gpios
+ mic-det-gpios:
+ $ref: audio-graph.yaml#/properties/mic-det-gpios
+ widgets:
+ $ref: audio-graph.yaml#/properties/widgets
required:
- compatible
@@ -39,22 +46,4 @@ required:
additionalProperties: false
-examples:
- - |
- sound {
- compatible = "audio-graph-card2";
-
- links = <&cpu_port>;
- };
-
- cpu {
- compatible = "cpu-driver";
-
- cpu_port: port { cpu_ep: endpoint { remote-endpoint = <&codec_ep>; }; };
- };
-
- codec {
- compatible = "codec-driver";
-
- port { codec_ep: endpoint { remote-endpoint = <&cpu_ep>; }; };
- };
+...
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
index 64654ceef208..d1cbfc5edd3a 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
@@ -4,39 +4,44 @@
$id: http://devicetree.org/schemas/sound/audio-graph-port.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Audio Graph Card 'port' Node Bindings
+title: Audio Graph Card 'port'
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
select: false
-allOf:
- - $ref: /schemas/graph.yaml#/$defs/port-base
-
-properties:
- prefix:
- description: "device name prefix"
- $ref: /schemas/types.yaml#/definitions/string
- convert-rate:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate"
- convert-channels:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels"
- convert-sample-format:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format"
-
-patternProperties:
- "^endpoint(@[0-9a-f]+)?":
- $ref: /schemas/graph.yaml#/$defs/endpoint-base
- unevaluatedProperties: false
+definitions:
+ port-base:
+ allOf:
+ - $ref: /schemas/graph.yaml#/$defs/port-base
+ - $ref: /schemas/sound/dai-params.yaml#
+ properties:
+ mclk-fs:
+ $ref: simple-card.yaml#/definitions/mclk-fs
+ playback-only:
+ description: port connection used only for playback
+ $ref: /schemas/types.yaml#/definitions/flag
+ capture-only:
+ description: port connection used only for capture
+ $ref: /schemas/types.yaml#/definitions/flag
+ link-trigger-order:
+ description: trigger order for both start/stop
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ link-trigger-order-start:
+ description: trigger order for start
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ link-trigger-order-stop:
+ description: trigger order for stop
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ endpoint-base:
+ allOf:
+ - $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ - $ref: /schemas/sound/dai-params.yaml#
properties:
mclk-fs:
- description: |
- Multiplication factor between stream rate and codec mclk.
- When defined, mclk-fs property defined in dai-link sub nodes are
- ignored.
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: simple-card.yaml#/definitions/mclk-fs
frame-inversion:
description: dai-link uses frame clock inversion
$ref: /schemas/types.yaml#/definitions/flag
@@ -53,6 +58,15 @@ patternProperties:
oneOf:
- $ref: /schemas/types.yaml#/definitions/flag
- $ref: /schemas/types.yaml#/definitions/phandle
+ clocks:
+ description: Indicates system clock
+ maxItems: 1
+ system-clock-frequency:
+ $ref: simple-card.yaml#/definitions/system-clock-frequency
+ system-clock-direction-out:
+ $ref: simple-card.yaml#/definitions/system-clock-direction-out
+ system-clock-fixed:
+ $ref: simple-card.yaml#/definitions/system-clock-fixed
dai-format:
description: audio format.
@@ -67,12 +81,6 @@ patternProperties:
- pdm
- msb
- lsb
- convert-rate:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate"
- convert-channels:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels"
- convert-sample-format:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format"
dai-tdm-slot-num:
description: Number of slots in use.
@@ -100,4 +108,24 @@ patternProperties:
minimum: 1
maximum: 64
+ ports:
+ $ref: "#/definitions/port-base"
+ unevaluatedProperties: false
+ patternProperties:
+ "^port(@[0-9a-f]+)?$":
+ $ref: "#/definitions/port-base"
+ unevaluatedProperties: false
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: "#/definitions/endpoint-base"
+ unevaluatedProperties: false
+
+allOf:
+ - $ref: "#/definitions/port-base"
+
+patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: "#/definitions/endpoint-base"
+ unevaluatedProperties: false
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
index aaa99c2deda0..9899d9d1958d 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
@@ -4,18 +4,21 @@
$id: http://devicetree.org/schemas/sound/audio-graph.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Audio Graph Device Tree Bindings
+title: Audio Graph
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+allOf:
+ - $ref: /schemas/sound/dai-params.yaml#
+
properties:
dais:
$ref: /schemas/types.yaml#/definitions/phandle-array
label:
maxItems: 1
prefix:
- description: "device name prefix"
+ description: device name prefix
$ref: /schemas/types.yaml#/definitions/string
routing:
description: |
@@ -24,20 +27,24 @@ properties:
connection's sink, the second being the connection's source.
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
widgets:
- description: User specified audio sound widgets.
+ description: |
+ User specified audio sound widgets.
+ Each entry is a pair of strings, the first being the type of
+ widget ("Microphone", "Line", "Headphone", "Speaker"), the
+ second being the machine specific name for the widget.
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
- convert-rate:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate"
- convert-channels:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels"
- convert-sample-format:
- $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format"
pa-gpios:
maxItems: 1
hp-det-gpio:
+ deprecated: true
+ maxItems: 1
+ hp-det-gpios:
maxItems: 1
mic-det-gpio:
+ deprecated: true
+ maxItems: 1
+ mic-det-gpios:
maxItems: 1
required:
diff --git a/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml b/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml
new file mode 100644
index 000000000000..d3cc1ea4a175
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/audio-iio-aux.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/audio-iio-aux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio IIO auxiliary
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description:
+ Auxiliary device based on Industrial I/O device channels
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: audio-iio-aux
+
+ io-channels:
+ description:
+ Industrial I/O device channels used
+
+ io-channel-names:
+ description:
+ Industrial I/O channel names related to io-channels.
+ These names are used to provides sound controls, widgets and routes names.
+
+ snd-control-invert-range:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ A list of 0/1 flags defining whether or not the related channel is
+ inverted
+ items:
+ enum: [0, 1]
+ default: 0
+ description: |
+ Invert the sound control value compared to the IIO channel raw value.
+ - 1: The related sound control value is inverted meaning that the
+ minimum sound control value correspond to the maximum IIO channel
+ raw value and the maximum sound control value correspond to the
+ minimum IIO channel raw value.
+ - 0: The related sound control value is not inverted meaning that the
+ minimum (resp maximum) sound control value correspond to the
+ minimum (resp maximum) IIO channel raw value.
+
+required:
+ - compatible
+ - io-channels
+ - io-channel-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ iio-aux {
+ compatible = "audio-iio-aux";
+ io-channels = <&iio 0>, <&iio 1>, <&iio 2>, <&iio 3>;
+ io-channel-names = "CH0", "CH1", "CH2", "CH3";
+ /* Invert CH1 and CH2 */
+ snd-control-invert-range = <0 1 1 0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml b/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml
index dce86dafe382..bc6c6b172238 100644
--- a/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml
+++ b/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml
@@ -15,7 +15,7 @@ description:
function (primarily the power limit for the amplifier).
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/awinic,aw87390.yaml b/Documentation/devicetree/bindings/sound/awinic,aw87390.yaml
new file mode 100644
index 000000000000..ba9d8767c5d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/awinic,aw87390.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/awinic,aw87390.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic Aw87390 Audio Amplifier
+
+maintainers:
+ - Weidong Wang <wangweidong.a@awinic.com>
+
+description:
+ The awinic aw87390 is specifically designed to improve
+ the musical output dynamic range, enhance the overall
+ sound quallity, which is a new high efficiency, low
+ noise, constant large volume, 6th Smart K audio amplifier.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: awinic,aw87390
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ awinic,audio-channel:
+ description:
+ It is used to distinguish multiple PA devices, so that different
+ configurations can be loaded to different PA devices
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - awinic,audio-channel
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@58 {
+ compatible = "awinic,aw87390";
+ reg = <0x58>;
+ #sound-dai-cells = <0>;
+ awinic,audio-channel = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
new file mode 100644
index 000000000000..bb92d6ca3144
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/awinic,aw88395.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic AW88395 Smart Audio Amplifier
+
+maintainers:
+ - Weidong Wang <wangweidong.a@awinic.com>
+
+description:
+ The Awinic AW88395 is an I2S/TDM input, high efficiency
+ digital Smart K audio amplifier with an integrated 10.25V
+ smart boost convert.
+
+properties:
+ compatible:
+ enum:
+ - awinic,aw88081
+ - awinic,aw88083
+ - awinic,aw88166
+ - awinic,aw88261
+ - awinic,aw88395
+ - awinic,aw88399
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+ awinic,audio-channel:
+ description:
+ It is used to distinguish multiple PA devices, so that different
+ configurations can be loaded to different PA devices
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ awinic,sync-flag:
+ description:
+ Flag bit used to keep the phase synchronized in the case of multiple PA
+ $ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - awinic,audio-channel
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - awinic,aw88081
+ - awinic,aw88083
+ - awinic,aw88261
+ then:
+ properties:
+ reset-gpios: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@34 {
+ compatible = "awinic,aw88395";
+ reg = <0x34>;
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+ awinic,audio-channel = <0>;
+ awinic,sync-flag;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 9d049d4bfd58..b6cc5f6f78c2 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -29,7 +29,7 @@ The schematics explaining the gpios are as follows:
IN2 +---o--+------------+--o---+ OUT2
loop2 relays
-The 'loop1' gpio pin controlls two relays, which are either in loop position,
+The 'loop1' gpio pin controls two relays, which are either in loop position,
meaning that input and output are directly connected, or they are in mixer
position, meaning that the signal is passed through the 'Sum' mixer. Similarly
for 'loop2'.
diff --git a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
deleted file mode 100644
index 7bb0362828ec..000000000000
--- a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* Broadcom BCM2835 SoC I2S/PCM module
-
-Required properties:
-- compatible: "brcm,bcm2835-i2s"
-- reg: Should contain PCM registers location and length.
-- clocks: the (PCM) clock to use
-- dmas: List of DMA controller phandle and DMA request line ordered pairs.
-- dma-names: Identifier string for each DMA request line in the dmas property.
- These strings correspond 1:1 with the ordered pairs in dmas.
-
- One of the DMA channels will be responsible for transmission (should be
- named "tx") and one for reception (should be named "rx").
-
-Example:
-
-bcm2835_i2s: i2s@7e203000 {
- compatible = "brcm,bcm2835-i2s";
- reg = <0x7e203000 0x24>;
- clocks = <&clocks BCM2835_CLOCK_PCM>;
-
- dmas = <&dma 2>,
- <&dma 3>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.yaml b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.yaml
new file mode 100644
index 000000000000..f3cfe92684d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/brcm,bcm2835-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 SoC I2S/PCM module
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-i2s
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ items:
+ - description: Transmission DMA controller phandle and request line.
+ - description: Reception DMA controller phandle and request line.
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ i2s@7e203000 {
+ compatible = "brcm,bcm2835-i2s";
+ reg = <0x7e203000 0x24>;
+ clocks = <&clocks BCM2835_CLOCK_PCM>;
+ dmas = <&dma 2>, <&dma 3>;
+ dma-names = "tx", "rx";
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml
index 51d815d0c696..e6cf2ebcd777 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml
@@ -22,6 +22,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
'#sound-dai-cells':
description:
The first cell indicating the audio interface.
@@ -42,7 +45,7 @@ properties:
Configures the peak current by monitoring the current through the boost FET.
Range starts at 1600 mA and goes to a maximum of 4500 mA with increments
of 50 mA. See section 4.3.6 of the datasheet for details.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1600
maximum: 4500
default: 4500
@@ -51,7 +54,7 @@ properties:
description:
Boost inductor value, expressed in nH. Valid
values include 1000, 1200, 1500 and 2200.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 1000
maximum: 2200
@@ -60,7 +63,7 @@ properties:
Total equivalent boost capacitance on the VBST
and VAMP pins, derated at 11 volts DC. The value must be rounded to the
nearest integer and expressed in uF.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
cirrus,asp-sdout-hiz:
description:
@@ -70,7 +73,7 @@ properties:
1 = Hi-Z during unused slots but logic 0 while all transmit channels disabled
2 = (Default) Logic 0 during unused slots, but Hi-Z while all transmit channels disabled
3 = Hi-Z during unused slots and while all transmit channels disabled
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
default: 2
@@ -82,11 +85,19 @@ properties:
boost-cap-microfarad.
External Boost must have GPIO1 as GPIO output. GPIO1 will be set high to
enable boost voltage.
+ Shared boost allows two amplifiers to share a single boost circuit by
+ communicating on the MDSYNC bus. The active amplifier controls the boost
+ circuit using combined data from both amplifiers. GPIO1 should be
+ configured for Sync when shared boost is used. Shared boost is not
+ compatible with External boost. Active amplifier requires
+ boost-peak-milliamp, boost-ind-nanohenry and boost-cap-microfarad.
0 = Internal Boost
1 = External Boost
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ 2 = Shared Boost Active
+ 3 = Shared Boost Passive
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
- maximum: 1
+ maximum: 3
cirrus,gpio1-polarity-invert:
description:
@@ -109,7 +120,7 @@ properties:
1 = GPIO
2 = Sync
3 = MCLK input
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
@@ -136,16 +147,23 @@ properties:
3 = MCLK input
4 = Push-pull INTB (active low)
5 = Push-pull INT (active high)
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 5
+ cirrus,subsystem-id:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Subsystem ID. If this property is present, it sets the system name,
+ used to identify the firmware and tuning to load.
+
required:
- compatible
- reg
- "#sound-dai-cells"
allOf:
+ - $ref: dai-common.yaml#
- if:
properties:
cirrus,boost-type:
@@ -171,25 +189,27 @@ allOf:
cirrus,gpio1-src-select:
enum: [1]
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
+
spi {
#address-cells = <1>;
#size-cells = <0>;
- cs35l41: cs35l41@2 {
- #sound-dai-cells = <1>;
- compatible = "cirrus,cs35l41";
- reg = <2>;
- VA-supply = <&dummy_vreg>;
- VP-supply = <&dummy_vreg>;
- reset-gpios = <&gpio 110 0>;
-
- cirrus,boost-type = <0>;
- cirrus,boost-peak-milliamp = <4500>;
- cirrus,boost-ind-nanohenry = <1000>;
- cirrus,boost-cap-microfarad = <15>;
+ cs35l41: speaker-amp@2 {
+ #sound-dai-cells = <1>;
+ compatible = "cirrus,cs35l41";
+ reg = <2>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ reset-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+
+ cirrus,boost-type = <0>;
+ cirrus,boost-peak-milliamp = <4500>;
+ cirrus,boost-ind-nanohenry = <1000>;
+ cirrus,boost-cap-microfarad = <15>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml
index 184a1344ea76..70f6c62aedca 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml
@@ -14,6 +14,9 @@ description: |
CS35L45 is a Boosted Mono Class D Amplifier with DSP
Speaker Protection and Adaptive Battery Management.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -22,6 +25,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
'#sound-dai-cells':
const: 1
@@ -42,17 +48,85 @@ properties:
Audio serial port SDOUT Hi-Z control. Sets the Hi-Z
configuration for SDOUT pin of amplifier. Logical OR of
CS35L45_ASP_TX_HIZ_xxx values.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
default: 2
+patternProperties:
+ "^cirrus,gpio-ctrl[1-3]$":
+ description:
+ GPIO pins configuration.
+ type: object
+ additionalProperties: false
+ properties:
+ gpio-dir:
+ description:
+ GPIO pin direction. Valid only when 'gpio-ctrl' is 1
+ 0 = Output
+ 1 = Input
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 1
+ gpio-lvl:
+ description:
+ GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0
+ 0 = Low
+ 1 = High
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 0
+ gpio-op-cfg:
+ description:
+ GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0
+ 0 = CMOS
+ 1 = Open Drain
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 0
+ gpio-pol:
+ description:
+ GPIO output polarity select. Valid only when 'gpio-ctrl' is 1
+ and 'gpio-dir' is 0
+ 0 = Non-inverted, Active High
+ 1 = Inverted, Active Low
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ default: 0
+ gpio-ctrl:
+ description:
+ Defines the function of the GPIO pin.
+ GPIO1
+ 0 = High impedance input
+ 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir'
+ 2 = Pin acts as MDSYNC, direction controlled by MDSYNC
+ 3-7 = Reserved
+ GPIO2
+ 0 = High impedance input
+ 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir'
+ 2 = Pin acts as open drain INT
+ 3 = Reserved
+ 4 = Pin acts as push-pull output INT. Active low.
+ 5 = Pin acts as push-pull output INT. Active high.
+ 6,7 = Reserved
+ GPIO3
+ 0 = High impedance input
+ 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir'
+ 2-7 = Reserved
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ default: 0
required:
- compatible
- reg
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -71,5 +145,15 @@ examples:
reset-gpios = <&gpio 110 0>;
cirrus,asp-sdout-hiz-ctrl = <(CS35L45_ASP_TX_HIZ_UNUSED |
CS35L45_ASP_TX_HIZ_DISABLED)>;
+ cirrus,gpio-ctrl1 {
+ gpio-ctrl = <0x2>;
+ };
+ cirrus,gpio-ctrl2 {
+ gpio-ctrl = <0x2>;
+ };
+ cirrus,gpio-ctrl3 {
+ gpio-ctrl = <0x1>;
+ gpio-dir = <0x1>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs4270.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs4270.yaml
new file mode 100644
index 000000000000..336e11773694
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs4270.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs4270.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS4270 audio CODEC
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description:
+ The CS4270 is a stereo audio codec. The driver for this device currently only
+ supports I2C.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: cirrus,cs4270
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ reset-gpios:
+ description:
+ This pin will be deasserted before communication to the codec starts.
+ maxItems: 1
+
+ va-supply:
+ description: Analog power supply.
+
+ vd-supply:
+ description: Digital power supply.
+
+ vlc-supply:
+ description: Serial Control Port power supply.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@48 {
+ compatible = "cirrus,cs4270";
+ reg = <0x48>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs4271.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs4271.yaml
new file mode 100644
index 000000000000..d286eb169915
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs4271.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs4271.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS4271 audio CODEC
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+description:
+ The CS4271 is a stereo audio codec. This device supports both the I2C
+ and the SPI bus.
+
+allOf:
+ - $ref: dai-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: cirrus,cs4271
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description:
+ Master clock connected to the MCLK pin if MCLK is an input (i.e. no
+ crystal used).
+
+ clock-names:
+ items:
+ - const: mclk
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ reset-gpios:
+ description:
+ This pin will be deasserted before communication to the codec starts.
+ maxItems: 1
+
+ va-supply:
+ description: Analog power supply.
+
+ vd-supply:
+ description: Digital power supply.
+
+ vl-supply:
+ description: Serial Control Port power supply.
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ cirrus,amuteb-eq-bmutec:
+ description:
+ When given, the Codec's AMUTEB=BMUTEC flag is enabled.
+ type: boolean
+
+ cirrus,enable-soft-reset:
+ description: |
+ The CS4271 requires its LRCLK and MCLK to be stable before its RESET
+ line is de-asserted. That also means that clocks cannot be changed
+ without putting the chip back into hardware reset, which also requires
+ a complete re-initialization of all registers.
+
+ One (undocumented) workaround is to assert and de-assert the PDN bit
+ in the MODE2 register. This workaround can be enabled with this DT
+ property.
+
+ Note that this is not needed in case the clocks are stable
+ throughout the entire runtime of the codec.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@0 {
+ compatible = "cirrus,cs4271";
+ reg = <0>;
+ #sound-dai-cells = <0>;
+ spi-max-frequency = <6000000>;
+ spi-cpol;
+ spi-cpha;
+ reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+ port {
+ endpoint {
+ remote-endpoint = <&i2s_ep>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml
index 7356084a2ca2..af599d8735e2 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml
@@ -68,7 +68,7 @@ properties:
This is "normal tip sense (TS)" in the datasheet.
The CS42L42_TS_INV_* defines are available for this.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 1
@@ -87,7 +87,7 @@ properties:
7 - 1.5s
The CS42L42_TS_DBNCE_* defines are available for this.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
@@ -106,7 +106,7 @@ properties:
7 - 1.5s
The CS42L42_TS_DBNCE_* defines are available for this.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
@@ -120,7 +120,7 @@ properties:
0ms - 200ms,
Default = 100ms
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 200
@@ -133,7 +133,7 @@ properties:
0ms - 20ms,
Default = 10ms
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 20
@@ -169,7 +169,7 @@ properties:
3 - Slowest
The CS42L42_HSBIAS_RAMP_* defines are available for this.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml
new file mode 100644
index 000000000000..99a536601cc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml
@@ -0,0 +1,314 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs42l43.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS42L43 Audio CODEC
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description: |
+ The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface
+ (Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed
+ for portable applications. It provides a high dynamic range, stereo
+ DAC for headphone output, two integrated Class D amplifiers for
+ loudspeakers, and two ADCs for wired headset microphone input or
+ stereo line input. PDM inputs are provided for digital microphones.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs42l43
+
+ reg:
+ maxItems: 1
+
+ vdd-p-supply:
+ description:
+ Power supply for the high voltage interface.
+
+ vdd-a-supply:
+ description:
+ Power supply for internal analog circuits.
+
+ vdd-d-supply:
+ description:
+ Power supply for internal digital circuits. Can be internally supplied.
+
+ vdd-io-supply:
+ description:
+ Power supply for external interface and internal digital logic.
+
+ vdd-cp-supply:
+ description:
+ Power supply for the amplifier 3 and 4 charge pump.
+
+ vdd-amp-supply:
+ description:
+ Power supply for amplifier 1 and 2.
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 1
+
+ clocks:
+ items:
+ - description: Synchronous audio clock provided on mclk_in.
+
+ clock-names:
+ const: mclk
+
+ cirrus,bias-low:
+ type: boolean
+ description:
+ Select a 1.8V headset micbias rather than 2.8V.
+
+ cirrus,bias-sense-microamp:
+ description:
+ Current at which the headset micbias sense clamp will engage, 0 to
+ disable.
+ enum: [ 0, 14, 24, 43, 52, 61, 71, 90, 99 ]
+ default: 14
+
+ cirrus,bias-ramp-ms:
+ description:
+ Time in milliseconds the hardware allows for the headset micbias to
+ ramp up.
+ enum: [ 10, 40, 90, 170 ]
+ default: 170
+
+ cirrus,detect-us:
+ description:
+ Time in microseconds the type detection will run for. Long values will
+ cause more audible effects, but give more accurate detection.
+ enum: [ 20, 100, 1000, 10000, 50000, 75000, 100000, 200000 ]
+ default: 1000
+
+ cirrus,button-automute:
+ type: boolean
+ description:
+ Enable the hardware automuting of decimator 1 when a headset button is
+ pressed.
+
+ cirrus,buttons-ohms:
+ description:
+ Impedance in Ohms for each headset button, these should be listed in
+ ascending order.
+ minItems: 1
+ maxItems: 6
+
+ cirrus,tip-debounce-ms:
+ description:
+ Software debounce on tip sense triggering in milliseconds.
+ default: 0
+
+ cirrus,tip-invert:
+ type: boolean
+ description:
+ Indicates tip detect polarity, inverted implies open-circuit whilst the
+ jack is inserted.
+
+ cirrus,tip-disable-pullup:
+ type: boolean
+ description:
+ Indicates if the internal pullup on the tip detect should be disabled.
+
+ cirrus,tip-fall-db-ms:
+ description:
+ Time in milliseconds a falling edge on the tip detect should be hardware
+ debounced for. Note the falling edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ cirrus,tip-rise-db-ms:
+ description:
+ Time in milliseconds a rising edge on the tip detect should be hardware
+ debounced for. Note the rising edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ cirrus,use-ring-sense:
+ type: boolean
+ description:
+ Indicates if the ring sense should be used.
+
+ cirrus,ring-invert:
+ type: boolean
+ description:
+ Indicates ring detect polarity, inverted implies open-circuit whilst the
+ jack is inserted.
+
+ cirrus,ring-disable-pullup:
+ type: boolean
+ description:
+ Indicates if the internal pullup on the ring detect should be disabled.
+
+ cirrus,ring-fall-db-ms:
+ description:
+ Time in milliseconds a falling edge on the ring detect should be hardware
+ debounced for. Note the falling edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ cirrus,ring-rise-db-ms:
+ description:
+ Time in milliseconds a rising edge on the ring detect should be hardware
+ debounced for. Note the rising edge is considered after the invert.
+ enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
+ default: 500
+
+ pinctrl:
+ type: object
+ $ref: /schemas/pinctrl/pinctrl.yaml#
+ additionalProperties: false
+
+ properties:
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-ranges:
+ items:
+ - items:
+ - description: A phandle to the CODEC pinctrl node
+ minimum: 0
+ - const: 0
+ - const: 0
+ - const: 3
+
+ patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/cirrus-cs42l43-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/cirrus-cs42l43-state"
+ additionalProperties: false
+
+ spi:
+ type: object
+ $ref: /schemas/spi/spi-controller.yaml#
+ unevaluatedProperties: false
+
+$defs:
+ cirrus-cs42l43-state:
+ type: object
+
+ allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml#
+ - $ref: /schemas/pinctrl/pinmux-node.yaml#
+
+ oneOf:
+ - required: [ groups ]
+ - required: [ pins ]
+
+ additionalProperties: false
+
+ properties:
+ groups:
+ enum: [ gpio1, gpio2, gpio3, asp, pdmout2, pdmout1, i2c, spi ]
+
+ pins:
+ enum: [ gpio1, gpio2, gpio3,
+ asp_dout, asp_fsync, asp_bclk,
+ pdmout2_clk, pdmout2_data, pdmout1_clk, pdmout1_data,
+ i2c_sda, i2c_scl,
+ spi_miso, spi_sck, spi_ssb ]
+
+ function:
+ enum: [ gpio, spdif, irq, mic-shutter, spk-shutter ]
+
+ drive-strength:
+ description: Set drive strength in mA
+ enum: [ 1, 2, 4, 8, 9, 10, 12, 16 ]
+
+ input-debounce:
+ description: Set input debounce in uS
+ enum: [ 0, 85 ]
+
+required:
+ - compatible
+ - reg
+ - vdd-p-supply
+ - vdd-a-supply
+ - vdd-io-supply
+ - vdd-cp-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cs42l43: codec@1a {
+ compatible = "cirrus,cs42l43";
+ reg = <0x1a>;
+
+ vdd-p-supply = <&vdd5v0>;
+ vdd-a-supply = <&vdd1v8>;
+ vdd-io-supply = <&vdd1v8>;
+ vdd-cp-supply = <&vdd1v8>;
+ vdd-amp-supply = <&vdd5v0>;
+
+ reset-gpios = <&gpio 0>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gpio>;
+ interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
+
+ #sound-dai-cells = <1>;
+
+ clocks = <&clks 0>;
+ clock-names = "mclk";
+
+ cs42l43_pins: pinctrl {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&cs42l43_pins 0 0 3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinsettings>;
+
+ pinsettings: default-state {
+ shutter-pins {
+ groups = "gpio3";
+ function = "mic-shutter";
+ };
+ };
+ };
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cs-gpios = <&cs42l43_pins 1 0>;
+
+ sensor@0 {
+ compatible = "bosch,bme680";
+ reg = <0>;
+ spi-max-frequency = <1400000>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml
index 963a871e74da..f7bafbd4f1c2 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/cirrus,cs42l51.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: CS42L51 audio codec DT bindings
+title: CS42L51 audio codec
maintainers:
- Olivier Moysan <olivier.moysan@foss.st.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: cirrus,cs42l51
@@ -41,12 +44,16 @@ properties:
VAHP-supply:
description: phandle to voltage regulator of headphone
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -66,6 +73,13 @@ examples:
VA-supply = <&reg_audio>;
VAHP-supply = <&reg_audio>;
reset-gpios = <&gpiog 9 GPIO_ACTIVE_LOW>;
+
+ /* assume audio-graph */
+ port {
+ cpu_endpoint: endpoint {
+ remote-endpoint = <&cpu_endpoint>;
+ };
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l84.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l84.yaml
new file mode 100644
index 000000000000..7f8338e8ae36
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l84.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs42l84.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS42L84 audio CODEC
+
+maintainers:
+ - Martin Povišer <povik+lin@cutebit.org>
+
+description: |
+ The CS42L84 is a headphone jack codec made by Cirrus Logic and embedded
+ in personal computers sold by Apple. It was first seen in 2021 Macbook
+ Pro models. It has stereo DAC for playback, mono ADC for capture, and
+ is somewhat similar to CS42L42 but with a different regmap.
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs42l84
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ jack_codec: codec@4b {
+ compatible = "cirrus,cs42l84";
+ reg = <0x4b>;
+ reset-gpios = <&pinctrl_nub 4 GPIO_ACTIVE_LOW>;
+ interrupts-extended = <&pinctrl_ap 180 IRQ_TYPE_LEVEL_LOW>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42xx8.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42xx8.yaml
new file mode 100644
index 000000000000..cd47905eb20a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs42xx8.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs42xx8.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS42448/CS42888 audio CODEC
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs42448
+ - cirrus,cs42888
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ const: mclk
+
+ VA-supply:
+ description: Analog power supply.
+
+ VD-supply:
+ description: Digital power supply.
+
+ VLC-supply:
+ description: Control port power supply
+
+ VLS-supply:
+ description: Serial port interface power supply.
+
+ reset-gpios:
+ description: This pin is connected to the chip's RESET pin.
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: cirrus,cs42888
+then:
+ required:
+ - VA-supply
+ - VD-supply
+ - VLC-supply
+ - VLS-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@48 {
+ compatible = "cirrus,cs42888";
+ reg = <0x48>;
+ clocks = <&codec_mclk 0>;
+ clock-names = "mclk";
+ VA-supply = <&reg_audio>;
+ VD-supply = <&reg_audio>;
+ VLS-supply = <&reg_audio>;
+ VLC-supply = <&reg_audio>;
+ reset-gpios = <&gpio 1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml
new file mode 100644
index 000000000000..bf087b57aaf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs48l32.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS48L32 audio DSP.
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description: |
+ The CS48L32 is a high-performance low-power audio DSP for smartphones and
+ other portable audio devices. The CS48L32 combines a programmable Halo Core
+ DSP with a variety of power-efficient fixed-function audio processors.
+
+ See also the binding headers:
+
+ include/dt-bindings/sound/cs48l32.yaml
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs48l32
+
+ reg:
+ description: SPI chip-select number.
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 25000000
+
+ vdd-a-supply:
+ description: Regulator supplying VDD_A
+
+ vdd-d-supply:
+ description: Regulator supplying VDD_D
+
+ vdd-io-supply:
+ description: Regulator supplying VDD_IO
+
+ vdd-cp-supply:
+ description: Regulator supplying VDD_CP
+
+ reset-gpios:
+ description:
+ One entry specifying the GPIO controlling /RESET. Although optional,
+ it is strongly recommended to use a hardware reset.
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The clock supplied on MCLK1
+
+ clock-names:
+ const: mclk1
+
+ '#sound-dai-cells':
+ const: 1
+
+ cirrus,in-type:
+ description: |
+ A list of input type settings for each ADC input.
+ Inputs are one of these types:
+ CS48L32_IN_TYPE_DIFF : analog differential (default)
+ CS48L32_IN_TYPE_SE : analog single-ended
+
+ The type of the left (L) and right (R) channel on each input is
+ independently configured, as are the two groups of pins muxable to
+ the input (referred to in the datasheet as "1" and "2").
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description:
+ IN1L_1 analog input type. One of the CS48L32_IN_TYPE_xxx.
+ minimum: 0
+ maximum: 1
+ default: 0
+ - description:
+ IN1R_1 analog input type. One of the CS48L32_IN_TYPE_xxx.
+ minimum: 0
+ maximum: 1
+ default: 0
+ - description:
+ IN1L_2 analog input type. One of the CS48L32_IN_TYPE_xxx.
+ minimum: 0
+ maximum: 1
+ default: 0
+ - description:
+ IN1R_2 analog input type. One of the CS48L32_IN_TYPE_xxx.
+ minimum: 0
+ maximum: 1
+ default: 0
+
+ cirrus,pdm-sup:
+ description: |
+ Indicate which MICBIAS output supplies bias to the microphone.
+ There is one cell per input (IN1, IN2, ...).
+
+ One of the CS48L32_MICBIAS_xxx values.
+ CS48L32_PDM_SUP_VOUT_MIC : mic biased from VOUT_MIC
+ CS48L32_PDM_SUP_MICBIAS1 : mic biased from MICBIAS1
+
+ Also see the INn_PDM_SUP field in the datasheet.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: IN1 PDM supply source
+ minimum: 0
+ maximum: 1
+ default: 0
+ - description: IN2 PDM supply source
+ minimum: 0
+ maximum: 1
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - vdd-a-supply
+ - vdd-d-supply
+ - vdd-io-supply
+ - vdd-cp-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/cs48l32.h>
+
+ spi@e0006000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xe0006000 0x1000>;
+
+ codec@1 {
+ compatible = "cirrus,cs48l32";
+
+ reg = <0x1>;
+ spi-max-frequency = <2500000>;
+
+ vdd-a-supply = <&regulator_1v8>;
+ vdd-d-supply = <&regulator_1v2>;
+ vdd-io-supply = <&regulator_1v8>;
+ vdd-cp-supply = <&regulator_1v8>;
+
+ reset-gpios = <&gpio 0 0>;
+
+ clocks = <&clks 0>;
+ clock-names = "mclk1";
+
+ interrupt-parent = <&gpio0>;
+ interrupts = <56 8>;
+
+ #sound-dai-cells = <1>;
+
+ cirrus,in-type = <
+ CS48L32_IN_TYPE_DIFF CS48L32_IN_TYPE_DIFF
+ CS48L32_IN_TYPE_SE CS48L32_IN_TYPE_SE
+ >;
+
+ cirrus,pdm-sup = <
+ CS48L32_PDM_SUP_MICBIAS1 CS48L32_PDM_SUP_MICBIAS1
+ >;
+ };
+ };
+
+#
+# Minimal config
+#
+ - |
+ #include <dt-bindings/sound/cs48l32.h>
+
+ spi@e0006000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xe0006000 0x1000>;
+
+ codec@1 {
+ compatible = "cirrus,cs48l32";
+
+ reg = <0x1>;
+
+ vdd-a-supply = <&regulator_1v8>;
+ vdd-d-supply = <&regulator_1v2>;
+ vdd-io-supply = <&regulator_1v8>;
+ vdd-cp-supply = <&regulator_1v8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs530x.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs530x.yaml
new file mode 100644
index 000000000000..7600fff0e3b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs530x.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,cs530x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic cs530x family of audio ADCs
+
+maintainers:
+ - Paul Handrigan <paulha@opensource.cirrus.com>
+ - patches@opensource.cirrus.com
+
+description:
+ The CS530X devices are a family of high performance audio ADCs.
+
+allOf:
+ - $ref: dai-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs4282
+ - cirrus,cs4302
+ - cirrus,cs4304
+ - cirrus,cs4308
+ - cirrus,cs5302
+ - cirrus,cs5304
+ - cirrus,cs5308
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 24000000
+
+ '#sound-dai-cells':
+ const: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vdd-a-supply:
+ description: Analog power supply
+
+ vdd-io-supply:
+ description: Digital IO power supply
+
+ cirrus,in-hiz-pin12:
+ description:
+ Sets input channels one and two to high impedance.
+ type: boolean
+
+ cirrus,in-hiz-pin34:
+ description:
+ Sets input channels three and four to high impedance.
+ type: boolean
+
+ cirrus,in-hiz-pin56:
+ description:
+ Sets input channels five and six to high impedance.
+ type: boolean
+
+ cirrus,in-hiz-pin78:
+ description:
+ Sets input channels seven and eight to high impedance.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cs5304: adc@48 {
+ compatible = "cirrus,cs5304";
+ reg = <0x48>;
+ #sound-dai-cells = <1>;
+ reset-gpios = <&gpio 110 GPIO_ACTIVE_LOW>;
+ vdd-a-supply = <&vreg>;
+ vdd-io-supply = <&vreg>;
+ cirrus,in-hiz-pin34;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
new file mode 100644
index 000000000000..4693e85aed37
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/cirrus,ep9301-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus EP93xx I2S Controller
+
+description: |
+ The I2S controller is used to stream serial audio data between the external
+ I2S CODECs’, ADCs/DACs, and the ARM Core. The controller supports I2S, Left-
+ and Right-Justified DSP formats.
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: cirrus,ep9301-i2s
+
+ '#sound-dai-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: mclk
+ - const: sclk
+ - const: lrclk
+
+ dmas:
+ items:
+ - description: out DMA channel
+ - description: in DMA channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - '#sound-dai-cells'
+ - reg
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ i2s: i2s@80820000 {
+ compatible = "cirrus,ep9301-i2s";
+ #sound-dai-cells = <0>;
+ reg = <0x80820000 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <28>;
+ clocks = <&syscon 29>,
+ <&syscon 30>,
+ <&syscon 31>;
+ clock-names = "mclk", "sclk", "lrclk";
+ dmas = <&dma0 0 1>, <&dma0 0 2>;
+ dma-names = "tx", "rx";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml
index cea612d3d4a7..52f024f5302a 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml
@@ -24,6 +24,9 @@ description: |
This binding must be part of the Lochnagar MFD binding:
[1] ../mfd/cirrus,lochnagar.yaml
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -49,4 +52,4 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/sound/cirrus,madera.yaml b/Documentation/devicetree/bindings/sound/cirrus,madera.yaml
index 23138ddcb62d..014d4eaa8793 100644
--- a/Documentation/devicetree/bindings/sound/cirrus,madera.yaml
+++ b/Documentation/devicetree/bindings/sound/cirrus,madera.yaml
@@ -22,6 +22,9 @@ description: |
The properties are all contained in the parent MFD node.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
'#sound-dai-cells':
description:
diff --git a/Documentation/devicetree/bindings/sound/component-common.yaml b/Documentation/devicetree/bindings/sound/component-common.yaml
new file mode 100644
index 000000000000..37766c5f3974
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/component-common.yaml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/component-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Audio Component Common Properties
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+properties:
+ sound-name-prefix:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Card implementing the routing property define the connection between
+ audio components as list of string pair. Component using the same
+ sink/source names may use this property to prepend the name of their
+ sinks/sources with the provided string.
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/cs35l35.txt b/Documentation/devicetree/bindings/sound/cs35l35.txt
index 7915897f8a81..e84f30c5c39b 100644
--- a/Documentation/devicetree/bindings/sound/cs35l35.txt
+++ b/Documentation/devicetree/bindings/sound/cs35l35.txt
@@ -110,7 +110,7 @@ Optional Monitor Signal Format sub-node:
See Sections 4.8.2 through 4.8.4 Serial-Port Control in the Datasheet
- -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formating
+ -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formatting
on the I2S Port. Each of the 3 8 bit values in the array contain the settings
for depth, location, and frame.
diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt
index 912bd162b477..d34117b8558e 100644
--- a/Documentation/devicetree/bindings/sound/cs35l36.txt
+++ b/Documentation/devicetree/bindings/sound/cs35l36.txt
@@ -33,7 +33,7 @@ Optional properties:
one amplifier in the system. If more than one it is best to Hi-Z the ASP
port to prevent bus contention on the output signal
- - cirrus,boost-ctl-select : Boost conerter control source selection.
+ - cirrus,boost-ctl-select : Boost converter control source selection.
Selects the source of the BST_CTL target VBST voltage for the boost
converter to generate.
0x00 - Control Port Value
diff --git a/Documentation/devicetree/bindings/sound/cs4265.txt b/Documentation/devicetree/bindings/sound/cs4265.txt
deleted file mode 100644
index 380fff8e4e83..000000000000
--- a/Documentation/devicetree/bindings/sound/cs4265.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-CS4265 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "cirrus,cs4265"
-
- - reg : the I2C address of the device for I2C. The I2C address depends on
- the state of the AD0 pin. If AD0 is high, the i2c address is 0x4f.
- If it is low, the i2c address is 0x4e.
-
-Optional properties:
-
- - reset-gpios : a GPIO spec for the reset pin. If specified, it will be
- deasserted before communication to the codec starts.
-
-Examples:
-
-codec_ad0_high: cs4265@4f { /* AD0 Pin is high */
- compatible = "cirrus,cs4265";
- reg = <0x4f>;
-};
-
-
-codec_ad0_low: cs4265@4e { /* AD0 Pin is low */
- compatible = "cirrus,cs4265";
- reg = <0x4e>;
-};
diff --git a/Documentation/devicetree/bindings/sound/cs4270.txt b/Documentation/devicetree/bindings/sound/cs4270.txt
deleted file mode 100644
index c33770ec4c3c..000000000000
--- a/Documentation/devicetree/bindings/sound/cs4270.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-CS4270 audio CODEC
-
-The driver for this device currently only supports I2C.
-
-Required properties:
-
- - compatible : "cirrus,cs4270"
-
- - reg : the I2C address of the device for I2C
-
-Optional properties:
-
- - reset-gpios : a GPIO spec for the reset pin. If specified, it will be
- deasserted before communication to the codec starts.
-
-Example:
-
-codec: cs4270@48 {
- compatible = "cirrus,cs4270";
- reg = <0x48>;
-};
diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt
deleted file mode 100644
index 6e699ceabacd..000000000000
--- a/Documentation/devicetree/bindings/sound/cs4271.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Cirrus Logic CS4271 DT bindings
-
-This driver supports both the I2C and the SPI bus.
-
-Required properties:
-
- - compatible: "cirrus,cs4271"
-
-For required properties on SPI, please consult
-Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Required properties on I2C:
-
- - reg: the i2c address
-
-
-Optional properties:
-
- - reset-gpio: a GPIO spec to define which pin is connected to the chip's
- !RESET pin
- - cirrus,amuteb-eq-bmutec: When given, the Codec's AMUTEB=BMUTEC flag
- is enabled.
- - cirrus,enable-soft-reset:
- The CS4271 requires its LRCLK and MCLK to be stable before its RESET
- line is de-asserted. That also means that clocks cannot be changed
- without putting the chip back into hardware reset, which also requires
- a complete re-initialization of all registers.
-
- One (undocumented) workaround is to assert and de-assert the PDN bit
- in the MODE2 register. This workaround can be enabled with this DT
- property.
-
- Note that this is not needed in case the clocks are stable
- throughout the entire runtime of the codec.
-
- - vd-supply: Digital power
- - vl-supply: Logic power
- - va-supply: Analog Power
-
-Examples:
-
- codec_i2c: cs4271@10 {
- compatible = "cirrus,cs4271";
- reg = <0x10>;
- reset-gpio = <&gpio 23 0>;
- vd-supply = <&vdd_3v3_reg>;
- vl-supply = <&vdd_3v3_reg>;
- va-supply = <&vdd_3v3_reg>;
- };
-
- codec_spi: cs4271@0 {
- compatible = "cirrus,cs4271";
- reg = <0x0>;
- reset-gpio = <&gpio 23 0>;
- spi-max-frequency = <6000000>;
- };
-
diff --git a/Documentation/devicetree/bindings/sound/cs42xx8.txt b/Documentation/devicetree/bindings/sound/cs42xx8.txt
deleted file mode 100644
index bbfe39347c20..000000000000
--- a/Documentation/devicetree/bindings/sound/cs42xx8.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-CS42448/CS42888 audio CODEC
-
-Required properties:
-
- - compatible : must contain one of "cirrus,cs42448" and "cirrus,cs42888"
-
- - reg : the I2C address of the device for I2C
-
- - clocks : a list of phandles + clock-specifiers, one for each entry in
- clock-names
-
- - clock-names : must contain "mclk"
-
- - VA-supply, VD-supply, VLS-supply, VLC-supply: power supplies for the device,
- as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
-Optional properties:
-
- - reset-gpios : a GPIO spec to define which pin is connected to the chip's
- !RESET pin
-
-Example:
-
-cs42888: codec@48 {
- compatible = "cirrus,cs42888";
- reg = <0x48>;
- clocks = <&codec_mclk 0>;
- clock-names = "mclk";
- VA-supply = <&reg_audio>;
- VD-supply = <&reg_audio>;
- VLS-supply = <&reg_audio>;
- VLC-supply = <&reg_audio>;
- reset-gpios = <&pca9557_b 1 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/sound/cs4341.txt b/Documentation/devicetree/bindings/sound/cs4341.txt
deleted file mode 100644
index 12b4aa8ef0db..000000000000
--- a/Documentation/devicetree/bindings/sound/cs4341.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Cirrus Logic CS4341 audio DAC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
- - compatible: "cirrus,cs4341a"
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-For required properties on I2C-bus, please consult
-Documentation/devicetree/bindings/i2c/i2c.txt
-For required properties on SPI-bus, please consult
-Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Example:
- codec: cs4341@0 {
- #sound-dai-cells = <0>;
- compatible = "cirrus,cs4341a";
- reg = <0>;
- spi-max-frequency = <6000000>;
- };
diff --git a/Documentation/devicetree/bindings/sound/cs4349.txt b/Documentation/devicetree/bindings/sound/cs4349.txt
deleted file mode 100644
index 54c117b59dba..000000000000
--- a/Documentation/devicetree/bindings/sound/cs4349.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-CS4349 audio CODEC
-
-Required properties:
-
- - compatible : "cirrus,cs4349"
-
- - reg : the I2C address of the device for I2C
-
-Optional properties:
-
- - reset-gpios : a GPIO spec for the reset pin.
-
-Example:
-
-codec: cs4349@48 {
- compatible = "cirrus,cs4349";
- reg = <0x48>;
- reset-gpios = <&gpio 54 0>;
-};
diff --git a/Documentation/devicetree/bindings/sound/cs53l30.txt b/Documentation/devicetree/bindings/sound/cs53l30.txt
index 4dbfb8274cd9..dc256adb35a2 100644
--- a/Documentation/devicetree/bindings/sound/cs53l30.txt
+++ b/Documentation/devicetree/bindings/sound/cs53l30.txt
@@ -30,7 +30,7 @@ Optional properties:
* frame using two different ways:
* 1) Normal I2S mode on two data pins -- each SDOUT
* carries 2-channel data in the same time.
- * 2) TDM mode on one signle data pin -- SDOUT1 carries
+ * 2) TDM mode on one single data pin -- SDOUT1 carries
* 4-channel data per frame.
Example:
diff --git a/Documentation/devicetree/bindings/sound/da7213.txt b/Documentation/devicetree/bindings/sound/da7213.txt
deleted file mode 100644
index 94584c96c4ae..000000000000
--- a/Documentation/devicetree/bindings/sound/da7213.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Dialog Semiconductor DA7212/DA7213 Audio Codec bindings
-
-======
-
-Required properties:
-- compatible : Should be "dlg,da7212" or "dlg,da7213"
-- reg: Specifies the I2C slave address
-
-Optional properties:
-- clocks : phandle and clock specifier for codec MCLK.
-- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
-
-- dlg,micbias1-lvl : Voltage (mV) for Mic Bias 1
- [<1600>, <2200>, <2500>, <3000>]
-- dlg,micbias2-lvl : Voltage (mV) for Mic Bias 2
- [<1600>, <2200>, <2500>, <3000>]
-- dlg,dmic-data-sel : DMIC channel select based on clock edge.
- ["lrise_rfall", "lfall_rrise"]
-- dlg,dmic-samplephase : When to sample audio from DMIC.
- ["on_clkedge", "between_clkedge"]
-- dlg,dmic-clkrate : DMIC clock frequency (Hz).
- [<1500000>, <3000000>]
-
- - VDDA-supply : Regulator phandle for Analogue power supply
- - VDDMIC-supply : Regulator phandle for Mic Bias
- - VDDIO-supply : Regulator phandle for I/O power supply
-
-======
-
-Example:
-
- codec_i2c: da7213@1a {
- compatible = "dlg,da7213";
- reg = <0x1a>;
-
- clocks = <&clks 201>;
- clock-names = "mclk";
-
- dlg,micbias1-lvl = <2500>;
- dlg,micbias2-lvl = <2500>;
-
- dlg,dmic-data-sel = "lrise_rfall";
- dlg,dmic-samplephase = "between_clkedge";
- dlg,dmic-clkrate = <3000000>;
- };
diff --git a/Documentation/devicetree/bindings/sound/da7219.txt b/Documentation/devicetree/bindings/sound/da7219.txt
deleted file mode 100644
index add1caf26ac2..000000000000
--- a/Documentation/devicetree/bindings/sound/da7219.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-Dialog Semiconductor DA7219 Audio Codec bindings
-
-DA7219 is an audio codec with advanced accessory detect features.
-
-======
-
-Required properties:
-- compatible : Should be "dlg,da7219"
-- reg: Specifies the I2C slave address
-
-- interrupts : IRQ line info for DA7219.
- (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
- further information relating to interrupt properties)
-
-- VDD-supply: VDD power supply for the device
-- VDDMIC-supply: VDDMIC power supply for the device
-- VDDIO-supply: VDDIO power supply for the device
- (See Documentation/devicetree/bindings/regulator/regulator.txt for further
- information relating to regulators)
-
-Optional properties:
-- interrupt-names : Name associated with interrupt line. Should be "wakeup" if
- interrupt is to be used to wake system, otherwise "irq" should be used.
-- wakeup-source: Flag to indicate this device can wake system (suspend/resume).
-
-- #clock-cells : Should be set to '<1>', two clock sources provided;
-- clock-output-names : Names given for DAI clock outputs (WCLK & BCLK);
-
-- clocks : phandle and clock specifier for codec MCLK.
-- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
-
-- dlg,micbias-lvl : Voltage (mV) for Mic Bias
- [<1600>, <1800>, <2000>, <2200>, <2400>, <2600>]
-- dlg,mic-amp-in-sel : Mic input source type
- ["diff", "se_p", "se_n"]
-
-Deprecated properties:
-- dlg,ldo-lvl : Required internal LDO voltage (mV) level for digital engine
- (LDO unavailable in production HW so property no longer required).
-
-======
-
-Child node - 'da7219_aad':
-
-Optional properties:
-- dlg,micbias-pulse-lvl : Mic bias higher voltage pulse level (mV).
- [<2800>, <2900>]
-- dlg,micbias-pulse-time : Mic bias higher voltage pulse duration (ms)
-- dlg,btn-cfg : Periodic button press measurements for 4-pole jack (ms)
- [<2>, <5>, <10>, <50>, <100>, <200>, <500>]
-- dlg,mic-det-thr : Impedance threshold for mic detection measurement (Ohms)
- [<200>, <500>, <750>, <1000>]
-- dlg,jack-ins-deb : Debounce time for jack insertion (ms)
- [<5>, <10>, <20>, <50>, <100>, <200>, <500>, <1000>]
-- dlg,jack-det-rate: Jack type detection latency (3/4 pole)
- ["32ms_64ms", "64ms_128ms", "128ms_256ms", "256ms_512ms"]
-- dlg,jack-rem-deb : Debounce time for jack removal (ms)
- [<1>, <5>, <10>, <20>]
-- dlg,a-d-btn-thr : Impedance threshold between buttons A and D
- [0x0 - 0xFF]
-- dlg,d-b-btn-thr : Impedance threshold between buttons D and B
- [0x0 - 0xFF]
-- dlg,b-c-btn-thr : Impedance threshold between buttons B and C
- [0x0 - 0xFF]
-- dlg,c-mic-btn-thr : Impedance threshold between button C and Mic
- [0x0 - 0xFF]
-- dlg,btn-avg : Number of 8-bit readings for averaged button measurement
- [<1>, <2>, <4>, <8>]
-- dlg,adc-1bit-rpt : Repeat count for 1-bit button measurement
- [<1>, <2>, <4>, <8>]
-
-======
-
-Example:
-
- codec: da7219@1a {
- compatible = "dlg,da7219";
- reg = <0x1a>;
-
- interrupt-parent = <&gpio6>;
- interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
-
- VDD-supply = <&reg_audio>;
- VDDMIC-supply = <&reg_audio>;
- VDDIO-supply = <&reg_audio>;
-
- #clock-cells = <1>;
- clock-output-names = "dai-wclk", "dai-bclk";
-
- clocks = <&clks 201>;
- clock-names = "mclk";
-
- dlg,ldo-lvl = <1200>;
- dlg,micbias-lvl = <2600>;
- dlg,mic-amp-in-sel = "diff";
-
- da7219_aad {
- dlg,btn-cfg = <50>;
- dlg,mic-det-thr = <500>;
- dlg,jack-ins-deb = <20>;
- dlg,jack-det-rate = "32ms_64ms";
- dlg,jack-rem-deb = <1>;
-
- dlg,a-d-btn-thr = <0xa>;
- dlg,d-b-btn-thr = <0x16>;
- dlg,b-c-btn-thr = <0x21>;
- dlg,c-mic-btn-thr = <0x3E>;
-
- dlg,btn-avg = <4>;
- dlg,adc-1bit-rpt = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/da9055.txt b/Documentation/devicetree/bindings/sound/da9055.txt
deleted file mode 100644
index 75c6338b6ae2..000000000000
--- a/Documentation/devicetree/bindings/sound/da9055.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Dialog DA9055 Audio CODEC
-
-DA9055 provides Audio CODEC support (I2C only).
-
-The Audio CODEC device in DA9055 has its own I2C address which is configurable,
-so the device is instantiated separately from the PMIC (MFD) device.
-
-For details on accompanying PMIC I2C device, see the following:
-Documentation/devicetree/bindings/mfd/da9055.txt
-
-Required properties:
-
- - compatible: "dlg,da9055-codec"
- - reg: Specifies the I2C slave address
-
-
-Example:
-
- codec: da9055-codec@1a {
- compatible = "dlg,da9055-codec";
- reg = <0x1a>;
- };
diff --git a/Documentation/devicetree/bindings/sound/dai-common.yaml b/Documentation/devicetree/bindings/sound/dai-common.yaml
new file mode 100644
index 000000000000..1aed2f0f1775
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/dai-common.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/dai-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Digital Audio Interface Common Properties
+
+maintainers:
+ - Jerome Brunet <jbrunet@baylibre.com>
+
+allOf:
+ - $ref: component-common.yaml#
+
+properties:
+ '#sound-dai-cells': true
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/dai-params.yaml b/Documentation/devicetree/bindings/sound/dai-params.yaml
index f5fb71f9b603..cd8508175564 100644
--- a/Documentation/devicetree/bindings/sound/dai-params.yaml
+++ b/Documentation/devicetree/bindings/sound/dai-params.yaml
@@ -11,15 +11,14 @@ maintainers:
select: false
-$defs:
-
- dai-channels:
+properties:
+ convert-channels:
description: Number of audio channels used by DAI
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 32
- dai-sample-format:
+ convert-sample-format:
description: Audio sample format used by DAI
$ref: /schemas/types.yaml#/definitions/string
enum:
@@ -29,12 +28,10 @@ $defs:
- s24_3le
- s32_le
- dai-sample-rate:
+ convert-rate:
description: Audio sample rate used by DAI
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 8000
maximum: 192000
-properties: {}
-
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
index f46c66bc6b2d..beef193aaaeb 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
@@ -102,21 +102,21 @@ properties:
default: 2
interrupts:
- anyOf:
- - minItems: 1
- items:
- - description: TX interrupt
- - description: RX interrupt
- - items:
- - description: common/combined interrupt
+ minItems: 1
+ maxItems: 2
interrupt-names:
oneOf:
- - minItems: 1
+ - description: TX interrupt
+ const: tx
+ - description: RX interrupt
+ const: rx
+ - description: TX and RX interrupts
items:
- const: tx
- const: rx
- - const: common
+ - description: Common/combined interrupt
+ const: common
fck_parent:
$ref: /schemas/types.yaml#/definitions/string
@@ -167,6 +167,7 @@ required:
- interrupt-names
allOf:
+ - $ref: dai-common.yaml#
- if:
properties:
opmode:
@@ -177,7 +178,7 @@ allOf:
required:
- tdm-slots
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt b/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
deleted file mode 100644
index 3ffc2562fb31..000000000000
--- a/Documentation/devicetree/bindings/sound/davinci-mcbsp.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments DaVinci McBSP module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This binding describes the "Multi-channel Buffered Serial Port" (McBSP)
-audio interface found in some TI DaVinci processors like the OMAP-L138 or AM180x.
-
-
-Required properties:
-~~~~~~~~~~~~~~~~~~~~
-- compatible :
- "ti,da850-mcbsp" : for DA850, AM180x and OPAM-L138 platforms
-
-- reg : physical base address and length of the controller memory mapped
- region(s).
-- reg-names : Should contain:
- * "mpu" for the main registers (required).
- * "dat" for the data FIFO (optional).
-
-- dmas: three element list of DMA controller phandles, DMA request line and
- TC channel ordered triplets.
-- dma-names: identifier string for each DMA request line in the dmas property.
- These strings correspond 1:1 with the ordered pairs in dmas. The dma
- identifiers must be "rx" and "tx".
-
-Optional properties:
-~~~~~~~~~~~~~~~~~~~~
-- interrupts : Interrupt numbers for McBSP
-- interrupt-names : Known interrupt names are "rx" and "tx"
-
-- pinctrl-0: Should specify pin control group used for this controller.
-- pinctrl-names: Should contain only one value - "default", for more details
- please refer to pinctrl-bindings.txt
-
-Example (AM1808):
-~~~~~~~~~~~~~~~~~
-
-mcbsp0: mcbsp@1d10000 {
- compatible = "ti,da850-mcbsp";
- pinctrl-names = "default";
- pinctrl-0 = <&mcbsp0_pins>;
-
- reg = <0x00110000 0x1000>,
- <0x00310000 0x1000>;
- reg-names = "mpu", "dat";
- interrupts = <97 98>;
- interrupt-names = "rx", "tx";
- dmas = <&edma0 3 1
- &edma0 2 1>;
- dma-names = "tx", "rx";
-};
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml
new file mode 100644
index 000000000000..4fa677023827
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/davinci-mcbsp.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/davinci-mcbsp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: McBSP Controller for TI SoCs
+
+maintainers:
+ - Bastien Curutchet <bastien.curutchet@bootlin.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,da850-mcbsp
+
+ reg:
+ minItems: 1
+ items:
+ - description: CFG registers
+ - description: data registers
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: mpu
+ - const: dat
+
+ dmas:
+ items:
+ - description: transmission DMA channel
+ - description: reception DMA channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ interrupts:
+ items:
+ - description: RX interrupt
+ - description: TX interrupt
+
+ interrupt-names:
+ items:
+ - const: rx
+ - const: tx
+
+ clocks:
+ minItems: 1
+ items:
+ - description: functional clock
+ - description: external input clock for sample rate generator.
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: fck
+ - const: clks
+
+ power-domains:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ ti,T1-framing-tx:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If the property is present, tx data delay is set to 2 bit clock periods.
+ McBSP will insert a blank period (high-impedance period) before the first
+ data bit. This can be used to interface to T1-framing devices.
+
+ ti,T1-framing-rx:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If the property is present, rx data delay is set to 2 bit clock periods.
+ McBSP will discard the bit preceding the data stream (called framing bit).
+ This can be used to interface to T1-framing devices.
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - reg-names
+ - dmas
+ - dma-names
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ mcbsp0@1d10000 {
+ #sound-dai-cells = <0>;
+ compatible = "ti,da850-mcbsp";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp0_pins>;
+
+ reg = <0x111000 0x1000>,
+ <0x311000 0x1000>;
+ reg-names = "mpu", "dat";
+ interrupts = <97>, <98>;
+ interrupt-names = "rx", "tx";
+ dmas = <&edma0 3 1>,
+ <&edma0 2 1>;
+ dma-names = "tx", "rx";
+
+ clocks = <&psc1 14>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/dialog,da7219.yaml b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
new file mode 100644
index 000000000000..19137abdba3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/dialog,da7219.yaml
@@ -0,0 +1,238 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/dialog,da7219.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA7219 Audio Codec
+
+maintainers:
+ - David Rau <David.Rau.opensource@dm.renesas.com>
+
+description:
+ The DA7219 is an ultra low-power audio codec with
+ in-built advanced accessory detection (AAD) for mobile
+ computing and accessory applications, which supports
+ sample rates up to 96 kHz at 24-bit resolution.
+
+properties:
+ compatible:
+ const: dlg,da7219
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ VDD-supply:
+ description:
+ VDD power supply for the device.
+
+ VDDMIC-supply:
+ description:
+ VDDMIC power supply for the device.
+
+ VDDIO-supply:
+ description:
+ VDDIO power supply for the device.
+
+ interrupt-names:
+ description:
+ Should be "wakeup" if interrupt is to be used to wake system,
+ otherwise "irq" should be used.
+ enum:
+ - wakeup
+ - irq
+
+ wakeup-source:
+ type: boolean
+ description:
+ Flag to indicate this device can wake system (suspend/resume).
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ minItems: 2
+ maxItems: 2
+ description:
+ Name given for DAI WCLK and BCLK outputs.
+
+ clocks:
+ maxItems: 1
+ description:
+ phandle and clock specifier for codec MCLK.
+
+ clock-names:
+ const: mclk
+
+ dlg,micbias-lvl:
+ enum: [1600, 1800, 2000, 2200, 2400, 2600]
+ description:
+ Voltage (mV) for Mic Bias.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,mic-amp-in-sel:
+ enum: [diff, se_p, se_n]
+ description:
+ Mic input source type.
+
+ diff - Differential.
+
+ se_p - MIC_P.
+ Positive differential analog microphone input.
+
+ se_n - MIC_N.
+ Negative differential analog microphone input.
+ $ref: /schemas/types.yaml#/definitions/string
+
+ da7219_aad:
+ type: object
+ additionalProperties: false
+ description:
+ Configuration of advanced accessory detection.
+ properties:
+ dlg,micbias-pulse-lvl:
+ enum: [2800, 2900]
+ description:
+ Mic bias higher voltage pulse level (mV).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,micbias-pulse-time:
+ description:
+ Mic bias higher voltage pulse duration (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+
+ dlg,btn-cfg:
+ enum: [2, 5, 10, 50, 100, 200, 500]
+ description:
+ Periodic button press measurements for 4-pole jack (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,mic-det-thr:
+ enum: [200, 500, 750, 1000]
+ description:
+ Impedance threshold for mic detection measurement (Ohms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,jack-ins-deb:
+ enum: [5, 10, 20, 50, 100, 200, 500, 1000]
+ description:
+ Debounce time for jack insertion (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,jack-ins-det-pty:
+ enum: [low, high]
+ description:
+ Polarity for jack insertion detection.
+ $ref: /schemas/types.yaml#/definitions/string
+
+ dlg,jack-det-rate:
+ enum: ["32_64", "64_128", "128_256", "256_512"]
+ description:
+ Jack type (3/4 pole) detection latency (ms).
+ $ref: /schemas/types.yaml#/definitions/string
+
+ dlg,jack-rem-deb:
+ enum: [1, 5, 10, 20]
+ description:
+ Debounce time for jack removal (ms).
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,a-d-btn-thr:
+ description:
+ Impedance threshold between buttons A and D.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,d-b-btn-thr:
+ description:
+ Impedance threshold between buttons D and B.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,b-c-btn-thr:
+ description:
+ Impedance threshold between buttons B and C.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,c-mic-btn-thr:
+ description:
+ Impedance threshold between button C and Mic.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+
+ dlg,btn-avg:
+ enum: [1, 2, 4, 8]
+ description:
+ Number of 8-bit readings for averaged button measurement.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ dlg,adc-1bit-rpt:
+ enum: [1, 2, 4, 8]
+ description:
+ Repeat count for 1-bit button measurement.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - VDD-supply
+ - VDDMIC-supply
+ - VDDIO-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec: da7219@1a {
+ compatible = "dlg,da7219";
+ reg = <0x1a>;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ VDD-supply = <&vdd_reg>;
+ VDDMIC-supply = <&vddmic_reg>;
+ VDDIO-supply = <&vddio_reg>;
+
+ #clock-cells = <1>;
+ clock-output-names = "da7219-dai-wclk", "da7219-dai-bclk";
+
+ clocks = <&clks 201>;
+ clock-names = "mclk";
+
+ dlg,micbias-lvl = <2600>;
+ dlg,mic-amp-in-sel = "diff";
+
+ da7219_aad {
+ dlg,btn-cfg = <50>;
+ dlg,mic-det-thr = <500>;
+ dlg,jack-ins-deb = <20>;
+ dlg,jack-ins-det-pty = "low";
+ dlg,jack-det-rate = "32_64";
+ dlg,jack-rem-deb = <1>;
+
+ dlg,a-d-btn-thr = <0xa>;
+ dlg,d-b-btn-thr = <0x16>;
+ dlg,b-c-btn-thr = <0x21>;
+ dlg,c-mic-btn-thr = <0x3E>;
+
+ dlg,btn-avg = <4>;
+ dlg,adc-1bit-rpt = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/dlg,da7213.yaml b/Documentation/devicetree/bindings/sound/dlg,da7213.yaml
new file mode 100644
index 000000000000..c2dede1e82ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/dlg,da7213.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/dlg,da7213.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA7212/DA7213 Audio Codec
+
+maintainers:
+ - Support Opensource <support.opensource@diasemi.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - dlg,da7212
+ - dlg,da7213
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+ "#sound-dai-cells":
+ const: 0
+
+ dlg,micbias1-lvl:
+ description: Voltage (mV) for Mic Bias 1
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1600, 2200, 2500, 3000 ]
+
+ dlg,micbias2-lvl:
+ description: Voltage (mV) for Mic Bias 2
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1600, 2200, 2500, 3000 ]
+
+ dlg,dmic-data-sel:
+ description: DMIC channel select based on clock edge
+ enum: [ lrise_rfall, lfall_rrise ]
+
+ dlg,dmic-samplephase:
+ description: When to sample audio from DMIC
+ enum: [ on_clkedge, between_clkedge ]
+
+ dlg,dmic-clkrate:
+ description: DMIC clock frequency (Hz)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1500000, 3000000 ]
+
+ VDDA-supply:
+ description: Analogue power supply
+
+ VDDIO-supply:
+ description: I/O power supply
+
+ VDDMIC-supply:
+ description: Mic Bias
+
+ VDDSP-supply:
+ description: Speaker supply
+
+ ports:
+ $ref: audio-graph-port.yaml#/definitions/ports
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "dlg,da7213";
+ reg = <0x1a>;
+
+ clocks = <&clks 201>;
+ clock-names = "mclk";
+
+ #sound-dai-cells = <0>;
+
+ dlg,micbias1-lvl = <2500>;
+ dlg,micbias2-lvl = <2500>;
+
+ dlg,dmic-data-sel = "lrise_rfall";
+ dlg,dmic-samplephase = "between_clkedge";
+ dlg,dmic-clkrate = <3000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/dmic-codec.yaml b/Documentation/devicetree/bindings/sound/dmic-codec.yaml
new file mode 100644
index 000000000000..cc3c84dd4c26
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/dmic-codec.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/dmic-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic PDM Digital microphone (DMIC) codec
+
+maintainers:
+ - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: dmic-codec
+
+ '#sound-dai-cells':
+ const: 0
+
+ vref-supply:
+ description: Phandle to the digital microphone reference supply
+
+ dmicen-gpios:
+ description: GPIO specifier for DMIC to control start and stop
+ maxItems: 1
+
+ num-channels:
+ description: Number of microphones on this DAI
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 8
+ default: 8
+
+ modeswitch-delay-ms:
+ description: Delay (in ms) to complete DMIC mode switch
+
+ wakeup-delay-ms:
+ description: Delay (in ms) after enabling the DMIC
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dmic {
+ compatible = "dmic-codec";
+ dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>;
+ num-channels = <1>;
+ wakeup-delay-ms = <50>;
+ modeswitch-delay-ms = <35>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/dmic.txt b/Documentation/devicetree/bindings/sound/dmic.txt
deleted file mode 100644
index 32e871037269..000000000000
--- a/Documentation/devicetree/bindings/sound/dmic.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Device-Tree bindings for Digital microphone (DMIC) codec
-
-This device support generic PDM digital microphone.
-
-Required properties:
- - compatible: should be "dmic-codec".
-
-Optional properties:
- - dmicen-gpios: GPIO specifier for dmic to control start and stop
- - num-channels: Number of microphones on this DAI
- - wakeup-delay-ms: Delay (in ms) after enabling the DMIC
- - modeswitch-delay-ms: Delay (in ms) to complete DMIC mode switch
-
-Example node:
-
- dmic_codec: dmic@0 {
- compatible = "dmic-codec";
- dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>;
- num-channels = <1>;
- wakeup-delay-ms <50>;
- modeswitch-delay-ms <35>;
- };
diff --git a/Documentation/devicetree/bindings/sound/es8328.txt b/Documentation/devicetree/bindings/sound/es8328.txt
deleted file mode 100644
index 33fbf058c997..000000000000
--- a/Documentation/devicetree/bindings/sound/es8328.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Everest ES8328 audio CODEC
-
-This device supports both I2C and SPI.
-
-Required properties:
-
- - compatible : Should be "everest,es8328" or "everest,es8388"
- - DVDD-supply : Regulator providing digital core supply voltage 1.8 - 3.6V
- - AVDD-supply : Regulator providing analog supply voltage 3.3V
- - PVDD-supply : Regulator providing digital IO supply voltage 1.8 - 3.6V
- - IPVDD-supply : Regulator providing analog output voltage 3.3V
- - clocks : A 22.5792 or 11.2896 MHz clock
- - reg : the I2C address of the device for I2C, the chip select number for SPI
-
-Pins on the device (for linking into audio routes):
-
- * LOUT1
- * LOUT2
- * ROUT1
- * ROUT2
- * LINPUT1
- * RINPUT1
- * LINPUT2
- * RINPUT2
- * Mic Bias
-
-
-Example:
-
-codec: es8328@11 {
- compatible = "everest,es8328";
- DVDD-supply = <&reg_3p3v>;
- AVDD-supply = <&reg_3p3v>;
- PVDD-supply = <&reg_3p3v>;
- HPVDD-supply = <&reg_3p3v>;
- clocks = <&clks 169>;
- reg = <0x11>;
-};
diff --git a/Documentation/devicetree/bindings/sound/everest,es7134.txt b/Documentation/devicetree/bindings/sound/everest,es7134.txt
deleted file mode 100644
index 091666069bde..000000000000
--- a/Documentation/devicetree/bindings/sound/everest,es7134.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-ES7134 i2s DA converter
-
-Required properties:
-- compatible : "everest,es7134" or
- "everest,es7144" or
- "everest,es7154"
-- VDD-supply : regulator phandle for the VDD supply
-- PVDD-supply: regulator phandle for the PVDD supply for the es7154
-
-Example:
-
-i2s_codec: external-codec {
- compatible = "everest,es7134";
- VDD-supply = <&vcc_5v>;
-};
diff --git a/Documentation/devicetree/bindings/sound/everest,es71x4.yaml b/Documentation/devicetree/bindings/sound/everest,es71x4.yaml
new file mode 100644
index 000000000000..efe9f3fd3778
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es71x4.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/everest,es71x4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Everest ES7134/7144/7154 2 channels I2S analog to digital converter
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - everest,es7134
+ - everest,es7144
+ - everest,es7154
+
+ VDD-supply: true
+ PVDD-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - VDD-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - everest,es7134
+ - everest,es7144
+ then:
+ properties:
+ PVDD-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - everest,es7154
+ then:
+ required:
+ - PVDD-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ codec {
+ compatible = "everest,es7134";
+ #sound-dai-cells = <0>;
+ VDD-supply = <&vdd_supply>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/everest,es7241.txt b/Documentation/devicetree/bindings/sound/everest,es7241.txt
deleted file mode 100644
index 28f82cf4959f..000000000000
--- a/Documentation/devicetree/bindings/sound/everest,es7241.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-ES7241 i2s AD converter
-
-Required properties:
-- compatible : "everest,es7241"
-- VDDP-supply: regulator phandle for the VDDA supply
-- VDDA-supply: regulator phandle for the VDDP supply
-- VDDD-supply: regulator phandle for the VDDD supply
-
-Optional properties:
-- reset-gpios: gpio connected to the reset pin
-- m0-gpios : gpio connected to the m0 pin
-- m1-gpios : gpio connected to the m1 pin
-- everest,sdout-pull-down:
- Format used by the serial interface is controlled by pulling
- the sdout. If the sdout is pulled down, leftj format is used.
- If this property is not provided, sdout is assumed to pulled
- up and i2s format is used
-
-Example:
-
-linein: audio-codec@2 {
- #sound-dai-cells = <0>;
- compatible = "everest,es7241";
- VDDA-supply = <&vcc_3v3>;
- VDDP-supply = <&vcc_3v3>;
- VDDD-supply = <&vcc_3v3>;
- reset-gpios = <&gpio GPIOH_42>;
-};
diff --git a/Documentation/devicetree/bindings/sound/everest,es7241.yaml b/Documentation/devicetree/bindings/sound/everest,es7241.yaml
new file mode 100644
index 000000000000..e5cfb40f1ef2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es7241.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/everest,es7241.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Everest ES7241 2 channels I2S analog to digital converter
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - everest,es7241
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO connected to the reset pin
+
+ m0-gpios:
+ maxItems: 1
+ description: GPIO connected to the m0 pin
+
+ m1-gpios:
+ maxItems: 1
+ description: GPIO connected to the m0 pin
+
+ everest,sdout-pull-down:
+ type: boolean
+ description:
+ Format used by the serial interface is controlled by pulling
+ the sdout. If the sdout is pulled down, leftj format is used.
+ If this property is not provided, sdout is assumed to pulled
+ up and i2s format is used
+
+ VDDP-supply: true
+ VDDA-supply: true
+ VDDD-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - VDDP-supply
+ - VDDA-supply
+ - VDDD-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ codec {
+ compatible = "everest,es7241";
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ VDDP-supply = <&vddp_supply>;
+ VDDA-supply = <&vdda_supply>;
+ VDDD-supply = <&vddd_supply>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.yaml b/Documentation/devicetree/bindings/sound/everest,es8316.yaml
index 3b752bba748b..81a0215050e0 100644
--- a/Documentation/devicetree/bindings/sound/everest,es8316.yaml
+++ b/Documentation/devicetree/bindings/sound/everest,es8316.yaml
@@ -4,15 +4,39 @@
$id: http://devicetree.org/schemas/sound/everest,es8316.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Everest ES8316 audio CODEC
+title: Everest ES8311, ES8316 and ES8323 audio CODECs
maintainers:
- Daniel Drake <drake@endlessm.com>
- Katsuhiro Suzuki <katsuhiro@katsuster.net>
+ - Matteo Martelli <matteomartelli3@gmail.com>
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+description: |
+ Everest ES8311, ES8316 and ES8323 audio CODECs
+
+ Pins on the device (for linking into audio routes):
+
+ Outputs:
+ * LOUT: Left Analog Output
+ * ROUT: Right Analog Output
+ * MICBIAS: Microphone Bias
+
+ Inputs:
+ * MIC1P: Microphone 1 Positive Analog Input
+ * MIC1N: Microphone 1 Negative Analog Input
+ * MIC2P: Microphone 2 Positive Analog Input
+ * MIC2N: Microphone 2 Negative Analog Input
+
+allOf:
+ - $ref: dai-common.yaml#
properties:
compatible:
- const: everest,es8316
+ enum:
+ - everest,es8311
+ - everest,es8316
+ - everest,es8323
reg:
maxItems: 1
@@ -25,6 +49,10 @@ properties:
items:
- const: mclk
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
"#sound-dai-cells":
const: 0
@@ -33,11 +61,11 @@ required:
- reg
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
es8316: codec@11 {
diff --git a/Documentation/devicetree/bindings/sound/everest,es8326.yaml b/Documentation/devicetree/bindings/sound/everest,es8326.yaml
index 07781408e788..b5594a9d508e 100755..100644
--- a/Documentation/devicetree/bindings/sound/everest,es8326.yaml
+++ b/Documentation/devicetree/bindings/sound/everest,es8326.yaml
@@ -24,6 +24,10 @@ properties:
items:
- const: mclk
+ interrupts:
+ maxItems: 1
+ description: interrupt output for headset detection
+
"#sound-dai-cells":
const: 0
@@ -32,12 +36,13 @@ properties:
description: |
just the value of reg 57. Bit(3) decides whether the jack polarity is inverted.
Bit(2) decides whether the button on the headset is inverted.
- Bit(1)/(0) decides the mic properity to be OMTP/CTIA or auto.
+ Bit(1)/(0) decides the mic property to be OMTP/CTIA or auto.
minimum: 0x00
maximum: 0x0f
default: 0x0f
everest,mic1-src:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint8
description:
the value of reg 2A when headset plugged.
@@ -46,6 +51,7 @@ properties:
default: 0x22
everest,mic2-src:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint8
description:
the value of reg 2A when headset unplugged.
@@ -87,7 +93,7 @@ properties:
0 means the chip detect jack type again after button released.
minimum: 0
maximum: 0x7f
- default: 0x45
+ default: 0x00
required:
- compatible
@@ -107,10 +113,8 @@ examples:
clocks = <&clks 10>;
clock-names = "mclk";
#sound-dai-cells = <0>;
- everest,mic1-src = [22];
- everest,mic2-src = [44];
everest,jack-pol = [0e];
everest,interrupt-src = [08];
- everest,interrupt-clk = [45];
+ everest,interrupt-clk = [00];
};
};
diff --git a/Documentation/devicetree/bindings/sound/everest,es8328.yaml b/Documentation/devicetree/bindings/sound/everest,es8328.yaml
new file mode 100644
index 000000000000..ddddd7b143ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es8328.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/everest,es8328.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Everest ES8328 audio CODEC
+
+description:
+ Everest Audio Codec, which can be connected via I2C or SPI.
+ Pins on the device (for linking into audio routes) are
+ * LOUT1
+ * LOUT2
+ * ROUT1
+ * ROUT2
+ * LINPUT1
+ * RINPUT1
+ * LINPUT2
+ * RINPUT2
+ * Mic Bias
+
+maintainers:
+ - David Yang <yangxiaohua@everest-semi.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - everest,es8328
+ - items:
+ - enum:
+ - everest,es8388
+ - const: everest,es8328
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: A 22.5792 or 11.2896 MHz clock
+
+ DVDD-supply:
+ description: Regulator providing digital core supply voltage 1.8 - 3.6V
+
+ AVDD-supply:
+ description: Regulator providing analog supply voltage 3.3V
+
+ PVDD-supply:
+ description: Regulator providing digital IO supply voltage 1.8 - 3.6V
+
+ HPVDD-supply:
+ description: Regulator providing analog output voltage 3.3V
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - DVDD-supply
+ - AVDD-supply
+ - PVDD-supply
+ - HPVDD-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ es8328: codec@11 {
+ compatible = "everest,es8328";
+ reg = <0x11>;
+ AVDD-supply = <&reg_3p3v>;
+ DVDD-supply = <&reg_3p3v>;
+ HPVDD-supply = <&reg_3p3v>;
+ PVDD-supply = <&reg_3p3v>;
+ clocks = <&clks 169>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/everest,es8375.yaml b/Documentation/devicetree/bindings/sound/everest,es8375.yaml
new file mode 100644
index 000000000000..4a3d671c66b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es8375.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/everest,es8375.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Everest ES8375 audio CODEC
+
+maintainers:
+ - Michael Zhang <zhangyi@everest-semi.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: everest,es8375
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock for master clock (MCLK)
+
+ clock-names:
+ items:
+ - const: mclk
+
+ vdda-supply:
+ description:
+ Analogue power supply.
+
+ vddd-supply:
+ description:
+ Interface power supply.
+
+ everest,mclk-src:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description: |
+ Represents the MCLK/SCLK pair pins used as the internal clock.
+ 0 represents selecting MCLK.
+ 1 represents selecting SCLK.
+ enum: [0, 1]
+ default: 0
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - vdda-supply
+ - vddd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ es8375: codec@18 {
+ compatible = "everest,es8375";
+ reg = <0x18>;
+ vdda-supply = <&vdd3v3>;
+ vddd-supply = <&vdd3v3>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/everest,es8389.yaml b/Documentation/devicetree/bindings/sound/everest,es8389.yaml
new file mode 100644
index 000000000000..a673df485ab3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es8389.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/everest,es8389.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Everest ES8389 audio CODEC
+
+maintainers:
+ - Michael Zhang <zhangyi@everest-semi.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: everest,es8389
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock for master clock (MCLK)
+
+ clock-names:
+ items:
+ - const: mclk
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ es8389: codec@10 {
+ compatible = "everest,es8389";
+ reg = <0x10>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/foursemi,fs2105s.yaml b/Documentation/devicetree/bindings/sound/foursemi,fs2105s.yaml
new file mode 100644
index 000000000000..4da735317e0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/foursemi,fs2105s.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/foursemi,fs2105s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FourSemi FS2104/5S Digital Audio Amplifier
+
+maintainers:
+ - Nick Li <nick.li@foursemi.com>
+
+description:
+ The FS2104 is a 15W Inductor-Less, Stereo, Closed-Loop,
+ Digital Input Class-D Power Amplifier with Enhanced Signal Processing.
+ The FS2105S is a 30W Inductor-Less, Stereo, Closed-Loop,
+ Digital Input Class-D Power Amplifier with Enhanced Signal Processing.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - foursemi,fs2104
+ - const: foursemi,fs2105s
+ - enum:
+ - foursemi,fs2105s
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The clock of I2S BCLK
+
+ clock-names:
+ items:
+ - const: bclk
+
+ interrupts:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ pvdd-supply:
+ description:
+ Regulator for power supply(PVDD in datasheet).
+
+ dvdd-supply:
+ description:
+ Regulator for digital supply(DVDD in datasheet).
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ It's the SDZ pin in datasheet, the pin is active low,
+ it will power down and reset the chip to shut down state.
+
+ firmware-name:
+ maxItems: 1
+ description: |
+ The firmware(*.bin) contains:
+ a. Register initialization settings
+ b. DSP effect parameters
+ c. Multi-scene sound effect configurations(optional)
+ It's gernerated by FourSemi's tuning tool.
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - pvdd-supply
+ - dvdd-supply
+ - reset-gpios
+ - firmware-name
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@68 {
+ compatible = "foursemi,fs2105s";
+ reg = <0x68>;
+ clocks = <&clocks 18>;
+ clock-names = "bclk";
+ #sound-dai-cells = <0>;
+ pvdd-supply = <&pvdd_supply>;
+ dvdd-supply = <&dvdd_supply>;
+ reset-gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ firmware-name = "fs2105s-btl-2p0-0s.bin";
+ pinctrl-names = "default";
+ pinctrl-0 = <&fs210x_pins_default>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
deleted file mode 100644
index 998b4c8a7f78..000000000000
--- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-Freescale Asynchronous Sample Rate Converter (ASRC) Controller
-
-The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of a
-signal associated with an input clock into a signal associated with a different
-output clock. The driver currently works as a Front End of DPCM with other Back
-Ends Audio controller such as ESAI, SSI and SAI. It has three pairs to support
-three substreams within totally 10 channels.
-
-Required properties:
-
- - compatible : Compatible list, should contain one of the following
- compatibles:
- "fsl,imx35-asrc",
- "fsl,imx53-asrc",
- "fsl,imx8qm-asrc",
- "fsl,imx8qxp-asrc",
-
- - reg : Offset and length of the register set for the device.
-
- - interrupts : Contains the spdif interrupt.
-
- - dmas : Generic dma devicetree binding as described in
- Documentation/devicetree/bindings/dma/dma.txt.
-
- - dma-names : Contains "rxa", "rxb", "rxc", "txa", "txb" and "txc".
-
- - clocks : Contains an entry for each entry in clock-names.
-
- - clock-names : Contains the following entries
- "mem" Peripheral access clock to access registers.
- "ipg" Peripheral clock to driver module.
- "asrck_<0-f>" Clock sources for input and output clock.
- "spba" The spba clock is required when ASRC is placed as a
- bus slave of the Shared Peripheral Bus and when two
- or more bus masters (CPU, DMA or DSP) try to access
- it. This property is optional depending on the SoC
- design.
-
- - fsl,asrc-rate : Defines a mutual sample rate used by DPCM Back Ends.
-
- - fsl,asrc-width : Defines a mutual sample width used by DPCM Back Ends.
-
- - fsl,asrc-clk-map : Defines clock map used in driver. which is required
- by imx8qm/imx8qxp platform
- <0> - select the map for asrc0 in imx8qm/imx8qxp
- <1> - select the map for asrc1 in imx8qm/imx8qxp
-
-Optional properties:
-
- - big-endian : If this property is absent, the little endian mode
- will be in use as default. Otherwise, the big endian
- mode will be in use for all the device registers.
-
- - fsl,asrc-format : Defines a mutual sample format used by DPCM Back
- Ends, which can replace the fsl,asrc-width.
- The value is 2 (S16_LE), or 6 (S24_LE).
-
-Example:
-
-asrc: asrc@2034000 {
- compatible = "fsl,imx53-asrc";
- reg = <0x02034000 0x4000>;
- interrupts = <0 50 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks 107>, <&clks 107>, <&clks 0>,
- <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>,
- <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>,
- <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>,
- <&clks 107>, <&clks 0>, <&clks 0>;
- clock-names = "mem", "ipg", "asrck0",
- "asrck_1", "asrck_2", "asrck_3", "asrck_4",
- "asrck_5", "asrck_6", "asrck_7", "asrck_8",
- "asrck_9", "asrck_a", "asrck_b", "asrck_c",
- "asrck_d", "asrck_e", "asrck_f";
- dmas = <&sdma 17 23 1>, <&sdma 18 23 1>, <&sdma 19 23 1>,
- <&sdma 20 23 1>, <&sdma 21 23 1>, <&sdma 22 23 1>;
- dma-names = "rxa", "rxb", "rxc",
- "txa", "txb", "txc";
- fsl,asrc-rate = <48000>;
- fsl,asrc-width = <16>;
-};
diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.txt b/Documentation/devicetree/bindings/sound/fsl,audmix.txt
deleted file mode 100644
index 840b7e0d6a63..000000000000
--- a/Documentation/devicetree/bindings/sound/fsl,audmix.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-NXP Audio Mixer (AUDMIX).
-
-The Audio Mixer is a on-chip functional module that allows mixing of two
-audio streams into a single audio stream. Audio Mixer has two input serial
-audio interfaces. These are driven by two Synchronous Audio interface
-modules (SAI). Each input serial interface carries 8 audio channels in its
-frame in TDM manner. Mixer mixes audio samples of corresponding channels
-from two interfaces into a single sample. Before mixing, audio samples of
-two inputs can be attenuated based on configuration. The output of the
-Audio Mixer is also a serial audio interface. Like input interfaces it has
-the same TDM frame format. This output is used to drive the serial DAC TDM
-interface of audio codec and also sent to the external pins along with the
-receive path of normal audio SAI module for readback by the CPU.
-
-The output of Audio Mixer can be selected from any of the three streams
- - serial audio input 1
- - serial audio input 2
- - mixed audio
-
-Mixing operation is independent of audio sample rate but the two audio
-input streams must have same audio sample rate with same number of channels
-in TDM frame to be eligible for mixing.
-
-Device driver required properties:
-=================================
- - compatible : Compatible list, contains "fsl,imx8qm-audmix"
-
- - reg : Offset and length of the register set for the device.
-
- - clocks : Must contain an entry for each entry in clock-names.
-
- - clock-names : Must include the "ipg" for register access.
-
- - power-domains : Must contain the phandle to AUDMIX power domain node
-
- - dais : Must contain a list of phandles to AUDMIX connected
- DAIs. The current implementation requires two phandles
- to SAI interfaces to be provided, the first SAI in the
- list being used to route the AUDMIX output.
-
-Device driver configuration example:
-======================================
- audmix: audmix@59840000 {
- compatible = "fsl,imx8qm-audmix";
- reg = <0x0 0x59840000 0x0 0x10000>;
- clocks = <&clk IMX8QXP_AUD_AUDMIX_IPG>;
- clock-names = "ipg";
- power-domains = <&pd_audmix>;
- dais = <&sai4>, <&sai5>;
- };
diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml
new file mode 100644
index 000000000000..3ad197b3c82c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml
@@ -0,0 +1,142 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,audmix.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Audio Mixer (AUDMIX).
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The Audio Mixer is a on-chip functional module that allows mixing of two
+ audio streams into a single audio stream. Audio Mixer has two input serial
+ audio interfaces. These are driven by two Synchronous Audio interface
+ modules (SAI). Each input serial interface carries 8 audio channels in its
+ frame in TDM manner. Mixer mixes audio samples of corresponding channels
+ from two interfaces into a single sample. Before mixing, audio samples of
+ two inputs can be attenuated based on configuration. The output of the
+ Audio Mixer is also a serial audio interface. Like input interfaces it has
+ the same TDM frame format. This output is used to drive the serial DAC TDM
+ interface of audio codec and also sent to the external pins along with the
+ receive path of normal audio SAI module for readback by the CPU.
+
+ The output of Audio Mixer can be selected from any of the three streams
+ - serial audio input 1
+ - serial audio input 2
+ - mixed audio
+
+ Mixing operation is independent of audio sample rate but the two audio
+ input streams must have same audio sample rate with same number of channels
+ in TDM frame to be eligible for mixing.
+
+properties:
+ compatible:
+ const: fsl,imx8qm-audmix
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ipg
+
+ power-domains:
+ maxItems: 1
+
+ dais:
+ description: contain a list of phandles to AUDMIX connected DAIs.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 2
+ items:
+ - description: the AUDMIX output
+ maxItems: 1
+ - description: serial audio input 1
+ maxItems: 1
+ - description: serial audio input 2
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ patternProperties:
+ '^port@[0-1]':
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+ description: Input port from SAI TX
+
+ properties:
+ port@2:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+ description: Output port to SAI RX
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ audmix@59840000 {
+ compatible = "fsl,imx8qm-audmix";
+ reg = <0x59840000 0x10000>;
+ clocks = <&amix_lpcg 0>;
+ clock-names = "ipg";
+ power-domains = <&pd_audmix>;
+ dais = <&sai4>, <&sai5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ playback-only;
+
+ amix_endpoint0: endpoint {
+ dai-tdm-slot-num = <8>;
+ dai-tdm-slot-width = <32>;
+ dai-tdm-slot-width-map = <32 8 32>;
+ dai-format = "dsp_a";
+ remote-endpoint = <&be00_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ playback-only;
+
+ amix_endpoint1: endpoint {
+ dai-tdm-slot-num = <8>;
+ dai-tdm-slot-width = <32>;
+ dai-tdm-slot-width-map = <32 8 32>;
+ dai-format = "dsp_a";
+ remote-endpoint = <&be01_ep>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ capture-only;
+
+ amix_endpoint2: endpoint {
+ dai-tdm-slot-num = <8>;
+ dai-tdm-slot-width = <32>;
+ dai-tdm-slot-width-map = <32 8 32>;
+ dai-format = "dsp_a";
+ bitclock-master;
+ frame-master;
+ remote-endpoint = <&be02_ep>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml
index bdde68a1059c..d5727f8bfb0b 100644
--- a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml
@@ -14,7 +14,13 @@ properties:
pattern: "^easrc@.*"
compatible:
- const: fsl,imx8mn-easrc
+ oneOf:
+ - enum:
+ - fsl,imx8mn-easrc
+ - items:
+ - enum:
+ - fsl,imx8mp-easrc
+ - const: fsl,imx8mn-easrc
reg:
maxItems: 1
@@ -45,8 +51,8 @@ properties:
- const: ctx3_tx
firmware-name:
- $ref: /schemas/types.yaml#/definitions/string
- const: imx/easrc/easrc-imx8mn.bin
+ items:
+ - const: imx/easrc/easrc-imx8mn.bin
description: The coefficient table for the filters
fsl,asrc-rate:
@@ -74,27 +80,30 @@ required:
- fsl,asrc-rate
- fsl,asrc-format
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/imx8mn-clock.h>
easrc: easrc@300c0000 {
- compatible = "fsl,imx8mn-easrc";
- reg = <0x300c0000 0x10000>;
- interrupts = <0x0 122 0x4>;
- clocks = <&clk IMX8MN_CLK_ASRC_ROOT>;
- clock-names = "mem";
- dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>,
- <&sdma2 18 23 0> , <&sdma2 19 23 0>,
- <&sdma2 20 23 0> , <&sdma2 21 23 0>,
- <&sdma2 22 23 0> , <&sdma2 23 23 0>;
- dma-names = "ctx0_rx", "ctx0_tx",
- "ctx1_rx", "ctx1_tx",
- "ctx2_rx", "ctx2_tx",
- "ctx3_rx", "ctx3_tx";
- firmware-name = "imx/easrc/easrc-imx8mn.bin";
- fsl,asrc-rate = <8000>;
- fsl,asrc-format = <2>;
+ compatible = "fsl,imx8mn-easrc";
+ reg = <0x300c0000 0x10000>;
+ interrupts = <0x0 122 0x4>;
+ clocks = <&clk IMX8MN_CLK_ASRC_ROOT>;
+ clock-names = "mem";
+ dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>,
+ <&sdma2 18 23 0> , <&sdma2 19 23 0>,
+ <&sdma2 20 23 0> , <&sdma2 21 23 0>,
+ <&sdma2 22 23 0> , <&sdma2 23 23 0>;
+ dma-names = "ctx0_rx", "ctx0_tx",
+ "ctx1_rx", "ctx1_tx",
+ "ctx2_rx", "ctx2_tx",
+ "ctx3_rx", "ctx3_tx";
+ firmware-name = "imx/easrc/easrc-imx8mn.bin";
+ fsl,asrc-rate = <8000>;
+ fsl,asrc-format = <2>;
};
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
deleted file mode 100644
index 0a2480aeecf0..000000000000
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-Freescale Enhanced Serial Audio Interface (ESAI) Controller
-
-The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port
-for serial communication with a variety of serial devices, including industry
-standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and
-other DSPs. It has up to six transmitters and four receivers.
-
-Required properties:
-
- - compatible : Compatible list, should contain one of the following
- compatibles:
- "fsl,imx35-esai",
- "fsl,vf610-esai",
- "fsl,imx6ull-esai",
- "fsl,imx8qm-esai",
-
- - reg : Offset and length of the register set for the device.
-
- - interrupts : Contains the spdif interrupt.
-
- - dmas : Generic dma devicetree binding as described in
- Documentation/devicetree/bindings/dma/dma.txt.
-
- - dma-names : Two dmas have to be defined, "tx" and "rx".
-
- - clocks : Contains an entry for each entry in clock-names.
-
- - clock-names : Includes the following entries:
- "core" The core clock used to access registers
- "extal" The esai baud clock for esai controller used to
- derive HCK, SCK and FS.
- "fsys" The system clock derived from ahb clock used to
- derive HCK, SCK and FS.
- "spba" The spba clock is required when ESAI is placed as a
- bus slave of the Shared Peripheral Bus and when two
- or more bus masters (CPU, DMA or DSP) try to access
- it. This property is optional depending on the SoC
- design.
-
- - fsl,fifo-depth : The number of elements in the transmit and receive
- FIFOs. This number is the maximum allowed value for
- TFCR[TFWM] or RFCR[RFWM].
-
- - fsl,esai-synchronous: This is a boolean property. If present, indicating
- that ESAI would work in the synchronous mode, which
- means all the settings for Receiving would be
- duplicated from Transmition related registers.
-
-Optional properties:
-
- - big-endian : If this property is absent, the native endian mode
- will be in use as default, or the big endian mode
- will be in use for all the device registers.
-
-Example:
-
-esai: esai@2024000 {
- compatible = "fsl,imx35-esai";
- reg = <0x02024000 0x4000>;
- interrupts = <0 51 0x04>;
- clocks = <&clks 208>, <&clks 118>, <&clks 208>;
- clock-names = "core", "extal", "fsys";
- dmas = <&sdma 23 21 0>, <&sdma 24 21 0>;
- dma-names = "rx", "tx";
- fsl,fifo-depth = <128>;
- fsl,esai-synchronous;
- big-endian;
-};
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.yaml b/Documentation/devicetree/bindings/sound/fsl,esai.yaml
new file mode 100644
index 000000000000..27c34ce4c2e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,esai.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Serial Audio Interface (ESAI) Controller
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port
+ for serial communication with a variety of serial devices, including industry
+ standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and
+ other DSPs. It has up to six transmitters and four receivers.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx35-esai
+ - fsl,imx6ull-esai
+ - fsl,vf610-esai
+ - items:
+ - enum:
+ - fsl,imx8qm-esai
+ - const: fsl,imx6ull-esai
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 3
+ items:
+ - description:
+ The core clock used to access registers.
+ - description:
+ The esai baud clock for esai controller used to
+ derive HCK, SCK and FS.
+ - description:
+ The system clock derived from ahb clock used to
+ derive HCK, SCK and FS.
+ - description:
+ The spba clock is required when ESAI is placed as a
+ bus slave of the Shared Peripheral Bus and when two
+ or more bus masters (CPU, DMA or DSP) try to access
+ it. This property is optional depending on the SoC
+ design.
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: core
+ - const: extal
+ - const: fsys
+ - const: spba
+
+ dmas:
+ minItems: 2
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ power-domains:
+ maxItems: 1
+
+ fsl,fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 64
+ description:
+ The number of elements in the transmit and receive
+ FIFOs. This number is the maximum allowed value for
+ TFCR[TFWM] or RFCR[RFWM].
+
+ fsl,esai-synchronous:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ This is a boolean property. If present, indicating
+ that ESAI would work in the synchronous mode, which
+ means all the settings for Receiving would be
+ duplicated from Transmission related registers.
+
+ big-endian:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ If this property is absent, the native endian mode
+ will be in use as default, or the big endian mode
+ will be in use for all the device registers.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8qm-esai
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
+examples:
+ - |
+ esai@2024000 {
+ compatible = "fsl,imx35-esai";
+ reg = <0x02024000 0x4000>;
+ interrupts = <0 51 0x04>;
+ clocks = <&clks 208>, <&clks 118>, <&clks 208>;
+ clock-names = "core", "extal", "fsys";
+ dmas = <&sdma 23 21 0>, <&sdma 24 21 0>;
+ dma-names = "rx", "tx";
+ fsl,fifo-depth = <128>;
+ fsl,esai-synchronous;
+ big-endian;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
new file mode 100644
index 000000000000..c9152bac7421
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
@@ -0,0 +1,189 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,imx-asrc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Asynchronous Sample Rate Converter (ASRC) Controller
+
+description:
+ The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of
+ a signal associated with an input clock into a signal associated with a
+ different output clock. The driver currently works as a Front End of DPCM
+ with other Back Ends Audio controller such as ESAI, SSI and SAI. It has
+ three pairs to support three substreams within totally 10 channels.
+
+maintainers:
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx35-asrc
+ - fsl,imx53-asrc
+ - fsl,imx8qm-asrc
+ - fsl,imx8qxp-asrc
+ - items:
+ - enum:
+ - fsl,imx6sx-asrc
+ - fsl,imx6ul-asrc
+ - const: fsl,imx53-asrc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 6
+
+ dma-names:
+ items:
+ - const: rxa
+ - const: rxb
+ - const: rxc
+ - const: txa
+ - const: txb
+ - const: txc
+
+ clocks:
+ maxItems: 19
+
+ clock-names:
+ items:
+ - const: mem
+ - const: ipg
+ - const: asrck_0
+ - const: asrck_1
+ - const: asrck_2
+ - const: asrck_3
+ - const: asrck_4
+ - const: asrck_5
+ - const: asrck_6
+ - const: asrck_7
+ - const: asrck_8
+ - const: asrck_9
+ - const: asrck_a
+ - const: asrck_b
+ - const: asrck_c
+ - const: asrck_d
+ - const: asrck_e
+ - const: asrck_f
+ - const: spba
+
+ power-domains:
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ fsl,asrc-rate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The mutual sample rate used by DPCM Back Ends
+
+ fsl,asrc-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The mutual sample width used by DPCM Back Ends
+ enum: [16, 24]
+
+ fsl,asrc-clk-map:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines clock map used in driver
+ <0> - select the map for asrc0 in imx8qm/imx8qxp
+ <1> - select the map for asrc1 in imx8qm/imx8qxp
+ enum: [0, 1]
+
+ big-endian:
+ type: boolean
+ description:
+ If this property is absent, the little endian mode will be in use as
+ default. Otherwise, the big endian mode will be in use for all the
+ device registers.
+
+ fsl,asrc-format:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines a mutual sample format used by DPCM Back Ends, which can
+ replace the fsl,asrc-width. The value is 2 (S16_LE), or 6 (S24_LE).
+ enum: [2, 6]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+ - clocks
+ - clock-names
+ - fsl,asrc-rate
+ - fsl,asrc-width
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-asrc
+ - fsl,imx8qxp-asrc
+ then:
+ required:
+ - fsl,asrc-clk-map
+ else:
+ properties:
+ fsl,asrc-clk-map: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-asrc
+ - fsl,imx8qxp-asrc
+ then:
+ required:
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ asrc: asrc@2034000 {
+ compatible = "fsl,imx53-asrc";
+ reg = <0x02034000 0x4000>;
+ interrupts = <0 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_ASRC_IPG>,
+ <&clks IMX6QDL_CLK_ASRC_MEM>, <&clks 0>,
+ <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>,
+ <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>,
+ <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>,
+ <&clks IMX6QDL_CLK_ASRC>, <&clks 0>, <&clks 0>,
+ <&clks IMX6QDL_CLK_SPBA>;
+ clock-names = "mem", "ipg", "asrck_0",
+ "asrck_1", "asrck_2", "asrck_3", "asrck_4",
+ "asrck_5", "asrck_6", "asrck_7", "asrck_8",
+ "asrck_9", "asrck_a", "asrck_b", "asrck_c",
+ "asrck_d", "asrck_e", "asrck_f", "spba";
+ dmas = <&sdma 17 23 1>, <&sdma 18 23 1>, <&sdma 19 23 1>,
+ <&sdma 20 23 1>, <&sdma 21 23 1>, <&sdma 22 23 1>;
+ dma-names = "rxa", "rxb", "rxc",
+ "txa", "txb", "txc";
+ fsl,asrc-rate = <48000>;
+ fsl,asrc-width = <16>;
+
+ port {
+ playback-only;
+
+ asrc_endpoint: endpoint {
+ remote-endpoint = <&fe00_ep>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-audio-es8328.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-audio-es8328.yaml
new file mode 100644
index 000000000000..5eb6f5812cf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,imx-audio-es8328.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,imx-audio-es8328.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX audio complex with ES8328 codec
+
+maintainers:
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+allOf:
+ - $ref: sound-card-common.yaml#
+
+properties:
+ compatible:
+ const: fsl,imx-audio-es8328
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: The user-visible name of this sound complex
+
+ ssi-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the i.MX SSI controller
+
+ jack-gpio:
+ description: Optional GPIO for headphone jack
+ maxItems: 1
+
+ audio-amp-supply:
+ description: Power regulator for speaker amps
+
+ audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the ES8328 audio codec
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of the connections between audio components. Each entry
+ is a pair of strings, the first being the connection's sink, the second
+ being the connection's source. Valid names could be power supplies,
+ ES8328 pins, and the jacks on the board:
+
+ Power supplies:
+ * audio-amp
+
+ ES8328 pins:
+ * LOUT1
+ * LOUT2
+ * ROUT1
+ * ROUT2
+ * LINPUT1
+ * LINPUT2
+ * RINPUT1
+ * RINPUT2
+ * Mic PGA
+
+ Board connectors:
+ * Headphone
+ * Speaker
+ * Mic Jack
+
+ mux-int-port:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The internal port of the i.MX audio muxer (AUDMUX)
+ enum: [1, 2, 7]
+ default: 1
+
+ mux-ext-port:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: The external port of the i.MX audio muxer (AUDMIX)
+ enum: [3, 4, 5, 6]
+ default: 3
+
+required:
+ - compatible
+ - model
+ - ssi-controller
+ - jack-gpio
+ - audio-amp-supply
+ - audio-codec
+ - audio-routing
+ - mux-int-port
+ - mux-ext-port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "fsl,imx-audio-es8328";
+ model = "imx-audio-es8328";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&codec>;
+ jack-gpio = <&gpio5 15 0>;
+ audio-amp-supply = <&reg_audio_amp>;
+ audio-routing =
+ "Speaker", "LOUT2",
+ "Speaker", "ROUT2",
+ "Speaker", "audio-amp",
+ "Headphone", "ROUT1",
+ "Headphone", "LOUT1",
+ "LINPUT1", "Mic Jack",
+ "RINPUT1", "Mic Jack",
+ "Mic Jack", "Mic Bias";
+ mux-int-port = <1>;
+ mux-ext-port = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml b/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml
new file mode 100644
index 000000000000..f00ae3219e15
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,imx95-cm7-sof.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP imx95 CM7 core
+
+maintainers:
+ - Daniel Baluta <daniel.baluta@nxp.com>
+
+description: NXP imx95 CM7 core used for audio processing
+
+properties:
+ compatible:
+ const: fsl,imx95-cm7-sof
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ const: sram
+
+ memory-region:
+ maxItems: 1
+
+ memory-region-names:
+ const: dma
+
+ port:
+ description: SAI3 port
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - memory-region
+ - memory-region-names
+ - port
+
+allOf:
+ - $ref: fsl,sof-cpu.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ cm7-cpu@80000000 {
+ compatible = "fsl,imx95-cm7-sof";
+ reg = <0x80000000 0x6100000>;
+ reg-names = "sram";
+ mboxes = <&mu7 2 0>, <&mu7 2 1>, <&mu7 3 0>, <&mu7 3 1>;
+ mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
+ memory-region = <&adma_res>;
+ memory-region-names = "dma";
+ port {
+ /* SAI3-WM8962 link */
+ endpoint {
+ remote-endpoint = <&wm8962_ep>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
index 64d57758ee67..c47b7a097490 100644
--- a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
@@ -15,9 +15,17 @@ description: |
properties:
compatible:
- enum:
- - fsl,imx8mm-micfil
- - fsl,imx8mp-micfil
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx95-micfil
+ - const: fsl,imx93-micfil
+
+ - enum:
+ - fsl,imx8mm-micfil
+ - fsl,imx8mp-micfil
+ - fsl,imx93-micfil
+ - fsl,imx943-micfil
reg:
maxItems: 1
@@ -55,6 +63,9 @@ properties:
- const: clkext3
minItems: 2
+ "#sound-dai-cells":
+ const: 0
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/sound/fsl,mqs.txt b/Documentation/devicetree/bindings/sound/fsl,mqs.txt
deleted file mode 100644
index d66284b8bef2..000000000000
--- a/Documentation/devicetree/bindings/sound/fsl,mqs.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-fsl,mqs audio CODEC
-
-Required properties:
- - compatible : Must contain one of "fsl,imx6sx-mqs", "fsl,codec-mqs"
- "fsl,imx8qm-mqs", "fsl,imx8qxp-mqs", "fsl,imx93-mqs".
- - clocks : A list of phandles + clock-specifiers, one for each entry in
- clock-names
- - clock-names : "mclk" - must required.
- "core" - required if compatible is "fsl,imx8qm-mqs", it
- is for register access.
- - gpr : A phandle of General Purpose Registers in IOMUX Controller.
- Required if compatible is "fsl,imx6sx-mqs".
-
-Required if compatible is "fsl,imx8qm-mqs":
- - power-domains: A phandle of PM domain provider node.
- - reg: Offset and length of the register set for the device.
-
-Example:
-
-mqs: mqs {
- compatible = "fsl,imx6sx-mqs";
- gpr = <&gpr>;
- clocks = <&clks IMX6SX_CLK_SAI1>;
- clock-names = "mclk";
- status = "disabled";
-};
-
-mqs: mqs@59850000 {
- compatible = "fsl,imx8qm-mqs";
- reg = <0x59850000 0x10000>;
- clocks = <&clk IMX8QM_AUD_MQS_IPG>,
- <&clk IMX8QM_AUD_MQS_HMCLK>;
- clock-names = "core", "mclk";
- power-domains = <&pd_mqs0>;
- status = "disabled";
-};
diff --git a/Documentation/devicetree/bindings/sound/fsl,mqs.yaml b/Documentation/devicetree/bindings/sound/fsl,mqs.yaml
new file mode 100644
index 000000000000..1415247c92c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,mqs.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,mqs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Medium Quality Sound (MQS)
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+ - Chancel Liu <chancel.liu@nxp.com>
+
+description: |
+ Medium quality sound (MQS) is used to generate medium quality audio
+ via a standard GPIO in the pinmux, allowing the user to connect
+ stereo speakers or headphones to a power amplifier without an
+ additional DAC chip.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx6sx-mqs
+ - fsl,imx8qm-mqs
+ - fsl,imx8qxp-mqs
+ - fsl,imx93-mqs
+ - fsl,imx943-aonmix-mqs
+ - fsl,imx943-wakeupmix-mqs
+ - fsl,imx95-aonmix-mqs
+ - fsl,imx95-netcmix-mqs
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ gpr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle to the General Purpose Register (GPR) node
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-mqs
+ - fsl,imx8qxp-mqs
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Master clock
+ - description: Clock for register access
+ clock-names:
+ items:
+ - const: mclk
+ - const: core
+ required:
+ - reg
+ - power-domains
+ else:
+ properties:
+ clocks:
+ items:
+ - description: Master clock
+ clock-names:
+ items:
+ - const: mclk
+ required:
+ - gpr
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6sx-clock.h>
+ mqs0: mqs {
+ compatible = "fsl,imx6sx-mqs";
+ gpr = <&gpr>;
+ clocks = <&clks IMX6SX_CLK_SAI1>;
+ clock-names = "mclk";
+ };
+
+ - |
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ mqs1: mqs@59850000 {
+ compatible = "fsl,imx8qm-mqs";
+ reg = <0x59850000 0x10000>;
+ clocks = <&mqs0_lpcg 0>, <&mqs0_lpcg 1>;
+ clock-names = "mclk", "core";
+ power-domains = <&pd IMX_SC_R_MQS_0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,mxs-audio-sgtl5000.yaml b/Documentation/devicetree/bindings/sound/fsl,mxs-audio-sgtl5000.yaml
new file mode 100644
index 000000000000..d12774b42a11
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,mxs-audio-sgtl5000.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,mxs-audio-sgtl5000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS audio complex with SGTL5000 codec
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - bluegiga,apx4devkit-sgtl5000
+ - denx,m28evk-sgtl5000
+ - fsl,imx28-evk-sgtl5000
+ - fsl,imx28-mbmx28lc-sgtl5000
+ - fsl,imx28-tx28-sgtl5000
+ - const: fsl,mxs-audio-sgtl5000
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: The user-visible name of this sound complex
+
+ saif-controllers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: The phandle list of the MXS SAIF controller
+
+ audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the SGTL5000 audio codec
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names could be power supplies, SGTL5000
+ pins, and the jacks on the board:
+
+ Power supplies:
+ * Mic Bias
+
+ SGTL5000 pins:
+ * MIC_IN
+ * LINE_IN
+ * HP_OUT
+ * LINE_OUT
+
+ Board connectors:
+ * Mic Jack
+ * Line In Jack
+ * Headphone Jack
+ * Line Out Jack
+ * Ext Spk
+
+required:
+ - compatible
+ - saif-controllers
+ - audio-codec
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "fsl,imx28-evk-sgtl5000", "fsl,mxs-audio-sgtl5000";
+ model = "imx28-evk-sgtl5000";
+ saif-controllers = <&saif0 &saif1>;
+ audio-codec = <&sgtl5000>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HP_OUT";
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
new file mode 100644
index 000000000000..a23e49198c37
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,qmc-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: QMC audio
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ The QMC audio is an ASoC component which uses QMC (QUICC Multichannel
+ Controller) channels to transfer the audio data.
+ It provides several DAIs. For each DAI, the DAI is working in interleaved mode
+ if only one QMC channel is used by the DAI or it is working in non-interleaved
+ mode if several QMC channels are used by the DAI.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: fsl,qmc-audio
+
+ '#address-cells':
+ const: 1
+ '#size-cells':
+ const: 0
+ '#sound-dai-cells':
+ const: 1
+
+patternProperties:
+ '^dai@([0-9]|[1-5][0-9]|6[0-3])$':
+ description:
+ A DAI managed by this controller
+ type: object
+ additionalProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 63
+ description:
+ The DAI number
+
+ fsl,qmc-chan:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: phandle to QMC node
+ - description: Channel number
+ minItems: 1
+ description:
+ Should be a phandle/number pair list. The list of phandle to QMC node
+ and the QMC channel pair to use for this DAI.
+ If only one phandle/number pair is provided, this DAI works in
+ interleaved mode, i.e. audio channels for this DAI are interleaved in
+ the QMC channel. If more than one pair is provided, this DAI works
+ in non-interleave mode. In that case the first audio channel uses the
+ the first QMC channel, the second audio channel uses the second QMC
+ channel, etc...
+
+ required:
+ - reg
+ - fsl,qmc-chan
+
+required:
+ - compatible
+ - '#address-cells'
+ - '#size-cells'
+ - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ audio_controller: audio-controller {
+ compatible = "fsl,qmc-audio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ dai@16 {
+ reg = <16>;
+ fsl,qmc-chan = <&qmc 16>;
+ };
+ dai@17 {
+ reg = <17>;
+ fsl,qmc-chan = <&qmc 17>;
+ };
+ dai@18 {
+ reg = <18>;
+ /* Non-interleaved mode */
+ fsl,qmc-chan = <&qmc 18>, <&qmc 19>;
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ simple-audio-card,dai-link@0 {
+ reg = <0>;
+ format = "dsp_b";
+ cpu {
+ sound-dai = <&audio_controller 16>;
+ };
+ codec {
+ sound-dai = <&codec1>;
+ dai-tdm-slot-num = <4>;
+ dai-tdm-slot-width = <8>;
+ /* TS 3, 5, 7, 9 */
+ dai-tdm-slot-tx-mask = <0 0 0 1 0 1 0 1 0 1>;
+ dai-tdm-slot-rx-mask = <0 0 0 1 0 1 0 1 0 1>;
+ };
+ };
+ simple-audio-card,dai-link@1 {
+ reg = <1>;
+ format = "dsp_b";
+ cpu {
+ sound-dai = <&audio_controller 17>;
+ };
+ codec {
+ sound-dai = <&codec2>;
+ dai-tdm-slot-num = <4>;
+ dai-tdm-slot-width = <8>;
+ /* TS 2, 4, 6, 8 */
+ dai-tdm-slot-tx-mask = <0 0 1 0 1 0 1 0 1>;
+ dai-tdm-slot-rx-mask = <0 0 1 0 1 0 1 0 1>;
+ };
+ };
+ simple-audio-card,dai-link@2 {
+ reg = <2>;
+ format = "dsp_b";
+ cpu {
+ sound-dai = <&audio_controller 18>;
+ };
+ codec {
+ sound-dai = <&codec3>;
+ dai-tdm-slot-num = <2>;
+ dai-tdm-slot-width = <8>;
+ /* TS 9, 10 */
+ dai-tdm-slot-tx-mask = <0 0 0 0 0 0 0 0 0 1 1>;
+ dai-tdm-slot-rx-mask = <0 0 0 0 0 0 0 0 0 1 1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
index d370c98a62c7..3d5d435c765b 100644
--- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
@@ -11,8 +11,14 @@ maintainers:
description: |
fsl_rpmsg is a virtual audio device. Mapping to real hardware devices
- are SAI, DMA controlled by Cortex M core. What we see from Linux
- side is a device which provides audio service by rpmsg channel.
+ are SAI, MICFIL, DMA controlled by Cortex M core. What we see from
+ Linux side is a device which provides audio service by rpmsg channel.
+ We can create different sound cards which access different hardwares
+ such as SAI, MICFIL, .etc through building rpmsg channels between
+ Cortex-A and Cortex-M.
+
+allOf:
+ - $ref: sound-card-common.yaml#
properties:
compatible:
@@ -22,10 +28,8 @@ properties:
- fsl,imx8mm-rpmsg-audio
- fsl,imx8mp-rpmsg-audio
- fsl,imx8ulp-rpmsg-audio
-
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
+ - fsl,imx93-rpmsg-audio
+ - fsl,imx95-rpmsg-audio
clocks:
items:
@@ -62,13 +66,6 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description: The phandle to a node of audio codec
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- description: |
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source.
-
fsl,enable-lpa:
$ref: /schemas/types.yaml#/definitions/flag
description: enable low power audio path.
@@ -85,11 +82,20 @@ properties:
This is a boolean property. If present, the receiving function
will be enabled.
+ fsl,rpmsg-channel-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ A string property to assign rpmsg channel this sound card sits on.
+ This property can be omitted if there is only one sound card and it sits
+ on "rpmsg-audio-channel".
+ enum:
+ - rpmsg-audio-channel
+ - rpmsg-micfil-channel
+
required:
- compatible
- - model
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -107,3 +113,22 @@ examples:
<&clk IMX8MN_AUDIO_PLL2_OUT>;
clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k";
};
+
+ - |
+ #include <dt-bindings/clock/imx8mm-clock.h>
+
+ rpmsg_micfil: audio-controller {
+ compatible = "fsl,imx8mm-rpmsg-audio";
+ model = "micfil-audio";
+ fsl,rpmsg-channel-name = "rpmsg-micfil-channel";
+ fsl,enable-lpa;
+ fsl,rpmsg-in;
+ clocks = <&clk IMX8MM_CLK_PDM_IPG>,
+ <&clk IMX8MM_CLK_PDM_ROOT>,
+ <&clk IMX8MM_CLK_SDMA3_ROOT>,
+ <&clk IMX8MM_AUDIO_PLL1_OUT>,
+ <&clk IMX8MM_AUDIO_PLL2_OUT>;
+ clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml
index 70c4111d59c7..0d733e5b08a4 100644
--- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml
@@ -18,14 +18,12 @@ description: |
properties:
compatible:
oneOf:
- - enum:
- - fsl,vf610-sai
- - fsl,imx6sx-sai
- - fsl,imx6ul-sai
- - fsl,imx7ulp-sai
- - fsl,imx8mq-sai
- - fsl,imx8qm-sai
- - fsl,imx8ulp-sai
+ - items:
+ - enum:
+ - fsl,imx6ul-sai
+ - fsl,imx7d-sai
+ - const: fsl,imx6sx-sai
+
- items:
- enum:
- fsl,imx8mm-sai
@@ -33,19 +31,24 @@ properties:
- fsl,imx8mp-sai
- const: fsl,imx8mq-sai
+ - items:
+ - enum:
+ - fsl,imx6sx-sai
+ - fsl,imx7ulp-sai
+ - fsl,imx8mq-sai
+ - fsl,imx8qm-sai
+ - fsl,imx8ulp-sai
+ - fsl,imx93-sai
+ - fsl,imx95-sai
+ - fsl,vf610-sai
+ - items:
+ - enum:
+ - fsl,imx94-sai
+ - const: fsl,imx95-sai
+
reg:
maxItems: 1
- interrupts:
- items:
- - description: receive and transmit interrupt
-
- dmas:
- maxItems: 2
-
- dma-names:
- maxItems: 2
-
clocks:
items:
- description: The ipg clock for register access
@@ -67,7 +70,7 @@ properties:
- const: mclk3
- const: pll8k
- const: pll11k
- minItems: 4
+ minItems: 5
- items:
- const: bus
- const: mclk1
@@ -77,19 +80,62 @@ properties:
- const: pll11k
minItems: 4
- lsb-first:
- description: |
- Configures whether the LSB or the MSB is transmitted
- first for the fifo data. If this property is absent,
- the MSB is transmitted first as default, or the LSB
- is transmitted first.
- type: boolean
+ power-domains:
+ maxItems: 1
+
+ dmas:
+ minItems: 1
+ maxItems: 2
+
+ dma-names:
+ minItems: 1
+ items:
+ - enum: [ rx, tx ]
+ - const: tx
+
+ interrupts:
+ items:
+ - description: receive and transmit interrupt
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+ description: port for TX and RX
+
+ port@1:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+ description: port for TX only
+
+ port@2:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+ description: port for RX only
big-endian:
description: |
required if all the SAI registers are big-endian rather than little-endian.
type: boolean
+ fsl,dataline:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ Configure the dataline. It has 3 value for each configuration
+ maxItems: 16
+ items:
+ items:
+ - description: format Default(0), I2S(1) or PDM(2)
+ enum: [0, 1, 2]
+ - description: dataline mask for 'rx'
+ - description: dataline mask for 'tx'
+
+ fsl,sai-mclk-direction-output:
+ description: SAI will output the SAI MCLK clock.
+ type: boolean
+
fsl,sai-synchronous-rx:
description: |
SAI will work in the synchronous mode (sync Tx with Rx) which means
@@ -108,56 +154,24 @@ properties:
of transmitter.
type: boolean
- fsl,dataline:
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- description: |
- Configure the dataline. It has 3 value for each configuration
- maxItems: 16
- items:
- items:
- - description: format Default(0), I2S(1) or PDM(2)
- enum: [0, 1, 2]
- - description: dataline mask for 'rx'
- - description: dataline mask for 'tx'
-
- fsl,sai-mclk-direction-output:
- description: SAI will output the SAI MCLK clock.
- type: boolean
-
fsl,shared-interrupt:
description: Interrupt is shared with other modules.
type: boolean
+ lsb-first:
+ description: |
+ Configures whether the LSB or the MSB is transmitted
+ first for the fifo data. If this property is absent,
+ the MSB is transmitted first as default, or the LSB
+ is transmitted first.
+ type: boolean
+
"#sound-dai-cells":
const: 0
description: optional, some dts node didn't add it.
allOf:
- - if:
- properties:
- compatible:
- contains:
- const: fsl,vf610-sai
- then:
- properties:
- dmas:
- items:
- - description: DMA controller phandle and request line for TX
- - description: DMA controller phandle and request line for RX
- dma-names:
- items:
- - const: tx
- - const: rx
- else:
- properties:
- dmas:
- items:
- - description: DMA controller phandle and request line for RX
- - description: DMA controller phandle and request line for TX
- dma-names:
- items:
- - const: rx
- - const: tx
+ - $ref: dai-common.yaml#
- if:
required:
- fsl,sai-asynchronous
@@ -168,13 +182,13 @@ allOf:
required:
- compatible
- reg
- - interrupts
- - dmas
- - dma-names
- clocks
- clock-names
+ - dmas
+ - dma-names
+ - interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -190,9 +204,8 @@ examples:
<&clks VF610_CLK_SAI2>,
<&clks 0>, <&clks 0>;
clock-names = "bus", "mclk1", "mclk2", "mclk3";
- dma-names = "tx", "rx";
- dmas = <&edma0 0 21>,
- <&edma0 0 20>;
+ dma-names = "rx", "tx";
+ dmas = <&edma0 0 20>, <&edma0 0 21>;
big-endian;
lsb-first;
};
@@ -213,4 +226,37 @@ examples:
dma-names = "rx", "tx";
fsl,dataline = <1 0xff 0xff 2 0xff 0x11>;
#sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ playback-only;
+
+ sai1_endpoint0: endpoint {
+ dai-tdm-slot-num = <8>;
+ dai-tdm-slot-width = <32>;
+ dai-tdm-slot-width-map = <32 8 32>;
+ dai-format = "dsp_a";
+ bitclock-master;
+ frame-master;
+ remote-endpoint = <&mcodec01_ep>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ capture-only;
+
+ sai1_endpoint1: endpoint {
+ dai-tdm-slot-num = <8>;
+ dai-tdm-slot-width = <32>;
+ dai-tdm-slot-width-map = <32 8 32>;
+ dai-format = "dsp_a";
+ remote-endpoint = <&fe02_ep>;
+ };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/sound/fsl,saif.yaml b/Documentation/devicetree/bindings/sound/fsl,saif.yaml
new file mode 100644
index 000000000000..0b5db6bb1b7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,saif.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,saif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS Serial Audio Interface (SAIF)
+
+maintainers:
+ - Lukasz Majewski <lukma@denx.de>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+description:
+ The SAIF is based on I2S module that is used to communicate with audio codecs,
+ but only with half-duplex manner (i.e. it can either transmit or receive PCM
+ audio).
+
+properties:
+ compatible:
+ const: fsl,imx28-saif
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+ "#clock-cells":
+ description: Configure the I2S device as MCLK clock provider.
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ fsl,saif-master:
+ description: Indicate that saif is a slave and its phandle points to master
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - interrupts
+ - dmas
+ - dma-names
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ saif0: saif@80042000 {
+ compatible = "fsl,imx28-saif";
+ reg = <0x80042000 2000>;
+ #sound-dai-cells = <0>;
+ interrupts = <59>;
+ dmas = <&dma_apbx 4>;
+ dma-names = "rx-tx";
+ #clock-cells = <0>;
+ clocks = <&clks 53>;
+ };
+ - |
+ saif1: saif@80046000 {
+ compatible = "fsl,imx28-saif";
+ reg = <0x80046000 2000>;
+ #sound-dai-cells = <0>;
+ interrupts = <58>;
+ dmas = <&dma_apbx 5>;
+ dma-names = "rx-tx";
+ clocks = <&clks 53>;
+ fsl,saif-master = <&saif0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml b/Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml
new file mode 100644
index 000000000000..c6ab1ca16763
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,sgtl5000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale SGTL5000 Stereo Codec
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: fsl,sgtl5000
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ assigned-clock-parents: true
+ assigned-clock-rates: true
+ assigned-clocks: true
+
+ clocks:
+ items:
+ - description: the clock provider of SYS_MCLK
+
+ VDDA-supply:
+ description: the regulator provider of VDDA
+
+ VDDIO-supply:
+ description: the regulator provider of VDDIO
+
+ VDDD-supply:
+ description: the regulator provider of VDDD
+
+ micbias-resistor-k-ohms:
+ description: The bias resistor to be used in kOhms. The resistor can take
+ values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not
+ mentioned or if the value is unknown, then micbias resistor is set to
+ 4k.
+ enum: [ 0, 2, 4, 8 ]
+
+ micbias-voltage-m-volts:
+ description: The bias voltage to be used in mVolts. The voltage can take
+ values from 1.25V to 3V by 250mV steps. If this node is not mentioned
+ or the value is unknown, then the value is set to 1.25V.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ]
+
+ lrclk-strength:
+ description: |
+ The LRCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
+ table below:
+
+ VDDIO 1.8V 2.5V 3.3V
+ 0 = Disable
+ 1 = 1.66 mA 2.87 mA 4.02 mA
+ 2 = 3.33 mA 5.74 mA 8.03 mA
+ 3 = 4.99 mA 8.61 mA 12.05 mA
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ sclk-strength:
+ description: |
+ The SCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
+ table below:
+
+ VDDIO 1.8V 2.5V 3.3V
+ 0 = Disable
+ 1 = 1.66 mA 2.87 mA 4.02 mA
+ 2 = 3.33 mA 5.74 mA 8.03 mA
+ 3 = 4.99 mA 8.61 mA 12.05 mA
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - VDDA-supply
+ - VDDIO-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 150>;
+ micbias-resistor-k-ohms = <2>;
+ micbias-voltage-m-volts = <2250>;
+ VDDA-supply = <&reg_3p3v>;
+ VDDIO-supply = <&reg_3p3v>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml b/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml
new file mode 100644
index 000000000000..31863932dbc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,sof-cpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP audio processor common properties
+
+maintainers:
+ - Daniel Baluta <daniel.baluta@nxp.com>
+
+properties:
+ mboxes:
+ maxItems: 4
+
+ mbox-names:
+ items:
+ - const: txdb0
+ - const: txdb1
+ - const: rxdb0
+ - const: rxdb1
+
+required:
+ - mboxes
+ - mbox-names
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
index 1d64e8337aa4..5654e9f61aba 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
@@ -16,22 +16,32 @@ description: |
properties:
compatible:
- enum:
- - fsl,imx35-spdif
- - fsl,vf610-spdif
- - fsl,imx6sx-spdif
- - fsl,imx8qm-spdif
- - fsl,imx8qxp-spdif
- - fsl,imx8mq-spdif
- - fsl,imx8mm-spdif
- - fsl,imx8mn-spdif
- - fsl,imx8ulp-spdif
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx35-spdif
+ - fsl,imx6sx-spdif
+ - fsl,imx8mm-spdif
+ - fsl,imx8mn-spdif
+ - fsl,imx8mq-spdif
+ - fsl,imx8qm-spdif
+ - fsl,imx8qxp-spdif
+ - fsl,imx8ulp-spdif
+ - fsl,vf610-spdif
+ - items:
+ - enum:
+ - fsl,imx6sl-spdif
+ - fsl,imx6sx-spdif
+ - const: fsl,imx35-spdif
reg:
maxItems: 1
interrupts:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Combined or receive interrupt
+ - description: Transmit interrupt
dmas:
items:
@@ -86,6 +96,9 @@ properties:
registers. Set this flag for HCDs with big endian descriptors and big
endian registers.
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -97,6 +110,33 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8qm-spdif
+ - fsl,imx8qxp-spdif
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-spdif
+ - fsl,imx8qxp-spdif
+ then:
+ required:
+ - power-domains
+
examples:
- |
spdif@2004000 {
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
deleted file mode 100644
index 7e15a85cecd2..000000000000
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Freescale Synchronous Serial Interface
-
-The SSI is a serial device that communicates with audio codecs. It can
-be programmed in AC97, I2S, left-justified, or right-justified modes.
-
-Required properties:
-- compatible: Compatible list, should contain one of the following
- compatibles:
- fsl,mpc8610-ssi
- fsl,imx51-ssi
- fsl,imx35-ssi
- fsl,imx21-ssi
-- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on.
-- reg: Offset and length of the register set for the device.
-- interrupts: <a b> where a is the interrupt number and b is a
- field that represents an encoding of the sense and
- level information for the interrupt. This should be
- encoded based on the information in section 2)
- depending on the type of interrupt controller you
- have.
-- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs.
- This number is the maximum allowed value for SFCSR[TFWM0].
- - clocks: "ipg" - Required clock for the SSI unit
- "baud" - Required clock for SSI master mode. Otherwise this
- clock is not used
-
-Required are also ac97 link bindings if ac97 is used. See
-Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary
-bindings.
-
-Optional properties:
-- codec-handle: Phandle to a 'codec' node that defines an audio
- codec connected to this SSI. This node is typically
- a child of an I2C or other control node.
-- fsl,fiq-stream-filter: Bool property. Disabled DMA and use FIQ instead to
- filter the codec stream. This is necessary for some boards
- where an incompatible codec is connected to this SSI, e.g.
- on pca100 and pcm043.
-- dmas: Generic dma devicetree binding as described in
- Documentation/devicetree/bindings/dma/dma.txt.
-- dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
- is not defined.
-- fsl,mode: The operating mode for the AC97 interface only.
- "ac97-slave" - AC97 mode, SSI is clock slave
- "ac97-master" - AC97 mode, SSI is clock master
-- fsl,ssi-asynchronous:
- If specified, the SSI is to be programmed in asynchronous
- mode. In this mode, pins SRCK, STCK, SRFS, and STFS must
- all be connected to valid signals. In synchronous mode,
- SRCK and SRFS are ignored. Asynchronous mode allows
- playback and capture to use different sample sizes and
- sample rates. Some drivers may require that SRCK and STCK
- be connected together, and SRFS and STFS be connected
- together. This would still allow different sample sizes,
- but not different sample rates.
-- fsl,playback-dma: Phandle to a node for the DMA channel to use for
- playback of audio. This is typically dictated by SOC
- design. See the notes below.
- Only used on Power Architecture.
-- fsl,capture-dma: Phandle to a node for the DMA channel to use for
- capture (recording) of audio. This is typically dictated
- by SOC design. See the notes below.
- Only used on Power Architecture.
-
-Child 'codec' node required properties:
-- compatible: Compatible list, contains the name of the codec
-
-Child 'codec' node optional properties:
-- clock-frequency: The frequency of the input clock, which typically comes
- from an on-board dedicated oscillator.
-
-Notes on fsl,playback-dma and fsl,capture-dma:
-
-On SOCs that have an SSI, specific DMA channels are hard-wired for playback
-and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for
-playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for
-playback and DMA channel 3 for capture. The developer can choose which
-DMA controller to use, but the channels themselves are hard-wired. The
-purpose of these two properties is to represent this hardware design.
-
-The device tree nodes for the DMA channels that are referenced by
-"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
-"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g.
-"fsl,mpc8610-dma-channel") can remain. If these nodes are left as
-"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
-drivers (fsldma) will attempt to use them, and it will conflict with the
-sound drivers.
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.yaml b/Documentation/devicetree/bindings/sound/fsl,ssi.yaml
new file mode 100644
index 000000000000..4ab10cd3b520
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.yaml
@@ -0,0 +1,194 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,ssi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Synchronous Serial Interface
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+description:
+ Notes on fsl,playback-dma and fsl,capture-dma
+ On SOCs that have an SSI, specific DMA channels are hard-wired for playback
+ and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for
+ playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for
+ playback and DMA channel 3 for capture. The developer can choose which
+ DMA controller to use, but the channels themselves are hard-wired. The
+ purpose of these two properties is to represent this hardware design.
+
+ The device tree nodes for the DMA channels that are referenced by
+ "fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
+ "fsl,ssi-dma-channel". The SOC-specific compatible string (e.g.
+ "fsl,mpc8610-dma-channel") can remain. If these nodes are left as
+ "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
+ drivers (fsldma) will attempt to use them, and it will conflict with the
+ sound drivers.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx50-ssi
+ - fsl,imx53-ssi
+ - const: fsl,imx51-ssi
+ - const: fsl,imx21-ssi
+ - items:
+ - enum:
+ - fsl,imx25-ssi
+ - fsl,imx27-ssi
+ - fsl,imx35-ssi
+ - fsl,imx51-ssi
+ - const: fsl,imx21-ssi
+ - items:
+ - enum:
+ - fsl,imx6q-ssi
+ - fsl,imx6sl-ssi
+ - fsl,imx6sx-ssi
+ - const: fsl,imx51-ssi
+ - items:
+ - const: fsl,imx21-ssi
+ - items:
+ - const: fsl,mpc8610-ssi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The ipg clock for register access
+ - description: clock for SSI master mode
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: baud
+ minItems: 1
+
+ dmas:
+ oneOf:
+ - items:
+ - description: DMA controller phandle and request line for RX
+ - description: DMA controller phandle and request line for TX
+ - items:
+ - description: DMA controller phandle and request line for RX0
+ - description: DMA controller phandle and request line for TX0
+ - description: DMA controller phandle and request line for RX1
+ - description: DMA controller phandle and request line for TX1
+
+ dma-names:
+ oneOf:
+ - items:
+ - const: rx
+ - const: tx
+ - items:
+ - const: rx0
+ - const: tx0
+ - const: rx1
+ - const: tx1
+
+ "#sound-dai-cells":
+ const: 0
+ description: optional, some dts node didn't add it.
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+ description: The SSI index
+
+ ac97-gpios:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Please refer to soc-ac97link.txt
+
+ codec-handle:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to a 'codec' node that defines an audio
+ codec connected to this SSI. This node is typically
+ a child of an I2C or other control node.
+
+ fsl,fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The number of elements in the transmit and receive FIFOs.
+ This number is the maximum allowed value for SFCSR[TFWM0].
+ enum: [8, 15]
+
+ fsl,fiq-stream-filter:
+ type: boolean
+ description:
+ Disabled DMA and use FIQ instead to filter the codec stream.
+ This is necessary for some boards where an incompatible codec
+ is connected to this SSI, e.g. on pca100 and pcm043.
+
+ fsl,mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ ac97-slave, ac97-master, i2s-slave, i2s-master,
+ lj-slave, lj-master, rj-slave, rj-master ]
+ description: |
+ "ac97-slave" - AC97 mode, SSI is clock slave
+ "ac97-master" - AC97 mode, SSI is clock master
+ "i2s-slave" - I2S mode, SSI is clock slave
+ "i2s-master" - I2S mode, SSI is clock master
+ "lj-slave" - Left justified mode, SSI is clock slave
+ "lj-master" - Left justified mode, SSI is clock master
+ "rj-slave" - Right justified mode, SSI is clock slave
+ "rj-master" - Right justified mode, SSI is clock master
+
+ fsl,ssi-asynchronous:
+ type: boolean
+ description: If specified, the SSI is to be programmed in asynchronous
+ mode. In this mode, pins SRCK, STCK, SRFS, and STFS must
+ all be connected to valid signals. In synchronous mode,
+ SRCK and SRFS are ignored. Asynchronous mode allows
+ playback and capture to use different sample sizes and
+ sample rates. Some drivers may require that SRCK and STCK
+ be connected together, and SRFS and STFS be connected
+ together. This would still allow different sample sizes,
+ but not different sample rates.
+
+ fsl,playback-dma:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to a node for the DMA channel to use for
+ playback of audio. This is typically dictated by SOC
+ design. Only used on Power Architecture.
+
+ fsl,capture-dma:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to a node for the DMA channel to use for
+ capture (recording) of audio. This is typically dictated
+ by SOC design. Only used on Power Architecture.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,fifo-depth
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ ssi@2028000 {
+ compatible = "fsl,imx6q-ssi", "fsl,imx51-ssi";
+ reg = <0x02028000 0x4000>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_SSI1_IPG>,
+ <&clks IMX6QDL_CLK_SSI1>;
+ clock-names = "ipg", "baud";
+ dmas = <&sdma 37 1 0>, <&sdma 38 1 0>;
+ dma-names = "rx", "tx";
+ #sound-dai-cells = <0>;
+ fsl,fifo-depth = <15>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
index 223b8ea693dc..f68d0e0ecfe5 100644
--- a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
@@ -21,6 +21,8 @@ properties:
compatible:
enum:
- fsl,imx8mp-xcvr
+ - fsl,imx93-xcvr
+ - fsl,imx95-xcvr
reg:
items:
@@ -37,7 +39,11 @@ properties:
- const: txfifo
interrupts:
- maxItems: 1
+ items:
+ - description: WAKEUPMIX Audio XCVR Interrupt 1
+ - description: WAKEUPMIX Audio XCVR Interrupt 2
+ - description: SPDIF wakeup interrupt from PHY
+ minItems: 1
clocks:
items:
@@ -45,6 +51,9 @@ properties:
- description: PHY clock
- description: SPBA clock
- description: PLL clock
+ - description: PLL clock source for 8kHz series
+ - description: PLL clock source for 11kHz series
+ minItems: 4
clock-names:
items:
@@ -52,6 +61,9 @@ properties:
- const: phy
- const: spba
- const: pll_ipg
+ - const: pll8k
+ - const: pll11k
+ minItems: 4
dmas:
items:
@@ -75,9 +87,51 @@ required:
- clock-names
- dmas
- dma-names
- - resets
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx8mp-xcvr
+ then:
+ required:
+ - resets
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx93-xcvr
+ - fsl,imx95-xcvr
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ maxItems: 2
+ else:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mp-xcvr
+ - fsl,imx93-xcvr
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ maxItems: 4
+
+unevaluatedProperties: false
examples:
- |
@@ -86,19 +140,21 @@ examples:
#include <dt-bindings/reset/imx8mp-reset.h>
xcvr: xcvr@30cc0000 {
- compatible = "fsl,imx8mp-xcvr";
- reg = <0x30cc0000 0x800>,
- <0x30cc0800 0x400>,
- <0x30cc0c00 0x080>,
- <0x30cc0e00 0x080>;
- reg-names = "ram", "regs", "rxfifo", "txfifo";
- interrupts = <0x0 128 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>,
- <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>,
- <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>,
- <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;
- clock-names = "ipg", "phy", "spba", "pll_ipg";
- dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>;
- dma-names = "rx", "tx";
- resets = <&audiomix_reset 0>;
+ compatible = "fsl,imx8mp-xcvr";
+ reg = <0x30cc0000 0x800>,
+ <0x30cc0800 0x400>,
+ <0x30cc0c00 0x080>,
+ <0x30cc0e00 0x080>;
+ reg-names = "ram", "regs", "rxfifo", "txfifo";
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>,
+ <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>,
+ <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>,
+ <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;
+ clock-names = "ipg", "phy", "spba", "pll_ipg";
+ dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>;
+ dma-names = "rx", "tx";
+ resets = <&audiomix_reset 0>;
};
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
deleted file mode 100644
index 8b4f4015cfe4..000000000000
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-Freescale Generic ASoC Sound Card with ASRC support
-
-The Freescale Generic ASoC Sound Card can be used, ideally, for all Freescale
-SoCs connecting with external CODECs.
-
-The idea of this generic sound card is a bit like ASoC Simple Card. However,
-for Freescale SoCs (especially those released in recent years), most of them
-have ASRC (Documentation/devicetree/bindings/sound/fsl,asrc.txt) inside. And
-this is a specific feature that might be painstakingly controlled and merged
-into the Simple Card.
-
-So having this generic sound card allows all Freescale SoC users to benefit
-from the simplification of a new card support and the capability of the wide
-sample rates support through ASRC.
-
-Note: The card is initially designed for those sound cards who use AC'97, I2S
- and PCM DAI formats. However, it'll be also possible to support those non
- AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as
- long as the driver has been properly upgraded.
-
-
-The compatible list for this generic sound card currently:
- "fsl,imx-audio-ac97"
-
- "fsl,imx-audio-cs42888"
-
- "fsl,imx-audio-cs427x"
- (compatible with CS4271 and CS4272)
-
- "fsl,imx-audio-wm8962"
-
- "fsl,imx-audio-sgtl5000"
- (compatible with Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt)
-
- "fsl,imx-audio-wm8960"
-
- "fsl,imx-audio-mqs"
-
- "fsl,imx-audio-wm8524"
-
- "fsl,imx-audio-tlv320aic32x4"
-
- "fsl,imx-audio-tlv320aic31xx"
-
- "fsl,imx-audio-si476x"
-
- "fsl,imx-audio-wm8958"
-
-Required properties:
-
- - compatible : Contains one of entries in the compatible list.
-
- - model : The user-visible name of this sound complex
-
- - audio-cpu : The phandle of an CPU DAI controller
-
- - audio-codec : The phandle of an audio codec
-
-Optional properties:
-
- - audio-asrc : The phandle of ASRC. It can be absent if there's no
- need to add ASRC support via DPCM.
-
- - audio-routing : A list of the connections between audio components.
- Each entry is a pair of strings, the first being the
- connection's sink, the second being the connection's
- source. There're a few pre-designed board connectors:
- * Line Out Jack
- * Line In Jack
- * Headphone Jack
- * Mic Jack
- * Ext Spk
- * AMIC (stands for Analog Microphone Jack)
- * DMIC (stands for Digital Microphone Jack)
-
- Note: The "Mic Jack" and "AMIC" are redundant while
- coexisting in order to support the old bindings
- of wm8962 and sgtl5000.
-
- - hp-det-gpio : The GPIO that detect headphones are plugged in
- - mic-det-gpio : The GPIO that detect microphones are plugged in
- - bitclock-master : Indicates dai-link bit clock master; for details see simple-card.yaml.
- - frame-master : Indicates dai-link frame master; for details see simple-card.yaml.
- - dai-format : audio format, for details see simple-card.yaml.
- - frame-inversion : dai-link uses frame clock inversion, for details see simple-card.yaml.
- - bitclock-inversion : dai-link uses bit clock inversion, for details see simple-card.yaml.
- - mclk-id : main clock id, specific for each card configuration.
-
-Optional unless SSI is selected as a CPU DAI:
-
- - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
-
- - mux-ext-port : The external port of the i.MX audio muxer
-
-Example:
-sound-cs42888 {
- compatible = "fsl,imx-audio-cs42888";
- model = "cs42888-audio";
- audio-cpu = <&esai>;
- audio-asrc = <&asrc>;
- audio-codec = <&cs42888>;
- audio-routing =
- "Line Out Jack", "AOUT1L",
- "Line Out Jack", "AOUT1R",
- "Line Out Jack", "AOUT2L",
- "Line Out Jack", "AOUT2R",
- "Line Out Jack", "AOUT3L",
- "Line Out Jack", "AOUT3R",
- "Line Out Jack", "AOUT4L",
- "Line Out Jack", "AOUT4R",
- "AIN1L", "Line In Jack",
- "AIN1R", "Line In Jack",
- "AIN2L", "Line In Jack",
- "AIN2R", "Line In Jack";
-};
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml
new file mode 100644
index 000000000000..88eb20bb008f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.yaml
@@ -0,0 +1,243 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl-asoc-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Generic ASoC Sound Card with ASRC support
+
+description:
+ The Freescale Generic ASoC Sound Card can be used, ideally,
+ for all Freescale SoCs connecting with external CODECs.
+
+ The idea of this generic sound card is a bit like ASoC Simple Card.
+ However, for Freescale SoCs (especially those released in recent years),
+ most of them have ASRC inside. And this is a specific feature that might
+ be painstakingly controlled and merged into the Simple Card.
+
+ So having this generic sound card allows all Freescale SoC users to
+ benefit from the simplification of a new card support and the capability
+ of the wide sample rates support through ASRC.
+
+ Note, The card is initially designed for those sound cards who use AC'97, I2S
+ and PCM DAI formats. However, it'll be also possible to support those non
+ AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as
+ long as the driver has been properly upgraded.
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx-sgtl5000
+ - fsl,imx25-pdk-sgtl5000
+ - fsl,imx53-cpuvo-sgtl5000
+ - fsl,imx51-babbage-sgtl5000
+ - fsl,imx53-m53evk-sgtl5000
+ - fsl,imx53-qsb-sgtl5000
+ - fsl,imx53-voipac-sgtl5000
+ - fsl,imx6-armadeus-sgtl5000
+ - fsl,imx6-rex-sgtl5000
+ - fsl,imx6-sabreauto-cs42888
+ - fsl,imx6-wandboard-sgtl5000
+ - fsl,imx6dl-nit6xlite-sgtl5000
+ - fsl,imx6q-ba16-sgtl5000
+ - fsl,imx6q-nitrogen6_max-sgtl5000
+ - fsl,imx6q-nitrogen6_som2-sgtl5000
+ - fsl,imx6q-nitrogen6x-sgtl5000
+ - fsl,imx6q-sabrelite-sgtl5000
+ - fsl,imx6q-sabresd-wm8962
+ - fsl,imx6q-udoo-ac97
+ - fsl,imx6q-ventana-sgtl5000
+ - fsl,imx6sl-evk-wm8962
+ - fsl,imx6sx-sdb-mqs
+ - fsl,imx6sx-sdb-wm8962
+ - fsl,imx7d-evk-wm8960
+ - karo,tx53-audio-sgtl5000
+ - tq,imx53-mba53-sgtl5000
+ - enum:
+ - fsl,imx-audio-ac97
+ - fsl,imx-audio-cs42888
+ - fsl,imx-audio-mqs
+ - fsl,imx-audio-sgtl5000
+ - fsl,imx-audio-wm8960
+ - fsl,imx-audio-wm8962
+ - items:
+ - enum:
+ - fsl,imx-sabreauto-spdif
+ - fsl,imx6sx-sdb-spdif
+ - const: fsl,imx-audio-spdif
+ - items:
+ - enum:
+ - fsl,imx-audio-ac97
+ - fsl,imx-audio-cs42888
+ - fsl,imx-audio-cs427x
+ - fsl,imx-audio-mqs
+ - fsl,imx-audio-nau8822
+ - fsl,imx-audio-sgtl5000
+ - fsl,imx-audio-si476x
+ - fsl,imx-audio-tlv320
+ - fsl,imx-audio-tlv320aic31xx
+ - fsl,imx-audio-tlv320aic32x4
+ - fsl,imx-audio-wm8524
+ - fsl,imx-audio-wm8904
+ - fsl,imx-audio-wm8960
+ - fsl,imx-audio-wm8962
+ - fsl,imx-audio-wm8958
+ - fsl,imx-audio-spdif
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: The user-visible name of this sound complex
+
+ audio-asrc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle of ASRC. It can be absent if there's no
+ need to add ASRC support via DPCM.
+
+ audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ The phandle of an audio codec.
+ With "fsl,imx-audio-spdif", either SPDIF audio codec spdif_transmitter,
+ spdif_receiver or both.
+ minItems: 1
+ maxItems: 2
+ items:
+ maxItems: 1
+
+ audio-cpu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of an CPU DAI controller
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source. There're a few pre-designed board
+ connectors. "AMIC" stands for Analog Microphone Jack.
+ "DMIC" stands for Digital Microphone Jack. The "Mic Jack" and "AMIC"
+ are redundant while coexisting in order to support the old bindings
+ of wm8962 and sgtl5000.
+
+ hp-det-gpio:
+ deprecated: true
+ maxItems: 1
+ description: The GPIO that detect headphones are plugged in
+
+ hp-det-gpios:
+ maxItems: 1
+ description: The GPIO that detect headphones are plugged in
+
+ mic-det-gpio:
+ deprecated: true
+ maxItems: 1
+ description: The GPIO that detect microphones are plugged in
+
+ mic-det-gpios:
+ maxItems: 1
+ description: The GPIO that detect microphones are plugged in
+
+ bitclock-master:
+ $ref: simple-card.yaml#/definitions/bitclock-master
+ description: Indicates dai-link bit clock master.
+
+ frame-master:
+ $ref: simple-card.yaml#/definitions/frame-master
+ description: Indicates dai-link frame master.
+
+ format:
+ $ref: simple-card.yaml#/definitions/format
+ description: audio format.
+
+ frame-inversion:
+ $ref: simple-card.yaml#/definitions/frame-inversion
+ description: dai-link uses frame clock inversion.
+
+ bitclock-inversion:
+ $ref: simple-card.yaml#/definitions/bitclock-inversion
+ description: dai-link uses bit clock inversion.
+
+ mclk-id:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Main clock id for each codec, specific for each card configuration.
+ minItems: 1
+ maxItems: 2
+
+ mux-int-port:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 7]
+ description: The internal port of the i.MX audio muxer (AUDMUX)
+
+ mux-ext-port:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [3, 4, 5, 6]
+ description: The external port of the i.MX audio muxer
+
+ ssi-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of an CPU DAI controller
+
+ spdif-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
+ description: The phandle of an S/PDIF CPU DAI controller.
+
+ spdif-out:
+ type: boolean
+ deprecated: true
+ description: |
+ If present, the transmitting function of S/PDIF will be enabled,
+ indicating there's a physical S/PDIF out connector or jack on the
+ board or it's connecting to some other IP block, such as an HDMI
+ encoder or display-controller.
+
+ spdif-in:
+ type: boolean
+ deprecated: true
+ description: |
+ If present, the receiving function of S/PDIF will be enabled,
+ indicating there is a physical S/PDIF in connector/jack on the board.
+
+required:
+ - compatible
+ - model
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound-cs42888 {
+ compatible = "fsl,imx-audio-cs42888";
+ model = "cs42888-audio";
+ audio-cpu = <&esai>;
+ audio-asrc = <&asrc>;
+ audio-codec = <&cs42888>;
+ audio-routing =
+ "Line Out Jack", "AOUT1L",
+ "Line Out Jack", "AOUT1R",
+ "Line Out Jack", "AOUT2L",
+ "Line Out Jack", "AOUT2R",
+ "Line Out Jack", "AOUT3L",
+ "Line Out Jack", "AOUT3R",
+ "Line Out Jack", "AOUT4L",
+ "Line Out Jack", "AOUT4R",
+ "AIN1L", "Line In Jack",
+ "AIN1R", "Line In Jack",
+ "AIN2L", "Line In Jack",
+ "AIN2R", "Line In Jack";
+ };
+
+ - |
+ sound-spdif-asrc {
+ compatible = "fsl,imx-audio-spdif";
+ model = "spdif-asrc-audio";
+ audio-cpu = <&spdif>;
+ audio-asrc = <&easrc>;
+ audio-codec = <&spdifdit>, <&spdifdir>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml b/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml
new file mode 100644
index 000000000000..5329dc140b1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/google,chv3-codec.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/google,chv3-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Chameleon v3 audio codec
+
+maintainers:
+ - Paweł Anikiel <pan@semihalf.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: google,chv3-codec
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ audio-codec {
+ compatible = "google,chv3-codec";
+ };
diff --git a/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml b/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml
new file mode 100644
index 000000000000..3ce910f44d39
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/google,chv3-i2s.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/google,chv3-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Chameleon v3 I2S device
+
+maintainers:
+ - Paweł Anikiel <pan@semihalf.com>
+
+description: |
+ I2S device for the Google Chameleon v3. The device handles both RX
+ and TX using a producer/consumer ring buffer design.
+
+properties:
+ compatible:
+ const: google,chv3-i2s
+
+ reg:
+ items:
+ - description: core registers
+ - description: irq registers
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2s@c0060300 {
+ compatible = "google,chv3-i2s";
+ reg = <0xc0060300 0x100>,
+ <0xc0060f00 0x10>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
index c3e9f3485449..dd51e8c5b8c2 100644
--- a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml
@@ -8,14 +8,17 @@ title: Audio codec controlled by ChromeOS EC
maintainers:
- Cheng-Yi Chiang <cychiang@chromium.org>
- - Tzung-Bi Shih <tzungbi@google.com>
+ - Tzung-Bi Shih <tzungbi@kernel.org>
description: |
Google's ChromeOS EC codec is a digital mic codec provided by the
Embedded Controller (EC) and is controlled via a host-command
interface. An EC codec node should only be found inside the "codecs"
subnode of a cros-ec node.
- (see Documentation/devicetree/bindings/mfd/google,cros-ec.yaml).
+ (see Documentation/devicetree/bindings/embedded-controller/google,cros-ec.yaml).
+
+allOf:
+ - $ref: dai-common.yaml#
properties:
compatible:
@@ -42,7 +45,7 @@ required:
- compatible
- '#sound-dai-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -57,6 +60,7 @@ examples:
cros-ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
+ interrupts = <93 0>;
codecs {
#address-cells = <2>;
diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
index 67ccddd44489..bac940553965 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
@@ -7,29 +7,21 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Google SC7180-Trogdor ASoC sound card driver
maintainers:
- - Rohit kumar <rohitkr@codeaurora.org>
+ - Rohit kumar <quic_rohkumar@quicinc.com>
- Cheng-Yi Chiang <cychiang@chromium.org>
description:
This binding describes the SC7180 sound card which uses LPASS for audio.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- google,sc7180-trogdor
- google,sc7180-coachz
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- description:
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source.
-
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
"#address-cells":
const: 1
@@ -74,7 +66,8 @@ patternProperties:
properties:
sound-dai:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
required:
- link-name
@@ -85,11 +78,10 @@ patternProperties:
required:
- compatible
- - model
- "#address-cells"
- "#size-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
index 869b40363af8..cdcd7c6f21eb 100644
--- a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
+++ b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml
@@ -7,28 +7,19 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Google SC7280-Herobrine ASoC sound card driver
maintainers:
- - Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
- Judy Hsiao <judyhsiao@chromium.org>
description:
This binding describes the SC7280 sound card which uses LPASS for audio.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- google,sc7280-herobrine
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- description:
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source.
-
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
"#address-cells":
const: 1
@@ -75,6 +66,18 @@ patternProperties:
additionalProperties: false
+ platform:
+ description: Holds subnode which includes the phandle of q6apm platform device.
+ type: object
+ properties:
+ sound-dai:
+ maxItems: 1
+
+ required:
+ - sound-dai
+
+ additionalProperties: false
+
required:
- link-name
- cpu
@@ -85,11 +88,10 @@ patternProperties:
required:
- compatible
- - model
- "#address-cells"
- "#size-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/gtm601.txt b/Documentation/devicetree/bindings/sound/gtm601.txt
deleted file mode 100644
index efa32a486c4a..000000000000
--- a/Documentation/devicetree/bindings/sound/gtm601.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-GTM601 UMTS modem audio interface CODEC
-
-This device has no configuration interface. The sample rate and channels are
-based on the compatible string
- "option,gtm601" = 8kHz mono
- "broadmobi,bm818" = 48KHz stereo
-
-Required properties:
-
- - compatible : one of
- "option,gtm601"
- "broadmobi,bm818"
-
-
-Example:
-
-codec: gtm601_codec {
- compatible = "option,gtm601";
-};
diff --git a/Documentation/devicetree/bindings/sound/ics43432.txt b/Documentation/devicetree/bindings/sound/ics43432.txt
deleted file mode 100644
index e6f05f2f6c4e..000000000000
--- a/Documentation/devicetree/bindings/sound/ics43432.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Invensense ICS-43432-compatible MEMS microphone with I2S output.
-
-There are no software configuration options for this device, indeed, the only
-host connection is the I2S interface. Apart from requirements on clock
-frequency (460 kHz to 3.379 MHz according to the data sheet) there must be
-64 clock cycles in each stereo output frame; 24 of the 32 available bits
-contain audio data. A hardware pin determines if the device outputs data
-on the left or right channel of the I2S frame.
-
-Required properties:
- - compatible: should be one of the following.
- "invensense,ics43432": For the Invensense ICS43432
- "cui,cmm-4030d-261": For the CUI CMM-4030D-261-I2S-TR
-
-Example:
-
- ics43432: ics43432 {
- compatible = "invensense,ics43432";
- };
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
index b6f5d486600e..3c75c8c78987 100644
--- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
+++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
@@ -9,23 +9,14 @@ title: NXP i.MX audio sound card.
maintainers:
- Shengjiu Wang <shengjiu.wang@nxp.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- fsl,imx-audio-card
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
-
- audio-routing:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
- description:
- A list of the connections between audio components. Each entry is a
- pair of strings, the first being the connection's sink, the second
- being the connection's source. Valid names could be power supplies,
- MicBias of codec and the jacks on the board.
-
patternProperties:
".*-dai-link$":
description:
@@ -55,6 +46,14 @@ patternProperties:
description: see tdm-slot.txt.
$ref: /schemas/types.yaml#/definitions/uint32
+ playback-only:
+ description: link is used only for playback
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ capture-only:
+ description: link is used only for capture
+ $ref: /schemas/types.yaml#/definitions/flag
+
cpu:
description: Holds subnode which indicates cpu dai.
type: object
@@ -80,13 +79,18 @@ patternProperties:
- link-name
- cpu
+ allOf:
+ - not:
+ required:
+ - playback-only
+ - capture-only
+
additionalProperties: false
required:
- compatible
- - model
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-es8328.txt b/Documentation/devicetree/bindings/sound/imx-audio-es8328.txt
deleted file mode 100644
index 07b68ab206fb..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-es8328.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Freescale i.MX audio complex with ES8328 codec
-
-Required properties:
-- compatible : "fsl,imx-audio-es8328"
-- model : The user-visible name of this sound complex
-- ssi-controller : The phandle of the i.MX SSI controller
-- jack-gpio : Optional GPIO for headphone jack
-- audio-amp-supply : Power regulator for speaker amps
-- audio-codec : The phandle of the ES8328 audio codec
-- audio-routing : A list of the connections between audio components.
- Each entry is a pair of strings, the first being the
- connection's sink, the second being the connection's
- source. Valid names could be power supplies, ES8328
- pins, and the jacks on the board:
-
- Power supplies:
- * audio-amp
-
- ES8328 pins:
- * LOUT1
- * LOUT2
- * ROUT1
- * ROUT2
- * LINPUT1
- * LINPUT2
- * RINPUT1
- * RINPUT2
- * Mic PGA
-
- Board connectors:
- * Headphone
- * Speaker
- * Mic Jack
-- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
-- mux-ext-port : The external port of the i.MX audio muxer (AUDMIX)
-
-Note: The AUDMUX port numbering should start at 1, which is consistent with
-hardware manual.
-
-Example:
-
-sound {
- compatible = "fsl,imx-audio-es8328";
- model = "imx-audio-es8328";
- ssi-controller = <&ssi1>;
- audio-codec = <&codec>;
- jack-gpio = <&gpio5 15 0>;
- audio-amp-supply = <&reg_audio_amp>;
- audio-routing =
- "Speaker", "LOUT2",
- "Speaker", "ROUT2",
- "Speaker", "audio-amp",
- "Headphone", "ROUT1",
- "Headphone", "LOUT1",
- "LINPUT1", "Mic Jack",
- "RINPUT1", "Mic Jack",
- "Mic Jack", "Mic Bias";
- mux-int-port = <1>;
- mux-ext-port = <3>;
-};
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt
deleted file mode 100644
index 2f89db88fd57..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Freescale i.MX audio complex with SGTL5000 codec
-
-Required properties:
-
- - compatible : "fsl,imx-audio-sgtl5000"
-
- - model : The user-visible name of this sound complex
-
- - ssi-controller : The phandle of the i.MX SSI controller
-
- - audio-codec : The phandle of the SGTL5000 audio codec
-
- - audio-routing : A list of the connections between audio components.
- Each entry is a pair of strings, the first being the
- connection's sink, the second being the connection's
- source. Valid names could be power supplies, SGTL5000
- pins, and the jacks on the board:
-
- Power supplies:
- * Mic Bias
-
- SGTL5000 pins:
- * MIC_IN
- * LINE_IN
- * HP_OUT
- * LINE_OUT
-
- Board connectors:
- * Mic Jack
- * Line In Jack
- * Headphone Jack
- * Line Out Jack
- * Ext Spk
-
- - mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
-
- - mux-ext-port : The external port of the i.MX audio muxer
-
-Note: The AUDMUX port numbering should start at 1, which is consistent with
-hardware manual.
-
-Example:
-
-sound {
- compatible = "fsl,imx51-babbage-sgtl5000",
- "fsl,imx-audio-sgtl5000";
- model = "imx51-babbage-sgtl5000";
- ssi-controller = <&ssi1>;
- audio-codec = <&sgtl5000>;
- audio-routing =
- "MIC_IN", "Mic Jack",
- "Mic Jack", "Mic Bias",
- "Headphone Jack", "HP_OUT";
- mux-int-port = <1>;
- mux-ext-port = <3>;
-};
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
deleted file mode 100644
index da84a442ccea..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Freescale i.MX audio complex with S/PDIF transceiver
-
-Required properties:
-
- - compatible : "fsl,imx-audio-spdif"
-
- - model : The user-visible name of this sound complex
-
- - spdif-controller : The phandle of the i.MX S/PDIF controller
-
-
-Optional properties:
-
- - spdif-out : This is a boolean property. If present, the
- transmitting function of S/PDIF will be enabled,
- indicating there's a physical S/PDIF out connector
- or jack on the board or it's connecting to some
- other IP block, such as an HDMI encoder or
- display-controller.
-
- - spdif-in : This is a boolean property. If present, the receiving
- function of S/PDIF will be enabled, indicating there
- is a physical S/PDIF in connector/jack on the board.
-
-* Note: At least one of these two properties should be set in the DT binding.
-
-
-Example:
-
-sound-spdif {
- compatible = "fsl,imx-audio-spdif";
- model = "imx-spdif";
- spdif-controller = <&spdif>;
- spdif-out;
- spdif-in;
-};
diff --git a/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml b/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
new file mode 100644
index 000000000000..5e11ce2c13ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/infineon,peb2466.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon PEB2466 codec
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ The Infineon PEB2466 codec is a programmable DSP-based four channels codec
+ with filters capabilities.
+
+ The time-slots used by the codec must be set and so, the properties
+ 'dai-tdm-slot-num', 'dai-tdm-slot-width', 'dai-tdm-slot-tx-mask' and
+ 'dai-tdm-slot-rx-mask' must be present in the sound card node for sub-nodes
+ that involve the codec. The codec uses one 8bit time-slot per channel.
+ 'dai-tdm-tdm-slot-with' must be set to 8.
+
+ The PEB2466 codec also supports 28 gpios (signaling pins).
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: infineon,peb2466
+
+ reg:
+ description:
+ SPI device address.
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ spi-max-frequency:
+ maximum: 8192000
+
+ reset-gpios:
+ description:
+ GPIO used to reset the device.
+ maxItems: 1
+
+ firmware-name:
+ maxItems: 1
+ description:
+ Filters coefficients file to load. If this property is omitted, internal
+ filters are disabled.
+
+ '#sound-dai-cells':
+ const: 0
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@0 {
+ compatible = "infineon,peb2466";
+ reg = <0>;
+ spi-max-frequency = <8192000>;
+ reset-gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml
index d607325f2f15..d15c000f14e1 100644
--- a/Documentation/devicetree/bindings/sound/ingenic,aic.yaml
+++ b/Documentation/devicetree/bindings/sound/ingenic,aic.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/ingenic,aic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs AC97 / I2S Controller (AIC) DT bindings
+title: Ingenic SoCs AC97 / I2S Controller (AIC)
maintainers:
- Paul Cercueil <paul@crapouillou.net>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
$nodename:
pattern: '^audio-controller@'
@@ -20,6 +23,7 @@ properties:
- ingenic,jz4760-i2s
- ingenic,jz4770-i2s
- ingenic,jz4780-i2s
+ - ingenic,x1000-i2s
- items:
- const: ingenic,jz4725b-i2s
- const: ingenic,jz4740-i2s
@@ -37,15 +41,11 @@ properties:
items:
- description: AIC clock
- description: I2S clock
- - description: EXT clock
- - description: PLL/2 clock
clock-names:
items:
- const: aic
- const: i2s
- - const: ext
- - const: pll half
dmas:
items:
@@ -57,7 +57,7 @@ properties:
- const: rx
- const: tx
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
@@ -82,10 +82,8 @@ examples:
interrupts = <18>;
clocks = <&cgu JZ4740_CLK_AIC>,
- <&cgu JZ4740_CLK_I2S>,
- <&cgu JZ4740_CLK_EXT>,
- <&cgu JZ4740_CLK_PLL_HALF>;
- clock-names = "aic", "i2s", "ext", "pll half";
+ <&cgu JZ4740_CLK_I2S>;
+ clock-names = "aic", "i2s";
dmas = <&dmac 25 0xffffffff>, <&dmac 24 0xffffffff>;
dma-names = "rx", "tx";
diff --git a/Documentation/devicetree/bindings/sound/ingenic,codec.yaml b/Documentation/devicetree/bindings/sound/ingenic,codec.yaml
index 48aae54dd643..b58b90850e35 100644
--- a/Documentation/devicetree/bindings/sound/ingenic,codec.yaml
+++ b/Documentation/devicetree/bindings/sound/ingenic,codec.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/ingenic,codec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic JZ47xx internal codec DT bindings
+title: Ingenic JZ47xx internal codec
maintainers:
- Paul Cercueil <paul@crapouillou.net>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
$nodename:
pattern: '^audio-codec@.*'
@@ -37,7 +40,7 @@ properties:
'#sound-dai-cells':
const: 0
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/inno-rk3036.txt b/Documentation/devicetree/bindings/sound/inno-rk3036.txt
deleted file mode 100644
index 758de8e27561..000000000000
--- a/Documentation/devicetree/bindings/sound/inno-rk3036.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Inno audio codec for RK3036
-
-Inno audio codec is integrated inside RK3036 SoC.
-
-Required properties:
-- compatible : Should be "rockchip,rk3036-codec".
-- reg : The registers of codec.
-- clock-names : Should be "acodec_pclk".
-- clocks : The clock of codec.
-- rockchip,grf : The phandle of grf device node.
-
-Example:
-
- acodec: acodec-ana@20030000 {
- compatible = "rk3036-codec";
- reg = <0x20030000 0x4000>;
- rockchip,grf = <&grf>;
- clock-names = "acodec_pclk";
- clocks = <&cru ACLK_VCODEC>;
- };
diff --git a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml
index 803627e984f6..dca617860938 100644
--- a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml
@@ -5,14 +5,18 @@
$id: http://devicetree.org/schemas/sound/intel,keembay-i2s.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Intel KeemBay I2S Device Tree Bindings
+title: Intel KeemBay I2S
maintainers:
- - Sia, Jee Heng <jee.heng.sia@intel.com>
+ - Daniele Alessandrelli <daniele.alessandrelli@intel.com>
+ - Paul J. Murphy <paul.j.murphy@intel.com>
description: |
Intel KeemBay I2S
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -64,23 +68,23 @@ required:
- clock-names
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- #define KEEM_BAY_PSS_AUX_I2S3
- #define KEEM_BAY_PSS_I2S3
- i2s3: i2s@20140000 {
- compatible = "intel,keembay-i2s";
- #sound-dai-cells = <0>;
- reg = <0x20140000 0x200>, /* I2S registers */
- <0x202a00a4 0x4>; /* I2S gen configuration */
- reg-names = "i2s-regs", "i2s_gen_cfg";
- interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "osc", "apb_clk";
- clocks = <&scmi_clk KEEM_BAY_PSS_AUX_I2S3>, <&scmi_clk KEEM_BAY_PSS_I2S3>;
- dmas = <&axi_dma0 29>, <&axi_dma0 33>;
- dma-names = "tx", "rx";
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #define KEEM_BAY_PSS_AUX_I2S3
+ #define KEEM_BAY_PSS_I2S3
+ i2s@20140000 {
+ compatible = "intel,keembay-i2s";
+ #sound-dai-cells = <0>;
+ reg = <0x20140000 0x200>, /* I2S registers */
+ <0x202a00a4 0x4>; /* I2S gen configuration */
+ reg-names = "i2s-regs", "i2s_gen_cfg";
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "osc", "apb_clk";
+ clocks = <&scmi_clk KEEM_BAY_PSS_AUX_I2S3>, <&scmi_clk KEEM_BAY_PSS_I2S3>;
+ dmas = <&axi_dma0 29>, <&axi_dma0 33>;
+ dma-names = "tx", "rx";
+ };
diff --git a/Documentation/devicetree/bindings/sound/invensense,ics43432.yaml b/Documentation/devicetree/bindings/sound/invensense,ics43432.yaml
new file mode 100644
index 000000000000..7bd984817aa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/invensense,ics43432.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/invensense,ics43432.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Invensense ICS-43432-compatible MEMS Microphone with I2S Output
+
+maintainers:
+ - Oleksij Rempel <o.rempel@pengutronix.de>
+
+description:
+ The ICS-43432 and compatible MEMS microphones output audio over an I2S
+ interface and require no software configuration. The only host connection
+ is the I2S bus. The microphone requires an I2S clock frequency between
+ 460 kHz and 3.379 MHz and 64 clock cycles per stereo frame. Each frame
+ contains 32-bit slots per channel, with 24 bits carrying audio data.
+ A hardware pin determines whether the microphone outputs audio on the
+ left or right channel of the I2S frame.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - invensense,ics43432
+ - cui,cmm-4030d-261
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ics43432: ics43432 {
+ compatible = "invensense,ics43432";
+
+ port {
+ endpoint {
+ remote-endpoint = <&i2s1_endpoint>;
+ dai-format = "i2s";
+ };
+ };
+
+ };
diff --git a/Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml b/Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml
new file mode 100644
index 000000000000..b36c35e5da1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/irondevice,sma1303.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/irondevice,sma1303.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Iron Device SMA1303 Audio Amplifier
+
+maintainers:
+ - Kiseok Jo <kiseok.jo@irondevice.com>
+
+description:
+ SMA1303 digital class-D audio amplifier
+ with an integrated boost converter.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - irondevice,sma1303
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ amplifier@1e {
+ compatible = "irondevice,sma1303";
+ reg = <0x1e>;
+ #sound-dai-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/irondevice,sma1307.yaml b/Documentation/devicetree/bindings/sound/irondevice,sma1307.yaml
new file mode 100644
index 000000000000..1e2a038d0048
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/irondevice,sma1307.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/irondevice,sma1307.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Iron Device SMA1307 Audio Amplifier
+
+maintainers:
+ - Kiseok Jo <kiseok.jo@irondevice.com>
+
+description:
+ SMA1307 boosted digital speaker amplifier with feedback-loop.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - irondevice,sma1307a
+ - irondevice,sma1307aq
+ description:
+ If a 'q' is added, it indicated the product is AEC-Q100
+ qualified for automotive applications. SMA1307A supports
+ both WLCSP and QFN packages. However, SMA1307AQ only
+ supports the QFN package.
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ amplifier@1e {
+ compatible = "irondevice,sma1307a";
+ reg = <0x1e>;
+ #sound-dai-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
index e3a1f485f664..a67b79cbe006 100644
--- a/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
+++ b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bluetooth SCO Audio Codec Device Tree Bindings
+title: Bluetooth SCO Audio Codec
maintainers:
- Mark Brown <broonie@kernel.org>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
'#sound-dai-cells':
enum:
@@ -26,7 +29,7 @@ required:
- '#sound-dai-cells'
- compatible
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
deleted file mode 100644
index a4f9257e313d..000000000000
--- a/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
+++ /dev/null
@@ -1,37 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/linux,spdif-dit.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Dummy SPDIF Transmitter Device Tree Bindings
-
-maintainers:
- - Mark Brown <broonie@kernel.org>
-
-allOf:
- - $ref: name-prefix.yaml#
-
-properties:
- compatible:
- const: linux,spdif-dit
-
- "#sound-dai-cells":
- const: 0
-
- sound-name-prefix: true
-
-required:
- - "#sound-dai-cells"
- - compatible
-
-additionalProperties: false
-
-examples:
- - |
- spdif-out {
- #sound-dai-cells = <0>;
- compatible = "linux,spdif-dit";
- };
-
-...
diff --git a/Documentation/devicetree/bindings/sound/linux,spdif.yaml b/Documentation/devicetree/bindings/sound/linux,spdif.yaml
new file mode 100644
index 000000000000..aea6230db54c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/linux,spdif.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/linux,spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dummy SPDIF Transmitter/Receiver
+
+maintainers:
+ - Mark Brown <broonie@kernel.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - linux,spdif-dit
+ - linux,spdif-dir
+
+ "#sound-dai-cells":
+ const: 0
+
+ sound-name-prefix: true
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
new file mode 100644
index 000000000000..61e8babed402
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/loongson,ls-audio-card.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson 7axxx/2kxxx ASoC audio sound card driver
+
+maintainers:
+ - Yingkun Meng <mengyingkun@loongson.cn>
+
+description:
+ The binding describes the sound card present in loongson
+ 7axxx/2kxxx platform. The sound card is an ASoC component
+ which uses Loongson I2S controller to transfer the audio data.
+
+properties:
+ compatible:
+ const: loongson,ls-audio-card
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ mclk-fs:
+ $ref: simple-card.yaml#/definitions/mclk-fs
+
+ cpu:
+ description: Holds subnode which indicates cpu dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ maxItems: 1
+ required:
+ - sound-dai
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ maxItems: 1
+ required:
+ - sound-dai
+
+required:
+ - compatible
+ - model
+ - mclk-fs
+ - cpu
+ - codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "loongson,ls-audio-card";
+ model = "loongson-audio";
+ mclk-fs = <512>;
+
+ cpu {
+ sound-dai = <&i2s>;
+ };
+ codec {
+ sound-dai = <&es8323>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/loongson,ls1b-ac97.yaml b/Documentation/devicetree/bindings/sound/loongson,ls1b-ac97.yaml
new file mode 100644
index 000000000000..1c6a2771f942
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/loongson,ls1b-ac97.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/loongson,ls1b-ac97.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 AC97 Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ The Loongson-1 AC97 controller supports 2-channel stereo output and input.
+ It is paired with the DMA engine to handle playback and capture functions.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls1b-ac97
+ - items:
+ - enum:
+ - loongson,ls1a-ac97
+ - loongson,ls1c-ac97
+ - const: loongson,ls1b-ac97
+
+ reg:
+ maxItems: 3
+
+ reg-names:
+ items:
+ - const: ac97
+ - const: audio-tx
+ - const: audio-rx
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - dmas
+ - dma-names
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ audio-controller@1fe74000 {
+ compatible = "loongson,ls1b-ac97";
+ reg = <0x1fe74000 0x60>, <0x1fe72420 0x4>, <0x1fe74c4c 0x4>;
+ reg-names = "ac97", "audio-tx", "audio-rx";
+ dmas = <&dma 1>, <&dma 2>;
+ dma-names = "tx", "rx";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/loongson,ls2k1000-i2s.yaml b/Documentation/devicetree/bindings/sound/loongson,ls2k1000-i2s.yaml
new file mode 100644
index 000000000000..da79510bb2d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/loongson,ls2k1000-i2s.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/loongson,ls2k1000-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-2K1000 I2S controller
+
+maintainers:
+ - Binbin Zhou <zhoubinbin@loongson.cn>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: loongson,ls2k1000-i2s
+
+ reg:
+ items:
+ - description: Loongson I2S controller Registers.
+ - description: APB DMA config register for Loongson I2S controller.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - dmas
+ - dma-names
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls2k-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2s@1fe2d000 {
+ compatible = "loongson,ls2k1000-i2s";
+ reg = <0x1fe2d000 0x14>,
+ <0x1fe00438 0x8>;
+ interrupt-parent = <&liointc0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LOONGSON2_APB_CLK>;
+ dmas = <&apbdma2 0>, <&apbdma3 0>;
+ dma-names = "tx", "rx";
+ #sound-dai-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
index 81f266d66ec5..4193d17d1c62 100644
--- a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
+++ b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/marvell,mmp-sspa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvel SSPA Digital Audio Interface Bindings
+title: Marvel SSPA Digital Audio Interface
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
$nodename:
pattern: "^audio-controller(@.*)?$"
@@ -57,6 +60,7 @@ properties:
properties:
endpoint:
type: object
+ additionalProperties: true
properties:
dai-format:
@@ -73,7 +77,7 @@ required:
- dma-names
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt
deleted file mode 100644
index 39d640294c62..000000000000
--- a/Documentation/devicetree/bindings/sound/max98090.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-MAX98090 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "maxim,max98090" or "maxim,max98091".
-
-- reg : The I2C address of the device.
-
-- interrupts : The CODEC's interrupt output.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-
-- clock-names: Should be "mclk"
-
-- #sound-dai-cells : should be 0.
-
-- maxim,dmic-freq: Frequency at which to clock DMIC
-
-- maxim,micbias: Micbias voltage applies to the analog mic, valid voltages value are:
- 0 - 2.2v
- 1 - 2.55v
- 2 - 2.4v
- 3 - 2.8v
-
-Pins on the device (for linking into audio routes):
-
- * MIC1
- * MIC2
- * DMICL
- * DMICR
- * IN1
- * IN2
- * IN3
- * IN4
- * IN5
- * IN6
- * IN12
- * IN34
- * IN56
- * HPL
- * HPR
- * SPKL
- * SPKR
- * RCVL
- * RCVR
- * MICBIAS
-
-Example:
-
-audio-codec@10 {
- compatible = "maxim,max98090";
- reg = <0x10>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(H, 4) IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max98095.txt b/Documentation/devicetree/bindings/sound/max98095.txt
deleted file mode 100644
index 318a4c82f17f..000000000000
--- a/Documentation/devicetree/bindings/sound/max98095.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-MAX98095 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "maxim,max98095".
-
-- reg : The I2C address of the device.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-
-- clock-names: Should be "mclk"
-
-Example:
-
-max98095: codec@11 {
- compatible = "maxim,max98095";
- reg = <0x11>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max98357a.txt b/Documentation/devicetree/bindings/sound/max98357a.txt
deleted file mode 100644
index 75db84d06240..000000000000
--- a/Documentation/devicetree/bindings/sound/max98357a.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Maxim MAX98357A/MAX98360A audio DAC
-
-This node models the Maxim MAX98357A/MAX98360A DAC.
-
-Required properties:
-- compatible : "maxim,max98357a" for MAX98357A.
- "maxim,max98360a" for MAX98360A.
-
-Optional properties:
-- sdmode-gpios : GPIO specifier for the chip's SD_MODE pin.
- If this option is not specified then driver does not manage
- the pin state (e.g. chip is always on).
-- sdmode-delay : specify delay time for SD_MODE pin.
- If this option is specified, which means it's required i2s clocks
- ready before SD_MODE is unmuted in order to avoid the speaker pop noise.
- It's observed that 5ms is sufficient.
-
-Example:
-
-max98357a {
- compatible = "maxim,max98357a";
- sdmode-gpios = <&qcom_pinmux 25 0>;
-};
-
-max98360a {
- compatible = "maxim,max98360a";
- sdmode-gpios = <&qcom_pinmux 25 0>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max98371.txt b/Documentation/devicetree/bindings/sound/max98371.txt
deleted file mode 100644
index 8b2b2704b574..000000000000
--- a/Documentation/devicetree/bindings/sound/max98371.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-max98371 codec
-
-This device supports I2C mode only.
-
-Required properties:
-
-- compatible : "maxim,max98371"
-- reg : The chip select number on the I2C bus
-
-Example:
-
-&i2c {
- max98371: max98371@31 {
- compatible = "maxim,max98371";
- reg = <0x31>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/max98504.txt b/Documentation/devicetree/bindings/sound/max98504.txt
deleted file mode 100644
index 583ed5fdfb28..000000000000
--- a/Documentation/devicetree/bindings/sound/max98504.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Maxim MAX98504 class D mono speaker amplifier
-
-This device supports I2C control interface and an IRQ output signal. It features
-a PCM and PDM digital audio interface (DAI) and a differential analog input.
-
-Required properties:
-
- - compatible : "maxim,max98504"
- - reg : should contain the I2C slave device address
- - DVDD-supply, DIOVDD-supply, PVDD-supply: power supplies for the device,
- as covered in ../regulator/regulator.txt
- - interrupts : should specify the interrupt line the device is connected to,
- as described in ../interrupt-controller/interrupts.txt
-
-Optional properties:
-
- - maxim,brownout-threshold - the PVDD brownout threshold, the value must be
- from 0, 1...21 range, corresponding to 2.6V, 2.65V...3.65V voltage range
- - maxim,brownout-attenuation - the brownout attenuation to the speaker gain
- applied during the "attack hold" and "timed hold" phase, the value must be
- from 0...6 (dB) range
- - maxim,brownout-attack-hold-ms - the brownout attack hold phase time in ms,
- 0...255 (VBATBROWN_ATTK_HOLD, register 0x0018)
- - maxim,brownout-timed-hold-ms - the brownout timed hold phase time in ms,
- 0...255 (VBATBROWN_TIME_HOLD, register 0x0019)
- - maxim,brownout-release-rate-ms - the brownout release phase step time in ms,
- 0...255 (VBATBROWN_RELEASE, register 0x001A)
-
-The default value when the above properties are not specified is 0,
-the maxim,brownout-threshold property must be specified to actually enable
-the PVDD brownout protection.
-
-Example:
-
- max98504@31 {
- compatible = "maxim,max98504";
- reg = <0x31>;
- interrupt-parent = <&gpio_bank_0>;
- interrupts = <2 0>;
-
- DVDD-supply = <&regulator>;
- DIOVDD-supply = <&regulator>;
- PVDD-supply = <&regulator>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max9867.txt b/Documentation/devicetree/bindings/sound/max9867.txt
deleted file mode 100644
index b8bd914ee697..000000000000
--- a/Documentation/devicetree/bindings/sound/max9867.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-max9867 codec
-
-This device supports I2C mode only.
-
-Required properties:
-
-- compatible : "maxim,max9867"
-- reg : The chip select number on the I2C bus
-
-Example:
-
-&i2c {
- max9867: max9867@18 {
- compatible = "maxim,max9867";
- reg = <0x18>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt
deleted file mode 100644
index 98cb9ba5b328..000000000000
--- a/Documentation/devicetree/bindings/sound/max9892x.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
-
-This device supports I2C.
-
-Required properties:
-
- - compatible : should be one of the following
- - "maxim,max98925"
- - "maxim,max98926"
- - "maxim,max98927"
-
- - vmon-slot-no : slot number used to send voltage information
- or in inteleave mode this will be used as
- interleave slot.
- MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
- MAX98927 slot range : 0 ~ 15, Default : 0
-
- - imon-slot-no : slot number used to send current information
- MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
- MAX98927 slot range : 0 ~ 15, Default : 0
-
- - interleave-mode : When using two MAX9892X in a system it is
- possible to create ADC data that that will
- overflow the frame size. Digital Audio Interleave
- mode provides a means to output VMON and IMON data
- from two devices on a single DOUT line when running
- smaller frames sizes such as 32 BCLKS per LRCLK or
- 48 BCLKS per LRCLK.
- Range : 0 (off), 1 (on), Default : 0
-
- - reg : the I2C address of the device for I2C
-
-Optional properties:
- - reset-gpios : GPIO to reset the device
-
-Example:
-
-codec: max98927@3a {
- compatible = "maxim,max98927";
- vmon-slot-no = <0>;
- imon-slot-no = <1>;
- interleave-mode = <0>;
- reg = <0x3a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/maxim,max9759.txt b/Documentation/devicetree/bindings/sound/maxim,max9759.txt
deleted file mode 100644
index 737a996374d3..000000000000
--- a/Documentation/devicetree/bindings/sound/maxim,max9759.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Maxim MAX9759 Speaker Amplifier
-===============================
-
-Required properties:
-- compatible : "maxim,max9759"
-- shutdown-gpios : the gpio connected to the shutdown pin
-- mute-gpios : the gpio connected to the mute pin
-- gain-gpios : the 2 gpios connected to the g1 and g2 pins
-
-Example:
-
-max9759: analog-amplifier {
- compatible = "maxim,max9759";
- shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
- mute-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
- gain-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>,
- <&gpio3 25 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/sound/maxim,max9759.yaml b/Documentation/devicetree/bindings/sound/maxim,max9759.yaml
new file mode 100644
index 000000000000..a76ee6a635af
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max9759.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max9759.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX9759 Speaker Amplifier
+
+maintainers:
+ - Otabek Nazrullaev <otabeknazrullaev1998@gmail.com>
+
+properties:
+ compatible:
+ const: maxim,max9759
+
+ shutdown-gpios:
+ maxItems: 1
+ description: the gpio connected to the shutdown pin
+
+ mute-gpios:
+ maxItems: 1
+ description: the gpio connected to the mute pin
+
+ gain-gpios:
+ maxItems: 2
+ description: the 2 gpios connected to the g1 and g2 pins
+
+required:
+ - compatible
+ - shutdown-gpios
+ - mute-gpios
+ - gain-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ amplifier {
+ compatible = "maxim,max9759";
+ shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
+ mute-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ gain-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>,
+ <&gpio3 25 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98088.txt b/Documentation/devicetree/bindings/sound/maxim,max98088.txt
deleted file mode 100644
index da764d913319..000000000000
--- a/Documentation/devicetree/bindings/sound/maxim,max98088.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-MAX98088 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible: "maxim,max98088" or "maxim,max98089".
-- reg: The I2C address of the device.
-
-Optional properties:
-
-- clocks: the clock provider of MCLK, see ../clock/clock-bindings.txt section
- "consumer" for more information.
-- clock-names: must be set to "mclk"
-
-Example:
-
-max98089: codec@10 {
- compatible = "maxim,max98089";
- reg = <0x10>;
- clocks = <&clks IMX6QDL_CLK_CKO2>;
- clock-names = "mclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98088.yaml b/Documentation/devicetree/bindings/sound/maxim,max98088.yaml
new file mode 100644
index 000000000000..e4a2967e1e81
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98088.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98088.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX98088 audio CODEC
+
+maintainers:
+ - Abdulrasaq Lawani <abdulrasaqolawani@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98088
+ - maxim,max98089
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@10 {
+ compatible = "maxim,max98089";
+ reg = <0x10>;
+ clocks = <&clks 0>;
+ clock-names = "mclk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98090.yaml b/Documentation/devicetree/bindings/sound/maxim,max98090.yaml
new file mode 100644
index 000000000000..9df1296aacb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98090.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98090.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98090/MAX98091 audio codecs
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description: |
+ Pins on the device (for linking into audio routes):
+ MIC1, MIC2, DMICL, DMICR, IN1, IN2, IN3, IN4, IN5, IN6, IN12, IN34, IN56,
+ HPL, HPR, SPKL, SPKR, RCVL, RCVR, MICBIAS
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98090
+ - maxim,max98091
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ interrupts:
+ maxItems: 1
+
+ maxim,dmic-freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 2500000
+ description:
+ DMIC clock frequency
+
+ maxim,micbias:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ default: 3
+ description: |
+ Micbias voltage applied to the analog mic, valid voltages value are:
+ 0 - 2.2v
+ 1 - 2.55v
+ 2 - 2.4v
+ 3 - 2.8v
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ interrupt-parent = <&gpx3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&i2s0 0>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98095.yaml b/Documentation/devicetree/bindings/sound/maxim,max98095.yaml
new file mode 100644
index 000000000000..76ea4fe711de
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98095.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98095.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98095 audio codec
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98095
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@11 {
+ compatible = "maxim,max98095";
+ reg = <0x11>;
+ clocks = <&i2s0 0>;
+ clock-names = "mclk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98357a.yaml b/Documentation/devicetree/bindings/sound/maxim,max98357a.yaml
new file mode 100644
index 000000000000..83ba8666fbb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98357a.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98357a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98357A/MAX98360A amplifier
+
+maintainers:
+ - Tzung-Bi Shih <tzungbi@kernel.org>
+
+description:
+ Maxim Integrated MAX98357A/MAX98360A is a digital pulse-code modulation (PCM)
+ input Class D amplifier.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98357a
+ - maxim,max98360a
+
+ '#sound-dai-cells':
+ const: 0
+
+ sdmode-gpios:
+ maxItems: 1
+ description:
+ Chip's SD_MODE pin. If missing the chip is always on.
+
+ sdmode-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay time for SD_MODE pin changes intended to make I2S clocks ready
+ before SD_MODE is unmuted in order to avoid the speaker pop noise.
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ amplifier {
+ compatible = "maxim,max98360a";
+ #sound-dai-cells = <0>;
+ sdmode-gpios = <&qcom_pinmux 25 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98371.yaml b/Documentation/devicetree/bindings/sound/maxim,max98371.yaml
new file mode 100644
index 000000000000..14fba34ef81a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98371.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98371.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX98371 audio codec
+
+maintainers:
+ - anish kumar <yesanishhere@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: maxim,max98371
+
+ '#sound-dai-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@31 {
+ compatible = "maxim,max98371";
+ reg = <0x31>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98390.yaml b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml
index deaa6886c42f..d35dd8408c61 100644
--- a/Documentation/devicetree/bindings/sound/maxim,max98390.yaml
+++ b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml
@@ -9,6 +9,9 @@ title: Maxim Integrated MAX98390 Speaker Amplifier with Integrated Dynamic Speak
maintainers:
- Steve Lee <steves.lee@maximintegrated.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: maxim,max98390
@@ -32,11 +35,14 @@ properties:
reset-gpios:
maxItems: 1
+ '#sound-dai-cells':
+ const: 0
+
required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98504.yaml b/Documentation/devicetree/bindings/sound/maxim,max98504.yaml
new file mode 100644
index 000000000000..6d33bb4a98ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98504.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98504.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98504 class D mono speaker amplifier
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+
+description:
+ Maxim Integrated MAX98504 speaker amplifier supports I2C control interface
+ with an IRQ output signal, PCM and PDM digital audio interface (DAI) and a
+ differential analog input.
+
+properties:
+ compatible:
+ const: maxim,max98504
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ DIOVDD-supply: true
+ DVDD-supply: true
+ PVDD-supply: true
+
+ maxim,brownout-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 21
+ default: 0
+ description:
+ PVDD brownout threshold, where values correspond to 2.6V, 2.65V...3.65V
+ voltage range. Property also enables the PVDD brownout protection.
+
+ maxim,brownout-attenuation:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 6
+ default: 0
+ description:
+ Brownout attenuation to the speaker gain applied during the "attack hold"
+ and "timed hold" phase, the value must be from 0...6 (dB) range.
+
+ maxim,brownout-attack-hold-ms:
+ maximum: 255
+ default: 0
+ description:
+ Brownout attack hold phase time in ms, VBATBROWN_ATTK_HOLD, register 0x0018.
+
+ maxim,brownout-timed-hold-ms:
+ maximum: 255
+ default: 0
+ description:
+ Brownout timed hold phase time in ms, VBATBROWN_TIME_HOLD, register 0x0019.
+
+ maxim,brownout-release-rate-ms:
+ maximum: 255
+ default: 0
+ description:
+ Brownout release phase step time in ms, VBATBROWN_RELEASE, register 0x001A.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ amplifier@31 {
+ compatible = "maxim,max98504";
+ reg = <0x31>;
+
+ DIOVDD-supply = <&ldo3_reg>;
+ DVDD-supply = <&ldo3_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/maxim,max9867.yaml b/Documentation/devicetree/bindings/sound/maxim,max9867.yaml
new file mode 100644
index 000000000000..0b9a84d33b6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max9867.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max9867.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX9867 CODEC
+
+description: |
+ This device supports I2C only.
+ Pins on the device (for linking into audio routes):
+ * LOUT
+ * ROUT
+ * LINL
+ * LINR
+ * MICL
+ * MICR
+ * DMICL
+ * DMICR
+
+maintainers:
+ - Ladislav Michl <ladis@linux-mips.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max9867
+
+ '#sound-dai-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@18 {
+ compatible = "maxim,max9867";
+ #sound-dai-cells = <0>;
+ reg = <0x18>;
+ clocks = <&codec_clk>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98925.yaml b/Documentation/devicetree/bindings/sound/maxim,max98925.yaml
new file mode 100644
index 000000000000..121e8d2d44da
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98925.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98925.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98925/MAX98926/MAX98927 speaker amplifier
+
+maintainers:
+ - Ryan Lee <ryans.lee@maximintegrated.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max98925
+ - maxim,max98926
+ - maxim,max98927
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ vmon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 30
+ default: 0
+ description:
+ Slot number used to send voltage information or in inteleave mode this
+ will be used as interleave slot.
+
+ imon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 30
+ default: 0
+ description:
+ Slot number used to send current information.
+
+ maxim,interleave-mode:
+ type: boolean
+ description:
+ When using two MAX9892X in a system it is possible to create ADC data
+ that will overflow the frame size. When enabled, the Digital Audio
+ Interleave mode provides a means to output VMON and IMON data from two
+ devices on a single DOUT line when running smaller frames sizes such as
+ 32 BCLKS per LRCLK or 48 BCLKS per LRCLK.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max98927
+ then:
+ properties:
+ vmon-slot-no:
+ minimum: 0
+ maximum: 15
+
+ imon-slot-no:
+ minimum: 0
+ maximum: 15
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@3a {
+ compatible = "maxim,max98927";
+ reg = <0x3a>;
+ #sound-dai-cells = <0>;
+
+ pinctrl-0 = <&speaker_default>;
+ pinctrl-names = "default";
+
+ reset-gpios = <&tlmm 69 GPIO_ACTIVE_LOW>;
+
+ vmon-slot-no = <1>;
+ imon-slot-no = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml b/Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml
deleted file mode 100644
index 0481315cb5f2..000000000000
--- a/Documentation/devicetree/bindings/sound/mchp,i2s-mcc.yaml
+++ /dev/null
@@ -1,108 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mchp,i2s-mcc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip I2S Multi-Channel Controller
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The I2SMCC complies with the Inter-IC Sound (I2S) bus specification and
- supports a Time Division Multiplexed (TDM) interface with external
- multi-channel audio codecs. It consists of a receiver, a transmitter and a
- common clock generator that can be enabled separately to provide Adapter,
- Client or Controller modes with receiver and/or transmitter active.
- On later I2SMCC versions (starting with Microchip's SAMA7G5) I2S
- multi-channel is supported by using multiple data pins, output and
- input, without TDM.
-
-properties:
- "#sound-dai-cells":
- const: 0
-
- compatible:
- enum:
- - microchip,sam9x60-i2smcc
- - microchip,sama7g5-i2smcc
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock (Optional). Should be set mostly when Master
- Mode is required.
- minItems: 1
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
- minItems: 1
-
- dmas:
- items:
- - description: TX DMA Channel
- - description: RX DMA Channel
-
- dma-names:
- items:
- - const: tx
- - const: rx
-
- microchip,tdm-data-pair:
- description:
- Represents the DIN/DOUT pair pins that are used to receive/send
- TDM data. It is optional and it is only needed if the controller
- uses the TDM mode.
- $ref: /schemas/types.yaml#/definitions/uint8
- enum: [0, 1, 2, 3]
- default: 0
-
-if:
- properties:
- compatible:
- const: microchip,sam9x60-i2smcc
-then:
- properties:
- microchip,tdm-data-pair: false
-
-required:
- - "#sound-dai-cells"
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- i2s@f001c000 {
- #sound-dai-cells = <0>;
- compatible = "microchip,sam9x60-i2smcc";
- reg = <0xf001c000 0x100>;
- interrupts = <34 IRQ_TYPE_LEVEL_HIGH 7>;
- dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
- AT91_XDMAC_DT_PERID(36))>,
- <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
- AT91_XDMAC_DT_PERID(37))>;
- dma-names = "tx", "rx";
- clocks = <&i2s_clk>, <&i2s_gclk>;
- clock-names = "pclk", "gclk";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2s_default>;
- };
diff --git a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml b/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
deleted file mode 100644
index 970311143253..000000000000
--- a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
+++ /dev/null
@@ -1,73 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mchp,spdifrx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip S/PDIF Rx Controller Device Tree Bindings
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The Microchip Sony/Philips Digital Interface Receiver is a serial port
- compliant with the IEC-60958 standard.
-
-properties:
- "#sound-dai-cells":
- const: 0
-
- compatible:
- const: microchip,sama7g5-spdifrx
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
-
- dmas:
- description: RX DMA Channel
- maxItems: 1
-
- dma-names:
- const: rx
-
-required:
- - "#sound-dai-cells"
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- spdifrx: spdifrx@e1614000 {
- #sound-dai-cells = <0>;
- compatible = "microchip,sama7g5-spdifrx";
- reg = <0xe1614000 0x4000>;
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma0 AT91_XDMAC_DT_PERID(49)>;
- dma-names = "rx";
- clocks = <&pmc PMC_TYPE_PERIPHERAL 84>, <&pmc PMC_TYPE_GCK 84>;
- clock-names = "pclk", "gclk";
- };
diff --git a/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml b/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml
deleted file mode 100644
index d5c022e49526..000000000000
--- a/Documentation/devicetree/bindings/sound/mchp,spdiftx.yaml
+++ /dev/null
@@ -1,75 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mchp,spdiftx.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip S/PDIF Tx Controller Device Tree Bindings
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The Microchip Sony/Philips Digital Interface Transmitter is a serial port
- compliant with the IEC-60958 standard.
-
-properties:
- "#sound-dai-cells":
- const: 0
-
- compatible:
- const: microchip,sama7g5-spdiftx
-
- reg:
- maxItems: 1
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
-
- dmas:
- description: TX DMA Channel
- maxItems: 1
-
- dma-names:
- const: tx
-
-required:
- - "#sound-dai-cells"
- - compatible
- - reg
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
-
- spdiftx@e1618000 {
- #sound-dai-cells = <0>;
- compatible = "microchip,sama7g5-spdiftx";
- reg = <0xe1618000 0x4000>;
- interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma0 AT91_XDMAC_DT_PERID(50)>;
- dma-names = "tx";
- clocks = <&pmc PMC_TYPE_PERIPHERAL 85>, <&pmc PMC_TYPE_GCK 85>;
- clock-names = "pclk", "gclk";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_spdiftx_default>;
- };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
new file mode 100644
index 000000000000..45382c4d86aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt2701-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Audio Front End (AFE) PCM controller for mt2701
+
+description:
+ The AFE PCM node must be a subnode of the MediaTek audsys device tree node.
+
+maintainers:
+ - Eugen Hristev <eugen.hristev@collabora.com>
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt2701-audio
+ - mediatek,mt7622-audio
+
+ interrupts:
+ items:
+ - description: AFE interrupt
+ - description: ASYS interrupt
+
+ interrupt-names:
+ items:
+ - const: afe
+ - const: asys
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: audio infra sys clock
+ - description: top audio mux 1
+ - description: top audio mux 2
+ - description: top audio sys a1 clock
+ - description: top audio sys a2 clock
+ - description: i2s0 source selection
+ - description: i2s1 source selection
+ - description: i2s2 source selection
+ - description: i2s3 source selection
+ - description: i2s0 source divider
+ - description: i2s1 source divider
+ - description: i2s2 source divider
+ - description: i2s3 source divider
+ - description: i2s0 master clock
+ - description: i2s1 master clock
+ - description: i2s2 master clock
+ - description: i2s3 master clock
+ - description: i2so0 hopping clock
+ - description: i2so1 hopping clock
+ - description: i2so2 hopping clock
+ - description: i2so3 hopping clock
+ - description: i2si0 hopping clock
+ - description: i2si1 hopping clock
+ - description: i2si2 hopping clock
+ - description: i2si3 hopping clock
+ - description: asrc0 output clock
+ - description: asrc1 output clock
+ - description: asrc2 output clock
+ - description: asrc3 output clock
+ - description: audio front end pd clock
+ - description: audio front end conn pd clock
+ - description: top audio a1 sys pd
+ - description: top audio a2 sys pd
+ - description: audio merge interface pd
+
+ clock-names:
+ items:
+ - const: infra_sys_audio_clk
+ - const: top_audio_mux1_sel
+ - const: top_audio_mux2_sel
+ - const: top_audio_a1sys_hp
+ - const: top_audio_a2sys_hp
+ - const: i2s0_src_sel
+ - const: i2s1_src_sel
+ - const: i2s2_src_sel
+ - const: i2s3_src_sel
+ - const: i2s0_src_div
+ - const: i2s1_src_div
+ - const: i2s2_src_div
+ - const: i2s3_src_div
+ - const: i2s0_mclk_en
+ - const: i2s1_mclk_en
+ - const: i2s2_mclk_en
+ - const: i2s3_mclk_en
+ - const: i2so0_hop_ck
+ - const: i2so1_hop_ck
+ - const: i2so2_hop_ck
+ - const: i2so3_hop_ck
+ - const: i2si0_hop_ck
+ - const: i2si1_hop_ck
+ - const: i2si2_hop_ck
+ - const: i2si3_hop_ck
+ - const: asrc0_out_ck
+ - const: asrc1_out_ck
+ - const: asrc2_out_ck
+ - const: asrc3_out_ck
+ - const: audio_afe_pd
+ - const: audio_afe_conn_pd
+ - const: audio_a1sys_pd
+ - const: audio_a2sys_pd
+ - const: audio_mrgif_pd
+
+required:
+ - compatible
+ - interrupts
+ - interrupt-names
+ - power-domains
+ - clocks
+ - clock-names
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
new file mode 100644
index 000000000000..cf985461a995
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt2701-wm8960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT2701 with WM8960 CODEC
+
+maintainers:
+ - Kartik Agarwala <agarwala.kartik@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mt2701-wm8960-machine
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT2701 ASoC platform.
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the WM8960 audio codec.
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - mediatek,platform
+ - audio-routing
+ - mediatek,audio-codec
+ - pinctrl-names
+ - pinctrl-0
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt2701-wm8960-machine";
+ mediatek,platform = <&afe>;
+ audio-routing =
+ "Headphone", "HP_L",
+ "Headphone", "HP_R",
+ "LINPUT1", "AMIC",
+ "RINPUT1", "AMIC";
+ mediatek,audio-codec = <&wm8960>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&aud_pins_default>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml
new file mode 100644
index 000000000000..398efdfe00f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-afe.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt7986-afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AFE PCM controller for MT7986
+
+maintainers:
+ - Maso Huang <maso.huang@mediatek.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt7986-afe
+ - items:
+ - enum:
+ - mediatek,mt7981-afe
+ - mediatek,mt7988-afe
+ - const: mediatek,mt7986-afe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 5
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ - description: mux for pcm_mck
+ - description: audio i2s/pcm mck
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+ - const: sel
+ - const: i2s_m
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7986-afe
+ then:
+ properties:
+ clocks:
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ clock-names:
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7981-afe
+ then:
+ properties:
+ clocks:
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ - description: mux for pcm_mck
+ clock-names:
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+ - const: sel
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7988-afe
+ then:
+ properties:
+ clocks:
+ items:
+ - description: audio bus clock
+ - description: audio 26M clock
+ - description: audio intbus clock
+ - description: audio hopping clock
+ - description: audio pll clock
+ - description: mux for pcm_mck
+ - description: audio i2s/pcm mck
+ clock-names:
+ items:
+ - const: bus_ck
+ - const: 26m_ck
+ - const: l_ck
+ - const: aud_ck
+ - const: eg2_ck
+ - const: sel
+ - const: i2s_m
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/mt7986-clk.h>
+
+ afe@11210000 {
+ compatible = "mediatek,mt7986-afe";
+ reg = <0x11210000 0x9000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&infracfg_ao CLK_INFRA_AUD_BUS_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_26M_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_L_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_AUD_CK>,
+ <&infracfg_ao CLK_INFRA_AUD_EG2_CK>;
+ clock-names = "bus_ck",
+ "26m_ck",
+ "l_ck",
+ "aud_ck",
+ "eg2_ck";
+ assigned-clocks = <&topckgen CLK_TOP_A1SYS_SEL>,
+ <&topckgen CLK_TOP_AUD_L_SEL>,
+ <&topckgen CLK_TOP_A_TUNER_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_APLL2_D4>,
+ <&apmixedsys CLK_APMIXED_APLL2>,
+ <&topckgen CLK_TOP_APLL2_D4>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml
new file mode 100644
index 000000000000..09247ceea3f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt7986-wm8960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT7986 sound card with WM8960 codec
+
+maintainers:
+ - Maso Huang <maso.huang@mediatek.com>
+
+allOf:
+ - $ref: sound-card-common.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt7986-wm8960-sound
+
+ platform:
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ description: The phandle of MT7986 platform.
+ maxItems: 1
+ required:
+ - sound-dai
+
+ codec:
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ description: The phandle of wm8960 codec.
+ maxItems: 1
+ required:
+ - sound-dai
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - audio-routing
+ - platform
+ - codec
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt7986-wm8960-sound";
+ model = "mt7986-wm8960";
+ audio-routing =
+ "Headphone", "HP_L",
+ "Headphone", "HP_R",
+ "LINPUT1", "AMIC",
+ "RINPUT1", "AMIC";
+
+ platform {
+ sound-dai = <&afe>;
+ };
+
+ codec {
+ sound-dai = <&wm8960>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8173-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8173-afe-pcm.yaml
new file mode 100644
index 000000000000..d8993b5d457a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8173-afe-pcm.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8173-afe-pcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek AFE PCM controller for MT8173
+
+maintainers:
+ - Trevor Wu <trevor.wu@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8173-afe-pcm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: audio infra sys clock
+ - description: audio top mux
+ - description: audio intbus mux
+ - description: apll1 clock
+ - description: apll2 clock
+ - description: i2s0 mclk mux
+ - description: i2s1 mclk mux
+ - description: i2s2 mclk mux
+ - description: i2s3 mclk mux
+ - description: i2s3 bclk mux
+
+ clock-names:
+ items:
+ - const: infra_sys_audio_clk
+ - const: top_pdn_audio
+ - const: top_pdn_aud_intbus
+ - const: bck0
+ - const: bck1
+ - const: i2s0_m
+ - const: i2s1_m
+ - const: i2s2_m
+ - const: i2s3_m
+ - const: i2s3_b
+
+ power-domains:
+ maxItems: 1
+
+ memory-region:
+ description: memory region for audio DMA buffers
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/mt8173-power.h>
+
+ mt8173-afe-pcm@11220000 {
+ compatible = "mediatek,mt8173-afe-pcm";
+ reg = <0x11220000 0x1000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_FALLING>;
+ power-domains = <&spm MT8173_POWER_DOMAIN_AUDIO>;
+ clocks = <&infracfg CLK_INFRA_AUDIO>,
+ <&topckgen CLK_TOP_AUDIO_SEL>,
+ <&topckgen CLK_TOP_AUD_INTBUS_SEL>,
+ <&topckgen CLK_TOP_APLL1_DIV0>,
+ <&topckgen CLK_TOP_APLL2_DIV0>,
+ <&topckgen CLK_TOP_I2S0_M_SEL>,
+ <&topckgen CLK_TOP_I2S1_M_SEL>,
+ <&topckgen CLK_TOP_I2S2_M_SEL>,
+ <&topckgen CLK_TOP_I2S3_M_SEL>,
+ <&topckgen CLK_TOP_I2S3_B_SEL>;
+ clock-names = "infra_sys_audio_clk",
+ "top_pdn_audio",
+ "top_pdn_aud_intbus",
+ "bck0",
+ "bck1",
+ "i2s0_m",
+ "i2s1_m",
+ "i2s2_m",
+ "i2s3_m",
+ "i2s3_b";
+ memory-region = <&afe_dma_mem>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8183-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8183-audio.yaml
new file mode 100644
index 000000000000..031b0fa7b4dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8183-audio.yaml
@@ -0,0 +1,228 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8183-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek AFE PCM controller for mt8183
+
+maintainers:
+ - Julien Massot <jmassot@collabora.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8183-audio
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: audiosys
+
+ power-domains:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: AFE clock
+ - description: ADDA DAC clock
+ - description: ADDA DAC pre-distortion clock
+ - description: ADDA ADC clock
+ - description: ADDA6 ADC clock
+ - description: Audio low-jitter 22.5792m clock
+ - description: Audio low-jitter 24.576m clock
+ - description: Audio PLL1 tuner clock
+ - description: Audio PLL2 tuner clock
+ - description: I2S1 bit clock
+ - description: I2S2 bit clock
+ - description: I2S3 bit clock
+ - description: I2S4 bit clock
+ - description: Audio Time-Division Multiplexing interface clock
+ - description: Powerdown Audio test model clock
+ - description: Audio infra sys clock
+ - description: Audio infra 26M clock
+ - description: Mux for audio clock
+ - description: Mux for audio internal bus clock
+ - description: Mux main divider by 4
+ - description: Primary audio mux
+ - description: Primary audio PLL
+ - description: Secondary audio mux
+ - description: Secondary audio PLL
+ - description: Primary audio en-generator clock
+ - description: Primary PLL divider by 4 for IEC
+ - description: Secondary audio en-generator clock
+ - description: Secondary PLL divider by 8 for IEC
+ - description: Mux selector for I2S port 0
+ - description: Mux selector for I2S port 1
+ - description: Mux selector for I2S port 2
+ - description: Mux selector for I2S port 3
+ - description: Mux selector for I2S port 4
+ - description: Mux selector for I2S port 5
+ - description: APLL1 and APLL2 divider for I2S port 0
+ - description: APLL1 and APLL2 divider for I2S port 1
+ - description: APLL1 and APLL2 divider for I2S port 2
+ - description: APLL1 and APLL2 divider for I2S port 3
+ - description: APLL1 and APLL2 divider for I2S port 4
+ - description: APLL1 and APLL2 divider for IEC
+ - description: 26MHz clock for audio subsystem
+
+ clock-names:
+ items:
+ - const: aud_afe_clk
+ - const: aud_dac_clk
+ - const: aud_dac_predis_clk
+ - const: aud_adc_clk
+ - const: aud_adc_adda6_clk
+ - const: aud_apll22m_clk
+ - const: aud_apll24m_clk
+ - const: aud_apll1_tuner_clk
+ - const: aud_apll2_tuner_clk
+ - const: aud_i2s1_bclk_sw
+ - const: aud_i2s2_bclk_sw
+ - const: aud_i2s3_bclk_sw
+ - const: aud_i2s4_bclk_sw
+ - const: aud_tdm_clk
+ - const: aud_tml_clk
+ - const: aud_infra_clk
+ - const: mtkaif_26m_clk
+ - const: top_mux_audio
+ - const: top_mux_aud_intbus
+ - const: top_syspll_d2_d4
+ - const: top_mux_aud_1
+ - const: top_apll1_ck
+ - const: top_mux_aud_2
+ - const: top_apll2_ck
+ - const: top_mux_aud_eng1
+ - const: top_apll1_d8
+ - const: top_mux_aud_eng2
+ - const: top_apll2_d8
+ - const: top_i2s0_m_sel
+ - const: top_i2s1_m_sel
+ - const: top_i2s2_m_sel
+ - const: top_i2s3_m_sel
+ - const: top_i2s4_m_sel
+ - const: top_i2s5_m_sel
+ - const: top_apll12_div0
+ - const: top_apll12_div1
+ - const: top_apll12_div2
+ - const: top_apll12_div3
+ - const: top_apll12_div4
+ - const: top_apll12_divb
+ - const: top_clk26m_clk
+
+required:
+ - compatible
+ - interrupts
+ - resets
+ - reset-names
+ - power-domains
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/mt8183-power.h>
+ #include <dt-bindings/reset/mt8183-resets.h>
+
+ audio-controller {
+ compatible = "mediatek,mt8183-audio";
+ interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_LOW>;
+ resets = <&watchdog MT8183_TOPRGU_AUDIO_SW_RST>;
+ reset-names = "audiosys";
+ power-domains = <&spm MT8183_POWER_DOMAIN_AUDIO>;
+ clocks = <&audiosys CLK_AUDIO_AFE>,
+ <&audiosys CLK_AUDIO_DAC>,
+ <&audiosys CLK_AUDIO_DAC_PREDIS>,
+ <&audiosys CLK_AUDIO_ADC>,
+ <&audiosys CLK_AUDIO_PDN_ADDA6_ADC>,
+ <&audiosys CLK_AUDIO_22M>,
+ <&audiosys CLK_AUDIO_24M>,
+ <&audiosys CLK_AUDIO_APLL_TUNER>,
+ <&audiosys CLK_AUDIO_APLL2_TUNER>,
+ <&audiosys CLK_AUDIO_I2S1>,
+ <&audiosys CLK_AUDIO_I2S2>,
+ <&audiosys CLK_AUDIO_I2S3>,
+ <&audiosys CLK_AUDIO_I2S4>,
+ <&audiosys CLK_AUDIO_TDM>,
+ <&audiosys CLK_AUDIO_TML>,
+ <&infracfg CLK_INFRA_AUDIO>,
+ <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
+ <&topckgen CLK_TOP_MUX_AUDIO>,
+ <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
+ <&topckgen CLK_TOP_SYSPLL_D2_D4>,
+ <&topckgen CLK_TOP_MUX_AUD_1>,
+ <&topckgen CLK_TOP_APLL1_CK>,
+ <&topckgen CLK_TOP_MUX_AUD_2>,
+ <&topckgen CLK_TOP_APLL2_CK>,
+ <&topckgen CLK_TOP_MUX_AUD_ENG1>,
+ <&topckgen CLK_TOP_APLL1_D8>,
+ <&topckgen CLK_TOP_MUX_AUD_ENG2>,
+ <&topckgen CLK_TOP_APLL2_D8>,
+ <&topckgen CLK_TOP_MUX_APLL_I2S0>,
+ <&topckgen CLK_TOP_MUX_APLL_I2S1>,
+ <&topckgen CLK_TOP_MUX_APLL_I2S2>,
+ <&topckgen CLK_TOP_MUX_APLL_I2S3>,
+ <&topckgen CLK_TOP_MUX_APLL_I2S4>,
+ <&topckgen CLK_TOP_MUX_APLL_I2S5>,
+ <&topckgen CLK_TOP_APLL12_DIV0>,
+ <&topckgen CLK_TOP_APLL12_DIV1>,
+ <&topckgen CLK_TOP_APLL12_DIV2>,
+ <&topckgen CLK_TOP_APLL12_DIV3>,
+ <&topckgen CLK_TOP_APLL12_DIV4>,
+ <&topckgen CLK_TOP_APLL12_DIVB>,
+ <&clk26m>;
+ clock-names = "aud_afe_clk",
+ "aud_dac_clk",
+ "aud_dac_predis_clk",
+ "aud_adc_clk",
+ "aud_adc_adda6_clk",
+ "aud_apll22m_clk",
+ "aud_apll24m_clk",
+ "aud_apll1_tuner_clk",
+ "aud_apll2_tuner_clk",
+ "aud_i2s1_bclk_sw",
+ "aud_i2s2_bclk_sw",
+ "aud_i2s3_bclk_sw",
+ "aud_i2s4_bclk_sw",
+ "aud_tdm_clk",
+ "aud_tml_clk",
+ "aud_infra_clk",
+ "mtkaif_26m_clk",
+ "top_mux_audio",
+ "top_mux_aud_intbus",
+ "top_syspll_d2_d4",
+ "top_mux_aud_1",
+ "top_apll1_ck",
+ "top_mux_aud_2",
+ "top_apll2_ck",
+ "top_mux_aud_eng1",
+ "top_apll1_d8",
+ "top_mux_aud_eng2",
+ "top_apll2_d8",
+ "top_i2s0_m_sel",
+ "top_i2s1_m_sel",
+ "top_i2s2_m_sel",
+ "top_i2s3_m_sel",
+ "top_i2s4_m_sel",
+ "top_i2s5_m_sel",
+ "top_apll12_div0",
+ "top_apll12_div1",
+ "top_apll12_div2",
+ "top_apll12_div3",
+ "top_apll12_div4",
+ "top_apll12_divb",
+ "top_clk26m_clk";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8183_da7219.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8183_da7219.yaml
new file mode 100644
index 000000000000..b526e8123182
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8183_da7219.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8183_da7219.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8183 sound card with external codecs
+
+maintainers:
+ - Julien Massot <jmassot@collabora.com>
+
+description:
+ MediaTek MT8183 SoC-based sound cards with DA7219 as headset codec,
+ and MAX98357A, RT1015 or RT1015P as speaker amplifiers. Optionally includes HDMI codec.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8183_da7219_max98357
+ - mediatek,mt8183_da7219_rt1015
+ - mediatek,mt8183_da7219_rt1015p
+
+ mediatek,headset-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the DA7219 headset codec.
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the MT8183 ASoC platform (e.g., AFE node).
+
+ mediatek,hdmi-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Optional phandle to the HDMI codec (e.g., IT6505).
+
+required:
+ - compatible
+ - mediatek,headset-codec
+ - mediatek,platform
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8183_da7219_max98357";
+ mediatek,headset-codec = <&da7219>;
+ mediatek,hdmi-codec = <&it6505dptx>;
+ mediatek,platform = <&afe>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8183_mt6358_ts3a227.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8183_mt6358_ts3a227.yaml
new file mode 100644
index 000000000000..43a6f9d40644
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8183_mt6358_ts3a227.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8183_mt6358_ts3a227.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8183 sound card with MT6358, TS3A227, and MAX98357/RT1015 codecs
+
+maintainers:
+ - Julien Massot <julien.massot@collabora.com>
+
+description:
+ MediaTek MT8183 SoC-based sound cards using the MT6358 codec,
+ with optional TS3A227 headset codec, EC codec (via Chrome EC), and HDMI audio.
+ Speaker amplifier can be one of MAX98357A/B, RT1015, or RT1015P.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8183_mt6358_ts3a227_max98357
+ - mediatek,mt8183_mt6358_ts3a227_max98357b
+ - mediatek,mt8183_mt6358_ts3a227_rt1015
+ - mediatek,mt8183_mt6358_ts3a227_rt1015p
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the MT8183 ASoC platform node (e.g., AFE).
+
+ mediatek,headset-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the TS3A227 headset codec.
+
+ mediatek,ec-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Optional phandle to a ChromeOS EC codec node.
+ See bindings in google,cros-ec-codec.yaml.
+
+ mediatek,hdmi-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Optional phandle to an HDMI audio codec node.
+
+required:
+ - compatible
+ - mediatek,platform
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8183_mt6358_ts3a227_max98357";
+ mediatek,headset-codec = <&ts3a227>;
+ mediatek,ec-codec = <&ec_codec>;
+ mediatek,hdmi-codec = <&it6505dptx>;
+ mediatek,platform = <&afe>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
new file mode 100644
index 000000000000..77af276ed2a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
@@ -0,0 +1,241 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8188-afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AFE PCM controller for mt8188
+
+maintainers:
+ - Trevor Wu <trevor.wu@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8188-afe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: audiosys
+
+ memory-region:
+ maxItems: 1
+ description: |
+ Shared memory region for AFE memif. A "shared-dma-pool".
+ See dtschema reserved-memory/shared-dma-pool.yaml for details.
+
+ mediatek,topckgen:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the mediatek topckgen controller
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the mediatek infracfg controller
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: 26M clock
+ - description: audio pll1 clock
+ - description: audio pll2 clock
+ - description: clock divider for i2si1_mck
+ - description: clock divider for i2si2_mck
+ - description: clock divider for i2so1_mck
+ - description: clock divider for i2so2_mck
+ - description: clock divider for dptx_mck
+ - description: a1sys hoping clock
+ - description: audio intbus clock
+ - description: audio hires clock
+ - description: audio local bus clock
+ - description: mux for dptx_mck
+ - description: mux for i2so1_mck
+ - description: mux for i2so2_mck
+ - description: mux for i2si1_mck
+ - description: mux for i2si2_mck
+ - description: audio 26m clock
+ - description: audio pll1 divide 4
+ - description: audio pll2 divide 4
+ - description: clock divider for iec
+ - description: mux for a2sys clock
+ - description: mux for aud_iec
+
+ clock-names:
+ items:
+ - const: clk26m
+ - const: apll1
+ - const: apll2
+ - const: apll12_div0
+ - const: apll12_div1
+ - const: apll12_div2
+ - const: apll12_div3
+ - const: apll12_div9
+ - const: top_a1sys_hp
+ - const: top_aud_intbus
+ - const: top_audio_h
+ - const: top_audio_local_bus
+ - const: top_dptx
+ - const: top_i2so1
+ - const: top_i2so2
+ - const: top_i2si1
+ - const: top_i2si2
+ - const: adsp_audio_26m
+ - const: apll1_d4
+ - const: apll2_d4
+ - const: apll12_div4
+ - const: top_a2sys
+ - const: top_aud_iec
+
+ mediatek,etdm-in1-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm in module.
+ enum:
+ - 1 # etdm2_in
+ - 2 # etdm1_out
+ - 3 # etdm2_out
+
+ mediatek,etdm-in2-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm in module.
+ enum:
+ - 0 # etdm1_in
+ - 2 # etdm1_out
+ - 3 # etdm2_out
+
+ mediatek,etdm-out1-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm out module.
+ enum:
+ - 0 # etdm1_in
+ - 1 # etdm2_in
+ - 3 # etdm2_out
+
+ mediatek,etdm-out2-cowork-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ etdm modules can share the same external clock pin. Specify
+ which etdm clock source is required by this etdm out module.
+ enum:
+ - 0 # etdm1_in
+ - 1 # etdm2_in
+ - 2 # etdm1_out
+
+patternProperties:
+ "^mediatek,etdm-in[1-2]-chn-disabled$":
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 1
+ maxItems: 16
+ description:
+ This is a list of channel IDs which should be disabled.
+ By default, all data received from ETDM pins will be outputted to
+ memory. etdm in supports disable_out in direct mode(w/o interconn),
+ so user can disable the specified channels by the property.
+ uniqueItems: true
+ items:
+ minimum: 0
+ maximum: 15
+
+ "^mediatek,etdm-in[1-2]-multi-pin-mode$":
+ type: boolean
+ description: if present, the etdm data mode is I2S.
+
+ "^mediatek,etdm-out[1-3]-multi-pin-mode$":
+ type: boolean
+ description: if present, the etdm data mode is I2S.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+ - reset-names
+ - mediatek,topckgen
+ - mediatek,infracfg
+ - power-domains
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ afe@10b10000 {
+ compatible = "mediatek,mt8188-afe";
+ reg = <0x10b10000 0x10000>;
+ interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>;
+ resets = <&watchdog 14>;
+ reset-names = "audiosys";
+ memory-region = <&snd_dma_mem_reserved>;
+ mediatek,topckgen = <&topckgen>;
+ mediatek,infracfg = <&infracfg_ao>;
+ power-domains = <&spm 13>; //MT8188_POWER_DOMAIN_AUDIO
+ mediatek,etdm-in2-cowork-source = <2>;
+ mediatek,etdm-out2-cowork-source = <0>;
+ mediatek,etdm-in1-multi-pin-mode;
+ mediatek,etdm-in1-chn-disabled = /bits/ 8 <0x0 0x2>;
+ clocks = <&clk26m>,
+ <&apmixedsys 9>, //CLK_APMIXED_APLL1
+ <&apmixedsys 10>, //CLK_APMIXED_APLL2
+ <&topckgen 186>, //CLK_TOP_APLL12_CK_DIV0
+ <&topckgen 187>, //CLK_TOP_APLL12_CK_DIV1
+ <&topckgen 188>, //CLK_TOP_APLL12_CK_DIV2
+ <&topckgen 189>, //CLK_TOP_APLL12_CK_DIV3
+ <&topckgen 191>, //CLK_TOP_APLL12_CK_DIV9
+ <&topckgen 83>, //CLK_TOP_A1SYS_HP
+ <&topckgen 31>, //CLK_TOP_AUD_INTBUS
+ <&topckgen 32>, //CLK_TOP_AUDIO_H
+ <&topckgen 69>, //CLK_TOP_AUDIO_LOCAL_BUS
+ <&topckgen 81>, //CLK_TOP_DPTX
+ <&topckgen 77>, //CLK_TOP_I2SO1
+ <&topckgen 78>, //CLK_TOP_I2SO2
+ <&topckgen 79>, //CLK_TOP_I2SI1
+ <&topckgen 80>, //CLK_TOP_I2SI2
+ <&adsp_audio26m 0>, //CLK_AUDIODSP_AUDIO26M
+ <&topckgen 132>, //CLK_TOP_APLL1_D4
+ <&topckgen 133>, //CLK_TOP_APLL2_D4
+ <&topckgen 183>, //CLK_TOP_APLL12_CK_DIV4
+ <&topckgen 84>, //CLK_TOP_A2SYS
+ <&topckgen 82>; //CLK_TOP_AUD_IEC>;
+ clock-names = "clk26m",
+ "apll1",
+ "apll2",
+ "apll12_div0",
+ "apll12_div1",
+ "apll12_div2",
+ "apll12_div3",
+ "apll12_div9",
+ "top_a1sys_hp",
+ "top_aud_intbus",
+ "top_audio_h",
+ "top_audio_local_bus",
+ "top_dptx",
+ "top_i2so1",
+ "top_i2so2",
+ "top_i2si1",
+ "top_i2si2",
+ "adsp_audio_26m",
+ "apll1_d4",
+ "apll2_d4",
+ "apll12_div4",
+ "top_a2sys",
+ "top_aud_iec";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
new file mode 100644
index 000000000000..7ba2ea2dfa0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8188-mt6359.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8188 ASoC sound card
+
+maintainers:
+ - Trevor Wu <trevor.wu@mediatek.com>
+
+allOf:
+ - $ref: sound-card-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt8188-es8326
+ - mediatek,mt8188-mt6359-evb
+ - mediatek,mt8188-nau8825
+ - mediatek,mt8188-rt5682s
+ - items:
+ - const: mediatek,mt8390-mt6359-evk
+ - const: mediatek,mt8188-mt6359-evb
+
+ audio-routing:
+ description:
+ Valid names could be the input or output widgets of audio components,
+ power supplies, MicBias of codec and the software switch.
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT8188 ASoC platform.
+
+ mediatek,adsp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle of the MT8188 ADSP platform, which is the optional Audio DSP
+ hardware that provides additional audio functionalities if present.
+ The AFE will link to ADSP when the phandle is provided.
+
+ mediatek,accdet:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle to the MT6359 accessory detection block, which detects audio
+ jack insertion and removal. This property should only be present if the
+ accdet block is actually wired to the audio jack pins and to be used for
+ jack detection.
+
+patternProperties:
+ "^dai-link-[0-9]+$":
+ type: object
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description:
+ This property corresponds to the name of the BE dai-link to which
+ we are going to update parameters in this node.
+ items:
+ enum:
+ - DPTX_BE
+ - ETDM1_IN_BE
+ - ETDM2_IN_BE
+ - ETDM1_OUT_BE
+ - ETDM2_OUT_BE
+ - ETDM3_OUT_BE
+ - PCM1_BE
+ - DL_SRC_BE
+ - UL_SRC_BE
+ - DMIC_BE
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ dai-format:
+ description: audio format.
+ items:
+ enum:
+ - i2s
+ - right_j
+ - left_j
+ - dsp_a
+ - dsp_b
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ enum:
+ - cpu
+ - codec
+
+ additionalProperties: false
+
+ required:
+ - link-name
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - mediatek,platform
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8188-mt6359-evb";
+ model = "MT6359-EVB";
+ mediatek,platform = <&afe>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&aud_pins_default>;
+ audio-routing =
+ "Headphone", "Headphone L",
+ "Headphone", "Headphone R",
+ "AIN1", "Headset Mic";
+ dai-link-0 {
+ link-name = "ETDM3_OUT_BE";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&hdmi0>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8189-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8189-afe-pcm.yaml
new file mode 100644
index 000000000000..9c9f21652af9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8189-afe-pcm.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8189-afe-pcm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Audio Front End PCM controller for MT8189
+
+maintainers:
+ - Darren Ye <darren.ye@mediatek.com>
+ - Cyril Chao <cyril.chao@mediatek.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8189-afe-pcm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ memory-region:
+ maxItems: 1
+
+ mediatek,apmixedsys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: To set up the apll12 tuner
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: mux for audio intbus
+ - description: mux for audio engen1
+ - description: mux for audio engen2
+ - description: mux for audio h
+ - description: audio apll1 clock
+ - description: audio apll2 clock
+ - description: audio apll1 divide4
+ - description: audio apll2 divide4
+ - description: audio apll12 divide for i2sin0
+ - description: audio apll12 divide for i2sin1
+ - description: audio apll12 divide for i2sout0
+ - description: audio apll12 divide for i2sout1
+ - description: audio apll12 divide for fmi2s
+ - description: audio apll12 divide for tdmout mck
+ - description: audio apll12 divide for tdmout bck
+ - description: mux for audio apll1
+ - description: mux for audio apll2
+ - description: mux for i2sin0 mck
+ - description: mux for i2sin1 mck
+ - description: mux for i2sout0 mck
+ - description: mux for i2sout1 mck
+ - description: mux for fmi2s mck
+ - description: mux for tdmout mck
+ - description: 26m clock
+ - description: audio slv clock
+ - description: audio mst clock
+ - description: audio intbus clock
+
+ clock-names:
+ items:
+ - const: top_aud_intbus
+ - const: top_aud_eng1
+ - const: top_aud_eng2
+ - const: top_aud_h
+ - const: apll1
+ - const: apll2
+ - const: apll1_d4
+ - const: apll2_d4
+ - const: apll12_div_i2sin0
+ - const: apll12_div_i2sin1
+ - const: apll12_div_i2sout0
+ - const: apll12_div_i2sout1
+ - const: apll12_div_fmi2s
+ - const: apll12_div_tdmout_m
+ - const: apll12_div_tdmout_b
+ - const: top_apll1
+ - const: top_apll2
+ - const: top_i2sin0
+ - const: top_i2sin1
+ - const: top_i2sout0
+ - const: top_i2sout1
+ - const: top_fmi2s
+ - const: top_dptx
+ - const: clk26m
+ - const: aud_slv_ck_peri
+ - const: aud_mst_ck_peri
+ - const: aud_intbus_ck_peri
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - memory-region
+ - power-domains
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ afe@11050000 {
+ compatible = "mediatek,mt8189-afe-pcm";
+ reg = <0 0x11050000 0 0x10000>;
+ interrupts = <GIC_SPI 392 IRQ_TYPE_LEVEL_HIGH 0>;
+ memory-region = <&afe_dma_mem_reserved>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&aud_pins_default>;
+ power-domains = <&scpsys 1>; //MT8189_POWER_DOMAIN_AUDIO
+ clocks = <&topckgen_clk 23>, //CLK_TOP_AUD_INTBUS_SEL
+ <&topckgen_clk 39>, //CLK_TOP_AUD_ENGEN1_SEL
+ <&topckgen_clk 40>, //CLK_TOP_AUD_ENGEN2_SEL
+ <&topckgen_clk 49>, //CLK_TOP_AUDIO_H_SEL
+ <&topckgen_clk 146>, //CLK_TOP_APLL1
+ <&topckgen_clk 151>, //CLK_TOP_APLL2
+ <&topckgen_clk 148>, //CLK_TOP_APLL1_D4
+ <&topckgen_clk 153>, //CLK_TOP_APLL2_D4
+ <&topckgen_clk 93>, //CLK_TOP_APLL12_CK_DIV_I2SIN0
+ <&topckgen_clk 94>, //CLK_TOP_APLL12_CK_DIV_I2SIN1
+ <&topckgen_clk 95>, //CLK_TOP_APLL12_CK_DIV_I2SOUT0
+ <&topckgen_clk 96>, //CLK_TOP_APLL12_CK_DIV_I2SOUT1
+ <&topckgen_clk 97>, //CLK_TOP_APLL12_CK_DIV_FMI2S
+ <&topckgen_clk 98>, //CLK_TOP_APLL12_CK_DIV_TDMOUT_M
+ <&topckgen_clk 99>, //CLK_TOP_APLL12_CK_DIV_TDMOUT_B
+ <&topckgen_clk 44>, //CLK_TOP_AUD_1_SEL
+ <&topckgen_clk 45>, //CLK_TOP_AUD_2_SEL
+ <&topckgen_clk 78>, //CLK_TOP_APLL_I2SIN0_MCK_SEL
+ <&topckgen_clk 79>, //CLK_TOP_APLL_I2SIN1_MCK_SEL
+ <&topckgen_clk 84>, //CLK_TOP_APLL_I2SOUT0_MCK_SEL
+ <&topckgen_clk 85>, //CLK_TOP_APLL_I2SOUT1_MCK_SEL
+ <&topckgen_clk 90>, //CLK_TOP_APLL_FMI2S_MCK_SEL
+ <&topckgen_clk 91>, //CLK_TOP_APLL_TDMOUT_MCK_SEL
+ <&topckgen_clk 191>, //CLK_TOP_TCK_26M_MX9
+ <&pericfg_ao_clk 77>, //CLK_PERAO_AUDIO0
+ <&pericfg_ao_clk 78>, //CLK_PERAO_AUDIO1
+ <&pericfg_ao_clk 79>; //CLK_PERAO_AUDIO2
+ clock-names = "top_aud_intbus",
+ "top_aud_eng1",
+ "top_aud_eng2",
+ "top_aud_h",
+ "apll1",
+ "apll2",
+ "apll1_d4",
+ "apll2_d4",
+ "apll12_div_i2sin0",
+ "apll12_div_i2sin1",
+ "apll12_div_i2sout0",
+ "apll12_div_i2sout1",
+ "apll12_div_fmi2s",
+ "apll12_div_tdmout_m",
+ "apll12_div_tdmout_b",
+ "top_apll1",
+ "top_apll2",
+ "top_i2sin0",
+ "top_i2sin1",
+ "top_i2sout0",
+ "top_i2sout1",
+ "top_fmi2s",
+ "top_dptx",
+ "clk26m",
+ "aud_slv_ck_peri",
+ "aud_mst_ck_peri",
+ "aud_intbus_ck_peri";
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8189-nau8825.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8189-nau8825.yaml
new file mode 100644
index 000000000000..dd9ee0a3b292
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8189-nau8825.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8189-nau8825.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8189 ASoC sound card
+
+maintainers:
+ - Darren Ye <darren.ye@mediatek.com>
+ - Cyril Chao <cyril.chao@mediatek.com>
+
+allOf:
+ - $ref: sound-card-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt8189-nau8825
+ - mediatek,mt8189-rt5650
+ - mediatek,mt8189-rt5682s
+ - mediatek,mt8189-rt5682i
+ - mediatek,mt8189-es8326
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT8189 ASoC platform.
+
+patternProperties:
+ "^dai-link-[0-9]+$":
+ type: object
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description:
+ This property corresponds to the name of the BE dai-link to which
+ we are going to update parameters in this node.
+ enum:
+ - TDM_DPTX_BE
+ - I2SOUT0_BE
+ - I2SIN0_BE
+ - I2SOUT1_BE
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ dai-format:
+ description: audio format.
+ enum:
+ - i2s
+ - right_j
+ - left_j
+ - dsp_a
+ - dsp_b
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ enum:
+ - cpu
+ - codec
+
+ additionalProperties: false
+
+ required:
+ - link-name
+
+required:
+ - compatible
+ - mediatek,platform
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8189-nau8825";
+ model = "mt8189_rt9123_8825";
+ mediatek,platform = <&afe>;
+ dai-link-0 {
+ link-name = "I2SOUT1_BE";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&nau8825>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml
new file mode 100644
index 000000000000..45ad56d37234
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8365-afe.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8365-afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Audio Front End PCM controller for MT8365
+
+maintainers:
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8365-afe-pcm
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: 26M clock
+ - description: mux for audio clock
+ - description: audio i2s0 mck
+ - description: audio i2s1 mck
+ - description: audio i2s2 mck
+ - description: audio i2s3 mck
+ - description: engen 1 clock
+ - description: engen 2 clock
+ - description: audio 1 clock
+ - description: audio 2 clock
+ - description: mux for i2s0
+ - description: mux for i2s1
+ - description: mux for i2s2
+ - description: mux for i2s3
+
+ clock-names:
+ items:
+ - const: top_clk26m_clk
+ - const: top_audio_sel
+ - const: audio_i2s0_m
+ - const: audio_i2s1_m
+ - const: audio_i2s2_m
+ - const: audio_i2s3_m
+ - const: engen1
+ - const: engen2
+ - const: aud1
+ - const: aud2
+ - const: i2s0_m_sel
+ - const: i2s1_m_sel
+ - const: i2s2_m_sel
+ - const: i2s3_m_sel
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ mediatek,dmic-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Indicates how many data pins are used to transmit two channels of PDM
+ signal. 1 means two wires, 0 means one wire. Default value is 0.
+ enum:
+ - 0 # one wire
+ - 1 # two wires
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mediatek,mt8365-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/power/mediatek,mt8365-power.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ audio-controller@11220000 {
+ compatible = "mediatek,mt8365-afe-pcm";
+ reg = <0 0x11220000 0 0x1000>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk26m>,
+ <&topckgen CLK_TOP_AUDIO_SEL>,
+ <&topckgen CLK_TOP_AUD_I2S0_M>,
+ <&topckgen CLK_TOP_AUD_I2S1_M>,
+ <&topckgen CLK_TOP_AUD_I2S2_M>,
+ <&topckgen CLK_TOP_AUD_I2S3_M>,
+ <&topckgen CLK_TOP_AUD_ENGEN1_SEL>,
+ <&topckgen CLK_TOP_AUD_ENGEN2_SEL>,
+ <&topckgen CLK_TOP_AUD_1_SEL>,
+ <&topckgen CLK_TOP_AUD_2_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S0_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S1_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S2_SEL>,
+ <&topckgen CLK_TOP_APLL_I2S3_SEL>;
+ clock-names = "top_clk26m_clk",
+ "top_audio_sel",
+ "audio_i2s0_m",
+ "audio_i2s1_m",
+ "audio_i2s2_m",
+ "audio_i2s3_m",
+ "engen1",
+ "engen2",
+ "aud1",
+ "aud2",
+ "i2s0_m_sel",
+ "i2s1_m_sel",
+ "i2s2_m_sel",
+ "i2s3_m_sel";
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8365_POWER_DOMAIN_AUDIO>;
+ mediatek,dmic-mode = <1>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml
new file mode 100644
index 000000000000..ff9ebb63a05f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt8365-mt6357.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8365 ASoC sound card
+
+maintainers:
+ - Alexandre Mergnat <amergnat@baylibre.com>
+
+properties:
+ compatible:
+ const: mediatek,mt8365-mt6357
+
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: dmic
+ - const: miso_off
+ - const: miso_on
+ - const: mosi_off
+ - const: mosi_on
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT8365 ASoC platform.
+
+patternProperties:
+ "^dai-link-[0-9]+$":
+ type: object
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ codec:
+ type: object
+ description: Holds subnode which indicates codec dai.
+
+ properties:
+ sound-dai:
+ maxItems: 1
+ description: phandle of the codec DAI
+
+ additionalProperties: false
+
+ link-name:
+ description: Indicates dai-link name and PCM stream name
+ enum:
+ - I2S_IN_BE
+ - I2S_OUT_BE
+ - PCM1_BE
+ - PDM1_BE
+ - PDM2_BE
+ - PDM3_BE
+ - PDM4_BE
+ - SPDIF_IN_BE
+ - SPDIF_OUT_BE
+ - TDM_IN_BE
+ - TDM_OUT_BE
+
+ sound-dai:
+ maxItems: 1
+ description: phandle of the CPU DAI
+
+ required:
+ - link-name
+ - sound-dai
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - pinctrl-names
+ - mediatek,platform
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt8365-mt6357";
+ pinctrl-names = "default",
+ "dmic",
+ "miso_off",
+ "miso_on",
+ "mosi_off",
+ "mosi_on";
+ pinctrl-0 = <&aud_default_pins>;
+ pinctrl-1 = <&aud_dmic_pins>;
+ pinctrl-2 = <&aud_miso_off_pins>;
+ pinctrl-3 = <&aud_miso_on_pins>;
+ pinctrl-4 = <&aud_mosi_off_pins>;
+ pinctrl-5 = <&aud_mosi_on_pins>;
+ mediatek,platform = <&afe>;
+
+ /* hdmi interface */
+ dai-link-0 {
+ link-name = "I2S_OUT_BE";
+ sound-dai = <&afe>;
+
+ codec {
+ sound-dai = <&it66121hdmitx>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml
deleted file mode 100644
index 04414eb4ada9..000000000000
--- a/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml
+++ /dev/null
@@ -1,100 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/microchip,pdmc.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Microchip Pulse Density Microphone Controller
-
-maintainers:
- - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
-
-description:
- The Microchip Pulse Density Microphone Controller (PDMC) interfaces up to 4
- digital microphones having Pulse Density Modulated (PDM) outputs.
-
-properties:
- compatible:
- const: microchip,sama7g5-pdmc
-
- reg:
- maxItems: 1
-
- "#sound-dai-cells":
- const: 0
-
- interrupts:
- maxItems: 1
-
- clocks:
- items:
- - description: Peripheral Bus Clock
- - description: Generic Clock
-
- clock-names:
- items:
- - const: pclk
- - const: gclk
-
- dmas:
- description: RX DMA Channel
- maxItems: 1
-
- dma-names:
- const: rx
-
- microchip,mic-pos:
- description: |
- Position of PDM microphones on the DS line and the sampling edge (rising
- or falling) of the CLK line. A microphone is represented as a pair of DS
- line and the sampling edge. The first microphone is mapped to channel 0,
- the second to channel 1, etc.
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
- items:
- - description: value for DS line
- - description: value for sampling edge
- anyOf:
- - enum:
- - [0, 0]
- - [0, 1]
- - [1, 0]
- - [1, 1]
- minItems: 1
- maxItems: 4
- uniqueItems: true
-
-required:
- - compatible
- - reg
- - "#sound-dai-cells"
- - interrupts
- - clocks
- - clock-names
- - dmas
- - dma-names
- - microchip,mic-pos
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/clock/at91.h>
- #include <dt-bindings/dma/at91.h>
- #include <dt-bindings/interrupt-controller/arm-gic.h>
- #include <dt-bindings/sound/microchip,pdmc.h>
-
- pdmc: sound@e1608000 {
- compatible = "microchip,sama7g5-pdmc";
- reg = <0xe1608000 0x4000>;
- #sound-dai-cells = <0>;
- interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
- dmas = <&dma0 AT91_XDMAC_DT_PERID(37)>;
- dma-names = "rx";
- clocks = <&pmc PMC_TYPE_PERIPHERAL 68>, <&pmc PMC_TYPE_GCK 68>;
- clock-names = "pclk", "gclk";
- microchip,mic-pos = <MCHP_PDMC_DS0 MCHP_PDMC_CLK_POSITIVE>,
- <MCHP_PDMC_DS0 MCHP_PDMC_CLK_NEGATIVE>,
- <MCHP_PDMC_DS1 MCHP_PDMC_CLK_POSITIVE>,
- <MCHP_PDMC_DS1 MCHP_PDMC_CLK_NEGATIVE>;
- };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml
new file mode 100644
index 000000000000..fb630a184350
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-i2smcc.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-i2smcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip I2S Multi-Channel Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The I2SMCC complies with the Inter-IC Sound (I2S) bus specification and
+ supports a Time Division Multiplexed (TDM) interface with external
+ multi-channel audio codecs. It consists of a receiver, a transmitter and a
+ common clock generator that can be enabled separately to provide Adapter,
+ Client or Controller modes with receiver and/or transmitter active.
+ On later I2SMCC versions (starting with Microchip's SAMA7G5) I2S
+ multi-channel is supported by using multiple data pins, output and
+ input, without TDM.
+
+properties:
+ "#sound-dai-cells":
+ const: 0
+
+ compatible:
+ oneOf:
+ - enum:
+ - microchip,sam9x60-i2smcc
+ - microchip,sama7g5-i2smcc
+ - items:
+ - enum:
+ - microchip,sam9x7-i2smcc
+ - const: microchip,sam9x60-i2smcc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock (Optional). Should be set mostly when Master
+ Mode is required.
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+ minItems: 1
+
+ dmas:
+ items:
+ - description: TX DMA Channel
+ - description: RX DMA Channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ microchip,tdm-data-pair:
+ description:
+ Represents the DIN/DOUT pair pins that are used to receive/send
+ TDM data. It is optional and it is only needed if the controller
+ uses the TDM mode.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ enum: [0, 1, 2, 3]
+ default: 0
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ const: microchip,sam9x60-i2smcc
+ then:
+ properties:
+ microchip,tdm-data-pair: false
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2s@f001c000 {
+ #sound-dai-cells = <0>;
+ compatible = "microchip,sam9x60-i2smcc";
+ reg = <0xf001c000 0x100>;
+ interrupts = <34 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(36))>,
+ <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
+ AT91_XDMAC_DT_PERID(37))>;
+ dma-names = "tx", "rx";
+ clocks = <&i2s_clk>, <&i2s_gclk>;
+ clock-names = "pclk", "gclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_default>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
new file mode 100644
index 000000000000..9aa65c975c4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-pdmc.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-pdmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Pulse Density Microphone Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The Microchip Pulse Density Microphone Controller (PDMC) interfaces up to 4
+ digital microphones having Pulse Density Modulated (PDM) outputs.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: microchip,sama7g5-pdmc
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+
+ dmas:
+ description: RX DMA Channel
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+ microchip,mic-pos:
+ description: |
+ Position of PDM microphones on the DS line and the sampling edge (rising
+ or falling) of the CLK line. A microphone is represented as a pair of DS
+ line and the sampling edge. The first microphone is mapped to channel 0,
+ the second to channel 1, etc.
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: value for DS line
+ enum: [0, 1]
+ - description: value for sampling edge
+ enum: [0, 1]
+ minItems: 1
+ maxItems: 4
+ uniqueItems: true
+
+ microchip,startup-delay-us:
+ description: |
+ Specifies the delay in microseconds that needs to be applied after
+ enabling the PDMC microphones to avoid unwanted noise due to microphones
+ not being ready.
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+ - microchip,mic-pos
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/sound/microchip,pdmc.h>
+
+ pdmc: sound@e1608000 {
+ compatible = "microchip,sama7g5-pdmc";
+ reg = <0xe1608000 0x4000>;
+ #sound-dai-cells = <0>;
+ interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(37)>;
+ dma-names = "rx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 68>, <&pmc PMC_TYPE_GCK 68>;
+ clock-names = "pclk", "gclk";
+ microchip,mic-pos = <MCHP_PDMC_DS0 MCHP_PDMC_CLK_POSITIVE>,
+ <MCHP_PDMC_DS0 MCHP_PDMC_CLK_NEGATIVE>,
+ <MCHP_PDMC_DS1 MCHP_PDMC_CLK_POSITIVE>,
+ <MCHP_PDMC_DS1 MCHP_PDMC_CLK_NEGATIVE>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml
new file mode 100644
index 000000000000..7fbab5871be4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdifrx.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-spdifrx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip S/PDIF Rx Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The Microchip Sony/Philips Digital Interface Receiver is a serial port
+ compliant with the IEC-60958 standard.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ "#sound-dai-cells":
+ const: 0
+
+ compatible:
+ const: microchip,sama7g5-spdifrx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+
+ dmas:
+ description: RX DMA Channel
+ maxItems: 1
+
+ dma-names:
+ const: rx
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spdifrx: spdifrx@e1614000 {
+ #sound-dai-cells = <0>;
+ compatible = "microchip,sama7g5-spdifrx";
+ reg = <0xe1614000 0x4000>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(49)>;
+ dma-names = "rx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 84>, <&pmc PMC_TYPE_GCK 84>;
+ clock-names = "pclk", "gclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml
new file mode 100644
index 000000000000..4702c528700d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/microchip,sama7g5-spdiftx.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/microchip,sama7g5-spdiftx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip S/PDIF Tx Controller
+
+maintainers:
+ - Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+description:
+ The Microchip Sony/Philips Digital Interface Transmitter is a serial port
+ compliant with the IEC-60958 standard.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ "#sound-dai-cells":
+ const: 0
+
+ compatible:
+ const: microchip,sama7g5-spdiftx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral Bus Clock
+ - description: Generic Clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: gclk
+
+ dmas:
+ description: TX DMA Channel
+ maxItems: 1
+
+ dma-names:
+ const: tx
+
+required:
+ - "#sound-dai-cells"
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/dma/at91.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spdiftx@e1618000 {
+ #sound-dai-cells = <0>;
+ compatible = "microchip,sama7g5-spdiftx";
+ reg = <0xe1618000 0x4000>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(50)>;
+ dma-names = "tx";
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 85>, <&pmc PMC_TYPE_GCK 85>;
+ clock-names = "pclk", "gclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdiftx_default>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mscc,zl38060.yaml b/Documentation/devicetree/bindings/sound/mscc,zl38060.yaml
new file mode 100644
index 000000000000..994313fd12b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mscc,zl38060.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mscc,zl38060.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZL38060 Connected Home Audio Processor from Microsemi.
+
+description: |
+ The ZL38060 is a "Connected Home Audio Processor" from Microsemi,
+ which consists of a Digital Signal Processor (DSP), several Digital
+ Audio Interfaces (DAIs), analog outputs, and a block of 14 GPIOs.
+
+maintainers:
+ - Jaroslav Kysela <perex@perex.cz>
+ - Takashi Iwai <tiwai@suse.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: mscc,zl38060
+
+ reg:
+ description:
+ SPI device address.
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 24000000
+
+ reset-gpios:
+ description:
+ A GPIO line handling reset of the chip. As the line is active low,
+ it should be marked GPIO_ACTIVE_LOW (see ../gpio/gpio.txt)
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec: zl38060@0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+ #sound-dai-cells = <0>;
+ compatible = "mscc,zl38060";
+ reg = <0>;
+ spi-max-frequency = <12000000>;
+ reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
deleted file mode 100644
index 560762e0a168..000000000000
--- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
+++ /dev/null
@@ -1,146 +0,0 @@
-Mediatek AFE PCM controller for mt2701
-
-Required properties:
-- compatible: should be one of the followings.
- - "mediatek,mt2701-audio"
- - "mediatek,mt7622-audio"
-- interrupts: should contain AFE and ASYS interrupts
-- interrupt-names: should be "afe" and "asys"
-- power-domains: should define the power domain
-- clocks: Must contain an entry for each entry in clock-names
- See ../clocks/clock-bindings.txt for details
-- clock-names: should have these clock names:
- "infra_sys_audio_clk",
- "top_audio_mux1_sel",
- "top_audio_mux2_sel",
- "top_audio_a1sys_hp",
- "top_audio_a2sys_hp",
- "i2s0_src_sel",
- "i2s1_src_sel",
- "i2s2_src_sel",
- "i2s3_src_sel",
- "i2s0_src_div",
- "i2s1_src_div",
- "i2s2_src_div",
- "i2s3_src_div",
- "i2s0_mclk_en",
- "i2s1_mclk_en",
- "i2s2_mclk_en",
- "i2s3_mclk_en",
- "i2so0_hop_ck",
- "i2so1_hop_ck",
- "i2so2_hop_ck",
- "i2so3_hop_ck",
- "i2si0_hop_ck",
- "i2si1_hop_ck",
- "i2si2_hop_ck",
- "i2si3_hop_ck",
- "asrc0_out_ck",
- "asrc1_out_ck",
- "asrc2_out_ck",
- "asrc3_out_ck",
- "audio_afe_pd",
- "audio_afe_conn_pd",
- "audio_a1sys_pd",
- "audio_a2sys_pd",
- "audio_mrgif_pd";
-- assigned-clocks: list of input clocks and dividers for the audio system.
- See ../clocks/clock-bindings.txt for details.
-- assigned-clocks-parents: parent of input clocks of assigned clocks.
-- assigned-clock-rates: list of clock frequencies of assigned clocks.
-
-Must be a subnode of MediaTek audsys device tree node.
-See ../arm/mediatek/mediatek,audsys.txt for details about the parent node.
-
-Example:
-
- audsys: audio-subsystem@11220000 {
- compatible = "mediatek,mt2701-audsys", "syscon";
- ...
-
- afe: audio-controller {
- compatible = "mediatek,mt2701-audio";
- interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
- interrupt-names = "afe", "asys";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
-
- clocks = <&infracfg CLK_INFRA_AUDIO>,
- <&topckgen CLK_TOP_AUD_MUX1_SEL>,
- <&topckgen CLK_TOP_AUD_MUX2_SEL>,
- <&topckgen CLK_TOP_AUD_48K_TIMING>,
- <&topckgen CLK_TOP_AUD_44K_TIMING>,
- <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
- <&audsys CLK_AUD_I2SO1>,
- <&audsys CLK_AUD_I2SO2>,
- <&audsys CLK_AUD_I2SO3>,
- <&audsys CLK_AUD_I2SO4>,
- <&audsys CLK_AUD_I2SIN1>,
- <&audsys CLK_AUD_I2SIN2>,
- <&audsys CLK_AUD_I2SIN3>,
- <&audsys CLK_AUD_I2SIN4>,
- <&audsys CLK_AUD_ASRCO1>,
- <&audsys CLK_AUD_ASRCO2>,
- <&audsys CLK_AUD_ASRCO3>,
- <&audsys CLK_AUD_ASRCO4>,
- <&audsys CLK_AUD_AFE>,
- <&audsys CLK_AUD_AFE_CONN>,
- <&audsys CLK_AUD_A1SYS>,
- <&audsys CLK_AUD_A2SYS>,
- <&audsys CLK_AUD_AFE_MRGIF>;
-
- clock-names = "infra_sys_audio_clk",
- "top_audio_mux1_sel",
- "top_audio_mux2_sel",
- "top_audio_a1sys_hp",
- "top_audio_a2sys_hp",
- "i2s0_src_sel",
- "i2s1_src_sel",
- "i2s2_src_sel",
- "i2s3_src_sel",
- "i2s0_src_div",
- "i2s1_src_div",
- "i2s2_src_div",
- "i2s3_src_div",
- "i2s0_mclk_en",
- "i2s1_mclk_en",
- "i2s2_mclk_en",
- "i2s3_mclk_en",
- "i2so0_hop_ck",
- "i2so1_hop_ck",
- "i2so2_hop_ck",
- "i2so3_hop_ck",
- "i2si0_hop_ck",
- "i2si1_hop_ck",
- "i2si2_hop_ck",
- "i2si3_hop_ck",
- "asrc0_out_ck",
- "asrc1_out_ck",
- "asrc2_out_ck",
- "asrc3_out_ck",
- "audio_afe_pd",
- "audio_afe_conn_pd",
- "audio_a1sys_pd",
- "audio_a2sys_pd",
- "audio_mrgif_pd";
-
- assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
- <&topckgen CLK_TOP_AUD_MUX2_SEL>,
- <&topckgen CLK_TOP_AUD_MUX1_DIV>,
- <&topckgen CLK_TOP_AUD_MUX2_DIV>;
- assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
- <&topckgen CLK_TOP_AUD2PLL_90M>;
- assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt b/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
deleted file mode 100644
index 809b609ea9d0..000000000000
--- a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-MT2701 with WM8960 CODEC
-
-Required properties:
-- compatible: "mediatek,mt2701-wm8960-machine"
-- mediatek,platform: the phandle of MT2701 ASoC platform
-- audio-routing: a list of the connections between audio
-- mediatek,audio-codec: the phandles of wm8960 codec
-- pinctrl-names: Should contain only one value - "default"
-- pinctrl-0: Should specify pin control groups used for this controller.
-
-Example:
-
- sound:sound {
- compatible = "mediatek,mt2701-wm8960-machine";
- mediatek,platform = <&afe>;
- audio-routing =
- "Headphone", "HP_L",
- "Headphone", "HP_R",
- "LINPUT1", "AMIC",
- "RINPUT1", "AMIC";
- mediatek,audio-codec = <&wm8960>;
- pinctrl-names = "default";
- pinctrl-0 = <&aud_pins_default>;
- };
diff --git a/Documentation/devicetree/bindings/sound/mt6359.yaml b/Documentation/devicetree/bindings/sound/mt6359.yaml
index a54f466f769d..128698630c86 100644
--- a/Documentation/devicetree/bindings/sound/mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mt6359.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/mt6359.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT6359 Codec Device Tree Bindings
+title: Mediatek MT6359 Codec
maintainers:
- Eason Yen <eason.yen@mediatek.com>
@@ -23,8 +23,8 @@ properties:
Indicates how many data pins are used to transmit two channels of PDM
signal. 0 means two wires, 1 means one wire. Default value is 0.
enum:
- - 0 # one wire
- - 1 # two wires
+ - 0 # two wires
+ - 1 # one wire
mediatek,mic-type-0:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -53,9 +53,9 @@ additionalProperties: false
examples:
- |
- mt6359codec: mt6359codec {
- mediatek,dmic-mode = <0>;
- mediatek,mic-type-0 = <2>;
+ mt6359codec: audio-codec {
+ mediatek,dmic-mode = <0>;
+ mediatek,mic-type-0 = <2>;
};
...
diff --git a/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt
deleted file mode 100644
index 1f1cba4152ce..000000000000
--- a/Documentation/devicetree/bindings/sound/mt8183-afe-pcm.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Mediatek AFE PCM controller for mt8183
-
-Required properties:
-- compatible = "mediatek,mt68183-audio";
-- reg: register location and size
-- interrupts: should contain AFE interrupt
-- resets: Must contain an entry for each entry in reset-names
- See ../reset/reset.txt for details.
-- reset-names: should have these reset names:
- "audiosys";
-- power-domains: should define the power domain
-- clocks: Must contain an entry for each entry in clock-names
-- clock-names: should have these clock names:
- "infra_sys_audio_clk",
- "mtkaif_26m_clk",
- "top_mux_audio",
- "top_mux_aud_intbus",
- "top_sys_pll3_d4",
- "top_clk26m_clk";
-
-Example:
-
- afe: mt8183-afe-pcm@11220000 {
- compatible = "mediatek,mt8183-audio";
- reg = <0 0x11220000 0 0x1000>;
- interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_LOW>;
- resets = <&watchdog MT8183_TOPRGU_AUDIO_SW_RST>;
- reset-names = "audiosys";
- power-domains = <&scpsys MT8183_POWER_DOMAIN_AUDIO>;
- clocks = <&infrasys CLK_INFRA_AUDIO>,
- <&infrasys CLK_INFRA_AUDIO_26M_BCLK>,
- <&topckgen CLK_TOP_MUX_AUDIO>,
- <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
- <&topckgen CLK_TOP_SYSPLL_D2_D4>,
- <&clk26m>;
- clock-names = "infra_sys_audio_clk",
- "mtkaif_26m_clk",
- "top_mux_audio",
- "top_mux_aud_intbus",
- "top_sys_pll_d2_d4",
- "top_clk26m_clk";
- };
diff --git a/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt b/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt
deleted file mode 100644
index f276dfc74b46..000000000000
--- a/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-MT8183 with MT6358, DA7219, MAX98357, and RT1015 CODECS
-
-Required properties:
-- compatible : "mediatek,mt8183_da7219_max98357" for MAX98357A codec
- "mediatek,mt8183_da7219_rt1015" for RT1015 codec
- "mediatek,mt8183_da7219_rt1015p" for RT1015P codec
-- mediatek,headset-codec: the phandles of da7219 codecs
-- mediatek,platform: the phandle of MT8183 ASoC platform
-
-Optional properties:
-- mediatek,hdmi-codec: the phandles of HDMI codec
-
-Example:
-
- sound {
- compatible = "mediatek,mt8183_da7219_max98357";
- mediatek,headset-codec = <&da7219>;
- mediatek,hdmi-codec = <&it6505dptx>;
- mediatek,platform = <&afe>;
- };
-
diff --git a/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt b/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt
deleted file mode 100644
index ecd46ed8eb98..000000000000
--- a/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-MT8183 with MT6358, TS3A227, MAX98357, and RT1015 CODECS
-
-Required properties:
-- compatible : "mediatek,mt8183_mt6358_ts3a227_max98357" for MAX98357A codec
- "mediatek,mt8183_mt6358_ts3a227_max98357b" for MAX98357B codec
- "mediatek,mt8183_mt6358_ts3a227_rt1015" for RT1015 codec
- "mediatek,mt8183_mt6358_ts3a227_rt1015p" for RT1015P codec
-- mediatek,platform: the phandle of MT8183 ASoC platform
-
-Optional properties:
-- mediatek,headset-codec: the phandles of ts3a227 codecs
-- mediatek,ec-codec: the phandle of EC codecs.
- See google,cros-ec-codec.txt for more details.
-- mediatek,hdmi-codec: the phandles of HDMI codec
-
-Example:
-
- sound {
- compatible = "mediatek,mt8183_mt6358_ts3a227_max98357";
- mediatek,headset-codec = <&ts3a227>;
- mediatek,ec-codec = <&ec_codec>;
- mediatek,hdmi-codec = <&it6505dptx>;
- mediatek,platform = <&afe>;
- };
-
diff --git a/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml
index 88f82d096443..f5af2cf18158 100644
--- a/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml
@@ -25,16 +25,20 @@ properties:
reset-names:
const: audiosys
+ memory-region:
+ description: memory region for audio DMA buffers
+ maxItems: 1
+
mediatek,apmixedsys:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek apmixedsys controller
mediatek,infracfg:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek infracfg controller
mediatek,topckgen:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek topckgen controller
clocks:
@@ -170,6 +174,7 @@ examples:
"top_apll12_div_tdm",
"top_mux_audio_h",
"top_clk26m_clk";
+ memory-region = <&afe_dma_mem>;
};
...
diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml
index d427f7f623db..037f21443ad1 100644
--- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml
@@ -12,17 +12,46 @@ maintainers:
description:
This binding describes the MT8186 sound card.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- mediatek,mt8186-mt6366-da7219-max98357-sound
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+ Valid names could be the input or output widgets of audio components,
+ power supplies, MicBias of codec and the software switch.
+ minItems: 2
+ items:
+ enum:
+ # Sinks
+ - HDMI1
+ - Headphones
+ - Line Out
+ - MIC
+ - Speakers
+
+ # Sources
+ - Headset Mic
+ - HPL
+ - HPR
+ - Speaker
+ - TX
+
mediatek,platform:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8186 ASoC platform.
headset-codec:
type: object
+ deprecated: true
additionalProperties: false
properties:
sound-dai:
@@ -32,6 +61,7 @@ properties:
playback-codecs:
type: object
+ deprecated: true
additionalProperties: false
properties:
sound-dai:
@@ -53,32 +83,114 @@ properties:
A list of the desired dai-links in the sound card. Each entry is a
name defined in the machine driver.
-additionalProperties: false
+patternProperties:
+ ".*-dai-link$":
+ type: object
+ additionalProperties: false
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name
+ items:
+ enum:
+ - I2S0
+ - I2S1
+ - I2S2
+ - I2S3
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ dai-format:
+ description: audio format
+ items:
+ enum:
+ - i2s
+ - right_j
+ - left_j
+ - dsp_a
+ - dsp_b
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ enum:
+ - cpu
+ - codec
+
+ required:
+ - link-name
+
+unevaluatedProperties: false
required:
- compatible
- mediatek,platform
- - headset-codec
- - playback-codecs
+
+# Disallow legacy properties if xxx-dai-link nodes are specified
+if:
+ not:
+ patternProperties:
+ ".*-dai-link$": false
+then:
+ properties:
+ headset-codec: false
+ speaker-codecs: false
examples:
- |
sound: mt8186-sound {
compatible = "mediatek,mt8186-mt6366-da7219-max98357-sound";
- mediatek,platform = <&afe>;
+ model = "mt8186_da7219_m98357";
pinctrl-names = "aud_clk_mosi_off",
"aud_clk_mosi_on";
pinctrl-0 = <&aud_clk_mosi_off>;
pinctrl-1 = <&aud_clk_mosi_on>;
+ mediatek,platform = <&afe>;
+
+ audio-routing =
+ "Headphones", "HPL",
+ "Headphones", "HPR",
+ "MIC", "Headset Mic",
+ "Speakers", "Speaker",
+ "HDMI1", "TX";
+
+ hs-playback-dai-link {
+ link-name = "I2S0";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&da7219>;
+ };
+ };
- headset-codec {
- sound-dai = <&da7219>;
+ hs-capture-dai-link {
+ link-name = "I2S1";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&da7219>;
+ };
};
- playback-codecs {
- sound-dai = <&anx_bridge_dp>,
- <&max98357a>;
+ spk-dp-playback-dai-link {
+ link-name = "I2S3";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&anx_bridge_dp>, <&max98357a>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml
index 4fc5b045d3cf..ed93f18ef985 100644
--- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml
@@ -12,17 +12,58 @@ maintainers:
description:
This binding describes the MT8186 sound card.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- mediatek,mt8186-mt6366-rt1019-rt5682s-sound
+ - mediatek,mt8186-mt6366-rt5682s-max98360-sound
+ - mediatek,mt8186-mt6366-rt5650-sound
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+ Valid names could be the input or output widgets of audio components,
+ power supplies, MicBias of codec and the software switch.
+ minItems: 2
+ items:
+ enum:
+ # Sinks
+ - HDMI1
+ - Headphone
+ - IN1P
+ - IN1N
+ - Line Out
+ - Speakers
+
+ # Sources
+ - Headset Mic
+ - HPOL
+ - HPOR
+ - Speaker
+ - SPOL
+ - SPOR
+ - TX
mediatek,platform:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8186 ASoC platform.
+ dmic-gpios:
+ maxItems: 1
+ description:
+ dmic-gpios optional prop for switching between two DMICs.
+ Ex, the GPIO can control a MUX HW component to select
+ dmic clk and data form a Front or Rear dmic.
+
headset-codec:
type: object
+ deprecated: true
additionalProperties: false
properties:
sound-dai:
@@ -32,6 +73,7 @@ properties:
playback-codecs:
type: object
+ deprecated: true
additionalProperties: false
properties:
sound-dai:
@@ -53,32 +95,106 @@ properties:
A list of the desired dai-links in the sound card. Each entry is a
name defined in the machine driver.
-additionalProperties: false
+patternProperties:
+ ".*-dai-link$":
+ type: object
+ additionalProperties: false
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name
+ enum: [ I2S0, I2S1, I2S2, I2S3 ]
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ dai-format:
+ description: audio format
+ enum: [ i2s, right_j, left_j, dsp_a, dsp_b ]
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ enum: [ cpu, codec ]
+
+ required:
+ - link-name
+
+unevaluatedProperties: false
required:
- compatible
- mediatek,platform
- - headset-codec
- - playback-codecs
+
+# Disallow legacy properties if xxx-dai-link nodes are specified
+if:
+ not:
+ patternProperties:
+ ".*-dai-link$": false
+then:
+ properties:
+ headset-codec: false
+ speaker-codecs: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
sound: mt8186-sound {
compatible = "mediatek,mt8186-mt6366-rt1019-rt5682s-sound";
- mediatek,platform = <&afe>;
+ model = "mt8186_rt1019_rt5682s";
pinctrl-names = "aud_clk_mosi_off",
- "aud_clk_mosi_on";
+ "aud_clk_mosi_on",
+ "aud_gpio_dmic_sec";
pinctrl-0 = <&aud_clk_mosi_off>;
pinctrl-1 = <&aud_clk_mosi_on>;
+ pinctrl-2 = <&aud_gpio_dmic_sec>;
+ mediatek,platform = <&afe>;
+
+ dmic-gpios = <&pio 23 GPIO_ACTIVE_HIGH>;
+
+ audio-routing =
+ "Headphone", "HPOL",
+ "Headphone", "HPOR",
+ "IN1P", "Headset Mic",
+ "Speakers", "Speaker",
+ "HDMI1", "TX";
+
+ hs-playback-dai-link {
+ link-name = "I2S0";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&rt5682s 0>;
+ };
+ };
- headset-codec {
- sound-dai = <&rt5682s>;
+ hs-capture-dai-link {
+ link-name = "I2S1";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&rt5682s 0>;
+ };
};
- playback-codecs {
- sound-dai = <&it6505dptx>,
- <&rt1019p>;
+ spk-hdmi-playback-dai-link {
+ link-name = "I2S3";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&it6505dptx>, <&rt1019p>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml
index 7a25bc9b8060..8ddf49b0040d 100644
--- a/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml
@@ -23,16 +23,20 @@ properties:
reset-names:
const: audiosys
+ memory-region:
+ description: memory region for audio DMA buffers
+ maxItems: 1
+
mediatek,apmixedsys:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek apmixedsys controller
mediatek,infracfg:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek infracfg controller
mediatek,topckgen:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek topckgen controller
power-domains:
@@ -95,6 +99,7 @@ examples:
"aud_dac_predis_clk",
"aud_infra_clk",
"aud_infra_26m_clk";
+ memory-region = <&afe_dma_mem>;
};
...
diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
index 478be7e3fa29..c4e68f31aaab 100644
--- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
@@ -13,6 +13,9 @@ maintainers:
description:
This binding describes the MT8192 sound card.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
@@ -20,27 +23,55 @@ properties:
- mediatek,mt8192_mt6359_rt1015p_rt5682
- mediatek,mt8192_mt6359_rt1015p_rt5682s
+ audio-routing:
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+ Valid names could be the input or output widgets of audio components,
+ power supplies, MicBias of codec and the software switch.
+ minItems: 2
+ items:
+ enum:
+ # Sinks
+ - Speakers
+ - Headphone Jack
+ - IN1P
+ - Left Spk
+ - Right Spk
+
+ # Sources
+ - Headset Mic
+ - HPOL
+ - HPOR
+ - Left SPO
+ - Right SPO
+ - Speaker
+
mediatek,platform:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8192 ASoC platform.
mediatek,hdmi-codec:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of HDMI codec.
+ deprecated: true
headset-codec:
type: object
additionalProperties: false
+ deprecated: true
properties:
sound-dai:
- $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
required:
- sound-dai
speaker-codecs:
type: object
additionalProperties: false
+ deprecated: true
properties:
sound-dai:
@@ -48,37 +79,124 @@ properties:
maxItems: 2
items:
maxItems: 1
- $ref: /schemas/types.yaml#/definitions/phandle-array
required:
- sound-dai
-additionalProperties: false
+patternProperties:
+ ".*-dai-link$":
+ type: object
+ additionalProperties: false
+
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name
+ enum:
+ - I2S0
+ - I2S1
+ - I2S2
+ - I2S3
+ - I2S4
+ - I2S5
+ - I2S6
+ - I2S7
+ - I2S8
+ - I2S9
+ - TDM
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ dai-format:
+ description: audio format
+ enum: [ i2s, right_j, left_j, dsp_a, dsp_b ]
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ enum: [ cpu, codec ]
+
+ required:
+ - link-name
+
+unevaluatedProperties: false
required:
- compatible
- mediatek,platform
- - headset-codec
- - speaker-codecs
+
+# Disallow legacy properties if xxx-dai-link nodes are specified
+if:
+ not:
+ patternProperties:
+ ".*-dai-link$": false
+then:
+ properties:
+ headset-codec: false
+ speaker-codecs: false
+ mediatek,hdmi-codec: false
examples:
- |
sound: mt8192-sound {
compatible = "mediatek,mt8192_mt6359_rt1015_rt5682";
- mediatek,platform = <&afe>;
- mediatek,hdmi-codec = <&anx_bridge_dp>;
+ model = "mt8192_mt6359_rt1015_rt5682";
pinctrl-names = "aud_clk_mosi_off",
"aud_clk_mosi_on";
pinctrl-0 = <&aud_clk_mosi_off>;
pinctrl-1 = <&aud_clk_mosi_on>;
+ mediatek,platform = <&afe>;
+
+ audio-routing =
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR",
+ "IN1P", "Headset Mic",
+ "Speakers", "Speaker";
+
+ spk-playback-dai-link {
+ link-name = "I2S3";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&rt1015p>;
+ };
+ };
+
+ hs-playback-dai-link {
+ link-name = "I2S8";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&rt5682 0>;
+ };
+ };
- headset-codec {
- sound-dai = <&rt5682>;
+ hs-capture-dai-link {
+ link-name = "I2S9";
+ dai-format = "i2s";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&rt5682 0>;
+ };
};
- speaker-codecs {
- sound-dai = <&rt1015_l>,
- <&rt1015_r>;
+ displayport-dai-link {
+ link-name = "TDM";
+ dai-format = "dsp_a";
+ codec {
+ sound-dai = <&anx_bridge_dp>;
+ };
};
};
diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
index 4452a4070eff..5c8dba2b3a81 100644
--- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
@@ -32,7 +32,7 @@ properties:
See ../reserved-memory/reserved-memory.txt for details.
mediatek,topckgen:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of the mediatek topckgen controller
power-domains:
@@ -111,7 +111,7 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
etdm modules can share the same external clock pin. Specify
- which etdm clock source is required by this etdm in moudule.
+ which etdm clock source is required by this etdm in module.
enum:
- 0 # etdm1_in
- 1 # etdm2_in
@@ -122,7 +122,7 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
etdm modules can share the same external clock pin. Specify
- which etdm clock source is required by this etdm out moudule.
+ which etdm clock source is required by this etdm out module.
enum:
- 0 # etdm1_in
- 1 # etdm2_in
diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml
index ad3447ff8b2c..356e1feee962 100644
--- a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml
+++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml
@@ -12,31 +12,66 @@ maintainers:
description:
This binding describes the MT8195 sound card.
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
- mediatek,mt8195_mt6359_rt1019_rt5682
- mediatek,mt8195_mt6359_rt1011_rt5682
- mediatek,mt8195_mt6359_max98390_rt5682
+ - mediatek,mt8195_mt6359
model:
$ref: /schemas/types.yaml#/definitions/string
description: User specified audio sound card name
+ audio-routing:
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+ Valid names could be the input or output widgets of audio components,
+ power supplies, MicBias of codec and the software switch.
+ minItems: 2
+ items:
+ enum:
+ # Sinks
+ - Ext Spk
+ - Headphone
+ - IN1P
+ - Left Spk
+ - Right Spk
+
+ # Sources
+ - Headphone L
+ - Headphone R
+ - Headset Mic
+ - HPOL
+ - HPOR
+ - Left BE_OUT
+ - Left SPO
+ - Right BE_OUT
+ - Right SPO
+ - Speaker
+
mediatek,platform:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8195 ASoC platform.
mediatek,dptx-codec:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8195 Display Port Tx codec node.
+ deprecated: true
mediatek,hdmi-codec:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8195 HDMI codec node.
+ deprecated: true
mediatek,adsp:
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
description: The phandle of MT8195 ADSP platform.
mediatek,dai-link:
@@ -45,20 +80,123 @@ properties:
A list of the desired dai-links in the sound card. Each entry is a
name defined in the machine driver.
+patternProperties:
+ ".*-dai-link$":
+ type: object
+ additionalProperties: false
+ description:
+ Container for dai-link level properties and CODEC sub-nodes.
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name
+ enum:
+ - DL_SRC_BE
+ - DPTX_BE
+ - ETDM1_IN_BE
+ - ETDM2_IN_BE
+ - ETDM1_OUT_BE
+ - ETDM2_OUT_BE
+ - ETDM3_OUT_BE
+ - PCM1_BE
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 2
+ required:
+ - sound-dai
+
+ dai-format:
+ description: audio format
+ enum: [ i2s, right_j, left_j, dsp_a, dsp_b ]
+
+ mediatek,clk-provider:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Indicates dai-link clock master.
+ enum: [ cpu, codec ]
+
+ required:
+ - link-name
+
additionalProperties: false
required:
- compatible
- mediatek,platform
+# Disallow legacy properties if xxx-dai-link nodes are specified
+if:
+ not:
+ patternProperties:
+ ".*-dai-link$": false
+then:
+ properties:
+ mediatek,dptx-codec: false
+ mediatek,hdmi-codec: false
+
examples:
- |
sound: mt8195-sound {
compatible = "mediatek,mt8195_mt6359_rt1019_rt5682";
+ model = "mt8195_r1019_5682";
mediatek,platform = <&afe>;
pinctrl-names = "default";
pinctrl-0 = <&aud_pins_default>;
+
+ audio-routing =
+ "Headphone", "HPOL",
+ "Headphone", "HPOR",
+ "IN1P", "Headset Mic",
+ "Ext Spk", "Speaker";
+
+ mm-dai-link {
+ link-name = "ETDM1_IN_BE";
+ mediatek,clk-provider = "cpu";
+ };
+
+ hs-playback-dai-link {
+ link-name = "ETDM1_OUT_BE";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&headset_codec>;
+ };
+ };
+
+ hs-capture-dai-link {
+ link-name = "ETDM2_IN_BE";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&headset_codec>;
+ };
+ };
+
+ spk-playback-dai-link {
+ link-name = "ETDM2_OUT_BE";
+ mediatek,clk-provider = "cpu";
+ codec {
+ sound-dai = <&spk_amplifier>;
+ };
+ };
+
+ hdmi-dai-link {
+ link-name = "ETDM3_OUT_BE";
+ codec {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+
+ displayport-dai-link {
+ link-name = "DPTX_BE";
+ codec {
+ sound-dai = <&dp_tx>;
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/sound/mtk-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mtk-afe-pcm.txt
deleted file mode 100644
index e302c7f43b95..000000000000
--- a/Documentation/devicetree/bindings/sound/mtk-afe-pcm.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Mediatek AFE PCM controller
-
-Required properties:
-- compatible = "mediatek,mt8173-afe-pcm";
-- reg: register location and size
-- interrupts: Should contain AFE interrupt
-- clock-names: should have these clock names:
- "infra_sys_audio_clk",
- "top_pdn_audio",
- "top_pdn_aud_intbus",
- "bck0",
- "bck1",
- "i2s0_m",
- "i2s1_m",
- "i2s2_m",
- "i2s3_m",
- "i2s3_b";
-
-Example:
-
- afe: mt8173-afe-pcm@11220000 {
- compatible = "mediatek,mt8173-afe-pcm";
- reg = <0 0x11220000 0 0x1000>;
- interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_FALLING>;
- clocks = <&infracfg INFRA_AUDIO>,
- <&topckgen TOP_AUDIO_SEL>,
- <&topckgen TOP_AUD_INTBUS_SEL>,
- <&topckgen TOP_APLL1_DIV0>,
- <&topckgen TOP_APLL2_DIV0>,
- <&topckgen TOP_I2S0_M_CK_SEL>,
- <&topckgen TOP_I2S1_M_CK_SEL>,
- <&topckgen TOP_I2S2_M_CK_SEL>,
- <&topckgen TOP_I2S3_M_CK_SEL>,
- <&topckgen TOP_I2S3_B_CK_SEL>;
- clock-names = "infra_sys_audio_clk",
- "top_pdn_audio",
- "top_pdn_aud_intbus",
- "bck0",
- "bck1",
- "i2s0_m",
- "i2s1_m",
- "i2s2_m",
- "i2s3_m",
- "i2s3_b";
- };
diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
index cb8c07c81ce4..4f5dec5cb3c2 100644
--- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt
+++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
@@ -6,9 +6,14 @@ Required properties:
"marvell,kirkwood-audio" for Kirkwood platforms
"marvell,dove-audio" for Dove platforms
"marvell,armada370-audio" for Armada 370 platforms
+ "marvell,armada-380-audio" for Armada 38x platforms
- reg: physical base address of the controller and length of memory mapped
- region.
+ region (named "i2s_regs").
+ With "marvell,armada-380-audio" two other regions are required:
+ first of those is dedicated for Audio PLL Configuration registers
+ (named "pll_regs") and the second one ("soc_ctrl") - for register
+ where one of exceptive I/O types (I2S or S/PDIF) is set.
- interrupts:
with "marvell,kirkwood-audio", the audio interrupt
@@ -23,6 +28,13 @@ Required properties:
"internal" for the internal clock
"extclk" for the external clock
+Optional properties:
+
+- spdif-mode:
+ Enable S/PDIF mode on Armada 38x SoC. Using this property
+ disables standard I2S I/O. Valid only with "marvell,armada-380-audio"
+ compatible string.
+
Example:
i2s1: audio-controller@b4000 {
diff --git a/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt
deleted file mode 100644
index 4eb980bd0287..000000000000
--- a/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-* Freescale MXS audio complex with SGTL5000 codec
-
-Required properties:
-- compatible : "fsl,mxs-audio-sgtl5000"
-- model : The user-visible name of this sound complex
-- saif-controllers : The phandle list of the MXS SAIF controller
-- audio-codec : The phandle of the SGTL5000 audio codec
-- audio-routing : A list of the connections between audio components.
- Each entry is a pair of strings, the first being the
- connection's sink, the second being the connection's
- source. Valid names could be power supplies, SGTL5000
- pins, and the jacks on the board:
-
- Power supplies:
- * Mic Bias
-
- SGTL5000 pins:
- * MIC_IN
- * LINE_IN
- * HP_OUT
- * LINE_OUT
-
- Board connectors:
- * Mic Jack
- * Line In Jack
- * Headphone Jack
- * Line Out Jack
- * Ext Spk
-
-Example:
-
-sound {
- compatible = "fsl,imx28-evk-sgtl5000",
- "fsl,mxs-audio-sgtl5000";
- model = "imx28-evk-sgtl5000";
- saif-controllers = <&saif0 &saif1>;
- audio-codec = <&sgtl5000>;
- audio-routing =
- "MIC_IN", "Mic Jack",
- "Mic Jack", "Mic Bias",
- "Headphone Jack", "HP_OUT";
-};
diff --git a/Documentation/devicetree/bindings/sound/mxs-saif.txt b/Documentation/devicetree/bindings/sound/mxs-saif.txt
deleted file mode 100644
index 7ba07a118e37..000000000000
--- a/Documentation/devicetree/bindings/sound/mxs-saif.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Freescale MXS Serial Audio Interface (SAIF)
-
-Required properties:
-- compatible: Should be "fsl,<chip>-saif"
-- reg: Should contain registers location and length
-- interrupts: Should contain ERROR interrupt number
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
- and SAIF DMA channel ID.
- Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Optional properties:
-- fsl,saif-master: phandle to the master SAIF. It's only required for
- the slave SAIF.
-
-Note: Each SAIF controller should have an alias correctly numbered
-in "aliases" node.
-
-Example:
-
-aliases {
- saif0 = &saif0;
- saif1 = &saif1;
-};
-
-saif0: saif@80042000 {
- compatible = "fsl,imx28-saif";
- reg = <0x80042000 2000>;
- interrupts = <59>;
- dmas = <&dma_apbx 4>;
- dma-names = "rx-tx";
-};
-
-saif1: saif@80046000 {
- compatible = "fsl,imx28-saif";
- reg = <0x80046000 2000>;
- interrupts = <58>;
- dmas = <&dma_apbx 5>;
- dma-names = "rx-tx";
- fsl,saif-master = <&saif0>;
-};
diff --git a/Documentation/devicetree/bindings/sound/name-prefix.yaml b/Documentation/devicetree/bindings/sound/name-prefix.yaml
deleted file mode 100644
index 2fe57f87ac52..000000000000
--- a/Documentation/devicetree/bindings/sound/name-prefix.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/name-prefix.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Component sound name prefix
-
-maintainers:
- - Jerome Brunet <jbrunet@baylibre.com>
-
-properties:
- sound-name-prefix:
- $ref: /schemas/types.yaml#/definitions/string
- description: |
- Card implementing the routing property define the connection between
- audio components as list of string pair. Component using the same
- sink/source names may use this property to prepend the name of their
- sinks/sources with the provided string.
-
-additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/nau8315.txt b/Documentation/devicetree/bindings/sound/nau8315.txt
deleted file mode 100644
index 6eaec46f384c..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8315.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Nuvoton NAU8315 Mono Class-D Amplifier
-
-Required properties:
-- compatible : "nuvoton,nau8315"
-
-Optional properties:
-- enable-gpios : GPIO specifier for the chip's device enable input(EN) pin.
- If this option is not specified then driver does not manage
- the pin state (e.g. chip is always on).
-
-Example:
-
-#include <dt-bindings/gpio/gpio.h>
-
-nau8315 {
- compatible = "nuvoton,nau8315";
- enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8540.txt b/Documentation/devicetree/bindings/sound/nau8540.txt
deleted file mode 100644
index 307a76528320..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8540.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-NAU85L40 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "nuvoton,nau8540"
-
- - reg : the I2C address of the device.
-
-Example:
-
-codec: nau8540@1c {
- compatible = "nuvoton,nau8540";
- reg = <0x1c>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8810.txt b/Documentation/devicetree/bindings/sound/nau8810.txt
deleted file mode 100644
index 7deaa452b200..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8810.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-NAU8810/NAU8812/NAU8814 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : One of "nuvoton,nau8810" or "nuvoton,nau8812" or
- "nuvoton,nau8814"
-
- - reg : the I2C address of the device.
-
-Example:
-
-codec: nau8810@1a {
- compatible = "nuvoton,nau8810";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8821.txt b/Documentation/devicetree/bindings/sound/nau8821.txt
deleted file mode 100644
index 7c84e7c7327a..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8821.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Nuvoton NAU88L21 audio codec
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "nuvoton,nau8821"
-
- - reg : the I2C address of the device. This is either 0x1B (CSB=0) or 0x54 (CSB=1).
-
-Optional properties:
- - nuvoton,jkdet-enable: Enable jack detection via JKDET pin.
- - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled,
- otherwise pin in high impedance state.
- - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down.
- - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low.
-
- - nuvoton,vref-impedance: VREF Impedance selection
- 0 - Open
- 1 - 25 kOhm
- 2 - 125 kOhm
- 3 - 2.5 kOhm
-
- - nuvoton,micbias-voltage: Micbias voltage level.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
- - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
-
- - nuvoton,dmic-clk-threshold: the ADC threshold of DMIC clock.
- - nuvoton,key_enable: Headset button detection switch.
-
-Example:
-
- headset: nau8821@1b {
- compatible = "nuvoton,nau8821";
- reg = <0x1b>;
- interrupt-parent = <&gpio>;
- interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
- nuvoton,jkdet-enable;
- nuvoton,jkdet-pull-enable;
- nuvoton,jkdet-pull-up;
- nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
- nuvoton,vref-impedance = <2>;
- nuvoton,micbias-voltage = <6>;
- nuvoton,jack-insert-debounce = <7>;
- nuvoton,jack-eject-debounce = <7>;
- nuvoton,dmic-clk-threshold = 3072000;
- };
diff --git a/Documentation/devicetree/bindings/sound/nau8822.txt b/Documentation/devicetree/bindings/sound/nau8822.txt
deleted file mode 100644
index a471d162d4e5..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8822.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-NAU8822 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "nuvoton,nau8822"
-
- - reg : the I2C address of the device.
-
-Example:
-
-codec: nau8822@1a {
- compatible = "nuvoton,nau8822";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nau8824.txt b/Documentation/devicetree/bindings/sound/nau8824.txt
deleted file mode 100644
index e0058b97e49a..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8824.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Nuvoton NAU8824 audio codec
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "nuvoton,nau8824"
-
- - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1).
-
-Optional properties:
- - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low.
-
- - nuvoton,vref-impedance: VREF Impedance selection
- 0 - Open
- 1 - 25 kOhm
- 2 - 125 kOhm
- 3 - 2.5 kOhm
-
- - nuvoton,micbias-voltage: Micbias voltage level.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-threshold-num: Number of buttons supported
- - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as
- SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R)
- where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance.
- Refer datasheet section 10.2 for more information about threshold calculation.
-
- - nuvoton,sar-hysteresis: Button impedance measurement hysteresis.
-
- - nuvoton,sar-voltage: Reference voltage for button impedance measurement.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-compare-time: SAR compare time
- 0 - 500 ns
- 1 - 1 us
- 2 - 2 us
- 3 - 4 us
-
- - nuvoton,sar-sampling-time: SAR sampling time
- 0 - 2 us
- 1 - 4 us
- 2 - 8 us
- 3 - 16 us
-
- - nuvoton,short-key-debounce: Button short key press debounce time.
- 0 - 30 ms
- 1 - 50 ms
- 2 - 100 ms
-
- - nuvoton,jack-eject-debounce: Jack ejection debounce time.
- 0 - 0 ms
- 1 - 1 ms
- 2 - 10 ms
-
-
-Example:
-
- headset: nau8824@1a {
- compatible = "nuvoton,nau8824";
- reg = <0x1a>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(E, 6) IRQ_TYPE_LEVEL_LOW>;
- nuvoton,vref-impedance = <2>;
- nuvoton,micbias-voltage = <6>;
- // Setup 4 buttons impedance according to Android specification
- nuvoton,sar-threshold-num = <4>;
- nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
- nuvoton,sar-hysteresis = <0>;
- nuvoton,sar-voltage = <6>;
- nuvoton,sar-compare-time = <1>;
- nuvoton,sar-sampling-time = <1>;
- nuvoton,short-key-debounce = <0>;
- nuvoton,jack-eject-debounce = <1>;
- };
diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt
deleted file mode 100644
index cb861aca8d40..000000000000
--- a/Documentation/devicetree/bindings/sound/nau8825.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-Nuvoton NAU8825 audio codec
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "nuvoton,nau8825"
-
- - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1).
-
-Optional properties:
- - nuvoton,jkdet-enable: Enable jack detection via JKDET pin.
- - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled,
- otherwise pin in high impedance state.
- - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down.
- - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low.
-
- - nuvoton,vref-impedance: VREF Impedance selection
- 0 - Open
- 1 - 25 kOhm
- 2 - 125 kOhm
- 3 - 2.5 kOhm
-
- - nuvoton,micbias-voltage: Micbias voltage level.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-threshold-num: Number of buttons supported
- - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as
- SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R)
- where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance.
- Refer datasheet section 10.2 for more information about threshold calculation.
-
- - nuvoton,sar-hysteresis: Button impedance measurement hysteresis.
-
- - nuvoton,sar-voltage: Reference voltage for button impedance measurement.
- 0 - VDDA
- 1 - VDDA
- 2 - VDDA * 1.1
- 3 - VDDA * 1.2
- 4 - VDDA * 1.3
- 5 - VDDA * 1.4
- 6 - VDDA * 1.53
- 7 - VDDA * 1.53
-
- - nuvoton,sar-compare-time: SAR compare time
- 0 - 500 ns
- 1 - 1 us
- 2 - 2 us
- 3 - 4 us
-
- - nuvoton,sar-sampling-time: SAR sampling time
- 0 - 2 us
- 1 - 4 us
- 2 - 8 us
- 3 - 16 us
-
- - nuvoton,short-key-debounce: Button short key press debounce time.
- 0 - 30 ms
- 1 - 50 ms
- 2 - 100 ms
- 3 - 30 ms
-
- - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
- - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms
-
- - nuvoton,crosstalk-enable: make crosstalk function enable if set.
-
- - nuvoton,adcout-drive-strong: make the drive strength of ADCOUT IO PIN strong if set.
- Otherwise, the drive keeps normal strength.
-
- - clocks: list of phandle and clock specifier pairs according to common clock bindings for the
- clocks described in clock-names
- - clock-names: should include "mclk" for the MCLK master clock
-
-Example:
-
- headset: nau8825@1a {
- compatible = "nuvoton,nau8825";
- reg = <0x1a>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(E, 6) IRQ_TYPE_LEVEL_LOW>;
- nuvoton,jkdet-enable;
- nuvoton,jkdet-pull-enable;
- nuvoton,jkdet-pull-up;
- nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
- nuvoton,vref-impedance = <2>;
- nuvoton,micbias-voltage = <6>;
- // Setup 4 buttons impedance according to Android specification
- nuvoton,sar-threshold-num = <4>;
- nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
- nuvoton,sar-hysteresis = <1>;
- nuvoton,sar-voltage = <0>;
- nuvoton,sar-compare-time = <0>;
- nuvoton,sar-sampling-time = <0>;
- nuvoton,short-key-debounce = <2>;
- nuvoton,jack-insert-debounce = <7>;
- nuvoton,jack-eject-debounce = <7>;
- nuvoton,crosstalk-enable;
-
- clock-names = "mclk";
- clocks = <&tegra_pmc TEGRA_PMC_CLK_OUT_2>;
- };
diff --git a/Documentation/devicetree/bindings/sound/neofidelity,ntp8835.yaml b/Documentation/devicetree/bindings/sound/neofidelity,ntp8835.yaml
new file mode 100644
index 000000000000..44d72a2ddfc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/neofidelity,ntp8835.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/neofidelity,ntp8835.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NeoFidelity NTP8835/NTP8835C Amplifiers
+
+maintainers:
+ - Igor Prusov <ivprusov@salutedevices.com>
+
+description: |
+ The NTP8835 is a single chip full digital audio amplifier
+ including power stages for stereo amplifier systems.
+ NTP8835 is integrated with versatile digital audio signal
+ processing functions, high-performance, high-fidelity fully
+ digital PWM modulator and two high-power full-bridge MOSFET
+ power stages. NTP8835C has identical programming interface,
+ but has different output signal characteristics.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - neofidelity,ntp8835
+ - neofidelity,ntp8835c
+
+ reg:
+ enum:
+ - 0x2a
+ - 0x2b
+ - 0x2c
+ - 0x2d
+
+ reset-gpios:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: wck
+ - const: bck
+ - const: scl
+ - const: mclk
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@2b {
+ compatible = "neofidelity,ntp8835";
+ #sound-dai-cells = <0>;
+ reg = <0x2b>;
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ clocks = <&clkc 551>, <&clkc 552>, <&clkc 553>, <&clkc 554>;
+ clock-names = "wck", "bck", "scl", "mclk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml b/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml
new file mode 100644
index 000000000000..6946177e391a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/neofidelity,ntp8918.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/neofidelity,ntp8918.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NeoFidelity NTP8918 Amplifier
+
+maintainers:
+ - Igor Prusov <ivprusov@salutedevices.com>
+
+description:
+ The NTP8918 is a single chip full digital audio amplifier
+ including power stage for stereo amplifier system.
+ The NTP8918 is integrated with versatile digital audio signal
+ processing functions, high-performance, high-fidelity fully
+ digital PWM modulator and two high-power full-bridge MOSFET
+ power stages.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - neofidelity,ntp8918
+
+ reg:
+ enum:
+ - 0x2a
+ - 0x2b
+ - 0x2c
+ - 0x2d
+
+ reset-gpios:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: wck
+ - const: scl
+ - const: bck
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@2a {
+ compatible = "neofidelity,ntp8918";
+ #sound-dai-cells = <0>;
+ reg = <0x2a>;
+ clocks = <&clkc 150>, <&clkc 151>, <&clkc 152>;
+ clock-names = "wck", "scl", "bck";
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml
new file mode 100644
index 000000000000..24006e9dc501
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8315.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8315.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8315/NAU8318 Mono Class-D Amplifier
+
+maintainers:
+ - David Lin <CTLIN0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8315
+ - nuvoton,nau8318
+
+ '#sound-dai-cells':
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+ description:
+ GPIO specifier for the chip's device enable input(EN) pin.
+ If this option is not specified then driver does not manage
+ the pin state (e.g. chip is always on).
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ codec {
+ compatible = "nuvoton,nau8315";
+ #sound-dai-cells = <0>;
+ enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml
new file mode 100644
index 000000000000..979be0d336da
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8325.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8325.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8325 audio Amplifier
+
+maintainers:
+ - Seven Lee <WTLI@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: nuvoton,nau8325
+
+ reg:
+ maxItems: 1
+
+ nuvoton,vref-impedance-ohms:
+ description:
+ The vref impedance to be used in ohms. Middle of voltage enables
+ Tie-Off selection options. Due to the high impedance of the VREF
+ pin, it is important to use a low-leakage capacitor.
+
+ enum: [0, 25000, 125000, 2500]
+
+ nuvoton,dac-vref-microvolt:
+ description:
+ The DAC vref to be used in voltage. DAC reference voltage setting. Can
+ be used for minor tuning of the output level. Since the VDDA is range
+ between 1.62 to 1.98 voltage, the typical value for design is 1.8V. After
+ the minor tuning, the final microvolt are as the below.
+
+ enum: [1800000, 2700000, 2880000, 3060000]
+
+ nuvoton,alc-enable:
+ description:
+ Enable digital automatic level control (ALC) function.
+ type: boolean
+
+ nuvoton,clock-detection-disable:
+ description:
+ When clock detection is enabled, it will detect whether MCLK
+ and FS are within the range. MCLK range is from 2.048MHz to 24.576MHz.
+ FS range is from 8kHz to 96kHz. And also needs to detect the ratio
+ MCLK_SRC/LRCK of 256, 400 or 500, and needs to detect the BCLK
+ to make sure data is present. There needs to be at least 8 BCLK
+ cycles per Frame Sync.
+ type: boolean
+
+ nuvoton,clock-det-data:
+ description:
+ Request clock detection to require 2048 non-zero samples before enabling
+ the audio paths. If set then non-zero samples is required, otherwise it
+ doesn't matter.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@21 {
+ compatible = "nuvoton,nau8325";
+ reg = <0x21>;
+ nuvoton,vref-impedance-ohms = <125000>;
+ nuvoton,dac-vref-microvolt = <2880000>;
+ nuvoton,alc-enable;
+ nuvoton,clock-det-data;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml
new file mode 100644
index 000000000000..9f44168efb3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8821.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8821.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU88L21 audio codec
+
+maintainers:
+ - Seven Lee <wtli@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: nuvoton,nau8821
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ nuvoton,jkdet-enable:
+ description: Enable jack detection via JKDET pin.
+ type: boolean
+
+ nuvoton,jkdet-pull-enable:
+ description: Enable JKDET pin pull. If set - pin pull enabled,
+ otherwise pin in high impedance state.
+ type: boolean
+
+ nuvoton,jkdet-pull-up:
+ description: Pull-up JKDET pin. If set then JKDET pin is pull up,
+ otherwise pull down.
+ type: boolean
+
+ nuvoton,key-enable:
+ description: handles key press detection.
+ type: boolean
+
+ nuvoton,jkdet-polarity:
+ description: JKDET pin polarity.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # active high
+ - 1 # active low
+ default: 1
+
+ nuvoton,micbias-voltage:
+ description: MICBIAS output level select.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA * 1
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,vref-impedance:
+ description: VMID Tie-off impedance select.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # open
+ - 1 # 25KOhms
+ - 2 # 125KOhms
+ - 3 # 2.5KOhms
+ default: 2
+
+ nuvoton,jack-insert-debounce:
+ description: number from 0 to 7 that sets debounce time to 2^(n+2)ms.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 7
+
+ nuvoton,jack-eject-debounce:
+ description: number from 0 to 7 that sets debounce time to 2^(n+2)ms.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 0
+
+ nuvoton,dmic-clk-threshold:
+ description: DMIC clock speed expected value. Unit is Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 3072000
+
+ nuvoton,dmic-slew-rate:
+ description: The range 0 to 7 represents the speed of DMIC slew rate.
+ The lowest value 0 means the slowest rate and the highest value
+ 7 means the fastest rate.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 7
+ default: 0
+
+ nuvoton,left-input-single-end:
+ description: Enable left input with single-ended settings if set.
+ For the headset mic application, the single-ended control is
+ just limited to the left adc for design demand.
+ type: boolean
+
+ nuvoton,adc-delay-ms:
+ description: Delay (in ms) to make input path stable and avoid pop noise.
+ minimum: 125
+ maximum: 500
+ default: 125
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1b {
+ compatible = "nuvoton,nau8821";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+ nuvoton,jkdet-enable;
+ nuvoton,jkdet-pull-enable;
+ nuvoton,jkdet-pull-up;
+ nuvoton,key-enable;
+ nuvoton,left-input-single-end;
+ nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
+ nuvoton,micbias-voltage = <6>;
+ nuvoton,vref-impedance = <2>;
+ nuvoton,jack-insert-debounce = <7>;
+ nuvoton,jack-eject-debounce = <0>;
+ nuvoton,dmic-clk-threshold = <3072000>;
+ nuvoton,dmic-slew-rate = <0>;
+ nuvoton,adc-delay-ms = <125>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
new file mode 100644
index 000000000000..cb8182bbc491
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8822.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8822.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8822 audio CODEC
+
+description: |
+ 24 bit stereo audio codec with speaker driver.
+ This device supports I2C/SPI.
+
+maintainers:
+ - David Lin <CTLIN0@nuvoton.com>
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8822
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+ nuvoton,spk-btl:
+ description:
+ If set, configure the two loudspeaker outputs as a Bridge Tied Load output
+ to drive a high power external loudspeaker.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "nuvoton,nau8822";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml
new file mode 100644
index 000000000000..232dc16a94a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8824.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8824.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8824 audio CODEC
+
+maintainers:
+ - John Hsu <KCHSU0@nuvoton.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8824
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ clocks:
+ items:
+ - description: The phandle of the master clock to the CODEC
+
+ clock-names:
+ items:
+ - const: mclk
+
+ interrupts:
+ maxItems: 1
+
+ nuvoton,jkdet-polarity:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ JKDET pin polarity.
+ enum:
+ - 0 # active high
+ - 1 # active low
+ default: 1
+
+ nuvoton,vref-impedance:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ VREF Impedance selection.
+ enum:
+ - 0 # Open
+ - 1 # 25 kOhm
+ - 2 # 125 kOhm
+ - 3 # 2.5 kOhm
+ default: 2
+
+ nuvoton,micbias-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Micbias voltage level.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-threshold-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of buttons supported.
+ minimum: 1
+ maximum: 8
+ default: 4
+
+ nuvoton,sar-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Impedance threshold for each button. Array that contains up to 8 buttons
+ configuration. SAR value is calculated as
+ SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) where MICBIAS is
+ configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by
+ 'nuvoton,sar-voltage', R - button impedance.
+ Refer datasheet section 10.2 for more information about threshold
+ calculation.
+ minItems: 1
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 255
+
+ nuvoton,sar-hysteresis:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button impedance measurement hysteresis.
+ default: 0
+
+ nuvoton,sar-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Reference voltage for button impedance measurement.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-compare-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR compare time.
+ enum:
+ - 0 # 500ns
+ - 1 # 1us
+ - 2 # 2us
+ - 3 # 4us
+ default: 1
+
+ nuvoton,sar-sampling-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR sampling time.
+ enum:
+ - 0 # 2us
+ - 1 # 4us
+ - 2 # 8us
+ - 3 # 16us
+ default: 1
+
+ nuvoton,short-key-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button short key press debounce time.
+ enum:
+ - 0 # 30 ms
+ - 1 # 50 ms
+ - 2 # 100 ms
+ default: 0
+
+ nuvoton,jack-eject-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Jack ejection debounce time.
+ enum:
+ - 0 # 0 ms
+ - 1 # 1 ms
+ - 2 # 10 ms
+ default: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ #sound-dai-cells = <0>;
+ compatible = "nuvoton,nau8824";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+ nuvoton,vref-impedance = <2>;
+ nuvoton,micbias-voltage = <6>;
+ nuvoton,sar-threshold-num = <4>;
+ // Setup 4 buttons impedance according to Android specification
+ nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
+ nuvoton,sar-hysteresis = <0>;
+ nuvoton,sar-voltage = <6>;
+ nuvoton,sar-compare-time = <1>;
+ nuvoton,sar-sampling-time = <1>;
+ nuvoton,short-key-debounce = <0>;
+ nuvoton,jack-eject-debounce = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml b/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml
new file mode 100644
index 000000000000..4ebbcb4e6056
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nuvoton,nau8825.yaml
@@ -0,0 +1,253 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nuvoton,nau8825.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NAU8825 audio CODEC
+
+maintainers:
+ - John Hsu <KCHSU0@nuvoton.com>
+
+description: |
+ NAU8825 audio CODEC
+
+ Pins on the device (for linking into audio routes):
+
+ Outputs:
+ * HPOL : Headphone Left Output
+ * HPOR : Headphone Right Output
+ * MICBIAS : Microphone Bias Output
+
+ Inputs:
+ * MICP : Analog Microphone Positive Input
+ * MICN : Analog Microphone Negative Input
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,nau8825
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ nuvoton,jkdet-enable:
+ description:
+ Enable jack detection via JKDET pin.
+ type: boolean
+
+ nuvoton,jkdet-pull-enable:
+ description:
+ Enable JKDET pin pull.
+ If set - pin pull enabled, otherwise pin in high impedance state.
+ type: boolean
+
+ nuvoton,jkdet-pull-up:
+ description:
+ Pull-up JKDET pin.
+ If set then JKDET pin is pull up, otherwise pull down.
+ type: boolean
+
+ nuvoton,jkdet-polarity:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ JKDET pin polarity.
+ enum:
+ - 0 # active high
+ - 1 # active low
+ default: 1
+
+ nuvoton,vref-impedance:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ VREF Impedance selection.
+ enum:
+ - 0 # Open
+ - 1 # 25 kOhm
+ - 2 # 125 kOhm
+ - 3 # 2.5 kOhm
+ default: 2
+
+ nuvoton,micbias-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Micbias voltage level.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-threshold-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Number of buttons supported.
+ minimum: 1
+ maximum: 4
+ default: 4
+
+ nuvoton,sar-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Impedance threshold for each button. Array that contains up to 8 buttons
+ configuration. SAR value is calculated as
+ SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) where MICBIAS is
+ configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by
+ 'nuvoton,sar-voltage', R - button impedance.
+ Refer datasheet section 10.2 for more information about threshold
+ calculation.
+ minItems: 1
+ maxItems: 4
+ items:
+ minimum: 0
+ maximum: 255
+
+ nuvoton,sar-hysteresis:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button impedance measurement hysteresis.
+ default: 0
+
+ nuvoton,sar-voltage:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Reference voltage for button impedance measurement.
+ enum:
+ - 0 # VDDA
+ - 1 # VDDA
+ - 2 # VDDA * 1.1
+ - 3 # VDDA * 1.2
+ - 4 # VDDA * 1.3
+ - 5 # VDDA * 1.4
+ - 6 # VDDA * 1.53
+ - 7 # VDDA * 1.53
+ default: 6
+
+ nuvoton,sar-compare-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR compare time.
+ enum:
+ - 0 # 500 ns
+ - 1 # 1 us
+ - 2 # 2 us
+ - 3 # 4 us
+ default: 1
+
+ nuvoton,sar-sampling-time:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ SAR sampling time.
+ enum:
+ - 0 # 2 us
+ - 1 # 4 us
+ - 2 # 8 us
+ - 3 # 16 us
+ default: 1
+
+ nuvoton,short-key-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Button short key press debounce time.
+ enum:
+ - 0 # 30 ms
+ - 1 # 50 ms
+ - 2 # 100 ms
+ - 3 # 30 ms
+ default: 3
+
+ nuvoton,jack-insert-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ number from 0 to 7 that sets debounce time to 2^(n+2) ms.
+ maximum: 7
+ default: 7
+
+ nuvoton,jack-eject-debounce:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ number from 0 to 7 that sets debounce time to 2^(n+2) ms
+ maximum: 7
+ default: 0
+
+ nuvoton,crosstalk-enable:
+ description:
+ make crosstalk function enable if set.
+ type: boolean
+
+ nuvoton,adcout-drive-strong:
+ description:
+ make the drive strength of ADCOUT IO PIN strong if set.
+ Otherwise, the drive keeps normal strength.
+ type: boolean
+
+ nuvoton,adc-delay-ms:
+ description:
+ Delay (in ms) to make input path stable and avoid pop noise.
+ The default value is 125 and range between 125 to 500 ms.
+ minimum: 125
+ maximum: 500
+ default: 125
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ #sound-dai-cells = <0>;
+ compatible = "nuvoton,nau8825";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+ nuvoton,jkdet-enable;
+ nuvoton,jkdet-pull-enable;
+ nuvoton,jkdet-pull-up;
+ nuvoton,jkdet-polarity = <GPIO_ACTIVE_LOW>;
+ nuvoton,vref-impedance = <2>;
+ nuvoton,micbias-voltage = <6>;
+ // Setup 4 buttons impedance according to Android specification
+ nuvoton,sar-threshold-num = <4>;
+ nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>;
+ nuvoton,sar-hysteresis = <1>;
+ nuvoton,sar-voltage = <0>;
+ nuvoton,sar-compare-time = <0>;
+ nuvoton,sar-sampling-time = <0>;
+ nuvoton,short-key-debounce = <2>;
+ nuvoton,jack-insert-debounce = <7>;
+ nuvoton,jack-eject-debounce = <7>;
+ nuvoton,crosstalk-enable;
+
+ clock-names = "mclk";
+ clocks = <&tegra_pmc 1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml
index 7ef774910e5c..96f2f927a6f5 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml
@@ -31,10 +31,10 @@ properties:
items:
enum:
# Board Connectors
- - "Headset Stereophone"
- - "Int Spk"
- - "Headset Mic"
- - "Digital Mic"
+ - Headset Stereophone
+ - Int Spk
+ - Headset Mic
+ - Digital Mic
# CODEC Pins
- SPKOUT
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml
index 82801b4f46dd..2588589ad62d 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common properties for NVIDIA Tegra audio complexes
@@ -80,4 +80,8 @@ properties:
type: boolean
description: The Mic Jack represents state of the headset microphone pin
+ nvidia,coupled-mic-hp-det:
+ type: boolean
+ description: The Mic detect GPIO is viable only if HP detect GPIO is active
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml
index b4bee466d67a..da89523ccf5f 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml
@@ -23,6 +23,7 @@ properties:
enum:
- nvidia,tegra210-audio-graph-card
- nvidia,tegra186-audio-graph-card
+ - nvidia,tegra264-audio-graph-card
clocks:
minItems: 2
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml
new file mode 100644
index 000000000000..241d20f3aad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-max9808x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra audio complex with MAX9808x CODEC
+
+maintainers:
+ - Jon Hunter <jonathanh@nvidia.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+
+allOf:
+ - $ref: nvidia,tegra-audio-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - pattern: '^[a-z0-9]+,tegra-audio-max98088(-[a-z0-9]+)+$'
+ - const: nvidia,tegra-audio-max98088
+ - items:
+ - pattern: '^[a-z0-9]+,tegra-audio-max98089(-[a-z0-9]+)+$'
+ - const: nvidia,tegra-audio-max98089
+
+ nvidia,audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the pins (documented in the binding document),
+ and the jacks on the board.
+ minItems: 2
+ items:
+ enum:
+ # Board Connectors
+ - Int Spk
+ - Headphone Jack
+ - Earpiece
+ - Headset Mic
+ - Internal Mic 1
+ - Internal Mic 2
+
+ # CODEC Pins
+ - HPL
+ - HPR
+ - SPKL
+ - SPKR
+ - RECL
+ - RECR
+ - INA1
+ - INA2
+ - INB1
+ - INB2
+ - MIC1
+ - MIC2
+ - MICBIAS
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+ #include <dt-bindings/soc/tegra-pmc.h>
+ sound {
+ compatible = "lg,tegra-audio-max98089-p895",
+ "nvidia,tegra-audio-max98089";
+ nvidia,model = "LG Optimus Vu MAX98089";
+
+ nvidia,audio-routing =
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "Int Spk", "SPKL",
+ "Int Spk", "SPKR",
+ "Earpiece", "RECL",
+ "Earpiece", "RECR",
+ "INA1", "Headset Mic",
+ "MIC1", "MICBIAS",
+ "MICBIAS", "Internal Mic 1",
+ "MIC2", "Internal Mic 2";
+
+ nvidia,i2s-controller = <&tegra_i2s0>;
+ nvidia,audio-codec = <&codec>;
+
+ clocks = <&tegra_car TEGRA30_CLK_PLL_A>,
+ <&tegra_car TEGRA30_CLK_PLL_A_OUT0>,
+ <&tegra_pmc TEGRA_PMC_CLK_OUT_1>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml
index ccc2ee77ca30..4d912458b18b 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml
@@ -38,10 +38,10 @@ properties:
items:
enum:
# Board Connectors
- - "Headphones"
- - "Speakers"
- - "Mic Jack"
- - "Int Mic"
+ - Headphones
+ - Speakers
+ - Mic Jack
+ - Int Mic
# CODEC Pins
- MIC1
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml
new file mode 100644
index 000000000000..0c8067c3b056
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-rt5631.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra audio complex with RT5631 CODEC
+
+maintainers:
+ - Jon Hunter <jonathanh@nvidia.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+
+allOf:
+ - $ref: nvidia,tegra-audio-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - pattern: '^[a-z0-9]+,tegra-audio-rt5631(-[a-z0-9]+)+$'
+ - const: nvidia,tegra-audio-rt5631
+
+ nvidia,audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the pins (documented in the binding document),
+ and the jacks on the board.
+ minItems: 2
+ items:
+ enum:
+ # Board Connectors
+ - Int Spk
+ - Headphone Jack
+ - Mic Jack
+ - Int Mic
+
+ # CODEC Pins
+ - MIC1
+ - MIC2
+ - AXIL
+ - AXIR
+ - MONOIN_RXN
+ - MONOIN_RXP
+ - DMIC
+ - MIC Bias1
+ - MIC Bias2
+ - MONO_IN
+ - AUXO1
+ - AUXO2
+ - SPOL
+ - SPOR
+ - HPOL
+ - HPOR
+ - MONO
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+ #include <dt-bindings/soc/tegra-pmc.h>
+ sound {
+ compatible = "asus,tegra-audio-rt5631-tf700t",
+ "nvidia,tegra-audio-rt5631";
+ nvidia,model = "Asus Transformer Infinity TF700T RT5631";
+
+ nvidia,audio-routing =
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR",
+ "Int Spk", "SPOL",
+ "Int Spk", "SPOR",
+ "MIC1", "MIC Bias1",
+ "MIC Bias1", "Mic Jack",
+ "DMIC", "Int Mic";
+
+ nvidia,i2s-controller = <&tegra_i2s1>;
+ nvidia,audio-codec = <&rt5631>;
+
+ clocks = <&tegra_car TEGRA30_CLK_PLL_A>,
+ <&tegra_car TEGRA30_CLK_PLL_A_OUT0>,
+ <&tegra_pmc TEGRA_PMC_CLK_OUT_1>;
+ clock-names = "pll_a", "pll_a_out0", "mclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml
index b1deaf271afa..2638592435b2 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml
@@ -31,9 +31,9 @@ properties:
items:
enum:
# Board Connectors
- - "Headphones"
- - "Speakers"
- - "Mic Jack"
+ - Headphones
+ - Speakers
+ - Mic Jack
# CODEC Pins
- DMIC1
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml
index a49997d6028b..09e1d0b18d27 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml
@@ -31,11 +31,11 @@ properties:
items:
enum:
# Board Connectors
- - "Headphone"
- - "Speaker"
- - "Headset Mic"
- - "Internal Mic 1"
- - "Internal Mic 2"
+ - Headphone
+ - Speaker
+ - Headset Mic
+ - Internal Mic 1
+ - Internal Mic 2
# CODEC Pins
- IN1P
@@ -47,14 +47,14 @@ properties:
- DMIC2
- DMIC3
- DMIC4
- - "DMIC L1"
- - "DMIC L2"
- - "DMIC L3"
- - "DMIC L4"
- - "DMIC R1"
- - "DMIC R2"
- - "DMIC R3"
- - "DMIC R4"
+ - DMIC L1
+ - DMIC L2
+ - DMIC L3
+ - DMIC L4
+ - DMIC R1
+ - DMIC R2
+ - DMIC R3
+ - DMIC R4
- LOUT1
- LOUT2
- LOUT3
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml
index 943e7c01741c..e5bc6a6ade24 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml
@@ -31,9 +31,9 @@ properties:
items:
enum:
# Board Connectors
- - "Headphone Jack"
- - "Line In Jack"
- - "Mic Jack"
+ - Headphone Jack
+ - Line In Jack
+ - Mic Jack
# CODEC Pins
- HP_OUT
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml
index a5b431d7d0c2..3323d6a438f5 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml
@@ -31,8 +31,8 @@ properties:
items:
enum:
# Board Connectors
- - "Headphone Jack"
- - "Mic Jack"
+ - Headphone Jack
+ - Mic Jack
# CODEC Pins
- LOUT1
@@ -53,7 +53,7 @@ properties:
- MIC1
- MIC2N
- MIC2
- - "Mic Bias"
+ - Mic Bias
required:
- nvidia,i2s-controller
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml
index 1b836acab980..1be25ce4514b 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml
@@ -35,10 +35,10 @@ properties:
items:
enum:
# Board Connectors
- - "Headphone Jack"
- - "Int Spk"
- - "Mic Jack"
- - "Int Mic"
+ - Headphone Jack
+ - Int Spk
+ - Mic Jack
+ - Int Mic
# CODEC Pins
- IN1L
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml
index a1448283344b..397306b8800d 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml
@@ -31,9 +31,9 @@ properties:
items:
enum:
# Board Connectors
- - "Headphone"
- - "LineIn"
- - "Mic"
+ - Headphone
+ - LineIn
+ - Mic
# CODEC Pins
- MONOOUT
@@ -48,7 +48,7 @@ properties:
- PCBEEP
- MIC1
- MIC2
- - "Mic Bias"
+ - Mic Bias
required:
- nvidia,ac97-controller
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml
index 520d0d063d1a..66b56e71599b 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-asrc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra186-asrc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra186 ASRC Device Tree Bindings
+title: Tegra186 ASRC
description: |
Asynchronous Sample Rate Converter (ASRC) converts the sampling frequency
@@ -23,7 +23,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -31,7 +31,9 @@ properties:
compatible:
oneOf:
- - const: nvidia,tegra186-asrc
+ - enum:
+ - nvidia,tegra186-asrc
+ - nvidia,tegra264-asrc
- items:
- enum:
- nvidia,tegra234-asrc
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml
index 73b98b2f3543..46ba167081ef 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra186-dspk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra186 DSPK Controller Device Tree Bindings
+title: Tegra186 DSPK Controller
description: |
The Digital Speaker Controller (DSPK) can be viewed as a Pulse
@@ -18,7 +18,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -29,6 +29,7 @@ properties:
- const: nvidia,tegra186-dspk
- items:
- enum:
+ - nvidia,tegra264-dspk
- nvidia,tegra234-dspk
- nvidia,tegra194-dspk
- const: nvidia,tegra186-dspk
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
deleted file mode 100644
index eaf00102d92c..000000000000
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-NVIDIA Tegra 20 AC97 controller
-
-Required properties:
-- compatible : "nvidia,tegra20-ac97"
-- reg : Should contain AC97 controller registers location and length
-- interrupts : Should contain AC97 interrupt
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - ac97
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number
- of the GPIO used to reset the external AC97 codec
-- nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number
- of the GPIO corresponding with the AC97 DAP _FS line
-
-Example:
-
-ac97@70002000 {
- compatible = "nvidia,tegra20-ac97";
- reg = <0x70002000 0x200>;
- interrupts = <0 81 0x04>;
- nvidia,codec-reset-gpio = <&gpio 170 0>;
- nvidia,codec-sync-gpio = <&gpio 120 0>;
- clocks = <&tegra_car 3>;
- resets = <&tegra_car 3>;
- reset-names = "ac97";
- dmas = <&apbdma 12>, <&apbdma 12>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml
new file mode 100644
index 000000000000..4ea0a303d995
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra20-ac97.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 AC97 controller
+
+maintainers:
+ - Thierry Reding <treding@nvidia.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra20-ac97
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: ac97
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ nvidia,codec-reset-gpios:
+ description: Reset pin of external AC97 codec
+ maxItems: 1
+
+ nvidia,codec-sync-gpios:
+ description: AC97 DAP _FS line
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+ - interrupts
+ - clocks
+ - dmas
+ - dma-names
+ - nvidia,codec-reset-gpios
+ - nvidia,codec-sync-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ ac97@70002000 {
+ compatible = "nvidia,tegra20-ac97";
+ reg = <0x70002000 0x200>;
+ resets = <&tegra_car 3>;
+ reset-names = "ac97";
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car 3>;
+ dmas = <&apbdma 12>, <&apbdma 12>;
+ dma-names = "rx", "tx";
+ nvidia,codec-reset-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
+ nvidia,codec-sync-gpios = <&gpio TEGRA_GPIO(P, 0) GPIO_ACTIVE_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt
deleted file mode 100644
index 6de3a7ee4efb..000000000000
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-NVIDIA Tegra 20 DAS (Digital Audio Switch) controller
-
-Required properties:
-- compatible : "nvidia,tegra20-das"
-- reg : Should contain DAS registers location and length
-
-Example:
-
-das@70000c00 {
- compatible = "nvidia,tegra20-das";
- reg = <0x70000c00 0x80>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml
new file mode 100644
index 000000000000..44c5ce8ee6be
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra20-das.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra 20 DAS (Digital Audio Switch) controller
+
+maintainers:
+ - Thierry Reding <treding@nvidia.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra20-das
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ das@70000c00 {
+ compatible = "nvidia,tegra20-das";
+ reg = <0x70000c00 0x80>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
index 60a368a132b8..dc76a4dc0ed2 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml
@@ -16,6 +16,9 @@ maintainers:
- Thierry Reding <treding@nvidia.com>
- Jon Hunter <jonathanh@nvidia.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: nvidia,tegra20-spdif
@@ -66,7 +69,7 @@ required:
- dma-names
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml
index 372043edd98f..2ce4049f94ac 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-admaif.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 ADMAIF Device Tree Bindings
+title: Tegra210 ADMAIF
description: |
ADMAIF is the interface between ADMA and AHUB. Each ADMA channel
@@ -26,6 +26,7 @@ properties:
- enum:
- nvidia,tegra210-admaif
- nvidia,tegra186-admaif
+ - nvidia,tegra264-admaif
- items:
- enum:
- nvidia,tegra234-admaif
@@ -39,6 +40,19 @@ properties:
dma-names: true
+ interconnects:
+ items:
+ - description: APE read memory client
+ - description: APE write memory client
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
+
+ iommus:
+ maxItems: 1
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
@@ -53,43 +67,72 @@ properties:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
-if:
- properties:
- compatible:
- contains:
- const: nvidia,tegra210-admaif
-
-then:
- properties:
- dmas:
- description:
- DMA channel specifiers, equally divided for Tx and Rx.
- minItems: 1
- maxItems: 20
- dma-names:
- items:
- pattern: "^[rt]x(10|[1-9])$"
- description:
- Should be "rx1", "rx2" ... "rx10" for DMA Rx channel
- Should be "tx1", "tx2" ... "tx10" for DMA Tx channel
- minItems: 1
- maxItems: 20
-
-else:
- properties:
- dmas:
- description:
- DMA channel specifiers, equally divided for Tx and Rx.
- minItems: 1
- maxItems: 40
- dma-names:
- items:
- pattern: "^[rt]x(1[0-9]|[1-9]|20)$"
- description:
- Should be "rx1", "rx2" ... "rx20" for DMA Rx channel
- Should be "tx1", "tx2" ... "tx20" for DMA Tx channel
- minItems: 1
- maxItems: 40
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra210-admaif
+ then:
+ properties:
+ dmas:
+ description:
+ DMA channel specifiers, equally divided for Tx and Rx.
+ minItems: 1
+ maxItems: 20
+ dma-names:
+ items:
+ pattern: "^[rt]x(10|[1-9])$"
+ description:
+ Should be "rx1", "rx2" ... "rx10" for DMA Rx channel
+ Should be "tx1", "tx2" ... "tx10" for DMA Tx channel
+ minItems: 1
+ maxItems: 20
+ interconnects: false
+ interconnect-names: false
+ iommus: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-admaif
+ then:
+ properties:
+ dmas:
+ description:
+ DMA channel specifiers, equally divided for Tx and Rx.
+ minItems: 1
+ maxItems: 40
+ dma-names:
+ items:
+ pattern: "^[rt]x(1[0-9]|[1-9]|20)$"
+ description:
+ Should be "rx1", "rx2" ... "rx20" for DMA Rx channel
+ Should be "tx1", "tx2" ... "tx20" for DMA Tx channel
+ minItems: 1
+ maxItems: 40
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra264-admaif
+ then:
+ properties:
+ dmas:
+ description:
+ DMA channel specifiers, equally divided for Tx and Rx.
+ minItems: 1
+ maxItems: 64
+ dma-names:
+ items:
+ pattern: "^[rt]x(3[0-2]|[1-2][0-9]|[1-9])$"
+ description:
+ Should be "rx1", "rx2" ... "rx32" for DMA Rx channel
+ Should be "tx1", "tx2" ... "tx32" for DMA Tx channel
+ minItems: 1
+ maxItems: 64
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml
index 8d8dc7fb3f0c..19a80929f93e 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-adx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 ADX Device Tree Bindings
+title: Tegra210 ADX
description: |
The Audio Demultiplexer (ADX) block takes an input stream with up to
@@ -19,7 +19,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -27,7 +27,9 @@ properties:
compatible:
oneOf:
- - const: nvidia,tegra210-adx
+ - enum:
+ - nvidia,tegra210-adx
+ - nvidia,tegra264-adx
- items:
- enum:
- nvidia,tegra234-adx
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml
index 47b6e712e4fb..1c9f24d26819 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-ahub.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 AHUB Device Tree Bindings
+title: Tegra210 AHUB
description: |
The Audio Hub (AHUB) comprises a collection of hardware accelerators
@@ -27,6 +27,7 @@ properties:
- nvidia,tegra210-ahub
- nvidia,tegra186-ahub
- nvidia,tegra234-ahub
+ - nvidia,tegra264-ahub
- items:
- const: nvidia,tegra194-ahub
- const: nvidia,tegra186-ahub
@@ -50,10 +51,10 @@ properties:
maxItems: 1
"#address-cells":
- const: 1
+ enum: [ 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
ranges: true
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml
index f9e4fc6e0c47..89712102cfdf 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-amx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 AMX Device Tree Bindings
+title: Tegra210 AMX
description: |
The Audio Multiplexer (AMX) block can multiplex up to four input streams
@@ -18,7 +18,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -26,11 +26,13 @@ properties:
compatible:
oneOf:
- - const: nvidia,tegra210-amx
+ - enum:
+ - nvidia,tegra210-amx
+ - nvidia,tegra194-amx
+ - nvidia,tegra264-amx
- items:
- const: nvidia,tegra186-amx
- const: nvidia,tegra210-amx
- - const: nvidia,tegra194-amx
- items:
- const: nvidia,tegra234-amx
- const: nvidia,tegra194-amx
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml
index bcb496d3ace5..bb8088878d4b 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-dmic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 DMIC Controller Device Tree Bindings
+title: Tegra210 DMIC Controller
description: |
The Digital MIC (DMIC) Controller is used to interface with Pulse
@@ -17,7 +17,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -28,6 +28,7 @@ properties:
- const: nvidia,tegra210-dmic
- items:
- enum:
+ - nvidia,tegra264-dmic
- nvidia,tegra234-dmic
- nvidia,tegra194-dmic
- nvidia,tegra186-dmic
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml
index 6188f561f878..903e815af8fd 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-i2s.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 I2S Controller Device Tree Bindings
+title: Tegra210 I2S Controller
description: |
The Inter-IC Sound (I2S) controller implements full-duplex,
@@ -17,7 +17,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -25,7 +25,9 @@ properties:
compatible:
oneOf:
- - const: nvidia,tegra210-i2s
+ - enum:
+ - nvidia,tegra210-i2s
+ - nvidia,tegra264-i2s
- items:
- enum:
- nvidia,tegra234-i2s
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml
index 5b9198602fc6..4c121b9cde1e 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mbdrc.yaml
@@ -23,6 +23,7 @@ properties:
- const: nvidia,tegra210-mbdrc
- items:
- enum:
+ - nvidia,tegra264-mbdrc
- nvidia,tegra234-mbdrc
- nvidia,tegra194-mbdrc
- nvidia,tegra186-mbdrc
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml
index ee1e1d2da79a..56b4c4fc123c 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-mixer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 Mixer Device Tree Bindings
+title: Tegra210 Mixer
description: |
The Mixer supports mixing of up to ten 7.1 audio input streams and
@@ -17,7 +17,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -28,6 +28,7 @@ properties:
- const: nvidia,tegra210-amixer
- items:
- enum:
+ - nvidia,tegra264-amixer
- nvidia,tegra234-amixer
- nvidia,tegra194-amixer
- nvidia,tegra186-amixer
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml
index c9888c553e78..bde4ac6319b1 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-mvc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 MVC Device Tree Bindings
+title: Tegra210 MVC
description: |
The Master Volume Control (MVC) provides gain or attenuation to a digital
@@ -20,7 +20,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -31,6 +31,7 @@ properties:
- const: nvidia,tegra210-mvc
- items:
- enum:
+ - nvidia,tegra264-mvc
- nvidia,tegra234-mvc
- nvidia,tegra194-mvc
- nvidia,tegra186-mvc
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml
index 9dc9ba590fa3..756c3096a2d6 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ope.yaml
@@ -17,7 +17,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
compatible:
@@ -25,6 +25,7 @@ properties:
- const: nvidia,tegra210-ope
- items:
- enum:
+ - nvidia,tegra264-ope
- nvidia,tegra234-ope
- nvidia,tegra194-ope
- nvidia,tegra186-ope
@@ -34,10 +35,10 @@ properties:
maxItems: 1
"#address-cells":
- const: 1
+ enum: [ 1, 2 ]
"#size-cells":
- const: 1
+ enum: [ 1, 2 ]
ranges: true
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml
index 1e373c49d639..2f11a484dc2e 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-peq.yaml
@@ -24,6 +24,7 @@ properties:
- const: nvidia,tegra210-peq
- items:
- enum:
+ - nvidia,tegra264-peq
- nvidia,tegra234-peq
- nvidia,tegra194-peq
- nvidia,tegra186-peq
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml
index 8579306fc56f..959aa7fffdac 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/nvidia,tegra210-sfc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra210 SFC Device Tree Bindings
+title: Tegra210 SFC
description: |
The Sampling Frequency Converter (SFC) converts the sampling frequency
@@ -17,7 +17,7 @@ maintainers:
- Sameer Pujar <spujar@nvidia.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
$nodename:
@@ -28,6 +28,7 @@ properties:
- const: nvidia,tegra210-sfc
- items:
- enum:
+ - nvidia,tegra264-sfc
- nvidia,tegra234-sfc
- nvidia,tegra194-sfc
- nvidia,tegra186-sfc
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
index 12c31b4b99e1..8a8767589ee0 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
@@ -20,14 +20,17 @@ properties:
compatible:
oneOf:
- - const: nvidia,tegra30-hda
+ - enum:
+ - nvidia,tegra30-hda
+ - nvidia,tegra194-hda
+ - nvidia,tegra234-hda
+ - nvidia,tegra264-hda
- items:
- enum:
- - nvidia,tegra234-hda
- - nvidia,tegra194-hda
- nvidia,tegra186-hda
- nvidia,tegra210-hda
- nvidia,tegra124-hda
+ - nvidia,tegra114-hda
- const: nvidia,tegra30-hda
- items:
- const: nvidia,tegra132-hda
@@ -42,15 +45,12 @@ properties:
maxItems: 1
clocks:
- minItems: 2
+ minItems: 1
maxItems: 3
clock-names:
- minItems: 2
- items:
- - const: hda
- - const: hda2hdmi
- - const: hda2codec_2x
+ minItems: 1
+ maxItems: 3
resets:
minItems: 2
@@ -58,10 +58,7 @@ properties:
reset-names:
minItems: 2
- items:
- - const: hda
- - const: hda2hdmi
- - const: hda2codec_2x
+ maxItems: 3
power-domains:
maxItems: 1
@@ -92,6 +89,92 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra30-hda
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ items:
+ - const: hda
+ - const: hda2hdmi
+ - const: hda2codec_2x
+ resets:
+ minItems: 3
+ reset-names:
+ items:
+ - const: hda
+ - const: hda2hdmi
+ - const: hda2codec_2x
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-hda
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ items:
+ - const: hda
+ - const: hda2hdmi
+ - const: hda2codec_2x
+ resets:
+ maxItems: 2
+ reset-names:
+ items:
+ - const: hda
+ - const: hda2hdmi
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra234-hda
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: hda
+ - const: hda2codec_2x
+ resets:
+ maxItems: 2
+ reset-names:
+ items:
+ - const: hda
+ - const: hda2codec_2x
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra264-hda
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: hda
+ resets:
+ maxItems: 2
+ reset-names:
+ items:
+ - const: hda
+ - const: hda2codec_2x
+ power-domains: false
+
examples:
- |
#include<dt-bindings/clock/tegra124-car-common.h>
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
deleted file mode 100644
index 38caa936f6f8..000000000000
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-NVIDIA Tegra30 I2S controller
-
-Required properties:
-- compatible : For Tegra30, must contain "nvidia,tegra30-i2s". For Tegra124,
- must contain "nvidia,tegra124-i2s". Otherwise, must contain
- "nvidia,<chip>-i2s" plus at least one of the above, where <chip> is
- tegra114 or tegra132.
-- reg : Should contain I2S registers location and length
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - i2s
-- nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback)
- first, tx (capture) second. See nvidia,tegra30-ahub.txt for values.
-
-Example:
-
-i2s@70080300 {
- compatible = "nvidia,tegra30-i2s";
- reg = <0x70080300 0x100>;
- nvidia,ahub-cif-ids = <4 4>;
- clocks = <&tegra_car 11>;
- resets = <&tegra_car 11>;
- reset-names = "i2s";
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml
new file mode 100644
index 000000000000..89c3c6414ab1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra30-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra30 I2S controller
+
+maintainers:
+ - Thierry Reding <treding@nvidia.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra124-i2s
+ - nvidia,tegra30-i2s
+ - items:
+ - const: nvidia,tegra114-i2s
+ - const: nvidia,tegra30-i2s
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: i2s
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: i2s
+
+ nvidia,ahub-cif-ids:
+ description: list of AHUB CIF IDs
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: rx (playback)
+ - description: tx (capture)
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - reset-names
+ - nvidia,ahub-cif-ids
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+
+ i2s@70080300 {
+ compatible = "nvidia,tegra30-i2s";
+ reg = <0x70080300 0x100>;
+ nvidia,ahub-cif-ids = <4 4>;
+ clocks = <&tegra_car TEGRA30_CLK_I2S0>;
+ resets = <&tegra_car 30>;
+ reset-names = "i2s";
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml b/Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml
new file mode 100644
index 000000000000..40a0877a8aba
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nxp,lpc3220-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32XX I2S Controller
+
+description:
+ The I2S controller in LPC32XX SoCs, ASoC DAI.
+
+maintainers:
+ - J.M.B. Downing <jonathan.downing@nautel.com>
+ - Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - nxp,lpc3220-i2s
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: input clock of the peripheral.
+
+ dmas:
+ items:
+ - description: RX DMA Channel
+ - description: TX DMA Channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - dmas
+ - dma-names
+ - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc32xx-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2s@20094000 {
+ compatible = "nxp,lpc3220-i2s";
+ reg = <0x20094000 0x1000>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk LPC32XX_CLK_I2S0>;
+ dmas = <&dma 0 1>, <&dma 13 1>;
+ dma-names = "rx", "tx";
+ #sound-dai-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
index 7f2e68ff6d34..fd2415e231eb 100644
--- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
+++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
@@ -10,7 +10,7 @@ maintainers:
- Stephan Gerhold <stephan@gerhold.net>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
deleted file mode 100644
index ff98a0cb5b3f..000000000000
--- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Texas Instruments OMAP4+ McPDM
-
-Required properties:
-- compatible: "ti,omap4-mcpdm"
-- reg: Register location and size as an array:
- <MPU access base address, size>,
- <L3 interconnect address, size>;
-- interrupts: Interrupt number for McPDM
-- ti,hwmods: Name of the hwmod associated to the McPDM
-- clocks: phandle for the pdmclk provider, likely <&twl6040>
-- clock-names: Must be "pdmclk"
-
-Example:
-
-mcpdm: mcpdm@40132000 {
- compatible = "ti,omap4-mcpdm";
- reg = <0x40132000 0x7f>, /* MPU private access */
- <0x49032000 0x7f>; /* L3 Interconnect */
- interrupts = <0 112 0x4>;
- interrupt-parent = <&gic>;
- ti,hwmods = "mcpdm";
-};
-
-In board DTS file the pdmclk needs to be added:
-
-&mcpdm {
- clocks = <&twl6040>;
- clock-names = "pdmclk";
- status = "okay";
-};
diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
deleted file mode 100644
index f6a715e4ef43..000000000000
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* Texas Instruments SoC with twl4030 based audio setups
-
-Required properties:
-- compatible: "ti,omap-twl4030"
-- ti,model: Name of the sound card (for example "omap3beagle")
-- ti,mcbsp: phandle for the McBSP node
-
-Optional properties:
-- ti,codec: phandle for the twl4030 audio node
-- ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl
-- ti, jack-det-gpio: Jack detect GPIO
-- ti,audio-routing: List of connections between audio components.
- Each entry is a pair of strings, the first being the connection's sink,
- the second being the connection's source.
- If the routing is not provided all possible connection will be available
-
-Available audio endpoints for the audio-routing table:
-
-Board connectors:
- * Headset Stereophone
- * Earpiece Spk
- * Handsfree Spk
- * Ext Spk
- * Main Mic
- * Sub Mic
- * Headset Mic
- * Carkit Mic
- * Digital0 Mic
- * Digital1 Mic
- * Line In
-
-twl4030 pins:
- * HSOL
- * HSOR
- * EARPIECE
- * HFL
- * HFR
- * PREDRIVEL
- * PREDRIVER
- * CARKITL
- * CARKITR
- * MAINMIC
- * SUBMIC
- * HSMIC
- * DIGIMIC0
- * DIGIMIC1
- * CARKITMIC
- * AUXL
- * AUXR
-
- * Headset Mic Bias
- * Mic Bias 1 /* Used for Main Mic or Digimic0 */
- * Mic Bias 2 /* Used for Sub Mic or Digimic1 */
-
-Example:
-
-sound {
- compatible = "ti,omap-twl4030";
- ti,model = "omap3beagle";
-
- ti,mcbsp = <&mcbsp2>;
-};
diff --git a/Documentation/devicetree/bindings/sound/option,gtm601.yaml b/Documentation/devicetree/bindings/sound/option,gtm601.yaml
new file mode 100644
index 000000000000..ff813d97fc59
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/option,gtm601.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/option,gtm601.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GTM601 UMTS modem audio interface CODEC
+
+maintainers:
+ - kernel@puri.sm
+
+description: >
+ This device has no configuration interface. The sample rate and channels are
+ based on the compatible string
+
+properties:
+ compatible:
+ oneOf:
+ - description: Broadmobi BM818 (48Khz stereo)
+ items:
+ - const: broadmobi,bm818
+ - const: option,gtm601
+ - description: GTM601 (8kHz mono)
+ const: option,gtm601
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+
+allOf:
+ - $ref: dai-common.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ codec {
+ compatible = "option,gtm601";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/pcm1789.txt b/Documentation/devicetree/bindings/sound/pcm1789.txt
deleted file mode 100644
index 3c74ed220ac2..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm1789.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Texas Instruments pcm1789 DT bindings
-
-PCM1789 is a simple audio codec that can be connected via
-I2C or SPI. Currently, only I2C bus is supported.
-
-Required properties:
-
- - compatible: "ti,pcm1789"
-
-Required properties on I2C:
-
- - reg: the I2C address
- - reset-gpios: GPIO to control the RESET pin
-
-Examples:
-
- audio-codec@4c {
- compatible = "ti,pcm1789";
- reg = <0x4c>;
- reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>;
- #sound-dai-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/sound/pcm179x.txt b/Documentation/devicetree/bindings/sound/pcm179x.txt
deleted file mode 100644
index 436c2b247693..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm179x.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Texas Instruments pcm179x DT bindings
-
-This driver supports both the I2C and SPI bus.
-
-Required properties:
-
- - compatible: "ti,pcm1792a"
-
-For required properties on SPI, please consult
-Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Required properties on I2C:
-
- - reg: the I2C address
-
-
-Examples:
-
- codec_spi: 1792a@0 {
- compatible = "ti,pcm1792a";
- spi-max-frequency = <600000>;
- };
-
- codec_i2c: 1792a@4c {
- compatible = "ti,pcm1792a";
- reg = <0x4c>;
- };
diff --git a/Documentation/devicetree/bindings/sound/pcm186x.txt b/Documentation/devicetree/bindings/sound/pcm186x.txt
deleted file mode 100644
index 1087f4855980..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm186x.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Texas Instruments PCM186x Universal Audio ADC
-
-These devices support both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "ti,pcm1862",
- "ti,pcm1863",
- "ti,pcm1864",
- "ti,pcm1865"
-
- - reg : The I2C address of the device for I2C, the chip select
- number for SPI.
-
- - avdd-supply: Analog core power supply (3.3v)
- - dvdd-supply: Digital core power supply
- - iovdd-supply: Digital IO power supply
- See regulator/regulator.txt for more information
-
-CODEC input pins:
- * VINL1
- * VINR1
- * VINL2
- * VINR2
- * VINL3
- * VINR3
- * VINL4
- * VINR4
-
-The pins can be used in referring sound node's audio-routing property.
-
-Example:
-
- pcm186x: audio-codec@4a {
- compatible = "ti,pcm1865";
- reg = <0x4a>;
-
- avdd-supply = <&reg_3v3_analog>;
- dvdd-supply = <&reg_3v3>;
- iovdd-supply = <&reg_1v8>;
- };
diff --git a/Documentation/devicetree/bindings/sound/pcm5102a.txt b/Documentation/devicetree/bindings/sound/pcm5102a.txt
deleted file mode 100644
index c63ab0b6ee19..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm5102a.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-PCM5102a audio CODECs
-
-These devices does not use I2C or SPI.
-
-Required properties:
-
- - compatible : set as "ti,pcm5102a"
-
-Examples:
-
- pcm5102a: pcm5102a {
- compatible = "ti,pcm5102a";
- };
diff --git a/Documentation/devicetree/bindings/sound/pcm512x.txt b/Documentation/devicetree/bindings/sound/pcm512x.txt
deleted file mode 100644
index 3aae3b41bd8e..000000000000
--- a/Documentation/devicetree/bindings/sound/pcm512x.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-PCM512x audio CODECs
-
-These devices support both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : One of "ti,pcm5121", "ti,pcm5122", "ti,pcm5141" or
- "ti,pcm5142"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
- - AVDD-supply, DVDD-supply, and CPVDD-supply : power supplies for the
- device, as covered in bindings/regulator/regulator.txt
-
-Optional properties:
-
- - clocks : A clock specifier for the clock connected as SCLK. If this
- is absent the device will be configured to clock from BCLK. If pll-in
- and pll-out are specified in addition to a clock, the device is
- configured to accept clock input on a specified gpio pin.
-
- - pll-in, pll-out : gpio pins used to connect the pll using <1>
- through <6>. The device will be configured for clock input on the
- given pll-in pin and PLL output on the given pll-out pin. An
- external connection from the pll-out pin to the SCLK pin is assumed.
-
-Examples:
-
- pcm5122: pcm5122@4c {
- compatible = "ti,pcm5122";
- reg = <0x4c>;
-
- AVDD-supply = <&reg_3v3_analog>;
- DVDD-supply = <&reg_1v8>;
- CPVDD-supply = <&reg_3v3>;
- };
-
-
- pcm5142: pcm5142@4c {
- compatible = "ti,pcm5142";
- reg = <0x4c>;
-
- AVDD-supply = <&reg_3v3_analog>;
- DVDD-supply = <&reg_1v8>;
- CPVDD-supply = <&reg_3v3>;
-
- clocks = <&sck>;
- pll-in = <3>;
- pll-out = <6>;
- };
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml
new file mode 100644
index 000000000000..6ad451549036
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc-sndcard.yaml
@@ -0,0 +1,205 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,apq8016-sbc-sndcard.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm APQ8016 and similar sound cards
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ - Stephan Gerhold <stephan@gerhold.net>
+
+properties:
+ compatible:
+ enum:
+ - qcom,apq8016-sbc-sndcard
+ - qcom,msm8916-qdsp6-sndcard
+
+ reg:
+ items:
+ - description: Microphone I/O mux register address
+ - description: Speaker I/O mux register address
+
+ reg-names:
+ items:
+ - const: mic-iomux
+ - const: spkr-iomux
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source. Valid names could be power supplies,
+ MicBias of codec and the jacks on the board.
+
+ aux-devs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ List of phandles pointing to auxiliary devices, such
+ as amplifiers, to be added to the sound card.
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User visible long sound card name
+
+ pin-switches:
+ description: List of widget names for which pin switches should be created.
+ $ref: /schemas/types.yaml#/definitions/string-array
+
+ widgets:
+ description: User specified audio sound widgets.
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+
+patternProperties:
+ ".*-dai-link$":
+ description:
+ Each subnode represents a dai link. Subnodes of each dai links would be
+ cpu/codec dais.
+
+ type: object
+
+ properties:
+ link-name:
+ description: Indicates dai-link name and PCM stream name.
+ $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
+
+ cpu:
+ description: Holds subnode which indicates cpu dai.
+ type: object
+ additionalProperties: false
+
+ properties:
+ sound-dai:
+ maxItems: 1
+
+ platform:
+ description: Holds subnode which indicates platform dai.
+ type: object
+ additionalProperties: false
+
+ properties:
+ sound-dai:
+ maxItems: 1
+
+ codec:
+ description: Holds subnode which indicates codec dai.
+ type: object
+ additionalProperties: false
+
+ properties:
+ sound-dai:
+ minItems: 1
+ maxItems: 8
+
+ required:
+ - link-name
+ - cpu
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - model
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/sound/qcom,lpass.h>
+ sound@7702000 {
+ compatible = "qcom,apq8016-sbc-sndcard";
+ reg = <0x07702000 0x4>, <0x07702004 0x4>;
+ reg-names = "mic-iomux", "spkr-iomux";
+
+ model = "DB410c";
+ audio-routing =
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+
+ pinctrl-0 = <&cdc_pdm_lines_act &ext_sec_tlmm_lines_act &ext_mclk_tlmm_lines_act>;
+ pinctrl-1 = <&cdc_pdm_lines_sus &ext_sec_tlmm_lines_sus &ext_mclk_tlmm_lines_sus>;
+ pinctrl-names = "default", "sleep";
+
+ quaternary-dai-link {
+ link-name = "ADV7533";
+ cpu {
+ sound-dai = <&lpass MI2S_QUATERNARY>;
+ };
+ codec {
+ sound-dai = <&adv_bridge 0>;
+ };
+ };
+
+ primary-dai-link {
+ link-name = "WCD";
+ cpu {
+ sound-dai = <&lpass MI2S_PRIMARY>;
+ };
+ codec {
+ sound-dai = <&lpass_codec 0>, <&wcd_codec 0>;
+ };
+ };
+
+ tertiary-dai-link {
+ link-name = "WCD-Capture";
+ cpu {
+ sound-dai = <&lpass MI2S_TERTIARY>;
+ };
+ codec {
+ sound-dai = <&lpass_codec 1>, <&wcd_codec 1>;
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ #include <dt-bindings/sound/qcom,q6asm.h>
+ sound@7702000 {
+ compatible = "qcom,msm8916-qdsp6-sndcard";
+ reg = <0x07702000 0x4>, <0x07702004 0x4>;
+ reg-names = "mic-iomux", "spkr-iomux";
+
+ model = "msm8916";
+ widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones";
+ pin-switches = "Speaker";
+ audio-routing =
+ "Speaker", "Speaker Amp OUT",
+ "Speaker Amp IN", "HPH_R",
+ "Headphones", "HPH_L",
+ "Headphones", "HPH_R",
+ "AMIC1", "MIC BIAS Internal1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS Internal3";
+ aux-devs = <&speaker_amp>;
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&cdc_pdm_lines_act>;
+ pinctrl-1 = <&cdc_pdm_lines_sus>;
+
+ mm1-dai-link {
+ link-name = "MultiMedia1";
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ primary-dai-link {
+ link-name = "Primary MI2S";
+ cpu {
+ sound-dai = <&q6afedai PRIMARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <&q6routing>;
+ };
+ codec {
+ sound-dai = <&lpass_codec 0>, <&wcd_codec 0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
deleted file mode 100644
index e1b9fa8a5bf8..000000000000
--- a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
+++ /dev/null
@@ -1,128 +0,0 @@
-* Qualcomm Technologies APQ8096 ASoC sound card driver
-
-This binding describes the APQ8096 sound card, which uses qdsp for audio.
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: must be "qcom,apq8096-sndcard"
-
-- audio-routing:
- Usage: Optional
- Value type: <stringlist>
- Definition: A list of the connections between audio components.
- Each entry is a pair of strings, the first being the
- connection's sink, the second being the connection's
- source. Valid names could be power supplies, MicBias
- of codec and the jacks on the board:
- Valid names include:
-
- Board Connectors:
- "Headphone Left"
- "Headphone Right"
- "Earphone"
- "Line Out1"
- "Line Out2"
- "Line Out3"
- "Line Out4"
- "Analog Mic1"
- "Analog Mic2"
- "Analog Mic3"
- "Analog Mic4"
- "Analog Mic5"
- "Analog Mic6"
- "Digital Mic2"
- "Digital Mic3"
-
- Audio pins and MicBias on WCD9335 Codec:
- "MIC_BIAS1"
- "MIC_BIAS2"
- "MIC_BIAS3"
- "MIC_BIAS4"
- "AMIC1"
- "AMIC2"
- "AMIC3"
- "AMIC4"
- "AMIC5"
- "AMIC6"
- "AMIC6"
- "DMIC1"
- "DMIC2"
- "DMIC3"
-
-- model:
- Usage: required
- Value type: <stringlist>
- Definition: The user-visible name of this sound card.
-
-- aux-devs
- Usage: optional
- Value type: <array of phandles>
- Definition: A list of phandles for auxiliary devices (e.g. analog
- amplifiers) that do not appear directly within the DAI
- links. Should be connected to another audio component
- using "audio-routing".
-
-= dailinks
-Each subnode of sndcard represents either a dailink, and subnodes of each
-dailinks would be cpu/codec/platform dais.
-
-- link-name:
- Usage: required
- Value type: <string>
- Definition: User friendly name for dai link
-
-= CPU, PLATFORM, CODEC dais subnodes
-- cpu:
- Usage: required
- Value type: <subnode>
- Definition: cpu dai sub-node
-
-- codec:
- Usage: Optional
- Value type: <subnode>
- Definition: codec dai sub-node
-
-- platform:
- Usage: Optional
- Value type: <subnode>
- Definition: platform dai sub-node
-
-- sound-dai:
- Usage: required
- Value type: <phandle with arguments>
- Definition: dai phandle/s and port of CPU/CODEC/PLATFORM node.
-
-Obsolete:
- qcom,model: String for soundcard name (Use model instead)
- qcom,audio-routing: A list of the connections between audio components.
- (Use audio-routing instead)
-
-Example:
-
-audio {
- compatible = "qcom,apq8096-sndcard";
- model = "DB820c";
-
- mm1-dai-link {
- link-name = "MultiMedia1";
- cpu {
- sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
- };
- };
-
- hdmi-dai-link {
- link-name = "HDMI Playback";
- cpu {
- sound-dai = <&q6afe HDMI_RX>;
- };
-
- platform {
- sound-dai = <&q6adm>;
- };
-
- codec {
- sound-dai = <&hdmi 0>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index ef18a572a1ff..3a559bd07a79 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/sound/qcom,lpass-cpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Technologies Inc. LPASS CPU dai driver bindings
+title: Qualcomm Technologies Inc. LPASS CPU dai driver
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
- - Rohit kumar <rohitkr@codeaurora.org>
+ - Rohit kumar <quic_rohkumar@quicinc.com>
description: |
Qualcomm Technologies Inc. SOC Low-Power Audio SubSystem (LPASS) that consist
@@ -35,7 +35,7 @@ properties:
clocks:
minItems: 3
- maxItems: 7
+ maxItems: 10
clock-names:
minItems: 1
@@ -65,6 +65,9 @@ properties:
power-domain-names:
maxItems: 1
+ required-opps:
+ maxItems: 1
+
'#sound-dai-cells':
const: 1
@@ -75,7 +78,7 @@ properties:
const: 0
patternProperties:
- "^dai-link@[0-9a-f]$":
+ "^dai-link@[0-9a-f]+$":
type: object
description: |
LPASS CPU dai node for each I2S device or Soundwire device. Bindings of each node
@@ -109,9 +112,10 @@ required:
- interrupt-names
- '#sound-dai-cells'
-additionalProperties: false
+unevaluatedProperties: false
allOf:
+ - $ref: dai-common.yaml#
- if:
properties:
compatible:
@@ -120,6 +124,8 @@ allOf:
then:
properties:
+ clocks:
+ maxItems: 3
clock-names:
items:
- const: ahbix-clk
@@ -134,6 +140,9 @@ allOf:
then:
properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
clock-names:
items:
- const: ahbix-clk
@@ -152,33 +161,31 @@ allOf:
then:
properties:
+ clocks:
+ minItems: 6
+ maxItems: 6
clock-names:
- oneOf:
- - items: #for I2S
- - const: pcnoc-sway-clk
- - const: audio-core
- - const: mclk0
- - const: pcnoc-mport-clk
- - const: mi2s-bit-clk0
- - const: mi2s-bit-clk1
- - items: #for HDMI
- - const: pcnoc-sway-clk
- - const: audio-core
- - const: pcnoc-mport-clk
+ items:
+ - const: pcnoc-sway-clk
+ - const: audio-core
+ - const: mclk0
+ - const: pcnoc-mport-clk
+ - const: mi2s-bit-clk0
+ - const: mi2s-bit-clk1
+ reg:
+ minItems: 2
+ maxItems: 2
reg-names:
- anyOf:
- - items: #for I2S
- - const: lpass-lpaif
- - items: #for I2S and HDMI
- - const: lpass-hdmiif
- - const: lpass-lpaif
+ items:
+ - const: lpass-hdmiif
+ - const: lpass-lpaif
+ interrupts:
+ minItems: 2
+ maxItems: 2
interrupt-names:
- anyOf:
- - items: #for I2S
- - const: lpass-irq-lpaif
- - items: #for I2S and HDMI
- - const: lpass-irq-lpaif
- - const: lpass-irq-hdmi
+ items:
+ - const: lpass-irq-lpaif
+ - const: lpass-irq-hdmi
required:
- iommus
- power-domains
@@ -191,54 +198,44 @@ allOf:
then:
properties:
+ clocks:
+ minItems: 10
+ maxItems: 10
clock-names:
- oneOf:
- - items: #for I2S
- - const: aon_cc_audio_hm_h
- - const: audio_cc_ext_mclk0
- - const: core_cc_sysnoc_mport_core
- - const: core_cc_ext_if0_ibit
- - const: core_cc_ext_if1_ibit
- - items: #for Soundwire
- - const: aon_cc_audio_hm_h
- - const: audio_cc_codec_mem
- - const: audio_cc_codec_mem0
- - const: audio_cc_codec_mem1
- - const: audio_cc_codec_mem2
- - const: aon_cc_va_mem0
- - items: #for HDMI
- - const: core_cc_sysnoc_mport_core
-
+ items:
+ - const: aon_cc_audio_hm_h
+ - const: audio_cc_ext_mclk0
+ - const: core_cc_sysnoc_mport_core
+ - const: core_cc_ext_if0_ibit
+ - const: core_cc_ext_if1_ibit
+ - const: audio_cc_codec_mem
+ - const: audio_cc_codec_mem0
+ - const: audio_cc_codec_mem1
+ - const: audio_cc_codec_mem2
+ - const: aon_cc_va_mem0
+ reg:
+ minItems: 6
+ maxItems: 6
reg-names:
- anyOf:
- - items: #for I2S
- - const: lpass-lpaif
- - items: #for I2S and HDMI
- - const: lpass-hdmiif
- - const: lpass-lpaif
- - items: #for I2S, soundwire and HDMI
- - const: lpass-hdmiif
- - const: lpass-lpaif
- - const: lpass-rxtx-cdc-dma-lpm
- - const: lpass-rxtx-lpaif
- - const: lpass-va-lpaif
- - const: lpass-va-cdc-dma-lpm
+ items:
+ - const: lpass-hdmiif
+ - const: lpass-lpaif
+ - const: lpass-rxtx-cdc-dma-lpm
+ - const: lpass-rxtx-lpaif
+ - const: lpass-va-lpaif
+ - const: lpass-va-cdc-dma-lpm
+ interrupts:
+ minItems: 4
+ maxItems: 4
interrupt-names:
- anyOf:
- - items: #for I2S
- - const: lpass-irq-lpaif
- - items: #for I2S and HDMI
- - const: lpass-irq-lpaif
- - const: lpass-irq-hdmi
- - items: #for I2S, soundwire and HDMI
- - const: lpass-irq-lpaif
- - const: lpass-irq-hdmi
- - const: lpass-irq-vaif
- - const: lpass-irq-rxtxif
+ items:
+ - const: lpass-irq-lpaif
+ - const: lpass-irq-hdmi
+ - const: lpass-irq-vaif
+ - const: lpass-irq-rxtxif
power-domain-names:
- allOf:
- - items:
- - const: lcx
+ items:
+ - const: lcx
required:
- iommus
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml
index 1de11e7f33bb..2eed2277511f 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml
@@ -4,18 +4,28 @@
$id: http://devicetree.org/schemas/sound/qcom,lpass-rx-macro.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LPASS(Low Power Audio Subsystem) RX Macro audio codec DT bindings
+title: LPASS(Low Power Audio Subsystem) RX Macro audio codec
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
properties:
compatible:
- enum:
- - qcom,sc7280-lpass-rx-macro
- - qcom,sm8250-lpass-rx-macro
- - qcom,sm8450-lpass-rx-macro
- - qcom,sc8280xp-lpass-rx-macro
+ oneOf:
+ - enum:
+ - qcom,sc7280-lpass-rx-macro
+ - qcom,sm6115-lpass-rx-macro
+ - qcom,sm8250-lpass-rx-macro
+ - qcom,sm8450-lpass-rx-macro
+ - qcom,sm8550-lpass-rx-macro
+ - qcom,sc8280xp-lpass-rx-macro
+ - items:
+ - enum:
+ - qcom,kaanapali-lpass-rx-macro
+ - qcom,sm8650-lpass-rx-macro
+ - qcom,sm8750-lpass-rx-macro
+ - qcom,x1e80100-lpass-rx-macro
+ - const: qcom,sm8550-lpass-rx-macro
reg:
maxItems: 1
@@ -27,24 +37,15 @@ properties:
const: 0
clocks:
+ minItems: 3
maxItems: 5
clock-names:
- oneOf:
- - items: #for ADSP based platforms
- - const: mclk
- - const: npl
- - const: macro
- - const: dcodec
- - const: fsgen
- - items: #for ADSP bypass based platforms
- - const: mclk
- - const: npl
- - const: fsgen
+ minItems: 3
+ maxItems: 5
clock-output-names:
- items:
- - const: mclk
+ maxItems: 1
power-domains:
maxItems: 2
@@ -59,7 +60,84 @@ required:
- reg
- "#sound-dai-cells"
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-lpass-rx-macro
+ then:
+ properties:
+ clock-names:
+ oneOf:
+ - items: # for ADSP based platforms
+ - const: mclk
+ - const: npl
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+ - items: # for ADSP bypass based platforms
+ - const: mclk
+ - const: npl
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-lpass-rx-macro
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: mclk
+ - const: npl
+ - const: dcodec
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-lpass-rx-macro
+ - qcom,sm8250-lpass-rx-macro
+ - qcom,sm8450-lpass-rx-macro
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ items:
+ - const: mclk
+ - const: npl
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-lpass-rx-macro
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml
index de8297b358e8..e5e65e226a02 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml
@@ -4,18 +4,28 @@
$id: http://devicetree.org/schemas/sound/qcom,lpass-tx-macro.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LPASS(Low Power Audio Subsystem) TX Macro audio codec DT bindings
+title: LPASS(Low Power Audio Subsystem) TX Macro audio codec
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
properties:
compatible:
- enum:
- - qcom,sc7280-lpass-tx-macro
- - qcom,sm8250-lpass-tx-macro
- - qcom,sm8450-lpass-tx-macro
- - qcom,sc8280xp-lpass-tx-macro
+ oneOf:
+ - enum:
+ - qcom,sc7280-lpass-tx-macro
+ - qcom,sm6115-lpass-tx-macro
+ - qcom,sm8250-lpass-tx-macro
+ - qcom,sm8450-lpass-tx-macro
+ - qcom,sm8550-lpass-tx-macro
+ - qcom,sc8280xp-lpass-tx-macro
+ - items:
+ - enum:
+ - qcom,kaanapali-lpass-tx-macro
+ - qcom,sm8650-lpass-tx-macro
+ - qcom,sm8750-lpass-tx-macro
+ - qcom,x1e80100-lpass-tx-macro
+ - const: qcom,sm8550-lpass-tx-macro
reg:
maxItems: 1
@@ -27,24 +37,15 @@ properties:
const: 0
clocks:
+ minItems: 3
maxItems: 5
clock-names:
- oneOf:
- - items: #for ADSP based platforms
- - const: mclk
- - const: npl
- - const: macro
- - const: dcodec
- - const: fsgen
- - items: #for ADSP bypass based platforms
- - const: mclk
- - const: npl
- - const: fsgen
+ minItems: 3
+ maxItems: 5
clock-output-names:
- items:
- - const: mclk
+ maxItems: 1
power-domains:
maxItems: 2
@@ -63,7 +64,84 @@ required:
- reg
- "#sound-dai-cells"
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-lpass-tx-macro
+ then:
+ properties:
+ clock-names:
+ oneOf:
+ - items: # for ADSP based platforms
+ - const: mclk
+ - const: npl
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+ - items: # for ADSP bypass based platforms
+ - const: mclk
+ - const: npl
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc8280xp-lpass-tx-macro
+ - qcom,sm8250-lpass-tx-macro
+ - qcom,sm8450-lpass-tx-macro
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ items:
+ - const: mclk
+ - const: npl
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sm6115-lpass-tx-macro
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: mclk
+ - const: npl
+ - const: dcodec
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-lpass-tx-macro
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
index 9f473c08cb2e..5c42b2b323ee 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
@@ -4,18 +4,29 @@
$id: http://devicetree.org/schemas/sound/qcom,lpass-va-macro.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LPASS(Low Power Audio Subsystem) VA Macro audio codec DT bindings
+title: LPASS(Low Power Audio Subsystem) VA Macro audio codec
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
properties:
compatible:
- enum:
- - qcom,sc7280-lpass-va-macro
- - qcom,sm8250-lpass-va-macro
- - qcom,sm8450-lpass-va-macro
- - qcom,sc8280xp-lpass-va-macro
+ oneOf:
+ - enum:
+ - qcom,sc7280-lpass-va-macro
+ - qcom,sm6115-lpass-va-macro
+ - qcom,sm8250-lpass-va-macro
+ - qcom,sm8450-lpass-va-macro
+ - qcom,sm8550-lpass-va-macro
+ - qcom,sc8280xp-lpass-va-macro
+ - items:
+ - enum:
+ - qcom,glymur-lpass-va-macro
+ - qcom,kaanapali-lpass-va-macro
+ - qcom,sm8650-lpass-va-macro
+ - qcom,sm8750-lpass-va-macro
+ - qcom,x1e80100-lpass-va-macro
+ - const: qcom,sm8550-lpass-va-macro
reg:
maxItems: 1
@@ -27,20 +38,15 @@ properties:
const: 0
clocks:
- maxItems: 3
+ minItems: 1
+ maxItems: 4
clock-names:
- oneOf:
- - items: #for ADSP based platforms
- - const: mclk
- - const: core
- - const: dcodec
- - items: #for ADSP bypass based platforms
- - const: mclk
+ minItems: 1
+ maxItems: 4
clock-output-names:
- items:
- - const: fsgen
+ maxItems: 1
power-domains:
maxItems: 2
@@ -61,8 +67,107 @@ required:
- compatible
- reg
- "#sound-dai-cells"
-
-additionalProperties: false
+ - clock-names
+ - clocks
+
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sc7280-lpass-va-macro
+
+ then:
+ if:
+ required:
+ - power-domains
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: mclk
+ else:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm6115-lpass-va-macro
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: mclk
+ - const: dcodec
+ - const: npl
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sm8250-lpass-va-macro
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-lpass-va-macro
+ - qcom,sm8450-lpass-va-macro
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+ - const: npl
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-lpass-va-macro
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+
+unevaluatedProperties: false
examples:
- |
@@ -75,7 +180,7 @@ examples:
clocks = <&aoncc 0>,
<&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
<&q6afecc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
- clock-names = "mclk", "core", "dcodec";
+ clock-names = "mclk", "macro", "dcodec";
clock-output-names = "fsgen";
qcom,dmic-sample-rate = <600000>;
vdd-micb-supply = <&vreg_s4a_1p8>;
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml
index 4959ad658eac..d5f22b5cf021 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml
@@ -4,18 +4,28 @@
$id: http://devicetree.org/schemas/sound/qcom,lpass-wsa-macro.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: LPASS(Low Power Audio Subsystem) VA Macro audio codec DT bindings
+title: LPASS(Low Power Audio Subsystem) VA Macro audio codec
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
properties:
compatible:
- enum:
- - qcom,sc7280-lpass-wsa-macro
- - qcom,sm8250-lpass-wsa-macro
- - qcom,sm8450-lpass-wsa-macro
- - qcom,sc8280xp-lpass-wsa-macro
+ oneOf:
+ - enum:
+ - qcom,sc7280-lpass-wsa-macro
+ - qcom,sm8250-lpass-wsa-macro
+ - qcom,sm8450-lpass-wsa-macro
+ - qcom,sm8550-lpass-wsa-macro
+ - qcom,sc8280xp-lpass-wsa-macro
+ - items:
+ - enum:
+ - qcom,glymur-lpass-wsa-macro
+ - qcom,kaanapali-lpass-wsa-macro
+ - qcom,sm8650-lpass-wsa-macro
+ - qcom,sm8750-lpass-wsa-macro
+ - qcom,x1e80100-lpass-wsa-macro
+ - const: qcom,sm8550-lpass-wsa-macro
reg:
maxItems: 1
@@ -27,19 +37,15 @@ properties:
const: 0
clocks:
- maxItems: 5
+ minItems: 4
+ maxItems: 6
clock-names:
- items:
- - const: mclk
- - const: npl
- - const: macro
- - const: dcodec
- - const: fsgen
+ minItems: 4
+ maxItems: 6
clock-output-names:
- items:
- - const: mclk
+ maxItems: 1
qcom,dmic-sample-rate:
description: dmic sample rate
@@ -53,10 +59,53 @@ required:
- reg
- "#sound-dai-cells"
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - qcom,sc7280-lpass-wsa-macro
+ - qcom,sm8250-lpass-wsa-macro
+ - qcom,sm8450-lpass-wsa-macro
+ - qcom,sc8280xp-lpass-wsa-macro
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ items:
+ - const: mclk
+ - const: npl
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8550-lpass-wsa-macro
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: mclk
+ - const: macro
+ - const: dcodec
+ - const: fsgen
+
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/qcom,sm8250-lpass-aoncc.h>
#include <dt-bindings/sound/qcom,q6afe.h>
codec@3240000 {
compatible = "qcom,sm8250-lpass-wsa-macro";
diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt
deleted file mode 100644
index e7d17dda55db..000000000000
--- a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-msm8916 analog audio CODEC
-
-Bindings for codec Analog IP which is integrated in pmic pm8916,
-
-## Bindings for codec core on pmic:
-
-Required properties
- - compatible = "qcom,pm8916-wcd-analog-codec";
- - reg: represents the slave base address provided to the peripheral.
- - interrupts: List of interrupts in given SPMI peripheral.
- - interrupt-names: Names specified to above list of interrupts in same
- order. List of supported interrupt names are:
- "cdc_spk_cnp_int" - Speaker click and pop interrupt.
- "cdc_spk_clip_int" - Speaker clip interrupt.
- "cdc_spk_ocp_int" - Speaker over current protect interrupt.
- "mbhc_ins_rem_det1" - jack insert removal detect interrupt 1.
- "mbhc_but_rel_det" - button release interrupt.
- "mbhc_but_press_det" - button press event
- "mbhc_ins_rem_det" - jack insert removal detect interrupt.
- "mbhc_switch_int" - multi button headset interrupt.
- "cdc_ear_ocp_int" - Earphone over current protect interrupt.
- "cdc_hphr_ocp_int" - Headphone R over current protect interrupt.
- "cdc_hphl_ocp_det" - Headphone L over current protect interrupt.
- "cdc_ear_cnp_int" - earphone cnp interrupt.
- "cdc_hphr_cnp_int" - hphr click and pop interrupt.
- "cdc_hphl_cnp_int" - hphl click and pop interrupt.
-
- - clocks: Handle to mclk.
- - clock-names: should be "mclk"
- - vdd-cdc-io-supply: phandle to VDD_CDC_IO regulator DT node.
- - vdd-cdc-tx-rx-cx-supply: phandle to VDD_CDC_TX/RX/CX regulator DT node.
- - vdd-micbias-supply: phandle of VDD_MICBIAS supply's regulator DT node.
-
-Optional Properties:
- - qcom,mbhc-vthreshold-low: Array of 5 threshold voltages in mV for 5 buttons
- detection on headset when the mbhc is powered up
- by internal current source, this is a low power.
- - qcom,mbhc-vthreshold-high: Array of 5 thresold voltages in mV for 5 buttons
- detection on headset when mbhc is powered up
- from micbias.
-- qcom,micbias-lvl: Voltage (mV) for Mic Bias
-- qcom,hphl-jack-type-normally-open: boolean, present if hphl pin on jack is a
- NO (Normally Open). If not specified, then
- its assumed that hphl pin on jack is NC
- (Normally Closed).
-- qcom,gnd-jack-type-normally-open: boolean, present if gnd pin on jack is
- NO (Normally Open). If not specified, then
- its assumed that gnd pin on jack is NC
- (Normally Closed).
-- qcom,micbias1-ext-cap: boolean, present if micbias1 has external capacitor
- connected.
-- qcom,micbias2-ext-cap: boolean, present if micbias2 has external capacitor
- connected.
-
-Example:
-
-spmi_bus {
- ...
- audio-codec@f000{
- compatible = "qcom,pm8916-wcd-analog-codec";
- reg = <0xf000 0x200>;
- reg-names = "pmic-codec-core";
- clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
- clock-names = "mclk";
- qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
- qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
- interrupt-parent = <&spmi_bus>;
- interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
- <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
- <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
- interrupt-names = "cdc_spk_cnp_int",
- "cdc_spk_clip_int",
- "cdc_spk_ocp_int",
- "mbhc_ins_rem_det1",
- "mbhc_but_rel_det",
- "mbhc_but_press_det",
- "mbhc_ins_rem_det",
- "mbhc_switch_int",
- "cdc_ear_ocp_int",
- "cdc_hphr_ocp_int",
- "cdc_hphl_ocp_det",
- "cdc_ear_cnp_int",
- "cdc_hphr_cnp_int",
- "cdc_hphl_cnp_int";
- vdd-cdc-io-supply = <&pm8916_l5>;
- vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
- vdd-micbias-supply = <&pm8916_l13>;
- #sound-dai-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital-codec.yaml b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital-codec.yaml
new file mode 100644
index 000000000000..a899c4e7c1c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital-codec.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,msm8916-wcd-digital-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8916 WCD Digital Audio Codec
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ The digital WCD audio codec found on Qualcomm MSM8916 LPASS.
+
+properties:
+ compatible:
+ const: qcom,msm8916-wcd-digital-codec
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ahbix-clk
+ - const: mclk
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#sound-dai-cells'
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8916.h>
+ audio-codec@771c000 {
+ compatible = "qcom,msm8916-wcd-digital-codec";
+ reg = <0x0771c000 0x400>;
+ clocks = <&gcc GCC_ULTAUDIO_AHBFABRIC_IXFABRIC_CLK>,
+ <&gcc GCC_CODEC_DIGCODEC_CLK>;
+ clock-names = "ahbix-clk", "mclk";
+ #sound-dai-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt b/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt
deleted file mode 100644
index 1c8e4cb25176..000000000000
--- a/Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-digital.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-msm8916 digital audio CODEC
-
-## Bindings for codec core in lpass:
-
-Required properties
- - compatible = "qcom,msm8916-wcd-digital-codec";
- - reg: address space for lpass codec.
- - clocks: Handle to mclk and ahbclk
- - clock-names: should be "mclk", "ahbix-clk".
-
-Example:
-
-audio-codec@771c000{
- compatible = "qcom,msm8916-wcd-digital-codec";
- reg = <0x0771c000 0x400>;
- clocks = <&gcc GCC_ULTAUDIO_AHBFABRIC_IXFABRIC_CLK>,
- <&gcc GCC_CODEC_DIGCODEC_CLK>;
- clock-names = "ahbix-clk", "mclk";
- #sound-dai-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/sound/qcom,pm4125-codec.yaml b/Documentation/devicetree/bindings/sound/qcom,pm4125-codec.yaml
new file mode 100644
index 000000000000..6e2f103be1d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,pm4125-codec.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,pm4125-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM4125 Audio Codec
+
+maintainers:
+ - Alexey Klimov <alexey.klimov@linaro.org>
+
+description:
+ The audio codec IC found on Qualcomm PM4125/PM2250 PMIC.
+ It has RX and TX Soundwire slave devices.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: qcom,pm4125-codec
+
+ reg:
+ description:
+ Specifies the SPMI base address for the audio codec peripherals. The
+ address space contains reset register needed to power-on the codec.
+ maxItems: 1
+
+ reg-names:
+ maxItems: 1
+
+ vdd-io-supply:
+ description: A reference to the 1.8V I/O supply
+
+ vdd-cp-supply:
+ description: A reference to the charge pump I/O supply
+
+ vdd-mic-bias-supply:
+ description: A reference to the 3.3V mic bias supply
+
+ vdd-pa-vpos-supply:
+ description: A reference to the PA VPOS supply
+
+ qcom,tx-device:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A reference to Soundwire tx device phandle
+
+ qcom,rx-device:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A reference to Soundwire rx device phandle
+
+ qcom,micbias1-microvolt:
+ description: micbias1 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,micbias2-microvolt:
+ description: micbias2 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,micbias3-microvolt:
+ description: micbias3 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,mbhc-buttons-vthreshold-microvolt:
+ description:
+ Array of 8 Voltage threshold values corresponding to headset
+ button0 - button7
+ minItems: 8
+ maxItems: 8
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - vdd-io-supply
+ - vdd-cp-supply
+ - vdd-mic-bias-supply
+ - vdd-pa-vpos-supply
+ - qcom,tx-device
+ - qcom,rx-device
+ - qcom,micbias1-microvolt
+ - qcom,micbias2-microvolt
+ - qcom,micbias3-microvolt
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@f000 {
+ compatible = "qcom,pm4125-codec";
+ reg = <0xf000>;
+ vdd-io-supply = <&pm4125_l15>;
+ vdd-cp-supply = <&pm4125_s4>;
+ vdd-pa-vpos-supply = <&pm4125_s4>;
+ vdd-mic-bias-supply = <&pm4125_l22>;
+ qcom,micbias1-microvolt = <1800000>;
+ qcom,micbias2-microvolt = <1800000>;
+ qcom,micbias3-microvolt = <1800000>;
+ qcom,rx-device = <&pm4125_rx>;
+ qcom,tx-device = <&pm4125_tx>;
+ #sound-dai-cells = <1>;
+ };
+ };
+ };
+
+ /* ... */
+
+ soundwire@a610000 {
+ reg = <0x0a610000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ pm4125_rx: audio-codec@0,4 {
+ compatible = "sdw20217010c00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,pm4125-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,pm4125-sdw.yaml
new file mode 100644
index 000000000000..769e4cb5b99b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,pm4125-sdw.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,pm4125-sdw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoundWire Slave devices on PM4125/PM2250 PMIC audio codec.
+
+maintainers:
+ - Alexey Klimov <alexey.klimov@linaro.org>
+
+description:
+ The audio codec IC found on Qualcomm PM4125/PM2250 PMICs.
+ It has RX and TX Soundwire slave devices.
+
+properties:
+ compatible:
+ const: sdw20217010c00
+
+ reg:
+ maxItems: 1
+
+ qcom,tx-port-mapping:
+ description: |
+ Specifies static port mapping between device and host tx ports.
+ In the order of the device port index which are adc1_port, adc23_port,
+ dmic03_mbhc_port, dmic46_port.
+ Supports maximum 2 tx soundwire ports.
+
+ PM4125 TX Port 1 (ADC1,2 & DMIC0 & MBHC) <=> SWR0 Port 1
+ PM4125 TX Port 2 (ADC1 & DMIC0,1,2 & MBHC) <=> SWR0 Port 2
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 4
+ items:
+ enum: [1, 2, 3, 4]
+
+ qcom,rx-port-mapping:
+ description: |
+ Specifies static port mapping between device and host rx ports.
+ In the order of device port index which are hph_port, clsh_port,
+ comp_port, lo_port, dsd port.
+ Supports maximum 2 rx soundwire ports.
+
+ PM4125 RX Port 1 (HPH_L/R) <==> SWR1 Port 1 (HPH_L/R)
+ PM4125 RX Port 2 (COMP_L/R) <==> SWR1 Port 3 (COMP_L/R)
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 5
+ items:
+ enum: [1, 2, 3, 4, 5]
+
+required:
+ - compatible
+ - reg
+
+oneOf:
+ - required:
+ - qcom,tx-port-mapping
+ - required:
+ - qcom,rx-port-mapping
+
+additionalProperties: false
+
+examples:
+ - |
+ soundwire@a610000 {
+ reg = <0x0a610000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ pm4125_rx: codec@0,1 {
+ compatible = "sdw20217010c00";
+ reg = <0 1>;
+ qcom,rx-port-mapping = <1 3>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml b/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml
new file mode 100644
index 000000000000..94e7a1860977
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,pm8916-wcd-analog-codec.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,pm8916-wcd-analog-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8916 WCD Analog Audio Codec
+
+maintainers:
+ - Konrad Dybcio <konradybcio@kernel.org>
+
+description:
+ The analog WCD audio codec found on Qualcomm PM8916 PMIC.
+
+properties:
+ compatible:
+ const: qcom,pm8916-wcd-analog-codec
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 14
+
+ interrupt-names:
+ items:
+ - const: cdc_spk_cnp_int
+ - const: cdc_spk_clip_int
+ - const: cdc_spk_ocp_int
+ - const: mbhc_ins_rem_det1
+ - const: mbhc_but_rel_det
+ - const: mbhc_but_press_det
+ - const: mbhc_ins_rem_det
+ - const: mbhc_switch_int
+ - const: cdc_ear_ocp_int
+ - const: cdc_hphr_ocp_int
+ - const: cdc_hphl_ocp_det
+ - const: cdc_ear_cnp_int
+ - const: cdc_hphr_cnp_int
+ - const: cdc_hphl_cnp_int
+
+ vdd-cdc-io-supply:
+ description: 1.8V buck supply
+
+ vdd-cdc-tx-rx-cx-supply:
+ description: 1.8V SIDO buck supply
+
+ vdd-micbias-supply:
+ description: micbias supply
+
+ qcom,mbhc-vthreshold-low:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Array of 5 threshold voltages in mV for 5-button detection on
+ headset when MBHC is powered by an internal current source.
+ minItems: 5
+ maxItems: 5
+
+ qcom,mbhc-vthreshold-high:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Array of 5 threshold voltages in mV for 5-button detection on
+ headset when MBHC is powered from micbias.
+ minItems: 5
+ maxItems: 5
+
+ qcom,micbias-lvl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Voltage (mV) for Mic Bias
+
+ qcom,hphl-jack-type-normally-open:
+ type: boolean
+ description:
+ True if the HPHL pin on the jack is NO (Normally Open), false if it's
+ NC (Normally Closed).
+
+ qcom,gnd-jack-type-normally-open:
+ type: boolean
+ description:
+ True if the GND pin on the jack is NO (Normally Open), false if it's
+ NC (Normally Closed).
+
+ qcom,micbias1-ext-cap:
+ type: boolean
+ description:
+ True if micbias1 has an external capacitor.
+
+ qcom,micbias2-ext-cap:
+ type: boolean
+ description:
+ True if micbias2 has an external capacitor.
+
+ "#sound-dai-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/spmi/spmi.h>
+
+ pmic@1 {
+ compatible = "qcom,pm8916", "qcom,spmi-pmic";
+ reg = <0x1 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@f000 {
+ compatible = "qcom,pm8916-wcd-analog-codec";
+ reg = <0xf000>;
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ interrupt-parent = <&spmi_bus>;
+ interrupts = <0x1 0xf0 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x5 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x6 IRQ_TYPE_NONE>,
+ <0x1 0xf0 0x7 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x0 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x1 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x2 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x3 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x4 IRQ_TYPE_NONE>,
+ <0x1 0xf1 0x5 IRQ_TYPE_NONE>;
+ interrupt-names = "cdc_spk_cnp_int",
+ "cdc_spk_clip_int",
+ "cdc_spk_ocp_int",
+ "mbhc_ins_rem_det1",
+ "mbhc_but_rel_det",
+ "mbhc_but_press_det",
+ "mbhc_ins_rem_det",
+ "mbhc_switch_int",
+ "cdc_ear_ocp_int",
+ "cdc_hphr_ocp_int",
+ "cdc_hphl_ocp_det",
+ "cdc_ear_cnp_int",
+ "cdc_hphr_cnp_int",
+ "cdc_hphl_cnp_int";
+ vdd-cdc-io-supply = <&pm8916_l5>;
+ vdd-cdc-tx-rx-cx-supply = <&pm8916_l5>;
+ vdd-micbias-supply = <&pm8916_l13>;
+ #sound-dai-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6adm-routing.yaml b/Documentation/devicetree/bindings/sound/qcom,q6adm-routing.yaml
index d0f7a79e240a..26fe8cc66b3c 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6adm-routing.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6adm-routing.yaml
@@ -7,13 +7,16 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Audio Device Manager (Q6ADM) routing
maintainers:
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
description:
Qualcomm Audio Device Manager (Q6ADM) routing node represents routing
specific configuration.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -26,27 +29,11 @@ required:
- compatible
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/soc/qcom,apr.h>
- #include <dt-bindings/sound/qcom,q6asm.h>
-
- apr {
- compatible = "qcom,apr-v2";
- qcom,domain = <APR_DOMAIN_ADSP>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- service@8 {
- compatible = "qcom,q6adm";
- reg = <APR_SVC_ADM>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
-
- routing {
- compatible = "qcom,q6adm-routing";
- #sound-dai-cells = <0>;
- };
- };
+ routing {
+ compatible = "qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6adm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6adm.yaml
new file mode 100644
index 000000000000..3c32c5b0fad8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6adm.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6adm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Audio Device Manager (Q6ADM)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: /schemas/soc/qcom/qcom,apr-services.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6adm
+
+ routing:
+ type: object
+ $ref: /schemas/sound/qcom,q6adm-routing.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP LPASS audio routing
+
+required:
+ - compatible
+ - routing
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,apr.h>
+
+ apr {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ service@8 {
+ compatible = "qcom,q6adm";
+ reg = <APR_SVC_ADM>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ routing {
+ compatible = "qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6afe.yaml b/Documentation/devicetree/bindings/sound/qcom,q6afe.yaml
new file mode 100644
index 000000000000..4624b3d461d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6afe.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6afe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Audio FrontEnd (Q6AFE)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: /schemas/soc/qcom/qcom,apr-services.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6afe
+
+ clock-controller:
+ $ref: /schemas/sound/qcom,q6dsp-lpass-clocks.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP LPASS clock controller
+
+ dais:
+ type: object
+ $ref: /schemas/sound/qcom,q6dsp-lpass-ports.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP audio ports
+
+ usbd:
+ type: object
+ $ref: /schemas/sound/qcom,q6usb.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP USB audio ports
+
+required:
+ - compatible
+ - dais
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,apr.h>
+ #include <dt-bindings/sound/qcom,q6afe.h>
+ apr {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ service@4 {
+ compatible = "qcom,q6afe";
+ reg = <APR_SVC_AFE>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ clock-controller {
+ compatible = "qcom,q6afe-clocks";
+ #clock-cells = <2>;
+ };
+
+ dais {
+ compatible = "qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ dai@22 {
+ reg = <QUATERNARY_MI2S_RX>;
+ qcom,sd-lines = <0 1 2 3>;
+ };
+ };
+
+ usbd {
+ compatible = "qcom,q6usb";
+ #sound-dai-cells = <1>;
+ iommus = <&apps_smmu 0x180f 0x0>;
+ qcom,usb-audio-intr-idx = /bits/ 16 <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
index 24f7bf2bfd95..9e5b30d9c6e6 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/qcom,q6apm-dai.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm Audio Process Manager Digital Audio Interfaces binding
+title: Qualcomm Audio Process Manager Digital Audio Interfaces
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -17,7 +17,8 @@ properties:
const: qcom,q6apm-dais
iommus:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
required:
- compatible
@@ -27,20 +28,7 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/soc/qcom,gpr.h>
- gpr {
- compatible = "qcom,gpr";
- #address-cells = <1>;
- #size-cells = <0>;
- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
-
- service@1 {
- compatible = "qcom,q6apm";
- reg = <1>;
-
- dais {
- compatible = "qcom,q6apm-dais";
- iommus = <&apps_smmu 0x1801 0x0>;
- };
- };
+ dais {
+ compatible = "qcom,q6apm-dais";
+ iommus = <&apps_smmu 0x1801 0x0>;
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
new file mode 100644
index 000000000000..2fb95544db8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6apm-lpass-dais.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm DSP LPASS (Low Power Audio SubSystem) Audio Ports
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6apm-lpass-dais
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dais {
+ compatible = "qcom,q6apm-lpass-dais";
+ #sound-dai-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
new file mode 100644
index 000000000000..ec06769a2b63
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6apm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Audio Process Manager (Q6APM)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+ - $ref: /schemas/soc/qcom/qcom,apr-services.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6apm
+
+ bedais:
+ type: object
+ $ref: /schemas/sound/qcom,q6apm-lpass-dais.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP audio ports
+
+ dais:
+ type: object
+ $ref: /schemas/sound/qcom,q6apm-dai.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP audio ports
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - bedais
+ - dais
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,gpr.h>
+
+ gpr {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ service@1 {
+ reg = <GPR_APM_MODULE_IID>;
+ compatible = "qcom,q6apm";
+ #sound-dai-cells = <0>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ dais {
+ compatible = "qcom,q6apm-dais";
+ iommus = <&apps_smmu 0x1801 0x0>;
+ };
+
+ bedais {
+ compatible = "qcom,q6apm-lpass-dais";
+ #sound-dai-cells = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
index 8deb8ffb143b..47a105a97ecf 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Audio Stream Manager (Q6ASM)
maintainers:
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
description:
@@ -56,7 +56,7 @@ patternProperties:
Compress offload dai.
dependencies:
- is-compress-dai: ["direction"]
+ is-compress-dai: [ direction ]
required:
- reg
@@ -73,40 +73,24 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/soc/qcom,apr.h>
- #include <dt-bindings/sound/qcom,q6asm.h>
-
- apr {
- compatible = "qcom,apr-v2";
- qcom,domain = <APR_DOMAIN_ADSP>;
+ dais {
+ compatible = "qcom,q6asm-dais";
+ iommus = <&apps_smmu 0x1821 0x0>;
#address-cells = <1>;
#size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ dai@0 {
+ reg = <0>;
+ };
+
+ dai@1 {
+ reg = <1>;
+ };
- service@7 {
- compatible = "qcom,q6asm";
- reg = <APR_SVC_ASM>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
-
- dais {
- compatible = "qcom,q6asm-dais";
- iommus = <&apps_smmu 0x1821 0x0>;
- #address-cells = <1>;
- #size-cells = <0>;
- #sound-dai-cells = <1>;
-
- dai@0 {
- reg = <0>;
- };
-
- dai@1 {
- reg = <1>;
- };
-
- dai@2 {
- reg = <2>;
- is-compress-dai;
- direction = <1>;
- };
- };
+ dai@2 {
+ reg = <2>;
+ is-compress-dai;
+ direction = <1>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm.yaml
new file mode 100644
index 000000000000..a6f88ce92299
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6asm.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6asm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Audio Stream Manager (Q6ASM)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: /schemas/soc/qcom/qcom,apr-services.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6asm
+
+ dais:
+ type: object
+ $ref: /schemas/sound/qcom,q6asm-dais.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP audio ports
+
+required:
+ - compatible
+ - dais
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,apr.h>
+
+ apr {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ service@7 {
+ compatible = "qcom,q6asm";
+ reg = <APR_SVC_ASM>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ dais {
+ compatible = "qcom,q6asm-dais";
+ iommus = <&apps_smmu 0x1821 0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ dai@0 {
+ reg = <0>;
+ };
+
+ dai@1 {
+ reg = <1>;
+ };
+
+ dai@2 {
+ reg = <2>;
+ is-compress-dai;
+ direction = <1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6core.yaml b/Documentation/devicetree/bindings/sound/qcom,q6core.yaml
new file mode 100644
index 000000000000..8642ef9f9142
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6core.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6core.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Audio Core (Q6Core)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: /schemas/soc/qcom/qcom,apr-services.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6core
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,apr.h>
+
+ apr {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ service@3 {
+ compatible = "qcom,q6core";
+ reg = <APR_SVC_ADSP_CORE>;
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml
index fd567d20417d..3552c44137ed 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-clocks.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-clocks.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm DSP LPASS Clock Controller binding
+title: Qualcomm DSP LPASS Clock Controller
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -35,41 +35,7 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/soc/qcom,apr.h>
- #include <dt-bindings/sound/qcom,q6afe.h>
- apr {
- compatible = "qcom,apr-v2";
- qcom,domain = <APR_DOMAIN_ADSP>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- service@4 {
- compatible = "qcom,q6afe";
- reg = <APR_SVC_AFE>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
-
- clock-controller {
- compatible = "qcom,q6afe-clocks";
- #clock-cells = <2>;
- };
- };
- };
-
- - |
- #include <dt-bindings/soc/qcom,gpr.h>
- gpr {
- compatible = "qcom,gpr";
- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- service@2 {
- reg = <GPR_PRM_MODULE_IID>;
- compatible = "qcom,q6prm";
-
- clock-controller {
- compatible = "qcom,q6prm-lpass-clocks";
- #clock-cells = <2>;
- };
- };
+ clock-controller {
+ compatible = "qcom,q6afe-clocks";
+ #clock-cells = <2>;
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml
index e53fc0960a14..08c618e7e428 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/qcom,q6dsp-lpass-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm DSP LPASS(Low Power Audio SubSystem) Audio Ports binding
+title: Qualcomm DSP LPASS(Low Power Audio SubSystem) Audio Ports
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -16,7 +16,6 @@ properties:
compatible:
enum:
- qcom,q6afe-dais
- - qcom,q6apm-lpass-dais
'#sound-dai-cells':
const: 1
@@ -27,7 +26,7 @@ properties:
'#size-cells':
const: 0
-#Digital Audio Interfaces
+# Digital Audio Interfaces
patternProperties:
'^dai@[0-9]+$':
type: object
@@ -150,54 +149,16 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/soc/qcom,apr.h>
- #include <dt-bindings/sound/qcom,q6afe.h>
- apr {
- compatible = "qcom,apr-v2";
- #address-cells = <1>;
- #size-cells = <0>;
- qcom,domain = <APR_DOMAIN_ADSP>;
-
- service@4 {
- compatible = "qcom,q6afe";
- reg = <APR_SVC_AFE>;
- qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
-
- dais {
- compatible = "qcom,q6afe-dais";
- #address-cells = <1>;
- #size-cells = <0>;
- #sound-dai-cells = <1>;
-
- dai@22 {
- reg = <QUATERNARY_MI2S_RX>;
- qcom,sd-lines = <0 1 2 3>;
- };
- };
- };
- };
- - |
- #include <dt-bindings/soc/qcom,gpr.h>
- gpr {
- compatible = "qcom,gpr";
+ #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
+
+ dais {
+ compatible = "qcom,q6afe-dais";
#address-cells = <1>;
#size-cells = <0>;
- qcom,domain = <GPR_DOMAIN_ID_ADSP>;
-
- service@1 {
- compatible = "qcom,q6apm";
- reg = <GPR_APM_MODULE_IID>;
-
- dais {
- compatible = "qcom,q6apm-lpass-dais";
- #address-cells = <1>;
- #size-cells = <0>;
- #sound-dai-cells = <1>;
-
- dai@22 {
- reg = <QUATERNARY_MI2S_RX>;
- qcom,sd-lines = <0 1 2 3>;
- };
- };
+ #sound-dai-cells = <1>;
+
+ dai@22 {
+ reg = <QUATERNARY_MI2S_RX>;
+ qcom,sd-lines = <0 1 2 3>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6prm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6prm.yaml
new file mode 100644
index 000000000000..3eafe189e699
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6prm.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6prm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Proxy Resource Manager (Q6PRM)
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+allOf:
+ - $ref: /schemas/soc/qcom/qcom,apr-services.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6prm
+
+ clock-controller:
+ $ref: /schemas/sound/qcom,q6dsp-lpass-clocks.yaml#
+ unevaluatedProperties: false
+ description: Qualcomm DSP LPASS clock controller
+
+required:
+ - compatible
+ - clock-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/qcom,gpr.h>
+
+ gpr {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ service@2 {
+ reg = <GPR_PRM_MODULE_IID>;
+ compatible = "qcom,q6prm";
+ qcom,protection-domain = "avs/audio", "msm/adsp/audio_pd";
+
+ clock-controller {
+ compatible = "qcom,q6prm-lpass-clocks";
+ #clock-cells = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6usb.yaml b/Documentation/devicetree/bindings/sound/qcom,q6usb.yaml
new file mode 100644
index 000000000000..37161d2aa96e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6usb.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,q6usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm ASoC DPCM USB backend DAI
+
+maintainers:
+ - Wesley Cheng <quic_wcheng@quicinc.com>
+
+description:
+ The USB port is a supported AFE path on the Q6 DSP. This ASoC DPCM
+ backend DAI will communicate the required settings to initialize the
+ XHCI host controller properly for enabling the offloaded audio stream.
+ Parameters defined under this node will carry settings, which will be
+ passed along during the QMI stream enable request and configuration of
+ the XHCI host controller.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - qcom,q6usb
+
+ iommus:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 1
+
+ qcom,usb-audio-intr-idx:
+ description:
+ Desired XHCI interrupter number to use. Depending on the audio DSP
+ on the platform, it will operate on a specific XHCI interrupter.
+ $ref: /schemas/types.yaml#/definitions/uint16
+ maximum: 8
+
+required:
+ - compatible
+ - "#sound-dai-cells"
+ - qcom,usb-audio-intr-idx
+
+additionalProperties: false
+
+examples:
+ - |
+ dais {
+ compatible = "qcom,q6usb";
+ #sound-dai-cells = <1>;
+ iommus = <&apps_smmu 0x180f 0x0>;
+ qcom,usb-audio-intr-idx = /bits/ 16 <2>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
index 70080d04ddc9..15f38622b98b 100644
--- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -15,16 +15,39 @@ description:
properties:
compatible:
- enum:
- - lenovo,yoga-c630-sndcard
- - qcom,apq8016-sbc-sndcard
- - qcom,db845c-sndcard
- - qcom,msm8916-qdsp6-sndcard
- - qcom,qrb5165-rb5-sndcard
- - qcom,sc8280xp-sndcard
- - qcom,sdm845-sndcard
- - qcom,sm8250-sndcard
- - qcom,sm8450-sndcard
+ oneOf:
+ - items:
+ - enum:
+ - lenovo,yoga-c630-sndcard
+ - qcom,db845c-sndcard
+ - const: qcom,sdm845-sndcard
+ - items:
+ - enum:
+ - qcom,kaanapali-sndcard
+ - qcom,sm8550-sndcard
+ - qcom,sm8650-sndcard
+ - qcom,sm8750-sndcard
+ - const: qcom,sm8450-sndcard
+ - enum:
+ - fairphone,fp4-sndcard
+ - fairphone,fp5-sndcard
+ - qcom,apq8096-sndcard
+ - qcom,glymur-sndcard
+ - qcom,qcm6490-idp-sndcard
+ - qcom,qcs615-sndcard
+ - qcom,qcs6490-rb3gen2-sndcard
+ - qcom,qcs8275-sndcard
+ - qcom,qcs9075-sndcard
+ - qcom,qcs9100-sndcard
+ - qcom,qrb2210-sndcard
+ - qcom,qrb4210-rb2-sndcard
+ - qcom,qrb5165-rb5-sndcard
+ - qcom,sc7180-qdsp6-sndcard
+ - qcom,sc8280xp-sndcard
+ - qcom,sdm845-sndcard
+ - qcom,sm8250-sndcard
+ - qcom,sm8450-sndcard
+ - qcom,x1e80100-sndcard
audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
@@ -44,18 +67,6 @@ properties:
$ref: /schemas/types.yaml#/definitions/string
description: User visible long sound card name
- pin-switches:
- description: List of widget names for which pin switches should be created.
- $ref: /schemas/types.yaml#/definitions/string-array
-
- widgets:
- description: User specified audio sound widgets.
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
-
- # Only valid for some compatibles (see allOf if below)
- reg: true
- reg-names: true
-
patternProperties:
".*-dai-link$":
description:
@@ -96,7 +107,7 @@ patternProperties:
properties:
sound-dai:
minItems: 1
- maxItems: 4
+ maxItems: 8
required:
- link-name
@@ -108,34 +119,6 @@ required:
- compatible
- model
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - qcom,apq8016-sbc-sndcard
- - qcom,msm8916-qdsp6-sndcard
- then:
- properties:
- reg:
- items:
- - description: Microphone I/O mux register address
- - description: Speaker I/O mux register address
- reg-names:
- items:
- - const: mic-iomux
- - const: spkr-iomux
- required:
- - compatible
- - model
- - reg
- - reg-names
- else:
- properties:
- reg: false
- reg-names: false
-
additionalProperties: false
examples:
@@ -216,99 +199,19 @@ examples:
sound-dai = <&vamacro 0>;
};
};
- };
- - |
- #include <dt-bindings/sound/qcom,lpass.h>
- sound@7702000 {
- compatible = "qcom,apq8016-sbc-sndcard";
- reg = <0x07702000 0x4>, <0x07702004 0x4>;
- reg-names = "mic-iomux", "spkr-iomux";
-
- model = "DB410c";
- audio-routing =
- "AMIC2", "MIC BIAS Internal2",
- "AMIC3", "MIC BIAS External1";
-
- pinctrl-0 = <&cdc_pdm_lines_act &ext_sec_tlmm_lines_act &ext_mclk_tlmm_lines_act>;
- pinctrl-1 = <&cdc_pdm_lines_sus &ext_sec_tlmm_lines_sus &ext_mclk_tlmm_lines_sus>;
- pinctrl-names = "default", "sleep";
-
- quaternary-dai-link {
- link-name = "ADV7533";
+ usb-dai-link {
+ link-name = "USB Playback";
cpu {
- sound-dai = <&lpass MI2S_QUATERNARY>;
- };
- codec {
- sound-dai = <&adv_bridge 0>;
+ sound-dai = <&q6afedai USB_RX>;
};
- };
- primary-dai-link {
- link-name = "WCD";
- cpu {
- sound-dai = <&lpass MI2S_PRIMARY>;
- };
codec {
- sound-dai = <&lpass_codec 0>, <&wcd_codec 0>;
+ sound-dai = <&usbdai USB_RX>;
};
- };
- tertiary-dai-link {
- link-name = "WCD-Capture";
- cpu {
- sound-dai = <&lpass MI2S_TERTIARY>;
- };
- codec {
- sound-dai = <&lpass_codec 1>, <&wcd_codec 1>;
- };
- };
- };
-
- - |
- #include <dt-bindings/sound/qcom,q6afe.h>
- #include <dt-bindings/sound/qcom,q6asm.h>
- sound@7702000 {
- compatible = "qcom,msm8916-qdsp6-sndcard";
- reg = <0x07702000 0x4>, <0x07702004 0x4>;
- reg-names = "mic-iomux", "spkr-iomux";
-
- model = "msm8916";
- widgets =
- "Speaker", "Speaker",
- "Headphone", "Headphones";
- pin-switches = "Speaker";
- audio-routing =
- "Speaker", "Speaker Amp OUT",
- "Speaker Amp IN", "HPH_R",
- "Headphones", "HPH_L",
- "Headphones", "HPH_R",
- "AMIC1", "MIC BIAS Internal1",
- "AMIC2", "MIC BIAS Internal2",
- "AMIC3", "MIC BIAS Internal3";
- aux-devs = <&speaker_amp>;
-
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cdc_pdm_lines_act>;
- pinctrl-1 = <&cdc_pdm_lines_sus>;
-
- mm1-dai-link {
- link-name = "MultiMedia1";
- cpu {
- sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
- };
- };
-
- primary-dai-link {
- link-name = "Primary MI2S";
- cpu {
- sound-dai = <&q6afedai PRIMARY_MI2S_RX>;
- };
platform {
sound-dai = <&q6routing>;
};
- codec {
- sound-dai = <&lpass_codec 0>, <&wcd_codec 0>;
- };
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt b/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt
deleted file mode 100644
index 5d6ea66a863f..000000000000
--- a/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt
+++ /dev/null
@@ -1,123 +0,0 @@
-QCOM WCD9335 Codec
-
-Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC, supports
-Qualcomm Technologies, Inc. (QTI) multimedia solutions, including
-the MSM8996, MSM8976, and MSM8956 chipsets. It has in-built
-Soundwire controller, interrupt mux. It supports both I2S/I2C and
-SLIMbus audio interfaces.
-
-Required properties with SLIMbus Interface:
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: For SLIMbus interface it should be "slimMID,PID",
- textual representation of Manufacturer ID, Product Code,
- shall be in lower case hexadecimal with leading zeroes
- suppressed. Refer to slimbus/bus.txt for details.
- Should be:
- "slim217,1a0" for MSM8996 and APQ8096 SoCs with SLIMbus.
-
-- reg
- Usage: required
- Value type: <u32 u32>
- Definition: Should be ('Device index', 'Instance ID')
-
-- interrupts
- Usage: required
- Value type: <prop-encoded-array>
- Definition: Interrupts via WCD INTR1 and INTR2 pins
-
-- interrupt-names:
- Usage: required
- Value type: <String array>
- Definition: Interrupt names of WCD INTR1 and INTR2
- Should be: "intr1", "intr2"
-
-- reset-gpios:
- Usage: required
- Value type: <String Array>
- Definition: Reset gpio line
-
-- slim-ifc-dev:
- Usage: required
- Value type: <phandle>
- Definition: SLIM interface device
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: See clock-bindings.txt section "consumers". List of
- three clock specifiers for mclk, mclk2 and slimbus clock.
-
-- clock-names:
- Usage: required
- Value type: <string>
- Definition: Must contain "mclk", "mclk2" and "slimbus" strings.
-
-- vdd-buck-supply:
- Usage: required
- Value type: <phandle>
- Definition: Should contain a reference to the 1.8V buck supply
-
-- vdd-buck-sido-supply:
- Usage: required
- Value type: <phandle>
- Definition: Should contain a reference to the 1.8V SIDO buck supply
-
-- vdd-rx-supply:
- Usage: required
- Value type: <phandle>
- Definition: Should contain a reference to the 1.8V rx supply
-
-- vdd-tx-supply:
- Usage: required
- Value type: <phandle>
- Definition: Should contain a reference to the 1.8V tx supply
-
-- vdd-vbat-supply:
- Usage: Optional
- Value type: <phandle>
- Definition: Should contain a reference to the vbat supply
-
-- vdd-micbias-supply:
- Usage: required
- Value type: <phandle>
- Definition: Should contain a reference to the micbias supply
-
-- vdd-io-supply:
- Usage: required
- Value type: <phandle>
- Definition: Should contain a reference to the 1.8V io supply
-
-- interrupt-controller:
- Usage: required
- Definition: Indicating that this is a interrupt controller
-
-- #interrupt-cells:
- Usage: required
- Value type: <int>
- Definition: should be 1
-
-#sound-dai-cells
- Usage: required
- Value type: <u32>
- Definition: Must be 1
-
-audio-codec@1{
- compatible = "slim217,1a0";
- reg = <1 0>;
- interrupts = <&msmgpio 54 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr2"
- reset-gpios = <&msmgpio 64 0>;
- slim-ifc-dev = <&wc9335_ifd>;
- clock-names = "mclk", "native";
- clocks = <&rpmcc RPM_SMD_DIV_CLK1>,
- <&rpmcc RPM_SMD_BB_CLK1>;
- vdd-buck-supply = <&pm8994_s4>;
- vdd-rx-supply = <&pm8994_s4>;
- vdd-buck-sido-supply = <&pm8994_s4>;
- vdd-tx-supply = <&pm8994_s4>;
- vdd-io-supply = <&pm8994_s4>;
- #sound-dai-cells = <1>;
-}
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml
new file mode 100644
index 000000000000..34f8fe4da9d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wcd9335.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WCD9335 Audio Codec
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC with in-built
+ Soundwire controller and interrupt mux. It supports both I2S/I2C and SLIMbus
+ audio interfaces.
+
+properties:
+ compatible:
+ const: slim217,1a0
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: mclk
+ - const: slimbus
+
+ interrupts:
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: intr1
+ - const: intr2
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ slim-ifc-dev:
+ description: SLIM IFC device interface
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ '#sound-dai-cells':
+ const: 1
+
+ vdd-buck-supply:
+ description: 1.8V buck supply
+
+ vdd-buck-sido-supply:
+ description: 1.8V SIDO buck supply
+
+ vdd-io-supply:
+ description: 1.8V I/O supply
+
+ vdd-micbias-supply:
+ description: micbias supply
+
+ vdd-rx-supply:
+ description: 1.8V rx supply
+
+ vdd-tx-supply:
+ description: 1.8V tx supply
+
+ vdd-vbat-supply:
+ description: vbat supply
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ required:
+ - slim-ifc-dev
+ then:
+ required:
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interrupt-controller
+ - '#interrupt-cells'
+ - reset-gpios
+ - slim-ifc-dev
+ - '#sound-dai-cells'
+ - vdd-buck-supply
+ - vdd-buck-sido-supply
+ - vdd-io-supply
+ - vdd-rx-supply
+ - vdd-tx-supply
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+ interrupts: false
+ interrupt-names: false
+ interrupt-controller: false
+ '#interrupt-cells': false
+ reset-gpios: false
+ slim-ifc-dev: false
+ '#sound-dai-cells': false
+ vdd-buck-supply: false
+ vdd-buck-sido-supply: false
+ vdd-io-supply: false
+ vdd-micbias-supply: false
+ vdd-rx-supply: false
+ vdd-tx-supply: false
+ vdd-vbat-supply: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ tasha_ifd: codec@0,0 {
+ compatible = "slim217,1a0";
+ reg = <0 0>;
+ };
+
+ codec@1,0 {
+ compatible = "slim217,1a0";
+ reg = <1 0>;
+
+ clock-names = "mclk", "slimbus";
+ clocks = <&div1_mclk>, <&rpmcc RPM_SMD_BB_CLK1>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <54 IRQ_TYPE_LEVEL_HIGH>,
+ <53 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr1", "intr2";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ reset-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>;
+ slim-ifc-dev = <&tasha_ifd>;
+ #sound-dai-cells = <1>;
+
+ vdd-buck-supply = <&vreg_s4a_1p8>;
+ vdd-buck-sido-supply = <&vreg_s4a_1p8>;
+ vdd-tx-supply = <&vreg_s4a_1p8>;
+ vdd-rx-supply = <&vreg_s4a_1p8>;
+ vdd-io-supply = <&vreg_s4a_1p8>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
index 8ca19f2b0b3d..3a7334e41fd6 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/qcom,wcd934x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for Qualcomm WCD9340/WCD9341 Audio Codec
+title: Qualcomm WCD9340/WCD9341 Audio Codec
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -28,7 +28,9 @@ properties:
description: GPIO spec for reset line to use
maxItems: 1
- slim-ifc-dev: true
+ slim-ifc-dev:
+ description: IFC device interface
+ $ref: /schemas/types.yaml#/definitions/phandle
clocks:
maxItems: 1
@@ -130,8 +132,9 @@ properties:
$ref: /schemas/gpio/qcom,wcd934x-gpio.yaml#
patternProperties:
- "^.*@[0-9a-f]+$":
+ "@[0-9a-f]+$":
type: object
+ additionalProperties: true
description: |
WCD934x subnode for each slave devices. Bindings of each subnodes
depends on the specific driver providing the functionality and
@@ -147,31 +150,61 @@ patternProperties:
required:
- compatible
- reg
- - reset-gpios
- - slim-ifc-dev
- - interrupts
- - interrupt-controller
- - clock-frequency
- - clock-output-names
- - qcom,micbias1-microvolt
- - qcom,micbias2-microvolt
- - qcom,micbias3-microvolt
- - qcom,micbias4-microvolt
- - "#interrupt-cells"
- - "#clock-cells"
- - "#sound-dai-cells"
- - "#address-cells"
- - "#size-cells"
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ required:
+ - slim-ifc-dev
+ then:
+ required:
+ - reset-gpios
+ - slim-ifc-dev
+ - interrupt-controller
+ - clock-frequency
+ - clock-output-names
+ - qcom,micbias1-microvolt
+ - qcom,micbias2-microvolt
+ - qcom,micbias3-microvolt
+ - qcom,micbias4-microvolt
+ - "#interrupt-cells"
+ - "#clock-cells"
+ - "#sound-dai-cells"
+ - "#address-cells"
+ - "#size-cells"
+ oneOf:
+ - required:
+ - interrupts-extended
+ - required:
+ - interrupts
+ else:
+ properties:
+ reset-gpios: false
+ slim-ifc-dev: false
+ interrupts: false
+ interrupt-controller: false
+ clock-frequency: false
+ clock-output-names: false
+ qcom,micbias1-microvolt: false
+ qcom,micbias2-microvolt: false
+ qcom,micbias3-microvolt: false
+ qcom,micbias4-microvolt: false
+ "#interrupt-cells": false
+ "#clock-cells": false
+ "#sound-dai-cells": false
+ "#address-cells": false
+ "#size-cells": false
additionalProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
codec@1,0{
compatible = "slim217,250";
- reg = <1 0>;
- reset-gpios = <&tlmm 64 0>;
- slim-ifc-dev = <&wcd9340_ifd>;
+ reg = <1 0>;
+ reset-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>;
+ slim-ifc-dev = <&wcd9340_ifd>;
#sound-dai-cells = <1>;
interrupt-parent = <&tlmm>;
interrupts = <54 4>;
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml
new file mode 100644
index 000000000000..c8543f969ebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wcd937x-sdw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoundWire Slave devices on WCD9370/WCD9375
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Qualcomm WCD9370/WCD9375 Codec is a standalone Hi-Fi audio codec IC.
+ It has RX and TX Soundwire slave devices. This bindings is for the
+ slave devices.
+
+properties:
+ compatible:
+ const: sdw20217010a00
+
+ reg:
+ maxItems: 1
+
+ qcom,tx-port-mapping:
+ description: |
+ Specifies static port mapping between device and host tx ports.
+ In the order of the device port index which are adc1_port, adc23_port,
+ dmic03_mbhc_port, dmic46_port.
+ Supports maximum 4 tx soundwire ports.
+
+ WCD9370 TX Port 1 (ADC1) <=> SWR2 Port 2
+ WCD9370 TX Port 2 (ADC2, 3) <=> SWR2 Port 2
+ WCD9370 TX Port 3 (DMIC0,1,2,3 & MBHC) <=> SWR2 Port 3
+ WCD9370 TX Port 4 (DMIC4,5,6,7) <=> SWR2 Port 4
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+ items:
+ enum: [1, 2, 3, 4]
+
+ qcom,rx-port-mapping:
+ description: |
+ Specifies static port mapping between device and host rx ports.
+ In the order of device port index which are hph_port, clsh_port,
+ comp_port, lo_port, dsd port.
+ Supports maximum 5 rx soundwire ports.
+
+ WCD9370 RX Port 1 (HPH_L/R) <==> SWR1 Port 1 (HPH_L/R)
+ WCD9370 RX Port 2 (CLSH) <==> SWR1 Port 2 (CLSH)
+ WCD9370 RX Port 3 (COMP_L/R) <==> SWR1 Port 3 (COMP_L/R)
+ WCD9370 RX Port 4 (LO) <==> SWR1 Port 4 (LO)
+ WCD9370 RX Port 5 (DSD_L/R) <==> SWR1 Port 5 (DSD)
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 5
+ maxItems: 5
+ items:
+ enum: [1, 2, 3, 4, 5]
+
+ qcom,tx-channel-mapping:
+ description: |
+ Specifies static channel mapping between slave and master tx port
+ channels.
+ In the order of slave port channels which is adc1, adc2, adc3,
+ dmic0, dmic1, mbhc, dmic2, dmic3, dmci4, dmic5, dmic6, dmic7.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 12
+ maxItems: 12
+ additionalItems: false
+ items:
+ enum:
+ - 1 # WCD9370_SWRM_CH1
+ - 2 # WCD9370_SWRM_CH2
+ - 3 # WCD9370_SWRM_CH3
+ - 4 # WCD9370_SWRM_CH4
+
+ qcom,rx-channel-mapping:
+ description: |
+ Specifies static channels mapping between slave and master rx port
+ channels.
+ In the order of slave port channels, which is
+ hph_l, hph_r, clsh, comp_l, comp_r, lo, dsd_r, dsd_l.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 8
+ maxItems: 8
+ additionalItems: false
+ items:
+ enum:
+ - 1 # WCD9370_SWRM_CH1
+ - 2 # WCD9370_SWRM_CH2
+ - 3 # WCD9370_SWRM_CH3
+ - 4 # WCD9370_SWRM_CH4
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soundwire@3210000 {
+ reg = <0x03210000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ wcd937x_rx: codec@0,4 {
+ compatible = "sdw20217010a00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 2 3 4 5>;
+ qcom,rx-channel-mapping = /bits/ 8 <1 2 1 1 2 1 1 2>;
+ };
+ };
+
+ soundwire@3230000 {
+ reg = <0x03230000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ wcd937x_tx: codec@0,3 {
+ compatible = "sdw20217010a00";
+ reg = <0 3>;
+ qcom,tx-port-mapping = <2 2 3 4>;
+ qcom,tx-channel-mapping = /bits/ 8 <1 2 1 1 2 3 3 4 1 2 3 4>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
new file mode 100644
index 000000000000..f94203798f24
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wcd937x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WCD9370/WCD9375 Audio Codec
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ Qualcomm WCD9370/WCD9375 Codec is a standalone Hi-Fi audio codec IC.
+ It has RX and TX Soundwire slave devices.
+
+allOf:
+ - $ref: dai-common.yaml#
+ - $ref: qcom,wcd93xx-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,wcd9370-codec
+ - items:
+ - const: qcom,wcd9375-codec
+ - const: qcom,wcd9370-codec
+
+ vdd-px-supply:
+ description: A reference to the 1.8V I/O supply
+
+required:
+ - compatible
+ - vdd-px-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ codec {
+ compatible = "qcom,wcd9370-codec";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&wcd_reset_n>;
+ pinctrl-1 = <&wcd_reset_n_sleep>;
+ reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
+ vdd-buck-supply = <&vreg_l17b_1p8>;
+ vdd-rxtx-supply = <&vreg_l18b_1p8>;
+ vdd-px-supply = <&vreg_l18b_1p8>;
+ vdd-mic-bias-supply = <&vreg_bob>;
+ qcom,micbias1-microvolt = <1800000>;
+ qcom,micbias2-microvolt = <1800000>;
+ qcom,micbias3-microvolt = <1800000>;
+ qcom,micbias4-microvolt = <1800000>;
+ qcom,rx-device = <&wcd937x_rx>;
+ qcom,tx-device = <&wcd937x_tx>;
+ #sound-dai-cells = <1>;
+ };
+
+ /* ... */
+
+ soundwire@3210000 {
+ reg = <0x03210000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ wcd937x_rx: codec@0,4 {
+ compatible = "sdw20217010a00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 2 3 4 5>;
+ };
+ };
+
+ soundwire@3230000 {
+ reg = <0x03230000 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ wcd937x_tx: codec@0,3 {
+ compatible = "sdw20217010a00";
+ reg = <0 3>;
+ qcom,tx-port-mapping = <1 2 3 4>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml
index 49a267b306f6..7b31bf93f1a1 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/qcom,wcd938x-sdw.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for Qualcomm SoundWire Slave devices on WCD9380/WCD9385
+title: Qualcomm SoundWire Slave devices on WCD9380/WCD9385
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -51,7 +51,7 @@ examples:
reg = <0x03210000 0x2000>;
wcd938x_rx: codec@0,4 {
compatible = "sdw20217010d00";
- reg = <0 4>;
+ reg = <0 4>;
qcom,rx-port-mapping = <1 2 3 4 5>;
};
};
@@ -62,7 +62,7 @@ examples:
reg = <0x03230000 0x2000>;
wcd938x_tx: codec@0,3 {
compatible = "sdw20217010d00";
- reg = <0 3>;
+ reg = <0 3>;
qcom,tx-port-mapping = <2 3 4 5>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml
index 51547190f709..ab1c6285dbf8 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/qcom,wcd938x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for Qualcomm WCD9380/WCD9385 Audio Codec
+title: Qualcomm WCD9380/WCD9385 Audio Codec
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -13,106 +13,37 @@ description: |
Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC.
It has RX and TX Soundwire slave devices.
+allOf:
+ - $ref: dai-common.yaml#
+ - $ref: qcom,wcd93xx-common.yaml#
+
properties:
compatible:
enum:
- qcom,wcd9380-codec
- qcom,wcd9385-codec
- reset-gpios:
- description: GPIO spec for reset line to use
+ mux-controls:
+ description: A reference to the audio mux switch for
+ switching CTIA/OMTP Headset types
maxItems: 1
us-euro-gpios:
description: GPIO spec for swapping gnd and mic segments
maxItems: 1
-
- vdd-buck-supply:
- description: A reference to the 1.8V buck supply
-
- vdd-rxtx-supply:
- description: A reference to the 1.8V rx supply
-
- vdd-io-supply:
- description: A reference to the 1.8V I/O supply
-
- vdd-mic-bias-supply:
- description: A reference to the 3.8V mic bias supply
-
- qcom,tx-device:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: A reference to Soundwire tx device phandle
-
- qcom,rx-device:
- $ref: /schemas/types.yaml#/definitions/phandle-array
- description: A reference to Soundwire rx device phandle
-
- qcom,micbias1-microvolt:
- description: micbias1 voltage
- minimum: 1800000
- maximum: 2850000
-
- qcom,micbias2-microvolt:
- description: micbias2 voltage
- minimum: 1800000
- maximum: 2850000
-
- qcom,micbias3-microvolt:
- description: micbias3 voltage
- minimum: 1800000
- maximum: 2850000
-
- qcom,micbias4-microvolt:
- description: micbias4 voltage
- minimum: 1800000
- maximum: 2850000
-
- qcom,hphl-jack-type-normally-closed:
- description: Indicates that HPHL jack switch type is normally closed
- type: boolean
-
- qcom,ground-jack-type-normally-closed:
- description: Indicates that Headset Ground switch type is normally closed
- type: boolean
-
- qcom,mbhc-headset-vthreshold-microvolt:
- description: Voltage threshold value for headset detection
- minimum: 0
- maximum: 2850000
-
- qcom,mbhc-headphone-vthreshold-microvolt:
- description: Voltage threshold value for headphone detection
- minimum: 0
- maximum: 2850000
-
- qcom,mbhc-buttons-vthreshold-microvolt:
- description:
- Array of 8 Voltage threshold values corresponding to headset
- button0 - button7
- minItems: 8
- maxItems: 8
-
- '#sound-dai-cells':
- const: 1
+ deprecated: true
required:
- compatible
- - reset-gpios
- - qcom,tx-device
- - qcom,rx-device
- - qcom,micbias1-microvolt
- - qcom,micbias2-microvolt
- - qcom,micbias3-microvolt
- - qcom,micbias4-microvolt
- - "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
codec {
compatible = "qcom,wcd9380-codec";
- reset-gpios = <&tlmm 32 0>;
+ reset-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
#sound-dai-cells = <1>;
qcom,tx-device = <&wcd938x_tx>;
qcom,rx-device = <&wcd938x_rx>;
@@ -134,7 +65,7 @@ examples:
reg = <0x03210000 0x2000>;
wcd938x_rx: codec@0,4 {
compatible = "sdw20217010d00";
- reg = <0 4>;
+ reg = <0 4>;
qcom,rx-port-mapping = <1 2 3 4 5>;
};
};
@@ -145,7 +76,7 @@ examples:
reg = <0x03230000 0x2000>;
wcd938x_tx: codec@0,3 {
compatible = "sdw20217010d00";
- reg = <0 3>;
+ reg = <0 3>;
qcom,tx-port-mapping = <2 3 4 5>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml
new file mode 100644
index 000000000000..67ed7701b5d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd939x-sdw.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wcd939x-sdw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoundWire devices on WCD9390/WCD9395
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Qualcomm WCD9390/WCD9395 Codec is a standalone Hi-Fi audio codec IC.
+ It has RX and TX Soundwire devices. This bindings is for the devices.
+
+properties:
+ compatible:
+ const: sdw20217010e00
+
+ reg:
+ maxItems: 1
+
+ qcom,tx-port-mapping:
+ description: |
+ Specifies static port mapping between device and host tx ports.
+ In the order of the device port index.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+
+ qcom,rx-port-mapping:
+ description: |
+ Specifies static port mapping between device and host rx ports.
+ In the order of device port index.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 6
+ maxItems: 6
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soundwire@3210000 {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ reg = <0x03210000 0x2000>;
+ wcd938x_rx: codec@0,4 {
+ compatible = "sdw20217010e00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 2 3 4 5 6>;
+ };
+ };
+
+ soundwire@3230000 {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ reg = <0x03230000 0x2000>;
+ wcd938x_tx: codec@0,3 {
+ compatible = "sdw20217010e00";
+ reg = <0 3>;
+ qcom,tx-port-mapping = <2 3 4 5>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml
new file mode 100644
index 000000000000..85283f94465d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd939x.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wcd939x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WCD9380/WCD9385 Audio Codec
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description: |
+ Qualcomm WCD9390/WCD9395 Codec is a standalone Hi-Fi audio codec IC.
+ It has RX and TX Soundwire devices.
+ The WCD9390/WCD9395 IC has a functionally separate USB-C Mux subsystem
+ accessible over an I2C interface.
+ The Audio Headphone and Microphone data path between the Codec and the USB-C Mux
+ subsystems are external to the IC, thus requiring DT port-endpoint graph description
+ to handle USB-C altmode & orientation switching for Audio Accessory Mode.
+
+allOf:
+ - $ref: dai-common.yaml#
+ - $ref: qcom,wcd93xx-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,wcd9390-codec
+ - items:
+ - const: qcom,wcd9395-codec
+ - const: qcom,wcd9390-codec
+
+ mode-switch:
+ description: Flag the port as possible handler of altmode switching
+ type: boolean
+
+ orientation-switch:
+ description: Flag the port as possible handler of orientation switching
+ type: boolean
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the WCD939x Codec node to USB MUX subsystems for the
+ purpose of handling altmode muxing and orientation switching to detect and
+ enable Audio Accessory Mode.
+
+ vdd-px-supply:
+ description: A reference to the 1.2V PX supply
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ codec {
+ compatible = "qcom,wcd9390-codec";
+ reset-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <1>;
+ qcom,tx-device = <&wcd939x_tx>;
+ qcom,rx-device = <&wcd939x_rx>;
+ qcom,micbias1-microvolt = <1800000>;
+ qcom,micbias2-microvolt = <1800000>;
+ qcom,micbias3-microvolt = <1800000>;
+ qcom,micbias4-microvolt = <1800000>;
+ qcom,hphl-jack-type-normally-closed;
+ qcom,ground-jack-type-normally-closed;
+ qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>;
+ qcom,mbhc-headphone-vthreshold-microvolt = <50000>;
+ };
+
+ /* ... */
+
+ soundwire@3210000 {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ reg = <0x03210000 0x2000>;
+ wcd939x_rx: codec@0,4 {
+ compatible = "sdw20217010e00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 2 3 4 5 6>;
+ };
+ };
+
+ soundwire@3230000 {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ reg = <0x03230000 0x2000>;
+ wcd938x_tx: codec@0,3 {
+ compatible = "sdw20217010e00";
+ reg = <0 3>;
+ qcom,tx-port-mapping = <2 3 4 5>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
new file mode 100644
index 000000000000..f78ba148ad25
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wcd93xx-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for Qualcomm WCD93xx Audio Codec
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+properties:
+ reset-gpios:
+ description: GPIO spec for reset line to use
+ maxItems: 1
+
+ vdd-buck-supply:
+ description: A reference to the 1.8V buck supply
+
+ vdd-rxtx-supply:
+ description: A reference to the 1.8V rx supply
+
+ vdd-io-supply:
+ description: A reference to the 1.8V I/O supply
+
+ vdd-mic-bias-supply:
+ description: A reference to the 3.8V mic bias supply
+
+ qcom,tx-device:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A reference to Soundwire tx device phandle
+
+ qcom,rx-device:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: A reference to Soundwire rx device phandle
+
+ qcom,micbias1-microvolt:
+ description: micbias1 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,micbias2-microvolt:
+ description: micbias2 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,micbias3-microvolt:
+ description: micbias3 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,micbias4-microvolt:
+ description: micbias4 voltage
+ minimum: 1800000
+ maximum: 2850000
+
+ qcom,hphl-jack-type-normally-closed:
+ description: Indicates that HPHL jack switch type is normally closed
+ type: boolean
+
+ qcom,ground-jack-type-normally-closed:
+ description: Indicates that Headset Ground switch type is normally closed
+ type: boolean
+
+ qcom,mbhc-headset-vthreshold-microvolt:
+ description: Voltage threshold value for headset detection
+ minimum: 0
+ maximum: 2850000
+
+ qcom,mbhc-headphone-vthreshold-microvolt:
+ description: Voltage threshold value for headphone detection
+ minimum: 0
+ maximum: 2850000
+
+ qcom,mbhc-buttons-vthreshold-microvolt:
+ description:
+ Array of 8 Voltage threshold values corresponding to headset
+ button0 - button7
+ minItems: 8
+ maxItems: 8
+
+ '#sound-dai-cells':
+ const: 1
+
+required:
+ - reset-gpios
+ - qcom,tx-device
+ - qcom,rx-device
+ - qcom,micbias1-microvolt
+ - qcom,micbias2-microvolt
+ - qcom,micbias3-microvolt
+ - qcom,micbias4-microvolt
+ - "#sound-dai-cells"
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml
index ea44d03e58ca..ac03672ebf6d 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wsa881x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/qcom,wsa881x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for Qualcomm WSA8810/WSA8815 Class-D Smart Speaker Amplifier
+title: Qualcomm WSA8810/WSA8815 Class-D Smart Speaker Amplifier
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
@@ -15,6 +15,9 @@ description: |
Their primary operating mode uses a SoundWire digital audio
interface. This binding is for SoundWire interface.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: sdw10217201000
@@ -39,7 +42,7 @@ required:
- "#thermal-sensor-cells"
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml
index 6113f65f2990..098f1df62c8c 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wsa883x.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/qcom,wsa883x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for The Qualcomm WSA8830/WSA8832/WSA8835
+title: Qualcomm WSA8830/WSA8832/WSA8835
smart speaker amplifier
maintainers:
@@ -15,6 +15,9 @@ description: |
Their primary operating mode uses a SoundWire digital audio
interface. This binding is for SoundWire interface.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: sdw10217020200
@@ -23,12 +26,24 @@ properties:
maxItems: 1
powerdown-gpios:
- description: GPIO spec for Powerdown/Shutdown line to use
+ description: GPIO spec for Powerdown/Shutdown line to use (pin SD_N)
+ maxItems: 1
+
+ reset-gpios:
+ description: Powerdown/Shutdown line to use (pin SD_N)
maxItems: 1
vdd-supply:
description: VDD Supply for the Codec
+ qcom,port-mapping:
+ description: |
+ Specifies static port mapping between slave and master ports.
+ In the order of slave port index.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+
'#thermal-sensor-cells':
const: 0
@@ -39,15 +54,22 @@ required:
- compatible
- reg
- vdd-supply
- - powerdown-gpios
- "#thermal-sensor-cells"
- "#sound-dai-cells"
-additionalProperties: false
+oneOf:
+ - required:
+ - powerdown-gpios
+ - required:
+ - reset-gpios
+
+unevaluatedProperties: false
examples:
- |
- soundwire-controller@3250000 {
+ #include <dt-bindings/gpio/gpio.h>
+
+ soundwire@3250000 {
#address-cells = <2>;
#size-cells = <0>;
reg = <0x3250000 0x2000>;
@@ -55,19 +77,21 @@ examples:
speaker@0,1 {
compatible = "sdw10217020200";
reg = <0 1>;
- powerdown-gpios = <&tlmm 1 0>;
+ powerdown-gpios = <&tlmm 1 GPIO_ACTIVE_LOW>;
vdd-supply = <&vreg_s10b_1p8>;
#thermal-sensor-cells = <0>;
#sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrLeft";
};
speaker@0,2 {
compatible = "sdw10217020200";
reg = <0 2>;
- powerdown-gpios = <&tlmm 89 0>;
+ powerdown-gpios = <&tlmm 89 GPIO_ACTIVE_LOW>;
vdd-supply = <&vreg_s10b_1p8>;
#thermal-sensor-cells = <0>;
#sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrRight";
};
};
diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml
new file mode 100644
index 000000000000..866c5e780fb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,wsa8840.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WSA8840/WSA8845/WSA8845H smart speaker amplifier
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+description:
+ WSA884X is a family of Qualcomm Aqstic smart speaker amplifiers using
+ SoundWire digital audio interface.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: sdw20217020400
+
+ reg:
+ maxItems: 1
+
+ powerdown-gpios:
+ description: Powerdown/Shutdown line to use (pin SD_N)
+ maxItems: 1
+
+ reset-gpios:
+ description: Powerdown/Shutdown line to use (pin SD_N)
+ maxItems: 1
+
+ qcom,port-mapping:
+ description: |
+ Specifies static port mapping between slave and master ports.
+ In the order of slave port index.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 6
+ maxItems: 6
+
+ '#sound-dai-cells':
+ const: 0
+
+ vdd-1p8-supply: true
+ vdd-io-supply: true
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+ - vdd-1p8-supply
+ - vdd-io-supply
+
+oneOf:
+ - required:
+ - powerdown-gpios
+ - required:
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ soundwire {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spkr_2_sd_n_active>;
+ powerdown-gpios = <&lpass_tlmm 18 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrRight";
+ vdd-1p8-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l3g_1p2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,alc203.yaml b/Documentation/devicetree/bindings/sound/realtek,alc203.yaml
new file mode 100644
index 000000000000..6b90788b45eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,alc203.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,alc203.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek ALC203 AC97 Audio Codec
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ ALC203 is a full duplex AC97 2.3 compatible stereo audio codec.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: realtek,alc203
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ audio-codec {
+ compatible = "realtek,alc203";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,alc5623.yaml b/Documentation/devicetree/bindings/sound/realtek,alc5623.yaml
new file mode 100644
index 000000000000..683c58c3ef50
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,alc5623.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,alc5623.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ALC5621/ALC5623 Audio Codec
+
+maintainers:
+ - Mahdi Khosravi <mmk1776@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - realtek,alc5621
+ - realtek,alc5623
+
+ reg:
+ maxItems: 1
+
+ add-ctrl:
+ description:
+ Default register value for Reg-40h, Additional Control Register.
+ If absent or zero, the register is left untouched.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ jack-det-ctrl:
+ description:
+ Default register value for Reg-5Ah, Jack Detect Control Register.
+ If absent or zero, the register is left untouched.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "realtek,alc5623";
+ reg = <0x1a>;
+ add-ctrl = <0x3700>;
+ jack-det-ctrl = <0x4810>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,alc5632.yaml b/Documentation/devicetree/bindings/sound/realtek,alc5632.yaml
new file mode 100644
index 000000000000..fb05988ff7ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,alc5632.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,alc5632.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ALC5632 audio CODEC
+
+description: |
+ Pins on the device (for linking into audio routes):
+ * SPK_OUTP
+ * SPK_OUTN
+ * HP_OUT_L
+ * HP_OUT_R
+ * AUX_OUT_P
+ * AUX_OUT_N
+ * LINE_IN_L
+ * LINE_IN_R
+ * PHONE_P
+ * PHONE_N
+ * MIC1_P
+ * MIC1_N
+ * MIC2_P
+ * MIC2_N
+ * MICBIAS1
+ * DMICDAT
+
+maintainers:
+ - Leon Romanovsky <leon@leon.nu>
+
+properties:
+ compatible:
+ const: realtek,alc5632
+
+ reg:
+ maxItems: 1
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - '#gpio-cells'
+ - gpio-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ compatible = "realtek,alc5632";
+ reg = <0x1a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1015.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1015.yaml
new file mode 100644
index 000000000000..880196081a60
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt1015.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt1015.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT1015 Mono Class D Audio Amplifier
+
+maintainers:
+ - Jack Yu <jack.yu@realtek.com>
+
+properties:
+ compatible:
+ enum:
+ - realtek,rt1015
+
+ reg:
+ maxItems: 1
+
+ realtek,power-up-delay-ms:
+ description: Set a delay time for flush work to be completed,
+ this vlaue is adjustable depending on platform.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@28 {
+ compatible = "realtek,rt1015";
+ reg = <0x28>;
+ realtek,power-up-delay-ms = <50>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml
index 1d73204451b1..7dac9e6f7f08 100644
--- a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml
+++ b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/sound/realtek,rt1015p.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Realtek rt1015p codec devicetree bindings
+title: Realtek rt1015p codec
maintainers:
- - Tzung-Bi Shih <tzungbi@google.com>
+ - Tzung-Bi Shih <tzungbi@kernel.org>
description: |
Rt1015p is a rt1015 variant which does not support I2C and
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml
new file mode 100644
index 000000000000..5287e9c9197e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt1016.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt1016.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Reaktek RT1016 Stereo Class D Audio Amplifier
+
+maintainers:
+ - oder_chiou@realtek.com
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: realtek,rt1016
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ compatible = "realtek,rt1016";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1019.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1019.yaml
new file mode 100644
index 000000000000..adf5e38f4dbc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt1019.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt1019.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT1019 Mono Class-D Audio Amplifier
+
+maintainers:
+ - jack.yu@realtek.com
+
+properties:
+ compatible:
+ const: realtek,rt1019
+
+ reg:
+ maxItems: 1
+ description: I2C address of the device.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rt1019: codec@28 {
+ compatible = "realtek,rt1019";
+ reg = <0x28>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml
new file mode 100644
index 000000000000..7fbf7739c371
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5514.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5514.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT5514 audio CODEC
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+description: |
+ This device supports both I2C and SPI.
+
+ Pins on the device (for linking into audio routes) for I2C:
+ * DMIC1L
+ * DMIC1R
+ * DMIC2L
+ * DMIC2R
+ * AMICL
+ * AMICR
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: realtek,rt5514
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master clock to the CODEC
+
+ clock-names:
+ items:
+ - const: mclk
+
+ interrupts:
+ maxItems: 1
+ description: The interrupt number to the cpu.
+
+ realtek,dmic-init-delay-ms:
+ description: Set the DMIC initial delay (ms) to wait it ready for I2C.
+
+ spi-max-frequency: true
+
+ wakeup-source:
+ type: boolean
+ description: Flag to indicate this device can wake system (suspend/resume).
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@57 {
+ compatible = "realtek,rt5514";
+ reg = <0x57>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5616.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5616.yaml
new file mode 100644
index 000000000000..29071044c66e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5616.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5616.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek rt5616 ALSA SoC audio codec driver
+
+description: |
+ Pins on the device (for linking into audio routes) for RT5616:
+
+ * IN1P
+ * IN2P
+ * IN2N
+ * LOUTL
+ * LOUTR
+ * HPOL
+ * HPOR
+
+maintainers:
+ - Bard Liao <bardliao@realtek.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: realtek,rt5616
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master clock to the CODEC
+
+ clock-names:
+ items:
+ - const: mclk
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@1b {
+ compatible = "realtek,rt5616";
+ reg = <0x1b>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5631.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5631.yaml
new file mode 100644
index 000000000000..747a731c44c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5631.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5631.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ALC5631/RT5631 audio CODEC
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+description: |
+ This device supports I2C only.
+
+ Pins on the device (for linking into audio routes):
+ * SPK_OUT_R_P
+ * SPK_OUT_R_N
+ * SPK_OUT_L_P
+ * SPK_OUT_L_N
+ * HP_OUT_L
+ * HP_OUT_R
+ * AUX_OUT2_LP
+ * AUX_OUT2_RN
+ * AUX_OUT1_LP
+ * AUX_OUT1_RN
+ * AUX_IN_L_JD
+ * AUX_IN_R_JD
+ * MONO_IN_P
+ * MONO_IN_N
+ * MIC1_P
+ * MIC1_N
+ * MIC2_P
+ * MIC2_N
+ * MONO_OUT_P
+ * MONO_OUT_N
+ * MICBIAS1
+ * MICBIAS2
+
+properties:
+ compatible:
+ enum:
+ - realtek,alc5631
+ - realtek,rt5631
+
+ reg:
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ compatible = "realtek,alc5631";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml
new file mode 100644
index 000000000000..3f4f59287c1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5640.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT5640/RT5639 audio CODEC
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+ This device supports I2C only.
+
+ Pins on the device (for linking into audio routes) for RT5639/RT5640:
+ * DMIC1
+ * DMIC2
+ * MICBIAS1
+ * IN1P
+ * IN1N
+ * IN2P
+ * IN2N
+ * IN3P
+ * IN3N
+ * HPOL
+ * HPOR
+ * LOUTL
+ * LOUTR
+ * SPOLP
+ * SPOLN
+ * SPORP
+ * SPORN
+
+ Additional pins on the device for RT5640:
+ * MONOP
+ * MONON
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - realtek,rt5640
+ - realtek,rt5639
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: The CODEC's interrupt output.
+
+ realtek,in1-differential:
+ description:
+ Indicate MIC1 input is differential, rather than single-ended.
+ type: boolean
+
+ realtek,in2-differential:
+ description:
+ Indicate MIC2 input is differential, rather than single-ended.
+ type: boolean
+
+ realtek,in3-differential:
+ description:
+ Indicate MIC3 input is differential, rather than single-ended.
+ type: boolean
+
+ realtek,lout-differential:
+ description:
+ Indicate LOUT output is differential, rather than single-ended.
+ type: boolean
+
+ realtek,dmic1-data-pin:
+ description: Specify which pin to be used as DMIC1 data pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic1 is not used
+ - 1 # using IN2P pin as dmic1 data pin
+ - 2 # using GPIO3 pin as dmic1 data pin
+
+ realtek,dmic2-data-pin:
+ description: Specify which pin to be used as DMIC2 data pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic2 is not used
+ - 1 # using IN2N pin as dmic2 data pin
+ - 2 # using GPIO4 pin as dmic2 data pin
+
+ realtek,jack-detect-source:
+ description: The Jack Detect source.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # Jack Detect function is not used
+ - 1 # Use GPIO1 for jack-detect
+ - 2 # Use JD1_IN4P for jack-detect
+ - 3 # Use JD2_IN4N for jack-detect
+ - 4 # Use GPIO2 for jack-detect
+ - 5 # Use GPIO3 for jack-detect
+ - 6 # Use GPIO4 for jack-detect
+
+ realtek,jack-detect-not-inverted:
+ description:
+ Normal jack-detect switches give an inverted signal, set this bool
+ in the rare case you've a jack-detect switch which is not inverted.
+ type: boolean
+
+ realtek,over-current-threshold-microamp:
+ description: micbias over-current detection threshold in µA
+ enum:
+ - 600
+ - 1500
+ - 2000
+
+ realtek,over-current-scale-factor:
+ description: micbias over-current detection scale-factor
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # Scale current by 0.5
+ - 1 # Scale current by 0.75
+ - 2 # Scale current by 1.0
+ - 3 # Scale current by 1.5
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "realtek,rt5640";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5645.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5645.yaml
new file mode 100644
index 000000000000..0a698798c22b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5645.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5645.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT5650/RT5645 audio CODEC
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+description: |
+ This device supports I2C only.
+
+ Pins on the device (for linking into audio routes) for RT5645/RT5650:
+ * DMIC L1
+ * DMIC R1
+ * DMIC L2
+ * DMIC R2
+ * IN1P
+ * IN1N
+ * IN2P
+ * IN2N
+ * Haptic Generator
+ * HPOL
+ * HPOR
+ * LOUTL
+ * LOUTR
+ * PDM1L
+ * PDM1R
+ * SPOL
+ * SPOR
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - realtek,rt5645
+ - realtek,rt5650
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description: The CODEC's interrupt output.
+
+ avdd-supply:
+ description: Power supply for AVDD, providing 1.8V.
+
+ cpvdd-supply:
+ description: Power supply for CPVDD, providing 1.8V.
+
+ hp-detect-gpios:
+ description:
+ A GPIO spec for the external headphone detect pin. If jd-mode = 0, we
+ will get the JD status by getting the value of hp-detect-gpios.
+ maxItems: 1
+
+ cbj-sleeve-gpios:
+ description:
+ A GPIO spec to control the external combo jack circuit to tie the
+ sleeve/ring2 contacts to the ground or floating. It could avoid some
+ electric noise from the active speaker jacks.
+ maxItems: 1
+
+ realtek,in2-differential:
+ description:
+ Indicate MIC2 input are differential, rather than single-ended.
+ type: boolean
+
+ realtek,dmic1-data-pin:
+ description: Specify which pin to be used as DMIC1 data pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic1 is not used
+ - 1 # using IN2P pin as dmic1 data pin
+ - 2 # using GPIO6 pin as dmic1 data pin
+ - 3 # using GPIO10 pin as dmic1 data pin
+ - 4 # using GPIO12 pin as dmic1 data pin
+
+ realtek,dmic2-data-pin:
+ description: Specify which pin to be used as DMIC2 data pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic2 is not used
+ - 1 # using IN2N pin as dmic2 data pin
+ - 2 # using GPIO5 pin as dmic2 data pin
+ - 3 # using GPIO11 pin as dmic2 data pin
+
+ realtek,jd-mode:
+ description: The JD mode of rt5645/rt5650.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # rt5645/rt5650 JD function is not used
+ - 1 # Mode-0 (VDD=3.3V), two port jack detection
+ - 2 # Mode-1 (VDD=3.3V), one port jack detection
+ - 3 # Mode-2 (VDD=1.8V), one port jack detection
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - avdd-supply
+ - cpvdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "realtek,rt5650";
+ reg = <0x1a>;
+ hp-detect-gpios = <&gpio 19 0>;
+ cbj-sleeve-gpios = <&gpio 20 0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ avdd-supply = <&avdd_reg>;
+ cpvdd-supply = <&cpvdd_supply>;
+ realtek,jd-mode = <3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml
new file mode 100644
index 000000000000..1100ffd9a7c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5659.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT5659/RT5658 audio CODEC
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+description: |
+ This device supports I2C only.
+
+ Pins on the device (for linking into audio routes) for RT5659/RT5658:
+ * DMIC L1
+ * DMIC R1
+ * DMIC L2
+ * DMIC R2
+ * IN1P
+ * IN1N
+ * IN2P
+ * IN2N
+ * IN3P
+ * IN3N
+ * IN4P
+ * IN4N
+ * HPOL
+ * HPOR
+ * SPOL
+ * SPOR
+ * LOUTL
+ * LOUTR
+ * MONOOUT
+ * PDML
+ * PDMR
+ * SPDIF
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - realtek,rt5659
+ - realtek,rt5658
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+ realtek,dmic1-data-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic1 is not used
+ - 1 # using IN2N pin as dmic1 data pin
+ - 2 # using GPIO5 pin as dmic1 data pin
+ - 3 # using GPIO9 pin as dmic1 data pin
+ - 4 # using GPIO11 pin as dmic1 data pin
+ description: Specify which pin to be used as DMIC1 data pin.
+ default: 0
+
+ realtek,dmic2-data-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic2 is not used
+ - 1 # using IN2P pin as dmic2 data pin
+ - 2 # using GPIO6 pin as dmic2 data pin
+ - 3 # using GPIO10 pin as dmic2 data pin
+ - 4 # using GPIO12 pin as dmic2 data pin
+ description: Specify which pin to be used as DMIC2 data pin.
+ default: 0
+
+ realtek,jd-src:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # No JD is used
+ - 1 # using JD3 as JD source
+ - 2 # JD source for Intel HDA header
+ description: Specify which JD source be used.
+ default: 0
+
+ realtek,ldo1-en-gpios:
+ maxItems: 1
+ description: CODEC's LDO1_EN pin.
+
+ realtek,reset-gpios:
+ maxItems: 1
+ description: CODEC's RESET pin.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1b {
+ compatible = "realtek,rt5659";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio>;
+ interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+ realtek,ldo1-en-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5677.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5677.yaml
new file mode 100644
index 000000000000..9ce23e58e5ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5677.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5677.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RT5677 audio CODEC
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+description: |
+ This device supports I2C only.
+
+ Pins on the device (for linking into audio routes):
+ * IN1P
+ * IN1N
+ * IN2P
+ * IN2N
+ * MICBIAS1
+ * DMIC1
+ * DMIC2
+ * DMIC3
+ * DMIC4
+ * LOUT1
+ * LOUT2
+ * LOUT3
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: realtek,rt5677
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ realtek,pow-ldo2-gpio:
+ maxItems: 1
+ description: CODEC's POW_LDO2 pin.
+
+ realtek,reset-gpio:
+ maxItems: 1
+ description: CODEC's RESET pin. Active low.
+
+ realtek,gpio-config:
+ description: |
+ Array of six 8bit elements that configures GPIO.
+ 0 - floating (reset value)
+ 1 - pull down
+ 2 - pull up
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 6
+ maxItems: 6
+ items:
+ maximum: 2
+
+ realtek,jd1-gpio:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # OFF
+ - 1 # GPIO1 for jd1.
+ - 2 # GPIO2 for jd1.
+ - 3 # GPIO3 for jd1.
+ description: Configures GPIO Mic Jack detection 1.
+
+ realtek,jd2-gpio:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # OFF
+ - 1 # GPIO4 for jd2.
+ - 2 # GPIO5 for jd2.
+ - 3 # GPIO6 for jd2.
+ description: Configures GPIO Mic Jack detection 2.
+
+ realtek,jd3-gpio:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # OFF
+ - 1 # GPIO4 for jd3.
+ - 2 # GPIO5 for jd3.
+ - 3 # GPIO6 for jd3.
+ description: Configures GPIO Mic Jack detection 3.
+
+patternProperties:
+ '^realtek,in[1-2]-differential$':
+ type: boolean
+ description: Indicate MIC1/2 input are differential, rather than
+ single-ended.
+
+ '^realtek,lout[1-3]-differential$':
+ type: boolean
+ description: Indicate LOUT1/2/3 outputs are differential, rather than
+ single-ended.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - gpio-controller
+ - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@2c {
+ compatible = "realtek,rt5677";
+ reg = <0x2c>;
+ interrupt-parent = <&gpio>;
+ interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ realtek,pow-ldo2-gpio = <&gpio 3 GPIO_ACTIVE_HIGH>;
+ realtek,reset-gpio = <&gpio 3 GPIO_ACTIVE_LOW>;
+ realtek,in1-differential;
+ realtek,gpio-config = <0 0 0 0 0 2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682.yaml
new file mode 100644
index 000000000000..39333ea05646
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5682.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/realtek,rt5682.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek rt5682 and rt5682i codecs
+
+maintainers:
+ - Bard Liao <bardliao@realtek.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - realtek,rt5682
+ - realtek,rt5682i
+
+ reg:
+ maxItems: 1
+ description: I2C address of the device.
+
+ interrupts:
+ maxItems: 1
+ description: The CODEC's interrupt output.
+
+ realtek,dmic1-data-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # dmic1 data is not used
+ - 1 # using GPIO2 pin as dmic1 data pin
+ - 2 # using GPIO5 pin as dmic1 data pin
+ description:
+ Specify which GPIO pin be used as DMIC1 data pin.
+
+ realtek,dmic1-clk-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # using GPIO1 pin as dmic1 clock pin
+ - 1 # using GPIO3 pin as dmic1 clock pin
+ description:
+ Specify which GPIO pin be used as DMIC1 clk pin.
+
+ realtek,jd-src:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # No JD is used
+ - 1 # using JD1 as JD source
+ description:
+ Specify which JD source be used.
+
+ realtek,ldo1-en-gpios:
+ description:
+ The GPIO that controls the CODEC's LDO1_EN pin.
+
+ realtek,btndet-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The debounce delay for push button.
+ The delay time is realtek,btndet-delay value multiple of 8.192 ms.
+ If absent, the default is 16.
+
+ realtek,dmic-clk-rate-hz:
+ description:
+ Set the clock rate (hz) for the requirement of the particular DMIC.
+
+ realtek,dmic-delay-ms:
+ description:
+ Set the delay time (ms) for the requirement of the particular DMIC.
+
+ realtek,dmic-clk-driving-high:
+ type: boolean
+ description:
+ Set the high driving of the DMIC clock out.
+
+ clocks:
+ items:
+ - description: phandle and clock specifier for codec MCLK.
+
+ clock-names:
+ items:
+ - const: mclk
+
+ "#clock-cells":
+ const: 1
+
+ clock-output-names:
+ minItems: 2
+ maxItems: 2
+ description: Name given for DAI word clock and bit clock outputs.
+
+ "#sound-dai-cells":
+ const: 1
+
+ AVDD-supply:
+ description: Regulator supplying analog power through the AVDD pin.
+
+ MICVDD-supply:
+ description: Regulator supplying power for the microphone bias through
+ the MICVDD pin.
+
+ VBAT-supply:
+ description: Regulator supplying battery power through the VBAT pin.
+
+ DBVDD-supply:
+ description: Regulator supplying I/O power through the DBVDD pin.
+
+ LDO1-IN-supply:
+ description: Regulator supplying power to the digital core and charge
+ pump through the LDO1_IN pin.
+
+required:
+ - compatible
+ - reg
+ - AVDD-supply
+ - VBAT-supply
+ - MICVDD-supply
+ - DBVDD-supply
+ - LDO1-IN-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "realtek,rt5682";
+ reg = <0x1a>;
+ interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+ realtek,ldo1-en-gpios =
+ <&gpio 2 GPIO_ACTIVE_HIGH>;
+ realtek,dmic1-data-pin = <1>;
+ realtek,dmic1-clk-pin = <1>;
+ realtek,jd-src = <1>;
+
+ #clock-cells = <1>;
+ clock-output-names = "rt5682-dai-wclk", "rt5682-dai-bclk";
+
+ clocks = <&osc>;
+ clock-names = "mclk";
+
+ AVDD-supply = <&avdd_reg>;
+ VBAT-supply = <&vbat_reg>;
+ MICVDD-supply = <&micvdd_reg>;
+ DBVDD-supply = <&dbvdd_reg>;
+ LDO1-IN-supply = <&ldo1_in_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml
index ca5b8987b749..ecfa7a576866 100644
--- a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml
+++ b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/realtek,rt5682s.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Realtek rt5682s codec devicetree bindings
+title: Realtek rt5682s codec
maintainers:
- Derek Fang <derek.fang@realtek.com>
@@ -12,6 +12,9 @@ maintainers:
description: |
Rt5682s(ALC5682I-VS) is a rt5682i variant which supports I2C only.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: realtek,rt5682s
@@ -87,11 +90,32 @@ properties:
maxItems: 2
description: Name given for DAI word clock and bit clock outputs.
-additionalProperties: false
+ "#sound-dai-cells":
+ const: 1
+
+ AVDD-supply:
+ description: Regulator supplying analog power through the AVDD pin.
+
+ MICVDD-supply:
+ description: Regulator supplying power for the microphone bias through the
+ MICVDD pin.
+
+ DBVDD-supply:
+ description: Regulator supplying I/O power through the DBVDD pin.
+
+ LDO1-IN-supply:
+ description: Regulator supplying power to the digital core and charge pump
+ through the LDO1_IN pin.
+
+unevaluatedProperties: false
required:
- compatible
- reg
+ - AVDD-supply
+ - MICVDD-supply
+ - DBVDD-supply
+ - LDO1-IN-supply
examples:
- |
@@ -117,5 +141,10 @@ examples:
clocks = <&osc>;
clock-names = "mclk";
+
+ AVDD-supply = <&avdd_reg>;
+ MICVDD-supply = <&micvdd_reg>;
+ DBVDD-supply = <&dbvdd_reg>;
+ LDO1-IN-supply = <&ldo1_in_reg>;
};
};
diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
index 0dd3f7361399..df91991699a7 100644
--- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
@@ -9,6 +9,9 @@ title: Renesas FIFO-buffered Serial Interface (FSI)
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
$nodename:
pattern: "^sound@.*"
@@ -64,7 +67,7 @@ required:
- power-domains
- '#sound-dai-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/renesas,idt821034.yaml b/Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
new file mode 100644
index 000000000000..a2b92dba5529
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/renesas,idt821034.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas IDT821034 codec device
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+description: |
+ The IDT821034 codec is a four channel PCM codec with onchip filters and
+ programmable gain setting.
+
+ The time-slots used by the codec must be set and so, the properties
+ 'dai-tdm-slot-num', 'dai-tdm-slot-width', 'dai-tdm-slot-tx-mask' and
+ 'dai-tdm-slot-rx-mask' must be present in the ALSA sound card node for
+ sub-nodes that involve the codec. The codec uses one 8bit time-slot per
+ channel.
+ 'dai-tdm-tdm-slot-with' must be set to 8.
+
+ The IDT821034 codec also supports 5 gpios (SLIC signals) per channel.
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: renesas,idt821034
+
+ reg:
+ description:
+ SPI device address.
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 8192000
+
+ spi-cpha: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ '#gpio-cells':
+ const: 2
+
+ gpio-controller: true
+
+required:
+ - compatible
+ - reg
+ - spi-cpha
+ - '#sound-dai-cells'
+ - gpio-controller
+ - '#gpio-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@0 {
+ compatible = "renesas,idt821034";
+ reg = <0>;
+ spi-max-frequency = <8192000>;
+ spi-cpha;
+ #sound-dai-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index b731f16aea84..3f07b072d995 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -94,7 +94,7 @@ see "Example: simple sound card for Asynchronous mode"
[xx]ch [yy]ch
------> [CTU] -------->
-CTU can convert [xx]ch to [yy]ch, or exchange outputed channel.
+CTU can convert [xx]ch to [yy]ch, or exchange outputted channel.
CTU conversion needs matrix settings.
For more detail information, see below
@@ -109,7 +109,7 @@ For more detail information, see below
- Register Description
- CTUn Scale Value exx Register (CTUn_SVxxR)
- ${LINUX}/sound/soc/sh/rcar/ctu.c
+ ${LINUX}/sound/soc/renesas/rcar/ctu.c
- comment of header
You need to use "simple-scu-audio-card" or "audio-graph-scu-card" for it.
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
index 268895c90bd5..e8a2acb92646 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/renesas,rsnd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas R-Car Sound Driver Device Tree Bindings
+title: Renesas R-Car Sound Driver
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
@@ -18,8 +18,7 @@ properties:
- enum:
- renesas,rcar_sound-r8a7778 # R-Car M1A
- renesas,rcar_sound-r8a7779 # R-Car H1
- - enum:
- - renesas,rcar_sound-gen1
+ - const: renesas,rcar_sound-gen1
# for Gen2 SoC
- items:
- enum:
@@ -32,8 +31,7 @@ properties:
- renesas,rcar_sound-r8a7791 # R-Car M2-W
- renesas,rcar_sound-r8a7793 # R-Car M2-N
- renesas,rcar_sound-r8a7794 # R-Car E2
- - enum:
- - renesas,rcar_sound-gen2
+ - const: renesas,rcar_sound-gen2
# for Gen3 SoC
- items:
- enum:
@@ -47,14 +45,19 @@ properties:
- renesas,rcar_sound-r8a77965 # R-Car M3-N
- renesas,rcar_sound-r8a77990 # R-Car E3
- renesas,rcar_sound-r8a77995 # R-Car D3
- - enum:
- - renesas,rcar_sound-gen3
- # for Generic
+ - const: renesas,rcar_sound-gen3
+ # for Gen4 SoC
- items:
- enum:
- - renesas,rcar_sound-gen1
- - renesas,rcar_sound-gen2
- - renesas,rcar_sound-gen3
+ - renesas,rcar_sound-r8a779g0 # R-Car V4H
+ - renesas,rcar_sound-r8a779h0 # R-Car V4M
+ - const: renesas,rcar_sound-gen4
+ # for Generic
+ - enum:
+ - renesas,rcar_sound-gen1
+ - renesas,rcar_sound-gen2
+ - renesas,rcar_sound-gen3
+ - renesas,rcar_sound-gen4
reg:
minItems: 1
@@ -68,6 +71,7 @@ properties:
description: |
it must be 0 if your system is using single DAI
it must be 1 if your system is using multi DAIs
+ This is used on simple-audio-card
enum: [0, 1]
"#clock-cells":
@@ -76,6 +80,12 @@ properties:
it must be 1 if your system has audio_clkout0/1/2/3
enum: [0, 1]
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
clock-frequency:
description: for audio_clkout0/1/2/3
@@ -100,28 +110,21 @@ properties:
clock-names:
description: List of necessary clock names.
- minItems: 1
- maxItems: 31
- items:
- oneOf:
- - const: ssi-all
- - pattern: '^ssi\.[0-9]$'
- - pattern: '^src\.[0-9]$'
- - pattern: '^mix\.[0-1]$'
- - pattern: '^ctu\.[0-1]$'
- - pattern: '^dvc\.[0-1]$'
- - pattern: '^clk_(a|b|c|i)$'
-
- ports:
- $ref: /schemas/graph.yaml#/properties/ports
- patternProperties:
- port(@[0-9a-f]+)?:
- $ref: audio-graph-port.yaml#
- unevaluatedProperties: false
+ # details are defined below
+ # ports is below
port:
- $ref: audio-graph-port.yaml#
+ $ref: audio-graph-port.yaml#/definitions/port-base
unevaluatedProperties: false
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?":
+ $ref: audio-graph-port.yaml#/definitions/endpoint-base
+ properties:
+ playback:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ capture:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ unevaluatedProperties: false
rcar_sound,dvc:
description: DVC subnode.
@@ -135,7 +138,7 @@ properties:
dmas:
maxItems: 1
dma-names:
- const: "tx"
+ const: tx
required:
- dmas
- dma-names
@@ -178,10 +181,6 @@ properties:
enum:
- tx
- rx
- required:
- - interrupts
- - dmas
- - dma-names
additionalProperties: false
rcar_sound,ssiu:
@@ -240,12 +239,11 @@ properties:
$ref: /schemas/types.yaml#/definitions/flag
required:
- interrupts
- - dmas
- - dma-names
additionalProperties: false
+patternProperties:
# For DAI base
- rcar_sound,dai:
+ 'rcar_sound,dai(@[0-9a-f]+)?$':
description: DAI subnode.
type: object
patternProperties:
@@ -265,15 +263,27 @@ properties:
- capture
additionalProperties: false
+ 'ports(@[0-9a-f]+)?$':
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ unevaluatedProperties: false
+ patternProperties:
+ '^port(@[0-9a-f]+)?$':
+ $ref: "#/properties/port"
+
required:
- compatible
- reg
- reg-names
- clocks
- clock-names
- - "#sound-dai-cells"
allOf:
+ - $ref: dai-common.yaml#
+
+ # --------------------
+ # reg/reg-names
+ # --------------------
+ # for Gen1
- if:
properties:
compatible:
@@ -284,18 +294,24 @@ allOf:
reg:
maxItems: 3
reg-names:
- maxItems: 3
items:
enum:
- - scu
+ - sru
- ssi
- adg
- else:
+ # for Gen2/Gen3
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rcar_sound-gen2
+ - renesas,rcar_sound-gen3
+ then:
properties:
reg:
- maxItems: 5
+ minItems: 5
reg-names:
- maxItems: 5
items:
enum:
- scu
@@ -303,35 +319,87 @@ allOf:
- ssiu
- ssi
- audmapp
+ # for Gen4
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rcar_sound-gen4
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ reg-names:
+ items:
+ enum:
+ - adg
+ - ssiu
+ - ssi
+ - sdmc
+
+ # --------------------
+ # clock-names
+ # --------------------
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rcar_sound-gen4
+ then:
+ properties:
+ clock-names:
+ maxItems: 3
+ items:
+ enum:
+ - ssi.0
+ - ssiu.0
+ - clkin
+ else:
+ properties:
+ clock-names:
+ minItems: 1
+ maxItems: 31
+ items:
+ oneOf:
+ - const: ssi-all
+ - pattern: '^ssi\.[0-9]$'
+ - pattern: '^src\.[0-9]$'
+ - pattern: '^mix\.[0-1]$'
+ - pattern: '^ctu\.[0-1]$'
+ - pattern: '^dvc\.[0-1]$'
+ - pattern: '^clk_(a|b|c|i)$'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/r8a7790-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a7790-sysc.h>
rcar_sound: sound@ec500000 {
#sound-dai-cells = <1>;
compatible = "renesas,rcar_sound-r8a7790", "renesas,rcar_sound-gen2";
reg = <0xec500000 0x1000>, /* SCU */
<0xec5a0000 0x100>, /* ADG */
<0xec540000 0x1000>, /* SSIU */
- <0xec541000 0x1280>, /* SSI */
+ <0xec541000 0x280>, /* SSI */
<0xec740000 0x200>; /* Audio DMAC peri peri*/
reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
- clocks = <&mstp10_clks 1005>, /* SSI-ALL */
- <&mstp10_clks 1006>, <&mstp10_clks 1007>, /* SSI9, SSI8 */
- <&mstp10_clks 1008>, <&mstp10_clks 1009>, /* SSI7, SSI6 */
- <&mstp10_clks 1010>, <&mstp10_clks 1011>, /* SSI5, SSI4 */
- <&mstp10_clks 1012>, <&mstp10_clks 1013>, /* SSI3, SSI2 */
- <&mstp10_clks 1014>, <&mstp10_clks 1015>, /* SSI1, SSI0 */
- <&mstp10_clks 1022>, <&mstp10_clks 1023>, /* SRC9, SRC8 */
- <&mstp10_clks 1024>, <&mstp10_clks 1025>, /* SRC7, SRC6 */
- <&mstp10_clks 1026>, <&mstp10_clks 1027>, /* SRC5, SRC4 */
- <&mstp10_clks 1028>, <&mstp10_clks 1029>, /* SRC3, SRC2 */
- <&mstp10_clks 1030>, <&mstp10_clks 1031>, /* SRC1, SRC0 */
- <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* MIX1, MIX0 */
- <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* CTU1, CTU0 */
- <&mstp10_clks 1019>, <&mstp10_clks 1018>, /* DVC0, DVC1 */
+ clocks = <&cpg CPG_MOD 1005>, /* SSI-ALL */
+ <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>, /* SSI9, SSI8 */
+ <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>, /* SSI7, SSI6 */
+ <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>, /* SSI5, SSI4 */
+ <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>, /* SSI3, SSI2 */
+ <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>, /* SSI1, SSI0 */
+ <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>, /* SRC9, SRC8 */
+ <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>, /* SRC7, SRC6 */
+ <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>, /* SRC5, SRC4 */
+ <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>, /* SRC3, SRC2 */
+ <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>, /* SRC1, SRC0 */
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>, /* MIX1, MIX0 */
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>, /* CTU1, CTU0 */
+ <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>, /* DVC0, DVC1 */
<&audio_clk_a>, <&audio_clk_b>, /* CLKA, CLKB */
<&audio_clk_c>, <&audio_clk_i>; /* CLKC, CLKI */
@@ -352,6 +420,17 @@ examples:
"clk_a", "clk_b",
"clk_c", "clk_i";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+
+ resets = <&cpg 1005>,
+ <&cpg 1006>, <&cpg 1007>, <&cpg 1008>, <&cpg 1009>,
+ <&cpg 1010>, <&cpg 1011>, <&cpg 1012>, <&cpg 1013>,
+ <&cpg 1014>, <&cpg 1015>;
+ reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6",
+ "ssi.5", "ssi.4", "ssi.3", "ssi.2",
+ "ssi.1", "ssi.0";
+
rcar_sound,dvc {
dvc0: dvc-0 {
dmas = <&audma0 0xbc>;
@@ -384,7 +463,7 @@ examples:
status = "disabled";
};
src1: src-1 {
- interrupts = <0 353 0>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x87>, <&audma1 0x9c>;
dma-names = "rx", "tx";
};
@@ -405,12 +484,12 @@ examples:
rcar_sound,ssi {
ssi0: ssi-0 {
- interrupts = <0 370 1>;
+ interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x01>, <&audma1 0x02>;
dma-names = "rx", "tx";
};
ssi1: ssi-1 {
- interrupts = <0 371 1>;
+ interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&audma0 0x03>, <&audma1 0x04>;
dma-names = "rx", "tx";
};
@@ -421,19 +500,19 @@ examples:
rcar_sound,dai {
dai0 {
playback = <&ssi5>, <&src5>;
- capture = <&ssi6>;
+ capture = <&ssi6>;
};
dai1 {
playback = <&ssi3>;
};
dai2 {
- capture = <&ssi4>;
+ capture = <&ssi4>;
};
dai3 {
playback = <&ssi7>;
};
dai4 {
- capture = <&ssi8>;
+ capture = <&ssi8>;
};
};
@@ -447,12 +526,11 @@ examples:
frame-master = <&rsnd_endpoint0>;
playback = <&ssi0>, <&src0>, <&dvc0>;
- capture = <&ssi1>, <&src1>, <&dvc1>;
+ capture = <&ssi1>, <&src1>, <&dvc1>;
};
};
};
-
/* assume audio-graph */
codec {
port {
diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml
index 0d9840375132..e4cdbf2202b9 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml
@@ -9,27 +9,35 @@ title: Renesas RZ/{G2L,V2L} ASoC Sound Serial Interface (SSIF-2)
maintainers:
- Biju Das <biju.das.jz@bp.renesas.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
items:
- enum:
- - renesas,r9a07g043-ssi # RZ/G2UL
+ - renesas,r9a07g043-ssi # RZ/G2UL and RZ/Five
- renesas,r9a07g044-ssi # RZ/G2{L,LC}
- renesas,r9a07g054-ssi # RZ/V2L
+ - renesas,r9a08g045-ssi # RZ/G3S
- const: renesas,rz-ssi
reg:
maxItems: 1
interrupts:
- maxItems: 4
+ minItems: 2
+ maxItems: 3
interrupt-names:
- items:
- - const: int_req
- - const: dma_rx
- - const: dma_tx
- - const: dma_rt
+ oneOf:
+ - items:
+ - const: int_req
+ - const: dma_rx
+ - const: dma_tx
+ - items:
+ - const: int_req
+ - const: dma_rt
clocks:
maxItems: 4
@@ -50,24 +58,6 @@ properties:
dmas:
minItems: 1
maxItems: 2
- description:
- The first cell represents a phandle to dmac.
- The second cell specifies the encoded MID/RID values of the SSI port
- connected to the DMA client and the slave channel configuration
- parameters.
- bits[0:9] - Specifies MID/RID value of a SSI channel as below
- MID/RID value of SSI rx0 = 0x256
- MID/RID value of SSI tx0 = 0x255
- MID/RID value of SSI rx1 = 0x25a
- MID/RID value of SSI tx1 = 0x259
- MID/RID value of SSI rt2 = 0x25f
- MID/RID value of SSI rx3 = 0x262
- MID/RID value of SSI tx3 = 0x261
- bit[10] - HIEN = 1, Detects a request in response to the rising edge
- of the signal
- bit[11] - LVL = 0, Detects based on the edge
- bits[12:14] - AM = 2, Bus cycle mode
- bit[15] - TM = 0, Single transfer mode
dma-names:
oneOf:
@@ -80,6 +70,10 @@ properties:
'#sound-dai-cells':
const: 0
+ port:
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ description: Connection to controller providing I2S signals
+
required:
- compatible
- reg
@@ -90,7 +84,7 @@ required:
- resets
- '#sound-dai-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -103,9 +97,8 @@ examples:
reg = <0x10049c00 0x400>;
interrupts = <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 327 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 328 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 329 IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "int_req", "dma_rx", "dma_tx", "dma_rt";
+ <GIC_SPI 328 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "int_req", "dma_rx", "dma_tx";
clocks = <&cpg CPG_MOD R9A07G044_SSI0_PCLK2>,
<&cpg CPG_MOD R9A07G044_SSI0_PCLK_SFR>,
<&audio_clk1>,
diff --git a/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml b/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml
index 5655ca568240..a1242e8e0687 100644
--- a/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml
+++ b/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml
@@ -16,6 +16,9 @@ description: |
applications like as TV, monitors. home entertainment, electronic music
equipment.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -42,7 +45,7 @@ required:
- dvdd-supply
- '#sound-dai-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/richtek,rt9123.yaml b/Documentation/devicetree/bindings/sound/richtek,rt9123.yaml
new file mode 100644
index 000000000000..819ca06203b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/richtek,rt9123.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/richtek,rt9123.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9123/RTQ9124 Audio Amplifier
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description:
+ RT9123 is a 3.2W mono Class-D audio amplifier that features high efficiency
+ and performance with ultra-low quiescent current. The digital audio interface
+ support various formats, including I2S, left-justified, right-justified, and
+ TDM formats.
+
+ RTQ9124 is an ultra-low output noise, digital input, mono-channel Class-D
+ power amplifier that supports a 2.1MHz switching frequency. It integrates
+ both DC and AC load diagnostics, as well as real-time load monitoring to
+ assess speaker condition. The device operates from 4.5V to 18V and delivers
+ up to 30W output power.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt9123
+ - richtek,rtq9124
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ amplifier@5e {
+ compatible = "richtek,rt9123";
+ reg = <0x5e>;
+ enable-gpios = <&gpio 26 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/richtek,rt9123p.yaml b/Documentation/devicetree/bindings/sound/richtek,rt9123p.yaml
new file mode 100644
index 000000000000..693511dfdda4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/richtek,rt9123p.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/richtek,rt9123p.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9123P Audio Amplifier
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description:
+ RT9123P is a RT9123 variant which does not support I2C control.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt9123p
+
+ '#sound-dai-cells':
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+
+ enable-delay-ms:
+ description:
+ Delay time for 'ENABLE' pin changes intended to make I2S clocks ready to
+ prevent speaker pop noise. The unit is in millisecond.
+
+required:
+ - compatible
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ amplifier {
+ compatible = "richtek,rt9123p";
+ enable-gpios = <&gpio 26 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/richtek,rtq9128.yaml b/Documentation/devicetree/bindings/sound/richtek,rtq9128.yaml
new file mode 100644
index 000000000000..d54686a19ab7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/richtek,rtq9128.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/richtek,rtq9128.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RTQ9128 Automative Audio Power Amplifier
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description:
+ The RTQ9128 is a ultra-low output noise, high-efficiency, four-channel
+ class-D audio power amplifier and delivering 4x75W into 4OHm at 10%
+ THD+N from a 25V supply in automotive applications.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - richtek,rtq9128
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+
+ richtek,tdm-input-data2-select:
+ type: boolean
+ description:
+ By default, if TDM mode is used, TDM data input will select 'DATA1' pin
+ as the data source. This option will configure TDM data input source from
+ 'DATA1' to 'DATA2' pin.
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ speaker@1a {
+ compatible = "richtek,rtq9128";
+ reg = <0x1a>;
+ enable-gpios = <&gpio 26 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
index 6a7c004bef17..9435f395403a 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml
@@ -14,6 +14,9 @@ description:
maintainers:
- Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -21,6 +24,7 @@ properties:
- rockchip,rk1808-i2s-tdm
- rockchip,rk3308-i2s-tdm
- rockchip,rk3568-i2s-tdm
+ - rockchip,rk3588-i2s-tdm
- rockchip,rv1126-i2s-tdm
reg:
@@ -82,6 +86,13 @@ properties:
- tx-m
- rx-m
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ power-domains:
+ maxItems: 1
+
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -124,7 +135,6 @@ properties:
the direction (input/output) needs to be dynamically adjusted.
type: boolean
-
required:
- compatible
- reg
@@ -135,10 +145,9 @@ required:
- clock-names
- resets
- reset-names
- - rockchip,grf
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml
index 22e1cf6c0592..ff9e400494f3 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip,pdm.yaml
@@ -16,6 +16,9 @@ description:
maintainers:
- Heiko Stuebner <heiko@sntech.de>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -83,7 +86,7 @@ required:
- dma-names
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3036-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3036-codec.yaml
new file mode 100644
index 000000000000..7570cc1375ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3036-codec.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3036-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3036 internal codec
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: rockchip,rk3036-codec
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock for audio codec
+
+ clock-names:
+ items:
+ - const: acodec_pclk
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle of the syscon node for the GRF register.
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - rockchip,grf
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3036-cru.h>
+ acodec: audio-codec@20030000 {
+ compatible = "rockchip,rk3036-codec";
+ reg = <0x20030000 0x4000>;
+ rockchip,grf = <&grf>;
+ clock-names = "acodec_pclk";
+ clocks = <&cru ACLK_VCODEC>;
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt
index e5430d1d34e4..73577ac1b89c 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt
@@ -12,7 +12,7 @@ Required properties:
source. For this driver the first string should always be
"Analog".
-Optionnal properties:
+Optional properties:
- rockchip,hp-en-gpios = The phandle of the GPIO that power up/down the
headphone (when the analog output is an headphone).
- rockchip,hp-det-gpios = The phandle of the GPIO that detects the headphone
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
new file mode 100644
index 000000000000..2cf229a076f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3308-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3308 Internal Codec
+
+description: |
+ This is the audio codec embedded in the Rockchip RK3308
+ SoC. It has 8 24-bit ADCs and 2 24-bit DACs. The maximum supported
+ sampling rate is 192 kHz.
+
+ It is connected internally to one out of a selection of the internal I2S
+ controllers.
+
+ The RK3308 audio codec has 8 independent capture channels, but some
+ features work on stereo pairs called groups:
+ * grp 0 -- MIC1 / MIC2
+ * grp 1 -- MIC3 / MIC4
+ * grp 2 -- MIC5 / MIC6
+ * grp 3 -- MIC7 / MIC8
+
+maintainers:
+ - Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+properties:
+ compatible:
+ const: rockchip,rk3308-codec
+
+ reg:
+ maxItems: 1
+
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the General Register Files (GRF)
+
+ clocks:
+ items:
+ - description: clock for TX
+ - description: clock for RX
+ - description: AHB clock driving the interface
+
+ clock-names:
+ items:
+ - const: mclk_tx
+ - const: mclk_rx
+ - const: hclk
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: codec
+
+ "#sound-dai-cells":
+ const: 0
+
+ rockchip,micbias-avdd-percent:
+ description: |
+ Voltage setting for the MICBIAS pins expressed as a percentage of
+ AVDD.
+
+ E.g. if rockchip,micbias-avdd-percent = 85 and AVDD = 3v3, then the
+ MIC BIAS voltage will be 3.3 V * 85% = 2.805 V.
+
+ enum: [ 50, 55, 60, 65, 70, 75, 80, 85 ]
+
+required:
+ - compatible
+ - reg
+ - rockchip,grf
+ - clocks
+ - resets
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3308-cru.h>
+
+ audio_codec: audio-codec@ff560000 {
+ compatible = "rockchip,rk3308-codec";
+ reg = <0xff560000 0x10000>;
+ rockchip,grf = <&grf>;
+ clock-names = "mclk_tx", "mclk_rx", "hclk";
+ clocks = <&cru SCLK_I2S2_8CH_TX_OUT>,
+ <&cru SCLK_I2S2_8CH_RX_OUT>,
+ <&cru PCLK_ACODEC>;
+ reset-names = "codec";
+ resets = <&cru SRST_ACODEC_P>;
+ #sound-dai-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml
index 75b3b33b5f1f..52e3f1f900c4 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml
@@ -9,6 +9,9 @@ title: Rockchip rk3328 internal codec
maintainers:
- Heiko Stuebner <heiko@sntech.de>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: rockchip,rk3328-codec
@@ -53,7 +56,7 @@ required:
- rockchip,grf
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3576-sai.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3576-sai.yaml
new file mode 100644
index 000000000000..149da9a91451
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3576-sai.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3576-sai.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Serial Audio Interface Controller
+
+description:
+ The Rockchip Serial Audio Interface (SAI) controller is a flexible audio
+ controller that implements the I2S, I2S/TDM and the PDM standards.
+
+maintainers:
+ - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: rockchip,rk3576-sai
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ minItems: 1
+ maxItems: 2
+
+ dma-names:
+ minItems: 1
+ items:
+ - enum: [tx, rx]
+ - const: rx
+
+ clocks:
+ items:
+ - description: master audio clock
+ - description: AHB clock driving the interface
+
+ clock-names:
+ items:
+ - const: mclk
+ - const: hclk
+
+ resets:
+ minItems: 1
+ items:
+ - description: reset for the mclk domain
+ - description: reset for the hclk domain
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: m
+ - const: h
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ power-domains:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ rockchip,sai-rx-route:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Defines the mapping of the controller's SDI ports to actual input lanes,
+ as well as the number of input lanes.
+ rockchip,sai-rx-route = <3> would mean sdi3 is receiving from data0, and
+ that there is only one receiving lane.
+ This property's absence is to be understood as only one receiving lane
+ being used if the controller has capture capabilities.
+ maxItems: 4
+ items:
+ minimum: 0
+ maximum: 3
+
+ rockchip,sai-tx-route:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Defines the mapping of the controller's SDO ports to actual output lanes,
+ as well as the number of output lanes.
+ rockchip,sai-tx-route = <3> would mean sdo3 is sending to data0, and
+ that there is only one transmitting lane.
+ This property's absence is to be understood as only one transmitting lane
+ being used if the controller has playback capabilities.
+ maxItems: 4
+ items:
+ minimum: 0
+ maximum: 3
+
+required:
+ - compatible
+ - reg
+ - dmas
+ - dma-names
+ - clocks
+ - clock-names
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3576-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/power/rockchip,rk3576-power.h>
+ #include <dt-bindings/reset/rockchip,rk3576-cru.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ sai1: sai@2a610000 {
+ compatible = "rockchip,rk3576-sai";
+ reg = <0x0 0x2a610000 0x0 0x1000>;
+ interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru MCLK_SAI1_8CH>, <&cru HCLK_SAI1_8CH>;
+ clock-names = "mclk", "hclk";
+ dmas = <&dmac0 2>, <&dmac0 3>;
+ dma-names = "tx", "rx";
+ power-domains = <&power RK3576_PD_AUDIO>;
+ resets = <&cru SRST_M_SAI1_8CH>, <&cru SRST_H_SAI1_8CH>;
+ reset-names = "m", "h";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sai1m0_lrck
+ &sai1m0_sclk
+ &sai1m0_sdi0
+ &sai1m0_sdo0
+ &sai1m0_sdo1
+ &sai1m0_sdo2
+ &sai1m0_sdo3>;
+ rockchip,sai-tx-route = <3 1 2 0>;
+ #sound-dai-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
index 7e36e389e976..fcb01abffa97 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml
@@ -13,6 +13,9 @@ description:
maintainers:
- Heiko Stuebner <heiko@sntech.de>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
oneOf:
@@ -31,6 +34,7 @@ properties:
- rockchip,rk3366-i2s
- rockchip,rk3368-i2s
- rockchip,rk3399-i2s
+ - rockchip,rk3588-i2s
- rockchip,rv1126-i2s
- const: rockchip,rk3066-i2s
@@ -79,6 +83,10 @@ properties:
resets:
maxItems: 2
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
rockchip,capture-channels:
$ref: /schemas/types.yaml#/definitions/uint32
default: 2
@@ -111,7 +119,7 @@ required:
- dma-names
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
index d0a24bf928d6..32dea7392e8d 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
@@ -26,10 +26,15 @@ properties:
- const: rockchip,rk3568-spdif
- items:
- enum:
+ - rockchip,rk3128-spdif
- rockchip,rk3188-spdif
- rockchip,rk3288-spdif
- rockchip,rk3308-spdif
- const: rockchip,rk3066-spdif
+ - items:
+ - enum:
+ - rockchip,rk3588-spdif
+ - const: rockchip,rk3568-spdif
reg:
maxItems: 1
@@ -75,17 +80,18 @@ required:
- dma-names
- "#sound-dai-cells"
-if:
- properties:
- compatible:
- contains:
- const: rockchip,rk3288-spdif
-
-then:
- required:
- - rockchip,grf
-
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3288-spdif
+ then:
+ required:
+ - rockchip,grf
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml b/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml
index 859ce64da152..5abcf92bc484 100644
--- a/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml
+++ b/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml
@@ -14,6 +14,9 @@ description:
maintainers:
- Katsuhiro Suzuki <katsuhiro@katsuster.net>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: rohm,bd28623
@@ -50,7 +53,7 @@ required:
- VCCP2-supply
- "#sound-dai-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/rt1015.txt b/Documentation/devicetree/bindings/sound/rt1015.txt
deleted file mode 100644
index e498966d436f..000000000000
--- a/Documentation/devicetree/bindings/sound/rt1015.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-RT1015 Mono Class D Audio Amplifier
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "realtek,rt1015".
-
-- reg : The I2C address of the device.
-
-Optional properties:
-
-- realtek,power-up-delay-ms
- Set a delay time for flush work to be completed,
- this value is adjustable depending on platform.
-
-Example:
-
-rt1015: codec@28 {
- compatible = "realtek,rt1015";
- reg = <0x28>;
- realtek,power-up-delay-ms = <50>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt1016.txt b/Documentation/devicetree/bindings/sound/rt1016.txt
deleted file mode 100644
index 2310f8ff259b..000000000000
--- a/Documentation/devicetree/bindings/sound/rt1016.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-RT1016 Stereo Class D Audio Amplifier
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "realtek,rt1016".
-
-- reg : The I2C address of the device.
-
-
-Example:
-
-rt1016: codec@1a {
- compatible = "realtek,rt1016";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt1019.yaml b/Documentation/devicetree/bindings/sound/rt1019.yaml
deleted file mode 100644
index 3d5a91a942f4..000000000000
--- a/Documentation/devicetree/bindings/sound/rt1019.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/rt1019.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: RT1019 Mono Class-D Audio Amplifier
-
-maintainers:
- - jack.yu@realtek.com
-
-properties:
- compatible:
- const: realtek,rt1019
-
- reg:
- maxItems: 1
- description: I2C address of the device.
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
- rt1019: codec@28 {
- compatible = "realtek,rt1019";
- reg = <0x28>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/rt5514.txt b/Documentation/devicetree/bindings/sound/rt5514.txt
deleted file mode 100644
index d2cc171f22f2..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5514.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-RT5514 audio CODEC
-
-This device supports both I2C and SPI.
-
-Required properties:
-
-- compatible : "realtek,rt5514".
-
-- reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-- clock-names: Should be "mclk"
-
-- interrupts: The interrupt number to the cpu. The interrupt specifier format
- depends on the interrupt controller.
-
-- realtek,dmic-init-delay-ms
- Set the DMIC initial delay (ms) to wait it ready for I2C.
-
-Pins on the device (for linking into audio routes) for I2C:
-
- * DMIC1L
- * DMIC1R
- * DMIC2L
- * DMIC2R
- * AMICL
- * AMICR
-
-Example:
-
-rt5514: codec@57 {
- compatible = "realtek,rt5514";
- reg = <0x57>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt b/Documentation/devicetree/bindings/sound/rt5616.txt
deleted file mode 100644
index 540a4bf252e4..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5616.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-RT5616 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "realtek,rt5616".
-
-- reg : The I2C address of the device.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC.
-
-- clock-names: Should be "mclk".
-
-Pins on the device (for linking into audio routes) for RT5616:
-
- * IN1P
- * IN2P
- * IN2N
- * LOUTL
- * LOUTR
- * HPOL
- * HPOR
-
-Example:
-
-rt5616: codec@1b {
- compatible = "realtek,rt5616";
- reg = <0x1b>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5631.txt b/Documentation/devicetree/bindings/sound/rt5631.txt
deleted file mode 100644
index 56bc85232c49..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5631.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-ALC5631/RT5631 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "realtek,alc5631" or "realtek,rt5631"
-
- - reg : the I2C address of the device.
-
-Pins on the device (for linking into audio routes):
-
- * SPK_OUT_R_P
- * SPK_OUT_R_N
- * SPK_OUT_L_P
- * SPK_OUT_L_N
- * HP_OUT_L
- * HP_OUT_R
- * AUX_OUT2_LP
- * AUX_OUT2_RN
- * AUX_OUT1_LP
- * AUX_OUT1_RN
- * AUX_IN_L_JD
- * AUX_IN_R_JD
- * MONO_IN_P
- * MONO_IN_N
- * MIC1_P
- * MIC1_N
- * MIC2_P
- * MIC2_N
- * MONO_OUT_P
- * MONO_OUT_N
- * MICBIAS1
- * MICBIAS2
-
-Example:
-
-alc5631: audio-codec@1a {
- compatible = "realtek,alc5631";
- reg = <0x1a>;
-};
-
-or
-
-rt5631: audio-codec@1a {
- compatible = "realtek,rt5631";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt
deleted file mode 100644
index ff1228713f7e..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5640.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-RT5640/RT5639 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : One of "realtek,rt5640" or "realtek,rt5639".
-
-- reg : The I2C address of the device.
-
-- interrupts : The CODEC's interrupt output.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-- clock-names: Should be "mclk"
-
-- realtek,in1-differential
-- realtek,in2-differential
-- realtek,in3-differential
- Boolean. Indicate MIC1/2/3 input are differential, rather than single-ended.
-
-- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
-
-- realtek,dmic1-data-pin
- 0: dmic1 is not used
- 1: using IN1P pin as dmic1 data pin
- 2: using GPIO3 pin as dmic1 data pin
-
-- realtek,dmic2-data-pin
- 0: dmic2 is not used
- 1: using IN1N pin as dmic2 data pin
- 2: using GPIO4 pin as dmic2 data pin
-
-- realtek,jack-detect-source
- u32. Valid values:
- 0: jack-detect is not used
- 1: Use GPIO1 for jack-detect
- 2: Use JD1_IN4P for jack-detect
- 3: Use JD2_IN4N for jack-detect
- 4: Use GPIO2 for jack-detect
- 5: Use GPIO3 for jack-detect
- 6: Use GPIO4 for jack-detect
-
-- realtek,jack-detect-not-inverted
- bool. Normal jack-detect switches give an inverted signal, set this bool
- in the rare case you've a jack-detect switch which is not inverted.
-
-- realtek,over-current-threshold-microamp
- u32, micbias over-current detection threshold in µA, valid values are
- 600, 1500 and 2000µA.
-
-- realtek,over-current-scale-factor
- u32, micbias over-current detection scale-factor, valid values are:
- 0: Scale current by 0.5
- 1: Scale current by 0.75
- 2: Scale current by 1.0
- 3: Scale current by 1.5
-
-Pins on the device (for linking into audio routes) for RT5639/RT5640:
-
- * DMIC1
- * DMIC2
- * MICBIAS1
- * IN1P
- * IN1N
- * IN2P
- * IN2N
- * IN3P
- * IN3N
- * HPOL
- * HPOR
- * LOUTL
- * LOUTR
- * SPOLP
- * SPOLN
- * SPORP
- * SPORN
-
-Additional pins on the device for RT5640:
-
- * MONOP
- * MONON
-
-Example:
-
-rt5640 {
- compatible = "realtek,rt5640";
- reg = <0x1c>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
- realtek,ldo1-en-gpios =
- <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5645.txt b/Documentation/devicetree/bindings/sound/rt5645.txt
deleted file mode 100644
index 41a62fd2ae1f..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5645.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-RT5650/RT5645 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : One of "realtek,rt5645" or "realtek,rt5650".
-
-- reg : The I2C address of the device.
-
-- interrupts : The CODEC's interrupt output.
-
-- avdd-supply: Power supply for AVDD, providing 1.8V.
-
-- cpvdd-supply: Power supply for CPVDD, providing 3.5V.
-
-Optional properties:
-
-- hp-detect-gpios:
- a GPIO spec for the external headphone detect pin. If jd-mode = 0,
- we will get the JD status by getting the value of hp-detect-gpios.
-
-- realtek,in2-differential
- Boolean. Indicate MIC2 input are differential, rather than single-ended.
-
-- realtek,dmic1-data-pin
- 0: dmic1 is not used
- 1: using IN2P pin as dmic1 data pin
- 2: using GPIO6 pin as dmic1 data pin
- 3: using GPIO10 pin as dmic1 data pin
- 4: using GPIO12 pin as dmic1 data pin
-
-- realtek,dmic2-data-pin
- 0: dmic2 is not used
- 1: using IN2N pin as dmic2 data pin
- 2: using GPIO5 pin as dmic2 data pin
- 3: using GPIO11 pin as dmic2 data pin
-
--- realtek,jd-mode : The JD mode of rt5645/rt5650
- 0 : rt5645/rt5650 JD function is not used
- 1 : Mode-0 (VDD=3.3V), two port jack detection
- 2 : Mode-1 (VDD=3.3V), one port jack detection
- 3 : Mode-2 (VDD=1.8V), one port jack detection
-
-Pins on the device (for linking into audio routes) for RT5645/RT5650:
-
- * DMIC L1
- * DMIC R1
- * DMIC L2
- * DMIC R2
- * IN1P
- * IN1N
- * IN2P
- * IN2N
- * Haptic Generator
- * HPOL
- * HPOR
- * LOUTL
- * LOUTR
- * PDM1L
- * PDM1R
- * SPOL
- * SPOR
-
-Example:
-
-codec: rt5650@1a {
- compatible = "realtek,rt5650";
- reg = <0x1a>;
- hp-detect-gpios = <&gpio 19 0>;
- interrupt-parent = <&gpio>;
- interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
- realtek,dmic-en = "true";
- realtek,en-jd-func = "true";
- realtek,jd-mode = <3>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5659.txt b/Documentation/devicetree/bindings/sound/rt5659.txt
deleted file mode 100644
index 013f534fa059..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5659.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-RT5659/RT5658 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : One of "realtek,rt5659" or "realtek,rt5658".
-
-- reg : The I2C address of the device.
-
-- interrupts : The CODEC's interrupt output.
-
-Optional properties:
-
-- clocks: The phandle of the master clock to the CODEC
-- clock-names: Should be "mclk"
-
-- realtek,in1-differential
-- realtek,in3-differential
-- realtek,in4-differential
- Boolean. Indicate MIC1/3/4 input are differential, rather than single-ended.
-
-- realtek,dmic1-data-pin
- 0: dmic1 is not used
- 1: using IN2N pin as dmic1 data pin
- 2: using GPIO5 pin as dmic1 data pin
- 3: using GPIO9 pin as dmic1 data pin
- 4: using GPIO11 pin as dmic1 data pin
-
-- realtek,dmic2-data-pin
- 0: dmic2 is not used
- 1: using IN2P pin as dmic2 data pin
- 2: using GPIO6 pin as dmic2 data pin
- 3: using GPIO10 pin as dmic2 data pin
- 4: using GPIO12 pin as dmic2 data pin
-
-- realtek,jd-src
- 0: No JD is used
- 1: using JD3 as JD source
- 2: JD source for Intel HDA header
-
-- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
-- realtek,reset-gpios : The GPIO that controls the CODEC's RESET pin.
-
-- sound-name-prefix: Please refer to name-prefix.yaml
-
-- ports: A Codec may have a single or multiple I2S interfaces. These
- interfaces on Codec side can be described under 'ports' or 'port'.
- When the SoC or host device is connected to multiple interfaces of
- the Codec, the connectivity can be described using 'ports' property.
- If a single interface is used, then 'port' can be used. The usage
- depends on the platform or board design.
- Please refer to Documentation/devicetree/bindings/graph.txt
-
-Pins on the device (for linking into audio routes) for RT5659/RT5658:
-
- * DMIC L1
- * DMIC R1
- * DMIC L2
- * DMIC R2
- * IN1P
- * IN1N
- * IN2P
- * IN2N
- * IN3P
- * IN3N
- * IN4P
- * IN4N
- * HPOL
- * HPOR
- * SPOL
- * SPOR
- * LOUTL
- * LOUTR
- * MONOOUT
- * PDML
- * PDMR
- * SPDIF
-
-Example:
-
-rt5659 {
- compatible = "realtek,rt5659";
- reg = <0x1b>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
- realtek,ldo1-en-gpios =
- <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5663.txt b/Documentation/devicetree/bindings/sound/rt5663.txt
index 2a55e9133408..24a6dab28f25 100644
--- a/Documentation/devicetree/bindings/sound/rt5663.txt
+++ b/Documentation/devicetree/bindings/sound/rt5663.txt
@@ -28,7 +28,7 @@ Optional properties:
If the value is 0, it means the impedance sensing is not supported.
- "realtek,impedance_sensing_table"
The matrix rows of the impedance sensing table are consisted by impedance
- minimum, impedance maximun, volume, DC offset w/o and w/ mic of each L and
+ minimum, impedance maximum, volume, DC offset w/o and w/ mic of each L and
R channel accordingly. Example is shown as following.
< 0 300 7 0xffd160 0xffd1c0 0xff8a10 0xff8ab0
301 65535 4 0xffe470 0xffe470 0xffb8e0 0xffb8e0>
diff --git a/Documentation/devicetree/bindings/sound/rt5677.txt b/Documentation/devicetree/bindings/sound/rt5677.txt
deleted file mode 100644
index da2430099181..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5677.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-RT5677 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "realtek,rt5677".
-
-- reg : The I2C address of the device.
-
-- interrupts : The CODEC's interrupt output.
-
-- gpio-controller : Indicates this device is a GPIO controller.
-
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters (currently unused).
-
-Optional properties:
-
-- realtek,pow-ldo2-gpio : The GPIO that controls the CODEC's POW_LDO2 pin.
-- realtek,reset-gpio : The GPIO that controls the CODEC's RESET pin. Active low.
-
-- realtek,in1-differential
-- realtek,in2-differential
-- realtek,lout1-differential
-- realtek,lout2-differential
-- realtek,lout3-differential
- Boolean. Indicate MIC1/2 input and LOUT1/2/3 outputs are differential,
- rather than single-ended.
-
-- realtek,gpio-config
- Array of six 8bit elements that configures GPIO.
- 0 - floating (reset value)
- 1 - pull down
- 2 - pull up
-
-- realtek,jd1-gpio
- Configures GPIO Mic Jack detection 1.
- Select 0 ~ 3 as OFF, GPIO1, GPIO2 and GPIO3 respectively.
-
-- realtek,jd2-gpio
-- realtek,jd3-gpio
- Configures GPIO Mic Jack detection 2 and 3.
- Select 0 ~ 3 as OFF, GPIO4, GPIO5 and GPIO6 respectively.
-
-Pins on the device (for linking into audio routes):
-
- * IN1P
- * IN1N
- * IN2P
- * IN2N
- * MICBIAS1
- * DMIC1
- * DMIC2
- * DMIC3
- * DMIC4
- * LOUT1
- * LOUT2
- * LOUT3
-
-Example:
-
-rt5677 {
- compatible = "realtek,rt5677";
- reg = <0x2c>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- realtek,pow-ldo2-gpio =
- <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
- realtek,reset-gpio = <&gpio TEGRA_GPIO(BB, 3) GPIO_ACTIVE_LOW>;
- realtek,in1-differential = "true";
- realtek,gpio-config = /bits/ 8 <0 0 0 0 0 2>; /* pull up GPIO6 */
- realtek,jd2-gpio = <3>; /* Enables Jack detection for GPIO6 */
-};
diff --git a/Documentation/devicetree/bindings/sound/rt5682.txt b/Documentation/devicetree/bindings/sound/rt5682.txt
deleted file mode 100644
index c5f2b8febcee..000000000000
--- a/Documentation/devicetree/bindings/sound/rt5682.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-RT5682 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
-- compatible : "realtek,rt5682" or "realtek,rt5682i"
-
-- reg : The I2C address of the device.
-
-Optional properties:
-
-- interrupts : The CODEC's interrupt output.
-
-- realtek,dmic1-data-pin
- 0: dmic1 is not used
- 1: using GPIO2 pin as dmic1 data pin
- 2: using GPIO5 pin as dmic1 data pin
-
-- realtek,dmic1-clk-pin
- 0: using GPIO1 pin as dmic1 clock pin
- 1: using GPIO3 pin as dmic1 clock pin
-
-- realtek,jd-src
- 0: No JD is used
- 1: using JD1 as JD source
-
-- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
-
-- realtek,btndet-delay
- The debounce delay for push button.
- The delay time is realtek,btndet-delay value multiple of 8.192 ms.
- If absent, the default is 16.
-
-- #clock-cells : Should be set to '<1>', wclk and bclk sources provided.
-- clock-output-names : Name given for DAI clocks output.
-
-- clocks : phandle and clock specifier for codec MCLK.
-- clock-names : Clock name string for 'clocks' attribute, should be "mclk".
-
-- realtek,dmic-clk-rate-hz : Set the clock rate (hz) for the requirement of
- the particular DMIC.
-
-- realtek,dmic-delay-ms : Set the delay time (ms) for the requirement of
- the particular DMIC.
-
-- realtek,dmic-clk-driving-high : Set the high driving of the DMIC clock out.
-
-- #sound-dai-cells: Should be set to '<0>'.
-
-Pins on the device (for linking into audio routes) for RT5682:
-
- * DMIC L1
- * DMIC R1
- * IN1P
- * HPOL
- * HPOR
-
-Example:
-
-rt5682 {
- compatible = "realtek,rt5682i";
- reg = <0x1a>;
- interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(U, 6) IRQ_TYPE_LEVEL_HIGH>;
- realtek,ldo1-en-gpios =
- <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
- realtek,dmic1-data-pin = <1>;
- realtek,dmic1-clk-pin = <1>;
- realtek,jd-src = <1>;
- realtek,btndet-delay = <16>;
-
- #clock-cells = <1>;
- clock-output-names = "rt5682-dai-wclk", "rt5682-dai-bclk";
-
- clocks = <&osc>;
- clock-names = "mclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml
index 447e013f6e17..5ea0819a261a 100644
--- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml
@@ -9,6 +9,9 @@ title: Samsung Aries audio complex with WM8994 codec
maintainers:
- Jonathan Bakker <xc-racer2@live.ca>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
enum:
@@ -17,10 +20,6 @@ properties:
# Without FM radio and modem slave
- samsung,fascinate4g-wm8994
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: The user-visible name of this sound complex.
-
cpu:
type: object
additionalProperties: false
@@ -46,6 +45,7 @@ properties:
samsung,audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ deprecated: true
description: |
List of the connections between audio
components; each entry is a pair of strings, the first being the
@@ -56,6 +56,7 @@ properties:
or FM In
For samsung,fascinate4g-wm8994: HP, SPK, RCV, LINE, Main Mic,
or HeadsetMic
+ Deprecated, use audio-routing.
extcon:
description: Extcon phandle for dock detection
@@ -87,10 +88,9 @@ properties:
required:
- compatible
- - model
- cpu
- codec
- - samsung,audio-routing
+ - audio-routing
- extcon
- main-micbias-supply
- headset-micbias-supply
@@ -98,7 +98,7 @@ required:
- headset-detect-gpios
- headset-key-gpios
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -121,7 +121,7 @@ examples:
headset-detect-gpios = <&gph0 6 GPIO_ACTIVE_HIGH>;
headset-key-gpios = <&gph3 6 GPIO_ACTIVE_HIGH>;
- samsung,audio-routing =
+ audio-routing =
"HP", "HPOUT1L",
"HP", "HPOUT1R",
diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
index 31095913e330..69ddfd4afdcd 100644
--- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml
@@ -9,14 +9,13 @@ title: Samsung Midas audio complex with WM1811 codec
maintainers:
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
const: samsung,midas-audio
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: The user-visible name of this sound complex.
-
cpu:
type: object
additionalProperties: false
@@ -38,6 +37,7 @@ properties:
- sound-dai
samsung,audio-routing:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
description: |
List of the connections between audio components; each entry is
@@ -45,6 +45,7 @@ properties:
being the connection's source; valid names for sources and sinks are
the WM1811's pins (as documented in its binding), and the jacks
on the board: HP, SPK, Main Mic, Sub Mic, Headset Mic.
+ Deprecated, use audio-routing.
mic-bias-supply:
description: Supply for the micbias on the Main microphone
@@ -52,6 +53,9 @@ properties:
submic-bias-supply:
description: Supply for the micbias on the Sub microphone
+ headset-mic-bias-supply:
+ description: Supply for the micbias on the Headset microphone
+
fm-sel-gpios:
maxItems: 1
description: GPIO pin for FM selection
@@ -60,16 +64,45 @@ properties:
maxItems: 1
description: GPIO pin for line out selection
+ headset-detect-gpios:
+ maxItems: 1
+ description: GPIO for detection of headset insertion
+
+ headset-key-gpios:
+ maxItems: 1
+ description: GPIO for detection of headset key press
+
+ io-channels:
+ maxItems: 1
+ description: IO channel to read micbias voltage for headset detection
+
+ io-channel-names:
+ const: headset-detect
+
+ samsung,headset-4pole-threshold-microvolt:
+ minItems: 2
+ maxItems: 2
+ description:
+ Array containing minimum and maximum IO channel value for 4-pole
+ (with microphone/button) headsets. If the IO channel value is
+ outside of this range, a 3-pole headset is assumed.
+
+ samsung,headset-button-threshold-microvolt:
+ minItems: 3
+ maxItems: 3
+ description: |
+ Array of minimum (inclusive) IO channel values for headset button
+ detection, in order: "Media", "Volume Up" and "Volume Down".
+
required:
- compatible
- - model
- cpu
- codec
- - samsung,audio-routing
+ - audio-routing
- mic-bias-supply
- submic-bias-supply
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -84,7 +117,7 @@ examples:
mic-bias-supply = <&mic_bias_reg>;
submic-bias-supply = <&submic_bias_reg>;
- samsung,audio-routing =
+ audio-routing =
"HP", "HPOUT1L",
"HP", "HPOUT1R",
diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
index 7b4e08ddef6a..c3dea852cc8d 100644
--- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml
@@ -10,6 +10,9 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
oneOf:
@@ -24,31 +27,26 @@ properties:
- const: samsung,odroid-xu4-audio
deprecated: true
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: The user-visible name of this sound complex.
-
- assigned-clock-parents: true
- assigned-clock-rates: true
- assigned-clocks: true
- clocks: true
-
cpu:
type: object
+ additionalProperties: false
properties:
sound-dai:
description: phandles to the I2S controllers
codec:
type: object
+ additionalProperties: false
properties:
sound-dai:
+ minItems: 1
items:
- - description: phandle of the MAX98090 CODEC
- description: phandle of the HDMI IP block node
+ - description: phandle of the MAX98090 CODEC
samsung,audio-routing:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ deprecated: true
description: |
List of the connections between audio
components; each entry is a pair of strings, the first being the
@@ -58,6 +56,7 @@ properties:
For Odroid X2: "Headphone Jack", "Mic Jack", "DMIC"
For Odroid U3, XU3: "Headphone Jack", "Speakers"
For Odroid XU4: no entries
+ Deprecated, use audio-routing.
samsung,audio-widgets:
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
@@ -67,18 +66,17 @@ properties:
required:
- compatible
- - model
- cpu
- codec
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
sound {
compatible = "hardkernel,odroid-xu3-audio";
model = "Odroid-XU3";
- samsung,audio-routing =
+ audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"IN1", "Mic Jack",
diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
index 491e08019c04..67586ba3e0a0 100644
--- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
@@ -10,6 +10,9 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: sound-card-common.yaml#
+
properties:
compatible:
const: samsung,tm2-audio
@@ -22,8 +25,10 @@ properties:
description: Phandles to the codecs.
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- - description: Phandle to the WM5110 audio codec.
- - description: Phandle to the HDMI transmitter node.
+ - items:
+ - description: Phandle to the WM5110 audio codec.
+ - items:
+ - description: Phandle to the HDMI transmitter node.
samsung,audio-routing:
description: |
@@ -32,6 +37,8 @@ properties:
being the connection's source; valid names for sources and sinks are the
WM5110's and MAX98504's pins and the jacks on the board: HP, SPK, Main
Mic, Sub Mic, Third Mic, Headset Mic.
+ Deprecated, use audio-routing.
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
i2s-controller:
@@ -44,20 +51,15 @@ properties:
mic-bias-gpios:
description: GPIO pin that enables the Main Mic bias regulator.
- model:
- description: The user-visible name of this sound complex.
- $ref: /schemas/types.yaml#/definitions/string
-
required:
- compatible
- audio-amplifier
- audio-codec
- - samsung,audio-routing
+ - audio-routing
- i2s-controller
- mic-bias-gpios
- - model
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -70,7 +72,7 @@ examples:
audio-amplifier = <&max98504>;
mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>;
model = "wm5110";
- samsung,audio-routing = "HP", "HPOUT1L",
+ audio-routing = "HP", "HPOUT1L",
"HP", "HPOUT1R",
"SPK", "SPKOUT",
"SPKOUT", "HPOUT2L",
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
index 84c4d6cba521..f45f73b5056d 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
@@ -10,6 +10,9 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
description: |
@@ -34,12 +37,25 @@ properties:
samsung,exynos7-i2s1: I2S1 on previous samsung platforms supports
stereo channels. Exynos7 I2S1 upgraded to 5.1 multichannel with
slightly modified bit offsets.
- enum:
- - samsung,s3c6410-i2s
- - samsung,s5pv210-i2s
- - samsung,exynos5420-i2s
- - samsung,exynos7-i2s
- - samsung,exynos7-i2s1
+
+ tesla,fsd-i2s: for 8/16/24bit stereo channel I2S for playback and
+ capture, secondary FIFO using external DMA, s/w reset control,
+ internal mux for root clock source with all root clock sampling
+ frequencies supported by Exynos7 I2S and 7.1 channel TDM support
+ for playback and capture TDM (Time division multiplexing) to allow
+ transfer of multiple channel audio data on single data line.
+ oneOf:
+ - enum:
+ - samsung,s3c6410-i2s
+ - samsung,s5pv210-i2s
+ - samsung,exynos5420-i2s
+ - samsung,exynos7-i2s
+ - samsung,exynos7-i2s1
+ - tesla,fsd-i2s
+ - items:
+ - enum:
+ - samsung,exynos5433-i2s
+ - const: samsung,exynos7-i2s
'#address-cells':
const: 1
@@ -64,9 +80,6 @@ properties:
- const: rx
- const: tx-sec
- assigned-clock-parents: true
- assigned-clocks: true
-
clocks:
minItems: 1
maxItems: 3
@@ -124,7 +137,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/serial-midi.yaml b/Documentation/devicetree/bindings/sound/serial-midi.yaml
index 4afc29376efc..3b2f6dd5bffa 100644
--- a/Documentation/devicetree/bindings/sound/serial-midi.yaml
+++ b/Documentation/devicetree/bindings/sound/serial-midi.yaml
@@ -20,7 +20,10 @@ description:
parent serial device. If the standard MIDI baud of 31.25 kBaud is needed
(as would be the case if interfacing with arbitrary external MIDI devices),
configure the clocks of the parent serial device so that a requested baud of 38.4 kBaud
- resuts in the standard MIDI baud rate, and set the 'current-speed' property to 38400 (default)
+ results in the standard MIDI baud rate, and set the 'current-speed' property to 38400 (default)
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
deleted file mode 100644
index 2bc7f00ce4a2..000000000000
--- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml
+++ /dev/null
@@ -1,110 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Freescale SGTL5000 Stereo Codec
-
-maintainers:
- - Fabio Estevam <festevam@gmail.com>
-
-properties:
- compatible:
- const: fsl,sgtl5000
-
- reg:
- maxItems: 1
-
- "#sound-dai-cells":
- const: 0
-
- assigned-clock-parents: true
- assigned-clock-rates: true
- assigned-clocks: true
-
- clocks:
- items:
- - description: the clock provider of SYS_MCLK
-
- VDDA-supply:
- description: the regulator provider of VDDA
-
- VDDIO-supply:
- description: the regulator provider of VDDIO
-
- VDDD-supply:
- description: the regulator provider of VDDD
-
- micbias-resistor-k-ohms:
- description: The bias resistor to be used in kOhms. The resistor can take
- values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not
- mentioned or if the value is unknown, then micbias resistor is set to
- 4k.
- enum: [ 0, 2, 4, 8 ]
-
- micbias-voltage-m-volts:
- description: The bias voltage to be used in mVolts. The voltage can take
- values from 1.25V to 3V by 250mV steps. If this node is not mentioned
- or the value is unknown, then the value is set to 1.25V.
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ]
-
- lrclk-strength:
- description: |
- The LRCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
- table below:
-
- VDDIO 1.8V 2.5V 3.3V
- 0 = Disable
- 1 = 1.66 mA 2.87 mA 4.02 mA
- 2 = 3.33 mA 5.74 mA 8.03 mA
- 3 = 4.99 mA 8.61 mA 12.05 mA
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum: [ 0, 1, 2, 3 ]
-
- sclk-strength:
- description: |
- The SCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
- table below:
-
- VDDIO 1.8V 2.5V 3.3V
- 0 = Disable
- 1 = 1.66 mA 2.87 mA 4.02 mA
- 2 = 3.33 mA 5.74 mA 8.03 mA
- 3 = 4.99 mA 8.61 mA 12.05 mA
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum: [ 0, 1, 2, 3 ]
-
- port:
- $ref: audio-graph-port.yaml#
- unevaluatedProperties: false
-
-required:
- - compatible
- - reg
- - "#sound-dai-cells"
- - clocks
- - VDDA-supply
- - VDDIO-supply
-
-additionalProperties: false
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- codec@a {
- compatible = "fsl,sgtl5000";
- reg = <0x0a>;
- #sound-dai-cells = <0>;
- clocks = <&clks 150>;
- micbias-resistor-k-ohms = <2>;
- micbias-voltage-m-volts = <2250>;
- VDDA-supply = <&reg_3p3v>;
- VDDIO-supply = <&reg_3p3v>;
- };
- };
-...
diff --git a/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
index 8327846356d3..5db1f989d050 100644
--- a/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/sound/simple-audio-amplifier.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Simple Audio Amplifier Device Tree Bindings
+title: Simple Audio Amplifier
maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
index b5fc35ee9b65..9b1bda4852e1 100644
--- a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
@@ -14,7 +14,7 @@ description: |
their input line is connected to the output line.
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
compatible:
@@ -24,6 +24,15 @@ properties:
description: |
GPIOs used to select the input line.
+ state-labels:
+ description: State of input line. default is "Input 1", "Input 2"
+ $ref: /schemas/types.yaml#/definitions/string-array
+ maxItems: 2
+
+ idle-state:
+ description: If present specifies the state when the mux is powered down
+ $ref: /schemas/mux/mux-controller.yaml#/properties/idle-state
+
sound-name-prefix: true
required:
@@ -37,4 +46,6 @@ examples:
mux {
compatible = "simple-audio-mux";
mux-gpios = <&gpio 3 0>;
+ state-labels = "Label_A", "Label_B";
+ idle-state = <0>;
};
diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml
index b261d49b9ddb..533d0a1da56e 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/simple-card.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Simple Audio Card Driver Device Tree Bindings
+title: Simple Audio Card Driver
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
@@ -78,7 +78,7 @@ definitions:
$ref: /schemas/types.yaml#/definitions/uint32
prefix:
- description: "device name prefix"
+ description: device name prefix
$ref: /schemas/types.yaml#/definitions/string
label:
@@ -148,6 +148,15 @@ definitions:
required:
- sound-dai
+ additional-devs:
+ type: object
+ description:
+ Additional devices used by the simple audio card.
+ patternProperties:
+ '^iio-aux(-.+)?$':
+ type: object
+ $ref: audio-iio-aux.yaml#
+
properties:
compatible:
contains:
@@ -187,6 +196,8 @@ properties:
$ref: "#/definitions/mclk-fs"
simple-audio-card,aux-devs:
$ref: "#/definitions/aux-devs"
+ simple-audio-card,additional-devs:
+ $ref: "#/definitions/additional-devs"
simple-audio-card,convert-rate:
$ref: "#/definitions/convert-rate"
simple-audio-card,convert-channels:
@@ -196,8 +207,14 @@ properties:
simple-audio-card,pin-switches:
$ref: "#/definitions/pin-switches"
simple-audio-card,hp-det-gpio:
+ deprecated: true
+ maxItems: 1
+ simple-audio-card,hp-det-gpios:
maxItems: 1
simple-audio-card,mic-det-gpio:
+ deprecated: true
+ maxItems: 1
+ simple-audio-card,mic-det-gpios:
maxItems: 1
patternProperties:
@@ -205,6 +222,8 @@ patternProperties:
$ref: "#/definitions/dai"
"^simple-audio-card,codec(@[0-9a-f]+)?$":
$ref: "#/definitions/dai"
+ "^simple-audio-card,plat(@[0-9a-f]+)?$":
+ $ref: "#/definitions/dai"
"^simple-audio-card,dai-link(@[0-9a-f]+)?$":
description: |
@@ -215,6 +234,10 @@ patternProperties:
reg:
maxItems: 1
+ "#address-cells":
+ const: 1
+ "#size-cells":
+ const: 0
# common properties
frame-master:
$ref: "#/definitions/frame-master"
@@ -239,14 +262,20 @@ patternProperties:
pin-switches:
$ref: "#/definitions/pin-switches"
hp-det-gpio:
+ deprecated: true
+ maxItems: 1
+ hp-det-gpios:
maxItems: 1
mic-det-gpio:
+ deprecated: true
+ maxItems: 1
+ mic-det-gpios:
maxItems: 1
patternProperties:
- "^cpu(@[0-9a-f]+)?":
+ "^cpu(-[0-9]+)?$":
$ref: "#/definitions/dai"
- "^codec(@[0-9a-f]+)?":
+ "^codec(-[0-9]+)?$":
$ref: "#/definitions/dai"
additionalProperties: false
@@ -256,9 +285,9 @@ required:
additionalProperties: false
examples:
-#--------------------
+# --------------------
# single DAI link
-#--------------------
+# --------------------
- |
sound {
compatible = "simple-audio-card";
@@ -285,9 +314,9 @@ examples:
};
};
-#--------------------
+# --------------------
# Multi DAI links
-#--------------------
+# --------------------
- |
sound {
compatible = "simple-audio-card";
@@ -328,10 +357,10 @@ examples:
};
};
-#--------------------
+# --------------------
# route audio from IMX6 SSI2 through TLV320DAC3100 codec
# through TPA6130A2 amplifier to headphones:
-#--------------------
+# --------------------
- |
sound {
compatible = "simple-audio-card";
@@ -353,9 +382,51 @@ examples:
};
};
-#--------------------
+# --------------------
+# route audio to/from a codec through an amplifier
+# designed with a potentiometer driven by IIO:
+# --------------------
+ - |
+ sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,aux-devs = <&amp_in>, <&amp_out>;
+ simple-audio-card,routing =
+ "CODEC LEFTIN", "AMP_IN LEFT OUT",
+ "CODEC RIGHTIN", "AMP_IN RIGHT OUT",
+ "AMP_OUT LEFT IN", "CODEC LEFTOUT",
+ "AMP_OUT RIGHT IN", "CODEC RIGHTOUT";
+
+ simple-audio-card,additional-devs {
+ amp_out: iio-aux-out {
+ compatible = "audio-iio-aux";
+ io-channels = <&pot_out 0>, <&pot_out 1>;
+ io-channel-names = "LEFT", "RIGHT";
+ snd-control-invert-range = <1 1>;
+ sound-name-prefix = "AMP_OUT";
+ };
+
+ amp_in: iio_aux-in {
+ compatible = "audio-iio-aux";
+ io-channels = <&pot_in 0>, <&pot_in 1>;
+ io-channel-names = "LEFT", "RIGHT";
+ sound-name-prefix = "AMP_IN";
+ };
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&cpu>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&codec>;
+ clocks = <&clocks>;
+ };
+ };
+
+# --------------------
# Sampling Rate Conversion
-#--------------------
+# --------------------
- |
sound {
compatible = "simple-audio-card";
@@ -381,9 +452,9 @@ examples:
};
};
-#--------------------
+# --------------------
# 2 CPU 1 Codec (Mixing)
-#--------------------
+# --------------------
- |
sound {
compatible = "simple-audio-card";
@@ -418,7 +489,7 @@ examples:
};
};
-#--------------------
+# --------------------
# Multi DAI links with DPCM:
#
# CPU0 ------ ak4613
@@ -427,7 +498,7 @@ examples:
# CPU3 --/ /* DPCM 5ch/6ch */
# CPU4 --/ /* DPCM 7ch/8ch */
# CPU5 ------ PCM3168A-c
-#--------------------
+# --------------------
- |
sound {
compatible = "simple-audio-card";
@@ -462,16 +533,16 @@ examples:
convert-channels = <8>; /* TDM Split */
- sndcpu1: cpu0 {
+ sndcpu1: cpu-0 {
sound-dai = <&rcar_sound 1>;
};
- cpu1 {
+ cpu-1 {
sound-dai = <&rcar_sound 2>;
};
- cpu2 {
+ cpu-2 {
sound-dai = <&rcar_sound 3>;
};
- cpu3 {
+ cpu-3 {
sound-dai = <&rcar_sound 4>;
};
codec {
diff --git a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
index 4b0795819064..a48d040b0a4f 100644
--- a/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/snps,designware-i2s.yaml
@@ -17,6 +17,9 @@ properties:
- const: snps,designware-i2s
- enum:
- snps,designware-i2s
+ - starfive,jh7110-i2stx0
+ - starfive,jh7110-i2stx1
+ - starfive,jh7110-i2srx
reg:
maxItems: 1
@@ -29,14 +32,36 @@ properties:
maxItems: 1
clocks:
- description: Sampling rate reference clock
- maxItems: 1
+ items:
+ - description: Sampling rate reference clock
+ - description: APB clock
+ - description: Audio master clock
+ - description: Inner audio master clock source
+ - description: External audio master clock source
+ - description: Bit clock
+ - description: Left/right channel clock
+ - description: External bit clock
+ - description: External left/right channel clock
+ minItems: 1
clock-names:
- const: i2sclk
+ items:
+ - const: i2sclk
+ - const: apb
+ - const: mclk
+ - const: mclk_inner
+ - const: mclk_ext
+ - const: bclk
+ - const: lrck
+ - const: bclk_ext
+ - const: lrck_ext
+ minItems: 1
resets:
- maxItems: 1
+ items:
+ - description: Optional controller resets
+ - description: controller reset of Sampling rate
+ minItems: 1
dmas:
items:
@@ -50,21 +75,99 @@ properties:
- const: rx
minItems: 1
-if:
- properties:
- compatible:
- contains:
- const: canaan,k210-i2s
-
-then:
- properties:
- "#sound-dai-cells":
- const: 1
-
-else:
- properties:
- "#sound-dai-cells":
- const: 0
+ starfive,syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller sys_syscon node.
+ - description: I2S-rx enabled control offset of SYS_SYSCONSAIF__SYSCFG register.
+ - description: I2S-rx enabled control mask
+ description:
+ The phandle to System Register Controller syscon node and the I2S-rx(ADC)
+ enabled control offset and mask of SYS_SYSCONSAIF__SYSCFG register.
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: canaan,k210-i2s
+ then:
+ properties:
+ "#sound-dai-cells":
+ const: 1
+ else:
+ properties:
+ "#sound-dai-cells":
+ const: 0
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: snps,designware-i2s
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ resets:
+ maxItems: 1
+ else:
+ properties:
+ resets:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-i2stx0
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+ clock-names:
+ minItems: 5
+ maxItems: 5
+ required:
+ - resets
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-i2stx1
+ then:
+ properties:
+ clocks:
+ minItems: 9
+ maxItems: 9
+ clock-names:
+ minItems: 9
+ maxItems: 9
+ required:
+ - resets
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-i2srx
+ then:
+ properties:
+ clocks:
+ minItems: 9
+ maxItems: 9
+ clock-names:
+ minItems: 9
+ maxItems: 9
+ required:
+ - resets
+ - starfive,syscon
+ else:
+ properties:
+ starfive,syscon: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
index 70f62ecd6eb2..8600520d7c47 100644
--- a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
+++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
@@ -9,6 +9,9 @@ title: UniPhier AIO audio system
maintainers:
- <alsa-devel@alsa-project.org>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -39,7 +42,7 @@ properties:
Specifies a phandle to soc-glue, which is used for changing mode of S/PDIF
signal pin to output from Hi-Z. This property is optional if you use I2S
signal pins only.
- $ref: "/schemas/types.yaml#/definitions/phandle"
+ $ref: /schemas/types.yaml#/definitions/phandle
"#sound-dai-cells":
const: 1
@@ -70,7 +73,7 @@ patternProperties:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
index be6acfda9999..985277648de1 100644
--- a/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
+++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
@@ -9,6 +9,9 @@ title: UniPhier EVEA SoC-internal sound codec
maintainers:
- <alsa-devel@alsa-project.org>
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: socionext,uniphier-evea
@@ -48,7 +51,7 @@ patternProperties:
$ref: audio-graph-port.yaml#
unevaluatedProperties: false
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
diff --git a/Documentation/devicetree/bindings/sound/sound-card-common.yaml b/Documentation/devicetree/bindings/sound/sound-card-common.yaml
new file mode 100644
index 000000000000..721950f65748
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sound-card-common.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/sound-card-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Board Sound Card Common Properties
+
+maintainers:
+ - Mark Brown <broonie@kernel.org>
+
+properties:
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+
+ ignore-suspend-widgets:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of audio sound widgets which are marked ignoring system suspend.
+ Paths between these endpoints are still active over suspend of the main
+ application processor that the current operating system is running.
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+required:
+ - model
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/sound-dai.yaml b/Documentation/devicetree/bindings/sound/sound-dai.yaml
index 61c6f7abc4e7..ff9036e43c44 100644
--- a/Documentation/devicetree/bindings/sound/sound-dai.yaml
+++ b/Documentation/devicetree/bindings/sound/sound-dai.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/sound-dai.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Digital Audio Interface consumer Device Tree Bindings
+title: Digital Audio Interface consumer
maintainers:
- Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/sound/spacemit,k1-i2s.yaml b/Documentation/devicetree/bindings/sound/spacemit,k1-i2s.yaml
new file mode 100644
index 000000000000..55bd0b307d22
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spacemit,k1-i2s.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/spacemit,k1-i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: K1 I2S controller
+
+description:
+ The I2S bus (Inter-IC sound bus) is a serial link for digital
+ audio data transfer between devices in the system.
+
+maintainers:
+ - Troy Mitchell <troy.mitchell@linux.spacemit.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-i2s
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock for I2S sysclk
+ - description: clock for I2S bclk
+ - description: clock for I2S bus
+ - description: clock for I2S controller
+
+ clock-names:
+ items:
+ - const: sysclk
+ - const: bclk
+ - const: bus
+ - const: func
+
+ dmas:
+ minItems: 1
+ maxItems: 2
+
+ dma-names:
+ minItems: 1
+ items:
+ - const: tx
+ - const: rx
+
+ resets:
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+ - resets
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+ i2s@d4026000 {
+ compatible = "spacemit,k1-i2s";
+ reg = <0xd4026000 0x30>;
+ clocks = <&syscon_mpmu CLK_I2S_SYSCLK>,
+ <&syscon_mpmu CLK_I2S_BCLK>,
+ <&syscon_apbc CLK_SSPA0_BUS>,
+ <&syscon_apbc CLK_SSPA0>;
+ clock-names = "sysclk", "bclk", "bus", "func";
+ dmas = <&pdma0 21>, <&pdma0 22>;
+ dma-names = "tx", "rx";
+ resets = <&syscon_apbc RESET_SSPA0>;
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/spdif-receiver.txt b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
deleted file mode 100644
index 80f807bf8a1d..000000000000
--- a/Documentation/devicetree/bindings/sound/spdif-receiver.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Device-Tree bindings for dummy spdif receiver
-
-Required properties:
- - compatible: should be "linux,spdif-dir".
-
-Example node:
-
- codec: spdif-receiver {
- compatible = "linux,spdif-dir";
- };
diff --git a/Documentation/devicetree/bindings/sound/sprd,pcm-platform.yaml b/Documentation/devicetree/bindings/sound/sprd,pcm-platform.yaml
new file mode 100644
index 000000000000..c15c01bbb884
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sprd,pcm-platform.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/sprd,pcm-platform.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum DMA platform
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,pcm-platform
+
+ dmas:
+ maxItems: 10
+
+ dma-names:
+ items:
+ - const: normal_p_l
+ - const: normal_p_r
+ - const: normal_c_l
+ - const: normal_c_r
+ - const: voice_c
+ - const: fast_p
+ - const: loop_c
+ - const: loop_p
+ - const: voip_c
+ - const: voip_p
+
+required:
+ - compatible
+ - dmas
+ - dma-names
+
+additionalProperties: false
+
+examples:
+ - |
+ platform {
+ compatible = "sprd,pcm-platform";
+ dmas = <&agcp_dma 1 1>, <&agcp_dma 2 2>,
+ <&agcp_dma 3 3>, <&agcp_dma 4 4>,
+ <&agcp_dma 5 5>, <&agcp_dma 6 6>,
+ <&agcp_dma 7 7>, <&agcp_dma 8 8>,
+ <&agcp_dma 9 9>, <&agcp_dma 10 10>;
+ dma-names = "normal_p_l", "normal_p_r",
+ "normal_c_l", "normal_c_r",
+ "voice_c", "fast_p",
+ "loop_c", "loop_p",
+ "voip_c", "voip_p";
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/sprd,sc9860-mcdt.yaml b/Documentation/devicetree/bindings/sound/sprd,sc9860-mcdt.yaml
new file mode 100644
index 000000000000..3b66bedeff97
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sprd,sc9860-mcdt.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/sprd,sc9860-mcdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum Multi-Channel Data Transfer controller
+
+description:
+ The Multi-channel data transfer controller is used for sound stream
+ transmission between the audio subsystem and other AP/CP subsystem. It
+ supports 10 DAC channels and 10 ADC channels, and each channel can be
+ configured with DMA mode or interrupt mode.
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,sc9860-mcdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mcdt@41490000 {
+ compatible = "sprd,sc9860-mcdt";
+ reg = <0x41490000 0x170>;
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/sprd-mcdt.txt b/Documentation/devicetree/bindings/sound/sprd-mcdt.txt
deleted file mode 100644
index 274ba0acbfd6..000000000000
--- a/Documentation/devicetree/bindings/sound/sprd-mcdt.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Spreadtrum Multi-Channel Data Transfer Binding
-
-The Multi-channel data transfer controller is used for sound stream
-transmission between audio subsystem and other AP/CP subsystem. It
-supports 10 DAC channel and 10 ADC channel, and each channel can be
-configured with DMA mode or interrupt mode.
-
-Required properties:
-- compatible: Should be "sprd,sc9860-mcdt".
-- reg: Should contain registers address and length.
-- interrupts: Should contain one interrupt shared by all channel.
-
-Example:
-
-mcdt@41490000 {
- compatible = "sprd,sc9860-mcdt";
- reg = <0 0x41490000 0 0x170>;
- interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/sprd-pcm.txt b/Documentation/devicetree/bindings/sound/sprd-pcm.txt
deleted file mode 100644
index 4b23e84b2e57..000000000000
--- a/Documentation/devicetree/bindings/sound/sprd-pcm.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Spreadtrum DMA platfrom bindings
-
-Required properties:
-- compatible: Should be "sprd,pcm-platform".
-- dmas: Specify the list of DMA controller phandle and DMA request line ordered pairs.
-- dma-names: Identifier string for each DMA request line in the dmas property.
- These strings correspond 1:1 with the ordered pairs in dmas.
-
-Example:
-
- audio_platform:platform@0 {
- compatible = "sprd,pcm-platform";
- dmas = <&agcp_dma 1 1>, <&agcp_dma 2 2>,
- <&agcp_dma 3 3>, <&agcp_dma 4 4>,
- <&agcp_dma 5 5>, <&agcp_dma 6 6>,
- <&agcp_dma 7 7>, <&agcp_dma 8 8>,
- <&agcp_dma 9 9>, <&agcp_dma 10 10>;
- dma-names = "normal_p_l", "normal_p_r",
- "normal_c_l", "normal_c_r",
- "voice_c", "fast_p",
- "loop_c", "loop_p",
- "voip_c", "voip_p";
- };
diff --git a/Documentation/devicetree/bindings/sound/ssm2518.txt b/Documentation/devicetree/bindings/sound/ssm2518.txt
deleted file mode 100644
index 59381a778c79..000000000000
--- a/Documentation/devicetree/bindings/sound/ssm2518.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-SSM2518 audio amplifier
-
-This device supports I2C only.
-
-Required properties:
- - compatible : Must be "adi,ssm2518"
- - reg : the I2C address of the device. This will either be 0x34 (ADDR pin low)
- or 0x35 (ADDR pin high)
-
-Optional properties:
- - gpios : GPIO connected to the nSD pin. If the property is not present it is
- assumed that the nSD pin is hardwired to always on.
-
-Example:
-
- ssm2518: ssm2518@34 {
- compatible = "adi,ssm2518";
- reg = <0x34>;
- gpios = <&gpio 5 0>;
- };
diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt
index 307398ef2317..e3d84864e0e4 100644
--- a/Documentation/devicetree/bindings/sound/st,sta350.txt
+++ b/Documentation/devicetree/bindings/sound/st,sta350.txt
@@ -77,7 +77,7 @@ Optional properties:
- st,odd-pwm-speed-mode:
If present, PWM speed mode run on odd speed mode (341.3 kHz) on all
- channels. If not present, normal PWM spped mode (384 kHz) will be used.
+ channels. If not present, normal PWM speed mode (384 kHz) will be used.
- st,distortion-compensation:
If present, distortion compensation variable uses DCC coefficient.
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
index d3966ae04ad0..b4f44f9c7c7d 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
enum:
- st,stm32h7-i2s
+ - st,stm32mp25-i2s
"#sound-dai-cells":
const: 0
@@ -30,6 +31,7 @@ properties:
- description: clock feeding the internal clock generator.
- description: I2S parent clock for sampling rates multiple of 8kHz.
- description: I2S parent clock for sampling rates multiple of 11.025kHz.
+ minItems: 2
clock-names:
items:
@@ -37,6 +39,7 @@ properties:
- const: i2sclk
- const: x8k
- const: x11k
+ minItems: 2
interrupts:
maxItems: 1
@@ -58,6 +61,14 @@ properties:
description: Configure the I2S device as MCLK clock provider.
const: 0
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- "#sound-dai-cells"
@@ -68,7 +79,37 @@ required:
- dmas
- dma-names
-additionalProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32h7-i2s
+
+ then:
+ properties:
+ clocks:
+ minItems: 4
+
+ clock-names:
+ minItems: 4
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp25-i2s
+
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ maxItems: 2
+
+unevaluatedProperties: false
examples:
- |
@@ -86,6 +127,13 @@ examples:
dma-names = "rx", "tx";
pinctrl-names = "default";
pinctrl-0 = <&i2s2_pins_a>;
+
+ /* assume audio-graph */
+ port {
+ codec_endpoint: endpoint {
+ remote-endpoint = <&codec_endpoint>;
+ };
+ };
};
...
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
index 56d206f97a96..4a7129d0b157 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml
@@ -20,6 +20,7 @@ properties:
enum:
- st,stm32f4-sai
- st,stm32h7-sai
+ - st,stm32mp25-sai
reg:
items:
@@ -43,11 +44,17 @@ properties:
const: 1
clocks:
+ minItems: 1
maxItems: 3
clock-names:
+ minItems: 1
maxItems: 3
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
@@ -63,12 +70,12 @@ patternProperties:
additionalProperties: false
description:
Two subnodes corresponding to SAI sub-block instances A et B
- can be defined. Subnode can be omitted for unsused sub-block.
+ can be defined. Subnode can be omitted for unused sub-block.
properties:
compatible:
description: Compatible for SAI sub-block A or B.
- pattern: "st,stm32-sai-sub-[ab]"
+ pattern: "^st,stm32-sai-sub-[ab]$"
"#sound-dai-cells":
const: 0
@@ -152,7 +159,13 @@ allOf:
items:
- const: x8k
- const: x11k
- else:
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mph7-sai
+ then:
properties:
clocks:
items:
@@ -166,6 +179,21 @@ allOf:
- const: x8k
- const: x11k
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp25-sai
+ then:
+ properties:
+ clocks:
+ items:
+ - description: pclk feeds the peripheral bus interface.
+
+ clock-names:
+ items:
+ - const: pclk
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
index 837e830c47ac..56c5738ea4c5 100644
--- a/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
+++ b/Documentation/devicetree/bindings/sound/st,stm32-spdifrx.yaml
@@ -13,6 +13,9 @@ description: |
The SPDIFRX peripheral, is designed to receive an S/PDIF flow compliant with
IEC-60958 and IEC-61937.
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -47,6 +50,14 @@ properties:
resets:
maxItems: 1
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- "#sound-dai-cells"
@@ -57,7 +68,7 @@ required:
- dmas
- dma-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/starfive,jh7110-pwmdac.yaml b/Documentation/devicetree/bindings/sound/starfive,jh7110-pwmdac.yaml
new file mode 100644
index 000000000000..e2b4db6aa2fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/starfive,jh7110-pwmdac.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/starfive,jh7110-pwmdac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 PWM-DAC Controller
+
+description:
+ The PWM-DAC Controller uses PWM square wave generators plus RC filters to
+ form a DAC for audio play in StarFive JH7110 SoC. This audio play controller
+ supports 16 bit audio format, up to 48K sampling frequency, up to left and
+ right dual channels.
+
+maintainers:
+ - Hal Feng <hal.feng@starfivetech.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: starfive,jh7110-pwmdac
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: PWMDAC APB
+ - description: PWMDAC CORE
+
+ clock-names:
+ items:
+ - const: apb
+ - const: core
+
+ resets:
+ maxItems: 1
+ description: PWMDAC APB
+
+ dmas:
+ maxItems: 1
+ description: TX DMA Channel
+
+ dma-names:
+ const: tx
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - dmas
+ - dma-names
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ pwmdac@100b0000 {
+ compatible = "starfive,jh7110-pwmdac";
+ reg = <0x100b0000 0x1000>;
+ clocks = <&syscrg 157>,
+ <&syscrg 158>;
+ clock-names = "apb", "core";
+ resets = <&syscrg 96>;
+ dmas = <&dma 22>;
+ dma-names = "tx";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml b/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml
new file mode 100644
index 000000000000..abb373fbfa26
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/starfive,jh7110-tdm.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/starfive,jh7110-tdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 TDM Controller
+
+description: |
+ The TDM Controller is a Time Division Multiplexed audio interface
+ integrated in StarFive JH7110 SoC, allowing up to 8 channels of
+ audio over a serial interface. The TDM controller can operate both
+ in master and slave mode.
+
+maintainers:
+ - Walker Chen <walker.chen@starfivetech.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - starfive,jh7110-tdm
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TDM AHB Clock
+ - description: TDM APB Clock
+ - description: TDM Internal Clock
+ - description: TDM Clock
+ - description: Inner MCLK
+ - description: TDM External Clock
+
+ clock-names:
+ items:
+ - const: tdm_ahb
+ - const: tdm_apb
+ - const: tdm_internal
+ - const: tdm
+ - const: mclk_inner
+ - const: tdm_ext
+
+ resets:
+ items:
+ - description: tdm ahb reset line
+ - description: tdm apb reset line
+ - description: tdm core reset line
+
+ dmas:
+ items:
+ - description: RX DMA Channel
+ - description: TX DMA Channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - dmas
+ - dma-names
+ - "#sound-dai-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ tdm@10090000 {
+ compatible = "starfive,jh7110-tdm";
+ reg = <0x10090000 0x1000>;
+ clocks = <&syscrg 184>,
+ <&syscrg 185>,
+ <&syscrg 186>,
+ <&syscrg 187>,
+ <&syscrg 17>,
+ <&tdm_ext>;
+ clock-names = "tdm_ahb", "tdm_apb",
+ "tdm_internal", "tdm",
+ "mclk_inner", "tdm_ext";
+ resets = <&syscrg 105>,
+ <&syscrg 107>,
+ <&syscrg 106>;
+ dmas = <&dma 20>, <&dma 21>;
+ dma-names = "rx","tx";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml
deleted file mode 100644
index 30f6b029ac08..000000000000
--- a/Documentation/devicetree/bindings/sound/tas2562.yaml
+++ /dev/null
@@ -1,78 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright (C) 2019 Texas Instruments Incorporated
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/sound/tas2562.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Texas Instruments TAS2562 Smart PA
-
-maintainers:
- - Andrew Davis <afd@ti.com>
-
-description: |
- The TAS2562 is a mono, digital input Class-D audio amplifier optimized for
- efficiently driving high peak power into small loudspeakers.
- Integrated speaker voltage and current sense provides for
- real time monitoring of loudspeaker behavior.
-
- Specifications about the audio amplifier can be found at:
- https://www.ti.com/lit/gpn/tas2562
- https://www.ti.com/lit/gpn/tas2563
- https://www.ti.com/lit/gpn/tas2564
- https://www.ti.com/lit/gpn/tas2110
-
-properties:
- compatible:
- enum:
- - ti,tas2562
- - ti,tas2563
- - ti,tas2564
- - ti,tas2110
-
- reg:
- maxItems: 1
- description: |
- I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
-
- shut-down-gpios:
- maxItems: 1
- description: GPIO used to control the state of the device.
- deprecated: true
-
- shutdown-gpios:
- maxItems: 1
- description: GPIO used to control the state of the device.
-
- interrupts:
- maxItems: 1
-
- ti,imon-slot-no:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TDM TX current sense time slot.
-
- '#sound-dai-cells':
- const: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- codec: codec@4c {
- compatible = "ti,tas2562";
- reg = <0x4c>;
- #sound-dai-cells = <1>;
- interrupt-parent = <&gpio1>;
- interrupts = <14>;
- shutdown-gpios = <&gpio1 15 0>;
- ti,imon-slot-no = <0>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml
deleted file mode 100644
index bc90e72bf7cf..000000000000
--- a/Documentation/devicetree/bindings/sound/tas2770.yaml
+++ /dev/null
@@ -1,82 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright (C) 2019-20 Texas Instruments Incorporated
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/sound/tas2770.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Texas Instruments TAS2770 Smart PA
-
-maintainers:
- - Shi Fu <shifu0704@thundersoft.com>
-
-description: |
- The TAS2770 is a mono, digital input Class-D audio amplifier optimized for
- efficiently driving high peak power into small loudspeakers.
- Integrated speaker voltage and current sense provides for
- real time monitoring of loudspeaker behavior.
-
-properties:
- compatible:
- enum:
- - ti,tas2770
-
- reg:
- maxItems: 1
- description: |
- I2C address of the device can be between 0x41 to 0x48.
-
- reset-gpio:
- maxItems: 1
- description: GPIO used to reset the device.
-
- shutdown-gpios:
- maxItems: 1
- description: GPIO used to control the state of the device.
-
- interrupts:
- maxItems: 1
-
- ti,imon-slot-no:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TDM TX current sense time slot.
-
- ti,vmon-slot-no:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TDM TX voltage sense time slot.
-
- ti,asi-format:
- deprecated: true
- $ref: /schemas/types.yaml#/definitions/uint32
- description: Sets TDM RX capture edge.
- enum:
- - 0 # Rising edge
- - 1 # Falling edge
-
- '#sound-dai-cells':
- const: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- codec: codec@41 {
- compatible = "ti,tas2770";
- reg = <0x41>;
- #sound-dai-cells = <1>;
- interrupt-parent = <&gpio1>;
- interrupts = <14>;
- reset-gpio = <&gpio1 15 0>;
- shutdown-gpios = <&gpio1 14 0>;
- ti,imon-slot-no = <0>;
- ti,vmon-slot-no = <2>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml
deleted file mode 100644
index 66a0df8850ea..000000000000
--- a/Documentation/devicetree/bindings/sound/tas27xx.yaml
+++ /dev/null
@@ -1,77 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright (C) 2020-2022 Texas Instruments Incorporated
-%YAML 1.2
----
-$id: "http://devicetree.org/schemas/sound/tas27xx.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
-
-title: Texas Instruments TAS2764/TAS2780 Smart PA
-
-maintainers:
- - Shenghao Ding <shenghao-ding@ti.com>
-
-description: |
- The TAS2764/TAS2780 is a mono, digital input Class-D audio amplifier
- optimized for efficiently driving high peak power into small
- loudspeakers. Integrated speaker voltage and current sense provides
- for real time monitoring of loudspeaker behavior.
-
-properties:
- compatible:
- enum:
- - ti,tas2764
- - ti,tas2780
-
- reg:
- maxItems: 1
- description: |
- I2C address of the device can be between 0x38 to 0x45.
-
- reset-gpios:
- maxItems: 1
- description: GPIO used to reset the device.
-
- shutdown-gpios:
- maxItems: 1
- description: GPIO used to control the state of the device.
-
- interrupts:
- maxItems: 1
-
- ti,imon-slot-no:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TDM TX current sense time slot.
-
- ti,vmon-slot-no:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: TDM TX voltage sense time slot.
-
- '#sound-dai-cells':
- const: 1
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- codec: codec@38 {
- compatible = "ti,tas2764";
- reg = <0x38>;
- #sound-dai-cells = <1>;
- interrupt-parent = <&gpio1>;
- interrupts = <14>;
- reset-gpios = <&gpio1 15 0>;
- shutdown-gpios = <&gpio1 15 0>;
- ti,imon-slot-no = <0>;
- ti,vmon-slot-no = <2>;
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt b/Documentation/devicetree/bindings/sound/tas571x.txt
deleted file mode 100644
index 7c8fd37c2f9e..000000000000
--- a/Documentation/devicetree/bindings/sound/tas571x.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Texas Instruments TAS5711/TAS5717/TAS5719/TAS5721 stereo power amplifiers
-
-The codec is controlled through an I2C interface. It also has two other
-signals that can be wired up to GPIOs: reset (strongly recommended), and
-powerdown (optional).
-
-Required properties:
-
-- compatible: should be one of the following:
- - "ti,tas5707"
- - "ti,tas5711",
- - "ti,tas5717",
- - "ti,tas5719",
- - "ti,tas5721"
-- reg: The I2C address of the device
-- #sound-dai-cells: must be equal to 0
-
-Optional properties:
-
-- reset-gpios: GPIO specifier for the TAS571x's active low reset line
-- pdn-gpios: GPIO specifier for the TAS571x's active low powerdown line
-- clocks: clock phandle for the MCLK input
-- clock-names: should be "mclk"
-- AVDD-supply: regulator phandle for the AVDD supply (all chips)
-- DVDD-supply: regulator phandle for the DVDD supply (all chips)
-- HPVDD-supply: regulator phandle for the HPVDD supply (5717/5719)
-- PVDD_AB-supply: regulator phandle for the PVDD_AB supply (5717/5719)
-- PVDD_CD-supply: regulator phandle for the PVDD_CD supply (5717/5719)
-- PVDD_A-supply: regulator phandle for the PVDD_A supply (5711)
-- PVDD_B-supply: regulator phandle for the PVDD_B supply (5711)
-- PVDD_C-supply: regulator phandle for the PVDD_C supply (5711)
-- PVDD_D-supply: regulator phandle for the PVDD_D supply (5711)
-- DRVDD-supply: regulator phandle for the DRVDD supply (5721)
-- PVDD-supply: regulator phandle for the PVDD supply (5721)
-
-Example:
-
- tas5717: audio-codec@2a {
- compatible = "ti,tas5717";
- reg = <0x2a>;
- #sound-dai-cells = <0>;
-
- reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
- pdn-gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
-
- clocks = <&clk_core CLK_I2S>;
- clock-names = "mclk";
- };
diff --git a/Documentation/devicetree/bindings/sound/tas5720.txt b/Documentation/devicetree/bindings/sound/tas5720.txt
index df99ca9451b0..7d851ae2bba2 100644
--- a/Documentation/devicetree/bindings/sound/tas5720.txt
+++ b/Documentation/devicetree/bindings/sound/tas5720.txt
@@ -6,11 +6,13 @@ audio playback. For more product information please see the links below:
https://www.ti.com/product/TAS5720L
https://www.ti.com/product/TAS5720M
+https://www.ti.com/product/TAS5720A-Q1
https://www.ti.com/product/TAS5722L
Required properties:
- compatible : "ti,tas5720",
+ "ti,tas5720a-q1",
"ti,tas5722"
- reg : I2C slave address
- dvdd-supply : phandle to a 3.3-V supply for the digital circuitry
diff --git a/Documentation/devicetree/bindings/sound/tas5805m.yaml b/Documentation/devicetree/bindings/sound/tas5805m.yaml
deleted file mode 100644
index 3aade02d8a96..000000000000
--- a/Documentation/devicetree/bindings/sound/tas5805m.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/tas5805m.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: TAS5805M audio amplifier
-
-maintainers:
- - Daniel Beer <daniel.beer@igorinstitute.com>
-
-description: |
- The TAS5805M is a class D audio amplifier with a built-in DSP.
-
-properties:
- compatible:
- enum:
- - ti,tas5805m
-
- reg:
- maxItems: 1
- description: |
- I2C address of the amplifier. See the datasheet for possible values.
-
- pvdd-supply:
- description: |
- Regulator for audio power supply (PVDD in the datasheet).
-
- pdn-gpios:
- description: |
- Power-down control GPIO (PDN pin in the datasheet).
-
- ti,dsp-config-name:
- description: |
- The name of the DSP configuration that should be loaded for this
- instance. Configuration blobs are sequences of register writes
- generated from TI's PPC3 tool.
- $ref: /schemas/types.yaml#/definitions/string
-
-examples:
- - |
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- tas5805m: tas5805m@2c {
- reg = <0x2c>;
- compatible = "ti,tas5805m";
-
- pvdd-supply = <&audiopwr>;
- pdn-gpios = <&tlmm 160 0>;
-
- ti,dsp-config-name = "mono_pbtl_48khz";
- };
- };
-
-additionalProperties: true
diff --git a/Documentation/devicetree/bindings/sound/test-component.yaml b/Documentation/devicetree/bindings/sound/test-component.yaml
index 17fdb4317239..9c40a2122dfd 100644
--- a/Documentation/devicetree/bindings/sound/test-component.yaml
+++ b/Documentation/devicetree/bindings/sound/test-component.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/test-component.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Test Component Device Tree Bindings
+title: Test Component
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
diff --git a/Documentation/devicetree/bindings/sound/tfa9879.txt b/Documentation/devicetree/bindings/sound/tfa9879.txt
deleted file mode 100644
index 1620e6848436..000000000000
--- a/Documentation/devicetree/bindings/sound/tfa9879.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-NXP TFA9879 class-D audio amplifier
-
-Required properties:
-
-- compatible : "nxp,tfa9879"
-
-- reg : the I2C address of the device
-
-- #sound-dai-cells : must be 0.
-
-Example:
-
-&i2c1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
-
- amp: amp@6c {
- #sound-dai-cells = <0>;
- compatible = "nxp,tfa9879";
- reg = <0x6c>;
- };
-};
-
diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
index 859d369c71e2..5b2874a80a4d 100644
--- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
@@ -13,7 +13,7 @@ maintainers:
description: |
The Infotainment board plugs into the Common Processor Board, the support of the
- extension board is extending the CPB audio support, decribed in:
+ extension board is extending the CPB audio support, described in:
sound/ti,j721e-cpb-audio.txt
The audio support on the Infotainment Expansion Board consists of McASP0
diff --git a/Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml b/Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml
new file mode 100644
index 000000000000..27c7019bdc85
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,omap-twl4030.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,omap-twl4030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments SoC with twl4030 based audio setups
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description:
+ Audio setups on TI OMAP SoCs using TWL4030-family
+ audio codec connected via a McBSP port.
+
+properties:
+ compatible:
+ const: ti,omap-twl4030
+
+ ti,model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: Name of the sound card (for example "omap3beagle").
+
+ ti,mcbsp:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle for the McBSP node.
+
+ ti,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle for the twl4030 audio node.
+
+ ti,mcbsp-voice:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the McBSP node connected to the voice port.
+
+ ti,jack-det-gpio:
+ description: GPIO specifier for jack detection.
+ maxItems: 1
+
+ ti,audio-routing:
+ description: |
+ A list of audio routing connections. Each entry is a pair of strings,
+ with the first being the connection's sink and the second being the
+ source. If not provided, all possible connections are available.
+
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ items:
+ enum:
+ # Board Connectors
+ - Headset Stereophone
+ - Earpiece Spk
+ - Handsfree Spk
+ - Ext Spk
+ - Main Mic
+ - Sub Mic
+ - Headset Mic
+ - Carkit Mic
+ - Digital0 Mic
+ - Digital1 Mic
+ - Line In
+
+ # CODEC Pins
+ - HSOL
+ - HSOR
+ - EARPIECE
+ - HFL
+ - HFR
+ - PREDRIVEL
+ - PREDRIVER
+ - CARKITL
+ - CARKITR
+ - MAINMIC
+ - SUBMIC
+ - HSMIC
+ - DIGIMIC0
+ - DIGIMIC1
+ - CARKITMIC
+ - AUXL
+ - AUXR
+
+ # Headset Mic Bias
+ - Mic Bias 1 # Used for Main Mic or Digimic0
+ - Mic Bias 2 # Used for Sub Mic or Digimic1
+
+required:
+ - compatible
+ - ti,model
+ - ti,mcbsp
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "ti,omap-twl4030";
+ ti,model = "omap3beagle";
+ ti,mcbsp = <&mcbsp2>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,omap4-mcpdm.yaml b/Documentation/devicetree/bindings/sound/ti,omap4-mcpdm.yaml
new file mode 100644
index 000000000000..cdea0a00826a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,omap4-mcpdm.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,omap4-mcpdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP McPDM
+
+maintainers:
+ - Misael Lopez Cruz <misael.lopez@ti.com>
+
+description:
+ OMAP ALSA SoC DAI driver using McPDM port used by TWL6040
+
+properties:
+ compatible:
+ const: ti,omap4-mcpdm
+
+ reg:
+ items:
+ - description: MPU access base address
+ - description: L3 interconnect address
+
+ reg-names:
+ items:
+ - const: mpu
+ - const: dma
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: up_link
+ - const: dn_link
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pdmclk
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - dmas
+ - dma-names
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ mcpdm@0 {
+ compatible = "ti,omap4-mcpdm";
+ reg = <0x0 0x7f>, /* MPU private access */
+ <0x49032000 0x7f>; /* L3 Interconnect */
+ reg-names = "mpu", "dma";
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ dmas = <&sdma 65>, <&sdma 66>;
+ dma-names = "up_link", "dn_link";
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
deleted file mode 100644
index 4df17185ab80..000000000000
--- a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Texas Instruments PCM1681 8-channel PWM Processor
-
-Required properties:
-
- - compatible: Should contain "ti,pcm1681".
- - reg: The i2c address. Should contain <0x4c>.
-
-Examples:
-
- i2c_bus {
- pcm1681@4c {
- compatible = "ti,pcm1681";
- reg = <0x4c>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml
new file mode 100644
index 000000000000..1f0e6787a746
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm1681.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PCM1681 8-channel Digital-to-Analog Converter
+
+maintainers:
+ - Shenghao Ding <shenghao-ding@ti.com>
+ - Kevin Lu <kevin-lu@ti.com>
+ - Baojun Xu <baojun.xu@ti.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: ti,pcm1681
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcm1681: audio-codec@4c {
+ compatible = "ti,pcm1681";
+ reg = <0x4c>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1754.yaml b/Documentation/devicetree/bindings/sound/ti,pcm1754.yaml
new file mode 100644
index 000000000000..a757f737690c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm1754.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm1754.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PCM1754 Stereo DAC
+
+description:
+ The PCM1754 is a simple stereo DAC that is controlled via hardware gpios.
+
+maintainers:
+ - Stefan Kerkmann <s.kerkmann@pengutronix.de>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,pcm1754
+
+ vcc-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ format-gpios:
+ maxItems: 1
+ description:
+ GPIO used to select the PCM format
+
+ mute-gpios:
+ maxItems: 1
+ description:
+ GPIO used to mute all outputs
+
+required:
+ - compatible
+ - '#sound-dai-cells'
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ codec {
+ compatible = "ti,pcm1754";
+ #sound-dai-cells = <0>;
+
+ vcc-supply = <&vcc_reg>;
+ mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
+ format-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1862.yaml b/Documentation/devicetree/bindings/sound/ti,pcm1862.yaml
new file mode 100644
index 000000000000..0f0e254a2420
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm1862.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm1862.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PCM186x Universal Audio ADC
+
+maintainers:
+ - Ranganath V N <vnranganath.20@gmail.com>
+
+description: |
+ The Texas Instruments PCM186x family are multi-channel audio ADCs
+ that support both I2C and SPI control interfaces, selected by
+ pin strapping. These devices include on-chip programmable gain
+ amplifiers and support differential or single-ended analog inputs.
+
+ CODEC input pins:
+ * VINL1
+ * VINR1
+ * VINL2
+ * VINR2
+ * VINL3
+ * VINR3
+ * VINL4
+ * VINR4
+
+ The pins can be used in referring sound node's audio-routing property.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,pcm1862
+ - ti,pcm1863
+ - ti,pcm1864
+ - ti,pcm1865
+
+ reg:
+ maxItems: 1
+
+ avdd-supply: true
+
+ dvdd-supply: true
+
+ iovdd-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - iovdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@4a {
+ compatible = "ti,pcm1865";
+ reg = <0x4a>;
+
+ avdd-supply = <&reg_3v3_analog>;
+ dvdd-supply = <&reg_3v3>;
+ iovdd-supply = <&reg_1v8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm3168a.txt b/Documentation/devicetree/bindings/sound/ti,pcm3168a.txt
deleted file mode 100644
index a02ecaab5183..000000000000
--- a/Documentation/devicetree/bindings/sound/ti,pcm3168a.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Texas Instruments pcm3168a DT bindings
-
-This driver supports both SPI and I2C bus access for this codec
-
-Required properties:
-
- - compatible: "ti,pcm3168a"
-
- - clocks : Contains an entry for each entry in clock-names
-
- - clock-names : Includes the following entries:
- "scki" The system clock
-
- - VDD1-supply : Digital power supply regulator 1 (+3.3V)
-
- - VDD2-supply : Digital power supply regulator 2 (+3.3V)
-
- - VCCAD1-supply : ADC power supply regulator 1 (+5V)
-
- - VCCAD2-supply : ADC power supply regulator 2 (+5V)
-
- - VCCDA1-supply : DAC power supply regulator 1 (+5V)
-
- - VCCDA2-supply : DAC power supply regulator 2 (+5V)
-
-For required properties on SPI/I2C, consult SPI/I2C device tree documentation
-
-Optional properties:
-
- - reset-gpios : Optional reset gpio line connected to RST pin of the codec.
- The RST line is low active:
- RST = low: device power-down
- RST = high: device is enabled
-
-Examples:
-
-i2c0: i2c0@0 {
-
- ...
-
- pcm3168a: audio-codec@44 {
- compatible = "ti,pcm3168a";
- reg = <0x44>;
- reset-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
- clocks = <&clk_core CLK_AUDIO>;
- clock-names = "scki";
- VDD1-supply = <&supply3v3>;
- VDD2-supply = <&supply3v3>;
- VCCAD1-supply = <&supply5v0>;
- VCCAD2-supply = <&supply5v0>;
- VCCDA1-supply = <&supply5v0>;
- VCCDA2-supply = <&supply5v0>;
- pinctrl-names = "default";
- pinctrl-0 = <&dac_clk_pin>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml b/Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml
new file mode 100644
index 000000000000..0b4f003989a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm3168a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PCM3168A Audio Codec
+
+maintainers:
+ - Damien Horsley <Damien.Horsley@imgtec.com>
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+description:
+ The Texas Instruments PCM3168A is a 24-bit Multi-channel Audio CODEC with
+ 96/192kHz sampling rate, supporting both SPI and I2C bus access.
+
+properties:
+ compatible:
+ const: ti,pcm3168a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: System clock input
+
+ clock-names:
+ items:
+ - const: scki
+
+ reset-gpios:
+ items:
+ - description: |
+ GPIO line connected to the active-low RST pin of the codec.
+ RST = low: device power-down
+ RST = high: device is enabled
+
+ "#sound-dai-cells":
+ enum: [0, 1]
+
+ VDD1-supply:
+ description: Digital power supply regulator 1 (+3.3V)
+
+ VDD2-supply:
+ description: Digital power supply regulator 2 (+3.3V)
+
+ VCCAD1-supply:
+ description: ADC power supply regulator 1 (+5V)
+
+ VCCAD2-supply:
+ description: ADC power supply regulator 2 (+5V)
+
+ VCCDA1-supply:
+ description: DAC power supply regulator 1 (+5V)
+
+ VCCDA2-supply:
+ description: DAC power supply regulator 2 (+5V)
+
+ ports:
+ $ref: audio-graph-port.yaml#/definitions/port-base
+ unevaluatedProperties: false
+ properties:
+ port@0:
+ $ref: audio-graph-port.yaml#
+ description: Audio input port.
+
+ port@1:
+ $ref: audio-graph-port.yaml#
+ description: Audio output port.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - VDD1-supply
+ - VDD2-supply
+ - VCCAD1-supply
+ - VCCAD2-supply
+ - VCCDA1-supply
+ - VCCDA2-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcm3168a: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ reset-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+ clocks = <&clk_core 42>;
+ clock-names = "scki";
+ VDD1-supply = <&supply3v3>;
+ VDD2-supply = <&supply3v3>;
+ VCCAD1-supply = <&supply5v0>;
+ VCCAD2-supply = <&supply5v0>;
+ VCCDA1-supply = <&supply5v0>;
+ VCCDA2-supply = <&supply5v0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm512x.yaml b/Documentation/devicetree/bindings/sound/ti,pcm512x.yaml
new file mode 100644
index 000000000000..21ea9ff5a2bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm512x.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm512x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCM512x and TAS575x audio CODECs/amplifiers
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,pcm5121
+ - ti,pcm5122
+ - ti,pcm5141
+ - ti,pcm5142
+ - ti,pcm5242
+ - ti,tas5754
+ - ti,tas5756
+
+ reg:
+ maxItems: 1
+
+ AVDD-supply: true
+
+ DVDD-supply: true
+
+ CPVDD-supply: true
+
+ clocks:
+ maxItems: 1
+ description: A clock specifier for the clock connected as SCLK. If this is
+ absent the device will be configured to clock from BCLK. If pll-in and
+ pll-out are specified in addition to a clock, the device is configured to
+ accept clock input on a specified gpio pin.
+
+ '#sound-dai-cells':
+ const: 0
+
+ pll-in:
+ description: GPIO pin used to connect the pll using <1> through <6>. The
+ device will be configured for clock input on the given pll-in pin.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 6
+
+ pll-out:
+ description: GPIO pin used to connect the pll using <1> through <6>. The
+ device will be configured for PLL output on the given pll-out pin. An
+ external connection from the pll-out pin to the SCLK pin is assumed.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 6
+
+required:
+ - compatible
+ - reg
+ - AVDD-supply
+ - DVDD-supply
+ - CPVDD-supply
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5754
+ - ti,tas5756
+
+then:
+ properties:
+ pll-in:
+ maximum: 3
+
+ pll-out:
+ maximum: 3
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@4c {
+ compatible = "ti,pcm5142";
+ reg = <0x4c>;
+ AVDD-supply = <&reg_3v3_analog>;
+ DVDD-supply = <&reg_1v8>;
+ CPVDD-supply = <&reg_3v3>;
+ #sound-dai-cells = <0>;
+ clocks = <&sck>;
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml
new file mode 100644
index 000000000000..d89b4255b51c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,pcm6240.yaml
@@ -0,0 +1,179 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 - 2024 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,pcm6240.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments PCM6240 Family Audio ADC/DAC
+
+maintainers:
+ - Shenghao Ding <shenghao-ding@ti.com>
+
+description: |
+ The PCM6240 Family is a big family of Audio ADC/DAC for
+ different Specifications, range from Personal Electric
+ to Automotive Electric, even some professional fields.
+
+ Specifications about the audio chip can be found at:
+ https://www.ti.com/lit/gpn/tlv320adc3120
+ https://www.ti.com/lit/gpn/tlv320adc5120
+ https://www.ti.com/lit/gpn/tlv320adc6120
+ https://www.ti.com/lit/gpn/dix4192
+ https://www.ti.com/lit/gpn/pcm1690
+ https://www.ti.com/lit/gpn/pcm3120-q1
+ https://www.ti.com/lit/gpn/pcm3140-q1
+ https://www.ti.com/lit/gpn/pcm5120-q1
+ https://www.ti.com/lit/gpn/pcm6120-q1
+ https://www.ti.com/lit/gpn/pcm6260-q1
+ https://www.ti.com/lit/gpn/pcm9211
+ https://www.ti.com/lit/gpn/pcmd3140
+ https://www.ti.com/lit/gpn/pcmd3180
+ https://www.ti.com/lit/gpn/taa5212
+ https://www.ti.com/lit/gpn/tad5212
+
+properties:
+ compatible:
+ description: |
+ ti,adc3120: Stereo-channel, 768-kHz, Burr-Brown™ audio analog-to-
+ digital converter (ADC) with 106-dB SNR.
+
+ ti,adc5120: 2-Channel, 768-kHz, Burr-Brown™ Audio ADC with 120-dB SNR.
+
+ ti,adc6120: Stereo-channel, 768-kHz, Burr-Brown™ audio analog-to-
+ digital converter (ADC) with 123-dB SNR.
+
+ ti,dix4192: 216-kHz digital audio converter with Quad-Channel In
+ and One-Channel Out.
+
+ ti,pcm1690: Automotive Catalog 113dB SNR 8-Channel Audio DAC with
+ Differential Outputs.
+
+ ti,pcm3120: Automotive, stereo, 106-dB SNR, 768-kHz, low-power
+ software-controlled audio ADC.
+
+ ti,pcm3140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC
+ with 106-dB SNR.
+
+ ti,pcm5120: Automotive, stereo, 120-dB SNR, 768-kHz, low-power
+ software-controlled audio ADC.
+
+ ti,pcm5140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC
+ with 120-dB SNR.
+
+ ti,pcm6120: Automotive, stereo, 123-dB SNR, 768-kHz, low-power
+ software-controlled audio ADC.
+
+ ti,pcm6140: Automotive, Quad-Channel, 768-kHz, Burr-Brown™ Audio ADC
+ with 123-dB SNR.
+
+ ti,pcm6240: Automotive 4-ch audio ADC with integrated programmable mic
+ bias, boost and input diagnostics.
+
+ ti,pcm6260: Automotive 6-ch audio ADC with integrated programmable mic
+ bias, boost and input diagnostics.
+
+ ti,pcm9211: 216-kHz digital audio converter With Stereo ADC and
+ Routing.
+
+ ti,pcmd3140: Four-channel PDM-input to TDM or I2S output converter.
+
+ ti,pcmd3180: Eight-channel pulse-density-modulation input to TDM or
+ I2S output converter.
+
+ ti,taa5212: Low-power high-performance stereo audio ADC with 118-dB
+ dynamic range.
+
+ ti,tad5212: Low-power stereo audio DAC with 120-dB dynamic range.
+ oneOf:
+ - items:
+ - enum:
+ - ti,adc3120
+ - ti,adc5120
+ - ti,pcm3120
+ - ti,pcm5120
+ - ti,pcm6120
+ - const: ti,adc6120
+ - items:
+ - enum:
+ - ti,pcmd512x
+ - ti,pcm9211
+ - ti,taa5212
+ - ti,tad5212
+ - const: ti,adc6120
+ - items:
+ - enum:
+ - ti,pcm3140
+ - ti,pcm5140
+ - ti,dix4192
+ - ti,pcm6140
+ - ti,pcm6260
+ - const: ti,pcm6240
+ - items:
+ - enum:
+ - ti,pcmd3140
+ - ti,pcmd3180
+ - ti,pcm1690
+ - ti,taa5412
+ - ti,tad5412
+ - const: ti,pcm6240
+ - enum:
+ - ti,adc6120
+ - ti,pcm6240
+
+ reg:
+ description:
+ I2C address, in multiple pcmdevices case, all the i2c address
+ aggregate as one Audio Device to support multiple audio slots.
+ minItems: 1
+ maxItems: 4
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description:
+ Invalid only for ti,pcm1690 because of no INT pin.
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,pcm1690
+ then:
+ properties:
+ interrupts: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ /* example for two devices with interrupt support */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@48 {
+ compatible = "ti,pcm6240";
+ reg = <0x48>, /* primary-device */
+ <0x4b>; /* secondary-device */
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,src4xxx.yaml b/Documentation/devicetree/bindings/sound/ti,src4xxx.yaml
index 9681b72b4918..27230c682d10 100644
--- a/Documentation/devicetree/bindings/sound/ti,src4xxx.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,src4xxx.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sound/ti,src4xxx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments SRC4392 Device Tree Bindings
+title: Texas Instruments SRC4392
description: |
The SRC4392 is a digital audio codec that can be connected via
@@ -14,7 +14,7 @@ maintainers:
- Matt Flax <flatmax@flatmax.com>
allOf:
- - $ref: name-prefix.yaml#
+ - $ref: dai-common.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2562.yaml b/Documentation/devicetree/bindings/sound/ti,tas2562.yaml
new file mode 100644
index 000000000000..3763ca16b91f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas2562.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas2562.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TAS2562 Smart PA
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+
+description: |
+ The TAS2562 is a mono, digital input Class-D audio amplifier optimized for
+ efficiently driving high peak power into small loudspeakers.
+ Integrated speaker voltage and current sense provides for
+ real time monitoring of loudspeaker behavior.
+
+ Specifications about the audio amplifier can be found at:
+ https://www.ti.com/lit/gpn/tas2562
+ https://www.ti.com/lit/gpn/tas2564
+ https://www.ti.com/lit/gpn/tas2110
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2562
+ - ti,tas2564
+ - ti,tas2110
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
+
+ shut-down-gpios:
+ maxItems: 1
+ description: GPIO used to control the state of the device.
+ deprecated: true
+
+ shutdown-gpios:
+ maxItems: 1
+ description: GPIO used to control the state of the device.
+
+ interrupts:
+ maxItems: 1
+
+ ti,imon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TDM TX current sense time slot.
+
+ '#sound-dai-cells':
+ # The codec has a single DAI, the #sound-dai-cells=<1>; case is left in for backward
+ # compatibility but is deprecated.
+ enum: [0, 1]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@4c {
+ compatible = "ti,tas2562";
+ reg = <0x4c>;
+ #sound-dai-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14>;
+ shutdown-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ ti,imon-slot-no = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml
new file mode 100644
index 000000000000..8eab98a0f7a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2019-20 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas2770.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TAS2770 Smart PA
+
+maintainers:
+ - Shi Fu <shifu0704@thundersoft.com>
+
+description: |
+ The TAS2770 is a mono, digital input Class-D audio amplifier optimized for
+ efficiently driving high peak power into small loudspeakers.
+ Integrated speaker voltage and current sense provides for
+ real time monitoring of loudspeaker behavior.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2770
+ - ti,tas5770l # Apple variant
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the device can be between 0x41 to 0x48.
+
+ reset-gpio:
+ maxItems: 1
+ description: GPIO used to reset the device.
+
+ shutdown-gpios:
+ maxItems: 1
+ description: GPIO used to control the state of the device.
+
+ interrupts:
+ maxItems: 1
+
+ ti,imon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TDM TX current sense time slot.
+
+ ti,vmon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TDM TX voltage sense time slot.
+
+ ti,asi-format:
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Sets TDM RX capture edge.
+ enum:
+ - 0 # Rising edge
+ - 1 # Falling edge
+
+ '#sound-dai-cells':
+ # The codec has a single DAI, the #sound-dai-cells=<1>; case is left in for backward
+ # compatibility but is deprecated.
+ enum: [0, 1]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@41 {
+ compatible = "ti,tas2770";
+ reg = <0x41>;
+ #sound-dai-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14>;
+ reset-gpio = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
+ ti,imon-slot-no = <0>;
+ ti,vmon-slot-no = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
new file mode 100644
index 000000000000..f3a5638f4239
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
@@ -0,0 +1,299 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 - 2025 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas2781.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TAS2563/TAS2781 SmartAMP
+
+maintainers:
+ - Shenghao Ding <shenghao-ding@ti.com>
+
+description: |
+ The TAS2118/TAS2X20 is mono, digital input Class-D audio
+ amplifier optimized for efficiently driving high peak power into
+ small loudspeakers.
+ The TAS257x is mono, digital input Class-D audio amplifier optimized
+ for efficiently driving high peak power into small loudspeakers.
+ Integrated speaker voltage and current sense provides for real time
+ monitoring of loudspeaker behavior.
+ The TAS2563/TAS2781 is a mono, digital input Class-D audio
+ amplifier optimized for efficiently driving high peak power into
+ small loudspeakers. An integrated on-chip DSP supports Texas
+ Instruments Smart Amp speaker protection algorithm. The
+ integrated speaker voltage and current sense provides for real time
+ monitoring of loudspeaker behavior.
+ The TAS5802/TAS5815/TAS5822/TAS5825/TAS5827/TAS5828 is a stereo,
+ digital input Class-D audio amplifier optimized for efficiently driving
+ high peak power into small loudspeakers. An integrated on-chip DSP
+ supports Texas Instruments Smart Amp speaker protection algorithm.
+
+ Specifications about the audio amplifier can be found at:
+ https://www.ti.com/lit/gpn/tas2120
+ https://www.ti.com/lit/gpn/tas2320
+ https://www.ti.com/lit/gpn/tas2563
+ https://www.ti.com/lit/gpn/tas2572
+ https://www.ti.com/lit/gpn/tas2574
+ https://www.ti.com/lit/gpn/tas2781
+ https://www.ti.com/lit/gpn/tas5806m
+ https://www.ti.com/lit/gpn/tas5806md
+ https://www.ti.com/lit/gpn/tas5815
+ https://www.ti.com/lit/gpn/tas5822m
+ https://www.ti.com/lit/gpn/tas5825m
+ https://www.ti.com/lit/gpn/tas5827
+ https://www.ti.com/lit/gpn/tas5828m
+ https://www.ti.com/lit/gpn/tas5830
+
+properties:
+ compatible:
+ description: |
+ ti,tas2020: 3.2-W Mono Digital Input Class-D Speaker Amp with 5.5V PVDD
+ Support.
+
+ ti,tas2118: 5-W Mono Digital Input Class-D Speaker Amp with Integrated
+ 8.4-V Class-H Boost.
+
+ ti,tas2120: 8.2-W Mono Digital Input Class-D Speaker Amp with
+ Integrated 14.75V Class-H Boost.
+
+ ti,tas2320: 15-W Mono Digital Input Class-D Speaker Amp with 15V Support.
+
+ ti,tas2563: 6.1-W Boosted Class-D Audio Amplifier With Integrated
+ DSP and IV Sense, 16/20/24/32bit stereo I2S or multichannel TDM.
+
+ ti,tas2568: 5.3-W Digital Input Smart Amp with I/V Sense and Integrated
+ 10.75-V Class-H Boost
+
+ ti,tas2570: 5.8-W Digital Input smart amp with I/V sense and integrated
+ 11-V Class-H Boost
+
+ ti,tas2572: 6.6-W Digital Input smart amp with I/V sense and integrated
+ 13-V Class-H Boost
+
+ ti,tas2574: 8.5-W Digital Input smart amp with I/V sense and integrated
+ 15-V Class-H Boost
+
+ ti,tas2781: 24-V Class-D Amplifier with Real Time Integrated Speaker
+ Protection and Audio Processing, 16/20/24/32bit stereo I2S or
+ multichannel TDM.
+
+ ti,tas5802: 22-W, Inductor-Less, Digital Input, Closed-Loop Class-D
+ Audio Amplifier with 96-Khz Extended Processing and Low Idle Power
+ Dissipation.
+
+ ti,tas5806m: 23-W, Inductor-Less, Digital Input, Stereo, Closed-Loop
+ Class-D Audio Amplifier with Enhanced Processing and Low Power
+ Dissipation.
+
+ ti,tas5806md: 23-W, Inductor-Less, Digital Input, Stereo, Closed-Loop
+ Class-D Audio Amplifier with Enhanced Processing and DirectPath(TM)
+ HP Driver
+
+ ti,tas5815: 30-W, Digital Input, Stereo, Closed-loop Class-D Audio
+ Amplifier with 96 kHz Enhanced Processing
+
+ ti,tas5822: 35-W, Digital Input, Stereo, Closed-Loop Class-D Audio
+ Amplifier with 96 kHz Enhanced Processing
+
+ ti,tas5825: 38-W Stereo, Inductor-Less, Digital Input, Closed-Loop 4.5V
+ to 26.4V Class-D Audio Amplifier with 192-kHz Extended Audio Processing.
+
+ ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop
+ Class-D Amplifier with Class-H Algorithm
+
+ ti,tas5828: 50-W Stereo, Digital Input, High Efficiency Closed-Loop
+ Class-D Amplifier with Hybrid-Pro Algorithm
+
+ ti,tas5830: 65-W Stereo, Digital Input, High Efficiency Closed-Loop
+ Class-D Amplifier with Class-H Algorithm
+ oneOf:
+ - items:
+ - enum:
+ - ti,tas2020
+ - ti,tas2118
+ - ti,tas2120
+ - ti,tas2320
+ - ti,tas2563
+ - ti,tas2568
+ - ti,tas2570
+ - ti,tas2572
+ - ti,tas2574
+ - ti,tas5802
+ - ti,tas5806m
+ - ti,tas5806md
+ - ti,tas5815
+ - ti,tas5822
+ - ti,tas5825
+ - ti,tas5827
+ - ti,tas5828
+ - ti,tas5830
+ - const: ti,tas2781
+ - enum:
+ - ti,tas2781
+
+ reg:
+ description:
+ I2C address, in multiple-AMP case, all the i2c address
+ aggregate as one Audio Device to support multiple audio slots.
+ maxItems: 8
+ minItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas2020
+ - ti,tas2118
+ - ti,tas2120
+ - ti,tas2320
+ - ti,tas2568
+ - ti,tas2574
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ items:
+ minimum: 0x48
+ maximum: 0x4b
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas2563
+ - ti,tas5825
+ then:
+ properties:
+ reg:
+ description:
+ I2C address, in multiple-AMP case, all the i2c address
+ aggregate as one Audio Device to support multiple audio slots.
+ maxItems: 4
+ minItems: 1
+ items:
+ minimum: 0x4c
+ maximum: 0x4f
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas2570
+ - ti,tas2572
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ items:
+ minimum: 0x48
+ maximum: 0x4b
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas2781
+ then:
+ properties:
+ reg:
+ description:
+ I2C address, in multiple-AMP case, all the i2c address
+ aggregate as one Audio Device to support multiple audio slots.
+ maxItems: 8
+ minItems: 1
+ items:
+ minimum: 0x38
+ maximum: 0x3f
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5802
+ - ti,tas5815
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ items:
+ minimum: 0x54
+ maximum: 0x57
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5806m
+ - ti,tas5806md
+ - ti,tas5822
+ then:
+ properties:
+ reg:
+ maxItems: 4
+ items:
+ minimum: 0x2c
+ maximum: 0x2f
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5827
+ - ti,tas5828
+ - ti,tas5830
+ then:
+ properties:
+ reg:
+ maxItems: 6
+ items:
+ minimum: 0x60
+ maximum: 0x65
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ /* example with quad tas2781s, such as tablet or pad device */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@38 {
+ compatible = "ti,tas2781";
+ reg = <0x38>, /* Audio slot 0 */
+ <0x3a>, /* Audio slot 1 */
+ <0x39>, /* Audio slot 2 */
+ <0x3b>; /* Audio slot 3 */
+
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml b/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml
new file mode 100644
index 000000000000..fcaae848e78a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020-2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas27xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TAS2764/TAS2780 Smart PA
+
+maintainers:
+ - Shenghao Ding <shenghao-ding@ti.com>
+
+description: |
+ The TAS2764/TAS2780 is a mono, digital input Class-D audio amplifier
+ optimized for efficiently driving high peak power into small
+ loudspeakers. Integrated speaker voltage and current sense provides
+ for real time monitoring of loudspeaker behavior.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2764
+ - ti,tas2780
+ - ti,sn012776 # Apple variant of TAS2764
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the device can be between 0x38 to 0x45.
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO used to reset the device.
+
+ shutdown-gpios:
+ maxItems: 1
+ description: GPIO used to control the state of the device.
+
+ interrupts:
+ maxItems: 1
+
+ ti,imon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TDM TX current sense time slot.
+
+ ti,vmon-slot-no:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: TDM TX voltage sense time slot.
+
+ '#sound-dai-cells':
+ # The codec has a single DAI, the #sound-dai-cells=<1>; case is left in for backward
+ # compatibility but is deprecated.
+ enum: [0, 1]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@38 {
+ compatible = "ti,tas2764";
+ reg = <0x38>;
+ #sound-dai-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14>;
+ reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ ti,imon-slot-no = <0>;
+ ti,vmon-slot-no = <2>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml b/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml
new file mode 100644
index 000000000000..0b013a34e2c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas57xx.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas57xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TAS5711/TAS5717/TAS5719/TAS5721 stereo power amplifiers
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - ti,tas5707
+ - ti,tas5711
+ - ti,tas5717
+ - ti,tas5719
+ - ti,tas5721
+ - ti,tas5733
+ - ti,tas5753
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO for the active low reset line
+
+ pdn-gpios:
+ maxItems: 1
+ description: GPIO for the active low powerdown line
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+ AVDD-supply: true
+ DVDD-supply: true
+ HPVDD-supply: true
+ PVDD_AB-supply: true
+ PVDD_CD-supply: true
+ PVDD_A-supply: true
+ PVDD_B-supply: true
+ PVDD_C-supply: true
+ PVDD_D-supply: true
+ DRVDD-supply: true
+ PVDD-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - '#sound-dai-cells'
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5717
+ - ti,tas5719
+ then:
+ properties:
+ PVDD_A-supply: false
+ PVDD_B-supply: false
+ PVDD_C-supply: false
+ PVDD_D-supply: false
+ DRVDD-supply: false
+ PVDD-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5711
+ then:
+ properties:
+ HPVDD-supply: false
+ PVDD_AB-supply: false
+ PVDD_CD-supply: false
+ DRVDD-supply: false
+ PVDD-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,tas5721
+ - ti,tas5753
+ then:
+ properties:
+ HPVDD-supply: false
+ PVDD_AB-supply: false
+ PVDD_CD-supply: false
+ PVDD_A-supply: false
+ PVDD_B-supply: false
+ PVDD_C-supply: false
+ PVDD_D-supply: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@2a {
+ compatible = "ti,tas5717";
+ reg = <0x2a>;
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ pdn-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ AVDD-supply = <&avdd_supply>;
+ DVDD-supply = <&dvdd_supply>;
+ HPVDD-supply = <&hpvdd_supply>;
+ PVDD_AB-supply = <&pvdd_ab_supply>;
+ PVDD_CD-supply = <&pvdd_cd_supply>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,tas5805m.yaml b/Documentation/devicetree/bindings/sound/ti,tas5805m.yaml
new file mode 100644
index 000000000000..c2c2835a9e1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas5805m.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tas5805m.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TAS5805M audio amplifier
+
+maintainers:
+ - Daniel Beer <daniel.beer@igorinstitute.com>
+
+description: |
+ The TAS5805M is a class D audio amplifier with a built-in DSP.
+
+properties:
+ compatible:
+ enum:
+ - ti,tas5805m
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the amplifier. See the datasheet for possible values.
+
+ pvdd-supply:
+ description: |
+ Regulator for audio power supply (PVDD in the datasheet).
+
+ pdn-gpios:
+ description: |
+ Power-down control GPIO (PDN pin in the datasheet).
+
+ ti,dsp-config-name:
+ description: |
+ The name of the DSP configuration that should be loaded for this
+ instance. Configuration blobs are sequences of register writes
+ generated from TI's PPC3 tool.
+ $ref: /schemas/types.yaml#/definitions/string
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ tas5805m: tas5805m@2c {
+ reg = <0x2c>;
+ compatible = "ti,tas5805m";
+
+ pvdd-supply = <&audiopwr>;
+ pdn-gpios = <&tlmm 160 0>;
+
+ ti,dsp-config-name = "mono_pbtl_48khz";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml
index 83936f594d1a..66b76656229f 100644
--- a/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml
@@ -14,6 +14,9 @@ description: |
https://www.ti.com/product/TLV320ADC3001
https://www.ti.com/product/TLV320ADC3101
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
enum:
@@ -55,8 +58,8 @@ properties:
description: |
Configuration for DMDIN/GPIO1 pin.
- When ADC3XXX_GPIO_GPO is configured, this causes corresponding the
- ALSA control "GPIOx Output" to appear, as a switch control.
+ When ADC3XXX_GPIO_GPO is selected, the pin may be controlled via the
+ GPIO framework, as pin number 0 on the device.
ti,dmclk-gpio2:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -73,12 +76,32 @@ properties:
description: |
Configuration for DMCLK/GPIO2 pin.
- When ADC3XXX_GPIO_GPO is configured, this causes corresponding the
- ALSA control "GPIOx Output" to appear, as a switch control.
+ When ADC3XXX_GPIO_GPO is selected, the pin may be controlled via the
+ GPIO framework, as pin number 1 on the device.
Note that there is currently no support for reading the GPIO pins as
inputs.
+ ti,micbias1-gpo:
+ type: boolean
+ description: |
+ When set, the MICBIAS1 pin may be controlled via the GPIO framework,
+ as pin number 3 on the device.
+
+ In this mode, when the pin is activated, it will be set to the voltage
+ specified by the ti,micbias1-vg property. When deactivated, the pin will
+ float.
+
+ ti,micbias2-gpo:
+ type: boolean
+ description: |
+ When set, the MICBIAS2 pin may be controlled via the GPIO framework,
+ as pin number 4 on the device.
+
+ In this mode, when the pin is activated, it will be set to the voltage
+ specified by the ti,micbias2-vg property. When deactivated, the pin will
+ float.
+
ti,micbias1-vg:
$ref: /schemas/types.yaml#/definitions/uint32
enum:
@@ -101,12 +124,16 @@ properties:
description: |
Mic bias voltage output on MICBIAS2 pin
+dependencies:
+ ti,micbias1-gpo: ['ti,micbias1-vg']
+ ti,micbias2-gpo: ['ti,micbias2-vg']
+
required:
- compatible
- reg
- clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320adcx140.yaml
new file mode 100644
index 000000000000..876fa97bfbcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320adcx140.yaml
@@ -0,0 +1,209 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tlv320adcx140.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TLV320ADCX140 Quad Channel Analog-to-Digital Converter
+
+maintainers:
+ - Andrew Davis <afd@ti.com>
+
+description: |
+ The TLV320ADCX140 are multichannel (4-ch analog recording or 8-ch digital
+ PDM microphones recording), high-performance audio, analog-to-digital
+ converter (ADC) with analog inputs supporting up to 2V RMS. The TLV320ADCX140
+ family supports line and microphone Inputs, and offers a programmable
+ microphone bias or supply voltage generation.
+
+ Specifications can be found at:
+ https://www.ti.com/lit/ds/symlink/tlv320adc3140.pdf
+ https://www.ti.com/lit/ds/symlink/tlv320adc5140.pdf
+ https://www.ti.com/lit/ds/symlink/tlv320adc6140.pdf
+
+properties:
+ compatible:
+ enum:
+ - ti,tlv320adc3140
+ - ti,tlv320adc5140
+ - ti,tlv320adc6140
+
+ reg:
+ maxItems: 1
+ description: |
+ I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
+
+ reset-gpios:
+ maxItems: 1
+ description: |
+ GPIO used for hardware reset.
+
+ areg-supply:
+ description: |
+ Regulator with AVDD at 3.3V. If not defined then the internal regulator
+ is enabled.
+
+ ti,mic-bias-source:
+ description: |
+ Indicates the source for MIC Bias.
+ 0 - Mic bias is set to VREF
+ 1 - Mic bias is set to VREF × 1.096
+ 6 - Mic bias is set to AVDD
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 6]
+
+ ti,vref-source:
+ description: |
+ Indicates the source for MIC Bias.
+ 0 - Set VREF to 2.75V
+ 1 - Set VREF to 2.5V
+ 2 - Set VREF to 1.375V
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ ti,pdm-edge-select:
+ description: |
+ Defines the PDMCLK sampling edge configuration for the PDM inputs. This
+ array is defined as <PDMIN1 PDMIN2 PDMIN3 PDMIN4>.
+
+ 0 - (default) Odd channel is latched on the negative edge and even
+ channel is latched on the positive edge.
+ 1 - Odd channel is latched on the positive edge and even channel is
+ latched on the negative edge.
+
+ PDMIN1 - PDMCLK latching edge used for channel 1 and 2 data
+ PDMIN2 - PDMCLK latching edge used for channel 3 and 4 data
+ PDMIN3 - PDMCLK latching edge used for channel 5 and 6 data
+ PDMIN4 - PDMCLK latching edge used for channel 7 and 8 data
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 1
+ default: [0, 0, 0, 0]
+
+ ti,gpi-config:
+ description: |
+ Defines the configuration for the general purpose input pins (GPI).
+ The array is defined as <GPI1 GPI2 GPI3 GPI4>.
+
+ 0 - (default) disabled
+ 1 - GPIX is configured as a general-purpose input (GPI)
+ 2 - GPIX is configured as a master clock input (MCLK)
+ 3 - GPIX is configured as an ASI input for daisy-chain (SDIN)
+ 4 - GPIX is configured as a PDM data input for channel 1 and channel
+ (PDMDIN1)
+ 5 - GPIX is configured as a PDM data input for channel 3 and channel
+ (PDMDIN2)
+ 6 - GPIX is configured as a PDM data input for channel 5 and channel
+ (PDMDIN3)
+ 7 - GPIX is configured as a PDM data input for channel 7 and channel
+ (PDMDIN4)
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 7
+ default: [0, 0, 0, 0]
+
+ ti,gpio-config:
+ description: |
+ Defines the configuration and output drive for the General Purpose
+ Input and Output pin (GPIO1). Its value is a pair, the first value is for
+ the configuration type and the second value is for the output drive
+ type. The array is defined as <GPIO1_CFG GPIO1_DRV>
+
+ configuration for the GPIO pin can be one of the following:
+ 0 - disabled
+ 1 - GPIO1 is configured as a general-purpose output (GPO)
+ 2 - (default) GPIO1 is configured as a device interrupt output (IRQ)
+ 3 - GPIO1 is configured as a secondary ASI output (SDOUT2)
+ 4 - GPIO1 is configured as a PDM clock output (PDMCLK)
+ 8 - GPIO1 is configured as an input to control when MICBIAS turns on or
+ off (MICBIAS_EN)
+ 9 - GPIO1 is configured as a general-purpose input (GPI)
+ 10 - GPIO1 is configured as a master clock input (MCLK)
+ 11 - GPIO1 is configured as an ASI input for daisy-chain (SDIN)
+ 12 - GPIO1 is configured as a PDM data input for channel 1 and channel 2
+ (PDMDIN1)
+ 13 - GPIO1 is configured as a PDM data input for channel 3 and channel 4
+ (PDMDIN2)
+ 14 - GPIO1 is configured as a PDM data input for channel 5 and channel 6
+ (PDMDIN3)
+ 15 - GPIO1 is configured as a PDM data input for channel 7 and channel 8
+ (PDMDIN4)
+
+ output drive type for the GPIO pin can be one of the following:
+ 0 - Hi-Z output
+ 1 - Drive active low and active high
+ 2 - (default) Drive active low and weak high
+ 3 - Drive active low and Hi-Z
+ 4 - Drive weak low and active high
+ 5 - Drive Hi-Z and active high
+
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+ items:
+ maximum: 15
+ default: [2, 2]
+
+ ti,asi-tx-drive:
+ type: boolean
+ description: |
+ When set the device will set the Tx ASI output to a Hi-Z state for unused
+ data cycles. Default is to drive the output low on unused ASI cycles.
+
+patternProperties:
+ '^ti,gpo-config-[1-4]$':
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Defines the configuration and output driver for the general purpose
+ output pins (GPO). These values are pairs, the first value is for the
+ configuration type and the second value is for the output drive type.
+ The array is defined as <GPO_CFG GPO_DRV>
+
+ GPO output configuration can be one of the following:
+
+ 0 - (default) disabled
+ 1 - GPOX is configured as a general-purpose output (GPO)
+ 2 - GPOX is configured as a device interrupt output (IRQ)
+ 3 - GPOX is configured as a secondary ASI output (SDOUT2)
+ 4 - GPOX is configured as a PDM clock output (PDMCLK)
+
+ GPO output drive configuration for the GPO pins can be one of the following:
+
+ 0d - (default) Hi-Z output
+ 1d - Drive active low and active high
+ 2d - Drive active low and weak high
+ 3d - Drive active low and Hi-Z
+ 4d - Drive weak low and active high
+ 5d - Drive Hi-Z and active high
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec: codec@4c {
+ compatible = "ti,tlv320adc5140";
+ reg = <0x4c>;
+ ti,mic-bias-source = <6>;
+ ti,pdm-edge-select = <0 1 0 1>;
+ ti,gpi-config = <4 5 6 7>;
+ ti,gpio-config = <10 2>;
+ ti,gpo-config-1 = <0 0>;
+ ti,gpo-config-2 = <0 0>;
+ reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml
new file mode 100644
index 000000000000..4783e6dbb5c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic32x4.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tlv320aic32x4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TLV320AIC32x4 Stereo Audio codec
+
+maintainers:
+ - Alexander Stein <alexander.stein@ew.tq-group.com>
+
+description: |
+ The TLV320AIC32x4 audio codec can be accessed using I2C or SPI
+
+properties:
+ compatible:
+ enum:
+ - ti,tas2505
+ - ti,tlv320aic32x4
+ - ti,tlv320aic32x6
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Master clock
+
+ clock-names:
+ items:
+ - const: mclk
+
+ av-supply:
+ description: Analog core power supply
+
+ dv-supply:
+ description: Digital core power supply
+
+ iov-supply:
+ description: Digital IO power supply
+
+ ldoin-supply:
+ description: LDO power supply
+
+ reset-gpios:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ aic32x4-gpio-func:
+ description: |
+ GPIO function configuration for pins MFP1-MFP5.
+ Types are defined in include/sound/tlv320aic32x4.h
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 5
+ maxItems: 5
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - iov-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ not:
+ required:
+ - ldoin-supply
+ then:
+ required:
+ - av-supply
+ - dv-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ iov-supply = <&reg_3v3>;
+ ldoin-supply = <&reg_3v3>;
+ clocks = <&clks 201>;
+ clock-names = "mclk";
+ aic32x4-gpio-func = <
+ 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
+ 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
+ 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */
+ 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
+ 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */
+ >;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
new file mode 100644
index 000000000000..206f6d61e362
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320aic3x.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tlv320aic3x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TLV320AIC3x Codec
+
+description: |
+ TLV320AIC3x are a series of low-power stereo audio codecs with stereo
+ headphone amplifier, as well as multiple inputs and outputs programmable in
+ single-ended or fully differential configurations.
+
+ The serial control bus supports SPI or I2C protocols, while the serial audio
+ data bus is programmable for I2S, left/right-justified, DSP, or TDM modes.
+
+ The following pins can be referred in the sound node's audio routing property:
+
+ CODEC output pins:
+ LLOUT
+ RLOUT
+ MONO_LOUT
+ HPLOUT
+ HPROUT
+ HPLCOM
+ HPRCOM
+
+ CODEC input pins for TLV320AIC3104:
+ MIC2L
+ MIC2R
+ LINE1L
+ LINE1R
+
+ CODEC input pins for other compatible codecs:
+ MIC3L
+ MIC3R
+ LINE1L
+ LINE2L
+ LINE1R
+ LINE2R
+
+maintainers:
+ - Jai Luthra <j-luthra@ti.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,tlv320aic3x
+ - ti,tlv320aic33
+ - ti,tlv320aic3007
+ - ti,tlv320aic3106
+ - ti,tlv320aic3104
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO specification for the active low RESET input.
+
+ gpio-reset:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ maxItems: 1
+ description:
+ Deprecated, please use reset-gpios instead.
+ deprecated: true
+
+ ai3x-gpio-func:
+ description: AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+
+ ai3x-micbias-vg:
+ description: MicBias required voltage. If node is omitted then MicBias is powered down.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - const: 1
+ description: MICBIAS output is powered to 2.0V.
+ - const: 2
+ description: MICBIAS output is powered to 2.5V.
+ - const: 3
+ description: MICBIAS output is connected to AVDD.
+
+ ai3x-ocmv:
+ description: Output Common-Mode Voltage selection.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ oneOf:
+ - const: 0
+ description: 1.35V
+ - const: 1
+ description: 1.5V
+ - const: 2
+ description: 1.65V
+ - const: 3
+ description: 1.8V
+
+ AVDD-supply:
+ description: Analog DAC voltage.
+
+ IOVDD-supply:
+ description: I/O voltage.
+
+ DRVDD-supply:
+ description: ADC analog and output driver voltage.
+
+ DVDD-supply:
+ description: Digital core voltage.
+
+ '#sound-dai-cells':
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tlv320aic3x_i2c: audio-codec@1b {
+ compatible = "ti,tlv320aic3x";
+ reg = <0x1b>;
+
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+
+ AVDD-supply = <&regulator>;
+ IOVDD-supply = <&regulator>;
+ DRVDD-supply = <&regulator>;
+ DVDD-supply = <&regulator>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tlv320aic3x_spi: audio-codec@0 {
+ compatible = "ti,tlv320aic3x";
+ reg = <0>; /* CS number */
+ #sound-dai-cells = <0>;
+
+ AVDD-supply = <&regulator>;
+ IOVDD-supply = <&regulator>;
+ DRVDD-supply = <&regulator>;
+ DVDD-supply = <&regulator>;
+ ai3x-ocmv = <0>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320dac3100.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320dac3100.yaml
new file mode 100644
index 000000000000..10299064cbc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tlv320dac3100.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tlv320dac3100.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - tlv320aic31xx Codec module
+
+maintainers:
+ - Shenghao Ding <shenghao-ding@ti.com>
+
+description: |
+ CODEC output pins:
+ * HPL
+ * HPR
+ * SPL, devices with stereo speaker amp
+ * SPR, devices with stereo speaker amp
+ * SPK, devices with mono speaker amp
+ * MICBIAS
+
+ CODEC input pins:
+ * MIC1LP, devices with ADC
+ * MIC1RP, devices with ADC
+ * MIC1LM, devices with ADC
+ * AIN1, devices without ADC
+ * AIN2, devices without ADC
+
+ The pins can be used in referring sound node's audio-routing property.
+
+properties:
+ compatible:
+ enum:
+ - ti,tlv320aic310x # - Generic TLV320AIC31xx with mono speaker amp
+ - ti,tlv320aic311x # - Generic TLV320AIC31xx with stereo speaker amp
+ - ti,tlv320aic3100 # - TLV320AIC3100 (mono speaker amp, no MiniDSP)
+ - ti,tlv320aic3110 # - TLV320AIC3110 (stereo speaker amp, no MiniDSP)
+ - ti,tlv320aic3120 # - TLV320AIC3120 (mono speaker amp, MiniDSP)
+ - ti,tlv320aic3111 # - TLV320AIC3111 (stereo speaker amp, MiniDSP)
+ - ti,tlv320dac3100 # - TLV320DAC3100 (no ADC, mono speaker amp, no MiniDSP)
+ - ti,tlv320dac3101 # - TLV320DAC3101 (no ADC, stereo speaker amp, no MiniDSP)
+
+ reg:
+ maxItems: 1
+
+ '#sound-dai-cells':
+ const: 0
+
+ HPVDD-supply: true
+
+ SPRVDD-supply: true
+
+ SPLVDD-supply: true
+
+ AVDD-supply: true
+
+ IOVDD-supply: true
+
+ DVDD-supply: true
+
+ reset-gpios:
+ description: GPIO specification for the active low RESET input.
+
+ ai31xx-micbias-vg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ enum: [1, 2, 3]
+ description: |
+ MicBias Voltage setting
+ 1 or MICBIAS_2_0V - MICBIAS output is powered to 2.0V
+ 2 or MICBIAS_2_5V - MICBIAS output is powered to 2.5V
+ 3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD
+
+ ai31xx-ocmv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ description: |
+ output common-mode voltage setting
+ 0 - 1.35V,
+ 1 - 1.5V,
+ 2 - 1.65V,
+ 3 - 1.8V
+
+ gpio-reset:
+ description: gpio pin number used for codec reset
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - HPVDD-supply
+ - SPRVDD-supply
+ - SPLVDD-supply
+ - AVDD-supply
+ - IOVDD-supply
+ - DVDD-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/sound/tlv320aic31xx.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sound@18 {
+ compatible = "ti,tlv320aic311x";
+ reg = <0x18>;
+
+ ai31xx-micbias-vg = <MICBIAS_2_0V>;
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+
+ HPVDD-supply = <&regulator>;
+ SPRVDD-supply = <&regulator>;
+ SPLVDD-supply = <&regulator>;
+ AVDD-supply = <&regulator>;
+ IOVDD-supply = <&regulator>;
+ DVDD-supply = <&regulator>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/sound/ti,tpa6130a2.yaml b/Documentation/devicetree/bindings/sound/ti,tpa6130a2.yaml
new file mode 100644
index 000000000000..a42bf9bde694
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tpa6130a2.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,tpa6130a2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - tpa6130a2 Codec module
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description:
+ Stereo, analog input headphone amplifier
+
+properties:
+ compatible:
+ enum:
+ - ti,tpa6130a2
+ - ti,tpa6140a2
+
+ reg:
+ maxItems: 1
+
+ Vdd-supply:
+ description: power supply regulator
+
+ power-gpio:
+ description: gpio pin to power the device
+
+required:
+ - compatible
+ - reg
+ - Vdd-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ amplifier@60 {
+ compatible = "ti,tpa6130a2";
+ reg = <0x60>;
+ Vdd-supply = <&vmmc2>;
+ power-gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/sound/ti,twl4030-audio.yaml b/Documentation/devicetree/bindings/sound/ti,twl4030-audio.yaml
new file mode 100644
index 000000000000..c9c3f7513ad4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,twl4030-audio.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,twl4030-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030-family Audio Module
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description:
+ The audio module within the TWL4030-family of companion chips consists
+ of an audio codec and a vibra driver. This binding describes the parent
+ node for these functions.
+
+properties:
+ compatible:
+ const: ti,twl4030-audio
+
+ codec:
+ type: object
+ description: Node containing properties for the audio codec functionality.
+
+ properties:
+ ti,digimic_delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay in milliseconds after enabling digital microphones to reduce
+ artifacts.
+
+ ti,ramp_delay_value:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Headset ramp delay configuration to reduce pop noise.
+
+ ti,hs_extmute:
+ type: boolean
+ description:
+ Enable the use of an external mute for headset pop reduction.
+
+ ti,hs_extmute_gpio:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ The GPIO specifier for the external mute control.
+ maxItems: 1
+
+ ti,offset_cncl_path:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset cancellation path selection. Refer to the Technical
+ Reference Manual for valid values.
+
+ # The 'codec' node itself is optional, but if it exists, it can be empty.
+ # We don't require any of its sub-properties.
+
+ ti,enable-vibra:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description:
+ Enable or disable the vibra functionality.
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+
+ twl_audio: audio {
+ compatible = "ti,twl4030-audio";
+
+ ti,enable-vibra = <1>;
+
+ codec {
+ ti,ramp_delay_value = <3>;
+ };
+
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
deleted file mode 100644
index ee698614862e..000000000000
--- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
+++ /dev/null
@@ -1,209 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
-# Copyright (C) 2019 Texas Instruments Incorporated
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/tlv320adcx140.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Texas Instruments TLV320ADCX140 Quad Channel Analog-to-Digital Converter
-
-maintainers:
- - Andrew Davis <afd@ti.com>
-
-description: |
- The TLV320ADCX140 are multichannel (4-ch analog recording or 8-ch digital
- PDM microphones recording), high-performance audio, analog-to-digital
- converter (ADC) with analog inputs supporting up to 2V RMS. The TLV320ADCX140
- family supports line and microphone Inputs, and offers a programmable
- microphone bias or supply voltage generation.
-
- Specifications can be found at:
- https://www.ti.com/lit/ds/symlink/tlv320adc3140.pdf
- https://www.ti.com/lit/ds/symlink/tlv320adc5140.pdf
- https://www.ti.com/lit/ds/symlink/tlv320adc6140.pdf
-
-properties:
- compatible:
- enum:
- - ti,tlv320adc3140
- - ti,tlv320adc5140
- - ti,tlv320adc6140
-
- reg:
- maxItems: 1
- description: |
- I2C addresss of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f
-
- reset-gpios:
- maxItems: 1
- description: |
- GPIO used for hardware reset.
-
- areg-supply:
- description: |
- Regulator with AVDD at 3.3V. If not defined then the internal regulator
- is enabled.
-
- ti,mic-bias-source:
- description: |
- Indicates the source for MIC Bias.
- 0 - Mic bias is set to VREF
- 1 - Mic bias is set to VREF × 1.096
- 6 - Mic bias is set to AVDD
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 6]
-
- ti,vref-source:
- description: |
- Indicates the source for MIC Bias.
- 0 - Set VREF to 2.75V
- 1 - Set VREF to 2.5V
- 2 - Set VREF to 1.375V
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
-
- ti,pdm-edge-select:
- description: |
- Defines the PDMCLK sampling edge configuration for the PDM inputs. This
- array is defined as <PDMIN1 PDMIN2 PDMIN3 PDMIN4>.
-
- 0 - (default) Odd channel is latched on the negative edge and even
- channel is latched on the positive edge.
- 1 - Odd channel is latched on the positive edge and even channel is
- latched on the negative edge.
-
- PDMIN1 - PDMCLK latching edge used for channel 1 and 2 data
- PDMIN2 - PDMCLK latching edge used for channel 3 and 4 data
- PDMIN3 - PDMCLK latching edge used for channel 5 and 6 data
- PDMIN4 - PDMCLK latching edge used for channel 7 and 8 data
-
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 4
- items:
- maximum: 1
- default: [0, 0, 0, 0]
-
- ti,gpi-config:
- description: |
- Defines the configuration for the general purpose input pins (GPI).
- The array is defined as <GPI1 GPI2 GPI3 GPI4>.
-
- 0 - (default) disabled
- 1 - GPIX is configured as a general-purpose input (GPI)
- 2 - GPIX is configured as a master clock input (MCLK)
- 3 - GPIX is configured as an ASI input for daisy-chain (SDIN)
- 4 - GPIX is configured as a PDM data input for channel 1 and channel
- (PDMDIN1)
- 5 - GPIX is configured as a PDM data input for channel 3 and channel
- (PDMDIN2)
- 6 - GPIX is configured as a PDM data input for channel 5 and channel
- (PDMDIN3)
- 7 - GPIX is configured as a PDM data input for channel 7 and channel
- (PDMDIN4)
-
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 4
- items:
- maximum: 7
- default: [0, 0, 0, 0]
-
- ti,asi-tx-drive:
- type: boolean
- description: |
- When set the device will set the Tx ASI output to a Hi-Z state for unused
- data cycles. Default is to drive the output low on unused ASI cycles.
-
-patternProperties:
- '^ti,gpo-config-[1-4]$':
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: |
- Defines the configuration and output driver for the general purpose
- output pins (GPO). These values are pairs, the first value is for the
- configuration type and the second value is for the output drive type.
- The array is defined as <GPO_CFG GPO_DRV>
-
- GPO output configuration can be one of the following:
-
- 0 - (default) disabled
- 1 - GPOX is configured as a general-purpose output (GPO)
- 2 - GPOX is configured as a device interrupt output (IRQ)
- 3 - GPOX is configured as a secondary ASI output (SDOUT2)
- 4 - GPOX is configured as a PDM clock output (PDMCLK)
-
- GPO output drive configuration for the GPO pins can be one of the following:
-
- 0d - (default) Hi-Z output
- 1d - Drive active low and active high
- 2d - Drive active low and weak high
- 3d - Drive active low and Hi-Z
- 4d - Drive weak low and active high
- 5d - Drive Hi-Z and active high
-
- ti,gpio-config:
- description: |
- Defines the configuration and output drive for the General Purpose
- Input and Output pin (GPIO1). Its value is a pair, the first value is for
- the configuration type and the second value is for the output drive
- type. The array is defined as <GPIO1_CFG GPIO1_DRV>
-
- configuration for the GPIO pin can be one of the following:
- 0 - disabled
- 1 - GPIO1 is configured as a general-purpose output (GPO)
- 2 - (default) GPIO1 is configured as a device interrupt output (IRQ)
- 3 - GPIO1 is configured as a secondary ASI output (SDOUT2)
- 4 - GPIO1 is configured as a PDM clock output (PDMCLK)
- 8 - GPIO1 is configured as an input to control when MICBIAS turns on or
- off (MICBIAS_EN)
- 9 - GPIO1 is configured as a general-purpose input (GPI)
- 10 - GPIO1 is configured as a master clock input (MCLK)
- 11 - GPIO1 is configured as an ASI input for daisy-chain (SDIN)
- 12 - GPIO1 is configured as a PDM data input for channel 1 and channel 2
- (PDMDIN1)
- 13 - GPIO1 is configured as a PDM data input for channel 3 and channel 4
- (PDMDIN2)
- 14 - GPIO1 is configured as a PDM data input for channel 5 and channel 6
- (PDMDIN3)
- 15 - GPIO1 is configured as a PDM data input for channel 7 and channel 8
- (PDMDIN4)
-
- output drive type for the GPIO pin can be one of the following:
- 0 - Hi-Z output
- 1 - Drive active low and active high
- 2 - (default) Drive active low and weak high
- 3 - Drive active low and Hi-Z
- 4 - Drive weak low and active high
- 5 - Drive Hi-Z and active high
-
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 2
- maxItems: 2
- items:
- maximum: 15
- default: [2, 2]
-
-required:
- - compatible
- - reg
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- i2c0 {
- #address-cells = <1>;
- #size-cells = <0>;
- codec: codec@4c {
- compatible = "ti,tlv320adc5140";
- reg = <0x4c>;
- ti,mic-bias-source = <6>;
- ti,pdm-edge-select = <0 1 0 1>;
- ti,gpi-config = <4 5 6 7>;
- ti,gpio-config = <10 2>;
- ti,gpo-config-1 = <0 0>;
- ti,gpo-config-2 = <0 0>;
- reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
deleted file mode 100644
index bbad98d5b986..000000000000
--- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Texas Instruments - tlv320aic31xx Codec module
-
-The tlv320aic31xx serial control bus communicates through I2C protocols
-
-Required properties:
-
-- compatible - "string" - One of:
- "ti,tlv320aic310x" - Generic TLV320AIC31xx with mono speaker amp
- "ti,tlv320aic311x" - Generic TLV320AIC31xx with stereo speaker amp
- "ti,tlv320aic3100" - TLV320AIC3100 (mono speaker amp, no MiniDSP)
- "ti,tlv320aic3110" - TLV320AIC3110 (stereo speaker amp, no MiniDSP)
- "ti,tlv320aic3120" - TLV320AIC3120 (mono speaker amp, MiniDSP)
- "ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP)
- "ti,tlv320dac3100" - TLV320DAC3100 (no ADC, mono speaker amp, no MiniDSP)
- "ti,tlv320dac3101" - TLV320DAC3101 (no ADC, stereo speaker amp, no MiniDSP)
-
-- reg - <int> - I2C slave address
-- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
- DVDD-supply : power supplies for the device as covered in
- Documentation/devicetree/bindings/regulator/regulator.txt
-
-
-Optional properties:
-
-- reset-gpios - GPIO specification for the active low RESET input.
-- ai31xx-micbias-vg - MicBias Voltage setting
- 1 or MICBIAS_2_0V - MICBIAS output is powered to 2.0V
- 2 or MICBIAS_2_5V - MICBIAS output is powered to 2.5V
- 3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD
- If this node is not mentioned or if the value is unknown, then
- micbias is set to 2.0V.
-- ai31xx-ocmv - output common-mode voltage setting
- 0 - 1.35V,
- 1 - 1.5V,
- 2 - 1.65V,
- 3 - 1.8V
-
-Deprecated properties:
-
-- gpio-reset - gpio pin number used for codec reset
-
-CODEC output pins:
- * HPL
- * HPR
- * SPL, devices with stereo speaker amp
- * SPR, devices with stereo speaker amp
- * SPK, devices with mono speaker amp
- * MICBIAS
-
-CODEC input pins:
- * MIC1LP, devices with ADC
- * MIC1RP, devices with ADC
- * MIC1LM, devices with ADC
- * AIN1, devices without ADC
- * AIN2, devices without ADC
-
-The pins can be used in referring sound node's audio-routing property.
-
-Example:
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/sound/tlv320aic31xx.h>
-
-tlv320aic31xx: tlv320aic31xx@18 {
- compatible = "ti,tlv320aic311x";
- reg = <0x18>;
-
- ai31xx-micbias-vg = <MICBIAS_OFF>;
-
- reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
-
- HPVDD-supply = <&regulator>;
- SPRVDD-supply = <&regulator>;
- SPLVDD-supply = <&regulator>;
- AVDD-supply = <&regulator>;
- IOVDD-supply = <&regulator>;
- DVDD-supply = <&regulator>;
-};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt
deleted file mode 100644
index f59125bc79d1..000000000000
--- a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Texas Instruments - tlv320aic32x4 Codec module
-
-The tlv320aic32x4 serial control bus communicates through I2C protocols
-
-Required properties:
- - compatible - "string" - One of:
- "ti,tlv320aic32x4" TLV320AIC3204
- "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256
- "ti,tas2505" TAS2505, TAS2521
- - reg: I2C slave address
- - supply-*: Required supply regulators are:
- "iov" - digital IO power supply
- "ldoin" - LDO power supply
- "dv" - Digital core power supply
- "av" - Analog core power supply
- If you supply ldoin, dv and av are optional. Otherwise they are required
- See regulator/regulator.txt for more information about the detailed binding
- format.
-
-Optional properties:
- - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt
- - clocks/clock-names: Clock named 'mclk' for the master clock of the codec.
- See clock/clock-bindings.txt for information about the detailed format.
- - aic32x4-gpio-func - <array of 5 int>
- - Types are defined in include/sound/tlv320aic32x4.h
-
-
-Example:
-
-codec: tlv320aic32x4@18 {
- compatible = "ti,tlv320aic32x4";
- reg = <0x18>;
- clocks = <&clks 201>;
- clock-names = "mclk";
- aic32x4-gpio-func= <
- 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
- 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
- 0x04 /* MFP3 AIC32X4_MFP3_GPIO_ENABLED */
- 0xff /* AIC32X4_MFPX_DEFAULT_VALUE */
- 0x08 /* MFP5 AIC32X4_MFP5_GPIO_INPUT */
- >;
-};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
deleted file mode 100644
index 20931a63fd64..000000000000
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Texas Instruments - tlv320aic3x Codec module
-
-The tlv320aic3x serial control bus communicates through both I2C and SPI bus protocols
-
-Required properties:
-
-- compatible - "string" - One of:
- "ti,tlv320aic3x" - Generic TLV320AIC3x device
- "ti,tlv320aic33" - TLV320AIC33
- "ti,tlv320aic3007" - TLV320AIC3007
- "ti,tlv320aic3106" - TLV320AIC3106
- "ti,tlv320aic3104" - TLV320AIC3104
-
-
-- reg - <int> - I2C slave address
-
-
-Optional properties:
-
-- reset-gpios - GPIO specification for the active low RESET input.
-- ai3x-gpio-func - <array of 2 int> - AIC3X_GPIO1 & AIC3X_GPIO2 Functionality
- - Not supported on tlv320aic3104
-- ai3x-micbias-vg - MicBias Voltage required.
- 1 - MICBIAS output is powered to 2.0V,
- 2 - MICBIAS output is powered to 2.5V,
- 3 - MICBIAS output is connected to AVDD,
- If this node is not mentioned or if the value is incorrect, then MicBias
- is powered down.
-- ai3x-ocmv - Output Common-Mode Voltage selection:
- 0 - 1.35V,
- 1 - 1.5V,
- 2 - 1.65V,
- 3 - 1.8V
-- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the
- device as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
-Deprecated properties:
-
-- gpio-reset - gpio pin number used for codec reset
-
-CODEC output pins:
- * LLOUT
- * RLOUT
- * MONO_LOUT
- * HPLOUT
- * HPROUT
- * HPLCOM
- * HPRCOM
-
-CODEC input pins for TLV320AIC3104:
- * MIC2L
- * MIC2R
- * LINE1L
- * LINE1R
-
-CODEC input pins for other compatible codecs:
- * MIC3L
- * MIC3R
- * LINE1L
- * LINE2L
- * LINE1R
- * LINE2R
-
-The pins can be used in referring sound node's audio-routing property.
-
-I2C example:
-
-#include <dt-bindings/gpio/gpio.h>
-
-tlv320aic3x: tlv320aic3x@1b {
- compatible = "ti,tlv320aic3x";
- reg = <0x1b>;
-
- reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
-
- AVDD-supply = <&regulator>;
- IOVDD-supply = <&regulator>;
- DRVDD-supply = <&regulator>;
- DVDD-supply = <&regulator>;
-};
-
-SPI example:
-
-spi0: spi@f0000000 {
- tlv320aic3x: codec@0 {
- compatible = "ti,tlv320aic3x";
- reg = <0>; /* CS number */
- #sound-dai-cells = <0>;
- spi-max-frequency = <1000000>;
-
- AVDD-supply = <&regulator>;
- IOVDD-supply = <&regulator>;
- DRVDD-supply = <&regulator>;
- DVDD-supply = <&regulator>;
- ai3x-ocmv = <0>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/tpa6130a2.txt b/Documentation/devicetree/bindings/sound/tpa6130a2.txt
deleted file mode 100644
index 6dfa740e4b2d..000000000000
--- a/Documentation/devicetree/bindings/sound/tpa6130a2.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Texas Instruments - tpa6130a2 Codec module
-
-The tpa6130a2 serial control bus communicates through I2C protocols
-
-Required properties:
-
-- compatible - "string" - One of:
- "ti,tpa6130a2" - TPA6130A2
- "ti,tpa6140a2" - TPA6140A2
-
-
-- reg - <int> - I2C slave address
-
-- Vdd-supply - <phandle> - power supply regulator
-
-Optional properties:
-
-- power-gpio - gpio pin to power the device
-
-Example:
-
-tpa6130a2: tpa6130a2@60 {
- compatible = "ti,tpa6130a2";
- reg = <0x60>;
- Vdd-supply = <&vmmc2>;
- power-gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/sound/trivial-codec.yaml b/Documentation/devicetree/bindings/sound/trivial-codec.yaml
new file mode 100644
index 000000000000..9a35dfb17349
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/trivial-codec.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/trivial-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trivial Audio Codec
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ # Analog Devices SSM2602 I2S audio CODEC devices
+ - adi,ssm2602
+ - adi,ssm2603
+ - adi,ssm2604
+ - adi,ssm3515
+ # Cirrus Logic CS4265 audio DAC
+ - cirrus,cs4265
+ - cirrus,cs4341a
+ - cirrus,cs4349
+ - dlg,da9055-codec
+ # Nuvoton Technology Corporation NAU85L40 Audio CODEC
+ - nuvoton,nau8540
+ - nuvoton,nau8810
+ - nuvoton,nau8812
+ - nuvoton,nau8814
+ # NXP TFA9879 class-D audio amplifier
+ - nxp,tfa9879
+ - nxp,uda1342
+ - sdw3019f836300
+ - ti,pcm1789
+ - ti,pcm1792a
+ - ti,pcm5102a
+ - wlf,wm8510
+ - wlf,wm8523
+ - wlf,wm8580
+ - wlf,wm8581
+ - wlf,wm8711
+ - wlf,wm8728
+ - wlf,wm8737
+ - wlf,wm8750
+ - wlf,wm8753
+ - wlf,wm8770
+ - wlf,wm8776
+ - wlf,wm8961
+ - wlf,wm8974
+ - wlf,wm8987
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ codec@1a {
+ compatible = "wlf,wm8523";
+ reg = <0x1a>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,arizona.yaml b/Documentation/devicetree/bindings/sound/wlf,arizona.yaml
index 1627c0bb69be..8156f30eadd6 100644
--- a/Documentation/devicetree/bindings/sound/wlf,arizona.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,arizona.yaml
@@ -16,6 +16,9 @@ description: |
This document lists sound specific bindings, see the primary binding
document ../mfd/arizona.yaml
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
'#sound-dai-cells':
description:
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml
new file mode 100644
index 000000000000..4d951ece394e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8524.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM8524 24-bit 192KHz Stereo DAC
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: wlf,wm8524
+
+ "#sound-dai-cells":
+ const: 0
+
+ wlf,mute-gpios:
+ maxItems: 1
+ description:
+ a GPIO spec for the MUTE pin.
+
+required:
+ - compatible
+ - wlf,mute-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ wm8524: codec {
+ compatible = "wlf,wm8524";
+ wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml
index 15795f63b5a3..858c0f689581 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8731.yaml
@@ -61,6 +61,7 @@ required:
- DCVDD-supply
allOf:
+ - $ref: dai-common.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8782.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8782.yaml
new file mode 100644
index 000000000000..d0bbdc9f9ced
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8782.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8782.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson Microelectromics WM8782 audio CODEC
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: wlf,wm8782
+
+ Vdda-supply:
+ description: Regulator for the analog power supply (2.7V - 5.5V)
+
+ Vdd-supply:
+ description: Regulator for the digital power supply (2.7V - 3.6V)
+
+ wlf,fsampen:
+ description: FSAMPEN pin value, 0 for low, 1 for high, 2 for disconnected.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2]
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - Vdda-supply
+ - Vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ wm8782: codec {
+ compatible = "wlf,wm8782";
+ Vdda-supply = <&vdda_supply>;
+ Vdd-supply = <&vdd_supply>;
+ wlf,fsampen = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8804.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8804.yaml
new file mode 100644
index 000000000000..3c060179f06e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8804.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8804.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: WM8804 audio codec
+
+description: |
+ This device supports both I2C and SPI (configured with pin strapping on the
+ board).
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+properties:
+ compatible:
+ const: wlf,wm8804
+
+ reg:
+ description:
+ The I2C address of the device for I2C, the chip select number for SPI.
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ PVDD-supply:
+ description: PLL core supply
+
+ DVDD-supply:
+ description: Digital core supply
+
+ wlf,reset-gpio:
+ description: A GPIO specifier for the GPIO controlling the reset pin.
+ maxItems: 1
+
+required:
+ - reg
+ - compatible
+ - PVDD-supply
+ - DVDD-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "wlf,wm8804";
+ reg = <0x1a>;
+ PVDD-supply = <&pvdd_reg>;
+ DVDD-supply = <&dvdd_reg>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml
index 7105ed5fd6c7..089b67384797 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/sound/wlf,wm8903.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/sound/wlf,wm8903.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: WM8903 audio codec
@@ -75,7 +75,6 @@ properties:
DCVDD-supply:
description: Digital core supply regulator for the DCVDD pin.
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml
new file mode 100644
index 000000000000..3029a868e5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml
@@ -0,0 +1,203 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8904.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM8904/WM8912 audio codecs
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description: |
+ Pins on the device (for linking into audio routes):
+ IN1L, IN1R, IN2L, IN2R, IN3L, IN3R, HPOUTL, HPOUTR, LINEOUTL, LINEOUTR,
+ MICBIAS
+
+properties:
+ compatible:
+ enum:
+ - wlf,wm8904
+ - wlf,wm8912
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: mclk
+
+ AVDD-supply: true
+ CPVDD-supply: true
+ DBVDD-supply: true
+ DCVDD-supply: true
+ MICVDD-supply: true
+
+ wlf,in1l-as-dmicdat1:
+ type: boolean
+ description:
+ Use IN1L/DMICDAT1 as DMICDAT1, enabling the DMIC input path.
+ Can be used separately or together with wlf,in1r-as-dmicdat2.
+
+ wlf,in1r-as-dmicdat2:
+ type: boolean
+ description:
+ Use IN1R/DMICDAT2 as DMICDAT2, enabling the DMIC input path.
+ Can be used separately or together with wlf,in1l-as-dmicdat1.
+
+ wlf,gpio-cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+ description:
+ Default register values for R121/122/123/124 (GPIO Control).
+ If any entry has the value 0xFFFF, the related register won't be set.
+ default: [0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF]
+
+ wlf,micbias-cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+ description:
+ Default register values for R6/R7 (Mic Bias Control).
+ default: [0, 0]
+
+ wlf,drc-cfg-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+ List of strings for the available DRC modes.
+ If absent, DRC is disabled.
+
+ wlf,drc-cfg-regs:
+ $ref: /schemas/types.yaml#/definitions/uint16-matrix
+ description:
+ Sets of default register values for R40/41/42/43 (DRC).
+ Each set corresponds to a DRC mode, so the number of sets should equal
+ the length of wlf,drc-cfg-names.
+ If absent, DRC is disabled.
+ items:
+ minItems: 4
+ maxItems: 4
+
+ wlf,retune-mobile-cfg-names:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description:
+ List of strings for the available retune modes.
+ If absent, retune is disabled.
+
+ wlf,retune-mobile-cfg-hz:
+ description:
+ The list must be the same length as wlf,retune-mobile-cfg-names.
+ If absent, retune is disabled.
+
+ wlf,retune-mobile-cfg-regs:
+ $ref: /schemas/types.yaml#/definitions/uint16-matrix
+ description:
+ Sets of default register values for R134/.../157 (EQ).
+ Each set corresponds to a retune mode, so the number of sets should equal
+ the length of wlf,retune-mobile-cfg-names.
+ If absent, retune is disabled.
+ items:
+ minItems: 24
+ maxItems: 24
+
+dependencies:
+ wlf,drc-cfg-names: [ 'wlf,drc-cfg-regs' ]
+ wlf,drc-cfg-regs: [ 'wlf,drc-cfg-names' ]
+
+ wlf,retune-mobile-cfg-names: [ 'wlf,retune-mobile-cfg-hz', 'wlf,retune-mobile-cfg-regs' ]
+ wlf,retune-mobile-cfg-regs: [ 'wlf,retune-mobile-cfg-names', 'wlf,retune-mobile-cfg-hz' ]
+ wlf,retune-mobile-cfg-hz: [ 'wlf,retune-mobile-cfg-names', 'wlf,retune-mobile-cfg-regs' ]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - AVDD-supply
+ - CPVDD-supply
+ - DBVDD-supply
+ - DCVDD-supply
+ - MICVDD-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ AVDD-supply = <&reg_1p8v>;
+ CPVDD-supply = <&reg_1p8v>;
+ DBVDD-supply = <&reg_1p8v>;
+ DCVDD-supply = <&reg_1p8v>;
+ MICVDD-supply = <&reg_1p8v>;
+
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition", "soft",
+ "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+
+ /* Use IN1R as DMICDAT2, leave IN1L as an analog input path */
+ wlf,in1r-as-dmicdat2;
+
+ wlf,retune-mobile-cfg-names = "bassboost", "bassboost", "treble";
+ wlf,retune-mobile-cfg-hz = <48000>, <44100>, <48000>;
+ /*
+ * Config registers per name, respectively:
+ * EQ_ENA, 100 Hz, 300 Hz, 875 Hz, 2400 Hz, 6900 Hz
+ * 1, +6 dB, +3 dB, 0 dB, 0 dB, 0 dB
+ * 1, +6 dB, +3 dB, 0 dB, 0 dB, 0 dB
+ * 1, -2 dB, -2 dB, 0 dB, 0 dB, +3 dB
+ * Each one uses the defaults for ReTune Mobile registers 140-157
+ */
+ wlf,retune-mobile-cfg-regs = /bits/ 16 <0x1 0x12 0xf 0xc 0xc 0xc
+ 0x0fca 0x0400 0x00d8 0x1eb5
+ 0xf145 0x0bd5 0x0075 0x1c58
+ 0xf3d3 0x0a54 0x0568 0x168e
+ 0xf829 0x07ad 0x1103 0x0564
+ 0x0559 0x4000>,
+
+ /bits/ 16 <0x1 0x12 0xf 0xc 0xc 0xc
+ 0x0fca 0x0400 0x00d8 0x1eb5
+ 0xf145 0x0bd5 0x0075 0x1c58
+ 0xf3d3 0x0a54 0x0568 0x168e
+ 0xf829 0x07ad 0x1103 0x0564
+ 0x0559 0x4000>,
+
+ /bits/ 16 <0x1 0xa 0xa 0xc 0xc 0xf
+ 0x0fca 0x0400 0x00d8 0x1eb5
+ 0xf145 0x0bd5 0x0075 0x1c58
+ 0xf3d3 0x0a54 0x0568 0x168e
+ 0xf829 0x07ad 0x1103 0x0564
+ 0x0559 0x4000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8940.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8940.yaml
index 8aadcbeed502..3e809217c4ca 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8940.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8940.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/wlf,wm8940.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Wolfson WM8940 Codec Device Tree Bindings
+title: Wolfson WM8940 Codec
maintainers:
- patches@opensource.cirrus.com
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
'#sound-dai-cells':
const: 0
@@ -27,7 +30,7 @@ required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml
new file mode 100644
index 000000000000..c8c786cb6c4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM8960 audio codec
+
+maintainers:
+ - patches@opensource.cirrus.com
+
+description: |
+ Wolfson WM8960 audio codec
+
+ Pins on the device (for linking into audio routes):
+
+ Outputs:
+ * HP_L : Left Headphone/Line Output
+ * HP_R : Right Headphone/Line Output
+ * SPK_LP : Left Speaker Output (Positive)
+ * SPK_LN : Left Speaker Output (Negative)
+ * SPK_RP : Right Speaker Output (Positive)
+ * SPK_RN : Right Speaker Output (Negative)
+ * OUT3 : Mono, Left, Right or buffered midrail output for capless mode
+
+ Inputs:
+ * LINPUT1 : Left single-ended or negative differential microphone input
+ * RINPUT1 : Right single-ended or negative differential microphone input
+ * LINPUT2 : Left line input or positive differential microphone input
+ * RINPUT2 : Right line input or positive differential microphone input
+ * LINPUT3 : Left line input, positive differential microphone, or Jack Detect 2
+ * RINPUT3 : Right line input, positive differential microphone, or Jack Detect 3
+
+properties:
+ compatible:
+ const: wlf,wm8960
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mclk
+
+ '#sound-dai-cells':
+ const: 0
+
+ AVDD-supply:
+ description: Analogue supply.
+
+ DBVDD-supply:
+ description: Digital Buffer Supply.
+
+ DCVDD-supply:
+ description: Digital Core Supply.
+
+ SPKVDD1-supply:
+ description: Supply for speaker drivers 1.
+
+ SPKVDD2-supply:
+ description: Supply for speaker drivers 2.
+
+ wlf,capless:
+ type: boolean
+ description:
+ If present, OUT3 pin will be enabled and disabled together with HP_L and
+ HP_R pins in response to jack detect events.
+
+ wlf,gpio-cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ description: |
+ A list of GPIO configuration register values.
+ - gpio-cfg[0]: ALRCGPIO of R9 (Audio interface)
+ - gpio-cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4).
+
+ wlf,hp-cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 3
+ description: |
+ A list of headphone jack detect configuration register values:
+ - hp-cfg[0]: HPSEL[1:0] of R48 (Additional Control 4).
+ - hp-cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2).
+ - hp-cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1).
+
+ wlf,shared-lrclk:
+ type: boolean
+ description:
+ If present, the LRCM bit of R24 (Additional control 2) gets set,
+ indicating that ADCLRC and DACLRC pins will be disabled only when ADC
+ (Left and Right) and DAC (Left and Right) are disabled.
+ When WM8960 works on synchronize mode and DACLRC pin is used to supply
+ frame clock, it will no frame clock for captrue unless enable DAC to
+ enable DACLRC pin. If shared-lrclk is present, no need to enable DAC for
+ captrue.
+
+ port:
+ $ref: audio-graph-port.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: dai-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ clocks = <&clks 0>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ wlf,hp-cfg = <3 2 3>;
+ wlf,gpio-cfg = <1 3>;
+ wlf,shared-lrclk;
+ DCVDD-supply = <&reg_audio>;
+ DBVDD-supply = <&reg_audio>;
+ AVDD-supply = <&reg_audio>;
+ SPKVDD1-supply = <&reg_audio>;
+ SPKVDD2-supply = <&reg_audio>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml
index 5e172e9462b9..5fe0b2c9f99f 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml
@@ -9,6 +9,9 @@ title: Wolfson WM8962 Ultra-Low Power Stereo CODEC
maintainers:
- patches@opensource.cirrus.com
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
compatible:
const: wlf,wm8962
@@ -87,7 +90,7 @@ required:
- SPKVDD1-supply
- SPKVDD2-supply
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
deleted file mode 100644
index 01d3a7c83419..000000000000
--- a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-WM8974 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
- - compatible: "wlf,wm8974"
- - reg: the I2C address or SPI chip select number of the device
-
-Examples:
-
-codec: wm8974@1a {
- compatible = "wlf,wm8974";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
index 96cf9fc9c8b0..efb5f9f6cc7a 100644
--- a/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
@@ -4,11 +4,14 @@
$id: http://devicetree.org/schemas/sound/wlf,wm8978.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Wolfson WM8978 Codec Device Tree Bindings
+title: Wolfson WM8978 Codec
maintainers:
- patches@opensource.cirrus.com
+allOf:
+ - $ref: dai-common.yaml#
+
properties:
'#sound-dai-cells':
const: 0
@@ -27,7 +30,7 @@ required:
- compatible
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8994.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8994.yaml
new file mode 100644
index 000000000000..0db04a90ac6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8994.yaml
@@ -0,0 +1,194 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/wlf,wm8994.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Wolfson WM1811/WM8994/WM8958 audio codecs
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@kernel.org>
+ - patches@opensource.cirrus.com
+
+description: |
+ These devices support both I2C and SPI (configured with pin strapping on the
+ board).
+
+ Pins on the device (for linking into audio routes):
+ IN1LN, IN1LP, IN2LN, IN2LP:VXRN, IN1RN, IN1RP, IN2RN, IN2RP:VXRP, SPKOUTLP,
+ SPKOUTLN, SPKOUTRP, SPKOUTRN, HPOUT1L, HPOUT1R, HPOUT2P, HPOUT2N, LINEOUT1P,
+ LINEOUT1N, LINEOUT2P, LINEOUT2N.
+
+properties:
+ compatible:
+ enum:
+ - wlf,wm1811
+ - wlf,wm8994
+ - wlf,wm8958
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: MCLK1
+ - const: MCLK2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 2
+ description:
+ The first cell is the IRQ number. The second cell is the flags, encoded
+ as the trigger masks.
+
+ AVDD1-supply: true
+ AVDD2-supply: true
+ CPVDD-supply: true
+ DBVDD-supply: true
+ DBVDD1-supply: true
+ DBVDD2-supply: true
+ DBVDD3-supply: true
+ DCVDD-supply: true
+ LDO1VDD-supply: true
+ LDO2VDD-supply: true
+ SPKVDD1-supply: true
+ SPKVDD2-supply: true
+
+ '#sound-dai-cells':
+ const: 0
+
+ wlf,gpio-cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 11
+ description:
+ A list of GPIO configuration register values. If absent, no configuration
+ of these registers is performed. If any value is over 0xffff then the
+ register will be left as default. If present 11 values must be supplied.
+
+ wlf,micbias-cfg:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ maxItems: 2
+ description:
+ Two MICBIAS register values for WM1811 or WM8958. If absent the register
+ defaults will be used.
+
+ wlf,ldo1ena-gpios:
+ maxItems: 1
+ description:
+ Control of LDO1ENA input to device.
+
+ wlf,ldo2ena-gpios:
+ maxItems: 1
+ description:
+ Control of LDO2ENA input to device.
+
+ wlf,lineout1-se:
+ type: boolean
+ description:
+ LINEOUT1 is in single ended mode.
+
+ wlf,lineout2-se:
+ type: boolean
+ description:
+ INEOUT2 is in single ended mode.
+
+ wlf,lineout1-feedback:
+ type: boolean
+ description:
+ LINEOUT1 has common mode feedback connected.
+
+ wlf,lineout2-feedback:
+ type: boolean
+ description:
+ LINEOUT2 has common mode feedback connected.
+
+ wlf,ldoena-always-driven:
+ type: boolean
+ description:
+ LDOENA is always driven.
+
+ wlf,spkmode-pu:
+ type: boolean
+ description:
+ Enable the internal pull-up resistor on the SPKMODE pin.
+
+ wlf,csnaddr-pd:
+ type: boolean
+ description:
+ Enable the internal pull-down resistor on the CS/ADDR pin.
+
+required:
+ - compatible
+ - reg
+ - AVDD2-supply
+ - CPVDD-supply
+ - SPKVDD1-supply
+ - SPKVDD2-supply
+
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - wlf,wm1811
+ - wlf,wm8958
+ then:
+ properties:
+ DBVDD-supply: false
+ LDO2VDD-supply: false
+ required:
+ - DBVDD1-supply
+ - DBVDD2-supply
+ - DBVDD3-supply
+ else:
+ properties:
+ DBVDD1-supply: false
+ DBVDD2-supply: false
+ DBVDD3-supply: false
+ required:
+ - DBVDD-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@1a {
+ compatible = "wlf,wm1811";
+ reg = <0x1a>;
+ clocks = <&i2s0 0>;
+ clock-names = "MCLK1";
+
+ AVDD2-supply = <&main_dc_reg>;
+ CPVDD-supply = <&main_dc_reg>;
+ DBVDD1-supply = <&main_dc_reg>;
+ DBVDD2-supply = <&main_dc_reg>;
+ DBVDD3-supply = <&main_dc_reg>;
+ LDO1VDD-supply = <&main_dc_reg>;
+ SPKVDD1-supply = <&main_dc_reg>;
+ SPKVDD2-supply = <&main_dc_reg>;
+
+ wlf,ldo1ena-gpios = <&gpb0 0 GPIO_ACTIVE_HIGH>;
+ wlf,ldo2ena-gpios = <&gpb0 1 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wm8510.txt b/Documentation/devicetree/bindings/sound/wm8510.txt
deleted file mode 100644
index e6b6cc041f89..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8510.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-WM8510 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8510"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Example:
-
-wm8510: codec@1a {
- compatible = "wlf,wm8510";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8523.txt b/Documentation/devicetree/bindings/sound/wm8523.txt
deleted file mode 100644
index f3a6485f4b8a..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8523.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-WM8523 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "wlf,wm8523"
-
- - reg : the I2C address of the device.
-
-Example:
-
-wm8523: codec@1a {
- compatible = "wlf,wm8523";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8524.txt b/Documentation/devicetree/bindings/sound/wm8524.txt
deleted file mode 100644
index f6c0c263b135..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8524.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-WM8524 audio CODEC
-
-This device does not use I2C or SPI but a simple Hardware Control Interface.
-
-Required properties:
-
- - compatible : "wlf,wm8524"
-
- - wlf,mute-gpios: a GPIO spec for the MUTE pin.
-
-Example:
-
-wm8524: codec {
- compatible = "wlf,wm8524";
- wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8580.txt b/Documentation/devicetree/bindings/sound/wm8580.txt
deleted file mode 100644
index ff3f9f5f2111..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8580.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-WM8580 and WM8581 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "wlf,wm8580", "wlf,wm8581"
-
- - reg : the I2C address of the device.
-
-Example:
-
-wm8580: codec@1a {
- compatible = "wlf,wm8580";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8711.txt b/Documentation/devicetree/bindings/sound/wm8711.txt
deleted file mode 100644
index c30a1387c4bf..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8711.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-WM8711 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8711"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Example:
-
-wm8711: codec@1a {
- compatible = "wlf,wm8711";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8728.txt b/Documentation/devicetree/bindings/sound/wm8728.txt
deleted file mode 100644
index a3608b4c78b9..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8728.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-WM8728 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8728"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Example:
-
-wm8728: codec@1a {
- compatible = "wlf,wm8728";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8737.txt b/Documentation/devicetree/bindings/sound/wm8737.txt
deleted file mode 100644
index eda1ec6a7563..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8737.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-WM8737 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8737"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Example:
-
-wm8737: codec@1a {
- compatible = "wlf,wm8737";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8750.yaml b/Documentation/devicetree/bindings/sound/wm8750.yaml
deleted file mode 100644
index 24246ac7bbdf..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8750.yaml
+++ /dev/null
@@ -1,42 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/wm8750.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: WM8750 and WM8987 audio CODECs
-
-description: |
- These devices support both I2C and SPI (configured with pin strapping
- on the board).
-
-maintainers:
- - Mark Brown <broonie@kernel.org>
-
-properties:
- compatible:
- enum:
- - wlf,wm8750
- - wlf,wm8987
-
- reg:
- description:
- The I2C address of the device for I2C, the chip select number for SPI
- maxItems: 1
-
-additionalProperties: false
-
-required:
- - reg
-
-examples:
- - |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- codec@1a {
- compatible = "wlf,wm8750";
- reg = <0x1a>;
- };
- };
diff --git a/Documentation/devicetree/bindings/sound/wm8753.txt b/Documentation/devicetree/bindings/sound/wm8753.txt
deleted file mode 100644
index eca9e5a825a9..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8753.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-WM8753 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8753"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Pins on the device (for linking into audio routes):
-
- * LOUT1
- * LOUT2
- * ROUT1
- * ROUT2
- * MONO1
- * MONO2
- * OUT3
- * OUT4
- * LINE1
- * LINE2
- * RXP
- * RXN
- * ACIN
- * ACOP
- * MIC1N
- * MIC1
- * MIC2N
- * MIC2
- * Mic Bias
-
-Example:
-
-wm8753: codec@1a {
- compatible = "wlf,wm8753";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8770.txt b/Documentation/devicetree/bindings/sound/wm8770.txt
deleted file mode 100644
index cac762a1105d..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8770.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-WM8770 audio CODEC
-
-This device supports SPI.
-
-Required properties:
-
- - compatible : "wlf,wm8770"
-
- - reg : the chip select number.
-
-Example:
-
-wm8770: codec@1 {
- compatible = "wlf,wm8770";
- reg = <1>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8776.txt b/Documentation/devicetree/bindings/sound/wm8776.txt
deleted file mode 100644
index 01173369c3ed..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8776.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-WM8776 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8776"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
-Example:
-
-wm8776: codec@1a {
- compatible = "wlf,wm8776";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8782.txt b/Documentation/devicetree/bindings/sound/wm8782.txt
deleted file mode 100644
index 256cdec6ec4d..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8782.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-WM8782 stereo ADC
-
-This device does not have any control interface or reset pins.
-
-Required properties:
-
- - compatible : "wlf,wm8782"
- - Vdda-supply : phandle to a regulator for the analog power supply (2.7V - 5.5V)
- - Vdd-supply : phandle to a regulator for the digital power supply (2.7V - 3.6V)
-
-Example:
-
-wm8782: stereo-adc {
- compatible = "wlf,wm8782";
- Vdda-supply = <&vdda_supply>;
- Vdd-supply = <&vdd_supply>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8804.txt b/Documentation/devicetree/bindings/sound/wm8804.txt
deleted file mode 100644
index 2c1641c17a91..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8804.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-WM8804 audio CODEC
-
-This device supports both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : "wlf,wm8804"
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
- - PVDD-supply, DVDD-supply : Power supplies for the device, as covered
- in Documentation/devicetree/bindings/regulator/regulator.txt
-
-Optional properties:
-
- - wlf,reset-gpio: A GPIO specifier for the GPIO controlling the reset pin
-
-Example:
-
-wm8804: codec@1a {
- compatible = "wlf,wm8804";
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt
deleted file mode 100644
index 66bf261423b9..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8904.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-WM8904 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
- - compatible: "wlf,wm8904" or "wlf,wm8912"
- - reg: the I2C address of the device.
- - clock-names: "mclk"
- - clocks: reference to
- <Documentation/devicetree/bindings/clock/clock-bindings.txt>
-
-Pins on the device (for linking into audio routes):
-
- * IN1L
- * IN1R
- * IN2L
- * IN2R
- * IN3L
- * IN3R
- * HPOUTL
- * HPOUTR
- * LINEOUTL
- * LINEOUTR
- * MICBIAS
-
-Examples:
-
-codec: wm8904@1a {
- compatible = "wlf,wm8904";
- reg = <0x1a>;
- clocks = <&pck0>;
- clock-names = "mclk";
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8960.txt b/Documentation/devicetree/bindings/sound/wm8960.txt
deleted file mode 100644
index 85d3b287108c..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8960.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-WM8960 audio CODEC
-
-This device supports I2C only.
-
-Required properties:
-
- - compatible : "wlf,wm8960"
-
- - reg : the I2C address of the device.
-
-Optional properties:
- - wlf,shared-lrclk: This is a boolean property. If present, the LRCM bit of
- R24 (Additional control 2) gets set, indicating that ADCLRC and DACLRC pins
- will be disabled only when ADC (Left and Right) and DAC (Left and Right)
- are disabled.
- When wm8960 works on synchronize mode and DACLRC pin is used to supply
- frame clock, it will no frame clock for captrue unless enable DAC to enable
- DACLRC pin. If shared-lrclk is present, no need to enable DAC for captrue.
-
- - wlf,capless: This is a boolean property. If present, OUT3 pin will be
- enabled and disabled together with HP_L and HP_R pins in response to jack
- detect events.
-
- - wlf,hp-cfg: A list of headphone jack detect configuration register values.
- The list must be 3 entries long.
- hp-cfg[0]: HPSEL[1:0] of R48 (Additional Control 4).
- hp-cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2).
- hp-cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1).
-
- - wlf,gpio-cfg: A list of GPIO configuration register values.
- The list must be 2 entries long.
- gpio-cfg[0]: ALRCGPIO of R9 (Audio interface)
- gpio-cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4).
-
-Example:
-
-wm8960: codec@1a {
- compatible = "wlf,wm8960";
- reg = <0x1a>;
-
- wlf,shared-lrclk;
-};
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt
deleted file mode 100644
index 8fa947509c10..000000000000
--- a/Documentation/devicetree/bindings/sound/wm8994.txt
+++ /dev/null
@@ -1,112 +0,0 @@
-WM1811/WM8994/WM8958 audio CODEC
-
-These devices support both I2C and SPI (configured with pin strapping
-on the board).
-
-Required properties:
-
- - compatible : One of "wlf,wm1811", "wlf,wm8994" or "wlf,wm8958".
-
- - reg : the I2C address of the device for I2C, the chip select
- number for SPI.
-
- - gpio-controller : Indicates this device is a GPIO controller.
- - #gpio-cells : Must be 2. The first cell is the pin number and the
- second cell is used to specify optional parameters (currently unused).
-
- - power supplies for the device, as covered in
- Documentation/devicetree/bindings/regulator/regulator.txt, depending
- on compatible:
- - for wlf,wm1811 and wlf,wm8958:
- AVDD1-supply, AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply,
- DCVDD-supply, CPVDD-supply, SPKVDD1-supply, SPKVDD2-supply
- - for wlf,wm8994:
- AVDD1-supply, AVDD2-supply, DBVDD-supply, DCVDD-supply, CPVDD-supply,
- SPKVDD1-supply, SPKVDD2-supply
-
-Optional properties:
-
- - interrupts : The interrupt line the IRQ signal for the device is
- connected to. This is optional, if it is not connected then none
- of the interrupt related properties should be specified.
- - interrupt-controller : These devices contain interrupt controllers
- and may provide interrupt services to other devices if they have an
- interrupt line connected.
- - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
- The first cell is the IRQ number.
- The second cell is the flags, encoded as the trigger masks from
- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
-
- - clocks : A list of up to two phandle and clock specifier pairs
- - clock-names : A list of clock names sorted in the same order as clocks.
- Valid clock names are "MCLK1" and "MCLK2".
-
- - wlf,gpio-cfg : A list of GPIO configuration register values. If absent,
- no configuration of these registers is performed. If any value is
- over 0xffff then the register will be left as default. If present 11
- values must be supplied.
-
- - wlf,micbias-cfg : Two MICBIAS register values for WM1811 or
- WM8958. If absent the register defaults will be used.
-
- - wlf,ldo1ena : GPIO specifier for control of LDO1ENA input to device.
- - wlf,ldo2ena : GPIO specifier for control of LDO2ENA input to device.
-
- - wlf,lineout1-se : If present LINEOUT1 is in single ended mode.
- - wlf,lineout2-se : If present LINEOUT2 is in single ended mode.
-
- - wlf,lineout1-feedback : If present LINEOUT1 has common mode feedback
- connected.
- - wlf,lineout2-feedback : If present LINEOUT2 has common mode feedback
- connected.
-
- - wlf,ldoena-always-driven : If present LDOENA is always driven.
-
- - wlf,spkmode-pu : If present enable the internal pull-up resistor on
- the SPKMODE pin.
-
- - wlf,csnaddr-pd : If present enable the internal pull-down resistor on
- the CS/ADDR pin.
-
-Pins on the device (for linking into audio routes):
-
- * IN1LN
- * IN1LP
- * IN2LN
- * IN2LP:VXRN
- * IN1RN
- * IN1RP
- * IN2RN
- * IN2RP:VXRP
- * SPKOUTLP
- * SPKOUTLN
- * SPKOUTRP
- * SPKOUTRN
- * HPOUT1L
- * HPOUT1R
- * HPOUT2P
- * HPOUT2N
- * LINEOUT1P
- * LINEOUT1N
- * LINEOUT2P
- * LINEOUT2N
-
-Example:
-
-wm8994: codec@1a {
- compatible = "wlf,wm8994";
- reg = <0x1a>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- lineout1-se;
-
- AVDD1-supply = <&regulator>;
- AVDD2-supply = <&regulator>;
- CPVDD-supply = <&regulator>;
- DBVDD-supply = <&regulator>;
- DCVDD-supply = <&regulator>;
- SPKVDD1-supply = <&regulator>;
- SPKVDD2-supply = <&regulator>;
-};
diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt
deleted file mode 100644
index cbc93c8f4963..000000000000
--- a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Device-Tree bindings for Xilinx PL audio formatter
-
-The IP core supports DMA, data formatting(AES<->PCM conversion)
-of audio samples.
-
-Required properties:
- - compatible: "xlnx,audio-formatter-1.0"
- - interrupt-names: Names specified to list of interrupts in same
- order mentioned under "interrupts".
- List of supported interrupt names are:
- "irq_mm2s" : interrupt from MM2S block
- "irq_s2mm" : interrupt from S2MM block
- - interrupts-parent: Phandle for interrupt controller.
- - interrupts: List of Interrupt numbers.
- - reg: Base address and size of the IP core instance.
- - clock-names: List of input clocks.
- Required elements: "s_axi_lite_aclk", "aud_mclk"
- - clocks: Input clock specifier. Refer to common clock bindings.
-
-Example:
- audio_ss_0_audio_formatter_0: audio_formatter@80010000 {
- compatible = "xlnx,audio-formatter-1.0";
- interrupt-names = "irq_mm2s", "irq_s2mm";
- interrupt-parent = <&gic>;
- interrupts = <0 104 4>, <0 105 4>;
- reg = <0x0 0x80010000 0x0 0x1000>;
- clock-names = "s_axi_lite_aclk", "aud_mclk";
- clocks = <&clk 71>, <&clk_wiz_1 0>;
- };
diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml
new file mode 100644
index 000000000000..82fa448bd2e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/xlnx,audio-formatter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx PL audio formatter
+
+description:
+ The IP core supports DMA, data formatting(AES<->PCM conversion)
+ of audio samples.
+
+maintainers:
+ - Vincenzo Frascino <vincenzo.frascino@arm.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,audio-formatter-1.0
+
+ reg:
+ maxItems: 1
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: irq_mm2s
+ - const: irq_s2mm
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: interrupt from MM2S block
+ - description: interrupt from S2MM block
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: s_axi_lite_aclk
+ - const: aud_mclk
+
+ clocks:
+ minItems: 1
+ items:
+ - description: clock for the axi data stream
+ - description: clock for the MEMS microphone data stream
+
+required:
+ - compatible
+ - reg
+ - interrupt-names
+ - interrupts
+ - clock-names
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ audio_formatter@80010000 {
+ compatible = "xlnx,audio-formatter-1.0";
+ reg = <0x80010000 0x1000>;
+ interrupt-names = "irq_mm2s", "irq_s2mm";
+ interrupt-parent = <&gic>;
+ interrupts = <0 104 4>, <0 105 4>;
+ clock-names = "s_axi_lite_aclk", "aud_mclk";
+ clocks = <&clk 71>, <&clk_wiz_1 0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt b/Documentation/devicetree/bindings/sound/xlnx,i2s.txt
deleted file mode 100644
index 5e7c7d5bb60a..000000000000
--- a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Device-Tree bindings for Xilinx I2S PL block
-
-The IP supports I2S based playback/capture audio
-
-Required property:
- - compatible: "xlnx,i2s-transmitter-1.0" for playback and
- "xlnx,i2s-receiver-1.0" for capture
-
-Required property common to both I2S playback and capture:
- - reg: Base address and size of the IP core instance.
- - xlnx,dwidth: sample data width. Can be any of 16, 24.
- - xlnx,num-channels: Number of I2S streams. Can be any of 1, 2, 3, 4.
- supported channels = 2 * xlnx,num-channels
-
-Example:
-
- i2s_receiver@a0080000 {
- compatible = "xlnx,i2s-receiver-1.0";
- reg = <0x0 0xa0080000 0x0 0x10000>;
- xlnx,dwidth = <0x18>;
- xlnx,num-channels = <1>;
- };
- i2s_transmitter@a0090000 {
- compatible = "xlnx,i2s-transmitter-1.0";
- reg = <0x0 0xa0090000 0x0 0x10000>;
- xlnx,dwidth = <0x18>;
- xlnx,num-channels = <1>;
- };
diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml b/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml
new file mode 100644
index 000000000000..3c2b0be07c53
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/xlnx,i2s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx I2S PL block
+
+description:
+ The IP supports I2S based playback/capture audio.
+
+maintainers:
+ - Vincenzo Frascino <vincenzo.frascino@arm.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,i2s-receiver-1.0
+ - xlnx,i2s-transmitter-1.0
+
+ reg:
+ maxItems: 1
+
+ xlnx,dwidth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 16
+ - 24
+ description: |
+ Sample data width.
+
+ xlnx,num-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 4
+ description: |
+ Number of I2S streams.
+
+required:
+ - compatible
+ - reg
+ - xlnx,dwidth
+ - xlnx,num-channels
+
+additionalProperties: false
+
+examples:
+ - |
+ i2s@a0080000 {
+ compatible = "xlnx,i2s-receiver-1.0";
+ reg = <0xa0080000 0x10000>;
+ xlnx,dwidth = <0x18>;
+ xlnx,num-channels = <1>;
+ };
+ i2s@a0090000 {
+ compatible = "xlnx,i2s-transmitter-1.0";
+ reg = <0xa0090000 0x10000>;
+ xlnx,dwidth = <0x18>;
+ xlnx,num-channels = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/xlnx,spdif.txt b/Documentation/devicetree/bindings/sound/xlnx,spdif.txt
deleted file mode 100644
index 15c2d64d247c..000000000000
--- a/Documentation/devicetree/bindings/sound/xlnx,spdif.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Device-Tree bindings for Xilinx SPDIF IP
-
-The IP supports playback and capture of SPDIF audio
-
-Required properties:
- - compatible: "xlnx,spdif-2.0"
- - clock-names: List of input clocks.
- Required elements: "s_axi_aclk", "aud_clk_i"
- - clocks: Input clock specifier. Refer to common clock bindings.
- - reg: Base address and address length of the IP core instance.
- - interrupts-parent: Phandle for interrupt controller.
- - interrupts: List of Interrupt numbers.
- - xlnx,spdif-mode: 0 :- receiver mode
- 1 :- transmitter mode
- - xlnx,aud_clk_i: input audio clock value.
-
-Example:
- spdif_0: spdif@80010000 {
- clock-names = "aud_clk_i", "s_axi_aclk";
- clocks = <&misc_clk_0>, <&clk 71>;
- compatible = "xlnx,spdif-2.0";
- interrupt-names = "spdif_interrupt";
- interrupt-parent = <&gic>;
- interrupts = <0 91 4>;
- reg = <0x0 0x80010000 0x0 0x10000>;
- xlnx,spdif-mode = <1>;
- xlnx,aud_clk_i = <49152913>;
- };
diff --git a/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml b/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml
new file mode 100644
index 000000000000..a45d8a0755fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/xlnx,spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx SPDIF IP
+
+description:
+ The IP supports playback and capture of SPDIF audio.
+
+maintainers:
+ - Vincenzo Frascino <vincenzo.frascino@arm.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,spdif-2.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: SPDIF audio interrupt
+
+ clock-names:
+ items:
+ - const: aud_clk_i
+ - const: s_axi_aclk
+
+ clocks:
+ minItems: 1
+ items:
+ - description: input audio clock
+ - description: clock for the AXI data stream
+
+ xlnx,spdif-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0
+ - 1
+ description: |
+ 0 - receiver
+ 1 - transmitter
+
+ xlnx,aud_clk_i:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Input audio clock frequency. It affects the sampling rate.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clock-names
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ spdif@80010000 {
+ compatible = "xlnx,spdif-2.0";
+ reg = <0x80010000 0x10000>;
+ clock-names = "aud_clk_i", "s_axi_aclk";
+ clocks = <&misc_clk_0>, <&clk 71>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 91 4>;
+ xlnx,spdif-mode = <1>;
+ xlnx,aud_clk_i = <49152913>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
new file mode 100644
index 000000000000..fb77a61f1350
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: XMOS XVF3500 VocalFusion Voice Processor
+
+maintainers:
+ - Javier Carrasco <javier.carrasco@wolfvision.net>
+
+description:
+ The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit
+ multicore controller for voice processing.
+ https://www.xmos.com/xvf3500/
+
+allOf:
+ - $ref: /schemas/usb/usb-device.yaml#
+
+properties:
+ compatible:
+ const: usb20b1,0013
+
+ reg: true
+
+ reset-gpios:
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Regulator for the 1V0 supply.
+
+ vddio-supply:
+ description:
+ Regulator for the 3V3 supply.
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vdd-supply
+ - vddio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ voice_processor: voice-processor@1 {
+ compatible = "usb20b1,0013";
+ reg = <1>;
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&vcc1v0>;
+ vddio-supply = <&vcc3v3>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/sound/zl38060.yaml b/Documentation/devicetree/bindings/sound/zl38060.yaml
deleted file mode 100644
index 338e2a13c775..000000000000
--- a/Documentation/devicetree/bindings/sound/zl38060.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/zl38060.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: ZL38060 Connected Home Audio Processor from Microsemi.
-
-description: |
- The ZL38060 is a "Connected Home Audio Processor" from Microsemi,
- which consists of a Digital Signal Processor (DSP), several Digital
- Audio Interfaces (DAIs), analog outputs, and a block of 14 GPIOs.
-
-maintainers:
- - Jaroslav Kysela <perex@perex.cz>
- - Takashi Iwai <tiwai@suse.com>
-
-properties:
- compatible:
- const: mscc,zl38060
-
- reg:
- description:
- SPI device address.
- maxItems: 1
-
- spi-max-frequency:
- maximum: 24000000
-
- reset-gpios:
- description:
- A GPIO line handling reset of the chip. As the line is active low,
- it should be marked GPIO_ACTIVE_LOW (see ../gpio/gpio.txt)
- maxItems: 1
-
- '#gpio-cells':
- const: 2
-
- gpio-controller: true
-
- '#sound-dai-cells':
- const: 0
-
-required:
- - compatible
- - reg
- - '#gpio-cells'
- - gpio-controller
- - '#sound-dai-cells'
-
-additionalProperties: false
-
-examples:
- - |
- #include <dt-bindings/gpio/gpio.h>
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
-
- codec: zl38060@0 {
- gpio-controller;
- #gpio-cells = <2>;
- #sound-dai-cells = <0>;
- compatible = "mscc,zl38060";
- reg = <0>;
- spi-max-frequency = <12000000>;
- reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
- };
- };
diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt
deleted file mode 100644
index c85c25779e3f..000000000000
--- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt
+++ /dev/null
@@ -1,214 +0,0 @@
-Qualcomm SoundWire Controller Bindings
-
-
-This binding describes the Qualcomm SoundWire Controller along with its
-board specific bus parameters.
-
-- compatible:
- Usage: required
- Value type: <stringlist>
- Definition: must be "qcom,soundwire-v<MAJOR>.<MINOR>.<STEP>",
- Example:
- "qcom,soundwire-v1.3.0"
- "qcom,soundwire-v1.5.0"
- "qcom,soundwire-v1.5.1"
- "qcom,soundwire-v1.6.0"
-- reg:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: the base address and size of SoundWire controller
- address space.
-
-- interrupts:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the SoundWire Controller core and optional
- wake IRQ
-
-- interrupt-names:
- Usage: Optional
- Value type: boolean
- Value type: <stringlist>
- Definition: should be "core" for core and "wakeup" for wake interrupt.
-
-- wakeup-source:
- Usage: Optional
- Value type: boolean
- Definition: should specify if SoundWire Controller is wake up capable.
-
-- clock-names:
- Usage: required
- Value type: <stringlist>
- Definition: should be "iface" for SoundWire Controller interface clock
-
-- clocks:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify the SoundWire Controller interface clock
-
-- #sound-dai-cells:
- Usage: required
- Value type: <u32>
- Definition: must be 1 for digital audio interfaces on the controller.
-
-- qcom,dout-ports:
- Usage: required
- Value type: <u32>
- Definition: must be count of data out ports
-
-- qcom,din-ports:
- Usage: required
- Value type: <u32>
- Definition: must be count of data in ports
-
-- qcom,ports-offset1:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify payload transport window offset1 of each
- data port. Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-offset2:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should specify payload transport window offset2 of each
- data port. Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-sinterval-low:
- Usage: required
- Value type: <prop-encoded-array>
- Definition: should be sample interval low of each data port.
- Out ports followed by In ports. Used for Sample Interval
- calculation.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-word-length:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be size of payload channel sample.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-block-pack-mode:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be 0 or 1 to indicate the block packing mode.
- 0 to indicate Blocks are per Channel
- 1 to indicate Blocks are per Port.
- Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-block-group-count:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be in range 1 to 4 to indicate how many sample
- intervals are combined into a payload.
- Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-lane-control:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be in range 0 to 7 to identify which data lane
- the data port uses.
- Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-hstart:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be number identifying lowerst numbered coloum in
- SoundWire Frame, i.e. left edge of the Transport sub-frame
- for each port. Values between 0 and 15 are valid.
- Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,ports-hstop:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be number identifying highest numbered coloum in
- SoundWire Frame, i.e. the right edge of the Transport
- sub-frame for each port. Values between 0 and 15 are valid.
- Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- qcom,dports-type:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: should be one of the following types
- 0 for reduced port
- 1 for simple ports
- 2 for full port
- Out ports followed by In ports.
- Value of 0xFF indicates that this option is not implemented
- or applicable for the respective data port.
- More info in MIPI Alliance SoundWire 1.0 Specifications.
-
-- reset:
- Usage: optional
- Value type: <prop-encoded-array>
- Definition: Should specify the SoundWire audio CSR reset controller interface,
- which is required for SoundWire version 1.6.0 and above.
-
-- reset-names:
- Usage: optional
- Value type: <stringlist>
- Definition: should be "swr_audio_cgcr" for SoundWire audio CSR reset
- controller interface.
-
-Note:
- More Information on detail of encoding of these fields can be
-found in MIPI Alliance SoundWire 1.0 Specifications.
-
-= SoundWire devices
-Each subnode of the bus represents SoundWire device attached to it.
-The properties of these nodes are defined by the individual bindings.
-
-= EXAMPLE
-The following example represents a SoundWire controller on DB845c board
-which has controller integrated inside WCD934x codec on SDM845 SoC.
-
-soundwire: soundwire@c85 {
- compatible = "qcom,soundwire-v1.3.0";
- reg = <0xc85 0x20>;
- interrupts = <20 IRQ_TYPE_EDGE_RISING>;
- clocks = <&wcc>;
- clock-names = "iface";
- resets = <&lpass_audiocc LPASS_AUDIO_SWR_TX_CGCR>;
- reset-names = "swr_audio_cgcr";
- #sound-dai-cells = <1>;
- qcom,dports-type = <0>;
- qcom,dout-ports = <6>;
- qcom,din-ports = <2>;
- qcom,ports-sinterval-low = /bits/ 8 <0x07 0x1F 0x3F 0x7 0x1F 0x3F 0x0F 0x0F>;
- qcom,ports-offset1 = /bits/ 8 <0x01 0x02 0x0C 0x6 0x12 0x0D 0x07 0x0A >;
- qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x1F 0x00 0x00 0x1F 0x00 0x00>;
-
- /* Left Speaker */
- left{
- ....
- };
-
- /* Right Speaker */
- right{
- ....
- };
-};
diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
new file mode 100644
index 000000000000..95d947fda6a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
@@ -0,0 +1,285 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soundwire/qcom,soundwire.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SoundWire Controller
+
+maintainers:
+ - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ - Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
+
+description:
+ The Qualcomm SoundWire controller along with its board specific bus parameters.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,soundwire-v1.3.0
+ - qcom,soundwire-v1.5.0
+ - qcom,soundwire-v1.5.1
+ - qcom,soundwire-v1.6.0
+ - qcom,soundwire-v1.7.0
+ - qcom,soundwire-v2.0.0
+ - items:
+ - enum:
+ - qcom,soundwire-v2.1.0
+ - const: qcom,soundwire-v2.0.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: specify the SoundWire controller core.
+ - description: specify the Soundwire controller wake IRQ.
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: core
+ - const: wakeup
+
+ clocks:
+ items:
+ - description: iface clock
+
+ clock-names:
+ items:
+ - const: iface
+
+ resets:
+ items:
+ - description: SWR_AUDIO_CGCR RESET
+
+ reset-names:
+ items:
+ - const: swr_audio_cgcr
+
+ '#sound-dai-cells':
+ const: 1
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 0
+
+ wakeup-source: true
+
+ qcom,din-ports:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: count of data in ports
+
+ qcom,dout-ports:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: count of data out ports
+
+ qcom,ports-word-length:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Size of payload channel sample.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+
+ qcom,ports-sinterval-low:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Sample interval (only lowest byte) of each data port.
+ Out ports followed by In ports. Used for Sample Interval calculation.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+
+ qcom,ports-sinterval:
+ $ref: /schemas/types.yaml#/definitions/uint16-array
+ description:
+ Sample interval of each data port.
+ Out ports followed by In ports. Used for Sample Interval calculation.
+ Value of 0xffff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+
+ qcom,ports-offset1:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Payload transport window offset1 of each data port.
+ Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+
+ qcom,ports-offset2:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Payload transport window offset2 of each data port.
+ Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+
+ qcom,ports-lane-control:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Identify which data lane the data port uses.
+ Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+
+ qcom,ports-block-pack-mode:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Indicate the block packing mode.
+ 0 to indicate Blocks are per Channel
+ 1 to indicate Blocks are per Port.
+ Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+ items:
+ oneOf:
+ - minimum: 0
+ maximum: 1
+ - const: 0xff
+
+ qcom,ports-hstart:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Identifying lowerst numbered column in SoundWire Frame,
+ i.e. left edge of the Transport sub-frame for each port.
+ Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+ items:
+ oneOf:
+ - minimum: 0
+ maximum: 15
+ - const: 0xff
+
+ qcom,ports-hstop:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ Identifying highest numbered column in SoundWire Frame,
+ i.e. the right edge of the Transport
+ sub-frame for each port. Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+ items:
+ oneOf:
+ - minimum: 0
+ maximum: 15
+ - const: 0xff
+
+ qcom,ports-block-group-count:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description:
+ In range 1 to 4 to indicate how many sample intervals are combined
+ into a payload. Out ports followed by In ports.
+ Value of 0xff indicates that this option is not implemented
+ or applicable for the respective data port.
+ More info in MIPI Alliance SoundWire 1.0 Specifications.
+ minItems: 3
+ maxItems: 16
+ items:
+ oneOf:
+ - minimum: 0
+ maximum: 4
+ - const: 0xff
+
+ label:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - '#sound-dai-cells'
+ - '#address-cells'
+ - '#size-cells'
+ - qcom,dout-ports
+ - qcom,din-ports
+ - qcom,ports-offset1
+ - qcom,ports-offset2
+
+oneOf:
+ - required:
+ - qcom,ports-sinterval-low
+ - required:
+ - qcom,ports-sinterval
+
+allOf:
+ - $ref: soundwire-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
+
+ soundwire@3210000 {
+ compatible = "qcom,soundwire-v1.6.0";
+ reg = <0x03210000 0x2000>;
+
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
+ <&pdc 130 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-names = "core", "wakeup";
+
+ clocks = <&lpass_rx_macro>;
+ clock-names = "iface";
+
+ qcom,din-ports = <0>;
+ qcom,dout-ports = <5>;
+
+ resets = <&lpass_audiocc LPASS_AUDIO_SWR_RX_CGCR>;
+ reset-names = "swr_audio_cgcr";
+
+ qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff>;
+ qcom,ports-sinterval-low = /bits/ 8 <0x03 0x3f 0x1f 0x03 0x03>;
+ qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x01 0x01>;
+ qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00>;
+ qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00>;
+ qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff>;
+ qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0x00>;
+
+ #sound-dai-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ codec@0,4 {
+ compatible = "sdw20217010d00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 2 3 4 5>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
index 4aad121eff3f..fdeb8af417d7 100644
--- a/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
+++ b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/soundwire/soundwire-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SoundWire Controller Generic Binding
+title: SoundWire Controller Common Properties
maintainers:
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
diff --git a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.txt b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.txt
deleted file mode 100644
index 8a18d71e6879..000000000000
--- a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Analog Devices AXI SPI Engine controller Device Tree Bindings
-
-Required properties:
-- compatible : Must be "adi,axi-spi-engine-1.00.a""
-- reg : Physical base address and size of the register map.
-- interrupts : Property with a value describing the interrupt
- number.
-- clock-names : List of input clock names - "s_axi_aclk", "spi_clk"
-- clocks : Clock phandles and specifiers (See clock bindings for
- details on clock-names and clocks).
-- #address-cells : Must be <1>
-- #size-cells : Must be <0>
-
-Optional subnodes:
- Subnodes are use to represent the SPI slave devices connected to the SPI
- master. They follow the generic SPI bindings as outlined in spi-bus.txt.
-
-Example:
-
- spi@@44a00000 {
- compatible = "adi,axi-spi-engine-1.00.a";
- reg = <0x44a00000 0x1000>;
- interrupts = <0 56 4>;
- clocks = <&clkc 15 &clkc 15>;
- clock-names = "s_axi_aclk", "spi_clk";
-
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* SPI devices */
- };
diff --git a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml
new file mode 100644
index 000000000000..4b3828eda6cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/adi,axi-spi-engine.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AXI SPI Engine Controller
+
+description: |
+ The AXI SPI Engine controller is part of the SPI Engine framework[1] and
+ allows memory mapped access to the SPI Engine control bus. This allows it
+ to be used as a general purpose software driven SPI controller as well as
+ some optional advanced acceleration and offloading capabilities.
+
+ [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine
+
+maintainers:
+ - Michael Hennerich <Michael.Hennerich@analog.com>
+ - Nuno Sá <nuno.sa@analog.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ const: adi,axi-spi-engine-1.00.a
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The AXI interconnect clock.
+ - description: The SPI controller clock.
+
+ clock-names:
+ items:
+ - const: s_axi_aclk
+ - const: spi_clk
+
+ trigger-sources:
+ description:
+ An array of trigger source phandles for offload instances. The index in
+ the array corresponds to the offload instance number.
+ minItems: 1
+ maxItems: 32
+
+ dmas:
+ description:
+ DMA channels connected to the input or output stream interface of an
+ offload instance.
+ minItems: 1
+ maxItems: 32
+
+ dma-names:
+ items:
+ pattern: "^offload(?:[12]?[0-9]|3[01])-[tr]x$"
+ minItems: 1
+ maxItems: 32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@44a00000 {
+ compatible = "adi,axi-spi-engine-1.00.a";
+ reg = <0x44a00000 0x1000>;
+ interrupts = <0 56 4>;
+ clocks = <&clkc 15>, <&clkc 15>;
+ clock-names = "s_axi_aclk", "spi_clk";
+
+ trigger-sources = <&trigger_clock>;
+ dmas = <&dma 0>;
+ dma-names = "offload0-rx";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* SPI devices */
+ };
diff --git a/Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml b/Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml
new file mode 100644
index 000000000000..855aa08995b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/airoha,en7581-snand.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/airoha,en7581-snand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI-NAND flash controller for Airoha ARM SoCs
+
+maintainers:
+ - Lorenzo Bianconi <lorenzo@kernel.org>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: airoha,en7581-snand
+ - items:
+ - enum:
+ - airoha,en7523-snand
+ - const: airoha,en7581-snand
+
+ reg:
+ items:
+ - description: spi base address
+ - description: nfi2spi base address
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: spi
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/en7523-clk.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spi@1fa10000 {
+ compatible = "airoha,en7581-snand";
+ reg = <0x0 0x1fa10000 0x0 0x140>,
+ <0x0 0x1fa11000 0x0 0x160>;
+
+ clocks = <&scuclk EN7523_CLK_SPI>;
+ clock-names = "spi";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spi-nand";
+ reg = <0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <2>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
index 8036499112f5..e1ab3f523ad6 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
@@ -4,19 +4,16 @@
$id: http://devicetree.org/schemas/spi/allwinner,sun4i-a10-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 SPI Controller Device Tree Bindings
+title: Allwinner A10 SPI Controller
allOf:
- - $ref: "spi-controller.yaml"
+ - $ref: spi-controller.yaml
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
const: allwinner,sun4i-a10-spi
@@ -46,11 +43,11 @@ properties:
- const: rx
- const: tx
- num-cs: true
-
patternProperties:
"^.*@[0-9a-f]+":
type: object
+ additionalProperties: true
+
properties:
reg:
items:
@@ -70,7 +67,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
index ca4c95345a49..3b47b68b92cb 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
@@ -4,21 +4,19 @@
$id: http://devicetree.org/schemas/spi/allwinner,sun6i-a31-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A31 SPI Controller Device Tree Bindings
+title: Allwinner A31 SPI Controller
allOf:
- - $ref: "spi-controller.yaml"
+ - $ref: spi-controller.yaml
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
oneOf:
+ - const: allwinner,sun50i-r329-spi
- const: allwinner,sun6i-a31-spi
- const: allwinner,sun8i-h3-spi
- items:
@@ -28,6 +26,15 @@ properties:
- allwinner,sun50i-h616-spi
- allwinner,suniv-f1c100s-spi
- const: allwinner,sun8i-h3-spi
+ - items:
+ - enum:
+ - allwinner,sun20i-d1-spi
+ - allwinner,sun50i-r329-spi-dbi
+ - const: allwinner,sun50i-r329-spi
+ - items:
+ - const: allwinner,sun20i-d1-spi-dbi
+ - const: allwinner,sun50i-r329-spi-dbi
+ - const: allwinner,sun50i-r329-spi
reg:
maxItems: 1
@@ -58,11 +65,11 @@ properties:
- const: rx
- const: tx
- num-cs: true
-
patternProperties:
"^.*@[0-9a-f]+":
type: object
+ additionalProperties: true
+
properties:
reg:
items:
@@ -82,7 +89,7 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml
new file mode 100644
index 000000000000..043879b434ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/amlogic,a1-spifc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic A1 SPI Flash Controller
+
+maintainers:
+ - Martin Kurbanov <mmkurbanov@sberdevices.ru>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - amlogic,a1-spifc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@fd000400 {
+ compatible = "amlogic,a1-spifc";
+ reg = <0xfd000400 0x290>;
+ clocks = <&clkc_clkid_spifc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/amlogic,a4-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,a4-spifc.yaml
new file mode 100644
index 000000000000..b4cef838bcd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,a4-spifc.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2025 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/amlogic,a4-spifc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI flash controller for Amlogic ARM SoCs
+
+maintainers:
+ - Liang Yang <liang.yang@amlogic.com>
+ - Feng Chen <feng.chen@amlogic.com>
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+
+description:
+ The Amlogic SPI flash controller is an extended version of the Amlogic NAND
+ flash controller. It supports SPI Nor Flash and SPI NAND Flash(where the Host
+ ECC HW engine could be enabled).
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ const: amlogic,a4-spifc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock apb gate
+ - description: clock used for the controller
+
+ clock-names:
+ items:
+ - const: gate
+ - const: core
+
+ interrupts:
+ maxItems: 1
+
+ amlogic,rx-adj:
+ description:
+ Number of clock cycles by which sampling is delayed.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sfc0: spi@fe08d000 {
+ compatible = "amlogic,a4-spifc";
+ reg = <0xfe08d000 0x800>;
+ clocks = <&clkc_periphs 31>,
+ <&clkc_periphs 102>;
+ clock-names = "gate", "core";
+
+ pinctrl-0 = <&spiflash_default>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spi-nand";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-ecc-engine = <&sfc0>;
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/amlogic,a4-spisg.yaml b/Documentation/devicetree/bindings/spi/amlogic,a4-spisg.yaml
new file mode 100644
index 000000000000..9bfb8089f7ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,a4-spisg.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2025 Amlogic, Inc. All rights reserved
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/amlogic,a4-spisg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic SPI Scatter-Gather Controller
+
+maintainers:
+ - Xianwei Zhao <xianwei.zhao@amlogic.com>
+ - Sunny Luo <sunny.luo@amlogic.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: amlogic,a4-spisg
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: pclk
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ spi@50000 {
+ compatible = "amlogic,a4-spisg";
+ reg = <0x50000 0x38>;
+ interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc 37>,
+ <&clkc 93>;
+ clock-names = "core", "pclk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
index 0c10f7678178..4e28e6e9d8e0 100644
--- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
@@ -2,17 +2,14 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson SPI Communication Controller
maintainers:
- Neil Armstrong <neil.armstrong@linaro.org>
-allOf:
- - $ref: "spi-controller.yaml#"
-
description: |
The Meson SPICC is a generic SPI controller for general purpose Full-Duplex
communications with dedicated 16 words RX/TX PIO FIFOs.
@@ -43,31 +40,53 @@ properties:
minItems: 1
maxItems: 2
-if:
- properties:
- compatible:
- contains:
- enum:
- - amlogic,meson-g12a-spicc
-
-then:
- properties:
- clocks:
- minItems: 2
-
- clock-names:
- items:
- - const: core
- - const: pclk
-
-else:
- properties:
- clocks:
- maxItems: 1
-
- clock-names:
- items:
- - const: core
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson-g12a-spicc
+
+ then:
+ properties:
+ clocks:
+ minItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: pclk
+
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson-gx-spicc
+
+ then:
+ properties:
+ pinctrl-0: true
+ pinctrl-1: true
+ pinctrl-2: true
+
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: idle-high
+ - const: idle-low
required:
- compatible
@@ -81,17 +100,17 @@ unevaluatedProperties: false
examples:
- |
spi@c1108d80 {
- compatible = "amlogic,meson-gx-spicc";
- reg = <0xc1108d80 0x80>;
- interrupts = <112>;
- clocks = <&clk81>;
- clock-names = "core";
- #address-cells = <1>;
- #size-cells = <0>;
-
- display@0 {
- compatible = "lg,lg4573";
- spi-max-frequency = <1000000>;
- reg = <0>;
- };
+ compatible = "amlogic,meson-gx-spicc";
+ reg = <0xc1108d80 0x80>;
+ interrupts = <112>;
+ clocks = <&clk81>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display@0 {
+ compatible = "lg,lg4573";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
index ac3b2ec300ac..8e769ccda97f 100644
--- a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson SPI Flash Controller
@@ -11,7 +11,7 @@ maintainers:
- Neil Armstrong <neil.armstrong@linaro.org>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
description: |
The Meson SPIFC is a controller optimized for communication with SPI
@@ -40,15 +40,15 @@ unevaluatedProperties: false
examples:
- |
spi@c1108c80 {
- compatible = "amlogic,meson6-spifc";
- reg = <0xc1108c80 0x80>;
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- flash: flash@0 {
- compatible = "spansion,m25p80", "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <40000000>;
- };
+ compatible = "amlogic,meson6-spifc";
+ reg = <0xc1108c80 0x80>;
+ clocks = <&clk81>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash: flash@0 {
+ compatible = "spansion,m25p80", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/apple,spi.yaml b/Documentation/devicetree/bindings/spi/apple,spi.yaml
new file mode 100644
index 000000000000..9356b9c337c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/apple,spi.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/apple,spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple ARM SoC SPI controller
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+maintainers:
+ - Hector Martin <marcan@marcan.st>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: apple,t6020-spi
+ - const: apple,t8103-spi
+ - items:
+ - enum:
+ - apple,t8103-spi
+ - apple,t8112-spi
+ - apple,t6000-spi
+ - const: apple,spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/apple-aic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spi@39b104000 {
+ compatible = "apple,t6000-spi", "apple,spi";
+ reg = <0x3 0x9b104000 0x0 0x4000>;
+ interrupt-parent = <&aic>;
+ interrupts = <AIC_IRQ 0 1107 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/arm,pl022-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/arm,pl022-peripheral-props.yaml
new file mode 100644
index 000000000000..bb8b6863b109
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/arm,pl022-peripheral-props.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/arm,pl022-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral-specific properties for Arm PL022 SPI controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+select: false
+
+properties:
+ pl022,interface:
+ description: SPI interface type
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # SPI
+ - 1 # Texas Instruments Synchronous Serial Frame Format
+ - 2 # Microwire (Half Duplex)
+
+ pl022,com-mode:
+ description: Specifies the transfer mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # interrupt mode
+ - 1 # polling mode
+ - 2 # DMA mode
+ default: 1
+
+ pl022,rx-level-trig:
+ description: Rx FIFO watermark level
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 4
+
+ pl022,tx-level-trig:
+ description: Tx FIFO watermark level
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 4
+
+ pl022,ctrl-len:
+ description: Microwire interface - Control length
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x03
+ maximum: 0x1f
+
+ pl022,wait-state:
+ description: Microwire interface - Wait state
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+ pl022,duplex:
+ description: Microwire interface - Full/Half duplex
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+
+additionalProperties: true
+...
diff --git a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
index fa8f4ac20985..80e542624cc6 100644
--- a/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
+++ b/Documentation/devicetree/bindings/spi/aspeed,ast2600-fmc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/aspeed,ast2600-fmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Aspeed SMC controllers bindings
+title: Aspeed SMC controllers
maintainers:
- Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
@@ -12,14 +12,16 @@ maintainers:
description: |
This binding describes the Aspeed Static Memory Controllers (FMC and
- SPI) of the AST2400, AST2500 and AST2600 SOCs.
+ SPI) of the AST2400, AST2500, AST2600 and AST2700 SOCs.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
enum:
+ - aspeed,ast2700-fmc
+ - aspeed,ast2700-spi
- aspeed,ast2600-fmc
- aspeed,ast2600-spi
- aspeed,ast2500-fmc
@@ -60,23 +62,23 @@ examples:
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
flash@0 {
- reg = < 0 >;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <50000000>;
- spi-rx-bus-width = <2>;
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
};
flash@1 {
- reg = < 1 >;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <50000000>;
- spi-rx-bus-width = <2>;
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
};
flash@2 {
- reg = < 2 >;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <50000000>;
- spi-rx-bus-width = <2>;
+ reg = < 2 >;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <2>;
};
};
diff --git a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml
index 4dd973e341e6..11885d0cc209 100644
--- a/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml
@@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel SPI device
maintainers:
- - Tudor Ambarus <tudor.ambarus@microchip.com>
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
allOf:
- $ref: spi-controller.yaml#
@@ -18,7 +18,10 @@ properties:
oneOf:
- const: atmel,at91rm9200-spi
- items:
- - const: microchip,sam9x60-spi
+ - enum:
+ - microchip,sam9x60-spi
+ - microchip,sam9x7-spi
+ - microchip,sama7d65-spi
- const: atmel,at91rm9200-spi
reg:
@@ -28,11 +31,16 @@ properties:
maxItems: 1
clock-names:
- contains:
- const: spi_clk
+ items:
+ - const: spi_clk
+ - const: spi_gclk
+ minItems: 1
clocks:
- maxItems: 1
+ items:
+ - description: Peripheral Bus clock
+ - description: Programmable Generic clock
+ minItems: 1
dmas:
items:
diff --git a/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml b/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml
index 1d493add4053..30ab42c95c08 100644
--- a/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml
+++ b/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel Quad Serial Peripheral Interface (QSPI)
maintainers:
- - Tudor Ambarus <tudor.ambarus@microchip.com>
+ - Tudor Ambarus <tudor.ambarus@linaro.org>
allOf:
- $ref: spi-controller.yaml#
@@ -17,6 +17,9 @@ properties:
enum:
- atmel,sama5d2-qspi
- microchip,sam9x60-qspi
+ - microchip,sam9x7-ospi
+ - microchip,sama7d65-qspi
+ - microchip,sama7d65-ospi
- microchip,sama7g5-qspi
- microchip,sama7g5-ospi
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt
deleted file mode 100644
index 9887b0724759..000000000000
--- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Broadcom BCM2835 auxiliar SPI1/2 controller
-
-The BCM2835 contains two forms of SPI master controller, one known simply as
-SPI0, and the other known as the "Universal SPI Master"; part of the
-auxiliary block. This binding applies to the SPI1/2 controller.
-
-Required properties:
-- compatible: Should be "brcm,bcm2835-aux-spi".
-- reg: Should contain register location and length for the spi block
-- interrupts: Should contain shared interrupt of the aux block
-- clocks: The clock feeding the SPI controller - needs to
- point to the auxiliar clock driver of the bcm2835,
- as this clock will enable the output gate for the specific
- clock.
-- cs-gpios: the cs-gpios (native cs is NOT supported)
- see also spi-bus.txt
-
-Example:
-
-spi1@7e215080 {
- compatible = "brcm,bcm2835-aux-spi";
- reg = <0x7e215080 0x40>;
- interrupts = <1 29>;
- clocks = <&aux_clocks BCM2835_AUX_CLOCK_SPI1>;
- #address-cells = <1>;
- #size-cells = <0>;
- cs-gpios = <&gpio 18>, <&gpio 17>, <&gpio 16>;
-};
-
-spi2@7e2150c0 {
- compatible = "brcm,bcm2835-aux-spi";
- reg = <0x7e2150c0 0x40>;
- interrupts = <1 29>;
- clocks = <&aux_clocks BCM2835_AUX_CLOCK_SPI2>;
- #address-cells = <1>;
- #size-cells = <0>;
- cs-gpios = <&gpio 43>, <&gpio 44>, <&gpio 45>;
-};
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.yaml
new file mode 100644
index 000000000000..561319544ee3
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/brcm,bcm2835-aux-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 Auxiliary SPI1/2 Controller
+
+maintainers:
+ - Karan Sanghavi <karansanghvi98@gmail.com>
+
+description:
+ The BCM2835 contains two forms of SPI master controller. One is known simply
+ as SPI0, and the other as the "Universal SPI Master," which is part of the
+ auxiliary block. This binding applies to the SPI1 and SPI2 auxiliary
+ controllers.
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-aux-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835-aux.h>
+ spi@7e215080 {
+ compatible = "brcm,bcm2835-aux-spi";
+ reg = <0x7e215080 0x40>;
+ interrupts = <1 29>;
+ clocks = <&aux_clocks BCM2835_AUX_CLOCK_SPI1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
deleted file mode 100644
index 3d55dd64b1be..000000000000
--- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Broadcom BCM2835 SPI0 controller
-
-The BCM2835 contains two forms of SPI master controller, one known simply as
-SPI0, and the other known as the "Universal SPI Master"; part of the
-auxiliary block. This binding applies to the SPI0 controller.
-
-Required properties:
-- compatible: Should be one of "brcm,bcm2835-spi" for BCM2835/2836/2837 or
- "brcm,bcm2711-spi" for BCM2711 or "brcm,bcm7211-spi" for BCM7211.
-- reg: Should contain register location and length.
-- interrupts: Should contain interrupt.
-- clocks: The clock feeding the SPI controller.
-
-Example:
-
-spi@20204000 {
- compatible = "brcm,bcm2835-spi";
- reg = <0x7e204000 0x1000>;
- interrupts = <2 22>;
- clocks = <&clk_spi>;
- #address-cells = <1>;
- #size-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.yaml
new file mode 100644
index 000000000000..94da68792194
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/brcm,bcm2835-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 SPI0 controller
+
+maintainers:
+ - Florian Fainelli <florian.fainelli@broadcom.com>
+ - Kanak Shilledar <kanakshilledar111@protonmail.com>
+ - Stefan Wahren <wahrenst@gmx.net>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-spi
+ - brcm,bcm2711-spi
+ - brcm,bcm7211-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@20204000 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204000 0x1000>;
+ interrupts = <2 22>;
+ clocks = <&clk_spi>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml
new file mode 100644
index 000000000000..6554978583f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-hsspi.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/brcm,bcm63xx-hsspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Broadband SoC High Speed SPI controller
+
+maintainers:
+ - William Zhang <william.zhang@broadcom.com>
+ - Kursad Oney <kursad.oney@broadcom.com>
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+description: |
+ Broadcom Broadband SoC supports High Speed SPI master controller since the
+ early MIPS based chips such as BCM6328 and BCM63268. This initial rev 1.0
+ controller was carried over to recent ARM based chips, such as BCM63138,
+ BCM4908 and BCM6858. The old MIPS based chip should continue to use the
+ brcm,bcm6328-hsspi compatible string. The recent ARM based chip is required to
+ use the brcm,bcmbca-hsspi-v1.0 as part of its compatible string list as
+ defined below to match the specific chip along with ip revision info.
+
+ This rev 1.0 controller has a limitation that can not keep the chip select line
+ active between the SPI transfers within the same SPI message. This can
+ terminate the transaction to some SPI devices prematurely. The issue can be
+ worked around by either the controller's prepend mode or using the dummy chip
+ select workaround. Driver automatically picks the suitable mode based on
+ transfer type so it is transparent to the user.
+
+ The newer SoCs such as BCM6756, BCM4912 and BCM6855 include an updated SPI
+ controller rev 1.1 that add the capability to allow the driver to control chip
+ select explicitly. This solves the issue in the old controller.
+
+properties:
+ compatible:
+ oneOf:
+ - const: brcm,bcm6328-hsspi
+ - items:
+ - enum:
+ - brcm,bcm47622-hsspi
+ - brcm,bcm4908-hsspi
+ - brcm,bcm63138-hsspi
+ - brcm,bcm63146-hsspi
+ - brcm,bcm63148-hsspi
+ - brcm,bcm63158-hsspi
+ - brcm,bcm63178-hsspi
+ - brcm,bcm6846-hsspi
+ - brcm,bcm6856-hsspi
+ - brcm,bcm6858-hsspi
+ - brcm,bcm6878-hsspi
+ - const: brcm,bcmbca-hsspi-v1.0
+ - items:
+ - enum:
+ - brcm,bcm4912-hsspi
+ - brcm,bcm6756-hsspi
+ - brcm,bcm6813-hsspi
+ - brcm,bcm6855-hsspi
+ - const: brcm,bcmbca-hsspi-v1.1
+
+ reg:
+ items:
+ - description: main registers
+ - description: miscellaneous control registers
+ minItems: 1
+
+ reg-names:
+ items:
+ - const: hsspi
+ - const: spim-ctrl
+ minItems: 1
+
+ clocks:
+ items:
+ - description: SPI master reference clock
+ - description: SPI master pll clock
+
+ clock-names:
+ items:
+ - const: hsspi
+ - const: pll
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - brcm,bcm6328-hsspi
+ - brcm,bcmbca-hsspi-v1.0
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
+ else:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+ reg-names:
+ minItems: 2
+ maxItems: 2
+ required:
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ spi@ff801000 {
+ compatible = "brcm,bcm6756-hsspi", "brcm,bcmbca-hsspi-v1.1";
+ reg = <0xff801000 0x1000>,
+ <0xff802610 0x4>;
+ reg-names = "hsspi", "spim-ctrl";
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&hsspi>, <&hsspi_pll>;
+ clock-names = "hsspi", "pll";
+ num-cs = <8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml
new file mode 100644
index 000000000000..fa03cdd68e70
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm63xx-spi.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/brcm,bcm63xx-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM6348/BCM6358 SPI controller
+
+maintainers:
+ - Jonas Gorski <jonas.gorski@gmail.com>
+
+description: |
+ Broadcom "Low Speed" SPI controller found in many older MIPS based Broadband
+ SoCs.
+
+ This controller has a limitation that can not keep the chip select line active
+ between the SPI transfers within the same SPI message. This can terminate the
+ transaction to some SPI devices prematurely. The issue can be worked around by
+ the controller's prepend mode.
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - brcm,bcm6368-spi
+ - brcm,bcm6362-spi
+ - brcm,bcm63268-spi
+ - const: brcm,bcm6358-spi
+ - enum:
+ - brcm,bcm6348-spi
+ - brcm,bcm6358-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI master reference clock
+
+ clock-names:
+ items:
+ - const: spi
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@10000800 {
+ compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi";
+ reg = <0x10000800 0x70c>;
+ interrupts = <1>;
+ clocks = <&clkctl 9>;
+ clock-names = "spi";
+ num-cs = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
index ec5873919170..45975f40d943 100644
--- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
The Broadcom SPI controller is a SPI master found on various SOCs, including
- BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consits
+ BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consists
of:
MSPI : SPI master controller can read and write to a SPI slave device
BSPI : Broadcom SPI in combination with the MSPI hw IP provides acceleration
@@ -20,7 +20,7 @@ description: |
io with 3-byte and 4-byte addressing support.
Supported Broadcom SoCs have one instance of MSPI+BSPI controller IP.
- MSPI master can be used wihout BSPI. BRCMSTB SoCs have an additional instance
+ MSPI master can be used without BSPI. BRCMSTB SoCs have an additional instance
of a MSPI master without the BSPI to use with non flash slave devices that
use SPI protocol.
@@ -99,98 +99,98 @@ required:
examples:
- | # BRCMSTB SoC: SPI Master (MSPI+BSPI) for SPI-NOR access
spi@f03e3400 {
- compatible = "brcm,spi-brcmstb-qspi", "brcm,spi-bcm-qspi";
- reg = <0xf03e3400 0x188>, <0xf03e3200 0x50>, <0xf03e0920 0x4>;
- reg-names = "mspi", "bspi", "cs_reg";
- interrupts = <0x5>, <0x6>, <0x1>, <0x2>, <0x3>, <0x4>, <0x0>;
- interrupt-parent = <&gic>;
- interrupt-names = "mspi_done",
- "mspi_halted",
- "spi_lr_fullness_reached",
- "spi_lr_session_aborted",
- "spi_lr_impatient",
- "spi_lr_session_done",
- "spi_lr_overread";
- clocks = <&hif_spi>;
- #address-cells = <0x1>;
- #size-cells = <0x0>;
-
- flash@0 {
- #size-cells = <0x2>;
- #address-cells = <0x2>;
- compatible = "m25p80";
- reg = <0x0>;
- spi-max-frequency = <0x2625a00>;
- spi-cpol;
- spi-cpha;
- };
+ compatible = "brcm,spi-brcmstb-qspi", "brcm,spi-bcm-qspi";
+ reg = <0xf03e3400 0x188>, <0xf03e3200 0x50>, <0xf03e0920 0x4>;
+ reg-names = "mspi", "bspi", "cs_reg";
+ interrupts = <0x5>, <0x6>, <0x1>, <0x2>, <0x3>, <0x4>, <0x0>;
+ interrupt-parent = <&gic>;
+ interrupt-names = "mspi_done",
+ "mspi_halted",
+ "spi_lr_fullness_reached",
+ "spi_lr_session_aborted",
+ "spi_lr_impatient",
+ "spi_lr_session_done",
+ "spi_lr_overread";
+ clocks = <&hif_spi>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ flash@0 {
+ #size-cells = <0x2>;
+ #address-cells = <0x2>;
+ compatible = "m25p80";
+ reg = <0x0>;
+ spi-max-frequency = <0x2625a00>;
+ spi-cpol;
+ spi-cpha;
+ };
};
- | # BRCMSTB SoC: MSPI master for any SPI device
spi@f0416000 {
- clocks = <&upg_fixed>;
- compatible = "brcm,spi-brcmstb-mspi", "brcm,spi-bcm-qspi";
- reg = <0xf0416000 0x180>;
- reg-names = "mspi";
- interrupts = <0x14>;
- interrupt-parent = <&irq0_aon_intc>;
- interrupt-names = "mspi_done";
- #address-cells = <1>;
- #size-cells = <0>;
+ clocks = <&upg_fixed>;
+ compatible = "brcm,spi-brcmstb-mspi", "brcm,spi-bcm-qspi";
+ reg = <0xf0416000 0x180>;
+ reg-names = "mspi";
+ interrupts = <0x14>;
+ interrupt-parent = <&irq0_aon_intc>;
+ interrupt-names = "mspi_done";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
- | # iProc SoC
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@18027200 {
- compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
- reg = <0x18027200 0x184>,
- <0x18027000 0x124>,
- <0x1811c408 0x004>,
- <0x180273a0 0x01c>;
- reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
- interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "mspi_done",
- "mspi_halted",
- "spi_lr_fullness_reached",
- "spi_lr_session_aborted",
- "spi_lr_impatient",
- "spi_lr_session_done";
- clocks = <&iprocmed>;
- num-cs = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
+ reg = <0x18027200 0x184>,
+ <0x18027000 0x124>,
+ <0x1811c408 0x004>,
+ <0x180273a0 0x01c>;
+ reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mspi_done",
+ "mspi_halted",
+ "spi_lr_fullness_reached",
+ "spi_lr_session_aborted",
+ "spi_lr_impatient",
+ "spi_lr_session_done";
+ clocks = <&iprocmed>;
+ num-cs = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
- | # NS2 SoC
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@66470200 {
- compatible = "brcm,spi-ns2-qspi", "brcm,spi-bcm-qspi";
- reg = <0x66470200 0x184>,
- <0x66470000 0x124>,
- <0x67017408 0x004>,
- <0x664703a0 0x01c>;
- reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
- interrupts = <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "spi_l1_intr";
- clocks = <&iprocmed>;
- num-cs = <2>;
+ compatible = "brcm,spi-ns2-qspi", "brcm,spi-bcm-qspi";
+ reg = <0x66470200 0x184>,
+ <0x66470000 0x124>,
+ <0x67017408 0x004>,
+ <0x664703a0 0x01c>;
+ reg-names = "mspi", "bspi", "intr_regs", "intr_status_reg";
+ interrupts = <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "spi_l1_intr";
+ clocks = <&iprocmed>;
+ num-cs = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
#address-cells = <1>;
- #size-cells = <0>;
-
- flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "m25p80";
- reg = <0x0>;
- spi-max-frequency = <12500000>;
- spi-cpol;
- spi-cpha;
- };
+ #size-cells = <1>;
+ compatible = "m25p80";
+ reg = <0x0>;
+ spi-max-frequency = <12500000>;
+ spi-cpol;
+ spi-cpha;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index 4707294d8f59..53a52fb8b819 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence Quad SPI controller
+title: Cadence Quad/Octal SPI controller
maintainers:
- Vaishnav Achath <vaishnav.a@ti.com>
@@ -19,19 +19,69 @@ allOf:
then:
required:
- power-domains
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh7110-qspi
+ then:
+ properties:
+ resets:
+ minItems: 2
+ maxItems: 3
+
+ reset-names:
+ minItems: 2
+ maxItems: 3
+ items:
+ enum: [ qspi, qspi-ocp, rstc_ref ]
+
+ else:
+ properties:
+ resets:
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ qspi, qspi-ocp ]
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amd,pensando-elba-qspi
+ then:
+ properties:
+ cdns,fifo-depth:
+ enum: [ 128, 256, 1024 ]
+ default: 1024
+ else:
+ properties:
+ cdns,fifo-depth:
+ enum: [ 128, 256 ]
+ default: 128
properties:
compatible:
oneOf:
- items:
- enum:
- - ti,k2g-qspi
- - ti,am654-ospi
+ - amd,pensando-elba-qspi
+ - amd,versal2-ospi
- intel,lgm-qspi
- - xlnx,versal-ospi-1.0
- intel,socfpga-qspi
+ - mobileye,eyeq5-ospi
+ - starfive,jh7110-qspi
+ - ti,am654-ospi
+ - ti,k2g-qspi
+ - xlnx,versal-ospi-1.0
+ # The compatible is qspi-nor for historical reasons but such
+ # controllers are meant to be used with flashes of all kinds,
+ # ie. also NAND flashes, not only NOR flashes.
- const: cdns,qspi-nor
- const: cdns,qspi-nor
+ deprecated: true
reg:
items:
@@ -42,14 +92,22 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: ref
+ - items:
+ - const: ref
+ - const: ahb
+ - const: apb
cdns,fifo-depth:
description:
Size of the data FIFO in words.
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum: [ 128, 256 ]
- default: 128
+ $ref: /schemas/types.yaml#/definitions/uint32
cdns,fifo-width:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -79,20 +137,32 @@ properties:
maxItems: 1
resets:
- maxItems: 2
+ minItems: 2
+ maxItems: 3
reset-names:
- minItems: 1
- maxItems: 2
+ minItems: 2
+ maxItems: 3
items:
- enum: [ qspi, qspi-ocp ]
+ enum: [ qspi, qspi-ocp, rstc_ref ]
+
+patternProperties:
+ "^flash@[0-9a-f]+$":
+ type: object
+ $ref: cdns,qspi-nor-peripheral-props.yaml
+ additionalProperties: true
+ required:
+ - cdns,read-delay
+ - cdns,tshsl-ns
+ - cdns,tsd2d-ns
+ - cdns,tchsh-ns
+ - cdns,tslch-ns
required:
- compatible
- reg
- interrupts
- clocks
- - cdns,fifo-depth
- cdns,fifo-width
- cdns,trigger-address
- '#address-cells'
@@ -103,21 +173,26 @@ unevaluatedProperties: false
examples:
- |
qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa00000 0x1000>;
- interrupts = <0 151 4>;
- clocks = <&qspi_clk>;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x00000000>;
- resets = <&rst 0x1>, <&rst 0x2>;
- reset-names = "qspi", "qspi-ocp";
-
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0x0>;
- };
+ compatible = "intel,socfpga-qspi", "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff705000 0x1000>,
+ <0xffa00000 0x1000>;
+ interrupts = <0 151 4>;
+ clocks = <&qspi_clk>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ resets = <&rst 0x1>, <&rst 0x2>;
+ reset-names = "qspi", "qspi-ocp";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ cdns,read-delay = <4>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
index b8bb8a3dbf54..38a5795589de 100644
--- a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
@@ -2,8 +2,8 @@
# Copyright 2020-21 Cadence
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/cdns,xspi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/cdns,xspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence XSPI Controller
@@ -15,24 +15,27 @@ description: |
single, dual, quad or octal wire transmission modes for
read/write access to slaves such as SPI-NOR flash.
-allOf:
- - $ref: "spi-controller.yaml#"
-
properties:
compatible:
- const: cdns,xspi-nor
+ enum:
+ - cdns,xspi-nor
+ - marvell,cn10-xspi-nor
reg:
items:
- description: address and length of the controller register set
- description: address and length of the Slave DMA data port
- description: address and length of the auxiliary registers
+ - description: address and length of the xfer registers
+ minItems: 3
reg-names:
items:
- const: io
- const: sdma
- const: aux
+ - const: xfer
+ minItems: 3
interrupts:
maxItems: 1
@@ -42,6 +45,27 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,cn10-xspi-nor
+ then:
+ properties:
+ reg:
+ minItems: 4
+ reg-names:
+ minItems: 4
+ else:
+ properties:
+ reg:
+ maxItems: 3
+ reg-names:
+ maxItems: 3
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml b/Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml
new file mode 100644
index 000000000000..73980a27dc00
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cirrus,ep9301-spi.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cirrus,ep9301-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EP93xx SoC SPI controller
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-spi
+ - items:
+ - enum:
+ - cirrus,ep9302-spi
+ - cirrus,ep9307-spi
+ - cirrus,ep9312-spi
+ - cirrus,ep9315-spi
+ - const: cirrus,ep9301-spi
+
+ reg:
+ items:
+ - description: SPI registers region
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI Controller reference clock source
+
+ dmas:
+ items:
+ - description: rx DMA channel
+ - description: tx DMA channel
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/clock/cirrus,ep9301-syscon.h>
+ spi@808a0000 {
+ compatible = "cirrus,ep9301-spi";
+ reg = <0x808a0000 0x18>;
+ interrupt-parent = <&vic1>;
+ interrupts = <21>;
+ clocks = <&syscon EP93XX_CLK_SPI>;
+ dmas = <&dma1 10 2>, <&dma1 10 1>;
+ dma-names = "rx", "tx";
+ cs-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/fsl,dspi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/fsl,dspi-peripheral-props.yaml
new file mode 100644
index 000000000000..9b62b75e17a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/fsl,dspi-peripheral-props.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/fsl,dspi-peripheral-props.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Peripheral-specific properties for Freescale DSPI controller
+
+maintainers:
+ - Vladimir Oltean <olteanv@gmail.com>
+
+description:
+ See spi-peripheral-props.yaml for more info.
+
+properties:
+ fsl,spi-cs-sck-delay:
+ deprecated: true
+ description:
+ Delay in nanoseconds between activating chip select and the start of
+ clock signal, at the start of a transfer.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ fsl,spi-sck-cs-delay:
+ deprecated: true
+ description:
+ Delay in nanoseconds between stopping the clock signal and
+ deactivating chip select, at the end of a transfer.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/spi/fsl,dspi.yaml b/Documentation/devicetree/bindings/spi/fsl,dspi.yaml
new file mode 100644
index 000000000000..8dbda1ffb5eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/fsl,dspi.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/fsl,dspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Freescale DSPI controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,vf610-dspi
+ - fsl,ls1021a-v1.0-dspi
+ - fsl,ls1012a-dspi
+ - fsl,ls1028a-dspi
+ - fsl,ls1043a-dspi
+ - fsl,ls1046a-dspi
+ - fsl,ls1088a-dspi
+ - fsl,ls2080a-dspi
+ - fsl,ls2085a-dspi
+ - fsl,lx2160a-dspi
+ - nxp,s32g2-dspi
+ - items:
+ - enum:
+ - fsl,ls1012a-dspi
+ - fsl,ls1028a-dspi
+ - fsl,ls1043a-dspi
+ - fsl,ls1046a-dspi
+ - fsl,ls1088a-dspi
+ - const: fsl,ls1021a-v1.0-dspi
+ - items:
+ - const: fsl,ls2080a-dspi
+ - const: fsl,ls2085a-dspi
+ - items:
+ - const: fsl,lx2160a-dspi
+ - const: fsl,ls2085a-dspi
+ - items:
+ - const: nxp,s32g3-dspi
+ - const: nxp,s32g2-dspi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: dspi
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for TX
+ - description: DMA controller phandle and request line for RX
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ spi-num-chipselects:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The number of the chip native chipselect signals.
+ cs-gpios don't count against this number.
+
+ big-endian: true
+
+ bus-num:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: SoC-specific identifier for the SPI controller.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - spi-num-chipselects
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/vf610-clock.h>
+
+ spi@4002c000 {
+ compatible = "fsl,vf610-dspi";
+ reg = <0x4002c000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_DSPI0>;
+ clock-names = "dspi";
+ spi-num-chipselects = <5>;
+ bus-num = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dspi0_1>;
+ big-endian;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <16000000>;
+ spi-cpol;
+ spi-cpha;
+ spi-cs-setup-delay-ns = <100>;
+ spi-cs-hold-delay-ns = <50>;
+ };
+ };
+ # S32G3 in target mode
+ - |
+ spi@401d4000 {
+ compatible = "nxp,s32g3-dspi", "nxp,s32g2-dspi";
+ reg = <0x401d4000 0x1000>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 26>;
+ clock-names = "dspi";
+ spi-num-chipselects = <8>;
+ bus-num = <0>;
+ dmas = <&edma0 0 7>, <&edma0 0 8>;
+ dma-names = "tx", "rx";
+ spi-slave;
+ };
diff --git a/Documentation/devicetree/bindings/spi/fsl,espi.yaml b/Documentation/devicetree/bindings/spi/fsl,espi.yaml
new file mode 100644
index 000000000000..d267bbfaf02f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/fsl,espi.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/fsl,espi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale eSPI (Enhanced Serial Peripheral Interface) controller
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+properties:
+ compatible:
+ const: fsl,mpc8536-espi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ fsl,espi-num-chipselects:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 1, 4 ]
+ description: The number of the chipselect signals.
+
+ fsl,csbef:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description: Chip select assertion time in bits before frame starts
+
+ fsl,csaft:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 15
+ description: Chip select negation time in bits after frame ends
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - fsl,espi-num-chipselects
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi@110000 {
+ compatible = "fsl,mpc8536-espi";
+ reg = <0x110000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <53 IRQ_TYPE_EDGE_FALLING>;
+ fsl,espi-num-chipselects = <4>;
+ fsl,csbef = <1>;
+ fsl,csaft = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
index e58644558412..1d10cfbad86c 100644
--- a/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
@@ -9,9 +9,6 @@ title: Freescale Quad Serial Peripheral Interface (QuadSPI)
maintainers:
- Han Xu <han.xu@nxp.com>
-allOf:
- - $ref: "spi-controller.yaml#"
-
properties:
compatible:
oneOf:
@@ -22,6 +19,7 @@ properties:
- fsl,imx6ul-qspi
- fsl,ls1021a-qspi
- fsl,ls2080a-qspi
+ - spacemit,k1-qspi
- items:
- enum:
- fsl,ls1043a-qspi
@@ -54,6 +52,11 @@ properties:
- const: qspi_en
- const: qspi
+ resets:
+ items:
+ - description: SoC QSPI reset
+ - description: SoC QSPI bus reset
+
required:
- compatible
- reg
@@ -62,6 +65,18 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: spacemit,k1-qspi
+ then:
+ properties:
+ resets: false
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/fsl,spi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi.yaml
new file mode 100644
index 000000000000..d74792fc9bf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/fsl,spi.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/fsl,spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale SPI (Serial Peripheral Interface) controller
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+properties:
+ compatible:
+ enum:
+ - fsl,spi
+ - aeroflexgaisler,spictrl
+
+ reg:
+ maxItems: 1
+
+ cell-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ QE SPI subblock index.
+ 0: QE subblock SPI1
+ 1: QE subblock SPI2
+
+ mode:
+ description: SPI operation mode
+ enum:
+ - cpu
+ - cpu-qe
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ description: input clock frequency to non FSL_SOC cores
+
+ cs-gpios: true
+
+ fsl,spisel_boot:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ For the MPC8306 and MPC8309, specifies that the SPISEL_BOOT signal is used
+ as chip select for a slave device. Use reg = <number of gpios> in the
+ corresponding child node, i.e. 0 if the cs-gpios property is not present.
+
+required:
+ - compatible
+ - reg
+ - mode
+ - interrupts
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi@4c0 {
+ compatible = "fsl,spi";
+ reg = <0x4c0 0x40>;
+ cell-index = <0>;
+ interrupts = <82 0>;
+ mode = "cpu";
+ cs-gpios = <&gpio 18 IRQ_TYPE_EDGE_RISING // device reg=<0>
+ &gpio 19 IRQ_TYPE_EDGE_RISING>; // device reg=<1>
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
index 50df1a40bbe3..14cac0e6e0a1 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
@@ -10,7 +10,7 @@ maintainers:
- Shawn Guo <shawnguo@kernel.org>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -24,6 +24,16 @@ properties:
- const: fsl,imx53-ecspi
- items:
- enum:
+ - fsl,imx25-cspi
+ - fsl,imx50-cspi
+ - fsl,imx51-cspi
+ - fsl,imx53-cspi
+ - const: fsl,imx35-cspi
+ - items:
+ - const: fsl,imx8mp-ecspi
+ - const: fsl,imx6ul-ecspi
+ - items:
+ - enum:
- fsl,imx50-ecspi
- fsl,imx6q-ecspi
- fsl,imx6sx-ecspi
@@ -34,7 +44,6 @@ properties:
- fsl,imx8mq-ecspi
- fsl,imx8mm-ecspi
- fsl,imx8mn-ecspi
- - fsl,imx8mp-ecspi
- const: fsl,imx51-ecspi
reg:
diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt
deleted file mode 100644
index 0654380eb751..000000000000
--- a/Documentation/devicetree/bindings/spi/fsl-spi.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* SPI (Serial Peripheral Interface)
-
-Required properties:
-- cell-index : QE SPI subblock index.
- 0: QE subblock SPI1
- 1: QE subblock SPI2
-- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl".
-- mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
-- reg : Offset and length of the register set for the device
-- interrupts : <a b> where a is the interrupt number and b is a
- field that represents an encoding of the sense and level
- information for the interrupt. This should be encoded based on
- the information in section 2) depending on the type of interrupt
- controller you have.
-- clock-frequency : input clock frequency to non FSL_SOC cores
-
-Optional properties:
-- cs-gpios : specifies the gpio pins to be used for chipselects.
- The gpios will be referred to as reg = <index> in the SPI child nodes.
- If unspecified, a single SPI device without a chip select can be used.
-- fsl,spisel_boot : for the MPC8306 and MPC8309, specifies that the
- SPISEL_BOOT signal is used as chip select for a slave device. Use
- reg = <number of gpios> in the corresponding child node, i.e. 0 if
- the cs-gpios property is not present.
-
-Example:
- spi@4c0 {
- cell-index = <0>;
- compatible = "fsl,spi";
- reg = <4c0 40>;
- interrupts = <82 0>;
- interrupt-parent = <700>;
- mode = "cpu";
- cs-gpios = <&gpio 18 1 // device reg=<0>
- &gpio 19 1>; // device reg=<1>
- };
-
-
-* eSPI (Enhanced Serial Peripheral Interface)
-
-Required properties:
-- compatible : should be "fsl,mpc8536-espi".
-- reg : Offset and length of the register set for the device.
-- interrupts : should contain eSPI interrupt, the device has one interrupt.
-- fsl,espi-num-chipselects : the number of the chipselect signals.
-
-Optional properties:
-- fsl,csbef: chip select assertion time in bits before frame starts
-- fsl,csaft: chip select negation time in bits after frame ends
-
-Example:
- spi@110000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc8536-espi";
- reg = <0x110000 0x1000>;
- interrupts = <53 0x2>;
- interrupt-parent = <&mpic>;
- fsl,espi-num-chipselects = <4>;
- fsl,csbef = <1>;
- fsl,csaft = <1>;
- };
diff --git a/Documentation/devicetree/bindings/spi/ibm,spi-fsi.yaml b/Documentation/devicetree/bindings/spi/ibm,spi-fsi.yaml
new file mode 100644
index 000000000000..d7fec4c3a801
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ibm,spi-fsi.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/ibm,spi-fsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM FSI-attached SPI Controller
+
+maintainers:
+ - Eddie James <eajames@linux.ibm.com>
+
+description:
+ A SPI controller found on IBM Power processors, accessed over FSI from a
+ service processor. This node will always be a child node of an ibm,fsi2spi
+ node.
+
+properties:
+ compatible:
+ enum:
+ - ibm,spi-fsi
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ fsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi@0 {
+ compatible = "ibm,spi-fsi";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@0 {
+ compatible = "atmel,at25";
+ reg = <0>;
+ size = <0x80000>;
+ address-width = <24>;
+ pagesize = <256>;
+ spi-max-frequency = <1000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml
index 360f76c226d9..c08d55b900bb 100644
--- a/Documentation/devicetree/bindings/spi/ingenic,spi.yaml
+++ b/Documentation/devicetree/bindings/spi/ingenic,spi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/ingenic,spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs SPI controller devicetree bindings
+title: Ingenic SoCs SPI controller
maintainers:
- Artur Rojek <contact@artur-rojek.eu>
diff --git a/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml b/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml
new file mode 100644
index 000000000000..de9d32feadf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,ls2k-spi.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/loongson,ls2k-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson SPI controller
+
+maintainers:
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls2k1000-spi
+ - items:
+ - enum:
+ - loongson,ls2k0500-spi
+ - const: loongson,ls2k1000-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi0: spi@1fff0220{
+ compatible = "loongson,ls2k1000-spi";
+ reg = <0x1fff0220 0x10>;
+ clocks = <&clk 17>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml b/Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml
new file mode 100644
index 000000000000..61caa1d86188
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/marvell,armada-3700-spi.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/marvell,armada-3700-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 3700 SPI Controller
+
+description:
+ The SPI controller on Marvell Armada 3700 SoC.
+
+maintainers:
+ - Kousik Sanagavarapu <five231003@gmail.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: marvell,armada-3700-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ num-cs:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi0: spi@10600 {
+ compatible = "marvell,armada-3700-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10600 0x5d>;
+ clocks = <&nb_perih_clk 7>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ num-cs = <4>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml b/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
index 0abcac385e7c..0a1bada8f800 100644
--- a/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
+++ b/Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
@@ -5,17 +5,22 @@
$id: http://devicetree.org/schemas/spi/marvell,mmp2-ssp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: PXA2xx SSP SPI Controller bindings
+title: PXA2xx SSP SPI Controller
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
-allOf:
- - $ref: spi-controller.yaml#
-
properties:
compatible:
- const: marvell,mmp2-ssp
+ enum:
+ - marvell,mmp2-ssp
+ - mrvl,ce4100-ssp
+ - mvrl,pxa168-ssp
+ - mrvl,pxa25x-ssp
+ - mvrl,pxa25x-nssp
+ - mrvl,pxa27x-ssp
+ - mrvl,pxa3xx-ssp
+ - mrvl,pxa910-ssp
interrupts:
maxItems: 1
@@ -26,6 +31,16 @@ properties:
clocks:
maxItems: 1
+ dmas:
+ items:
+ - description: Receive DMA
+ - description: Transmit DMA
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
ready-gpios:
description: |
GPIO used to signal a SPI master that the FIFO is filled and we're
@@ -41,6 +56,18 @@ required:
dependencies:
ready-gpios: [ spi-slave ]
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: marvell,mmp2-ssp
+ then:
+ properties:
+ dmas: false
+ dma-names: false
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/marvell,orion-spi.yaml b/Documentation/devicetree/bindings/spi/marvell,orion-spi.yaml
new file mode 100644
index 000000000000..7f5ec1d7f59b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/marvell,orion-spi.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/marvell,orion-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Orion SPI controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory CLEMENT <gregory.clement@bootlin.com>
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - marvell,orion-spi
+ - marvell,armada-380-spi # For ap80x and cp11x
+ - items:
+ - enum:
+ - marvell,armada-370-spi
+ - marvell,armada-375-spi
+ - marvell,armada-380-spi
+ - marvell,armada-390-spi
+ - marvell,armada-xp-spi
+ - const: marvell,orion-spi
+
+ cell-index:
+ description: Instance id for the SPI controller
+ deprecated: true
+
+ reg:
+ minItems: 1
+ items:
+ - description: control registers
+ - description: CS0 MBUS target/attribute registers for direct mode
+ - description: CS1 MBUS target/attribute registers for direct mode
+ - description: CS2 MBUS target/attribute registers for direct mode
+ - description: CS3 MBUS target/attribute registers for direct mode
+ - description: CS4 MBUS target/attribute registers for direct mode
+ - description: CS5 MBUS target/attribute registers for direct mode
+ - description: CS6 MBUS target/attribute registers for direct mode
+ - description: CS7 MBUS target/attribute registers for direct mode
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: axi
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@10600 {
+ compatible = "marvell,orion-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ reg = <0x10600 0x28>;
+ clocks = <&coreclk 0>;
+ interrupts = <23>;
+ };
+ - |
+ #define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ spi@10600 {
+ compatible = "marvell,orion-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
+ <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
+ <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
+ <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
+ <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
+ <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
+ <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
+ <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
+ <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
+ clocks = <&coreclk 0>;
+ interrupts = <23>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
index 8d2a6c084eab..3bf3eb1f8728 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
@@ -10,7 +10,7 @@ maintainers:
- Leilk Liu <leilk.liu@mediatek.com>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -33,16 +33,24 @@ properties:
- const: mediatek,mt6765-spi
- items:
- enum:
+ - mediatek,mt7981-spi-ipm
- mediatek,mt7986-spi-ipm
+ - mediatek,mt7988-spi-quad
+ - mediatek,mt7988-spi-single
- mediatek,mt8188-spi-ipm
- const: mediatek,spi-ipm
- items:
- enum:
+ - mediatek,mt8196-spi
+ - const: mediatek,mt6991-spi
+ - items:
+ - enum:
- mediatek,mt2701-spi
- mediatek,mt2712-spi
- mediatek,mt6589-spi
- mediatek,mt6765-spi
- mediatek,mt6893-spi
+ - mediatek,mt6991-spi
- mediatek,mt7622-spi
- mediatek,mt8135-spi
- mediatek,mt8173-spi
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml
index 6e6e02c91780..1e5e89a693c3 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-snfi.yaml
@@ -18,14 +18,12 @@ description: |
using the accompanying ECC engine. There should be only one spi
slave device following generic spi bindings.
-allOf:
- - $ref: /schemas/spi/spi-controller.yaml#
-
properties:
compatible:
enum:
- mediatek,mt7622-snand
- mediatek,mt7629-snand
+ - mediatek,mt7986-snand
reg:
items:
@@ -36,19 +34,20 @@ properties:
- description: NFI interrupt
clocks:
- items:
- - description: clock used for the controller
- - description: clock used for the SPI bus
+ minItems: 2
+ maxItems: 3
clock-names:
- items:
- - const: nfi_clk
- - const: pad_clk
+ minItems: 2
+ maxItems: 3
nand-ecc-engine:
description: device-tree node of the accompanying ECC engine.
$ref: /schemas/types.yaml#/definitions/phandle
+ mediatek,rx-latch-latency-ns:
+ description: Data read latch latency, unit is nanoseconds.
+
required:
- compatible
- reg
@@ -57,6 +56,43 @@ required:
- clock-names
- nand-ecc-engine
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt7622-snand
+ - mediatek,mt7629-snand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: clock used for the controller
+ - description: clock used for the SPI bus
+ clock-names:
+ items:
+ - const: nfi_clk
+ - const: pad_clk
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt7986-snand
+ then:
+ properties:
+ clocks:
+ items:
+ - description: clock used for the controller
+ - description: clock used for the SPI bus
+ - description: clock used for the AHB bus
+ clock-names:
+ items:
+ - const: nfi_clk
+ - const: pad_clk
+ - const: nfi_hclk
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml
index 7977799a8ee1..d19c9f73978f 100644
--- a/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml
@@ -10,7 +10,7 @@ maintainers:
- Leilk Liu <leilk.liu@mediatek.com>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml
index 1051690e3753..636338d24bdf 100644
--- a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml
@@ -13,17 +13,21 @@ description:
maintainers:
- Conor Dooley <conor.dooley@microchip.com>
-allOf:
- - $ref: spi-controller.yaml#
-
properties:
compatible:
oneOf:
- items:
- - const: microchip,mpfs-qspi
+ - enum:
+ - microchip,mpfs-qspi
+ - microchip,pic64gx-qspi
- const: microchip,coreqspi-rtl-v2
- - const: microchip,coreqspi-rtl-v2 #FPGA QSPI
- - const: microchip,mpfs-spi
+ - enum:
+ - microchip,coreqspi-rtl-v2 # FPGA QSPI
+ - microchip,corespi-rtl-v5 # FPGA CoreSPI
+ - microchip,mpfs-spi
+ - items:
+ - const: microchip,pic64gx-spi
+ - const: microchip,mpfs-spi
reg:
maxItems: 1
@@ -37,12 +41,102 @@ properties:
clocks:
maxItems: 1
+ microchip,apb-datawidth:
+ description: APB bus data width in bits.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [8, 16, 32]
+ default: 8
+
+ microchip,frame-size:
+ description: |
+ Number of bits per SPI frame, as configured in Libero.
+ In Motorola and TI modes, this corresponds directly
+ to the requested frame size. For NSC mode this is set
+ to 9 + the required data frame size.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 4
+ maximum: 32
+ default: 8
+
+ microchip,protocol-configuration:
+ description: CoreSPI protocol selection. Determines operating mode
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - motorola
+ - ti
+ - nsc
+ default: motorola
+
+ microchip,motorola-mode:
+ description: Motorola SPI mode selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3]
+ default: 3
+
+ microchip,ssel-active:
+ description: |
+ Keep SSEL asserted between frames when using the Motorola protocol.
+ When present, the controller keeps SSEL active across contiguous
+ transfers and deasserts only when the overall transfer completes.
+ type: boolean
+
required:
- compatible
- reg
- interrupts
- clocks
+allOf:
+ - $ref: spi-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,mpfs-spi
+ then:
+ properties:
+ num-cs:
+ default: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,mpfs-spi
+ not:
+ required:
+ - cs-gpios
+ then:
+ properties:
+ num-cs:
+ maximum: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,corespi-rtl-v5
+ then:
+ properties:
+ num-cs:
+ minimum: 1
+ maximum: 8
+ default: 8
+
+ fifo-depth:
+ minimum: 1
+ maximum: 32
+ default: 4
+
+ else:
+ properties:
+ microchip,apb-datawidth: false
+ microchip,frame-size: false
+ microchip,protocol-configuration: false
+ microchip,motorola-mode: false
+ microchip,ssel-active: false
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml b/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
index 3fd0a8adfe9a..303f6dca89c0 100644
--- a/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mikrotik,rb4xx-spi.yaml
@@ -11,7 +11,7 @@ maintainers:
- Bert Vermeulen <bert@biot.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
index 9202c44b4478..221fe6e2ef53 100644
--- a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/spi/mxicy,mx25f0a-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Macronix SPI controller device tree bindings
+title: Macronix SPI controller
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.yaml b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
index 51f8c664323e..0cf8e7269ba9 100644
--- a/Documentation/devicetree/bindings/spi/mxs-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
@@ -10,7 +10,7 @@ maintainers:
- Marek Vasut <marex@denx.de>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -24,6 +24,9 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 1
+
dmas:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt b/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt
index c63ce4cc0a80..fb38e96d395f 100644
--- a/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt
+++ b/Documentation/devicetree/bindings/spi/nuvoton,npcm-fiu.txt
@@ -51,7 +51,7 @@ fiu3: spi@c00000000 {
clocks = <&clk NPCM7XX_CLK_AHB>;
pinctrl-names = "default";
pinctrl-0 = <&spi3_pins>;
- spi-nor@0 {
+ flash@0 {
...
};
};
diff --git a/Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt b/Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt
deleted file mode 100644
index a4e72e52af59..000000000000
--- a/Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Nuvoton NPCM Peripheral Serial Peripheral Interface(PSPI) controller driver
-
-Nuvoton NPCM7xx SOC support two PSPI channels.
-
-Required properties:
- - compatible : "nuvoton,npcm750-pspi" for Poleg NPCM7XX.
- "nuvoton,npcm845-pspi" for Arbel NPCM8XX.
- - #address-cells : should be 1. see spi-bus.txt
- - #size-cells : should be 0. see spi-bus.txt
- - specifies physical base address and size of the register.
- - interrupts : contain PSPI interrupt.
- - clocks : phandle of PSPI reference clock.
- - clock-names: Should be "clk_apb5".
- - pinctrl-names : a pinctrl state named "default" must be defined.
- - pinctrl-0 : phandle referencing pin configuration of the device.
- - resets : phandle to the reset control for this device.
- - cs-gpios: Specifies the gpio pins to be used for chipselects.
- See: Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
-- clock-frequency : Input clock frequency to the PSPI block in Hz.
- Default is 25000000 Hz.
-
-spi0: spi@f0200000 {
- compatible = "nuvoton,npcm750-pspi";
- reg = <0xf0200000 0x1000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pspi1_pins>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk NPCM7XX_CLK_APB5>;
- clock-names = "clk_apb5";
- resets = <&rstc NPCM7XX_RESET_IPSRST2 NPCM7XX_RESET_PSPI1>
- cs-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.yaml
new file mode 100644
index 000000000000..db0fb872020a
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nuvoton,npcm-pspi.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nuvoton,npcm-pspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Peripheral SPI (PSPI) Controller
+
+maintainers:
+ - Tomer Maimon <tmaimon77@gmail.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+description:
+ Nuvoton NPCM Peripheral Serial Peripheral Interface (PSPI) controller.
+ Nuvoton NPCM7xx SOC supports two PSPI channels.
+ Nuvoton NPCM8xx SOC support one PSPI channel.
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,npcm750-pspi # Poleg NPCM7XX
+ - nuvoton,npcm845-pspi # Arbel NPCM8XX
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: PSPI reference clock.
+
+ clock-names:
+ items:
+ - const: clk_apb5
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/nuvoton,npcm7xx-reset.h>
+ #include "dt-bindings/gpio/gpio.h"
+ spi0: spi@f0200000 {
+ compatible = "nuvoton,npcm750-pspi";
+ reg = <0xf0200000 0x1000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pspi1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM7XX_CLK_APB5>;
+ clock-names = "clk_apb5";
+ resets = <&rstc NPCM7XX_RESET_IPSRST2 NPCM7XX_RESET_PSPI1>;
+ cs-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/nuvoton,wpcm450-fiu.yaml b/Documentation/devicetree/bindings/spi/nuvoton,wpcm450-fiu.yaml
new file mode 100644
index 000000000000..c97bf48b56b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nuvoton,wpcm450-fiu.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nuvoton,wpcm450-fiu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton WPCM450 Flash Interface Unit (FIU)
+
+maintainers:
+ - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ const: nuvoton,wpcm450-fiu
+
+ reg:
+ items:
+ - description: FIU registers
+ - description: Memory-mapped flash contents
+
+ reg-names:
+ items:
+ - const: control
+ - const: memory
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ nuvoton,shm:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the SHM block (see ../arm/nuvoton,shm.yaml)
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@c8000000 {
+ compatible = "nuvoton,wpcm450-fiu";
+ reg = <0xc8000000 0x1000>, <0xc0000000 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg-names = "control", "memory";
+ clocks = <&clk 0>;
+ nuvoton,shm = <&shm>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
deleted file mode 100644
index db8e0d71c5bc..000000000000
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-NVIDIA Tegra114 SPI controller.
-
-Required properties:
-- compatible : For Tegra114, must contain "nvidia,tegra114-spi".
- Otherwise, must contain '"nvidia,<chip>-spi", "nvidia,tegra114-spi"' where
- <chip> is tegra124, tegra132, or tegra210.
-- reg: Should contain SPI registers location and length.
-- interrupts: Should contain SPI interrupts.
-- clock-names : Must include the following entries:
- - spi
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - spi
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-Optional properties:
-- nvidia,tx-clk-tap-delay: Delays the clock going out to the external device
- with this tap value. This property is used to tune the outgoing data from
- Tegra SPI master with respect to outgoing Tegra SPI master clock.
- Tap values vary based on the platform design trace lengths from Tegra SPI
- to corresponding slave devices. Valid tap values are from 0 thru 63.
-- nvidia,rx-clk-tap-delay: Delays the clock coming in from the external device
- with this tap value. This property is used to adjust the Tegra SPI master
- clock with respect to the data from the SPI slave device.
- Tap values vary based on the platform design trace lengths from Tegra SPI
- to corresponding slave devices. Valid tap values are from 0 thru 63.
-
-Example:
-
-spi@7000d600 {
- compatible = "nvidia,tegra114-spi";
- reg = <0x7000d600 0x200>;
- interrupts = <0 82 0x04>;
- spi-max-frequency = <25000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car 44>;
- clock-names = "spi";
- resets = <&tegra_car 44>;
- reset-names = "spi";
- dmas = <&apbdma 16>, <&apbdma 16>;
- dma-names = "rx", "tx";
- <spi-client>@<bus_num> {
- ...
- ...
- nvidia,rx-clk-tap-delay = <0>;
- nvidia,tx-clk-tap-delay = <16>;
- ...
- };
-
-};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml
new file mode 100644
index 000000000000..58222ffa53d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,tegra114-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra114 SPI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra114-spi
+ - items:
+ - enum:
+ - nvidia,tegra210-spi
+ - nvidia,tegra124-spi
+ - const: nvidia,tegra114-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI module clock
+
+ clock-names:
+ items:
+ - const: spi
+
+ resets:
+ items:
+ - description: SPI module reset
+
+ reset-names:
+ items:
+ - const: spi
+
+ dmas:
+ items:
+ - description: DMA channel for the reception FIFO
+ - description: DMA channel for the transmission FIFO
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+allOf:
+ - $ref: spi-controller.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ spi@7000d600 {
+ compatible = "nvidia,tegra114-spi";
+ reg = <0x7000d600 0x200>;
+ interrupts = <0 82 0x04>;
+ clocks = <&tegra_car 44>;
+ clock-names = "spi";
+ resets = <&tegra_car 44>;
+ reset-names = "spi";
+ dmas = <&apbdma 16>, <&apbdma 16>;
+ dma-names = "rx", "tx";
+
+ spi-max-frequency = <25000000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ nvidia,rx-clk-tap-delay = <0>;
+ nvidia,tx-clk-tap-delay = <16>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
deleted file mode 100644
index c212491929b5..000000000000
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-NVIDIA Tegra20 SFLASH controller.
-
-Required properties:
-- compatible : should be "nvidia,tegra20-sflash".
-- reg: Should contain SFLASH registers location and length.
-- interrupts: Should contain SFLASH interrupts.
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - spi
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Example:
-
-spi@7000c380 {
- compatible = "nvidia,tegra20-sflash";
- reg = <0x7000c380 0x80>;
- interrupts = <0 39 0x04>;
- spi-max-frequency = <25000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car 43>;
- resets = <&tegra_car 43>;
- reset-names = "spi";
- dmas = <&apbdma 11>, <&apbdma 11>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml
new file mode 100644
index 000000000000..e245bad85a25
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,tegra20-sflash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20 SFLASH controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra20-sflash
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: spi
+
+ dmas:
+ items:
+ - description: DMA channel used for reception
+ - description: DMA channel used for transmission
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+allOf:
+ - $ref: spi-controller.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@7000c380 {
+ compatible = "nvidia,tegra20-sflash";
+ reg = <0x7000c380 0x80>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <25000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car TEGRA20_CLK_SPI>;
+ resets = <&tegra_car 43>;
+ reset-names = "spi";
+ dmas = <&apbdma 11>, <&apbdma 11>;
+ dma-names = "rx", "tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
deleted file mode 100644
index 40d80b93e327..000000000000
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-NVIDIA Tegra20/Tegra30 SLINK controller.
-
-Required properties:
-- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
-- reg: Should contain SLINK registers location and length.
-- interrupts: Should contain SLINK interrupts.
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - spi
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx
- - tx
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Example:
-
-spi@7000d600 {
- compatible = "nvidia,tegra20-slink";
- reg = <0x7000d600 0x200>;
- interrupts = <0 82 0x04>;
- spi-max-frequency = <25000000>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car 44>;
- resets = <&tegra_car 44>;
- reset-names = "spi";
- dmas = <&apbdma 16>, <&apbdma 16>;
- dma-names = "rx", "tx";
-};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml
new file mode 100644
index 000000000000..291c25ec015d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,tegra20-slink.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra20/30 SLINK controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-slink
+ - nvidia,tegra30-slink
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: spi
+
+ dmas:
+ items:
+ - description: DMA channel used for reception
+ - description: DMA channel used for transmission
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ operating-points-v2:
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ power-domains:
+ items:
+ - description: phandle to the core power domain
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+allOf:
+ - $ref: spi-controller.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@7000d600 {
+ compatible = "nvidia,tegra20-slink";
+ reg = <0x7000d600 0x200>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <25000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car TEGRA20_CLK_SBC2>;
+ resets = <&tegra_car 44>;
+ reset-names = "spi";
+ dmas = <&apbdma 16>, <&apbdma 16>;
+ dma-names = "rx", "tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
index 6b733e5c1163..8b3640280559 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
@@ -10,9 +10,6 @@ maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jonathan Hunter <jonathanh@nvidia.com>
-allOf:
- - $ref: "spi-controller.yaml#"
-
properties:
compatible:
enum:
@@ -47,9 +44,13 @@ properties:
- const: rx
- const: tx
+ iommus:
+ maxItems: 1
+
patternProperties:
- "@[0-9a-f]+":
+ "@[0-9a-f]+$":
type: object
+ additionalProperties: true
properties:
spi-rx-bus-width:
@@ -68,31 +69,43 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: nvidia,tegra234-qspi
+ then:
+ properties:
+ iommus: false
+
examples:
- |
#include <dt-bindings/clock/tegra210-car.h>
#include <dt-bindings/reset/tegra210-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
spi@70410000 {
- compatible = "nvidia,tegra210-qspi";
- reg = <0x70410000 0x1000>;
- interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&tegra_car TEGRA210_CLK_QSPI>,
- <&tegra_car TEGRA210_CLK_QSPI_PM>;
- clock-names = "qspi", "qspi_out";
- resets = <&tegra_car 211>;
- dmas = <&apbdma 5>, <&apbdma 5>;
- dma-names = "rx", "tx";
-
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <104000000>;
- spi-tx-bus-width = <2>;
- spi-rx-bus-width = <2>;
- nvidia,tx-clk-tap-delay = <0>;
- nvidia,rx-clk-tap-delay = <0>;
- };
+ compatible = "nvidia,tegra210-qspi";
+ reg = <0x70410000 0x1000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&tegra_car TEGRA210_CLK_QSPI>,
+ <&tegra_car TEGRA210_CLK_QSPI_PM>;
+ clock-names = "qspi", "qspi_out";
+ resets = <&tegra_car 211>;
+ dmas = <&apbdma 5>, <&apbdma 5>;
+ dma-names = "rx", "tx";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <104000000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ nvidia,tx-clk-tap-delay = <0>;
+ nvidia,rx-clk-tap-delay = <0>;
+ };
};
diff --git a/Documentation/devicetree/bindings/spi/nxp,lpc3220-spi.yaml b/Documentation/devicetree/bindings/spi/nxp,lpc3220-spi.yaml
new file mode 100644
index 000000000000..d5f780912f21
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nxp,lpc3220-spi.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nxp,lpc3220-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC3220 SPI controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,lpc3220-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc32xx-clock.h>
+
+ spi@20088000 {
+ compatible = "nxp,lpc3220-spi";
+ reg = <0x20088000 0x1000>;
+ clocks = <&clk LPC32XX_CLK_SPI1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/nxp,sc18is.yaml b/Documentation/devicetree/bindings/spi/nxp,sc18is.yaml
new file mode 100644
index 000000000000..43753a94837c
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nxp,sc18is.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nxp,sc18is.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP SC18IS602/SC18IS603 I2C to SPI bridge
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,sc18is602
+ - nxp,sc18is602b
+ - nxp,sc18is603
+
+ reg:
+ maxItems: 1
+
+ clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 7372000
+ description:
+ external oscillator clock frequency. The clock-frequency property is
+ relevant and needed only if the chip has an external oscillator
+ (SC18IS603).
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi@28 {
+ compatible = "nxp,sc18is603";
+ reg = <0x28>;
+ clock-frequency = <14744000>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.yaml b/Documentation/devicetree/bindings/spi/omap-spi.yaml
index 9952199cae11..ff4d361707bd 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/omap-spi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/omap-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SPI controller bindings for OMAP and K3 SoCs
+title: SPI Controller on OMAP and K3 SoCs
maintainers:
- Aswath Govindraju <a-govindraju@ti.com>
@@ -68,7 +68,7 @@ properties:
dma-names:
description:
List of DMA request names. These strings correspond 1:1 with
- the DMA sepecifiers listed in dmas. The string names is to be
+ the DMA specifiers listed in dmas. The string names is to be
"rxN" and "txN" for RX and TX requests, respectively. Where N
is the chip select number.
minItems: 1
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
index 2e20ca313ec1..edf399681d7a 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
@@ -9,7 +9,7 @@ title: GENI based Qualcomm Universal Peripheral (QUP) Serial Peripheral Interfac
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description:
The QUP v3 core is a GENI based AHB slave that provides a common data path
@@ -25,6 +25,7 @@ description:
allOf:
- $ref: /schemas/spi/spi-controller.yaml#
+ - $ref: /schemas/soc/qcom/qcom,se-common-props.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
index b622bb7363ec..1696ac46a660 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/qcom,spi-qcom-qspi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/qcom,spi-qcom-qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Quad Serial Peripheral Interface (QSPI)
@@ -30,6 +29,9 @@ properties:
reg:
maxItems: 1
+ iommus:
+ maxItems: 1
+
interrupts:
maxItems: 1
@@ -53,6 +55,11 @@ properties:
- const: qspi-config
- const: qspi-memory
+ operating-points-v2: true
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -88,7 +95,6 @@ examples:
spi-tx-bus-width = <2>;
spi-rx-bus-width = <2>;
};
-
};
};
...
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml
new file mode 100644
index 000000000000..7d0571feb46d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/qcom,spi-qpic-snand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QPIC NAND controller
+
+maintainers:
+ - Md sadre Alam <quic_mdalam@quicinc.com>
+
+description:
+ The QCOM QPIC-SPI-NAND flash controller is an extended version of
+ the QCOM QPIC NAND flash controller. It can work both in serial
+ and parallel mode. It supports typical SPI-NAND page cache
+ operations in single, dual or quad IO mode with pipelined ECC
+ encoding/decoding using the QPIC ECC HW engine.
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,ipq5018-snand
+ - qcom,ipq5332-snand
+ - qcom,ipq5424-snand
+ - const: qcom,ipq9574-snand
+ - const: qcom,ipq9574-snand
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: core
+ - const: aon
+ - const: iom
+
+ dmas:
+ items:
+ - description: tx DMA channel
+ - description: rx DMA channel
+ - description: cmd DMA channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+ - const: cmd
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,ipq9574-gcc.h>
+ spi@79b0000 {
+ compatible = "qcom,ipq9574-snand";
+ reg = <0x1ac00000 0x800>;
+
+ clocks = <&gcc GCC_QPIC_CLK>,
+ <&gcc GCC_QPIC_AHB_CLK>,
+ <&gcc GCC_QPIC_IO_MACRO_CLK>;
+ clock-names = "core", "aon", "iom";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spi-nand";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-ecc-engine = <&qpic_nand>;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml
index 93f14dd01afc..7df21b15a0d4 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.yaml
@@ -9,7 +9,7 @@ title: Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI)
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
description:
The QUP core is an AHB slave that provides a common data path (an output FIFO
@@ -44,9 +44,17 @@ properties:
- const: tx
- const: rx
+ interconnects:
+ maxItems: 1
+
interrupts:
maxItems: 1
+ operating-points-v2: true
+
+ power-domains:
+ maxItems: 1
+
reg:
maxItems: 1
@@ -62,7 +70,9 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
+ #include <dt-bindings/interconnect/qcom,msm8996.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
spi@7575000 {
compatible = "qcom,spi-qup-v2.2.1";
@@ -76,6 +86,9 @@ examples:
pinctrl-1 = <&blsp1_spi1_sleep>;
dmas = <&blsp1_dma 12>, <&blsp1_dma 13>;
dma-names = "tx", "rx";
+ power-domains = <&rpmpd MSM8996_VDDCX>;
+ operating-points-v2 = <&spi_opp_table>;
+ interconnects = <&pnoc MASTER_BLSP_1 &bimc SLAVE_EBI_CH0>;
#address-cells = <1>;
#size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml
index 2f938c293f70..70330d945a70 100644
--- a/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml
@@ -11,7 +11,7 @@ maintainers:
- Birger Koblitz <mail@birger-koblitz.de>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml
new file mode 100644
index 000000000000..36d79a90552b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/realtek,rtl9301-snand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI-NAND Flash Controller for Realtek RTL9300 SoCs
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+description:
+ The Realtek RTL9300 SoCs have a built in SPI-NAND controller. It supports
+ typical SPI-NAND page cache operations in single, dual or quad IO mode.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - realtek,rtl9302b-snand
+ - realtek,rtl9302c-snand
+ - realtek,rtl9303-snand
+ - const: realtek,rtl9301-snand
+ - const: realtek,rtl9301-snand
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@1a400 {
+ compatible = "realtek,rtl9302c-snand", "realtek,rtl9301-snand";
+ reg = <0x1a400 0x44>;
+ interrupt-parent = <&intc>;
+ interrupts = <19>;
+ clocks = <&lx_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spi-nand";
+ reg = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
index f45d3b75d6de..0ef3f8421986 100644
--- a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml
@@ -21,7 +21,7 @@ properties:
- enum:
- renesas,rspi-r7s72100 # RZ/A1H
- renesas,rspi-r7s9210 # RZ/A2
- - renesas,r9a07g043-rspi # RZ/G2UL
+ - renesas,r9a07g043-rspi # RZ/G2UL and RZ/Five
- renesas,r9a07g044-rspi # RZ/G2{L,LC}
- renesas,r9a07g054-rspi # RZ/V2L
- const: renesas,rspi-rz
@@ -141,15 +141,15 @@ examples:
#include <dt-bindings/power/r8a7791-sysc.h>
qspi: spi@e6b10000 {
- compatible = "renesas,qspi-r8a7791", "renesas,qspi";
- reg = <0xe6b10000 0x2c>;
- interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 917>;
- dmas = <&dmac0 0x17>, <&dmac0 0x18>, <&dmac1 0x17>, <&dmac1 0x18>;
- dma-names = "tx", "rx", "tx", "rx";
- power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
- resets = <&cpg 917>;
- num-cs = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
+ compatible = "renesas,qspi-r8a7791", "renesas,qspi";
+ reg = <0xe6b10000 0x2c>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 917>;
+ dmas = <&dmac0 0x17>, <&dmac0 0x18>, <&dmac1 0x17>, <&dmac1 0x18>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 917>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
new file mode 100644
index 000000000000..069557a587b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/renesas,rzv2h-rspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2H(P) Renesas Serial Peripheral Interface (RSPI)
+
+maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - renesas,r9a09g057-rspi # RZ/V2H(P)
+ - renesas,r9a09g077-rspi # RZ/T2H
+ - items:
+ - const: renesas,r9a09g056-rspi # RZ/V2N
+ - const: renesas,r9a09g057-rspi
+ - items:
+ - const: renesas,r9a09g087-rspi # RZ/N2H
+ - const: renesas,r9a09g077-rspi # RZ/T2H
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Idle Interrupt
+ - description: Error Interrupt
+ - description: Communication End Interrupt
+ - description: Receive Buffer Full Interrupt
+ - description: Transmit Buffer Empty Interrupt
+
+ interrupt-names:
+ items:
+ - const: idle
+ - const: error
+ - const: end
+ - const: rx
+ - const: tx
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: presetn
+ - const: tresetn
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - '#address-cells'
+ - '#size-cells'
+
+allOf:
+ - $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g057-rspi
+ then:
+ properties:
+ clocks:
+ minItems: 3
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: pclk_sfr
+ - const: tclk
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g077-rspi
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: pclkspi
+
+ resets: false
+ reset-names: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/renesas-cpg-mssr.h>
+ spi@12800800 {
+ compatible = "renesas,r9a09g057-rspi";
+
+ reg = <0x12800800 0x400>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 113 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 504 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 505 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "idle", "error", "end", "rx", "tx";
+ clocks = <&cpg CPG_MOD 0x5a>,
+ <&cpg CPG_MOD 0x5b>,
+ <&cpg CPG_MOD 0x5c>;
+ clock-names = "pclk", "pclk_sfr", "tclk";
+ resets = <&cpg 0x7f>, <&cpg 0x80>;
+ reset-names = "presetn", "tresetn";
+ power-domains = <&cpg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml
new file mode 100644
index 000000000000..bed829837df1
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2m-csi.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/renesas,rzv2m-csi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M Clocked Serial Interface (CSI)
+
+maintainers:
+ - Fabrizio Castro <fabrizio.castro.jz@renesas.com>
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: renesas,rzv2m-csi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The clock used to generate the output clock (CSICLK)
+ - description: Internal clock to access the registers (PCLK)
+
+ clock-names:
+ items:
+ - const: csiclk
+ - const: pclk
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ renesas,csi-no-ss:
+ type: boolean
+ description:
+ The CSI Slave Selection (SS) pin won't be used to enable transmission and
+ reception. Only available when in target mode.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - '#address-cells'
+ - '#size-cells'
+
+dependencies:
+ renesas,csi-no-ss: [ spi-slave ]
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/r9a09g011-cpg.h>
+ csi4: spi@a4020200 {
+ compatible = "renesas,rzv2m-csi";
+ reg = <0xa4020200 0x80>;
+ interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A09G011_CSI4_CLK>,
+ <&cpg CPG_MOD R9A09G011_CPERI_GRPH_PCLK>;
+ clock-names = "csiclk", "pclk";
+ resets = <&cpg R9A09G011_CSI_GPH_PRESETN>;
+ power-domains = <&cpg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
index 491a695a2deb..e0c7047ae8ad 100644
--- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
@@ -4,14 +4,11 @@
$id: http://devicetree.org/schemas/spi/renesas,sh-msiof.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Renesas MSIOF SPI controller
+title: Renesas MSIOF SPI / I2S controller
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
-allOf:
- - $ref: spi-controller.yaml#
-
properties:
compatible:
oneOf:
@@ -54,6 +51,7 @@ properties:
- renesas,msiof-r8a779a0 # R-Car V3U
- renesas,msiof-r8a779f0 # R-Car S4-8
- renesas,msiof-r8a779g0 # R-Car V4H
+ - renesas,msiof-r8a779h0 # R-Car V4M
- const: renesas,rcar-gen4-msiof # generic R-Car Gen4
# compatible device
- items:
@@ -145,27 +143,56 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
default: 64
+ # for MSIOF-I2S
+ port:
+ $ref: ../sound/audio-graph-port.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- reg
- interrupts
- - '#address-cells'
- - '#size-cells'
+ - clocks
+ - power-domains
+
+allOf:
+ # additional "required""
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: renesas,sh-mobile-msiof
+ then:
+ required:
+ - resets
+
+ # If it doesn't have "port" node, it is "MSIOF-SPI"
+ - if:
+ not:
+ required:
+ - port
+ then:
+ allOf:
+ - $ref: spi-controller.yaml#
unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/r8a7791-clock.h>
- #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/r8a7791-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a7791-sysc.h>
msiof0: spi@e6e20000 {
compatible = "renesas,msiof-r8a7791", "renesas,rcar-gen2-msiof";
reg = <0xe6e20000 0x0064>;
- interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>;
+ interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 000>;
dmas = <&dmac0 0x51>, <&dmac0 0x52>;
dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
+ resets = <&cpg 0>;
#address-cells = <1>;
#size-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml b/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml
index 339fb39529f3..ac1503de0478 100644
--- a/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml
+++ b/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml
@@ -47,6 +47,8 @@ properties:
patternProperties:
"^flash@[0-3]$":
type: object
+ additionalProperties: true
+
properties:
reg:
minimum: 0
diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml
index e0a465d70b0a..1ce8b2770a4a 100644
--- a/Documentation/devicetree/bindings/spi/samsung,spi.yaml
+++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml
@@ -17,13 +17,19 @@ properties:
compatible:
oneOf:
- enum:
- - samsung,s3c2443-spi # for S3C2443, S3C2416 and S3C2450
+ - google,gs101-spi
- samsung,s3c6410-spi
- samsung,s5pv210-spi # for S5PV210 and S5PC110
- samsung,exynos4210-spi
- samsung,exynos5433-spi
+ - samsung,exynos850-spi
- samsung,exynosautov9-spi
- tesla,fsd-spi
+ - items:
+ - enum:
+ - samsung,exynos8895-spi
+ - samsung,exynosautov920-spi
+ - const: samsung,exynos850-spi
- const: samsung,exynos7-spi
deprecated: true
@@ -35,8 +41,6 @@ properties:
minItems: 2
maxItems: 3
- cs-gpios: true
-
dmas:
minItems: 2
maxItems: 2
@@ -76,8 +80,6 @@ required:
- compatible
- clocks
- clock-names
- - dmas
- - dma-names
- interrupts
- reg
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
index d33b72fabc5d..5c87fc8a845d 100644
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -10,7 +10,7 @@ maintainers:
- Mark Brown <broonie@kernel.org>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
- if:
properties:
compatible:
@@ -37,6 +37,17 @@ allOf:
else:
required:
- interrupts
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amd,pensando-elba-spi
+ then:
+ required:
+ - amd,pensando-elba-syscon
+ else:
+ properties:
+ amd,pensando-elba-syscon: false
properties:
compatible:
@@ -45,24 +56,25 @@ properties:
enum:
- snps,dw-apb-ssi
- snps,dwc-ssi-1.01a
- - description: Microsemi Ocelot/Jaguar2 SoC SPI Controller
- items:
- - enum:
- - mscc,ocelot-spi
- - mscc,jaguar2-spi
- - const: snps,dw-apb-ssi
- description: Microchip Sparx5 SoC SPI Controller
const: microchip,sparx5-spi
- description: Amazon Alpine SPI Controller
const: amazon,alpine-dw-apb-ssi
- - description: Renesas RZ/N1 SPI Controller
+ - description: Vendor controllers which use snps,dw-apb-ssi as fallback
items:
- - const: renesas,rzn1-spi
+ - enum:
+ - mscc,ocelot-spi
+ - mscc,jaguar2-spi
+ - renesas,rzn1-spi
+ - sophgo,sg2042-spi
+ - thead,th1520-spi
- const: snps,dw-apb-ssi
- description: Intel Keem Bay SPI Controller
const: intel,keembay-ssi
- - description: Intel Thunder Bay SPI Controller
- const: intel,thunderbay-ssi
+ - description: Intel Mount Evans Integrated Management Complex SPI Controller
+ const: intel,mountevans-imc-ssi
+ - description: AMD Pensando Elba SoC SPI Controller
+ const: amd,pensando-elba-spi
- description: Baikal-T1 SPI Controller
const: baikal,bt1-ssi
- description: Baikal-T1 System Boot SPI Controller
@@ -71,9 +83,7 @@ properties:
const: canaan,k210-spi
- description: Renesas RZ/N1 SPI Controller
items:
- - enum:
- - renesas,r9a06g032-spi # RZ/N1D
- - renesas,r9a06g033-spi # RZ/N1S
+ - const: renesas,r9a06g032-spi # RZ/N1D
- const: renesas,rzn1-spi # RZ/N1
reg:
@@ -136,9 +146,17 @@ properties:
of the designware controller, and the upper limit is also subject to
controller configuration.
+ amd,pensando-elba-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ Block address to control SPI chip-selects. The Elba SoC system controller
+ provides an interface to override the native DWC SSI CS control.
+
patternProperties:
- "^.*@[0-9a-f]+$":
+ "@[0-9a-f]+$":
type: object
+ additionalProperties: true
+
properties:
reg:
minimum: 0
diff --git a/Documentation/devicetree/bindings/spi/socionext,f-ospi.yaml b/Documentation/devicetree/bindings/spi/socionext,f-ospi.yaml
new file mode 100644
index 000000000000..9878d1446552
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/socionext,f-ospi.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/socionext,f-ospi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext F_OSPI controller
+
+description: |
+ The Socionext F_OSPI is a controller used to interface with flash
+ memories using the SPI communication interface.
+
+maintainers:
+ - Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: socionext,f-ospi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ num-cs:
+ minimum: 1
+ maximum: 4
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ ospi0: spi@80000000 {
+ compatible = "socionext,f-ospi";
+ reg = <0x80000000 0x1000>;
+ clocks = <&clks 0>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spansion,s25fl128s", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/socionext,synquacer-spi.yaml b/Documentation/devicetree/bindings/spi/socionext,synquacer-spi.yaml
new file mode 100644
index 000000000000..45cbe744c7ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/socionext,synquacer-spi.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/socionext,synquacer-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext SynQuacer HS-SPI Controller
+
+maintainers:
+ - Masahisa Kojima <masahisa.kojima@linaro.org>
+ - Jassi Brar <jaswinder.singh@linaro.org>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: socionext,synquacer-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: core clock
+ - description: rate clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: iHCLK
+ - const: iPCLK
+
+ interrupts:
+ items:
+ - description: Receive Interrupt
+ - description: Transmit Interrupt
+ - description: Fault Interrupt
+
+ socionext,use-rtm:
+ type: boolean
+ description: Enable using "retimed clock" for RX
+
+ socionext,set-aces:
+ type: boolean
+ description: Enable same active clock edges field to be set
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@ff110000 {
+ compatible = "socionext,synquacer-spi";
+ reg = <0xff110000 0x1000>;
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_hsspi>;
+ clock-names = "iHCLK";
+ socionext,use-rtm;
+ socionext,set-aces;
+ };
+...
diff --git a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
index 597fc4e6b01c..c96131ebbea1 100644
--- a/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/socionext,uniphier-spi.yaml
@@ -17,9 +17,6 @@ allOf:
- $ref: spi-controller.yaml#
properties:
- "#address-cells": true
- "#size-cells": true
-
compatible:
const: socionext,uniphier-scssi
diff --git a/Documentation/devicetree/bindings/spi/spi-armada-3700.txt b/Documentation/devicetree/bindings/spi/spi-armada-3700.txt
deleted file mode 100644
index 1564aa8c02cd..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-armada-3700.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Marvell Armada 3700 SPI Controller
-
-Required Properties:
-
-- compatible: should be "marvell,armada-3700-spi"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The interrupt number. The interrupt specifier format depends on
- the interrupt controller and of its driver.
-- clocks: Must contain the clock source, usually from the North Bridge clocks.
-- num-cs: The number of chip selects that is supported by this SPI Controller
-- #address-cells: should be 1.
-- #size-cells: should be 0.
-
-Example:
-
- spi0: spi@10600 {
- compatible = "marvell,armada-3700-spi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x10600 0x5d>;
- clocks = <&nb_perih_clk 7>;
- interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
- num-cs = <4>;
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt b/Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt
deleted file mode 100644
index 37b29ee13860..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-bcm63xx-hsspi.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Binding for Broadcom BCM6328 High Speed SPI controller
-
-Required properties:
-- compatible: must contain of "brcm,bcm6328-hsspi".
-- reg: Base address and size of the controllers memory area.
-- interrupts: Interrupt for the SPI block.
-- clocks: phandles of the SPI clock and the PLL clock.
-- clock-names: must be "hsspi", "pll".
-- #address-cells: <1>, as required by generic SPI binding.
-- #size-cells: <0>, also as required by generic SPI binding.
-
-Optional properties:
-- num-cs: some controllers have less than 8 cs signals. Defaults to 8
- if absent.
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
- spi@10001000 {
- compatible = "brcm,bcm6328-hsspi";
- reg = <0x10001000 0x600>;
-
- interrupts = <29>;
-
- clocks = <&clkctl 9>, <&hsspi_pll>;
- clock-names = "hsspi", "pll";
-
- num-cs = <2>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt b/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt
deleted file mode 100644
index 1c16f6692613..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-bcm63xx.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Binding for Broadcom BCM6348/BCM6358 SPI controller
-
-Required properties:
-- compatible: must contain one of "brcm,bcm6348-spi", "brcm,bcm6358-spi".
-- reg: Base address and size of the controllers memory area.
-- interrupts: Interrupt for the SPI block.
-- clocks: phandle of the SPI clock.
-- clock-names: has to be "spi".
-- #address-cells: <1>, as required by generic SPI binding.
-- #size-cells: <0>, also as required by generic SPI binding.
-
-Optional properties:
-- num-cs: some controllers have less than 8 cs signals. Defaults to 8
- if absent.
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
- spi@10000800 {
- compatible = "brcm,bcm6368-spi", "brcm,bcm6358-spi";
- reg = <0x10000800 0x70c>;
-
- interrupts = <1>;
-
- clocks = <&clkctl 9>;
- clock-names = "spi";
-
- num-cs = <5>;
-
- #address-cells = <1>;
- #size-cells = <0>;
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.yaml b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
index 82d0ca5c00f3..347bed0c4956 100644
--- a/Documentation/devicetree/bindings/spi/spi-cadence.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.yaml
@@ -4,19 +4,25 @@
$id: http://devicetree.org/schemas/spi/spi-cadence.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence SPI controller Device Tree Bindings
+title: Cadence SPI controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
- enum:
- - cdns,spi-r1p6
- - xlnx,zynq-spi-r1p6
+ oneOf:
+ - enum:
+ - xlnx,zynq-spi-r1p6
+ - items:
+ - enum:
+ - xlnx,zynqmp-spi-r1p6
+ - xlnx,versal-net-spi-r1p6
+ - cix,sky1-spi-r1p6
+ - const: cdns,spi-r1p6
reg:
maxItems: 1
@@ -49,6 +55,19 @@ properties:
enum: [ 0, 1 ]
default: 0
+ power-domains:
+ maxItems: 1
+
+ label:
+ description: Descriptive name of the SPI controller.
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: spi
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml
index 01042a7f382e..3b8e990e30c4 100644
--- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/spi-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SPI Controller Generic Binding
+title: SPI Controller Common Properties
maintainers:
- Mark Brown <broonie@kernel.org>
@@ -17,7 +17,7 @@ description: |
properties:
$nodename:
- pattern: "^spi(@.*|-[0-9a-f])*$"
+ pattern: "^spi(@.*|-([0-9]|[1-9][0-9]+))?$"
"#address-cells":
enum: [0, 1]
@@ -69,6 +69,26 @@ properties:
Should be generally avoided and be replaced by
spi-cs-high + ACTIVE_HIGH.
+ The simplest way to obtain an active-high CS signal is to configure the
+ controller's cs-gpio property with the ACTIVE_HIGH flag and set the
+ peripheral's spi-cs-high property. See example below for a better
+ understanding.
+
+ fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Size of the RX and TX data FIFOs in bytes.
+
+ rx-fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Size of the RX data FIFO in bytes.
+
+ tx-fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Size of the TX data FIFO in bytes.
+
num-cs:
$ref: /schemas/types.yaml#/definitions/uint32
description:
@@ -91,9 +111,10 @@ properties:
- compatible
patternProperties:
- "^.*@[0-9a-f]+$":
+ "@[0-9a-f]+$":
type: object
$ref: spi-peripheral-props.yaml
+ additionalProperties: true
properties:
spi-3wire:
@@ -115,6 +136,10 @@ patternProperties:
- compatible
- reg
+dependencies:
+ rx-fifo-depth: [ tx-fifo-depth ]
+ tx-fifo-depth: [ rx-fifo-depth ]
+
allOf:
- if:
not:
@@ -128,6 +153,14 @@ allOf:
properties:
"#address-cells":
const: 0
+ - not:
+ required:
+ - fifo-depth
+ - rx-fifo-depth
+ - not:
+ required:
+ - fifo-depth
+ - tx-fifo-depth
additionalProperties: true
@@ -161,3 +194,23 @@ examples:
stacked-memories = /bits/ 64 <0x10000000 0x10000000>;
};
};
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi@20204000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204000 0x1000>;
+ interrupts = <2 22>;
+ clocks = <&clk_spi>;
+ cs-gpios = <&gpio 8 GPIO_ACTIVE_HIGH>;
+
+ display@0 {
+ compatible = "lg,lg4573";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ spi-cs-high;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
deleted file mode 100644
index 30a79da9c039..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-ARM Freescale DSPI controller
-
-Required properties:
-- compatible : must be one of:
- "fsl,vf610-dspi",
- "fsl,ls1021a-v1.0-dspi",
- "fsl,ls1012a-dspi" (optionally followed by "fsl,ls1021a-v1.0-dspi"),
- "fsl,ls1028a-dspi",
- "fsl,ls1043a-dspi" (optionally followed by "fsl,ls1021a-v1.0-dspi"),
- "fsl,ls1046a-dspi" (optionally followed by "fsl,ls1021a-v1.0-dspi"),
- "fsl,ls1088a-dspi" (optionally followed by "fsl,ls1021a-v1.0-dspi"),
- "fsl,ls2080a-dspi" (optionally followed by "fsl,ls2085a-dspi"),
- "fsl,ls2085a-dspi",
- "fsl,lx2160a-dspi",
-- reg : Offset and length of the register set for the device
-- interrupts : Should contain SPI controller interrupt
-- clocks: from common clock binding: handle to dspi clock.
-- clock-names: from common clock binding: Shall be "dspi".
-- pinctrl-0: pin control group to be used for this controller.
-- pinctrl-names: must contain a "default" entry.
-- spi-num-chipselects : the number of the chipselect signals.
-
-Optional property:
-- big-endian: If present the dspi device's registers are implemented
- in big endian mode.
-- bus-num : the slave chip chipselect signal number.
-
-Optional SPI slave node properties:
-- fsl,spi-cs-sck-delay: a delay in nanoseconds between activating chip
- select and the start of clock signal, at the start of a transfer.
-- fsl,spi-sck-cs-delay: a delay in nanoseconds between stopping the clock
- signal and deactivating chip select, at the end of a transfer.
-
-Example:
-
-dspi0@4002c000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,vf610-dspi";
- reg = <0x4002c000 0x1000>;
- interrupts = <0 67 0x04>;
- clocks = <&clks VF610_CLK_DSPI0>;
- clock-names = "dspi";
- spi-num-chipselects = <5>;
- bus-num = <0>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_dspi0_1>;
- big-endian;
-
- sflash: at26df081a@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "atmel,at26df081a";
- spi-max-frequency = <16000000>;
- spi-cpol;
- spi-cpha;
- reg = <0>;
- linux,modalias = "m25p80";
- modal = "at26df081a";
- fsl,spi-cs-sck-delay = <100>;
- fsl,spi-sck-cs-delay = <50>;
- };
-};
-
-
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
index 8b44284d30c6..a82360bed188 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
@@ -7,10 +7,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Low Power SPI (LPSPI) for i.MX
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -18,11 +20,18 @@ properties:
- enum:
- fsl,imx7ulp-spi
- fsl,imx8qxp-spi
+ - nxp,s32g2-lpspi
- items:
- enum:
- fsl,imx8ulp-spi
- fsl,imx93-spi
+ - fsl,imx94-spi
+ - fsl,imx95-spi
- const: fsl,imx7ulp-spi
+ - items:
+ - const: nxp,s32g3-lpspi
+ - const: nxp,s32g2-lpspi
+
reg:
maxItems: 1
@@ -56,6 +65,16 @@ properties:
this property to re-config the chipselect value in the LPSPI driver.
type: boolean
+ num-cs:
+ description:
+ number of chip selects.
+ minimum: 1
+ maximum: 2
+ default: 1
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -80,4 +99,5 @@ examples:
clock-names = "per", "ipg";
spi-slave;
fsl,spi-only-use-cs1-sel;
+ num-cs = <2>;
};
diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.yaml b/Documentation/devicetree/bindings/spi/spi-gpio.yaml
index 0d0b6d9dad1c..9ce1df93d4c3 100644
--- a/Documentation/devicetree/bindings/spi/spi-gpio.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/spi-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SPI-GPIO devicetree bindings
+title: SPI-GPIO
maintainers:
- Rob Herring <robh@kernel.org>
@@ -14,7 +14,7 @@ description:
dedicated GPIO lines.
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
properties:
compatible:
@@ -41,7 +41,7 @@ properties:
num-chipselects:
description: Number of chipselect lines. Should be <0> if a single device
with no chip select is connected.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
# Deprecated properties
gpio-sck: false
diff --git a/Documentation/devicetree/bindings/spi/spi-mux.yaml b/Documentation/devicetree/bindings/spi/spi-mux.yaml
index 7ea79f6d33f3..b1e2a97be699 100644
--- a/Documentation/devicetree/bindings/spi/spi-mux.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-mux.yaml
@@ -30,8 +30,8 @@ description: |
+------------+
allOf:
- - $ref: "/schemas/spi/spi-controller.yaml#"
- - $ref: "/schemas/spi/spi-peripheral-props.yaml#"
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
@@ -46,7 +46,6 @@ properties:
required:
- compatible
- reg
- - spi-max-frequency
- mux-controls
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
index 1b552c298277..902db92da832 100644
--- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
@@ -11,16 +11,23 @@ maintainers:
- Kuldeep Singh <singh.kuldeep87k@gmail.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
- enum:
- - nxp,imx8dxl-fspi
- - nxp,imx8mm-fspi
- - nxp,imx8mp-fspi
- - nxp,imx8qxp-fspi
- - nxp,lx2160a-fspi
+ oneOf:
+ - enum:
+ - nxp,imx8dxl-fspi
+ - nxp,imx8mm-fspi
+ - nxp,imx8mp-fspi
+ - nxp,imx8qxp-fspi
+ - nxp,imx8ulp-fspi
+ - nxp,lx2160a-fspi
+ - items:
+ - enum:
+ - nxp,imx93-fspi
+ - nxp,imx95-fspi
+ - const: nxp,imx8mm-fspi
reg:
items:
@@ -45,6 +52,9 @@ properties:
- const: fspi_en
- const: fspi
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt
deleted file mode 100644
index 8434a65fc12a..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-orion.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Marvell Orion SPI device
-
-Required properties:
-- compatible : should be on of the following:
- - "marvell,orion-spi" for the Orion, mv78x00, Kirkwood and Dove SoCs
- - "marvell,armada-370-spi", for the Armada 370 SoCs
- - "marvell,armada-375-spi", for the Armada 375 SoCs
- - "marvell,armada-380-spi", for the Armada 38x SoCs
- - "marvell,armada-390-spi", for the Armada 39x SoCs
- - "marvell,armada-xp-spi", for the Armada XP SoCs
-- reg : offset and length of the register set for the device.
- This property can optionally have additional entries to configure
- the SPI direct access mode that some of the Marvell SoCs support
- additionally to the normal indirect access (PIO) mode. The values
- for the MBus "target" and "attribute" are defined in the Marvell
- SoC "Functional Specifications" Manual in the chapter "Marvell
- Core Processor Address Decoding".
- The eight register sets following the control registers refer to
- chip-select lines 0 through 7 respectively.
-- cell-index : Which of multiple SPI controllers is this.
-- clocks : pointers to the reference clocks for this device, the first
- one is the one used for the clock on the spi bus, the
- second one is optional and is the clock used for the
- functional part of the controller
-
-Optional properties:
-- interrupts : Is currently not used.
-- clock-names : names of used clocks, mandatory if the second clock is
- used, the name must be "core", and "axi" (the latter
- is only for Armada 7K/8K).
-
-
-Example:
- spi@10600 {
- compatible = "marvell,orion-spi";
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- reg = <0x10600 0x28>;
- interrupts = <23>;
- };
-
-Example with SPI direct mode support (optionally):
- spi0: spi@10600 {
- compatible = "marvell,orion-spi";
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- reg = <MBUS_ID(0xf0, 0x01) 0x10600 0x28>, /* control */
- <MBUS_ID(0x01, 0x1e) 0 0xffffffff>, /* CS0 */
- <MBUS_ID(0x01, 0x5e) 0 0xffffffff>, /* CS1 */
- <MBUS_ID(0x01, 0x9e) 0 0xffffffff>, /* CS2 */
- <MBUS_ID(0x01, 0xde) 0 0xffffffff>, /* CS3 */
- <MBUS_ID(0x01, 0x1f) 0 0xffffffff>, /* CS4 */
- <MBUS_ID(0x01, 0x5f) 0 0xffffffff>, /* CS5 */
- <MBUS_ID(0x01, 0x9f) 0 0xffffffff>, /* CS6 */
- <MBUS_ID(0x01, 0xdf) 0 0xffffffff>; /* CS7 */
- interrupts = <23>;
- };
-
-To enable the direct mode, the board specific 'ranges' property in the
-'soc' node needs to add the entries for the desired SPI controllers
-and its chip-selects that are used in the direct mode instead of PIO
-mode. Here an example for this (SPI controller 0, device 1 and SPI
-controller 1, device 2 are used in direct mode. All other SPI device
-are used in the default indirect (PIO) mode):
- soc {
- /*
- * Enable the SPI direct access by configuring an entry
- * here in the board-specific ranges property
- */
- ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000>, /* internal regs */
- <MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>, /* BootROM */
- <MBUS_ID(0x01, 0x5e) 0 0 0xf1100000 0x10000>, /* SPI0-DEV1 */
- <MBUS_ID(0x01, 0x9a) 0 0 0xf1110000 0x10000>; /* SPI1-DEV2 */
-
-For further information on the MBus bindings, please see the MBus
-DT documentation:
-Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
index dca677f9e1b9..8b6e8fc009db 100644
--- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
@@ -8,12 +8,13 @@ title: Peripheral-specific properties for a SPI bus.
description:
Many SPI controllers need to add properties to peripheral devices. They could
- be common properties like spi-max-frequency, spi-cpha, etc. or they could be
- controller specific like delay in clock or data lines, etc. These properties
- need to be defined in the peripheral node because they are per-peripheral and
- there can be multiple peripherals attached to a controller. All those
- properties are listed here. The controller specific properties should go in
- their own separate schema that should be referenced from here.
+ be common properties like spi-max-frequency, spi-cs-high, etc. or they could
+ be controller specific like delay in clock or data lines, etc. These
+ properties need to be defined in the peripheral node because they are
+ per-peripheral and there can be multiple peripherals attached to a
+ controller. All those properties are listed here. The controller specific
+ properties should go in their own separate schema that should be referenced
+ from here.
maintainers:
- Mark Brown <broonie@kernel.org>
@@ -44,6 +45,21 @@ properties:
description:
Maximum SPI clocking speed of the device in Hz.
+ spi-cs-setup-delay-ns:
+ description:
+ Delay in nanoseconds to be introduced by the controller after CS is
+ asserted.
+
+ spi-cs-hold-delay-ns:
+ description:
+ Delay in nanoseconds to be introduced by the controller before CS is
+ de-asserted.
+
+ spi-cs-inactive-delay-ns:
+ description:
+ Delay in nanoseconds to be introduced by the controller after CS is
+ de-asserted.
+
spi-rx-bus-width:
description:
Bus width to the SPI bus used for read transfers.
@@ -98,9 +114,17 @@ properties:
minItems: 2
maxItems: 4
+ st,spi-midi-ns:
+ deprecated: true
+ description: |
+ Only for STM32H7, (Master Inter-Data Idleness) minimum time
+ delay in nanoseconds inserted between two consecutive data frames.
+
# The controller specific properties go here.
allOf:
+ - $ref: arm,pl022-peripheral-props.yaml#
- $ref: cdns,qspi-nor-peripheral-props.yaml#
+ - $ref: fsl,dspi-peripheral-props.yaml#
- $ref: samsung,spi-peripheral-props.yaml#
- $ref: nvidia,tegra210-quad-peripheral-props.yaml#
diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
index 0e382119c64f..7f174b7d0a26 100644
--- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml
@@ -10,7 +10,8 @@ maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
+ - $ref: /schemas/arm/primecell.yaml#
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
@@ -45,7 +46,7 @@ properties:
description: delay in ms following transfer completion before the
runtime power management system suspends the device. A setting of 0
indicates no delay and the device will be suspended immediately.
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
pl022,rt:
description: indicates the controller should run the message pump with realtime
@@ -73,57 +74,6 @@ properties:
resets:
maxItems: 1
-patternProperties:
- "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-f]+$":
- type: object
- # SPI slave nodes must be children of the SPI master node and can
- # contain the following properties.
- properties:
- pl022,interface:
- description: SPI interface type
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum:
- - 0 # SPI
- - 1 # Texas Instruments Synchronous Serial Frame Format
- - 2 # Microwire (Half Duplex)
-
- pl022,com-mode:
- description: Specifies the transfer mode
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum:
- - 0 # interrupt mode
- - 1 # polling mode
- - 2 # DMA mode
- default: 1
-
- pl022,rx-level-trig:
- description: Rx FIFO watermark level
- $ref: "/schemas/types.yaml#/definitions/uint32"
- minimum: 0
- maximum: 4
-
- pl022,tx-level-trig:
- description: Tx FIFO watermark level
- $ref: "/schemas/types.yaml#/definitions/uint32"
- minimum: 0
- maximum: 4
-
- pl022,ctrl-len:
- description: Microwire interface - Control length
- $ref: "/schemas/types.yaml#/definitions/uint32"
- minimum: 0x03
- maximum: 0x1f
-
- pl022,wait-state:
- description: Microwire interface - Wait state
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum: [0, 1]
-
- pl022,duplex:
- description: Microwire interface - Full/Half duplex
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum: [0, 1]
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 66e49947b703..ce6762c92fda 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -11,7 +11,7 @@ description:
as flash and display controllers using the SPI communication interface.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
maintainers:
- Heiko Stuebner <heiko@sntech.de>
@@ -34,7 +34,11 @@ properties:
- rockchip,rk3328-spi
- rockchip,rk3368-spi
- rockchip,rk3399-spi
+ - rockchip,rk3506-spi
+ - rockchip,rk3528-spi
+ - rockchip,rk3562-spi
- rockchip,rk3568-spi
+ - rockchip,rk3576-spi
- rockchip,rk3588-spi
- rockchip,rv1126-spi
- const: rockchip,rk3066-spi
diff --git a/Documentation/devicetree/bindings/spi/spi-sc18is602.txt b/Documentation/devicetree/bindings/spi/spi-sc18is602.txt
deleted file mode 100644
index 02f9033270a2..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-sc18is602.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-NXP SC18IS602/SCIS603
-
-Required properties:
- - compatible : Should be one of
- "nxp,sc18is602"
- "nxp,sc18is602b"
- "nxp,sc18is603"
- - reg: I2C bus address
-
-Optional properties:
- - clock-frequency : external oscillator clock frequency. If not
- specified, the SC18IS602 default frequency (7372000) will be used.
-
-The clock-frequency property is relevant and needed only if the chip has an
-external oscillator (SC18IS603).
-
-Example:
-
- sc18is603@28 {
- compatible = "nxp,sc18is603";
- reg = <0x28>;
- clock-frequency = <14744000>;
- }
diff --git a/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml b/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml
new file mode 100644
index 000000000000..0e7ead763705
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/spi-sg2044-nor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SG2044 SPI NOR controller
+
+maintainers:
+ - Longbin Li <looong.bin@gmail.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - sophgo,sg2042-spifmc-nor
+ - sophgo,sg2044-spifmc-nor
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi@1000000 {
+ compatible = "sophgo,sg2044-spifmc-nor";
+ reg = <0x1000000 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk 0>;
+ interrupts = <37 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&rst 0>;
+ };
diff --git a/Documentation/devicetree/bindings/spi/spi-sifive.yaml b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
index 6e7e394fc1e4..5bffefb9c7eb 100644
--- a/Documentation/devicetree/bindings/spi/spi-sifive.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-sifive.yaml
@@ -12,7 +12,7 @@ maintainers:
- Palmer Dabbelt <palmer@sifive.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
@@ -51,14 +51,14 @@ properties:
sifive,fifo-depth:
description:
Depth of hardware queues; defaults to 8
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [8]
default: 8
sifive,max-bits-per-word:
description:
Maximum bits per word; defaults to 8
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4, 5, 6, 7, 8]
default: 8
diff --git a/Documentation/devicetree/bindings/spi/spi-sprd.txt b/Documentation/devicetree/bindings/spi/spi-sprd.txt
deleted file mode 100644
index 3c7eacce0ee3..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-sprd.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Spreadtrum SPI Controller
-
-Required properties:
-- compatible: Should be "sprd,sc9860-spi".
-- reg: Offset and length of SPI controller register space.
-- interrupts: Should contain SPI interrupt.
-- clock-names: Should contain following entries:
- "spi" for SPI clock,
- "source" for SPI source (parent) clock,
- "enable" for SPI module enable clock.
-- clocks: List of clock input name strings sorted in the same order
- as the clock-names property.
-- #address-cells: The number of cells required to define a chip select
- address on the SPI bus. Should be set to 1.
-- #size-cells: Should be set to 0.
-
-Optional properties:
-dma-names: Should contain names of the SPI used DMA channel.
-dmas: Should contain DMA channels and DMA slave ids which the SPI used
- sorted in the same order as the dma-names property.
-
-Example:
-spi0: spi@70a00000{
- compatible = "sprd,sc9860-spi";
- reg = <0 0x70a00000 0 0x1000>;
- interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "spi", "source","enable";
- clocks = <&clk_spi0>, <&ext_26m>, <&clk_ap_apb_gates 5>;
- dma-names = "rx_chn", "tx_chn";
- dmas = <&apdma 11 11>, <&apdma 12 12>;
- #address-cells = <1>;
- #size-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/spi/spi-st-ssc.txt b/Documentation/devicetree/bindings/spi/spi-st-ssc.txt
deleted file mode 100644
index 1bdc4709e474..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-st-ssc.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-STMicroelectronics SSC (SPI) Controller
----------------------------------------
-
-Required properties:
-- compatible : "st,comms-ssc4-spi"
-- reg : Offset and length of the device's register set
-- interrupts : The interrupt specifier
-- clock-names : Must contain "ssc"
-- clocks : Must contain an entry for each name in clock-names
- See ../clk/*
-- pinctrl-names : Uses "default", can use "sleep" if provided
- See ../pinctrl/pinctrl-bindings.txt
-
-Optional properties:
-- cs-gpios : List of GPIO chip selects
- See ../spi/spi-bus.txt
-
-Child nodes represent devices on the SPI bus
- See ../spi/spi-bus.txt
-
-Example:
- spi@9840000 {
- compatible = "st,comms-ssc4-spi";
- reg = <0x9840000 0x110>;
- interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>;
- clock-names = "ssc";
- pinctrl-0 = <&pinctrl_spi0_default>;
- pinctrl-names = "default";
- cs-gpios = <&pio17 5 0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- st95hf@0{
- compatible = "st,st95hf";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml
index 3a58cf0f1ec8..edb5ba71af3a 100644
--- a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml
@@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus sp7021 SPI controller
allOf:
- - $ref: "spi-controller.yaml"
+ - $ref: spi-controller.yaml
maintainers:
- Li-hao Kuo <lhjeff911@gmail.com>
@@ -59,9 +59,9 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- spi@9C002D80 {
+ spi@9c002d80 {
compatible = "sunplus,sp7021-spi";
- reg = <0x9C002D80 0x80>, <0x9C002E00 0x80>;
+ reg = <0x9c002d80 0x80>, <0x9c002e00 0x80>;
reg-names = "master", "slave";
interrupt-parent = <&intc>;
interrupt-names = "dma_w",
diff --git a/Documentation/devicetree/bindings/spi/spi-synquacer.txt b/Documentation/devicetree/bindings/spi/spi-synquacer.txt
deleted file mode 100644
index 291dfa692d0a..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-synquacer.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* Socionext Synquacer HS-SPI bindings
-
-Required Properties:
-- compatible: should be "socionext,synquacer-spi"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: should contain the "spi_rx", "spi_tx" and "spi_fault" interrupts.
-- clocks: core clock iHCLK. Optional rate clock iPCLK (default is iHCLK)
-- clock-names: Shall be "iHCLK" and "iPCLK" respectively
-
-Optional Properties:
-- socionext,use-rtm: boolean, if required to use "retimed clock" for RX
-- socionext,set-aces: boolean, if same active clock edges field to be set.
-
-Example:
-
- spi0: spi@ff110000 {
- compatible = "socionext,synquacer-spi";
- reg = <0xff110000 0x1000>;
- interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_hsspi>;
- clock-names = "iHCLK";
- socionext,use-rtm;
- socionext,set-aces;
- };
diff --git a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
index 03e5dca7e933..4beb3af0416d 100644
--- a/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-xilinx.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/spi/spi-xilinx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx SPI controller Device Tree Bindings
+title: Xilinx SPI controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
index fafde1c06be6..02cf1314367b 100644
--- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml
@@ -4,19 +4,19 @@
$id: http://devicetree.org/schemas/spi/spi-zynqmp-qspi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings
+title: Xilinx Zynq UltraScale+ MPSoC GQSPI controller
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
-
-allOf:
- - $ref: "spi-controller.yaml#"
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
- const: xlnx,zynqmp-qspi-1.0
+ enum:
+ - xlnx,versal-qspi-1.0
+ - xlnx,zynqmp-qspi-1.0
reg:
+ minItems: 1
maxItems: 2
interrupts:
@@ -30,6 +30,12 @@ properties:
clocks:
maxItems: 2
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -39,16 +45,33 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: spi-controller.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: xlnx,zynqmp-qspi-1.0
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
examples:
- |
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
qspi: spi@ff0f0000 {
compatible = "xlnx,zynqmp-qspi-1.0";
- clocks = <&zynqmp_clk QSPI_REF>, <&zynqmp_clk LPD_LSBUS>;
+ clocks = <&zynqmp_clk 53>, <&zynqmp_clk 82>;
clock-names = "ref_clk", "pclk";
interrupts = <0 15 4>;
interrupt-parent = <&gic>;
diff --git a/Documentation/devicetree/bindings/spi/sprd,sc9860-spi.yaml b/Documentation/devicetree/bindings/spi/sprd,sc9860-spi.yaml
new file mode 100644
index 000000000000..d55c01e9a038
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/sprd,sc9860-spi.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/sprd,sc9860-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC9860 SPI Controller
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+properties:
+ compatible:
+ const: sprd,sc9860-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SPI clock
+ - description: SPI source (parent) clock
+ - description: SPI module enable clock
+
+ clock-names:
+ items:
+ - const: spi
+ - const: source
+ - const: enable
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx_chn
+ - const: tx_chn
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ spi@70a00000 {
+ compatible = "sprd,sc9860-spi";
+ reg = <0x70a00000 0x1000>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_spi0>, <&ext_26m>, <&clk_ap_apb_gates 5>;
+ clock-names = "spi", "source", "enable";
+ dmas = <&apdma 11 11>, <&apdma 12 12>;
+ dma-names = "rx_chn", "tx_chn";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml
index a3ab1a1f1eb4..903b06f88b1b 100644
--- a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml
+++ b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml
@@ -1,9 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/spi/sprd,spi-adi.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/spi/sprd,spi-adi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Spreadtrum ADI controller
diff --git a/Documentation/devicetree/bindings/spi/st,ssc-spi.yaml b/Documentation/devicetree/bindings/spi/st,ssc-spi.yaml
new file mode 100644
index 000000000000..6a77cd3f5d6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/st,ssc-spi.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/st,ssc-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SSC SPI Controller
+
+description: |
+ The STMicroelectronics SSC SPI controller can be found on STi platforms
+ and it used to communicate with external devices using the
+ Serial Peripheral Interface.
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: st,comms-ssc4-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ssc
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ spi@9840000 {
+ compatible = "st,comms-ssc4-spi";
+ reg = <0x9840000 0x110>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+ clock-names = "ssc";
+ pinctrl-0 = <&pinctrl_spi0_default>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
index 6ec6f556182f..3f1a27efff80 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/spi/st,stm32-qspi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Quad Serial Peripheral Interface (QSPI) bindings
+title: STMicroelectronics STM32 Quad Serial Peripheral Interface (QSPI)
maintainers:
- Christophe Kerello <christophe.kerello@foss.st.com>
- Patrice Chotard <patrice.chotard@foss.st.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
properties:
compatible:
@@ -46,6 +46,10 @@ properties:
- const: tx
- const: rx
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
index 3d64bed266ac..ca880a226afa 100644
--- a/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/st,stm32-spi.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spi/st,stm32-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 SPI Controller bindings
+title: STMicroelectronics STM32 SPI Controller
description: |
The STM32 SPI controller is used to communicate with external devices using
@@ -17,7 +17,7 @@ maintainers:
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
- if:
properties:
compatible:
@@ -27,12 +27,37 @@ allOf:
then:
properties:
st,spi-midi-ns: false
+ sram: false
+ dmas:
+ maxItems: 2
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,stm32mp25-spi
+
+ then:
+ properties:
+ sram: false
+ dmas:
+ maxItems: 2
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
properties:
compatible:
enum:
- st,stm32f4-spi
+ - st,stm32f7-spi
- st,stm32h7-spi
+ - st,stm32mp25-spi
reg:
maxItems: 1
@@ -48,27 +73,32 @@ properties:
dmas:
description: |
- DMA specifiers for tx and rx dma. DMA fifo mode must be used. See
- the STM32 DMA bindings Documentation/devicetree/bindings/dma/st,stm32-dma.yaml.
+ DMA specifiers for tx and rx channels. DMA fifo mode must be used. See
+ the STM32 DMA bindings Documentation/devicetree/bindings/dma/stm32/st,*dma.yaml
+ minItems: 2
items:
- description: rx DMA channel
- description: tx DMA channel
+ - description: rxm2m MDMA channel
dma-names:
+ minItems: 2
items:
- const: rx
- const: tx
+ - const: rxm2m
-patternProperties:
- "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-f]+$":
- type: object
- # SPI slave nodes must be children of the SPI master node and can
- # contain the following properties.
- properties:
- st,spi-midi-ns:
- description: |
- Only for STM32H7, (Master Inter-Data Idleness) minimum time
- delay in nanoseconds inserted between two consecutive data frames.
+ sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ Phandles to a reserved SRAM region which is used as temporary
+ storage memory between DMA and MDMA engines.
+ The region should be defined as child node of the AHB SRAM node
+ as per the generic bindings in Documentation/devicetree/bindings/sram/sram.yaml
+
+ access-controllers:
+ minItems: 1
+ maxItems: 2
required:
- compatible
@@ -84,18 +114,17 @@ examples:
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
spi@4000b000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "st,stm32h7-spi";
- reg = <0x4000b000 0x400>;
- interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&rcc SPI2_K>;
- resets = <&rcc SPI2_R>;
- dmas = <&dmamux1 0 39 0x400 0x05>,
- <&dmamux1 1 40 0x400 0x05>;
- dma-names = "rx", "tx";
- cs-gpios = <&gpioa 11 0>;
-
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32h7-spi";
+ reg = <0x4000b000 0x400>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rcc SPI2_K>;
+ resets = <&rcc SPI2_R>;
+ dmas = <&dmamux1 0 39 0x400 0x05>,
+ <&dmamux1 1 40 0x400 0x05>;
+ dma-names = "rx", "tx";
+ cs-gpios = <&gpioa 11 0>;
};
...
diff --git a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
new file mode 100644
index 000000000000..272bc308726b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/st,stm32mp25-ospi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 Octal Serial Peripheral Interface (OSPI)
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: st,stm32mp25-ospi
+
+ reg:
+ maxItems: 1
+
+ memory-region:
+ description:
+ Memory region to be used for memory-map read access.
+ In memory-mapped mode, read access are performed from the memory
+ device using the direct mapping.
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: phandle to OSPI block reset
+ - description: phandle to delay block reset
+
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+ st,syscfg-dlyb:
+ description: configure OCTOSPI delay block.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - description: phandle to syscfg
+ - description: register offset within syscfg
+
+ access-controllers:
+ description: phandle to the rifsc device to check access right
+ and in some cases, an additional phandle to the rcc device for
+ secure clock control.
+ items:
+ - description: phandle to bus controller
+ - description: phandle to clock controller
+ minItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - interrupts
+ - st,syscfg-dlyb
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/st,stm32mp25-rcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/reset/st,stm32mp25-rcc.h>
+
+ spi@40430000 {
+ compatible = "st,stm32mp25-ospi";
+ reg = <0x40430000 0x400>;
+ memory-region = <&mm_ospi1>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&hpdma 2 0x62 0x00003121 0x0>,
+ <&hpdma 2 0x42 0x00003112 0x0>;
+ dma-names = "tx", "rx";
+ clocks = <&scmi_clk CK_SCMI_OSPI1>;
+ resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>;
+ access-controllers = <&rifsc 74>;
+ power-domains = <&CLUSTER_PD>;
+ st,syscfg-dlyb = <&syscfg 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <108000000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spi/ti,qspi.yaml b/Documentation/devicetree/bindings/spi/ti,qspi.yaml
new file mode 100644
index 000000000000..626a915b3d77
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ti,qspi.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/ti,qspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI QSPI controller
+
+maintainers:
+ - Kousik Sanagavarapu <five231003@gmail.com>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,am4372-qspi
+ - ti,dra7xxx-qspi
+
+ reg:
+ items:
+ - description: base registers
+ - description: mapped memory
+
+ reg-names:
+ items:
+ - const: qspi_base
+ - const: qspi_mmap
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: fck
+
+ interrupts:
+ maxItems: 1
+
+ num-cs:
+ minimum: 1
+ maximum: 4
+ default: 1
+
+ ti,hwmods:
+ description:
+ Name of the hwmod associated to the QSPI. This is for legacy
+ platforms only.
+ $ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
+
+ syscon-chipselects:
+ description:
+ Handle to system control region containing QSPI chipselect register
+ and offset of that register.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to system control register
+ - description: register offset
+
+ spi-max-frequency:
+ description: Maximum SPI clocking speed of the controller in Hz.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/dra7.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@4b300000 {
+ compatible = "ti,dra7xxx-qspi";
+ reg = <0x4b300000 0x100>,
+ <0x5c000000 0x4000000>;
+ reg-names = "qspi_base", "qspi_mmap";
+ syscon-chipselects = <&scm_conf 0x558>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&l4per2_clkctrl DRA7_L4PER2_QSPI_CLKCTRL 25>;
+ clock-names = "fck";
+ num-cs = <4>;
+ spi-max-frequency = <48000000>;
+ interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt b/Documentation/devicetree/bindings/spi/ti_qspi.txt
deleted file mode 100644
index 47b184bce414..000000000000
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-TI QSPI controller.
-
-Required properties:
-- compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi".
-- reg: Should contain QSPI registers location and length.
-- reg-names: Should contain the resource reg names.
- - qspi_base: Qspi configuration register Address space
- - qspi_mmap: Memory mapped Address space
- - (optional) qspi_ctrlmod: Control module Address space
-- interrupts: should contain the qspi interrupt number.
-- #address-cells, #size-cells : Must be present if the device has sub-nodes
-- ti,hwmods: Name of the hwmod associated to the QSPI
-
-Recommended properties:
-- spi-max-frequency: Definition as per
- Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
-- syscon-chipselects: Handle to system control region contains QSPI
- chipselect register and offset of that register.
-
-NOTE: TI QSPI controller requires different pinmux and IODelay
-parameters for Mode-0 and Mode-3 operations, which needs to be set up by
-the bootloader (U-Boot). Default configuration only supports Mode-0
-operation. Hence, "spi-cpol" and "spi-cpha" DT properties cannot be
-specified in the slave nodes of TI QSPI controller without appropriate
-modification to bootloader.
-
-Example:
-
-For am4372:
-qspi: qspi@47900000 {
- compatible = "ti,am4372-qspi";
- reg = <0x47900000 0x100>, <0x30000000 0x4000000>;
- reg-names = "qspi_base", "qspi_mmap";
- #address-cells = <1>;
- #size-cells = <0>;
- spi-max-frequency = <25000000>;
- ti,hwmods = "qspi";
-};
-
-For dra7xx:
-qspi: qspi@4b300000 {
- compatible = "ti,dra7xxx-qspi";
- reg = <0x4b300000 0x100>,
- <0x5c000000 0x4000000>,
- reg-names = "qspi_base", "qspi_mmap";
- syscon-chipselects = <&scm_conf 0x558>;
- #address-cells = <1>;
- #size-cells = <0>;
- spi-max-frequency = <48000000>;
- ti,hwmods = "qspi";
-};
diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
index 1f1c40a9f320..7ea8fb42ce2c 100644
--- a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
@@ -11,10 +11,10 @@ description:
memory devices.
allOf:
- - $ref: "spi-controller.yaml#"
+ - $ref: spi-controller.yaml#
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
# Everything else is described in the common file
properties:
diff --git a/Documentation/devicetree/bindings/spmi/apple,spmi.yaml b/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
new file mode 100644
index 000000000000..ba524f1eb704
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/apple,spmi.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spmi/apple,spmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SPMI controller
+
+maintainers:
+ - Sasha Finkelstein <fnkl.kernel@gmail.com>
+
+description: A SPMI controller present on most Apple SoCs
+
+allOf:
+ - $ref: spmi.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - apple,t6020-spmi
+ - apple,t8012-spmi
+ - apple,t8015-spmi
+ - const: apple,t8103-spmi
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,t8103-spmi
+ - apple,t6000-spmi
+ - apple,t8112-spmi
+ - const: apple,spmi
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/spmi/spmi.h>
+
+ spmi@920a1300 {
+ compatible = "apple,t6000-spmi", "apple,spmi";
+ reg = <0x920a1300 0x100>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ pmic@f {
+ reg = <0xf SPMI_USID>;
+ /* PMIC-specific properties */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
index f882903769f9..3ccf35de3719 100644
--- a/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
+++ b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
@@ -14,7 +14,7 @@ description: |
It is a MIPI System Power Management (SPMI) controller.
The PMIC part is provided by
- ./Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml.
+ Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml.
allOf:
- $ref: spmi.yaml#
@@ -48,26 +48,23 @@ patternProperties:
PMIC properties, which are specific to the used SPMI PMIC device(s).
When used in combination with HiSilicon 6421v600, the properties
are documented at
- drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml.
+ Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
unevaluatedProperties: false
examples:
- |
- bus {
- #address-cells = <2>;
- #size-cells = <2>;
+ #include <dt-bindings/spmi/spmi.h>
- spmi: spmi@fff24000 {
+ spmi@fff24000 {
compatible = "hisilicon,kirin970-spmi-controller";
+ reg = <0xfff24000 0x1000>;
#address-cells = <2>;
#size-cells = <0>;
- reg = <0x0 0xfff24000 0x0 0x1000>;
hisilicon,spmi-channel = <2>;
pmic@0 {
- reg = <0 0>;
- /* pmic properties */
+ reg = <0 SPMI_USID>;
+ /* pmic properties */
};
- };
};
diff --git a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
index 2445c5e0b0ef..7f0be0ac644a 100644
--- a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
+++ b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/spmi/mtk,spmi-mtk-pmif.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek SPMI Controller Device Tree Bindings
+title: Mediatek SPMI Controller
maintainers:
- Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
@@ -14,13 +14,19 @@ description: |+
for multiple SoCs to control a single SPMI master.
allOf:
- - $ref: "spmi.yaml"
+ - $ref: spmi.yaml
properties:
compatible:
- enum:
- - mediatek,mt6873-spmi
- - mediatek,mt8195-spmi
+ oneOf:
+ - enum:
+ - mediatek,mt6873-spmi
+ - mediatek,mt8195-spmi
+ - items:
+ - enum:
+ - mediatek,mt8186-spmi
+ - mediatek,mt8188-spmi
+ - const: mediatek,mt8195-spmi
reg:
maxItems: 2
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
index fee4f0eb4665..51daf1b847a9 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
@@ -85,6 +85,15 @@ properties:
description: >
which of the PMIC Arb provided channels to use for accesses
+ qcom,bus-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 1
+ description: >
+ SPMI bus instance. only applicable to PMIC arbiter version 7 and beyond.
+ Supported values, 0 = primary bus, 1 = secondary bus
+ deprecated: true
+
required:
- compatible
- reg-names
@@ -113,5 +122,7 @@ examples:
interrupt-controller;
#interrupt-cells = <4>;
+
+ qcom,bus-id = <0>;
};
diff --git a/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml
new file mode 100644
index 000000000000..7c3cc20a80d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spmi/qcom,x1e80100-spmi-pmic-arb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 SPMI Controller (PMIC Arbiter v7)
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+ The X1E80100 SPMI PMIC Arbiter implements HW version 7 and it's an SPMI
+ controller with wrapping arbitration logic to allow for multiple on-chip
+ devices to control up to 2 SPMI separate buses.
+
+ The PMIC Arbiter can also act as an interrupt controller, providing interrupts
+ to slave devices.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: qcom,sar2130p-spmi-pmic-arb
+ - const: qcom,x1e80100-spmi-pmic-arb
+ - const: qcom,x1e80100-spmi-pmic-arb
+
+ reg:
+ items:
+ - description: core registers
+ - description: tx-channel per virtual slave registers
+ - description: rx-channel (called observer) per virtual slave registers
+
+ reg-names:
+ items:
+ - const: core
+ - const: chnls
+ - const: obsrvr
+
+ ranges: true
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ qcom,ee:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 5
+ description: >
+ indicates the active Execution Environment identifier
+
+ qcom,channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 5
+ description: >
+ which of the PMIC Arb provided channels to use for accesses
+
+patternProperties:
+ "^spmi@[a-f0-9]+$":
+ type: object
+ $ref: /schemas/spmi/spmi.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ items:
+ - description: configuration registers
+ - description: interrupt controller registers
+
+ reg-names:
+ items:
+ - const: cnfg
+ - const: intr
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: periph_irq
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 4
+ description: |
+ cell 1: slave ID for the requested interrupt (0-15)
+ cell 2: peripheral ID for requested interrupt (0-255)
+ cell 3: the requested peripheral interrupt (0-7)
+ cell 4: interrupt flags indicating level-sense information,
+ as defined in dt-bindings/interrupt-controller/irq.h
+
+required:
+ - compatible
+ - reg-names
+ - qcom,ee
+ - qcom,channel
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spmi: arbiter@c400000 {
+ compatible = "qcom,x1e80100-spmi-pmic-arb";
+ reg = <0 0x0c400000 0 0x3000>,
+ <0 0x0c500000 0 0x4000000>,
+ <0 0x0c440000 0 0x80000>;
+ reg-names = "core", "chnls", "obsrvr";
+
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ spmi_bus0: spmi@c42d000 {
+ reg = <0 0x0c42d000 0 0x4000>,
+ <0 0x0c4c0000 0 0x10000>;
+ reg-names = "cnfg", "intr";
+
+ interrupt-names = "periph_irq";
+ interrupts-extended = <&pdc 1 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <4>;
+
+ #address-cells = <2>;
+ #size-cells = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
index d64c1b28fb61..e7f7cf72719e 100644
--- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
+++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/sram/allwinner,sun4i-a10-system-control.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 System Control Device Tree Bindings
+title: Allwinner A10 System Control
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -47,7 +47,10 @@ properties:
- const: allwinner,sun8i-v3s-system-control
- const: allwinner,sun8i-h3-system-control
- items:
- - const: allwinner,sun50i-h6-system-control
+ - enum:
+ - allwinner,sun50i-a100-system-control
+ - allwinner,sun50i-h6-system-control
+ - allwinner,sun55i-a523-system-control
- const: allwinner,sun50i-a64-system-control
reg:
@@ -56,18 +59,21 @@ properties:
ranges: true
patternProperties:
- "^sram@[a-z0-9]+":
- type: object
+ "^regulators@[0-9a-f]+$":
+ $ref: /schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
- properties:
- compatible:
- const: mmio-sram
+ "^sram@[a-f0-9]+":
+ $ref: /schemas/sram/sram.yaml#
+ unevaluatedProperties: false
patternProperties:
"^sram-section?@[a-f0-9]+$":
type: object
+ additionalProperties: false
properties:
+ reg: true
+
compatible:
oneOf:
- const: allwinner,sun4i-a10-sram-a3-a4
@@ -130,3 +136,28 @@ examples:
};
};
};
+
+ - |
+ syscon@3000000 {
+ compatible = "allwinner,sun20i-d1-system-control";
+ reg = <0x3000000 0x1000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ regulators@3000150 {
+ compatible = "allwinner,sun20i-d1-system-ldos";
+ reg = <0x3000150 0x4>;
+
+ reg_ldoa: ldoa {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ reg_ldob: ldob {
+ regulator-name = "vcc-dram";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index e9199190198d..6a627c57ae2f 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -18,13 +18,37 @@ properties:
items:
- enum:
- qcom,apq8064-imem
+ - qcom,ipq5424-imem
+ - qcom,msm8226-imem
- qcom,msm8974-imem
+ - qcom,msm8976-imem
- qcom,qcs404-imem
+ - qcom,qcs615-imem
+ - qcom,qcs8300-imem
+ - qcom,qdu1000-imem
+ - qcom,sa8775p-imem
+ - qcom,sar2130p-imem
- qcom,sc7180-imem
- qcom,sc7280-imem
+ - qcom,sc8280xp-imem
- qcom,sdm630-imem
- qcom,sdm845-imem
- qcom,sdx55-imem
+ - qcom,sdx65-imem
+ - qcom,sdx75-imem
+ - qcom,sm6115-imem
+ - qcom,sm6125-imem
+ - qcom,sm6350-imem
+ - qcom,sm6375-imem
+ - qcom,sm7150-imem
+ - qcom,sm8150-imem
+ - qcom,sm8250-imem
+ - qcom,sm8350-imem
+ - qcom,sm8450-imem
+ - qcom,sm8550-imem
+ - qcom,sm8650-imem
+ - qcom,sm8750-imem
+ - qcom,x1e80100-imem
- const: syscon
- const: simple-mfd
diff --git a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
index 071f2d676196..61c784ef7b51 100644
--- a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
@@ -15,7 +15,9 @@ description: |
properties:
compatible:
- const: qcom,msm8974-ocmem
+ enum:
+ - qcom,msm8226-ocmem # v1.1.0
+ - qcom,msm8974-ocmem # v1.4.0
reg:
items:
@@ -28,11 +30,13 @@ properties:
- const: mem
clocks:
+ minItems: 1
items:
- description: Core clock
- description: Interface clock
clock-names:
+ minItems: 1
items:
- const: core
- const: iface
@@ -58,9 +62,30 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8974-ocmem
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ else:
+ properties:
+ clocks:
+ minItems: 1
+ clock-names:
+ minItems: 1
+
patternProperties:
"-sram@[0-9a-f]+$":
type: object
+ additionalProperties: false
description: A region of reserved memory.
properties:
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 993430be355b..7c1337e159f2 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -94,12 +94,19 @@ patternProperties:
- samsung,exynos4210-sysram
- samsung,exynos4210-sysram-ns
- socionext,milbeaut-smp-sram
+ - stericsson,u8500-esram
reg:
description:
IO mem address range, relative to the SRAM range.
maxItems: 1
+ reg-io-width:
+ description:
+ The size (in bytes) of the IO accesses that should be performed on the
+ SRAM.
+ enum: [1, 2, 4, 8]
+
pool:
description:
Indicates that the particular reserved SRAM area is addressable
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
deleted file mode 100644
index 88bc94fe1f6d..000000000000
--- a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* ST SPEAr ADC device driver
-
-Required properties:
-- compatible: Should be "st,spear600-adc"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the ADC interrupt
-- sampling-frequency: Default sampling frequency
-
-Optional properties:
-- vref-external: External voltage reference in milli-volts. If omitted
- the internal voltage reference will be used.
-- average-samples: Number of samples to generate an average value. If
- omitted, single data conversion will be used.
-
-Examples:
-
- adc: adc@d8200000 {
- compatible = "st,spear600-adc";
- reg = <0xd8200000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <6>;
- sampling-frequency = <5000000>;
- vref-external = <2500>; /* 2.5V VRef */
- };
diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst
index 36a17b250ccc..ce767b1eccf2 100644
--- a/Documentation/devicetree/bindings/submitting-patches.rst
+++ b/Documentation/devicetree/bindings/submitting-patches.rst
@@ -15,9 +15,22 @@ I. For patch submitters
"dt-bindings: <binding dir>: ..."
+ Few subsystems, like ASoC, media, regulators and SPI, expect reverse order
+ of the prefixes::
+
+ "<binding dir>: dt-bindings: ..."
+
The 80 characters of the subject are precious. It is recommended to not
- use "Documentation" or "doc" because that is implied. All bindings are
- docs. Repeating "binding" again should also be avoided.
+ use "Documentation", "doc" or "YAML" because that is implied. All
+ bindings are docs and all new bindings are supposed to be in Devicetree
+ schema format. Repeating "binding" again should also be avoided, so for
+ a new device it is often enough for example::
+
+ "dt-bindings: iio: adc: Add ROHM BD79100G"
+
+ Conversion of other formats to DT schema::
+
+ "dt-bindings: iio: adc: adi,ad7476: Convert to DT schema"
2) DT binding files are written in DT schema format using json-schema
vocabulary and YAML file format. The DT binding files must pass validation
@@ -42,26 +55,27 @@ I. For patch submitters
the code implementing the binding.
6) Any compatible strings used in a chip or board DTS file must be
- previously documented in the corresponding DT binding text file
+ previously documented in the corresponding DT binding file
in Documentation/devicetree/bindings. This rule applies even if
the Linux device driver does not yet match on the compatible
string. [ checkpatch will emit warnings if this step is not
followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864
("checkpatch: add DT compatible string documentation checks"). ]
- 7) The wildcard "<chip>" may be used in compatible strings, as in
- the following example:
-
- - compatible: Must contain '"nvidia,<chip>-pcie",
- "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
+ 7) DTS is treated in general as driver-independent hardware description, thus
+ any DTS patches, regardless whether using existing or new bindings, should
+ be placed at the end of patchset to indicate no dependency of drivers on
+ the DTS. DTS will be anyway applied through separate tree or branch, so
+ different order would indicate the series is non-bisectable.
- As in the above example, the known values of "<chip>" should be
- documented if it is used.
+ If a driver subsystem maintainer prefers to apply entire set, instead of
+ their relevant portion of patchset, please split the DTS patches into
+ separate patchset with a reference in changelog or cover letter to the
+ bindings submission on the mailing list.
8) If a documented compatible string is not yet matched by the
driver, the documentation should also include a compatible
- string that is matched by the driver (as in the "nvidia,tegra20-pcie"
- example above).
+ string that is matched by the driver.
9) Bindings are actively used by multiple projects other than the Linux
Kernel, extra care and consideration may need to be taken when making changes
@@ -81,9 +95,13 @@ II. For kernel maintainers
For subsystem bindings (anything affecting more than a single device),
getting a devicetree maintainer to review it is required.
- 3) For a series going though multiple trees, the binding patch should be
+ 3) For a series going through multiple trees, the binding patch should be
kept with the driver using the binding.
+ 4) The DTS files should however never be applied via driver subsystem tree,
+ but always via platform SoC trees on dedicated branches (see also
+ Documentation/process/maintainer-soc.rst).
+
III. Notes
==========
diff --git a/Documentation/devicetree/bindings/thermal/airoha,en7581-thermal.yaml b/Documentation/devicetree/bindings/thermal/airoha,en7581-thermal.yaml
new file mode 100644
index 000000000000..ca0242ef0378
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/airoha,en7581-thermal.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/airoha,en7581-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 Thermal Sensor and Monitor
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+properties:
+ compatible:
+ const: airoha,en7581-thermal
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ airoha,chip-scu:
+ description: phandle to the chip SCU syscon
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ '#thermal-sensor-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - airoha,chip-scu
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ thermal-sensor@1efbd800 {
+ compatible = "airoha,en7581-thermal";
+ reg = <0x1efbd000 0xd5c>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ airoha,chip-scu = <&chip_scu>;
+
+ #thermal-sensor-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
index 6e0b110153b0..3e61689f6dd4 100644
--- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
+++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
@@ -4,22 +4,26 @@
$id: http://devicetree.org/schemas/thermal/allwinner,sun8i-a83t-ths.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner SUN8I Thermal Controller Device Tree Bindings
+title: Allwinner SUN8I Thermal Controller
maintainers:
- Vasily Khoruzhick <anarsoul@gmail.com>
- Yangtao Li <tiny.windzz@gmail.com>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
enum:
- allwinner,sun8i-a83t-ths
- allwinner,sun8i-h3-ths
- allwinner,sun8i-r40-ths
+ - allwinner,sun20i-d1-ths
- allwinner,sun50i-a64-ths
- allwinner,sun50i-a100-ths
- allwinner,sun50i-h5-ths
- allwinner,sun50i-h6-ths
+ - allwinner,sun50i-h616-ths
clocks:
minItems: 1
@@ -49,7 +53,10 @@ properties:
nvmem-cell-names:
const: calibration
- # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details
+ allwinner,sram:
+ maxItems: 1
+ description: phandle to device controlling temperate offset SYS_CFG register
+
"#thermal-sensor-cells":
enum:
- 0
@@ -61,8 +68,10 @@ allOf:
compatible:
contains:
enum:
+ - allwinner,sun20i-d1-ths
- allwinner,sun50i-a100-ths
- allwinner,sun50i-h6-ths
+ - allwinner,sun50i-h616-ths
then:
properties:
@@ -81,10 +90,23 @@ allOf:
minItems: 2
- if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: allwinner,sun50i-h616-ths
+
+ then:
+ properties:
+ allwinner,sram: false
+
+ - if:
properties:
compatible:
contains:
- const: allwinner,sun8i-h3-ths
+ enum:
+ - allwinner,sun8i-h3-ths
+ - allwinner,sun20i-d1-ths
then:
properties:
@@ -97,16 +119,12 @@ allOf:
const: 1
- if:
- properties:
- compatible:
- contains:
- enum:
- - allwinner,sun8i-h3-ths
- - allwinner,sun8i-r40-ths
- - allwinner,sun50i-a64-ths
- - allwinner,sun50i-a100-ths
- - allwinner,sun50i-h5-ths
- - allwinner,sun50i-h6-ths
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - allwinner,sun8i-a83t-ths
then:
required:
@@ -118,45 +136,44 @@ required:
- compatible
- reg
- interrupts
- - '#thermal-sensor-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
thermal-sensor@1f04000 {
- compatible = "allwinner,sun8i-a83t-ths";
- reg = <0x01f04000 0x100>;
- interrupts = <0 31 0>;
- nvmem-cells = <&ths_calibration>;
- nvmem-cell-names = "calibration";
- #thermal-sensor-cells = <1>;
+ compatible = "allwinner,sun8i-a83t-ths";
+ reg = <0x01f04000 0x100>;
+ interrupts = <0 31 0>;
+ nvmem-cells = <&ths_calibration>;
+ nvmem-cell-names = "calibration";
+ #thermal-sensor-cells = <1>;
};
- |
thermal-sensor@1c25000 {
- compatible = "allwinner,sun8i-h3-ths";
- reg = <0x01c25000 0x400>;
- clocks = <&ccu 0>, <&ccu 1>;
- clock-names = "bus", "mod";
- resets = <&ccu 2>;
- interrupts = <0 31 0>;
- nvmem-cells = <&ths_calibration>;
- nvmem-cell-names = "calibration";
- #thermal-sensor-cells = <0>;
+ compatible = "allwinner,sun8i-h3-ths";
+ reg = <0x01c25000 0x400>;
+ clocks = <&ccu 0>, <&ccu 1>;
+ clock-names = "bus", "mod";
+ resets = <&ccu 2>;
+ interrupts = <0 31 0>;
+ nvmem-cells = <&ths_calibration>;
+ nvmem-cell-names = "calibration";
+ #thermal-sensor-cells = <0>;
};
- |
thermal-sensor@5070400 {
- compatible = "allwinner,sun50i-h6-ths";
- reg = <0x05070400 0x100>;
- clocks = <&ccu 0>;
- clock-names = "bus";
- resets = <&ccu 2>;
- interrupts = <0 15 0>;
- nvmem-cells = <&ths_calibration>;
- nvmem-cell-names = "calibration";
- #thermal-sensor-cells = <1>;
+ compatible = "allwinner,sun50i-h6-ths";
+ reg = <0x05070400 0x100>;
+ clocks = <&ccu 0>;
+ clock-names = "bus";
+ resets = <&ccu 2>;
+ interrupts = <0 15 0>;
+ nvmem-cells = <&ths_calibration>;
+ nvmem-cell-names = "calibration";
+ #thermal-sensor-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
deleted file mode 100644
index 12fc4ef04837..000000000000
--- a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Amazon's Annapurna Labs Thermal Sensor
-
-Simple thermal device that allows temperature reading by a single MMIO
-transaction.
-
-Required properties:
-- compatible: "amazon,al-thermal".
-- reg: The physical base address and length of the sensor's registers.
-- #thermal-sensor-cells: Must be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description.
-
-Example:
- thermal: thermal {
- compatible = "amazon,al-thermal";
- reg = <0x0 0x05002860 0x0 0x1>;
- #thermal-sensor-cells = <0x1>;
- };
-
- thermal-zones {
- thermal-z0 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&thermal 0>;
- trips {
- critical {
- temperature = <105000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
-
- };
- };
-
diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.yaml b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.yaml
new file mode 100644
index 000000000000..6b5884d74dd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/amazon,al-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amazon Annapurna Labs Thermal Sensor
+
+maintainers:
+ - Talel Shenhar <talel@amazon.com>
+
+description:
+ Simple thermal device that allows temperature reading by a single MMIO
+ transaction.
+
+properties:
+ compatible:
+ items:
+ - const: amazon,al-thermal
+
+ reg:
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ const: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal: thermal@5002860 {
+ compatible = "amazon,al-thermal";
+ reg = <0x05002860 0x1>;
+ #thermal-sensor-cells = <0x1>;
+ };
+
+ thermal-zones {
+ z0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&thermal 0>;
+ trips {
+ critical {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 999c6b365f1d..70b273271754 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -11,13 +11,17 @@ maintainers:
description: Binding for Amlogic Thermal
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
- items:
- - enum:
- - amlogic,g12a-cpu-thermal
- - amlogic,g12a-ddr-thermal
- - const: amlogic,g12a-thermal
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - const: amlogic,g12a-thermal
+ - const: amlogic,a1-cpu-thermal
reg:
maxItems: 1
@@ -28,9 +32,12 @@ properties:
clocks:
maxItems: 1
+ power-domains:
+ maxItems: 1
+
amlogic,ao-secure:
description: phandle to the ao-secure syscon
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
'#thermal-sensor-cells':
const: 0
@@ -42,17 +49,17 @@ required:
- clocks
- amlogic,ao-secure
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- cpu_temp: temperature-sensor@ff634800 {
- compatible = "amlogic,g12a-cpu-thermal",
- "amlogic,g12a-thermal";
- reg = <0xff634800 0x50>;
- interrupts = <0x0 0x24 0x0>;
- clocks = <&clk 164>;
- #thermal-sensor-cells = <0>;
- amlogic,ao-secure = <&sec_AO>;
- };
+ temperature-sensor@ff634800 {
+ compatible = "amlogic,g12a-cpu-thermal",
+ "amlogic,g12a-thermal";
+ reg = <0xff634800 0x50>;
+ interrupts = <0x0 0x24 0x0>;
+ clocks = <&clk 164>;
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
...
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
deleted file mode 100644
index b0bee7e42038..000000000000
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* Marvell Armada 370/375/380/XP thermal management
-
-Required properties:
-
-- compatible: Should be set to one of the following:
- * marvell,armada370-thermal
- * marvell,armada375-thermal
- * marvell,armada380-thermal
- * marvell,armadaxp-thermal
- * marvell,armada-ap806-thermal
- * marvell,armada-cp110-thermal
-
-Note: these bindings are deprecated for AP806/CP110 and should instead
-follow the rules described in:
-Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt
-Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
-
-- reg: Device's register space.
- Two entries are expected, see the examples below. The first one points
- to the status register (4B). The second one points to the control
- registers (8B).
- Note: The compatibles marvell,armada370-thermal,
- marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
- "control MSB/control 1", with size of 4 (deprecated binding), or point
- to "control LSB/control 0" with size of 8 (current binding). All other
- compatibles must point to "control LSB/control 0" with size of 8.
-
-Examples:
-
- /* Legacy bindings */
- thermal@d0018300 {
- compatible = "marvell,armada370-thermal";
- reg = <0xd0018300 0x4
- 0xd0018304 0x4>;
- };
-
- ap_thermal: thermal@6f8084 {
- compatible = "marvell,armada-ap806-thermal";
- reg = <0x6f808C 0x4>,
- <0x6f8084 0x8>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml
index 89a2c32c0ab2..29a9844e8b48 100644
--- a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml
@@ -19,30 +19,30 @@ description: |+
Refer to the bindings described in
Documentation/devicetree/bindings/mfd/syscon.yaml
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
const: brcm,bcm2711-thermal
- # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details
"#thermal-sensor-cells":
const: 0
required:
- compatible
- - '#thermal-sensor-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- avs-monitor@7d5d2000 {
- compatible = "brcm,bcm2711-avs-monitor",
- "syscon", "simple-mfd";
- reg = <0x7d5d2000 0xf00>;
-
- thermal: thermal {
- compatible = "brcm,bcm2711-thermal";
- #thermal-sensor-cells = <0>;
- };
+ avs-monitor@7d5d2000 {
+ compatible = "brcm,bcm2711-avs-monitor",
+ "syscon", "simple-mfd";
+ reg = <0x7d5d2000 0xf00>;
+
+ thermal: thermal {
+ compatible = "brcm,bcm2711-thermal";
+ #thermal-sensor-cells = <0>;
};
+ };
...
diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml
index 267a0f423504..2f62551a49c1 100644
--- a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml
+++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
items:
- enum:
+ - brcm,avs-tmon-bcm74110
- brcm,avs-tmon-bcm7216
- brcm,avs-tmon-bcm7445
- const: brcm,avs-tmon
@@ -42,15 +43,14 @@ additionalProperties: false
required:
- compatible
- reg
- - "#thermal-sensor-cells"
examples:
- |
- thermal@f04d1500 {
- compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon";
- reg = <0xf04d1500 0x28>;
- interrupts = <0x6>;
- interrupt-names = "tmon";
- interrupt-parent = <&avs_host_l2_intc>;
- #thermal-sensor-cells = <0>;
- };
+ thermal@f04d1500 {
+ compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon";
+ reg = <0xf04d1500 0x28>;
+ interrupts = <0x6>;
+ interrupt-names = "tmon";
+ interrupt-parent = <&avs_host_l2_intc>;
+ #thermal-sensor-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
deleted file mode 100644
index a3e9ec5dc7ac..000000000000
--- a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Binding for Thermal Sensor driver for BCM2835 SoCs.
-
-Required parameters:
--------------------
-
-compatible: should be one of: "brcm,bcm2835-thermal",
- "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal"
-reg: Address range of the thermal registers.
-clocks: Phandle of the clock used by the thermal sensor.
-#thermal-sensor-cells: should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml)
-
-Example:
-
-thermal-zones {
- cpu_thermal: cpu-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
-
- thermal-sensors = <&thermal>;
-
- trips {
- cpu-crit {
- temperature = <80000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
-
- coefficients = <(-538) 407000>;
-
- cooling-maps {
- };
- };
-};
-
-thermal: thermal@7e212000 {
- compatible = "brcm,bcm2835-thermal";
- reg = <0x7e212000 0x8>;
- clocks = <&clocks BCM2835_CLOCK_TSENS>;
- #thermal-sensor-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml
new file mode 100644
index 000000000000..ddf0f20e5285
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/brcm,bcm2835-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2835 thermal sensor
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@i2se.com>
+
+allOf:
+ - $ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-thermal
+ - brcm,bcm2836-thermal
+ - brcm,bcm2837-thermal
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 0
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ thermal@7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+ #thermal-sensor-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
deleted file mode 100644
index 3ab330219d45..000000000000
--- a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
+++ /dev/null
@@ -1,105 +0,0 @@
-* Broadcom Stingray Thermal
-
-This binding describes thermal sensors that is part of Stingray SoCs.
-
-Required properties:
-- compatible : Must be "brcm,sr-thermal"
-- reg : Memory where tmon data will be available.
-- brcm,tmon-mask: A one cell bit mask of valid TMON sources.
- Each bit represents single TMON source.
-- #thermal-sensor-cells : Thermal sensor phandler
-- polling-delay: Max number of milliseconds to wait between polls.
-- thermal-sensors: A list of thermal sensor phandles and specifier.
- specifier value is tmon ID and it should be
- in correspond with brcm,tmon-mask.
-- temperature: trip temperature threshold in millicelsius.
-
-Example:
- tmons {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x8f100000 0x100>;
-
- tmon: tmon@0 {
- compatible = "brcm,sr-thermal";
- reg = <0x0 0x40>;
- brcm,tmon-mask = <0x3f>;
- #thermal-sensor-cells = <1>;
- };
- };
-
- thermal-zones {
- ihost0_thermal: ihost0-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
- thermal-sensors = <&tmon 0>;
- trips {
- cpu-crit {
- temperature = <105000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- };
- ihost1_thermal: ihost1-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
- thermal-sensors = <&tmon 1>;
- trips {
- cpu-crit {
- temperature = <105000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- };
- ihost2_thermal: ihost2-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
- thermal-sensors = <&tmon 2>;
- trips {
- cpu-crit {
- temperature = <105000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- };
- ihost3_thermal: ihost3-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
- thermal-sensors = <&tmon 3>;
- trips {
- cpu-crit {
- temperature = <105000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- };
- crmu_thermal: crmu-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
- thermal-sensors = <&tmon 4>;
- trips {
- cpu-crit {
- temperature = <105000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- };
- nitro_thermal: nitro-thermal {
- polling-delay-passive = <0>;
- polling-delay = <1000>;
- thermal-sensors = <&tmon 5>;
- trips {
- cpu-crit {
- temperature = <105000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.yaml
new file mode 100644
index 000000000000..576a627cd599
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/brcm,sr-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Stingray Thermal Sensors
+
+maintainers:
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+allOf:
+ - $ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ const: brcm,sr-thermal
+
+ reg:
+ maxItems: 1
+
+ brcm,tmon-mask:
+ description:
+ A one-cell bit mask of valid TMON sources. Each bit represents a single
+ TMON source.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ '#thermal-sensor-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - brcm,tmon-mask
+
+additionalProperties: false
+
+examples:
+ - |
+ tmon: thermal-sensor@0 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x0 0x40>;
+ brcm,tmon-mask = <0x3f>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal-zones {
+ ihost0_thermal: ihost0-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tmon 0>;
+ trips {
+ cpu-crit {
+ temperature = <105000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ ihost1_thermal: ihost1-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tmon 1>;
+ trips {
+ cpu-crit {
+ temperature = <105000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ ihost2_thermal: ihost2-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tmon 2>;
+ trips {
+ cpu-crit {
+ temperature = <105000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ ihost3_thermal: ihost3-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tmon 3>;
+ trips {
+ cpu-crit {
+ temperature = <105000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ crmu_thermal: crmu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tmon 4>;
+ trips {
+ cpu-crit {
+ temperature = <105000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ nitro_thermal: nitro-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tmon 5>;
+ trips {
+ cpu-crit {
+ temperature = <105000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/da9062-thermal.txt b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
deleted file mode 100644
index e241bb5a5584..000000000000
--- a/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* Dialog DA9062/61 TJUNC Thermal Module
-
-This module is part of the DA9061/DA9062. For more details about entire
-DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
-
-Junction temperature thermal module uses an interrupt signal to identify
-high THERMAL_TRIP_HOT temperatures for the PMIC device.
-
-Required properties:
-
-- compatible: should be one of the following valid compatible string lines:
- "dlg,da9061-thermal", "dlg,da9062-thermal"
- "dlg,da9062-thermal"
-
-Optional properties:
-
-- polling-delay-passive : Specify the polling period, measured in
- milliseconds, between thermal zone device update checks.
-
-Example: DA9062
-
- pmic0: da9062@58 {
- thermal {
- compatible = "dlg,da9062-thermal";
- polling-delay-passive = <3000>;
- };
- };
-
-Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
-
- pmic0: da9061@58 {
- thermal {
- compatible = "dlg,da9061-thermal", "dlg,da9062-thermal";
- polling-delay-passive = <3000>;
- };
- };
diff --git a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt b/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
deleted file mode 100644
index 2e1c06fad81f..000000000000
--- a/Documentation/devicetree/bindings/thermal/db8500-thermal.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-* ST-Ericsson DB8500 Thermal
-
-** Thermal node properties:
-
-- compatible : "stericsson,db8500-thermal";
-- reg : address range of the thermal sensor registers;
-- interrupts : interrupts generated from PRCMU;
-- interrupt-names : "IRQ_HOTMON_LOW" and "IRQ_HOTMON_HIGH";
-- num-trips : number of total trip points, this is required, set it 0 if none,
- if greater than 0, the following properties must be defined;
-- tripN-temp : temperature of trip point N, should be in ascending order;
-- tripN-type : type of trip point N, should be one of "active" "passive" "hot"
- "critical";
-- tripN-cdev-num : number of the cooling devices which can be bound to trip
- point N, this is required if trip point N is defined, set it 0 if none,
- otherwise the following cooling device names must be defined;
-- tripN-cdev-nameM : name of the No. M cooling device of trip point N;
-
-Usually the num-trips and tripN-*** are separated in board related dts files.
-
-Example:
-thermal@801573c0 {
- compatible = "stericsson,db8500-thermal";
- reg = <0x801573c0 0x40>;
- interrupts = <21 0x4>, <22 0x4>;
- interrupt-names = "IRQ_HOTMON_LOW", "IRQ_HOTMON_HIGH";
-
- num-trips = <3>;
-
- trip0-temp = <75000>;
- trip0-type = "active";
- trip0-cdev-num = <1>;
- trip0-cdev-name0 = "thermal-cpufreq-0";
-
- trip1-temp = <80000>;
- trip1-type = "active";
- trip1-cdev-num = <2>;
- trip1-cdev-name0 = "thermal-cpufreq-0";
- trip1-cdev-name1 = "thermal-fan";
-
- trip2-temp = <85000>;
- trip2-type = "critical";
- trip2-cdev-num = <0>;
-}
diff --git a/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml b/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
new file mode 100644
index 000000000000..e8b2cac41084
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/dlg,da9062-thermal.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/dlg,da9062-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog DA9062/61 TJUNC Thermal Module
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ This module is part of the DA9061/DA9062. For more details about entire
+ DA906{1,2} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
+
+ Junction temperature thermal module uses an interrupt signal to identify
+ high THERMAL_TRIP_HOT temperatures for the PMIC device.
+
+properties:
+ compatible:
+ oneOf:
+ - const: dlg,da9062-thermal
+ - items:
+ - const: dlg,da9061-thermal
+ - const: dlg,da9062-thermal
+
+ polling-delay-passive:
+ description:
+ Specify the polling period, measured in milliseconds, between
+ thermal zone device update checks.
+
+required:
+ - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/thermal/fsl,imx91-tmu.yaml b/Documentation/devicetree/bindings/thermal/fsl,imx91-tmu.yaml
new file mode 100644
index 000000000000..7fd1a86d7287
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/fsl,imx91-tmu.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/fsl,imx91-tmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX91 Thermal
+
+maintainers:
+ - Pengfei Li <pengfei.li_1@nxp.com>
+
+description:
+ i.MX91 features a new temperature sensor. It includes programmable
+ temperature threshold comparators for both normal and privileged
+ accesses and allows a programmable measurement frequency for the
+ Periodic One-Shot Measurement mode. Additionally, it provides
+ status registers for indicating the end of measurement and threshold
+ violation events.
+
+properties:
+ compatible:
+ items:
+ - const: fsl,imx91-tmu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Comparator 1 irq
+ - description: Comparator 2 irq
+ - description: Data ready irq
+
+ interrupt-names:
+ items:
+ - const: thr1
+ - const: thr2
+ - const: ready
+
+ nvmem-cells:
+ items:
+ - description: Phandle to the trim control 1 provided by ocotp
+ - description: Phandle to the trim control 2 provided by ocotp
+
+ nvmem-cell-names:
+ items:
+ - const: trim1
+ - const: trim2
+
+ "#thermal-sensor-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: thermal-sensor.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx93-clock.h>
+
+ thermal-sensor@44482000 {
+ compatible = "fsl,imx91-tmu";
+ reg = <0x44482000 0x1000>;
+ #thermal-sensor-cells = <0>;
+ clocks = <&clk IMX93_CLK_TMC_GATE>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "thr1", "thr2", "ready";
+ nvmem-cells = <&tmu_trim1>, <&tmu_trim2>;
+ nvmem-cell-names = "trim1", "trim2";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml b/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml
index f9e4b3c8d0ee..ceef318668bf 100644
--- a/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/thermal/fsl,scu-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - Thermal bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - Thermal Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
@@ -18,7 +18,9 @@ allOf:
properties:
compatible:
items:
- - const: fsl,imx8qxp-sc-thermal
+ - enum:
+ - fsl,imx8dxl-sc-thermal
+ - fsl,imx8qxp-sc-thermal
- const: fsl,imx-sc-thermal
'#thermal-sensor-cells':
@@ -26,7 +28,6 @@ properties:
required:
- compatible
- - '#thermal-sensor-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml b/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
new file mode 100644
index 000000000000..12e6418dc24d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/generic-adc-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: General Purpose Analog To Digital Converter (ADC) based thermal sensor
+
+maintainers:
+ - Laxman Dewangan <ldewangan@nvidia.com>
+
+description:
+ On some of platforms, thermal sensor like thermistors are connected to
+ one of ADC channel and sensor resistance is read via voltage across the
+ sensor resistor. The voltage read across the sensor is mapped to
+ temperature using voltage-temperature lookup table.
+
+$ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ const: generic-adc-thermal
+
+ '#thermal-sensor-cells':
+ const: 0
+
+ io-channels:
+ maxItems: 1
+
+ io-channel-names:
+ const: sensor-channel
+
+ temperature-lookup-table:
+ description: |
+ Lookup table to map the relation between ADC value and temperature.
+ When ADC is read, the value is looked up on the table to get the
+ equivalent temperature.
+
+ If not specified, driver assumes the ADC channel gives milliCelsius
+ directly.
+ $ref: /schemas/types.yaml#/definitions/int32-matrix
+ items:
+ items:
+ - description: Temperature in milliCelsius
+ - description: ADC read value
+
+required:
+ - compatible
+ - io-channels
+ - io-channel-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/thermal/thermal.h>
+
+ thermal-sensor {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&ads1015 1>;
+ io-channel-names = "sensor-channel";
+ temperature-lookup-table = <
+ (-40000) 2578
+ (-39000) 2577
+ (-38000) 2576
+ (-37000) 2575
+ (-36000) 2574
+ (-35000) 2573
+ (-34000) 2572
+ (-33000) 2571
+ (-32000) 2569
+ (-31000) 2568
+ (-30000) 2567
+ /* skip */
+ 118000 254
+ 119000 247
+ 120000 240
+ 121000 233
+ 122000 226
+ 123000 220
+ 124000 214
+ 125000 208>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/thermal/hisilicon,tsensor.yaml b/Documentation/devicetree/bindings/thermal/hisilicon,tsensor.yaml
new file mode 100644
index 000000000000..11aca2b749d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/hisilicon,tsensor.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/hisilicon,tsensor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Temperature Sensor on HiSilicon SoCs
+
+maintainers:
+ - Abdulrasaq Lawani <abdulrasaqolawani@gmail.com>
+
+allOf:
+ - $ref: thermal-sensor.yaml
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,tsensor
+ - hisilicon,hi3660-tsensor
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: thermal_clk
+
+ interrupts:
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - '#thermal-sensor-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/hi6220-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ temperature-sensor@f7030700 {
+ compatible = "hisilicon,tsensor";
+ reg = <0xf7030700 0x1000>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sys_ctrl HI6220_TSENSOR_CLK>;
+ clock-names = "thermal_clk";
+ #thermal-sensor-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
deleted file mode 100644
index 4b19d80e6558..000000000000
--- a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-* Temperature Sensor on hisilicon SoCs
-
-** Required properties :
-
-- compatible: "hisilicon,tsensor".
-- reg: physical base address of thermal sensor and length of memory mapped
- region.
-- interrupt: The interrupt number to the cpu. Defines the interrupt used
- by /SOCTHERM/tsensor.
-- clock-names: Input clock name, should be 'thermal_clk'.
-- clocks: phandles for clock specified in "clock-names" property.
-- #thermal-sensor-cells: Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description.
-
-Example :
-
-for Hi6220:
- tsensor: tsensor@0,f7030700 {
- compatible = "hisilicon,tsensor";
- reg = <0x0 0xf7030700 0x0 0x1000>;
- interrupts = <0 7 0x4>;
- clocks = <&sys_ctrl HI6220_TSENSOR_CLK>;
- clock-names = "thermal_clk";
- #thermal-sensor-cells = <1>;
- }
-
-for Hi3660:
- tsensor: tsensor@fff30000 {
- compatible = "hisilicon,hi3660-tsensor";
- reg = <0x0 0xfff30000 0x0 0x1000>;
- interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
- #thermal-sensor-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
index 16b57f57d103..949b154856c5 100644
--- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml
@@ -4,18 +4,23 @@
$id: http://devicetree.org/schemas/thermal/imx-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX Thermal Binding
+title: NXP i.MX Thermal
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- - Anson Huang <Anson.Huang@nxp.com>
properties:
compatible:
- enum:
- - fsl,imx6q-tempmon
- - fsl,imx6sx-tempmon
- - fsl,imx7d-tempmon
+ oneOf:
+ - enum:
+ - fsl,imx6q-tempmon
+ - fsl,imx6sx-tempmon
+ - fsl,imx7d-tempmon
+ - items:
+ - enum:
+ - fsl,imx6sll-tempmon
+ - fsl,imx6ul-tempmon
+ - const: fsl,imx6sx-tempmon
interrupts:
description: |
@@ -40,11 +45,11 @@ properties:
- const: temp_grade
fsl,tempmon:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: Phandle to anatop system controller node.
fsl,tempmon-data:
- $ref: '/schemas/types.yaml#/definitions/phandle'
+ $ref: /schemas/types.yaml#/definitions/phandle
description: |
Deprecated property, phandle pointer to fuse controller that contains
TEMPMON calibration data, e.g. OCOTP on imx6q. The details about
@@ -54,6 +59,9 @@ properties:
clocks:
maxItems: 1
+ "#thermal-sensor-cells":
+ const: 0
+
required:
- compatible
- interrupts
@@ -61,6 +69,9 @@ required:
- nvmem-cells
- nvmem-cell-names
+allOf:
+ - $ref: thermal-sensor.yaml#
+
additionalProperties: false
examples:
@@ -69,19 +80,19 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
efuse@21bc000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,imx6sx-ocotp", "syscon";
- reg = <0x021bc000 0x4000>;
- clocks = <&clks IMX6SX_CLK_OCOTP>;
-
- tempmon_calib: calib@38 {
- reg = <0x38 4>;
- };
-
- tempmon_temp_grade: temp-grade@20 {
- reg = <0x20 4>;
- };
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,imx6sx-ocotp", "syscon";
+ reg = <0x021bc000 0x4000>;
+ clocks = <&clks IMX6SX_CLK_OCOTP>;
+
+ tempmon_calib: calib@38 {
+ reg = <0x38 4>;
+ };
+
+ tempmon_temp_grade: temp-grade@20 {
+ reg = <0x20 4>;
+ };
};
anatop@20c8000 {
@@ -92,11 +103,12 @@ examples:
<0 127 IRQ_TYPE_LEVEL_HIGH>;
tempmon {
- compatible = "fsl,imx6sx-tempmon";
- interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
- fsl,tempmon = <&anatop>;
- nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
- nvmem-cell-names = "calib", "temp_grade";
- clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
+ compatible = "fsl,imx6sx-tempmon";
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,tempmon = <&anatop>;
+ nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
+ nvmem-cell-names = "calib", "temp_grade";
+ clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
+ #thermal-sensor-cells = <0>;
};
};
diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
index 89c54e08ee61..df6c7c5d519f 100644
--- a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
@@ -4,10 +4,12 @@
$id: http://devicetree.org/schemas/thermal/imx8mm-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP i.MX8M Mini Thermal Binding
+title: NXP i.MX8M Mini Thermal
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
description: |
i.MX8MM has TMU IP to allow temperature measurement, there are
@@ -16,6 +18,8 @@ description: |
for i.MX8MM which has ONLY 1 sensor, v2 is for i.MX8MP which has
2 sensors.
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
oneOf:
@@ -32,6 +36,13 @@ properties:
clocks:
maxItems: 1
+ nvmem-cells:
+ maxItems: 1
+ description: Phandle to the calibration data provided by ocotp
+
+ nvmem-cell-names:
+ const: calib
+
"#thermal-sensor-cells":
description: |
Number of cells required to uniquely identify the thermal
@@ -44,19 +55,18 @@ required:
- compatible
- reg
- clocks
- - '#thermal-sensor-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/imx8mm-clock.h>
thermal-sensor@30260000 {
- compatible = "fsl,imx8mm-tmu";
- reg = <0x30260000 0x10000>;
- clocks = <&clk IMX8MM_CLK_TMU_ROOT>;
- #thermal-sensor-cells = <0>;
+ compatible = "fsl,imx8mm-tmu";
+ reg = <0x30260000 0x10000>;
+ clocks = <&clk IMX8MM_CLK_TMU_ROOT>;
+ #thermal-sensor-cells = <0>;
};
...
diff --git a/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
new file mode 100644
index 000000000000..79e691b08341
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/loongson,ls2k-thermal.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/loongson,ls2k-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal sensors on Loongson-2 SoCs
+
+maintainers:
+ - zhanghongchen <zhanghongchen@loongson.cn>
+ - Yinbo Zhu <zhuyinbo@loongson.cn>
+
+allOf:
+ - $ref: /schemas/thermal/thermal-sensor.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - loongson,ls2k1000-thermal
+ - loongson,ls2k2000-thermal
+ - items:
+ - enum:
+ - loongson,ls2k0500-thermal
+ - const: loongson,ls2k1000-thermal
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - loongson,ls2k2000-thermal
+
+then:
+ properties:
+ reg:
+ minItems: 2
+ maxItems: 2
+
+else:
+ properties:
+ reg:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ thermal: thermal-sensor@1fe01500 {
+ compatible = "loongson,ls2k1000-thermal";
+ reg = <0x1fe01500 0x30>;
+ interrupt-parent = <&liointc0>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ #thermal-sensor-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/marvell,armada-ap806-thermal.yaml b/Documentation/devicetree/bindings/thermal/marvell,armada-ap806-thermal.yaml
new file mode 100644
index 000000000000..2c370317a40e
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/marvell,armada-ap806-thermal.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/marvell,armada-ap806-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada AP80x/CP110 thermal management
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada-ap806-thermal
+ - marvell,armada-ap807-thermal
+ - marvell,armada-cp110-thermal
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ Overheat interrupt. The interrupt is connected thru a System Error
+ Interrupt (SEI) controller.
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ description: Cell represents the channel ID. There is one sensor per
+ channel. O refers to the thermal IP internal channel.
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal-sensor@80 {
+ compatible = "marvell,armada-ap806-thermal";
+ reg = <0x80 0x10>;
+ interrupts = <18>;
+ #thermal-sensor-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/marvell,armada370-thermal.yaml b/Documentation/devicetree/bindings/thermal/marvell,armada370-thermal.yaml
new file mode 100644
index 000000000000..337792859448
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/marvell,armada370-thermal.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/marvell,armada370-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 3xx/XP thermal management
+
+maintainers:
+ - Miquel Raynal <miquel.raynal@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - marvell,armada370-thermal
+ - marvell,armada375-thermal
+ - marvell,armada380-thermal
+ - marvell,armadaxp-thermal
+
+ reg:
+ items:
+ - description: status register (4B)
+ - description: control register (8B)
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ thermal@d0018300 {
+ compatible = "marvell,armada370-thermal";
+ reg = <0xd0018300 0x4>,
+ <0xd0018304 0x8>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml b/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml
new file mode 100644
index 000000000000..0259cd3ce9c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek,lvts-thermal.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/mediatek,lvts-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SoC Low Voltage Thermal Sensor (LVTS)
+
+maintainers:
+ - Balsam CHIHI <bchihi@baylibre.com>
+
+description: |
+ LVTS is a thermal management architecture composed of three subsystems,
+ a Sensing device - Thermal Sensing Micro Circuit Unit (TSMCU),
+ a Converter - Low Voltage Thermal Sensor converter (LVTS), and
+ a Digital controller (LVTS_CTRL).
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt7988-lvts-ap
+ - mediatek,mt8186-lvts
+ - mediatek,mt8188-lvts-ap
+ - mediatek,mt8188-lvts-mcu
+ - mediatek,mt8192-lvts-ap
+ - mediatek,mt8192-lvts-mcu
+ - mediatek,mt8195-lvts-ap
+ - mediatek,mt8195-lvts-mcu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+ description: LVTS reset for clearing temporary data on AP/MCU.
+
+ nvmem-cells:
+ minItems: 1
+ items:
+ - description: Calibration eFuse data 1 for LVTS
+ - description: Calibration eFuse data 2 for LVTS
+
+ nvmem-cell-names:
+ minItems: 1
+ items:
+ - const: lvts-calib-data-1
+ - const: lvts-calib-data-2
+
+ "#thermal-sensor-cells":
+ const: 1
+
+allOf:
+ - $ref: thermal-sensor.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8188-lvts-ap
+ - mediatek,mt8188-lvts-mcu
+ - mediatek,mt8192-lvts-ap
+ - mediatek,mt8192-lvts-mcu
+ then:
+ properties:
+ nvmem-cells:
+ maxItems: 1
+
+ nvmem-cell-names:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8186-lvts
+ - mediatek,mt8195-lvts-ap
+ - mediatek,mt8195-lvts-mcu
+ then:
+ properties:
+ nvmem-cells:
+ minItems: 2
+
+ nvmem-cell-names:
+ minItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+ - nvmem-cells
+ - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/mt8195-clk.h>
+ #include <dt-bindings/reset/mt8195-resets.h>
+ #include <dt-bindings/thermal/mediatek,lvts-thermal.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ lvts_mcu: thermal-sensor@11278000 {
+ compatible = "mediatek,mt8195-lvts-mcu";
+ reg = <0 0x11278000 0 0x1000>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&infracfg_ao CLK_INFRA_AO_THERM>;
+ resets = <&infracfg_ao MT8195_INFRA_RST4_THERM_CTRL_MCU_SWRST>;
+ nvmem-cells = <&lvts_efuse_data1 &lvts_efuse_data2>;
+ nvmem-cell-names = "lvts-calib-data-1", "lvts-calib-data-2";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
+ thermal_zones: thermal-zones {
+ cpu0-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&lvts_mcu MT8195_MCU_LITTLE_CPU0>;
+
+ trips {
+ cpu0_alert: trip-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu0_crit: trip-crit {
+ temperature = <100000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/mediatek,thermal.yaml b/Documentation/devicetree/bindings/thermal/mediatek,thermal.yaml
new file mode 100644
index 000000000000..7bd0955e6d04
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/mediatek,thermal.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/mediatek,thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek thermal controller for on-SoC temperatures
+
+maintainers:
+ - Sascha Hauer <s.hauer@pengutronix.de>
+
+description:
+ This device does not have its own ADC, instead it directly controls the AUXADC
+ via AHB bus accesses. For this reason it needs phandles to the AUXADC. Also it
+ controls a mux in the apmixedsys register space via AHB bus accesses, so a
+ phandle to the APMIXEDSYS is also needed.
+
+allOf:
+ - $ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2701-thermal
+ - mediatek,mt2712-thermal
+ - mediatek,mt7622-thermal
+ - mediatek,mt7986-thermal
+ - mediatek,mt8173-thermal
+ - mediatek,mt8183-thermal
+ - mediatek,mt8365-thermal
+ - items:
+ - enum:
+ - mediatek,mt8516-thermal
+ - const: mediatek,mt2701-thermal
+ - items:
+ - enum:
+ - mediatek,mt7981-thermal
+ - const: mediatek,mt7986-thermal
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Main clock needed for register access
+ - description: The AUXADC clock
+
+ clock-names:
+ items:
+ - const: therm
+ - const: auxadc
+
+ mediatek,auxadc:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the AUXADC which the thermal controller uses
+
+ mediatek,apmixedsys:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the APMIXEDSYS controller
+
+ resets:
+ description: Reset controller controlling the thermal controller
+
+ nvmem-cells:
+ items:
+ - description:
+ NVMEM cell with EEPROMA phandle to the calibration data provided by an
+ NVMEM device. If unspecified default values shall be used.
+
+ nvmem-cell-names:
+ items:
+ - const: calibration-data
+
+required:
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - mediatek,auxadc
+ - mediatek,apmixedsys
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/reset/mt8173-resets.h>
+
+ thermal@1100b000 {
+ compatible = "mediatek,mt8173-thermal";
+ reg = <0x1100b000 0x1000>;
+ interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "therm", "auxadc";
+ resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
+ mediatek,auxadc = <&auxadc>;
+ mediatek,apmixedsys = <&apmixedsys>;
+ nvmem-cells = <&thermal_calibration_data>;
+ nvmem-cell-names = "calibration-data";
+ #thermal-sensor-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
deleted file mode 100644
index 5c7e7bdd029a..000000000000
--- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Mediatek Thermal
-
-This describes the device tree binding for the Mediatek thermal controller
-which measures the on-SoC temperatures. This device does not have its own ADC,
-instead it directly controls the AUXADC via AHB bus accesses. For this reason
-this device needs phandles to the AUXADC. Also it controls a mux in the
-apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS
-is also needed.
-
-Required properties:
-- compatible:
- - "mediatek,mt8173-thermal" : For MT8173 family of SoCs
- - "mediatek,mt2701-thermal" : For MT2701 family of SoCs
- - "mediatek,mt2712-thermal" : For MT2712 family of SoCs
- - "mediatek,mt7622-thermal" : For MT7622 SoC
- - "mediatek,mt8183-thermal" : For MT8183 family of SoCs
- - "mediatek,mt8516-thermal", "mediatek,mt2701-thermal : For MT8516 family of SoCs
-- reg: Address range of the thermal controller
-- interrupts: IRQ for the thermal controller
-- clocks, clock-names: Clocks needed for the thermal controller. required
- clocks are:
- "therm": Main clock needed for register access
- "auxadc": The AUXADC clock
-- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
-- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
-- #thermal-sensor-cells : Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description.
-
-Optional properties:
-- resets: Reference to the reset controller controlling the thermal controller.
-- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
- unspecified default values shall be used.
-- nvmem-cell-names: Should be "calibration-data"
-
-Example:
-
- thermal: thermal@1100b000 {
- #thermal-sensor-cells = <1>;
- compatible = "mediatek,mt8173-thermal";
- reg = <0 0x1100b000 0 0x1000>;
- interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
- clock-names = "therm", "auxadc";
- resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
- reset-names = "therm";
- mediatek,auxadc = <&auxadc>;
- mediatek,apmixedsys = <&apmixedsys>;
- nvmem-cells = <&thermal_calibration_data>;
- nvmem-cell-names = "calibration-data";
- };
diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
deleted file mode 100644
index aea4a2a178b9..000000000000
--- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
+++ /dev/null
@@ -1,238 +0,0 @@
-Tegra124 SOCTHERM thermal management system
-
-The SOCTHERM IP block contains thermal sensors, support for polled
-or interrupt-based thermal monitoring, CPU and GPU throttling based
-on temperature trip points, and handling external overcurrent
-notifications. It is also used to manage emergency shutdown in an
-overheating situation.
-
-Required properties :
-- compatible : For Tegra124, must contain "nvidia,tegra124-soctherm".
- For Tegra132, must contain "nvidia,tegra132-soctherm".
- For Tegra210, must contain "nvidia,tegra210-soctherm".
-- reg : Should contain at least 2 entries for each entry in reg-names:
- - SOCTHERM register set
- - Tegra CAR register set: Required for Tegra124 and Tegra210.
- - CCROC register set: Required for Tegra132.
-- reg-names : Should contain at least 2 entries:
- - soctherm-reg
- - car-reg
- - ccroc-reg
-- interrupts : Defines the interrupt used by SOCTHERM
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- - tsensor
- - soctherm
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - soctherm
-- #thermal-sensor-cells : Should be 1. For a description of this property, see
- Documentation/devicetree/bindings/thermal/thermal-sensor.yaml.
- See <dt-bindings/thermal/tegra124-soctherm.h> for a list of valid values
- when referring to thermal sensors.
-- throttle-cfgs: A sub-node which is a container of configuration for each
- hardware throttle events. These events can be set as cooling devices.
- * throttle events: Sub-nodes must be named as "light" or "heavy".
- Properties:
- - nvidia,priority: Each throttles has its own throttle settings, so the
- SW need to set priorities for various throttle, the HW arbiter can select
- the final throttle settings.
- Bigger value indicates higher priority, In general, higher priority
- translates to lower target frequency. SW needs to ensure that critical
- thermal alarms are given higher priority, and ensure that there is
- no race if priority of two vectors is set to the same value.
- The range of this value is 1~100.
- - nvidia,cpu-throt-percent: This property is for Tegra124 and Tegra210.
- It is the throttling depth of pulse skippers, it's the percentage
- throttling.
- - nvidia,cpu-throt-level: This property is only for Tegra132, it is the
- level of pulse skippers, which used to throttle clock frequencies. It
- indicates cpu clock throttling depth, and the depth can be programmed.
- Must set as following values:
- TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED
- TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE
- - nvidia,gpu-throt-level: This property is for Tegra124 and Tegra210.
- It is the level of pulse skippers, which used to throttle clock
- frequencies. It indicates gpu clock throttling depth and can be
- programmed to any of the following values which represent a throttling
- percentage:
- TEGRA_SOCTHERM_THROT_LEVEL_NONE (0%)
- TEGRA_SOCTHERM_THROT_LEVEL_LOW (50%),
- TEGRA_SOCTHERM_THROT_LEVEL_MED (75%),
- TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%).
- - #cooling-cells: Should be 1. This cooling device only support on/off state.
- For a description of this property see:
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
-
- Optional properties: The following properties are T210 specific and
- valid only for OCx throttle events.
- - nvidia,count-threshold: Specifies the number of OC events that are
- required for triggering an interrupt. Interrupts are not triggered if
- the property is missing. A value of 0 will interrupt on every OC alarm.
- - nvidia,polarity-active-low: Configures the polarity of the OC alaram
- signal. If present, this means assert low, otherwise assert high.
- - nvidia,alarm-filter: Number of clocks to filter event. When the filter
- expires (which means the OC event has not occurred for a long time),
- the counter is cleared and filter is rearmed. Default value is 0.
- - nvidia,throttle-period-us: Specifies the number of uSec for which
- throttling is engaged after the OC event is deasserted. Default value
- is 0.
-
-Optional properties:
-- nvidia,thermtrips : When present, this property specifies the temperature at
- which the soctherm hardware will assert the thermal trigger signal to the
- Power Management IC, which can be configured to reset or shutdown the device.
- It is an array of pairs where each pair represents a tsensor id followed by a
- temperature in milli Celcius. In the absence of this property the critical
- trip point will be used for thermtrip temperature.
-
-Note:
-- the "critical" type trip points will be used to set the temperature at which
-the SOC_THERM hardware will assert a thermal trigger if the "nvidia,thermtrips"
-property is missing. When the thermtrips property is present, the breach of a
-critical trip point is reported back to the thermal framework to implement
-software shutdown.
-
-- the "hot" type trip points will be set to SOC_THERM hardware as the throttle
-temperature. Once the temperature of this thermal zone is higher
-than it, it will trigger the HW throttle event.
-
-Example :
-
- soctherm@700e2000 {
- compatible = "nvidia,tegra124-soctherm";
- reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
- 0x0 0x60006000 0x0 0x400 /* CAR reg_base */
- reg-names = "soctherm-reg", "car-reg";
- interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
- <&tegra_car TEGRA124_CLK_SOC_THERM>;
- clock-names = "tsensor", "soctherm";
- resets = <&tegra_car 78>;
- reset-names = "soctherm";
-
- #thermal-sensor-cells = <1>;
-
- nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500
- TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
-
- throttle-cfgs {
- /*
- * When the "heavy" cooling device triggered,
- * the HW will skip cpu clock's pulse in 85% depth,
- * skip gpu clock's pulse in 85% level
- */
- throttle_heavy: heavy {
- nvidia,priority = <100>;
- nvidia,cpu-throt-percent = <85>;
- nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * When the "light" cooling device triggered,
- * the HW will skip cpu clock's pulse in 50% depth,
- * skip gpu clock's pulse in 50% level
- */
- throttle_light: light {
- nvidia,priority = <80>;
- nvidia,cpu-throt-percent = <50>;
- nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * If these two devices are triggered in same time, the HW throttle
- * arbiter will select the highest priority as the final throttle
- * settings to skip cpu pulse.
- */
-
- throttle_oc1: oc1 {
- nvidia,priority = <50>;
- nvidia,polarity-active-low;
- nvidia,count-threshold = <100>;
- nvidia,alarm-filter = <5100000>;
- nvidia,throttle-period-us = <0>;
- nvidia,cpu-throt-percent = <75>;
- nvidia,gpu-throt-level =
- <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
- };
- };
- };
-
-Example: referring to Tegra132's "reg", "reg-names" and "throttle-cfgs" :
-
- soctherm@700e2000 {
- compatible = "nvidia,tegra132-soctherm";
- reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
- 0x0 0x70040000 0x0 0x200>; /* CCROC reg_base */;
- reg-names = "soctherm-reg", "ccroc-reg";
-
- throttle-cfgs {
- /*
- * When the "heavy" cooling device triggered,
- * the HW will skip cpu clock's pulse in HIGH level
- */
- throttle_heavy: heavy {
- nvidia,priority = <100>;
- nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * When the "light" cooling device triggered,
- * the HW will skip cpu clock's pulse in MED level
- */
- throttle_light: light {
- nvidia,priority = <80>;
- nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
-
- #cooling-cells = <1>;
- };
-
- /*
- * If these two devices are triggered in same time, the HW throttle
- * arbiter will select the highest priority as the final throttle
- * settings to skip cpu pulse.
- */
-
- };
- };
-
-Example: referring to thermal sensors :
-
- thermal-zones {
- cpu {
- polling-delay-passive = <1000>;
- polling-delay = <1000>;
-
- thermal-sensors =
- <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>;
-
- trips {
- cpu_shutdown_trip: shutdown-trip {
- temperature = <102500>;
- hysteresis = <1000>;
- type = "critical";
- };
-
- cpu_throttle_trip: throttle-trip {
- temperature = <100000>;
- hysteresis = <1000>;
- type = "hot";
- };
- };
-
- cooling-maps {
- map0 {
- trip = <&cpu_throttle_trip>;
- cooling-device = <&throttle_heavy 1 1>;
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml
new file mode 100644
index 000000000000..25efedced584
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.yaml
@@ -0,0 +1,388 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/nvidia,tegra124-soctherm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra124 SOCTHERM Thermal Management System
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The SOCTHERM IP block contains thermal sensors, support for
+ polled or interrupt-based thermal monitoring, CPU and GPU throttling based
+ on temperature trip points, and handling external overcurrent notifications.
+ It is also used to manage emergency shutdown in an overheating situation.
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra114-soctherm
+ - nvidia,tegra124-soctherm
+ - nvidia,tegra132-soctherm
+ - nvidia,tegra210-soctherm
+ - nvidia,tegra210b01-soctherm
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ maxItems: 2
+
+ interrupts:
+ items:
+ - description: module interrupt
+ - description: EDP interrupt
+
+ interrupt-names:
+ items:
+ - const: thermal
+ - const: edp
+
+ clocks:
+ items:
+ - description: thermal sensor clock
+ - description: module clock
+
+ clock-names:
+ items:
+ - const: tsensor
+ - const: soctherm
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: soctherm
+
+ "#thermal-sensor-cells":
+ const: 1
+
+ throttle-cfgs:
+ $ref: thermal-cooling-devices.yaml
+ description: A sub-node which is a container of configuration for each
+ hardware throttle events. These events can be set as cooling devices.
+ Throttle event sub-nodes must be named as "light" or "heavy".
+ unevaluatedProperties: false
+ patternProperties:
+ "^(light|heavy|oc1)$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ "#cooling-cells":
+ const: 2
+
+ nvidia,priority:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 100
+ description: Each throttles has its own throttle settings, so the
+ SW need to set priorities for various throttle, the HW arbiter
+ can select the final throttle settings. Bigger value indicates
+ higher priority, In general, higher priority translates to lower
+ target frequency. SW needs to ensure that critical thermal
+ alarms are given higher priority, and ensure that there is no
+ race if priority of two vectors is set to the same value.
+
+ nvidia,cpu-throt-percent:
+ description: This property is for Tegra124 and Tegra210. It is the
+ throttling depth of pulse skippers, it's the percentage
+ throttling.
+ minimum: 0
+ maximum: 100
+
+ nvidia,cpu-throt-level:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This property is only for Tegra132, it is the level
+ of pulse skippers, which used to throttle clock frequencies. It
+ indicates cpu clock throttling depth, and the depth can be
+ programmed.
+ enum:
+ # none (TEGRA_SOCTHERM_THROT_LEVEL_NONE)
+ - 0
+ # low (TEGRA_SOCTHERM_THROT_LEVEL_LOW)
+ - 1
+ # medium (TEGRA_SOCTHERM_THROT_LEVEL_MED)
+ - 2
+ # high (TEGRA_SOCTHERM_THROT_LEVEL_HIGH)
+ - 3
+
+ nvidia,gpu-throt-level:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: This property is for Tegra124 and Tegra210. It is the
+ level of pulse skippers, which used to throttle clock
+ frequencies. It indicates gpu clock throttling depth and can be
+ programmed to any of the following values which represent a
+ throttling percentage.
+ enum:
+ # none (0%, TEGRA_SOCTHERM_THROT_LEVEL_NONE)
+ - 0
+ # low (50%, TEGRA_SOCTHERM_THROT_LEVEL_LOW)
+ - 1
+ # medium (75%, TEGRA_SOCTHERM_THROT_LEVEL_MED)
+ - 2
+ # high (85%, TEGRA_SOCTHERM_THROT_LEVEL_HIGH)
+ - 3
+
+ # optional
+ # Tegra210 specific and valid only for OCx throttle events
+ nvidia,count-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Specifies the number of OC events that are required
+ for triggering an interrupt. Interrupts are not triggered if the
+ property is missing. A value of 0 will interrupt on every OC
+ alarm.
+
+ nvidia,polarity-active-low:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: Configures the polarity of the OC alaram signal. If
+ present, this means assert low, otherwise assert high.
+
+ nvidia,alarm-filter:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Number of clocks to filter event. When the filter
+ expires (which means the OC event has not occurred for a long
+ time), the counter is cleared and filter is rearmed.
+ default: 0
+
+ nvidia,throttle-period-us:
+ description: Specifies the number of microseconds for which
+ throttling is engaged after the OC event is deasserted.
+ default: 0
+
+ # optional
+ nvidia,thermtrips:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ When present, this property specifies the temperature at which the
+ SOCTHERM hardware will assert the thermal trigger signal to the Power
+ Management IC, which can be configured to reset or shutdown the device.
+ It is an array of pairs where each pair represents a tsensor ID followed
+ by a temperature in milli Celcius. In the absence of this property the
+ critical trip point will be used for thermtrip temperature.
+
+ Note:
+ - the "critical" type trip points will be used to set the temperature at
+ which the SOCTHERM hardware will assert a thermal trigger if the
+ "nvidia,thermtrips" property is missing. When the thermtrips property
+ is present, the breach of a critical trip point is reported back to
+ the thermal framework to implement software shutdown.
+
+ - the "hot" type trip points will be set to SOCTHERM hardware as the
+ throttle temperature. Once the temperature of this thermal zone is
+ higher than it, it will trigger the HW throttle event.
+ items:
+ items:
+ - description: sensor ID
+ oneOf:
+ - description: CPU sensor
+ const: 0
+ - description: MEM sensor
+ const: 1
+ - description: GPU sensor
+ const: 2
+ - description: PLLX sensor
+ const: 3
+ - description: temperature threshold (in millidegree Celsius)
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: thermal-sensor.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra114-soctherm
+ - nvidia,tegra124-soctherm
+ - nvidia,tegra210-soctherm
+ - nvidia,tegra210b01-soctherm
+ then:
+ properties:
+ reg:
+ items:
+ - description: SOCTHERM register set
+ - description: clock and reset controller registers
+
+ reg-names:
+ items:
+ - const: soctherm-reg
+ - const: car-reg
+
+ else:
+ properties:
+ reg:
+ items:
+ - description: SOCTHERM register set
+ - description: CCROC registers
+
+ reg-names:
+ items:
+ - const: soctherm-reg
+ - const: ccroc-reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/thermal/tegra124-soctherm.h>
+
+ soctherm@700e2000 {
+ compatible = "nvidia,tegra124-soctherm";
+ reg = <0x700e2000 0x600>, /* SOC_THERM reg_base */
+ <0x60006000 0x400>; /* CAR reg_base */
+ reg-names = "soctherm-reg", "car-reg";
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "thermal", "edp";
+ clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+ <&tegra_car TEGRA124_CLK_SOC_THERM>;
+ clock-names = "tsensor", "soctherm";
+ resets = <&tegra_car 78>;
+ reset-names = "soctherm";
+
+ #thermal-sensor-cells = <1>;
+
+ nvidia,thermtrips = <TEGRA124_SOCTHERM_SENSOR_CPU 102500>,
+ <TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
+
+ throttle-cfgs {
+ /*
+ * When the "heavy" cooling device triggered,
+ * the HW will skip cpu clock's pulse in 85% depth,
+ * skip gpu clock's pulse in 85% level
+ */
+ heavy {
+ nvidia,priority = <100>;
+ nvidia,cpu-throt-percent = <85>;
+ nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * When the "light" cooling device triggered,
+ * the HW will skip cpu clock's pulse in 50% depth,
+ * skip gpu clock's pulse in 50% level
+ */
+ light {
+ nvidia,priority = <80>;
+ nvidia,cpu-throt-percent = <50>;
+ nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_LOW>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * If these two devices are triggered in same time, the HW throttle
+ * arbiter will select the highest priority as the final throttle
+ * settings to skip cpu pulse.
+ */
+
+ oc1 {
+ nvidia,priority = <50>;
+ nvidia,polarity-active-low;
+ nvidia,count-threshold = <100>;
+ nvidia,alarm-filter = <5100000>;
+ nvidia,throttle-period-us = <0>;
+ nvidia,cpu-throt-percent = <75>;
+ nvidia,gpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
+ };
+ };
+ };
+
+ # referring to Tegra132's "reg", "reg-names" and "throttle-cfgs"
+ - |
+ thermal-sensor@700e2000 {
+ compatible = "nvidia,tegra132-soctherm";
+ reg = <0x700e2000 0x600>, /* SOC_THERM reg_base */
+ <0x70040000 0x200>; /* CCROC reg_base */
+ reg-names = "soctherm-reg", "ccroc-reg";
+ interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "thermal", "edp";
+ clocks = <&tegra_car TEGRA124_CLK_TSENSOR>,
+ <&tegra_car TEGRA124_CLK_SOC_THERM>;
+ clock-names = "tsensor", "soctherm";
+ resets = <&tegra_car 78>;
+ reset-names = "soctherm";
+ #thermal-sensor-cells = <1>;
+
+ throttle-cfgs {
+ /*
+ * When the "heavy" cooling device triggered,
+ * the HW will skip cpu clock's pulse in HIGH level
+ */
+ heavy {
+ nvidia,priority = <100>;
+ nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * When the "light" cooling device triggered,
+ * the HW will skip cpu clock's pulse in MED level
+ */
+ light {
+ nvidia,priority = <80>;
+ nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>;
+
+ #cooling-cells = <2>;
+ };
+
+ /*
+ * If these two devices are triggered in same time, the HW throttle
+ * arbiter will select the highest priority as the final throttle
+ * settings to skip cpu pulse.
+ */
+ };
+ };
+
+ # referring to thermal sensors
+ - |
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&soctherm TEGRA124_SOCTHERM_SENSOR_CPU>;
+
+ trips {
+ cpu_shutdown_trip: shutdown-trip {
+ temperature = <102500>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+
+ cpu_throttle_trip: throttle-trip {
+ temperature = <100000>;
+ hysteresis = <1000>;
+ type = "hot";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_throttle_trip>;
+ cooling-device = <&throttle_heavy 1 1>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml
index c91fd07e4061..978b9e6ab8a3 100644
--- a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml
@@ -20,11 +20,7 @@ description: |
node. See ../firmware/nvidia,tegra186-bpmp.yaml for details of the
BPMP binding.
- This node represents a thermal sensor. See
-
- Documentation/devicetree/bindings/thermal/thermal-sensor.yaml
-
- for details of the core thermal binding.
+$ref: thermal-sensor.yaml#
properties:
compatible:
@@ -33,10 +29,6 @@ properties:
- nvidia,tegra194-bpmp-thermal
'#thermal-sensor-cells':
- $ref: /schemas/types.yaml#/definitions/uint32
- description: Number of cells needed in the phandle specifier to
- identify a given sensor. Must be 1 and the single cell specifies
- the sensor index.
const: 1
-additionalProperties: false
+unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml
index a35da257b070..63a29a1f7fe6 100644
--- a/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml
+++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra30-tsensor.yaml
@@ -27,6 +27,8 @@ description: |
TSENSOR has two channels which monitor two different spots of the SoC.
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
const: nvidia,tegra30-tsensor
@@ -46,19 +48,14 @@ properties:
"#thermal-sensor-cells":
const: 1
- assigned-clock-parents: true
- assigned-clock-rates: true
- assigned-clocks: true
-
required:
- compatible
- reg
- clocks
- resets
- interrupts
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml b/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml
index 5f08b6e59b8a..30b22151aa82 100644
--- a/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom,spmi-temp-alarm.yaml
@@ -42,7 +42,6 @@ required:
- compatible
- reg
- interrupts
- - '#thermal-sensor-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
index e1587ddf7de3..1175bb358382 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
@@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Limits Management Hardware(LMh)
maintainers:
- - Thara Gopinath <thara.gopinath@linaro.org>
+ - Thara Gopinath <thara.gopinath@gmail.com>
description:
Limits Management Hardware(LMh) is a hardware infrastructure on some
@@ -17,10 +17,14 @@ description:
properties:
compatible:
- enum:
- - qcom,sc8180x-lmh
- - qcom,sdm845-lmh
- - qcom,sm8150-lmh
+ oneOf:
+ - enum:
+ - qcom,sc8180x-lmh
+ - qcom,sdm845-lmh
+ - qcom,sm8150-lmh
+ - items:
+ - const: qcom,qcm2290-lmh
+ - const: qcom,sm8150-lmh
reg:
items:
@@ -37,7 +41,7 @@ properties:
cpus:
description:
phandle of the first cpu in the LMh cluster
- $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
qcom,lmh-temp-arm-millicelsius:
description:
diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml
index 8273ac55b63f..bfad8130a042 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm-hc.yaml
@@ -8,6 +8,8 @@ title: Qualcomm's SPMI PMIC ADC HC Thermal Monitoring
maintainers:
- Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
const: qcom,spmi-adc-tm-hc
@@ -20,9 +22,6 @@ properties:
"#thermal-sensor-cells":
const: 1
- description:
- Number of cells required to uniquely identify the thermal sensors. Since
- we have multiple sensors this is set to 1
"#address-cells":
const: 1
@@ -106,31 +105,32 @@ required:
- interrupts
- "#address-cells"
- "#size-cells"
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/iio/qcom,spmi-vadc.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spmi_bus {
+
+ pmic {
#address-cells = <1>;
#size-cells = <0>;
+
pm8998_adc: adc@3100 {
- reg = <0x3100>;
compatible = "qcom,spmi-adc-rev2";
+ reg = <0x3100>;
#address-cells = <1>;
#size-cells = <0>;
#io-channel-cells = <1>;
- /* Other propreties are omitted */
- adc-chan@4c {
+ /* Other properties are omitted */
+ channel@4c {
reg = <ADC5_XO_THERM_100K_PU>;
};
};
- pm8998_adc_tm: adc-tm@3400 {
+ adc-tm@3400 {
compatible = "qcom,spmi-adc-tm-hc";
reg = <0x3400>;
interrupts = <0x2 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
index feb390d50696..4470a5942fb2 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
@@ -8,11 +8,14 @@ title: Qualcomm's SPMI PMIC ADC Thermal Monitoring
maintainers:
- Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
enum:
- qcom,spmi-adc-tm5
- qcom,spmi-adc-tm5-gen2
+ - qcom,adc-tm7 # Incomplete / subject to change
reg:
maxItems: 1
@@ -22,9 +25,6 @@ properties:
"#thermal-sensor-cells":
const: 1
- description:
- Number of cells required to uniquely identify the thermal sensors. Since
- we have multiple sensors this is set to 1
"#address-cells":
const: 1
@@ -158,33 +158,35 @@ required:
- interrupts
- "#address-cells"
- "#size-cells"
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/iio/qcom,spmi-vadc.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spmi_bus {
+
+ pmic {
#address-cells = <1>;
#size-cells = <0>;
+
pm8150b_adc: adc@3100 {
- reg = <0x3100>;
compatible = "qcom,spmi-adc5";
+ reg = <0x3100>;
#address-cells = <1>;
#size-cells = <0>;
#io-channel-cells = <1>;
/* Other properties are omitted */
- conn-therm@4f {
+ channel@4f {
reg = <ADC5_AMUX_THM3_100K_PU>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "conn_therm";
};
};
- pm8150b_adc_tm: adc-tm@3500 {
+ adc-tm@3500 {
compatible = "qcom,spmi-adc-tm5";
reg = <0x3500>;
interrupts = <0x2 0x35 0x0 IRQ_TYPE_EDGE_RISING>;
@@ -205,31 +207,35 @@ examples:
#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
#include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h>
#include <dt-bindings/interrupt-controller/irq.h>
- spmi_bus {
+
+ pmic {
#address-cells = <1>;
#size-cells = <0>;
+
pmk8350_vadc: adc@3100 {
- reg = <0x3100>;
compatible = "qcom,spmi-adc7";
+ reg = <0x3100>;
#address-cells = <1>;
#size-cells = <0>;
#io-channel-cells = <1>;
/* Other properties are omitted */
- xo-therm@44 {
+ channel@44 {
reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "xo_therm";
};
- conn-therm@47 {
- reg = <PM8350_ADC7_AMUX_THM4_100K_PU>;
+ channel@147 {
+ reg = <PM8350_ADC7_AMUX_THM4_100K_PU(1)>;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
+ label = "conn_therm";
};
};
- pmk8350_adc_tm: adc-tm@3400 {
+ adc-tm@3400 {
compatible = "qcom,spmi-adc-tm5-gen2";
reg = <0x3400>;
interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
@@ -247,7 +253,7 @@ examples:
conn-therm@1 {
reg = <1>;
- io-channels = <&pmk8350_vadc PM8350_ADC7_AMUX_THM4_100K_PU>;
+ io-channels = <&pmk8350_vadc PM8350_ADC7_AMUX_THM4_100K_PU(1)>;
qcom,avg-samples = <2>;
qcom,ratiometric;
qcom,hw-settle-time-us = <200>;
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 038d81338fcf..3c5256b0cd9f 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -29,14 +29,24 @@ properties:
items:
- enum:
- qcom,mdm9607-tsens
+ - qcom,msm8226-tsens
+ - qcom,msm8909-tsens
- qcom,msm8916-tsens
- qcom,msm8939-tsens
- qcom,msm8974-tsens
- const: qcom,tsens-v0_1
+ - description:
+ v1 of TSENS without RPM which requires to be explicitly reset
+ and enabled in the driver.
+ enum:
+ - qcom,ipq5018-tsens
+
- description: v1 of TSENS
items:
- enum:
+ - qcom,msm8937-tsens
+ - qcom,msm8956-tsens
- qcom,msm8976-tsens
- qcom,qcs404-tsens
- const: qcom,tsens-v1
@@ -44,21 +54,49 @@ properties:
- description: v2 of TSENS
items:
- enum:
+ - qcom,glymur-tsens
+ - qcom,kaanapali-tsens
+ - qcom,milos-tsens
- qcom,msm8953-tsens
- qcom,msm8996-tsens
- qcom,msm8998-tsens
+ - qcom,qcm2290-tsens
+ - qcom,qcs8300-tsens
+ - qcom,qcs615-tsens
+ - qcom,sa8255p-tsens
+ - qcom,sa8775p-tsens
+ - qcom,sar2130p-tsens
- qcom,sc7180-tsens
- qcom,sc7280-tsens
- qcom,sc8180x-tsens
- qcom,sc8280xp-tsens
- qcom,sdm630-tsens
- qcom,sdm845-tsens
+ - qcom,sm6115-tsens
- qcom,sm6350-tsens
+ - qcom,sm6375-tsens
- qcom,sm8150-tsens
- qcom,sm8250-tsens
- qcom,sm8350-tsens
+ - qcom,sm8450-tsens
+ - qcom,sm8550-tsens
+ - qcom,sm8650-tsens
+ - qcom,x1e80100-tsens
- const: qcom,tsens-v2
+ - description: v2 of TSENS with combined interrupt
+ enum:
+ - qcom,ipq5332-tsens
+ - qcom,ipq5424-tsens
+ - qcom,ipq8074-tsens
+
+ - description: v2 of TSENS with combined interrupt
+ items:
+ - enum:
+ - qcom,ipq6018-tsens
+ - qcom,ipq9574-tsens
+ - const: qcom,ipq8074-tsens
+
reg:
items:
- description: TM registers
@@ -66,29 +104,139 @@ properties:
interrupts:
minItems: 1
- items:
- - description: Combined interrupt if upper or lower threshold crossed
- - description: Interrupt if critical threshold crossed
+ maxItems: 2
interrupt-names:
minItems: 1
- items:
- - const: uplow
- - const: critical
+ maxItems: 2
nvmem-cells:
- minItems: 1
- maxItems: 2
- description:
- Reference to an nvmem node for the calibration data
+ oneOf:
+ - minItems: 1
+ maxItems: 2
+ description:
+ Reference to an nvmem node for the calibration data
+ - minItems: 5
+ maxItems: 35
+ description: |
+ Reference to nvmem cells for the calibration mode, two calibration
+ bases and two cells per each sensor
+ # special case for msm8974 / apq8084
+ - maxItems: 51
+ description: |
+ Reference to nvmem cells for the calibration mode, two calibration
+ bases and two cells per each sensor, main and backup copies, plus use_backup cell
nvmem-cell-names:
- minItems: 1
- items:
- - const: calib
- - enum:
- - calib_backup
- - calib_sel
+ oneOf:
+ - minItems: 1
+ items:
+ - const: calib
+ - enum:
+ - calib_backup
+ - calib_sel
+ - minItems: 5
+ items:
+ - const: mode
+ - const: base1
+ - const: base2
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ - pattern: '^s[0-9]+_p1$'
+ - pattern: '^s[0-9]+_p2$'
+ # special case for msm8974 / apq8084
+ - items:
+ - const: mode
+ - const: base1
+ - const: base2
+ - const: use_backup
+ - const: mode_backup
+ - const: base1_backup
+ - const: base2_backup
+ - const: s0_p1
+ - const: s0_p2
+ - const: s1_p1
+ - const: s1_p2
+ - const: s2_p1
+ - const: s2_p2
+ - const: s3_p1
+ - const: s3_p2
+ - const: s4_p1
+ - const: s4_p2
+ - const: s5_p1
+ - const: s5_p2
+ - const: s6_p1
+ - const: s6_p2
+ - const: s7_p1
+ - const: s7_p2
+ - const: s8_p1
+ - const: s8_p2
+ - const: s9_p1
+ - const: s9_p2
+ - const: s10_p1
+ - const: s10_p2
+ - const: s0_p1_backup
+ - const: s0_p2_backup
+ - const: s1_p1_backup
+ - const: s1_p2_backup
+ - const: s2_p1_backup
+ - const: s2_p2_backup
+ - const: s3_p1_backup
+ - const: s3_p2_backup
+ - const: s4_p1_backup
+ - const: s4_p2_backup
+ - const: s5_p1_backup
+ - const: s5_p2_backup
+ - const: s6_p1_backup
+ - const: s6_p2_backup
+ - const: s7_p1_backup
+ - const: s7_p2_backup
+ - const: s8_p1_backup
+ - const: s8_p2_backup
+ - const: s9_p1_backup
+ - const: s9_p2_backup
+ - const: s10_p1_backup
+ - const: s10_p2_backup
+ - minItems: 8
+ items:
+ - const: mode
+ - const: base0
+ - const: base1
+ - pattern: '^tsens_sens[0-9]+_off$'
+ - pattern: '^tsens_sens[0-9]+_off$'
+ - pattern: '^tsens_sens[0-9]+_off$'
+ - pattern: '^tsens_sens[0-9]+_off$'
+ - pattern: '^tsens_sens[0-9]+_off$'
+ - pattern: '^tsens_sens[0-9]+_off$'
+ - pattern: '^tsens_sens[0-9]+_off$'
"#qcom,sensors":
description:
@@ -99,51 +247,76 @@ properties:
"#thermal-sensor-cells":
const: 1
- description:
- Number of cells required to uniquely identify the thermal sensors. Since
- we have multiple sensors this is set to 1
required:
- compatible
- interrupts
- interrupt-names
- - "#thermal-sensor-cells"
- "#qcom,sensors"
allOf:
+ - $ref: thermal-sensor.yaml#
+
- if:
properties:
compatible:
contains:
enum:
+ - qcom,ipq5018-tsens
- qcom,ipq8064-tsens
- - qcom,mdm9607-tsens
- - qcom,msm8916-tsens
- qcom,msm8960-tsens
- - qcom,msm8974-tsens
- - qcom,msm8976-tsens
- - qcom,qcs404-tsens
- qcom,tsens-v0_1
- qcom,tsens-v1
then:
properties:
interrupts:
- maxItems: 1
+ items:
+ - description: Combined interrupt if upper or lower threshold crossed
interrupt-names:
- maxItems: 1
+ items:
+ - const: uplow
- else:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,tsens-v2
+ then:
+ properties:
+ interrupts:
+ items:
+ - description: Combined interrupt if upper or lower threshold crossed
+ - description: Interrupt if critical threshold crossed
+ interrupt-names:
+ items:
+ - const: uplow
+ - const: critical
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5332-tsens
+ - qcom,ipq5424-tsens
+ - qcom,ipq8074-tsens
+ then:
properties:
interrupts:
- minItems: 2
+ items:
+ - description: Combined interrupt if upper, lower or critical thresholds crossed
interrupt-names:
- minItems: 2
+ items:
+ - const: combined
- if:
properties:
compatible:
contains:
enum:
+ - qcom,ipq5332-tsens
+ - qcom,ipq5424-tsens
+ - qcom,ipq8074-tsens
- qcom,tsens-v0_1
- qcom,tsens-v1
- qcom,tsens-v2
@@ -152,78 +325,117 @@ allOf:
required:
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
- // Example msm9860 based SoC (ipq8064):
- gcc: clock-controller {
-
- /* ... */
+ thermal-sensor {
+ compatible = "qcom,ipq8064-tsens";
- tsens: thermal-sensor {
- compatible = "qcom,ipq8064-tsens";
+ nvmem-cells = <&tsens_calib>, <&tsens_calib_backup>;
+ nvmem-cell-names = "calib", "calib_backup";
+ interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow";
- nvmem-cells = <&tsens_calib>, <&tsens_calib_backup>;
- nvmem-cell-names = "calib", "calib_backup";
- interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow";
+ #qcom,sensors = <11>;
+ #thermal-sensor-cells = <1>;
+ };
- #qcom,sensors = <11>;
- #thermal-sensor-cells = <1>;
- };
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ // Example 1 (new calibration data: for pre v1 IP):
+ thermal-sensor@4a9000 {
+ compatible = "qcom,msm8916-tsens", "qcom,tsens-v0_1";
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
+
+ nvmem-cells = <&tsens_mode>,
+ <&tsens_base1>, <&tsens_base2>,
+ <&tsens_s0_p1>, <&tsens_s0_p2>,
+ <&tsens_s1_p1>, <&tsens_s1_p2>,
+ <&tsens_s2_p1>, <&tsens_s2_p2>,
+ <&tsens_s4_p1>, <&tsens_s4_p2>,
+ <&tsens_s5_p1>, <&tsens_s5_p2>;
+ nvmem-cell-names = "mode",
+ "base1", "base2",
+ "s0_p1", "s0_p2",
+ "s1_p1", "s1_p2",
+ "s2_p1", "s2_p2",
+ "s4_p1", "s4_p2",
+ "s5_p1", "s5_p2";
+
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow";
+
+ #qcom,sensors = <5>;
+ #thermal-sensor-cells = <1>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
// Example 1 (legacy: for pre v1 IP):
- tsens1: thermal-sensor@900000 {
- compatible = "qcom,msm8916-tsens", "qcom,tsens-v0_1";
- reg = <0x4a9000 0x1000>, /* TM */
- <0x4a8000 0x1000>; /* SROT */
+ tsens1: thermal-sensor@4a9000 {
+ compatible = "qcom,msm8916-tsens", "qcom,tsens-v0_1";
+ reg = <0x4a9000 0x1000>, /* TM */
+ <0x4a8000 0x1000>; /* SROT */
- nvmem-cells = <&tsens_caldata>, <&tsens_calsel>;
- nvmem-cell-names = "calib", "calib_sel";
+ nvmem-cells = <&tsens_caldata>, <&tsens_calsel>;
+ nvmem-cell-names = "calib", "calib_sel";
- interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow";
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow";
- #qcom,sensors = <5>;
- #thermal-sensor-cells = <1>;
+ #qcom,sensors = <5>;
+ #thermal-sensor-cells = <1>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
// Example 2 (for any platform containing v1 of the TSENS IP):
tsens2: thermal-sensor@4a9000 {
- compatible = "qcom,qcs404-tsens", "qcom,tsens-v1";
- reg = <0x004a9000 0x1000>, /* TM */
- <0x004a8000 0x1000>; /* SROT */
+ compatible = "qcom,qcs404-tsens", "qcom,tsens-v1";
+ reg = <0x004a9000 0x1000>, /* TM */
+ <0x004a8000 0x1000>; /* SROT */
- nvmem-cells = <&tsens_caldata>;
- nvmem-cell-names = "calib";
+ nvmem-cells = <&tsens_caldata>;
+ nvmem-cell-names = "calib";
- interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow";
+ interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow";
- #qcom,sensors = <10>;
- #thermal-sensor-cells = <1>;
+ #qcom,sensors = <10>;
+ #thermal-sensor-cells = <1>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
// Example 3 (for any platform containing v2 of the TSENS IP):
tsens3: thermal-sensor@c263000 {
- compatible = "qcom,sdm845-tsens", "qcom,tsens-v2";
- reg = <0xc263000 0x1ff>,
- <0xc222000 0x1ff>;
+ compatible = "qcom,sdm845-tsens", "qcom,tsens-v2";
+ reg = <0xc263000 0x1ff>,
+ <0xc222000 0x1ff>;
+
+ interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow", "critical";
+
+ #qcom,sensors = <13>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ // Example 4 (for any IPQ8074 based SoC-s):
+ tsens4: thermal-sensor@4a9000 {
+ compatible = "qcom,ipq8074-tsens";
+ reg = <0x4a9000 0x1000>,
+ <0x4a8000 0x1000>;
- interrupts = <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow", "critical";
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "combined";
- #qcom,sensors = <13>;
- #thermal-sensor-cells = <1>;
+ #qcom,sensors = <16>;
+ #thermal-sensor-cells = <1>;
};
...
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
index f09e8723ca2b..aa756dae512a 100644
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -7,7 +7,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
+
+$ref: thermal-sensor.yaml#
properties:
compatible:
@@ -29,14 +33,15 @@ properties:
maxItems: 1
fsl,tmu-range:
- $ref: '/schemas/types.yaml#/definitions/uint32-array'
+ $ref: /schemas/types.yaml#/definitions/uint32-array
description: |
The values to be programmed into TTRnCR, as specified by the SoC
reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
- maxItems: 4
+ minItems: 2
+ maxItems: 7
fsl,tmu-calibration:
- $ref: '/schemas/types.yaml#/definitions/uint32-matrix'
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
description: |
A list of cell pairs containing temperature calibration data, as
specified by the SoC reference manual. The first cell of each pair
@@ -67,9 +72,8 @@ required:
- interrupts
- fsl,tmu-range
- fsl,tmu-calibration
- - '#thermal-sensor-cells'
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
index 0f05f5c886c5..b6657d64cf3d 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
@@ -15,6 +15,8 @@ description:
maintainers:
- Niklas Söderlund <niklas.soderlund@ragnatech.se>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
enum:
@@ -28,6 +30,8 @@ properties:
- renesas,r8a77980-thermal # R-Car V3H
- renesas,r8a779a0-thermal # R-Car V3U
- renesas,r8a779f0-thermal # R-Car S4-8
+ - renesas,r8a779g0-thermal # R-Car V4H
+ - renesas,r8a779h0-thermal # R-Car V4M
reg: true
@@ -55,7 +59,6 @@ required:
- clocks
- power-domains
- resets
- - "#thermal-sensor-cells"
if:
properties:
@@ -80,6 +83,7 @@ else:
- description: TSC1 registers
- description: TSC2 registers
- description: TSC3 registers
+ - description: TSC4 registers
if:
not:
properties:
@@ -87,11 +91,13 @@ else:
contains:
enum:
- renesas,r8a779f0-thermal
+ - renesas,r8a779g0-thermal
+ - renesas,r8a779h0-thermal
then:
required:
- interrupts
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -100,33 +106,33 @@ examples:
#include <dt-bindings/power/r8a7795-sysc.h>
tsc: thermal@e6198000 {
- compatible = "renesas,r8a7795-thermal";
- reg = <0xe6198000 0x100>,
- <0xe61a0000 0x100>,
- <0xe61a8000 0x100>;
- interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 522>;
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
- resets = <&cpg 522>;
- #thermal-sensor-cells = <1>;
+ compatible = "renesas,r8a7795-thermal";
+ reg = <0xe6198000 0x100>,
+ <0xe61a0000 0x100>,
+ <0xe61a8000 0x100>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 522>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 522>;
+ #thermal-sensor-cells = <1>;
};
thermal-zones {
- sensor_thermal: sensor-thermal {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 0>;
-
- trips {
- sensor1_crit: sensor1-crit {
- temperature = <90000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
+ sensor_thermal: sensor-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 0>;
+
+ trips {
+ sensor1_crit: sensor1-crit {
+ temperature = <90000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
};
+ };
};
- |
#include <dt-bindings/clock/r8a779a0-cpg-mssr.h>
@@ -134,14 +140,14 @@ examples:
#include <dt-bindings/power/r8a779a0-sysc.h>
tsc_r8a779a0: thermal@e6190000 {
- compatible = "renesas,r8a779a0-thermal";
- reg = <0xe6190000 0x200>,
- <0xe6198000 0x200>,
- <0xe61a0000 0x200>,
- <0xe61a8000 0x200>,
- <0xe61b0000 0x200>;
- clocks = <&cpg CPG_MOD 919>;
- power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>;
- resets = <&cpg 919>;
- #thermal-sensor-cells = <1>;
+ compatible = "renesas,r8a779a0-thermal";
+ reg = <0xe6190000 0x200>,
+ <0xe6198000 0x200>,
+ <0xe61a0000 0x200>,
+ <0xe61a8000 0x200>,
+ <0xe61b0000 0x200>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>;
+ resets = <&cpg 919>;
+ #thermal-sensor-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
index 119998d10ff4..221a58d18cad 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml
@@ -98,8 +98,8 @@ examples:
# Example (non interrupt support)
- |
thermal@ffc48000 {
- compatible = "renesas,thermal-r8a7779", "renesas,rcar-thermal";
- reg = <0xffc48000 0x38>;
+ compatible = "renesas,thermal-r8a7779", "renesas,rcar-thermal";
+ reg = <0xffc48000 0x38>;
};
# Example (interrupt support)
@@ -109,12 +109,12 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
thermal@e61f0000 {
- compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal";
- reg = <0xe61f0000 0x14>, <0xe61f0100 0x38>,
- <0xe61f0200 0x38>, <0xe61f0300 0x38>;
- interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp5_clks R8A73A4_CLK_THERMAL>;
- power-domains = <&pd_c5>;
+ compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal";
+ reg = <0xe61f0000 0x14>, <0xe61f0100 0x38>,
+ <0xe61f0200 0x38>, <0xe61f0300 0x38>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp5_clks R8A73A4_CLK_THERMAL>;
+ power-domains = <&pd_c5>;
};
# Example (with thermal-zone)
@@ -124,32 +124,32 @@ examples:
#include <dt-bindings/power/r8a7790-sysc.h>
thermal: thermal@e61f0000 {
- compatible = "renesas,thermal-r8a7790",
- "renesas,rcar-gen2-thermal",
- "renesas,rcar-thermal";
- reg = <0xe61f0000 0x10>, <0xe61f0100 0x38>;
- interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 522>;
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 522>;
- #thermal-sensor-cells = <0>;
+ compatible = "renesas,thermal-r8a7790",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
+ reg = <0xe61f0000 0x10>, <0xe61f0100 0x38>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 522>;
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 522>;
+ #thermal-sensor-cells = <0>;
};
thermal-zones {
- cpu_thermal: cpu-thermal {
- polling-delay-passive = <1000>;
- polling-delay = <5000>;
-
- thermal-sensors = <&thermal>;
-
- trips {
- cpu-crit {
- temperature = <115000>;
- hysteresis = <0>;
- type = "critical";
- };
- };
- cooling-maps {
- };
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
};
+ cooling-maps {
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/thermal/renesas,r9a08g045-tsu.yaml b/Documentation/devicetree/bindings/thermal/renesas,r9a08g045-tsu.yaml
new file mode 100644
index 000000000000..573e2b9d3752
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/renesas,r9a08g045-tsu.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/renesas,r9a08g045-tsu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G3S Thermal Sensor Unit
+
+description:
+ The thermal sensor unit (TSU) measures the temperature(Tj) inside
+ the LSI.
+
+maintainers:
+ - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+
+$ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ const: renesas,r9a08g045-tsu
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TSU module clock
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: TSU module reset
+
+ io-channels:
+ items:
+ - description: ADC channel which reports the TSU temperature
+
+ io-channel-names:
+ items:
+ - const: tsu
+
+ "#thermal-sensor-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - resets
+ - io-channels
+ - io-channel-names
+ - '#thermal-sensor-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a08g045-cpg.h>
+
+ tsu: thermal@10059000 {
+ compatible = "renesas,r9a08g045-tsu";
+ reg = <0x10059000 0x1000>;
+ clocks = <&cpg CPG_MOD R9A08G045_TSU_PCLK>;
+ resets = <&cpg R9A08G045_TSU_PRESETN>;
+ power-domains = <&cpg>;
+ #thermal-sensor-cells = <0>;
+ io-channels = <&adc 8>;
+ io-channel-names = "tsu";
+ };
+
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsu>;
+
+ trips {
+ sensor_crit: sensor-crit {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ target: trip-point {
+ temperature = <100000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/thermal/renesas,r9a09g047-tsu.yaml b/Documentation/devicetree/bindings/thermal/renesas,r9a09g047-tsu.yaml
new file mode 100644
index 000000000000..befdc8b7a082
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/renesas,r9a09g047-tsu.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/renesas,r9a09g047-tsu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G3E Temperature Sensor Unit (TSU)
+
+maintainers:
+ - John Madieu <john.madieu.xa@bp.renesas.com>
+
+description:
+ The Temperature Sensor Unit (TSU) is an integrated thermal sensor that
+ monitors the chip temperature on the Renesas RZ/G3E SoC. The TSU provides
+ real-time temperature measurements for thermal management.
+
+properties:
+ compatible:
+ oneOf:
+ - const: renesas,r9a09g047-tsu # RZ/G3E
+ - items:
+ - const: renesas,r9a09g057-tsu # RZ/V2H
+ - const: renesas,r9a09g047-tsu # RZ/G3E
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Conversion complete interrupt signal (pulse)
+ - description: Comparison result interrupt signal (level)
+
+ interrupt-names:
+ items:
+ - const: adi
+ - const: adcmpi
+
+ "#thermal-sensor-cells":
+ const: 0
+
+ renesas,tsu-trim:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to system controller
+ - description: offset of trim registers
+ description:
+ Phandle and offset to the system controller containing the TSU
+ calibration trim values. The offset points to the first trim register
+ (OTPTSU1TRMVAL0), with the second trim register (OTPTSU1TRMVAL1) located
+ at offset + 4.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - power-domains
+ - interrupts
+ - interrupt-names
+ - "#thermal-sensor-cells"
+ - renesas,tsu-trim
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g047-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ thermal-sensor@14002000 {
+ compatible = "renesas,r9a09g047-tsu";
+ reg = <0x14002000 0x1000>;
+ clocks = <&cpg CPG_MOD 0x10a>;
+ resets = <&cpg 0xf8>;
+ power-domains = <&cpg>;
+ interrupts = <GIC_SPI 250 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "adi", "adcmpi";
+ #thermal-sensor-cells = <0>;
+ renesas,tsu-trim = <&sys 0x330>;
+ };
diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
index f6c1be226aaa..9fa5c4c49d76 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
@@ -9,6 +9,8 @@ title: Temperature Sensor ADC (TSADC) on Rockchip SoCs
maintainers:
- Heiko Stuebner <heiko@sntech.de>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
enum:
@@ -19,6 +21,8 @@ properties:
- rockchip,rk3368-tsadc
- rockchip,rk3399-tsadc
- rockchip,rk3568-tsadc
+ - rockchip,rk3576-tsadc
+ - rockchip,rk3588-tsadc
- rockchip,rv1108-tsadc
reg:
@@ -36,6 +40,17 @@ properties:
- const: tsadc
- const: apb_pclk
+ nvmem-cells:
+ items:
+ - description: cell handle to where the trim's base temperature is stored
+ - description:
+ cell handle to where the trim's tenths of Celsius base value is stored
+
+ nvmem-cell-names:
+ items:
+ - const: trim_base
+ - const: trim_base_frac
+
resets:
minItems: 1
maxItems: 3
@@ -47,6 +62,12 @@ properties:
- const: tsadc
- const: tsadc-phy
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
"#thermal-sensor-cells":
const: 1
@@ -68,6 +89,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
+patternProperties:
+ "@[0-9a-f]+$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+ description: sensor ID, a.k.a. channel number
+
+ nvmem-cells:
+ items:
+ - description: handle of cell containing calibration data
+
+ nvmem-cell-names:
+ items:
+ - const: trim
+
+ required:
+ - reg
+
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -75,9 +117,46 @@ required:
- clocks
- clock-names
- resets
- - "#thermal-sensor-cells"
-additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,px30-tsadc
+ - rockchip,rk3366-tsadc
+ - rockchip,rk3399-tsadc
+ - rockchip,rk3568-tsadc
+ then:
+ required:
+ - rockchip,grf
+ else:
+ properties:
+ rockchip,grf: false
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-tsadc
+ then:
+ properties:
+ nvmem-cells: false
+ nvmem-cell-names: false
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-tsadc
+ - rockchip,rk3576-tsadc
+ then:
+ patternProperties:
+ "@[0-9a-f]+$": false
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml b/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml
index 1d8373397848..136589f5adee 100644
--- a/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml
@@ -13,11 +13,13 @@ description:
maintainers:
- Biju Das <biju.das.jz@bp.renesas.com>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
items:
- enum:
- - renesas,r9a07g043-tsu # RZ/G2UL
+ - renesas,r9a07g043-tsu # RZ/G2UL and RZ/Five
- renesas,r9a07g044-tsu # RZ/G2{L,LC}
- renesas,r9a07g054-tsu # RZ/V2L
- const: renesas,rzg2l-tsu
@@ -43,36 +45,35 @@ required:
- clocks
- power-domains
- resets
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/r9a07g044-cpg.h>
tsu: thermal@10059400 {
- compatible = "renesas,r9a07g044-tsu",
- "renesas,rzg2l-tsu";
- reg = <0x10059400 0x400>;
- clocks = <&cpg CPG_MOD R9A07G044_TSU_PCLK>;
- resets = <&cpg R9A07G044_TSU_PRESETN>;
- power-domains = <&cpg>;
- #thermal-sensor-cells = <1>;
+ compatible = "renesas,r9a07g044-tsu",
+ "renesas,rzg2l-tsu";
+ reg = <0x10059400 0x400>;
+ clocks = <&cpg CPG_MOD R9A07G044_TSU_PCLK>;
+ resets = <&cpg R9A07G044_TSU_PRESETN>;
+ power-domains = <&cpg>;
+ #thermal-sensor-cells = <1>;
};
thermal-zones {
- cpu-thermal {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsu 0>;
-
- trips {
- sensor_crit: sensor-crit {
- temperature = <125000>;
- hysteresis = <1000>;
- type = "critical";
- };
- };
+ cpu-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsu 0>;
+
+ trips {
+ sensor_crit: sensor-crit {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
};
+ };
};
diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
index 1344df708e2d..29a08b0729ee 100644
--- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
@@ -61,7 +61,8 @@ properties:
TRIMINFO at 0x10068000 contains data for TMU channel 2
minItems: 1
- '#thermal-sensor-cells': true
+ '#thermal-sensor-cells':
+ const: 0
vtmu-supply:
description: The regulator node supplying voltage to TMU.
diff --git a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
index c5b25ce44956..8210b7079721 100644
--- a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
@@ -14,6 +14,8 @@ description: |
maintainers:
- Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
enum:
@@ -38,22 +40,16 @@ properties:
required:
- compatible
- interrupts
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
// The UniPhier thermal should be a subnode of a "syscon" compatible node.
- sysctrl@61840000 {
- compatible = "socionext,uniphier-ld20-sysctrl",
- "simple-mfd", "syscon";
- reg = <0x61840000 0x10000>;
-
- pvtctl: thermal {
- compatible = "socionext,uniphier-ld20-thermal";
- interrupts = <0 3 1>;
- #thermal-sensor-cells = <0>;
- };
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ pvtctl: thermal-sensor {
+ compatible = "socionext,uniphier-ld20-thermal";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ #thermal-sensor-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml b/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml
index 6d65a3cf2af2..afa551f6185f 100644
--- a/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml
@@ -4,13 +4,15 @@
$id: http://devicetree.org/schemas/thermal/sprd-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Spreadtrum thermal sensor controller bindings
+title: Spreadtrum thermal sensor controller
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
- Baolin Wang <baolin.wang7@gmail.com>
- Chunyan Zhang <zhang.lyra@gmail.com>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
const: sprd,ums512-thermal
@@ -77,35 +79,34 @@ required:
- clock-names
- nvmem-cells
- nvmem-cell-names
- - "#thermal-sensor-cells"
- "#address-cells"
- "#size-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- ap_thm0: thermal@32200000 {
- compatible = "sprd,ums512-thermal";
- reg = <0x32200000 0x10000>;
- clock-names = "enable";
- clocks = <&aonapb_gate 32>;
- #thermal-sensor-cells = <1>;
- nvmem-cells = <&thm0_sign>, <&thm0_ratio>;
- nvmem-cell-names = "thm_sign_cal", "thm_ratio_cal";
- #address-cells = <1>;
- #size-cells = <0>;
-
- prometheus-sensor@0 {
- reg = <0>;
- nvmem-cells = <&thm0_sen0>;
- nvmem-cell-names = "sen_delta_cal";
- };
-
- ank-sensor@1 {
- reg = <1>;
- nvmem-cells = <&thm0_sen1>;
- nvmem-cell-names = "sen_delta_cal";
- };
+ thermal@32200000 {
+ compatible = "sprd,ums512-thermal";
+ reg = <0x32200000 0x10000>;
+ clock-names = "enable";
+ clocks = <&aonapb_gate 32>;
+ #thermal-sensor-cells = <1>;
+ nvmem-cells = <&thm0_sign>, <&thm0_ratio>;
+ nvmem-cell-names = "thm_sign_cal", "thm_ratio_cal";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ prometheus-sensor@0 {
+ reg = <0>;
+ nvmem-cells = <&thm0_sen0>;
+ nvmem-cell-names = "sen_delta_cal";
+ };
+
+ ank-sensor@1 {
+ reg = <1>;
+ nvmem-cells = <&thm0_sen1>;
+ nvmem-cell-names = "sen_delta_cal";
};
+ };
...
diff --git a/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml b/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml
new file mode 100644
index 000000000000..9f6fc5c95c55
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,stih407-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi digital thermal sensor (DTS)
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+ - Lee Jones <lee@kernel.org>
+
+allOf:
+ - $ref: thermal-sensor.yaml
+
+properties:
+ compatible:
+ const: st,stih407-thermal
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: thermal
+
+ interrupts:
+ description:
+ For thermal sensors for which no interrupt has been defined, a polling
+ delay of 1000ms will be used to read the temperature from device.
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ temperature-sensor@91a0000 {
+ compatible = "st,stih407-thermal";
+ reg = <0x91a0000 0x28>;
+ clock-names = "thermal";
+ clocks = <&CLK_SYSIN>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
+ #thermal-sensor-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml b/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml
index bee41cff5142..1c01a80a0cdd 100644
--- a/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/st,stm32-thermal.yaml
@@ -4,11 +4,13 @@
$id: http://devicetree.org/schemas/thermal/st,stm32-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 digital thermal sensor (DTS) binding
+title: STMicroelectronics STM32 digital thermal sensor (DTS)
maintainers:
- Pascal Paillet <p.paillet@foss.st.com>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
const: st,stm32-thermal
@@ -30,14 +32,13 @@ properties:
const: 0
required:
- - "#thermal-sensor-cells"
- compatible
- reg
- interrupts
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt b/Documentation/devicetree/bindings/thermal/st-thermal.txt
deleted file mode 100644
index a2f939137e35..000000000000
--- a/Documentation/devicetree/bindings/thermal/st-thermal.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Binding for Thermal Sensor driver for STMicroelectronics STi series of SoCs.
-
-Required parameters:
--------------------
-
-compatible : Should be "st,stih407-thermal"
-
-clock-names : Should be "thermal".
- See: Documentation/devicetree/bindings/resource-names.txt
-clocks : Phandle of the clock used by the thermal sensor.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Optional parameters:
--------------------
-
-reg : For non-sysconf based sensors, this should be the physical base
- address and length of the sensor's registers.
-interrupts : Standard way to define interrupt number.
- NB: For thermal sensor's for which no interrupt has been
- defined, a polling delay of 1000ms will be used to read the
- temperature from device.
-
-Example:
-
- temp0@91a0000 {
- compatible = "st,stih407-thermal";
- reg = <0x91a0000 0x28>;
- clock-names = "thermal";
- clocks = <&CLK_SYSIN>;
- interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
- st,passive_cooling_temp = <110>;
- };
diff --git a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
index 850a9841b110..b9022f1613d8 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/thermal/thermal-cooling-devices.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Thermal cooling device binding
+title: Thermal cooling device
maintainers:
- Amit Kucheria <amitk@kernel.org>
@@ -76,9 +76,13 @@ examples:
next-level-cache = <&L2_0>;
L2_0: l2-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <2>;
next-level-cache = <&L3_0>;
L3_0: l3-cache {
compatible = "cache";
+ cache-unified;
+ cache-level = <3>;
};
};
};
diff --git a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
deleted file mode 100644
index e136946a2f4f..000000000000
--- a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-General Purpose Analog To Digital Converter (ADC) based thermal sensor.
-
-On some of platforms, thermal sensor like thermistors are connected to
-one of ADC channel and sensor resistance is read via voltage across the
-sensor resistor. The voltage read across the sensor is mapped to
-temperature using voltage-temperature lookup table.
-
-Required properties:
-===================
-- compatible: Must be "generic-adc-thermal".
-- #thermal-sensor-cells: Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description
- of this property.
-Optional properties:
-===================
-- temperature-lookup-table: Two dimensional array of Integer; lookup table
- to map the relation between ADC value and
- temperature. When ADC is read, the value is
- looked up on the table to get the equivalent
- temperature.
-
- The first value of the each row of array is the
- temperature in milliCelsius and second value of
- the each row of array is the ADC read value.
-
- If not specified, driver assumes the ADC channel
- gives milliCelsius directly.
-
-Example :
-#include <dt-bindings/thermal/thermal.h>
-
-i2c@7000c400 {
- ads1015: ads1015@4a {
- reg = <0x4a>;
- compatible = "ads1015";
- sampling-frequency = <3300>;
- #io-channel-cells = <1>;
- };
-};
-
-tboard_thermistor: thermal-sensor {
- compatible = "generic-adc-thermal";
- #thermal-sensor-cells = <0>;
- io-channels = <&ads1015 1>;
- io-channel-names = "sensor-channel";
- temperature-lookup-table = < (-40000) 2578
- (-39000) 2577
- (-38000) 2576
- (-37000) 2575
- (-36000) 2574
- (-35000) 2573
- (-34000) 2572
- (-33000) 2571
- (-32000) 2569
- (-31000) 2568
- (-30000) 2567
- ::::::::::
- 118000 254
- 119000 247
- 120000 240
- 121000 233
- 122000 226
- 123000 220
- 124000 214
- 125000 208>;
-};
-
-dummy_cool_dev: dummy-cool-dev {
- compatible = "dummy-cooling-dev";
- #cooling-cells = <2>; /* min followed by max */
-};
-
-thermal-zones {
- Tboard {
- polling-delay = <15000>; /* milliseconds */
- polling-delay-passive = <0>; /* milliseconds */
- thermal-sensors = <&tboard_thermistor>;
-
- trips {
- therm_est_trip: therm_est_trip {
- temperature = <40000>;
- type = "active";
- hysteresis = <1000>;
- };
- };
-
- cooling-maps {
- map0 {
- trip = <&therm_est_trip>;
- cooling-device = <&dummy_cool_dev THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
- contribution = <100>;
- };
-
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
index cc938d7ad1f3..1b77d542a7b8 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/thermal/thermal-idle.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Thermal idle cooling device binding
+title: Thermal idle cooling device
maintainers:
- Daniel Lezcano <daniel.lezcano@linaro.org>
@@ -48,99 +48,105 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/thermal/thermal.h>
+ /{
+ #include <dt-bindings/thermal/thermal.h>
- // Example: Combining idle cooling device on big CPUs with cpufreq cooling device
- cpus {
+ compatible = "foo";
+ model = "foo";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ // Example: Combining idle cooling device on big CPUs with cpufreq cooling device
+ cpus {
#address-cells = <2>;
#size-cells = <0>;
/* ... */
- cpu_b0: cpu@100 {
- device_type = "cpu";
- compatible = "arm,cortex-a72";
- reg = <0x0 0x100>;
- enable-method = "psci";
- capacity-dmips-mhz = <1024>;
- dynamic-power-coefficient = <436>;
- #cooling-cells = <2>; /* min followed by max */
- cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>;
- thermal-idle {
- #cooling-cells = <2>;
- duration-us = <10000>;
- exit-latency-us = <500>;
- };
+ cpu_b0: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
+ dynamic-power-coefficient = <436>;
+ #cooling-cells = <2>; /* min followed by max */
+ cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>;
+ cpu_b0_therm: thermal-idle {
+ #cooling-cells = <2>;
+ duration-us = <10000>;
+ exit-latency-us = <500>;
+ };
+ };
+
+ cpu_b1: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
+ dynamic-power-coefficient = <436>;
+ #cooling-cells = <2>; /* min followed by max */
+ cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>;
+ cpu_b1_therm: thermal-idle {
+ #cooling-cells = <2>;
+ duration-us = <10000>;
+ exit-latency-us = <500>;
};
+ };
- cpu_b1: cpu@101 {
- device_type = "cpu";
- compatible = "arm,cortex-a72";
- reg = <0x0 0x101>;
- enable-method = "psci";
- capacity-dmips-mhz = <1024>;
- dynamic-power-coefficient = <436>;
- #cooling-cells = <2>; /* min followed by max */
- cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>;
- thermal-idle {
- #cooling-cells = <2>;
- duration-us = <10000>;
- exit-latency-us = <500>;
- };
- };
-
- /* ... */
+ /* ... */
- };
+ };
- /* ... */
+ /* ... */
- thermal_zones {
- cpu_thermal: cpu {
+ thermal_zones {
+ cpu_thermal: cpu {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* ... */
trips {
- cpu_alert0: cpu_alert0 {
- temperature = <65000>;
- hysteresis = <2000>;
- type = "passive";
- };
-
- cpu_alert1: cpu_alert1 {
- temperature = <70000>;
- hysteresis = <2000>;
- type = "passive";
- };
-
- cpu_alert2: cpu_alert2 {
- temperature = <75000>;
- hysteresis = <2000>;
- type = "passive";
- };
-
- cpu_crit: cpu_crit {
- temperature = <95000>;
- hysteresis = <2000>;
- type = "critical";
- };
+ cpu_alert0: cpu_alert0 {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_alert1: cpu_alert1 {
+ temperature = <70000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_alert2: cpu_alert2 {
+ temperature = <75000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
};
cooling-maps {
- map0 {
- trip = <&cpu_alert1>;
- cooling-device = <&{/cpus/cpu@100/thermal-idle} 0 15 >,
- <&{/cpus/cpu@101/thermal-idle} 0 15>;
- };
-
- map1 {
- trip = <&cpu_alert2>;
- cooling-device =
- <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&cpu_b1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
- };
+ map0 {
+ trip = <&cpu_alert1>;
+ cooling-device = <&cpu_b0_therm 0 15 >,
+ <&cpu_b1_therm 0 15>;
+ };
+
+ map1 {
+ trip = <&cpu_alert2>;
+ cooling-device = <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu_b1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
};
- };
+ };
+ };
};
diff --git a/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml b/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml
index 4bd345c71eb8..57565b3fb07c 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-sensor.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/thermal/thermal-sensor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Thermal sensor binding
+title: Thermal sensor
maintainers:
- Amit Kucheria <amitk@kernel.org>
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
index 8d2c6d74b605..0de0a9757ccc 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -5,10 +5,10 @@
$id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
$schema: http://devicetree.org/meta-schemas/base.yaml#
-title: Thermal zone binding
+title: Thermal zone
maintainers:
- - Amit Kucheria <amitk@kernel.org>
+ - Daniel Lezcano <daniel.lezcano@linaro.org>
description: |
Thermal management is achieved in devicetree by describing the sensor hardware
@@ -49,7 +49,10 @@ properties:
to take when the temperature crosses those thresholds.
patternProperties:
- "^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$":
+ # Node name is limited in size due to Linux kernel requirements - 19
+ # characters in total (see THERMAL_NAME_LENGTH, including terminating NUL
+ # byte):
+ "^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$":
type: object
description:
Each thermal zone node contains information about how frequently it
@@ -75,6 +78,21 @@ patternProperties:
framework and assumes that the thermal sensors in this zone
support interrupts.
+ critical-action:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ The action the OS should perform after the critical temperature is reached.
+ If the property is not set, it is up to the system to select the correct
+ action. The recommended and preferred default is shutdown.
+ Choose 'reboot' with care, as the hardware may be in thermal stress,
+ thus leading to infinite reboots that may cause damage to the hardware.
+ Make sure the firmware/bootloader will act as the last resort and take
+ over the thermal control.
+
+ enum:
+ - shutdown
+ - reboot
+
thermal-sensors:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
@@ -171,6 +189,7 @@ patternProperties:
cooling-maps:
type: object
+ additionalProperties: false
description:
This node describes the action to be taken when a thermal zone
crosses one of the temperature thresholds described in the trips
@@ -211,10 +230,7 @@ patternProperties:
additionalProperties: false
required:
- - polling-delay
- - polling-delay-passive
- thermal-sensors
- - trips
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml b/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml
index ea14de80ec75..c123d9070525 100644
--- a/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/ti,am654-thermal.yaml
@@ -4,11 +4,13 @@
$id: http://devicetree.org/schemas/thermal/ti,am654-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments AM654 VTM (DTS) binding
+title: Texas Instruments AM654 VTM (DTS)
maintainers:
- Keerthy <j-keerthy@ti.com>
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
const: ti,am654-vtm
@@ -26,9 +28,8 @@ required:
- compatible
- reg
- power-domains
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -46,11 +47,11 @@ examples:
thermal-sensors = <&vtm0 0>;
trips {
- mpu0_crit: mpu0_crit {
- temperature = <125000>; /* milliCelsius */
- hysteresis = <2000>; /* milliCelsius */
- type = "critical";
- };
+ mpu0_crit: mpu0_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
};
};
...
diff --git a/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml b/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml
index c74f124ebfc0..82b77b9795a3 100644
--- a/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml
@@ -4,11 +4,26 @@
$id: http://devicetree.org/schemas/thermal/ti,j72xx-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments J72XX VTM (DTS) binding
+title: Texas Instruments J72XX VTM (DTS)
maintainers:
- Keerthy <j-keerthy@ti.com>
+description: |
+ The TI K3 family of SoCs typically have a Voltage & Thermal
+ Management (VTM) device to control up to 8 temperature diode
+ sensors to measure silicon junction temperatures from different
+ hotspots of the chip as well as provide temperature, interrupt
+ and alerting information.
+
+ The following polynomial equation can then be used to convert
+ value returned by this device into a temperature in Celsius
+
+ Temp(C) = (-9.2627e-12) * x^4 + (6.0373e-08) * x^3 + \
+ (-1.7058e-04) * x^2 + (3.2512e-01) * x + (-4.9003e+01)
+
+$ref: thermal-sensor.yaml#
+
properties:
compatible:
enum:
@@ -19,7 +34,12 @@ properties:
items:
- description: VTM cfg1 register space
- description: VTM cfg2 register space
- - description: VTM efuse register space
+ - description: |
+ A software trimming method must be applied to some Jacinto
+ devices to function properly. This eFuse region provides
+ the information needed for these SoCs to report
+ temperatures accurately.
+ minItems: 2
power-domains:
maxItems: 1
@@ -27,13 +47,27 @@ properties:
"#thermal-sensor-cells":
const: 1
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,j721e-vtm
+ then:
+ properties:
+ reg:
+ minItems: 3
+ else:
+ properties:
+ reg:
+ maxItems: 2
+
required:
- compatible
- reg
- power-domains
- - "#thermal-sensor-cells"
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/timer/actions,owl-timer.txt b/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
deleted file mode 100644
index 977054f87563..000000000000
--- a/Documentation/devicetree/bindings/timer/actions,owl-timer.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Actions Semi Owl Timer
-
-Required properties:
-- compatible : "actions,s500-timer" for S500
- "actions,s700-timer" for S700
- "actions,s900-timer" for S900
-- reg : Offset and length of the register set for the device.
-- interrupts : Should contain the interrupts.
-- interrupt-names : Valid names are: "2hz0", "2hz1",
- "timer0", "timer1", "timer2", "timer3"
- See ../resource-names.txt
-
-Example:
-
- timer@b0168000 {
- compatible = "actions,s500-timer";
- reg = <0xb0168000 0x100>;
- interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "timer0", "timer1";
- };
diff --git a/Documentation/devicetree/bindings/timer/actions,owl-timer.yaml b/Documentation/devicetree/bindings/timer/actions,owl-timer.yaml
new file mode 100644
index 000000000000..646c554a390a
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/actions,owl-timer.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/actions,owl-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl timer
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+
+description:
+ Actions Semi Owl SoCs provide 32bit and 2Hz timers.
+ The 32bit timers support dynamic irq, as well as one-shot mode.
+
+properties:
+ compatible:
+ enum:
+ - actions,s500-timer
+ - actions,s700-timer
+ - actions,s900-timer
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 6
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 6
+ items:
+ enum:
+ - 2hz0
+ - 2hz1
+ - timer0
+ - timer1
+ - timer2
+ - timer3
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - interrupts
+ - interrupt-names
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - actions,s500-timer
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ maxItems: 4
+ interrupt-names:
+ items:
+ - const: 2hz0
+ - const: 2hz1
+ - const: timer0
+ - const: timer1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - actions,s700-timer
+ - actions,s900-timer
+ then:
+ properties:
+ interrupts:
+ minItems: 1
+ maxItems: 1
+ interrupt-names:
+ items:
+ - const: timer1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ timer@b0168000 {
+ compatible = "actions,s500-timer";
+ reg = <0xb0168000 0x100>;
+ clocks = <&hosc>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "2hz0", "2hz1", "timer0", "timer1";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml
index 3711872b6b99..b3538fac1ad2 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-a10-timer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/allwinner,sun4i-a10-timer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Timer Device Tree Bindings
+title: Allwinner A10 Timer
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
index 2ecac754e1cd..f1853daec2f9 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/allwinner,sun5i-a13-hstimer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A13 High-Speed Timer Device Tree Bindings
+title: Allwinner A13 High-Speed Timer
maintainers:
- Chen-Yu Tsai <wens@csie.org>
diff --git a/Documentation/devicetree/bindings/timer/altr,timer-1.0.txt b/Documentation/devicetree/bindings/timer/altr,timer-1.0.txt
deleted file mode 100644
index e698e3488735..000000000000
--- a/Documentation/devicetree/bindings/timer/altr,timer-1.0.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Altera Timer
-
-Required properties:
-
-- compatible : should be "altr,timer-1.0"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : Should contain the timer interrupt number
-- clock-frequency : The frequency of the clock that drives the counter, in Hz.
-
-Example:
-
-timer {
- compatible = "altr,timer-1.0";
- reg = <0x00400000 0x00000020>;
- interrupt-parent = <&cpu>;
- interrupts = <11>;
- clock-frequency = <125000000>;
-};
diff --git a/Documentation/devicetree/bindings/timer/altr,timer-1.0.yaml b/Documentation/devicetree/bindings/timer/altr,timer-1.0.yaml
new file mode 100644
index 000000000000..576260c72d42
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/altr,timer-1.0.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/altr,timer-1.0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera Timer
+
+maintainers:
+ - Dinh Nguyen <dinguyen@kernel.org>
+
+properties:
+ compatible:
+ const: altr,timer-1.0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ description: Frequency of the clock that drives the counter, in Hz.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@400000 {
+ compatible = "altr,timer-1.0";
+ reg = <0x00400000 0x00000020>;
+ interrupts = <11>;
+ clock-frequency = <125000000>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt b/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt
deleted file mode 100644
index a9da22bda912..000000000000
--- a/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Amlogic Meson6 SoCs Timer Controller
-
-Required properties:
-
-- compatible : should be "amlogic,meson6-timer"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : The four interrupts, one for each timer event
-- clocks : phandles to the pclk (system clock) and XTAL clocks
-- clock-names : must contain "pclk" and "xtal"
-
-Example:
-
-timer@c1109940 {
- compatible = "amlogic,meson6-timer";
- reg = <0xc1109940 0x14>;
- interrupts = <GIC_SPI 10 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 11 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>;
- clocks = <&xtal>, <&clk81>;
- clock-names = "xtal", "pclk";
-};
diff --git a/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml b/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml
new file mode 100644
index 000000000000..8381a5404ef7
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/amlogic,meson6-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson6 SoCs Timer Controller
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+properties:
+ compatible:
+ const: amlogic,meson6-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 4
+ description: per-timer event interrupts
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: xtal
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ timer@c1109940 {
+ compatible = "amlogic,meson6-timer";
+ reg = <0xc1109940 0x14>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 11 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&clk81>;
+ clock-names = "xtal", "pclk";
+ };
diff --git a/Documentation/devicetree/bindings/timer/andestech,plmt0.yaml b/Documentation/devicetree/bindings/timer/andestech,plmt0.yaml
new file mode 100644
index 000000000000..90b612096004
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,plmt0.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/andestech,plmt0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes machine-level timer
+
+description:
+ The Andes machine-level timer device (PLMT0) provides machine-level timer
+ functionality for a set of HARTs on a RISC-V platform. It has a single
+ fixed-frequency monotonic time counter (MTIME) register and a time compare
+ register (MTIMECMP) for each HART connected to the PLMT0. A timer interrupt is
+ generated if MTIME >= MTIMECMP.
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - andestech,qilai-plmt
+ - const: andestech,plmt0
+
+ reg:
+ maxItems: 1
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 32
+ description:
+ Specifies which harts are connected to the PLMT0. Each item must points
+ to a riscv,cpu-intc node, which has a riscv cpu node as parent. The
+ PLMT0 supports 1 hart up to 32 harts.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts-extended
+
+examples:
+ - |
+ interrupt-controller@100000 {
+ compatible = "andestech,qilai-plmt", "andestech,plmt0";
+ reg = <0x100000 0x100000>;
+ interrupts-extended = <&cpu0intc 7>,
+ <&cpu1intc 7>,
+ <&cpu2intc 7>,
+ <&cpu3intc 7>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index df8ce87fd54b..c5fc3b6c8bd0 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -22,16 +22,15 @@ properties:
compatible:
oneOf:
- items:
- - enum:
- - arm,cortex-a15-timer
- - enum:
- - arm,armv7-timer
+ - const: arm,cortex-a15-timer
+ - const: arm,armv7-timer
- items:
- enum:
- arm,armv7-timer
- - items:
- - enum:
- arm,armv8-timer
+ - items:
+ - const: arm,armv8-timer
+ - const: arm,armv7-timer
interrupts:
minItems: 1
diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml
index cd2176cad53a..ab8f28993139 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml
@@ -60,12 +60,13 @@ properties:
be implemented in an always-on power domain."
patternProperties:
- '^frame@[0-9a-z]*$':
+ '^frame@[0-9a-f]+$':
type: object
+ additionalProperties: false
description: A timer node has up to 8 frame sub-nodes, each with the following properties.
properties:
frame-number:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
diff --git a/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
deleted file mode 100644
index 48f84d74edde..000000000000
--- a/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-ARM MPS2 timer
-
-The MPS2 platform has simple general-purpose 32 bits timers.
-
-Required properties:
-- compatible : Should be "arm,mps2-timer"
-- reg : Address and length of the register set
-- interrupts : Reference to the timer interrupt
-
-Required clocking property, have to be one of:
-- clocks : The input clock of the timer
-- clock-frequency : The rate in HZ in input of the ARM MPS2 timer
-
-Examples:
-
-timer1: mps2-timer@40000000 {
- compatible = "arm,mps2-timer";
- reg = <0x40000000 0x1000>;
- interrupts = <8>;
- clocks = <&sysclk>;
-};
-
-timer2: mps2-timer@40001000 {
- compatible = "arm,mps2-timer";
- reg = <0x40001000 0x1000>;
- interrupts = <9>;
- clock-frequency = <25000000>;
-};
diff --git a/Documentation/devicetree/bindings/timer/arm,mps2-timer.yaml b/Documentation/devicetree/bindings/timer/arm,mps2-timer.yaml
new file mode 100644
index 000000000000..64c6aedd7e8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,mps2-timer.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm,mps2-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM MPS2 timer
+
+maintainers:
+ - Vladimir Murzin <vladimir.murzin@arm.com>
+
+description:
+ The MPS2 platform has simple general-purpose 32 bits timers.
+
+properties:
+ compatible:
+ const: arm,mps2-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ description: Rate in Hz of the timer input clock
+
+oneOf:
+ - required: [clocks]
+ - required: [clock-frequency]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@40000000 {
+ compatible = "arm,mps2-timer";
+ reg = <0x40000000 0x1000>;
+ interrupts = <8>;
+ clocks = <&sysclk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml
index 5684df6448ef..eb1127352c7b 100644
--- a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml
@@ -50,7 +50,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
timer@2c000600 {
- compatible = "arm,arm11mp-twd-timer";
- reg = <0x2c000600 0x20>;
- interrupts = <GIC_PPI 13 0xf01>;
+ compatible = "arm,arm11mp-twd-timer";
+ reg = <0x2c000600 0x20>;
+ interrupts = <GIC_PPI 13 0xf01>;
};
diff --git a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt
deleted file mode 100644
index 844bd5fbd04c..000000000000
--- a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-BCM2835 System Timer
-
-The System Timer peripheral provides four 32-bit timer channels and a
-single 64-bit free running counter. Each channel has an output compare
-register, which is compared against the 32 least significant bits of the
-free running counter values, and generates an interrupt.
-
-Required properties:
-
-- compatible : should be "brcm,bcm2835-system-timer"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : A list of 4 interrupt sinks; one per timer channel.
-- clock-frequency : The frequency of the clock that drives the counter, in Hz.
-
-Example:
-
-timer {
- compatible = "brcm,bcm2835-system-timer";
- reg = <0x7e003000 0x1000>;
- interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
- clock-frequency = <1000000>;
-};
diff --git a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.yaml b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.yaml
new file mode 100644
index 000000000000..f5804b5b0e63
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/brcm,bcm2835-system-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BCM2835 System Timer
+
+maintainers:
+ - Stefan Wahren <wahrenst@gmx.net>
+ - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
+
+description:
+ The System Timer peripheral provides four 32-bit timer channels and a
+ single 64-bit free running counter. Each channel has an output compare
+ register, which is compared against the 32 least significant bits of the
+ free running counter values, and generates an interrupt.
+
+properties:
+ compatible:
+ const: brcm,bcm2835-system-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: System Timer Compare 0 match (used by VideoCore GPU)
+ - description: System Timer Compare 1 match (usable for ARM core)
+ - description: System Timer Compare 2 match (used by VideoCore GPU)
+ - description: System Timer Compare 3 match (usable for ARM core)
+
+ clock-frequency: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@7e003000 {
+ compatible = "brcm,bcm2835-system-timer";
+ reg = <0x7e003000 0x1000>;
+ interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
+ clock-frequency = <1000000>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml b/Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml
new file mode 100644
index 000000000000..6707d9760857
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/brcm,bcmbca-timer.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/brcm,bcmbca-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Broadband SoC timer
+
+maintainers:
+ - Rafał Miłecki <rafal@milecki.pl>
+
+properties:
+ compatible:
+ oneOf:
+ - const: brcm,bcm6345-timer
+ description: >
+ An old block with 3 timers.
+
+ It can be found in BCM6345, BCM6838 and BCM63268.
+ - const: brcm,bcm63138-timer
+ description: >
+ Updated block with 4 timers and control regs at the beginning.
+
+ It can be found in newer SoCs, e.g. BCM63138, BCM63148, BCM63381,
+ BCM68360, BCM6848, BCM6858, BCM4908.
+
+ reg:
+ maxItems: 1
+
+additionalProperties: false
+
+required:
+ - reg
+
+examples:
+ - |
+ timer@fffe0200 {
+ compatible = "brcm,bcm6345-timer";
+ reg = <0xfffe0200 0x1c>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt b/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt
deleted file mode 100644
index 39adf54b4388..000000000000
--- a/Documentation/devicetree/bindings/timer/brcm,kona-timer.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Broadcom Kona Family timer
------------------------------------------------------
-This timer is used in the following Broadcom SoCs:
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
-
-Required properties:
-- compatible : "brcm,kona-timer"
-- DEPRECATED: compatible : "bcm,kona-timer"
-- reg : Register range for the timer
-- interrupts : interrupt for the timer
-- clocks: phandle + clock specifier pair of the external clock
-- clock-frequency: frequency that the clock operates
-
-Only one of clocks or clock-frequency should be specified.
-
-Refer to clocks/clock-bindings.txt for generic clock consumer properties.
-
-Example:
- timer@35006000 {
- compatible = "brcm,kona-timer";
- reg = <0x35006000 0x1000>;
- interrupts = <0x0 7 0x4>;
- clocks = <&hub_timer_clk>;
- };
-
diff --git a/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml b/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml
new file mode 100644
index 000000000000..d6af8383d6fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/brcm,kona-timer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/brcm,kona-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona family timer
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+
+properties:
+ compatible:
+ const: brcm,kona-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency: true
+
+oneOf:
+ - required:
+ - clocks
+ - required:
+ - clock-frequency
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm281xx.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@35006000 {
+ compatible = "brcm,kona-timer";
+ reg = <0x35006000 0x1000>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&aon_ccu BCM281XX_AON_CCU_HUB_TIMER>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
index 7d821fd480f6..da342464d32e 100644
--- a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
+++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cadence TTC - Triple Timer Counter
maintainers:
- - Michal Simek <michal.simek@xilinx.com>
+ - Michal Simek <michal.simek@amd.com>
properties:
compatible:
@@ -28,16 +28,27 @@ properties:
maxItems: 1
timer-width:
- $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: /schemas/types.yaml#/definitions/uint32
description: |
Bit width of the timer, necessary if not 16.
+ "#pwm-cells":
+ const: 3
+
required:
- compatible
- reg
- - interrupts
- clocks
+allOf:
+ - if:
+ not:
+ required:
+ - "#pwm-cells"
+ then:
+ required:
+ - interrupts
+
additionalProperties: false
examples:
@@ -50,3 +61,12 @@ examples:
clocks = <&cpu_clk 3>;
timer-width = <32>;
};
+
+ - |
+ pwm: pwm@f8002000 {
+ compatible = "cdns,ttc";
+ reg = <0xf8002000 0x1000>;
+ clocks = <&cpu_clk 3>;
+ timer-width = <32>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt b/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt
deleted file mode 100644
index d4c62e7b1714..000000000000
--- a/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Cirrus Logic CLPS711X Timer Counter
-
-Required properties:
-- compatible: Shall contain "cirrus,ep7209-timer".
-- reg : Address and length of the register set.
-- interrupts: The interrupt number of the timer.
-- clocks : phandle of timer reference clock.
-
-Note: Each timer should have an alias correctly numbered in "aliases" node.
-
-Example:
- aliases {
- timer0 = &timer1;
- timer1 = &timer2;
- };
-
- timer1: timer@80000300 {
- compatible = "cirrus,ep7312-timer", "cirrus,ep7209-timer";
- reg = <0x80000300 0x4>;
- interrupts = <8>;
- clocks = <&clks 5>;
- };
-
- timer2: timer@80000340 {
- compatible = "cirrus,ep7312-timer", "cirrus,ep7209-timer";
- reg = <0x80000340 0x4>;
- interrupts = <9>;
- clocks = <&clks 6>;
- };
diff --git a/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.yaml b/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.yaml
new file mode 100644
index 000000000000..507b777e16bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/cirrus,clps711x-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CLPS711X Timer Counter
+
+maintainers:
+ - Alexander Shiyan <shc_work@mail.ru>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - cirrus,ep7312-timer
+ - const: cirrus,ep7209-timer
+ - const: cirrus,ep7209-timer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@80000300 {
+ compatible = "cirrus,ep7312-timer", "cirrus,ep7209-timer";
+ reg = <0x80000300 0x4>;
+ interrupts = <8>;
+ clocks = <&clks 5>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/cirrus,ep9301-timer.yaml b/Documentation/devicetree/bindings/timer/cirrus,ep9301-timer.yaml
new file mode 100644
index 000000000000..e463e11e259d
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/cirrus,ep9301-timer.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/cirrus,ep9301-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP93xx timer
+
+maintainers:
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-timer
+ - items:
+ - enum:
+ - cirrus,ep9302-timer
+ - cirrus,ep9307-timer
+ - cirrus,ep9312-timer
+ - cirrus,ep9315-timer
+ - const: cirrus,ep9301-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@80810000 {
+ compatible = "cirrus,ep9301-timer";
+ reg = <0x80810000 0x100>;
+ interrupt-parent = <&vic1>;
+ interrupts = <19>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/cnxt,cx92755-timer.yaml b/Documentation/devicetree/bindings/timer/cnxt,cx92755-timer.yaml
new file mode 100644
index 000000000000..8f1a5af32a36
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/cnxt,cx92755-timer.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cnxt,cx92755-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Conexant Digicolor SoCs Timer Controller
+
+maintainers:
+ - Baruch Siach <baruch@tkos.co.il>
+
+properties:
+ compatible:
+ const: cnxt,cx92755-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: Contains 8 interrupts, one for each timer
+ items:
+ - description: interrupt for timer 0
+ - description: interrupt for timer 1
+ - description: interrupt for timer 2
+ - description: interrupt for timer 3
+ - description: interrupt for timer 4
+ - description: interrupt for timer 5
+ - description: interrupt for timer 6
+ - description: interrupt for timer 7
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@f0000fc0 {
+ compatible = "cnxt,cx92755-timer";
+ reg = <0xf0000fc0 0x40>;
+ interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
+ clocks = <&main_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
deleted file mode 100644
index 6b04344f4bea..000000000000
--- a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-=================
-gx6605s SOC Timer
-=================
-
-The timer is used in gx6605s soc as system timer and the driver
-contain clk event and clk source.
-
-==============================
-timer node bindings definition
-==============================
-
- Description: Describes gx6605s SOC timer
-
- PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: must be "csky,gx6605s-timer"
- - reg
- Usage: required
- Value type: <u32 u32>
- Definition: <phyaddr size> in soc from cpu view
- - clocks
- Usage: required
- Value type: phandle + clock specifier cells
- Definition: must be input clk node
- - interrupt
- Usage: required
- Value type: <u32>
- Definition: must be timer irq num defined by soc
-
-Examples:
----------
-
- timer0: timer@20a000 {
- compatible = "csky,gx6605s-timer";
- reg = <0x0020a000 0x400>;
- clocks = <&dummy_apb_clk>;
- interrupts = <10>;
- interrupt-parent = <&intc>;
- };
diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.yaml b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.yaml
new file mode 100644
index 000000000000..888fc8113996
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/csky,gx6605s-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: gx6605s SOC Timer
+
+maintainers:
+ - Guo Ren <guoren@kernel.org>
+
+properties:
+ compatible:
+ const: csky,gx6605s-timer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@20a000 {
+ compatible = "csky,gx6605s-timer";
+ reg = <0x0020a000 0x400>;
+ clocks = <&dummy_apb_clk>;
+ interrupts = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/csky,mptimer.txt b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
deleted file mode 100644
index f5c7e99cf52b..000000000000
--- a/Documentation/devicetree/bindings/timer/csky,mptimer.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-============================
-C-SKY Multi-processors Timer
-============================
-
-C-SKY multi-processors timer is designed for C-SKY SMP system and the
-regs is accessed by cpu co-processor 4 registers with mtcr/mfcr.
-
- - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer.
- - PTIM_TSR "cr<1, 14>" Interrupt cleanup status reg.
- - PTIM_CCVR "cr<3, 14>" Current counter value reg.
- - PTIM_LVR "cr<6, 14>" Window value reg to trigger next event.
-
-==============================
-timer node bindings definition
-==============================
-
- Description: Describes SMP timer
-
- PROPERTIES
-
- - compatible
- Usage: required
- Value type: <string>
- Definition: must be "csky,mptimer"
- - clocks
- Usage: required
- Value type: <node>
- Definition: must be input clk node
- - interrupts
- Usage: required
- Value type: <u32>
- Definition: must be timer irq num defined by soc
-
-Examples:
----------
-
- timer: timer {
- compatible = "csky,mptimer";
- clocks = <&dummy_apb_clk>;
- interrupts = <16>;
- interrupt-parent = <&intc>;
- };
diff --git a/Documentation/devicetree/bindings/timer/csky,mptimer.yaml b/Documentation/devicetree/bindings/timer/csky,mptimer.yaml
new file mode 100644
index 000000000000..12cc5282c8f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,mptimer.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/csky,mptimer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: C-SKY Multi-processors Timer
+
+maintainers:
+ - Flavio Suligoi <f.suligoi@asem.it>
+ - Guo Ren <guoren@kernel.org>
+
+description: |
+ C-SKY multi-processors timer is designed for C-SKY SMP system and the regs are
+ accessed by cpu co-processor 4 registers with mtcr/mfcr.
+
+ - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer.
+ - PTIM_TSR "cr<1, 14>" Interrupt cleanup status reg.
+ - PTIM_CCVR "cr<3, 14>" Current counter value reg.
+ - PTIM_LVR "cr<6, 14>" Window value reg to trigger next event.
+
+properties:
+ compatible:
+ items:
+ - const: csky,mptimer
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer {
+ compatible = "csky,mptimer";
+ clocks = <&dummy_apb_clk>;
+ interrupts = <16>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/digicolor-timer.txt b/Documentation/devicetree/bindings/timer/digicolor-timer.txt
deleted file mode 100644
index d1b659bbc29f..000000000000
--- a/Documentation/devicetree/bindings/timer/digicolor-timer.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Conexant Digicolor SoCs Timer Controller
-
-Required properties:
-
-- compatible : should be "cnxt,cx92755-timer"
-- reg : Specifies base physical address and size of the "Agent Communication"
- timer registers
-- interrupts : Contains 8 interrupts, one for each timer
-- clocks: phandle to the main clock
-
-Example:
-
- timer@f0000fc0 {
- compatible = "cnxt,cx92755-timer";
- reg = <0xf0000fc0 0x40>;
- interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
- clocks = <&main_clk>;
- };
diff --git a/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml b/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
new file mode 100644
index 000000000000..c1e7c2b6afde
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/econet,en751221-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet EN751221 High Precision Timer (HPT)
+
+maintainers:
+ - Caleb James DeLisle <cjd@cjdns.fr>
+
+description:
+ The EcoNet High Precision Timer (HPT) is a timer peripheral found in various
+ EcoNet SoCs, including the EN751221 and EN751627 families. It provides per-VPE
+ count/compare registers and a per-CPU control register, with a single interrupt
+ line using a percpu-devid interrupt mechanism.
+
+properties:
+ compatible:
+ oneOf:
+ - const: econet,en751221-timer
+ - items:
+ - const: econet,en751627-timer
+ - const: econet,en751221-timer
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+ description: A percpu-devid timer interrupt shared across CPUs.
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: econet,en751627-timer
+ then:
+ properties:
+ reg:
+ items:
+ - description: VPE timers 0 and 1
+ - description: VPE timers 2 and 3
+ else:
+ properties:
+ reg:
+ items:
+ - description: VPE timers 0 and 1
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@1fbf0400 {
+ compatible = "econet,en751627-timer", "econet,en751221-timer";
+ reg = <0x1fbf0400 0x100>, <0x1fbe0000 0x100>;
+ interrupt-parent = <&intc>;
+ interrupts = <30>;
+ clocks = <&hpt_clock>;
+ };
+ - |
+ timer@1fbf0400 {
+ compatible = "econet,en751221-timer";
+ reg = <0x1fbe0400 0x100>;
+ interrupt-parent = <&intc>;
+ interrupts = <30>;
+ clocks = <&hpt_clock>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.yaml b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.yaml
new file mode 100644
index 000000000000..317c5010c4c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ezchip,nps400-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EZChip NPS400 Timers
+
+maintainers:
+ - Noam Camus <noamca@mellanox.com>
+
+properties:
+ compatible:
+ enum:
+ - ezchip,nps400-timer0
+ - ezchip,nps400-timer1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ezchip,nps400-timer0
+ then:
+ required: [ interrupts ]
+
+examples:
+ - |
+ timer {
+ compatible = "ezchip,nps400-timer0";
+ interrupts = <3>;
+ clocks = <&sysclk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
deleted file mode 100644
index e3cfce8fecc5..000000000000
--- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-NPS Network Processor
-
-Required properties:
-
-- compatible : should be "ezchip,nps400-timer0"
-
-Clocks required for compatible = "ezchip,nps400-timer0":
-- interrupts : The interrupt of the first timer
-- clocks : Must contain a single entry describing the clock input
-
-Example:
-
-timer {
- compatible = "ezchip,nps400-timer0";
- interrupts = <3>;
- clocks = <&sysclk>;
-};
diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
deleted file mode 100644
index c0ab4190b8fb..000000000000
--- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-NPS Network Processor
-
-Required properties:
-
-- compatible : should be "ezchip,nps400-timer1"
-
-Clocks required for compatible = "ezchip,nps400-timer1":
-- clocks : Must contain a single entry describing the clock input
-
-Example:
-
-timer {
- compatible = "ezchip,nps400-timer1";
- clocks = <&sysclk>;
-};
diff --git a/Documentation/devicetree/bindings/timer/faraday,fttmr010.txt b/Documentation/devicetree/bindings/timer/faraday,fttmr010.txt
deleted file mode 100644
index 3cb2f4c98d64..000000000000
--- a/Documentation/devicetree/bindings/timer/faraday,fttmr010.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Faraday Technology timer
-
-This timer is a generic IP block from Faraday Technology, embedded in the
-Cortina Systems Gemini SoCs and other designs.
-
-Required properties:
-
-- compatible : Must be one of
- "faraday,fttmr010"
- "cortina,gemini-timer", "faraday,fttmr010"
- "moxa,moxart-timer", "faraday,fttmr010"
- "aspeed,ast2400-timer"
- "aspeed,ast2500-timer"
- "aspeed,ast2600-timer"
-
-- reg : Should contain registers location and length
-- interrupts : Should contain the three timer interrupts usually with
- flags for falling edge
-
-Optionally required properties:
-
-- clocks : a clock to provide the tick rate for "faraday,fttmr010"
-- clock-names : should be "EXTCLK" and "PCLK" for the external tick timer
- and peripheral clock respectively, for "faraday,fttmr010"
-- syscon : a phandle to the global Gemini system controller if the compatible
- type is "cortina,gemini-timer"
-
-Example:
-
-timer@43000000 {
- compatible = "faraday,fttmr010";
- reg = <0x43000000 0x1000>;
- interrupts = <14 IRQ_TYPE_EDGE_FALLING>, /* Timer 1 */
- <15 IRQ_TYPE_EDGE_FALLING>, /* Timer 2 */
- <16 IRQ_TYPE_EDGE_FALLING>; /* Timer 3 */
- clocks = <&extclk>, <&pclk>;
- clock-names = "EXTCLK", "PCLK";
-};
diff --git a/Documentation/devicetree/bindings/timer/faraday,fttmr010.yaml b/Documentation/devicetree/bindings/timer/faraday,fttmr010.yaml
new file mode 100644
index 000000000000..39506323556c
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/faraday,fttmr010.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/faraday,fttmr010.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday FTTMR010 timer
+
+maintainers:
+ - Joel Stanley <joel@jms.id.au>
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description:
+ This timer is a generic IP block from Faraday Technology, embedded in the
+ Cortina Systems Gemini SoCs and other designs.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: moxa,moxart-timer
+ - const: faraday,fttmr010
+ - enum:
+ - aspeed,ast2400-timer
+ - aspeed,ast2500-timer
+ - aspeed,ast2600-timer
+ - cortina,gemini-timer
+ - faraday,fttmr010
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 8
+ description: One interrupt per timer
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Peripheral clock
+ - description: External tick clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: PCLK
+ - const: EXTCLK
+
+ resets:
+ maxItems: 1
+
+ syscon:
+ description: System controller phandle for Gemini systems
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: cortina,gemini-timer
+ then:
+ required:
+ - syscon
+ else:
+ properties:
+ syscon: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@43000000 {
+ compatible = "faraday,fttmr010";
+ reg = <0x43000000 0x1000>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>, /* Timer 1 */
+ <15 IRQ_TYPE_EDGE_FALLING>, /* Timer 2 */
+ <16 IRQ_TYPE_EDGE_FALLING>; /* Timer 3 */
+ clocks = <&pclk>, <&extclk>;
+ clock-names = "PCLK", "EXTCLK";
+ };
diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
deleted file mode 100644
index aa8c40230e5e..000000000000
--- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Freescale FlexTimer Module (FTM) Timer
-
-Required properties:
-
-- compatible : should be "fsl,ftm-timer"
-- reg : Specifies base physical address and size of the register sets for the
- clock event device and clock source device.
-- interrupts : Should be the clock event device interrupt.
-- clocks : The clocks provided by the SoC to drive the timer, must contain an
- entry for each entry in clock-names.
-- clock-names : Must include the following entries:
- o "ftm-evt"
- o "ftm-src"
- o "ftm-evt-counter-en"
- o "ftm-src-counter-en"
-- big-endian: One boolean property, the big endian mode will be in use if it is
- present, or the little endian mode will be in use for all the device registers.
-
-Example:
-ftm: ftm@400b8000 {
- compatible = "fsl,ftm-timer";
- reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
- interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "ftm-evt", "ftm-src",
- "ftm-evt-counter-en", "ftm-src-counter-en";
- clocks = <&clks VF610_CLK_FTM2>,
- <&clks VF610_CLK_FTM3>,
- <&clks VF610_CLK_FTM2_EXT_FIX_EN>,
- <&clks VF610_CLK_FTM3_EXT_FIX_EN>;
- big-endian;
-};
diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.yaml b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.yaml
new file mode 100644
index 000000000000..e3b61b62521e
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/fsl,ftm-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale FlexTimer Module (FTM) Timer
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: fsl,ftm-timer
+
+ reg:
+ items:
+ - description: clock event device
+ - description: clock source device
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description: The clocks provided by the SoC to drive the timer, must
+ contain an entry for each entry in clock-names.
+ minItems: 4
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: ftm-evt
+ - const: ftm-src
+ - const: ftm-evt-counter-en
+ - const: ftm-src-counter-en
+
+ big-endian: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/vf610-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ ftm@400b8000 {
+ compatible = "fsl,ftm-timer";
+ reg = <0x400b8000 0x1000>,
+ <0x400b9000 0x1000>;
+ interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "ftm-evt", "ftm-src", "ftm-evt-counter-en", "ftm-src-counter-en";
+ clocks = <&clks VF610_CLK_FTM2>, <&clks VF610_CLK_FTM3>,
+ <&clks VF610_CLK_FTM2_EXT_FIX_EN>, <&clks VF610_CLK_FTM3_EXT_FIX_EN>;
+ big-endian;
+ };
diff --git a/Documentation/devicetree/bindings/timer/fsl,gtm.txt b/Documentation/devicetree/bindings/timer/fsl,gtm.txt
deleted file mode 100644
index fc1c571f7412..000000000000
--- a/Documentation/devicetree/bindings/timer/fsl,gtm.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Freescale General-purpose Timers Module
-
-Required properties:
- - compatible : should be
- "fsl,<chip>-gtm", "fsl,gtm" for SOC GTMs
- "fsl,<chip>-qe-gtm", "fsl,qe-gtm", "fsl,gtm" for QE GTMs
- "fsl,<chip>-cpm2-gtm", "fsl,cpm2-gtm", "fsl,gtm" for CPM2 GTMs
- - reg : should contain gtm registers location and length (0x40).
- - interrupts : should contain four interrupts.
- - clock-frequency : specifies the frequency driving the timer.
-
-Example:
-
-timer@500 {
- compatible = "fsl,mpc8360-gtm", "fsl,gtm";
- reg = <0x500 0x40>;
- interrupts = <90 8 78 8 84 8 72 8>;
- interrupt-parent = <&ipic>;
- /* filled by u-boot */
- clock-frequency = <0>;
-};
-
-timer@440 {
- compatible = "fsl,mpc8360-qe-gtm", "fsl,qe-gtm", "fsl,gtm";
- reg = <0x440 0x40>;
- interrupts = <12 13 14 15>;
- interrupt-parent = <&qeic>;
- /* filled by u-boot */
- clock-frequency = <0>;
-};
diff --git a/Documentation/devicetree/bindings/timer/fsl,gtm.yaml b/Documentation/devicetree/bindings/timer/fsl,gtm.yaml
new file mode 100644
index 000000000000..1f35f1ee0be2
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,gtm.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/fsl,gtm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale General-purpose Timers Module
+
+maintainers:
+ - J. Neuschäfer <j.ne@posteo.net>
+
+properties:
+ compatible:
+ oneOf:
+ # for SoC GTMs
+ - items:
+ - enum:
+ - fsl,mpc8308-gtm
+ - fsl,mpc8313-gtm
+ - fsl,mpc8315-gtm
+ - fsl,mpc8360-gtm
+ - const: fsl,gtm
+
+ # for QE GTMs
+ - items:
+ - enum:
+ - fsl,mpc8360-qe-gtm
+ - fsl,mpc8569-qe-gtm
+ - const: fsl,qe-gtm
+ - const: fsl,gtm
+
+ # for CPM2 GTMs (no known examples)
+ - items:
+ # - enum:
+ # - fsl,<chip>-cpm2-gtm
+ - const: fsl,cpm2-gtm
+ - const: fsl,gtm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Interrupt for timer 1 (e.g. GTM1 or GTM5)
+ - description: Interrupt for timer 2 (e.g. GTM2 or GTM6)
+ - description: Interrupt for timer 3 (e.g. GTM3 or GTM7)
+ - description: Interrupt for timer 4 (e.g. GTM4 or GTM8)
+
+ clock-frequency: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clock-frequency
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@500 {
+ compatible = "fsl,mpc8360-gtm", "fsl,gtm";
+ reg = <0x500 0x40>;
+ interrupts = <90 IRQ_TYPE_LEVEL_LOW>,
+ <78 IRQ_TYPE_LEVEL_LOW>,
+ <84 IRQ_TYPE_LEVEL_LOW>,
+ <72 IRQ_TYPE_LEVEL_LOW>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+ };
+
+ - |
+ timer@440 {
+ compatible = "fsl,mpc8360-qe-gtm", "fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ interrupts = <12>, <13>, <14>, <15>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
index a4f51f46b7a1..9898dc7ea97b 100644
--- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
@@ -21,6 +21,7 @@ properties:
- items:
- enum:
- fsl,imx25-gpt
+ - fsl,imx35-gpt
- fsl,imx50-gpt
- fsl,imx51-gpt
- fsl,imx53-gpt
@@ -31,7 +32,15 @@ properties:
- enum:
- fsl,imx6sl-gpt
- fsl,imx6sx-gpt
+ - fsl,imx7d-gpt
+ - fsl,imx8mp-gpt
+ - fsl,imxrt1050-gpt
+ - fsl,imxrt1170-gpt
- const: fsl,imx6dl-gpt
+ - items:
+ - enum:
+ - fsl,imx6ul-gpt
+ - const: fsl,imx6sx-gpt
reg:
maxItems: 1
@@ -40,14 +49,18 @@ properties:
maxItems: 1
clocks:
+ minItems: 2
items:
- description: SoC GPT ipg clock
- description: SoC GPT per clock
+ - description: SoC GPT osc per clock
clock-names:
+ minItems: 2
items:
- const: ipg
- const: per
+ - const: osc_per
required:
- compatible
@@ -56,6 +69,29 @@ required:
- clocks
- clock-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx6dl-gpt
+ - fsl,imx6q-gpt
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 3
+ clock-names:
+ minItems: 2
+ maxItems: 3
+ else:
+ properties:
+ clocks:
+ maxItems: 2
+ clock-names:
+ maxItems: 2
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/timer/fsl,timrot.yaml b/Documentation/devicetree/bindings/timer/fsl,timrot.yaml
new file mode 100644
index 000000000000..d181f274ef9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,timrot.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/fsl,timrot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS Timer
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - fsl,imx23-timrot
+ - fsl,imx28-timrot
+ - const: fsl,timrot
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: irq for timer0
+ - description: irq for timer1
+ - description: irq for timer2
+ - description: irq for timer3
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer: timer@80068000 {
+ compatible = "fsl,imx28-timrot", "fsl,timrot";
+ reg = <0x80068000 0x2000>;
+ interrupts = <48>, <49>, <50>, <51>;
+ clocks = <&clks 26>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
new file mode 100644
index 000000000000..42e130654d58
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,vf610-pit.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/fsl,vf610-pit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Periodic Interrupt Timer (PIT)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The PIT module is an array of timers that can be used to raise interrupts
+ and trigger DMA channels.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,vf610-pit
+ - nxp,s32g2-pit
+ - items:
+ - const: nxp,s32g3-pit
+ - const: nxp,s32g2-pit
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: pit
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/vf610-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@40037000 {
+ compatible = "fsl,vf610-pit";
+ reg = <0x40037000 0x1000>;
+ interrupts = <39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_PIT>;
+ clock-names = "pit";
+ };
diff --git a/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
deleted file mode 100644
index 7afce80bf6a0..000000000000
--- a/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Pistachio general-purpose timer based clocksource
-
-Required properties:
- - compatible: "img,pistachio-gptimer".
- - reg: Address range of the timer registers.
- - interrupts: An interrupt for each of the four timers
- - clocks: Should contain a clock specifier for each entry in clock-names
- - clock-names: Should contain the following entries:
- "sys", interface clock
- "slow", slow counter clock
- "fast", fast counter clock
- - img,cr-periph: Must contain a phandle to the peripheral control
- syscon node.
-
-Example:
- timer: timer@18102000 {
- compatible = "img,pistachio-gptimer";
- reg = <0x18102000 0x100>;
- interrupts = <GIC_SHARED 60 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SHARED 61 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SHARED 62 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SHARED 63 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk_periph PERIPH_CLK_COUNTER_FAST>,
- <&clk_periph PERIPH_CLK_COUNTER_SLOW>,
- <&cr_periph SYS_CLK_TIMER>;
- clock-names = "fast", "slow", "sys";
- img,cr-periph = <&cr_periph>;
- };
diff --git a/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.yaml b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.yaml
new file mode 100644
index 000000000000..a8654bcf68a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/img,pistachio-gptimer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Pistachio general-purpose timer
+
+maintainers:
+ - Ezequiel Garcia <ezequiel.garcia@imgtec.com>
+
+properties:
+ compatible:
+ const: img,pistachio-gptimer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Timer0 interrupt
+ - description: Timer1 interrupt
+ - description: Timer2 interrupt
+ - description: Timer3 interrupt
+
+ clocks:
+ items:
+ - description: Fast counter clock
+ - description: Slow counter clock
+ - description: Interface clock
+
+ clock-names:
+ items:
+ - const: fast
+ - const: slow
+ - const: sys
+
+ img,cr-periph:
+ description: Peripheral control syscon phandle
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - img,cr-periph
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/mips-gic.h>
+ #include <dt-bindings/clock/pistachio-clk.h>
+
+ timer@18102000 {
+ compatible = "img,pistachio-gptimer";
+ reg = <0x18102000 0x100>;
+ interrupts = <GIC_SHARED 60 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 61 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 62 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SHARED 63 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_periph PERIPH_CLK_COUNTER_FAST>,
+ <&clk_periph PERIPH_CLK_COUNTER_SLOW>,
+ <&cr_periph SYS_CLK_TIMER>;
+ clock-names = "fast", "slow", "sys";
+ img,cr-periph = <&cr_periph>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
index 98648bf9e151..bdc82d8bce0e 100644
--- a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
+++ b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/ingenic,sysost.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for SYSOST in Ingenic XBurst family SoCs
+title: SYSOST in Ingenic XBurst family SoCs
maintainers:
- 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
index 0a01e4f5eddb..585b5f5217c4 100644
--- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
+++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml
@@ -4,11 +4,11 @@
$id: http://devicetree.org/schemas/timer/ingenic,tcu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic SoCs Timer/Counter Unit (TCU) devicetree bindings
+title: Ingenic SoCs Timer/Counter Unit (TCU)
description: |
For a description of the TCU hardware and drivers, have a look at
- Documentation/mips/ingenic-tcu.rst.
+ Documentation/arch/mips/ingenic-tcu.rst.
maintainers:
- Paul Cercueil <paul@crapouillou.net>
@@ -114,6 +114,8 @@ patternProperties:
"^watchdog@[a-f0-9]+$":
type: object
$ref: /schemas/watchdog/watchdog.yaml#
+ unevaluatedProperties: false
+
properties:
compatible:
oneOf:
@@ -146,6 +148,8 @@ patternProperties:
"^pwm@[a-f0-9]+$":
type: object
$ref: /schemas/pwm/pwm.yaml#
+ unevaluatedProperties: false
+
properties:
compatible:
oneOf:
diff --git a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml
index f32575d4b5aa..526b8db4d575 100644
--- a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml
@@ -2,8 +2,8 @@
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/timer/intel,ixp4xx-timer.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/timer/intel,ixp4xx-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx XScale Networking Processors Timers
diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt b/Documentation/devicetree/bindings/timer/jcore,pit.txt
deleted file mode 100644
index af5dd35469d7..000000000000
--- a/Documentation/devicetree/bindings/timer/jcore,pit.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-J-Core Programmable Interval Timer and Clocksource
-
-Required properties:
-
-- compatible: Must be "jcore,pit".
-
-- reg: Memory region(s) for timer/clocksource registers. For SMP,
- there should be one region per cpu, indexed by the sequential,
- zero-based hardware cpu number.
-
-- interrupts: An interrupt to assign for the timer. The actual pit
- core is integrated with the aic and allows the timer interrupt
- assignment to be programmed by software, but this property is
- required in order to reserve an interrupt number that doesn't
- conflict with other devices.
-
-
-Example:
-
-timer@200 {
- compatible = "jcore,pit";
- reg = < 0x200 0x30 0x500 0x30 >;
- interrupts = < 0x48 >;
-};
diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.yaml b/Documentation/devicetree/bindings/timer/jcore,pit.yaml
new file mode 100644
index 000000000000..9e6e25b75293
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/jcore,pit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: J-Core Programmable Interval Timer and Clocksource
+
+maintainers:
+ - Rich Felker <dalias@libc.org>
+
+properties:
+ compatible:
+ const: jcore,pit
+
+ reg:
+ description:
+ Memory region(s) for timer/clocksource registers. For SMP, there should be
+ one region per cpu, indexed by the sequential, zero-based hardware cpu
+ number.
+
+ interrupts:
+ description:
+ An interrupt to assign for the timer. The actual pit core is integrated
+ with the aic and allows the timer interrupt assignment to be programmed by
+ software, but this property is required in order to reserve an interrupt
+ number that doesn't conflict with other devices.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@200 {
+ compatible = "jcore,pit";
+ reg = <0x200 0x30 0x500 0x30>;
+ interrupts = <0x48>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml b/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml
new file mode 100644
index 000000000000..ad61ae55850b
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/loongson,ls1x-pwmtimer.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/loongson,ls1x-pwmtimer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 PWM timer
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+description:
+ Loongson-1 PWM timer can be used for system clock source
+ and clock event timers.
+
+properties:
+ compatible:
+ const: loongson,ls1b-pwmtimer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls1x-clk.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ clocksource: timer@1fe5c030 {
+ compatible = "loongson,ls1b-pwmtimer";
+ reg = <0x1fe5c030 0x10>;
+
+ clocks = <&clkc LS1X_CLKID_APB>;
+ interrupt-parent = <&intc0>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt
deleted file mode 100644
index b2d07ad90e9a..000000000000
--- a/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-TI-NSPIRE timer
-
-Required properties:
-
-- compatible : should be "lsi,zevio-timer".
-- reg : The physical base address and size of the timer (always first).
-- clocks: phandle to the source clock.
-
-Optional properties:
-
-- interrupts : The interrupt number of the first timer.
-- reg : The interrupt acknowledgement registers
- (always after timer base address)
-
-If any of the optional properties are not given, the timer is added as a
-clock-source only.
-
-Example:
-
-timer {
- compatible = "lsi,zevio-timer";
- reg = <0x900D0000 0x1000>, <0x900A0020 0x8>;
- interrupts = <19>;
- clocks = <&timer_clk>;
-};
-
-Example (no clock-events):
-
-timer {
- compatible = "lsi,zevio-timer";
- reg = <0x900D0000 0x1000>;
- clocks = <&timer_clk>;
-};
diff --git a/Documentation/devicetree/bindings/timer/lsi,zevio-timer.yaml b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.yaml
new file mode 100644
index 000000000000..358455d8e7a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/lsi,zevio-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-NSPIRE timer
+
+maintainers:
+ - Daniel Tang <dt.tangr@gmail.com>
+
+properties:
+ compatible:
+ const: lsi,zevio-timer
+
+ reg:
+ minItems: 1
+ items:
+ - description: Timer registers
+ - description: Interrupt acknowledgement registers (optional)
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ required: [ interrupts ]
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@900d0000 {
+ compatible = "lsi,zevio-timer";
+ reg = <0x900D0000 0x1000>, <0x900A0020 0x8>;
+ interrupts = <19>;
+ clocks = <&timer_clk>;
+ };
+ - |
+ timer@900d0000 {
+ compatible = "lsi,zevio-timer";
+ reg = <0x900D0000 0x1000>;
+ clocks = <&timer_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-timer.yaml b/Documentation/devicetree/bindings/timer/marvell,armada-370-timer.yaml
new file mode 100644
index 000000000000..bc0677fe86eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-timer.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/marvell,armada-370-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 370, 375, 380 and XP Timers
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: marvell,armada-380-timer
+ - const: marvell,armada-xp-timer
+ - items:
+ - const: marvell,armada-375-timer
+ - const: marvell,armada-370-timer
+ - enum:
+ - marvell,armada-370-timer
+ - marvell,armada-xp-timer
+
+ reg:
+ items:
+ - description: Global timer registers
+ - description: Local/private timer registers
+
+ interrupts:
+ items:
+ - description: Global timer interrupt 0
+ - description: Global timer interrupt 1
+ - description: Global timer interrupt 2
+ - description: Global timer interrupt 3
+ - description: First private timer interrupt
+ - description: Second private timer interrupt
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: nbclk
+ - const: fixed
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,armada-375-timer
+ - marvell,armada-xp-timer
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ required:
+ - clock-names
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
+examples:
+ - |
+ timer@20300 {
+ compatible = "marvell,armada-xp-timer";
+ reg = <0x20300 0x30>, <0x21040 0x30>;
+ interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
+ clocks = <&coreclk 2>, <&refclk>;
+ clock-names = "nbclk", "fixed";
+ };
diff --git a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
deleted file mode 100644
index e9c78ce880e6..000000000000
--- a/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Marvell Armada 370 and Armada XP Timers
----------------------------------------
-
-Required properties:
-- compatible: Should be one of the following
- "marvell,armada-370-timer",
- "marvell,armada-375-timer",
- "marvell,armada-xp-timer".
-- interrupts: Should contain the list of Global Timer interrupts and
- then local timer interrupts
-- reg: Should contain location and length for timers register. First
- pair for the Global Timer registers, second pair for the
- local/private timers.
-
-Clocks required for compatible = "marvell,armada-370-timer":
-- clocks : Must contain a single entry describing the clock input
-
-Clocks required for compatibles = "marvell,armada-xp-timer",
- "marvell,armada-375-timer":
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names : Must include the following entries:
- "nbclk" (L2/coherency fabric clock),
- "fixed" (Reference 25 MHz fixed-clock).
-
-Examples:
-
-- Armada 370:
-
- timer {
- compatible = "marvell,armada-370-timer";
- reg = <0x20300 0x30>, <0x21040 0x30>;
- interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
- clocks = <&coreclk 2>;
- };
-
-- Armada XP:
-
- timer {
- compatible = "marvell,armada-xp-timer";
- reg = <0x20300 0x30>, <0x21040 0x30>;
- interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
- clocks = <&coreclk 2>, <&refclk>;
- clock-names = "nbclk", "fixed";
- };
diff --git a/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
deleted file mode 100644
index cd1a0c256f94..000000000000
--- a/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Marvell Orion SoC timer
-
-Required properties:
-- compatible: shall be "marvell,orion-timer"
-- reg: base address of the timer register starting with TIMERS CONTROL register
-- interrupts: should contain the interrupts for Timer0 and Timer1
-- clocks: phandle of timer reference clock (tclk)
-
-Example:
- timer: timer {
- compatible = "marvell,orion-timer";
- reg = <0x20300 0x20>;
- interrupt-parent = <&bridge_intc>;
- interrupts = <1>, <2>;
- clocks = <&core_clk 0>;
- };
diff --git a/Documentation/devicetree/bindings/timer/marvell,orion-timer.yaml b/Documentation/devicetree/bindings/timer/marvell,orion-timer.yaml
new file mode 100644
index 000000000000..f973afffa5ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,orion-timer.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/marvell,orion-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Orion SoC timer
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ const: marvell,orion-timer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Timer0 interrupt
+ - description: Timer1 interrupt
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@20300 {
+ compatible = "marvell,orion-timer";
+ reg = <0x20300 0x20>;
+ interrupts = <1>, <2>;
+ clocks = <&core_clk 0>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
deleted file mode 100644
index f1c848af91d3..000000000000
--- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-MediaTek Timers
----------------
-
-MediaTek SoCs have different timers on different platforms,
-- CPUX (ARM/ARM64 System Timer)
-- GPT (General Purpose Timer)
-- SYST (System Timer)
-
-The proper timer will be selected automatically by driver.
-
-Required properties:
-- compatible should contain:
- For those SoCs that use GPT
- * "mediatek,mt2701-timer" for MT2701 compatible timers (GPT)
- * "mediatek,mt6580-timer" for MT6580 compatible timers (GPT)
- * "mediatek,mt6582-timer" for MT6582 compatible timers (GPT)
- * "mediatek,mt6589-timer" for MT6589 compatible timers (GPT)
- * "mediatek,mt7623-timer" for MT7623 compatible timers (GPT)
- * "mediatek,mt8127-timer" for MT8127 compatible timers (GPT)
- * "mediatek,mt8135-timer" for MT8135 compatible timers (GPT)
- * "mediatek,mt8173-timer" for MT8173 compatible timers (GPT)
- * "mediatek,mt8516-timer" for MT8516 compatible timers (GPT)
- * "mediatek,mt6577-timer" for MT6577 and all above compatible timers (GPT)
-
- For those SoCs that use SYST
- * "mediatek,mt8183-timer" for MT8183 compatible timers (SYST)
- * "mediatek,mt8186-timer" for MT8186 compatible timers (SYST)
- * "mediatek,mt8192-timer" for MT8192 compatible timers (SYST)
- * "mediatek,mt8195-timer" for MT8195 compatible timers (SYST)
- * "mediatek,mt7629-timer" for MT7629 compatible timers (SYST)
- * "mediatek,mt6765-timer" for MT6765 and all above compatible timers (SYST)
-
- For those SoCs that use CPUX
- * "mediatek,mt6795-systimer" for MT6795 compatible timers (CPUX)
-
-- reg: Should contain location and length for timer register.
-- clocks: Should contain system clock.
-
-Examples:
-
- timer@10008000 {
- compatible = "mediatek,mt6577-timer";
- reg = <0x10008000 0x80>;
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&system_clk>;
- };
diff --git a/Documentation/devicetree/bindings/timer/mediatek,timer.yaml b/Documentation/devicetree/bindings/timer/mediatek,timer.yaml
new file mode 100644
index 000000000000..337580dc77d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/mediatek,timer.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/mediatek,timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SoC timers
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description:
+ MediaTek SoCs have different timers on different platforms,
+ CPUX (ARM/ARM64 System Timer), GPT (General Purpose Timer)
+ and SYST (System Timer).
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mt6577-timer
+ - mediatek,mt6765-timer
+ - mediatek,mt6795-systimer
+ # GPT Timers
+ - items:
+ - enum:
+ - mediatek,mt2701-timer
+ - mediatek,mt6572-timer
+ - mediatek,mt6580-timer
+ - mediatek,mt6582-timer
+ - mediatek,mt6589-timer
+ - mediatek,mt6795-timer
+ - mediatek,mt7623-timer
+ - mediatek,mt8127-timer
+ - mediatek,mt8135-timer
+ - mediatek,mt8173-timer
+ - mediatek,mt8516-timer
+ - const: mediatek,mt6577-timer
+ # SYST Timers
+ - items:
+ - enum:
+ - mediatek,mt7629-timer
+ - mediatek,mt8183-timer
+ - mediatek,mt8186-timer
+ - mediatek,mt8188-timer
+ - mediatek,mt8192-timer
+ - mediatek,mt8195-timer
+ - mediatek,mt8196-timer
+ - mediatek,mt8365-systimer
+ - const: mediatek,mt6765-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Timer clock
+ - description: RTC or bus clock
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ timer@10008000 {
+ compatible = "mediatek,mt6577-timer";
+ reg = <0x10008000 0x80>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&system_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml
index 1fbc260a0cbd..fe6bc4173789 100644
--- a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml
@@ -4,12 +4,12 @@
$id: http://devicetree.org/schemas/timer/mrvl,mmp-timer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell MMP Timer bindings
+title: Marvell MMP Timer
maintainers:
- Daniel Lezcano <daniel.lezcano@linaro.org>
- Thomas Gleixner <tglx@linutronix.de>
- - Rob Herring <robh+dt@kernel.org>
+ - Rob Herring <robh@kernel.org>
properties:
$nodename:
diff --git a/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml b/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml
index 03d5dba5d5b3..f118ca423e38 100644
--- a/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/mstar,msc313e-timer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mstar MSC313e Timer Device Tree Bindings
+title: Mstar MSC313e Timer
maintainers:
- Daniel Palmer <daniel@0x0f.com>
diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml
index 737af78ad70c..d53e1bb98b8a 100644
--- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml
@@ -25,7 +25,13 @@ properties:
- description: The timer interrupt of timer 0
clocks:
- maxItems: 1
+ items:
+ - description: The reference clock for timer 0
+ - description: The reference clock for timer 1
+ - description: The reference clock for timer 2
+ - description: The reference clock for timer 3
+ - description: The reference clock for timer 4
+ minItems: 1
required:
- compatible
diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml
index b78209cd0f28..adf208b7a5b9 100644
--- a/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra timer
@@ -100,7 +100,6 @@ properties:
items:
- const: timer
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml
index db8b5595540f..1d0bd36907ed 100644
--- a/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/timer/nvidia,tegra186-timer.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/timer/nvidia,tegra186-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra186 timer
@@ -15,7 +15,6 @@ description: >
reference generated by USEC, TSC or either clk_m or OSC. Each TMR can be
programmed to generate one-shot, periodic, or watchdog interrupts.
-
properties:
compatible:
oneOf:
diff --git a/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt b/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt
deleted file mode 100644
index 51b05a0e70d1..000000000000
--- a/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* NXP LPC3220 timer
-
-The NXP LPC3220 timer is used on a wide range of NXP SoCs. This
-includes LPC32xx, LPC178x, LPC18xx and LPC43xx parts.
-
-Required properties:
-- compatible:
- Should be "nxp,lpc3220-timer".
-- reg:
- Address and length of the register set.
-- interrupts:
- Reference to the timer interrupt
-- clocks:
- Should contain a reference to timer clock.
-- clock-names:
- Should contain "timerclk".
-
-Example:
-
-timer1: timer@40085000 {
- compatible = "nxp,lpc3220-timer";
- reg = <0x40085000 0x1000>;
- interrupts = <13>;
- clocks = <&ccu1 CLK_CPU_TIMER1>;
- clock-names = "timerclk";
-};
diff --git a/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.yaml
new file mode 100644
index 000000000000..3ae2eb0625da
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/nxp,lpc3220-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC3220 timer
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+description: |
+ The NXP LPC3220 timer is used on a wide range of NXP SoCs. This includes
+ LPC32xx, LPC178x, LPC18xx and LPC43xx parts.
+
+properties:
+ compatible:
+ const: nxp,lpc3220-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: timerclk
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc32xx-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@4004c000 {
+ compatible = "nxp,lpc3220-timer";
+ reg = <0x4004c000 0x1000>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk LPC32XX_CLK_TIMER1>;
+ clock-names = "timerclk";
+ };
diff --git a/Documentation/devicetree/bindings/timer/nxp,s32g2-stm.yaml b/Documentation/devicetree/bindings/timer/nxp,s32g2-stm.yaml
new file mode 100644
index 000000000000..b44b9794bb85
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,s32g2-stm.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/nxp,s32g2-stm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP System Timer Module (STM)
+
+maintainers:
+ - Daniel Lezcano <daniel.lezcano@kernel.org>
+
+description:
+ The System Timer Module supports commonly required system and application
+ software timing functions. STM includes a 32-bit count-up timer and four
+ 32-bit compare channels with a separate interrupt source for each channel.
+ The timer is driven by the STM module clock divided by an 8-bit prescale
+ value.
+
+properties:
+ compatible:
+ oneOf:
+ - const: nxp,s32g2-stm
+ - items:
+ - const: nxp,s32g3-stm
+ - const: nxp,s32g2-stm
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Counter clock
+ - description: Module clock
+ - description: Register clock
+
+ clock-names:
+ items:
+ - const: counter
+ - const: module
+ - const: register
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ timer@4011c000 {
+ compatible = "nxp,s32g2-stm";
+ reg = <0x4011c000 0x3000>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks 0x3b>, <&clks 0x3c>, <&clks 0x3c>;
+ clock-names = "counter", "module", "register";
+ };
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
index 830211c55b4a..6b80b060672e 100644
--- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
@@ -18,7 +18,14 @@ description: |
properties:
compatible:
- const: nxp,sysctr-timer
+ oneOf:
+ - enum:
+ - nxp,imx95-sysctr-timer
+ - nxp,sysctr-timer
+ - items:
+ - enum:
+ - nxp,imx94-sysctr-timer
+ - const: nxp,imx95-sysctr-timer
reg:
maxItems: 1
@@ -32,6 +39,10 @@ properties:
clock-names:
const: per
+ nxp,no-divider:
+ description: if present, means there is no internal base clk divider.
+ type: boolean
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt b/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt
deleted file mode 100644
index d191612539e8..000000000000
--- a/Documentation/devicetree/bindings/timer/oxsemi,rps-timer.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Oxford Semiconductor OXNAS SoCs Family RPS Timer
-================================================
-
-Required properties:
-- compatible: Should be "oxsemi,ox810se-rps-timer" or "oxsemi,ox820-rps-timer"
-- reg : Specifies base physical address and size of the registers.
-- interrupts : The interrupts of the two timers
-- clocks : The phandle of the timer clock source
-
-example:
-
-timer0: timer@200 {
- compatible = "oxsemi,ox810se-rps-timer";
- reg = <0x200 0x40>;
- clocks = <&rpsclk>;
- interrupts = <4 5>;
-};
diff --git a/Documentation/devicetree/bindings/timer/qcom,msm-timer.txt b/Documentation/devicetree/bindings/timer/qcom,msm-timer.txt
deleted file mode 100644
index 5e10c345548f..000000000000
--- a/Documentation/devicetree/bindings/timer/qcom,msm-timer.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* MSM Timer
-
-Properties:
-
-- compatible : Should at least contain "qcom,msm-timer". More specific
- properties specify which subsystem the timers are paired with.
-
- "qcom,kpss-timer" - krait subsystem
- "qcom,scss-timer" - scorpion subsystem
-
-- interrupts : Interrupts for the debug timer, the first general purpose
- timer, and optionally a second general purpose timer, and
- optionally as well, 2 watchdog interrupts, in that order.
-
-- reg : Specifies the base address of the timer registers.
-
-- clocks: Reference to the parent clocks, one per output clock. The parents
- must appear in the same order as the clock names.
-
-- clock-names: The name of the clocks as free-form strings. They should be in
- the same order as the clocks.
-
-- clock-frequency : The frequency of the debug timer and the general purpose
- timer(s) in Hz in that order.
-
-Optional:
-
-- cpu-offset : per-cpu offset used when the timer is accessed without the
- CPU remapping facilities. The offset is
- cpu-offset + (0x10000 * cpu-nr).
-
-Example:
-
- timer@200a000 {
- compatible = "qcom,scss-timer", "qcom,msm-timer";
- interrupts = <1 1 0x301>,
- <1 2 0x301>,
- <1 3 0x301>,
- <1 4 0x301>,
- <1 5 0x301>;
- reg = <0x0200a000 0x100>;
- clock-frequency = <19200000>,
- <32768>;
- clocks = <&sleep_clk>;
- clock-names = "sleep";
- cpu-offset = <0x40000>;
- };
diff --git a/Documentation/devicetree/bindings/timer/ralink,cevt-systick.yaml b/Documentation/devicetree/bindings/timer/ralink,cevt-systick.yaml
new file mode 100644
index 000000000000..59d97feddf4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ralink,cevt-systick.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/ralink,cevt-systick.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System tick counter present in Ralink family SoCs
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+properties:
+ compatible:
+ const: ralink,cevt-systick
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ systick@d00 {
+ compatible = "ralink,cevt-systick";
+ reg = <0xd00 0x10>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <7>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml b/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml
new file mode 100644
index 000000000000..daa7832babe3
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ralink,rt2880-timer.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/ralink,rt2880-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Timer present in Ralink family SoCs
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+properties:
+ compatible:
+ const: ralink,rt2880-timer
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@100 {
+ compatible = "ralink,rt2880-timer";
+ reg = <0x100 0x20>;
+
+ clocks = <&sysc 3>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <1>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml b/Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml
new file mode 100644
index 000000000000..7b6ec2c69484
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/realtek,otto-timer.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/realtek,otto-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek Otto SoCs Timer/Counter
+
+description:
+ Realtek SoCs support a number of timers/counters. These are used
+ as a per CPU clock event generator and an overall CPU clocksource.
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+properties:
+ $nodename:
+ pattern: "^timer@[0-9a-f]+$"
+
+ compatible:
+ items:
+ - enum:
+ - realtek,rtl9302-timer
+ - const: realtek,otto-timer
+
+ reg:
+ items:
+ - description: timer0 registers
+ - description: timer1 registers
+ - description: timer2 registers
+ - description: timer3 registers
+ - description: timer4 registers
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: timer0 interrupt
+ - description: timer1 interrupt
+ - description: timer2 interrupt
+ - description: timer3 interrupt
+ - description: timer4 interrupt
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@3200 {
+ compatible = "realtek,rtl9302-timer", "realtek,otto-timer";
+ reg = <0x3200 0x10>, <0x3210 0x10>, <0x3220 0x10>,
+ <0x3230 0x10>, <0x3240 0x10>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <7>, <8>, <9>, <10>, <11>;
+ clocks = <&lx_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/realtek,rtd1625-systimer.yaml b/Documentation/devicetree/bindings/timer/realtek,rtd1625-systimer.yaml
new file mode 100644
index 000000000000..e08d3d2d306b
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/realtek,rtd1625-systimer.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/realtek,rtd1625-systimer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek System Timer
+
+maintainers:
+ - Hao-Wen Ting <haowen.ting@realtek.com>
+
+description:
+ The Realtek SYSTIMER (System Timer) is a 64-bit global hardware counter operating
+ at a fixed 1MHz frequency. Thanks to its compare match interrupt capability,
+ the timer natively supports oneshot mode for tick broadcast functionality.
+
+properties:
+ compatible:
+ oneOf:
+ - const: realtek,rtd1625-systimer
+ - items:
+ - const: realtek,rtd1635-systimer
+ - const: realtek,rtd1625-systimer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ timer@89420 {
+ compatible = "realtek,rtd1635-systimer",
+ "realtek,rtd1625-systimer";
+ reg = <0x89420 0x18>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
index bde6c9b66bf4..260b05f213e6 100644
--- a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml
@@ -102,12 +102,16 @@ properties:
- enum:
- renesas,r8a779a0-cmt0 # 32-bit CMT0 on R-Car V3U
- renesas,r8a779f0-cmt0 # 32-bit CMT0 on R-Car S4-8
+ - renesas,r8a779g0-cmt0 # 32-bit CMT0 on R-Car V4H
+ - renesas,r8a779h0-cmt0 # 32-bit CMT0 on R-Car V4M
- const: renesas,rcar-gen4-cmt0 # 32-bit CMT0 on R-Car Gen4
- items:
- enum:
- renesas,r8a779a0-cmt1 # 48-bit CMT on R-Car V3U
- renesas,r8a779f0-cmt1 # 48-bit CMT on R-Car S4-8
+ - renesas,r8a779g0-cmt1 # 48-bit CMT on R-Car V4H
+ - renesas,r8a779h0-cmt1 # 48-bit CMT on R-Car V4M
- const: renesas,rcar-gen4-cmt1 # 48-bit CMT on R-Car Gen4
reg:
@@ -174,29 +178,29 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7790-sysc.h>
cmt0: timer@ffca0000 {
- compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0";
- reg = <0xffca0000 0x1004>;
- interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 124>;
- clock-names = "fck";
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 124>;
+ compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0";
+ reg = <0xffca0000 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
};
cmt1: timer@e6130000 {
- compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1";
- reg = <0xe6130000 0x1004>;
- interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 329>;
- clock-names = "fck";
- power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
- resets = <&cpg 329>;
+ compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1";
+ reg = <0xe6130000 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
};
diff --git a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
index 233d74d5402c..a7385d865bca 100644
--- a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
@@ -38,9 +38,9 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
timer@e0180000 {
- compatible = "renesas,em-sti";
- reg = <0xe0180000 0x54>;
- interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sti_sclk>;
- clock-names = "sclk";
+ compatible = "renesas,em-sti";
+ reg = <0xe0180000 0x54>;
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sti_sclk>;
+ clock-names = "sclk";
};
diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml
index 15d8dddf4ae9..e56c12f03f72 100644
--- a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml
@@ -66,11 +66,11 @@ examples:
#include <dt-bindings/clock/r7s72100-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
mtu2: timer@fcff0000 {
- compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
- reg = <0xfcff0000 0x400>;
- interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "tgi0a";
- clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
- clock-names = "fck";
- power-domains = <&cpg_clocks>;
+ compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
+ reg = <0xfcff0000 0x400>;
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tgi0a";
+ clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
+ clock-names = "fck";
+ power-domains = <&cpg_clocks>;
};
diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
index 7207929e5cd6..0983c1efec80 100644
--- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml
@@ -23,9 +23,11 @@ properties:
- enum:
- renesas,r7s72100-ostm # RZ/A1H
- renesas,r7s9210-ostm # RZ/A2M
- - renesas,r9a07g043-ostm # RZ/G2UL
+ - renesas,r9a07g043-ostm # RZ/G2UL and RZ/Five
- renesas,r9a07g044-ostm # RZ/G2{L,LC}
- renesas,r9a07g054-ostm # RZ/V2L
+ - renesas,r9a09g056-ostm # RZ/V2N
+ - renesas,r9a09g057-ostm # RZ/V2H(P)
- const: renesas,ostm # Generic
reg:
@@ -53,11 +55,11 @@ required:
if:
properties:
compatible:
- contains:
- enum:
- - renesas,r9a07g043-ostm
- - renesas,r9a07g044-ostm
- - renesas,r9a07g054-ostm
+ not:
+ contains:
+ enum:
+ - renesas,r7s72100-ostm
+ - renesas,r7s9210-ostm
then:
required:
- resets
@@ -69,9 +71,9 @@ examples:
#include <dt-bindings/clock/r7s72100-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
ostm0: timer@fcfec000 {
- compatible = "renesas,r7s72100-ostm", "renesas,ostm";
- reg = <0xfcfec000 0x30>;
- interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>;
- clocks = <&mstp5_clks R7S72100_CLK_OSTM0>;
- power-domains = <&cpg_clocks>;
+ compatible = "renesas,r7s72100-ostm", "renesas,ostm";
+ reg = <0xfcfec000 0x30>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&mstp5_clks R7S72100_CLK_OSTM0>;
+ power-domains = <&cpg_clocks>;
};
diff --git a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
new file mode 100644
index 000000000000..3ad10c5b66ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
@@ -0,0 +1,306 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/renesas,rz-mtu3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Multi-Function Timer Pulse Unit 3 (MTU3a)
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ This hardware block consists of eight 16-bit timer channels and one
+ 32-bit timer channel. It supports the following specifications:
+ - Pulse input/output: 28 lines max
+ - Pulse input 3 lines
+ - Count clock 11 clocks for each channel (14 clocks for MTU0, 12 clocks
+ for MTU2, and 10 clocks for MTU5, four clocks for MTU1-MTU2 combination
+ (when LWA = 1))
+ - Operating frequency Up to 100 MHz
+ - Available operations [MTU0 to MTU4, MTU6, MTU7, and MTU8]
+ - Waveform output on compare match
+ - Input capture function (noise filter setting available)
+ - Counter-clearing operation
+ - Simultaneous writing to multiple timer counters (TCNT)
+ (excluding MTU8)
+ - Simultaneous clearing on compare match or input capture
+ (excluding MTU8)
+ - Simultaneous input and output to registers in synchronization with
+ counter operations (excluding MTU8)
+ - Up to 12-phase PWM output in combination with synchronous operation
+ (excluding MTU8)
+ - [MTU0 MTU3, MTU4, MTU6, MTU7, and MTU8]
+ - Buffer operation specifiable
+ - [MTU1, MTU2]
+ - Phase counting mode can be specified independently
+ - 32-bit phase counting mode can be specified for interlocked operation
+ of MTU1 and MTU2 (when TMDR3.LWA = 1)
+ - Cascade connection operation available
+ - [MTU3, MTU4, MTU6, and MTU7]
+ - Through interlocked operation of MTU3/4 and MTU6/7, the positive and
+ negative signals in six phases (12 phases in total) can be output in
+ complementary PWM and reset-synchronized PWM operation
+ - In complementary PWM mode, values can be transferred from buffer
+ registers to temporary registers at crests and troughs of the timer-
+ counter values or when the buffer registers (TGRD registers in MTU4
+ and MTU7) are written to
+ - Double-buffering selectable in complementary PWM mode
+ - [MTU3 and MTU4]
+ - Through interlocking with MTU0, a mode for driving AC synchronous
+ motors (brushless DC motors) by using complementary PWM output and
+ reset-synchronized PWM output is settable and allows the selection
+ of two types of waveform output (chopping or level)
+ - [MTU5]
+ - Capable of operation as a dead-time compensation counter
+ - [MTU0/MTU5, MTU1, MTU2, and MTU8]
+ - 32-bit phase counting mode specifiable by combining MTU1 and MTU2 and
+ through interlocked operation with MTU0/MTU5 and MTU8
+ - Interrupt-skipping function
+ - In complementary PWM mode, interrupts on crests and troughs of counter
+ values and triggers to start conversion by the A/D converter can be
+ skipped
+ - Interrupt sources: 43 sources.
+ - Buffer operation:
+ - Automatic transfer of register data (transfer from the buffer
+ register to the timer register).
+ - Trigger generation
+ - A/D converter start triggers can be generated
+ - A/D converter start request delaying function enables A/D converter
+ to be started with any desired timing and to be synchronized with
+ PWM output
+ - Low power consumption function
+ - The MTU3a can be placed in the module-stop state
+
+ There are two phase counting modes. 16-bit phase counting mode in which
+ MTU1 and MTU2 operate independently, and cascade connection 32-bit phase
+ counting mode in which MTU1 and MTU2 are cascaded.
+
+ In phase counting mode, the phase difference between two external input
+ clocks is detected and the corresponding TCNT is incremented or
+ decremented.
+ The below counters are supported
+ count0 - MTU1 16-bit phase counting
+ count1 - MTU2 16-bit phase counting
+ count2 - MTU1+ MTU2 32-bit phase counting
+
+ The module supports PWM mode{1,2}, Reset-synchronized PWM mode and
+ complementary PWM mode{1,2,3}.
+
+ In complementary PWM mode, six positive-phase and six negative-phase PWM
+ waveforms (12 phases in total) with dead time can be output by
+ combining MTU{3,4} and MTU{6,7}.
+
+ The below pwm channels are supported in pwm mode 1.
+ pwm0 - MTU0.MTIOC0A PWM mode 1
+ pwm1 - MTU0.MTIOC0C PWM mode 1
+ pwm2 - MTU1.MTIOC1A PWM mode 1
+ pwm3 - MTU2.MTIOC2A PWM mode 1
+ pwm4 - MTU3.MTIOC3A PWM mode 1
+ pwm5 - MTU3.MTIOC3C PWM mode 1
+ pwm6 - MTU4.MTIOC4A PWM mode 1
+ pwm7 - MTU4.MTIOC4C PWM mode 1
+ pwm8 - MTU6.MTIOC6A PWM mode 1
+ pwm9 - MTU6.MTIOC6C PWM mode 1
+ pwm10 - MTU7.MTIOC7A PWM mode 1
+ pwm11 - MTU7.MTIOC7C PWM mode 1
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a07g043-mtu3 # RZ/{G2UL,Five}
+ - renesas,r9a07g044-mtu3 # RZ/G2{L,LC}
+ - renesas,r9a07g054-mtu3 # RZ/V2L
+ - const: renesas,rz-mtu3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: MTU0.TGRA input capture/compare match
+ - description: MTU0.TGRB input capture/compare match
+ - description: MTU0.TGRC input capture/compare match
+ - description: MTU0.TGRD input capture/compare match
+ - description: MTU0.TCNT overflow
+ - description: MTU0.TGRE compare match
+ - description: MTU0.TGRF compare match
+ - description: MTU1.TGRA input capture/compare match
+ - description: MTU1.TGRB input capture/compare match
+ - description: MTU1.TCNT overflow
+ - description: MTU1.TCNT underflow
+ - description: MTU2.TGRA input capture/compare match
+ - description: MTU2.TGRB input capture/compare match
+ - description: MTU2.TCNT overflow
+ - description: MTU2.TCNT underflow
+ - description: MTU3.TGRA input capture/compare match
+ - description: MTU3.TGRB input capture/compare match
+ - description: MTU3.TGRC input capture/compare match
+ - description: MTU3.TGRD input capture/compare match
+ - description: MTU3.TCNT overflow
+ - description: MTU4.TGRA input capture/compare match
+ - description: MTU4.TGRB input capture/compare match
+ - description: MTU4.TGRC input capture/compare match
+ - description: MTU4.TGRD input capture/compare match
+ - description: MTU4.TCNT overflow/underflow
+ - description: MTU5.TGRU input capture/compare match
+ - description: MTU5.TGRV input capture/compare match
+ - description: MTU5.TGRW input capture/compare match
+ - description: MTU6.TGRA input capture/compare match
+ - description: MTU6.TGRB input capture/compare match
+ - description: MTU6.TGRC input capture/compare match
+ - description: MTU6.TGRD input capture/compare match
+ - description: MTU6.TCNT overflow
+ - description: MTU7.TGRA input capture/compare match
+ - description: MTU7.TGRB input capture/compare match
+ - description: MTU7.TGRC input capture/compare match
+ - description: MTU7.TGRD input capture/compare match
+ - description: MTU7.TCNT overflow/underflow
+ - description: MTU8.TGRA input capture/compare match
+ - description: MTU8.TGRB input capture/compare match
+ - description: MTU8.TGRC input capture/compare match
+ - description: MTU8.TGRD input capture/compare match
+ - description: MTU8.TCNT overflow
+ - description: MTU8.TCNT underflow
+
+ interrupt-names:
+ items:
+ - const: tgia0
+ - const: tgib0
+ - const: tgic0
+ - const: tgid0
+ - const: tciv0
+ - const: tgie0
+ - const: tgif0
+ - const: tgia1
+ - const: tgib1
+ - const: tciv1
+ - const: tciu1
+ - const: tgia2
+ - const: tgib2
+ - const: tciv2
+ - const: tciu2
+ - const: tgia3
+ - const: tgib3
+ - const: tgic3
+ - const: tgid3
+ - const: tciv3
+ - const: tgia4
+ - const: tgib4
+ - const: tgic4
+ - const: tgid4
+ - const: tciv4
+ - const: tgiu5
+ - const: tgiv5
+ - const: tgiw5
+ - const: tgia6
+ - const: tgib6
+ - const: tgic6
+ - const: tgid6
+ - const: tciv6
+ - const: tgia7
+ - const: tgib7
+ - const: tgic7
+ - const: tgid7
+ - const: tciv7
+ - const: tgia8
+ - const: tgib8
+ - const: tgic8
+ - const: tgid8
+ - const: tciv8
+ - const: tciu8
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#pwm-cells":
+ oneOf:
+ - const: 2
+ deprecated: true
+ - const: 3
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - power-domains
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mtu3: timer@10001200 {
+ compatible = "renesas,r9a07g044-mtu3", "renesas,rz-mtu3";
+ reg = <0x10001200 0xb00>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 171 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 172 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 173 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 174 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 175 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 176 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 179 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 180 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 181 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 182 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 183 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 184 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 185 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 186 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 188 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 189 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 190 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 191 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 192 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 194 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 195 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 198 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 199 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 200 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 201 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 202 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 203 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 204 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 206 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 207 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 208 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 210 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 211 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 213 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0", "tciv0", "tgie0",
+ "tgif0",
+ "tgia1", "tgib1", "tciv1", "tciu1",
+ "tgia2", "tgib2", "tciv2", "tciu2",
+ "tgia3", "tgib3", "tgic3", "tgid3", "tciv3",
+ "tgia4", "tgib4", "tgic4", "tgid4", "tciv4",
+ "tgiu5", "tgiv5", "tgiw5",
+ "tgia6", "tgib6", "tgic6", "tgid6", "tciv6",
+ "tgia7", "tgib7", "tgic7", "tgid7", "tciv7",
+ "tgia8", "tgib8", "tgic8", "tgid8", "tciv8", "tciu8";
+ clocks = <&cpg CPG_MOD R9A07G044_MTU_X_MCK_MTU3>;
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G044_MTU_X_PRESET_MTU3>;
+ #pwm-cells = <3>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
index c57169118b68..b1229595acfb 100644
--- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
@@ -21,13 +21,24 @@ properties:
compatible:
items:
- enum:
+ - renesas,tmu-r8a73a4 # R-Mobile APE6
- renesas,tmu-r8a7740 # R-Mobile A1
+ - renesas,tmu-r8a7742 # RZ/G1H
+ - renesas,tmu-r8a7743 # RZ/G1M
+ - renesas,tmu-r8a7744 # RZ/G1N
+ - renesas,tmu-r8a7745 # RZ/G1E
+ - renesas,tmu-r8a77470 # RZ/G1C
- renesas,tmu-r8a774a1 # RZ/G2M
- renesas,tmu-r8a774b1 # RZ/G2N
- renesas,tmu-r8a774c0 # RZ/G2E
- renesas,tmu-r8a774e1 # RZ/G2H
- renesas,tmu-r8a7778 # R-Car M1A
- renesas,tmu-r8a7779 # R-Car H1
+ - renesas,tmu-r8a7790 # R-Car H2
+ - renesas,tmu-r8a7791 # R-Car M2-W
+ - renesas,tmu-r8a7792 # R-Car V2H
+ - renesas,tmu-r8a7793 # R-Car M2-N
+ - renesas,tmu-r8a7794 # R-Car E2
- renesas,tmu-r8a7795 # R-Car H3
- renesas,tmu-r8a7796 # R-Car M3-W
- renesas,tmu-r8a77961 # R-Car M3-W+
@@ -37,6 +48,9 @@ properties:
- renesas,tmu-r8a77990 # R-Car E3
- renesas,tmu-r8a77995 # R-Car D3
- renesas,tmu-r8a779a0 # R-Car V3U
+ - renesas,tmu-r8a779f0 # R-Car S4-8
+ - renesas,tmu-r8a779g0 # R-Car V4H
+ - renesas,tmu-r8a779h0 # R-Car V4M
- const: renesas,tmu
reg:
@@ -44,7 +58,19 @@ properties:
interrupts:
minItems: 2
- maxItems: 3
+ items:
+ - description: Underflow interrupt, channel 0
+ - description: Underflow interrupt, channel 1
+ - description: Underflow interrupt, channel 2
+ - description: Input capture interrupt, channel 2
+
+ interrupt-names:
+ minItems: 2
+ items:
+ - const: tuni0
+ - const: tuni1
+ - const: tuni2
+ - const: ticpi2
clocks:
maxItems: 1
@@ -69,6 +95,7 @@ required:
- compatible
- reg
- interrupts
+ - interrupt-names
- clocks
- clock-names
- power-domains
@@ -79,6 +106,7 @@ if:
compatible:
contains:
enum:
+ - renesas,tmu-r8a73a4
- renesas,tmu-r8a7740
- renesas,tmu-r8a7778
- renesas,tmu-r8a7779
@@ -94,13 +122,15 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7779-sysc.h>
tmu0: timer@ffd80000 {
- compatible = "renesas,tmu-r8a7779", "renesas,tmu";
- reg = <0xffd80000 0x30>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
- clock-names = "fck";
- power-domains = <&sysc R8A7779_PD_ALWAYS_ON>;
- #renesas,channels = <3>;
+ compatible = "renesas,tmu-r8a7779", "renesas,tmu";
+ reg = <0xffd80000 0x30>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tuni0", "tuni1", "tuni2", "ticpi2";
+ clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7779_PD_ALWAYS_ON>;
+ #renesas,channels = <3>;
};
diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml
deleted file mode 100644
index 01554dff23d8..000000000000
--- a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/timer/renesas,tpu.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Renesas H8/300 Timer Pulse Unit
-
-maintainers:
- - Yoshinori Sato <ysato@users.sourceforge.jp>
-
-description:
- The TPU is a 16bit timer/counter with configurable clock inputs and
- programmable compare match.
- This implementation supports only cascade mode.
-
-select:
- properties:
- compatible:
- contains:
- const: renesas,tpu
- '#pwm-cells': false
- required:
- - compatible
-
-properties:
- compatible:
- const: renesas,tpu
-
- reg:
- items:
- - description: First channel
- - description: Second channel
-
- clocks:
- maxItems: 1
-
- clock-names:
- const: fck
-
-required:
- - compatible
- - reg
- - clocks
- - clock-names
-
-additionalProperties: false
-
-examples:
- - |
- tpu: tpu@ffffe0 {
- compatible = "renesas,tpu";
- reg = <0xffffe0 16>, <0xfffff0 12>;
- clocks = <&pclk>;
- clock-names = "fck";
- };
diff --git a/Documentation/devicetree/bindings/timer/riscv,timer.yaml b/Documentation/devicetree/bindings/timer/riscv,timer.yaml
new file mode 100644
index 000000000000..38d67e1a5a79
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/riscv,timer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/riscv,timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V timer
+
+maintainers:
+ - Anup Patel <anup@brainfault.org>
+
+description: |+
+ RISC-V platforms always have a RISC-V timer device for the supervisor-mode
+ based on the time CSR defined by the RISC-V privileged specification. The
+ timer interrupts of this device are configured using the RISC-V SBI Time
+ extension or the RISC-V Sstc extension.
+
+ The clock frequency of RISC-V timer device is specified via the
+ "timebase-frequency" DT property of "/cpus" DT node which is described
+ in Documentation/devicetree/bindings/riscv/cpus.yaml
+
+properties:
+ compatible:
+ enum:
+ - riscv,timer
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4096 # Should be enough?
+
+ riscv,timer-cannot-wake-cpu:
+ type: boolean
+ description:
+ If present, the timer interrupt cannot wake up the CPU from one or
+ more suspend/idle states.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - interrupts-extended
+
+examples:
+ - |
+ timer {
+ compatible = "riscv,timer";
+ interrupts-extended = <&cpu1intc 5>,
+ <&cpu2intc 5>,
+ <&cpu3intc 5>,
+ <&cpu4intc 5>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
index 5d157d87dad5..6d0eb0014eee 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/rockchip,rk-timer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Rockchip Timer Device Tree Bindings
+title: Rockchip Timer
maintainers:
- Daniel Lezcano <daniel.lezcano@linaro.org>
@@ -17,12 +17,15 @@ properties:
- items:
- enum:
- rockchip,rv1108-timer
+ - rockchip,rv1126-timer
- rockchip,rk3036-timer
+ - rockchip,rk3128-timer
- rockchip,rk3188-timer
- rockchip,rk3228-timer
- rockchip,rk3229-timer
- - rockchip,rk3288-timer
- rockchip,rk3368-timer
+ - rockchip,rk3576-timer
+ - rockchip,rk3588-timer
- rockchip,px30-timer
- const: rockchip,rk3288-timer
reg:
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
index 9c81d00b12e0..a4b229e0e78a 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
@@ -25,12 +25,18 @@ properties:
- samsung,exynos4412-mct
- items:
- enum:
+ - axis,artpec8-mct
+ - axis,artpec9-mct
+ - google,gs101-mct
+ - samsung,exynos2200-mct-peris
- samsung,exynos3250-mct
- samsung,exynos5250-mct
- samsung,exynos5260-mct
- samsung,exynos5420-mct
- samsung,exynos5433-mct
- samsung,exynos850-mct
+ - samsung,exynos8895-mct
+ - samsung,exynos990-mct
- tesla,fsd-mct
- const: samsung,exynos4210-mct
@@ -45,6 +51,19 @@ properties:
reg:
maxItems: 1
+ samsung,frc-shared:
+ type: boolean
+ description: |
+ Indicates that the hardware requires that this processor share the
+ free-running counter with a different (main) processor.
+
+ samsung,local-timers:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 16
+ description: |
+ List of indices of local timers usable from this processor.
+
interrupts:
description: |
Interrupts should be put in specific order. This is, the local timer
@@ -75,6 +94,17 @@ required:
allOf:
- if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - axis,artpec8-mct
+ then:
+ properties:
+ samsung,local-timers: false
+ samsung,frc-shared: false
+ - if:
properties:
compatible:
contains:
@@ -101,10 +131,16 @@ allOf:
compatible:
contains:
enum:
+ - axis,artpec8-mct
+ - axis,artpec9-mct
+ - google,gs101-mct
+ - samsung,exynos2200-mct-peris
- samsung,exynos5260-mct
- samsung,exynos5420-mct
- samsung,exynos5433-mct
- samsung,exynos850-mct
+ - samsung,exynos8895-mct
+ - samsung,exynos990-mct
then:
properties:
interrupts:
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index e64f46339079..0d3b8dc362ba 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -20,24 +20,48 @@ description:
property of "/cpus" DT node. The "timebase-frequency" DT property is
described in Documentation/devicetree/bindings/riscv/cpus.yaml
+ T-Head C906/C910 CPU cores include an implementation of CLINT too, however
+ their implementation lacks a memory-mapped MTIME register, thus not
+ compatible with SiFive ones.
+
properties:
compatible:
- items:
- - enum:
- - sifive,fu540-c000-clint
- - starfive,jh7100-clint
- - canaan,k210-clint
- - const: sifive,clint0
+ oneOf:
+ - items:
+ - enum:
+ - canaan,k210-clint # Canaan Kendryte K210
+ - eswin,eic7700-clint # ESWIN EIC7700
+ - sifive,fu540-c000-clint # SiFive FU540
+ - spacemit,k1-clint # SpacemiT K1
+ - starfive,jh7100-clint # StarFive JH7100
+ - starfive,jh7110-clint # StarFive JH7110
+ - starfive,jh8100-clint # StarFive JH8100
+ - tenstorrent,blackhole-clint # Tenstorrent Blackhole
+ - const: sifive,clint0 # SiFive CLINT v0 IP block
+ - items:
+ - {}
+ - const: sifive,clint2 # SiFive CLINT v2 IP block
+ description:
+ SiFive CLINT v2 is the HRT that supports the Zicntr. The control of sifive,clint2
+ differs from that of sifive,clint0, making them incompatible.
+ - items:
+ - enum:
+ - allwinner,sun20i-d1-clint
+ - sophgo,cv1800b-clint
+ - sophgo,cv1812h-clint
+ - sophgo,sg2002-clint
+ - thead,th1520-clint
+ - const: thead,c900-clint
+ - items:
+ - const: sifive,clint0
+ - const: riscv,clint0
+ deprecated: true
+ description: For the QEMU virt machine only
description:
- Should be "<vendor>,<chip>-clint" and "sifive,clint<version>".
- Supported compatible strings are -
- "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
- onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive
- CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and
- "sifive,clint0" for the SiFive CLINT v0 IP block with no chip
- integration tweaks.
- Please refer to sifive-blocks-ip-versioning.txt for details
+ Should be "<vendor>,<chip>-clint", followed by "sifive,clint<version>"
+ when compatible with a SiFive CLINT. Please refer to
+ sifive-blocks-ip-versioning.txt for details regarding the latter.
reg:
maxItems: 1
@@ -46,6 +70,22 @@ properties:
minItems: 1
maxItems: 4095
+ sifive,fine-ctr-bits:
+ maximum: 15
+ description: The width in bits of the fine counter.
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: sifive,clint2
+then:
+ required:
+ - sifive,fine-ctr-bits
+else:
+ properties:
+ sifive,fine-ctr-bits: false
+
additionalProperties: false
required:
@@ -61,6 +101,6 @@ examples:
<&cpu2intc 3>, <&cpu2intc 7>,
<&cpu3intc 3>, <&cpu3intc 7>,
<&cpu4intc 3>, <&cpu4intc 7>;
- reg = <0x2000000 0x10000>;
+ reg = <0x2000000 0x10000>;
};
...
diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
deleted file mode 100644
index 147ef3e74452..000000000000
--- a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Synopsys ARC Local Timer with Interrupt Capabilities
-- Found on all ARC CPUs (ARC700/ARCHS)
-- Can be optionally programmed to interrupt on Limit
-- Two idential copies TIMER0 and TIMER1 exist in ARC cores and historically
- TIMER0 used as clockevent provider (true for all ARC cores)
- TIMER1 used for clocksource (mandatory for ARC700, optional for ARC HS)
-
-Required properties:
-
-- compatible : should be "snps,arc-timer"
-- interrupts : single Interrupt going into parent intc
- (16 for ARCHS cores, 3 for ARC700 cores)
-- clocks : phandle to the source clock
-
-Example:
-
- timer0 {
- compatible = "snps,arc-timer";
- interrupts = <3>;
- interrupt-parent = <&core_intc>;
- clocks = <&core_clk>;
- };
-
- timer1 {
- compatible = "snps,arc-timer";
- clocks = <&core_clk>;
- };
diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer.yaml b/Documentation/devicetree/bindings/timer/snps,arc-timer.yaml
new file mode 100644
index 000000000000..0d1e37db6f8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/snps,arc-timer.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/snps,arc-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys ARC Local Timer
+
+maintainers:
+ - Vineet Gupta <vgupta@synopsys.com>
+
+description: >
+ Synopsys ARC Local Timer with Interrupt Capabilities
+
+ - Found on all ARC CPUs (ARC700/ARCHS)
+ - Can be optionally programmed to interrupt on Limit
+ - Two identical copies TIMER0 and TIMER1 exist in ARC cores and historically
+ TIMER0 used as clockevent provider (true for all ARC cores)
+ TIMER1 used for clocksource (mandatory for ARC700, optional for ARC HS)
+
+properties:
+ compatible:
+ const: snps,arc-timer
+
+ interrupts:
+ maxItems: 1
+ description: A single timer interrupt going into the parent interrupt controller.
+ Use <16> for ARCHS cores, <3> for ARC700 cores.
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer0 {
+ compatible = "snps,arc-timer";
+ interrupts = <3>;
+ clocks = <&core_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
deleted file mode 100644
index b6cd1b3922de..000000000000
--- a/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Synopsys ARC Free Running 64-bit Global Timer for ARC HS CPUs
-- clocksource provider for SMP SoC
-
-Required properties:
-
-- compatible : should be "snps,archs-gfrc"
-- clocks : phandle to the source clock
-
-Example:
-
- gfrc {
- compatible = "snps,archs-gfrc";
- clocks = <&core_clk>;
- };
diff --git a/Documentation/devicetree/bindings/timer/snps,archs-gfrc.yaml b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.yaml
new file mode 100644
index 000000000000..fb16f4aba1c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/snps,archs-gfrc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys ARC Free Running 64-bit Global Timer for ARC HS CPUs
+
+maintainers:
+ - Vineet Gupta <vgupta@synopsys.com>
+
+properties:
+ compatible:
+ const: snps,archs-gfrc
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer {
+ compatible = "snps,archs-gfrc";
+ clocks = <&core_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt b/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
deleted file mode 100644
index 47bd7a702f3f..000000000000
--- a/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Synopsys ARC Free Running 64-bit Local Timer for ARC HS CPUs
-- clocksource provider for UP SoC
-
-Required properties:
-
-- compatible : should be "snps,archs-rtc"
-- clocks : phandle to the source clock
-
-Example:
-
- rtc {
- compatible = "snps,arc-rtc";
- clocks = <&core_clk>;
- };
diff --git a/Documentation/devicetree/bindings/timer/snps,archs-rtc.yaml b/Documentation/devicetree/bindings/timer/snps,archs-rtc.yaml
new file mode 100644
index 000000000000..7478810eb24a
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/snps,archs-rtc.yaml
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/snps,archs-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys ARC Free Running 64-bit Local Timer for ARC HS CPUs
+
+maintainers:
+ - Vineet Gupta <vgupta@synopsys.com>
+
+properties:
+ compatible:
+ const: snps,archs-rtc
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ rtc {
+ compatible = "snps,archs-rtc";
+ clocks = <&core_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
deleted file mode 100644
index ac44c4b67530..000000000000
--- a/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Milbeaut SoCs Timer Controller
-
-Required properties:
-
-- compatible : should be "socionext,milbeaut-timer".
-- reg : Specifies base physical address and size of the registers.
-- interrupts : The interrupt of the first timer.
-- clocks: phandle to the input clk.
-
-Example:
-
-timer {
- compatible = "socionext,milbeaut-timer";
- reg = <0x1e000050 0x20>
- interrupts = <0 91 4>;
- clocks = <&clk 4>;
-};
diff --git a/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.yaml b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.yaml
new file mode 100644
index 000000000000..9ab72b762314
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/socionext,milbeaut-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Milbeaut SoCs Timer Controller
+
+maintainers:
+ - Sugaya Taichi <sugaya.taichi@socionext.com>
+
+properties:
+ compatible:
+ const: socionext,milbeaut-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@1e000050 {
+ compatible = "socionext,milbeaut-timer";
+ reg = <0x1e000050 0x20>;
+ interrupts = <0 91 4>;
+ clocks = <&clk 4>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/sprd,sc9860-timer.yaml b/Documentation/devicetree/bindings/timer/sprd,sc9860-timer.yaml
new file mode 100644
index 000000000000..62c6da8bab5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/sprd,sc9860-timer.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/sprd,sc9860-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SC9860 timer
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+description:
+ The Spreadtrum SC9860 platform provides 3 general-purpose timers.
+ These timers can support 32bit or 64bit counter, as well as supporting
+ period mode or one-shot mode, and they can be a wakeup source
+ during deep sleep.
+
+properties:
+ compatible:
+ enum:
+ - sprd,sc9860-timer
+ - sprd,sc9860-suspend-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: sprd,sc9860-timer
+ then:
+ required:
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ timer@40050000 {
+ compatible = "sprd,sc9860-timer";
+ reg = <0 0x40050000 0 0x20>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_32k>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt b/Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt
deleted file mode 100644
index 6d97e7d0f6e8..000000000000
--- a/Documentation/devicetree/bindings/timer/spreadtrum,sprd-timer.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Spreadtrum timers
-
-The Spreadtrum SC9860 platform provides 3 general-purpose timers.
-These timers can support 32bit or 64bit counter, as well as supporting
-period mode or one-shot mode, and they are can be wakeup source
-during deep sleep.
-
-Required properties:
-- compatible: should be "sprd,sc9860-timer" for SC9860 platform.
-- reg: The register address of the timer device.
-- interrupts: Should contain the interrupt for the timer device.
-- clocks: The phandle to the source clock (usually a 32.768 KHz fixed clock).
-
-Example:
- timer@40050000 {
- compatible = "sprd,sc9860-timer";
- reg = <0 0x40050000 0 0x20>;
- interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&ext_32k>;
- };
diff --git a/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml b/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml
index 901848d298ec..fa65878b3571 100644
--- a/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml
+++ b/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml
@@ -2,8 +2,8 @@
# Copyright 2022 Linaro Ltd.
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/timer/st,nomadik-mtu.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/timer/st,nomadik-mtu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ST Microelectronics Nomadik Multi-Timer Unit MTU Timer
diff --git a/Documentation/devicetree/bindings/timer/st,spear-timer.txt b/Documentation/devicetree/bindings/timer/st,spear-timer.txt
deleted file mode 100644
index b5238a07da17..000000000000
--- a/Documentation/devicetree/bindings/timer/st,spear-timer.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* SPEAr ARM Timer
-
-** Timer node required properties:
-
-- compatible : Should be:
- "st,spear-timer"
-- reg: Address range of the timer registers
-- interrupt: Should contain the timer interrupt number
-
-Example:
-
- timer@f0000000 {
- compatible = "st,spear-timer";
- reg = <0xf0000000 0x400>;
- interrupts = <2>;
- };
diff --git a/Documentation/devicetree/bindings/timer/st,spear-timer.yaml b/Documentation/devicetree/bindings/timer/st,spear-timer.yaml
new file mode 100644
index 000000000000..9f26b5f2b38a
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/st,spear-timer.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/st,spear-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPEAr ARM Timer
+
+maintainers:
+ - Viresh Kumar <vireshk@kernel.org>
+ - Shiraz Hashim <shiraz.linux.kernel@gmail.com>
+
+properties:
+ compatible:
+ const: st,spear-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@f0000000 {
+ compatible = "st,spear-timer";
+ reg = <0xf0000000 0x400>;
+ interrupts = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml b/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml
index 937aa8a56366..9ec11537620a 100644
--- a/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/st,stm32-timer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/st,stm32-timer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 general-purpose 16 and 32 bits timers bindings
+title: STMicroelectronics STM32 general-purpose 16 and 32 bits timers
maintainers:
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
diff --git a/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer.yaml b/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer.yaml
new file mode 100644
index 000000000000..cf7c82e980f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/thead,c900-aclint-mtimer.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/thead,c900-aclint-mtimer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ACLINT Machine-level Timer Device
+
+maintainers:
+ - Inochi Amaoto <inochiama@outlook.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - sophgo,sg2042-aclint-mtimer
+ - sophgo,sg2044-aclint-mtimer
+ - const: thead,c900-aclint-mtimer
+ - items:
+ - enum:
+ - anlogic,dr1v90-aclint-mtimer
+ - const: nuclei,ux900-aclint-mtimer
+
+ reg:
+ items:
+ - description: MTIMECMP Registers
+
+ reg-names:
+ items:
+ - const: mtimecmp
+
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4095
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts-extended
+
+examples:
+ - |
+ timer@ac000000 {
+ compatible = "sophgo,sg2042-aclint-mtimer", "thead,c900-aclint-mtimer";
+ interrupts-extended = <&cpu1intc 7>,
+ <&cpu2intc 7>,
+ <&cpu3intc 7>,
+ <&cpu4intc 7>;
+ reg = <0xac000000 0x00010000>;
+ reg-names = "mtimecmp";
+ };
+...
diff --git a/Documentation/devicetree/bindings/timer/ti,da830-timer.yaml b/Documentation/devicetree/bindings/timer/ti,da830-timer.yaml
new file mode 100644
index 000000000000..e9646f4e86cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ti,da830-timer.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/ti,da830-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DaVinci Timer
+
+maintainers:
+ - Kousik Sanagavarapu <five231003@gmail.com>
+
+description: |
+ This is a 64-bit timer found on TI's DaVinci architecture devices. The timer
+ can be configured as a general-purpose 64-bit timer, dual general-purpose
+ 32-bit timers. When configured as dual 32-bit timers, each half can operate
+ in conjunction (chain mode) or independently (unchained mode) of each other.
+
+ The timer is a free running up-counter and can generate interrupts when the
+ counter reaches preset counter values.
+
+properties:
+ compatible:
+ const: ti,da830-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 2
+ maxItems: 10
+
+ interrupt-names:
+ minItems: 2
+ items:
+ - const: tint12
+ - const: tint34
+ - const: cmpint0
+ - const: cmpint1
+ - const: cmpint2
+ - const: cmpint3
+ - const: cmpint4
+ - const: cmpint5
+ - const: cmpint6
+ - const: cmpint7
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@20000 {
+ compatible = "ti,da830-timer";
+ reg = <0x20000 0x1000>;
+ interrupts = <21>, <22>;
+ interrupt-names = "tint12", "tint34";
+ clocks = <&pll0_auxclk>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/timer/ti,davinci-timer.txt b/Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
deleted file mode 100644
index 29bf91ccf5b7..000000000000
--- a/Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-* Device tree bindings for Texas Instruments DaVinci timer
-
-This document provides bindings for the 64-bit timer in the DaVinci
-architecture devices. The timer can be configured as a general-purpose 64-bit
-timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
-timers, each half can operate in conjunction (chain mode) or independently
-(unchained mode) of each other.
-
-The timer is a free running up-counter and can generate interrupts when the
-counter reaches preset counter values.
-
-Also see ../watchdog/davinci-wdt.txt for timers that are configurable as
-watchdog timers.
-
-Required properties:
-
-- compatible : should be "ti,da830-timer".
-- reg : specifies base physical address and count of the registers.
-- interrupts : interrupts generated by the timer.
-- interrupt-names: should be "tint12", "tint34", "cmpint0", "cmpint1",
- "cmpint2", "cmpint3", "cmpint4", "cmpint5", "cmpint6",
- "cmpint7" ("cmpintX" may be omitted if not present in the
- hardware).
-- clocks : the clock feeding the timer clock.
-
-Example:
-
- clocksource: timer@20000 {
- compatible = "ti,da830-timer";
- reg = <0x20000 0x1000>;
- interrupts = <21>, <22>, <74>, <75>, <76>, <77>, <78>, <79>,
- <80>, <81>;
- interrupt-names = "tint12", "tint34", "cmpint0", "cmpint1",
- "cmpint2", "cmpint3", "cmpint4", "cmpint5",
- "cmpint6", "cmpint7";
- clocks = <&pll0_auxclk>;
- };
diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
deleted file mode 100644
index d3905a5412b8..000000000000
--- a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Device tree bindings for Texas instruments Keystone timer
-
-This document provides bindings for the 64-bit timer in the KeyStone
-architecture devices. The timer can be configured as a general-purpose 64-bit
-timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
-timers, each half can operate in conjunction (chain mode) or independently
-(unchained mode) of each other.
-
-It is global timer is a free running up-counter and can generate interrupt
-when the counter reaches preset counter values.
-
-Documentation:
-https://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
-
-Required properties:
-
-- compatible : should be "ti,keystone-timer".
-- reg : specifies base physical address and count of the registers.
-- interrupts : interrupt generated by the timer.
-- clocks : the clock feeding the timer clock.
-
-Example:
-
-timer@22f0000 {
- compatible = "ti,keystone-timer";
- reg = <0x022f0000 0x80>;
- interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
- clocks = <&clktimer15>;
-};
diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.yaml b/Documentation/devicetree/bindings/timer/ti,keystone-timer.yaml
new file mode 100644
index 000000000000..1caf5ce64f01
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ti,keystone-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Keystone timer
+
+maintainers:
+ - Alexander A. Klimov <grandmaster@al2klimov.de>
+ - Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
+
+description: >
+ A 64-bit timer in the KeyStone architecture devices. The timer can be
+ configured as a general-purpose 64-bit timer, dual general-purpose 32-bit
+ timers. When configured as dual 32-bit timers, each half can operate in
+ conjunction (chain mode) or independently (unchained mode) of each other.
+
+ It is global timer is a free running up-counter and can generate interrupt
+ when the counter reaches preset counter values.
+
+ Documentation:
+ https://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
+
+properties:
+ compatible:
+ const: ti,keystone-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: irq
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: timer
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ timer@22f0000 {
+ compatible = "ti,keystone-timer";
+ reg = <0x022f0000 0x80>;
+ interrupts = <110 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clktimer15>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml b/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml
index e32df21e63a0..acbb6f8997ee 100644
--- a/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml
+++ b/Documentation/devicetree/bindings/timer/ti,timer-dm.yaml
@@ -51,6 +51,11 @@ properties:
- const: timer_sys_ck
minItems: 1
+ power-domains:
+ description:
+ Power domain if available
+ maxItems: 1
+
interrupts:
description:
Interrupt if available. The timer PWM features may be usable
@@ -94,13 +99,15 @@ additionalProperties: false
allOf:
- if:
- not:
- properties:
- compatible:
- contains:
- const: ti,am654-timer
+ properties:
+ compatible:
+ contains:
+ const: ti,am654-timer
then:
required:
+ - power-domains
+ else:
+ required:
- interrupts
- if:
diff --git a/Documentation/devicetree/bindings/timer/via,vt8500-timer.txt b/Documentation/devicetree/bindings/timer/via,vt8500-timer.txt
deleted file mode 100644
index 901c73f0d8ef..000000000000
--- a/Documentation/devicetree/bindings/timer/via,vt8500-timer.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 Timer
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-timer"
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : interrupt for the timer
-
-Example:
-
- timer@d8130100 {
- compatible = "via,vt8500-timer";
- reg = <0xd8130100 0x28>;
- interrupts = <36>;
- };
diff --git a/Documentation/devicetree/bindings/timer/via,vt8500-timer.yaml b/Documentation/devicetree/bindings/timer/via,vt8500-timer.yaml
new file mode 100644
index 000000000000..e748149948f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/via,vt8500-timer.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/via,vt8500-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/Wondermedia VT8500 Timer
+
+description:
+ This is the timer block that is a standalone part of the system power
+ management controller on VIA/WonderMedia SoCs (VIA VT8500 and alike).
+ The hardware has a single 32-bit counter running at 3 MHz and four match
+ registers, each of which is associated with a dedicated match interrupt,
+ and the first of which can also serve as the system watchdog (if the
+ watchdog function is enabled, it will reset the system upon match instead
+ of triggering its respective interrupt)
+
+maintainers:
+ - Alexey Charkov <alchark@gmail.com>
+
+properties:
+ compatible:
+ const: via,vt8500-timer
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Channel 0 match. Note that if the watchdog function
+ is enabled, this interrupt will not fire and the system will
+ reboot instead once the counter reaches match register 0 value
+ - description: Channel 1 match
+ - description: Channel 2 match
+ - description: Channel 3 match
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@d8130100 {
+ compatible = "via,vt8500-timer";
+ reg = <0xd8130100 0x28>;
+ interrupts = <36>;
+ };
diff --git a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
index dd168d41d2e0..b1597db04263 100644
--- a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timer/xlnx,xps-timer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Xilinx LogiCORE IP AXI Timer Device Tree Binding
+title: Xilinx LogiCORE IP AXI Timer
maintainers:
- Sean Anderson <sean.anderson@seco.com>
diff --git a/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml b/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
index fd6a7b51f571..95f42acd0c54 100644
--- a/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
+++ b/Documentation/devicetree/bindings/timestamp/hardware-timestamps-common.yaml
@@ -17,7 +17,7 @@ description:
properties:
$nodename:
- pattern: "^timestamp(@.*|-[0-9a-f])?$"
+ pattern: "^timestamp(@.*|-([0-9]|[1-9][0-9]+))?$"
"#timestamp-cells":
description:
diff --git a/Documentation/devicetree/bindings/timestamp/hte-consumer.yaml b/Documentation/devicetree/bindings/timestamp/hte-consumer.yaml
index 6456515c3d26..5142d6d4fc0a 100644
--- a/Documentation/devicetree/bindings/timestamp/hte-consumer.yaml
+++ b/Documentation/devicetree/bindings/timestamp/hte-consumer.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timestamp/hte-consumer.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: HTE Consumer Device Tree Bindings
+title: HTE Consumer
maintainers:
- Dipen Patel <dipenp@nvidia.com>
diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index c31e207d1652..456797967adc 100644
--- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
+++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Tegra194 on chip generic hardware timestamping engine (HTE)
+title: Tegra on chip generic hardware timestamping engine (HTE) provider
maintainers:
- Dipen Patel <dipenp@nvidia.com>
@@ -23,6 +23,8 @@ properties:
enum:
- nvidia,tegra194-gte-aon
- nvidia,tegra194-gte-lic
+ - nvidia,tegra234-gte-aon
+ - nvidia,tegra234-gte-lic
reg:
maxItems: 1
@@ -40,12 +42,20 @@ properties:
nvidia,slices:
$ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
description:
HTE lines are arranged in 32 bit slice where each bit represents different
line/signal that it can enable/configure for the timestamp. It is u32
- property and depends on the HTE instance in the chip. The value 3 is for
- GPIO GTE and 11 for IRQ GTE.
- enum: [3, 11]
+ property and the value depends on the HTE instance in the chip. The AON
+ GTE instances for both Tegra194 and Tegra234 has 3 slices. The Tegra194
+ LIC instance has 11 slices and Tegra234 LIC has 17 slices.
+ enum: [3, 11, 17]
+
+ nvidia,gpio-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The phandle to AON gpio controller instance. This is required to handle
+ namespace conversion between GPIO and GTE.
'#timestamp-cells':
description:
@@ -59,9 +69,53 @@ required:
- compatible
- reg
- interrupts
- - nvidia,slices
- "#timestamp-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-gte-aon
+ - nvidia,tegra234-gte-aon
+ then:
+ properties:
+ nvidia,slices:
+ const: 3
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-gte-lic
+ then:
+ properties:
+ nvidia,slices:
+ const: 11
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra234-gte-lic
+ then:
+ properties:
+ nvidia,slices:
+ const: 17
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra234-gte-aon
+ then:
+ required:
+ - nvidia,gpio-controller
+
additionalProperties: false
examples:
@@ -71,7 +125,6 @@ examples:
reg = <0xc1e0000 0x10000>;
interrupts = <0 13 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <3>;
#timestamp-cells = <1>;
};
@@ -81,7 +134,6 @@ examples:
reg = <0x3aa0000 0x10000>;
interrupts = <0 11 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <11>;
#timestamp-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/tpm/google,cr50.yaml b/Documentation/devicetree/bindings/tpm/google,cr50.yaml
new file mode 100644
index 000000000000..9302e12e9fc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/google,cr50.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/google,cr50.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Security Chip H1 (running Cr50 firmware)
+
+maintainers:
+ - Andrey Pronin <apronin@chromium.org>
+
+description: |
+ Google has designed a family of security chips called "Titan".
+ One member is the H1 built into Chromebooks and running Cr50 firmware:
+ https://www.osfc.io/2018/talks/google-secure-microcontroller-and-ccd-closed-case-debugging/
+
+ The chip provides several functions, including TPM 2.0 like functionality.
+ It communicates over SPI or I²C using the FIFO protocol described in the
+ TCG PC Client Platform TPM Profile Specification for TPM 2.0 (PTP), sec 6:
+ https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
+
+properties:
+ compatible:
+ const: google,cr50
+
+allOf:
+ - $ref: tpm-common.yaml#
+
+anyOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - $ref: tcg,tpm-tis-i2c.yaml#/properties/reg
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@0 {
+ reg = <0>;
+ compatible = "google,cr50";
+ spi-max-frequency = <800000>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@50 {
+ compatible = "google,cr50";
+ reg = <0x50>;
+ interrupts-extended = <&pio 88 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cr50_int>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml b/Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml
new file mode 100644
index 000000000000..8b0d3d4be5d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/ibm,vtpm.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/ibm,vtpm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: IBM Virtual Trusted Platform Module (vTPM)
+
+maintainers:
+ - Nayna Jain <nayna@linux.ibm.com>
+
+description: |
+ Virtual TPM is used on IBM POWER7+ and POWER8 systems running POWERVM.
+ It is supported through the adjunct partition with firmware release 740
+ or higher. With vTPM support, each lpar is able to have its own vTPM
+ without the physical TPM hardware. The TPM functionality is provided by
+ communicating with the vTPM adjunct partition through Hypervisor calls
+ (Hcalls) and Command/Response Queue (CRQ) commands.
+
+properties:
+ compatible:
+ enum:
+ - IBM,vtpm
+ - IBM,vtpm20
+
+ device_type:
+ description:
+ type of virtual device
+ enum:
+ - IBM,vtpm
+ - IBM,vtpm20
+
+ reg:
+ maxItems: 1
+
+ ibm,#dma-address-cells:
+ description:
+ number of cells that are used to encode the physical address field of
+ dma-window properties
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ ibm,#dma-size-cells:
+ description:
+ number of cells that are used to encode the size field of
+ dma-window properties
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ ibm,my-dma-window:
+ description:
+ DMA window associated with this virtual I/O Adapter
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 5
+ maxItems: 5
+
+ ibm,my-drc-index:
+ description:
+ integer index for the connector between the device and its parent;
+ present only if Dynamic Reconfiguration (DR) Connector is enabled
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ibm,loc-code:
+ description:
+ unique and persistent location code associated with this virtual
+ I/O Adapter
+ $ref: /schemas/types.yaml#/definitions/string
+
+required:
+ - compatible
+ - device_type
+ - reg
+ - interrupts
+ - ibm,#dma-address-cells
+ - ibm,#dma-size-cells
+ - ibm,my-dma-window
+ - ibm,my-drc-index
+ - ibm,loc-code
+ - linux,sml-base
+ - linux,sml-size
+
+allOf:
+ - $ref: tpm-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@30000003 {
+ compatible = "IBM,vtpm";
+ device_type = "IBM,vtpm";
+ reg = <0x30000003>;
+ interrupts = <0xa0003 0x0>;
+ ibm,#dma-address-cells = <0x2>;
+ ibm,#dma-size-cells = <0x2>;
+ ibm,my-dma-window = <0x10000003 0x0 0x0 0x0 0x10000000>;
+ ibm,my-drc-index = <0x30000003>;
+ ibm,loc-code = "U8286.41A.10082DV-V3-C3";
+ linux,sml-base = <0xc60e 0x0>;
+ linux,sml-size = <0xbce10200>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml b/Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml
new file mode 100644
index 000000000000..fdb81968f03d
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/microsoft,ftpm.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/microsoft,ftpm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microsoft firmware-based Trusted Platform Module (fTPM)
+
+maintainers:
+ - Thirupathaiah Annapureddy <thiruan@microsoft.com>
+ - Sasha Levin <sashal@kernel.org>
+
+description: |
+ Commodity CPU architectures, such as ARM and Intel CPUs, have started to
+ offer trusted computing features in their CPUs aimed at displacing dedicated
+ trusted hardware. Unfortunately, these CPU architectures raise serious
+ challenges to building trusted systems because they omit providing secure
+ resources outside the CPU perimeter.
+
+ Microsoft's firmware-based TPM 2.0 (fTPM) leverages ARM TrustZone to overcome
+ these challenges and provide software with security guarantees similar to
+ those of dedicated trusted hardware.
+
+ https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/
+ https://github.com/Microsoft/ms-tpm-20-ref/tree/main/Samples/ARM32-FirmwareTPM
+
+properties:
+ compatible:
+ const: microsoft,ftpm
+
+required:
+ - compatible
+ - linux,sml-base
+ - linux,sml-size
+
+allOf:
+ - $ref: tpm-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ tpm {
+ compatible = "microsoft,ftpm";
+ linux,sml-base = <0x0 0xc0000000>;
+ linux,sml-size = <0x10000>;
+ };
diff --git a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml
new file mode 100644
index 000000000000..af7720dc4a12
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-i2c.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/tcg,tpm-tis-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I²C-attached Trusted Platform Module conforming to TCG TIS specification
+
+maintainers:
+ - Lukas Wunner <lukas@wunner.de>
+
+description: |
+ The Trusted Computing Group (TCG) has defined a multi-vendor standard
+ for accessing a TPM chip. It can be transported over various buses,
+ one of them being I²C. The standard is named:
+ TCG PC Client Specific TPM Interface Specification (TIS)
+ https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
+
+ The I²C interface was not originally part of the standard, but added
+ in 2017 with a separate document:
+ TCG PC Client Platform TPM Profile Specification for TPM 2.0 (PTP)
+ https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
+
+ Recent TPM 2.0 chips conform to this generic interface, others use a
+ vendor-specific I²C interface.
+
+properties:
+ compatible:
+ oneOf:
+ - description: Generic TPM 2.0 chips conforming to TCG PTP interface
+ items:
+ - enum:
+ - infineon,slb9673
+ - nuvoton,npct75x
+ - st,st33ktpm2xi2c
+ - const: tcg,tpm-tis-i2c
+
+ - description: TPM 1.2 and 2.0 chips with vendor-specific I²C interface
+ items:
+ - enum:
+ - atmel,at97sc3204t # TPM 1.2
+ - infineon,slb9635tt # TPM 1.2 (maximum 100 kHz)
+ - infineon,slb9645tt # TPM 1.2 (maximum 400 kHz)
+ - infineon,tpm_i2c_infineon # TPM 1.2
+ - nuvoton,npct501 # TPM 1.2
+ - nuvoton,npct601 # TPM 2.0
+ - st,st33zp24-i2c # TPM 2.0
+ - winbond,wpct301 # TPM 1.2
+
+ reg:
+ description: address of TPM on the I²C bus
+
+allOf:
+ - $ref: tpm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@57 {
+ label = "tpm";
+ compatible = "nuvoton,npct601";
+ reg = <0x57>;
+ linux,sml-base = <0x7f 0xfd450000>;
+ linux,sml-size = <0x10000>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@13 {
+ reg = <0x13>;
+ compatible = "st,st33zp24-i2c";
+ interrupt-parent = <&gpio5>;
+ interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
+ lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml
new file mode 100644
index 000000000000..87bce0692129
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/tcg,tpm-tis-mmio.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/tcg,tpm-tis-mmio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MMIO-accessed Trusted Platform Module conforming to TCG TIS specification
+
+maintainers:
+ - Lukas Wunner <lukas@wunner.de>
+
+description: |
+ The Trusted Computing Group (TCG) has defined a multi-vendor standard
+ for accessing a TPM chip. It can be transported over various buses,
+ one of them being LPC (via MMIO). The standard is named:
+ TCG PC Client Specific TPM Interface Specification (TIS)
+ https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - at97sc3201
+ - atmel,at97sc3204
+ - socionext,synquacer-tpm-mmio
+ - const: tcg,tpm-tis-mmio
+
+ reg:
+ description:
+ location and length of the MMIO registers, length should be
+ at least 0x5000 bytes
+
+allOf:
+ - $ref: tpm-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ tpm@90000 {
+ compatible = "atmel,at97sc3204", "tcg,tpm-tis-mmio";
+ reg = <0x90000 0x5000>;
+ interrupt-parent = <&EIC0>;
+ interrupts = <1 2>;
+ };
diff --git a/Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml b/Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml
new file mode 100644
index 000000000000..6cb2de7cb568
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/tcg,tpm_tis-spi.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/tcg,tpm_tis-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI-attached Trusted Platform Module conforming to TCG TIS specification
+
+maintainers:
+ - Lukas Wunner <lukas@wunner.de>
+
+description: |
+ The Trusted Computing Group (TCG) has defined a multi-vendor standard
+ for accessing a TPM chip. It can be transported over various buses,
+ one of them being SPI. The standard is named:
+ TCG PC Client Specific TPM Interface Specification (TIS)
+ https://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - atmel,attpm20p
+ - infineon,slb9670
+ - st,st33htpm-spi
+ - st,st33zp24-spi
+ - const: tcg,tpm_tis-spi
+
+allOf:
+ - $ref: tpm-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: st,st33zp24-spi
+ then:
+ properties:
+ spi-max-frequency:
+ maximum: 10000000
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@0 {
+ reg = <0>;
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ spi-max-frequency = <10000000>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@0 {
+ reg = <0>;
+ compatible = "st,st33zp24-spi", "tcg,tpm_tis-spi";
+ spi-max-frequency = <10000000>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
+ lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/tpm/tpm-common.yaml b/Documentation/devicetree/bindings/tpm/tpm-common.yaml
new file mode 100644
index 000000000000..3c1241b2a43f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tpm/tpm-common.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/tpm/tpm-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trusted Platform Module common properties
+
+maintainers:
+ - Lukas Wunner <lukas@wunner.de>
+
+properties:
+ $nodename:
+ pattern: '^tpm(@[0-9a-f]+)?$'
+
+ interrupts:
+ description: indicates command completion
+ maxItems: 1
+
+ label:
+ description: human readable string describing the device, e.g. "tpm"
+
+ linux,sml-base:
+ description:
+ base address of reserved memory allocated for firmware event log
+ $ref: /schemas/types.yaml#/definitions/uint64
+
+ linux,sml-size:
+ description:
+ size of reserved memory allocated for firmware event log
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ memory-region:
+ description: reserved memory allocated for firmware event log
+ maxItems: 1
+
+ powered-while-suspended:
+ description:
+ present when the TPM is left powered on between suspend and resume
+ (makes the suspend/resume callbacks do nothing)
+ type: boolean
+
+ resets:
+ description: Reset controller to reset the TPM
+ maxItems: 1
+
+ reset-gpios:
+ description: Output GPIO pin to reset the TPM
+ maxItems: 1
+
+# must always have both linux,sml-base and linux,sml-size
+dependentRequired:
+ linux,sml-base: ['linux,sml-size']
+ linux,sml-size: ['linux,sml-base']
+
+# must only have either memory-region or linux,sml-base
+# as well as either resets or reset-gpios
+dependentSchemas:
+ memory-region:
+ properties:
+ linux,sml-base: false
+ linux,sml-base:
+ properties:
+ memory-region: false
+ resets:
+ properties:
+ reset-gpios: false
+ reset-gpios:
+ properties:
+ resets: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ pattern: '^st,st33zp24'
+ then:
+ properties:
+ lpcpd-gpios:
+ description:
+ Output GPIO pin used for ST33ZP24 power management of D1/D2 state.
+ If set, power must be present when the platform is going into
+ sleep/hibernate mode.
+ maxItems: 1
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/trigger-source/adi,util-sigma-delta-spi.yaml b/Documentation/devicetree/bindings/trigger-source/adi,util-sigma-delta-spi.yaml
new file mode 100644
index 000000000000..ea466179551c
--- /dev/null
+++ b/Documentation/devicetree/bindings/trigger-source/adi,util-sigma-delta-spi.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2025 Analog Devices, Inc.
+# Copyright (c) 2025 BayLibre, SAS
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/trigger-source/adi,util-sigma-delta-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices Util Sigma-Delta SPI IP Core
+
+maintainers:
+ - David Lechner <dlechner@baylibre.com>
+
+description:
+ The Util Sigma-Delta SPI is an FPGA IP core from Analog Devices that provides
+ a SPI offload trigger from the RDY signal of the combined DOUT/RDY pin of
+ the sigma-delta family of ADCs.
+ https://analogdevicesinc.github.io/hdl/library/util_sigma_delta_spi/index.html
+
+properties:
+ compatible:
+ const: adi,util-sigma-delta-spi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#trigger-source-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#trigger-source-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ trigger@40000 {
+ reg = <0x40000 0x1000>;
+ compatible = "adi,util-sigma-delta-spi";
+ clocks = <&clk 0>;
+ #trigger-source-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml b/Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml
new file mode 100644
index 000000000000..1331d153ee82
--- /dev/null
+++ b/Documentation/devicetree/bindings/trigger-source/gpio-trigger.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/trigger-source/gpio-trigger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic trigger source using GPIO
+
+description: A GPIO used as a trigger source.
+
+maintainers:
+ - Jonathan Santos <Jonathan.Santos@analog.com>
+
+properties:
+ compatible:
+ const: gpio-trigger
+
+ '#trigger-source-cells':
+ const: 0
+
+ gpios:
+ maxItems: 1
+ description: GPIO to be used as a trigger source.
+
+required:
+ - compatible
+ - '#trigger-source-cells'
+ - gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ trigger {
+ compatible = "gpio-trigger";
+ #trigger-source-cells = <0>;
+ gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml b/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml
new file mode 100644
index 000000000000..1eac20031dc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/trigger-source/pwm-trigger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic trigger source using PWM
+
+description: Remaps a PWM channel as a trigger source.
+
+maintainers:
+ - David Lechner <dlechner@baylibre.com>
+
+properties:
+ compatible:
+ const: pwm-trigger
+
+ '#trigger-source-cells':
+ const: 0
+
+ pwms:
+ maxItems: 1
+
+required:
+ - compatible
+ - '#trigger-source-cells'
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ trigger {
+ compatible = "pwm-trigger";
+ #trigger-source-cells = <0>;
+ pwms = <&pwm 0 1000000 0>;
+ };
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 61746755c107..d0f7dbf15d6f 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/trivial-devices.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Trivial I2C and SPI devices that have simple device tree bindings
+title: Trivial I2C and SPI devices
maintainers:
- Rob Herring <robh@kernel.org>
@@ -28,55 +28,65 @@ properties:
compatible:
items:
+ # Entries are sorted alphanumerically by the compatible
- enum:
+ # ABB register based spi sensors
+ - abb,spi-sensor
+ # Acbel fsg032 power supply
+ - acbel,fsg032
# SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin
- - ad,ad7414
+ - ad,ad7414 # Deprecated, use adi,ad7414
+ - adi,ad7414
# ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
- ad,adm9240
# AD5110 - Nonvolatile Digital Potentiometer
- adi,ad5110
- # Analog Devices ADP5585 Keypad Decoder and I/O Expansion
- - adi,adp5585
- # Analog Devices ADP5585 Keypad Decoder and I/O Expansion with support for Row5
- - adi,adp5585-02
- # Analog Devices ADP5589 Keypad Decoder and I/O Expansion
- - adi,adp5589
+ # Temperature sensor with integrated fan control
+ - adi,adm1027
+ # Analog Devices ADT7410 High Accuracy Digital Temperature Sensor
+ - adi,adt7410
+ # Analog Devices ADT7411 Temperature Sensor and 8-channel ADC
+ - adi,adt7411
+ # Analog Devices ADT7420 High Accuracy Digital Temperature Sensor
+ - adi,adt7420
+ # Analog Devices ADT7422 High Accuracy Digital Temperature Sensor
+ - adi,adt7422
+ # Temperature sensor with integrated fan control
+ - adi,adt7463
+ # Temperature sensor with integrated fan control
+ - adi,adt7468
# Analog Devices LT7182S Dual Channel 6A, 20V PolyPhase Step-Down Silent Switcher
- adi,lt7182s
# AMS iAQ-Core VOC Sensor
- ams,iaq-core
- # i2c serial eeprom (24cxx)
- - at,24c08
- # i2c trusted platform module (TPM)
- - atmel,at97sc3204t
+ # Arduino microcontroller interface over SPI on UnoQ board
+ - arduino,unoq-mcu
+ # Temperature monitoring of Astera Labs PT5161L PCIe retimer
+ - asteralabs,pt5161l
+ # i2c h/w elliptic curve crypto module
+ - atmel,atecc508a
# ATSHA204 - i2c h/w symmetric crypto module
- atmel,atsha204
# ATSHA204A - i2c h/w symmetric crypto module
- atmel,atsha204a
- # i2c h/w elliptic curve crypto module
- - atmel,atecc508a
# BPA-RS600: Power Supply
- blutek,bpa-rs600
- # Bosch Sensortec pressure, temperature, humididty and VOC sensor
- - bosch,bme680
# CM32181: Ambient Light Sensor
- capella,cm32181
# CM3232: Ambient Light Sensor
- capella,cm3232
# CM3323: Ambient Light Sensor
- capella,cm3323
+ # Cisco SPI Petra
+ - cisco,spi-petra
# High-Precision Digital Thermometer
- dallas,ds1631
# Total-Elapsed-Time Recorder with Alarm
- dallas,ds1682
- # Tiny Digital Thermometer and Thermostat
- - dallas,ds1775
# CPU Peripheral Monitor
- dallas,ds1780
# CPU Supervisor with Nonvolatile Memory and Programmable I/O
- dallas,ds4510
- # Digital Thermometer and Thermostat
- - dallas,ds75
# Delta AHE-50DC Open19 power shelf fan control module
- delta,ahe50dc-fan
# Delta Electronics DPS-650-AB power supply
@@ -91,6 +101,8 @@ properties:
- devantech,srf08
# Devantech SRF10 ultrasonic ranger
- devantech,srf10
+ # DFRobot SEN0322 oxygen sensor
+ - dfrobot,sen0322
# DH electronics GmbH on-board CPLD trivial SPI device
- dh,dhcom-board
# DA9053: flexible system level PMIC with multicore support
@@ -109,14 +121,8 @@ properties:
- fsl,mma7660
# MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
- fsl,mma8450
- # MPL3115: Absolute Digital Pressure Sensor
- - fsl,mpl3115
# MPR121: Proximity Capacitive Touch Sensor Controller
- fsl,mpr121
- # Monolithic Power Systems Inc. multi-phase controller mp2888
- - mps,mp2888
- # Monolithic Power Systems Inc. multi-phase controller mp2975
- - mps,mp2975
# Honeywell Humidicon HIH-6130 humidity/temperature sensor
- honeywell,hi6130
# IBM Common Form Factor Power Supply Versions (all versions)
@@ -125,24 +131,14 @@ properties:
- ibm,cffps1
# IBM Common Form Factor Power Supply Versions 2
- ibm,cffps2
+ # IBM On-Chip Controller hwmon device
+ - ibm,p8-occ-hwmon
# Infineon IR36021 digital POL buck controller
- infineon,ir36021
- # Infineon IR38060 Voltage Regulator
- - infineon,ir38060
- # Infineon IR38064 Voltage Regulator
- - infineon,ir38064
- # Infineon IR38164 Voltage Regulator
- - infineon,ir38164
- # Infineon IR38263 Voltage Regulator
- - infineon,ir38263
- # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
- - infineon,slb9635tt
- # Infineon SLB9645 I2C TPM (new protocol, max 400khz)
- - infineon,slb9645tt
- # Infineon SLB9673 I2C TPM 2.0
- - infineon,slb9673
- # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
- - infineon,tlv493d-a1b6
+ # Infineon IRPS5401 Voltage Regulator (PMIC)
+ - infineon,irps5401
+ # Infineon Hot-swap controller xdp710
+ - infineon,xdp710
# Infineon Multi-phase Digital VR Controller xdpe11280
- infineon,xdpe11280
# Infineon Multi-phase Digital VR Controller xdpe12254
@@ -161,14 +157,22 @@ properties:
- injoinic,ip5207
# Injoinic IP5209 2.4A Power Bank IC with I2C
- injoinic,ip5209
+ # Injoinic IP5306 2.1A Power Bank IC with I2C option
+ - injoinic,ip5306
# Inspur Power System power supply unit version 1
- inspur,ipsps1
+ # Intel common redudant power supply crps185
+ - intel,crps185
# Intersil ISL29028 Ambient Light and Proximity Sensor
- isil,isl29028
# Intersil ISL29030 Ambient Light and Proximity Sensor
- isil,isl29030
- # Intersil ISL68137 Digital Output Configurable PWM Controller
- - isil,isl68137
+ # Intersil ISL76682 Ambient Light Sensor
+ - isil,isl76682
+ # JEDEC JESD300 (SPD5118) Hub and Serial Presence Detect
+ - jedec,spd5118
+ # Linear Technology LTC2488
+ - lineartechnology,ltc2488
# 5 Bit Programmable, Pulse-Width Modulator
- maxim,ds1050
# 10 kOhm digital potentiometer with I2C interface
@@ -179,28 +183,36 @@ properties:
- maxim,ds1803-100
# 10 kOhm digital potentiometer with I2C interface
- maxim,ds3502
- # Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
- - maxim,max1237
# Temperature Sensor, I2C interface
- maxim,max1619
- # 10-bit 10 kOhm linear programable voltage divider
+ # Digital temperature sensor with 0.1°C accuracy
+ - maxim,max30208
+ # 3-Channel Remote Temperature Sensor
+ - maxim,max31730
+ # 10-bit 10 kOhm linear programmable voltage divider
- maxim,max5481
- # 10-bit 50 kOhm linear programable voltage divider
+ # 10-bit 50 kOhm linear programmable voltage divider
- maxim,max5482
- # 10-bit 10 kOhm linear programable variable resistor
+ # 10-bit 10 kOhm linear programmable variable resistor
- maxim,max5483
- # 10-bit 50 kOhm linear programable variable resistor
+ # 10-bit 50 kOhm linear programmable variable resistor
- maxim,max5484
# PECI-to-I2C translator for PECI-to-SMBus/I2C protocol conversion
- maxim,max6621
- # 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
- - maxim,max6625
- # 3-Channel Remote Temperature Sensor
- - maxim,max31730
+ # InTune Automatically Compensated Digital PoL Controller with Driver and PMBus Telemetry
+ - maxim,max15301
+ # 6A InTune Automatically Compensated Converter with PMBus Telemetry
+ - maxim,max15303
+ # Multiphase Master with PMBus Interface and Internal Buck Converter
+ - maxim,max20751
# mCube 3-axis 8-bit digital accelerometer
- mcube,mc3230
+ # mCube 3-axis 8-bit digital accelerometer
+ - mcube,mc3510c
# Measurement Specialities I2C temperature and humidity sensor
- meas,htu21
+ # Measurement Specialities I2C temperature and humidity sensor
+ - meas,htu31
# Measurement Specialities I2C pressure and temperature sensor
- meas,ms5637
# Measurement Specialities I2C pressure and temperature sensor
@@ -218,7 +230,7 @@ properties:
# MEMSIC magnetometer
- memsic,mmc35240
# MEMSIC 3-axis accelerometer
- - memsic,mx4005
+ - memsic,mxc4005
# MEMSIC 2-axis 8-bit digital accelerometer
- memsic,mxc6225
# MEMSIC 2-axis 8-bit digital accelerometer
@@ -243,79 +255,136 @@ properties:
- microchip,mcp3427
# Microchip differential I2C ADC, 4 Channel, 16 bit
- microchip,mcp3428
- # Microchip 7-bit Single I2C Digital POT (5k)
- - microchip,mcp4017-502
# Microchip 7-bit Single I2C Digital POT (10k)
- microchip,mcp4017-103
- # Microchip 7-bit Single I2C Digital POT (50k)
- - microchip,mcp4017-503
# Microchip 7-bit Single I2C Digital POT (100k)
- microchip,mcp4017-104
# Microchip 7-bit Single I2C Digital POT (5k)
- - microchip,mcp4018-502
+ - microchip,mcp4017-502
+ # Microchip 7-bit Single I2C Digital POT (50k)
+ - microchip,mcp4017-503
# Microchip 7-bit Single I2C Digital POT (10k)
- microchip,mcp4018-103
- # Microchip 7-bit Single I2C Digital POT (50k)
- - microchip,mcp4018-503
# Microchip 7-bit Single I2C Digital POT (100k)
- microchip,mcp4018-104
# Microchip 7-bit Single I2C Digital POT (5k)
- - microchip,mcp4019-502
+ - microchip,mcp4018-502
+ # Microchip 7-bit Single I2C Digital POT (50k)
+ - microchip,mcp4018-503
# Microchip 7-bit Single I2C Digital POT (10k)
- microchip,mcp4019-103
- # Microchip 7-bit Single I2C Digital POT (50k)
- - microchip,mcp4019-503
# Microchip 7-bit Single I2C Digital POT (100k)
- microchip,mcp4019-104
+ # Microchip 7-bit Single I2C Digital POT (5k)
+ - microchip,mcp4019-502
+ # Microchip 7-bit Single I2C Digital POT (50k)
+ - microchip,mcp4019-503
# PWM Fan Speed Controller With Fan Fault Detection
- microchip,tc654
# PWM Fan Speed Controller With Fan Fault Detection
- microchip,tc655
+ # Micron SPI NOR Authenta
+ - micron,spi-authenta
# MiraMEMS DA226 2-axis 14-bit digital accelerometer
- miramems,da226
# MiraMEMS DA280 3-axis 14-bit digital accelerometer
- miramems,da280
# MiraMEMS DA311 3-axis 12-bit digital accelerometer
- miramems,da311
+ # Monolithic Power Systems Inc. multi-phase controller mp2856
+ - mps,mp2856
+ # Monolithic Power Systems Inc. multi-phase controller mp2857
+ - mps,mp2857
+ # Monolithic Power Systems Inc. multi-phase controller mp2869
+ - mps,mp2869
+ # Monolithic Power Systems Inc. multi-phase controller mp2888
+ - mps,mp2888
+ # Monolithic Power Systems Inc. multi-phase controller mp2891
+ - mps,mp2891
+ # Monolithic Power Systems Inc. multi-phase controller mp2925
+ - mps,mp2925
+ # Monolithic Power Systems Inc. multi-phase controller mp2929
+ - mps,mp2929
+ # Monolithic Power Systems Inc. multi-phase controller mp29502
+ - mps,mp29502
+ # Monolithic Power Systems Inc. multi-phase controller mp29608
+ - mps,mp29608
+ # Monolithic Power Systems Inc. multi-phase controller mp29612
+ - mps,mp29612
+ # Monolithic Power Systems Inc. multi-phase controller mp29816
+ - mps,mp29816
+ # Monolithic Power Systems Inc. multi-phase controller mp2993
+ - mps,mp2993
+ # Monolithic Power Systems Inc. hot-swap protection device
+ - mps,mp5023
+ # Monolithic Power Systems Inc. multi-phase hot-swap controller mp5920
+ - mps,mp5920
+ # Monolithic Power Systems Inc. multi-phase hot-swap controller mp5990
+ - mps,mp5990
+ # Monolithic Power Systems Inc. multi-phase hot-swap controller mp5998
+ - mps,mp5998
+ # Monolithic Power Systems Inc. digital step-down converter mp9941
+ - mps,mp9941
+ # Monolithic Power Systems Inc. digital step-down converter mp9945
+ - mps,mp9945
# Temperature sensor with integrated fan control
- national,lm63
- # I2C TEMP SENSOR
- - national,lm75
+ # Temperature sensor with integrated fan control
+ - national,lm64
+ # Temperature sensor
+ - national,lm95235
+ # Temperature sensor
+ - national,lm95245
+ # Temperature sensor with integrated fan control
+ - national,lm96163
# Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
- national,lm80
# Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
- national,lm81
# Temperature sensor with integrated fan control
- national,lm85
+ # Temperature sensor with integrated fan control
+ - national,lm85b
+ # Temperature sensor with integrated fan control
+ - national,lm85c
# I2C ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator
- national,lm92
- # i2c trusted platform module (TPM)
- - nuvoton,npct501
- # i2c trusted platform module (TPM2)
- - nuvoton,npct601
# Nuvoton Temperature Sensor
- nuvoton,w83773g
+ # NXP ISP1301 USB transceiver
+ - nxp,isp1301
# OKI ML86V7667 video decoder
- oki,ml86v7667
- # OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus
- - ovti,ov5642
+ # ON Semiconductor ADT7462 Temperature, Voltage Monitor and Fan Controller
+ - onnn,adt7462
# 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
- plx,pex8648
# Pulsedlight LIDAR range-finding sensor
- pulsedlight,lidar-lite-v2
+ # Renesas HS3001 Temperature and Relative Humidity Sensors
+ - renesas,hs3001
# Renesas ISL29501 time-of-flight sensor
- renesas,isl29501
+ # Rohm BH2228FV 8 channel DAC
+ - rohm,bh2228fv
+ # Rohm DH2228FV - This device does not exist, use rohm,bh2228fv instead.
+ - rohm,dh2228fv
# S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
- samsung,24ad0xd1
# Samsung Exynos SoC SATA PHY I2C device
- samsung,exynos-sataphy-i2c
- # Sensirion low power multi-pixel gas sensor with I2C interface
- - sensirion,sgpc3
+ # Semtech sx1301 baseband processor
+ - semtech,sx1301
# Sensirion multi-pixel gas sensor with I2C interface
- sensirion,sgp30
# Sensirion gas sensor with I2C interface
- sensirion,sgp40
+ # Sensirion low power multi-pixel gas sensor with I2C interface
+ - sensirion,sgpc3
# Sensirion temperature & humidity sensor with I2C interface
+ - sensirion,sht20
+ - sensirion,sht21
+ - sensirion,sht25
- sensirion,sht4x
# Sensortek 3 axis accelerometer
- sensortek,stk8312
@@ -323,20 +392,52 @@ properties:
- sensortek,stk8ba50
# SGX Sensortech VZ89X Sensors
- sgx,vz89x
+ # SGX Sensortech VZ89TE Sensors
+ - sgx,vz89te
+ # Silicon Labs EM3581 Zigbee SoC with SPI interface
+ - silabs,em3581
+ # Silicon Labs SI3210 Programmable CMOS SLIC/CODEC with SPI interface
+ - silabs,si3210
+ # Relative Humidity and Temperature Sensors
+ - silabs,si7005
# Relative Humidity and Temperature Sensors
- silabs,si7020
# Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
- skyworks,sky81452
- # Socionext SynQuacer TPM MMIO module
- - socionext,synquacer-tpm-mmio
+ # Temperature sensor with integrated fan control
+ - smsc,emc6d100
+ # Temperature sensor with integrated fan control
+ - smsc,emc6d101
+ # Temperature sensor with integrated fan control
+ - smsc,emc6d102
+ # Temperature sensor with integrated fan control
+ - smsc,emc6d103
+ # Temperature sensor with integrated fan control
+ - smsc,emc6d103s
# SparkFun Qwiic Joystick (COM-15168) with i2c interface
- sparkfun,qwiic-joystick
- # i2c serial eeprom (24cxx)
- - st,24c256
+ # Sierra Wireless mangOH Green SPI IoT interface
+ - swir,mangoh-iotport-spi
+ # Synaptics I2C touchpad
+ - synaptics,synaptics_i2c
# Ambient Light Sensor with SMBUS/Two Wire Serial Interface
- taos,tsl2550
- # Temperature Monitoring and Fan Control
- - ti,amc6821
+ # Digital PWM System Controller PMBus
+ - ti,cd9200
+ # Digital PWM System Controller PMBus
+ - ti,cd9220
+ # Digital PWM System Controller PMBus
+ - ti,cd9222
+ # Digital PWM System Controller PMBus
+ - ti,cd9224
+ # Digital PWM System Controller PMBus
+ - ti,cd9240
+ # Digital PWM System Controller PMBus
+ - ti,cd9244
+ # Digital PWM System Controller PMBus
+ - ti,cd9246
+ # Digital PWM System Controller PMBus
+ - ti,cd9248
# Temperature and humidity sensor with i2c interface
- ti,hdc1000
# Temperature and humidity sensor with i2c interface
@@ -356,22 +457,26 @@ properties:
- ti,lm74
# Temperature sensor with integrated fan control
- ti,lm96000
- # I2C Touch-Screen Controller
- - ti,tsc2003
# Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
- ti,tmp103
# Thermometer with SPI interface
- ti,tmp121
- ti,tmp122
- ti,tmp125
- # Digital Temperature Sensor
- - ti,tmp275
# TI DC-DC converter on PMBus
- ti,tps40400
+ # TI DCAP+ multiphase controller
+ - ti,tps53647
+ # TI DCAP+ multiphase controller
+ - ti,tps53667
# TI Dual channel DCAP+ multiphase controller TPS53676 with AVSBus
- ti,tps53676
# TI Dual channel DCAP+ multiphase controller TPS53679
- ti,tps53679
+ # TI Dual channel DCAP+ multiphase controller TPS53681
+ - ti,tps53681
+ # TI Dual channel DCAP+ multiphase controller TPS53685 with AMD-SVI3
+ - ti,tps53685
# TI Dual channel DCAP+ multiphase controller TPS53688
- ti,tps53688
# TI DC-DC converters on PMBus
@@ -379,12 +484,12 @@ properties:
- ti,tps544b25
- ti,tps544c20
- ti,tps544c25
+ - ti,tps546b24
+ - ti,tps546d24
+ # I2C Touch-Screen Controller
+ - ti,tsc2003
# Winbond/Nuvoton H/W Monitor
- winbond,w83793
- # Vicor Corporation Digital Supervisor
- - vicor,pli1209bc
- # i2c trusted platform module (TPM)
- - winbond,wpct301
required:
- compatible
diff --git a/Documentation/devicetree/bindings/ufs/amd,versal2-ufs.yaml b/Documentation/devicetree/bindings/ufs/amd,versal2-ufs.yaml
new file mode 100644
index 000000000000..c00ec342d574
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/amd,versal2-ufs.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/amd,versal2-ufs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD Versal Gen 2 UFS Host Controller
+
+maintainers:
+ - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+allOf:
+ - $ref: ufs-common.yaml
+
+properties:
+ compatible:
+ const: amd,versal2-ufs
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: core
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: host
+ - const: phy
+
+required:
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ ufs@f10b0000 {
+ compatible = "amd,versal2-ufs";
+ reg = <0xf10b0000 0x1000>;
+ clocks = <&ufs_core_clk>;
+ clock-names = "core";
+ resets = <&scmi_reset 4>, <&scmi_reset 35>;
+ reset-names = "host", "phy";
+ interrupts = <GIC_SPI 234 IRQ_TYPE_LEVEL_HIGH>;
+ freq-table-hz = <0 0>;
+ };
diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml
index fb45f66d6454..835e17269d2d 100644
--- a/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml
+++ b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml
@@ -49,6 +49,8 @@ properties:
reg:
maxItems: 1
+ dma-coherent: true
+
required:
- compatible
- clocks
diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
index 32fd535a514a..15c347f5e660 100644
--- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
@@ -7,23 +7,23 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mediatek Universal Flash Storage (UFS) Controller
maintainers:
- - Stanley Chu <stanley.chu@mediatek.com>
-
-allOf:
- - $ref: ufs-common.yaml
+ - Peter Wang <peter.wang@mediatek.com>
+ - Chaotian Jing <chaotian.jing@mediatek.com>
properties:
compatible:
enum:
- mediatek,mt8183-ufshci
- mediatek,mt8192-ufshci
+ - mediatek,mt8195-ufshci
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 8
clock-names:
- items:
- - const: ufs
+ minItems: 1
+ maxItems: 8
phys:
maxItems: 1
@@ -33,6 +33,10 @@ properties:
vcc-supply: true
+ mediatek,ufs-disable-mcq:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: The mask to disable MCQ (Multi-Circular Queue) for UFS host.
+
required:
- compatible
- clocks
@@ -43,6 +47,37 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: ufs-common.yaml
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8195-ufshci
+ then:
+ properties:
+ clocks:
+ minItems: 8
+ clock-names:
+ items:
+ - const: ufs
+ - const: ufs_aes
+ - const: ufs_tick
+ - const: unipro_sysclk
+ - const: unipro_tick
+ - const: unipro_mp_bclk
+ - const: ufs_tx_symbol
+ - const: ufs_mem_sub
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: ufs
+
examples:
- |
#include <dt-bindings/clock/mt8183-clk.h>
diff --git a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
new file mode 100644
index 000000000000..d94ef4e6b85a
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
@@ -0,0 +1,167 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/qcom,sc7180-ufshc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SC7180 and Other SoCs UFS Controllers
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+# Select only our matches, not all jedec,ufs-2.0
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8998-ufshc
+ - qcom,qcs8300-ufshc
+ - qcom,sa8775p-ufshc
+ - qcom,sc7180-ufshc
+ - qcom,sc7280-ufshc
+ - qcom,sc8180x-ufshc
+ - qcom,sc8280xp-ufshc
+ - qcom,sm8250-ufshc
+ - qcom,sm8350-ufshc
+ - qcom,sm8450-ufshc
+ - qcom,sm8550-ufshc
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,msm8998-ufshc
+ - qcom,qcs8300-ufshc
+ - qcom,sa8775p-ufshc
+ - qcom,sc7180-ufshc
+ - qcom,sc7280-ufshc
+ - qcom,sc8180x-ufshc
+ - qcom,sc8280xp-ufshc
+ - qcom,sm8250-ufshc
+ - qcom,sm8350-ufshc
+ - qcom,sm8450-ufshc
+ - qcom,sm8550-ufshc
+ - const: qcom,ufshc
+ - const: jedec,ufs-2.0
+
+ reg:
+ maxItems: 1
+
+ reg-names:
+ items:
+ - const: std
+
+ clocks:
+ minItems: 7
+ maxItems: 8
+
+ clock-names:
+ minItems: 7
+ items:
+ - const: core_clk
+ - const: bus_aggr_clk
+ - const: iface_clk
+ - const: core_clk_unipro
+ - const: ref_clk
+ - const: tx_lane0_sync_clk
+ - const: rx_lane0_sync_clk
+ - const: rx_lane1_sync_clk
+
+ qcom,ice:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the Inline Crypto Engine node
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: qcom,ufs-common.yaml
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7180-ufshc
+ then:
+ properties:
+ clocks:
+ maxItems: 7
+ clock-names:
+ maxItems: 7
+ else:
+ properties:
+ clocks:
+ minItems: 8
+ clock-names:
+ minItems: 8
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,sm8450.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ufs@1d84000 {
+ compatible = "qcom,sm8450-ufshc", "qcom,ufshc",
+ "jedec,ufs-2.0";
+ reg = <0x0 0x01d84000 0x0 0x3000>;
+ interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&ufs_mem_phy_lanes>;
+ phy-names = "ufsphy";
+ lanes-per-direction = <2>;
+ #reset-cells = <1>;
+ resets = <&gcc GCC_UFS_PHY_BCR>;
+ reset-names = "rst";
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l7b_2p5>;
+ vcc-max-microamp = <1100000>;
+ vccq-supply = <&vreg_l9b_1p2>;
+ vccq-max-microamp = <1200000>;
+
+ power-domains = <&gcc UFS_PHY_GDSC>;
+ iommus = <&apps_smmu 0xe0 0x0>;
+ interconnects = <&aggre1_noc MASTER_UFS_MEM &mc_virt SLAVE_EBI1>,
+ <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_UFS_MEM_CFG>;
+ interconnect-names = "ufs-ddr", "cpu-ufs";
+
+ clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>,
+ <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+ clock-names = "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "rx_lane1_sync_clk";
+ freq-table-hz = <75000000 300000000>,
+ <0 0>,
+ <0 0>,
+ <75000000 300000000>,
+ <75000000 300000000>,
+ <0 0>,
+ <0 0>,
+ <0 0>;
+ qcom,ice = <&ice>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
new file mode 100644
index 000000000000..cea84ab2204f
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/qcom,sm8650-ufshc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8650 and Other SoCs UFS Controllers
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+# Select only our matches, not all jedec,ufs-2.0
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,kaanapali-ufshc
+ - qcom,sm8650-ufshc
+ - qcom,sm8750-ufshc
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,kaanapali-ufshc
+ - qcom,sm8650-ufshc
+ - qcom,sm8750-ufshc
+ - const: qcom,ufshc
+ - const: jedec,ufs-2.0
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: std
+ - const: mcq
+
+ clocks:
+ minItems: 8
+ maxItems: 8
+
+ clock-names:
+ items:
+ - const: core_clk
+ - const: bus_aggr_clk
+ - const: iface_clk
+ - const: core_clk_unipro
+ - const: ref_clk
+ - const: tx_lane0_sync_clk
+ - const: rx_lane0_sync_clk
+ - const: rx_lane1_sync_clk
+
+ qcom,ice:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the Inline Crypto Engine node
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: qcom,ufs-common.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8650-gcc.h>
+ #include <dt-bindings/clock/qcom,sm8650-tcsr.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8650-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ufshc@1d84000 {
+ compatible = "qcom,sm8650-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
+ reg = <0x0 0x01d84000 0x0 0x3000>;
+
+ interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>,
+ <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
+ <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+ clock-names = "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "rx_lane1_sync_clk";
+
+ resets = <&gcc GCC_UFS_PHY_BCR>;
+ reset-names = "rst";
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+
+ interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "ufs-ddr",
+ "cpu-ufs";
+
+ power-domains = <&gcc UFS_PHY_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
+
+ operating-points-v2 = <&ufs_opp_table>;
+
+ iommus = <&apps_smmu 0x60 0>;
+
+ lanes-per-direction = <2>;
+ qcom,ice = <&ice>;
+
+ phys = <&ufs_mem_phy>;
+ phy-names = "ufsphy";
+
+ #reset-cells = <1>;
+
+ vcc-supply = <&vreg_l7b_2p5>;
+ vcc-max-microamp = <1100000>;
+ vccq-supply = <&vreg_l9b_1p2>;
+ vccq-max-microamp = <1200000>;
+
+ ufs_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <100000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-201500000 {
+ opp-hz = /bits/ 64 <201500000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <201500000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-403000000 {
+ opp-hz = /bits/ 64 <403000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <403000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs-common.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs-common.yaml
new file mode 100644
index 000000000000..962dffcd28b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs-common.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/qcom,ufs-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Universal Flash Storage (UFS) Controller Common Properties
+
+maintainers:
+ - Bjorn Andersson <bjorn.andersson@linaro.org>
+
+properties:
+ clocks:
+ minItems: 7
+ maxItems: 9
+
+ clock-names:
+ minItems: 7
+ maxItems: 9
+
+ dma-coherent: true
+
+ interconnects:
+ minItems: 2
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ufs-ddr
+ - const: cpu-ufs
+
+ iommus:
+ minItems: 1
+ maxItems: 2
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ items:
+ - const: ufsphy
+
+ power-domains:
+ maxItems: 1
+
+ required-opps:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+ reset-names:
+ items:
+ - const: rst
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the RESET pin of the UFS memory device.
+
+allOf:
+ - $ref: ufs-common.yaml
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index f2d6298d926c..516bb61a4624 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -15,7 +15,15 @@ select:
properties:
compatible:
contains:
- const: qcom,ufshc
+ enum:
+ - qcom,msm8994-ufshc
+ - qcom,msm8996-ufshc
+ - qcom,qcs615-ufshc
+ - qcom,sdm845-ufshc
+ - qcom,sm6115-ufshc
+ - qcom,sm6125-ufshc
+ - qcom,sm6350-ufshc
+ - qcom,sm8150-ufshc
required:
- compatible
@@ -25,89 +33,48 @@ properties:
- enum:
- qcom,msm8994-ufshc
- qcom,msm8996-ufshc
- - qcom,msm8998-ufshc
- - qcom,sc8280xp-ufshc
+ - qcom,qcs615-ufshc
- qcom,sdm845-ufshc
+ - qcom,sm6115-ufshc
+ - qcom,sm6125-ufshc
- qcom,sm6350-ufshc
- qcom,sm8150-ufshc
- - qcom,sm8250-ufshc
- - qcom,sm8350-ufshc
- - qcom,sm8450-ufshc
- const: qcom,ufshc
- const: jedec,ufs-2.0
- clocks:
- minItems: 8
- maxItems: 11
-
- clock-names:
- minItems: 8
- maxItems: 11
-
- interconnects:
- minItems: 2
- maxItems: 2
-
- interconnect-names:
- items:
- - const: ufs-ddr
- - const: cpu-ufs
-
- iommus:
- minItems: 1
- maxItems: 2
-
- phys:
- maxItems: 1
-
- phy-names:
- items:
- - const: ufsphy
-
- power-domains:
- maxItems: 1
+ qcom,ice:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the Inline Crypto Engine node
reg:
minItems: 1
maxItems: 2
- resets:
- maxItems: 1
-
- '#reset-cells':
- const: 1
-
- reset-names:
+ reg-names:
items:
- - const: rst
-
- reset-gpios:
- maxItems: 1
- description:
- GPIO connected to the RESET pin of the UFS memory device.
+ - const: std
+ - const: ice
required:
- compatible
- reg
allOf:
- - $ref: ufs-common.yaml
+ - $ref: qcom,ufs-common.yaml
- if:
properties:
compatible:
contains:
enum:
- - qcom,msm8998-ufshc
- - qcom,sc8280xp-ufshc
- - qcom,sm8250-ufshc
- - qcom,sm8350-ufshc
- - qcom,sm8450-ufshc
+ - qcom,sdm845-ufshc
+ - qcom,sm6350-ufshc
+ - qcom,sm8150-ufshc
then:
properties:
clocks:
- minItems: 8
- maxItems: 8
+ minItems: 9
+ maxItems: 9
clock-names:
items:
- const: core_clk
@@ -118,18 +85,20 @@ allOf:
- const: tx_lane0_sync_clk
- const: rx_lane0_sync_clk
- const: rx_lane1_sync_clk
+ - const: ice_core_clk
reg:
- minItems: 1
- maxItems: 1
+ minItems: 2
+ reg-names:
+ minItems: 2
+ required:
+ - reg-names
- if:
properties:
compatible:
contains:
enum:
- - qcom,sdm845-ufshc
- - qcom,sm6350-ufshc
- - qcom,sm8150-ufshc
+ - qcom,msm8996-ufshc
then:
properties:
clocks:
@@ -138,56 +107,78 @@ allOf:
clock-names:
items:
- const: core_clk
+ - const: bus_clk
- const: bus_aggr_clk
- const: iface_clk
- const: core_clk_unipro
+ - const: core_clk_ice
- const: ref_clk
- const: tx_lane0_sync_clk
- const: rx_lane0_sync_clk
- - const: rx_lane1_sync_clk
- - const: ice_core_clk
reg:
- minItems: 2
- maxItems: 2
+ maxItems: 1
+ reg-names:
+ maxItems: 1
- if:
properties:
compatible:
contains:
enum:
- - qcom,msm8996-ufshc
+ - qcom,qcs615-ufshc
+ - qcom,sm6115-ufshc
+ - qcom,sm6125-ufshc
then:
properties:
clocks:
- minItems: 11
- maxItems: 11
+ minItems: 8
+ maxItems: 8
clock-names:
items:
- - const: core_clk_src
- const: core_clk
- - const: bus_clk
- const: bus_aggr_clk
- const: iface_clk
- - const: core_clk_unipro_src
- const: core_clk_unipro
- - const: core_clk_ice
- const: ref_clk
- const: tx_lane0_sync_clk
- const: rx_lane0_sync_clk
+ - const: ice_core_clk
reg:
- minItems: 1
- maxItems: 1
+ minItems: 2
+ reg-names:
+ minItems: 2
+ required:
+ - reg-names
# TODO: define clock bindings for qcom,msm8994-ufshc
+ - if:
+ required:
+ - qcom,ice
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ clocks:
+ minItems: 7
+ maxItems: 8
+ else:
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 2
+ clocks:
+ minItems: 7
+ maxItems: 9
+
unevaluatedProperties: false
examples:
- |
- #include <dt-bindings/clock/qcom,gcc-sm8450.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8150.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interconnect/qcom,sm8450.h>
+ #include <dt-bindings/interconnect/qcom,sm8150.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
soc {
@@ -195,9 +186,12 @@ examples:
#size-cells = <2>;
ufs@1d84000 {
- compatible = "qcom,sm8450-ufshc", "qcom,ufshc",
+ compatible = "qcom,sm8150-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
- reg = <0 0x01d84000 0 0x3000>;
+ reg = <0x0 0x01d84000 0x0 0x2500>,
+ <0x0 0x01d90000 0x0 0x8000>;
+ reg-names = "std", "ice";
+
interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
phys = <&ufs_mem_phy_lanes>;
phy-names = "ufsphy";
@@ -213,19 +207,8 @@ examples:
vccq-max-microamp = <1200000>;
power-domains = <&gcc UFS_PHY_GDSC>;
- iommus = <&apps_smmu 0xe0 0x0>;
- interconnects = <&aggre1_noc MASTER_UFS_MEM &mc_virt SLAVE_EBI1>,
- <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_UFS_MEM_CFG>;
- interconnect-names = "ufs-ddr", "cpu-ufs";
+ iommus = <&apps_smmu 0x300 0>;
- clock-names = "core_clk",
- "bus_aggr_clk",
- "iface_clk",
- "core_clk_unipro",
- "ref_clk",
- "tx_lane0_sync_clk",
- "rx_lane0_sync_clk",
- "rx_lane1_sync_clk";
clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
<&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
<&gcc GCC_UFS_PHY_AHB_CLK>,
@@ -233,14 +216,25 @@ examples:
<&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
<&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
- <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
- freq-table-hz = <75000000 300000000>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>,
+ <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clock-names = "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "rx_lane1_sync_clk",
+ "ice_core_clk";
+ freq-table-hz = <37500000 300000000>,
+ <0 0>,
+ <0 0>,
+ <37500000 300000000>,
<0 0>,
<0 0>,
- <75000000 300000000>,
- <75000000 300000000>,
<0 0>,
<0 0>,
- <0 0>;
+ <0 300000000>;
};
};
diff --git a/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml
index f04f9f61fa9f..ac11ac7d1d12 100644
--- a/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml
@@ -33,6 +33,16 @@ properties:
resets:
maxItems: 1
+ nvmem-cells:
+ maxItems: 1
+
+ nvmem-cell-names:
+ items:
+ - const: calibration
+
+dependencies:
+ nvmem-cells: [ nvmem-cell-names ]
+
required:
- compatible
- reg
@@ -50,12 +60,14 @@ examples:
#include <dt-bindings/power/r8a779f0-sysc.h>
ufs: ufs@e686000 {
- compatible = "renesas,r8a779f0-ufs";
- reg = <0xe6860000 0x100>;
- interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>;
- clock-names = "fck", "ref_clk";
- freq-table-hz = <200000000 200000000>, <38400000 38400000>;
- power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
- resets = <&cpg 1514>;
+ compatible = "renesas,r8a779f0-ufs";
+ reg = <0xe6860000 0x100>;
+ interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1514>, <&ufs30_clk>;
+ clock-names = "fck", "ref_clk";
+ freq-table-hz = <200000000 200000000>, <38400000 38400000>;
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 1514>;
+ nvmem-cells = <&ufs_tune>;
+ nvmem-cell-names = "calibration";
};
diff --git a/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml b/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml
new file mode 100644
index 000000000000..c7d17cf4dc42
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/rockchip,rk3576-ufshc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip UFS Host Controller
+
+maintainers:
+ - Shawn Lin <shawn.lin@rock-chips.com>
+
+allOf:
+ - $ref: ufs-common.yaml
+
+properties:
+ compatible:
+ const: rockchip,rk3576-ufshc
+
+ reg:
+ maxItems: 5
+
+ reg-names:
+ items:
+ - const: hci
+ - const: mphy
+ - const: hci_grf
+ - const: mphy_grf
+ - const: hci_apb
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: core
+ - const: pclk
+ - const: pclk_mphy
+ - const: ref_out
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 4
+
+ reset-names:
+ items:
+ - const: biu
+ - const: sys
+ - const: ufs
+ - const: grf
+
+ reset-gpios:
+ maxItems: 1
+ description: |
+ GPIO specifiers for host to reset the whole UFS device including PHY and
+ memory. This gpio is active low and should choose the one whose high output
+ voltage is lower than 1.5V based on the UFS spec.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - resets
+ - reset-names
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rockchip,rk3576-cru.h>
+ #include <dt-bindings/reset/rockchip,rk3576-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/rockchip,rk3576-power.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ufshc: ufshc@2a2d0000 {
+ compatible = "rockchip,rk3576-ufshc";
+ reg = <0x0 0x2a2d0000 0x0 0x10000>,
+ <0x0 0x2b040000 0x0 0x10000>,
+ <0x0 0x2601f000 0x0 0x1000>,
+ <0x0 0x2603c000 0x0 0x1000>,
+ <0x0 0x2a2e0000 0x0 0x10000>;
+ reg-names = "hci", "mphy", "hci_grf", "mphy_grf", "hci_apb";
+ clocks = <&cru ACLK_UFS_SYS>, <&cru PCLK_USB_ROOT>, <&cru PCLK_MPHY>,
+ <&cru CLK_REF_UFS_CLKOUT>;
+ clock-names = "core", "pclk", "pclk_mphy", "ref_out";
+ interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&power RK3576_PD_USB>;
+ resets = <&cru SRST_A_UFS_BIU>, <&cru SRST_A_UFS_SYS>, <&cru SRST_A_UFS>,
+ <&cru SRST_P_UFS_GRF>;
+ reset-names = "biu", "sys", "ufs", "grf";
+ reset-gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
index 2c715eec48b8..a7eb7ad85a94 100644
--- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/ufs/samsung,exynos-ufs.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Samsung SoC series UFS host controller Device Tree Bindings
+title: Samsung SoC series UFS host controller
maintainers:
- Alim Akhtar <alim.akhtar@samsung.com>
@@ -12,12 +12,10 @@ maintainers:
description: |
Each Samsung UFS host controller instance should have its own node.
-allOf:
- - $ref: ufs-common.yaml
-
properties:
compatible:
enum:
+ - google,gs101-ufs
- samsung,exynos7-ufs
- samsung,exynosautov9-ufs
- samsung,exynosautov9-ufs-vh
@@ -38,14 +36,24 @@ properties:
- const: ufsp
clocks:
+ minItems: 2
items:
- description: ufs link core clock
- description: unipro main clock
+ - description: fmp clock
+ - description: ufs aclk clock
+ - description: ufs pclk clock
+ - description: sysreg clock
clock-names:
+ minItems: 2
items:
- const: core_clk
- const: sclk_unipro_main
+ - const: fmp
+ - const: aclk
+ - const: pclk
+ - const: sysreg
phys:
maxItems: 1
@@ -53,11 +61,17 @@ properties:
phy-names:
const: ufs-phy
+ power-domains:
+ maxItems: 1
+
samsung,sysreg:
- $ref: '/schemas/types.yaml#/definitions/phandle-array'
- description: Should be phandle/offset pair. The phandle to the syscon node
- which indicates the FSYSx sysreg interface and the offset of
- the control register for UFS io coherency setting.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to FSYSx sysreg node
+ - description: offset of the control register for UFS io coherency setting
+ description:
+ Phandle and offset to the FSYSx sysreg for UFS io coherency setting.
dma-coherent: true
@@ -69,6 +83,30 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: ufs-common.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-ufs
+
+ then:
+ properties:
+ clocks:
+ minItems: 6
+
+ clock-names:
+ minItems: 6
+
+ else:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ maxItems: 2
+
unevaluatedProperties: false
examples:
@@ -77,19 +115,19 @@ examples:
#include <dt-bindings/clock/exynos7-clk.h>
ufs: ufs@15570000 {
- compatible = "samsung,exynos7-ufs";
- reg = <0x15570000 0x100>,
- <0x15570100 0x100>,
- <0x15571000 0x200>,
- <0x15572000 0x300>;
- reg-names = "hci", "vs_hci", "unipro", "ufsp";
- interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clock_fsys1 ACLK_UFS20_LINK>,
- <&clock_fsys1 SCLK_UFSUNIPRO20_USER>;
- clock-names = "core_clk", "sclk_unipro_main";
- pinctrl-names = "default";
- pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
- phys = <&ufs_phy>;
- phy-names = "ufs-phy";
+ compatible = "samsung,exynos7-ufs";
+ reg = <0x15570000 0x100>,
+ <0x15570100 0x100>,
+ <0x15571000 0x200>,
+ <0x15572000 0x300>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock_fsys1 ACLK_UFS20_LINK>,
+ <&clock_fsys1 SCLK_UFSUNIPRO20_USER>;
+ clock-names = "core_clk", "sclk_unipro_main";
+ pinctrl-names = "default";
+ pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
+ phys = <&ufs_phy>;
+ phy-names = "ufs-phy";
};
...
diff --git a/Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml b/Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml
new file mode 100644
index 000000000000..36a8ae77949f
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/sprd,ums9620-ufs.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/sprd,ums9620-ufs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc Universal Flash Storage (UFS) Controller
+
+maintainers:
+ - Zhe Wang <zhe.wang1@unisoc.com>
+
+allOf:
+ - $ref: ufs-common.yaml
+
+properties:
+ compatible:
+ const: sprd,ums9620-ufs
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: controller_eb
+ - const: cfg_eb
+ - const: core
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: controller
+ - const: device
+
+ vdd-mphy-supply:
+ description:
+ Phandle to vdd-mphy supply regulator node.
+
+ sprd,ufs-anlg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of syscon used to control ufs analog regs.
+
+ sprd,aon-apb-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of syscon used to control always-on regs.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ufs: ufs@22000000 {
+ compatible = "sprd,ums9620-ufs";
+ reg = <0x22000000 0x3000>;
+ interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+ vcc-supply = <&vddemmccore>;
+ vdd-mphy-supply = <&vddufs1v2>;
+ clocks = <&apahb_gate 5>, <&apahb_gate 22>, <&aonapb_clk 52>;
+ clock-names = "controller_eb", "cfg_eb", "core";
+ assigned-clocks = <&aonapb_clk 52>;
+ assigned-clock-parents = <&g5l_pll 12>;
+ resets = <&apahb_gate 4>, <&aonapb_gate 69>;
+ reset-names = "controller", "device";
+ sprd,ufs-anlg-syscon = <&anlg_phy_g12_regs>;
+ sprd,aon-apb-syscon = <&aon_apb_regs>;
+ };
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index 47a4e9e1a775..9f04f34d8c5a 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -20,11 +20,25 @@ properties:
items:
- description: Minimum frequency for given clock in Hz
- description: Maximum frequency for given clock in Hz
+ deprecated: true
description: |
+ Preferred is operating-points-v2.
+
Array of <min max> operating frequencies in Hz stored in the same order
- as the clocks property. If this property is not defined or a value in the
- array is "0" then it is assumed that the frequency is set by the parent
- clock or a fixed rate clock source.
+ as the clocks property. If either this property or operating-points-v2 is
+ not defined or a value in the array is "0" then it is assumed that the
+ frequency is set by the parent clock or a fixed rate clock source.
+
+ operating-points-v2:
+ description:
+ Preferred over freq-table-hz.
+ If present, each OPP must contain array of frequencies stored in the same
+ order for each clock. If clock frequency in the array is "0" then it is
+ assumed that the frequency is set by the parent clock or a fixed rate
+ clock source.
+
+ opp-table:
+ type: object
interrupts:
maxItems: 1
@@ -73,10 +87,43 @@ properties:
description:
Specifies max. load that can be drawn from VCCQ2 supply.
+ msi-parent: true
+
+ limit-hs-gear:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 6
+ default: 6
+ description:
+ Restricts the maximum HS gear used in both TX and RX directions.
+
+ limit-gear-rate:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [rate-a, rate-b]
+ default: rate-b
+ description:
+ Restricts the UFS controller to rate-a or rate-b for both TX and
+ RX directions.
+
dependencies:
- freq-table-hz: [ 'clocks' ]
+ freq-table-hz: [ clocks ]
+ operating-points-v2: [ clocks, clock-names ]
required:
- interrupts
+allOf:
+ - if:
+ required:
+ - freq-table-hz
+ then:
+ properties:
+ operating-points-v2: false
+ - if:
+ required:
+ - operating-points-v2
+ then:
+ properties:
+ freq-table-hz: false
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index e5dbf4169bc9..7ffcd236d7bb 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/allwinner,sun4i-a10-musb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 mUSB OTG Controller Device Tree Bindings
+title: Allwinner A10 mUSB OTG Controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
@@ -13,15 +13,19 @@ maintainers:
properties:
compatible:
oneOf:
- - const: allwinner,sun4i-a10-musb
- - const: allwinner,sun6i-a31-musb
- - const: allwinner,sun8i-a33-musb
- - const: allwinner,sun8i-h3-musb
+ - enum:
+ - allwinner,sun4i-a10-musb
+ - allwinner,sun6i-a31-musb
+ - allwinner,sun8i-a33-musb
+ - allwinner,sun8i-h3-musb
+ - allwinner,suniv-f1c100s-musb
- items:
- enum:
- allwinner,sun8i-a83t-musb
- allwinner,sun20i-d1-musb
+ - allwinner,sun50i-a100-musb
- allwinner,sun50i-h6-musb
+ - allwinner,sun55i-a523-musb
- const: allwinner,sun8i-a33-musb
- items:
- const: allwinner,sun50i-h616-musb
diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
index daf2a859418d..da757c1155d4 100644
--- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
+++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/amlogic,meson-g12a-usb-ctrl.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/amlogic,meson-g12a-usb-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic Meson G12A DWC3 USB SoC Controller Glue
@@ -108,6 +108,7 @@ allOf:
then:
properties:
phy-names:
+ minItems: 2
items:
- const: usb2-phy0 # USB2 PHY0 if USBHOST_A port is used
- const: usb2-phy1 # USB2 PHY1 if USBOTG_B port is used
diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml b/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml
index ee436308e5dc..3f5857aee3b0 100644
--- a/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml
+++ b/Documentation/devicetree/bindings/usb/analogix,anx7411.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/analogix,anx7411.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analogix ANX7411 Type-C controller bindings
+title: Analogix ANX7411 Type-C controller
maintainers:
- Xin Ji <xji@analogixsemi.com>
@@ -23,22 +23,11 @@ properties:
connector:
type: object
$ref: ../connector/usb-connector.yaml
- description:
- Properties for usb c connector.
properties:
compatible:
const: usb-c-connector
- power-role: true
-
- data-role: true
-
- try-power-role: true
-
- required:
- - compatible
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/usb/apple,dwc3.yaml b/Documentation/devicetree/bindings/usb/apple,dwc3.yaml
new file mode 100644
index 000000000000..f70c33f32c5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/apple,dwc3.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/apple,dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple Silicon DWC3 USB controller
+
+maintainers:
+ - Sven Peter <sven@kernel.org>
+
+description:
+ Apple Silicon SoCs use a Synopsys DesignWare DWC3 based controller for each of
+ their Type-C ports.
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - apple,t6000-dwc3
+ - apple,t6020-dwc3
+ - apple,t8112-dwc3
+ - const: apple,t8103-dwc3
+ - const: apple,t8103-dwc3
+
+ reg:
+ items:
+ - description: Core DWC3 region
+ - description: Apple-specific DWC3 region
+
+ reg-names:
+ items:
+ - const: dwc3-core
+ - const: dwc3-apple
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ maxItems: 2
+
+ resets:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - iommus
+ - resets
+ - power-domains
+ - usb-role-switch
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/apple-aic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ usb@82280000 {
+ compatible = "apple,t8103-dwc3";
+ reg = <0x82280000 0xcd00>, <0x8228cd00 0x3200>;
+ reg-names = "dwc3-core", "dwc3-apple";
+ interrupts = <AIC_IRQ 777 IRQ_TYPE_LEVEL_HIGH>;
+ iommus = <&dwc3_0_dart_0 0>, <&dwc3_0_dart_1 1>;
+
+ power-domains = <&ps_atc0_usb>;
+ resets = <&atcphy0>;
+
+ usb-role-switch;
+ };
diff --git a/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml b/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml
index 8b019ac05bbe..7f22f9c031b2 100644
--- a/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml
+++ b/Documentation/devicetree/bindings/usb/aspeed,usb-vhub.yaml
@@ -67,6 +67,7 @@ properties:
vhub-strings:
type: object
+ additionalProperties: false
properties:
'#address-cells':
@@ -78,6 +79,7 @@ properties:
patternProperties:
'^string@[0-9a-f]+$':
type: object
+ additionalProperties: false
description: string descriptors of the specific language
properties:
@@ -111,27 +113,27 @@ examples:
- |
#include <dt-bindings/clock/aspeed-clock.h>
vhub: usb-vhub@1e6a0000 {
- compatible = "aspeed,ast2500-usb-vhub";
- reg = <0x1e6a0000 0x300>;
- interrupts = <5>;
- clocks = <&syscon ASPEED_CLK_GATE_USBPORT1CLK>;
- aspeed,vhub-downstream-ports = <5>;
- aspeed,vhub-generic-endpoints = <15>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usb2ad_default>;
-
- vhub-vendor-id = <0x1d6b>;
- vhub-product-id = <0x0107>;
- vhub-device-revision = <0x0100>;
- vhub-strings {
- #address-cells = <1>;
- #size-cells = <0>;
-
- string@409 {
- reg = <0x409>;
- manufacturer = "ASPEED";
- product = "USB Virtual Hub";
- serial-number = "0000";
- };
+ compatible = "aspeed,ast2500-usb-vhub";
+ reg = <0x1e6a0000 0x300>;
+ interrupts = <5>;
+ clocks = <&syscon ASPEED_CLK_GATE_USBPORT1CLK>;
+ aspeed,vhub-downstream-ports = <5>;
+ aspeed,vhub-generic-endpoints = <15>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb2ad_default>;
+
+ vhub-vendor-id = <0x1d6b>;
+ vhub-product-id = <0x0107>;
+ vhub-device-revision = <0x0100>;
+ vhub-strings {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ string@409 {
+ reg = <0x409>;
+ manufacturer = "ASPEED";
+ product = "USB Virtual Hub";
+ serial-number = "0000";
};
+ };
};
diff --git a/Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt b/Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt
deleted file mode 100644
index 452c45c7bf29..000000000000
--- a/Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* Broadcom USB controllers
-
-Required properties:
-- compatible: "brcm,bcm3384-ohci", "brcm,bcm3384-ehci"
-
- These currently use the generic-ohci and generic-ehci drivers. On some
- systems, special handling may be needed in the following cases:
-
- - Restoring state after systemwide power save modes
- - Sharing PHYs with the USBD (UDC) hardware
- - Figuring out which controllers are disabled on ASIC bondout variants
diff --git a/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
index 2a9acf2b5a64..1536cbec6334 100644
--- a/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml
@@ -4,10 +4,10 @@
$id: http://devicetree.org/schemas/usb/brcm,bcm7445-ehci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom STB USB EHCI Controller Device Tree Bindings
+title: Broadcom STB USB EHCI Controller
allOf:
- - $ref: "usb-hcd.yaml"
+ - $ref: usb-hcd.yaml
maintainers:
- Al Cooper <alcooperx@gmail.com>
diff --git a/Documentation/devicetree/bindings/usb/brcm,bdc.yaml b/Documentation/devicetree/bindings/usb/brcm,bdc.yaml
index 9e561fee98f1..f9375c69e86b 100644
--- a/Documentation/devicetree/bindings/usb/brcm,bdc.yaml
+++ b/Documentation/devicetree/bindings/usb/brcm,bdc.yaml
@@ -41,10 +41,10 @@ additionalProperties: false
examples:
- |
- usb@f0b02000 {
- compatible = "brcm,bdc-udc-v2";
- reg = <0xf0b02000 0xfc4>;
- interrupts = <0x0 0x60 0x0>;
- phys = <&usbphy_0 0x0>;
- clocks = <&sw_usbd>;
- };
+ usb@f0b02000 {
+ compatible = "brcm,bdc-udc-v2";
+ reg = <0xf0b02000 0xfc4>;
+ interrupts = <0x0 0x60 0x0>;
+ phys = <&usbphy_0 0x0>;
+ clocks = <&sw_usbd>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
index d4618d15ecc1..5cc81ced589d 100644
--- a/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
+++ b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/brcm,usb-pinmap.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom USB pin map Controller Device Tree Bindings
+title: Broadcom USB pin map Controller
maintainers:
- Al Cooper <alcooperx@gmail.com>
diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
index dc9d6ed0781d..f454ddd9bbaa 100644
--- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
+++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/cdns,usb3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Cadence USBSS-DRD controller bindings
+title: Cadence USBSS-DRD controller
maintainers:
- Pawel Laszczak <pawell@cadence.com>
@@ -42,8 +42,11 @@ properties:
- const: otg
- const: wakeup
- dr_mode:
- enum: [host, otg, peripheral]
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ This port is used with the 'usb-role-switch' property to connect the
+ cdns3 to type C connector.
maximum-speed:
enum: [super-speed, high-speed, full-speed]
@@ -64,12 +67,15 @@ properties:
description:
size of memory intended as internal memory for endpoints
buffers expressed in KB
- $ref: /schemas/types.yaml#/definitions/uint32
+ $ref: /schemas/types.yaml#/definitions/uint16
cdns,phyrst-a-enable:
description: Enable resetting of PHY if Rx fail is detected
type: boolean
+dependencies:
+ port: [ usb-role-switch ]
+
required:
- compatible
- reg
@@ -77,7 +83,10 @@ required:
- interrupts
- interrupt-names
-additionalProperties: false
+allOf:
+ - $ref: usb-drd.yaml#
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
new file mode 100644
index 000000000000..10020af15afc
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
@@ -0,0 +1,203 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/chipidea,usb2-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB2 ChipIdea USB controller Common Properties
+
+maintainers:
+ - Xu Yang <xu.yang_2@nxp.com>
+
+properties:
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ dr_mode: true
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+ phy_type: true
+
+ iommus:
+ maxItems: 1
+
+ itc-setting:
+ description:
+ interrupt threshold control register control, the setting should be
+ aligned with ITC bits at register USBCMD.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ahb-burst-config:
+ description:
+ it is vendor dependent, the required value should be aligned with
+ AHBBRST at SBUSCFG, the range is from 0x0 to 0x7. This property is
+ used to change AHB burst configuration, check the chipidea spec for
+ meaning of each value. If this property is not existed, it will use
+ the reset value.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x0
+ maximum: 0x7
+
+ tx-burst-size-dword:
+ description:
+ it is vendor dependent, the tx burst size in dword (4 bytes), This
+ register represents the maximum length of a the burst in 32-bit
+ words while moving data from system memory to the USB bus, the value
+ of this property will only take effect if property "ahb-burst-config"
+ is set to 0, if this property is missing the reset default of the
+ hardware implementation will be used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x0
+ maximum: 0x20
+
+ rx-burst-size-dword:
+ description:
+ it is vendor dependent, the rx burst size in dword (4 bytes), This
+ register represents the maximum length of a the burst in 32-bit words
+ while moving data from the USB bus to system memory, the value of
+ this property will only take effect if property "ahb-burst-config"
+ is set to 0, if this property is missing the reset default of the
+ hardware implementation will be used.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x0
+ maximum: 0x20
+
+ extcon:
+ description:
+ Phandles to external connector devices. First phandle should point
+ to external connector, which provide "USB" cable events, the second
+ should point to external connector device, which provide "USB-HOST"
+ cable events. If one of the external connector devices is not
+ required, empty <0> phandle should be specified.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ items:
+ - description: vbus extcon
+ - description: id extcon
+
+ phy-clkgate-delay-us:
+ description:
+ The delay time (us) between putting the PHY into low power mode and
+ gating the PHY clock.
+
+ non-zero-ttctrl-ttha:
+ description:
+ After setting this property, the value of register ttctrl.ttha
+ will be 0x7f; if not, the value will be 0x0, this is the default
+ value. It needs to be very carefully for setting this property, it
+ is recommended that consult with your IC engineer before setting
+ this value. On the most of chipidea platforms, the "usage_tt" flag
+ at RTL is 0, so this property only affects siTD.
+
+ If this property is not set, the max packet size is 1023 bytes, and
+ if the total of packet size for previous transactions are more than
+ 256 bytes, it can't accept any transactions within this frame. The
+ use case is single transaction, but higher frame rate.
+
+ If this property is set, the max packet size is 188 bytes, it can
+ handle more transactions than above case, it can accept transactions
+ until it considers the left room size within frame is less than 188
+ bytes, software needs to make sure it does not send more than 90%
+ maximum_periodic_data_per_frame. The use case is multiple
+ transactions, but less frame rate.
+ type: boolean
+
+ mux-controls:
+ description:
+ The mux control for toggling host/device output of this controller.
+ It's expected that a mux state of 0 indicates device mode and a mux
+ state of 1 indicates host mode.
+ maxItems: 1
+
+ mux-control-names:
+ const: usb_switch
+
+ pinctrl-names:
+ description:
+ Names for optional pin modes in "default", "host", "device".
+ In case of HSIC-mode, "idle" and "active" pin modes are mandatory.
+ In this case, the "idle" state needs to pull down the data and
+ strobe pin and the "active" state needs to pull up the strobe pin.
+ oneOf:
+ - items:
+ - const: idle
+ - const: active
+ - items:
+ - const: default
+ - const: host
+ - const: device
+ - items:
+ - const: default
+ - enum:
+ - host
+ - device
+ - items:
+ - const: default
+
+ pinctrl-0:
+ maxItems: 1
+
+ pinctrl-1:
+ maxItems: 1
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: usb-phy
+
+ vbus-supply:
+ description: reference to the VBUS regulator.
+
+ usb-phy:
+ description: phandle for the PHY device. Use "phys" instead.
+ maxItems: 1
+ deprecated: true
+
+ port:
+ description:
+ Any connector to the data bus of this controller should be modelled
+ using the OF graph bindings specified, if the "usb-role-switch"
+ property is used.
+ $ref: /schemas/graph.yaml#/properties/port
+
+ reset-gpios:
+ maxItems: 1
+
+dependencies:
+ port: [ usb-role-switch ]
+ mux-controls: [ mux-control-names ]
+
+required:
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: usb-hcd.yaml#
+ - $ref: usb-drd.yaml#
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-imx.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-imx.yaml
new file mode 100644
index 000000000000..51014955ab3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-imx.yaml
@@ -0,0 +1,309 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/chipidea,usb2-imx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP USB2 ChipIdea USB controller
+
+maintainers:
+ - Xu Yang <xu.yang_2@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx27-usb
+ - items:
+ - enum:
+ - fsl,imx23-usb
+ - fsl,imx25-usb
+ - fsl,imx28-usb
+ - fsl,imx35-usb
+ - fsl,imx50-usb
+ - fsl,imx51-usb
+ - fsl,imx53-usb
+ - fsl,imx6q-usb
+ - fsl,imx6sl-usb
+ - fsl,imx6sx-usb
+ - fsl,imx6ul-usb
+ - fsl,imx7d-usb
+ - fsl,vf610-usb
+ - const: fsl,imx27-usb
+ - items:
+ - enum:
+ - fsl,imx8dxl-usb
+ - fsl,imx8ulp-usb
+ - const: fsl,imx7ulp-usb
+ - const: fsl,imx6ul-usb
+ - items:
+ - enum:
+ - fsl,imx8mm-usb
+ - fsl,imx8mn-usb
+ - fsl,imx93-usb
+ - fsl,imx95-usb
+ - const: fsl,imx7d-usb
+ - const: fsl,imx27-usb
+ - items:
+ - enum:
+ - fsl,imx6sll-usb
+ - fsl,imx7ulp-usb
+ - const: fsl,imx6ul-usb
+ - const: fsl,imx27-usb
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: USB controller interrupt or combine USB controller
+ and wakeup interrupts.
+ - description: Wakeup interrupt
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ fsl,usbmisc:
+ description:
+ Phandler of non-core register device, with one argument that
+ indicate usb controller index
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to usbmisc node
+ - description: index of usb controller
+
+ disable-over-current:
+ type: boolean
+ description: disable over current detect
+
+ over-current-active-low:
+ type: boolean
+ description: over current signal polarity is active low
+
+ over-current-active-high:
+ type: boolean
+ description:
+ Over current signal polarity is active high. It's recommended to
+ specify the over current polarity.
+
+ power-active-high:
+ type: boolean
+ description: power signal polarity is active high
+
+ external-vbus-divider:
+ type: boolean
+ description: enables off-chip resistor divider for Vbus
+
+ samsung,picophy-pre-emp-curr-control:
+ description:
+ HS Transmitter Pre-Emphasis Current Control. This signal controls
+ the amount of current sourced to the USB_OTG*_DP and USB_OTG*_DN
+ pins after a J-to-K or K-to-J transition. The range is from 0x0 to
+ 0x3, the default value is 0x1. Details can refer to TXPREEMPAMPTUNE0
+ bits of USBNC_n_PHY_CFG1.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x0
+ maximum: 0x3
+
+ samsung,picophy-dc-vol-level-adjust:
+ description:
+ HS DC Voltage Level Adjustment. Adjust the high-speed transmitter DC
+ level voltage. The range is from 0x0 to 0xf, the default value is
+ 0x3. Details can refer to TXVREFTUNE0 bits of USBNC_n_PHY_CFG1.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0x0
+ maximum: 0xf
+
+ fsl,picophy-rise-fall-time-adjust:
+ description:
+ HS Transmitter Rise/Fall Time Adjustment. Adjust the rise/fall times
+ of the high-speed transmitter waveform. It has no unit. The rise/fall
+ time will be increased or decreased by a certain percentage relative
+ to design default time. (0:-10%; 1:design default; 2:+15%; 3:+20%)
+ Details can refer to TXRISETUNE0 bit of USBNC_n_PHY_CFG1.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 3
+ default: 1
+
+ fsl,usbphy:
+ description: phandle of usb phy that connects to the port. Use "phys" instead.
+ $ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
+
+required:
+ - compatible
+
+allOf:
+ - $ref: chipidea,usb2-common.yaml#
+ - if:
+ properties:
+ phy_type:
+ const: hsic
+ required:
+ - phy_type
+ then:
+ properties:
+ pinctrl-names:
+ items:
+ - const: idle
+ - const: active
+
+ # imx27 Soc needs three clocks
+ - if:
+ properties:
+ compatible:
+ const: fsl,imx27-usb
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
+ - const: per
+
+ # imx25 and imx35 Soc need three clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx25-usb
+ - fsl,imx35-usb
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ items:
+ - const: ipg
+ - const: ahb
+ - const: per
+
+ # imx93 Soc needs two clocks
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx93-usb
+ - fsl,imx95-usb
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: usb_ctrl_root
+ - const: usb_wakeup
+
+ # imx7d Soc need one clock
+ - if:
+ properties:
+ compatible:
+ items:
+ - const: fsl,imx7d-usb
+ - const: fsl,imx27-usb
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names: false
+
+ # other Soc need one clock
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx23-usb
+ - fsl,imx28-usb
+ - fsl,imx50-usb
+ - fsl,imx51-usb
+ - fsl,imx53-usb
+ - fsl,imx6q-usb
+ - fsl,imx6sl-usb
+ - fsl,imx6sx-usb
+ - fsl,imx6ul-usb
+ - fsl,imx8mm-usb
+ - fsl,imx8mn-usb
+ - fsl,vf610-usb
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names: false
+
+ # imx95 soc use two interrupts
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx95-usb
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx7d-clock.h>
+
+ usb@30b10000 {
+ compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
+ reg = <0x30b10000 0x200>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_USB_CTRL_CLK>;
+ fsl,usbphy = <&usbphynop1>;
+ fsl,usbmisc = <&usbmisc1 0>;
+ phy-clkgate-delay-us = <400>;
+ };
+
+ # Example for HSIC:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+
+ usb@2184400 {
+ compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+ reg = <0x02184400 0x200>;
+ interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_USBOH3>;
+ fsl,usbphy = <&usbphynop1>;
+ fsl,usbmisc = <&usbmisc 2>;
+ phy_type = "hsic";
+ dr_mode = "host";
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x10>;
+ rx-burst-size-dword = <0x10>;
+ pinctrl-names = "idle", "active";
+ pinctrl-0 = <&pinctrl_usbh2_idle>;
+ pinctrl-1 = <&pinctrl_usbh2_active>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usb424,9730";
+ reg = <1>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
deleted file mode 100644
index ba51fb1252b9..000000000000
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ /dev/null
@@ -1,158 +0,0 @@
-* USB2 ChipIdea USB controller for ci13xxx
-
-Required properties:
-- compatible: should be one of:
- "fsl,imx23-usb"
- "fsl,imx27-usb"
- "fsl,imx28-usb"
- "fsl,imx6q-usb"
- "fsl,imx6sl-usb"
- "fsl,imx6sx-usb"
- "fsl,imx6ul-usb"
- "fsl,imx7d-usb"
- "fsl,imx7ulp-usb"
- "lsi,zevio-usb"
- "qcom,ci-hdrc"
- "chipidea,usb2"
- "xlnx,zynq-usb-2.20a"
- "nvidia,tegra20-udc"
- "nvidia,tegra30-udc"
- "nvidia,tegra114-udc"
- "nvidia,tegra124-udc"
-- reg: base address and length of the registers
-- interrupts: interrupt for the USB controller
-
-Recommended properies:
-- phy_type: the type of the phy connected to the core. Should be one
- of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
- property the PORTSC register won't be touched.
-- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
-
-Deprecated properties:
-- usb-phy: phandle for the PHY device. Use "phys" instead.
-- fsl,usbphy: phandle of usb phy that connects to the port. Use "phys" instead.
-
-Optional properties:
-- clocks: reference to the USB clock
-- phys: reference to the USB PHY
-- phy-names: should be "usb-phy"
-- vbus-supply: reference to the VBUS regulator
-- maximum-speed: limit the maximum connection speed to "full-speed".
-- tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts
-- itc-setting: interrupt threshold control register control, the setting
- should be aligned with ITC bits at register USBCMD.
-- ahb-burst-config: it is vendor dependent, the required value should be
- aligned with AHBBRST at SBUSCFG, the range is from 0x0 to 0x7. This
- property is used to change AHB burst configuration, check the chipidea
- spec for meaning of each value. If this property is not existed, it
- will use the reset value.
-- tx-burst-size-dword: it is vendor dependent, the tx burst size in dword
- (4 bytes), This register represents the maximum length of a the burst
- in 32-bit words while moving data from system memory to the USB
- bus, the value of this property will only take effect if property
- "ahb-burst-config" is set to 0, if this property is missing the reset
- default of the hardware implementation will be used.
-- rx-burst-size-dword: it is vendor dependent, the rx burst size in dword
- (4 bytes), This register represents the maximum length of a the burst
- in 32-bit words while moving data from the USB bus to system memory,
- the value of this property will only take effect if property
- "ahb-burst-config" is set to 0, if this property is missing the reset
- default of the hardware implementation will be used.
-- extcon: phandles to external connector devices. First phandle should point to
- external connector, which provide "USB" cable events, the second should point
- to external connector device, which provide "USB-HOST" cable events. If one
- of the external connector devices is not required, empty <0> phandle should
- be specified.
-- phy-clkgate-delay-us: the delay time (us) between putting the PHY into
- low power mode and gating the PHY clock.
-- non-zero-ttctrl-ttha: after setting this property, the value of register
- ttctrl.ttha will be 0x7f; if not, the value will be 0x0, this is the default
- value. It needs to be very carefully for setting this property, it is
- recommended that consult with your IC engineer before setting this value.
- On the most of chipidea platforms, the "usage_tt" flag at RTL is 0, so this
- property only affects siTD.
- If this property is not set, the max packet size is 1023 bytes, and if
- the total of packet size for pervious transactions are more than 256 bytes,
- it can't accept any transactions within this frame. The use case is single
- transaction, but higher frame rate.
- If this property is set, the max packet size is 188 bytes, it can handle
- more transactions than above case, it can accept transactions until it
- considers the left room size within frame is less than 188 bytes, software
- needs to make sure it does not send more than 90%
- maximum_periodic_data_per_frame. The use case is multiple transactions, but
- less frame rate.
-- mux-controls: The mux control for toggling host/device output of this
- controller. It's expected that a mux state of 0 indicates device mode and a
- mux state of 1 indicates host mode.
-- mux-control-names: Shall be "usb_switch" if mux-controls is specified.
-- pinctrl-names: Names for optional pin modes in "default", "host", "device".
- In case of HSIC-mode, "idle" and "active" pin modes are mandatory. In this
- case, the "idle" state needs to pull down the data and strobe pin
- and the "active" state needs to pull up the strobe pin.
-- pinctrl-n: alternate pin modes
-
-i.mx specific properties
-- fsl,usbmisc: phandler of non-core register device, with one
- argument that indicate usb controller index
-- disable-over-current: disable over current detect
-- over-current-active-low: over current signal polarity is active low.
-- over-current-active-high: over current signal polarity is active high.
- It's recommended to specify the over current polarity.
-- power-active-high: power signal polarity is active high
-- external-vbus-divider: enables off-chip resistor divider for Vbus
-- samsung,picophy-pre-emp-curr-control: HS Transmitter Pre-Emphasis Current
- Control. This signal controls the amount of current sourced to the
- USB_OTG*_DP and USB_OTG*_DN pins after a J-to-K or K-to-J transition.
- The range is from 0x0 to 0x3, the default value is 0x1.
- Details can refer to TXPREEMPAMPTUNE0 bits of USBNC_n_PHY_CFG1.
-- samsung,picophy-dc-vol-level-adjust: HS DC Voltage Level Adjustment.
- Adjust the high-speed transmitter DC level voltage.
- The range is from 0x0 to 0xf, the default value is 0x3.
- Details can refer to TXVREFTUNE0 bits of USBNC_n_PHY_CFG1.
-
-Example:
-
- usb@f7ed0000 {
- compatible = "chipidea,usb2";
- reg = <0xf7ed0000 0x10000>;
- interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&chip CLKID_USB0>;
- phys = <&usb_phy0>;
- phy-names = "usb-phy";
- vbus-supply = <&reg_usb0_vbus>;
- itc-setting = <0x4>; /* 4 micro-frames */
- /* Incremental burst of unspecified length */
- ahb-burst-config = <0x0>;
- tx-burst-size-dword = <0x10>; /* 64 bytes */
- rx-burst-size-dword = <0x10>;
- extcon = <0>, <&usb_id>;
- phy-clkgate-delay-us = <400>;
- mux-controls = <&usb_switch>;
- mux-control-names = "usb_switch";
- };
-
-Example for HSIC:
-
- usb@2184400 {
- compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
- reg = <0x02184400 0x200>;
- interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6QDL_CLK_USBOH3>;
- fsl,usbphy = <&usbphynop1>;
- fsl,usbmisc = <&usbmisc 2>;
- phy_type = "hsic";
- dr_mode = "host";
- ahb-burst-config = <0x0>;
- tx-burst-size-dword = <0x10>;
- rx-burst-size-dword = <0x10>;
- pinctrl-names = "idle", "active";
- pinctrl-0 = <&pinctrl_usbh2_idle>;
- pinctrl-1 = <&pinctrl_usbh2_active>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbnet: ethernet@1 {
- compatible = "usb424,9730";
- reg = <1>;
- };
- };
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
new file mode 100644
index 000000000000..691d6cf02c27
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ci-hdrc-usb2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB2 ChipIdea USB controller
+
+maintainers:
+ - Xu Yang <xu.yang_2@nxp.com>
+ - Peng Fan <peng.fan@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - chipidea,usb2
+ - lsi,zevio-usb
+ - nuvoton,npcm750-udc
+ - nvidia,tegra20-ehci
+ - nvidia,tegra20-udc
+ - nvidia,tegra30-ehci
+ - nvidia,tegra30-udc
+ - nvidia,tegra114-udc
+ - nvidia,tegra124-udc
+ - nxp,s32g2-usb
+ - qcom,ci-hdrc
+ - items:
+ - enum:
+ - nvidia,tegra114-ehci
+ - nvidia,tegra124-ehci
+ - nvidia,tegra210-ehci
+ - const: nvidia,tegra30-ehci
+ - items:
+ - const: xlnx,zynq-usb-2.20a
+ - const: chipidea,usb2
+ - items:
+ - enum:
+ - nuvoton,npcm845-udc
+ - const: nuvoton,npcm750-udc
+ - items:
+ - enum:
+ - nxp,s32g3-usb
+ - const: nxp,s32g2-usb
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+
+ operating-points-v2:
+ description: A phandle to the OPP table containing the performance states.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ phy-select:
+ description:
+ Phandler of TCSR node with two argument that indicate register
+ offset, and phy index
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - description: phandle to TCSR node
+ - description: register offset
+ - description: phy index
+
+ nvidia,phy:
+ description: phandle of usb phy that connects to the port. Use "phys" instead.
+ $ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
+
+ nvidia,needs-double-reset:
+ description: Indicates double reset or not.
+ type: boolean
+ deprecated: true
+
+ ulpi:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^phy(-[0-9])?$":
+ description: The phy child node for Qcom chips.
+ type: object
+ $ref: /schemas/phy/qcom,usb-hs-phy.yaml
+
+required:
+ - compatible
+
+allOf:
+ - $ref: chipidea,usb2-common.yaml#
+ - $ref: usb-hcd.yaml#
+ - $ref: usb-drd.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/berlin2.h>
+
+ usb@f7ed0000 {
+ compatible = "chipidea,usb2";
+ reg = <0xf7ed0000 0x10000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&chip CLKID_USB0>;
+ phys = <&usb_phy0>;
+ phy-names = "usb-phy";
+ vbus-supply = <&reg_usb0_vbus>;
+ itc-setting = <0x4>; /* 4 micro-frames */
+ /* Incremental burst of unspecified length */
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x10>; /* 64 bytes */
+ rx-burst-size-dword = <0x10>;
+ extcon = <0>, <&usb_id>;
+ phy-clkgate-delay-us = <400>;
+ mux-controls = <&usb_switch>;
+ mux-control-names = "usb_switch";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
new file mode 100644
index 000000000000..0620d82508c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cypress,cypd4226.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/cypress,cypd4226.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress cypd4226 Type-C Controller
+
+maintainers:
+ - Wayne Chang <waynec@nvidia.com>
+
+description:
+ The Cypress cypd4226 is a dual Type-C controller that is controlled
+ via an I2C interface.
+
+properties:
+ compatible:
+ const: cypress,cypd4226
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ const: 0x08
+
+ interrupts:
+ items:
+ - description: cypd4226 host interrupt
+
+ firmware-name:
+ enum:
+ - nvidia,gpu
+ - nvidia,jetson-agx-xavier
+ description: |
+ The name of the CCGx firmware built for product series.
+ should be set one of following:
+ - "nvidia,gpu" for the NVIDIA RTX product series
+ - "nvidia,jetson-agx-xavier" for the NVIDIA Jetson product series
+
+patternProperties:
+ '^connector@[01]$':
+ $ref: /schemas/connector/usb-connector.yaml#
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+anyOf:
+ - required:
+ - connector@0
+ - required:
+ - connector@1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec@8 {
+ compatible = "cypress,cypd4226";
+ reg = <0x08>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ firmware-name = "nvidia,jetson-agx-xavier";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ label = "USB-C";
+ data-role = "dual";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&usb_role_switch0>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/cypress,hx3.yaml b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml
new file mode 100644
index 000000000000..d6eac1213228
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cypress,hx3.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/cypress,hx3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cypress HX3 USB 3.0 hub controller family
+
+maintainers:
+ - Benjamin Bara <benjamin.bara@skidata.com>
+
+allOf:
+ - $ref: usb-device.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - usb4b4,6504
+ - usb4b4,6506
+ - items:
+ - enum:
+ - usb4b4,6500
+ - usb4b4,6508
+ - const: usb4b4,6504
+ - items:
+ - enum:
+ - usb4b4,6502
+ - usb4b4,6503
+ - usb4b4,6507
+ - usb4b4,650a
+ - const: usb4b4,6506
+
+ reg: true
+
+ reset-gpios:
+ items:
+ - description: GPIO specifier for RESETN pin.
+
+ vdd-supply:
+ description:
+ 1V2 power supply (VDD_EFUSE, AVDD12, DVDD12).
+
+ vdd2-supply:
+ description:
+ 3V3 power supply (AVDD33, VDD_IO).
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+required:
+ - compatible
+ - reg
+ - peer-hub
+ - vdd-supply
+ - vdd2-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb4b4,6504";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&reg_1v2_usb>;
+ vdd2-supply = <&reg_3v3_usb>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb4b4,6506";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&reg_1v2_usb>;
+ vdd2-supply = <&reg_3v3_usb>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index 1bfbc6ef16eb..6c3a10991b8b 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/dwc2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: DesignWare HS OTG USB 2.0 controller Bindings
+title: DesignWare HS OTG USB 2.0 controller
maintainers:
- Rob Herring <robh@kernel.org>
@@ -32,6 +32,7 @@ properties:
- enum:
- rockchip,px30-usb
- rockchip,rk3036-usb
+ - rockchip,rk3128-usb
- rockchip,rk3188-usb
- rockchip,rk3228-usb
- rockchip,rk3288-usb
@@ -42,18 +43,23 @@ properties:
- const: rockchip,rk3066-usb
- const: snps,dwc2
- const: lantiq,arx100-usb
+ - const: lantiq,ase-usb
+ - const: lantiq,danube-usb
- const: lantiq,xrx200-usb
+ - const: lantiq,xrx300-usb
- items:
- enum:
- amlogic,meson8-usb
- amlogic,meson8b-usb
- amlogic,meson-gxbb-usb
- amlogic,meson-g12a-usb
+ - amlogic,meson-a1-usb
- intel,socfpga-agilex-hsotg
- const: snps,dwc2
- const: amcc,dwc-otg
- const: apm,apm82181-dwc-otg
- const: snps,dwc2
+ - const: sophgo,cv1800b-usb
- const: st,stm32f4x9-fsotg
- const: st,stm32f4x9-hsotg
- const: st,stm32f7-hsotg
@@ -71,11 +77,14 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
clock-names:
items:
- const: otg
+ - const: utmi
+ minItems: 1
disable-over-current:
type: boolean
@@ -164,6 +173,10 @@ properties:
tpl-support: true
+ access-controllers:
+ minItems: 1
+ maxItems: 2
+
dependencies:
port: [ usb-role-switch ]
role-switch-default-mode: [ usb-role-switch ]
@@ -175,11 +188,11 @@ required:
- clocks
- clock-names
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
- usb@101c0000 {
+ usb@101c0000 {
compatible = "rockchip,rk3066-usb", "snps,dwc2";
reg = <0x10180000 0x40000>;
interrupts = <18>;
@@ -187,6 +200,6 @@ examples:
clock-names = "otg";
phys = <&usbphy>;
phy-names = "usb2-phy";
- };
+ };
...
diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
index 098b73134a1b..d6823ef5f9a7 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx SuperSpeed DWC3 USB SoC controller
maintainers:
- - Manish Narani <manish.narani@xilinx.com>
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
compatible:
@@ -26,6 +26,8 @@ properties:
ranges: true
+ dma-coherent: true
+
power-domains:
description: specifies a phandle to PM domain provider node
maxItems: 1
@@ -45,6 +47,7 @@ properties:
- const: ref_clk
resets:
+ minItems: 1
description:
A list of phandles for resets listed in reset-names.
@@ -54,6 +57,7 @@ properties:
- description: USB APB reset
reset-names:
+ minItems: 1
items:
- const: usb_crst
- const: usb_hibrst
@@ -93,6 +97,26 @@ required:
- resets
- reset-names
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - xlnx,versal-dwc3
+ then:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
+ else:
+ properties:
+ resets:
+ minItems: 3
+ reset-names:
+ minItems: 3
+
additionalProperties: false
examples:
@@ -100,7 +124,6 @@ examples:
#include <dt-bindings/dma/xlnx-zynqmp-dpdma.h>
#include <dt-bindings/power/xlnx-zynqmp-power.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
- #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
#include <dt-bindings/phy/phy.h>
axi {
@@ -112,7 +135,7 @@ examples:
#size-cells = <0x2>;
compatible = "xlnx,zynqmp-dwc3";
reg = <0x0 0xff9d0000 0x0 0x100>;
- clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
+ clocks = <&zynqmp_clk 32>, <&zynqmp_clk 34>;
clock-names = "bus_clk", "ref_clk";
power-domains = <&zynqmp_firmware PD_USB_0>;
resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>,
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt
deleted file mode 100644
index d77e11a975a2..000000000000
--- a/Documentation/devicetree/bindings/usb/ehci-omap.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OMAP HS USB EHCI controller
-
-This device is usually the child of the omap-usb-host
-Documentation/devicetree/bindings/mfd/omap-usb-host.txt
-
-Required properties:
-
-- compatible: should be "ti,ehci-omap"
-- reg: should contain one register range i.e. start and length
-- interrupts: description of the interrupt line
-
-Optional properties:
-
-- phys: list of phandles to PHY nodes.
- This property is required if at least one of the ports are in
- PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
-
-To specify the port mode, see
-Documentation/devicetree/bindings/mfd/omap-usb-host.txt
-
-Example for OMAP4:
-
-usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap";
- reg = <0x4a064c00 0x400>;
- interrupts = <0 77 0x4>;
-};
-
-&usbhsehci {
- phys = <&hsusb1_phy 0 &hsusb3_phy>;
-};
diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt b/Documentation/devicetree/bindings/usb/ehci-orion.txt
deleted file mode 100644
index 2855bae79fda..000000000000
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* EHCI controller, Orion Marvell variants
-
-Required properties:
-- compatible: must be one of the following
- "marvell,orion-ehci"
- "marvell,armada-3700-ehci"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The EHCI interrupt
-
-Optional properties:
-- clocks: reference to the clock
-- phys: reference to the USB PHY
-- phy-names: name of the USB PHY, should be "usb"
-
-Example:
-
- ehci@50000 {
- compatible = "marvell,orion-ehci";
- reg = <0x50000 0x1000>;
- interrupts = <19>;
- };
diff --git a/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml b/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
new file mode 100644
index 000000000000..41c3b1b98991
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/eswin,eic7700-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESWIN EIC7700 SoC Usb Controller
+
+maintainers:
+ - Wei Yang <yangwei1@eswincomputing.com>
+ - Senchuan Zhang <zhangsenchuan@eswincomputing.com>
+ - Hang Cao <caohang@eswincomputing.com>
+
+description:
+ The Usb controller on EIC7700 SoC.
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+
+properties:
+ compatible:
+ const: eswin,eic7700-dwc3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ items:
+ - const: peripheral
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: cfg
+ - const: usb_en
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: vaux
+ - const: usb_rst
+
+ eswin,hsp-sp-csr:
+ description:
+ HSP CSR is to control and get status of different high-speed peripherals
+ (such as Ethernet, USB, SATA, etc.) via register, which can tune
+ board-level's parameters of PHY, etc.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to HSP Register Controller hsp_sp_csr node.
+ - description: USB bus register offset.
+ - description: AXI low power register offset.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - resets
+ - reset-names
+ - eswin,hsp-sp-csr
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ usb@50480000 {
+ compatible = "eswin,eic7700-dwc3";
+ reg = <0x50480000 0x10000>;
+ clocks = <&clock 135>,
+ <&clock 136>,
+ <&hspcrg 18>;
+ clock-names = "aclk", "cfg", "usb_en";
+ interrupt-parent = <&plic>;
+ interrupts = <85>;
+ interrupt-names = "peripheral";
+ resets = <&reset 84>, <&hspcrg 2>;
+ reset-names = "vaux", "usb_rst";
+ dr_mode = "peripheral";
+ maximum-speed = "high-speed";
+ phy_type = "utmi";
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x800 0x818>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
deleted file mode 100644
index 06a2286e2054..000000000000
--- a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Faraday FOTG Host controller
-
-This OTG-capable USB host controller is found in Cortina Systems
-Gemini and other SoC products.
-
-Required properties:
-- compatible: should be one of:
- "faraday,fotg210"
- "cortina,gemini-usb", "faraday,fotg210"
-- reg: should contain one register range i.e. start and length
-- interrupts: description of the interrupt line
-
-Optional properties:
-- clocks: should contain the IP block clock
-- clock-names: should be "PCLK" for the IP block clock
-
-Required properties for "cortina,gemini-usb" compatible:
-- syscon: a phandle to the system controller to access PHY registers
-
-Optional properties for "cortina,gemini-usb" compatible:
-- cortina,gemini-mini-b: boolean property that indicates that a Mini-B
- OTG connector is in use
-- wakeup-source: see power/wakeup-source.txt
-
-Example for Gemini:
-
-usb@68000000 {
- compatible = "cortina,gemini-usb", "faraday,fotg210";
- reg = <0x68000000 0x1000>;
- interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cc 12>;
- clock-names = "PCLK";
- syscon = <&syscon>;
- wakeup-source;
-};
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml b/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml
new file mode 100644
index 000000000000..3fe4d1564dfe
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2022 Linaro Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/faraday,fotg210.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday Technology FOTG200 series HS OTG USB 2.0 controller
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+allOf:
+ - $ref: usb-drd.yaml#
+ - $ref: usb-hcd.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: faraday,fotg200
+ - const: faraday,fotg210
+ - items:
+ - const: cortina,gemini-usb
+ - const: faraday,fotg200
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: PCLK
+
+ resets:
+ maxItems: 1
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the global Gemini system controller on
+ Gemini systems
+
+ dr_mode: true
+
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: usb2-phy
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/cortina,gemini-clock.h>
+ #include <dt-bindings/reset/cortina,gemini-reset.h>
+ usb0: usb@68000000 {
+ compatible = "cortina,gemini-usb", "faraday,fotg200";
+ reg = <0x68000000 0x1000>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&syscon GEMINI_RESET_USB0>;
+ clocks = <&syscon GEMINI_CLK_GATE_USB0>;
+ clock-names = "PCLK";
+ syscon = <&syscon>;
+ dr_mode = "host";
+ };
diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
index 9473f26b0621..89b1fb90aeeb 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
+++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
@@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/fcs,fsa4480.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/fcs,fsa4480.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ON Semiconductor Analog Audio Switch
@@ -11,8 +11,12 @@ maintainers:
properties:
compatible:
- enum:
- - fcs,fsa4480
+ oneOf:
+ - const: fcs,fsa4480
+ - items:
+ - enum:
+ - ocs,ocp96011
+ - const: fcs,fsa4480
reg:
maxItems: 1
@@ -23,25 +27,57 @@ properties:
vcc-supply:
description: power supply (2.7V-5.5V)
- mode-switch:
- description: Flag the port as possible handle of altmode switching
- type: boolean
-
- orientation-switch:
- description: Flag the port as possible handler of orientation switching
- type: boolean
+ mode-switch: true
+ orientation-switch: true
port:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
description:
A port node to link the FSA4480 to a TypeC controller for the purpose of
handling altmode muxing and orientation switching.
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Specifies how the AUX+/- lines are connected to SBU1/2.
+ oneOf:
+ - items:
+ - const: 0
+ - const: 1
+ description: |
+ Default AUX/SBU layout (FSA4480)
+ - AUX+ connected to SBU2
+ - AUX- connected to SBU1
+ Default AUX/SBU layout (OCP96011)
+ - AUX+ connected to SBU1
+ - AUX- connected to SBU2
+ - items:
+ - const: 1
+ - const: 0
+ description: |
+ Swapped AUX/SBU layout (FSA4480)
+ - AUX+ connected to SBU1
+ - AUX- connected to SBU2
+ Swapped AUX/SBU layout (OCP96011)
+ - AUX+ connected to SBU2
+ - AUX- connected to SBU1
required:
- compatible
- reg
- port
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+
additionalProperties: false
examples:
@@ -51,22 +87,22 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- fsa4480@42 {
- compatible = "fcs,fsa4480";
- reg = <0x42>;
+ typec-mux@42 {
+ compatible = "fcs,fsa4480";
+ reg = <0x42>;
- interrupts-extended = <&tlmm 2 IRQ_TYPE_LEVEL_LOW>;
+ interrupts-extended = <&tlmm 2 IRQ_TYPE_LEVEL_LOW>;
- vcc-supply = <&vreg_bob>;
+ vcc-supply = <&vreg_bob>;
- mode-switch;
- orientation-switch;
+ mode-switch;
+ orientation-switch;
- port {
- fsa4480_ept: endpoint {
- remote-endpoint = <&typec_controller>;
+ port {
+ fsa4480_ept: endpoint {
+ remote-endpoint = <&typec_controller>;
+ };
};
- };
};
};
...
diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
deleted file mode 100644
index 60e4654297af..000000000000
--- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Fairchild FUSB302 Type-C Port controllers
-
-Required properties :
-- compatible : "fcs,fusb302"
-- reg : I2C slave address
-- interrupts : Interrupt specifier
-
-Required sub-node:
-- connector : The "usb-c-connector" attached to the FUSB302 IC. The bindings
- of the connector node are specified in:
-
- Documentation/devicetree/bindings/connector/usb-connector.yaml
-
-
-Example:
-
-fusb302: typec-portc@54 {
- compatible = "fcs,fusb302";
- reg = <0x54>;
- interrupt-parent = <&nmi_intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- power-role = "dual";
- try-power-role = "sink";
- source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
- PDO_VAR(3000, 12000, 3000)
- PDO_PPS_APDO(3000, 11000, 3000)>;
- op-sink-microwatt = <10000000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.yaml b/Documentation/devicetree/bindings/usb/fcs,fusb302.yaml
new file mode 100644
index 000000000000..b396ea0ab10c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fcs,fusb302.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Fairchild FUSB302 Type-C Port controller
+
+maintainers:
+ - Rob Herring <robh@kernel.org>
+
+properties:
+ compatible:
+ const: fcs,fusb302
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vbus-supply:
+ description: VBUS power supply
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vbus-supply
+ - connector
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/usb/pd.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-portc@54 {
+ compatible = "fcs,fusb302";
+ reg = <0x54>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ vbus-supply = <&vbus_typec>;
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(3000, 12000, 3000)
+ PDO_PPS_APDO(3000, 11000, 3000)>;
+ op-sink-microwatt = <10000000>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
index 01ab0f922ae8..73e7a60a0060 100644
--- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml
@@ -12,7 +12,11 @@ maintainers:
properties:
compatible:
- const: fsl,imx8mp-dwc3
+ oneOf:
+ - items:
+ - const: fsl,imx95-dwc3
+ - const: fsl,imx8mp-dwc3
+ - const: fsl,imx8mp-dwc3
reg:
items:
@@ -52,7 +56,7 @@ properties:
fsl,permanently-attached:
type: boolean
description:
- Indicates if the device atached to a downstream port is
+ Indicates if the device attached to a downstream port is
permanently attached.
fsl,disable-port-power-control:
@@ -71,6 +75,9 @@ properties:
description:
Power pad (PWR) polarity is active low.
+ power-domains:
+ maxItems: 1
+
# Required child node:
patternProperties:
@@ -82,17 +89,27 @@ required:
- reg
- "#address-cells"
- "#size-cells"
- - dma-ranges
- ranges
- clocks
- clock-names
- interrupts
+ - power-domains
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ const: fsl,imx8mp-dwc3
+ then:
+ required:
+ - dma-ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx8mp-clock.h>
+ #include <dt-bindings/power/imx8mp-power.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
usb3_0: usb@32f10100 {
compatible = "fsl,imx8mp-dwc3";
@@ -102,6 +119,7 @@ examples:
<&clk IMX8MP_CLK_USB_ROOT>;
clock-names = "hsio", "suspend";
interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_USB>;
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x40000000 0x40000000 0xc0000000>;
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml
new file mode 100644
index 000000000000..50569d3ee767
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fsl,imx8mq-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP iMX8MQ Soc USB Controller
+
+maintainers:
+ - Li Jun <jun.li@nxp.com>
+ - Peng Fan <peng.fan@nxp.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8mq-dwc3
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: fsl,imx8mq-dwc3
+ - const: snps,dwc3
+
+allOf:
+ - $ref: snps,dwc3.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mq-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb_dwc3_1: usb@38200000 {
+ compatible = "fsl,imx8mq-dwc3", "snps,dwc3";
+ reg = <0x38200000 0x10000>;
+ clocks = <&clk IMX8MQ_CLK_USB2_CTRL_ROOT>,
+ <&clk IMX8MQ_CLK_USB_CORE_REF>,
+ <&clk IMX8MQ_CLK_32K>;
+ clock-names = "bus_early", "ref", "suspend";
+ interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml
new file mode 100644
index 000000000000..ceb76394af60
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fsl,imx8qm-cdns3.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 NXP
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fsl,imx8qm-cdns3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP iMX8QM Soc USB Controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: fsl,imx8qm-usb3
+
+ reg:
+ items:
+ - description: Register set for iMX USB3 Platform Control
+
+ "#address-cells":
+ enum: [ 1, 2 ]
+
+ "#size-cells":
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ clocks:
+ items:
+ - description: Standby clock. Used during ultra low power states.
+ - description: USB bus clock for usb3 controller.
+ - description: AXI clock for AXI interface.
+ - description: ipg clock for register access.
+ - description: Core clock for usb3 controller.
+
+ clock-names:
+ items:
+ - const: lpm
+ - const: bus
+ - const: aclk
+ - const: ipg
+ - const: core
+
+ power-domains:
+ maxItems: 1
+
+# Required child node:
+
+patternProperties:
+ "^usb@[0-9a-f]+$":
+ $ref: cdns,usb3.yaml#
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-lpcg.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@5b110000 {
+ compatible = "fsl,imx8qm-usb3";
+ reg = <0x5b110000 0x10000>;
+ ranges;
+ clocks = <&usb3_lpcg IMX_LPCG_CLK_1>,
+ <&usb3_lpcg IMX_LPCG_CLK_0>,
+ <&usb3_lpcg IMX_LPCG_CLK_7>,
+ <&usb3_lpcg IMX_LPCG_CLK_4>,
+ <&usb3_lpcg IMX_LPCG_CLK_5>;
+ clock-names = "lpm", "bus", "aclk", "ipg", "core";
+ assigned-clocks = <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_MST_BUS>;
+ assigned-clock-rates = <250000000>;
+ power-domains = <&pd IMX_SC_R_USB_2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usb@5b120000 {
+ compatible = "cdns,usb3";
+ reg = <0x5b120000 0x10000>, /* memory area for OTG/DRD registers */
+ <0x5b130000 0x10000>, /* memory area for HOST registers */
+ <0x5b140000 0x10000>; /* memory area for DEVICE registers */
+ reg-names = "otg", "xhci", "dev";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "host", "peripheral", "otg", "wakeup";
+ phys = <&usb3_phy>;
+ phy-names = "cdns3,usb3-phy";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml b/Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml
new file mode 100644
index 000000000000..4784f057264a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fsl,ls1028a.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fsl,ls1028a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale layerscape SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,ls1012a-dwc3
+ - fsl,ls1043a-dwc3
+ - fsl,ls1046a-dwc3
+ - fsl,ls1088a-dwc3
+ - fsl,ls208xa-dwc3
+ - fsl,lx2160a-dwc3
+ - const: fsl,ls1028a-dwc3
+ - const: fsl,ls1028a-dwc3
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@fe800000 {
+ compatible = "fsl,ls1028a-dwc3";
+ reg = <0xfe800000 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,usb2.yaml b/Documentation/devicetree/bindings/usb/fsl,usb2.yaml
new file mode 100644
index 000000000000..caedf11db284
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fsl,usb2.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fsl,usb2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale SOC USB controllers
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description: |
+ The device node for a USB controller that is part of a Freescale
+ SOC is as described in the document "Open Firmware Recommended
+ Practice: Universal Serial Bus" with the following modifications
+ and additions.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl-usb2-mph
+ - fsl-usb2-dr
+ - items:
+ - enum:
+ - fsl-usb2-dr-v2.2
+ - fsl-usb2-dr-v2.5
+ - const: fsl-usb2-dr
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ phy_type:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ulpi, serial, utmi, utmi_wide]
+
+ port0:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates port0 is connected for fsl-usb2-mph compatible controllers.
+
+ port1:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates port1 is connected for "fsl-usb2-mph" compatible controllers.
+
+ fsl,invert-drvvbus:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ for MPC5121 USB0 only. Indicates the
+ port power polarity of internal PHY signal DRVVBUS is inverted.
+
+ fsl,invert-pwr-fault:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ for MPC5121 USB0 only. Indicates
+ the PWR_FAULT signal polarity is inverted.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - phy_type
+
+allOf:
+ - $ref: usb-drd.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ usb@22000 {
+ compatible = "fsl-usb2-mph";
+ reg = <22000 1000>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ phy_type = "ulpi";
+ port0;
+ port1;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ usb@23000 {
+ compatible = "fsl-usb2-dr";
+ reg = <23000 1000>;
+ interrupts = <26 IRQ_TYPE_EDGE_RISING>;
+ dr_mode = "otg";
+ phy_type = "ulpi";
+ };
diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
new file mode 100644
index 000000000000..d06efe4dbb3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/fsl,usbmisc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX wrapper module for Chipidea USB2 controller
+
+maintainers:
+ - Xu Yang <xu.yang_2@nxp.com>
+ - Peng Fan <peng.fan@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - fsl,imx25-usbmisc
+ - fsl,imx27-usbmisc
+ - fsl,imx35-usbmisc
+ - fsl,imx51-usbmisc
+ - fsl,imx53-usbmisc
+ - fsl,imx6q-usbmisc
+ - fsl,vf610-usbmisc
+ - nxp,s32g2-usbmisc
+ - nxp,s32g3-usbmisc
+ - items:
+ - enum:
+ - fsl,imx6ul-usbmisc
+ - fsl,imx6sl-usbmisc
+ - fsl,imx6sx-usbmisc
+ - fsl,imx7d-usbmisc
+ - const: fsl,imx6q-usbmisc
+ - items:
+ - enum:
+ - fsl,imx7ulp-usbmisc
+ - fsl,imx8mm-usbmisc
+ - fsl,imx8mn-usbmisc
+ - fsl,imx8ulp-usbmisc
+ - fsl,imx94-usbmisc
+ - fsl,imx95-usbmisc
+ - const: fsl,imx7d-usbmisc
+ - const: fsl,imx6q-usbmisc
+ - items:
+ - const: fsl,imx6sll-usbmisc
+ - const: fsl,imx6ul-usbmisc
+ - const: fsl,imx6q-usbmisc
+
+ clocks:
+ maxItems: 1
+
+ reg:
+ minItems: 1
+ items:
+ - description: Base and length of the Wrapper module register
+ - description: Base and length of the HSIO Block Control register
+
+ '#index-cells':
+ const: 1
+ description: Cells used to describe usb controller index.
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ # imx95 soc needs use HSIO Block Control
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx95-usbmisc
+ then:
+ properties:
+ reg:
+ minItems: 2
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ usbmisc@2184800 {
+ compatible = "fsl,imx6q-usbmisc";
+ reg = <0x02184800 0x200>;
+ #index-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt b/Documentation/devicetree/bindings/usb/fsl-usb.txt
deleted file mode 100644
index 0b08b006c5ea..000000000000
--- a/Documentation/devicetree/bindings/usb/fsl-usb.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-Freescale SOC USB controllers
-
-The device node for a USB controller that is part of a Freescale
-SOC is as described in the document "Open Firmware Recommended
-Practice : Universal Serial Bus" with the following modifications
-and additions :
-
-Required properties :
- - compatible : Should be "fsl-usb2-mph" for multi port host USB
- controllers, or "fsl-usb2-dr" for dual role USB controllers
- or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121.
- Wherever applicable, the IP version of the USB controller should
- also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132).
- - phy_type : For multi port host USB controllers, should be one of
- "ulpi", or "serial". For dual role USB controllers, should be
- one of "ulpi", "utmi", "utmi_wide", or "serial".
- - reg : Offset and length of the register set for the device
- - port0 : boolean; if defined, indicates port0 is connected for
- fsl-usb2-mph compatible controllers. Either this property or
- "port1" (or both) must be defined for "fsl-usb2-mph" compatible
- controllers.
- - port1 : boolean; if defined, indicates port1 is connected for
- fsl-usb2-mph compatible controllers. Either this property or
- "port0" (or both) must be defined for "fsl-usb2-mph" compatible
- controllers.
- - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
- controllers. Can be "host", "peripheral", or "otg". Default to
- "host" if not defined for backward compatibility.
-
-Recommended properties :
- - interrupts : <a b> where a is the interrupt number and b is a
- field that represents an encoding of the sense and level
- information for the interrupt. This should be encoded based on
- the information in section 2) depending on the type of interrupt
- controller you have.
-
-Optional properties :
- - fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
- port power polarity of internal PHY signal DRVVBUS is inverted.
- - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
- the PWR_FAULT signal polarity is inverted.
-
-Example multi port host USB controller device node :
- usb@22000 {
- compatible = "fsl-usb2-mph";
- reg = <22000 1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <700>;
- interrupts = <27 1>;
- phy_type = "ulpi";
- port0;
- port1;
- };
-
-Example dual role USB controller device node :
- usb@23000 {
- compatible = "fsl-usb2-dr";
- reg = <23000 1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <700>;
- interrupts = <26 1>;
- dr_mode = "otg";
- phy = "ulpi";
- };
-
-Example dual role USB controller device node for MPC5121ADS:
-
- usb@4000 {
- compatible = "fsl,mpc5121-usb2-dr";
- reg = <0x4000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = < &ipic >;
- interrupts = <44 0x8>;
- dr_mode = "otg";
- phy_type = "utmi_wide";
- fsl,invert-drvvbus;
- fsl,invert-pwr-fault;
- };
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 079f7cff0c24..4e84bead0232 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/usb/generic-ehci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: USB EHCI Controller Device Tree Bindings
+title: USB EHCI Controller
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
allOf:
- - $ref: "usb-hcd.yaml"
+ - $ref: usb-hcd.yaml
- if:
properties:
compatible:
@@ -28,8 +28,11 @@ properties:
- items:
- enum:
- allwinner,sun4i-a10-ehci
+ - allwinner,sun50i-a100-ehci
- allwinner,sun50i-a64-ehci
- allwinner,sun50i-h6-ehci
+ - allwinner,sun50i-h616-ehci
+ - allwinner,sun55i-a523-ehci
- allwinner,sun5i-a13-ehci
- allwinner,sun6i-a31-ehci
- allwinner,sun7i-a20-ehci
@@ -37,11 +40,13 @@ properties:
- allwinner,sun8i-a83t-ehci
- allwinner,sun8i-h3-ehci
- allwinner,sun8i-r40-ehci
+ - allwinner,sun8i-v3s-ehci
- allwinner,sun9i-a80-ehci
- allwinner,sun20i-d1-ehci
- aspeed,ast2400-ehci
- aspeed,ast2500-ehci
- aspeed,ast2600-ehci
+ - aspeed,ast2700-ehci
- brcm,bcm3384-ehci
- brcm,bcm63268-ehci
- brcm,bcm6328-ehci
@@ -60,11 +65,13 @@ properties:
- ibm,476gtr-ehci
- nxp,lpc1850-ehci
- qca,ar7100-ehci
+ - rockchip,rk3588-ehci
- snps,hsdk-v1.0-ehci
- socionext,uniphier-ehci
- const: generic-ehci
- items:
- enum:
+ - atmel,at91sam9g45-ehci
- cavium,octeon-6335-ehci
- ibm,usb-ehci-440epx
- ibm,usb-ehci-460ex
@@ -73,7 +80,14 @@ properties:
- const: usb-ehci
- enum:
- generic-ehci
+ - marvell,ac5-ehci
+ - marvell,armada-3700-ehci
+ - marvell,orion-ehci
+ - nuvoton,npcm750-ehci
+ - nuvoton,npcm845-ehci
+ - ti,ehci-omap
- usb-ehci
+ - via,vt8500-ehci
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index 180361b79f52..3ee1586fc8b9 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -4,10 +4,7 @@
$id: http://devicetree.org/schemas/usb/generic-ohci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: USB OHCI Controller Device Tree Bindings
-
-allOf:
- - $ref: "usb-hcd.yaml"
+title: USB OHCI Controller
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -18,8 +15,11 @@ properties:
- items:
- enum:
- allwinner,sun4i-a10-ohci
+ - allwinner,sun50i-a100-ohci
- allwinner,sun50i-a64-ohci
- allwinner,sun50i-h6-ohci
+ - allwinner,sun50i-h616-ohci
+ - allwinner,sun55i-a523-ohci
- allwinner,sun5i-a13-ohci
- allwinner,sun6i-a31-ohci
- allwinner,sun7i-a20-ohci
@@ -27,6 +27,7 @@ properties:
- allwinner,sun8i-a83t-ohci
- allwinner,sun8i-h3-ohci
- allwinner,sun8i-r40-ohci
+ - allwinner,sun8i-v3s-ohci
- allwinner,sun9i-a80-ohci
- allwinner,sun20i-d1-ohci
- brcm,bcm3384-ohci
@@ -46,9 +47,19 @@ properties:
- hpe,gxp-ohci
- ibm,476gtr-ohci
- ingenic,jz4740-ohci
+ - rockchip,rk3588-ohci
- snps,hsdk-v1.0-ohci
- const: generic-ohci
- - const: generic-ohci
+ - enum:
+ - generic-ohci
+ - ti,ohci-omap3
+ - items:
+ - enum:
+ - cavium,octeon-6335-ohci
+ - nintendo,hollywood-usb-ohci
+ - nxp,ohci-nxp
+ - st,spear600-ohci
+ - const: usb-ohci
reg:
maxItems: 1
@@ -62,7 +73,7 @@ properties:
clocks:
minItems: 1
- maxItems: 3
+ maxItems: 4
description: |
In case the Renesas R-Car Gen3 SoCs:
- if a host only channel: first clock should be host.
@@ -118,12 +129,44 @@ properties:
- host
- otg
+ transceiver:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ The associated ISP1301 device. Necessary for the UDC controller for
+ connecting to the USB physical layer.
+
required:
- compatible
- reg
- interrupts
-additionalProperties: false
+allOf:
+ - $ref: usb-hcd.yaml
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: nxp,ohci-nxp
+ then:
+ properties:
+ transceiver: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-ohci
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ else:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
index 23d73df96ea3..62678abd74b5 100644
--- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -4,27 +4,32 @@
$id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: USB xHCI Controller Device Tree Bindings
+title: USB xHCI Controller
maintainers:
- Mathias Nyman <mathias.nyman@intel.com>
-allOf:
- - $ref: "usb-xhci.yaml#"
-
properties:
compatible:
oneOf:
- description: Generic xHCI device
const: generic-xhci
- - description: Armada 37xx/375/38x/8k SoCs
+ - description: Armada 375/38x SoCs
items:
- enum:
- - marvell,armada3700-xhci
- marvell,armada-375-xhci
- marvell,armada-380-xhci
+ - description: Armada 37xx/8k SoCs
+ items:
+ - enum:
+ - marvell,armada3700-xhci
- marvell,armada-8k-xhci
- const: generic-xhci
+ - description: Broadcom SoCs with power domains
+ items:
+ - enum:
+ - brcm,bcm2711-xhci
+ - const: brcm,xhci-brcm-v2
- description: Broadcom STB SoCs with xHCI
enum:
- brcm,xhci-brcm-v2
@@ -49,6 +54,19 @@ properties:
- const: core
- const: reg
+ dma-coherent: true
+
+ dr_mode:
+ enum:
+ - host
+ - otg
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
unevaluatedProperties: false
required:
@@ -56,6 +74,20 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: usb-xhci.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm2711-xhci
+ then:
+ required:
+ - power-domains
+ else:
+ properties:
+ power-domains: false
+
examples:
- |
usb@f0931000 {
diff --git a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
new file mode 100644
index 000000000000..9a94b2a74a1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/genesys,gl850g.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Genesys Logic USB hub controller
+
+maintainers:
+ - Icenowy Zheng <uwu@icenowy.me>
+
+properties:
+ compatible:
+ enum:
+ - usb5e3,608
+ - usb5e3,610
+ - usb5e3,620
+ - usb5e3,626
+
+ reg: true
+
+ reset-gpios:
+ description: GPIO controlling the RESET# pin.
+
+ vdd-supply:
+ description:
+ The regulator that provides 3.3V or 5.0V core power to the hub.
+
+ peer-hub: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ '^port@':
+ $ref: /schemas/graph.yaml#/properties/port
+
+ properties:
+ reg:
+ minimum: 1
+ maximum: 4
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: usb-hub.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - usb5e3,608
+ then:
+ properties:
+ peer-hub: false
+ vdd-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - usb5e3,610
+ - usb5e3,620
+ then:
+ properties:
+ peer-hub: true
+ vdd-supply: true
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ usb {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub: hub@1 {
+ compatible = "usb5e3,608";
+ reg = <1>;
+ reset-gpios = <&pio 7 2 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ usb {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb5e3,610";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&vcc_5v>;
+ };
+
+ /* 3.1 hub on port 4 */
+ hub_3_0: hub@2 {
+ compatible = "usb5e3,620";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&vcc_5v>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
new file mode 100644
index 000000000000..793662f6f3bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO-based SBU mux
+
+maintainers:
+ - Bjorn Andersson <andersson@kernel.org>
+
+description:
+ In USB Type-C applications the SBU lines needs to be connected, disconnected
+ and swapped depending on the altmode and orientation. This binding describes
+ a family of hardware solutions which switches between these modes using GPIO
+ signals.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nxp,cbdtu02043
+ - onnn,fsusb42
+ - onnn,fsusb43l10x
+ - pericom,pi3usb102
+ - ti,tmuxhs4212
+ - const: gpio-sbu-mux
+
+ enable-gpios:
+ description: Switch enable GPIO
+
+ select-gpios:
+ description: Orientation select
+
+ vcc-supply:
+ description: power supply
+
+ mode-switch: true
+ orientation-switch: true
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the SBU mux to a TypeC controller for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - select-gpios
+ - orientation-switch
+ - port
+
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+ - if:
+ required:
+ - mode-switch
+ then:
+ required:
+ - enable-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ tcpm {
+ connector {
+ compatible = "usb-c-connector";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tcpm_hs_out: endpoint {
+ remote-endpoint = <&usb_hs_phy_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ tcpm_ss_out: endpoint {
+ remote-endpoint = <&usb_ss_phy_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ tcpm_sbu_out: endpoint {
+ remote-endpoint = <&sbu_mux_in>;
+ };
+ };
+ };
+ };
+ };
+
+ sbu-mux {
+ compatible = "pericom,pi3usb102", "gpio-sbu-mux";
+
+ enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
+ select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ sbu_mux_in: endpoint {
+ remote-endpoint = <&tcpm_sbu_out>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/hisilicon,hi3798mv200-dwc3.yaml b/Documentation/devicetree/bindings/usb/hisilicon,hi3798mv200-dwc3.yaml
new file mode 100644
index 000000000000..f3011694393d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/hisilicon,hi3798mv200-dwc3.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/hisilicon,hi3798mv200-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon Hi3798MV200 DWC3 USB SoC controller
+
+maintainers:
+ - Yang Xiwen <forbidden405@foxmail.com>
+
+properties:
+ compatible:
+ const: hisilicon,hi3798mv200-dwc3
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
+
+ clocks:
+ items:
+ - description: Controller bus clock
+ - description: Controller suspend clock
+ - description: Controller reference clock
+ - description: Controller gm clock
+ - description: Controller gs clock
+ - description: Controller utmi clock
+ - description: Controller pipe clock
+
+ clock-names:
+ items:
+ - const: bus
+ - const: suspend
+ - const: ref
+ - const: gm
+ - const: gs
+ - const: utmi
+ - const: pipe
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: soft
+
+patternProperties:
+ '^usb@[0-9a-f]+$':
+ $ref: snps,dwc3.yaml#
+
+required:
+ - compatible
+ - ranges
+ - '#address-cells'
+ - '#size-cells'
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb {
+ compatible = "hisilicon,hi3798mv200-dwc3";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&clk_bus>,
+ <&clk_suspend>,
+ <&clk_ref>,
+ <&clk_gm>,
+ <&clk_gs>,
+ <&clk_utmi>,
+ <&clk_pipe>;
+ clock-names = "bus", "suspend", "ref", "gm", "gs", "utmi", "pipe";
+ resets = <&crg 0xb0 12>;
+ reset-names = "soft";
+
+ usb@98a0000 {
+ compatible = "snps,dwc3";
+ reg = <0x98a0000 0x10000>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_bus>,
+ <&clk_suspend>,
+ <&clk_ref>;
+ clock-names = "bus_early", "suspend", "ref";
+ phys = <&usb2_phy1_port2>, <&combphy0 0>;
+ phy-names = "usb2-phy", "usb3-phy";
+ maximum-speed = "super-speed";
+ dr_mode = "host";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml
index 59212358fcce..4cc1496a913c 100644
--- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml
+++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/ingenic,musb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Ingenic JZ47xx USB IP DT bindings
+title: Ingenic JZ47xx USB IP
maintainers:
- Paul Cercueil <paul@crapouillou.net>
diff --git a/Documentation/devicetree/bindings/usb/intel,ixp4xx-udc.yaml b/Documentation/devicetree/bindings/usb/intel,ixp4xx-udc.yaml
new file mode 100644
index 000000000000..4ed602746897
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/intel,ixp4xx-udc.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,ixp4xx-udc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel IXP4xx SoC USB Device Controller (UDC)
+
+description: The IXP4xx SoCs has a full-speed USB Device
+ Controller with 16 endpoints and a built-in transceiver.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ const: intel,ixp4xx-udc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ usb@c800b000 {
+ compatible = "intel,ixp4xx-udc";
+ reg = <0xc800b000 0x1000>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
index d3511f48cd55..1a75544a8c31 100644
--- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
@@ -58,20 +58,20 @@ examples:
#define KEEM_BAY_A53_AUX_USB_SUSPEND
usb {
- compatible = "intel,keembay-dwc3";
- clocks = <&scmi_clk KEEM_BAY_A53_AUX_USB>,
- <&scmi_clk KEEM_BAY_A53_AUX_USB_REF>,
- <&scmi_clk KEEM_BAY_A53_AUX_USB_ALT_REF>,
- <&scmi_clk KEEM_BAY_A53_AUX_USB_SUSPEND>;
- clock-names = "async_master", "ref", "alt_ref", "suspend";
- ranges;
- #address-cells = <1>;
- #size-cells = <1>;
-
- usb@34000000 {
- compatible = "snps,dwc3";
- reg = <0x34000000 0x10000>;
- interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
- dr_mode = "peripheral";
- };
+ compatible = "intel,keembay-dwc3";
+ clocks = <&scmi_clk KEEM_BAY_A53_AUX_USB>,
+ <&scmi_clk KEEM_BAY_A53_AUX_USB_REF>,
+ <&scmi_clk KEEM_BAY_A53_AUX_USB_ALT_REF>,
+ <&scmi_clk KEEM_BAY_A53_AUX_USB_SUSPEND>;
+ clock-names = "async_master", "ref", "alt_ref", "suspend";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usb@34000000 {
+ compatible = "snps,dwc3";
+ reg = <0x34000000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "peripheral";
+ };
};
diff --git a/Documentation/devicetree/bindings/usb/isp1301.txt b/Documentation/devicetree/bindings/usb/isp1301.txt
deleted file mode 100644
index ecd607dacba5..000000000000
--- a/Documentation/devicetree/bindings/usb/isp1301.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* NXP ISP1301 USB transceiver
-
-Required properties:
-- compatible: must be "nxp,isp1301"
-- reg: I2C address of the ISP1301 device
-
-Optional properties of devices using ISP1301:
-- transceiver: phandle of isp1301 - this helps the ISP1301 driver to find the
- ISP1301 instance associated with the respective USB driver
-
-Example:
-
- isp1301: usb-transceiver@2c {
- compatible = "nxp,isp1301";
- reg = <0x2c>;
- };
-
- usbd@31020000 {
- compatible = "nxp,lpc3220-udc";
- reg = <0x31020000 0x300>;
- interrupt-parent = <&mic>;
- interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
- transceiver = <&isp1301>;
- };
diff --git a/Documentation/devicetree/bindings/usb/ite,it5205.yaml b/Documentation/devicetree/bindings/usb/ite,it5205.yaml
new file mode 100644
index 000000000000..889710733de5
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ite,it5205.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ite,it5205.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE IT5202 Type-C USB Alternate Mode Passive MUX
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ - Tianping Fang <tianping.fang@mediatek.com>
+
+properties:
+ compatible:
+ const: ite,it5205
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: Power supply for VCC pin (3.3V)
+
+ mode-switch:
+ description: Flag the port as possible handle of altmode switching
+ type: boolean
+
+ orientation-switch:
+ description: Flag the port as possible handler of orientation switching
+ type: boolean
+
+ ite,ovp-enable:
+ description: Enable Over Voltage Protection functionality
+ type: boolean
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the IT5205 to a TypeC controller for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+ - orientation-switch
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@48 {
+ compatible = "ite,it5205";
+ reg = <0x48>;
+
+ mode-switch;
+ orientation-switch;
+
+ vcc-supply = <&mt6359_vibr_ldo_reg>;
+
+ port {
+ it5205_usbss_sbu: endpoint {
+ remote-endpoint = <&typec_controller>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt
deleted file mode 100644
index 29f12a533f66..000000000000
--- a/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* NXP LPC32xx SoC USB Device Controller (UDC)
-
-Required properties:
-- compatible: Must be "nxp,lpc3220-udc"
-- reg: Physical base address of the controller and length of memory mapped
- region.
-- interrupts: The USB interrupts:
- * USB Device Low Priority Interrupt
- * USB Device High Priority Interrupt
- * USB Device DMA Interrupt
- * External USB Transceiver Interrupt (OTG ATX)
-- transceiver: phandle of the associated ISP1301 device - this is necessary for
- the UDC controller for connecting to the USB physical layer
-
-Example:
-
- isp1301: usb-transceiver@2c {
- compatible = "nxp,isp1301";
- reg = <0x2c>;
- };
-
- usbd@31020000 {
- compatible = "nxp,lpc3220-udc";
- reg = <0x31020000 0x300>;
- interrupt-parent = <&mic>;
- interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
- transceiver = <&isp1301>;
- };
diff --git a/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml b/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
index 3cf93dd45eb7..a0246aa1f236 100644
--- a/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/usb/marvell,pxau2o-ehci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell PXA/MMP EHCI bindings
+title: Marvell PXA/MMP EHCI
maintainers:
- Lubomir Rintel <lkundrak@v3.sk>
diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
index 93a19eda610b..3de4dc40b791 100644
--- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
+++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/maxim,max33359.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/maxim,max33359.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Maxim TCPCI Type-C PD controller DT bindings
+title: Maxim TCPCI Type-C PD controller
maintainers:
- Badhri Jagan Sridharan <badhri@google.com>
@@ -13,8 +13,12 @@ description: Maxim TCPCI Type-C PD controller
properties:
compatible:
- enum:
- - maxim,max33359
+ oneOf:
+ - enum:
+ - maxim,max33359
+ - items:
+ - const: maxim,max77759-tcpci
+ - const: maxim,max33359
reg:
maxItems: 1
@@ -40,7 +44,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/usb/pd.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -69,6 +73,8 @@ examples:
PDO_FIXED_DATA_SWAP |
PDO_FIXED_DUAL_ROLE)
PDO_FIXED(9000, 2000, 0)>;
+ sink-bc12-completion-time-ms = <500>;
+ pd-revision = /bits/ 8 <0x03 0x01 0x01 0x08>;
};
};
};
diff --git a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml
index 1d893d3d3432..6edb1fc5044e 100644
--- a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml
+++ b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml
@@ -50,18 +50,18 @@ additionalProperties: false
examples:
- |
- #include <dt-bindings/gpio/gpio.h>
- #include <dt-bindings/interrupt-controller/irq.h>
- spi0 {
- #address-cells = <1>;
- #size-cells = <0>;
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
- udc@0 {
- compatible = "maxim,max3420-udc";
- reg = <0>;
- interrupt-parent = <&gpio>;
- interrupts = <0 IRQ_TYPE_EDGE_FALLING>, <10 IRQ_TYPE_EDGE_BOTH>;
- interrupt-names = "udc", "vbus";
- spi-max-frequency = <12500000>;
- };
- };
+ udc@0 {
+ compatible = "maxim,max3420-udc";
+ reg = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>, <10 IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "udc", "vbus";
+ spi-max-frequency = <12500000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
index 8db1f8b597c3..053264e60583 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT bindings
+title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller
maintainers:
- ChiYuan Huang <cy_huang@richtek.com>
@@ -43,7 +43,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/usb/pd.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml
new file mode 100644
index 000000000000..747d0f16d9b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/mediatek,mt6370-tcpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediatTek MT6370 Type-C Port Switch and Power Delivery controller
+
+maintainers:
+ - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+ MediaTek MT6370 is a multi-functional device.
+ It integrates charger, ADC, flash, RGB indicators,
+ regulators (DSV/VIBLDO), and TypeC Port Switch with Power Delivery controller.
+ This document only describes MT6370 Type-C Port Switch and
+ Power Delivery controller.
+
+properties:
+ compatible:
+ enum:
+ - mediatek,mt6370-tcpc
+
+ interrupts:
+ maxItems: 1
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - interrupts
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index b0e58b15b9ae..231e6f35a986 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -5,13 +5,13 @@
$id: http://devicetree.org/schemas/usb/mediatek,mtk-xhci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek USB3 xHCI Device Tree Bindings
+title: MediaTek USB3 xHCI
maintainers:
- Chunfeng Yun <chunfeng.yun@mediatek.com>
allOf:
- - $ref: "usb-xhci.yaml"
+ - $ref: usb-xhci.yaml
description: |
There are two scenarios:
@@ -28,12 +28,16 @@ properties:
- mediatek,mt7622-xhci
- mediatek,mt7623-xhci
- mediatek,mt7629-xhci
+ - mediatek,mt7986-xhci
+ - mediatek,mt7988-xhci
- mediatek,mt8173-xhci
- mediatek,mt8183-xhci
- mediatek,mt8186-xhci
- mediatek,mt8188-xhci
+ - mediatek,mt8189-xhci
- mediatek,mt8192-xhci
- mediatek,mt8195-xhci
+ - mediatek,mt8365-xhci
- const: mediatek,mtk-xhci
reg:
@@ -75,6 +79,7 @@ properties:
- description: Mcu bus clock for register access
- description: DMA bus clock for data transfer
- description: controller clock
+ - description: frame count clock
clock-names:
minItems: 1
@@ -84,14 +89,7 @@ properties:
- const: mcu_ck
- const: dma_ck
- const: xhci_ck
-
- assigned-clocks:
- minItems: 1
- maxItems: 5
-
- assigned-clock-parents:
- minItems: 1
- maxItems: 5
+ - const: frmcnt_ck
phys:
description:
@@ -109,6 +107,10 @@ properties:
- description: USB3/SS(P) PHY
- description: USB2/HS PHY
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) Output endpoint to a Type-C connector
+
vusb33-supply:
description: Regulator of USB AVDD3.3v
@@ -128,6 +130,17 @@ properties:
defined in the xHCI spec on MTK's controller.
default: 5000
+ rx-fifo-depth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ It is a quirk used to work around Gen1 isoc-in endpoint transfer issue
+ that still send out unexpected ACK after device finishes the burst
+ transfer with a short packet and cause an exception, specially on a 4K
+ camera device, it happens on controller before about IPM v1.6.0;
+ the side-effect is that it may cause performance drop about 10%,
+ including bulk transfer, prefer to use 3k here. The size is in bytes.
+ enum: [1024, 2048, 3072, 4096]
+
# the following properties are only used for case 1
wakeup-source:
description: enable USB remote wakeup, see power/wakeup-source.txt
@@ -156,7 +169,8 @@ properties:
104 - used by mt8195, IP1, specific 1.04;
105 - used by mt8195, IP2, specific 1.05;
106 - used by mt8195, IP3, specific 1.06;
- enum: [1, 2, 101, 102, 103, 104, 105, 106]
+ 110 - used by mt8189, IP4, specific 1.10;
+ enum: [1, 2, 101, 102, 103, 104, 105, 106, 110]
mediatek,u3p-dis-msk:
$ref: /schemas/types.yaml#/definitions/uint32
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
index b019d490170d..21fc6bbe954f 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
@@ -5,13 +5,13 @@
$id: http://devicetree.org/schemas/usb/mediatek,mtu3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek USB3 DRD Controller Device Tree Bindings
+title: MediaTek USB3 DRD Controller
maintainers:
- Chunfeng Yun <chunfeng.yun@mediatek.com>
allOf:
- - $ref: "usb-drd.yaml"
+ - $ref: usb-drd.yaml
description: |
The DRD controller has a glue layer IPPC (IP Port Control), and its host is
@@ -24,9 +24,11 @@ properties:
- mediatek,mt2712-mtu3
- mediatek,mt8173-mtu3
- mediatek,mt8183-mtu3
+ - mediatek,mt8186-mtu3
- mediatek,mt8188-mtu3
- mediatek,mt8192-mtu3
- mediatek,mt8195-mtu3
+ - mediatek,mt8365-mtu3
- const: mediatek,mtu3
reg:
@@ -64,6 +66,8 @@ properties:
- description: Reference clock used by low power mode etc
- description: Mcu bus clock for register access
- description: DMA bus clock for data transfer
+ - description: DRD controller clock
+ - description: Frame count clock
clock-names:
minItems: 1
@@ -72,6 +76,8 @@ properties:
- const: ref_ck
- const: mcu_ck
- const: dma_ck
+ - const: xhci_ck
+ - const: frmcnt_ck
phys:
description:
@@ -149,6 +155,18 @@ properties:
property is used. See graph.txt
$ref: /schemas/graph.yaml#/properties/port
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: High Speed (HS) data bus.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) data bus.
+
enable-manual-drd:
$ref: /schemas/types.yaml#/definitions/flag
description:
@@ -179,7 +197,10 @@ properties:
2 - used by mt2712 etc, revision 2 with following IPM rule;
101 - used by mt8183, specific 1.01;
102 - used by mt8192, specific 1.02;
- enum: [1, 2, 101, 102]
+ 103 - used by mt8195, IP0, specific 1.03;
+ 105 - used by mt8195, IP2, specific 1.05;
+ 106 - used by mt8195, IP3, specific 1.06;
+ enum: [1, 2, 101, 102, 103, 105, 106]
mediatek,u3p-dis-msk:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -202,9 +223,9 @@ patternProperties:
example if the host mode is enabled.
dependencies:
- connector: [ 'usb-role-switch' ]
- port: [ 'usb-role-switch' ]
- role-switch-default-mode: [ 'usb-role-switch' ]
+ connector: [ usb-role-switch ]
+ port: [ usb-role-switch ]
+ role-switch-default-mode: [ usb-role-switch ]
wakeup-source: [ 'mediatek,syscon-wakeup' ]
required:
@@ -298,7 +319,7 @@ examples:
# Dual role switch with type-c
- |
usb@11201000 {
- compatible ="mediatek,mt8183-mtu3", "mediatek,mtu3";
+ compatible = "mediatek,mt8183-mtu3", "mediatek,mtu3";
reg = <0x11201000 0x2e00>, <0x11203e00 0x0100>;
reg-names = "mac", "ippc";
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
index 11a33f9b1f17..a39d38db7714 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
@@ -5,7 +5,7 @@
$id: http://devicetree.org/schemas/usb/mediatek,musb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek MUSB DRD/OTG Controller Device Tree Bindings
+title: MediaTek MUSB DRD/OTG Controller
maintainers:
- Min Guo <min.guo@mediatek.com>
@@ -68,8 +68,8 @@ properties:
type: object
dependencies:
- usb-role-switch: [ 'connector' ]
- connector: [ 'usb-role-switch' ]
+ usb-role-switch: [ connector ]
+ connector: [ usb-role-switch ]
required:
- compatible
diff --git a/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml
index 48c458c65848..a812317d8089 100644
--- a/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/microchip,mpfs-musb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Microchip MPFS USB Controller Device Tree Bindings
+title: Microchip MPFS USB Controller
allOf:
- $ref: usb-drd.yaml#
@@ -14,8 +14,11 @@ maintainers:
properties:
compatible:
- enum:
- - microchip,mpfs-musb
+ oneOf:
+ - items:
+ - const: microchip,pic64gx-musb
+ - const: microchip,mpfs-musb
+ - const: microchip,mpfs-musb
dr_mode: true
@@ -34,6 +37,13 @@ properties:
clocks:
maxItems: 1
+ microchip,ext-vbus-drv:
+ description:
+ Some ULPI USB PHYs do not support an internal VBUS supply and driving
+ the CPEN pin requires the configuration of the UPLI_USE__EXTVBUS
+ bit in ULPI_BUSCONTROL.
+ $ref: /schemas/types.yaml#/definitions/flag
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
new file mode 100644
index 000000000000..4e3901efed3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/microchip,usb2514.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip USB2514 Hub Controller
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - usb424,2412
+ - usb424,2417
+ - usb424,2514
+ - usb424,2517
+ - items:
+ - enum:
+ - usb424,2512
+ - usb424,2513
+ - const: usb424,2514
+
+ reg: true
+
+ reset-gpios:
+ description: GPIO connected to the RESET_N pin.
+
+ vdd-supply:
+ description: 3.3V power supply.
+
+ vdda-supply:
+ description: 3.3V analog power supply.
+
+ clocks:
+ description: External 24MHz clock connected to the CLKIN pin.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^.*@[0-9a-f]{1,2}$":
+ description: The hard wired USB devices
+ type: object
+ $ref: /schemas/usb/usb-device.yaml
+ additionalProperties: true
+
+allOf:
+ - $ref: usb-device.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: usb424,2514
+ then:
+ properties:
+ vdda-supply: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb-hub@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&reg_3v3_hub>;
+ vdda-supply = <&reg_3v3a_hub>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usbb95,772b";
+ reg = <1>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
new file mode 100644
index 000000000000..c68c04da3399
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/microchip,usb5744.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip USB5744 4-port Hub Controller
+
+description:
+ Microchip's USB5744 SmartHubTM IC is a 4 port, SuperSpeed (SS)/Hi-Speed (HS),
+ low power, low pin count configurable and fully compliant with the USB 3.1
+ Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low Speed
+ (LS) USB signaling, offering complete coverage of all defined USB operating
+ speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0
+ controller, so 5 Gbps SuperSpeed data transfers are not affected by slower
+ USB 2.0 traffic.
+
+maintainers:
+ - Michal Simek <michal.simek@amd.com>
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
+
+properties:
+ compatible:
+ enum:
+ - usb424,2744
+ - usb424,5744
+ - microchip,usb5744
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the GRST# pin.
+
+ vdd-supply:
+ description:
+ 3V3 power supply to the hub
+
+ vdd2-supply:
+ description:
+ 1V2 power supply to the hub
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+ i2c-bus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle of an usb hub connected via i2c bus.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,usb5744
+ then:
+ properties:
+ reset-gpios: false
+ vdd-supply: false
+ vdd2-supply: false
+ peer-hub: false
+ i2c-bus: false
+ else:
+ $ref: /schemas/usb/usb-device.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c: i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hub: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
+ };
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ i2c-bus = <&hub>;
+ reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ i2c-bus = <&hub>;
+ reset-gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
deleted file mode 100644
index 8654a3ec23e4..000000000000
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-MSM SoC HSUSB controllers
-
-EHCI
-
-Required properties:
-- compatible: Should contain "qcom,ehci-host"
-- regs: offset and length of the register set in the memory map
-- usb-phy: phandle for the PHY device
-
-Example EHCI controller device node:
-
- ehci: ehci@f9a55000 {
- compatible = "qcom,ehci-host";
- reg = <0xf9a55000 0x400>;
- usb-phy = <&usb_otg>;
- };
-
-USB PHY with optional OTG:
-
-Required properties:
-- compatible: Should contain:
- "qcom,usb-otg-ci" for chipsets with ChipIdea 45nm PHY
- "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
-
-- regs: Offset and length of the register set in the memory map
-- interrupts: interrupt-specifier for the OTG interrupt.
-
-- clocks: A list of phandle + clock-specifier pairs for the
- clocks listed in clock-names
-- clock-names: Should contain the following:
- "phy" USB PHY reference clock
- "core" Protocol engine clock
- "iface" Interface bus clock
- "alt_core" Protocol engine clock for targets with asynchronous
- reset methodology. (optional)
-
-- vdccx-supply: phandle to the regulator for the vdd supply for
- digital circuit operation.
-- v1p8-supply: phandle to the regulator for the 1.8V supply
-- v3p3-supply: phandle to the regulator for the 3.3V supply
-
-- resets: A list of phandle + reset-specifier pairs for the
- resets listed in reset-names
-- reset-names: Should contain the following:
- "phy" USB PHY controller reset
- "link" USB LINK controller reset
-
-- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of
- 1 - PHY control
- 2 - PMIC control
-
-Optional properties:
-- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
-
-- switch-gpio: A phandle + gpio-specifier pair. Some boards are using Dual
- SPDT USB Switch, witch is cotrolled by GPIO to de/multiplex
- D+/D- USB lines between connectors.
-
-- qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device
- Mode Eye Diagram test. Start address at which these values will be
- written is ULPI_EXT_VENDOR_SPECIFIC. Value of -1 is reserved as
- "do not overwrite default value at this address".
- For example: qcom,phy-init-sequence = < -1 0x63 >;
- Will update only value at address ULPI_EXT_VENDOR_SPECIFIC + 1.
-
-- qcom,phy-num: Select number of pyco-phy to use, can be one of
- 0 - PHY one, default
- 1 - Second PHY
- Some platforms may have configuration to allow USB
- controller work with any of the two HSPHYs present.
-
-- qcom,vdd-levels: This property must be a list of three integer values
- (no, min, max) where each value represents either a voltage
- in microvolts or a value corresponding to voltage corner.
-
-- qcom,manual-pullup: If present, vbus is not routed to USB controller/phy
- and controller driver therefore enables pull-up explicitly
- before starting controller using usbcmd run/stop bit.
-
-- extcon: phandles to external connector devices. First phandle
- should point to external connector, which provide "USB"
- cable events, the second should point to external connector
- device, which provide "USB-HOST" cable events. If one of
- the external connector devices is not required empty <0>
- phandle should be specified.
-
-Example HSUSB OTG controller device node:
-
- usb@f9a55000 {
- compatible = "qcom,usb-otg-snps";
- reg = <0xf9a55000 0x400>;
- interrupts = <0 134 0>;
- dr_mode = "peripheral";
-
- clocks = <&gcc GCC_XO_CLK>, <&gcc GCC_USB_HS_SYSTEM_CLK>,
- <&gcc GCC_USB_HS_AHB_CLK>;
-
- clock-names = "phy", "core", "iface";
-
- vddcx-supply = <&pm8841_s2_corner>;
- v1p8-supply = <&pm8941_l6>;
- v3p3-supply = <&pm8941_l24>;
-
- resets = <&gcc GCC_USB2A_PHY_BCR>, <&gcc GCC_USB_HS_BCR>;
- reset-names = "phy", "link";
-
- qcom,otg-control = <1>;
- qcom,phy-init-sequence = < -1 0x63 >;
- qcom,vdd-levels = <1 5 7>;
- };
diff --git a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
deleted file mode 100644
index 5a0f1f14fbfa..000000000000
--- a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Nuvoton NPCM7XX SoC USB controllers:
------------------------------
-
-EHCI:
------
-
-Required properties:
-- compatible: "nuvoton,npcm750-ehci"
-- interrupts: Should contain the EHCI interrupt
-- reg: Physical address and length of the register set for the device
-
-Example:
-
- ehci1: usb@f0806000 {
- compatible = "nuvoton,npcm750-ehci";
- reg = <0xf0806000 0x1000>;
- interrupts = <0 61 4>;
- };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
index fd6e7c81426e..c6e661e8915c 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/nvidia,tegra-xudc.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/nvidia,tegra-xudc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Device tree binding for NVIDIA Tegra XUSB device mode controller (XUDC)
+title: NVIDIA Tegra XUSB device mode controller (XUDC)
description:
The Tegra XUDC controller supports both USB 2.0 HighSpeed/FullSpeed and
@@ -22,6 +22,7 @@ properties:
- nvidia,tegra210-xudc # For Tegra210
- nvidia,tegra186-xudc # For Tegra186
- nvidia,tegra194-xudc # For Tegra194
+ - nvidia,tegra234-xudc # For Tegra234
reg:
minItems: 2
@@ -90,6 +91,7 @@ properties:
phys:
minItems: 1
+ maxItems: 2
description:
Must contain an entry for each entry in phy-names.
See ../phy/phy-bindings.txt for details.
@@ -98,13 +100,7 @@ properties:
minItems: 1
items:
- const: usb2-0
- - const: usb2-1
- - const: usb2-2
- - const: usb2-3
- const: usb3-0
- - const: usb3-1
- - const: usb3-2
- - const: usb3-3
avddio-usb-supply:
description: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
@@ -112,6 +108,8 @@ properties:
hvdd-usb-supply:
description: USB controller power supply. Must supply 3.3 V.
+ dma-coherent: true
+
required:
- compatible
- reg
@@ -153,6 +151,7 @@ allOf:
enum:
- nvidia,tegra186-xudc
- nvidia,tegra194-xudc
+ - nvidia,tegra234-xudc
then:
properties:
reg:
@@ -164,6 +163,17 @@ allOf:
clock-names:
maxItems: 4
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-xudc
+ - nvidia,tegra234-xudc
+ then:
+ required:
+ - dma-coherent
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
deleted file mode 100644
index 5bfcc0b4d6b9..000000000000
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-NVIDIA Tegra xHCI controller
-============================
-
-The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by
-the Tegra XUSB pad controller.
-
-Required properties:
---------------------
-- compatible: Must be:
- - Tegra124: "nvidia,tegra124-xusb"
- - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb"
- - Tegra210: "nvidia,tegra210-xusb"
- - Tegra186: "nvidia,tegra186-xusb"
-- reg: Must contain the base and length of the xHCI host registers, XUSB FPCI
- registers and XUSB IPFS registers.
-- reg-names: Must contain the following entries:
- - "hcd"
- - "fpci"
- - "ipfs"
-- interrupts: Must contain the xHCI host interrupt and the mailbox interrupt.
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clock/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - xusb_host
- - xusb_host_src
- - xusb_falcon_src
- - xusb_ss
- - xusb_ss_src
- - xusb_ss_div2
- - xusb_hs_src
- - xusb_fs_src
- - pll_u_480m
- - clk_m
- - pll_e
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - xusb_host
- - xusb_ss
- - xusb_src
- Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
-- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to
- configure the USB pads used by the XHCI controller
-
-For Tegra124 and Tegra132:
-- avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
-- dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05 V.
-- avdd-usb-supply: USB controller power supply. Must supply 3.3 V.
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3 V.
-- hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
-
-For Tegra210:
-- dvddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
-- hvddio-pex-supply: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
-- avdd-usb-supply: USB controller power supply. Must supply 3.3 V.
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V.
-
-For Tegra210 and Tegra186:
-- power-domains: A list of PM domain specifiers that reference each power-domain
- used by the xHCI controller. This list must comprise of a specifier for the
- XUSBA and XUSBC power-domains. See ../power/power_domain.txt and
- ../arm/tegra/nvidia,tegra20-pmc.txt for details.
-- power-domain-names: A list of names that represent each of the specifiers in
- the 'power-domains' property. Must include 'xusb_ss' and 'xusb_host' which
- represent the power-domains XUSBA and XUSBC, respectively. See
- ../power/power_domain.txt for details.
-
-Optional properties:
---------------------
-- phys: Must contain an entry for each entry in phy-names.
- See ../phy/phy-bindings.txt for details.
-- phy-names: Should include an entry for each PHY used by the controller. The
- following PHYs are available:
- - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
- - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
- - Tegra210: usb2-0, usb2-1, usb2-2, usb2-3, hsic-0, usb3-0, usb3-1, usb3-2,
- usb3-3
- - Tegra186: usb2-0, usb2-1, usb2-2, hsic-0, usb3-0, usb3-1, usb3-2
-
-Example:
---------
-
- usb@0,70090000 {
- compatible = "nvidia,tegra124-xusb";
- reg = <0x0 0x70090000 0x0 0x8000>,
- <0x0 0x70098000 0x0 0x1000>,
- <0x0 0x70099000 0x0 0x1000>;
- reg-names = "hcd", "fpci", "ipfs";
-
- interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
-
- clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
- <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_SS>,
- <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
- <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
- <&tegra_car TEGRA124_CLK_PLL_U_480M>,
- <&tegra_car TEGRA124_CLK_CLK_M>,
- <&tegra_car TEGRA124_CLK_PLL_E>;
- clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
- "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
- "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
- "clk_m", "pll_e";
- resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
- reset-names = "xusb_host", "xusb_ss", "xusb_src";
-
- nvidia,xusb-padctl = <&padctl>;
-
- phys = <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-1}>, /* mini-PCIe USB */
- <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-2}>, /* USB A */
- <&{/padctl@0,7009f000/pads/pcie/lanes/pcie-0}>; /* USB A */
- phy-names = "usb2-1", "usb2-2", "usb3-0";
-
- avddio-pex-supply = <&vdd_1v05_run>;
- dvddio-pex-supply = <&vdd_1v05_run>;
- avdd-usb-supply = <&vdd_3v3_lp0>;
- avdd-pll-utmip-supply = <&vddio_1v8>;
- avdd-pll-erefe-supply = <&avdd_1v05_run>;
- avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
- hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
- hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
- };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
new file mode 100644
index 000000000000..d6ca8c93073d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
@@ -0,0 +1,200 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra124-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra124 xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The Tegra xHCI controller supports both USB2 and USB3 interfaces
+ exposed by the Tegra XUSB pad controller.
+
+properties:
+ # required
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra124
+ const: nvidia,tegra124-xusb
+
+ - description: NVIDIA Tegra132
+ items:
+ - const: nvidia,tegra132-xusb
+ - const: nvidia,tegra124-xusb
+
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+ - description: base and length of the XUSB IPFS registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+ - const: ipfs
+
+ interrupts:
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+
+ clocks:
+ items:
+ - description: XUSB host clock
+ - description: XUSB host source clock
+ - description: XUSB Falcon source clock
+ - description: XUSB SuperSpeed clock
+ - description: XUSB SuperSpeed clock divider
+ - description: XUSB SuperSpeed source clock
+ - description: XUSB HighSpeed clock source
+ - description: XUSB FullSpeed clock source
+ - description: USB PLL
+ - description: reference clock
+ - description: I/O PLL
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_host_src
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_div2
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ resets:
+ items:
+ - description: reset for the XUSB host controller
+ - description: reset for the SuperSpeed logic
+ - description: shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+
+ reset-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+ - const: xusb_src
+
+ nvidia,xusb-padctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+
+ # optional
+ phys:
+ minItems: 1
+ maxItems: 7
+
+ phy-names:
+ minItems: 1
+ maxItems: 7
+ items:
+ enum:
+ - usb2-0
+ - usb2-1
+ - usb2-2
+ - hsic-0
+ - hsic-1
+ - usb3-0
+ - usb3-1
+
+ avddio-pex-supply:
+ description: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+
+ dvddio-pex-supply:
+ description: PCIe/USB3 digital logic power supply. Must supply 1.05 V.
+
+ avdd-usb-supply:
+ description: USB controller power supply. Must supply 3.3 V.
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-erefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ avdd-usb-ss-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-usb-ss-supply:
+ description: High-voltage PCIe/USB3 power supply. Must supply 3.3 V.
+
+ hvdd-usb-ss-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 3.3 V.
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - nvidia,xusb-padctl
+ - phys
+ - phy-names
+ - avddio-pex-supply
+ - dvddio-pex-supply
+ - avdd-usb-supply
+ - hvdd-usb-ss-supply
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@70090000 {
+ compatible = "nvidia,tegra124-xusb";
+ reg = <0x70090000 0x8000>,
+ <0x70098000 0x1000>,
+ <0x70099000 0x1000>;
+ reg-names = "hcd", "fpci", "ipfs";
+
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
+ <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
+ <&tegra_car TEGRA124_CLK_PLL_U_480M>,
+ <&tegra_car TEGRA124_CLK_CLK_M>,
+ <&tegra_car TEGRA124_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+
+ nvidia,xusb-padctl = <&padctl>;
+
+ phys = <&phy_usb2_1>, <&phy_usb2_2>, <&phy_pcie_0>;
+ phy-names = "usb2-1", "usb2-2", "usb3-0";
+
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-usb-supply = <&vdd_3v3_lp0>;
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
+ hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
+ hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml
new file mode 100644
index 000000000000..a04c6ce1e0f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra186-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra186 xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The Tegra xHCI controller supports both USB2 and USB3 interfaces
+ exposed by the Tegra XUSB pad controller.
+
+properties:
+ compatible:
+ const: nvidia,tegra186-xusb
+
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+
+ interrupts:
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+
+ clocks:
+ items:
+ - description: XUSB host clock
+ - description: XUSB Falcon source clock
+ - description: XUSB SuperSpeed clock
+ - description: XUSB SuperSpeed source clock
+ - description: XUSB HighSpeed clock source
+ - description: XUSB FullSpeed clock source
+ - description: USB PLL
+ - description: reference clock
+ - description: I/O PLL
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ interconnects:
+ items:
+ - description: read client
+ - description: write client
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
+
+ iommus:
+ maxItems: 1
+
+ nvidia,xusb-padctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+
+ phys:
+ minItems: 1
+ maxItems: 7
+
+ phy-names:
+ minItems: 1
+ maxItems: 7
+ items:
+ enum:
+ - usb2-0
+ - usb2-1
+ - usb2-2
+ - hsic-0
+ - usb3-0
+ - usb3-1
+ - usb3-2
+
+ power-domains:
+ items:
+ - description: XUSBC power domain (for Host and USB 2.0)
+ - description: XUSBA power domain (for SuperSpeed)
+
+ power-domain-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+
+ dvddio-pex-supply:
+ description: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+
+ hvddio-pex-supply:
+ description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB controller power supply. Must supply 3.3 V.
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-uerefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ dvdd-usb-ss-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-usb-ss-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 1.8 V.
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra186-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra186-mc.h>
+ #include <dt-bindings/power/tegra186-powergate.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+
+ usb@3530000 {
+ compatible = "nvidia,tegra186-xusb";
+ reg = <0x03530000 0x8000>,
+ <0x03538000 0x1000>;
+ reg-names = "hcd", "fpci";
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA186_CLK_XUSB_HOST>,
+ <&bpmp TEGRA186_CLK_XUSB_FALCON>,
+ <&bpmp TEGRA186_CLK_XUSB_SS>,
+ <&bpmp TEGRA186_CLK_XUSB_CORE_SS>,
+ <&bpmp TEGRA186_CLK_CLK_M>,
+ <&bpmp TEGRA186_CLK_XUSB_FS>,
+ <&bpmp TEGRA186_CLK_PLLU>,
+ <&bpmp TEGRA186_CLK_CLK_M>,
+ <&bpmp TEGRA186_CLK_PLLE>;
+ clock-names = "xusb_host", "xusb_falcon_src", "xusb_ss",
+ "xusb_ss_src", "xusb_hs_src", "xusb_fs_src",
+ "pll_u_480m", "clk_m", "pll_e";
+ power-domains = <&bpmp TEGRA186_POWER_DOMAIN_XUSBC>,
+ <&bpmp TEGRA186_POWER_DOMAIN_XUSBA>;
+ power-domain-names = "xusb_host", "xusb_ss";
+ interconnects = <&mc TEGRA186_MEMORY_CLIENT_XUSB_HOSTR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_XUSB_HOSTW &emc>;
+ interconnect-names = "dma-mem", "write";
+ iommus = <&smmu TEGRA186_SID_XUSB_HOST>;
+ nvidia,xusb-padctl = <&padctl>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phys = <&phy_usb2_0>, <&phy_usb2_1>, <&phy_usb3_0>;
+ phy-names = "usb2-0", "usb2-1", "usb3-0";
+ };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml
new file mode 100644
index 000000000000..b356793f73a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra194-xusb.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra194-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra194 xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The Tegra xHCI controller supports both USB2 and USB3 interfaces
+ exposed by the Tegra XUSB pad controller.
+
+properties:
+ compatible:
+ const: nvidia,tegra194-xusb
+
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+
+ interrupts:
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+
+ clocks:
+ items:
+ - description: XUSB host clock
+ - description: XUSB Falcon source clock
+ - description: XUSB SuperSpeed clock
+ - description: XUSB SuperSpeed source clock
+ - description: XUSB HighSpeed clock source
+ - description: XUSB FullSpeed clock source
+ - description: USB PLL
+ - description: reference clock
+ - description: I/O PLL
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ interconnects:
+ items:
+ - description: read client
+ - description: write client
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
+
+ iommus:
+ maxItems: 1
+
+ nvidia,xusb-padctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+
+ phys:
+ minItems: 1
+ maxItems: 8
+
+ phy-names:
+ minItems: 1
+ maxItems: 8
+ items:
+ enum:
+ - usb2-0
+ - usb2-1
+ - usb2-2
+ - usb2-3
+ - usb3-0
+ - usb3-1
+ - usb3-2
+ - usb3-3
+
+ power-domains:
+ items:
+ - description: XUSBC power domain (for Host and USB 2.0)
+ - description: XUSBA power domain (for SuperSpeed)
+
+ power-domain-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+
+ dvddio-pex-supply:
+ description: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+
+ hvddio-pex-supply:
+ description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB controller power supply. Must supply 3.3 V.
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-uerefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ dvdd-usb-ss-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-usb-ss-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 1.8 V.
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra194-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra194-mc.h>
+ #include <dt-bindings/power/tegra194-powergate.h>
+ #include <dt-bindings/reset/tegra194-reset.h>
+
+ usb@3610000 {
+ compatible = "nvidia,tegra194-xusb";
+ reg = <0x03610000 0x40000>,
+ <0x03600000 0x10000>;
+ reg-names = "hcd", "fpci";
+
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&bpmp TEGRA194_CLK_XUSB_CORE_HOST>,
+ <&bpmp TEGRA194_CLK_XUSB_FALCON>,
+ <&bpmp TEGRA194_CLK_XUSB_CORE_SS>,
+ <&bpmp TEGRA194_CLK_XUSB_SS>,
+ <&bpmp TEGRA194_CLK_CLK_M>,
+ <&bpmp TEGRA194_CLK_XUSB_FS>,
+ <&bpmp TEGRA194_CLK_UTMIPLL>,
+ <&bpmp TEGRA194_CLK_CLK_M>,
+ <&bpmp TEGRA194_CLK_PLLE>;
+ clock-names = "xusb_host", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_src", "xusb_hs_src",
+ "xusb_fs_src", "pll_u_480m", "clk_m",
+ "pll_e";
+ interconnects = <&mc TEGRA194_MEMORY_CLIENT_XUSB_HOSTR &emc>,
+ <&mc TEGRA194_MEMORY_CLIENT_XUSB_HOSTW &emc>;
+ interconnect-names = "dma-mem", "write";
+ iommus = <&smmu TEGRA194_SID_XUSB_HOST>;
+
+ power-domains = <&bpmp TEGRA194_POWER_DOMAIN_XUSBC>,
+ <&bpmp TEGRA194_POWER_DOMAIN_XUSBA>;
+ power-domain-names = "xusb_host", "xusb_ss";
+
+ nvidia,xusb-padctl = <&xusb_padctl>;
+
+ phys = <&phy_usb2_0>, <&phy_usb2_1>, <&phy_usb2_3>, <&phy_usb3_0>,
+ <&phy_usb3_2>, <&phy_usb3_3>;
+ phy-names = "usb2-0", "usb2-1", "usb2-3", "usb3-0", "usb3-2", "usb3-3";
+ };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
deleted file mode 100644
index f60785f73d3d..000000000000
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Tegra SOC USB controllers
-
-The device node for a USB controller that is part of a Tegra
-SOC is as described in the document "Open Firmware Recommended
-Practice : Universal Serial Bus" with the following modifications
-and additions :
-
-Required properties :
- - compatible : For Tegra20, must contain "nvidia,tegra20-ehci".
- For Tegra30, must contain "nvidia,tegra30-ehci". Otherwise, must contain
- "nvidia,<chip>-ehci" plus at least one of the above, where <chip> is
- tegra114, tegra124, tegra132, or tegra210.
- - nvidia,phy : phandle of the PHY that the controller is connected to.
- - clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
- - resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names : Must include the following entries:
- - usb
-
-Optional properties:
- - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20
- USB ports, which need reset twice due to hardware issues.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml
new file mode 100644
index 000000000000..c0e313c70bba
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra210-xusb.yaml
@@ -0,0 +1,195 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra210-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra210 xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The Tegra xHCI controller supports both USB2 and USB3 interfaces
+ exposed by the Tegra XUSB pad controller.
+
+properties:
+ compatible:
+ const: nvidia,tegra210-xusb
+
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+ - description: base and length of the XUSB IPFS registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+ - const: ipfs
+
+ interrupts:
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+
+ clocks:
+ items:
+ - description: XUSB host clock
+ - description: XUSB host source clock
+ - description: XUSB Falcon source clock
+ - description: XUSB SuperSpeed clock
+ - description: XUSB SuperSpeed clock divider
+ - description: XUSB SuperSpeed source clock
+ - description: XUSB HighSpeed clock source
+ - description: XUSB FullSpeed clock source
+ - description: USB PLL
+ - description: reference clock
+ - description: I/O PLL
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_host_src
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_div2
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ resets:
+ items:
+ - description: reset for the XUSB host controller
+ - description: reset for the SuperSpeed logic
+ - description: shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+
+ reset-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+ - const: xusb_src
+
+ nvidia,xusb-padctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+
+ phys:
+ minItems: 1
+ maxItems: 9
+
+ phy-names:
+ minItems: 1
+ maxItems: 9
+ items:
+ enum:
+ - usb2-0
+ - usb2-1
+ - usb2-2
+ - usb2-3
+ - hsic-0
+ - usb3-0
+ - usb3-1
+ - usb3-2
+ - usb3-3
+
+ power-domains:
+ items:
+ - description: XUSBC power domain (for Host and USB 2.0)
+ - description: XUSBA power domain (for SuperSpeed)
+
+ power-domain-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+
+ dvddio-pex-supply:
+ description: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+
+ hvddio-pex-supply:
+ description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB controller power supply. Must supply 3.3 V.
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-uerefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ dvdd-usb-ss-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-usb-ss-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 1.8 V.
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@70090000 {
+ compatible = "nvidia,tegra210-xusb";
+ reg = <0x70090000 0x8000>,
+ <0x70098000 0x1000>,
+ <0x70099000 0x1000>;
+ reg-names = "hcd", "fpci", "ipfs";
+
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&tegra_car TEGRA210_CLK_XUSB_HOST>,
+ <&tegra_car TEGRA210_CLK_XUSB_HOST_SRC>,
+ <&tegra_car TEGRA210_CLK_XUSB_FALCON_SRC>,
+ <&tegra_car TEGRA210_CLK_XUSB_SS>,
+ <&tegra_car TEGRA210_CLK_XUSB_SS_DIV2>,
+ <&tegra_car TEGRA210_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA210_CLK_XUSB_HS_SRC>,
+ <&tegra_car TEGRA210_CLK_XUSB_FS_SRC>,
+ <&tegra_car TEGRA210_CLK_PLL_U_480M>,
+ <&tegra_car TEGRA210_CLK_CLK_M>,
+ <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src",
+ "xusb_falcon_src", "xusb_ss",
+ "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src",
+ "pll_u_480m", "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>,
+ <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+ power-domains = <&pd_xusbhost>, <&pd_xusbss>;
+ power-domain-names = "xusb_host", "xusb_ss";
+
+ nvidia,xusb-padctl = <&padctl>;
+
+ phys = <&phy_usb2_0>, <&phy_usb2_1>, <&phy_usb2_2>, <&phy_usb2_3>,
+ <&phy_pcie_6>, <&phy_pcie_5>;
+ phy-names = "usb2-0", "usb2-1", "usb2-2", "usb2-3", "usb3-0",
+ "usb3-1";
+ dvddio-pex-supply = <&vdd_pex_1v05>;
+ hvddio-pex-supply = <&vdd_1v8>;
+ avdd-usb-supply = <&vdd_3v3_sys>;
+ avdd-pll-utmip-supply = <&vdd_1v8>;
+ avdd-pll-uerefe-supply = <&vdd_pex_1v05>;
+ dvdd-usb-ss-pll-supply = <&vdd_pex_1v05>;
+ hvdd-usb-ss-pll-e-supply = <&vdd_1v8>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@1 {
+ compatible = "usb955,9ff";
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
new file mode 100644
index 000000000000..ec0993497fbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra234-xusb.yaml
@@ -0,0 +1,186 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra234-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra234 xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by
+ the Tegra XUSB pad controller. The xHCI controller controls up to eight
+ ports; there are four USB 2.0 ports and four USB 3.2 Gen1 x1 ports.
+
+properties:
+ compatible:
+ const: nvidia,tegra234-xusb
+
+ reg:
+ items:
+ - description: xHCI host registers
+ - description: XUSB FPCI registers
+ - description: XUSB bar2 registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+ - const: bar2
+
+ interrupts:
+ minItems: 2
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+ - description: USB wake event 0
+ - description: USB wake event 1
+ - description: USB wake event 2
+ - description: USB wake event 3
+ - description: USB wake event 4
+ - description: USB wake event 5
+ - description: USB wake event 6
+ description: |
+ The first two interrupts are required for the USB host controller. The
+ remaining USB wake event interrupts are optional. Each USB wake event is
+ independent; it is not necessary to use all of these events on a
+ platform. The USB host controller can function even if no wake-up events
+ are defined. The USB wake event interrupts are handled by the Tegra PMC;
+ hence, the interrupt controller for these is the PMC and the interrupt
+ IDs correspond to the PMC wake event IDs. A complete list of wake event
+ IDs is provided below, and this information is also present in the Tegra
+ TRM document.
+
+ PMC wake-up 76 for USB3 port 0 wakeup
+ PMC wake-up 77 for USB3 port 1 wakeup
+ PMC wake-up 78 for USB3 port 2 and port 3 wakeup
+ PMC wake-up 79 for USB2 port 0 wakeup
+ PMC wake-up 80 for USB2 port 1 wakeup
+ PMC wake-up 81 for USB2 port 2 wakeup
+ PMC wake-up 82 for USB2 port 3 wakeup
+
+ clocks:
+ items:
+ - description: XUSB host clock
+ - description: XUSB Falcon source clock
+ - description: XUSB SuperSpeed clock
+ - description: XUSB SuperSpeed source clock
+ - description: XUSB HighSpeed clock source
+ - description: XUSB FullSpeed clock source
+ - description: USB PLL
+ - description: reference clock
+ - description: I/O PLL
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ interconnects:
+ items:
+ - description: read client
+ - description: write client
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
+
+ iommus:
+ maxItems: 1
+
+ nvidia,xusb-padctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+
+ phys:
+ minItems: 1
+ maxItems: 8
+
+ phy-names:
+ minItems: 1
+ maxItems: 8
+ items:
+ enum:
+ - usb2-0
+ - usb2-1
+ - usb2-2
+ - usb2-3
+ - usb3-0
+ - usb3-1
+ - usb3-2
+ - usb3-3
+
+ power-domains:
+ items:
+ - description: XUSBC power domain (for Host and USB 2.0)
+ - description: XUSBA power domain (for SuperSpeed)
+
+ power-domain-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+
+ dma-coherent: true
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra234-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/power/tegra234-powergate.h>
+
+ usb@3610000 {
+ compatible = "nvidia,tegra234-xusb";
+ reg = <0x03610000 0x40000>,
+ <0x03600000 0x10000>,
+ <0x03650000 0x10000>;
+ reg-names = "hcd", "fpci", "bar2";
+
+ interrupts-extended = <&gic GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
+ <&pmc 76 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&bpmp TEGRA234_CLK_XUSB_CORE_HOST>,
+ <&bpmp TEGRA234_CLK_XUSB_FALCON>,
+ <&bpmp TEGRA234_CLK_XUSB_CORE_SS>,
+ <&bpmp TEGRA234_CLK_XUSB_SS>,
+ <&bpmp TEGRA234_CLK_CLK_M>,
+ <&bpmp TEGRA234_CLK_XUSB_FS>,
+ <&bpmp TEGRA234_CLK_UTMIP_PLL>,
+ <&bpmp TEGRA234_CLK_CLK_M>,
+ <&bpmp TEGRA234_CLK_PLLE>;
+ clock-names = "xusb_host", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_src", "xusb_hs_src",
+ "xusb_fs_src", "pll_u_480m", "clk_m",
+ "pll_e";
+ interconnects = <&mc TEGRA234_MEMORY_CLIENT_XUSB_HOSTR &emc>,
+ <&mc TEGRA234_MEMORY_CLIENT_XUSB_HOSTW &emc>;
+ interconnect-names = "dma-mem", "write";
+ iommus = <&smmu_niso1 TEGRA234_SID_XUSB_HOST>;
+
+ power-domains = <&bpmp TEGRA234_POWER_DOMAIN_XUSBC>,
+ <&bpmp TEGRA234_POWER_DOMAIN_XUSBA>;
+ power-domain-names = "xusb_host", "xusb_ss";
+
+ nvidia,xusb-padctl = <&xusb_padctl>;
+
+ phys = <&pad_lanes_usb2_0>;
+ phy-names = "usb2-0";
+ };
diff --git a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml
index f238848ad094..e2743a4b9520 100644
--- a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml
+++ b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/nxp,isp1760.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: NXP ISP1760 family controller bindings
+title: NXP ISP1760 family controller
maintainers:
- Sebastian Siewior <bigeasy@linutronix.de>
diff --git a/Documentation/devicetree/bindings/usb/nxp,lpc3220-udc.yaml b/Documentation/devicetree/bindings/usb/nxp,lpc3220-udc.yaml
new file mode 100644
index 000000000000..be0457a06861
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nxp,lpc3220-udc.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nxp,lpc3220-udc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC32xx SoC USB Device Controller (UDC)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+properties:
+ compatible:
+ const: nxp,lpc3220-udc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: USB Device Low Priority Interrupt
+ - description: USB Device High Priority Interrupt
+ - description: USB Device DMA Interrupt
+ - description: External USB Transceiver Interrupt (OTG ATX)
+
+ clocks:
+ maxItems: 1
+
+ transceiver:
+ description:
+ phandle of the associated ISP1301 device - this is necessary for
+ the UDC controller for connecting to the USB physical layer
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - transceiver
+
+additionalProperties: false
+
+examples:
+ - |
+ usbd@31020000 {
+ compatible = "nxp,lpc3220-udc";
+ reg = <0x31020000 0x300>;
+ interrupt-parent = <&mic>;
+ interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
+ transceiver = <&isp1301>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
new file mode 100644
index 000000000000..4d2fcaa71870
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nxp,ptn36502.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PTN36502 Type-C USB 3.1 Gen 1 and DisplayPort v1.2 combo redriver
+
+maintainers:
+ - Luca Weiss <luca.weiss@fairphone.com>
+
+properties:
+ compatible:
+ enum:
+ - nxp,ptn36502
+
+ reg:
+ maxItems: 1
+
+ vdd18-supply:
+ description: Power supply for VDD18 pin
+
+ orientation-switch: true
+ retimer-switch: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) Output endpoint to the Type-C connector
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) Input endpoint from the Super-Speed PHY
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@1a {
+ compatible = "nxp,ptn36502";
+ reg = <0x1a>;
+
+ vdd18-supply = <&usb_redrive_1v8>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usb_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ phy_con_ss: endpoint {
+ remote-endpoint = <&usb_phy_ss>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+ usb_con_sbu: endpoint {
+ remote-endpoint = <&typec_dp_aux>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml b/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml
new file mode 100644
index 000000000000..65a8632b4d9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PTN5110 Type-C Port Controller
+
+maintainers:
+ - Li Jun <jun.li@nxp.com>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,ptn5110
+ - const: tcpci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - connector
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/usb/pd.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcpci@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) PDO_VAR(5000, 12000, 2000)>;
+ op-sink-microwatt = <10000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ohci-nxp.txt b/Documentation/devicetree/bindings/usb/ohci-nxp.txt
deleted file mode 100644
index 71e28c1017ed..000000000000
--- a/Documentation/devicetree/bindings/usb/ohci-nxp.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* OHCI controller, NXP ohci-nxp variant
-
-Required properties:
-- compatible: must be "nxp,ohci-nxp"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: The OHCI interrupt
-- transceiver: phandle of the associated ISP1301 device - this is necessary for
- the UDC controller for connecting to the USB physical layer
-
-Example (LPC32xx):
-
- isp1301: usb-transceiver@2c {
- compatible = "nxp,isp1301";
- reg = <0x2c>;
- };
-
- ohci@31020000 {
- compatible = "nxp,ohci-nxp";
- reg = <0x31020000 0x300>;
- interrupt-parent = <&mic>;
- interrupts = <0x3b 0>;
- transceiver = <&isp1301>;
- };
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
deleted file mode 100644
index ce8c47cff6d0..000000000000
--- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-OMAP HS USB OHCI controller (OMAP3 and later)
-
-Required properties:
-
-- compatible: should be "ti,ohci-omap3"
-- reg: should contain one register range i.e. start and length
-- interrupts: description of the interrupt line
-
-Example for OMAP4:
-
-usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3";
- reg = <0x4a064800 0x400>;
- interrupts = <0 76 0x4>;
-};
diff --git a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
new file mode 100644
index 000000000000..25fab5fdc2cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/onnn,nb7vpq904m.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ON Semiconductor Type-C DisplayPort ALT Mode Linear Redriver
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - onnn,nb7vpq904m
+
+ reg:
+ maxItems: 1
+
+ vcc-supply:
+ description: power supply (1.8V)
+
+ enable-gpios: true
+ orientation-switch: true
+ retimer-switch: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) Output endpoint to the Type-C connector
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: Super Speed (SS) Input endpoint from the Super-Speed PHY
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array of physical data lane indexes. Position determines how
+ lanes are connected to the redriver, It is assumed the same order
+ is kept on the other side of the redriver.
+ Lane number represents the following
+ - 0 is RX2 lane
+ - 1 is TX2 lane
+ - 2 is TX1 lane
+ - 3 is RX1 lane
+ The position determines the physical port of the redriver, in the
+ order A, B, C & D.
+ oneOf:
+ - items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+ description: |
+ This is the lanes default layout
+ - Port A to RX2 lane
+ - Port B to TX2 lane
+ - Port C to TX1 lane
+ - Port D to RX1 lane
+ - items:
+ - const: 3
+ - const: 2
+ - const: 1
+ - const: 0
+ description: |
+ This is the USBRX2/USBTX2 and USBRX1/USBTX1 swapped lanes layout
+ - Port A to RX1 lane
+ - Port B to TX1 lane
+ - Port C to TX2 lane
+ - Port D to RX2 lane
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@32 {
+ compatible = "onnn,nb7vpq904m";
+ reg = <0x32>;
+
+ vcc-supply = <&vreg_l15b_1p8>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usb_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ phy_con_ss: endpoint {
+ remote-endpoint = <&usb_phy_ss>;
+ data-lanes = <3 2 1 0>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+ usb_con_sbu: endpoint {
+ remote-endpoint = <&typec_dp_aux>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/parade,ps5511.yaml b/Documentation/devicetree/bindings/usb/parade,ps5511.yaml
new file mode 100644
index 000000000000..10d002f09db8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/parade,ps5511.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/parade,ps5511.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parade PS5511 4+1 Port USB 3.2 Gen 1 Hub Controller
+
+maintainers:
+ - Pin-yen Lin <treapking@chromium.org>
+
+properties:
+ compatible:
+ enum:
+ - usb1da0,5511
+ - usb1da0,55a1
+
+ reset-gpios:
+ items:
+ - description: GPIO specifier for RESETB pin.
+
+ vddd11-supply:
+ description:
+ 1V1 power supply to the hub
+
+ vdd33-supply:
+ description:
+ 3V3 power supply to the hub
+
+ peer-hub: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ '^port@':
+ $ref: /schemas/graph.yaml#/properties/port
+
+ properties:
+ reg:
+ minimum: 1
+ maximum: 5
+
+additionalProperties:
+ properties:
+ reg:
+ minimum: 1
+ maximum: 5
+
+required:
+ - peer-hub
+
+allOf:
+ - $ref: usb-hub.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - usb1da0,55a1
+ then:
+ properties:
+ ports:
+ properties:
+ port@5: false
+
+ patternProperties:
+ '^.*@5$': false
+
+examples:
+ - |
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb1da0,55a1";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* USB 2.0 device on port 5 */
+ device@5 {
+ reg = <5>;
+ compatible = "usb123,4567";
+ };
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb1da0,5511";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* Type-A connector on port 3 */
+ port@3 {
+ reg = <3>;
+ endpoint {
+ remote-endpoint = <&usb_a0_ss>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/parade,ps8830.yaml b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
new file mode 100644
index 000000000000..eaeab1c01a59
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/parade,ps8830.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parade PS883x USB and DisplayPort Retimer
+
+maintainers:
+ - Abel Vesa <abel.vesa@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: parade,ps8833
+ - const: parade,ps8830
+ - const: parade,ps8830
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO Clock
+
+ reset-gpios:
+ maxItems: 1
+
+ vdd-supply:
+ description: power supply (1.07V)
+
+ vdd33-supply:
+ description: power supply (3.3V)
+
+ vdd33-cap-supply:
+ description: power supply (3.3V)
+
+ vddar-supply:
+ description: power supply (1.07V)
+
+ vddat-supply:
+ description: power supply (1.07V)
+
+ vddio-supply:
+ description: power supply (1.2V or 1.8V)
+
+ orientation-switch: true
+ retimer-switch: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) Output endpoint to the Type-C connector
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: Super Speed (SS) Input endpoint from the Super-Speed PHY
+ unevaluatedProperties: false
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - reset-gpios
+ - vdd-supply
+ - vdd33-supply
+ - vdd33-cap-supply
+ - vddat-supply
+ - vddio-supply
+ - orientation-switch
+ - retimer-switch
+
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@8 {
+ compatible = "parade,ps8830";
+ reg = <0x8>;
+
+ clocks = <&clk_rtmr_xo>;
+
+ vdd-supply = <&vreg_rtmr_1p15>;
+ vdd33-supply = <&vreg_rtmr_3p3>;
+ vdd33-cap-supply = <&vreg_rtmr_3p3>;
+ vddar-supply = <&vreg_rtmr_1p15>;
+ vddat-supply = <&vreg_rtmr_1p15>;
+ vddio-supply = <&vreg_rtmr_1p8>;
+
+ reset-gpios = <&tlmm 10 GPIO_ACTIVE_LOW>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <&usb_phy_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ remote-endpoint = <&typec_dp_aux>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/pxa-usb.txt b/Documentation/devicetree/bindings/usb/pxa-usb.txt
index 9c331799b87c..53fdae4fa6f6 100644
--- a/Documentation/devicetree/bindings/usb/pxa-usb.txt
+++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt
@@ -22,7 +22,7 @@ Optional properties:
Example:
usb0: ohci@4c000000 {
- compatible = "marvell,pxa-ohci", "usb-ohci";
+ compatible = "marvell,pxa-ohci";
reg = <0x4c000000 0x100000>;
interrupts = <18>;
marvell,enable-port1;
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index cd2f7cb6745a..a792434c59db 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -4,31 +4,57 @@
$id: http://devicetree.org/schemas/usb/qcom,dwc3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm SuperSpeed DWC3 USB SoC controller
+title: Legacy Qualcomm SuperSpeed DWC3 USB SoC controller
maintainers:
- Wesley Cheng <quic_wcheng@quicinc.com>
+# Use the combined qcom,snps-dwc3 instead
+deprecated: true
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: qcom,dwc3
+ required:
+ - compatible
+
properties:
compatible:
items:
- enum:
- qcom,ipq4019-dwc3
+ - qcom,ipq5018-dwc3
+ - qcom,ipq5332-dwc3
+ - qcom,ipq5424-dwc3
- qcom,ipq6018-dwc3
- qcom,ipq8064-dwc3
- qcom,ipq8074-dwc3
+ - qcom,ipq9574-dwc3
- qcom,msm8953-dwc3
- qcom,msm8994-dwc3
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
+ - qcom,qcm2290-dwc3
- qcom,qcs404-dwc3
+ - qcom,qcs615-dwc3
+ - qcom,qcs8300-dwc3
+ - qcom,qdu1000-dwc3
+ - qcom,sa8775p-dwc3
+ - qcom,sar2130p-dwc3
- qcom,sc7180-dwc3
- qcom,sc7280-dwc3
+ - qcom,sc8180x-dwc3
+ - qcom,sc8180x-dwc3-mp
- qcom,sc8280xp-dwc3
+ - qcom,sc8280xp-dwc3-mp
- qcom,sdm660-dwc3
+ - qcom,sdm670-dwc3
- qcom,sdm845-dwc3
- qcom,sdx55-dwc3
- qcom,sdx65-dwc3
+ - qcom,sdx75-dwc3
- qcom,sm4250-dwc3
- qcom,sm6115-dwc3
- qcom,sm6125-dwc3
@@ -38,6 +64,11 @@ properties:
- qcom,sm8250-dwc3
- qcom,sm8350-dwc3
- qcom,sm8450-dwc3
+ - qcom,sm8550-dwc3
+ - qcom,sm8650-dwc3
+ - qcom,sm8750-dwc3
+ - qcom,x1e80100-dwc3
+ - qcom,x1e80100-dwc3-mp
- const: qcom,dwc3
reg:
@@ -56,6 +87,9 @@ properties:
description: specifies a phandle to PM domain provider node
maxItems: 1
+ required-opps:
+ maxItems: 1
+
clocks:
description: |
Several clocks are used, depending on the variant. Typical ones are::
@@ -74,15 +108,6 @@ properties:
minItems: 1
maxItems: 9
- assigned-clocks:
- items:
- - description: Phandle and clock specifier of MOCK_UTMI_CLK.
- - description: Phandle and clock specifoer of MASTER_CLK.
-
- assigned-clock-rates:
- items:
- - description: Must be 19.2MHz (19200000).
- - description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode.
resets:
maxItems: 1
@@ -95,12 +120,29 @@ properties:
- const: apps-usb
interrupts:
- minItems: 1
- maxItems: 4
+ description: |
+ Different types of interrupts are used based on HS PHY used on target:
+ - pwr_event: Used for wakeup based on other power events.
+ - hs_phy_irq: Apart from DP/DM/QUSB2 PHY interrupts, there is
+ hs_phy_irq which is not triggered by default and its
+ functionality is mutually exclusive to that of
+ {dp/dm}_hs_phy_irq and qusb2_phy_irq.
+ - qusb2_phy: SoCs with QUSB2 PHY do not have separate DP/DM IRQs and
+ expose only a single IRQ whose behavior can be modified
+ by the QUSB2PHY_INTR_CTRL register. The required DPSE/
+ DMSE configuration is done in QUSB2PHY_INTR_CTRL register
+ of PHY address space.
+ - {dp/dm}_hs_phy_irq: These IRQ's directly reflect changes on the DP/
+ DM pads of the SoC. These are used for wakeup
+ only on SoCs with non-QUSB2 targets with
+ exception of SDM670/SDM845/SM6350.
+ - ss_phy_irq: Used for remote wakeup in Super Speed mode of operation.
+ minItems: 2
+ maxItems: 18
interrupt-names:
- minItems: 1
- maxItems: 4
+ minItems: 2
+ maxItems: 18
qcom,select-utmi-as-pipe-clk:
description:
@@ -116,6 +158,7 @@ properties:
patternProperties:
"^usb@[0-9a-f]+$":
$ref: snps,dwc3.yaml#
+ unevaluatedProperties: false
properties:
wakeup-source: false
@@ -126,7 +169,6 @@ required:
- "#address-cells"
- "#size-cells"
- ranges
- - power-domains
- clocks
- clock-names
- interrupts
@@ -139,6 +181,7 @@ allOf:
contains:
enum:
- qcom,ipq4019-dwc3
+ - qcom,ipq5332-dwc3
then:
properties:
clocks:
@@ -170,13 +213,19 @@ allOf:
compatible:
contains:
enum:
+ - qcom,ipq9574-dwc3
- qcom,msm8953-dwc3
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
+ - qcom,qcs8300-dwc3
+ - qcom,sa8775p-dwc3
- qcom,sc7180-dwc3
- qcom,sc7280-dwc3
+ - qcom,sdm670-dwc3
- qcom,sdm845-dwc3
- qcom,sdx55-dwc3
+ - qcom,sdx65-dwc3
+ - qcom,sdx75-dwc3
- qcom,sm6350-dwc3
then:
properties:
@@ -219,6 +268,7 @@ allOf:
contains:
enum:
- qcom,ipq8074-dwc3
+ - qcom,qdu1000-dwc3
then:
properties:
clocks:
@@ -235,6 +285,7 @@ allOf:
compatible:
contains:
enum:
+ - qcom,ipq5018-dwc3
- qcom,msm8994-dwc3
- qcom,qcs404-dwc3
then:
@@ -254,6 +305,9 @@ allOf:
contains:
enum:
- qcom,sc8280xp-dwc3
+ - qcom,sc8280xp-dwc3-mp
+ - qcom,x1e80100-dwc3
+ - qcom,x1e80100-dwc3-mp
then:
properties:
clocks:
@@ -279,25 +333,40 @@ allOf:
then:
properties:
clocks:
- minItems: 6
+ minItems: 4
+ maxItems: 5
clock-names:
- items:
- - const: cfg_noc
- - const: core
- - const: iface
- - const: sleep
- - const: mock_utmi
- - const: bus
+ oneOf:
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: sleep
+ - const: mock_utmi
- if:
properties:
compatible:
contains:
enum:
+ - qcom,qcm2290-dwc3
+ - qcom,qcs615-dwc3
+ - qcom,sar2130p-dwc3
+ - qcom,sc8180x-dwc3
+ - qcom,sc8180x-dwc3-mp
+ - qcom,sm6115-dwc3
- qcom,sm6125-dwc3
- qcom,sm8150-dwc3
- qcom,sm8250-dwc3
- qcom,sm8450-dwc3
+ - qcom,sm8550-dwc3
+ - qcom,sm8650-dwc3
+ - qcom,sm8750-dwc3
then:
properties:
clocks:
@@ -337,55 +406,43 @@ allOf:
compatible:
contains:
enum:
- - qcom,ipq4019-dwc3
+ - qcom,ipq5018-dwc3
- qcom,ipq6018-dwc3
- - qcom,ipq8064-dwc3
- qcom,ipq8074-dwc3
- - qcom,msm8994-dwc3
- - qcom,qcs404-dwc3
- - qcom,sc7180-dwc3
- - qcom,sdm845-dwc3
- - qcom,sdx55-dwc3
- - qcom,sdx65-dwc3
- - qcom,sm4250-dwc3
- - qcom,sm6115-dwc3
- - qcom,sm6125-dwc3
- - qcom,sm6350-dwc3
- - qcom,sm8150-dwc3
- - qcom,sm8250-dwc3
- - qcom,sm8350-dwc3
- - qcom,sm8450-dwc3
+ - qcom,msm8953-dwc3
+ - qcom,msm8998-dwc3
then:
properties:
interrupts:
- items:
- - description: The interrupt that is asserted
- when a wakeup event is received on USB2 bus.
- - description: The interrupt that is asserted
- when a wakeup event is received on USB3 bus.
- - description: Wakeup event on DM line.
- - description: Wakeup event on DP line.
+ minItems: 2
+ maxItems: 3
interrupt-names:
+ minItems: 2
items:
- - const: hs_phy_irq
+ - const: pwr_event
+ - const: qusb2_phy
- const: ss_phy_irq
- - const: dm_hs_phy_irq
- - const: dp_hs_phy_irq
- if:
properties:
compatible:
contains:
enum:
- - qcom,msm8953-dwc3
- qcom,msm8996-dwc3
- - qcom,msm8998-dwc3
+ - qcom,qcs404-dwc3
+ - qcom,sdm660-dwc3
+ - qcom,sm6115-dwc3
+ - qcom,sm6125-dwc3
then:
properties:
interrupts:
- maxItems: 2
+ minItems: 3
+ maxItems: 4
interrupt-names:
+ minItems: 3
items:
+ - const: pwr_event
+ - const: qusb2_phy
- const: hs_phy_irq
- const: ss_phy_irq
@@ -394,24 +451,23 @@ allOf:
compatible:
contains:
enum:
- - qcom,sdm660-dwc3
+ - qcom,ipq5332-dwc3
then:
properties:
interrupts:
- minItems: 1
- maxItems: 2
+ maxItems: 3
interrupt-names:
- minItems: 1
items:
- - const: hs_phy_irq
- - const: ss_phy_irq
+ - const: pwr_event
+ - const: dp_hs_phy_irq
+ - const: dm_hs_phy_irq
- if:
properties:
compatible:
contains:
enum:
- - qcom,sc7280-dwc3
+ - qcom,x1e80100-dwc3
then:
properties:
interrupts:
@@ -420,7 +476,7 @@ allOf:
interrupt-names:
minItems: 3
items:
- - const: hs_phy_irq
+ - const: pwr_event
- const: dp_hs_phy_irq
- const: dm_hs_phy_irq
- const: ss_phy_irq
@@ -430,18 +486,102 @@ allOf:
compatible:
contains:
enum:
+ - qcom,ipq4019-dwc3
+ - qcom,ipq8064-dwc3
+ - qcom,msm8994-dwc3
+ - qcom,qcs615-dwc3
+ - qcom,qcs8300-dwc3
+ - qcom,qdu1000-dwc3
+ - qcom,sa8775p-dwc3
+ - qcom,sc7180-dwc3
+ - qcom,sc7280-dwc3
+ - qcom,sc8180x-dwc3
- qcom,sc8280xp-dwc3
+ - qcom,sdm670-dwc3
+ - qcom,sdm845-dwc3
+ - qcom,sdx55-dwc3
+ - qcom,sdx65-dwc3
+ - qcom,sdx75-dwc3
+ - qcom,sm4250-dwc3
+ - qcom,sm6350-dwc3
+ - qcom,sm8150-dwc3
+ - qcom,sm8250-dwc3
+ - qcom,sm8350-dwc3
+ - qcom,sm8450-dwc3
+ - qcom,sm8550-dwc3
+ - qcom,sm8650-dwc3
+ - qcom,sm8750-dwc3
then:
properties:
interrupts:
- maxItems: 4
+ minItems: 4
+ maxItems: 5
interrupt-names:
+ minItems: 4
items:
- const: pwr_event
+ - const: hs_phy_irq
- const: dp_hs_phy_irq
- const: dm_hs_phy_irq
- const: ss_phy_irq
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8180x-dwc3-mp
+ - qcom,x1e80100-dwc3-mp
+ then:
+ properties:
+ interrupts:
+ minItems: 10
+ maxItems: 10
+ interrupt-names:
+ items:
+ - const: pwr_event_1
+ - const: pwr_event_2
+ - const: hs_phy_1
+ - const: hs_phy_2
+ - const: dp_hs_phy_1
+ - const: dm_hs_phy_1
+ - const: dp_hs_phy_2
+ - const: dm_hs_phy_2
+ - const: ss_phy_1
+ - const: ss_phy_2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-dwc3-mp
+ then:
+ properties:
+ interrupts:
+ minItems: 18
+ maxItems: 18
+ interrupt-names:
+ items:
+ - const: pwr_event_1
+ - const: pwr_event_2
+ - const: pwr_event_3
+ - const: pwr_event_4
+ - const: hs_phy_1
+ - const: hs_phy_2
+ - const: hs_phy_3
+ - const: hs_phy_4
+ - const: dp_hs_phy_1
+ - const: dm_hs_phy_1
+ - const: dp_hs_phy_2
+ - const: dm_hs_phy_2
+ - const: dp_hs_phy_3
+ - const: dm_hs_phy_3
+ - const: dp_hs_phy_4
+ - const: dm_hs_phy_4
+ - const: ss_phy_1
+ - const: ss_phy_2
+
additionalProperties: false
examples:
@@ -475,12 +615,13 @@ examples:
<&gcc GCC_USB30_PRIM_MASTER_CLK>;
assigned-clock-rates = <19200000>, <150000000>;
- interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 488 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 489 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "hs_phy_irq", "ss_phy_irq",
- "dm_hs_phy_irq", "dp_hs_phy_irq";
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 489 IRQ_TYPE_EDGE_BOTH>,
+ <GIC_SPI 488 IRQ_TYPE_EDGE_BOTH>,
+ <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pwr_event", "hs_phy_irq",
+ "dp_hs_phy_irq", "dm_hs_phy_irq", "ss_phy_irq";
power-domains = <&gcc USB30_PRIM_GDSC>;
diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index 000000000000..6d3fa2bc9cee
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,248 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PMIC based USB Type-C block
+
+maintainers:
+ - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+description:
+ Qualcomm PMIC Type-C block
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - qcom,pmi632-typec
+ - qcom,pm8150b-typec
+ - items:
+ - enum:
+ - qcom,pm6150-typec
+ - qcom,pm7250b-typec
+ - const: qcom,pm8150b-typec
+ - items:
+ - enum:
+ - qcom,pm4125-typec
+ - const: qcom,pmi632-typec
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
+
+ reg:
+ description: Type-C port and pdphy SPMI register base offsets
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ minItems: 8
+ items:
+ - description: Type-C CC attach notification, VBUS error, tCCDebounce done
+ - description: Type-C VCONN powered
+ - description: Type-C CC state change
+ - description: Type-C VCONN over-current
+ - description: Type-C VBUS state change
+ - description: Type-C Attach/detach notification
+ - description: Type-C Legacy cable detect
+ - description: Type-C Try.Src Try.Snk state change
+ - description: Power Domain Signal TX - HardReset or CableReset signal TX
+ - description: Power Domain Signal RX - HardReset or CableReset signal RX
+ - description: Power Domain TX complete
+ - description: Power Domain RX complete
+ - description: Power Domain TX fail
+ - description: Power Domain TX message discard
+ - description: Power Domain RX message discard
+ - description: Power Domain Fast Role Swap event
+
+ interrupt-names:
+ minItems: 8
+ items:
+ - const: or-rid-detect-change
+ - const: vpd-detect
+ - const: cc-state-change
+ - const: vconn-oc
+ - const: vbus-change
+ - const: attach-detach
+ - const: legacy-cable-detect
+ - const: try-snk-src-detect
+ - const: sig-tx
+ - const: sig-rx
+ - const: msg-tx
+ - const: msg-rx
+ - const: msg-tx-failed
+ - const: msg-tx-discarded
+ - const: msg-rx-discarded
+ - const: fr-swap
+
+ vdd-vbus-supply:
+ description: VBUS power supply.
+
+ vdd-pdphy-supply:
+ description: VDD regulator supply to the PDPHY.
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Contains a port which produces data-role switching messages.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - vdd-vbus-supply
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,pmi632-typec
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ interrupts:
+ maxItems: 8
+ interrupt-names:
+ maxItems: 8
+ vdd-pdphy-supply: false
+ else:
+ properties:
+ reg:
+ maxItems: 2
+ interrupts:
+ minItems: 16
+ interrupt-names:
+ maxItems: 16
+ required:
+ - vdd-pdphy-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/usb/pd.h>
+
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8150b_typec: typec@1500 {
+ compatible = "qcom,pm8150b-typec";
+ reg = <0x1500>,
+ <0x1700>;
+
+ interrupts = <0x2 0x15 0x00 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x01 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x15 0x02 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x03 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x15 0x04 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x05 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x15 0x06 IRQ_TYPE_EDGE_BOTH>,
+ <0x2 0x15 0x07 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x00 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x01 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x02 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x03 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x04 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x05 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x06 IRQ_TYPE_EDGE_RISING>,
+ <0x2 0x17 0x07 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "or-rid-detect-change",
+ "vpd-detect",
+ "cc-state-change",
+ "vconn-oc",
+ "vbus-change",
+ "attach-detach",
+ "legacy-cable-detect",
+ "try-snk-src-detect",
+ "sig-tx",
+ "sig-rx",
+ "msg-tx",
+ "msg-rx",
+ "msg-tx-failed",
+ "msg-tx-discarded",
+ "msg-rx-discarded",
+ "fr-swap";
+
+ vdd-vbus-supply = <&pm8150b_vbus>;
+ vdd-pdphy-supply = <&vreg_l2a_3p1>;
+
+ connector {
+ compatible = "usb-c-connector";
+
+ power-role = "source";
+ data-role = "dual";
+ self-powered;
+
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_DUAL_ROLE |
+ PDO_FIXED_USB_COMM | PDO_FIXED_DATA_SWAP)>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ pmic_typec_hs_in: endpoint {
+ remote-endpoint = <&usb_hs_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ pmic_typec_ss_in: endpoint {
+ remote-endpoint = <&usb_phy_typec_ss_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ pmic_typec_sbu: endpoint {
+ remote-endpoint = <&usb_mux_sbu>;
+ };
+ };
+ };
+ };
+ };
+ };
+
+ usb {
+ dr_mode = "otg";
+ usb-role-switch;
+ port {
+ usb_hs_out: endpoint {
+ remote-endpoint = <&pmic_typec_hs_in>;
+ };
+ };
+ };
+
+ usb-phy {
+ orientation-switch;
+ port {
+ usb_phy_typec_ss_out: endpoint {
+ remote-endpoint = <&pmic_typec_ss_in>;
+ };
+ };
+ };
+
+ usb-mux {
+ orientation-switch;
+ mode-switch;
+
+ port {
+ usb_mux_sbu: endpoint {
+ remote-endpoint = <&pmic_typec_sbu>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
new file mode 100644
index 000000000000..8cee7c5582f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
@@ -0,0 +1,660 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/qcom,snps-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Wesley Cheng <quic_wcheng@quicinc.com>
+
+description:
+ Describes the Qualcomm USB block, based on Synopsys DWC3.
+
+select:
+ properties:
+ compatible:
+ contains:
+ const: qcom,snps-dwc3
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,glymur-dwc3
+ - qcom,glymur-dwc3-mp
+ - qcom,ipq4019-dwc3
+ - qcom,ipq5018-dwc3
+ - qcom,ipq5332-dwc3
+ - qcom,ipq5424-dwc3
+ - qcom,ipq6018-dwc3
+ - qcom,ipq8064-dwc3
+ - qcom,ipq8074-dwc3
+ - qcom,ipq9574-dwc3
+ - qcom,kaanapali-dwc3
+ - qcom,milos-dwc3
+ - qcom,msm8953-dwc3
+ - qcom,msm8994-dwc3
+ - qcom,msm8996-dwc3
+ - qcom,msm8998-dwc3
+ - qcom,qcm2290-dwc3
+ - qcom,qcs404-dwc3
+ - qcom,qcs615-dwc3
+ - qcom,qcs8300-dwc3
+ - qcom,qdu1000-dwc3
+ - qcom,sa8775p-dwc3
+ - qcom,sar2130p-dwc3
+ - qcom,sc7180-dwc3
+ - qcom,sc7280-dwc3
+ - qcom,sc8180x-dwc3
+ - qcom,sc8180x-dwc3-mp
+ - qcom,sc8280xp-dwc3
+ - qcom,sc8280xp-dwc3-mp
+ - qcom,sdm660-dwc3
+ - qcom,sdm670-dwc3
+ - qcom,sdm845-dwc3
+ - qcom,sdx55-dwc3
+ - qcom,sdx65-dwc3
+ - qcom,sdx75-dwc3
+ - qcom,sm4250-dwc3
+ - qcom,sm6115-dwc3
+ - qcom,sm6125-dwc3
+ - qcom,sm6350-dwc3
+ - qcom,sm6375-dwc3
+ - qcom,sm8150-dwc3
+ - qcom,sm8250-dwc3
+ - qcom,sm8350-dwc3
+ - qcom,sm8450-dwc3
+ - qcom,sm8550-dwc3
+ - qcom,sm8650-dwc3
+ - qcom,sm8750-dwc3
+ - qcom,x1e80100-dwc3
+ - qcom,x1e80100-dwc3-mp
+ - const: qcom,snps-dwc3
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ required-opps:
+ maxItems: 1
+
+ clocks:
+ description: |
+ Several clocks are used, depending on the variant. Typical ones are::
+ - cfg_noc:: System Config NOC clock.
+ - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ 60MHz for HS operation.
+ - iface:: System bus AXI clock.
+ - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ power mode (U3).
+ - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ mode. Its frequency should be 19.2MHz.
+ minItems: 1
+ maxItems: 9
+
+ clock-names:
+ minItems: 1
+ maxItems: 9
+
+ dma-coherent: true
+
+ iommus:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: usb-ddr
+ - const: apps-usb
+
+ interrupts:
+ description: |
+ Different types of interrupts are used based on HS PHY used on target:
+ - dwc_usb3: Core DWC3 interrupt
+ - pwr_event: Used for wakeup based on other power events.
+ - hs_phy_irq: Apart from DP/DM/QUSB2 PHY interrupts, there is
+ hs_phy_irq which is not triggered by default and its
+ functionality is mutually exclusive to that of
+ {dp/dm}_hs_phy_irq and qusb2_phy_irq.
+ - qusb2_phy: SoCs with QUSB2 PHY do not have separate DP/DM IRQs and
+ expose only a single IRQ whose behavior can be modified
+ by the QUSB2PHY_INTR_CTRL register. The required DPSE/
+ DMSE configuration is done in QUSB2PHY_INTR_CTRL register
+ of PHY address space.
+ - {dp/dm}_hs_phy_irq: These IRQ's directly reflect changes on the DP/
+ DM pads of the SoC. These are used for wakeup
+ only on SoCs with non-QUSB2 targets with
+ exception of SDM670/SDM845/SM6350.
+ - ss_phy_irq: Used for remote wakeup in Super Speed mode of operation.
+ minItems: 3
+ maxItems: 19
+
+ interrupt-names:
+ minItems: 3
+ maxItems: 19
+
+ qcom,select-utmi-as-pipe-clk:
+ description:
+ If present, disable USB3 pipe_clk requirement.
+ Used when dwc3 operates without SSPHY and only
+ HS/FS/LS modes are supported.
+ type: boolean
+
+ wakeup-source: true
+
+# Required child node:
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq4019-dwc3
+ - qcom,ipq5332-dwc3
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ items:
+ - const: core
+ - const: sleep
+ - const: mock_utmi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq8064-dwc3
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Master/Core clock, has to be >= 125 MHz
+ for SS operation and >= 60MHz for HS operation.
+ clock-names:
+ items:
+ - const: core
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq9574-dwc3
+ - qcom,kaanapali-dwc3
+ - qcom,msm8953-dwc3
+ - qcom,msm8996-dwc3
+ - qcom,msm8998-dwc3
+ - qcom,qcs8300-dwc3
+ - qcom,sa8775p-dwc3
+ - qcom,sc7180-dwc3
+ - qcom,sc7280-dwc3
+ - qcom,sdm670-dwc3
+ - qcom,sdm845-dwc3
+ - qcom,sdx55-dwc3
+ - qcom,sdx65-dwc3
+ - qcom,sdx75-dwc3
+ - qcom,sm6350-dwc3
+ - qcom,sm8750-dwc3
+ then:
+ properties:
+ clocks:
+ maxItems: 5
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq6018-dwc3
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 4
+ clock-names:
+ oneOf:
+ - items:
+ - const: core
+ - const: sleep
+ - const: mock_utmi
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: sleep
+ - const: mock_utmi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq8074-dwc3
+ - qcom,qdu1000-dwc3
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: sleep
+ - const: mock_utmi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5018-dwc3
+ - qcom,msm8994-dwc3
+ - qcom,qcs404-dwc3
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+ clock-names:
+ items:
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-dwc3
+ - qcom,sc8280xp-dwc3-mp
+ - qcom,x1e80100-dwc3
+ - qcom,x1e80100-dwc3-mp
+ then:
+ properties:
+ clocks:
+ maxItems: 9
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - const: noc_aggr
+ - const: noc_aggr_north
+ - const: noc_aggr_south
+ - const: noc_sys
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sdm660-dwc3
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 5
+ clock-names:
+ oneOf:
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - items:
+ - const: cfg_noc
+ - const: core
+ - const: sleep
+ - const: mock_utmi
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,milos-dwc3
+ - qcom,qcm2290-dwc3
+ - qcom,qcs615-dwc3
+ - qcom,sar2130p-dwc3
+ - qcom,sc8180x-dwc3
+ - qcom,sc8180x-dwc3-mp
+ - qcom,sm6115-dwc3
+ - qcom,sm6125-dwc3
+ - qcom,sm8150-dwc3
+ - qcom,sm8250-dwc3
+ - qcom,sm8450-dwc3
+ - qcom,sm8550-dwc3
+ - qcom,sm8650-dwc3
+ then:
+ properties:
+ clocks:
+ minItems: 6
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - const: xo
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sm8350-dwc3
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 6
+ clock-names:
+ minItems: 5
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - const: xo
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-dwc3
+ - qcom,glymur-dwc3-mp
+
+ then:
+ properties:
+ clocks:
+ maxItems: 7
+ clock-names:
+ items:
+ - const: cfg_noc
+ - const: core
+ - const: iface
+ - const: sleep
+ - const: mock_utmi
+ - const: noc_aggr_north
+ - const: noc_aggr_south
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5018-dwc3
+ - qcom,ipq6018-dwc3
+ - qcom,ipq8074-dwc3
+ - qcom,msm8953-dwc3
+ - qcom,msm8998-dwc3
+ then:
+ properties:
+ interrupts:
+ minItems: 3
+ maxItems: 4
+ interrupt-names:
+ minItems: 3
+ items:
+ - const: dwc_usb3
+ - const: pwr_event
+ - const: qusb2_phy
+ - const: ss_phy_irq
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,msm8996-dwc3
+ - qcom,qcs404-dwc3
+ - qcom,sdm660-dwc3
+ - qcom,sm6115-dwc3
+ - qcom,sm6125-dwc3
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ maxItems: 5
+ interrupt-names:
+ minItems: 4
+ items:
+ - const: dwc_usb3
+ - const: pwr_event
+ - const: qusb2_phy
+ - const: hs_phy_irq
+ - const: ss_phy_irq
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq5332-dwc3
+ then:
+ properties:
+ interrupts:
+ maxItems: 4
+ interrupt-names:
+ items:
+ - const: dwc_usb3
+ - const: pwr_event
+ - const: dp_hs_phy_irq
+ - const: dm_hs_phy_irq
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-dwc3
+ - qcom,milos-dwc3
+ - qcom,x1e80100-dwc3
+ then:
+ properties:
+ interrupts:
+ minItems: 4
+ maxItems: 5
+ interrupt-names:
+ minItems: 4
+ items:
+ - const: dwc_usb3
+ - const: pwr_event
+ - const: dp_hs_phy_irq
+ - const: dm_hs_phy_irq
+ - const: ss_phy_irq
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,ipq4019-dwc3
+ - qcom,ipq8064-dwc3
+ - qcom,kaanapali-dwc3
+ - qcom,msm8994-dwc3
+ - qcom,qcs615-dwc3
+ - qcom,qcs8300-dwc3
+ - qcom,qdu1000-dwc3
+ - qcom,sa8775p-dwc3
+ - qcom,sc7180-dwc3
+ - qcom,sc7280-dwc3
+ - qcom,sc8180x-dwc3
+ - qcom,sc8280xp-dwc3
+ - qcom,sdm670-dwc3
+ - qcom,sdm845-dwc3
+ - qcom,sdx55-dwc3
+ - qcom,sdx65-dwc3
+ - qcom,sdx75-dwc3
+ - qcom,sm4250-dwc3
+ - qcom,sm6350-dwc3
+ - qcom,sm8150-dwc3
+ - qcom,sm8250-dwc3
+ - qcom,sm8350-dwc3
+ - qcom,sm8450-dwc3
+ - qcom,sm8550-dwc3
+ - qcom,sm8650-dwc3
+ - qcom,sm8750-dwc3
+ then:
+ properties:
+ interrupts:
+ minItems: 5
+ maxItems: 6
+ interrupt-names:
+ minItems: 5
+ items:
+ - const: dwc_usb3
+ - const: pwr_event
+ - const: hs_phy_irq
+ - const: dp_hs_phy_irq
+ - const: dm_hs_phy_irq
+ - const: ss_phy_irq
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-dwc3-mp
+ - qcom,sc8180x-dwc3-mp
+ - qcom,x1e80100-dwc3-mp
+ then:
+ properties:
+ interrupts:
+ minItems: 11
+ maxItems: 11
+ interrupt-names:
+ items:
+ - const: dwc_usb3
+ - const: pwr_event_1
+ - const: pwr_event_2
+ - const: hs_phy_1
+ - const: hs_phy_2
+ - const: dp_hs_phy_1
+ - const: dm_hs_phy_1
+ - const: dp_hs_phy_2
+ - const: dm_hs_phy_2
+ - const: ss_phy_1
+ - const: ss_phy_2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc8280xp-dwc3-mp
+ then:
+ properties:
+ interrupts:
+ minItems: 19
+ maxItems: 19
+ interrupt-names:
+ items:
+ - const: dwc_usb3
+ - const: pwr_event_1
+ - const: pwr_event_2
+ - const: pwr_event_3
+ - const: pwr_event_4
+ - const: hs_phy_1
+ - const: hs_phy_2
+ - const: hs_phy_3
+ - const: hs_phy_4
+ - const: dp_hs_phy_1
+ - const: dm_hs_phy_1
+ - const: dp_hs_phy_2
+ - const: dm_hs_phy_2
+ - const: dp_hs_phy_3
+ - const: dm_hs_phy_3
+ - const: dp_hs_phy_4
+ - const: dm_hs_phy_4
+ - const: ss_phy_1
+ - const: ss_phy_2
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-sdm845.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb@a600000 {
+ compatible = "qcom,sdm845-dwc3", "qcom,snps-dwc3";
+ reg = <0 0x0a600000 0 0x100000>;
+
+ clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
+ <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>;
+ clock-names = "cfg_noc",
+ "core",
+ "iface",
+ "sleep",
+ "mock_utmi";
+
+ assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+ assigned-clock-rates = <19200000>, <150000000>;
+
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 489 IRQ_TYPE_EDGE_BOTH>,
+ <GIC_SPI 488 IRQ_TYPE_EDGE_BOTH>,
+ <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dwc_usb3", "pwr_event", "hs_phy_irq",
+ "dp_hs_phy_irq", "dm_hs_phy_irq", "ss_phy_irq";
+
+ power-domains = <&gcc USB30_PRIM_GDSC>;
+
+ resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+ iommus = <&apps_smmu 0x740 0>;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml b/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml
new file mode 100644
index 000000000000..96dcec9b7620
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/qcom,wcd939x-usbss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm WCD9380/WCD9385 USB SubSystem Altmode/Analog Audio Switch
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ Qualcomm WCD9390/WCD9395 is a standalone Hi-Fi audio codec IC with a
+ functionally separate USB SubSystem for Altmode/Analog Audio Switch
+ accessible over an I2C interface.
+ The Audio Headphone and Microphone data path between the Codec and the
+ USB-C Mux subsystems are external to the IC, thus requiring DT port-endpoint
+ graph description to handle USB-C altmode & orientation switching for Audio
+ Accessory Mode.
+
+properties:
+ compatible:
+ oneOf:
+ - const: qcom,wcd9390-usbss
+ - items:
+ - const: qcom,wcd9395-usbss
+ - const: qcom,wcd9390-usbss
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ vdd-supply:
+ description: USBSS VDD power supply
+
+ mode-switch: true
+ orientation-switch: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the WCD939x USB SubSystem to a TypeC controller for the
+ purpose of handling altmode muxing and orientation switching.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ A port node to link the WCD939x USB SubSystem to the Codec SubSystem for the
+ purpose of handling USB-C Audio Accessory Mode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+ - ports
+
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@42 {
+ compatible = "qcom,wcd9390-usbss";
+ reg = <0x42>;
+
+ vdd-supply = <&vreg_bob>;
+
+ mode-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ wcd9390_usbss_sbu: endpoint {
+ remote-endpoint = <&typec_sbu>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ wcd9390_usbss_codec: endpoint {
+ remote-endpoint = <&wcd9390_codec_usbss>;
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/realtek,rtd-dwc3.yaml b/Documentation/devicetree/bindings/usb/realtek,rtd-dwc3.yaml
new file mode 100644
index 000000000000..345d0132d4a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/realtek,rtd-dwc3.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/realtek,rtd-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DWC3 USB SoC Controller Glue
+
+maintainers:
+ - Stanley Chang <stanley_chang@realtek.com>
+
+description:
+ The Realtek DHC SoC embeds a DWC3 USB IP Core configured for USB 2.0
+ and USB 3.0 in host or dual-role mode.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - realtek,rtd1295-dwc3
+ - realtek,rtd1315e-dwc3
+ - realtek,rtd1319-dwc3
+ - realtek,rtd1319d-dwc3
+ - realtek,rtd1395-dwc3
+ - realtek,rtd1619-dwc3
+ - realtek,rtd1619b-dwc3
+ - const: realtek,rtd-dwc3
+
+ reg:
+ items:
+ - description: Address and length of register set for wrapper of dwc3 core.
+ - description: Address and length of register set for pm control.
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^usb@[0-9a-f]+$":
+ $ref: snps,dwc3.yaml#
+ description: Required child node
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@98013e00 {
+ compatible = "realtek,rtd1319d-dwc3", "realtek,rtd-dwc3";
+ reg = <0x98013e00 0x140>, <0x98013f60 0x4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usb@98050000 {
+ compatible = "snps,dwc3";
+ reg = <0x98050000 0x9000>;
+ interrupts = <0 94 4>;
+ phys = <&usb2phy &usb3phy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ dr_mode = "otg";
+ usb-role-switch;
+ role-switch-default-mode = "host";
+ snps,dis_u2_susphy_quirk;
+ snps,parkmode-disable-ss-quirk;
+ snps,parkmode-disable-hs-quirk;
+ maximum-speed = "high-speed";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/realtek,rtd-type-c.yaml b/Documentation/devicetree/bindings/usb/realtek,rtd-type-c.yaml
new file mode 100644
index 000000000000..6142b0b5b534
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/realtek,rtd-type-c.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/realtek,rtd-type-c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD SoCs USB Type-C Connector detection
+
+maintainers:
+ - Stanley Chang <stanley_chang@realtek.com>
+
+description:
+ Realtek digital home center (DHC) RTD series SoCs include a type c module.
+ This module is able to detect the state of type c connector.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1295-type-c
+ - realtek,rtd1312c-type-c
+ - realtek,rtd1315e-type-c
+ - realtek,rtd1319-type-c
+ - realtek,rtd1319d-type-c
+ - realtek,rtd1395-type-c
+ - realtek,rtd1619-type-c
+ - realtek,rtd1619b-type-c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ nvmem-cell-names:
+ items:
+ - const: usb-cal
+
+ nvmem-cells:
+ maxItems: 1
+ description:
+ The phandle to nvmem cell that contains the trimming data.
+ The type c parameter trimming data specified via efuse.
+ If unspecified, default value is used.
+
+ realtek,rd-ctrl-gpios:
+ description: The gpio node to control external Rd on board.
+ maxItems: 1
+
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ description: Properties for usb c connector.
+ type: object
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ type-c@7220 {
+ compatible = "realtek,rtd1619b-type-c";
+ reg = <0x7220 0x20>;
+ interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_cc1_pins>, <&usb_cc2_pins>;
+ nvmem-cells = <&otp_usb_cal>;
+ nvmem-cell-names = "usb-cal";
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml
index 50f2b505bdeb..a020afaf2d6e 100644
--- a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml
+++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml
@@ -1,16 +1,16 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/realtek,rts5411.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for the Realtek RTS5411 USB 3.0 hub controller
+title: Realtek RTS5411 USB 3.0 hub controller
maintainers:
- Matthias Kaehlcke <mka@chromium.org>
allOf:
- - $ref: usb-device.yaml#
+ - $ref: usb-hub.yaml#
properties:
compatible:
@@ -19,24 +19,35 @@ properties:
- usbbda,5411
- usbbda,411
- reg: true
-
vdd-supply:
description:
phandle to the regulator that provides power to the hub.
- peer-hub:
- $ref: '/schemas/types.yaml#/definitions/phandle'
- description:
- phandle to the peer hub on the controller.
+ peer-hub: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ patternProperties:
+ '^port@':
+ $ref: /schemas/graph.yaml#/properties/port
+
+ properties:
+ reg:
+ minimum: 1
+ maximum: 4
+
+additionalProperties:
+ properties:
+ reg:
+ minimum: 1
+ maximum: 4
required:
- peer-hub
- compatible
- reg
-additionalProperties: false
-
examples:
- |
usb {
@@ -50,6 +61,13 @@ examples:
reg = <1>;
vdd-supply = <&pp3300_hub>;
peer-hub = <&hub_3_0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* USB 2.0 device on port 2 */
+ device@2 {
+ compatible = "usb123,4567";
+ reg = <2>;
+ };
};
/* 3.0 hub on port 2 */
@@ -58,5 +76,17 @@ examples:
reg = <2>;
vdd-supply = <&pp3300_hub>;
peer-hub = <&hub_2_0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* Type-A connector on port 4 */
+ port@4 {
+ reg = <4>;
+ endpoint {
+ remote-endpoint = <&usb_a0_ss>;
+ };
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/usb/renesas,rzg3e-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,rzg3e-xhci.yaml
new file mode 100644
index 000000000000..3f4b09e48ce0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rzg3e-xhci.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/renesas,rzg3e-xhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas USB 3.2 Gen2 Host controller
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a09g056-xhci # RZ/V2N
+ - renesas,r9a09g057-xhci # RZ/V2H(P)
+ - const: renesas,r9a09g047-xhci
+
+ - items:
+ - const: renesas,r9a09g047-xhci # RZ/G3E
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Logical OR of all interrupt signals.
+ - description: System management interrupt
+ - description: Host system error interrupt
+ - description: Power management event interrupt
+ - description: xHC interrupt
+
+ interrupt-names:
+ items:
+ - const: all
+ - const: smi
+ - const: hse
+ - const: pme
+ - const: xhc
+
+ clocks:
+ maxItems: 1
+
+ phys:
+ maxItems: 2
+
+ phy-names:
+ items:
+ - const: usb2-phy
+ - const: usb3-phy
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - power-domains
+ - resets
+ - phys
+ - phy-names
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g047-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@15850000 {
+ compatible = "renesas,r9a09g047-xhci";
+ reg = <0x15850000 0x10000>;
+ interrupts = <GIC_SPI 759 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 758 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 757 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 756 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 755 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "all", "smi", "hse", "pme", "xhc";
+ clocks = <&cpg CPG_MOD 0xaf>;
+ power-domains = <&cpg>;
+ resets = <&cpg 0xaa>;
+ phys = <&usb3_phy>, <&usb3_phy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
diff --git a/Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml b/Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml
new file mode 100644
index 000000000000..b6e84a2a6925
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/renesas,rzn1-usbf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/N1 SoCs USBF (USB Function) controller
+
+description: |
+ The Renesas USBF controller is an USB2.0 device
+ controller (UDC).
+
+maintainers:
+ - Herve Codina <herve.codina@bootlin.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a06g032-usbf
+ - const: renesas,rzn1-usbf
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Internal bus clock (AHB) for Function
+ - description: Internal bus clock (AHB) for Power Management
+
+ clock-names:
+ items:
+ - const: hclkf
+ - const: hclkpm
+
+ power-domains:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: The USBF EPC interrupt
+ - description: The USBF AHB-EPC interrupt
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+
+ usb@4001e000 {
+ compatible = "renesas,r9a06g032-usbf", "renesas,rzn1-usbf";
+ reg = <0x4001e000 0x2000>;
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysctrl R9A06G032_HCLK_USBF>,
+ <&sysctrl R9A06G032_HCLK_USBPM>;
+ clock-names = "hclkf", "hclkpm";
+ power-domains = <&sysctrl>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml b/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml
new file mode 100644
index 000000000000..b87e139c29e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rzv2m-usb3drd.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/renesas,rzv2m-usb3drd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2M USB 3.1 DRD controller
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+description: |
+ The RZ/V2{M, MA} USB3.1 DRD module supports the following functions
+ * Role swapping function by the ID pin of the Micro-AB receptacle
+ * Battery Charging Specification Revision 1.2
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a09g011-usb3drd # RZ/V2M
+ - renesas,r9a09g055-usb3drd # RZ/V2MA
+ - const: renesas,rzv2m-usb3drd
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Dual Role Device (DRD)
+ - description: Battery Charging
+ - description: Global Purpose Input
+
+ interrupt-names:
+ items:
+ - const: drd
+ - const: bc
+ - const: gpi
+
+ clocks:
+ items:
+ - description: Peripheral AXI clock
+ - description: APB clock
+
+ clock-names:
+ items:
+ - const: axi
+ - const: reg
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ enum: [ 1, 2 ]
+
+ '#size-cells':
+ enum: [ 1, 2 ]
+
+patternProperties:
+ "^usb3peri@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/usb/renesas,usb3-peri.yaml
+
+ "^usb@[0-9a-f]+$":
+ type: object
+ $ref: renesas,usb-xhci.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a09g011-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb3drd: usb@85070400 {
+ compatible = "renesas,r9a09g011-usb3drd", "renesas,rzv2m-usb3drd";
+ reg = <0x85070400 0x100>;
+ interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "drd", "bc", "gpi";
+ clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_P>,
+ <&cpg CPG_MOD R9A09G011_USB_PCLK>;
+ clock-names = "axi", "reg";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A09G011_USB_DRD_RESET>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usb3host: usb@85060000 {
+ compatible = "renesas,r9a09g011-xhci",
+ "renesas,rzv2m-xhci";
+ reg = <0x85060000 0x2000>;
+ interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_H>,
+ <&cpg CPG_MOD R9A09G011_USB_PCLK>;
+ clock-names = "axi", "reg";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A09G011_USB_ARESETN_H>;
+ };
+
+ usb3peri: usb3peri@85070000 {
+ compatible = "renesas,r9a09g011-usb3-peri",
+ "renesas,rzv2m-usb3-peri";
+ reg = <0x85070000 0x400>;
+ interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A09G011_USB_ACLK_P>,
+ <&cpg CPG_MOD R9A09G011_USB_PCLK>;
+ clock-names = "axi", "reg";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A09G011_USB_ARESETN_P>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
index 4c5efaf02308..1a07c0d2b1b1 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml
@@ -10,9 +10,6 @@ maintainers:
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
-allOf:
- - $ref: "usb-xhci.yaml"
-
properties:
compatible:
oneOf:
@@ -37,6 +34,11 @@ properties:
- renesas,xhci-r8a77965 # R-Car M3-N
- renesas,xhci-r8a77990 # R-Car E3
- const: renesas,rcar-gen3-xhci # R-Car Gen3 and RZ/G2
+ - items:
+ - enum:
+ - renesas,r9a09g011-xhci # RZ/V2M
+ - renesas,r9a09g055-xhci # RZ/V2MA
+ - const: renesas,rzv2m-xhci # RZ/{V2M, V2MA}
reg:
maxItems: 1
@@ -45,7 +47,16 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Main clock for host
+ - description: Register access clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: axi
+ - const: reg
phys:
maxItems: 1
@@ -68,6 +79,28 @@ required:
- power-domains
- resets
+allOf:
+ - $ref: usb-xhci.yaml
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rzv2m-xhci
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ required:
+ - clock-names
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
index 9fcf54b10b07..4e56e4ffeaf2 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml
@@ -11,18 +11,25 @@ maintainers:
properties:
compatible:
- items:
- - enum:
- - renesas,r8a774a1-usb3-peri # RZ/G2M
- - renesas,r8a774b1-usb3-peri # RZ/G2N
- - renesas,r8a774c0-usb3-peri # RZ/G2E
- - renesas,r8a774e1-usb3-peri # RZ/G2H
- - renesas,r8a7795-usb3-peri # R-Car H3
- - renesas,r8a7796-usb3-peri # R-Car M3-W
- - renesas,r8a77961-usb3-peri # R-Car M3-W+
- - renesas,r8a77965-usb3-peri # R-Car M3-N
- - renesas,r8a77990-usb3-peri # R-Car E3
- - const: renesas,rcar-gen3-usb3-peri
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r8a774a1-usb3-peri # RZ/G2M
+ - renesas,r8a774b1-usb3-peri # RZ/G2N
+ - renesas,r8a774c0-usb3-peri # RZ/G2E
+ - renesas,r8a774e1-usb3-peri # RZ/G2H
+ - renesas,r8a7795-usb3-peri # R-Car H3
+ - renesas,r8a7796-usb3-peri # R-Car M3-W
+ - renesas,r8a77961-usb3-peri # R-Car M3-W+
+ - renesas,r8a77965-usb3-peri # R-Car M3-N
+ - renesas,r8a77990-usb3-peri # R-Car E3
+ - const: renesas,rcar-gen3-usb3-peri
+
+ - items:
+ - enum:
+ - renesas,r9a09g011-usb3-peri # RZ/V2M
+ - renesas,r9a09g055-usb3-peri # RZ/V2MA
+ - const: renesas,rzv2m-usb3-peri
reg:
maxItems: 1
@@ -31,7 +38,16 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Main clock
+ - description: Register access clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: axi
+ - const: reg
phys:
maxItems: 1
@@ -78,6 +94,27 @@ required:
- interrupts
- clocks
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,rzv2m-usb3-peri
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ required:
+ - clock-names
+ - resets
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+
additionalProperties: false
examples:
@@ -95,19 +132,19 @@ examples:
usb-role-switch;
ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- usb3_hs_ep: endpoint {
- remote-endpoint = <&hs_ep>;
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ usb3_hs_ep: endpoint {
+ remote-endpoint = <&hs_ep>;
};
- port@1 {
- reg = <1>;
- usb3_role_switch: endpoint {
- remote-endpoint = <&hd3ss3220_out_ep>;
- };
+ };
+ port@1 {
+ reg = <1>;
+ usb3_role_switch: endpoint {
+ remote-endpoint = <&hd3ss3220_out_ep>;
};
+ };
};
};
diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
index bad55dfb2fa0..0b8b90dd1951 100644
--- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
+++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
@@ -19,10 +19,17 @@ properties:
- items:
- enum:
- renesas,usbhs-r7s9210 # RZ/A2
- - renesas,usbhs-r9a07g043 # RZ/G2UL
+ - const: renesas,rza2-usbhs
+
+ - items:
+ - enum:
+ - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five
- renesas,usbhs-r9a07g044 # RZ/G2{L,LC}
- renesas,usbhs-r9a07g054 # RZ/V2L
- - const: renesas,rza2-usbhs
+ - renesas,usbhs-r9a08g045 # RZ/G3S
+ - renesas,usbhs-r9a09g056 # RZ/V2N
+ - renesas,usbhs-r9a09g057 # RZ/V2H(P)
+ - const: renesas,rzg2l-usbhs
- items:
- enum:
@@ -52,6 +59,12 @@ properties:
- renesas,usbhs-r8a77995 # R-Car D3
- const: renesas,rcar-gen3-usbhs
+ - const: renesas,usbhs-r9a09g077 # RZ/T2H
+
+ - items:
+ - const: renesas,usbhs-r9a09g087 # RZ/N2H
+ - const: renesas,usbhs-r9a09g077 # RZ/T2H
+
reg:
maxItems: 1
@@ -72,6 +85,10 @@ properties:
Integer to use BUSWAIT register.
renesas,enable-gpio:
+ deprecated: true
+ maxItems: 1
+
+ renesas,enable-gpios:
maxItems: 1
description: |
gpio specifier to check GPIO determining if USB function should be
@@ -118,10 +135,7 @@ allOf:
properties:
compatible:
contains:
- enum:
- - renesas,usbhs-r9a07g043
- - renesas,usbhs-r9a07g044
- - renesas,usbhs-r9a07g054
+ const: renesas,rzg2l-usbhs
then:
properties:
interrupts:
@@ -133,9 +147,25 @@ allOf:
required:
- resets
else:
- properties:
- interrupts:
- maxItems: 1
+ if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,usbhs-r9a09g077
+ then:
+ properties:
+ resets: false
+ clocks:
+ maxItems: 1
+ interrupts:
+ items:
+ - description: USB function interrupt USB_FI
+ - description: USB function DMA0 transmit completion interrupt USB_FDMA0
+ - description: USB function DMA1 transmit completion interrupt USB_FDMA1
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
new file mode 100644
index 000000000000..ae611f7e57ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/richtek,rt1711h.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT1711H Type-C Port Switch and Power Delivery controller
+
+maintainers:
+ - Gene Chen <gene_chen@richtek.com>
+
+description: |
+ The RT1711H is a USB Type-C controller that complies with the latest
+ USB Type-C and PD standards. It does the USB Type-C detection including attach
+ and orientation. It integrates the physical layer of the USB BMC power
+ delivery protocol to allow up to 100W of power. The BMC PD block enables full
+ support for alternative interfaces of the Type-C specification.
+
+properties:
+ compatible:
+ enum:
+ - richtek,rt1711h
+ - richtek,rt1715
+ description:
+ RT1711H support PD20, RT1715 support PD30 except Fast Role Swap.
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ vbus-supply:
+ description: VBUS power supply
+
+ wakeup-source:
+ type: boolean
+
+ connector:
+ type: object
+ $ref: /schemas/connector/usb-connector.yaml#
+ description:
+ Properties for usb c connector.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - connector
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/usb/pd.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rt1711h@4e {
+ compatible = "richtek,rt1711h";
+ reg = <0x4e>;
+ interrupts-extended = <&gpio26 3 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
+ sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
+ op-sink-microwatt = <10000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ endpoint {
+ remote-endpoint = <&usb_hs>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ endpoint {
+ remote-endpoint = <&usb_ss>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+ endpoint {
+ remote-endpoint = <&dp_aux>;
+ };
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml
index 65a93f7738d5..07bec1fe6ebf 100644
--- a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml
@@ -1,16 +1,16 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/richtek,rt1719.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/richtek,rt1719.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Richtek RT1719 sink-only Type-C PD controller bindings
+title: Richtek RT1719 sink-only Type-C PD controller
maintainers:
- ChiYuan Huang <cy_huang@richtek.com>
description: |
- The RT1719 is a sink-only USB Type-C contoller that complies with the latest
+ The RT1719 is a sink-only USB Type-C controller that complies with the latest
USB Type-C and PD standards. It does the USB Type-C detection including attach
and orientation. It integrates the physical layer of the USB BMC power
delivery protocol to allow up to 100W of power. The BMC PD block enables full
@@ -48,7 +48,7 @@ required:
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
index b3798d94d2fd..fd1b13c0ed6b 100644
--- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
@@ -15,13 +15,10 @@ description:
Phy documentation is provided in the following places.
USB2.0 PHY
- Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml
+ Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
Type-C PHY
- Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
-
-allOf:
- - $ref: snps,dwc3.yaml#
+ Documentation/devicetree/bindings/phy/rockchip,rk3399-typec-phy.yaml
select:
properties:
@@ -29,8 +26,10 @@ select:
contains:
enum:
- rockchip,rk3328-dwc3
- - rockchip,rk3399-dwc3
+ - rockchip,rk3562-dwc3
- rockchip,rk3568-dwc3
+ - rockchip,rk3576-dwc3
+ - rockchip,rk3588-dwc3
required:
- compatible
@@ -39,8 +38,10 @@ properties:
items:
- enum:
- rockchip,rk3328-dwc3
- - rockchip,rk3399-dwc3
+ - rockchip,rk3562-dwc3
- rockchip,rk3568-dwc3
+ - rockchip,rk3576-dwc3
+ - rockchip,rk3588-dwc3
- const: snps,dwc3
reg:
@@ -60,7 +61,9 @@ properties:
Master/Core clock, must to be >= 62.5 MHz for SS
operation and >= 30MHz for HS operation
- description:
- Controller grf clock
+ Controller grf clock OR UTMI clock
+ - description:
+ PIPE clock
clock-names:
minItems: 3
@@ -68,7 +71,11 @@ properties:
- const: ref_clk
- const: suspend_clk
- const: bus_clk
- - const: grf_clk
+ - enum:
+ - grf_clk
+ - utmi
+ - pipe
+ - const: pipe
power-domains:
maxItems: 1
@@ -88,9 +95,73 @@ required:
- clocks
- clock-names
+allOf:
+ - $ref: snps,dwc3.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3328-dwc3
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 4
+ clock-names:
+ minItems: 3
+ items:
+ - const: ref_clk
+ - const: suspend_clk
+ - const: bus_clk
+ - const: grf_clk
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3562-dwc3
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: ref_clk
+ - const: suspend_clk
+ - const: bus_clk
+ - const: pipe
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3568-dwc3
+ - rockchip,rk3576-dwc3
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+ clock-names:
+ maxItems: 3
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-dwc3
+ then:
+ properties:
+ clock-names:
+ minItems: 3
+ items:
+ - const: ref_clk
+ - const: suspend_clk
+ - const: bus_clk
+ - const: utmi
+ - const: pipe
+
examples:
- |
- #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/clock/rk3328-cru.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
bus {
@@ -98,11 +169,11 @@ examples:
#size-cells = <2>;
usbdrd3_0: usb@fe800000 {
- compatible = "rockchip,rk3399-dwc3", "snps,dwc3";
+ compatible = "rockchip,rk3328-dwc3", "snps,dwc3";
reg = <0x0 0xfe800000 0x0 0x100000>;
interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
- <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
+ <&cru ACLK_USB3OTG>;
clock-names = "ref_clk", "suspend_clk",
"bus_clk", "grf_clk";
dr_mode = "otg";
diff --git a/Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml
new file mode 100644
index 000000000000..3159f9a6a0f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/rockchip,rk3399-dwc3.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/rockchip,rk3399-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3399 SuperSpeed DWC3 USB SoC controller
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-dwc3
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ ranges: true
+
+ clocks:
+ items:
+ - description:
+ Controller reference clock, must to be 24 MHz
+ - description:
+ Controller suspend clock, must to be 24 MHz or 32 KHz
+ - description:
+ Master/Core clock, must to be >= 62.5 MHz for SS
+ operation and >= 30MHz for HS operation
+ - description:
+ USB3 aclk peri
+ - description:
+ USB3 aclk
+ - description:
+ Controller grf clock
+
+ clock-names:
+ items:
+ - const: ref_clk
+ - const: suspend_clk
+ - const: bus_clk
+ - const: aclk_usb3_rksoc_axi_perf
+ - const: aclk_usb3
+ - const: grf_clk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: usb3-otg
+
+patternProperties:
+ '^usb@':
+ $ref: snps,dwc3.yaml#
+
+additionalProperties: false
+
+required:
+ - compatible
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/power/rk3399-power.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb {
+ compatible = "rockchip,rk3399-dwc3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "grf_clk";
+ resets = <&cru SRST_A_USB3_OTG0>;
+ reset-names = "usb3-otg";
+
+ usb@fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru ACLK_USB3OTG0>,
+ <&cru SCLK_USB3OTG0_SUSPEND>;
+ clock-names = "ref", "bus_early", "suspend";
+ dr_mode = "otg";
+ phys = <&u2phy0_otg>, <&tcphy0_usb3>;
+ phy-names = "usb2-phy", "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,dis-tx-ipgap-linecheck-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
deleted file mode 100644
index 26c85afd0b53..000000000000
--- a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Samsung S3C2410 and compatible SoC USB controller
-
-OHCI
-
-Required properties:
- - compatible: should be "samsung,s3c2410-ohci" for USB host controller
- - reg: address and length of the controller memory mapped region
- - interrupts: interrupt number for the USB OHCI controller
- - clocks: Should reference the bus and host clocks
- - clock-names: Should contain two strings
- "usb-bus-host" for the USB bus clock
- "usb-host" for the USB host clock
-
-Example:
-
-usb0: ohci@49000000 {
- compatible = "samsung,s3c2410-ohci";
- reg = <0x49000000 0x100>;
- interrupts = <0 0 26 3>;
- clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
- clock-names = "usb-bus-host", "usb-host";
-};
diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
index 6b9a3bcb3926..8af0143c3e47 100644
--- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
@@ -11,10 +11,22 @@ maintainers:
properties:
compatible:
- enum:
- - samsung,exynos5250-dwusb3
- - samsung,exynos5433-dwusb3
- - samsung,exynos7-dwusb3
+ oneOf:
+ - enum:
+ - google,gs101-dwusb3
+ - samsung,exynos2200-dwusb3
+ - samsung,exynos5250-dwusb3
+ - samsung,exynos5433-dwusb3
+ - samsung,exynos7-dwusb3
+ - samsung,exynos7870-dwusb3
+ - samsung,exynos850-dwusb3
+ - samsung,exynosautov920-dwusb3
+ - items:
+ - const: samsung,exynos8890-dwusb3
+ - const: samsung,exynos7-dwusb3
+ - items:
+ - const: samsung,exynos990-dwusb3
+ - const: samsung,exynos850-dwusb3
'#address-cells':
const: 1
@@ -27,6 +39,9 @@ properties:
minItems: 1
maxItems: 4
+ power-domains:
+ maxItems: 1
+
ranges: true
'#size-cells':
@@ -50,7 +65,6 @@ required:
- clock-names
- ranges
- '#size-cells'
- - vdd10-supply
- vdd33-supply
allOf:
@@ -58,6 +72,38 @@ allOf:
properties:
compatible:
contains:
+ const: google,gs101-dwusb3
+ then:
+ properties:
+ clocks:
+ minItems: 4
+ maxItems: 4
+ clock-names:
+ items:
+ - const: bus_early
+ - const: susp_clk
+ - const: link_aclk
+ - const: link_pclk
+ required:
+ - vdd10-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos2200-dwusb3
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: link_aclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
const: samsung,exynos5250-dwusb3
then:
properties:
@@ -67,12 +113,14 @@ allOf:
clock-names:
items:
- const: usbdrd30
+ required:
+ - vdd10-supply
- if:
properties:
compatible:
contains:
- const: samsung,exynos54333-dwusb3
+ const: samsung,exynos5433-dwusb3
then:
properties:
clocks:
@@ -82,8 +130,10 @@ allOf:
items:
- const: aclk
- const: susp_clk
- - const: pipe_pclk
- const: phyclk
+ - const: pipe_pclk
+ required:
+ - vdd10-supply
- if:
properties:
@@ -100,6 +150,56 @@ allOf:
- const: usbdrd30
- const: usbdrd30_susp_clk
- const: usbdrd30_axius_clk
+ required:
+ - vdd10-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos7870-dwusb3
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: bus_early
+ - const: ref
+ - const: ctrl
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynos850-dwusb3
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: bus_early
+ - const: ref
+ required:
+ - vdd10-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,exynosautov920-dwusb3
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ items:
+ - const: ref
+ - const: susp_clk
additionalProperties: false
@@ -108,19 +208,19 @@ examples:
#include <dt-bindings/clock/exynos5420.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
- usb {
+ usb@12000000 {
compatible = "samsung,exynos5250-dwusb3";
#address-cells = <1>;
#size-cells = <1>;
- ranges;
+ ranges = <0x0 0x12000000 0x10000>;
clocks = <&clock CLK_USBD300>;
clock-names = "usbdrd30";
vdd33-supply = <&ldo9_reg>;
vdd10-supply = <&ldo11_reg>;
- usb@12000000 {
+ usb@0 {
compatible = "snps,dwc3";
- reg = <0x12000000 0x10000>;
+ reg = <0x0 0x10000>;
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
phy-names = "usb2-phy", "usb3-phy";
diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
deleted file mode 100644
index 0388634598ce..000000000000
--- a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Samsung High Speed USB OTG controller
------------------------------
-
-The Samsung HSOTG IP can be found on Samsung SoCs, from S3C6400 onwards.
-It gives functionality of OTG-compliant USB 2.0 host and device with
-support for USB 2.0 high-speed (480Mbps) and full-speed (12 Mbps)
-operation.
-
-Currently only device mode is supported.
-
-Binding details
------
-
-Required properties:
-- compatible: "samsung,s3c6400-hsotg" should be used for all currently
- supported SoC,
-- interrupts: specifier of interrupt signal of interrupt controller,
- according to bindings of interrupt controller,
-- clocks: contains an array of clock specifiers:
- - first entry: OTG clock
-- clock-names: contains array of clock names:
- - first entry: must be "otg"
-- vusb_d-supply: phandle to voltage regulator of digital section,
-- vusb_a-supply: phandle to voltage regulator of analog section.
-
-Example
------
-
- hsotg@12480000 {
- compatible = "samsung,s3c6400-hsotg";
- reg = <0x12480000 0x20000>;
- interrupts = <0 71 0>;
- clocks = <&clock 305>;
- clock-names = "otg";
- vusb_d-supply = <&vusb_reg>;
- vusb_a-supply = <&vusbdac_reg>;
- };
-
diff --git a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
index 321b6f166197..18e35122dc1f 100644
--- a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
+++ b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/smsc,usb3503.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SMSC USB3503 High-Speed Hub Controller Device Tree Bindings
+title: SMSC USB3503 High-Speed Hub Controller
maintainers:
- Dongjin Kim <tobetter@gmail.com>
@@ -14,6 +14,7 @@ properties:
enum:
- smsc,usb3503
- smsc,usb3503a
+ - smsc,usb3803
reg:
maxItems: 1
@@ -33,6 +34,12 @@ properties:
description: >
GPIO for reset
+ bypass-gpios:
+ maxItems: 1
+ description: >
+ GPIO for bypass.
+ Control signal to select between HUB MODE and BYPASS MODE.
+
disabled-ports:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
@@ -46,9 +53,10 @@ properties:
initial-mode:
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2]
description: >
- Specifies initial mode. 1 for Hub mode, 2 for standby mode.
+ Specifies initial mode. 1 for Hub mode, 2 for standby mode and 3 for bypass mode.
+ In bypass mode the downstream port 3 is connected to the upstream port with low
+ switch resistance R_on.
clocks:
maxItems: 1
@@ -71,39 +79,81 @@ properties:
required:
- compatible
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ enum:
+ - smsc,usb3803
+ then:
+ properties:
+ bypass-gpios: false
+
+ - if:
+ required:
+ - bypass-gpios
+ then:
+ properties:
+ initial-mode:
+ enum: [1, 2, 3]
+ else:
+ properties:
+ initial-mode:
+ enum: [1, 2]
+
additionalProperties: false
examples:
- |
- i2c {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb-hub@8 {
- compatible = "smsc,usb3503";
- reg = <0x08>;
- connect-gpios = <&gpx3 0 1>;
- disabled-ports = <2 3>;
- intn-gpios = <&gpx3 4 1>;
- reset-gpios = <&gpx3 5 1>;
- initial-mode = <1>;
- clocks = <&clks 80>;
- clock-names = "refclk";
- };
- };
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb-hub@8 {
+ compatible = "smsc,usb3503";
+ reg = <0x08>;
+ connect-gpios = <&gpx3 0 1>;
+ disabled-ports = <2 3>;
+ intn-gpios = <&gpx3 4 1>;
+ reset-gpios = <&gpx3 5 1>;
+ initial-mode = <1>;
+ clocks = <&clks 80>;
+ clock-names = "refclk";
+ };
+ };
+
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb-hub@8 {
+ compatible = "smsc,usb3803";
+ reg = <0x08>;
+ connect-gpios = <&gpx3 0 1>;
+ disabled-ports = <2 3>;
+ intn-gpios = <&gpx3 4 1>;
+ reset-gpios = <&gpx3 5 1>;
+ bypass-gpios = <&gpx3 6 1>;
+ initial-mode = <3>;
+ clocks = <&clks 80>;
+ clock-names = "refclk";
+ };
+ };
- |
- #include <dt-bindings/gpio/gpio.h>
-
- usb-hub {
- /* I2C is not connected */
- compatible = "smsc,usb3503";
- initial-mode = <1>; /* initialize in HUB mode */
- disabled-ports = <1>;
- intn-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
- reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
- connect-gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */
- refclk-frequency = <19200000>;
- };
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb-hub {
+ /* I2C is not connected */
+ compatible = "smsc,usb3503";
+ initial-mode = <1>; /* initialize in HUB mode */
+ disabled-ports = <1>;
+ intn-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+ reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+ connect-gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */
+ refclk-frequency = <19200000>;
+ };
...
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
new file mode 100644
index 000000000000..6c0b8b653824
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml
@@ -0,0 +1,432 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/snps,dwc3-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare USB3 Controller common properties
+
+maintainers:
+ - Felipe Balbi <balbi@kernel.org>
+
+description:
+ Defines the properties of the DWC3 core as being embedded in either an
+ vendor-specific implementation or as a standalone component.
+
+allOf:
+ - $ref: usb-drd.yaml#
+ - if:
+ properties:
+ dr_mode:
+ const: peripheral
+
+ required:
+ - dr_mode
+ then:
+ $ref: usb.yaml#
+ else:
+ $ref: usb-xhci.yaml#
+
+properties:
+ extcon:
+ maxItems: 1
+ deprecated: true
+
+ usb-phy:
+ minItems: 1
+ items:
+ - description: USB2/HS PHY
+ - description: USB3/SS PHY
+
+ phys:
+ minItems: 1
+ maxItems: 19
+
+ phy-names:
+ minItems: 1
+ maxItems: 19
+ oneOf:
+ - items:
+ enum: [ usb2-phy, usb3-phy ]
+ - items:
+ pattern: "^usb(2-([0-9]|1[0-4])|3-[0-3])$"
+
+ snps,usb2-lpm-disable:
+ description: Indicate if we don't want to enable USB2 HW LPM for host
+ mode.
+ type: boolean
+
+ snps,usb3_lpm_capable:
+ description: Determines if platform is USB3 LPM capable
+ type: boolean
+
+ snps,usb2-gadget-lpm-disable:
+ description: Indicate if we don't want to enable USB2 HW LPM for gadget
+ mode.
+ type: boolean
+
+ snps,reserved-endpoints:
+ description:
+ Reserve endpoints for other needs, e.g, for tracing control and output.
+ When set, the driver will avoid using them for the regular USB transfers.
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ minItems: 1
+ maxItems: 30
+ items:
+ minimum: 2
+ maximum: 31
+
+ snps,dis-start-transfer-quirk:
+ description:
+ When set, disable isoc START TRANSFER command failure SW work-around
+ for DWC_usb31 version 1.70a-ea06 and prior.
+ type: boolean
+
+ snps,disable_scramble_quirk:
+ description:
+ True when SW should disable data scrambling. Only really useful for FPGA
+ builds.
+ type: boolean
+
+ snps,has-lpm-erratum:
+ description: True when DWC3 was configured with LPM Erratum enabled
+ type: boolean
+
+ snps,lpm-nyet-threshold:
+ description: LPM NYET threshold
+ $ref: /schemas/types.yaml#/definitions/uint8
+
+ snps,u2exit_lfps_quirk:
+ description: Set if we want to enable u2exit lfps quirk
+ type: boolean
+
+ snps,u2ss_inp3_quirk:
+ description: Set if we enable P3 OK for U2/SS Inactive quirk
+ type: boolean
+
+ snps,req_p1p2p3_quirk:
+ description:
+ When set, the core will always request for P1/P2/P3 transition sequence.
+ type: boolean
+
+ snps,del_p1p2p3_quirk:
+ description:
+ When set core will delay P1/P2/P3 until a certain amount of 8B10B errors
+ occur.
+ type: boolean
+
+ snps,del_phy_power_chg_quirk:
+ description: When set core will delay PHY power change from P0 to P1/P2/P3.
+ type: boolean
+
+ snps,lfps_filter_quirk:
+ description: When set core will filter LFPS reception.
+ type: boolean
+
+ snps,rx_detect_poll_quirk:
+ description:
+ when set core will disable a 400us delay to start Polling LFPS after
+ RX.Detect.
+ type: boolean
+
+ snps,tx_de_emphasis_quirk:
+ description: When set core will set Tx de-emphasis value
+ type: boolean
+
+ snps,tx_de_emphasis:
+ description:
+ The value driven to the PHY is controlled by the LTSSM during USB3
+ Compliance mode.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ enum:
+ - 0 # -6dB de-emphasis
+ - 1 # -3.5dB de-emphasis
+ - 2 # No de-emphasis
+
+ snps,dis_u3_susphy_quirk:
+ description: When set core will disable USB3 suspend phy
+ type: boolean
+
+ snps,dis_u2_susphy_quirk:
+ description: When set core will disable USB2 suspend phy
+ type: boolean
+
+ snps,dis_enblslpm_quirk:
+ description:
+ When set clears the enblslpm in GUSB2PHYCFG, disabling the suspend signal
+ to the PHY.
+ type: boolean
+
+ snps,dis-u1-entry-quirk:
+ description: Set if link entering into U1 needs to be disabled
+ type: boolean
+
+ snps,dis-u2-entry-quirk:
+ description: Set if link entering into U2 needs to be disabled
+ type: boolean
+
+ snps,dis_rxdet_inp3_quirk:
+ description:
+ When set core will disable receiver detection in PHY P3 power state.
+ type: boolean
+
+ snps,dis-u2-freeclk-exists-quirk:
+ description:
+ When set, clear the u2_freeclk_exists in GUSB2PHYCFG, specify that USB2
+ PHY doesn't provide a free-running PHY clock.
+ type: boolean
+
+ snps,dis-del-phy-power-chg-quirk:
+ description:
+ When set core will change PHY power from P0 to P1/P2/P3 without delay.
+ type: boolean
+
+ snps,dis-tx-ipgap-linecheck-quirk:
+ description: When set, disable u2mac linestate check during HS transmit
+ type: boolean
+
+ snps,parkmode-disable-ss-quirk:
+ description:
+ When set, all SuperSpeed bus instances in park mode are disabled.
+ type: boolean
+
+ snps,parkmode-disable-hs-quirk:
+ description:
+ When set, all HighSpeed bus instances in park mode are disabled.
+ type: boolean
+
+ snps,dis_metastability_quirk:
+ description:
+ When set, disable metastability workaround. CAUTION! Use only if you are
+ absolutely sure of it.
+ type: boolean
+
+ snps,dis-split-quirk:
+ description:
+ When set, change the way URBs are handled by the driver. Needed to
+ avoid -EPROTO errors with usbhid on some devices (Hikey 970).
+ type: boolean
+
+ snps,gfladj-refclk-lpm-sel-quirk:
+ description:
+ When set, run the SOF/ITP counter based on ref_clk.
+ type: boolean
+
+ snps,resume-hs-terminations:
+ description:
+ Fix the issue of HS terminations CRC error on resume by enabling this
+ quirk. When set, all the termsel, xcvrsel, opmode becomes 0 during end
+ of resume. This option is to support certain legacy ULPI PHYs.
+ type: boolean
+
+ snps,ulpi-ext-vbus-drv:
+ description:
+ Some ULPI USB PHY does not support internal VBUS supply, and driving
+ the CPEN pin, requires the configuration of the ulpi DRVVBUSEXTERNAL
+ bit. When set, the xhci host will configure the USB2 PHY drives VBUS
+ with an external supply.
+ type: boolean
+
+ snps,is-utmi-l1-suspend:
+ description:
+ True when DWC3 asserts output signal utmi_l1_suspend_n, false when
+ asserts utmi_sleep_n.
+ type: boolean
+
+ snps,hird-threshold:
+ description: HIRD threshold
+ $ref: /schemas/types.yaml#/definitions/uint8
+
+ snps,hsphy_interface:
+ description:
+ High-Speed PHY interface selection between UTMI+ and ULPI when the
+ DWC_USB3_HSPHY_INTERFACE has value 3.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [utmi, ulpi]
+
+ snps,quirk-frame-length-adjustment:
+ description:
+ Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame
+ length adjustment when the fladj_30mhz_sdbnd signal is invalid or
+ incorrect.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 0x3f
+
+ snps,ref-clock-period-ns:
+ description:
+ Value for REFCLKPER field of GUCTL register for reference clock period in
+ nanoseconds, when the hardware set default does not match the actual
+ clock.
+
+ This binding is deprecated. Instead, provide an appropriate reference clock.
+ minimum: 8
+ maximum: 62
+ deprecated: true
+
+ snps,rx-thr-num-pkt:
+ description:
+ USB RX packet threshold count. In host mode, this field specifies
+ the space that must be available in the RX FIFO before the core can
+ start the corresponding USB RX transaction (burst).
+ In device mode, this field specifies the space that must be
+ available in the RX FIFO before the core can send ERDY for a
+ flow-controlled endpoint. It is only used for SuperSpeed.
+ The valid values for this field are from 1 to 15. (DWC3 SuperSpeed
+ USB 3.0 Controller Databook)
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 15
+
+ snps,rx-max-burst:
+ description:
+ Max USB RX burst size. In host mode, this field specifies the
+ Maximum Bulk IN burst the DWC_usb3 core can perform. When the system
+ bus is slower than the USB, RX FIFO can overrun during a long burst.
+ You can program a smaller value to this field to limit the RX burst
+ size that the core can perform. It only applies to SS Bulk,
+ Isochronous, and Interrupt IN endpoints in the host mode.
+ In device mode, this field specifies the NUMP value that is sent in
+ ERDY for an OUT endpoint.
+ The valid values for this field are from 1 to 16. (DWC3 SuperSpeed
+ USB 3.0 Controller Databook)
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 16
+
+ snps,tx-thr-num-pkt:
+ description:
+ USB TX packet threshold count. This field specifies the number of
+ packets that must be in the TXFIFO before the core can start
+ transmission for the corresponding USB transaction (burst).
+ This count is valid in both host and device modes. It is only used
+ for SuperSpeed operation.
+ Valid values are from 1 to 15. (DWC3 SuperSpeed USB 3.0 Controller
+ Databook)
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 15
+
+ snps,tx-max-burst:
+ description:
+ Max USB TX burst size. When the system bus is slower than the USB,
+ TX FIFO can underrun during a long burst. Program a smaller value
+ to this field to limit the TX burst size that the core can execute.
+ In Host mode, it only applies to SS Bulk, Isochronous, and Interrupt
+ OUT endpoints. This value is not used in device mode.
+ Valid values are from 1 to 16. (DWC3 SuperSpeed USB 3.0 Controller
+ Databook)
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 16
+
+ snps,rx-thr-num-pkt-prd:
+ description:
+ Periodic ESS RX packet threshold count (host mode only). Set this and
+ snps,rx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31
+ programming guide section 1.2.4) to enable periodic ESS RX threshold.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 16
+
+ snps,rx-max-burst-prd:
+ description:
+ Max periodic ESS RX burst size (host mode only). Set this and
+ snps,rx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31
+ programming guide section 1.2.4) to enable periodic ESS RX threshold.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 16
+
+ snps,tx-thr-num-pkt-prd:
+ description:
+ Periodic ESS TX packet threshold count (host mode only). Set this and
+ snps,tx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31
+ programming guide section 1.2.3) to enable periodic ESS TX threshold.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 16
+
+ snps,tx-max-burst-prd:
+ description:
+ Max periodic ESS TX burst size (host mode only). Set this and
+ snps,tx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31
+ programming guide section 1.2.3) to enable periodic ESS TX threshold.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 1
+ maximum: 16
+
+ tx-fifo-resize:
+ description: Determines if the TX fifos can be dynamically resized depending
+ on the number of IN endpoints used and if bursting is supported. This
+ may help improve bandwidth on platforms with higher system latencies, as
+ increased fifo space allows for the controller to prefetch data into its
+ internal memory.
+ type: boolean
+
+ tx-fifo-max-num:
+ description: Specifies the max number of packets the txfifo resizing logic
+ can account for when higher endpoint bursting is used. (bMaxBurst > 6) The
+ higher the number, the more fifo space the txfifo resizing logic will
+ allocate for that endpoint.
+ $ref: /schemas/types.yaml#/definitions/uint8
+ minimum: 3
+
+ snps,incr-burst-type-adjustment:
+ description:
+ Value for INCR burst type of GSBUSCFG0 register, undefined length INCR
+ burst type enable and INCRx type. A single value means INCRX burst mode
+ enabled. If more than one value specified, undefined length INCR burst
+ type will be enabled with burst lengths utilized up to the maximum
+ of the values passed in this property.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ uniqueItems: true
+ items:
+ enum: [1, 4, 8, 16, 32, 64, 128, 256]
+
+ num-hc-interrupters:
+ maximum: 8
+ default: 1
+
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+ description: Connector for dual role switch
+ type: object
+ unevaluatedProperties: false
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ This port is used with the 'usb-role-switch' property to connect the
+ dwc3 to type C connector.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Those ports should be used with any connector to the data bus of this
+ controller using the OF graph bindings specified if the "usb-role-switch"
+ property is used.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: High Speed (HS) data bus.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Super Speed (SS) data bus.
+
+ wakeup-source:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Enable USB remote wakeup.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: true
+...
+
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 1779d08ba1c0..4380bb6fa2f0 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -15,18 +15,7 @@ description:
compatible string.
allOf:
- - $ref: usb-drd.yaml#
- - if:
- properties:
- dr_mode:
- const: peripheral
-
- required:
- - dr_mode
- then:
- $ref: usb.yaml#
- else:
- $ref: usb-xhci.yaml#
+ - $ref: snps,dwc3-common.yaml#
properties:
compatible:
@@ -44,15 +33,15 @@ properties:
It's either a single common DWC3 interrupt (dwc_usb3) or individual
interrupts for the host, gadget and DRD modes.
minItems: 1
- maxItems: 3
+ maxItems: 4
interrupt-names:
minItems: 1
- maxItems: 3
+ maxItems: 4
oneOf:
- const: dwc_usb3
- items:
- enum: [host, peripheral, otg]
+ enum: [host, peripheral, otg, wakeup]
clocks:
description:
@@ -73,281 +62,19 @@ properties:
iommus:
maxItems: 1
- usb-phy:
- minItems: 1
- items:
- - description: USB2/HS PHY
- - description: USB3/SS PHY
-
- phys:
- minItems: 1
- maxItems: 2
-
- phy-names:
+ power-domains:
+ description:
+ The DWC3 has 2 power-domains. The power management unit (PMU) and
+ everything else. The PMU is typically always powered and may not have an
+ entry.
minItems: 1
- maxItems: 2
items:
- enum:
- - usb2-phy
- - usb3-phy
+ - description: Core
+ - description: Power management unit
resets:
minItems: 1
- snps,usb2-lpm-disable:
- description: Indicate if we don't want to enable USB2 HW LPM for host
- mode.
- type: boolean
-
- snps,usb3_lpm_capable:
- description: Determines if platform is USB3 LPM capable
- type: boolean
-
- snps,usb2-gadget-lpm-disable:
- description: Indicate if we don't want to enable USB2 HW LPM for gadget
- mode.
- type: boolean
-
- snps,dis-start-transfer-quirk:
- description:
- When set, disable isoc START TRANSFER command failure SW work-around
- for DWC_usb31 version 1.70a-ea06 and prior.
- type: boolean
-
- snps,disable_scramble_quirk:
- description:
- True when SW should disable data scrambling. Only really useful for FPGA
- builds.
- type: boolean
-
- snps,has-lpm-erratum:
- description: True when DWC3 was configured with LPM Erratum enabled
- type: boolean
-
- snps,lpm-nyet-threshold:
- description: LPM NYET threshold
- $ref: /schemas/types.yaml#/definitions/uint8
-
- snps,u2exit_lfps_quirk:
- description: Set if we want to enable u2exit lfps quirk
- type: boolean
-
- snps,u2ss_inp3_quirk:
- description: Set if we enable P3 OK for U2/SS Inactive quirk
- type: boolean
-
- snps,req_p1p2p3_quirk:
- description:
- When set, the core will always request for P1/P2/P3 transition sequence.
- type: boolean
-
- snps,del_p1p2p3_quirk:
- description:
- When set core will delay P1/P2/P3 until a certain amount of 8B10B errors
- occur.
- type: boolean
-
- snps,del_phy_power_chg_quirk:
- description: When set core will delay PHY power change from P0 to P1/P2/P3.
- type: boolean
-
- snps,lfps_filter_quirk:
- description: When set core will filter LFPS reception.
- type: boolean
-
- snps,rx_detect_poll_quirk:
- description:
- when set core will disable a 400us delay to start Polling LFPS after
- RX.Detect.
- type: boolean
-
- snps,tx_de_emphasis_quirk:
- description: When set core will set Tx de-emphasis value
- type: boolean
-
- snps,tx_de_emphasis:
- description:
- The value driven to the PHY is controlled by the LTSSM during USB3
- Compliance mode.
- $ref: /schemas/types.yaml#/definitions/uint8
- enum:
- - 0 # -6dB de-emphasis
- - 1 # -3.5dB de-emphasis
- - 2 # No de-emphasis
-
- snps,dis_u3_susphy_quirk:
- description: When set core will disable USB3 suspend phy
- type: boolean
-
- snps,dis_u2_susphy_quirk:
- description: When set core will disable USB2 suspend phy
- type: boolean
-
- snps,dis_enblslpm_quirk:
- description:
- When set clears the enblslpm in GUSB2PHYCFG, disabling the suspend signal
- to the PHY.
- type: boolean
-
- snps,dis-u1-entry-quirk:
- description: Set if link entering into U1 needs to be disabled
- type: boolean
-
- snps,dis-u2-entry-quirk:
- description: Set if link entering into U2 needs to be disabled
- type: boolean
-
- snps,dis_rxdet_inp3_quirk:
- description:
- When set core will disable receiver detection in PHY P3 power state.
- type: boolean
-
- snps,dis-u2-freeclk-exists-quirk:
- description:
- When set, clear the u2_freeclk_exists in GUSB2PHYCFG, specify that USB2
- PHY doesn't provide a free-running PHY clock.
- type: boolean
-
- snps,dis-del-phy-power-chg-quirk:
- description:
- When set core will change PHY power from P0 to P1/P2/P3 without delay.
- type: boolean
-
- snps,dis-tx-ipgap-linecheck-quirk:
- description: When set, disable u2mac linestate check during HS transmit
- type: boolean
-
- snps,parkmode-disable-ss-quirk:
- description:
- When set, all SuperSpeed bus instances in park mode are disabled.
- type: boolean
-
- snps,dis_metastability_quirk:
- description:
- When set, disable metastability workaround. CAUTION! Use only if you are
- absolutely sure of it.
- type: boolean
-
- snps,dis-split-quirk:
- description:
- When set, change the way URBs are handled by the driver. Needed to
- avoid -EPROTO errors with usbhid on some devices (Hikey 970).
- type: boolean
-
- snps,is-utmi-l1-suspend:
- description:
- True when DWC3 asserts output signal utmi_l1_suspend_n, false when
- asserts utmi_sleep_n.
- type: boolean
-
- snps,hird-threshold:
- description: HIRD threshold
- $ref: /schemas/types.yaml#/definitions/uint8
-
- snps,hsphy_interface:
- description:
- High-Speed PHY interface selection between UTMI+ and ULPI when the
- DWC_USB3_HSPHY_INTERFACE has value 3.
- $ref: /schemas/types.yaml#/definitions/uint8
- enum: [utmi, ulpi]
-
- snps,quirk-frame-length-adjustment:
- description:
- Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame
- length adjustment when the fladj_30mhz_sdbnd signal is invalid or
- incorrect.
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
- maximum: 0x3f
-
- snps,ref-clock-period-ns:
- description:
- Value for REFCLKPER field of GUCTL register for reference clock period in
- nanoseconds, when the hardware set default does not match the actual
- clock.
-
- This binding is deprecated. Instead, provide an appropriate reference clock.
- minimum: 8
- maximum: 62
- deprecated: true
-
- snps,rx-thr-num-pkt-prd:
- description:
- Periodic ESS RX packet threshold count (host mode only). Set this and
- snps,rx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31
- programming guide section 1.2.4) to enable periodic ESS RX threshold.
- $ref: /schemas/types.yaml#/definitions/uint8
- minimum: 1
- maximum: 16
-
- snps,rx-max-burst-prd:
- description:
- Max periodic ESS RX burst size (host mode only). Set this and
- snps,rx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31
- programming guide section 1.2.4) to enable periodic ESS RX threshold.
- $ref: /schemas/types.yaml#/definitions/uint8
- minimum: 1
- maximum: 16
-
- snps,tx-thr-num-pkt-prd:
- description:
- Periodic ESS TX packet threshold count (host mode only). Set this and
- snps,tx-max-burst-prd to a valid, non-zero value 1-16 (DWC_usb31
- programming guide section 1.2.3) to enable periodic ESS TX threshold.
- $ref: /schemas/types.yaml#/definitions/uint8
- minimum: 1
- maximum: 16
-
- snps,tx-max-burst-prd:
- description:
- Max periodic ESS TX burst size (host mode only). Set this and
- snps,tx-thr-num-pkt-prd to a valid, non-zero value 1-16 (DWC_usb31
- programming guide section 1.2.3) to enable periodic ESS TX threshold.
- $ref: /schemas/types.yaml#/definitions/uint8
- minimum: 1
- maximum: 16
-
- tx-fifo-resize:
- description: Determines if the TX fifos can be dynamically resized depending
- on the number of IN endpoints used and if bursting is supported. This
- may help improve bandwidth on platforms with higher system latencies, as
- increased fifo space allows for the controller to prefetch data into its
- internal memory.
- type: boolean
-
- tx-fifo-max-num:
- description: Specifies the max number of packets the txfifo resizing logic
- can account for when higher endpoint bursting is used. (bMaxBurst > 6) The
- higher the number, the more fifo space the txfifo resizing logic will
- allocate for that endpoint.
- $ref: /schemas/types.yaml#/definitions/uint8
- minimum: 3
-
- snps,incr-burst-type-adjustment:
- description:
- Value for INCR burst type of GSBUSCFG0 register, undefined length INCR
- burst type enable and INCRx type. A single value means INCRX burst mode
- enabled. If more than one value specified, undefined length INCR burst
- type will be enabled with burst lengths utilized up to the maximum
- of the values passed in this property.
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
- maxItems: 8
- uniqueItems: true
- items:
- enum: [1, 4, 8, 16, 32, 64, 128, 256]
-
- port:
- $ref: /schemas/graph.yaml#/properties/port
- description:
- This port is used with the 'usb-role-switch' property to connect the
- dwc3 to type C connector.
-
- wakeup-source:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- Enable USB remote wakeup.
-
unevaluatedProperties: false
required:
diff --git a/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml b/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml
new file mode 100644
index 000000000000..0f0b5e061ca1
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/spacemit,k1-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 SuperSpeed DWC3 USB SoC Controller
+
+maintainers:
+ - Ze Huang <huang.ze@linux.dev>
+
+description: |
+ The SpacemiT K1 embeds a DWC3 USB IP Core which supports Host functions
+ for USB 3.0 and DRD for USB 2.0.
+
+ Key features:
+ - USB3.0 SuperSpeed and USB2.0 High/Full/Low-Speed support
+ - Supports low-power modes (USB2.0 suspend, USB3.0 U1/U2/U3)
+ - Internal DMA controller and flexible endpoint FIFO sizing
+
+ Communication Interface:
+ - Use of PIPE3 (125MHz) interface for USB3.0 PHY
+ - Use of UTMI+ (30/60MHz) interface for USB2.0 PHY
+
+allOf:
+ - $ref: snps,dwc3-common.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-dwc3
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: usbdrd30
+
+ interrupts:
+ maxItems: 1
+
+ phys:
+ items:
+ - description: phandle to USB2/HS PHY
+ - description: phandle to USB3/SS PHY
+
+ phy-names:
+ items:
+ - const: usb2-phy
+ - const: usb3-phy
+
+ resets:
+ items:
+ - description: USB3.0 AHB reset
+ - description: USB3.0 VCC reset
+ - description: USB3.0 PHY reset
+
+ reset-names:
+ items:
+ - const: ahb
+ - const: vcc
+ - const: phy
+
+ reset-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 2
+ description: delay after reset sequence [us]
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS voltage.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - phys
+ - phy-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ usb@c0a00000 {
+ compatible = "spacemit,k1-dwc3";
+ reg = <0xc0a00000 0x10000>;
+ clocks = <&syscon_apmu 16>;
+ clock-names = "usbdrd30";
+ interrupts = <125>;
+ phys = <&usb2phy>, <&usb3phy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ resets = <&syscon_apmu 8>,
+ <&syscon_apmu 9>,
+ <&syscon_apmu 10>;
+ reset-names = "ahb", "vcc", "phy";
+ reset-delay = <2>;
+ vbus-supply = <&usb3_vbus>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub_2_0: hub@1 {
+ compatible = "usb2109,2817";
+ reg = <1>;
+ vdd-supply = <&usb3_vhub>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio 3 28 1>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb2109,817";
+ reg = <2>;
+ vdd-supply = <&usb3_vhub>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio 3 28 1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/spear-usb.txt b/Documentation/devicetree/bindings/usb/spear-usb.txt
deleted file mode 100644
index 1dc91cc459c0..000000000000
--- a/Documentation/devicetree/bindings/usb/spear-usb.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-ST SPEAr SoC USB controllers:
------------------------------
-
-EHCI:
------
-
-Required properties:
-- compatible: "st,spear600-ehci"
-- interrupts: Should contain the EHCI interrupt
-
-Example:
-
- ehci@e1800000 {
- compatible = "st,spear600-ehci", "usb-ehci";
- reg = <0xe1800000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <27>;
- };
-
-
-OHCI:
------
-
-Required properties:
-- compatible: "st,spear600-ohci"
-- interrupts: Should contain the OHCI interrupt
-
-Example:
-
- ohci@e1900000 {
- compatible = "st,spear600-ohci", "usb-ohci";
- reg = <0xe1800000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <26>;
- };
diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml
index b5a8c9814dd3..acda2f47fbc9 100644
--- a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml
+++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/st,stusb160x.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/st,stusb160x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STUSB160x Type-C controller bindings
+title: STMicroelectronics STUSB160x Type-C controller
maintainers:
- Amelie Delaunay <amelie.delaunay@foss.st.com>
@@ -33,6 +33,7 @@ properties:
connector:
type: object
$ref: /schemas/connector/usb-connector.yaml#
+ unevaluatedProperties: false
properties:
compatible:
@@ -55,7 +56,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
- i2c4 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -74,9 +75,14 @@ examples:
data-role = "dual";
typec-power-opmode = "default";
- port {
- typec_con_ep: endpoint {
- remote-endpoint = <&usbotg_hs_ep>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ typec_con_ep: endpoint {
+ remote-endpoint = <&usbotg_hs_ep>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml b/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
new file mode 100644
index 000000000000..24aa9c10d6ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/starfive,jh7110-usb.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/starfive,jh7110-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JH7110 wrapper module for the Cadence USBSS-DRD controller
+
+maintainers:
+ - Minda Chen <minda.chen@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jh7110-usb
+
+ ranges: true
+
+ starfive,stg-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to System Register Controller stg_syscon node.
+ - description: dr mode register offset of STG_SYSCONSAIF__SYSCFG register for USB.
+ description:
+ The phandle to System Register Controller syscon node and the offset
+ of STG_SYSCONSAIF__SYSCFG register for USB.
+
+ dr_mode:
+ enum: [host, otg, peripheral]
+
+ "#address-cells":
+ enum: [1, 2]
+
+ "#size-cells":
+ enum: [1, 2]
+
+ clocks:
+ items:
+ - description: link power management clock
+ - description: standby clock
+ - description: APB clock
+ - description: AXI clock
+ - description: UTMI APB clock
+
+ clock-names:
+ items:
+ - const: lpm
+ - const: stb
+ - const: apb
+ - const: axi
+ - const: utmi_apb
+
+ resets:
+ items:
+ - description: Power up reset
+ - description: APB clock reset
+ - description: AXI clock reset
+ - description: UTMI APB clock reset
+
+ reset-names:
+ items:
+ - const: pwrup
+ - const: apb
+ - const: axi
+ - const: utmi_apb
+
+patternProperties:
+ "^usb@[0-9a-f]+$":
+ $ref: cdns,usb3.yaml#
+ description: Required child node
+
+required:
+ - compatible
+ - ranges
+ - starfive,stg-syscon
+ - '#address-cells'
+ - '#size-cells'
+ - dr_mode
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ usb@10100000 {
+ compatible = "starfive,jh7110-usb";
+ ranges = <0x0 0x10100000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ starfive,stg-syscon = <&stg_syscon 0x4>;
+ clocks = <&syscrg 4>,
+ <&stgcrg 5>,
+ <&stgcrg 1>,
+ <&stgcrg 3>,
+ <&stgcrg 2>;
+ clock-names = "lpm", "stb", "apb", "axi", "utmi_apb";
+ resets = <&stgcrg 10>,
+ <&stgcrg 8>,
+ <&stgcrg 7>,
+ <&stgcrg 9>;
+ reset-names = "pwrup", "apb", "axi", "utmi_apb";
+ dr_mode = "host";
+
+ usb@0 {
+ compatible = "cdns,usb3";
+ reg = <0x0 0x10000>,
+ <0x10000 0x10000>,
+ <0x20000 0x10000>;
+ reg-names = "otg", "xhci", "dev";
+ interrupts = <100>, <108>, <110>;
+ interrupt-names = "host", "peripheral", "otg";
+ maximum-speed = "super-speed";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml
index d25fc708e32c..f6e6d084d1c5 100644
--- a/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,am62-usb.yaml
@@ -14,7 +14,10 @@ properties:
const: ti,am62-usb
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: USB CFG register space
+ - description: USB PHY2 register space
ranges: true
@@ -82,7 +85,8 @@ examples:
usbss1: usb@f910000 {
compatible = "ti,am62-usb";
- reg = <0x00 0x0f910000 0x00 0x800>;
+ reg = <0x00 0x0f910000 0x00 0x800>,
+ <0x00 0x0f918000 0x00 0x400>;
clocks = <&k3_clks 162 3>;
clock-names = "ref";
ti,syscon-phy-pll-refclk = <&wkup_conf 0x4018>;
@@ -92,7 +96,7 @@ examples:
usb@31100000 {
compatible = "snps,dwc3";
- reg =<0x00 0x31100000 0x00 0x50000>;
+ reg = <0x00 0x31100000 0x00 0x50000>;
interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>, /* irq.0 */
<GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>; /* irq.0 */
interrupt-names = "host", "peripheral";
diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
index b86bf6bc9cd6..06099e93c6c3 100644
--- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml
@@ -25,6 +25,14 @@ properties:
interrupts:
maxItems: 1
+ id-gpios:
+ description:
+ An input gpio for USB ID pin. Upon detecting a UFP device, HD3SS3220
+ will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V,
+ the HD3SS3220 will assert ID pin low. This is done to enforce Type-C
+ requirement that VBUS must be at VSafe0V before re-enabling VBUS.
+ maxItems: 1
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: OF graph bindings (specified in bindings/graph.txt) that model
@@ -46,37 +54,36 @@ properties:
required:
- compatible
- reg
- - interrupts
additionalProperties: false
examples:
- |
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
hd3ss3220@47 {
- compatible = "ti,hd3ss3220";
- reg = <0x47>;
- interrupt-parent = <&gpio6>;
- interrupts = <3>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- hd3ss3220_in_ep: endpoint {
- remote-endpoint = <&ss_ep>;
- };
- };
- port@1 {
- reg = <1>;
- hd3ss3220_out_ep: endpoint {
- remote-endpoint = <&usb3_role_switch>;
- };
- };
+ compatible = "ti,hd3ss3220";
+ reg = <0x47>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ hd3ss3220_in_ep: endpoint {
+ remote-endpoint = <&ss_ep>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ hd3ss3220_out_ep: endpoint {
+ remote-endpoint = <&usb3_role_switch>;
+ };
};
+ };
};
};
diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
index eedde385d299..653a89586f4e 100644
--- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/ti,j721e-usb.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/ti,j721e-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bindings for the TI wrapper module for the Cadence USBSS-DRD controller
+title: TI wrapper module for the Cadence USBSS-DRD controller
maintainers:
- Roger Quadros <rogerq@kernel.org>
@@ -13,10 +13,9 @@ properties:
compatible:
oneOf:
- const: ti,j721e-usb
- - const: ti,am64-usb
- items:
- - const: ti,j721e-usb
- const: ti,am64-usb
+ - const: ti,j721e-usb
reg:
maxItems: 1
@@ -53,12 +52,6 @@ properties:
VBUS pin of the SoC via a 1/3 voltage divider.
type: boolean
- assigned-clocks:
- maxItems: 1
-
- assigned-clock-parents:
- maxItems: 1
-
'#address-cells':
const: 2
diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
index c1f0194ad0d5..9252d893f694 100644
--- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml
@@ -34,14 +34,6 @@ properties:
minItems: 1
maxItems: 2
- assigned-clocks:
- minItems: 1
- maxItems: 2
-
- assigned-clock-parents:
- minItems: 1
- maxItems: 2
-
power-domains:
maxItems: 1
description: Should contain a phandle to a PM domain provider node
diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
index a4c53b1f1af3..1745e28b3110 100644
--- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/usb/ti,tps6598x.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/usb/ti,tps6598x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments 6598x Type-C Port Switch and Power Delivery controller DT bindings
+title: Texas Instruments 6598x Type-C Port Switch and Power Delivery controller
maintainers:
- Bryan O'Donoghue <bryan.odonoghue@linaro.org>
@@ -20,9 +20,30 @@ properties:
enum:
- ti,tps6598x
- apple,cd321x
+ - ti,tps25750
+
reg:
+ minItems: 1
+ items:
+ - description: main PD controller address
+ - description: |
+ I2C slave address field in PBMs input data
+ which is used as the device address when writing the
+ patch for TPS25750.
+ The patch address can be any value except 0x00, 0x20,
+ 0x21, 0x22, and 0x23
+
+ reg-names:
+ items:
+ - const: main
+ - const: patch-address
+
+ reset-gpios:
+ description: GPIO used for the HRESET pin.
maxItems: 1
+ wakeup-source: true
+
interrupts:
maxItems: 1
@@ -30,24 +51,59 @@ properties:
items:
- const: irq
+ connector:
+ $ref: /schemas/connector/usb-connector.yaml#
+
+ firmware-name:
+ description: |
+ Should contain the name of the default patch binary
+ file located on the firmware search path which is
+ used to switch the controller into APP mode.
+ This is used when tps25750 doesn't have an EEPROM
+ connected to it.
+ maxItems: 1
+
required:
- compatible
- reg
- - interrupts
- - interrupt-names
-additionalProperties: true
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,tps25750
+ then:
+ properties:
+ reg:
+ maxItems: 2
+
+ connector:
+ required:
+ - data-role
+
+ required:
+ - connector
+ - reg-names
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+additionalProperties: false
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
- i2c0 {
+ i2c {
#address-cells = <1>;
#size-cells = <0>;
tps6598x: tps6598x@38 {
compatible = "ti,tps6598x";
reg = <0x38>;
+ wakeup-source;
interrupt-parent = <&msmgpio>;
interrupts = <107 IRQ_TYPE_LEVEL_LOW>;
@@ -55,6 +111,7 @@ examples:
pinctrl-names = "default";
pinctrl-0 = <&typec_pins>;
+ reset-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
typec_con: connector {
compatible = "usb-c-connector";
@@ -67,4 +124,36 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec@21 {
+ compatible = "ti,tps25750";
+ reg = <0x21>, <0x0f>;
+ reg-names = "main", "patch-address";
+
+ interrupt-parent = <&msmgpio>;
+ interrupts = <100 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "irq";
+ firmware-name = "tps25750.bin";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&typec_pins>;
+
+ typec_con0: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ port {
+ typec_ep0: endpoint {
+ remote-endpoint = <&otg_ep>;
+ };
+ };
+ };
+ };
+ };
...
diff --git a/Documentation/devicetree/bindings/usb/ti,tusb1046.yaml b/Documentation/devicetree/bindings/usb/ti,tusb1046.yaml
new file mode 100644
index 000000000000..e1501ea6b50b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ti,tusb1046.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ti,tusb1046.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TUSB1046-DCI Type-C crosspoint switch
+
+maintainers:
+ - Romain Gantois <romain.gantois@bootlin.com>
+
+allOf:
+ - $ref: usb-switch.yaml#
+ - $ref: usb-switch-ports.yaml#
+
+properties:
+ compatible:
+ const: ti,tusb1046
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ typec-mux@44 {
+ compatible = "ti,tusb1046";
+ reg = <0x44>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ endpoint {
+ remote-endpoint = <&typec_controller>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml b/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml
new file mode 100644
index 000000000000..c4a91b3d6612
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ti,tusb73x0-pci.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ti,tusb73x0-pci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TUSB73x0 USB 3.0 xHCI Host Controller (PCIe)
+
+maintainers:
+ - Francesco Dolcini <francesco.dolcini@toradex.com>
+
+description:
+ TUSB73x0 USB 3.0 xHCI Host Controller via PCIe x1 Gen2 interface.
+ The TUSB7320 supports up to two downstream ports, the TUSB7340 supports up
+ to four downstream ports, both variants share the same PCI device ID.
+
+properties:
+ compatible:
+ const: pci104c,8241
+
+ reg:
+ maxItems: 1
+
+ ti,pwron-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Configure the polarity of the PWRONx# signals. When this is present, the
+ PWRONx# pins are active high and their internal pull-down resistors are
+ disabled. When this is absent, the PWRONx# pins are active low (default)
+ and their internal pull-down resistors are enabled.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: usb-xhci.yaml
+
+additionalProperties: false
+
+examples:
+ - |
+ pcie@0 {
+ reg = <0x0 0x1000>;
+ ranges = <0x02000000 0x0 0x100000 0x10000000 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+
+ usb@0 {
+ compatible = "pci104c,8241";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ ti,pwron-active-high;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ti,twl4030-usb.yaml b/Documentation/devicetree/bindings/usb/ti,twl4030-usb.yaml
new file mode 100644
index 000000000000..6ef337507425
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ti,twl4030-usb.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ti,twl4030-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL4030 USB PHY and Comparator
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description:
+ Bindings for the USB PHY and comparator module found within the
+ TWL4030 family of companion chips. If a sibling node is compatible with
+ "ti,twl4030-bci", the driver for that node will query this device for
+ USB power status.
+
+properties:
+ compatible:
+ const: ti,twl4030-usb
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: OTG interrupt number for ID events.
+ - description: USB interrupt number for VBUS events.
+
+ usb1v5-supply:
+ description: Phandle to the vusb1v5 regulator.
+
+ usb1v8-supply:
+ description: Phandle to the vusb1v8 regulator.
+
+ usb3v1-supply:
+ description: Phandle to the vusb3v1 regulator.
+
+ usb_mode:
+ description: |
+ The mode used by the PHY to connect to the controller:
+ 1: ULPI mode
+ 2: CEA2011_3PIN mode
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - interrupts
+ - usb1v5-supply
+ - usb1v8-supply
+ - usb3v1-supply
+ - usb_mode
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ usb-phy {
+ compatible = "ti,twl4030-usb";
+
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+
+ usb1v5-supply = <&reg_vusb1v5>;
+ usb1v8-supply = <&reg_vusb1v8>;
+ usb3v1-supply = <&reg_vusb3v1>;
+ usb_mode = <1>;
+
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/ti,twl6030-usb.yaml b/Documentation/devicetree/bindings/usb/ti,twl6030-usb.yaml
new file mode 100644
index 000000000000..33b6da50660a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ti,twl6030-usb.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ti,twl6030-usb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TWL6030 USB Comparator
+
+maintainers:
+ - Peter Ujfalusi <peter.ujfalusi@gmail.com>
+
+description:
+ Bindings for the USB comparator module found within the TWL6030
+ family of companion chips.
+
+properties:
+ compatible:
+ const: ti,twl6030-usb
+
+ interrupts:
+ items:
+ - description: OTG for ID events in host mode
+ - description: USB device mode for VBUS events
+
+ usb-supply:
+ description:
+ Phandle to the VUSB regulator. For TWL6030, this should be the 'vusb'
+ regulator. For TWL6032 subclass, it should be the 'ldousb' regulator.
+
+required:
+ - compatible
+ - interrupts
+ - usb-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ usb {
+ compatible = "ti,twl6030-usb";
+
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>, <10 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+
+ usb-supply = <&reg_vusb>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml b/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml
new file mode 100644
index 000000000000..61217da8b2f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ti,usb8020b.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/ti,usb8020b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI USB8020B USB 3.0 hub controller
+
+maintainers:
+ - Macpaul Lin <macpaul.lin@mediatek.com>
+
+allOf:
+ - $ref: usb-device.yaml#
+
+properties:
+ compatible:
+ enum:
+ - usb451,8025
+ - usb451,8027
+
+ reg: true
+
+ reset-gpios:
+ items:
+ - description: GPIO specifier for GRST# pin.
+
+ vdd-supply:
+ description:
+ VDD power supply to the hub
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+required:
+ - compatible
+ - reg
+ - peer-hub
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb451,8027";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&pio 7 GPIO_ACTIVE_HIGH>;
+ vdd-supply = <&usb_hub_fixed_3v3>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb451,8025";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&pio 7 GPIO_ACTIVE_HIGH>;
+ vdd-supply = <&usb_hub_fixed_3v3>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml
index e04fbd8ab0b7..5e3eae9c2961 100644
--- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml
@@ -1,10 +1,10 @@
-# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Binding for the TI USB8041 USB 3.0 hub controller
+title: TI USB8041 and USB8044 USB 3.0 hub controllers
maintainers:
- Alexander Stein <alexander.stein@ew.tq-group.com>
@@ -17,6 +17,8 @@ properties:
enum:
- usb451,8140
- usb451,8142
+ - usb451,8440
+ - usb451,8442
reg: true
@@ -51,17 +53,17 @@ examples:
/* 2.0 hub on port 1 */
hub_2_0: hub@1 {
- compatible = "usb451,8142";
- reg = <1>;
- peer-hub = <&hub_3_0>;
- reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
};
/* 3.0 hub on port 2 */
hub_3_0: hub@2 {
- compatible = "usb451,8140";
- reg = <2>;
- peer-hub = <&hub_2_0>;
- reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
deleted file mode 100644
index 17327a296110..000000000000
--- a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-USB COMPARATOR OF TWL CHIPS
-
-TWL6030 USB COMPARATOR
- - compatible : Should be "ti,twl6030-usb"
- - interrupts : Two interrupt numbers to the cpu should be specified. First
- interrupt number is the otg interrupt number that raises ID interrupts when
- the controller has to act as host and the second interrupt number is the
- usb interrupt number that raises VBUS interrupts when the controller has to
- act as device
- - usb-supply : phandle to the regulator device tree node. It should be vusb
- if it is twl6030 or ldousb if it is twl6032 subclass.
-
-twl6030-usb {
- compatible = "ti,twl6030-usb";
- interrupts = < 4 10 >;
-};
-
-Board specific device node entry
-&twl6030-usb {
- usb-supply = <&vusb>;
-};
-
-TWL4030 USB PHY AND COMPARATOR
- - compatible : Should be "ti,twl4030-usb"
- - interrupts : The interrupt numbers to the cpu should be specified. First
- interrupt number is the otg interrupt number that raises ID interrupts
- and VBUS interrupts. The second interrupt number is optional.
- - <supply-name>-supply : phandle to the regulator device tree node.
- <supply-name> should be vusb1v5, vusb1v8 and vusb3v1
- - usb_mode : The mode used by the phy to connect to the controller. "1"
- specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode.
-
-If a sibling node is compatible "ti,twl4030-bci", then it will find
-this device and query it for USB power status.
-
-twl4030-usb {
- compatible = "ti,twl4030-usb";
- interrupts = < 10 4 >;
- usb1v5-supply = <&vusb1v5>;
- usb1v8-supply = <&vusb1v8>;
- usb3v1-supply = <&vusb3v1>;
- usb_mode = <1>;
-};
diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
deleted file mode 100644
index 2082522b1c32..000000000000
--- a/Documentation/devicetree/bindings/usb/typec-tcpci.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-TCPCI(Typec port cotroller interface) binding
----------------------------------------------
-
-Required properties:
-- compatible: should be set one of following:
- - "nxp,ptn5110" for NXP USB PD TCPC PHY IC ptn5110.
-
-- reg: the i2c slave address of typec port controller device.
-- interrupt-parent: the phandle to the interrupt controller which provides
- the interrupt.
-- interrupts: interrupt specification for tcpci alert.
-
-Required sub-node:
-- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
- of connector node are specified in
- Documentation/devicetree/bindings/connector/usb-connector.yaml
-
-Example:
-
-ptn5110@50 {
- compatible = "nxp,ptn5110";
- reg = <0x50>;
- interrupt-parent = <&gpio3>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- power-role = "dual";
- try-power-role = "sink";
- source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>;
- sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
- PDO_VAR(5000, 12000, 2000)>;
- op-sink-microwatt = <10000000>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
- usb_con_ss: endpoint {
- remote-endpoint = <&usb3_data_ss>;
- };
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/usb/usb-device.yaml b/Documentation/devicetree/bindings/usb/usb-device.yaml
index b77960a7a37b..09fceb469f10 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-device.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/usb-device.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: The device tree bindings for the Generic USB Device
+title: Generic USB Device
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -28,7 +28,8 @@ description: |
properties:
compatible:
- pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
+ contains:
+ pattern: "^usb[0-9a-f]{1,4},[0-9a-f]{1,4}$"
description: Device nodes or combined nodes.
"usbVID,PID", where VID is the vendor id and PID the product id.
The textual representation of VID and PID shall be in lower case
@@ -39,8 +40,10 @@ properties:
reg:
description: the number of the USB hub port or the USB host-controller
- port to which this device is attached. The range is 1-255.
- maxItems: 1
+ port to which this device is attached.
+ items:
+ - minimum: 1
+ maximum: 255
"#address-cells":
description: should be 1 for hub nodes with device nodes,
@@ -76,7 +79,6 @@ patternProperties:
maxItems: 1
required:
- - compatible
- reg
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/usb/usb-drd.yaml b/Documentation/devicetree/bindings/usb/usb-drd.yaml
index f229fc8068d9..114fb5dc0498 100644
--- a/Documentation/devicetree/bindings/usb/usb-drd.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-drd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/usb-drd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic USB OTG Controller Device Tree Bindings
+title: Generic USB OTG Controller
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -27,6 +27,7 @@ properties:
should default to OTG.
$ref: /schemas/types.yaml#/definitions/string
enum: [host, peripheral, otg]
+ default: otg
hnp-disable:
description:
diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
index 1dc3d5d7b44f..45a19d4928af 100644
--- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/usb-hcd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic USB Host Controller Device Tree Bindings
+title: Generic USB Host Controller
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -41,7 +41,7 @@ examples:
- |
usb {
phys = <&usb2_phy1>, <&usb3_phy1>;
- phy-names = "usb";
+ phy-names = "usb2", "usb3";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/usb/usb-hub.yaml b/Documentation/devicetree/bindings/usb/usb-hub.yaml
new file mode 100644
index 000000000000..5238ab105763
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-hub.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb-hub.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic USB Hub
+
+maintainers:
+ - Pin-yen Lin <treapking@chromium.org>
+
+allOf:
+ - $ref: usb-device.yaml#
+
+properties:
+ '#address-cells':
+ const: 1
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ The downstream facing USB ports
+
+ patternProperties:
+ "^port@[1-9a-f][0-9a-f]*$":
+ $ref: /schemas/graph.yaml#/properties/port
+
+patternProperties:
+ '^.*@[1-9a-f][0-9a-f]*$':
+ description: The hard wired USB devices
+ type: object
+ $ref: /schemas/usb/usb-device.yaml
+ additionalProperties: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: true
+
+examples:
+ - |
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb123,4567";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* USB 2.0 device on port 5 */
+ device@5 {
+ reg = <5>;
+ compatible = "usb765,4321";
+ };
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb123,abcd";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* Type-A connector on port 3 */
+ port@3 {
+ reg = <3>;
+ endpoint {
+ remote-endpoint = <&usb_a0_ss>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml
index 2824c17285ee..9b3ea23654af 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml
@@ -27,6 +27,9 @@ properties:
vcc-supply:
description: phandle to the regulator that provides power to the PHY.
+ power-domains:
+ maxItems: 1
+
reset-gpios:
maxItems: 1
@@ -34,10 +37,16 @@ properties:
description: Should specify the GPIO detecting a VBus insertion
maxItems: 1
- vbus-regulator:
- description: Should specifiy the regulator supplying current drawn from
- the VBus line.
- $ref: /schemas/types.yaml#/definitions/phandle
+ vbus-supply:
+ description: regulator supplying VBUS. It will be enabled and disabled
+ dynamically in OTG mode. If the regulator is controlled by a
+ GPIO line, this should be modeled as a regulator-fixed and
+ referenced by this supply.
+
+ wakeup-source:
+ description:
+ Specify if the USB phy can detect the remote wakeup signal
+ while the system sleep.
required:
- compatible
@@ -57,7 +66,7 @@ examples:
vcc-supply = <&hsusb1_vcc_regulator>;
reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
vbus-detect-gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
- vbus-regulator = <&vbus_regulator>;
+ vbus-supply = <&vbus_regulator>;
#phy-cells = <0>;
};
diff --git a/Documentation/devicetree/bindings/usb/usb-switch-ports.yaml b/Documentation/devicetree/bindings/usb/usb-switch-ports.yaml
new file mode 100644
index 000000000000..6bf0c97e30ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-switch-ports.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb-switch-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB Orientation and Mode Switches Ports Graph Properties
+
+maintainers:
+ - Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+description:
+ Ports Graph properties for devices handling USB mode and orientation switching.
+
+properties:
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description:
+ A port node to link the device to a TypeC controller for the purpose of
+ handling altmode muxing and orientation switching.
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ uniqueItems: true
+ items:
+ maximum: 8
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Super Speed (SS) Output endpoint to the Type-C connector
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description:
+ Super Speed (SS) Input endpoint from the Super-Speed PHY
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ uniqueItems: true
+ items:
+ maximum: 8
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml
new file mode 100644
index 000000000000..f77731493dc4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB Orientation and Mode Switches Common Properties
+
+maintainers:
+ - Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+description:
+ Common properties for devices handling USB mode and orientation switching.
+
+properties:
+ mode-switch:
+ description: Possible handler of altmode switching
+ type: boolean
+
+ orientation-switch:
+ description: Possible handler of orientation switching
+ type: boolean
+
+ retimer-switch:
+ description: Possible handler of SuperSpeed signals retiming
+ type: boolean
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/usb/usb-uhci.txt b/Documentation/devicetree/bindings/usb/usb-uhci.txt
deleted file mode 100644
index d1702eb2c8bd..000000000000
--- a/Documentation/devicetree/bindings/usb/usb-uhci.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Generic Platform UHCI Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "generic-uhci" (deprecated: "platform-uhci")
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : UHCI controller interrupt
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Example:
-
- uhci@d8007b00 {
- compatible = "generic-uhci";
- reg = <0xd8007b00 0x200>;
- interrupts = <43>;
- };
diff --git a/Documentation/devicetree/bindings/usb/usb-uhci.yaml b/Documentation/devicetree/bindings/usb/usb-uhci.yaml
new file mode 100644
index 000000000000..e050ca203945
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-uhci.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb-uhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Platform UHCI Controller
+
+maintainers:
+ - Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: generic-uhci
+ - const: platform-uhci
+ deprecated: true
+ - items:
+ - enum:
+ - aspeed,ast2400-uhci
+ - aspeed,ast2500-uhci
+ - aspeed,ast2600-uhci
+ - aspeed,ast2700-uhci
+ - const: generic-uhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#ports':
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: usb-hcd.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: generic-uhci
+ then:
+ required:
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: aspeed,ast2700-uhci
+ then:
+ required:
+ - resets
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+
+ usb@d8007b00 {
+ compatible = "generic-uhci";
+ reg = <0xd8007b00 0x200>;
+ interrupts = <43>;
+ clocks = <&syscon ASPEED_CLK_GATE_USBUHCICLK>;
+ };
+ - |
+ #include <dt-bindings/clock/aspeed-clock.h>
+
+ usb@1e6b0000 {
+ compatible = "aspeed,ast2500-uhci", "generic-uhci";
+ reg = <0x1e6b0000 0x100>;
+ interrupts = <14>;
+ #ports = <2>;
+ clocks = <&syscon ASPEED_CLK_GATE_USBUHCICLK>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml
index 965f87fef702..4238ae896ef6 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/usb/usb-xhci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic USB xHCI Controller Device Tree Bindings
+title: Generic USB xHCI Controller
maintainers:
- Mathias Nyman <mathias.nyman@intel.com>
allOf:
- - $ref: "usb-hcd.yaml#"
+ - $ref: usb-hcd.yaml#
properties:
usb2-lpm-disable:
@@ -29,6 +29,12 @@ properties:
description: Interrupt moderation interval
default: 5000
+ num-hc-interrupters:
+ description: Maximum number of interrupters to allocate
+ $ref: /schemas/types.yaml#/definitions/uint16
+ minimum: 1
+ maximum: 1024
+
additionalProperties: true
examples:
diff --git a/Documentation/devicetree/bindings/usb/usb.yaml b/Documentation/devicetree/bindings/usb/usb.yaml
index 939f217b8c7b..1761b7aa92f0 100644
--- a/Documentation/devicetree/bindings/usb/usb.yaml
+++ b/Documentation/devicetree/bindings/usb/usb.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/usb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Generic USB Controller Device Tree Bindings
+title: Generic USB Controller
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@@ -25,6 +25,8 @@ properties:
usb-phy:
$ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
description:
List of all the USB PHYs on this HCD to be accepted by the legacy USB
Physical Layer subsystem.
diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt b/Documentation/devicetree/bindings/usb/usb251xb.txt
deleted file mode 100644
index 1a934eab175e..000000000000
--- a/Documentation/devicetree/bindings/usb/usb251xb.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-Microchip USB 2.0 Hi-Speed Hub Controller
-
-The device node for the configuration of a Microchip USB251x/xBi USB 2.0
-Hi-Speed Controller.
-
-Required properties :
- - compatible : Should be "microchip,usb251xb" or one of the specific types:
- "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
- "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi",
- "microchip,usb2517", "microchip,usb2517i", "microchip,usb2422"
- - reg : I2C address on the selected bus (default is <0x2C>)
-
-Optional properties :
- - reset-gpios : Should specify the gpio for hub reset
- - vdd-supply : Should specify the phandle to the regulator supplying vdd
- - skip-config : Skip Hub configuration, but only send the USB-Attach command
- - vendor-id : Set USB Vendor ID of the hub (16 bit, default is 0x0424)
- - product-id : Set USB Product ID of the hub (16 bit, default depends on type)
- - device-id : Set USB Device ID of the hub (16 bit, default is 0x0bb3)
- - language-id : Set USB Language ID (16 bit, default is 0x0000)
- - manufacturer : Set USB Manufacturer string (max 31 characters long)
- - product : Set USB Product string (max 31 characters long)
- - serial : Set USB Serial string (max 31 characters long)
- - {bus,self}-powered : selects between self- and bus-powered operation
- (boolean, default is self-powered)
- - disable-hi-speed : disable USB Hi-Speed support (boolean)
- - {multi,single}-tt : selects between multi- and single-transaction-translator
- (boolean, default is multi-tt)
- - disable-eop : disable End of Packet generation in full-speed mode (boolean)
- - {ganged,individual}-sensing : select over-current sense type in self-powered
- mode (boolean, default is individual)
- - {ganged,individual}-port-switching : select port power switching mode
- (boolean, default is individual)
- - dynamic-power-switching : enable auto-switching from self- to bus-powered
- operation if the local power source is removed or unavailable (boolean)
- - oc-delay-us : Delay time (in microseconds) for filtering the over-current
- sense inputs. Valid values are 100, 4000, 8000 (default) and 16000. If
- an invalid value is given, the default is used instead.
- - compound-device : indicate the hub is part of a compound device (boolean)
- - port-mapping-mode : enable port mapping mode (boolean)
- - led-{usb,speed}-mode : led usb/speed indication mode selection
- (boolean, default is speed mode)
- - string-support : enable string descriptor support (required for manufacturer,
- product and serial string configuration)
- - non-removable-ports : Should specify the ports which have a non-removable
- device connected.
- - sp-disabled-ports : Specifies the ports which will be self-power disabled
- - bp-disabled-ports : Specifies the ports which will be bus-power disabled
- - sp-max-total-current-microamp: Specifies max current consumed by the hub
- from VBUS when operating in self-powered hub. It includes the hub
- silicon along with all associated circuitry including a permanently
- attached peripheral (range: 0 - 100000 uA, default 1000 uA)
- - bp-max-total-current-microamp: Specifies max current consumed by the hub
- from VBUS when operating in self-powered hub. It includes the hub
- silicon along with all associated circuitry including a permanently
- attached peripheral (range: 0 - 510000 uA, default 100000 uA)
- - sp-max-removable-current-microamp: Specifies max current consumed by the hub
- from VBUS when operating in self-powered hub. It includes the hub
- silicon along with all associated circuitry excluding a permanently
- attached peripheral (range: 0 - 100000 uA, default 1000 uA)
- - bp-max-removable-current-microamp: Specifies max current consumed by the hub
- from VBUS when operating in self-powered hub. It includes the hub
- silicon along with all associated circuitry excluding a permanently
- attached peripheral (range: 0 - 510000 uA, default 100000 uA)
- - power-on-time-ms : Specifies the time it takes from the time the host
- initiates the power-on sequence to a port until the port has adequate
- power. The value is given in ms in a 0 - 510 range (default is 100ms).
- - swap-dx-lanes : Specifies the ports which will swap the differential-pair
- (D+/D-), default is not-swapped.
-
-Examples:
- usb2512b@2c {
- compatible = "microchip,usb2512b";
- reg = <0x2c>;
- reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
- };
-
- usb2514b@2c {
- compatible = "microchip,usb2514b";
- reg = <0x2c>;
- vendor-id = /bits/ 16 <0x0000>;
- product-id = /bits/ 16 <0x0000>;
- string-support;
- manufacturer = "Foo";
- product = "Foo-Bar";
- serial = "1234567890A";
- /* correct misplaced usb connectors on port 1,2 */
- swap-dx-lanes = <1 2>;
- };
diff --git a/Documentation/devicetree/bindings/usb/usb251xb.yaml b/Documentation/devicetree/bindings/usb/usb251xb.yaml
new file mode 100644
index 000000000000..0329a6aaaa92
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb251xb.yaml
@@ -0,0 +1,278 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb251xb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip USB 2.0 Hi-Speed Hub Controller
+
+maintainers:
+ - Richard Leitner <richard.leitner@skidata.com>
+
+properties:
+ compatible:
+ enum:
+ - microchip,usb2422
+ - microchip,usb2512b
+ - microchip,usb2512bi
+ - microchip,usb2513b
+ - microchip,usb2513bi
+ - microchip,usb2514b
+ - microchip,usb2514bi
+ - microchip,usb2517
+ - microchip,usb2517i
+ - microchip,usb251xb
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description: |
+ Should specify the gpio for hub reset
+
+ vdd-supply:
+ description: |
+ Should specify the phandle to the regulator supplying vdd
+
+ skip-config:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Skip Hub configuration, but only send the USB-Attach command
+
+ vendor-id:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ default: 0x0424
+ description: |
+ Set USB Vendor ID of the hub
+
+ product-id:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ description: |
+ Set USB Product ID of the hub
+
+ device-id:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ default: 0x0bb3
+ description: |
+ Set USB Device ID of the hub
+
+ language-id:
+ $ref: /schemas/types.yaml#/definitions/uint16
+ default: 0x0000
+ description: |
+ Set USB Language ID
+
+ manufacturer:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Set USB Manufacturer string (max 31 characters long)
+
+ product:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Set USB Product string (max 31 characters long)
+
+ serial:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Set USB Serial string (max 31 characters long)
+
+ bus-powered:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ selects between self- and bus-powered operation
+ (boolean, default is self-powered)
+
+ self-powered:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ selects between self- and bus-powered operation
+ (boolean, default is self-powered)
+
+ disable-hi-speed:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ disable USB Hi-Speed support (boolean)
+
+ multi-tt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ selects between multi- and single-transaction-translator
+ (boolean, default is multi-tt)
+
+ single-tt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ selects between multi- and single-transaction-translator
+ (boolean, default is multi-tt)
+
+ disable-eop:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ disable End of Packet generation in full-speed mode (boolean)
+
+ ganged-sensing:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ select over-current sense type in self-powered mode
+ (boolean, default is individual)
+
+ individual-sensing:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ select over-current sense type in self-powered mode
+ (boolean, default is individual)
+
+ ganged-port-switching:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ select port power switching mode (boolean, default is individual)
+
+ individual-port-switching:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ select port power switching mode (boolean, default is individual)
+
+ dynamic-power-switching:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ enable auto-switching from self- to bus-powered operation if the
+ local power source is removed or unavailable (boolean)
+
+ oc-delay-us:
+ enum: [100, 4000, 8000, 16000]
+ default: 8000
+ description: |
+ Delay time (in microseconds) for filtering the over-current sense
+ inputs. If an invalid value is given, the default is used instead.
+
+ compound-device:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ indicate the hub is part of a compound device (boolean)
+
+ port-mapping-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ enable port mapping mode (boolean)
+
+ led-usb-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ led usb/speed indication mode selection (boolean, default is speed mode)
+
+ led-speed-mode:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ led usb/speed indication mode selection (boolean, default is speed mode)
+
+ string-support:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ enable string descriptor support (required for manufacturer, product
+ and serial string configuration)
+
+ non-removable-ports:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: |
+ Should specify the ports which have a non-removable device connected.
+
+ sp-disabled-ports:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: |
+ Specifies the ports which will be self-power disabled
+
+ bp-disabled-ports:
+ $ref: /schemas/types.yaml#/definitions/uint8-array
+ description: |
+ Specifies the ports which will be bus-power disabled
+
+ sp-max-total-current-microamp:
+ maximum: 100000
+ default: 1000
+ description: |
+ Specifies max current consumed by the hub from VBUS when
+ operating in self-powered hub. It includes the hub silicon
+ along with all associated circuitry including a permanently
+ attached peripheral.
+
+ bp-max-total-current-microamp:
+ maximum: 510000
+ default: 100000
+ description: |
+ Specifies max current consumed by the hub from VBUS when
+ operating in self-powered hub. It includes the hub silicon
+ along with all associated circuitry including a permanently
+ attached peripheral.
+
+ sp-max-removable-current-microamp:
+ maximum: 100000
+ default: 1000
+ description: |
+ Specifies max current consumed by the hub from VBUS when
+ operating in self-powered hub. It includes the hub silicon
+ along with all associated circuitry excluding a permanently
+ attached peripheral.
+
+ bp-max-removable-current-microamp:
+ maximum: 510000
+ default: 100000
+ description: |
+ Specifies max current consumed by the hub from VBUS when
+ operating in self-powered hub. It includes the hub silicon
+ along with all associated circuitry excluding a permanently
+ attached peripheral.
+
+ power-on-time-ms:
+ maximum: 510
+ default: 100
+ description: |
+ Specifies the time it takes from the time the host initiates the
+ power-on sequence to a port until the port has adequate power.
+
+ swap-dx-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ Specifies the ports which will swap the differential-pair (D+/D-),
+ default is not-swapped.
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb-hub@2c {
+ compatible = "microchip,usb2512b";
+ reg = <0x2c>;
+ reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ };
+
+ usb-hub@2d {
+ compatible = "microchip,usb2514b";
+ reg = <0x2d>;
+ vendor-id = /bits/ 16 <0x0000>;
+ product-id = /bits/ 16 <0x0000>;
+ string-support;
+ manufacturer = "Foo";
+ product = "Foo-Bar";
+ serial = "1234567890A";
+ /* correct misplaced usb connectors on port 1,2 */
+ swap-dx-lanes = <1 2>;
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ usb-hub {
+ /* I2C is not connected */
+ compatible = "microchip,usb2512b";
+ reset-gpios = <&porta 8 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
deleted file mode 100644
index b796836d2ce7..000000000000
--- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Freescale i.MX non-core registers
-
-Required properties:
-- #index-cells: Cells used to describe usb controller index. Should be <1>
-- compatible: Should be one of below:
- "fsl,imx6q-usbmisc" for imx6q
- "fsl,vf610-usbmisc" for Vybrid vf610
- "fsl,imx6sx-usbmisc" for imx6sx
- "fsl,imx7d-usbmisc" for imx7d
- "fsl,imx7ulp-usbmisc" for imx7ulp
-- reg: Should contain registers location and length
-
-Examples:
-usbmisc@2184800 {
- #index-cells = <1>;
- compatible = "fsl,imx6q-usbmisc";
- reg = <0x02184800 0x200>;
-};
diff --git a/Documentation/devicetree/bindings/usb/vialab,vl817.yaml b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
new file mode 100644
index 000000000000..c815010ba9c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/vialab,vl817.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/vialab,vl817.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Via labs VL817 USB 3.1 hub controller
+
+maintainers:
+ - Anand Moon <linux.amoon@gmail.com>
+
+allOf:
+ - $ref: usb-device.yaml#
+
+properties:
+ compatible:
+ enum:
+ - usb2109,2817
+ - usb2109,817
+
+ reg: true
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the RESET# pin.
+
+ vdd-supply:
+ description:
+ phandle to the regulator that provides power to the hub.
+
+ peer-hub:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to the peer hub on the controller.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - peer-hub
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb2109,2817";
+ reg = <1>;
+ vdd-supply = <&vcc_5v>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.1 hub on port 4 */
+ hub_3_0: hub@2 {
+ compatible = "usb2109,817";
+ reg = <2>;
+ vdd-supply = <&vcc_5v>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml b/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml
index c2b2243c7892..937670de01cc 100644
--- a/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml
+++ b/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/usb/willsemi,wusb3801.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: WUSB3801 Type-C port controller DT bindings
+title: WUSB3801 Type-C port controller
description:
The Will Semiconductor WUSB3801 is a USB Type-C port controller which
@@ -28,6 +28,7 @@ properties:
connector:
type: object
$ref: ../connector/usb-connector.yaml#
+ unevaluatedProperties: false
description:
The managed USB Type-C connector. Since WUSB3801 does not support
Power Delivery, the node should have the "pd-disable" property.
diff --git a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
index 04c123c7252a..f295aa9d9ee7 100644
--- a/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx udc controller
maintainers:
- - Manish Narani <manish.narani@xilinx.com>
+ - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
compatible:
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 1faea7d315c0..c7591b2aec2a 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -18,9 +18,10 @@ patternProperties:
# DO NOT ADD NEW PROPERTIES TO THIS LIST
"^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*": true
"^(keypad|m25p|max8952|max8997|max8998|mpmc),.*": true
- "^(pinctrl-single|#pinctrl-single|PowerPC),.*": true
+ "^(pciclass|pinctrl-single|#pinctrl-single|PowerPC),.*": true
"^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*": true
- "^(simple-audio-card|st-plgpio|st-spics|ts),.*": true
+ "^(simple-audio-card|st-plgpio|st-spics|ts|vsc8531),.*": true
+ "^pool[0-3],.*": true
# Keep list in alphabetical order.
"^100ask,.*":
@@ -29,6 +30,8 @@ patternProperties:
description: 70mai Co., Ltd.
"^8dev,.*":
description: 8devices, UAB
+ "^9tripod,.*":
+ description: Shenzhen 9Tripod Innovation and Development CO., LTD.
"^abb,.*":
description: ABB
"^abilis,.*":
@@ -37,12 +40,18 @@ patternProperties:
description: Abracon Corporation
"^abt,.*":
description: ShenZhen Asia Better Technology Ltd.
+ "^acbel,.*":
+ description: Acbel Polytech Inc.
+ "^acelink,.*":
+ description: Acelink Technology Co., Ltd.
"^acer,.*":
description: Acer Inc.
"^acme,.*":
description: Acme Systems srl
"^actions,.*":
description: Actions Semiconductor Co., Ltd.
+ "^actiontec,.*":
+ description: Actiontec Electronics, Inc
"^active-semi,.*":
description: Active-Semi International Inc
"^ad,.*":
@@ -57,6 +66,10 @@ patternProperties:
description: AD Holdings Plc.
"^adi,.*":
description: Analog Devices, Inc.
+ "^adieng,.*":
+ description: ADI Engineering, Inc.
+ "^admatec,.*":
+ description: admatec GmbH
"^advantech,.*":
description: Advantech Corporation
"^aeroflexgaisler,.*":
@@ -69,8 +82,18 @@ patternProperties:
description: Annapurna Labs
"^alcatel,.*":
description: Alcatel
+ "^aldec,.*":
+ description: Aldec, Inc.
+ "^alfa-network,.*":
+ description: ALFA Network Inc.
"^allegro,.*":
description: Allegro DVT
+ "^allegromicro,.*":
+ description: Allegro MicroSystems, Inc.
+ "^alliedtelesis,.*":
+ description: Allied Telesis, Inc.
+ "^alliedvision,.*":
+ description: Allied Vision Technologies GmbH
"^allo,.*":
description: Allo.com
"^allwinner,.*":
@@ -97,6 +120,8 @@ patternProperties:
description: Amlogic, Inc.
"^ampere,.*":
description: Ampere Computing LLC
+ "^amphenol,.*":
+ description: Amphenol Advanced Sensors
"^ampire,.*":
description: Ampire Co., Ltd.
"^ams,.*":
@@ -109,8 +134,14 @@ patternProperties:
description: Anbernic
"^andestech,.*":
description: Andes Technology Corporation
+ "^anlogic,.*":
+ description: Shanghai Anlogic Infotech Co., Ltd.
"^anvo,.*":
description: Anvo-Systems Dresden GmbH
+ "^aoly,.*":
+ description: Shenzhen Aoly Technology Co., Ltd.
+ "^aosong,.*":
+ description: Guangzhou Aosong Electronic Co., Ltd.
"^apm,.*":
description: Applied Micro Circuits Corporation (APM)
"^apple,.*":
@@ -121,16 +152,24 @@ patternProperties:
description: Arasan Chip Systems
"^archermind,.*":
description: ArcherMind Technology (Nanjing) Co., Ltd.
+ "^arcom,.*":
+ description: Arcom Controllers
"^arctic,.*":
description: Arctic Sand
"^arcx,.*":
description: arcx Inc. / Archronix Inc.
+ "^argon40,.*":
+ description: Argon 40 Technologies Limited
+ "^ariaboard,.*":
+ description: Shanghai Novotech Co., Ltd. (Ariaboard)
"^aries,.*":
description: Aries Embedded GmbH
"^arm,.*":
description: ARM Ltd.
"^armadeus,.*":
description: ARMadeus Systems SARL
+ "^armsom,.*":
+ description: ArmSoM Technology Co., Ltd.
"^arrow,.*":
description: Arrow Electronics
"^artesyn,.*":
@@ -141,10 +180,14 @@ patternProperties:
description: All Sensors Corporation
"^asix,.*":
description: ASIX Electronics Corporation
+ "^asl-tek,.*":
+ description: ASL Xiamen Technology Co., Ltd.
"^aspeed,.*":
description: ASPEED Technology Inc.
"^asrock,.*":
description: ASRock Inc.
+ "^asteralabs,.*":
+ description: Astera Labs, Inc.
"^asus,.*":
description: AsusTek Computer Inc.
"^atheros,.*":
@@ -170,6 +213,8 @@ patternProperties:
description: Shanghai Awinic Technology Co., Ltd.
"^axentia,.*":
description: Axentia Technologies AB
+ "^axiado,.*":
+ description: Axiado Corporation
"^axis,.*":
description: Axis Communications AB
"^azoteq,.*":
@@ -184,10 +229,20 @@ patternProperties:
description: Compass Electronics Group, LLC
"^beagle,.*":
description: BeagleBoard.org Foundation
+ "^belling,.*":
+ description: Shanghai Belling Co., Ltd.
+ "^bestar,.*":
+ description: Shenzhen Bestar Electronic Technology Co., Ltd.
"^bhf,.*":
description: Beckhoff Automation GmbH & Co. KG
+ "^bigtreetech,.*":
+ description: Shenzhen BigTree Tech Co., LTD
"^bitmain,.*":
description: Bitmain Technologies
+ "^blaize,.*":
+ description: Blaize, Inc.
+ "^bluegiga,.*":
+ description: Bluegiga Technologies Ltd.
"^blutek,.*":
description: BluTek Power
"^boe,.*":
@@ -196,26 +251,34 @@ patternProperties:
description: Bosch Sensortec GmbH
"^boundary,.*":
description: Boundary Devices Inc.
- "^broadmobi,.*":
- description: Shanghai Broadmobi Communication Technology Co.,Ltd.
"^brcm,.*":
description: Broadcom Corporation
+ "^broadmobi,.*":
+ description: Shanghai Broadmobi Communication Technology Co.,Ltd.
"^bsh,.*":
description: BSH Hausgeraete GmbH
+ "^bst,.*":
+ description: Black Sesame Technologies Co., Ltd.
"^bticino,.*":
description: Bticino International
"^buffalo,.*":
description: Buffalo, Inc.
+ "^buglabs,.*":
+ description: Bug Labs, Inc.
"^bur,.*":
description: B&R Industrial Automation GmbH
"^bytedance,.*":
description: ByteDance Ltd.
"^calamp,.*":
description: CalAmp Corp.
+ "^calao,.*":
+ description: CALAO Systems SAS
"^calaosystems,.*":
description: CALAO Systems SAS
"^calxeda,.*":
description: Calxeda
+ "^cameo,.*":
+ description: Cameo Communications, Inc
"^canaan,.*":
description: Canaan, Inc.
"^caninos,.*":
@@ -228,6 +291,8 @@ patternProperties:
description: Catalyst Semiconductor, Inc.
"^cavium,.*":
description: Cavium, Inc.
+ "^cct,.*":
+ description: Crystal Clear Technology Sdn. Bhd.
"^cdns,.*":
description: Cadence Design Systems Inc.
"^cdtech,.*":
@@ -236,6 +301,8 @@ patternProperties:
description: CellWise Microelectronics Co., Ltd
"^ceva,.*":
description: Ceva, Inc.
+ "^chargebyte,.*":
+ description: chargebyte GmbH
"^checkpoint,.*":
description: Check Point Software Technologies Ltd.
"^chefree,.*":
@@ -246,6 +313,8 @@ patternProperties:
description: ChipOne
"^chipspark,.*":
description: ChipSPARK
+ "^chongzhou,.*":
+ description: Shenzhen Chongzhou Electronic Technology Co., Ltd
"^chrontel,.*":
description: Chrontel, Inc.
"^chrp,.*":
@@ -260,6 +329,12 @@ patternProperties:
description: Cirrus Logic, Inc.
"^cisco,.*":
description: Cisco Systems, Inc.
+ "^cix,.*":
+ description: CIX Technology Group Co., Ltd.
+ "^clockwork,.*":
+ description: Clockwork Tech LLC
+ "^cloos,.*":
+ description: Carl Cloos Schweisstechnik GmbH.
"^cloudengines,.*":
description: Cloud Engines, Inc.
"^cnm,.*":
@@ -268,10 +343,16 @@ patternProperties:
description: Conexant Systems, Inc.
"^colorfly,.*":
description: Colorful GRP, Shenzhen Xueyushi Technology Ltd.
+ "^compal,.*":
+ description: Compal Electronics, Inc.
"^compulab,.*":
description: CompuLab Ltd.
+ "^comvetia,.*":
+ description: ComVetia AG
"^congatec,.*":
description: congatec GmbH
+ "^coolpi,.*":
+ description: cool-pi.com
"^coreriver,.*":
description: CORERIVER Semiconductor Co.,Ltd.
"^corpro,.*":
@@ -288,14 +369,20 @@ patternProperties:
description: Crystalfontz America, Inc.
"^csky,.*":
description: Hangzhou C-SKY Microsystems Co., Ltd
+ "^csot,.*":
+ description: Guangzhou China Star Optoelectronics Technology Co., Ltd
"^csq,.*":
description: Shenzen Chuangsiqi Technology Co.,Ltd.
+ "^csr,.*":
+ description: Cambridge Silicon Radio
"^ctera,.*":
description: CTERA Networks Intl.
"^ctu,.*":
description: Czech Technical University in Prague
"^cubietech,.*":
description: Cubietech, Ltd.
+ "^cudy,.*":
+ description: Shenzhen Cudy Technology Co., Ltd.
"^cui,.*":
description: CUI Devices
"^cypress,.*":
@@ -310,6 +397,8 @@ patternProperties:
description: DataImage, Inc.
"^davicom,.*":
description: DAVICOM Semiconductor, Inc.
+ "^deepcomputing,.*":
+ description: DeepComputing (HK) Limited
"^dell,.*":
description: Dell Inc.
"^delta,.*":
@@ -322,6 +411,8 @@ patternProperties:
description: Devantech, Ltd.
"^dfi,.*":
description: DFI Inc.
+ "^dfrobot,.*":
+ description: DFRobot Corporation
"^dh,.*":
description: DH electronics GmbH
"^difrnce,.*":
@@ -330,8 +421,14 @@ patternProperties:
description: Digi International Inc.
"^digilent,.*":
description: Diglent, Inc.
+ "^dimonoff,.*":
+ description: Dimonoff inc.
+ "^diodes,.*":
+ description: Diodes, Inc.
"^dioo,.*":
description: Dioo Microcircuit Co., Ltd
+ "^djn,.*":
+ description: Shenzhen DJN Optronics Technology Co., Ltd
"^dlc,.*":
description: DLC Display Co., Ltd.
"^dlg,.*":
@@ -348,6 +445,8 @@ patternProperties:
description: DPTechnics
"^dragino,.*":
description: Dragino Technology Co., Limited
+ "^dream,.*":
+ description: Dream Property GmbH
"^ds,.*":
description: DaSheng, Inc.
"^dserve,.*":
@@ -366,12 +465,20 @@ patternProperties:
description: EBV Elektronik
"^eckelmann,.*":
description: Eckelmann AG
+ "^econet,.*":
+ description: EcoNet (HK) Limited
+ "^edgeble,.*":
+ description: Edgeble AI Technologies Pvt. Ltd.
"^edimax,.*":
description: EDIMAX Technology Co., Ltd
"^edt,.*":
description: Emerging Display Technologies
+ "^ees,.*":
+ description: Emtop Embedded Solutions
"^eeti,.*":
description: eGalax_eMPIA Technology Inc
+ "^egnite,.*":
+ description: egnite GmbH
"^einfochips,.*":
description: Einfochips
"^eink,.*":
@@ -388,8 +495,12 @@ patternProperties:
description: Elimo Engineering Ltd.
"^elpida,.*":
description: Elpida Memory, Inc.
+ "^embedfire,.*":
+ description: Dongguan EmbedFire Electronic Technology Co., Ltd.
"^embest,.*":
description: Shenzhen Embest Technology Co., Ltd.
+ "^emcraft,.*":
+ description: Emcraft Systems
"^emlid,.*":
description: Emlid, Ltd.
"^emmicro,.*":
@@ -398,8 +509,12 @@ patternProperties:
description: Empire Electronix
"^emtrion,.*":
description: emtrion GmbH
+ "^enbw,.*":
+ description: Energie Baden-Württemberg AG
"^enclustra,.*":
description: Enclustra GmbH
+ "^endian,.*":
+ description: Endian SRL
"^endless,.*":
description: Endless Mobile, Inc.
"^ene,.*":
@@ -420,6 +535,8 @@ patternProperties:
description: Espressif Systems Co. Ltd.
"^est,.*":
description: ESTeem Wireless Modems
+ "^eswin,.*":
+ description: Beijing ESWIN Technology Group Co. Ltd.
"^ettus,.*":
description: NI Ettus Research
"^eukrea,.*":
@@ -440,10 +557,15 @@ patternProperties:
description: EZchip Semiconductor
"^facebook,.*":
description: Facebook
+ "^fairchild,.*":
+ description: Fairchild Semiconductor (deprecated, use 'onnn')
+ deprecated: true
"^fairphone,.*":
description: Fairphone B.V.
"^faraday,.*":
description: Faraday Technology Corporation
+ "^fascontek,.*":
+ description: Fascontek
"^fastrax,.*":
description: Fastrax Oy
"^fcs,.*":
@@ -456,10 +578,22 @@ patternProperties:
description: Foxconn Industrial Internet
"^firefly,.*":
description: Firefly
+ "^fitipower,.*":
+ description: Fitipower Integrated Technology Inc.
+ "^flipkart,.*":
+ description: Flipkart Inc.
"^focaltech,.*":
description: FocalTech Systems Co.,Ltd
"^forlinx,.*":
description: Baoding Forlinx Embedded Technology Co., Ltd.
+ "^foursemi,.*":
+ description: Shanghai FourSemi Semiconductor Co.,Ltd.
+ "^foxlink,.*":
+ description: Foxlink Group
+ "^freebox,.*":
+ description: Freebox SAS
+ "^freecom,.*":
+ description: Freecom Gmbh
"^frida,.*":
description: Shenzhen Frida LCD Co., Ltd.
"^friendlyarm,.*":
@@ -470,8 +604,14 @@ patternProperties:
description: Fujitsu Ltd.
"^fxtec,.*":
description: FX Technology Ltd.
+ "^galaxycore,.*":
+ description: GalaxyCore Inc.
+ "^gameforce,.*":
+ description: GameForce
"^gardena,.*":
description: GARDENA GmbH
+ "^gateway,.*":
+ description: Gateway Communications
"^gateworks,.*":
description: Gateworks Corporation
"^gcw,.*":
@@ -484,24 +624,42 @@ patternProperties:
description: GE Fanuc Intelligent Platforms Embedded Systems, Inc.
"^GEFanuc,.*":
description: GE Fanuc Intelligent Platforms Embedded Systems, Inc.
+ "^gehc,.*":
+ description: GE HealthCare
"^gemei,.*":
description: Gemei Digital Technology Co., Ltd.
+ "^gemtek,.*":
+ description: Gemtek Technology Co., Ltd.
+ "^genesys,.*":
+ description: Genesys Logic, Inc.
+ "^genexis,.*":
+ description: Genexis BV/AB
"^geniatech,.*":
description: Geniatech, Inc.
"^giantec,.*":
description: Giantec Semiconductor, Inc.
"^giantplus,.*":
description: Giantplus Technology Co., Ltd.
+ "^glinet,.*":
+ description: GL Intelligence, Inc.
"^globalscale,.*":
description: Globalscale Technologies, Inc.
"^globaltop,.*":
description: GlobalTop Technology, Inc.
"^gmt,.*":
description: Global Mixed-mode Technology, Inc.
+ "^gocontroll,.*":
+ description: GOcontroll Modular Embedded Electronics B.V.
+ "^goldelico,.*":
+ description: Golden Delicious Computers GmbH & Co. KG
"^goodix,.*":
description: Shenzhen Huiding Technology Co., Ltd.
"^google,.*":
description: Google, Inc.
+ "^goramo,.*":
+ description: Goramo Gorecki
+ "^gplus,.*":
+ description: GPLUS
"^grinn,.*":
description: Grinn
"^grmn,.*":
@@ -520,12 +678,18 @@ patternProperties:
description: Haoyu Microelectronic Co. Ltd.
"^hardkernel,.*":
description: Hardkernel Co., Ltd
+ "^hce,.*":
+ description: HCE Engineering SRL
+ "^headacoustics,.*":
+ description: HEAD acoustics
"^hechuang,.*":
description: Shenzhen Hechuang Intelligent Co.
"^hideep,.*":
description: HiDeep Inc.
"^himax,.*":
description: Himax Technologies, Inc.
+ "^hinlink,.*":
+ description: Shenzhen HINLINK Technology Co., Ltd.
"^hirschmann,.*":
description: Hirschmann Automation and Control GmbH
"^hisi,.*":
@@ -539,10 +703,14 @@ patternProperties:
description: Hitex Development Tools
"^holt,.*":
description: Holt Integrated Circuits, Inc.
+ "^holtek,.*":
+ description: Holtek Semiconductor, Inc.
"^honestar,.*":
description: Honestar Technologies Co., Ltd.
"^honeywell,.*":
description: Honeywell
+ "^hoperf,.*":
+ description: Shenzhen Hope Microelectronics Co., Ltd.
"^hoperun,.*":
description: Jiangsu HopeRun Software Co., Ltd.
"^hp,.*":
@@ -551,12 +719,14 @@ patternProperties:
description: Hewlett Packard Enterprise
"^hsg,.*":
description: HannStar Display Co.
- "^holtek,.*":
- description: Holtek Semiconductor, Inc.
+ "^htc,.*":
+ description: HTC Corporation
"^huawei,.*":
description: Huawei Technologies Co., Ltd.
"^hugsun,.*":
description: Shenzhen Hugsun Technology Co. Ltd.
+ "^huiling,.*":
+ description: Shenzhen Huiling Information Technology Co., Ltd.
"^hwacom,.*":
description: HwaCom Systems Inc.
"^hxt,.*":
@@ -565,18 +735,24 @@ patternProperties:
description: Hycon Technology Corp.
"^hydis,.*":
description: Hydis Technologies
+ "^hynitron,.*":
+ description: Shanghai Hynitron Microelectronics Co. Ltd.
"^hynix,.*":
description: SK Hynix Inc.
"^hyundai,.*":
description: Hyundai Technology
"^i2se,.*":
description: I2SE GmbH
+ "^IBM,.*":
+ description: International Business Machines (IBM)
"^ibm,.*":
description: International Business Machines (IBM)
"^icplus,.*":
description: IC Plus Corp.
"^idt,.*":
description: Integrated Device Technologies, Inc.
+ "^iei,.*":
+ description: IEI Integration Corp.
"^ifi,.*":
description: Ingenieurburo Fur Ic-Technologie (I/F/I)
"^ilitek,.*":
@@ -587,22 +763,28 @@ patternProperties:
description: Imagination Technologies Ltd.
"^imi,.*":
description: Integrated Micro-Electronics Inc.
+ "^inanbo,.*":
+ description: Shenzhen INANBO Electronic Technology Co., Ltd.
"^incircuit,.*":
description: In-Circuit GmbH
+ "^incostartec,.*":
+ description: INCOstartec GmbH
+ "^indiedroid,.*":
+ description: Indiedroid
"^inet-tek,.*":
description: Shenzhen iNet Mobile Internet Technology Co., Ltd
"^infineon,.*":
description: Infineon Technologies
"^inforce,.*":
description: Inforce Computing
- "^ingrasys,.*":
- description: Ingrasys Technology Inc.
- "^ivo,.*":
- description: InfoVision Optoelectronics Kunshan Co. Ltd.
"^ingenic,.*":
description: Ingenic Semiconductor
+ "^ingrasys,.*":
+ description: Ingrasys Technology Inc.
"^injoinic,.*":
description: Injoinic Technology Corp.
+ "^innocomm,.*":
+ description: InnoComm Mobile Technology Corp.
"^innolux,.*":
description: Innolux Corporation
"^inside-secure,.*":
@@ -623,6 +805,8 @@ patternProperties:
description: Inverse Path
"^iom,.*":
description: Iomega Corporation
+ "^irondevice,.*":
+ description: Iron Device Corporation
"^isee,.*":
description: ISEE 2007 S.L.
"^isil,.*":
@@ -635,20 +819,34 @@ patternProperties:
description: ITEAD Intelligent Systems Co.Ltd
"^itian,.*":
description: ITian Corporation
+ "^ivo,.*":
+ description: InfoVision Optoelectronics Kunshan Co. Ltd.
"^iwave,.*":
description: iWave Systems Technologies Pvt. Ltd.
+ "^jadard,.*":
+ description: Jadard Technology Inc.
+ "^jasonic,.*":
+ description: Jasonic Technology Ltd.
"^jdi,.*":
description: Japan Display Inc.
"^jedec,.*":
description: JEDEC Solid State Technology Association
+ "^jenson,.*":
+ description: Jenson Display Co. Ltd.
"^jesurun,.*":
description: Shenzhen Jesurun Electronics Business Dept.
"^jethome,.*":
description: JetHome (IP Sokolov P.A.)
"^jianda,.*":
description: Jiandangjing Technology Co., Ltd.
+ "^jide,.*":
+ description: Jide Tech
"^joz,.*":
description: JOZ BV
+ "^jty,.*":
+ description: JTY
+ "^jutouch,.*":
+ description: JuTouch Technology Co., Ltd.
"^kam,.*":
description: Kamstrup A/S
"^karo,.*":
@@ -693,6 +891,10 @@ patternProperties:
description: Lantiq Semiconductor
"^lattice,.*":
description: Lattice Semiconductor
+ "^lckfb,.*":
+ description: Shenzhen JLC Technology Group Co., Ltd.
+ "^lctech,.*":
+ description: Shenzen LC Technology Co., Ltd.
"^leadtek,.*":
description: Shenzhen Leadtek Technology Co., Ltd.
"^leez,.*":
@@ -713,6 +915,12 @@ patternProperties:
description: Lichee Pi
"^linaro,.*":
description: Linaro Limited
+ "^lincolntech,.*":
+ description: Lincoln Technology Solutions
+ "^lineartechnology,.*":
+ description: Linear Technology
+ "^linkease,.*":
+ description: Shenzhen LinkEase Network Technology Co., Ltd.
"^linksprite,.*":
description: LinkSprite Technologies, Inc.
"^linksys,.*":
@@ -723,6 +931,8 @@ patternProperties:
description: Linux-specific binding
"^linx,.*":
description: Linx Technologies
+ "^liontron,.*":
+ description: Shenzhen Liontron Technology Co., Ltd
"^liteon,.*":
description: LITE-ON Technology Corp.
"^litex,.*":
@@ -739,8 +949,16 @@ patternProperties:
description: Lontium Semiconductor Corporation
"^loongson,.*":
description: Loongson Technology Corporation Limited
+ "^loongmasses,.*":
+ description: Nanjing Loongmasses Ltd.
"^lsi,.*":
description: LSI Corp. (LSI Logic)
+ "^luckfox,.*":
+ description: Shenzhen Luckfox Technology Co., Ltd.
+ "^lunzn,.*":
+ description: Shenzhen Lunzn Technology Co., Ltd.
+ "^luxul,.*":
+ description: Lagrand | AV
"^lwn,.*":
description: Liebherr-Werk Nenzing GmbH
"^lxa,.*":
@@ -753,12 +971,20 @@ patternProperties:
description: Mantix Display Technology Co.,Ltd.
"^mapleboard,.*":
description: Mapleboard.org
+ "^marantec,.*":
+ description: Marantec electronics GmbH
"^marvell,.*":
description: Marvell Technology Group Ltd.
"^maxbotix,.*":
description: MaxBotix Inc.
"^maxim,.*":
description: Maxim Integrated Products
+ "^maxlinear,.*":
+ description: MaxLinear Inc.
+ "^maxtor,.*":
+ description: Maxtor Corporation
+ "^mayqueen,.*":
+ description: Mayqueen Technologies Ltd.
"^mbvl,.*":
description: Mobiveil Inc.
"^mcube,.*":
@@ -779,6 +1005,8 @@ patternProperties:
description: MELFAS Inc.
"^mellanox,.*":
description: Mellanox Technologies
+ "^memsensing,.*":
+ description: MEMSensing Microsystems Co., Ltd.
"^memsic,.*":
description: MEMSIC Inc.
"^menlo,.*":
@@ -803,30 +1031,45 @@ patternProperties:
description: Microsoft Corporation
"^microsys,.*":
description: MicroSys Electronics GmbH
+ "^microtips,.*":
+ description: Microtips Technology USA
"^mikroe,.*":
description: MikroElektronika d.o.o.
"^mikrotik,.*":
description: MikroTik
+ "^milianke,.*":
+ description: Changzhou Milianke Electronic Technology Co., Ltd
+ "^milkv,.*":
+ description: MilkV Technology Co., Ltd
"^miniand,.*":
description: Miniand Tech
"^minix,.*":
description: MINIX Technology Ltd.
+ "^mips,.*":
+ description: MIPS Technology (deprecated, use 'mti' or 'img')
+ deprecated: true
"^miramems,.*":
description: MiraMEMS Sensing Technology Co., Ltd.
"^mitsubishi,.*":
description: Mitsubishi Electric Corporation
+ "^mitsumi,.*":
+ description: Mitsumi Electric Co., Ltd.
"^mixel,.*":
description: Mixel, Inc.
"^miyoo,.*":
description: Miyoo
"^mntre,.*":
description: MNT Research GmbH
+ "^mobileye,.*":
+ description: Mobileye Vision Technologies Ltd.
"^modtronix,.*":
description: Modtronix Engineering
"^moortec,.*":
description: Moortec Semiconductor Ltd.
"^mosaixtech,.*":
description: Mosaix Technologies, Inc.
+ "^motorcomm,.*":
+ description: MotorComm, Inc.
"^motorola,.*":
description: Motorola, Inc.
"^moxa,.*":
@@ -863,10 +1106,16 @@ patternProperties:
description: MYIR Tech Limited
"^national,.*":
description: National Semiconductor
+ "^neardi,.*":
+ description: Shanghai Neardi Technology Co., Ltd.
"^nec,.*":
description: NEC LCD Technologies, Ltd.
+ "^neofidelity,.*":
+ description: Neofidelity Inc.
"^neonode,.*":
description: Neonode Inc.
+ "^netcube,.*":
+ description: NetCube Systems Austria
"^netgear,.*":
description: NETGEAR
"^netlogic,.*":
@@ -879,14 +1128,18 @@ patternProperties:
description: Shenzhen Netxeon Technology CO., LTD
"^neweast,.*":
description: Guangdong Neweast Optoelectronics CO., LTD
+ "^newhaven,.*":
+ description: Newhaven Display International
+ "^newvision,.*":
+ description: New Vision Display (Shenzhen) Co., Ltd.
"^nexbox,.*":
description: Nexbox
"^nextthing,.*":
description: Next Thing Co.
- "^newhaven,.*":
- description: Newhaven Display International
"^ni,.*":
description: National Instruments
+ "^nicera,.*":
+ description: Nippon Ceramic Co., Ltd.
"^nintendo,.*":
description: Nintendo
"^nlt,.*":
@@ -895,8 +1148,19 @@ patternProperties:
description: Nokia
"^nordic,.*":
description: Nordic Semiconductor
+ "^nothing,.*":
+ description: Nothing Technology Limited
+ "^novatech,.*":
+ description: NovaTech Automation
+ "^novatek,.*":
+ description: Novatek
"^novtech,.*":
description: NovTech, Inc.
+ "^nuclei,.*":
+ description: Nuclei System Technology
+ "^numonyx,.*":
+ description: Numonyx (deprecated, use micron)
+ deprecated: true
"^nutsboard,.*":
description: NutsBoard
"^nuvoton,.*":
@@ -923,6 +1187,8 @@ patternProperties:
description: One Laptop Per Child
"^oneplus,.*":
description: OnePlus Technology (Shenzhen) Co., Ltd.
+ "^onie,.*":
+ description: Open Network Install Environment group
"^onion,.*":
description: Onion Corporation
"^onnn,.*":
@@ -937,8 +1203,12 @@ patternProperties:
description: OpenCores.org
"^openembed,.*":
description: OpenEmbed
+ "^openpandora,.*":
+ description: OpenPandora GmbH
"^openrisc,.*":
description: OpenRISC.io
+ "^openwrt,.*":
+ description: OpenWrt
"^option,.*":
description: Option NV
"^oranth,.*":
@@ -969,14 +1239,20 @@ patternProperties:
description: Parade Technologies Inc.
"^parallax,.*":
description: Parallax Inc.
+ "^particle,.*":
+ description: Particle Industries, Inc.
"^pda,.*":
description: Precision Design Associates, Inc.
+ "^pegatron,.*":
+ description: Pegatron Corporation
"^pericom,.*":
description: Pericom Technology Inc.
"^pervasive,.*":
description: Pervasive Displays, Inc.
"^phicomm,.*":
description: PHICOMM Co., Ltd.
+ "^phontech,.*":
+ description: Phontech
"^phytec,.*":
description: PHYTEC Messtechnik GmbH
"^picochip,.*":
@@ -1003,6 +1279,8 @@ patternProperties:
description: PocketBook International SA
"^polaroid,.*":
description: Polaroid Corporation
+ "^polyhex,.*":
+ description: Polyhex Technology Co. Ltd.
"^portwell,.*":
description: Portwell Inc.
"^poslab,.*":
@@ -1013,16 +1291,24 @@ patternProperties:
description: Powertip Tech. Corp.
"^powervr,.*":
description: PowerVR (deprecated, use img)
+ "^powkiddy,.*":
+ description: Powkiddy
+ "^primeview,.*":
+ description: Prime View International (PVI)
"^primux,.*":
description: Primux Trading, S.L.
"^probox2,.*":
description: PROBOX2 (by W2COMP Co., Ltd.)
+ "^pri,.*":
+ description: Priva
"^prt,.*":
description: Protonic Holland
"^pulsedlight,.*":
description: PulsedLight, Inc
"^purism,.*":
description: Purism, SPC
+ "^puya,.*":
+ description: Puya Semiconductor (Shanghai) Co., Ltd.
"^qca,.*":
description: Qualcomm Atheros, Inc.
"^qcom,.*":
@@ -1031,10 +1317,10 @@ patternProperties:
description: QEMU, a generic and open source machine emulator and virtualizer
"^qi,.*":
description: Qi Hardware
- "^qihua,.*":
- description: Chengdu Kaixuan Information Technology Co., Ltd.
"^qiaodian,.*":
description: QiaoDian XianShi Corporation
+ "^qihua,.*":
+ description: Chengdu Kaixuan Information Technology Co., Ltd.
"^qishenglong,.*":
description: Shenzhen QiShenglong Industrialist Co., Ltd.
"^qnap,.*":
@@ -1051,44 +1337,60 @@ patternProperties:
description: Ramtron International
"^raspberrypi,.*":
description: Raspberry Pi Foundation
+ "^raumfeld,.*":
+ description: Raumfeld GmbH
"^raydium,.*":
description: Raydium Semiconductor Corp.
+ "^raystar,.*":
+ description: Raystar Optronics, Inc.
"^rda,.*":
description: Unisoc Communications, Inc.
"^realtek,.*":
description: Realtek Semiconductor Corp.
+ "^relfor,.*":
+ description: Relfor Labs Pvt. Ltd.
"^remarkable,.*":
description: reMarkable AS
"^renesas,.*":
description: Renesas Electronics Corporation
- "^rex,.*":
- description: iMX6 Rex Project
"^rervision,.*":
description: Shenzhen Rervision Technology Co., Ltd.
+ "^retronix,.*":
+ description: Retronix Technology Inc.
"^revotics,.*":
description: Revolution Robotics, Inc. (Revotics)
+ "^rex,.*":
+ description: iMX6 Rex Project
"^richtek,.*":
description: Richtek Technology Corporation
"^ricoh,.*":
description: Ricoh Co. Ltd.
"^rikomagic,.*":
description: Rikomagic Tech Corp. Ltd
- "^riscv,.*":
- description: RISC-V Foundation
"^riot,.*":
description: Embest RIoT
+ "^riscv,.*":
+ description: RISC-V Foundation
"^rockchip,.*":
- description: Fuzhou Rockchip Electronics Co., Ltd
+ description: Rockchip Electronics Co., Ltd.
"^rocktech,.*":
description: ROCKTECH DISPLAYS LIMITED
"^rohm,.*":
description: ROHM Semiconductor Co., Ltd
"^ronbo,.*":
description: Ronbo Electronics
+ "^ronetix,.*":
+ description: Ronetix GmbH
"^roofull,.*":
description: Shenzhen Roofull Technology Co, Ltd
"^roseapplepi,.*":
description: RoseapplePi.org
+ "^rve,.*":
+ description: Recharge Véhicule Électrique (RVE) inc.
+ "^saef,.*":
+ description: Saef Technology Limited
+ "^sakurapi,.*":
+ description: SakuraPi.org
"^samsung,.*":
description: Samsung Semiconductor
"^samtec,.*":
@@ -1103,6 +1405,14 @@ patternProperties:
description: Smart Battery System
"^schindler,.*":
description: Schindler
+ "^schneider,.*":
+ description: Schneider Electric
+ "^schulercontrol,.*":
+ description: Schuler Group
+ "^sciosense,.*":
+ description: ScioSense B.V.
+ "^sdmc,.*":
+ description: SDMC Technology Co., Ltd
"^seagate,.*":
description: Seagate Technology PLC
"^seeed,.*":
@@ -1133,14 +1443,22 @@ patternProperties:
description: SHIFT GmbH
"^shimafuji,.*":
description: Shimafuji Electric, Inc.
+ "^shineworld,.*":
+ description: ShineWorld Innovations
"^shiratech,.*":
description: Shiratech Solutions
"^si-en,.*":
description: Si-En Technology Ltd.
"^si-linux,.*":
description: Silicon Linux Corporation
+ "^sielaff,.*":
+ description: Sielaff GmbH & Co.
+ "^siemens,.*":
+ description: Siemens AG
"^sifive,.*":
description: SiFive, Inc.
+ "^siflower,.*":
+ description: Shanghai Siflower Communication Co.
"^sigma,.*":
description: Sigma Designs, Inc.
"^sii,.*":
@@ -1161,8 +1479,8 @@ patternProperties:
description: Siliconfile Technologies lnc.
"^siliconmitus,.*":
description: Silicon Mitus, Inc.
- "^siemens,.*":
- description: Siemens AG
+ "^silvaco,.*":
+ description: Silvaco, Inc.
"^simtek,.*":
description: Cypress Semiconductor Corporation (Simtek Corporation)
"^sinlinx,.*":
@@ -1183,8 +1501,14 @@ patternProperties:
description: SKOV A/S
"^skyworks,.*":
description: Skyworks Solutions, Inc.
+ "^smartfiber,.*":
+ description: ShenZhen Smartfiber Technology Co, Ltd.
"^smartlabs,.*":
description: SmartLabs LLC
+ "^smartrg,.*":
+ description: SmartRG, Inc.
+ "^smi,.*":
+ description: Silicon Motion Technology Corporation
"^smsc,.*":
description: Standard Microsystems Corporation
"^snps,.*":
@@ -1197,8 +1521,16 @@ patternProperties:
description: SolidRun
"^solomon,.*":
description: Solomon Systech Limited
+ "^somfy,.*":
+ description: Somfy Systems Inc.
"^sony,.*":
description: Sony Corporation
+ "^sophgo,.*":
+ description: Sophgo Technology Inc.
+ "^sourceparts,.*":
+ description: Source Parts Inc.
+ "^spacemit,.*":
+ description: SpacemiT (Hangzhou) Technology Co. Ltd
"^spansion,.*":
description: Spansion Inc.
"^sparkfun,.*":
@@ -1207,6 +1539,8 @@ patternProperties:
description: SpinalHDL
"^sprd,.*":
description: Spreadtrum Communications Inc.
+ "^square,.*":
+ description: Square
"^ssi,.*":
description: SSI Computer Corp
"^sst,.*":
@@ -1222,6 +1556,8 @@ patternProperties:
description: Starry Electronic Technology (ShenZhen) Co., LTD
"^startek,.*":
description: Startek
+ "^starterkit,.*":
+ description: Starterkit
"^ste,.*":
description: ST-Ericsson
deprecated: true
@@ -1248,17 +1584,20 @@ patternProperties:
description: Sun Microsystems, Inc
"^supermicro,.*":
description: Super Micro Computer, Inc.
- "^silvaco,.*":
- description: Silvaco, Inc.
"^swir,.*":
description: Sierra Wireless
"^syna,.*":
description: Synaptics Inc.
+ "^synaptics,.*":
+ description: Synaptics Inc.
+ deprecated: true
"^synology,.*":
description: Synology, Inc.
"^synopsys,.*":
description: Synopsys, Inc. (deprecated, use snps)
deprecated: true
+ "^taos,.*":
+ description: Texas Advanced Optoelectronic Solutions Inc.
"^tbs,.*":
description: TBS Technologies
"^tbs-biometrics,.*":
@@ -1269,22 +1608,36 @@ patternProperties:
description: Toby Churchill Ltd.
"^tcs,.*":
description: Shenzhen City Tang Cheng Technology Co., Ltd.
+ "^tcu,.*":
+ description: TC Unterhaltungselektronik AG
"^tdo,.*":
description: Shangai Top Display Optoelectronics Co., Ltd
+ "^team-source-display,.*":
+ description: Shenzhen Team Source Display Technology Co., Ltd. (TSD)
"^technexion,.*":
description: TechNexion
"^technologic,.*":
description: Technologic Systems
+ "^techstar,.*":
+ description: Shenzhen Techstar Electronics Co., Ltd.
+ "^techwell,.*":
+ description: Techwell, Inc.
+ "^teejet,.*":
+ description: TeeJet
"^teltonika,.*":
description: Teltonika Networks
"^tempo,.*":
description: Tempo Semiconductor
- "^techstar,.*":
- description: Shenzhen Techstar Electronics Co., Ltd.
+ "^tenda,.*":
+ description: Shenzhen Tenda Technology Co., Ltd.
+ "^tenstorrent,.*":
+ description: Tenstorrent AI ULC
"^terasic,.*":
description: Terasic Inc.
"^tesla,.*":
description: Tesla, Inc.
+ "^test,.*":
+ description: Reserved for use by tests. For example, KUnit.
"^tfc,.*":
description: Three Five Corp
"^thead,.*":
@@ -1295,6 +1648,8 @@ patternProperties:
description: thingy.jp
"^thundercomm,.*":
description: Thundercomm Technology Co., Ltd.
+ "^thwc,.*":
+ description: Shenzhen Tong Heng Wei Chuang Technology Co., Ltd.
"^ti,.*":
description: Texas Instruments
"^tianma,.*":
@@ -1307,6 +1662,8 @@ patternProperties:
description: Topeet
"^topic,.*":
description: Topic Embedded Systems
+ "^topland,.*":
+ description: Topland Electronics (H.K) Co., Ltd.
"^toppoly,.*":
description: TPO (deprecated, use tpo)
deprecated: true
@@ -1326,6 +1683,8 @@ patternProperties:
description: TPO
"^tq,.*":
description: TQ-Systems GmbH
+ "^transpeed,.*":
+ description: Transpeed
"^traverse,.*":
description: Traverse Technologies Australia Pty Ltd
"^tronfy,.*":
@@ -1334,26 +1693,30 @@ patternProperties:
description: Tronsmart
"^truly,.*":
description: Truly Semiconductors Limited
- "^visionox,.*":
- description: Visionox
- "^team-source-display,.*":
- description: Shenzhen Team Source Display Technology Co., Ltd. (TSD)
"^tsd,.*":
description: Theobroma Systems Design und Consulting GmbH
+ "^turing,.*":
+ description: Turing Machines, Inc.
"^tyan,.*":
description: Tyan Computer Corporation
+ "^tyhx,.*":
+ description: NanjingTianyihexin Electronics Ltd.
"^u-blox,.*":
description: u-blox
"^u-boot,.*":
description: U-Boot bootloader
- "^ucrobotics,.*":
- description: uCRobotics
"^ubnt,.*":
description: Ubiquiti Networks
+ "^ucrobotics,.*":
+ description: uCRobotics
"^udoo,.*":
description: Udoo
+ "^ufispace,.*":
+ description: Ufi Space Co., Ltd.
"^ugoos,.*":
description: Ugoos Industrial Co., Ltd.
+ "^uni-t,.*":
+ description: Uni-Trend Technology (China) Co., Ltd.
"^uniwest,.*":
description: United Western Technologies Corp (UniWest)
"^upisemi,.*":
@@ -1362,12 +1725,20 @@ patternProperties:
description: United Radiant Technology Corporation
"^usi,.*":
description: Universal Scientific Industrial Co., Ltd.
+ "^usr,.*":
+ description: U.S. Robotics Corporation
+ "^ultrarisc,.*":
+ description: UltraRISC Technology Co., Ltd.
+ "^ultratronik,.*":
+ description: Ultratronik GmbH
"^utoo,.*":
description: Aigo Digital Technology Co., Ltd.
"^v3,.*":
description: V3 Semiconductor
"^vaisala,.*":
description: Vaisala
+ "^valve,.*":
+ description: Valve Corporation
"^vamrs,.*":
description: Vamrs Ltd.
"^variscite,.*":
@@ -1378,6 +1749,8 @@ patternProperties:
description: Vertexcom Technologies, Inc.
"^via,.*":
description: VIA Technologies, Inc.
+ "^vialab,.*":
+ description: VIA Labs, Inc.
"^vicor,.*":
description: Vicor Corporation
"^videostrong,.*":
@@ -1388,6 +1761,8 @@ patternProperties:
description: Used for virtual device without specific vendor.
"^vishay,.*":
description: Vishay Intertechnology, Inc
+ "^visionox,.*":
+ description: Visionox
"^vitesse,.*":
description: Vitesse Semiconductor Corporation
"^vivante,.*":
@@ -1398,10 +1773,18 @@ patternProperties:
description: VoCore Studio
"^voipac,.*":
description: Voipac Technologies s.r.o.
+ "^voltafield,.*":
+ description: Voltafield Technology Corp.
"^vot,.*":
description: Vision Optical Technology Co., Ltd.
+ "^vscom,.*":
+ description: VS Visions Systems GmbH
"^vxt,.*":
description: VXT Ltd
+ "^wacom,.*":
+ description: Wacom
+ "^wanchanglong,.*":
+ description: Wanchanglong Electronics Technology(SHENZHEN)Co.,Ltd.
"^wand,.*":
description: Wandbord (Technexion)
"^waveshare,.*":
@@ -1420,6 +1803,8 @@ patternProperties:
description: Shenzhen whwave Electronics, Inc.
"^wi2wi,.*":
description: Wi2Wi, Inc.
+ "^widora,.*":
+ description: Beijing Widora Technology Co., Ltd.
"^wiligear,.*":
description: Wiligear, Ltd.
"^willsemi,.*":
@@ -1430,6 +1815,8 @@ patternProperties:
description: Wingtech Technology Co., Ltd.
"^winlink,.*":
description: WinLink Co., Ltd
+ "^winsen,.*":
+ description: Winsen Corp.
"^winstar,.*":
description: Winstar Display Corp.
"^wirelesstag,.*":
@@ -1442,8 +1829,8 @@ patternProperties:
description: Wondermedia Technologies, Inc.
"^wobo,.*":
description: Wobo
- "^wanchanglong,.*":
- description: Wanchanglong Electronics Technology(SHENZHEN)Co.,Ltd.
+ "^wolfvision,.*":
+ description: WolfVision GmbH
"^x-powers,.*":
description: X-Powers
"^xen,.*":
@@ -1452,6 +1839,8 @@ patternProperties:
description: Extreme Engineering Solutions (X-ES)
"^xiaomi,.*":
description: Xiaomi Technology Co., Ltd.
+ "^xicor,.*":
+ description: Xicor Inc.
"^xillybus,.*":
description: Xillybus Ltd.
"^xingbangda,.*":
@@ -1476,6 +1865,8 @@ patternProperties:
description: Yes Optoelectronics Co.,Ltd.
"^yic,.*":
description: YIC System Co., Ltd.
+ "^yiming,.*":
+ description: Henan Yiming Technology Co., Ltd.
"^ylm,.*":
description: Shenzhen Yangliming Electronic Technology Co., Ltd.
"^yna,.*":
@@ -1486,10 +1877,14 @@ patternProperties:
description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd.
"^ysoft,.*":
description: Y Soft Corporation a.s.
- "^zealz,.*":
- description: Zealz
+ "^yuridenki,.*":
+ description: Yuridenki-Shokai Co. Ltd.
+ "^yuzukihd,.*":
+ description: YuzukiHD Open Source Hardware
"^zarlink,.*":
description: Zarlink Semiconductor
+ "^zealz,.*":
+ description: Zealz
"^zeitec,.*":
description: ZEITEC Semiconductor Co., LTD.
"^zidoo,.*":
@@ -1507,7 +1902,7 @@ patternProperties:
# Normal property name match without a comma
# These should catch all node/property names without a prefix
- "^[a-zA-Z0-9#_][a-zA-Z0-9+\\-._@]{0,63}$": true
+ "^[a-zA-Z0-9#_][a-zA-Z0-9#+\\-._@]{0,63}$": true
"^[a-zA-Z0-9+\\-._]*@[0-9a-zA-Z,]*$": true
"^#.*": true
diff --git a/Documentation/devicetree/bindings/virtio/iommu.txt b/Documentation/devicetree/bindings/virtio/iommu.txt
deleted file mode 100644
index 2407fea0651c..000000000000
--- a/Documentation/devicetree/bindings/virtio/iommu.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-* virtio IOMMU PCI device
-
-When virtio-iommu uses the PCI transport, its programming interface is
-discovered dynamically by the PCI probing infrastructure. However the
-device tree statically describes the relation between IOMMU and DMA
-masters. Therefore, the PCI root complex that hosts the virtio-iommu
-contains a child node representing the IOMMU device explicitly.
-
-Required properties:
-
-- compatible: Should be "virtio,pci-iommu"
-- reg: PCI address of the IOMMU. As defined in the PCI Bus
- Binding reference [1], the reg property is a five-cell
- address encoded as (phys.hi phys.mid phys.lo size.hi
- size.lo). phys.hi should contain the device's BDF as
- 0b00000000 bbbbbbbb dddddfff 00000000. The other cells
- should be zero.
-- #iommu-cells: Each platform DMA master managed by the IOMMU is assigned
- an endpoint ID, described by the "iommus" property [2].
- For virtio-iommu, #iommu-cells must be 1.
-
-Notes:
-
-- DMA from the IOMMU device isn't managed by another IOMMU. Therefore the
- virtio-iommu node doesn't have an "iommus" property, and is omitted from
- the iommu-map property of the root complex.
-
-Example:
-
-pcie@10000000 {
- compatible = "pci-host-ecam-generic";
- ...
-
- /* The IOMMU programming interface uses slot 00:01.0 */
- iommu0: iommu@0008 {
- compatible = "virtio,pci-iommu";
- reg = <0x00000800 0 0 0 0>;
- #iommu-cells = <1>;
- };
-
- /*
- * The IOMMU manages all functions in this PCI domain except
- * itself. Omit BDF 00:01.0.
- */
- iommu-map = <0x0 &iommu0 0x0 0x8>
- <0x9 &iommu0 0x9 0xfff7>;
-};
-
-pcie@20000000 {
- compatible = "pci-host-ecam-generic";
- ...
- /*
- * The IOMMU also manages all functions from this domain,
- * with endpoint IDs 0x10000 - 0x1ffff
- */
- iommu-map = <0x0 &iommu0 0x10000 0x10000>;
-};
-
-ethernet@fe001000 {
- ...
- /* The IOMMU manages this platform device with endpoint ID 0x20000 */
- iommus = <&iommu0 0x20000>;
-};
-
-[1] Documentation/devicetree/bindings/pci/pci.txt
-[2] Documentation/devicetree/bindings/iommu/iommu.txt
diff --git a/Documentation/devicetree/bindings/virtio/pci-iommu.yaml b/Documentation/devicetree/bindings/virtio/pci-iommu.yaml
new file mode 100644
index 000000000000..8bd6ad72ac7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/virtio/pci-iommu.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/virtio/pci-iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: virtio-iommu device using the virtio-pci transport
+
+maintainers:
+ - Jean-Philippe Brucker <jean-philippe@linaro.org>
+
+description: |
+ When virtio-iommu uses the PCI transport, its programming interface is
+ discovered dynamically by the PCI probing infrastructure. However the
+ device tree statically describes the relation between IOMMU and DMA
+ masters. Therefore, the PCI root complex that hosts the virtio-iommu
+ contains a child node representing the IOMMU device explicitly.
+
+ DMA from the IOMMU device isn't managed by another IOMMU. Therefore the
+ virtio-iommu node doesn't have an "iommus" property, and is omitted from
+ the iommu-map property of the root complex.
+
+allOf:
+ - $ref: /schemas/pci/pci-device.yaml#
+
+properties:
+ # If compatible is present, it should contain the vendor and device ID
+ # according to the PCI Bus Binding specification. Since PCI provides
+ # built-in identification methods, compatible is not actually required.
+ compatible:
+ oneOf:
+ - items:
+ - const: virtio,pci-iommu
+ - const: pci1af4,1057
+ - items:
+ - const: pci1af4,1057
+
+ reg:
+ maxItems: 1
+
+ '#iommu-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#iommu-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie@40000000 {
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0x0 0x40000000 0x0 0x1000000>;
+ ranges = <0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x0f000000>;
+
+ /*
+ * The IOMMU manages all functions in this PCI domain except
+ * itself. Omit BDF 00:01.0.
+ */
+ iommu-map = <0x0 &iommu0 0x0 0x8
+ 0x9 &iommu0 0x9 0xfff7>;
+
+ /* The IOMMU programming interface uses slot 00:01.0 */
+ iommu0: iommu@1,0 {
+ compatible = "pci1af4,1057";
+ reg = <0x800 0 0 0 0>;
+ #iommu-cells = <1>;
+ };
+ };
+
+ pcie@50000000 {
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ reg = <0x0 0x50000000 0x0 0x1000000>;
+ ranges = <0x02000000 0x0 0x51000000 0x0 0x51000000 0x0 0x0f000000>;
+
+ /*
+ * The IOMMU also manages all functions from this domain,
+ * with endpoint IDs 0x10000 - 0x1ffff
+ */
+ iommu-map = <0x0 &iommu0 0x10000 0x10000>;
+ };
+
+ ethernet {
+ /* The IOMMU manages this platform device with endpoint ID 0x20000 */
+ iommus = <&iommu0 0x20000>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/virtio/virtio-device.yaml b/Documentation/devicetree/bindings/virtio/virtio-device.yaml
index 1778ea9b5aa5..8c6919ba9497 100644
--- a/Documentation/devicetree/bindings/virtio/virtio-device.yaml
+++ b/Documentation/devicetree/bindings/virtio/virtio-device.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/virtio/virtio-device.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Virtio device bindings
+title: Virtio device
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
diff --git a/Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml b/Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml
new file mode 100644
index 000000000000..ef70fa2c0c5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/amd,axi-1wire-host.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/w1/amd,axi-1wire-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AMD AXI 1-wire bus host for programmable logic
+
+maintainers:
+ - Kris Chaplin <kris.chaplin@amd.com>
+
+properties:
+ compatible:
+ const: amd,axi-1wire-host
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ onewire@a0000000 {
+ compatible = "amd,axi-1wire-host";
+ reg = <0xa0000000 0x10000>;
+ clocks = <&zynqmp_clk 0x47>;
+ interrupts = <GIC_SPI 0x59 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/w1/fsl-imx-owire.yaml b/Documentation/devicetree/bindings/w1/fsl-imx-owire.yaml
index 55adea827c34..2c1bbc0eb05a 100644
--- a/Documentation/devicetree/bindings/w1/fsl-imx-owire.yaml
+++ b/Documentation/devicetree/bindings/w1/fsl-imx-owire.yaml
@@ -24,6 +24,9 @@ properties:
reg:
maxItems: 1
+ interrupts:
+ maxItems: 1
+
clocks:
maxItems: 1
@@ -40,5 +43,6 @@ examples:
owire@63fa4000 {
compatible = "fsl,imx53-owire", "fsl,imx21-owire";
reg = <0x63fa4000 0x4000>;
+ interrupts = <88>;
clocks = <&clks IMX5_CLK_OWIRE_GATE>;
};
diff --git a/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml b/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml
new file mode 100644
index 000000000000..fe6b3f9a3f8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/w1/maxim,ds2482.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim One wire bus master controller
+
+maintainers:
+ - Stefan Wahren <stefan.wahren@chargebyte.com>
+
+description: |
+ I2C to 1-wire bridges
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ds2482-100.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/DS2482-800.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/DS2484.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,ds2482
+ - maxim,ds2484
+
+ reg:
+ maxItems: 1
+
+ vcc-supply: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ onewire@18 {
+ compatible = "maxim,ds2484";
+ reg = <0x18>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/w1/w1-gpio.yaml b/Documentation/devicetree/bindings/w1/w1-gpio.yaml
index 8eef2380161b..b02b02237082 100644
--- a/Documentation/devicetree/bindings/w1/w1-gpio.yaml
+++ b/Documentation/devicetree/bindings/w1/w1-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/w1/w1-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Bitbanged GPIO 1-Wire Bus Device Tree Bindings
+title: Bitbanged GPIO 1-Wire Bus
maintainers:
- Daniel Mack <zonque@gmail.com>
diff --git a/Documentation/devicetree/bindings/w1/w1-uart.yaml b/Documentation/devicetree/bindings/w1/w1-uart.yaml
new file mode 100644
index 000000000000..bd7c62d780b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/w1-uart.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/w1/w1-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UART 1-Wire Bus
+
+maintainers:
+ - Christoph Winklhofer <cj.winklhofer@gmail.com>
+
+description: |
+ UART 1-wire bus. Utilizes the UART interface via the Serial Device Bus
+ to create the 1-Wire timing patterns.
+
+ The UART peripheral must support full-duplex and operate in open-drain
+ mode. The timing patterns are generated by a specific combination of
+ baud-rate and transmitted byte, which corresponds to a 1-Wire read bit,
+ write bit or reset pulse.
+
+ The default baud-rate for reset and presence detection is 9600 and for
+ a 1-Wire read or write operation 115200. In case the actual baud-rate
+ is different from the requested one, the transmitted byte is adapted
+ to generate the 1-Wire timing patterns.
+
+ https://www.analog.com/en/technical-articles/using-a-uart-to-implement-a-1wire-bus-master.html
+
+properties:
+ compatible:
+ const: w1-uart
+
+ reset-bps:
+ default: 9600
+ description:
+ The baud rate for the 1-Wire reset and presence detect.
+
+ write-0-bps:
+ default: 115200
+ description:
+ The baud rate for the 1-Wire write-0 cycle.
+
+ write-1-bps:
+ default: 115200
+ description:
+ The baud rate for the 1-Wire write-1 and read cycle.
+
+required:
+ - compatible
+
+additionalProperties:
+ type: object
+
+examples:
+ - |
+ serial {
+ onewire {
+ compatible = "w1-uart";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/airoha,en7581-wdt.yaml b/Documentation/devicetree/bindings/watchdog/airoha,en7581-wdt.yaml
new file mode 100644
index 000000000000..6259478bdae5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/airoha,en7581-wdt.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/airoha,en7581-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Airoha EN7581 Watchdog Timer
+
+maintainers:
+ - Christian Marangi <ansuelsmth@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: airoha,an7583-wdt
+ - const: airoha,en7581-wdt
+ - const: airoha,en7581-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: BUS clock (timer ticks at half the BUS clock)
+ maxItems: 1
+
+ clock-names:
+ const: bus
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/en7523-clk.h>
+
+ watchdog@1fbf0100 {
+ compatible = "airoha,en7581-wdt";
+ reg = <0x1fbf0100 0x3c>;
+
+ clocks = <&scuclk EN7523_CLK_BUS>;
+ clock-names = "bus";
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
index ed6c1ca80dcc..b35ac03d5172 100644
--- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
@@ -4,15 +4,15 @@
$id: http://devicetree.org/schemas/watchdog/allwinner,sun4i-a10-wdt.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Allwinner A10 Watchdog Device Tree Bindings
-
-allOf:
- - $ref: "watchdog.yaml#"
+title: Allwinner A10 Watchdog
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
oneOf:
@@ -32,6 +32,7 @@ properties:
- items:
- const: allwinner,sun20i-d1-wdt-reset
- const: allwinner,sun20i-d1-wdt
+ - const: allwinner,sun55i-a523-wdt
reg:
maxItems: 1
@@ -60,6 +61,7 @@ if:
- allwinner,sun20i-d1-wdt-reset
- allwinner,sun50i-r329-wdt
- allwinner,sun50i-r329-wdt-reset
+ - allwinner,sun55i-a523-wdt
then:
properties:
diff --git a/Documentation/devicetree/bindings/watchdog/alphascale,asm9260-wdt.yaml b/Documentation/devicetree/bindings/watchdog/alphascale,asm9260-wdt.yaml
new file mode 100644
index 000000000000..6425fe51d20c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/alphascale,asm9260-wdt.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/alphascale,asm9260-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Alphascale asm9260 Watchdog timer
+
+maintainers:
+ - Oleksij Rempel <linux@rempel-privat.de>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: alphascale,asm9260-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: source clock, used for tick counter
+ - description: ahb gate
+
+ clock-names:
+ items:
+ - const: mod
+ - const: ahb
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: wdt_rst
+
+ alphascale,mode:
+ description: |
+ Specifies the reset mode of operation. If set to sw, then reset is handled
+ via interrupt request, if set to debug, then it does nothing and logs.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [hw, sw, debug]
+ default: hw
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/alphascale,asm9260.h>
+ watchdog0: watchdog@80048000 {
+ compatible = "alphascale,asm9260-wdt";
+ reg = <0x80048000 0x10>;
+ clocks = <&acc CLKID_SYS_WDT>, <&acc CLKID_AHB_WDT>;
+ clock-names = "mod", "ahb";
+ interrupts = <55>;
+ timeout-sec = <30>;
+ alphascale,mode = "hw";
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt b/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
deleted file mode 100644
index 75b265a04047..000000000000
--- a/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Alphascale asm9260 Watchdog timer
-
-Required properties:
-
-- compatible : should be "alphascale,asm9260-wdt".
-- reg : Specifies base physical address and size of the registers.
-- clocks : the clocks feeding the watchdog timer. See clock-bindings.txt
-- clock-names : should be set to
- "mod" - source for tick counter.
- "ahb" - ahb gate.
-- resets : phandle pointing to the system reset controller with
- line index for the watchdog.
-- reset-names : should be set to "wdt_rst".
-
-Optional properties:
-- timeout-sec : shall contain the default watchdog timeout in seconds,
- if unset, the default timeout is 30 seconds.
-- alphascale,mode : three modes are supported
- "hw" - hw reset (default).
- "sw" - sw reset.
- "debug" - no action is taken.
-
-Example:
-
-watchdog0: watchdog@80048000 {
- compatible = "alphascale,asm9260-wdt";
- reg = <0x80048000 0x10>;
- clocks = <&acc CLKID_SYS_WDT>, <&acc CLKID_AHB_WDT>;
- clock-names = "mod", "ahb";
- interrupts = <55>;
- resets = <&rst WDT_RESET>;
- reset-names = "wdt_rst";
- timeout-sec = <30>;
- alphascale,mode = "hw";
-};
diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
index 497d60408ea0..d0eff1ea52b4 100644
--- a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
@@ -2,8 +2,8 @@
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/watchdog/amlogic,meson-gxbb-wdt.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/watchdog/amlogic,meson-gxbb-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Meson GXBB SoCs Watchdog timer
@@ -15,8 +15,16 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson-gxbb-wdt
+ oneOf:
+ - enum:
+ - amlogic,meson-gxbb-wdt
+ - amlogic,t7-wdt
+ - items:
+ - enum:
+ - amlogic,a4-wdt
+ - amlogic,c3-wdt
+ - amlogic,s4-wdt
+ - const: amlogic,t7-wdt
reg:
maxItems: 1
@@ -36,7 +44,7 @@ unevaluatedProperties: false
examples:
- |
watchdog@98d0 {
- compatible = "amlogic,meson-gxbb-wdt";
- reg = <0x98d0 0x10>;
- clocks = <&xtal>;
+ compatible = "amlogic,meson-gxbb-wdt";
+ reg = <0x98d0 0x10>;
+ clocks = <&xtal>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml
new file mode 100644
index 000000000000..84732cb58ec4
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson6-wdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/amlogic,meson6-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Meson6 SoCs Watchdog timer
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - amlogic,meson6-wdt
+ - amlogic,meson8-wdt
+ - amlogic,meson8b-wdt
+ - items:
+ - const: amlogic,meson8m2-wdt
+ - const: amlogic,meson8b-wdt
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ wdt: watchdog@c1109900 {
+ compatible = "amlogic,meson6-wdt";
+ reg = <0xc1109900 0x8>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_EDGE_RISING>;
+ timeout-sec = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
index e58c56a6fdf6..05602678c070 100644
--- a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
@@ -6,19 +6,30 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple SoC Watchdog
-allOf:
- - $ref: "watchdog.yaml#"
-
maintainers:
- Sven Peter <sven@svenpeter.dev>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
- items:
- - enum:
- - apple,t8103-wdt
- - apple,t6000-wdt
- - const: apple,wdt
+ oneOf:
+ - items:
+ - const: apple,t6020-wdt
+ - const: apple,t8103-wdt
+ - items:
+ - enum:
+ # Do not add additional SoC to this list.
+ - apple,s5l8960x-wdt
+ - apple,t7000-wdt
+ - apple,s8000-wdt
+ - apple,t8010-wdt
+ - apple,t8015-wdt
+ - apple,t8103-wdt
+ - apple,t8112-wdt
+ - apple,t6000-wdt
+ - const: apple,wdt
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml
index 6bfa46353c4e..aa804f96acba 100644
--- a/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml
@@ -40,7 +40,6 @@ unevaluatedProperties: false
examples:
- |
-
watchdog@2a440000 {
compatible = "arm,sbsa-gwdt";
reg = <0x2a440000 0x1000>,
diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.yaml b/Documentation/devicetree/bindings/watchdog/arm,sp805.yaml
index a69cac8ec208..bd7c09ed1938 100644
--- a/Documentation/devicetree/bindings/watchdog/arm,sp805.yaml
+++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.yaml
@@ -43,7 +43,6 @@ properties:
Clocks driving the watchdog timer hardware. The first clock is used
for the actual watchdog counter. The second clock drives the register
interface.
- minItems: 2
maxItems: 2
clock-names:
@@ -51,6 +50,10 @@ properties:
- const: wdog_clk
- const: apb_pclk
+ resets:
+ maxItems: 1
+ description: WDOGRESn input reset signal for sp805 module.
+
required:
- compatible
- reg
@@ -68,4 +71,5 @@ examples:
interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&wdt_clk>, <&apb_pclk>;
clock-names = "wdog_clk", "apb_pclk";
+ resets = <&wdt_rst>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml
index bb8901854222..9646ac72051e 100644
--- a/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml
@@ -44,7 +44,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
watchdog@2c000620 {
- compatible = "arm,arm11mp-twd-wdt";
- reg = <0x2c000620 0x20>;
- interrupts = <GIC_PPI 14 0xf01>;
+ compatible = "arm,arm11mp-twd-wdt";
+ reg = <0x2c000620 0x20>;
+ interrupts = <GIC_PPI 14 0xf01>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
index e3a1d79574e2..8e9d0b7e8244 100644
--- a/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
@@ -6,16 +6,17 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Secure Monitor Call based watchdog
-allOf:
- - $ref: "watchdog.yaml#"
-
maintainers:
- Julius Werner <jwerner@chromium.org>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
enum:
- arm,smc-wdt
+
arm,smc-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -30,9 +31,9 @@ unevaluatedProperties: false
examples:
- |
watchdog {
- compatible = "arm,smc-wdt";
- arm,smc-id = <0x82003D06>;
- timeout-sec = <15>;
+ compatible = "arm,smc-wdt";
+ arm,smc-id = <0x82003D06>;
+ timeout-sec = <15>;
};
...
diff --git a/Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt b/Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt
deleted file mode 100644
index a8d00c31a1d8..000000000000
--- a/Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-* Armada 37xx CPU Watchdog Timer Controller
-
-Required properties:
-- compatible : must be "marvell,armada-3700-wdt"
-- reg : base physical address of the controller and length of memory mapped
- region.
-- clocks : the clock feeding the watchdog timer. See clock-bindings.txt
-- marvell,system-controller : reference to syscon node for the CPU Miscellaneous
- Registers
-
-Example:
-
- cpu_misc: system-controller@d000 {
- compatible = "marvell,armada-3700-cpu-misc", "syscon";
- reg = <0xd000 0x1000>;
- };
-
- wdt: watchdog@8300 {
- compatible = "marvell,armada-3700-wdt";
- reg = <0x8300 0x40>;
- marvell,system-controller = <&cpu_misc>;
- clocks = <&xtalclk>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
new file mode 100644
index 000000000000..9322cb5b462a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/aspeed,ast2400-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Aspeed watchdog timer controllers
+
+maintainers:
+ - Andrew Jeffery <andrew@codeconstruct.com.au>
+
+properties:
+ compatible:
+ enum:
+ - aspeed,ast2400-wdt
+ - aspeed,ast2500-wdt
+ - aspeed,ast2600-wdt
+ - aspeed,ast2700-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: >
+ The clock used to drive the watchdog counter. From the AST2500 no source
+ other than the 1MHz clock can be selected, so the clocks property is
+ optional.
+
+ aspeed,reset-type:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - cpu
+ - soc
+ - system
+ - none
+ default: system
+ description: >
+ The watchdog can be programmed to generate one of three different types of
+ reset when a timeout occcurs.
+
+ Specifying 'cpu' will only reset the processor on a timeout event.
+
+ Specifying 'soc' will reset a configurable subset of the SoC's controllers
+ on a timeout event. Controllers critical to the SoC's operation may remain
+ untouched. The set of SoC controllers to reset may be specified via the
+ aspeed,reset-mask property if the node has the aspeed,ast2500-wdt or
+ aspeed,ast2600-wdt compatible.
+
+ Specifying 'system' will reset all controllers on a timeout event, as if
+ EXTRST had been asserted.
+
+ Specifying 'none' will cause the timeout event to have no reset effect.
+ Another watchdog engine on the chip must be used for chip reset operations.
+
+ aspeed,alt-boot:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: >
+ Direct the watchdog to configure the SoC to boot from the alternative boot
+ region if a timeout occurs.
+
+ aspeed,external-signal:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: >
+ Assert the timeout event on an external signal pin associated with the
+ watchdog controller instance. The pin must be muxed appropriately.
+
+ aspeed,ext-pulse-duration:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: >
+ The duration, in microseconds, of the pulse emitted on the external signal
+ pin.
+
+ aspeed,ext-push-pull:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: >
+ If aspeed,external-signal is specified in the node, set the external
+ signal pin's drive type to push-pull. If aspeed,ext-push-pull is not
+ specified then the pin is configured as open-drain.
+
+ aspeed,ext-active-high:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: >
+ If both aspeed,external-signal and aspeed,ext-push-pull are specified in
+ the node, set the pulse polarity to active-high. If aspeed,ext-active-high
+ is not specified then the pin is configured as active-low.
+
+ aspeed,reset-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 5
+ description: >
+ A bitmask indicating which peripherals will be reset if the watchdog
+ timer expires. On AST2500 SoCs this should be a single word defined using
+ the AST2500_WDT_RESET_* macros; on AST2600 SoCs this should be a two-word
+ array with the first word defined using the AST2600_WDT_RESET1_* macros,
+ and the second word defined using the AST2600_WDT_RESET2_* macros; on
+ AST2700 SoCs, this should be five-word array from AST2700_WDT_RESET1_*
+ macros to AST2700_WDT_RESET5_* macros.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ anyOf:
+ - required:
+ - aspeed,ext-push-pull
+ - required:
+ - aspeed,ext-active-high
+ - required:
+ - aspeed,reset-mask
+ then:
+ properties:
+ compatible:
+ enum:
+ - aspeed,ast2500-wdt
+ - aspeed,ast2600-wdt
+ - aspeed,ast2700-wdt
+ - if:
+ required:
+ - aspeed,ext-active-high
+ then:
+ required:
+ - aspeed,ext-push-pull
+
+additionalProperties: false
+
+examples:
+ - |
+ watchdog@1e785000 {
+ compatible = "aspeed,ast2400-wdt";
+ reg = <0x1e785000 0x1c>;
+ aspeed,reset-type = "system";
+ aspeed,external-signal;
+ };
+ - |
+ #include <dt-bindings/watchdog/aspeed-wdt.h>
+ watchdog@1e785040 {
+ compatible = "aspeed,ast2600-wdt";
+ reg = <0x1e785040 0x40>;
+ aspeed,reset-type = "soc";
+ aspeed,reset-mask = <AST2600_WDT_RESET1_DEFAULT
+ (AST2600_WDT_RESET2_DEFAULT & ~AST2600_WDT_RESET2_LPC)>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
deleted file mode 100644
index a8197632d6d2..000000000000
--- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Aspeed Watchdog Timer
-
-Required properties:
- - compatible: must be one of:
- - "aspeed,ast2400-wdt"
- - "aspeed,ast2500-wdt"
- - "aspeed,ast2600-wdt"
-
- - reg: physical base address of the controller and length of memory mapped
- region
-
-Optional properties:
-
- - aspeed,reset-type = "cpu|soc|system|none"
-
- Reset behavior - Whenever a timeout occurs the watchdog can be programmed
- to generate one of three different, mutually exclusive, types of resets.
-
- Type "none" can be specified to indicate that no resets are to be done.
- This is useful in situations where another watchdog engine on chip is
- to perform the reset.
-
- If 'aspeed,reset-type=' is not specified the default is to enable system
- reset.
-
- Reset types:
-
- - cpu: Reset CPU on watchdog timeout
-
- - soc: Reset 'System on Chip' on watchdog timeout
-
- - system: Reset system on watchdog timeout
-
- - none: No reset is performed on timeout. Assumes another watchdog
- engine is responsible for this.
-
- - aspeed,alt-boot: If property is present then boot from alternate block.
- - aspeed,external-signal: If property is present then signal is sent to
- external reset counter (only WDT1 and WDT2). If not
- specified no external signal is sent.
- - aspeed,ext-pulse-duration: External signal pulse duration in microseconds
-
-Optional properties for AST2500-compatible watchdogs:
- - aspeed,ext-push-pull: If aspeed,external-signal is present, set the pin's
- drive type to push-pull. The default is open-drain.
- - aspeed,ext-active-high: If aspeed,external-signal is present and and the pin
- is configured as push-pull, then set the pulse
- polarity to active-high. The default is active-low.
-
-Example:
-
- wdt1: watchdog@1e785000 {
- compatible = "aspeed,ast2400-wdt";
- reg = <0x1e785000 0x1c>;
- aspeed,reset-type = "system";
- aspeed,external-signal;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/atmel,at91rm9200-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,at91rm9200-wdt.yaml
new file mode 100644
index 000000000000..7af3571d89f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/atmel,at91rm9200-wdt.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/atmel,at91rm9200-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel AT91RM9200 System Timer Watchdog
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: atmel,at91rm9200-wdt
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@fffffd00 {
+ compatible = "atmel,at91rm9200-wdt";
+ reg = <0xfffffd00 0x10>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/atmel,at91sam9-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,at91sam9-wdt.yaml
new file mode 100644
index 000000000000..ad27bc518670
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/atmel,at91sam9-wdt.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/atmel,at91sam9-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Watchdog Timers
+
+maintainers:
+ - Eugen Hristev <eugen.hristev@microchip.com>
+
+properties:
+ compatible:
+ const: atmel,at91sam9260-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ atmel,max-heartbeat-sec:
+ description:
+ Should contain the maximum heartbeat value in seconds. This value
+ should be less or equal to 16. It is used to compute the WDV field.
+ maximum: 16
+
+ atmel,min-heartbeat-sec:
+ description:
+ Should contain the minimum heartbeat value in seconds. This value
+ must be smaller than the max-heartbeat-sec value. It is used to
+ compute the WDD field.
+ maximum: 16
+
+ atmel,watchdog-type:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Should be hardware or software.
+ oneOf:
+ - description:
+ Hardware watchdog uses the at91 watchdog reset.
+ const: hardware
+ - description: |
+ Software watchdog uses the watchdog interrupt
+ to trigger a software reset.
+ const: software
+ default: hardware
+
+ atmel,reset-type:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: |
+ Should be proc or all. This is valid only when using hardware watchdog.
+ oneOf:
+ - description:
+ Assert peripherals and processor reset signals.
+ const: all
+ - description:
+ Assert the processor reset signal.
+ const: proc
+ default: all
+
+ atmel,disable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Should be present if you want to stop the watchdog.
+
+ atmel,idle-halt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Should be present if you want to stop the watchdog when
+ entering idle state.
+ CAUTION: This property should be used with care, it actually makes the
+ watchdog not counting when the CPU is in idle state, therefore the
+ watchdog reset time depends on mean CPU usage and will not reset at all
+ if the CPU stops working while it is in idle state, which is probably
+ not what you want.
+
+ atmel,dbg-halt:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ Should be present if you want to stop the watchdog when
+ entering debug state.
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - $ref: watchdog.yaml#
+ - if:
+ properties:
+ atmel,reset-type:
+ enum:
+ - all
+ - proc
+ then:
+ properties:
+ atmel,watchdog-type:
+ const: hardware
+
+dependencies:
+ atmel,reset-type: ['atmel,watchdog-type']
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ watchdog@fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <&clk32k>;
+ timeout-sec = <15>;
+ atmel,watchdog-type = "hardware";
+ atmel,reset-type = "all";
+ atmel,dbg-halt;
+ atmel,idle-halt;
+ atmel,max-heartbeat-sec = <16>;
+ atmel,min-heartbeat-sec = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml
index a9635c03761c..cdf87db36183 100644
--- a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml
@@ -10,14 +10,18 @@ maintainers:
- Eugen Hristev <eugen.hristev@microchip.com>
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
properties:
compatible:
- enum:
- - atmel,sama5d4-wdt
- - microchip,sam9x60-wdt
- - microchip,sama7g5-wdt
+ oneOf:
+ - enum:
+ - atmel,sama5d4-wdt
+ - microchip,sam9x60-wdt
+ - microchip,sama7g5-wdt
+ - items:
+ - const: microchip,sam9x7-wdt
+ - const: microchip,sam9x60-wdt
reg:
maxItems: 1
@@ -65,13 +69,13 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
watchdog@fc068640 {
- compatible = "atmel,sama5d4-wdt";
- reg = <0xfc068640 0x10>;
- interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>;
- timeout-sec = <10>;
- atmel,watchdog-type = "hardware";
- atmel,dbg-halt;
- atmel,idle-halt;
+ compatible = "atmel,sama5d4-wdt";
+ reg = <0xfc068640 0x10>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>;
+ timeout-sec = <10>;
+ atmel,watchdog-type = "hardware";
+ atmel,dbg-halt;
+ atmel,idle-halt;
};
...
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
deleted file mode 100644
index d4d86cf8f9eb..000000000000
--- a/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-Atmel AT91RM9200 System Timer Watchdog
-
-Required properties:
-- compatible: must be "atmel,at91sam9260-wdt".
-
-Example:
- watchdog@fffffd00 {
- compatible = "atmel,at91rm9200-wdt";
- };
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
deleted file mode 100644
index 711a880b3d3b..000000000000
--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-* Atmel Watchdog Timers
-
-** at91sam9-wdt
-
-Required properties:
-- compatible: must be "atmel,at91sam9260-wdt".
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: phandle to input clock.
-
-Optional properties:
-- timeout-sec: contains the watchdog timeout in seconds.
-- interrupts : Should contain WDT interrupt.
-- atmel,max-heartbeat-sec : Should contain the maximum heartbeat value in
- seconds. This value should be less or equal to 16. It is used to
- compute the WDV field.
-- atmel,min-heartbeat-sec : Should contain the minimum heartbeat value in
- seconds. This value must be smaller than the max-heartbeat-sec value.
- It is used to compute the WDD field.
-- atmel,watchdog-type : Should be "hardware" or "software". Hardware watchdog
- use the at91 watchdog reset. Software watchdog use the watchdog
- interrupt to trigger a software reset.
-- atmel,reset-type : Should be "proc" or "all".
- "all" : assert peripherals and processor reset signals
- "proc" : assert the processor reset signal
- This is valid only when using "hardware" watchdog.
-- atmel,disable : Should be present if you want to disable the watchdog.
-- atmel,idle-halt : Should be present if you want to stop the watchdog when
- entering idle state.
- CAUTION: This property should be used with care, it actually makes the
- watchdog not counting when the CPU is in idle state, therefore the
- watchdog reset time depends on mean CPU usage and will not reset at all
- if the CPU stop working while it is in idle state, which is probably
- not what you want.
-- atmel,dbg-halt : Should be present if you want to stop the watchdog when
- entering debug state.
-
-Example:
- watchdog@fffffd40 {
- compatible = "atmel,at91sam9260-wdt";
- reg = <0xfffffd40 0x10>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
- clocks = <&clk32k>;
- timeout-sec = <15>;
- atmel,watchdog-type = "hardware";
- atmel,reset-type = "all";
- atmel,dbg-halt;
- atmel,idle-halt;
- atmel,max-heartbeat-sec = <16>;
- atmel,min-heartbeat-sec = <0>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
deleted file mode 100644
index f801d71de1cd..000000000000
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-BCM2835 Watchdog timer
-
-Required properties:
-
-- compatible : should be "brcm,bcm2835-pm-wdt"
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-
-- timeout-sec : Contains the watchdog timeout in seconds
-
-Example:
-
-watchdog {
- compatible = "brcm,bcm2835-pm-wdt";
- reg = <0x7e100000 0x28>;
- timeout-sec = <10>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
index a926809352b8..e898167ef628 100644
--- a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
@@ -6,14 +6,14 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: BCM63xx and BCM7038 watchdog timer
-allOf:
- - $ref: "watchdog.yaml#"
-
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
- Justin Chen <justinpopo6@gmail.com>
- Rafał Miłecki <rafal@milecki.pl>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
enum:
@@ -29,15 +29,15 @@ properties:
The clock running the watchdog. If no clock is found the driver will
default to 27000000 Hz.
-unevaluatedProperties: false
-
required:
- reg
+unevaluatedProperties: false
+
examples:
- |
watchdog@f040a7e8 {
- compatible = "brcm,bcm7038-wdt";
- reg = <0xf040a7e8 0x16>;
- clocks = <&upg_fixed>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0xf040a7e8 0x16>;
+ clocks = <&upg_fixed>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt
deleted file mode 100644
index 2b86a00e351d..000000000000
--- a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Broadcom Kona Family Watchdog Timer
------------------------------------
-
-This watchdog timer is used in the following Broadcom SoCs:
- BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
-
-Required properties:
- - compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
- - reg: memory address & range
-
-Example:
- watchdog@35002f40 {
- compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
- reg = <0x35002f40 0x6c>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml
new file mode 100644
index 000000000000..3d4403b41cbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,kona-wdt.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/brcm,kona-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Kona Family Watchdog Timer
+
+description: |
+ This watchdog timer is used in the following Broadcom SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+maintainers:
+ - Florian Fainelli <f.fainelli@gmail.com>
+ - Ray Jui <rjui@broadcom.com>
+ - Scott Branden <sbranden@broadcom.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: brcm,bcm11351-wdt
+ - const: brcm,kona-wdt
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@35002f40 {
+ compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
+ reg = <0x35002f40 0x6c>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt b/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt
deleted file mode 100644
index 750a87657448..000000000000
--- a/Documentation/devicetree/bindings/watchdog/cadence-wdt.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Zynq Watchdog Device Tree Bindings
--------------------------------------------
-
-Required properties:
-- compatible : Should be "cdns,wdt-r1p2".
-- clocks : This is pclk (APB clock).
-- interrupts : This is wd_irq - watchdog timeout interrupt.
-
-Optional properties
-- reset-on-timeout : If this property exists, then a reset is done
- when watchdog times out.
-- timeout-sec : Watchdog timeout value (in seconds).
-
-Example:
- watchdog@f8005000 {
- compatible = "cdns,wdt-r1p2";
- clocks = <&clkc 45>;
- interrupt-parent = <&intc>;
- interrupts = <0 9 1>;
- reg = <0xf8005000 0x1000>;
- reset-on-timeout;
- timeout-sec = <10>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml b/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml
new file mode 100644
index 000000000000..3c17c5883bce
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cdns,wdt-r1p2.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/cdns,wdt-r1p2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence watchdog timer controller
+
+maintainers:
+ - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+ The cadence watchdog timer is used to detect and recover from
+ system malfunctions. This watchdog contains 24 bit counter and
+ a programmable reset period. The timeout period varies from 1 ms
+ to 30 seconds while using a 100Mhz clock.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cdns,wdt-r1p2
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-on-timeout:
+ type: boolean
+ description: |
+ If this property exists, then a reset is done when watchdog
+ times out.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@f8005000 {
+ compatible = "cdns,wdt-r1p2";
+ reg = <0xf8005000 0x1000>;
+ clocks = <&clkc 45>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_EDGE_RISING>;
+ reset-on-timeout;
+ timeout-sec = <10>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/watchdog/cirrus,ep9301-wdt.yaml b/Documentation/devicetree/bindings/watchdog/cirrus,ep9301-wdt.yaml
new file mode 100644
index 000000000000..5dbe891c70c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cirrus,ep9301-wdt.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/cirrus,ep9301-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic EP93xx Watchdog Timer
+
+maintainers:
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+ - Alexander Sverdlin <alexander.sverdlin@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: cirrus,ep9301-wdt
+ - items:
+ - enum:
+ - cirrus,ep9302-wdt
+ - cirrus,ep9307-wdt
+ - cirrus,ep9312-wdt
+ - cirrus,ep9315-wdt
+ - const: cirrus,ep9301-wdt
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@80940000 {
+ compatible = "cirrus,ep9301-wdt";
+ reg = <0x80940000 0x08>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/cnxt,cx92755-wdt.yaml b/Documentation/devicetree/bindings/watchdog/cnxt,cx92755-wdt.yaml
new file mode 100644
index 000000000000..13236ee61f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/cnxt,cx92755-wdt.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/cnxt,cx92755-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Conexant Digicolor SoCs Watchdog timer
+
+description: |
+ The watchdog functionality in Conexant Digicolor SoCs relies on the so called
+ "Agent Communication" block. This block includes the eight programmable system
+ timer counters. The first timer (called "Timer A") is the only one that can be
+ used as watchdog.
+
+maintainers:
+ - Baruch Siach <baruch@tkos.co.il>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: cnxt,cx92755-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@f0000fc0 {
+ compatible = "cnxt,cx92755-wdt";
+ reg = <0xf0000fc0 0x8>;
+ clocks = <&main_clk>;
+ timeout-sec = <15>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
deleted file mode 100644
index 354314d854ef..000000000000
--- a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* Dialog Semiconductor DA9062/61 Watchdog Timer
-
-Required properties:
-
-- compatible: should be one of the following valid compatible string lines:
- "dlg,da9061-watchdog", "dlg,da9062-watchdog"
- "dlg,da9062-watchdog"
-
-Optional properties:
-- dlg,use-sw-pm: Add this property to disable the watchdog during suspend.
- Only use this option if you can't use the watchdog automatic suspend
- function during a suspend (see register CONTROL_B).
-- dlg,wdt-sd: Set what happens on watchdog timeout. If this bit is set the
- watchdog timeout triggers SHUTDOWN, if cleared the watchdog triggers
- POWERDOWN. Can be 0 or 1. Only use this option if you want to change the
- default chip's OTP setting for WATCHDOG_SD bit. If this property is NOT
- set the WATCHDOG_SD bit and on timeout watchdog behavior will match the
- chip's OTP settings.
-
-Example: DA9062
-
- pmic0: da9062@58 {
- watchdog {
- compatible = "dlg,da9062-watchdog";
- };
- };
-
-Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
-
- pmic0: da9061@58 {
- watchdog {
- compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";
- };
- };
diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
deleted file mode 100644
index aa10b8ec36e2..000000000000
--- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Texas Instruments DaVinci/Keystone Watchdog Timer (WDT) Controller
-
-Required properties:
-- compatible : Should be "ti,davinci-wdt", "ti,keystone-wdt"
-- reg : Should contain WDT registers location and length
-
-Optional properties:
-- timeout-sec : Contains the watchdog timeout in seconds
-- clocks : the clock feeding the watchdog timer.
- Needed if platform uses clocks.
- See clock-bindings.txt
-
-Documentation:
-Davinci DM646x - https://www.ti.com/lit/ug/spruer5b/spruer5b.pdf
-Keystone - https://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
-
-Examples:
-
-wdt: wdt@2320000 {
- compatible = "ti,davinci-wdt";
- reg = <0x02320000 0x80>;
- timeout-sec = <30>;
- clocks = <&clkwdtimer0>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/digicolor-wdt.txt b/Documentation/devicetree/bindings/watchdog/digicolor-wdt.txt
deleted file mode 100644
index a882967e17d4..000000000000
--- a/Documentation/devicetree/bindings/watchdog/digicolor-wdt.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Conexant Digicolor SoCs Watchdog timer
-
-The watchdog functionality in Conexant Digicolor SoCs relies on the so called
-"Agent Communication" block. This block includes the eight programmable system
-timer counters. The first timer (called "Timer A") is the only one that can be
-used as watchdog.
-
-Required properties:
-
-- compatible : Should be "cnxt,cx92755-wdt"
-- reg : Specifies base physical address and size of the registers
-- clocks : phandle; specifies the clock that drives the timer
-
-Optional properties:
-
-- timeout-sec : Contains the watchdog timeout in seconds
-
-Example:
-
- watchdog@f0000fc0 {
- compatible = "cnxt,cx92755-wdt";
- reg = <0xf0000fc0 0x8>;
- clocks = <&main_clk>;
- timeout-sec = <15>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/dlg,da9062-watchdog.yaml b/Documentation/devicetree/bindings/watchdog/dlg,da9062-watchdog.yaml
new file mode 100644
index 000000000000..64619ba08d40
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/dlg,da9062-watchdog.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/dlg,da9062-watchdog.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dialog Semiconductor DA906{1,2,3} Watchdog Timer
+
+maintainers:
+ - Steve Twiss <stwiss.opensource@diasemi.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - dlg,da9062-watchdog
+ - dlg,da9063-watchdog
+ - items:
+ - const: dlg,da9061-watchdog
+ - const: dlg,da9062-watchdog
+
+ dlg,use-sw-pm:
+ type: boolean
+ description:
+ Add this property to disable the watchdog during suspend.
+ Only use this option if you can't use the watchdog automatic suspend
+ function during a suspend (see register CONTROL_B).
+
+ dlg,wdt-sd:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description:
+ Set what happens on watchdog timeout. If this bit is set the
+ watchdog timeout triggers SHUTDOWN, if cleared the watchdog triggers
+ POWERDOWN. Can be 0 or 1. Only use this option if you want to change the
+ default chip's OTP setting for WATCHDOG_SD bit. If this property is NOT
+ set the WATCHDOG_SD bit and on timeout watchdog behavior will match the
+ chip's OTP settings.
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ dlg,use-sw-pm;
+ dlg,wdt-sd = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml
index 6ecd429f76b5..726dc872ad02 100644
--- a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml
+++ b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml
@@ -15,7 +15,7 @@ description: |
SoCs and others.
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
properties:
compatible:
@@ -52,16 +52,16 @@ examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
watchdog@41000000 {
- compatible = "faraday,ftwdt010";
- reg = <0x41000000 0x1000>;
- interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
- timeout-sec = <5>;
+ compatible = "faraday,ftwdt010";
+ reg = <0x41000000 0x1000>;
+ interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+ timeout-sec = <5>;
};
- |
watchdog: watchdog@98500000 {
- compatible = "moxa,moxart-watchdog", "faraday,ftwdt010";
- reg = <0x98500000 0x10>;
- clocks = <&clk_apb>;
- clock-names = "PCLK";
+ compatible = "moxa,moxart-watchdog", "faraday,ftwdt010";
+ reg = <0x98500000 0x10>;
+ clocks = <&clk_apb>;
+ clock-names = "PCLK";
};
...
diff --git a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml
index f84c45d687d7..1d9f15ec6657 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/watchdog/fsl,scu-wdt.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: i.MX SCU Client Device Node - Watchdog bindings based on SCU Message Protocol
+title: i.MX SCU Client Device Node - Watchdog Based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
@@ -18,7 +18,10 @@ allOf:
properties:
compatible:
items:
- - const: fsl,imx8qxp-sc-wdt
+ - enum:
+ - fsl,imx8dxl-sc-wdt
+ - fsl,imx8qm-sc-wdt
+ - fsl,imx8qxp-sc-wdt
- const: fsl,imx-sc-wdt
required:
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
index fb7695515be1..34951783a633 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
@@ -7,10 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX Watchdog Timer (WDT) Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
-
-allOf:
- - $ref: "watchdog.yaml#"
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
properties:
compatible:
@@ -36,7 +35,9 @@ properties:
- fsl,imx8mp-wdt
- fsl,imx8mq-wdt
- fsl,ls1012a-wdt
+ - fsl,ls1021a-wdt
- fsl,ls1043a-wdt
+ - fsl,ls1046a-wdt
- fsl,vf610-wdt
- const: fsl,imx21-wdt
@@ -49,17 +50,67 @@ properties:
clocks:
maxItems: 1
+ big-endian: true
+
fsl,ext-reset-output:
$ref: /schemas/types.yaml#/definitions/flag
description: |
If present, the watchdog device is configured to assert its
external reset (WDOG_B) instead of issuing a software reset.
+ fsl,suspend-in-wait:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description: |
+ If present, the watchdog device is suspended in WAIT mode
+ (Suspend-to-Idle). Only supported on certain devices.
+
required:
- compatible
- interrupts
- reg
+allOf:
+ - $ref: watchdog.yaml#
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx25-wdt
+ - fsl,imx35-wdt
+ - fsl,imx50-wdt
+ - fsl,imx51-wdt
+ - fsl,imx53-wdt
+ - fsl,imx6q-wdt
+ - fsl,imx6sl-wdt
+ - fsl,imx6sll-wdt
+ - fsl,imx6sx-wdt
+ - fsl,imx6ul-wdt
+ - fsl,imx7d-wdt
+ - fsl,imx8mm-wdt
+ - fsl,imx8mn-wdt
+ - fsl,imx8mp-wdt
+ - fsl,imx8mq-wdt
+ - fsl,vf610-wdt
+ then:
+ properties:
+ fsl,suspend-in-wait: false
+
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,ls1012a-wdt
+ - fsl,ls1021a-wdt
+ - fsl,ls1043a-wdt
+ - fsl,ls1046a-wdt
+ then:
+ properties:
+ big-endian: false
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml
index 8562978aa0c8..6ec391b9723a 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml
@@ -7,10 +7,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX7ULP Watchdog Timer (WDT) Controller
maintainers:
- - Anson Huang <Anson.Huang@nxp.com>
+ - Shawn Guo <shawnguo@kernel.org>
+ - Sascha Hauer <s.hauer@pengutronix.de>
+ - Fabio Estevam <festevam@gmail.com>
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
properties:
compatible:
@@ -20,6 +22,10 @@ properties:
- const: fsl,imx8ulp-wdt
- const: fsl,imx7ulp-wdt
- const: fsl,imx93-wdt
+ - items:
+ - enum:
+ - fsl,imx94-wdt
+ - const: fsl,imx93-wdt
reg:
maxItems: 1
@@ -30,7 +36,10 @@ properties:
clocks:
maxItems: 1
- timeout-sec: true
+ fsl,ext-reset-output:
+ description:
+ When set, wdog can generate external reset from the wdog_any pin.
+ type: boolean
required:
- compatible
@@ -38,7 +47,7 @@ required:
- reg
- clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
deleted file mode 100644
index 198794963786..000000000000
--- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* GPIO-controlled Watchdog
-
-Required Properties:
-- compatible: Should contain "linux,wdt-gpio".
-- gpios: From common gpio binding; gpio connection to WDT reset pin.
-- hw_algo: The algorithm used by the driver. Should be one of the
- following values:
- - toggle: Either a high-to-low or a low-to-high transition clears
- the WDT counter. The watchdog timer is disabled when GPIO is
- left floating or connected to a three-state buffer.
- - level: Low or high level starts counting WDT timeout,
- the opposite level disables the WDT. Active level is determined
- by the GPIO flags.
-- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
-
-Optional Properties:
-- always-running: If the watchdog timer cannot be disabled, add this flag to
- have the driver keep toggling the signal without a client. It will only cease
- to toggle the signal when the device is open and the timeout elapsed.
-
-Example:
- watchdog: watchdog {
- /* ADM706 */
- compatible = "linux,wdt-gpio";
- gpios = <&gpio3 9 GPIO_ACTIVE_LOW>;
- hw_algo = "toggle";
- hw_margin_ms = <1600>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/img,pdc-wdt.yaml b/Documentation/devicetree/bindings/watchdog/img,pdc-wdt.yaml
new file mode 100644
index 000000000000..a88a27354505
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/img,pdc-wdt.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/img,pdc-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ImgTec PowerDown Controller (PDC) Watchdog Timer (WDT)
+
+maintainers:
+ - Shresth Prasad <shresthprasad7@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - img,pdc-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: watchdog counter clock
+ - description: register interface clock
+
+ clock-names:
+ items:
+ - const: wdt
+ - const: sys
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ watchdog@18102100 {
+ compatible = "img,pdc-wdt";
+ reg = <0x18102100 0x100>;
+ clocks = <&pdc_wdt_clk>, <&sys_clk>;
+ clock-names = "wdt", "sys";
+ interrupts = <0 52 IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt b/Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt
deleted file mode 100644
index b2fa11fd43de..000000000000
--- a/Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-*ImgTec PowerDown Controller (PDC) Watchdog Timer (WDT)
-
-Required properties:
-- compatible : Should be "img,pdc-wdt"
-- reg : Should contain WDT registers location and length
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Should contain "wdt" and "sys"; the watchdog counter
- clock and register interface clock respectively.
-- interrupts : Should contain WDT interrupt
-
-Examples:
-
-watchdog@18102100 {
- compatible = "img,pdc-wdt";
- reg = <0x18102100 0x100>;
- clocks = <&pdc_wdt_clk>, <&sys_clk>;
- clock-names = "wdt", "sys";
- interrupts = <0 52 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/intel,keembay-wdt.yaml b/Documentation/devicetree/bindings/watchdog/intel,keembay-wdt.yaml
index 1437ff8a122f..8231dde2bfa6 100644
--- a/Documentation/devicetree/bindings/watchdog/intel,keembay-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/intel,keembay-wdt.yaml
@@ -9,6 +9,9 @@ title: Intel Keem Bay SoC non-secure Watchdog Timer
maintainers:
- Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
enum:
@@ -37,7 +40,7 @@ required:
- interrupt-names
- clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml b/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
index 179272f74de5..0821ba0e84a3 100644
--- a/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml
@@ -11,14 +11,19 @@ maintainers:
description: |
This module is part of the sl28cpld multi-function device. For more
- details see ../mfd/kontron,sl28cpld.yaml.
+ details see ../embedded-controller/kontron,sl28cpld.yaml.
allOf:
- $ref: watchdog.yaml#
properties:
compatible:
- const: kontron,sl28cpld-wdt
+ oneOf:
+ - items:
+ - enum:
+ - kontron,sa67mcu-wdt
+ - const: kontron,sl28cpld-wdt
+ - const: kontron,sl28cpld-wdt
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/watchdog/lantiq,wdt.yaml b/Documentation/devicetree/bindings/watchdog/lantiq,wdt.yaml
new file mode 100644
index 000000000000..a7edae9ca05a
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/lantiq,wdt.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/lantiq,wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq WTD watchdog
+
+maintainers:
+ - Hauke Mehrtens <hauke@hauke-m.de>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - lantiq,falcon-wdt
+ - lantiq,wdt
+ - lantiq,xrx100-wdt
+ - items:
+ - enum:
+ - lantiq,xrx200-wdt
+ - const: lantiq,xrx100-wdt
+
+ reg:
+ maxItems: 1
+
+ lantiq,rcu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the RCU syscon node
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: watchdog.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - lantiq,xrx100-wdt
+ - lantiq,falcon-wdt
+ then:
+ required:
+ - lantiq,rcu
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@803f0 {
+ compatible = "lantiq,xrx200-wdt", "lantiq,xrx100-wdt";
+ reg = <0x803f0 0x10>;
+
+ lantiq,rcu = <&rcu0>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/lantiq-wdt.txt b/Documentation/devicetree/bindings/watchdog/lantiq-wdt.txt
deleted file mode 100644
index 18d4d8302702..000000000000
--- a/Documentation/devicetree/bindings/watchdog/lantiq-wdt.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Lantiq WTD watchdog binding
-============================
-
-This describes the binding of the Lantiq watchdog driver.
-
--------------------------------------------------------------------------------
-Required properties:
-- compatible : Should be one of
- "lantiq,wdt"
- "lantiq,xrx100-wdt"
- "lantiq,xrx200-wdt", "lantiq,xrx100-wdt"
- "lantiq,falcon-wdt"
-- reg : Address of the watchdog block
-- lantiq,rcu : A phandle to the RCU syscon (required for
- "lantiq,falcon-wdt" and "lantiq,xrx100-wdt")
-
--------------------------------------------------------------------------------
-Example for the watchdog on the xRX200 SoCs:
- watchdog@803f0 {
- compatible = "lantiq,xrx200-wdt", "lantiq,xrx100-wdt";
- reg = <0x803f0 0x10>;
-
- lantiq,rcu = <&rcu0>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/linux,wdt-gpio.yaml b/Documentation/devicetree/bindings/watchdog/linux,wdt-gpio.yaml
new file mode 100644
index 000000000000..499f1b7e03f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/linux,wdt-gpio.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/linux,wdt-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO-controlled Watchdog
+
+maintainers:
+ - Guenter Roeck <linux@roeck-us.net>
+ - Robert Marko <robert.marko@sartura.hr>
+
+properties:
+ compatible:
+ const: linux,wdt-gpio
+
+ gpios:
+ description: gpio connection to WDT reset pin
+ maxItems: 1
+
+ hw_algo:
+ description: The algorithm used by the driver.
+ oneOf:
+ - description:
+ Either a high-to-low or a low-to-high transition clears the WDT counter.
+ The watchdog timer is disabled when GPIO is left floating or connected
+ to a three-state buffer.
+ const: toggle
+ - description:
+ Low or high level starts counting WDT timeout, the opposite level
+ disables the WDT.
+ Active level is determined by the GPIO flags.
+ const: level
+
+ hw_margin_ms:
+ description: Maximum time to reset watchdog circuit (milliseconds).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2
+ maximum: 65535
+
+ always-running:
+ type: boolean
+ description:
+ If the watchdog timer cannot be disabled, add this flag to have the driver
+ keep toggling the signal without a client.
+ It will only cease to toggle the signal when the device is open and the
+ timeout elapsed.
+
+required:
+ - compatible
+ - gpios
+ - hw_algo
+ - hw_margin_ms
+
+allOf:
+ - $ref: watchdog.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ watchdog {
+ compatible = "linux,wdt-gpio";
+ gpios = <&gpio3 9 GPIO_ACTIVE_LOW>;
+ hw_algo = "toggle";
+ hw_margin_ms = <1600>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml b/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml
new file mode 100644
index 000000000000..50a9b468c4a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/loongson,ls1x-wdt.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/loongson,ls1x-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson Watchdog Timer
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - loongson,ls1b-wdt
+ - loongson,ls1c-wdt
+ - loongson,ls2k0300-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/loongson,ls1x-clk.h>
+ watchdog: watchdog@1fe5c060 {
+ compatible = "loongson,ls1b-wdt";
+ reg = <0x1fe5c060 0xc>;
+
+ clocks = <&clkc LS1X_CLKID_APB>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/lpc18xx-wdt.txt b/Documentation/devicetree/bindings/watchdog/lpc18xx-wdt.txt
deleted file mode 100644
index 09f6b24969e0..000000000000
--- a/Documentation/devicetree/bindings/watchdog/lpc18xx-wdt.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-* NXP LPC18xx Watchdog Timer (WDT)
-
-Required properties:
-- compatible: Should be "nxp,lpc1850-wwdt"
-- reg: Should contain WDT registers location and length
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Should contain "wdtclk" and "reg"; the watchdog counter
- clock and register interface clock respectively.
-- interrupts: Should contain WDT interrupt
-
-Examples:
-
-watchdog@40080000 {
- compatible = "nxp,lpc1850-wwdt";
- reg = <0x40080000 0x24>;
- clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_WWDT>;
- clock-names = "wdtclk", "reg";
- interrupts = <49>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
deleted file mode 100644
index c1b67a78f00c..000000000000
--- a/Documentation/devicetree/bindings/watchdog/marvel.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-* Marvell Orion Watchdog Time
-
-Required Properties:
-
-- Compatibility : "marvell,orion-wdt"
- "marvell,armada-370-wdt"
- "marvell,armada-xp-wdt"
- "marvell,armada-375-wdt"
- "marvell,armada-380-wdt"
-
-- reg : Should contain two entries: first one with the
- timer control address, second one with the
- rstout enable address.
-
-For "marvell,armada-375-wdt" and "marvell,armada-380-wdt":
-
-- reg : A third entry is mandatory and should contain the
- shared mask/unmask RSTOUT address.
-
-Clocks required for compatibles = "marvell,orion-wdt",
- "marvell,armada-370-wdt":
-- clocks : Must contain a single entry describing the clock input
-
-Clocks required for compatibles = "marvell,armada-xp-wdt"
- "marvell,armada-375-wdt"
- "marvell,armada-380-wdt":
-- clocks : Must contain an entry for each entry in clock-names.
-- clock-names : Must include the following entries:
- "nbclk" (L2/coherency fabric clock),
- "fixed" (Reference 25 MHz fixed-clock).
-
-Optional properties:
-
-- interrupts : Contains the IRQ for watchdog expiration
-- timeout-sec : Contains the watchdog timeout in seconds
-
-Example:
-
- wdt@20300 {
- compatible = "marvell,orion-wdt";
- reg = <0x20300 0x28>, <0x20108 0x4>;
- interrupts = <3>;
- timeout-sec = <10>;
- clocks = <&gate_clk 7>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/marvell,armada-3700-wdt.yaml b/Documentation/devicetree/bindings/watchdog/marvell,armada-3700-wdt.yaml
new file mode 100644
index 000000000000..60d44d642fb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/marvell,armada-3700-wdt.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/marvell,armada-3700-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Armada 37xx CPU Watchdog Timer Controller
+
+maintainers:
+ - Marek Behún <kabel@kernel.org>
+
+properties:
+ compatible:
+ const: marvell,armada-3700-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ marvell,system-controller:
+ description: Reference to syscon node for the CPU Miscellaneous Registers
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - marvell,system-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ watchdog@8300 {
+ compatible = "marvell,armada-3700-wdt";
+ reg = <0x8300 0x40>;
+ marvell,system-controller = <&cpu_misc>;
+ clocks = <&xtalclk>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml b/Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml
new file mode 100644
index 000000000000..1b583f232e53
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/marvell,cn10624-wdt.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/marvell,cn10624-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Global Timer (GTI) system watchdog
+
+maintainers:
+ - Bharat Bhushan <bbhushan2@marvell.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - marvell,cn9670-wdt
+ - marvell,cn10624-wdt
+
+ - items:
+ - enum:
+ - marvell,cn9880-wdt
+ - marvell,cnf9535-wdt
+ - const: marvell,cn9670-wdt
+
+ - items:
+ - enum:
+ - marvell,cn10308-wdt
+ - marvell,cnf10518-wdt
+ - const: marvell,cn10624-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: refclk
+
+ marvell,wdt-timer-index:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 63
+ description:
+ An SoC have many timers (up to 64), firmware can reserve one or more timer
+ for some other use case and configures one of the global timer as watchdog
+ timer. Firmware will update this field with the timer number configured
+ as watchdog timer.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ watchdog@802000040000 {
+ compatible = "marvell,cn9670-wdt";
+ reg = <0x00008020 0x00040000 0x00000000 0x00020000>;
+ interrupts = <GIC_SPI 38 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&sclk>;
+ clock-names = "refclk";
+ marvell,wdt-timer-index = <63>;
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/watchdog/marvell,orion-wdt.yaml b/Documentation/devicetree/bindings/watchdog/marvell,orion-wdt.yaml
new file mode 100644
index 000000000000..fdc7bc45dfde
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/marvell,orion-wdt.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/marvell,orion-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Orion Watchdog Timer
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+
+properties:
+ compatible:
+ enum:
+ - marvell,orion-wdt
+ - marvell,armada-370-wdt
+ - marvell,armada-xp-wdt
+ - marvell,armada-375-wdt
+ - marvell,armada-380-wdt
+
+ reg:
+ minItems: 2
+ items:
+ - description: Timer control register address
+ - description: RSTOUT enable register address
+ - description: Shared mask/unmask RSTOUT register address
+
+ clocks:
+ minItems: 1
+ items:
+ - description: L2/coherency fabric clock input
+ - description: Reference 25 MHz fixed-clock supply
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: nbclk
+ - const: fixed
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: timeout
+ - description: pre-timeout
+
+allOf:
+ - $ref: watchdog.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,armada-375-wdt
+ - marvell,armada-380-wdt
+ then:
+ properties:
+ reg:
+ minItems: 3
+ else:
+ properties:
+ reg:
+ maxItems: 2
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,armada-xp-wdt
+ - marvell,armada-375-wdt
+ - marvell,armada-380-wdt
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ interrupts:
+ minItems: 2
+
+ required:
+ - clock-names
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@20300 {
+ compatible = "marvell,orion-wdt";
+ reg = <0x20300 0x28>, <0x20108 0x4>;
+ interrupts = <3>;
+ timeout-sec = <10>;
+ clocks = <&gate_clk 7>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
index ab9641e845db..442c21f12a3b 100644
--- a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
+++ b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
@@ -6,13 +6,14 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim 63xx Watchdog Timers
-allOf:
- - $ref: "watchdog.yaml#"
-
maintainers:
- Marc Zyngier <maz@kernel.org>
- Linus Walleij <linus.walleij@linaro.org>
+allOf:
+ - $ref: watchdog.yaml#
+ - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
+
properties:
compatible:
enum:
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml
new file mode 100644
index 000000000000..18160869c378
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mt7621-wdt.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/mediatek,mt7621-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink Watchdog Timers
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt7621-wdt
+
+ reg:
+ maxItems: 1
+
+ mediatek,sysctl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ phandle to system controller 'sysc' syscon node which
+ controls system registers
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ watchdog@100 {
+ compatible = "mediatek,mt7621-wdt";
+ reg = <0x100 0x100>;
+ mediatek,sysctl = <&sysc>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
new file mode 100644
index 000000000000..953629cb9558
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/mediatek,mtk-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek SoCs Watchdog timer
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description:
+ The watchdog supports a pre-timeout interrupt that fires
+ timeout-sec/2 before the expiry.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - mediatek,mt2712-wdt
+ - mediatek,mt6589-wdt
+ - mediatek,mt6735-wdt
+ - mediatek,mt6795-wdt
+ - mediatek,mt7986-wdt
+ - mediatek,mt7988-wdt
+ - mediatek,mt8183-wdt
+ - mediatek,mt8186-wdt
+ - mediatek,mt8188-wdt
+ - mediatek,mt8192-wdt
+ - mediatek,mt8195-wdt
+ - items:
+ - enum:
+ - mediatek,mt2701-wdt
+ - mediatek,mt6572-wdt
+ - mediatek,mt6582-wdt
+ - mediatek,mt6797-wdt
+ - mediatek,mt7622-wdt
+ - mediatek,mt7623-wdt
+ - mediatek,mt7629-wdt
+ - mediatek,mt8173-wdt
+ - mediatek,mt8188-wdt
+ - mediatek,mt8189-wdt
+ - mediatek,mt8365-wdt
+ - mediatek,mt8516-wdt
+ - const: mediatek,mt6589-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Watchdog pre-timeout (bark) interrupt
+
+ mediatek,disable-extrst:
+ description: Disable sending output reset signal
+ type: boolean
+
+ mediatek,reset-by-toprgu:
+ description: The Top Reset Generation Unit (TOPRGU) generates reset signals
+ and distributes them to each IP. If present, the watchdog timer will be
+ reset by TOPRGU once system resets.
+ type: boolean
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8183-wdt";
+ reg = <0 0x10007000 0 0x100>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
+ mediatek,disable-extrst;
+ timeout-sec = <10>;
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/meson-wdt.txt b/Documentation/devicetree/bindings/watchdog/meson-wdt.txt
deleted file mode 100644
index 7588cc3971bf..000000000000
--- a/Documentation/devicetree/bindings/watchdog/meson-wdt.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Meson SoCs Watchdog timer
-
-Required properties:
-
-- compatible : depending on the SoC this should be one of:
- "amlogic,meson6-wdt" on Meson6 SoCs
- "amlogic,meson8-wdt" and "amlogic,meson6-wdt" on Meson8 SoCs
- "amlogic,meson8b-wdt" on Meson8b SoCs
- "amlogic,meson8m2-wdt" and "amlogic,meson8b-wdt" on Meson8m2 SoCs
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-- timeout-sec: contains the watchdog timeout in seconds.
-
-Example:
-
-wdt: watchdog@c1109900 {
- compatible = "amlogic,meson6-wdt";
- reg = <0xc1109900 0x8>;
- timeout-sec = <10>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
deleted file mode 100644
index 1169857d1d12..000000000000
--- a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-MOXA ART Watchdog timer
-
-Required properties:
-
-- compatible : Must be "moxa,moxart-watchdog"
-- reg : Should contain registers location and length
-- clocks : Should contain phandle for the clock that drives the counter
-
-Example:
-
- watchdog: watchdog@98500000 {
- compatible = "moxa,moxart-watchdog";
- reg = <0x98500000 0x10>;
- clocks = <&coreclk>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml
index e3e8b86dbf63..33794711c594 100644
--- a/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/watchdog/mstar,msc313e-wdt.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MStar Watchdog Device Tree Bindings
+title: MStar Watchdog
maintainers:
- Daniel Palmer <daniel@0x0f.com>
diff --git a/Documentation/devicetree/bindings/watchdog/mt7621-wdt.txt b/Documentation/devicetree/bindings/watchdog/mt7621-wdt.txt
deleted file mode 100644
index c15ef0ef609f..000000000000
--- a/Documentation/devicetree/bindings/watchdog/mt7621-wdt.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Ralink Watchdog Timers
-
-Required properties:
-- compatible: must be "mediatek,mt7621-wdt"
-- reg: physical base address of the controller and length of the register range
-
-Example:
-
- watchdog@100 {
- compatible = "mediatek,mt7621-wdt";
- reg = <0x100 0x10>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
deleted file mode 100644
index 762c62e428ef..000000000000
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Mediatek SoCs Watchdog timer
-
-The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
-before the expiry.
-
-Required properties:
-
-- compatible should contain:
- "mediatek,mt2701-wdt", "mediatek,mt6589-wdt": for MT2701
- "mediatek,mt2712-wdt": for MT2712
- "mediatek,mt6582-wdt", "mediatek,mt6589-wdt": for MT6582
- "mediatek,mt6589-wdt": for MT6589
- "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797
- "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622
- "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623
- "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629
- "mediatek,mt7986-wdt", "mediatek,mt6589-wdt": for MT7986
- "mediatek,mt8183-wdt": for MT8183
- "mediatek,mt8186-wdt", "mediatek,mt6589-wdt": for MT8186
- "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516
- "mediatek,mt8192-wdt": for MT8192
- "mediatek,mt8195-wdt", "mediatek,mt6589-wdt": for MT8195
-
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-- mediatek,disable-extrst: disable send output reset signal
-- interrupts: Watchdog pre-timeout (bark) interrupt.
-- timeout-sec: contains the watchdog timeout in seconds.
-- #reset-cells: Should be 1.
-
-Example:
-
-watchdog: watchdog@10007000 {
- compatible = "mediatek,mt8183-wdt",
- "mediatek,mt6589-wdt";
- mediatek,disable-extrst;
- reg = <0 0x10007000 0 0x100>;
- interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>;
- timeout-sec = <10>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
deleted file mode 100644
index 866a958b8a2b..000000000000
--- a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Nuvoton NPCM Watchdog
-
-Nuvoton NPCM timer module provides five 24-bit timer counters, and a watchdog.
-The watchdog supports a pre-timeout interrupt that fires 10ms before the
-expiry.
-
-Required properties:
-- compatible : "nuvoton,npcm750-wdt" for NPCM750 (Poleg), or
- "nuvoton,wpcm450-wdt" for WPCM450 (Hermon), or
- "nuvoton,npcm845-wdt" for NPCM845 (Arbel).
-- reg : Offset and length of the register set for the device.
-- interrupts : Contain the timer interrupt with flags for
- falling edge.
-
-Required clocking property, have to be one of:
-- clocks : phandle of timer reference clock.
-- clock-frequency : The frequency in Hz of the clock that drives the NPCM7xx
- timer (usually 25000000).
-
-Optional properties:
-- timeout-sec : Contains the watchdog timeout in seconds
-
-Example:
-
-timer@f000801c {
- compatible = "nuvoton,npcm750-wdt";
- interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0xf000801c 0x4>;
- clocks = <&clk NPCM7XX_CLK_TIMER>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
new file mode 100644
index 000000000000..7aa30f5b5c49
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/nuvoton,npcm750-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Watchdog
+
+maintainers:
+ - Joel Stanley <joel@jms.id.au>
+
+description:
+ Nuvoton NPCM timer module provides five 24-bit timer counters, and a watchdog.
+ The watchdog supports a pre-timeout interrupt that fires 10ms before the
+ expiry.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nuvoton,npcm750-wdt
+ - nuvoton,wpcm450-wdt
+ - items:
+ - enum:
+ - nuvoton,npcm845-wdt
+ - const: nuvoton,npcm750-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ description: Frequency in Hz of the clock that drives the NPCM timer.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
+
+ watchdog@f000801c {
+ compatible = "nuvoton,npcm750-wdt";
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf000801c 0x4>;
+ clocks = <&clk NPCM7XX_CLK_TIMER>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/nxp,lpc1850-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/nxp,lpc1850-wwdt.yaml
new file mode 100644
index 000000000000..52878fdbe3ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/nxp,lpc1850-wwdt.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/nxp,lpc1850-wwdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP LPC18xx Watchdog Timer (WDT)
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ const: nxp,lpc1850-wwdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Watchdog counter clock
+ - description: Register interface clock
+
+ clock-names:
+ items:
+ - const: wdtclk
+ - const: reg
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/lpc18xx-cgu.h>
+ #include <dt-bindings/clock/lpc18xx-ccu.h>
+
+ watchdog@40080000 {
+ compatible = "nxp,lpc1850-wwdt";
+ reg = <0x40080000 0x24>;
+ clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_WWDT>;
+ clock-names = "wdtclk", "reg";
+ interrupts = <49>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/nxp,pnx4008-wdt.yaml b/Documentation/devicetree/bindings/watchdog/nxp,pnx4008-wdt.yaml
new file mode 100644
index 000000000000..8964c1c5d522
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/nxp,pnx4008-wdt.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/nxp,pnx4008-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PNX watchdog timer
+
+maintainers:
+ - Roland Stigge <stigge@antcom.de>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: nxp,pnx4008-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@4003c000 {
+ compatible = "nxp,pnx4008-wdt";
+ reg = <0x4003c000 0x1000>;
+ timeout-sec = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml b/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml
new file mode 100644
index 000000000000..8f168a05b50c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/nxp,s32g2-swt.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/nxp,s32g2-swt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Software Watchdog Timer (SWT)
+
+maintainers:
+ - Daniel Lezcano <daniel.lezcano@kernel.org>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: nxp,s32g2-swt
+ - items:
+ - const: nxp,s32g3-swt
+ - const: nxp,s32g2-swt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Counter clock
+ - description: Module clock
+ - description: Register clock
+
+ clock-names:
+ items:
+ - const: counter
+ - const: module
+ - const: register
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@40100000 {
+ compatible = "nxp,s32g2-swt";
+ reg = <0x40100000 0x1000>;
+ clocks = <&clks 0x3a>, <&clks 0x3b>, <&clks 0x3c>;
+ clock-names = "counter", "module", "register";
+ timeout-sec = <10>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
deleted file mode 100644
index c6ae9c9d5e3e..000000000000
--- a/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Xilinx AXI/PLB soft-core watchdog Device Tree Bindings
----------------------------------------------------------
-
-Required properties:
-- compatible : Should be "xlnx,xps-timebase-wdt-1.00.a" or
- "xlnx,xps-timebase-wdt-1.01.a".
-- reg : Physical base address and size
-
-Optional properties:
-- clocks : Input clock specifier. Refer to common clock
- bindings.
-- clock-frequency : Frequency of clock in Hz
-- xlnx,wdt-enable-once : 0 - Watchdog can be restarted
- 1 - Watchdog can be enabled just once
-- xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
- <val> is integer from 8 to 31.
-
-Example:
-axi-timebase-wdt@40100000 {
- clock-frequency = <50000000>;
- compatible = "xlnx,xps-timebase-wdt-1.00.a";
- clocks = <&clkc 15>;
- reg = <0x40100000 0x10000>;
- xlnx,wdt-enable-once = <0x0>;
- xlnx,wdt-interval = <0x1b>;
-} ;
diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
deleted file mode 100644
index 1fa20e453a2d..000000000000
--- a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-TI Watchdog Timer (WDT) Controller for OMAP
-
-Required properties:
-- compatible : "ti,omap3-wdt" for OMAP3 or "ti,omap4-wdt" for OMAP4
-- ti,hwmods : Name of the hwmod associated to the WDT
-
-Optional properties:
-- timeout-sec : default watchdog timeout in seconds
-
-Examples:
-
-wdt2: wdt@4a314000 {
- compatible = "ti,omap4-wdt", "ti,omap3-wdt";
- ti,hwmods = "wd_timer2";
-};
diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
deleted file mode 100644
index 4b76bec62af9..000000000000
--- a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* NXP PNX watchdog timer
-
-Required properties:
-- compatible: must be "nxp,pnx4008-wdt"
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-Optional properties:
-- timeout-sec: contains the watchdog timeout in seconds.
-
-Example:
-
- watchdog@4003c000 {
- compatible = "nxp,pnx4008-wdt";
- reg = <0x4003C000 0x1000>;
- timeout-sec = <10>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/qca,ar7130-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qca,ar7130-wdt.yaml
new file mode 100644
index 000000000000..82040ca10eda
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/qca,ar7130-wdt.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/qca,ar7130-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros AR7130 Watchdog Timer (WDT) Controller
+
+maintainers:
+ - Gabor Juhos <juhosg@openwrt.org>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: qca,ar7130-wdt
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@18060008 {
+ compatible = "qca,ar7130-wdt";
+ reg = <0x18060008 0x8>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt b/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt
deleted file mode 100644
index 7a89e5f85415..000000000000
--- a/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-* Qualcomm Atheros AR7130 Watchdog Timer (WDT) Controller
-
-Required properties:
-- compatible: must be "qca,ar7130-wdt"
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-Example:
-
-wdt@18060008 {
- compatible = "qca,ar9330-wdt", "qca,ar7130-wdt";
- reg = <0x18060008 0x8>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml
index 568eb8480fc3..a519422c371c 100644
--- a/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/qcom,pm8916-wdt.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm PM8916 watchdog timer controller
maintainers:
- - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+ - Krzysztof Kozlowski <krzk@kernel.org>
allOf:
- $ref: watchdog.yaml#
@@ -30,22 +30,27 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/spmi/spmi.h>
- pmic@0 {
- compatible = "qcom,pm8916", "qcom,spmi-pmic";
- reg = <0x0 SPMI_USID>;
- #address-cells = <1>;
+ spmi {
+ #address-cells = <2>;
#size-cells = <0>;
- pon@800 {
- compatible = "qcom,pm8916-pon";
- reg = <0x800>;
- mode-bootloader = <0x2>;
- mode-recovery = <0x1>;
-
- watchdog {
- compatible = "qcom,pm8916-wdt";
- interrupts = <0x0 0x8 6 IRQ_TYPE_EDGE_RISING>;
- timeout-sec = <60>;
+ pmic@0 {
+ compatible = "qcom,pm8916", "qcom,spmi-pmic";
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pon@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x800>;
+ mode-bootloader = <0x2>;
+ mode-recovery = <0x1>;
+
+ watchdog {
+ compatible = "qcom,pm8916-wdt";
+ interrupts = <0x0 0x8 6 IRQ_TYPE_EDGE_RISING>;
+ timeout-sec = <60>;
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
index d8ac0be36e6c..54f5311ed016 100644
--- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml
@@ -7,17 +7,31 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Krait Processor Sub-system (KPSS) Watchdog timer
maintainers:
- - Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
-
-allOf:
- - $ref: watchdog.yaml#
+ - Rajendra Nayak <quic_rjendra@quicinc.com>
properties:
+ $nodename:
+ pattern: "^(watchdog|timer)@[0-9a-f]+$"
+
compatible:
oneOf:
- items:
- enum:
+ - qcom,kpss-wdt-ipq4019
+ - qcom,apss-wdt-ipq5018
+ - qcom,apss-wdt-ipq5332
+ - qcom,apss-wdt-ipq5424
+ - qcom,apss-wdt-ipq9574
+ - qcom,apss-wdt-kaanapali
+ - qcom,apss-wdt-msm8226
+ - qcom,apss-wdt-msm8974
+ - qcom,apss-wdt-msm8994
+ - qcom,apss-wdt-qcm2290
- qcom,apss-wdt-qcs404
+ - qcom,apss-wdt-qcs615
+ - qcom,apss-wdt-qcs8300
+ - qcom,apss-wdt-sa8255p
+ - qcom,apss-wdt-sa8775p
- qcom,apss-wdt-sc7180
- qcom,apss-wdt-sc7280
- qcom,apss-wdt-sc8180x
@@ -25,19 +39,24 @@ properties:
- qcom,apss-wdt-sdm845
- qcom,apss-wdt-sdx55
- qcom,apss-wdt-sdx65
+ - qcom,apss-wdt-sm6115
- qcom,apss-wdt-sm6350
- qcom,apss-wdt-sm8150
- qcom,apss-wdt-sm8250
- const: qcom,kpss-wdt
+ - const: qcom,kpss-wdt
+ deprecated: true
+ - items:
+ - const: qcom,scss-timer
+ - const: qcom,msm-timer
- items:
- enum:
- - qcom,kpss-wdt
- - qcom,kpss-timer
- qcom,kpss-wdt-apq8064
- - qcom,kpss-wdt-ipq4019
- qcom,kpss-wdt-ipq8064
+ - qcom,kpss-wdt-mdm9615
- qcom,kpss-wdt-msm8960
- - qcom,scss-timer
+ - const: qcom,kpss-timer
+ - const: qcom,msm-timer
reg:
maxItems: 1
@@ -45,18 +64,87 @@ properties:
clocks:
maxItems: 1
+ clock-names:
+ items:
+ - const: sleep
+
+ clock-frequency:
+ description:
+ The frequency of the general purpose timer in Hz.
+
+ cpu-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Per-CPU offset used when the timer is accessed without the CPU remapping
+ facilities. The offset is cpu-offset + (0x10000 * cpu-nr).
+
+ interrupts:
+ minItems: 1
+ maxItems: 5
+
required:
- compatible
- reg
- clocks
+allOf:
+ - $ref: watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,kpss-wdt
+ then:
+ properties:
+ clock-frequency: false
+ cpu-offset: false
+ interrupts:
+ minItems: 1
+ items:
+ - description: Bark
+ - description: Bite
+
+ else:
+ properties:
+ interrupts:
+ minItems: 3
+ items:
+ - description: Debug
+ - description: First general purpose timer
+ - description: Second general purpose timer
+ - description: First watchdog
+ - description: Second watchdog
+ required:
+ - clock-frequency
+
unevaluatedProperties: false
examples:
- |
- watchdog@208a038 {
- compatible = "qcom,kpss-wdt-ipq8064";
- reg = <0x0208a038 0x40>;
- clocks = <&sleep_clk>;
- timeout-sec = <10>;
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@17c10000 {
+ compatible = "qcom,apss-wdt-sm8150", "qcom,kpss-wdt";
+ reg = <0x17c10000 0x1000>;
+ clocks = <&sleep_clk>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_EDGE_RISING>;
+ timeout-sec = <10>;
+ };
+
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@200a000 {
+ compatible = "qcom,kpss-wdt-ipq8064", "qcom,kpss-timer", "qcom,msm-timer";
+ interrupts = <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
+ <GIC_PPI 5 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
+ reg = <0x0200a000 0x100>;
+ clock-frequency = <25000000>;
+ clocks = <&sleep_clk>;
+ clock-names = "sleep";
+ cpu-offset = <0x80000>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/ralink,rt2880-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ralink,rt2880-wdt.yaml
new file mode 100644
index 000000000000..51e00de947e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ralink,rt2880-wdt.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/ralink,rt2880-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ralink Watchdog Timers
+
+maintainers:
+ - Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: ralink,rt2880-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@100 {
+ compatible = "ralink,rt2880-wdt";
+ reg = <0x120 0x10>;
+ clocks = <&clkref>;
+ resets = <&rstctrl 8>;
+ interrupt-parent = <&intc>;
+ interrupts = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
index 099245fe7b10..1f5390a67cdb 100644
--- a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml
@@ -67,12 +67,10 @@ required:
- reg
- clocks
- interrupts
+ - interrupt-names
unevaluatedProperties: false
-dependencies:
- interrupts: [ interrupt-names ]
-
examples:
- |
watchdog: watchdog@3150 {
diff --git a/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt b/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt
deleted file mode 100644
index 05653054bd5b..000000000000
--- a/Documentation/devicetree/bindings/watchdog/realtek,rtd119x.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Realtek RTD1295 Watchdog
-========================
-
-Required properties:
-
-- compatible : Should be "realtek,rtd1295-watchdog"
-- reg : Specifies the physical base address and size of registers
-- clocks : Specifies one clock input
-
-
-Example:
-
- watchdog@98007680 {
- compatible = "realtek,rtd1295-watchdog";
- reg = <0x98007680 0x100>;
- clocks = <&osc27M>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/realtek,rtd1295-watchdog.yaml b/Documentation/devicetree/bindings/watchdog/realtek,rtd1295-watchdog.yaml
new file mode 100644
index 000000000000..2a0ea1696317
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/realtek,rtd1295-watchdog.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/realtek,rtd1295-watchdog.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTD1295 Watchdog
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: realtek,rtd1295-watchdog
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@98007680 {
+ compatible = "realtek,rtd1295-watchdog";
+ reg = <0x98007680 0x100>;
+ clocks = <&osc27M>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,r9a09g057-wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,r9a09g057-wdt.yaml
new file mode 100644
index 000000000000..099200c4f136
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/renesas,r9a09g057-wdt.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/renesas,r9a09g057-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/V2H(P) Watchdog Timer (WDT) Controller
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a09g047-wdt # RZ/G3E
+ - renesas,r9a09g056-wdt # RZ/V2N
+ - const: renesas,r9a09g057-wdt # RZ/V2H(P)
+
+ - items:
+ - const: renesas,r9a09g087-wdt # RZ/N2H
+ - const: renesas,r9a09g077-wdt # RZ/T2H
+
+ - enum:
+ - renesas,r9a09g057-wdt # RZ/V2H(P)
+ - renesas,r9a09g077-wdt # RZ/T2H
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Register access clock
+ - description: Main clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: pclk
+ - const: oscclk
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ timeout-sec: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+allOf:
+ - $ref: watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g057-wdt
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ reg:
+ minItems: 2
+ resets: false
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/renesas,r9a09g057-cpg.h>
+
+ watchdog@11c00400 {
+ compatible = "renesas,r9a09g057-wdt";
+ reg = <0x11c00400 0x400>;
+ clocks = <&cpg CPG_MOD 0x4b>, <&cpg CPG_MOD 0x4c>;
+ clock-names = "pclk", "oscclk";
+ resets = <&cpg 0x75>;
+ power-domains = <&cpg>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,rcar-gen3-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,rcar-gen3-wwdt.yaml
new file mode 100644
index 000000000000..ffafe9a6d3f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/renesas,rcar-gen3-wwdt.yaml
@@ -0,0 +1,114 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/renesas,rcar-gen3-wwdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas Window Watchdog Timer (WWDT) Controller
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r8a77970-wwdt # R-Car V3M
+ - renesas,r8a77980-wwdt # R-Car V3H
+ - const: renesas,rcar-gen3-wwdt
+
+ - items:
+ - enum:
+ - renesas,r8a779a0-wwdt # R-Car V3U
+ - renesas,r8a779f0-wwdt # R-Car S4
+ - renesas,r8a779g0-wwdt # R-Car V4H
+ - renesas,r8a779h0-wwdt # R-Car V4M
+ - const: renesas,rcar-gen4-wwdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Pretimeout, 75% of overflow reached
+ - description: Error occurred
+
+ interrupt-names:
+ items:
+ - const: pretimeout
+ - const: error
+
+ clocks:
+ items:
+ - description: Counting clock
+ - description: Bus clock
+
+ clock-names:
+ items:
+ - const: cnt
+ - const: bus
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ items:
+ - const: cnt
+ - const: bus
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - power-domains
+
+allOf:
+ - $ref: watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r8a779a0-wwdt
+ - renesas,r8a779f0-wwdt
+ then:
+ properties:
+ resets:
+ minItems: 2
+ reset-names:
+ minItems: 2
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
+ #include <dt-bindings/power/r8a779g0-sysc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@ffc90000 {
+ compatible = "renesas,r8a779g0-wwdt",
+ "renesas,rcar-gen4-wwdt";
+ reg = <0xffc90000 0x10>;
+ interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pretimeout", "error";
+ clocks = <&cpg CPG_CORE R8A779G0_CLK_R>,
+ <&cpg CPG_CORE R8A779G0_CLK_SASYNCRT>;
+ clock-names = "cnt", "bus";
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 1200>;
+ reset-names = "cnt";
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,rza-wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,rza-wdt.yaml
new file mode 100644
index 000000000000..ba922c3f7b10
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/renesas,rza-wdt.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/renesas,rza-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/A Watchdog Timer (WDT) Controller
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r7s72100-wdt # RZ/A1
+ - renesas,r7s9210-wdt # RZ/A2
+ - const: renesas,rza-wdt # RZ/A
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ timeout-sec: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+allOf:
+ - $ref: watchdog.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r7s72100-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@fcfe0000 {
+ compatible = "renesas,r7s72100-wdt", "renesas,rza-wdt";
+ reg = <0xfcfe0000 0x6>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&p0_clk>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,rzg2l-wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,rzg2l-wdt.yaml
new file mode 100644
index 000000000000..a4d06c9c8b86
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/renesas,rzg2l-wdt.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/renesas,rzg2l-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Watchdog Timer (WDT) Controller
+
+maintainers:
+ - Biju Das <biju.das.jz@bp.renesas.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a07g043-wdt # RZ/G2UL and RZ/Five
+ - renesas,r9a07g044-wdt # RZ/G2{L,LC}
+ - renesas,r9a07g054-wdt # RZ/V2L
+ - renesas,r9a08g045-wdt # RZ/G3S
+ - const: renesas,rzg2l-wdt
+
+ - items:
+ - const: renesas,r9a09g011-wdt # RZ/V2M
+ - const: renesas,rzv2m-wdt # RZ/V2M
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ items:
+ - description: Timeout
+ - description: Parity error
+
+ interrupt-names:
+ minItems: 1
+ items:
+ - const: wdt
+ - const: perrout
+
+ clocks:
+ items:
+ - description: Register access clock
+ - description: Main clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: oscclk
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ timeout-sec: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+
+allOf:
+ - $ref: watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,rzg2l-wdt
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ interrupt-names:
+ minItems: 2
+ required:
+ - interrupt-names
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a07g044-cpg.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@12800800 {
+ compatible = "renesas,r9a07g044-wdt",
+ "renesas,rzg2l-wdt";
+ reg = <0x12800800 0x400>;
+ clocks = <&cpg CPG_MOD R9A07G044_WDT0_PCLK>,
+ <&cpg CPG_MOD R9A07G044_WDT0_CLK>;
+ clock-names = "pclk", "oscclk";
+ interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "wdt", "perrout";
+ resets = <&cpg R9A07G044_WDT0_PRESETN>;
+ power-domains = <&cpg>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,rzn1-wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,rzn1-wdt.yaml
new file mode 100644
index 000000000000..7e3ee533cd56
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/renesas,rzn1-wdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/renesas,rzn1-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/N1 Watchdog Timer (WDT) Controller
+
+maintainers:
+ - Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+properties:
+ compatible:
+ items:
+ - const: renesas,r9a06g032-wdt # RZ/N1D
+ - const: renesas,rzn1-wdt # RZ/N1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ timeout-sec: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+allOf:
+ - $ref: watchdog.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ watchdog@40008000 {
+ compatible = "renesas,r9a06g032-wdt", "renesas,rzn1-wdt";
+ reg = <0x40008000 0x1000>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&sysctrl R9A06G032_CLK_WATCHDOG>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
index a8d7dde5271b..7aebc5a5cf17 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
@@ -15,24 +15,6 @@ properties:
oneOf:
- items:
- enum:
- - renesas,r7s72100-wdt # RZ/A1
- - renesas,r7s9210-wdt # RZ/A2
- - const: renesas,rza-wdt # RZ/A
-
- - items:
- - enum:
- - renesas,r9a06g032-wdt # RZ/N1D
- - const: renesas,rzn1-wdt # RZ/N1
-
- - items:
- - enum:
- - renesas,r9a07g043-wdt # RZ/G2UL
- - renesas,r9a07g044-wdt # RZ/G2{L,LC}
- - renesas,r9a07g054-wdt # RZ/V2L
- - const: renesas,rzg2l-wdt
-
- - items:
- - enum:
- renesas,r8a7742-wdt # RZ/G1H
- renesas,r8a7743-wdt # RZ/G1M
- renesas,r8a7744-wdt # RZ/G1N
@@ -65,18 +47,18 @@ properties:
- enum:
- renesas,r8a779a0-wdt # R-Car V3U
- renesas,r8a779f0-wdt # R-Car S4-8
+ - renesas,r8a779g0-wdt # R-Car V4H
+ - renesas,r8a779h0-wdt # R-Car V4M
- const: renesas,rcar-gen4-wdt # R-Car Gen4
reg:
maxItems: 1
- interrupts: true
-
- interrupt-names: true
-
- clocks: true
+ interrupts:
+ maxItems: 1
- clock-names: true
+ clocks:
+ maxItems: 1
power-domains:
maxItems: 1
@@ -90,66 +72,35 @@ required:
- compatible
- reg
- clocks
+ - interrupts
+ - power-domains
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
- if:
not:
properties:
compatible:
contains:
- enum:
- - renesas,rza-wdt
- - renesas,rzn1-wdt
+ const: renesas,r8a77980-wdt
then:
required:
- - power-domains
- resets
- - if:
- properties:
- compatible:
- contains:
- enum:
- - renesas,rzg2l-wdt
- then:
- properties:
- interrupts:
- maxItems: 2
- interrupt-names:
- items:
- - const: wdt
- - const: perrout
- clocks:
- items:
- - description: Register access clock
- - description: Main clock
- clock-names:
- items:
- - const: pclk
- - const: oscclk
- required:
- - clock-names
- - interrupt-names
- else:
- properties:
- interrupts:
- maxItems: 1
- clocks:
- maxItems: 1
-
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7795-cpg-mssr.h>
#include <dt-bindings/power/r8a7795-sysc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
wdt0: watchdog@e6020000 {
- compatible = "renesas,r8a7795-wdt", "renesas,rcar-gen3-wdt";
- reg = <0xe6020000 0x0c>;
- clocks = <&cpg CPG_MOD 402>;
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
- resets = <&cpg 402>;
- timeout-sec = <60>;
+ compatible = "renesas,r8a7795-wdt", "renesas,rcar-gen3-wdt";
+ reg = <0xe6020000 0x0c>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 402>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 402>;
+ timeout-sec = <60>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt b/Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt
deleted file mode 100644
index 05b95bfa2a89..000000000000
--- a/Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Ralink Watchdog Timers
-
-Required properties:
-- compatible: must be "ralink,rt2880-wdt"
-- reg: physical base address of the controller and length of the register range
-
-Optional properties:
-- interrupts: Specify the INTC interrupt number
-
-Example:
-
- watchdog@120 {
- compatible = "ralink,rt2880-wdt";
- reg = <0x120 0x10>;
-
- interrupt-parent = <&intc>;
- interrupts = <1>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index b08373336b16..53fc64f5b56d 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -16,13 +16,22 @@ description: |+
properties:
compatible:
- enum:
- - samsung,s3c2410-wdt # for S3C2410
- - samsung,s3c6410-wdt # for S3C6410, S5PV210 and Exynos4
- - samsung,exynos5250-wdt # for Exynos5250
- - samsung,exynos5420-wdt # for Exynos5420
- - samsung,exynos7-wdt # for Exynos7
- - samsung,exynos850-wdt # for Exynos850
+ oneOf:
+ - enum:
+ - google,gs101-wdt # for Google gs101
+ - samsung,s3c2410-wdt # for S3C2410
+ - samsung,s3c6410-wdt # for S3C6410, S5PV210 and Exynos4
+ - samsung,exynos5250-wdt # for Exynos5250
+ - samsung,exynos5420-wdt # for Exynos5420
+ - samsung,exynos7-wdt # for Exynos7
+ - samsung,exynos850-wdt # for Exynos850
+ - samsung,exynos990-wdt # for Exynos990
+ - samsung,exynosautov9-wdt # for Exynosautov9
+ - samsung,exynosautov920-wdt # for Exynosautov920
+ - items:
+ - enum:
+ - tesla,fsd-wdt
+ - const: samsung,exynos7-wdt
reg:
maxItems: 1
@@ -41,13 +50,14 @@ properties:
samsung,cluster-index:
$ref: /schemas/types.yaml#/definitions/uint32
description:
- Index of CPU cluster on which watchdog is running (in case of Exynos850)
+ Index of CPU cluster on which watchdog is running (in case of Exynos850,
+ Exynos990 or Google gs101).
samsung,syscon-phandle:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the PMU system controller node (in case of Exynos5250,
- Exynos5420, Exynos7 and Exynos850).
+ Exynos5420, Exynos7, Exynos850, Exynos990 and gs101).
required:
- compatible
@@ -63,10 +73,14 @@ allOf:
compatible:
contains:
enum:
+ - google,gs101-wdt
- samsung,exynos5250-wdt
- samsung,exynos5420-wdt
- samsung,exynos7-wdt
- samsung,exynos850-wdt
+ - samsung,exynos990-wdt
+ - samsung,exynosautov9-wdt
+ - samsung,exynosautov920-wdt
then:
required:
- samsung,syscon-phandle
@@ -75,7 +89,11 @@ allOf:
compatible:
contains:
enum:
+ - google,gs101-wdt
- samsung,exynos850-wdt
+ - samsung,exynos990-wdt
+ - samsung,exynosautov9-wdt
+ - samsung,exynosautov920-wdt
then:
properties:
clocks:
@@ -87,7 +105,7 @@ allOf:
- const: watchdog
- const: watchdog_src
samsung,cluster-index:
- enum: [0, 1]
+ enum: [0, 1, 2]
required:
- samsung,cluster-index
else:
diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index 6461eb4f4a27..609e98cdaaff 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -6,12 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Synopsys Designware Watchdog Timer
-allOf:
- - $ref: "watchdog.yaml#"
-
maintainers:
- Jamie Iles <jamie@jamieiles.com>
+allOf:
+ - $ref: watchdog.yaml#
+
properties:
compatible:
oneOf:
@@ -20,6 +20,7 @@ properties:
- enum:
- rockchip,px30-wdt
- rockchip,rk3066-wdt
+ - rockchip,rk3128-wdt
- rockchip,rk3188-wdt
- rockchip,rk3228-wdt
- rockchip,rk3288-wdt
@@ -27,8 +28,13 @@ properties:
- rockchip,rk3328-wdt
- rockchip,rk3368-wdt
- rockchip,rk3399-wdt
+ - rockchip,rk3506-wdt
+ - rockchip,rk3562-wdt
- rockchip,rk3568-wdt
+ - rockchip,rk3576-wdt
+ - rockchip,rk3588-wdt
- rockchip,rv1108-wdt
+ - rockchip,rv1126-wdt
- const: snps,dw-wdt
reg:
@@ -71,35 +77,35 @@ properties:
minItems: 16
maxItems: 16
-unevaluatedProperties: false
-
required:
- compatible
- reg
- clocks
+unevaluatedProperties: false
+
examples:
- |
watchdog@ffd02000 {
- compatible = "snps,dw-wdt";
- reg = <0xffd02000 0x1000>;
- interrupts = <0 171 4>;
- clocks = <&per_base_clk>;
- resets = <&wdt_rst>;
+ compatible = "snps,dw-wdt";
+ reg = <0xffd02000 0x1000>;
+ interrupts = <0 171 4>;
+ clocks = <&per_base_clk>;
+ resets = <&wdt_rst>;
};
- |
watchdog@ffd02000 {
- compatible = "snps,dw-wdt";
- reg = <0xffd02000 0x1000>;
- interrupts = <0 171 4>;
- clocks = <&per_base_clk>;
- clock-names = "tclk";
- snps,watchdog-tops = <0x000000FF 0x000001FF 0x000003FF
- 0x000007FF 0x0000FFFF 0x0001FFFF
- 0x0003FFFF 0x0007FFFF 0x000FFFFF
- 0x001FFFFF 0x003FFFFF 0x007FFFFF
- 0x00FFFFFF 0x01FFFFFF 0x03FFFFFF
- 0x07FFFFFF>;
+ compatible = "snps,dw-wdt";
+ reg = <0xffd02000 0x1000>;
+ interrupts = <0 171 4>;
+ clocks = <&per_base_clk>;
+ clock-names = "tclk";
+ snps,watchdog-tops = <0x000000FF 0x000001FF 0x000003FF
+ 0x000007FF 0x0000FFFF 0x0001FFFF
+ 0x0003FFFF 0x0007FFFF 0x000FFFFF
+ 0x001FFFFF 0x003FFFFF 0x007FFFFF
+ 0x00FFFFFF 0x01FFFFFF 0x03FFFFFF
+ 0x07FFFFFF>;
};
...
diff --git a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
index 90698cfa8f94..ba0709314360 100644
--- a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml
@@ -10,7 +10,7 @@ maintainers:
- Keiji Hayashibara <hayashibara.keiji@socionext.com>
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
properties:
compatible:
@@ -25,12 +25,6 @@ examples:
- |
// The UniPhier watchdog should be a subnode of a "syscon" compatible node.
- sysctrl@61840000 {
- compatible = "socionext,uniphier-ld11-sysctrl",
- "simple-mfd", "syscon";
- reg = <0x61840000 0x10000>;
-
- watchdog {
- compatible = "socionext,uniphier-wdt";
- };
+ watchdog {
+ compatible = "socionext,uniphier-wdt";
};
diff --git a/Documentation/devicetree/bindings/watchdog/sprd,sp9860-wdt.yaml b/Documentation/devicetree/bindings/watchdog/sprd,sp9860-wdt.yaml
new file mode 100644
index 000000000000..730d9a3a3cc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sprd,sp9860-wdt.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/sprd,sp9860-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Spreadtrum SP9860 watchdog timer
+
+maintainers:
+ - Orson Zhai <orsonzhai@gmail.com>
+ - Baolin Wang <baolin.wang7@gmail.com>
+ - Chunyan Zhang <zhang.lyra@gmail.com>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: sprd,sp9860-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: enable
+ - const: rtc_enable
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - timeout-sec
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/sprd,sc9860-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ watchdog@40310000 {
+ compatible = "sprd,sp9860-wdt";
+ reg = <0 0x40310000 0 0x1000>;
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&aon_gate CLK_APCPU_WDG_EB>, <&aon_gate CLK_AP_WDG_RTC_EB>;
+ clock-names = "enable", "rtc_enable";
+ timeout-sec = <12>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/watchdog/sprd-wdt.txt b/Documentation/devicetree/bindings/watchdog/sprd-wdt.txt
deleted file mode 100644
index aeaf3e0caf47..000000000000
--- a/Documentation/devicetree/bindings/watchdog/sprd-wdt.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Spreadtrum SoCs Watchdog timer
-
-Required properties:
-- compatible : Should be "sprd,sp9860-wdt".
-- reg : Specifies base physical address and size of the registers.
-- interrupts : Exactly one interrupt specifier.
-- timeout-sec : Contain the default watchdog timeout in seconds.
-- clock-names : Contain the input clock names.
-- clocks : Phandles to input clocks.
-
-Example:
- watchdog: watchdog@40310000 {
- compatible = "sprd,sp9860-wdt";
- reg = <0 0x40310000 0 0x1000>;
- interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
- timeout-sec = <12>;
- clock-names = "enable", "rtc_enable";
- clocks = <&clk_aon_apb_gates1 8>, <&clk_aon_apb_rtc_gates 9>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml
index 39736449ba64..86bd39d50850 100644
--- a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml
+++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/watchdog/st,stm32-iwdg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: STMicroelectronics STM32 Independent WatchDoG (IWDG) bindings
+title: STMicroelectronics STM32 Independent WatchDoG (IWDG)
maintainers:
- Yannick Fertre <yannick.fertre@foss.st.com>
- Christophe Roullier <christophe.roullier@foss.st.com>
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
properties:
compatible:
@@ -36,6 +36,12 @@ properties:
minItems: 1
maxItems: 2
+ interrupts:
+ maxItems: 1
+ description: Pre-timeout interrupt from the watchdog.
+
+ wakeup-source: true
+
required:
- compatible
- reg
@@ -48,11 +54,11 @@ examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
watchdog@5a002000 {
- compatible = "st,stm32mp1-iwdg";
- reg = <0x5a002000 0x400>;
- clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
- clock-names = "pclk", "lsi";
- timeout-sec = <32>;
+ compatible = "st,stm32mp1-iwdg";
+ reg = <0x5a002000 0x400>;
+ clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
+ clock-names = "pclk", "lsi";
+ timeout-sec = <32>;
};
...
diff --git a/Documentation/devicetree/bindings/watchdog/starfive,jh7100-wdt.yaml b/Documentation/devicetree/bindings/watchdog/starfive,jh7100-wdt.yaml
new file mode 100644
index 000000000000..e21f807b0b69
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/starfive,jh7100-wdt.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/starfive,jh7100-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive Watchdog for JH7100 and JH7110 SoC
+
+maintainers:
+ - Xingyu Wu <xingyu.wu@starfivetech.com>
+ - Samin Guo <samin.guo@starfivetech.com>
+
+description:
+ The JH7100 and JH7110 watchdog both are 32 bit counters. JH7100 watchdog
+ has only one timeout phase and reboots. And JH7110 watchdog has two
+ timeout phases. At the first phase, the signal of watchdog interrupt
+ output(WDOGINT) will rise when counter is 0. The counter will reload
+ the timeout value. And then, if counter decreases to 0 again and WDOGINT
+ isn't cleared, the watchdog will reset the system unless the watchdog
+ reset is disabled.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - starfive,jh7100-wdt
+ - starfive,jh7110-wdt
+ - items:
+ - enum:
+ - starfive,jh8100-wdt
+ - const: starfive,jh7110-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: APB clock
+ - description: Core clock
+
+ clock-names:
+ items:
+ - const: apb
+ - const: core
+
+ resets:
+ minItems: 1
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+allOf:
+ - $ref: watchdog.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - starfive,jh8100-wdt
+ then:
+ properties:
+ resets:
+ items:
+ - description: Core reset
+ else:
+ properties:
+ resets:
+ items:
+ - description: APB reset
+ - description: Core reset
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@12480000 {
+ compatible = "starfive,jh7100-wdt";
+ reg = <0x12480000 0x10000>;
+ clocks = <&clk 171>,
+ <&clk 172>;
+ clock-names = "apb", "core";
+ resets = <&rst 99>,
+ <&rst 100>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/technologic,ts7200-wdt.yaml b/Documentation/devicetree/bindings/watchdog/technologic,ts7200-wdt.yaml
new file mode 100644
index 000000000000..7e4bfef152f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/technologic,ts7200-wdt.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/technologic,ts7200-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Technologic Systems TS-72xx based SBCs watchdog
+
+maintainers:
+ - Nikita Shubin <nikita.shubin@maquefel.me>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: technologic,ts7200-wdt
+ - items:
+ - enum:
+ - technologic,ts7300-wdt
+ - technologic,ts7260-wdt
+ - technologic,ts7250-wdt
+ - const: technologic,ts7200-wdt
+
+ reg:
+ items:
+ - description: control register
+ - description: feed register
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@23800000 {
+ compatible = "technologic,ts7200-wdt";
+ reg = <0x23800000 0x01>, <0x23c00000 0x01>;
+ timeout-sec = <30>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/watchdog/ti,davinci-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,davinci-wdt.yaml
new file mode 100644
index 000000000000..3c78f60f5f48
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ti,davinci-wdt.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/ti,davinci-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI DaVinci/Keystone Watchdog Timer Controller
+
+maintainers:
+ - Kousik Sanagavarapu <five231003@gmail.com>
+
+description: |
+ TI's Watchdog Timer Controller for DaVinci and Keystone Processors.
+
+ Datasheets
+
+ Davinci DM646x - https://www.ti.com/lit/ug/spruer5b/spruer5b.pdf
+ Keystone - https://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: ti,keystone-wdt
+ - const: ti,davinci-wdt
+ - items:
+ - const: ti,davinci-wdt
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ wdt: watchdog@22f0080 {
+ compatible = "ti,keystone-wdt", "ti,davinci-wdt";
+ reg = <0x022f0080 0x80>;
+ clocks = <&clkwdtimer0>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/watchdog/ti,omap2-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,omap2-wdt.yaml
new file mode 100644
index 000000000000..913b55222f29
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ti,omap2-wdt.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/ti,omap2-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI OMAP Watchdog Timer Controller
+
+maintainers:
+ - Aaro Koskinen <aaro.koskinen@iki.fi>
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - ti,omap2-wdt
+ - ti,omap3-wdt
+ - items:
+ - enum:
+ - ti,am4372-wdt
+ - ti,omap4-wdt
+ - ti,omap5-wdt
+ - const: ti,omap3-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ti,hwmods:
+ description: Name of the hardware module associated with the watchdog.
+ $ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@48314000 {
+ compatible = "ti,omap3-wdt";
+ reg = <0x48314000 0x80>;
+ ti,hwmods = "wd_timer2";
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml
index 2f33635876ff..62ddc284a524 100644
--- a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml
@@ -18,7 +18,7 @@ description:
to directly reset the SoC.
allOf:
- - $ref: "watchdog.yaml#"
+ - $ref: watchdog.yaml#
properties:
compatible:
@@ -34,6 +34,20 @@ properties:
power-domains:
maxItems: 1
+ memory-region:
+ maxItems: 1
+ description:
+ Contains the watchdog reserved memory. It is optional.
+ In the reserved memory, the specified values, which are
+ PON_REASON_SOF_NUM(0xBBBBCCCC), PON_REASON_MAGIC_NUM(0xDDDDDDDD),
+ and PON_REASON_EOF_NUM(0xCCCCBBBB), are pre-stored at the first
+ 3 * 4 bytes to tell that last boot was caused by watchdog reset.
+ Once the PON reason is captured by driver(rti_wdt.c), the driver
+ is supposed to wipe the whole memory region. Surely, if this
+ property is set, at least 12 bytes reserved memory starting from
+ specific memory address(0xa220000) should be set. More please
+ refer to example.
+
required:
- compatible
- reg
@@ -47,7 +61,18 @@ examples:
/*
* RTI WDT in main domain on J721e SoC. Assigned clocks are used to
* select the source clock for the watchdog, forcing it to tick with
- * a 32kHz clock in this case.
+ * a 32kHz clock in this case. Add a reserved memory(optional) to keep
+ * the watchdog reset cause persistent, which was be written in 12 bytes
+ * starting from 0xa2200000 by RTI Watchdog Firmware, then make it
+ * possible to get watchdog reset cause in driver.
+ *
+ * Reserved memory should be defined as follows:
+ * reserved-memory {
+ * wdt_reset_memory_region: wdt-memory@a2200000 {
+ * reg = <0x00 0xa2200000 0x00 0x1000>;
+ * no-map;
+ * };
+ * }
*/
#include <dt-bindings/soc/ti,sci_pm_domain.h>
@@ -58,4 +83,5 @@ examples:
power-domains = <&k3_pds 252 TI_SCI_PD_EXCLUSIVE>;
assigned-clocks = <&k3_clks 252 1>;
assigned-clock-parents = <&k3_clks 252 5>;
+ memory-region = <&wdt_reset_memory_region>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
index 690e19ce4b87..3e9fd49d935e 100644
--- a/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
@@ -2,8 +2,8 @@
# Copyright 2020 Toshiba Electronic Devices & Storage Corporation
%YAML 1.2
---
-$id: "http://devicetree.org/schemas/watchdog/toshiba,visconti-wdt.yaml#"
-$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+$id: http://devicetree.org/schemas/watchdog/toshiba,visconti-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba Visconti SoCs PIUWDT Watchdog timer
@@ -24,31 +24,25 @@ properties:
clocks:
maxItems: 1
- timeout-sec: true
-
required:
- compatible
- reg
- clocks
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
+ #include <dt-bindings/clock/toshiba,tmpv770x.h>
+
soc {
#address-cells = <2>;
#size-cells = <2>;
- wdt_clk: wdt-clk {
- compatible = "fixed-clock";
- clock-frequency = <150000000>;
- #clock-cells = <0>;
- };
-
- watchdog@28330000 {
+ wdt: watchdog@28330000 {
compatible = "toshiba,visconti-wdt";
reg = <0 0x28330000 0 0x1000>;
- clocks = <&wdt_clk>;
timeout-sec = <20>;
+ clocks = <&pismu TMPV770X_CLK_WDTCLK>;
};
};
diff --git a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
deleted file mode 100644
index 80a37193c0b8..000000000000
--- a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Device tree bindings for twl4030-wdt driver (TWL4030 watchdog)
-
-Required properties:
- compatible = "ti,twl4030-wdt";
-
-Example:
-
-watchdog {
- compatible = "ti,twl4030-wdt";
-};
diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
index e3dfb02f0ca5..77ac23516d6d 100644
--- a/Documentation/devicetree/bindings/watchdog/watchdog.yaml
+++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/watchdog/watchdog.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Watchdog Generic Bindings
+title: Watchdog Common Properties
maintainers:
- Guenter Roeck <linux@roeck-us.net>
@@ -14,11 +14,17 @@ description: |
This document describes generic bindings which can be used to
describe watchdog devices in a device tree.
+select:
+ properties:
+ $nodename:
+ pattern: "^watchdog(@.*|-([0-9]|[1-9][0-9]+))?$"
+
properties:
$nodename:
- pattern: "^watchdog(@.*|-[0-9a-f])?$"
+ pattern: "^(pmic|timer|watchdog)(@.*|-([0-9]|[1-9][0-9]+))?$"
timeout-sec:
+ maxItems: 1
description:
Contains the watchdog timeout in seconds.
diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
new file mode 100644
index 000000000000..14b069599740
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/xlnx,versal-wwdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal window watchdog timer controller
+
+maintainers:
+ - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+ Versal watchdog intellectual property uses window watchdog mode.
+ Window watchdog timer(WWDT) contains closed(first) and open(second)
+ window with 32 bit width. Write to the watchdog timer within
+ predefined window periods of time. This means a period that is not
+ too soon and a period that is not too late. The WWDT has to be
+ restarted within the open window time. If software tries to restart
+ WWDT outside of the open window time period, it generates a reset.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,versal-wwdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@fd4d0000 {
+ compatible = "xlnx,versal-wwdt";
+ reg = <0xfd4d0000 0x10000>;
+ clocks = <&clock25>;
+ timeout-sec = <30>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
new file mode 100644
index 000000000000..dc1ff39d05a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/xlnx,xps-timebase-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx AXI/PLB softcore and window Watchdog Timer
+
+maintainers:
+ - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+ - Srinivas Neeli <srinivas.neeli@amd.com>
+
+description:
+ The Timebase watchdog timer(WDT) is a free-running 32 bit counter.
+ WDT uses a dual-expiration architecture. After one expiration of
+ the timeout interval, an interrupt is generated and the WDT state
+ bit is set to one in the status register. If the state bit is not
+ cleared (by writing a one to the state bit) before the next
+ expiration of the timeout interval, a WDT reset is generated.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,xps-timebase-wdt-1.01.a
+ - xlnx,xps-timebase-wdt-1.00.a
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ description: Frequency of clock in Hz
+
+ xlnx,wdt-interval:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Watchdog timeout interval
+ minimum: 8
+ maximum: 32
+
+ xlnx,wdt-enable-once:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ description: If watchdog is configured as enable once,
+ then the watchdog cannot be disabled after
+ it has been enabled.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@40100000 {
+ compatible = "xlnx,xps-timebase-wdt-1.00.a";
+ reg = <0x40100000 0x1000>;
+ clock-frequency = <50000000>;
+ clocks = <&clkc 15>;
+ xlnx,wdt-enable-once = <0x0>;
+ xlnx,wdt-interval = <0x1b>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
deleted file mode 100644
index 3de96186e92e..000000000000
--- a/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Zodiac Inflight Innovations RAVE Supervisory Processor Watchdog Bindings
-
-RAVE SP watchdog device is a "MFD cell" device corresponding to
-watchdog functionality of RAVE Supervisory Processor. It is expected
-that its Device Tree node is specified as a child of the node
-corresponding to the parent RAVE SP device (as documented in
-Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
-
-Required properties:
-
-- compatible: Depending on wire protocol implemented by RAVE SP
- firmware, should be one of:
- - "zii,rave-sp-watchdog"
- - "zii,rave-sp-watchdog-legacy"
-
-Optional properties:
-
-- wdt-timeout: Two byte nvmem cell specified as per
- Documentation/devicetree/bindings/nvmem/nvmem.txt
-
-Example:
-
- rave-sp {
- compatible = "zii,rave-sp-rdu1";
- current-speed = <38400>;
-
- eeprom {
- wdt_timeout: wdt-timeout@8E {
- reg = <0x8E 2>;
- };
- };
-
- watchdog {
- compatible = "zii,rave-sp-watchdog";
- nvmem-cells = <&wdt_timeout>;
- nvmem-cell-names = "wdt-timeout";
- };
- }
-
diff --git a/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.yaml
new file mode 100644
index 000000000000..de0d56725dd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/zii,rave-sp-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zodiac Inflight Innovations RAVE Supervisory Processor Watchdog
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ RAVE SP watchdog device is a "MFD cell" device corresponding to
+ watchdog functionality of RAVE Supervisory Processor. It is expected
+ that its Device Tree node is specified as a child of the node
+ corresponding to the parent RAVE SP device (as documented in
+ Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml)
+
+properties:
+ compatible:
+ enum:
+ - zii,rave-sp-watchdog
+ - zii,rave-sp-watchdog-legacy
+
+ nvmem-cell-names:
+ items:
+ - const: wdt_timeout
+
+ nvmem-cells:
+ maxItems: 1
+
+required:
+ - compatible
+
+allOf:
+ - $ref: watchdog.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog {
+ compatible = "zii,rave-sp-watchdog";
+ nvmem-cells = <&wdt_timeout>;
+ nvmem-cell-names = "wdt_timeout";
+ };
+
diff --git a/Documentation/devicetree/bindings/watchdog/zii,rave-wdt.yaml b/Documentation/devicetree/bindings/watchdog/zii,rave-wdt.yaml
new file mode 100644
index 000000000000..9dbaa941538e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zii,rave-wdt.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/zii,rave-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Zodiac RAVE Watchdog Timer
+
+maintainers:
+ - Martyn Welch <martyn.welch@collabora.co.uk>
+ - Guenter Roeck <linux@roeck-us.net>
+ - Wim Van Sebroeck <wim@iguana.be>
+
+properties:
+ compatible:
+ const: zii,rave-wdt
+
+ reg:
+ maxItems: 1
+ description: i2c slave address of device, usually 0x38
+
+ reset-duration-ms:
+ description:
+ Duration of the pulse generated when the watchdog times
+ out.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: watchdog.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ watchdog@38 {
+ compatible = "zii,rave-wdt";
+ reg = <0x38>;
+ timeout-sec = <30>;
+ reset-duration-ms = <30>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt b/Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt
deleted file mode 100644
index 3d878184ec3f..000000000000
--- a/Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Zodiac RAVE Watchdog Timer
-
-Required properties:
-- compatible: must be "zii,rave-wdt"
-- reg: i2c slave address of device, usually 0x38
-
-Optional Properties:
-- timeout-sec: Watchdog timeout value in seconds.
-- reset-duration-ms: Duration of the pulse generated when the watchdog times
- out. Value in milliseconds.
-
-Example:
-
- watchdog@38 {
- compatible = "zii,rave-wdt";
- reg = <0x38>;
- timeout-sec = <30>;
- reset-duration-ms = <30>;
- };
diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst
index 1ad081de2dd0..667816dd7d50 100644
--- a/Documentation/devicetree/bindings/writing-bindings.rst
+++ b/Documentation/devicetree/bindings/writing-bindings.rst
@@ -31,18 +31,39 @@ Overall design
devices only need child nodes when the child nodes have their own DT
resources. A single node can be multiple providers (e.g. clocks and resets).
+- DON'T treat device node names as a stable ABI, but instead use phandles or
+ compatibles to find sibling devices. Exception: sub-nodes of given device
+ could be treated as ABI, if explicitly documented in the bindings.
+
- DON'T use 'syscon' alone without a specific compatible string. A 'syscon'
hardware block should have a compatible string unique enough to infer the
register layout of the entire block (at a minimum).
+- DON'T use 'simple-mfd' compatible for non-trivial devices, where children
+ depend on some resources from the parent. Similarly, 'simple-bus' should not
+ be used for complex buses and even 'regs' property means device is not
+ a simple bus.
+
Properties
==========
-- DO make 'compatible' properties specific. DON'T use wildcards in compatible
- strings. DO use fallback compatibles when devices are the same as or a subset
- of prior implementations. DO add new compatibles in case there are new
- features or bugs.
+- DO make 'compatible' properties specific.
+
+ - DON'T use wildcards or device-family names in compatible strings.
+
+ - DO use fallback compatibles when devices are the same as or a superset of
+ prior implementations.
+
+ - DO add new compatibles in case there are new features or bugs.
+
+ - DO use a SoC-specific compatible for all SoC devices, followed by a
+ fallback if appropriate. SoC-specific compatibles are also preferred for
+ the fallbacks.
+
+ - DON'T use bus suffixes to encode the type of interface device is using.
+ The parent bus node already implies that interface. DON'T add the type of
+ device, if the device cannot be anything else.
- DO use a vendor prefix on device-specific property names. Consider if
properties could be common among devices of the same class. Check other
@@ -51,12 +72,21 @@ Properties
- DON'T redefine common properties. Just reference the definition and define
constraints specific to the device.
+- DON'T add properties to avoid a specific compatible. DON'T add properties if
+ they are implied by (deducible from) the compatible.
+
- DO use common property unit suffixes for properties with scientific units.
Recommended suffixes are listed at
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
- DO define properties in terms of constraints. How many entries? What are
- possible values? What is the order?
+ possible values? What is the order? All these constraints represent the ABI
+ as well.
+
+- DON'T make changes that break the ABI without explicit and detailed rationale
+ for why the changes have to be made and their impact. ABI impact goes beyond
+ the Linux kernel, because it also covers other open-source upstream projects.
+
Typical cases and caveats
=========================
@@ -64,7 +94,7 @@ Typical cases and caveats
- Phandle entries, like clocks/dmas/interrupts/resets, should always be
explicitly ordered. Include the {clock,dma,interrupt,reset}-names if there is
more than one phandle. When used, both of these fields need the same
- constraints (e.g. list of items).
+ constraints (e.g. list of items).
- For names used in {clock,dma,interrupt,reset}-names, do not add any suffix,
e.g.: "tx" instead of "txirq" (for interrupt).
@@ -84,6 +114,15 @@ Typical cases and caveats
- "syscon" is not a generic property. Use vendor and type, e.g.
"vendor,power-manager-syscon".
+- Do not add instance index (IDs) properties or custom OF aliases. If the
+ devices have different programming model, they might need different
+ compatibles. If such devices use some other device in a different way, e.g.
+ they program the phy differently, use cell/phandle arguments.
+
+- Bindings files should be named like compatible: vendor,device.yaml. In case
+ of multiple compatibles in the binding, use one of the fallbacks or a more
+ generic name, yet still matching compatible style.
+
Board/SoC .dts Files
====================
diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst
index 4a381d20f2b4..05c34248e544 100644
--- a/Documentation/devicetree/bindings/writing-schema.rst
+++ b/Documentation/devicetree/bindings/writing-schema.rst
@@ -31,7 +31,7 @@ $schema
Indicates the meta-schema the schema file adheres to.
title
- A one-line description on the contents of the binding schema.
+ A one-line description of the hardware being described in the binding schema.
maintainers
A DT specific property. Contains a list of email address(es)
@@ -39,10 +39,40 @@ maintainers
description
Optional. A multi-line text block containing any detailed
- information about this binding. It should contain things such as what the block
+ information about this hardware. It should contain things such as what the block
or device does, standards the device conforms to, and links to datasheets for
more information.
+ The YAML format has several options for defining the formatting of the text
+ block. The options are controlled with indicator characters following the key
+ (e.g. "description: \|"). The minimum formatting needed for a block should be
+ used. The formatting controls can not only affect whether the YAML can be
+ parsed correctly, but are important when the text blocks are rendered to
+ another form. The options are as follows.
+
+ The default without any indicators is flowed, plain scalar style where single
+ line breaks and leading whitespace are stripped. Paragraphs are delimited by
+ blank lines (i.e. double line break). This style cannot contain ": " in it as
+ it will be interpreted as a key. Any " #" sequence will be interpreted as
+ a comment. There's other restrictions on characters as well. Most
+ restrictions are on what the first character can be.
+
+ The second style is folded which is indicated by ">" character. In addition
+ to maintaining line breaks on double line breaks, the folded style also
+ maintains leading whitespace beyond indentation of the first line. The line
+ breaks on indented lines are also maintained.
+
+ The third style is literal which is indicated by "\|" character. The literal
+ style maintains all line breaks and whitespace (beyond indentation of the
+ first line).
+
+ The above is not a complete description of YAML text blocks. More details on
+ multi-line YAML text blocks can be found online:
+
+ https://yaml-multiline.info/
+
+ https://www.yaml.info/learn/quote.html
+
select
Optional. A json-schema used to match nodes for applying the
schema. By default, without 'select', nodes are matched against their possible
@@ -71,9 +101,36 @@ required
A list of DT properties from the 'properties' section that
must always be present.
+additionalProperties / unevaluatedProperties
+ Keywords controlling how schema will validate properties not matched by this
+ schema's 'properties' or 'patternProperties'. Each schema is supposed to
+ have exactly one of these keywords in top-level part, so either
+ additionalProperties or unevaluatedProperties. Nested nodes, so properties
+ being objects, are supposed to have one as well.
+
+ * additionalProperties: false
+ Most common case, where no additional schema is referenced or if this
+ binding allows subset of properties from other referenced schemas.
+
+ * unevaluatedProperties: false
+ Used when this binding references other schema whose all properties
+ should be allowed.
+
+ * additionalProperties: true
+ - Top-level part:
+ Rare case, used for schemas implementing common set of properties. Such
+ schemas are supposed to be referenced by other schemas, which then use
+ 'unevaluatedProperties: false'. Typically bus or common-part schemas.
+ - Nested node:
+ When listing only the expected compatible of the nested node and there
+ is an another schema matching that compatible which ends with one of
+ two above cases ('false').
+
examples
- Optional. A list of one or more DTS hunks implementing the
- binding. Note: YAML doesn't allow leading tabs, so spaces must be used instead.
+ Optional. A list of one or more DTS hunks implementing this binding only.
+ Example should not contain unrelated device nodes, e.g. consumer nodes in a
+ provider binding, other nodes referenced by phandle.
+ Note: YAML doesn't allow leading tabs, so spaces must be used instead.
Unless noted otherwise, all properties are required.
@@ -108,12 +165,23 @@ The YAML Devicetree format also makes all string values an array and scalar
values a matrix (in order to define groupings) even when only a single value
is present. Single entries in schemas are fixed up to match this encoding.
+When bindings cover multiple similar devices that differ in some properties,
+those properties should be constrained for each device. This usually means:
+
+ * In top level 'properties' define the property with the broadest constraints.
+ * In 'if:then:' blocks, further narrow the constraints for those properties.
+ * Do not define the properties within an 'if:then:' block (note that
+ 'additionalItems' also won't allow that).
+
Coding style
------------
Use YAML coding style (two-space indentation). For DTS examples in the schema,
preferred is four-space indentation.
+Place entries in 'properties' and 'required' sections in the same order, using
+style from Documentation/devicetree/bindings/dts-coding-style.rst.
+
Testing
-------
@@ -159,11 +227,14 @@ It is possible to run both in a single command::
make dt_binding_check dtbs_check
It is also possible to run checks with a subset of matching schema files by
-setting the ``DT_SCHEMA_FILES`` variable to a specific schema file or pattern.
+setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or
+patterns (partial match of a fixed string). Each file or pattern should be
+separated by ':'.
::
make dt_binding_check DT_SCHEMA_FILES=trivial-devices.yaml
+ make dt_binding_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml
make dt_binding_check DT_SCHEMA_FILES=/gpio/
make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
diff --git a/Documentation/devicetree/bindings/xilinx.txt b/Documentation/devicetree/bindings/xilinx.txt
index 28199b31fe5e..0ee9de99b3ae 100644
--- a/Documentation/devicetree/bindings/xilinx.txt
+++ b/Documentation/devicetree/bindings/xilinx.txt
@@ -102,15 +102,6 @@
Default is <d#1024 d#480>.
- rotate-display (empty) : rotate display 180 degrees.
- ii) Xilinx SystemACE
-
- The Xilinx SystemACE device is used to program FPGAs from an FPGA
- bitstream stored on a CF card. It can also be used as a generic CF
- interface device.
-
- Optional properties:
- - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
-
iii) Xilinx EMAC and Xilinx TEMAC
Xilinx Ethernet devices. In addition to general xilinx properties
@@ -118,13 +109,6 @@
property, and may include other common network device properties
like local-mac-address.
- iv) Xilinx Uartlite
-
- Xilinx uartlite devices are simple fixed speed serial ports.
-
- Required properties:
- - current-speed : Baud rate of uartlite
-
v) Xilinx hwicap
Xilinx hwicap devices provide access to the configuration logic
@@ -141,16 +125,6 @@
- compatible : should contain "xlnx,xps-hwicap-1.00.a" or
"xlnx,opb-hwicap-1.00.b".
- vi) Xilinx Uart 16550
-
- Xilinx UART 16550 devices are very similar to the NS16550 but with
- different register spacing and an offset from the base address.
-
- Required properties:
- - clock-frequency : Frequency of the clock input
- - reg-offset : A value of 3 is required
- - reg-shift : A value of 2 is required
-
vii) Xilinx USB Host controller
The Xilinx USB host controller is EHCI compatible but with a different
diff --git a/Documentation/devicetree/of_unittest.rst b/Documentation/devicetree/of_unittest.rst
index 8864b52d1195..8b557acd29d1 100644
--- a/Documentation/devicetree/of_unittest.rst
+++ b/Documentation/devicetree/of_unittest.rst
@@ -50,15 +50,13 @@ from 'scripts/dtc/of_unittest_expect --help'.
The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
the test data required for executing the unit tests automated in
-drivers/of/unittest.c. Currently, following Device Tree Source Include files
-(.dtsi) are included in testcases.dts::
+drivers/of/unittest.c. See the content of the folder::
- drivers/of/unittest-data/tests-interrupts.dtsi
- drivers/of/unittest-data/tests-platform.dtsi
- drivers/of/unittest-data/tests-phandle.dtsi
- drivers/of/unittest-data/tests-match.dtsi
+ drivers/of/unittest-data/tests-*.dtsi
-When the kernel is build with OF_SELFTEST enabled, then the following make
+for the Device Tree Source Include files (.dtsi) included in testcases.dts.
+
+When the kernel is built with CONFIG_OF_UNITTEST enabled, then the following make
rule::
$(obj)/%.dtb: $(src)/%.dts FORCE
@@ -135,7 +133,7 @@ via the following kernel symbols::
__dtb_testcases_end - address marking the end of test data blob
Secondly, it calls of_fdt_unflatten_tree() to unflatten the flattened
-blob. And finally, if the machine's device tree (i.e live tree) is present,
+blob. And finally, if the machine's device tree (i.e. live tree) is present,
then it attaches the unflattened test data tree to the live tree, else it
attaches itself as a live device tree.
diff --git a/Documentation/devicetree/overlay-notes.rst b/Documentation/devicetree/overlay-notes.rst
index e139f22b363e..ba401ef850e7 100644
--- a/Documentation/devicetree/overlay-notes.rst
+++ b/Documentation/devicetree/overlay-notes.rst
@@ -14,11 +14,11 @@ How overlays work
A Devicetree's overlay purpose is to modify the kernel's live tree, and
have the modification affecting the state of the kernel in a way that
is reflecting the changes.
-Since the kernel mainly deals with devices, any new device node that result
+Since the kernel mainly deals with devices, any new device node that results
in an active device should have it created while if the device node is either
disabled or removed all together, the affected device should be deregistered.
-Lets take an example where we have a foo board with the following base tree::
+Let's take an example where we have a foo board with the following base tree::
---- foo.dts ---------------------------------------------------------------
/* FOO platform */
@@ -38,10 +38,10 @@ Lets take an example where we have a foo board with the following base tree::
};
---- foo.dts ---------------------------------------------------------------
-The overlay bar.dts,
+The overlay bar.dtso,
::
- ---- bar.dts - overlay target location by label ----------------------------
+ ---- bar.dtso - overlay target location by label ---------------------------
/dts-v1/;
/plugin/;
&ocp {
@@ -51,7 +51,7 @@ The overlay bar.dts,
... /* various properties and child nodes */
};
};
- ---- bar.dts ---------------------------------------------------------------
+ ---- bar.dtso --------------------------------------------------------------
when loaded (and resolved as described in [1]) should result in foo+bar.dts::
@@ -88,9 +88,9 @@ in the base DT. In this case, the target path can be provided. The target
location by label syntax is preferred because the overlay can be applied to
any base DT containing the label, no matter where the label occurs in the DT.
-The above bar.dts example modified to use target path syntax is::
+The above bar.dtso example modified to use target path syntax is::
- ---- bar.dts - overlay target location by explicit path --------------------
+ ---- bar.dtso - overlay target location by explicit path -------------------
/dts-v1/;
/plugin/;
&{/ocp} {
@@ -100,7 +100,7 @@ The above bar.dts example modified to use target path syntax is::
... /* various properties and child nodes */
}
};
- ---- bar.dts ---------------------------------------------------------------
+ ---- bar.dtso --------------------------------------------------------------
Overlay in-kernel API
@@ -111,7 +111,7 @@ The API is quite easy to use.
1) Call of_overlay_fdt_apply() to create and apply an overlay changeset. The
return value is an error or a cookie identifying this overlay.
-2) Call of_overlay_remove() to remove and cleanup the overlay changeset
+2) Call of_overlay_remove() to remove and clean up the overlay changeset
previously created via the call to of_overlay_fdt_apply(). Removal of an
overlay changeset that is stacked by another will not be permitted.
diff --git a/Documentation/devicetree/usage-model.rst b/Documentation/devicetree/usage-model.rst
index b6a287955ee5..c6146c96ac56 100644
--- a/Documentation/devicetree/usage-model.rst
+++ b/Documentation/devicetree/usage-model.rst
@@ -46,7 +46,7 @@ The DT was originally created by Open Firmware as part of the
communication method for passing data from Open Firmware to a client
program (like to an operating system). An operating system used the
Device Tree to discover the topology of the hardware at runtime, and
-thereby support a majority of available hardware without hard coded
+thereby supported a majority of available hardware without hard coded
information (assuming drivers were available for all devices).
Since Open Firmware is commonly used on PowerPC and SPARC platforms,
@@ -128,7 +128,7 @@ successor, the BeagleBoard xM board might look like, respectively::
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
-claims that it compatible with the OMAP 3450 SoC, and the omap3 family
+claims that it is compatible with the OMAP 3450 SoC, and the omap3 family
of SoCs in general. You'll notice that the list is sorted from most
specific (exact board) to least specific (SoC family).
@@ -205,7 +205,7 @@ platform-specific configuration data.
During early boot, the architecture setup code calls of_scan_flat_dt()
several times with different helper callbacks to parse device tree
-data before paging is setup. The of_scan_flat_dt() code scans through
+data before paging is set up. The of_scan_flat_dt() code scans through
the device tree and uses the helpers to extract information required
during early boot. Typically the early_init_dt_scan_chosen() helper
is used to parse the chosen node including kernel parameters,
@@ -415,6 +415,6 @@ When using the DT, this creates problems for of_platform_populate()
because it must decide whether to register each node as either a
platform_device or an amba_device. This unfortunately complicates the
device creation model a little bit, but the solution turns out not to
-be too invasive. If a node is compatible with "arm,amba-primecell", then
+be too invasive. If a node is compatible with "arm,primecell", then
of_platform_populate() will register it as an amba_device instead of a
platform_device.
diff --git a/Documentation/doc-guide/checktransupdate.rst b/Documentation/doc-guide/checktransupdate.rst
new file mode 100644
index 000000000000..7b25375cc6d9
--- /dev/null
+++ b/Documentation/doc-guide/checktransupdate.rst
@@ -0,0 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Checking for needed translation updates
+=======================================
+
+This script helps track the translation status of the documentation in
+different locales, i.e., whether the documentation is up-to-date with
+the English counterpart.
+
+How it works
+------------
+
+It uses ``git log`` command to track the latest English commit from the
+translation commit (order by author date) and the latest English commits
+from HEAD. If any differences occur, the file is considered as out-of-date,
+then commits that need to be updated will be collected and reported.
+
+Features implemented
+
+- check all files in a certain locale
+- check a single file or a set of files
+- provide options to change output format
+- track the translation status of files that have no translation
+
+Usage
+-----
+
+::
+
+ tools/docs/checktransupdate.py --help
+
+Please refer to the output of argument parser for usage details.
+
+Samples
+
+- ``tools/docs/checktransupdate.py -l zh_CN``
+ This will print all the files that need to be updated in the zh_CN locale.
+- ``tools/docs/checktransupdate.py Documentation/translations/zh_CN/dev-tools/testing-overview.rst``
+ This will only print the status of the specified file.
+
+Then the output is something like:
+
+::
+
+ Documentation/dev-tools/kfence.rst
+ No translation in the locale of zh_CN
+
+ Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+ commit 42fb9cfd5b18 ("Documentation: dev-tools: Add link to RV docs")
+ 1 commits needs resolving in total
+
+Features to be implemented
+
+- files can be a folder instead of only a file
diff --git a/Documentation/doc-guide/contributing.rst b/Documentation/doc-guide/contributing.rst
index d4793826ad9a..f8047e633113 100644
--- a/Documentation/doc-guide/contributing.rst
+++ b/Documentation/doc-guide/contributing.rst
@@ -138,6 +138,10 @@ times, but it's highly important. If we can actually eliminate warnings
from the documentation build, then we can start expecting developers to
avoid adding new ones.
+In addition to warnings from the regular documentation build, you can also
+run ``make refcheckdocs`` to find references to nonexistent documentation
+files.
+
Languishing kerneldoc comments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -148,7 +152,7 @@ generate links to that documentation. Adding ``kernel-doc`` directives to
the documentation to bring those comments in can help the community derive
the full value of the work that has gone into creating them.
-The ``scripts/find-unused-docs.sh`` tool can be used to find these
+The ``tools/docs/find-unused-docs.sh`` tool can be used to find these
overlooked comments.
Note that the most value comes from pulling in the documentation for
diff --git a/Documentation/doc-guide/index.rst b/Documentation/doc-guide/index.rst
index 7c7d97784626..24d058faa75c 100644
--- a/Documentation/doc-guide/index.rst
+++ b/Documentation/doc-guide/index.rst
@@ -12,6 +12,7 @@ How to write kernel documentation
parse-headers
contributing
maintainer-profile
+ checktransupdate
.. only:: subproject and html
diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst
index 1dcbd7332476..fd89a6d56ea9 100644
--- a/Documentation/doc-guide/kernel-doc.rst
+++ b/Documentation/doc-guide/kernel-doc.rst
@@ -143,7 +143,7 @@ Return values
~~~~~~~~~~~~~
The return value, if any, should be described in a dedicated section
-named ``Return``.
+named ``Return`` (or ``Returns``).
.. note::
@@ -151,9 +151,9 @@ named ``Return``.
line breaks, so if you try to format some text nicely, as in::
* Return:
- * 0 - OK
- * -EINVAL - invalid argument
- * -ENOMEM - out of memory
+ * %0 - OK
+ * %-EINVAL - invalid argument
+ * %-ENOMEM - out of memory
this will all run together and produce::
@@ -163,8 +163,8 @@ named ``Return``.
ReST list, e. g.::
* Return:
- * * 0 - OK to runtime suspend the device
- * * -EBUSY - Device should not be runtime suspended
+ * * %0 - OK to runtime suspend the device
+ * * %-EBUSY - Device should not be runtime suspended
#) If the descriptive text you provide has lines that begin with
some phrase followed by a colon, each of those phrases will be taken
@@ -337,10 +337,55 @@ Typedefs with function prototypes can also be documented::
* Description of the type.
*
* Context: Locking context.
- * Return: Meaning of the return value.
+ * Returns: Meaning of the return value.
*/
typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2);
+Object-like macro documentation
+-------------------------------
+
+Object-like macros are distinct from function-like macros. They are
+differentiated by whether the macro name is immediately followed by a
+left parenthesis ('(') for function-like macros or not followed by one
+for object-like macros.
+
+Function-like macros are handled like functions by ``scripts/kernel-doc``.
+They may have a parameter list. Object-like macros have do not have a
+parameter list.
+
+The general format of an object-like macro kernel-doc comment is::
+
+ /**
+ * define object_name - Brief description.
+ *
+ * Description of the object.
+ */
+
+Example::
+
+ /**
+ * define MAX_ERRNO - maximum errno value that is supported
+ *
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a normal
+ * pointer with the same return value.
+ */
+ #define MAX_ERRNO 4095
+
+Example::
+
+ /**
+ * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
+ * Initializes struct drm_plane_helper_funcs for VRAM handling
+ *
+ * This macro initializes struct drm_plane_helper_funcs to use the
+ * respective helper functions.
+ */
+ #define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \
+ .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \
+ .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb
+
+
Highlights and cross-references
-------------------------------
@@ -360,6 +405,10 @@ Domain`_ references.
``%CONST``
Name of a constant. (No cross-referencing, just formatting.)
+ Examples::
+
+ %0 %NULL %-1 %-EFAULT %-EINVAL %-ENOMEM
+
````literal````
A literal block that should be handled as-is. The output will use a
``monospaced font``.
@@ -488,6 +537,7 @@ identifiers: *[ function/type ...]*
Include documentation for each *function* and *type* in *source*.
If no *function* is specified, the documentation for all functions
and types in the *source* will be included.
+ *type* can be a struct, union, enum, or typedef identifier.
Examples::
@@ -533,20 +583,23 @@ source.
How to use kernel-doc to generate man pages
-------------------------------------------
-If you just want to use kernel-doc to generate man pages you can do this
-from the kernel git tree::
+To generate man pages for all files that contain kernel-doc markups, run::
+
+ $ make mandocs
+
+Or calling ``script-build-wrapper`` directly::
- $ scripts/kernel-doc -man \
- $(git grep -l '/\*\*' -- :^Documentation :^tools) \
- | scripts/split-man.pl /tmp/man
+ $ ./tools/docs/sphinx-build-wrapper mandocs
-Some older versions of git do not support some of the variants of syntax for
-path exclusion. One of the following commands may work for those versions::
+The output will be at ``/man`` directory inside the output directory
+(by default: ``Documentation/output``).
- $ scripts/kernel-doc -man \
- $(git grep -l '/\*\*' -- . ':!Documentation' ':!tools') \
- | scripts/split-man.pl /tmp/man
+Optionally, it is possible to generate a partial set of man pages by
+using SPHINXDIRS:
+
+ $ make SPHINXDIRS=driver-api/media mandocs
+
+.. note::
- $ scripts/kernel-doc -man \
- $(git grep -l '/\*\*' -- . ":(exclude)Documentation" ":(exclude)tools") \
- | scripts/split-man.pl /tmp/man
+ When SPHINXDIRS={subdir} is used, it will only generate man pages for
+ the files explicitly inside a ``Documentation/{subdir}/.../*.rst`` file.
diff --git a/Documentation/doc-guide/maintainer-profile.rst b/Documentation/doc-guide/maintainer-profile.rst
index 755d39f0d407..db3636d0d71d 100644
--- a/Documentation/doc-guide/maintainer-profile.rst
+++ b/Documentation/doc-guide/maintainer-profile.rst
@@ -27,6 +27,13 @@ documentation and ensure that no new errors or warnings have been
introduced. Generating HTML documents and looking at the result will help
to avoid unsightly misunderstandings about how things will be rendered.
+All new documentation (including additions to existing documents) should
+ideally justify who the intended target audience is somewhere in the
+changelog; this way, we ensure that the documentation ends up in the correct
+place. Some possible categories are: kernel developers (experts or
+beginners), userspace programmers, end users and/or system administrators,
+and distributors.
+
Key cycle dates
---------------
diff --git a/Documentation/doc-guide/parse-headers.rst b/Documentation/doc-guide/parse-headers.rst
index 5da0046f7059..a7bb01ff04eb 100644
--- a/Documentation/doc-guide/parse-headers.rst
+++ b/Documentation/doc-guide/parse-headers.rst
@@ -5,173 +5,168 @@ Including uAPI header files
Sometimes, it is useful to include header files and C example codes in
order to describe the userspace API and to generate cross-references
between the code and the documentation. Adding cross-references for
-userspace API files has an additional vantage: Sphinx will generate warnings
+userspace API files has an additional advantage: Sphinx will generate warnings
if a symbol is not found at the documentation. That helps to keep the
uAPI documentation in sync with the Kernel changes.
-The :ref:`parse_headers.pl <parse_headers>` provide a way to generate such
+The :ref:`parse_headers.py <parse_headers>` provides a way to generate such
cross-references. It has to be called via Makefile, while building the
documentation. Please see ``Documentation/userspace-api/media/Makefile`` for an example
about how to use it inside the Kernel tree.
.. _parse_headers:
-parse_headers.pl
-^^^^^^^^^^^^^^^^
+tools/docs/parse_headers.py
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
NAME
****
-
-parse_headers.pl - parse a C file, in order to identify functions, structs,
+parse_headers.py - parse a C file, in order to identify functions, structs,
enums and defines and create cross-references to a Sphinx book.
+USAGE
+*****
+
+parse-headers.py [-h] [-d] [-t] ``FILE_IN`` ``FILE_OUT`` ``FILE_RULES``
SYNOPSIS
********
-
-\ **parse_headers.pl**\ [<options>] <C_FILE> <OUT_FILE> [<EXCEPTIONS_FILE>]
-
-Where <options> can be: --debug, --help or --usage.
-
-
-OPTIONS
-*******
-
-
-
-\ **--debug**\
-
- Put the script in verbose mode, useful for debugging.
-
-
-
-\ **--usage**\
-
- Prints a brief help message and exits.
-
-
-
-\ **--help**\
-
- Prints a more detailed help message and exits.
-
-
-DESCRIPTION
-***********
-
-
-Convert a C header or source file (C_FILE), into a ReStructured Text
+Converts a C header or source file ``FILE_IN`` into a ReStructured Text
included via ..parsed-literal block with cross-references for the
documentation files that describe the API. It accepts an optional
-EXCEPTIONS_FILE with describes what elements will be either ignored or
-be pointed to a non-default reference.
-
-The output is written at the (OUT_FILE).
+``FILE_RULES`` file to describe what elements will be either ignored or
+be pointed to a non-default reference type/name.
-It is capable of identifying defines, functions, structs, typedefs,
-enums and enum symbols and create cross-references for all of them.
-It is also capable of distinguish #define used for specifying a Linux
-ioctl.
+The output is written at ``FILE_OUT``.
-The EXCEPTIONS_FILE contain two types of statements: \ **ignore**\ or \ **replace**\ .
+It is capable of identifying ``define``, ``struct``, ``typedef``, ``enum``
+and enum ``symbol``, creating cross-references for all of them.
-The syntax for the ignore tag is:
+It is also capable of distinguishing ``#define`` used for specifying
+Linux-specific macros used to define ``ioctl``.
+The optional ``FILE_RULES`` contains a set of rules like::
-ignore \ **type**\ \ **name**\
+ ignore ioctl VIDIOC_ENUM_FMT
+ replace ioctl VIDIOC_DQBUF vidioc_qbuf
+ replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ :c:type:`v4l2_event_motion_det`
-The \ **ignore**\ means that it won't generate cross references for a
-\ **name**\ symbol of type \ **type**\ .
+POSITIONAL ARGUMENTS
+********************
-The syntax for the replace tag is:
+ ``FILE_IN``
+ Input C file
+ ``FILE_OUT``
+ Output RST file
-replace \ **type**\ \ **name**\ \ **new_value**\
+ ``FILE_RULES``
+ Exceptions file (optional)
-The \ **replace**\ means that it will generate cross references for a
-\ **name**\ symbol of type \ **type**\ , but, instead of using the default
-replacement rule, it will use \ **new_value**\ .
-
-For both statements, \ **type**\ can be either one of the following:
+OPTIONS
+*******
+ ``-h``, ``--help``
+ show a help message and exit
+ ``-d``, ``--debug``
+ Increase debug level. Can be used multiple times
+ ``-t``, ``--toc``
+ instead of a literal block, outputs a TOC table at the RST file
-\ **ioctl**\
- The ignore or replace statement will apply to ioctl definitions like:
+DESCRIPTION
+***********
- #define VIDIOC_DBG_S_REGISTER _IOW('V', 79, struct v4l2_dbg_register)
+Creates an enriched version of a Kernel header file with cross-links
+to each C data structure type, from ``FILE_IN``, formatting it with
+reStructuredText notation, either as-is or as a table of contents.
+It accepts an optional ``FILE_RULES`` which describes what elements will be
+either ignored or be pointed to a non-default reference, and optionally
+defines the C namespace to be used.
+It is meant to allow having more comprehensive documentation, where
+uAPI headers will create cross-reference links to the code.
-\ **define**\
+The output is written at the ``FILE_OUT``.
- The ignore or replace statement will apply to any other #define found
- at C_FILE.
+The ``FILE_RULES`` may contain contain three types of statements:
+**ignore**, **replace** and **namespace**.
+By default, it create rules for all symbols and defines, but it also
+allows parsing an exception file. Such file contains a set of rules
+using the syntax below:
+1. Ignore rules:
-\ **typedef**\
+ ignore *type* *symbol*
- The ignore or replace statement will apply to typedef statements at C_FILE.
+Removes the symbol from reference generation.
+2. Replace rules:
+ replace *type* *old_symbol* *new_reference*
-\ **struct**\
+ Replaces *old_symbol* with a *new_reference*.
+ The *new_reference* can be:
- The ignore or replace statement will apply to the name of struct statements
- at C_FILE.
+ - A simple symbol name;
+ - A full Sphinx reference.
+3. Namespace rules
+ namespace *namespace*
-\ **enum**\
+ Sets C *namespace* to be used during cross-reference generation. Can
+ be overridden by replace rules.
- The ignore or replace statement will apply to the name of enum statements
- at C_FILE.
+On ignore and replace rules, *type* can be:
+ - ioctl:
+ for defines of the form ``_IO*``, e.g., ioctl definitions
+ - define:
+ for other defines
-\ **symbol**\
+ - symbol:
+ for symbols defined within enums;
- The ignore or replace statement will apply to the name of enum value
- at C_FILE.
+ - typedef:
+ for typedefs;
- For replace statements, \ **new_value**\ will automatically use :c:type:
- references for \ **typedef**\ , \ **enum**\ and \ **struct**\ types. It will use :ref:
- for \ **ioctl**\ , \ **define**\ and \ **symbol**\ types. The type of reference can
- also be explicitly defined at the replace statement.
+ - enum:
+ for the name of a non-anonymous enum;
+ - struct:
+ for structs.
EXAMPLES
********
+- Ignore a define ``_VIDEODEV2_H`` at ``FILE_IN``::
-ignore define _VIDEODEV2_H
-
-
-Ignore a #define _VIDEODEV2_H at the C_FILE.
-
-ignore symbol PRIVATE
-
+ ignore define _VIDEODEV2_H
-On a struct like:
+- On an data structure like this enum::
-enum foo { BAR1, BAR2, PRIVATE };
+ enum foo { BAR1, BAR2, PRIVATE };
-It won't generate cross-references for \ **PRIVATE**\ .
+ It won't generate cross-references for ``PRIVATE``::
-replace symbol BAR1 :c:type:\`foo\`
-replace symbol BAR2 :c:type:\`foo\`
+ ignore symbol PRIVATE
+ At the same struct, instead of creating one cross reference per symbol,
+ make them all point to the ``enum foo`` C type::
-On a struct like:
+ replace symbol BAR1 :c:type:\`foo\`
+ replace symbol BAR2 :c:type:\`foo\`
-enum foo { BAR1, BAR2, PRIVATE };
-It will make the BAR1 and BAR2 enum symbols to cross reference the foo
-symbol at the C domain.
+- Use C namespace ``MC`` for all symbols at ``FILE_IN``::
+ namespace MC
BUGS
****
@@ -184,7 +179,7 @@ COPYRIGHT
*********
-Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab+samsung@kernel.org>.
+Copyright (c) 2016, 2025 by Mauro Carvalho Chehab <mchehab+huawei@kernel.org>.
License GPLv2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>.
diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst
index c708cec889af..51c370260f3b 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -28,7 +28,7 @@ Sphinx Install
==============
The ReST markups currently used by the Documentation/ files are meant to be
-built with ``Sphinx`` version 1.7 or higher.
+built with ``Sphinx`` version 3.4.3 or higher.
There's a script that checks for the Sphinx requirements. Please see
:ref:`sphinx-pre-install` for further details.
@@ -42,19 +42,14 @@ with your distributions. In order to do so, it is recommended to install
Sphinx inside a virtual environment, using ``virtualenv-3``
or ``virtualenv``, depending on how your distribution packaged Python 3.
-.. note::
-
- #) It is recommended to use the RTD theme for html output. Depending
- on the Sphinx version, it should be installed separately,
- with ``pip install sphinx_rtd_theme``.
-
-In summary, if you want to install Sphinx version 2.4.4, you should do::
+In summary, if you want to install the latest version of Sphinx, you
+should do::
- $ virtualenv sphinx_2.4.4
- $ . sphinx_2.4.4/bin/activate
- (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt
+ $ virtualenv sphinx_latest
+ $ . sphinx_latest/bin/activate
+ (sphinx_latest) $ pip install -r Documentation/sphinx/requirements.txt
-After running ``. sphinx_2.4.4/bin/activate``, the prompt will change,
+After running ``. sphinx_latest/bin/activate``, the prompt will change,
in order to indicate that you're using the new environment. If you
open a new shell, you need to rerun this command to enter again at
the virtual environment before building the documentation.
@@ -63,8 +58,7 @@ Image output
------------
The kernel documentation build system contains an extension that
-handles images on both GraphViz and SVG formats (see
-:ref:`sphinx_kfigure`).
+handles images in both GraphViz and SVG formats (see :ref:`sphinx_kfigure`).
For it to work, you need to install both GraphViz and ImageMagick
packages. If those packages are not installed, the build system will
@@ -108,11 +102,11 @@ further info.
Checking for Sphinx dependencies
--------------------------------
-There's a script that automatically check for Sphinx dependencies. If it can
+There's a script that automatically checks for Sphinx dependencies. If it can
recognize your distribution, it will also give a hint about the install
command line options for your distro::
- $ ./scripts/sphinx-pre-install
+ $ ./tools/docs/sphinx-pre-install
Checking if the needed tools for Fedora release 26 (Twenty Six) are available
Warning: better to also install "texlive-luatex85".
You should run:
@@ -122,7 +116,7 @@ command line options for your distro::
. sphinx_2.4.4/bin/activate
pip install -r Documentation/sphinx/requirements.txt
- Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468.
+ Can't build as 1 mandatory dependency is missing at ./tools/docs/sphinx-pre-install line 468.
By default, it checks all the requirements for both html and PDF, including
the requirements for images, math expressions and LaTeX build, and assumes
@@ -137,6 +131,29 @@ It supports two optional parameters:
``--no-virtualenv``
Use OS packaging for Sphinx instead of Python virtual environment.
+Installing Sphinx Minimal Version
+---------------------------------
+
+When changing Sphinx build system, it is important to ensure that
+the minimal version will still be supported. Nowadays, it is
+becoming harder to do that on modern distributions, as it is not
+possible to install with Python 3.13 and above.
+
+Testing with the lowest supported Python version as defined at
+Documentation/process/changes.rst can be done by creating
+a venv with it with, and install minimal requirements with::
+
+ /usr/bin/python3.9 -m venv sphinx_min
+ . sphinx_min/bin/activate
+ pip install -r Documentation/sphinx/min_requirements.txt
+
+A more comprehensive test can be done by using:
+
+ tools/docs/test_doc_build.py
+
+Such script create one Python venv per supported version,
+optionally building documentation for a range of Sphinx versions.
+
Sphinx Build
============
@@ -147,11 +164,9 @@ section of ``make help``. The generated documentation is placed in
format-specific subdirectories under ``Documentation/output``.
To generate documentation, Sphinx (``sphinx-build``) must obviously be
-installed. For prettier HTML output, the Read the Docs Sphinx theme
-(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
-``XeLaTeX`` and ``convert(1)`` from ImageMagick
-(https://www.imagemagick.org).\ [#ink]_
-All of these are widely available and packaged in distributions.
+installed. For PDF output you'll also need ``XeLaTeX`` and ``convert(1)``
+from ImageMagick (https://www.imagemagick.org).\ [#ink]_ All of these are
+widely available and packaged in distributions.
To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more verbose
@@ -160,13 +175,15 @@ output.
It is also possible to pass an extra DOCS_CSS overlay file, in order to customize
the html layout, by using the ``DOCS_CSS`` make variable.
-By default, the build will try to use the Read the Docs sphinx theme:
+By default, the "Alabaster" theme is used to build the HTML documentation;
+this theme is bundled with Sphinx and need not be installed separately.
+The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable.
- https://github.com/readthedocs/sphinx_rtd_theme
+.. note::
-If the theme is not available, it will fall-back to the classic one.
-
-The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable.
+ Some people might prefer to use the RTD theme for html output.
+ Depending on the Sphinx version, it should be installed separately,
+ with ``pip install sphinx_rtd_theme``.
There is another make variable ``SPHINXDIRS``, which is useful when test
building a subset of documentation. For example, you can build documents
@@ -289,7 +306,7 @@ Here are some specific guidelines for the kernel documentation:
from highlighting. For a short snippet of code embedded in the text, use \`\`.
-the C domain
+The C domain
------------
The **Sphinx C Domain** (name c) is suited for documentation of C API. E.g. a
@@ -319,9 +336,18 @@ the documentation build system will automatically turn a reference to
function name exists. If you see ``c:func:`` use in a kernel document,
please feel free to remove it.
+Tables
+------
+
+ReStructuredText provides several options for table syntax. Kernel style for
+tables is to prefer *simple table* syntax or *grid table* syntax. See the
+`reStructuredText user reference for table syntax`_ for more details.
+
+.. _reStructuredText user reference for table syntax:
+ https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables
list tables
------------
+~~~~~~~~~~~
The list-table formats can be useful for tables that are not easily laid
out in the usual Sphinx ASCII-art formats. These formats are nearly
@@ -432,6 +458,15 @@ path.
For information on cross-referencing to kernel-doc functions or types, see
Documentation/doc-guide/kernel-doc.rst.
+Referencing commits
+~~~~~~~~~~~~~~~~~~~
+
+References to git commits are automatically hyperlinked given that they are
+written in one of these formats::
+
+ commit 72bf4f1767f0
+ commit 72bf4f1767f0 ("net: do not leave an empty skb in write queue")
+
.. _sphinx_kfigure:
Figures & Images
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
deleted file mode 100644
index 352ff53a2306..000000000000
--- a/Documentation/dontdiff
+++ /dev/null
@@ -1,271 +0,0 @@
-*.a
-*.aux
-*.bc
-*.bin
-*.bz2
-*.c.[012]*.*
-*.cis
-*.cpio
-*.csp
-*.dsp
-*.dvi
-*.elf
-*.eps
-*.fw
-*.gcno
-*.gcov
-*.gen.S
-*.gif
-*.grep
-*.grp
-*.gz
-*.html
-*.i
-*.jpeg
-*.ko
-*.ll
-*.log
-*.lst
-*.lzma
-*.lzo
-*.mo
-*.moc
-*.mod
-*.mod.c
-*.o
-*.o.*
-*.order
-*.orig
-*.out
-*.patch
-*.pdf
-*.plist
-*.png
-*.pot
-*.ps
-*.rej
-*.s
-*.sgml
-*.so
-*.so.dbg
-*.symtypes
-*.tab.c
-*.tab.h
-*.tex
-*.ver
-*.xml
-*.xz
-*.zst
-*_MODULES
-*_vga16.c
-*~
-\#*#
-*.9
-.*
-.*.d
-.mm
-53c700_d.h
-CVS
-ChangeSet
-GPATH
-GRTAGS
-GSYMS
-GTAGS
-Image
-Module.markers
-Module.symvers
-PENDING
-SCCS
-System.map*
-TAGS
-aconf
-af_names.h
-aic7*reg.h*
-aic7*reg_print.c*
-aic7*seq.h*
-aicasm
-aicdb.h*
-altivec*.c
-asm-offsets.h
-asm_offsets.h
-autoconf.h*
-av_permissions.h
-bbootsect
-bin2c
-binkernel.spec
-bootsect
-bounds.h
-bsetup
-btfixupprep
-build
-bvmlinux
-bzImage*
-capability_names.h
-capflags.c
-classlist.h*
-comp*.log
-compile.h*
-conf
-config
-config-*
-config.mak
-config.mak.autogen
-conmakehash
-consolemap_deftbl.c*
-cpustr.h
-crc32table.h*
-cscope.*
-defkeymap.c
-devlist.h*
-devicetable-offsets.h
-dnotify_test
-dslm
-dtc
-elf2ecoff
-elfconfig.h*
-evergreen_reg_safe.h
-fixdep
-flask.h
-fore200e_mkfirm
-fore200e_pca_fw.c*
-gconf
-gconf-cfg
-gen-devlist
-gen_crc32table
-gen_init_cpio
-generated
-genheaders
-genksyms
-*_gray256.c
-hpet_example
-hugepage-mmap
-hugepage-shm
-ihex2fw
-inat-tables.c
-initramfs_list
-int16.c
-int1.c
-int2.c
-int32.c
-int4.c
-int8.c
-kallsyms
-keywords.c
-ksym.c*
-ksym.h*
-*lex.c
-*lex.*.c
-linux
-logo_*.c
-logo_*_clut224.c
-logo_*_mono.c
-mach-types
-mach-types.h
-machtypes.h
-map
-map_hugetlb
-mconf
-mconf-cfg
-miboot*
-mk_elfconfig
-mkboot
-mkbugboot
-mkcpustr
-mkdep
-mkprep
-mkregtable
-mktables
-mktree
-mkutf8data
-modpost
-modules-only.symvers
-modules.builtin
-modules.builtin.modinfo
-modules.nsdeps
-modules.order
-modversions.h*
-nconf
-nconf-cfg
-ncscope.*
-offset.h
-oui.c*
-page-types
-parse.c
-parse.h
-patches*
-pca200e.bin
-pca200e_ecd.bin2
-perf.data
-perf.data.old
-perf-archive
-piggyback
-piggy.gzip
-piggy.S
-pnmtologo
-ppc_defs.h*
-pss_boot.h
-qconf
-qconf-cfg
-r100_reg_safe.h
-r200_reg_safe.h
-r300_reg_safe.h
-r420_reg_safe.h
-r600_reg_safe.h
-randstruct.seed
-randomize_layout_hash.h
-randomize_layout_seed.h
-recordmcount
-relocs
-rlim_names.h
-rn50_reg_safe.h
-rs600_reg_safe.h
-rv515_reg_safe.h
-series
-setup
-setup.bin
-setup.elf
-sortextable
-sImage
-sm_tbl*
-split-include
-syscalltab.h
-tables.c
-tags
-test_get_len
-tftpboot.img
-timeconst.h
-times.h*
-trix_boot.h
-utsrelease.h*
-vdso-syms.lds
-vdso.lds
-vdso32-int80-syms.lds
-vdso32-syms.lds
-vdso32-syscall-syms.lds
-vdso32-sysenter-syms.lds
-vdso32.lds
-vdso32.so.dbg
-vdso64.lds
-vdso64.so.dbg
-version.h*
-vmImage
-vmlinux
-vmlinux-*
-vmlinux.aout
-vmlinux.bin.all
-vmlinux.lds
-vmlinux.map
-vmlinux.symvers
-vmlinuz
-voffset.h
-vsyscall.lds
-vsyscall_32.lds
-wanxlfw.inc
-uImage
-unifdef
-utf8data.h
-wakeup.bin
-wakeup.elf
-wakeup.lds
-zImage*
-zoffset.h
diff --git a/Documentation/driver-api/80211/mac80211.rst b/Documentation/driver-api/80211/mac80211.rst
index 67d2e58b45e4..e38a220401f5 100644
--- a/Documentation/driver-api/80211/mac80211.rst
+++ b/Documentation/driver-api/80211/mac80211.rst
@@ -120,7 +120,7 @@ functions/definitions
ieee80211_rx
ieee80211_rx_ni
ieee80211_rx_irqsafe
- ieee80211_tx_status
+ ieee80211_tx_status_skb
ieee80211_tx_status_ni
ieee80211_tx_status_irqsafe
ieee80211_rts_get
diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst
index cec84908fbc0..b236de773e1d 100644
--- a/Documentation/driver-api/auxiliary_bus.rst
+++ b/Documentation/driver-api/auxiliary_bus.rst
@@ -24,7 +24,6 @@ Auxiliary Device Creation
.. kernel-doc:: drivers/base/auxiliary.c
:identifiers: auxiliary_device_init __auxiliary_device_add
- auxiliary_find_device
Auxiliary Device Memory Model and Lifespan
------------------------------------------
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst
index 3e2dae954898..5e9f7aee71a7 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -15,8 +15,8 @@ Driver device table
:no-identifiers: pci_device_id
-Delaying, scheduling, and timer routines
-----------------------------------------
+Delaying and scheduling routines
+--------------------------------
.. kernel-doc:: include/linux/sched.h
:internal:
@@ -33,16 +33,16 @@ Delaying, scheduling, and timer routines
.. kernel-doc:: include/linux/completion.h
:internal:
-.. kernel-doc:: kernel/time/timer.c
- :export:
+Time and timer routines
+-----------------------
-Wait queues and Wake events
----------------------------
-
-.. kernel-doc:: include/linux/wait.h
+.. kernel-doc:: include/linux/jiffies.h
:internal:
-.. kernel-doc:: kernel/sched/wait.c
+.. kernel-doc:: kernel/time/time.c
+ :export:
+
+.. kernel-doc:: kernel/time/timer.c
:export:
High-resolution timers
@@ -57,6 +57,15 @@ High-resolution timers
.. kernel-doc:: kernel/time/hrtimer.c
:export:
+Wait queues and Wake events
+---------------------------
+
+.. kernel-doc:: include/linux/wait.h
+ :internal:
+
+.. kernel-doc:: kernel/sched/wait.c
+ :export:
+
Internal Functions
------------------
@@ -84,7 +93,13 @@ Reference counting
Atomics
-------
-.. kernel-doc:: arch/x86/include/asm/atomic.h
+.. kernel-doc:: include/linux/atomic/atomic-instrumented.h
+ :internal:
+
+.. kernel-doc:: include/linux/atomic/atomic-arch-fallback.h
+ :internal:
+
+.. kernel-doc:: include/linux/atomic/atomic-long.h
:internal:
Kernel objects manipulation
@@ -93,6 +108,9 @@ Kernel objects manipulation
.. kernel-doc:: lib/kobject.c
:export:
+.. kernel-doc:: lib/kobject_uevent.c
+ :export:
+
Kernel utility functions
------------------------
@@ -107,9 +125,6 @@ Kernel utility functions
.. kernel-doc:: kernel/panic.c
:export:
-.. kernel-doc:: include/linux/overflow.h
- :internal:
-
Device Resource Management
--------------------------
diff --git a/Documentation/driver-api/clk.rst b/Documentation/driver-api/clk.rst
index 3cad45d14187..93bab5336dfd 100644
--- a/Documentation/driver-api/clk.rst
+++ b/Documentation/driver-api/clk.rst
@@ -258,6 +258,11 @@ clocks properly but rely on them being on from the bootloader, bypassing
the disabling means that the driver will remain functional while the issues
are sorted out.
+You can see which clocks have been disabled by booting your kernel with these
+parameters::
+
+ tp_printk trace_event=clk:clk_disable
+
To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
kernel.
diff --git a/Documentation/driver-api/coco/index.rst b/Documentation/driver-api/coco/index.rst
new file mode 100644
index 000000000000..af9f08ca0cfd
--- /dev/null
+++ b/Documentation/driver-api/coco/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+Confidential Computing
+======================
+
+.. toctree::
+ :maxdepth: 1
+
+ measurement-registers
+
+.. only:: subproject and html
diff --git a/Documentation/driver-api/coco/measurement-registers.rst b/Documentation/driver-api/coco/measurement-registers.rst
new file mode 100644
index 000000000000..962a44efa2c0
--- /dev/null
+++ b/Documentation/driver-api/coco/measurement-registers.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+=====================
+Measurement Registers
+=====================
+
+.. kernel-doc:: include/linux/tsm-mr.h
+ :internal:
+
+.. kernel-doc:: drivers/virt/coco/guest/tsm-mr.c
+ :export:
diff --git a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst
new file mode 100644
index 000000000000..f815d4fd8372
--- /dev/null
+++ b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst
@@ -0,0 +1,849 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+IAA Compression Accelerator Crypto Driver
+=========================================
+
+Tom Zanussi <tom.zanussi@linux.intel.com>
+
+The IAA crypto driver supports compression/decompression compatible
+with the DEFLATE compression standard described in RFC 1951, which is
+the compression/decompression algorithm exported by this module.
+
+The IAA hardware spec can be found here:
+
+ https://cdrdv2.intel.com/v1/dl/getContent/721858
+
+The iaa_crypto driver is designed to work as a layer underneath
+higher-level compression devices such as zswap.
+
+Users can select IAA compress/decompress acceleration by specifying
+one of the supported IAA compression algorithms in whatever facility
+allows compression algorithms to be selected.
+
+For example, a zswap device can select the IAA 'fixed' mode
+represented by selecting the 'deflate-iaa' crypto compression
+algorithm::
+
+ # echo deflate-iaa > /sys/module/zswap/parameters/compressor
+
+This will tell zswap to use the IAA 'fixed' compression mode for all
+compresses and decompresses.
+
+Currently, there is only one compression modes available, 'fixed'
+mode.
+
+The 'fixed' compression mode implements the compression scheme
+specified by RFC 1951 and is given the crypto algorithm name
+'deflate-iaa'. (Because the IAA hardware has a 4k history-window
+limitation, only buffers <= 4k, or that have been compressed using a
+<= 4k history window, are technically compliant with the deflate spec,
+which allows for a window of up to 32k. Because of this limitation,
+the IAA fixed mode deflate algorithm is given its own algorithm name
+rather than simply 'deflate').
+
+
+Config options and other setup
+==============================
+
+The IAA crypto driver is available via menuconfig using the following
+path::
+
+ Cryptographic API -> Hardware crypto devices -> Support for Intel(R) IAA Compression Accelerator
+
+In the configuration file the option called CONFIG_CRYPTO_DEV_IAA_CRYPTO.
+
+The IAA crypto driver also supports statistics, which are available
+via menuconfig using the following path::
+
+ Cryptographic API -> Hardware crypto devices -> Support for Intel(R) IAA Compression -> Enable Intel(R) IAA Compression Accelerator Statistics
+
+In the configuration file the option called CONFIG_CRYPTO_DEV_IAA_CRYPTO_STATS.
+
+The following config options should also be enabled::
+
+ CONFIG_IRQ_REMAP=y
+ CONFIG_INTEL_IOMMU=y
+ CONFIG_INTEL_IOMMU_SVM=y
+ CONFIG_PCI_ATS=y
+ CONFIG_PCI_PRI=y
+ CONFIG_PCI_PASID=y
+ CONFIG_INTEL_IDXD=m
+ CONFIG_INTEL_IDXD_SVM=y
+
+IAA is one of the first Intel accelerator IPs that can work in
+conjunction with the Intel IOMMU. There are multiple modes that exist
+for testing. Based on IOMMU configuration, there are 3 modes::
+
+ - Scalable
+ - Legacy
+ - No IOMMU
+
+
+Scalable mode
+-------------
+
+Scalable mode supports Shared Virtual Memory (SVM or SVA). It is
+entered when using the kernel boot commandline::
+
+ intel_iommu=on,sm_on
+
+with VT-d turned on in BIOS.
+
+With scalable mode, both shared and dedicated workqueues are available
+for use.
+
+For scalable mode, the following BIOS settings should be enabled::
+
+ Socket Configuration > IIO Configuration > Intel VT for Directed I/O (VT-d) > Intel VT for Directed I/O
+
+ Socket Configuration > IIO Configuration > PCIe ENQCMD > ENQCMDS
+
+
+Legacy mode
+-----------
+
+Legacy mode is entered when using the kernel boot commandline::
+
+ intel_iommu=off
+
+or VT-d is not turned on in BIOS.
+
+If you have booted into Linux and not sure if VT-d is on, do a "dmesg
+| grep -i dmar". If you don't see a number of DMAR devices enumerated,
+most likely VT-d is not on.
+
+With legacy mode, only dedicated workqueues are available for use.
+
+
+No IOMMU mode
+-------------
+
+No IOMMU mode is entered when using the kernel boot commandline::
+
+ iommu=off.
+
+With no IOMMU mode, only dedicated workqueues are available for use.
+
+
+Usage
+=====
+
+accel-config
+------------
+
+When loaded, the iaa_crypto driver automatically creates a default
+configuration and enables it, and assigns default driver attributes.
+If a different configuration or set of driver attributes is required,
+the user must first disable the IAA devices and workqueues, reset the
+configuration, and then re-register the deflate-iaa algorithm with the
+crypto subsystem by removing and reinserting the iaa_crypto module.
+
+The :ref:`iaa_disable_script` in the 'Use Cases'
+section below can be used to disable the default configuration.
+
+See :ref:`iaa_default_config` below for details of the default
+configuration.
+
+More likely than not, however, and because of the complexity and
+configurability of the accelerator devices, the user will want to
+configure the device and manually enable the desired devices and
+workqueues.
+
+The userspace tool to help doing that is called accel-config. Using
+accel-config to configure device or loading a previously saved config
+is highly recommended. The device can be controlled via sysfs
+directly but comes with the warning that you should do this ONLY if
+you know exactly what you are doing. The following sections will not
+cover the sysfs interface but assumes you will be using accel-config.
+
+The :ref:`iaa_sysfs_config` section in the appendix below can be
+consulted for the sysfs interface details if interested.
+
+The accel-config tool along with instructions for building it can be
+found here:
+
+ https://github.com/intel/idxd-config/#readme
+
+Typical usage
+-------------
+
+In order for the iaa_crypto module to actually do any
+compression/decompression work on behalf of a facility, one or more
+IAA workqueues need to be bound to the iaa_crypto driver.
+
+For instance, here's an example of configuring an IAA workqueue and
+binding it to the iaa_crypto driver (note that device names are
+specified as 'iax' rather than 'iaa' - this is because upstream still
+has the old 'iax' device naming in place) ::
+
+ # configure wq1.0
+
+ accel-config config-wq --group-id=0 --mode=dedicated --type=kernel --priority=10 --name="iaa_crypto" --driver-name="crypto" iax1/wq1.0
+
+ accel-config config-engine iax1/engine1.0 --group-id=0
+
+ # enable IAA device iax1
+
+ accel-config enable-device iax1
+
+ # enable wq1.0 on IAX device iax1
+
+ accel-config enable-wq iax1/wq1.0
+
+Whenever a new workqueue is bound to or unbound from the iaa_crypto
+driver, the available workqueues are 'rebalanced' such that work
+submitted from a particular CPU is given to the most appropriate
+workqueue available. Current best practice is to configure and bind
+at least one workqueue for each IAA device, but as long as there is at
+least one workqueue configured and bound to any IAA device in the
+system, the iaa_crypto driver will work, albeit most likely not as
+efficiently.
+
+The IAA crypto algorigthms is operational and compression and
+decompression operations are fully enabled following the successful
+binding of the first IAA workqueue to the iaa_crypto driver.
+
+Similarly, the IAA crypto algorithm is not operational and compression
+and decompression operations are disabled following the unbinding of
+the last IAA worqueue to the iaa_crypto driver.
+
+As a result, the IAA crypto algorithms and thus the IAA hardware are
+only available when one or more workques are bound to the iaa_crypto
+driver.
+
+When there are no IAA workqueues bound to the driver, the IAA crypto
+algorithms can be unregistered by removing the module.
+
+
+Driver attributes
+-----------------
+
+There are a couple user-configurable driver attributes that can be
+used to configure various modes of operation. They're listed below,
+along with their default values. To set any of these attributes, echo
+the appropriate values to the attribute file located under
+/sys/bus/dsa/drivers/crypto/
+
+The attribute settings at the time the IAA algorithms are registered
+are captured in each algorithm's crypto_ctx and used for all compresses
+and decompresses when using that algorithm.
+
+The available attributes are:
+
+ - verify_compress
+
+ Toggle compression verification. If set, each compress will be
+ internally decompressed and the contents verified, returning error
+ codes if unsuccessful. This can be toggled with 0/1::
+
+ echo 0 > /sys/bus/dsa/drivers/crypto/verify_compress
+
+ The default setting is '1' - verify all compresses.
+
+ - sync_mode
+
+ Select mode to be used to wait for completion of each compresses
+ and decompress operation.
+
+ The crypto async interface support implemented by iaa_crypto
+ provides an implementation that satisfies the interface but does
+ so in a synchronous manner - it fills and submits the IDXD
+ descriptor and then loops around waiting for it to complete before
+ returning. This isn't a problem at the moment, since all existing
+ callers (e.g. zswap) wrap any asynchronous callees in a
+ synchronous wrapper anyway.
+
+ The iaa_crypto driver does however provide true asynchronous
+ support for callers that can make use of it. In this mode, it
+ fills and submits the IDXD descriptor, then returns immediately
+ with -EINPROGRESS. The caller can then either poll for completion
+ itself, which requires specific code in the caller which currently
+ nothing in the upstream kernel implements, or go to sleep and wait
+ for an interrupt signaling completion. This latter mode is
+ supported by current users in the kernel such as zswap via
+ synchronous wrappers. Although it is supported this mode is
+ significantly slower than the synchronous mode that does the
+ polling in the iaa_crypto driver previously mentioned.
+
+ This mode can be enabled by writing 'async_irq' to the sync_mode
+ iaa_crypto driver attribute::
+
+ echo async_irq > /sys/bus/dsa/drivers/crypto/sync_mode
+
+ Async mode without interrupts (caller must poll) can be enabled by
+ writing 'async' to it (please see Caveat)::
+
+ echo async > /sys/bus/dsa/drivers/crypto/sync_mode
+
+ The mode that does the polling in the iaa_crypto driver can be
+ enabled by writing 'sync' to it::
+
+ echo sync > /sys/bus/dsa/drivers/crypto/sync_mode
+
+ The default mode is 'sync'.
+
+ Caveat: since the only mechanism that iaa_crypto currently implements
+ for async polling without interrupts is via the 'sync' mode as
+ described earlier, writing 'async' to
+ '/sys/bus/dsa/drivers/crypto/sync_mode' will internally enable the
+ 'sync' mode. This is to ensure correct iaa_crypto behavior until true
+ async polling without interrupts is enabled in iaa_crypto.
+
+.. _iaa_default_config:
+
+IAA Default Configuration
+-------------------------
+
+When the iaa_crypto driver is loaded, each IAA device has a single
+work queue configured for it, with the following attributes::
+
+ mode "dedicated"
+ threshold 0
+ size Total WQ Size from WQCAP
+ priority 10
+ type IDXD_WQT_KERNEL
+ group 0
+ name "iaa_crypto"
+ driver_name "crypto"
+
+The devices and workqueues are also enabled and therefore the driver
+is ready to be used without any additional configuration.
+
+The default driver attributes in effect when the driver is loaded are::
+
+ sync_mode "sync"
+ verify_compress 1
+
+In order to change either the device/work queue or driver attributes,
+the enabled devices and workqueues must first be disabled. In order
+to have the new configuration applied to the deflate-iaa crypto
+algorithm, it needs to be re-registered by removing and reinserting
+the iaa_crypto module. The :ref:`iaa_disable_script` in the 'Use
+Cases' section below can be used to disable the default configuration.
+
+Statistics
+==========
+
+If the optional debugfs statistics support is enabled, the IAA crypto
+driver will generate statistics which can be accessed in debugfs at::
+
+ # ls -al /sys/kernel/debug/iaa-crypto/
+ total 0
+ drwxr-xr-x 2 root root 0 Mar 3 07:55 .
+ drwx------ 53 root root 0 Mar 3 07:55 ..
+ -rw-r--r-- 1 root root 0 Mar 3 07:55 global_stats
+ -rw-r--r-- 1 root root 0 Mar 3 07:55 stats_reset
+ -rw-r--r-- 1 root root 0 Mar 3 07:55 wq_stats
+
+The global_stats file shows a set of global statistics collected since
+the driver has been loaded or reset::
+
+ # cat global_stats
+ global stats:
+ total_comp_calls: 4300
+ total_decomp_calls: 4164
+ total_sw_decomp_calls: 0
+ total_comp_bytes_out: 5993989
+ total_decomp_bytes_in: 5993989
+ total_completion_einval_errors: 0
+ total_completion_timeout_errors: 0
+ total_completion_comp_buf_overflow_errors: 136
+
+The wq_stats file shows per-wq stats, a set for each iaa device and wq
+in addition to some global stats::
+
+ # cat wq_stats
+ iaa device:
+ id: 1
+ n_wqs: 1
+ comp_calls: 0
+ comp_bytes: 0
+ decomp_calls: 0
+ decomp_bytes: 0
+ wqs:
+ name: iaa_crypto
+ comp_calls: 0
+ comp_bytes: 0
+ decomp_calls: 0
+ decomp_bytes: 0
+
+ iaa device:
+ id: 3
+ n_wqs: 1
+ comp_calls: 0
+ comp_bytes: 0
+ decomp_calls: 0
+ decomp_bytes: 0
+ wqs:
+ name: iaa_crypto
+ comp_calls: 0
+ comp_bytes: 0
+ decomp_calls: 0
+ decomp_bytes: 0
+
+ iaa device:
+ id: 5
+ n_wqs: 1
+ comp_calls: 1360
+ comp_bytes: 1999776
+ decomp_calls: 0
+ decomp_bytes: 0
+ wqs:
+ name: iaa_crypto
+ comp_calls: 1360
+ comp_bytes: 1999776
+ decomp_calls: 0
+ decomp_bytes: 0
+
+ iaa device:
+ id: 7
+ n_wqs: 1
+ comp_calls: 2940
+ comp_bytes: 3994213
+ decomp_calls: 4164
+ decomp_bytes: 5993989
+ wqs:
+ name: iaa_crypto
+ comp_calls: 2940
+ comp_bytes: 3994213
+ decomp_calls: 4164
+ decomp_bytes: 5993989
+ ...
+
+Writing to 'stats_reset' resets all the stats, including the
+per-device and per-wq stats::
+
+ # echo 1 > stats_reset
+ # cat wq_stats
+ global stats:
+ total_comp_calls: 0
+ total_decomp_calls: 0
+ total_comp_bytes_out: 0
+ total_decomp_bytes_in: 0
+ total_completion_einval_errors: 0
+ total_completion_timeout_errors: 0
+ total_completion_comp_buf_overflow_errors: 0
+ ...
+
+
+Use cases
+=========
+
+Simple zswap test
+-----------------
+
+For this example, the kernel should be configured according to the
+dedicated mode options described above, and zswap should be enabled as
+well::
+
+ CONFIG_ZSWAP=y
+
+This is a simple test that uses iaa_compress as the compressor for a
+swap (zswap) device. It sets up the zswap device and then uses the
+memory_memadvise program listed below to forcibly swap out and in a
+specified number of pages, demonstrating both compress and decompress.
+
+The zswap test expects the work queues for each IAA device on the
+system to be configured properly as a kernel workqueue with a
+workqueue driver_name of "crypto".
+
+The first step is to make sure the iaa_crypto module is loaded::
+
+ modprobe iaa_crypto
+
+If the IAA devices and workqueues haven't previously been disabled and
+reconfigured, then the default configuration should be in place and no
+further IAA configuration is necessary. See :ref:`iaa_default_config`
+below for details of the default configuration.
+
+If the default configuration is in place, you should see the iaa
+devices and wq0s enabled::
+
+ # cat /sys/bus/dsa/devices/iax1/state
+ enabled
+ # cat /sys/bus/dsa/devices/iax1/wq1.0/state
+ enabled
+
+To demonstrate that the following steps work as expected, these
+commands can be used to enable debug output::
+
+ # echo -n 'module iaa_crypto +p' > /sys/kernel/debug/dynamic_debug/control
+ # echo -n 'module idxd +p' > /sys/kernel/debug/dynamic_debug/control
+
+Use the following commands to enable zswap::
+
+ # echo 0 > /sys/module/zswap/parameters/enabled
+ # echo 50 > /sys/module/zswap/parameters/max_pool_percent
+ # echo deflate-iaa > /sys/module/zswap/parameters/compressor
+ # echo 1 > /sys/module/zswap/parameters/enabled
+ # echo 100 > /proc/sys/vm/swappiness
+ # echo never > /sys/kernel/mm/transparent_hugepage/enabled
+ # echo 1 > /proc/sys/vm/overcommit_memory
+
+Now you can now run the zswap workload you want to measure. For
+example, using the memory_memadvise code below, the following command
+will swap in and out 100 pages::
+
+ ./memory_madvise 100
+
+ Allocating 100 pages to swap in/out
+ Swapping out 100 pages
+ Swapping in 100 pages
+ Swapped out and in 100 pages
+
+You should see something like the following in the dmesg output::
+
+ [ 404.202972] idxd 0000:e7:02.0: iaa_comp_acompress: dma_map_sg, src_addr 223925c000, nr_sgs 1, req->src 00000000ee7cb5e6, req->slen 4096, sg_dma_len(sg) 4096
+ [ 404.202973] idxd 0000:e7:02.0: iaa_comp_acompress: dma_map_sg, dst_addr 21dadf8000, nr_sgs 1, req->dst 000000008d6acea8, req->dlen 4096, sg_dma_len(sg) 8192
+ [ 404.202975] idxd 0000:e7:02.0: iaa_compress: desc->src1_addr 223925c000, desc->src1_size 4096, desc->dst_addr 21dadf8000, desc->max_dst_size 4096, desc->src2_addr 2203543000, desc->src2_size 1568
+ [ 404.202981] idxd 0000:e7:02.0: iaa_compress_verify: (verify) desc->src1_addr 21dadf8000, desc->src1_size 228, desc->dst_addr 223925c000, desc->max_dst_size 4096, desc->src2_addr 0, desc->src2_size 0
+ ...
+
+Now that basic functionality has been demonstrated, the defaults can
+be erased and replaced with a different configuration. To do that,
+first disable zswap::
+
+ # echo lzo > /sys/module/zswap/parameters/compressor
+ # swapoff -a
+ # echo 0 > /sys/module/zswap/parameters/accept_threshold_percent
+ # echo 0 > /sys/module/zswap/parameters/max_pool_percent
+ # echo 0 > /sys/module/zswap/parameters/enabled
+ # echo 0 > /sys/module/zswap/parameters/enabled
+
+Then run the :ref:`iaa_disable_script` in the 'Use Cases' section
+below to disable the default configuration.
+
+Finally turn swap back on::
+
+ # swapon -a
+
+Following all that the IAA device(s) can now be re-configured and
+enabled as desired for further testing. Below is one example.
+
+The zswap test expects the work queues for each IAA device on the
+system to be configured properly as a kernel workqueue with a
+workqueue driver_name of "crypto".
+
+The below script automatically does that::
+
+ #!/bin/bash
+
+ echo "IAA devices:"
+ lspci -d:0cfe
+ echo "# IAA devices:"
+ lspci -d:0cfe | wc -l
+
+ #
+ # count iaa instances
+ #
+ iaa_dev_id="0cfe"
+ num_iaa=$(lspci -d:${iaa_dev_id} | wc -l)
+ echo "Found ${num_iaa} IAA instances"
+
+ #
+ # disable iaa wqs and devices
+ #
+ echo "Disable IAA"
+
+ for ((i = 1; i < ${num_iaa} * 2; i += 2)); do
+ echo disable wq iax${i}/wq${i}.0
+ accel-config disable-wq iax${i}/wq${i}.0
+ echo disable iaa iax${i}
+ accel-config disable-device iax${i}
+ done
+
+ echo "End Disable IAA"
+
+ echo "Reload iaa_crypto module"
+
+ rmmod iaa_crypto
+ modprobe iaa_crypto
+
+ echo "End Reload iaa_crypto module"
+
+ #
+ # configure iaa wqs and devices
+ #
+ echo "Configure IAA"
+ for ((i = 1; i < ${num_iaa} * 2; i += 2)); do
+ accel-config config-wq --group-id=0 --mode=dedicated --wq-size=128 --priority=10 --type=kernel --name="iaa_crypto" --driver-name="crypto" iax${i}/wq${i}.0
+ accel-config config-engine iax${i}/engine${i}.0 --group-id=0
+ done
+
+ echo "End Configure IAA"
+
+ #
+ # enable iaa wqs and devices
+ #
+ echo "Enable IAA"
+
+ for ((i = 1; i < ${num_iaa} * 2; i += 2)); do
+ echo enable iaa iax${i}
+ accel-config enable-device iax${i}
+ echo enable wq iax${i}/wq${i}.0
+ accel-config enable-wq iax${i}/wq${i}.0
+ done
+
+ echo "End Enable IAA"
+
+When the workqueues are bound to the iaa_crypto driver, you should
+see something similar to the following in dmesg output if you've
+enabled debug output (echo -n 'module iaa_crypto +p' >
+/sys/kernel/debug/dynamic_debug/control)::
+
+ [ 60.752344] idxd 0000:f6:02.0: add_iaa_wq: added wq 000000004068d14d to iaa 00000000c9585ba2, n_wq 1
+ [ 60.752346] iaa_crypto: rebalance_wq_table: nr_nodes=2, nr_cpus 160, nr_iaa 8, cpus_per_iaa 20
+ [ 60.752347] iaa_crypto: rebalance_wq_table: iaa=0
+ [ 60.752349] idxd 0000:6a:02.0: request_iaa_wq: getting wq from iaa_device 0000000042d7bc52 (0)
+ [ 60.752350] idxd 0000:6a:02.0: request_iaa_wq: returning unused wq 00000000c8bb4452 (0) from iaa device 0000000042d7bc52 (0)
+ [ 60.752352] iaa_crypto: rebalance_wq_table: assigned wq for cpu=0, node=0 = wq 00000000c8bb4452
+ [ 60.752354] iaa_crypto: rebalance_wq_table: iaa=0
+ [ 60.752355] idxd 0000:6a:02.0: request_iaa_wq: getting wq from iaa_device 0000000042d7bc52 (0)
+ [ 60.752356] idxd 0000:6a:02.0: request_iaa_wq: returning unused wq 00000000c8bb4452 (0) from iaa device 0000000042d7bc52 (0)
+ [ 60.752358] iaa_crypto: rebalance_wq_table: assigned wq for cpu=1, node=0 = wq 00000000c8bb4452
+ [ 60.752359] iaa_crypto: rebalance_wq_table: iaa=0
+ [ 60.752360] idxd 0000:6a:02.0: request_iaa_wq: getting wq from iaa_device 0000000042d7bc52 (0)
+ [ 60.752361] idxd 0000:6a:02.0: request_iaa_wq: returning unused wq 00000000c8bb4452 (0) from iaa device 0000000042d7bc52 (0)
+ [ 60.752362] iaa_crypto: rebalance_wq_table: assigned wq for cpu=2, node=0 = wq 00000000c8bb4452
+ [ 60.752364] iaa_crypto: rebalance_wq_table: iaa=0
+ .
+ .
+ .
+
+Once the workqueues and devices have been enabled, the IAA crypto
+algorithms are enabled and available. When the IAA crypto algorithms
+have been successfully enabled, you should see the following dmesg
+output::
+
+ [ 64.893759] iaa_crypto: iaa_crypto_enable: iaa_crypto now ENABLED
+
+Now run the following zswap-specific setup commands to have zswap use
+the 'fixed' compression mode::
+
+ echo 0 > /sys/module/zswap/parameters/enabled
+ echo 50 > /sys/module/zswap/parameters/max_pool_percent
+ echo deflate-iaa > /sys/module/zswap/parameters/compressor
+ echo 1 > /sys/module/zswap/parameters/enabled
+
+ echo 100 > /proc/sys/vm/swappiness
+ echo never > /sys/kernel/mm/transparent_hugepage/enabled
+ echo 1 > /proc/sys/vm/overcommit_memory
+
+Finally, you can now run the zswap workload you want to measure. For
+example, using the code below, the following command will swap in and
+out 100 pages::
+
+ ./memory_madvise 100
+
+ Allocating 100 pages to swap in/out
+ Swapping out 100 pages
+ Swapping in 100 pages
+ Swapped out and in 100 pages
+
+You should see something like the following in the dmesg output if
+you've enabled debug output (echo -n 'module iaa_crypto +p' >
+/sys/kernel/debug/dynamic_debug/control)::
+
+ [ 404.202972] idxd 0000:e7:02.0: iaa_comp_acompress: dma_map_sg, src_addr 223925c000, nr_sgs 1, req->src 00000000ee7cb5e6, req->slen 4096, sg_dma_len(sg) 4096
+ [ 404.202973] idxd 0000:e7:02.0: iaa_comp_acompress: dma_map_sg, dst_addr 21dadf8000, nr_sgs 1, req->dst 000000008d6acea8, req->dlen 4096, sg_dma_len(sg) 8192
+ [ 404.202975] idxd 0000:e7:02.0: iaa_compress: desc->src1_addr 223925c000, desc->src1_size 4096, desc->dst_addr 21dadf8000, desc->max_dst_size 4096, desc->src2_addr 2203543000, desc->src2_size 1568
+ [ 404.202981] idxd 0000:e7:02.0: iaa_compress_verify: (verify) desc->src1_addr 21dadf8000, desc->src1_size 228, desc->dst_addr 223925c000, desc->max_dst_size 4096, desc->src2_addr 0, desc->src2_size 0
+ [ 409.203227] idxd 0000:e7:02.0: iaa_comp_adecompress: dma_map_sg, src_addr 21ddd8b100, nr_sgs 1, req->src 0000000084adab64, req->slen 228, sg_dma_len(sg) 228
+ [ 409.203235] idxd 0000:e7:02.0: iaa_comp_adecompress: dma_map_sg, dst_addr 21ee3dc000, nr_sgs 1, req->dst 000000004e2990d0, req->dlen 4096, sg_dma_len(sg) 4096
+ [ 409.203239] idxd 0000:e7:02.0: iaa_decompress: desc->src1_addr 21ddd8b100, desc->src1_size 228, desc->dst_addr 21ee3dc000, desc->max_dst_size 4096, desc->src2_addr 0, desc->src2_size 0
+ [ 409.203254] idxd 0000:e7:02.0: iaa_comp_adecompress: dma_map_sg, src_addr 21ddd8b100, nr_sgs 1, req->src 0000000084adab64, req->slen 228, sg_dma_len(sg) 228
+ [ 409.203256] idxd 0000:e7:02.0: iaa_comp_adecompress: dma_map_sg, dst_addr 21f1551000, nr_sgs 1, req->dst 000000004e2990d0, req->dlen 4096, sg_dma_len(sg) 4096
+ [ 409.203257] idxd 0000:e7:02.0: iaa_decompress: desc->src1_addr 21ddd8b100, desc->src1_size 228, desc->dst_addr 21f1551000, desc->max_dst_size 4096, desc->src2_addr 0, desc->src2_size 0
+
+In order to unregister the IAA crypto algorithms, and register new
+ones using different parameters, any users of the current algorithm
+should be stopped and the IAA workqueues and devices disabled.
+
+In the case of zswap, remove the IAA crypto algorithm as the
+compressor and turn off swap (to remove all references to
+iaa_crypto)::
+
+ echo lzo > /sys/module/zswap/parameters/compressor
+ swapoff -a
+
+ echo 0 > /sys/module/zswap/parameters/accept_threshold_percent
+ echo 0 > /sys/module/zswap/parameters/max_pool_percent
+ echo 0 > /sys/module/zswap/parameters/enabled
+
+Once zswap is disabled and no longer using iaa_crypto, the IAA wqs and
+devices can be disabled.
+
+.. _iaa_disable_script:
+
+IAA disable script
+------------------
+
+The below script automatically does that::
+
+ #!/bin/bash
+
+ echo "IAA devices:"
+ lspci -d:0cfe
+ echo "# IAA devices:"
+ lspci -d:0cfe | wc -l
+
+ #
+ # count iaa instances
+ #
+ iaa_dev_id="0cfe"
+ num_iaa=$(lspci -d:${iaa_dev_id} | wc -l)
+ echo "Found ${num_iaa} IAA instances"
+
+ #
+ # disable iaa wqs and devices
+ #
+ echo "Disable IAA"
+
+ for ((i = 1; i < ${num_iaa} * 2; i += 2)); do
+ echo disable wq iax${i}/wq${i}.0
+ accel-config disable-wq iax${i}/wq${i}.0
+ echo disable iaa iax${i}
+ accel-config disable-device iax${i}
+ done
+
+ echo "End Disable IAA"
+
+Finally, at this point the iaa_crypto module can be removed, which
+will unregister the current IAA crypto algorithms::
+
+ rmmod iaa_crypto
+
+
+memory_madvise.c (gcc -o memory_memadvise memory_madvise.c)::
+
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <string.h>
+ #include <unistd.h>
+ #include <sys/mman.h>
+ #include <linux/mman.h>
+
+ #ifndef MADV_PAGEOUT
+ #define MADV_PAGEOUT 21 /* force pages out immediately */
+ #endif
+
+ #define PG_SZ 4096
+
+ int main(int argc, char **argv)
+ {
+ int i, nr_pages = 1;
+ int64_t *dump_ptr;
+ char *addr, *a;
+ int loop = 1;
+
+ if (argc > 1)
+ nr_pages = atoi(argv[1]);
+
+ printf("Allocating %d pages to swap in/out\n", nr_pages);
+
+ /* allocate pages */
+ addr = mmap(NULL, nr_pages * PG_SZ, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+ *addr = 1;
+
+ /* initialize data in page to all '*' chars */
+ memset(addr, '*', nr_pages * PG_SZ);
+
+ printf("Swapping out %d pages\n", nr_pages);
+
+ /* Tell kernel to swap it out */
+ madvise(addr, nr_pages * PG_SZ, MADV_PAGEOUT);
+
+ while (loop > 0) {
+ /* Wait for swap out to finish */
+ sleep(5);
+
+ a = addr;
+
+ printf("Swapping in %d pages\n", nr_pages);
+
+ /* Access the page ... this will swap it back in again */
+ for (i = 0; i < nr_pages; i++) {
+ if (a[0] != '*') {
+ printf("Bad data from decompress!!!!!\n");
+
+ dump_ptr = (int64_t *)a;
+ for (int j = 0; j < 100; j++) {
+ printf(" page %d data: %#llx\n", i, *dump_ptr);
+ dump_ptr++;
+ }
+ }
+
+ a += PG_SZ;
+ }
+
+ loop --;
+ }
+
+ printf("Swapped out and in %d pages\n", nr_pages);
+
+Appendix
+========
+
+.. _iaa_sysfs_config:
+
+IAA sysfs config interface
+--------------------------
+
+Below is a description of the IAA sysfs interface, which as mentioned
+in the main document, should only be used if you know exactly what you
+are doing. Even then, there's no compelling reason to use it directly
+since accel-config can do everything the sysfs interface can and in
+fact accel-config is based on it under the covers.
+
+The 'IAA config path' is /sys/bus/dsa/devices and contains
+subdirectories representing each IAA device, workqueue, engine, and
+group. Note that in the sysfs interface, the IAA devices are actually
+named using iax e.g. iax1, iax3, etc. (Note that IAA devices are the
+odd-numbered devices; the even-numbered devices are DSA devices and
+can be ignored for IAA).
+
+The 'IAA device bind path' is /sys/bus/dsa/drivers/idxd/bind and is
+the file that is written to enable an IAA device.
+
+The 'IAA workqueue bind path' is /sys/bus/dsa/drivers/crypto/bind and
+is the file that is written to enable an IAA workqueue.
+
+Similarly /sys/bus/dsa/drivers/idxd/unbind and
+/sys/bus/dsa/drivers/crypto/unbind are used to disable IAA devices and
+workqueues.
+
+The basic sequence of commands needed to set up the IAA devices and
+workqueues is:
+
+For each device::
+ 1) Disable any workqueues enabled on the device. For example to
+ disable workques 0 and 1 on IAA device 3::
+
+ # echo wq3.0 > /sys/bus/dsa/drivers/crypto/unbind
+ # echo wq3.1 > /sys/bus/dsa/drivers/crypto/unbind
+
+ 2) Disable the device. For example to disable IAA device 3::
+
+ # echo iax3 > /sys/bus/dsa/drivers/idxd/unbind
+
+ 3) configure the desired workqueues. For example, to configure
+ workqueue 3 on IAA device 3::
+
+ # echo dedicated > /sys/bus/dsa/devices/iax3/wq3.3/mode
+ # echo 128 > /sys/bus/dsa/devices/iax3/wq3.3/size
+ # echo 0 > /sys/bus/dsa/devices/iax3/wq3.3/group_id
+ # echo 10 > /sys/bus/dsa/devices/iax3/wq3.3/priority
+ # echo "kernel" > /sys/bus/dsa/devices/iax3/wq3.3/type
+ # echo "iaa_crypto" > /sys/bus/dsa/devices/iax3/wq3.3/name
+ # echo "crypto" > /sys/bus/dsa/devices/iax3/wq3.3/driver_name
+
+ 4) Enable the device. For example to enable IAA device 3::
+
+ # echo iax3 > /sys/bus/dsa/drivers/idxd/bind
+
+ 5) Enable the desired workqueues on the device. For example to
+ enable workques 0 and 1 on IAA device 3::
+
+ # echo wq3.0 > /sys/bus/dsa/drivers/crypto/bind
+ # echo wq3.1 > /sys/bus/dsa/drivers/crypto/bind
diff --git a/Documentation/driver-api/crypto/iaa/index.rst b/Documentation/driver-api/crypto/iaa/index.rst
new file mode 100644
index 000000000000..aa6837e27264
--- /dev/null
+++ b/Documentation/driver-api/crypto/iaa/index.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================
+IAA (Intel Analytics Accelerator)
+=================================
+
+IAA provides hardware compression and decompression via the crypto
+API.
+
+.. toctree::
+ :maxdepth: 1
+
+ iaa-crypto
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/driver-api/crypto/index.rst b/Documentation/driver-api/crypto/index.rst
new file mode 100644
index 000000000000..fb9709b98bea
--- /dev/null
+++ b/Documentation/driver-api/crypto/index.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+Crypto Drivers
+==============
+
+Documentation for crypto drivers that may need more involved setup and
+configuration.
+
+.. toctree::
+ :maxdepth: 1
+
+ iaa/index
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/driver-api/cxl/allocation/dax.rst b/Documentation/driver-api/cxl/allocation/dax.rst
new file mode 100644
index 000000000000..c6f7a5da832f
--- /dev/null
+++ b/Documentation/driver-api/cxl/allocation/dax.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========
+DAX Devices
+===========
+CXL capacity exposed as a DAX device can be accessed directly via mmap.
+Users may wish to use this interface mechanism to write their own userland
+CXL allocator, or to managed shared or persistent memory regions across multiple
+hosts.
+
+If the capacity is shared across hosts or persistent, appropriate flushing
+mechanisms must be employed unless the region supports Snoop Back-Invalidate.
+
+Note that mappings must be aligned (size and base) to the dax device's base
+alignment, which is typically 2MB - but maybe be configured larger.
+
+::
+
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <stdint.h>
+ #include <sys/mman.h>
+ #include <fcntl.h>
+ #include <unistd.h>
+
+ #define DEVICE_PATH "/dev/dax0.0" // Replace DAX device path
+ #define DEVICE_SIZE (4ULL * 1024 * 1024 * 1024) // 4GB
+
+ int main() {
+ int fd;
+ void* mapped_addr;
+
+ /* Open the DAX device */
+ fd = open(DEVICE_PATH, O_RDWR);
+ if (fd < 0) {
+ perror("open");
+ return -1;
+ }
+
+ /* Map the device into memory */
+ mapped_addr = mmap(NULL, DEVICE_SIZE, PROT_READ | PROT_WRITE,
+ MAP_SHARED, fd, 0);
+ if (mapped_addr == MAP_FAILED) {
+ perror("mmap");
+ close(fd);
+ return -1;
+ }
+
+ printf("Mapped address: %p\n", mapped_addr);
+
+ /* You can now access the device through the mapped address */
+ uint64_t* ptr = (uint64_t*)mapped_addr;
+ *ptr = 0x1234567890abcdef; // Write a value to the device
+ printf("Value at address %p: 0x%016llx\n", ptr, *ptr);
+
+ /* Clean up */
+ munmap(mapped_addr, DEVICE_SIZE);
+ close(fd);
+ return 0;
+ }
diff --git a/Documentation/driver-api/cxl/allocation/hugepages.rst b/Documentation/driver-api/cxl/allocation/hugepages.rst
new file mode 100644
index 000000000000..1023c6922829
--- /dev/null
+++ b/Documentation/driver-api/cxl/allocation/hugepages.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========
+Huge Pages
+==========
+
+Contiguous Memory Allocator
+===========================
+CXL Memory onlined as SystemRAM during early boot is eligible for use by CMA,
+as the NUMA node hosting that capacity will be `Online` at the time CMA
+carves out contiguous capacity.
+
+CXL Memory deferred to the CXL Driver for configuration cannot have its
+capacity allocated by CMA - as the NUMA node hosting the capacity is `Offline`
+at :code:`__init` time - when CMA carves out contiguous capacity.
+
+HugeTLB
+=======
+Different huge page sizes allow different memory configurations.
+
+2MB Huge Pages
+--------------
+All CXL capacity regardless of configuration time or memory zone is eligible
+for use as 2MB huge pages.
+
+1GB Huge Pages
+--------------
+CXL capacity onlined in :code:`ZONE_NORMAL` is eligible for 1GB Gigantic Page
+allocation.
+
+CXL capacity onlined in :code:`ZONE_MOVABLE` is not eligible for 1GB Gigantic
+Page allocation.
diff --git a/Documentation/driver-api/cxl/allocation/page-allocator.rst b/Documentation/driver-api/cxl/allocation/page-allocator.rst
new file mode 100644
index 000000000000..3fa584a248bd
--- /dev/null
+++ b/Documentation/driver-api/cxl/allocation/page-allocator.rst
@@ -0,0 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================
+The Page Allocator
+==================
+
+The kernel page allocator services all general page allocation requests, such
+as :code:`kmalloc`. CXL configuration steps affect the behavior of the page
+allocator based on the selected `Memory Zone` and `NUMA node` the capacity is
+placed in.
+
+This section mostly focuses on how these configurations affect the page
+allocator (as of Linux v6.15) rather than the overall page allocator behavior.
+
+NUMA nodes and mempolicy
+========================
+Unless a task explicitly registers a mempolicy, the default memory policy
+of the linux kernel is to allocate memory from the `local NUMA node` first,
+and fall back to other nodes only if the local node is pressured.
+
+Generally, we expect to see local DRAM and CXL memory on separate NUMA nodes,
+with the CXL memory being non-local. Technically, however, it is possible
+for a compute node to have no local DRAM, and for CXL memory to be the
+`local` capacity for that compute node.
+
+
+Memory Zones
+============
+CXL capacity may be onlined in :code:`ZONE_NORMAL` or :code:`ZONE_MOVABLE`.
+
+As of v6.15, the page allocator attempts to allocate from the highest
+available and compatible ZONE for an allocation from the local node first.
+
+An example of a `zone incompatibility` is attempting to service an allocation
+marked :code:`GFP_KERNEL` from :code:`ZONE_MOVABLE`. Kernel allocations are
+typically not migratable, and as a result can only be serviced from
+:code:`ZONE_NORMAL` or lower.
+
+To simplify this, the page allocator will prefer :code:`ZONE_MOVABLE` over
+:code:`ZONE_NORMAL` by default, but if :code:`ZONE_MOVABLE` is depleted, it
+will fallback to allocate from :code:`ZONE_NORMAL`.
+
+
+CGroups and CPUSets
+===================
+Finally, assuming CXL memory is reachable via the page allocation (i.e. onlined
+in :code:`ZONE_NORMAL`), the :code:`cpusets.mems_allowed` may be used by
+containers to limit the accessibility of certain NUMA nodes for tasks in that
+container. Users may wish to utilize this in multi-tenant systems where some
+tasks prefer not to use slower memory.
+
+In the reclaim section we'll discuss some limitations of this interface to
+prevent demotions of shared data to CXL memory (if demotions are enabled).
+
diff --git a/Documentation/driver-api/cxl/allocation/reclaim.rst b/Documentation/driver-api/cxl/allocation/reclaim.rst
new file mode 100644
index 000000000000..f40f1cae391a
--- /dev/null
+++ b/Documentation/driver-api/cxl/allocation/reclaim.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======
+Reclaim
+=======
+Another way CXL memory can be utilized *indirectly* is via the reclaim system
+in :code:`mm/vmscan.c`. Reclaim is engaged when memory capacity on the system
+becomes pressured based on global and cgroup-local `watermark` settings.
+
+In this section we won't discuss the `watermark` configurations, just how CXL
+memory can be consumed by various pieces of reclaim system.
+
+Demotion
+========
+By default, the reclaim system will prefer swap (or zswap) when reclaiming
+memory. Enabling :code:`kernel/mm/numa/demotion_enabled` will cause vmscan
+to opportunistically prefer distant NUMA nodes to swap or zswap, if capacity
+is available.
+
+Demotion engages the :code:`mm/memory_tier.c` component to determine the
+next demotion node. The next demotion node is based on the :code:`HMAT`
+or :code:`CDAT` performance data.
+
+cpusets.mems_allowed quirk
+--------------------------
+In Linux v6.15 and below, demotion does not respect :code:`cpusets.mems_allowed`
+when migrating pages. As a result, if demotion is enabled, vmscan cannot
+guarantee isolation of a container's memory from nodes not set in mems_allowed.
+
+In Linux v6.XX and up, demotion does attempt to respect
+:code:`cpusets.mems_allowed`; however, certain classes of shared memory
+originally instantiated by another cgroup (such as common libraries - e.g.
+libc) may still be demoted. As a result, the mems_allowed interface still
+cannot provide perfect isolation from the remote nodes.
+
+ZSwap and Node Preference
+=========================
+In Linux v6.15 and below, ZSwap allocates memory from the local node of the
+processor for the new pages being compressed. Since pages being compressed
+are typically cold, the result is a cold page becomes promoted - only to
+be later demoted as it ages off the LRU.
+
+In Linux v6.XX, ZSwap tries to prefer the node of the page being compressed
+as the allocation target for the compression page. This helps prevent
+thrashing.
+
+Demotion with ZSwap
+===================
+When enabling both Demotion and ZSwap, you create a situation where ZSwap
+will prefer the slowest form of CXL memory by default until that tier of
+memory is exhausted.
diff --git a/Documentation/driver-api/cxl/conventions.rst b/Documentation/driver-api/cxl/conventions.rst
new file mode 100644
index 000000000000..e37336d7b116
--- /dev/null
+++ b/Documentation/driver-api/cxl/conventions.rst
@@ -0,0 +1,182 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+=======================================
+Compute Express Link: Linux Conventions
+=======================================
+
+There exists shipping platforms that bend or break CXL specification
+expectations. Record the details and the rationale for those deviations.
+Borrow the ACPI Code First template format to capture the assumptions
+and tradeoffs such that multiple platform implementations can follow the
+same convention.
+
+<(template) Title>
+==================
+
+Document
+--------
+CXL Revision <rev>, Version <ver>
+
+License
+-------
+SPDX-License Identifier: CC-BY-4.0
+
+Creator/Contributors
+--------------------
+
+Summary of the Change
+---------------------
+
+<Detail the conflict with the specification and where available the
+assumptions and tradeoffs taken by the hardware platform.>
+
+
+Benefits of the Change
+----------------------
+
+<Detail what happens if platforms and Linux do not adopt this
+convention.>
+
+References
+----------
+
+Detailed Description of the Change
+----------------------------------
+
+<Propose spec language that corrects the conflict.>
+
+
+Resolve conflict between CFMWS, Platform Memory Holes, and Endpoint Decoders
+============================================================================
+
+Document
+--------
+
+CXL Revision 3.2, Version 1.0
+
+License
+-------
+
+SPDX-License Identifier: CC-BY-4.0
+
+Creator/Contributors
+--------------------
+
+- Fabio M. De Francesco, Intel
+- Dan J. Williams, Intel
+- Mahesh Natu, Intel
+
+Summary of the Change
+---------------------
+
+According to the current Compute Express Link (CXL) Specifications (Revision
+3.2, Version 1.0), the CXL Fixed Memory Window Structure (CFMWS) describes zero
+or more Host Physical Address (HPA) windows associated with each CXL Host
+Bridge. Each window represents a contiguous HPA range that may be interleaved
+across one or more targets, including CXL Host Bridges. Each window has a set
+of restrictions that govern its usage. It is the Operating System-directed
+configuration and Power Management (OSPM) responsibility to utilize each window
+for the specified use.
+
+Table 9-22 of the current CXL Specifications states that the Window Size field
+contains the total number of consecutive bytes of HPA this window describes.
+This value must be a multiple of the Number of Interleave Ways (NIW) * 256 MB.
+
+Platform Firmware (BIOS) might reserve physical addresses below 4 GB where a
+memory gap such as the Low Memory Hole for PCIe MMIO may exist. In such cases,
+the CFMWS Range Size may not adhere to the NIW * 256 MB rule.
+
+The HPA represents the actual physical memory address space that the CXL devices
+can decode and respond to, while the System Physical Address (SPA), a related
+but distinct concept, represents the system-visible address space that users can
+direct transaction to and so it excludes reserved regions.
+
+BIOS publishes CFMWS to communicate the active SPA ranges that, on platforms
+with LMH's, map to a strict subset of the HPA. The SPA range trims out the hole,
+resulting in lost capacity in the Endpoints with no SPA to map to that part of
+the HPA range that intersects the hole.
+
+E.g, an x86 platform with two CFMWS and an LMH starting at 2 GB:
+
+ +--------+------------+-------------------+------------------+-------------------+------+
+ | Window | CFMWS Base | CFMWS Size | HDM Decoder Base | HDM Decoder Size | Ways |
+ +========+============+===================+==================+===================+======+
+ |  0 | 0 GB | 2 GB | 0 GB | 3 GB | 12 |
+ +--------+------------+-------------------+------------------+-------------------+------+
+ |  1 | 4 GB | NIW*256MB Aligned | 4 GB | NIW*256MB Aligned | 12 |
+ +--------+------------+-------------------+------------------+-------------------+------+
+
+HDM decoder base and HDM decoder size represent all the 12 Endpoint Decoders of
+a 12 ways region and all the intermediate Switch Decoders. They are configured
+by the BIOS according to the NIW * 256MB rule, resulting in a HPA range size of
+3GB. Instead, the CFMWS Base and CFMWS Size are used to configure the Root
+Decoder HPA range that results smaller (2GB) than that of the Switch and
+Endpoint Decoders in the hierarchy (3GB).
+
+This creates 2 issues which lead to a failure to construct a region:
+
+1) A mismatch in region size between root and any HDM decoder. The root decoders
+ will always be smaller due to the trim.
+
+2) The trim causes the root decoder to violate the (NIW * 256MB) rule.
+
+This change allows a region with a base address of 0GB to bypass these checks to
+allow for region creation with the trimmed root decoder address range.
+
+This change does not allow for any other arbitrary region to violate these
+checks - it is intended exclusively to enable x86 platforms which map CXL memory
+under 4GB.
+
+Despite the HDM decoders covering the PCIE hole HPA region, it is expected that
+the platform will never route address accesses to the CXL complex because the
+root decoder only covers the trimmed region (which excludes this). This is
+outside the ability of Linux to enforce.
+
+On the example platform, only the first 2GB will be potentially usable, but
+Linux, aiming to adhere to the current specifications, fails to construct
+Regions and attach Endpoint and intermediate Switch Decoders to them.
+
+There are several points of failure that due to the expectation that the Root
+Decoder HPA size, that is equal to the CFMWS from which it is configured, has
+to be greater or equal to the matching Switch and Endpoint HDM Decoders.
+
+In order to succeed with construction and attachment, Linux must construct a
+Region with Root Decoder HPA range size, and then attach to that all the
+intermediate Switch Decoders and Endpoint Decoders that belong to the hierarchy
+regardless of their range sizes.
+
+Benefits of the Change
+----------------------
+
+Without the change, the OSPM wouldn't match intermediate Switch and Endpoint
+Decoders with Root Decoders configured with CFMWS HPA sizes that don't align
+with the NIW * 256MB constraint, and so it leads to lost memdev capacity.
+
+This change allows the OSPM to construct Regions and attach intermediate Switch
+and Endpoint Decoders to them, so that the addressable part of the memory
+devices total capacity is made available to the users.
+
+References
+----------
+
+Compute Express Link Specification Revision 3.2, Version 1.0
+<https://www.computeexpresslink.org/>
+
+Detailed Description of the Change
+----------------------------------
+
+The description of the Window Size field in table 9-22 needs to account for
+platforms with Low Memory Holes, where SPA ranges might be subsets of the
+endpoints HPA. Therefore, it has to be changed to the following:
+
+"The total number of consecutive bytes of HPA this window represents. This value
+shall be a multiple of NIW * 256 MB.
+
+On platforms that reserve physical addresses below 4 GB, such as the Low Memory
+Hole for PCIe MMIO on x86, an instance of CFMWS whose Base HPA range is 0 might
+have a size that doesn't align with the NIW * 256 MB constraint.
+
+Note that the matching intermediate Switch Decoders and the Endpoint Decoders
+HPA range sizes must still align to the above-mentioned rule, but the memory
+capacity that exceeds the CFMWS window size won't be accessible.".
diff --git a/Documentation/driver-api/cxl/devices/device-types.rst b/Documentation/driver-api/cxl/devices/device-types.rst
new file mode 100644
index 000000000000..7f69dfa4509b
--- /dev/null
+++ b/Documentation/driver-api/cxl/devices/device-types.rst
@@ -0,0 +1,165 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Devices and Protocols
+=====================
+
+The type of CXL device (Memory, Accelerator, etc) dictates many configuration steps. This section
+covers some basic background on device types and on-device resources used by the platform and OS
+which impact configuration.
+
+Protocols
+=========
+
+There are three core protocols to CXL. For the purpose of this documentation,
+we will only discuss very high level definitions as the specific hardware
+details are largely abstracted away from Linux. See the CXL specification
+for more details.
+
+CXL.io
+------
+The basic interaction protocol, similar to PCIe configuration mechanisms.
+Typically used for initialization, configuration, and I/O access for anything
+other than memory (CXL.mem) or cache (CXL.cache) operations.
+
+The Linux CXL driver exposes access to .io functionality via the various sysfs
+interfaces and /dev/cxl/ devices (which exposes direct access to device
+mailboxes).
+
+CXL.cache
+---------
+The mechanism by which a device may coherently access and cache host memory.
+
+Largely transparent to Linux once configured.
+
+CXL.mem
+---------
+The mechanism by which the CPU may coherently access and cache device memory.
+
+Largely transparent to Linux once configured.
+
+
+Device Types
+============
+
+Type-1
+------
+
+A Type-1 CXL device:
+
+* Supports cxl.io and cxl.cache protocols
+* Implements a fully coherent cache
+* Allows Device-to-Host coherence and Host-to-Device snoops.
+* Does NOT have host-managed device memory (HDM)
+
+Typical examples of type-1 devices is a Smart NIC - which may want to
+directly operate on host-memory (DMA) to store incoming packets. These
+devices largely rely on CPU-attached memory.
+
+Type-2
+------
+
+A Type-2 CXL Device:
+
+* Supports cxl.io, cxl.cache, and cxl.mem protocols
+* Optionally implements coherent cache and Host-Managed Device Memory
+* Is typically an accelerator device with high bandwidth memory.
+
+The primary difference between a type-1 and type-2 device is the presence
+of host-managed device memory, which allows the device to operate on a
+local memory bank - while the CPU still has coherent DMA to the same memory.
+
+This allows things like GPUs to expose their memory via DAX devices or file
+descriptors, allows drivers and programs direct access to device memory
+rather than use block-transfer semantics.
+
+Type-3
+------
+
+A Type-3 CXL Device
+
+* Supports cxl.io and cxl.mem
+* Implements Host-Managed Device Memory
+* May provide either Volatile or Persistent memory capacity (or both).
+
+A basic example of a type-3 device is a simple memory expander, whose
+local memory capacity is exposed to the CPU for access directly via
+basic coherent DMA.
+
+Switch
+------
+
+A CXL switch is a device capable of routing any CXL (and by extension, PCIe)
+protocol between an upstream, downstream, or peer devices. Many devices, such
+as Multi-Logical Devices, imply the presence of switching in some manner.
+
+Logical Devices and Heads
+-------------------------
+
+A CXL device may present one or more "Logical Devices" to one or more hosts
+(via physical "Heads").
+
+A Single-Logical Device (SLD) is a device which presents a single device to
+one or more heads.
+
+A Multi-Logical Device (MLD) is a device which may present multiple devices
+to one or more upstream devices.
+
+A Single-Headed Device exposes only a single physical connection.
+
+A Multi-Headed Device exposes multiple physical connections.
+
+MHSLD
+~~~~~
+A Multi-Headed Single-Logical Device (MHSLD) exposes a single logical
+device to multiple heads which may be connected to one or more discrete
+hosts. An example of this would be a simple memory-pool which may be
+statically configured (prior to boot) to expose portions of its memory
+to Linux via :doc:`CEDT <../platform/acpi/cedt>`.
+
+MHMLD
+~~~~~
+A Multi-Headed Multi-Logical Device (MHMLD) exposes multiple logical
+devices to multiple heads which may be connected to one or more discrete
+hosts. An example of this would be a Dynamic Capacity Device or which
+may be configured at runtime to expose portions of its memory to Linux.
+
+Example Devices
+===============
+
+Memory Expander
+---------------
+The simplest form of Type-3 device is a memory expander. A memory expander
+exposes Host-Managed Device Memory (HDM) to Linux. This memory may be
+Volatile or Non-Volatile (Persistent).
+
+Memory Expanders will typically be considered a form of Single-Headed,
+Single-Logical Device - as its form factor will typically be an add-in-card
+(AIC) or some other similar form-factor.
+
+The Linux CXL driver provides support for static or dynamic configuration of
+basic memory expanders. The platform may program decoders prior to OS init
+(e.g. auto-decoders), or the user may program the fabric if the platform
+defers these operations to the OS.
+
+Multiple Memory Expanders may be added to an external chassis and exposed to
+a host via a head attached to a CXL switch. This is a "memory pool", and
+would be considered an MHSLD or MHMLD depending on the management capabilities
+provided by the switch platform.
+
+As of v6.14, Linux does not provide a formalized interface to manage non-DCD
+MHSLD or MHMLD devices.
+
+Dynamic Capacity Device (DCD)
+-----------------------------
+
+A Dynamic Capacity Device is a Type-3 device which provides dynamic management
+of memory capacity. The basic premise of a DCD to provide an allocator-like
+interface for physical memory capacity to a "Fabric Manager" (an external,
+privileged host with privileges to change configurations for other hosts).
+
+A DCD manages "Memory Extents", which may be volatile or persistent. Extents
+may also be exclusive to a single host or shared across multiple hosts.
+
+As of v6.14, Linux does not provide a formalized interface to manage DCD
+devices, however there is active work on LKML targeting future release.
diff --git a/Documentation/driver-api/cxl/index.rst b/Documentation/driver-api/cxl/index.rst
index 036e49553542..c1106a68b67c 100644
--- a/Documentation/driver-api/cxl/index.rst
+++ b/Documentation/driver-api/cxl/index.rst
@@ -4,9 +4,51 @@
Compute Express Link
====================
+CXL device configuration has a complex handoff between platform (Hardware,
+BIOS, EFI), OS (early boot, core kernel, driver), and user policy decisions
+that have impacts on each other. The docs here break up configurations steps.
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Overview
+
+ theory-of-operation
+ maturity-map
+ conventions
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Device Reference
+
+ devices/device-types
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Platform Configuration
+
+ platform/bios-and-efi
+ platform/acpi
+ platform/cdat
+ platform/example-configs
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Linux Kernel Configuration
+
+ linux/overview
+ linux/early-boot
+ linux/cxl-driver
+ linux/dax-driver
+ linux/memory-hotplug
+ linux/access-coordinates
+
.. toctree::
- :maxdepth: 1
+ :maxdepth: 2
+ :caption: Memory Allocation
- memory-devices
+ allocation/dax
+ allocation/page-allocator
+ allocation/reclaim
+ allocation/hugepages.rst
.. only:: subproject and html
diff --git a/Documentation/driver-api/cxl/linux/access-coordinates.rst b/Documentation/driver-api/cxl/linux/access-coordinates.rst
new file mode 100644
index 000000000000..341a7c682043
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/access-coordinates.rst
@@ -0,0 +1,178 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+==================================
+CXL Access Coordinates Computation
+==================================
+
+Latency and Bandwidth Calculation
+=================================
+A memory region performance coordinates (latency and bandwidth) are typically
+provided via ACPI tables :doc:`SRAT <../platform/acpi/srat>` and
+:doc:`HMAT <../platform/acpi/hmat>`. However, the platform firmware (BIOS) is
+not able to annotate those for CXL devices that are hot-plugged since they do
+not exist during platform firmware initialization. The CXL driver can compute
+the performance coordinates by retrieving data from several components.
+
+The :doc:`SRAT <../platform/acpi/srat>` provides a Generic Port Affinity
+subtable that ties a proximity domain to a device handle, which in this case
+would be the CXL hostbridge. Using this association, the performance
+coordinates for the Generic Port can be retrieved from the
+:doc:`HMAT <../platform/acpi/hmat>` subtable. This piece represents the
+performance coordinates between a CPU and a Generic Port (CXL hostbridge).
+
+The :doc:`CDAT <../platform/cdat>` provides the performance coordinates for
+the CXL device itself. That is the bandwidth and latency to access that device's
+memory region. The DSMAS subtable provides a DSMADHandle that is tied to a
+Device Physical Address (DPA) range. The DSLBIS subtable provides the
+performance coordinates that's tied to a DSMADhandle and this ties the two
+table entries together to provide the performance coordinates for each DPA
+region. For example, if a device exports a DRAM region and a PMEM region,
+then there would be different performance characteristsics for each of those
+regions.
+
+If there's a CXL switch in the topology, then the performance coordinates for the
+switch is provided by SSLBIS subtable. This provides the bandwidth and latency
+for traversing the switch between the switch upstream port and the switch
+downstream port that points to the endpoint device.
+
+Simple topology example::
+
+ GP0/HB0/ACPI0016-0
+ RP0
+ |
+ | L0
+ |
+ SW 0 / USP0
+ SW 0 / DSP0
+ |
+ | L1
+ |
+ EP0
+
+In this example, there is a CXL switch between an endpoint and a root port.
+Latency in this example is calculated as such:
+L(EP0) - Latency from EP0 CDAT DSMAS+DSLBIS
+L(L1) - Link latency between EP0 and SW0DSP0
+L(SW0) - Latency for the switch from SW0 CDAT SSLBIS.
+L(L0) - Link latency between SW0 and RP0
+L(RP0) - Latency from root port to CPU via SRAT and HMAT (Generic Port).
+Total read and write latencies are the sum of all these parts.
+
+Bandwidth in this example is calculated as such:
+B(EP0) - Bandwidth from EP0 CDAT DSMAS+DSLBIS
+B(L1) - Link bandwidth between EP0 and SW0DSP0
+B(SW0) - Bandwidth for the switch from SW0 CDAT SSLBIS.
+B(L0) - Link bandwidth between SW0 and RP0
+B(RP0) - Bandwidth from root port to CPU via SRAT and HMAT (Generic Port).
+The total read and write bandwidth is the min() of all these parts.
+
+To calculate the link bandwidth:
+LinkOperatingFrequency (GT/s) is the current negotiated link speed.
+DataRatePerLink (MB/s) = LinkOperatingFrequency / 8
+Bandwidth (MB/s) = PCIeCurrentLinkWidth * DataRatePerLink
+Where PCIeCurrentLinkWidth is the number of lanes in the link.
+
+To calculate the link latency:
+LinkLatency (picoseconds) = FlitSize / LinkBandwidth (MB/s)
+
+See `CXL Memory Device SW Guide r1.0 <https://www.intel.com/content/www/us/en/content-details/643805/cxl-memory-device-software-guide.html>`_,
+section 2.11.3 and 2.11.4 for details.
+
+In the end, the access coordinates for a constructed memory region is calculated from one
+or more memory partitions from each of the CXL device(s).
+
+Shared Upstream Link Calculation
+================================
+For certain CXL region construction with endpoints behind CXL switches (SW) or
+Root Ports (RP), there is the possibility of the total bandwidth for all
+the endpoints behind a switch being more than the switch upstream link.
+A similar situation can occur within the host, upstream of the root ports.
+The CXL driver performs an additional pass after all the targets have
+arrived for a region in order to recalculate the bandwidths with possible
+upstream link being a limiting factor in mind.
+
+The algorithm assumes the configuration is a symmetric topology as that
+maximizes performance. When asymmetric topology is detected, the calculation
+is aborted. An asymmetric topology is detected during topology walk where the
+number of RPs detected as a grandparent is not equal to the number of devices
+iterated in the same iteration loop. The assumption is made that subtle
+asymmetry in properties does not happen and all paths to EPs are equal.
+
+There can be multiple switches under an RP. There can be multiple RPs under
+a CXL Host Bridge (HB). There can be multiple HBs under a CXL Fixed Memory
+Window Structure (CFMWS) in the :doc:`CEDT <../platform/acpi/cedt>`.
+
+An example hierarchy::
+
+ CFMWS 0
+ |
+ _________|_________
+ | |
+ ACPI0017-0 ACPI0017-1
+ GP0/HB0/ACPI0016-0 GP1/HB1/ACPI0016-1
+ | | | |
+ RP0 RP1 RP2 RP3
+ | | | |
+ SW 0 SW 1 SW 2 SW 3
+ | | | | | | | |
+ EP0 EP1 EP2 EP3 EP4 EP5 EP6 EP7
+
+Computation for the example hierarchy:
+
+Min (GP0 to CPU BW,
+ Min(SW 0 Upstream Link to RP0 BW,
+ Min(SW0SSLBIS for SW0DSP0 (EP0), EP0 DSLBIS, EP0 Upstream Link) +
+ Min(SW0SSLBIS for SW0DSP1 (EP1), EP1 DSLBIS, EP1 Upstream link)) +
+ Min(SW 1 Upstream Link to RP1 BW,
+ Min(SW1SSLBIS for SW1DSP0 (EP2), EP2 DSLBIS, EP2 Upstream Link) +
+ Min(SW1SSLBIS for SW1DSP1 (EP3), EP3 DSLBIS, EP3 Upstream link))) +
+Min (GP1 to CPU BW,
+ Min(SW 2 Upstream Link to RP2 BW,
+ Min(SW2SSLBIS for SW2DSP0 (EP4), EP4 DSLBIS, EP4 Upstream Link) +
+ Min(SW2SSLBIS for SW2DSP1 (EP5), EP5 DSLBIS, EP5 Upstream link)) +
+ Min(SW 3 Upstream Link to RP3 BW,
+ Min(SW3SSLBIS for SW3DSP0 (EP6), EP6 DSLBIS, EP6 Upstream Link) +
+ Min(SW3SSLBIS for SW3DSP1 (EP7), EP7 DSLBIS, EP7 Upstream link))))
+
+The calculation starts at cxl_region_shared_upstream_perf_update(). A xarray
+is created to collect all the endpoint bandwidths via the
+cxl_endpoint_gather_bandwidth() function. The min() of bandwidth from the
+endpoint CDAT and the upstream link bandwidth is calculated. If the endpoint
+has a CXL switch as a parent, then min() of calculated bandwidth and the
+bandwidth from the SSLBIS for the switch downstream port that is associated
+with the endpoint is calculated. The final bandwidth is stored in a
+'struct cxl_perf_ctx' in the xarray indexed by a device pointer. If the
+endpoint is direct attached to a root port (RP), the device pointer would be an
+RP device. If the endpoint is behind a switch, the device pointer would be the
+upstream device of the parent switch.
+
+At the next stage, the code walks through one or more switches if they exist
+in the topology. For endpoints directly attached to RPs, this step is skipped.
+If there is another switch upstream, the code takes the min() of the current
+gathered bandwidth and the upstream link bandwidth. If there's a switch
+upstream, then the SSLBIS of the upstream switch.
+
+Once the topology walk reaches the RP, whether it's direct attached endpoints
+or walking through the switch(es), cxl_rp_gather_bandwidth() is called. At
+this point all the bandwidths are aggregated per each host bridge, which is
+also the index for the resulting xarray.
+
+The next step is to take the min() of the per host bridge bandwidth and the
+bandwidth from the Generic Port (GP). The bandwidths for the GP are retrieved
+via ACPI tables (:doc:`SRAT <../platform/acpi/srat>` and
+:doc:`HMAT <../platform/acpi/hmat>`). The minimum bandwidth are aggregated
+under the same ACPI0017 device to form a new xarray.
+
+Finally, the cxl_region_update_bandwidth() is called and the aggregated
+bandwidth from all the members of the last xarray is updated for the
+access coordinates residing in the cxl region (cxlr) context.
+
+QTG ID
+======
+Each :doc:`CEDT <../platform/acpi/cedt>` has a QTG ID field. This field provides
+the ID that associates with a QoS Throttling Group (QTG) for the CFMWS window.
+Once the access coordinates are calculated, an ACPI Device Specific Method can
+be issued to the ACPI0016 device to retrieve the QTG ID depends on the access
+coordinates provided. The QTG ID for the device can be used as guidance to match
+to the CFMWS to setup the best Linux root decoder for the device performance.
diff --git a/Documentation/driver-api/cxl/linux/cxl-driver.rst b/Documentation/driver-api/cxl/linux/cxl-driver.rst
new file mode 100644
index 000000000000..dd6dd17dc536
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/cxl-driver.rst
@@ -0,0 +1,630 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+CXL Driver Operation
+====================
+
+The devices described in this section are present in ::
+
+ /sys/bus/cxl/devices/
+ /dev/cxl/
+
+The :code:`cxl-cli` library, maintained as part of the NDTCL project, may
+be used to script interactions with these devices.
+
+Drivers
+=======
+The CXL driver is split into a number of drivers.
+
+* cxl_core - fundamental init interface and core object creation
+* cxl_port - initializes root and provides port enumeration interface.
+* cxl_acpi - initializes root decoders and interacts with ACPI data.
+* cxl_p/mem - initializes memory devices
+* cxl_pci - uses cxl_port to enumerate the actual fabric hierarchy.
+
+Driver Devices
+==============
+Here is an example from a single-socket system with 4 host bridges. Two host
+bridges have a single memory device attached, and the devices are interleaved
+into a single memory region. The memory region has been converted to dax. ::
+
+ # ls /sys/bus/cxl/devices/
+ dax_region0 decoder3.0 decoder6.0 mem0 port3
+ decoder0.0 decoder4.0 decoder6.1 mem1 port4
+ decoder1.0 decoder5.0 endpoint5 port1 region0
+ decoder2.0 decoder5.1 endpoint6 port2 root0
+
+
+.. kernel-render:: DOT
+ :alt: Digraph of CXL fabric describing host-bridge interleaving
+ :caption: Diagraph of CXL fabric with a host-bridge interleave memory region
+
+ digraph foo {
+ "root0" -> "port1";
+ "root0" -> "port3";
+ "root0" -> "decoder0.0";
+ "port1" -> "endpoint5";
+ "port3" -> "endpoint6";
+ "port1" -> "decoder1.0";
+ "port3" -> "decoder3.0";
+ "endpoint5" -> "decoder5.0";
+ "endpoint6" -> "decoder6.0";
+ "decoder0.0" -> "region0";
+ "decoder0.0" -> "decoder1.0";
+ "decoder0.0" -> "decoder3.0";
+ "decoder1.0" -> "decoder5.0";
+ "decoder3.0" -> "decoder6.0";
+ "decoder5.0" -> "region0";
+ "decoder6.0" -> "region0";
+ "region0" -> "dax_region0";
+ "dax_region0" -> "dax0.0";
+ }
+
+For this section we'll explore the devices present in this configuration, but
+we'll explore more configurations in-depth in example configurations below.
+
+Base Devices
+------------
+Most devices in a CXL fabric are a `port` of some kind (because each
+device mostly routes request from one device to the next, rather than
+provide a direct service).
+
+Root
+~~~~
+The `CXL Root` is logical object created by the `cxl_acpi` driver during
+:code:`cxl_acpi_probe` - if the :code:`ACPI0017` `Compute Express Link
+Root Object` Device Class is found.
+
+The Root contains links to:
+
+* `Host Bridge Ports` defined by CHBS in the :doc:`CEDT<../platform/acpi/cedt>`
+
+* `Downstream Ports` typically connected to `Host Bridge Ports`.
+
+* `Root Decoders` defined by CFMWS the :doc:`CEDT<../platform/acpi/cedt>`
+
+::
+
+ # ls /sys/bus/cxl/devices/root0
+ decoder0.0 dport0 dport5 port2 subsystem
+ decoders_committed dport1 modalias port3 uevent
+ devtype dport4 port1 port4 uport
+
+ # cat /sys/bus/cxl/devices/root0/devtype
+ cxl_port
+
+ # cat port1/devtype
+ cxl_port
+
+ # cat decoder0.0/devtype
+ cxl_decoder_root
+
+The root is first `logical port` in the CXL fabric, as presented by the Linux
+CXL driver. The `CXL root` is a special type of `switch port`, in that it
+only has downstream port connections.
+
+Port
+~~~~
+A `port` object is better described as a `switch port`. It may represent a
+host bridge to the root or an actual switch port on a switch. A `switch port`
+contains one or more decoders used to route memory requests downstream ports,
+which may be connected to another `switch port` or an `endpoint port`.
+
+::
+
+ # ls /sys/bus/cxl/devices/port1
+ decoder1.0 dport0 driver parent_dport uport
+ decoders_committed dport113 endpoint5 subsystem
+ devtype dport2 modalias uevent
+
+ # cat devtype
+ cxl_port
+
+ # cat decoder1.0/devtype
+ cxl_decoder_switch
+
+ # cat endpoint5/devtype
+ cxl_port
+
+CXL `Host Bridges` in the fabric are probed during :code:`cxl_acpi_probe` at
+the time the `CXL Root` is probed. The allows for the immediate logical
+connection to between the root and host bridge.
+
+* The root has a downstream port connection to a host bridge
+
+* The host bridge has an upstream port connection to the root.
+
+* The host bridge has one or more downstream port connections to switch
+ or endpoint ports.
+
+A `Host Bridge` is a special type of CXL `switch port`. It is explicitly
+defined in the ACPI specification via `ACPI0016` ID. `Host Bridge` ports
+will be probed at `acpi_probe` time, while similar ports on an actual switch
+will be probed later. Otherwise, switch and host bridge ports look very
+similar - the both contain switch decoders which route accesses between
+upstream and downstream ports.
+
+Endpoint
+~~~~~~~~
+An `endpoint` is a terminal port in the fabric. This is a `logical device`,
+and may be one of many `logical devices` presented by a memory device. It
+is still considered a type of `port` in the fabric.
+
+An `endpoint` contains `endpoint decoders` and the device's Coherent Device
+Attribute Table (which describes the device's capabilities). ::
+
+ # ls /sys/bus/cxl/devices/endpoint5
+ CDAT decoders_committed modalias uevent
+ decoder5.0 devtype parent_dport uport
+ decoder5.1 driver subsystem
+
+ # cat /sys/bus/cxl/devices/endpoint5/devtype
+ cxl_port
+
+ # cat /sys/bus/cxl/devices/endpoint5/decoder5.0/devtype
+ cxl_decoder_endpoint
+
+
+Memory Device (memdev)
+~~~~~~~~~~~~~~~~~~~~~~
+A `memdev` is probed and added by the `cxl_pci` driver in :code:`cxl_pci_probe`
+and is managed by the `cxl_mem` driver. It primarily provides the `IOCTL`
+interface to a memory device, via :code:`/dev/cxl/memN`, and exposes various
+device configuration data. ::
+
+ # ls /sys/bus/cxl/devices/mem0
+ dev firmware_version payload_max security uevent
+ driver label_storage_size pmem serial
+ firmware numa_node ram subsystem
+
+A Memory Device is a discrete base object that is not a port. While the
+physical device it belongs to may also host an `endpoint`, the relationship
+between an `endpoint` and a `memdev` is not captured in sysfs.
+
+Port Relationships
+~~~~~~~~~~~~~~~~~~
+In our example described above, there are four host bridges attached to the
+root, and two of the host bridges have one endpoint attached.
+
+.. kernel-render:: DOT
+ :alt: Digraph of CXL fabric describing host-bridge interleaving
+ :caption: Diagraph of CXL fabric with a host-bridge interleave memory region
+
+ digraph foo {
+ "root0" -> "port1";
+ "root0" -> "port2";
+ "root0" -> "port3";
+ "root0" -> "port4";
+ "port1" -> "endpoint5";
+ "port3" -> "endpoint6";
+ }
+
+Decoders
+--------
+A `Decoder` is short for a CXL Host-Managed Device Memory (HDM) Decoder. It is
+a device that routes accesses through the CXL fabric to an endpoint, and at
+the endpoint translates a `Host Physical` to `Device Physical` Addressing.
+
+The CXL 3.1 specification heavily implies that only endpoint decoders should
+engage in translation of `Host Physical Address` to `Device Physical Address`.
+::
+
+ 8.2.4.20 CXL HDM Decoder Capability Structure
+
+ IMPLEMENTATION NOTE
+ CXL Host Bridge and Upstream Switch Port Decode Flow
+
+ IMPLEMENTATION NOTE
+ Device Decode Logic
+
+These notes imply that there are two logical groups of decoders.
+
+* Routing Decoder - a decoder which routes accesses but does not translate
+ addresses from HPA to DPA.
+
+* Translating Decoder - a decoder which translates accesses from HPA to DPA
+ for an endpoint to service.
+
+The CXL drivers distinguish 3 decoder types: root, switch, and endpoint. Only
+endpoint decoders are Translating Decoders, all others are Routing Decoders.
+
+.. note:: PLATFORM VENDORS BE AWARE
+
+ Linux makes a strong assumption that endpoint decoders are the only decoder
+ in the fabric that actively translates HPA to DPA. Linux assumes routing
+ decoders pass the HPA unchanged to the next decoder in the fabric.
+
+ It is therefore assumed that any given decoder in the fabric will have an
+ address range that is a subset of its upstream port decoder. Any deviation
+ from this scheme undefined per the specification. Linux prioritizes
+ spec-defined / architectural behavior.
+
+Decoders may have one or more `Downstream Targets` if configured to interleave
+memory accesses. This will be presented in sysfs via the :code:`target_list`
+parameter.
+
+Root Decoder
+~~~~~~~~~~~~
+A `Root Decoder` is logical construct of the physical address and interleave
+configurations present in the CFMWS field of the :doc:`CEDT
+<../platform/acpi/cedt>`.
+Linux presents this information as a decoder present in the `CXL Root`. We
+consider this a `Root Decoder`, though technically it exists on the boundary
+of the CXL specification and platform-specific CXL root implementations.
+
+Linux considers these logical decoders a type of `Routing Decoder`, and is the
+first decoder in the CXL fabric to receive a memory access from the platform's
+memory controllers.
+
+`Root Decoders` are created during :code:`cxl_acpi_probe`. One root decoder
+is created per CFMWS entry in the :doc:`CEDT <../platform/acpi/cedt>`.
+
+The :code:`target_list` parameter is filled by the CFMWS target fields. Targets
+of a root decoder are `Host Bridges`, which means interleave done at the root
+decoder level is an `Inter-Host-Bridge Interleave`.
+
+Only root decoders are capable of `Inter-Host-Bridge Interleave`.
+
+Such interleaves must be configured by the platform and described in the ACPI
+CEDT CFMWS, as the target CXL host bridge UIDs in the CFMWS must match the CXL
+host bridge UIDs in the CHBS field of the :doc:`CEDT
+<../platform/acpi/cedt>` and the UID field of CXL Host Bridges defined in
+the :doc:`DSDT <../platform/acpi/dsdt>`.
+
+Interleave settings in a root decoder describe how to interleave accesses among
+the *immediate downstream targets*, not the entire interleave set.
+
+The memory range described in the root decoder is used to
+
+1) Create a memory region (:code:`region0` in this example), and
+
+2) Associate the region with an IO Memory Resource (:code:`kernel/resource.c`)
+
+::
+
+ # ls /sys/bus/cxl/devices/decoder0.0/
+ cap_pmem devtype region0
+ cap_ram interleave_granularity size
+ cap_type2 interleave_ways start
+ cap_type3 locked subsystem
+ create_ram_region modalias target_list
+ delete_region qos_class uevent
+
+ # cat /sys/bus/cxl/devices/decoder0.0/region0/resource
+ 0xc050000000
+
+The IO Memory Resource is created during early boot when the CFMWS region is
+identified in the EFI Memory Map or E820 table (on x86).
+
+Root decoders are defined as a separate devtype, but are also a type
+of `Switch Decoder` due to having downstream targets. ::
+
+ # cat /sys/bus/cxl/devices/decoder0.0/devtype
+ cxl_decoder_root
+
+Switch Decoder
+~~~~~~~~~~~~~~
+Any non-root, translating decoder is considered a `Switch Decoder`, and will
+present with the type :code:`cxl_decoder_switch`. Both `Host Bridge` and `CXL
+Switch` (device) decoders are of type :code:`cxl_decoder_switch`. ::
+
+ # ls /sys/bus/cxl/devices/decoder1.0/
+ devtype locked size target_list
+ interleave_granularity modalias start target_type
+ interleave_ways region subsystem uevent
+
+ # cat /sys/bus/cxl/devices/decoder1.0/devtype
+ cxl_decoder_switch
+
+ # cat /sys/bus/cxl/devices/decoder1.0/region
+ region0
+
+A `Switch Decoder` has associations between a region defined by a root
+decoder and downstream target ports. Interleaving done within a switch decoder
+is a multi-downstream-port interleave (or `Intra-Host-Bridge Interleave` for
+host bridges).
+
+Interleave settings in a switch decoder describe how to interleave accesses
+among the *immediate downstream targets*, not the entire interleave set.
+
+Switch decoders are created during :code:`cxl_switch_port_probe` in the
+:code:`cxl_port` driver, and is created based on a PCI device's DVSEC
+registers.
+
+Switch decoder programming is validated during probe if the platform programs
+them during boot (See `Auto Decoders` below), or on commit if programmed at
+runtime (See `Runtime Programming` below).
+
+
+Endpoint Decoder
+~~~~~~~~~~~~~~~~
+Any decoder attached to a *terminal* point in the CXL fabric (`An Endpoint`) is
+considered an `Endpoint Decoder`. Endpoint decoders are of type
+:code:`cxl_decoder_endpoint`. ::
+
+ # ls /sys/bus/cxl/devices/decoder5.0
+ devtype locked start
+ dpa_resource modalias subsystem
+ dpa_size mode target_type
+ interleave_granularity region uevent
+ interleave_ways size
+
+ # cat /sys/bus/cxl/devices/decoder5.0/devtype
+ cxl_decoder_endpoint
+
+ # cat /sys/bus/cxl/devices/decoder5.0/region
+ region0
+
+An `Endpoint Decoder` has an association with a region defined by a root
+decoder and describes the device-local resource associated with this region.
+
+Unlike root and switch decoders, endpoint decoders translate `Host Physical` to
+`Device Physical` address ranges. The interleave settings on an endpoint
+therefore describe the entire *interleave set*.
+
+`Device Physical Address` regions must be committed in-order. For example, the
+DPA region starting at 0x80000000 cannot be committed before the DPA region
+starting at 0x0.
+
+As of Linux v6.15, Linux does not support *imbalanced* interleave setups, all
+endpoints in an interleave set are expected to have the same interleave
+settings (granularity and ways must be the same).
+
+Endpoint decoders are created during :code:`cxl_endpoint_port_probe` in the
+:code:`cxl_port` driver, and is created based on a PCI device's DVSEC registers.
+
+Decoder Relationships
+~~~~~~~~~~~~~~~~~~~~~
+In our example described above, there is one root decoder which routes memory
+accesses over two host bridges. Each host bridge has a decoder which routes
+access to their singular endpoint targets. Each endpoint has a decoder which
+translates HPA to DPA and services the memory request.
+
+The driver validates relationships between ports by decoder programming, so
+we can think of decoders being related in a similarly hierarchical fashion to
+ports.
+
+.. kernel-render:: DOT
+ :alt: Digraph of hierarchical relationship between root, switch, and endpoint decoders.
+ :caption: Diagraph of CXL root, switch, and endpoint decoders.
+
+ digraph foo {
+ "root0" -> "decoder0.0";
+ "decoder0.0" -> "decoder1.0";
+ "decoder0.0" -> "decoder3.0";
+ "decoder1.0" -> "decoder5.0";
+ "decoder3.0" -> "decoder6.0";
+ }
+
+Regions
+-------
+
+Memory Region
+~~~~~~~~~~~~~
+A `Memory Region` is a logical construct that connects a set of CXL ports in
+the fabric to an IO Memory Resource. It is ultimately used to expose the memory
+on these devices to the DAX subsystem via a `DAX Region`.
+
+An example RAM region: ::
+
+ # ls /sys/bus/cxl/devices/region0/
+ access0 devtype modalias subsystem uuid
+ access1 driver mode target0
+ commit interleave_granularity resource target1
+ dax_region0 interleave_ways size uevent
+
+A memory region can be constructed during endpoint probe, if decoders were
+programmed by BIOS/EFI (see `Auto Decoders`), or by creating a region manually
+via a `Root Decoder`'s :code:`create_ram_region` or :code:`create_pmem_region`
+interfaces.
+
+The interleave settings in a `Memory Region` describe the configuration of the
+`Interleave Set` - and are what can be expected to be seen in the endpoint
+interleave settings.
+
+.. kernel-render:: DOT
+ :alt: Digraph of CXL memory region relationships between root and endpoint decoders.
+ :caption: Regions are created based on root decoder configurations. Endpoint decoders
+ must be programmed with the same interleave settings as the region.
+
+ digraph foo {
+ "root0" -> "decoder0.0";
+ "decoder0.0" -> "region0";
+ "region0" -> "decoder5.0";
+ "region0" -> "decoder6.0";
+ }
+
+DAX Region
+~~~~~~~~~~
+A `DAX Region` is used to convert a CXL `Memory Region` to a DAX device. A
+DAX device may then be accessed directly via a file descriptor interface, or
+converted to System RAM via the DAX kmem driver. See the DAX driver section
+for more details. ::
+
+ # ls /sys/bus/cxl/devices/dax_region0/
+ dax0.0 devtype modalias uevent
+ dax_region driver subsystem
+
+Mailbox Interfaces
+------------------
+A mailbox command interface for each device is exposed in ::
+
+ /dev/cxl/mem0
+ /dev/cxl/mem1
+
+These mailboxes may receive any specification-defined command. Raw commands
+(custom commands) can only be sent to these interfaces if the build config
+:code:`CXL_MEM_RAW_COMMANDS` is set. This is considered a debug and/or
+development interface, not an officially supported mechanism for creation
+of vendor-specific commands (see the `fwctl` subsystem for that).
+
+Decoder Programming
+===================
+
+Runtime Programming
+-------------------
+During probe, the only decoders *required* to be programmed are `Root Decoders`.
+In reality, `Root Decoders` are a logical construct to describe the memory
+region and interleave configuration at the host bridge level - as described
+in the ACPI CEDT CFMWS.
+
+All other `Switch` and `Endpoint` decoders may be programmed by the user
+at runtime - if the platform supports such configurations.
+
+This interaction is what creates a `Software Defined Memory` environment.
+
+See the :code:`cxl-cli` documentation for more information about how to
+configure CXL decoders at runtime.
+
+Auto Decoders
+-------------
+Auto Decoders are decoders programmed by BIOS/EFI at boot time, and are
+almost always locked (cannot be changed). This is done by a platform
+which may have a static configuration - or certain quirks which may prevent
+dynamic runtime changes to the decoders (such as requiring additional
+controller programming within the CPU complex outside the scope of CXL).
+
+Auto Decoders are probed automatically as long as the devices and memory
+regions they are associated with probe without issue. When probing Auto
+Decoders, the driver's primary responsibility is to ensure the fabric is
+sane - as-if validating runtime programmed regions and decoders.
+
+If Linux cannot validate auto-decoder configuration, the memory will not
+be surfaced as a DAX device - and therefore not be exposed to the page
+allocator - effectively stranding it.
+
+Interleave
+----------
+
+The Linux CXL driver supports `Cross-Link First` interleave. This dictates
+how interleave is programmed at each decoder step, as the driver validates
+the relationships between a decoder and it's parent.
+
+For example, in a `Cross-Link First` interleave setup with 16 endpoints
+attached to 4 host bridges, linux expects the following ways/granularity
+across the root, host bridge, and endpoints respectively.
+
+.. flat-table:: 4x4 cross-link first interleave settings
+
+ * - decoder
+ - ways
+ - granularity
+
+ * - root
+ - 4
+ - 256
+
+ * - host bridge
+ - 4
+ - 1024
+
+ * - endpoint
+ - 16
+ - 256
+
+At the root, every a given access will be routed to the
+:code:`((HPA / 256) % 4)th` target host bridge. Within a host bridge, every
+:code:`((HPA / 1024) % 4)th` target endpoint. Each endpoint translates based
+on the entire 16 device interleave set.
+
+Unbalanced interleave sets are not supported - decoders at a similar point
+in the hierarchy (e.g. all host bridge decoders) must have the same ways and
+granularity configuration.
+
+At Root
+~~~~~~~
+Root decoder interleave is defined by CFMWS field of the :doc:`CEDT
+<../platform/acpi/cedt>`. The CEDT may actually define multiple CFMWS
+configurations to describe the same physical capacity, with the intent to allow
+users to decide at runtime whether to online memory as interleaved or
+non-interleaved. ::
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Window base address : 0000000100000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ First Target : 00000007
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Window base address : 0000000200000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ First Target : 00000006
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Window base address : 0000000300000000
+ Window size : 0000000200000000
+ Interleave Members (2^n) : 01
+ Interleave Arithmetic : 00
+ First Target : 00000007
+ Next Target : 00000006
+
+In this example, the CFMWS defines two discrete non-interleaved 4GB regions
+for each host bridge, and one interleaved 8GB region that targets both. This
+would result in 3 root decoders presenting in the root. ::
+
+ # ls /sys/bus/cxl/devices/root0/decoder*
+ decoder0.0 decoder0.1 decoder0.2
+
+ # cat /sys/bus/cxl/devices/decoder0.0/target_list start size
+ 7
+ 0x100000000
+ 0x100000000
+
+ # cat /sys/bus/cxl/devices/decoder0.1/target_list start size
+ 6
+ 0x200000000
+ 0x100000000
+
+ # cat /sys/bus/cxl/devices/decoder0.2/target_list start size
+ 7,6
+ 0x300000000
+ 0x200000000
+
+These decoders are not runtime programmable. They are used to generate a
+`Memory Region` to bring this memory online with runtime programmed settings
+at the `Switch` and `Endpoint` decoders.
+
+At Host Bridge or Switch
+~~~~~~~~~~~~~~~~~~~~~~~~
+`Host Bridge` and `Switch` decoders are programmable via the following fields:
+
+- :code:`start` - the HPA region associated with the memory region
+- :code:`size` - the size of the region
+- :code:`target_list` - the list of downstream ports
+- :code:`interleave_ways` - the number downstream ports to interleave across
+- :code:`interleave_granularity` - the granularity to interleave at.
+
+Linux expects the :code:`interleave_granularity` of switch decoders to be
+derived from their upstream port connections. In `Cross-Link First` interleave
+configurations, the :code:`interleave_granularity` of a decoder is equal to
+:code:`parent_interleave_granularity * parent_interleave_ways`.
+
+At Endpoint
+~~~~~~~~~~~
+`Endpoint Decoders` are programmed similar to Host Bridge and Switch decoders,
+with the exception that the ways and granularity are defined by the interleave
+set (e.g. the interleave settings defined by the associated `Memory Region`).
+
+- :code:`start` - the HPA region associated with the memory region
+- :code:`size` - the size of the region
+- :code:`interleave_ways` - the number endpoints in the interleave set
+- :code:`interleave_granularity` - the granularity to interleave at.
+
+These settings are used by endpoint decoders to *Translate* memory requests
+from HPA to DPA. This is why they must be aware of the entire interleave set.
+
+Linux does not support unbalanced interleave configurations. As a result, all
+endpoints in an interleave set must have the same ways and granularity.
+
+Example Configurations
+======================
+.. toctree::
+ :maxdepth: 1
+
+ example-configurations/single-device.rst
+ example-configurations/hb-interleave.rst
+ example-configurations/intra-hb-interleave.rst
+ example-configurations/multi-interleave.rst
diff --git a/Documentation/driver-api/cxl/linux/dax-driver.rst b/Documentation/driver-api/cxl/linux/dax-driver.rst
new file mode 100644
index 000000000000..10d953a2167b
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/dax-driver.rst
@@ -0,0 +1,43 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+DAX Driver Operation
+====================
+The `Direct Access Device` driver was originally designed to provide a
+memory-like access mechanism to memory-like block-devices. It was
+extended to support CXL Memory Devices, which provide user-configured
+memory devices.
+
+The CXL subsystem depends on the DAX subsystem to either:
+
+- Generate a file-like interface to userland via :code:`/dev/daxN.Y`, or
+- Engage the memory-hotplug interface to add CXL memory to page allocator.
+
+The DAX subsystem exposes this ability through the `cxl_dax_region` driver.
+A `dax_region` provides the translation between a CXL `memory_region` and
+a `DAX Device`.
+
+DAX Device
+==========
+A `DAX Device` is a file-like interface exposed in :code:`/dev/daxN.Y`. A
+memory region exposed via dax device can be accessed via userland software
+via the :code:`mmap()` system-call. The result is direct mappings to the
+CXL capacity in the task's page tables.
+
+Users wishing to manually handle allocation of CXL memory should use this
+interface.
+
+kmem conversion
+===============
+The :code:`dax_kmem` driver converts a `DAX Device` into a series of `hotplug
+memory blocks` managed by :code:`kernel/memory-hotplug.c`. This capacity
+will be exposed to the kernel page allocator in the user-selected memory
+zone.
+
+The :code:`memmap_on_memory` setting (both global and DAX device local)
+dictates where the kernell will allocate the :code:`struct folio` descriptors
+for this memory will come from. If :code:`memmap_on_memory` is set, memory
+hotplug will set aside a portion of the memory block capacity to allocate
+folios. If unset, the memory is allocated via a normal :code:`GFP_KERNEL`
+allocation - and as a result will most likely land on the local NUM node of the
+CPU executing the hotplug operation.
diff --git a/Documentation/driver-api/cxl/linux/early-boot.rst b/Documentation/driver-api/cxl/linux/early-boot.rst
new file mode 100644
index 000000000000..a7fc6fc85fbe
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/early-boot.rst
@@ -0,0 +1,137 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+Linux Init (Early Boot)
+=======================
+
+Linux configuration is split into two major steps: Early-Boot and everything else.
+
+During early boot, Linux sets up immutable resources (such as numa nodes), while
+later operations include things like driver probe and memory hotplug. Linux may
+read EFI and ACPI information throughout this process to configure logical
+representations of the devices.
+
+During Linux Early Boot stage (functions in the kernel that have the __init
+decorator), the system takes the resources created by EFI/BIOS
+(:doc:`ACPI tables <../platform/acpi>`) and turns them into resources that the
+kernel can consume.
+
+
+BIOS, Build and Boot Options
+============================
+
+There are 4 pre-boot options that need to be considered during kernel build
+which dictate how memory will be managed by Linux during early boot.
+
+* EFI_MEMORY_SP
+
+ * BIOS/EFI Option that dictates whether memory is SystemRAM or
+ Specific Purpose. Specific Purpose memory will be deferred to
+ drivers to manage - and not immediately exposed as system RAM.
+
+* CONFIG_EFI_SOFT_RESERVE
+
+ * Linux Build config option that dictates whether the kernel supports
+ Specific Purpose memory.
+
+* CONFIG_MHP_DEFAULT_ONLINE_TYPE
+
+ * Linux Build config that dictates whether and how Specific Purpose memory
+ converted to a dax device should be managed (left as DAX or onlined as
+ SystemRAM in ZONE_NORMAL or ZONE_MOVABLE).
+
+* nosoftreserve
+
+ * Linux kernel boot option that dictates whether Soft Reserve should be
+ supported. Similar to CONFIG_EFI_SOFT_RESERVE.
+
+Memory Map Creation
+===================
+
+While the kernel parses the EFI memory map, if :code:`Specific Purpose` memory
+is supported and detected, it will set this region aside as
+:code:`SOFT_RESERVED`.
+
+If :code:`EFI_MEMORY_SP=0`, :code:`CONFIG_EFI_SOFT_RESERVE=n`, or
+:code:`nosoftreserve=y` - Linux will default a CXL device memory region to
+SystemRAM. This will expose the memory to the kernel page allocator in
+:code:`ZONE_NORMAL`, making it available for use for most allocations (including
+:code:`struct page` and page tables).
+
+If `Specific Purpose` is set and supported, :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE_*`
+dictates whether the memory is onlined by default (:code:`_OFFLINE` or
+:code:`_ONLINE_*`), and if online which zone to online this memory to by default
+(:code:`_NORMAL` or :code:`_MOVABLE`).
+
+If placed in :code:`ZONE_MOVABLE`, the memory will not be available for most
+kernel allocations (such as :code:`struct page` or page tables). This may
+significant impact performance depending on the memory capacity of the system.
+
+
+NUMA Node Reservation
+=====================
+
+Linux refers to the proximity domains (:code:`PXM`) defined in the :doc:`SRAT
+<../platform/acpi/srat>` to create NUMA nodes in :code:`acpi_numa_init`.
+Typically, there is a 1:1 relation between :code:`PXM` and NUMA node IDs.
+
+The SRAT is the only ACPI defined way of defining Proximity Domains. Linux
+chooses to, at most, map those 1:1 with NUMA nodes.
+:doc:`CEDT <../platform/acpi/cedt>` adds a description of SPA ranges which
+Linux may map to one or more NUMA nodes.
+
+If there are CXL ranges in the CFMWS but not in SRAT, then a fake :code:`PXM`
+is created (as of v6.15). In the future, Linux may reject CFMWS not described
+by SRAT due to the ambiguity of proximity domain association.
+
+It is important to note that NUMA node creation cannot be done at runtime. All
+possible NUMA nodes are identified at :code:`__init` time, more specifically
+during :code:`mm_init`. The CEDT and SRAT must contain sufficient :code:`PXM`
+data for Linux to identify NUMA nodes their associated memory regions.
+
+The relevant code exists in: :code:`linux/drivers/acpi/numa/srat.c`.
+
+See :doc:`Example Platform Configurations <../platform/example-configs>`
+for more info.
+
+Memory Tiers Creation
+=====================
+Memory tiers are a collection of NUMA nodes grouped by performance characteristics.
+During :code:`__init`, Linux initializes the system with a default memory tier that
+contains all nodes marked :code:`N_MEMORY`.
+
+:code:`memory_tier_init` is called at boot for all nodes with memory online by
+default. :code:`memory_tier_late_init` is called during late-init for nodes setup
+during driver configuration.
+
+Nodes are only marked :code:`N_MEMORY` if they have *online* memory.
+
+Tier membership can be inspected in ::
+
+ /sys/devices/virtual/memory_tiering/memory_tierN/nodelist
+ 0-1
+
+If nodes are grouped which have clear difference in performance, check the
+:doc:`HMAT <../platform/acpi/hmat>` and CDAT information for the CXL nodes. All
+nodes default to the DRAM tier, unless HMAT/CDAT information is reported to the
+memory_tier component via `access_coordinates`.
+
+For more, see :doc:`CXL access coordinates documentation
+<../linux/access-coordinates>`.
+
+Contiguous Memory Allocation
+============================
+The contiguous memory allocator (CMA) enables reservation of contiguous memory
+regions on NUMA nodes during early boot. However, CMA cannot reserve memory
+on NUMA nodes that are not online during early boot. ::
+
+ void __init hugetlb_cma_reserve(int order) {
+ if (!node_online(nid))
+ /* do not allow reservations */
+ }
+
+This means if users intend to defer management of CXL memory to the driver, CMA
+cannot be used to guarantee huge page allocations. If enabling CXL memory as
+SystemRAM in `ZONE_NORMAL` during early boot, CMA reservations per-node can be
+made with the :code:`cma_pernuma` or :code:`numa_cma` kernel command line
+parameters.
diff --git a/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst
new file mode 100644
index 000000000000..f071490763a2
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/example-configurations/hb-interleave.rst
@@ -0,0 +1,314 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+Inter-Host-Bridge Interleave
+============================
+This cxl-cli configuration dump shows the following host configuration:
+
+* A single socket system with one CXL root
+* CXL Root has Four (4) CXL Host Bridges
+* Two CXL Host Bridges have a single CXL Memory Expander Attached
+* The CXL root is configured to interleave across the two host bridges.
+
+This output is generated by :code:`cxl list -v` and describes the relationships
+between objects exposed in :code:`/sys/bus/cxl/devices/`.
+
+::
+
+ [
+ {
+ "bus":"root0",
+ "provider":"ACPI.CXL",
+ "nr_dports":4,
+ "dports":[
+ {
+ "dport":"pci0000:00",
+ "alias":"ACPI0016:01",
+ "id":0
+ },
+ {
+ "dport":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "id":4
+ },
+ {
+ "dport":"pci0000:2a",
+ "alias":"ACPI0016:03",
+ "id":1
+ },
+ {
+ "dport":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "id":5
+ }
+ ],
+
+This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL
+Host Bridges. The `Root` can be considered the singular upstream port attached
+to the platform's memory controller - which routes memory requests to it.
+
+The `ports:root0` section lays out how each of these downstream ports are
+configured. If a port is not configured (id's 0 and 1), they are omitted.
+
+::
+
+ "ports:root0":[
+ {
+ "port":"port1",
+ "host":"pci0000:d2",
+ "depth":1,
+ "nr_dports":3,
+ "dports":[
+ {
+ "dport":"0000:d2:01.1",
+ "alias":"device:02",
+ "id":0
+ },
+ {
+ "dport":"0000:d2:01.3",
+ "alias":"device:05",
+ "id":2
+ },
+ {
+ "dport":"0000:d2:07.1",
+ "alias":"device:0d",
+ "id":113
+ }
+ ],
+
+This chunk shows the available downstream ports associated with the CXL Host
+Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream
+ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`..
+
+::
+
+ "endpoints:port1":[
+ {
+ "endpoint":"endpoint5",
+ "host":"mem0",
+ "parent_dport":"0000:d2:01.1",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem0",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:d3:00.0"
+ },
+ "decoders:endpoint5":[
+ {
+ "decoder":"decoder5.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ }
+ ],
+
+This chunk shows the endpoints attached to the host bridge :code:`port1`.
+
+:code:`endpoint5` contains a single configured decoder :code:`decoder5.0`
+which has the same interleave configuration as :code:`region0` (shown later).
+
+Next we have the decodesr belonging to the host bridge:
+
+::
+
+ "decoders:port1":[
+ {
+ "decoder":"decoder1.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":1,
+ "region":"region0",
+ "nr_targets":1,
+ "targets":[
+ {
+ "target":"0000:d2:01.1",
+ "alias":"device:02",
+ "position":0,
+ "id":0
+ }
+ ]
+ }
+ ]
+ },
+
+Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose only
+target is :code:`dport1` - which is attached to :code:`endpoint5`.
+
+The following chunk shows a similar configuration for Host Bridge :code:`port3`,
+the second host bridge with a memory device attached.
+
+::
+
+ {
+ "port":"port3",
+ "host":"pci0000:a8",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:a8:01.1",
+ "alias":"device:c3",
+ "id":0
+ }
+ ],
+ "endpoints:port3":[
+ {
+ "endpoint":"endpoint6",
+ "host":"mem1",
+ "parent_dport":"0000:a8:01.1",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem1",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:a9:00.0"
+ },
+ "decoders:endpoint6":[
+ {
+ "decoder":"decoder6.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ }
+ ],
+ "decoders:port3":[
+ {
+ "decoder":"decoder3.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":1,
+ "region":"region0",
+ "nr_targets":1,
+ "targets":[
+ {
+ "target":"0000:a8:01.1",
+ "alias":"device:c3",
+ "position":0,
+ "id":0
+ }
+ ]
+ }
+ ]
+ },
+
+
+The next chunk shows the two CXL host bridges without attached endpoints.
+
+::
+
+ {
+ "port":"port2",
+ "host":"pci0000:00",
+ "depth":1,
+ "nr_dports":2,
+ "dports":[
+ {
+ "dport":"0000:00:01.3",
+ "alias":"device:55",
+ "id":2
+ },
+ {
+ "dport":"0000:00:07.1",
+ "alias":"device:5d",
+ "id":113
+ }
+ ]
+ },
+ {
+ "port":"port4",
+ "host":"pci0000:2a",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:2a:01.1",
+ "alias":"device:d0",
+ "id":0
+ }
+ ]
+ }
+ ],
+
+Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder
+applies the interleave across the downstream ports :code:`port1` and
+:code:`port3` - with a granularity of 256 bytes.
+
+This information is generated by the CXL driver reading the ACPI CEDT CMFWS.
+
+::
+
+ "decoders:root0":[
+ {
+ "decoder":"decoder0.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "max_available_extent":0,
+ "volatile_capable":true,
+ "nr_targets":2,
+ "targets":[
+ {
+ "target":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "position":1,
+ "id":4
+ },
+ {
+ "target":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "position":0,
+ "id":5
+ }
+ ],
+
+Finally we have the `Memory Region` associated with the `Root Decoder`
+:code:`decoder0.0`. This region describes the overall interleave configuration
+of the interleave set.
+
+::
+
+ "regions:decoder0.0":[
+ {
+ "region":"region0",
+ "resource":825975898112,
+ "size":274877906944,
+ "type":"ram",
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "decode_state":"commit",
+ "mappings":[
+ {
+ "position":1,
+ "memdev":"mem1",
+ "decoder":"decoder6.0"
+ },
+ {
+ "position":0,
+ "memdev":"mem0",
+ "decoder":"decoder5.0"
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
diff --git a/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst
new file mode 100644
index 000000000000..077dfaf8458d
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/example-configurations/intra-hb-interleave.rst
@@ -0,0 +1,291 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+Intra-Host-Bridge Interleave
+============================
+This cxl-cli configuration dump shows the following host configuration:
+
+* A single socket system with one CXL root
+* CXL Root has Four (4) CXL Host Bridges
+* One (1) CXL Host Bridges has two CXL Memory Expanders Attached
+* The Host bridge decoder is programmed to interleave across the expanders.
+
+This output is generated by :code:`cxl list -v` and describes the relationships
+between objects exposed in :code:`/sys/bus/cxl/devices/`.
+
+::
+
+ [
+ {
+ "bus":"root0",
+ "provider":"ACPI.CXL",
+ "nr_dports":4,
+ "dports":[
+ {
+ "dport":"pci0000:00",
+ "alias":"ACPI0016:01",
+ "id":0
+ },
+ {
+ "dport":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "id":4
+ },
+ {
+ "dport":"pci0000:2a",
+ "alias":"ACPI0016:03",
+ "id":1
+ },
+ {
+ "dport":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "id":5
+ }
+ ],
+
+This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL
+Host Bridges. The `Root` can be considered the singular upstream port attached
+to the platform's memory controller - which routes memory requests to it.
+
+The `ports:root0` section lays out how each of these downstream ports are
+configured. If a port is not configured (id's 0 and 1), they are omitted.
+
+::
+
+ "ports:root0":[
+ {
+ "port":"port1",
+ "host":"pci0000:d2",
+ "depth":1,
+ "nr_dports":3,
+ "dports":[
+ {
+ "dport":"0000:d2:01.1",
+ "alias":"device:02",
+ "id":0
+ },
+ {
+ "dport":"0000:d2:01.3",
+ "alias":"device:05",
+ "id":2
+ },
+ {
+ "dport":"0000:d2:07.1",
+ "alias":"device:0d",
+ "id":113
+ }
+ ],
+
+This chunk shows the available downstream ports associated with the CXL Host
+Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream
+ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`..
+
+::
+
+ "endpoints:port1":[
+ {
+ "endpoint":"endpoint5",
+ "host":"mem0",
+ "parent_dport":"0000:d2:01.1",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem0",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:d3:00.0"
+ },
+ "decoders:endpoint5":[
+ {
+ "decoder":"decoder5.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ },
+ {
+ "endpoint":"endpoint6",
+ "host":"mem1",
+ "parent_dport":"0000:d2:01.3,
+ "depth":2,
+ "memdev":{
+ "memdev":"mem1",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:a9:00.0"
+ },
+ "decoders:endpoint6":[
+ {
+ "decoder":"decoder6.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ }
+ ],
+
+This chunk shows the endpoints attached to the host bridge :code:`port1`.
+
+:code:`endpoint5` contains a single configured decoder :code:`decoder5.0`
+which has the same interleave configuration memory region they belong to
+(show later).
+
+Next we have the decoders belonging to the host bridge:
+
+::
+
+ "decoders:port1":[
+ {
+ "decoder":"decoder1.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "region":"region0",
+ "nr_targets":2,
+ "targets":[
+ {
+ "target":"0000:d2:01.1",
+ "alias":"device:02",
+ "position":0,
+ "id":0
+ },
+ {
+ "target":"0000:d2:01.3",
+ "alias":"device:05",
+ "position":1,
+ "id":0
+ }
+ ]
+ }
+ ]
+ },
+
+Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`) with two
+targets: :code:`dport1` and :code:`dport3` - which are attached to
+:code:`endpoint5` and :code:`endpoint6` respectively.
+
+The host bridge decoder interleaves these devices at a 256 byte granularity.
+
+The next chunk shows the three CXL host bridges without attached endpoints.
+
+::
+
+ {
+ "port":"port2",
+ "host":"pci0000:00",
+ "depth":1,
+ "nr_dports":2,
+ "dports":[
+ {
+ "dport":"0000:00:01.3",
+ "alias":"device:55",
+ "id":2
+ },
+ {
+ "dport":"0000:00:07.1",
+ "alias":"device:5d",
+ "id":113
+ }
+ ]
+ },
+ {
+ "port":"port3",
+ "host":"pci0000:a8",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:a8:01.1",
+ "alias":"device:c3",
+ "id":0
+ }
+ ],
+ },
+ {
+ "port":"port4",
+ "host":"pci0000:2a",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:2a:01.1",
+ "alias":"device:d0",
+ "id":0
+ }
+ ]
+ }
+ ],
+
+Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder
+applies the interleave across the downstream ports :code:`port1` and
+:code:`port3` - with a granularity of 256 bytes.
+
+This information is generated by the CXL driver reading the ACPI CEDT CMFWS.
+
+::
+
+ "decoders:root0":[
+ {
+ "decoder":"decoder0.0",
+ "resource":825975898112,
+ "size":274877906944,
+ "interleave_ways":1,
+ "max_available_extent":0,
+ "volatile_capable":true,
+ "nr_targets":2,
+ "targets":[
+ {
+ "target":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "position":1,
+ "id":4
+ },
+ ],
+
+Finally we have the `Memory Region` associated with the `Root Decoder`
+:code:`decoder0.0`. This region describes the overall interleave configuration
+of the interleave set.
+
+::
+
+ "regions:decoder0.0":[
+ {
+ "region":"region0",
+ "resource":825975898112,
+ "size":274877906944,
+ "type":"ram",
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "decode_state":"commit",
+ "mappings":[
+ {
+ "position":1,
+ "memdev":"mem1",
+ "decoder":"decoder6.0"
+ },
+ {
+ "position":0,
+ "memdev":"mem0",
+ "decoder":"decoder5.0"
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
diff --git a/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst b/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst
new file mode 100644
index 000000000000..008f9053c630
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/example-configurations/multi-interleave.rst
@@ -0,0 +1,401 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+Multi-Level Interleave
+======================
+This cxl-cli configuration dump shows the following host configuration:
+
+* A single socket system with one CXL root
+* CXL Root has Four (4) CXL Host Bridges
+* Two CXL Host Bridges have a two CXL Memory Expanders Attached each.
+* The CXL root is configured to interleave across the two host bridges.
+* Each host bridge with expanders interleaves across two endpoints.
+
+This output is generated by :code:`cxl list -v` and describes the relationships
+between objects exposed in :code:`/sys/bus/cxl/devices/`.
+
+::
+
+ [
+ {
+ "bus":"root0",
+ "provider":"ACPI.CXL",
+ "nr_dports":4,
+ "dports":[
+ {
+ "dport":"pci0000:00",
+ "alias":"ACPI0016:01",
+ "id":0
+ },
+ {
+ "dport":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "id":4
+ },
+ {
+ "dport":"pci0000:2a",
+ "alias":"ACPI0016:03",
+ "id":1
+ },
+ {
+ "dport":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "id":5
+ }
+ ],
+
+This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL
+Host Bridges. The `Root` can be considered the singular upstream port attached
+to the platform's memory controller - which routes memory requests to it.
+
+The `ports:root0` section lays out how each of these downstream ports are
+configured. If a port is not configured (id's 0 and 1), they are omitted.
+
+::
+
+ "ports:root0":[
+ {
+ "port":"port1",
+ "host":"pci0000:d2",
+ "depth":1,
+ "nr_dports":3,
+ "dports":[
+ {
+ "dport":"0000:d2:01.1",
+ "alias":"device:02",
+ "id":0
+ },
+ {
+ "dport":"0000:d2:01.3",
+ "alias":"device:05",
+ "id":2
+ },
+ {
+ "dport":"0000:d2:07.1",
+ "alias":"device:0d",
+ "id":113
+ }
+ ],
+
+This chunk shows the available downstream ports associated with the CXL Host
+Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream
+ports: :code:`dport0`, :code:`dport2`, and :code:`dport113`.
+
+::
+
+ "endpoints:port1":[
+ {
+ "endpoint":"endpoint5",
+ "host":"mem0",
+ "parent_dport":"0000:d2:01.1",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem0",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:d3:00.0"
+ },
+ "decoders:endpoint5":[
+ {
+ "decoder":"decoder5.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":4,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ },
+ {
+ "endpoint":"endpoint6",
+ "host":"mem1",
+ "parent_dport":"0000:d2:01.3",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem1",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:d3:00.0"
+ },
+ "decoders:endpoint6":[
+ {
+ "decoder":"decoder6.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":4,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ }
+ ],
+
+This chunk shows the endpoints attached to the host bridge :code:`port1`.
+
+:code:`endpoint5` contains a single configured decoder :code:`decoder5.0`
+which has the same interleave configuration as :code:`region0` (shown later).
+
+:code:`endpoint6` contains a single configured decoder :code:`decoder5.0`
+which has the same interleave configuration as :code:`region0` (shown later).
+
+Next we have the decoders belonging to the host bridge:
+
+::
+
+ "decoders:port1":[
+ {
+ "decoder":"decoder1.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":2,
+ "interleave_granularity":512,
+ "region":"region0",
+ "nr_targets":2,
+ "targets":[
+ {
+ "target":"0000:d2:01.1",
+ "alias":"device:02",
+ "position":0,
+ "id":0
+ },
+ {
+ "target":"0000:d2:01.3",
+ "alias":"device:05",
+ "position":2,
+ "id":0
+ }
+ ]
+ }
+ ]
+ },
+
+Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose
+targets are :code:`dport0` and :code:`dport2` - which are attached to
+:code:`endpoint5` and :code:`endpoint6` respectively.
+
+The following chunk shows a similar configuration for Host Bridge :code:`port3`,
+the second host bridge with a memory device attached.
+
+::
+
+ {
+ "port":"port3",
+ "host":"pci0000:a8",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:a8:01.1",
+ "alias":"device:c3",
+ "id":0
+ },
+ {
+ "dport":"0000:a8:01.3",
+ "alias":"device:c5",
+ "id":0
+ }
+ ],
+ "endpoints:port3":[
+ {
+ "endpoint":"endpoint7",
+ "host":"mem2",
+ "parent_dport":"0000:a8:01.1",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem2",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:a9:00.0"
+ },
+ "decoders:endpoint7":[
+ {
+ "decoder":"decoder7.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":4,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ },
+ {
+ "endpoint":"endpoint8",
+ "host":"mem3",
+ "parent_dport":"0000:a8:01.3",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem3",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:a9:00.0"
+ },
+ "decoders:endpoint8":[
+ {
+ "decoder":"decoder8.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":4,
+ "interleave_granularity":256,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ }
+ ],
+ "decoders:port3":[
+ {
+ "decoder":"decoder3.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":2,
+ "interleave_granularity":512,
+ "region":"region0",
+ "nr_targets":1,
+ "targets":[
+ {
+ "target":"0000:a8:01.1",
+ "alias":"device:c3",
+ "position":1,
+ "id":0
+ },
+ {
+ "target":"0000:a8:01.3",
+ "alias":"device:c5",
+ "position":3,
+ "id":0
+ }
+ ]
+ }
+ ]
+ },
+
+
+The next chunk shows the two CXL host bridges without attached endpoints.
+
+::
+
+ {
+ "port":"port2",
+ "host":"pci0000:00",
+ "depth":1,
+ "nr_dports":2,
+ "dports":[
+ {
+ "dport":"0000:00:01.3",
+ "alias":"device:55",
+ "id":2
+ },
+ {
+ "dport":"0000:00:07.1",
+ "alias":"device:5d",
+ "id":113
+ }
+ ]
+ },
+ {
+ "port":"port4",
+ "host":"pci0000:2a",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:2a:01.1",
+ "alias":"device:d0",
+ "id":0
+ }
+ ]
+ }
+ ],
+
+Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder
+applies the interleave across the downstream ports :code:`port1` and
+:code:`port3` - with a granularity of 256 bytes.
+
+This information is generated by the CXL driver reading the ACPI CEDT CMFWS.
+
+::
+
+ "decoders:root0":[
+ {
+ "decoder":"decoder0.0",
+ "resource":825975898112,
+ "size":549755813888,
+ "interleave_ways":2,
+ "interleave_granularity":256,
+ "max_available_extent":0,
+ "volatile_capable":true,
+ "nr_targets":2,
+ "targets":[
+ {
+ "target":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "position":1,
+ "id":4
+ },
+ {
+ "target":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "position":0,
+ "id":5
+ }
+ ],
+
+Finally we have the `Memory Region` associated with the `Root Decoder`
+:code:`decoder0.0`. This region describes the overall interleave configuration
+of the interleave set. So we see there are a total of :code:`4` interleave
+targets across 4 endpoint decoders.
+
+::
+
+ "regions:decoder0.0":[
+ {
+ "region":"region0",
+ "resource":825975898112,
+ "size":549755813888,
+ "type":"ram",
+ "interleave_ways":4,
+ "interleave_granularity":256,
+ "decode_state":"commit",
+ "mappings":[
+ {
+ "position":3,
+ "memdev":"mem3",
+ "decoder":"decoder8.0"
+ },
+ {
+ "position":2,
+ "memdev":"mem1",
+ "decoder":"decoder6.0"
+ }
+ {
+ "position":1,
+ "memdev":"mem2",
+ "decoder":"decoder7.0"
+ },
+ {
+ "position":0,
+ "memdev":"mem0",
+ "decoder":"decoder5.0"
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
diff --git a/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst b/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst
new file mode 100644
index 000000000000..5fd38eb0aaf4
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/example-configurations/single-device.rst
@@ -0,0 +1,246 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+Single Device
+=============
+This cxl-cli configuration dump shows the following host configuration:
+
+* A single socket system with one CXL root
+* CXL Root has Four (4) CXL Host Bridges
+* One CXL Host Bridges has a single CXL Memory Expander Attached
+* No interleave is present.
+
+This output is generated by :code:`cxl list -v` and describes the relationships
+between objects exposed in :code:`/sys/bus/cxl/devices/`.
+
+::
+
+ [
+ {
+ "bus":"root0",
+ "provider":"ACPI.CXL",
+ "nr_dports":4,
+ "dports":[
+ {
+ "dport":"pci0000:00",
+ "alias":"ACPI0016:01",
+ "id":0
+ },
+ {
+ "dport":"pci0000:a8",
+ "alias":"ACPI0016:02",
+ "id":4
+ },
+ {
+ "dport":"pci0000:2a",
+ "alias":"ACPI0016:03",
+ "id":1
+ },
+ {
+ "dport":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "id":5
+ }
+ ],
+
+This chunk shows the CXL "bus" (root0) has 4 downstream ports attached to CXL
+Host Bridges. The `Root` can be considered the singular upstream port attached
+to the platform's memory controller - which routes memory requests to it.
+
+The `ports:root0` section lays out how each of these downstream ports are
+configured. If a port is not configured (id's 0, 1, and 4), they are omitted.
+
+::
+
+ "ports:root0":[
+ {
+ "port":"port1",
+ "host":"pci0000:d2",
+ "depth":1,
+ "nr_dports":3,
+ "dports":[
+ {
+ "dport":"0000:d2:01.1",
+ "alias":"device:02",
+ "id":0
+ },
+ {
+ "dport":"0000:d2:01.3",
+ "alias":"device:05",
+ "id":2
+ },
+ {
+ "dport":"0000:d2:07.1",
+ "alias":"device:0d",
+ "id":113
+ }
+ ],
+
+This chunk shows the available downstream ports associated with the CXL Host
+Bridge :code:`port1`. In this case, :code:`port1` has 3 available downstream
+ports: :code:`dport1`, :code:`dport2`, and :code:`dport113`..
+
+::
+
+ "endpoints:port1":[
+ {
+ "endpoint":"endpoint5",
+ "host":"mem0",
+ "parent_dport":"0000:d2:01.1",
+ "depth":2,
+ "memdev":{
+ "memdev":"mem0",
+ "ram_size":137438953472,
+ "serial":0,
+ "numa_node":0,
+ "host":"0000:d3:00.0"
+ },
+ "decoders:endpoint5":[
+ {
+ "decoder":"decoder5.0",
+ "resource":825975898112,
+ "size":137438953472,
+ "interleave_ways":1,
+ "region":"region0",
+ "dpa_resource":0,
+ "dpa_size":137438953472,
+ "mode":"ram"
+ }
+ ]
+ }
+ ],
+
+This chunk shows the endpoints attached to the host bridge :code:`port1`.
+
+:code:`endpoint5` contains a single configured decoder :code:`decoder5.0`
+which has the same interleave configuration as :code:`region0` (shown later).
+
+Next we have the decoders belonging to the host bridge:
+
+::
+
+ "decoders:port1":[
+ {
+ "decoder":"decoder1.0",
+ "resource":825975898112,
+ "size":137438953472,
+ "interleave_ways":1,
+ "region":"region0",
+ "nr_targets":1,
+ "targets":[
+ {
+ "target":"0000:d2:01.1",
+ "alias":"device:02",
+ "position":0,
+ "id":0
+ }
+ ]
+ }
+ ]
+ },
+
+Host Bridge :code:`port1` has a single decoder (:code:`decoder1.0`), whose only
+target is :code:`dport1` - which is attached to :code:`endpoint5`.
+
+The next chunk shows the three CXL host bridges without attached endpoints.
+
+::
+
+ {
+ "port":"port2",
+ "host":"pci0000:00",
+ "depth":1,
+ "nr_dports":2,
+ "dports":[
+ {
+ "dport":"0000:00:01.3",
+ "alias":"device:55",
+ "id":2
+ },
+ {
+ "dport":"0000:00:07.1",
+ "alias":"device:5d",
+ "id":113
+ }
+ ]
+ },
+ {
+ "port":"port3",
+ "host":"pci0000:a8",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:a8:01.1",
+ "alias":"device:c3",
+ "id":0
+ }
+ ]
+ },
+ {
+ "port":"port4",
+ "host":"pci0000:2a",
+ "depth":1,
+ "nr_dports":1,
+ "dports":[
+ {
+ "dport":"0000:2a:01.1",
+ "alias":"device:d0",
+ "id":0
+ }
+ ]
+ }
+ ],
+
+Next we have the `Root Decoders` belonging to :code:`root0`. This root decoder
+is a pass-through decoder because :code:`interleave_ways` is set to :code:`1`.
+
+This information is generated by the CXL driver reading the ACPI CEDT CMFWS.
+
+::
+
+ "decoders:root0":[
+ {
+ "decoder":"decoder0.0",
+ "resource":825975898112,
+ "size":137438953472,
+ "interleave_ways":1,
+ "max_available_extent":0,
+ "volatile_capable":true,
+ "nr_targets":1,
+ "targets":[
+ {
+ "target":"pci0000:d2",
+ "alias":"ACPI0016:00",
+ "position":0,
+ "id":5
+ }
+ ],
+
+Finally we have the `Memory Region` associated with the `Root Decoder`
+:code:`decoder0.0`. This region describes the discrete region associated
+with the lone device.
+
+::
+
+ "regions:decoder0.0":[
+ {
+ "region":"region0",
+ "resource":825975898112,
+ "size":137438953472,
+ "type":"ram",
+ "interleave_ways":1,
+ "decode_state":"commit",
+ "mappings":[
+ {
+ "position":0,
+ "memdev":"mem0",
+ "decoder":"decoder5.0"
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
diff --git a/Documentation/driver-api/cxl/linux/memory-hotplug.rst b/Documentation/driver-api/cxl/linux/memory-hotplug.rst
new file mode 100644
index 000000000000..af368c2bc9cf
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/memory-hotplug.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+Memory Hotplug
+==============
+The final phase of surfacing CXL memory to the kernel page allocator is for
+the `DAX` driver to surface a `Driver Managed` memory region via the
+memory-hotplug component.
+
+There are four major configurations to consider:
+
+1) Default Online Behavior (on/off and zone)
+2) Hotplug Memory Block size
+3) Memory Map Resource location
+4) Driver-Managed Memory Designation
+
+Default Online Behavior
+=======================
+The default-online behavior of hotplug memory is dictated by the following,
+in order of precedence:
+
+- :code:`CONFIG_MHP_DEFAULT_ONLINE_TYPE` Build Configuration
+- :code:`memhp_default_state` Boot parameter
+- :code:`/sys/devices/system/memory/auto_online_blocks` value
+
+These dictate whether hotplugged memory blocks arrive in one of three states:
+
+1) Offline
+2) Online in :code:`ZONE_NORMAL`
+3) Online in :code:`ZONE_MOVABLE`
+
+:code:`ZONE_NORMAL` implies this capacity may be used for almost any allocation,
+while :code:`ZONE_MOVABLE` implies this capacity should only be used for
+migratable allocations.
+
+:code:`ZONE_MOVABLE` attempts to retain the hotplug-ability of a memory block
+so that it the entire region may be hot-unplugged at a later time. Any capacity
+onlined into :code:`ZONE_NORMAL` should be considered permanently attached to
+the page allocator.
+
+Hotplug Memory Block Size
+=========================
+By default, on most architectures, the Hotplug Memory Block Size is either
+128MB or 256MB. On x86, the block size increases up to 2GB as total memory
+capacity exceeds 64GB. As of v6.15, Linux does not take into account the
+size and alignment of the ACPI CEDT CFMWS regions (see Early Boot docs) when
+deciding the Hotplug Memory Block Size.
+
+Memory Map
+==========
+The location of :code:`struct folio` allocations to represent the hotplugged
+memory capacity are dictated by the following system settings:
+
+- :code:`/sys_module/memory_hotplug/parameters/memmap_on_memory`
+- :code:`/sys/bus/dax/devices/daxN.Y/memmap_on_memory`
+
+If both of these parameters are set to true, :code:`struct folio` for this
+capacity will be carved out of the memory block being onlined. This has
+performance implications if the memory is particularly high-latency and
+its :code:`struct folio` becomes hotly contended.
+
+If either parameter is set to false, :code:`struct folio` for this capacity
+will be allocated from the local node of the processor running the hotplug
+procedure. This capacity will be allocated from :code:`ZONE_NORMAL` on
+that node, as it is a :code:`GFP_KERNEL` allocation.
+
+Systems with extremely large amounts of :code:`ZONE_MOVABLE` memory (e.g.
+CXL memory pools) must ensure that there is sufficient local
+:code:`ZONE_NORMAL` capacity to host the memory map for the hotplugged capacity.
+
+Driver Managed Memory
+=====================
+The DAX driver surfaces this memory to memory-hotplug as "Driver Managed". This
+is not a configurable setting, but it's important to note that driver managed
+memory is explicitly excluded from use during kexec. This is required to ensure
+any reset or out-of-band operations that the CXL device may be subject to during
+a functional system-reboot (such as a reset-on-probe) will not cause portions of
+the kexec kernel to be overwritten.
diff --git a/Documentation/driver-api/cxl/linux/overview.rst b/Documentation/driver-api/cxl/linux/overview.rst
new file mode 100644
index 000000000000..648beb2c8c83
--- /dev/null
+++ b/Documentation/driver-api/cxl/linux/overview.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========
+Overview
+========
+
+This section presents the configuration process of a CXL Type-3 memory device,
+and how it is ultimately exposed to users as either a :code:`DAX` device or
+normal memory pages via the kernel's page allocator.
+
+Portions marked with a bullet are points at which certain kernel objects
+are generated.
+
+1) Early Boot
+
+ a) BIOS, Build, and Boot Parameters
+
+ i) EFI_MEMORY_SP
+ ii) CONFIG_EFI_SOFT_RESERVE
+ iii) CONFIG_MHP_DEFAULT_ONLINE_TYPE
+ iv) nosoftreserve
+
+ b) Memory Map Creation
+
+ i) EFI Memory Map / E820 Consulted for Soft-Reserved
+
+ * CXL Memory is set aside to be handled by the CXL driver
+
+ * Soft-Reserved IO Resource created for CFMWS entry
+
+ c) NUMA Node Creation
+
+ * Nodes created from ACPI CEDT CFMWS and SRAT Proximity domains (PXM)
+
+ d) Memory Tier Creation
+
+ * A default memory_tier is created with all nodes.
+
+ e) Contiguous Memory Allocation
+
+ * Any requested CMA is allocated from Online nodes
+
+ f) Init Finishes, Drivers start probing
+
+2) ACPI and PCI Drivers
+
+ a) Detects PCI device is CXL, marking it for probe by CXL driver
+
+3) CXL Driver Operation
+
+ a) Base device creation
+
+ * root, port, and memdev devices created
+ * CEDT CFMWS IO Resource creation
+
+ b) Decoder creation
+
+ * root, switch, and endpoint decoders created
+
+ c) Logical device creation
+
+ * memory_region and endpoint devices created
+
+ d) Devices are associated with each other
+
+ * If auto-decoder (BIOS-programmed decoders), driver validates
+ configurations, builds associations, and locks configs at probe time.
+
+ * If user-configured, validation and associations are built at
+ decoder-commit time.
+
+ e) Regions surfaced as DAX region
+
+ * dax_region created
+
+ * DAX device created via DAX driver
+
+4) DAX Driver Operation
+
+ a) DAX driver surfaces DAX region as one of two dax device modes
+
+ * kmem - dax device is converted to hotplug memory blocks
+
+ * DAX kmem IO Resource creation
+
+ * hmem - dax device is left as daxdev to be accessed as a file.
+
+ * If hmem, journey ends here.
+
+ b) DAX kmem surfaces memory region to Memory Hotplug to add to page
+ allocator as "driver managed memory"
+
+5) Memory Hotplug
+
+ a) mhp component surfaces a dax device memory region as multiple memory
+ blocks to the page allocator
+
+ * blocks appear in :code:`/sys/bus/memory/devices` and linked to a NUMA node
+
+ b) blocks are onlined into the requested zone (NORMAL or MOVABLE)
+
+ * Memory is marked "Driver Managed" to avoid kexec from using it as region
+ for kernel updates
diff --git a/Documentation/driver-api/cxl/maturity-map.rst b/Documentation/driver-api/cxl/maturity-map.rst
new file mode 100644
index 000000000000..282c1102dd81
--- /dev/null
+++ b/Documentation/driver-api/cxl/maturity-map.rst
@@ -0,0 +1,202 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===========================================
+Compute Express Link Subsystem Maturity Map
+===========================================
+
+The Linux CXL subsystem tracks the dynamic `CXL specification
+<https://computeexpresslink.org/cxl-specification-landing-page>`_ that
+continues to respond to new use cases with new features, capability
+updates and fixes. At any given point some aspects of the subsystem are
+more mature than others. While the periodic pull requests summarize the
+`work being incorporated each merge window
+<https://lore.kernel.org/linux-cxl/?q=s%3APULL+s%3ACXL+tc%3Atorvalds+NOT+s%3ARe>`_,
+those do not always convey progress relative to a starting point and a
+future end goal.
+
+What follows is a coarse breakdown of the subsystem's major
+responsibilities along with a maturity score. The expectation is that
+the change-history of this document provides an overview summary of the
+subsystem maturation over time.
+
+The maturity scores are:
+
+- [3] Mature: Work in this area is complete and no changes on the horizon.
+ Note that this score can regress from one kernel release to the next
+ based on new test results or end user reports.
+
+- [2] Stabilizing: Major functionality operational, common cases are
+ mature, but known corner cases are still a work in progress.
+
+- [1] Initial: Capability that has exited the Proof of Concept phase, but
+ may still have significant gaps to close and fixes to apply as real
+ world testing occurs.
+
+- [0] Known gap: Feature is on a medium to long term horizon to
+ implement. If the specification has a feature that does not even have
+ a '0' score in this document, there is a good chance that no one in
+ the linux-cxl@vger.kernel.org community has started to look at it.
+
+- X: Out of scope for kernel enabling, or kernel enabling not required
+
+Feature and Capabilities
+========================
+
+Enumeration / Provisioning
+--------------------------
+All of the fundamental enumeration an object model of the subsystem is
+in place, but there are several corner cases that are pending closure.
+
+
+* [2] CXL Window Enumeration
+
+ * [2] :ref:`Extended-linear memory-side cache <extended-linear>`
+ * [0] Low Memory-hole
+ * [X] Hetero-interleave
+
+* [2] Switch Enumeration
+
+ * [0] CXL register enumeration link-up dependency
+
+* [2] HDM Decoder Configuration
+
+ * [0] Decoder target and granularity constraints
+
+* [2] Performance enumeration
+
+ * [3] Endpoint CDAT
+ * [3] Switch CDAT
+ * [1] CDAT to Core-mm integration
+
+ * [1] x86
+ * [0] Arm64
+ * [0] All other arch.
+
+ * [0] Shared link
+
+* [2] Hotplug
+ (see CXL Window Enumeration)
+
+ * [0] Handle Soft Reserved conflicts
+
+* [0] :ref:`RCH link status <rch-link-status>`
+* [0] Fabrics / G-FAM (chapter 7)
+* [0] Global Access Endpoint
+
+
+RAS
+---
+In many ways CXL can be seen as a standardization of what would normally
+be handled by custom EDAC drivers. The open development here is
+mainly caused by the enumeration corner cases above.
+
+* [3] Component events (OS)
+* [2] Component events (FFM)
+* [1] Endpoint protocol errors (OS)
+* [1] Endpoint protocol errors (FFM)
+* [0] Switch protocol errors (OS)
+* [1] Switch protocol errors (FFM)
+* [2] DPA->HPA Address translation
+
+ * [1] XOR Interleave translation
+ (see CXL Window Enumeration)
+
+* [1] Memory Failure coordination
+* [0] Scrub control
+* [2] ACPI error injection EINJ
+
+ * [0] EINJ v2
+ * [X] Compliance DOE
+
+* [2] Native error injection
+* [3] RCH error handling
+* [1] VH error handling
+* [0] PPR
+* [0] Sparing
+* [0] Device built in test
+
+
+Mailbox commands
+----------------
+
+* [3] Firmware update
+* [3] Health / Alerts
+* [1] :ref:`Background commands <background-commands>`
+* [3] Sanitization
+* [3] Security commands
+* [3] RAW Command Debug Passthrough
+* [0] CEL-only-validation Passthrough
+* [0] Switch CCI
+* [3] Timestamp
+* [1] PMEM labels
+* [3] PMEM GPF / Dirty Shutdown
+* [0] Scan Media
+
+PMU
+---
+* [1] Type 3 PMU
+* [0] Switch USP/ DSP, Root Port
+
+Security
+--------
+
+* [X] CXL Trusted Execution Environment Security Protocol (TSP)
+* [X] CXL IDE (subsumed by TSP)
+
+Memory-pooling
+--------------
+
+* [1] Hotplug of LDs (via PCI hotplug)
+* [0] Dynamic Capacity Device (DCD) Support
+
+Multi-host sharing
+------------------
+
+* [0] Hardware coherent shared memory
+* [0] Software managed coherency shared memory
+
+Multi-host memory
+-----------------
+
+* [0] Dynamic Capacity Device Support
+* [0] Sharing
+
+Accelerator
+-----------
+
+* [0] Accelerator memory enumeration HDM-D (CXL 1.1/2.0 Type-2)
+* [0] Accelerator memory enumeration HDM-DB (CXL 3.0 Type-2)
+* [0] CXL.cache 68b (CXL 2.0)
+* [0] CXL.cache 256b Cache IDs (CXL 3.0)
+
+User Flow Support
+-----------------
+
+* [2] Inject & clear poison by region offset
+
+Details
+=======
+
+.. _extended-linear:
+
+* **Extended-linear memory-side cache**: An HMAT proposal to enumerate the presence of a
+ memory-side cache where the cache capacity extends the SRAT address
+ range capacity. `See the ECN
+ <https://lore.kernel.org/linux-cxl/6650e4f835a0e_195e294a8@dwillia2-mobl3.amr.corp.intel.com.notmuch/>`_
+ for more details:
+
+.. _rch-link-status:
+
+* **RCH Link Status**: RCH (Restricted CXL Host) topologies, end up
+ hiding some standard registers like PCIe Link Status / Capabilities in
+ the CXL RCRB (Root Complex Register Block).
+
+.. _background-commands:
+
+* **Background commands**: The CXL background command mechanism is
+ awkward as the single slot is monopolized potentially indefinitely by
+ various commands. A `cancel on conflict
+ <http://lore.kernel.org/r/66035c2e8ba17_770232948b@dwillia2-xfh.jf.intel.com.notmuch>`_
+ facility is needed to make sure the kernel can ensure forward progress
+ of priority commands.
diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst
deleted file mode 100644
index 5149ecdc53c7..000000000000
--- a/Documentation/driver-api/cxl/memory-devices.rst
+++ /dev/null
@@ -1,383 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-.. include:: <isonum.txt>
-
-===================================
-Compute Express Link Memory Devices
-===================================
-
-A Compute Express Link Memory Device is a CXL component that implements the
-CXL.mem protocol. It contains some amount of volatile memory, persistent memory,
-or both. It is enumerated as a PCI device for configuration and passing
-messages over an MMIO mailbox. Its contribution to the System Physical
-Address space is handled via HDM (Host Managed Device Memory) decoders
-that optionally define a device's contribution to an interleaved address
-range across multiple devices underneath a host-bridge or interleaved
-across host-bridges.
-
-CXL Bus: Theory of Operation
-============================
-Similar to how a RAID driver takes disk objects and assembles them into a new
-logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and
-assemble them into a CXL.mem decode topology. The need for runtime configuration
-of the CXL.mem topology is also similar to RAID in that different environments
-with the same hardware configuration may decide to assemble the topology in
-contrasting ways. One may choose performance (RAID0) striping memory across
-multiple Host Bridges and endpoints while another may opt for fault tolerance
-and disable any striping in the CXL.mem topology.
-
-Platform firmware enumerates a menu of interleave options at the "CXL root port"
-(Linux term for the top of the CXL decode topology). From there, PCIe topology
-dictates which endpoints can participate in which Host Bridge decode regimes.
-Each PCIe Switch in the path between the root and an endpoint introduces a point
-at which the interleave can be split. For example platform firmware may say at a
-given range only decodes to 1 one Host Bridge, but that Host Bridge may in turn
-interleave cycles across multiple Root Ports. An intervening Switch between a
-port and an endpoint may interleave cycles across multiple Downstream Switch
-Ports, etc.
-
-Here is a sample listing of a CXL topology defined by 'cxl_test'. The 'cxl_test'
-module generates an emulated CXL topology of 2 Host Bridges each with 2 Root
-Ports. Each of those Root Ports are connected to 2-way switches with endpoints
-connected to those downstream ports for a total of 8 endpoints::
-
- # cxl list -BEMPu -b cxl_test
- {
- "bus":"root3",
- "provider":"cxl_test",
- "ports:root3":[
- {
- "port":"port5",
- "host":"cxl_host_bridge.1",
- "ports:port5":[
- {
- "port":"port8",
- "host":"cxl_switch_uport.1",
- "endpoints:port8":[
- {
- "endpoint":"endpoint9",
- "host":"mem2",
- "memdev":{
- "memdev":"mem2",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x1",
- "numa_node":1,
- "host":"cxl_mem.1"
- }
- },
- {
- "endpoint":"endpoint15",
- "host":"mem6",
- "memdev":{
- "memdev":"mem6",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x5",
- "numa_node":1,
- "host":"cxl_mem.5"
- }
- }
- ]
- },
- {
- "port":"port12",
- "host":"cxl_switch_uport.3",
- "endpoints:port12":[
- {
- "endpoint":"endpoint17",
- "host":"mem8",
- "memdev":{
- "memdev":"mem8",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x7",
- "numa_node":1,
- "host":"cxl_mem.7"
- }
- },
- {
- "endpoint":"endpoint13",
- "host":"mem4",
- "memdev":{
- "memdev":"mem4",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x3",
- "numa_node":1,
- "host":"cxl_mem.3"
- }
- }
- ]
- }
- ]
- },
- {
- "port":"port4",
- "host":"cxl_host_bridge.0",
- "ports:port4":[
- {
- "port":"port6",
- "host":"cxl_switch_uport.0",
- "endpoints:port6":[
- {
- "endpoint":"endpoint7",
- "host":"mem1",
- "memdev":{
- "memdev":"mem1",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0",
- "numa_node":0,
- "host":"cxl_mem.0"
- }
- },
- {
- "endpoint":"endpoint14",
- "host":"mem5",
- "memdev":{
- "memdev":"mem5",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x4",
- "numa_node":0,
- "host":"cxl_mem.4"
- }
- }
- ]
- },
- {
- "port":"port10",
- "host":"cxl_switch_uport.2",
- "endpoints:port10":[
- {
- "endpoint":"endpoint16",
- "host":"mem7",
- "memdev":{
- "memdev":"mem7",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x6",
- "numa_node":0,
- "host":"cxl_mem.6"
- }
- },
- {
- "endpoint":"endpoint11",
- "host":"mem3",
- "memdev":{
- "memdev":"mem3",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x2",
- "numa_node":0,
- "host":"cxl_mem.2"
- }
- }
- ]
- }
- ]
- }
- ]
- }
-
-In that listing each "root", "port", and "endpoint" object correspond a kernel
-'struct cxl_port' object. A 'cxl_port' is a device that can decode CXL.mem to
-its descendants. So "root" claims non-PCIe enumerable platform decode ranges and
-decodes them to "ports", "ports" decode to "endpoints", and "endpoints"
-represent the decode from SPA (System Physical Address) to DPA (Device Physical
-Address).
-
-Continuing the RAID analogy, disks have both topology metadata and on device
-metadata that determine RAID set assembly. CXL Port topology and CXL Port link
-status is metadata for CXL.mem set assembly. The CXL Port topology is enumerated
-by the arrival of a CXL.mem device. I.e. unless and until the PCIe core attaches
-the cxl_pci driver to a CXL Memory Expander there is no role for CXL Port
-objects. Conversely for hot-unplug / removal scenarios, there is no need for
-the Linux PCI core to tear down switch-level CXL resources because the endpoint
-->remove() event cleans up the port data that was established to support that
-Memory Expander.
-
-The port metadata and potential decode schemes that a give memory device may
-participate can be determined via a command like::
-
- # cxl list -BDMu -d root -m mem3
- {
- "bus":"root3",
- "provider":"cxl_test",
- "decoders:root3":[
- {
- "decoder":"decoder3.1",
- "resource":"0x8030000000",
- "size":"512.00 MiB (536.87 MB)",
- "volatile_capable":true,
- "nr_targets":2
- },
- {
- "decoder":"decoder3.3",
- "resource":"0x8060000000",
- "size":"512.00 MiB (536.87 MB)",
- "pmem_capable":true,
- "nr_targets":2
- },
- {
- "decoder":"decoder3.0",
- "resource":"0x8020000000",
- "size":"256.00 MiB (268.44 MB)",
- "volatile_capable":true,
- "nr_targets":1
- },
- {
- "decoder":"decoder3.2",
- "resource":"0x8050000000",
- "size":"256.00 MiB (268.44 MB)",
- "pmem_capable":true,
- "nr_targets":1
- }
- ],
- "memdevs:root3":[
- {
- "memdev":"mem3",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x2",
- "numa_node":0,
- "host":"cxl_mem.2"
- }
- ]
- }
-
-...which queries the CXL topology to ask "given CXL Memory Expander with a kernel
-device name of 'mem3' which platform level decode ranges may this device
-participate". A given expander can participate in multiple CXL.mem interleave
-sets simultaneously depending on how many decoder resource it has. In this
-example mem3 can participate in one or more of a PMEM interleave that spans to
-Host Bridges, a PMEM interleave that targets a single Host Bridge, a Volatile
-memory interleave that spans 2 Host Bridges, and a Volatile memory interleave
-that only targets a single Host Bridge.
-
-Conversely the memory devices that can participate in a given platform level
-decode scheme can be determined via a command like the following::
-
- # cxl list -MDu -d 3.2
- [
- {
- "memdevs":[
- {
- "memdev":"mem1",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0",
- "numa_node":0,
- "host":"cxl_mem.0"
- },
- {
- "memdev":"mem5",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x4",
- "numa_node":0,
- "host":"cxl_mem.4"
- },
- {
- "memdev":"mem7",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x6",
- "numa_node":0,
- "host":"cxl_mem.6"
- },
- {
- "memdev":"mem3",
- "pmem_size":"256.00 MiB (268.44 MB)",
- "ram_size":"256.00 MiB (268.44 MB)",
- "serial":"0x2",
- "numa_node":0,
- "host":"cxl_mem.2"
- }
- ]
- },
- {
- "root decoders":[
- {
- "decoder":"decoder3.2",
- "resource":"0x8050000000",
- "size":"256.00 MiB (268.44 MB)",
- "pmem_capable":true,
- "nr_targets":1
- }
- ]
- }
- ]
-
-...where the naming scheme for decoders is "decoder<port_id>.<instance_id>".
-
-Driver Infrastructure
-=====================
-
-This section covers the driver infrastructure for a CXL memory device.
-
-CXL Memory Device
------------------
-
-.. kernel-doc:: drivers/cxl/pci.c
- :doc: cxl pci
-
-.. kernel-doc:: drivers/cxl/pci.c
- :internal:
-
-.. kernel-doc:: drivers/cxl/mem.c
- :doc: cxl mem
-
-CXL Port
---------
-.. kernel-doc:: drivers/cxl/port.c
- :doc: cxl port
-
-CXL Core
---------
-.. kernel-doc:: drivers/cxl/cxl.h
- :doc: cxl objects
-
-.. kernel-doc:: drivers/cxl/cxl.h
- :internal:
-
-.. kernel-doc:: drivers/cxl/core/port.c
- :doc: cxl core
-
-.. kernel-doc:: drivers/cxl/core/port.c
- :identifiers:
-
-.. kernel-doc:: drivers/cxl/core/pci.c
- :doc: cxl core pci
-
-.. kernel-doc:: drivers/cxl/core/pci.c
- :identifiers:
-
-.. kernel-doc:: drivers/cxl/core/pmem.c
- :doc: cxl pmem
-
-.. kernel-doc:: drivers/cxl/core/regs.c
- :doc: cxl registers
-
-.. kernel-doc:: drivers/cxl/core/mbox.c
- :doc: cxl mbox
-
-CXL Regions
------------
-.. kernel-doc:: drivers/cxl/core/region.c
- :doc: cxl core region
-
-.. kernel-doc:: drivers/cxl/core/region.c
- :identifiers:
-
-External Interfaces
-===================
-
-CXL IOCTL Interface
--------------------
-
-.. kernel-doc:: include/uapi/linux/cxl_mem.h
- :doc: UAPI
-
-.. kernel-doc:: include/uapi/linux/cxl_mem.h
- :internal:
diff --git a/Documentation/driver-api/cxl/platform/acpi.rst b/Documentation/driver-api/cxl/platform/acpi.rst
new file mode 100644
index 000000000000..ee7e6bd4c43d
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/acpi.rst
@@ -0,0 +1,76 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========
+ACPI Tables
+===========
+
+ACPI is the "Advanced Configuration and Power Interface", which is a standard
+that defines how platforms and OS manage power and configure computer hardware.
+For the purpose of this theory of operation, when referring to "ACPI" we will
+usually refer to "ACPI Tables" - which are the way a platform (BIOS/EFI)
+communicates static configuration information to the operation system.
+
+The Following ACPI tables contain *static* configuration and performance data
+about CXL devices.
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi/cedt.rst
+ acpi/srat.rst
+ acpi/hmat.rst
+ acpi/slit.rst
+ acpi/dsdt.rst
+
+The SRAT table may also contain generic port/initiator content that is intended
+to describe the generic port, but not information about the rest of the path to
+the endpoint.
+
+Linux uses these tables to configure kernel resources for statically configured
+(by BIOS/EFI) CXL devices, such as:
+
+- NUMA nodes
+- Memory Tiers
+- NUMA Abstract Distances
+- SystemRAM Memory Regions
+- Weighted Interleave Node Weights
+
+ACPI Debugging
+==============
+
+The :code:`acpidump -b` command dumps the ACPI tables into binary format.
+
+The :code:`iasl -d` command disassembles the files into human readable format.
+
+Example :code:`acpidump -b && iasl -d cedt.dat` ::
+
+ [000h 0000 4] Signature : "CEDT" [CXL Early Discovery Table]
+
+Common Issues
+-------------
+Most failures described here result in a failure of the driver to surface
+memory as a DAX device and/or kmem.
+
+* CEDT CFMWS targets list UIDs do not match CEDT CHBS UIDs.
+* CEDT CFMWS targets list UIDs do not match DSDT CXL Host Bridge UIDs.
+* CEDT CFMWS Restriction Bits are not correct.
+* CEDT CFMWS Memory regions are poorly aligned.
+* CEDT CFMWS Memory regions spans a platform memory hole.
+* CEDT CHBS UIDs do not match DSDT CXL Host Bridge UIDs.
+* CEDT CHBS Specification version is incorrect.
+* SRAT is missing regions described in CEDT CFMWS.
+
+ * Result: failure to create a NUMA node for the region, or
+ region is placed in wrong node.
+
+* HMAT is missing data for regions described in CEDT CFMWS.
+
+ * Result: NUMA node being placed in the wrong memory tier.
+
+* SLIT has bad data.
+
+ * Result: Lots of performance mechanisms in the kernel will be very unhappy.
+
+All of these issues will appear to users as if the driver is failing to
+support CXL - when in reality they are all the failure of a platform to
+configure the ACPI tables correctly.
diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
new file mode 100644
index 000000000000..1d9c9d3592dc
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================================
+CEDT - CXL Early Discovery Table
+================================
+
+The CXL Early Discovery Table is generated by BIOS to describe the CXL memory
+regions configured at boot by the BIOS.
+
+CHBS
+====
+The CXL Host Bridge Structure describes CXL host bridges. Other than describing
+device register information, it reports the specific host bridge UID for this
+host bridge. These host bridge ID's will be referenced in other tables.
+
+Example ::
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000007 <- Host bridge _UID
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010370400000
+ Register length : 0000000000010000
+
+CFMWS
+=====
+The CXL Fixed Memory Window structure describes a memory region associated
+with one or more CXL host bridges (as described by the CHBS). It additionally
+describes any inter-host-bridge interleave configuration that may have been
+programmed by BIOS.
+
+Example ::
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 000000C050000000 <- Memory Region
+ Window size : 0000003CA0000000
+ Interleave Members (2^n) : 01 <- Interleave configuration
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007 <- Host Bridge _UID
+ Next Target : 00000006 <- Host Bridge _UID
+
+The restriction field dictates what this SPA range may be used for (memory type,
+voltile vs persistent, etc). One or more bits may be set. ::
+
+ Bit[0]: CXL Type 2 Memory
+ Bit[1]: CXL Type 3 Memory
+ Bit[2]: Volatile Memory
+ Bit[3]: Persistent Memory
+ Bit[4]: Fixed Config (HPA cannot be re-used)
+
+INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT
+reported in this structure, and is solely defined via CXL device decoder
+programming (host bridge and endpoint decoders).
diff --git a/Documentation/driver-api/cxl/platform/acpi/dsdt.rst b/Documentation/driver-api/cxl/platform/acpi/dsdt.rst
new file mode 100644
index 000000000000..b4583b01d67d
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/acpi/dsdt.rst
@@ -0,0 +1,28 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================================
+DSDT - Differentiated system Description Table
+==============================================
+
+This table describes what peripherals a machine has.
+
+This table's UIDs for CXL devices - specifically host bridges, must be
+consistent with the contents of the CEDT, otherwise the CXL driver will
+fail to probe correctly.
+
+Example Compute Express Link Host Bridge ::
+
+ Scope (_SB)
+ {
+ Device (S0D0)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ Name (_CID, Package (0x02) // _CID: Compatible ID
+ {
+ EisaId ("PNP0A08") /* PCI Express Bus */,
+ EisaId ("PNP0A03") /* PCI Bus */
+ })
+ ...
+ Name (_UID, 0x05) // _UID: Unique ID
+ ...
+ }
diff --git a/Documentation/driver-api/cxl/platform/acpi/hmat.rst b/Documentation/driver-api/cxl/platform/acpi/hmat.rst
new file mode 100644
index 000000000000..095a26f02a37
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/acpi/hmat.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================================
+HMAT - Heterogeneous Memory Attribute Table
+===========================================
+
+The Heterogeneous Memory Attributes Table contains information such as cache
+attributes and bandwidth and latency details for memory proximity domains.
+For the purpose of this document, we will only discuss the SSLIB entry.
+
+SLLBI
+=====
+The System Locality Latency and Bandwidth Information records latency and
+bandwidth information for proximity domains.
+
+This table is used by Linux to configure interleave weights and memory tiers.
+
+Example (Heavily truncated for brevity) ::
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 00 <- Latency
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Entry : 0080 <- DRAM LTC
+ Entry : 0100 <- CXL LTC
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 03 <- Bandwidth
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Entry : 1200 <- DRAM BW
+ Entry : 0200 <- CXL BW
diff --git a/Documentation/driver-api/cxl/platform/acpi/slit.rst b/Documentation/driver-api/cxl/platform/acpi/slit.rst
new file mode 100644
index 000000000000..a56768e8fe41
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/acpi/slit.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+SLIT - System Locality Information Table
+========================================
+
+The system locality information table provides "abstract distances" between
+accessor and memory nodes. Node without initiators (cpus) are infinitely (FF)
+distance away from all other nodes.
+
+The abstract distance described in this table does not describe any real
+latency of bandwidth information.
+
+Example ::
+
+ Signature : "SLIT" [System Locality Information Table]
+ Localities : 0000000000000004
+ Locality 0 : 10 20 20 30
+ Locality 1 : 20 10 30 20
+ Locality 2 : FF FF 0A FF
+ Locality 3 : FF FF FF 0A
diff --git a/Documentation/driver-api/cxl/platform/acpi/srat.rst b/Documentation/driver-api/cxl/platform/acpi/srat.rst
new file mode 100644
index 000000000000..cc98ca0e508e
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/acpi/srat.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+SRAT - Static Resource Affinity Table
+=====================================
+
+The System/Static Resource Affinity Table describes resource (CPU, Memory)
+affinity to "Proximity Domains". This table is technically optional, but for
+performance information (see "HMAT") to be enumerated by linux it must be
+present.
+
+There is a careful dance between the CEDT and SRAT tables and how NUMA nodes are
+created. If things don't look quite the way you expect - check the SRAT Memory
+Affinity entries and CEDT CFMWS to determine what your platform actually
+supports in terms of flexible topologies.
+
+The SRAT may statically assign portions of a CFMWS SPA range to a specific
+proximity domains. See linux numa creation for more information about how
+this presents in the NUMA topology.
+
+Proximity Domain
+================
+A proximity domain is ROUGHLY equivalent to "NUMA Node" - though a 1-to-1
+mapping is not guaranteed. There are scenarios where "Proximity Domain 4" may
+map to "NUMA Node 3", for example. (See "NUMA Node Creation")
+
+Memory Affinity
+===============
+Generally speaking, if a host does any amount of CXL fabric (decoder)
+programming in BIOS - an SRAT entry for that memory needs to be present.
+
+Example ::
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000001 <- NUMA Node 1
+ Reserved1 : 0000
+ Base Address : 000000C050000000 <- Physical Memory Region
+ Address Length : 0000003CA0000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+
+Generic Port Affinity
+=====================
+The Generic Port Affinity subtable provides an association between a proximity
+domain and a device handle representing a Generic Port such as a CXL host
+bridge. With the association, latency and bandwidth numbers can be retrieved
+from the SRAT for the path between CPU(s) (initiator) and the Generic Port.
+This is used to construct performance coordinates for hotplugged CXL DEVICES,
+which cannot be enumerated at boot by platform firmware.
+
+Example ::
+
+ Subtable Type : 06 [Generic Port Affinity]
+ Length : 20 <- 32d, length of table
+ Reserved : 00
+ Device Handle Type : 00 <- 0 - ACPI, 1 - PCI
+ Proximity Domain : 00000001
+ Device Handle : ACPI0016:01
+ Flags : 00000001 <- Bit 0 (Enabled)
+ Reserved : 00000000
+
+The Proximity Domain is matched up to the :doc:`HMAT <hmat>` SSLBI Target
+Proximity Domain List for the related latency or bandwidth numbers. Those
+performance numbers are tied to a CXL host bridge via the Device Handle.
+The driver uses the association to retrieve the Generic Port performance
+numbers for the whole CXL path access coordinates calculation.
diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
new file mode 100644
index 000000000000..a9aa0ccd92af
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
@@ -0,0 +1,262 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+BIOS/EFI Configuration
+======================
+
+BIOS and EFI are largely responsible for configuring static information about
+devices (or potential future devices) such that Linux can build the appropriate
+logical representations of these devices.
+
+At a high level, this is what occurs during this phase of configuration.
+
+* The bootloader starts the BIOS/EFI.
+
+* BIOS/EFI do early device probe to determine static configuration
+
+* BIOS/EFI creates ACPI Tables that describe static config for the OS
+
+* BIOS/EFI create the system memory map (EFI Memory Map, E820, etc)
+
+* BIOS/EFI calls :code:`start_kernel` and begins the Linux Early Boot process.
+
+Much of what this section is concerned with is ACPI Table production and
+static memory map configuration. More detail on these tables can be found
+at :doc:`ACPI Tables <acpi>`.
+
+.. note::
+ Platform Vendors should read carefully, as this sections has recommendations
+ on physical memory region size and alignment, memory holes, HDM interleave,
+ and what linux expects of HDM decoders trying to work with these features.
+
+UEFI Settings
+=============
+If your platform supports it, the :code:`uefisettings` command can be used to
+read/write EFI settings. Changes will be reflected on the next reboot. Kexec
+is not a sufficient reboot.
+
+One notable configuration here is the EFI_MEMORY_SP (Specific Purpose) bit.
+When this is enabled, this bit tells linux to defer management of a memory
+region to a driver (in this case, the CXL driver). Otherwise, the memory is
+treated as "normal memory", and is exposed to the page allocator during
+:code:`__init`.
+
+uefisettings examples
+---------------------
+
+:code:`uefisettings identify` ::
+
+ uefisettings identify
+
+ bios_vendor: xxx
+ bios_version: xxx
+ bios_release: xxx
+ bios_date: xxx
+ product_name: xxx
+ product_family: xxx
+ product_version: xxx
+
+On some AMD platforms, the :code:`EFI_MEMORY_SP` bit is set via the :code:`CXL
+Memory Attribute` field. This may be called something else on your platform.
+
+:code:`uefisettings get "CXL Memory Attribute"` ::
+
+ selector: xxx
+ ...
+ question: Question {
+ name: "CXL Memory Attribute",
+ answer: "Enabled",
+ ...
+ }
+
+Physical Memory Map
+===================
+
+Physical Address Region Alignment
+---------------------------------
+
+As of Linux v6.14, the hotplug memory system requires memory regions to be
+uniform in size and alignment. While the CXL specification allows for memory
+regions as small as 256MB, the supported memory block size and alignment for
+hotplugged memory is architecture-defined.
+
+A Linux memory blocks may be as small as 128MB and increase in powers of two.
+
+* On ARM, the default block size and alignment is either 128MB or 256MB.
+
+* On x86, the default block size is 256MB, and increases to 2GB as the
+ capacity of the system increases up to 64GB.
+
+For best support across versions, platform vendors should place CXL memory at
+a 2GB aligned base address, and regions should be 2GB aligned. This also helps
+prevent the creating thousands of memory devices (one per block).
+
+Memory Holes
+------------
+
+Holes in the memory map are tricky. Consider a 4GB device located at base
+address 0x100000000, but with the following memory map ::
+
+ ---------------------
+ | 0x100000000 |
+ | CXL |
+ | 0x1BFFFFFFF |
+ ---------------------
+ | 0x1C0000000 |
+ | MEMORY HOLE |
+ | 0x1FFFFFFFF |
+ ---------------------
+ | 0x200000000 |
+ | CXL CONT. |
+ | 0x23FFFFFFF |
+ ---------------------
+
+There are two issues to consider:
+
+* decoder programming, and
+* memory block alignment.
+
+If your architecture requires 2GB uniform size and aligned memory blocks, the
+only capacity Linux is capable of mapping (as of v6.14) would be the capacity
+from `0x100000000-0x180000000`. The remaining capacity will be stranded, as
+they are not of 2GB aligned length.
+
+Assuming your architecture and memory configuration allows 1GB memory blocks,
+this memory map is supported and this should be presented as multiple CFMWS
+in the CEDT that describe each side of the memory hole separately - along with
+matching decoders.
+
+Multiple decoders can (and should) be used to manage such a memory hole (see
+below), but each chunk of a memory hole should be aligned to a reasonable block
+size (larger alignment is always better). If you intend to have memory holes
+in the memory map, expect to use one decoder per contiguous chunk of host
+physical memory.
+
+As of v6.14, Linux does provide support for memory hotplug of multiple
+physical memory regions separated by a memory hole described by a single
+HDM decoder.
+
+
+Decoder Programming
+===================
+If BIOS/EFI intends to program the decoders to be statically configured,
+there are a few things to consider to avoid major pitfalls that will
+prevent Linux compatibility. Some of these recommendations are not
+required "per the specification", but Linux makes no guarantees of support
+otherwise.
+
+
+Translation Point
+-----------------
+Per the specification, the only decoders which **TRANSLATE** Host Physical
+Address (HPA) to Device Physical Address (DPA) are the **Endpoint Decoders**.
+All other decoders in the fabric are intended to route accesses without
+translating the addresses.
+
+This is heavily implied by the specification, see: ::
+
+ CXL Specification 3.1
+ 8.2.4.20: CXL HDM Decoder Capability Structure
+ - Implementation Note: CXL Host Bridge and Upstream Switch Port Decoder Flow
+ - Implementation Note: Device Decoder Logic
+
+Given this, Linux makes a strong assumption that decoders between CPU and
+endpoint will all be programmed with addresses ranges that are subsets of
+their parent decoder.
+
+Due to some ambiguity in how Architecture, ACPI, PCI, and CXL specifications
+"hand off" responsibility between domains, some early adopting platforms
+attempted to do translation at the originating memory controller or host
+bridge. This configuration requires a platform specific extension to the
+driver and is not officially endorsed - despite being supported.
+
+It is *highly recommended* **NOT** to do this; otherwise, you are on your own
+to implement driver support for your platform.
+
+Interleave and Configuration Flexibility
+----------------------------------------
+If providing cross-host-bridge interleave, a CFMWS entry in the :doc:`CEDT
+<acpi/cedt>` must be presented with target host-bridges for the interleaved
+device sets (there may be multiple behind each host bridge).
+
+If providing intra-host-bridge interleaving, only 1 CFMWS entry in the CEDT is
+required for that host bridge - if it covers the entire capacity of the devices
+behind the host bridge.
+
+If intending to provide users flexibility in programming decoders beyond the
+root, you may want to provide multiple CFMWS entries in the CEDT intended for
+different purposes. For example, you may want to consider adding:
+
+1) A CFMWS entry to cover all interleavable host bridges.
+2) A CFMWS entry to cover all devices on a single host bridge.
+3) A CFMWS entry to cover each device.
+
+A platform may choose to add all of these, or change the mode based on a BIOS
+setting. For each CFMWS entry, Linux expects descriptions of the described
+memory regions in the :doc:`SRAT <acpi/srat>` to determine the number of
+NUMA nodes it should reserve during early boot / init.
+
+As of v6.14, Linux will create a NUMA node for each CEDT CFMWS entry, even if
+a matching SRAT entry does not exist; however, this is not guaranteed in the
+future and such a configuration should be avoided.
+
+Memory Holes
+------------
+If your platform includes memory holes interspersed between your CXL memory, it
+is recommended to utilize multiple decoders to cover these regions of memory,
+rather than try to program the decoders to accept the entire range and expect
+Linux to manage the overlap.
+
+For example, consider the Memory Hole described above ::
+
+ ---------------------
+ | 0x100000000 |
+ | CXL |
+ | 0x1BFFFFFFF |
+ ---------------------
+ | 0x1C0000000 |
+ | MEMORY HOLE |
+ | 0x1FFFFFFFF |
+ ---------------------
+ | 0x200000000 |
+ | CXL CONT. |
+ | 0x23FFFFFFF |
+ ---------------------
+
+Assuming this is provided by a single device attached directly to a host bridge,
+Linux would expect the following decoder programming ::
+
+ ----------------------- -----------------------
+ | root-decoder-0 | | root-decoder-1 |
+ | base: 0x100000000 | | base: 0x200000000 |
+ | size: 0xC0000000 | | size: 0x40000000 |
+ ----------------------- -----------------------
+ | |
+ ----------------------- -----------------------
+ | HB-decoder-0 | | HB-decoder-1 |
+ | base: 0x100000000 | | base: 0x200000000 |
+ | size: 0xC0000000 | | size: 0x40000000 |
+ ----------------------- -----------------------
+ | |
+ ----------------------- -----------------------
+ | ep-decoder-0 | | ep-decoder-1 |
+ | base: 0x100000000 | | base: 0x200000000 |
+ | size: 0xC0000000 | | size: 0x40000000 |
+ ----------------------- -----------------------
+
+With a CEDT configuration with two CFMWS describing the above root decoders.
+
+Linux makes no guarantee of support for strange memory hole situations.
+
+Multi-Media Devices
+-------------------
+The CFMWS field of the CEDT has special restriction bits which describe whether
+the described memory region allows volatile or persistent memory (or both). If
+the platform intends to support either:
+
+1) A device with multiple medias, or
+2) Using a persistent memory device as normal memory
+
+A platform may wish to create multiple CEDT CFMWS entries to describe the same
+memory, with the intent of allowing the end user flexibility in how that memory
+is configured. Linux does not presently have strong requirements in this area.
diff --git a/Documentation/driver-api/cxl/platform/cdat.rst b/Documentation/driver-api/cxl/platform/cdat.rst
new file mode 100644
index 000000000000..34bbe7264d71
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/cdat.rst
@@ -0,0 +1,118 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Coherent Device Attribute Table (CDAT)
+======================================
+
+The CDAT provides functional and performance attributes of devices such
+as CXL accelerators, switches, or endpoints. The table formatting is
+similar to ACPI tables. CDAT data may be parsed by BIOS at boot or may
+be enumerated at runtime (after device hotplug, for example).
+
+Terminology:
+DPA - Device Physical Address, used by the CXL device to denote the address
+it supports for that device.
+
+DSMADHandle - A device unique handle that is associated with a DPA range
+defined by the DSMAS table.
+
+
+===============================================
+Device Scoped Memory Affinity Structure (DSMAS)
+===============================================
+
+The DSMAS contains information such as DSMADHandle, the DPA Base, and DPA
+Length.
+
+This table is used by Linux in conjunction with the Device Scoped Latency and
+Bandwidth Information Structure (DSLBIS) to determine the performance
+attributes of the CXL device itself.
+
+Example ::
+
+ Structure Type : 00 [DSMAS]
+ Reserved : 00
+ Length : 0018 <- 24d, size of structure
+ DSMADHandle : 01
+ Flags : 00
+ Reserved : 0000
+ DPA Base : 0000000040000000 <- 1GiB base
+ DPA Length : 0000000080000000 <- 2GiB size
+
+
+==================================================================
+Device Scoped Latency and Bandwidth Information Structure (DSLBIS)
+==================================================================
+
+This table is used by Linux in conjunction with DSMAS to determine the
+performance attributes of a CXL device. The DSLBIS contains latency
+and bandwidth information based on DSMADHandle matching.
+
+Example ::
+
+ Structure Type : 01 [DSLBIS]
+ Reserved : 00
+ Length : 18 <- 24d, size of structure
+ Handle : 0001 <- DSMAS handle
+ Flags : 00 <- Matches flag field for HMAT SLLBIS
+ Data Type : 00 <- Latency
+ Entry Basee Unit : 0000000000001000 <- Entry Base Unit field in HMAT SSLBIS
+ Entry : 010000000000 <- First byte used here, CXL LTC
+ Reserved : 0000
+
+ Structure Type : 01 [DSLBIS]
+ Reserved : 00
+ Length : 18 <- 24d, size of structure
+ Handle : 0001 <- DSMAS handle
+ Flags : 00 <- Matches flag field for HMAT SLLBIS
+ Data Type : 03 <- Bandwidth
+ Entry Basee Unit : 0000000000001000 <- Entry Base Unit field in HMAT SSLBIS
+ Entry : 020000000000 <- First byte used here, CXL BW
+ Reserved : 0000
+
+
+==================================================================
+Switch Scoped Latency and Bandwidth Information Structure (SSLBIS)
+==================================================================
+
+The SSLBIS contains information about the latency and bandwidth of a switch.
+
+The table is used by Linux to compute the performance coordinates of a CXL path
+from the device to the root port where a switch is part of the path.
+
+Example ::
+
+ Structure Type : 05 [SSLBIS]
+ Reserved : 00
+ Length : 20 <- 32d, length of record, including SSLB entries
+ Data Type : 00 <- Latency
+ Reserved : 000000
+ Entry Base Unit : 00000000000000001000 <- Matches Entry Base Unit in HMAT SSLBIS
+
+ <- SSLB Entry 0
+ Port X ID : 0100 <- First port, 0100h represents an upstream port
+ Port Y ID : 0000 <- Second port, downstream port 0
+ Latency : 0100 <- Port latency
+ Reserved : 0000
+ <- SSLB Entry 1
+ Port X ID : 0100
+ Port Y ID : 0001
+ Latency : 0100
+ Reserved : 0000
+
+
+ Structure Type : 05 [SSLBIS]
+ Reserved : 00
+ Length : 18 <- 24d, length of record, including SSLB entry
+ Data Type : 03 <- Bandwidth
+ Reserved : 000000
+ Entry Base Unit : 00000000000000001000 <- Matches Entry Base Unit in HMAT SSLBIS
+
+ <- SSLB Entry 0
+ Port X ID : 0100 <- First port, 0100h represents an upstream port
+ Port Y ID : FFFF <- Second port, FFFFh indicates any port
+ Bandwidth : 1200 <- Port bandwidth
+ Reserved : 0000
+
+The CXL driver uses a combination of CDAT, HMAT, SRAT, and other data to
+generate "whole path performance" data for a CXL device.
diff --git a/Documentation/driver-api/cxl/platform/example-configs.rst b/Documentation/driver-api/cxl/platform/example-configs.rst
new file mode 100644
index 000000000000..90a10d7473c6
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/example-configs.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Example Platform Configurations
+###############################
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+
+ example-configurations/one-dev-per-hb.rst
+ example-configurations/multi-dev-per-hb.rst
+ example-configurations/hb-interleave.rst
+ example-configurations/flexible.rst
diff --git a/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst b/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst
new file mode 100644
index 000000000000..dab704b6fcc2
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/example-configurations/flexible.rst
@@ -0,0 +1,296 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Flexible Presentation
+=====================
+This system has a single socket with two CXL host bridges. Each host bridge
+has two CXL memory expanders with a 4GB of memory (32GB total).
+
+On this system, the platform designer wanted to provide the user flexibility
+to configure the memory devices in various interleave or NUMA node
+configurations. So they provided every combination.
+
+Things to note:
+
+* Cross-Bridge interleave is described in one CFMWS that covers all capacity.
+* One CFMWS is also described per-host bridge.
+* One CFMWS is also described per-device.
+* This SRAT describes one node for each of the above CFMWS.
+* The HMAT describes performance for each node in the SRAT.
+
+:doc:`CEDT <../acpi/cedt>`::
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000007
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010370400000
+ Register length : 0000000000010000
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000006
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010380800000
+ Register length : 0000000000010000
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000001000000000
+ Window size : 0000000400000000
+ Interleave Members (2^n) : 01
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+ Second Target : 00000006
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000002000000000
+ Window size : 0000000200000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000002200000000
+ Window size : 0000000200000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000006
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000003000000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000003100000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000003200000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000006
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000003300000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000006
+
+:doc:`SRAT <../acpi/srat>`::
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000001
+ Reserved1 : 0000
+ Base Address : 0000001000000000
+ Address Length : 0000000400000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000002
+ Reserved1 : 0000
+ Base Address : 0000002000000000
+ Address Length : 0000000200000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000003
+ Reserved1 : 0000
+ Base Address : 0000002200000000
+ Address Length : 0000000200000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000004
+ Reserved1 : 0000
+ Base Address : 0000003000000000
+ Address Length : 0000000100000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000005
+ Reserved1 : 0000
+ Base Address : 0000003100000000
+ Address Length : 0000000100000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000006
+ Reserved1 : 0000
+ Base Address : 0000003200000000
+ Address Length : 0000000100000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000007
+ Reserved1 : 0000
+ Base Address : 0000003300000000
+ Address Length : 0000000100000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+:doc:`HMAT <../acpi/hmat>`::
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 00 [Latency]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Target Proximity Domain List : 00000002
+ Target Proximity Domain List : 00000003
+ Target Proximity Domain List : 00000004
+ Target Proximity Domain List : 00000005
+ Target Proximity Domain List : 00000006
+ Target Proximity Domain List : 00000007
+ Entry : 0080
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 03 [Bandwidth]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Target Proximity Domain List : 00000002
+ Target Proximity Domain List : 00000003
+ Target Proximity Domain List : 00000004
+ Target Proximity Domain List : 00000005
+ Target Proximity Domain List : 00000006
+ Target Proximity Domain List : 00000007
+ Entry : 1200
+ Entry : 0400
+ Entry : 0200
+ Entry : 0200
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+ Entry : 0100
+
+:doc:`SLIT <../acpi/slit>`::
+
+ Signature : "SLIT" [System Locality Information Table]
+ Localities : 0000000000000003
+ Locality 0 : 10 20 20 20 20 20 20 20
+ Locality 1 : FF 0A FF FF FF FF FF FF
+ Locality 2 : FF FF 0A FF FF FF FF FF
+ Locality 3 : FF FF FF 0A FF FF FF FF
+ Locality 4 : FF FF FF FF 0A FF FF FF
+ Locality 5 : FF FF FF FF FF 0A FF FF
+ Locality 6 : FF FF FF FF FF FF 0A FF
+ Locality 7 : FF FF FF FF FF FF FF 0A
+
+:doc:`DSDT <../acpi/dsdt>`::
+
+ Scope (_SB)
+ {
+ Device (S0D0)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x07) // _UID: Unique ID
+ }
+ ...
+ Device (S0D5)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x06) // _UID: Unique ID
+ }
+ }
diff --git a/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst b/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst
new file mode 100644
index 000000000000..c474dcf09fb0
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/example-configurations/hb-interleave.rst
@@ -0,0 +1,107 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+Cross-Host-Bridge Interleave
+============================
+This system has a single socket with two CXL host bridges. Each host bridge
+has a single CXL memory expander with a 4GB of memory.
+
+Things to note:
+
+* Cross-Bridge interleave is described.
+* The expanders are described by a single CFMWS.
+* This SRAT describes one node for both host bridges.
+* The HMAT describes a single node's performance.
+
+:doc:`CEDT <../acpi/cedt>`::
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000007
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010370400000
+ Register length : 0000000000010000
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000006
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010380800000
+ Register length : 0000000000010000
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000001000000000
+ Window size : 0000000200000000
+ Interleave Members (2^n) : 01
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+ Second Target : 00000006
+
+:doc:`SRAT <../acpi/srat>`::
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000001
+ Reserved1 : 0000
+ Base Address : 0000001000000000
+ Address Length : 0000000200000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+:doc:`HMAT <../acpi/hmat>`::
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 00 [Latency]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Target Proximity Domain List : 00000002
+ Entry : 0080
+ Entry : 0100
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 03 [Bandwidth]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Target Proximity Domain List : 00000002
+ Entry : 1200
+ Entry : 0400
+
+:doc:`SLIT <../acpi/slit>`::
+
+ Signature : "SLIT" [System Locality Information Table]
+ Localities : 0000000000000003
+ Locality 0 : 10 20
+ Locality 1 : FF 0A
+
+:doc:`DSDT <../acpi/dsdt>`::
+
+ Scope (_SB)
+ {
+ Device (S0D0)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x07) // _UID: Unique ID
+ }
+ ...
+ Device (S0D5)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x06) // _UID: Unique ID
+ }
+ }
diff --git a/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst b/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst
new file mode 100644
index 000000000000..a7854a79dbbd
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/example-configurations/multi-dev-per-hb.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================================
+Multiple Devices per Host Bridge
+================================
+
+In this example system we will have a single socket and one CXL host bridge.
+There are two CXL memory expanders with 4GB attached to the host bridge.
+
+Things to note:
+
+* Intra-Bridge interleave is not described here.
+* The expanders are described by a single CEDT/CFMWS.
+* This CEDT/SRAT describes one node for both devices.
+* There is only one proximity domain the HMAT for both devices.
+
+:doc:`CEDT <../acpi/cedt>`::
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000007
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010370400000
+ Register length : 0000000000010000
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000001000000000
+ Window size : 0000000200000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+
+:doc:`SRAT <../acpi/srat>`::
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000001
+ Reserved1 : 0000
+ Base Address : 0000001000000000
+ Address Length : 0000000200000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+:doc:`HMAT <../acpi/hmat>`::
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 00 [Latency]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Entry : 0080
+ Entry : 0100
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 03 [Bandwidth]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Entry : 1200
+ Entry : 0200
+
+:doc:`SLIT <../acpi/slit>`::
+
+ Signature : "SLIT" [System Locality Information Table]
+ Localities : 0000000000000003
+ Locality 0 : 10 20
+ Locality 1 : FF 0A
+
+:doc:`DSDT <../acpi/dsdt>`::
+
+ Scope (_SB)
+ {
+ Device (S0D0)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x07) // _UID: Unique ID
+ }
+ ...
+ }
diff --git a/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst b/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst
new file mode 100644
index 000000000000..a4c3fb51ea7d
--- /dev/null
+++ b/Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst
@@ -0,0 +1,136 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================
+One Device per Host Bridge
+==========================
+
+This system has a single socket with two CXL host bridges. Each host bridge
+has a single CXL memory expander with a 4GB of memory.
+
+Things to note:
+
+* Cross-Bridge interleave is not being used.
+* The expanders are in two separate but adjacent memory regions.
+* This CEDT/SRAT describes one node per device
+* The expanders have the same performance and will be in the same memory tier.
+
+:doc:`CEDT <../acpi/cedt>`::
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000007
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010370400000
+ Register length : 0000000000010000
+
+ Subtable Type : 00 [CXL Host Bridge Structure]
+ Reserved : 00
+ Length : 0020
+ Associated host bridge : 00000006
+ Specification version : 00000001
+ Reserved : 00000000
+ Register base : 0000010380800000
+ Register length : 0000000000010000
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000001000000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000007
+
+ Subtable Type : 01 [CXL Fixed Memory Window Structure]
+ Reserved : 00
+ Length : 002C
+ Reserved : 00000000
+ Window base address : 0000001100000000
+ Window size : 0000000100000000
+ Interleave Members (2^n) : 00
+ Interleave Arithmetic : 00
+ Reserved : 0000
+ Granularity : 00000000
+ Restrictions : 0006
+ QtgId : 0001
+ First Target : 00000006
+
+:doc:`SRAT <../acpi/srat>`::
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000001
+ Reserved1 : 0000
+ Base Address : 0000001000000000
+ Address Length : 0000000100000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+ Subtable Type : 01 [Memory Affinity]
+ Length : 28
+ Proximity Domain : 00000002
+ Reserved1 : 0000
+ Base Address : 0000001100000000
+ Address Length : 0000000100000000
+ Reserved2 : 00000000
+ Flags (decoded below) : 0000000B
+ Enabled : 1
+ Hot Pluggable : 1
+ Non-Volatile : 0
+
+:doc:`HMAT <../acpi/hmat>`::
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 00 [Latency]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Target Proximity Domain List : 00000002
+ Entry : 0080
+ Entry : 0100
+ Entry : 0100
+
+ Structure Type : 0001 [SLLBI]
+ Data Type : 03 [Bandwidth]
+ Target Proximity Domain List : 00000000
+ Target Proximity Domain List : 00000001
+ Target Proximity Domain List : 00000002
+ Entry : 1200
+ Entry : 0200
+ Entry : 0200
+
+:doc:`SLIT <../acpi/slit>`::
+
+ Signature : "SLIT" [System Locality Information Table]
+ Localities : 0000000000000003
+ Locality 0 : 10 20 20
+ Locality 1 : FF 0A FF
+ Locality 2 : FF FF 0A
+
+:doc:`DSDT <../acpi/dsdt>`::
+
+ Scope (_SB)
+ {
+ Device (S0D0)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x07) // _UID: Unique ID
+ }
+ ...
+ Device (S0D5)
+ {
+ Name (_HID, "ACPI0016" /* Compute Express Link Host Bridge */) // _HID: Hardware ID
+ ...
+ Name (_UID, 0x06) // _UID: Unique ID
+ }
+ }
diff --git a/Documentation/driver-api/cxl/theory-of-operation.rst b/Documentation/driver-api/cxl/theory-of-operation.rst
new file mode 100644
index 000000000000..257f513e320c
--- /dev/null
+++ b/Documentation/driver-api/cxl/theory-of-operation.rst
@@ -0,0 +1,415 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===============================================
+Compute Express Link Driver Theory of Operation
+===============================================
+
+A Compute Express Link Memory Device is a CXL component that implements the
+CXL.mem protocol. It contains some amount of volatile memory, persistent memory,
+or both. It is enumerated as a PCI device for configuration and passing
+messages over an MMIO mailbox. Its contribution to the System Physical
+Address space is handled via HDM (Host Managed Device Memory) decoders
+that optionally define a device's contribution to an interleaved address
+range across multiple devices underneath a host-bridge or interleaved
+across host-bridges.
+
+The CXL Bus
+===========
+Similar to how a RAID driver takes disk objects and assembles them into a new
+logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and
+assemble them into a CXL.mem decode topology. The need for runtime configuration
+of the CXL.mem topology is also similar to RAID in that different environments
+with the same hardware configuration may decide to assemble the topology in
+contrasting ways. One may choose performance (RAID0) striping memory across
+multiple Host Bridges and endpoints while another may opt for fault tolerance
+and disable any striping in the CXL.mem topology.
+
+Platform firmware enumerates a menu of interleave options at the "CXL root port"
+(Linux term for the top of the CXL decode topology). From there, PCIe topology
+dictates which endpoints can participate in which Host Bridge decode regimes.
+Each PCIe Switch in the path between the root and an endpoint introduces a point
+at which the interleave can be split. For example, platform firmware may say a
+given range only decodes to one Host Bridge, but that Host Bridge may in turn
+interleave cycles across multiple Root Ports. An intervening Switch between a
+port and an endpoint may interleave cycles across multiple Downstream Switch
+Ports, etc.
+
+Here is a sample listing of a CXL topology defined by 'cxl_test'. The 'cxl_test'
+module generates an emulated CXL topology of 2 Host Bridges each with 2 Root
+Ports. Each of those Root Ports are connected to 2-way switches with endpoints
+connected to those downstream ports for a total of 8 endpoints::
+
+ # cxl list -BEMPu -b cxl_test
+ {
+ "bus":"root3",
+ "provider":"cxl_test",
+ "ports:root3":[
+ {
+ "port":"port5",
+ "host":"cxl_host_bridge.1",
+ "ports:port5":[
+ {
+ "port":"port8",
+ "host":"cxl_switch_uport.1",
+ "endpoints:port8":[
+ {
+ "endpoint":"endpoint9",
+ "host":"mem2",
+ "memdev":{
+ "memdev":"mem2",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x1",
+ "numa_node":1,
+ "host":"cxl_mem.1"
+ }
+ },
+ {
+ "endpoint":"endpoint15",
+ "host":"mem6",
+ "memdev":{
+ "memdev":"mem6",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x5",
+ "numa_node":1,
+ "host":"cxl_mem.5"
+ }
+ }
+ ]
+ },
+ {
+ "port":"port12",
+ "host":"cxl_switch_uport.3",
+ "endpoints:port12":[
+ {
+ "endpoint":"endpoint17",
+ "host":"mem8",
+ "memdev":{
+ "memdev":"mem8",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x7",
+ "numa_node":1,
+ "host":"cxl_mem.7"
+ }
+ },
+ {
+ "endpoint":"endpoint13",
+ "host":"mem4",
+ "memdev":{
+ "memdev":"mem4",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x3",
+ "numa_node":1,
+ "host":"cxl_mem.3"
+ }
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "port":"port4",
+ "host":"cxl_host_bridge.0",
+ "ports:port4":[
+ {
+ "port":"port6",
+ "host":"cxl_switch_uport.0",
+ "endpoints:port6":[
+ {
+ "endpoint":"endpoint7",
+ "host":"mem1",
+ "memdev":{
+ "memdev":"mem1",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0",
+ "numa_node":0,
+ "host":"cxl_mem.0"
+ }
+ },
+ {
+ "endpoint":"endpoint14",
+ "host":"mem5",
+ "memdev":{
+ "memdev":"mem5",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x4",
+ "numa_node":0,
+ "host":"cxl_mem.4"
+ }
+ }
+ ]
+ },
+ {
+ "port":"port10",
+ "host":"cxl_switch_uport.2",
+ "endpoints:port10":[
+ {
+ "endpoint":"endpoint16",
+ "host":"mem7",
+ "memdev":{
+ "memdev":"mem7",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x6",
+ "numa_node":0,
+ "host":"cxl_mem.6"
+ }
+ },
+ {
+ "endpoint":"endpoint11",
+ "host":"mem3",
+ "memdev":{
+ "memdev":"mem3",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x2",
+ "numa_node":0,
+ "host":"cxl_mem.2"
+ }
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+
+In that listing each "root", "port", and "endpoint" object correspond a kernel
+'struct cxl_port' object. A 'cxl_port' is a device that can decode CXL.mem to
+its descendants. So "root" claims non-PCIe enumerable platform decode ranges and
+decodes them to "ports", "ports" decode to "endpoints", and "endpoints"
+represent the decode from SPA (System Physical Address) to DPA (Device Physical
+Address).
+
+Continuing the RAID analogy, disks have both topology metadata and on-device
+metadata that determine RAID set assembly. CXL Port topology and CXL Port link
+status is metadata for CXL.mem set assembly. The CXL Port topology is enumerated
+by the arrival of a CXL.mem device. I.e. unless and until the PCIe core attaches
+the cxl_pci driver to a CXL Memory Expander there is no role for CXL Port
+objects. Conversely for hot-unplug / removal scenarios, there is no need for
+the Linux PCI core to tear down switch-level CXL resources because the endpoint
+->remove() event cleans up the port data that was established to support that
+Memory Expander.
+
+The port metadata and potential decode schemes that a given memory device may
+participate can be determined via a command like::
+
+ # cxl list -BDMu -d root -m mem3
+ {
+ "bus":"root3",
+ "provider":"cxl_test",
+ "decoders:root3":[
+ {
+ "decoder":"decoder3.1",
+ "resource":"0x8030000000",
+ "size":"512.00 MiB (536.87 MB)",
+ "volatile_capable":true,
+ "nr_targets":2
+ },
+ {
+ "decoder":"decoder3.3",
+ "resource":"0x8060000000",
+ "size":"512.00 MiB (536.87 MB)",
+ "pmem_capable":true,
+ "nr_targets":2
+ },
+ {
+ "decoder":"decoder3.0",
+ "resource":"0x8020000000",
+ "size":"256.00 MiB (268.44 MB)",
+ "volatile_capable":true,
+ "nr_targets":1
+ },
+ {
+ "decoder":"decoder3.2",
+ "resource":"0x8050000000",
+ "size":"256.00 MiB (268.44 MB)",
+ "pmem_capable":true,
+ "nr_targets":1
+ }
+ ],
+ "memdevs:root3":[
+ {
+ "memdev":"mem3",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x2",
+ "numa_node":0,
+ "host":"cxl_mem.2"
+ }
+ ]
+ }
+
+...which queries the CXL topology to ask "given CXL Memory Expander with a kernel
+device name of 'mem3' which platform level decode ranges may this device
+participate". A given expander can participate in multiple CXL.mem interleave
+sets simultaneously depending on how many decoder resources it has. In this
+example mem3 can participate in one or more of a PMEM interleave that spans two
+Host Bridges, a PMEM interleave that targets a single Host Bridge, a Volatile
+memory interleave that spans 2 Host Bridges, and a Volatile memory interleave
+that only targets a single Host Bridge.
+
+Conversely the memory devices that can participate in a given platform level
+decode scheme can be determined via a command like the following::
+
+ # cxl list -MDu -d 3.2
+ [
+ {
+ "memdevs":[
+ {
+ "memdev":"mem1",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0",
+ "numa_node":0,
+ "host":"cxl_mem.0"
+ },
+ {
+ "memdev":"mem5",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x4",
+ "numa_node":0,
+ "host":"cxl_mem.4"
+ },
+ {
+ "memdev":"mem7",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x6",
+ "numa_node":0,
+ "host":"cxl_mem.6"
+ },
+ {
+ "memdev":"mem3",
+ "pmem_size":"256.00 MiB (268.44 MB)",
+ "ram_size":"256.00 MiB (268.44 MB)",
+ "serial":"0x2",
+ "numa_node":0,
+ "host":"cxl_mem.2"
+ }
+ ]
+ },
+ {
+ "root decoders":[
+ {
+ "decoder":"decoder3.2",
+ "resource":"0x8050000000",
+ "size":"256.00 MiB (268.44 MB)",
+ "pmem_capable":true,
+ "nr_targets":1
+ }
+ ]
+ }
+ ]
+
+...where the naming scheme for decoders is "decoder<port_id>.<instance_id>".
+
+Driver Infrastructure
+=====================
+
+This section covers the driver infrastructure for a CXL memory device.
+
+CXL Memory Device
+-----------------
+
+.. kernel-doc:: drivers/cxl/pci.c
+ :doc: cxl pci
+
+.. kernel-doc:: drivers/cxl/pci.c
+ :internal:
+
+.. kernel-doc:: drivers/cxl/mem.c
+ :doc: cxl mem
+
+.. kernel-doc:: drivers/cxl/cxlmem.h
+ :internal:
+
+.. kernel-doc:: drivers/cxl/core/memdev.c
+ :identifiers:
+
+CXL Port
+--------
+.. kernel-doc:: drivers/cxl/port.c
+ :doc: cxl port
+
+CXL Core
+--------
+.. kernel-doc:: drivers/cxl/cxl.h
+ :doc: cxl objects
+
+.. kernel-doc:: drivers/cxl/cxl.h
+ :internal:
+
+.. kernel-doc:: drivers/cxl/acpi.c
+ :identifiers: add_cxl_resources
+
+.. kernel-doc:: drivers/cxl/core/hdm.c
+ :doc: cxl core hdm
+
+.. kernel-doc:: drivers/cxl/core/hdm.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/cdat.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/port.c
+ :doc: cxl core
+
+.. kernel-doc:: drivers/cxl/core/port.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/pci.c
+ :doc: cxl core pci
+
+.. kernel-doc:: drivers/cxl/core/pci.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/pmem.c
+ :doc: cxl pmem
+
+.. kernel-doc:: drivers/cxl/core/pmem.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/regs.c
+ :doc: cxl registers
+
+.. kernel-doc:: drivers/cxl/core/regs.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/mbox.c
+ :doc: cxl mbox
+
+.. kernel-doc:: drivers/cxl/core/mbox.c
+ :identifiers:
+
+.. kernel-doc:: drivers/cxl/core/features.c
+ :doc: cxl features
+
+See :c:func:`devm_cxl_setup_features` for API details.
+
+CXL Regions
+-----------
+.. kernel-doc:: drivers/cxl/core/region.c
+ :doc: cxl core region
+
+.. kernel-doc:: drivers/cxl/core/region.c
+ :identifiers:
+
+External Interfaces
+===================
+
+CXL IOCTL Interface
+-------------------
+
+.. kernel-doc:: include/uapi/linux/cxl_mem.h
+ :doc: UAPI
+
+.. kernel-doc:: include/uapi/linux/cxl_mem.h
+ :internal:
diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst
index 4d2baac0311c..d1aaa961cac4 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -16,7 +16,7 @@ Bus-Independent Device Accesses
Introduction
============
-Linux provides an API which abstracts performing IO across all busses
+Linux provides an API which abstracts performing IO across all buses
and devices, allowing device drivers to be written independently of bus
type.
@@ -71,7 +71,7 @@ can be compiler optimised, you can use __readb() and friends to
indicate the relaxed ordering. Use this with care.
While the basic functions are defined to be synchronous with respect to
-each other and ordered with respect to each other the busses the devices
+each other and ordered with respect to each other the buses the devices
sit on may themselves have asynchronicity. In particular many authors
are burned by the fact that PCI bus writes are posted asynchronously. A
driver author must issue a read from the same device to ensure that
@@ -408,11 +408,12 @@ functions for details on the CPU side of things.
ioremap_uc()
------------
-ioremap_uc() behaves like ioremap() except that on the x86 architecture without
-'PAT' mode, it marks memory as uncached even when the MTRR has designated
-it as cacheable, see Documentation/x86/pat.rst.
+ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension,
+and on ia64 with its slightly unconventional ioremap() behavior, everywhere
+elss ioremap_uc() defaults to return NULL.
-Portable drivers should avoid the use of ioremap_uc().
+
+Portable drivers should avoid the use of ioremap_uc(), use ioremap() instead.
ioremap_cache()
---------------
@@ -516,6 +517,3 @@ Public Functions Provided
.. kernel-doc:: arch/x86/include/asm/io.h
:internal:
-
-.. kernel-doc:: lib/pci_iomap.c
- :export:
diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 36a76cbe9095..29abf1eebf9f 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -1,18 +1,34 @@
-Buffer Sharing and Synchronization
-==================================
+Buffer Sharing and Synchronization (dma-buf)
+============================================
The dma-buf subsystem provides the framework for sharing buffers for
hardware (DMA) access across multiple device drivers and subsystems, and
for synchronizing asynchronous hardware access.
-This is used, for example, by drm "prime" multi-GPU support, but is of
-course not limited to GPU use cases.
+As an example, it is used extensively by the DRM subsystem to exchange
+buffers between processes, contexts, library APIs within the same
+process, and also to exchange buffers with other subsystems such as
+V4L2.
+
+This document describes the way in which kernel subsystems can use and
+interact with the three main primitives offered by dma-buf:
+
+ - dma-buf, representing a sg_table and exposed to userspace as a file
+ descriptor to allow passing between processes, subsystems, devices,
+ etc;
+ - dma-fence, providing a mechanism to signal when an asynchronous
+ hardware operation has completed; and
+ - dma-resv, which manages a set of dma-fences for a particular dma-buf
+ allowing implicit (kernel-ordered) synchronization of work to
+ preserve the illusion of coherent access
+
+
+Userspace API principles and use
+--------------------------------
+
+For more details on how to design your subsystem's API for dma-buf use, please
+see Documentation/userspace-api/dma-buf-alloc-exchange.rst.
-The three main components of this are: (1) dma-buf, representing a
-sg_table and exposed to userspace as a file descriptor to allow passing
-between devices, (2) fence, which provides a mechanism to signal when
-one device has finished access, and (3) reservation, which manages the
-shared or exclusive fence(s) associated with the buffer.
Shared DMA Buffers
------------------
@@ -61,7 +77,7 @@ consider though:
the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other
llseek operation will report -EINVAL.
- If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all
+ If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all
cases. Userspace can use this to detect support for discovering the dma-buf
size using llseek.
@@ -119,6 +135,12 @@ DMA Buffer ioctls
.. kernel-doc:: include/uapi/linux/dma-buf.h
+DMA-BUF locking convention
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/dma-buf/dma-buf.c
+ :doc: locking convention
+
Kernel Functions and Structures Reference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -158,6 +180,12 @@ DMA Fence Signalling Annotations
.. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: fence signalling annotation
+DMA Fence Deadline Hints
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
+ :doc: deadline hints
+
DMA Fences Functions Reference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -191,8 +219,8 @@ DMA Fence unwrap
.. kernel-doc:: include/linux/dma-fence-unwrap.h
:internal:
-DMA Fence uABI/Sync File
-~~~~~~~~~~~~~~~~~~~~~~~~
+DMA Fence Sync File
+~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/dma-buf/sync_file.c
:export:
@@ -200,6 +228,12 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
+DMA Fence Sync File uABI
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/uapi/linux/sync_file.h
+ :internal:
+
Indefinite DMA Fences
~~~~~~~~~~~~~~~~~~~~~
@@ -258,7 +292,7 @@ through memory management dependencies which userspace is unaware of, which
randomly hangs workloads until the timeout kicks in. Workloads, which from
userspace's perspective, do not contain a deadlock. In such a mixed fencing
architecture there is no single entity with knowledge of all dependencies.
-Thefore preventing such deadlocks from within the kernel is not possible.
+Therefore preventing such deadlocks from within the kernel is not possible.
The only solution to avoid dependencies loops is by not allowing indefinite
fences in the kernel. This means:
diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
index bfd057b21a00..d491e385d61a 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -80,6 +80,10 @@ The details of these operations are:
- slave_sg: DMA a list of scatter gather buffers from/to a peripheral
+ - peripheral_dma_vec: DMA an array of scatter gather buffers from/to a
+ peripheral. Similar to slave_sg, but uses an array of dma_vec
+ structures instead of a scatterlist.
+
- dma_cyclic: Perform a cyclic DMA operation from/to a peripheral till the
operation is explicitly stopped.
@@ -102,6 +106,11 @@ The details of these operations are:
unsigned int sg_len, enum dma_data_direction direction,
unsigned long flags);
+ struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
+ struct dma_chan *chan, const struct dma_vec *vecs,
+ size_t nents, enum dma_data_direction direction,
+ unsigned long flags);
+
struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_data_direction direction);
@@ -175,7 +184,7 @@ The details of these operations are:
driver can ask for the pointer, maximum size and the currently used size of
the metadata and can directly update or read it.
- Becasue the DMA driver manages the memory area containing the metadata,
+ Because the DMA driver manages the memory area containing the metadata,
clients must make sure that they do not try to access or get the pointer
after their transfer completion callback has run for the descriptor.
If no completion callback has been defined for the transfer, then the
diff --git a/Documentation/driver-api/dmaengine/dmatest.rst b/Documentation/driver-api/dmaengine/dmatest.rst
index cf9859cd0b43..e2a63cefd783 100644
--- a/Documentation/driver-api/dmaengine/dmatest.rst
+++ b/Documentation/driver-api/dmaengine/dmatest.rst
@@ -89,7 +89,7 @@ The following command returns the state of the test. ::
% cat /sys/module/dmatest/parameters/run
-To wait for test completion userpace can poll 'run' until it is false, or use
+To wait for test completion userspace can poll 'run' until it is false, or use
the wait parameter. Specifying 'wait=1' when loading the module causes module
initialization to pause until a test run has completed, while reading
/sys/module/dmatest/parameters/wait waits for any running test to complete
diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst
index ceac2a300e32..1594598b3317 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -172,8 +172,8 @@ Currently, the types available are:
- It's usually used for copying pixel data between host memory and
memory-mapped GPU device memory, such as found on modern PCI video graphics
cards. The most immediate example is the OpenGL API function
- ``glReadPielx()``, which might require a verbatim copy of a huge framebuffer
- from local device memory onto host memory.
+ ``glReadPixels()``, which might require a verbatim copy of a huge
+ framebuffer from local device memory onto host memory.
- DMA_XOR
@@ -217,10 +217,12 @@ Currently, the types available are:
- DMA_ASYNC_TX
- - Must not be set by the device, and will be set by the framework
- if needed
+ - The device supports asynchronous memory-to-memory operations,
+ including memcpy, memset, xor, pq, xor_val, and pq_val.
- - TODO: What is it about?
+ - This capability is automatically set by the DMA engine
+ framework and must not be configured manually by device
+ drivers.
- DMA_SLAVE
@@ -433,6 +435,12 @@ supported.
- residue: Provides the residue bytes of the transfer for those that
support residue.
+- ``device_prep_peripheral_dma_vec``
+
+ - Similar to ``device_prep_slave_sg``, but it takes a pointer to a
+ array of ``dma_vec`` structures, which (in the long run) will replace
+ scatterlists.
+
- ``device_issue_pending``
- Takes the first transaction descriptor in the pending queue,
@@ -544,6 +552,10 @@ dma_cookie_t
- Not really relevant any more since the introduction of ``virt-dma``
that abstracts it away.
+dma_vec
+
+- A small structure that contains a DMA address and length.
+
DMA_CTRL_ACK
- If clear, the descriptor cannot be reused by provider until the
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
new file mode 100644
index 000000000000..83118c728ed9
--- /dev/null
+++ b/Documentation/driver-api/dpll.rst
@@ -0,0 +1,635 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================
+The Linux kernel dpll subsystem
+===============================
+
+DPLL
+====
+
+PLL - Phase Locked Loop is an electronic circuit which syntonizes clock
+signal of a device with an external clock signal. Effectively enabling
+device to run on the same clock signal beat as provided on a PLL input.
+
+DPLL - Digital Phase Locked Loop is an integrated circuit which in
+addition to plain PLL behavior incorporates a digital phase detector
+and may have digital divider in the loop. As a result, the frequency on
+DPLL's input and output may be configurable.
+
+Subsystem
+=========
+
+The main purpose of dpll subsystem is to provide general interface
+to configure devices that use any kind of Digital PLL and could use
+different sources of input signal to synchronize to, as well as
+different types of outputs.
+The main interface is NETLINK_GENERIC based protocol with an event
+monitoring multicast group defined.
+
+Device object
+=============
+
+Single dpll device object means single Digital PLL circuit and bunch of
+connected pins.
+It reports the supported modes of operation and current status to the
+user in response to the `do` request of netlink command
+``DPLL_CMD_DEVICE_GET`` and list of dplls registered in the subsystem
+with `dump` netlink request of the same command.
+Changing the configuration of dpll device is done with `do` request of
+netlink ``DPLL_CMD_DEVICE_SET`` command.
+A device handle is ``DPLL_A_ID``, it shall be provided to get or set
+configuration of particular device in the system. It can be obtained
+with a ``DPLL_CMD_DEVICE_GET`` `dump` request or
+a ``DPLL_CMD_DEVICE_ID_GET`` `do` request, where the one must provide
+attributes that result in single device match.
+
+Pin object
+==========
+
+A pin is amorphic object which represents either input or output, it
+could be internal component of the device, as well as externally
+connected.
+The number of pins per dpll vary, but usually multiple pins shall be
+provided for a single dpll device.
+Pin's properties, capabilities and status is provided to the user in
+response to `do` request of netlink ``DPLL_CMD_PIN_GET`` command.
+It is also possible to list all the pins that were registered in the
+system with `dump` request of ``DPLL_CMD_PIN_GET`` command.
+Configuration of a pin can be changed by `do` request of netlink
+``DPLL_CMD_PIN_SET`` command.
+Pin handle is a ``DPLL_A_PIN_ID``, it shall be provided to get or set
+configuration of particular pin in the system. It can be obtained with
+``DPLL_CMD_PIN_GET`` `dump` request or ``DPLL_CMD_PIN_ID_GET`` `do`
+request, where user provides attributes that result in single pin match.
+
+Pin selection
+=============
+
+In general, selected pin (the one which signal is driving the dpll
+device) can be obtained from ``DPLL_A_PIN_STATE`` attribute, and only
+one pin shall be in ``DPLL_PIN_STATE_CONNECTED`` state for any dpll
+device.
+
+Pin selection can be done either manually or automatically, depending
+on hardware capabilities and active dpll device work mode
+(``DPLL_A_MODE`` attribute). The consequence is that there are
+differences for each mode in terms of available pin states, as well as
+for the states the user can request for a dpll device.
+
+In manual mode (``DPLL_MODE_MANUAL``) the user can request or receive
+one of following pin states:
+
+- ``DPLL_PIN_STATE_CONNECTED`` - the pin is used to drive dpll device
+- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin is not used to drive dpll
+ device
+
+In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can request or
+receive one of following pin states:
+
+- ``DPLL_PIN_STATE_SELECTABLE`` - the pin shall be considered as valid
+ input for automatic selection algorithm
+- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin shall be not considered as
+ a valid input for automatic selection algorithm
+
+In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can only receive
+pin state ``DPLL_PIN_STATE_CONNECTED`` once automatic selection
+algorithm locks a dpll device with one of the inputs.
+
+Shared pins
+===========
+
+A single pin object can be attached to multiple dpll devices.
+Then there are two groups of configuration knobs:
+
+1) Set on a pin - the configuration affects all dpll devices pin is
+ registered to (i.e., ``DPLL_A_PIN_FREQUENCY``),
+2) Set on a pin-dpll tuple - the configuration affects only selected
+ dpll device (i.e., ``DPLL_A_PIN_PRIO``, ``DPLL_A_PIN_STATE``,
+ ``DPLL_A_PIN_DIRECTION``).
+
+MUX-type pins
+=============
+
+A pin can be MUX-type, it aggregates child pins and serves as a pin
+multiplexer. One or more pins are registered with MUX-type instead of
+being directly registered to a dpll device.
+Pins registered with a MUX-type pin provide user with additional nested
+attribute ``DPLL_A_PIN_PARENT_PIN`` for each parent they were registered
+with.
+If a pin was registered with multiple parent pins, they behave like a
+multiple output multiplexer. In this case output of a
+``DPLL_CMD_PIN_GET`` would contain multiple pin-parent nested
+attributes with current state related to each parent, like::
+
+ 'pin': [{{
+ 'clock-id': 282574471561216,
+ 'module-name': 'ice',
+ 'capabilities': 4,
+ 'id': 13,
+ 'parent-pin': [
+ {'parent-id': 2, 'state': 'connected'},
+ {'parent-id': 3, 'state': 'disconnected'}
+ ],
+ 'type': 'synce-eth-port'
+ }}]
+
+Only one child pin can provide its signal to the parent MUX-type pin at
+a time, the selection is done by requesting change of a child pin state
+on desired parent, with the use of ``DPLL_A_PIN_PARENT`` nested
+attribute. Example of netlink `set state on parent pin` message format:
+
+ ========================== =============================================
+ ``DPLL_A_PIN_ID`` child pin id
+ ``DPLL_A_PIN_PARENT_PIN`` nested attribute for requesting configuration
+ related to parent pin
+ ``DPLL_A_PIN_PARENT_ID`` parent pin id
+ ``DPLL_A_PIN_STATE`` requested pin state on parent
+ ========================== =============================================
+
+Pin priority
+============
+
+Some devices might offer a capability of automatic pin selection mode
+(enum value ``DPLL_MODE_AUTOMATIC`` of ``DPLL_A_MODE`` attribute).
+Usually, automatic selection is performed on the hardware level, which
+means only pins directly connected to the dpll can be used for automatic
+input pin selection.
+In automatic selection mode, the user cannot manually select a input
+pin for the device, instead the user shall provide all directly
+connected pins with a priority ``DPLL_A_PIN_PRIO``, the device would
+pick a highest priority valid signal and use it to control the DPLL
+device. Example of netlink `set priority on parent pin` message format:
+
+ ============================ =============================================
+ ``DPLL_A_PIN_ID`` configured pin id
+ ``DPLL_A_PIN_PARENT_DEVICE`` nested attribute for requesting configuration
+ related to parent dpll device
+ ``DPLL_A_PIN_PARENT_ID`` parent dpll device id
+ ``DPLL_A_PIN_PRIO`` requested pin prio on parent dpll
+ ============================ =============================================
+
+Child pin of MUX-type pin is not capable of automatic input pin selection,
+in order to configure active input of a MUX-type pin, the user needs to
+request desired pin state of the child pin on the parent pin,
+as described in the ``MUX-type pins`` chapter.
+
+Phase offset measurement and adjustment
+========================================
+
+Device may provide ability to measure a phase difference between signals
+on a pin and its parent dpll device. If pin-dpll phase offset measurement
+is supported, it shall be provided with ``DPLL_A_PIN_PHASE_OFFSET``
+attribute for each parent dpll device. The reported phase offset may be
+computed as the average of prior values and the current measurement, using
+the following formula:
+
+.. math::
+ curr\_avg = prev\_avg * \frac{2^N-1}{2^N} + new\_val * \frac{1}{2^N}
+
+where `curr_avg` is the current reported phase offset, `prev_avg` is the
+previously reported value, `new_val` is the current measurement, and `N` is
+the averaging factor. Configured averaging factor value is provided with
+``DPLL_A_PHASE_OFFSET_AVG_FACTOR`` attribute of a device and value change can
+be requested with the same attribute with ``DPLL_CMD_DEVICE_SET`` command.
+
+ ================================== ======================================
+ ``DPLL_A_PHASE_OFFSET_AVG_FACTOR`` attr configured value of phase offset
+ averaging factor
+ ================================== ======================================
+
+Device may also provide ability to adjust a signal phase on a pin.
+If pin phase adjustment is supported, minimal and maximal values and
+granularity that pin handle shall be provided to the user on
+``DPLL_CMD_PIN_GET`` respond with ``DPLL_A_PIN_PHASE_ADJUST_MIN``,
+``DPLL_A_PIN_PHASE_ADJUST_MAX`` and ``DPLL_A_PIN_PHASE_ADJUST_GRAN``
+attributes. Configured phase adjust value is provided with
+``DPLL_A_PIN_PHASE_ADJUST`` attribute of a pin, and value change can be
+requested with the same attribute with ``DPLL_CMD_PIN_SET`` command.
+
+ ================================ ==========================================
+ ``DPLL_A_PIN_ID`` configured pin id
+ ``DPLL_A_PIN_PHASE_ADJUST_GRAN`` attr granularity of phase adjustment value
+ ``DPLL_A_PIN_PHASE_ADJUST_MIN`` attr minimum value of phase adjustment
+ ``DPLL_A_PIN_PHASE_ADJUST_MAX`` attr maximum value of phase adjustment
+ ``DPLL_A_PIN_PHASE_ADJUST`` attr configured value of phase
+ adjustment on parent dpll device
+ ``DPLL_A_PIN_PARENT_DEVICE`` nested attribute for requesting
+ configuration on given parent dpll
+ device
+ ``DPLL_A_PIN_PARENT_ID`` parent dpll device id
+ ``DPLL_A_PIN_PHASE_OFFSET`` attr measured phase difference
+ between a pin and parent dpll device
+ ================================ ==========================================
+
+All phase related values are provided in pico seconds, which represents
+time difference between signals phase. The negative value means that
+phase of signal on pin is earlier in time than dpll's signal. Positive
+value means that phase of signal on pin is later in time than signal of
+a dpll.
+
+Phase adjust (also min and max) values are integers, but measured phase
+offset values are fractional with 3-digit decimal places and shell be
+divided with ``DPLL_PIN_PHASE_OFFSET_DIVIDER`` to get integer part and
+modulo divided to get fractional part.
+
+Phase offset monitor
+====================
+
+Phase offset measurement is typically performed against the current active
+source. However, some DPLL (Digital Phase-Locked Loop) devices may offer
+the capability to monitor phase offsets across all available inputs.
+The attribute and current feature state shall be included in the response
+message of the ``DPLL_CMD_DEVICE_GET`` command for supported DPLL devices.
+In such cases, users can also control the feature using the
+``DPLL_CMD_DEVICE_SET`` command by setting the ``enum dpll_feature_state``
+values for the attribute.
+Once enabled the phase offset measurements for the input shall be returned
+in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
+
+ =============================== ========================
+ ``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
+ =============================== ========================
+
+Embedded SYNC
+=============
+
+Device may provide ability to use Embedded SYNC feature. It allows
+to embed additional SYNC signal into the base frequency of a pin - a one
+special pulse of base frequency signal every time SYNC signal pulse
+happens. The user can configure the frequency of Embedded SYNC.
+The Embedded SYNC capability is always related to a given base frequency
+and HW capabilities. The user is provided a range of Embedded SYNC
+frequencies supported, depending on current base frequency configured for
+the pin.
+
+ ========================================= =================================
+ ``DPLL_A_PIN_ESYNC_FREQUENCY`` current Embedded SYNC frequency
+ ``DPLL_A_PIN_ESYNC_FREQUENCY_SUPPORTED`` nest available Embedded SYNC
+ frequency ranges
+ ``DPLL_A_PIN_FREQUENCY_MIN`` attr minimum value of frequency
+ ``DPLL_A_PIN_FREQUENCY_MAX`` attr maximum value of frequency
+ ``DPLL_A_PIN_ESYNC_PULSE`` pulse type of Embedded SYNC
+ ========================================= =================================
+
+Reference SYNC
+==============
+
+The device may support the Reference SYNC feature, which allows the combination
+of two inputs into a input pair. In this configuration, clock signals
+from both inputs are used to synchronize the DPLL device. The higher frequency
+signal is utilized for the loop bandwidth of the DPLL, while the lower frequency
+signal is used to syntonize the output signal of the DPLL device. This feature
+enables the provision of a high-quality loop bandwidth signal from an external
+source.
+
+A capable input provides a list of inputs that can be bound with to create
+Reference SYNC. To control this feature, the user must request a desired
+state for a target pin: use ``DPLL_PIN_STATE_CONNECTED`` to enable or
+``DPLL_PIN_STATE_DISCONNECTED`` to disable the feature. An input pin can be
+bound to only one other pin at any given time.
+
+ ============================== ==========================================
+ ``DPLL_A_PIN_REFERENCE_SYNC`` nested attribute for providing info or
+ requesting configuration of the Reference
+ SYNC feature
+ ``DPLL_A_PIN_ID`` target pin id for Reference SYNC feature
+ ``DPLL_A_PIN_STATE`` state of Reference SYNC connection
+ ============================== ==========================================
+
+Configuration commands group
+============================
+
+Configuration commands are used to get information about registered
+dpll devices (and pins), as well as set configuration of device or pins.
+As dpll devices must be abstracted and reflect real hardware,
+there is no way to add new dpll device via netlink from user space and
+each device should be registered by its driver.
+
+All netlink commands require ``GENL_ADMIN_PERM``. This is to prevent
+any spamming/DoS from unauthorized userspace applications.
+
+List of netlink commands with possible attributes
+=================================================
+
+Constants identifying command types for dpll device uses a
+``DPLL_CMD_`` prefix and suffix according to command purpose.
+The dpll device related attributes use a ``DPLL_A_`` prefix and
+suffix according to attribute purpose.
+
+ ==================================== =================================
+ ``DPLL_CMD_DEVICE_ID_GET`` command to get device ID
+ ``DPLL_A_MODULE_NAME`` attr module name of registerer
+ ``DPLL_A_CLOCK_ID`` attr Unique Clock Identifier
+ (EUI-64), as defined by the
+ IEEE 1588 standard
+ ``DPLL_A_TYPE`` attr type of dpll device
+ ==================================== =================================
+
+ ==================================== =================================
+ ``DPLL_CMD_DEVICE_GET`` command to get device info or
+ dump list of available devices
+ ``DPLL_A_ID`` attr unique dpll device ID
+ ``DPLL_A_MODULE_NAME`` attr module name of registerer
+ ``DPLL_A_CLOCK_ID`` attr Unique Clock Identifier
+ (EUI-64), as defined by the
+ IEEE 1588 standard
+ ``DPLL_A_MODE`` attr selection mode
+ ``DPLL_A_MODE_SUPPORTED`` attr available selection modes
+ ``DPLL_A_LOCK_STATUS`` attr dpll device lock status
+ ``DPLL_A_TEMP`` attr device temperature info
+ ``DPLL_A_TYPE`` attr type of dpll device
+ ==================================== =================================
+
+ ==================================== =================================
+ ``DPLL_CMD_DEVICE_SET`` command to set dpll device config
+ ``DPLL_A_ID`` attr internal dpll device index
+ ``DPLL_A_MODE`` attr selection mode to configure
+ ==================================== =================================
+
+Constants identifying command types for pins uses a
+``DPLL_CMD_PIN_`` prefix and suffix according to command purpose.
+The pin related attributes use a ``DPLL_A_PIN_`` prefix and suffix
+according to attribute purpose.
+
+ ==================================== =================================
+ ``DPLL_CMD_PIN_ID_GET`` command to get pin ID
+ ``DPLL_A_PIN_MODULE_NAME`` attr module name of registerer
+ ``DPLL_A_PIN_CLOCK_ID`` attr Unique Clock Identifier
+ (EUI-64), as defined by the
+ IEEE 1588 standard
+ ``DPLL_A_PIN_BOARD_LABEL`` attr pin board label provided
+ by registerer
+ ``DPLL_A_PIN_PANEL_LABEL`` attr pin panel label provided
+ by registerer
+ ``DPLL_A_PIN_PACKAGE_LABEL`` attr pin package label provided
+ by registerer
+ ``DPLL_A_PIN_TYPE`` attr type of a pin
+ ==================================== =================================
+
+ ==================================== ==================================
+ ``DPLL_CMD_PIN_GET`` command to get pin info or dump
+ list of available pins
+ ``DPLL_A_PIN_ID`` attr unique a pin ID
+ ``DPLL_A_PIN_MODULE_NAME`` attr module name of registerer
+ ``DPLL_A_PIN_CLOCK_ID`` attr Unique Clock Identifier
+ (EUI-64), as defined by the
+ IEEE 1588 standard
+ ``DPLL_A_PIN_BOARD_LABEL`` attr pin board label provided
+ by registerer
+ ``DPLL_A_PIN_PANEL_LABEL`` attr pin panel label provided
+ by registerer
+ ``DPLL_A_PIN_PACKAGE_LABEL`` attr pin package label provided
+ by registerer
+ ``DPLL_A_PIN_TYPE`` attr type of a pin
+ ``DPLL_A_PIN_FREQUENCY`` attr current frequency of a pin
+ ``DPLL_A_PIN_FREQUENCY_SUPPORTED`` nested attr provides supported
+ frequencies
+ ``DPLL_A_PIN_ANY_FREQUENCY_MIN`` attr minimum value of frequency
+ ``DPLL_A_PIN_ANY_FREQUENCY_MAX`` attr maximum value of frequency
+ ``DPLL_A_PIN_PHASE_ADJUST_GRAN`` attr granularity of phase
+ adjustment value
+ ``DPLL_A_PIN_PHASE_ADJUST_MIN`` attr minimum value of phase
+ adjustment
+ ``DPLL_A_PIN_PHASE_ADJUST_MAX`` attr maximum value of phase
+ adjustment
+ ``DPLL_A_PIN_PHASE_ADJUST`` attr configured value of phase
+ adjustment on parent device
+ ``DPLL_A_PIN_PARENT_DEVICE`` nested attr for each parent device
+ the pin is connected with
+ ``DPLL_A_PIN_PARENT_ID`` attr parent dpll device id
+ ``DPLL_A_PIN_PRIO`` attr priority of pin on the
+ dpll device
+ ``DPLL_A_PIN_STATE`` attr state of pin on the parent
+ dpll device
+ ``DPLL_A_PIN_DIRECTION`` attr direction of a pin on the
+ parent dpll device
+ ``DPLL_A_PIN_PHASE_OFFSET`` attr measured phase difference
+ between a pin and parent dpll
+ ``DPLL_A_PIN_PARENT_PIN`` nested attr for each parent pin
+ the pin is connected with
+ ``DPLL_A_PIN_PARENT_ID`` attr parent pin id
+ ``DPLL_A_PIN_STATE`` attr state of pin on the parent
+ pin
+ ``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities
+ ==================================== ==================================
+
+ ==================================== =================================
+ ``DPLL_CMD_PIN_SET`` command to set pins configuration
+ ``DPLL_A_PIN_ID`` attr unique a pin ID
+ ``DPLL_A_PIN_FREQUENCY`` attr requested frequency of a pin
+ ``DPLL_A_PIN_PHASE_ADJUST`` attr requested value of phase
+ adjustment on parent device
+ ``DPLL_A_PIN_PARENT_DEVICE`` nested attr for each parent dpll
+ device configuration request
+ ``DPLL_A_PIN_PARENT_ID`` attr parent dpll device id
+ ``DPLL_A_PIN_DIRECTION`` attr requested direction of a pin
+ ``DPLL_A_PIN_PRIO`` attr requested priority of pin on
+ the dpll device
+ ``DPLL_A_PIN_STATE`` attr requested state of pin on
+ the dpll device
+ ``DPLL_A_PIN_PARENT_PIN`` nested attr for each parent pin
+ configuration request
+ ``DPLL_A_PIN_PARENT_ID`` attr parent pin id
+ ``DPLL_A_PIN_STATE`` attr requested state of pin on
+ parent pin
+ ==================================== =================================
+
+Netlink dump requests
+=====================
+
+The ``DPLL_CMD_DEVICE_GET`` and ``DPLL_CMD_PIN_GET`` commands are
+capable of dump type netlink requests, in which case the response is in
+the same format as for their ``do`` request, but every device or pin
+registered in the system is returned.
+
+SET commands format
+===================
+
+``DPLL_CMD_DEVICE_SET`` - to target a dpll device, the user provides
+``DPLL_A_ID``, which is unique identifier of dpll device in the system,
+as well as parameter being configured (``DPLL_A_MODE``).
+
+``DPLL_CMD_PIN_SET`` - to target a pin user must provide a
+``DPLL_A_PIN_ID``, which is unique identifier of a pin in the system.
+Also configured pin parameters must be added.
+If ``DPLL_A_PIN_FREQUENCY`` is configured, this affects all the dpll
+devices that are connected with the pin, that is why frequency attribute
+shall not be enclosed in ``DPLL_A_PIN_PARENT_DEVICE``.
+Other attributes: ``DPLL_A_PIN_PRIO``, ``DPLL_A_PIN_STATE`` or
+``DPLL_A_PIN_DIRECTION`` must be enclosed in
+``DPLL_A_PIN_PARENT_DEVICE`` as their configuration relates to only one
+of parent dplls, targeted by ``DPLL_A_PIN_PARENT_ID`` attribute which is
+also required inside that nest.
+For MUX-type pins the ``DPLL_A_PIN_STATE`` attribute is configured in
+similar way, by enclosing required state in ``DPLL_A_PIN_PARENT_PIN``
+nested attribute and targeted parent pin id in ``DPLL_A_PIN_PARENT_ID``.
+
+In general, it is possible to configure multiple parameters at once, but
+internally each parameter change will be invoked separately, where order
+of configuration is not guaranteed by any means.
+
+Configuration pre-defined enums
+===============================
+
+.. kernel-doc:: include/uapi/linux/dpll.h
+
+Notifications
+=============
+
+dpll device can provide notifications regarding status changes of the
+device, i.e. lock status changes, input/output changes or other alarms.
+There is one multicast group that is used to notify user-space apps via
+netlink socket: ``DPLL_MCGRP_MONITOR``
+
+Notifications messages:
+
+ ============================== =====================================
+ ``DPLL_CMD_DEVICE_CREATE_NTF`` dpll device was created
+ ``DPLL_CMD_DEVICE_DELETE_NTF`` dpll device was deleted
+ ``DPLL_CMD_DEVICE_CHANGE_NTF`` dpll device has changed
+ ``DPLL_CMD_PIN_CREATE_NTF`` dpll pin was created
+ ``DPLL_CMD_PIN_DELETE_NTF`` dpll pin was deleted
+ ``DPLL_CMD_PIN_CHANGE_NTF`` dpll pin has changed
+ ============================== =====================================
+
+Events format is the same as for the corresponding get command.
+Format of ``DPLL_CMD_DEVICE_`` events is the same as response of
+``DPLL_CMD_DEVICE_GET``.
+Format of ``DPLL_CMD_PIN_`` events is same as response of
+``DPLL_CMD_PIN_GET``.
+
+Device driver implementation
+============================
+
+Device is allocated by dpll_device_get() call. Second call with the
+same arguments will not create new object but provides pointer to
+previously created device for given arguments, it also increases
+refcount of that object.
+Device is deallocated by dpll_device_put() call, which first
+decreases the refcount, once refcount is cleared the object is
+destroyed.
+
+Device should implement set of operations and register device via
+dpll_device_register() at which point it becomes available to the
+users. Multiple driver instances can obtain reference to it with
+dpll_device_get(), as well as register dpll device with their own
+ops and priv.
+
+The pins are allocated separately with dpll_pin_get(), it works
+similarly to dpll_device_get(). Function first creates object and then
+for each call with the same arguments only the object refcount
+increases. Also dpll_pin_put() works similarly to dpll_device_put().
+
+A pin can be registered with parent dpll device or parent pin, depending
+on hardware needs. Each registration requires registerer to provide set
+of pin callbacks, and private data pointer for calling them:
+
+- dpll_pin_register() - register pin with a dpll device,
+- dpll_pin_on_pin_register() - register pin with another MUX type pin.
+
+Notifications of adding or removing dpll devices are created within
+subsystem itself.
+Notifications about registering/deregistering pins are also invoked by
+the subsystem.
+Notifications about status changes either of dpll device or a pin are
+invoked in two ways:
+
+- after successful change was requested on dpll subsystem, the subsystem
+ calls corresponding notification,
+- requested by device driver with dpll_device_change_ntf() or
+ dpll_pin_change_ntf() when driver informs about the status change.
+
+The device driver using dpll interface is not required to implement all
+the callback operation. Nevertheless, there are few required to be
+implemented.
+Required dpll device level callback operations:
+
+- ``.mode_get``,
+- ``.lock_status_get``.
+
+Required pin level callback operations:
+
+- ``.state_on_dpll_get`` (pins registered with dpll device),
+- ``.state_on_pin_get`` (pins registered with parent pin),
+- ``.direction_get``.
+
+Every other operation handler is checked for existence and
+``-EOPNOTSUPP`` is returned in case of absence of specific handler.
+
+The simplest implementation is in the OCP TimeCard driver. The ops
+structures are defined like this:
+
+.. code-block:: c
+
+ static const struct dpll_device_ops dpll_ops = {
+ .lock_status_get = ptp_ocp_dpll_lock_status_get,
+ .mode_get = ptp_ocp_dpll_mode_get,
+ .mode_supported = ptp_ocp_dpll_mode_supported,
+ };
+
+ static const struct dpll_pin_ops dpll_pins_ops = {
+ .frequency_get = ptp_ocp_dpll_frequency_get,
+ .frequency_set = ptp_ocp_dpll_frequency_set,
+ .direction_get = ptp_ocp_dpll_direction_get,
+ .direction_set = ptp_ocp_dpll_direction_set,
+ .state_on_dpll_get = ptp_ocp_dpll_state_get,
+ };
+
+The registration part is then looks like this part:
+
+.. code-block:: c
+
+ clkid = pci_get_dsn(pdev);
+ bp->dpll = dpll_device_get(clkid, 0, THIS_MODULE);
+ if (IS_ERR(bp->dpll)) {
+ err = PTR_ERR(bp->dpll);
+ dev_err(&pdev->dev, "dpll_device_alloc failed\n");
+ goto out;
+ }
+
+ err = dpll_device_register(bp->dpll, DPLL_TYPE_PPS, &dpll_ops, bp);
+ if (err)
+ goto out;
+
+ for (i = 0; i < OCP_SMA_NUM; i++) {
+ bp->sma[i].dpll_pin = dpll_pin_get(clkid, i, THIS_MODULE, &bp->sma[i].dpll_prop);
+ if (IS_ERR(bp->sma[i].dpll_pin)) {
+ err = PTR_ERR(bp->dpll);
+ goto out_dpll;
+ }
+
+ err = dpll_pin_register(bp->dpll, bp->sma[i].dpll_pin, &dpll_pins_ops,
+ &bp->sma[i]);
+ if (err) {
+ dpll_pin_put(bp->sma[i].dpll_pin);
+ goto out_dpll;
+ }
+ }
+
+In the error path we have to rewind every allocation in the reverse order:
+
+.. code-block:: c
+
+ while (i) {
+ --i;
+ dpll_pin_unregister(bp->dpll, bp->sma[i].dpll_pin, &dpll_pins_ops, &bp->sma[i]);
+ dpll_pin_put(bp->sma[i].dpll_pin);
+ }
+ dpll_device_put(bp->dpll);
+
+More complex example can be found in Intel's ICE driver or nVidia's mlx5 driver.
+
+SyncE enablement
+================
+For SyncE enablement it is required to allow control over dpll device
+for a software application which monitors and configures the inputs of
+dpll device in response to current state of a dpll device and its
+inputs.
+In such scenario, dpll device input signal shall be also configurable
+to drive dpll with signal recovered from the PHY netdevice.
+This is done by exposing a pin to the netdevice - attaching pin to the
+netdevice itself with
+``dpll_netdev_pin_set(struct net_device *dev, struct dpll_pin *dpll_pin)``.
+Exposed pin id handle ``DPLL_A_PIN_ID`` is then identifiable by the user
+as it is attached to rtnetlink respond to get ``RTM_NEWLINK`` command in
+nested attribute ``IFLA_DPLL_PIN``.
diff --git a/Documentation/driver-api/driver-model/bus.rst b/Documentation/driver-api/driver-model/bus.rst
index 016b15a6e8ea..9709ab62a468 100644
--- a/Documentation/driver-api/driver-model/bus.rst
+++ b/Documentation/driver-api/driver-model/bus.rst
@@ -125,8 +125,8 @@ Exporting Attributes
struct bus_attribute {
struct attribute attr;
- ssize_t (*show)(struct bus_type *, char * buf);
- ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
+ ssize_t (*show)(const struct bus_type *, char * buf);
+ ssize_t (*store)(const struct bus_type *, const char * buf, size_t count);
};
Bus drivers can export attributes using the BUS_ATTR_RW macro that works
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index 5e6de4ab25dc..0198ac65e874 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -275,10 +275,10 @@ GPIO
devm_gpiod_put()
devm_gpiod_unhinge()
devm_gpiochip_add_data()
- devm_gpio_request()
devm_gpio_request_one()
I2C
+ devm_i2c_add_adapter()
devm_i2c_new_dummy_device()
IIO
@@ -286,12 +286,16 @@ IIO
devm_iio_device_register()
devm_iio_dmaengine_buffer_setup()
devm_iio_kfifo_buffer_setup()
+ devm_iio_kfifo_buffer_setup_ext()
devm_iio_map_array_register()
devm_iio_triggered_buffer_setup()
+ devm_iio_triggered_buffer_setup_ext()
devm_iio_trigger_alloc()
devm_iio_trigger_register()
devm_iio_channel_get()
devm_iio_channel_get_all()
+ devm_iio_hw_consumer_alloc()
+ devm_fwnode_iio_channel_get_by_name()
INPUT
devm_input_allocate_device()
@@ -311,17 +315,14 @@ IOMAP
devm_ioremap()
devm_ioremap_uc()
devm_ioremap_wc()
- devm_ioremap_np()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_ioremap_resource_wc()
devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device
devm_platform_ioremap_resource_byname()
devm_platform_get_and_ioremap_resource()
devm_iounmap()
- pcim_iomap()
- pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
- pcim_iomap_table() : array of mapped addresses indexed by BAR
- pcim_iounmap()
+
+ Note: For the PCI devices the specific pcim_*() functions may be used, see below.
IRQ
devm_free_irq()
@@ -339,7 +340,10 @@ IRQ
LED
devm_led_classdev_register()
+ devm_led_classdev_register_ext()
devm_led_classdev_unregister()
+ devm_led_trigger_register()
+ devm_of_led_get()
MDIO
devm_mdiobus_alloc()
@@ -357,7 +361,9 @@ MEM
devm_kmalloc_array()
devm_kmemdup()
devm_krealloc()
+ devm_krealloc_array()
devm_kstrdup()
+ devm_kstrdup_const()
devm_kvasprintf()
devm_kzalloc()
@@ -377,18 +383,24 @@ NET
PER-CPU MEM
devm_alloc_percpu()
- devm_free_percpu()
PCI
devm_pci_alloc_host_bridge() : managed PCI host bridge allocation
devm_pci_remap_cfgspace() : ioremap PCI configuration space
devm_pci_remap_cfg_resource() : ioremap PCI configuration space resource
- pcim_enable_device() : after success, all PCI ops become managed
+
+ pcim_enable_device() : after success, the PCI device gets disabled automatically on driver detach
+ pcim_iomap() : do iomap() on a single BAR
+ pcim_iomap_regions() : do request_region() and iomap() on multiple BARs
+ pcim_iomap_table() : array of mapped addresses indexed by BAR
+ pcim_iounmap() : do iounmap() on a single BAR
pcim_pin_device() : keep PCI device enabled after release
+ pcim_set_mwi() : enable Memory-Write-Invalidate PCI transaction
PHY
devm_usb_get_phy()
- devm_usb_put_phy()
+ devm_usb_get_phy_by_node()
+ devm_usb_get_phy_by_phandle()
PINCTRL
devm_pinctrl_get()
@@ -403,16 +415,20 @@ POWER
devm_reboot_mode_unregister()
PWM
+ devm_pwmchip_alloc()
+ devm_pwmchip_add()
devm_pwm_get()
devm_fwnode_pwm_get()
REGULATOR
devm_regulator_bulk_register_supply_alias()
devm_regulator_bulk_get()
+ devm_regulator_bulk_get_const()
devm_regulator_bulk_get_enable()
devm_regulator_bulk_put()
devm_regulator_get()
devm_regulator_get_enable()
+ devm_regulator_get_enable_read_voltage()
devm_regulator_get_enable_optional()
devm_regulator_get_exclusive()
devm_regulator_get_optional()
@@ -440,9 +456,12 @@ SLAVE DMA ENGINE
devm_acpi_dma_controller_register()
SPI
- devm_spi_alloc_master()
- devm_spi_alloc_slave()
- devm_spi_register_master()
+ devm_spi_alloc_host()
+ devm_spi_alloc_target()
+ devm_spi_optimize_message()
+ devm_spi_register_controller()
+ devm_spi_register_host()
+ devm_spi_register_target()
WATCHDOG
devm_watchdog_register_device()
diff --git a/Documentation/driver-api/driver-model/overview.rst b/Documentation/driver-api/driver-model/overview.rst
index e98d0ab4a9b6..b3f447bf9f07 100644
--- a/Documentation/driver-api/driver-model/overview.rst
+++ b/Documentation/driver-api/driver-model/overview.rst
@@ -22,7 +22,7 @@ uniformity across the different bus types.
The current driver model provides a common, uniform data model for describing
a bus and the devices that can appear under the bus. The unified bus
-model includes a set of common attributes which all busses carry, and a set
+model includes a set of common attributes which all buses carry, and a set
of common callbacks, such as device discovery during bus probing, bus
shutdown, bus power management, etc.
diff --git a/Documentation/driver-api/driver-model/platform.rst b/Documentation/driver-api/driver-model/platform.rst
index 1fe5c6c6199c..cf5ff48d3115 100644
--- a/Documentation/driver-api/driver-model/platform.rst
+++ b/Documentation/driver-api/driver-model/platform.rst
@@ -4,7 +4,7 @@ Platform Devices and Drivers
See <linux/platform_device.h> for the driver model interface to the
platform bus: platform_device, and platform_driver. This pseudo-bus
-is used to connect devices on busses with minimal infrastructure,
+is used to connect devices on buses with minimal infrastructure,
like those used to integrate peripherals on many system-on-chip
processors, or some "legacy" PC interconnects; as opposed to large
formally specified ones like PCI or USB.
@@ -41,13 +41,14 @@ and shutdown notifications using the standard conventions::
struct platform_driver {
int (*probe)(struct platform_device *);
- int (*remove)(struct platform_device *);
+ void (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
- int (*suspend_late)(struct platform_device *, pm_message_t state);
- int (*resume_early)(struct platform_device *);
int (*resume)(struct platform_device *);
struct device_driver driver;
+ const struct platform_device_id *id_table;
+ bool prevent_deferred_probe;
+ bool driver_managed_dma;
};
Note that probe() should in general verify that the specified device hardware
diff --git a/Documentation/driver-api/early-userspace/buffer-format.rst b/Documentation/driver-api/early-userspace/buffer-format.rst
index 7f74e301fdf3..4597a91100b7 100644
--- a/Documentation/driver-api/early-userspace/buffer-format.rst
+++ b/Documentation/driver-api/early-userspace/buffer-format.rst
@@ -4,20 +4,18 @@ initramfs buffer format
Al Viro, H. Peter Anvin
-Last revision: 2002-01-13
-
-Starting with kernel 2.5.x, the old "initial ramdisk" protocol is
-getting {replaced/complemented} with the new "initial ramfs"
-(initramfs) protocol. The initramfs contents is passed using the same
-memory buffer protocol used by the initrd protocol, but the contents
+With kernel 2.5.x, the old "initial ramdisk" protocol was complemented
+with an "initial ramfs" protocol. The initramfs content is passed
+using the same memory buffer protocol used by initrd, but the content
is different. The initramfs buffer contains an archive which is
-expanded into a ramfs filesystem; this document details the format of
-the initramfs buffer format.
+expanded into a ramfs filesystem; this document details the initramfs
+buffer format.
The initramfs buffer format is based around the "newc" or "crc" CPIO
formats, and can be created with the cpio(1) utility. The cpio
-archive can be compressed using gzip(1). One valid version of an
-initramfs buffer is thus a single .cpio.gz file.
+archive can be compressed using gzip(1), or any other algorithm provided
+via CONFIG_DECOMPRESS_*. One valid version of an initramfs buffer is
+thus a single .cpio.gz file.
The full format of the initramfs buffer is defined by the following
grammar, where::
@@ -25,12 +23,20 @@ grammar, where::
* is used to indicate "0 or more occurrences of"
(|) indicates alternatives
+ indicates concatenation
- GZIP() indicates the gzip(1) of the operand
+ GZIP() indicates gzip compression of the operand
+ BZIP2() indicates bzip2 compression of the operand
+ LZMA() indicates lzma compression of the operand
+ XZ() indicates xz compression of the operand
+ LZO() indicates lzo compression of the operand
+ LZ4() indicates lz4 compression of the operand
+ ZSTD() indicates zstd compression of the operand
ALGN(n) means padding with null bytes to an n-byte boundary
- initramfs := ("\0" | cpio_archive | cpio_gzip_archive)*
+ initramfs := ("\0" | cpio_archive | cpio_compressed_archive)*
- cpio_gzip_archive := GZIP(cpio_archive)
+ cpio_compressed_archive := (GZIP(cpio_archive) | BZIP2(cpio_archive)
+ | LZMA(cpio_archive) | XZ(cpio_archive) | LZO(cpio_archive)
+ | LZ4(cpio_archive) | ZSTD(cpio_archive))
cpio_archive := cpio_file* + (<nothing> | cpio_trailer)
@@ -75,9 +81,16 @@ c_chksum 8 bytes Checksum of data field if c_magic is 070702;
The c_mode field matches the contents of st_mode returned by stat(2)
on Linux, and encodes the file type and file permissions.
+c_mtime is ignored unless CONFIG_INITRAMFS_PRESERVE_MTIME=y is set.
+
The c_filesize should be zero for any file which is not a regular file
or symlink.
+c_namesize may account for more than one trailing '\0', as long as the
+value doesn't exceed PATH_MAX. This can be useful for ensuring that a
+subsequent file data segment is aligned, e.g. to a filesystem block
+boundary.
+
The c_chksum field contains a simple 32-bit unsigned sum of all the
bytes in the data field. cpio(1) refers to this as "crc", which is
clearly incorrect (a cyclic redundancy check is a different and
diff --git a/Documentation/driver-api/edac.rst b/Documentation/driver-api/edac.rst
index b8c742aa0a71..f4f044b95c4f 100644
--- a/Documentation/driver-api/edac.rst
+++ b/Documentation/driver-api/edac.rst
@@ -106,6 +106,16 @@ will occupy those chip-select rows.
This term is avoided because it is unclear when needing to distinguish
between chip-select rows and socket sets.
+* High Bandwidth Memory (HBM)
+
+HBM is a new memory type with low power consumption and ultra-wide
+communication lanes. It uses vertically stacked memory chips (DRAM dies)
+interconnected by microscopic wires called "through-silicon vias," or
+TSVs.
+
+Several stacks of HBM chips connect to the CPU or GPU through an ultra-fast
+interconnect called the "interposer". Therefore, HBM's characteristics
+are nearly indistinguishable from on-chip integrated RAM.
Memory Controllers
------------------
@@ -176,3 +186,113 @@ nodes::
the L1 and L2 directories would be "edac_device_block's"
.. kernel-doc:: drivers/edac/edac_device.h
+
+
+Heterogeneous system support
+----------------------------
+
+An AMD heterogeneous system is built by connecting the data fabrics of
+both CPUs and GPUs via custom xGMI links. Thus, the data fabric on the
+GPU nodes can be accessed the same way as the data fabric on CPU nodes.
+
+The MI200 accelerators are data center GPUs. They have 2 data fabrics,
+and each GPU data fabric contains four Unified Memory Controllers (UMC).
+Each UMC contains eight channels. Each UMC channel controls one 128-bit
+HBM2e (2GB) channel (equivalent to 8 X 2GB ranks). This creates a total
+of 4096-bits of DRAM data bus.
+
+While the UMC is interfacing a 16GB (8high X 2GB DRAM) HBM stack, each UMC
+channel is interfacing 2GB of DRAM (represented as rank).
+
+Memory controllers on AMD GPU nodes can be represented in EDAC thusly:
+
+ GPU DF / GPU Node -> EDAC MC
+ GPU UMC -> EDAC CSROW
+ GPU UMC channel -> EDAC CHANNEL
+
+For example: a heterogeneous system with 1 AMD CPU is connected to
+4 MI200 (Aldebaran) GPUs using xGMI.
+
+Some more heterogeneous hardware details:
+
+- The CPU UMC (Unified Memory Controller) is mostly the same as the GPU UMC.
+ They have chip selects (csrows) and channels. However, the layouts are different
+ for performance, physical layout, or other reasons.
+- CPU UMCs use 1 channel, In this case UMC = EDAC channel. This follows the
+ marketing speak. CPU has X memory channels, etc.
+- CPU UMCs use up to 4 chip selects, So UMC chip select = EDAC CSROW.
+- GPU UMCs use 1 chip select, So UMC = EDAC CSROW.
+- GPU UMCs use 8 channels, So UMC channel = EDAC channel.
+
+The EDAC subsystem provides a mechanism to handle AMD heterogeneous
+systems by calling system specific ops for both CPUs and GPUs.
+
+AMD GPU nodes are enumerated in sequential order based on the PCI
+hierarchy, and the first GPU node is assumed to have a Node ID value
+following those of the CPU nodes after latter are fully populated::
+
+ $ ls /sys/devices/system/edac/mc/
+ mc0 - CPU MC node 0
+ mc1 |
+ mc2 |- GPU card[0] => node 0(mc1), node 1(mc2)
+ mc3 |
+ mc4 |- GPU card[1] => node 0(mc3), node 1(mc4)
+ mc5 |
+ mc6 |- GPU card[2] => node 0(mc5), node 1(mc6)
+ mc7 |
+ mc8 |- GPU card[3] => node 0(mc7), node 1(mc8)
+
+For example, a heterogeneous system with one AMD CPU is connected to
+four MI200 (Aldebaran) GPUs using xGMI. This topology can be represented
+via the following sysfs entries::
+
+ /sys/devices/system/edac/mc/..
+
+ CPU # CPU node
+ ├── mc 0
+
+ GPU Nodes are enumerated sequentially after CPU nodes have been populated
+ GPU card 1 # Each MI200 GPU has 2 nodes/mcs
+ ├── mc 1 # GPU node 0 == mc1, Each MC node has 4 UMCs/CSROWs
+ │   ├── csrow 0 # UMC 0
+ │   │   ├── channel 0 # Each UMC has 8 channels
+ │   │   ├── channel 1 # size of each channel is 2 GB, so each UMC has 16 GB
+ │   │   ├── channel 2
+ │   │   ├── channel 3
+ │   │   ├── channel 4
+ │   │   ├── channel 5
+ │   │   ├── channel 6
+ │   │   ├── channel 7
+ │   ├── csrow 1 # UMC 1
+ │   │   ├── channel 0
+ │   │   ├── ..
+ │   │   ├── channel 7
+ │   ├── .. ..
+ │   ├── csrow 3 # UMC 3
+ │   │   ├── channel 0
+ │   │   ├── ..
+ │   │   ├── channel 7
+ │   ├── rank 0
+ │   ├── .. ..
+ │   ├── rank 31 # total 32 ranks/dimms from 4 UMCs
+ ├
+ ├── mc 2 # GPU node 1 == mc2
+ │   ├── .. # each GPU has total 64 GB
+
+ GPU card 2
+ ├── mc 3
+ │   ├── ..
+ ├── mc 4
+ │   ├── ..
+
+ GPU card 3
+ ├── mc 5
+ │   ├── ..
+ ├── mc 6
+ │   ├── ..
+
+ GPU card 4
+ ├── mc 7
+ │   ├── ..
+ ├── mc 8
+ │   ├── ..
diff --git a/Documentation/driver-api/eisa.rst b/Documentation/driver-api/eisa.rst
index c07565ba57da..3563e5f7e98d 100644
--- a/Documentation/driver-api/eisa.rst
+++ b/Documentation/driver-api/eisa.rst
@@ -8,9 +8,9 @@ This document groups random notes about porting EISA drivers to the
new EISA/sysfs API.
Starting from version 2.5.59, the EISA bus is almost given the same
-status as other much more mainstream busses such as PCI or USB. This
+status as other much more mainstream buses such as PCI or USB. This
has been possible through sysfs, which defines a nice enough set of
-abstractions to manage busses, devices and drivers.
+abstractions to manage buses, devices and drivers.
Although the new API is quite simple to use, converting existing
drivers to the new infrastructure is not an easy task (mostly because
@@ -189,15 +189,15 @@ eisa_bus.enable_dev
initialize the device in such conditions.
eisa_bus.disable_dev
- A comma-separated list of slots to be enabled, even if the firmware
+ A comma-separated list of slots to be disabled, even if the firmware
set the card as enabled. The driver won't be called to handle this
device.
virtual_root.force_probe
Force the probing code to probe EISA slots even when it cannot find an
EISA compliant mainboard (nothing appears on slot 0). Defaults to 0
- (don't force), and set to 1 (force probing) when either
- CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
+ (don't force), and set to 1 (force probing) when
+ CONFIG_EISA_VLB_PRIMING is set.
Random notes
============
@@ -205,7 +205,7 @@ Random notes
Converting an EISA driver to the new API mostly involves *deleting*
code (since probing is now in the core EISA code). Unfortunately, most
drivers share their probing routine between ISA, and EISA. Special
-care must be taken when ripping out the EISA code, so other busses
+care must be taken when ripping out the EISA code, so other buses
won't suffer from these surgical strikes...
You *must not* expect any EISA device to be detected when returning
diff --git a/Documentation/driver-api/extcon.rst b/Documentation/driver-api/extcon.rst
new file mode 100644
index 000000000000..d3217b9cdcd5
--- /dev/null
+++ b/Documentation/driver-api/extcon.rst
@@ -0,0 +1,255 @@
+=======================
+Extcon Device Subsystem
+=======================
+
+Overview
+========
+
+The Extcon (External Connector) subsystem provides a unified framework for
+managing external connectors in Linux systems. It allows drivers to report
+the state of external connectors and provides a standardized interface for
+userspace to query and monitor these states.
+
+Extcon is particularly useful in modern devices with multiple connectivity
+options, such as smartphones, tablets, and laptops. It helps manage various
+types of connectors, including:
+
+1. USB connectors (e.g., USB-C, micro-USB)
+2. Charging ports (e.g., fast charging, wireless charging)
+3. Audio jacks (e.g., 3.5mm headphone jack)
+4. Video outputs (e.g., HDMI, DisplayPort)
+5. Docking stations
+
+Real-world examples:
+
+1. Smartphone USB-C port:
+ A single USB-C port on a smartphone can serve multiple functions. Extcon
+ can manage the different states of this port, such as:
+ - USB data connection
+ - Charging (various types like fast charging, USB Power Delivery)
+ - Audio output (USB-C headphones)
+ - Video output (USB-C to HDMI adapter)
+
+2. Laptop docking station:
+ When a laptop is connected to a docking station, multiple connections are
+ made simultaneously. Extcon can handle the state changes for:
+ - Power delivery
+ - External displays
+ - USB hub connections
+ - Ethernet connectivity
+
+3. Wireless charging pad:
+ Extcon can manage the state of a wireless charging connection, allowing
+ the system to respond appropriately when a device is placed on or removed
+ from the charging pad.
+
+4. Smart TV HDMI ports:
+ In a smart TV, Extcon can manage multiple HDMI ports, detecting when
+ devices are connected or disconnected, and potentially identifying the
+ type of device (e.g., gaming console, set-top box, Blu-ray player).
+
+The Extcon framework simplifies the development of drivers for these complex
+scenarios by providing a standardized way to report and query connector
+states, handle mutually exclusive connections, and manage connector
+properties. This allows for more robust and flexible handling of external
+connections in modern devices.
+
+Key Components
+==============
+
+extcon_dev
+----------
+
+The core structure representing an Extcon device::
+
+ struct extcon_dev {
+ const char *name;
+ const unsigned int *supported_cable;
+ const u32 *mutually_exclusive;
+
+ /* Internal data */
+ struct device dev;
+ unsigned int id;
+ struct raw_notifier_head nh_all;
+ struct raw_notifier_head *nh;
+ struct list_head entry;
+ int max_supported;
+ spinlock_t lock;
+ u32 state;
+
+ /* Sysfs related */
+ struct device_type extcon_dev_type;
+ struct extcon_cable *cables;
+ struct attribute_group attr_g_muex;
+ struct attribute **attrs_muex;
+ struct device_attribute *d_attrs_muex;
+ };
+
+Key fields:
+
+- ``name``: Name of the Extcon device
+- ``supported_cable``: Array of supported cable types
+- ``mutually_exclusive``: Array defining mutually exclusive cable types
+ This field is crucial for enforcing hardware constraints. It's an array of
+ 32-bit unsigned integers, where each element represents a set of mutually
+ exclusive cable types. The array should be terminated with a 0.
+
+ For example:
+
+ ::
+
+ static const u32 mutually_exclusive[] = {
+ BIT(0) | BIT(1), /* Cable 0 and 1 are mutually exclusive */
+ BIT(2) | BIT(3) | BIT(4), /* Cables 2, 3, and 4 are mutually exclusive */
+ 0 /* Terminator */
+ };
+
+ In this example, cables 0 and 1 cannot be connected simultaneously, and
+ cables 2, 3, and 4 are also mutually exclusive. This is useful for
+ scenarios like a single port that can either be USB or HDMI, but not both
+ at the same time.
+
+ The Extcon core uses this information to prevent invalid combinations of
+ cable states, ensuring that the reported states are always consistent
+ with the hardware capabilities.
+
+- ``state``: Current state of the device (bitmap of connected cables)
+
+
+extcon_cable
+------------
+
+Represents an individual cable managed by an Extcon device::
+
+ struct extcon_cable {
+ struct extcon_dev *edev;
+ int cable_index;
+ struct attribute_group attr_g;
+ struct device_attribute attr_name;
+ struct device_attribute attr_state;
+ struct attribute *attrs[3];
+ union extcon_property_value usb_propval[EXTCON_PROP_USB_CNT];
+ union extcon_property_value chg_propval[EXTCON_PROP_CHG_CNT];
+ union extcon_property_value jack_propval[EXTCON_PROP_JACK_CNT];
+ union extcon_property_value disp_propval[EXTCON_PROP_DISP_CNT];
+ DECLARE_BITMAP(usb_bits, EXTCON_PROP_USB_CNT);
+ DECLARE_BITMAP(chg_bits, EXTCON_PROP_CHG_CNT);
+ DECLARE_BITMAP(jack_bits, EXTCON_PROP_JACK_CNT);
+ DECLARE_BITMAP(disp_bits, EXTCON_PROP_DISP_CNT);
+ };
+
+Core Functions
+==============
+
+.. kernel-doc:: drivers/extcon/extcon.c
+ :identifiers: extcon_get_state
+
+.. kernel-doc:: drivers/extcon/extcon.c
+ :identifiers: extcon_set_state
+
+.. kernel-doc:: drivers/extcon/extcon.c
+ :identifiers: extcon_set_state_sync
+
+.. kernel-doc:: drivers/extcon/extcon.c
+ :identifiers: extcon_get_property
+
+
+Sysfs Interface
+===============
+
+Extcon devices expose the following sysfs attributes:
+
+- ``name``: Name of the Extcon device
+- ``state``: Current state of all supported cables
+- ``cable.N/name``: Name of the Nth supported cable
+- ``cable.N/state``: State of the Nth supported cable
+
+Usage Example
+-------------
+
+.. code-block:: c
+
+ #include <linux/module.h>
+ #include <linux/platform_device.h>
+ #include <linux/extcon.h>
+
+ struct my_extcon_data {
+ struct extcon_dev *edev;
+ struct device *dev;
+ };
+
+ static const unsigned int my_extcon_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_NONE,
+ };
+
+ static int my_extcon_probe(struct platform_device *pdev)
+ {
+ struct my_extcon_data *data;
+ int ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->dev = &pdev->dev;
+
+ /* Initialize extcon device */
+ data->edev = devm_extcon_dev_allocate(data->dev, my_extcon_cable);
+ if (IS_ERR(data->edev)) {
+ dev_err(data->dev, "Failed to allocate extcon device\n");
+ return PTR_ERR(data->edev);
+ }
+
+ /* Register extcon device */
+ ret = devm_extcon_dev_register(data->dev, data->edev);
+ if (ret < 0) {
+ dev_err(data->dev, "Failed to register extcon device\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, data);
+
+ /* Example: Set initial state */
+ extcon_set_state_sync(data->edev, EXTCON_USB, true);
+
+ dev_info(data->dev, "My extcon driver probed successfully\n");
+ return 0;
+ }
+
+ static int my_extcon_remove(struct platform_device *pdev)
+ {
+ struct my_extcon_data *data = platform_get_drvdata(pdev);
+
+ /* Example: Clear state before removal */
+ extcon_set_state_sync(data->edev, EXTCON_USB, false);
+
+ dev_info(data->dev, "My extcon driver removed\n");
+ return 0;
+ }
+
+ static const struct of_device_id my_extcon_of_match[] = {
+ { .compatible = "my,extcon-device", },
+ { },
+ };
+ MODULE_DEVICE_TABLE(of, my_extcon_of_match);
+
+ static struct platform_driver my_extcon_driver = {
+ .driver = {
+ .name = "my-extcon-driver",
+ .of_match_table = my_extcon_of_match,
+ },
+ .probe = my_extcon_probe,
+ .remove = my_extcon_remove,
+ };
+
+ module_platform_driver(my_extcon_driver);
+
+This example demonstrates:
+---------------------------
+
+- Defining supported cable types (USB and USB Host in this case).
+- Allocating and registering an extcon device.
+- Setting an initial state for a cable (USB connected in this example).
+- Clearing the state when the driver is removed.
diff --git a/Documentation/driver-api/firewire.rst b/Documentation/driver-api/firewire.rst
index d3cfa73cbb2b..28a32410f7d2 100644
--- a/Documentation/driver-api/firewire.rst
+++ b/Documentation/driver-api/firewire.rst
@@ -43,6 +43,8 @@ Firewire core transaction interfaces
Firewire Isochronous I/O interfaces
===================================
+.. kernel-doc:: include/linux/firewire.h
+ :functions: fw_iso_context_schedule_flush_completions
.. kernel-doc:: drivers/firewire/core-iso.c
:export:
diff --git a/Documentation/driver-api/firmware/efi/index.rst b/Documentation/driver-api/firmware/efi/index.rst
index 4fe8abba9fc6..5a6b6229592c 100644
--- a/Documentation/driver-api/firmware/efi/index.rst
+++ b/Documentation/driver-api/firmware/efi/index.rst
@@ -1,11 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
-============
-UEFI Support
-============
+====================================================
+Unified Extensible Firmware Interface (UEFI) Support
+====================================================
UEFI stub library functions
===========================
.. kernel-doc:: drivers/firmware/efi/libstub/mem.c
:internal:
+
+UEFI Common Platform Error Record (CPER) functions
+==================================================
+
+.. kernel-doc:: drivers/firmware/efi/cper.c
diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
index fdcfce42c6d2..336e912281c3 100644
--- a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
+++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
@@ -42,3 +42,8 @@ then of course these rules will not apply strictly.)
deprecating old major versions, then this should only be done as a
last option, and be stated clearly in all communications.
+* Firmware files that affect the User API (UAPI) shall not introduce
+ changes that break existing userspace programs. Updates to such firmware
+ must ensure backward compatibility with existing userspace applications.
+ This includes maintaining consistent interfaces and behaviors that
+ userspace programs rely on.
diff --git a/Documentation/driver-api/firmware/fw_search_path.rst b/Documentation/driver-api/firmware/fw_search_path.rst
index a360f1009fa3..d7cb1e8f0076 100644
--- a/Documentation/driver-api/firmware/fw_search_path.rst
+++ b/Documentation/driver-api/firmware/fw_search_path.rst
@@ -22,5 +22,10 @@ can use the file:
* /sys/module/firmware_class/parameters/path
-You would echo into it your custom path and firmware requested will be
-searched for there first.
+You would echo into it your custom path and firmware requested will be searched
+for there first. Be aware that newline characters will be taken into account
+and may not produce the intended effects. For instance you might want to use:
+
+echo -n /path/to/script > /sys/module/firmware_class/parameters/path
+
+to ensure that your script is being used.
diff --git a/Documentation/driver-api/firmware/fw_upload.rst b/Documentation/driver-api/firmware/fw_upload.rst
index 76922591e446..edf1d0c5e7c3 100644
--- a/Documentation/driver-api/firmware/fw_upload.rst
+++ b/Documentation/driver-api/firmware/fw_upload.rst
@@ -57,7 +57,8 @@ function calls firmware_upload_unregister() such as::
len = (truncate) ? truncate - fw_name : strlen(fw_name);
sec->fw_name = kmemdup_nul(fw_name, len, GFP_KERNEL);
- fwl = firmware_upload_register(sec->dev, sec->fw_name, &m10bmc_ops, sec);
+ fwl = firmware_upload_register(THIS_MODULE, sec->dev, sec->fw_name,
+ &m10bmc_ops, sec);
if (IS_ERR(fwl)) {
dev_err(sec->dev, "Firmware Upload driver failed to start\n");
kfree(sec->fw_name);
diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst
index 604208534095..833f68fb0700 100644
--- a/Documentation/driver-api/fpga/fpga-bridge.rst
+++ b/Documentation/driver-api/fpga/fpga-bridge.rst
@@ -6,9 +6,12 @@ API to implement a new FPGA bridge
* struct fpga_bridge - The FPGA Bridge structure
* struct fpga_bridge_ops - Low level Bridge driver ops
-* fpga_bridge_register() - Create and register a bridge
+* __fpga_bridge_register() - Create and register a bridge
* fpga_bridge_unregister() - Unregister a bridge
+The helper macro ``fpga_bridge_register()`` automatically sets
+the module that registers the FPGA bridge as the owner.
+
.. kernel-doc:: include/linux/fpga/fpga-bridge.h
:functions: fpga_bridge
@@ -16,7 +19,7 @@ API to implement a new FPGA bridge
:functions: fpga_bridge_ops
.. kernel-doc:: drivers/fpga/fpga-bridge.c
- :functions: fpga_bridge_register
+ :functions: __fpga_bridge_register
.. kernel-doc:: drivers/fpga/fpga-bridge.c
:functions: fpga_bridge_unregister
diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst
index 49c0a9512653..8d2b79f696c1 100644
--- a/Documentation/driver-api/fpga/fpga-mgr.rst
+++ b/Documentation/driver-api/fpga/fpga-mgr.rst
@@ -24,7 +24,8 @@ How to support a new FPGA device
--------------------------------
To add another FPGA manager, write a driver that implements a set of ops. The
-probe function calls fpga_mgr_register() or fpga_mgr_register_full(), such as::
+probe function calls ``fpga_mgr_register()`` or ``fpga_mgr_register_full()``,
+such as::
static const struct fpga_manager_ops socfpga_fpga_ops = {
.write_init = socfpga_fpga_ops_configure_init,
@@ -69,10 +70,11 @@ probe function calls fpga_mgr_register() or fpga_mgr_register_full(), such as::
}
Alternatively, the probe function could call one of the resource managed
-register functions, devm_fpga_mgr_register() or devm_fpga_mgr_register_full().
-When these functions are used, the parameter syntax is the same, but the call
-to fpga_mgr_unregister() should be removed. In the above example, the
-socfpga_fpga_remove() function would not be required.
+register functions, ``devm_fpga_mgr_register()`` or
+``devm_fpga_mgr_register_full()``. When these functions are used, the
+parameter syntax is the same, but the call to ``fpga_mgr_unregister()`` should be
+removed. In the above example, the ``socfpga_fpga_remove()`` function would not be
+required.
The ops will implement whatever device specific register writes are needed to
do the programming sequence for this particular FPGA. These ops return 0 for
@@ -125,15 +127,19 @@ API for implementing a new FPGA Manager driver
* struct fpga_manager - the FPGA manager struct
* struct fpga_manager_ops - Low level FPGA manager driver ops
* struct fpga_manager_info - Parameter structure for fpga_mgr_register_full()
-* fpga_mgr_register_full() - Create and register an FPGA manager using the
+* __fpga_mgr_register_full() - Create and register an FPGA manager using the
fpga_mgr_info structure to provide the full flexibility of options
-* fpga_mgr_register() - Create and register an FPGA manager using standard
+* __fpga_mgr_register() - Create and register an FPGA manager using standard
arguments
-* devm_fpga_mgr_register_full() - Resource managed version of
- fpga_mgr_register_full()
-* devm_fpga_mgr_register() - Resource managed version of fpga_mgr_register()
+* __devm_fpga_mgr_register_full() - Resource managed version of
+ __fpga_mgr_register_full()
+* __devm_fpga_mgr_register() - Resource managed version of __fpga_mgr_register()
* fpga_mgr_unregister() - Unregister an FPGA manager
+Helper macros ``fpga_mgr_register_full()``, ``fpga_mgr_register()``,
+``devm_fpga_mgr_register_full()``, and ``devm_fpga_mgr_register()`` are available
+to ease the registration.
+
.. kernel-doc:: include/linux/fpga/fpga-mgr.h
:functions: fpga_mgr_states
@@ -147,16 +153,16 @@ API for implementing a new FPGA Manager driver
:functions: fpga_manager_info
.. kernel-doc:: drivers/fpga/fpga-mgr.c
- :functions: fpga_mgr_register_full
+ :functions: __fpga_mgr_register_full
.. kernel-doc:: drivers/fpga/fpga-mgr.c
- :functions: fpga_mgr_register
+ :functions: __fpga_mgr_register
.. kernel-doc:: drivers/fpga/fpga-mgr.c
- :functions: devm_fpga_mgr_register_full
+ :functions: __devm_fpga_mgr_register_full
.. kernel-doc:: drivers/fpga/fpga-mgr.c
- :functions: devm_fpga_mgr_register
+ :functions: __devm_fpga_mgr_register
.. kernel-doc:: drivers/fpga/fpga-mgr.c
:functions: fpga_mgr_unregister
diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst
index dc55d60a0b4a..2d03b5fb7657 100644
--- a/Documentation/driver-api/fpga/fpga-region.rst
+++ b/Documentation/driver-api/fpga/fpga-region.rst
@@ -46,13 +46,16 @@ API to add a new FPGA region
----------------------------
* struct fpga_region - The FPGA region struct
-* struct fpga_region_info - Parameter structure for fpga_region_register_full()
-* fpga_region_register_full() - Create and register an FPGA region using the
+* struct fpga_region_info - Parameter structure for __fpga_region_register_full()
+* __fpga_region_register_full() - Create and register an FPGA region using the
fpga_region_info structure to provide the full flexibility of options
-* fpga_region_register() - Create and register an FPGA region using standard
+* __fpga_region_register() - Create and register an FPGA region using standard
arguments
* fpga_region_unregister() - Unregister an FPGA region
+Helper macros ``fpga_region_register()`` and ``fpga_region_register_full()``
+automatically set the module that registers the FPGA region as the owner.
+
The FPGA region's probe function will need to get a reference to the FPGA
Manager it will be using to do the programming. This usually would happen
during the region's probe function.
@@ -82,10 +85,10 @@ following APIs to handle building or tearing down that list.
:functions: fpga_region_info
.. kernel-doc:: drivers/fpga/fpga-region.c
- :functions: fpga_region_register_full
+ :functions: __fpga_region_register_full
.. kernel-doc:: drivers/fpga/fpga-region.c
- :functions: fpga_region_register
+ :functions: __fpga_region_register
.. kernel-doc:: drivers/fpga/fpga-region.c
:functions: fpga_region_unregister
diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
index 71ccc30e586b..e826f16ea43d 100644
--- a/Documentation/driver-api/generic-counter.rst
+++ b/Documentation/driver-api/generic-counter.rst
@@ -467,7 +467,7 @@ Counter sysfs
Translates counter data to the standard Counter sysfs interface format
and vice versa.
-Please refer to the ``Documentation/ABI/testing/sysfs-bus-counter`` file
+Please refer to the Documentation/ABI/testing/sysfs-bus-counter file
for a detailed breakdown of the available Generic Counter interface
sysfs attributes.
@@ -483,7 +483,7 @@ Sysfs Interface
Several sysfs attributes are generated by the Generic Counter interface,
and reside under the ``/sys/bus/counter/devices/counterX`` directory,
where ``X`` is to the respective counter device id. Please see
-``Documentation/ABI/testing/sysfs-bus-counter`` for detailed information
+Documentation/ABI/testing/sysfs-bus-counter for detailed information
on each Generic Counter interface sysfs attribute.
Through these sysfs attributes, programs and scripts may interact with
diff --git a/Documentation/driver-api/generic_pt.rst b/Documentation/driver-api/generic_pt.rst
new file mode 100644
index 000000000000..fd29d1b525e5
--- /dev/null
+++ b/Documentation/driver-api/generic_pt.rst
@@ -0,0 +1,137 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+Generic Radix Page Table
+========================
+
+.. kernel-doc:: include/linux/generic_pt/common.h
+ :doc: Generic Radix Page Table
+
+.. kernel-doc:: drivers/iommu/generic_pt/pt_defs.h
+ :doc: Generic Page Table Language
+
+Usage
+=====
+
+Generic PT is structured as a multi-compilation system. Since each format
+provides an API using a common set of names there can be only one format active
+within a compilation unit. This design avoids function pointers around the low
+level API.
+
+Instead the function pointers can end up at the higher level API (i.e.
+map/unmap, etc.) and the per-format code can be directly inlined into the
+per-format compilation unit. For something like IOMMU each format will be
+compiled into a per-format IOMMU operations kernel module.
+
+For this to work the .c file for each compilation unit will include both the
+format headers and the generic code for the implementation. For instance in an
+implementation compilation unit the headers would normally be included as
+follows:
+
+generic_pt/fmt/iommu_amdv1.c::
+
+ #include <linux/generic_pt/common.h>
+ #include "defs_amdv1.h"
+ #include "../pt_defs.h"
+ #include "amdv1.h"
+ #include "../pt_common.h"
+ #include "../pt_iter.h"
+ #include "../iommu_pt.h" /* The IOMMU implementation */
+
+iommu_pt.h includes definitions that will generate the operations functions for
+map/unmap/etc. using the definitions provided by AMDv1. The resulting module
+will have exported symbols named like pt_iommu_amdv1_init().
+
+Refer to drivers/iommu/generic_pt/fmt/iommu_template.h for an example of how the
+IOMMU implementation uses multi-compilation to generate per-format ops structs
+pointers.
+
+The format code is written so that the common names arise from #defines to
+distinct format specific names. This is intended to aid debuggability by
+avoiding symbol clashes across all the different formats.
+
+Exported symbols and other global names are mangled using a per-format string
+via the NS() helper macro.
+
+The format uses struct pt_common as the top-level struct for the table,
+and each format will have its own struct pt_xxx which embeds it to store
+format-specific information.
+
+The implementation will further wrap struct pt_common in its own top-level
+struct, such as struct pt_iommu_amdv1.
+
+Format functions at the struct pt_common level
+----------------------------------------------
+
+.. kernel-doc:: include/linux/generic_pt/common.h
+ :identifiers:
+.. kernel-doc:: drivers/iommu/generic_pt/pt_common.h
+
+Iteration Helpers
+-----------------
+
+.. kernel-doc:: drivers/iommu/generic_pt/pt_iter.h
+
+Writing a Format
+----------------
+
+It is best to start from a simple format that is similar to the target. x86_64
+is usually a good reference for something simple, and AMDv1 is something fairly
+complete.
+
+The required inline functions need to be implemented in the format header.
+These should all follow the standard pattern of::
+
+ static inline pt_oaddr_t amdv1pt_entry_oa(const struct pt_state *pts)
+ {
+ [..]
+ }
+ #define pt_entry_oa amdv1pt_entry_oa
+
+where a uniquely named per-format inline function provides the implementation
+and a define maps it to the generic name. This is intended to make debug symbols
+work better. inline functions should always be used as the prototypes in
+pt_common.h will cause the compiler to validate the function signature to
+prevent errors.
+
+Review pt_fmt_defaults.h to understand some of the optional inlines.
+
+Once the format compiles then it should be run through the generic page table
+kunit test in kunit_generic_pt.h using kunit. For example::
+
+ $ tools/testing/kunit/kunit.py run --build_dir build_kunit_x86_64 --arch x86_64 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig amdv1_fmt_test.*
+ [...]
+ [11:15:08] Testing complete. Ran 9 tests: passed: 9
+ [11:15:09] Elapsed time: 3.137s total, 0.001s configuring, 2.368s building, 0.311s running
+
+The generic tests are intended to prove out the format functions and give
+clearer failures to speed up finding the problems. Once those pass then the
+entire kunit suite should be run.
+
+IOMMU Invalidation Features
+---------------------------
+
+Invalidation is how the page table algorithms synchronize with a HW cache of the
+page table memory, typically called the TLB (or IOTLB for IOMMU cases).
+
+The TLB can store present PTEs, non-present PTEs and table pointers, depending
+on its design. Every HW has its own approach on how to describe what has changed
+to have changed items removed from the TLB.
+
+PT_FEAT_FLUSH_RANGE
+~~~~~~~~~~~~~~~~~~~
+
+PT_FEAT_FLUSH_RANGE is the easiest scheme to understand. It tries to generate a
+single range invalidation for each operation, over-invalidating if there are
+gaps of VA that don't need invalidation. This trades off impacted VA for number
+of invalidation operations. It does not keep track of what is being invalidated;
+however, if pages have to be freed then page table pointers have to be cleaned
+from the walk cache. The range can start/end at any page boundary.
+
+PT_FEAT_FLUSH_RANGE_NO_GAPS
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+PT_FEAT_FLUSH_RANGE_NO_GAPS is similar to PT_FEAT_FLUSH_RANGE; however, it tries
+to minimize the amount of impacted VA by issuing extra flush operations. This is
+useful if the cost of processing VA is very high, for instance because a
+hypervisor is processing the page table with a shadowing algorithm.
diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
index b33aa04f213f..069b54d8591b 100644
--- a/Documentation/driver-api/gpio/board.rst
+++ b/Documentation/driver-api/gpio/board.rst
@@ -4,12 +4,6 @@ GPIO Mappings
This document explains how GPIOs can be assigned to given devices and functions.
-Note that it only applies to the new descriptor-based interface. For a
-description of the deprecated integer-based GPIO interface please refer to
-legacy.rst (actually, there is no real mapping possible with the old
-interface; you just fetch an integer from somewhere and request the
-corresponding GPIO).
-
All platforms can enable the GPIO library, but if the platform strictly
requires GPIO functionality to be present, it needs to select GPIOLIB from its
Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
@@ -100,6 +94,71 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
For more information about the ACPI GPIO bindings see
Documentation/firmware-guide/acpi/gpio-properties.rst.
+Software Nodes
+--------------
+
+Software nodes allow board-specific code to construct an in-memory,
+device-tree-like structure using struct software_node and struct
+property_entry. This structure can then be associated with a platform device,
+allowing drivers to use the standard device properties API to query
+configuration, just as they would on an ACPI or device tree system.
+
+Software-node-backed GPIOs are described using the ``PROPERTY_ENTRY_GPIO()``
+macro, which ties a software node representing the GPIO controller with
+consumer device. It allows consumers to use regular gpiolib APIs, such as
+gpiod_get(), gpiod_get_optional().
+
+The software node representing a GPIO controller need not be attached to the
+GPIO controller device. The only requirement is that the node must be
+registered and its name must match the GPIO controller's label.
+
+For example, here is how to describe a single GPIO-connected LED. This is an
+alternative to using platform_data on legacy systems.
+
+.. code-block:: c
+
+ #include <linux/property.h>
+ #include <linux/gpio/machine.h>
+ #include <linux/gpio/property.h>
+
+ /*
+ * 1. Define a node for the GPIO controller. Its .name must match the
+ * controller's label.
+ */
+ static const struct software_node gpio_controller_node = {
+ .name = "gpio-foo",
+ };
+
+ /* 2. Define the properties for the LED device. */
+ static const struct property_entry led_device_props[] = {
+ PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
+ PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
+ PROPERTY_ENTRY_GPIO("gpios", &gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
+ { }
+ };
+
+ /* 3. Define the software node for the LED device. */
+ static const struct software_node led_device_swnode = {
+ .name = "status-led",
+ .properties = led_device_props,
+ };
+
+ /*
+ * 4. Register the software nodes and the platform device.
+ */
+ const struct software_node *swnodes[] = {
+ &gpio_controller_node,
+ &led_device_swnode,
+ NULL
+ };
+ software_node_register_node_group(swnodes);
+
+ // Then register a platform_device for "leds-gpio" and associate
+ // it with &led_device_swnode via .fwnode.
+
+For a complete guide on converting board files to use software nodes, see
+Documentation/driver-api/gpio/legacy-boards.rst.
+
Platform Data
-------------
Finally, GPIOs can be bound to devices and functions using platform data. Board
diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
index de6fc79ad6f0..bb3366047fad 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -2,9 +2,7 @@
GPIO Descriptor Consumer Interface
==================================
-This document describes the consumer interface of the GPIO framework. Note that
-it describes the new descriptor-based interface. For a description of the
-deprecated integer-based GPIO interface please refer to legacy.rst.
+This document describes the consumer interface of the GPIO framework.
Guidelines for GPIOs consumers
@@ -29,6 +27,10 @@ warnings. These stubs are used for two use cases:
will use it under other compile-time configurations. In this case the
consumer must make sure not to call into these functions, or the user will
be met with console warnings that may be perceived as intimidating.
+ Combining truly optional GPIOLIB usage with calls to
+ ``[devm_]gpiod_get_optional()`` is a *bad idea*, and will result in weird
+ error messages. Use the ordinary getter functions with optional GPIOLIB:
+ some open coding of error handling should be expected when you do this.
All the functions that work with the descriptor-based GPIO interface are
prefixed with ``gpiod_``. The ``gpio_`` prefix is used for the legacy
@@ -218,9 +220,9 @@ Use the following calls to access GPIOs from an atomic context::
int gpiod_get_value(const struct gpio_desc *desc);
void gpiod_set_value(struct gpio_desc *desc, int value);
-The values are boolean, zero for low, nonzero for high. When reading the value
-of an output pin, the value returned should be what's seen on the pin. That
-won't always match the specified output value, because of issues including
+The values are boolean, zero for inactive, nonzero for active. When reading the
+value of an output pin, the value returned should be what's seen on the pin.
+That won't always match the specified output value, because of issues including
open-drain signaling and output latencies.
The get/set calls do not return errors because "invalid GPIO" should have been
@@ -273,11 +275,11 @@ switch their output to a high impedance value. The consumer should not need to
care. (For details read about open drain in driver.rst.)
With this, all the gpiod_set_(array)_value_xxx() functions interpret the
-parameter "value" as "asserted" ("1") or "de-asserted" ("0"). The physical line
+parameter "value" as "active" ("1") or "inactive" ("0"). The physical line
level will be driven accordingly.
As an example, if the active low property for a dedicated GPIO is set, and the
-gpiod_set_(array)_value_xxx() passes "asserted" ("1"), the physical line level
+gpiod_set_(array)_value_xxx() passes "active" ("1"), the physical line level
will be driven low.
To summarize::
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index 6baaeab79534..85d86f92c41b 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -7,7 +7,7 @@ This document serves as a guide for writers of GPIO chip drivers.
Each GPIO controller driver needs to include the following header, which defines
the structures used to define a GPIO driver::
- #include <linux/gpio/driver.h>
+ #include <linux/gpio/driver.h>
Internal Representation of GPIOs
@@ -69,9 +69,8 @@ driver code:
The code implementing a gpio_chip should support multiple instances of the
controller, preferably using the driver model. That code will configure each
-gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
-devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use
-gpiochip_remove() when it is unavoidable.
+gpio_chip and issue gpiochip_add_data() or devm_gpiochip_add_data(). Removing
+a GPIO controller should be rare; use gpiochip_remove() when it is unavoidable.
Often a gpio_chip is part of an instance-specific structure with states not
exposed by the GPIO interfaces, such as addressing, power management, and more.
@@ -144,7 +143,7 @@ is not open, it will present a high-impedance (tristate) to the external rail::
in ----|| |/
||--+ in ----|
| |\
- GND GND
+ GND GND
This configuration is normally used as a way to achieve one of two things:
@@ -218,10 +217,10 @@ not support open drain/open source in hardware, the GPIO library will instead
use a trick: when a line is set as output, if the line is flagged as open
drain, and the IN output value is low, it will be driven low as usual. But
if the IN output value is set to high, it will instead *NOT* be driven high,
-instead it will be switched to input, as input mode is high impedance, thus
-achieving an "open drain emulation" of sorts: electrically the behaviour will
-be identical, with the exception of possible hardware glitches when switching
-the mode of the line.
+instead it will be switched to input, as input mode is an equivalent to
+high impedance, thus achieving an "open drain emulation" of sorts: electrically
+the behaviour will be identical, with the exception of possible hardware glitches
+when switching the mode of the line.
For open source configuration the same principle is used, just that instead
of actively driving the line low, it is set to input.
@@ -550,10 +549,10 @@ the interrupt separately and go with it:
struct my_gpio *g;
struct gpio_irq_chip *girq;
- ret = devm_request_threaded_irq(dev, irq, NULL,
- irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
+ ret = devm_request_threaded_irq(dev, irq, NULL, irq_thread_fn,
+ IRQF_ONESHOT, "my-chip", g);
if (ret < 0)
- return ret;
+ return ret;
/* Get a pointer to the gpio_irq_chip */
girq = &g->gc.irq;
@@ -681,12 +680,12 @@ certain operations and keep track of usage inside of the gpiolib subsystem.
Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
to mark the GPIO as being used as an IRQ::
- int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
+ int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
is released::
- void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
+ void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .startup() and .shutdown() callbacks from the
@@ -708,12 +707,12 @@ When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
the IRQ is enabled or disabled. In order to inform gpiolib about this,
the irqchip driver should call::
- void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
+ void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
This allows drivers to drive the GPIO as an output while the IRQ is
disabled. When the IRQ is enabled again, a driver should call::
- void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
+ void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .irq_disable() and .irq_enable() callbacks from the
@@ -751,7 +750,7 @@ compliance:
- Test your driver with the appropriate in-kernel real-time test cases for both
level and edge IRQs
-* [1] http://www.spinics.net/lists/linux-omap/msg120425.html
+* [1] https://lore.kernel.org/r/1437496011-11486-1-git-send-email-bigeasy@linutronix.de/
* [2] https://lore.kernel.org/r/1443209283-20781-2-git-send-email-grygorii.strashko@ti.com
* [3] https://lore.kernel.org/r/1443209283-20781-3-git-send-email-grygorii.strashko@ti.com
@@ -763,12 +762,12 @@ Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
descriptors through the gpiolib API. A GPIO driver can use the following
functions to request and free descriptors::
- struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
- u16 hwnum,
- const char *label,
- enum gpiod_flags flags)
+ struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
+ u16 hwnum,
+ const char *label,
+ enum gpiod_flags flags)
- void gpiochip_free_own_desc(struct gpio_desc *desc)
+ void gpiochip_free_own_desc(struct gpio_desc *desc)
Descriptors requested with gpiochip_request_own_desc() must be released with
gpiochip_free_own_desc().
diff --git a/Documentation/driver-api/gpio/drivers-on-gpio.rst b/Documentation/driver-api/gpio/drivers-on-gpio.rst
index af632d764ac6..95572d2a94ce 100644
--- a/Documentation/driver-api/gpio/drivers-on-gpio.rst
+++ b/Documentation/driver-api/gpio/drivers-on-gpio.rst
@@ -27,7 +27,12 @@ hardware descriptions such as device tree or ACPI:
to the lines for a more permanent solution of this type.
- gpio-beeper: drivers/input/misc/gpio-beeper.c is used to provide a beep from
- an external speaker connected to a GPIO line.
+ an external speaker connected to a GPIO line. (If the beep is controlled by
+ off/on, for an actual PWM waveform, see pwm-gpio below.)
+
+- pwm-gpio: drivers/pwm/pwm-gpio.c is used to toggle a GPIO with a high
+ resolution timer producing a PWM waveform on the GPIO line, as well as
+ Linux high resolution timers can do.
- extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an
external connector status, such as a headset line for an audio driver or an
diff --git a/Documentation/driver-api/gpio/index.rst b/Documentation/driver-api/gpio/index.rst
index 1d48fe248f05..bee58f709b9a 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -12,9 +12,10 @@ Contents:
driver
consumer
board
+ legacy-boards
drivers-on-gpio
- legacy
bt8xxgpio
+ pca953x
Core
====
@@ -28,7 +29,7 @@ Core
ACPI support
============
-.. kernel-doc:: drivers/gpio/gpiolib-acpi.c
+.. kernel-doc:: drivers/gpio/gpiolib-acpi-core.c
:export:
Device tree support
diff --git a/Documentation/driver-api/gpio/intro.rst b/Documentation/driver-api/gpio/intro.rst
index c9c19243b97f..5936a9c57df3 100644
--- a/Documentation/driver-api/gpio/intro.rst
+++ b/Documentation/driver-api/gpio/intro.rst
@@ -10,18 +10,6 @@ The documents in this directory give detailed instructions on how to access
GPIOs in drivers, and how to write a driver for a device that provides GPIOs
itself.
-Due to the history of GPIO interfaces in the kernel, there are two different
-ways to obtain and use GPIOs:
-
- - The descriptor-based interface is the preferred way to manipulate GPIOs,
- and is described by all the files in this directory excepted legacy.rst.
- - The legacy integer-based interface which is considered deprecated (but still
- usable for compatibility reasons) is documented in legacy.rst.
-
-The remainder of this document applies to the new descriptor-based interface.
-legacy.rst contains the same information applied to the legacy
-integer-based interface.
-
What is a GPIO?
===============
diff --git a/Documentation/driver-api/gpio/legacy-boards.rst b/Documentation/driver-api/gpio/legacy-boards.rst
new file mode 100644
index 000000000000..46e3a26dba77
--- /dev/null
+++ b/Documentation/driver-api/gpio/legacy-boards.rst
@@ -0,0 +1,298 @@
+Supporting Legacy Boards
+========================
+
+Many drivers in the kernel, such as ``leds-gpio`` and ``gpio-keys``, are
+migrating away from using board-specific ``platform_data`` to a unified device
+properties interface. This interface allows drivers to be simpler and more
+generic, as they can query properties in a standardized way.
+
+On modern systems, these properties are provided via device tree. However, some
+older platforms have not been converted to device tree and instead rely on
+board files to describe their hardware configuration. To bridge this gap and
+allow these legacy boards to work with modern, generic drivers, the kernel
+provides a mechanism called **software nodes**.
+
+This document provides a guide on how to convert a legacy board file from using
+``platform_data`` and ``gpiod_lookup_table`` to the modern software node
+approach for describing GPIO-connected devices.
+
+The Core Idea: Software Nodes
+-----------------------------
+
+Software nodes allow board-specific code to construct an in-memory,
+device-tree-like structure using struct software_node and struct
+property_entry. This structure can then be associated with a platform device,
+allowing drivers to use the standard device properties API (e.g.,
+device_property_read_u32(), device_property_read_string()) to query
+configuration, just as they would on an ACPI or device tree system.
+
+The gpiolib code has support for handling software nodes, so that if GPIO is
+described properly, as detailed in the section below, then regular gpiolib APIs,
+such as gpiod_get(), gpiod_get_optional(), and others will work.
+
+Requirements for GPIO Properties
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using software nodes to describe GPIO connections, the following
+requirements must be met for the GPIO core to correctly resolve the reference:
+
+1. **The GPIO controller's software node "name" must match the controller's
+ "label".** The gpiolib core uses this name to find the corresponding
+ struct gpio_chip at runtime.
+ This software node has to be registered, but need not be attached to the
+ device representing the GPIO controller that is providing the GPIO in
+ question. It may be left as a "free floating" node.
+
+2. **The GPIO property must be a reference.** The ``PROPERTY_ENTRY_GPIO()``
+ macro handles this as it is an alias for ``PROPERTY_ENTRY_REF()``.
+
+3. **The reference must have exactly two arguments:**
+
+ - The first argument is the GPIO offset within the controller.
+ - The second argument is the flags for the GPIO line (e.g.,
+ GPIO_ACTIVE_HIGH, GPIO_ACTIVE_LOW).
+
+The ``PROPERTY_ENTRY_GPIO()`` macro is the preferred way of defining GPIO
+properties in software nodes.
+
+Conversion Example
+------------------
+
+Let's walk through an example of converting a board file that defines a GPIO-
+connected LED and a button.
+
+Before: Using Platform Data
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A typical legacy board file might look like this:
+
+.. code-block:: c
+
+ #include <linux/platform_device.h>
+ #include <linux/leds.h>
+ #include <linux/gpio_keys.h>
+ #include <linux/gpio/machine.h>
+
+ #define MYBOARD_GPIO_CONTROLLER "gpio-foo"
+
+ /* LED setup */
+ static const struct gpio_led myboard_leds[] = {
+ {
+ .name = "myboard:green:status",
+ .default_trigger = "heartbeat",
+ },
+ };
+
+ static const struct gpio_led_platform_data myboard_leds_pdata = {
+ .num_leds = ARRAY_SIZE(myboard_leds),
+ .leds = myboard_leds,
+ };
+
+ static struct gpiod_lookup_table myboard_leds_gpios = {
+ .dev_id = "leds-gpio",
+ .table = {
+ GPIO_LOOKUP_IDX(MYBOARD_GPIO_CONTROLLER, 42, NULL, 0, GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
+ /* Button setup */
+ static struct gpio_keys_button myboard_buttons[] = {
+ {
+ .code = KEY_WPS_BUTTON,
+ .desc = "WPS Button",
+ .active_low = 1,
+ },
+ };
+
+ static const struct gpio_keys_platform_data myboard_buttons_pdata = {
+ .buttons = myboard_buttons,
+ .nbuttons = ARRAY_SIZE(myboard_buttons),
+ };
+
+ static struct gpiod_lookup_table myboard_buttons_gpios = {
+ .dev_id = "gpio-keys",
+ .table = {
+ GPIO_LOOKUP_IDX(MYBOARD_GPIO_CONTROLLER, 15, NULL, 0, GPIO_ACTIVE_LOW),
+ { },
+ },
+ };
+
+ /* Device registration */
+ static int __init myboard_init(void)
+ {
+ gpiod_add_lookup_table(&myboard_leds_gpios);
+ gpiod_add_lookup_table(&myboard_buttons_gpios);
+
+ platform_device_register_data(NULL, "leds-gpio", -1,
+ &myboard_leds_pdata, sizeof(myboard_leds_pdata));
+ platform_device_register_data(NULL, "gpio-keys", -1,
+ &myboard_buttons_pdata, sizeof(myboard_buttons_pdata));
+
+ return 0;
+ }
+
+After: Using Software Nodes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here is how the same configuration can be expressed using software nodes.
+
+Step 1: Define the GPIO Controller Node
+***************************************
+
+First, define a software node that represents the GPIO controller that the
+LEDs and buttons are connected to. The ``name`` of this node must match the
+name of the driver for the GPIO controller (e.g., "gpio-foo").
+
+.. code-block:: c
+
+ #include <linux/property.h>
+ #include <linux/gpio/property.h>
+
+ #define MYBOARD_GPIO_CONTROLLER "gpio-foo"
+
+ static const struct software_node myboard_gpio_controller_node = {
+ .name = MYBOARD_GPIO_CONTROLLER,
+ };
+
+Step 2: Define Consumer Device Nodes and Properties
+***************************************************
+
+Next, define the software nodes for the consumer devices (the LEDs and buttons).
+This involves creating a parent node for each device type and child nodes for
+each individual LED or button.
+
+.. code-block:: c
+
+ /* LED setup */
+ static const struct software_node myboard_leds_node = {
+ .name = "myboard-leds",
+ };
+
+ static const struct property_entry myboard_status_led_props[] = {
+ PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
+ PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
+ PROPERTY_ENTRY_GPIO("gpios", &myboard_gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
+ { }
+ };
+
+ static const struct software_node myboard_status_led_swnode = {
+ .name = "status-led",
+ .parent = &myboard_leds_node,
+ .properties = myboard_status_led_props,
+ };
+
+ /* Button setup */
+ static const struct software_node myboard_keys_node = {
+ .name = "myboard-keys",
+ };
+
+ static const struct property_entry myboard_wps_button_props[] = {
+ PROPERTY_ENTRY_STRING("label", "WPS Button"),
+ PROPERTY_ENTRY_U32("linux,code", KEY_WPS_BUTTON),
+ PROPERTY_ENTRY_GPIO("gpios", &myboard_gpio_controller_node, 15, GPIO_ACTIVE_LOW),
+ { }
+ };
+
+ static const struct software_node myboard_wps_button_swnode = {
+ .name = "wps-button",
+ .parent = &myboard_keys_node,
+ .properties = myboard_wps_button_props,
+ };
+
+
+
+Step 3: Group and Register the Nodes
+************************************
+
+For maintainability, it is often beneficial to group all software nodes into a
+single array and register them with one call.
+
+.. code-block:: c
+
+ static const struct software_node * const myboard_swnodes[] = {
+ &myboard_gpio_controller_node,
+ &myboard_leds_node,
+ &myboard_status_led_swnode,
+ &myboard_keys_node,
+ &myboard_wps_button_swnode,
+ NULL
+ };
+
+ static int __init myboard_init(void)
+ {
+ int error;
+
+ error = software_node_register_node_group(myboard_swnodes);
+ if (error) {
+ pr_err("Failed to register software nodes: %d\n", error);
+ return error;
+ }
+
+ // ... platform device registration follows
+ }
+
+.. note::
+ When splitting registration of nodes by devices that they represent, it is
+ essential that the software node representing the GPIO controller itself
+ is registered first, before any of the nodes that reference it.
+
+Step 4: Register Platform Devices with Software Nodes
+*****************************************************
+
+Finally, register the platform devices and associate them with their respective
+software nodes using the ``fwnode`` field in struct platform_device_info.
+
+.. code-block:: c
+
+ static struct platform_device *leds_pdev;
+ static struct platform_device *keys_pdev;
+
+ static int __init myboard_init(void)
+ {
+ struct platform_device_info pdev_info;
+ int error;
+
+ error = software_node_register_node_group(myboard_swnodes);
+ if (error)
+ return error;
+
+ memset(&pdev_info, 0, sizeof(pdev_info));
+ pdev_info.name = "leds-gpio";
+ pdev_info.id = PLATFORM_DEVID_NONE;
+ pdev_info.fwnode = software_node_fwnode(&myboard_leds_node);
+ leds_pdev = platform_device_register_full(&pdev_info);
+ if (IS_ERR(leds_pdev)) {
+ error = PTR_ERR(leds_pdev);
+ goto err_unregister_nodes;
+ }
+
+ memset(&pdev_info, 0, sizeof(pdev_info));
+ pdev_info.name = "gpio-keys";
+ pdev_info.id = PLATFORM_DEVID_NONE;
+ pdev_info.fwnode = software_node_fwnode(&myboard_keys_node);
+ keys_pdev = platform_device_register_full(&pdev_info);
+ if (IS_ERR(keys_pdev)) {
+ error = PTR_ERR(keys_pdev);
+ platform_device_unregister(leds_pdev);
+ goto err_unregister_nodes;
+ }
+
+ return 0;
+
+ err_unregister_nodes:
+ software_node_unregister_node_group(myboard_swnodes);
+ return error;
+ }
+
+ static void __exit myboard_exit(void)
+ {
+ platform_device_unregister(keys_pdev);
+ platform_device_unregister(leds_pdev);
+ software_node_unregister_node_group(myboard_swnodes);
+ }
+
+With these changes, the generic ``leds-gpio`` and ``gpio-keys`` drivers will
+be able to probe successfully and get their configuration from the properties
+defined in the software nodes, removing the need for board-specific platform
+data.
diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst
deleted file mode 100644
index 9b12eeb89170..000000000000
--- a/Documentation/driver-api/gpio/legacy.rst
+++ /dev/null
@@ -1,769 +0,0 @@
-======================
-Legacy GPIO Interfaces
-======================
-
-This provides an overview of GPIO access conventions on Linux.
-
-These calls use the gpio_* naming prefix. No other calls should use that
-prefix, or the related __gpio_* prefix.
-
-
-What is a GPIO?
-===============
-A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
-digital signal. They are provided from many kinds of chip, and are familiar
-to Linux developers working with embedded and custom hardware. Each GPIO
-represents a bit connected to a particular pin, or "ball" on Ball Grid Array
-(BGA) packages. Board schematics show which external hardware connects to
-which GPIOs. Drivers can be written generically, so that board setup code
-passes such pin configuration data to drivers.
-
-System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every
-non-dedicated pin can be configured as a GPIO; and most chips have at least
-several dozen of them. Programmable logic devices (like FPGAs) can easily
-provide GPIOs; multifunction chips like power managers, and audio codecs
-often have a few such pins to help with pin scarcity on SOCs; and there are
-also "GPIO Expander" chips that connect using the I2C or SPI serial busses.
-Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
-firmware knowing how they're used).
-
-The exact capabilities of GPIOs vary between systems. Common options:
-
- - Output values are writable (high=1, low=0). Some chips also have
- options about how that value is driven, so that for example only one
- value might be driven ... supporting "wire-OR" and similar schemes
- for the other value (notably, "open drain" signaling).
-
- - Input values are likewise readable (1, 0). Some chips support readback
- of pins configured as "output", which is very useful in such "wire-OR"
- cases (to support bidirectional signaling). GPIO controllers may have
- input de-glitch/debounce logic, sometimes with software controls.
-
- - Inputs can often be used as IRQ signals, often edge triggered but
- sometimes level triggered. Such IRQs may be configurable as system
- wakeup events, to wake the system from a low power state.
-
- - Usually a GPIO will be configurable as either input or output, as needed
- by different product boards; single direction ones exist too.
-
- - Most GPIOs can be accessed while holding spinlocks, but those accessed
- through a serial bus normally can't. Some systems support both types.
-
-On a given board each GPIO is used for one specific purpose like monitoring
-MMC/SD card insertion/removal, detecting card writeprotect status, driving
-a LED, configuring a transceiver, bitbanging a serial bus, poking a hardware
-watchdog, sensing a switch, and so on.
-
-
-GPIO conventions
-================
-Note that this is called a "convention" because you don't need to do it this
-way, and it's no crime if you don't. There **are** cases where portability
-is not the main issue; GPIOs are often used for the kind of board-specific
-glue logic that may even change between board revisions, and can't ever be
-used on a board that's wired differently. Only least-common-denominator
-functionality can be very portable. Other features are platform-specific,
-and that can be critical for glue logic.
-
-Plus, this doesn't require any implementation framework, just an interface.
-One platform might implement it as simple inline functions accessing chip
-registers; another might implement it by delegating through abstractions
-used for several very different kinds of GPIO controller. (There is some
-optional code supporting such an implementation strategy, described later
-in this document, but drivers acting as clients to the GPIO interface must
-not care how it's implemented.)
-
-That said, if the convention is supported on their platform, drivers should
-use it when possible. Platforms must select GPIOLIB if GPIO functionality
-is strictly required. Drivers that can't work without
-standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The
-GPIO calls are available, either as "real code" or as optimized-away stubs,
-when drivers use the include file:
-
- #include <linux/gpio.h>
-
-If you stick to this convention then it'll be easier for other developers to
-see what your code is doing, and help maintain it.
-
-Note that these operations include I/O barriers on platforms which need to
-use them; drivers don't need to add them explicitly.
-
-
-Identifying GPIOs
------------------
-GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
-reserves "negative" numbers for other purposes like marking signals as
-"not available on this board", or indicating faults. Code that doesn't
-touch the underlying hardware treats these integers as opaque cookies.
-
-Platforms define how they use those integers, and usually #define symbols
-for the GPIO lines so that board-specific setup code directly corresponds
-to the relevant schematics. In contrast, drivers should only use GPIO
-numbers passed to them from that setup code, using platform_data to hold
-board-specific pin configuration data (along with other board specific
-data they need). That avoids portability problems.
-
-So for example one platform uses numbers 32-159 for GPIOs; while another
-uses numbers 0..63 with one set of GPIO controllers, 64-79 with another
-type of GPIO controller, and on one particular board 80-95 with an FPGA.
-The numbers need not be contiguous; either of those platforms could also
-use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
-
-If you want to initialize a structure with an invalid GPIO number, use
-some negative number (perhaps "-EINVAL"); that will never be valid. To
-test if such number from such a structure could reference a GPIO, you
-may use this predicate:
-
- int gpio_is_valid(int number);
-
-A number that's not valid will be rejected by calls which may request
-or free GPIOs (see below). Other numbers may also be rejected; for
-example, a number might be valid but temporarily unused on a given board.
-
-Whether a platform supports multiple GPIO controllers is a platform-specific
-implementation issue, as are whether that support can leave "holes" in the space
-of GPIO numbers, and whether new controllers can be added at runtime. Such issues
-can affect things including whether adjacent GPIO numbers are both valid.
-
-Using GPIOs
------------
-The first thing a system should do with a GPIO is allocate it, using
-the gpio_request() call; see later.
-
-One of the next things to do with a GPIO, often in board setup code when
-setting up a platform_device using the GPIO, is mark its direction::
-
- /* set as input or output, returning 0 or negative errno */
- int gpio_direction_input(unsigned gpio);
- int gpio_direction_output(unsigned gpio, int value);
-
-The return value is zero for success, else a negative errno. It should
-be checked, since the get/set calls don't have error returns and since
-misconfiguration is possible. You should normally issue these calls from
-a task context. However, for spinlock-safe GPIOs it's OK to use them
-before tasking is enabled, as part of early board setup.
-
-For output GPIOs, the value provided becomes the initial output value.
-This helps avoid signal glitching during system startup.
-
-For compatibility with legacy interfaces to GPIOs, setting the direction
-of a GPIO implicitly requests that GPIO (see below) if it has not been
-requested already. That compatibility is being removed from the optional
-gpiolib framework.
-
-Setting the direction can fail if the GPIO number is invalid, or when
-that particular GPIO can't be used in that mode. It's generally a bad
-idea to rely on boot firmware to have set the direction correctly, since
-it probably wasn't validated to do more than boot Linux. (Similarly,
-that board setup code probably needs to multiplex that pin as a GPIO,
-and configure pullups/pulldowns appropriately.)
-
-
-Spinlock-Safe GPIO access
--------------------------
-Most GPIO controllers can be accessed with memory read/write instructions.
-Those don't need to sleep, and can safely be done from inside hard
-(nonthreaded) IRQ handlers and similar contexts.
-
-Use the following calls to access such GPIOs,
-for which gpio_cansleep() will always return false (see below)::
-
- /* GPIO INPUT: return zero or nonzero */
- int gpio_get_value(unsigned gpio);
-
- /* GPIO OUTPUT */
- void gpio_set_value(unsigned gpio, int value);
-
-The values are boolean, zero for low, nonzero for high. When reading the
-value of an output pin, the value returned should be what's seen on the
-pin ... that won't always match the specified output value, because of
-issues including open-drain signaling and output latencies.
-
-The get/set calls have no error returns because "invalid GPIO" should have
-been reported earlier from gpio_direction_*(). However, note that not all
-platforms can read the value of output pins; those that can't should always
-return zero. Also, using these calls for GPIOs that can't safely be accessed
-without sleeping (see below) is an error.
-
-Platform-specific implementations are encouraged to optimize the two
-calls to access the GPIO value in cases where the GPIO number (and for
-output, value) are constant. It's normal for them to need only a couple
-of instructions in such cases (reading or writing a hardware register),
-and not to need spinlocks. Such optimized calls can make bitbanging
-applications a lot more efficient (in both space and time) than spending
-dozens of instructions on subroutine calls.
-
-
-GPIO access that may sleep
---------------------------
-Some GPIO controllers must be accessed using message based busses like I2C
-or SPI. Commands to read or write those GPIO values require waiting to
-get to the head of a queue to transmit a command and get its response.
-This requires sleeping, which can't be done from inside IRQ handlers.
-
-Platforms that support this type of GPIO distinguish them from other GPIOs
-by returning nonzero from this call (which requires a valid GPIO number,
-which should have been previously allocated with gpio_request)::
-
- int gpio_cansleep(unsigned gpio);
-
-To access such GPIOs, a different set of accessors is defined::
-
- /* GPIO INPUT: return zero or nonzero, might sleep */
- int gpio_get_value_cansleep(unsigned gpio);
-
- /* GPIO OUTPUT, might sleep */
- void gpio_set_value_cansleep(unsigned gpio, int value);
-
-
-Accessing such GPIOs requires a context which may sleep, for example
-a threaded IRQ handler, and those accessors must be used instead of
-spinlock-safe accessors without the cansleep() name suffix.
-
-Other than the fact that these accessors might sleep, and will work
-on GPIOs that can't be accessed from hardIRQ handlers, these calls act
-the same as the spinlock-safe calls.
-
-**IN ADDITION** calls to setup and configure such GPIOs must be made
-from contexts which may sleep, since they may need to access the GPIO
-controller chip too (These setup calls are usually made from board
-setup or driver probe/teardown code, so this is an easy constraint.)::
-
- gpio_direction_input()
- gpio_direction_output()
- gpio_request()
-
- ## gpio_request_one()
- ## gpio_request_array()
- ## gpio_free_array()
-
- gpio_free()
- gpio_set_debounce()
-
-
-
-Claiming and Releasing GPIOs
-----------------------------
-To help catch system configuration errors, two calls are defined::
-
- /* request GPIO, returning 0 or negative errno.
- * non-null labels may be useful for diagnostics.
- */
- int gpio_request(unsigned gpio, const char *label);
-
- /* release previously-claimed GPIO */
- void gpio_free(unsigned gpio);
-
-Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
-GPIOs that have already been claimed with that call. The return value of
-gpio_request() must be checked. You should normally issue these calls from
-a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs
-before tasking is enabled, as part of early board setup.
-
-These calls serve two basic purposes. One is marking the signals which
-are actually in use as GPIOs, for better diagnostics; systems may have
-several hundred potential GPIOs, but often only a dozen are used on any
-given board. Another is to catch conflicts, identifying errors when
-(a) two or more drivers wrongly think they have exclusive use of that
-signal, or (b) something wrongly believes it's safe to remove drivers
-needed to manage a signal that's in active use. That is, requesting a
-GPIO can serve as a kind of lock.
-
-Some platforms may also use knowledge about what GPIOs are active for
-power management, such as by powering down unused chip sectors and, more
-easily, gating off unused clocks.
-
-For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
-be informed of their use; a gpiolib driver's .request() operation may call
-pinctrl_gpio_request(), and a gpiolib driver's .free() operation may call
-pinctrl_gpio_free(). The pinctrl subsystem allows a pinctrl_gpio_request()
-to succeed concurrently with a pin or pingroup being "owned" by a device for
-pin multiplexing.
-
-Any programming of pin multiplexing hardware that is needed to route the
-GPIO signal to the appropriate pin should occur within a GPIO driver's
-.direction_input() or .direction_output() operations, and occur after any
-setup of an output GPIO's value. This allows a glitch-free migration from a
-pin's special function to GPIO. This is sometimes required when using a GPIO
-to implement a workaround on signals typically driven by a non-GPIO HW block.
-
-Some platforms allow some or all GPIO signals to be routed to different pins.
-Similarly, other aspects of the GPIO or pin may need to be configured, such as
-pullup/pulldown. Platform software should arrange that any such details are
-configured prior to gpio_request() being called for those GPIOs, e.g. using
-the pinctrl subsystem's mapping table, so that GPIO users need not be aware
-of these details.
-
-Also note that it's your responsibility to have stopped using a GPIO
-before you free it.
-
-Considering in most cases GPIOs are actually configured right after they
-are claimed, three additional calls are defined::
-
- /* request a single GPIO, with initial configuration specified by
- * 'flags', identical to gpio_request() wrt other arguments and
- * return value
- */
- int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);
-
- /* request multiple GPIOs in a single call
- */
- int gpio_request_array(struct gpio *array, size_t num);
-
- /* release multiple GPIOs in a single call
- */
- void gpio_free_array(struct gpio *array, size_t num);
-
-where 'flags' is currently defined to specify the following properties:
-
- * GPIOF_DIR_IN - to configure direction as input
- * GPIOF_DIR_OUT - to configure direction as output
-
- * GPIOF_INIT_LOW - as output, set initial level to LOW
- * GPIOF_INIT_HIGH - as output, set initial level to HIGH
- * GPIOF_OPEN_DRAIN - gpio pin is open drain type.
- * GPIOF_OPEN_SOURCE - gpio pin is open source type.
-
- * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction
- * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction
-
-since GPIOF_INIT_* are only valid when configured as output, so group valid
-combinations as:
-
- * GPIOF_IN - configure as input
- * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
- * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
-
-When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
-open drain type. Such pins will not be driven to 1 in output mode. It is
-require to connect pull-up on such pins. By enabling this flag, gpio lib will
-make the direction to input when it is asked to set value of 1 in output mode
-to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode.
-
-When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is
-open source type. Such pins will not be driven to 0 in output mode. It is
-require to connect pull-down on such pin. By enabling this flag, gpio lib will
-make the direction to input when it is asked to set value of 0 in output mode
-to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode.
-
-In the future, these flags can be extended to support more properties.
-
-Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is
-introduced to encapsulate all three fields as::
-
- struct gpio {
- unsigned gpio;
- unsigned long flags;
- const char *label;
- };
-
-A typical example of usage::
-
- static struct gpio leds_gpios[] = {
- { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */
- { 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* default to OFF */
- { 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* default to OFF */
- { 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* default to OFF */
- { ... },
- };
-
- err = gpio_request_one(31, GPIOF_IN, "Reset Button");
- if (err)
- ...
-
- err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios));
- if (err)
- ...
-
- gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios));
-
-
-GPIOs mapped to IRQs
---------------------
-GPIO numbers are unsigned integers; so are IRQ numbers. These make up
-two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
-map between them using calls like::
-
- /* map GPIO numbers to IRQ numbers */
- int gpio_to_irq(unsigned gpio);
-
- /* map IRQ numbers to GPIO numbers (avoid using this) */
- int irq_to_gpio(unsigned irq);
-
-Those return either the corresponding number in the other namespace, or
-else a negative errno code if the mapping can't be done. (For example,
-some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO
-number that wasn't set up as an input using gpio_direction_input(), or
-to use an IRQ number that didn't originally come from gpio_to_irq().
-
-These two mapping calls are expected to cost on the order of a single
-addition or subtraction. They're not allowed to sleep.
-
-Non-error values returned from gpio_to_irq() can be passed to request_irq()
-or free_irq(). They will often be stored into IRQ resources for platform
-devices, by the board-specific initialization code. Note that IRQ trigger
-options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
-system wakeup capabilities.
-
-Non-error values returned from irq_to_gpio() would most commonly be used
-with gpio_get_value(), for example to initialize or update driver state
-when the IRQ is edge-triggered. Note that some platforms don't support
-this reverse mapping, so you should avoid using it.
-
-
-Emulating Open Drain Signals
-----------------------------
-Sometimes shared signals need to use "open drain" signaling, where only the
-low signal level is actually driven. (That term applies to CMOS transistors;
-"open collector" is used for TTL.) A pullup resistor causes the high signal
-level. This is sometimes called a "wire-AND"; or more practically, from the
-negative logic (low=true) perspective this is a "wire-OR".
-
-One common example of an open drain signal is a shared active-low IRQ line.
-Also, bidirectional data bus signals sometimes use open drain signals.
-
-Some GPIO controllers directly support open drain outputs; many don't. When
-you need open drain signaling but your hardware doesn't directly support it,
-there's a common idiom you can use to emulate it with any GPIO pin that can
-be used as either an input or an output:
-
- LOW: gpio_direction_output(gpio, 0) ... this drives the signal
- and overrides the pullup.
-
- HIGH: gpio_direction_input(gpio) ... this turns off the output,
- so the pullup (or some other device) controls the signal.
-
-If you are "driving" the signal high but gpio_get_value(gpio) reports a low
-value (after the appropriate rise time passes), you know some other component
-is driving the shared signal low. That's not necessarily an error. As one
-common example, that's how I2C clocks are stretched: a slave that needs a
-slower clock delays the rising edge of SCK, and the I2C master adjusts its
-signaling rate accordingly.
-
-
-GPIO controllers and the pinctrl subsystem
-------------------------------------------
-
-A GPIO controller on a SOC might be tightly coupled with the pinctrl
-subsystem, in the sense that the pins can be used by other functions
-together with an optional gpio feature. We have already covered the
-case where e.g. a GPIO controller need to reserve a pin or set the
-direction of a pin by calling any of::
-
- pinctrl_gpio_request()
- pinctrl_gpio_free()
- pinctrl_gpio_direction_input()
- pinctrl_gpio_direction_output()
-
-But how does the pin control subsystem cross-correlate the GPIO
-numbers (which are a global business) to a certain pin on a certain
-pin controller?
-
-This is done by registering "ranges" of pins, which are essentially
-cross-reference tables. These are described in
-Documentation/driver-api/pin-control.rst
-
-While the pin allocation is totally managed by the pinctrl subsystem,
-gpio (under gpiolib) is still maintained by gpio drivers. It may happen
-that different pin ranges in a SoC is managed by different gpio drivers.
-
-This makes it logical to let gpio drivers announce their pin ranges to
-the pin ctrl subsystem before it will call 'pinctrl_gpio_request' in order
-to request the corresponding pin to be prepared by the pinctrl subsystem
-before any gpio usage.
-
-For this, the gpio controller can register its pin range with pinctrl
-subsystem. There are two ways of doing it currently: with or without DT.
-
-For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt.
-
-For non-DT support, user can call gpiochip_add_pin_range() with appropriate
-parameters to register a range of gpio pins with a pinctrl driver. For this
-exact name string of pinctrl device has to be passed as one of the
-argument to this routine.
-
-
-What do these conventions omit?
-===============================
-One of the biggest things these conventions omit is pin multiplexing, since
-this is highly chip-specific and nonportable. One platform might not need
-explicit multiplexing; another might have just two options for use of any
-given pin; another might have eight options per pin; another might be able
-to route a given GPIO to any one of several pins. (Yes, those examples all
-come from systems that run Linux today.)
-
-Related to multiplexing is configuration and enabling of the pullups or
-pulldowns integrated on some platforms. Not all platforms support them,
-or support them in the same way; and any given board might use external
-pullups (or pulldowns) so that the on-chip ones should not be used.
-(When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
-Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a
-platform-specific issue, as are models like (not) having a one-to-one
-correspondence between configurable pins and GPIOs.
-
-There are other system-specific mechanisms that are not specified here,
-like the aforementioned options for input de-glitching and wire-OR output.
-Hardware may support reading or writing GPIOs in gangs, but that's usually
-configuration dependent: for GPIOs sharing the same bank. (GPIOs are
-commonly grouped in banks of 16 or 32, with a given SOC having several such
-banks.) Some systems can trigger IRQs from output GPIOs, or read values
-from pins not managed as GPIOs. Code relying on such mechanisms will
-necessarily be nonportable.
-
-Dynamic definition of GPIOs is not currently standard; for example, as
-a side effect of configuring an add-on board with some GPIO expanders.
-
-
-GPIO implementor's framework (OPTIONAL)
-=======================================
-As noted earlier, there is an optional implementation framework making it
-easier for platforms to support different kinds of GPIO controller using
-the same programming interface. This framework is called "gpiolib".
-
-As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file
-will be found there. That will list all the controllers registered through
-this framework, and the state of the GPIOs currently in use.
-
-
-Controller Drivers: gpio_chip
------------------------------
-In this framework each GPIO controller is packaged as a "struct gpio_chip"
-with information common to each controller of that type:
-
- - methods to establish GPIO direction
- - methods used to access GPIO values
- - flag saying whether calls to its methods may sleep
- - optional debugfs dump method (showing extra state like pullup config)
- - label for diagnostics
-
-There is also per-instance data, which may come from device.platform_data:
-the number of its first GPIO, and how many GPIOs it exposes.
-
-The code implementing a gpio_chip should support multiple instances of the
-controller, possibly using the driver model. That code will configure each
-gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be
-rare; use gpiochip_remove() when it is unavoidable.
-
-Most often a gpio_chip is part of an instance-specific structure with state
-not exposed by the GPIO interfaces, such as addressing, power management,
-and more. Chips such as codecs will have complex non-GPIO state.
-
-Any debugfs dump method should normally ignore signals which haven't been
-requested as GPIOs. They can use gpiochip_is_requested(), which returns
-either NULL or the label associated with that GPIO when it was requested.
-
-
-Platform Support
-----------------
-To force-enable this framework, a platform's Kconfig will "select" GPIOLIB,
-else it is up to the user to configure support for GPIO.
-
-It may also provide a custom value for ARCH_NR_GPIOS, so that it better
-reflects the number of GPIOs in actual use on that platform, without
-wasting static table space. (It should count both built-in/SoC GPIOs and
-also ones on GPIO expanders.
-
-If neither of these options are selected, the platform does not support
-GPIOs through GPIO-lib and the code cannot be enabled by the user.
-
-Trivial implementations of those functions can directly use framework
-code, which always dispatches through the gpio_chip::
-
- #define gpio_get_value __gpio_get_value
- #define gpio_set_value __gpio_set_value
- #define gpio_cansleep __gpio_cansleep
-
-Fancier implementations could instead define those as inline functions with
-logic optimizing access to specific SOC-based GPIOs. For example, if the
-referenced GPIO is the constant "12", getting or setting its value could
-cost as little as two or three instructions, never sleeping. When such an
-optimization is not possible those calls must delegate to the framework
-code, costing at least a few dozen instructions. For bitbanged I/O, such
-instruction savings can be significant.
-
-For SOCs, platform-specific code defines and registers gpio_chip instances
-for each bank of on-chip GPIOs. Those GPIOs should be numbered/labeled to
-match chip vendor documentation, and directly match board schematics. They
-may well start at zero and go up to a platform-specific limit. Such GPIOs
-are normally integrated into platform initialization to make them always be
-available, from arch_initcall() or earlier; they can often serve as IRQs.
-
-
-Board Support
--------------
-For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi
-function devices, FPGAs or CPLDs -- most often board-specific code handles
-registering controller devices and ensures that their drivers know what GPIO
-numbers to use with gpiochip_add(). Their numbers often start right after
-platform-specific GPIOs.
-
-For example, board setup code could create structures identifying the range
-of GPIOs that chip will expose, and passes them to each GPIO expander chip
-using platform_data. Then the chip driver's probe() routine could pass that
-data to gpiochip_add().
-
-Initialization order can be important. For example, when a device relies on
-an I2C-based GPIO, its probe() routine should only be called after that GPIO
-becomes available. That may mean the device should not be registered until
-calls for that GPIO can work. One way to address such dependencies is for
-such gpio_chip controllers to provide setup() and teardown() callbacks to
-board specific code; those board specific callbacks would register devices
-once all the necessary resources are available, and remove them later when
-the GPIO controller device becomes unavailable.
-
-
-Sysfs Interface for Userspace (OPTIONAL)
-========================================
-Platforms which use the "gpiolib" implementors framework may choose to
-configure a sysfs user interface to GPIOs. This is different from the
-debugfs interface, since it provides control over GPIO direction and
-value instead of just showing a gpio state summary. Plus, it could be
-present on production systems without debugging support.
-
-Given appropriate hardware documentation for the system, userspace could
-know for example that GPIO #23 controls the write protect line used to
-protect boot loader segments in flash memory. System upgrade procedures
-may need to temporarily remove that protection, first importing a GPIO,
-then changing its output state, then updating the code before re-enabling
-the write protection. In normal use, GPIO #23 would never be touched,
-and the kernel would have no need to know about it.
-
-Again depending on appropriate hardware documentation, on some systems
-userspace GPIO can be used to determine system configuration data that
-standard kernels won't know about. And for some tasks, simple userspace
-GPIO drivers could be all that the system really needs.
-
-Note that standard kernel drivers exist for common "LEDs and Buttons"
-GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those
-instead of talking directly to the GPIOs; they integrate with kernel
-frameworks better than your userspace code could.
-
-
-Paths in Sysfs
---------------
-There are three kinds of entry in /sys/class/gpio:
-
- - Control interfaces used to get userspace control over GPIOs;
-
- - GPIOs themselves; and
-
- - GPIO controllers ("gpio_chip" instances).
-
-That's in addition to standard files including the "device" symlink.
-
-The control interfaces are write-only:
-
- /sys/class/gpio/
-
- "export" ... Userspace may ask the kernel to export control of
- a GPIO to userspace by writing its number to this file.
-
- Example: "echo 19 > export" will create a "gpio19" node
- for GPIO #19, if that's not requested by kernel code.
-
- "unexport" ... Reverses the effect of exporting to userspace.
-
- Example: "echo 19 > unexport" will remove a "gpio19"
- node exported using the "export" file.
-
-GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)
-and have the following read/write attributes:
-
- /sys/class/gpio/gpioN/
-
- "direction" ... reads as either "in" or "out". This value may
- normally be written. Writing as "out" defaults to
- initializing the value as low. To ensure glitch free
- operation, values "low" and "high" may be written to
- configure the GPIO as an output with that initial value.
-
- Note that this attribute *will not exist* if the kernel
- doesn't support changing the direction of a GPIO, or
- it was exported by kernel code that didn't explicitly
- allow userspace to reconfigure this GPIO's direction.
-
- "value" ... reads as either 0 (low) or 1 (high). If the GPIO
- is configured as an output, this value may be written;
- any nonzero value is treated as high.
-
- If the pin can be configured as interrupt-generating interrupt
- and if it has been configured to generate interrupts (see the
- description of "edge"), you can poll(2) on that file and
- poll(2) will return whenever the interrupt was triggered. If
- you use poll(2), set the events POLLPRI. If you use select(2),
- set the file descriptor in exceptfds. After poll(2) returns,
- either lseek(2) to the beginning of the sysfs file and read the
- new value or close the file and re-open it to read the value.
-
- "edge" ... reads as either "none", "rising", "falling", or
- "both". Write these strings to select the signal edge(s)
- that will make poll(2) on the "value" file return.
-
- This file exists only if the pin can be configured as an
- interrupt generating input pin.
-
- "active_low" ... reads as either 0 (false) or 1 (true). Write
- any nonzero value to invert the value attribute both
- for reading and writing. Existing and subsequent
- poll(2) support configuration via the edge attribute
- for "rising" and "falling" edges will follow this
- setting.
-
-GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
-controller implementing GPIOs starting at #42) and have the following
-read-only attributes:
-
- /sys/class/gpio/gpiochipN/
-
- "base" ... same as N, the first GPIO managed by this chip
-
- "label" ... provided for diagnostics (not always unique)
-
- "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
-
-Board documentation should in most cases cover what GPIOs are used for
-what purposes. However, those numbers are not always stable; GPIOs on
-a daughtercard might be different depending on the base board being used,
-or other cards in the stack. In such cases, you may need to use the
-gpiochip nodes (possibly in conjunction with schematics) to determine
-the correct GPIO number to use for a given signal.
-
-
-Exporting from Kernel code
---------------------------
-Kernel code can explicitly manage exports of GPIOs which have already been
-requested using gpio_request()::
-
- /* export the GPIO to userspace */
- int gpio_export(unsigned gpio, bool direction_may_change);
-
- /* reverse gpio_export() */
- void gpio_unexport();
-
- /* create a sysfs link to an exported GPIO node */
- int gpio_export_link(struct device *dev, const char *name,
- unsigned gpio)
-
-After a kernel driver requests a GPIO, it may only be made available in
-the sysfs interface by gpio_export(). The driver can control whether the
-signal direction may change. This helps drivers prevent userspace code
-from accidentally clobbering important system state.
-
-This explicit exporting can help with debugging (by making some kinds
-of experiments easier), or can provide an always-there interface that's
-suitable for documenting as part of a board support package.
-
-After the GPIO has been exported, gpio_export_link() allows creating
-symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can
-use this to provide the interface under their own device in sysfs with
-a descriptive name.
-
-
-API Reference
-=============
-
-The functions listed in this section are deprecated. The GPIO descriptor based
-API should be used in new code.
-
-.. kernel-doc:: drivers/gpio/gpiolib-legacy.c
- :export:
diff --git a/Documentation/driver-api/gpio/pca953x.rst b/Documentation/driver-api/gpio/pca953x.rst
new file mode 100644
index 000000000000..4bd7cf1120cb
--- /dev/null
+++ b/Documentation/driver-api/gpio/pca953x.rst
@@ -0,0 +1,552 @@
+============================================
+PCA953x I²C GPIO expander compatibility list
+============================================
+
+:Author: Levente Révész <levente.revesz@eilabs.com>
+
+I went through all the datasheets and created this note listing
+chip functions and register layouts.
+
+Overview of chips
+=================
+
+Chips with the basic 4 registers
+--------------------------------
+
+These chips have 4 register banks: input, output, invert and direction.
+Each of these banks contains (lines/8) registers, one for each GPIO port.
+
+Banks offset is always a power of 2:
+
+- 4 lines -> bank offset is 1
+- 8 lines -> bank offset is 1
+- 16 lines -> bank offset is 2
+- 24 lines -> bank offset is 4
+- 32 lines -> bank offset is 4
+- 40 lines -> bank offset is 8
+
+For example, register layout of GPIO expander with 24 lines:
+
++------+-----------------+--------+
+| addr | function | bank |
++======+=================+========+
+| 00 | input port0 | |
++------+-----------------+ |
+| 01 | input port1 | bank 0 |
++------+-----------------+ |
+| 02 | input port2 | |
++------+-----------------+--------+
+| 03 | n/a | |
++------+-----------------+--------+
+| 04 | output port0 | |
++------+-----------------+ |
+| 05 | output port1 | bank 1 |
++------+-----------------+ |
+| 06 | output port2 | |
++------+-----------------+--------+
+| 07 | n/a | |
++------+-----------------+--------+
+| 08 | invert port0 | |
++------+-----------------+ |
+| 09 | invert port1 | bank 2 |
++------+-----------------+ |
+| 0A | invert port2 | |
++------+-----------------+--------+
+| 0B | n/a | |
++------+-----------------+--------+
+| 0C | direction port0 | |
++------+-----------------+ |
+| 0D | direction port1 | bank 3 |
++------+-----------------+ |
+| 0E | direction port2 | |
++------+-----------------+--------+
+| 0F | n/a | |
++------+-----------------+--------+
+
+.. note::
+ This is followed by all supported chips, except by pcal6534.
+
+The table below shows the offsets for each of the compatible chips:
+
+========== ===== ========= ===== ====== ====== =========
+compatible lines interrupt input output invert direction
+========== ===== ========= ===== ====== ====== =========
+pca9536 4 no 00 01 02 03
+pca9537 4 yes 00 01 02 03
+pca6408 8 yes 00 01 02 03
+tca6408 8 yes 00 01 02 03
+pca9534 8 yes 00 01 02 03
+pca9538 8 yes 00 01 02 03
+pca9554 8 yes 00 01 02 03
+tca9554 8 yes 00 01 02 03
+pca9556 8 no 00 01 02 03
+pca9557 8 no 00 01 02 03
+pca6107 8 yes 00 01 02 03
+pca6416 16 yes 00 02 04 06
+tca6416 16 yes 00 02 04 06
+pca9535 16 yes 00 02 04 06
+pca9539 16 yes 00 02 04 06
+tca9539 16 yes 00 02 04 06
+pca9555 16 yes 00 02 04 06
+max7318 16 yes 00 02 04 06
+tca6424 24 yes 00 04 08 0C
+========== ===== ========= ===== ====== ====== =========
+
+Chips with additional timeout_en register
+-----------------------------------------
+
+These Maxim chips have a bus timeout function which can be enabled in
+the timeout_en register. This is present in only two chips. Defaults to
+timeout disabled.
+
+========== ===== ========= ===== ====== ====== ========= ==========
+compatible lines interrupt input output invert direction timeout_en
+========== ===== ========= ===== ====== ====== ========= ==========
+max7310 8 no 00 01 02 03 04
+max7312 16 yes 00 02 04 06 08
+========== ===== ========= ===== ====== ====== ========= ==========
+
+Chips with additional int_mask register
+---------------------------------------
+
+These chips have an interrupt mask register in addition to the 4 basic
+registers. The interrupt masks default to all interrupts disabled. To
+use interrupts with these chips, the driver has to set the int_mask
+register.
+
+========== ===== ========= ===== ====== ====== ========= ========
+compatible lines interrupt input output invert direction int_mask
+========== ===== ========= ===== ====== ====== ========= ========
+pca9505 40 yes 00 08 10 18 20
+pca9506 40 yes 00 08 10 18 20
+========== ===== ========= ===== ====== ====== ========= ========
+
+Chips with additional int_mask and out_conf registers
+-----------------------------------------------------
+
+This chip has an interrupt mask register, and an output port
+configuration register, which can select between push-pull and
+open-drain modes. Each bit controls two lines. Both of these registers
+are present in PCAL chips as well, albeit the out_conf works
+differently.
+
+========== ===== ========= ===== ====== ====== ========= ======== ========
+compatible lines interrupt input output invert direction int_mask out_conf
+========== ===== ========= ===== ====== ====== ========= ======== ========
+pca9698 40 yes 00 08 10 18 20 28
+========== ===== ========= ===== ====== ====== ========= ======== ========
+
+pca9698 also has a "master output" register for setting all outputs per
+port to the same value simultaneously, and a chip specific mode register
+for various additional chip settings.
+
+========== ============= ====
+compatible master_output mode
+========== ============= ====
+pca9698 29 2A
+========== ============= ====
+
+Chips with LED blink and intensity control
+------------------------------------------
+
+These Maxim chips have no invert register.
+
+They have two sets of output registers (output0 and output1). An internal
+timer alternates the effective output between the values set in these
+registers, if blink mode is enabled in the blink register. The
+master_intensity register and the intensity registers together define
+the PWM intensity value for each pair of outputs.
+
+These chips can be used as simple GPIO expanders if the driver handles the
+input, output0 and direction registers.
+
+========== ===== ========= ===== ======= ========= ======= ================ ===== =========
+compatible lines interrupt input output0 direction output1 master_intensity blink intensity
+========== ===== ========= ===== ======= ========= ======= ================ ===== =========
+max7315 8 yes 00 01 03 09 0E 0F 10
+max7313 16 yes 00 02 06 0A 0E 0F 10
+========== ===== ========= ===== ======= ========= ======= ================ ===== =========
+
+Basic PCAL chips
+----------------
+
+========== ===== ========= ===== ====== ====== =========
+compatible lines interrupt input output invert direction
+========== ===== ========= ===== ====== ====== =========
+pcal6408 8 yes 00 01 02 03
+pcal9554b 8 yes 00 01 02 03
+pcal6416 16 yes 00 02 04 06
+pcal9535 16 yes 00 02 04 06
+pcal9555a 16 yes 00 02 04 06
+========== ===== ========= ===== ====== ====== =========
+
+These chips have several additional features:
+
+ 1. output drive strength setting (out_strength)
+ 2. input latch (in_latch)
+ 3. pull-up/pull-down (pull_in, pull_sel)
+ 4. push-pull/open-drain outputs (out_conf)
+ 5. interrupt mask and interrupt status (int_mask, int_status)
+
+========== ============ ======== ======= ======== ======== ========== ========
+compatible out_strength in_latch pull_en pull_sel int_mask int_status out_conf
+========== ============ ======== ======= ======== ======== ========== ========
+pcal6408 40 42 43 44 45 46 4F
+pcal9554b 40 42 43 44 45 46 4F
+pcal6416 40 44 46 48 4A 4C 4F
+pcal9535 40 44 46 48 4A 4C 4F
+pcal9555a 40 44 46 48 4A 4C 4F
+========== ============ ======== ======= ======== ======== ========== ========
+
+Currently the driver has support for the input latch, pull-up/pull-down
+and uses int_mask and int_status for interrupts.
+
+PCAL chips with extended interrupt and output configuration functions
+---------------------------------------------------------------------
+
+========== ===== ========= ===== ====== ====== =========
+compatible lines interrupt input output invert direction
+========== ===== ========= ===== ====== ====== =========
+pcal6524 24 yes 00 04 08 0C
+pcal6534 34 yes 00 05 0A 0F
+========== ===== ========= ===== ====== ====== =========
+
+These chips have the full PCAL register set, plus the following functions:
+
+ 1. interrupt event selection: level, rising, falling, any edge
+ 2. clear interrupt status per line
+ 3. read input without clearing interrupt status
+ 4. individual output config (push-pull/open-drain) per output line
+ 5. debounce inputs
+
+========== ============ ======== ======= ======== ======== ========== ========
+compatible out_strength in_latch pull_en pull_sel int_mask int_status out_conf
+========== ============ ======== ======= ======== ======== ========== ========
+pcal6524 40 48 4C 50 54 58 5C
+pcal6534 30 3A 3F 44 49 4E 53
+========== ============ ======== ======= ======== ======== ========== ========
+
+========== ======== ========= ============ ============== ======== ==============
+compatible int_edge int_clear input_status indiv_out_conf debounce debounce_count
+========== ======== ========= ============ ============== ======== ==============
+pcal6524 60 68 6C 70 74 76
+pcal6534 54 5E 63 68 6D 6F
+========== ======== ========= ============ ============== ======== ==============
+
+As can be seen in the table above, pcal6534 does not follow the usual
+bank spacing rule. Its banks are closely packed instead.
+
+PCA957X chips with a completely different register layout
+---------------------------------------------------------
+
+These chips have the basic 4 registers, but at unusual addresses.
+
+Additionally, they have:
+
+ 1. pull-up/pull-down (pull_sel)
+ 2. a global pull enable, defaults to disabled (config)
+ 3. interrupt mask, interrupt status (int_mask, int_status)
+
+========== ===== ========= ===== ====== ====== ======== ========= ====== ======== ==========
+compatible lines interrupt input invert config pull_sel direction output int_mask int_status
+========== ===== ========= ===== ====== ====== ======== ========= ====== ======== ==========
+pca9574 8 yes 00 01 02 03 04 05 06 07
+pca9575 16 yes 00 02 04 06 08 0A 0C 0E
+========== ===== ========= ===== ====== ====== ======== ========= ====== ======== ==========
+
+Currently the driver supports none of the advanced features.
+
+XRA1202
+-------
+
+Basic 4 registers, plus advanced features:
+
+ 1. interrupt mask, defaults to interrupts disabled
+ 2. interrupt status
+ 3. interrupt event selection, level, rising, falling, any edge
+ (int_mask, rising_mask, falling_mask)
+ 4. pull-up (no pull-down)
+ 5. tri-state
+ 6. debounce
+
+========== ===== ========= ===== ====== ====== ========= =========
+compatible lines interrupt input output invert direction pullup_en
+========== ===== ========= ===== ====== ====== ========= =========
+xra1202 8 yes 00 01 02 03 04
+========== ===== ========= ===== ====== ====== ========= =========
+
+========== ======== ======== ========== =========== ============ ========
+compatible int_mask tristate int_status rising_mask falling_mask debounce
+========== ======== ======== ========== =========== ============ ========
+xra1202 05 06 07 08 09 0A
+========== ======== ======== ========== =========== ============ ========
+
+Overview of functions
+=====================
+
+This section lists chip functions that are supported by the driver
+already, or are at least common in multiple chips.
+
+Input, Output, Invert, Direction
+--------------------------------
+
+The basic 4 GPIO functions are present in all but one chip category, i.e.
+`Chips with LED blink and intensity control`_ are missing the invert
+register.
+
+3 different layouts are used for these registers:
+
+ 1. banks 0, 1, 2, 3 with bank offsets of 2^n
+ - all other chips
+
+ 2. banks 0, 1, 2, 3 with closely packed banks
+ - pcal6534
+
+ 3. banks 0, 5, 1, 4 with bank offsets of 2^n
+ - pca9574
+ - pca9575
+
+Interrupts
+----------
+
+Only an interrupt mask register
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The same layout is used for all of these:
+
+ 1. bank 5 with bank offsets of 2^n
+ - pca9505
+ - pca9506
+ - pca9698
+
+Interrupt mask and interrupt status registers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+These work the same way in all of the chips: mask and status have
+one bit per line, 1 in the mask means interrupt enabled.
+
+Layouts:
+
+ 1. base offset 0x40, bank 5 and bank 6, bank offsets of 2^n
+ - pcal6408
+ - pcal6416
+ - pcal9535
+ - pcal9554b
+ - pcal9555a
+ - pcal6524
+
+ 2. base offset 0x30, bank 5 and 6, closely packed banks
+ - pcal6534
+
+ 3. bank 6 and 7, bank offsets of 2^n
+ - pca9574
+ - pca9575
+
+ 4. bank 5 and 7, bank offsets of 2^n
+ - xra1202
+
+Interrupt on specific edges
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+`PCAL chips with extended interrupt and output configuration functions`_
+have an int_edge register. This contains 2 bits per line, one of 4 events
+can be selected for each line:
+
+ 0: level, 1: rising edge, 2: falling edge, 3: any edge
+
+Layouts:
+
+ 1. base offset 0x40, bank 7, bank offsets of 2^n
+
+ - pcal6524
+
+ 2. base offset 0x30, bank 7 + offset 0x01, closely packed banks
+ (out_conf is 1 byte, not (lines/8) bytes, hence the 0x01 offset)
+
+ - pcal6534
+
+`XRA1202`_ chips have a different mechanism for the same thing: they have
+a rising mask and a falling mask, with one bit per line.
+
+Layout:
+
+ 1. bank 5, bank offsets of 2^n
+
+Input latch
+-----------
+
+Only `Basic PCAL chips`_ and
+`PCAL chips with extended interrupt and output configuration functions`_
+have this function. When the latch is enabled, the interrupt is not cleared
+until the input port is read. When the latch is disabled, the interrupt
+is cleared even if the input register is not read, if the input pin returns
+to the logic value it had before generating the interrupt. Defaults to latch
+disabled.
+
+Currently the driver enables the latch for each line with interrupt
+enabled.
+
+ 1. base offset 0x40, bank 2, bank offsets of 2^n
+ - pcal6408
+ - pcal6416
+ - pcal9535
+ - pcal9554b
+ - pcal9555a
+ - pcal6524
+
+ 2. base offset 0x30, bank 2, closely packed banks
+ - pcal6534
+
+Pull-up and pull-down
+---------------------
+
+`Basic PCAL chips`_ and
+`PCAL chips with extended interrupt and output configuration functions`_
+use the same mechanism: their pull_en register enables the pull-up or pull-down
+function, and their pull_sel register chooses the direction. They all use one
+bit per line.
+
+ 0: pull-down, 1: pull-up
+
+Layouts:
+
+ 1. base offset 0x40, bank 3 (en) and 4 (sel), bank offsets of 2^n
+ - pcal6408
+ - pcal6416
+ - pcal9535
+ - pcal9554b
+ - pcal9555a
+ - pcal6524
+
+ 2. base offset 0x30, bank 3 (en) and 4 (sel), closely packed banks
+ - pcal6534
+
+`PCA957X chips with a completely different register layout`_ have a pull_sel
+register with one bit per line, and a global pull_en bit in their config
+register.
+
+Layout:
+
+ 1. bank 2 (config), bank 3 (sel), bank offsets of 2^n
+ - pca9574
+ - pca9575
+
+`XRA1202`_ chips can only pull-up. They have a pullup_en register.
+
+Layout:
+
+ 1. bank 4, bank offsets of 2^n
+ - xra1202
+
+Push-pull and open-drain
+------------------------
+
+`Chips with additional int_mask and out_conf registers`_ have this function,
+but only for select IO ports. Register has 1 bit per 2 lines. In pca9698,
+only port0 and port1 have this function.
+
+ 0: open-drain, 1: push-pull
+
+Layout:
+
+ 1. base offset 5*bankoffset
+ - pca9698
+
+`Basic PCAL chips`_ have 1 bit per port in one single out_conf register.
+Only whole ports can be configured.
+
+ 0: push-pull, 1: open-drain
+
+Layout:
+
+ 1. base offset 0x4F
+ - pcal6408
+ - pcal6416
+ - pcal9535
+ - pcal9554b
+ - pcal9555a
+
+`PCAL chips with extended interrupt and output configuration functions`_
+can set this for each line individually. They have the same per-port out_conf
+register as `Basic PCAL chips`_, but they also have an indiv_out_conf register
+with one bit per line, which inverts the effect of the port-wise setting.
+
+ 0: push-pull, 1: open-drain
+
+Layouts:
+
+ 1. base offset 0x40 + 7*bankoffset (out_conf),
+ base offset 0x60, bank 4 (indiv_out_conf) with bank offset of 2^n
+
+ - pcal6524
+
+ 2. base offset 0x30 + 7*banksize (out_conf),
+ base offset 0x54, bank 4 (indiv_out_conf), closely packed banks
+
+ - pcal6534
+
+This function is currently not supported by the driver.
+
+Output drive strength
+---------------------
+
+Only PCAL chips have this function. 2 bits per line.
+
+==== ==============
+bits drive strength
+==== ==============
+ 00 0.25x
+ 01 0.50x
+ 10 0.75x
+ 11 1.00x
+==== ==============
+
+ 1. base offset 0x40, bank 0 and 1, bank offsets of 2^n
+ - pcal6408
+ - pcal6416
+ - pcal9535
+ - pcal9554b
+ - pcal9555a
+ - pcal6524
+
+ 2. base offset 0x30, bank 0 and 1, closely packed banks
+ - pcal6534
+
+Currently not supported by the driver.
+
+Datasheets
+==========
+
+- MAX7310: https://datasheets.maximintegrated.com/en/ds/MAX7310.pdf
+- MAX7312: https://datasheets.maximintegrated.com/en/ds/MAX7312.pdf
+- MAX7313: https://datasheets.maximintegrated.com/en/ds/MAX7313.pdf
+- MAX7315: https://datasheets.maximintegrated.com/en/ds/MAX7315.pdf
+- MAX7318: https://datasheets.maximintegrated.com/en/ds/MAX7318.pdf
+- PCA6107: https://pdf1.alldatasheet.com/datasheet-pdf/view/161780/TI/PCA6107.html
+- PCA6408A: https://www.nxp.com/docs/en/data-sheet/PCA6408A.pdf
+- PCA6416A: https://www.nxp.com/docs/en/data-sheet/PCA6416A.pdf
+- PCA9505: https://www.nxp.com/docs/en/data-sheet/PCA9505_9506.pdf
+- PCA9505: https://www.nxp.com/docs/en/data-sheet/PCA9505_9506.pdf
+- PCA9534: https://www.nxp.com/docs/en/data-sheet/PCA9534.pdf
+- PCA9535: https://www.nxp.com/docs/en/data-sheet/PCA9535_PCA9535C.pdf
+- PCA9536: https://www.nxp.com/docs/en/data-sheet/PCA9536.pdf
+- PCA9537: https://www.nxp.com/docs/en/data-sheet/PCA9537.pdf
+- PCA9538: https://www.nxp.com/docs/en/data-sheet/PCA9538.pdf
+- PCA9539: https://www.nxp.com/docs/en/data-sheet/PCA9539_PCA9539R.pdf
+- PCA9554: https://www.nxp.com/docs/en/data-sheet/PCA9554_9554A.pdf
+- PCA9555: https://www.nxp.com/docs/en/data-sheet/PCA9555.pdf
+- PCA9556: https://www.nxp.com/docs/en/data-sheet/PCA9556.pdf
+- PCA9557: https://www.nxp.com/docs/en/data-sheet/PCA9557.pdf
+- PCA9574: https://www.nxp.com/docs/en/data-sheet/PCA9574.pdf
+- PCA9575: https://www.nxp.com/docs/en/data-sheet/PCA9575.pdf
+- PCA9698: https://www.nxp.com/docs/en/data-sheet/PCA9698.pdf
+- PCAL6408A: https://www.nxp.com/docs/en/data-sheet/PCAL6408A.pdf
+- PCAL6416A: https://www.nxp.com/docs/en/data-sheet/PCAL6416A.pdf
+- PCAL6524: https://www.nxp.com/docs/en/data-sheet/PCAL6524.pdf
+- PCAL6534: https://www.nxp.com/docs/en/data-sheet/PCAL6534.pdf
+- PCAL9535A: https://www.nxp.com/docs/en/data-sheet/PCAL9535A.pdf
+- PCAL9554B: https://www.nxp.com/docs/en/data-sheet/PCAL9554B_PCAL9554C.pdf
+- PCAL9555A: https://www.nxp.com/docs/en/data-sheet/PCAL9555A.pdf
+- TCA6408A: https://www.ti.com/lit/gpn/tca6408a
+- TCA6416: https://www.ti.com/lit/gpn/tca6416
+- TCA6424: https://www.ti.com/lit/gpn/tca6424
+- TCA9539: https://www.ti.com/lit/gpn/tca9539
+- TCA9554: https://www.ti.com/lit/gpn/tca9554
+- XRA1202: https://assets.maxlinear.com/web/documents/xra1202_1202p_101_042213.pdf
diff --git a/Documentation/driver-api/hsi.rst b/Documentation/driver-api/hsi.rst
index f9cec02b72a1..01b6bebfbd1a 100644
--- a/Documentation/driver-api/hsi.rst
+++ b/Documentation/driver-api/hsi.rst
@@ -4,7 +4,7 @@ High Speed Synchronous Serial Interface (HSI)
Introduction
---------------
-High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol,
+High Speed Synchronous Interface (HSI) is a full duplex, low latency protocol,
that is optimized for die-level interconnect between an Application Processor
and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
implemented by multiple vendors since then.
@@ -52,7 +52,7 @@ hsi-char Device
------------------
Each port automatically registers a generic client driver called hsi_char,
-which provides a charecter device for userspace representing the HSI port.
+which provides a character device for userspace representing the HSI port.
It can be used to communicate via HSI from userspace. Userspace may
configure the hsi_char device using the following ioctl commands:
diff --git a/Documentation/driver-api/hte/index.rst b/Documentation/driver-api/hte/index.rst
index 9f43301c05dc..29011de9a4b8 100644
--- a/Documentation/driver-api/hte/index.rst
+++ b/Documentation/driver-api/hte/index.rst
@@ -18,5 +18,5 @@ HTE Tegra Provider
.. toctree::
:maxdepth: 1
- tegra194-hte
+ tegra-hte
diff --git a/Documentation/driver-api/hte/tegra-hte.rst b/Documentation/driver-api/hte/tegra-hte.rst
new file mode 100644
index 000000000000..85e654772782
--- /dev/null
+++ b/Documentation/driver-api/hte/tegra-hte.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+HTE Kernel provider driver
+==========================
+
+Description
+-----------
+The Nvidia tegra HTE provider also known as GTE (Generic Timestamping Engine)
+driver implements two GTE instances: 1) GPIO GTE and 2) LIC
+(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the timestamp
+from the system counter TSC which has 31.25MHz clock rate, and the driver
+converts clock tick rate to nanoseconds before storing it as timestamp value.
+
+GPIO GTE
+--------
+
+This GTE instance timestamps GPIO in real time. For that to happen GPIO
+needs to be configured as input. Only the always on (AON) GPIO controller
+instance supports timestamping GPIOs in real time as it is tightly coupled with
+the GPIO GTE. To support this, GPIOLIB adds two optional APIs as mentioned
+below. The GPIO GTE code supports both kernel and userspace consumers. The
+kernel space consumers can directly talk to HTE subsystem while userspace
+consumers timestamp requests go through GPIOLIB CDEV framework to HTE
+subsystem. The hte devicetree binding described at
+``Documentation/devicetree/bindings/timestamp`` provides an example of how a
+consumer can request an GPIO line.
+
+See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
+
+For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
+specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
+returns the timestamp in nanoseconds.
+
+LIC (Legacy Interrupt Controller) IRQ GTE
+-----------------------------------------
+
+This GTE instance timestamps LIC IRQ lines in real time. The hte devicetree
+binding described at ``Documentation/devicetree/bindings/timestamp``
+provides an example of how a consumer can request an IRQ line. Since it is a
+one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ
+number that they are interested in. There is no userspace consumer support for
+this GTE instance in the HTE framework.
+
+The provider source code of both IRQ and GPIO GTE instances is located at
+``drivers/hte/hte-tegra194.c``. The test driver
+``drivers/hte/hte-tegra194-test.c`` demonstrates HTE API usage for both IRQ
+and GPIO GTE.
diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
deleted file mode 100644
index f2d617265546..000000000000
--- a/Documentation/driver-api/hte/tegra194-hte.rst
+++ /dev/null
@@ -1,48 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0+
-
-HTE Kernel provider driver
-==========================
-
-Description
------------
-The Nvidia tegra194 HTE provider driver implements two GTE
-(Generic Timestamping Engine) instances: 1) GPIO GTE and 2) LIC
-(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the
-timestamp from the system counter TSC which has 31.25MHz clock rate, and the
-driver converts clock tick rate to nanoseconds before storing it as timestamp
-value.
-
-GPIO GTE
---------
-
-This GTE instance timestamps GPIO in real time. For that to happen GPIO
-needs to be configured as input. The always on (AON) GPIO controller instance
-supports timestamping GPIOs in real time and it has 39 GPIO lines. The GPIO GTE
-and AON GPIO controller are tightly coupled as it requires very specific bits
-to be set in GPIO config register before GPIO GTE can be used, for that GPIOLIB
-adds two optional APIs as below. The GPIO GTE code supports both kernel
-and userspace consumers. The kernel space consumers can directly talk to HTE
-subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV
-framework to HTE subsystem.
-
-See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
-
-For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
-specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
-returns the timestamp in nanoseconds.
-
-LIC (Legacy Interrupt Controller) IRQ GTE
------------------------------------------
-
-This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ
-lines which this instance can add timestamps to in real time. The hte
-devicetree binding described at ``Documentation/devicetree/bindings/timestamp``
-provides an example of how a consumer can request an IRQ line. Since it is a
-one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ
-number that they are interested in. There is no userspace consumer support for
-this GTE instance in the HTE framework.
-
-The provider source code of both IRQ and GPIO GTE instances is located at
-``drivers/hte/hte-tegra194.c``. The test driver
-``drivers/hte/hte-tegra194-test.c`` demonstrates HTE API usage for both IRQ
-and GPIO GTE.
diff --git a/Documentation/driver-api/hw-recoverable-errors.rst b/Documentation/driver-api/hw-recoverable-errors.rst
new file mode 100644
index 000000000000..fc526c3454bd
--- /dev/null
+++ b/Documentation/driver-api/hw-recoverable-errors.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================================
+Recoverable Hardware Error Tracking in vmcoreinfo
+=================================================
+
+Overview
+--------
+
+This feature provides a generic infrastructure within the Linux kernel to track
+and log recoverable hardware errors. These are hardware recoverable errors
+visible that might not cause immediate panics but may influence health, mainly
+because new code path will be executed in the kernel.
+
+By recording counts and timestamps of recoverable errors into the vmcoreinfo
+crash dump notes, this infrastructure aids post-mortem crash analysis tools in
+correlating hardware events with kernel failures. This enables faster triage
+and better understanding of root causes, especially in large-scale cloud
+environments where hardware issues are common.
+
+Benefits
+--------
+
+- Facilitates correlation of hardware recoverable errors with kernel panics or
+ unusual code paths that lead to system crashes.
+- Provides operators and cloud providers quick insights, improving reliability
+ and reducing troubleshooting time.
+- Complements existing full hardware diagnostics without replacing them.
+
+Data Exposure and Consumption
+-----------------------------
+
+- The tracked error data consists of per-error-type counts and timestamps of
+ last occurrence.
+- This data is stored in the `hwerror_data` array, categorized by error source
+ types like CPU, memory, PCI, CXL, and others.
+- It is exposed via vmcoreinfo crash dump notes and can be read using tools
+ like `crash`, `drgn`, or other kernel crash analysis utilities.
+- There is no other way to read these data other than from crash dumps.
+- These errors are divided by area, which includes CPU, Memory, PCI, CXL and
+ others.
+
+Typical usage example (in drgn REPL):
+
+.. code-block:: python
+
+ >>> prog['hwerror_data']
+ (struct hwerror_info[HWERR_RECOV_MAX]){
+ {
+ .count = (int)844,
+ .timestamp = (time64_t)1752852018,
+ },
+ ...
+ }
+
+Enabling
+--------
+
+- This feature is enabled when CONFIG_VMCORE_INFO is set.
+
diff --git a/Documentation/driver-api/i3c/protocol.rst b/Documentation/driver-api/i3c/protocol.rst
index 02653defa011..fe338f8085db 100644
--- a/Documentation/driver-api/i3c/protocol.rst
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -71,8 +71,8 @@ During DAA, each I3C device reports 3 important things:
related capabilities
* DCR: Device Characteristic Register. This 8-bit register describes the
functionalities provided by the device
-* Provisional ID: A 48-bit unique identifier. On a given bus there should be no
- Provisional ID collision, otherwise the discovery mechanism may fail.
+* Provisioned ID: A 48-bit unique identifier. On a given bus there should be no
+ Provisioned ID collision, otherwise the discovery mechanism may fail.
I3C slave events
================
@@ -165,8 +165,8 @@ The first thing attached to an HDR command is the HDR mode. There are currently
for more details):
* HDR-DDR: Double Data Rate mode
-* HDR-TSP: Ternary Symbol Pure. Only usable on busses with no I2C devices
-* HDR-TSL: Ternary Symbol Legacy. Usable on busses with I2C devices
+* HDR-TSP: Ternary Symbol Pure. Only usable on buses with no I2C devices
+* HDR-TSL: Ternary Symbol Legacy. Usable on buses with I2C devices
When sending an HDR command, the whole bus has to enter HDR mode, which is done
using a broadcast CCC command.
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index e83026aebe97..63f364e862d1 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -15,8 +15,8 @@ trigger source. Multiple data channels can be read at once from
IIO buffer sysfs interface
==========================
An IIO buffer has an associated attributes directory under
-:file:`/sys/bus/iio/iio:device{X}/buffer/*`. Here are some of the existing
-attributes:
+:file:`/sys/bus/iio/devices/iio:device{X}/buffer/*`. Here are some of the
+existing attributes:
* :file:`length`, the total number of data samples (capacity) that can be
stored by the buffer.
@@ -28,8 +28,8 @@ IIO buffer setup
The meta information associated with a channel reading placed in a buffer is
called a scan element. The important bits configuring scan elements are
exposed to userspace applications via the
-:file:`/sys/bus/iio/iio:device{X}/scan_elements/` directory. This directory contains
-attributes of the following form:
+:file:`/sys/bus/iio/devices/iio:device{X}/scan_elements/` directory. This
+directory contains attributes of the following form:
* :file:`enable`, used for enabling a channel. If and only if its attribute
is non *zero*, then a triggered capture will contain data samples for this
diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst
index 715cf29482a1..42b580fb2989 100644
--- a/Documentation/driver-api/iio/core.rst
+++ b/Documentation/driver-api/iio/core.rst
@@ -24,7 +24,7 @@ then we will show how a device driver makes use of an IIO device.
There are two ways for a user space application to interact with an IIO driver.
-1. :file:`/sys/bus/iio/iio:device{X}/`, this represents a hardware sensor
+1. :file:`/sys/bus/iio/devices/iio:device{X}/`, this represents a hardware sensor
and groups together the data channels of the same chip.
2. :file:`/dev/iio:device{X}`, character device node interface used for
buffered data transfer and for events information retrieval.
@@ -51,8 +51,8 @@ IIO device sysfs interface
Attributes are sysfs files used to expose chip info and also allowing
applications to set various configuration parameters. For device with
-index X, attributes can be found under /sys/bus/iio/iio:deviceX/ directory.
-Common attributes are:
+index X, attributes can be found under /sys/bus/iio/devices/iio:deviceX/
+directory. Common attributes are:
* :file:`name`, description of the physical chip.
* :file:`dev`, shows the major:minor pair associated with
@@ -60,7 +60,7 @@ Common attributes are:
* :file:`sampling_frequency_available`, available discrete set of sampling
frequency values for device.
* Available standard attributes for IIO devices are described in the
- :file:`Documentation/ABI/testing/sysfs-bus-iio` file in the Linux kernel
+ :file:Documentation/ABI/testing/sysfs-bus-iio file in the Linux kernel
sources.
IIO device channels
@@ -140,16 +140,16 @@ Here is how we can make use of the channel's modifiers::
This channel's definition will generate two separate sysfs files for raw data
retrieval:
-* :file:`/sys/bus/iio/iio:device{X}/in_intensity_ir_raw`
-* :file:`/sys/bus/iio/iio:device{X}/in_intensity_both_raw`
+* :file:`/sys/bus/iio/devices/iio:device{X}/in_intensity_ir_raw`
+* :file:`/sys/bus/iio/devices/iio:device{X}/in_intensity_both_raw`
one file for processed data:
-* :file:`/sys/bus/iio/iio:device{X}/in_illuminance_input`
+* :file:`/sys/bus/iio/devices/iio:device{X}/in_illuminance_input`
and one shared sysfs file for sampling frequency:
-* :file:`/sys/bus/iio/iio:device{X}/sampling_frequency`.
+* :file:`/sys/bus/iio/devices/iio:device{X}/sampling_frequency`.
Here is how we can make use of the channel's indexing::
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index d3a58f77328e..1833e6a0687e 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -1,115 +1,154 @@
-========================================
-The Linux driver implementer's API guide
-========================================
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Driver implementer's API guide
+==============================
The kernel offers a wide variety of interfaces to support the development
of device drivers. This document is an only somewhat organized collection
of some of those interfaces — it will hopefully get better over time! The
available subsections can be seen below.
-.. class:: toc-title
- Table of contents
+General information for driver authors
+======================================
+
+This section contains documentation that should, at some point or other, be
+of interest to most developers working on device drivers.
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
- driver-model/index
basics
+ driver-model/index
+ device_link
infrastructure
ioctl
- early-userspace/index
pm/index
- clk
+
+Useful support libraries
+========================
+
+This section contains documentation that should, at some point or other, be
+of interest to most developers working on device drivers.
+
+.. toctree::
+ :maxdepth: 1
+
+ early-userspace/index
+ connector
device-io
+ devfreq
dma-buf
- device_link
component
- message-based
- infiniband
- aperture
- frame-buffer
- regulator
- reset
- iio/index
- input
- usb/index
- firewire
- pci/index
+ io-mapping
+ io_ordering
+ uio-howto
+ vfio-mediated-device
+ vfio
+ vfio-pci-device-specific-driver-acceptance
+
+Bus-level documentation
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
+ auxiliary_bus
cxl/index
- spi
- i2c
- ipmb
- ipmi
+ eisa
+ firewire
i3c/index
- interconnect
- devfreq
- hsi
- edac
- scsi
- libata
- target
- mailbox
- mtdnand
- miscellaneous
- mei/index
- mtd/index
- mmc/index
- nvdimm/index
- w1
+ isa
+ men-chameleon-bus
+ pci/index
rapidio/index
- s390-drivers
+ slimbus
+ usb/index
+ virtio/index
vme
+ w1
+ xillybus
+
+
+Subsystem-specific APIs
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
80211/index
- uio-howto
+ acpi/index
+ backlight/lp855x-driver.rst
+ clk
+ coco/index
+ console
+ crypto/index
+ dmaengine/index
+ dpll
+ edac
+ extcon
firmware/index
- pin-control
+ fpga/index
+ frame-buffer
+ aperture
+ generic-counter
+ generic_pt
gpio/index
+ hsi
+ hte/index
+ hw-recoverable-errors
+ i2c
+ iio/index
+ infiniband
+ input
+ interconnect
+ ipmb
+ ipmi
+ libata
+ mailbox
md/index
media/index
+ mei/index
+ memory-devices/index
+ message-based
misc_devices
+ miscellaneous
+ mmc/index
+ mtd/index
+ mtdnand
nfc/index
- dmaengine/index
- slimbus
- soundwire/index
- thermal/index
- fpga/index
- acpi/index
- auxiliary_bus
- backlight/lp855x-driver.rst
- connector
- console
- dcdbas
- eisa
- isa
- isapnp
- io-mapping
- io_ordering
- generic-counter
- memory-devices/index
- men-chameleon-bus
ntb
+ nvdimm/index
nvmem
parport-lowlevel
+ phy/index
+ pin-control
+ pldmfw/index
pps
ptp
- phy/index
pwm
- pldmfw/index
+ pwrseq
+ regulator
+ reset
rfkill
+ s390-drivers
+ scsi
serial/index
sm501
+ soundwire/index
+ spi
surface_aggregator/index
switchtec
sync_file
+ target
+ tee
+ thermal/index
tty/index
- vfio-mediated-device
- vfio
- vfio-pci-device-specific-driver-acceptance
+ wbrf
+ wmi
xilinx/index
- xillybus
zorro
- hte/index
.. only:: subproject and html
diff --git a/Documentation/driver-api/infiniband.rst b/Documentation/driver-api/infiniband.rst
index 30e142ccbee9..10d8be9e74fe 100644
--- a/Documentation/driver-api/infiniband.rst
+++ b/Documentation/driver-api/infiniband.rst
@@ -77,14 +77,14 @@ iSCSI Extensions for RDMA (iSER)
:internal:
.. kernel-doc:: drivers/infiniband/ulp/iser/iscsi_iser.c
- :functions: iscsi_iser_pdu_alloc iser_initialize_task_headers \
- iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit \
- iscsi_iser_cleanup_task iscsi_iser_check_protection \
- iscsi_iser_conn_create iscsi_iser_conn_bind \
- iscsi_iser_conn_start iscsi_iser_conn_stop \
- iscsi_iser_session_destroy iscsi_iser_session_create \
- iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll \
- iscsi_iser_ep_disconnect
+ :functions: iscsi_iser_pdu_alloc iser_initialize_task_headers
+ iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit
+ iscsi_iser_cleanup_task iscsi_iser_check_protection
+ iscsi_iser_conn_create iscsi_iser_conn_bind
+ iscsi_iser_conn_start iscsi_iser_conn_stop
+ iscsi_iser_session_destroy iscsi_iser_session_create
+ iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll
+ iscsi_iser_ep_disconnect
.. kernel-doc:: drivers/infiniband/ulp/iser/iser_initiator.c
:internal:
diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst
index 683bd460e222..35e36fee4238 100644
--- a/Documentation/driver-api/infrastructure.rst
+++ b/Documentation/driver-api/infrastructure.rst
@@ -8,12 +8,24 @@ The Basic Device Driver-Model Structures
:internal:
:no-identifiers: device_link_state
+.. kernel-doc:: include/linux/device/bus.h
+ :identifiers: bus_type bus_notifier_event
+
+.. kernel-doc:: include/linux/device/class.h
+ :identifiers: class
+
+.. kernel-doc:: include/linux/device/driver.h
+ :identifiers: probe_type device_driver
+
Device Drivers Base
-------------------
.. kernel-doc:: drivers/base/init.c
:internal:
+.. kernel-doc:: include/linux/device/driver.h
+ :no-identifiers: probe_type device_driver
+
.. kernel-doc:: drivers/base/driver.c
:export:
@@ -23,9 +35,18 @@ Device Drivers Base
.. kernel-doc:: drivers/base/syscore.c
:export:
+.. kernel-doc:: include/linux/device/class.h
+ :no-identifiers: class
+
.. kernel-doc:: drivers/base/class.c
:export:
+.. kernel-doc:: include/linux/device/faux.h
+ :internal:
+
+.. kernel-doc:: drivers/base/faux.c
+ :export:
+
.. kernel-doc:: drivers/base/node.c
:internal:
@@ -41,6 +62,9 @@ Device Drivers Base
.. kernel-doc:: drivers/base/platform.c
:export:
+.. kernel-doc:: include/linux/device/bus.h
+ :no-identifiers: bus_type bus_notifier_event
+
.. kernel-doc:: drivers/base/bus.c
:export:
diff --git a/Documentation/driver-api/input.rst b/Documentation/driver-api/input.rst
index 4bbb26ae2a89..bd7a3578ade7 100644
--- a/Documentation/driver-api/input.rst
+++ b/Documentation/driver-api/input.rst
@@ -40,3 +40,10 @@ Sparse keymap support
.. kernel-doc:: drivers/input/sparse-keymap.c
:export:
+PS/2 protocol support
+---------------------
+.. kernel-doc:: include/linux/libps2.h
+ :internal:
+
+.. kernel-doc:: drivers/input/serio/libps2.c
+ :export:
diff --git a/Documentation/driver-api/interconnect.rst b/Documentation/driver-api/interconnect.rst
index 5ed4f57a6bac..a92d0f277a1f 100644
--- a/Documentation/driver-api/interconnect.rst
+++ b/Documentation/driver-api/interconnect.rst
@@ -113,3 +113,28 @@ through dot to generate diagrams in many graphical formats::
$ cat /sys/kernel/debug/interconnect/interconnect_graph | \
dot -Tsvg > interconnect_graph.svg
+
+The ``test-client`` directory provides interfaces for issuing BW requests to
+any arbitrary path. Note that for safety reasons, this feature is disabled by
+default without a Kconfig to enable it. Enabling it requires code changes to
+``#define INTERCONNECT_ALLOW_WRITE_DEBUGFS``. Example usage::
+
+ cd /sys/kernel/debug/interconnect/test-client/
+
+ # Configure node endpoints for the path from CPU to DDR on
+ # qcom/sm8550.
+ echo chm_apps > src_node
+ echo ebi > dst_node
+
+ # Get path between src_node and dst_node. This is only
+ # necessary after updating the node endpoints.
+ echo 1 > get
+
+ # Set desired BW to 1GBps avg and 2GBps peak.
+ echo 1000000 > avg_bw
+ echo 2000000 > peak_bw
+
+ # Vote for avg_bw and peak_bw on the latest path from "get".
+ # Voting for multiple paths is possible by repeating this
+ # process for different nodes endpoints.
+ echo 1 > commit
diff --git a/Documentation/driver-api/io-mapping.rst b/Documentation/driver-api/io-mapping.rst
index a0cfb15988df..7274204b0435 100644
--- a/Documentation/driver-api/io-mapping.rst
+++ b/Documentation/driver-api/io-mapping.rst
@@ -44,7 +44,7 @@ This _wc variant returns a write-combining map to the page and may only be
used with mappings created by io_mapping_create_wc()
Temporary mappings are only valid in the context of the caller. The mapping
-is not guaranteed to be globaly visible.
+is not guaranteed to be globally visible.
io_mapping_map_local_wc() has a side effect on X86 32bit as it disables
migration to make the mapping code work. No caller can rely on this side
@@ -78,7 +78,7 @@ variant, although this may be significantly slower::
unsigned long offset)
This works like io_mapping_map_atomic/local_wc() except it has no side
-effects and the pointer is globaly visible.
+effects and the pointer is globally visible.
The mappings are released with::
diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst
index e224e47b6b09..f52ab2df2569 100644
--- a/Documentation/driver-api/ipmi.rst
+++ b/Documentation/driver-api/ipmi.rst
@@ -45,7 +45,7 @@ manual), choose the 'IPMI SI handler' option. A driver also exists
for direct I2C access to the IPMI management controller. Some boards
support this, but it is unknown if it will work on every board. For
this, choose 'IPMI SMBus handler', but be ready to try to do some
-figuring to see if it will work on your system if the SMBIOS/APCI
+figuring to see if it will work on your system if the SMBIOS/ACPI
information is wrong or not present. It is fairly safe to have both
these enabled and let the drivers auto-detect what is present.
@@ -63,7 +63,7 @@ situation, you need to read the section below named 'The SI Driver' or
IPMI defines a standard watchdog timer. You can enable this with the
'IPMI Watchdog Timer' config option. If you compile the driver into
the kernel, then via a kernel command-line option you can have the
-watchdog timer start as soon as it initializes. It also have a lot
+watchdog timer start as soon as it initializes. It also has a lot
of other options, see the 'Watchdog' section below for more details.
Note that you can also have the watchdog continue to run if it is
closed (by default it is disabled on close). Go into the 'Watchdog
@@ -280,10 +280,8 @@ Creating the User
To use the message handler, you must first create a user using
ipmi_create_user. The interface number specifies which SMI you want
to connect to, and you must supply callback functions to be called
-when data comes in. The callback function can run at interrupt level,
-so be careful using the callbacks. This also allows to you pass in a
-piece of data, the handler_data, that will be passed back to you on
-all calls.
+when data comes in. This also allows to you pass in a piece of data,
+the handler_data, that will be passed back to you on all calls.
Once you are done, call ipmi_destroy_user() to get rid of the user.
@@ -303,8 +301,7 @@ use it for anything you like.
Responses come back in the function pointed to by the ipmi_recv_hndl
field of the "handler" that you passed in to ipmi_create_user().
-Remember again, these may be running at interrupt level. Remember to
-look at the receive type, too.
+Remember to look at the receive type, too.
From userland, you fill out an ipmi_req_t structure and use the
IPMICTL_SEND_COMMAND ioctl. For incoming stuff, you can use select()
@@ -317,13 +314,13 @@ This gives the receiver a place to actually put the message.
If the message cannot fit into the data you provide, you will get an
EMSGSIZE error and the driver will leave the data in the receive
-queue. If you want to get it and have it truncate the message, us
+queue. If you want to get it and have it truncate the message, use
the IPMICTL_RECEIVE_MSG_TRUNC ioctl.
When you send a command (which is defined by the lowest-order bit of
the netfn per the IPMI spec) on the IPMB bus, the driver will
automatically assign the sequence number to the command and save the
-command. If the response is not receive in the IPMI-specified 5
+command. If the response is not received in the IPMI-specified 5
seconds, it will generate a response automatically saying the command
timed out. If an unsolicited response comes in (if it was after 5
seconds, for instance), that response will be ignored.
@@ -367,7 +364,7 @@ channel bitmasks do not overlap.
To respond to a received command, set the response bit in the returned
netfn, use the address from the received message, and use the same
-msgid that you got in the receive message.
+msgid that you got in the received message.
From userland, equivalent IOCTLs are provided to do these functions.
@@ -440,7 +437,7 @@ register would be 0xca6. This defaults to 1.
The regsizes parameter gives the size of a register, in bytes. The
data used by IPMI is 8-bits wide, but it may be inside a larger
-register. This parameter allows the read and write type to specified.
+register. This parameter allows the read and write type to be specified.
It may be 1, 2, 4, or 8. The default is 1.
Since the register size may be larger than 32 bits, the IPMI data may not
@@ -481,8 +478,8 @@ If your IPMI interface does not support interrupts and is a KCS or
SMIC interface, the IPMI driver will start a kernel thread for the
interface to help speed things up. This is a low-priority kernel
thread that constantly polls the IPMI driver while an IPMI operation
-is in progress. The force_kipmid module parameter will all the user to
-force this thread on or off. If you force it off and don't have
+is in progress. The force_kipmid module parameter will allow the user
+to force this thread on or off. If you force it off and don't have
interrupts, the driver will run VERY slowly. Don't blame me,
these interfaces suck.
@@ -540,7 +537,7 @@ at module load time (for a module) with::
alerts_broken
The addresses are normal I2C addresses. The adapter is the string
-name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name.
+name of the adapter, as shown in /sys/bus/i2c/devices/i2c-<n>/name.
It is *NOT* i2c-<n> itself. Also, the comparison is done ignoring
spaces, so if the name is "This is an I2C chip" you can say
adapter_name=ThisisanI2cchip. This is because it's hard to pass in
@@ -583,7 +580,7 @@ kernel command line as::
These are the same options as on the module command line.
The I2C driver does not support non-blocking access or polling, so
-this driver cannod to IPMI panic events, extend the watchdog at panic
+this driver cannot do IPMI panic events, extend the watchdog at panic
time, or other panic-related IPMI functions without special kernel
patches and driver modifications. You can get those at the openipmi
web page.
@@ -610,7 +607,7 @@ Parameters are::
ipmi_ipmb.retry_time_ms=<Time between retries on IPMB>
ipmi_ipmb.max_retries=<Number of times to retry a message>
-Loading the module will not result in the driver automatcially
+Loading the module will not result in the driver automatically
starting unless there is device tree information setting it up. If
you want to instantiate one of these by hand, do::
@@ -620,12 +617,12 @@ Note that the address you give here is the I2C address, not the IPMI
address. So if you want your MC address to be 0x60, you put 0x30
here. See the I2C driver info for more details.
-Command bridging to other IPMB busses through this interface does not
+Command bridging to other IPMB buses through this interface does not
work. The receive message queue is not implemented, by design. There
is only one receive message queue on a BMC, and that is meant for the
host drivers, not something on the IPMB bus.
-A BMC may have multiple IPMB busses, which bus your device sits on
+A BMC may have multiple IPMB buses, which bus your device sits on
depends on how the system is wired. You can fetch the channels with
"ipmitool channel info <n>" where <n> is the channel, with the
channels being 0-7 and try the IPMB channels.
diff --git a/Documentation/driver-api/isapnp.rst b/Documentation/driver-api/isapnp.rst
deleted file mode 100644
index 8d0840ac847b..000000000000
--- a/Documentation/driver-api/isapnp.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-==========================================================
-ISA Plug & Play support by Jaroslav Kysela <perex@suse.cz>
-==========================================================
-
-Interface /proc/isapnp
-======================
-
-The interface has been removed. See pnp.txt for more details.
-
-Interface /proc/bus/isapnp
-==========================
-
-This directory allows access to ISA PnP cards and logical devices.
-The regular files contain the contents of ISA PnP registers for
-a logical device.
diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst
index 311af516a3fd..93d97fe78e3f 100644
--- a/Documentation/driver-api/libata.rst
+++ b/Documentation/driver-api/libata.rst
@@ -32,22 +32,6 @@ register blocks.
:c:type:`struct ata_port_operations <ata_port_operations>`
----------------------------------------------------------
-Disable ATA port
-~~~~~~~~~~~~~~~~
-
-::
-
- void (*port_disable) (struct ata_port *);
-
-
-Called from :c:func:`ata_bus_probe` error path, as well as when unregistering
-from the SCSI module (rmmod, hot unplug). This function should do
-whatever needs to be done to take the port out of use. In most cases,
-:c:func:`ata_port_disable` can be used as this hook.
-
-Called from :c:func:`ata_bus_probe` on a failed probe. Called from
-:c:func:`ata_scsi_release`.
-
Post-IDENTIFY device configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -274,14 +258,6 @@ Exception and probe handling (EH)
::
- void (*eng_timeout) (struct ata_port *ap);
- void (*phy_reset) (struct ata_port *ap);
-
-
-Deprecated. Use ``->error_handler()`` instead.
-
-::
-
void (*freeze) (struct ata_port *ap);
void (*thaw) (struct ata_port *ap);
@@ -307,18 +283,25 @@ interrupts, start DMA engine, etc.
``->error_handler()`` is a driver's hook into probe, hotplug, and recovery
and other exceptional conditions. The primary responsibility of an
-implementation is to call :c:func:`ata_do_eh` or :c:func:`ata_bmdma_drive_eh`
-with a set of EH hooks as arguments:
+implementation is to call :c:func:`ata_std_error_handler`.
+
+:c:func:`ata_std_error_handler` will perform a standard error handling sequence
+to resurect failed devices, detach lost devices and add new devices (if any).
+This function will call the various reset operations for a port, as needed.
+These operations are as follows.
-'prereset' hook (may be NULL) is called during an EH reset, before any
-other actions are taken.
+* The 'prereset' operation (which may be NULL) is called during an EH reset,
+ before any other action is taken.
-'postreset' hook (may be NULL) is called after the EH reset is
-performed. Based on existing conditions, severity of the problem, and
-hardware capabilities,
+* The 'postreset' hook (which may be NULL) is called after the EH reset is
+ performed. Based on existing conditions, severity of the problem, and hardware
+ capabilities,
-Either 'softreset' (may be NULL) or 'hardreset' (may be NULL) will be
-called to perform the low-level EH reset.
+* Either the 'softreset' operation or the 'hardreset' operation will be called
+ to perform the low-level EH reset. If both operations are defined,
+ 'hardreset' is preferred and used. If both are not defined, no low-level reset
+ is performed and EH assumes that an ATA class device is connected through the
+ link.
::
@@ -364,8 +347,7 @@ SATA phy read/write
u32 val);
-Read and write standard SATA phy registers. Currently only used if
-``->phy_reset`` hook called the :c:func:`sata_phy_reset` helper function.
+Read and write standard SATA phy registers.
sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE.
Init and shutdown
@@ -536,13 +518,12 @@ to return without deallocating the qc. This leads us to
:c:func:`ata_scsi_error` is the current ``transportt->eh_strategy_handler()``
for libata. As discussed above, this will be entered in two cases -
-timeout and ATAPI error completion. This function calls low level libata
-driver's :c:func:`eng_timeout` callback, the standard callback for which is
-:c:func:`ata_eng_timeout`. It checks if a qc is active and calls
-:c:func:`ata_qc_timeout` on the qc if so. Actual error handling occurs in
-:c:func:`ata_qc_timeout`.
+timeout and ATAPI error completion. This function will check if a qc is active
+and has not failed yet. Such a qc will be marked with AC_ERR_TIMEOUT such that
+EH will know to handle it later. Then it calls low level libata driver's
+:c:func:`error_handler` callback.
-If EH is invoked for timeout, :c:func:`ata_qc_timeout` stops BMDMA and
+When the :c:func:`error_handler` callback is invoked it stops BMDMA and
completes the qc. Note that as we're currently in EH, we cannot call
scsi_done. As described in SCSI EH doc, a recovered scmd should be
either retried with :c:func:`scsi_queue_insert` or finished with
diff --git a/Documentation/driver-api/md/md-cluster.rst b/Documentation/driver-api/md/md-cluster.rst
index 96eb52cec7eb..e93f35e0e157 100644
--- a/Documentation/driver-api/md/md-cluster.rst
+++ b/Documentation/driver-api/md/md-cluster.rst
@@ -65,7 +65,7 @@ There are three groups of locks for managing the device:
2.3 new-device management
-------------------------
- A single lock: "no-new-dev" is used to co-ordinate the addition of
+ A single lock: "no-new-dev" is used to coordinate the addition of
new devices - this must be synchronized across the array.
Normally all nodes hold a concurrent-read lock on this device.
diff --git a/Documentation/driver-api/md/raid5-cache.rst b/Documentation/driver-api/md/raid5-cache.rst
index d7a15f44a7c3..5f947cbc2e78 100644
--- a/Documentation/driver-api/md/raid5-cache.rst
+++ b/Documentation/driver-api/md/raid5-cache.rst
@@ -81,7 +81,7 @@ The write-through and write-back cache use the same disk format. The cache disk
is organized as a simple write log. The log consists of 'meta data' and 'data'
pairs. The meta data describes the data. It also includes checksum and sequence
ID for recovery identification. Data can be IO data and parity data. Data is
-checksumed too. The checksum is stored in the meta data ahead of the data. The
+checksummed too. The checksum is stored in the meta data ahead of the data. The
checksum is an optimization because MD can write meta and data freely without
worry about the order. MD superblock has a field pointed to the valid meta data
of log head.
diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst
index c7d4891bd24e..94bd1dae82d5 100644
--- a/Documentation/driver-api/media/camera-sensor.rst
+++ b/Documentation/driver-api/media/camera-sensor.rst
@@ -1,10 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
+.. _media_writing_camera_sensor_drivers:
+
Writing camera sensor drivers
=============================
-CSI-2 and parallel (BT.601 and BT.656) busses
----------------------------------------------
+This document covers the in-kernel APIs only. For the best practices on
+userspace API implementation in camera sensor drivers, please see
+:ref:`media_using_camera_sensor_drivers`.
+
+CSI-2, parallel and BT.656 buses
+--------------------------------
Please see :ref:`transmitter-receiver`.
@@ -13,7 +19,7 @@ Handling clocks
Camera sensors have an internal clock tree including a PLL and a number of
divisors. The clock tree is generally configured by the driver based on a few
-input parameters that are specific to the hardware:: the external clock frequency
+input parameters that are specific to the hardware: the external clock frequency
and the link frequency. The two parameters generally are obtained from system
firmware. **No other frequencies should be used in any circumstances.**
@@ -23,119 +29,81 @@ used in the system. Using another frequency may cause harmful effects
elsewhere. Therefore only the pre-determined frequencies are configurable by the
user.
+The external clock frequency shall be retrieved by obtaining the external clock
+using the ``devm_v4l2_sensor_clk_get()`` helper function, and then getting its
+frequency with ``clk_get_rate()``. Usage of the helper function guarantees
+correct behaviour regardless of whether the sensor is integrated in a DT-based
+or ACPI-based system.
+
ACPI
~~~~
-Read the ``clock-frequency`` _DSD property to denote the frequency. The driver
-can rely on this frequency being used.
+ACPI-based systems typically don't register the sensor external clock with the
+kernel, but specify the external clock frequency in the ``clock-frequency``
+_DSD property. The ``devm_v4l2_sensor_clk_get()`` helper creates and returns a
+fixed clock set at that rate.
Devicetree
~~~~~~~~~~
-The currently preferred way to achieve this is using ``assigned-clocks``,
-``assigned-clock-parents`` and ``assigned-clock-rates`` properties. See
-``Documentation/devicetree/bindings/clock/clock-bindings.txt`` for more
-information. The driver then gets the frequency using ``clk_get_rate()``.
+Devicetree-based systems declare the sensor external clock in the device tree
+and reference it from the sensor node. The preferred way to select the external
+clock frequency is to use the ``assigned-clocks``, ``assigned-clock-parents``
+and ``assigned-clock-rates`` properties in the sensor node to set the clock
+rate. See the `clock device tree bindings
+<https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml>`_
+for more information. The ``devm_v4l2_sensor_clk_get()`` helper retrieves and
+returns that clock.
This approach has the drawback that there's no guarantee that the frequency
hasn't been modified directly or indirectly by another driver, or supported by
the board's clock tree to begin with. Changes to the Common Clock Framework API
are required to ensure reliability.
-Frame size
-----------
-
-There are two distinct ways to configure the frame size produced by camera
-sensors.
-
-Freely configurable camera sensor drivers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Freely configurable camera sensor drivers expose the device's internal
-processing pipeline as one or more sub-devices with different cropping and
-scaling configurations. The output size of the device is the result of a series
-of cropping and scaling operations from the device's pixel array's size.
-
-An example of such a driver is the CCS driver (see ``drivers/media/i2c/ccs``).
-
-Register list based drivers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Register list based drivers generally, instead of able to configure the device
-they control based on user requests, are limited to a number of preset
-configurations that combine a number of different parameters that on hardware
-level are independent. How a driver picks such configuration is based on the
-format set on a source pad at the end of the device's internal pipeline.
-
-Most sensor drivers are implemented this way, see e.g.
-``drivers/media/i2c/imx319.c`` for an example.
-
-Frame interval configuration
-----------------------------
-
-There are two different methods for obtaining possibilities for different frame
-intervals as well as configuring the frame interval. Which one to implement
-depends on the type of the device.
-
-Raw camera sensors
-~~~~~~~~~~~~~~~~~~
-
-Instead of a high level parameter such as frame interval, the frame interval is
-a result of the configuration of a number of camera sensor implementation
-specific parameters. Luckily, these parameters tend to be the same for more or
-less all modern raw camera sensors.
-
-The frame interval is calculated using the following equation::
-
- frame interval = (analogue crop width + horizontal blanking) *
- (analogue crop height + vertical blanking) / pixel rate
-
-The formula is bus independent and is applicable for raw timing parameters on
-large variety of devices beyond camera sensors. Devices that have no analogue
-crop, use the full source image size, i.e. pixel array size.
-
-Horizontal and vertical blanking are specified by ``V4L2_CID_HBLANK`` and
-``V4L2_CID_VBLANK``, respectively. The unit of the ``V4L2_CID_HBLANK`` control
-is pixels and the unit of the ``V4L2_CID_VBLANK`` is lines. The pixel rate in
-the sensor's **pixel array** is specified by ``V4L2_CID_PIXEL_RATE`` in the same
-sub-device. The unit of that control is pixels per second.
-
-Register list based drivers need to implement read-only sub-device nodes for the
-purpose. Devices that are not register list based need these to configure the
-device's internal processing pipeline.
-
-The first entity in the linear pipeline is the pixel array. The pixel array may
-be followed by other entities that are there to allow configuring binning,
-skipping, scaling or digital crop :ref:`v4l2-subdev-selections`.
-
-USB cameras etc. devices
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-USB video class hardware, as well as many cameras offering a similar higher
-level interface natively, generally use the concept of frame interval (or frame
-rate) on device level in firmware or hardware. This means lower level controls
-implemented by raw cameras may not be used on uAPI (or even kAPI) to control the
-frame interval on these devices.
-
Power management
----------------
-Always use runtime PM to manage the power states of your device. Camera sensor
-drivers are in no way special in this respect: they are responsible for
-controlling the power state of the device they otherwise control as well. In
-general, the device must be powered on at least when its registers are being
-accessed and when it is streaming.
-
-Existing camera sensor drivers may rely on the old
-struct v4l2_subdev_core_ops->s_power() callback for bridge or ISP drivers to
-manage their power state. This is however **deprecated**. If you feel you need
-to begin calling an s_power from an ISP or a bridge driver, instead please add
-runtime PM support to the sensor driver you are using. Likewise, new drivers
-should not use s_power.
-
-Please see examples in e.g. ``drivers/media/i2c/ov8856.c`` and
-``drivers/media/i2c/ccs/ccs-core.c``. The two drivers work in both ACPI
-and DT based systems.
+Camera sensors are used in conjunction with other devices to form a camera
+pipeline. They must obey the rules listed herein to ensure coherent power
+management over the pipeline.
+
+Camera sensor drivers are responsible for controlling the power state of the
+device they otherwise control as well. They shall use runtime PM to manage
+power states. Runtime PM shall be enabled at probe time and disabled at remove
+time. Drivers should enable runtime PM autosuspend. Also see
+:ref:`async sub-device registration <media-registering-async-subdevs>`.
+
+The runtime PM handlers shall handle clocks, regulators, GPIOs, and other
+system resources required to power the sensor up and down. For drivers that
+don't use any of those resources (such as drivers that support ACPI systems
+only), the runtime PM handlers may be left unimplemented.
+
+In general, the device shall be powered on at least when its registers are
+being accessed and when it is streaming. Drivers should use
+``pm_runtime_resume_and_get()`` when starting streaming and
+``pm_runtime_put()`` or ``pm_runtime_put_autosuspend()`` when stopping
+streaming. They may power the device up at probe time (for example to read
+identification registers), but should not keep it powered unconditionally after
+probe.
+
+At system suspend time, the whole camera pipeline must stop streaming, and
+restart when the system is resumed. This requires coordination between the
+camera sensor and the rest of the camera pipeline. Bridge drivers are
+responsible for this coordination, and instruct camera sensors to stop and
+restart streaming by calling the appropriate subdev operations
+(``.enable_streams()`` or ``.disable_streams()``). Camera sensor drivers shall
+therefore **not** keep track of the streaming state to stop streaming in the PM
+suspend handler and restart it in the resume handler. Drivers should in general
+not implement the system PM handlers.
+
+Camera sensor drivers shall **not** implement the subdev ``.s_power()``
+operation, as it is deprecated. While this operation is implemented in some
+existing drivers as they predate the deprecation, new drivers shall use runtime
+PM instead. If you feel you need to begin calling ``.s_power()`` from an ISP or
+a bridge driver, instead add runtime PM support to the sensor driver you are
+using and drop its ``.s_power()`` handler.
+
+Please also see :ref:`examples <media-camera-sensor-examples>`.
Control framework
~~~~~~~~~~~~~~~~~
@@ -151,3 +119,40 @@ used to obtain device's power state after the power state transition:
The function returns a non-zero value if it succeeded getting the power count or
runtime PM was disabled, in either of which cases the driver may proceed to
access the device.
+
+Rotation, orientation and flipping
+----------------------------------
+
+Use ``v4l2_fwnode_device_parse()`` to obtain rotation and orientation
+information from system firmware and ``v4l2_ctrl_new_fwnode_properties()`` to
+register the appropriate controls.
+
+.. _media-camera-sensor-examples:
+
+Example drivers
+---------------
+
+Features implemented by sensor drivers vary, and depending on the set of
+supported features and other qualities, particular sensor drivers better serve
+the purpose of an example. The following drivers are known to be good examples:
+
+.. flat-table:: Example sensor drivers
+ :header-rows: 0
+ :widths: 1 1 1 2
+
+ * - Driver name
+ - File(s)
+ - Driver type
+ - Example topic
+ * - CCS
+ - ``drivers/media/i2c/ccs/``
+ - Freely configurable
+ - Power management (ACPI and DT), UAPI
+ * - imx219
+ - ``drivers/media/i2c/imx219.c``
+ - Register list based
+ - Power management (DT), UAPI, mode selection
+ * - imx319
+ - ``drivers/media/i2c/imx319.c``
+ - Register list based
+ - Power management (ACPI and DT)
diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst
index ae0d20798edc..f1ffdec388f3 100644
--- a/Documentation/driver-api/media/cec-core.rst
+++ b/Documentation/driver-api/media/cec-core.rst
@@ -109,9 +109,11 @@ your driver:
int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
int (*adap_monitor_pin_enable)(struct cec_adapter *adap, bool enable);
int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
- void (*adap_configured)(struct cec_adapter *adap, bool configured);
+ void (*adap_unconfigured)(struct cec_adapter *adap);
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
u32 signal_free_time, struct cec_msg *msg);
+ void (*adap_nb_transmit_canceled)(struct cec_adapter *adap,
+ const struct cec_msg *msg);
void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
void (*adap_free)(struct cec_adapter *adap);
@@ -122,8 +124,8 @@ your driver:
...
};
-The seven low-level ops deal with various aspects of controlling the CEC adapter
-hardware:
+These low-level ops deal with various aspects of controlling the CEC adapter
+hardware. They are all called with the mutex adap->lock held.
To enable/disable the hardware::
@@ -179,14 +181,12 @@ can receive directed messages to that address.
Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID.
-Called when the adapter is fully configured or unconfigured::
+Called when the adapter is unconfigured::
- void (*adap_configured)(struct cec_adapter *adap, bool configured);
+ void (*adap_unconfigured)(struct cec_adapter *adap);
-If configured == true, then the adapter is fully configured, i.e. all logical
-addresses have been successfully claimed. If configured == false, then the
-adapter is unconfigured. If the driver has to take specific actions after
-(un)configuration, then that can be done through this optional callback.
+The adapter is unconfigured. If the driver has to take specific actions after
+unconfiguration, then that can be done through this optional callback.
To transmit a new message::
@@ -207,6 +207,19 @@ The CEC_FREE_TIME_TO_USEC macro can be used to convert signal_free_time to
microseconds (one data bit period is 2.4 ms).
+To pass on the result of a canceled non-blocking transmit::
+
+ void (*adap_nb_transmit_canceled)(struct cec_adapter *adap,
+ const struct cec_msg *msg);
+
+This optional callback can be used to obtain the result of a canceled
+non-blocking transmit with sequence number msg->sequence. This is
+called if the transmit was aborted, the transmit timed out (i.e. the
+hardware never signaled that the transmit finished), or the transmit
+was successful, but the wait for the expected reply was either aborted
+or it timed out.
+
+
To log the current CEC hardware status::
void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
@@ -372,7 +385,8 @@ Implementing the High-Level CEC Adapter
---------------------------------------
The low-level operations drive the hardware, the high-level operations are
-CEC protocol driven. The following high-level callbacks are available:
+CEC protocol driven. The high-level callbacks are called without the adap->lock
+mutex being held. The following high-level callbacks are available:
.. code-block:: none
@@ -384,9 +398,19 @@ CEC protocol driven. The following high-level callbacks are available:
...
/* High-level CEC message callback */
+ void (*configured)(struct cec_adapter *adap);
int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
};
+Called when the adapter is configured::
+
+ void (*configured)(struct cec_adapter *adap);
+
+The adapter is fully configured, i.e. all logical addresses have been
+successfully claimed. If the driver has to take specific actions after
+configuration, then that can be done through this optional callback.
+
+
The received() callback allows the driver to optionally handle a newly
received CEC message::
diff --git a/Documentation/driver-api/media/drivers/ccs/ccs.rst b/Documentation/driver-api/media/drivers/ccs/ccs.rst
index b461c8aa2a16..5d4451339b7f 100644
--- a/Documentation/driver-api/media/drivers/ccs/ccs.rst
+++ b/Documentation/driver-api/media/drivers/ccs/ccs.rst
@@ -2,59 +2,46 @@
.. include:: <isonum.txt>
+.. _media-ccs-driver:
+
MIPI CCS camera sensor driver
=============================
The MIPI CCS camera sensor driver is a generic driver for `MIPI CCS
<https://www.mipi.org/specifications/camera-command-set>`_ compliant
-camera sensors. It exposes three sub-devices representing the pixel array,
-the binner and the scaler.
-
-As the capabilities of individual devices vary, the driver exposes
-interfaces based on the capabilities that exist in hardware.
-
-Pixel Array sub-device
-----------------------
-
-The pixel array sub-device represents the camera sensor's pixel matrix, as well
-as analogue crop functionality present in many compliant devices. The analogue
-crop is configured using the ``V4L2_SEL_TGT_CROP`` on the source pad (0) of the
-entity. The size of the pixel matrix can be obtained by getting the
-``V4L2_SEL_TGT_NATIVE_SIZE`` target.
-
-Binner
-------
-
-The binner sub-device represents the binning functionality on the sensor. For
-that purpose, selection target ``V4L2_SEL_TGT_COMPOSE`` is supported on the
-sink pad (0).
-
-Additionally, if a device has no scaler or digital crop functionality, the
-source pad (1) expses another digital crop selection rectangle that can only
-crop at the end of the lines and frames.
-
-Scaler
-------
-
-The scaler sub-device represents the digital crop and scaling functionality of
-the sensor. The V4L2 selection target ``V4L2_SEL_TGT_CROP`` is used to
-configure the digital crop on the sink pad (0) when digital crop is supported.
-Scaling is configured using selection target ``V4L2_SEL_TGT_COMPOSE`` on the
-sink pad (0) as well.
-
-Additionally, if the scaler sub-device exists, its source pad (1) exposes
-another digital crop selection rectangle that can only crop at the end of the
-lines and frames.
-
-Digital and analogue crop
--------------------------
-
-Digital crop functionality is referred to as cropping that effectively works by
-dropping some data on the floor. Analogue crop, on the other hand, means that
-the cropped information is never retrieved. In case of camera sensors, the
-analogue data is never read from the pixel matrix that are outside the
-configured selection rectangle that designates crop. The difference has an
-effect in device timing and likely also in power consumption.
+camera sensors.
+
+Also see :ref:`the CCS driver UAPI documentation <media-ccs-uapi>`.
+
+CCS static data
+---------------
+
+The MIPI CCS driver supports CCS static data for all compliant devices,
+including not just those compliant with CCS 1.1 but also CCS 1.0 and SMIA(++).
+For CCS the file names are formed as
+
+ ccs/ccs-sensor-vvvv-mmmm-rrrr.fw (sensor) and
+ ccs/ccs-module-vvvv-mmmm-rrrr.fw (module).
+
+For SMIA++ compliant devices the corresponding file names are
+
+ ccs/smiapp-sensor-vv-mmmm-rr.fw (sensor) and
+ ccs/smiapp-module-vv-mmmm-rrrr.fw (module).
+
+For SMIA (non-++) compliant devices the static data file name is
+
+ ccs/smia-sensor-vv-mmmm-rr.fw (sensor).
+
+vvvv or vv denotes MIPI and SMIA manufacturer IDs respectively, mmmm model ID
+and rrrr or rr revision number.
+
+CCS tools
+~~~~~~~~~
+
+`CCS tools <https://github.com/MIPI-Alliance/ccs-tools/>`_ is a set of
+tools for working with CCS static data files. CCS tools includes a
+definition of the human-readable CCS static data YAML format and includes a
+program to convert it to a binary.
Register definition generator
-----------------------------
diff --git a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs
index 2a4edc7e051a..3d3152b45821 100755
--- a/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs
+++ b/Documentation/driver-api/media/drivers/ccs/mk-ccs-regs
@@ -82,14 +82,6 @@ for my $fh ($H, $LH) {
print $fh "/* $license */\n$copyright$note\n";
}
-sub bit_def($) {
- my $bit = shift @_;
-
- return "BIT($bit)" if defined $kernel;
- return "(1U << $bit)" if $bit =~ /^[a-zA-Z0-9_]+$/;
- return "(1U << ($bit))";
-}
-
print $H <<EOF
#ifndef __${uc_header}__
#define __${uc_header}__
@@ -97,23 +89,63 @@ print $H <<EOF
EOF
;
-print $H "#include <linux/bits.h>\n\n" if defined $kernel;
-
print $H <<EOF
-#define CCS_FL_BASE 16
+#include <linux/bits.h>
+
+#include <media/v4l2-cci.h>
+
EOF
- ;
+ if defined $kernel;
+
+print $H "#define CCS_FL_BASE " .
+ (defined $kernel ? "CCI_REG_PRIVATE_SHIFT" : 16) . "\n";
+
+my $flag = -1;
+my $all_flags;
+
+sub bit_def($) {
+ my $bit = shift @_;
+
+ if (defined $kernel) {
+ return "BIT$bit" if $bit =~ /^\(.*\)$/;
+ return "BIT($bit)";
+ }
+ return "(1U << $bit)";
+}
+
+sub flag_str($$) {
+ my ($flag, $check) = @_;
-print $H "#define CCS_FL_16BIT " . bit_def("CCS_FL_BASE") . "\n";
-print $H "#define CCS_FL_32BIT " . bit_def("CCS_FL_BASE + 1") . "\n";
-print $H "#define CCS_FL_FLOAT_IREAL " . bit_def("CCS_FL_BASE + 2") . "\n";
-print $H "#define CCS_FL_IREAL " . bit_def("CCS_FL_BASE + 3") . "\n";
+ $$flag++;
+
+ my $flag_str = !$$flag ? "CCS_FL_BASE" : "(CCS_FL_BASE + $$flag)";
+
+ $flag_str = bit_def($flag_str);
+
+ $$check .= " | " if defined $$check;
+
+ $$check .= $flag_str;
+
+ return $flag_str;
+}
+
+if (! defined $kernel) {
+ print $H "#define CCS_FL_16BIT " . flag_str(\$flag, \$all_flags) . "\n";
+ print $H "#define CCS_FL_32BIT " . flag_str(\$flag, \$all_flags) . "\n";
+}
+
+print $H "#define CCS_FL_FLOAT_IREAL " . flag_str(\$flag, \$all_flags) . "\n";
+print $H "#define CCS_FL_IREAL " . flag_str(\$flag, \$all_flags) . "\n";
+print $H "#define CCS_BUILD_BUG \\
+ BUILD_BUG_ON(~CCI_REG_PRIVATE_MASK & ($all_flags))\n"
+ if defined $kernel;
print $H <<EOF
+
#define CCS_R_ADDR(r) ((r) & 0xffff)
EOF
- ;
+ if ! defined $kernel;
print $A <<EOF
#include <stdint.h>
@@ -189,12 +221,12 @@ sub tabconv($) {
return (join "\n", @l) . "\n";
}
-sub elem_size(@) {
+sub elem_bits(@) {
my @flags = @_;
- return 2 if grep /^16$/, @flags;
- return 4 if grep /^32$/, @flags;
- return 1;
+ return 16 if grep /^16$/, @flags;
+ return 32 if grep /^32$/, @flags;
+ return 8;
}
sub arr_size($) {
@@ -296,9 +328,13 @@ while (<$R>) {
next if $#{$this{args}} + 1 != scalar keys %{$this{argparams}};
- my $reg_formula = "($this{addr}";
+ my $reg_formula = "$this{addr}";
my $lim_formula;
+ chop $reg_formula;
+
+ $reg_formula = "(" . $reg_formula if $this{flagstring} ne "";
+
foreach my $arg (@{$this{args}}) {
my $d = $h->{$arg}->{discontig};
my $times = $h->{$arg}->{elsize} != 1 ?
@@ -315,11 +351,13 @@ while (<$R>) {
$lim_formula .= (defined $lim_formula ? " + " : "") . "($arg)$times";
}
- $reg_formula .= ")\n";
+ $reg_formula .= ")";
$lim_formula =~ s/^\(([a-z0-9]+)\)$/$1/i;
print $H tabconv sprintf("#define %-62s %s", "CCS_R_" . (uc $this{name}) .
- $this{arglist}, $reg_formula);
+ $this{arglist}, $reg_formula .
+ (($this{flagstring} eq "") ? "" :
+ " | " . $this{flagstring} . ")") . "\n");
print $H tabconv $hdr_data;
undef $hdr_data;
@@ -369,16 +407,23 @@ while (<$R>) {
$name =~ s/[,\.-]/_/g;
my $flagstring = "";
- my $size = elem_size(@flags);
- $flagstring .= "| CCS_FL_16BIT " if $size eq "2";
- $flagstring .= "| CCS_FL_32BIT " if $size eq "4";
+ my $bits = elem_bits(@flags);
+ if (! defined $kernel) {
+ $flagstring .= "| CCS_FL_16BIT " if $bits == 16;
+ $flagstring .= "| CCS_FL_32BIT " if $bits == 32;
+ }
$flagstring .= "| CCS_FL_FLOAT_IREAL " if grep /^float_ireal$/, @flags;
$flagstring .= "| CCS_FL_IREAL " if grep /^ireal$/, @flags;
$flagstring =~ s/^\| //;
$flagstring =~ s/ $//;
$flagstring = "($flagstring)" if $flagstring =~ /\|/;
my $base_addr = $addr;
- $addr = "($addr | $flagstring)" if $flagstring ne "";
+ $addr = "CCI_REG$bits($addr)" if defined $kernel;
+
+ if ($flagstring ne "" && !@$args) {
+ $addr = "($addr | $flagstring)";
+ $flagstring = "";
+ }
my $arglist = @$args ? "(" . (join ", ", @$args) . ")" : "";
$hdr_data .= sprintf "#define %-62s %s\n", "CCS_R_" . (uc $name), $addr
@@ -388,11 +433,12 @@ while (<$R>) {
%this = ( name => $name,
addr => $addr,
+ flagstring => $flagstring,
base_addr => $base_addr,
argparams => {},
args => $args,
arglist => $arglist,
- elsize => $size,
+ elsize => $bits / 8,
);
if (!@$args) {
diff --git a/Documentation/driver-api/media/drivers/cpia2_devel.rst b/Documentation/driver-api/media/drivers/cpia2_devel.rst
deleted file mode 100644
index decaa4768c78..000000000000
--- a/Documentation/driver-api/media/drivers/cpia2_devel.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The cpia2 driver
-================
-
-Authors: Peter Pregler <Peter_Pregler@email.com>,
-Scott J. Bertin <scottbertin@yahoo.com>, and
-Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
-this one was modelled from.
-
-
-Notes to developers
-~~~~~~~~~~~~~~~~~~~
-
- - This is a driver version stripped of the 2.4 back compatibility
- and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
-
-Programmer's overview of cpia2 driver
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
-division of ST Microelectronics). There are two versions. The first is the
-STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
-up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version,
-which can handle up to 30 fps VGA. Both coprocessors can be attached to two
-CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will
-be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
-
-The two chipsets operate almost identically. The core is an 8051 processor,
-running two different versions of firmware. The 672 runs the VP4 video
-processor code, the 676 runs VP5. There are a few differences in register
-mappings for the two chips. In these cases, the symbols defined in the
-header files are marked with VP4 or VP5 as part of the symbol name.
-
-The cameras appear externally as three sets of registers. Setting register
-values is the only way to control the camera. Some settings are
-interdependant, such as the sequence required to power up the camera. I will
-try to make note of all of these cases.
-
-The register sets are called blocks. Block 0 is the system block. This
-section is always powered on when the camera is plugged in. It contains
-registers that control housekeeping functions such as powering up the video
-processor. The video processor is the VP block. These registers control
-how the video from the sensor is processed. Examples are timing registers,
-user mode (vga, qvga), scaling, cropping, framerates, and so on. The last
-block is the video compressor (VC). The video stream sent from the camera is
-compressed as Motion JPEG (JPEGA). The VC controls all of the compression
-parameters. Looking at the file cpia2_registers.h, you can get a full view
-of these registers and the possible values for most of them.
-
-One or more registers can be set or read by sending a usb control message to
-the camera. There are three modes for this. Block mode requests a number
-of contiguous registers. Random mode reads or writes random registers with
-a tuple structure containing address/value pairs. The repeat mode is only
-used by VP4 to load a firmware patch. It contains a starting address and
-a sequence of bytes to be written into a gpio port.
diff --git a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst
deleted file mode 100644
index 4e87bdbc7ae4..000000000000
--- a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-The VPBE V4L2 driver design
-===========================
-
-File partitioning
------------------
-
- V4L2 display device driver
- drivers/media/platform/ti/davinci/vpbe_display.c
- drivers/media/platform/ti/davinci/vpbe_display.h
-
- VPBE display controller
- drivers/media/platform/ti/davinci/vpbe.c
- drivers/media/platform/ti/davinci/vpbe.h
-
- VPBE venc sub device driver
- drivers/media/platform/ti/davinci/vpbe_venc.c
- drivers/media/platform/ti/davinci/vpbe_venc.h
- drivers/media/platform/ti/davinci/vpbe_venc_regs.h
-
- VPBE osd driver
- drivers/media/platform/ti/davinci/vpbe_osd.c
- drivers/media/platform/ti/davinci/vpbe_osd.h
- drivers/media/platform/ti/davinci/vpbe_osd_regs.h
-
-To be done
-----------
-
-vpbe display controller
- - Add support for external encoders.
- - add support for selecting external encoder as default at probe time.
-
-vpbe venc sub device
- - add timings for supporting ths8200
- - add support for LogicPD LCD.
-
-FB drivers
- - Add support for fbdev drivers.- Ready and part of subsequent patches.
diff --git a/Documentation/driver-api/media/drivers/index.rst b/Documentation/driver-api/media/drivers/index.rst
index 32406490557c..7f6f3dcd5c90 100644
--- a/Documentation/driver-api/media/drivers/index.rst
+++ b/Documentation/driver-api/media/drivers/index.rst
@@ -13,10 +13,8 @@ Video4Linux (V4L) drivers
:maxdepth: 5
bttv-devel
- cpia2_devel
cx2341x-devel
cx88-devel
- davinci-vpbe-devel
fimc-devel
pvrusb2
pxa_camera
@@ -28,6 +26,7 @@ Video4Linux (V4L) drivers
vimc-devel
zoran
ccs/ccs
+ ipu6
Digital TV drivers
diff --git a/Documentation/driver-api/media/drivers/ipu6.rst b/Documentation/driver-api/media/drivers/ipu6.rst
new file mode 100644
index 000000000000..88f6498e74db
--- /dev/null
+++ b/Documentation/driver-api/media/drivers/ipu6.rst
@@ -0,0 +1,190 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================
+Intel IPU6 Driver
+==================
+
+Author: Bingbu Cao <bingbu.cao@intel.com>
+
+Overview
+=========
+
+Intel IPU6 is the sixth generation of Intel Image Processing Unit used in some
+Intel Chipsets such as Tiger Lake, Jasper Lake, Alder Lake, Raptor Lake and
+Meteor Lake. IPU6 consists of two major systems: Input System (ISYS) and
+Processing System (PSYS). IPU6 are visible on the PCI bus as a single device, it
+can be found by ``lspci``:
+
+``0000:00:05.0 Multimedia controller: Intel Corporation Device xxxx (rev xx)``
+
+IPU6 has a 16 MB BAR in PCI configuration Space for MMIO registers which is
+visible for driver.
+
+Buttress
+=========
+
+The IPU6 is connecting to the system fabric with Buttress which is enabling host
+driver to control the IPU6, it also allows IPU6 access the system memory to
+store and load frame pixel streams and any other metadata.
+
+Buttress mainly manages several system functionalities: power management,
+interrupt handling, firmware authentication and global timer sync.
+
+ISYS and PSYS Power flow
+------------------------
+
+IPU6 driver initialize the ISYS and PSYS power up or down request by setting the
+Buttress frequency control register for ISYS and PSYS
+(``IPU6_BUTTRESS_REG_IS_FREQ_CTL`` and ``IPU6_BUTTRESS_REG_PS_FREQ_CTL``) in
+function:
+
+.. c:function:: int ipu6_buttress_power(...)
+
+Buttress forwards the request to Punit, after Punit execute the power up flow,
+Buttress indicates driver that ISYS or PSYS is powered up by updating the power
+status registers.
+
+.. Note:: ISYS power up needs take place prior to PSYS power up, ISYS power down
+ needs take place after PSYS power down due to hardware limitation.
+
+Interrupt
+---------
+
+IPU6 interrupt can be generated as MSI or INTA, interrupt will be triggered when
+ISYS, PSYS, Buttress event or error happen, driver can get the interrupt cause
+by reading the interrupt status register ``BUTTRESS_REG_ISR_STATUS``, driver
+clears the irq status and then calls specific ISYS or PSYS irq handler.
+
+.. c:function:: irqreturn_t ipu6_buttress_isr(int irq, ...)
+
+Security and firmware authentication
+-------------------------------------
+
+To address the IPU6 firmware security concerns, the IPU6 firmware needs to
+undergo an authentication process before it is allowed to executed on the IPU6
+internal processors. The IPU6 driver will work with Converged Security Engine
+(CSE) to complete authentication process. The CSE is responsible of
+authenticating the IPU6 firmware. The authenticated firmware binary is copied
+into an isolated memory region. Firmware authentication process is implemented
+by CSE following an IPC handshake with the IPU6 driver. There are some Buttress
+registers used by the CSE and the IPU6 driver to communicate with each other via
+IPC.
+
+.. c:function:: int ipu6_buttress_authenticate(...)
+
+Global timer sync
+-----------------
+
+The IPU6 driver initiates a Hammock Harbor synchronization flow each time it
+starts camera operation. The IPU6 will synchronizes an internal counter in the
+Buttress with a copy of the SoC time, this counter maintains the up-to-date time
+until camera operation is stopped. The IPU6 driver can use this time counter to
+calibrate the timestamp based on the timestamp in response event from firmware.
+
+.. c:function:: int ipu6_buttress_start_tsc_sync(...)
+
+DMA and MMU
+============
+
+The IPU6 has its own scalar processor where the firmware run at and an internal
+32-bit virtual address space. The IPU6 has MMU address translation hardware to
+allow that scalar processors to access the internal memory and external system
+memory through IPU6 virtual address. The address translation is based on two
+levels of page lookup tables stored in system memory which are maintained by the
+IPU6 driver. The IPU6 driver sets the level-1 page table base address to MMU
+register and allows MMU to perform page table lookups.
+
+The IPU6 driver exports its own DMA operations. The IPU6 driver will update the
+page table entries for each DMA operation and invalidate the MMU TLB after each
+unmap and free.
+
+Firmware file format
+====================
+
+The IPU6 firmware is in Code Partition Directory (CPD) file format. The CPD
+firmware contains a CPD header, several CPD entries and components. The CPD
+component includes 3 entries - manifest, metadata and module data. Manifest and
+metadata are defined by CSE and used by CSE for authentication. Module data is
+specific to IPU6 which holds the binary data of firmware called package
+directory. The IPU6 driver (``ipu6-cpd.c`` in particular) parses and validates
+the CPD firmware file and gets the package directory binary data of the IPU6
+firmware, copies it to specific DMA buffer and sets its base address to Buttress
+``FW_SOURCE_BASE`` register. Finally the CSE will do authentication for this
+firmware binary.
+
+
+Syscom interface
+================
+
+The IPU6 driver communicates with firmware via the Syscom ABI. Syscom is an
+inter-processor communication mechanism between the IPU scalar processors and
+the CPU. There are a number of resources shared between firmware and software.
+A system memory region where the message queues reside, firmware can access the
+memory region via the IPU MMU. The Syscom queues are FIFO fixed depth queues
+with a configurable number of tokens (messages). There are also common IPU6 MMIO
+registers where the queue read and write indices reside. Software and firmware
+function as producer and consumer of tokens in the queues and update the write
+and read indices separately when sending or receiving each message.
+
+The IPU6 driver must prepare and configure the number of input and output
+queues, configure the count of tokens per queue and the size of per token before
+initiating and starting the communication with firmware. Firmware and software
+must use same configurations. The IPU6 Buttress has a number of firmware boot
+parameter registers which can be used to store the address of configuration and
+initialise the Syscom state, then driver can request firmware to start and run via
+setting the scalar processor control status register.
+
+Input System
+============
+
+IPU6 input system consists of MIPI D-PHY and several CSI-2 receivers. It can
+capture image pixel data from camera sensors or other MIPI CSI-2 output devices.
+
+D-PHYs and CSI-2 ports lane mapping
+-----------------------------------
+
+The IPU6 integrates different D-PHY IPs on different SoCs, on Tiger Lake and
+Alder Lake, IPU6 integrates MCD10 D-PHY, IPU6SE on Jasper Lake integrates JSL
+D-PHY and IPU6EP on Meteor Lake integrates a Synopsys DWC D-PHY. There is an
+adaptional layer between D-PHY and CSI-2 receiver controller which includes port
+configuration, PHY wrapper or private test interfaces for D-PHY. There are 3
+D-PHY drivers ``ipu6-isys-mcd-phy.c``, ``ipu6-isys-jsl-phy.c`` and
+``ipu6-isys-dwc-phy.c`` program the above 3 D-PHYs in IPU6.
+
+Different IPU6 versions have different D-PHY lanes mappings, On Tiger Lake,
+there are 12 data lanes and 8 clock lanes, IPU6 support maximum 8 CSI-2 ports,
+see the PPI mmapping in ``ipu6-isys-mcd-phy.c`` for more information. On Jasper
+Lake and Alder Lake, D-PHY has 8 data lanes and 4 clock lanes, the IPU6 supports
+maximum 4 CSI-2 ports. For Meteor Lake, D-PHY has 12 data lanes and 6 clock
+lanes so IPU6 support maximum 6 CSI-2 ports.
+
+.. Note:: Each pair of CSI-2 two ports is a single unit that can share the data
+ lanes. For example, for CSI-2 port 0 and 1, CSI-2 port 0 support
+ maximum 4 data lanes, CSI-2 port 1 support maximum 2 data lanes, CSI-2
+ port 0 with 2 data lanes can work together with CSI-2 port 1 with 2
+ data lanes. If trying to use CSI-2 port 0 with 4 lanes, CSI-2 port 1
+ will not be available as the 4 data lanes are shared by CSI-2 port 0
+ and 1. The same applies to CSI ports 2/3, 4/5 and 7/8.
+
+ISYS firmware ABIs
+------------------
+
+The IPU6 firmware implements a series of ABIs for software access. In general,
+software firstly prepares the stream configuration ``struct
+ipu6_fw_isys_stream_cfg_data_abi`` and sends the configuration to firmware via
+sending ``STREAM_OPEN`` command. Stream configuration includes input pins and
+output pins, input pin ``struct ipu6_fw_isys_input_pin_info_abi`` defines the
+resolution and data type of input source, output pin ``struct
+ipu6_fw_isys_output_pin_info_abi`` defines the output resolution, stride and
+frame format, etc.
+
+Once the driver gets the interrupt from firmware that indicates stream open
+successfully, the driver will send the ``STREAM_START`` and ``STREAM_CAPTURE``
+command to request firmware to start capturing image frames. ``STREAM_CAPTURE``
+command queues the buffers to firmware with ``struct
+ipu6_fw_isys_frame_buff_set``, software then waits for the interrupt and
+response from firmware, ``PIN_DATA_READY`` means a buffer is ready on a specific
+output pin and then software can return the buffer to user.
+
+.. Note:: See :ref:`Examples<ipu6_isys_capture_examples>` about how to do
+ capture by IPU6 ISYS driver.
diff --git a/Documentation/driver-api/media/drivers/vidtv.rst b/Documentation/driver-api/media/drivers/vidtv.rst
index 673bdff919ea..54f269f478d3 100644
--- a/Documentation/driver-api/media/drivers/vidtv.rst
+++ b/Documentation/driver-api/media/drivers/vidtv.rst
@@ -28,7 +28,7 @@ Currently, it consists of:
takes parameters at initialization that will dictate how the simulation
behaves.
-- Code reponsible for encoding a valid MPEG Transport Stream, which is then
+- Code responsible for encoding a valid MPEG Transport Stream, which is then
passed to the bridge driver. This fake stream contains some hardcoded content.
For now, we have a single, audio-only channel containing a single MPEG
Elementary Stream, which in turn contains a SMPTE 302m encoded sine-wave.
diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst
index b205e10c3154..3e05b7f0442a 100644
--- a/Documentation/driver-api/media/drivers/zoran.rst
+++ b/Documentation/driver-api/media/drivers/zoran.rst
@@ -222,7 +222,7 @@ The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
Ireland, Nigeria, South Africa.
The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
-and is used in Argentinia, Uruguay, an a few others
+and is used in Argentina, Uruguay, an a few others
We do not talk about how the audio is broadcast !
diff --git a/Documentation/driver-api/media/dtv-common.rst b/Documentation/driver-api/media/dtv-common.rst
index f8b2c4dc8170..207a22bcaf4a 100644
--- a/Documentation/driver-api/media/dtv-common.rst
+++ b/Documentation/driver-api/media/dtv-common.rst
@@ -3,15 +3,6 @@
Digital TV Common functions
---------------------------
-Math functions
-~~~~~~~~~~~~~~
-
-Provide some commonly-used math functions, usually required in order to
-estimate signal strength and signal to noise measurements in dB.
-
-.. kernel-doc:: include/media/dvb_math.h
-
-
DVB devices
~~~~~~~~~~~
diff --git a/Documentation/driver-api/media/dtv-demux.rst b/Documentation/driver-api/media/dtv-demux.rst
index c0ae5dec5328..144124142622 100644
--- a/Documentation/driver-api/media/dtv-demux.rst
+++ b/Documentation/driver-api/media/dtv-demux.rst
@@ -24,7 +24,7 @@ unless this is fixed in the HW platform.
The demux kABI only controls front-ends regarding to their connections with
demuxes; the kABI used to set the other front-end parameters, such as
-tuning, are devined via the Digital TV Frontend kABI.
+tuning, are defined via the Digital TV Frontend kABI.
The functions that implement the abstract interface demux should be defined
static or module private and registered to the Demux core for external
diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst
index 08e206567408..d5593182a3f9 100644
--- a/Documentation/driver-api/media/index.rst
+++ b/Documentation/driver-api/media/index.rst
@@ -20,13 +20,8 @@ Documentation/userspace-api/media/index.rst
- for the userspace APIs used on media devices.
-.. only:: html
-
- .. class:: toc-title
-
- Table of Contents
-
.. toctree::
+ :caption: Table of Contents
:maxdepth: 5
:numbered:
diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
index ffc712a5f632..2127e5b15e8f 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -75,7 +75,7 @@ The media maintainers that work on specific areas of the subsystem are:
Sean Young <sean@mess.org>
- HDMI CEC:
- Hans Verkuil <hverkuil@xs4all.nl>
+ Hans Verkuil <hverkuil@kernel.org>
- Media controller drivers:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
@@ -84,7 +84,7 @@ The media maintainers that work on specific areas of the subsystem are:
Sakari Ailus <sakari.ailus@linux.intel.com>
- V4L2 drivers and core V4L2 frameworks:
- Hans Verkuil <hverkuil@xs4all.nl>
+ Hans Verkuil <hverkuil@kernel.org>
The subsystem maintainer is:
Mauro Carvalho Chehab <mchehab@kernel.org>
@@ -116,7 +116,7 @@ CEC drivers ``cec-compliance``
.. [3] The ``v4l2-compliance`` also covers the media controller usage inside
V4L2 drivers.
-Other compilance tools are under development to check other parts of the
+Other compliance tools are under development to check other parts of the
subsystem.
Those tests need to pass before the patches go upstream.
diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst
index 84aa7cdb5341..1d010bd7ec49 100644
--- a/Documentation/driver-api/media/mc-core.rst
+++ b/Documentation/driver-api/media/mc-core.rst
@@ -144,7 +144,8 @@ valid values are described at :c:func:`media_create_pad_link()` and
Graph traversal
^^^^^^^^^^^^^^^
-The media framework provides APIs to iterate over entities in a graph.
+The media framework provides APIs to traverse media graphs, locating connected
+entities and links.
To iterate over all entities belonging to a media device, drivers can use
the media_device_for_each_entity macro, defined in
@@ -159,31 +160,6 @@ the media_device_for_each_entity macro, defined in
...
}
-Drivers might also need to iterate over all entities in a graph that can be
-reached only through enabled links starting at a given entity. The media
-framework provides a depth-first graph traversal API for that purpose.
-
-.. note::
-
- Graphs with cycles (whether directed or undirected) are **NOT**
- supported by the graph traversal API. To prevent infinite loops, the graph
- traversal code limits the maximum depth to ``MEDIA_ENTITY_ENUM_MAX_DEPTH``,
- currently defined as 16.
-
-Drivers initiate a graph traversal by calling
-:c:func:`media_graph_walk_start()`
-
-The graph structure, provided by the caller, is initialized to start graph
-traversal at the given entity.
-
-Drivers can then retrieve the next entity by calling
-:c:func:`media_graph_walk_next()`
-
-When the graph traversal is complete the function will return ``NULL``.
-
-Graph traversal can be interrupted at any moment. No cleanup function call
-is required and the graph structure can be freed normally.
-
Helper functions can be used to find a link between two given pads, or a pad
connected to another pad through an enabled link
(:c:func:`media_entity_find_link()`, :c:func:`media_pad_remote_pad_first()`,
@@ -214,19 +190,28 @@ Link properties can be modified at runtime by calling
Pipelines and media streams
^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A media stream is a stream of pixels or metadata originating from one or more
+source devices (such as a sensors) and flowing through media entity pads
+towards the final sinks. The stream can be modified on the route by the
+devices (e.g. scaling or pixel format conversions), or it can be split into
+multiple branches, or multiple branches can be merged.
+
+A media pipeline is a set of media streams which are interdependent. This
+interdependency can be caused by the hardware (e.g. configuration of a second
+stream cannot be changed if the first stream has been enabled) or by the driver
+due to the software design. Most commonly a media pipeline consists of a single
+stream which does not branch.
+
When starting streaming, drivers must notify all entities in the pipeline to
prevent link states from being modified during streaming by calling
:c:func:`media_pipeline_start()`.
-The function will mark all entities connected to the given entity through
-enabled links, either directly or indirectly, as streaming.
+The function will mark all the pads which are part of the pipeline as streaming.
-The struct media_pipeline instance pointed to by
-the pipe argument will be stored in every entity in the pipeline.
-Drivers should embed the struct media_pipeline
-in higher-level pipeline structures and can then access the
-pipeline through the struct media_entity
-pipe field.
+The struct media_pipeline instance pointed to by the pipe argument will be
+stored in every pad in the pipeline. Drivers should embed the struct
+media_pipeline in higher-level pipeline structures and can then access the
+pipeline through the struct media_pad pipe field.
Calls to :c:func:`media_pipeline_start()` can be nested.
The pipeline pointer must be identical for all nested calls to the function.
@@ -267,6 +252,45 @@ Subsystems should facilitate link validation by providing subsystem specific
helper functions to provide easy access for commonly needed information, and
in the end provide a way to use driver-specific callbacks.
+Pipeline traversal
+^^^^^^^^^^^^^^^^^^
+
+Once a pipeline has been constructed with :c:func:`media_pipeline_start()`,
+drivers can iterate over entities or pads in the pipeline with the
+:c:macro:´media_pipeline_for_each_entity` and
+:c:macro:´media_pipeline_for_each_pad` macros. Iterating over pads is
+straightforward:
+
+.. code-block:: c
+
+ media_pipeline_pad_iter iter;
+ struct media_pad *pad;
+
+ media_pipeline_for_each_pad(pipe, &iter, pad) {
+ /* 'pad' will point to each pad in turn */
+ ...
+ }
+
+To iterate over entities, the iterator needs to be initialized and cleaned up
+as an additional steps:
+
+.. code-block:: c
+
+ media_pipeline_entity_iter iter;
+ struct media_entity *entity;
+ int ret;
+
+ ret = media_pipeline_entity_iter_init(pipe, &iter);
+ if (ret)
+ ...;
+
+ media_pipeline_for_each_entity(pipe, &iter, entity) {
+ /* 'entity' will point to each entity in turn */
+ ...
+ }
+
+ media_pipeline_entity_iter_cleanup(&iter);
+
Media Controller Device Allocator API
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst
index e1e9258dd862..22e1b13ecde9 100644
--- a/Documentation/driver-api/media/tx-rx.rst
+++ b/Documentation/driver-api/media/tx-rx.rst
@@ -6,13 +6,13 @@ Pixel data transmitter and receiver drivers
===========================================
V4L2 supports various devices that transmit and receive pixel data. Examples of
-these devices include a camera sensor, a TV tuner and a parallel or a CSI-2
-receiver in an SoC.
+these devices include a camera sensor, a TV tuner and a parallel, a BT.656 or a
+CSI-2 receiver in an SoC.
Bus types
---------
-The following busses are the most common. This section discusses these two only.
+The following buses are the most common. This section discusses these two only.
MIPI CSI-2
^^^^^^^^^^
@@ -22,12 +22,13 @@ the host SoC. It is defined by the `MIPI alliance`_.
.. _`MIPI alliance`: https://www.mipi.org/
-Parallel
-^^^^^^^^
+Parallel and BT.656
+^^^^^^^^^^^^^^^^^^^
-`BT.601`_ and `BT.656`_ are the most common parallel busses.
+The parallel and `BT.656`_ buses transport one bit of data on each clock cycle
+per data line. The parallel bus uses synchronisation and other additional
+signals whereas BT.656 embeds synchronisation.
-.. _`BT.601`: https://en.wikipedia.org/wiki/Rec._601
.. _`BT.656`: https://en.wikipedia.org/wiki/ITU-R_BT.656
Transmitter drivers
@@ -35,7 +36,7 @@ Transmitter drivers
Transmitter drivers generally need to provide the receiver drivers with the
configuration of the transmitter. What is required depends on the type of the
-bus. These are common for both busses.
+bus. These are common for both buses.
Media bus pixel code
^^^^^^^^^^^^^^^^^^^^
@@ -48,12 +49,31 @@ Link frequency
The :ref:`V4L2_CID_LINK_FREQ <v4l2-cid-link-freq>` control is used to tell the
receiver the frequency of the bus (i.e. it is not the same as the symbol rate).
-``.s_stream()`` callback
-^^^^^^^^^^^^^^^^^^^^^^^^
+Drivers that do not have user-configurable link frequency should report it
+through the ``.get_mbus_config()`` subdev pad operation, in the ``link_freq``
+field of struct v4l2_mbus_config, instead of through controls.
+
+Receiver drivers should use :c:func:`v4l2_get_link_freq` helper to obtain the
+link frequency from the transmitter sub-device.
+
+``.enable_streams()`` and ``.disable_streams()`` callbacks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The struct struct v4l2_subdev_video_ops->s_stream() callback is used by the
-receiver driver to control the transmitter driver's streaming state.
+The struct v4l2_subdev_pad_ops->enable_streams() and struct
+v4l2_subdev_pad_ops->disable_streams() callbacks are used by the receiver driver
+to control the transmitter driver's streaming state. These callbacks may not be
+called directly, but by using ``v4l2_subdev_enable_streams()`` and
+``v4l2_subdev_disable_streams()``.
+
+Stopping the transmitter
+^^^^^^^^^^^^^^^^^^^^^^^^
+A transmitter stops sending the stream of images as a result of
+calling the ``.disable_streams()`` callback. Some transmitters may stop the
+stream at a frame boundary whereas others stop immediately,
+effectively leaving the current frame unfinished. The receiver driver
+should not make assumptions either way, but function properly in both
+cases.
CSI-2 transmitter drivers
-------------------------
@@ -75,14 +95,15 @@ where
* - link_freq
- The value of the ``V4L2_CID_LINK_FREQ`` integer64 menu item.
* - nr_of_lanes
- - Number of data lanes used on the CSI-2 link. This can
- be obtained from the OF endpoint configuration.
+ - Number of data lanes used on the CSI-2 link.
* - 2
- Data is transferred on both rising and falling edge of the signal.
* - bits_per_sample
- Number of bits per sample.
* - k
- - 16 for D-PHY and 7 for C-PHY
+ - 16 for D-PHY and 7 for C-PHY.
+
+Information on whether D-PHY or C-PHY is used, and the value of ``nr_of_lanes``, can be obtained from the OF endpoint configuration.
.. note::
@@ -90,8 +111,8 @@ where
pixel rate on the camera sensor's pixel array which is indicated by the
:ref:`V4L2_CID_PIXEL_RATE <v4l2-cid-pixel-rate>` control.
-LP-11 and LP-111 modes
-^^^^^^^^^^^^^^^^^^^^^^
+LP-11 and LP-111 states
+^^^^^^^^^^^^^^^^^^^^^^^
As part of transitioning to high speed mode, a CSI-2 transmitter typically
briefly sets the bus to LP-11 or LP-111 state, depending on the PHY. This period
@@ -105,7 +126,7 @@ in software, especially when there is no interrupt telling something is
happening.
One way to address this is to configure the transmitter side explicitly to LP-11
-or LP-111 mode, which requires support from the transmitter hardware. This is
+or LP-111 state, which requires support from the transmitter hardware. This is
not universally available. Many devices return to this state once streaming is
stopped while the state after power-on is LP-00 or LP-000.
@@ -116,18 +137,8 @@ transitioning to streaming state, but not yet start streaming. Similarly, the
to call ``.post_streamoff()`` for each successful call of ``.pre_streamon()``.
In the context of CSI-2, the ``.pre_streamon()`` callback is used to transition
-the transmitter to the LP-11 or LP-111 mode. This also requires powering on the
+the transmitter to the LP-11 or LP-111 state. This also requires powering on the
device, so this should be only done when it is needed.
-Receiver drivers that do not need explicit LP-11 or LP-111 mode setup are waived
-from calling the two callbacks.
-
-Stopping the transmitter
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-A transmitter stops sending the stream of images as a result of
-calling the ``.s_stream()`` callback. Some transmitters may stop the
-stream at a frame boundary whereas others stop immediately,
-effectively leaving the current frame unfinished. The receiver driver
-should not make assumptions either way, but function properly in both
-cases.
+Receiver drivers that do not need explicit LP-11 or LP-111 state setup are
+waived from calling the two callbacks.
diff --git a/Documentation/driver-api/media/v4l2-cci.rst b/Documentation/driver-api/media/v4l2-cci.rst
new file mode 100644
index 000000000000..dd297a40ed20
--- /dev/null
+++ b/Documentation/driver-api/media/v4l2-cci.rst
@@ -0,0 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+V4L2 CCI kAPI
+^^^^^^^^^^^^^
+.. kernel-doc:: include/media/v4l2-cci.h
diff --git a/Documentation/driver-api/media/v4l2-controls.rst b/Documentation/driver-api/media/v4l2-controls.rst
index b2e91804829b..fc04907589ab 100644
--- a/Documentation/driver-api/media/v4l2-controls.rst
+++ b/Documentation/driver-api/media/v4l2-controls.rst
@@ -110,6 +110,7 @@ For sub-device drivers:
v4l2_ctrl_handler_free(&foo->ctrl_handler);
+:c:func:`v4l2_ctrl_handler_free` does not touch the handler's ``error`` field.
2) Add controls:
@@ -191,12 +192,8 @@ These functions are typically called right after the
V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0,
0, test_pattern);
...
- if (foo->ctrl_handler.error) {
- int err = foo->ctrl_handler.error;
-
- v4l2_ctrl_handler_free(&foo->ctrl_handler);
- return err;
- }
+ if (foo->ctrl_handler.error)
+ return v4l2_ctrl_handler_free(&foo->ctrl_handler);
The :c:func:`v4l2_ctrl_new_std` function returns the v4l2_ctrl pointer to
the new control, but if you do not need to access the pointer outside the
diff --git a/Documentation/driver-api/media/v4l2-core.rst b/Documentation/driver-api/media/v4l2-core.rst
index 1a8c4a5f256b..a5f5102c64cc 100644
--- a/Documentation/driver-api/media/v4l2-core.rst
+++ b/Documentation/driver-api/media/v4l2-core.rst
@@ -13,7 +13,6 @@ Video4Linux devices
v4l2-subdev
v4l2-event
v4l2-controls
- v4l2-videobuf
v4l2-videobuf2
v4l2-dv-timings
v4l2-flash-led-class
@@ -22,7 +21,10 @@ Video4Linux devices
v4l2-mem2mem
v4l2-async
v4l2-fwnode
+ v4l2-cci
v4l2-rect
v4l2-tuner
v4l2-common
v4l2-tveeprom
+ v4l2-jpeg
+ v4l2-isp
diff --git a/Documentation/driver-api/media/v4l2-dev.rst b/Documentation/driver-api/media/v4l2-dev.rst
index 99e3b5fa7444..d5cb19b21a9f 100644
--- a/Documentation/driver-api/media/v4l2-dev.rst
+++ b/Documentation/driver-api/media/v4l2-dev.rst
@@ -157,14 +157,6 @@ changing the e.g. exposure of the webcam.
Of course, you can always do all the locking yourself by leaving both lock
pointers at ``NULL``.
-If you use the old :ref:`videobuf framework <vb_framework>` then you must
-pass the :c:type:`video_device`->lock to the videobuf queue initialize
-function: if videobuf has to wait for a frame to arrive, then it will
-temporarily unlock the lock and relock it afterwards. If your driver also
-waits in the code, then you should do the same to allow other
-processes to access the device node while the first process is waiting for
-something.
-
In the case of :ref:`videobuf2 <vb2_framework>` you will need to implement the
``wait_prepare()`` and ``wait_finish()`` callbacks to unlock/lock if applicable.
If you use the ``queue->lock`` pointer, then you can use the helper functions
diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst
index 3eeaa8da0c9e..a934caa483a4 100644
--- a/Documentation/driver-api/media/v4l2-fh.rst
+++ b/Documentation/driver-api/media/v4l2-fh.rst
@@ -1,33 +1,27 @@
.. SPDX-License-Identifier: GPL-2.0
-V4L2 File handlers
-------------------
+V4L2 File handles
+-----------------
-struct v4l2_fh provides a way to easily keep file handle specific
-data that is used by the V4L2 framework.
+struct v4l2_fh provides a way to easily keep file handle specific data that is
+used by the V4L2 framework. Its usage is mandatory in all drivers.
-.. attention::
- New drivers must use struct v4l2_fh
- since it is also used to implement priority handling
- (:ref:`VIDIOC_G_PRIORITY`).
+struct v4l2_fh is allocated in the driver's ``open()`` file operation handler.
+It is typically embedded in a larger driver-specific structure. The
+:c:type:`v4l2_fh` must be initialized with a call to :c:func:`v4l2_fh_init`,
+and added to the video device with :c:func:`v4l2_fh_add`. This associates the
+:c:type:`v4l2_fh` with the :c:type:`file` by setting ``file->private_data`` to
+point to the :c:type:`v4l2_fh`.
-The users of :c:type:`v4l2_fh` (in the V4L2 framework, not the driver) know
-whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer
-by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags.
-This bit is set whenever :c:func:`v4l2_fh_init` is called.
+Similarly, the struct v4l2_fh is freed in the driver's ``release()`` file
+operation handler. It must be removed from the video device with
+:c:func:`v4l2_fh_del` and cleaned up with :c:func:`v4l2_fh_exit` before being
+freed.
-struct v4l2_fh is allocated as a part of the driver's own file handle
-structure and ``file->private_data`` is set to it in the driver's ``open()``
-function by the driver.
-
-In many cases the struct v4l2_fh will be embedded in a larger
-structure. In that case you should call:
-
-#) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()``
-#) :c:func:`v4l2_fh_del` and :c:func:`v4l2_fh_exit` in ``release()``
-
-Drivers can extract their own file handle structure by using the container_of
-macro.
+Drivers must not access ``file->private_data`` directly. They can retrieve the
+:c:type:`v4l2_fh` associated with a :c:type:`file` by calling
+:c:func:`file_to_v4l2_fh`. Drivers can extract their own file handle structure
+by using the container_of macro.
Example:
@@ -56,18 +50,17 @@ Example:
...
- file->private_data = &my_fh->fh;
- v4l2_fh_add(&my_fh->fh);
+ v4l2_fh_add(&my_fh->fh, file);
return 0;
}
int my_release(struct file *file)
{
- struct v4l2_fh *fh = file->private_data;
+ struct v4l2_fh *fh = file_to_v4l2_fh(file);
struct my_fh *my_fh = container_of(fh, struct my_fh, fh);
...
- v4l2_fh_del(&my_fh->fh);
+ v4l2_fh_del(&my_fh->fh, file);
v4l2_fh_exit(&my_fh->fh);
kfree(my_fh);
return 0;
@@ -78,19 +71,17 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
:c:func:`v4l2_fh_init <v4l2_fh_init>`
(:c:type:`fh <v4l2_fh>`, :c:type:`vdev <video_device>`)
-
- Initialise the file handle. This **MUST** be performed in the driver's
:c:type:`v4l2_file_operations`->open() handler.
-
:c:func:`v4l2_fh_add <v4l2_fh_add>`
-(:c:type:`fh <v4l2_fh>`)
+(:c:type:`fh <v4l2_fh>`, struct file \*filp)
- Add a :c:type:`v4l2_fh` to :c:type:`video_device` file handle list.
Must be called once the file handle is completely initialized.
:c:func:`v4l2_fh_del <v4l2_fh_del>`
-(:c:type:`fh <v4l2_fh>`)
+(:c:type:`fh <v4l2_fh>`, struct file \*filp)
- Unassociate the file handle from :c:type:`video_device`. The file handle
exit function may now be called.
@@ -101,6 +92,10 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
- Uninitialise the file handle. After uninitialisation the :c:type:`v4l2_fh`
memory can be freed.
+:c:func:`file_to_v4l2_fh <file_to_v4l2_fh>`
+(struct file \*filp)
+
+- Retrieve the :c:type:`v4l2_fh` instance associated with a :c:type:`file`.
If struct v4l2_fh is not embedded, then you can use these helper functions:
diff --git a/Documentation/driver-api/media/v4l2-isp.rst b/Documentation/driver-api/media/v4l2-isp.rst
new file mode 100644
index 000000000000..618ae614ff79
--- /dev/null
+++ b/Documentation/driver-api/media/v4l2-isp.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+V4L2 generic ISP parameters and statistics support
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Design rationale
+================
+
+ISP configuration parameters and statistics are processed and collected by
+drivers and exchanged with userspace through data types that usually
+reflect the ISP peripheral registers layout.
+
+Each ISP driver defines its own metadata output format for parameters and
+a metadata capture format for statistics. The buffer layout is realized by a
+set of C structures that reflects the registers layout. The number and types
+of C structures is fixed by the format definition and becomes part of the Linux
+kernel uAPI/uABI interface.
+
+Because of the hard requirement of backward compatibility when extending the
+user API/ABI interface, modifying an ISP driver capture or output metadata
+format after it has been accepted by mainline is very hard if not impossible.
+
+It generally happens, in fact, that after the first accepted revision of an ISP
+driver the buffers layout need to be modified, either to support new hardware
+blocks, to fix bugs or to support different revisions of the hardware.
+
+Each of these situations would require defining a new metadata format, making it
+really hard to maintain and extend drivers and requiring userspace to use
+the correct format depending on the kernel revision in use.
+
+V4L2 ISP configuration parameters
+=================================
+
+For these reasons, Video4Linux2 defines generic types for ISP configuration
+parameters and statistics. Drivers are still expected to define their own
+formats for their metadata output and capture nodes, but the buffers layout can
+be defined using the extensible and versioned types defined by
+include/uapi/linux/media/v4l2-isp.h.
+
+Drivers are expected to provide the definitions of their supported ISP blocks
+and the expected maximum size of a buffer.
+
+For driver developers a set of helper functions to assist them with validation
+of the buffer received from userspace is available in
+drivers/media/v4l2-core/v4l2-isp.c
+
+V4L2 ISP support driver documentation
+=====================================
+.. kernel-doc:: include/media/v4l2-isp.h
diff --git a/Documentation/driver-api/media/v4l2-jpeg.rst b/Documentation/driver-api/media/v4l2-jpeg.rst
new file mode 100644
index 000000000000..af3bc52f865b
--- /dev/null
+++ b/Documentation/driver-api/media/v4l2-jpeg.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+V4L2 JPEG header related functions and data structures
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: include/media/v4l2-jpeg.h
+ :internal:
+
+.. kernel-doc:: drivers/media/v4l2-core/v4l2-jpeg.c
+ :export:
diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst
index 6f8d79926aa5..13aec460e802 100644
--- a/Documentation/driver-api/media/v4l2-subdev.rst
+++ b/Documentation/driver-api/media/v4l2-subdev.rst
@@ -157,6 +157,9 @@ below.
Using one or the other registration method only affects the probing process, the
run-time bridge-subdevice interaction is in both cases the same.
+Registering synchronous sub-devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
In the **synchronous** case a device (bridge) driver needs to register the
:c:type:`v4l2_subdev` with the v4l2_device:
@@ -175,10 +178,14 @@ You can unregister a sub-device using:
:c:func:`v4l2_device_unregister_subdev <v4l2_device_unregister_subdev>`
(:c:type:`sd <v4l2_subdev>`).
-
Afterwards the subdev module can be unloaded and
:c:type:`sd <v4l2_subdev>`->dev == ``NULL``.
+.. _media-registering-async-subdevs:
+
+Registering asynchronous sub-devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
In the **asynchronous** case subdevice probing can be invoked independently of
the bridge driver availability. The subdevice driver then has to verify whether
all the requirements for a successful probing are satisfied. This can include a
@@ -190,64 +197,94 @@ performed using the :c:func:`v4l2_async_unregister_subdev` call. Subdevices
registered this way are stored in a global list of subdevices, ready to be
picked up by bridge drivers.
-Bridge drivers in turn have to register a notifier object. This is
-performed using the :c:func:`v4l2_async_nf_register` call. To
-unregister the notifier the driver has to call
-:c:func:`v4l2_async_nf_unregister`. The former of the two functions
-takes two arguments: a pointer to struct :c:type:`v4l2_device` and a
-pointer to struct :c:type:`v4l2_async_notifier`.
+Drivers must complete all initialization of the sub-device before
+registering it using :c:func:`v4l2_async_register_subdev`, including
+enabling runtime PM. This is because the sub-device becomes accessible
+as soon as it gets registered.
+
+Asynchronous sub-device notifiers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Bridge drivers in turn have to register a notifier object. This is performed
+using the :c:func:`v4l2_async_nf_register` call. To unregister the notifier the
+driver has to call :c:func:`v4l2_async_nf_unregister`. Before releasing memory
+of an unregister notifier, it must be cleaned up by calling
+:c:func:`v4l2_async_nf_cleanup`.
Before registering the notifier, bridge drivers must do two things: first, the
-notifier must be initialized using the :c:func:`v4l2_async_nf_init`.
-Second, bridge drivers can then begin to form a list of subdevice descriptors
-that the bridge device needs for its operation. Several functions are available
-to add subdevice descriptors to a notifier, depending on the type of device and
-the needs of the driver.
-
-:c:func:`v4l2_async_nf_add_fwnode_remote` and
-:c:func:`v4l2_async_nf_add_i2c` are for bridge and ISP drivers for
-registering their async sub-devices with the notifier.
-
-:c:func:`v4l2_async_register_subdev_sensor` is a helper function for
-sensor drivers registering their own async sub-device, but it also registers a
-notifier and further registers async sub-devices for lens and flash devices
-found in firmware. The notifier for the sub-device is unregistered with the
-async sub-device.
-
-These functions allocate an async sub-device descriptor which is of type struct
-:c:type:`v4l2_async_subdev` embedded in a driver-specific struct. The &struct
-:c:type:`v4l2_async_subdev` shall be the first member of this struct:
+notifier must be initialized using the :c:func:`v4l2_async_nf_init`. Second,
+bridge drivers can then begin to form a list of async connection descriptors
+that the bridge device needs for its
+operation. :c:func:`v4l2_async_nf_add_fwnode`,
+:c:func:`v4l2_async_nf_add_fwnode_remote` and :c:func:`v4l2_async_nf_add_i2c`
+
+Async connection descriptors describe connections to external sub-devices the
+drivers for which are not yet probed. Based on an async connection, a media data
+or ancillary link may be created when the related sub-device becomes
+available. There may be one or more async connections to a given sub-device but
+this is not known at the time of adding the connections to the notifier. Async
+connections are bound as matching async sub-devices are found, one by one.
+
+Asynchronous sub-device notifier for sub-devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A driver that registers an asynchronous sub-device may also register an
+asynchronous notifier. This is called an asynchronous sub-device notifier and the
+process is similar to that of a bridge driver apart from that the notifier is
+initialised using :c:func:`v4l2_async_subdev_nf_init` instead. A sub-device
+notifier may complete only after the V4L2 device becomes available, i.e. there's
+a path via async sub-devices and notifiers to a notifier that is not an
+asynchronous sub-device notifier.
+
+Asynchronous sub-device registration helper for camera sensor drivers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:c:func:`v4l2_async_register_subdev_sensor` is a helper function for sensor
+drivers registering their own async connection, but it also registers a notifier
+and further registers async connections for lens and flash devices found in
+firmware. The notifier for the sub-device is unregistered and cleaned up with
+the async sub-device, using :c:func:`v4l2_async_unregister_subdev`.
+
+Asynchronous sub-device notifier example
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These functions allocate an async connection descriptor which is of type struct
+:c:type:`v4l2_async_connection` embedded in a driver-specific struct. The &struct
+:c:type:`v4l2_async_connection` shall be the first member of this struct:
.. code-block:: c
- struct my_async_subdev {
- struct v4l2_async_subdev asd;
+ struct my_async_connection {
+ struct v4l2_async_connection asc;
...
};
- struct my_async_subdev *my_asd;
+ struct my_async_connection *my_asc;
struct fwnode_handle *ep;
...
- my_asd = v4l2_async_nf_add_fwnode_remote(&notifier, ep,
- struct my_async_subdev);
+ my_asc = v4l2_async_nf_add_fwnode_remote(&notifier, ep,
+ struct my_async_connection);
fwnode_handle_put(ep);
- if (IS_ERR(asd))
- return PTR_ERR(asd);
+ if (IS_ERR(my_asc))
+ return PTR_ERR(my_asc);
+
+Asynchronous sub-device notifier callbacks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The V4L2 core will then use these descriptors to match asynchronously
-registered subdevices to them. If a match is detected the ``.bound()``
-notifier callback is called. After all subdevices have been located the
-.complete() callback is called. When a subdevice is removed from the
-system the .unbind() method is called. All three callbacks are optional.
+The V4L2 core will then use these connection descriptors to match asynchronously
+registered subdevices to them. If a match is detected the ``.bound()`` notifier
+callback is called. After all connections have been bound the .complete()
+callback is called. When a connection is removed from the system the
+``.unbind()`` method is called. All three callbacks are optional.
Drivers can store any type of custom data in their driver-specific
-:c:type:`v4l2_async_subdev` wrapper. If any of that data requires special
+:c:type:`v4l2_async_connection` wrapper. If any of that data requires special
handling when the structure is freed, drivers must implement the ``.destroy()``
notifier callback. The framework will call it right before freeing the
-:c:type:`v4l2_async_subdev`.
+:c:type:`v4l2_async_connection`.
Calling subdev operations
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -321,7 +358,7 @@ response to video node operations. This hides the complexity of the underlying
hardware from applications. For complex devices, finer-grained control of the
device than what the video nodes offer may be required. In those cases, bridge
drivers that implement :ref:`the media controller API <media_controller>` may
-opt for making the subdevice operations directly accessible from userpace.
+opt for making the subdevice operations directly accessible from userspace.
Device nodes named ``v4l-subdev``\ *X* can be created in ``/dev`` to access
sub-devices directly. If a sub-device supports direct userspace configuration
@@ -532,8 +569,8 @@ device configuration. This is often implemented as e.g. an array of struct
v4l2_mbus_framefmt, one entry for each pad, and similarly for crop and compose
rectangles.
-In addition to the active configuration, each subdev file handle has an array of
-struct v4l2_subdev_pad_config, managed by the V4L2 core, which contains the try
+In addition to the active configuration, each subdev file handle has a struct
+v4l2_subdev_state, managed by the V4L2 core, which contains the try
configuration.
To simplify the subdev drivers the V4L2 subdev API now optionally supports a
@@ -574,7 +611,7 @@ issues with subdevice drivers that let the V4L2 core manage the active state,
as they expect to receive the appropriate state as a parameter. To help the
conversion of subdevice drivers to a managed active state without having to
convert all callers at the same time, an additional wrapper layer has been
-added to v4l2_subdev_call(), which handles the NULL case by geting and locking
+added to v4l2_subdev_call(), which handles the NULL case by getting and locking
the callee's active state with :c:func:`v4l2_subdev_lock_and_get_active_state()`,
and unlocking the state after the call.
@@ -593,6 +630,14 @@ before calling v4l2_subdev_init_finalize():
This shares the driver's private mutex between the controls and the states.
+Streams, multiplexed media pads and internal routing
+----------------------------------------------------
+
+A subdevice driver can implement support for multiplexed streams by setting
+the V4L2_SUBDEV_FL_STREAMS subdev flag and implementing support for
+centrally managed subdev active state, routing and stream based
+configuration.
+
V4L2 sub-device functions and data structures
---------------------------------------------
diff --git a/Documentation/driver-api/media/v4l2-videobuf.rst b/Documentation/driver-api/media/v4l2-videobuf.rst
deleted file mode 100644
index 4b1d84eefeb8..000000000000
--- a/Documentation/driver-api/media/v4l2-videobuf.rst
+++ /dev/null
@@ -1,403 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. _vb_framework:
-
-Videobuf Framework
-==================
-
-Author: Jonathan Corbet <corbet@lwn.net>
-
-Current as of 2.6.33
-
-.. note::
-
- The videobuf framework was deprecated in favor of videobuf2. Shouldn't
- be used on new drivers.
-
-Introduction
-------------
-
-The videobuf layer functions as a sort of glue layer between a V4L2 driver
-and user space. It handles the allocation and management of buffers for
-the storage of video frames. There is a set of functions which can be used
-to implement many of the standard POSIX I/O system calls, including read(),
-poll(), and, happily, mmap(). Another set of functions can be used to
-implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
-including buffer allocation, queueing and dequeueing, and streaming
-control. Using videobuf imposes a few design decisions on the driver
-author, but the payback comes in the form of reduced code in the driver and
-a consistent implementation of the V4L2 user-space API.
-
-Buffer types
-------------
-
-Not all video devices use the same kind of buffers. In fact, there are (at
-least) three common variations:
-
- - Buffers which are scattered in both the physical and (kernel) virtual
- address spaces. (Almost) all user-space buffers are like this, but it
- makes great sense to allocate kernel-space buffers this way as well when
- it is possible. Unfortunately, it is not always possible; working with
- this kind of buffer normally requires hardware which can do
- scatter/gather DMA operations.
-
- - Buffers which are physically scattered, but which are virtually
- contiguous; buffers allocated with vmalloc(), in other words. These
- buffers are just as hard to use for DMA operations, but they can be
- useful in situations where DMA is not available but virtually-contiguous
- buffers are convenient.
-
- - Buffers which are physically contiguous. Allocation of this kind of
- buffer can be unreliable on fragmented systems, but simpler DMA
- controllers cannot deal with anything else.
-
-Videobuf can work with all three types of buffers, but the driver author
-must pick one at the outset and design the driver around that decision.
-
-[It's worth noting that there's a fourth kind of buffer: "overlay" buffers
-which are located within the system's video memory. The overlay
-functionality is considered to be deprecated for most use, but it still
-shows up occasionally in system-on-chip drivers where the performance
-benefits merit the use of this technique. Overlay buffers can be handled
-as a form of scattered buffer, but there are very few implementations in
-the kernel and a description of this technique is currently beyond the
-scope of this document.]
-
-Data structures, callbacks, and initialization
-----------------------------------------------
-
-Depending on which type of buffers are being used, the driver should
-include one of the following files:
-
-.. code-block:: none
-
- <media/videobuf-dma-sg.h> /* Physically scattered */
- <media/videobuf-vmalloc.h> /* vmalloc() buffers */
- <media/videobuf-dma-contig.h> /* Physically contiguous */
-
-The driver's data structure describing a V4L2 device should include a
-struct videobuf_queue instance for the management of the buffer queue,
-along with a list_head for the queue of available buffers. There will also
-need to be an interrupt-safe spinlock which is used to protect (at least)
-the queue.
-
-The next step is to write four simple callbacks to help videobuf deal with
-the management of buffers:
-
-.. code-block:: none
-
- struct videobuf_queue_ops {
- int (*buf_setup)(struct videobuf_queue *q,
- unsigned int *count, unsigned int *size);
- int (*buf_prepare)(struct videobuf_queue *q,
- struct videobuf_buffer *vb,
- enum v4l2_field field);
- void (*buf_queue)(struct videobuf_queue *q,
- struct videobuf_buffer *vb);
- void (*buf_release)(struct videobuf_queue *q,
- struct videobuf_buffer *vb);
- };
-
-buf_setup() is called early in the I/O process, when streaming is being
-initiated; its purpose is to tell videobuf about the I/O stream. The count
-parameter will be a suggested number of buffers to use; the driver should
-check it for rationality and adjust it if need be. As a practical rule, a
-minimum of two buffers are needed for proper streaming, and there is
-usually a maximum (which cannot exceed 32) which makes sense for each
-device. The size parameter should be set to the expected (maximum) size
-for each frame of data.
-
-Each buffer (in the form of a struct videobuf_buffer pointer) will be
-passed to buf_prepare(), which should set the buffer's size, width, height,
-and field fields properly. If the buffer's state field is
-VIDEOBUF_NEEDS_INIT, the driver should pass it to:
-
-.. code-block:: none
-
- int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb,
- struct v4l2_framebuffer *fbuf);
-
-Among other things, this call will usually allocate memory for the buffer.
-Finally, the buf_prepare() function should set the buffer's state to
-VIDEOBUF_PREPARED.
-
-When a buffer is queued for I/O, it is passed to buf_queue(), which should
-put it onto the driver's list of available buffers and set its state to
-VIDEOBUF_QUEUED. Note that this function is called with the queue spinlock
-held; if it tries to acquire it as well things will come to a screeching
-halt. Yes, this is the voice of experience. Note also that videobuf may
-wait on the first buffer in the queue; placing other buffers in front of it
-could again gum up the works. So use list_add_tail() to enqueue buffers.
-
-Finally, buf_release() is called when a buffer is no longer intended to be
-used. The driver should ensure that there is no I/O active on the buffer,
-then pass it to the appropriate free routine(s):
-
-.. code-block:: none
-
- /* Scatter/gather drivers */
- int videobuf_dma_unmap(struct videobuf_queue *q,
- struct videobuf_dmabuf *dma);
- int videobuf_dma_free(struct videobuf_dmabuf *dma);
-
- /* vmalloc drivers */
- void videobuf_vmalloc_free (struct videobuf_buffer *buf);
-
- /* Contiguous drivers */
- void videobuf_dma_contig_free(struct videobuf_queue *q,
- struct videobuf_buffer *buf);
-
-One way to ensure that a buffer is no longer under I/O is to pass it to:
-
-.. code-block:: none
-
- int videobuf_waiton(struct videobuf_buffer *vb, int non_blocking, int intr);
-
-Here, vb is the buffer, non_blocking indicates whether non-blocking I/O
-should be used (it should be zero in the buf_release() case), and intr
-controls whether an interruptible wait is used.
-
-File operations
----------------
-
-At this point, much of the work is done; much of the rest is slipping
-videobuf calls into the implementation of the other driver callbacks. The
-first step is in the open() function, which must initialize the
-videobuf queue. The function to use depends on the type of buffer used:
-
-.. code-block:: none
-
- void videobuf_queue_sg_init(struct videobuf_queue *q,
- struct videobuf_queue_ops *ops,
- struct device *dev,
- spinlock_t *irqlock,
- enum v4l2_buf_type type,
- enum v4l2_field field,
- unsigned int msize,
- void *priv);
-
- void videobuf_queue_vmalloc_init(struct videobuf_queue *q,
- struct videobuf_queue_ops *ops,
- struct device *dev,
- spinlock_t *irqlock,
- enum v4l2_buf_type type,
- enum v4l2_field field,
- unsigned int msize,
- void *priv);
-
- void videobuf_queue_dma_contig_init(struct videobuf_queue *q,
- struct videobuf_queue_ops *ops,
- struct device *dev,
- spinlock_t *irqlock,
- enum v4l2_buf_type type,
- enum v4l2_field field,
- unsigned int msize,
- void *priv);
-
-In each case, the parameters are the same: q is the queue structure for the
-device, ops is the set of callbacks as described above, dev is the device
-structure for this video device, irqlock is an interrupt-safe spinlock to
-protect access to the data structures, type is the buffer type used by the
-device (cameras will use V4L2_BUF_TYPE_VIDEO_CAPTURE, for example), field
-describes which field is being captured (often V4L2_FIELD_NONE for
-progressive devices), msize is the size of any containing structure used
-around struct videobuf_buffer, and priv is a private data pointer which
-shows up in the priv_data field of struct videobuf_queue. Note that these
-are void functions which, evidently, are immune to failure.
-
-V4L2 capture drivers can be written to support either of two APIs: the
-read() system call and the rather more complicated streaming mechanism. As
-a general rule, it is necessary to support both to ensure that all
-applications have a chance of working with the device. Videobuf makes it
-easy to do that with the same code. To implement read(), the driver need
-only make a call to one of:
-
-.. code-block:: none
-
- ssize_t videobuf_read_one(struct videobuf_queue *q,
- char __user *data, size_t count,
- loff_t *ppos, int nonblocking);
-
- ssize_t videobuf_read_stream(struct videobuf_queue *q,
- char __user *data, size_t count,
- loff_t *ppos, int vbihack, int nonblocking);
-
-Either one of these functions will read frame data into data, returning the
-amount actually read; the difference is that videobuf_read_one() will only
-read a single frame, while videobuf_read_stream() will read multiple frames
-if they are needed to satisfy the count requested by the application. A
-typical driver read() implementation will start the capture engine, call
-one of the above functions, then stop the engine before returning (though a
-smarter implementation might leave the engine running for a little while in
-anticipation of another read() call happening in the near future).
-
-The poll() function can usually be implemented with a direct call to:
-
-.. code-block:: none
-
- unsigned int videobuf_poll_stream(struct file *file,
- struct videobuf_queue *q,
- poll_table *wait);
-
-Note that the actual wait queue eventually used will be the one associated
-with the first available buffer.
-
-When streaming I/O is done to kernel-space buffers, the driver must support
-the mmap() system call to enable user space to access the data. In many
-V4L2 drivers, the often-complex mmap() implementation simplifies to a
-single call to:
-
-.. code-block:: none
-
- int videobuf_mmap_mapper(struct videobuf_queue *q,
- struct vm_area_struct *vma);
-
-Everything else is handled by the videobuf code.
-
-The release() function requires two separate videobuf calls:
-
-.. code-block:: none
-
- void videobuf_stop(struct videobuf_queue *q);
- int videobuf_mmap_free(struct videobuf_queue *q);
-
-The call to videobuf_stop() terminates any I/O in progress - though it is
-still up to the driver to stop the capture engine. The call to
-videobuf_mmap_free() will ensure that all buffers have been unmapped; if
-so, they will all be passed to the buf_release() callback. If buffers
-remain mapped, videobuf_mmap_free() returns an error code instead. The
-purpose is clearly to cause the closing of the file descriptor to fail if
-buffers are still mapped, but every driver in the 2.6.32 kernel cheerfully
-ignores its return value.
-
-ioctl() operations
-------------------
-
-The V4L2 API includes a very long list of driver callbacks to respond to
-the many ioctl() commands made available to user space. A number of these
-- those associated with streaming I/O - turn almost directly into videobuf
-calls. The relevant helper functions are:
-
-.. code-block:: none
-
- int videobuf_reqbufs(struct videobuf_queue *q,
- struct v4l2_requestbuffers *req);
- int videobuf_querybuf(struct videobuf_queue *q, struct v4l2_buffer *b);
- int videobuf_qbuf(struct videobuf_queue *q, struct v4l2_buffer *b);
- int videobuf_dqbuf(struct videobuf_queue *q, struct v4l2_buffer *b,
- int nonblocking);
- int videobuf_streamon(struct videobuf_queue *q);
- int videobuf_streamoff(struct videobuf_queue *q);
-
-So, for example, a VIDIOC_REQBUFS call turns into a call to the driver's
-vidioc_reqbufs() callback which, in turn, usually only needs to locate the
-proper struct videobuf_queue pointer and pass it to videobuf_reqbufs().
-These support functions can replace a great deal of buffer management
-boilerplate in a lot of V4L2 drivers.
-
-The vidioc_streamon() and vidioc_streamoff() functions will be a bit more
-complex, of course, since they will also need to deal with starting and
-stopping the capture engine.
-
-Buffer allocation
------------------
-
-Thus far, we have talked about buffers, but have not looked at how they are
-allocated. The scatter/gather case is the most complex on this front. For
-allocation, the driver can leave buffer allocation entirely up to the
-videobuf layer; in this case, buffers will be allocated as anonymous
-user-space pages and will be very scattered indeed. If the application is
-using user-space buffers, no allocation is needed; the videobuf layer will
-take care of calling get_user_pages() and filling in the scatterlist array.
-
-If the driver needs to do its own memory allocation, it should be done in
-the vidioc_reqbufs() function, *after* calling videobuf_reqbufs(). The
-first step is a call to:
-
-.. code-block:: none
-
- struct videobuf_dmabuf *videobuf_to_dma(struct videobuf_buffer *buf);
-
-The returned videobuf_dmabuf structure (defined in
-<media/videobuf-dma-sg.h>) includes a couple of relevant fields:
-
-.. code-block:: none
-
- struct scatterlist *sglist;
- int sglen;
-
-The driver must allocate an appropriately-sized scatterlist array and
-populate it with pointers to the pieces of the allocated buffer; sglen
-should be set to the length of the array.
-
-Drivers using the vmalloc() method need not (and cannot) concern themselves
-with buffer allocation at all; videobuf will handle those details. The
-same is normally true of contiguous-DMA drivers as well; videobuf will
-allocate the buffers (with dma_alloc_coherent()) when it sees fit. That
-means that these drivers may be trying to do high-order allocations at any
-time, an operation which is not always guaranteed to work. Some drivers
-play tricks by allocating DMA space at system boot time; videobuf does not
-currently play well with those drivers.
-
-As of 2.6.31, contiguous-DMA drivers can work with a user-supplied buffer,
-as long as that buffer is physically contiguous. Normal user-space
-allocations will not meet that criterion, but buffers obtained from other
-kernel drivers, or those contained within huge pages, will work with these
-drivers.
-
-Filling the buffers
--------------------
-
-The final part of a videobuf implementation has no direct callback - it's
-the portion of the code which actually puts frame data into the buffers,
-usually in response to interrupts from the device. For all types of
-drivers, this process works approximately as follows:
-
- - Obtain the next available buffer and make sure that somebody is actually
- waiting for it.
-
- - Get a pointer to the memory and put video data there.
-
- - Mark the buffer as done and wake up the process waiting for it.
-
-Step (1) above is done by looking at the driver-managed list_head structure
-- the one which is filled in the buf_queue() callback. Because starting
-the engine and enqueueing buffers are done in separate steps, it's possible
-for the engine to be running without any buffers available - in the
-vmalloc() case especially. So the driver should be prepared for the list
-to be empty. It is equally possible that nobody is yet interested in the
-buffer; the driver should not remove it from the list or fill it until a
-process is waiting on it. That test can be done by examining the buffer's
-done field (a wait_queue_head_t structure) with waitqueue_active().
-
-A buffer's state should be set to VIDEOBUF_ACTIVE before being mapped for
-DMA; that ensures that the videobuf layer will not try to do anything with
-it while the device is transferring data.
-
-For scatter/gather drivers, the needed memory pointers will be found in the
-scatterlist structure described above. Drivers using the vmalloc() method
-can get a memory pointer with:
-
-.. code-block:: none
-
- void *videobuf_to_vmalloc(struct videobuf_buffer *buf);
-
-For contiguous DMA drivers, the function to use is:
-
-.. code-block:: none
-
- dma_addr_t videobuf_to_dma_contig(struct videobuf_buffer *buf);
-
-The contiguous DMA API goes out of its way to hide the kernel-space address
-of the DMA buffer from drivers.
-
-The final step is to set the size field of the relevant videobuf_buffer
-structure to the actual size of the captured image, set state to
-VIDEOBUF_DONE, then call wake_up() on the done queue. At this point, the
-buffer is owned by the videobuf layer and the driver should not touch it
-again.
-
-Developers who are interested in more information can go into the relevant
-header files; there are a few low-level functions declared there which have
-not been talked about here. Note also that all of these calls are exported
-GPL-only, so they will not be available to non-GPL kernel modules.
diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst
index 3a22b522ee78..eae6f18f18cf 100644
--- a/Documentation/driver-api/mei/index.rst
+++ b/Documentation/driver-api/mei/index.rst
@@ -9,13 +9,8 @@ Intel(R) Management Engine Interface (Intel(R) MEI)
**Copyright** |copy| 2019 Intel Corporation
-.. only:: html
-
- .. class:: toc-title
-
- Table of Contents
-
.. toctree::
+ :caption: Table of Contents
:maxdepth: 3
mei
diff --git a/Documentation/driver-api/mei/nfc.rst b/Documentation/driver-api/mei/nfc.rst
index b5b6fc96f85e..8fe8664c28cc 100644
--- a/Documentation/driver-api/mei/nfc.rst
+++ b/Documentation/driver-api/mei/nfc.rst
@@ -3,7 +3,7 @@
MEI NFC
-------
-Some Intel 8 and 9 Serieses chipsets supports NFC devices connected behind
+Some Intel 8 and 9 Series chipsets support NFC devices connected behind
the Intel Management Engine controller.
MEI client bus exposes the NFC chips as NFC phy devices and enables
binding with Microread and NXP PN544 NFC device driver from the Linux NFC
diff --git a/Documentation/driver-api/miscellaneous.rst b/Documentation/driver-api/miscellaneous.rst
index 304ffb146cf9..4a5104a368ac 100644
--- a/Documentation/driver-api/miscellaneous.rst
+++ b/Documentation/driver-api/miscellaneous.rst
@@ -16,12 +16,11 @@ Parallel Port Devices
16x50 UART Driver
=================
-.. kernel-doc:: drivers/tty/serial/serial_core.c
- :export:
-
.. kernel-doc:: drivers/tty/serial/8250/8250_core.c
:export:
+See serial/driver.rst for related APIs.
+
Pulse-Width Modulation (PWM)
============================
diff --git a/Documentation/driver-api/mmc/index.rst b/Documentation/driver-api/mmc/index.rst
index 7339736ac774..8188863e5959 100644
--- a/Documentation/driver-api/mmc/index.rst
+++ b/Documentation/driver-api/mmc/index.rst
@@ -10,4 +10,5 @@ MMC/SD/SDIO card support
mmc-dev-attrs
mmc-dev-parts
mmc-async-req
+ mmc-test
mmc-tools
diff --git a/Documentation/driver-api/mmc/mmc-test.rst b/Documentation/driver-api/mmc/mmc-test.rst
new file mode 100644
index 000000000000..1fe33eb43742
--- /dev/null
+++ b/Documentation/driver-api/mmc/mmc-test.rst
@@ -0,0 +1,299 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+MMC Test Framework
+========================
+
+Overview
+========
+
+The `mmc_test` framework is designed to test the performance and reliability of host controller drivers and all devices handled by the MMC subsystem. This includes not only MMC devices but also SD cards and other devices supported by the subsystem.
+
+The framework provides a variety of tests to evaluate different aspects of the host controller and device interactions, such as read and write performance, data integrity, and error handling. These tests help ensure that the host controller drivers and devices operate correctly under various conditions.
+
+The `mmc_test` framework is particularly useful for:
+
+- Verifying the functionality and performance of MMC and SD host controller drivers.
+- Ensuring compatibility and reliability of MMC and SD devices.
+- Identifying and diagnosing issues in the MMC subsystem.
+
+The results of the tests are logged in the kernel log, providing detailed information about the test outcomes and any encountered issues.
+
+Note: whatever is on your card will be overwritten by these tests.
+
+Initialization
+==============
+
+To use the ``mmc_test`` framework, follow these steps:
+
+1. **Enable the MMC Test Framework**:
+
+ Ensure that the ``CONFIG_MMC_TEST`` kernel configuration option is enabled. This can be done by configuring the kernel:
+
+ .. code-block:: none
+
+ make menuconfig
+
+ Navigate to:
+
+ Device Drivers --->
+ <*> MMC/SD/SDIO card support --->
+ [*] MMC host test driver
+
+ Alternatively, you can enable it directly in the kernel configuration file:
+
+ .. code-block:: none
+
+ echo "CONFIG_MMC_TEST=y" >> .config
+
+ Rebuild and install the kernel if necessary.
+
+2. **Load the MMC Test Module**:
+
+ If the ``mmc_test`` framework is built as a module, you need to load it using ``modprobe``:
+
+ .. code-block:: none
+
+ modprobe mmc_test
+
+Binding the MMC Card for Testing
+================================
+
+To enable MMC testing, you need to unbind the MMC card from the ``mmcblk`` driver and bind it to the ``mmc_test`` driver. This allows the ``mmc_test`` framework to take control of the MMC card for testing purposes.
+
+1. Identify the MMC card:
+
+ .. code-block:: sh
+
+ ls /sys/bus/mmc/devices/
+
+ This will list the MMC devices, such as ``mmc0:0001``.
+
+2. Unbind the MMC card from the ``mmcblk`` driver:
+
+ .. code-block:: sh
+
+ echo 'mmc0:0001' > /sys/bus/mmc/drivers/mmcblk/unbind
+
+3. Bind the MMC card to the ``mmc_test`` driver:
+
+ .. code-block:: sh
+
+ echo 'mmc0:0001' > /sys/bus/mmc/drivers/mmc_test/bind
+
+After binding, you should see a line in the kernel log indicating that the card has been claimed for testing:
+
+.. code-block:: none
+
+ mmc_test mmc0:0001: Card claimed for testing.
+
+
+Usage - Debugfs Entries
+=======================
+
+Once the ``mmc_test`` framework is enabled, you can interact with the following debugfs entries located in ``/sys/kernel/debug/mmc0/mmc0:0001``:
+
+1. **test**:
+
+ This file is used to run specific tests. Write the test number to this file to execute a test.
+
+ .. code-block:: sh
+
+ echo <test_number> > /sys/kernel/debug/mmc0/mmc0:0001/test
+
+ The test result is indicated in the kernel log info. You can view the kernel log using the `dmesg` command or by checking the log file in `/var/log/`.
+
+ .. code-block:: sh
+
+ dmesg | grep mmc0
+
+ Example:
+
+ To run test number 4 (Basic read with data verification):
+
+ .. code-block:: sh
+
+ echo 4 > /sys/kernel/debug/mmc0/mmc0:0001/test
+
+ Check the kernel log for the result:
+
+ .. code-block:: sh
+
+ dmesg | grep mmc0
+
+2. **testlist**:
+
+ This file lists all available tests. You can read this file to see the list of tests and their corresponding numbers.
+
+ .. code-block:: sh
+
+ cat /sys/kernel/debug/mmc0/mmc0:0001/testlist
+
+ The available tests are listed in the table below:
+
++------+--------------------------------+---------------------------------------------+
+| Test | Test Name | Test Description |
++======+================================+=============================================+
+| 0 | Run all tests | Runs all available tests |
++------+--------------------------------+---------------------------------------------+
+| 1 | Basic write | Performs a basic write operation of a |
+| | | single 512-Byte block to the MMC card |
+| | | without data verification. |
++------+--------------------------------+---------------------------------------------+
+| 2 | Basic read | Same for read |
++------+--------------------------------+---------------------------------------------+
+| 3 | Basic write | Performs a basic write operation of a |
+| | (with data verification) | single 512-Byte block to the MMC card |
+| | | with data verification by reading back |
+| | | the written data and comparing it. |
++------+--------------------------------+---------------------------------------------+
+| 4 | Basic read | Same for read |
+| | (with data verification) | |
++------+--------------------------------+---------------------------------------------+
+| 5 | Multi-block write | Performs a multi-block write operation of |
+| | | 8 blocks (each 512 bytes) to the MMC card. |
++------+--------------------------------+---------------------------------------------+
+| 6 | Multi-block read | Same for read |
++------+--------------------------------+---------------------------------------------+
+| 7 | Power of two block writes | Performs write operations with block sizes |
+| | | that are powers of two, starting from 1 |
+| | | byte up to 256 bytes, to the MMC card. |
++------+--------------------------------+---------------------------------------------+
+| 8 | Power of two block reads | Same for read |
++------+--------------------------------+---------------------------------------------+
+| 9 | Weird sized block writes | Performs write operations with varying |
+| | | block sizes starting from 3 bytes and |
+| | | increasing by 7 bytes each iteration, up |
+| | | to 511 bytes, to the MMC card. |
++------+--------------------------------+---------------------------------------------+
+| 10 | Weird sized block reads | same for read |
++------+--------------------------------+---------------------------------------------+
+| 11 | Badly aligned write | Performs write operations with buffers |
+| | | starting at different alignments (0 to 7 |
+| | | bytes offset) to test how the MMC card |
+| | | handles unaligned data transfers. |
++------+--------------------------------+---------------------------------------------+
+| 12 | Badly aligned read | same for read |
++------+--------------------------------+---------------------------------------------+
+| 13 | Badly aligned multi-block write| same for multi-write |
++------+--------------------------------+---------------------------------------------+
+| 14 | Badly aligned multi-block read | same for multi-read |
++------+--------------------------------+---------------------------------------------+
+| 15 | Proper xfer_size at write | intentionally create a broken transfer by |
+| | (Start failure) | modifying the MMC request in a way that it |
+| | | will not perform as expected, e.g. use |
+| | | MMC_WRITE_BLOCK for a multi-block transfer |
++------+--------------------------------+---------------------------------------------+
+| 16 | Proper xfer_size at read | same for read |
+| | (Start failure) | |
++------+--------------------------------+---------------------------------------------+
+| 17 | Proper xfer_size at write | same for 2 blocks |
+| | (Midway failure) | |
++------+--------------------------------+---------------------------------------------+
+| 18 | Proper xfer_size at read | same for read |
+| | (Midway failure) | |
++------+--------------------------------+---------------------------------------------+
+| 19 | Highmem write | use a high memory page |
++------+--------------------------------+---------------------------------------------+
+| 20 | Highmem read | same for read |
++------+--------------------------------+---------------------------------------------+
+| 21 | Multi-block highmem write | same for multi-write |
++------+--------------------------------+---------------------------------------------+
+| 22 | Multi-block highmem read | same for mult-read |
++------+--------------------------------+---------------------------------------------+
+| 23 | Best-case read performance | Performs 512K sequential read (non sg) |
++------+--------------------------------+---------------------------------------------+
+| 24 | Best-case write performance | same for write |
++------+--------------------------------+---------------------------------------------+
+| 25 | Best-case read performance | Same using sg |
+| | (Into scattered pages) | |
++------+--------------------------------+---------------------------------------------+
+| 26 | Best-case write performance | same for write |
+| | (From scattered pages) | |
++------+--------------------------------+---------------------------------------------+
+| 27 | Single read performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 28 | Single write performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 29 | Single trim performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 30 | Consecutive read performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 31 | Consecutive write performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 32 | Consecutive trim performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 33 | Random read performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 34 | Random write performance | By transfer size |
++------+--------------------------------+---------------------------------------------+
+| 35 | Large sequential read | Into scattered pages |
++------+--------------------------------+---------------------------------------------+
+| 36 | Large sequential write | From scattered pages |
++------+--------------------------------+---------------------------------------------+
+| 37 | Write performance | With blocking req 4k to 4MB |
++------+--------------------------------+---------------------------------------------+
+| 38 | Write performance | With non-blocking req 4k to 4MB |
++------+--------------------------------+---------------------------------------------+
+| 39 | Read performance | With blocking req 4k to 4MB |
++------+--------------------------------+---------------------------------------------+
+| 40 | Read performance | With non-blocking req 4k to 4MB |
++------+--------------------------------+---------------------------------------------+
+| 41 | Write performance | Blocking req 1 to 512 sg elems |
++------+--------------------------------+---------------------------------------------+
+| 42 | Write performance | Non-blocking req 1 to 512 sg elems |
++------+--------------------------------+---------------------------------------------+
+| 43 | Read performance | Blocking req 1 to 512 sg elems |
++------+--------------------------------+---------------------------------------------+
+| 44 | Read performance | Non-blocking req 1 to 512 sg elems |
++------+--------------------------------+---------------------------------------------+
+| 45 | Reset test | |
++------+--------------------------------+---------------------------------------------+
+| 46 | Commands during read | No Set Block Count (CMD23) |
++------+--------------------------------+---------------------------------------------+
+| 47 | Commands during write | No Set Block Count (CMD23) |
++------+--------------------------------+---------------------------------------------+
+| 48 | Commands during read | Use Set Block Count (CMD23) |
++------+--------------------------------+---------------------------------------------+
+| 49 | Commands during write | Use Set Block Count (CMD23) |
++------+--------------------------------+---------------------------------------------+
+| 50 | Commands during non-blocking | Read - use Set Block Count (CMD23) |
++------+--------------------------------+---------------------------------------------+
+| 51 | Commands during non-blocking | Write - use Set Block Count (CMD23) |
++------+--------------------------------+---------------------------------------------+
+
+Test Results
+============
+
+The results of the tests are logged in the kernel log. Each test logs the start, end, and result of the test. The possible results are:
+
+- **OK**: The test completed successfully.
+- **FAILED**: The test failed.
+- **UNSUPPORTED (by host)**: The test is unsupported by the host.
+- **UNSUPPORTED (by card)**: The test is unsupported by the card.
+- **ERROR**: An error occurred during the test.
+
+Example Kernel Log Output
+=========================
+
+When running a test, you will see log entries similar to the following in the kernel log:
+
+.. code-block:: none
+
+ [ 1234.567890] mmc0: Starting tests of card mmc0:0001...
+ [ 1234.567891] mmc0: Test case 4. Basic read (with data verification)...
+ [ 1234.567892] mmc0: Result: OK
+ [ 1234.567893] mmc0: Tests completed.
+
+In this example, test case 4 (Basic read with data verification) was executed, and the result was OK.
+
+
+Contributing
+============
+
+Contributions to the `mmc_test` framework are welcome. Please follow the standard Linux kernel contribution guidelines and submit patches to the appropriate maintainers.
+
+Contact
+=======
+
+For more information or to report issues, please contact the MMC subsystem maintainers.
diff --git a/Documentation/driver-api/mtd/nand_ecc.rst b/Documentation/driver-api/mtd/nand_ecc.rst
index 74347c14a70b..a0d681f26a2e 100644
--- a/Documentation/driver-api/mtd/nand_ecc.rst
+++ b/Documentation/driver-api/mtd/nand_ecc.rst
@@ -462,7 +462,7 @@ statements is reduced. This is also reflected in the assembly code.
Analysis 3
==========
-Very weird. Guess it has to do with caching or instruction parallellism
+Very weird. Guess it has to do with caching or instruction parallelism
or so. I also tried on an eeePC (Celeron, clocked at 900 Mhz). Interesting
observation was that this one is only 30% slower (according to time)
executing the code as my 3Ghz D920 processor.
diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
index 4a3adca417fd..148fa4288760 100644
--- a/Documentation/driver-api/mtd/spi-nor.rst
+++ b/Documentation/driver-api/mtd/spi-nor.rst
@@ -2,67 +2,204 @@
SPI NOR framework
=================
-Part I - Why do we need this framework?
----------------------------------------
-
-SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus
-controller operates agnostic of the specific device attached. However, some
-controllers (such as Freescale's QuadSPI controller) cannot easily handle
-arbitrary streams of bytes, but rather are designed specifically for SPI NOR.
-
-In particular, Freescale's QuadSPI controller must know the NOR commands to
-find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of
-opcodes, addresses, or data payloads; a SPI controller simply knows to send or
-receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under
-which the controller driver is aware of the opcodes, addressing, and other
-details of the SPI NOR protocol.
-
-Part II - How does the framework work?
---------------------------------------
-
-This framework just adds a new layer between the MTD and the SPI bus driver.
-With this new layer, the SPI NOR controller driver does not depend on the
-m25p80 code anymore.
-
-Before this framework, the layer is like::
-
- MTD
- ------------------------
- m25p80
- ------------------------
- SPI bus driver
- ------------------------
- SPI NOR chip
-
-After this framework, the layer is like::
-
- MTD
- ------------------------
- SPI NOR framework
- ------------------------
- m25p80
- ------------------------
- SPI bus driver
- ------------------------
- SPI NOR chip
-
-With the SPI NOR controller driver (Freescale QuadSPI), it looks like::
-
- MTD
- ------------------------
- SPI NOR framework
- ------------------------
- fsl-quadSPI
- ------------------------
- SPI NOR chip
-
-Part III - How can drivers use the framework?
----------------------------------------------
-
-The main API is spi_nor_scan(). Before you call the hook, a driver should
-initialize the necessary fields for spi_nor{}. Please see
-drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c
-when you want to write a new driver for a SPI NOR controller.
-Another API is spi_nor_restore(), this is used to restore the status of SPI
-flash chip such as addressing mode. Call it whenever detach the driver from
-device or reboot the system.
+How to propose a new flash addition
+-----------------------------------
+
+Most SPI NOR flashes comply with the JEDEC JESD216
+Serial Flash Discoverable Parameter (SFDP) standard. SFDP describes
+the functional and feature capabilities of serial flash devices in a
+standard set of internal read-only parameter tables.
+
+The SPI NOR driver queries the SFDP tables in order to determine the
+flash's parameters and settings. If the flash defines the SFDP tables
+it's likely that you won't need a flash entry at all, and instead
+rely on the generic flash driver which probes the flash solely based
+on its SFDP data. All one has to do is to specify the "jedec,spi-nor"
+compatible in the device tree.
+
+There are cases however where you need to define an explicit flash
+entry. This typically happens when the flash has settings or support
+that is not covered by the SFDP tables (e.g. Block Protection), or
+when the flash contains mangled SFDP data. If the later, one needs
+to implement the ``spi_nor_fixups`` hooks in order to amend the SFDP
+parameters with the correct values.
+
+Minimum testing requirements
+-----------------------------
+
+Do all the tests from below and paste them in the commit's comments
+section, after the ``---`` marker.
+
+1) Specify the controller that you used to test the flash and specify
+ the frequency at which the flash was operated, e.g.::
+
+ This flash is populated on the X board and was tested at Y
+ frequency using the Z (put compatible) SPI controller.
+
+2) Dump the sysfs entries and print the md5/sha1/sha256 SFDP checksum::
+
+ root@1:~# cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
+ sst26vf064b
+ root@1:~# cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
+ bf2643
+ root@1:~# cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
+ sst
+ root@1:~# xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
+ 53464450060102ff00060110300000ff81000106000100ffbf0001180002
+ 0001fffffffffffffffffffffffffffffffffd20f1ffffffff0344eb086b
+ 083b80bbfeffffffffff00ffffff440b0c200dd80fd810d820914824806f
+ 1d81ed0f773830b030b0f7ffffff29c25cfff030c080ffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffff0004fff37f0000f57f0000f9ff
+ 7d00f57f0000f37f0000ffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ ffffbf2643ffb95ffdff30f260f332ff0a122346ff0f19320f1919ffffff
+ ffffffff00669938ff05013506040232b03072428de89888a585c09faf5a
+ ffff06ec060c0003080bffffffffff07ffff0202ff060300fdfd040700fc
+ 0300fefe0202070e
+ root@1:~# sha256sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
+ 428f34d0461876f189ac97f93e68a05fa6428c6650b3b7baf736a921e5898ed1 /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
+
+ Please dump the SFDP tables using ``xxd -p``. It enables us to do
+ the reverse operation and convert the hexdump to binary with
+ ``xxd -rp``. Dumping the SFDP data with ``hexdump -Cv`` is accepted,
+ but less desirable.
+
+3) Dump debugfs data::
+
+ root@1:~# cat /sys/kernel/debug/spi-nor/spi0.0/capabilities
+ Supported read modes by the flash
+ 1S-1S-1S
+ opcode 0x03
+ mode cycles 0
+ dummy cycles 0
+ 1S-1S-1S (fast read)
+ opcode 0x0b
+ mode cycles 0
+ dummy cycles 8
+ 1S-1S-2S
+ opcode 0x3b
+ mode cycles 0
+ dummy cycles 8
+ 1S-2S-2S
+ opcode 0xbb
+ mode cycles 4
+ dummy cycles 0
+ 1S-1S-4S
+ opcode 0x6b
+ mode cycles 0
+ dummy cycles 8
+ 1S-4S-4S
+ opcode 0xeb
+ mode cycles 2
+ dummy cycles 4
+ 4S-4S-4S
+ opcode 0x0b
+ mode cycles 2
+ dummy cycles 4
+
+ Supported page program modes by the flash
+ 1S-1S-1S
+ opcode 0x02
+
+ root@1:~# cat /sys/kernel/debug/spi-nor/spi0.0/params
+ name sst26vf064b
+ id bf 26 43 bf 26 43
+ size 8.00 MiB
+ write size 1
+ page size 256
+ address nbytes 3
+ flags HAS_LOCK | HAS_16BIT_SR | SOFT_RESET | SWP_IS_VOLATILE
+
+ opcodes
+ read 0xeb
+ dummy cycles 6
+ erase 0x20
+ program 0x02
+ 8D extension none
+
+ protocols
+ read 1S-4S-4S
+ write 1S-1S-1S
+ register 1S-1S-1S
+
+ erase commands
+ 20 (4.00 KiB) [0]
+ d8 (8.00 KiB) [1]
+ d8 (32.0 KiB) [2]
+ d8 (64.0 KiB) [3]
+ c7 (8.00 MiB)
+
+ sector map
+ region (in hex) | erase mask | flags
+ ------------------+------------+----------
+ 00000000-00007fff | [01 ] |
+ 00008000-0000ffff | [0 2 ] |
+ 00010000-007effff | [0 3] |
+ 007f0000-007f7fff | [0 2 ] |
+ 007f8000-007fffff | [01 ] |
+
+4) Use `mtd-utils <https://git.infradead.org/mtd-utils.git>`__
+ and verify that erase, read and page program operations work fine::
+
+ root@1:~# dd if=/dev/urandom of=./spi_test bs=1M count=2
+ 2+0 records in
+ 2+0 records out
+ 2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.848566 s, 2.5 MB/s
+
+ root@1:~# mtd_debug erase /dev/mtd0 0 2097152
+ Erased 2097152 bytes from address 0x00000000 in flash
+
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+
+ root@1:~# hexdump spi_read
+ 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
+ *
+ 0200000
+
+ root@1:~# sha256sum spi_read
+ 4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5 spi_read
+
+ root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test
+ Copied 2097152 bytes from spi_test to address 0x00000000 in flash
+
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+
+ If the flash comes erased by default and the previous erase was ignored,
+ we won't catch it, thus test the erase again::
+
+ root@1:~# mtd_debug erase /dev/mtd0 0 2097152
+ Erased 2097152 bytes from address 0x00000000 in flash
+
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+
+ root@1:~# sha256sum spi*
+ 4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+
+ Dump some other relevant data::
+
+ root@1:~# mtd_debug info /dev/mtd0
+ mtd.type = MTD_NORFLASH
+ mtd.flags = MTD_CAP_NORFLASH
+ mtd.size = 8388608 (8M)
+ mtd.erasesize = 4096 (4K)
+ mtd.writesize = 1
+ mtd.oobsize = 0
+ regions = 0
diff --git a/Documentation/driver-api/nfc/nfc-hci.rst b/Documentation/driver-api/nfc/nfc-hci.rst
index f10fe53aa9fe..486aa647c456 100644
--- a/Documentation/driver-api/nfc/nfc-hci.rst
+++ b/Documentation/driver-api/nfc/nfc-hci.rst
@@ -150,7 +150,7 @@ LLC
Communication between the CPU and the chip often requires some link layer
protocol. Those are isolated as modules managed by the HCI layer. There are
-currently two modules : nop (raw transfert) and shdlc.
+currently two modules : nop (raw transfer) and shdlc.
A new llc must implement the following functions::
struct nfc_llc_ops {
diff --git a/Documentation/driver-api/ntb.rst b/Documentation/driver-api/ntb.rst
index 11577c2105c5..a49c41383779 100644
--- a/Documentation/driver-api/ntb.rst
+++ b/Documentation/driver-api/ntb.rst
@@ -35,7 +35,7 @@ anyone who has written a pci driver.
NTB Typical client driver implementation
----------------------------------------
-Primary purpose of NTB is to share some peace of memory between at least two
+Primary purpose of NTB is to share some piece of memory between at least two
systems. So the NTB device features like Scratchpad/Message registers are
mainly used to perform the proper memory window initialization. Typically
there are two types of memory window interfaces supported by the NTB API:
@@ -207,9 +207,9 @@ The MSI test client serves to test and debug the MSI library which
allows for passing MSI interrupts across NTB memory windows. The
test client is interacted with through the debugfs filesystem:
-* *debugfs*/ntb\_tool/*hw*/
+* *debugfs*/ntb\_msi\_test/*hw*/
A directory in debugfs will be created for each
- NTB device probed by the tool. This directory is shortened to *hw*
+ NTB device probed by the msi test. This directory is shortened to *hw*
below.
* *hw*/port
This file describes the local port number
diff --git a/Documentation/driver-api/nvdimm/btt.rst b/Documentation/driver-api/nvdimm/btt.rst
index 107395c042ae..2d8269f834bd 100644
--- a/Documentation/driver-api/nvdimm/btt.rst
+++ b/Documentation/driver-api/nvdimm/btt.rst
@@ -83,7 +83,7 @@ flags, and the remaining form the internal block number.
======== =============================================================
Bit Description
======== =============================================================
-31 - 30 Error and Zero flags - Used in the following way::
+31 - 30 Error and Zero flags - Used in the following way:
== == ====================================================
31 30 Description
diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst
index be8587a558e1..959ba1cc0263 100644
--- a/Documentation/driver-api/nvdimm/nvdimm.rst
+++ b/Documentation/driver-api/nvdimm/nvdimm.rst
@@ -82,7 +82,7 @@ LABEL:
Metadata stored on a DIMM device that partitions and identifies
(persistently names) capacity allocated to different PMEM namespaces. It
also indicates whether an address abstraction like a BTT is applied to
- the namepsace. Note that traditional partition tables, GPT/MBR, are
+ the namespace. Note that traditional partition tables, GPT/MBR, are
layered on top of a PMEM namespace, or an address abstraction like BTT
if present, but partition support is deprecated going forward.
@@ -230,7 +230,7 @@ LIBNVDIMM/LIBNDCTL: Bus
A bus has a 1:1 relationship with an NFIT. The current expectation for
ACPI based systems is that there is only ever one platform-global NFIT.
That said, it is trivial to register multiple NFITs, the specification
-does not preclude it. The infrastructure supports multiple busses and
+does not preclude it. The infrastructure supports multiple buses and
we use this capability to test multiple NFIT configurations in the unit
test.
@@ -535,12 +535,12 @@ internally with a static identifier::
char devname[50];
snprintf(devname, sizeof(devname), "namespace%d.%d",
- ndctl_region_get_id(region), paramaters->id);
+ ndctl_region_get_id(region), parameters->id);
ndctl_namespace_set_alt_name(ndns, devname);
/* 'uuid' must be set prior to setting size! */
- ndctl_namespace_set_uuid(ndns, paramaters->uuid);
- ndctl_namespace_set_size(ndns, paramaters->size);
+ ndctl_namespace_set_uuid(ndns, parameters->uuid);
+ ndctl_namespace_set_size(ndns, parameters->size);
/* unlike pmem namespaces, blk namespaces have a sector size */
if (parameters->lbasize)
ndctl_namespace_set_sector_size(ndns, parameters->lbasize);
diff --git a/Documentation/driver-api/nvdimm/security.rst b/Documentation/driver-api/nvdimm/security.rst
index 7aab71524116..eb3d35e6a95c 100644
--- a/Documentation/driver-api/nvdimm/security.rst
+++ b/Documentation/driver-api/nvdimm/security.rst
@@ -83,7 +83,7 @@ passed in.
6. Freeze
---------
The freeze operation does not require any keys. The security config can be
-frozen by a user with root privelege.
+frozen by a user with root privilege.
7. Disable
----------
diff --git a/Documentation/driver-api/nvmem.rst b/Documentation/driver-api/nvmem.rst
index e3366322d46c..790e2dc652c0 100644
--- a/Documentation/driver-api/nvmem.rst
+++ b/Documentation/driver-api/nvmem.rst
@@ -41,7 +41,7 @@ A NVMEM provider can register with NVMEM core by supplying relevant
nvmem configuration to nvmem_register(), on success core would return a valid
nvmem_device pointer.
-nvmem_unregister(nvmem) is used to unregister a previously registered provider.
+nvmem_unregister() is used to unregister a previously registered provider.
For example, a simple nvram case::
@@ -59,10 +59,10 @@ For example, a simple nvram case::
devm_nvmem_register(&config);
}
-Users of board files can define and register nvmem cells using the
-nvmem_cell_table struct::
+Device drivers can define and register an nvmem cell using the nvmem_cell_info
+struct::
- static struct nvmem_cell_info foo_nvmem_cells[] = {
+ static const struct nvmem_cell_info foo_nvmem_cell = {
{
.name = "macaddr",
.offset = 0x7f00,
@@ -70,13 +70,7 @@ nvmem_cell_table struct::
}
};
- static struct nvmem_cell_table foo_nvmem_cell_table = {
- .nvmem_name = "i2c-eeprom",
- .cells = foo_nvmem_cells,
- .ncells = ARRAY_SIZE(foo_nvmem_cells),
- };
-
- nvmem_add_cell_table(&foo_nvmem_cell_table);
+ int nvmem_add_one_cell(nvmem, &foo_nvmem_cell);
Additionally it is possible to create nvmem cell lookup entries and register
them with the nvmem framework from machine code as shown in the example below::
@@ -185,3 +179,24 @@ ex::
=====================
See Documentation/devicetree/bindings/nvmem/nvmem.txt
+
+8. NVMEM layouts
+================
+
+NVMEM layouts are yet another mechanism to create cells. With the device
+tree binding it is possible to specify simple cells by using an offset
+and a length. Sometimes, the cells doesn't have a static offset, but
+the content is still well defined, e.g. tag-length-values. In this case,
+the NVMEM device content has to be first parsed and the cells need to
+be added accordingly. Layouts let you read the content of the NVMEM device
+and let you add cells dynamically.
+
+Another use case for layouts is the post processing of cells. With layouts,
+it is possible to associate a custom post processing hook to a cell. It
+even possible to add this hook to cells not created by the layout itself.
+
+9. Internal kernel API
+======================
+
+.. kernel-doc:: drivers/nvmem/core.c
+ :export:
diff --git a/Documentation/driver-api/parport-lowlevel.rst b/Documentation/driver-api/parport-lowlevel.rst
index 0633d70ffda7..a907e279f509 100644
--- a/Documentation/driver-api/parport-lowlevel.rst
+++ b/Documentation/driver-api/parport-lowlevel.rst
@@ -7,6 +7,7 @@ PARPORT interface documentation
Described here are the following functions:
Global functions::
+
parport_register_driver
parport_unregister_driver
parport_enumerate
@@ -34,6 +35,7 @@ Global functions::
Port functions (can be overridden by low-level drivers):
SPP::
+
port->ops->read_data
port->ops->write_data
port->ops->read_status
@@ -46,17 +48,20 @@ Port functions (can be overridden by low-level drivers):
port->ops->data_reverse
EPP::
+
port->ops->epp_write_data
port->ops->epp_read_data
port->ops->epp_write_addr
port->ops->epp_read_addr
ECP::
+
port->ops->ecp_write_data
port->ops->ecp_read_data
port->ops->ecp_write_addr
Other::
+
port->ops->nibble_read_data
port->ops->byte_read_data
port->ops->compat_write_data
diff --git a/Documentation/driver-api/pci/index.rst b/Documentation/driver-api/pci/index.rst
index c6cf1fef61ce..9e1b801d0f74 100644
--- a/Documentation/driver-api/pci/index.rst
+++ b/Documentation/driver-api/pci/index.rst
@@ -4,15 +4,13 @@
The Linux PCI driver implementer's API guide
============================================
-.. class:: toc-title
-
- Table of contents
-
.. toctree::
+ :caption: Table of contents
:maxdepth: 2
pci
p2pdma
+ tsm
.. only:: subproject and html
diff --git a/Documentation/driver-api/pci/p2pdma.rst b/Documentation/driver-api/pci/p2pdma.rst
index 44deb52beeb4..280673b50350 100644
--- a/Documentation/driver-api/pci/p2pdma.rst
+++ b/Documentation/driver-api/pci/p2pdma.rst
@@ -9,22 +9,48 @@ between two devices on the bus. This type of transaction is henceforth
called Peer-to-Peer (or P2P). However, there are a number of issues that
make P2P transactions tricky to do in a perfectly safe way.
-One of the biggest issues is that PCI doesn't require forwarding
-transactions between hierarchy domains, and in PCIe, each Root Port
-defines a separate hierarchy domain. To make things worse, there is no
-simple way to determine if a given Root Complex supports this or not.
-(See PCIe r4.0, sec 1.3.1). Therefore, as of this writing, the kernel
-only supports doing P2P when the endpoints involved are all behind the
-same PCI bridge, as such devices are all in the same PCI hierarchy
-domain, and the spec guarantees that all transactions within the
-hierarchy will be routable, but it does not require routing
-between hierarchies.
-
-The second issue is that to make use of existing interfaces in Linux,
-memory that is used for P2P transactions needs to be backed by struct
-pages. However, PCI BARs are not typically cache coherent so there are
-a few corner case gotchas with these pages so developers need to
-be careful about what they do with them.
+For PCIe the routing of Transaction Layer Packets (TLPs) is well-defined up
+until they reach a host bridge or root port. If the path includes PCIe switches
+then based on the ACS settings the transaction can route entirely within
+the PCIe hierarchy and never reach the root port. The kernel will evaluate
+the PCIe topology and always permit P2P in these well-defined cases.
+
+However, if the P2P transaction reaches the host bridge then it might have to
+hairpin back out the same root port, be routed inside the CPU SOC to another
+PCIe root port, or routed internally to the SOC.
+
+The PCIe specification doesn't define the forwarding of transactions between
+hierarchy domains and kernel defaults to blocking such routing. There is an
+allow list to allow detecting known-good HW, in which case P2P between any
+two PCIe devices will be permitted.
+
+Since P2P inherently is doing transactions between two devices it requires two
+drivers to be co-operating inside the kernel. The providing driver has to convey
+its MMIO to the consuming driver. To meet the driver model lifecycle rules the
+MMIO must have all DMA mapping removed, all CPU accesses prevented, all page
+table mappings undone before the providing driver completes remove().
+
+This requires the providing and consuming driver to actively work together to
+guarantee that the consuming driver has stopped using the MMIO during a removal
+cycle. This is done by either a synchronous invalidation shutdown or waiting
+for all usage refcounts to reach zero.
+
+At the lowest level the P2P subsystem offers a naked struct p2p_provider that
+delegates lifecycle management to the providing driver. It is expected that
+drivers using this option will wrap their MMIO memory in DMABUF and use DMABUF
+to provide an invalidation shutdown. These MMIO addresess have no struct page, and
+if used with mmap() must create special PTEs. As such there are very few
+kernel uAPIs that can accept pointers to them; in particular they cannot be used
+with read()/write(), including O_DIRECT.
+
+Building on this, the subsystem offers a layer to wrap the MMIO in a ZONE_DEVICE
+pgmap of MEMORY_DEVICE_PCI_P2PDMA to create struct pages. The lifecycle of
+pgmap ensures that when the pgmap is destroyed all other drivers have stopped
+using the MMIO. This option works with O_DIRECT flows, in some cases, if the
+underlying subsystem supports handling MEMORY_DEVICE_PCI_P2PDMA through
+FOLL_PCI_P2PDMA. The use of FOLL_LONGTERM is prevented. As this relies on pgmap
+it also relies on architecture support along with alignment and minimum size
+limitations.
Driver Writer's Guide
@@ -83,19 +109,9 @@ this to include other types of resources like doorbells.
Client Drivers
--------------
-A client driver typically only has to conditionally change its DMA map
-routine to use the mapping function :c:func:`pci_p2pdma_map_sg()` instead
-of the usual :c:func:`dma_map_sg()` function. Memory mapped in this
-way does not need to be unmapped.
-
-The client may also, optionally, make use of
-:c:func:`is_pci_p2pdma_page()` to determine when to use the P2P mapping
-functions and when to use the regular mapping functions. In some
-situations, it may be more appropriate to use a flag to indicate a
-given request is P2P memory and map appropriately. It is important to
-ensure that struct pages that back P2P memory stay out of code that
-does not have support for them as other code may treat the pages as
-regular memory which may not be appropriate.
+A client driver only has to use the mapping API :c:func:`dma_map_sg()`
+and :c:func:`dma_unmap_sg()` functions as usual, and the implementation
+will do the right thing for the P2P capable memory.
Orchestrator Drivers
@@ -124,14 +140,39 @@ allocating scatter-gather lists with P2P memory.
Struct Page Caveats
-------------------
-Driver writers should be very careful about not passing these special
-struct pages to code that isn't prepared for it. At this time, the kernel
-interfaces do not have any checks for ensuring this. This obviously
-precludes passing these pages to userspace.
+While the MEMORY_DEVICE_PCI_P2PDMA pages can be installed in VMAs,
+pin_user_pages() and related will not return them unless FOLL_PCI_P2PDMA is set.
+
+The MEMORY_DEVICE_PCI_P2PDMA pages require care to support in the kernel. The
+KVA is still MMIO and must still be accessed through the normal
+readX()/writeX()/etc helpers. Direct CPU access (e.g. memcpy) is forbidden, just
+like any other MMIO mapping. While this will actually work on some
+architectures, others will experience corruption or just crash in the kernel.
+Supporting FOLL_PCI_P2PDMA in a subsystem requires scrubbing it to ensure no CPU
+access happens.
+
+
+Usage With DMABUF
+=================
+
+DMABUF provides an alternative to the above struct page-based
+client/provider/orchestrator system and should be used when struct page
+doesn't exist. In this mode the exporting driver will wrap
+some of its MMIO in a DMABUF and give the DMABUF FD to userspace.
+
+Userspace can then pass the FD to an importing driver which will ask the
+exporting driver to map it to the importer.
+
+In this case the initiator and target pci_devices are known and the P2P subsystem
+is used to determine the mapping type. The phys_addr_t-based DMA API is used to
+establish the dma_addr_t.
+
+Lifecycle is controlled by DMABUF move_notify(). When the exporting driver wants
+to remove() it must deliver an invalidation shutdown to all DMABUF importing
+drivers through move_notify() and synchronously DMA unmap all the MMIO.
-P2P memory is also technically IO memory but should never have any side
-effects behind it. Thus, the order of loads and stores should not be important
-and ioreadX(), iowriteX() and friends should not be necessary.
+No importing driver can continue to have a DMA map to the MMIO after the
+exporting driver has destroyed its p2p_provider.
P2P DMA Support Library
diff --git a/Documentation/driver-api/pci/pci.rst b/Documentation/driver-api/pci/pci.rst
index 4843cfad4f60..99a1bbaaec5d 100644
--- a/Documentation/driver-api/pci/pci.rst
+++ b/Documentation/driver-api/pci/pci.rst
@@ -4,6 +4,12 @@ PCI Support Library
.. kernel-doc:: drivers/pci/pci.c
:export:
+.. kernel-doc:: drivers/pci/iomap.c
+ :export:
+
+.. kernel-doc:: drivers/pci/devres.c
+ :export:
+
.. kernel-doc:: drivers/pci/pci-driver.c
:export:
@@ -31,6 +37,9 @@ PCI Support Library
.. kernel-doc:: drivers/pci/slot.c
:export:
+.. kernel-doc:: drivers/pci/rebar.c
+ :export:
+
.. kernel-doc:: drivers/pci/rom.c
:export:
@@ -40,6 +49,9 @@ PCI Support Library
.. kernel-doc:: drivers/pci/pci-sysfs.c
:internal:
+.. kernel-doc:: drivers/pci/tph.c
+ :export:
+
PCI Hotplug Support Library
---------------------------
diff --git a/Documentation/driver-api/pci/tsm.rst b/Documentation/driver-api/pci/tsm.rst
new file mode 100644
index 000000000000..232b92bec93f
--- /dev/null
+++ b/Documentation/driver-api/pci/tsm.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+========================================================
+PCI Trusted Execution Environment Security Manager (TSM)
+========================================================
+
+Subsystem Interfaces
+====================
+
+.. kernel-doc:: include/linux/pci-ide.h
+ :internal:
+
+.. kernel-doc:: drivers/pci/ide.c
+ :export:
+
+.. kernel-doc:: include/linux/pci-tsm.h
+ :internal:
+
+.. kernel-doc:: drivers/pci/tsm.c
+ :export:
diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
index 8fc1ce0bb905..719a2b3fd2ab 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -94,7 +94,8 @@ Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
phy_ops to get back the private data.
-4. Getting a reference to the PHY
+Getting a reference to the PHY
+==============================
Before the controller can make use of the PHY, it has to get a reference to
it. This framework provides the following APIs to get a reference to the PHY.
@@ -102,27 +103,31 @@ it. This framework provides the following APIs to get a reference to the PHY.
::
struct phy *phy_get(struct device *dev, const char *string);
- struct phy *phy_optional_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
struct phy *devm_phy_optional_get(struct device *dev,
const char *string);
+ struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
+ const char *con_id);
+ struct phy *devm_of_phy_optional_get(struct device *dev,
+ struct device_node *np,
+ const char *con_id);
struct phy *devm_of_phy_get_by_index(struct device *dev,
struct device_node *np,
int index);
-phy_get, phy_optional_get, devm_phy_get and devm_phy_optional_get can
-be used to get the PHY. In the case of dt boot, the string arguments
+phy_get, devm_phy_get and devm_phy_optional_get can be used to get the PHY.
+In the case of dt boot, the string arguments
should contain the phy name as given in the dt data and in the case of
non-dt boot, it should contain the label of the PHY. The two
devm_phy_get associates the device with the PHY using devres on
successful PHY get. On driver detach, release function is invoked on
-the devres data and devres data is freed. phy_optional_get and
-devm_phy_optional_get should be used when the phy is optional. These
-two functions will never return -ENODEV, but instead returns NULL when
-the phy cannot be found.Some generic drivers, such as ehci, may use multiple
-phys and for such drivers referencing phy(s) by name(s) does not make sense. In
-this case, devm_of_phy_get_by_index can be used to get a phy reference based on
-the index.
+the devres data and devres data is freed.
+The _optional_get variants should be used when the phy is optional. These
+functions will never return -ENODEV, but instead return NULL when
+the phy cannot be found.
+Some generic drivers, such as ehci, may use multiple phys. In this case,
+devm_of_phy_get or devm_of_phy_get_by_index can be used to get a phy
+reference based on name or index.
It should be noted that NULL is a valid phy reference. All phy
consumer calls on the NULL phy become NOPs. That is the release calls,
@@ -130,6 +135,28 @@ the phy_init() and phy_exit() calls, and phy_power_on() and
phy_power_off() calls are all NOP when applied to a NULL phy. The NULL
phy is useful in devices for handling optional phy devices.
+Order of API calls
+==================
+
+The general order of calls should be::
+
+ [devm_][of_]phy_get()
+ phy_init()
+ phy_power_on()
+ [phy_set_mode[_ext]()]
+ ...
+ phy_power_off()
+ phy_exit()
+ [[of_]phy_put()]
+
+Some PHY drivers may not implement :c:func:`phy_init` or :c:func:`phy_power_on`,
+but controllers should always call these functions to be compatible with other
+PHYs. Some PHYs may require :c:func:`phy_set_mode <phy_set_mode_ext>`, while
+others may use a default mode (typically configured via devicetree or other
+firmware). For compatibility, you should always call this function if you know
+what mode you will be using. Generally, this function should be called after
+:c:func:`phy_power_on`, although some PHY drivers may allow it at any time.
+
Releasing a reference to the PHY
================================
@@ -171,8 +198,7 @@ pm_runtime_get_sync of PHY provider device because of parent-child relationship.
It should also be noted that phy_power_on and phy_power_off performs
phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
-phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
-phy_pm_runtime_forbid for performing PM operations.
+phy_pm_runtime_put and phy_pm_runtime_put_sync for performing PM operations.
PHY Mappings
============
diff --git a/Documentation/driver-api/pin-control.rst b/Documentation/driver-api/pin-control.rst
index 71eefe5a023f..1f585ecca63c 100644
--- a/Documentation/driver-api/pin-control.rst
+++ b/Documentation/driver-api/pin-control.rst
@@ -11,20 +11,18 @@ This subsystem deals with:
- Multiplexing of pins, pads, fingers (etc) see below for details
- Configuration of pins, pads, fingers (etc), such as software-controlled
- biasing and driving mode specific pins, such as pull-up/down, open drain,
+ biasing and driving mode specific pins, such as pull-up, pull-down, open drain,
load capacitance etc.
Top-level interface
===================
-Definition of PIN CONTROLLER:
+Definitions:
-- A pin controller is a piece of hardware, usually a set of registers, that
+- A PIN CONTROLLER is a piece of hardware, usually a set of registers, that
can control PINs. It may be able to multiplex, bias, set load capacitance,
set drive strength, etc. for individual pins or groups of pins.
-Definition of PIN:
-
- PINS are equal to pads, fingers, balls or whatever packaging input or
output line you want to control and these are denoted by unsigned integers
in the range 0..maxpin. This numberspace is local to each PIN CONTROLLER, so
@@ -57,7 +55,9 @@ Here is an example of a PGA (Pin Grid Array) chip seen from underneath::
1 o o o o o o o o
To register a pin controller and name all the pins on this package we can do
-this in our driver::
+this in our driver:
+
+.. code-block:: c
#include <linux/pinctrl/pinctrl.h>
@@ -78,14 +78,13 @@ this in our driver::
.owner = THIS_MODULE,
};
- int __init foo_probe(void)
+ int __init foo_init(void)
{
int error;
struct pinctrl_dev *pctl;
- error = pinctrl_register_and_init(&foo_desc, <PARENT>,
- NULL, &pctl);
+ error = pinctrl_register_and_init(&foo_desc, <PARENT>, NULL, &pctl);
if (error)
return error;
@@ -95,20 +94,20 @@ this in our driver::
To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and
selected drivers, you need to select them from your machine's Kconfig entry,
since these are so tightly integrated with the machines they are used on.
-See for example arch/arm/mach-ux500/Kconfig for an example.
+See ``arch/arm/mach-ux500/Kconfig`` for an example.
Pins usually have fancier names than this. You can find these in the datasheet
for your chip. Notice that the core pinctrl.h file provides a fancy macro
-called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
-the pins from 0 in the upper left corner to 63 in the lower right corner.
+called ``PINCTRL_PIN()`` to create the struct entries. As you can see the pins are
+enumerated from 0 in the upper left corner to 63 in the lower right corner.
This enumeration was arbitrarily chosen, in practice you need to think
through your numbering system so that it matches the layout of registers
and such things in your driver, or the code may become complicated. You must
also consider matching of offsets to the GPIO ranges that may be handled by
the pin controller.
-For a padring with 467 pads, as opposed to actual pins, I used an enumeration
-like this, walking around the edge of the chip, which seems to be industry
+For a padding with 467 pads, as opposed to actual pins, the enumeration will
+be like this, walking around the edge of the chip, which seems to be industry
standard too (all these pads had names, too)::
@@ -132,50 +131,38 @@ on { 0, 8, 16, 24 }, and a group of pins dealing with an I2C interface on pins
on { 24, 25 }.
These two groups are presented to the pin control subsystem by implementing
-some generic pinctrl_ops like this::
+some generic ``pinctrl_ops`` like this:
- #include <linux/pinctrl/pinctrl.h>
+.. code-block:: c
- struct foo_group {
- const char *name;
- const unsigned int *pins;
- const unsigned num_pins;
- };
+ #include <linux/pinctrl/pinctrl.h>
static const unsigned int spi0_pins[] = { 0, 8, 16, 24 };
static const unsigned int i2c0_pins[] = { 24, 25 };
- static const struct foo_group foo_groups[] = {
- {
- .name = "spi0_grp",
- .pins = spi0_pins,
- .num_pins = ARRAY_SIZE(spi0_pins),
- },
- {
- .name = "i2c0_grp",
- .pins = i2c0_pins,
- .num_pins = ARRAY_SIZE(i2c0_pins),
- },
+ static const struct pingroup foo_groups[] = {
+ PINCTRL_PINGROUP("spi0_grp", spi0_pins, ARRAY_SIZE(spi0_pins)),
+ PINCTRL_PINGROUP("i2c0_grp", i2c0_pins, ARRAY_SIZE(i2c0_pins)),
};
-
static int foo_get_groups_count(struct pinctrl_dev *pctldev)
{
return ARRAY_SIZE(foo_groups);
}
static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
- unsigned selector)
+ unsigned int selector)
{
return foo_groups[selector].name;
}
- static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
- const unsigned **pins,
- unsigned *num_pins)
+ static int foo_get_group_pins(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ const unsigned int **pins,
+ unsigned int *npins)
{
- *pins = (unsigned *) foo_groups[selector].pins;
- *num_pins = foo_groups[selector].num_pins;
+ *pins = foo_groups[selector].pins;
+ *npins = foo_groups[selector].npins;
return 0;
}
@@ -185,13 +172,12 @@ some generic pinctrl_ops like this::
.get_group_pins = foo_get_group_pins,
};
-
static struct pinctrl_desc foo_desc = {
- ...
- .pctlops = &foo_pctrl_ops,
+ ...
+ .pctlops = &foo_pctrl_ops,
};
-The pin control subsystem will call the .get_groups_count() function to
+The pin control subsystem will call the ``.get_groups_count()`` function to
determine the total number of legal selectors, then it will call the other functions
to retrieve the name and pins of the group. Maintaining the data structure of
the groups is up to the driver, this is just a simple example - in practice you
@@ -204,59 +190,62 @@ Pin configuration
Pins can sometimes be software-configured in various ways, mostly related
to their electronic properties when used as inputs or outputs. For example you
-may be able to make an output pin high impedance, or "tristate" meaning it is
+may be able to make an output pin high impedance (Hi-Z), or "tristate" meaning it is
effectively disconnected. You may be able to connect an input pin to VDD or GND
using a certain resistor value - pull up and pull down - so that the pin has a
stable value when nothing is driving the rail it is connected to, or when it's
unconnected.
Pin configuration can be programmed by adding configuration entries into the
-mapping table; see section "Board/machine configuration" below.
+mapping table; see section `Board/machine configuration`_ below.
The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP
above, is entirely defined by the pin controller driver.
The pin configuration driver implements callbacks for changing pin
-configuration in the pin controller ops like this::
+configuration in the pin controller ops like this:
+
+.. code-block:: c
- #include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinconf.h>
+ #include <linux/pinctrl/pinctrl.h>
+
#include "platform_x_pindefs.h"
static int foo_pin_config_get(struct pinctrl_dev *pctldev,
- unsigned offset,
- unsigned long *config)
+ unsigned int offset,
+ unsigned long *config)
{
struct my_conftype conf;
- ... Find setting for pin @ offset ...
+ /* ... Find setting for pin @ offset ... */
*config = (unsigned long) conf;
}
static int foo_pin_config_set(struct pinctrl_dev *pctldev,
- unsigned offset,
- unsigned long config)
+ unsigned int offset,
+ unsigned long config)
{
struct my_conftype *conf = (struct my_conftype *) config;
switch (conf) {
case PLATFORM_X_PULL_UP:
...
- }
+ break;
}
}
- static int foo_pin_config_group_get (struct pinctrl_dev *pctldev,
- unsigned selector,
- unsigned long *config)
+ static int foo_pin_config_group_get(struct pinctrl_dev *pctldev,
+ unsigned selector,
+ unsigned long *config)
{
...
}
- static int foo_pin_config_group_set (struct pinctrl_dev *pctldev,
- unsigned selector,
- unsigned long config)
+ static int foo_pin_config_group_set(struct pinctrl_dev *pctldev,
+ unsigned selector,
+ unsigned long config)
{
...
}
@@ -281,8 +270,8 @@ The GPIO drivers may want to perform operations of various types on the same
physical pins that are also registered as pin controller pins.
First and foremost, the two subsystems can be used as completely orthogonal,
-see the section named "pin control requests from drivers" and
-"drivers needing both pin control and GPIOs" below for details. But in some
+see the section named `Pin control requests from drivers`_ and
+`Drivers needing both pin control and GPIOs`_ below for details. But in some
situations a cross-subsystem mapping between pins and GPIOs is needed.
Since the pin controller subsystem has its pinspace local to the pin controller
@@ -291,7 +280,13 @@ controller handles control of a certain GPIO pin. Since a single pin controller
may be muxing several GPIO ranges (typically SoCs that have one set of pins,
but internally several GPIO silicon blocks, each modelled as a struct
gpio_chip) any number of GPIO ranges can be added to a pin controller instance
-like this::
+like this:
+
+.. code-block:: c
+
+ #include <linux/gpio/driver.h>
+
+ #include <linux/pinctrl/pinctrl.h>
struct gpio_chip chip_a;
struct gpio_chip chip_b;
@@ -302,7 +297,7 @@ like this::
.base = 32,
.pin_base = 32,
.npins = 16,
- .gc = &chip_a;
+ .gc = &chip_a,
};
static struct pinctrl_gpio_range gpio_range_b = {
@@ -314,16 +309,18 @@ like this::
.gc = &chip_b;
};
+ int __init foo_init(void)
{
struct pinctrl_dev *pctl;
...
pinctrl_add_gpio_range(pctl, &gpio_range_a);
pinctrl_add_gpio_range(pctl, &gpio_range_b);
+ ...
}
So this complex system has one pin controller handling two different
GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
-"chip b" have different .pin_base, which means a start pin number of the
+"chip b" have different ``pin_base``, which means a start pin number of the
GPIO range.
The GPIO range of "chip a" starts from the GPIO base of 32 and actual
@@ -331,7 +328,7 @@ pin range also starts from 32. However "chip b" has different starting
offset for the GPIO range and pin range. The GPIO range of "chip b" starts
from GPIO number 48, while the pin range of "chip b" starts from 64.
-We can convert a gpio number to actual pin number using this "pin_base".
+We can convert a gpio number to actual pin number using this ``pin_base``.
They are mapped in the global GPIO pin space at:
chip a:
@@ -343,9 +340,11 @@ chip b:
The above examples assume the mapping between the GPIOs and pins is
linear. If the mapping is sparse or haphazard, an array of arbitrary pin
-numbers can be encoded in the range like this::
+numbers can be encoded in the range like this:
+
+.. code-block:: c
- static const unsigned range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
+ static const unsigned int range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
static struct pinctrl_gpio_range gpio_range = {
.name = "chip",
@@ -353,16 +352,17 @@ numbers can be encoded in the range like this::
.base = 32,
.pins = &range_pins,
.npins = ARRAY_SIZE(range_pins),
- .gc = &chip;
+ .gc = &chip,
};
-In this case the pin_base property will be ignored. If the name of a pin
+In this case the ``pin_base`` property will be ignored. If the name of a pin
group is known, the pins and npins elements of the above structure can be
-initialised using the function pinctrl_get_group_pins(), e.g. for pin
-group "foo"::
+initialised using the function ``pinctrl_get_group_pins()``, e.g. for pin
+group "foo":
+
+.. code-block:: c
- pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins,
- &gpio_range.npins);
+ pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins, &gpio_range.npins);
When GPIO-specific functions in the pin control subsystem are called, these
ranges will be used to look up the appropriate pin controller by inspecting
@@ -378,8 +378,8 @@ will get a pin number into its handled number range. Further it is also passed
the range ID value, so that the pin controller knows which range it should
deal with.
-Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see
-section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind
+Calling ``pinctrl_add_gpio_range()`` from pinctrl driver is DEPRECATED. Please see
+section 2.1 of ``Documentation/devicetree/bindings/gpio/gpio.txt`` on how to bind
pinctrl and gpio drivers.
@@ -466,10 +466,10 @@ in your machine configuration. It is inspired by the clk, GPIO and regulator
subsystems, so devices will request their mux setting, but it's also possible
to request a single pin for e.g. GPIO.
-Definitions:
+The conventions are:
- FUNCTIONS can be switched in and out by a driver residing with the pin
- control subsystem in the drivers/pinctrl/* directory of the kernel. The
+ control subsystem in the ``drivers/pinctrl`` directory of the kernel. The
pin control driver knows the possible functions. In the example above you can
identify three pinmux functions, one for spi, one for i2c and one for mmc.
@@ -515,11 +515,13 @@ Definitions:
In the example case we can define that this particular machine shall
use device spi0 with pinmux function fspi0 group gspi0 and i2c0 on function
fi2c0 group gi2c0, on the primary pin controller, we get mappings
- like these::
+ like these:
+
+ .. code-block:: c
{
{"map-spi0", spi0, pinctrl0, fspi0, gspi0},
- {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0}
+ {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0},
}
Every map must be assigned a state name, pin controller, device and
@@ -569,80 +571,51 @@ is possible to perform the requested mux setting, poke the hardware so that
this happens.
Pinmux drivers are required to supply a few callback functions, some are
-optional. Usually the set_mux() function is implemented, writing values into
+optional. Usually the ``.set_mux()`` function is implemented, writing values into
some certain registers to activate a certain mux setting for a certain pin.
-A simple driver for the above example will work by setting bits 0, 1, 2, 3 or 4
+A simple driver for the above example will work by setting bits 0, 1, 2, 3, 4, or 5
into some register named MUX to select a certain function with a certain
-group of pins would work something like this::
+group of pins would work something like this:
+
+.. code-block:: c
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
- struct foo_group {
- const char *name;
- const unsigned int *pins;
- const unsigned num_pins;
- };
-
- static const unsigned spi0_0_pins[] = { 0, 8, 16, 24 };
- static const unsigned spi0_1_pins[] = { 38, 46, 54, 62 };
- static const unsigned i2c0_pins[] = { 24, 25 };
- static const unsigned mmc0_1_pins[] = { 56, 57 };
- static const unsigned mmc0_2_pins[] = { 58, 59 };
- static const unsigned mmc0_3_pins[] = { 60, 61, 62, 63 };
-
- static const struct foo_group foo_groups[] = {
- {
- .name = "spi0_0_grp",
- .pins = spi0_0_pins,
- .num_pins = ARRAY_SIZE(spi0_0_pins),
- },
- {
- .name = "spi0_1_grp",
- .pins = spi0_1_pins,
- .num_pins = ARRAY_SIZE(spi0_1_pins),
- },
- {
- .name = "i2c0_grp",
- .pins = i2c0_pins,
- .num_pins = ARRAY_SIZE(i2c0_pins),
- },
- {
- .name = "mmc0_1_grp",
- .pins = mmc0_1_pins,
- .num_pins = ARRAY_SIZE(mmc0_1_pins),
- },
- {
- .name = "mmc0_2_grp",
- .pins = mmc0_2_pins,
- .num_pins = ARRAY_SIZE(mmc0_2_pins),
- },
- {
- .name = "mmc0_3_grp",
- .pins = mmc0_3_pins,
- .num_pins = ARRAY_SIZE(mmc0_3_pins),
- },
+ static const unsigned int spi0_0_pins[] = { 0, 8, 16, 24 };
+ static const unsigned int spi0_1_pins[] = { 38, 46, 54, 62 };
+ static const unsigned int i2c0_pins[] = { 24, 25 };
+ static const unsigned int mmc0_1_pins[] = { 56, 57 };
+ static const unsigned int mmc0_2_pins[] = { 58, 59 };
+ static const unsigned int mmc0_3_pins[] = { 60, 61, 62, 63 };
+
+ static const struct pingroup foo_groups[] = {
+ PINCTRL_PINGROUP("spi0_0_grp", spi0_0_pins, ARRAY_SIZE(spi0_0_pins)),
+ PINCTRL_PINGROUP("spi0_1_grp", spi0_1_pins, ARRAY_SIZE(spi0_1_pins)),
+ PINCTRL_PINGROUP("i2c0_grp", i2c0_pins, ARRAY_SIZE(i2c0_pins)),
+ PINCTRL_PINGROUP("mmc0_1_grp", mmc0_1_pins, ARRAY_SIZE(mmc0_1_pins)),
+ PINCTRL_PINGROUP("mmc0_2_grp", mmc0_2_pins, ARRAY_SIZE(mmc0_2_pins)),
+ PINCTRL_PINGROUP("mmc0_3_grp", mmc0_3_pins, ARRAY_SIZE(mmc0_3_pins)),
};
-
static int foo_get_groups_count(struct pinctrl_dev *pctldev)
{
return ARRAY_SIZE(foo_groups);
}
static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
- unsigned selector)
+ unsigned int selector)
{
return foo_groups[selector].name;
}
- static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
- const unsigned ** pins,
- unsigned * num_pins)
+ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned int selector,
+ const unsigned int **pins,
+ unsigned int *npins)
{
- *pins = (unsigned *) foo_groups[selector].pins;
- *num_pins = foo_groups[selector].num_pins;
+ *pins = foo_groups[selector].pins;
+ *npins = foo_groups[selector].npins;
return 0;
}
@@ -652,33 +625,14 @@ group of pins would work something like this::
.get_group_pins = foo_get_group_pins,
};
- struct foo_pmx_func {
- const char *name;
- const char * const *groups;
- const unsigned num_groups;
- };
-
static const char * const spi0_groups[] = { "spi0_0_grp", "spi0_1_grp" };
static const char * const i2c0_groups[] = { "i2c0_grp" };
- static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp",
- "mmc0_3_grp" };
+ static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp", "mmc0_3_grp" };
- static const struct foo_pmx_func foo_functions[] = {
- {
- .name = "spi0",
- .groups = spi0_groups,
- .num_groups = ARRAY_SIZE(spi0_groups),
- },
- {
- .name = "i2c0",
- .groups = i2c0_groups,
- .num_groups = ARRAY_SIZE(i2c0_groups),
- },
- {
- .name = "mmc0",
- .groups = mmc0_groups,
- .num_groups = ARRAY_SIZE(mmc0_groups),
- },
+ static const struct pinfunction foo_functions[] = {
+ PINCTRL_PINFUNCTION("spi0", spi0_groups, ARRAY_SIZE(spi0_groups)),
+ PINCTRL_PINFUNCTION("i2c0", i2c0_groups, ARRAY_SIZE(i2c0_groups)),
+ PINCTRL_PINFUNCTION("mmc0", mmc0_groups, ARRAY_SIZE(mmc0_groups)),
};
static int foo_get_functions_count(struct pinctrl_dev *pctldev)
@@ -686,26 +640,26 @@ group of pins would work something like this::
return ARRAY_SIZE(foo_functions);
}
- static const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector)
+ static const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned int selector)
{
return foo_functions[selector].name;
}
- static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
- const char * const **groups,
- unsigned * const num_groups)
+ static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned int selector,
+ const char * const **groups,
+ unsigned int * const ngroups)
{
*groups = foo_functions[selector].groups;
- *num_groups = foo_functions[selector].num_groups;
+ *ngroups = foo_functions[selector].ngroups;
return 0;
}
- static int foo_set_mux(struct pinctrl_dev *pctldev, unsigned selector,
- unsigned group)
+ static int foo_set_mux(struct pinctrl_dev *pctldev, unsigned int selector,
+ unsigned int group)
{
- u8 regbit = (1 << selector + group);
+ u8 regbit = BIT(group);
- writeb((readb(MUX)|regbit), MUX);
+ writeb((readb(MUX) | regbit), MUX);
return 0;
}
@@ -724,16 +678,17 @@ group of pins would work something like this::
.pmxops = &foo_pmxops,
};
-In the example activating muxing 0 and 1 at the same time setting bits
-0 and 1, uses one pin in common so they would collide.
+In the example activating muxing 0 and 2 at the same time setting bits
+0 and 2, uses pin 24 in common so they would collide. All the same for
+the muxes 1 and 5, which have pin 62 in common.
The beauty of the pinmux subsystem is that since it keeps track of all
pins and who is using them, it will already have denied an impossible
request like that, so the driver does not need to worry about such
things - when it gets a selector passed in, the pinmux subsystem makes
sure no other device or GPIO assignment is already using the selected
-pins. Thus bits 0 and 1 in the control register will never be set at the
-same time.
+pins. Thus bits 0 and 2, or 1 and 5 in the control register will never
+be set at the same time.
All the above functions are mandatory to implement for a pinmux driver.
@@ -742,18 +697,18 @@ Pin control interaction with the GPIO subsystem
===============================================
Note that the following implies that the use case is to use a certain pin
-from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
+from the Linux kernel using the API in ``<linux/gpio/consumer.h>`` with gpiod_get()
and similar functions. There are cases where you may be using something
that your datasheet calls "GPIO mode", but actually is just an electrical
configuration for a certain device. See the section below named
-"GPIO mode pitfalls" for more details on this scenario.
+`GPIO mode pitfalls`_ for more details on this scenario.
-The public pinmux API contains two functions named pinctrl_gpio_request()
-and pinctrl_gpio_free(). These two functions shall *ONLY* be called from
-gpiolib-based drivers as part of their gpio_request() and
-gpio_free() semantics. Likewise the pinctrl_gpio_direction_[input|output]
-shall only be called from within respective gpio_direction_[input|output]
-gpiolib implementation.
+The public pinmux API contains two functions named ``pinctrl_gpio_request()``
+and ``pinctrl_gpio_free()``. These two functions shall *ONLY* be called from
+gpiolib-based drivers as part of their ``.request()`` and ``.free()`` semantics.
+Likewise the ``pinctrl_gpio_direction_input()`` / ``pinctrl_gpio_direction_output()``
+shall only be called from within respective ``.direction_input()`` /
+``.direction_output()`` gpiolib implementation.
NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
controlled e.g. muxed in. Instead, implement a proper gpiolib driver and have
@@ -767,8 +722,8 @@ In this case, the function array would become 64 entries for each GPIO
setting and then the device functions.
For this reason there are two functions a pin control driver can implement
-to enable only GPIO on an individual pin: .gpio_request_enable() and
-.gpio_disable_free().
+to enable only GPIO on an individual pin: ``.gpio_request_enable()`` and
+``.gpio_disable_free()``.
This function will pass in the affected GPIO range identified by the pin
controller core, so you know which GPIO pins are being affected by the request
@@ -776,12 +731,12 @@ operation.
If your driver needs to have an indication from the framework of whether the
GPIO pin shall be used for input or output you can implement the
-.gpio_set_direction() function. As described this shall be called from the
+``.gpio_set_direction()`` function. As described this shall be called from the
gpiolib driver and the affected GPIO range, pin offset and desired direction
will be passed along to this function.
Alternatively to using these special functions, it is fully allowed to use
-named functions for each GPIO pin, the pinctrl_gpio_request() will attempt to
+named functions for each GPIO pin, the ``pinctrl_gpio_request()`` will attempt to
obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered.
@@ -794,7 +749,7 @@ is taken to mean different things than what the kernel does, the developer
may be confused by a datasheet talking about a pin being possible to set
into "GPIO mode". It appears that what hardware engineers mean with
"GPIO mode" is not necessarily the use case that is implied in the kernel
-interface <linux/gpio.h>: a pin that you grab from kernel code and then
+interface ``<linux/gpio/consumer.h>``: a pin that you grab from kernel code and then
either listen for input or drive high/low to assert/deassert some
external line.
@@ -805,9 +760,10 @@ for a device.
The GPIO portions of a pin and its relation to a certain pin controller
configuration and muxing logic can be constructed in several ways. Here
-are two examples::
+are two examples.
+
+Example **(A)**::
- (A)
pin config
logic regs
| +- SPI
@@ -836,9 +792,7 @@ simultaneous access to the same pin from GPIO and pin multiplexing
consumers on hardware of this type. The pinctrl driver should set this flag
accordingly.
-::
-
- (B)
+Example **(B)**::
pin config
logic regs
@@ -882,7 +836,7 @@ hardware and shall be put into different subsystems:
Depending on the exact HW register design, some functions exposed by the
GPIO subsystem may call into the pinctrl subsystem in order to
-co-ordinate register settings across HW modules. In particular, this may
+coordinate register settings across HW modules. In particular, this may
be needed for HW with separate GPIO and pin controller HW modules, where
e.g. GPIO direction is determined by a register in the pin controller HW
module rather than the GPIO HW module.
@@ -899,23 +853,25 @@ If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
to think that you need to come up with something really complex, that the
pin shall be used for UART TX and GPIO at the same time, that you will grab
a pin control handle and set it to a certain state to enable UART TX to be
-muxed in, then twist it over to GPIO mode and use gpio_direction_output()
+muxed in, then twist it over to GPIO mode and use gpiod_direction_output()
to drive it low during sleep, then mux it over to UART TX again when you
-wake up and maybe even gpio_request/gpio_free as part of this cycle. This
+wake up and maybe even gpiod_get() / gpiod_put() as part of this cycle. This
all gets very complicated.
The solution is to not think that what the datasheet calls "GPIO mode"
-has to be handled by the <linux/gpio.h> interface. Instead view this as
-a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
+has to be handled by the ``<linux/gpio/consumer.h>`` interface. Instead view this as
+a certain pin config setting. Look in e.g. ``<linux/pinctrl/pinconf-generic.h>``
and you find this in the documentation:
- PIN_CONFIG_OUTPUT:
+ PIN_CONFIG_LEVEL:
this will configure the pin in output, use argument
1 to indicate high level, argument 0 to indicate low level.
So it is perfectly possible to push a pin into "GPIO mode" and drive the
line low as part of the usual pin control map. So for example your UART
-driver may look like this::
+driver may look like this:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
@@ -928,34 +884,35 @@ driver may look like this::
/* Normal mode */
retval = pinctrl_select_state(pinctrl, pins_default);
+
/* Sleep mode */
retval = pinctrl_select_state(pinctrl, pins_sleep);
And your machine configuration may look like this:
---------------------------------------------------
-::
+.. code-block:: c
static unsigned long uart_default_mode[] = {
PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
};
static unsigned long uart_sleep_mode[] = {
- PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
+ PIN_CONF_PACKED(PIN_CONFIG_LEVEL, 0),
};
static struct pinctrl_map pinmap[] __initdata = {
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
- "u0_group", "u0"),
+ "u0_group", "u0"),
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
- "UART_TX_PIN", uart_default_mode),
+ "UART_TX_PIN", uart_default_mode),
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
- "u0_group", "gpio-mode"),
+ "u0_group", "gpio-mode"),
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
- "UART_TX_PIN", uart_sleep_mode),
+ "UART_TX_PIN", uart_sleep_mode),
};
- foo_init(void) {
+ foo_init(void)
+ {
pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
}
@@ -995,7 +952,9 @@ part of this.
A pin controller configuration for a machine looks pretty much like a simple
regulator configuration, so for the example array above we want to enable i2c
-and spi on the second function mapping::
+and spi on the second function mapping:
+
+.. code-block:: c
#include <linux/pinctrl/machine.h>
@@ -1030,23 +989,29 @@ must match a function provided by the pinmux driver handling this pin range.
As you can see we may have several pin controllers on the system and thus
we need to specify which one of them contains the functions we wish to map.
-You register this pinmux mapping to the pinmux subsystem by simply::
+You register this pinmux mapping to the pinmux subsystem by simply:
+
+.. code-block:: c
ret = pinctrl_register_mappings(mapping, ARRAY_SIZE(mapping));
Since the above construct is pretty common there is a helper macro to make
it even more compact which assumes you want to use pinctrl-foo and position
-0 for mapping, for example::
+0 for mapping, for example:
+
+.. code-block:: c
static struct pinctrl_map mapping[] __initdata = {
- PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT,
+ PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT,
"pinctrl-foo", NULL, "i2c0"),
};
The mapping table may also contain pin configuration entries. It's common for
each pin/group to have a number of configuration entries that affect it, so
the table entries for configuration reference an array of config parameters
-and values. An example using the convenience macros is shown below::
+and values. An example using the convenience macros is shown below:
+
+.. code-block:: c
static unsigned long i2c_grp_configs[] = {
FOO_PIN_DRIVEN,
@@ -1073,8 +1038,10 @@ Finally, some devices expect the mapping table to contain certain specific
named states. When running on hardware that doesn't need any pin controller
configuration, the mapping table must still contain those named states, in
order to explicitly indicate that the states were provided and intended to
-be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining
-a named state without causing any pin controller to be programmed::
+be empty. Table entry macro ``PIN_MAP_DUMMY_STATE()`` serves the purpose of defining
+a named state without causing any pin controller to be programmed:
+
+.. code-block:: c
static struct pinctrl_map mapping[] __initdata = {
PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT),
@@ -1085,7 +1052,9 @@ Complex mappings
================
As it is possible to map a function to different groups of pins an optional
-.group can be specified like this::
+.group can be specified like this:
+
+.. code-block:: c
...
{
@@ -1107,13 +1076,15 @@ As it is possible to map a function to different groups of pins an optional
...
This example mapping is used to switch between two positions for spi0 at
-runtime, as described further below under the heading "Runtime pinmuxing".
+runtime, as described further below under the heading `Runtime pinmuxing`_.
Further it is possible for one named state to affect the muxing of several
groups of pins, say for example in the mmc0 example above, where you can
additively expand the mmc0 bus from 2 to 4 to 8 pins. If we want to use all
-three groups for a total of 2+2+4 = 8 pins (for an 8-bit MMC bus as is the
-case), we define a mapping like this::
+three groups for a total of 2 + 2 + 4 = 8 pins (for an 8-bit MMC bus as is the
+case), we define a mapping like this:
+
+.. code-block:: c
...
{
@@ -1167,13 +1138,17 @@ case), we define a mapping like this::
...
The result of grabbing this mapping from the device with something like
-this (see next paragraph)::
+this (see next paragraph):
+
+.. code-block:: c
p = devm_pinctrl_get(dev);
s = pinctrl_lookup_state(p, "8bit");
ret = pinctrl_select_state(p, s);
-or more simply::
+or more simply:
+
+.. code-block:: c
p = devm_pinctrl_get_select(dev, "8bit");
@@ -1187,8 +1162,55 @@ pinmux core.
Pin control requests from drivers
=================================
-When a device driver is about to probe the device core will automatically
-attempt to issue pinctrl_get_select_default() on these devices.
+When a device driver is about to probe, the device core attaches the
+standard states if they are defined in the device tree by calling
+``pinctrl_bind_pins()`` on these devices.
+Possible standard state names are: "default", "init", "sleep" and "idle".
+
+- if ``default`` is defined in the device tree, it is selected before
+ device probe.
+
+- if ``init`` and ``default`` are defined in the device tree, the "init"
+ state is selected before the driver probe and the "default" state is
+ selected after the driver probe.
+
+- the ``sleep`` and ``idle`` states are for power management and can only
+ be selected with the PM API bellow.
+
+PM interfaces
+=================
+PM runtime suspend/resume might need to execute the same init sequence as
+during probe. Since the predefined states are already attached to the
+device, the driver can activate these states explicitly with the
+following helper functions:
+
+- ``pinctrl_pm_select_default_state()``
+- ``pinctrl_pm_select_init_state()``
+- ``pinctrl_pm_select_sleep_state()``
+- ``pinctrl_pm_select_idle_state()``
+
+For example, if resuming the device depend on certain pinmux states
+
+.. code-block:: c
+
+ foo_suspend()
+ {
+ /* suspend device */
+ ...
+
+ pinctrl_pm_select_sleep_state(dev);
+ }
+
+ foo_resume()
+ {
+ pinctrl_pm_select_init_state(dev);
+
+ /* resuming device */
+ ...
+
+ pinctrl_pm_select_default_state(dev);
+ }
+
This way driver writers do not need to add any of the boilerplate code
of the type found below. However when doing fine-grained state selection
and not using the "default" state, you may have to do some device driver
@@ -1206,12 +1228,20 @@ some cases where a driver needs to e.g. switch between different mux mappings
at runtime this is not possible.
A typical case is if a driver needs to switch bias of pins from normal
-operation and going to sleep, moving from the PINCTRL_STATE_DEFAULT to
-PINCTRL_STATE_SLEEP at runtime, re-biasing or even re-muxing pins to save
+operation and going to sleep, moving from the ``PINCTRL_STATE_DEFAULT`` to
+``PINCTRL_STATE_SLEEP`` at runtime, re-biasing or even re-muxing pins to save
current in sleep mode.
+Another case is when the pinctrl needs to switch to a certain mode during
+probe and then revert to the default state at the end of probe. For example
+a PINMUX may need to be configured as a GPIO during probe. In this case, use
+``PINCTRL_STATE_INIT`` to switch state before probe, then move to
+``PINCTRL_STATE_DEFAULT`` at the end of probe for normal operation.
+
A driver may request a certain control state to be activated, usually just the
-default state like this::
+default state like this:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
@@ -1225,22 +1255,24 @@ default state like this::
{
/* Allocate a state holder named "foo" etc */
struct foo_state *foo = ...;
+ int ret;
foo->p = devm_pinctrl_get(&device);
if (IS_ERR(foo->p)) {
- /* FIXME: clean up "foo" here */
- return PTR_ERR(foo->p);
+ ret = PTR_ERR(foo->p);
+ foo->p = NULL;
+ return ret;
}
foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
if (IS_ERR(foo->s)) {
- /* FIXME: clean up "foo" here */
+ devm_pinctrl_put(foo->p);
return PTR_ERR(foo->s);
}
- ret = pinctrl_select_state(foo->s);
+ ret = pinctrl_select_state(foo->p, foo->s);
if (ret < 0) {
- /* FIXME: clean up "foo" here */
+ devm_pinctrl_put(foo->p);
return ret;
}
}
@@ -1251,49 +1283,49 @@ arrangement on your bus.
The semantics of the pinctrl APIs are:
-- pinctrl_get() is called in process context to obtain a handle to all pinctrl
+- ``pinctrl_get()`` is called in process context to obtain a handle to all pinctrl
information for a given client device. It will allocate a struct from the
kernel memory to hold the pinmux state. All mapping table parsing or similar
slow operations take place within this API.
-- devm_pinctrl_get() is a variant of pinctrl_get() that causes pinctrl_put()
+- ``devm_pinctrl_get()`` is a variant of pinctrl_get() that causes ``pinctrl_put()``
to be called automatically on the retrieved pointer when the associated
device is removed. It is recommended to use this function over plain
- pinctrl_get().
+ ``pinctrl_get()``.
-- pinctrl_lookup_state() is called in process context to obtain a handle to a
+- ``pinctrl_lookup_state()`` is called in process context to obtain a handle to a
specific state for a client device. This operation may be slow, too.
-- pinctrl_select_state() programs pin controller hardware according to the
+- ``pinctrl_select_state()`` programs pin controller hardware according to the
definition of the state as given by the mapping table. In theory, this is a
fast-path operation, since it only involved blasting some register settings
into hardware. However, note that some pin controllers may have their
registers on a slow/IRQ-based bus, so client devices should not assume they
- can call pinctrl_select_state() from non-blocking contexts.
+ can call ``pinctrl_select_state()`` from non-blocking contexts.
-- pinctrl_put() frees all information associated with a pinctrl handle.
+- ``pinctrl_put()`` frees all information associated with a pinctrl handle.
-- devm_pinctrl_put() is a variant of pinctrl_put() that may be used to
- explicitly destroy a pinctrl object returned by devm_pinctrl_get().
+- ``devm_pinctrl_put()`` is a variant of ``pinctrl_put()`` that may be used to
+ explicitly destroy a pinctrl object returned by ``devm_pinctrl_get()``.
However, use of this function will be rare, due to the automatic cleanup
that will occur even without calling it.
- pinctrl_get() must be paired with a plain pinctrl_put().
- pinctrl_get() may not be paired with devm_pinctrl_put().
- devm_pinctrl_get() can optionally be paired with devm_pinctrl_put().
- devm_pinctrl_get() may not be paired with plain pinctrl_put().
+ ``pinctrl_get()`` must be paired with a plain ``pinctrl_put()``.
+ ``pinctrl_get()`` may not be paired with ``devm_pinctrl_put()``.
+ ``devm_pinctrl_get()`` can optionally be paired with ``devm_pinctrl_put()``.
+ ``devm_pinctrl_get()`` may not be paired with plain ``pinctrl_put()``.
Usually the pin control core handled the get/put pair and call out to the
device drivers bookkeeping operations, like checking available functions and
-the associated pins, whereas select_state pass on to the pin controller
+the associated pins, whereas ``pinctrl_select_state()`` pass on to the pin controller
driver which takes care of activating and/or deactivating the mux setting by
quickly poking some registers.
-The pins are allocated for your device when you issue the devm_pinctrl_get()
+The pins are allocated for your device when you issue the ``devm_pinctrl_get()``
call, after this you should be able to see this in the debugfs listing of all
pins.
-NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the
+NOTE: the pinctrl system will return ``-EPROBE_DEFER`` if it cannot find the
requested pinctrl handles, for example if the pinctrl driver has not yet
registered. Thus make sure that the error path in your driver gracefully
cleans up and is ready to retry the probing later in the startup process.
@@ -1305,18 +1337,20 @@ Drivers needing both pin control and GPIOs
Again, it is discouraged to let drivers lookup and select pin control states
themselves, but again sometimes this is unavoidable.
-So say that your driver is fetching its resources like this::
+So say that your driver is fetching its resources like this:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
- #include <linux/gpio.h>
+ #include <linux/gpio/consumer.h>
struct pinctrl *pinctrl;
- int gpio;
+ struct gpio_desc *gpio;
pinctrl = devm_pinctrl_get_select_default(&dev);
- gpio = devm_gpio_request(&dev, 14, "foo");
+ gpio = devm_gpiod_get(&dev, "foo");
-Here we first request a certain pin state and then request GPIO 14 to be
+Here we first request a certain pin state and then request GPIO "foo" to be
used. If you're using the subsystems orthogonally like this, you should
nominally always get your pinctrl handle and select the desired pinctrl
state BEFORE requesting the GPIO. This is a semantic convention to avoid
@@ -1331,9 +1365,9 @@ probing, nevertheless orthogonal to the GPIO subsystem.
But there are also situations where it makes sense for the GPIO subsystem
to communicate directly with the pinctrl subsystem, using the latter as a
back-end. This is when the GPIO driver may call out to the functions
-described in the section "Pin control interaction with the GPIO subsystem"
+described in the section `Pin control interaction with the GPIO subsystem`_
above. This only involves per-pin multiplexing, and will be completely
-hidden behind the gpio_*() function namespace. In this case, the driver
+hidden behind the gpiod_*() function namespace. In this case, the driver
need not interact with the pin control subsystem at all.
If a pin control driver and a GPIO driver is dealing with the same pins
@@ -1348,12 +1382,14 @@ System pin control hogging
==========================
Pin control map entries can be hogged by the core when the pin controller
-is registered. This means that the core will attempt to call pinctrl_get(),
-lookup_state() and select_state() on it immediately after the pin control
-device has been registered.
+is registered. This means that the core will attempt to call ``pinctrl_get()``,
+``pinctrl_lookup_state()`` and ``pinctrl_select_state()`` on it immediately after
+the pin control device has been registered.
This occurs for mapping table entries where the client device name is equal
-to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT::
+to the pin controller device name, and the state name is ``PINCTRL_STATE_DEFAULT``:
+
+.. code-block:: c
{
.dev_name = "pinctrl-foo",
@@ -1365,7 +1401,9 @@ to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT::
Since it may be common to request the core to hog a few always-applicable
mux settings on the primary pin controller, there is a convenience macro for
-this::
+this:
+
+.. code-block:: c
PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */,
"power_func")
@@ -1385,7 +1423,9 @@ function, but with different named in the mapping as described under
This snippet first initializes a state object for both groups (in foo_probe()),
then muxes the function in the pins defined by group A, and finally muxes it in
-on the pins defined by group B::
+on the pins defined by group B:
+
+.. code-block:: c
#include <linux/pinctrl/consumer.h>
@@ -1399,11 +1439,11 @@ on the pins defined by group B::
if (IS_ERR(p))
...
- s1 = pinctrl_lookup_state(foo->p, "pos-A");
+ s1 = pinctrl_lookup_state(p, "pos-A");
if (IS_ERR(s1))
...
- s2 = pinctrl_lookup_state(foo->p, "pos-B");
+ s2 = pinctrl_lookup_state(p, "pos-B");
if (IS_ERR(s2))
...
}
@@ -1411,16 +1451,16 @@ on the pins defined by group B::
foo_switch()
{
/* Enable on position A */
- ret = pinctrl_select_state(s1);
+ ret = pinctrl_select_state(p, s1);
if (ret < 0)
- ...
+ ...
...
/* Enable on position B */
- ret = pinctrl_select_state(s2);
+ ret = pinctrl_select_state(p, s2);
if (ret < 0)
- ...
+ ...
...
}
@@ -1432,6 +1472,7 @@ can be used by different functions at different times on a running system.
Debugfs files
=============
+
These files are created in ``/sys/kernel/debug/pinctrl``:
- ``pinctrl-devices``: prints each pin controller device along with columns to
@@ -1440,7 +1481,7 @@ These files are created in ``/sys/kernel/debug/pinctrl``:
- ``pinctrl-handles``: prints each configured pin controller handle and the
corresponding pinmux maps
-- ``pinctrl-maps``: print all pinctrl maps
+- ``pinctrl-maps``: prints all pinctrl maps
A sub-directory is created inside of ``/sys/kernel/debug/pinctrl`` for each pin
controller device containing these files:
@@ -1448,20 +1489,22 @@ controller device containing these files:
- ``pins``: prints a line for each pin registered on the pin controller. The
pinctrl driver may add additional information such as register contents.
-- ``gpio-ranges``: print ranges that map gpio lines to pins on the controller
+- ``gpio-ranges``: prints ranges that map gpio lines to pins on the controller
-- ``pingroups``: print all pin groups registered on the pin controller
+- ``pingroups``: prints all pin groups registered on the pin controller
-- ``pinconf-pins``: print pin config settings for each pin
+- ``pinconf-pins``: prints pin config settings for each pin
-- ``pinconf-groups``: print pin config settings per pin group
+- ``pinconf-groups``: prints pin config settings per pin group
-- ``pinmux-functions``: print each pin function along with the pin groups that
+- ``pinmux-functions``: prints each pin function along with the pin groups that
map to the pin function
-- ``pinmux-pins``: iterate through all pins and print mux owner, gpio owner
+- ``pinmux-pins``: iterates through all pins and prints mux owner, gpio owner
and if the pin is a hog
-- ``pinmux-select``: write to this file to activate a pin function for a group::
+- ``pinmux-select``: write to this file to activate a pin function for a group:
+
+ .. code-block:: sh
echo "<group-name function-name>" > pinmux-select
diff --git a/Documentation/driver-api/pldmfw/index.rst b/Documentation/driver-api/pldmfw/index.rst
index ad2c33ece30f..e59beca374c1 100644
--- a/Documentation/driver-api/pldmfw/index.rst
+++ b/Documentation/driver-api/pldmfw/index.rst
@@ -14,13 +14,12 @@ the PLDM for Firmware Update standard
file-format
driver-ops
-==================================
Overview of the ``pldmfw`` library
==================================
The ``pldmfw`` library is intended to be used by device drivers for
implementing device flash update based on firmware files following the PLDM
-firwmare file format.
+firmware file format.
It is implemented using an ops table that allows device drivers to provide
the underlying device specific functionality.
diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst
index d448cb57df86..36d5c9c9fd11 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -255,7 +255,7 @@ get registered: a child can never be registered, probed or resumed before
its parent; and can't be removed or suspended after that parent.
The policy is that the device hierarchy should match hardware bus topology.
-[Or at least the control bus, for devices which use multiple busses.]
+[Or at least the control bus, for devices which use multiple buses.]
In particular, this means that a device registration may fail if the parent of
the device is suspending (i.e. has been chosen by the PM core as the next
device to suspend) or has already suspended, as well as after all of the other
@@ -358,7 +358,7 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``.
is probed against the device in question by passing them to the
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
these flags is set, the PM core will not apply the direct-complete
- procedure described above to the given device and, consequenty, to any
+ procedure described above to the given device and, consequently, to any
of its ancestors. The second flag, when set, informs the middle layer
code (bus types, device types, PM domains, classes) that it should take
the return value of the ``->prepare`` callback provided by the driver
@@ -493,7 +493,7 @@ states, like S3).
Drivers must also be prepared to notice that the device has been removed
while the system was powered down, whenever that's physically possible.
-PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of busses
+PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of buses
where common Linux platforms will see such removal. Details of how drivers
will notice and handle such removals are currently bus-specific, and often
involve a separate thread.
diff --git a/Documentation/driver-api/pps.rst b/Documentation/driver-api/pps.rst
index 2d6b99766ee8..598729f9cd27 100644
--- a/Documentation/driver-api/pps.rst
+++ b/Documentation/driver-api/pps.rst
@@ -200,11 +200,56 @@ Generators
Sometimes one needs to be able not only to catch PPS signals but to produce
them also. For example, running a distributed simulation, which requires
-computers' clock to be synchronized very tightly. One way to do this is to
-invent some complicated hardware solutions but it may be neither necessary
-nor affordable. The cheap way is to load a PPS generator on one of the
-computers (master) and PPS clients on others (slaves), and use very simple
-cables to deliver signals using parallel ports, for example.
+computers' clock to be synchronized very tightly.
+
+To do so the class pps-gen has been added. PPS generators can be
+registered in the kernel by defining a struct pps_gen_source_info as
+follows::
+
+ static const struct pps_gen_source_info pps_gen_dummy_info = {
+ .use_system_clock = true,
+ .get_time = pps_gen_dummy_get_time,
+ .enable = pps_gen_dummy_enable,
+ };
+
+Where the use_system_clock states if the generator uses the system
+clock to generate its pulses, or they are from a peripheral device
+clock. Method get_time() is used to query the time stored into the
+generator clock, while the method enable() is used to enable or
+disable the PPS pulse generation.
+
+Then calling the function pps_gen_register_source() in your
+initialization routine as follows creates a new generator in the
+system::
+
+ pps_gen = pps_gen_register_source(&pps_gen_dummy_info);
+
+Generators SYSFS support
+------------------------
+
+If the SYSFS filesystem is enabled in the kernel it provides a new class::
+
+ $ ls /sys/class/pps-gen/
+ pps-gen0/ pps-gen1/ pps-gen2/
+
+Every directory is the ID of a PPS generator defined in the system and
+inside of it you find several files::
+
+ $ ls -F /sys/class/pps-gen/pps-gen0/
+ dev enable name power/ subsystem@ system time uevent
+
+To enable the PPS signal generation you can use the command below::
+
+ $ echo 1 > /sys/class/pps-gen/pps-gen0/enable
+
+Parallel port generator
+------------------------
+
+One way to do this is to invent some complicated hardware solutions but it
+may be neither necessary nor affordable. The cheap way is to load a PPS
+generator on one of the computers (master) and PPS clients on others
+(slaves), and use very simple cables to deliver signals using parallel
+ports, for example.
Parallel port cable pinout::
@@ -240,3 +285,27 @@ delay between assert and clear edge as small as possible to reduce system
latencies. But if it is too small slave won't be able to capture clear edge
transition. The default of 30us should be good enough in most situations.
The delay can be selected using 'delay' pps_gen_parport module parameter.
+
+
+Intel Timed I/O PPS signal generator
+------------------------------------
+
+Intel Timed I/O is a high precision device, present on 2019 and newer Intel
+CPUs, that can generate PPS signals.
+
+Timed I/O and system time are both driven by same hardware clock. The signal
+is generated with a precision of ~20 nanoseconds. The generated PPS signal
+is used to synchronize an external device with system clock. For example,
+it can be used to share your clock with a device that receives PPS signal,
+generated by Timed I/O device. There are dedicated Timed I/O pins to deliver
+the PPS signal to an external device.
+
+Usage of Intel Timed I/O as PPS generator:
+
+Start generating PPS signal::
+
+ $echo 1 > /sys/class/pps-gen/pps-genx/enable
+
+Stop generating PPS signal::
+
+ $echo 0 > /sys/class/pps-gen/pps-genx/enable
diff --git a/Documentation/driver-api/ptp.rst b/Documentation/driver-api/ptp.rst
index 664838ae7776..5e033c3b11b3 100644
--- a/Documentation/driver-api/ptp.rst
+++ b/Documentation/driver-api/ptp.rst
@@ -73,6 +73,22 @@ Writing clock drivers
class driver, since the lock may also be needed by the clock
driver's interrupt service routine.
+PTP hardware clock requirements for '.adjphase'
+-----------------------------------------------
+
+ The 'struct ptp_clock_info' interface has a '.adjphase' function.
+ This function has a set of requirements from the PHC in order to be
+ implemented.
+
+ * The PHC implements a servo algorithm internally that is used to
+ correct the offset passed in the '.adjphase' call.
+ * When other PTP adjustment functions are called, the PHC servo
+ algorithm is disabled.
+
+ **NOTE:** '.adjphase' is not a simple time adjustment functionality
+ that 'jumps' the PHC clock time based on the provided offset. It
+ should correct the offset provided using an internal algorithm.
+
Supported hardware
==================
@@ -106,3 +122,16 @@ Supported hardware
- LPF settings (bandwidth, phase limiting, automatic holdover, physical layer assist (per ITU-T G.8273.2))
- Programmable output PTP clocks, any frequency up to 1GHz (to other PHY/MAC time stampers, refclk to ASSPs/SoCs/FPGAs)
- Lock to GNSS input, automatic switching between GNSS and user-space PHC control (optional)
+
+ * NVIDIA Mellanox
+
+ - GPIO
+ - Certain variants of ConnectX-6 Dx and later products support one
+ GPIO which can time stamp external triggers and one GPIO to produce
+ periodic signals.
+ - Certain variants of ConnectX-5 and older products support one GPIO,
+ configured to either time stamp external triggers or produce
+ periodic signals.
+ - PHC instances
+ - All ConnectX devices have a free-running counter
+ - ConnectX-6 Dx and later devices have a UTC format counter
diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index 8c71a2055d27..0d27a40f5818 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -35,20 +35,26 @@ consumers to providers, as given in the following example::
Using PWMs
----------
-Legacy users can request a PWM device using pwm_request() and free it
-after usage with pwm_free().
-
-New users should use the pwm_get() function and pass to it the consumer
-device or a consumer name. pwm_put() is used to free the PWM device. Managed
-variants of the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
+Consumers use the pwm_get() function and pass to it the consumer device or a
+consumer name. pwm_put() is used to free the PWM device. Managed variants of
+the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist.
After being requested, a PWM has to be configured using::
- int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state);
+ int pwm_apply_might_sleep(struct pwm_device *pwm, struct pwm_state *state);
This API controls both the PWM period/duty_cycle config and the
enable/disable state.
+PWM devices can be used from atomic context, if the PWM does not sleep. You
+can check if this the case with::
+
+ bool pwm_might_sleep(struct pwm_device *pwm);
+
+If false, the PWM can also be configured from atomic context with::
+
+ int pwm_apply_atomic(struct pwm_device *pwm, struct pwm_state *state);
+
As a consumer, don't rely on the output's state for a disabled PWM. If it's
easily possible, drivers are supposed to emit the inactive state, but some
drivers cannot. If you rely on getting the inactive state, use .duty_cycle=0,
@@ -60,13 +66,13 @@ If supported by the driver, the signal can be optimized, for example to improve
EMI by phase shifting the individual channels of a chip.
The pwm_config(), pwm_enable() and pwm_disable() functions are just wrappers
-around pwm_apply_state() and should not be used if the user wants to change
+around pwm_apply_might_sleep() and should not be used if the user wants to change
several parameter at once. For example, if you see pwm_config() and
pwm_{enable,disable}() calls in the same function, this probably means you
-should switch to pwm_apply_state().
+should switch to pwm_apply_might_sleep().
The PWM user API also allows one to query the PWM state that was passed to the
-last invocation of pwm_apply_state() using pwm_get_state(). Note this is
+last invocation of pwm_apply_might_sleep() using pwm_get_state(). Note this is
different to what the driver has actually implemented if the request cannot be
satisfied exactly with the hardware in use. There is currently no way for
consumers to get the actually implemented settings.
@@ -114,13 +120,13 @@ channel that was exported. The following properties will then be available:
duty_cycle
The active time of the PWM signal (read/write).
- Value is in nanoseconds and must be less than the period.
+ Value is in nanoseconds and must be less than or equal to the period.
polarity
Changes the polarity of the PWM signal (read/write).
Writes to this property only work if the PWM chip supports changing
- the polarity. The polarity can only be changed if the PWM is not
- enabled. Value is the string "normal" or "inversed".
+ the polarity.
+ Value is the string "normal" or "inversed".
enable
Enable/disable the PWM signal (read/write).
@@ -137,11 +143,12 @@ to implement the pwm_*() functions itself. This means that it's impossible
to have multiple PWM drivers in the system. For this reason it's mandatory
for new drivers to use the generic PWM framework.
-A new PWM controller/chip can be added using pwmchip_add() and removed
-again with pwmchip_remove(). pwmchip_add() takes a filled in struct
-pwm_chip as argument which provides a description of the PWM chip, the
-number of PWM devices provided by the chip and the chip-specific
-implementation of the supported PWM operations to the framework.
+A new PWM controller/chip can be allocated using pwmchip_alloc(), then
+registered using pwmchip_add() and removed again with pwmchip_remove(). To undo
+pwmchip_alloc() use pwmchip_put(). pwmchip_add() takes a filled in struct
+pwm_chip as argument which provides a description of the PWM chip, the number
+of PWM devices provided by the chip and the chip-specific implementation of the
+supported PWM operations to the framework.
When implementing polarity support in a PWM driver, make sure to respect the
signal conventions in the PWM framework. By definition, normal polarity
@@ -165,11 +172,16 @@ consumers should implement it as described in the "Using PWMs" section.
Locking
-------
-The PWM core list manipulations are protected by a mutex, so pwm_request()
-and pwm_free() may not be called from an atomic context. Currently the
-PWM core does not enforce any locking to pwm_enable(), pwm_disable() and
-pwm_config(), so the calling context is currently driver specific. This
-is an issue derived from the former barebone API and should be fixed soon.
+The PWM core list manipulations are protected by a mutex, so pwm_get()
+and pwm_put() may not be called from an atomic context.
+Most functions in the PWM consumer API might sleep and so must not be called
+from atomic context. The notable exception is pwm_apply_atomic() which has the
+same semantics as pwm_apply_might_sleep() but can be called from atomic context.
+(The price for that is that it doesn't work for all PWM devices, use
+pwm_might_sleep() to check if a given PWM supports atomic operation.
+
+Locking in the PWM core ensures that callbacks related to a single chip are
+serialized.
Helpers
-------
diff --git a/Documentation/driver-api/pwrseq.rst b/Documentation/driver-api/pwrseq.rst
new file mode 100644
index 000000000000..ad18b2326b68
--- /dev/null
+++ b/Documentation/driver-api/pwrseq.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright 2024 Linaro Ltd.
+
+====================
+Power Sequencing API
+====================
+
+:Author: Bartosz Golaszewski
+
+Introduction
+============
+
+This framework is designed to abstract complex power-up sequences that are
+shared between multiple logical devices in the Linux kernel.
+
+The intention is to allow consumers to obtain a power sequencing handle
+exposed by the power sequence provider and delegate the actual requesting and
+control of the underlying resources as well as to allow the provider to
+mitigate any potential conflicts between multiple users behind the scenes.
+
+Glossary
+--------
+
+The power sequencing API uses a number of terms specific to the subsystem:
+
+Unit
+
+ A unit is a discrete chunk of a power sequence. For instance one unit may
+ enable a set of regulators, another may enable a specific GPIO. Units can
+ define dependencies in the form of other units that must be enabled before
+ it itself can be.
+
+Target
+
+ A target is a set of units (composed of the "final" unit and its
+ dependencies) that a consumer selects by its name when requesting a handle
+ to the power sequencer. Via the dependency system, multiple targets may
+ share the same parts of a power sequence but ignore parts that are
+ irrelevant.
+
+Descriptor
+
+ A handle passed by the pwrseq core to every consumer that serves as the
+ entry point to the provider layer. It ensures coherence between different
+ users and keeps reference counting consistent.
+
+Consumer interface
+==================
+
+The consumer API is aimed to be as simple as possible. The driver interested in
+getting a descriptor from the power sequencer should call pwrseq_get() and
+specify the name of the target it wants to reach in the sequence after calling
+pwrseq_power_up(). The descriptor can be released by calling pwrseq_put() and
+the consumer can request the powering down of its target with
+pwrseq_power_off(). Note that there is no guarantee that pwrseq_power_off()
+will have any effect as there may be multiple users of the underlying resources
+who may keep them active.
+
+Provider interface
+==================
+
+The provider API is admittedly not nearly as straightforward as the one for
+consumers but it makes up for it in flexibility.
+
+Each provider can logically split the power-up sequence into discrete chunks
+(units) and define their dependencies. They can then expose named targets that
+consumers may use as the final point in the sequence that they wish to reach.
+
+To that end the providers fill out a set of configuration structures and
+register with the pwrseq subsystem by calling pwrseq_device_register().
+
+Dynamic consumer matching
+-------------------------
+
+The main difference between pwrseq and other Linux kernel providers is the
+mechanism for dynamic matching of consumers and providers. Every power sequence
+provider driver must implement the `match()` callback and pass it to the pwrseq
+core when registering with the subsystems.
+
+When a client requests a sequencer handle, the core will call this callback for
+every registered provider and let it flexibly figure out whether the proposed
+client device is indeed its consumer. For example: if the provider binds to the
+device-tree node representing a power management unit of a chipset and the
+consumer driver controls one of its modules, the provider driver may parse the
+relevant regulator supply properties in device tree and see if they lead from
+the PMU to the consumer.
+
+API reference
+=============
+
+.. kernel-doc:: include/linux/pwrseq/provider.h
+ :internal:
+
+.. kernel-doc:: drivers/power/sequencing/core.c
+ :export:
diff --git a/Documentation/driver-api/reset.rst b/Documentation/driver-api/reset.rst
index 84e03d7039cc..f773100daaa4 100644
--- a/Documentation/driver-api/reset.rst
+++ b/Documentation/driver-api/reset.rst
@@ -218,4 +218,3 @@ devm_reset_controller_register().
reset_controller_register
reset_controller_unregister
devm_reset_controller_register
- reset_controller_add_lookup
diff --git a/Documentation/driver-api/s390-drivers.rst b/Documentation/driver-api/s390-drivers.rst
index 5158577bc29b..8c0845c4eee7 100644
--- a/Documentation/driver-api/s390-drivers.rst
+++ b/Documentation/driver-api/s390-drivers.rst
@@ -27,7 +27,7 @@ not strictly considered I/O devices. They are considered here as well,
although they are not the focus of this document.
Some additional information can also be found in the kernel source under
-Documentation/s390/driver-model.rst.
+Documentation/arch/s390/driver-model.rst.
The css bus
===========
@@ -38,7 +38,7 @@ into several categories:
* Standard I/O subchannels, for use by the system. They have a child
device on the ccw bus and are described below.
* I/O subchannels bound to the vfio-ccw driver. See
- Documentation/s390/vfio-ccw.rst.
+ Documentation/arch/s390/vfio-ccw.rst.
* Message subchannels. No Linux driver currently exists.
* CHSC subchannels (at most one). The chsc subchannel driver can be used
to send asynchronous chsc commands.
diff --git a/Documentation/driver-api/scsi.rst b/Documentation/driver-api/scsi.rst
index 64b231d125e0..8bbdfb018c53 100644
--- a/Documentation/driver-api/scsi.rst
+++ b/Documentation/driver-api/scsi.rst
@@ -18,9 +18,9 @@ optical drives, test equipment, and medical devices) to a host computer.
Although the old parallel (fast/wide/ultra) SCSI bus has largely fallen
out of use, the SCSI command set is more widely used than ever to
-communicate with devices over a number of different busses.
+communicate with devices over a number of different buses.
-The `SCSI protocol <http://www.t10.org/scsi-3.htm>`__ is a big-endian
+The `SCSI protocol <https://www.t10.org/scsi-3.htm>`__ is a big-endian
peer-to-peer packet based protocol. SCSI commands are 6, 10, 12, or 16
bytes long, often followed by an associated data payload.
@@ -28,8 +28,7 @@ SCSI commands can be transported over just about any kind of bus, and
are the default protocol for storage devices attached to USB, SATA, SAS,
Fibre Channel, FireWire, and ATAPI devices. SCSI packets are also
commonly exchanged over Infiniband,
-`I2O <http://i2o.shadowconnect.com/faq.php>`__, TCP/IP
-(`iSCSI <https://en.wikipedia.org/wiki/ISCSI>`__), even `Parallel
+TCP/IP (`iSCSI <https://en.wikipedia.org/wiki/ISCSI>`__), even `Parallel
ports <http://cyberelk.net/tim/parport/parscsi.html>`__.
Design of the Linux SCSI subsystem
@@ -127,7 +126,7 @@ Manage scsi_dev_info_list, which tracks blacklisted and whitelisted
devices.
.. kernel-doc:: drivers/scsi/scsi_devinfo.c
- :internal:
+ :export:
drivers/scsi/scsi_ioctl.c
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -163,16 +162,15 @@ statistics and to pass information directly to the lowlevel driver. I.E.
plumbing to manage /proc/scsi/\*
.. kernel-doc:: drivers/scsi/scsi_proc.c
- :internal:
drivers/scsi/scsi_netlink.c
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Infrastructure to provide async events from transports to userspace via
netlink, using a single NETLINK_SCSITRANSPORT protocol for all
-transports. See `the original patch
-submission <http://marc.info/?l=linux-scsi&m=115507374832500&w=2>`__ for
-more details.
+transports. See `the original patch submission
+<https://lore.kernel.org/linux-scsi/1155070439.6275.5.camel@localhost.localdomain/>`__
+for more details.
.. kernel-doc:: drivers/scsi/scsi_netlink.c
:internal:
@@ -194,7 +192,7 @@ else, sequentially scan LUNs up until some maximum is reached, or a LUN
is seen that cannot have a device attached to it.
.. kernel-doc:: drivers/scsi/scsi_scan.c
- :internal:
+ :export:
drivers/scsi/scsi_sysctl.c
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -259,7 +257,7 @@ attributes for Serial Attached SCSI, a variant of SATA aimed at large
high-end systems.
The SAS transport class contains common code to deal with SAS HBAs, an
-aproximated representation of SAS topologies in the driver model, and
+approximated representation of SAS topologies in the driver model, and
various sysfs attributes to expose these topologies and management
interfaces to userspace.
@@ -288,7 +286,7 @@ Parallel SCSI (SPI) transport class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The file drivers/scsi/scsi_transport_spi.c defines transport
-attributes for traditional (fast/wide/ultra) SCSI busses.
+attributes for traditional (fast/wide/ultra) SCSI buses.
.. kernel-doc:: drivers/scsi/scsi_transport_spi.c
:export:
@@ -328,11 +326,11 @@ the ordinary is seen.
To be more realistic, the simulated devices have the transport
attributes of SAS disks.
-For documentation see http://sg.danny.cz/sg/sdebug26.html
+For documentation see http://sg.danny.cz/sg/scsi_debug.html
todo
~~~~
Parallel (fast/wide/ultra) SCSI, USB, SATA, SAS, Fibre Channel,
-FireWire, ATAPI devices, Infiniband, I2O, Parallel ports,
+FireWire, ATAPI devices, Infiniband, Parallel ports,
netlink...
diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst
index 23c6b956cd90..c1db6a1a67c4 100644
--- a/Documentation/driver-api/serial/driver.rst
+++ b/Documentation/driver-api/serial/driver.rst
@@ -24,9 +24,8 @@ console support.
Console Support
---------------
-The serial core provides a few helper functions. This includes identifing
-the correct port structure (via uart_get_console()) and decoding command line
-arguments (uart_parse_options()).
+The serial core provides a few helper functions. This includes
+decoding command line arguments (uart_parse_options()).
There is also a helper function (uart_console_write()) which performs a
character by character write, translating newlines to CRLF sequences.
@@ -76,7 +75,10 @@ Other functions
uart_add_one_port uart_remove_one_port uart_console_write
uart_parse_earlycon uart_parse_options uart_set_options
uart_get_lsr_info uart_handle_dcd_change uart_handle_cts_change
- uart_try_toggle_sysrq uart_get_console
+ uart_try_toggle_sysrq
+
+.. kernel-doc:: include/linux/serial_core.h
+ :identifiers: uart_port_tx_limited uart_port_tx
Other notes
-----------
@@ -98,6 +100,6 @@ Modem control lines via GPIO
Some helpers are provided in order to set/get modem control lines via GPIO.
.. kernel-doc:: drivers/tty/serial/serial_mctrl_gpio.c
- :identifiers: mctrl_gpio_init mctrl_gpio_free mctrl_gpio_to_gpiod
+ :identifiers: mctrl_gpio_init mctrl_gpio_to_gpiod
mctrl_gpio_set mctrl_gpio_get mctrl_gpio_enable_ms
- mctrl_gpio_disable_ms
+ mctrl_gpio_disable_ms_sync mctrl_gpio_disable_ms_no_sync
diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
index 6ebad75c74ed..dce061ef7647 100644
--- a/Documentation/driver-api/serial/serial-rs485.rst
+++ b/Documentation/driver-api/serial/serial-rs485.rst
@@ -29,23 +29,28 @@ RS485 Serial Communications
3. Data Structures Already Available in the Kernel
==================================================
- The Linux kernel provides the serial_rs485 structure (see [1]) to handle
- RS485 communications. This data structure is used to set and configure RS485
+ The Linux kernel provides the struct serial_rs485 to handle RS485
+ communications. This data structure is used to set and configure RS485
parameters in the platform data and in ioctls.
- The device tree can also provide RS485 boot time parameters (see [2]
- for bindings). The driver is in charge of filling this data structure from
- the values given by the device tree.
+ The device tree can also provide RS485 boot time parameters
+ [#DT-bindings]_. The serial core fills the struct serial_rs485 from the
+ values given by the device tree when the driver calls
+ uart_get_rs485_mode().
Any driver for devices capable of working both as RS232 and RS485 should
- implement the rs485_config callback and provide rs485_supported in the
- uart_port structure. The serial core calls rs485_config to do the device
- specific part in response to TIOCSRS485 ioctl (see below). The rs485_config
- callback receives a pointer to a sanitizated serial_rs485 structure. The
- serial_rs485 userspace provides is sanitized before calling rs485_config
- using rs485_supported that indicates what RS485 features the driver supports
- for the uart_port. TIOCGRS485 ioctl can be used to read back the
- serial_rs485 structure matching to the current configuration.
+ implement the ``rs485_config`` callback and provide ``rs485_supported``
+ in the ``struct uart_port``. The serial core calls ``rs485_config`` to do
+ the device specific part in response to TIOCSRS485 ioctl (see below). The
+ ``rs485_config`` callback receives a pointer to a sanitizated struct
+ serial_rs485. The struct serial_rs485 userspace provides is sanitized
+ before calling ``rs485_config`` using ``rs485_supported`` that indicates
+ what RS485 features the driver supports for the ``struct uart_port``.
+ TIOCGRS485 ioctl can be used to read back the struct serial_rs485
+ matching to the current configuration.
+
+.. kernel-doc:: include/uapi/linux/serial.h
+ :identifiers: serial_rs485 uart_get_rs485_mode
4. Usage from user-level
========================
@@ -103,29 +108,28 @@ RS485 Serial Communications
========================
The Linux kernel provides addressing mode for multipoint RS-485 serial
- communications line. The addressing mode is enabled with SER_RS485_ADDRB
- flag in serial_rs485. Struct serial_rs485 has two additional flags and
- fields for enabling receive and destination addresses.
+ communications line. The addressing mode is enabled with
+ ``SER_RS485_ADDRB`` flag in struct serial_rs485. The struct serial_rs485
+ has two additional flags and fields for enabling receive and destination
+ addresses.
Address mode flags:
- - SER_RS485_ADDRB: Enabled addressing mode (sets also ADDRB in termios).
- - SER_RS485_ADDR_RECV: Receive (filter) address enabled.
- - SER_RS485_ADDR_DEST: Set destination address.
+ - ``SER_RS485_ADDRB``: Enabled addressing mode (sets also ADDRB in termios).
+ - ``SER_RS485_ADDR_RECV``: Receive (filter) address enabled.
+ - ``SER_RS485_ADDR_DEST``: Set destination address.
- Address fields (enabled with corresponding SER_RS485_ADDR_* flag):
- - addr_recv: Receive address.
- - addr_dest: Destination address.
+ Address fields (enabled with corresponding ``SER_RS485_ADDR_*`` flag):
+ - ``addr_recv``: Receive address.
+ - ``addr_dest``: Destination address.
Once a receive address is set, the communication can occur only with the
particular device and other peers are filtered out. It is left up to the
receiver side to enforce the filtering. Receive address will be cleared
- if SER_RS485_ADDR_RECV is not set.
+ if ``SER_RS485_ADDR_RECV`` is not set.
Note: not all devices supporting RS485 support multipoint addressing.
6. References
=============
- [1] include/uapi/linux/serial.h
-
- [2] Documentation/devicetree/bindings/serial/rs485.txt
+.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
diff --git a/Documentation/driver-api/soundwire/bra.rst b/Documentation/driver-api/soundwire/bra.rst
new file mode 100644
index 000000000000..c08ab2591496
--- /dev/null
+++ b/Documentation/driver-api/soundwire/bra.rst
@@ -0,0 +1,336 @@
+==========================
+Bulk Register Access (BRA)
+==========================
+
+Conventions
+-----------
+
+Capitalized words used in this documentation are intentional and refer
+to concepts of the SoundWire 1.x specification.
+
+Introduction
+------------
+
+The SoundWire 1.x specification provides a mechanism to speed-up
+command/control transfers by reclaiming parts of the audio
+bandwidth. The Bulk Register Access (BRA) protocol is a standard
+solution based on the Bulk Payload Transport (BPT) definitions.
+
+The regular control channel uses Column 0 and can only send/retrieve
+one byte per frame with write/read commands. With a typical 48kHz
+frame rate, only 48kB/s can be transferred.
+
+The optional Bulk Register Access capability can transmit up to 12
+Mbits/s and reduce transfer times by several orders of magnitude, but
+has multiple design constraints:
+
+ (1) Each frame can only support a read or a write transfer, with a
+ 10-byte overhead per frame (header and footer response).
+
+ (2) The read/writes SHALL be from/to contiguous register addresses
+ in the same frame. A fragmented register space decreases the
+ efficiency of the protocol by requiring multiple BRA transfers
+ scheduled in different frames.
+
+ (3) The targeted Peripheral device SHALL support the optional Data
+ Port 0, and likewise the Manager SHALL expose audio-like Ports
+ to insert BRA packets in the audio payload using the concepts of
+ Sample Interval, HSTART, HSTOP, etc.
+
+ (4) The BRA transport efficiency depends on the available
+ bandwidth. If there are no on-going audio transfers, the entire
+ frame minus Column 0 can be reclaimed for BRA. The frame shape
+ also impacts efficiency: since Column0 cannot be used for
+ BTP/BRA, the frame should rely on a large number of columns and
+ minimize the number of rows. The bus clock should be as high as
+ possible.
+
+ (5) The number of bits transferred per frame SHALL be a multiple of
+ 8 bits. Padding bits SHALL be inserted if necessary at the end
+ of the data.
+
+ (6) The regular read/write commands can be issued in parallel with
+ BRA transfers. This is convenient to e.g. deal with alerts, jack
+ detection or change the volume during firmware download, but
+ accessing the same address with two independent protocols has to
+ be avoided to avoid undefined behavior.
+
+ (7) Some implementations may not be capable of handling the
+ bandwidth of the BRA protocol, e.g. in the case of a slow I2C
+ bus behind the SoundWire IP. In this case, the transfers may
+ need to be spaced in time or flow-controlled.
+
+ (8) Each BRA packet SHALL be marked as 'Active' when valid data is
+ to be transmitted. This allows for software to allocate a BRA
+ stream but not transmit/discard data while processing the
+ results or preparing the next batch of data, or allowing the
+ peripheral to deal with the previous transfer. In addition BRA
+ transfer can be started early on without data being ready.
+
+ (9) Up to 470 bytes may be transmitted per frame.
+
+ (10) The address is represented with 32 bits and does not rely on
+ the paging registers used for the regular command/control
+ protocol in Column 0.
+
+
+Error checking
+--------------
+
+Firmware download is one of the key usages of the Bulk Register Access
+protocol. To make sure the binary data integrity is not compromised by
+transmission or programming errors, each BRA packet provides:
+
+ (1) A CRC on the 7-byte header. This CRC helps the Peripheral Device
+ check if it is addressed and set the start address and number of
+ bytes. The Peripheral Device provides a response in Byte 7.
+
+ (2) A CRC on the data block (header excluded). This CRC is
+ transmitted as the last-but-one byte in the packet, prior to the
+ footer response.
+
+The header response can be one of:
+ (a) Ack
+ (b) Nak
+ (c) Not Ready
+
+The footer response can be one of:
+ (1) Ack
+ (2) Nak (CRC failure)
+ (3) Good (operation completed)
+ (4) Bad (operation failed)
+
+Example frame
+-------------
+
+The example below is not to scale and makes simplifying assumptions
+for clarity. The different chunks in the BRA packets are not required
+to start on a new SoundWire Row, and the scale of data may vary.
+
+ ::
+
+ +---+--------------------------------------------+
+ + | |
+ + | BRA HEADER |
+ + | |
+ + +--------------------------------------------+
+ + C | HEADER CRC |
+ + O +--------------------------------------------+
+ + M | HEADER RESPONSE |
+ + M +--------------------------------------------+
+ + A | |
+ + N | |
+ + D | DATA |
+ + | |
+ + | |
+ + | |
+ + +--------------------------------------------+
+ + | DATA CRC |
+ + +--------------------------------------------+
+ + | FOOTER RESPONSE |
+ +---+--------------------------------------------+
+
+
+Assuming the frame uses N columns, the configuration shown above can
+be programmed by setting the DP0 registers as:
+
+ - HSTART = 1
+ - HSTOP = N - 1
+ - Sampling Interval = N
+ - WordLength = N - 1
+
+Addressing restrictions
+-----------------------
+
+The Device Number specified in the Header follows the SoundWire
+definitions, and broadcast and group addressing are permitted. For now
+the Linux implementation only allows for a single BPT transfer to a
+single device at a time. This might be revisited at a later point as
+an optimization to send the same firmware to multiple devices, but
+this would only be beneficial for single-link solutions.
+
+In the case of multiple Peripheral devices attached to different
+Managers, the broadcast and group addressing is not supported by the
+SoundWire specification. Each device must be handled with separate BRA
+streams, possibly in parallel - the links are really independent.
+
+Unsupported features
+--------------------
+
+The Bulk Register Access specification provides a number of
+capabilities that are not supported in known implementations, such as:
+
+ (1) Transfers initiated by a Peripheral Device. The BRA Initiator is
+ always the Manager Device.
+
+ (2) Flow-control capabilities and retransmission based on the
+ 'NotReady' header response require extra buffering in the
+ SoundWire IP and are not implemented.
+
+Bi-directional handling
+-----------------------
+
+The BRA protocol can handle writes as well as reads, and in each
+packet the header and footer response are provided by the Peripheral
+Target device. On the Peripheral device, the BRA protocol is handled
+by a single DP0 data port, and at the low-level the bus ownership can
+will change for header/footer response as well as the data transmitted
+during a read.
+
+On the host side, most implementations rely on a Port-like concept,
+with two FIFOs consuming/generating data transfers in parallel
+(Host->Peripheral and Peripheral->Host). The amount of data
+consumed/produced by these FIFOs is not symmetrical, as a result
+hardware typically inserts markers to help software and hardware
+interpret raw data
+
+Each packet will typically have:
+
+ (1) a 'Start of Packet' indicator.
+
+ (2) an 'End of Packet' indicator.
+
+ (3) a packet identifier to correlate the data requested and
+ transmitted, and the error status for each frame
+
+Hardware implementations can check errors at the frame level, and
+retry a transfer in case of errors. However, as for the flow-control
+case, this requires extra buffering and intelligence in the
+hardware. The Linux support assumes that the entire transfer is
+cancelled if a single error is detected in one of the responses.
+
+Abstraction required
+~~~~~~~~~~~~~~~~~~~~
+
+There are no standard registers or mandatory implementation at the
+Manager level, so the low-level BPT/BRA details must be hidden in
+Manager-specific code. For example the Cadence IP format above is not
+known to the codec drivers.
+
+Likewise, codec drivers should not have to know the frame size. The
+computation of CRC and handling of responses is handled in helpers and
+Manager-specific code.
+
+The host BRA driver may also have restrictions on pages allocated for
+DMA, or other host-DSP communication protocols. The codec driver
+should not be aware of any of these restrictions, since it might be
+reused in combination with different implementations of Manager IPs.
+
+Concurrency between BRA and regular read/write
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The existing 'nread/nwrite' API already relies on a notion of start
+address and number of bytes, so it would be possible to extend this
+API with a 'hint' requesting BPT/BRA be used.
+
+However BRA transfers could be quite long, and the use of a single
+mutex for regular read/write and BRA is a show-stopper. Independent
+operation of the control/command and BRA transfers is a fundamental
+requirement, e.g. to change the volume level with the existing regmap
+interface while downloading firmware. The integration must however
+ensure that there are no concurrent access to the same address with
+the command/control protocol and the BRA protocol.
+
+In addition, the 'sdw_msg' structure hard-codes support for 16-bit
+addresses and paging registers which are irrelevant for BPT/BRA
+support based on native 32-bit addresses. A separate API with
+'sdw_bpt_msg' makes more sense.
+
+One possible strategy to speed-up all initialization tasks would be to
+start a BRA transfer for firmware download, then deal with all the
+"regular" read/writes in parallel with the command channel, and last
+to wait for the BRA transfers to complete. This would allow for a
+degree of overlap instead of a purely sequential solution. As such,
+the BRA API must support async transfers and expose a separate wait
+function.
+
+
+Peripheral/bus interface
+------------------------
+
+The bus interface for BPT/BRA is made of two functions:
+
+ - sdw_bpt_send_async(bpt_message)
+
+ This function sends the data using the Manager
+ implementation-defined capabilities (typically DMA or IPC
+ protocol).
+
+ Queueing is currently not supported, the caller
+ needs to wait for completion of the requested transfer.
+
+ - sdw_bpt_wait()
+
+ This function waits for the entire message provided by the
+ codec driver in the 'send_async' stage. Intermediate status for
+ smaller chunks will not be provided back to the codec driver,
+ only a return code will be provided.
+
+Regmap use
+~~~~~~~~~~
+
+Existing codec drivers rely on regmap to download firmware to
+Peripherals. regmap exposes an async interface similar to the
+send/wait API suggested above, so at a high-level it would seem
+natural to combine BRA and regmap. The regmap layer could check if BRA
+is available or not, and use a regular read-write command channel in
+the latter case.
+
+The regmap integration will be handled in a second step.
+
+BRA stream model
+----------------
+
+For regular audio transfers, the machine driver exposes a dailink
+connecting CPU DAI(s) and Codec DAI(s).
+
+This model is not required BRA support:
+
+ (1) The SoundWire DAIs are mainly wrappers for SoundWire Data
+ Ports, with possibly some analog or audio conversion
+ capabilities bolted behind the Data Port. In the context of
+ BRA, the DP0 is the destination. DP0 registers are standard and
+ can be programmed blindly without knowing what Peripheral is
+ connected to each link. In addition, if there are multiple
+ Peripherals on a link and some of them do not support DP0, the
+ write commands to program DP0 registers will generate harmless
+ COMMAND_IGNORED responses that will be wired-ORed with
+ responses from Peripherals which support DP0. In other words,
+ the DP0 programming can be done with broadcast commands, and
+ the information on the Target device can be added only in the
+ BRA Header.
+
+ (2) At the CPU level, the DAI concept is not useful for BRA; the
+ machine driver will not create a dailink relying on DP0. The
+ only concept that is needed is the notion of port.
+
+ (3) The stream concept relies on a set of master_rt and slave_rt
+ concepts. All of these entities represent ports and not DAIs.
+
+ (4) With the assumption that a single BRA stream is used per link,
+ that stream can connect master ports as well as all peripheral
+ DP0 ports.
+
+ (5) BRA transfers only make sense in the context of one
+ Manager/Link, so the BRA stream handling does not rely on the
+ concept of multi-link aggregation allowed by regular DAI links.
+
+Audio DMA support
+-----------------
+
+Some DMAs, such as HDaudio, require an audio format field to be
+set. This format is in turn used to define acceptable bursts. BPT/BRA
+support is not fully compatible with these definitions in that the
+format and bandwidth may vary between read and write commands.
+
+In addition, on Intel HDaudio Intel platforms the DMAs need to be
+programmed with a PCM format matching the bandwidth of the BPT/BRA
+transfer. The format is based on 192kHz 32-bit samples, and the number
+of channels varies to adjust the bandwidth. The notion of channel is
+completely notional since the data is not typical audio
+PCM. Programming such channels helps reserve enough bandwidth and adjust
+FIFO sizes to avoid xruns.
+
+Alignment requirements are currently not enforced at the core level
+but at the platform-level, e.g. for Intel the data sizes must be
+equal to or larger than 16 bytes.
diff --git a/Documentation/driver-api/soundwire/bra_cadence.rst b/Documentation/driver-api/soundwire/bra_cadence.rst
new file mode 100644
index 000000000000..4560752e8f47
--- /dev/null
+++ b/Documentation/driver-api/soundwire/bra_cadence.rst
@@ -0,0 +1,66 @@
+Cadence IP BRA support
+----------------------
+
+Format requirements
+~~~~~~~~~~~~~~~~~~~
+
+The Cadence IP relies on PDI0 for TX and PDI1 for RX. The data needs
+to be formatted with the following conventions:
+
+ (1) all Data is stored in bits 15..0 of the 32-bit PDI FIFOs.
+
+ (2) the start of packet is BIT(31).
+
+ (3) the end of packet is BIT(30).
+
+ (4) A packet ID is stored in bits 19..16. This packet ID is
+ determined by software and is typically a rolling counter.
+
+ (5) Padding shall be inserted as needed so that the Header CRC,
+ Header response, Footer CRC, Footer response are always in
+ Byte0. Padding is inserted by software for writes, and on reads
+ software shall discard the padding added by the hardware.
+
+Example format
+~~~~~~~~~~~~~~
+
+The following table represents the sequence provided to PDI0 for a
+write command followed by a read command.
+
+::
+
+ +---+---+--------+---------------+---------------+
+ + 1 | 0 | ID = 0 | WR HDR[1] | WR HDR[0] |
+ + | | | WR HDR[3] | WR HDR[2] |
+ + | | | WR HDR[5] | WR HDR[4] |
+ + | | | pad | WR HDR CRC |
+ + | | | WR Data[1] | WR Data[0] |
+ + | | | WR Data[3] | WR Data[2] |
+ + | | | WR Data[n-2] | WR Data[n-3] |
+ + | | | pad | WR Data[n-1] |
+ + 0 | 1 | | pad | WR Data CRC |
+ +---+---+--------+---------------+---------------+
+ + 1 | 0 | ID = 1 | RD HDR[1] | RD HDR[0] |
+ + | | | RD HDR[3] | RD HDR[2] |
+ + | | | RD HDR[5] | RD HDR[4] |
+ + 0 | 1 | | pad | RD HDR CRC |
+ +---+---+--------+---------------+---------------+
+
+
+The table below represents the data received on PDI1 for the same
+write command followed by a read command.
+
+::
+
+ +---+---+--------+---------------+---------------+
+ + 1 | 0 | ID = 0 | pad | WR Hdr Rsp |
+ + 0 | 1 | | pad | WR Ftr Rsp |
+ +---+---+--------+---------------+---------------+
+ + 1 | 0 | ID = 0 | pad | Rd Hdr Rsp |
+ + | | | RD Data[1] | RD Data[0] |
+ + | | | RD Data[3] | RD Data[2] |
+ + | | | RD HDR[n-2] | RD Data[n-3] |
+ + | | | pad | RD Data[n-1] |
+ + | | | pad | RD Data CRC |
+ + 0 | 1 | | pad | RD Ftr Rsp |
+ +---+---+--------+---------------+---------------+
diff --git a/Documentation/driver-api/soundwire/index.rst b/Documentation/driver-api/soundwire/index.rst
index 234911a0db99..ef8d90dfbdde 100644
--- a/Documentation/driver-api/soundwire/index.rst
+++ b/Documentation/driver-api/soundwire/index.rst
@@ -9,6 +9,8 @@ SoundWire Documentation
stream
error_handling
locking
+ bra
+ bra_cadence
.. only:: subproject and html
diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst
index b432a2de45d3..d66201299633 100644
--- a/Documentation/driver-api/soundwire/stream.rst
+++ b/Documentation/driver-api/soundwire/stream.rst
@@ -291,7 +291,7 @@ per stream. From ASoC DPCM framework, this stream state maybe linked to
.. code-block:: c
- int sdw_alloc_stream(char * stream_name);
+ int sdw_alloc_stream(char * stream_name, enum sdw_stream_type type);
The SoundWire core provides a sdw_startup_stream() helper function,
typically called during a dailink .startup() callback, which performs
@@ -324,12 +324,12 @@ framework, this stream state is linked to .hw_params() operation.
int sdw_stream_add_master(struct sdw_bus * bus,
struct sdw_stream_config * stream_config,
- struct sdw_ports_config * ports_config,
+ const struct sdw_ports_config * ports_config,
struct sdw_stream_runtime * stream);
int sdw_stream_add_slave(struct sdw_slave * slave,
struct sdw_stream_config * stream_config,
- struct sdw_ports_config * ports_config,
+ const struct sdw_ports_config * ports_config,
struct sdw_stream_runtime * stream);
diff --git a/Documentation/driver-api/soundwire/summary.rst b/Documentation/driver-api/soundwire/summary.rst
index 01dcb954f6d7..df78053743b5 100644
--- a/Documentation/driver-api/soundwire/summary.rst
+++ b/Documentation/driver-api/soundwire/summary.rst
@@ -184,14 +184,6 @@ function that provides capabilities information. Bus needs to know a set of
Slave capabilities to program Slave registers and to control the Bus
reconfigurations.
-Future enhancements to be done
-==============================
-
- (1) Bulk Register Access (BRA) transfers.
-
-
- (2) Multiple data lane support.
-
Links
=====
diff --git a/Documentation/driver-api/spi.rst b/Documentation/driver-api/spi.rst
index f64cb666498a..74eca6735042 100644
--- a/Documentation/driver-api/spi.rst
+++ b/Documentation/driver-api/spi.rst
@@ -13,7 +13,7 @@ additional chipselect line is usually active-low (nCS); four signals are
normally used for each peripheral, plus sometimes an interrupt.
The SPI bus facilities listed here provide a generalized interface to
-declare SPI busses and devices, manage them according to the standard
+declare SPI buses and devices, manage them according to the standard
Linux driver model, and perform input/output operations. At this time,
only "master" side interfaces are supported, where Linux talks to SPI
peripherals and does not implement such a peripheral itself. (Interfaces
@@ -25,8 +25,8 @@ hardware, which may be as simple as a set of GPIO pins or as complex as
a pair of FIFOs connected to dual DMA engines on the other side of the
SPI shift register (maximizing throughput). Such drivers bridge between
whatever bus they sit on (often the platform bus) and SPI, and expose
-the SPI side of their device as a :c:type:`struct spi_master
-<spi_master>`. SPI devices are children of that master,
+the SPI side of their device as a :c:type:`struct spi_controller
+<spi_controller>`. SPI devices are children of that master,
represented as a :c:type:`struct spi_device <spi_device>` and
manufactured from :c:type:`struct spi_board_info
<spi_board_info>` descriptors which are usually provided by
diff --git a/Documentation/driver-api/surface_aggregator/client.rst b/Documentation/driver-api/surface_aggregator/client.rst
index 27f95abdbe99..e100ab0a24cc 100644
--- a/Documentation/driver-api/surface_aggregator/client.rst
+++ b/Documentation/driver-api/surface_aggregator/client.rst
@@ -19,7 +19,7 @@
.. |ssam_notifier_unregister| replace:: :c:func:`ssam_notifier_unregister`
.. |ssam_device_notifier_register| replace:: :c:func:`ssam_device_notifier_register`
.. |ssam_device_notifier_unregister| replace:: :c:func:`ssam_device_notifier_unregister`
-.. |ssam_request_sync| replace:: :c:func:`ssam_request_sync`
+.. |ssam_request_do_sync| replace:: :c:func:`ssam_request_do_sync`
.. |ssam_event_mask| replace:: :c:type:`enum ssam_event_mask <ssam_event_mask>`
@@ -191,7 +191,7 @@ data received from it is converted from little-endian to host endianness.
* they do not correspond to an actual SAM/EC request.
*/
rqst.target_category = SSAM_SSH_TC_SAM;
- rqst.target_id = 0x01;
+ rqst.target_id = SSAM_SSH_TID_SAM;
rqst.command_id = 0x02;
rqst.instance_id = 0x03;
rqst.flags = SSAM_REQUEST_HAS_RESPONSE;
@@ -209,12 +209,12 @@ data received from it is converted from little-endian to host endianness.
* with the SSAM_REQUEST_HAS_RESPONSE flag set in the specification
* above.
*/
- status = ssam_request_sync(ctrl, &rqst, &resp);
+ status = ssam_request_do_sync(ctrl, &rqst, &resp);
/*
* Alternatively use
*
- * ssam_request_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
+ * ssam_request_do_sync_onstack(ctrl, &rqst, &resp, sizeof(arg_le));
*
* to perform the request, allocating the message buffer directly
* on the stack as opposed to allocation via kzalloc().
@@ -230,7 +230,7 @@ data received from it is converted from little-endian to host endianness.
return status;
}
-Note that |ssam_request_sync| in its essence is a wrapper over lower-level
+Note that |ssam_request_do_sync| in its essence is a wrapper over lower-level
request primitives, which may also be used to perform requests. Refer to its
implementation and documentation for more details.
@@ -241,7 +241,7 @@ one of the generator macros, for example via:
SSAM_DEFINE_SYNC_REQUEST_W(__ssam_tmp_perf_mode_set, __le32, {
.target_category = SSAM_SSH_TC_TMP,
- .target_id = 0x01,
+ .target_id = SSAM_SSH_TID_SAM,
.command_id = 0x03,
.instance_id = 0x00,
});
diff --git a/Documentation/driver-api/surface_aggregator/ssh.rst b/Documentation/driver-api/surface_aggregator/ssh.rst
index bf007d6c9873..58a757319931 100644
--- a/Documentation/driver-api/surface_aggregator/ssh.rst
+++ b/Documentation/driver-api/surface_aggregator/ssh.rst
@@ -13,6 +13,7 @@
.. |DATA_NSQ| replace:: ``DATA_NSQ``
.. |TC| replace:: ``TC``
.. |TID| replace:: ``TID``
+.. |SID| replace:: ``SID``
.. |IID| replace:: ``IID``
.. |RQID| replace:: ``RQID``
.. |CID| replace:: ``CID``
@@ -38,7 +39,7 @@ Note that the standard disclaimer for this subsystem also applies to this
document: All of this has been reverse-engineered and may thus be erroneous
and/or incomplete.
-All CRCs used in the following are two-byte ``crc_ccitt_false(0xffff, ...)``.
+All CRCs used in the following are two-byte ``crc_itu_t(0xffff, ...)``.
All multi-byte values are little-endian, there is no implicit padding between
values.
@@ -76,7 +77,7 @@ after the frame structure and before the payload. The payload is followed by
its own CRC (over all payload bytes). If the payload is not present (i.e.
the frame has ``LEN=0``), the CRC of the payload is still present and will
evaluate to ``0xffff``. The |LEN| field does not include any of the CRCs, it
-equals the number of bytes inbetween the CRC of the frame and the CRC of the
+equals the number of bytes between the CRC of the frame and the CRC of the
payload.
Additionally, the following fixed two-byte sequences are used:
@@ -219,13 +220,13 @@ following fields, packed together and in order:
- |u8|
- Target category.
- * - |TID| (out)
+ * - |TID|
- |u8|
- - Target ID for outgoing (host to EC) commands.
+ - Target ID for commands/messages.
- * - |TID| (in)
+ * - |SID|
- |u8|
- - Target ID for incoming (EC to host) commands.
+ - Source ID for commands/messages.
* - |IID|
- |u8|
@@ -286,19 +287,20 @@ general, however, a single target category should map to a single reserved
event request ID.
Furthermore, requests, responses, and events have an associated target ID
-(``TID``). This target ID is split into output (host to EC) and input (EC to
-host) fields, with the respecting other field (e.g. output field on incoming
-messages) set to zero. Two ``TID`` values are known: Primary (``0x01``) and
-secondary (``0x02``). In general, the response to a request should have the
-same ``TID`` value, however, the field (output vs. input) should be used in
-accordance to the direction in which the response is sent (i.e. on the input
-field, as responses are generally sent from the EC to the host).
-
-Note that, even though requests and events should be uniquely identifiable
-by target category and command ID alone, the EC may require specific
-target ID and instance ID values to accept a command. A command that is
-accepted for ``TID=1``, for example, may not be accepted for ``TID=2``
-and vice versa.
+(``TID``) and source ID (``SID``). These two fields indicate where a message
+originates from (``SID``) and what the intended target of the message is
+(``TID``). Note that a response to a specific request therefore has the source
+and target IDs swapped when compared to the original request (i.e. the request
+target is the response source and the request source is the response target).
+See (:c:type:`enum ssh_request_id <ssh_request_id>`) for possible values of
+both.
+
+Note that, even though requests and events should be uniquely identifiable by
+target category and command ID alone, the EC may require specific target ID and
+instance ID values to accept a command. A command that is accepted for
+``TID=1``, for example, may not be accepted for ``TID=2`` and vice versa. While
+this may not always hold in reality, you can think of different target/source
+IDs indicating different physical ECs with potentially different feature sets.
Limitations and Observations
diff --git a/Documentation/driver-api/tee.rst b/Documentation/driver-api/tee.rst
new file mode 100644
index 000000000000..5eaeb8103988
--- /dev/null
+++ b/Documentation/driver-api/tee.rst
@@ -0,0 +1,66 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+TEE (Trusted Execution Environment) driver API
+===============================================
+
+Kernel provides a TEE bus infrastructure where a Trusted Application is
+represented as a device identified via Universally Unique Identifier (UUID) and
+client drivers register a table of supported device UUIDs.
+
+TEE bus infrastructure registers following APIs:
+
+match():
+ iterates over the client driver UUID table to find a corresponding
+ match for device UUID. If a match is found, then this particular device is
+ probed via corresponding probe API registered by the client driver. This
+ process happens whenever a device or a client driver is registered with TEE
+ bus.
+
+uevent():
+ notifies user-space (udev) whenever a new device is registered on
+ TEE bus for auto-loading of modularized client drivers.
+
+TEE bus device enumeration is specific to underlying TEE implementation, so it
+is left open for TEE drivers to provide corresponding implementation.
+
+Then TEE client driver can talk to a matched Trusted Application using APIs
+listed in include/linux/tee_drv.h.
+
+TEE client driver example
+-------------------------
+
+Suppose a TEE client driver needs to communicate with a Trusted Application
+having UUID: ``ac6a4085-0e82-4c33-bf98-8eb8e118b6c2``, so driver registration
+snippet would look like::
+
+ static const struct tee_client_device_id client_id_table[] = {
+ {UUID_INIT(0xac6a4085, 0x0e82, 0x4c33,
+ 0xbf, 0x98, 0x8e, 0xb8, 0xe1, 0x18, 0xb6, 0xc2)},
+ {}
+ };
+
+ MODULE_DEVICE_TABLE(tee, client_id_table);
+
+ static struct tee_client_driver client_driver = {
+ .id_table = client_id_table,
+ .driver = {
+ .name = DRIVER_NAME,
+ .bus = &tee_bus_type,
+ .probe = client_probe,
+ .remove = client_remove,
+ },
+ };
+
+ static int __init client_init(void)
+ {
+ return driver_register(&client_driver.driver);
+ }
+
+ static void __exit client_exit(void)
+ {
+ driver_unregister(&client_driver.driver);
+ }
+
+ module_init(client_init);
+ module_exit(client_exit);
diff --git a/Documentation/driver-api/thermal/exynos_thermal_emulation.rst b/Documentation/driver-api/thermal/exynos_thermal_emulation.rst
index c21d10838bc5..c679502f01c7 100644
--- a/Documentation/driver-api/thermal/exynos_thermal_emulation.rst
+++ b/Documentation/driver-api/thermal/exynos_thermal_emulation.rst
@@ -28,13 +28,13 @@ changed into it.
delay of changing temperature. However, this node only uses same delay
of real sensing time, 938us.)
-Exynos emulation mode requires synchronous of value changing and
-enabling. It means when you want to update the any value of delay or
-next temperature, then you have to enable emulation mode at the same
-time. (Or you have to keep the mode enabling.) If you don't, it fails to
-change the value to updated one and just use last succeessful value
-repeatedly. That's why this node gives users the right to change
-termerpature only. Just one interface makes it more simply to use.
+Exynos emulation mode requires that value changes and enabling are performed
+synchronously. This means that when you want to update any value, such as the
+delay or the next temperature, you must enable emulation mode at the same
+time (or keep the mode enabled). If you do not, the value will fail to update
+and the last successful value will continue to be used. For this reason,
+this node only allows users to change the temperature. Providing a single
+interface makes it simpler to use.
Disabling emulation mode only requires writing value 0 to sysfs node.
diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst
index 030306ffa408..a886028014ab 100644
--- a/Documentation/driver-api/thermal/index.rst
+++ b/Documentation/driver-api/thermal/index.rst
@@ -14,7 +14,6 @@ Thermal
exynos_thermal
exynos_thermal_emulation
- intel_powerclamp
nouveau_thermal
x86_pkg_temperature_thermal
intel_dptf
diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst
index 372bdb4d04c6..916bf0f36a03 100644
--- a/Documentation/driver-api/thermal/intel_dptf.rst
+++ b/Documentation/driver-api/thermal/intel_dptf.rst
@@ -84,6 +84,9 @@ DPTF ACPI Drivers interface
https:/github.com/intel/thermal_daemon for decoding
thermal table.
+``production_mode`` (RO)
+ When different from zero, manufacturer locked thermal configuration
+ from further changes.
ACPI Thermal Relationship table interface
------------------------------------------
@@ -161,6 +164,16 @@ ABI.
``power_limit_1_tmax_us`` (RO)
Maximum powercap sysfs constraint_1_time_window_us for Intel RAPL
+``power_floor_status`` (RO)
+ When set to 1, the power floor of the system in the current
+ configuration has been reached. It needs to be reconfigured to allow
+ power to be reduced any further.
+
+``power_floor_enable`` (RW)
+ When set to 1, enable reading and notification of the power floor
+ status. Notifications are triggered for the power_floor_status
+ attribute value changes.
+
:file:`/sys/bus/pci/devices/0000\:00\:04.0/`
``tcc_offset_degree_celsius`` (RW)
@@ -178,11 +191,42 @@ ABI.
User space can specify any one of the available workload type using
this interface.
+:file:`/sys/bus/pci/devices/0000\:00\:04.0/ptc_0_control`
+:file:`/sys/bus/pci/devices/0000\:00\:04.0/ptc_1_control`
+:file:`/sys/bus/pci/devices/0000\:00\:04.0/ptc_2_control`
+
+All these controls needs admin privilege to update.
+
+``enable`` (RW)
+ 1 for enable, 0 for disable. Shows the current enable status of
+ platform temperature control feature. User space can enable/disable
+ hardware controls.
+
+``temperature_target`` (RW)
+ Update a new temperature target in milli degree celsius for hardware to
+ use for the temperature control.
+
+``thermal_tolerance`` (RW)
+ This attribute ranges from 0 to 7, where 0 represents
+ the most aggressive control to avoid any temperature overshoots, and
+ 7 represents a more graceful approach, favoring performance even at
+ the expense of temperature overshoots.
+ Note: This level may not scale linearly. For example, a value of 3 does
+ not necessarily imply a 50% improvement in performance compared to a
+ value of 0.
+
+Given that this is platform temperature control, it is expected that a
+single user-level manager owns and manages the controls. If multiple
+user-level software applications attempt to write different targets, it
+can lead to unexpected behavior.
+
+
DPTF Processor thermal RFIM interface
--------------------------------------------
-RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator)
-and DDR (Double Data Rate)frequencies to avoid RF interference with WiFi and 5G.
+RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator),
+DDR (Double Data Rate) and DLVR (Digital Linear Voltage Regulator)
+frequencies to avoid RF interference with WiFi and 5G.
Switching voltage regulators (VR) generate radiated EMI or RFI at the
fundamental frequency and its harmonics. Some harmonics may interfere
@@ -193,6 +237,15 @@ small % and shift away the switching noise harmonic interference from
radio channels. OEM or ODMs can use the driver to control SOC IVR
operation within the range where it does not impact IVR performance.
+Some products use DLVR instead of FIVR as switching voltage regulator.
+In this case attributes of DLVR must be adjusted instead of FIVR.
+
+While shifting the frequencies additional clock noise can be introduced,
+which is compensated by adjusting Spread spectrum percent. This helps
+to reduce the clock noise to meet regulatory compliance. This spreading
+% increases bandwidth of signal transmission and hence reduces the
+effects of interference, noise and signal fading.
+
DRAM devices of DDR IO interface and their power plane can generate EMI
at the data rates. Similar to IVR control mechanism, Intel offers a
mechanism by which DDR data rates can be changed if several conditions
@@ -261,6 +314,38 @@ DVFS attributes
``rfi_disable (RW)``
Disable DDR rate change feature
+DLVR attributes
+
+:file:`/sys/bus/pci/devices/0000\:00\:04.0/dlvr/`
+
+``dlvr_hardware_rev`` (RO)
+ DLVR hardware revision.
+
+``dlvr_freq_mhz`` (RO)
+ Current DLVR PLL frequency in MHz.
+
+``dlvr_freq_select`` (RW)
+ Sets DLVR PLL clock frequency. Once set, and enabled via
+ dlvr_rfim_enable, the dlvr_freq_mhz will show the current
+ DLVR PLL frequency.
+
+``dlvr_pll_busy`` (RO)
+ PLL can't accept frequency change when set.
+
+``dlvr_rfim_enable`` (RW)
+ 0: Disable RF frequency hopping, 1: Enable RF frequency hopping.
+
+``dlvr_spread_spectrum_pct`` (RW)
+ Sets DLVR spread spectrum percent value.
+
+``dlvr_control_mode`` (RW)
+ Specifies how frequencies are spread using spread spectrum.
+ 0: Down spread,
+ 1: Spread in the Center.
+
+``dlvr_control_lock`` (RW)
+ 1: future writes are ignored.
+
DPTF Power supply and Battery Interface
----------------------------------------
@@ -270,3 +355,80 @@ DPTF Fan Control
----------------------------------------
Refer to Documentation/admin-guide/acpi/fan_performance_states.rst
+
+Workload Type Hints
+----------------------------------------
+
+The firmware in Meteor Lake processor generation is capable of identifying
+workload type and passing hints regarding it to the OS. A special sysfs
+interface is provided to allow user space to obtain workload type hints from
+the firmware and control the rate at which they are provided.
+
+User space can poll attribute "workload_type_index" for the current hint or
+can receive a notification whenever the value of this attribute is updated.
+
+file:`/sys/bus/pci/devices/0000:00:04.0/workload_hint/`
+Segment 0, bus 0, device 4, function 0 is reserved for the processor thermal
+device on all Intel client processors. So, the above path doesn't change
+based on the processor generation.
+
+``workload_hint_enable`` (RW)
+ Enable firmware to send workload type hints to user space.
+
+``notification_delay_ms`` (RW)
+ Minimum delay in milliseconds before firmware will notify OS. This is
+ for the rate control of notifications. This delay is between changing
+ the workload type prediction in the firmware and notifying the OS about
+ the change. The default delay is 1024 ms. The delay of 0 is invalid.
+ The delay is rounded up to the nearest power of 2 to simplify firmware
+ programming of the delay value. The read of notification_delay_ms
+ attribute shows the effective value used.
+
+``workload_type_index`` (RO)
+ Predicted workload type index. User space can get notification of
+ change via existing sysfs attribute change notification mechanism.
+
+ The supported index values and their meaning for the Meteor Lake
+ processor generation are as follows:
+
+ 0 - Idle: System performs no tasks, power and idle residency are
+ consistently low for long periods of time.
+
+ 1 – Battery Life: Power is relatively low, but the processor may
+ still be actively performing a task, such as video playback for
+ a long period of time.
+
+ 2 – Sustained: Power level that is relatively high for a long period
+ of time, with very few to no periods of idleness, which will
+ eventually exhaust RAPL Power Limit 1 and 2.
+
+ 3 – Bursty: Consumes a relatively constant average amount of power, but
+ periods of relative idleness are interrupted by bursts of
+ activity. The bursts are relatively short and the periods of
+ relative idleness between them typically prevent RAPL Power
+ Limit 1 from being exhausted.
+
+ 4 – Unknown: Can't classify.
+
+ On processors starting from Panther Lake additional hints are provided.
+ The hardware analyzes workload residencies over an extended period to
+ determine whether the workload classification tends toward idle/battery
+ life states or sustained/performance states. Based on this long-term
+ analysis, it classifies:
+
+ Power Classification: If the workload exhibits more idle or battery life
+ residencies, it is classified as "power".
+
+ Performance Classification: If the workload exhibits more sustained or
+ performance residencies, it is classified as "performance".
+
+ This approach enables applications to ignore short-term workload
+ fluctuations and instead respond to longer-term power vs. performance
+ trends.
+
+ Residency thresholds for this classification are CPU generation-specific.
+ Classification is reported via bit 4 of the workload_type_index:
+
+ Bit 4 = 1: Power classification
+
+ Bit 4 = 0: Performance classification
diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst
index 2e0f79a9e2ee..f73de211bdce 100644
--- a/Documentation/driver-api/thermal/sysfs-api.rst
+++ b/Documentation/driver-api/thermal/sysfs-api.rst
@@ -4,8 +4,6 @@ Generic Thermal Sysfs driver How To
Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com>
-Updated: 2 January 2008
-
Copyright (c) 2008 Intel Corporation
@@ -38,61 +36,57 @@ temperature) and throttle appropriate devices.
::
- struct thermal_zone_device
- *thermal_zone_device_register(char *type,
- int trips, int mask, void *devdata,
- struct thermal_zone_device_ops *ops,
- const struct thermal_zone_params *tzp,
- int passive_delay, int polling_delay))
+ struct thermal_zone_device *
+ thermal_zone_device_register_with_trips(const char *type,
+ const struct thermal_trip *trips,
+ int num_trips, void *devdata,
+ const struct thermal_zone_device_ops *ops,
+ const struct thermal_zone_params *tzp,
+ unsigned int passive_delay,
+ unsigned int polling_delay)
- This interface function adds a new thermal zone device (sensor) to
+ This interface function adds a new thermal zone device (sensor) to the
/sys/class/thermal folder as `thermal_zone[0-*]`. It tries to bind all the
- thermal cooling devices registered at the same time.
+ thermal cooling devices registered to it at the same time.
type:
the thermal zone type.
trips:
- the total number of trip points this thermal zone supports.
- mask:
- Bit string: If 'n'th bit is set, then trip point 'n' is writable.
+ the table of trip points for this thermal zone.
devdata:
device private data
ops:
thermal zone device call-backs.
- .bind:
- bind the thermal zone device with a thermal cooling device.
- .unbind:
- unbind the thermal zone device with a thermal cooling device.
+ .should_bind:
+ check whether or not a given cooling device should be bound to
+ a given trip point in this thermal zone.
.get_temp:
get the current temperature of the thermal zone.
.set_trips:
- set the trip points window. Whenever the current temperature
- is updated, the trip points immediately below and above the
- current temperature are found.
- .get_mode:
- get the current mode (enabled/disabled) of the thermal zone.
-
- - "enabled" means the kernel thermal management is
- enabled.
- - "disabled" will prevent kernel thermal driver action
- upon trip points so that user applications can take
- charge of thermal management.
- .set_mode:
- set the mode (enabled/disabled) of the thermal zone.
- .get_trip_type:
- get the type of certain trip point.
- .get_trip_temp:
- get the temperature above which the certain trip point
- will be fired.
+ set the trip points window. Whenever the current temperature
+ is updated, the trip points immediately below and above the
+ current temperature are found.
+ .change_mode:
+ change the mode (enabled/disabled) of the thermal zone.
+ .set_trip_temp:
+ set the temperature of a given trip point.
+ .get_crit_temp:
+ get the critical temperature for this thermal zone.
.set_emul_temp:
- set the emulation temperature which helps in debugging
- different threshold temperature points.
+ set the emulation temperature which helps in debugging
+ different threshold temperature points.
+ .get_trend:
+ get the trend of most recent zone temperature changes.
+ .hot:
+ hot trip point crossing handler.
+ .critical:
+ critical trip point crossing handler.
tzp:
thermal zone platform parameters.
passive_delay:
- number of milliseconds to wait between polls when
- performing passive cooling.
+ number of milliseconds to wait between polls when performing passive
+ cooling.
polling_delay:
number of milliseconds to wait between polls when checking
whether trip points have been crossed (0 for interrupt driven systems).
@@ -251,97 +245,11 @@ temperature) and throttle appropriate devices.
It deletes the corresponding entry from /sys/class/thermal folder and
unbinds itself from all the thermal zone devices using it.
-1.3 interface for binding a thermal zone device with a thermal cooling device
------------------------------------------------------------------------------
-
- ::
-
- int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
- int trip, struct thermal_cooling_device *cdev,
- unsigned long upper, unsigned long lower, unsigned int weight);
-
- This interface function binds a thermal cooling device to a particular trip
- point of a thermal zone device.
-
- This function is usually called in the thermal zone device .bind callback.
-
- tz:
- the thermal zone device
- cdev:
- thermal cooling device
- trip:
- indicates which trip point in this thermal zone the cooling device
- is associated with.
- upper:
- the Maximum cooling state for this trip point.
- THERMAL_NO_LIMIT means no upper limit,
- and the cooling device can be in max_state.
- lower:
- the Minimum cooling state can be used for this trip point.
- THERMAL_NO_LIMIT means no lower limit,
- and the cooling device can be in cooling state 0.
- weight:
- the influence of this cooling device in this thermal
- zone. See 1.4.1 below for more information.
-
- ::
-
- int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
- int trip, struct thermal_cooling_device *cdev);
-
- This interface function unbinds a thermal cooling device from a particular
- trip point of a thermal zone device. This function is usually called in
- the thermal zone device .unbind callback.
-
- tz:
- the thermal zone device
- cdev:
- thermal cooling device
- trip:
- indicates which trip point in this thermal zone the cooling device
- is associated with.
-
1.4 Thermal Zone Parameters
---------------------------
::
- struct thermal_bind_params
-
- This structure defines the following parameters that are used to bind
- a zone with a cooling device for a particular trip point.
-
- .cdev:
- The cooling device pointer
- .weight:
- The 'influence' of a particular cooling device on this
- zone. This is relative to the rest of the cooling
- devices. For example, if all cooling devices have a
- weight of 1, then they all contribute the same. You can
- use percentages if you want, but it's not mandatory. A
- weight of 0 means that this cooling device doesn't
- contribute to the cooling of this zone unless all cooling
- devices have a weight of 0. If all weights are 0, then
- they all contribute the same.
- .trip_mask:
- This is a bit mask that gives the binding relation between
- this thermal zone and cdev, for a particular trip point.
- If nth bit is set, then the cdev and thermal zone are bound
- for trip point n.
- .binding_limits:
- This is an array of cooling state limits. Must have
- exactly 2 * thermal_zone.number_of_trip_points. It is an
- array consisting of tuples <lower-state upper-state> of
- state limits. Each trip will be associated with one state
- limit tuple when binding. A NULL pointer means
- <THERMAL_NO_LIMITS THERMAL_NO_LIMITS> on all trips.
- These limits are used when binding a cdev to a trip point.
- .match:
- This call back returns success(0) if the 'tz and cdev' need to
- be bound, as per platform data.
-
- ::
-
struct thermal_zone_params
This structure defines the platform level parameters for a thermal zone.
@@ -357,10 +265,6 @@ temperature) and throttle appropriate devices.
will be created. when no_hwmon == true, nothing will be done.
In case the thermal_zone_params is NULL, the hwmon interface
will be created (for backward compatibility).
- .num_tbps:
- Number of thermal_bind_params entries for this zone
- .tbp:
- thermal_bind_params entries
2. sysfs attributes structure
=============================
@@ -411,8 +315,6 @@ Thermal cooling device sys I/F, created once it's registered::
Then next two dynamic attributes are created/removed in pairs. They represent
the relationship between a thermal zone and its associated cooling device.
-They are created/removed for each successful execution of
-thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device.
::
@@ -504,32 +406,28 @@ are supposed to implement the callback. If they don't, the thermal
framework calculated the trend by comparing the previous and the current
temperature values.
-4.2. get_thermal_instance
--------------------------
-
-This function returns the thermal_instance corresponding to a given
-{thermal_zone, cooling_device, trip_point} combination. Returns NULL
-if such an instance does not exist.
-
-4.3. thermal_cdev_update
+4.2. thermal_cdev_update
------------------------
This function serves as an arbitrator to set the state of a cooling
device. It sets the cooling device to the deepest cooling state if
possible.
-5. thermal_emergency_poweroff
-=============================
+5. Critical Events
+==================
+
+On an event of critical trip temperature crossing, the thermal framework
+will trigger a hardware protection power-off (shutdown) or reboot,
+depending on configuration.
-On an event of critical trip temperature crossing the thermal framework
-shuts down the system by calling hw_protection_shutdown(). The
-hw_protection_shutdown() first attempts to perform an orderly shutdown
-but accepts a delay after which it proceeds doing a forced power-off
-or as last resort an emergency_restart.
+At first, the kernel will attempt an orderly power-off or reboot, but
+accepts a delay after which it proceeds to do a forced power-off or
+reboot, respectively. If this fails, ``emergency_restart()`` is invoked
+as last resort.
The delay should be carefully profiled so as to give adequate time for
-orderly poweroff.
+orderly power-off or reboot.
-If the delay is set to 0 emergency poweroff will not be supported. So a
-carefully profiled non-zero positive value is a must for emergency
-poweroff to be triggered.
+If the delay is set to 0, the emergency action will not be supported. So a
+carefully profiled non-zero positive value is a must for the emergency
+action to be triggered.
diff --git a/Documentation/driver-api/tty/console.rst b/Documentation/driver-api/tty/console.rst
new file mode 100644
index 000000000000..4348e36cd33b
--- /dev/null
+++ b/Documentation/driver-api/tty/console.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======
+Console
+=======
+
+.. contents:: :local:
+
+Struct Console
+==============
+
+.. kernel-doc:: include/linux/console.h
+ :identifiers: console cons_flags
+
+Internals
+---------
+
+.. kernel-doc:: include/linux/console.h
+ :identifiers: nbcon_state nbcon_prio nbcon_context nbcon_write_context
+
+Struct Consw
+============
+
+.. kernel-doc:: include/linux/console.h
+ :identifiers: consw
+
+Console functions
+=================
+
+.. kernel-doc:: include/linux/console.h
+ :identifiers: console_srcu_read_flags console_srcu_write_flags
+ console_is_registered for_each_console_srcu for_each_console
+
+.. kernel-doc:: drivers/tty/vt/selection.c
+ :export:
+.. kernel-doc:: drivers/tty/vt/vt.c
+ :export:
+
+Internals
+---------
+
+.. kernel-doc:: drivers/tty/vt/selection.c
+ :internal:
+.. kernel-doc:: drivers/tty/vt/vt.c
+ :internal:
diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst
index 2d32606a4278..c1ffe3d1ec46 100644
--- a/Documentation/driver-api/tty/index.rst
+++ b/Documentation/driver-api/tty/index.rst
@@ -36,7 +36,9 @@ In-detail description of the named TTY structures is in separate documents:
tty_struct
tty_ldisc
tty_buffer
+ tty_ioctl
tty_internals
+ console
Writing TTY Driver
==================
diff --git a/Documentation/driver-api/tty/n_gsm.rst b/Documentation/driver-api/tty/n_gsm.rst
index 35d7381515b0..120317ec990f 100644
--- a/Documentation/driver-api/tty/n_gsm.rst
+++ b/Documentation/driver-api/tty/n_gsm.rst
@@ -25,8 +25,12 @@ Config Initiator
#. Switch the serial line to using the n_gsm line discipline by using
``TIOCSETD`` ioctl.
+#. Configure the mux using ``GSMIOC_GETCONF_EXT``/``GSMIOC_SETCONF_EXT`` ioctl if needed.
+
#. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl.
+#. Configure DLCs using ``GSMIOC_GETCONF_DLCI``/``GSMIOC_SETCONF_DLCI`` ioctl for non-defaults.
+
#. Obtain base gsmtty number for the used serial port.
Major parts of the initialization program
@@ -42,6 +46,8 @@ Config Initiator
int ldisc = N_GSM0710;
struct gsm_config c;
+ struct gsm_config_ext ce;
+ struct gsm_dlci_config dc;
struct termios configuration;
uint32_t first;
@@ -62,6 +68,12 @@ Config Initiator
/* use n_gsm line discipline */
ioctl(fd, TIOCSETD, &ldisc);
+ /* get n_gsm extended configuration */
+ ioctl(fd, GSMIOC_GETCONF_EXT, &ce);
+ /* use keep-alive once every 5s for modem connection supervision */
+ ce.keep_alive = 500;
+ /* set the new extended configuration */
+ ioctl(fd, GSMIOC_SETCONF_EXT, &ce);
/* get n_gsm configuration */
ioctl(fd, GSMIOC_GETCONF, &c);
/* we are initiator and need encoding 0 (basic) */
@@ -72,6 +84,13 @@ Config Initiator
c.mtu = 127;
/* set the new configuration */
ioctl(fd, GSMIOC_SETCONF, &c);
+ /* get DLC 1 configuration */
+ dc.channel = 1;
+ ioctl(fd, GSMIOC_GETCONF_DLCI, &dc);
+ /* the first user channel gets a higher priority */
+ dc.priority = 1;
+ /* set the new DLC 1 specific configuration */
+ ioctl(fd, GSMIOC_SETCONF_DLCI, &dc);
/* get first gsmtty device node */
ioctl(fd, GSMIOC_GETFIRST, &first);
printf("first muxed line: /dev/gsmtty%i\n", first);
@@ -106,8 +125,13 @@ Config Requester
#. Switch the serial line to using the *n_gsm* line discipline by using
``TIOCSETD`` ioctl.
+#. Configure the mux using ``GSMIOC_GETCONF_EXT``/``GSMIOC_SETCONF_EXT``
+ ioctl if needed.
+
#. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl.
+#. Configure DLCs using ``GSMIOC_GETCONF_DLCI``/``GSMIOC_SETCONF_DLCI`` ioctl for non-defaults.
+
#. Obtain base gsmtty number for the used serial port::
#include <stdio.h>
@@ -119,6 +143,8 @@ Config Requester
int ldisc = N_GSM0710;
struct gsm_config c;
+ struct gsm_config_ext ce;
+ struct gsm_dlci_config dc;
struct termios configuration;
uint32_t first;
@@ -132,6 +158,12 @@ Config Requester
/* use n_gsm line discipline */
ioctl(fd, TIOCSETD, &ldisc);
+ /* get n_gsm extended configuration */
+ ioctl(fd, GSMIOC_GETCONF_EXT, &ce);
+ /* use keep-alive once every 5s for peer connection supervision */
+ ce.keep_alive = 500;
+ /* set the new extended configuration */
+ ioctl(fd, GSMIOC_SETCONF_EXT, &ce);
/* get n_gsm configuration */
ioctl(fd, GSMIOC_GETCONF, &c);
/* we are requester and need encoding 0 (basic) */
@@ -142,6 +174,13 @@ Config Requester
c.mtu = 127;
/* set the new configuration */
ioctl(fd, GSMIOC_SETCONF, &c);
+ /* get DLC 1 configuration */
+ dc.channel = 1;
+ ioctl(fd, GSMIOC_GETCONF_DLCI, &dc);
+ /* the first user channel gets a higher priority */
+ dc.priority = 1;
+ /* set the new DLC 1 specific configuration */
+ ioctl(fd, GSMIOC_SETCONF_DLCI, &dc);
/* get first gsmtty device node */
ioctl(fd, GSMIOC_GETFIRST, &first);
printf("first muxed line: /dev/gsmtty%i\n", first);
diff --git a/Documentation/driver-api/tty/tty_buffer.rst b/Documentation/driver-api/tty/tty_buffer.rst
index a39d4781e0d2..4b5ca1776d4f 100644
--- a/Documentation/driver-api/tty/tty_buffer.rst
+++ b/Documentation/driver-api/tty/tty_buffer.rst
@@ -15,10 +15,13 @@ Flip Buffer Management
======================
.. kernel-doc:: drivers/tty/tty_buffer.c
- :identifiers: tty_prepare_flip_string tty_insert_flip_string_fixed_flag
- tty_insert_flip_string_flags __tty_insert_flip_char
+ :identifiers: tty_prepare_flip_string
tty_flip_buffer_push tty_ldisc_receive_buf
+.. kernel-doc:: include/linux/tty_flip.h
+ :identifiers: tty_insert_flip_string_fixed_flag tty_insert_flip_string_flags
+ tty_insert_flip_char
+
----
Other Functions
diff --git a/Documentation/driver-api/tty/tty_driver.rst b/Documentation/driver-api/tty/tty_driver.rst
index cc529f863406..7138222a70f2 100644
--- a/Documentation/driver-api/tty/tty_driver.rst
+++ b/Documentation/driver-api/tty/tty_driver.rst
@@ -25,6 +25,8 @@ freed.
For reference, both allocation and deallocation functions are explained here in
detail:
+.. kernel-doc:: include/linux/tty_driver.h
+ :identifiers: tty_alloc_driver
.. kernel-doc:: drivers/tty/tty_io.c
:identifiers: __tty_alloc_driver tty_driver_kref_put
@@ -35,7 +37,7 @@ Here comes the documentation of flags accepted by tty_alloc_driver() (or
__tty_alloc_driver()):
.. kernel-doc:: include/linux/tty_driver.h
- :doc: TTY Driver Flags
+ :identifiers: tty_driver_flag
----
diff --git a/Documentation/driver-api/tty/tty_ioctl.rst b/Documentation/driver-api/tty/tty_ioctl.rst
new file mode 100644
index 000000000000..3ff1ac5e07f1
--- /dev/null
+++ b/Documentation/driver-api/tty/tty_ioctl.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+TTY IOCTL Helpers
+=================
+
+.. kernel-doc:: drivers/tty/tty_ioctl.c
+
+.. kernel-doc:: include/linux/tty.h
+ :identifiers: tty_get_baud_rate
diff --git a/Documentation/driver-api/tty/tty_port.rst b/Documentation/driver-api/tty/tty_port.rst
index 5cb90e954fcf..504a353f2682 100644
--- a/Documentation/driver-api/tty/tty_port.rst
+++ b/Documentation/driver-api/tty/tty_port.rst
@@ -42,9 +42,10 @@ TTY Refcounting
TTY Helpers
-----------
+.. kernel-doc:: include/linux/tty_port.h
+ :identifiers: tty_port_tty_hangup tty_port_tty_vhangup
.. kernel-doc:: drivers/tty/tty_port.c
- :identifiers: tty_port_tty_hangup tty_port_tty_wakeup
-
+ :identifiers: tty_port_tty_wakeup
Modem Signals
-------------
diff --git a/Documentation/driver-api/tty/tty_struct.rst b/Documentation/driver-api/tty/tty_struct.rst
index c72f5a4293b2..29caf1c1ca5f 100644
--- a/Documentation/driver-api/tty/tty_struct.rst
+++ b/Documentation/driver-api/tty/tty_struct.rst
@@ -72,7 +72,7 @@ TTY Struct Flags
================
.. kernel-doc:: include/linux/tty.h
- :doc: TTY Struct Flags
+ :identifiers: tty_struct_flags
TTY Struct Reference
====================
diff --git a/Documentation/driver-api/usb/anchors.rst b/Documentation/driver-api/usb/anchors.rst
index 4b248e691bd6..5a93d171e76c 100644
--- a/Documentation/driver-api/usb/anchors.rst
+++ b/Documentation/driver-api/usb/anchors.rst
@@ -45,17 +45,6 @@ This function kills all URBs associated with an anchor. The URBs
are called in the reverse temporal order they were submitted.
This way no data can be reordered.
-:c:func:`usb_unlink_anchored_urbs`
-----------------------------------
-
-
-This function unlinks all URBs associated with an anchor. The URBs
-are processed in the reverse temporal order they were submitted.
-This is similar to :c:func:`usb_kill_anchored_urbs`, but it will not sleep.
-Therefore no guarantee is made that the URBs have been unlinked when
-the call returns. They may be unlinked later but will be unlinked in
-finite time.
-
:c:func:`usb_scuttle_anchored_urbs`
-----------------------------------
diff --git a/Documentation/driver-api/usb/callbacks.rst b/Documentation/driver-api/usb/callbacks.rst
index 2b80cf54bcc3..927da49b8f00 100644
--- a/Documentation/driver-api/usb/callbacks.rst
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -99,8 +99,10 @@ The disconnect() callback
This callback is a signal to break any connection with an interface.
You are not allowed any IO to a device after returning from this
callback. You also may not do any other operation that may interfere
-with another driver bound the interface, eg. a power management
-operation.
+with another driver bound to the interface, eg. a power management
+operation. Outstanding operations on the device must be completed or
+aborted before this callback may return.
+
If you are called due to a physical disconnection, all your URBs will be
killed by usbcore. Note that in this case disconnect will be called some
time after the physical disconnection. Thus your driver must be prepared
diff --git a/Documentation/driver-api/usb/dma.rst b/Documentation/driver-api/usb/dma.rst
index d32c27e11b90..02f6825ff830 100644
--- a/Documentation/driver-api/usb/dma.rst
+++ b/Documentation/driver-api/usb/dma.rst
@@ -93,44 +93,18 @@ DMA address space of the device. However, most buffers passed to your
driver can safely be used with such DMA mapping. (See the first section
of Documentation/core-api/dma-api-howto.rst, titled "What memory is DMA-able?")
-- When you're using scatterlists, you can map everything at once. On some
- systems, this kicks in an IOMMU and turns the scatterlists into single
- DMA transactions::
+- When you have the scatterlists which have been mapped for the USB controller,
+ you could use the new ``usb_sg_*()`` calls, which would turn scatterlist
+ into URBs::
- int usb_buffer_map_sg (struct usb_device *dev, unsigned pipe,
- struct scatterlist *sg, int nents);
+ int usb_sg_init(struct usb_sg_request *io, struct usb_device *dev,
+ unsigned pipe, unsigned period, struct scatterlist *sg,
+ int nents, size_t length, gfp_t mem_flags);
- void usb_buffer_dmasync_sg (struct usb_device *dev, unsigned pipe,
- struct scatterlist *sg, int n_hw_ents);
+ void usb_sg_wait(struct usb_sg_request *io);
- void usb_buffer_unmap_sg (struct usb_device *dev, unsigned pipe,
- struct scatterlist *sg, int n_hw_ents);
+ void usb_sg_cancel(struct usb_sg_request *io);
- It's probably easier to use the new ``usb_sg_*()`` calls, which do the DMA
- mapping and apply other tweaks to make scatterlist i/o be fast.
-
-- Some drivers may prefer to work with the model that they're mapping large
- buffers, synchronizing their safe re-use. (If there's no re-use, then let
- usbcore do the map/unmap.) Large periodic transfers make good examples
- here, since it's cheaper to just synchronize the buffer than to unmap it
- each time an urb completes and then re-map it on during resubmission.
-
- These calls all work with initialized urbs: ``urb->dev``, ``urb->pipe``,
- ``urb->transfer_buffer``, and ``urb->transfer_buffer_length`` must all be
- valid when these calls are used (``urb->setup_packet`` must be valid too
- if urb is a control request)::
-
- struct urb *usb_buffer_map (struct urb *urb);
-
- void usb_buffer_dmasync (struct urb *urb);
-
- void usb_buffer_unmap (struct urb *urb);
-
- The calls manage ``urb->transfer_dma`` for you, and set
- ``URB_NO_TRANSFER_DMA_MAP`` so that usbcore won't map or unmap the buffer.
- They cannot be used for setup_packet buffers in control requests.
-
-Note that several of those interfaces are currently commented out, since
-they don't have current users. See the source code. Other than the dmasync
-calls (where the underlying DMA primitives have changed), most of them can
-easily be commented back in if you want to use them.
+ When the USB controller doesn't support DMA, the ``usb_sg_init()`` would try
+ to submit URBs in PIO way as long as the page in scatterlists is not in the
+ Highmem, which could be very rare in modern architectures.
diff --git a/Documentation/driver-api/usb/dwc3.rst b/Documentation/driver-api/usb/dwc3.rst
index 8b36ff11cef9..e3d6a620997f 100644
--- a/Documentation/driver-api/usb/dwc3.rst
+++ b/Documentation/driver-api/usb/dwc3.rst
@@ -18,7 +18,7 @@ controller which can be configured in one of 4 ways:
4. Hub configuration
Linux currently supports several versions of this controller. In all
-likelyhood, the version in your SoC is already supported. At the time
+likelihood, the version in your SoC is already supported. At the time
of this writing, known tested versions range from 2.02a to 3.10a. As a
rule of thumb, anything above 2.02a should work reliably well.
diff --git a/Documentation/driver-api/usb/hotplug.rst b/Documentation/driver-api/usb/hotplug.rst
index c1e13107c50e..12260f704a01 100644
--- a/Documentation/driver-api/usb/hotplug.rst
+++ b/Documentation/driver-api/usb/hotplug.rst
@@ -5,7 +5,7 @@ Linux Hotplugging
=================
-In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
+In hotpluggable buses like USB (and Cardbus PCI), end-users plug devices
into the bus with power on. In most cases, users expect the devices to become
immediately usable. That means the system must do many things, including:
diff --git a/Documentation/driver-api/usb/index.rst b/Documentation/driver-api/usb/index.rst
index cfa8797ea614..fcb24d0500d9 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -3,6 +3,7 @@ Linux USB API
=============
.. toctree::
+ :maxdepth: 1
usb
gadget
diff --git a/Documentation/driver-api/usb/usb.rst b/Documentation/driver-api/usb/usb.rst
index 2c94ff2f4385..7f2f41e80c1c 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -13,7 +13,7 @@ structure, with the host as the root (the system's master), hubs as
interior nodes, and peripherals as leaves (and slaves). Modern PCs
support several such trees of USB devices, usually
a few USB 3.0 (5 GBit/s) or USB 3.1 (10 GBit/s) and some legacy
-USB 2.0 (480 MBit/s) busses just in case.
+USB 2.0 (480 MBit/s) buses just in case.
That master/slave asymmetry was designed-in for a number of reasons, one
being ease of use. It is not physically possible to mistake upstream and
@@ -42,7 +42,7 @@ two. One is intended for *general-purpose* drivers (exposed through
driver frameworks), and the other is for drivers that are *part of the
core*. Such core drivers include the *hub* driver (which manages trees
of USB devices) and several different kinds of *host controller
-drivers*, which control individual busses.
+drivers*, which control individual buses.
The device model seen by USB drivers is relatively complex.
@@ -161,6 +161,7 @@ rely on 64bit DMA to eliminate another kind of bounce buffer.
.. kernel-doc:: drivers/usb/core/urb.c
:export:
+.. c:namespace:: usb_core
.. kernel-doc:: drivers/usb/core/message.c
:export:
@@ -420,6 +421,12 @@ USBDEVFS_CONNECTINFO
know the devnum value already, it's the DDD value of the device file
name.
+USBDEVFS_GET_SPEED
+ Returns the speed of the device. The speed is returned as a
+ numerical value in accordance with enum usb_device_speed
+
+ File modification time is not updated by this request.
+
USBDEVFS_GETDRIVER
Returns the name of the kernel driver bound to a given interface (a
string). Parameter is a pointer to this structure, which is
@@ -771,8 +778,7 @@ Speed may be:
======= ======================================================
1.5 Mbit/s for low speed USB
12 Mbit/s for full speed USB
- 480 Mbit/s for high speed USB (added for USB 2.0);
- also used for Wireless USB, which has no fixed speed
+ 480 Mbit/s for high speed USB (added for USB 2.0)
5000 Mbit/s for SuperSpeed USB (added for USB 3.0)
======= ======================================================
diff --git a/Documentation/driver-api/usb/usb3-debug-port.rst b/Documentation/driver-api/usb/usb3-debug-port.rst
index b9fd131f4723..d4610457b052 100644
--- a/Documentation/driver-api/usb/usb3-debug-port.rst
+++ b/Documentation/driver-api/usb/usb3-debug-port.rst
@@ -48,7 +48,7 @@ kernel boot parameter::
"earlyprintk=xdbc"
If there are multiple xHCI controllers in your system, you can
-append a host contoller index to this kernel parameter. This
+append a host controller index to this kernel parameter. This
index starts from 0.
Current design doesn't support DbC runtime suspend/resume. As
diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
index 10416cc11cd5..b748b9fb1965 100644
--- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst
+++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
@@ -613,7 +613,7 @@ endpoints configuration from the hardware, so we use line 12 instruction
to bypass reading the configuration from silicon, and rely on a
hard-coded table that describes the endpoints configuration instead::
- static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = {
+ static const struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = {
{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, },
{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, },
{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, },
@@ -709,7 +709,7 @@ Resources
USB Home Page: https://www.usb.org
-linux-usb Mailing List Archives: https://marc.info/?l=linux-usb
+linux-usb Mailing List Archives: https://lore.kernel.org/linux-usb
USB On-the-Go Basics:
https://www.maximintegrated.com/app-notes/index.mvp/id/1822
@@ -717,4 +717,4 @@ https://www.maximintegrated.com/app-notes/index.mvp/id/1822
:ref:`Writing USB Device Drivers <writing-usb-driver>`
Texas Instruments USB Configuration Wiki Page:
-http://processors.wiki.ti.com/index.php/Usbgeneralpage
+https://web.archive.org/web/20201215135015/http://processors.wiki.ti.com/index.php/Usbgeneralpage
diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
index f47dca6645aa..bbd548b66b42 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -58,23 +58,17 @@ devices as examples, as these devices are the first devices to use this module::
| MDEV CORE |
| MODULE |
| mdev.ko |
- | +-----------+ | mdev_register_device() +--------------+
+ | +-----------+ | mdev_register_parent() +--------------+
| | | +<------------------------+ |
- | | | | | nvidia.ko |<-> physical
+ | | | | | ccw_device.ko|<-> physical
| | | +------------------------>+ | device
| | | | callbacks +--------------+
| | Physical | |
- | | device | | mdev_register_device() +--------------+
+ | | device | | mdev_register_parent() +--------------+
| | interface | |<------------------------+ |
| | | | | i915.ko |<-> physical
| | | +------------------------>+ | device
| | | | callbacks +--------------+
- | | | |
- | | | | mdev_register_device() +--------------+
- | | | +<------------------------+ |
- | | | | | ccw_device.ko|<-> physical
- | | | +------------------------>+ | device
- | | | | callbacks +--------------+
| +-----------+ |
+---------------+
@@ -103,7 +97,8 @@ structure to represent a mediated device's driver::
struct mdev_driver {
int (*probe) (struct mdev_device *dev);
void (*remove) (struct mdev_device *dev);
- struct attribute_group **supported_type_groups;
+ unsigned int (*get_available)(struct mdev_type *mtype);
+ ssize_t (*show_description)(struct mdev_type *mtype, char *buf);
struct device_driver driver;
};
@@ -125,8 +120,8 @@ vfio_device_ops.
When a driver wants to add the GUID creation sysfs to an existing device it has
probe'd to then it should call::
- int mdev_register_device(struct device *dev,
- struct mdev_driver *mdev_driver);
+ int mdev_register_parent(struct mdev_parent *parent, struct device *dev,
+ struct mdev_driver *mdev_driver);
This will provide the 'mdev_supported_types/XX/create' files which can then be
used to trigger the creation of a mdev_device. The created mdev_device will be
@@ -134,7 +129,7 @@ attached to the specified driver.
When the driver needs to remove itself it calls::
- void mdev_unregister_device(struct device *dev);
+ void mdev_unregister_parent(struct mdev_parent *parent);
Which will unbind and destroy all the created mdevs and remove the sysfs files.
@@ -200,17 +195,14 @@ Directories and files under the sysfs for Each Physical Device
sprintf(buf, "%s-%s", dev_driver_string(parent->dev), group->name);
- (or using mdev_parent_dev(mdev) to arrive at the parent device outside
- of the core mdev code)
-
* device_api
- This attribute should show which device API is being created, for example,
+ This attribute shows which device API is being created, for example,
"vfio-pci" for a PCI device.
* available_instances
- This attribute should show the number of devices of type <type-id> that can be
+ This attribute shows the number of devices of type <type-id> that can be
created.
* [device]
@@ -220,11 +212,11 @@ Directories and files under the sysfs for Each Physical Device
* name
- This attribute should show human readable name. This is optional attribute.
+ This attribute shows a human readable name.
* description
- This attribute should show brief features/description of the type. This is
+ This attribute can show brief features/description of the type. This is an
optional attribute.
Directories and Files Under the sysfs for Each mdev Device
@@ -272,106 +264,6 @@ these callbacks are supported in the TYPE1 IOMMU module. To enable them for
other IOMMU backend modules, such as PPC64 sPAPR module, they need to provide
these two callback functions.
-Using the Sample Code
-=====================
-
-mtty.c in samples/vfio-mdev/ directory is a sample driver program to
-demonstrate how to use the mediated device framework.
-
-The sample driver creates an mdev device that simulates a serial port over a PCI
-card.
-
-1. Build and load the mtty.ko module.
-
- This step creates a dummy device, /sys/devices/virtual/mtty/mtty/
-
- Files in this device directory in sysfs are similar to the following::
-
- # tree /sys/devices/virtual/mtty/mtty/
- /sys/devices/virtual/mtty/mtty/
- |-- mdev_supported_types
- | |-- mtty-1
- | | |-- available_instances
- | | |-- create
- | | |-- device_api
- | | |-- devices
- | | `-- name
- | `-- mtty-2
- | |-- available_instances
- | |-- create
- | |-- device_api
- | |-- devices
- | `-- name
- |-- mtty_dev
- | `-- sample_mtty_dev
- |-- power
- | |-- autosuspend_delay_ms
- | |-- control
- | |-- runtime_active_time
- | |-- runtime_status
- | `-- runtime_suspended_time
- |-- subsystem -> ../../../../class/mtty
- `-- uevent
-
-2. Create a mediated device by using the dummy device that you created in the
- previous step::
-
- # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \
- /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/create
-
-3. Add parameters to qemu-kvm::
-
- -device vfio-pci,\
- sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
-
-4. Boot the VM.
-
- In the Linux guest VM, with no hardware on the host, the device appears
- as follows::
-
- # lspci -s 00:05.0 -xxvv
- 00:05.0 Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])
- Subsystem: Device 4348:3253
- Physical Slot: 5
- Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
- Stepping- SERR- FastB2B- DisINTx-
- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
- <TAbort- <MAbort- >SERR- <PERR- INTx-
- Interrupt: pin A routed to IRQ 10
- Region 0: I/O ports at c150 [size=8]
- Region 1: I/O ports at c158 [size=8]
- Kernel driver in use: serial
- 00: 48 43 53 32 01 00 00 02 10 02 00 07 00 00 00 00
- 10: 51 c1 00 00 59 c1 00 00 00 00 00 00 00 00 00 00
- 20: 00 00 00 00 00 00 00 00 00 00 00 00 48 43 53 32
- 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
-
- In the Linux guest VM, dmesg output for the device is as follows:
-
- serial 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, high) -> IRQ 10
- 0000:00:05.0: ttyS1 at I/O 0xc150 (irq = 10) is a 16550A
- 0000:00:05.0: ttyS2 at I/O 0xc158 (irq = 10) is a 16550A
-
-
-5. In the Linux guest VM, check the serial ports::
-
- # setserial -g /dev/ttyS*
- /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
- /dev/ttyS1, UART: 16550A, Port: 0xc150, IRQ: 10
- /dev/ttyS2, UART: 16550A, Port: 0xc158, IRQ: 10
-
-6. Using minicom or any terminal emulation program, open port /dev/ttyS1 or
- /dev/ttyS2 with hardware flow control disabled.
-
-7. Type data on the minicom terminal or send data to the terminal emulation
- program and read the data.
-
- Data is loop backed from hosts mtty driver.
-
-8. Destroy the mediated device that you created::
-
- # echo 1 > /sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001/remove
-
References
==========
diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst
index c663b6f97825..2a21a42c9386 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -239,29 +239,162 @@ group and can access them as follows::
/* Gratuitous device reset and go... */
ioctl(device, VFIO_DEVICE_RESET);
+IOMMUFD and vfio_iommu_type1
+----------------------------
+
+IOMMUFD is the new user API to manage I/O page tables from userspace.
+It intends to be the portal of delivering advanced userspace DMA
+features (nested translation [5]_, PASID [6]_, etc.) while also providing
+a backwards compatibility interface for existing VFIO_TYPE1v2_IOMMU use
+cases. Eventually the vfio_iommu_type1 driver, as well as the legacy
+vfio container and group model is intended to be deprecated.
+
+The IOMMUFD backwards compatibility interface can be enabled two ways.
+In the first method, the kernel can be configured with
+CONFIG_IOMMUFD_VFIO_CONTAINER, in which case the IOMMUFD subsystem
+transparently provides the entire infrastructure for the VFIO
+container and IOMMU backend interfaces. The compatibility mode can
+also be accessed if the VFIO container interface, ie. /dev/vfio/vfio is
+simply symlink'd to /dev/iommu. Note that at the time of writing, the
+compatibility mode is not entirely feature complete relative to
+VFIO_TYPE1v2_IOMMU (ex. DMA mapping MMIO) and does not attempt to
+provide compatibility to the VFIO_SPAPR_TCE_IOMMU interface. Therefore
+it is not generally advisable at this time to switch from native VFIO
+implementations to the IOMMUFD compatibility interfaces.
+
+Long term, VFIO users should migrate to device access through the cdev
+interface described below, and native access through the IOMMUFD
+provided interfaces.
+
+VFIO Device cdev
+----------------
+
+Traditionally user acquires a device fd via VFIO_GROUP_GET_DEVICE_FD
+in a VFIO group.
+
+With CONFIG_VFIO_DEVICE_CDEV=y the user can now acquire a device fd
+by directly opening a character device /dev/vfio/devices/vfioX where
+"X" is the number allocated uniquely by VFIO for registered devices.
+cdev interface does not support noiommu devices, so user should use
+the legacy group interface if noiommu is wanted.
+
+The cdev only works with IOMMUFD. Both VFIO drivers and applications
+must adapt to the new cdev security model which requires using
+VFIO_DEVICE_BIND_IOMMUFD to claim DMA ownership before starting to
+actually use the device. Once BIND succeeds then a VFIO device can
+be fully accessed by the user.
+
+VFIO device cdev doesn't rely on VFIO group/container/iommu drivers.
+Hence those modules can be fully compiled out in an environment
+where no legacy VFIO application exists.
+
+So far SPAPR does not support IOMMUFD yet. So it cannot support device
+cdev either.
+
+vfio device cdev access is still bound by IOMMU group semantics, ie. there
+can be only one DMA owner for the group. Devices belonging to the same
+group can not be bound to multiple iommufd_ctx or shared between native
+kernel and vfio bus driver or other driver supporting the driver_managed_dma
+flag. A violation of this ownership requirement will fail at the
+VFIO_DEVICE_BIND_IOMMUFD ioctl, which gates full device access.
+
+Device cdev Example
+-------------------
+
+Assume user wants to access PCI device 0000:6a:01.0::
+
+ $ ls /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/
+ vfio0
+
+This device is therefore represented as vfio0. The user can verify
+its existence::
+
+ $ ls -l /dev/vfio/devices/vfio0
+ crw------- 1 root root 511, 0 Feb 16 01:22 /dev/vfio/devices/vfio0
+ $ cat /sys/bus/pci/devices/0000:6a:01.0/vfio-dev/vfio0/dev
+ 511:0
+ $ ls -l /dev/char/511\:0
+ lrwxrwxrwx 1 root root 21 Feb 16 01:22 /dev/char/511:0 -> ../vfio/devices/vfio0
+
+Then provide the user with access to the device if unprivileged
+operation is desired::
+
+ $ chown user:user /dev/vfio/devices/vfio0
+
+Finally the user could get cdev fd by::
+
+ cdev_fd = open("/dev/vfio/devices/vfio0", O_RDWR);
+
+An opened cdev_fd doesn't give the user any permission of accessing
+the device except binding the cdev_fd to an iommufd. After that point
+then the device is fully accessible including attaching it to an
+IOMMUFD IOAS/HWPT to enable userspace DMA::
+
+ struct vfio_device_bind_iommufd bind = {
+ .argsz = sizeof(bind),
+ .flags = 0,
+ };
+ struct iommu_ioas_alloc alloc_data = {
+ .size = sizeof(alloc_data),
+ .flags = 0,
+ };
+ struct vfio_device_attach_iommufd_pt attach_data = {
+ .argsz = sizeof(attach_data),
+ .flags = 0,
+ };
+ struct iommu_ioas_map map = {
+ .size = sizeof(map),
+ .flags = IOMMU_IOAS_MAP_READABLE |
+ IOMMU_IOAS_MAP_WRITEABLE |
+ IOMMU_IOAS_MAP_FIXED_IOVA,
+ .__reserved = 0,
+ };
+
+ iommufd = open("/dev/iommu", O_RDWR);
+
+ bind.iommufd = iommufd;
+ ioctl(cdev_fd, VFIO_DEVICE_BIND_IOMMUFD, &bind);
+
+ ioctl(iommufd, IOMMU_IOAS_ALLOC, &alloc_data);
+ attach_data.pt_id = alloc_data.out_ioas_id;
+ ioctl(cdev_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, &attach_data);
+
+ /* Allocate some space and setup a DMA mapping */
+ map.user_va = (int64_t)mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
+ MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+ map.iova = 0; /* 1MB starting at 0x0 from device view */
+ map.length = 1024 * 1024;
+ map.ioas_id = alloc_data.out_ioas_id;
+
+ ioctl(iommufd, IOMMU_IOAS_MAP, &map);
+
+ /* Other device operations as stated in "VFIO Usage Example" */
+
VFIO User API
-------------------------------------------------------------------------------
-Please see include/linux/vfio.h for complete API documentation.
+Please see include/uapi/linux/vfio.h for complete API documentation.
VFIO bus driver API
-------------------------------------------------------------------------------
VFIO bus drivers, such as vfio-pci make use of only a few interfaces
into VFIO core. When devices are bound and unbound to the driver,
-the driver should call vfio_register_group_dev() and
-vfio_unregister_group_dev() respectively::
+Following interfaces are called when devices are bound to and
+unbound from the driver::
- void vfio_init_group_dev(struct vfio_device *device,
- struct device *dev,
- const struct vfio_device_ops *ops);
- void vfio_uninit_group_dev(struct vfio_device *device);
int vfio_register_group_dev(struct vfio_device *device);
+ int vfio_register_emulated_iommu_dev(struct vfio_device *device);
void vfio_unregister_group_dev(struct vfio_device *device);
-The driver should embed the vfio_device in its own structure and call
-vfio_init_group_dev() to pre-configure it before going to registration
-and call vfio_uninit_group_dev() after completing the un-registration.
+The driver should embed the vfio_device in its own structure and use
+vfio_alloc_device() to allocate the structure, and can register
+@init/@release callbacks to manage any private state wrapping the
+vfio_device::
+
+ vfio_alloc_device(dev_struct, member, dev, ops);
+ void vfio_put_device(struct vfio_device *device);
+
vfio_register_group_dev() indicates to the core to begin tracking the
iommu_group of the specified dev and register the dev as owned by a VFIO bus
driver. Once vfio_register_group_dev() returns it is possible for userspace to
@@ -270,28 +403,66 @@ ready before calling it. The driver provides an ops structure for callbacks
similar to a file operations structure::
struct vfio_device_ops {
- int (*open)(struct vfio_device *vdev);
+ char *name;
+ int (*init)(struct vfio_device *vdev);
void (*release)(struct vfio_device *vdev);
+ int (*bind_iommufd)(struct vfio_device *vdev,
+ struct iommufd_ctx *ictx, u32 *out_device_id);
+ void (*unbind_iommufd)(struct vfio_device *vdev);
+ int (*attach_ioas)(struct vfio_device *vdev, u32 *pt_id);
+ void (*detach_ioas)(struct vfio_device *vdev);
+ int (*open_device)(struct vfio_device *vdev);
+ void (*close_device)(struct vfio_device *vdev);
ssize_t (*read)(struct vfio_device *vdev, char __user *buf,
size_t count, loff_t *ppos);
- ssize_t (*write)(struct vfio_device *vdev,
- const char __user *buf,
- size_t size, loff_t *ppos);
+ ssize_t (*write)(struct vfio_device *vdev, const char __user *buf,
+ size_t count, loff_t *size);
long (*ioctl)(struct vfio_device *vdev, unsigned int cmd,
unsigned long arg);
- int (*mmap)(struct vfio_device *vdev,
- struct vm_area_struct *vma);
+ int (*mmap)(struct vfio_device *vdev, struct vm_area_struct *vma);
+ void (*request)(struct vfio_device *vdev, unsigned int count);
+ int (*match)(struct vfio_device *vdev, char *buf);
+ void (*dma_unmap)(struct vfio_device *vdev, u64 iova, u64 length);
+ int (*device_feature)(struct vfio_device *device, u32 flags,
+ void __user *arg, size_t argsz);
};
Each function is passed the vdev that was originally registered
-in the vfio_register_group_dev() call above. This allows the bus driver
-to obtain its private data using container_of(). The open/release
-callbacks are issued when a new file descriptor is created for a
-device (via VFIO_GROUP_GET_DEVICE_FD). The ioctl interface provides
-a direct pass through for VFIO_DEVICE_* ioctls. The read/write/mmap
-interfaces implement the device region access defined by the device's
-own VFIO_DEVICE_GET_REGION_INFO ioctl.
+in the vfio_register_group_dev() or vfio_register_emulated_iommu_dev()
+call above. This allows the bus driver to obtain its private data using
+container_of().
+
+::
+
+ - The init/release callbacks are issued when vfio_device is initialized
+ and released.
+
+ - The open/close device callbacks are issued when the first
+ instance of a file descriptor for the device is created (eg.
+ via VFIO_GROUP_GET_DEVICE_FD) for a user session.
+
+ - The ioctl callback provides a direct pass through for some VFIO_DEVICE_*
+ ioctls.
+ - The [un]bind_iommufd callbacks are issued when the device is bound to
+ and unbound from iommufd.
+
+ - The [de]attach_ioas callback is issued when the device is attached to
+ and detached from an IOAS managed by the bound iommufd. However, the
+ attached IOAS can also be automatically detached when the device is
+ unbound from iommufd.
+
+ - The read/write/mmap callbacks implement the device region access defined
+ by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl.
+
+ - The request callback is issued when device is going to be unregistered,
+ such as when trying to unbind the device from the vfio bus driver.
+
+ - The dma_unmap callback is issued when a range of iovas are unmapped
+ in the container or IOAS attached by the device. Drivers which make
+ use of the vfio page pinning interface must implement this callback in
+ order to unpin pages within the dma_unmap range. Drivers must tolerate
+ this callback even before calls to open_device().
PPC64 sPAPR implementation note
-------------------------------
@@ -526,3 +697,11 @@ This implementation has some specifics:
\-0d.1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
+
+.. [5] Nested translation is an IOMMU feature which supports two stage
+ address translations. This improves the address translation efficiency
+ in IOMMU virtualization.
+
+.. [6] PASID stands for Process Address Space ID, introduced by PCI
+ Express. It is a prerequisite for Shared Virtual Addressing (SVA)
+ and Scalable I/O Virtualization (Scalable IOV).
diff --git a/Documentation/driver-api/virtio/index.rst b/Documentation/driver-api/virtio/index.rst
new file mode 100644
index 000000000000..528b14b291e3
--- /dev/null
+++ b/Documentation/driver-api/virtio/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======
+Virtio
+======
+
+.. toctree::
+ :maxdepth: 1
+
+ virtio
+ writing_virtio_drivers
diff --git a/Documentation/driver-api/virtio/virtio.rst b/Documentation/driver-api/virtio/virtio.rst
new file mode 100644
index 000000000000..7947b4ca690e
--- /dev/null
+++ b/Documentation/driver-api/virtio/virtio.rst
@@ -0,0 +1,145 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _virtio:
+
+===============
+Virtio on Linux
+===============
+
+Introduction
+============
+
+Virtio is an open standard that defines a protocol for communication
+between drivers and devices of different types, see Chapter 5 ("Device
+Types") of the virtio spec (`[1]`_). Originally developed as a standard
+for paravirtualized devices implemented by a hypervisor, it can be used
+to interface any compliant device (real or emulated) with a driver.
+
+For illustrative purposes, this document will focus on the common case
+of a Linux kernel running in a virtual machine and using paravirtualized
+devices provided by the hypervisor, which exposes them as virtio devices
+via standard mechanisms such as PCI.
+
+
+Device - Driver communication: virtqueues
+=========================================
+
+Although the virtio devices are really an abstraction layer in the
+hypervisor, they're exposed to the guest as if they are physical devices
+using a specific transport method -- PCI, MMIO or CCW -- that is
+orthogonal to the device itself. The virtio spec defines these transport
+methods in detail, including device discovery, capabilities and
+interrupt handling.
+
+The communication between the driver in the guest OS and the device in
+the hypervisor is done through shared memory (that's what makes virtio
+devices so efficient) using specialized data structures called
+virtqueues, which are actually ring buffers [#f1]_ of buffer descriptors
+similar to the ones used in a network device:
+
+.. kernel-doc:: include/uapi/linux/virtio_ring.h
+ :identifiers: struct vring_desc
+
+All the buffers the descriptors point to are allocated by the guest and
+used by the host either for reading or for writing but not for both.
+
+Refer to Chapter 2.5 ("Virtqueues") of the virtio spec (`[1]`_) for the
+reference definitions of virtqueues and "Virtqueues and virtio ring: How
+the data travels" blog post (`[2]`_) for an illustrated overview of how
+the host device and the guest driver communicate.
+
+The :c:type:`vring_virtqueue` struct models a virtqueue, including the
+ring buffers and management data. Embedded in this struct is the
+:c:type:`virtqueue` struct, which is the data structure that's
+ultimately used by virtio drivers:
+
+.. kernel-doc:: include/linux/virtio.h
+ :identifiers: struct virtqueue
+
+The callback function pointed by this struct is triggered when the
+device has consumed the buffers provided by the driver. More
+specifically, the trigger will be an interrupt issued by the hypervisor
+(see vring_interrupt()). Interrupt request handlers are registered for
+a virtqueue during the virtqueue setup process (transport-specific).
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: vring_interrupt
+
+
+Device discovery and probing
+============================
+
+In the kernel, the virtio core contains the virtio bus driver and
+transport-specific drivers like `virtio-pci` and `virtio-mmio`. Then
+there are individual virtio drivers for specific device types that are
+registered to the virtio bus driver.
+
+How a virtio device is found and configured by the kernel depends on how
+the hypervisor defines it. Taking the `QEMU virtio-console
+<https://gitlab.com/qemu-project/qemu/-/blob/master/hw/char/virtio-console.c>`__
+device as an example. When using PCI as a transport method, the device
+will present itself on the PCI bus with vendor 0x1af4 (Red Hat, Inc.)
+and device id 0x1003 (virtio console), as defined in the spec, so the
+kernel will detect it as it would do with any other PCI device.
+
+During the PCI enumeration process, if a device is found to match the
+virtio-pci driver (according to the virtio-pci device table, any PCI
+device with vendor id = 0x1af4)::
+
+ /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF. */
+ static const struct pci_device_id virtio_pci_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
+ { 0 }
+ };
+
+then the virtio-pci driver is probed and, if the probing goes well, the
+device is registered to the virtio bus::
+
+ static int virtio_pci_probe(struct pci_dev *pci_dev,
+ const struct pci_device_id *id)
+ {
+ ...
+
+ if (force_legacy) {
+ rc = virtio_pci_legacy_probe(vp_dev);
+ /* Also try modern mode if we can't map BAR0 (no IO space). */
+ if (rc == -ENODEV || rc == -ENOMEM)
+ rc = virtio_pci_modern_probe(vp_dev);
+ if (rc)
+ goto err_probe;
+ } else {
+ rc = virtio_pci_modern_probe(vp_dev);
+ if (rc == -ENODEV)
+ rc = virtio_pci_legacy_probe(vp_dev);
+ if (rc)
+ goto err_probe;
+ }
+
+ ...
+
+ rc = register_virtio_device(&vp_dev->vdev);
+
+When the device is registered to the virtio bus the kernel will look
+for a driver in the bus that can handle the device and call that
+driver's ``probe`` method.
+
+At this point, the virtqueues will be allocated and configured by
+calling the appropriate ``virtio_find`` helper function, such as
+virtio_find_single_vq() or virtio_find_vqs(), which will end up calling
+a transport-specific ``find_vqs`` method.
+
+
+References
+==========
+
+_`[1]` Virtio Spec v1.2:
+https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html
+
+.. Check for later versions of the spec as well.
+
+_`[2]` Virtqueues and virtio ring: How the data travels
+https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
+
+.. rubric:: Footnotes
+
+.. [#f1] that's why they may be also referred to as virtrings.
diff --git a/Documentation/driver-api/virtio/writing_virtio_drivers.rst b/Documentation/driver-api/virtio/writing_virtio_drivers.rst
new file mode 100644
index 000000000000..e5de6f5d061a
--- /dev/null
+++ b/Documentation/driver-api/virtio/writing_virtio_drivers.rst
@@ -0,0 +1,196 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _writing_virtio_drivers:
+
+======================
+Writing Virtio Drivers
+======================
+
+Introduction
+============
+
+This document serves as a basic guideline for driver programmers that
+need to hack a new virtio driver or understand the essentials of the
+existing ones. See :ref:`Virtio on Linux <virtio>` for a general
+overview of virtio.
+
+
+Driver boilerplate
+==================
+
+As a bare minimum, a virtio driver needs to register in the virtio bus
+and configure the virtqueues for the device according to its spec, the
+configuration of the virtqueues in the driver side must match the
+virtqueue definitions in the device. A basic driver skeleton could look
+like this::
+
+ #include <linux/virtio.h>
+ #include <linux/virtio_ids.h>
+ #include <linux/virtio_config.h>
+ #include <linux/module.h>
+
+ /* device private data (one per device) */
+ struct virtio_dummy_dev {
+ struct virtqueue *vq;
+ };
+
+ static void virtio_dummy_recv_cb(struct virtqueue *vq)
+ {
+ struct virtio_dummy_dev *dev = vq->vdev->priv;
+ char *buf;
+ unsigned int len;
+
+ while ((buf = virtqueue_get_buf(dev->vq, &len)) != NULL) {
+ /* process the received data */
+ }
+ }
+
+ static int virtio_dummy_probe(struct virtio_device *vdev)
+ {
+ struct virtio_dummy_dev *dev = NULL;
+
+ /* initialize device data */
+ dev = kzalloc(sizeof(struct virtio_dummy_dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ /* the device has a single virtqueue */
+ dev->vq = virtio_find_single_vq(vdev, virtio_dummy_recv_cb, "input");
+ if (IS_ERR(dev->vq)) {
+ kfree(dev);
+ return PTR_ERR(dev->vq);
+
+ }
+ vdev->priv = dev;
+
+ /* from this point on, the device can notify and get callbacks */
+ virtio_device_ready(vdev);
+
+ return 0;
+ }
+
+ static void virtio_dummy_remove(struct virtio_device *vdev)
+ {
+ struct virtio_dummy_dev *dev = vdev->priv;
+
+ /*
+ * disable vq interrupts: equivalent to
+ * vdev->config->reset(vdev)
+ */
+ virtio_reset_device(vdev);
+
+ /* detach unused buffers */
+ while ((buf = virtqueue_detach_unused_buf(dev->vq)) != NULL) {
+ kfree(buf);
+ }
+
+ /* remove virtqueues */
+ vdev->config->del_vqs(vdev);
+
+ kfree(dev);
+ }
+
+ static const struct virtio_device_id id_table[] = {
+ { VIRTIO_ID_DUMMY, VIRTIO_DEV_ANY_ID },
+ { 0 },
+ };
+
+ static struct virtio_driver virtio_dummy_driver = {
+ .driver.name = KBUILD_MODNAME,
+ .id_table = id_table,
+ .probe = virtio_dummy_probe,
+ .remove = virtio_dummy_remove,
+ };
+
+ module_virtio_driver(virtio_dummy_driver);
+ MODULE_DEVICE_TABLE(virtio, id_table);
+ MODULE_DESCRIPTION("Dummy virtio driver");
+ MODULE_LICENSE("GPL");
+
+The device id ``VIRTIO_ID_DUMMY`` here is a placeholder, virtio drivers
+should be added only for devices that are defined in the spec, see
+include/uapi/linux/virtio_ids.h. Device ids need to be at least reserved
+in the virtio spec before being added to that file.
+
+If your driver doesn't have to do anything special in its ``init`` and
+``exit`` methods, you can use the module_virtio_driver() helper to
+reduce the amount of boilerplate code.
+
+The ``probe`` method does the minimum driver setup in this case
+(memory allocation for the device data) and initializes the
+virtqueue. virtio_device_ready() is used to enable the virtqueue and to
+notify the device that the driver is ready to manage the device
+("DRIVER_OK"). The virtqueues are anyway enabled automatically by the
+core after ``probe`` returns.
+
+.. kernel-doc:: include/linux/virtio_config.h
+ :identifiers: virtio_device_ready
+
+In any case, the virtqueues need to be enabled before adding buffers to
+them.
+
+Sending and receiving data
+==========================
+
+The virtio_dummy_recv_cb() callback in the code above will be triggered
+when the device notifies the driver after it finishes processing a
+descriptor or descriptor chain, either for reading or writing. However,
+that's only the second half of the virtio device-driver communication
+process, as the communication is always started by the driver regardless
+of the direction of the data transfer.
+
+To configure a buffer transfer from the driver to the device, first you
+have to add the buffers -- packed as `scatterlists` -- to the
+appropriate virtqueue using any of the virtqueue_add_inbuf(),
+virtqueue_add_outbuf() or virtqueue_add_sgs(), depending on whether you
+need to add one input `scatterlist` (for the device to fill in), one
+output `scatterlist` (for the device to consume) or multiple
+`scatterlists`, respectively. Then, once the virtqueue is set up, a call
+to virtqueue_kick() sends a notification that will be serviced by the
+hypervisor that implements the device::
+
+ struct scatterlist sg[1];
+ sg_init_one(sg, buffer, BUFLEN);
+ virtqueue_add_inbuf(dev->vq, sg, 1, buffer, GFP_ATOMIC);
+ virtqueue_kick(dev->vq);
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_add_inbuf
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_add_outbuf
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_add_sgs
+
+Then, after the device has read or written the buffers prepared by the
+driver and notifies it back, the driver can call virtqueue_get_buf() to
+read the data produced by the device (if the virtqueue was set up with
+input buffers) or simply to reclaim the buffers if they were already
+consumed by the device:
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_get_buf_ctx
+
+The virtqueue callbacks can be disabled and re-enabled using the
+virtqueue_disable_cb() and the family of virtqueue_enable_cb() functions
+respectively. See drivers/virtio/virtio_ring.c for more details:
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_disable_cb
+
+.. kernel-doc:: drivers/virtio/virtio_ring.c
+ :identifiers: virtqueue_enable_cb
+
+But note that some spurious callbacks can still be triggered under
+certain scenarios. The way to disable callbacks reliably is to reset the
+device or the virtqueue (virtio_reset_device()).
+
+
+References
+==========
+
+_`[1]` Virtio Spec v1.2:
+https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html
+
+Check for later versions of the spec as well.
diff --git a/Documentation/driver-api/wbrf.rst b/Documentation/driver-api/wbrf.rst
new file mode 100644
index 000000000000..6b18833e2e69
--- /dev/null
+++ b/Documentation/driver-api/wbrf.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+=================================
+WBRF - Wifi Band RFI Mitigations
+=================================
+
+Due to electrical and mechanical constraints in certain platform designs
+there may be likely interference of relatively high-powered harmonics of
+the GPU memory clocks with local radio module frequency bands used by
+certain Wifi bands.
+
+To mitigate possible RFI interference producers can advertise the
+frequencies in use and consumers can use this information to avoid using
+these frequencies for sensitive features.
+
+When a platform is known to have this issue with any contained devices,
+the platform designer will advertise the availability of this feature via
+ACPI devices with a device specific method (_DSM).
+* Producers with this _DSM will be able to advertise the frequencies in use.
+* Consumers with this _DSM will be able to register for notifications of
+frequencies in use.
+
+Some general terms
+==================
+
+Producer: such component who can produce high-powered radio frequency
+Consumer: such component who can adjust its in-use frequency in
+response to the radio frequencies of other components to mitigate the
+possible RFI.
+
+To make the mechanism function, those producers should notify active use
+of their particular frequencies so that other consumers can make relative
+internal adjustments as necessary to avoid this resonance.
+
+ACPI interface
+==============
+
+Although initially used by for wifi + dGPU use cases, the ACPI interface
+can be scaled to any type of device that a platform designer discovers
+can cause interference.
+
+The GUID used for the _DSM is 7B7656CF-DC3D-4C1C-83E9-66E721DE3070.
+
+3 functions are available in this _DSM:
+
+* 0: discover # of functions available
+* 1: record RF bands in use
+* 2: retrieve RF bands in use
+
+Driver programming interface
+============================
+
+.. kernel-doc:: drivers/platform/x86/amd/wbrf.c
+
+Sample Usage
+=============
+
+The expected flow for the producers:
+1. During probe, call `acpi_amd_wbrf_supported_producer` to check if WBRF
+can be enabled for the device.
+2. On using some frequency band, call `acpi_amd_wbrf_add_remove` with 'add'
+param to get other consumers properly notified.
+3. Or on stopping using some frequency band, call
+`acpi_amd_wbrf_add_remove` with 'remove' param to get other consumers notified.
+
+The expected flow for the consumers:
+1. During probe, call `acpi_amd_wbrf_supported_consumer` to check if WBRF
+can be enabled for the device.
+2. Call `amd_wbrf_register_notifier` to register for notification
+of frequency band change(add or remove) from other producers.
+3. Call the `amd_wbrf_retrieve_freq_band` initially to retrieve
+current active frequency bands considering some producers may broadcast
+such information before the consumer is up.
+4. On receiving a notification for frequency band change, run
+`amd_wbrf_retrieve_freq_band` again to retrieve the latest
+active frequency bands.
+5. During driver cleanup, call `amd_wbrf_unregister_notifier` to
+unregister the notifier.
diff --git a/Documentation/driver-api/wmi.rst b/Documentation/driver-api/wmi.rst
new file mode 100644
index 000000000000..db835b43c937
--- /dev/null
+++ b/Documentation/driver-api/wmi.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==============
+WMI Driver API
+==============
+
+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
+considered to be deprecated, so new WMI drivers should generally avoid it since
+it has some issues with multiple WMI devices sharing the same GUID.
+The modern bus-based interface instead maps each WMI device to a
+:c:type:`struct wmi_device <wmi_device>`, so it supports WMI devices sharing the
+same GUID. Drivers can then register a :c:type:`struct wmi_driver <wmi_driver>`
+which will be bound to compatible WMI devices by the driver core.
+
+.. kernel-doc:: include/linux/wmi.h
+ :internal:
+
+.. kernel-doc:: drivers/platform/wmi/core.c
+ :export:
diff --git a/Documentation/edac/features.rst b/Documentation/edac/features.rst
new file mode 100644
index 000000000000..3f283de297c7
--- /dev/null
+++ b/Documentation/edac/features.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later
+
+=================
+EDAC/RAS features
+=================
+
+Copyright (c) 2024-2025 HiSilicon Limited.
+
+:Author: Shiju Jose <shiju.jose@huawei.com>
+:License: The GNU Free Documentation License, Version 1.2 without
+ Invariant Sections, Front-Cover Texts nor Back-Cover Texts.
+ (dual licensed under the GPL v2)
+
+- Written for: 6.15
+
+Introduction
+------------
+
+EDAC/RAS components plugging and high-level design:
+
+1. Scrub control
+
+2. Error Check Scrub (ECS) control
+
+3. ACPI RAS2 features
+
+4. Post Package Repair (PPR) control
+
+5. Memory Sparing Repair control
+
+High level design is illustrated in the following diagram::
+
+ +-----------------------------------------------+
+ | Userspace - Rasdaemon |
+ | +-------------+ |
+ | | RAS CXL mem | +---------------+ |
+ | |error handler|---->| | |
+ | +-------------+ | RAS dynamic | |
+ | +-------------+ | scrub, memory | |
+ | | RAS memory |---->| repair control| |
+ | |error handler| +----|----------+ |
+ | +-------------+ | |
+ +--------------------------|--------------------+
+ |
+ |
+ +-------------------------------|------------------------------+
+ | Kernel EDAC extension for | controlling RAS Features |
+ |+------------------------------|----------------------------+ |
+ || EDAC Core Sysfs EDAC| Bus | |
+ || +--------------------------|---------------------------+| |
+ || |/sys/bus/edac/devices/<dev>/scrubX/ | | EDAC device || |
+ || |/sys/bus/edac/devices/<dev>/ecsX/ |<->| EDAC MC || |
+ || |/sys/bus/edac/devices/<dev>/repairX | | EDAC sysfs || |
+ || +---------------------------|--------------------------+| |
+ || EDAC|Bus | |
+ || | | |
+ || +----------+ Get feature | Get feature | |
+ || | | desc +---------|------+ desc +----------+ | |
+ || |EDAC scrub|<-----| EDAC device | | | | |
+ || +----------+ | driver- RAS |----->| EDAC mem | | |
+ || +----------+ | feature control| | repair | | |
+ || | |<-----| | +----------+ | |
+ || |EDAC ECS | +---------|------+ | |
+ || +----------+ Register RAS|features | |
+ || ______________________|_____________ | |
+ |+---------|---------------|------------------|--------------+ |
+ | +-------|----+ +-------|-------+ +----|----------+ |
+ | | | | CXL mem driver| | Client driver | |
+ | | ACPI RAS2 | | scrub, ECS, | | memory repair | |
+ | | driver | | sparing, PPR | | features | |
+ | +-----|------+ +-------|-------+ +------|--------+ |
+ | | | | |
+ +--------|-----------------|--------------------|--------------+
+ | | |
+ +--------|-----------------|--------------------|--------------+
+ | +---|-----------------|--------------------|-------+ |
+ | | | |
+ | | Platform HW and Firmware | |
+ | +--------------------------------------------------+ |
+ +--------------------------------------------------------------+
+
+
+1. EDAC Features components - Create feature-specific descriptors. For
+ example: scrub, ECS, memory repair in the above diagram.
+
+2. EDAC device driver for controlling RAS Features - Get feature's attribute
+ descriptors from EDAC RAS feature component and registers device's RAS
+ features with EDAC bus and expose the features control attributes via
+ sysfs. For example, /sys/bus/edac/devices/<dev-name>/<feature>X/
+
+3. RAS dynamic feature controller - Userspace sample modules in rasdaemon for
+ dynamic scrub/repair control to issue scrubbing/repair when excess number
+ of corrected memory errors are reported in a short span of time.
+
+RAS features
+------------
+1. Memory Scrub
+
+Memory scrub features are documented in `Documentation/edac/scrub.rst`.
+
+2. Memory Repair
+
+Memory repair features are documented in `Documentation/edac/memory_repair.rst`.
diff --git a/Documentation/edac/index.rst b/Documentation/edac/index.rst
new file mode 100644
index 000000000000..420c6601dbae
--- /dev/null
+++ b/Documentation/edac/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later
+
+==============
+EDAC Subsystem
+==============
+
+.. toctree::
+ :maxdepth: 1
+
+ features
+ memory_repair
+ scrub
diff --git a/Documentation/edac/memory_repair.rst b/Documentation/edac/memory_repair.rst
new file mode 100644
index 000000000000..5f8da7c9b186
--- /dev/null
+++ b/Documentation/edac/memory_repair.rst
@@ -0,0 +1,152 @@
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later
+
+==========================
+EDAC Memory Repair Control
+==========================
+
+Copyright (c) 2024-2025 HiSilicon Limited.
+
+:Author: Shiju Jose <shiju.jose@huawei.com>
+:License: The GNU Free Documentation License, Version 1.2 without
+ Invariant Sections, Front-Cover Texts nor Back-Cover Texts.
+ (dual licensed under the GPL v2)
+:Original Reviewers:
+
+- Written for: 6.15
+
+Introduction
+------------
+
+Some memory devices support repair operations to address issues in their
+memory media. Post Package Repair (PPR) and memory sparing are examples of
+such features.
+
+Post Package Repair (PPR)
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Post Package Repair is a maintenance operation which requests the memory
+device to perform repair operation on its media. It is a memory self-healing
+feature that fixes a failing memory location by replacing it with a spare row
+in a DRAM device.
+
+For example, a CXL memory device with DRAM components that support PPR
+features implements maintenance operations. DRAM components support those
+types of PPR functions:
+
+ - hard PPR, for a permanent row repair, and
+ - soft PPR, for a temporary row repair.
+
+Soft PPR is much faster than hard PPR, but the repair is lost after a power
+cycle.
+
+The data may not be retained and memory requests may not be correctly
+processed during a repair operation. In such case, the repair operation should
+not be executed at runtime.
+
+For example, for CXL memory devices, see CXL spec rev 3.1 [1]_ sections
+8.2.9.7.1.1 PPR Maintenance Operations, 8.2.9.7.1.2 sPPR Maintenance Operation
+and 8.2.9.7.1.3 hPPR Maintenance Operation for more details.
+
+Memory Sparing
+~~~~~~~~~~~~~~
+
+Memory sparing is a repair function that replaces a portion of memory with
+a portion of functional memory at a particular granularity. Memory
+sparing has cacheline/row/bank/rank sparing granularities. For example, in
+rank memory-sparing mode, one memory rank serves as a spare for other ranks on
+the same channel in case they fail.
+
+The spare rank is held in reserve and not used as active memory until
+a failure is indicated, with reserved capacity subtracted from the total
+available memory in the system.
+
+After an error threshold is surpassed in a system protected by memory sparing,
+the content of a failing rank of DIMMs is copied to the spare rank. The
+failing rank is then taken offline and the spare rank placed online for use as
+active memory in place of the failed rank.
+
+For example, CXL memory devices can support various subclasses for sparing
+operation vary in terms of the scope of the sparing being performed.
+
+Cacheline sparing subclass refers to a sparing action that can replace a full
+cacheline. Row sparing is provided as an alternative to PPR sparing functions
+and its scope is that of a single DDR row. Bank sparing allows an entire bank
+to be replaced. Rank sparing is defined as an operation in which an entire DDR
+rank is replaced.
+
+See CXL spec 3.1 [1]_ section 8.2.9.7.1.4 Memory Sparing Maintenance
+Operations for more details.
+
+.. [1] https://computeexpresslink.org/cxl-specification/
+
+Use cases of generic memory repair features control
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1. The soft PPR, hard PPR and memory-sparing features share similar control
+ attributes. Therefore, there is a need for a standardized, generic sysfs
+ repair control that is exposed to userspace and used by administrators,
+ scripts and tools.
+
+2. When a CXL device detects an error in a memory component, it informs the
+ host of the need for a repair maintenance operation by using an event
+ record where the "maintenance needed" flag is set. The event record
+ specifies the device physical address (DPA) and attributes of the memory
+ that requires repair. The kernel reports the corresponding CXL general
+ media or DRAM trace event to userspace, and userspace tools (e.g.
+ rasdaemon) initiate a repair maintenance operation in response to the
+ device request using the sysfs repair control.
+
+3. Userspace tools, such as rasdaemon, request a repair operation on a memory
+ region when maintenance need flag set or an uncorrected memory error or
+ excess of corrected memory errors above a threshold value is reported or an
+ exceed corrected errors threshold flag set for that memory.
+
+4. Multiple PPR/sparing instances may be present per memory device.
+
+5. Drivers should enforce that live repair is safe. In systems where memory
+ mapping functions can change between boots, one approach to this is to log
+ memory errors seen on this boot against which to check live memory repair
+ requests.
+
+The File System
+---------------
+
+The control attributes of a registered memory repair instance could be
+accessed in the /sys/bus/edac/devices/<dev-name>/mem_repairX/
+
+sysfs
+-----
+
+Sysfs files are documented in
+`Documentation/ABI/testing/sysfs-edac-memory-repair`.
+
+Examples
+--------
+
+The memory repair usage takes the form shown in this example:
+
+1. CXL memory sparing
+
+Memory sparing is defined as a repair function that replaces a portion of
+memory with a portion of functional memory at that same DPA. The subclass
+for this operation, cacheline/row/bank/rank sparing, vary in terms of the
+scope of the sparing being performed.
+
+Memory sparing maintenance operations may be supported by CXL devices that
+implement CXL.mem protocol. A sparing maintenance operation requests the
+CXL device to perform a repair operation on its media. For example, a CXL
+device with DRAM components that support memory sparing features may
+implement sparing maintenance operations.
+
+2. CXL memory Soft Post Package Repair (sPPR)
+
+Post Package Repair (PPR) maintenance operations may be supported by CXL
+devices that implement CXL.mem protocol. A PPR maintenance operation
+requests the CXL device to perform a repair operation on its media.
+For example, a CXL device with DRAM components that support PPR features
+may implement PPR Maintenance operations. Soft PPR (sPPR) is a temporary
+row repair. Soft PPR may be faster, but the repair is lost with a power
+cycle.
+
+Sysfs files for memory repair are documented in
+`Documentation/ABI/testing/sysfs-edac-memory-repair`
diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst
new file mode 100644
index 000000000000..2cfa74fa1ffd
--- /dev/null
+++ b/Documentation/edac/scrub.rst
@@ -0,0 +1,342 @@
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later
+
+=============
+Scrub Control
+=============
+
+Copyright (c) 2024-2025 HiSilicon Limited.
+
+:Author: Shiju Jose <shiju.jose@huawei.com>
+:License: The GNU Free Documentation License, Version 1.2 without
+ Invariant Sections, Front-Cover Texts nor Back-Cover Texts.
+ (dual licensed under the GPL v2)
+
+- Written for: 6.15
+
+Introduction
+------------
+
+Increasing DRAM size and cost have made memory subsystem reliability an
+important concern. These modules are used where potentially corrupted data
+could cause expensive or fatal issues. Memory errors are among the top
+hardware failures that cause server and workload crashes.
+
+Memory scrubbing is a feature where an ECC (Error-Correcting Code) engine
+reads data from each memory media location, corrects if necessary and writes
+the corrected data back to the same memory media location.
+
+DIMMs can be scrubbed at a configurable rate to detect uncorrected memory
+errors and attempt recovery from detected errors, providing the following
+benefits:
+
+1. Proactively scrubbing DIMMs reduces the chance of a correctable error
+ becoming uncorrectable.
+
+2. When detected, uncorrected errors caught in unallocated memory pages are
+ isolated and prevented from being allocated to an application or the OS.
+
+3. This reduces the likelihood of software or hardware products encountering
+ memory errors.
+
+4. The additional data on failures in memory may be used to build up
+ statistics that are later used to decide whether to use memory repair
+ technologies such as Post Package Repair or Sparing.
+
+There are 2 types of memory scrubbing:
+
+1. Background (patrol) scrubbing while the DRAM is otherwise idle.
+
+2. On-demand scrubbing for a specific address range or region of memory.
+
+Several types of interfaces to hardware memory scrubbers have been
+identified, such as CXL memory device patrol scrub, CXL DDR5 ECS, ACPI
+RAS2 memory scrubbing, and ACPI NVDIMM ARS (Address Range Scrub).
+
+The control mechanisms vary across different memory scrubbers. To enable
+standardized userspace tooling, there is a need to present these controls
+through a standardized ABI.
+
+A generic memory EDAC scrub control allows users to manage underlying
+scrubbers in the system through a standardized sysfs control interface. It
+abstracts the management of various scrubbing functionalities into a unified
+set of functions.
+
+Use cases of common scrub control feature
+-----------------------------------------
+
+1. Several types of interfaces for hardware memory scrubbers have been
+ identified, including the CXL memory device patrol scrub, CXL DDR5 ECS,
+ ACPI RAS2 memory scrubbing features, ACPI NVDIMM ARS (Address Range Scrub),
+ and software-based memory scrubbers.
+
+ Of the identified interfaces to hardware memory scrubbers some support
+ control over patrol (background) scrubbing (e.g., ACPI RAS2, CXL) and/or
+ on-demand scrubbing (e.g., ACPI RAS2, ACPI ARS). However, the scrub control
+ interfaces vary between memory scrubbers, highlighting the need for
+ a standardized, generic sysfs scrub control interface that is accessible to
+ userspace for administration and use by scripts/tools.
+
+2. User-space scrub controls allow users to disable scrubbing if necessary,
+ for example, to disable background patrol scrubbing or adjust the scrub
+ rate for performance-aware operations where background activities need to
+ be minimized or disabled.
+
+3. User-space tools enable on-demand scrubbing for specific address ranges,
+ provided that the scrubber supports this functionality.
+
+4. User-space tools can also control memory DIMM scrubbing at a configurable
+ scrub rate via sysfs scrub controls. This approach offers several benefits:
+
+ 4.1. Detects uncorrectable memory errors early, before user access to affected
+ memory, helping facilitate recovery.
+
+ 4.2. Reduces the likelihood of correctable errors developing into uncorrectable
+ errors.
+
+5. Policy control for hotplugged memory is necessary because there may not
+ be a system-wide BIOS or similar control to manage scrub settings for a CXL
+ device added after boot. Determining these settings is a policy decision,
+ balancing reliability against performance, so userspace should control it.
+ Therefore, a unified interface is recommended for handling this function in
+ a way that aligns with other similar interfaces, rather than creating a
+ separate one.
+
+Scrubbing features
+------------------
+
+CXL Memory Scrubbing features
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CXL spec r3.1 [1]_ section 8.2.9.9.11.1 describes the memory device patrol
+scrub control feature. The device patrol scrub proactively locates and makes
+corrections to errors in regular cycle. The patrol scrub control allows the
+userspace request to change CXL patrol scrubber's configurations.
+
+The patrol scrub control allows the requester to specify the number of
+hours in which the patrol scrub cycles must be completed, provided that
+the requested scrub rate must be within the supported range of the
+scrub rate that the device is capable of. In the CXL driver, the
+number of seconds per scrub cycles, which user requests via sysfs, is
+rescaled to hours per scrub cycles.
+
+In addition, they allow the host to disable the feature in case it interferes
+with performance-aware operations which require the background operations to
+be turned off.
+
+Error Check Scrub (ECS)
+~~~~~~~~~~~~~~~~~~~~~~~
+
+CXL spec r3.1 [1]_ section 8.2.9.9.11.2 describes Error Check Scrub (ECS)
+- a feature defined in the JEDEC DDR5 SDRAM Specification (JESD79-5) and
+allowing DRAM to internally read, correct single-bit errors, and write back
+corrected data bits to the DRAM array while providing transparency to error
+counts.
+
+The DDR5 device contains number of memory media Field Replaceable Units (FRU)
+per device. The DDR5 ECS feature and thus the ECS control driver supports
+configuring the ECS parameters per FRU.
+
+ACPI RAS2 Hardware-based Memory Scrubbing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ACPI spec 6.5 [2]_ section 5.2.21 ACPI RAS2 describes an ACPI RAS2 table
+which provides interfaces for platform RAS features and supports independent
+RAS controls and capabilities for a given RAS feature for multiple instances
+of the same component in a given system.
+
+Memory RAS features apply to RAS capabilities, controls and operations that
+are specific to memory. RAS2 PCC sub-spaces for memory-specific RAS features
+have a Feature Type of 0x00 (Memory).
+
+The platform can use the hardware-based memory scrubbing feature to expose
+controls and capabilities associated with hardware-based memory scrub
+engines. The RAS2 memory scrubbing feature supports as per spec,
+
+1. Independent memory scrubbing controls for each NUMA domain, identified
+ using its proximity domain.
+
+2. Provision for background (patrol) scrubbing of the entire memory system,
+ as well as on-demand scrubbing for a specific region of memory.
+
+ACPI Address Range Scrubbing (ARS)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ACPI spec 6.5 [2]_ section 9.19.7.2 describes Address Range Scrubbing (ARS).
+ARS allows the platform to communicate memory errors to system software.
+This capability allows system software to prevent accesses to addresses with
+uncorrectable errors in memory. ARS functions manage all NVDIMMs present in
+the system. Only one scrub can be in progress system wide at any given time.
+
+The following functions are supported as per the specification:
+
+1. Query ARS Capabilities for a given address range, indicates platform
+ supports the ACPI NVDIMM Root Device Unconsumed Error Notification.
+
+2. Start ARS triggers an Address Range Scrub for the given memory range.
+ Address scrubbing can be done for volatile or persistent memory, or both.
+
+3. Query ARS Status command allows software to get the status of ARS,
+ including the progress of ARS and ARS error record.
+
+4. Clear Uncorrectable Error.
+
+5. Translate SPA
+
+6. ARS Error Inject etc.
+
+The kernel supports an existing control for ARS and ARS is currently not
+supported in EDAC.
+
+.. [1] https://computeexpresslink.org/cxl-specification/
+
+.. [2] https://uefi.org/specs/ACPI/6.5/
+
+Comparison of various scrubbing features
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ +--------------+-----------+-----------+-----------+-----------+
+ | | ACPI | CXL patrol| CXL ECS | ARS |
+ | Name | RAS2 | scrub | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | On-demand | Supported | No | No | Supported |
+ | Scrubbing | | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Background | Supported | Supported | Supported | No |
+ | scrubbing | | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Mode of | Scrub ctrl| per device| per memory| Unknown |
+ | scrubbing | per NUMA | | media | |
+ | | domain. | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Query scrub | Supported | Supported | Supported | Supported |
+ | capabilities | | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Setting | Supported | No | No | Supported |
+ | address range| | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Setting | Supported | Supported | No | No |
+ | scrub rate | | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Unit for | Not | in hours | No | No |
+ | scrub rate | Defined | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | | Supported | | | |
+ | Scrub | on-demand | No | No | Supported |
+ | status/ | scrubbing | | | |
+ | Completion | only | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+ | UC error | |CXL general|CXL general| ACPI UCE |
+ | reporting | Exception |media/DRAM |media/DRAM | notify and|
+ | | |event/media|event/media| query |
+ | | |scan? |scan? | ARS status|
+ +--------------+-----------+-----------+-----------+-----------+
+ | | | | | |
+ | Support for | Supported | Supported | Supported | No |
+ | EDAC control | | | | |
+ | | | | | |
+ +--------------+-----------+-----------+-----------+-----------+
+
+The File System
+---------------
+
+The control attributes of a registered scrubber instance could be
+accessed in:
+
+/sys/bus/edac/devices/<dev-name>/scrubX/
+
+sysfs
+-----
+
+Sysfs files are documented in
+`Documentation/ABI/testing/sysfs-edac-scrub`
+
+`Documentation/ABI/testing/sysfs-edac-ecs`
+
+Examples
+--------
+
+The usage takes the form shown in these examples:
+
+1. CXL memory Patrol Scrub
+
+The following are the use cases identified why we might increase the scrub rate.
+
+- Scrubbing is needed at device granularity because a device is showing
+ unexpectedly high errors.
+
+- Scrubbing may apply to memory that isn't online at all yet. Likely this
+ is a system wide default setting on boot.
+
+- Scrubbing at a higher rate because the monitor software has determined that
+ more reliability is necessary for a particular data set. This is called
+ Differentiated Reliability.
+
+1.1. Device based scrubbing
+
+CXL memory is exposed to memory management subsystem and ultimately userspace
+via CXL devices. Device-based scrubbing is used for the first use case
+described in "Section 1 CXL Memory Patrol Scrub".
+
+When combining control via the device interfaces and region interfaces,
+"see Section 1.2 Region based scrubbing".
+
+Sysfs files for scrubbing are documented in
+`Documentation/ABI/testing/sysfs-edac-scrub`
+
+1.2. Region based scrubbing
+
+CXL memory is exposed to memory management subsystem and ultimately userspace
+via CXL regions. CXL Regions represent mapped memory capacity in system
+physical address space. These can incorporate one or more parts of multiple CXL
+memory devices with traffic interleaved across them. The user may want to control
+the scrub rate via this more abstract region instead of having to figure out the
+constituent devices and program them separately. The scrub rate for each device
+covers the whole device. Thus if multiple regions use parts of that device then
+requests for scrubbing of other regions may result in a higher scrub rate than
+requested for this specific region.
+
+Region-based scrubbing is used for the third use case described in
+"Section 1 CXL Memory Patrol Scrub".
+
+Userspace must follow below set of rules on how to set the scrub rates for any
+mixture of requirements.
+
+1. Taking each region in turn from lowest desired scrub rate to highest and set
+ their scrub rates. Later regions may override the scrub rate on individual
+ devices (and hence potentially whole regions).
+
+2. Take each device for which enhanced scrubbing is required (higher rate) and
+ set those scrub rates. This will override the scrub rates of individual devices,
+ setting them to the maximum rate required for any of the regions they help back,
+ unless a specific rate is already defined.
+
+Sysfs files for scrubbing are documented in
+`Documentation/ABI/testing/sysfs-edac-scrub`
+
+2. CXL memory Error Check Scrub (ECS)
+
+The Error Check Scrub (ECS) feature enables a memory device to perform error
+checking and correction (ECC) and count single-bit errors. The associated
+memory controller sets the ECS mode with a trigger sent to the memory
+device. CXL ECS control allows the host, thus the userspace, to change the
+attributes for error count mode, threshold number of errors per segment
+(indicating how many segments have at least that number of errors) for
+reporting errors, and reset the ECS counter. Thus the responsibility for
+initiating Error Check Scrub on a memory device may lie with the memory
+controller or platform when unexpectedly high error rates are detected.
+
+Sysfs files for scrubbing are documented in
+`Documentation/ABI/testing/sysfs-edac-ecs`
diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst
index 17779a2772e5..c2d3996b5b40 100644
--- a/Documentation/fault-injection/fault-injection.rst
+++ b/Documentation/fault-injection/fault-injection.rst
@@ -2,7 +2,7 @@
Fault injection capabilities infrastructure
===========================================
-See also drivers/md/md-faulty.c and "every_nth" module option for scsi_debug.
+See also "every_nth" module option for scsi_debug.
Available fault injection capabilities
@@ -45,6 +45,32 @@ Available fault injection capabilities
ALLOW_ERROR_INJECTION() macro, by setting debugfs entries
under /sys/kernel/debug/fail_function. No boot option supported.
+- fail_skb_realloc
+
+ inject skb (socket buffer) reallocation events into the network path. The
+ primary goal is to identify and prevent issues related to pointer
+ mismanagement in the network subsystem. By forcing skb reallocation at
+ strategic points, this feature creates scenarios where existing pointers to
+ skb headers become invalid.
+
+ When the fault is injected and the reallocation is triggered, cached pointers
+ to skb headers and data no longer reference valid memory locations. This
+ deliberate invalidation helps expose code paths where proper pointer updating
+ is neglected after a reallocation event.
+
+ By creating these controlled fault scenarios, the system can catch instances
+ where stale pointers are used, potentially leading to memory corruption or
+ system instability.
+
+ To select the interface to act on, write the network name to
+ /sys/kernel/debug/fail_skb_realloc/devname.
+ If this field is left empty (which is the default value), skb reallocation
+ will be forced on all network interfaces.
+
+ The effectiveness of this fault detection is enhanced when KASAN is
+ enabled, as it helps identify invalid memory references and use-after-free
+ (UAF) issues.
+
- NVMe fault injection
inject NVMe status code and retry flag on devices permitted by setting
@@ -52,6 +78,14 @@ Available fault injection capabilities
status code is NVME_SC_INVALID_OPCODE with no retry. The status code and
retry flag can be set via the debugfs.
+- Null test block driver fault injection
+
+ inject IO timeouts by setting config items under
+ /sys/kernel/config/nullb/<disk>/timeout_inject,
+ inject requeue requests by setting config items under
+ /sys/kernel/config/nullb/<disk>/requeue_inject, and
+ inject init_hctx() errors by setting config items under
+ /sys/kernel/config/nullb/<disk>/init_hctx_fault_inject.
Configure fault-injection capabilities behavior
-----------------------------------------------
@@ -83,9 +117,7 @@ configuration of fault-injection capabilities.
- /sys/kernel/debug/fail*/times:
specifies how many times failures may happen at most. A value of -1
- means "no limit". Note, though, that this file only accepts unsigned
- values. So, if you want to specify -1, you better use 'printf' instead
- of 'echo', e.g.: $ printf %#x -1 > times
+ means "no limit".
- /sys/kernel/debug/fail*/space:
@@ -135,6 +167,14 @@ configuration of fault-injection capabilities.
default is 'Y', setting it to 'N' will also inject failures into
highmem/user allocations (__GFP_HIGHMEM allocations).
+- /sys/kernel/debug/failslab/cache-filter
+ Format: { 'Y' | 'N' }
+
+ default is 'N', setting it to 'Y' will only inject failures when
+ objects are requests from certain caches.
+
+ Select the cache by writing '1' to /sys/kernel/slab/<cache>/failslab:
+
- /sys/kernel/debug/failslab/ignore-gfp-wait:
- /sys/kernel/debug/fail_page_alloc/ignore-gfp-wait:
@@ -202,6 +242,19 @@ configuration of fault-injection capabilities.
use a negative errno, you better use 'printf' instead of 'echo', e.g.:
$ printf %#x -12 > retval
+- /sys/kernel/debug/fail_skb_realloc/devname:
+
+ Specifies the network interface on which to force SKB reallocation. If
+ left empty, SKB reallocation will be applied to all network interfaces.
+
+ Example usage::
+
+ # Force skb reallocation on eth0
+ echo "eth0" > /sys/kernel/debug/fail_skb_realloc/devname
+
+ # Clear the selection and force skb reallocation on all interfaces
+ echo "" > /sys/kernel/debug/fail_skb_realloc/devname
+
Boot option
^^^^^^^^^^^
@@ -213,6 +266,7 @@ use the boot option::
fail_usercopy=
fail_make_request=
fail_futex=
+ fail_skb_realloc=
mmc_core.fail_request=<interval>,<probability>,<space>,<times>
proc entries
@@ -233,6 +287,71 @@ proc entries
This feature is intended for systematic testing of faults in a single
system call. See an example below.
+
+Error Injectable Functions
+--------------------------
+
+This part is for the kernel developers considering to add a function to
+ALLOW_ERROR_INJECTION() macro.
+
+Requirements for the Error Injectable Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Since the function-level error injection forcibly changes the code path
+and returns an error even if the input and conditions are proper, this can
+cause unexpected kernel crash if you allow error injection on the function
+which is NOT error injectable. Thus, you (and reviewers) must ensure;
+
+- The function returns an error code if it fails, and the callers must check
+ it correctly (need to recover from it).
+
+- The function does not execute any code which can change any state before
+ the first error return. The state includes global or local, or input
+ variable. For example, clear output address storage (e.g. `*ret = NULL`),
+ increments/decrements counter, set a flag, preempt/irq disable or get
+ a lock (if those are recovered before returning error, that will be OK.)
+
+The first requirement is important, and it will result in that the release
+(free objects) functions are usually harder to inject errors than allocate
+functions. If errors of such release functions are not correctly handled
+it will cause a memory leak easily (the caller will confuse that the object
+has been released or corrupted.)
+
+The second one is for the caller which expects the function should always
+does something. Thus if the function error injection skips whole of the
+function, the expectation is betrayed and causes an unexpected error.
+
+Type of the Error Injectable Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each error injectable functions will have the error type specified by the
+ALLOW_ERROR_INJECTION() macro. You have to choose it carefully if you add
+a new error injectable function. If the wrong error type is chosen, the
+kernel may crash because it may not be able to handle the error.
+There are 4 types of errors defined in include/asm-generic/error-injection.h
+
+EI_ETYPE_NULL
+ This function will return `NULL` if it fails. e.g. return an allocated
+ object address.
+
+EI_ETYPE_ERRNO
+ This function will return an `-errno` error code if it fails. e.g. return
+ -EINVAL if the input is wrong. This will include the functions which will
+ return an address which encodes `-errno` by ERR_PTR() macro.
+
+EI_ETYPE_ERRNO_NULL
+ This function will return an `-errno` or `NULL` if it fails. If the caller
+ of this function checks the return value with IS_ERR_OR_NULL() macro, this
+ type will be appropriate.
+
+EI_ETYPE_TRUE
+ This function will return `true` (non-zero positive value) if it fails.
+
+If you specifies a wrong type, for example, EI_TYPE_ERRNO for the function
+which returns an allocated object, it may cause a problem because the returned
+value is not an object address and the caller can not access to the address.
+
+
How to add new fault injection capability
-----------------------------------------
@@ -284,7 +403,7 @@ Application Examples
echo Y > /sys/kernel/debug/$FAILTYPE/task-filter
echo 10 > /sys/kernel/debug/$FAILTYPE/probability
echo 100 > /sys/kernel/debug/$FAILTYPE/interval
- printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times
+ echo -1 > /sys/kernel/debug/$FAILTYPE/times
echo 0 > /sys/kernel/debug/$FAILTYPE/space
echo 2 > /sys/kernel/debug/$FAILTYPE/verbose
echo Y > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait
@@ -338,7 +457,7 @@ Application Examples
echo N > /sys/kernel/debug/$FAILTYPE/task-filter
echo 10 > /sys/kernel/debug/$FAILTYPE/probability
echo 100 > /sys/kernel/debug/$FAILTYPE/interval
- printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times
+ echo -1 > /sys/kernel/debug/$FAILTYPE/times
echo 0 > /sys/kernel/debug/$FAILTYPE/space
echo 2 > /sys/kernel/debug/$FAILTYPE/verbose
echo Y > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait
@@ -369,7 +488,7 @@ Application Examples
echo N > /sys/kernel/debug/$FAILTYPE/task-filter
echo 100 > /sys/kernel/debug/$FAILTYPE/probability
echo 0 > /sys/kernel/debug/$FAILTYPE/interval
- printf %#x -1 > /sys/kernel/debug/$FAILTYPE/times
+ echo -1 > /sys/kernel/debug/$FAILTYPE/times
echo 0 > /sys/kernel/debug/$FAILTYPE/space
echo 1 > /sys/kernel/debug/$FAILTYPE/verbose
@@ -388,6 +507,18 @@ Application Examples
losetup -d $DEVICE
rm testfile.img
+------------------------------------------------------------------------------
+
+- Inject only skbuff allocation failures ::
+
+ # mark skbuff_head_cache as faulty
+ echo 1 > /sys/kernel/slab/skbuff_head_cache/failslab
+ # Turn on cache filter (off by default)
+ echo 1 > /sys/kernel/debug/failslab/cache-filter
+ # Turn on fault injection
+ echo 1 > /sys/kernel/debug/failslab/times
+ echo 1 > /sys/kernel/debug/failslab/probability
+
Tool to run command with failslab or fail_page_alloc
----------------------------------------------------
diff --git a/Documentation/fault-injection/index.rst b/Documentation/fault-injection/index.rst
index 8408a8a91b34..a6ea1d190222 100644
--- a/Documentation/fault-injection/index.rst
+++ b/Documentation/fault-injection/index.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
===============
-fault-injection
+Fault-injection
===============
.. toctree::
diff --git a/Documentation/fault-injection/notifier-error-inject.rst b/Documentation/fault-injection/notifier-error-inject.rst
index 1668b6e48d3a..fdf2dc433ead 100644
--- a/Documentation/fault-injection/notifier-error-inject.rst
+++ b/Documentation/fault-injection/notifier-error-inject.rst
@@ -91,8 +91,8 @@ For more usage examples
There are tools/testing/selftests using the notifier error injection features
for CPU and memory notifiers.
- * tools/testing/selftests/cpu-hotplug/on-off-test.sh
- * tools/testing/selftests/memory-hotplug/on-off-test.sh
+ * tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh
+ * tools/testing/selftests/memory-hotplug/mem-on-off-test.sh
These scripts first do simple online and offline tests and then do fault
injection tests if notifier error injection module is available.
diff --git a/Documentation/fault-injection/provoke-crashes.rst b/Documentation/fault-injection/provoke-crashes.rst
index 3abe84225613..1f087e502ca6 100644
--- a/Documentation/fault-injection/provoke-crashes.rst
+++ b/Documentation/fault-injection/provoke-crashes.rst
@@ -29,7 +29,7 @@ recur_count
cpoint_name
Where in the kernel to trigger the action. It can be
one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY,
- FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT.
+ FS_SUBMIT_BH, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT.
cpoint_type
Indicates the action to be taken on hitting the crash point.
diff --git a/Documentation/fb/aty128fb.rst b/Documentation/fb/aty128fb.rst
index 3f107718f933..0da8070a5521 100644
--- a/Documentation/fb/aty128fb.rst
+++ b/Documentation/fb/aty128fb.rst
@@ -1,8 +1,6 @@
-=================
-What is aty128fb?
-=================
-
-.. [This file is cloned from VesaFB/matroxfb]
+=========================================
+aty128fb - ATI Rage128 framebuffer driver
+=========================================
This is a driver for a graphic framebuffer for ATI Rage128 based devices
on Intel and PPC boxes.
diff --git a/Documentation/fb/deferred_io.rst b/Documentation/fb/deferred_io.rst
index 7300cff255a3..7fc1933b06d9 100644
--- a/Documentation/fb/deferred_io.rst
+++ b/Documentation/fb/deferred_io.rst
@@ -9,7 +9,7 @@ works:
- userspace app like Xfbdev mmaps framebuffer
- deferred IO and driver sets up fault and page_mkwrite handlers
-- userspace app tries to write to mmaped vaddress
+- userspace app tries to write to mmapped vaddress
- we get pagefault and reach fault handler
- fault handler finds and returns physical page
- we get page_mkwrite where we add this page to a list
diff --git a/Documentation/fb/efifb.rst b/Documentation/fb/efifb.rst
index 6badff64756f..3d4aab406dee 100644
--- a/Documentation/fb/efifb.rst
+++ b/Documentation/fb/efifb.rst
@@ -1,6 +1,6 @@
-==============
-What is efifb?
-==============
+===================================
+efifb - Generic EFI platform driver
+===================================
This is a generic EFI platform driver for systems with UEFI firmware. The
system must be booted via the EFI stub for this to be usable. efifb supports
diff --git a/Documentation/fb/ep93xx-fb.rst b/Documentation/fb/ep93xx-fb.rst
index 1dd67f4688c7..93b3494f5309 100644
--- a/Documentation/fb/ep93xx-fb.rst
+++ b/Documentation/fb/ep93xx-fb.rst
@@ -41,7 +41,6 @@ your board initialisation function::
ep93xx_register_fb(&some_board_fb_info);
-=====================
Video Attribute Flags
=====================
@@ -79,7 +78,6 @@ EP93XXFB_USE_SDCSN2 Use SDCSn[2] for the framebuffer.
EP93XXFB_USE_SDCSN3 Use SDCSn[3] for the framebuffer.
=============================== ======================================
-==================
Platform callbacks
==================
@@ -101,7 +99,6 @@ obtained as follows::
/* Board specific framebuffer setup */
}
-======================
Setting the video mode
======================
@@ -119,7 +116,6 @@ set when the module is installed::
modprobe ep93xx-fb video=320x240
-==============
Screenpage bug
==============
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index 212f7003cfba..a98a5cb0b0d8 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -39,11 +39,13 @@ Also, you will need to select at least one compiled-in font, but if
you don't do anything, the kernel configuration tool will select one for you,
usually an 8x16 font.
-GOTCHA: A common bug report is enabling the framebuffer without enabling the
-framebuffer console. Depending on the driver, you may get a blanked or
-garbled display, but the system still boots to completion. If you are
-fortunate to have a driver that does not alter the graphics chip, then you
-will still get a VGA console.
+.. admonition:: GOTCHA
+
+ A common bug report is enabling the framebuffer without enabling the
+ framebuffer console. Depending on the driver, you may get a blanked or
+ garbled display, but the system still boots to completion. If you are
+ fortunate to have a driver that does not alter the graphics chip, then you
+ will still get a VGA console.
B. Loading
==========
@@ -74,6 +76,7 @@ Possible scenarios:
over the console.
C. Boot options
+===============
The framebuffer console has several, largely unknown, boot options
that can change its behavior.
@@ -116,9 +119,10 @@ C. Boot options
outside the given range will still be controlled by the standard
console driver.
- NOTE: For x86 machines, the standard console is the VGA console which
- is typically located on the same video card. Thus, the consoles that
- are controlled by the VGA console will be garbled.
+ .. note::
+ For x86 machines, the standard console is the VGA console which
+ is typically located on the same video card. Thus, the consoles that
+ are controlled by the VGA console will be garbled.
4. fbcon=rotate:<n>
@@ -140,10 +144,11 @@ C. Boot options
Console rotation will only become available if Framebuffer Console
Rotation support is compiled in your kernel.
- NOTE: This is purely console rotation. Any other applications that
- use the framebuffer will remain at their 'normal' orientation.
- Actually, the underlying fb driver is totally ignorant of console
- rotation.
+ .. note::
+ This is purely console rotation. Any other applications that
+ use the framebuffer will remain at their 'normal' orientation.
+ Actually, the underlying fb driver is totally ignorant of console
+ rotation.
5. fbcon=margin:<color>
@@ -172,7 +177,8 @@ C. Boot options
The value 'n' overrides the number of bootup logos. 0 disables the
logo, and -1 gives the default which is the number of online CPUs.
-C. Attaching, Detaching and Unloading
+D. Attaching, Detaching and Unloading
+=====================================
Before going on to how to attach, detach and unload the framebuffer console, an
illustration of the dependencies may help.
@@ -249,11 +255,11 @@ restored properly. The following is one of the several methods that you can do:
echo 1 > /sys/class/vtconsole/vtcon1/bind
8. Once fbcon is unbound, all drivers registered to the system will also
-become unbound. This means that fbcon and individual framebuffer drivers
-can be unloaded or reloaded at will. Reloading the drivers or fbcon will
-automatically bind the console, fbcon and the drivers together. Unloading
-all the drivers without unloading fbcon will make it impossible for the
-console to bind fbcon.
+ become unbound. This means that fbcon and individual framebuffer drivers
+ can be unloaded or reloaded at will. Reloading the drivers or fbcon will
+ automatically bind the console, fbcon and the drivers together. Unloading
+ all the drivers without unloading fbcon will make it impossible for the
+ console to bind fbcon.
Notes for vesafb users:
=======================
diff --git a/Documentation/fb/gxfb.rst b/Documentation/fb/gxfb.rst
index 5738709bccbb..3fda485606bd 100644
--- a/Documentation/fb/gxfb.rst
+++ b/Documentation/fb/gxfb.rst
@@ -1,8 +1,6 @@
-=============
-What is gxfb?
-=============
-
-.. [This file is cloned from VesaFB/aty128fb]
+=======================================
+gxfb - AMD Geode GX2 framebuffer driver
+=======================================
This is a graphics framebuffer driver for AMD Geode GX2 based processors.
diff --git a/Documentation/fb/index.rst b/Documentation/fb/index.rst
index baf02393d8ee..e2f7488b6e2e 100644
--- a/Documentation/fb/index.rst
+++ b/Documentation/fb/index.rst
@@ -4,43 +4,52 @@
Frame Buffer
============
+General information
+===================
+
+.. toctree::
+ :maxdepth: 1
+
+ api
+ cmap_xfbdev
+ deferred_io
+ fbcon
+ framebuffer
+ internals
+ modedb
+
+Driver documentation
+====================
+
.. toctree::
- :maxdepth: 1
-
- api
- arkfb
- aty128fb
- cirrusfb
- cmap_xfbdev
- deferred_io
- efifb
- ep93xx-fb
- fbcon
- framebuffer
- gxfb
- intel810
- intelfb
- internals
- lxfb
- matroxfb
- metronomefb
- modedb
- pvr2fb
- pxafb
- s3fb
- sa1100fb
- sh7760fb
- sisfb
- sm501
- sm712fb
- sstfb
- tgafb
- tridentfb
- udlfb
- uvesafb
- vesafb
- viafb
- vt8623fb
+ :maxdepth: 1
+
+ arkfb
+ aty128fb
+ cirrusfb
+ efifb
+ ep93xx-fb
+ gxfb
+ intel810
+ lxfb
+ matroxfb
+ metronomefb
+ pvr2fb
+ pxafb
+ s3fb
+ sa1100fb
+ sh7760fb
+ sisfb
+ sm501
+ sm712fb
+ sstfb
+ tgafb
+ tridentfb
+ udlfb
+ uvesafb
+ vesafb
+ viafb
+ vt8623fb
.. only:: subproject and html
diff --git a/Documentation/fb/intelfb.rst b/Documentation/fb/intelfb.rst
deleted file mode 100644
index e2d0903f4efb..000000000000
--- a/Documentation/fb/intelfb.rst
+++ /dev/null
@@ -1,155 +0,0 @@
-=============================================================
-Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
-=============================================================
-
-A. Introduction
-===============
-
-This is a framebuffer driver for various Intel 8xx/9xx compatible
-graphics devices. These would include:
-
- - Intel 830M
- - Intel 845G
- - Intel 852GM
- - Intel 855GM
- - Intel 865G
- - Intel 915G
- - Intel 915GM
- - Intel 945G
- - Intel 945GM
- - Intel 945GME
- - Intel 965G
- - Intel 965GM
-
-B. List of available options
-=============================
-
- a. "video=intelfb"
- enables the intelfb driver
-
- Recommendation: required
-
- b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
- select mode
-
- Recommendation: user preference
- (default = 1024x768-32@70)
-
- c. "vram=<value>"
- select amount of system RAM in MB to allocate for the video memory
- if not enough RAM was already allocated by the BIOS.
-
- Recommendation: 1 - 4 MB.
- (default = 4 MB)
-
- d. "voffset=<value>"
- select at what offset in MB of the logical memory to allocate the
- framebuffer memory. The intent is to avoid the memory blocks
- used by standard graphics applications (XFree86). Depending on your
- usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
- for the least amount). Note, an arbitrary setting may conflict
- with XFree86.
-
- Recommendation: do not set
- (default = 48 MB)
-
- e. "accel"
- enable text acceleration. This can be enabled/reenabled anytime
- by using 'fbset -accel true/false'.
-
- Recommendation: enable
- (default = set)
-
- f. "hwcursor"
- enable cursor acceleration.
-
- Recommendation: enable
- (default = set)
-
- g. "mtrr"
- enable MTRR. This allows data transfers to the framebuffer memory
- to occur in bursts which can significantly increase performance.
- Not very helpful with the intel chips because of 'shared memory'.
-
- Recommendation: set
- (default = set)
-
- h. "fixed"
- disable mode switching.
-
- Recommendation: do not set
- (default = not set)
-
- The binary parameters can be unset with a "no" prefix, example "noaccel".
- The default parameter (not named) is the mode.
-
-C. Kernel booting
-=================
-
-Separate each option/option-pair by commas (,) and the option from its value
-with an equals sign (=) as in the following::
-
- video=intelfb:option1,option2=value2
-
-Sample Usage
-------------
-
-In /etc/lilo.conf, add the line::
-
- append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
-
-This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
-framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
-will be enabled.
-
-Remarks
--------
-
-If setting this parameter doesn't work (you stay in a 80x25 text-mode),
-you might need to set the "vga=<mode>" parameter too - see vesafb.txt
-in this directory.
-
-
-D. Module options
-==================
-
-The module parameters are essentially similar to the kernel
-parameters. The main difference is that you need to include a Boolean value
-(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
-
-Example, to enable MTRR, include "mtrr=1".
-
-Sample Usage
-------------
-
-Using the same setup as described above, load the module like this::
-
- modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
-
-Or just add the following to a configuration file in /etc/modprobe.d/::
-
- options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
-
-and just do a::
-
- modprobe intelfb
-
-
-E. Acknowledgment:
-===================
-
- 1. Geert Uytterhoeven - his excellent howto and the virtual
- framebuffer driver code made this possible.
-
- 2. Jeff Hartmann for his agpgart code.
-
- 3. David Dawes for his original kernel 2.4 code.
-
- 4. The X developers. Insights were provided just by reading the
- XFree86 source code.
-
- 5. Antonino A. Daplas for his inspiring i810fb driver.
-
- 6. Andrew Morton for his kernel patches maintenance.
-
-Sylvain
diff --git a/Documentation/fb/lxfb.rst b/Documentation/fb/lxfb.rst
index 863e6b98fbae..0a176ab376e3 100644
--- a/Documentation/fb/lxfb.rst
+++ b/Documentation/fb/lxfb.rst
@@ -1,9 +1,6 @@
-=============
-What is lxfb?
-=============
-
-.. [This file is cloned from VesaFB/aty128fb]
-
+======================================
+lxfb - AMD Geode LX framebuffer driver
+======================================
This is a graphics framebuffer driver for AMD Geode LX based processors.
diff --git a/Documentation/fb/matroxfb.rst b/Documentation/fb/matroxfb.rst
index 6158c49c8571..8ac7534a2e61 100644
--- a/Documentation/fb/matroxfb.rst
+++ b/Documentation/fb/matroxfb.rst
@@ -1,9 +1,6 @@
-=================
-What is matroxfb?
-=================
-
-.. [This file is cloned from VesaFB. Thanks go to Gerd Knorr]
-
+================================================
+matroxfb - Framebuffer driver for Matrox devices
+================================================
This is a driver for a graphic framebuffer for Matrox devices on
Alpha, Intel and PPC boxes.
diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 4d2411e32ebb..bb2889c6ea27 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -26,6 +26,14 @@ Valid mode specifiers (mode_option argument)::
with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
Things between square brackets are optional.
+Valid names are::
+
+ - NSTC: 480i output, with the CCIR System-M TV mode and NTSC color encoding
+ - NTSC-J: 480i output, with the CCIR System-M TV mode, the NTSC color
+ encoding, and a black level equal to the blanking level.
+ - PAL: 576i output, with the CCIR System-B TV mode and PAL color encoding
+ - PAL-M: 480i output, with the CCIR System-M TV mode and PAL color encoding
+
If 'M' is specified in the mode_option argument (after <yres> and before
<bpp> and <refresh>, if specified) the timings will be calculated using
VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
@@ -65,6 +73,8 @@ Valid options are::
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
degrees. Valid values are 0, 90, 180 and 270.
+ - tv_mode: Analog TV mode. One of "NTSC", "NTSC-443", "NTSC-J", "PAL",
+ "PAL-M", "PAL-N", or "SECAM".
- panel_orientation, one of "normal", "upside_down", "left_side_up", or
"right_side_up". For KMS drivers only, this sets the "panel orientation"
property on the kms connector as hint for kms users.
diff --git a/Documentation/fb/pvr2fb.rst b/Documentation/fb/pvr2fb.rst
index fcf2c21c8fcf..315ce085a585 100644
--- a/Documentation/fb/pvr2fb.rst
+++ b/Documentation/fb/pvr2fb.rst
@@ -1,6 +1,6 @@
-===============
-What is pvr2fb?
-===============
+===============================================
+pvr2fb - PowerVR 2 graphics frame buffer driver
+===============================================
This is a driver for PowerVR 2 based graphics frame buffers, such as the
one found in the Dreamcast.
diff --git a/Documentation/fb/sa1100fb.rst b/Documentation/fb/sa1100fb.rst
index 67e2650e017d..c5ca019b361a 100644
--- a/Documentation/fb/sa1100fb.rst
+++ b/Documentation/fb/sa1100fb.rst
@@ -1,9 +1,6 @@
-=================
-What is sa1100fb?
-=================
-
-.. [This file is cloned from VesaFB/matroxfb]
-
+=================================================
+sa1100fb - SA-1100 LCD graphic framebuffer driver
+=================================================
This is a driver for a graphic framebuffer for the SA-1100 LCD
controller.
diff --git a/Documentation/fb/sisfb.rst b/Documentation/fb/sisfb.rst
index 8f4e502ea12e..9982f5ee0560 100644
--- a/Documentation/fb/sisfb.rst
+++ b/Documentation/fb/sisfb.rst
@@ -1,6 +1,6 @@
-==============
-What is sisfb?
-==============
+=====================================
+sisfb - SiS framebuffer device driver
+=====================================
sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
graphics chips. Supported are:
diff --git a/Documentation/fb/sm712fb.rst b/Documentation/fb/sm712fb.rst
index 994dad3b0238..abbc6efae25f 100644
--- a/Documentation/fb/sm712fb.rst
+++ b/Documentation/fb/sm712fb.rst
@@ -1,6 +1,6 @@
-================
-What is sm712fb?
-================
+==========================================================
+sm712fb - Silicon Motion SM712 graphics framebuffer driver
+==========================================================
This is a graphics framebuffer driver for Silicon Motion SM712 based processors.
@@ -31,5 +31,5 @@ Missing Features
================
(alias TODO list)
- * 2D acceleratrion
+ * 2D acceleration
* dual-head support
diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst
index 42466ff49c58..7386eb63bac8 100644
--- a/Documentation/fb/sstfb.rst
+++ b/Documentation/fb/sstfb.rst
@@ -73,7 +73,7 @@ Module insertion
the device will be /dev/fb0. You can check this by doing a
cat /proc/fb. You can find a copy of con2fb in tools/ directory.
if you don't have another fb device, this step is superfluous,
- as the console subsystem automagicaly binds ttys to the fb.
+ as the console subsystem automagically binds ttys to the fb.
#. switch to the virtual console you just mapped. "tadaaa" ...
Module removal
@@ -192,7 +192,7 @@ Todo
- Get rid of the previous paragraph.
- Buy more coffee.
- test/port to other arch.
-- try to add panning using tweeks with front and back buffer .
+- try to add panning using tweaks with front and back buffer.
- try to implement accel on voodoo2, this board can actually do a
lot in 2D even if it was sold as a 3D only board ...
diff --git a/Documentation/fb/tgafb.rst b/Documentation/fb/tgafb.rst
index 0c50d2134aa4..f0944da1ea5e 100644
--- a/Documentation/fb/tgafb.rst
+++ b/Documentation/fb/tgafb.rst
@@ -1,6 +1,6 @@
-==============
-What is tgafb?
-==============
+=======================================
+tgafb - TGA graphics framebuffer driver
+=======================================
This is a driver for DECChip 21030 based graphics framebuffers, a.k.a. TGA
cards, which are usually found in older Digital Alpha systems. The
diff --git a/Documentation/fb/udlfb.rst b/Documentation/fb/udlfb.rst
index 99cfbb7a1922..9e75ac6b07c3 100644
--- a/Documentation/fb/udlfb.rst
+++ b/Documentation/fb/udlfb.rst
@@ -1,6 +1,6 @@
-==============
-What is udlfb?
-==============
+==================================
+udlfb - DisplayLink USB 2.0 driver
+==================================
This is a driver for DisplayLink USB 2.0 era graphics chips.
diff --git a/Documentation/fb/vesafb.rst b/Documentation/fb/vesafb.rst
index f890a4f5623b..d8241e38bb28 100644
--- a/Documentation/fb/vesafb.rst
+++ b/Documentation/fb/vesafb.rst
@@ -1,6 +1,6 @@
-===============
-What is vesafb?
-===============
+===========================================
+vesafb - Generic graphic framebuffer driver
+===========================================
This is a generic driver for a graphic framebuffer on intel boxes.
diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt b/Documentation/features/core/cBPF-JIT/arch-support.txt
index a053667a7a8c..937840080de7 100644
--- a/Documentation/features/core/cBPF-JIT/arch-support.txt
+++ b/Documentation/features/core/cBPF-JIT/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | TODO |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt
index c0bb9c92937f..83f77f55fc87 100644
--- a/Documentation/features/core/eBPF-JIT/arch-support.txt
+++ b/Documentation/features/core/eBPF-JIT/arch-support.txt
@@ -7,19 +7,18 @@
| arch |status|
-----------------------
| alpha: | TODO |
- | arc: | TODO |
+ | arc: | ok |
| arm: | ok |
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
| nios2: | TODO |
| openrisc: | TODO |
- | parisc: | TODO |
+ | parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt
index c9bfff292816..425442e31fa2 100644
--- a/Documentation/features/core/generic-idle-thread/arch-support.txt
+++ b/Documentation/features/core/generic-idle-thread/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | ok |
- | ia64: | ok |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
@@ -25,7 +24,7 @@
| s390: | ok |
| sh: | ok |
| sparc: | ok |
- | um: | TODO |
+ | um: | ok |
| x86: | ok |
| xtensa: | ok |
-----------------------
diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt
index 35e2a44b1448..683de7c15058 100644
--- a/Documentation/features/core/jump-labels/arch-support.txt
+++ b/Documentation/features/core/jump-labels/arch-support.txt
@@ -10,15 +10,14 @@
| arc: | ok |
| arm: | ok |
| arm64: | ok |
- | csky: | TODO |
+ | csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
| nios2: | TODO |
- | openrisc: | TODO |
+ | openrisc: | ok |
| parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
diff --git a/Documentation/features/core/mseal_sys_mappings/arch-support.txt b/Documentation/features/core/mseal_sys_mappings/arch-support.txt
new file mode 100644
index 000000000000..fa85381acc43
--- /dev/null
+++ b/Documentation/features/core/mseal_sys_mappings/arch-support.txt
@@ -0,0 +1,30 @@
+#
+# Feature name: mseal-system-mappings
+# Kconfig: ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
+# description: arch supports mseal system mappings
+#
+ -----------------------
+ | arch |status|
+ -----------------------
+ | alpha: | TODO |
+ | arc: | N/A |
+ | arm: | N/A |
+ | arm64: | ok |
+ | csky: | N/A |
+ | hexagon: | N/A |
+ | loongarch: | ok |
+ | m68k: | N/A |
+ | microblaze: | N/A |
+ | mips: | TODO |
+ | nios2: | N/A |
+ | openrisc: | N/A |
+ | parisc: | TODO |
+ | powerpc: | TODO |
+ | riscv: | ok |
+ | s390: | ok |
+ | sh: | N/A |
+ | sparc: | TODO |
+ | um: | TODO |
+ | x86: | ok |
+ | xtensa: | N/A |
+ -----------------------
diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt
index 9b3e2ce12b44..f3d744c76061 100644
--- a/Documentation/features/core/thread-info-in-task/arch-support.txt
+++ b/Documentation/features/core/thread-info-in-task/arch-support.txt
@@ -1,7 +1,7 @@
#
# Feature name: thread-info-in-task
# Kconfig: THREAD_INFO_IN_TASK
-# description: arch makes use of the core kernel facility to embedd thread_info in task_struct
+# description: arch makes use of the core kernel facility to embed thread_info in task_struct
#
-----------------------
| arch |status|
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
@@ -25,7 +24,7 @@
| s390: | ok |
| sh: | TODO |
| sparc: | TODO |
- | um: | TODO |
+ | um: | ok |
| x86: | ok |
| xtensa: | TODO |
-----------------------
diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt
index 9c7ffec5d51d..4f36fcbfb6d5 100644
--- a/Documentation/features/core/tracehook/arch-support.txt
+++ b/Documentation/features/core/tracehook/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | ok |
- | ia64: | ok |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
@@ -25,7 +24,7 @@
| s390: | ok |
| sh: | ok |
| sparc: | ok |
- | um: | TODO |
+ | um: | ok |
| x86: | ok |
| xtensa: | ok |
-----------------------
diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt
index 2fd5fb6f5f23..39c6e78c0cbe 100644
--- a/Documentation/features/debug/KASAN/arch-support.txt
+++ b/Documentation/features/debug/KASAN/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
@@ -25,7 +24,7 @@
| s390: | ok |
| sh: | TODO |
| sparc: | TODO |
- | um: | TODO |
+ | um: | ok |
| x86: | ok |
| xtensa: | ok |
-----------------------
diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
index c45711e55c7b..156687a7436d 100644
--- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
+++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt
index 0b3ba2415fac..63494bddc263 100644
--- a/Documentation/features/debug/gcov-profile-all/arch-support.txt
+++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt
index 0a91f5ce34a9..4449e1f55cd8 100644
--- a/Documentation/features/debug/kcov/arch-support.txt
+++ b/Documentation/features/debug/kcov/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt
index 04120d278c22..f287f16ce0ec 100644
--- a/Documentation/features/debug/kgdb/arch-support.txt
+++ b/Documentation/features/debug/kgdb/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | ok |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt
index e487c356ab20..f45149cfa313 100644
--- a/Documentation/features/debug/kmemleak/arch-support.txt
+++ b/Documentation/features/debug/kmemleak/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
index b3697f4c806e..d937b7a03575 100644
--- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
+++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | TODO |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
@@ -21,7 +20,7 @@
| openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
- | riscv: | ok |
+ | riscv: | TODO |
| s390: | ok |
| sh: | TODO |
| sparc: | TODO |
diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt
index 452385ac9e06..1ea27aedd098 100644
--- a/Documentation/features/debug/kprobes/arch-support.txt
+++ b/Documentation/features/debug/kprobes/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | ok |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt
index daecf046e72b..022be42e64f9 100644
--- a/Documentation/features/debug/kretprobes/arch-support.txt
+++ b/Documentation/features/debug/kretprobes/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | ok |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt
index adb1bd055bfd..92f5d0f444fa 100644
--- a/Documentation/features/debug/optprobes/arch-support.txt
+++ b/Documentation/features/debug/optprobes/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | TODO |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt
index ddcd7161d14c..de8f43f2e5d6 100644
--- a/Documentation/features/debug/stackprotector/arch-support.txt
+++ b/Documentation/features/debug/stackprotector/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt
index 25121200f9f9..0c698003ce9c 100644
--- a/Documentation/features/debug/uprobes/arch-support.txt
+++ b/Documentation/features/debug/uprobes/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/debug/user-ret-profiler/arch-support.txt b/Documentation/features/debug/user-ret-profiler/arch-support.txt
index f2fcff8e77b7..3e431767581d 100644
--- a/Documentation/features/debug/user-ret-profiler/arch-support.txt
+++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | TODO |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt
index 95e485c87e36..3c6ce35d704f 100644
--- a/Documentation/features/io/dma-contiguous/arch-support.txt
+++ b/Documentation/features/io/dma-contiguous/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh
deleted file mode 100755
index e73aa35848f0..000000000000
--- a/Documentation/features/list-arch.sh
+++ /dev/null
@@ -1,11 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-#
-# Small script that visualizes the kernel feature support status
-# of an architecture.
-#
-# (If no arguments are given then it will print the host architecture's status.)
-#
-
-ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
-
-$(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH
diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt
index 8b1a8d9e1c79..2c3a4b91f16d 100644
--- a/Documentation/features/locking/cmpxchg-local/arch-support.txt
+++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt
index ab69e8f56a37..b6b00469f7d0 100644
--- a/Documentation/features/locking/lockdep/arch-support.txt
+++ b/Documentation/features/locking/lockdep/arch-support.txt
@@ -12,14 +12,13 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | ok |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
| nios2: | TODO |
| openrisc: | ok |
- | parisc: | TODO |
+ | parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
index 0bfb72a08d82..b286a5fff283 100644
--- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
index d2f2201febc8..cf26042480e2 100644
--- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
@@ -10,10 +10,9 @@
| arc: | TODO |
| arm: | TODO |
| arm64: | ok |
- | csky: | TODO |
+ | csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
@@ -21,7 +20,7 @@
| openrisc: | ok |
| parisc: | TODO |
| powerpc: | ok |
- | riscv: | TODO |
+ | riscv: | ok |
| s390: | TODO |
| sh: | TODO |
| sparc: | ok |
diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt
index 0d0647b06762..75c05d348c01 100644
--- a/Documentation/features/perf/kprobes-event/arch-support.txt
+++ b/Documentation/features/perf/kprobes-event/arch-support.txt
@@ -12,13 +12,12 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | ok |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
| nios2: | TODO |
- | openrisc: | TODO |
+ | openrisc: | ok |
| parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt
index 13c297bbf05c..09431518b0e8 100644
--- a/Documentation/features/perf/perf-regs/arch-support.txt
+++ b/Documentation/features/perf/perf-regs/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt
index 931687eec671..f9db4dd8ef79 100644
--- a/Documentation/features/perf/perf-stackdump/arch-support.txt
+++ b/Documentation/features/perf/perf-stackdump/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt
index 336d728b8a45..7425d2b994a3 100644
--- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt
+++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt
@@ -5,11 +5,27 @@
#
# Architecture requirements
#
-# * arm/arm64/powerpc
+# * arm/arm64/powerpc/s390
#
# Rely on implicit context synchronization as a result of exception return
# when returning from IPI handler, and when returning to user-space.
#
+# * riscv
+#
+# riscv uses xRET as return from interrupt and to return to user-space.
+#
+# Given that xRET is not core serializing, we rely on FENCE.I for providing
+# core serialization:
+#
+# - by calling sync_core_before_usermode() on return from interrupt (cf.
+# ipi_sync_core()),
+#
+# - via switch_mm() and sync_core_before_usermode() (respectively, for
+# uthread->uthread and kthread->uthread transitions) before returning
+# to user-space.
+#
+# The serialization in switch_mm() is activated by prepare_sync_core_cmd().
+#
# * x86
#
# x86-32 uses IRET as return from interrupt, which takes care of the IPI.
@@ -35,8 +51,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
@@ -44,8 +59,8 @@
| openrisc: | TODO |
| parisc: | TODO |
| powerpc: | ok |
- | riscv: | TODO |
- | s390: | TODO |
+ | riscv: | ok |
+ | s390: | ok |
| sh: | TODO |
| sparc: | TODO |
| um: | TODO |
diff --git a/Documentation/features/sched/numa-balancing/arch-support.txt b/Documentation/features/sched/numa-balancing/arch-support.txt
index 76d012118372..984601c7c479 100644
--- a/Documentation/features/sched/numa-balancing/arch-support.txt
+++ b/Documentation/features/sched/numa-balancing/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | .. |
| hexagon: | .. |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | .. |
| microblaze: | .. |
| mips: | TODO |
diff --git a/Documentation/features/scripts/features-refresh.sh b/Documentation/features/scripts/features-refresh.sh
deleted file mode 100755
index 9e72d38a0720..000000000000
--- a/Documentation/features/scripts/features-refresh.sh
+++ /dev/null
@@ -1,98 +0,0 @@
-#
-# Small script that refreshes the kernel feature support status in place.
-#
-
-for F_FILE in Documentation/features/*/*/arch-support.txt; do
- F=$(grep "^# Kconfig:" "$F_FILE" | cut -c26-)
-
- #
- # Each feature F is identified by a pair (O, K), where 'O' can
- # be either the empty string (for 'nop') or "not" (the logical
- # negation operator '!'); other operators are not supported.
- #
- O=""
- K=$F
- if [[ "$F" == !* ]]; then
- O="not"
- K=$(echo $F | sed -e 's/^!//g')
- fi
-
- #
- # F := (O, K) is 'valid' iff there is a Kconfig file (for some
- # arch) which contains K.
- #
- # Notice that this definition entails an 'asymmetry' between
- # the case 'O = ""' and the case 'O = "not"'. E.g., F may be
- # _invalid_ if:
- #
- # [case 'O = ""']
- # 1) no arch provides support for F,
- # 2) K does not exist (e.g., it was renamed/mis-typed);
- #
- # [case 'O = "not"']
- # 3) all archs provide support for F,
- # 4) as in (2).
- #
- # The rationale for adopting this definition (and, thus, for
- # keeping the asymmetry) is:
- #
- # We want to be able to 'detect' (2) (or (4)).
- #
- # (1) and (3) may further warn the developers about the fact
- # that K can be removed.
- #
- F_VALID="false"
- for ARCH_DIR in arch/*/; do
- K_FILES=$(find $ARCH_DIR -name "Kconfig*")
- K_GREP=$(grep "$K" $K_FILES)
- if [ ! -z "$K_GREP" ]; then
- F_VALID="true"
- break
- fi
- done
- if [ "$F_VALID" = "false" ]; then
- printf "WARNING: '%s' is not a valid Kconfig\n" "$F"
- fi
-
- T_FILE="$F_FILE.tmp"
- grep "^#" $F_FILE > $T_FILE
- echo " -----------------------" >> $T_FILE
- echo " | arch |status|" >> $T_FILE
- echo " -----------------------" >> $T_FILE
- for ARCH_DIR in arch/*/; do
- ARCH=$(echo $ARCH_DIR | sed -e 's/arch//g' | sed -e 's/\///g')
- K_FILES=$(find $ARCH_DIR -name "Kconfig*")
- K_GREP=$(grep "$K" $K_FILES)
- #
- # Arch support status values for (O, K) are updated according
- # to the following rules.
- #
- # - ("", K) is 'supported by a given arch', if there is a
- # Kconfig file for that arch which contains K;
- #
- # - ("not", K) is 'supported by a given arch', if there is
- # no Kconfig file for that arch which contains K;
- #
- # - otherwise: preserve the previous status value (if any),
- # default to 'not yet supported'.
- #
- # Notice that, according these rules, invalid features may be
- # updated/modified.
- #
- if [ "$O" = "" ] && [ ! -z "$K_GREP" ]; then
- printf " |%12s: | ok |\n" "$ARCH" >> $T_FILE
- elif [ "$O" = "not" ] && [ -z "$K_GREP" ]; then
- printf " |%12s: | ok |\n" "$ARCH" >> $T_FILE
- else
- S=$(grep -v "^#" "$F_FILE" | grep " $ARCH:")
- if [ ! -z "$S" ]; then
- echo "$S" >> $T_FILE
- else
- printf " |%12s: | TODO |\n" "$ARCH" \
- >> $T_FILE
- fi
- fi
- done
- echo " -----------------------" >> $T_FILE
- mv $T_FILE $F_FILE
-done
diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
index a86b8b1f3d10..13feb679649e 100644
--- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt
+++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt
@@ -12,9 +12,8 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
- | m68k: | TODO |
+ | loongarch: | ok |
+ | m68k: | ok |
| microblaze: | TODO |
| mips: | ok |
| nios2: | TODO |
diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt
index 364169f00ee2..ccba965e8d07 100644
--- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt
+++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt
index 6ea274790e47..d6100b226de5 100644
--- a/Documentation/features/time/clockevents/arch-support.txt
+++ b/Documentation/features/time/clockevents/arch-support.txt
@@ -12,14 +12,13 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | ok |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | ok |
| mips: | ok |
| nios2: | ok |
| openrisc: | ok |
- | parisc: | TODO |
+ | parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt
index e59071a49090..891be9f61903 100644
--- a/Documentation/features/time/context-tracking/arch-support.txt
+++ b/Documentation/features/time/context-tracking/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt
index fd17d8de5ef1..3d10075a8a8a 100644
--- a/Documentation/features/time/irq-time-acct/arch-support.txt
+++ b/Documentation/features/time/irq-time-acct/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | .. |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt
index 1a859ac05e9e..21f11d47ef72 100644
--- a/Documentation/features/time/virt-cpuacct/arch-support.txt
+++ b/Documentation/features/time/virt-cpuacct/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | ok |
| hexagon: | TODO |
- | ia64: | ok |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt
index b1229953391b..57406c0d5353 100644
--- a/Documentation/features/vm/ELF-ASLR/arch-support.txt
+++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt
@@ -1,6 +1,7 @@
#
# Feature name: ELF-ASLR
# Kconfig: ARCH_HAS_ELF_RANDOMIZE
+# Kconfig: ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
# description: arch randomizes the stack, heap and binary images of ELF binaries
#
-----------------------
@@ -10,10 +11,9 @@
| arc: | TODO |
| arm: | ok |
| arm64: | ok |
- | csky: | TODO |
+ | csky: | ok |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/vm/PG_uncached/arch-support.txt b/Documentation/features/vm/PG_uncached/arch-support.txt
deleted file mode 100644
index 02f325fbfcd0..000000000000
--- a/Documentation/features/vm/PG_uncached/arch-support.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-#
-# Feature name: PG_uncached
-# Kconfig: ARCH_USES_PG_UNCACHED
-# description: arch supports the PG_uncached page flag
-#
- -----------------------
- | arch |status|
- -----------------------
- | alpha: | TODO |
- | arc: | TODO |
- | arm: | TODO |
- | arm64: | TODO |
- | csky: | TODO |
- | hexagon: | TODO |
- | ia64: | ok |
- | loong: | TODO |
- | m68k: | TODO |
- | microblaze: | TODO |
- | mips: | TODO |
- | nios2: | TODO |
- | openrisc: | TODO |
- | parisc: | TODO |
- | powerpc: | TODO |
- | riscv: | TODO |
- | s390: | TODO |
- | sh: | TODO |
- | sparc: | TODO |
- | um: | TODO |
- | x86: | ok |
- | xtensa: | TODO |
- -----------------------
diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt
index 9bfff977ef55..b4a5ce16940d 100644
--- a/Documentation/features/vm/THP/arch-support.txt
+++ b/Documentation/features/vm/THP/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | .. |
| hexagon: | .. |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | .. |
| microblaze: | .. |
| mips: | ok |
diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt
index 039e4e91ada3..d222bd3ee749 100644
--- a/Documentation/features/vm/TLB/arch-support.txt
+++ b/Documentation/features/vm/TLB/arch-support.txt
@@ -9,11 +9,10 @@
| alpha: | TODO |
| arc: | TODO |
| arm: | TODO |
- | arm64: | N/A |
+ | arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | .. |
| microblaze: | .. |
| mips: | TODO |
@@ -21,7 +20,7 @@
| openrisc: | .. |
| parisc: | TODO |
| powerpc: | TODO |
- | riscv: | TODO |
+ | riscv: | ok |
| s390: | TODO |
| sh: | TODO |
| sparc: | TODO |
diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt
index 13b4940e0c3a..2d6de7b04538 100644
--- a/Documentation/features/vm/huge-vmap/arch-support.txt
+++ b/Documentation/features/vm/huge-vmap/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | TODO |
+ | loongarch: | TODO |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |
@@ -21,7 +20,7 @@
| openrisc: | TODO |
| parisc: | TODO |
| powerpc: | ok |
- | riscv: | TODO |
+ | riscv: | ok |
| s390: | TODO |
| sh: | TODO |
| sparc: | TODO |
diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt
index 6bd78eb4dc6e..1638c2cb17f1 100644
--- a/Documentation/features/vm/ioremap_prot/arch-support.txt
+++ b/Documentation/features/vm/ioremap_prot/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt
index fc3687b5e89b..3f777f8b67d5 100644
--- a/Documentation/features/vm/pte_special/arch-support.txt
+++ b/Documentation/features/vm/pte_special/arch-support.txt
@@ -12,8 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
- | ia64: | TODO |
- | loong: | ok |
+ | loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | ok |
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst
index 7b5964bc8865..be3504ca034a 100644
--- a/Documentation/filesystems/9p.rst
+++ b/Documentation/filesystems/9p.rst
@@ -31,7 +31,7 @@ Other applications are described in the following papers:
* PROSE I/O: Using 9p to enable Application Partitions
http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
* VirtFS: A Virtualization Aware File System pass-through
- http://goo.gl/3WPDg
+ https://kernel.org/doc/ols/2010/ols2010-pages-109-120.pdf
Usage
=====
@@ -40,7 +40,7 @@ For remote file server::
mount -t 9p 10.10.1.2 /mnt/9
-For Plan 9 From User Space applications (http://swtch.com/plan9)::
+For Plan 9 From User Space applications (https://9fans.github.io/plan9port/)::
mount -t 9p `namespace`/acme /mnt/9 -o trans=unix,uname=$USER
@@ -48,11 +48,66 @@ For server running on QEMU host with virtio transport::
mount -t 9p -o trans=virtio <mount_tag> /mnt/9
-where mount_tag is the tag associated by the server to each of the exported
+where mount_tag is the tag generated by the server to each of the exported
mount points. Each 9P export is seen by the client as a virtio device with an
associated "mount_tag" property. Available mount tags can be
seen by reading /sys/bus/virtio/drivers/9pnet_virtio/virtio<n>/mount_tag files.
+USBG Usage
+==========
+
+To mount a 9p FS on a USB Host accessible via the gadget at runtime::
+
+ mount -t 9p -o trans=usbg,aname=/path/to/fs <device> /mnt/9
+
+To mount a 9p FS on a USB Host accessible via the gadget as root filesystem::
+
+ root=<device> rootfstype=9p rootflags=trans=usbg,cache=loose,uname=root,access=0,dfltuid=0,dfltgid=0,aname=/path/to/rootfs
+
+where <device> is the tag associated by the usb gadget transport.
+It is defined by the configfs instance name.
+
+USBG Example
+============
+
+The USB host exports a filesystem, while the gadget on the USB device
+side makes it mountable.
+
+Diod (9pfs server) and the forwarder are on the development host, where
+the root filesystem is actually stored. The gadget is initialized during
+boot (or later) on the embedded board. Then the forwarder will find it
+on the USB bus and start forwarding requests.
+
+In this case the 9p requests come from the device and are handled by the
+host. The reason is that USB device ports are normally not available on
+PCs, so a connection in the other direction would not work.
+
+When using the usbg transport, for now there is no native usb host
+service capable to handle the requests from the gadget driver. For
+this we have to use the extra python tool p9_fwd.py from tools/usb.
+
+Just start the 9pfs capable network server like diod/nfs-ganesha e.g.::
+
+ $ diod -f -n -d 0 -S -l 0.0.0.0:9999 -e $PWD
+
+Optionally scan your bus if there are more then one usbg gadgets to find their path::
+
+ $ python $kernel_dir/tools/usb/p9_fwd.py list
+
+ Bus | Addr | Manufacturer | Product | ID | Path
+ --- | ---- | ---------------- | ---------------- | --------- | ----
+ 2 | 67 | unknown | unknown | 1d6b:0109 | 2-1.1.2
+ 2 | 68 | unknown | unknown | 1d6b:0109 | 2-1.1.3
+
+Then start the python transport::
+
+ $ python $kernel_dir/tools/usb/p9_fwd.py --path 2-1.1.2 connect -p 9999
+
+After that the gadget driver can be used as described above.
+
+One use-case is to use it as an alternative to NFS root booting during
+the development of embedded Linux devices.
+
Options
=======
@@ -68,6 +123,7 @@ Options
virtio connect to the next virtio channel available
(from QEMU with trans_virtio module)
rdma connect to a specified RDMA channel
+ usbg connect to a specified usb gadget channel
======== ============================================
uname=name user name to attempt mount as on the remote server. The
@@ -78,19 +134,39 @@ Options
offering several exported file systems.
cache=mode specifies a caching policy. By default, no caches are used.
-
- none
- default no cache policy, metadata and data
- alike are synchronous.
- loose
- no attempts are made at consistency,
- intended for exclusive, read-only mounts
- fscache
- use FS-Cache for a persistent, read-only
- cache backend.
- mmap
- minimal cache that is only used for read-write
- mmap. Northing else is cached, like cache=none
+ The mode can be specified as a bitmask or by using one of the
+ preexisting common 'shortcuts'.
+ The bitmask is described below: (unspecified bits are reserved)
+
+ ========== ====================================================
+ 0b00000000 all caches disabled, mmap disabled
+ 0b00000001 file caches enabled
+ 0b00000010 meta-data caches enabled
+ 0b00000100 writeback behavior (as opposed to writethrough)
+ 0b00001000 loose caches (no explicit consistency with server)
+ 0b10000000 fscache enabled for persistent caching
+ ========== ====================================================
+
+ The current shortcuts and their associated bitmask are:
+
+ ========= ====================================================
+ none 0b00000000 (no caching)
+ readahead 0b00000001 (only read-ahead file caching)
+ mmap 0b00000101 (read-ahead + writeback file cache)
+ loose 0b00001111 (non-coherent file and meta-data caches)
+ fscache 0b10001111 (persistent loose cache)
+ ========= ====================================================
+
+ NOTE: only these shortcuts are tested modes of operation at the
+ moment, so using other combinations of bit-patterns is not
+ known to work. Work on better cache support is in progress.
+
+ IMPORTANT: loose caches (and by extension at the moment fscache)
+ do not necessarily validate cached values on the server. In other
+ words changes on the server are not guaranteed to be reflected
+ on the client system. Only use this mode of operation if you
+ have an exclusive mount and the server will not modify the
+ filesystem underneath you.
debug=n specifies debug level. The debug level is a bitmask.
@@ -137,6 +213,12 @@ Options
This can be used to share devices/named pipes/sockets between
hosts. This functionality will be expanded in later versions.
+ directio bypass page cache on all read/write operations
+
+ ignoreqv ignore qid.version==0 as a marker to ignore cache
+
+ noxattr do not offer xattr functions on this mount.
+
access there are four access modes.
user
if a user tries to access a file on v9fs
diff --git a/Documentation/filesystems/afs.rst b/Documentation/filesystems/afs.rst
index ca062a7f8ee2..f15ba388bbde 100644
--- a/Documentation/filesystems/afs.rst
+++ b/Documentation/filesystems/afs.rst
@@ -44,7 +44,7 @@ options::
CONFIG_AF_RXRPC - The RxRPC protocol transport
CONFIG_RXKAD - The RxRPC Kerberos security handler
- CONFIG_AFS - The AFS filesystem
+ CONFIG_AFS_FS - The AFS filesystem
Additionally, the following can be turned on to aid debugging::
diff --git a/Documentation/filesystems/api-summary.rst b/Documentation/filesystems/api-summary.rst
index 98db2ea5fa12..cc5cc7f3fbd8 100644
--- a/Documentation/filesystems/api-summary.rst
+++ b/Documentation/filesystems/api-summary.rst
@@ -56,9 +56,6 @@ Other Functions
.. kernel-doc:: fs/namei.c
:export:
-.. kernel-doc:: fs/buffer.c
- :export:
-
.. kernel-doc:: block/bio.c
:export:
diff --git a/Documentation/filesystems/autofs-mount-control.rst b/Documentation/filesystems/autofs-mount-control.rst
index bf4b511cdbe8..b5a379d25c40 100644
--- a/Documentation/filesystems/autofs-mount-control.rst
+++ b/Documentation/filesystems/autofs-mount-control.rst
@@ -196,7 +196,7 @@ information and return operation results::
struct args_ismountpoint ismountpoint;
};
- char path[0];
+ char path[];
};
The ioctlfd field is a mount point file descriptor of an autofs mount
diff --git a/Documentation/filesystems/autofs.rst b/Documentation/filesystems/autofs.rst
index 4f490278d22f..5eb02394fcc3 100644
--- a/Documentation/filesystems/autofs.rst
+++ b/Documentation/filesystems/autofs.rst
@@ -18,7 +18,7 @@ key advantages:
2. The names and locations of filesystems can be stored in
a remote database and can change at any time. The content
- in that data base at the time of access will be used to provide
+ in that database at the time of access will be used to provide
a target for the access. The interpretation of names in the
filesystem can even be programmatic rather than database-backed,
allowing wildcards for example, and can vary based on the user who
@@ -423,7 +423,7 @@ The available ioctl commands are:
and objects are expired if the are not in use.
**AUTOFS_EXP_FORCED** causes the in use status to be ignored
- and objects are expired ieven if they are in use. This assumes
+ and objects are expired even if they are in use. This assumes
that the daemon has requested this because it is capable of
performing the umount.
@@ -442,7 +442,7 @@ which can be used to communicate directly with the autofs filesystem.
It requires CAP_SYS_ADMIN for access.
The 'ioctl's that can be used on this device are described in a separate
-document `autofs-mount-control.txt`, and are summarised briefly here.
+document `autofs-mount-control.rst`, and are summarised briefly here.
Each ioctl is passed a pointer to an `autofs_dev_ioctl` structure::
struct autofs_dev_ioctl {
@@ -467,7 +467,7 @@ Each ioctl is passed a pointer to an `autofs_dev_ioctl` structure::
struct args_ismountpoint ismountpoint;
};
- char path[0];
+ char path[];
};
For the **OPEN_MOUNT** and **IS_MOUNTPOINT** commands, the target
diff --git a/Documentation/filesystems/befs.rst b/Documentation/filesystems/befs.rst
index 79f9740d76ff..a22f603b2938 100644
--- a/Documentation/filesystems/befs.rst
+++ b/Documentation/filesystems/befs.rst
@@ -106,8 +106,8 @@ iocharset=xxx Use xxx as the name of the NLS translation table.
debug The driver will output debugging information to the syslog.
============= ===========================================================
-How to Get Lastest Version
-==========================
+How to Get Latest Version
+=========================
The latest version is currently available at:
<http://befs-driver.sourceforge.net/>
diff --git a/Documentation/filesystems/btrfs.rst b/Documentation/filesystems/btrfs.rst
index 992eddb0e11b..a81db8f54d68 100644
--- a/Documentation/filesystems/btrfs.rst
+++ b/Documentation/filesystems/btrfs.rst
@@ -37,7 +37,6 @@ For more information please refer to the documentation site or wiki
https://btrfs.readthedocs.io
- https://btrfs.wiki.kernel.org
that maintains information about administration tasks, frequently asked
questions, use cases, mount options, comprehensible changelogs, features,
diff --git a/Documentation/filesystems/buffer.rst b/Documentation/filesystems/buffer.rst
new file mode 100644
index 000000000000..ae24faf68efa
--- /dev/null
+++ b/Documentation/filesystems/buffer.rst
@@ -0,0 +1,12 @@
+Buffer Heads
+============
+
+Linux uses buffer heads to maintain state about individual filesystem blocks.
+Buffer heads are deprecated and new filesystems should use iomap instead.
+
+Functions
+---------
+
+.. kernel-doc:: include/linux/buffer_head.h
+.. kernel-doc:: fs/buffer.c
+ :export:
diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst
index fc7abf712315..b3ccc782cb3b 100644
--- a/Documentation/filesystems/caching/cachefiles.rst
+++ b/Documentation/filesystems/caching/cachefiles.rst
@@ -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::
- echo 5 >/sys/modules/cachefiles/parameters/debug
+ echo 5 > /sys/module/cachefiles/parameters/debug
Starting the Cache
@@ -416,7 +416,7 @@ process is the target of an operation by some other process (SIGKILL for
example).
The subjective security holds the active security properties of a process, and
-may be overridden. This is not seen externally, and is used whan a process
+may be overridden. This is not seen externally, and is used when a process
acts upon another object, for example SIGKILLing another process or opening a
file.
diff --git a/Documentation/filesystems/caching/fscache.rst b/Documentation/filesystems/caching/fscache.rst
index a74d7b052dc1..de1f32526cc1 100644
--- a/Documentation/filesystems/caching/fscache.rst
+++ b/Documentation/filesystems/caching/fscache.rst
@@ -318,10 +318,10 @@ where the columns are:
Debugging
=========
-If CONFIG_FSCACHE_DEBUG is enabled, the FS-Cache facility can have runtime
-debugging enabled by adjusting the value in::
+If CONFIG_NETFS_DEBUG is enabled, the FS-Cache facility and NETFS support can
+have runtime debugging enabled by adjusting the value in::
- /sys/module/fscache/parameters/debug
+ /sys/module/netfs/parameters/debug
This is a bitmask of debugging streams to enable:
@@ -343,6 +343,6 @@ This is a bitmask of debugging streams to enable:
The appropriate set of values should be OR'd together and the result written to
the control file. For example::
- echo $((1|8|512)) >/sys/module/fscache/parameters/debug
+ echo $((1|8|512)) >/sys/module/netfs/parameters/debug
will turn on all function entry debugging.
diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst
index 1d18e9def183..665b27f1556e 100644
--- a/Documentation/filesystems/caching/netfs-api.rst
+++ b/Documentation/filesystems/caching/netfs-api.rst
@@ -59,7 +59,7 @@ A filesystem would typically have a volume cookie for each superblock.
The filesystem then acquires a cookie for each file within that volume using an
object key. Object keys are binary blobs and only need to be unique within
-their parent volume. The cache backend is reponsible for rendering the binary
+their parent volume. The cache backend is responsible for rendering the binary
blob into something it can use and may employ hash tables, trees or whatever to
improve its ability to find an object. This is transparent to the network
filesystem.
@@ -91,7 +91,7 @@ actually required and it can use the fscache I/O API directly.
Volume Registration
===================
-The first step for a network filsystem is to acquire a volume cookie for the
+The first step for a network filesystem is to acquire a volume cookie for the
volume it wants to access::
struct fscache_volume *
@@ -119,7 +119,7 @@ is provided. If the coherency data doesn't match, the entire cache volume will
be invalidated.
This function can return errors such as EBUSY if the volume key is already in
-use by an acquired volume or ENOMEM if an allocation failure occured. It may
+use by an acquired volume or ENOMEM if an allocation failure occurred. It may
also return a NULL volume cookie if fscache is not enabled. It is safe to
pass a NULL cookie to any function that takes a volume cookie. This will
cause that function to do nothing.
diff --git a/Documentation/filesystems/ceph.rst b/Documentation/filesystems/ceph.rst
index 4942e018db85..6d2276a87a5a 100644
--- a/Documentation/filesystems/ceph.rst
+++ b/Documentation/filesystems/ceph.rst
@@ -57,12 +57,25 @@ a snapshot on any subdirectory (and its nested contents) in the
system. Snapshot creation and deletion are as simple as 'mkdir
.snap/foo' and 'rmdir .snap/foo'.
-Ceph also provides some recursive accounting on directories for nested
-files and bytes. That is, a 'getfattr -d foo' on any directory in the
-system will reveal the total number of nested regular files and
-subdirectories, and a summation of all nested file sizes. This makes
-the identification of large disk space consumers relatively quick, as
-no 'du' or similar recursive scan of the file system is required.
+Snapshot names have two limitations:
+
+* They can not start with an underscore ('_'), as these names are reserved
+ for internal usage by the MDS.
+* They can not exceed 240 characters in size. This is because the MDS makes
+ use of long snapshot names internally, which follow the format:
+ `_<SNAPSHOT-NAME>_<INODE-NUMBER>`. Since filenames in general can't have
+ more than 255 characters, and `<node-id>` takes 13 characters, the long
+ snapshot names can take as much as 255 - 1 - 1 - 13 = 240.
+
+Ceph also provides some recursive accounting on directories for nested files
+and bytes. You can run the commands::
+
+ getfattr -n ceph.dir.rfiles /some/dir
+ getfattr -n ceph.dir.rbytes /some/dir
+
+to get the total number of nested files and their combined size, respectively.
+This makes the identification of large disk space consumers relatively quick,
+as no 'du' or similar recursive scan of the file system is required.
Finally, Ceph also allows quotas to be set on any directory in the system.
The quota can restrict the number of bytes or the number of files stored
@@ -203,7 +216,6 @@ For more information on Ceph, see the home page at
The Linux kernel client source tree is available at
- https://github.com/ceph/ceph-client.git
- - git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
and the source for the full system is at
https://github.com/ceph/ceph.git
diff --git a/Documentation/filesystems/cifs/index.rst b/Documentation/filesystems/cifs/index.rst
deleted file mode 100644
index 1c8597a679ab..000000000000
--- a/Documentation/filesystems/cifs/index.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-===============================
-CIFS
-===============================
-
-
-.. toctree::
- :maxdepth: 1
-
- ksmbd
- cifsroot
diff --git a/Documentation/filesystems/coda.rst b/Documentation/filesystems/coda.rst
index bdde7e4e010b..0db3c83a50e5 100644
--- a/Documentation/filesystems/coda.rst
+++ b/Documentation/filesystems/coda.rst
@@ -141,7 +141,7 @@ kernel support.
a process P which accessing a Coda file. It makes a system call which
traps to the OS kernel. Examples of such calls trapping to the kernel
are ``read``, ``write``, ``open``, ``close``, ``create``, ``mkdir``,
- ``rmdir``, ``chmod`` in a Unix ontext. Similar calls exist in the Win32
+ ``rmdir``, ``chmod`` in a Unix context. Similar calls exist in the Win32
environment, and are named ``CreateFile``.
Generally the operating system handles the request in a virtual
diff --git a/Documentation/filesystems/configfs.rst b/Documentation/filesystems/configfs.rst
index 1d3d6f4a82a9..ac22138de6a4 100644
--- a/Documentation/filesystems/configfs.rst
+++ b/Documentation/filesystems/configfs.rst
@@ -253,7 +253,7 @@ to be used.
If binary attribute is readable and the config_item provides a
ct_item_ops->read_bin_attribute() method, that method will be called
whenever userspace asks for a read(2) on the attribute. The converse
-will happen for write(2). The reads/writes are bufferred so only a
+will happen for write(2). The reads/writes are buffered so only a
single read/write will occur; the attributes' need not concern itself
with it.
@@ -289,7 +289,6 @@ config_item_type::
const char *name);
struct config_group *(*make_group)(struct config_group *group,
const char *name);
- int (*commit_item)(struct config_item *item);
void (*disconnect_notify)(struct config_group *group,
struct config_item *item);
void (*drop_item)(struct config_group *group,
@@ -486,50 +485,3 @@ up. Here, the heartbeat code calls configfs_depend_item(). If it
succeeds, then heartbeat knows the region is safe to give to ocfs2.
If it fails, it was being torn down anyway, and heartbeat can gracefully
pass up an error.
-
-Committable Items
-=================
-
-Note:
- Committable items are currently unimplemented.
-
-Some config_items cannot have a valid initial state. That is, no
-default values can be specified for the item's attributes such that the
-item can do its work. Userspace must configure one or more attributes,
-after which the subsystem can start whatever entity this item
-represents.
-
-Consider the FakeNBD device from above. Without a target address *and*
-a target device, the subsystem has no idea what block device to import.
-The simple example assumes that the subsystem merely waits until all the
-appropriate attributes are configured, and then connects. This will,
-indeed, work, but now every attribute store must check if the attributes
-are initialized. Every attribute store must fire off the connection if
-that condition is met.
-
-Far better would be an explicit action notifying the subsystem that the
-config_item is ready to go. More importantly, an explicit action allows
-the subsystem to provide feedback as to whether the attributes are
-initialized in a way that makes sense. configfs provides this as
-committable items.
-
-configfs still uses only normal filesystem operations. An item is
-committed via rename(2). The item is moved from a directory where it
-can be modified to a directory where it cannot.
-
-Any group that provides the ct_group_ops->commit_item() method has
-committable items. When this group appears in configfs, mkdir(2) will
-not work directly in the group. Instead, the group will have two
-subdirectories: "live" and "pending". The "live" directory does not
-support mkdir(2) or rmdir(2) either. It only allows rename(2). The
-"pending" directory does allow mkdir(2) and rmdir(2). An item is
-created in the "pending" directory. Its attributes can be modified at
-will. Userspace commits the item by renaming it into the "live"
-directory. At this point, the subsystem receives the ->commit_item()
-callback. If all required attributes are filled to satisfaction, the
-method returns zero and the item is moved to the "live" directory.
-
-As rmdir(2) does not work in the "live" directory, an item must be
-shutdown, or "uncommitted". Again, this is done via rename(2), this
-time from the "live" directory back to the "pending" one. The subsystem
-is notified by the ct_group_ops->uncommit_object() method.
diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst
index c04609d8ee24..5b283f3d1eb1 100644
--- a/Documentation/filesystems/dax.rst
+++ b/Documentation/filesystems/dax.rst
@@ -206,8 +206,6 @@ stall the CPU for an extended period, you should also not attempt to
implement direct_access.
These block devices may be used for inspiration:
-- brd: RAM backed block device driver
-- dcssblk: s390 dcss block device driver
- pmem: NVDIMM persistent memory driver
@@ -291,7 +289,7 @@ The DAX code does not work correctly on architectures which have virtually
mapped caches such as ARM, MIPS and SPARC.
Calling :c:func:`get_user_pages()` on a range of user memory that has been
-mmaped from a `DAX` file will fail when there are no 'struct page' to describe
+mmapped from a `DAX` file will fail when there are no 'struct page' to describe
those pages. This problem has been addressed in some device drivers
by adding optional struct page support for pages under the control of
the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of
diff --git a/Documentation/filesystems/debugfs.rst b/Documentation/filesystems/debugfs.rst
index 71b1fee56d2a..55f807293924 100644
--- a/Documentation/filesystems/debugfs.rst
+++ b/Documentation/filesystems/debugfs.rst
@@ -155,8 +155,8 @@ any code which does so in the mainline. Note that all files created with
debugfs_create_blob() are read-only.
If you want to dump a block of registers (something that happens quite
-often during development, even if little such code reaches mainline.
-Debugfs offers two functions: one to make a registers-only file, and
+often during development, even if little such code reaches mainline),
+debugfs offers two functions: one to make a registers-only file, and
another to insert a register block in the middle of another sequential
file::
@@ -183,7 +183,7 @@ The "base" argument may be 0, but you may want to build the reg32 array
using __stringify, and a number of register names (macros) are actually
byte offsets over a base for the register block.
-If you want to dump an u32 array in debugfs, you can create file with::
+If you want to dump a u32 array in debugfs, you can create a file with::
struct debugfs_u32_array {
u32 *array;
@@ -197,7 +197,7 @@ If you want to dump an u32 array in debugfs, you can create file with::
The "array" argument wraps a pointer to the array's data and the number
of its elements. Note: Once array is created its size can not be changed.
-There is a helper function to create device related seq_file::
+There is a helper function to create a device-related seq_file::
void debugfs_create_devm_seqfile(struct device *dev,
const char *name,
@@ -211,18 +211,16 @@ seq_file content.
There are a couple of other directory-oriented helper functions::
- struct dentry *debugfs_rename(struct dentry *old_dir,
- struct dentry *old_dentry,
- struct dentry *new_dir,
- const char *new_name);
+ struct dentry *debugfs_change_name(struct dentry *dentry,
+ const char *fmt, ...);
struct dentry *debugfs_create_symlink(const char *name,
struct dentry *parent,
const char *target);
-A call to debugfs_rename() will give a new name to an existing debugfs
-file, possibly in a different directory. The new_name must not exist prior
-to the call; the return value is old_dentry with updated information.
+A call to debugfs_change_name() will give a new name to an existing debugfs
+file, always in the same directory. The new_name must not exist prior
+to the call; the return value is 0 on success and -E... on failure.
Symbolic links can be created with debugfs_create_symlink().
There is one important thing that all debugfs users must take into account:
@@ -231,22 +229,15 @@ module is unloaded without explicitly removing debugfs entries, the result
will be a lot of stale pointers and no end of highly antisocial behavior.
So all debugfs users - at least those which can be built as modules - must
be prepared to remove all files and directories they create there. A file
-can be removed with::
+or directory can be removed with::
void debugfs_remove(struct dentry *dentry);
The dentry value can be NULL or an error value, in which case nothing will
-be removed.
-
-Once upon a time, debugfs users were required to remember the dentry
-pointer for every debugfs file they created so that all files could be
-cleaned up. We live in more civilized times now, though, and debugfs users
-can call::
-
- void debugfs_remove_recursive(struct dentry *dentry);
-
-If this function is passed a pointer for the dentry corresponding to the
-top-level directory, the entire hierarchy below that directory will be
-removed.
+be removed. Note that this function will recursively remove all files and
+directories underneath it. Previously, debugfs_remove_recursive() was used
+to perform that task, but this function is now just an alias to
+debugfs_remove(). debugfs_remove_recursive() should be considered
+deprecated.
.. [1] http://lwn.net/Articles/309298/
diff --git a/Documentation/filesystems/devpts.rst b/Documentation/filesystems/devpts.rst
index a03248ddfb4c..b6324ab1960d 100644
--- a/Documentation/filesystems/devpts.rst
+++ b/Documentation/filesystems/devpts.rst
@@ -5,8 +5,8 @@ The Devpts Filesystem
=====================
Each mount of the devpts filesystem is now distinct such that ptys
-and their indicies allocated in one mount are independent from ptys
-and their indicies in all other mounts.
+and their indices allocated in one mount are independent from ptys
+and their indices in all other mounts.
All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node
with permissions ``0000``.
diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst
index 504ba940c36c..6fdf0b02df43 100644
--- a/Documentation/filesystems/directory-locking.rst
+++ b/Documentation/filesystems/directory-locking.rst
@@ -11,127 +11,268 @@ When taking the i_rwsem on multiple non-directory objects, we
always acquire the locks in order by increasing address. We'll call
that "inode pointer" order in the following.
-For our purposes all operations fall in 5 classes:
-1) read access. Locking rules: caller locks directory we are accessing.
-The lock is taken shared.
+Primitives
+==========
-2) object creation. Locking rules: same as above, but the lock is taken
-exclusive.
+For our purposes all operations fall in 6 classes:
-3) object removal. Locking rules: caller locks parent, finds victim,
-locks victim and calls the method. Locks are exclusive.
+1. read access. Locking rules:
-4) rename() that is _not_ cross-directory. Locking rules: caller locks
-the parent and finds source and target. In case of exchange (with
-RENAME_EXCHANGE in flags argument) lock both. In any case,
-if the target already exists, lock it. If the source is a non-directory,
-lock it. If we need to lock both, lock them in inode pointer order.
-Then call the method. All locks are exclusive.
-NB: we might get away with locking the source (and target in exchange
-case) shared.
+ * lock the directory we are accessing (shared)
-5) link creation. Locking rules:
+2. object creation. Locking rules:
- * lock parent
- * check that source is not a directory
- * lock source
- * call the method.
+ * lock the directory we are accessing (exclusive)
-All locks are exclusive.
+3. object removal. Locking rules:
-6) cross-directory rename. The trickiest in the whole bunch. Locking
-rules:
+ * lock the parent (exclusive)
+ * find the victim
+ * lock the victim (exclusive)
- * lock the filesystem
- * lock parents in "ancestors first" order.
- * find source and target.
- * if old parent is equal to or is a descendent of target
- fail with -ENOTEMPTY
- * if new parent is equal to or is a descendent of source
- fail with -ELOOP
- * If it's an exchange, lock both the source and the target.
- * If the target exists, lock it. If the source is a non-directory,
- lock it. If we need to lock both, do so in inode pointer order.
- * call the method.
+4. link creation. Locking rules:
+
+ * lock the parent (exclusive)
+ * check that the source is not a directory
+ * lock the source (exclusive; probably could be weakened to shared)
-All ->i_rwsem are taken exclusive. Again, we might get away with locking
-the source (and target in exchange case) shared.
+5. rename that is _not_ cross-directory. Locking rules:
-The rules above obviously guarantee that all directories that are going to be
-read, modified or removed by method will be locked by caller.
+ * lock the parent (exclusive)
+ * find the source and target
+ * decide which of the source and target need to be locked.
+ The source needs to be locked if it's a non-directory, target - if it's
+ a non-directory or about to be removed.
+ * take the locks that need to be taken (exclusive), in inode pointer order
+ if need to take both (that can happen only when both source and target
+ are non-directories - the source because it wouldn't need to be locked
+ otherwise and the target because mixing directory and non-directory is
+ allowed only with RENAME_EXCHANGE, and that won't be removing the target).
+6. cross-directory rename. The trickiest in the whole bunch. Locking rules:
+
+ * lock the filesystem
+ * if the parents don't have a common ancestor, fail the operation.
+ * lock the parents in "ancestors first" order (exclusive). If neither is an
+ ancestor of the other, lock the parent of source first.
+ * find the source and target.
+ * verify that the source is not a descendent of the target and
+ target is not a descendent of source; fail the operation otherwise.
+ * lock the subdirectories involved (exclusive), source before target.
+ * lock the non-directories involved (exclusive), in inode pointer order.
+
+The rules above obviously guarantee that all directories that are going
+to be read, modified or removed by method will be locked by the caller.
+
+
+Splicing
+========
+
+There is one more thing to consider - splicing. It's not an operation
+in its own right; it may happen as part of lookup. We speak of the
+operations on directory trees, but we obviously do not have the full
+picture of those - especially for network filesystems. What we have
+is a bunch of subtrees visible in dcache and locking happens on those.
+Trees grow as we do operations; memory pressure prunes them. Normally
+that's not a problem, but there is a nasty twist - what should we do
+when one growing tree reaches the root of another? That can happen in
+several scenarios, starting from "somebody mounted two nested subtrees
+from the same NFS4 server and doing lookups in one of them has reached
+the root of another"; there's also open-by-fhandle stuff, and there's a
+possibility that directory we see in one place gets moved by the server
+to another and we run into it when we do a lookup.
+
+For a lot of reasons we want to have the same directory present in dcache
+only once. Multiple aliases are not allowed. So when lookup runs into
+a subdirectory that already has an alias, something needs to be done with
+dcache trees. Lookup is already holding the parent locked. If alias is
+a root of separate tree, it gets attached to the directory we are doing a
+lookup in, under the name we'd been looking for. If the alias is already
+a child of the directory we are looking in, it changes name to the one
+we'd been looking for. No extra locking is involved in these two cases.
+However, if it's a child of some other directory, the things get trickier.
+First of all, we verify that it is *not* an ancestor of our directory
+and fail the lookup if it is. Then we try to lock the filesystem and the
+current parent of the alias. If either trylock fails, we fail the lookup.
+If trylocks succeed, we detach the alias from its current parent and
+attach to our directory, under the name we are looking for.
+
+Note that splicing does *not* involve any modification of the filesystem;
+all we change is the view in dcache. Moreover, holding a directory locked
+exclusive prevents such changes involving its children and holding the
+filesystem lock prevents any changes of tree topology, other than having a
+root of one tree becoming a child of directory in another. In particular,
+if two dentries have been found to have a common ancestor after taking
+the filesystem lock, their relationship will remain unchanged until
+the lock is dropped. So from the directory operations' point of view
+splicing is almost irrelevant - the only place where it matters is one
+step in cross-directory renames; we need to be careful when checking if
+parents have a common ancestor.
+
+
+Multiple-filesystem stuff
+=========================
+
+For some filesystems a method can involve a directory operation on
+another filesystem; it may be ecryptfs doing operation in the underlying
+filesystem, overlayfs doing something to the layers, network filesystem
+using a local one as a cache, etc. In all such cases the operations
+on other filesystems must follow the same locking rules. Moreover, "a
+directory operation on this filesystem might involve directory operations
+on that filesystem" should be an asymmetric relation (or, if you will,
+it should be possible to rank the filesystems so that directory operation
+on a filesystem could trigger directory operations only on higher-ranked
+ones - in these terms overlayfs ranks lower than its layers, network
+filesystem ranks lower than whatever it caches on, etc.)
+
+
+Deadlock avoidance
+==================
If no directory is its own ancestor, the scheme above is deadlock-free.
Proof:
- First of all, at any moment we have a partial ordering of the
- objects - A < B iff A is an ancestor of B.
-
- That ordering can change. However, the following is true:
-
-(1) if object removal or non-cross-directory rename holds lock on A and
- attempts to acquire lock on B, A will remain the parent of B until we
- acquire the lock on B. (Proof: only cross-directory rename can change
- the parent of object and it would have to lock the parent).
-
-(2) if cross-directory rename holds the lock on filesystem, order will not
- change until rename acquires all locks. (Proof: other cross-directory
- renames will be blocked on filesystem lock and we don't start changing
- the order until we had acquired all locks).
-
-(3) locks on non-directory objects are acquired only after locks on
- directory objects, and are acquired in inode pointer order.
- (Proof: all operations but renames take lock on at most one
- non-directory object, except renames, which take locks on source and
- target in inode pointer order in the case they are not directories.)
-
-Now consider the minimal deadlock. Each process is blocked on
-attempt to acquire some lock and already holds at least one lock. Let's
-consider the set of contended locks. First of all, filesystem lock is
-not contended, since any process blocked on it is not holding any locks.
-Thus all processes are blocked on ->i_rwsem.
-
-By (3), any process holding a non-directory lock can only be
-waiting on another non-directory lock with a larger address. Therefore
-the process holding the "largest" such lock can always make progress, and
-non-directory objects are not included in the set of contended locks.
-
-Thus link creation can't be a part of deadlock - it can't be
-blocked on source and it means that it doesn't hold any locks.
-
-Any contended object is either held by cross-directory rename or
-has a child that is also contended. Indeed, suppose that it is held by
-operation other than cross-directory rename. Then the lock this operation
-is blocked on belongs to child of that object due to (1).
-
-It means that one of the operations is cross-directory rename.
-Otherwise the set of contended objects would be infinite - each of them
-would have a contended child and we had assumed that no object is its
-own descendent. Moreover, there is exactly one cross-directory rename
-(see above).
-
-Consider the object blocking the cross-directory rename. One
-of its descendents is locked by cross-directory rename (otherwise we
-would again have an infinite set of contended objects). But that
-means that cross-directory rename is taking locks out of order. Due
-to (2) the order hadn't changed since we had acquired filesystem lock.
-But locking rules for cross-directory rename guarantee that we do not
-try to acquire lock on descendent before the lock on ancestor.
-Contradiction. I.e. deadlock is impossible. Q.E.D.
-
+There is a ranking on the locks, such that all primitives take
+them in order of non-decreasing rank. Namely,
+
+ * rank ->i_rwsem of non-directories on given filesystem in inode pointer
+ order.
+ * put ->i_rwsem of all directories on a filesystem at the same rank,
+ lower than ->i_rwsem of any non-directory on the same filesystem.
+ * put ->s_vfs_rename_mutex at rank lower than that of any ->i_rwsem
+ on the same filesystem.
+ * among the locks on different filesystems use the relative
+ rank of those filesystems.
+
+For example, if we have NFS filesystem caching on a local one, we have
+
+ 1. ->s_vfs_rename_mutex of NFS filesystem
+ 2. ->i_rwsem of directories on that NFS filesystem, same rank for all
+ 3. ->i_rwsem of non-directories on that filesystem, in order of
+ increasing address of inode
+ 4. ->s_vfs_rename_mutex of local filesystem
+ 5. ->i_rwsem of directories on the local filesystem, same rank for all
+ 6. ->i_rwsem of non-directories on local filesystem, in order of
+ increasing address of inode.
+
+It's easy to verify that operations never take a lock with rank
+lower than that of an already held lock.
+
+Suppose deadlocks are possible. Consider the minimal deadlocked
+set of threads. It is a cycle of several threads, each blocked on a lock
+held by the next thread in the cycle.
+
+Since the locking order is consistent with the ranking, all
+contended locks in the minimal deadlock will be of the same rank,
+i.e. they all will be ->i_rwsem of directories on the same filesystem.
+Moreover, without loss of generality we can assume that all operations
+are done directly to that filesystem and none of them has actually
+reached the method call.
+
+In other words, we have a cycle of threads, T1,..., Tn,
+and the same number of directories (D1,...,Dn) such that
+
+ T1 is blocked on D1 which is held by T2
+
+ T2 is blocked on D2 which is held by T3
+
+ ...
+
+ Tn is blocked on Dn which is held by T1.
+
+Each operation in the minimal cycle must have locked at least
+one directory and blocked on attempt to lock another. That leaves
+only 3 possible operations: directory removal (locks parent, then
+child), same-directory rename killing a subdirectory (ditto) and
+cross-directory rename of some sort.
+
+There must be a cross-directory rename in the set; indeed,
+if all operations had been of the "lock parent, then child" sort
+we would have Dn a parent of D1, which is a parent of D2, which is
+a parent of D3, ..., which is a parent of Dn. Relationships couldn't
+have changed since the moment directory locks had been acquired,
+so they would all hold simultaneously at the deadlock time and
+we would have a loop.
+
+Since all operations are on the same filesystem, there can't be
+more than one cross-directory rename among them. Without loss of
+generality we can assume that T1 is the one doing a cross-directory
+rename and everything else is of the "lock parent, then child" sort.
+
+In other words, we have a cross-directory rename that locked
+Dn and blocked on attempt to lock D1, which is a parent of D2, which is
+a parent of D3, ..., which is a parent of Dn. Relationships between
+D1,...,Dn all hold simultaneously at the deadlock time. Moreover,
+cross-directory rename does not get to locking any directories until it
+has acquired filesystem lock and verified that directories involved have
+a common ancestor, which guarantees that ancestry relationships between
+all of them had been stable.
+
+Consider the order in which directories are locked by the
+cross-directory rename; parents first, then possibly their children.
+Dn and D1 would have to be among those, with Dn locked before D1.
+Which pair could it be?
+
+It can't be the parents - indeed, since D1 is an ancestor of Dn,
+it would be the first parent to be locked. Therefore at least one of the
+children must be involved and thus neither of them could be a descendent
+of another - otherwise the operation would not have progressed past
+locking the parents.
+
+It can't be a parent and its child; otherwise we would've had
+a loop, since the parents are locked before the children, so the parent
+would have to be a descendent of its child.
+
+It can't be a parent and a child of another parent either.
+Otherwise the child of the parent in question would've been a descendent
+of another child.
+
+That leaves only one possibility - namely, both Dn and D1 are
+among the children, in some order. But that is also impossible, since
+neither of the children is a descendent of another.
+
+That concludes the proof, since the set of operations with the
+properties required for a minimal deadlock can not exist.
+
+Note that the check for having a common ancestor in cross-directory
+rename is crucial - without it a deadlock would be possible. Indeed,
+suppose the parents are initially in different trees; we would lock the
+parent of source, then try to lock the parent of target, only to have
+an unrelated lookup splice a distant ancestor of source to some distant
+descendent of the parent of target. At that point we have cross-directory
+rename holding the lock on parent of source and trying to lock its
+distant ancestor. Add a bunch of rmdir() attempts on all directories
+in between (all of those would fail with -ENOTEMPTY, had they ever gotten
+the locks) and voila - we have a deadlock.
+
+Loop avoidance
+==============
These operations are guaranteed to avoid loop creation. Indeed,
the only operation that could introduce loops is cross-directory rename.
-Since the only new (parent, child) pair added by rename() is (new parent,
-source), such loop would have to contain these objects and the rest of it
-would have to exist before rename(). I.e. at the moment of loop creation
-rename() responsible for that would be holding filesystem lock and new parent
-would have to be equal to or a descendent of source. But that means that
-new parent had been equal to or a descendent of source since the moment when
-we had acquired filesystem lock and rename() would fail with -ELOOP in that
-case.
+Suppose after the operation there is a loop; since there hadn't been such
+loops before the operation, at least on of the nodes in that loop must've
+had its parent changed. In other words, the loop must be passing through
+the source or, in case of exchange, possibly the target.
+
+Since the operation has succeeded, neither source nor target could have
+been ancestors of each other. Therefore the chain of ancestors starting
+in the parent of source could not have passed through the target and
+vice versa. On the other hand, the chain of ancestors of any node could
+not have passed through the node itself, or we would've had a loop before
+the operation. But everything other than source and target has kept
+the parent after the operation, so the operation does not change the
+chains of ancestors of (ex-)parents of source and target. In particular,
+those chains must end after a finite number of steps.
+
+Now consider the loop created by the operation. It passes through either
+source or target; the next node in the loop would be the ex-parent of
+target or source resp. After that the loop would follow the chain of
+ancestors of that parent. But as we have just shown, that chain must
+end after a finite number of steps, which means that it can't be a part
+of any loop. Q.E.D.
While this locking scheme works for arbitrary DAGs, it relies on
ability to check that directory is a descendent of another object. Current
diff --git a/Documentation/filesystems/dlmfs.rst b/Documentation/filesystems/dlmfs.rst
index 28dd41a63be2..70d4e48242c3 100644
--- a/Documentation/filesystems/dlmfs.rst
+++ b/Documentation/filesystems/dlmfs.rst
@@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires most of its infrastructure.
:Project web page: http://ocfs2.wiki.kernel.org
:Tools web page: https://github.com/markfasheh/ocfs2-tools
-:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+:OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
@@ -36,7 +36,7 @@ None
Usage
=====
-If you're just interested in OCFS2, then please see ocfs2.txt. The
+If you're just interested in OCFS2, then please see ocfs2.rst. The
rest of this document will be geared towards those who want to use
dlmfs for easy to setup and easy to use clustered locking in
userspace.
diff --git a/Documentation/filesystems/efivarfs.rst b/Documentation/filesystems/efivarfs.rst
index 0551985821b8..f646c3f0980f 100644
--- a/Documentation/filesystems/efivarfs.rst
+++ b/Documentation/filesystems/efivarfs.rst
@@ -40,4 +40,4 @@ accidentally.
*See also:*
- Documentation/admin-guide/acpi/ssdt-overlays.rst
-- Documentation/ABI/stable/sysfs-firmware-efi-vars
+- Documentation/ABI/removed/sysfs-firmware-efi-vars
diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst
index 05e03d54af1a..08194f194b94 100644
--- a/Documentation/filesystems/erofs.rst
+++ b/Documentation/filesystems/erofs.rst
@@ -30,12 +30,18 @@ It is implemented to be a better choice for the following scenarios:
especially for those embedded devices with limited memory and high-density
hosts with numerous containers.
-Here is the main features of EROFS:
+Here are the main features of EROFS:
- Little endian on-disk design;
- - 4KiB block size and 32-bit block addresses, therefore 16TiB address space
- at most for now;
+ - Block-based distribution and file-based distribution over fscache are
+ supported;
+
+ - Support multiple devices to refer to external blobs, which can be used
+ for container images;
+
+ - 32-bit block addresses for each device, therefore 16TiB address space at
+ most with 4KiB block size for now;
- Two inode layouts for different requirements:
@@ -50,19 +56,26 @@ Here is the main features of EROFS:
Metadata reserved 8 bytes 18 bytes
===================== ============ ======================================
- - Metadata and data could be mixed as an option;
-
- - Support extended attributes (xattrs) as an option;
+ - Support extended attributes as an option;
- - Support tailpacking data and xattr inline compared to byte-addressed
- unaligned metadata or smaller block size alternatives;
+ - Support a bloom filter that speeds up negative extended attribute lookups;
- - Support POSIX.1e ACLs by using xattrs;
+ - Support POSIX.1e ACLs by using extended attributes;
- Support transparent data compression as an option:
- LZ4 and MicroLZMA algorithms can be used on a per-file basis; In addition,
- inplace decompression is also supported to avoid bounce compressed buffers
- and page cache thrashing.
+ LZ4, MicroLZMA and DEFLATE algorithms can be used on a per-file basis; In
+ addition, inplace decompression is also supported to avoid bounce compressed
+ buffers and unnecessary page cache thrashing.
+
+ - Support chunk-based data deduplication and rolling-hash compressed data
+ deduplication;
+
+ - Support tailpacking inline compared to byte-addressed unaligned metadata
+ or smaller block size alternatives;
+
+ - Support merging tail-end data into a special inode as fragments.
+
+ - Support large folios to make use of THPs (Transparent Hugepages);
- Support direct I/O on uncompressed files to avoid double caching for loop
devices;
@@ -70,8 +83,6 @@ Here is the main features of EROFS:
- Support FSDAX on uncompressed images for secure containers and ramdisks in
order to get rid of unnecessary page cache.
- - Support multiple devices for multi blob container images;
-
- Support file-based on-demand loading with the Fscache infrastructure.
The following git tree provides the file system user-space tools under
@@ -80,6 +91,10 @@ compatibility checking tool (fsck.erofs), and a debugging tool (dump.erofs):
- git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
+For more information, please also refer to the documentation site:
+
+- https://erofs.docs.kernel.org
+
Bugs and patches are welcome, please kindly help us and send to the following
linux-erofs mailing list:
@@ -101,7 +116,7 @@ cache_strategy=%s Select a strategy for cached decompression from now on:
cluster for further reading. It still does
in-place I/O decompression for the rest
compressed physical clusters;
- readaround Cache the both ends of incomplete compressed
+ readaround Cache both ends of incomplete compressed
physical clusters for further reading.
It still does in-place I/O decompression
for the rest compressed physical clusters.
@@ -111,6 +126,9 @@ dax={always,never} Use direct access (no page cache). See
dax A legacy option which is an alias for ``dax=always``.
device=%s Specify a path to an extra device to be used together.
fsid=%s Specify a filesystem image ID for Fscache back-end.
+domain_id=%s Specify a domain ID in fscache mode so that different images
+ with the same blobs under a given domain ID can share storage.
+fsoffset=%llu Specify block-aligned filesystem offset for the primary device.
=================== =========================================================
Sysfs Entries
@@ -186,7 +204,7 @@ may not. All metadatas can be now observed in two different spaces (views):
| |
|__________________| 64 bytes
- Xattrs, extents, data inline are followed by the corresponding inode with
+ Xattrs, extents, data inline are placed after the corresponding inode with
proper alignment, and they could be optional for different data mappings.
_currently_ total 5 data layouts are supported:
@@ -257,9 +275,41 @@ details.)
By the way, chunk-based files are all uncompressed for now.
+Long extended attribute name prefixes
+-------------------------------------
+There are use cases where extended attributes with different values can have
+only a few common prefixes (such as overlayfs xattrs). The predefined prefixes
+work inefficiently in both image size and runtime performance in such cases.
+
+The long xattr name prefixes feature is introduced to address this issue. The
+overall idea is that, apart from the existing predefined prefixes, the xattr
+entry could also refer to user-specified long xattr name prefixes, e.g.
+"trusted.overlay.".
+
+When referring to a long xattr name prefix, the highest bit (bit 7) of
+erofs_xattr_entry.e_name_index is set, while the lower bits (bit 0-6) as a whole
+represent the index of the referred long name prefix among all long name
+prefixes. Therefore, only the trailing part of the name apart from the long
+xattr name prefix is stored in erofs_xattr_entry.e_name, which could be empty if
+the full xattr name matches exactly as its long xattr name prefix.
+
+All long xattr prefixes are stored one by one in the packed inode as long as
+the packed inode is valid, or in the meta inode otherwise. The
+xattr_prefix_count (of the on-disk superblock) indicates the total number of
+long xattr name prefixes, while (xattr_prefix_start * 4) indicates the start
+offset of long name prefixes in the packed/meta inode. Note that, long extended
+attribute name prefixes are disabled if xattr_prefix_count is 0.
+
+Each long name prefix is stored in the format: ALIGN({__le16 len, data}, 4),
+where len represents the total size of the data part. The data part is actually
+represented by 'struct erofs_xattr_long_prefix', where base_index represents the
+index of the predefined xattr name prefix, e.g. EROFS_XATTR_INDEX_TRUSTED for
+"trusted.overlay." long name prefix, while the infix string keeps the string
+after stripping the short prefix, e.g. "overlay." for the example above.
+
Data compression
----------------
-EROFS implements LZ4 fixed-sized output compression which generates fixed-sized
+EROFS implements fixed-sized output compression which generates fixed-sized
compressed data blocks from variable-sized input in contrast to other existing
fixed-sized input solutions. Relatively higher compression ratios can be gotten
by using fixed-sized output compression since nowadays popular data compression
@@ -314,3 +364,6 @@ to understand its delta0 is constantly 1, as illustrated below::
If another HEAD follows a HEAD lcluster, there is no room to record CBLKCNT,
but it's easy to know the size of such pcluster is 1 lcluster as well.
+
+Since Linux v6.1, each pcluster can be used for multiple variable-sized extents,
+therefore it can be used for compressed data deduplication.
diff --git a/Documentation/filesystems/ext4/atomic_writes.rst b/Documentation/filesystems/ext4/atomic_writes.rst
new file mode 100644
index 000000000000..ae8995740aa8
--- /dev/null
+++ b/Documentation/filesystems/ext4/atomic_writes.rst
@@ -0,0 +1,225 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _atomic_writes:
+
+Atomic Block Writes
+-------------------------
+
+Introduction
+~~~~~~~~~~~~
+
+Atomic (untorn) block writes ensure that either the entire write is committed
+to disk or none of it is. This prevents "torn writes" during power loss or
+system crashes. The ext4 filesystem supports atomic writes (only with Direct
+I/O) on regular files with extents, provided the underlying storage device
+supports hardware atomic writes. This is supported in the following two ways:
+
+1. **Single-fsblock Atomic Writes**:
+ EXT4 supports atomic write operations with a single filesystem block since
+ v6.13. In this the atomic write unit minimum and maximum sizes are both set
+ to filesystem blocksize.
+ e.g. doing atomic write of 16KB with 16KB filesystem blocksize on 64KB
+ pagesize system is possible.
+
+2. **Multi-fsblock Atomic Writes with Bigalloc**:
+ EXT4 now also supports atomic writes spanning multiple filesystem blocks
+ using a feature known as bigalloc. The atomic write unit's minimum and
+ maximum sizes are determined by the filesystem block size and cluster size,
+ based on the underlying device’s supported atomic write unit limits.
+
+Requirements
+~~~~~~~~~~~~
+
+Basic requirements for atomic writes in ext4:
+
+ 1. The extents feature must be enabled (default for ext4)
+ 2. The underlying block device must support atomic writes
+ 3. For single-fsblock atomic writes:
+
+ 1. A filesystem with appropriate block size (up to the page size)
+ 4. For multi-fsblock atomic writes:
+
+ 1. The bigalloc feature must be enabled
+ 2. The cluster size must be appropriately configured
+
+NOTE: EXT4 does not support software or COW based atomic write, which means
+atomic writes on ext4 are only supported if underlying storage device supports
+it.
+
+Multi-fsblock Implementation Details
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bigalloc feature changes ext4 to allocate in units of multiple filesystem
+blocks, also known as clusters. With bigalloc each bit within block bitmap
+represents a cluster (power of 2 number of blocks) rather than individual
+filesystem blocks.
+EXT4 supports multi-fsblock atomic writes with bigalloc, subject to the
+following constraints. The minimum atomic write size is the larger of the fs
+block size and the minimum hardware atomic write unit; and the maximum atomic
+write size is smaller of the bigalloc cluster size and the maximum hardware
+atomic write unit. Bigalloc ensures that all allocations are aligned to the
+cluster size, which satisfies the LBA alignment requirements of the hardware
+device if the start of the partition/logical volume is itself aligned correctly.
+
+Here is the block allocation strategy in bigalloc for atomic writes:
+
+ * For regions with fully mapped extents, no additional work is needed
+ * For append writes, a new mapped extent is allocated
+ * For regions that are entirely holes, unwritten extent is created
+ * For large unwritten extents, the extent gets split into two unwritten
+ extents of appropriate requested size
+ * For mixed mapping regions (combinations of holes, unwritten extents, or
+ mapped extents), ext4_map_blocks() is called in a loop with
+ EXT4_GET_BLOCKS_ZERO flag to convert the region into a single contiguous
+ mapped extent by writing zeroes to it and converting any unwritten extents to
+ written, if found within the range.
+
+Note: Writing on a single contiguous underlying extent, whether mapped or
+unwritten, is not inherently problematic. However, writing to a mixed mapping
+region (i.e. one containing a combination of mapped and unwritten extents)
+must be avoided when performing atomic writes.
+
+The reason is that, atomic writes when issued via pwritev2() with the RWF_ATOMIC
+flag, requires that either all data is written or none at all. In the event of
+a system crash or unexpected power loss during the write operation, the affected
+region (when later read) must reflect either the complete old data or the
+complete new data, but never a mix of both.
+
+To enforce this guarantee, we ensure that the write target is backed by
+a single, contiguous extent before any data is written. This is critical because
+ext4 defers the conversion of unwritten extents to written extents until the I/O
+completion path (typically in ->end_io()). If a write is allowed to proceed over
+a mixed mapping region (with mapped and unwritten extents) and a failure occurs
+mid-write, the system could observe partially updated regions after reboot, i.e.
+new data over mapped areas, and stale (old) data over unwritten extents that
+were never marked written. This violates the atomicity and/or torn write
+prevention guarantee.
+
+To prevent such torn writes, ext4 proactively allocates a single contiguous
+extent for the entire requested region in ``ext4_iomap_alloc`` via
+``ext4_map_blocks_atomic()``. EXT4 also force commits the current journalling
+transaction in case if allocation is done over mixed mapping. This ensures any
+pending metadata updates (like unwritten to written extents conversion) in this
+range are in consistent state with the file data blocks, before performing the
+actual write I/O. If the commit fails, the whole I/O must be aborted to prevent
+from any possible torn writes.
+Only after this step, the actual data write operation is performed by the iomap.
+
+Handling Split Extents Across Leaf Blocks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There can be a special edge case where we have logically and physically
+contiguous extents stored in separate leaf nodes of the on-disk extent tree.
+This occurs because on-disk extent tree merges only happens within the leaf
+blocks except for a case where we have 2-level tree which can get merged and
+collapsed entirely into the inode.
+If such a layout exists and, in the worst case, the extent status cache entries
+are reclaimed due to memory pressure, ``ext4_map_blocks()`` may never return
+a single contiguous extent for these split leaf extents.
+
+To address this edge case, a new get block flag
+``EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS flag`` is added to enhance the
+``ext4_map_query_blocks()`` lookup behavior.
+
+This new get block flag allows ``ext4_map_blocks()`` to first check if there is
+an entry in the extent status cache for the full range.
+If not present, it consults the on-disk extent tree using
+``ext4_map_query_blocks()``.
+If the located extent is at the end of a leaf node, it probes the next logical
+block (lblk) to detect a contiguous extent in the adjacent leaf.
+
+For now only one additional leaf block is queried to maintain efficiency, as
+atomic writes are typically constrained to small sizes
+(e.g. [blocksize, clustersize]).
+
+
+Handling Journal transactions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To support multi-fsblock atomic writes, we ensure enough journal credits are
+reserved during:
+
+ 1. Block allocation time in ``ext4_iomap_alloc()``. We first query if there
+ could be a mixed mapping for the underlying requested range. If yes, then we
+ reserve credits of up to ``m_len``, assuming every alternate block can be
+ an unwritten extent followed by a hole.
+
+ 2. During ``->end_io()`` call, we make sure a single transaction is started for
+ doing unwritten-to-written conversion. The loop for conversion is mainly
+ only required to handle a split extent across leaf blocks.
+
+How to
+~~~~~~
+
+Creating Filesystems with Atomic Write Support
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+First check the atomic write units supported by block device.
+See :ref:`atomic_write_bdev_support` for more details.
+
+For single-fsblock atomic writes with a larger block size
+(on systems with block size < page size):
+
+.. code-block:: bash
+
+ # Create an ext4 filesystem with a 16KB block size
+ # (requires page size >= 16KB)
+ mkfs.ext4 -b 16384 /dev/device
+
+For multi-fsblock atomic writes with bigalloc:
+
+.. code-block:: bash
+
+ # Create an ext4 filesystem with bigalloc and 64KB cluster size
+ mkfs.ext4 -F -O bigalloc -b 4096 -C 65536 /dev/device
+
+Where ``-b`` specifies the block size, ``-C`` specifies the cluster size in bytes,
+and ``-O bigalloc`` enables the bigalloc feature.
+
+Application Interface
+^^^^^^^^^^^^^^^^^^^^^
+
+Applications can use the ``pwritev2()`` system call with the ``RWF_ATOMIC`` flag
+to perform atomic writes:
+
+.. code-block:: c
+
+ pwritev2(fd, iov, iovcnt, offset, RWF_ATOMIC);
+
+The write must be aligned to the filesystem's block size and not exceed the
+filesystem's maximum atomic write unit size.
+See ``generic_atomic_write_valid()`` for more details.
+
+``statx()`` system call with ``STATX_WRITE_ATOMIC`` flag can provide following
+details:
+
+ * ``stx_atomic_write_unit_min``: Minimum size of an atomic write request.
+ * ``stx_atomic_write_unit_max``: Maximum size of an atomic write request.
+ * ``stx_atomic_write_segments_max``: Upper limit for segments. The number of
+ separate memory buffers that can be gathered into a write operation
+ (e.g., the iovcnt parameter for IOV_ITER). Currently, this is always set to one.
+
+The STATX_ATTR_WRITE_ATOMIC flag in ``statx->attributes`` is set if atomic
+writes are supported.
+
+.. _atomic_write_bdev_support:
+
+Hardware Support
+~~~~~~~~~~~~~~~~
+
+The underlying storage device must support atomic write operations.
+Modern NVMe and SCSI devices often provide this capability.
+The Linux kernel exposes this information through sysfs:
+
+* ``/sys/block/<device>/queue/atomic_write_unit_min`` - Minimum atomic write size
+* ``/sys/block/<device>/queue/atomic_write_unit_max`` - Maximum atomic write size
+
+Nonzero values for these attributes indicate that the device supports
+atomic writes.
+
+See Also
+~~~~~~~~
+
+* :doc:`bigalloc` - Documentation on the bigalloc feature
+* :doc:`allocators` - Documentation on block allocation in ext4
+* Support for atomic block writes in 6.13:
+ https://lwn.net/Articles/1009298/
diff --git a/Documentation/filesystems/ext4/bitmaps.rst b/Documentation/filesystems/ext4/bitmaps.rst
index 91c45d86e9bb..9d7d7b083a25 100644
--- a/Documentation/filesystems/ext4/bitmaps.rst
+++ b/Documentation/filesystems/ext4/bitmaps.rst
@@ -19,10 +19,3 @@ necessarily the case that no blocks are in use -- if ``meta_bg`` is set,
the bitmaps and group descriptor live inside the group. Unfortunately,
ext2fs_test_block_bitmap2() will return '0' for those locations,
which produces confusing debugfs output.
-
-Inode Table
------------
-Inode tables are statically allocated at mkfs time. Each block group
-descriptor points to the start of the table, and the superblock records
-the number of inodes per group. See the section on inodes for more
-information.
diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst
index 46d78f860623..7cbf0b2b778e 100644
--- a/Documentation/filesystems/ext4/blockgroup.rst
+++ b/Documentation/filesystems/ext4/blockgroup.rst
@@ -1,7 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0
+Block Groups
+------------
+
Layout
-------
+~~~~~~
The layout of a standard block group is approximately as follows (each
of these fields is discussed in a separate section below):
@@ -60,7 +63,7 @@ groups (flex_bg). Leftover space is used for file data blocks, indirect
block maps, extent tree blocks, and extended attributes.
Flexible Block Groups
----------------------
+~~~~~~~~~~~~~~~~~~~~~
Starting in ext4, there is a new feature called flexible block groups
(flex_bg). In a flex_bg, several block groups are tied together as one
@@ -78,7 +81,7 @@ if flex_bg is enabled. The number of block groups that make up a
flex_bg is given by 2 ^ ``sb.s_log_groups_per_flex``.
Meta Block Groups
------------------
+~~~~~~~~~~~~~~~~~
Without the option META_BG, for safety concerns, all block group
descriptors copies are kept in the first block group. Given the default
@@ -105,9 +108,9 @@ descriptors. Instead, the superblock and a single block group descriptor
block is placed at the beginning of the first, second, and last block
groups in a meta-block group. A meta-block group is a collection of
block groups which can be described by a single block group descriptor
-block. Since the size of the block group descriptor structure is 32
-bytes, a meta-block group contains 32 block groups for filesystems with
-a 1KB block size, and 128 block groups for filesystems with a 4KB
+block. Since the size of the block group descriptor structure is 64
+bytes, a meta-block group contains 16 block groups for filesystems with
+a 1KB block size, and 64 block groups for filesystems with a 4KB
blocksize. Filesystems can either be created using this new block group
descriptor layout, or existing filesystems can be resized on-line, and
the field s_first_meta_bg in the superblock will indicate the first
@@ -117,7 +120,7 @@ Please see an important note about ``BLOCK_UNINIT`` in the section about
block and inode bitmaps.
Lazy Block Group Initialization
--------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A new feature for ext4 are three block group descriptor flags that
enable mkfs to skip initializing other parts of the block group
diff --git a/Documentation/filesystems/ext4/directory.rst b/Documentation/filesystems/ext4/directory.rst
index 6eece8e31df8..9b003a4d453f 100644
--- a/Documentation/filesystems/ext4/directory.rst
+++ b/Documentation/filesystems/ext4/directory.rst
@@ -183,10 +183,10 @@ in the place where the name normally goes. The structure is
- det_checksum
- Directory leaf block checksum.
-The leaf directory block checksum is calculated against the FS UUID, the
-directory's inode number, the directory's inode generation number, and
-the entire directory entry block up to (but not including) the fake
-directory entry.
+The leaf directory block checksum is calculated against the FS UUID (or
+the checksum seed, if that feature is enabled for the fs), the directory's
+inode number, the directory's inode generation number, and the entire
+directory entry block up to (but not including) the fake directory entry.
Hash Tree Directories
~~~~~~~~~~~~~~~~~~~~~
@@ -196,12 +196,12 @@ new feature was added to ext3 to provide a faster (but peculiar)
balanced tree keyed off a hash of the directory entry name. If the
EXT4_INDEX_FL (0x1000) flag is set in the inode, this directory uses a
hashed btree (htree) to organize and find directory entries. For
-backwards read-only compatibility with ext2, this tree is actually
-hidden inside the directory file, masquerading as “empty” directory data
-blocks! It was stated previously that the end of the linear directory
-entry table was signified with an entry pointing to inode 0; this is
-(ab)used to fool the old linear-scan algorithm into thinking that the
-rest of the directory block is empty so that it moves on.
+backwards read-only compatibility with ext2, interior tree nodes are actually
+hidden inside the directory file, masquerading as “empty” directory entries
+spanning the whole block. It was stated previously that directory entries
+with the inode set to 0 are treated as unused entries; this is (ab)used to
+fool the old linear-scan algorithm into skipping over those blocks containing
+the interior tree node data.
The root of the tree always lives in the first data block of the
directory. By ext2 custom, the '.' and '..' entries must appear at the
@@ -209,24 +209,24 @@ beginning of this first block, so they are put here as two
``struct ext4_dir_entry_2`` s and not stored in the tree. The rest of
the root node contains metadata about the tree and finally a hash->block
map to find nodes that are lower in the htree. If
-``dx_root.info.indirect_levels`` is non-zero then the htree has two
-levels; the data block pointed to by the root node's map is an interior
-node, which is indexed by a minor hash. Interior nodes in this tree
-contains a zeroed out ``struct ext4_dir_entry_2`` followed by a
-minor_hash->block map to find leafe nodes. Leaf nodes contain a linear
-array of all ``struct ext4_dir_entry_2``; all of these entries
-(presumably) hash to the same value. If there is an overflow, the
-entries simply overflow into the next leaf node, and the
-least-significant bit of the hash (in the interior node map) that gets
-us to this next leaf node is set.
-
-To traverse the directory as a htree, the code calculates the hash of
-the desired file name and uses it to find the corresponding block
-number. If the tree is flat, the block is a linear array of directory
-entries that can be searched; otherwise, the minor hash of the file name
-is computed and used against this second block to find the corresponding
-third block number. That third block number will be a linear array of
-directory entries.
+``dx_root.info.indirect_levels`` is non-zero then the htree has that many
+levels and the blocks pointed to by the root node's map are interior nodes.
+These interior nodes have a zeroed out ``struct ext4_dir_entry_2`` followed by
+a hash->block map to find nodes of the next level. Leaf nodes look like
+classic linear directory blocks, but all of its entries have a hash value
+equal or greater than the indicated hash of the parent node.
+
+The actual hash value for an entry name is only 31 bits, the least-significant
+bit is set to 0. However, if there is a hash collision between directory
+entries, the least-significant bit may get set to 1 on interior nodes in the
+case where these two (or more) hash-colliding entries do not fit into one leaf
+node and must be split across multiple nodes.
+
+To look up a name in such a htree, the code calculates the hash of the desired
+file name and uses it to find the leaf node with the range of hash values the
+calculated hash falls into (in other words, a lookup works basically the same
+as it would in a B-Tree keyed by the hash value), and possibly also scanning
+the leaf nodes that follow (in tree order) in case of hash collisions.
To traverse the directory as a linear array (such as the old code does),
the code simply reads every data block in the directory. The blocks used
@@ -319,7 +319,8 @@ of a data block:
* - 0x24
- __le32
- block
- - The block number (within the directory file) that goes with hash=0.
+ - The block number (within the directory file) that lead to the left-most
+ leaf node, i.e. the leaf containing entries with the lowest hash values.
* - 0x28
- struct dx_entry
- entries[0]
@@ -442,7 +443,7 @@ The dx_tail structure is 8 bytes long and looks like this:
* - 0x0
- u32
- dt_reserved
- - Zero.
+ - Unused (but still part of the checksum curiously).
* - 0x4
- __le32
- dt_checksum
@@ -450,4 +451,4 @@ The dx_tail structure is 8 bytes long and looks like this:
The checksum is calculated against the FS UUID, the htree index header
(dx_root or dx_node), all of the htree indices (dx_entry) that are in
-use, and the tail block (dx_tail).
+use, and the tail block (dx_tail) with the dt_checksum initially set to 0.
diff --git a/Documentation/filesystems/ext4/dynamic.rst b/Documentation/filesystems/ext4/dynamic.rst
index bb0c84333341..bbad439aada2 100644
--- a/Documentation/filesystems/ext4/dynamic.rst
+++ b/Documentation/filesystems/ext4/dynamic.rst
@@ -6,7 +6,9 @@ Dynamic Structures
Dynamic metadata are created on the fly when files and blocks are
allocated to files.
-.. include:: inodes.rst
-.. include:: ifork.rst
-.. include:: directory.rst
-.. include:: attributes.rst
+.. toctree::
+
+ inodes
+ ifork
+ directory
+ attributes
diff --git a/Documentation/filesystems/ext4/globals.rst b/Documentation/filesystems/ext4/globals.rst
index b17418974fd3..c6a6abce818a 100644
--- a/Documentation/filesystems/ext4/globals.rst
+++ b/Documentation/filesystems/ext4/globals.rst
@@ -6,9 +6,12 @@ Global Structures
The filesystem is sharded into a number of block groups, each of which
have static metadata at fixed locations.
-.. include:: super.rst
-.. include:: group_descr.rst
-.. include:: bitmaps.rst
-.. include:: mmp.rst
-.. include:: journal.rst
-.. include:: orphan.rst
+.. toctree::
+
+ super
+ group_descr
+ bitmaps
+ inode_table
+ mmp
+ journal
+ orphan
diff --git a/Documentation/filesystems/ext4/index.rst b/Documentation/filesystems/ext4/index.rst
index 705d813d558f..1ff8150c50e9 100644
--- a/Documentation/filesystems/ext4/index.rst
+++ b/Documentation/filesystems/ext4/index.rst
@@ -5,7 +5,7 @@ ext4 Data Structures and Algorithms
===================================
.. toctree::
- :maxdepth: 6
+ :maxdepth: 2
:numbered:
about
diff --git a/Documentation/filesystems/ext4/inode_table.rst b/Documentation/filesystems/ext4/inode_table.rst
new file mode 100644
index 000000000000..f7900a52c0d5
--- /dev/null
+++ b/Documentation/filesystems/ext4/inode_table.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Inode Table
+-----------
+
+Inode tables are statically allocated at mkfs time. Each block group
+descriptor points to the start of the table, and the superblock records
+the number of inodes per group. See :doc:`inode documentation <inodes>`
+for more information on inode table layout.
diff --git a/Documentation/filesystems/ext4/inodes.rst b/Documentation/filesystems/ext4/inodes.rst
index cfc6c1659931..55cd5c380e92 100644
--- a/Documentation/filesystems/ext4/inodes.rst
+++ b/Documentation/filesystems/ext4/inodes.rst
@@ -297,6 +297,8 @@ The ``i_flags`` field is a combination of these values:
- Inode has inline data (EXT4_INLINE_DATA_FL).
* - 0x20000000
- Create children with the same project ID (EXT4_PROJINHERIT_FL).
+ * - 0x40000000
+ - Use case-insensitive lookups for directory contents (EXT4_CASEFOLD_FL).
* - 0x80000000
- Reserved for ext4 library (EXT4_RESERVED_FL).
* -
diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst
index a6bef5293a60..6e8fb2d4b46f 100644
--- a/Documentation/filesystems/ext4/journal.rst
+++ b/Documentation/filesystems/ext4/journal.rst
@@ -260,8 +260,13 @@ which is 1024 bytes long:
- s_num_fc_blocks
- Number of fast commit blocks in the journal.
* - 0x58
+ - __be32
+ - s_head
+ - Block number of the head (first unused block) of the journal, only
+ up-to-date when the journal is empty.
+ * - 0x5C
- __u32
- - s_padding[42]
+ - s_padding[40]
-
* - 0xFC
- __be32
diff --git a/Documentation/filesystems/ext4/overview.rst b/Documentation/filesystems/ext4/overview.rst
index 0fad6eda6e15..171c3963d7f6 100644
--- a/Documentation/filesystems/ext4/overview.rst
+++ b/Documentation/filesystems/ext4/overview.rst
@@ -16,12 +16,15 @@ All fields in ext4 are written to disk in little-endian order. HOWEVER,
all fields in jbd2 (the journal) are written to disk in big-endian
order.
-.. include:: blocks.rst
-.. include:: blockgroup.rst
-.. include:: special_inodes.rst
-.. include:: allocators.rst
-.. include:: checksums.rst
-.. include:: bigalloc.rst
-.. include:: inlinedata.rst
-.. include:: eainode.rst
-.. include:: verity.rst
+.. toctree::
+
+ blocks
+ blockgroup
+ special_inodes
+ allocators
+ checksums
+ bigalloc
+ inlinedata
+ eainode
+ verity
+ atomic_writes
diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst
index 0152888cac29..9a59cded9bd7 100644
--- a/Documentation/filesystems/ext4/super.rst
+++ b/Documentation/filesystems/ext4/super.rst
@@ -328,9 +328,13 @@ The ext4 superblock is laid out as follows in
- s_checksum_type
- Metadata checksum algorithm type. The only valid value is 1 (crc32c).
* - 0x176
- - __le16
- - s_reserved_pad
- -
+ - \_\_u8
+ - s\_encryption\_level
+ - Versioning level for encryption.
+ * - 0x177
+ - \_\_u8
+ - s\_reserved\_pad
+ - Padding to next 32bits.
* - 0x178
- __le64
- s_kbytes_written
@@ -466,9 +470,13 @@ The ext4 superblock is laid out as follows in
- s_last_error_time_hi
- Upper 8 bits of the s_last_error_time field.
* - 0x27A
- - __u8
- - s_pad[2]
- - Zero padding.
+ - \_\_u8
+ - s\_first\_error\_errcode
+ -
+ * - 0x27B
+ - \_\_u8
+ - s\_last\_error\_errcode
+ -
* - 0x27C
- __le16
- s_encoding
@@ -663,7 +671,9 @@ following:
* - 0x8000
- Data in inode (INCOMPAT_INLINE_DATA).
* - 0x10000
- - Encrypted inodes are present on the filesystem. (INCOMPAT_ENCRYPT).
+ - Encrypted inodes can be present. (INCOMPAT_ENCRYPT).
+ * - 0x20000
+ - Directories can be marked case-insensitive. (INCOMPAT_CASEFOLD).
.. _super_rocompat:
@@ -772,7 +782,7 @@ The ``s_default_mount_opts`` field is any combination of the following:
* - 0x0010
- Do not support 32-bit UIDs. (EXT4_DEFM_UID16)
* - 0x0020
- - All data and metadata are commited to the journal.
+ - All data and metadata are committed to the journal.
(EXT4_DEFM_JMODE_DATA)
* - 0x0040
- All data are flushed to the disk before metadata are committed to the
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 17df9a02ccff..cb90d1ae82d0 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -1,8 +1,11 @@
.. SPDX-License-Identifier: GPL-2.0
-==========================================
-WHAT IS Flash-Friendly File System (F2FS)?
-==========================================
+=================================
+Flash-Friendly File System (F2FS)
+=================================
+
+Overview
+========
NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have
been equipped on a variety systems ranging from mobile to server systems. Since
@@ -25,10 +28,14 @@ a consistency checking tool (fsck.f2fs), and a debugging tool (dump.f2fs).
- git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git
-For reporting bugs and sending patches, please use the following mailing list:
+For sending patches, please use the following mailing list:
- linux-f2fs-devel@lists.sourceforge.net
+For reporting bugs, please use the following f2fs bug tracker link:
+
+- https://bugzilla.kernel.org/enter_bug.cgi?product=File%20System&component=f2fs
+
Background and Design issues
============================
@@ -122,9 +129,7 @@ norecovery Disable the roll-forward recovery routine, mounted read-
discard/nodiscard Enable/disable real-time discard in f2fs, if discard is
enabled, f2fs will issue discard/TRIM commands when a
segment is cleaned.
-no_heap Disable heap-style segment allocation which finds free
- segments for data from the beginning of main area, while
- for node from the end of main area.
+heap/no_heap Deprecated.
nouser_xattr Disable Extended User Attributes. Note: xattr is enabled
by default if CONFIG_F2FS_FS_XATTR is selected.
noacl Disable POSIX Access Control List. Note: acl is enabled
@@ -154,6 +159,8 @@ nobarrier This option can be used if underlying storage guarantees
If this option is set, no cache_flush commands are issued
but f2fs still guarantees the write ordering of all the
data writes.
+barrier If this option is set, cache_flush commands are allowed to be
+ issued.
fastboot This option is used when a system wants to reduce mount
time as much as possible, even though normal performance
can be sacrificed.
@@ -169,37 +176,48 @@ data_flush Enable data flushing before checkpoint in order to
persist data of regular and symlink.
reserve_root=%d Support configuring reserved space which is used for
allocation from a privileged user with specified uid or
- gid, unit: 4KB, the default limit is 0.2% of user blocks.
-resuid=%d The user ID which may use the reserved blocks.
-resgid=%d The group ID which may use the reserved blocks.
+ gid, unit: 4KB, the default limit is 12.5% of user blocks.
+reserve_node=%d Support configuring reserved nodes which are used for
+ allocation from a privileged user with specified uid or
+ gid, the default limit is 12.5% of all nodes.
+resuid=%d The user ID which may use the reserved blocks and nodes.
+resgid=%d The group ID which may use the reserved blocks and nodes.
fault_injection=%d Enable fault injection in all supported types with
specified injection rate.
fault_type=%d Support configuring fault injection type, should be
enabled with fault_injection option, fault type value
is shown below, it supports single or combined type.
- =================== ===========
- Type_Name Type_Value
- =================== ===========
- FAULT_KMALLOC 0x000000001
- FAULT_KVMALLOC 0x000000002
- FAULT_PAGE_ALLOC 0x000000004
- FAULT_PAGE_GET 0x000000008
- FAULT_ALLOC_BIO 0x000000010 (obsolete)
- FAULT_ALLOC_NID 0x000000020
- FAULT_ORPHAN 0x000000040
- FAULT_BLOCK 0x000000080
- FAULT_DIR_DEPTH 0x000000100
- FAULT_EVICT_INODE 0x000000200
- FAULT_TRUNCATE 0x000000400
- FAULT_READ_IO 0x000000800
- FAULT_CHECKPOINT 0x000001000
- FAULT_DISCARD 0x000002000
- FAULT_WRITE_IO 0x000004000
- FAULT_SLAB_ALLOC 0x000008000
- FAULT_DQUOT_INIT 0x000010000
- FAULT_LOCK_OP 0x000020000
- =================== ===========
+ .. code-block:: none
+
+ =========================== ==========
+ Type_Name Type_Value
+ =========================== ==========
+ FAULT_KMALLOC 0x00000001
+ FAULT_KVMALLOC 0x00000002
+ FAULT_PAGE_ALLOC 0x00000004
+ FAULT_PAGE_GET 0x00000008
+ FAULT_ALLOC_BIO 0x00000010 (obsolete)
+ FAULT_ALLOC_NID 0x00000020
+ FAULT_ORPHAN 0x00000040
+ FAULT_BLOCK 0x00000080
+ FAULT_DIR_DEPTH 0x00000100
+ FAULT_EVICT_INODE 0x00000200
+ FAULT_TRUNCATE 0x00000400
+ FAULT_READ_IO 0x00000800
+ FAULT_CHECKPOINT 0x00001000
+ FAULT_DISCARD 0x00002000
+ FAULT_WRITE_IO 0x00004000
+ FAULT_SLAB_ALLOC 0x00008000
+ FAULT_DQUOT_INIT 0x00010000
+ FAULT_LOCK_OP 0x00020000
+ FAULT_BLKADDR_VALIDITY 0x00040000
+ FAULT_BLKADDR_CONSISTENCE 0x00080000
+ FAULT_NO_SEGMENT 0x00100000
+ FAULT_INCONSISTENT_FOOTER 0x00200000
+ FAULT_TIMEOUT 0x00400000 (1000ms)
+ FAULT_VMALLOC 0x00800000
+ =========================== ==========
mode=%s Control block allocation mode which supports "adaptive"
and "lfs". In "lfs" mode, there should be no random
writes towards main area.
@@ -208,7 +226,7 @@ mode=%s Control block allocation mode which supports "adaptive"
fragmentation/after-GC situation itself. The developers use these
modes to understand filesystem fragmentation/after-GC condition well,
and eventually get some insights to handle them better.
- In "fragment:segment", f2fs allocates a new segment in ramdom
+ In "fragment:segment", f2fs allocates a new segment in random
position. With this, we can simulate the after-GC condition.
In "fragment:block", we can scatter block allocation with
"max_fragment_chunk" and "max_fragment_hole" sysfs nodes.
@@ -221,8 +239,6 @@ mode=%s Control block allocation mode which supports "adaptive"
option for more randomness.
Please, use these options for your experiments and we strongly
recommend to re-format the filesystem after using these options.
-io_bits=%u Set the bit size of write IO requests. It should be set
- with "mode=lfs".
usrquota Enable plain user disk quota accounting.
grpquota Enable plain group disk quota accounting.
prjquota Enable plain project quota accounting.
@@ -230,9 +246,9 @@ usrjquota=<file> Appoint specified file and type during mount, so that quota
grpjquota=<file> information can be properly updated during recovery flow,
prjjquota=<file> <quota file>: must be in root directory;
jqfmt=<quota type> <quota type>: [vfsold,vfsv0,vfsv1].
-offusrjquota Turn off user journalled quota.
-offgrpjquota Turn off group journalled quota.
-offprjjquota Turn off project journalled quota.
+usrjquota= Turn off user journalled quota.
+grpjquota= Turn off group journalled quota.
+prjjquota= Turn off project journalled quota.
quota Enable plain user disk quota accounting.
noquota Disable all plain disk quota option.
alloc_mode=%s Adjust block allocation policy, which supports "reuse"
@@ -253,11 +269,11 @@ test_dummy_encryption=%s
The argument may be either "v1" or "v2", in order to
select the corresponding fscrypt policy version.
checkpoint=%s[:%u[%]] Set to "disable" to turn off checkpointing. Set to "enable"
- to reenable checkpointing. Is enabled by default. While
+ to re-enable checkpointing. Is enabled by default. While
disabled, any unmounting or unexpected shutdowns will cause
the filesystem contents to appear as they did when the
filesystem was mounted with that option.
- While mounting with checkpoint=disabled, the filesystem must
+ While mounting with checkpoint=disable, the filesystem must
run garbage collection to ensure that all available space can
be used. If this takes too much time, the mount may return
EAGAIN. You may optionally add a value to indicate how much
@@ -282,10 +298,15 @@ nocheckpoint_merge Disable checkpoint merge feature.
compress_algorithm=%s Control compress algorithm, currently f2fs supports "lzo",
"lz4", "zstd" and "lzo-rle" algorithm.
compress_algorithm=%s:%d Control compress algorithm and its compress level, now, only
- "lz4" and "zstd" support compress level config.
- algorithm level range
- lz4 3 - 16
- zstd 1 - 22
+ "lz4" and "zstd" support compress level config::
+
+ ========= ===========
+ algorithm level range
+ ========= ===========
+ lz4 3 - 16
+ zstd 1 - 22
+ ========= ===========
+
compress_log_size=%u Support configuring compress cluster size. The size will
be 4KB * (1 << %u). The default and minimum sizes are 16KB.
compress_extension=%s Support adding specified extension, so that f2fs can enable
@@ -340,6 +361,52 @@ memory=%s Control memory mode. This supports "normal" and "low" modes.
Because of the nature of low memory devices, in this mode, f2fs
will try to save memory sometimes by sacrificing performance.
"normal" mode is the default mode and same as before.
+age_extent_cache Enable an age extent cache based on rb-tree. It records
+ data block update frequency of the extent per inode, in
+ order to provide better temperature hints for data block
+ allocation.
+errors=%s Specify f2fs behavior on critical errors. This supports modes:
+ "panic", "continue" and "remount-ro", respectively, trigger
+ panic immediately, continue without doing anything, and remount
+ the partition in read-only mode. By default it uses "continue"
+ mode.
+
+ .. code-block:: none
+
+ ====================== =============== =============== ========
+ mode continue remount-ro panic
+ ====================== =============== =============== ========
+ access ops normal normal N/A
+ syscall errors -EIO -EROFS N/A
+ mount option rw ro N/A
+ pending dir write keep keep N/A
+ pending non-dir write drop keep N/A
+ pending node write drop keep N/A
+ pending meta write keep keep N/A
+ ====================== =============== =============== ========
+nat_bits Enable nat_bits feature to enhance full/empty nat blocks access,
+ by default it's disabled.
+lookup_mode=%s Control the directory lookup behavior for casefolded
+ directories. This option has no effect on directories
+ that do not have the casefold feature enabled.
+
+ .. code-block:: none
+
+ ================== ========================================
+ Value Description
+ ================== ========================================
+ perf (Default) Enforces a hash-only lookup.
+ The linear search fallback is always
+ disabled, ignoring the on-disk flag.
+ compat Enables the linear search fallback for
+ compatibility with directory entries
+ created by older kernel that used a
+ different case-folding algorithm.
+ This mode ignores the on-disk flag.
+ auto F2FS determines the mode based on the
+ on-disk `SB_ENC_NO_COMPAT_FALLBACK_FL`
+ flag.
+ ================== ========================================
======================== ============================================================
Debugfs Entries
@@ -453,7 +520,7 @@ Note: please refer to the manpage of dump.f2fs(8) to get full option list.
sload.f2fs
----------
-The sload.f2fs gives a way to insert files and directories in the exisiting disk
+The sload.f2fs gives a way to insert files and directories in the existing disk
image. This tool is useful when building f2fs images given compiled files.
Note: please refer to the manpage of sload.f2fs(8) to get full option list.
@@ -749,6 +816,37 @@ In order to identify whether the data in the victim segment are valid or not,
F2FS manages a bitmap. Each bit represents the validity of a block, and the
bitmap is composed of a bit stream covering whole blocks in main area.
+Write-hint Policy
+-----------------
+
+F2FS sets the whint all the time with the below policy.
+
+===================== ======================== ===================
+User F2FS Block
+===================== ======================== ===================
+N/A META WRITE_LIFE_NONE|REQ_META
+N/A HOT_NODE WRITE_LIFE_NONE
+N/A WARM_NODE WRITE_LIFE_MEDIUM
+N/A COLD_NODE WRITE_LIFE_LONG
+ioctl(COLD) COLD_DATA WRITE_LIFE_EXTREME
+extension list " "
+
+-- buffered io
+------------------------------------------------------------------
+N/A COLD_DATA WRITE_LIFE_EXTREME
+N/A HOT_DATA WRITE_LIFE_SHORT
+N/A WARM_DATA WRITE_LIFE_NOT_SET
+
+-- direct io
+------------------------------------------------------------------
+WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME
+WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT
+WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET
+WRITE_LIFE_NONE " WRITE_LIFE_NONE
+WRITE_LIFE_MEDIUM " WRITE_LIFE_MEDIUM
+WRITE_LIFE_LONG " WRITE_LIFE_LONG
+===================== ======================== ===================
+
Fallocate(2) Policy
-------------------
@@ -765,7 +863,7 @@ Allocating disk space
as a method of optimally implementing that function.
However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to
-fallocate(fd, DEFAULT_MODE), it allocates on-disk block addressess having
+fallocate(fd, DEFAULT_MODE), it allocates on-disk block addresses having
zero or random data, which is useful to the below scenario where:
1. create(fd)
@@ -856,24 +954,26 @@ compression enabled files (refer to "Compression implementation" section for how
enable compression on a regular inode).
1) compress_mode=fs
-This is the default option. f2fs does automatic compression in the writeback of the
-compression enabled files.
+
+ This is the default option. f2fs does automatic compression in the writeback of the
+ compression enabled files.
2) compress_mode=user
-This disables the automatic compression and gives the user discretion of choosing the
-target file and the timing. The user can do manual compression/decompression on the
-compression enabled files using F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE
-ioctls like the below.
-To decompress a file,
+ This disables the automatic compression and gives the user discretion of choosing the
+ target file and the timing. The user can do manual compression/decompression on the
+ compression enabled files using F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE
+ ioctls like the below.
+
+To decompress a file::
-fd = open(filename, O_WRONLY, 0);
-ret = ioctl(fd, F2FS_IOC_DECOMPRESS_FILE);
+ fd = open(filename, O_WRONLY, 0);
+ ret = ioctl(fd, F2FS_IOC_DECOMPRESS_FILE);
-To compress a file,
+To compress a file::
-fd = open(filename, O_WRONLY, 0);
-ret = ioctl(fd, F2FS_IOC_COMPRESS_FILE);
+ fd = open(filename, O_WRONLY, 0);
+ ret = ioctl(fd, F2FS_IOC_COMPRESS_FILE);
NVMe Zoned Namespace devices
----------------------------
@@ -889,3 +989,47 @@ NVMe Zoned Namespace devices
can start before the zone-capacity and span across zone-capacity boundary.
Such spanning segments are also considered as usable segments. All blocks
past the zone-capacity are considered unusable in these segments.
+
+Device aliasing feature
+-----------------------
+
+f2fs can utilize a special file called a "device aliasing file." This file allows
+the entire storage device to be mapped with a single, large extent, not using
+the usual f2fs node structures. This mapped area is pinned and primarily intended
+for holding the space.
+
+Essentially, this mechanism allows a portion of the f2fs area to be temporarily
+reserved and used by another filesystem or for different purposes. Once that
+external usage is complete, the device aliasing file can be deleted, releasing
+the reserved space back to F2FS for its own use.
+
+.. code-block::
+
+ # ls /dev/vd*
+ /dev/vdb (32GB) /dev/vdc (32GB)
+ # mkfs.ext4 /dev/vdc
+ # mkfs.f2fs -c /dev/vdc@vdc.file /dev/vdb
+ # mount /dev/vdb /mnt/f2fs
+ # ls -l /mnt/f2fs
+ vdc.file
+ # df -h
+ /dev/vdb 64G 33G 32G 52% /mnt/f2fs
+
+ # mount -o loop /dev/vdc /mnt/ext4
+ # df -h
+ /dev/vdb 64G 33G 32G 52% /mnt/f2fs
+ /dev/loop7 32G 24K 30G 1% /mnt/ext4
+ # umount /mnt/ext4
+
+ # f2fs_io getflags /mnt/f2fs/vdc.file
+ get a flag on /mnt/f2fs/vdc.file ret=0, flags=nocow(pinned),immutable
+ # f2fs_io setflags noimmutable /mnt/f2fs/vdc.file
+ get a flag on noimmutable ret=0, flags=800010
+ set a flag on /mnt/f2fs/vdc.file ret=0, flags=noimmutable
+ # rm /mnt/f2fs/vdc.file
+ # df -h
+ /dev/vdb 64G 753M 64G 2% /mnt/f2fs
+
+So, the key idea is, user can do any file operations on /dev/vdc, and
+reclaim the space after the use, while the space is counted as /data.
+That doesn't require modifying partition size and filesystem format.
diff --git a/Documentation/filesystems/fiemap.rst b/Documentation/filesystems/fiemap.rst
index 93fc96f760aa..23b3ed229e49 100644
--- a/Documentation/filesystems/fiemap.rst
+++ b/Documentation/filesystems/fiemap.rst
@@ -12,21 +12,10 @@ returns a list of extents.
Request Basics
--------------
-A fiemap request is encoded within struct fiemap::
-
- struct fiemap {
- __u64 fm_start; /* logical offset (inclusive) at
- * which to start mapping (in) */
- __u64 fm_length; /* logical length of mapping which
- * userspace cares about (in) */
- __u32 fm_flags; /* FIEMAP_FLAG_* flags for request (in/out) */
- __u32 fm_mapped_extents; /* number of extents that were
- * mapped (out) */
- __u32 fm_extent_count; /* size of fm_extents array (in) */
- __u32 fm_reserved;
- struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */
- };
+A fiemap request is encoded within struct fiemap:
+.. kernel-doc:: include/uapi/linux/fiemap.h
+ :identifiers: fiemap
fm_start, and fm_length specify the logical range within the file
which the process would like mappings for. Extents returned mirror
@@ -60,6 +49,8 @@ FIEMAP_FLAG_XATTR
If this flag is set, the extents returned will describe the inodes
extended attribute lookup tree, instead of its data tree.
+FIEMAP_FLAG_CACHE
+ This flag requests caching of the extents.
Extent Mapping
--------------
@@ -77,18 +68,10 @@ complete the requested range and will not have the FIEMAP_EXTENT_LAST
flag set (see the next section on extent flags).
Each extent is described by a single fiemap_extent structure as
-returned in fm_extents::
-
- struct fiemap_extent {
- __u64 fe_logical; /* logical offset in bytes for the start of
- * the extent */
- __u64 fe_physical; /* physical offset in bytes for the start
- * of the extent */
- __u64 fe_length; /* length in bytes for the extent */
- __u64 fe_reserved64[2];
- __u32 fe_flags; /* FIEMAP_EXTENT_* flags for this extent */
- __u32 fe_reserved[3];
- };
+returned in fm_extents:
+
+.. kernel-doc:: include/uapi/linux/fiemap.h
+ :identifiers: fiemap_extent
All offsets and lengths are in bytes and mirror those on disk. It is valid
for an extents logical offset to start before the request or its logical
@@ -175,6 +158,8 @@ FIEMAP_EXTENT_MERGED
userspace would be highly inefficient, the kernel will try to merge most
adjacent blocks into 'extents'.
+FIEMAP_EXTENT_SHARED
+ This flag is set to request that space be shared with other files.
VFS -> File System Implementation
---------------------------------
@@ -191,14 +176,10 @@ each discovered extent::
u64 len);
->fiemap is passed struct fiemap_extent_info which describes the
-fiemap request::
-
- struct fiemap_extent_info {
- unsigned int fi_flags; /* Flags as passed from user */
- unsigned int fi_extents_mapped; /* Number of mapped extents */
- unsigned int fi_extents_max; /* Size of fiemap_extent array */
- struct fiemap_extent *fi_extents_start; /* Start of fiemap_extent array */
- };
+fiemap request:
+
+.. kernel-doc:: include/linux/fiemap.h
+ :identifiers: fiemap_extent_info
It is intended that the file system should not need to access any of this
structure directly. Filesystem handlers should be tolerant to signals and return
diff --git a/Documentation/filesystems/files.rst b/Documentation/filesystems/files.rst
index bcf84459917f..eb770f891b27 100644
--- a/Documentation/filesystems/files.rst
+++ b/Documentation/filesystems/files.rst
@@ -62,7 +62,7 @@ the fdtable structure -
be held.
4. To look up the file structure given an fd, a reader
- must use either lookup_fd_rcu() or files_lookup_fd_rcu() APIs. These
+ must use either lookup_fdget_rcu() or files_lookup_fdget_rcu() APIs. These
take care of barrier requirements due to lock-free lookup.
An example::
@@ -70,43 +70,22 @@ the fdtable structure -
struct file *file;
rcu_read_lock();
- file = lookup_fd_rcu(fd);
- if (file) {
- ...
- }
- ....
+ file = lookup_fdget_rcu(fd);
rcu_read_unlock();
-
-5. Handling of the file structures is special. Since the look-up
- of the fd (fget()/fget_light()) are lock-free, it is possible
- that look-up may race with the last put() operation on the
- file structure. This is avoided using atomic_long_inc_not_zero()
- on ->f_count::
-
- rcu_read_lock();
- file = files_lookup_fd_rcu(files, fd);
if (file) {
- if (atomic_long_inc_not_zero(&file->f_count))
- *fput_needed = 1;
- else
- /* Didn't get the reference, someone's freed */
- file = NULL;
+ ...
+ fput(file);
}
- rcu_read_unlock();
....
- return file;
-
- atomic_long_inc_not_zero() detects if refcounts is already zero or
- goes to zero during increment. If it does, we fail
- fget()/fget_light().
-6. Since both fdtable and file structures can be looked up
+5. Since both fdtable and file structures can be looked up
lock-free, they must be installed using rcu_assign_pointer()
API. If they are looked up lock-free, rcu_dereference()
must be used. However it is advisable to use files_fdtable()
- and lookup_fd_rcu()/files_lookup_fd_rcu() which take care of these issues.
+ and lookup_fdget_rcu()/files_lookup_fdget_rcu() which take care of these
+ issues.
-7. While updating, the fdtable pointer must be looked up while
+6. While updating, the fdtable pointer must be looked up while
holding files->file_lock. If ->file_lock is dropped, then
another thread expand the files thereby creating a new
fdtable and making the earlier fdtable pointer stale.
@@ -126,3 +105,19 @@ the fdtable structure -
Since locate_fd() can drop ->file_lock (and reacquire ->file_lock),
the fdtable pointer (fdt) must be loaded after locate_fd().
+On newer kernels rcu based file lookup has been switched to rely on
+SLAB_TYPESAFE_BY_RCU instead of call_rcu(). It isn't sufficient anymore
+to just acquire a reference to the file in question under rcu using
+atomic_long_inc_not_zero() since the file might have already been
+recycled and someone else might have bumped the reference. In other
+words, callers might see reference count bumps from newer users. For
+this is reason it is necessary to verify that the pointer is the same
+before and after the reference count increment. This pattern can be seen
+in get_file_rcu() and __files_get_rcu().
+
+In addition, it isn't possible to access or check fields in struct file
+without first acquiring a reference on it under rcu lookup. Not doing
+that was always very dodgy and it was only usable for non-pointer data
+in struct file. With SLAB_TYPESAFE_BY_RCU it is necessary that callers
+either first acquire a reference or they must hold the files_lock of the
+fdtable.
diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
index 5ba5817c17c2..70af896822e1 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -31,15 +31,15 @@ However, except for filenames, fscrypt does not encrypt filesystem
metadata.
Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated
-directly into supported filesystems --- currently ext4, F2FS, and
-UBIFS. This allows encrypted files to be read and written without
-caching both the decrypted and encrypted pages in the pagecache,
-thereby nearly halving the memory used and bringing it in line with
-unencrypted files. Similarly, half as many dentries and inodes are
-needed. eCryptfs also limits encrypted filenames to 143 bytes,
-causing application compatibility issues; fscrypt allows the full 255
-bytes (NAME_MAX). Finally, unlike eCryptfs, the fscrypt API can be
-used by unprivileged users, with no need to mount anything.
+directly into supported filesystems --- currently ext4, F2FS, UBIFS,
+and CephFS. This allows encrypted files to be read and written
+without caching both the decrypted and encrypted pages in the
+pagecache, thereby nearly halving the memory used and bringing it in
+line with unencrypted files. Similarly, half as many dentries and
+inodes are needed. eCryptfs also limits encrypted filenames to 143
+bytes, causing application compatibility issues; fscrypt allows the
+full 255 bytes (NAME_MAX). Finally, unlike eCryptfs, the fscrypt API
+can be used by unprivileged users, with no need to mount anything.
fscrypt does not support encrypting files in-place. Instead, it
supports marking an empty directory as encrypted. Then, after
@@ -70,7 +70,7 @@ Online attacks
--------------
fscrypt (and storage encryption in general) can only provide limited
-protection, if any at all, against online attacks. In detail:
+protection against online attacks. In detail:
Side-channel attacks
~~~~~~~~~~~~~~~~~~~~
@@ -99,16 +99,23 @@ Therefore, any encryption-specific access control checks would merely
be enforced by kernel *code* and therefore would be largely redundant
with the wide variety of access control mechanisms already available.)
-Kernel memory compromise
-~~~~~~~~~~~~~~~~~~~~~~~~
+Read-only kernel memory compromise
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Unless `hardware-wrapped keys`_ are used, an attacker who gains the
+ability to read from arbitrary kernel memory, e.g. by mounting a
+physical attack or by exploiting a kernel security vulnerability, can
+compromise all fscrypt keys that are currently in-use. This also
+extends to cold boot attacks; if the system is suddenly powered off,
+keys the system was using may remain in memory for a short time.
-An attacker who compromises the system enough to read from arbitrary
-memory, e.g. by mounting a physical attack or by exploiting a kernel
-security vulnerability, can compromise all encryption keys that are
-currently in use.
+However, if hardware-wrapped keys are used, then the fscrypt master
+keys and file contents encryption keys (but not other types of fscrypt
+subkeys such as filenames encryption keys) are protected from
+compromises of arbitrary kernel memory.
-However, fscrypt allows encryption keys to be removed from the kernel,
-which may protect them from later compromise.
+In addition, fscrypt allows encryption keys to be removed from the
+kernel, which may protect them from later compromise.
In more detail, the FS_IOC_REMOVE_ENCRYPTION_KEY ioctl (or the
FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl) can wipe a master
@@ -137,13 +144,29 @@ However, these ioctls have some limitations:
- In general, decrypted contents and filenames in the kernel VFS
caches are freed but not wiped. Therefore, portions thereof may be
recoverable from freed memory, even after the corresponding key(s)
- were wiped. To partially solve this, you can set
- CONFIG_PAGE_POISONING=y in your kernel config and add page_poison=1
- to your kernel command line. However, this has a performance cost.
-
-- Secret keys might still exist in CPU registers, in crypto
- accelerator hardware (if used by the crypto API to implement any of
- the algorithms), or in other places not explicitly considered here.
+ were wiped. To partially solve this, you can add init_on_free=1 to
+ your kernel command line. However, this has a performance cost.
+
+- Secret keys might still exist in CPU registers or in other places
+ not explicitly considered here.
+
+Full system compromise
+~~~~~~~~~~~~~~~~~~~~~~
+
+An attacker who gains "root" access and/or the ability to execute
+arbitrary kernel code can freely exfiltrate data that is protected by
+any in-use fscrypt keys. Thus, usually fscrypt provides no meaningful
+protection in this scenario. (Data that is protected by a key that is
+absent throughout the entire attack remains protected, modulo the
+limitations of key removal mentioned above in the case where the key
+was removed prior to the attack.)
+
+However, if `hardware-wrapped keys`_ are used, such attackers will be
+unable to exfiltrate the master keys or file contents keys in a form
+that will be usable after the system is powered off. This may be
+useful if the attacker is significantly time-limited and/or
+bandwidth-limited, so they can only exfiltrate some data and need to
+rely on a later offline attack to exfiltrate the rest of it.
Limitations of v1 policies
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -171,6 +194,10 @@ policies on all new encrypted directories.
Key hierarchy
=============
+Note: this section assumes the use of raw keys rather than
+hardware-wrapped keys. The use of hardware-wrapped keys modifies the
+key hierarchy slightly. For details, see `Hardware-wrapped keys`_.
+
Master Keys
-----------
@@ -261,9 +288,9 @@ DIRECT_KEY policies
The Adiantum encryption mode (see `Encryption modes and usage`_) is
suitable for both contents and filenames encryption, and it accepts
-long IVs --- long enough to hold both an 8-byte logical block number
-and a 16-byte per-file nonce. Also, the overhead of each Adiantum key
-is greater than that of an AES-256-XTS key.
+long IVs --- long enough to hold both an 8-byte data unit index and a
+16-byte per-file nonce. Also, the overhead of each Adiantum key is
+greater than that of an AES-256-XTS key.
Therefore, to improve performance and save memory, for Adiantum a
"direct key" configuration is supported. When the user has enabled
@@ -300,8 +327,8 @@ IV_INO_LBLK_32 policies
IV_INO_LBLK_32 policies work like IV_INO_LBLK_64, except that for
IV_INO_LBLK_32, the inode number is hashed with SipHash-2-4 (where the
-SipHash key is derived from the master key) and added to the file
-logical block number mod 2^32 to produce a 32-bit IV.
+SipHash key is derived from the master key) and added to the file data
+unit index mod 2^32 to produce a 32-bit IV.
This format is optimized for use with inline encryption hardware
compliant with the eMMC v5.2 standard, which supports only 32 IV bits
@@ -332,76 +359,174 @@ Encryption modes and usage
fscrypt allows one encryption mode to be specified for file contents
and one encryption mode to be specified for filenames. Different
directory trees are permitted to use different encryption modes.
+
+Supported modes
+---------------
+
Currently, the following pairs of encryption modes are supported:
-- AES-256-XTS for contents and AES-256-CTS-CBC for filenames
-- AES-128-CBC for contents and AES-128-CTS-CBC for filenames
+- AES-256-XTS for contents and AES-256-CBC-CTS for filenames
+- AES-256-XTS for contents and AES-256-HCTR2 for filenames
- Adiantum for both contents and filenames
-- AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only)
-
-If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.
-
-AES-128-CBC was added only for low-powered embedded devices with
-crypto accelerators such as CAAM or CESA that do not support XTS. To
-use AES-128-CBC, CONFIG_CRYPTO_ESSIV and CONFIG_CRYPTO_SHA256 (or
-another SHA-256 implementation) must be enabled so that ESSIV can be
-used.
-
-Adiantum is a (primarily) stream cipher-based mode that is fast even
-on CPUs without dedicated crypto instructions. It's also a true
-wide-block mode, unlike XTS. It can also eliminate the need to derive
-per-file encryption keys. However, it depends on the security of two
-primitives, XChaCha12 and AES-256, rather than just one. See the
-paper "Adiantum: length-preserving encryption for entry-level
-processors" (https://eprint.iacr.org/2018/720.pdf) for more details.
-To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast
-implementations of ChaCha and NHPoly1305 should be enabled, e.g.
-CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM.
-
-AES-256-HCTR2 is another true wide-block encryption mode that is intended for
-use on CPUs with dedicated crypto instructions. AES-256-HCTR2 has the property
-that a bitflip in the plaintext changes the entire ciphertext. This property
-makes it desirable for filename encryption since initialization vectors are
-reused within a directory. For more details on AES-256-HCTR2, see the paper
-"Length-preserving encryption with HCTR2"
-(https://eprint.iacr.org/2021/1441.pdf). To use AES-256-HCTR2,
-CONFIG_CRYPTO_HCTR2 must be enabled. Also, fast implementations of XCTR and
-POLYVAL should be enabled, e.g. CRYPTO_POLYVAL_ARM64_CE and
-CRYPTO_AES_ARM64_CE_BLK for ARM64.
-
-New encryption modes can be added relatively easily, without changes
-to individual filesystems. However, authenticated encryption (AE)
-modes are not currently supported because of the difficulty of dealing
-with ciphertext expansion.
+- AES-128-CBC-ESSIV for contents and AES-128-CBC-CTS for filenames
+- SM4-XTS for contents and SM4-CBC-CTS for filenames
+
+Note: in the API, "CBC" means CBC-ESSIV, and "CTS" means CBC-CTS.
+So, for example, FSCRYPT_MODE_AES_256_CTS means AES-256-CBC-CTS.
+
+Authenticated encryption modes are not currently supported because of
+the difficulty of dealing with ciphertext expansion. Therefore,
+contents encryption uses a block cipher in `XTS mode
+<https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS>`_ or
+`CBC-ESSIV mode
+<https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_(ESSIV)>`_,
+or a wide-block cipher. Filenames encryption uses a
+block cipher in `CBC-CTS mode
+<https://en.wikipedia.org/wiki/Ciphertext_stealing>`_ or a wide-block
+cipher.
+
+The (AES-256-XTS, AES-256-CBC-CTS) pair is the recommended default.
+It is also the only option that is *guaranteed* to always be supported
+if the kernel supports fscrypt at all; see `Kernel config options`_.
+
+The (AES-256-XTS, AES-256-HCTR2) pair is also a good choice that
+upgrades the filenames encryption to use a wide-block cipher. (A
+*wide-block cipher*, also called a tweakable super-pseudorandom
+permutation, has the property that changing one bit scrambles the
+entire result.) As described in `Filenames encryption`_, a wide-block
+cipher is the ideal mode for the problem domain, though CBC-CTS is the
+"least bad" choice among the alternatives. For more information about
+HCTR2, see `the HCTR2 paper <https://eprint.iacr.org/2021/1441.pdf>`_.
+
+Adiantum is recommended on systems where AES is too slow due to lack
+of hardware acceleration for AES. Adiantum is a wide-block cipher
+that uses XChaCha12 and AES-256 as its underlying components. Most of
+the work is done by XChaCha12, which is much faster than AES when AES
+acceleration is unavailable. For more information about Adiantum, see
+`the Adiantum paper <https://eprint.iacr.org/2018/720.pdf>`_.
+
+The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair was added to try to
+provide a more efficient option for systems that lack AES instructions
+in the CPU but do have a non-inline crypto engine such as CAAM or CESA
+that supports AES-CBC (and not AES-XTS). This is deprecated. It has
+been shown that just doing AES on the CPU is actually faster.
+Moreover, Adiantum is faster still and is recommended on such systems.
+
+The remaining mode pairs are the "national pride ciphers":
+
+- (SM4-XTS, SM4-CBC-CTS)
+
+Generally speaking, these ciphers aren't "bad" per se, but they
+receive limited security review compared to the usual choices such as
+AES and ChaCha. They also don't bring much new to the table. It is
+suggested to only use these ciphers where their use is mandated.
+
+Kernel config options
+---------------------
+
+Enabling fscrypt support (CONFIG_FS_ENCRYPTION) automatically pulls in
+only the basic support from the crypto API needed to use AES-256-XTS
+and AES-256-CBC-CTS encryption. For optimal performance, it is
+strongly recommended to also enable any available platform-specific
+kconfig options that provide acceleration for the algorithm(s) you
+wish to use. Support for any "non-default" encryption modes typically
+requires extra kconfig options as well.
+
+Below, some relevant options are listed by encryption mode. Note,
+acceleration options not listed below may be available for your
+platform; refer to the kconfig menus. File contents encryption can
+also be configured to use inline encryption hardware instead of the
+kernel crypto API (see `Inline encryption support`_); in that case,
+the file contents mode doesn't need to supported in the kernel crypto
+API, but the filenames mode still does.
+
+- AES-256-XTS and AES-256-CBC-CTS
+ - Recommended:
+ - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
+ - x86: CONFIG_CRYPTO_AES_NI_INTEL
+
+- AES-256-HCTR2
+ - Mandatory:
+ - CONFIG_CRYPTO_HCTR2
+ - Recommended:
+ - arm64: CONFIG_CRYPTO_AES_ARM64_CE_BLK
+ - x86: CONFIG_CRYPTO_AES_NI_INTEL
+
+- Adiantum
+ - Mandatory:
+ - CONFIG_CRYPTO_ADIANTUM
+ - Recommended:
+ - arm32: CONFIG_CRYPTO_NHPOLY1305_NEON
+ - arm64: CONFIG_CRYPTO_NHPOLY1305_NEON
+ - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2
+ - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2
+
+- AES-128-CBC-ESSIV and AES-128-CBC-CTS:
+ - Mandatory:
+ - CONFIG_CRYPTO_ESSIV
+ - CONFIG_CRYPTO_SHA256 or another SHA-256 implementation
+ - Recommended:
+ - AES-CBC acceleration
Contents encryption
-------------------
-For file contents, each filesystem block is encrypted independently.
-Starting from Linux kernel 5.5, encryption of filesystems with block
-size less than system's page size is supported.
-
-Each block's IV is set to the logical block number within the file as
-a little endian number, except that:
-
-- With CBC mode encryption, ESSIV is also used. Specifically, each IV
- is encrypted with AES-256 where the AES-256 key is the SHA-256 hash
- of the file's data encryption key.
-
-- With `DIRECT_KEY policies`_, the file's nonce is appended to the IV.
- Currently this is only allowed with the Adiantum encryption mode.
-
-- With `IV_INO_LBLK_64 policies`_, the logical block number is limited
- to 32 bits and is placed in bits 0-31 of the IV. The inode number
- (which is also limited to 32 bits) is placed in bits 32-63.
-
-- With `IV_INO_LBLK_32 policies`_, the logical block number is limited
- to 32 bits and is placed in bits 0-31 of the IV. The inode number
- is then hashed and added mod 2^32.
-
-Note that because file logical block numbers are included in the IVs,
-filesystems must enforce that blocks are never shifted around within
-encrypted files, e.g. via "collapse range" or "insert range".
+For contents encryption, each file's contents is divided into "data
+units". Each data unit is encrypted independently. The IV for each
+data unit incorporates the zero-based index of the data unit within
+the file. This ensures that each data unit within a file is encrypted
+differently, which is essential to prevent leaking information.
+
+Note: the encryption depending on the offset into the file means that
+operations like "collapse range" and "insert range" that rearrange the
+extent mapping of files are not supported on encrypted files.
+
+There are two cases for the sizes of the data units:
+
+* Fixed-size data units. This is how all filesystems other than UBIFS
+ work. A file's data units are all the same size; the last data unit
+ is zero-padded if needed. By default, the data unit size is equal
+ to the filesystem block size. On some filesystems, users can select
+ a sub-block data unit size via the ``log2_data_unit_size`` field of
+ the encryption policy; see `FS_IOC_SET_ENCRYPTION_POLICY`_.
+
+* Variable-size data units. This is what UBIFS does. Each "UBIFS
+ data node" is treated as a crypto data unit. Each contains variable
+ length, possibly compressed data, zero-padded to the next 16-byte
+ boundary. Users cannot select a sub-block data unit size on UBIFS.
+
+In the case of compression + encryption, the compressed data is
+encrypted. UBIFS compression works as described above. f2fs
+compression works a bit differently; it compresses a number of
+filesystem blocks into a smaller number of filesystem blocks.
+Therefore a f2fs-compressed file still uses fixed-size data units, and
+it is encrypted in a similar way to a file containing holes.
+
+As mentioned in `Key hierarchy`_, the default encryption setting uses
+per-file keys. In this case, the IV for each data unit is simply the
+index of the data unit in the file. However, users can select an
+encryption setting that does not use per-file keys. For these, some
+kind of file identifier is incorporated into the IVs as follows:
+
+- With `DIRECT_KEY policies`_, the data unit index is placed in bits
+ 0-63 of the IV, and the file's nonce is placed in bits 64-191.
+
+- With `IV_INO_LBLK_64 policies`_, the data unit index is placed in
+ bits 0-31 of the IV, and the file's inode number is placed in bits
+ 32-63. This setting is only allowed when data unit indices and
+ inode numbers fit in 32 bits.
+
+- With `IV_INO_LBLK_32 policies`_, the file's inode number is hashed
+ and added to the data unit index. The resulting value is truncated
+ to 32 bits and placed in bits 0-31 of the IV. This setting is only
+ allowed when data unit indices and inode numbers fit in 32 bits.
+
+The byte order of the IV is always little endian.
+
+If the user selects FSCRYPT_MODE_AES_128_CBC for the contents mode, an
+ESSIV layer is automatically included. In this case, before the IV is
+passed to AES-128-CBC, it is encrypted with AES-256 where the AES-256
+key is the SHA-256 hash of the file's contents encryption key.
Filenames encryption
--------------------
@@ -416,7 +541,7 @@ alternatively has the file's nonce (for `DIRECT_KEY policies`_) or
inode number (for `IV_INO_LBLK_64 policies`_) included in the IVs.
Thus, IV reuse is limited to within a single directory.
-With CTS-CBC, the IV reuse means that when the plaintext filenames share a
+With CBC-CTS, the IV reuse means that when the plaintext filenames share a
common prefix at least as long as the cipher block size (16 bytes for AES), the
corresponding encrypted filenames will also share a common prefix. This is
undesirable. Adiantum and HCTR2 do not have this weakness, as they are
@@ -470,7 +595,8 @@ follows::
__u8 contents_encryption_mode;
__u8 filenames_encryption_mode;
__u8 flags;
- __u8 __reserved[4];
+ __u8 log2_data_unit_size;
+ __u8 __reserved[3];
__u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE];
};
@@ -486,7 +612,14 @@ This structure must be initialized as follows:
be set to constants from ``<linux/fscrypt.h>`` which identify the
encryption modes to use. If unsure, use FSCRYPT_MODE_AES_256_XTS
(1) for ``contents_encryption_mode`` and FSCRYPT_MODE_AES_256_CTS
- (4) for ``filenames_encryption_mode``.
+ (4) for ``filenames_encryption_mode``. For details, see `Encryption
+ modes and usage`_.
+
+ v1 encryption policies only support three combinations of modes:
+ (FSCRYPT_MODE_AES_256_XTS, FSCRYPT_MODE_AES_256_CTS),
+ (FSCRYPT_MODE_AES_128_CBC, FSCRYPT_MODE_AES_128_CTS), and
+ (FSCRYPT_MODE_ADIANTUM, FSCRYPT_MODE_ADIANTUM). v2 policies support
+ all combinations documented in `Supported modes`_.
- ``flags`` contains optional flags from ``<linux/fscrypt.h>``:
@@ -505,6 +638,29 @@ This structure must be initialized as follows:
The DIRECT_KEY, IV_INO_LBLK_64, and IV_INO_LBLK_32 flags are
mutually exclusive.
+- ``log2_data_unit_size`` is the log2 of the data unit size in bytes,
+ or 0 to select the default data unit size. The data unit size is
+ the granularity of file contents encryption. For example, setting
+ ``log2_data_unit_size`` to 12 causes file contents be passed to the
+ underlying encryption algorithm (such as AES-256-XTS) in 4096-byte
+ data units, each with its own IV.
+
+ Not all filesystems support setting ``log2_data_unit_size``. ext4
+ and f2fs support it since Linux v6.7. On filesystems that support
+ it, the supported nonzero values are 9 through the log2 of the
+ filesystem block size, inclusively. The default value of 0 selects
+ the filesystem block size.
+
+ The main use case for ``log2_data_unit_size`` is for selecting a
+ data unit size smaller than the filesystem block size for
+ compatibility with inline encryption hardware that only supports
+ smaller data unit sizes. ``/sys/block/$disk/queue/crypto/`` may be
+ useful for checking which data unit sizes are supported by a
+ particular system's inline encryption hardware.
+
+ Leave this field zeroed unless you are certain you need it. Using
+ an unnecessarily small data unit size reduces performance.
+
- For v2 encryption policies, ``__reserved`` must be zeroed.
- For v1 encryption policies, ``master_key_descriptor`` specifies how
@@ -697,7 +853,9 @@ a pointer to struct fscrypt_add_key_arg, defined as follows::
struct fscrypt_key_specifier key_spec;
__u32 raw_size;
__u32 key_id;
- __u32 __reserved[8];
+ #define FSCRYPT_ADD_KEY_FLAG_HW_WRAPPED 0x00000001
+ __u32 flags;
+ __u32 __reserved[7];
__u8 raw[];
};
@@ -716,7 +874,7 @@ a pointer to struct fscrypt_add_key_arg, defined as follows::
struct fscrypt_provisioning_key_payload {
__u32 type;
- __u32 __reserved;
+ __u32 flags;
__u8 raw[];
};
@@ -744,24 +902,32 @@ as follows:
Alternatively, if ``key_id`` is nonzero, this field must be 0, since
in that case the size is implied by the specified Linux keyring key.
-- ``key_id`` is 0 if the raw key is given directly in the ``raw``
- field. Otherwise ``key_id`` is the ID of a Linux keyring key of
- type "fscrypt-provisioning" whose payload is
- struct fscrypt_provisioning_key_payload whose ``raw`` field contains
- the raw key and whose ``type`` field matches ``key_spec.type``.
- Since ``raw`` is variable-length, the total size of this key's
- payload must be ``sizeof(struct fscrypt_provisioning_key_payload)``
- plus the raw key size. The process must have Search permission on
- this key.
-
- Most users should leave this 0 and specify the raw key directly.
- The support for specifying a Linux keyring key is intended mainly to
+- ``key_id`` is 0 if the key is given directly in the ``raw`` field.
+ Otherwise ``key_id`` is the ID of a Linux keyring key of type
+ "fscrypt-provisioning" whose payload is struct
+ fscrypt_provisioning_key_payload whose ``raw`` field contains the
+ key, whose ``type`` field matches ``key_spec.type``, and whose
+ ``flags`` field matches ``flags``. Since ``raw`` is
+ variable-length, the total size of this key's payload must be
+ ``sizeof(struct fscrypt_provisioning_key_payload)`` plus the number
+ of key bytes. The process must have Search permission on this key.
+
+ Most users should leave this 0 and specify the key directly. The
+ support for specifying a Linux keyring key is intended mainly to
allow re-adding keys after a filesystem is unmounted and re-mounted,
- without having to store the raw keys in userspace memory.
+ without having to store the keys in userspace memory.
+
+- ``flags`` contains optional flags from ``<linux/fscrypt.h>``:
+
+ - FSCRYPT_ADD_KEY_FLAG_HW_WRAPPED: This denotes that the key is a
+ hardware-wrapped key. See `Hardware-wrapped keys`_. This flag
+ can't be used if FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR is used.
- ``raw`` is a variable-length field which must contain the actual
key, ``raw_size`` bytes long. Alternatively, if ``key_id`` is
- nonzero, then this field is unused.
+ nonzero, then this field is unused. Note that despite being named
+ ``raw``, if FSCRYPT_ADD_KEY_FLAG_HW_WRAPPED is specified then it
+ will contain a wrapped key, not a raw key.
For v2 policy keys, the kernel keeps track of which user (identified
by effective user ID) added the key, and only allows the key to be
@@ -773,8 +939,8 @@ prevent that other user from unexpectedly removing it. Therefore,
FS_IOC_ADD_ENCRYPTION_KEY may also be used to add a v2 policy key
*again*, even if it's already added by other user(s). In this case,
FS_IOC_ADD_ENCRYPTION_KEY will just install a claim to the key for the
-current user, rather than actually add the key again (but the raw key
-must still be provided, as a proof of knowledge).
+current user, rather than actually add the key again (but the key must
+still be provided, as a proof of knowledge).
FS_IOC_ADD_ENCRYPTION_KEY returns 0 if either the key or a claim to
the key was either added or already exists.
@@ -783,20 +949,23 @@ FS_IOC_ADD_ENCRYPTION_KEY can fail with the following errors:
- ``EACCES``: FSCRYPT_KEY_SPEC_TYPE_DESCRIPTOR was specified, but the
caller does not have the CAP_SYS_ADMIN capability in the initial
- user namespace; or the raw key was specified by Linux key ID but the
+ user namespace; or the key was specified by Linux key ID but the
process lacks Search permission on the key.
+- ``EBADMSG``: invalid hardware-wrapped key
- ``EDQUOT``: the key quota for this user would be exceeded by adding
the key
- ``EINVAL``: invalid key size or key specifier type, or reserved bits
were set
-- ``EKEYREJECTED``: the raw key was specified by Linux key ID, but the
- key has the wrong type
-- ``ENOKEY``: the raw key was specified by Linux key ID, but no key
- exists with that ID
+- ``EKEYREJECTED``: the key was specified by Linux key ID, but the key
+ has the wrong type
+- ``ENOKEY``: the key was specified by Linux key ID, but no key exists
+ with that ID
- ``ENOTTY``: this type of filesystem does not implement encryption
- ``EOPNOTSUPP``: the kernel was not configured with encryption
support for this filesystem, or the filesystem superblock has not
- had encryption enabled on it
+ had encryption enabled on it; or a hardware wrapped key was specified
+ but the filesystem does not support inline encryption or the hardware
+ does not support hardware-wrapped keys
Legacy method
~~~~~~~~~~~~~
@@ -859,9 +1028,8 @@ or removed by non-root users.
These ioctls don't work on keys that were added via the legacy
process-subscribed keyrings mechanism.
-Before using these ioctls, read the `Kernel memory compromise`_
-section for a discussion of the security goals and limitations of
-these ioctls.
+Before using these ioctls, read the `Online attacks`_ section for a
+discussion of the security goals and limitations of these ioctls.
FS_IOC_REMOVE_ENCRYPTION_KEY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -998,8 +1166,8 @@ The caller must zero all input fields, then fill in ``key_spec``:
On success, 0 is returned and the kernel fills in the output fields:
- ``status`` indicates whether the key is absent, present, or
- incompletely removed. Incompletely removed means that the master
- secret has been removed, but some files are still in use; i.e.,
+ incompletely removed. Incompletely removed means that removal has
+ been initiated, but some files are still in use; i.e.,
`FS_IOC_REMOVE_ENCRYPTION_KEY`_ returned 0 but set the informational
status flag FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY.
@@ -1150,22 +1318,13 @@ this by validating all top-level encryption policies prior to access.
Inline encryption support
=========================
-By default, fscrypt uses the kernel crypto API for all cryptographic
-operations (other than HKDF, which fscrypt partially implements
-itself). The kernel crypto API supports hardware crypto accelerators,
-but only ones that work in the traditional way where all inputs and
-outputs (e.g. plaintexts and ciphertexts) are in memory. fscrypt can
-take advantage of such hardware, but the traditional acceleration
-model isn't particularly efficient and fscrypt hasn't been optimized
-for it.
-
-Instead, many newer systems (especially mobile SoCs) have *inline
-encryption hardware* that can encrypt/decrypt data while it is on its
-way to/from the storage device. Linux supports inline encryption
-through a set of extensions to the block layer called *blk-crypto*.
-blk-crypto allows filesystems to attach encryption contexts to bios
-(I/O requests) to specify how the data will be encrypted or decrypted
-in-line. For more information about blk-crypto, see
+Many newer systems (especially mobile SoCs) have *inline encryption
+hardware* that can encrypt/decrypt data while it is on its way to/from
+the storage device. Linux supports inline encryption through a set of
+extensions to the block layer called *blk-crypto*. blk-crypto allows
+filesystems to attach encryption contexts to bios (I/O requests) to
+specify how the data will be encrypted or decrypted in-line. For more
+information about blk-crypto, see
:ref:`Documentation/block/inline-encryption.rst <inline_encryption>`.
On supported filesystems (currently ext4 and f2fs), fscrypt can use
@@ -1181,7 +1340,8 @@ inline encryption hardware doesn't have the needed crypto capabilities
(e.g. support for the needed encryption algorithm and data unit size)
and where blk-crypto-fallback is unusable. (For blk-crypto-fallback
to be usable, it must be enabled in the kernel configuration with
-CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y.)
+CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y, and the file must be
+protected by a raw key rather than a hardware-wrapped key.)
Currently fscrypt always uses the filesystem block size (which is
usually 4096 bytes) as the data unit size. Therefore, it can only use
@@ -1189,7 +1349,76 @@ inline encryption hardware that supports that data unit size.
Inline encryption doesn't affect the ciphertext or other aspects of
the on-disk format, so users may freely switch back and forth between
-using "inlinecrypt" and not using "inlinecrypt".
+using "inlinecrypt" and not using "inlinecrypt". An exception is that
+files that are protected by a hardware-wrapped key can only be
+encrypted/decrypted by the inline encryption hardware and therefore
+can only be accessed when the "inlinecrypt" mount option is used. For
+more information about hardware-wrapped keys, see below.
+
+Hardware-wrapped keys
+---------------------
+
+fscrypt supports using *hardware-wrapped keys* when the inline
+encryption hardware supports it. Such keys are only present in kernel
+memory in wrapped (encrypted) form; they can only be unwrapped
+(decrypted) by the inline encryption hardware and are temporally bound
+to the current boot. This prevents the keys from being compromised if
+kernel memory is leaked. This is done without limiting the number of
+keys that can be used and while still allowing the execution of
+cryptographic tasks that are tied to the same key but can't use inline
+encryption hardware, e.g. filenames encryption.
+
+Note that hardware-wrapped keys aren't specific to fscrypt; they are a
+block layer feature (part of *blk-crypto*). For more details about
+hardware-wrapped keys, see the block layer documentation at
+:ref:`Documentation/block/inline-encryption.rst
+<hardware_wrapped_keys>`. The rest of this section just focuses on
+the details of how fscrypt can use hardware-wrapped keys.
+
+fscrypt supports hardware-wrapped keys by allowing the fscrypt master
+keys to be hardware-wrapped keys as an alternative to raw keys. To
+add a hardware-wrapped key with `FS_IOC_ADD_ENCRYPTION_KEY`_,
+userspace must specify FSCRYPT_ADD_KEY_FLAG_HW_WRAPPED in the
+``flags`` field of struct fscrypt_add_key_arg and also in the
+``flags`` field of struct fscrypt_provisioning_key_payload when
+applicable. The key must be in ephemerally-wrapped form, not
+long-term wrapped form.
+
+Some limitations apply. First, files protected by a hardware-wrapped
+key are tied to the system's inline encryption hardware. Therefore
+they can only be accessed when the "inlinecrypt" mount option is used,
+and they can't be included in portable filesystem images. Second,
+currently the hardware-wrapped key support is only compatible with
+`IV_INO_LBLK_64 policies`_ and `IV_INO_LBLK_32 policies`_, as it
+assumes that there is just one file contents encryption key per
+fscrypt master key rather than one per file. Future work may address
+this limitation by passing per-file nonces down the storage stack to
+allow the hardware to derive per-file keys.
+
+Implementation-wise, to encrypt/decrypt the contents of files that are
+protected by a hardware-wrapped key, fscrypt uses blk-crypto,
+attaching the hardware-wrapped key to the bio crypt contexts. As is
+the case with raw keys, the block layer will program the key into a
+keyslot when it isn't already in one. However, when programming a
+hardware-wrapped key, the hardware doesn't program the given key
+directly into a keyslot but rather unwraps it (using the hardware's
+ephemeral wrapping key) and derives the inline encryption key from it.
+The inline encryption key is the key that actually gets programmed
+into a keyslot, and it is never exposed to software.
+
+However, fscrypt doesn't just do file contents encryption; it also
+uses its master keys to derive filenames encryption keys, key
+identifiers, and sometimes some more obscure types of subkeys such as
+dirhash keys. So even with file contents encryption out of the
+picture, fscrypt still needs a raw key to work with. To get such a
+key from a hardware-wrapped key, fscrypt asks the inline encryption
+hardware to derive a cryptographically isolated "software secret" from
+the hardware-wrapped key. fscrypt uses this "software secret" to key
+its KDF to derive all subkeys other than file contents keys.
+
+Note that this implies that the hardware-wrapped key feature only
+protects the file contents encryption keys. It doesn't protect other
+fscrypt subkeys such as filenames encryption keys.
Direct I/O support
==================
@@ -1246,7 +1475,8 @@ directory.) These structs are defined as follows::
u8 contents_encryption_mode;
u8 filenames_encryption_mode;
u8 flags;
- u8 __reserved[4];
+ u8 log2_data_unit_size;
+ u8 __reserved[3];
u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE];
u8 nonce[FSCRYPT_FILE_NONCE_SIZE];
};
@@ -1270,10 +1500,10 @@ the file contents themselves, as described below:
For the read path (->read_folio()) of regular files, filesystems can
read the ciphertext into the page cache and decrypt it in-place. The
-page lock must be held until decryption has finished, to prevent the
-page from becoming visible to userspace prematurely.
+folio lock must be held until decryption has finished, to prevent the
+folio from becoming visible to userspace prematurely.
-For the write path (->writepage()) of regular files, filesystems
+For the write path (->writepages()) of regular files, filesystems
cannot encrypt data in-place in the page cache, since the cached
plaintext must be preserved. Instead, filesystems must encrypt into a
temporary buffer or "bounce page", then write out the temporary
diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst
index cb8e7573882a..412cf11e3298 100644
--- a/Documentation/filesystems/fsverity.rst
+++ b/Documentation/filesystems/fsverity.rst
@@ -16,7 +16,7 @@ btrfs filesystems. Like fscrypt, not too much filesystem-specific
code is needed to support fs-verity.
fs-verity is similar to `dm-verity
-<https://www.kernel.org/doc/Documentation/device-mapper/verity.txt>`_
+<https://www.kernel.org/doc/Documentation/admin-guide/device-mapper/verity.rst>`_
but works on files rather than block devices. On regular files on
filesystems supporting fs-verity, userspace can execute an ioctl that
causes the filesystem to build a Merkle tree for the file and persist
@@ -38,20 +38,14 @@ fail at runtime.
Use cases
=========
-By itself, the base fs-verity feature only provides integrity
-protection, i.e. detection of accidental (non-malicious) corruption.
+By itself, fs-verity only provides integrity protection, i.e.
+detection of accidental (non-malicious) corruption.
However, because fs-verity makes retrieving the file hash extremely
efficient, it's primarily meant to be used as a tool to support
authentication (detection of malicious modifications) or auditing
(logging file hashes before use).
-Trusted userspace code (e.g. operating system code running on a
-read-only partition that is itself authenticated by dm-verity) can
-authenticate the contents of an fs-verity file by using the
-`FS_IOC_MEASURE_VERITY`_ ioctl to retrieve its hash, then verifying a
-digital signature of it.
-
A standard file hash could be used instead of fs-verity. However,
this is inefficient if the file is large and only a small portion may
be accessed. This is often the case for Android application package
@@ -69,24 +63,41 @@ still be used on read-only filesystems. fs-verity is for files that
must live on a read-write filesystem because they are independently
updated and potentially user-installed, so dm-verity cannot be used.
-The base fs-verity feature is a hashing mechanism only; actually
-authenticating the files may be done by:
-
-* Userspace-only
-
-* Builtin signature verification + userspace policy
-
- fs-verity optionally supports a simple signature verification
- mechanism where users can configure the kernel to require that
- all fs-verity files be signed by a key loaded into a keyring;
- see `Built-in signature verification`_.
-
-* Integrity Measurement Architecture (IMA)
-
- IMA supports including fs-verity file digests and signatures in the
- IMA measurement list and verifying fs-verity based file signatures
- stored as security.ima xattrs, based on policy.
-
+fs-verity does not mandate a particular scheme for authenticating its
+file hashes. (Similarly, dm-verity does not mandate a particular
+scheme for authenticating its block device root hashes.) Options for
+authenticating fs-verity file hashes include:
+
+- Trusted userspace code. Often, the userspace code that accesses
+ files can be trusted to authenticate them. Consider e.g. an
+ application that wants to authenticate data files before using them,
+ or an application loader that is part of the operating system (which
+ is already authenticated in a different way, such as by being loaded
+ from a read-only partition that uses dm-verity) and that wants to
+ authenticate applications before loading them. In these cases, this
+ trusted userspace code can authenticate a file's contents by
+ retrieving its fs-verity digest using `FS_IOC_MEASURE_VERITY`_, then
+ verifying a signature of it using any userspace cryptographic
+ library that supports digital signatures.
+
+- Integrity Measurement Architecture (IMA). IMA supports fs-verity
+ file digests as an alternative to its traditional full file digests.
+ "IMA appraisal" enforces that files contain a valid, matching
+ signature in their "security.ima" extended attribute, as controlled
+ by the IMA policy. For more information, see the IMA documentation.
+
+- Integrity Policy Enforcement (IPE). IPE supports enforcing access
+ control decisions based on immutable security properties of files,
+ including those protected by fs-verity's built-in signatures.
+ "IPE policy" specifically allows for the authorization of fs-verity
+ files using properties ``fsverity_digest`` for identifying
+ files by their verity digest, and ``fsverity_signature`` to authorize
+ files with a verified fs-verity's built-in signature. For
+ details on configuring IPE policies and understanding its operational
+ modes, please refer to :doc:`IPE admin guide </admin-guide/LSM/ipe>`.
+
+- Trusted userspace code in combination with `Built-in signature
+ verification`_. This approach should be used only with great care.
User API
========
@@ -111,29 +122,31 @@ follows::
};
This structure contains the parameters of the Merkle tree to build for
-the file, and optionally contains a signature. It must be initialized
-as follows:
+the file. It must be initialized as follows:
- ``version`` must be 1.
- ``hash_algorithm`` must be the identifier for the hash algorithm to
use for the Merkle tree, such as FS_VERITY_HASH_ALG_SHA256. See
``include/uapi/linux/fsverity.h`` for the list of possible values.
-- ``block_size`` must be the Merkle tree block size. Currently, this
- must be equal to the system page size, which is usually 4096 bytes.
- Other sizes may be supported in the future. This value is not
- necessarily the same as the filesystem block size.
+- ``block_size`` is the Merkle tree block size, in bytes. In Linux
+ v6.3 and later, this can be any power of 2 between (inclusively)
+ 1024 and the minimum of the system page size and the filesystem
+ block size. In earlier versions, the page size was the only allowed
+ value.
- ``salt_size`` is the size of the salt in bytes, or 0 if no salt is
provided. The salt is a value that is prepended to every hashed
block; it can be used to personalize the hashing for a particular
file or device. Currently the maximum salt size is 32 bytes.
- ``salt_ptr`` is the pointer to the salt, or NULL if no salt is
provided.
-- ``sig_size`` is the size of the signature in bytes, or 0 if no
- signature is provided. Currently the signature is (somewhat
- arbitrarily) limited to 16128 bytes. See `Built-in signature
- verification`_ for more information.
-- ``sig_ptr`` is the pointer to the signature, or NULL if no
- signature is provided.
+- ``sig_size`` is the size of the builtin signature in bytes, or 0 if no
+ builtin signature is provided. Currently the builtin signature is
+ (somewhat arbitrarily) limited to 16128 bytes.
+- ``sig_ptr`` is the pointer to the builtin signature, or NULL if no
+ builtin signature is provided. A builtin signature is only needed
+ if the `Built-in signature verification`_ feature is being used. It
+ is not needed for IMA appraisal, and it is not needed if the file
+ signature is being handled entirely in userspace.
- All reserved fields must be zeroed.
FS_IOC_ENABLE_VERITY causes the filesystem to build a Merkle tree for
@@ -157,29 +170,29 @@ fatal signal), no changes are made to the file.
FS_IOC_ENABLE_VERITY can fail with the following errors:
- ``EACCES``: the process does not have write access to the file
-- ``EBADMSG``: the signature is malformed
+- ``EBADMSG``: the builtin signature is malformed
- ``EBUSY``: this ioctl is already running on the file
- ``EEXIST``: the file already has verity enabled
- ``EFAULT``: the caller provided inaccessible memory
+- ``EFBIG``: the file is too large to enable verity on
- ``EINTR``: the operation was interrupted by a fatal signal
- ``EINVAL``: unsupported version, hash algorithm, or block size; or
reserved bits are set; or the file descriptor refers to neither a
regular file nor a directory.
- ``EISDIR``: the file descriptor refers to a directory
-- ``EKEYREJECTED``: the signature doesn't match the file
-- ``EMSGSIZE``: the salt or signature is too long
-- ``ENOKEY``: the fs-verity keyring doesn't contain the certificate
- needed to verify the signature
+- ``EKEYREJECTED``: the builtin signature doesn't match the file
+- ``EMSGSIZE``: the salt or builtin signature is too long
+- ``ENOKEY``: the ".fs-verity" keyring doesn't contain the certificate
+ needed to verify the builtin signature
- ``ENOPKG``: fs-verity recognizes the hash algorithm, but it's not
- available in the kernel's crypto API as currently configured (e.g.
- for SHA-512, missing CONFIG_CRYPTO_SHA512).
+ available in the kernel as currently configured
- ``ENOTTY``: this type of filesystem does not implement fs-verity
- ``EOPNOTSUPP``: the kernel was not configured with fs-verity
support; or the filesystem superblock has not had the 'verity'
feature enabled on it; or the filesystem does not support fs-verity
on this file. (See `Filesystem support`_.)
-- ``EPERM``: the file is append-only; or, a signature is required and
- one was not provided.
+- ``EPERM``: the file is append-only; or, a builtin signature is
+ required and one was not provided.
- ``EROFS``: the filesystem is read-only
- ``ETXTBSY``: someone has the file open for writing. This can be the
caller's file descriptor, another open file descriptor, or the file
@@ -234,11 +247,17 @@ FS_IOC_READ_VERITY_METADATA
The FS_IOC_READ_VERITY_METADATA ioctl reads verity metadata from a
verity file. This ioctl is available since Linux v5.12.
-This ioctl allows writing a server program that takes a verity file
-and serves it to a client program, such that the client can do its own
-fs-verity compatible verification of the file. This only makes sense
-if the client doesn't trust the server and if the server needs to
-provide the storage for the client.
+This ioctl is useful for cases where the verity verification should be
+performed somewhere other than the currently running kernel.
+
+One example is a server program that takes a verity file and serves it
+to a client program, such that the client can do its own fs-verity
+compatible verification of the file. This only makes sense if the
+client doesn't trust the server and if the server needs to provide the
+storage for the client.
+
+Another example is copying verity metadata when creating filesystem
+images in userspace (such as with ``mkfs.ext4 -d``).
This is a fairly specialized use case, and most fs-verity users won't
need this ioctl.
@@ -268,9 +287,9 @@ This ioctl takes in a pointer to the following structure::
- ``FS_VERITY_METADATA_TYPE_DESCRIPTOR`` reads the fs-verity
descriptor. See `fs-verity descriptor`_.
-- ``FS_VERITY_METADATA_TYPE_SIGNATURE`` reads the signature which was
- passed to FS_IOC_ENABLE_VERITY, if any. See `Built-in signature
- verification`_.
+- ``FS_VERITY_METADATA_TYPE_SIGNATURE`` reads the builtin signature
+ which was passed to FS_IOC_ENABLE_VERITY, if any. See `Built-in
+ signature verification`_.
The semantics are similar to those of ``pread()``. ``offset``
specifies the offset in bytes into the metadata item to read from, and
@@ -297,7 +316,7 @@ FS_IOC_READ_VERITY_METADATA can fail with the following errors:
overflowed
- ``ENODATA``: the file is not a verity file, or
FS_VERITY_METADATA_TYPE_SIGNATURE was requested but the file doesn't
- have a built-in signature
+ have a builtin signature
- ``ENOTTY``: this type of filesystem does not implement fs-verity, or
this ioctl is not yet implemented on it
- ``EOPNOTSUPP``: the kernel was not configured with fs-verity
@@ -322,6 +341,8 @@ the file has fs-verity enabled. This can perform better than
FS_IOC_GETFLAGS and FS_IOC_MEASURE_VERITY because it doesn't require
opening the file, and opening verity files can be expensive.
+.. _accessing_verity_files:
+
Accessing verity files
======================
@@ -345,8 +366,8 @@ non-verity one, with the following exceptions:
with EIO (for read()) or SIGBUS (for mmap() reads).
- If the sysctl "fs.verity.require_signatures" is set to 1 and the
- file is not signed by a key in the fs-verity keyring, then opening
- the file will fail. See `Built-in signature verification`_.
+ file is not signed by a key in the ".fs-verity" keyring, then
+ opening the file will fail. See `Built-in signature verification`_.
Direct access to the Merkle tree is not supported. Therefore, if a
verity file is copied, or is backed up and restored, then it will lose
@@ -431,29 +452,38 @@ root hash as well as other fields such as the file size::
Built-in signature verification
===============================
-With CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y, fs-verity supports putting
-a portion of an authentication policy (see `Use cases`_) in the
-kernel. Specifically, it adds support for:
+CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y adds supports for in-kernel
+verification of fs-verity builtin signatures.
+
+**IMPORTANT**! Please take great care before using this feature.
+It is not the only way to do signatures with fs-verity, and the
+alternatives (such as userspace signature verification, and IMA
+appraisal) can be much better. It's also easy to fall into a trap
+of thinking this feature solves more problems than it actually does.
-1. At fs-verity module initialization time, a keyring ".fs-verity" is
- created. The root user can add trusted X.509 certificates to this
- keyring using the add_key() system call, then (when done)
- optionally use keyctl_restrict_keyring() to prevent additional
- certificates from being added.
+Enabling this option adds the following:
+
+1. At boot time, the kernel creates a keyring named ".fs-verity". The
+ root user can add trusted X.509 certificates to this keyring using
+ the add_key() system call.
2. `FS_IOC_ENABLE_VERITY`_ accepts a pointer to a PKCS#7 formatted
detached signature in DER format of the file's fs-verity digest.
- On success, this signature is persisted alongside the Merkle tree.
- Then, any time the file is opened, the kernel will verify the
+ On success, the ioctl persists the signature alongside the Merkle
+ tree. Then, any time the file is opened, the kernel verifies the
file's actual digest against this signature, using the certificates
- in the ".fs-verity" keyring.
+ in the ".fs-verity" keyring. This verification happens as long as the
+ file's signature exists, regardless of the state of the sysctl variable
+ "fs.verity.require_signatures" described in the next item. The IPE LSM
+ relies on this behavior to recognize and label fsverity files
+ that contain a verified built-in fsverity signature.
3. A new sysctl "fs.verity.require_signatures" is made available.
When set to 1, the kernel requires that all verity files have a
correctly signed digest as described in (2).
-fs-verity file digests must be signed in the following format, which
-is similar to the structure used by `FS_IOC_MEASURE_VERITY`_::
+The data that the signature as described in (2) must be a signature of
+is the fs-verity file digest in the following format::
struct fsverity_formatted_digest {
char magic[8]; /* must be "FSVerity" */
@@ -462,13 +492,75 @@ is similar to the structure used by `FS_IOC_MEASURE_VERITY`_::
__u8 digest[];
};
-fs-verity's built-in signature verification support is meant as a
-relatively simple mechanism that can be used to provide some level of
-authenticity protection for verity files, as an alternative to doing
-the signature verification in userspace or using IMA-appraisal.
-However, with this mechanism, userspace programs still need to check
-that the verity bit is set, and there is no protection against verity
-files being swapped around.
+That's it. It should be emphasized again that fs-verity builtin
+signatures are not the only way to do signatures with fs-verity. See
+`Use cases`_ for an overview of ways in which fs-verity can be used.
+fs-verity builtin signatures have some major limitations that should
+be carefully considered before using them:
+
+- Builtin signature verification does *not* make the kernel enforce
+ that any files actually have fs-verity enabled. Thus, it is not a
+ complete authentication policy. Currently, if it is used, one
+ way to complete the authentication policy is for trusted userspace
+ code to explicitly check whether files have fs-verity enabled with a
+ signature before they are accessed. (With
+ fs.verity.require_signatures=1, just checking whether fs-verity is
+ enabled suffices.) But, in this case the trusted userspace code
+ could just store the signature alongside the file and verify it
+ itself using a cryptographic library, instead of using this feature.
+
+- Another approach is to utilize fs-verity builtin signature
+ verification in conjunction with the IPE LSM, which supports defining
+ a kernel-enforced, system-wide authentication policy that allows only
+ files with a verified fs-verity builtin signature to perform certain
+ operations, such as execution. Note that IPE doesn't require
+ fs.verity.require_signatures=1.
+ Please refer to :doc:`IPE admin guide </admin-guide/LSM/ipe>` for
+ more details.
+
+- A file's builtin signature can only be set at the same time that
+ fs-verity is being enabled on the file. Changing or deleting the
+ builtin signature later requires re-creating the file.
+
+- Builtin signature verification uses the same set of public keys for
+ all fs-verity enabled files on the system. Different keys cannot be
+ trusted for different files; each key is all or nothing.
+
+- The sysctl fs.verity.require_signatures applies system-wide.
+ Setting it to 1 only works when all users of fs-verity on the system
+ agree that it should be set to 1. This limitation can prevent
+ fs-verity from being used in cases where it would be helpful.
+
+- Builtin signature verification can only use signature algorithms
+ that are supported by the kernel. For example, the kernel does not
+ yet support Ed25519, even though this is often the signature
+ algorithm that is recommended for new cryptographic designs.
+
+- fs-verity builtin signatures are in PKCS#7 format, and the public
+ keys are in X.509 format. These formats are commonly used,
+ including by some other kernel features (which is why the fs-verity
+ builtin signatures use them), and are very feature rich.
+ Unfortunately, history has shown that code that parses and handles
+ these formats (which are from the 1990s and are based on ASN.1)
+ often has vulnerabilities as a result of their complexity. This
+ complexity is not inherent to the cryptography itself.
+
+ fs-verity users who do not need advanced features of X.509 and
+ PKCS#7 should strongly consider using simpler formats, such as plain
+ Ed25519 keys and signatures, and verifying signatures in userspace.
+
+ fs-verity users who choose to use X.509 and PKCS#7 anyway should
+ still consider that verifying those signatures in userspace is more
+ flexible (for other reasons mentioned earlier in this document) and
+ eliminates the need to enable CONFIG_FS_VERITY_BUILTIN_SIGNATURES
+ and its associated increase in kernel attack surface. In some cases
+ it can even be necessary, since advanced X.509 and PKCS#7 features
+ do not always work as intended with the kernel. For example, the
+ kernel does not check X.509 certificate validity times.
+
+ Note: IMA appraisal, which supports fs-verity, does not use PKCS#7
+ for its signatures, so it partially avoids the issues discussed
+ here. IMA appraisal does use X.509.
Filesystem support
==================
@@ -495,9 +587,11 @@ To create verity files on an ext4 filesystem, the filesystem must have
been formatted with ``-O verity`` or had ``tune2fs -O verity`` run on
it. "verity" is an RO_COMPAT filesystem feature, so once set, old
kernels will only be able to mount the filesystem readonly, and old
-versions of e2fsck will be unable to check the filesystem. Moreover,
-currently ext4 only supports mounting a filesystem with the "verity"
-feature when its block size is equal to PAGE_SIZE (often 4096 bytes).
+versions of e2fsck will be unable to check the filesystem.
+
+Originally, an ext4 filesystem with the "verity" feature could only be
+mounted when its block size was equal to the system page size
+(typically 4096 bytes). In Linux v6.3, this limitation was removed.
ext4 sets the EXT4_VERITY_FL on-disk inode flag on verity files. It
can only be set by `FS_IOC_ENABLE_VERITY`_, and it cannot be cleared.
@@ -518,9 +612,7 @@ support paging multi-gigabyte xattrs into memory, and to support
encrypting xattrs. Note that the verity metadata *must* be encrypted
when the file is, since it contains hashes of the plaintext data.
-Currently, ext4 verity only supports the case where the Merkle tree
-block size, filesystem block size, and page size are all the same. It
-also only supports extent-based files.
+ext4 only allows verity on extent-based files.
f2fs
----
@@ -538,11 +630,10 @@ Like ext4, f2fs stores the verity metadata (Merkle tree and
fsverity_descriptor) past the end of the file, starting at the first
64K boundary beyond i_size. See explanation for ext4 above.
Moreover, f2fs supports at most 4096 bytes of xattr entries per inode
-which wouldn't be enough for even a single Merkle tree block.
+which usually wouldn't be enough for even a single Merkle tree block.
-Currently, f2fs verity only supports a Merkle tree block size of 4096.
-Also, f2fs doesn't support enabling verity on files that currently
-have atomic or volatile writes pending.
+f2fs doesn't support enabling verity on files that currently have
+atomic or volatile writes pending.
btrfs
-----
@@ -567,51 +658,48 @@ Pagecache
~~~~~~~~~
For filesystems using Linux's pagecache, the ``->read_folio()`` and
-``->readahead()`` methods must be modified to verify pages before they
-are marked Uptodate. Merely hooking ``->read_iter()`` would be
+``->readahead()`` methods must be modified to verify folios before
+they are marked Uptodate. Merely hooking ``->read_iter()`` would be
insufficient, since ``->read_iter()`` is not used for memory maps.
-Therefore, fs/verity/ provides a function fsverity_verify_page() which
-verifies a page that has been read into the pagecache of a verity
-inode, but is still locked and not Uptodate, so it's not yet readable
-by userspace. As needed to do the verification,
-fsverity_verify_page() will call back into the filesystem to read
-Merkle tree pages via fsverity_operations::read_merkle_tree_page().
+Therefore, fs/verity/ provides the function fsverity_verify_blocks()
+which verifies data that has been read into the pagecache of a verity
+inode. The containing folio must still be locked and not Uptodate, so
+it's not yet readable by userspace. As needed to do the verification,
+fsverity_verify_blocks() will call back into the filesystem to read
+hash blocks via fsverity_operations::read_merkle_tree_page().
-fsverity_verify_page() returns false if verification failed; in this
-case, the filesystem must not set the page Uptodate. Following this,
+fsverity_verify_blocks() returns false if verification failed; in this
+case, the filesystem must not set the folio Uptodate. Following this,
as per the usual Linux pagecache behavior, attempts by userspace to
-read() from the part of the file containing the page will fail with
-EIO, and accesses to the page within a memory map will raise SIGBUS.
-
-fsverity_verify_page() currently only supports the case where the
-Merkle tree block size is equal to PAGE_SIZE (often 4096 bytes).
+read() from the part of the file containing the folio will fail with
+EIO, and accesses to the folio within a memory map will raise SIGBUS.
-In principle, fsverity_verify_page() verifies the entire path in the
-Merkle tree from the data page to the root hash. However, for
-efficiency the filesystem may cache the hash pages. Therefore,
-fsverity_verify_page() only ascends the tree reading hash pages until
-an already-verified hash page is seen, as indicated by the PageChecked
-bit being set. It then verifies the path to that page.
+In principle, verifying a data block requires verifying the entire
+path in the Merkle tree from the data block to the root hash.
+However, for efficiency the filesystem may cache the hash blocks.
+Therefore, fsverity_verify_blocks() only ascends the tree reading hash
+blocks until an already-verified hash block is seen. It then verifies
+the path to that block.
This optimization, which is also used by dm-verity, results in
excellent sequential read performance. This is because usually (e.g.
-127 in 128 times for 4K blocks and SHA-256) the hash page from the
+127 in 128 times for 4K blocks and SHA-256) the hash block from the
bottom level of the tree will already be cached and checked from
-reading a previous data page. However, random reads perform worse.
+reading a previous data block. However, random reads perform worse.
Block device based filesystems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Block device based filesystems (e.g. ext4 and f2fs) in Linux also use
the pagecache, so the above subsection applies too. However, they
-also usually read many pages from a file at once, grouped into a
+also usually read many data blocks from a file at once, grouped into a
structure called a "bio". To make it easier for these types of
filesystems to support fs-verity, fs/verity/ also provides a function
-fsverity_verify_bio() which verifies all pages in a bio.
+fsverity_verify_bio() which verifies all data blocks in a bio.
ext4 and f2fs also support encryption. If a verity file is also
-encrypted, the pages must be decrypted before being verified. To
+encrypted, the data must be decrypted before being verified. To
support this, these filesystems allocate a "post-read context" for
each bio and store it in ``->bi_private``::
@@ -626,14 +714,14 @@ each bio and store it in ``->bi_private``::
verity, or both is enabled. After the bio completes, for each needed
postprocessing step the filesystem enqueues the bio_post_read_ctx on a
workqueue, and then the workqueue work does the decryption or
-verification. Finally, pages where no decryption or verity error
-occurred are marked Uptodate, and the pages are unlocked.
+verification. Finally, folios where no decryption or verity error
+occurred are marked Uptodate, and the folios are unlocked.
On many filesystems, files can contain holes. Normally,
-``->readahead()`` simply zeroes holes and sets the corresponding pages
-Uptodate; no bios are issued. To prevent this case from bypassing
-fs-verity, these filesystems use fsverity_verify_page() to verify hole
-pages.
+``->readahead()`` simply zeroes hole blocks and considers the
+corresponding data to be up-to-date; no bios are issued. To prevent
+this case from bypassing fs-verity, filesystems use
+fsverity_verify_blocks() to verify hole blocks.
Filesystems also disable direct I/O on verity files, since otherwise
direct I/O would bypass fs-verity.
@@ -644,7 +732,7 @@ Userspace utility
This document focuses on the kernel, but a userspace utility for
fs-verity can be found at:
- https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git
+ https://git.kernel.org/pub/scm/fs/fsverity/fsverity-utils.git
See the README.md file in the fsverity-utils source tree for details,
including examples of setting up fs-verity protected files.
@@ -793,9 +881,9 @@ weren't already directly answered in other parts of this document.
:A: There are many reasons why this is not possible or would be very
difficult, including the following:
- - To prevent bypassing verification, pages must not be marked
+ - To prevent bypassing verification, folios must not be marked
Uptodate until they've been verified. Currently, each
- filesystem is responsible for marking pages Uptodate via
+ filesystem is responsible for marking folios Uptodate via
``->readahead()``. Therefore, currently it's not possible for
the VFS to do the verification on its own. Changing this would
require significant changes to the VFS and all filesystems.
diff --git a/Documentation/filesystems/fuse/fuse-io-uring.rst b/Documentation/filesystems/fuse/fuse-io-uring.rst
new file mode 100644
index 000000000000..d73dd0dbd238
--- /dev/null
+++ b/Documentation/filesystems/fuse/fuse-io-uring.rst
@@ -0,0 +1,99 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================================
+FUSE-over-io-uring design documentation
+=======================================
+
+This documentation covers basic details how the fuse
+kernel/userspace communication through io-uring is configured
+and works. For generic details about FUSE see fuse.rst.
+
+This document also covers the current interface, which is
+still in development and might change.
+
+Limitations
+===========
+As of now not all requests types are supported through io-uring, userspace
+is required to also handle requests through /dev/fuse after io-uring setup
+is complete. Specifically notifications (initiated from the daemon side)
+and interrupts.
+
+Fuse io-uring configuration
+===========================
+
+Fuse kernel requests are queued through the classical /dev/fuse
+read/write interface - until io-uring setup is complete.
+
+In order to set up fuse-over-io-uring fuse-server (user-space)
+needs to submit SQEs (opcode = IORING_OP_URING_CMD) to the /dev/fuse
+connection file descriptor. Initial submit is with the sub command
+FUSE_URING_REQ_REGISTER, which will just register entries to be
+available in the kernel.
+
+Once at least one entry per queue is submitted, kernel starts
+to enqueue to ring queues.
+Note, every CPU core has its own fuse-io-uring queue.
+Userspace handles the CQE/fuse-request and submits the result as
+subcommand FUSE_URING_REQ_COMMIT_AND_FETCH - kernel completes
+the requests and also marks the entry available again. If there are
+pending requests waiting the request will be immediately submitted
+to the daemon again.
+
+Initial SQE
+-----------::
+
+ | | FUSE filesystem daemon
+ | |
+ | | >io_uring_submit()
+ | | IORING_OP_URING_CMD /
+ | | FUSE_URING_CMD_REGISTER
+ | | [wait cqe]
+ | | >io_uring_wait_cqe() or
+ | | >io_uring_submit_and_wait()
+ | |
+ | >fuse_uring_cmd() |
+ | >fuse_uring_register() |
+
+
+Sending requests with CQEs
+--------------------------::
+
+ | | FUSE filesystem daemon
+ | | [waiting for CQEs]
+ | "rm /mnt/fuse/file" |
+ | |
+ | >sys_unlink() |
+ | >fuse_unlink() |
+ | [allocate request] |
+ | >fuse_send_one() |
+ | ... |
+ | >fuse_uring_queue_fuse_req |
+ | [queue request on fg queue] |
+ | >fuse_uring_add_req_to_ring_ent() |
+ | ... |
+ | >fuse_uring_copy_to_ring() |
+ | >io_uring_cmd_done() |
+ | >request_wait_answer() |
+ | [sleep on req->waitq] |
+ | | [receives and handles CQE]
+ | | [submit result and fetch next]
+ | | >io_uring_submit()
+ | | IORING_OP_URING_CMD/
+ | | FUSE_URING_CMD_COMMIT_AND_FETCH
+ | >fuse_uring_cmd() |
+ | >fuse_uring_commit_fetch() |
+ | >fuse_uring_commit() |
+ | >fuse_uring_copy_from_ring() |
+ | [ copy the result to the fuse req] |
+ | >fuse_uring_req_end() |
+ | >fuse_request_end() |
+ | [wake up req->waitq] |
+ | >fuse_uring_next_fuse_req |
+ | [wait or handle next req] |
+ | |
+ | [req->waitq woken up] |
+ | <fuse_unlink() |
+ | <sys_unlink() |
+
+
+
diff --git a/Documentation/filesystems/fuse-io.rst b/Documentation/filesystems/fuse/fuse-io.rst
index 255a368fe534..d736ac4cb483 100644
--- a/Documentation/filesystems/fuse-io.rst
+++ b/Documentation/filesystems/fuse/fuse-io.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
==============
-Fuse I/O Modes
+FUSE I/O Modes
==============
Fuse supports the following I/O modes:
@@ -15,7 +15,8 @@ The direct-io mode can be selected with the FOPEN_DIRECT_IO flag in the
FUSE_OPEN reply.
In direct-io mode the page cache is completely bypassed for reads and writes.
-No read-ahead takes place. Shared mmap is disabled.
+No read-ahead takes place. Shared mmap is disabled by default. To allow shared
+mmap, the FUSE_DIRECT_IO_ALLOW_MMAP flag may be enabled in the FUSE_INIT reply.
In cached mode reads may be satisfied from the page cache, and data may be
read-ahead by the kernel to fill the cache. The cache is always kept consistent
diff --git a/Documentation/filesystems/fuse/fuse-passthrough.rst b/Documentation/filesystems/fuse/fuse-passthrough.rst
new file mode 100644
index 000000000000..2b0e7c2da54a
--- /dev/null
+++ b/Documentation/filesystems/fuse/fuse-passthrough.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================
+FUSE Passthrough
+================
+
+Introduction
+============
+
+FUSE (Filesystem in Userspace) passthrough is a feature designed to improve the
+performance of FUSE filesystems for I/O operations. Typically, FUSE operations
+involve communication between the kernel and a userspace FUSE daemon, which can
+incur overhead. Passthrough allows certain operations on a FUSE file to bypass
+the userspace daemon and be executed directly by the kernel on an underlying
+"backing file".
+
+This is achieved by the FUSE daemon registering a file descriptor (pointing to
+the backing file on a lower filesystem) with the FUSE kernel module. The kernel
+then receives an identifier (``backing_id``) for this registered backing file.
+When a FUSE file is subsequently opened, the FUSE daemon can, in its response to
+the ``OPEN`` request, include this ``backing_id`` and set the
+``FOPEN_PASSTHROUGH`` flag. This establishes a direct link for specific
+operations.
+
+Currently, passthrough is supported for operations like ``read(2)``/``write(2)``
+(via ``read_iter``/``write_iter``), ``splice(2)``, and ``mmap(2)``.
+
+Enabling Passthrough
+====================
+
+To use FUSE passthrough:
+
+ 1. The FUSE filesystem must be compiled with ``CONFIG_FUSE_PASSTHROUGH``
+ enabled.
+ 2. The FUSE daemon, during the ``FUSE_INIT`` handshake, must negotiate the
+ ``FUSE_PASSTHROUGH`` capability and specify its desired
+ ``max_stack_depth``.
+ 3. The (privileged) FUSE daemon uses the ``FUSE_DEV_IOC_BACKING_OPEN`` ioctl
+ on its connection file descriptor (e.g., ``/dev/fuse``) to register a
+ backing file descriptor and obtain a ``backing_id``.
+ 4. When handling an ``OPEN`` or ``CREATE`` request for a FUSE file, the daemon
+ replies with the ``FOPEN_PASSTHROUGH`` flag set in
+ ``fuse_open_out::open_flags`` and provides the corresponding ``backing_id``
+ in ``fuse_open_out::backing_id``.
+ 5. The FUSE daemon should eventually call ``FUSE_DEV_IOC_BACKING_CLOSE`` with
+ the ``backing_id`` to release the kernel's reference to the backing file
+ when it's no longer needed for passthrough setups.
+
+Privilege Requirements
+======================
+
+Setting up passthrough functionality currently requires the FUSE daemon to
+possess the ``CAP_SYS_ADMIN`` capability. This requirement stems from several
+security and resource management considerations that are actively being
+discussed and worked on. The primary reasons for this restriction are detailed
+below.
+
+Resource Accounting and Visibility
+----------------------------------
+
+The core mechanism for passthrough involves the FUSE daemon opening a file
+descriptor to a backing file and registering it with the FUSE kernel module via
+the ``FUSE_DEV_IOC_BACKING_OPEN`` ioctl. This ioctl returns a ``backing_id``
+associated with a kernel-internal ``struct fuse_backing`` object, which holds a
+reference to the backing ``struct file``.
+
+A significant concern arises because the FUSE daemon can close its own file
+descriptor to the backing file after registration. The kernel, however, will
+still hold a reference to the ``struct file`` via the ``struct fuse_backing``
+object as long as it's associated with a ``backing_id`` (or subsequently, with
+an open FUSE file in passthrough mode).
+
+This behavior leads to two main issues for unprivileged FUSE daemons:
+
+ 1. **Invisibility to lsof and other inspection tools**: Once the FUSE
+ daemon closes its file descriptor, the open backing file held by the kernel
+ becomes "hidden." Standard tools like ``lsof``, which typically inspect
+ process file descriptor tables, would not be able to identify that this
+ file is still open by the system on behalf of the FUSE filesystem. This
+ makes it difficult for system administrators to track resource usage or
+ debug issues related to open files (e.g., preventing unmounts).
+
+ 2. **Bypassing RLIMIT_NOFILE**: The FUSE daemon process is subject to
+ resource limits, including the maximum number of open file descriptors
+ (``RLIMIT_NOFILE``). If an unprivileged daemon could register backing files
+ and then close its own FDs, it could potentially cause the kernel to hold
+ an unlimited number of open ``struct file`` references without these being
+ accounted against the daemon's ``RLIMIT_NOFILE``. This could lead to a
+ denial-of-service (DoS) by exhausting system-wide file resources.
+
+The ``CAP_SYS_ADMIN`` requirement acts as a safeguard against these issues,
+restricting this powerful capability to trusted processes.
+
+**NOTE**: ``io_uring`` solves this similar issue by exposing its "fixed files",
+which are visible via ``fdinfo`` and accounted under the registering user's
+``RLIMIT_NOFILE``.
+
+Filesystem Stacking and Shutdown Loops
+--------------------------------------
+
+Another concern relates to the potential for creating complex and problematic
+filesystem stacking scenarios if unprivileged users could set up passthrough.
+A FUSE passthrough filesystem might use a backing file that resides:
+
+ * On the *same* FUSE filesystem.
+ * On another filesystem (like OverlayFS) which itself might have an upper or
+ lower layer that is a FUSE filesystem.
+
+These configurations could create dependency loops, particularly during
+filesystem shutdown or unmount sequences, leading to deadlocks or system
+instability. This is conceptually similar to the risks associated with the
+``LOOP_SET_FD`` ioctl, which also requires ``CAP_SYS_ADMIN``.
+
+To mitigate this, FUSE passthrough already incorporates checks based on
+filesystem stacking depth (``sb->s_stack_depth`` and ``fc->max_stack_depth``).
+For example, during the ``FUSE_INIT`` handshake, the FUSE daemon can negotiate
+the ``max_stack_depth`` it supports. When a backing file is registered via
+``FUSE_DEV_IOC_BACKING_OPEN``, the kernel checks if the backing file's
+filesystem stack depth is within the allowed limit.
+
+The ``CAP_SYS_ADMIN`` requirement provides an additional layer of security,
+ensuring that only privileged users can create these potentially complex
+stacking arrangements.
+
+General Security Posture
+------------------------
+
+As a general principle for new kernel features that allow userspace to instruct
+the kernel to perform direct operations on its behalf based on user-provided
+file descriptors, starting with a higher privilege requirement (like
+``CAP_SYS_ADMIN``) is a conservative and common security practice. This allows
+the feature to be used and tested while further security implications are
+evaluated and addressed.
diff --git a/Documentation/filesystems/fuse.rst b/Documentation/filesystems/fuse/fuse.rst
index 1e31e87aee68..0fbd5a03fdc9 100644
--- a/Documentation/filesystems/fuse.rst
+++ b/Documentation/filesystems/fuse/fuse.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
-====
-FUSE
-====
+=============
+FUSE Overview
+=============
Definitions
===========
@@ -129,6 +129,20 @@ For each connection the following files exist within this directory:
connection. This means that all waiting requests will be aborted an
error returned for all aborted and new requests.
+ max_background
+ The maximum number of background requests that can be outstanding
+ at a time. When the number of background requests reaches this limit,
+ further requests will be blocked until some are completed, potentially
+ causing I/O operations to stall.
+
+ congestion_threshold
+ The threshold of background requests at which the kernel considers
+ the filesystem to be congested. When the number of background requests
+ exceeds this value, the kernel will skip asynchronous readahead
+ operations, reducing read-ahead optimizations but preserving essential
+ I/O, as well as suspending non-synchronous writeback operations
+ (WB_SYNC_NONE), delaying page cache flushing to the filesystem.
+
Only the owner of the mount may read or write these files.
Interrupting filesystem operations
diff --git a/Documentation/filesystems/fuse/index.rst b/Documentation/filesystems/fuse/index.rst
new file mode 100644
index 000000000000..393a845214da
--- /dev/null
+++ b/Documentation/filesystems/fuse/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================================
+FUSE (Filesystem in Userspace) Technical Documentation
+======================================================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ fuse
+ fuse-io
+ fuse-io-uring
+ fuse-passthrough
diff --git a/Documentation/filesystems/gfs2-glocks.rst b/Documentation/filesystems/gfs2-glocks.rst
deleted file mode 100644
index d14f230f0b12..000000000000
--- a/Documentation/filesystems/gfs2-glocks.rst
+++ /dev/null
@@ -1,253 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-============================
-Glock internal locking rules
-============================
-
-This documents the basic principles of the glock state machine
-internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h)
-has two main (internal) locks:
-
- 1. A spinlock (gl_lockref.lock) which protects the internal state such
- as gl_state, gl_target and the list of holders (gl_holders)
- 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
- threads from making calls to the DLM, etc. at the same time. If a
- thread takes this lock, it must then call run_queue (usually via the
- workqueue) when it releases it in order to ensure any pending tasks
- are completed.
-
-The gl_holders list contains all the queued lock requests (not
-just the holders) associated with the glock. If there are any
-held locks, then they will be contiguous entries at the head
-of the list. Locks are granted in strictly the order that they
-are queued, except for those marked LM_FLAG_PRIORITY which are
-used only during recovery, and even then only for journal locks.
-
-There are three lock states that users of the glock layer can request,
-namely shared (SH), deferred (DF) and exclusive (EX). Those translate
-to the following DLM lock modes:
-
-========== ====== =====================================================
-Glock mode DLM lock mode
-========== ====== =====================================================
- UN IV/NL Unlocked (no DLM lock associated with glock) or NL
- SH PR (Protected read)
- DF CW (Concurrent write)
- EX EX (Exclusive)
-========== ====== =====================================================
-
-Thus DF is basically a shared mode which is incompatible with the "normal"
-shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O
-operations. The glocks are basically a lock plus some routines which deal
-with cache management. The following rules apply for the cache:
-
-========== ========== ============== ========== ==============
-Glock mode Cache data Cache Metadata Dirty Data Dirty Metadata
-========== ========== ============== ========== ==============
- UN No No No No
- SH Yes Yes No No
- DF No Yes No No
- EX Yes Yes Yes Yes
-========== ========== ============== ========== ==============
-
-These rules are implemented using the various glock operations which
-are defined for each type of glock. Not all types of glocks use
-all the modes. Only inode glocks use the DF mode for example.
-
-Table of glock operations and per type constants:
-
-============= =============================================================
-Field Purpose
-============= =============================================================
-go_xmote_th Called before remote state change (e.g. to sync dirty data)
-go_xmote_bh Called after remote state change (e.g. to refill cache)
-go_inval Called if remote state change requires invalidating the cache
-go_demote_ok Returns boolean value of whether its ok to demote a glock
- (e.g. checks timeout, and that there is no cached data)
-go_lock Called for the first local holder of a lock
-go_unlock Called on the final local unlock of a lock
-go_dump Called to print content of object for debugfs file, or on
- error to dump glock to the log.
-go_type The type of the glock, ``LM_TYPE_*``
-go_callback Called if the DLM sends a callback to drop this lock
-go_flags GLOF_ASPACE is set, if the glock has an address space
- associated with it
-============= =============================================================
-
-The minimum hold time for each lock is the time after a remote lock
-grant for which we ignore remote demote requests. This is in order to
-prevent a situation where locks are being bounced around the cluster
-from node to node with none of the nodes making any progress. This
-tends to show up most with shared mmaped files which are being written
-to by multiple nodes. By delaying the demotion in response to a
-remote callback, that gives the userspace program time to make
-some progress before the pages are unmapped.
-
-There is a plan to try and remove the go_lock and go_unlock callbacks
-if possible, in order to try and speed up the fast path though the locking.
-Also, eventually we hope to make the glock "EX" mode locally shared
-such that any local locking will be done with the i_mutex as required
-rather than via the glock.
-
-Locking rules for glock operations:
-
-============= ====================== =============================
-Operation GLF_LOCK bit lock held gl_lockref.lock spinlock held
-============= ====================== =============================
-go_xmote_th Yes No
-go_xmote_bh Yes No
-go_inval Yes No
-go_demote_ok Sometimes Yes
-go_lock Yes No
-go_unlock Yes No
-go_dump Sometimes Yes
-go_callback Sometimes (N/A) Yes
-============= ====================== =============================
-
-.. Note::
-
- Operations must not drop either the bit lock or the spinlock
- if its held on entry. go_dump and do_demote_ok must never block.
- Note that go_dump will only be called if the glock's state
- indicates that it is caching uptodate data.
-
-Glock locking order within GFS2:
-
- 1. i_rwsem (if required)
- 2. Rename glock (for rename only)
- 3. Inode glock(s)
- (Parents before children, inodes at "same level" with same parent in
- lock number order)
- 4. Rgrp glock(s) (for (de)allocation operations)
- 5. Transaction glock (via gfs2_trans_begin) for non-read operations
- 6. i_rw_mutex (if required)
- 7. Page lock (always last, very important!)
-
-There are two glocks per inode. One deals with access to the inode
-itself (locking order as above), and the other, known as the iopen
-glock is used in conjunction with the i_nlink field in the inode to
-determine the lifetime of the inode in question. Locking of inodes
-is on a per-inode basis. Locking of rgrps is on a per rgrp basis.
-In general we prefer to lock local locks prior to cluster locks.
-
-Glock Statistics
-----------------
-
-The stats are divided into two sets: those relating to the
-super block and those relating to an individual glock. The
-super block stats are done on a per cpu basis in order to
-try and reduce the overhead of gathering them. They are also
-further divided by glock type. All timings are in nanoseconds.
-
-In the case of both the super block and glock statistics,
-the same information is gathered in each case. The super
-block timing statistics are used to provide default values for
-the glock timing statistics, so that newly created glocks
-should have, as far as possible, a sensible starting point.
-The per-glock counters are initialised to zero when the
-glock is created. The per-glock statistics are lost when
-the glock is ejected from memory.
-
-The statistics are divided into three pairs of mean and
-variance, plus two counters. The mean/variance pairs are
-smoothed exponential estimates and the algorithm used is
-one which will be very familiar to those used to calculation
-of round trip times in network code. See "TCP/IP Illustrated,
-Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement",
-p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards.
-Unlike the TCP/IP Illustrated case, the mean and variance are
-not scaled, but are in units of integer nanoseconds.
-
-The three pairs of mean/variance measure the following
-things:
-
- 1. DLM lock time (non-blocking requests)
- 2. DLM lock time (blocking requests)
- 3. Inter-request time (again to the DLM)
-
-A non-blocking request is one which will complete right
-away, whatever the state of the DLM lock in question. That
-currently means any requests when (a) the current state of
-the lock is exclusive, i.e. a lock demotion (b) the requested
-state is either null or unlocked (again, a demotion) or (c) the
-"try lock" flag is set. A blocking request covers all the other
-lock requests.
-
-There are two counters. The first is there primarily to show
-how many lock requests have been made, and thus how much data
-has gone into the mean/variance calculations. The other counter
-is counting queuing of holders at the top layer of the glock
-code. Hopefully that number will be a lot larger than the number
-of dlm lock requests issued.
-
-So why gather these statistics? There are several reasons
-we'd like to get a better idea of these timings:
-
-1. To be able to better set the glock "min hold time"
-2. To spot performance issues more easily
-3. To improve the algorithm for selecting resource groups for
- allocation (to base it on lock wait time, rather than blindly
- using a "try lock")
-
-Due to the smoothing action of the updates, a step change in
-some input quantity being sampled will only fully be taken
-into account after 8 samples (or 4 for the variance) and this
-needs to be carefully considered when interpreting the
-results.
-
-Knowing both the time it takes a lock request to complete and
-the average time between lock requests for a glock means we
-can compute the total percentage of the time for which the
-node is able to use a glock vs. time that the rest of the
-cluster has its share. That will be very useful when setting
-the lock min hold time.
-
-Great care has been taken to ensure that we
-measure exactly the quantities that we want, as accurately
-as possible. There are always inaccuracies in any
-measuring system, but I hope this is as accurate as we
-can reasonably make it.
-
-Per sb stats can be found here::
-
- /sys/kernel/debug/gfs2/<fsname>/sbstats
-
-Per glock stats can be found here::
-
- /sys/kernel/debug/gfs2/<fsname>/glstats
-
-Assuming that debugfs is mounted on /sys/kernel/debug and also
-that <fsname> is replaced with the name of the gfs2 filesystem
-in question.
-
-The abbreviations used in the output as are follows:
-
-========= ================================================================
-srtt Smoothed round trip time for non blocking dlm requests
-srttvar Variance estimate for srtt
-srttb Smoothed round trip time for (potentially) blocking dlm requests
-srttvarb Variance estimate for srttb
-sirt Smoothed inter request time (for dlm requests)
-sirtvar Variance estimate for sirt
-dlm Number of dlm requests made (dcnt in glstats file)
-queue Number of glock requests queued (qcnt in glstats file)
-========= ================================================================
-
-The sbstats file contains a set of these stats for each glock type (so 8 lines
-for each type) and for each cpu (one column per cpu). The glstats file contains
-a set of these stats for each glock in a similar format to the glocks file, but
-using the format mean/variance for each of the timing stats.
-
-The gfs2_glock_lock_time tracepoint prints out the current values of the stats
-for the glock in question, along with some addition information on each dlm
-reply that is received:
-
-====== =======================================
-status The status of the dlm request
-flags The dlm request flags
-tdiff The time taken by this specific request
-====== =======================================
-
-(remaining fields as per above list)
-
-
diff --git a/Documentation/filesystems/gfs2.rst b/Documentation/filesystems/gfs2.rst
deleted file mode 100644
index 1bc48a13430c..000000000000
--- a/Documentation/filesystems/gfs2.rst
+++ /dev/null
@@ -1,52 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-====================
-Global File System 2
-====================
-
-GFS2 is a cluster file system. It allows a cluster of computers to
-simultaneously use a block device that is shared between them (with FC,
-iSCSI, NBD, etc). GFS2 reads and writes to the block device like a local
-file system, but also uses a lock module to allow the computers coordinate
-their I/O so file system consistency is maintained. One of the nifty
-features of GFS2 is perfect consistency -- changes made to the file system
-on one machine show up immediately on all other machines in the cluster.
-
-GFS2 uses interchangeable inter-node locking mechanisms, the currently
-supported mechanisms are:
-
- lock_nolock
- - allows GFS2 to be used as a local file system
-
- lock_dlm
- - uses the distributed lock manager (dlm) for inter-node locking.
- The dlm is found at linux/fs/dlm/
-
-lock_dlm depends on user space cluster management systems found
-at the URL above.
-
-To use GFS2 as a local file system, no external clustering systems are
-needed, simply::
-
- $ mkfs -t gfs2 -p lock_nolock -j 1 /dev/block_device
- $ mount -t gfs2 /dev/block_device /dir
-
-The gfs2-utils package is required on all cluster nodes and, for lock_dlm, you
-will also need the dlm and corosync user space utilities configured as per the
-documentation.
-
-gfs2-utils can be found at https://pagure.io/gfs2-utils
-
-GFS2 is not on-disk compatible with previous versions of GFS, but it
-is pretty close.
-
-The following man pages are available from gfs2-utils:
-
- ============ =============================================
- fsck.gfs2 to repair a filesystem
- gfs2_grow to expand a filesystem online
- gfs2_jadd to add journals to a filesystem online
- tunegfs2 to manipulate, examine and tune a filesystem
- gfs2_convert to convert a gfs filesystem to GFS2 in-place
- mkfs.gfs2 to make a filesystem
- ============ =============================================
diff --git a/Documentation/filesystems/gfs2/glocks.rst b/Documentation/filesystems/gfs2/glocks.rst
new file mode 100644
index 000000000000..ce5ff08cbd59
--- /dev/null
+++ b/Documentation/filesystems/gfs2/glocks.rst
@@ -0,0 +1,249 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+Glock internal locking rules
+============================
+
+This documents the basic principles of the glock state machine
+internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h)
+has two main (internal) locks:
+
+ 1. A spinlock (gl_lockref.lock) which protects the internal state such
+ as gl_state, gl_target and the list of holders (gl_holders)
+ 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
+ threads from making calls to the DLM, etc. at the same time. If a
+ thread takes this lock, it must then call run_queue (usually via the
+ workqueue) when it releases it in order to ensure any pending tasks
+ are completed.
+
+The gl_holders list contains all the queued lock requests (not
+just the holders) associated with the glock. If there are any
+held locks, then they will be contiguous entries at the head
+of the list. Locks are granted in strictly the order that they
+are queued.
+
+There are three lock states that users of the glock layer can request,
+namely shared (SH), deferred (DF) and exclusive (EX). Those translate
+to the following DLM lock modes:
+
+========== ====== =====================================================
+Glock mode DLM lock mode
+========== ====== =====================================================
+ UN IV/NL Unlocked (no DLM lock associated with glock) or NL
+ SH PR (Protected read)
+ DF CW (Concurrent write)
+ EX EX (Exclusive)
+========== ====== =====================================================
+
+Thus DF is basically a shared mode which is incompatible with the "normal"
+shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O
+operations. The glocks are basically a lock plus some routines which deal
+with cache management. The following rules apply for the cache:
+
+========== ============== ========== ========== ==============
+Glock mode Cache Metadata Cache data Dirty Data Dirty Metadata
+========== ============== ========== ========== ==============
+ UN No No No No
+ DF Yes No No No
+ SH Yes Yes No No
+ EX Yes Yes Yes Yes
+========== ============== ========== ========== ==============
+
+These rules are implemented using the various glock operations which
+are defined for each type of glock. Not all types of glocks use
+all the modes. Only inode glocks use the DF mode for example.
+
+Table of glock operations and per type constants:
+
+============== =============================================================
+Field Purpose
+============== =============================================================
+go_sync Called before remote state change (e.g. to sync dirty data)
+go_xmote_bh Called after remote state change (e.g. to refill cache)
+go_inval Called if remote state change requires invalidating the cache
+go_instantiate Called when a glock has been acquired
+go_held Called every time a glock holder is acquired
+go_dump Called to print content of object for debugfs file, or on
+ error to dump glock to the log.
+go_callback Called if the DLM sends a callback to drop this lock
+go_unlocked Called when a glock is unlocked (dlm_unlock())
+go_type The type of the glock, ``LM_TYPE_*``
+go_flags GLOF_ASPACE is set, if the glock has an address space
+ associated with it
+============== =============================================================
+
+The minimum hold time for each lock is the time after a remote lock
+grant for which we ignore remote demote requests. This is in order to
+prevent a situation where locks are being bounced around the cluster
+from node to node with none of the nodes making any progress. This
+tends to show up most with shared mmapped files which are being written
+to by multiple nodes. By delaying the demotion in response to a
+remote callback, that gives the userspace program time to make
+some progress before the pages are unmapped.
+
+Eventually, we hope to make the glock "EX" mode locally shared such that any
+local locking will be done with the i_mutex as required rather than via the
+glock.
+
+Locking rules for glock operations:
+
+============== ====================== =============================
+Operation GLF_LOCK bit lock held gl_lockref.lock spinlock held
+============== ====================== =============================
+go_sync Yes No
+go_xmote_bh Yes No
+go_inval Yes No
+go_instantiate No No
+go_held No No
+go_dump Sometimes Yes
+go_callback Sometimes (N/A) Yes
+go_unlocked Yes No
+============== ====================== =============================
+
+.. Note::
+
+ Operations must not drop either the bit lock or the spinlock
+ if its held on entry. go_dump and do_demote_ok must never block.
+ Note that go_dump will only be called if the glock's state
+ indicates that it is caching up-to-date data.
+
+Glock locking order within GFS2:
+
+ 1. i_rwsem (if required)
+ 2. Rename glock (for rename only)
+ 3. Inode glock(s)
+ (Parents before children, inodes at "same level" with same parent in
+ lock number order)
+ 4. Rgrp glock(s) (for (de)allocation operations)
+ 5. Transaction glock (via gfs2_trans_begin) for non-read operations
+ 6. i_rw_mutex (if required)
+ 7. Page lock (always last, very important!)
+
+There are two glocks per inode. One deals with access to the inode
+itself (locking order as above), and the other, known as the iopen
+glock is used in conjunction with the i_nlink field in the inode to
+determine the lifetime of the inode in question. Locking of inodes
+is on a per-inode basis. Locking of rgrps is on a per rgrp basis.
+In general we prefer to lock local locks prior to cluster locks.
+
+Glock Statistics
+----------------
+
+The stats are divided into two sets: those relating to the
+super block and those relating to an individual glock. The
+super block stats are done on a per cpu basis in order to
+try and reduce the overhead of gathering them. They are also
+further divided by glock type. All timings are in nanoseconds.
+
+In the case of both the super block and glock statistics,
+the same information is gathered in each case. The super
+block timing statistics are used to provide default values for
+the glock timing statistics, so that newly created glocks
+should have, as far as possible, a sensible starting point.
+The per-glock counters are initialised to zero when the
+glock is created. The per-glock statistics are lost when
+the glock is ejected from memory.
+
+The statistics are divided into three pairs of mean and
+variance, plus two counters. The mean/variance pairs are
+smoothed exponential estimates and the algorithm used is
+one which will be very familiar to those used to calculation
+of round trip times in network code. See "TCP/IP Illustrated,
+Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement",
+p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards.
+Unlike the TCP/IP Illustrated case, the mean and variance are
+not scaled, but are in units of integer nanoseconds.
+
+The three pairs of mean/variance measure the following
+things:
+
+ 1. DLM lock time (non-blocking requests)
+ 2. DLM lock time (blocking requests)
+ 3. Inter-request time (again to the DLM)
+
+A non-blocking request is one which will complete right
+away, whatever the state of the DLM lock in question. That
+currently means any requests when (a) the current state of
+the lock is exclusive, i.e. a lock demotion (b) the requested
+state is either null or unlocked (again, a demotion) or (c) the
+"try lock" flag is set. A blocking request covers all the other
+lock requests.
+
+There are two counters. The first is there primarily to show
+how many lock requests have been made, and thus how much data
+has gone into the mean/variance calculations. The other counter
+is counting queuing of holders at the top layer of the glock
+code. Hopefully that number will be a lot larger than the number
+of dlm lock requests issued.
+
+So why gather these statistics? There are several reasons
+we'd like to get a better idea of these timings:
+
+1. To be able to better set the glock "min hold time"
+2. To spot performance issues more easily
+3. To improve the algorithm for selecting resource groups for
+ allocation (to base it on lock wait time, rather than blindly
+ using a "try lock")
+
+Due to the smoothing action of the updates, a step change in
+some input quantity being sampled will only fully be taken
+into account after 8 samples (or 4 for the variance) and this
+needs to be carefully considered when interpreting the
+results.
+
+Knowing both the time it takes a lock request to complete and
+the average time between lock requests for a glock means we
+can compute the total percentage of the time for which the
+node is able to use a glock vs. time that the rest of the
+cluster has its share. That will be very useful when setting
+the lock min hold time.
+
+Great care has been taken to ensure that we
+measure exactly the quantities that we want, as accurately
+as possible. There are always inaccuracies in any
+measuring system, but I hope this is as accurate as we
+can reasonably make it.
+
+Per sb stats can be found here::
+
+ /sys/kernel/debug/gfs2/<fsname>/sbstats
+
+Per glock stats can be found here::
+
+ /sys/kernel/debug/gfs2/<fsname>/glstats
+
+Assuming that debugfs is mounted on /sys/kernel/debug and also
+that <fsname> is replaced with the name of the gfs2 filesystem
+in question.
+
+The abbreviations used in the output as are follows:
+
+========= ================================================================
+srtt Smoothed round trip time for non blocking dlm requests
+srttvar Variance estimate for srtt
+srttb Smoothed round trip time for (potentially) blocking dlm requests
+srttvarb Variance estimate for srttb
+sirt Smoothed inter request time (for dlm requests)
+sirtvar Variance estimate for sirt
+dlm Number of dlm requests made (dcnt in glstats file)
+queue Number of glock requests queued (qcnt in glstats file)
+========= ================================================================
+
+The sbstats file contains a set of these stats for each glock type (so 8 lines
+for each type) and for each cpu (one column per cpu). The glstats file contains
+a set of these stats for each glock in a similar format to the glocks file, but
+using the format mean/variance for each of the timing stats.
+
+The gfs2_glock_lock_time tracepoint prints out the current values of the stats
+for the glock in question, along with some addition information on each dlm
+reply that is received:
+
+====== =======================================
+status The status of the dlm request
+flags The dlm request flags
+tdiff The time taken by this specific request
+====== =======================================
+
+(remaining fields as per above list)
+
+
diff --git a/Documentation/filesystems/gfs2/index.rst b/Documentation/filesystems/gfs2/index.rst
new file mode 100644
index 000000000000..e5e195403561
--- /dev/null
+++ b/Documentation/filesystems/gfs2/index.rst
@@ -0,0 +1,64 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Global File System 2
+====================
+
+Overview
+========
+
+GFS2 is a cluster file system. It allows a cluster of computers to
+simultaneously use a block device that is shared between them (with FC,
+iSCSI, NBD, etc). GFS2 reads and writes to the block device like a local
+file system, but also uses a lock module to allow the computers coordinate
+their I/O so file system consistency is maintained. One of the nifty
+features of GFS2 is perfect consistency -- changes made to the file system
+on one machine show up immediately on all other machines in the cluster.
+
+GFS2 uses interchangeable inter-node locking mechanisms, the currently
+supported mechanisms are:
+
+ lock_nolock
+ - allows GFS2 to be used as a local file system
+
+ lock_dlm
+ - uses the distributed lock manager (dlm) for inter-node locking.
+ The dlm is found at linux/fs/dlm/
+
+lock_dlm depends on user space cluster management systems found
+at the URL above.
+
+To use GFS2 as a local file system, no external clustering systems are
+needed, simply::
+
+ $ mkfs -t gfs2 -p lock_nolock -j 1 /dev/block_device
+ $ mount -t gfs2 /dev/block_device /dir
+
+The gfs2-utils package is required on all cluster nodes and, for lock_dlm, you
+will also need the dlm and corosync user space utilities configured as per the
+documentation.
+
+gfs2-utils can be found at https://pagure.io/gfs2-utils
+
+GFS2 is not on-disk compatible with previous versions of GFS, but it
+is pretty close.
+
+The following man pages are available from gfs2-utils:
+
+ ============ =============================================
+ fsck.gfs2 to repair a filesystem
+ gfs2_grow to expand a filesystem online
+ gfs2_jadd to add journals to a filesystem online
+ tunegfs2 to manipulate, examine and tune a filesystem
+ gfs2_convert to convert a gfs filesystem to GFS2 in-place
+ mkfs.gfs2 to make a filesystem
+ ============ =============================================
+
+Implementation Notes
+====================
+
+.. toctree::
+ :maxdepth: 1
+
+ glocks
+ uevents
diff --git a/Documentation/filesystems/gfs2-uevents.rst b/Documentation/filesystems/gfs2/uevents.rst
index f162a2c76c69..f162a2c76c69 100644
--- a/Documentation/filesystems/gfs2-uevents.rst
+++ b/Documentation/filesystems/gfs2/uevents.rst
diff --git a/Documentation/filesystems/hpfs.rst b/Documentation/filesystems/hpfs.rst
index 7e0dd2f4373e..0f9516b5eb07 100644
--- a/Documentation/filesystems/hpfs.rst
+++ b/Documentation/filesystems/hpfs.rst
@@ -65,7 +65,7 @@ are case sensitive, so for example when you create a file FOO, you can use
'cat FOO', 'cat Foo', 'cat foo' or 'cat F*' but not 'cat f*'. Note, that you
also won't be able to compile linux kernel (and maybe other things) on HPFS
because kernel creates different files with names like bootsect.S and
-bootsect.s. When searching for file thats name has characters >= 128, codepages
+bootsect.s. When searching for file whose name has characters >= 128, codepages
are used - see below.
OS/2 ignores dots and spaces at the end of file name, so this driver does as
well. If you create 'a. ...', the file 'a' will be created, but you can still
diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst
index b9b31066aef2..2a206129f828 100644
--- a/Documentation/filesystems/idmappings.rst
+++ b/Documentation/filesystems/idmappings.rst
@@ -36,7 +36,7 @@ and write down the mappings it will generate::
From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an
idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are
order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
-the set of all possible ids useable on a given system.
+the set of all possible ids usable on a given system.
Looking at this mathematically briefly will help us highlight some properties
that make it easier to understand how we can translate between idmappings. For
@@ -47,7 +47,7 @@ example, we know that the inverse idmapping is an order isomorphism as well::
k10002 -> u24
Given that we are dealing with order isomorphisms plus the fact that we're
-dealing with subsets we can embedd idmappings into each other, i.e. we can
+dealing with subsets we can embed idmappings into each other, i.e. we can
sensibly translate between different idmappings. For example, assume we've been
given the three idmappings::
@@ -60,11 +60,11 @@ and id ``k11000`` which has been generated by the first idmapping by mapping
Because we're dealing with order isomorphic subsets it is meaningful to ask
what id ``k11000`` corresponds to in the second or third idmapping. The
-straightfoward algorithm to use is to apply the inverse of the first idmapping,
+straightforward algorithm to use is to apply the inverse of the first idmapping,
mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using
either the second idmapping mapping or third idmapping mapping. The second
-idmapping would map ``u1000`` down to ``21000``. The third idmapping would map
-``u1000`` down to ``u31000``.
+idmapping would map ``u1000`` down to ``k21000``. The third idmapping would map
+``u1000`` down to ``k31000``.
If we were given the same task for the following three idmappings::
@@ -146,9 +146,10 @@ For the rest of this document we will prefix all userspace ids with ``u`` and
all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So
an idmapping will be written as ``u0:k10000:r10000``.
-For example, the id ``u1000`` is an id in the upper idmapset or "userspace
-idmapset" starting with ``u1000``. And it is mapped to ``k11000`` which is a
-kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``.
+For example, within this idmapping, the id ``u1000`` is an id in the upper
+idmapset or "userspace idmapset" starting with ``u0``. And it is mapped to
+``k11000`` which is a kernel id in the lower idmapset or "kernel idmapset"
+starting with ``k10000``.
A kernel id is always created by an idmapping. Such idmappings are associated
with user namespaces. Since we mainly care about how idmappings work we're not
@@ -241,7 +242,7 @@ according to the filesystem's idmapping as this would give the wrong owner if
the caller is using an idmapping.
So the kernel will map the id back up in the idmapping of the caller. Let's
-assume the caller has the slighly unconventional idmapping
+assume the caller has the somewhat unconventional idmapping
``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``.
Consequently the user would see that this file is owned by ``u4000``.
@@ -320,6 +321,10 @@ and equally wrong::
from_kuid(u20000:k0:r10000, u1000) = k21000
~~~~~
+Since userspace ids have type ``uid_t`` and ``gid_t`` and kernel ids have type
+``kuid_t`` and ``kgid_t`` the compiler will throw an error when they are
+conflated. So the two examples above would cause a compilation failure.
+
Idmappings when creating filesystem objects
-------------------------------------------
@@ -363,12 +368,19 @@ So with the second step the kernel guarantees that a valid userspace id can be
written to disk. If it can't the kernel will refuse the creation request to not
even remotely risk filesystem corruption.
-The astute reader will have realized that this is simply a varation of the
+The astute reader will have realized that this is simply a variation of the
crossmapping algorithm we mentioned above in a previous section. First, the
kernel maps the caller's userspace id down into a kernel id according to the
caller's idmapping and then maps that kernel id up according to the
filesystem's idmapping.
+From the implementation point it's worth mentioning how idmappings are represented.
+All idmappings are taken from the corresponding user namespace.
+
+ - caller's idmapping (usually taken from ``current_user_ns()``)
+ - filesystem's idmapping (``sb->s_user_ns``)
+ - mount's idmapping (``mnt_idmap(vfsmnt)``)
+
Let's see some examples with caller/filesystem idmapping but without mount
idmappings. This will exhibit some problems we can hit. After that we will
revisit/reconsider these examples, this time using mount idmappings, to see how
@@ -454,7 +466,7 @@ the kernel id that was created in the caller's idmapping. This has mainly two
consequences.
First, that we can't allow a caller to ultimately write to disk with another
-userspace id. We could only do this if we were to mount the whole fileystem
+userspace id. We could only do this if we were to mount the whole filesystem
with the caller's or another idmapping. But that solution is limited to a few
filesystems and not very flexible. But this is a use-case that is pretty
important in containerized workloads.
@@ -585,7 +597,7 @@ on their work machine.
In both cases changing ownership recursively has grave implications. The most
obvious one is that ownership is changed globally and permanently. In the home
-directory case this change in ownership would even need to happen everytime the
+directory case this change in ownership would even need to happen every time the
user switches from their home to their work machine. For really large sets of
files this becomes increasingly costly.
@@ -623,42 +635,105 @@ privileged users in the initial user namespace.
However, it is perfectly possible to combine idmapped mounts with filesystems
mountable inside user namespaces. We will touch on this further below.
+Filesystem types vs idmapped mount types
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+With the introduction of idmapped mounts we need to distinguish between
+filesystem ownership and mount ownership of a VFS object such as an inode. The
+owner of a inode might be different when looked at from a filesystem
+perspective than when looked at from an idmapped mount. Such fundamental
+conceptual distinctions should almost always be clearly expressed in the code.
+So, to distinguish idmapped mount ownership from filesystem ownership separate
+types have been introduced.
+
+If a uid or gid has been generated using the filesystem or caller's idmapping
+then we will use the ``kuid_t`` and ``kgid_t`` types. However, if a uid or gid
+has been generated using a mount idmapping then we will be using the dedicated
+``vfsuid_t`` and ``vfsgid_t`` types.
+
+All VFS helpers that generate or take uids and gids as arguments use the
+``vfsuid_t`` and ``vfsgid_t`` types and we will be able to rely on the compiler
+to catch errors that originate from conflating filesystem and VFS uids and gids.
+
+The ``vfsuid_t`` and ``vfsgid_t`` types are often mapped from and to ``kuid_t``
+and ``kgid_t`` types similar how ``kuid_t`` and ``kgid_t`` types are mapped
+from and to ``uid_t`` and ``gid_t`` types::
+
+ uid_t <--> kuid_t <--> vfsuid_t
+ gid_t <--> kgid_t <--> vfsgid_t
+
+Whenever we report ownership based on a ``vfsuid_t`` or ``vfsgid_t`` type,
+e.g., during ``stat()``, or store ownership information in a shared VFS object
+based on a ``vfsuid_t`` or ``vfsgid_t`` type, e.g., during ``chown()`` we can
+use the ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` helpers.
+
+To illustrate why this helper currently exists, consider what happens when we
+change ownership of an inode from an idmapped mount. After we generated
+a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to
+this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership.
+Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t``
+or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and
+``vfsgid_into_kgid()``.
+
+Note, whenever a shared VFS object, e.g., a cached ``struct inode`` or a cached
+``struct posix_acl``, stores ownership information a filesystem or "global"
+``kuid_t`` and ``kgid_t`` must be used. Ownership expressed via ``vfsuid_t``
+and ``vfsgid_t`` is specific to an idmapped mount.
+
+We already noted that ``vfsuid_t`` and ``vfsgid_t`` types are generated based
+on mount idmappings whereas ``kuid_t`` and ``kgid_t`` types are generated based
+on filesystem idmappings. To prevent abusing filesystem idmappings to generate
+``vfsuid_t`` or ``vfsgid_t`` types or mount idmappings to generate ``kuid_t``
+or ``kgid_t`` types filesystem idmappings and mount idmappings are different
+types as well.
+
+All helpers that map to or from ``vfsuid_t`` and ``vfsgid_t`` types require
+a mount idmapping to be passed which is of type ``struct mnt_idmap``. Passing
+a filesystem or caller idmapping will cause a compilation error.
+
+Similar to how we prefix all userspace ids in this document with ``u`` and all
+kernel ids with ``k`` we will prefix all VFS ids with ``v``. So a mount
+idmapping will be written as: ``u0:v10000:r10000``.
+
Remapping helpers
~~~~~~~~~~~~~~~~~
Idmapping functions were added that translate between idmappings. They make use
-of the remapping algorithm we've introduced earlier. We're going to look at
-two:
+of the remapping algorithm we've introduced earlier. We're going to look at:
-- ``i_uid_into_mnt()`` and ``i_gid_into_mnt()``
+- ``i_uid_into_vfsuid()`` and ``i_gid_into_vfsgid()``
- The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into
- kernel ids in the mount's idmapping::
+ The ``i_*id_into_vfs*id()`` functions translate filesystem's kernel ids into
+ VFS ids in the mount's idmapping::
/* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */
from_kuid(filesystem, kid) = uid
- /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
+ /* Map the filesystem's userspace id down ito a VFS id in the mount's idmapping. */
make_kuid(mount, uid) = kuid
- ``mapped_fsuid()`` and ``mapped_fsgid()``
The ``mapped_fs*id()`` functions translate the caller's kernel ids into
kernel ids in the filesystem's idmapping. This translation is achieved by
- remapping the caller's kernel ids using the mount's idmapping::
+ remapping the caller's VFS ids using the mount's idmapping::
- /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
+ /* Map the caller's VFS id up into a userspace id in the mount's idmapping. */
from_kuid(mount, kid) = uid
/* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
make_kuid(filesystem, uid) = kuid
+- ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()``
+
+ Whenever
+
Note that these two functions invert each other. Consider the following
idmappings::
caller idmapping: u0:k10000:r10000
filesystem idmapping: u0:k20000:r10000
- mount idmapping: u0:k10000:r10000
+ mount idmapping: u0:v10000:r10000
Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id
to ``k21000`` according to its idmapping. This is what is stored in the
@@ -669,20 +744,21 @@ would usually simply use the crossmapping algorithm and map the filesystem's
kernel id up to a userspace id in the caller's idmapping.
But when the caller is accessing the file on an idmapped mount the kernel will
-first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id
-into a kernel id in the mount's idmapping::
+first call ``i_uid_into_vfsuid()`` thereby translating the filesystem's kernel
+id into a VFS id in the mount's idmapping::
- i_uid_into_mnt(k21000):
+ i_uid_into_vfsuid(k21000):
/* Map the filesystem's kernel id up into a userspace id. */
from_kuid(u0:k20000:r10000, k21000) = u1000
- /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */
- make_kuid(u0:k10000:r10000, u1000) = k11000
+ /* Map the filesystem's userspace id down into a VFS id in the mount's idmapping. */
+ make_kuid(u0:v10000:r10000, u1000) = v11000
Finally, when the kernel reports the owner to the caller it will turn the
-kernel id in the mount's idmapping into a userspace id in the caller's
+VFS id in the mount's idmapping into a userspace id in the caller's
idmapping::
+ k11000 = vfsuid_into_kuid(v11000)
from_kuid(u0:k10000:r10000, k11000) = u1000
We can test whether this algorithm really works by verifying what happens when
@@ -696,18 +772,19 @@ fails.
But when the caller is accessing the file on an idmapped mount the kernel will
first call ``mapped_fs*id()`` thereby translating the caller's kernel id into
-a kernel id according to the mount's idmapping::
+a VFS id according to the mount's idmapping::
mapped_fsuid(k11000):
/* Map the caller's kernel id up into a userspace id in the mount's idmapping. */
from_kuid(u0:k10000:r10000, k11000) = u1000
/* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */
- make_kuid(u0:k20000:r10000, u1000) = k21000
+ make_kuid(u0:v20000:r10000, u1000) = v21000
-When finally writing to disk the kernel will then map ``k21000`` up into a
+When finally writing to disk the kernel will then map ``v21000`` up into a
userspace id in the filesystem's idmapping::
+ k21000 = vfsuid_into_kuid(v21000)
from_kuid(u0:k20000:r10000, k21000) = u1000
As we can see, we end up with an invertible and therefore information
@@ -725,7 +802,7 @@ Example 2 reconsidered
caller id: u1000
caller idmapping: u0:k10000:r10000
filesystem idmapping: u0:k20000:r10000
- mount idmapping: u0:k10000:r10000
+ mount idmapping: u0:v10000:r10000
When the caller is using a non-initial idmapping the common case is to attach
the same idmapping to the mount. We now perform three steps:
@@ -734,17 +811,17 @@ the same idmapping to the mount. We now perform three steps:
make_kuid(u0:k10000:r10000, u1000) = k11000
-2. Translate the caller's kernel id into a kernel id in the filesystem's
+2. Translate the caller's VFS id into a kernel id in the filesystem's
idmapping::
- mapped_fsuid(k11000):
- /* Map the kernel id up into a userspace id in the mount's idmapping. */
- from_kuid(u0:k10000:r10000, k11000) = u1000
+ mapped_fsuid(v11000):
+ /* Map the VFS id up into a userspace id in the mount's idmapping. */
+ from_kuid(u0:v10000:r10000, v11000) = u1000
/* Map the userspace id down into a kernel id in the filesystem's idmapping. */
make_kuid(u0:k20000:r10000, u1000) = k21000
-2. Verify that the caller's kernel ids can be mapped to userspace ids in the
+3. Verify that the caller's kernel ids can be mapped to userspace ids in the
filesystem's idmapping::
from_kuid(u0:k20000:r10000, k21000) = u1000
@@ -759,7 +836,7 @@ Example 3 reconsidered
caller id: u1000
caller idmapping: u0:k10000:r10000
filesystem idmapping: u0:k0:r4294967295
- mount idmapping: u0:k10000:r10000
+ mount idmapping: u0:v10000:r10000
The same translation algorithm works with the third example.
@@ -767,20 +844,20 @@ The same translation algorithm works with the third example.
make_kuid(u0:k10000:r10000, u1000) = k11000
-2. Translate the caller's kernel id into a kernel id in the filesystem's
+2. Translate the caller's VFS id into a kernel id in the filesystem's
idmapping::
- mapped_fsuid(k11000):
- /* Map the kernel id up into a userspace id in the mount's idmapping. */
- from_kuid(u0:k10000:r10000, k11000) = u1000
+ mapped_fsuid(v11000):
+ /* Map the VFS id up into a userspace id in the mount's idmapping. */
+ from_kuid(u0:v10000:r10000, v11000) = u1000
/* Map the userspace id down into a kernel id in the filesystem's idmapping. */
make_kuid(u0:k0:r4294967295, u1000) = k1000
-2. Verify that the caller's kernel ids can be mapped to userspace ids in the
+3. Verify that the caller's kernel ids can be mapped to userspace ids in the
filesystem's idmapping::
- from_kuid(u0:k0:r4294967295, k21000) = u1000
+ from_kuid(u0:k0:r4294967295, k1000) = u1000
So the ownership that lands on disk will be ``u1000``.
@@ -792,7 +869,7 @@ Example 4 reconsidered
file id: u1000
caller idmapping: u0:k10000:r10000
filesystem idmapping: u0:k0:r4294967295
- mount idmapping: u0:k10000:r10000
+ mount idmapping: u0:v10000:r10000
In order to report ownership to userspace the kernel now does three steps using
the translation algorithm we introduced earlier:
@@ -802,17 +879,18 @@ the translation algorithm we introduced earlier:
make_kuid(u0:k0:r4294967295, u1000) = k1000
-2. Translate the kernel id into a kernel id in the mount's idmapping::
+2. Translate the kernel id into a VFS id in the mount's idmapping::
- i_uid_into_mnt(k1000):
+ i_uid_into_vfsuid(k1000):
/* Map the kernel id up into a userspace id in the filesystem's idmapping. */
from_kuid(u0:k0:r4294967295, k1000) = u1000
- /* Map the userspace id down into a kernel id in the mounts's idmapping. */
- make_kuid(u0:k10000:r10000, u1000) = k11000
+ /* Map the userspace id down into a VFS id in the mounts's idmapping. */
+ make_kuid(u0:v10000:r10000, u1000) = v11000
-3. Map the kernel id up into a userspace id in the caller's idmapping::
+3. Map the VFS id up into a userspace id in the caller's idmapping::
+ k11000 = vfsuid_into_kuid(v11000)
from_kuid(u0:k10000:r10000, k11000) = u1000
Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's
@@ -828,7 +906,7 @@ Example 5 reconsidered
file id: u1000
caller idmapping: u0:k10000:r10000
filesystem idmapping: u0:k20000:r10000
- mount idmapping: u0:k10000:r10000
+ mount idmapping: u0:v10000:r10000
Again, in order to report ownership to userspace the kernel now does three
steps using the translation algorithm we introduced earlier:
@@ -838,17 +916,18 @@ steps using the translation algorithm we introduced earlier:
make_kuid(u0:k20000:r10000, u1000) = k21000
-2. Translate the kernel id into a kernel id in the mount's idmapping::
+2. Translate the kernel id into a VFS id in the mount's idmapping::
- i_uid_into_mnt(k21000):
+ i_uid_into_vfsuid(k21000):
/* Map the kernel id up into a userspace id in the filesystem's idmapping. */
from_kuid(u0:k20000:r10000, k21000) = u1000
- /* Map the userspace id down into a kernel id in the mounts's idmapping. */
- make_kuid(u0:k10000:r10000, u1000) = k11000
+ /* Map the userspace id down into a VFS id in the mounts's idmapping. */
+ make_kuid(u0:v10000:r10000, u1000) = v11000
-3. Map the kernel id up into a userspace id in the caller's idmapping::
+3. Map the VFS id up into a userspace id in the caller's idmapping::
+ k11000 = vfsuid_into_kuid(v11000)
from_kuid(u0:k10000:r10000, k11000) = u1000
Earlier, the file's kernel id couldn't be crossmapped in the filesystems's
@@ -899,23 +978,23 @@ from above:::
caller id: u1125
caller idmapping: u0:k0:r4294967295
filesystem idmapping: u0:k0:r4294967295
- mount idmapping: u1000:k1125:r1
+ mount idmapping: u1000:v1125:r1
1. Map the caller's userspace ids into kernel ids in the caller's idmapping::
make_kuid(u0:k0:r4294967295, u1125) = k1125
-2. Translate the caller's kernel id into a kernel id in the filesystem's
+2. Translate the caller's VFS id into a kernel id in the filesystem's
idmapping::
- mapped_fsuid(k1125):
- /* Map the kernel id up into a userspace id in the mount's idmapping. */
- from_kuid(u1000:k1125:r1, k1125) = u1000
+ mapped_fsuid(v1125):
+ /* Map the VFS id up into a userspace id in the mount's idmapping. */
+ from_kuid(u1000:v1125:r1, v1125) = u1000
/* Map the userspace id down into a kernel id in the filesystem's idmapping. */
make_kuid(u0:k0:r4294967295, u1000) = k1000
-2. Verify that the caller's kernel ids can be mapped to userspace ids in the
+3. Verify that the caller's filesystem ids can be mapped to userspace ids in the
filesystem's idmapping::
from_kuid(u0:k0:r4294967295, k1000) = u1000
@@ -930,24 +1009,25 @@ on their work computer:
file id: u1000
caller idmapping: u0:k0:r4294967295
filesystem idmapping: u0:k0:r4294967295
- mount idmapping: u1000:k1125:r1
+ mount idmapping: u1000:v1125:r1
1. Map the userspace id on disk down into a kernel id in the filesystem's
idmapping::
make_kuid(u0:k0:r4294967295, u1000) = k1000
-2. Translate the kernel id into a kernel id in the mount's idmapping::
+2. Translate the kernel id into a VFS id in the mount's idmapping::
- i_uid_into_mnt(k1000):
+ i_uid_into_vfsuid(k1000):
/* Map the kernel id up into a userspace id in the filesystem's idmapping. */
from_kuid(u0:k0:r4294967295, k1000) = u1000
- /* Map the userspace id down into a kernel id in the mounts's idmapping. */
- make_kuid(u1000:k1125:r1, u1000) = k1125
+ /* Map the userspace id down into a VFS id in the mounts's idmapping. */
+ make_kuid(u1000:v1125:r1, u1000) = v1125
-3. Map the kernel id up into a userspace id in the caller's idmapping::
+3. Map the VFS id up into a userspace id in the caller's idmapping::
+ k1125 = vfsuid_into_kuid(v1125)
from_kuid(u0:k0:r4294967295, k1125) = u1125
So ultimately the caller will be reported that the file belongs to ``u1125``
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index bee63d42e5ec..f4873197587d 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -29,11 +29,13 @@ algorithms work.
fiemap
files
locks
+ multigrain-ts
mount_api
quota
seq_file
sharedsubtree
idmappings
+ iomap/index
automount-support
@@ -50,6 +52,7 @@ filesystem implementations.
.. toctree::
:maxdepth: 2
+ buffer
journalling
fscrypt
fsverity
@@ -72,7 +75,6 @@ Documentation for filesystem implementations.
befs
bfs
btrfs
- cifs/index
ceph
coda
configfs
@@ -87,19 +89,15 @@ Documentation for filesystem implementations.
ext3
ext4/index
f2fs
- gfs2
- gfs2-uevents
- gfs2-glocks
+ gfs2/index
hfs
hfsplus
hpfs
- fuse
- fuse-io
+ fuse/index
inotify
isofs
nilfs2
nfs/index
- ntfs
ntfs3
ocfs2
ocfs2-online-filecheck
@@ -110,17 +108,17 @@ Documentation for filesystem implementations.
qnx6
ramfs-rootfs-initramfs
relay
+ resctrl
romfs
+ smb/index
spufs/index
squashfs
sysfs
- sysv-fs
tmpfs
ubifs
ubifs-authentication
udf
virtiofs
vfat
- xfs-delayed-logging-design
- xfs-self-describing-metadata
+ xfs/index
zonefs
diff --git a/Documentation/filesystems/iomap/design.rst b/Documentation/filesystems/iomap/design.rst
new file mode 100644
index 000000000000..0f7672676c0b
--- /dev/null
+++ b/Documentation/filesystems/iomap/design.rst
@@ -0,0 +1,459 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _iomap_design:
+
+..
+ Dumb style notes to maintain the author's sanity:
+ Please try to start sentences on separate lines so that
+ sentence changes don't bleed colors in diff.
+ Heading decorations are documented in sphinx.rst.
+
+==============
+Library Design
+==============
+
+.. contents:: Table of Contents
+ :local:
+
+Introduction
+============
+
+iomap is a filesystem library for handling common file operations.
+The library has two layers:
+
+ 1. A lower layer that provides an iterator over ranges of file offsets.
+ This layer tries to obtain mappings of each file ranges to storage
+ from the filesystem, but the storage information is not necessarily
+ required.
+
+ 2. An upper layer that acts upon the space mappings provided by the
+ lower layer iterator.
+
+The iteration can involve mappings of file's logical offset ranges to
+physical extents, but the storage layer information is not necessarily
+required, e.g. for walking cached file information.
+The library exports various APIs for implementing file operations such
+as:
+
+ * Pagecache reads and writes
+ * Folio write faults to the pagecache
+ * Writeback of dirty folios
+ * Direct I/O reads and writes
+ * fsdax I/O reads, writes, loads, and stores
+ * FIEMAP
+ * lseek ``SEEK_DATA`` and ``SEEK_HOLE``
+ * swapfile activation
+
+This origins of this library is the file I/O path that XFS once used; it
+has now been extended to cover several other operations.
+
+Who Should Read This?
+=====================
+
+The target audience for this document are filesystem, storage, and
+pagecache programmers and code reviewers.
+
+If you are working on PCI, machine architectures, or device drivers, you
+are most likely in the wrong place.
+
+How Is This Better?
+===================
+
+Unlike the classic Linux I/O model which breaks file I/O into small
+units (generally memory pages or blocks) and looks up space mappings on
+the basis of that unit, the iomap model asks the filesystem for the
+largest space mappings that it can create for a given file operation and
+initiates operations on that basis.
+This strategy improves the filesystem's visibility into the size of the
+operation being performed, which enables it to combat fragmentation with
+larger space allocations when possible.
+Larger space mappings improve runtime performance by amortizing the cost
+of mapping function calls into the filesystem across a larger amount of
+data.
+
+At a high level, an iomap operation `looks like this
+<https://lore.kernel.org/all/ZGbVaewzcCysclPt@dread.disaster.area/>`_:
+
+1. For each byte in the operation range...
+
+ 1. Obtain a space mapping via ``->iomap_begin``
+
+ 2. For each sub-unit of work...
+
+ 1. Revalidate the mapping and go back to (1) above, if necessary.
+ So far only the pagecache operations need to do this.
+
+ 2. Do the work
+
+ 3. Increment operation cursor
+
+ 4. Release the mapping via ``->iomap_end``, if necessary
+
+Each iomap operation will be covered in more detail below.
+This library was covered previously by an `LWN article
+<https://lwn.net/Articles/935934/>`_ and a `KernelNewbies page
+<https://kernelnewbies.org/KernelProjects/iomap>`_.
+
+The goal of this document is to provide a brief discussion of the
+design and capabilities of iomap, followed by a more detailed catalog
+of the interfaces presented by iomap.
+If you change iomap, please update this design document.
+
+File Range Iterator
+===================
+
+Definitions
+-----------
+
+ * **buffer head**: Shattered remnants of the old buffer cache.
+
+ * ``fsblock``: The block size of a file, also known as ``i_blocksize``.
+
+ * ``i_rwsem``: The VFS ``struct inode`` rwsemaphore.
+ Processes hold this in shared mode to read file state and contents.
+ Some filesystems may allow shared mode for writes.
+ Processes often hold this in exclusive mode to change file state and
+ contents.
+
+ * ``invalidate_lock``: The pagecache ``struct address_space``
+ rwsemaphore that protects against folio insertion and removal for
+ filesystems that support punching out folios below EOF.
+ Processes wishing to insert folios must hold this lock in shared
+ mode to prevent removal, though concurrent insertion is allowed.
+ Processes wishing to remove folios must hold this lock in exclusive
+ mode to prevent insertions.
+ Concurrent removals are not allowed.
+
+ * ``dax_read_lock``: The RCU read lock that dax takes to prevent a
+ device pre-shutdown hook from returning before other threads have
+ released resources.
+
+ * **filesystem mapping lock**: This synchronization primitive is
+ internal to the filesystem and must protect the file mapping data
+ from updates while a mapping is being sampled.
+ The filesystem author must determine how this coordination should
+ happen; it does not need to be an actual lock.
+
+ * **iomap internal operation lock**: This is a general term for
+ synchronization primitives that iomap functions take while holding a
+ mapping.
+ A specific example would be taking the folio lock while reading or
+ writing the pagecache.
+
+ * **pure overwrite**: A write operation that does not require any
+ metadata or zeroing operations to perform during either submission
+ or completion.
+ This implies that the filesystem must have already allocated space
+ on disk as ``IOMAP_MAPPED`` and the filesystem must not place any
+ constraints on IO alignment or size.
+ The only constraints on I/O alignment are device level (minimum I/O
+ size and alignment, typically sector size).
+
+``struct iomap``
+----------------
+
+The filesystem communicates to the iomap iterator the mapping of
+byte ranges of a file to byte ranges of a storage device with the
+structure below:
+
+.. code-block:: c
+
+ struct iomap {
+ u64 addr;
+ loff_t offset;
+ u64 length;
+ u16 type;
+ u16 flags;
+ struct block_device *bdev;
+ struct dax_device *dax_dev;
+ void *inline_data;
+ void *private;
+ u64 validity_cookie;
+ };
+
+The fields are as follows:
+
+ * ``offset`` and ``length`` describe the range of file offsets, in
+ bytes, covered by this mapping.
+ These fields must always be set by the filesystem.
+
+ * ``type`` describes the type of the space mapping:
+
+ * **IOMAP_HOLE**: No storage has been allocated.
+ This type must never be returned in response to an ``IOMAP_WRITE``
+ operation because writes must allocate and map space, and return
+ the mapping.
+ The ``addr`` field must be set to ``IOMAP_NULL_ADDR``.
+ iomap does not support writing (whether via pagecache or direct
+ I/O) to a hole.
+
+ * **IOMAP_DELALLOC**: A promise to allocate space at a later time
+ ("delayed allocation").
+ If the filesystem returns IOMAP_F_NEW here and the write fails, the
+ ``->iomap_end`` function must delete the reservation.
+ The ``addr`` field must be set to ``IOMAP_NULL_ADDR``.
+
+ * **IOMAP_MAPPED**: The file range maps to specific space on the
+ storage device.
+ The device is returned in ``bdev`` or ``dax_dev``.
+ The device address, in bytes, is returned via ``addr``.
+
+ * **IOMAP_UNWRITTEN**: The file range maps to specific space on the
+ storage device, but the space has not yet been initialized.
+ The device is returned in ``bdev`` or ``dax_dev``.
+ The device address, in bytes, is returned via ``addr``.
+ Reads from this type of mapping will return zeroes to the caller.
+ For a write or writeback operation, the ioend should update the
+ mapping to MAPPED.
+ Refer to the sections about ioends for more details.
+
+ * **IOMAP_INLINE**: The file range maps to the memory buffer
+ specified by ``inline_data``.
+ For write operation, the ``->iomap_end`` function presumably
+ handles persisting the data.
+ The ``addr`` field must be set to ``IOMAP_NULL_ADDR``.
+
+ * ``flags`` describe the status of the space mapping.
+ These flags should be set by the filesystem in ``->iomap_begin``:
+
+ * **IOMAP_F_NEW**: The space under the mapping is newly allocated.
+ Areas that will not be written to must be zeroed.
+ If a write fails and the mapping is a space reservation, the
+ reservation must be deleted.
+
+ * **IOMAP_F_DIRTY**: The inode will have uncommitted metadata needed
+ to access any data written.
+ fdatasync is required to commit these changes to persistent
+ storage.
+ This needs to take into account metadata changes that *may* be made
+ at I/O completion, such as file size updates from direct I/O.
+
+ * **IOMAP_F_SHARED**: The space under the mapping is shared.
+ Copy on write is necessary to avoid corrupting other file data.
+
+ * **IOMAP_F_BUFFER_HEAD**: This mapping requires the use of buffer
+ heads for pagecache operations.
+ Do not add more uses of this.
+
+ * **IOMAP_F_MERGED**: Multiple contiguous block mappings were
+ coalesced into this single mapping.
+ This is only useful for FIEMAP.
+
+ * **IOMAP_F_XATTR**: The mapping is for extended attribute data, not
+ regular file data.
+ This is only useful for FIEMAP.
+
+ * **IOMAP_F_BOUNDARY**: This indicates I/O and its completion must not be
+ merged with any other I/O or completion. Filesystems must use this when
+ submitting I/O to devices that cannot handle I/O crossing certain LBAs
+ (e.g. ZNS devices). This flag applies only to buffered I/O writeback; all
+ other functions ignore it.
+
+ * **IOMAP_F_PRIVATE**: This flag is reserved for filesystem private use.
+
+ * **IOMAP_F_ANON_WRITE**: Indicates that (write) I/O does not have a target
+ block assigned to it yet and the file system will do that in the bio
+ submission handler, splitting the I/O as needed.
+
+ * **IOMAP_F_ATOMIC_BIO**: This indicates write I/O must be submitted with the
+ ``REQ_ATOMIC`` flag set in the bio. Filesystems need to set this flag to
+ inform iomap that the write I/O operation requires torn-write protection
+ based on HW-offload mechanism. They must also ensure that mapping updates
+ upon the completion of the I/O must be performed in a single metadata
+ update.
+
+ These flags can be set by iomap itself during file operations.
+ The filesystem should supply an ``->iomap_end`` function if it needs
+ to observe these flags:
+
+ * **IOMAP_F_SIZE_CHANGED**: The file size has changed as a result of
+ using this mapping.
+
+ * **IOMAP_F_STALE**: The mapping was found to be stale.
+ iomap will call ``->iomap_end`` on this mapping and then
+ ``->iomap_begin`` to obtain a new mapping.
+
+ Currently, these flags are only set by pagecache operations.
+
+ * ``addr`` describes the device address, in bytes.
+
+ * ``bdev`` describes the block device for this mapping.
+ This only needs to be set for mapped or unwritten operations.
+
+ * ``dax_dev`` describes the DAX device for this mapping.
+ This only needs to be set for mapped or unwritten operations, and
+ only for a fsdax operation.
+
+ * ``inline_data`` points to a memory buffer for I/O involving
+ ``IOMAP_INLINE`` mappings.
+ This value is ignored for all other mapping types.
+
+ * ``private`` is a pointer to `filesystem-private information
+ <https://lore.kernel.org/all/20180619164137.13720-7-hch@lst.de/>`_.
+ This value will be passed unchanged to ``->iomap_end``.
+
+ * ``validity_cookie`` is a magic freshness value set by the filesystem
+ that should be used to detect stale mappings.
+ For pagecache operations this is critical for correct operation
+ because page faults can occur, which implies that filesystem locks
+ should not be held between ``->iomap_begin`` and ``->iomap_end``.
+ Filesystems with completely static mappings need not set this value.
+ Only pagecache operations revalidate mappings; see the section about
+ ``iomap_valid`` for details.
+
+``struct iomap_ops``
+--------------------
+
+Every iomap function requires the filesystem to pass an operations
+structure to obtain a mapping and (optionally) to release the mapping:
+
+.. code-block:: c
+
+ struct iomap_ops {
+ int (*iomap_begin)(struct inode *inode, loff_t pos, loff_t length,
+ unsigned flags, struct iomap *iomap,
+ struct iomap *srcmap);
+
+ int (*iomap_end)(struct inode *inode, loff_t pos, loff_t length,
+ ssize_t written, unsigned flags,
+ struct iomap *iomap);
+ };
+
+``->iomap_begin``
+~~~~~~~~~~~~~~~~~
+
+iomap operations call ``->iomap_begin`` to obtain one file mapping for
+the range of bytes specified by ``pos`` and ``length`` for the file
+``inode``.
+This mapping should be returned through the ``iomap`` pointer.
+The mapping must cover at least the first byte of the supplied file
+range, but it does not need to cover the entire requested range.
+
+Each iomap operation describes the requested operation through the
+``flags`` argument.
+The exact value of ``flags`` will be documented in the
+operation-specific sections below.
+These flags can, at least in principle, apply generally to iomap
+operations:
+
+ * ``IOMAP_DIRECT`` is set when the caller wishes to issue file I/O to
+ block storage.
+
+ * ``IOMAP_DAX`` is set when the caller wishes to issue file I/O to
+ memory-like storage.
+
+ * ``IOMAP_NOWAIT`` is set when the caller wishes to perform a best
+ effort attempt to avoid any operation that would result in blocking
+ the submitting task.
+ This is similar in intent to ``O_NONBLOCK`` for network APIs - it is
+ intended for asynchronous applications to keep doing other work
+ instead of waiting for the specific unavailable filesystem resource
+ to become available.
+ Filesystems implementing ``IOMAP_NOWAIT`` semantics need to use
+ trylock algorithms.
+ They need to be able to satisfy the entire I/O request range with a
+ single iomap mapping.
+ They need to avoid reading or writing metadata synchronously.
+ They need to avoid blocking memory allocations.
+ They need to avoid waiting on transaction reservations to allow
+ modifications to take place.
+ They probably should not be allocating new space.
+ And so on.
+ If there is any doubt in the filesystem developer's mind as to
+ whether any specific ``IOMAP_NOWAIT`` operation may end up blocking,
+ then they should return ``-EAGAIN`` as early as possible rather than
+ start the operation and force the submitting task to block.
+ ``IOMAP_NOWAIT`` is often set on behalf of ``IOCB_NOWAIT`` or
+ ``RWF_NOWAIT``.
+
+ * ``IOMAP_DONTCACHE`` is set when the caller wishes to perform a
+ buffered file I/O and would like the kernel to drop the pagecache
+ after the I/O completes, if it isn't already being used by another
+ thread.
+
+If it is necessary to read existing file contents from a `different
+<https://lore.kernel.org/all/20191008071527.29304-9-hch@lst.de/>`_
+device or address range on a device, the filesystem should return that
+information via ``srcmap``.
+Only pagecache and fsdax operations support reading from one mapping and
+writing to another.
+
+``->iomap_end``
+~~~~~~~~~~~~~~~
+
+After the operation completes, the ``->iomap_end`` function, if present,
+is called to signal that iomap is finished with a mapping.
+Typically, implementations will use this function to tear down any
+context that were set up in ``->iomap_begin``.
+For example, a write might wish to commit the reservations for the bytes
+that were operated upon and unreserve any space that was not operated
+upon.
+``written`` might be zero if no bytes were touched.
+``flags`` will contain the same value passed to ``->iomap_begin``.
+iomap ops for reads are not likely to need to supply this function.
+
+Both functions should return a negative errno code on error, or zero on
+success.
+
+Preparing for File Operations
+=============================
+
+iomap only handles mapping and I/O.
+Filesystems must still call out to the VFS to check input parameters
+and file state before initiating an I/O operation.
+It does not handle obtaining filesystem freeze protection, updating of
+timestamps, stripping privileges, or access control.
+
+Locking Hierarchy
+=================
+
+iomap requires that filesystems supply their own locking model.
+There are three categories of synchronization primitives, as far as
+iomap is concerned:
+
+ * The **upper** level primitive is provided by the filesystem to
+ coordinate access to different iomap operations.
+ The exact primitive is specific to the filesystem and operation,
+ but is often a VFS inode, pagecache invalidation, or folio lock.
+ For example, a filesystem might take ``i_rwsem`` before calling
+ ``iomap_file_buffered_write`` and ``iomap_file_unshare`` to prevent
+ these two file operations from clobbering each other.
+ Pagecache writeback may lock a folio to prevent other threads from
+ accessing the folio until writeback is underway.
+
+ * The **lower** level primitive is taken by the filesystem in the
+ ``->iomap_begin`` and ``->iomap_end`` functions to coordinate
+ access to the file space mapping information.
+ The fields of the iomap object should be filled out while holding
+ this primitive.
+ The upper level synchronization primitive, if any, remains held
+ while acquiring the lower level synchronization primitive.
+ For example, XFS takes ``ILOCK_EXCL`` and ext4 takes ``i_data_sem``
+ while sampling mappings.
+ Filesystems with immutable mapping information may not require
+ synchronization here.
+
+ * The **operation** primitive is taken by an iomap operation to
+ coordinate access to its own internal data structures.
+ The upper level synchronization primitive, if any, remains held
+ while acquiring this primitive.
+ The lower level primitive is not held while acquiring this
+ primitive.
+ For example, pagecache write operations will obtain a file mapping,
+ then grab and lock a folio to copy new contents.
+ It may also lock an internal folio state object to update metadata.
+
+The exact locking requirements are specific to the filesystem; for
+certain operations, some of these locks can be elided.
+All further mentions of locking are *recommendations*, not mandates.
+Each filesystem author must figure out the locking for themself.
+
+Bugs and Limitations
+====================
+
+ * No support for fscrypt.
+ * No support for compression.
+ * No support for fsverity yet.
+ * Strong assumptions that IO should work the way it does on XFS.
+ * Does iomap *actually* work for non-regular file data?
+
+Patches welcome!
diff --git a/Documentation/filesystems/iomap/index.rst b/Documentation/filesystems/iomap/index.rst
new file mode 100644
index 000000000000..3c6a52440250
--- /dev/null
+++ b/Documentation/filesystems/iomap/index.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+VFS iomap Documentation
+=======================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ design
+ operations
+ porting
diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst
new file mode 100644
index 000000000000..da982ca7e413
--- /dev/null
+++ b/Documentation/filesystems/iomap/operations.rst
@@ -0,0 +1,785 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _iomap_operations:
+
+..
+ Dumb style notes to maintain the author's sanity:
+ Please try to start sentences on separate lines so that
+ sentence changes don't bleed colors in diff.
+ Heading decorations are documented in sphinx.rst.
+
+=========================
+Supported File Operations
+=========================
+
+.. contents:: Table of Contents
+ :local:
+
+Below are a discussion of the high level file operations that iomap
+implements.
+
+Buffered I/O
+============
+
+Buffered I/O is the default file I/O path in Linux.
+File contents are cached in memory ("pagecache") to satisfy reads and
+writes.
+Dirty cache will be written back to disk at some point that can be
+forced via ``fsync`` and variants.
+
+iomap implements nearly all the folio and pagecache management that
+filesystems have to implement themselves under the legacy I/O model.
+This means that the filesystem need not know the details of allocating,
+mapping, managing uptodate and dirty state, or writeback of pagecache
+folios.
+Under the legacy I/O model, this was managed very inefficiently with
+linked lists of buffer heads instead of the per-folio bitmaps that iomap
+uses.
+Unless the filesystem explicitly opts in to buffer heads, they will not
+be used, which makes buffered I/O much more efficient, and the pagecache
+maintainer much happier.
+
+``struct address_space_operations``
+-----------------------------------
+
+The following iomap functions can be referenced directly from the
+address space operations structure:
+
+ * ``iomap_dirty_folio``
+ * ``iomap_release_folio``
+ * ``iomap_invalidate_folio``
+ * ``iomap_is_partially_uptodate``
+
+The following address space operations can be wrapped easily:
+
+ * ``read_folio``
+ * ``readahead``
+ * ``writepages``
+ * ``bmap``
+ * ``swap_activate``
+
+``struct iomap_write_ops``
+--------------------------
+
+.. code-block:: c
+
+ struct iomap_write_ops {
+ struct folio *(*get_folio)(struct iomap_iter *iter, loff_t pos,
+ unsigned len);
+ void (*put_folio)(struct inode *inode, loff_t pos, unsigned copied,
+ struct folio *folio);
+ bool (*iomap_valid)(struct inode *inode, const struct iomap *iomap);
+ int (*read_folio_range)(const struct iomap_iter *iter,
+ struct folio *folio, loff_t pos, size_t len);
+ };
+
+iomap calls these functions:
+
+ - ``get_folio``: Called to allocate and return an active reference to
+ a locked folio prior to starting a write.
+ If this function is not provided, iomap will call
+ ``iomap_get_folio``.
+ This could be used to `set up per-folio filesystem state
+ <https://lore.kernel.org/all/20190429220934.10415-5-agruenba@redhat.com/>`_
+ for a write.
+
+ - ``put_folio``: Called to unlock and put a folio after a pagecache
+ operation completes.
+ If this function is not provided, iomap will ``folio_unlock`` and
+ ``folio_put`` on its own.
+ This could be used to `commit per-folio filesystem state
+ <https://lore.kernel.org/all/20180619164137.13720-6-hch@lst.de/>`_
+ that was set up by ``->get_folio``.
+
+ - ``iomap_valid``: The filesystem may not hold locks between
+ ``->iomap_begin`` and ``->iomap_end`` because pagecache operations
+ can take folio locks, fault on userspace pages, initiate writeback
+ for memory reclamation, or engage in other time-consuming actions.
+ If a file's space mapping data are mutable, it is possible that the
+ mapping for a particular pagecache folio can `change in the time it
+ takes
+ <https://lore.kernel.org/all/20221123055812.747923-8-david@fromorbit.com/>`_
+ to allocate, install, and lock that folio.
+
+ For the pagecache, races can happen if writeback doesn't take
+ ``i_rwsem`` or ``invalidate_lock`` and updates mapping information.
+ Races can also happen if the filesystem allows concurrent writes.
+ For such files, the mapping *must* be revalidated after the folio
+ lock has been taken so that iomap can manage the folio correctly.
+
+ fsdax does not need this revalidation because there's no writeback
+ and no support for unwritten extents.
+
+ Filesystems subject to this kind of race must provide a
+ ``->iomap_valid`` function to decide if the mapping is still valid.
+ If the mapping is not valid, the mapping will be sampled again.
+
+ To support making the validity decision, the filesystem's
+ ``->iomap_begin`` function may set ``struct iomap::validity_cookie``
+ at the same time that it populates the other iomap fields.
+ A simple validation cookie implementation is a sequence counter.
+ If the filesystem bumps the sequence counter every time it modifies
+ the inode's extent map, it can be placed in the ``struct
+ iomap::validity_cookie`` during ``->iomap_begin``.
+ If the value in the cookie is found to be different to the value
+ the filesystem holds when the mapping is passed back to
+ ``->iomap_valid``, then the iomap should considered stale and the
+ validation failed.
+
+ - ``read_folio_range``: Called to synchronously read in the range that will
+ be written to. If this function is not provided, iomap will default to
+ submitting a bio read request.
+
+These ``struct kiocb`` flags are significant for buffered I/O with iomap:
+
+ * ``IOCB_NOWAIT``: Turns on ``IOMAP_NOWAIT``.
+
+ * ``IOCB_DONTCACHE``: Turns on ``IOMAP_DONTCACHE``.
+
+``struct iomap_read_ops``
+--------------------------
+
+.. code-block:: c
+
+ struct iomap_read_ops {
+ int (*read_folio_range)(const struct iomap_iter *iter,
+ struct iomap_read_folio_ctx *ctx, size_t len);
+ void (*submit_read)(struct iomap_read_folio_ctx *ctx);
+ };
+
+iomap calls these functions:
+
+ - ``read_folio_range``: Called to read in the range. This must be provided
+ by the caller. If this succeeds, iomap_finish_folio_read() must be called
+ after the range is read in, regardless of whether the read succeeded or
+ failed.
+
+ - ``submit_read``: Submit any pending read requests. This function is
+ optional.
+
+Internal per-Folio State
+------------------------
+
+If the fsblock size matches the size of a pagecache folio, it is assumed
+that all disk I/O operations will operate on the entire folio.
+The uptodate (memory contents are at least as new as what's on disk) and
+dirty (memory contents are newer than what's on disk) status of the
+folio are all that's needed for this case.
+
+If the fsblock size is less than the size of a pagecache folio, iomap
+tracks the per-fsblock uptodate and dirty state itself.
+This enables iomap to handle both "bs < ps" `filesystems
+<https://lore.kernel.org/all/20230725122932.144426-1-ritesh.list@gmail.com/>`_
+and large folios in the pagecache.
+
+iomap internally tracks two state bits per fsblock:
+
+ * ``uptodate``: iomap will try to keep folios fully up to date.
+ If there are read(ahead) errors, those fsblocks will not be marked
+ uptodate.
+ The folio itself will be marked uptodate when all fsblocks within the
+ folio are uptodate.
+
+ * ``dirty``: iomap will set the per-block dirty state when programs
+ write to the file.
+ The folio itself will be marked dirty when any fsblock within the
+ folio is dirty.
+
+iomap also tracks the amount of read and write disk IOs that are in
+flight.
+This structure is much lighter weight than ``struct buffer_head``
+because there is only one per folio, and the per-fsblock overhead is two
+bits vs. 104 bytes.
+
+Filesystems wishing to turn on large folios in the pagecache should call
+``mapping_set_large_folios`` when initializing the incore inode.
+
+Buffered Readahead and Reads
+----------------------------
+
+The ``iomap_readahead`` function initiates readahead to the pagecache.
+The ``iomap_read_folio`` function reads one folio's worth of data into
+the pagecache.
+The ``flags`` argument to ``->iomap_begin`` will be set to zero.
+The pagecache takes whatever locks it needs before calling the
+filesystem.
+
+Both ``iomap_readahead`` and ``iomap_read_folio`` pass in a ``struct
+iomap_read_folio_ctx``:
+
+.. code-block:: c
+
+ struct iomap_read_folio_ctx {
+ const struct iomap_read_ops *ops;
+ struct folio *cur_folio;
+ struct readahead_control *rac;
+ void *read_ctx;
+ };
+
+``iomap_readahead`` must set:
+ * ``ops->read_folio_range()`` and ``rac``
+
+``iomap_read_folio`` must set:
+ * ``ops->read_folio_range()`` and ``cur_folio``
+
+``ops->submit_read()`` and ``read_ctx`` are optional. ``read_ctx`` is used to
+pass in any custom data the caller needs accessible in the ops callbacks for
+fulfilling reads.
+
+Buffered Writes
+---------------
+
+The ``iomap_file_buffered_write`` function writes an ``iocb`` to the
+pagecache.
+``IOMAP_WRITE`` or ``IOMAP_WRITE`` | ``IOMAP_NOWAIT`` will be passed as
+the ``flags`` argument to ``->iomap_begin``.
+Callers commonly take ``i_rwsem`` in either shared or exclusive mode
+before calling this function.
+
+mmap Write Faults
+~~~~~~~~~~~~~~~~~
+
+The ``iomap_page_mkwrite`` function handles a write fault to a folio in
+the pagecache.
+``IOMAP_WRITE | IOMAP_FAULT`` will be passed as the ``flags`` argument
+to ``->iomap_begin``.
+Callers commonly take the mmap ``invalidate_lock`` in shared or
+exclusive mode before calling this function.
+
+Buffered Write Failures
+~~~~~~~~~~~~~~~~~~~~~~~
+
+After a short write to the pagecache, the areas not written will not
+become marked dirty.
+The filesystem must arrange to `cancel
+<https://lore.kernel.org/all/20221123055812.747923-6-david@fromorbit.com/>`_
+such `reservations
+<https://lore.kernel.org/linux-xfs/20220817093627.GZ3600936@dread.disaster.area/>`_
+because writeback will not consume the reservation.
+The ``iomap_write_delalloc_release`` can be called from a
+``->iomap_end`` function to find all the clean areas of the folios
+caching a fresh (``IOMAP_F_NEW``) delalloc mapping.
+It takes the ``invalidate_lock``.
+
+The filesystem must supply a function ``punch`` to be called for
+each file range in this state.
+This function must *only* remove delayed allocation reservations, in
+case another thread racing with the current thread writes successfully
+to the same region and triggers writeback to flush the dirty data out to
+disk.
+
+Zeroing for File Operations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Filesystems can call ``iomap_zero_range`` to perform zeroing of the
+pagecache for non-truncation file operations that are not aligned to
+the fsblock size.
+``IOMAP_ZERO`` will be passed as the ``flags`` argument to
+``->iomap_begin``.
+Callers typically hold ``i_rwsem`` and ``invalidate_lock`` in exclusive
+mode before calling this function.
+
+Unsharing Reflinked File Data
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Filesystems can call ``iomap_file_unshare`` to force a file sharing
+storage with another file to preemptively copy the shared data to newly
+allocate storage.
+``IOMAP_WRITE | IOMAP_UNSHARE`` will be passed as the ``flags`` argument
+to ``->iomap_begin``.
+Callers typically hold ``i_rwsem`` and ``invalidate_lock`` in exclusive
+mode before calling this function.
+
+Truncation
+----------
+
+Filesystems can call ``iomap_truncate_page`` to zero the bytes in the
+pagecache from EOF to the end of the fsblock during a file truncation
+operation.
+``truncate_setsize`` or ``truncate_pagecache`` will take care of
+everything after the EOF block.
+``IOMAP_ZERO`` will be passed as the ``flags`` argument to
+``->iomap_begin``.
+Callers typically hold ``i_rwsem`` and ``invalidate_lock`` in exclusive
+mode before calling this function.
+
+Pagecache Writeback
+-------------------
+
+Filesystems can call ``iomap_writepages`` to respond to a request to
+write dirty pagecache folios to disk.
+The ``mapping`` and ``wbc`` parameters should be passed unchanged.
+The ``wpc`` pointer should be allocated by the filesystem and must
+be initialized to zero.
+
+The pagecache will lock each folio before trying to schedule it for
+writeback.
+It does not lock ``i_rwsem`` or ``invalidate_lock``.
+
+The dirty bit will be cleared for all folios run through the
+``->writeback_range`` machinery described below even if the writeback fails.
+This is to prevent dirty folio clots when storage devices fail; an
+``-EIO`` is recorded for userspace to collect via ``fsync``.
+
+The ``ops`` structure must be specified and is as follows:
+
+``struct iomap_writeback_ops``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: c
+
+ struct iomap_writeback_ops {
+ int (*writeback_range)(struct iomap_writepage_ctx *wpc,
+ struct folio *folio, u64 pos, unsigned int len, u64 end_pos);
+ int (*writeback_submit)(struct iomap_writepage_ctx *wpc, int error);
+ };
+
+The fields are as follows:
+
+ - ``writeback_range``: Sets ``wpc->iomap`` to the space mapping of the file
+ range (in bytes) given by ``offset`` and ``len``.
+ iomap calls this function for each dirty fs block in each dirty folio,
+ though it will `reuse mappings
+ <https://lore.kernel.org/all/20231207072710.176093-15-hch@lst.de/>`_
+ for runs of contiguous dirty fsblocks within a folio.
+ Do not return ``IOMAP_INLINE`` mappings here; the ``->iomap_end``
+ function must deal with persisting written data.
+ Do not return ``IOMAP_DELALLOC`` mappings here; iomap currently
+ requires mapping to allocated space.
+ Filesystems can skip a potentially expensive mapping lookup if the
+ mappings have not changed.
+ This revalidation must be open-coded by the filesystem; it is
+ unclear if ``iomap::validity_cookie`` can be reused for this
+ purpose.
+
+ If this methods fails to schedule I/O for any part of a dirty folio, it
+ should throw away any reservations that may have been made for the write.
+ The folio will be marked clean and an ``-EIO`` recorded in the
+ pagecache.
+ Filesystems can use this callback to `remove
+ <https://lore.kernel.org/all/20201029163313.1766967-1-bfoster@redhat.com/>`_
+ delalloc reservations to avoid having delalloc reservations for
+ clean pagecache.
+ This function must be supplied by the filesystem.
+ If this succeeds, iomap_finish_folio_write() must be called once writeback
+ completes for the range, regardless of whether the writeback succeeded or
+ failed.
+
+ - ``writeback_submit``: Submit the previous built writeback context.
+ Block based file systems should use the iomap_ioend_writeback_submit
+ helper, other file system can implement their own.
+ File systems can optionally hook into writeback bio submission.
+ This might include pre-write space accounting updates, or installing
+ a custom ``->bi_end_io`` function for internal purposes, such as
+ deferring the ioend completion to a workqueue to run metadata update
+ transactions from process context before submitting the bio.
+ This function must be supplied by the filesystem.
+
+Pagecache Writeback Completion
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To handle the bookkeeping that must happen after disk I/O for writeback
+completes, iomap creates chains of ``struct iomap_ioend`` objects that
+wrap the ``bio`` that is used to write pagecache data to disk.
+By default, iomap finishes writeback ioends by clearing the writeback
+bit on the folios attached to the ``ioend``.
+If the write failed, it will also set the error bits on the folios and
+the address space.
+This can happen in interrupt or process context, depending on the
+storage device.
+Filesystems that need to update internal bookkeeping (e.g. unwritten
+extent conversions) should set their own bi_end_io on the bios
+submitted by ``->submit_writeback``
+This function should call ``iomap_finish_ioends`` after finishing its
+own work (e.g. unwritten extent conversion).
+
+Some filesystems may wish to `amortize the cost of running metadata
+transactions
+<https://lore.kernel.org/all/20220120034733.221737-1-david@fromorbit.com/>`_
+for post-writeback updates by batching them.
+They may also require transactions to run from process context, which
+implies punting batches to a workqueue.
+iomap ioends contain a ``list_head`` to enable batching.
+
+Given a batch of ioends, iomap has a few helpers to assist with
+amortization:
+
+ * ``iomap_sort_ioends``: Sort all the ioends in the list by file
+ offset.
+
+ * ``iomap_ioend_try_merge``: Given an ioend that is not in any list and
+ a separate list of sorted ioends, merge as many of the ioends from
+ the head of the list into the given ioend.
+ ioends can only be merged if the file range and storage addresses are
+ contiguous; the unwritten and shared status are the same; and the
+ write I/O outcome is the same.
+ The merged ioends become their own list.
+
+ * ``iomap_finish_ioends``: Finish an ioend that possibly has other
+ ioends linked to it.
+
+Direct I/O
+==========
+
+In Linux, direct I/O is defined as file I/O that is issued directly to
+storage, bypassing the pagecache.
+The ``iomap_dio_rw`` function implements O_DIRECT (direct I/O) reads and
+writes for files.
+
+.. code-block:: c
+
+ ssize_t iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
+ const struct iomap_ops *ops,
+ const struct iomap_dio_ops *dops,
+ unsigned int dio_flags, void *private,
+ size_t done_before);
+
+The filesystem can provide the ``dops`` parameter if it needs to perform
+extra work before or after the I/O is issued to storage.
+The ``done_before`` parameter tells the how much of the request has
+already been transferred.
+It is used to continue a request asynchronously when `part of the
+request
+<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c03098d4b9ad76bca2966a8769dcfe59f7f85103>`_
+has already been completed synchronously.
+
+The ``done_before`` parameter should be set if writes for the ``iocb``
+have been initiated prior to the call.
+The direction of the I/O is determined from the ``iocb`` passed in.
+
+The ``dio_flags`` argument can be set to any combination of the
+following values:
+
+ * ``IOMAP_DIO_FORCE_WAIT``: Wait for the I/O to complete even if the
+ kiocb is not synchronous.
+
+ * ``IOMAP_DIO_OVERWRITE_ONLY``: Perform a pure overwrite for this range
+ or fail with ``-EAGAIN``.
+ This can be used by filesystems with complex unaligned I/O
+ write paths to provide an optimised fast path for unaligned writes.
+ If a pure overwrite can be performed, then serialisation against
+ other I/Os to the same filesystem block(s) is unnecessary as there is
+ no risk of stale data exposure or data loss.
+ If a pure overwrite cannot be performed, then the filesystem can
+ perform the serialisation steps needed to provide exclusive access
+ to the unaligned I/O range so that it can perform allocation and
+ sub-block zeroing safely.
+ Filesystems can use this flag to try to reduce locking contention,
+ but a lot of `detailed checking
+ <https://lore.kernel.org/linux-ext4/20230314130759.642710-1-bfoster@redhat.com/>`_
+ is required to do it `correctly
+ <https://lore.kernel.org/linux-ext4/20230810165559.946222-1-bfoster@redhat.com/>`_.
+
+ * ``IOMAP_DIO_PARTIAL``: If a page fault occurs, return whatever
+ progress has already been made.
+ The caller may deal with the page fault and retry the operation.
+ If the caller decides to retry the operation, it should pass the
+ accumulated return values of all previous calls as the
+ ``done_before`` parameter to the next call.
+
+These ``struct kiocb`` flags are significant for direct I/O with iomap:
+
+ * ``IOCB_NOWAIT``: Turns on ``IOMAP_NOWAIT``.
+
+ * ``IOCB_SYNC``: Ensure that the device has persisted data to disk
+ before completing the call.
+ In the case of pure overwrites, the I/O may be issued with FUA
+ enabled.
+
+ * ``IOCB_HIPRI``: Poll for I/O completion instead of waiting for an
+ interrupt.
+ Only meaningful for asynchronous I/O, and only if the entire I/O can
+ be issued as a single ``struct bio``.
+
+Filesystems should call ``iomap_dio_rw`` from ``->read_iter`` and
+``->write_iter``, and set ``FMODE_CAN_ODIRECT`` in the ``->open``
+function for the file.
+They should not set ``->direct_IO``, which is deprecated.
+
+If a filesystem wishes to perform its own work before direct I/O
+completion, it should call ``__iomap_dio_rw``.
+If its return value is not an error pointer or a NULL pointer, the
+filesystem should pass the return value to ``iomap_dio_complete`` after
+finishing its internal work.
+
+Return Values
+-------------
+
+``iomap_dio_rw`` can return one of the following:
+
+ * A non-negative number of bytes transferred.
+
+ * ``-ENOTBLK``: Fall back to buffered I/O.
+ iomap itself will return this value if it cannot invalidate the page
+ cache before issuing the I/O to storage.
+ The ``->iomap_begin`` or ``->iomap_end`` functions may also return
+ this value.
+
+ * ``-EIOCBQUEUED``: The asynchronous direct I/O request has been
+ queued and will be completed separately.
+
+ * Any of the other negative error codes.
+
+Direct Reads
+------------
+
+A direct I/O read initiates a read I/O from the storage device to the
+caller's buffer.
+Dirty parts of the pagecache are flushed to storage before initiating
+the read io.
+The ``flags`` value for ``->iomap_begin`` will be ``IOMAP_DIRECT`` with
+any combination of the following enhancements:
+
+ * ``IOMAP_NOWAIT``, as defined previously.
+
+Callers commonly hold ``i_rwsem`` in shared mode before calling this
+function.
+
+Direct Writes
+-------------
+
+A direct I/O write initiates a write I/O to the storage device from the
+caller's buffer.
+Dirty parts of the pagecache are flushed to storage before initiating
+the write io.
+The pagecache is invalidated both before and after the write io.
+The ``flags`` value for ``->iomap_begin`` will be ``IOMAP_DIRECT |
+IOMAP_WRITE`` with any combination of the following enhancements:
+
+ * ``IOMAP_NOWAIT``, as defined previously.
+
+ * ``IOMAP_OVERWRITE_ONLY``: Allocating blocks and zeroing partial
+ blocks is not allowed.
+ The entire file range must map to a single written or unwritten
+ extent.
+ The file I/O range must be aligned to the filesystem block size
+ if the mapping is unwritten and the filesystem cannot handle zeroing
+ the unaligned regions without exposing stale contents.
+
+ * ``IOMAP_ATOMIC``: This write is being issued with torn-write
+ protection.
+ Torn-write protection may be provided based on HW-offload or by a
+ software mechanism provided by the filesystem.
+
+ For HW-offload based support, only a single bio can be created for the
+ write, and the write must not be split into multiple I/O requests, i.e.
+ flag REQ_ATOMIC must be set.
+ The file range to write must be aligned to satisfy the requirements
+ of both the filesystem and the underlying block device's atomic
+ commit capabilities.
+ If filesystem metadata updates are required (e.g. unwritten extent
+ conversion or copy-on-write), all updates for the entire file range
+ must be committed atomically as well.
+ Untorn-writes may be longer than a single file block. In all cases,
+ the mapping start disk block must have at least the same alignment as
+ the write offset.
+ The filesystems must set IOMAP_F_ATOMIC_BIO to inform iomap core of an
+ untorn-write based on HW-offload.
+
+ For untorn-writes based on a software mechanism provided by the
+ filesystem, all the disk block alignment and single bio restrictions
+ which apply for HW-offload based untorn-writes do not apply.
+ The mechanism would typically be used as a fallback for when
+ HW-offload based untorn-writes may not be issued, e.g. the range of the
+ write covers multiple extents, meaning that it is not possible to issue
+ a single bio.
+ All filesystem metadata updates for the entire file range must be
+ committed atomically as well.
+
+Callers commonly hold ``i_rwsem`` in shared or exclusive mode before
+calling this function.
+
+``struct iomap_dio_ops:``
+-------------------------
+.. code-block:: c
+
+ struct iomap_dio_ops {
+ void (*submit_io)(const struct iomap_iter *iter, struct bio *bio,
+ loff_t file_offset);
+ int (*end_io)(struct kiocb *iocb, ssize_t size, int error,
+ unsigned flags);
+ struct bio_set *bio_set;
+ };
+
+The fields of this structure are as follows:
+
+ - ``submit_io``: iomap calls this function when it has constructed a
+ ``struct bio`` object for the I/O requested, and wishes to submit it
+ to the block device.
+ If no function is provided, ``submit_bio`` will be called directly.
+ Filesystems that would like to perform additional work before (e.g.
+ data replication for btrfs) should implement this function.
+
+ - ``end_io``: This is called after the ``struct bio`` completes.
+ This function should perform post-write conversions of unwritten
+ extent mappings, handle write failures, etc.
+ The ``flags`` argument may be set to a combination of the following:
+
+ * ``IOMAP_DIO_UNWRITTEN``: The mapping was unwritten, so the ioend
+ should mark the extent as written.
+
+ * ``IOMAP_DIO_COW``: Writing to the space in the mapping required a
+ copy on write operation, so the ioend should switch mappings.
+
+ - ``bio_set``: This allows the filesystem to provide a custom bio_set
+ for allocating direct I/O bios.
+ This enables filesystems to `stash additional per-bio information
+ <https://lore.kernel.org/all/20220505201115.937837-3-hch@lst.de/>`_
+ for private use.
+ If this field is NULL, generic ``struct bio`` objects will be used.
+
+Filesystems that want to perform extra work after an I/O completion
+should set a custom ``->bi_end_io`` function via ``->submit_io``.
+Afterwards, the custom endio function must call
+``iomap_dio_bio_end_io`` to finish the direct I/O.
+
+DAX I/O
+=======
+
+Some storage devices can be directly mapped as memory.
+These devices support a new access mode known as "fsdax" that allows
+loads and stores through the CPU and memory controller.
+
+fsdax Reads
+-----------
+
+A fsdax read performs a memcpy from storage device to the caller's
+buffer.
+The ``flags`` value for ``->iomap_begin`` will be ``IOMAP_DAX`` with any
+combination of the following enhancements:
+
+ * ``IOMAP_NOWAIT``, as defined previously.
+
+Callers commonly hold ``i_rwsem`` in shared mode before calling this
+function.
+
+fsdax Writes
+------------
+
+A fsdax write initiates a memcpy to the storage device from the caller's
+buffer.
+The ``flags`` value for ``->iomap_begin`` will be ``IOMAP_DAX |
+IOMAP_WRITE`` with any combination of the following enhancements:
+
+ * ``IOMAP_NOWAIT``, as defined previously.
+
+ * ``IOMAP_OVERWRITE_ONLY``: The caller requires a pure overwrite to be
+ performed from this mapping.
+ This requires the filesystem extent mapping to already exist as an
+ ``IOMAP_MAPPED`` type and span the entire range of the write I/O
+ request.
+ If the filesystem cannot map this request in a way that allows the
+ iomap infrastructure to perform a pure overwrite, it must fail the
+ mapping operation with ``-EAGAIN``.
+
+Callers commonly hold ``i_rwsem`` in exclusive mode before calling this
+function.
+
+fsdax mmap Faults
+~~~~~~~~~~~~~~~~~
+
+The ``dax_iomap_fault`` function handles read and write faults to fsdax
+storage.
+For a read fault, ``IOMAP_DAX | IOMAP_FAULT`` will be passed as the
+``flags`` argument to ``->iomap_begin``.
+For a write fault, ``IOMAP_DAX | IOMAP_FAULT | IOMAP_WRITE`` will be
+passed as the ``flags`` argument to ``->iomap_begin``.
+
+Callers commonly hold the same locks as they do to call their iomap
+pagecache counterparts.
+
+fsdax Truncation, fallocate, and Unsharing
+------------------------------------------
+
+For fsdax files, the following functions are provided to replace their
+iomap pagecache I/O counterparts.
+The ``flags`` argument to ``->iomap_begin`` are the same as the
+pagecache counterparts, with ``IOMAP_DAX`` added.
+
+ * ``dax_file_unshare``
+ * ``dax_zero_range``
+ * ``dax_truncate_page``
+
+Callers commonly hold the same locks as they do to call their iomap
+pagecache counterparts.
+
+fsdax Deduplication
+-------------------
+
+Filesystems implementing the ``FIDEDUPERANGE`` ioctl must call the
+``dax_remap_file_range_prep`` function with their own iomap read ops.
+
+Seeking Files
+=============
+
+iomap implements the two iterating whence modes of the ``llseek`` system
+call.
+
+SEEK_DATA
+---------
+
+The ``iomap_seek_data`` function implements the SEEK_DATA "whence" value
+for llseek.
+``IOMAP_REPORT`` will be passed as the ``flags`` argument to
+``->iomap_begin``.
+
+For unwritten mappings, the pagecache will be searched.
+Regions of the pagecache with a folio mapped and uptodate fsblocks
+within those folios will be reported as data areas.
+
+Callers commonly hold ``i_rwsem`` in shared mode before calling this
+function.
+
+SEEK_HOLE
+---------
+
+The ``iomap_seek_hole`` function implements the SEEK_HOLE "whence" value
+for llseek.
+``IOMAP_REPORT`` will be passed as the ``flags`` argument to
+``->iomap_begin``.
+
+For unwritten mappings, the pagecache will be searched.
+Regions of the pagecache with no folio mapped, or a !uptodate fsblock
+within a folio will be reported as sparse hole areas.
+
+Callers commonly hold ``i_rwsem`` in shared mode before calling this
+function.
+
+Swap File Activation
+====================
+
+The ``iomap_swapfile_activate`` function finds all the base-page aligned
+regions in a file and sets them up as swap space.
+The file will be ``fsync()``'d before activation.
+``IOMAP_REPORT`` will be passed as the ``flags`` argument to
+``->iomap_begin``.
+All mappings must be mapped or unwritten; cannot be dirty or shared, and
+cannot span multiple block devices.
+Callers must hold ``i_rwsem`` in exclusive mode; this is already
+provided by ``swapon``.
+
+File Space Mapping Reporting
+============================
+
+iomap implements two of the file space mapping system calls.
+
+FS_IOC_FIEMAP
+-------------
+
+The ``iomap_fiemap`` function exports file extent mappings to userspace
+in the format specified by the ``FS_IOC_FIEMAP`` ioctl.
+``IOMAP_REPORT`` will be passed as the ``flags`` argument to
+``->iomap_begin``.
+Callers commonly hold ``i_rwsem`` in shared mode before calling this
+function.
+
+FIBMAP (deprecated)
+-------------------
+
+``iomap_bmap`` implements FIBMAP.
+The calling conventions are the same as for FIEMAP.
+This function is only provided to maintain compatibility for filesystems
+that implemented FIBMAP prior to conversion.
+This ioctl is deprecated; do **not** add a FIBMAP implementation to
+filesystems that do not have it.
+Callers should probably hold ``i_rwsem`` in shared mode before calling
+this function, but this is unclear.
diff --git a/Documentation/filesystems/iomap/porting.rst b/Documentation/filesystems/iomap/porting.rst
new file mode 100644
index 000000000000..3d49a32c0fff
--- /dev/null
+++ b/Documentation/filesystems/iomap/porting.rst
@@ -0,0 +1,120 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _iomap_porting:
+
+..
+ Dumb style notes to maintain the author's sanity:
+ Please try to start sentences on separate lines so that
+ sentence changes don't bleed colors in diff.
+ Heading decorations are documented in sphinx.rst.
+
+=======================
+Porting Your Filesystem
+=======================
+
+.. contents:: Table of Contents
+ :local:
+
+Why Convert?
+============
+
+There are several reasons to convert a filesystem to iomap:
+
+ 1. The classic Linux I/O path is not terribly efficient.
+ Pagecache operations lock a single base page at a time and then call
+ into the filesystem to return a mapping for only that page.
+ Direct I/O operations build I/O requests a single file block at a
+ time.
+ This worked well enough for direct/indirect-mapped filesystems such
+ as ext2, but is very inefficient for extent-based filesystems such
+ as XFS.
+
+ 2. Large folios are only supported via iomap; there are no plans to
+ convert the old buffer_head path to use them.
+
+ 3. Direct access to storage on memory-like devices (fsdax) is only
+ supported via iomap.
+
+ 4. Lower maintenance overhead for individual filesystem maintainers.
+ iomap handles common pagecache related operations itself, such as
+ allocating, instantiating, locking, and unlocking of folios.
+ No ->write_begin(), ->write_end() or direct_IO
+ address_space_operations are required to be implemented by
+ filesystem using iomap.
+
+How Do I Convert a Filesystem?
+==============================
+
+First, add ``#include <linux/iomap.h>`` from your source code and add
+``select FS_IOMAP`` to your filesystem's Kconfig option.
+Build the kernel, run fstests with the ``-g all`` option across a wide
+variety of your filesystem's supported configurations to build a
+baseline of which tests pass and which ones fail.
+
+The recommended approach is first to implement ``->iomap_begin`` (and
+``->iomap_end`` if necessary) to allow iomap to obtain a read-only
+mapping of a file range.
+In most cases, this is a relatively trivial conversion of the existing
+``get_block()`` function for read-only mappings.
+``FS_IOC_FIEMAP`` is a good first target because it is trivial to
+implement support for it and then to determine that the extent map
+iteration is correct from userspace.
+If FIEMAP is returning the correct information, it's a good sign that
+other read-only mapping operations will do the right thing.
+
+Next, modify the filesystem's ``get_block(create = false)``
+implementation to use the new ``->iomap_begin`` implementation to map
+file space for selected read operations.
+Hide behind a debugging knob the ability to switch on the iomap mapping
+functions for selected call paths.
+It is necessary to write some code to fill out the bufferhead-based
+mapping information from the ``iomap`` structure, but the new functions
+can be tested without needing to implement any iomap APIs.
+
+Once the read-only functions are working like this, convert each high
+level file operation one by one to use iomap native APIs instead of
+going through ``get_block()``.
+Done one at a time, regressions should be self evident.
+You *do* have a regression test baseline for fstests, right?
+It is suggested to convert swap file activation, ``SEEK_DATA``, and
+``SEEK_HOLE`` before tackling the I/O paths.
+A likely complexity at this point will be converting the buffered read
+I/O path because of bufferheads.
+The buffered read I/O paths doesn't need to be converted yet, though the
+direct I/O read path should be converted in this phase.
+
+At this point, you should look over your ``->iomap_begin`` function.
+If it switches between large blocks of code based on dispatching of the
+``flags`` argument, you should consider breaking it up into
+per-operation iomap ops with smaller, more cohesive functions.
+XFS is a good example of this.
+
+The next thing to do is implement ``get_blocks(create == true)``
+functionality in the ``->iomap_begin``/``->iomap_end`` methods.
+It is strongly recommended to create separate mapping functions and
+iomap ops for write operations.
+Then convert the direct I/O write path to iomap, and start running fsx
+w/ DIO enabled in earnest on filesystem.
+This will flush out lots of data integrity corner case bugs that the new
+write mapping implementation introduces.
+
+Now, convert any remaining file operations to call the iomap functions.
+This will get the entire filesystem using the new mapping functions, and
+they should largely be debugged and working correctly after this step.
+
+Most likely at this point, the buffered read and write paths will still
+need to be converted.
+The mapping functions should all work correctly, so all that needs to be
+done is rewriting all the code that interfaces with bufferheads to
+interface with iomap and folios.
+It is much easier first to get regular file I/O (without any fancy
+features like fscrypt, fsverity, compression, or data=journaling)
+converted to use iomap.
+Some of those fancy features (fscrypt and compression) aren't
+implemented yet in iomap.
+For unjournalled filesystems that use the pagecache for symbolic links
+and directories, you might also try converting their handling to iomap.
+
+The rest is left as an exercise for the reader, as it will be different
+for every filesystem.
+If you encounter problems, email the people and lists in
+``get_maintainers.pl`` for help.
diff --git a/Documentation/filesystems/journalling.rst b/Documentation/filesystems/journalling.rst
index e18f90ffc6fd..863e93e623f7 100644
--- a/Documentation/filesystems/journalling.rst
+++ b/Documentation/filesystems/journalling.rst
@@ -111,9 +111,7 @@ a callback function when the transaction is finally committed to disk,
so that you can do some of your own management. You ask the journalling
layer for calling the callback by simply setting
``journal->j_commit_callback`` function pointer and that function is
-called after each transaction commit. You can also use
-``transaction->t_private_list`` for attaching entries to a transaction
-that need processing when the transaction commits.
+called after each transaction commit.
JBD2 also provides a way to block all transaction updates via
jbd2_journal_lock_updates() /
@@ -137,7 +135,7 @@ Fast commits
JBD2 to also allows you to perform file-system specific delta commits known as
fast commits. In order to use fast commits, you will need to set following
-callbacks that perform correspodning work:
+callbacks that perform corresponding work:
`journal->j_fc_cleanup_cb`: Cleanup function called after every full commit and
fast commit.
@@ -149,7 +147,7 @@ File system is free to perform fast commits as and when it wants as long as it
gets permission from JBD2 to do so by calling the function
:c:func:`jbd2_fc_begin_commit()`. Once a fast commit is done, the client
file system should tell JBD2 about it by calling
-:c:func:`jbd2_fc_end_commit()`. If file system wants JBD2 to perform a full
+:c:func:`jbd2_fc_end_commit()`. If the file system wants JBD2 to perform a full
commit immediately after stopping the fast commit it can do so by calling
:c:func:`jbd2_fc_end_commit_fallback()`. This is useful if fast commit operation
fails for some reason and the only way to guarantee consistency is for JBD2 to
@@ -199,7 +197,7 @@ Journal Level
.. kernel-doc:: fs/jbd2/recovery.c
:internal:
-Transasction Level
+Transaction Level
~~~~~~~~~~~~~~~~~~
.. kernel-doc:: fs/jbd2/transaction.c
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index 4bb2627026ec..77704fde9845 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -17,7 +17,8 @@ dentry_operations
prototypes::
- int (*d_revalidate)(struct dentry *, unsigned int);
+ int (*d_revalidate)(struct inode *, const struct qstr *,
+ struct dentry *, unsigned int);
int (*d_weak_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, struct qstr *);
int (*d_compare)(const struct dentry *,
@@ -29,7 +30,9 @@ prototypes::
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
struct vfsmount *(*d_automount)(struct path *path);
int (*d_manage)(const struct path *, bool);
- struct dentry *(*d_real)(struct dentry *, const struct inode *);
+ struct dentry *(*d_real)(struct dentry *, enum d_real_type type);
+ bool (*d_unalias_trylock)(const struct dentry *);
+ void (*d_unalias_unlock)(const struct dentry *);
locking rules:
@@ -49,6 +52,8 @@ d_dname: no no no no
d_automount: no no yes no
d_manage: no no yes (ref-walk) maybe
d_real no no yes no
+d_unalias_trylock yes no no no
+d_unalias_unlock yes no no no
================== =========== ======== ============== ========
inode_operations
@@ -56,40 +61,43 @@ inode_operations
prototypes::
- int (*create) (struct inode *,struct dentry *,umode_t, bool);
+ int (*create) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t, bool);
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
- int (*symlink) (struct inode *,struct dentry *,const char *);
- int (*mkdir) (struct inode *,struct dentry *,umode_t);
+ int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *);
+ struct dentry *(*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
- int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
- int (*rename) (struct inode *, struct dentry *,
+ int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t);
+ int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *,
struct inode *, struct dentry *, unsigned int);
int (*readlink) (struct dentry *, char __user *,int);
const char *(*get_link) (struct dentry *, struct inode *, struct delayed_call *);
void (*truncate) (struct inode *);
- int (*permission) (struct inode *, int, unsigned int);
- struct posix_acl * (*get_acl)(struct inode *, int, bool);
- int (*setattr) (struct dentry *, struct iattr *);
- int (*getattr) (const struct path *, struct kstat *, u32, unsigned int);
+ int (*permission) (struct mnt_idmap *, struct inode *, int, unsigned int);
+ struct posix_acl * (*get_inode_acl)(struct inode *, int, bool);
+ int (*setattr) (struct mnt_idmap *, struct dentry *, struct iattr *);
+ int (*getattr) (struct mnt_idmap *, const struct path *, struct kstat *, u32, unsigned int);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *,
struct file *, unsigned open_flag,
umode_t create_mode);
- int (*tmpfile) (struct inode *, struct dentry *, umode_t);
- int (*fileattr_set)(struct user_namespace *mnt_userns,
- struct dentry *dentry, struct fileattr *fa);
- int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
+ int (*tmpfile) (struct mnt_idmap *, struct inode *,
+ struct file *, umode_t);
+ int (*fileattr_set)(struct mnt_idmap *idmap,
+ struct dentry *dentry, struct file_kattr *fa);
+ int (*fileattr_get)(struct dentry *dentry, struct file_kattr *fa);
+ struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
+ struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
locking rules:
all may block
-============= =============================================
+============== ==================================================
ops i_rwsem(inode)
-============= =============================================
+============== ==================================================
lookup: shared
create: exclusive
link: exclusive (both)
@@ -98,11 +106,12 @@ symlink: exclusive
mkdir: exclusive
unlink: exclusive (both)
rmdir: exclusive (both)(see below)
-rename: exclusive (all) (see below)
+rename: exclusive (both parents, some children) (see below)
readlink: no
get_link: no
setattr: exclusive
permission: no (may not block if called in rcu-walk mode)
+get_inode_acl: no
get_acl: no
getattr: no
listxattr: no
@@ -112,12 +121,16 @@ atomic_open: shared (exclusive if O_CREAT is set in open flags)
tmpfile: no
fileattr_get: no or exclusive
fileattr_set: exclusive
-============= =============================================
+get_offset_ctx no
+============== ==================================================
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_rwsem
exclusive on victim.
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
+ ->unlink() and ->rename() have ->i_rwsem exclusive on all non-directories
+ involved.
+ ->rename() has ->i_rwsem exclusive on any subdirectory that changes parent.
See Documentation/filesystems/directory-locking.rst for more detailed discussion
of the locking scheme for directory operations.
@@ -132,7 +145,7 @@ prototypes::
struct inode *inode, const char *name, void *buffer,
size_t size);
int (*set)(const struct xattr_handler *handler,
- struct user_namespace *mnt_userns,
+ struct mnt_idmap *idmap,
struct dentry *dentry, struct inode *inode, const char *name,
const void *buffer, size_t size, int flags);
@@ -236,17 +249,16 @@ address_space_operations
========================
prototypes::
- int (*writepage)(struct page *page, struct writeback_control *wbc);
int (*read_folio)(struct file *, struct folio *);
int (*writepages)(struct address_space *, struct writeback_control *);
bool (*dirty_folio)(struct address_space *, struct folio *folio);
void (*readahead)(struct readahead_control *);
- int (*write_begin)(struct file *, struct address_space *mapping,
+ int (*write_begin)(const struct kiocb *, struct address_space *mapping,
loff_t pos, unsigned len,
- struct page **pagep, void **fsdata);
- int (*write_end)(struct file *, struct address_space *mapping,
+ struct folio **foliop, void **fsdata);
+ int (*write_end)(const struct kiocb *, struct address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
- struct page *page, void *fsdata);
+ struct folio *folio, void *fsdata);
sector_t (*bmap)(struct address_space *, sector_t);
void (*invalidate_folio) (struct folio *, size_t start, size_t len);
bool (*release_folio)(struct folio *, gfp_t);
@@ -256,7 +268,7 @@ prototypes::
struct folio *src, enum migrate_mode);
int (*launder_folio)(struct folio *);
bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count);
- int (*error_remove_page)(struct address_space *, struct page *);
+ int (*error_remove_folio)(struct address_space *, struct folio *);
int (*swap_activate)(struct swap_info_struct *sis, struct file *f, sector_t *span)
int (*swap_deactivate)(struct file *);
int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter);
@@ -267,12 +279,11 @@ locking rules:
====================== ======================== ========= ===============
ops folio locked i_rwsem invalidate_lock
====================== ======================== ========= ===============
-writepage: yes, unlocks (see below)
read_folio: yes, unlocks shared
writepages:
dirty_folio: maybe
readahead: yes, unlocks shared
-write_begin: locks the page exclusive
+write_begin: locks the folio exclusive
write_end: yes, unlocks exclusive
bmap:
invalidate_folio: yes exclusive
@@ -282,7 +293,7 @@ direct_IO:
migrate_folio: yes (both)
launder_folio: yes
is_partially_uptodate: yes
-error_remove_page: yes
+error_remove_folio: yes
swap_activate: no
swap_deactivate: no
swap_rw: yes, unlocks
@@ -296,54 +307,6 @@ completion.
->readahead() unlocks the folios that I/O is attempted on like ->read_folio().
-->writepage() is used for two purposes: for "memory cleansing" and for
-"sync". These are quite different operations and the behaviour may differ
-depending upon the mode.
-
-If writepage is called for sync (wbc->sync_mode != WBC_SYNC_NONE) then
-it *must* start I/O against the page, even if that would involve
-blocking on in-progress I/O.
-
-If writepage is called for memory cleansing (sync_mode ==
-WBC_SYNC_NONE) then its role is to get as much writeout underway as
-possible. So writepage should try to avoid blocking against
-currently-in-progress I/O.
-
-If the filesystem is not called for "sync" and it determines that it
-would need to block against in-progress I/O to be able to start new I/O
-against the page the filesystem should redirty the page with
-redirty_page_for_writepage(), then unlock the page and return zero.
-This may also be done to avoid internal deadlocks, but rarely.
-
-If the filesystem is called for sync then it must wait on any
-in-progress I/O and then start new I/O.
-
-The filesystem should unlock the page synchronously, before returning to the
-caller, unless ->writepage() returns special WRITEPAGE_ACTIVATE
-value. WRITEPAGE_ACTIVATE means that page cannot really be written out
-currently, and VM should stop calling ->writepage() on this page for some
-time. VM does this by moving page to the head of the active list, hence the
-name.
-
-Unless the filesystem is going to redirty_page_for_writepage(), unlock the page
-and return zero, writepage *must* run set_page_writeback() against the page,
-followed by unlocking it. Once set_page_writeback() has been run against the
-page, write I/O can be submitted and the write I/O completion handler must run
-end_page_writeback() once the I/O is complete. If no I/O is submitted, the
-filesystem must run end_page_writeback() against the page before returning from
-writepage.
-
-That is: after 2.5.12, pages which are under writeout are *not* locked. Note,
-if the filesystem needs the page to be locked during writeout, that is ok, too,
-the page is allowed to be unlocked at any point in time between the calls to
-set_page_writeback() and end_page_writeback().
-
-Note, failure to run either redirty_page_for_writepage() or the combination of
-set_page_writeback()/end_page_writeback() on a page submitted to writepage
-will leave the page itself marked clean but it will be tagged as dirty in the
-radix tree. This incoherency can lead to all sorts of hard-to-debug problems
-in the filesystem like having dirty inodes at umount and losing written data.
-
->writepages() is used for periodic writeback and for syscall-initiated
sync operations. The address_space should start I/O against at least
``*nr_to_write`` pages. ``*nr_to_write`` must be decremented for each page
@@ -351,8 +314,8 @@ which is written. The address_space implementation may write more (or less)
pages than ``*nr_to_write`` asks for, but it should try to be reasonably close.
If nr_to_write is NULL, all dirty pages must be written.
-writepages should _only_ write pages which are present on
-mapping->io_pages.
+writepages should _only_ write pages which are present in
+mapping->i_pages.
->dirty_folio() is called from various places in the kernel when
the target folio is marked as needing writeback. The folio cannot be
@@ -371,10 +334,17 @@ invalidate_lock before invalidating page cache in truncate / hole punch
path (and thus calling into ->invalidate_folio) to block races between page
cache invalidation and page cache filling functions (fault, read, ...).
-->release_folio() is called when the kernel is about to try to drop the
-buffers from the folio in preparation for freeing it. It returns false to
-indicate that the buffers are (or may be) freeable. If ->release_folio is
-NULL, the kernel assumes that the fs has no private interest in the buffers.
+->release_folio() is called when the MM wants to make a change to the
+folio that would invalidate the filesystem's private data. For example,
+it may be about to be removed from the address_space or split. The folio
+is locked and not under writeback. It may be dirty. The gfp parameter
+is not usually used for allocation, but rather to indicate what the
+filesystem may do to attempt to free the private data. The filesystem may
+return false to indicate that the folio's private data cannot be freed.
+If it returns true, it should have already removed the private data from
+the folio. If a filesystem does not provide a ->release_folio method,
+the pagecache will assume that private data is buffer_heads and call
+try_to_free_buffers().
->free_folio() is called when the kernel has dropped the folio
from the page cache.
@@ -473,7 +443,7 @@ prototypes::
int (*direct_access) (struct block_device *, sector_t, void **,
unsigned long *);
void (*unlock_native_capacity) (struct gendisk *);
- int (*getgeo)(struct block_device *, struct hd_geometry *);
+ int (*getgeo)(struct gendisk *, struct hd_geometry *);
void (*swap_slot_free_notify) (struct block_device *, unsigned long);
locking rules:
@@ -506,7 +476,6 @@ prototypes::
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
int (*iopoll) (struct kiocb *kiocb, bool spin);
- int (*iterate) (struct file *, struct dir_context *);
int (*iterate_shared) (struct file *, struct dir_context *);
__poll_t (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
@@ -518,8 +487,6 @@ prototypes::
int (*fsync) (struct file *, loff_t start, loff_t end, int datasync);
int (*fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
- ssize_t (*sendpage) (struct file *, struct page *, int, size_t,
- loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
unsigned long, unsigned long, unsigned long);
int (*check_flags)(int);
@@ -550,9 +517,8 @@ mutex or just to use i_size_read() instead.
Note: this does not protect the file->f_pos against concurrent modifications
since this is something the userspace has to take care about.
-->iterate() is called with i_rwsem exclusive.
-
-->iterate_shared() is called with i_rwsem at least shared.
+->iterate_shared() is called with i_rwsem held for reading, and with the
+file f_pos_lock held exclusively
->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
Most instances call fasync_helper(), which does that maintenance, so it's
@@ -627,26 +593,29 @@ vm_operations_struct
prototypes::
- void (*open)(struct vm_area_struct*);
- void (*close)(struct vm_area_struct*);
- vm_fault_t (*fault)(struct vm_area_struct*, struct vm_fault *);
+ void (*open)(struct vm_area_struct *);
+ void (*close)(struct vm_area_struct *);
+ vm_fault_t (*fault)(struct vm_fault *);
+ vm_fault_t (*huge_fault)(struct vm_fault *, unsigned int order);
+ vm_fault_t (*map_pages)(struct vm_fault *, pgoff_t start, pgoff_t end);
vm_fault_t (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
vm_fault_t (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *);
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
locking rules:
-============= ========= ===========================
+============= ========== ===========================
ops mmap_lock PageLocked(page)
-============= ========= ===========================
-open: yes
-close: yes
-fault: yes can return with page locked
-map_pages: yes
-page_mkwrite: yes can return with page locked
-pfn_mkwrite: yes
-access: yes
-============= ========= ===========================
+============= ========== ===========================
+open: write
+close: read/write
+fault: read can return with page locked
+huge_fault: maybe-read
+map_pages: maybe-read
+page_mkwrite: read can return with page locked
+pfn_mkwrite: read
+access: read
+============= ========== ===========================
->fault() is called when a previously not present pte is about to be faulted
in. The filesystem must find and return the page associated with the passed in
@@ -656,11 +625,18 @@ then ensure the page is not already truncated (invalidate_lock will block
subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
locked. The VM will unlock the page.
+->huge_fault() is called when there is no PUD or PMD entry present. This
+gives the filesystem the opportunity to install a PUD or PMD sized page.
+Filesystems can also use the ->fault method to return a PMD sized page,
+so implementing this function may not be necessary. In particular,
+filesystems should not call filemap_fault() from ->huge_fault().
+The mmap_lock may not be held when this method is called.
+
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from "start_pgoff"
-till "end_pgoff". ->map_pages() is called with page table locked and must
+till "end_pgoff". ->map_pages() is called with the RCU lock held and must
not block. If it's not possible to reach a page without blocking,
-filesystem should skip it. Filesystem should use do_set_pte() to setup
+filesystem should skip it. Filesystem should use set_pte_range() to setup
page table entry. Pointer to entry associated with the page is passed in
"pte" field in vm_fault structure. Pointers to entries for other offsets
should be calculated relative to "pte".
diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst
index eb358a00be27..c99ab1f7fea4 100644
--- a/Documentation/filesystems/mount_api.rst
+++ b/Documentation/filesystems/mount_api.rst
@@ -79,7 +79,6 @@ context. This is represented by the fs_context structure::
unsigned int sb_flags;
unsigned int sb_flags_mask;
unsigned int s_iflags;
- unsigned int lsm_flags;
enum fs_context_purpose purpose:8;
...
};
@@ -507,8 +506,16 @@ returned.
* ::
+ int vfs_parse_fs_qstr(struct fs_context *fc, const char *key,
+ const struct qstr *value);
+
+ A wrapper around vfs_parse_fs_param() that copies the value string it is
+ passed.
+
+ * ::
+
int vfs_parse_fs_string(struct fs_context *fc, const char *key,
- const char *value, size_t v_size);
+ const char *value);
A wrapper around vfs_parse_fs_param() that copies the value string it is
passed.
@@ -562,17 +569,6 @@ or looking up of superblocks.
The following helpers all wrap sget_fc():
- * ::
-
- int vfs_get_super(struct fs_context *fc,
- enum vfs_get_super_keying keying,
- int (*fill_super)(struct super_block *sb,
- struct fs_context *fc))
-
- This creates/looks up a deviceless superblock. The keying indicates how
- many superblocks of this type may exist and in what manner they may be
- shared:
-
(1) vfs_get_single_super
Only one such superblock may exist in the system. Any further
@@ -657,6 +653,8 @@ The members are as follows:
fs_param_is_blockdev Blockdev path * Needs lookup
fs_param_is_path Path * Needs lookup
fs_param_is_fd File descriptor result->int_32
+ fs_param_is_uid User ID (u32) result->uid
+ fs_param_is_gid Group ID (u32) result->gid
======================= ======================= =====================
Note that if the value is of fs_param_is_bool type, fs_parse() will try
@@ -681,7 +679,6 @@ The members are as follows:
fsparam_bool() fs_param_is_bool
fsparam_u32() fs_param_is_u32
fsparam_u32oct() fs_param_is_u32_octal
- fsparam_u32hex() fs_param_is_u32_hex
fsparam_s32() fs_param_is_s32
fsparam_u64() fs_param_is_u64
fsparam_enum() fs_param_is_enum
@@ -690,6 +687,8 @@ The members are as follows:
fsparam_bdev() fs_param_is_blockdev
fsparam_path() fs_param_is_path
fsparam_fd() fs_param_is_fd
+ fsparam_uid() fs_param_is_uid
+ fsparam_gid() fs_param_is_gid
======================= ===============================================
all of which take two arguments, name string and option number - for
@@ -763,22 +762,8 @@ process the parameters it is given.
* ::
- bool validate_constant_table(const struct constant_table *tbl,
- size_t tbl_size,
- int low, int high, int special);
-
- Validate a constant table. Checks that all the elements are appropriately
- ordered, that there are no duplicates and that the values are between low
- and high inclusive, though provision is made for one allowable special
- value outside of that range. If no special value is required, special
- should just be set to lie inside the low-to-high range.
-
- If all is good, true is returned. If the table is invalid, errors are
- logged to the kernel log buffer and false is returned.
-
- * ::
-
- bool fs_validate_description(const struct fs_parameter_description *desc);
+ bool fs_validate_description(const char *name,
+ const struct fs_parameter_description *desc);
This performs some validation checks on a parameter description. It
returns true if the description is good and false if it is not. It will
@@ -796,8 +781,9 @@ process the parameters it is given.
option number (which it returns).
If successful, and if the parameter type indicates the result is a
- boolean, integer or enum type, the value is converted by this function and
- the result stored in result->{boolean,int_32,uint_32,uint_64}.
+ boolean, integer, enum, uid, or gid type, the value is converted by this
+ function and the result stored in
+ result->{boolean,int_32,uint_32,uint_64,uid,gid}.
If a match isn't initially made, the key is prefixed with "no" and no
value is present then an attempt will be made to look up the key with the
@@ -814,6 +800,7 @@ process the parameters it is given.
int fs_lookup_param(struct fs_context *fc,
struct fs_parameter *value,
bool want_bdev,
+ unsigned int flags,
struct path *_path);
This takes a parameter that carries a string or filename type and attempts
diff --git a/Documentation/filesystems/multigrain-ts.rst b/Documentation/filesystems/multigrain-ts.rst
new file mode 100644
index 000000000000..c779e47284e8
--- /dev/null
+++ b/Documentation/filesystems/multigrain-ts.rst
@@ -0,0 +1,125 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+Multigrain Timestamps
+=====================
+
+Introduction
+============
+Historically, the kernel has always used coarse time values to stamp inodes.
+This value is updated every jiffy, so any change that happens within that jiffy
+will end up with the same timestamp.
+
+When the kernel goes to stamp an inode (due to a read or write), it first gets
+the current time and then compares it to the existing timestamp(s) to see
+whether anything will change. If nothing changed, then it can avoid updating
+the inode's metadata.
+
+Coarse timestamps are therefore good from a performance standpoint, since they
+reduce the need for metadata updates, but bad from the standpoint of
+determining whether anything has changed, since a lot of things can happen in a
+jiffy.
+
+They are particularly troublesome with NFSv3, where unchanging timestamps can
+make it difficult to tell whether to invalidate caches. NFSv4 provides a
+dedicated change attribute that should always show a visible change, but not
+all filesystems implement this properly, causing the NFS server to substitute
+the ctime in many cases.
+
+Multigrain timestamps aim to remedy this by selectively using fine-grained
+timestamps when a file has had its timestamps queried recently, and the current
+coarse-grained time does not cause a change.
+
+Inode Timestamps
+================
+There are currently 3 timestamps in the inode that are updated to the current
+wallclock time on different activity:
+
+ctime:
+ The inode change time. This is stamped with the current time whenever
+ the inode's metadata is changed. Note that this value is not settable
+ from userland.
+
+mtime:
+ The inode modification time. This is stamped with the current time
+ any time a file's contents change.
+
+atime:
+ The inode access time. This is stamped whenever an inode's contents are
+ read. Widely considered to be a terrible mistake. Usually avoided with
+ options like noatime or relatime.
+
+Updating the mtime always implies a change to the ctime, but updating the
+atime due to a read request does not.
+
+Multigrain timestamps are only tracked for the ctime and the mtime. atimes are
+not affected and always use the coarse-grained value (subject to the floor).
+
+Inode Timestamp Ordering
+========================
+
+In addition to just providing info about changes to individual files, file
+timestamps also serve an important purpose in applications like "make". These
+programs measure timestamps in order to determine whether source files might be
+newer than cached objects.
+
+Userland applications like make can only determine ordering based on
+operational boundaries. For a syscall those are the syscall entry and exit
+points. For io_uring or nfsd operations, that's the request submission and
+response. In the case of concurrent operations, userland can make no
+determination about the order in which things will occur.
+
+For instance, if a single thread modifies one file, and then another file in
+sequence, the second file must show an equal or later mtime than the first. The
+same is true if two threads are issuing similar operations that do not overlap
+in time.
+
+If however, two threads have racing syscalls that overlap in time, then there
+is no such guarantee, and the second file may appear to have been modified
+before, after or at the same time as the first, regardless of which one was
+submitted first.
+
+Note that the above assumes that the system doesn't experience a backward jump
+of the realtime clock. If that occurs at an inopportune time, then timestamps
+can appear to go backward, even on a properly functioning system.
+
+Multigrain Timestamp Implementation
+===================================
+Multigrain timestamps are aimed at ensuring that changes to a single file are
+always recognizable, without violating the ordering guarantees when multiple
+different files are modified. This affects the mtime and the ctime, but the
+atime will always use coarse-grained timestamps.
+
+It uses an unused bit in the i_ctime_nsec field to indicate whether the mtime
+or ctime has been queried. If either or both have, then the kernel takes
+special care to ensure the next timestamp update will display a visible change.
+This ensures tight cache coherency for use-cases like NFS, without sacrificing
+the benefits of reduced metadata updates when files aren't being watched.
+
+The Ctime Floor Value
+=====================
+It's not sufficient to simply use fine or coarse-grained timestamps based on
+whether the mtime or ctime has been queried. A file could get a fine grained
+timestamp, and then a second file modified later could get a coarse-grained one
+that appears earlier than the first, which would break the kernel's timestamp
+ordering guarantees.
+
+To mitigate this problem, maintain a global floor value that ensures that
+this can't happen. The two files in the above example may appear to have been
+modified at the same time in such a case, but they will never show the reverse
+order. To avoid problems with realtime clock jumps, the floor is managed as a
+monotonic ktime_t, and the values are converted to realtime clock values as
+needed.
+
+Implementation Notes
+====================
+Multigrain timestamps are intended for use by local filesystems that get
+ctime values from the local clock. This is in contrast to network filesystems
+and the like that just mirror timestamp values from a server.
+
+For most filesystems, it's sufficient to just set the FS_MGTIME flag in the
+fstype->fs_flags in order to opt-in, providing the ctime is only ever set via
+inode_set_ctime_current(). If the filesystem has a ->getattr routine that
+doesn't call generic_fillattr, then it should call fill_mg_cmtime() to
+fill those values. For setattr, it should use setattr_copy() to update the
+timestamps, or otherwise mimic its behavior.
diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst
index 73a4176144b3..ddd799df6ce3 100644
--- a/Documentation/filesystems/netfs_library.rst
+++ b/Documentation/filesystems/netfs_library.rst
@@ -1,33 +1,187 @@
.. SPDX-License-Identifier: GPL-2.0
-=================================
-Network Filesystem Helper Library
-=================================
+===================================
+Network Filesystem Services Library
+===================================
.. Contents:
- Overview.
+ - Requests and streams.
+ - Subrequests.
+ - Result collection and retry.
+ - Local caching.
+ - Content encryption (fscrypt).
- Per-inode context.
- Inode context helper functions.
- - Buffered read helpers.
- - Read helper functions.
- - Read helper structures.
- - Read helper operations.
- - Read helper procedure.
- - Read helper cache API.
+ - Inode locking.
+ - Inode writeback.
+ - High-level VFS API.
+ - Unlocked read/write iter.
+ - Pre-locked read/write iter.
+ - Monolithic files API.
+ - Memory-mapped I/O API.
+ - High-level VM API.
+ - Deprecated PG_private2 API.
+ - I/O request API.
+ - Request structure.
+ - Stream structure.
+ - Subrequest structure.
+ - Filesystem methods.
+ - Terminating a subrequest.
+ - Local cache API.
+ - API function reference.
Overview
========
-The network filesystem helper library is a set of functions designed to aid a
-network filesystem in implementing VM/VFS operations. For the moment, that
-just includes turning various VM buffered read operations into requests to read
-from the server. The helper library, however, can also interpose other
-services, such as local caching or local data encryption.
+The network filesystem services library, netfslib, is a set of functions
+designed to aid a network filesystem in implementing VM/VFS API operations. It
+takes over the normal buffered read, readahead, write and writeback and also
+handles unbuffered and direct I/O.
-Note that the library module doesn't link against local caching directly, so
-access must be provided by the netfs.
+The library provides support for (re-)negotiation of I/O sizes and retrying
+failed I/O as well as local caching and will, in the future, provide content
+encryption.
+
+It insulates the filesystem from VM interface changes as much as possible and
+handles VM features such as large multipage folios. The filesystem basically
+just has to provide a way to perform read and write RPC calls.
+
+The way I/O is organised inside netfslib consists of a number of objects:
+
+ * A *request*. A request is used to track the progress of the I/O overall and
+ to hold on to resources. The collection of results is done at the request
+ level. The I/O within a request is divided into a number of parallel
+ streams of subrequests.
+
+ * A *stream*. A non-overlapping series of subrequests. The subrequests
+ within a stream do not have to be contiguous.
+
+ * A *subrequest*. This is the basic unit of I/O. It represents a single RPC
+ call or a single cache I/O operation. The library passes these to the
+ filesystem and the cache to perform.
+
+Requests and Streams
+--------------------
+
+When actually performing I/O (as opposed to just copying into the pagecache),
+netfslib will create one or more requests to track the progress of the I/O and
+to hold resources.
+
+A read operation will have a single stream and the subrequests within that
+stream may be of mixed origins, for instance mixing RPC subrequests and cache
+subrequests.
+
+On the other hand, a write operation may have multiple streams, where each
+stream targets a different destination. For instance, there may be one stream
+writing to the local cache and one to the server. Currently, only two streams
+are allowed, but this could be increased if parallel writes to multiple servers
+is desired.
+
+The subrequests within a write stream do not need to match alignment or size
+with the subrequests in another write stream and netfslib performs the tiling
+of subrequests in each stream over the source buffer independently. Further,
+each stream may contain holes that don't correspond to holes in the other
+stream.
+
+In addition, the subrequests do not need to correspond to the boundaries of the
+folios or vectors in the source/destination buffer. The library handles the
+collection of results and the wrangling of folio flags and references.
+
+Subrequests
+-----------
+
+Subrequests are at the heart of the interaction between netfslib and the
+filesystem using it. Each subrequest is expected to correspond to a single
+read or write RPC or cache operation. The library will stitch together the
+results from a set of subrequests to provide a higher level operation.
+
+Netfslib has two interactions with the filesystem or the cache when setting up
+a subrequest. First, there's an optional preparatory step that allows the
+filesystem to negotiate the limits on the subrequest, both in terms of maximum
+number of bytes and maximum number of vectors (e.g. for RDMA). This may
+involve negotiating with the server (e.g. cifs needing to acquire credits).
+
+And, secondly, there's the issuing step in which the subrequest is handed off
+to the filesystem to perform.
+
+Note that these two steps are done slightly differently between read and write:
+
+ * For reads, the VM/VFS tells us how much is being requested up front, so the
+ library can preset maximum values that the cache and then the filesystem can
+ then reduce. The cache also gets consulted first on whether it wants to do
+ a read before the filesystem is consulted.
+
+ * For writeback, it is unknown how much there will be to write until the
+ pagecache is walked, so no limit is set by the library.
+
+Once a subrequest is completed, the filesystem or cache informs the library of
+the completion and then collection is invoked. Depending on whether the
+request is synchronous or asynchronous, the collection of results will be done
+in either the application thread or in a work queue.
+
+Result Collection and Retry
+---------------------------
+
+As subrequests complete, the results are collected and collated by the library
+and folio unlocking is performed progressively (if appropriate). Once the
+request is complete, async completion will be invoked (again, if appropriate).
+It is possible for the filesystem to provide interim progress reports to the
+library to cause folio unlocking to happen earlier if possible.
+
+If any subrequests fail, netfslib can retry them. It will wait until all
+subrequests are completed, offer the filesystem the opportunity to fiddle with
+the resources/state held by the request and poke at the subrequests before
+re-preparing and re-issuing the subrequests.
+
+This allows the tiling of contiguous sets of failed subrequest within a stream
+to be changed, adding more subrequests or ditching excess as necessary (for
+instance, if the network sizes change or the server decides it wants smaller
+chunks).
+
+Further, if one or more contiguous cache-read subrequests fail, the library
+will pass them to the filesystem to perform instead, renegotiating and retiling
+them as necessary to fit with the filesystem's parameters rather than those of
+the cache.
+
+Local Caching
+-------------
+
+One of the services netfslib provides, via ``fscache``, is the option to cache
+on local disk a copy of the data obtained from/written to a network filesystem.
+The library will manage the storing, retrieval and some invalidation of data
+automatically on behalf of the filesystem if a cookie is attached to the
+``netfs_inode``.
+
+Note that local caching used to use the PG_private_2 (aliased as PG_fscache) to
+keep track of a page that was being written to the cache, but this is now
+deprecated as PG_private_2 will be removed.
+
+Instead, folios that are read from the server for which there was no data in
+the cache will be marked as dirty and will have ``folio->private`` set to a
+special value (``NETFS_FOLIO_COPY_TO_CACHE``) and left to writeback to write.
+If the folio is modified before that happened, the special value will be
+cleared and the write will become normally dirty.
+
+When writeback occurs, folios that are so marked will only be written to the
+cache and not to the server. Writeback handles mixed cache-only writes and
+server-and-cache writes by using two streams, sending one to the cache and one
+to the server. The server stream will have gaps in it corresponding to those
+folios.
+
+Content Encryption (fscrypt)
+----------------------------
+
+Though it does not do so yet, at some point netfslib will acquire the ability
+to do client-side content encryption on behalf of the network filesystem (Ceph,
+for example). fscrypt can be used for this if appropriate (it may not be -
+cifs, for example).
+
+The data will be stored encrypted in the local cache using the same manner of
+encryption as the data written to the server and the library will impose bounce
+buffering and RMW cycles as necessary.
Per-Inode Context
@@ -40,10 +194,13 @@ structure is defined::
struct netfs_inode {
struct inode inode;
const struct netfs_request_ops *ops;
- struct fscache_cookie *cache;
+ struct fscache_cookie * cache;
+ loff_t remote_i_size;
+ unsigned long flags;
+ ...
};
-A network filesystem that wants to use netfs lib must place one of these in its
+A network filesystem that wants to use netfslib must place one of these in its
inode wrapper struct instead of the VFS ``struct inode``. This can be done in
a way similar to the following::
@@ -56,7 +213,8 @@ This allows netfslib to find its state by using ``container_of()`` from the
inode pointer, thereby allowing the netfslib helper functions to be pointed to
directly by the VFS/VM operation tables.
-The structure contains the following fields:
+The structure contains the following fields that are of interest to the
+filesystem:
* ``inode``
@@ -71,6 +229,37 @@ The structure contains the following fields:
Local caching cookie, or NULL if no caching is enabled. This field does not
exist if fscache is disabled.
+ * ``remote_i_size``
+
+ The size of the file on the server. This differs from inode->i_size if
+ local modifications have been made but not yet written back.
+
+ * ``flags``
+
+ A set of flags, some of which the filesystem might be interested in:
+
+ * ``NETFS_ICTX_MODIFIED_ATTR``
+
+ Set if netfslib modifies mtime/ctime. The filesystem is free to ignore
+ this or clear it.
+
+ * ``NETFS_ICTX_UNBUFFERED``
+
+ Do unbuffered I/O upon the file. Like direct I/O but without the
+ alignment limitations. RMW will be performed if necessary. The pagecache
+ will not be used unless mmap() is also used.
+
+ * ``NETFS_ICTX_WRITETHROUGH``
+
+ Do writethrough caching upon the file. I/O will be set up and dispatched
+ as buffered writes are made to the page cache. mmap() does the normal
+ writeback thing.
+
+ * ``NETFS_ICTX_SINGLE_NO_UPLOAD``
+
+ Set if the file has a monolithic content that must be read entirely in a
+ single go and must not be written back to the server, though it can be
+ cached (e.g. AFS directories).
Inode Context Helper Functions
------------------------------
@@ -84,117 +273,250 @@ set the operations table pointer::
then a function to cast from the VFS inode structure to the netfs context::
- struct netfs_inode *netfs_node(struct inode *inode);
+ struct netfs_inode *netfs_inode(struct inode *inode);
and finally, a function to get the cache cookie pointer from the context
attached to an inode (or NULL if fscache is disabled)::
struct fscache_cookie *netfs_i_cookie(struct netfs_inode *ctx);
+Inode Locking
+-------------
+
+A number of functions are provided to manage the locking of i_rwsem for I/O and
+to effectively extend it to provide more separate classes of exclusion::
+
+ int netfs_start_io_read(struct inode *inode);
+ void netfs_end_io_read(struct inode *inode);
+ int netfs_start_io_write(struct inode *inode);
+ void netfs_end_io_write(struct inode *inode);
+ int netfs_start_io_direct(struct inode *inode);
+ void netfs_end_io_direct(struct inode *inode);
+
+The exclusion breaks down into four separate classes:
+
+ 1) Buffered reads and writes.
+
+ Buffered reads can run concurrently each other and with buffered writes,
+ but buffered writes cannot run concurrently with each other.
+
+ 2) Direct reads and writes.
+
+ Direct (and unbuffered) reads and writes can run concurrently since they do
+ not share local buffering (i.e. the pagecache) and, in a network
+ filesystem, are expected to have exclusion managed on the server (though
+ this may not be the case for, say, Ceph).
+
+ 3) Other major inode modifying operations (e.g. truncate, fallocate).
+
+ These should just access i_rwsem directly.
+
+ 4) mmap().
+
+ mmap'd accesses might operate concurrently with any of the other classes.
+ They might form the buffer for an intra-file loopback DIO read/write. They
+ might be permitted on unbuffered files.
+
+Inode Writeback
+---------------
+
+Netfslib will pin resources on an inode for future writeback (such as pinning
+use of an fscache cookie) when an inode is dirtied. However, this pinning
+needs careful management. To manage the pinning, the following sequence
+occurs:
+
+ 1) An inode state flag ``I_PINNING_NETFS_WB`` is set by netfslib when the
+ pinning begins (when a folio is dirtied, for example) if the cache is
+ active to stop the cache structures from being discarded and the cache
+ space from being culled. This also prevents re-getting of cache resources
+ if the flag is already set.
+
+ 2) This flag then cleared inside the inode lock during inode writeback in the
+ VM - and the fact that it was set is transferred to ``->unpinned_netfs_wb``
+ in ``struct writeback_control``.
+
+ 3) If ``->unpinned_netfs_wb`` is now set, the write_inode procedure is forced.
+
+ 4) The filesystem's ``->write_inode()`` function is invoked to do the cleanup.
+
+ 5) The filesystem invokes netfs to do its cleanup.
+
+To do the cleanup, netfslib provides a function to do the resource unpinning::
+
+ int netfs_unpin_writeback(struct inode *inode, struct writeback_control *wbc);
+
+If the filesystem doesn't need to do anything else, this may be set as a its
+``.write_inode`` method.
+
+Further, if an inode is deleted, the filesystem's write_inode method may not
+get called, so::
+
+ void netfs_clear_inode_writeback(struct inode *inode, const void *aux);
-Buffered Read Helpers
-=====================
+must be called from ``->evict_inode()`` *before* ``clear_inode()`` is called.
-The library provides a set of read helpers that handle the ->read_folio(),
-->readahead() and much of the ->write_begin() VM operations and translate them
-into a common call framework.
-The following services are provided:
+High-Level VFS API
+==================
- * Handle folios that span multiple pages.
+Netfslib provides a number of sets of API calls for the filesystem to delegate
+VFS operations to. Netfslib, in turn, will call out to the filesystem and the
+cache to negotiate I/O sizes, issue RPCs and provide places for it to intervene
+at various times.
- * Insulate the netfs from VM interface changes.
+Unlocked Read/Write Iter
+------------------------
- * Allow the netfs to arbitrarily split reads up into pieces, even ones that
- don't match folio sizes or folio alignments and that may cross folios.
+The first API set is for the delegation of operations to netfslib when the
+filesystem is called through the standard VFS read/write_iter methods::
- * Allow the netfs to expand a readahead request in both directions to meet its
- needs.
+ ssize_t netfs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter);
+ ssize_t netfs_file_write_iter(struct kiocb *iocb, struct iov_iter *from);
+ ssize_t netfs_buffered_read_iter(struct kiocb *iocb, struct iov_iter *iter);
+ ssize_t netfs_unbuffered_read_iter(struct kiocb *iocb, struct iov_iter *iter);
+ ssize_t netfs_unbuffered_write_iter(struct kiocb *iocb, struct iov_iter *from);
- * Allow the netfs to partially fulfil a read, which will then be resubmitted.
+They can be assigned directly to ``.read_iter`` and ``.write_iter``. They
+perform the inode locking themselves and the first two will switch between
+buffered I/O and DIO as appropriate.
- * Handle local caching, allowing cached data and server-read data to be
- interleaved for a single request.
+Pre-Locked Read/Write Iter
+--------------------------
- * Handle clearing of bufferage that aren't on the server.
+The second API set is for the delegation of operations to netfslib when the
+filesystem is called through the standard VFS methods, but needs to do some
+other stuff before or after calling netfslib whilst still inside locked section
+(e.g. Ceph negotiating caps). The unbuffered read function is::
- * Handle retrying of reads that failed, switching reads from the cache to the
- server as necessary.
+ ssize_t netfs_unbuffered_read_iter_locked(struct kiocb *iocb, struct iov_iter *iter);
- * In the future, this is a place that other services can be performed, such as
- local encryption of data to be stored remotely or in the cache.
+This must not be assigned directly to ``.read_iter`` and the filesystem is
+responsible for performing the inode locking before calling it. In the case of
+buffered read, the filesystem should use ``filemap_read()``.
-From the network filesystem, the helpers require a table of operations. This
-includes a mandatory method to issue a read operation along with a number of
-optional methods.
+There are three functions for writes::
+ ssize_t netfs_buffered_write_iter_locked(struct kiocb *iocb, struct iov_iter *from,
+ struct netfs_group *netfs_group);
+ ssize_t netfs_perform_write(struct kiocb *iocb, struct iov_iter *iter,
+ struct netfs_group *netfs_group);
+ ssize_t netfs_unbuffered_write_iter_locked(struct kiocb *iocb, struct iov_iter *iter,
+ struct netfs_group *netfs_group);
-Read Helper Functions
+These must not be assigned directly to ``.write_iter`` and the filesystem is
+responsible for performing the inode locking before calling them.
+
+The first two functions are for buffered writes; the first just adds some
+standard write checks and jumps to the second, but if the filesystem wants to
+do the checks itself, it can use the second directly. The third function is
+for unbuffered or DIO writes.
+
+On all three write functions, there is a writeback group pointer (which should
+be NULL if the filesystem doesn't use this). Writeback groups are set on
+folios when they're modified. If a folio to-be-modified is already marked with
+a different group, it is flushed first. The writeback API allows writing back
+of a specific group.
+
+Memory-Mapped I/O API
---------------------
-Three read helpers are provided::
+An API for support of mmap()'d I/O is provided::
+
+ vm_fault_t netfs_page_mkwrite(struct vm_fault *vmf, struct netfs_group *netfs_group);
+
+This allows the filesystem to delegate ``.page_mkwrite`` to netfslib. The
+filesystem should not take the inode lock before calling it, but, as with the
+locked write functions above, this does take a writeback group pointer. If the
+page to be made writable is in a different group, it will be flushed first.
+
+Monolithic Files API
+--------------------
+
+There is also a special API set for files for which the content must be read in
+a single RPC (and not written back) and is maintained as a monolithic blob
+(e.g. an AFS directory), though it can be stored and updated in the local cache::
+
+ ssize_t netfs_read_single(struct inode *inode, struct file *file, struct iov_iter *iter);
+ void netfs_single_mark_inode_dirty(struct inode *inode);
+ int netfs_writeback_single(struct address_space *mapping,
+ struct writeback_control *wbc,
+ struct iov_iter *iter);
+
+The first function reads from a file into the given buffer, reading from the
+cache in preference if the data is cached there; the second function allows the
+inode to be marked dirty, causing a later writeback; and the third function can
+be called from the writeback code to write the data to the cache, if there is
+one.
+
+The inode should be marked ``NETFS_ICTX_SINGLE_NO_UPLOAD`` if this API is to be
+used. The writeback function requires the buffer to be of ITER_FOLIOQ type.
- void netfs_readahead(struct readahead_control *ractl);
- int netfs_read_folio(struct file *file,
- struct folio *folio);
- int netfs_write_begin(struct netfs_inode *ctx,
- struct file *file,
- struct address_space *mapping,
- loff_t pos,
- unsigned int len,
- struct folio **_folio,
- void **_fsdata);
+High-Level VM API
+==================
-Each corresponds to a VM address space operation. These operations use the
-state in the per-inode context.
+Netfslib also provides a number of sets of API calls for the filesystem to
+delegate VM operations to. Again, netfslib, in turn, will call out to the
+filesystem and the cache to negotiate I/O sizes, issue RPCs and provide places
+for it to intervene at various times::
-For ->readahead() and ->read_folio(), the network filesystem just point directly
-at the corresponding read helper; whereas for ->write_begin(), it may be a
-little more complicated as the network filesystem might want to flush
-conflicting writes or track dirty data and needs to put the acquired folio if
-an error occurs after calling the helper.
+ void netfs_readahead(struct readahead_control *);
+ int netfs_read_folio(struct file *, struct folio *);
+ int netfs_writepages(struct address_space *mapping,
+ struct writeback_control *wbc);
+ bool netfs_dirty_folio(struct address_space *mapping, struct folio *folio);
+ void netfs_invalidate_folio(struct folio *folio, size_t offset, size_t length);
+ bool netfs_release_folio(struct folio *folio, gfp_t gfp);
-The helpers manage the read request, calling back into the network filesystem
-through the suppplied table of operations. Waits will be performed as
-necessary before returning for helpers that are meant to be synchronous.
+These are ``address_space_operations`` methods and can be set directly in the
+operations table.
-If an error occurs, the ->free_request() will be called to clean up the
-netfs_io_request struct allocated. If some parts of the request are in
-progress when an error occurs, the request will get partially completed if
-sufficient data is read.
+Deprecated PG_private_2 API
+---------------------------
-Additionally, there is::
+There is also a deprecated function for filesystems that still use the
+``->write_begin`` method::
- * void netfs_subreq_terminated(struct netfs_io_subrequest *subreq,
- ssize_t transferred_or_error,
- bool was_async);
+ int netfs_write_begin(struct netfs_inode *inode, struct file *file,
+ struct address_space *mapping, loff_t pos, unsigned int len,
+ struct folio **_folio, void **_fsdata);
-which should be called to complete a read subrequest. This is given the number
-of bytes transferred or a negative error code, plus a flag indicating whether
-the operation was asynchronous (ie. whether the follow-on processing can be
-done in the current context, given this may involve sleeping).
+It uses the deprecated PG_private_2 flag and so should not be used.
-Read Helper Structures
-----------------------
+I/O Request API
+===============
-The read helpers make use of a couple of structures to maintain the state of
-the read. The first is a structure that manages a read request as a whole::
+The I/O request API comprises a number of structures and a number of functions
+that the filesystem may need to use.
+
+Request Structure
+-----------------
+
+The request structure manages the request as a whole, holding some resources
+and state on behalf of the filesystem and tracking the collection of results::
struct netfs_io_request {
+ enum netfs_io_origin origin;
struct inode *inode;
struct address_space *mapping;
- struct netfs_cache_resources cache_resources;
+ struct netfs_group *group;
+ struct netfs_io_stream io_streams[];
void *netfs_priv;
- loff_t start;
- size_t len;
- loff_t i_size;
- const struct netfs_request_ops *netfs_ops;
+ void *netfs_priv2;
+ unsigned long long start;
+ unsigned long long len;
+ unsigned long long i_size;
unsigned int debug_id;
+ unsigned long flags;
...
};
-The above fields are the ones the netfs can use. They are:
+Many of the fields are for internal use, but the fields shown here are of
+interest to the filesystem:
+
+ * ``origin``
+
+ The origin of the request (readahead, read_folio, DIO read, writeback, ...).
* ``inode``
* ``mapping``
@@ -202,11 +524,19 @@ The above fields are the ones the netfs can use. They are:
The inode and the address space of the file being read from. The mapping
may or may not point to inode->i_data.
- * ``cache_resources``
+ * ``group``
+
+ The writeback group this request is dealing with or NULL. This holds a ref
+ on the group.
- Resources for the local cache to use, if present.
+ * ``io_streams``
+
+ The parallel streams of subrequests available to the request. Currently two
+ are available, but this may be made extensible in future. ``NR_IO_STREAMS``
+ indicates the size of the array.
* ``netfs_priv``
+ * ``netfs_priv2``
The network filesystem's private data. The value for this can be passed in
to the helper functions or set during the request.
@@ -221,37 +551,121 @@ The above fields are the ones the netfs can use. They are:
The size of the file at the start of the request.
- * ``netfs_ops``
-
- A pointer to the operation table. The value for this is passed into the
- helper functions.
-
* ``debug_id``
A number allocated to this operation that can be displayed in trace lines
for reference.
+ * ``flags``
+
+ Flags for managing and controlling the operation of the request. Some of
+ these may be of interest to the filesystem:
+
+ * ``NETFS_RREQ_RETRYING``
+
+ Netfslib sets this when generating retries.
+
+ * ``NETFS_RREQ_PAUSE``
+
+ The filesystem can set this to request to pause the library's subrequest
+ issuing loop - but care needs to be taken as netfslib may also set it.
+
+ * ``NETFS_RREQ_NONBLOCK``
+ * ``NETFS_RREQ_BLOCKED``
+
+ Netfslib sets the first to indicate that non-blocking mode was set by the
+ caller and the filesystem can set the second to indicate that it would
+ have had to block.
+
+ * ``NETFS_RREQ_USE_PGPRIV2``
+
+ The filesystem can set this if it wants to use PG_private_2 to track
+ whether a folio is being written to the cache. This is deprecated as
+ PG_private_2 is going to go away.
+
+If the filesystem wants more private data than is afforded by this structure,
+then it should wrap it and provide its own allocator.
+
+Stream Structure
+----------------
+
+A request is comprised of one or more parallel streams and each stream may be
+aimed at a different target.
+
+For read requests, only stream 0 is used. This can contain a mixture of
+subrequests aimed at different sources. For write requests, stream 0 is used
+for the server and stream 1 is used for the cache. For buffered writeback,
+stream 0 is not enabled unless a normal dirty folio is encountered, at which
+point ->begin_writeback() will be invoked and the filesystem can mark the
+stream available.
+
+The stream struct looks like::
+
+ struct netfs_io_stream {
+ unsigned char stream_nr;
+ bool avail;
+ size_t sreq_max_len;
+ unsigned int sreq_max_segs;
+ unsigned int submit_extendable_to;
+ ...
+ };
+
+A number of members are available for access/use by the filesystem:
+
+ * ``stream_nr``
+
+ The number of the stream within the request.
+
+ * ``avail``
+
+ True if the stream is available for use. The filesystem should set this on
+ stream zero if in ->begin_writeback().
+
+ * ``sreq_max_len``
+ * ``sreq_max_segs``
+
+ These are set by the filesystem or the cache in ->prepare_read() or
+ ->prepare_write() for each subrequest to indicate the maximum number of
+ bytes and, optionally, the maximum number of segments (if not 0) that that
+ subrequest can support.
+
+ * ``submit_extendable_to``
+
+ The size that a subrequest can be rounded up to beyond the EOF, given the
+ available buffer. This allows the cache to work out if it can do a DIO read
+ or write that straddles the EOF marker.
-The second structure is used to manage individual slices of the overall read
-request::
+Subrequest Structure
+--------------------
+
+Individual units of I/O are managed by the subrequest structure. These
+represent slices of the overall request and run independently::
struct netfs_io_subrequest {
struct netfs_io_request *rreq;
- loff_t start;
+ struct iov_iter io_iter;
+ unsigned long long start;
size_t len;
size_t transferred;
unsigned long flags;
+ short error;
unsigned short debug_index;
+ unsigned char stream_nr;
...
};
-Each subrequest is expected to access a single source, though the helpers will
+Each subrequest is expected to access a single source, though the library will
handle falling back from one source type to another. The members are:
* ``rreq``
A pointer to the read request.
+ * ``io_iter``
+
+ An I/O iterator representing a slice of the buffer to be read into or
+ written from.
+
* ``start``
* ``len``
@@ -260,256 +674,295 @@ handle falling back from one source type to another. The members are:
* ``transferred``
- The amount of data transferred so far of the length of this slice. The
- network filesystem or cache should start the operation this far into the
- slice. If a short read occurs, the helpers will call again, having updated
- this to reflect the amount read so far.
+ The amount of data transferred so far for this subrequest. This should be
+ added to with the length of the transfer made by this issuance of the
+ subrequest. If this is less than ``len`` then the subrequest may be
+ reissued to continue.
* ``flags``
- Flags pertaining to the read. There are two of interest to the filesystem
- or cache:
+ Flags for managing the subrequest. There are a number of interest to the
+ filesystem or cache:
+
+ * ``NETFS_SREQ_MADE_PROGRESS``
+
+ Set by the filesystem to indicates that at least one byte of data was read
+ or written.
+
+ * ``NETFS_SREQ_HIT_EOF``
+
+ The filesystem should set this if a read hit the EOF on the file (in which
+ case ``transferred`` should stop at the EOF). Netfslib may expand the
+ subrequest out to the size of the folio containing the EOF on the off
+ chance that a third party change happened or a DIO read may have asked for
+ more than is available. The library will clear any excess pagecache.
* ``NETFS_SREQ_CLEAR_TAIL``
- This can be set to indicate that the remainder of the slice, from
- transferred to len, should be cleared.
+ The filesystem can set this to indicate that the remainder of the slice,
+ from transferred to len, should be cleared. Do not set if HIT_EOF is set.
+
+ * ``NETFS_SREQ_NEED_RETRY``
+
+ The filesystem can set this to tell netfslib to retry the subrequest.
- * ``NETFS_SREQ_SEEK_DATA_READ``
+ * ``NETFS_SREQ_BOUNDARY``
- This is a hint to the cache that it might want to try skipping ahead to
- the next data (ie. using SEEK_DATA).
+ This can be set by the filesystem on a subrequest to indicate that it ends
+ at a boundary with the filesystem structure (e.g. at the end of a Ceph
+ object). It tells netfslib not to retile subrequests across it.
+
+ * ``error``
+
+ This is for the filesystem to store result of the subrequest. It should be
+ set to 0 if successful and a negative error code otherwise.
* ``debug_index``
+ * ``stream_nr``
A number allocated to this slice that can be displayed in trace lines for
- reference.
+ reference and the number of the request stream that it belongs to.
+
+If necessary, the filesystem can get and put extra refs on the subrequest it is
+given::
+ void netfs_get_subrequest(struct netfs_io_subrequest *subreq,
+ enum netfs_sreq_ref_trace what);
+ void netfs_put_subrequest(struct netfs_io_subrequest *subreq,
+ enum netfs_sreq_ref_trace what);
-Read Helper Operations
-----------------------
+using netfs trace codes to indicate the reason. Care must be taken, however,
+as once control of the subrequest is returned to netfslib, the same subrequest
+can be reissued/retried.
-The network filesystem must provide the read helpers with a table of operations
-through which it can issue requests and negotiate::
+Filesystem Methods
+------------------
+
+The filesystem sets a table of operations in ``netfs_inode`` for netfslib to
+use::
struct netfs_request_ops {
- void (*init_request)(struct netfs_io_request *rreq, struct file *file);
+ mempool_t *request_pool;
+ mempool_t *subrequest_pool;
+ int (*init_request)(struct netfs_io_request *rreq, struct file *file);
void (*free_request)(struct netfs_io_request *rreq);
- int (*begin_cache_operation)(struct netfs_io_request *rreq);
+ void (*free_subrequest)(struct netfs_io_subrequest *rreq);
void (*expand_readahead)(struct netfs_io_request *rreq);
- bool (*clamp_length)(struct netfs_io_subrequest *subreq);
+ int (*prepare_read)(struct netfs_io_subrequest *subreq);
void (*issue_read)(struct netfs_io_subrequest *subreq);
- bool (*is_still_valid)(struct netfs_io_request *rreq);
- int (*check_write_begin)(struct file *file, loff_t pos, unsigned len,
- struct folio **foliop, void **_fsdata);
void (*done)(struct netfs_io_request *rreq);
+ void (*update_i_size)(struct inode *inode, loff_t i_size);
+ void (*post_modify)(struct inode *inode);
+ void (*begin_writeback)(struct netfs_io_request *wreq);
+ void (*prepare_write)(struct netfs_io_subrequest *subreq);
+ void (*issue_write)(struct netfs_io_subrequest *subreq);
+ void (*retry_request)(struct netfs_io_request *wreq,
+ struct netfs_io_stream *stream);
+ void (*invalidate_cache)(struct netfs_io_request *wreq);
};
-The operations are as follows:
+The table starts with a pair of optional pointers to memory pools from which
+requests and subrequests can be allocated. If these are not given, netfslib
+has default pools that it will use instead. If the filesystem wraps the netfs
+structs in its own larger structs, then it will need to use its own pools.
+Netfslib will allocate directly from the pools.
- * ``init_request()``
-
- [Optional] This is called to initialise the request structure. It is given
- the file for reference.
+The methods defined in the table are:
+ * ``init_request()``
* ``free_request()``
+ * ``free_subrequest()``
- [Optional] This is called as the request is being deallocated so that the
- filesystem can clean up any state it has attached there.
-
- * ``begin_cache_operation()``
-
- [Optional] This is called to ask the network filesystem to call into the
- cache (if present) to initialise the caching state for this read. The netfs
- library module cannot access the cache directly, so the cache should call
- something like fscache_begin_read_operation() to do this.
-
- The cache gets to store its state in ->cache_resources and must set a table
- of operations of its own there (though of a different type).
-
- This should return 0 on success and an error code otherwise. If an error is
- reported, the operation may proceed anyway, just without local caching (only
- out of memory and interruption errors cause failure here).
+ [Optional] A filesystem may implement these to initialise or clean up any
+ resources that it attaches to the request or subrequest.
* ``expand_readahead()``
[Optional] This is called to allow the filesystem to expand the size of a
- readahead read request. The filesystem gets to expand the request in both
- directions, though it's not permitted to reduce it as the numbers may
- represent an allocation already made. If local caching is enabled, it gets
- to expand the request first.
+ readahead request. The filesystem gets to expand the request in both
+ directions, though it must retain the initial region as that may represent
+ an allocation already made. If local caching is enabled, it gets to expand
+ the request first.
Expansion is communicated by changing ->start and ->len in the request
structure. Note that if any change is made, ->len must be increased by at
least as much as ->start is reduced.
- * ``clamp_length()``
-
- [Optional] This is called to allow the filesystem to reduce the size of a
- subrequest. The filesystem can use this, for example, to chop up a request
- that has to be split across multiple servers or to put multiple reads in
- flight.
-
- This should return 0 on success and an error code on error.
-
- * ``issue_read()``
+ * ``prepare_read()``
- [Required] The helpers use this to dispatch a subrequest to the server for
- reading. In the subrequest, ->start, ->len and ->transferred indicate what
- data should be read from the server.
+ [Optional] This is called to allow the filesystem to limit the size of a
+ subrequest. It may also limit the number of individual regions in iterator,
+ such as required by RDMA. This information should be set on stream zero in::
- There is no return value; the netfs_subreq_terminated() function should be
- called to indicate whether or not the operation succeeded and how much data
- it transferred. The filesystem also should not deal with setting folios
- uptodate, unlocking them or dropping their refs - the helpers need to deal
- with this as they have to coordinate with copying to the local cache.
+ rreq->io_streams[0].sreq_max_len
+ rreq->io_streams[0].sreq_max_segs
- Note that the helpers have the folios locked, but not pinned. It is
- possible to use the ITER_XARRAY iov iterator to refer to the range of the
- inode that is being operated upon without the need to allocate large bvec
- tables.
+ The filesystem can use this, for example, to chop up a request that has to
+ be split across multiple servers or to put multiple reads in flight.
- * ``is_still_valid()``
+ Zero should be returned on success and an error code otherwise.
- [Optional] This is called to find out if the data just read from the local
- cache is still valid. It should return true if it is still valid and false
- if not. If it's not still valid, it will be reread from the server.
+ * ``issue_read()``
- * ``check_write_begin()``
+ [Required] Netfslib calls this to dispatch a subrequest to the server for
+ reading. In the subrequest, ->start, ->len and ->transferred indicate what
+ data should be read from the server and ->io_iter indicates the buffer to be
+ used.
- [Optional] This is called from the netfs_write_begin() helper once it has
- allocated/grabbed the folio to be modified to allow the filesystem to flush
- conflicting state before allowing it to be modified.
+ There is no return value; the ``netfs_read_subreq_terminated()`` function
+ should be called to indicate that the subrequest completed either way.
+ ->error, ->transferred and ->flags should be updated before completing. The
+ termination can be done asynchronously.
- It may unlock and discard the folio it was given and set the caller's folio
- pointer to NULL. It should return 0 if everything is now fine (``*foliop``
- left set) or the op should be retried (``*foliop`` cleared) and any other
- error code to abort the operation.
+ Note: the filesystem must not deal with setting folios uptodate, unlocking
+ them or dropping their refs - the library deals with this as it may have to
+ stitch together the results of multiple subrequests that variously overlap
+ the set of folios.
- * ``done``
+ * ``done()``
- [Optional] This is called after the folios in the request have all been
+ [Optional] This is called after the folios in a read request have all been
unlocked (and marked uptodate if applicable).
+ * ``update_i_size()``
+
+ [Optional] This is invoked by netfslib at various points during the write
+ paths to ask the filesystem to update its idea of the file size. If not
+ given, netfslib will set i_size and i_blocks and update the local cache
+ cookie.
+
+ * ``post_modify()``
+
+ [Optional] This is called after netfslib writes to the pagecache or when it
+ allows an mmap'd page to be marked as writable.
+
+ * ``begin_writeback()``
+
+ [Optional] Netfslib calls this when processing a writeback request if it
+ finds a dirty page that isn't simply marked NETFS_FOLIO_COPY_TO_CACHE,
+ indicating it must be written to the server. This allows the filesystem to
+ only set up writeback resources when it knows it's going to have to perform
+ a write.
+
+ * ``prepare_write()``
+ [Optional] This is called to allow the filesystem to limit the size of a
+ subrequest. It may also limit the number of individual regions in iterator,
+ such as required by RDMA. This information should be set on stream to which
+ the subrequest belongs::
-Read Helper Procedure
----------------------
-
-The read helpers work by the following general procedure:
-
- * Set up the request.
-
- * For readahead, allow the local cache and then the network filesystem to
- propose expansions to the read request. This is then proposed to the VM.
- If the VM cannot fully perform the expansion, a partially expanded read will
- be performed, though this may not get written to the cache in its entirety.
-
- * Loop around slicing chunks off of the request to form subrequests:
-
- * If a local cache is present, it gets to do the slicing, otherwise the
- helpers just try to generate maximal slices.
+ rreq->io_streams[subreq->stream_nr].sreq_max_len
+ rreq->io_streams[subreq->stream_nr].sreq_max_segs
- * The network filesystem gets to clamp the size of each slice if it is to be
- the source. This allows rsize and chunking to be implemented.
+ The filesystem can use this, for example, to chop up a request that has to
+ be split across multiple servers or to put multiple writes in flight.
- * The helpers issue a read from the cache or a read from the server or just
- clears the slice as appropriate.
+ This is not permitted to return an error. Instead, in the event of failure,
+ ``netfs_prepare_write_failed()`` must be called.
- * The next slice begins at the end of the last one.
+ * ``issue_write()``
- * As slices finish being read, they terminate.
+ [Required] This is used to dispatch a subrequest to the server for writing.
+ In the subrequest, ->start, ->len and ->transferred indicate what data
+ should be written to the server and ->io_iter indicates the buffer to be
+ used.
- * When all the subrequests have terminated, the subrequests are assessed and
- any that are short or have failed are reissued:
+ There is no return value; the ``netfs_write_subreq_terminated()`` function
+ should be called to indicate that the subrequest completed either way.
+ ->error, ->transferred and ->flags should be updated before completing. The
+ termination can be done asynchronously.
- * Failed cache requests are issued against the server instead.
+ Note: the filesystem must not deal with removing the dirty or writeback
+ marks on folios involved in the operation and should not take refs or pins
+ on them, but should leave retention to netfslib.
- * Failed server requests just fail.
+ * ``retry_request()``
- * Short reads against either source will be reissued against that source
- provided they have transferred some more data:
+ [Optional] Netfslib calls this at the beginning of a retry cycle. This
+ allows the filesystem to examine the state of the request, the subrequests
+ in the indicated stream and of its own data and make adjustments or
+ renegotiate resources.
+
+ * ``invalidate_cache()``
- * The cache may need to skip holes that it can't do DIO from.
+ [Optional] This is called by netfslib to invalidate data stored in the local
+ cache in the event that writing to the local cache fails, providing updated
+ coherency data that netfs can't provide.
- * If NETFS_SREQ_CLEAR_TAIL was set, a short read will be cleared to the
- end of the slice instead of reissuing.
+Terminating a subrequest
+------------------------
- * Once the data is read, the folios that have been fully read/cleared:
+When a subrequest completes, there are a number of functions that the cache or
+subrequest can call to inform netfslib of the status change. One function is
+provided to terminate a write subrequest at the preparation stage and acts
+synchronously:
- * Will be marked uptodate.
+ * ``void netfs_prepare_write_failed(struct netfs_io_subrequest *subreq);``
- * If a cache is present, will be marked with PG_fscache.
+ Indicate that the ->prepare_write() call failed. The ``error`` field should
+ have been updated.
- * Unlocked
+Note that ->prepare_read() can return an error as a read can simply be aborted.
+Dealing with writeback failure is trickier.
- * Any folios that need writing to the cache will then have DIO writes issued.
+The other functions are used for subrequests that got as far as being issued:
- * Synchronous operations will wait for reading to be complete.
+ * ``void netfs_read_subreq_terminated(struct netfs_io_subrequest *subreq);``
- * Writes to the cache will proceed asynchronously and the folios will have the
- PG_fscache mark removed when that completes.
+ Tell netfslib that a read subrequest has terminated. The ``error``,
+ ``flags`` and ``transferred`` fields should have been updated.
- * The request structures will be cleaned up when everything has completed.
+ * ``void netfs_write_subrequest_terminated(void *_op, ssize_t transferred_or_error);``
+ Tell netfslib that a write subrequest has terminated. Either the amount of
+ data processed or the negative error code can be passed in. This is
+ can be used as a kiocb completion function.
-Read Helper Cache API
----------------------
+ * ``void netfs_read_subreq_progress(struct netfs_io_subrequest *subreq);``
-When implementing a local cache to be used by the read helpers, two things are
-required: some way for the network filesystem to initialise the caching for a
-read request and a table of operations for the helpers to call.
+ This is provided to optionally update netfslib on the incremental progress
+ of a read, allowing some folios to be unlocked early and does not actually
+ terminate the subrequest. The ``transferred`` field should have been
+ updated.
-The network filesystem's ->begin_cache_operation() method is called to set up a
-cache and this must call into the cache to do the work. If using fscache, for
-example, the cache would call::
+Local Cache API
+---------------
- int fscache_begin_read_operation(struct netfs_io_request *rreq,
- struct fscache_cookie *cookie);
+Netfslib provides a separate API for a local cache to implement, though it
+provides some somewhat similar routines to the filesystem request API.
-passing in the request pointer and the cookie corresponding to the file.
-
-The netfs_io_request object contains a place for the cache to hang its
+Firstly, the netfs_io_request object contains a place for the cache to hang its
state::
struct netfs_cache_resources {
const struct netfs_cache_ops *ops;
void *cache_priv;
void *cache_priv2;
+ unsigned int debug_id;
+ unsigned int inval_counter;
};
-This contains an operations table pointer and two private pointers. The
-operation table looks like the following::
+This contains an operations table pointer and two private pointers plus the
+debug ID of the fscache cookie for tracing purposes and an invalidation counter
+that is cranked by calls to ``fscache_invalidate()`` allowing cache subrequests
+to be invalidated after completion.
+
+The cache operation table looks like the following::
struct netfs_cache_ops {
void (*end_operation)(struct netfs_cache_resources *cres);
-
void (*expand_readahead)(struct netfs_cache_resources *cres,
loff_t *_start, size_t *_len, loff_t i_size);
-
enum netfs_io_source (*prepare_read)(struct netfs_io_subrequest *subreq,
- loff_t i_size);
-
+ loff_t i_size);
int (*read)(struct netfs_cache_resources *cres,
loff_t start_pos,
struct iov_iter *iter,
bool seek_data,
netfs_io_terminated_t term_func,
void *term_func_priv);
-
- int (*prepare_write)(struct netfs_cache_resources *cres,
- loff_t *_start, size_t *_len, loff_t i_size,
- bool no_space_allocated_yet);
-
- int (*write)(struct netfs_cache_resources *cres,
- loff_t start_pos,
- struct iov_iter *iter,
- netfs_io_terminated_t term_func,
- void *term_func_priv);
-
- int (*query_occupancy)(struct netfs_cache_resources *cres,
- loff_t start, size_t len, size_t granularity,
- loff_t *_data_start, size_t *_data_len);
+ void (*prepare_write_subreq)(struct netfs_io_subrequest *subreq);
+ void (*issue_write)(struct netfs_io_subrequest *subreq);
};
With a termination handler function pointer::
@@ -526,11 +979,17 @@ The methods defined in the table are:
* ``expand_readahead()``
- [Optional] Called at the beginning of a netfs_readahead() operation to allow
- the cache to expand a request in either direction. This allows the cache to
+ [Optional] Called at the beginning of a readahead operation to allow the
+ cache to expand a request in either direction. This allows the cache to
size the request appropriately for the cache granularity.
- The function is passed poiners to the start and length in its parameters,
+ * ``prepare_read()``
+
+ [Required] Called to configure the next slice of a request. ->start and
+ ->len in the subrequest indicate where and how big the next slice can be;
+ the cache gets to reduce the length to match its granularity requirements.
+
+ The function is passed pointers to the start and length in its parameters,
plus the size of the file for reference, and adjusts the start and length
appropriately. It should return one of:
@@ -543,12 +1002,6 @@ The methods defined in the table are:
downloaded from the server or read from the cache - or whether slicing
should be given up at the current point.
- * ``prepare_read()``
-
- [Required] Called to configure the next slice of a request. ->start and
- ->len in the subrequest indicate where and how big the next slice can be;
- the cache gets to reduce the length to match its granularity requirements.
-
* ``read()``
[Required] Called to read from the cache. The start file offset is given
@@ -562,44 +1015,33 @@ The methods defined in the table are:
indicating whether the termination is definitely happening in the caller's
context.
- * ``prepare_write()``
+ * ``prepare_write_subreq()``
- [Required] Called to prepare a write to the cache to take place. This
- involves checking to see whether the cache has sufficient space to honour
- the write. ``*_start`` and ``*_len`` indicate the region to be written; the
- region can be shrunk or it can be expanded to a page boundary either way as
- necessary to align for direct I/O. i_size holds the size of the object and
- is provided for reference. no_space_allocated_yet is set to true if the
- caller is certain that no data has been written to that region - for example
- if it tried to do a read from there already.
+ [Required] This is called to allow the cache to limit the size of a
+ subrequest. It may also limit the number of individual regions in iterator,
+ such as required by DIO/DMA. This information should be set on stream to
+ which the subrequest belongs::
- * ``write()``
+ rreq->io_streams[subreq->stream_nr].sreq_max_len
+ rreq->io_streams[subreq->stream_nr].sreq_max_segs
- [Required] Called to write to the cache. The start file offset is given
- along with an iterator to write from, which gives the length also.
-
- Also provided is a pointer to a termination handler function and private
- data to pass to that function. The termination function should be called
- with the number of bytes transferred or an error code, plus a flag
- indicating whether the termination is definitely happening in the caller's
- context.
+ The filesystem can use this, for example, to chop up a request that has to
+ be split across multiple servers or to put multiple writes in flight.
- * ``query_occupancy()``
+ This is not permitted to return an error. In the event of failure,
+ ``netfs_prepare_write_failed()`` must be called.
- [Required] Called to find out where the next piece of data is within a
- particular region of the cache. The start and length of the region to be
- queried are passed in, along with the granularity to which the answer needs
- to be aligned. The function passes back the start and length of the data,
- if any, available within that region. Note that there may be a hole at the
- front.
+ * ``issue_write()``
- It returns 0 if some data was found, -ENODATA if there was no usable data
- within the region or -ENOBUFS if there is no caching on this file.
+ [Required] This is used to dispatch a subrequest to the cache for writing.
+ In the subrequest, ->start, ->len and ->transferred indicate what data
+ should be written to the cache and ->io_iter indicates the buffer to be
+ used.
-Note that these methods are passed a pointer to the cache resource structure,
-not the read request structure as they could be used in other situations where
-there isn't a read request structure as well, such as writing dirty data to the
-cache.
+ There is no return value; the ``netfs_write_subreq_terminated()`` function
+ should be called to indicate that the subrequest completed either way.
+ ->error, ->transferred and ->flags should be updated before completing. The
+ termination can be done asynchronously.
API Function Reference
@@ -607,4 +1049,3 @@ API Function Reference
.. kernel-doc:: include/linux/netfs.h
.. kernel-doc:: fs/netfs/buffered_read.c
-.. kernel-doc:: fs/netfs/io.c
diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst
index 5147e15815a1..4804441155f5 100644
--- a/Documentation/filesystems/nfs/client-identifier.rst
+++ b/Documentation/filesystems/nfs/client-identifier.rst
@@ -131,7 +131,7 @@ deployments, this construction is usually adequate. Often, however,
the node name by itself is not adequately unique, and can change
unexpectedly. Problematic situations include:
- - NFS-root (diskless) clients, where the local DCHP server (or
+ - NFS-root (diskless) clients, where the local DHCP server (or
equivalent) does not provide a unique host name.
- "Containers" within a single Linux host. If each container has
@@ -152,7 +152,7 @@ string:
via the kernel command line, or when the "nfs" module is
loaded.
- /sys/fs/nfs/client/net/identifier
+ /sys/fs/nfs/net/nfs_client/identifier
This virtual file, available since Linux 5.3, is local to the
network namespace in which it is accessed and so can provide
distinction between network namespaces (containers) when the
@@ -164,7 +164,7 @@ then that uniquifier can be used. For example, a uniquifier might
be formed at boot using the container's internal identifier:
sha256sum /etc/machine-id | awk '{print $1}' \\
- > /sys/fs/nfs/client/net/identifier
+ > /sys/fs/nfs/net/nfs_client/identifier
Security considerations
-----------------------
diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst
index 0e98edd353b5..de64d2d002a2 100644
--- a/Documentation/filesystems/nfs/exporting.rst
+++ b/Documentation/filesystems/nfs/exporting.rst
@@ -122,12 +122,9 @@ are exportable by setting the s_export_op field in the struct
super_block. This field must point to a "struct export_operations"
struct which has the following members:
- encode_fh (optional)
- Takes a dentry and creates a filehandle fragment which can later be used
- to find or create a dentry for the same object. The default
- implementation creates a filehandle fragment that encodes a 32bit inode
- and generation number for the inode encoded, and if necessary the
- same information for the parent.
+ encode_fh (mandatory)
+ Takes a dentry and creates a filehandle fragment which may later be used
+ to find or create a dentry for the same object.
fh_to_dentry (mandatory)
Given a filehandle fragment, this should find the implied object and
@@ -215,3 +212,29 @@ following flags are defined:
This flag causes nfsd to close any open files for this inode _before_
calling into the vfs to do an unlink or a rename that would replace
an existing file.
+
+ EXPORT_OP_REMOTE_FS - Backing storage for this filesystem is remote
+ PF_LOCAL_THROTTLE exists for loopback NFSD, where a thread needs to
+ write to one bdi (the final bdi) in order to free up writes queued
+ to another bdi (the client bdi). Such threads get a private balance
+ of dirty pages so that dirty pages for the client bdi do not imact
+ the daemon writing to the final bdi. For filesystems whose durable
+ storage is not local (such as exported NFS filesystems), this
+ constraint has negative consequences. EXPORT_OP_REMOTE_FS enables
+ an export to disable writeback throttling.
+
+ EXPORT_OP_NOATOMIC_ATTR - Filesystem does not update attributes atomically
+ EXPORT_OP_NOATOMIC_ATTR indicates that the exported filesystem
+ cannot provide the semantics required by the "atomic" boolean in
+ NFSv4's change_info4. This boolean indicates to a client whether the
+ returned before and after change attributes were obtained atomically
+ with the respect to the requested metadata operation (UNLINK,
+ OPEN/CREATE, MKDIR, etc).
+
+ EXPORT_OP_FLUSH_ON_CLOSE - Filesystem flushes file data on close(2)
+ On most filesystems, inodes can remain under writeback after the
+ file is closed. NFSD relies on client activity or local flusher
+ threads to handle writeback. Certain filesystems, such as NFS, flush
+ all of an inode's dirty data on last close. Exports that behave this
+ way should set EXPORT_OP_FLUSH_ON_CLOSE so that NFSD knows to skip
+ waiting for writeback when closing such files.
diff --git a/Documentation/filesystems/nfs/index.rst b/Documentation/filesystems/nfs/index.rst
index 8536134f31fd..a29a212b5b4d 100644
--- a/Documentation/filesystems/nfs/index.rst
+++ b/Documentation/filesystems/nfs/index.rst
@@ -8,9 +8,11 @@ NFS
client-identifier
exporting
+ localio
pnfs
rpc-cache
rpc-server-gss
nfs41-server
+ nfsd-io-modes
knfsd-stats
reexport
diff --git a/Documentation/filesystems/nfs/localio.rst b/Documentation/filesystems/nfs/localio.rst
new file mode 100644
index 000000000000..79808b37d745
--- /dev/null
+++ b/Documentation/filesystems/nfs/localio.rst
@@ -0,0 +1,357 @@
+===========
+NFS LOCALIO
+===========
+
+Overview
+========
+
+The LOCALIO auxiliary RPC protocol allows the Linux NFS client and
+server to reliably handshake to determine if they are on the same
+host. Select "NFS client and server support for LOCALIO auxiliary
+protocol" in menuconfig to enable CONFIG_NFS_LOCALIO in the kernel
+config (both CONFIG_NFS_FS and CONFIG_NFSD must also be enabled).
+
+Once an NFS client and server handshake as "local", the client will
+bypass the network RPC protocol for read, write and commit operations.
+Due to this XDR and RPC bypass, these operations will operate faster.
+
+The LOCALIO auxiliary protocol's implementation, which uses the same
+connection as NFS traffic, follows the pattern established by the NFS
+ACL protocol extension.
+
+The LOCALIO auxiliary protocol is needed to allow robust discovery of
+clients local to their servers. In a private implementation that
+preceded use of this LOCALIO protocol, a fragile sockaddr network
+address based match against all local network interfaces was attempted.
+But unlike the LOCALIO protocol, the sockaddr-based matching didn't
+handle use of iptables or containers.
+
+The robust handshake between local client and server is just the
+beginning, the ultimate use case this locality makes possible is the
+client is able to open files and issue reads, writes and commits
+directly to the server without having to go over the network. The
+requirement is to perform these loopback NFS operations as efficiently
+as possible, this is particularly useful for container use cases
+(e.g. kubernetes) where it is possible to run an IO job local to the
+server.
+
+The performance advantage realized from LOCALIO's ability to bypass
+using XDR and RPC for reads, writes and commits can be extreme, e.g.:
+
+fio for 20 secs with directio, qd of 8, 16 libaio threads:
+ - With LOCALIO:
+ 4K read: IOPS=979k, BW=3825MiB/s (4011MB/s)(74.7GiB/20002msec)
+ 4K write: IOPS=165k, BW=646MiB/s (678MB/s)(12.6GiB/20002msec)
+ 128K read: IOPS=402k, BW=49.1GiB/s (52.7GB/s)(982GiB/20002msec)
+ 128K write: IOPS=11.5k, BW=1433MiB/s (1503MB/s)(28.0GiB/20004msec)
+
+ - Without LOCALIO:
+ 4K read: IOPS=79.2k, BW=309MiB/s (324MB/s)(6188MiB/20003msec)
+ 4K write: IOPS=59.8k, BW=234MiB/s (245MB/s)(4671MiB/20002msec)
+ 128K read: IOPS=33.9k, BW=4234MiB/s (4440MB/s)(82.7GiB/20004msec)
+ 128K write: IOPS=11.5k, BW=1434MiB/s (1504MB/s)(28.0GiB/20011msec)
+
+fio for 20 secs with directio, qd of 8, 1 libaio thread:
+ - With LOCALIO:
+ 4K read: IOPS=230k, BW=898MiB/s (941MB/s)(17.5GiB/20001msec)
+ 4K write: IOPS=22.6k, BW=88.3MiB/s (92.6MB/s)(1766MiB/20001msec)
+ 128K read: IOPS=38.8k, BW=4855MiB/s (5091MB/s)(94.8GiB/20001msec)
+ 128K write: IOPS=11.4k, BW=1428MiB/s (1497MB/s)(27.9GiB/20001msec)
+
+ - Without LOCALIO:
+ 4K read: IOPS=77.1k, BW=301MiB/s (316MB/s)(6022MiB/20001msec)
+ 4K write: IOPS=32.8k, BW=128MiB/s (135MB/s)(2566MiB/20001msec)
+ 128K read: IOPS=24.4k, BW=3050MiB/s (3198MB/s)(59.6GiB/20001msec)
+ 128K write: IOPS=11.4k, BW=1430MiB/s (1500MB/s)(27.9GiB/20001msec)
+
+FAQ
+===
+
+1. What are the use cases for LOCALIO?
+
+ a. Workloads where the NFS client and server are on the same host
+ realize improved IO performance. In particular, it is common when
+ running containerised workloads for jobs to find themselves
+ running on the same host as the knfsd server being used for
+ storage.
+
+2. What are the requirements for LOCALIO?
+
+ a. Bypass use of the network RPC protocol as much as possible. This
+ includes bypassing XDR and RPC for open, read, write and commit
+ operations.
+ b. Allow client and server to autonomously discover if they are
+ running local to each other without making any assumptions about
+ the local network topology.
+ c. Support the use of containers by being compatible with relevant
+ namespaces (e.g. network, user, mount).
+ d. Support all versions of NFS. NFSv3 is of particular importance
+ because it has wide enterprise usage and pNFS flexfiles makes use
+ of it for the data path.
+
+3. Why doesn’t LOCALIO just compare IP addresses or hostnames when
+ deciding if the NFS client and server are co-located on the same
+ host?
+
+ Since one of the main use cases is containerised workloads, we cannot
+ assume that IP addresses will be shared between the client and
+ server. This sets up a requirement for a handshake protocol that
+ needs to go over the same connection as the NFS traffic in order to
+ identify that the client and the server really are running on the
+ same host. The handshake uses a secret that is sent over the wire,
+ and can be verified by both parties by comparing with a value stored
+ in shared kernel memory if they are truly co-located.
+
+4. Does LOCALIO improve pNFS flexfiles?
+
+ Yes, LOCALIO complements pNFS flexfiles by allowing it to take
+ advantage of NFS client and server locality. Policy that initiates
+ client IO as closely to the server where the data is stored naturally
+ benefits from the data path optimization LOCALIO provides.
+
+5. Why not develop a new pNFS layout to enable LOCALIO?
+
+ A new pNFS layout could be developed, but doing so would put the
+ onus on the server to somehow discover that the client is co-located
+ when deciding to hand out the layout.
+ There is value in a simpler approach (as provided by LOCALIO) that
+ allows the NFS client to negotiate and leverage locality without
+ requiring more elaborate modeling and discovery of such locality in a
+ more centralized manner.
+
+6. Why is having the client perform a server-side file OPEN, without
+ using RPC, beneficial? Is the benefit pNFS specific?
+
+ Avoiding the use of XDR and RPC for file opens is beneficial to
+ performance regardless of whether pNFS is used. Especially when
+ dealing with small files its best to avoid going over the wire
+ whenever possible, otherwise it could reduce or even negate the
+ benefits of avoiding the wire for doing the small file I/O itself.
+ Given LOCALIO's requirements the current approach of having the
+ client perform a server-side file open, without using RPC, is ideal.
+ If in the future requirements change then we can adapt accordingly.
+
+7. Why is LOCALIO only supported with UNIX Authentication (AUTH_UNIX)?
+
+ Strong authentication is usually tied to the connection itself. It
+ works by establishing a context that is cached by the server, and
+ that acts as the key for discovering the authorisation token, which
+ can then be passed to rpc.mountd to complete the authentication
+ process. On the other hand, in the case of AUTH_UNIX, the credential
+ that was passed over the wire is used directly as the key in the
+ upcall to rpc.mountd. This simplifies the authentication process, and
+ so makes AUTH_UNIX easier to support.
+
+8. How do export options that translate RPC user IDs behave for LOCALIO
+ operations (eg. root_squash, all_squash)?
+
+ Export options that translate user IDs are managed by nfsd_setuser()
+ which is called by nfsd_setuser_and_check_port() which is called by
+ __fh_verify(). So they get handled exactly the same way for LOCALIO
+ as they do for non-LOCALIO.
+
+9. How does LOCALIO make certain that object lifetimes are managed
+ properly given NFSD and NFS operate in different contexts?
+
+ See the detailed "NFS Client and Server Interlock" section below.
+
+RPC
+===
+
+The LOCALIO auxiliary RPC protocol consists of a single "UUID_IS_LOCAL"
+RPC method that allows the Linux NFS client to verify the local Linux
+NFS server can see the nonce (single-use UUID) the client generated and
+made available in nfs_common. This protocol isn't part of an IETF
+standard, nor does it need to be considering it is Linux-to-Linux
+auxiliary RPC protocol that amounts to an implementation detail.
+
+The UUID_IS_LOCAL method encodes the client generated uuid_t in terms of
+the fixed UUID_SIZE (16 bytes). The fixed size opaque encode and decode
+XDR methods are used instead of the less efficient variable sized
+methods.
+
+The RPC program number for the NFS_LOCALIO_PROGRAM is 400122 (as assigned
+by IANA, see https://www.iana.org/assignments/rpc-program-numbers/ ):
+Linux Kernel Organization 400122 nfslocalio
+
+The LOCALIO protocol spec in rpcgen syntax is::
+
+ /* raw RFC 9562 UUID */
+ #define UUID_SIZE 16
+ typedef u8 uuid_t<UUID_SIZE>;
+
+ program NFS_LOCALIO_PROGRAM {
+ version LOCALIO_V1 {
+ void
+ NULL(void) = 0;
+
+ void
+ UUID_IS_LOCAL(uuid_t) = 1;
+ } = 1;
+ } = 400122;
+
+LOCALIO uses the same transport connection as NFS traffic. As such,
+LOCALIO is not registered with rpcbind.
+
+NFS Common and Client/Server Handshake
+======================================
+
+fs/nfs_common/nfslocalio.c provides interfaces that enable an NFS client
+to generate a nonce (single-use UUID) and associated short-lived
+nfs_uuid_t struct, register it with nfs_common for subsequent lookup and
+verification by the NFS server and if matched the NFS server populates
+members in the nfs_uuid_t struct. The NFS client then uses nfs_common to
+transfer the nfs_uuid_t from its nfs_uuids to the nn->nfsd_serv
+clients_list from the nfs_common's uuids_list. See:
+fs/nfs/localio.c:nfs_local_probe()
+
+nfs_common's nfs_uuids list is the basis for LOCALIO enablement, as such
+it has members that point to nfsd memory for direct use by the client
+(e.g. 'net' is the server's network namespace, through it the client can
+access nn->nfsd_serv with proper rcu read access). It is this client
+and server synchronization that enables advanced usage and lifetime of
+objects to span from the host kernel's nfsd to per-container knfsd
+instances that are connected to nfs client's running on the same local
+host.
+
+NFS Client and Server Interlock
+===============================
+
+LOCALIO provides the nfs_uuid_t object and associated interfaces to
+allow proper network namespace (net-ns) and NFSD object refcounting.
+
+LOCALIO required the introduction and use of NFSD's percpu nfsd_net_ref
+to interlock nfsd_shutdown_net() and nfsd_open_local_fh(), to ensure
+each net-ns is not destroyed while in use by nfsd_open_local_fh(), and
+warrants a more detailed explanation:
+
+ nfsd_open_local_fh() uses nfsd_net_try_get() before opening its
+ nfsd_file handle and then the caller (NFS client) must drop the
+ reference for the nfsd_file and associated net-ns using
+ nfsd_file_put_local() once it has completed its IO.
+
+ This interlock working relies heavily on nfsd_open_local_fh() being
+ afforded the ability to safely deal with the possibility that the
+ NFSD's net-ns (and nfsd_net by association) may have been destroyed
+ by nfsd_destroy_serv() via nfsd_shutdown_net().
+
+This interlock of the NFS client and server has been verified to fix an
+easy to hit crash that would occur if an NFSD instance running in a
+container, with a LOCALIO client mounted, is shutdown. Upon restart of
+the container and associated NFSD, the client would go on to crash due
+to NULL pointer dereference that occurred due to the LOCALIO client's
+attempting to nfsd_open_local_fh() without having a proper reference on
+NFSD's net-ns.
+
+NFS Client issues IO instead of Server
+======================================
+
+Because LOCALIO is focused on protocol bypass to achieve improved IO
+performance, alternatives to the traditional NFS wire protocol (SUNRPC
+with XDR) must be provided to access the backing filesystem.
+
+See fs/nfs/localio.c:nfs_local_open_fh() and
+fs/nfsd/localio.c:nfsd_open_local_fh() for the interface that makes
+focused use of select nfs server objects to allow a client local to a
+server to open a file pointer without needing to go over the network.
+
+The client's fs/nfs/localio.c:nfs_local_open_fh() will call into the
+server's fs/nfsd/localio.c:nfsd_open_local_fh() and carefully access
+both the associated nfsd network namespace and nn->nfsd_serv in terms of
+RCU. If nfsd_open_local_fh() finds that the client no longer sees valid
+nfsd objects (be it struct net or nn->nfsd_serv) it returns -ENXIO
+to nfs_local_open_fh() and the client will try to reestablish the
+LOCALIO resources needed by calling nfs_local_probe() again. This
+recovery is needed if/when an nfsd instance running in a container were
+to reboot while a LOCALIO client is connected to it.
+
+Once the client has an open nfsd_file pointer it will issue reads,
+writes and commits directly to the underlying local filesystem (normally
+done by the nfs server). As such, for these operations, the NFS client
+is issuing IO to the underlying local filesystem that it is sharing with
+the NFS server. See: fs/nfs/localio.c:nfs_local_doio() and
+fs/nfs/localio.c:nfs_local_commit().
+
+With normal NFS that makes use of RPC to issue IO to the server, if an
+application uses O_DIRECT the NFS client will bypass the pagecache but
+the NFS server will not. The NFS server's use of buffered IO affords
+applications to be less precise with their alignment when issuing IO to
+the NFS client. But if all applications properly align their IO, LOCALIO
+can be configured to use end-to-end O_DIRECT semantics from the NFS
+client to the underlying local filesystem, that it is sharing with
+the NFS server, by setting the 'localio_O_DIRECT_semantics' nfs module
+parameter to Y, e.g.:
+
+ echo Y > /sys/module/nfs/parameters/localio_O_DIRECT_semantics
+
+Once enabled, it will cause LOCALIO to use end-to-end O_DIRECT semantics
+(but again, this may cause IO to fail if applications do not properly
+align their IO).
+
+Security
+========
+
+LOCALIO is only supported when UNIX-style authentication (AUTH_UNIX, aka
+AUTH_SYS) is used.
+
+Care is taken to ensure the same NFS security mechanisms are used
+(authentication, etc) regardless of whether LOCALIO or regular NFS
+access is used. The auth_domain established as part of the traditional
+NFS client access to the NFS server is also used for LOCALIO.
+
+Relative to containers, LOCALIO gives the client access to the network
+namespace the server has. This is required to allow the client to access
+the server's per-namespace nfsd_net struct. With traditional NFS, the
+client is afforded this same level of access (albeit in terms of the NFS
+protocol via SUNRPC). No other namespaces (user, mount, etc) have been
+altered or purposely extended from the server to the client.
+
+Module Parameters
+=================
+
+/sys/module/nfs/parameters/localio_enabled (bool)
+controls if LOCALIO is enabled, defaults to Y. If client and server are
+local but 'localio_enabled' is set to N then LOCALIO will not be used.
+
+/sys/module/nfs/parameters/localio_O_DIRECT_semantics (bool)
+controls if O_DIRECT extends down to the underlying filesystem, defaults
+to N. Application IO must be logical blocksize aligned, otherwise
+O_DIRECT will fail.
+
+/sys/module/nfsv3/parameters/nfs3_localio_probe_throttle (uint)
+controls if NFSv3 read and write IOs will trigger (re)enabling of
+LOCALIO every N (nfs3_localio_probe_throttle) IOs, defaults to 0
+(disabled). Must be power-of-2, admin keeps all the pieces if they
+misconfigure (too low a value or non-power-of-2).
+
+Testing
+=======
+
+The LOCALIO auxiliary protocol and associated NFS LOCALIO read, write
+and commit access have proven stable against various test scenarios:
+
+- Client and server both on the same host.
+
+- All permutations of client and server support enablement for both
+ local and remote client and server.
+
+- Testing against NFS storage products that don't support the LOCALIO
+ protocol was also performed.
+
+- Client on host, server within a container (for both v3 and v4.2).
+ The container testing was in terms of podman managed containers and
+ includes successful container stop/restart scenario.
+
+- Formalizing these test scenarios in terms of existing test
+ infrastructure is on-going. Initial regular coverage is provided in
+ terms of ktest running xfstests against a LOCALIO-enabled NFS loopback
+ mount configuration, and includes lockdep and KASAN coverage, see:
+ https://evilpiepirate.org/~testdashboard/ci?user=snitzer&branch=snitm-nfs-next
+ https://github.com/koverstreet/ktest
+
+- Various kdevops testing (in terms of "Chuck's BuildBot") has been
+ performed to regularly verify the LOCALIO changes haven't caused any
+ regressions to non-LOCALIO NFS use cases.
+
+- All of Hammerspace's various sanity tests pass with LOCALIO enabled
+ (this includes numerous pNFS and flexfiles tests).
diff --git a/Documentation/filesystems/nfs/nfsd-io-modes.rst b/Documentation/filesystems/nfs/nfsd-io-modes.rst
new file mode 100644
index 000000000000..0fd6e82478fe
--- /dev/null
+++ b/Documentation/filesystems/nfs/nfsd-io-modes.rst
@@ -0,0 +1,153 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+NFSD IO MODES
+=============
+
+Overview
+========
+
+NFSD has historically always used buffered IO when servicing READ and
+WRITE operations. BUFFERED is NFSD's default IO mode, but it is possible
+to override that default to use either DONTCACHE or DIRECT IO modes.
+
+Experimental NFSD debugfs interfaces are available to allow the NFSD IO
+mode used for READ and WRITE to be configured independently. See both:
+
+- /sys/kernel/debug/nfsd/io_cache_read
+- /sys/kernel/debug/nfsd/io_cache_write
+
+The default value for both io_cache_read and io_cache_write reflects
+NFSD's default IO mode (which is NFSD_IO_BUFFERED=0).
+
+Based on the configured settings, NFSD's IO will either be:
+
+- cached using page cache (NFSD_IO_BUFFERED=0)
+- cached but removed from page cache on completion (NFSD_IO_DONTCACHE=1)
+- not cached stable_how=NFS_UNSTABLE (NFSD_IO_DIRECT=2)
+
+To set an NFSD IO mode, write a supported value (0 - 2) to the
+corresponding IO operation's debugfs interface, e.g.::
+
+ echo 2 > /sys/kernel/debug/nfsd/io_cache_read
+ echo 2 > /sys/kernel/debug/nfsd/io_cache_write
+
+To check which IO mode NFSD is using for READ or WRITE, simply read the
+corresponding IO operation's debugfs interface, e.g.::
+
+ cat /sys/kernel/debug/nfsd/io_cache_read
+ cat /sys/kernel/debug/nfsd/io_cache_write
+
+If you experiment with NFSD's IO modes on a recent kernel and have
+interesting results, please report them to linux-nfs@vger.kernel.org
+
+NFSD DONTCACHE
+==============
+
+DONTCACHE offers a hybrid approach to servicing IO that aims to offer
+the benefits of using DIRECT IO without any of the strict alignment
+requirements that DIRECT IO imposes. To achieve this buffered IO is used
+but the IO is flagged to "drop behind" (meaning associated pages are
+dropped from the page cache) when IO completes.
+
+DONTCACHE aims to avoid what has proven to be a fairly significant
+limition of Linux's memory management subsystem if/when large amounts of
+data is infrequently accessed (e.g. read once _or_ written once but not
+read until much later). Such use-cases are particularly problematic
+because the page cache will eventually become a bottleneck to servicing
+new IO requests.
+
+For more context on DONTCACHE, please see these Linux commit headers:
+
+- Overview: 9ad6344568cc3 ("mm/filemap: change filemap_create_folio()
+ to take a struct kiocb")
+- for READ: 8026e49bff9b1 ("mm/filemap: add read support for
+ RWF_DONTCACHE")
+- for WRITE: 974c5e6139db3 ("xfs: flag as supporting FOP_DONTCACHE")
+
+NFSD_IO_DONTCACHE will fall back to NFSD_IO_BUFFERED if the underlying
+filesystem doesn't indicate support by setting FOP_DONTCACHE.
+
+NFSD DIRECT
+===========
+
+DIRECT IO doesn't make use of the page cache, as such it is able to
+avoid the Linux memory management's page reclaim scalability problems
+without resorting to the hybrid use of page cache that DONTCACHE does.
+
+Some workloads benefit from NFSD avoiding the page cache, particularly
+those with a working set that is significantly larger than available
+system memory. The pathological worst-case workload that NFSD DIRECT has
+proven to help most is: NFS client issuing large sequential IO to a file
+that is 2-3 times larger than the NFS server's available system memory.
+The reason for such improvement is NFSD DIRECT eliminates a lot of work
+that the memory management subsystem would otherwise be required to
+perform (e.g. page allocation, dirty writeback, page reclaim). When
+using NFSD DIRECT, kswapd and kcompactd are no longer commanding CPU
+time trying to find adequate free pages so that forward IO progress can
+be made.
+
+The performance win associated with using NFSD DIRECT was previously
+discussed on linux-nfs, see:
+https://lore.kernel.org/linux-nfs/aEslwqa9iMeZjjlV@kernel.org/
+
+But in summary:
+
+- NFSD DIRECT can significantly reduce memory requirements
+- NFSD DIRECT can reduce CPU load by avoiding costly page reclaim work
+- NFSD DIRECT can offer more deterministic IO performance
+
+As always, your mileage may vary and so it is important to carefully
+consider if/when it is beneficial to make use of NFSD DIRECT. When
+assessing comparative performance of your workload please be sure to log
+relevant performance metrics during testing (e.g. memory usage, cpu
+usage, IO performance). Using perf to collect perf data that may be used
+to generate a "flamegraph" for work Linux must perform on behalf of your
+test is a really meaningful way to compare the relative health of the
+system and how switching NFSD's IO mode changes what is observed.
+
+If NFSD_IO_DIRECT is specified by writing 2 (or 3 and 4 for WRITE) to
+NFSD's debugfs interfaces, ideally the IO will be aligned relative to
+the underlying block device's logical_block_size. Also the memory buffer
+used to store the READ or WRITE payload must be aligned relative to the
+underlying block device's dma_alignment.
+
+But NFSD DIRECT does handle misaligned IO in terms of O_DIRECT as best
+it can:
+
+Misaligned READ:
+ If NFSD_IO_DIRECT is used, expand any misaligned READ to the next
+ DIO-aligned block (on either end of the READ). The expanded READ is
+ verified to have proper offset/len (logical_block_size) and
+ dma_alignment checking.
+
+Misaligned WRITE:
+ If NFSD_IO_DIRECT is used, split any misaligned WRITE into a start,
+ middle and end as needed. The large middle segment is DIO-aligned
+ and the start and/or end are misaligned. Buffered IO is used for the
+ misaligned segments and O_DIRECT is used for the middle DIO-aligned
+ segment. DONTCACHE buffered IO is _not_ used for the misaligned
+ segments because using normal buffered IO offers significant RMW
+ performance benefit when handling streaming misaligned WRITEs.
+
+Tracing:
+ The nfsd_read_direct trace event shows how NFSD expands any
+ misaligned READ to the next DIO-aligned block (on either end of the
+ original READ, as needed).
+
+ This combination of trace events is useful for READs::
+
+ echo 1 > /sys/kernel/tracing/events/nfsd/nfsd_read_vector/enable
+ echo 1 > /sys/kernel/tracing/events/nfsd/nfsd_read_direct/enable
+ echo 1 > /sys/kernel/tracing/events/nfsd/nfsd_read_io_done/enable
+ echo 1 > /sys/kernel/tracing/events/xfs/xfs_file_direct_read/enable
+
+ The nfsd_write_direct trace event shows how NFSD splits a given
+ misaligned WRITE into a DIO-aligned middle segment.
+
+ This combination of trace events is useful for WRITEs::
+
+ echo 1 > /sys/kernel/tracing/events/nfsd/nfsd_write_opened/enable
+ echo 1 > /sys/kernel/tracing/events/nfsd/nfsd_write_direct/enable
+ echo 1 > /sys/kernel/tracing/events/nfsd/nfsd_write_io_done/enable
+ echo 1 > /sys/kernel/tracing/events/xfs/xfs_file_direct_write/enable
diff --git a/Documentation/filesystems/nfs/nfsd-maintainer-entry-profile.rst b/Documentation/filesystems/nfs/nfsd-maintainer-entry-profile.rst
new file mode 100644
index 000000000000..4d6b57dbab2a
--- /dev/null
+++ b/Documentation/filesystems/nfs/nfsd-maintainer-entry-profile.rst
@@ -0,0 +1,547 @@
+NFSD Maintainer Entry Profile
+=============================
+
+A Maintainer Entry Profile supplements the top-level process
+documents (found in Documentation/process/) with customs that are
+specific to a subsystem and its maintainers. A contributor may use
+this document to set their expectations and avoid common mistakes.
+A maintainer may use these profiles to look across subsystems for
+opportunities to converge on best common practices.
+
+Overview
+--------
+The Network File System (NFS) is a standardized family of network
+protocols that enable access to files across a set of network-
+connected peer hosts. Applications on NFS clients access files that
+reside on file systems that are shared by NFS servers. A single
+network peer can act as both an NFS client and an NFS server.
+
+NFSD refers to the NFS server implementation included in the Linux
+kernel. An in-kernel NFS server has fast access to files stored
+in file systems local to that server. NFSD can share files stored
+on most of the file system types native to Linux, including xfs,
+ext4, btrfs, and tmpfs.
+
+Mailing list
+------------
+The linux-nfs@vger.kernel.org mailing list is a public list. Its
+purpose is to enable collaboration among developers working on the
+Linux NFS stack, both client and server. It is not a place for
+conversations that are not related directly to the Linux NFS stack.
+
+The linux-nfs mailing list is archived on `lore.kernel.org <https://lore.kernel.org/linux-nfs/>`_.
+
+The Linux NFS community does not have any chat room.
+
+Reporting bugs
+--------------
+If you experience an NFSD-related bug on a distribution-built
+kernel, please start by working with your Linux distributor.
+
+Bug reports against upstream Linux code bases are welcome on the
+linux-nfs@vger.kernel.org mailing list, where some active triage
+can be done. NFSD bugs may also be reported in the Linux kernel
+community's bugzilla at:
+
+ https://bugzilla.kernel.org
+
+Please file NFSD-related bugs under the "Filesystems/NFSD"
+component. In general, including as much detail as possible is a
+good start, including pertinent system log messages from both
+the client and server.
+
+User space software related to NFSD, such as mountd or the exportfs
+command, is contained in the nfs-utils package. Report problems
+with those components to linux-nfs@vger.kernel.org. You might be
+directed to move the report to a specific bug tracker.
+
+Contributor's Guide
+-------------------
+
+Standards compliance
+~~~~~~~~~~~~~~~~~~~~
+The priority is for NFSD to interoperate fully with the Linux NFS
+client. We also test against other popular NFS client implementa-
+tions regularly at NFS bake-a-thon events (also known as plug-
+fests). Non-Linux NFS clients are not part of upstream NFSD CI/CD.
+
+The NFSD community strives to provide an NFS server implementation
+that interoperates with all standards-compliant NFS client
+implementations. This is done by staying as close as is sensible to
+the normative mandates in the IETF's published NFS, RPC, and GSS-API
+standards.
+
+It is always useful to reference an RFC and section number in a code
+comment where behavior deviates from the standard (and even when the
+behavior is compliant but the implementation is obfuscatory).
+
+On the rare occasion when a deviation from standard-mandated
+behavior is needed, brief documentation of the use case or
+deficiencies in the standard is a required part of in-code
+documentation.
+
+Care must always be taken to avoid leaking local error codes (ie,
+errnos) to clients of NFSD. A proper NFS status code is always
+required in NFS protocol replies.
+
+NFSD administrative interfaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+NFSD administrative interfaces include:
+
+- an NFSD or SUNRPC module parameter
+
+- export options in /etc/exports
+
+- files under /proc/fs/nfsd/ or /proc/sys/sunrpc/
+
+- the NFSD netlink protocol
+
+Frequently, a request is made to introduce or modify one of NFSD's
+traditional administrative interfaces. Certainly it is technically
+easy to introduce a new administrative setting. However, there are
+good reasons why the NFSD maintainers prefer to leave that as a last
+resort:
+
+- As with any API, administrative interfaces are difficult to get
+ right.
+
+- Once they are documented and have a legacy of use, administrative
+ interfaces become difficult to modify or remove.
+
+- Every new administrative setting multiplies the NFSD test matrix.
+
+- The cost of one administrative interface is incremental, but costs
+ add up across all of the existing interfaces.
+
+It is often better for everyone if effort is made up front to
+understanding the underlying requirement of the new setting, and
+then trying to make it tune itself (or to become otherwise
+unnecessary).
+
+If a new setting is indeed necessary, first consider adding it to
+the NFSD netlink protocol. Or if it doesn't need to be a reliable
+long term user space feature, it can be added to NFSD's menagerie of
+experimental settings which reside under /sys/kernel/debug/nfsd/ .
+
+Field observability
+~~~~~~~~~~~~~~~~~~~
+NFSD employs several different mechanisms for observing operation,
+including counters, printks, WARNings, and static trace points. Each
+have their strengths and weaknesses. Contributors should select the
+most appropriate tool for their task.
+
+- BUG must be avoided if at all possible, as it will frequently
+ result in a full system crash.
+
+- WARN is appropriate only when a full stack trace is useful.
+
+- printk can show detailed information. These must not be used
+ in code paths where they can be triggered repeatedly by remote
+ users.
+
+- dprintk can show detailed information, but can be enabled only
+ in pre-set groups. The overhead of emitting output makes dprintk
+ inappropriate for frequent operations like I/O.
+
+- Counters are always on, but provide little information about
+ individual events other than how frequently they occur.
+
+- static trace points can be enabled individually or in groups
+ (via a glob). These are generally low overhead, and thus are
+ favored for use in hot paths.
+
+- dynamic tracing, such as kprobes or eBPF, are quite flexible but
+ cannot be used in certain environments (eg, full kernel lock-
+ down).
+
+Testing
+~~~~~~~
+The kdevops project
+
+ https://github.com/linux-kdevops/kdevops
+
+contains several NFS-specific workflows, as well as the community
+standard fstests suite. These workflows are based on open source
+testing tools such as ltp and fio. Contributors are encouraged to
+use these tools without kdevops, or contributors should install and
+use kdevops themselves to verify their patches before submission.
+
+Coding style
+~~~~~~~~~~~~
+Follow the coding style preferences described in
+
+ Documentation/process/coding-style.rst
+
+with the following exceptions:
+
+- Add new local variables to a function in reverse Christmas tree
+ order
+
+- Use the kdoc comment style for
+ + non-static functions
+ + static inline functions
+ + static functions that are callbacks/virtual functions
+
+- All new function names start with ``nfsd_`` for non-NFS-version-
+ specific functions.
+
+- New function names that are specific to NFSv2 or NFSv3, or are
+ used by all minor versions of NFSv4, use ``nfsdN_`` where N is
+ the version.
+
+- New function names specific to an NFSv4 minor version can be
+ named with ``nfsd4M_`` where M is the minor version.
+
+Patch preparation
+~~~~~~~~~~~~~~~~~
+Read and follow all guidelines in
+
+ Documentation/process/submitting-patches.rst
+
+Use tagging to identify all patch authors. However, reviewers and
+testers should be added by replying to the email patch submission.
+Email is extensively used in order to publicly archive review and
+testing attributions. These tags are automatically inserted into
+your patches when they are applied.
+
+The code in the body of the diff already shows /what/ is being
+changed. Thus it is not necessary to repeat that in the patch
+description. Instead, the description should contain one or more
+of:
+
+- A brief problem statement ("what is this patch trying to fix?")
+ with a root-cause analysis.
+
+- End-user visible symptoms or items that a support engineer might
+ use to search for the patch, like stack traces.
+
+- A brief explanation of why the patch is the best way to address
+ the problem.
+
+- Any context that reviewers might need to understand the changes
+ made by the patch.
+
+- Any relevant benchmarking results, and/or functional test results.
+
+As detailed in Documentation/process/submitting-patches.rst,
+identify the point in history that the issue being addressed was
+introduced by using a Fixes: tag.
+
+Mention in the patch description if that point in history cannot be
+determined -- that is, no Fixes: tag can be provided. In this case,
+please make it clear to maintainers whether an LTS backport is
+needed even though there is no Fixes: tag.
+
+The NFSD maintainers prefer to add stable tagging themselves, after
+public discussion in response to the patch submission. Contributors
+may suggest stable tagging, but be aware that many version
+management tools add such stable Cc's when you post your patches.
+Don't add "Cc: stable" unless you are absolutely sure the patch
+needs to go to stable during the initial submission process.
+
+Patch submission
+~~~~~~~~~~~~~~~~
+Patches to NFSD are submitted via the kernel's email-based review
+process that is common to most other kernel subsystems.
+
+Just before each submission, rebase your patch or series on the
+nfsd-testing branch at
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
+
+The NFSD subsystem is maintained separately from the Linux in-kernel
+NFS client. The NFSD maintainers do not normally take submissions
+for client changes, nor can they respond authoritatively to bug
+reports or feature requests for NFS client code.
+
+This means that contributors might be asked to resubmit patches if
+they were emailed to the incorrect set of maintainers and reviewers.
+This is not a rejection, but simply a correction of the submission
+process.
+
+When in doubt, consult the NFSD entry in the MAINTAINERS file to
+see which files and directories fall under the NFSD subsystem.
+
+The proper set of email addresses for NFSD patches are:
+
+To: the NFSD maintainers and reviewers listed in MAINTAINERS
+Cc: linux-nfs@vger.kernel.org and optionally linux-kernel@
+
+If there are other subsystems involved in the patches (for example
+MM or RDMA) their primary mailing list address can be included in
+the Cc: field. Other contributors and interested parties may be
+included there as well.
+
+In general we prefer that contributors use common patch email tools
+such as "git send-email" or "stg email format/send", which tend to
+get the details right without a lot of fuss.
+
+A series consisting of a single patch is not required to have a
+cover letter. However, a cover letter can be included if there is
+substantial context that is not appropriate to include in the
+patch description.
+
+Please note that, with an e-mail based submission process, series
+cover letters are not part of the work that is committed to the
+kernel source code base or its commit history. Therefore always try
+to keep pertinent information in the patch descriptions.
+
+Design documentation is welcome, but as cover letters are not
+preserved, a perhaps better option is to include a patch that adds
+such documentation under Documentation/filesystems/nfs/.
+
+Reviewers will ask about test coverage and what use cases the
+patches are expected to address. Please be prepared to answer these
+questions.
+
+Review comments from maintainers might be politely stated, but in
+general, these are not optional to address when they are actionable.
+If necessary, the maintainers retain the right to not apply patches
+when contributors refuse to address reasonable requests.
+
+Post changes to kernel source code and user space source code as
+separate series. You can connect the two series with comments in
+your cover letters.
+
+Generally the NFSD maintainers ask for a reposts even for simple
+modifications in order to publicly archive the request and the
+resulting repost before it is pulled into the NFSD trees. This
+also enables us to rebuild a patch series quickly without missing
+changes that might have been discussed via email.
+
+Avoid frequently reposting large series with only small changes. As
+a rule of thumb, posting substantial changes more than once a week
+will result in reviewer overload.
+
+Remember, there are only a handful of subsystem maintainers and
+reviewers, but potentially many sources of contributions. The
+maintainers and reviewers, therefore, are always the less scalable
+resource. Be kind to your friendly neighborhood maintainer.
+
+Patch Acceptance
+~~~~~~~~~~~~~~~~
+There isn't a formal review process for NFSD, but we like to see
+at least two Reviewed-by: notices for patches that are more than
+simple clean-ups. Reviews are done in public on
+linux-nfs@vger.kernel.org and are archived on lore.kernel.org.
+
+Currently the NFSD patch queues are maintained in branches here:
+
+ https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
+
+The NFSD maintainers apply patches initially to the nfsd-testing
+branch, which is always open to new submissions. Patches can be
+applied while review is ongoing. nfsd-testing is a topic branch,
+so it can change frequently, it will be rebased, and your patch
+might get dropped if there is a problem with it.
+
+Generally a script-generated "thank you" email will indicate when
+your patch has been added to the nfsd-testing branch. You can track
+the progress of your patch using the linux-nfs patchworks instance:
+
+ https://patchwork.kernel.org/project/linux-nfs/list/
+
+While your patch is in nfsd-testing, it is exposed to a variety of
+test environments, including community zero-day bots, static
+analysis tools, and NFSD continuous integration testing. The soak
+period is three to four weeks.
+
+Each patch that survives in nfsd-testing for the soak period without
+changes is moved to the nfsd-next branch.
+
+The nfsd-next branch is automatically merged into linux-next and
+fs-next on a nightly basis.
+
+Patches that survive in nfsd-next are included in the next NFSD
+merge window pull request. These windows typically occur once every
+63 days (nine weeks).
+
+When the upstream merge window closes, the nfsd-next branch is
+renamed nfsd-fixes, and a new nfsd-next branch is created, based on
+the upstream -rc1 tag.
+
+Fixes that are destined for an upstream -rc release also run the
+nfsd-testing gauntlet, but are then applied to the nfsd-fixes
+branch. That branch is made available for Linus to pull after a
+short time. In order to limit the risk of introducing regressions,
+we limit such fixes to emergency situations or fixes to breakage
+that occurred during the most recent upstream merge.
+
+Please make it clear when submitting an emergency patch that
+immediate action (either application to -rc or LTS backport) is
+needed.
+
+Sensitive patch submissions and bug reports
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+CVEs are generated by specific members of the Linux kernel community
+and several external entities. The Linux NFS community does not emit
+or assign CVEs. CVEs are assigned after an issue and its fix are
+known.
+
+However, the NFSD maintainers sometimes receive sensitive security
+reports, and at times these are significant enough to need to be
+embargoed. In such rare cases, fixes can be developed and reviewed
+out of the public eye.
+
+Please be aware that many version management tools add the stable
+Cc's when you post your patches. This is generally a nuisance, but
+it can result in outing an embargoed security issue accidentally.
+Don't add "Cc: stable" unless you are absolutely sure the patch
+needs to go to stable@ during the initial submission process.
+
+Patches that are merged without ever appearing on any list, and
+which carry a Reported-by: or Fixes: tag are detected as suspicious
+by security-focused people. We encourage that, after any private
+review, security-sensitive patches should be posted to linux-nfs@
+for the usual public review, archiving, and test period.
+
+LLM-generated submissions
+~~~~~~~~~~~~~~~~~~~~~~~~~
+The Linux kernel community as a whole is still exploring the new
+world of LLM-generated code. The NFSD maintainers will entertain
+submission of patches that are partially or wholly generated by
+LLM-based development tools. Such submissions are held to the
+same standards as submissions created entirely by human authors:
+
+- The human contributor identifies themselves via a Signed-off-by:
+ tag. This tag counts as a DoC.
+
+- The human contributor is solely responsible for code provenance
+ and any contamination by inadvertently-included code with a
+ conflicting license, as usual.
+
+- The human contributor must be able to answer and address review
+ questions. A patch description such as "This fixed my problem
+ but I don't know why" is not acceptable.
+
+- The contribution is subjected to the same test regimen as all
+ other submissions.
+
+- An indication (via a Generated-by: tag or otherwise) that the
+ contribution is LLM-generated is not required.
+
+It is easy to address review comments and fix requests in LLM
+generated code. So easy, in fact, that it becomes tempting to repost
+refreshed code immediately. Please resist that temptation.
+
+As always, please avoid reposting series revisions more than once
+every 24 hours.
+
+Clean-up patches
+~~~~~~~~~~~~~~~~
+The NFSD maintainers discourage patches which perform simple clean-
+ups, which are not in the context of other work. For example:
+
+* Addressing ``checkpatch.pl`` warnings after merge
+* Addressing :ref:`Local variable ordering<rcs>` issues
+* Addressing long-standing whitespace damage
+
+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 encouraged.
+
+Stable and LTS support
+----------------------
+Upstream NFSD continuous integration testing runs against LTS trees
+whenever they are updated.
+
+Please indicate when a patch containing a fix needs to be considered
+for LTS kernels, either via a Fixes: tag or explicit mention.
+
+Feature requests
+----------------
+There is no one way to make an official feature request, but
+discussion about the request should eventually make its way to
+the linux-nfs@vger.kernel.org mailing list for public review by
+the community.
+
+Subsystem boundaries
+~~~~~~~~~~~~~~~~~~~~
+NFSD itself is not much more than a protocol engine. This means its
+primary responsibility is to translate the NFS protocol into API
+calls in the Linux kernel. For example, NFSD is not responsible for
+knowing exactly how bytes or file attributes are managed on a block
+device. It relies on other kernel subsystems for that.
+
+If the subsystems on which NFSD relies do not implement a particular
+feature, even if the standard NFS protocols do support that feature,
+that usually means NFSD cannot provide that feature without
+substantial development work in other areas of the kernel.
+
+Specificity
+~~~~~~~~~~~
+Feature requests can come from anywhere, and thus can often be
+nebulous. A requester might not understand what a "use case" or
+"user story" is. These descriptive paradigms are often used by
+developers and architects to understand what is required of a
+design, but are terms of art in the software trade, not used in
+the everyday world.
+
+In order to prevent contributors and maintainers from becoming
+overwhelmed, we won't be afraid of saying "no" politely to
+underspecified requests.
+
+Community roles and their authority
+-----------------------------------
+The purpose of Linux subsystem communities is to provide expertise
+and active stewardship of a narrow set of source files in the Linux
+kernel. This can include managing user space tooling as well.
+
+To contextualize the structure of the Linux NFS community that
+is responsible for stewardship of the NFS server code base, we
+define the community roles here.
+
+- **Contributor** : Anyone who submits a code change, bug fix,
+ recommendation, documentation fix, and so on. A contributor can
+ submit regularly or infrequently.
+
+- **Outside Contributor** : A contributor who is not a regular actor
+ in the Linux NFS community. This can mean someone who contributes
+ to other parts of the kernel, or someone who just noticed a
+ misspelling in a comment and sent a patch.
+
+- **Reviewer** : Someone who is named in the MAINTAINERS file as a
+ reviewer is an area expert who can request changes to contributed
+ code, and expects that contributors will address the request.
+
+- **External Reviewer** : Someone who is not named in the
+ MAINTAINERS file as a reviewer, but who is an area expert.
+ Examples include Linux kernel contributors with networking,
+ security, or persistent storage expertise, or developers who
+ contribute primarily to other NFS implementations.
+
+One or more people will take on the following roles. These people
+are often generically referred to as "maintainers", and are
+identified in the MAINTAINERS file with the "M:" tag under the NFSD
+subsystem.
+
+- **Upstream Release Manager** : This role is responsible for
+ curating contributions into a branch, reviewing test results, and
+ then sending a pull request during merge windows. There is a
+ trust relationship between the release manager and Linus.
+
+- **Bug Triager** : Someone who is a first responder to bug reports
+ submitted to the linux-nfs mailing list or bug trackers, and helps
+ troubleshoot and identify next steps.
+
+- **Security Lead** : The security lead handles contacts from the
+ security community to resolve immediate issues, as well as dealing
+ with long-term security issues such as supply chain concerns. For
+ upstream, that's usually whether contributions violate licensing
+ or other intellectual property agreements.
+
+- **Testing Lead** : The testing lead builds and runs the test
+ infrastructure for the subsystem. The testing lead may ask for
+ patches to be dropped because of ongoing high defect rates.
+
+- **LTS Maintainer** : The LTS maintainer is responsible for managing
+ the Fixes: and Cc: stable annotations on patches, and seeing that
+ patches that cannot be automatically applied to LTS kernels get
+ proper manual backports as necessary.
+
+- **Community Manager** : This umpire role can be asked to call balls
+ and strikes during conflicts, but is also responsible for ensuring
+ the health of the relationships within the community and for
+ facilitating discussions on long-term topics such as how to manage
+ growing technical debt.
diff --git a/Documentation/filesystems/nfs/reexport.rst b/Documentation/filesystems/nfs/reexport.rst
index ff9ae4a46530..044be965d75e 100644
--- a/Documentation/filesystems/nfs/reexport.rst
+++ b/Documentation/filesystems/nfs/reexport.rst
@@ -26,9 +26,13 @@ Reboot recovery
---------------
The NFS protocol's normal reboot recovery mechanisms don't work for the
-case when the reexport server reboots. Clients will lose any locks
-they held before the reboot, and further IO will result in errors.
-Closing and reopening files should clear the errors.
+case when the reexport server reboots because the source server has not
+rebooted, and so it is not in grace. Since the source server is not in
+grace, it cannot offer any guarantees that the file won't have been
+changed between the locks getting lost and any attempt to recover them.
+The same applies to delegations and any associated locks. Clients are
+not allowed to get file locks or delegations from a reexport server, any
+attempts will fail with operation not supported.
Filehandle limits
-----------------
diff --git a/Documentation/filesystems/nfs/rpc-cache.rst b/Documentation/filesystems/nfs/rpc-cache.rst
index bb164eea969b..339efd75016a 100644
--- a/Documentation/filesystems/nfs/rpc-cache.rst
+++ b/Documentation/filesystems/nfs/rpc-cache.rst
@@ -78,7 +78,7 @@ Creating a Cache
include taking references to shared objects.
void update(struct cache_head \*orig, struct cache_head \*new)
- Set the 'content' fileds in 'new' from 'orig'.
+ Set the 'content' fields in 'new' from 'orig'.
int cache_show(struct seq_file \*m, struct cache_detail \*cd, struct cache_head \*h)
Optional. Used to provide a /proc file that lists the
diff --git a/Documentation/filesystems/nfs/rpc-server-gss.rst b/Documentation/filesystems/nfs/rpc-server-gss.rst
index ccaea9e7cea2..5c1a1c58fc27 100644
--- a/Documentation/filesystems/nfs/rpc-server-gss.rst
+++ b/Documentation/filesystems/nfs/rpc-server-gss.rst
@@ -29,7 +29,7 @@ The Linux kernel, at the moment, supports only the KRB5 mechanism, and
depends on GSSAPI extensions that are KRB5 specific.
GSSAPI is a complex library, and implementing it completely in kernel is
-unwarranted. However GSSAPI operations are fundementally separable in 2
+unwarranted. However GSSAPI operations are fundamentally separable in 2
parts:
- initial context establishment
diff --git a/Documentation/filesystems/nilfs2.rst b/Documentation/filesystems/nilfs2.rst
index 6c49f04e9e0a..e3a5c8977f2c 100644
--- a/Documentation/filesystems/nilfs2.rst
+++ b/Documentation/filesystems/nilfs2.rst
@@ -231,7 +231,7 @@ file structures (nilfs_finfo), and per block structures (nilfs_binfo)::
The logs include regular files, directory files, symbolic link files
-and several meta data files. The mata data files are the files used
+and several meta data files. The meta data files are the files used
to maintain file system meta data. The current version of NILFS2 uses
the following meta data files::
diff --git a/Documentation/filesystems/ntfs.rst b/Documentation/filesystems/ntfs.rst
deleted file mode 100644
index 5bb093a26485..000000000000
--- a/Documentation/filesystems/ntfs.rst
+++ /dev/null
@@ -1,466 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-================================
-The Linux NTFS filesystem driver
-================================
-
-
-.. Table of contents
-
- - Overview
- - Web site
- - Features
- - Supported mount options
- - Known bugs and (mis-)features
- - Using NTFS volume and stripe sets
- - The Device-Mapper driver
- - The Software RAID / MD driver
- - Limitations when using the MD driver
-
-
-Overview
-========
-
-Linux-NTFS comes with a number of user-space programs known as ntfsprogs.
-These include mkntfs, a full-featured ntfs filesystem format utility,
-ntfsundelete used for recovering files that were unintentionally deleted
-from an NTFS volume and ntfsresize which is used to resize an NTFS partition.
-See the web site for more information.
-
-To mount an NTFS 1.2/3.x (Windows NT4/2000/XP/2003) volume, use the file
-system type 'ntfs'. The driver currently supports read-only mode (with no
-fault-tolerance, encryption or journalling) and very limited, but safe, write
-support.
-
-For fault tolerance and raid support (i.e. volume and stripe sets), you can
-use the kernel's Software RAID / MD driver. See section "Using Software RAID
-with NTFS" for details.
-
-
-Web site
-========
-
-There is plenty of additional information on the linux-ntfs web site
-at http://www.linux-ntfs.org/
-
-The web site has a lot of additional information, such as a comprehensive
-FAQ, documentation on the NTFS on-disk format, information on the Linux-NTFS
-userspace utilities, etc.
-
-
-Features
-========
-
-- This is a complete rewrite of the NTFS driver that used to be in the 2.4 and
- earlier kernels. This new driver implements NTFS read support and is
- functionally equivalent to the old ntfs driver and it also implements limited
- write support. The biggest limitation at present is that files/directories
- cannot be created or deleted. See below for the list of write features that
- are so far supported. Another limitation is that writing to compressed files
- is not implemented at all. Also, neither read nor write access to encrypted
- files is so far implemented.
-- The new driver has full support for sparse files on NTFS 3.x volumes which
- the old driver isn't happy with.
-- The new driver supports execution of binaries due to mmap() now being
- supported.
-- The new driver supports loopback mounting of files on NTFS which is used by
- some Linux distributions to enable the user to run Linux from an NTFS
- partition by creating a large file while in Windows and then loopback
- mounting the file while in Linux and creating a Linux filesystem on it that
- is used to install Linux on it.
-- A comparison of the two drivers using::
-
- time find . -type f -exec md5sum "{}" \;
-
- run three times in sequence with each driver (after a reboot) on a 1.4GiB
- NTFS partition, showed the new driver to be 20% faster in total time elapsed
- (from 9:43 minutes on average down to 7:53). The time spent in user space
- was unchanged but the time spent in the kernel was decreased by a factor of
- 2.5 (from 85 CPU seconds down to 33).
-- The driver does not support short file names in general. For backwards
- compatibility, we implement access to files using their short file names if
- they exist. The driver will not create short file names however, and a
- rename will discard any existing short file name.
-- The new driver supports exporting of mounted NTFS volumes via NFS.
-- The new driver supports async io (aio).
-- The new driver supports fsync(2), fdatasync(2), and msync(2).
-- The new driver supports readv(2) and writev(2).
-- The new driver supports access time updates (including mtime and ctime).
-- The new driver supports truncate(2) and open(2) with O_TRUNC. But at present
- only very limited support for highly fragmented files, i.e. ones which have
- their data attribute split across multiple extents, is included. Another
- limitation is that at present truncate(2) will never create sparse files,
- since to mark a file sparse we need to modify the directory entry for the
- file and we do not implement directory modifications yet.
-- The new driver supports write(2) which can both overwrite existing data and
- extend the file size so that you can write beyond the existing data. Also,
- writing into sparse regions is supported and the holes are filled in with
- clusters. But at present only limited support for highly fragmented files,
- i.e. ones which have their data attribute split across multiple extents, is
- included. Another limitation is that write(2) will never create sparse
- files, since to mark a file sparse we need to modify the directory entry for
- the file and we do not implement directory modifications yet.
-
-Supported mount options
-=======================
-
-In addition to the generic mount options described by the manual page for the
-mount command (man 8 mount, also see man 5 fstab), the NTFS driver supports the
-following mount options:
-
-======================= =======================================================
-iocharset=name Deprecated option. Still supported but please use
- nls=name in the future. See description for nls=name.
-
-nls=name Character set to use when returning file names.
- Unlike VFAT, NTFS suppresses names that contain
- unconvertible characters. Note that most character
- sets contain insufficient characters to represent all
- possible Unicode characters that can exist on NTFS.
- To be sure you are not missing any files, you are
- advised to use nls=utf8 which is capable of
- representing all Unicode characters.
-
-utf8=<bool> Option no longer supported. Currently mapped to
- nls=utf8 but please use nls=utf8 in the future and
- make sure utf8 is compiled either as module or into
- the kernel. See description for nls=name.
-
-uid=
-gid=
-umask= Provide default owner, group, and access mode mask.
- These options work as documented in mount(8). By
- default, the files/directories are owned by root and
- he/she has read and write permissions, as well as
- browse permission for directories. No one else has any
- access permissions. I.e. the mode on all files is by
- default rw------- and for directories rwx------, a
- consequence of the default fmask=0177 and dmask=0077.
- Using a umask of zero will grant all permissions to
- everyone, i.e. all files and directories will have mode
- rwxrwxrwx.
-
-fmask=
-dmask= Instead of specifying umask which applies both to
- files and directories, fmask applies only to files and
- dmask only to directories.
-
-sloppy=<BOOL> If sloppy is specified, ignore unknown mount options.
- Otherwise the default behaviour is to abort mount if
- any unknown options are found.
-
-show_sys_files=<BOOL> If show_sys_files is specified, show the system files
- in directory listings. Otherwise the default behaviour
- is to hide the system files.
- Note that even when show_sys_files is specified, "$MFT"
- will not be visible due to bugs/mis-features in glibc.
- Further, note that irrespective of show_sys_files, all
- files are accessible by name, i.e. you can always do
- "ls -l \$UpCase" for example to specifically show the
- system file containing the Unicode upcase table.
-
-case_sensitive=<BOOL> If case_sensitive is specified, treat all file names as
- case sensitive and create file names in the POSIX
- namespace. Otherwise the default behaviour is to treat
- file names as case insensitive and to create file names
- in the WIN32/LONG name space. Note, the Linux NTFS
- driver will never create short file names and will
- remove them on rename/delete of the corresponding long
- file name.
- Note that files remain accessible via their short file
- name, if it exists. If case_sensitive, you will need
- to provide the correct case of the short file name.
-
-disable_sparse=<BOOL> If disable_sparse is specified, creation of sparse
- regions, i.e. holes, inside files is disabled for the
- volume (for the duration of this mount only). By
- default, creation of sparse regions is enabled, which
- is consistent with the behaviour of traditional Unix
- filesystems.
-
-errors=opt What to do when critical filesystem errors are found.
- Following values can be used for "opt":
-
- ======== =========================================
- continue DEFAULT, try to clean-up as much as
- possible, e.g. marking a corrupt inode as
- bad so it is no longer accessed, and then
- continue.
- recover At present only supported is recovery of
- the boot sector from the backup copy.
- If read-only mount, the recovery is done
- in memory only and not written to disk.
- ======== =========================================
-
- Note that the options are additive, i.e. specifying::
-
- errors=continue,errors=recover
-
- means the driver will attempt to recover and if that
- fails it will clean-up as much as possible and
- continue.
-
-mft_zone_multiplier= Set the MFT zone multiplier for the volume (this
- setting is not persistent across mounts and can be
- changed from mount to mount but cannot be changed on
- remount). Values of 1 to 4 are allowed, 1 being the
- default. The MFT zone multiplier determines how much
- space is reserved for the MFT on the volume. If all
- other space is used up, then the MFT zone will be
- shrunk dynamically, so this has no impact on the
- amount of free space. However, it can have an impact
- on performance by affecting fragmentation of the MFT.
- In general use the default. If you have a lot of small
- files then use a higher value. The values have the
- following meaning:
-
- ===== =================================
- Value MFT zone size (% of volume size)
- ===== =================================
- 1 12.5%
- 2 25%
- 3 37.5%
- 4 50%
- ===== =================================
-
- Note this option is irrelevant for read-only mounts.
-======================= =======================================================
-
-
-Known bugs and (mis-)features
-=============================
-
-- The link count on each directory inode entry is set to 1, due to Linux not
- supporting directory hard links. This may well confuse some user space
- applications, since the directory names will have the same inode numbers.
- This also speeds up ntfs_read_inode() immensely. And we haven't found any
- problems with this approach so far. If you find a problem with this, please
- let us know.
-
-
-Please send bug reports/comments/feedback/abuse to the Linux-NTFS development
-list at sourceforge: linux-ntfs-dev@lists.sourceforge.net
-
-
-Using NTFS volume and stripe sets
-=================================
-
-For support of volume and stripe sets, you can either use the kernel's
-Device-Mapper driver or the kernel's Software RAID / MD driver. The former is
-the recommended one to use for linear raid. But the latter is required for
-raid level 5. For striping and mirroring, either driver should work fine.
-
-
-The Device-Mapper driver
-------------------------
-
-You will need to create a table of the components of the volume/stripe set and
-how they fit together and load this into the kernel using the dmsetup utility
-(see man 8 dmsetup).
-
-Linear volume sets, i.e. linear raid, has been tested and works fine. Even
-though untested, there is no reason why stripe sets, i.e. raid level 0, and
-mirrors, i.e. raid level 1 should not work, too. Stripes with parity, i.e.
-raid level 5, unfortunately cannot work yet because the current version of the
-Device-Mapper driver does not support raid level 5. You may be able to use the
-Software RAID / MD driver for raid level 5, see the next section for details.
-
-To create the table describing your volume you will need to know each of its
-components and their sizes in sectors, i.e. multiples of 512-byte blocks.
-
-For NT4 fault tolerant volumes you can obtain the sizes using fdisk. So for
-example if one of your partitions is /dev/hda2 you would do::
-
- $ fdisk -ul /dev/hda
-
- Disk /dev/hda: 81.9 GB, 81964302336 bytes
- 255 heads, 63 sectors/track, 9964 cylinders, total 160086528 sectors
- Units = sectors of 1 * 512 = 512 bytes
-
- Device Boot Start End Blocks Id System
- /dev/hda1 * 63 4209029 2104483+ 83 Linux
- /dev/hda2 4209030 37768814 16779892+ 86 NTFS
- /dev/hda3 37768815 46170809 4200997+ 83 Linux
-
-And you would know that /dev/hda2 has a size of 37768814 - 4209030 + 1 =
-33559785 sectors.
-
-For Win2k and later dynamic disks, you can for example use the ldminfo utility
-which is part of the Linux LDM tools (the latest version at the time of
-writing is linux-ldm-0.0.8.tar.bz2). You can download it from:
-
- http://www.linux-ntfs.org/
-
-Simply extract the downloaded archive (tar xvjf linux-ldm-0.0.8.tar.bz2), go
-into it (cd linux-ldm-0.0.8) and change to the test directory (cd test). You
-will find the precompiled (i386) ldminfo utility there. NOTE: You will not be
-able to compile this yourself easily so use the binary version!
-
-Then you would use ldminfo in dump mode to obtain the necessary information::
-
- $ ./ldminfo --dump /dev/hda
-
-This would dump the LDM database found on /dev/hda which describes all of your
-dynamic disks and all the volumes on them. At the bottom you will see the
-VOLUME DEFINITIONS section which is all you really need. You may need to look
-further above to determine which of the disks in the volume definitions is
-which device in Linux. Hint: Run ldminfo on each of your dynamic disks and
-look at the Disk Id close to the top of the output for each (the PRIVATE HEADER
-section). You can then find these Disk Ids in the VBLK DATABASE section in the
-<Disk> components where you will get the LDM Name for the disk that is found in
-the VOLUME DEFINITIONS section.
-
-Note you will also need to enable the LDM driver in the Linux kernel. If your
-distribution did not enable it, you will need to recompile the kernel with it
-enabled. This will create the LDM partitions on each device at boot time. You
-would then use those devices (for /dev/hda they would be /dev/hda1, 2, 3, etc)
-in the Device-Mapper table.
-
-You can also bypass using the LDM driver by using the main device (e.g.
-/dev/hda) and then using the offsets of the LDM partitions into this device as
-the "Start sector of device" when creating the table. Once again ldminfo would
-give you the correct information to do this.
-
-Assuming you know all your devices and their sizes things are easy.
-
-For a linear raid the table would look like this (note all values are in
-512-byte sectors)::
-
- # Offset into Size of this Raid type Device Start sector
- # volume device of device
- 0 1028161 linear /dev/hda1 0
- 1028161 3903762 linear /dev/hdb2 0
- 4931923 2103211 linear /dev/hdc1 0
-
-For a striped volume, i.e. raid level 0, you will need to know the chunk size
-you used when creating the volume. Windows uses 64kiB as the default, so it
-will probably be this unless you changes the defaults when creating the array.
-
-For a raid level 0 the table would look like this (note all values are in
-512-byte sectors)::
-
- # Offset Size Raid Number Chunk 1st Start 2nd Start
- # into of the type of size Device in Device in
- # volume volume stripes device device
- 0 2056320 striped 2 128 /dev/hda1 0 /dev/hdb1 0
-
-If there are more than two devices, just add each of them to the end of the
-line.
-
-Finally, for a mirrored volume, i.e. raid level 1, the table would look like
-this (note all values are in 512-byte sectors)::
-
- # Ofs Size Raid Log Number Region Should Number Source Start Target Start
- # in of the type type of log size sync? of Device in Device in
- # vol volume params mirrors Device Device
- 0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
-
-If you are mirroring to multiple devices you can specify further targets at the
-end of the line.
-
-Note the "Should sync?" parameter "nosync" means that the two mirrors are
-already in sync which will be the case on a clean shutdown of Windows. If the
-mirrors are not clean, you can specify the "sync" option instead of "nosync"
-and the Device-Mapper driver will then copy the entirety of the "Source Device"
-to the "Target Device" or if you specified multiple target devices to all of
-them.
-
-Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),
-and hand it over to dmsetup to work with, like so::
-
- $ dmsetup create myvolume1 /etc/ntfsvolume1
-
-You can obviously replace "myvolume1" with whatever name you like.
-
-If it all worked, you will now have the device /dev/device-mapper/myvolume1
-which you can then just use as an argument to the mount command as usual to
-mount the ntfs volume. For example::
-
- $ mount -t ntfs -o ro /dev/device-mapper/myvolume1 /mnt/myvol1
-
-(You need to create the directory /mnt/myvol1 first and of course you can use
-anything you like instead of /mnt/myvol1 as long as it is an existing
-directory.)
-
-It is advisable to do the mount read-only to see if the volume has been setup
-correctly to avoid the possibility of causing damage to the data on the ntfs
-volume.
-
-
-The Software RAID / MD driver
------------------------------
-
-An alternative to using the Device-Mapper driver is to use the kernel's
-Software RAID / MD driver. For which you need to set up your /etc/raidtab
-appropriately (see man 5 raidtab).
-
-Linear volume sets, i.e. linear raid, as well as stripe sets, i.e. raid level
-0, have been tested and work fine (though see section "Limitations when using
-the MD driver with NTFS volumes" especially if you want to use linear raid).
-Even though untested, there is no reason why mirrors, i.e. raid level 1, and
-stripes with parity, i.e. raid level 5, should not work, too.
-
-You have to use the "persistent-superblock 0" option for each raid-disk in the
-NTFS volume/stripe you are configuring in /etc/raidtab as the persistent
-superblock used by the MD driver would damage the NTFS volume.
-
-Windows by default uses a stripe chunk size of 64k, so you probably want the
-"chunk-size 64k" option for each raid-disk, too.
-
-For example, if you have a stripe set consisting of two partitions /dev/hda5
-and /dev/hdb1 your /etc/raidtab would look like this::
-
- raiddev /dev/md0
- raid-level 0
- nr-raid-disks 2
- nr-spare-disks 0
- persistent-superblock 0
- chunk-size 64k
- device /dev/hda5
- raid-disk 0
- device /dev/hdb1
- raid-disk 1
-
-For linear raid, just change the raid-level above to "raid-level linear", for
-mirrors, change it to "raid-level 1", and for stripe sets with parity, change
-it to "raid-level 5".
-
-Note for stripe sets with parity you will also need to tell the MD driver
-which parity algorithm to use by specifying the option "parity-algorithm
-which", where you need to replace "which" with the name of the algorithm to
-use (see man 5 raidtab for available algorithms) and you will have to try the
-different available algorithms until you find one that works. Make sure you
-are working read-only when playing with this as you may damage your data
-otherwise. If you find which algorithm works please let us know (email the
-linux-ntfs developers list linux-ntfs-dev@lists.sourceforge.net or drop in on
-IRC in channel #ntfs on the irc.freenode.net network) so we can update this
-documentation.
-
-Once the raidtab is setup, run for example raid0run -a to start all devices or
-raid0run /dev/md0 to start a particular md device, in this case /dev/md0.
-
-Then just use the mount command as usual to mount the ntfs volume using for
-example::
-
- mount -t ntfs -o ro /dev/md0 /mnt/myntfsvolume
-
-It is advisable to do the mount read-only to see if the md volume has been
-setup correctly to avoid the possibility of causing damage to the data on the
-ntfs volume.
-
-
-Limitations when using the Software RAID / MD driver
------------------------------------------------------
-
-Using the md driver will not work properly if any of your NTFS partitions have
-an odd number of sectors. This is especially important for linear raid as all
-data after the first partition with an odd number of sectors will be offset by
-one or more sectors so if you mount such a partition with write support you
-will cause massive damage to the data on the volume which will only become
-apparent when you try to use the volume again under Windows.
-
-So when using linear raid, make sure that all your partitions have an even
-number of sectors BEFORE attempting to use it. You have been warned!
-
-Even better is to simply use the Device-Mapper for linear raid and then you do
-not have this problem with odd numbers of sectors.
diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst
index d67ccd22c63b..2b86a9b3a6de 100644
--- a/Documentation/filesystems/ntfs3.rst
+++ b/Documentation/filesystems/ntfs3.rst
@@ -25,6 +25,11 @@ versions up to 3.1. File system type to use on mount is *ntfs3*.
Note: Applied to empty files, this allows to switch type between
sparse(0x200), compressed(0x800) and normal.
+ - *system.ntfs_attrib_be* gets/sets ntfs file/dir attributes.
+
+ Same value as system.ntfs_attrib but always represent as big-endian
+ (endianness of system.ntfs_attrib is the same as of the CPU).
+
Mount Options
=============
@@ -56,17 +61,6 @@ this table marked with no it means default is without **no**.
directories, fmask applies only to files and dmask only to directories.
* - fmask=
- * - noacsrules
- - "No access rules" mount option sets access rights for files/folders to
- 777 and owner/group to root. This mount option absorbs all other
- permissions.
-
- - Permissions change for files/folders will be reported as successful,
- but they will remain 777.
-
- - Owner/group change will be reported as successful, butthey will stay
- as root.
-
* - nohidden
- Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute
will not be shown under Linux.
@@ -75,6 +69,20 @@ this table marked with no it means default is without **no**.
- Files with the Windows-specific SYSTEM (FILE_ATTRIBUTE_SYSTEM) attribute
will be marked as system immutable files.
+ * - hide_dot_files
+ - Updates the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute
+ when creating and moving or renaming files. Files whose names start
+ with a dot will have the HIDDEN attribute set and files whose names
+ do not start with a dot will have it unset.
+
+ * - windows_names
+ - Prevents the creation of files and directories with a name not allowed
+ by Windows, either because it contains some not allowed character (which
+ are the characters " * / : < > ? \\ | and those whose code is less than
+ 0x20), because the name (with or without extension) is a reserved file
+ name (CON, AUX, NUL, PRN, LPT1-9, COM1-9) or because the last character
+ is a space or a dot. Existing such files can still be read and renamed.
+
* - discard
- Enable support of the TRIM command for improved performance on delete
operations, which is recommended for use with the solid-state drives
@@ -104,7 +112,7 @@ this table marked with no it means default is without **no**.
Todo list
=========
- Full journaling support over JBD. Currently journal replaying is supported
- which is not necessarily as effectice as JBD would be.
+ which is not necessarily as effective as JBD would be.
References
==========
diff --git a/Documentation/filesystems/ocfs2-online-filecheck.rst b/Documentation/filesystems/ocfs2-online-filecheck.rst
index 2257bb53edc1..9e8449416e0b 100644
--- a/Documentation/filesystems/ocfs2-online-filecheck.rst
+++ b/Documentation/filesystems/ocfs2-online-filecheck.rst
@@ -58,33 +58,33 @@ inode, fixing inode and setting the size of result record history.
# echo "<inode>" > /sys/fs/ocfs2/<devname>/filecheck/check
# cat /sys/fs/ocfs2/<devname>/filecheck/check
-The output is like this::
+ The output is like this::
INO DONE ERROR
39502 1 GENERATION
- <INO> lists the inode numbers.
- <DONE> indicates whether the operation has been finished.
- <ERROR> says what kind of errors was found. For the detailed error numbers,
- please refer to the file linux/fs/ocfs2/filecheck.h.
+ <INO> lists the inode numbers.
+ <DONE> indicates whether the operation has been finished.
+ <ERROR> says what kind of errors was found. For the detailed error numbers,
+ please refer to the file linux/fs/ocfs2/filecheck.h.
2. If you determine to fix this inode, do::
# echo "<inode>" > /sys/fs/ocfs2/<devname>/filecheck/fix
# cat /sys/fs/ocfs2/<devname>/filecheck/fix
-The output is like this:::
+ The output is like this::
INO DONE ERROR
39502 1 SUCCESS
-This time, the <ERROR> column indicates whether this fix is successful or not.
+ This time, the <ERROR> column indicates whether this fix is successful or not.
3. The record cache is used to store the history of check/fix results. It's
-default size is 10, and can be adjust between the range of 10 ~ 100. You can
-adjust the size like this::
+ default size is 10, and can be adjust between the range of 10 ~ 100. You can
+ adjust the size like this::
- # echo "<size>" > /sys/fs/ocfs2/<devname>/filecheck/set
+ # echo "<size>" > /sys/fs/ocfs2/<devname>/filecheck/set
Fixing stuff
============
diff --git a/Documentation/filesystems/ocfs2.rst b/Documentation/filesystems/ocfs2.rst
index 42ca9a3d4c6e..5827062995cb 100644
--- a/Documentation/filesystems/ocfs2.rst
+++ b/Documentation/filesystems/ocfs2.rst
@@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl".
Project web page: http://ocfs2.wiki.kernel.org
Tools git tree: https://github.com/markfasheh/ocfs2-tools
-OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
+OCFS2 mailing lists: https://subspace.kernel.org/lists.linux.dev.html
All code copyright 2005 Oracle except when otherwise noted.
diff --git a/Documentation/filesystems/orangefs.rst b/Documentation/filesystems/orangefs.rst
index 463e37694250..931159e61796 100644
--- a/Documentation/filesystems/orangefs.rst
+++ b/Documentation/filesystems/orangefs.rst
@@ -274,7 +274,7 @@ then contains:
of kcalloced memory. This memory is used as an array of pointers
to each of the pages in the IO buffer through a call to get_user_pages.
* desc_array - a pointer to ``desc_count * (sizeof(struct orangefs_bufmap_desc))``
- bytes of kcalloced memory. This memory is further intialized:
+ bytes of kcalloced memory. This memory is further initialized:
user_desc is the kernel's copy of the IO buffer's ORANGEFS_dev_map_desc
structure. user_desc->ptr points to the IO buffer.
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index 4c76fda07645..ab989807a2cb 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -9,7 +9,7 @@ Overlay Filesystem
This document describes a prototype for a new approach to providing
overlay-filesystem functionality in Linux (sometimes referred to as
union-filesystems). An overlay-filesystem tries to present a
-filesystem which is the result over overlaying one filesystem on top
+filesystem which is the result of overlaying one filesystem on top
of the other.
@@ -39,7 +39,7 @@ objects in the original filesystem.
On 64bit systems, even if all overlay layers are not on the same
underlying filesystem, the same compliant behavior could be achieved
with the "xino" feature. The "xino" feature composes a unique object
-identifier from the real object st_ino and an underlying fsid index.
+identifier from the real object st_ino and an underlying fsid number.
The "xino" feature uses the high inode number bits for fsid, because the
underlying filesystems rarely use the high inode number bits. In case
the underlying inode number does overflow into the high xino bits, overlay
@@ -61,7 +61,7 @@ Inode properties
|Configuration | Persistent | Uniform | st_ino == d_ino | d_ino == i_ino |
| | st_ino | st_dev | | [*] |
+==============+=====+======+=====+======+========+========+========+=======+
-| | dir | !dir | dir | !dir | dir + !dir | dir | !dir |
+| | dir | !dir | dir | !dir | dir | !dir | dir | !dir |
+--------------+-----+------+-----+------+--------+--------+--------+-------+
| All layers | Y | Y | Y | Y | Y | Y | Y | Y |
| on same fs | | | | | | | | |
@@ -118,7 +118,7 @@ Where both upper and lower objects are directories, a merged directory
is formed.
At mount time, the two directories given as mount options "lowerdir" and
-"upperdir" are combined into a merged directory:
+"upperdir" are combined into a merged directory::
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
workdir=/work /merged
@@ -145,7 +145,9 @@ filesystem, an overlay filesystem needs to record in the upper filesystem
that files have been removed. This is done using whiteouts and opaque
directories (non-directories are always opaque).
-A whiteout is created as a character device with 0/0 device number.
+A whiteout is created as a character device with 0/0 device number or
+as a zero-size regular file with the xattr "trusted.overlay.whiteout".
+
When a whiteout is found in the upper level of a merged directory, any
matching name in the lower level is ignored, and the whiteout itself
is also hidden.
@@ -154,6 +156,13 @@ A directory is made opaque by setting the xattr "trusted.overlay.opaque"
to "y". Where the upper filesystem contains an opaque directory, any
directory in the lower filesystem with the same name is ignored.
+An opaque directory should not contain any whiteouts, because they do not
+serve any purpose. A merge directory containing regular files with the xattr
+"trusted.overlay.whiteout", should be additionally marked by setting the xattr
+"trusted.overlay.opaque" to "x" on the merge directory itself.
+This is needed to avoid the overhead of checking the "trusted.overlay.whiteout"
+on all entries during readdir in the common case.
+
readdir
-------
@@ -172,12 +181,12 @@ directory is being read. This is unlikely to be noticed by many
programs.
seek offsets are assigned sequentially when the directories are read.
-Thus if
+Thus if:
- - read part of a directory
- - remember an offset, and close the directory
- - re-open the directory some time later
- - seek to the remembered offset
+ - read part of a directory
+ - remember an offset, and close the directory
+ - re-open the directory some time later
+ - seek to the remembered offset
there may be little correlation between the old and new locations in
the list of filenames, particularly if anything has changed in the
@@ -195,7 +204,7 @@ handle it in two different ways:
1. return EXDEV error: this error is returned by rename(2) when trying to
move a file or directory across filesystem boundaries. Hence
- applications are usually prepared to hande this error (mv(1) for example
+ applications are usually prepared to handle this error (mv(1) for example
recursively copies the directory tree). This is the default behavior.
2. If the "redirect_dir" feature is enabled, then the directory will be
@@ -231,12 +240,11 @@ Mount options:
Redirects are enabled.
- "redirect_dir=follow":
Redirects are not created, but followed.
-- "redirect_dir=off":
- Redirects are not created and only followed if "redirect_always_follow"
- feature is enabled in the kernel/module config.
- "redirect_dir=nofollow":
- Redirects are not created and not followed (equivalent to "redirect_dir=off"
- if "redirect_always_follow" feature is not enabled).
+ Redirects are not created and not followed.
+- "redirect_dir=off":
+ If "redirect_always_follow" is enabled in the kernel/module config,
+ this "off" translates to "follow", otherwise it translates to "nofollow".
When the NFS export feature is enabled, every copied up directory is
indexed by the file handle of the lower inode and a file handle of the
@@ -258,7 +266,7 @@ Non-directories
Objects that are not directories (files, symlinks, device-special
files etc.) are presented either from the upper or lower filesystem as
appropriate. When a file in the lower filesystem is accessed in a way
-the requires write-access, such as opening for write access, changing
+that requires write-access, such as opening for write access, changing
some metadata etc., the file is first copied from the lower filesystem
to the upper filesystem (copy_up). Note that creating a hard-link
also requires copy_up, though of course creation of a symlink does
@@ -284,21 +292,35 @@ rename or unlink will of course be noticed and handled).
Permission model
----------------
+An overlay filesystem stashes credentials that will be used when
+accessing lower or upper filesystems.
+
+In the old mount api the credentials of the task calling mount(2) are
+stashed. In the new mount api the credentials of the task creating the
+superblock through FSCONFIG_CMD_CREATE command of fsconfig(2) are
+stashed.
+
+Starting with kernel v6.15 it is possible to use the "override_creds"
+mount option which will cause the credentials of the calling task to be
+recorded. Note that "override_creds" is only meaningful when used with
+the new mount api as the old mount api combines setting options and
+superblock creation in a single mount(2) syscall.
+
Permission checking in the overlay filesystem follows these principles:
1) permission check SHOULD return the same result before and after copy up
2) task creating the overlay mount MUST NOT gain additional privileges
- 3) non-mounting task MAY gain additional privileges through the overlay,
- compared to direct access on underlying lower or upper filesystems
+ 3) task[*] MAY gain additional privileges through the overlay,
+ compared to direct access on underlying lower or upper filesystems
-This is achieved by performing two permission checks on each access
+This is achieved by performing two permission checks on each access:
a) check if current task is allowed access based on local DAC (owner,
group, mode and posix acl), as well as MAC checks
- b) check if mounting task would be allowed real operation on lower or
+ b) check if stashed credentials would be allowed real operation on lower or
upper layer based on underlying filesystem permissions, again including
MAC checks
@@ -307,16 +329,16 @@ are copied up. On the other hand it can result in server enforced
permissions (used by NFS, for example) being ignored (3).
Check (b) ensures that no task gains permissions to underlying layers that
-the mounting task does not have (2). This also means that it is possible
+the stashed credentials do not have (2). This also means that it is possible
to create setups where the consistency rule (1) does not hold; normally,
-however, the mounting task will have sufficient privileges to perform all
-operations.
+however, the stashed credentials will have sufficient privileges to
+perform all operations.
-Another way to demonstrate this model is drawing parallels between
+Another way to demonstrate this model is drawing parallels between::
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,... /merged
-and
+and::
cp -a /lower /upper
mount --bind /upper /merged
@@ -329,7 +351,7 @@ Multiple lower layers
---------------------
Multiple lower layers can now be given using the colon (":") as a
-separator character between the directory names. For example:
+separator character between the directory names. For example::
mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged
@@ -340,14 +362,30 @@ The specified lower directories will be stacked beginning from the
rightmost one and going left. In the above example lower1 will be the
top, lower2 the middle and lower3 the bottom layer.
+Note: directory names containing colons can be provided as lower layer by
+escaping the colons with a single backslash. For example::
+
+ mount -t overlay overlay -olowerdir=/a\:lower\:\:dir /merged
+
+Since kernel version v6.8, directory names containing colons can also
+be configured as lower layer using the "lowerdir+" mount options and the
+fsconfig syscall from new mount api. For example::
+
+ fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/a:lower::dir", 0);
+
+In the latter case, colons in lower layer directory names will be escaped
+as an octal characters (\072) when displayed in /proc/self/mountinfo.
Metadata only copy up
---------------------
-When metadata only copy up feature is enabled, overlayfs will only copy
+When the "metacopy" feature is enabled, overlayfs will only copy
up metadata (as opposed to whole file), when a metadata specific operation
-like chown/chmod is performed. Full file will be copied up later when
-file is opened for WRITE operation.
+like chown/chmod is performed. An upper file in this state is marked with
+"trusted.overlayfs.metacopy" xattr which indicates that the upper file
+contains no data. The data will be copied up later when file is opened for
+WRITE operation. After the lower file's data is copied up,
+the "trusted.overlayfs.metacopy" xattr is removed from the upper file.
In other words, this is delayed data copy up operation and data is copied
up when there is a need to actually modify data.
@@ -371,6 +409,122 @@ conflict with metacopy=on, and will result in an error.
[*] redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
given.
+
+Data-only lower layers
+----------------------
+
+With "metacopy" feature enabled, an overlayfs regular file may be a composition
+of information from up to three different layers:
+
+ 1) metadata from a file in the upper layer
+
+ 2) st_ino and st_dev object identifier from a file in a lower layer
+
+ 3) data from a file in another lower layer (further below)
+
+The "lower data" file can be on any lower layer, except from the top most
+lower layer.
+
+Below the topmost lower layer, any number of lowermost layers may be defined
+as "data-only" lower layers, using double colon ("::") separators.
+A normal lower layer is not allowed to be below a data-only layer, so single
+colon separators are not allowed to the right of double colon ("::") separators.
+
+
+For example::
+
+ mount -t overlay overlay -olowerdir=/l1:/l2:/l3::/do1::/do2 /merged
+
+The paths of files in the "data-only" lower layers are not visible in the
+merged overlayfs directories and the metadata and st_ino/st_dev of files
+in the "data-only" lower layers are not visible in overlayfs inodes.
+
+Only the data of the files in the "data-only" lower layers may be visible
+when a "metacopy" file in one of the lower layers above it, has a "redirect"
+to the absolute path of the "lower data" file in the "data-only" lower layer.
+
+Instead of explicitly enabling "metacopy=on" it is sufficient to specify at
+least one data-only layer to enable redirection of data to a data-only layer.
+In this case other forms of metacopy are rejected. Note: this way, data-only
+layers may be used together with "userxattr", in which case careful attention
+must be given to privileges needed to change the "user.overlay.redirect" xattr
+to prevent misuse.
+
+Since kernel version v6.8, "data-only" lower layers can also be added using
+the "datadir+" mount options and the fsconfig syscall from new mount api.
+For example::
+
+ fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/l1", 0);
+ fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/l2", 0);
+ fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir+", "/l3", 0);
+ fsconfig(fs_fd, FSCONFIG_SET_STRING, "datadir+", "/do1", 0);
+ fsconfig(fs_fd, FSCONFIG_SET_STRING, "datadir+", "/do2", 0);
+
+
+Specifying layers via file descriptors
+--------------------------------------
+
+Since kernel v6.13, overlayfs supports specifying layers via file descriptors in
+addition to specifying them as paths. This feature is available for the
+"datadir+", "lowerdir+", "upperdir", and "workdir+" mount options with the
+fsconfig syscall from the new mount api::
+
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower1);
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower2);
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower3);
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "datadir+", NULL, fd_data1);
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "datadir+", NULL, fd_data2);
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "workdir", NULL, fd_work);
+ fsconfig(fs_fd, FSCONFIG_SET_FD, "upperdir", NULL, fd_upper);
+
+
+fs-verity support
+-----------------
+
+During metadata copy up of a lower file, if the source file has
+fs-verity enabled and overlay verity support is enabled, then the
+digest of the lower file is added to the "trusted.overlay.metacopy"
+xattr. This is then used to verify the content of the lower file
+each the time the metacopy file is opened.
+
+When a layer containing verity xattrs is used, it means that any such
+metacopy file in the upper layer is guaranteed to match the content
+that was in the lower at the time of the copy-up. If at any time
+(during a mount, after a remount, etc) such a file in the lower is
+replaced or modified in any way, access to the corresponding file in
+overlayfs will result in EIO errors (either on open, due to overlayfs
+digest check, or from a later read due to fs-verity) and a detailed
+error is printed to the kernel logs. For more details of how fs-verity
+file access works, see :ref:`Documentation/filesystems/fsverity.rst
+<accessing_verity_files>`.
+
+Verity can be used as a general robustness check to detect accidental
+changes in the overlayfs directories in use. But, with additional care
+it can also give more powerful guarantees. For example, if the upper
+layer is fully trusted (by using dm-verity or something similar), then
+an untrusted lower layer can be used to supply validated file content
+for all metacopy files. If additionally the untrusted lower
+directories are specified as "Data-only", then they can only supply
+such file content, and the entire mount can be trusted to match the
+upper layer.
+
+This feature is controlled by the "verity" mount option, which
+supports these values:
+
+- "off":
+ The metacopy digest is never generated or used. This is the
+ default if verity option is not specified.
+- "on":
+ Whenever a metacopy file specifies an expected digest, the
+ corresponding data file must match the specified digest. When
+ generating a metacopy file the verity digest will be set in it
+ based on the source file (if it has one).
+- "require":
+ Same as "on", but additionally all metacopy files must specify a
+ digest (or EIO is returned on open). This means metadata copy up
+ will only be used if the data file has fs-verity enabled,
+ otherwise a full copy-up is used.
+
Sharing and copying layers
--------------------------
@@ -383,34 +537,58 @@ Using an upper layer path and/or a workdir path that are already used by
another overlay mount is not allowed and may fail with EBUSY. Using
partially overlapping paths is not allowed and may fail with EBUSY.
If files are accessed from two overlayfs mounts which share or overlap the
-upper layer and/or workdir path the behavior of the overlay is undefined,
+upper layer and/or workdir path, the behavior of the overlay is undefined,
though it will not result in a crash or deadlock.
Mounting an overlay using an upper layer path, where the upper layer path
was previously used by another mounted overlay in combination with a
-different lower layer path, is allowed, unless the "inodes index" feature
-or "metadata only copy up" feature is enabled.
+different lower layer path, is allowed, unless the "index" or "metacopy"
+features are enabled.
-With the "inodes index" feature, on the first time mount, an NFS file
+With the "index" feature, on the first time mount, an NFS file
handle of the lower layer root directory, along with the UUID of the lower
filesystem, are encoded and stored in the "trusted.overlay.origin" extended
attribute on the upper layer root directory. On subsequent mount attempts,
the lower root directory file handle and lower filesystem UUID are compared
to the stored origin in upper root directory. On failure to verify the
lower root origin, mount will fail with ESTALE. An overlayfs mount with
-"inodes index" enabled will fail with EOPNOTSUPP if the lower filesystem
+"index" enabled will fail with EOPNOTSUPP if the lower filesystem
does not support NFS export, lower filesystem does not have a valid UUID or
if the upper filesystem does not support extended attributes.
-For "metadata only copy up" feature there is no verification mechanism at
+For the "metacopy" feature, there is no verification mechanism at
mount time. So if same upper is mounted with different set of lower, mount
probably will succeed but expect the unexpected later on. So don't do it.
It is quite a common practice to copy overlay layers to a different
directory tree on the same or different underlying filesystem, and even
-to a different machine. With the "inodes index" feature, trying to mount
+to a different machine. With the "index" feature, trying to mount
the copied layers will fail the verification of the lower root file handle.
+Nesting overlayfs mounts
+------------------------
+
+It is possible to use a lower directory that is stored on an overlayfs
+mount. For regular files this does not need any special care. However, files
+that have overlayfs attributes, such as whiteouts or "overlay.*" xattrs, will
+be interpreted by the underlying overlayfs mount and stripped out. In order to
+allow the second overlayfs mount to see the attributes they must be escaped.
+
+Overlayfs specific xattrs are escaped by using a special prefix of
+"overlay.overlay.". So, a file with a "trusted.overlay.overlay.metacopy" xattr
+in the lower dir will be exposed as a regular file with a
+"trusted.overlay.metacopy" xattr in the overlayfs mount. This can be nested by
+repeating the prefix multiple time, as each instance only removes one prefix.
+
+A lower dir with a regular whiteout will always be handled by the overlayfs
+mount, so to support storing an effective whiteout file in an overlayfs mount an
+alternative form of whiteout is supported. This form is a regular, zero-size
+file with the "overlay.whiteout" xattr set, inside a directory with the
+"overlay.opaque" xattr set to "x" (see `whiteouts and opaque directories`_).
+These alternative whiteouts are never created by overlayfs, but can be used by
+userspace tools (like containers) that generate lower layers.
+These alternative whiteouts can be escaped using the standard xattr escape
+mechanism in order to properly nest to any depth.
Non-standard behavior
---------------------
@@ -420,20 +598,21 @@ filesystem.
This is the list of cases that overlayfs doesn't currently handle:
-a) POSIX mandates updating st_atime for reads. This is currently not
-done in the case when the file resides on a lower layer.
+ a) POSIX mandates updating st_atime for reads. This is currently not
+ done in the case when the file resides on a lower layer.
-b) If a file residing on a lower layer is opened for read-only and then
-memory mapped with MAP_SHARED, then subsequent changes to the file are not
-reflected in the memory mapping.
+ b) If a file residing on a lower layer is opened for read-only and then
+ memory mapped with MAP_SHARED, then subsequent changes to the file are not
+ reflected in the memory mapping.
-c) If a file residing on a lower layer is being executed, then opening that
-file for write or truncating the file will not be denied with ETXTBSY.
+ c) If a file residing on a lower layer is being executed, then opening that
+ file for write or truncating the file will not be denied with ETXTBSY.
The following options allow overlayfs to act more like a standards
compliant filesystem:
-1) "redirect_dir"
+redirect_dir
+````````````
Enabled with the mount option or module option: "redirect_dir=on" or with
the kernel config option CONFIG_OVERLAY_FS_REDIRECT_DIR=y.
@@ -441,7 +620,8 @@ the kernel config option CONFIG_OVERLAY_FS_REDIRECT_DIR=y.
If this feature is disabled, then rename(2) on a lower or merged directory
will fail with EXDEV ("Invalid cross-device link").
-2) "inode index"
+index
+`````
Enabled with the mount option or module option "index=on" or with the
kernel config option CONFIG_OVERLAY_FS_INDEX=y.
@@ -450,7 +630,8 @@ If this feature is disabled and a file with multiple hard links is copied
up, then this will "break" the link. Changes will not be propagated to
other names referring to the same inode.
-3) "xino"
+xino
+````
Enabled with the mount option "xino=auto" or "xino=on", with the module
option "xino_auto=on" or with the kernel config option
@@ -477,7 +658,7 @@ a crash or deadlock.
Offline changes, when the overlay is not mounted, are allowed to the
upper tree. Offline changes to the lower tree are only allowed if the
-"metadata only copy up", "inode index", "xino" and "redirect_dir" features
+"metacopy", "index", "xino" and "redirect_dir" features
have not been used. If the lower tree is modified and any of these
features has been used, the behavior of the overlay is undefined,
though it will not result in a crash or deadlock.
@@ -517,12 +698,13 @@ directory inode.
When encoding a file handle from an overlay filesystem object, the
following rules apply:
-1. For a non-upper object, encode a lower file handle from lower inode
-2. For an indexed object, encode a lower file handle from copy_up origin
-3. For a pure-upper object and for an existing non-indexed upper object,
- encode an upper file handle from upper inode
+ 1. For a non-upper object, encode a lower file handle from lower inode
+ 2. For an indexed object, encode a lower file handle from copy_up origin
+ 3. For a pure-upper object and for an existing non-indexed upper object,
+ encode an upper file handle from upper inode
The encoded overlay file handle includes:
+
- Header including path type information (e.g. lower/upper)
- UUID of the underlying filesystem
- Underlying filesystem encoding of underlying inode
@@ -532,15 +714,15 @@ are stored in extended attribute "trusted.overlay.origin".
When decoding an overlay file handle, the following steps are followed:
-1. Find underlying layer by UUID and path type information.
-2. Decode the underlying filesystem file handle to underlying dentry.
-3. For a lower file handle, lookup the handle in index directory by name.
-4. If a whiteout is found in index, return ESTALE. This represents an
- overlay object that was deleted after its file handle was encoded.
-5. For a non-directory, instantiate a disconnected overlay dentry from the
- decoded underlying dentry, the path type and index inode, if found.
-6. For a directory, use the connected underlying decoded dentry, path type
- and index, to lookup a connected overlay dentry.
+ 1. Find underlying layer by UUID and path type information.
+ 2. Decode the underlying filesystem file handle to underlying dentry.
+ 3. For a lower file handle, lookup the handle in index directory by name.
+ 4. If a whiteout is found in index, return ESTALE. This represents an
+ overlay object that was deleted after its file handle was encoded.
+ 5. For a non-directory, instantiate a disconnected overlay dentry from the
+ decoded underlying dentry, the path type and index inode, if found.
+ 6. For a directory, use the connected underlying decoded dentry, path type
+ and index, to lookup a connected overlay dentry.
Decoding a non-directory file handle may return a disconnected dentry.
copy_up of that disconnected dentry will create an upper index entry with
@@ -576,6 +758,31 @@ can be useful in case the underlying disk is copied and the UUID of this copy
is changed. This is only applicable if all lower/upper/work directories are on
the same filesystem, otherwise it will fallback to normal behaviour.
+
+UUID and fsid
+-------------
+
+The UUID of overlayfs instance itself and the fsid reported by statfs(2) are
+controlled by the "uuid" mount option, which supports these values:
+
+- "null":
+ UUID of overlayfs is null. fsid is taken from upper most filesystem.
+- "off":
+ UUID of overlayfs is null. fsid is taken from upper most filesystem.
+ UUID of underlying layers is ignored.
+- "on":
+ UUID of overlayfs is generated and used to report a unique fsid.
+ UUID is stored in xattr "trusted.overlay.uuid", making overlayfs fsid
+ unique and persistent. This option requires an overlayfs with upper
+ filesystem that supports xattrs.
+- "auto": (default)
+ UUID is taken from xattr "trusted.overlay.uuid" if it exists.
+ Upgrade to "uuid=on" on first time mount of new overlay filesystem that
+ meets the prerequisites.
+ Downgrade to "uuid=null" for existing overlay filesystems that were never
+ mounted with "uuid=on".
+
+
Volatile mount
--------------
@@ -587,20 +794,20 @@ without significant effort.
The advantage of mounting with the "volatile" option is that all forms of
sync calls to the upper filesystem are omitted.
-In order to avoid a giving a false sense of safety, the syncfs (and fsync)
+In order to avoid giving a false sense of safety, the syncfs (and fsync)
semantics of volatile mounts are slightly different than that of the rest of
VFS. If any writeback error occurs on the upperdir's filesystem after a
volatile mount takes place, all sync functions will return an error. Once this
condition is reached, the filesystem will not recover, and every subsequent sync
-call will return an error, even if the upperdir has not experience a new error
+call will return an error, even if the upperdir has not experienced a new error
since the last sync call.
When overlay is mounted with "volatile" option, the directory
"$workdir/work/incompat/volatile" is created. During next mount, overlay
checks for this directory and refuses to mount if present. This is a strong
-indicator that user should throw away upper and work directories and create
-fresh one. In very limited cases where the user knows that the system has
-not crashed and contents of upperdir are intact, The "volatile" directory
+indicator that the user should discard upper and work directories and create
+fresh ones. In very limited cases where the user knows that the system has
+not crashed and contents of upperdir are intact, the "volatile" directory
can be removed.
@@ -618,9 +825,9 @@ Testsuite
There's a testsuite originally developed by David Howells and currently
maintained by Amir Goldstein at:
- https://github.com/amir73il/unionmount-testsuite.git
+https://github.com/amir73il/unionmount-testsuite.git
-Run as root:
+Run as root::
# cd unionmount-testsuite
# ./run --ov --verify
diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
index 2b2df6aa5432..9ced1135608e 100644
--- a/Documentation/filesystems/path-lookup.rst
+++ b/Documentation/filesystems/path-lookup.rst
@@ -531,7 +531,7 @@ this retry process in the next article.
Automount points are locations in the filesystem where an attempt to
lookup a name can trigger changes to how that lookup should be
handled, in particular by mounting a filesystem there. These are
-covered in greater detail in autofs.txt in the Linux documentation
+covered in greater detail in autofs.rst in the Linux documentation
tree, but a few notes specifically related to path lookup are in order
here.
diff --git a/Documentation/filesystems/path-lookup.txt b/Documentation/filesystems/path-lookup.txt
index 1aa7ce099f6f..d2cf2852e1f8 100644
--- a/Documentation/filesystems/path-lookup.txt
+++ b/Documentation/filesystems/path-lookup.txt
@@ -379,4 +379,4 @@ Papers and other documentation on dcache locking
2. http://lse.sourceforge.net/locking/dcache/dcache.html
-3. path-lookup.md in this directory.
+3. path-lookup.rst in this directory.
diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
index e8f370d9ce9c..3397937ed838 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -177,7 +177,7 @@ settles down a bit.
**mandatory**
s_export_op is now required for exporting a filesystem.
-isofs, ext2, ext3, resierfs, fat
+isofs, ext2, ext3, fat
can be used as examples of very different filesystems.
---
@@ -211,7 +211,7 @@ test and set for you.
e.g.::
inode = iget_locked(sb, ino);
- if (inode->i_state & I_NEW) {
+ if (inode_state_read_once(inode) & I_NEW) {
err = read_inode_from_disk(inode);
if (err < 0) {
iget_failed(inode);
@@ -313,7 +313,7 @@ done.
**mandatory**
-block truncatation on error exit from ->write_begin, and ->direct_IO
+block truncation on error exit from ->write_begin, and ->direct_IO
moved from generic methods (block_write_begin, cont_write_begin,
nobh_write_begin, blockdev_direct_IO*) to callers. Take a look at
ext2_write_failed and callers for an example.
@@ -340,8 +340,8 @@ of those. Caller makes sure async writeback cannot be running for the inode whil
->drop_inode() returns int now; it's called on final iput() with
inode->i_lock held and it returns true if filesystems wants the inode to be
-dropped. As before, generic_drop_inode() is still the default and it's been
-updated appropriately. generic_delete_inode() is also alive and it consists
+dropped. As before, inode_generic_drop() is still the default and it's been
+updated appropriately. inode_just_drop() is also alive and it consists
simply of return 1. Note that all actual eviction work is done by caller after
->drop_inode() returns.
@@ -462,15 +462,15 @@ ERR_PTR(...).
argument; instead of passing IPERM_FLAG_RCU we add MAY_NOT_BLOCK into mask.
generic_permission() has also lost the check_acl argument; ACL checking
-has been taken to VFS and filesystems need to provide a non-NULL ->i_op->get_acl
-to read an ACL from disk.
+has been taken to VFS and filesystems need to provide a non-NULL
+->i_op->get_inode_acl to read an ACL from disk.
---
**mandatory**
If you implement your own ->llseek() you must handle SEEK_HOLE and
-SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to
+SEEK_DATA. You can handle this by returning -EINVAL, but it would be nicer to
support it in some way. The generic handler assumes that the entire file is
data and there is a virtual hole at the end of the file. So if the provided
offset is less than i_size and SEEK_DATA is specified, return the same offset.
@@ -517,7 +517,7 @@ The witch is dead! Well, 2/3 of it, anyway. ->d_revalidate() and
->create() doesn't take ``struct nameidata *``; unlike the previous
two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that
-local filesystems can ignore tha argument - they are guaranteed that the
+local filesystems can ignore this argument - they are guaranteed that the
object doesn't exist. It's remote/distributed ones that might care...
---
@@ -537,7 +537,7 @@ vfs_readdir() is gone; switch to iterate_dir() instead
**mandatory**
-->readdir() is gone now; switch to ->iterate()
+->readdir() is gone now; switch to ->iterate_shared()
**mandatory**
@@ -693,24 +693,19 @@ parallel now.
---
-**recommended**
+**mandatory**
-->iterate_shared() is added; it's a parallel variant of ->iterate().
+->iterate_shared() is added.
Exclusion on struct file level is still provided (as well as that
between it and lseek on the same struct file), but if your directory
has been opened several times, you can get these called in parallel.
Exclusion between that method and all directory-modifying ones is
still provided, of course.
-Often enough ->iterate() can serve as ->iterate_shared() without any
-changes - it is a read-only operation, after all. If you have any
-per-inode or per-dentry in-core data structures modified by ->iterate(),
-you might need something to serialize the access to them. If you
-do dcache pre-seeding, you'll need to switch to d_alloc_parallel() for
-that; look for in-tree examples.
-
-Old method is only used if the new one is absent; eventually it will
-be removed. Switch while you still can; the old one won't stay.
+If you have any per-inode or per-dentry in-core data structures modified
+by ->iterate_shared(), you might need something to serialize the access
+to them. If you do dcache pre-seeding, you'll need to switch to
+d_alloc_parallel() for that; look for in-tree examples.
---
@@ -863,7 +858,7 @@ be misspelled d_alloc_anon().
**mandatory**
-[should've been added in 2016] stale comment in finish_open() nonwithstanding,
+[should've been added in 2016] stale comment in finish_open() notwithstanding,
failure exits in ->atomic_open() instances should *NOT* fput() the file,
no matter what. Everything is handled by the caller.
@@ -930,6 +925,412 @@ should be done by looking at FMODE_LSEEK in file->f_mode.
filldir_t (readdir callbacks) calling conventions have changed. Instead of
returning 0 or -E... it returns bool now. false means "no more" (as -E... used
to) and true - "keep going" (as 0 in old calling conventions). Rationale:
-callers never looked at specific -E... values anyway. ->iterate() and
-->iterate_shared() instance require no changes at all, all filldir_t ones in
-the tree converted.
+callers never looked at specific -E... values anyway. -> iterate_shared()
+instances require no changes at all, all filldir_t ones in the tree
+converted.
+
+---
+
+**mandatory**
+
+Calling conventions for ->tmpfile() have changed. It now takes a struct
+file pointer instead of struct dentry pointer. d_tmpfile() is similarly
+changed to simplify callers. The passed file is in a non-open state and on
+success must be opened before returning (e.g. by calling
+finish_open_simple()).
+
+---
+
+**mandatory**
+
+Calling convention for ->huge_fault has changed. It now takes a page
+order instead of an enum page_entry_size, and it may be called without the
+mmap_lock held. All in-tree users have been audited and do not seem to
+depend on the mmap_lock being held, but out of tree users should verify
+for themselves. If they do need it, they can return VM_FAULT_RETRY to
+be called with the mmap_lock held.
+
+---
+
+**mandatory**
+
+The order of opening block devices and matching or creating superblocks has
+changed.
+
+The old logic opened block devices first and then tried to find a
+suitable superblock to reuse based on the block device pointer.
+
+The new logic tries to find a suitable superblock first based on the device
+number, and opening the block device afterwards.
+
+Since opening block devices cannot happen under s_umount because of lock
+ordering requirements s_umount is now dropped while opening block devices and
+reacquired before calling fill_super().
+
+In the old logic concurrent mounters would find the superblock on the list of
+superblocks for the filesystem type. Since the first opener of the block device
+would hold s_umount they would wait until the superblock became either born or
+was discarded due to initialization failure.
+
+Since the new logic drops s_umount concurrent mounters could grab s_umount and
+would spin. Instead they are now made to wait using an explicit wait-wake
+mechanism without having to hold s_umount.
+
+---
+
+**mandatory**
+
+The holder of a block device is now the superblock.
+
+The holder of a block device used to be the file_system_type which wasn't
+particularly useful. It wasn't possible to go from block device to owning
+superblock without matching on the device pointer stored in the superblock.
+This mechanism would only work for a single device so the block layer couldn't
+find the owning superblock of any additional devices.
+
+In the old mechanism reusing or creating a superblock for a racing mount(2) and
+umount(2) relied on the file_system_type as the holder. This was severely
+underdocumented however:
+
+(1) Any concurrent mounter that managed to grab an active reference on an
+ existing superblock was made to wait until the superblock either became
+ ready or until the superblock was removed from the list of superblocks of
+ the filesystem type. If the superblock is ready the caller would simple
+ reuse it.
+
+(2) If the mounter came after deactivate_locked_super() but before
+ the superblock had been removed from the list of superblocks of the
+ filesystem type the mounter would wait until the superblock was shutdown,
+ reuse the block device and allocate a new superblock.
+
+(3) If the mounter came after deactivate_locked_super() and after
+ the superblock had been removed from the list of superblocks of the
+ filesystem type the mounter would reuse the block device and allocate a new
+ superblock (the bd_holder point may still be set to the filesystem type).
+
+Because the holder of the block device was the file_system_type any concurrent
+mounter could open the block devices of any superblock of the same
+file_system_type without risking seeing EBUSY because the block device was
+still in use by another superblock.
+
+Making the superblock the owner of the block device changes this as the holder
+is now a unique superblock and thus block devices associated with it cannot be
+reused by concurrent mounters. So a concurrent mounter in (2) could suddenly
+see EBUSY when trying to open a block device whose holder was a different
+superblock.
+
+The new logic thus waits until the superblock and the devices are shutdown in
+->kill_sb(). Removal of the superblock from the list of superblocks of the
+filesystem type is now moved to a later point when the devices are closed:
+
+(1) Any concurrent mounter managing to grab an active reference on an existing
+ superblock is made to wait until the superblock is either ready or until
+ the superblock and all devices are shutdown in ->kill_sb(). If the
+ superblock is ready the caller will simply reuse it.
+
+(2) If the mounter comes after deactivate_locked_super() but before
+ the superblock has been removed from the list of superblocks of the
+ filesystem type the mounter is made to wait until the superblock and the
+ devices are shut down in ->kill_sb() and the superblock is removed from the
+ list of superblocks of the filesystem type. The mounter will allocate a new
+ superblock and grab ownership of the block device (the bd_holder pointer of
+ the block device will be set to the newly allocated superblock).
+
+(3) This case is now collapsed into (2) as the superblock is left on the list
+ of superblocks of the filesystem type until all devices are shutdown in
+ ->kill_sb(). In other words, if the superblock isn't on the list of
+ superblock of the filesystem type anymore then it has given up ownership of
+ all associated block devices (the bd_holder pointer is NULL).
+
+As this is a VFS level change it has no practical consequences for filesystems
+other than that all of them must use one of the provided kill_litter_super(),
+kill_anon_super(), or kill_block_super() helpers.
+
+---
+
+**mandatory**
+
+Lock ordering has been changed so that s_umount ranks above open_mutex again.
+All places where s_umount was taken under open_mutex have been fixed up.
+
+---
+
+**mandatory**
+
+export_operations ->encode_fh() no longer has a default implementation to
+encode FILEID_INO32_GEN* file handles.
+Filesystems that used the default implementation may use the generic helper
+generic_encode_ino32_fh() explicitly.
+
+---
+
+**mandatory**
+
+If ->rename() update of .. on cross-directory move needs an exclusion with
+directory modifications, do *not* lock the subdirectory in question in your
+->rename() - it's done by the caller now [that item should've been added in
+28eceeda130f "fs: Lock moved directories"].
+
+---
+
+**mandatory**
+
+On same-directory ->rename() the (tautological) update of .. is not protected
+by any locks; just don't do it if the old parent is the same as the new one.
+We really can't lock two subdirectories in same-directory rename - not without
+deadlocks.
+
+---
+
+**mandatory**
+
+lock_rename() and lock_rename_child() may fail in cross-directory case, if
+their arguments do not have a common ancestor. In that case ERR_PTR(-EXDEV)
+is returned, with no locks taken. In-tree users updated; out-of-tree ones
+would need to do so.
+
+---
+
+**mandatory**
+
+The list of children anchored in parent dentry got turned into hlist now.
+Field names got changed (->d_children/->d_sib instead of ->d_subdirs/->d_child
+for anchor/entries resp.), so any affected places will be immediately caught
+by compiler.
+
+---
+
+**mandatory**
+
+->d_delete() instances are now called for dentries with ->d_lock held
+and refcount equal to 0. They are not permitted to drop/regain ->d_lock.
+None of in-tree instances did anything of that sort. Make sure yours do not...
+
+---
+
+**mandatory**
+
+->d_prune() instances are now called without ->d_lock held on the parent.
+->d_lock on dentry itself is still held; if you need per-parent exclusions (none
+of the in-tree instances did), use your own spinlock.
+
+->d_iput() and ->d_release() are called with victim dentry still in the
+list of parent's children. It is still unhashed, marked killed, etc., just not
+removed from parent's ->d_children yet.
+
+Anyone iterating through the list of children needs to be aware of the
+half-killed dentries that might be seen there; taking ->d_lock on those will
+see them negative, unhashed and with negative refcount, which means that most
+of the in-kernel users would've done the right thing anyway without any adjustment.
+
+---
+
+**recommended**
+
+Block device freezing and thawing have been moved to holder operations.
+
+Before this change, get_active_super() would only be able to find the
+superblock of the main block device, i.e., the one stored in sb->s_bdev. Block
+device freezing now works for any block device owned by a given superblock, not
+just the main block device. The get_active_super() helper and bd_fsfreeze_sb
+pointer are gone.
+
+---
+
+**mandatory**
+
+set_blocksize() takes opened struct file instead of struct block_device now
+and it *must* be opened exclusive.
+
+---
+
+**mandatory**
+
+->d_revalidate() gets two extra arguments - inode of parent directory and
+name our dentry is expected to have. Both are stable (dir is pinned in
+non-RCU case and will stay around during the call in RCU case, and name
+is guaranteed to stay unchanging). Your instance doesn't have to use
+either, but it often helps to avoid a lot of painful boilerplate.
+Note that while name->name is stable and NUL-terminated, it may (and
+often will) have name->name[name->len] equal to '/' rather than '\0' -
+in normal case it points into the pathname being looked up.
+NOTE: if you need something like full path from the root of filesystem,
+you are still on your own - this assists with simple cases, but it's not
+magic.
+
+---
+
+**recommended**
+
+kern_path_locked() and user_path_locked() no longer return a negative
+dentry so this doesn't need to be checked. If the name cannot be found,
+ERR_PTR(-ENOENT) is returned.
+
+---
+
+**recommended**
+
+lookup_one_qstr_excl() is changed to return errors in more cases, so
+these conditions don't require explicit checks:
+
+ - if LOOKUP_CREATE is NOT given, then the dentry won't be negative,
+ ERR_PTR(-ENOENT) is returned instead
+ - if LOOKUP_EXCL IS given, then the dentry won't be positive,
+ ERR_PTR(-EEXIST) is rreturned instread
+
+LOOKUP_EXCL now means "target must not exist". It can be combined with
+LOOK_CREATE or LOOKUP_RENAME_TARGET.
+
+---
+
+**mandatory**
+invalidate_inodes() is gone use evict_inodes() instead.
+
+---
+
+**mandatory**
+
+->mkdir() now returns a dentry. If the created inode is found to
+already be in cache and have a dentry (often IS_ROOT()), it will need to
+be spliced into the given name in place of the given dentry. That dentry
+now needs to be returned. If the original dentry is used, NULL should
+be returned. Any error should be returned with ERR_PTR().
+
+In general, filesystems which use d_instantiate_new() to install the new
+inode can safely return NULL. Filesystems which may not have an I_NEW inode
+should use d_drop();d_splice_alias() and return the result of the latter.
+
+If a positive dentry cannot be returned for some reason, in-kernel
+clients such as cachefiles, nfsd, smb/server may not perform ideally but
+will fail-safe.
+
+---
+
+** mandatory**
+
+lookup_one(), lookup_one_unlocked(), lookup_one_positive_unlocked() now
+take a qstr instead of a name and len. These, not the "one_len"
+versions, should be used whenever accessing a filesystem from outside
+that filesysmtem, through a mount point - which will have a mnt_idmap.
+
+---
+
+** mandatory**
+
+Functions try_lookup_one_len(), lookup_one_len(),
+lookup_one_len_unlocked() and lookup_positive_unlocked() have been
+renamed to try_lookup_noperm(), lookup_noperm(),
+lookup_noperm_unlocked(), lookup_noperm_positive_unlocked(). They now
+take a qstr instead of separate name and length. QSTR() can be used
+when strlen() is needed for the length.
+
+These function no longer do any permission checking - they previously
+checked that the caller has 'X' permission on the parent. They must
+ONLY be used internally by a filesystem on itself when it knows that
+permissions are irrelevant or in a context where permission checks have
+already been performed such as after vfs_path_parent_lookup()
+
+---
+
+** mandatory**
+
+d_hash_and_lookup() is no longer exported or available outside the VFS.
+Use try_lookup_noperm() instead. This adds name validation and takes
+arguments in the opposite order but is otherwise identical.
+
+Using try_lookup_noperm() will require linux/namei.h to be included.
+
+---
+
+**mandatory**
+
+Calling conventions for ->d_automount() have changed; we should *not* grab
+an extra reference to new mount - it should be returned with refcount 1.
+
+---
+
+collect_mounts()/drop_collected_mounts()/iterate_mounts() are gone now.
+Replacement is collect_paths()/drop_collected_path(), with no special
+iterator needed. Instead of a cloned mount tree, the new interface returns
+an array of struct path, one for each mount collect_mounts() would've
+created. These struct path point to locations in the caller's namespace
+that would be roots of the cloned mounts.
+
+---
+
+**mandatory**
+
+If your filesystem sets the default dentry_operations, use set_default_d_op()
+rather than manually setting sb->s_d_op.
+
+---
+
+**mandatory**
+
+d_set_d_op() is no longer exported (or public, for that matter); _if_
+your filesystem really needed that, make use of d_splice_alias_ops()
+to have them set. Better yet, think hard whether you need different
+->d_op for different dentries - if not, just use set_default_d_op()
+at mount time and be done with that. Currently procfs is the only
+thing that really needs ->d_op varying between dentries.
+
+---
+
+**highly recommended**
+
+The file operations mmap() callback is deprecated in favour of
+mmap_prepare(). This passes a pointer to a vm_area_desc to the callback
+rather than a VMA, as the VMA at this stage is not yet valid.
+
+The vm_area_desc provides the minimum required information for a filesystem
+to initialise state upon memory mapping of a file-backed region, and output
+parameters for the file system to set this state.
+
+In nearly all cases, this is all that is required for a filesystem. However, if
+a filesystem needs to perform an operation such a pre-population of page tables,
+then that action can be specified in the vm_area_desc->action field, which can
+be configured using the mmap_action_*() helpers.
+
+---
+
+**mandatory**
+
+Several functions are renamed:
+
+- kern_path_locked -> start_removing_path
+- kern_path_create -> start_creating_path
+- user_path_create -> start_creating_user_path
+- user_path_locked_at -> start_removing_user_path_at
+- done_path_create -> end_creating_path
+
+---
+
+**mandatory**
+
+Calling conventions for vfs_parse_fs_string() have changed; it does *not*
+take length anymore (value ? strlen(value) : 0 is used). If you want
+a different length, use
+
+ vfs_parse_fs_qstr(fc, key, &QSTR_LEN(value, len))
+
+instead.
+
+---
+
+**mandatory**
+
+vfs_mkdir() now returns a dentry - the one returned by ->mkdir(). If
+that dentry is different from the dentry passed in, including if it is
+an IS_ERR() dentry pointer, the original dentry is dput().
+
+When vfs_mkdir() returns an error, and so both dputs() the original
+dentry and doesn't provide a replacement, it also unlocks the parent.
+Consequently the return value from vfs_mkdir() can be passed to
+end_creating() and the parent will be unlocked precisely when necessary.
+
+---
+
+**mandatory**
+
+kill_litter_super() is gone; convert to DCACHE_PERSISTENT use (as all
+in-tree filesystems have done).
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index e7aafc82be99..8256e857e2d7 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -47,6 +47,8 @@ fixes/update part 1.1 Stefani Seibold <stefani@seibold.net> June 9 2009
3.10 /proc/<pid>/timerslack_ns - Task timerslack value
3.11 /proc/<pid>/patch_state - Livepatch patch operation state
3.12 /proc/<pid>/arch_status - Task architecture specific information
+ 3.13 /proc/<pid>/fd - List of symlinks to open files
+ 3.14 /proc/<pid/ksm_stat - Information about the process's ksm status.
4 Configuring procfs
4.1 Mount options
@@ -59,19 +61,6 @@ Preface
0.1 Introduction/Credits
------------------------
-This documentation is part of a soon (or so we hope) to be released book on
-the SuSE Linux distribution. As there is no complete documentation for the
-/proc file system and we've used many freely available sources to write these
-chapters, it seems only fair to give the work back to the Linux community.
-This work is based on the 2.2.* kernel version and the upcoming 2.4.*. I'm
-afraid it's still far from complete, but we hope it will be useful. As far as
-we know, it is the first 'all-in-one' document about the /proc file system. It
-is focused on the Intel x86 hardware, so if you are looking for PPC, ARM,
-SPARC, AXP, etc., features, you probably won't find what you are looking for.
-It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But
-additions and patches are welcome and will be added to this document if you
-mail them to Bodo.
-
We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of
other people for help compiling this documentation. We'd also like to extend a
special thank you to Andi Kleen for documentation, which we relied on heavily
@@ -79,16 +68,8 @@ to create this document, as well as the additional information he provided.
Thanks to everybody else who contributed source or docs to the Linux kernel
and helped create a great piece of software... :)
-If you have any comments, corrections or additions, please don't hesitate to
-contact Bodo Bauer at bb@ricochet.net. We'll be happy to add them to this
-document.
-
The latest version of this document is available online at
-http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html
-
-If the above direction does not works for you, you could try the kernel
-mailing list at linux-kernel@vger.kernel.org and/or try to reach me at
-comandante@zaralinux.com.
+https://www.kernel.org/doc/html/latest/filesystems/proc.html
0.2 Legal Stuff
---------------
@@ -126,6 +107,16 @@ process running on the system, which is named after the process ID (PID).
The link 'self' points to the process reading the file system. Each process
subdirectory has the entries listed in Table 1-1.
+A process can read its own information from /proc/PID/* with no extra
+permissions. When reading /proc/PID/* information for other processes, reading
+process is required to have either CAP_SYS_PTRACE capability with
+PTRACE_MODE_READ access permissions, or, alternatively, CAP_PERFMON
+capability. This applies to all read-only information like `maps`, `environ`,
+`pagemap`, etc. The only exception is `mem` file due to its read-write nature,
+which requires CAP_SYS_PTRACE capabilities with more elevated
+PTRACE_MODE_ATTACH permissions; CAP_PERFMON capability does not grant access
+to /proc/PID/mem for other processes.
+
Note that an open file descriptor to /proc/<pid> or to any of its
contained files or subdirectories does not prevent <pid> being reused
for some other process in the event that <pid> exits. Operations on
@@ -178,6 +169,7 @@ read the file /proc/PID/status::
Gid: 100 100 100 100
FDSize: 256
Groups: 100 14 16
+ Kthread: 0
VmPeak: 5004 kB
VmSize: 5004 kB
VmLck: 0 kB
@@ -231,7 +223,7 @@ asynchronous manner and the value may not be very precise. To see a precise
snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table.
It's slow but very precise.
-.. table:: Table 1-2: Contents of the status files (as of 4.19)
+.. table:: Table 1-2: Contents of the status fields (as of 4.19)
========================== ===================================================
Field Content
@@ -245,7 +237,8 @@ It's slow but very precise.
Ngid NUMA group ID (0 if none)
Pid process id
PPid process id of the parent process
- TracerPid PID of process tracing this process (0 if not)
+ TracerPid PID of process tracing this process (0 if not, or
+ the tracer is outside of the current pid namespace)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
FDSize number of file descriptor slots currently allocated
@@ -254,6 +247,7 @@ It's slow but very precise.
NSpid descendant namespace process ID hierarchy
NSpgid descendant namespace process group ID hierarchy
NSsid descendant namespace session ID hierarchy
+ Kthread kernel thread flag, 1 is yes, 0 is no
VmPeak peak virtual memory size
VmSize total program size
VmLck locked memory size
@@ -276,8 +270,9 @@ It's slow but very precise.
HugetlbPages size of hugetlb memory portions
CoreDumping process's memory is currently being dumped
(killing the process may lead to a corrupted core)
- THP_enabled process is allowed to use THP (returns 0 when
- PR_SET_THP_DISABLE is set on the process
+ THP_enabled process is allowed to use THP (returns 0 when
+ PR_SET_THP_DISABLE is set on the process to disable
+ THP completely, not just partially)
Threads number of threads
SigQ number of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
@@ -303,7 +298,7 @@ It's slow but very precise.
========================== ===================================================
-.. table:: Table 1-3: Contents of the statm files (as of 2.6.8-rc3)
+.. table:: Table 1-3: Contents of the statm fields (as of 2.6.8-rc3)
======== =============================== ==============================
Field Content
@@ -321,7 +316,7 @@ It's slow but very precise.
======== =============================== ==============================
-.. table:: Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
+.. table:: Table 1-4: Contents of the stat fields (as of 2.6.30-rc7)
============= ===============================================================
Field Content
@@ -426,17 +421,28 @@ with the memory region, as the case would be with BSS (uninitialized data).
The "pathname" shows the name associated file for this mapping. If the mapping
is not associated with a file:
- ============= ====================================
+ =================== ===========================================
[heap] the heap of the program
[stack] the stack of the main process
[vdso] the "virtual dynamic shared object",
the kernel system call handler
- [anon:<name>] an anonymous mapping that has been
+ [anon:<name>] a private anonymous mapping that has been
named by userspace
- ============= ====================================
+ [anon_shmem:<name>] an anonymous shared memory mapping that has
+ been named by userspace
+ =================== ===========================================
or if empty, the mapping is anonymous.
+Starting with 6.11 kernel, /proc/PID/maps provides an alternative
+ioctl()-based API that gives ability to flexibly and efficiently query and
+filter individual VMAs. This interface is binary and is meant for more
+efficient and easy programmatic use. `struct procmap_query`, defined in
+linux/fs.h UAPI header, serves as an input/output argument to the
+`PROCMAP_QUERY` ioctl() command. See comments in linus/fs.h UAPI header for
+details on query semantics, supported flags, data returned, and general API
+usage information.
+
The /proc/PID/smaps is an extension based on maps, showing the memory
consumption for each of the process's mappings. For each mapping (aka Virtual
Memory Area, or VMA) there is a series of lines such as the following::
@@ -455,6 +461,7 @@ Memory Area, or VMA) there is a series of lines such as the following::
Private_Dirty: 0 kB
Referenced: 892 kB
Anonymous: 0 kB
+ KSM: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
@@ -468,14 +475,15 @@ Memory Area, or VMA) there is a series of lines such as the following::
THPeligible: 0
VmFlags: rd ex mr mw me dw
-The first of these lines shows the same information as is displayed for the
-mapping in /proc/PID/maps. Following lines show the size of the mapping
-(size); the size of each page allocated when backing a VMA (KernelPageSize),
-which is usually the same as the size in the page table entries; the page size
-used by the MMU when backing a VMA (in most cases, the same as KernelPageSize);
-the amount of the mapping that is currently resident in RAM (RSS); the
-process' proportional share of this mapping (PSS); and the number of clean and
-dirty shared and private pages in the mapping.
+The first of these lines shows the same information as is displayed for
+the mapping in /proc/PID/maps. Following lines show the size of the
+mapping (size); the size of each page allocated when backing a VMA
+(KernelPageSize), which is usually the same as the size in the page table
+entries; the page size used by the MMU when backing a VMA (in most cases,
+the same as KernelPageSize); the amount of the mapping that is currently
+resident in RAM (RSS); the process's proportional share of this mapping
+(PSS); and the number of clean and dirty shared and private pages in the
+mapping.
The "proportional set size" (PSS) of a process is the count of pages it has
in memory, where each page is divided by the number of processes sharing it.
@@ -484,9 +492,25 @@ process, its PSS will be 1500. "Pss_Dirty" is the portion of PSS which
consists of dirty pages. ("Pss_Clean" is not included, but it can be
calculated by subtracting "Pss_Dirty" from "Pss".)
-Note that even a page which is part of a MAP_SHARED mapping, but has only
-a single pte mapped, i.e. is currently used by only one process, is accounted
-as private and not as shared.
+Traditionally, a page is accounted as "private" if it is mapped exactly once,
+and a page is accounted as "shared" when mapped multiple times, even when
+mapped in the same process multiple times. Note that this accounting is
+independent of MAP_SHARED.
+
+In some kernel configurations, the semantics of pages part of a larger
+allocation (e.g., THP) can differ: a page is accounted as "private" if all
+pages part of the corresponding large allocation are *certainly* mapped in the
+same process, even if the page is mapped multiple times in that process. A
+page is accounted as "shared" if any page page of the larger allocation
+is *maybe* mapped in a different process. In some cases, a large allocation
+might be treated as "maybe mapped by multiple processes" even though this
+is no longer the case.
+
+Some kernel configurations do not track the precise number of times a page part
+of a larger allocation is mapped. In this case, when calculating the PSS, the
+average number of mappings per page in this larger allocation might be used
+as an approximation for the number of mappings of a page. The PSS calculation
+will be imprecise in this case.
"Referenced" indicates the amount of memory currently marked as referenced or
accessed.
@@ -495,18 +519,21 @@ accessed.
a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
and a page is modified, the file page is replaced by a private anonymous copy.
+"KSM" reports how many of the pages are KSM pages. Note that KSM-placed zeropages
+are not included, only actual KSM pages.
+
"LazyFree" shows the amount of memory which is marked by madvise(MADV_FREE).
The memory isn't freed immediately with madvise(). It's freed in memory
pressure if the memory is clean. Please note that the printed value might
be lower than the real value due to optimizations used in the current
implementation. If this is not desirable please file a bug report.
-"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
+"AnonHugePages" shows the amount of memory backed by transparent hugepage.
-"ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by
+"ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by
huge pages.
-"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by
+"Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by
hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical
reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field.
@@ -518,15 +545,15 @@ replaced by copy-on-write) part of the underlying shmem object out on swap.
does not take into account swapped out page of underlying shmem objects.
"Locked" indicates whether the mapping is locked in memory or not.
-"THPeligible" indicates whether the mapping is eligible for allocating THP
-pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise.
-It just shows the current status.
+"THPeligible" indicates whether the mapping is eligible for allocating
+naturally aligned THP pages of any currently enabled size. 1 if true, 0
+otherwise.
"VmFlags" field deserves a separate description. This member represents the
kernel flags associated with the particular virtual memory area in two letter
encoded manner. The codes are the following:
- == =======================================
+ == =============================================================
rd readable
wr writeable
ex executable
@@ -537,7 +564,6 @@ encoded manner. The codes are the following:
ms may share
gd stack segment growns down
pf pure PFN range
- dw disabled write to the mapped file
lo pages are locked in memory
io memory mapped I/O area
sr sequential read advise provided
@@ -555,12 +581,18 @@ encoded manner. The codes are the following:
mm mixed map area
hg huge page advise flag
nh no huge page advise flag
- mg mergable advise flag
+ mg mergeable advise flag
bt arm64 BTI guarded page
mt arm64 MTE allocation tags are enabled
um userfaultfd missing tracking
uw userfaultfd wr-protect tracking
- == =======================================
+ ui userfaultfd minor fault
+ ss shadow/guarded control stack page
+ sl sealed
+ lf lock on fault pages
+ dp always lazily freeable mapping
+ gu maybe contains guard regions (if not set, definitely doesn't)
+ == =============================================================
Note that there is no guarantee that every flag and associated mnemonic will
be present in all further kernel releases. Things get changed, the flags may
@@ -663,6 +695,11 @@ Where:
node locality page counters (N0 == node0, N1 == node1, ...) and the kernel page
size, in KB, that is backing the mapping up.
+Note that some kernel configurations do not track the precise number of times
+a page part of a larger allocation (e.g., THP) is mapped. In these
+configurations, "mapmax" might corresponds to the average number of mappings
+per page in such a larger allocation instead.
+
1.2 Kernel data
---------------
@@ -677,10 +714,17 @@ files are there, and which are missing.
============ ===============================================================
File Content
============ ===============================================================
+ allocinfo Memory allocations profiling information
apm Advanced power management info
+ bootconfig Kernel command line obtained from boot config,
+ and, if there were kernel parameters from the
+ boot loader, a "# Parameters from bootloader:"
+ line followed by a line containing those
+ parameters prefixed by "# ". (5.5)
buddyinfo Kernel memory allocator information (see text) (2.5)
bus Directory containing bus specific information
- cmdline Kernel command line
+ cmdline Kernel command line, both from bootloader and embedded
+ in the kernel image
cpuinfo Info about the CPU
devices Available devices (block and character)
dma Used DMS channels
@@ -936,6 +980,48 @@ also be allocatable although a lot of filesystem metadata may have to be
reclaimed to achieve this.
+allocinfo
+~~~~~~~~~
+
+Provides information about memory allocations at all locations in the code
+base. Each allocation in the code is identified by its source file, line
+number, module (if originates from a loadable module) and the function calling
+the allocation. The number of bytes allocated and number of calls at each
+location are reported. The first line indicates the version of the file, the
+second line is the header listing fields in the file.
+If file version is 2.0 or higher then each line may contain additional
+<key>:<value> pairs representing extra information about the call site.
+For example if the counters are not accurate, the line will be appended with
+"accurate:no" pair.
+
+Supported markers in v2:
+accurate:no
+
+ Absolute values of the counters in this line are not accurate
+ because of the failure to allocate memory to track some of the
+ allocations made at this location. Deltas in these counters are
+ accurate, therefore counters can be used to track allocation size
+ and count changes.
+
+Example output.
+
+::
+
+ > tail -n +3 /proc/allocinfo | sort -rn
+ 127664128 31168 mm/page_ext.c:270 func:alloc_page_ext
+ 56373248 4737 mm/slub.c:2259 func:alloc_slab_page
+ 14880768 3633 mm/readahead.c:247 func:page_cache_ra_unbounded
+ 14417920 3520 mm/mm_init.c:2530 func:alloc_large_system_hash
+ 13377536 234 block/blk-mq.c:3421 func:blk_mq_alloc_rqs
+ 11718656 2861 mm/filemap.c:1919 func:__filemap_get_folio
+ 9192960 2800 kernel/fork.c:307 func:alloc_thread_stack_node
+ 4206592 4 net/netfilter/nf_conntrack_core.c:2567 func:nf_ct_alloc_hashtable
+ 4136960 1010 drivers/staging/ctagmod/ctagmod.c:20 [ctagmod] func:ctagmod_start
+ 3940352 962 mm/memory.c:4214 func:alloc_anon_folio
+ 2894464 22613 fs/kernfs/dir.c:615 func:__kernfs_new_node
+ ...
+
+
meminfo
~~~~~~~
@@ -982,6 +1068,7 @@ Example output. You may not have all of these fields.
SUnreclaim: 142336 kB
KernelStack: 11168 kB
PageTables: 20540 kB
+ SecPageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
@@ -991,6 +1078,7 @@ Example output. You may not have all of these fields.
VmallocUsed: 40444 kB
VmallocChunk: 0 kB
Percpu: 29312 kB
+ EarlyMemtestBad: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 4149248 kB
ShmemHugePages: 0 kB
@@ -999,6 +1087,8 @@ Example output. You may not have all of these fields.
FilePmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
+ Unaccepted: 0 kB
+ Balloon: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
@@ -1071,9 +1161,15 @@ Dirty
Writeback
Memory which is actively being written back to the disk
AnonPages
- Non-file backed pages mapped into userspace page tables
+ Non-file backed pages mapped into userspace page tables. Note that
+ some kernel configurations might consider all pages part of a
+ larger allocation (e.g., THP) as "mapped", as soon as a single
+ page is mapped.
Mapped
- files which have been mmaped, such as libraries
+ files which have been mmapped, such as libraries. Note that some
+ kernel configurations might consider all pages part of a larger
+ allocation (e.g., THP) as "mapped", as soon as a single page is
+ mapped.
Shmem
Total memory used by shared memory (shmem) and tmpfs
KReclaimable
@@ -1090,13 +1186,18 @@ KernelStack
Memory consumed by the kernel stacks of all tasks
PageTables
Memory consumed by userspace page tables
+SecPageTables
+ Memory consumed by secondary page tables, this currently includes
+ KVM mmu and IOMMU allocations on x86 and arm64.
NFS_Unstable
- Always zero. Previous counted pages which had been written to
+ Always zero. Previously counted pages which had been written to
the server, but has not been committed to stable storage.
Bounce
- Memory used for block device "bounce buffers"
+ Always zero. Previously memory used for block device
+ "bounce buffers".
WritebackTmp
- Memory used by FUSE for temporary writeback buffers
+ Always zero. Previously memory used by FUSE for temporary
+ writeback buffers.
CommitLimit
Based on the overcommit ratio ('vm.overcommit_ratio'),
this is the total amount of memory currently available to
@@ -1138,6 +1239,13 @@ VmallocChunk
Percpu
Memory allocated to the percpu allocator used to back percpu
allocations. This stat excludes the cost of metadata.
+EarlyMemtestBad
+ The amount of RAM/memory in kB, that was identified as corrupted
+ by early memtest. If memtest was not run, this field will not
+ be displayed at all. Size is never rounded down to 0 kB.
+ That means if 0 kB is reported, you can safely assume
+ there was at least one pass of memtest and none of the passes
+ found a single faulty byte of RAM.
HardwareCorrupted
The amount of RAM/memory in KB, the kernel identifies as
corrupted.
@@ -1157,6 +1265,10 @@ CmaTotal
Memory reserved for the Contiguous Memory Allocator (CMA)
CmaFree
Free remaining memory in the CMA reserves
+Unaccepted
+ Memory that has not been accepted by the guest
+Balloon
+ Memory returned to Host by VM Balloon Drivers
HugePages_Total, HugePages_Free, HugePages_Rsvd, HugePages_Surp, Hugepagesize, Hugetlb
See Documentation/admin-guide/mm/hugetlbpage.rst.
DirectMap4k, DirectMap2M, DirectMap1G
@@ -1276,6 +1388,7 @@ support this. Table 1-9 lists the files and their meaning.
rt_cache Routing cache
snmp SNMP data
sockstat Socket statistics
+ softnet_stat Per-CPU incoming packets queues statistics of online CPUs
tcp TCP sockets
udp UDP sockets
unix UNIX domain sockets
@@ -1312,9 +1425,9 @@ many times the slaves link has failed.
1.4 SCSI info
-------------
-If you have a SCSI host adapter in your system, you'll find a subdirectory
-named after the driver for this adapter in /proc/scsi. You'll also see a list
-of all recognized SCSI devices in /proc/scsi::
+If you have a SCSI or ATA host adapter in your system, you'll find a
+subdirectory named after the driver for this adapter in /proc/scsi.
+You'll also see a list of all recognized SCSI devices in /proc/scsi::
>cat /proc/scsi/scsi
Attached devices:
@@ -1440,16 +1553,18 @@ Various pieces of information about kernel activity are available in the
since the system first booted. For a quick look, simply cat the file::
> cat /proc/stat
- cpu 2255 34 2290 22625563 6290 127 456 0 0 0
- cpu0 1132 34 1441 11311718 3675 127 438 0 0 0
- cpu1 1123 0 849 11313845 2614 0 18 0 0 0
- intr 114930548 113199788 3 0 5 263 0 4 [... lots more numbers ...]
- ctxt 1990473
- btime 1062191376
- processes 2915
- procs_running 1
+ cpu 237902850 368826709 106375398 1873517540 1135548 0 14507935 0 0 0
+ cpu0 60045249 91891769 26331539 468411416 495718 0 5739640 0 0 0
+ cpu1 59746288 91759249 26609887 468860630 312281 0 4384817 0 0 0
+ cpu2 59489247 92985423 26904446 467808813 171668 0 2268998 0 0 0
+ cpu3 58622065 92190267 26529524 468436680 155879 0 2114478 0 0 0
+ intr 8688370575 8 3373 0 0 0 0 0 0 1 40791 0 0 353317 0 0 0 0 224789828 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 190974333 41958554 123983334 43 0 224593 0 0 0 <more 0's deleted>
+ ctxt 22848221062
+ btime 1605316999
+ processes 746787147
+ procs_running 2
procs_blocked 0
- softirq 183433 0 21755 12 39 1137 231 21459 2263
+ softirq 12121874454 100099120 3938138295 127375644 2795979 187870761 0 173808342 3072582055 52608 224184354
The very first "cpu" line aggregates the numbers in all of the other "cpuN"
lines. These numbers identify the amount of time the CPU has spent performing
@@ -1511,8 +1626,8 @@ softirq.
Information about mounted ext4 file systems can be found in
/proc/fs/ext4. Each mounted filesystem will have a directory in
/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
-/proc/fs/ext4/dm-0). The files in each per-device directory are shown
-in Table 1-12, below.
+/proc/fs/ext4/sda9 or /proc/fs/ext4/dm-0). The files in each per-device
+directory are shown in Table 1-12, below.
.. table:: Table 1-12: Files in /proc/fs/ext4/<devname>
@@ -1592,12 +1707,12 @@ can inadvertently disrupt your system, it is advisable to read both
documentation and source before actually making adjustments. In any case, be
very careful when writing to any of these files. The entries in /proc may
change slightly between the 2.1.* and the 2.2 kernel, so if there is any doubt
-review the kernel documentation in the directory /usr/src/linux/Documentation.
+review the kernel documentation in the directory linux/Documentation.
This chapter is heavily based on the documentation included in the pre 2.2
kernels, and became part of it in version 2.2.1 of the Linux kernel.
-Please see: Documentation/admin-guide/sysctl/ directory for descriptions of these
-entries.
+Please see: Documentation/admin-guide/sysctl/ directory for descriptions of
+these entries.
Summary
-------
@@ -1867,8 +1982,8 @@ For more information on mount propagation see:
These files provide a method to access a task's comm value. It also allows for
a task to set its own or one of its thread siblings comm value. The comm value
is limited in size compared to the cmdline value, so writing anything longer
-then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
-comm value.
+then the kernel's TASK_COMM_LEN (currently 16 chars, including the NUL
+terminator) will result in a truncated comm value.
3.7 /proc/<pid>/task/<tid>/children - Information about task children
@@ -2045,6 +2160,20 @@ DMA Buffer files
where 'size' is the size of the DMA buffer in bytes. 'count' is the file count of
the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter.
+VFIO Device files
+~~~~~~~~~~~~~~~~~
+
+::
+
+ pos: 0
+ flags: 02000002
+ mnt_id: 17
+ ino: 5122
+ vfio-device-syspath: /sys/devices/pci0000:e0/0000:e0:01.1/0000:e1:00.0/0000:e2:05.0/0000:e8:00.0
+
+where 'vfio-device-syspath' is the sysfs path corresponding to the VFIO device
+file.
+
3.9 /proc/<pid>/map_files - Information about memory mapped files
---------------------------------------------------------------------
This directory contains symbolic links which represent memory mapped files
@@ -2145,6 +2274,90 @@ AVX512_elapsed_ms
the task is unlikely an AVX512 user, but depends on the workload and the
scheduling scenario, it also could be a false negative mentioned above.
+3.13 /proc/<pid>/fd - List of symlinks to open files
+-------------------------------------------------------
+This directory contains symbolic links which represent open files
+the process is maintaining. Example output::
+
+ lr-x------ 1 root root 64 Sep 20 17:53 0 -> /dev/null
+ l-wx------ 1 root root 64 Sep 20 17:53 1 -> /dev/null
+ lrwx------ 1 root root 64 Sep 20 17:53 10 -> 'socket:[12539]'
+ lrwx------ 1 root root 64 Sep 20 17:53 11 -> 'socket:[12540]'
+ lrwx------ 1 root root 64 Sep 20 17:53 12 -> 'socket:[12542]'
+
+The number of open files for the process is stored in 'size' member
+of stat() output for /proc/<pid>/fd for fast access.
+-------------------------------------------------------
+
+3.14 /proc/<pid/ksm_stat - Information about the process's ksm status
+---------------------------------------------------------------------
+When CONFIG_KSM is enabled, each process has this file which displays
+the information of ksm merging status.
+
+Example
+~~~~~~~
+
+::
+
+ / # cat /proc/self/ksm_stat
+ ksm_rmap_items 0
+ ksm_zero_pages 0
+ ksm_merging_pages 0
+ ksm_process_profit 0
+ ksm_merge_any: no
+ ksm_mergeable: no
+
+Description
+~~~~~~~~~~~
+
+ksm_rmap_items
+^^^^^^^^^^^^^^
+
+The number of ksm_rmap_item structures in use. The structure
+ksm_rmap_item stores the reverse mapping information for virtual
+addresses. KSM will generate a ksm_rmap_item for each ksm-scanned page of
+the process.
+
+ksm_zero_pages
+^^^^^^^^^^^^^^
+
+When /sys/kernel/mm/ksm/use_zero_pages is enabled, it represent how many
+empty pages are merged with kernel zero pages by KSM.
+
+ksm_merging_pages
+^^^^^^^^^^^^^^^^^
+
+It represents how many pages of this process are involved in KSM merging
+(not including ksm_zero_pages). It is the same with what
+/proc/<pid>/ksm_merging_pages shows.
+
+ksm_process_profit
+^^^^^^^^^^^^^^^^^^
+
+The profit that KSM brings (Saved bytes). KSM can save memory by merging
+identical pages, but also can consume additional memory, because it needs
+to generate a number of rmap_items to save each scanned page's brief rmap
+information. Some of these pages may be merged, but some may not be abled
+to be merged after being checked several times, which are unprofitable
+memory consumed.
+
+ksm_merge_any
+^^^^^^^^^^^^^
+
+It specifies whether the process's 'mm is added by prctl() into the
+candidate list of KSM or not, and if KSM scanning is fully enabled at
+process level.
+
+ksm_mergeable
+^^^^^^^^^^^^^
+
+It specifies whether any VMAs of the process''s mms are currently
+applicable to KSM.
+
+More information about KSM can be found in
+Documentation/admin-guide/mm/ksm.rst.
+
+
Chapter 4: Configuring procfs
=============================
@@ -2157,6 +2370,7 @@ The following mount options are supported:
hidepid= Set /proc/<pid>/ access mode.
gid= Set the group authorized to learn processes information.
subset= Show only the specified subset of procfs.
+ pidns= Specify a the namespace used by this procfs.
========= ========================================================
hidepid=off or hidepid=0 means classic mode - everybody may access all
@@ -2173,7 +2387,7 @@ arguments are now protected against local eavesdroppers.
hidepid=invisible or hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be
fully invisible to other users. It doesn't mean that it hides a fact whether a
process with a specific pid value exists (it can be learned by other means, e.g.
-by "kill -0 $PID"), but it hides process' uid and gid, which may be learned by
+by "kill -0 $PID"), but it hides process's uid and gid, which may be learned by
stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task of
gathering information about running processes, whether some daemon runs with
elevated privileges, whether other user runs some sensitive program, whether
@@ -2189,10 +2403,17 @@ information about processes information, just add identd to this group.
subset=pid hides all top level files and directories in the procfs that
are not related to tasks.
+pidns= specifies a pid namespace (either as a string path to something like
+`/proc/$pid/ns/pid`, or a file descriptor when using `FSCONFIG_SET_FD`) that
+will be used by the procfs instance when translating pids. By default, procfs
+will use the calling process's active pid namespace. Note that the pid
+namespace of an existing procfs instance cannot be modified (attempting to do
+so will give an `-EBUSY` error).
+
Chapter 5: Filesystem behavior
==============================
-Originally, before the advent of pid namepsace, procfs was a global file
+Originally, before the advent of pid namespace, procfs was a global file
system. It means that there was only one procfs instance in the system.
When pid namespace was added, a separate procfs instance was mounted in
diff --git a/Documentation/filesystems/propagate_umount.txt b/Documentation/filesystems/propagate_umount.txt
new file mode 100644
index 000000000000..9a7eb96df300
--- /dev/null
+++ b/Documentation/filesystems/propagate_umount.txt
@@ -0,0 +1,484 @@
+ Notes on propagate_umount()
+
+Umount propagation starts with a set of mounts we are already going to
+take out. Ideally, we would like to add all downstream cognates to
+that set - anything with the same mountpoint as one of the removed
+mounts and with parent that would receive events from the parent of that
+mount. However, there are some constraints the resulting set must
+satisfy.
+
+It is convenient to define several properties of sets of mounts:
+
+1) A set S of mounts is non-shifting if for any mount X belonging
+to S all subtrees mounted strictly inside of X (i.e. not overmounting
+the root of X) contain only elements of S.
+
+2) A set S is non-revealing if all locked mounts that belong to S have
+parents that also belong to S.
+
+3) A set S is closed if it contains all children of its elements.
+
+The set of mounts taken out by umount(2) must be non-shifting and
+non-revealing; the first constraint is what allows to reparent
+any remaining mounts and the second is what prevents the exposure
+of any concealed mountpoints.
+
+propagate_umount() takes the original set as an argument and tries to
+extend that set. The original set is a full subtree and its root is
+unlocked; what matters is that it's closed and non-revealing.
+Resulting set may not be closed; there might still be mounts outside
+of that set, but only on top of stacks of root-overmounting elements
+of set. They can be reparented to the place where the bottom of
+stack is attached to a mount that will survive. NOTE: doing that
+will violate a constraint on having no more than one mount with
+the same parent/mountpoint pair; however, the caller (umount_tree())
+will immediately remedy that - it may keep unmounted element attached
+to parent, but only if the parent itself is unmounted. Since all
+conflicts created by reparenting have common parent *not* in the
+set and one side of the conflict (bottom of the stack of overmounts)
+is in the set, it will be resolved. However, we rely upon umount_tree()
+doing that pretty much immediately after the call of propagate_umount().
+
+Algorithm is based on two statements:
+ 1) for any set S, there is a maximal non-shifting subset of S
+and it can be calculated in O(#S) time.
+ 2) for any non-shifting set S, there is a maximal non-revealing
+subset of S. That subset is also non-shifting and it can be calculated
+in O(#S) time.
+
+ Finding candidates.
+
+We are given a closed set U and we want to find all mounts that have
+the same mountpoint as some mount m in U *and* whose parent receives
+propagation from the parent of the same mount m. Naive implementation
+would be
+ S = {}
+ for each m in U
+ add m to S
+ p = parent(m)
+ for each q in Propagation(p) - {p}
+ child = look_up(q, mountpoint(m))
+ if child
+ add child to S
+but that can lead to excessive work - there might be propagation among the
+subtrees of U, in which case we'd end up examining the same candidates
+many times. Since propagation is transitive, the same will happen to
+everything downstream of that candidate and it's not hard to construct
+cases where the approach above leads to the time quadratic by the actual
+number of candidates.
+
+Note that if we run into a candidate we'd already seen, it must've been
+added on an earlier iteration of the outer loop - all additions made
+during one iteration of the outer loop have different parents. So
+if we find a child already added to the set, we know that everything
+in Propagation(parent(child)) with the same mountpoint has been already
+added.
+ S = {}
+ for each m in U
+ if m in S
+ continue
+ add m to S
+ p = parent(m)
+ q = propagation_next(p, p)
+ while q
+ child = look_up(q, mountpoint(m))
+ if child
+ if child in S
+ q = skip_them(q, p)
+ continue;
+ add child to S
+ q = propagation_next(q, p)
+where
+skip_them(q, p)
+ keep walking Propagation(p) from q until we find something
+ not in Propagation(q)
+
+would get rid of that problem, but we need a sane implementation of
+skip_them(). That's not hard to do - split propagation_next() into
+"down into mnt_slave_list" and "forward-and-up" parts, with the
+skip_them() being "repeat the forward-and-up part until we get NULL
+or something that isn't a peer of the one we are skipping".
+
+Note that there can be no absolute roots among the extra candidates -
+they all come from mount lookups. Absolute root among the original
+set is _currently_ impossible, but it might be worth protecting
+against.
+
+ Maximal non-shifting subsets.
+
+Let's call a mount m in a set S forbidden in that set if there is a
+subtree mounted strictly inside m and containing mounts that do not
+belong to S.
+
+The set is non-shifting when none of its elements are forbidden in it.
+
+If mount m is forbidden in a set S, it is forbidden in any subset S' it
+belongs to. In other words, it can't belong to any of the non-shifting
+subsets of S. If we had a way to find a forbidden mount or show that
+there's none, we could use it to find the maximal non-shifting subset
+simply by finding and removing them until none remain.
+
+Suppose mount m is forbidden in S; then any mounts forbidden in S - {m}
+must have been forbidden in S itself. Indeed, since m has descendents
+that do not belong to S, any subtree that fits into S will fit into
+S - {m} as well.
+
+So in principle we could go through elements of S, checking if they
+are forbidden in S and removing the ones that are. Removals will
+not invalidate the checks done for earlier mounts - if they were not
+forbidden at the time we checked, they won't become forbidden later.
+It's too costly to be practical, but there is a similar approach that
+is linear by size of S.
+
+Let's say that mount x in a set S is forbidden by mount y, if
+ * both x and y belong to S.
+ * there is a chain of mounts starting at x and leaving S
+ immediately after passing through y, with the first
+ mountpoint strictly inside x.
+Note 1: x may be equal to y - that's the case when something not
+belonging to S is mounted strictly inside x.
+Note 2: if y does not belong to S, it can't forbid anything in S.
+Note 3: if y has no children outside of S, it can't forbid anything in S.
+
+It's easy to show that mount x is forbidden in S if and only if x is
+forbidden in S by some mount y. And it's easy to find all mounts in S
+forbidden by a given mount.
+
+Consider the following operation:
+ Trim(S, m) = S - {x : x is forbidden by m in S}
+
+Note that if m does not belong to S or has no children outside of S we
+are guaranteed that Trim(S, m) is equal to S.
+
+The following is true: if x is forbidden by y in Trim(S, m), it was
+already forbidden by y in S.
+
+Proof: Suppose x is forbidden by y in Trim(S, m). Then there is a
+chain of mounts (x_0 = x, ..., x_k = y, x_{k+1} = r), such that x_{k+1}
+is the first element that doesn't belong to Trim(S, m) and the
+mountpoint of x_1 is strictly inside x. If mount r belongs to S, it must
+have been removed by Trim(S, m), i.e. it was forbidden in S by m.
+Then there was a mount chain from r to some child of m that stayed in
+S all the way until m, but that's impossible since x belongs to Trim(S, m)
+and prepending (x_0, ..., x_k) to that chain demonstrates that x is also
+forbidden in S by m, and thus can't belong to Trim(S, m).
+Therefore r can not belong to S and our chain demonstrates that
+x is forbidden by y in S. QED.
+
+Corollary: no mount is forbidden by m in Trim(S, m). Indeed, any
+such mount would have been forbidden by m in S and thus would have been
+in the part of S removed in Trim(S, m).
+
+Corollary: no mount is forbidden by m in Trim(Trim(S, m), n). Indeed,
+any such would have to have been forbidden by m in Trim(S, m), which
+is impossible.
+
+Corollary: after
+ S = Trim(S, x_1)
+ S = Trim(S, x_2)
+ ...
+ S = Trim(S, x_k)
+no mount remaining in S will be forbidden by either of x_1,...,x_k.
+
+The following will reduce S to its maximal non-shifting subset:
+ visited = {}
+ while S contains elements not belonging to visited
+ let m be an arbitrary such element of S
+ S = Trim(S, m)
+ add m to visited
+
+S never grows, so the number of elements of S not belonging to visited
+decreases at least by one on each iteration. When the loop terminates,
+all mounts remaining in S belong to visited. It's easy to see that at
+the beginning of each iteration no mount remaining in S will be forbidden
+by any element of visited. In other words, no mount remaining in S will
+be forbidden, i.e. final value of S will be non-shifting. It will be
+the maximal non-shifting subset, since we were removing only forbidden
+elements.
+
+ There are two difficulties in implementing the above in linear
+time, both due to the fact that Trim() might need to remove more than one
+element. Naive implementation of Trim() is vulnerable to running into a
+long chain of mounts, each mounted on top of parent's root. Nothing in
+that chain is forbidden, so nothing gets removed from it. We need to
+recognize such chains and avoid walking them again on subsequent calls of
+Trim(), otherwise we will end up with worst-case time being quadratic by
+the number of elements in S. Another difficulty is in implementing the
+outer loop - we need to iterate through all elements of a shrinking set.
+That would be trivial if we never removed more than one element at a time
+(linked list, with list_for_each_entry_safe for iterator), but we may
+need to remove more than one entry, possibly including the ones we have
+already visited.
+
+ Let's start with naive algorithm for Trim():
+
+Trim_one(m)
+ found = false
+ for each n in children(m)
+ if n not in S
+ found = true
+ if (mountpoint(n) != root(m))
+ remove m from S
+ break
+ if found
+ Trim_ancestors(m)
+
+Trim_ancestors(m)
+ for (; parent(m) in S; m = parent(m)) {
+ if (mountpoint(m) != root(parent(m)))
+ remove parent(m) from S
+ }
+
+If m belongs to S, Trim_one(m) will replace S with Trim(S, m).
+Proof:
+ Consider the chains excluding elements from Trim(S, m). The last
+two elements in such chain are m and some child of m that does not belong
+to S. If m has no such children, Trim(S, m) is equal to S.
+ m itself is removed if and only if the chain has exactly two
+elements, i.e. when the last element does not overmount the root of m.
+In other words, that happens when m has a child not in S that does not
+overmount the root of m.
+ All other elements to remove will be ancestors of m, such that
+the entire descent chain from them to m is contained in S. Let
+(x_0, x_1, ..., x_k = m) be the longest such chain. x_i needs to be
+removed if and only if x_{i+1} does not overmount its root. It's easy
+to see that Trim_ancestors(m) will iterate through that chain from
+x_k to x_1 and that it will remove exactly the elements that need to be
+removed.
+
+ Note that if the loop in Trim_ancestors() walks into an already
+visited element, we are guaranteed that remaining iterations will see
+only elements that had already been visited and remove none of them.
+That's the weakness that makes it vulnerable to long chains of full
+overmounts.
+
+ It's easy to deal with, if we can afford setting marks on
+elements of S; we would mark all elements already visited by
+Trim_ancestors() and have it bail out as soon as it sees an already
+marked element.
+
+ The problems with iterating through the set can be dealt with in
+several ways, depending upon the representation we choose for our set.
+One useful observation is that we are given a closed subset in S - the
+original set passed to propagate_umount(). Its elements can neither
+forbid anything nor be forbidden by anything - all their descendents
+belong to S, so they can not occur anywhere in any excluding chain.
+In other words, the elements of that subset will remain in S until
+the end and Trim_one(S, m) is a no-op for all m from that subset.
+
+ That suggests keeping S as a disjoint union of a closed set U
+('will be unmounted, no matter what') and the set of all elements of
+S that do not belong to U. That set ('candidates') is all we need
+to iterate through. Let's represent it as a subset in a cyclic list,
+consisting of all list elements that are marked as candidates (initially -
+all of them). Then we could have Trim_ancestors() only remove the mark,
+leaving the elements on the list. Then Trim_one() would never remove
+anything other than its argument from the containing list, allowing to
+use list_for_each_entry_safe() as iterator.
+
+ Assuming that representation we get the following:
+
+ list_for_each_entry_safe(m, ..., Candidates, ...)
+ Trim_one(m)
+where
+Trim_one(m)
+ if (m is not marked as a candidate)
+ strip the "seen by Trim_ancestors" mark from m
+ remove m from the Candidates list
+ return
+
+ remove_this = false
+ found = false
+ for each n in children(m)
+ if n not in S
+ found = true
+ if (mountpoint(n) != root(m))
+ remove_this = true
+ break
+ if found
+ Trim_ancestors(m)
+ if remove_this
+ strip the "seen by Trim_ancestors" mark from m
+ strip the "candidate" mark from m
+ remove m from the Candidate list
+
+Trim_ancestors(m)
+ for (p = parent(m); p is marked as candidate ; m = p, p = parent(p)) {
+ if m is marked as seen by Trim_ancestors
+ return
+ mark m as seen by Trim_ancestors
+ if (mountpoint(m) != root(p))
+ strip the "candidate" mark from p
+ }
+
+ Terminating condition in the loop in Trim_ancestors() is correct,
+since that loop will never run into p belonging to U - p is always
+an ancestor of argument of Trim_one() and since U is closed, the argument
+of Trim_one() would also have to belong to U. But Trim_one() is never
+called for elements of U. In other words, p belongs to S if and only
+if it belongs to candidates.
+
+ Time complexity:
+* we get no more than O(#S) calls of Trim_one()
+* the loop over children in Trim_one() never looks at the same child
+twice through all the calls.
+* iterations of that loop for children in S are no more than O(#S)
+in the worst case
+* at most two children that are not elements of S are considered per
+call of Trim_one().
+* the loop in Trim_ancestors() sets its mark once per iteration and
+no element of S has is set more than once.
+
+ In the end we may have some elements excluded from S by
+Trim_ancestors() still stuck on the list. We could do a separate
+loop removing them from the list (also no worse than O(#S) time),
+but it's easier to leave that until the next phase - there we will
+iterate through the candidates anyway.
+
+ The caller has already removed all elements of U from their parents'
+lists of children, which means that checking if child belongs to S is
+equivalent to checking if it's marked as a candidate; we'll never see
+the elements of U in the loop over children in Trim_one().
+
+ What's more, if we see that children(m) is empty and m is not
+locked, we can immediately move m into the committed subset (remove
+from the parent's list of children, etc.). That's one fewer mount we'll
+have to look into when we check the list of children of its parent *and*
+when we get to building the non-revealing subset.
+
+ Maximal non-revealing subsets
+
+If S is not a non-revealing subset, there is a locked element x in S
+such that parent of x is not in S.
+
+Obviously, no non-revealing subset of S may contain x. Removing such
+elements one by one will obviously end with the maximal non-revealing
+subset (possibly empty one). Note that removal of an element will
+require removal of all its locked children, etc.
+
+If the set had been non-shifting, it will remain non-shifting after
+such removals.
+Proof: suppose S was non-shifting, x is a locked element of S, parent of x
+is not in S and S - {x} is not non-shifting. Then there is an element m
+in S - {x} and a subtree mounted strictly inside m, such that m contains
+an element not in S - {x}. Since S is non-shifting, everything in
+that subtree must belong to S. But that means that this subtree must
+contain x somewhere *and* that parent of x either belongs that subtree
+or is equal to m. Either way it must belong to S. Contradiction.
+
+// same representation as for finding maximal non-shifting subsets:
+// S is a disjoint union of a non-revealing set U (the ones we are committed
+// to unmount) and a set of candidates, represented as a subset of list
+// elements that have "is a candidate" mark on them.
+// Elements of U are removed from their parents' lists of children.
+// In the end candidates becomes empty and maximal non-revealing non-shifting
+// subset of S is now in U
+ while (Candidates list is non-empty)
+ handle_locked(first(Candidates))
+
+handle_locked(m)
+ if m is not marked as a candidate
+ strip the "seen by Trim_ancestors" mark from m
+ remove m from the list
+ return
+ cutoff = m
+ for (p = m; p in candidates; p = parent(p)) {
+ strip the "seen by Trim_ancestors" mark from p
+ strip the "candidate" mark from p
+ remove p from the Candidates list
+ if (!locked(p))
+ cutoff = parent(p)
+ }
+ if p in U
+ cutoff = p
+ while m != cutoff
+ remove m from children(parent(m))
+ add m to U
+ m = parent(m)
+
+Let (x_0, ..., x_n = m) be the maximal chain of descent of m within S.
+* If it contains some elements of U, let x_k be the last one of those.
+Then union of U with {x_{k+1}, ..., x_n} is obviously non-revealing.
+* otherwise if all its elements are locked, then none of {x_0, ..., x_n}
+may be elements of a non-revealing subset of S.
+* otherwise let x_k be the first unlocked element of the chain. Then none
+of {x_0, ..., x_{k-1}} may be an element of a non-revealing subset of
+S and union of U and {x_k, ..., x_n} is non-revealing.
+
+handle_locked(m) finds which of these cases applies and adjusts Candidates
+and U accordingly. U remains non-revealing, union of Candidates and
+U still contains any non-revealing subset of S and after the call of
+handle_locked(m) m is guaranteed to be not in Candidates list. So having
+it called for each element of S would suffice to empty Candidates,
+leaving U the maximal non-revealing subset of S.
+
+However, handle_locked(m) is a no-op when m belongs to U, so it's enough
+to have it called for elements of Candidates list until none remain.
+
+Time complexity: number of calls of handle_locked() is limited by
+#Candidates, each iteration of the first loop in handle_locked() removes
+an element from the list, so their total number of executions is also
+limited by #Candidates; number of iterations in the second loop is no
+greater than the number of iterations of the first loop.
+
+
+ Reparenting
+
+After we'd calculated the final set, we still need to deal with
+reparenting - if an element of the final set has a child not in it,
+we need to reparent such child.
+
+Such children can only be root-overmounting (otherwise the set wouldn't
+be non-shifting) and their parents can not belong to the original set,
+since the original is guaranteed to be closed.
+
+
+ Putting all of that together
+
+The plan is to
+ * find all candidates
+ * trim down to maximal non-shifting subset
+ * trim down to maximal non-revealing subset
+ * reparent anything that needs to be reparented
+ * return the resulting set to the caller
+
+For the 2nd and 3rd steps we want to separate the set into growing
+non-revealing subset, initially containing the original set ("U" in
+terms of the pseudocode above) and everything we are still not sure about
+("candidates"). It means that for the output of the 1st step we'd like
+the extra candidates separated from the stuff already in the original set.
+For the 4th step we would like the additions to U separate from the
+original set.
+
+So let's go for
+ * original set ("set"). Linkage via mnt_list
+ * undecided candidates ("candidates"). Subset of a list,
+consisting of all its elements marked with a new flag (T_UMOUNT_CANDIDATE).
+Initially all elements of the list will be marked that way; in the
+end the list will become empty and no mounts will remain marked with
+that flag.
+ * Reuse T_MARKED for "has been already seen by trim_ancestors()".
+ * anything in U that hadn't been in the original set - elements of
+candidates will gradually be either discarded or moved there. In other
+words, it's the candidates we have already decided to unmount. Its role
+is reasonably close to the old "to_umount", so let's use that name.
+Linkage via mnt_list.
+
+For gather_candidates() we'll need to maintain both candidates (S -
+set) and intersection of S with set. Use T_UMOUNT_CANDIDATE for
+all elements we encounter, putting the ones not already in the original
+set into the list of candidates. When we are done, strip that flag from
+all elements of the original set. That gives a cheap way to check
+if element belongs to S (in gather_candidates) and to candidates
+itself (at later stages). Call that predicate is_candidate(); it would
+be m->mnt_t_flags & T_UMOUNT_CANDIDATE.
+
+All elements of the original set are marked with MNT_UMOUNT and we'll
+need the same for elements added when joining the contents of to_umount
+to set in the end. Let's set MNT_UMOUNT at the time we add an element
+to to_umount; that's close to what the old 'umount_one' is doing, so
+let's keep that name. It also gives us another predicate we need -
+"belongs to union of set and to_umount"; will_be_unmounted() for now.
+
+Removals from the candidates list should strip both T_MARKED and
+T_UMOUNT_CANDIDATE; call it remove_from_candidates_list().
diff --git a/Documentation/filesystems/qnx6.rst b/Documentation/filesystems/qnx6.rst
index 523b798f04e7..560f3d470422 100644
--- a/Documentation/filesystems/qnx6.rst
+++ b/Documentation/filesystems/qnx6.rst
@@ -135,7 +135,7 @@ inode.
Character and block special devices do not exist in QNX as those files
are handled by the QNX kernel/drivers and created in /dev independent of the
-underlaying filesystem.
+underlying filesystem.
Long filenames
--------------
diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
index 164960631925..a9d271e171c3 100644
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
@@ -6,8 +6,7 @@ Ramfs, rootfs and initramfs
October 17, 2005
-Rob Landley <rob@landley.net>
-=============================
+:Author: Rob Landley <rob@landley.net>
What is ramfs?
--------------
@@ -291,11 +290,11 @@ Why cpio rather than tar?
This decision was made back in December, 2001. The discussion started here:
- http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html
+- https://lore.kernel.org/lkml/a03cke$640$1@cesium.transmeta.com/
And spawned a second thread (specifically on tar vs cpio), starting here:
- http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html
+- https://lore.kernel.org/lkml/3C25A06D.7030408@zytor.com/
The quick and dirty summary version (which is no substitute for reading
the above threads) is:
@@ -311,12 +310,12 @@ the above threads) is:
either way about the archive format, and there are alternative tools,
such as:
- http://freecode.com/projects/afio
+ https://linux.die.net/man/1/afio
2) The cpio archive format chosen by the kernel is simpler and cleaner (and
thus easier to create and parse) than any of the (literally dozens of)
various tar archive formats. The complete initramfs archive format is
- explained in buffer-format.txt, created in usr/gen_init_cpio.c, and
+ explained in buffer-format.rst, created in usr/gen_init_cpio.c, and
extracted in init/initramfs.c. All three together come to less than 26k
total of human-readable text.
@@ -332,12 +331,12 @@ the above threads) is:
5) Al Viro made the decision (quote: "tar is ugly as hell and not going to be
supported on the kernel side"):
- http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
+ - https://lore.kernel.org/lkml/Pine.GSO.4.21.0112222109050.21702-100000@weyl.math.psu.edu/
explained his reasoning:
- - http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
- - http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
+ - https://lore.kernel.org/lkml/Pine.GSO.4.21.0112222240530.21702-100000@weyl.math.psu.edu/
+ - https://lore.kernel.org/lkml/Pine.GSO.4.21.0112230849550.23300-100000@weyl.math.psu.edu/
and, most importantly, designed and implemented the initramfs code.
diff --git a/Documentation/filesystems/relay.rst b/Documentation/filesystems/relay.rst
index 04ad083cfe62..301ff4c6e6c6 100644
--- a/Documentation/filesystems/relay.rst
+++ b/Documentation/filesystems/relay.rst
@@ -32,7 +32,7 @@ functions in the relay interface code - please see that for details.
Semantics
=========
-Each relay channel has one buffer per CPU, each buffer has one or more
+Each relay channel has one buffer per CPU; each buffer has one or more
sub-buffers. Messages are written to the first sub-buffer until it is
too full to contain a new message, in which case it is written to
the next (if available). Messages are never split across sub-buffers.
@@ -40,7 +40,7 @@ At this point, userspace can be notified so it empties the first
sub-buffer, while the kernel continues writing to the next.
When notified that a sub-buffer is full, the kernel knows how many
-bytes of it are padding i.e. unused space occurring because a complete
+bytes of it are padding, i.e., unused space occurring because a complete
message couldn't fit into a sub-buffer. Userspace can use this
knowledge to copy only valid data.
@@ -71,7 +71,7 @@ klog and relay-apps example code
================================
The relay interface itself is ready to use, but to make things easier,
-a couple simple utility functions and a set of examples are provided.
+a couple of simple utility functions and a set of examples are provided.
The relay-apps example tarball, available on the relay sourceforge
site, contains a set of self-contained examples, each consisting of a
@@ -91,7 +91,7 @@ registered will data actually be logged (see the klog and kleak
examples for details).
It is of course possible to use the relay interface from scratch,
-i.e. without using any of the relay-apps example code or klog, but
+i.e., without using any of the relay-apps example code or klog, but
you'll have to implement communication between userspace and kernel,
allowing both to convey the state of buffers (full, empty, amount of
padding). The read() interface both removes padding and internally
@@ -119,7 +119,7 @@ mmap() results in channel buffer being mapped into the caller's
must map the entire file, which is NRBUF * SUBBUFSIZE.
read() read the contents of a channel buffer. The bytes read are
- 'consumed' by the reader, i.e. they won't be available
+ 'consumed' by the reader, i.e., they won't be available
again to subsequent reads. If the channel is being used
in no-overwrite mode (the default), it can be read at any
time even if there's an active kernel writer. If the
@@ -138,7 +138,7 @@ poll() POLLIN/POLLRDNORM/POLLERR supported. User applications are
notified when sub-buffer boundaries are crossed.
close() decrements the channel buffer's refcount. When the refcount
- reaches 0, i.e. when no process or kernel client has the
+ reaches 0, i.e., when no process or kernel client has the
buffer open, the channel buffer is freed.
=========== ============================================================
@@ -149,7 +149,7 @@ host filesystem must be mounted. For example::
.. Note::
- the host filesystem doesn't need to be mounted for kernel
+ The host filesystem doesn't need to be mounted for kernel
clients to create or use channels - it only needs to be
mounted when user space applications need access to the buffer
data.
@@ -301,16 +301,6 @@ user-defined data with a channel, and is immediately available
(including in create_buf_file()) via chan->private_data or
buf->chan->private_data.
-Buffer-only channels
---------------------
-
-These channels have no files associated and can be created with
-relay_open(NULL, NULL, ...). Such channels are useful in scenarios such
-as when doing early tracing in the kernel, before the VFS is up. In these
-cases, one may open a buffer-only channel and then call
-relay_late_setup_files() when the kernel is ready to handle files,
-to expose the buffered data to the userspace.
-
Channel 'modes'
---------------
@@ -325,7 +315,7 @@ section, as it pertains mainly to mmap() implementations.
In 'overwrite' mode, also known as 'flight recorder' mode, writes
continuously cycle around the buffer and will never fail, but will
unconditionally overwrite old data regardless of whether it's actually
-been consumed. In no-overwrite mode, writes will fail, i.e. data will
+been consumed. In no-overwrite mode, writes will fail, i.e., data will
be lost, if the number of unconsumed sub-buffers equals the total
number of sub-buffers in the channel. It should be clear that if
there is no consumer or if the consumer can't consume sub-buffers fast
@@ -344,7 +334,7 @@ initialize the next sub-buffer if appropriate 2) finalize the previous
sub-buffer if appropriate and 3) return a boolean value indicating
whether or not to actually move on to the next sub-buffer.
-To implement 'no-overwrite' mode, the userspace client would provide
+To implement 'no-overwrite' mode, the userspace client provides
an implementation of the subbuf_start() callback something like the
following::
@@ -364,9 +354,9 @@ following::
return 1;
}
-If the current buffer is full, i.e. all sub-buffers remain unconsumed,
+If the current buffer is full, i.e., all sub-buffers remain unconsumed,
the callback returns 0 to indicate that the buffer switch should not
-occur yet, i.e. until the consumer has had a chance to read the
+occur yet, i.e., until the consumer has had a chance to read the
current set of ready sub-buffers. For the relay_buf_full() function
to make sense, the consumer is responsible for notifying the relay
interface when sub-buffers have been consumed via
@@ -400,7 +390,7 @@ consulted.
The default subbuf_start() implementation, used if the client doesn't
define any callbacks, or doesn't define the subbuf_start() callback,
-implements the simplest possible 'no-overwrite' mode, i.e. it does
+implements the simplest possible 'no-overwrite' mode, i.e., it does
nothing but return 0.
Header information can be reserved at the beginning of each sub-buffer
@@ -467,7 +457,7 @@ rather than open and close a new channel for each use. relay_reset()
can be used for this purpose - it resets a channel to its initial
state without reallocating channel buffer memory or destroying
existing mappings. It should however only be called when it's safe to
-do so, i.e. when the channel isn't currently being written to.
+do so, i.e., when the channel isn't currently being written to.
Finally, there are a couple of utility callbacks that can be used for
different purposes. buf_mapped() is called whenever a channel buffer
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
new file mode 100644
index 000000000000..8c8ce678148a
--- /dev/null
+++ b/Documentation/filesystems/resctrl.rst
@@ -0,0 +1,1932 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+=====================================================
+User Interface for Resource Control feature (resctrl)
+=====================================================
+
+:Copyright: |copy| 2016 Intel Corporation
+:Authors: - Fenghua Yu <fenghua.yu@intel.com>
+ - Tony Luck <tony.luck@intel.com>
+ - Vikas Shivappa <vikas.shivappa@intel.com>
+
+
+Intel refers to this feature as Intel Resource Director Technology(Intel(R) RDT).
+AMD refers to this feature as AMD Platform Quality of Service(AMD QoS).
+
+This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo
+flag bits:
+
+=============================================================== ================================
+RDT (Resource Director Technology) Allocation "rdt_a"
+CAT (Cache Allocation Technology) "cat_l3", "cat_l2"
+CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2"
+CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc"
+MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local"
+MBA (Memory Bandwidth Allocation) "mba"
+SMBA (Slow Memory Bandwidth Allocation) ""
+BMEC (Bandwidth Monitoring Event Configuration) ""
+ABMC (Assignable Bandwidth Monitoring Counters) ""
+SDCIAE (Smart Data Cache Injection Allocation Enforcement) ""
+=============================================================== ================================
+
+Historically, new features were made visible by default in /proc/cpuinfo. This
+resulted in the feature flags becoming hard to parse by humans. Adding a new
+flag to /proc/cpuinfo should be avoided if user space can obtain information
+about the feature from resctrl's info directory.
+
+To use the feature mount the file system::
+
+ # mount -t resctrl resctrl [-o cdp[,cdpl2][,mba_MBps][,debug]] /sys/fs/resctrl
+
+mount options are:
+
+"cdp":
+ Enable code/data prioritization in L3 cache allocations.
+"cdpl2":
+ Enable code/data prioritization in L2 cache allocations.
+"mba_MBps":
+ Enable the MBA Software Controller(mba_sc) to specify MBA
+ bandwidth in MiBps
+"debug":
+ Make debug files accessible. Available debug files are annotated with
+ "Available only with debug option".
+
+L2 and L3 CDP are controlled separately.
+
+RDT features are orthogonal. A particular system may support only
+monitoring, only control, or both monitoring and control. Cache
+pseudo-locking is a unique way of using cache control to "pin" or
+"lock" data in the cache. Details can be found in
+"Cache Pseudo-Locking".
+
+
+The mount succeeds if either of allocation or monitoring is present, but
+only those files and directories supported by the system will be created.
+For more details on the behavior of the interface during monitoring
+and allocation, see the "Resource alloc and monitor groups" section.
+
+Info directory
+==============
+
+The 'info' directory contains information about the enabled
+resources. Each resource has its own subdirectory. The subdirectory
+names reflect the resource names.
+
+Most of the files in the resource's subdirectory are read-only, and
+describe properties of the resource. Resources that support global
+configuration options also include writable files that can be used
+to modify those settings.
+
+Each subdirectory contains the following files with respect to
+allocation:
+
+Cache resource(L3/L2) subdirectory contains the following files
+related to allocation:
+
+"num_closids":
+ The number of CLOSIDs which are valid for this
+ resource. The kernel uses the smallest number of
+ CLOSIDs of all enabled resources as limit.
+"cbm_mask":
+ The bitmask which is valid for this resource.
+ This mask is equivalent to 100%.
+"min_cbm_bits":
+ The minimum number of consecutive bits which
+ must be set when writing a mask.
+
+"shareable_bits":
+ Bitmask of shareable resource with other executing entities
+ (e.g. I/O). Applies to all instances of this resource. User
+ can use this when setting up exclusive cache partitions.
+ Note that some platforms support devices that have their
+ own settings for cache use which can over-ride these bits.
+
+ When "io_alloc" is enabled, a portion of each cache instance can
+ be configured for shared use between hardware and software.
+ "bit_usage" should be used to see which portions of each cache
+ instance is configured for hardware use via "io_alloc" feature
+ because every cache instance can have its "io_alloc" bitmask
+ configured independently via "io_alloc_cbm".
+
+"bit_usage":
+ Annotated capacity bitmasks showing how all
+ instances of the resource are used. The legend is:
+
+ "0":
+ Corresponding region is unused. When the system's
+ resources have been allocated and a "0" is found
+ in "bit_usage" it is a sign that resources are
+ wasted.
+
+ "H":
+ Corresponding region is used by hardware only
+ but available for software use. If a resource
+ has bits set in "shareable_bits" or "io_alloc_cbm"
+ but not all of these bits appear in the resource
+ groups' schemata then the bits appearing in
+ "shareable_bits" or "io_alloc_cbm" but no
+ resource group will be marked as "H".
+ "X":
+ Corresponding region is available for sharing and
+ used by hardware and software. These are the bits
+ that appear in "shareable_bits" or "io_alloc_cbm"
+ as well as a resource group's allocation.
+ "S":
+ Corresponding region is used by software
+ and available for sharing.
+ "E":
+ Corresponding region is used exclusively by
+ one resource group. No sharing allowed.
+ "P":
+ Corresponding region is pseudo-locked. No
+ sharing allowed.
+"sparse_masks":
+ Indicates if non-contiguous 1s value in CBM is supported.
+
+ "0":
+ Only contiguous 1s value in CBM is supported.
+ "1":
+ Non-contiguous 1s value in CBM is supported.
+
+"io_alloc":
+ "io_alloc" enables system software to configure the portion of
+ the cache allocated for I/O traffic. File may only exist if the
+ system supports this feature on some of its cache resources.
+
+ "disabled":
+ Resource supports "io_alloc" but the feature is disabled.
+ Portions of cache used for allocation of I/O traffic cannot
+ be configured.
+ "enabled":
+ Portions of cache used for allocation of I/O traffic
+ can be configured using "io_alloc_cbm".
+ "not supported":
+ Support not available for this resource.
+
+ The feature can be modified by writing to the interface, for example:
+
+ To enable::
+
+ # echo 1 > /sys/fs/resctrl/info/L3/io_alloc
+
+ To disable::
+
+ # echo 0 > /sys/fs/resctrl/info/L3/io_alloc
+
+ The underlying implementation may reduce resources available to
+ general (CPU) cache allocation. See architecture specific notes
+ below. Depending on usage requirements the feature can be enabled
+ or disabled.
+
+ On AMD systems, io_alloc feature is supported by the L3 Smart
+ Data Cache Injection Allocation Enforcement (SDCIAE). The CLOSID for
+ io_alloc is the highest CLOSID supported by the resource. When
+ io_alloc is enabled, the highest CLOSID is dedicated to io_alloc and
+ no longer available for general (CPU) cache allocation. When CDP is
+ enabled, io_alloc routes I/O traffic using the highest CLOSID allocated
+ for the instruction cache (CDP_CODE), making this CLOSID no longer
+ available for general (CPU) cache allocation for both the CDP_CODE
+ and CDP_DATA resources.
+
+"io_alloc_cbm":
+ Capacity bitmasks that describe the portions of cache instances to
+ which I/O traffic from supported I/O devices are routed when "io_alloc"
+ is enabled.
+
+ CBMs are displayed in the following format:
+
+ <cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+ Example::
+
+ # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+ 0=ffff;1=ffff
+
+ CBMs can be configured by writing to the interface.
+
+ Example::
+
+ # echo 1=ff > /sys/fs/resctrl/info/L3/io_alloc_cbm
+ # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+ 0=ffff;1=00ff
+
+ # echo "0=ff;1=f" > /sys/fs/resctrl/info/L3/io_alloc_cbm
+ # cat /sys/fs/resctrl/info/L3/io_alloc_cbm
+ 0=00ff;1=000f
+
+ When CDP is enabled "io_alloc_cbm" associated with the CDP_DATA and CDP_CODE
+ resources may reflect the same values. For example, values read from and
+ written to /sys/fs/resctrl/info/L3DATA/io_alloc_cbm may be reflected by
+ /sys/fs/resctrl/info/L3CODE/io_alloc_cbm and vice versa.
+
+Memory bandwidth(MB) subdirectory contains the following files
+with respect to allocation:
+
+"min_bandwidth":
+ The minimum memory bandwidth percentage which
+ user can request.
+
+"bandwidth_gran":
+ The granularity in which the memory bandwidth
+ percentage is allocated. The allocated
+ b/w percentage is rounded off to the next
+ control step available on the hardware. The
+ available bandwidth control steps are:
+ min_bandwidth + N * bandwidth_gran.
+
+"delay_linear":
+ Indicates if the delay scale is linear or
+ non-linear. This field is purely informational
+ only.
+
+"thread_throttle_mode":
+ Indicator on Intel systems of how tasks running on threads
+ of a physical core are throttled in cases where they
+ request different memory bandwidth percentages:
+
+ "max":
+ the smallest percentage is applied
+ to all threads
+ "per-thread":
+ bandwidth percentages are directly applied to
+ the threads running on the core
+
+If RDT monitoring is available there will be an "L3_MON" directory
+with the following files:
+
+"num_rmids":
+ The number of RMIDs available. This is the
+ upper bound for how many "CTRL_MON" + "MON"
+ groups can be created.
+
+"mon_features":
+ Lists the monitoring events if
+ monitoring is enabled for the resource.
+ Example::
+
+ # cat /sys/fs/resctrl/info/L3_MON/mon_features
+ llc_occupancy
+ mbm_total_bytes
+ mbm_local_bytes
+
+ If the system supports Bandwidth Monitoring Event
+ Configuration (BMEC), then the bandwidth events will
+ be configurable. The output will be::
+
+ # cat /sys/fs/resctrl/info/L3_MON/mon_features
+ llc_occupancy
+ mbm_total_bytes
+ mbm_total_bytes_config
+ mbm_local_bytes
+ mbm_local_bytes_config
+
+"mbm_total_bytes_config", "mbm_local_bytes_config":
+ Read/write files containing the configuration for the mbm_total_bytes
+ and mbm_local_bytes events, respectively, when the Bandwidth
+ Monitoring Event Configuration (BMEC) feature is supported.
+ The event configuration settings are domain specific and affect
+ all the CPUs in the domain. When either event configuration is
+ changed, the bandwidth counters for all RMIDs of both events
+ (mbm_total_bytes as well as mbm_local_bytes) are cleared for that
+ domain. The next read for every RMID will report "Unavailable"
+ and subsequent reads will report the valid value.
+
+ Following are the types of events supported:
+
+ ==== ========================================================
+ Bits Description
+ ==== ========================================================
+ 6 Dirty Victims from the QOS domain to all types of memory
+ 5 Reads to slow memory in the non-local NUMA domain
+ 4 Reads to slow memory in the local NUMA domain
+ 3 Non-temporal writes to non-local NUMA domain
+ 2 Non-temporal writes to local NUMA domain
+ 1 Reads to memory in the non-local NUMA domain
+ 0 Reads to memory in the local NUMA domain
+ ==== ========================================================
+
+ By default, the mbm_total_bytes configuration is set to 0x7f to count
+ all the event types and the mbm_local_bytes configuration is set to
+ 0x15 to count all the local memory events.
+
+ Examples:
+
+ * To view the current configuration::
+ ::
+
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
+ 0=0x7f;1=0x7f;2=0x7f;3=0x7f
+
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config
+ 0=0x15;1=0x15;3=0x15;4=0x15
+
+ * To change the mbm_total_bytes to count only reads on domain 0,
+ the bits 0, 1, 4 and 5 needs to be set, which is 110011b in binary
+ (in hexadecimal 0x33):
+ ::
+
+ # echo "0=0x33" > /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
+
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
+ 0=0x33;1=0x7f;2=0x7f;3=0x7f
+
+ * To change the mbm_local_bytes to count all the slow memory reads on
+ domain 0 and 1, the bits 4 and 5 needs to be set, which is 110000b
+ in binary (in hexadecimal 0x30):
+ ::
+
+ # echo "0=0x30;1=0x30" > /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config
+
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config
+ 0=0x30;1=0x30;3=0x15;4=0x15
+
+"mbm_assign_mode":
+ The supported counter assignment modes. The enclosed brackets indicate which mode
+ is enabled. The MBM events associated with counters may reset when "mbm_assign_mode"
+ is changed.
+ ::
+
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+ [mbm_event]
+ default
+
+ "mbm_event":
+
+ mbm_event mode allows users to assign a hardware counter to an RMID, event
+ pair and monitor the bandwidth usage as long as it is assigned. The hardware
+ continues to track the assigned counter until it is explicitly unassigned by
+ the user. Each event within a resctrl group can be assigned independently.
+
+ In this mode, a monitoring event can only accumulate data while it is backed
+ by a hardware counter. Use "mbm_L3_assignments" found in each CTRL_MON and MON
+ group to specify which of the events should have a counter assigned. The number
+ of counters available is described in the "num_mbm_cntrs" file. Changing the
+ mode may cause all counters on the resource to reset.
+
+ Moving to mbm_event counter assignment mode requires users to assign the counters
+ to the events. Otherwise, the MBM event counters will return 'Unassigned' when read.
+
+ The mode is beneficial for AMD platforms that support more CTRL_MON
+ and MON groups than available hardware counters. By default, this
+ feature is enabled on AMD platforms with the ABMC (Assignable Bandwidth
+ Monitoring Counters) capability, ensuring counters remain assigned even
+ when the corresponding RMID is not actively used by any processor.
+
+ "default":
+
+ In default mode, resctrl assumes there is a hardware counter for each
+ event within every CTRL_MON and MON group. On AMD platforms, it is
+ recommended to use the mbm_event mode, if supported, to prevent reset of MBM
+ events between reads resulting from hardware re-allocating counters. This can
+ result in misleading values or display "Unavailable" if no counter is assigned
+ to the event.
+
+ * To enable "mbm_event" counter assignment mode:
+ ::
+
+ # echo "mbm_event" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+
+ * To enable "default" monitoring mode:
+ ::
+
+ # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+
+"num_mbm_cntrs":
+ The maximum number of counters (total of available and assigned counters) in
+ each domain when the system supports mbm_event mode.
+
+ For example, on a system with maximum of 32 memory bandwidth monitoring
+ counters in each of its L3 domains:
+ ::
+
+ # cat /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs
+ 0=32;1=32
+
+"available_mbm_cntrs":
+ The number of counters available for assignment in each domain when mbm_event
+ mode is enabled on the system.
+
+ For example, on a system with 30 available [hardware] assignable counters
+ in each of its L3 domains:
+ ::
+
+ # cat /sys/fs/resctrl/info/L3_MON/available_mbm_cntrs
+ 0=30;1=30
+
+"event_configs":
+ Directory that exists when "mbm_event" counter assignment mode is supported.
+ Contains a sub-directory for each MBM event that can be assigned to a counter.
+
+ Two MBM events are supported by default: mbm_local_bytes and mbm_total_bytes.
+ Each MBM event's sub-directory contains a file named "event_filter" that is
+ used to view and modify which memory transactions the MBM event is configured
+ with. The file is accessible only when "mbm_event" counter assignment mode is
+ enabled.
+
+ List of memory transaction types supported:
+
+ ========================== ========================================================
+ Name Description
+ ========================== ========================================================
+ dirty_victim_writes_all Dirty Victims from the QOS domain to all types of memory
+ remote_reads_slow_memory Reads to slow memory in the non-local NUMA domain
+ local_reads_slow_memory Reads to slow memory in the local NUMA domain
+ remote_non_temporal_writes Non-temporal writes to non-local NUMA domain
+ local_non_temporal_writes Non-temporal writes to local NUMA domain
+ remote_reads Reads to memory in the non-local NUMA domain
+ local_reads Reads to memory in the local NUMA domain
+ ========================== ========================================================
+
+ For example::
+
+ # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter
+ local_reads,remote_reads,local_non_temporal_writes,remote_non_temporal_writes,
+ local_reads_slow_memory,remote_reads_slow_memory,dirty_victim_writes_all
+
+ # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_local_bytes/event_filter
+ local_reads,local_non_temporal_writes,local_reads_slow_memory
+
+ Modify the event configuration by writing to the "event_filter" file within
+ the "event_configs" directory. The read/write "event_filter" file contains the
+ configuration of the event that reflects which memory transactions are counted by it.
+
+ For example::
+
+ # echo "local_reads, local_non_temporal_writes" >
+ /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter
+
+ # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter
+ local_reads,local_non_temporal_writes
+
+"mbm_assign_on_mkdir":
+ Exists when "mbm_event" counter assignment mode is supported. Accessible
+ only when "mbm_event" counter assignment mode is enabled.
+
+ Determines if a counter will automatically be assigned to an RMID, MBM event
+ pair when its associated monitor group is created via mkdir. Enabled by default
+ on boot, also when switched from "default" mode to "mbm_event" counter assignment
+ mode. Users can disable this capability by writing to the interface.
+
+ "0":
+ Auto assignment is disabled.
+ "1":
+ Auto assignment is enabled.
+
+ Example::
+
+ # echo 0 > /sys/fs/resctrl/info/L3_MON/mbm_assign_on_mkdir
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_on_mkdir
+ 0
+
+"max_threshold_occupancy":
+ Read/write file provides the largest value (in
+ bytes) at which a previously used LLC_occupancy
+ counter can be considered for re-use.
+
+Finally, in the top level of the "info" directory there is a file
+named "last_cmd_status". This is reset with every "command" issued
+via the file system (making new directories or writing to any of the
+control files). If the command was successful, it will read as "ok".
+If the command failed, it will provide more information that can be
+conveyed in the error returns from file operations. E.g.
+::
+
+ # echo L3:0=f7 > schemata
+ bash: echo: write error: Invalid argument
+ # cat info/last_cmd_status
+ mask f7 has non-consecutive 1-bits
+
+Resource alloc and monitor groups
+=================================
+
+Resource groups are represented as directories in the resctrl file
+system. The default group is the root directory which, immediately
+after mounting, owns all the tasks and cpus in the system and can make
+full use of all resources.
+
+On a system with RDT control features additional directories can be
+created in the root directory that specify different amounts of each
+resource (see "schemata" below). The root and these additional top level
+directories are referred to as "CTRL_MON" groups below.
+
+On a system with RDT monitoring the root directory and other top level
+directories contain a directory named "mon_groups" in which additional
+directories can be created to monitor subsets of tasks in the CTRL_MON
+group that is their ancestor. These are called "MON" groups in the rest
+of this document.
+
+Removing a directory will move all tasks and cpus owned by the group it
+represents to the parent. Removing one of the created CTRL_MON groups
+will automatically remove all MON groups below it.
+
+Moving MON group directories to a new parent CTRL_MON group is supported
+for the purpose of changing the resource allocations of a MON group
+without impacting its monitoring data or assigned tasks. This operation
+is not allowed for MON groups which monitor CPUs. No other move
+operation is currently allowed other than simply renaming a CTRL_MON or
+MON group.
+
+All groups contain the following files:
+
+"tasks":
+ Reading this file shows the list of all tasks that belong to
+ this group. Writing a task id to the file will add a task to the
+ group. Multiple tasks can be added by separating the task ids
+ with commas. Tasks will be assigned sequentially. Multiple
+ failures are not supported. A single failure encountered while
+ attempting to assign a task will cause the operation to abort and
+ already added tasks before the failure will remain in the group.
+ Failures will be logged to /sys/fs/resctrl/info/last_cmd_status.
+
+ If the group is a CTRL_MON group the task is removed from
+ whichever previous CTRL_MON group owned the task and also from
+ any MON group that owned the task. If the group is a MON group,
+ then the task must already belong to the CTRL_MON parent of this
+ group. The task is removed from any previous MON group.
+
+
+"cpus":
+ Reading this file shows a bitmask of the logical CPUs owned by
+ this group. Writing a mask to this file will add and remove
+ CPUs to/from this group. As with the tasks file a hierarchy is
+ maintained where MON groups may only include CPUs owned by the
+ parent CTRL_MON group.
+ When the resource group is in pseudo-locked mode this file will
+ only be readable, reflecting the CPUs associated with the
+ pseudo-locked region.
+
+
+"cpus_list":
+ Just like "cpus", only using ranges of CPUs instead of bitmasks.
+
+
+When control is enabled all CTRL_MON groups will also contain:
+
+"schemata":
+ A list of all the resources available to this group.
+ Each resource has its own line and format - see below for details.
+
+"size":
+ Mirrors the display of the "schemata" file to display the size in
+ bytes of each allocation instead of the bits representing the
+ allocation.
+
+"mode":
+ The "mode" of the resource group dictates the sharing of its
+ allocations. A "shareable" resource group allows sharing of its
+ allocations while an "exclusive" resource group does not. A
+ cache pseudo-locked region is created by first writing
+ "pseudo-locksetup" to the "mode" file before writing the cache
+ pseudo-locked region's schemata to the resource group's "schemata"
+ file. On successful pseudo-locked region creation the mode will
+ automatically change to "pseudo-locked".
+
+"ctrl_hw_id":
+ Available only with debug option. The identifier used by hardware
+ for the control group. On x86 this is the CLOSID.
+
+When monitoring is enabled all MON groups will also contain:
+
+"mon_data":
+ This contains a set of files organized by L3 domain and by
+ RDT event. E.g. on a system with two L3 domains there will
+ be subdirectories "mon_L3_00" and "mon_L3_01". Each of these
+ directories have one file per event (e.g. "llc_occupancy",
+ "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these
+ files provide a read out of the current value of the event for
+ all tasks in the group. In CTRL_MON groups these files provide
+ the sum for all tasks in the CTRL_MON group and all tasks in
+ MON groups. Please see example section for more details on usage.
+ On systems with Sub-NUMA Cluster (SNC) enabled there are extra
+ directories for each node (located within the "mon_L3_XX" directory
+ for the L3 cache they occupy). These are named "mon_sub_L3_YY"
+ where "YY" is the node number.
+
+ When the 'mbm_event' counter assignment mode is enabled, reading
+ an MBM event of a MON group returns 'Unassigned' if no hardware
+ counter is assigned to it. For CTRL_MON groups, 'Unassigned' is
+ returned if the MBM event does not have an assigned counter in the
+ CTRL_MON group nor in any of its associated MON groups.
+
+"mon_hw_id":
+ Available only with debug option. The identifier used by hardware
+ for the monitor group. On x86 this is the RMID.
+
+When monitoring is enabled all MON groups may also contain:
+
+"mbm_L3_assignments":
+ Exists when "mbm_event" counter assignment mode is supported and lists the
+ counter assignment states of the group.
+
+ The assignment list is displayed in the following format:
+
+ <Event>:<Domain ID>=<Assignment state>;<Domain ID>=<Assignment state>
+
+ Event: A valid MBM event in the
+ /sys/fs/resctrl/info/L3_MON/event_configs directory.
+
+ Domain ID: A valid domain ID. When writing, '*' applies the changes
+ to all the domains.
+
+ Assignment states:
+
+ _ : No counter assigned.
+
+ e : Counter assigned exclusively.
+
+ Example:
+
+ To display the counter assignment states for the default group.
+ ::
+
+ # cd /sys/fs/resctrl
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=e;1=e
+ mbm_local_bytes:0=e;1=e
+
+ Assignments can be modified by writing to the interface.
+
+ Examples:
+
+ To unassign the counter associated with the mbm_total_bytes event on domain 0:
+ ::
+
+ # echo "mbm_total_bytes:0=_" > /sys/fs/resctrl/mbm_L3_assignments
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=_;1=e
+ mbm_local_bytes:0=e;1=e
+
+ To unassign the counter associated with the mbm_total_bytes event on all the domains:
+ ::
+
+ # echo "mbm_total_bytes:*=_" > /sys/fs/resctrl/mbm_L3_assignments
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=_;1=_
+ mbm_local_bytes:0=e;1=e
+
+ To assign a counter associated with the mbm_total_bytes event on all domains in
+ exclusive mode:
+ ::
+
+ # echo "mbm_total_bytes:*=e" > /sys/fs/resctrl/mbm_L3_assignments
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=e;1=e
+ mbm_local_bytes:0=e;1=e
+
+When the "mba_MBps" mount option is used all CTRL_MON groups will also contain:
+
+"mba_MBps_event":
+ Reading this file shows which memory bandwidth event is used
+ as input to the software feedback loop that keeps memory bandwidth
+ below the value specified in the schemata file. Writing the
+ name of one of the supported memory bandwidth events found in
+ /sys/fs/resctrl/info/L3_MON/mon_features changes the input
+ event.
+
+Resource allocation rules
+-------------------------
+
+When a task is running the following rules define which resources are
+available to it:
+
+1) If the task is a member of a non-default group, then the schemata
+ for that group is used.
+
+2) Else if the task belongs to the default group, but is running on a
+ CPU that is assigned to some specific group, then the schemata for the
+ CPU's group is used.
+
+3) Otherwise the schemata for the default group is used.
+
+Resource monitoring rules
+-------------------------
+1) If a task is a member of a MON group, or non-default CTRL_MON group
+ then RDT events for the task will be reported in that group.
+
+2) If a task is a member of the default CTRL_MON group, but is running
+ on a CPU that is assigned to some specific group, then the RDT events
+ for the task will be reported in that group.
+
+3) Otherwise RDT events for the task will be reported in the root level
+ "mon_data" group.
+
+
+Notes on cache occupancy monitoring and control
+===============================================
+When moving a task from one group to another you should remember that
+this only affects *new* cache allocations by the task. E.g. you may have
+a task in a monitor group showing 3 MB of cache occupancy. If you move
+to a new group and immediately check the occupancy of the old and new
+groups you will likely see that the old group is still showing 3 MB and
+the new group zero. When the task accesses locations still in cache from
+before the move, the h/w does not update any counters. On a busy system
+you will likely see the occupancy in the old group go down as cache lines
+are evicted and re-used while the occupancy in the new group rises as
+the task accesses memory and loads into the cache are counted based on
+membership in the new group.
+
+The same applies to cache allocation control. Moving a task to a group
+with a smaller cache partition will not evict any cache lines. The
+process may continue to use them from the old partition.
+
+Hardware uses CLOSid(Class of service ID) and an RMID(Resource monitoring ID)
+to identify a control group and a monitoring group respectively. Each of
+the resource groups are mapped to these IDs based on the kind of group. The
+number of CLOSid and RMID are limited by the hardware and hence the creation of
+a "CTRL_MON" directory may fail if we run out of either CLOSID or RMID
+and creation of "MON" group may fail if we run out of RMIDs.
+
+max_threshold_occupancy - generic concepts
+------------------------------------------
+
+Note that an RMID once freed may not be immediately available for use as
+the RMID is still tagged the cache lines of the previous user of RMID.
+Hence such RMIDs are placed on limbo list and checked back if the cache
+occupancy has gone down. If there is a time when system has a lot of
+limbo RMIDs but which are not ready to be used, user may see an -EBUSY
+during mkdir.
+
+max_threshold_occupancy is a user configurable value to determine the
+occupancy at which an RMID can be freed.
+
+The mon_llc_occupancy_limbo tracepoint gives the precise occupancy in bytes
+for a subset of RMID that are not immediately available for allocation.
+This can't be relied on to produce output every second, it may be necessary
+to attempt to create an empty monitor group to force an update. Output may
+only be produced if creation of a control or monitor group fails.
+
+Schemata files - general concepts
+---------------------------------
+Each line in the file describes one resource. The line starts with
+the name of the resource, followed by specific values to be applied
+in each of the instances of that resource on the system.
+
+Cache IDs
+---------
+On current generation systems there is one L3 cache per socket and L2
+caches are generally just shared by the hyperthreads on a core, but this
+isn't an architectural requirement. We could have multiple separate L3
+caches on a socket, multiple cores could share an L2 cache. So instead
+of using "socket" or "core" to define the set of logical cpus sharing
+a resource we use a "Cache ID". At a given cache level this will be a
+unique number across the whole system (but it isn't guaranteed to be a
+contiguous sequence, there may be gaps). To find the ID for each logical
+CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id
+
+Cache Bit Masks (CBM)
+---------------------
+For cache resources we describe the portion of the cache that is available
+for allocation using a bitmask. The maximum value of the mask is defined
+by each cpu model (and may be different for different cache levels). It
+is found using CPUID, but is also provided in the "info" directory of
+the resctrl file system in "info/{resource}/cbm_mask". Some Intel hardware
+requires that these masks have all the '1' bits in a contiguous block. So
+0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9
+and 0xA are not. Check /sys/fs/resctrl/info/{resource}/sparse_masks
+if non-contiguous 1s value is supported. On a system with a 20-bit mask
+each bit represents 5% of the capacity of the cache. You could partition
+the cache into four equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000.
+
+Notes on Sub-NUMA Cluster mode
+==============================
+When SNC mode is enabled, Linux may load balance tasks between Sub-NUMA
+nodes much more readily than between regular NUMA nodes since the CPUs
+on Sub-NUMA nodes share the same L3 cache and the system may report
+the NUMA distance between Sub-NUMA nodes with a lower value than used
+for regular NUMA nodes.
+
+The top-level monitoring files in each "mon_L3_XX" directory provide
+the sum of data across all SNC nodes sharing an L3 cache instance.
+Users who bind tasks to the CPUs of a specific Sub-NUMA node can read
+the "llc_occupancy", "mbm_total_bytes", and "mbm_local_bytes" in the
+"mon_sub_L3_YY" directories to get node local data.
+
+Memory bandwidth allocation is still performed at the L3 cache
+level. I.e. throttling controls are applied to all SNC nodes.
+
+L3 cache allocation bitmaps also apply to all SNC nodes. But note that
+the amount of L3 cache represented by each bit is divided by the number
+of SNC nodes per L3 cache. E.g. with a 100MB cache on a system with 10-bit
+allocation masks each bit normally represents 10MB. With SNC mode enabled
+with two SNC nodes per L3 cache, each bit only represents 5MB.
+
+Memory bandwidth Allocation and monitoring
+==========================================
+
+For Memory bandwidth resource, by default the user controls the resource
+by indicating the percentage of total memory bandwidth.
+
+The minimum bandwidth percentage value for each cpu model is predefined
+and can be looked up through "info/MB/min_bandwidth". The bandwidth
+granularity that is allocated is also dependent on the cpu model and can
+be looked up at "info/MB/bandwidth_gran". The available bandwidth
+control steps are: min_bw + N * bw_gran. Intermediate values are rounded
+to the next control step available on the hardware.
+
+The bandwidth throttling is a core specific mechanism on some of Intel
+SKUs. Using a high bandwidth and a low bandwidth setting on two threads
+sharing a core may result in both threads being throttled to use the
+low bandwidth (see "thread_throttle_mode").
+
+The fact that Memory bandwidth allocation(MBA) may be a core
+specific mechanism where as memory bandwidth monitoring(MBM) is done at
+the package level may lead to confusion when users try to apply control
+via the MBA and then monitor the bandwidth to see if the controls are
+effective. Below are such scenarios:
+
+1. User may *not* see increase in actual bandwidth when percentage
+ values are increased:
+
+This can occur when aggregate L2 external bandwidth is more than L3
+external bandwidth. Consider an SKL SKU with 24 cores on a package and
+where L2 external is 10GBps (hence aggregate L2 external bandwidth is
+240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20
+threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3
+bandwidth of 100GBps although the percentage value specified is only 50%
+<< 100%. Hence increasing the bandwidth percentage will not yield any
+more bandwidth. This is because although the L2 external bandwidth still
+has capacity, the L3 external bandwidth is fully used. Also note that
+this would be dependent on number of cores the benchmark is run on.
+
+2. Same bandwidth percentage may mean different actual bandwidth
+ depending on # of threads:
+
+For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4
+thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although
+they have same percentage bandwidth of 10%. This is simply because as
+threads start using more cores in an rdtgroup, the actual bandwidth may
+increase or vary although user specified bandwidth percentage is same.
+
+In order to mitigate this and make the interface more user friendly,
+resctrl added support for specifying the bandwidth in MiBps as well. The
+kernel underneath would use a software feedback mechanism or a "Software
+Controller(mba_sc)" which reads the actual bandwidth using MBM counters
+and adjust the memory bandwidth percentages to ensure::
+
+ "actual bandwidth < user specified bandwidth".
+
+By default, the schemata would take the bandwidth percentage values
+where as user can switch to the "MBA software controller" mode using
+a mount option 'mba_MBps'. The schemata format is specified in the below
+sections.
+
+L3 schemata file details (code and data prioritization disabled)
+----------------------------------------------------------------
+With CDP disabled the L3 schemata format is::
+
+ L3:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+L3 schemata file details (CDP enabled via mount option to resctrl)
+------------------------------------------------------------------
+When CDP is enabled L3 control is split into two separate resources
+so you can specify independent masks for code and data like this::
+
+ L3DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L3CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+L2 schemata file details
+------------------------
+CDP is supported at L2 using the 'cdpl2' mount option. The schemata
+format is either::
+
+ L2:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+or
+
+ L2DATA:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+ L2CODE:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
+
+
+Memory bandwidth Allocation (default mode)
+------------------------------------------
+
+Memory b/w domain is L3 cache.
+::
+
+ MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
+
+Memory bandwidth Allocation specified in MiBps
+----------------------------------------------
+
+Memory bandwidth domain is L3 cache.
+::
+
+ MB:<cache_id0>=bw_MiBps0;<cache_id1>=bw_MiBps1;...
+
+Slow Memory Bandwidth Allocation (SMBA)
+---------------------------------------
+AMD hardware supports Slow Memory Bandwidth Allocation (SMBA).
+CXL.memory is the only supported "slow" memory device. With the
+support of SMBA, the hardware enables bandwidth allocation on
+the slow memory devices. If there are multiple such devices in
+the system, the throttling logic groups all the slow sources
+together and applies the limit on them as a whole.
+
+The presence of SMBA (with CXL.memory) is independent of slow memory
+devices presence. If there are no such devices on the system, then
+configuring SMBA will have no impact on the performance of the system.
+
+The bandwidth domain for slow memory is L3 cache. Its schemata file
+is formatted as:
+::
+
+ SMBA:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
+
+Reading/writing the schemata file
+---------------------------------
+Reading the schemata file will show the state of all resources
+on all domains. When writing you only need to specify those values
+which you wish to change. E.g.
+::
+
+ # cat schemata
+ L3DATA:0=fffff;1=fffff;2=fffff;3=fffff
+ L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
+ # echo "L3DATA:2=3c0;" > schemata
+ # cat schemata
+ L3DATA:0=fffff;1=fffff;2=3c0;3=fffff
+ L3CODE:0=fffff;1=fffff;2=fffff;3=fffff
+
+Reading/writing the schemata file (on AMD systems)
+--------------------------------------------------
+Reading the schemata file will show the current bandwidth limit on all
+domains. The allocated resources are in multiples of one eighth GB/s.
+When writing to the file, you need to specify what cache id you wish to
+configure the bandwidth limit.
+
+For example, to allocate 2GB/s limit on the first cache id:
+
+::
+
+ # cat schemata
+ MB:0=2048;1=2048;2=2048;3=2048
+ L3:0=ffff;1=ffff;2=ffff;3=ffff
+
+ # echo "MB:1=16" > schemata
+ # cat schemata
+ MB:0=2048;1= 16;2=2048;3=2048
+ L3:0=ffff;1=ffff;2=ffff;3=ffff
+
+Reading/writing the schemata file (on AMD systems) with SMBA feature
+--------------------------------------------------------------------
+Reading and writing the schemata file is the same as without SMBA in
+above section.
+
+For example, to allocate 8GB/s limit on the first cache id:
+
+::
+
+ # cat schemata
+ SMBA:0=2048;1=2048;2=2048;3=2048
+ MB:0=2048;1=2048;2=2048;3=2048
+ L3:0=ffff;1=ffff;2=ffff;3=ffff
+
+ # echo "SMBA:1=64" > schemata
+ # cat schemata
+ SMBA:0=2048;1= 64;2=2048;3=2048
+ MB:0=2048;1=2048;2=2048;3=2048
+ L3:0=ffff;1=ffff;2=ffff;3=ffff
+
+Cache Pseudo-Locking
+====================
+CAT enables a user to specify the amount of cache space that an
+application can fill. Cache pseudo-locking builds on the fact that a
+CPU can still read and write data pre-allocated outside its current
+allocated area on a cache hit. With cache pseudo-locking, data can be
+preloaded into a reserved portion of cache that no application can
+fill, and from that point on will only serve cache hits. The cache
+pseudo-locked memory is made accessible to user space where an
+application can map it into its virtual address space and thus have
+a region of memory with reduced average read latency.
+
+The creation of a cache pseudo-locked region is triggered by a request
+from the user to do so that is accompanied by a schemata of the region
+to be pseudo-locked. The cache pseudo-locked region is created as follows:
+
+- Create a CAT allocation CLOSNEW with a CBM matching the schemata
+ from the user of the cache region that will contain the pseudo-locked
+ memory. This region must not overlap with any current CAT allocation/CLOS
+ on the system and no future overlap with this cache region is allowed
+ while the pseudo-locked region exists.
+- Create a contiguous region of memory of the same size as the cache
+ region.
+- Flush the cache, disable hardware prefetchers, disable preemption.
+- Make CLOSNEW the active CLOS and touch the allocated memory to load
+ it into the cache.
+- Set the previous CLOS as active.
+- At this point the closid CLOSNEW can be released - the cache
+ pseudo-locked region is protected as long as its CBM does not appear in
+ any CAT allocation. Even though the cache pseudo-locked region will from
+ this point on not appear in any CBM of any CLOS an application running with
+ any CLOS will be able to access the memory in the pseudo-locked region since
+ the region continues to serve cache hits.
+- The contiguous region of memory loaded into the cache is exposed to
+ user-space as a character device.
+
+Cache pseudo-locking increases the probability that data will remain
+in the cache via carefully configuring the CAT feature and controlling
+application behavior. There is no guarantee that data is placed in
+cache. Instructions like INVD, WBINVD, CLFLUSH, etc. can still evict
+“locked” data from cache. Power management C-states may shrink or
+power off cache. Deeper C-states will automatically be restricted on
+pseudo-locked region creation.
+
+It is required that an application using a pseudo-locked region runs
+with affinity to the cores (or a subset of the cores) associated
+with the cache on which the pseudo-locked region resides. A sanity check
+within the code will not allow an application to map pseudo-locked memory
+unless it runs with affinity to cores associated with the cache on which the
+pseudo-locked region resides. The sanity check is only done during the
+initial mmap() handling, there is no enforcement afterwards and the
+application self needs to ensure it remains affine to the correct cores.
+
+Pseudo-locking is accomplished in two stages:
+
+1) During the first stage the system administrator allocates a portion
+ of cache that should be dedicated to pseudo-locking. At this time an
+ equivalent portion of memory is allocated, loaded into allocated
+ cache portion, and exposed as a character device.
+2) During the second stage a user-space application maps (mmap()) the
+ pseudo-locked memory into its address space.
+
+Cache Pseudo-Locking Interface
+------------------------------
+A pseudo-locked region is created using the resctrl interface as follows:
+
+1) Create a new resource group by creating a new directory in /sys/fs/resctrl.
+2) Change the new resource group's mode to "pseudo-locksetup" by writing
+ "pseudo-locksetup" to the "mode" file.
+3) Write the schemata of the pseudo-locked region to the "schemata" file. All
+ bits within the schemata should be "unused" according to the "bit_usage"
+ file.
+
+On successful pseudo-locked region creation the "mode" file will contain
+"pseudo-locked" and a new character device with the same name as the resource
+group will exist in /dev/pseudo_lock. This character device can be mmap()'ed
+by user space in order to obtain access to the pseudo-locked memory region.
+
+An example of cache pseudo-locked region creation and usage can be found below.
+
+Cache Pseudo-Locking Debugging Interface
+----------------------------------------
+The pseudo-locking debugging interface is enabled by default (if
+CONFIG_DEBUG_FS is enabled) and can be found in /sys/kernel/debug/resctrl.
+
+There is no explicit way for the kernel to test if a provided memory
+location is present in the cache. The pseudo-locking debugging interface uses
+the tracing infrastructure to provide two ways to measure cache residency of
+the pseudo-locked region:
+
+1) Memory access latency using the pseudo_lock_mem_latency tracepoint. Data
+ from these measurements are best visualized using a hist trigger (see
+ example below). In this test the pseudo-locked region is traversed at
+ a stride of 32 bytes while hardware prefetchers and preemption
+ are disabled. This also provides a substitute visualization of cache
+ hits and misses.
+2) Cache hit and miss measurements using model specific precision counters if
+ available. Depending on the levels of cache on the system the pseudo_lock_l2
+ and pseudo_lock_l3 tracepoints are available.
+
+When a pseudo-locked region is created a new debugfs directory is created for
+it in debugfs as /sys/kernel/debug/resctrl/<newdir>. A single
+write-only file, pseudo_lock_measure, is present in this directory. The
+measurement of the pseudo-locked region depends on the number written to this
+debugfs file:
+
+1:
+ writing "1" to the pseudo_lock_measure file will trigger the latency
+ measurement captured in the pseudo_lock_mem_latency tracepoint. See
+ example below.
+2:
+ writing "2" to the pseudo_lock_measure file will trigger the L2 cache
+ residency (cache hits and misses) measurement captured in the
+ pseudo_lock_l2 tracepoint. See example below.
+3:
+ writing "3" to the pseudo_lock_measure file will trigger the L3 cache
+ residency (cache hits and misses) measurement captured in the
+ pseudo_lock_l3 tracepoint.
+
+All measurements are recorded with the tracing infrastructure. This requires
+the relevant tracepoints to be enabled before the measurement is triggered.
+
+Example of latency debugging interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In this example a pseudo-locked region named "newlock" was created. Here is
+how we can measure the latency in cycles of reading from this region and
+visualize this data with a histogram that is available if CONFIG_HIST_TRIGGERS
+is set::
+
+ # :> /sys/kernel/tracing/trace
+ # echo 'hist:keys=latency' > /sys/kernel/tracing/events/resctrl/pseudo_lock_mem_latency/trigger
+ # echo 1 > /sys/kernel/tracing/events/resctrl/pseudo_lock_mem_latency/enable
+ # echo 1 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure
+ # echo 0 > /sys/kernel/tracing/events/resctrl/pseudo_lock_mem_latency/enable
+ # cat /sys/kernel/tracing/events/resctrl/pseudo_lock_mem_latency/hist
+
+ # event histogram
+ #
+ # trigger info: hist:keys=latency:vals=hitcount:sort=hitcount:size=2048 [active]
+ #
+
+ { latency: 456 } hitcount: 1
+ { latency: 50 } hitcount: 83
+ { latency: 36 } hitcount: 96
+ { latency: 44 } hitcount: 174
+ { latency: 48 } hitcount: 195
+ { latency: 46 } hitcount: 262
+ { latency: 42 } hitcount: 693
+ { latency: 40 } hitcount: 3204
+ { latency: 38 } hitcount: 3484
+
+ Totals:
+ Hits: 8192
+ Entries: 9
+ Dropped: 0
+
+Example of cache hits/misses debugging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In this example a pseudo-locked region named "newlock" was created on the L2
+cache of a platform. Here is how we can obtain details of the cache hits
+and misses using the platform's precision counters.
+::
+
+ # :> /sys/kernel/tracing/trace
+ # echo 1 > /sys/kernel/tracing/events/resctrl/pseudo_lock_l2/enable
+ # echo 2 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure
+ # echo 0 > /sys/kernel/tracing/events/resctrl/pseudo_lock_l2/enable
+ # cat /sys/kernel/tracing/trace
+
+ # tracer: nop
+ #
+ # _-----=> irqs-off
+ # / _----=> need-resched
+ # | / _---=> hardirq/softirq
+ # || / _--=> preempt-depth
+ # ||| / delay
+ # TASK-PID CPU# |||| TIMESTAMP FUNCTION
+ # | | | |||| | |
+ pseudo_lock_mea-1672 [002] .... 3132.860500: pseudo_lock_l2: hits=4097 miss=0
+
+
+Examples for RDT allocation usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1) Example 1
+
+On a two socket machine (one L3 cache per socket) with just four bits
+for cache bit masks, minimum b/w of 10% with a memory bandwidth
+granularity of 10%.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p0 p1
+ # echo "L3:0=3;1=c\nMB:0=50;1=50" > /sys/fs/resctrl/p0/schemata
+ # echo "L3:0=3;1=3\nMB:0=50;1=50" > /sys/fs/resctrl/p1/schemata
+
+The default resource group is unmodified, so we have access to all parts
+of all caches (its schemata file reads "L3:0=f;1=f").
+
+Tasks that are under the control of group "p0" may only allocate from the
+"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
+Tasks in group "p1" use the "lower" 50% of cache on both sockets.
+
+Similarly, tasks that are under the control of group "p0" may use a
+maximum memory b/w of 50% on socket0 and 50% on socket 1.
+Tasks in group "p1" may also use 50% memory b/w on both sockets.
+Note that unlike cache masks, memory b/w cannot specify whether these
+allocations can overlap or not. The allocations specifies the maximum
+b/w that the group may be able to use and the system admin can configure
+the b/w accordingly.
+
+If resctrl is using the software controller (mba_sc) then user can enter the
+max b/w in MB rather than the percentage values.
+::
+
+ # echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata
+ # echo "L3:0=3;1=3\nMB:0=1024;1=500" > /sys/fs/resctrl/p1/schemata
+
+In the above example the tasks in "p1" and "p0" on socket 0 would use a max b/w
+of 1024MB where as on socket 1 they would use 500MB.
+
+2) Example 2
+
+Again two sockets, but this time with a more realistic 20-bit mask.
+
+Two real time tasks pid=1234 running on processor 0 and pid=5678 running on
+processor 1 on socket 0 on a 2-socket and dual core machine. To avoid noisy
+neighbors, each of the two real-time tasks exclusively occupies one quarter
+of L3 cache on socket 0.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+
+First we reset the schemata for the default group so that the "upper"
+50% of the L3 cache on socket 0 and 50% of memory b/w cannot be used by
+ordinary tasks::
+
+ # echo "L3:0=3ff;1=fffff\nMB:0=50;1=100" > schemata
+
+Next we make a resource group for our first real time task and give
+it access to the "top" 25% of the cache on socket 0.
+::
+
+ # mkdir p0
+ # echo "L3:0=f8000;1=fffff" > p0/schemata
+
+Finally we move our first real time task into this resource group. We
+also use taskset(1) to ensure the task always runs on a dedicated CPU
+on socket 0. Most uses of resource groups will also constrain which
+processors tasks run on.
+::
+
+ # echo 1234 > p0/tasks
+ # taskset -cp 1 1234
+
+Ditto for the second real time task (with the remaining 25% of cache)::
+
+ # mkdir p1
+ # echo "L3:0=7c00;1=fffff" > p1/schemata
+ # echo 5678 > p1/tasks
+ # taskset -cp 2 5678
+
+For the same 2 socket system with memory b/w resource and CAT L3 the
+schemata would look like(Assume min_bandwidth 10 and bandwidth_gran is
+10):
+
+For our first real time task this would request 20% memory b/w on socket 0.
+::
+
+ # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
+
+For our second real time task this would request an other 20% memory b/w
+on socket 0.
+::
+
+ # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata
+
+3) Example 3
+
+A single socket system which has real-time tasks running on core 4-7 and
+non real-time workload assigned to core 0-3. The real-time tasks share text
+and data, so a per task association is not required and due to interaction
+with the kernel it's desired that the kernel on these cores shares L3 with
+the tasks.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+
+First we reset the schemata for the default group so that the "upper"
+50% of the L3 cache on socket 0, and 50% of memory bandwidth on socket 0
+cannot be used by ordinary tasks::
+
+ # echo "L3:0=3ff\nMB:0=50" > schemata
+
+Next we make a resource group for our real time cores and give it access
+to the "top" 50% of the cache on socket 0 and 50% of memory bandwidth on
+socket 0.
+::
+
+ # mkdir p0
+ # echo "L3:0=ffc00\nMB:0=50" > p0/schemata
+
+Finally we move core 4-7 over to the new group and make sure that the
+kernel and the tasks running there get 50% of the cache. They should
+also get 50% of memory bandwidth assuming that the cores 4-7 are SMT
+siblings and only the real time threads are scheduled on the cores 4-7.
+::
+
+ # echo F0 > p0/cpus
+
+4) Example 4
+
+The resource groups in previous examples were all in the default "shareable"
+mode allowing sharing of their cache allocations. If one resource group
+configures a cache allocation then nothing prevents another resource group
+to overlap with that allocation.
+
+In this example a new exclusive resource group will be created on a L2 CAT
+system with two L2 cache instances that can be configured with an 8-bit
+capacity bitmask. The new exclusive resource group will be configured to use
+25% of each cache instance.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl/
+ # cd /sys/fs/resctrl
+
+First, we observe that the default group is configured to allocate to all L2
+cache::
+
+ # cat schemata
+ L2:0=ff;1=ff
+
+We could attempt to create the new resource group at this point, but it will
+fail because of the overlap with the schemata of the default group::
+
+ # mkdir p0
+ # echo 'L2:0=0x3;1=0x3' > p0/schemata
+ # cat p0/mode
+ shareable
+ # echo exclusive > p0/mode
+ -sh: echo: write error: Invalid argument
+ # cat info/last_cmd_status
+ schemata overlaps
+
+To ensure that there is no overlap with another resource group the default
+resource group's schemata has to change, making it possible for the new
+resource group to become exclusive.
+::
+
+ # echo 'L2:0=0xfc;1=0xfc' > schemata
+ # echo exclusive > p0/mode
+ # grep . p0/*
+ p0/cpus:0
+ p0/mode:exclusive
+ p0/schemata:L2:0=03;1=03
+ p0/size:L2:0=262144;1=262144
+
+A new resource group will on creation not overlap with an exclusive resource
+group::
+
+ # mkdir p1
+ # grep . p1/*
+ p1/cpus:0
+ p1/mode:shareable
+ p1/schemata:L2:0=fc;1=fc
+ p1/size:L2:0=786432;1=786432
+
+The bit_usage will reflect how the cache is used::
+
+ # cat info/L2/bit_usage
+ 0=SSSSSSEE;1=SSSSSSEE
+
+A resource group cannot be forced to overlap with an exclusive resource group::
+
+ # echo 'L2:0=0x1;1=0x1' > p1/schemata
+ -sh: echo: write error: Invalid argument
+ # cat info/last_cmd_status
+ overlaps with exclusive group
+
+Example of Cache Pseudo-Locking
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Lock portion of L2 cache from cache id 1 using CBM 0x3. Pseudo-locked
+region is exposed at /dev/pseudo_lock/newlock that can be provided to
+application for argument to mmap().
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl/
+ # cd /sys/fs/resctrl
+
+Ensure that there are bits available that can be pseudo-locked, since only
+unused bits can be pseudo-locked the bits to be pseudo-locked needs to be
+removed from the default resource group's schemata::
+
+ # cat info/L2/bit_usage
+ 0=SSSSSSSS;1=SSSSSSSS
+ # echo 'L2:1=0xfc' > schemata
+ # cat info/L2/bit_usage
+ 0=SSSSSSSS;1=SSSSSS00
+
+Create a new resource group that will be associated with the pseudo-locked
+region, indicate that it will be used for a pseudo-locked region, and
+configure the requested pseudo-locked region capacity bitmask::
+
+ # mkdir newlock
+ # echo pseudo-locksetup > newlock/mode
+ # echo 'L2:1=0x3' > newlock/schemata
+
+On success the resource group's mode will change to pseudo-locked, the
+bit_usage will reflect the pseudo-locked region, and the character device
+exposing the pseudo-locked region will exist::
+
+ # cat newlock/mode
+ pseudo-locked
+ # cat info/L2/bit_usage
+ 0=SSSSSSSS;1=SSSSSSPP
+ # ls -l /dev/pseudo_lock/newlock
+ crw------- 1 root root 243, 0 Apr 3 05:01 /dev/pseudo_lock/newlock
+
+::
+
+ /*
+ * Example code to access one page of pseudo-locked cache region
+ * from user space.
+ */
+ #define _GNU_SOURCE
+ #include <fcntl.h>
+ #include <sched.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <unistd.h>
+ #include <sys/mman.h>
+
+ /*
+ * It is required that the application runs with affinity to only
+ * cores associated with the pseudo-locked region. Here the cpu
+ * is hardcoded for convenience of example.
+ */
+ static int cpuid = 2;
+
+ int main(int argc, char *argv[])
+ {
+ cpu_set_t cpuset;
+ long page_size;
+ void *mapping;
+ int dev_fd;
+ int ret;
+
+ page_size = sysconf(_SC_PAGESIZE);
+
+ CPU_ZERO(&cpuset);
+ CPU_SET(cpuid, &cpuset);
+ ret = sched_setaffinity(0, sizeof(cpuset), &cpuset);
+ if (ret < 0) {
+ perror("sched_setaffinity");
+ exit(EXIT_FAILURE);
+ }
+
+ dev_fd = open("/dev/pseudo_lock/newlock", O_RDWR);
+ if (dev_fd < 0) {
+ perror("open");
+ exit(EXIT_FAILURE);
+ }
+
+ mapping = mmap(0, page_size, PROT_READ | PROT_WRITE, MAP_SHARED,
+ dev_fd, 0);
+ if (mapping == MAP_FAILED) {
+ perror("mmap");
+ close(dev_fd);
+ exit(EXIT_FAILURE);
+ }
+
+ /* Application interacts with pseudo-locked memory @mapping */
+
+ ret = munmap(mapping, page_size);
+ if (ret < 0) {
+ perror("munmap");
+ close(dev_fd);
+ exit(EXIT_FAILURE);
+ }
+
+ close(dev_fd);
+ exit(EXIT_SUCCESS);
+ }
+
+Locking between applications
+----------------------------
+
+Certain operations on the resctrl filesystem, composed of read/writes
+to/from multiple files, must be atomic.
+
+As an example, the allocation of an exclusive reservation of L3 cache
+involves:
+
+ 1. Read the cbmmasks from each directory or the per-resource "bit_usage"
+ 2. Find a contiguous set of bits in the global CBM bitmask that is clear
+ in any of the directory cbmmasks
+ 3. Create a new directory
+ 4. Set the bits found in step 2 to the new directory "schemata" file
+
+If two applications attempt to allocate space concurrently then they can
+end up allocating the same bits so the reservations are shared instead of
+exclusive.
+
+To coordinate atomic operations on the resctrlfs and to avoid the problem
+above, the following locking procedure is recommended:
+
+Locking is based on flock, which is available in libc and also as a shell
+script command
+
+Write lock:
+
+ A) Take flock(LOCK_EX) on /sys/fs/resctrl
+ B) Read/write the directory structure.
+ C) funlock
+
+Read lock:
+
+ A) Take flock(LOCK_SH) on /sys/fs/resctrl
+ B) If success read the directory structure.
+ C) funlock
+
+Example with bash::
+
+ # Atomically read directory structure
+ $ flock -s /sys/fs/resctrl/ find /sys/fs/resctrl
+
+ # Read directory contents and create new subdirectory
+
+ $ cat create-dir.sh
+ find /sys/fs/resctrl/ > output.txt
+ mask = function-of(output.txt)
+ mkdir /sys/fs/resctrl/newres/
+ echo mask > /sys/fs/resctrl/newres/schemata
+
+ $ flock /sys/fs/resctrl/ ./create-dir.sh
+
+Example with C::
+
+ /*
+ * Example code do take advisory locks
+ * before accessing resctrl filesystem
+ */
+ #include <sys/file.h>
+ #include <stdlib.h>
+
+ void resctrl_take_shared_lock(int fd)
+ {
+ int ret;
+
+ /* take shared lock on resctrl filesystem */
+ ret = flock(fd, LOCK_SH);
+ if (ret) {
+ perror("flock");
+ exit(-1);
+ }
+ }
+
+ void resctrl_take_exclusive_lock(int fd)
+ {
+ int ret;
+
+ /* release lock on resctrl filesystem */
+ ret = flock(fd, LOCK_EX);
+ if (ret) {
+ perror("flock");
+ exit(-1);
+ }
+ }
+
+ void resctrl_release_lock(int fd)
+ {
+ int ret;
+
+ /* take shared lock on resctrl filesystem */
+ ret = flock(fd, LOCK_UN);
+ if (ret) {
+ perror("flock");
+ exit(-1);
+ }
+ }
+
+ void main(void)
+ {
+ int fd, ret;
+
+ fd = open("/sys/fs/resctrl", O_DIRECTORY);
+ if (fd == -1) {
+ perror("open");
+ exit(-1);
+ }
+ resctrl_take_shared_lock(fd);
+ /* code to read directory contents */
+ resctrl_release_lock(fd);
+
+ resctrl_take_exclusive_lock(fd);
+ /* code to read and write directory contents */
+ resctrl_release_lock(fd);
+ }
+
+Examples for RDT Monitoring along with allocation usage
+=======================================================
+Reading monitored data
+----------------------
+Reading an event file (for ex: mon_data/mon_L3_00/llc_occupancy) would
+show the current snapshot of LLC occupancy of the corresponding MON
+group or CTRL_MON group.
+
+
+Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group)
+------------------------------------------------------------------------
+On a two socket machine (one L3 cache per socket) with just four bits
+for cache bit masks::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p0 p1
+ # echo "L3:0=3;1=c" > /sys/fs/resctrl/p0/schemata
+ # echo "L3:0=3;1=3" > /sys/fs/resctrl/p1/schemata
+ # echo 5678 > p1/tasks
+ # echo 5679 > p1/tasks
+
+The default resource group is unmodified, so we have access to all parts
+of all caches (its schemata file reads "L3:0=f;1=f").
+
+Tasks that are under the control of group "p0" may only allocate from the
+"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1.
+Tasks in group "p1" use the "lower" 50% of cache on both sockets.
+
+Create monitor groups and assign a subset of tasks to each monitor group.
+::
+
+ # cd /sys/fs/resctrl/p1/mon_groups
+ # mkdir m11 m12
+ # echo 5678 > m11/tasks
+ # echo 5679 > m12/tasks
+
+fetch data (data shown in bytes)
+::
+
+ # cat m11/mon_data/mon_L3_00/llc_occupancy
+ 16234000
+ # cat m11/mon_data/mon_L3_01/llc_occupancy
+ 14789000
+ # cat m12/mon_data/mon_L3_00/llc_occupancy
+ 16789000
+
+The parent ctrl_mon group shows the aggregated data.
+::
+
+ # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy
+ 31234000
+
+Example 2 (Monitor a task from its creation)
+--------------------------------------------
+On a two socket machine (one L3 cache per socket)::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p0 p1
+
+An RMID is allocated to the group once its created and hence the <cmd>
+below is monitored from its creation.
+::
+
+ # echo $$ > /sys/fs/resctrl/p1/tasks
+ # <cmd>
+
+Fetch the data::
+
+ # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy
+ 31789000
+
+Example 3 (Monitor without CAT support or before creating CAT groups)
+---------------------------------------------------------------------
+
+Assume a system like HSW has only CQM and no CAT support. In this case
+the resctrl will still mount but cannot create CTRL_MON directories.
+But user can create different MON groups within the root group thereby
+able to monitor all tasks including kernel threads.
+
+This can also be used to profile jobs cache size footprint before being
+able to allocate them to different allocation groups.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir mon_groups/m01
+ # mkdir mon_groups/m02
+
+ # echo 3478 > /sys/fs/resctrl/mon_groups/m01/tasks
+ # echo 2467 > /sys/fs/resctrl/mon_groups/m02/tasks
+
+Monitor the groups separately and also get per domain data. From the
+below its apparent that the tasks are mostly doing work on
+domain(socket) 0.
+::
+
+ # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_00/llc_occupancy
+ 31234000
+ # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_01/llc_occupancy
+ 34555
+ # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_00/llc_occupancy
+ 31234000
+ # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_01/llc_occupancy
+ 32789
+
+
+Example 4 (Monitor real time tasks)
+-----------------------------------
+
+A single socket system which has real time tasks running on cores 4-7
+and non real time tasks on other cpus. We want to monitor the cache
+occupancy of the real time threads on these cores.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl
+ # cd /sys/fs/resctrl
+ # mkdir p1
+
+Move the cpus 4-7 over to p1::
+
+ # echo f0 > p1/cpus
+
+View the llc occupancy snapshot::
+
+ # cat /sys/fs/resctrl/p1/mon_data/mon_L3_00/llc_occupancy
+ 11234000
+
+
+Examples on working with mbm_assign_mode
+========================================
+
+a. Check if MBM counter assignment mode is supported.
+::
+
+ # mount -t resctrl resctrl /sys/fs/resctrl/
+
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+ [mbm_event]
+ default
+
+The "mbm_event" mode is detected and enabled.
+
+b. Check how many assignable counters are supported.
+::
+
+ # cat /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs
+ 0=32;1=32
+
+c. Check how many assignable counters are available for assignment in each domain.
+::
+
+ # cat /sys/fs/resctrl/info/L3_MON/available_mbm_cntrs
+ 0=30;1=30
+
+d. To list the default group's assign states.
+::
+
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=e;1=e
+ mbm_local_bytes:0=e;1=e
+
+e. To unassign the counter associated with the mbm_total_bytes event on domain 0.
+::
+
+ # echo "mbm_total_bytes:0=_" > /sys/fs/resctrl/mbm_L3_assignments
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=_;1=e
+ mbm_local_bytes:0=e;1=e
+
+f. To unassign the counter associated with the mbm_total_bytes event on all domains.
+::
+
+ # echo "mbm_total_bytes:*=_" > /sys/fs/resctrl/mbm_L3_assignments
+ # cat /sys/fs/resctrl/mbm_L3_assignment
+ mbm_total_bytes:0=_;1=_
+ mbm_local_bytes:0=e;1=e
+
+g. To assign a counter associated with the mbm_total_bytes event on all domains in
+exclusive mode.
+::
+
+ # echo "mbm_total_bytes:*=e" > /sys/fs/resctrl/mbm_L3_assignments
+ # cat /sys/fs/resctrl/mbm_L3_assignments
+ mbm_total_bytes:0=e;1=e
+ mbm_local_bytes:0=e;1=e
+
+h. Read the events mbm_total_bytes and mbm_local_bytes of the default group. There is
+no change in reading the events with the assignment.
+::
+
+ # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
+ 779247936
+ # cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_total_bytes
+ 562324232
+ # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_local_bytes
+ 212122123
+ # cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_local_bytes
+ 121212144
+
+i. Check the event configurations.
+::
+
+ # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter
+ local_reads,remote_reads,local_non_temporal_writes,remote_non_temporal_writes,
+ local_reads_slow_memory,remote_reads_slow_memory,dirty_victim_writes_all
+
+ # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_local_bytes/event_filter
+ local_reads,local_non_temporal_writes,local_reads_slow_memory
+
+j. Change the event configuration for mbm_local_bytes.
+::
+
+ # echo "local_reads, local_non_temporal_writes, local_reads_slow_memory, remote_reads" >
+ /sys/fs/resctrl/info/L3_MON/event_configs/mbm_local_bytes/event_filter
+
+ # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_local_bytes/event_filter
+ local_reads,local_non_temporal_writes,local_reads_slow_memory,remote_reads
+
+k. Now read the local events again. The first read may come back with "Unavailable"
+status. The subsequent read of mbm_local_bytes will display the current value.
+::
+
+ # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_local_bytes
+ Unavailable
+ # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_local_bytes
+ 2252323
+ # cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_local_bytes
+ Unavailable
+ # cat /sys/fs/resctrl/mon_data/mon_L3_01/mbm_local_bytes
+ 1566565
+
+l. Users have the option to go back to 'default' mbm_assign_mode if required. This can be
+done using the following command. Note that switching the mbm_assign_mode may reset all
+the MBM counters (and thus all MBM events) of all the resctrl groups.
+::
+
+ # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+ # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
+ mbm_event
+ [default]
+
+m. Unmount the resctrl filesystem.
+::
+
+ # umount /sys/fs/resctrl/
+
+Intel RDT Errata
+================
+
+Intel MBM Counters May Report System Memory Bandwidth Incorrectly
+-----------------------------------------------------------------
+
+Errata SKX99 for Skylake server and BDF102 for Broadwell server.
+
+Problem: Intel Memory Bandwidth Monitoring (MBM) counters track metrics
+according to the assigned Resource Monitor ID (RMID) for that logical
+core. The IA32_QM_CTR register (MSR 0xC8E), used to report these
+metrics, may report incorrect system bandwidth for certain RMID values.
+
+Implication: Due to the errata, system memory bandwidth may not match
+what is reported.
+
+Workaround: MBM total and local readings are corrected according to the
+following correction factor table:
+
++---------------+---------------+---------------+-----------------+
+|core count |rmid count |rmid threshold |correction factor|
++---------------+---------------+---------------+-----------------+
+|1 |8 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|2 |16 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|3 |24 |15 |0.969650 |
++---------------+---------------+---------------+-----------------+
+|4 |32 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|6 |48 |31 |0.969650 |
++---------------+---------------+---------------+-----------------+
+|7 |56 |47 |1.142857 |
++---------------+---------------+---------------+-----------------+
+|8 |64 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|9 |72 |63 |1.185115 |
++---------------+---------------+---------------+-----------------+
+|10 |80 |63 |1.066553 |
++---------------+---------------+---------------+-----------------+
+|11 |88 |79 |1.454545 |
++---------------+---------------+---------------+-----------------+
+|12 |96 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|13 |104 |95 |1.230769 |
++---------------+---------------+---------------+-----------------+
+|14 |112 |95 |1.142857 |
++---------------+---------------+---------------+-----------------+
+|15 |120 |95 |1.066667 |
++---------------+---------------+---------------+-----------------+
+|16 |128 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|17 |136 |127 |1.254863 |
++---------------+---------------+---------------+-----------------+
+|18 |144 |127 |1.185255 |
++---------------+---------------+---------------+-----------------+
+|19 |152 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|20 |160 |127 |1.066667 |
++---------------+---------------+---------------+-----------------+
+|21 |168 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|22 |176 |159 |1.454334 |
++---------------+---------------+---------------+-----------------+
+|23 |184 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|24 |192 |127 |0.969744 |
++---------------+---------------+---------------+-----------------+
+|25 |200 |191 |1.280246 |
++---------------+---------------+---------------+-----------------+
+|26 |208 |191 |1.230921 |
++---------------+---------------+---------------+-----------------+
+|27 |216 |0 |1.000000 |
++---------------+---------------+---------------+-----------------+
+|28 |224 |191 |1.143118 |
++---------------+---------------+---------------+-----------------+
+
+If rmid > rmid threshold, MBM total and local values should be multiplied
+by the correction factor.
+
+See:
+
+1. Erratum SKX99 in Intel Xeon Processor Scalable Family Specification Update:
+http://web.archive.org/web/20200716124958/https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html
+
+2. Erratum BDF102 in Intel Xeon E5-2600 v4 Processor Product Family Specification Update:
+http://web.archive.org/web/20191125200531/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v4-spec-update.pdf
+
+3. The errata in Intel Resource Director Technology (Intel RDT) on 2nd Generation Intel Xeon Scalable Processors Reference Manual:
+https://software.intel.com/content/www/us/en/develop/articles/intel-resource-director-technology-rdt-reference-manual.html
+
+for further information.
diff --git a/Documentation/filesystems/seq_file.rst b/Documentation/filesystems/seq_file.rst
index a6726082a7c2..1e1713d00010 100644
--- a/Documentation/filesystems/seq_file.rst
+++ b/Documentation/filesystems/seq_file.rst
@@ -130,7 +130,7 @@ called SEQ_START_TOKEN; it can be used if you wish to instruct your
show() function (described below) to print a header at the top of the
output. SEQ_START_TOKEN should only be used if the offset is zero,
however. SEQ_START_TOKEN has no special meaning to the core seq_file
-code. It is provided as a convenience for a start() funciton to
+code. It is provided as a convenience for a start() function to
communicate with the next() and show() functions.
The next function to implement is called, amazingly, next(); its job is to
@@ -217,7 +217,7 @@ between the calls to start() and stop(), so holding a lock during that time
is a reasonable thing to do. The seq_file code will also avoid taking any
other locks while the iterator is active.
-The iterater value returned by start() or next() is guaranteed to be
+The iterator value returned by start() or next() is guaranteed to be
passed to a subsequent next() or stop() call. This allows resources
such as locks that were taken to be reliably released. There is *no*
guarantee that the iterator will be passed to show(), though in practice
diff --git a/Documentation/filesystems/sharedsubtree.rst b/Documentation/filesystems/sharedsubtree.rst
index d83395354250..8b7dc9159083 100644
--- a/Documentation/filesystems/sharedsubtree.rst
+++ b/Documentation/filesystems/sharedsubtree.rst
@@ -31,961 +31,960 @@ and versioned filesystem.
-----------
Shared subtree provides four different flavors of mounts; struct vfsmount to be
-precise
+precise:
- a. shared mount
- b. slave mount
- c. private mount
- d. unbindable mount
+a) A **shared mount** can be replicated to as many mountpoints and all the
+ replicas continue to be exactly same.
-2a) A shared mount can be replicated to as many mountpoints and all the
-replicas continue to be exactly same.
+ Here is an example:
- Here is an example:
+ Let's say /mnt has a mount that is shared::
- Let's say /mnt has a mount that is shared::
+ # mount --make-shared /mnt
- mount --make-shared /mnt
+ .. note::
+ mount(8) command now supports the --make-shared flag,
+ so the sample 'smount' program is no longer needed and has been
+ removed.
- Note: mount(8) command now supports the --make-shared flag,
- so the sample 'smount' program is no longer needed and has been
- removed.
+ ::
- ::
+ # mount --bind /mnt /tmp
- # mount --bind /mnt /tmp
+ The above command replicates the mount at /mnt to the mountpoint /tmp
+ and the contents of both the mounts remain identical.
- The above command replicates the mount at /mnt to the mountpoint /tmp
- and the contents of both the mounts remain identical.
+ ::
- ::
+ #ls /mnt
+ a b c
- #ls /mnt
- a b c
+ #ls /tmp
+ a b c
- #ls /tmp
- a b c
+ Now let's say we mount a device at /tmp/a::
- Now let's say we mount a device at /tmp/a::
+ # mount /dev/sd0 /tmp/a
- # mount /dev/sd0 /tmp/a
+ # ls /tmp/a
+ t1 t2 t3
- #ls /tmp/a
- t1 t2 t3
+ # ls /mnt/a
+ t1 t2 t3
- #ls /mnt/a
- t1 t2 t3
+ Note that the mount has propagated to the mount at /mnt as well.
- Note that the mount has propagated to the mount at /mnt as well.
+ And the same is true even when /dev/sd0 is mounted on /mnt/a. The
+ contents will be visible under /tmp/a too.
- And the same is true even when /dev/sd0 is mounted on /mnt/a. The
- contents will be visible under /tmp/a too.
+b) A **slave mount** is like a shared mount except that mount and umount events
+ only propagate towards it.
-2b) A slave mount is like a shared mount except that mount and umount events
- only propagate towards it.
+ All slave mounts have a master mount which is a shared.
- All slave mounts have a master mount which is a shared.
+ Here is an example:
- Here is an example:
+ Let's say /mnt has a mount which is shared::
- Let's say /mnt has a mount which is shared.
- # mount --make-shared /mnt
+ # mount --make-shared /mnt
- Let's bind mount /mnt to /tmp
- # mount --bind /mnt /tmp
+ Let's bind mount /mnt to /tmp::
- the new mount at /tmp becomes a shared mount and it is a replica of
- the mount at /mnt.
+ # mount --bind /mnt /tmp
- Now let's make the mount at /tmp; a slave of /mnt
- # mount --make-slave /tmp
+ the new mount at /tmp becomes a shared mount and it is a replica of
+ the mount at /mnt.
- let's mount /dev/sd0 on /mnt/a
- # mount /dev/sd0 /mnt/a
+ Now let's make the mount at /tmp; a slave of /mnt::
- #ls /mnt/a
- t1 t2 t3
+ # mount --make-slave /tmp
- #ls /tmp/a
- t1 t2 t3
+ let's mount /dev/sd0 on /mnt/a::
- Note the mount event has propagated to the mount at /tmp
+ # mount /dev/sd0 /mnt/a
- However let's see what happens if we mount something on the mount at /tmp
+ # ls /mnt/a
+ t1 t2 t3
- # mount /dev/sd1 /tmp/b
+ # ls /tmp/a
+ t1 t2 t3
- #ls /tmp/b
- s1 s2 s3
+ Note the mount event has propagated to the mount at /tmp
- #ls /mnt/b
+ However let's see what happens if we mount something on the mount at
+ /tmp::
- Note how the mount event has not propagated to the mount at
- /mnt
+ # mount /dev/sd1 /tmp/b
+ # ls /tmp/b
+ s1 s2 s3
-2c) A private mount does not forward or receive propagation.
+ # ls /mnt/b
- This is the mount we are familiar with. Its the default type.
+ Note how the mount event has not propagated to the mount at
+ /mnt
-2d) A unbindable mount is a unbindable private mount
+c) A **private mount** does not forward or receive propagation.
- let's say we have a mount at /mnt and we make it unbindable::
+ This is the mount we are familiar with. Its the default type.
- # mount --make-unbindable /mnt
- Let's try to bind mount this mount somewhere else::
+d) An **unbindable mount** is, as the name suggests, an unbindable private
+ mount.
- # mount --bind /mnt /tmp
- mount: wrong fs type, bad option, bad superblock on /mnt,
- or too many mounted file systems
+ let's say we have a mount at /mnt and we make it unbindable::
- Binding a unbindable mount is a invalid operation.
+ # mount --make-unbindable /mnt
+
+ Let's try to bind mount this mount somewhere else::
+
+ # mount --bind /mnt /tmp mount: wrong fs type, bad option, bad
+ superblock on /mnt, or too many mounted file systems
+
+ Binding a unbindable mount is a invalid operation.
3) Setting mount states
+-----------------------
- The mount command (util-linux package) can be used to set mount
- states::
+The mount command (util-linux package) can be used to set mount
+states::
- mount --make-shared mountpoint
- mount --make-slave mountpoint
- mount --make-private mountpoint
- mount --make-unbindable mountpoint
+ mount --make-shared mountpoint
+ mount --make-slave mountpoint
+ mount --make-private mountpoint
+ mount --make-unbindable mountpoint
4) Use cases
------------
- A) A process wants to clone its own namespace, but still wants to
- access the CD that got mounted recently.
+A) A process wants to clone its own namespace, but still wants to
+ access the CD that got mounted recently.
- Solution:
+ Solution:
- The system administrator can make the mount at /cdrom shared::
+ The system administrator can make the mount at /cdrom shared::
- mount --bind /cdrom /cdrom
- mount --make-shared /cdrom
+ mount --bind /cdrom /cdrom
+ mount --make-shared /cdrom
- Now any process that clones off a new namespace will have a
- mount at /cdrom which is a replica of the same mount in the
- parent namespace.
+ Now any process that clones off a new namespace will have a
+ mount at /cdrom which is a replica of the same mount in the
+ parent namespace.
- So when a CD is inserted and mounted at /cdrom that mount gets
- propagated to the other mount at /cdrom in all the other clone
- namespaces.
+ So when a CD is inserted and mounted at /cdrom that mount gets
+ propagated to the other mount at /cdrom in all the other clone
+ namespaces.
- B) A process wants its mounts invisible to any other process, but
- still be able to see the other system mounts.
+B) A process wants its mounts invisible to any other process, but
+ still be able to see the other system mounts.
- Solution:
+ Solution:
- To begin with, the administrator can mark the entire mount tree
- as shareable::
+ To begin with, the administrator can mark the entire mount tree
+ as shareable::
- mount --make-rshared /
+ mount --make-rshared /
- A new process can clone off a new namespace. And mark some part
- of its namespace as slave::
+ A new process can clone off a new namespace. And mark some part
+ of its namespace as slave::
- mount --make-rslave /myprivatetree
+ mount --make-rslave /myprivatetree
- Hence forth any mounts within the /myprivatetree done by the
- process will not show up in any other namespace. However mounts
- done in the parent namespace under /myprivatetree still shows
- up in the process's namespace.
+ Hence forth any mounts within the /myprivatetree done by the
+ process will not show up in any other namespace. However mounts
+ done in the parent namespace under /myprivatetree still shows
+ up in the process's namespace.
- Apart from the above semantics this feature provides the
- building blocks to solve the following problems:
+Apart from the above semantics this feature provides the
+building blocks to solve the following problems:
- C) Per-user namespace
+C) Per-user namespace
- The above semantics allows a way to share mounts across
- namespaces. But namespaces are associated with processes. If
- namespaces are made first class objects with user API to
- associate/disassociate a namespace with userid, then each user
- could have his/her own namespace and tailor it to his/her
- requirements. This needs to be supported in PAM.
+ The above semantics allows a way to share mounts across
+ namespaces. But namespaces are associated with processes. If
+ namespaces are made first class objects with user API to
+ associate/disassociate a namespace with userid, then each user
+ could have his/her own namespace and tailor it to his/her
+ requirements. This needs to be supported in PAM.
- D) Versioned files
+D) Versioned files
- If the entire mount tree is visible at multiple locations, then
- an underlying versioning file system can return different
- versions of the file depending on the path used to access that
- file.
+ If the entire mount tree is visible at multiple locations, then
+ an underlying versioning file system can return different
+ versions of the file depending on the path used to access that
+ file.
- An example is::
+ An example is::
- mount --make-shared /
- mount --rbind / /view/v1
- mount --rbind / /view/v2
- mount --rbind / /view/v3
- mount --rbind / /view/v4
+ mount --make-shared /
+ mount --rbind / /view/v1
+ mount --rbind / /view/v2
+ mount --rbind / /view/v3
+ mount --rbind / /view/v4
- and if /usr has a versioning filesystem mounted, then that
- mount appears at /view/v1/usr, /view/v2/usr, /view/v3/usr and
- /view/v4/usr too
+ and if /usr has a versioning filesystem mounted, then that
+ mount appears at /view/v1/usr, /view/v2/usr, /view/v3/usr and
+ /view/v4/usr too
- A user can request v3 version of the file /usr/fs/namespace.c
- by accessing /view/v3/usr/fs/namespace.c . The underlying
- versioning filesystem can then decipher that v3 version of the
- filesystem is being requested and return the corresponding
- inode.
+ A user can request v3 version of the file /usr/fs/namespace.c
+ by accessing /view/v3/usr/fs/namespace.c . The underlying
+ versioning filesystem can then decipher that v3 version of the
+ filesystem is being requested and return the corresponding
+ inode.
5) Detailed semantics
---------------------
- The section below explains the detailed semantics of
- bind, rbind, move, mount, umount and clone-namespace operations.
-
- Note: the word 'vfsmount' and the noun 'mount' have been used
- to mean the same thing, throughout this document.
+The section below explains the detailed semantics of
+bind, rbind, move, mount, umount and clone-namespace operations.
-5a) Mount states
+.. Note::
+ the word 'vfsmount' and the noun 'mount' have been used
+ to mean the same thing, throughout this document.
- A given mount can be in one of the following states
+a) Mount states
- 1) shared
- 2) slave
- 3) shared and slave
- 4) private
- 5) unbindable
+ A **propagation event** is defined as event generated on a vfsmount
+ that leads to mount or unmount actions in other vfsmounts.
- A 'propagation event' is defined as event generated on a vfsmount
- that leads to mount or unmount actions in other vfsmounts.
+ A **peer group** is defined as a group of vfsmounts that propagate
+ events to each other.
- A 'peer group' is defined as a group of vfsmounts that propagate
- events to each other.
+ A given mount can be in one of the following states:
- (1) Shared mounts
+ (1) Shared mounts
- A 'shared mount' is defined as a vfsmount that belongs to a
- 'peer group'.
+ A **shared mount** is defined as a vfsmount that belongs to a
+ peer group.
- For example::
+ For example::
- mount --make-shared /mnt
- mount --bind /mnt /tmp
+ mount --make-shared /mnt
+ mount --bind /mnt /tmp
- The mount at /mnt and that at /tmp are both shared and belong
- to the same peer group. Anything mounted or unmounted under
- /mnt or /tmp reflect in all the other mounts of its peer
- group.
+ The mount at /mnt and that at /tmp are both shared and belong
+ to the same peer group. Anything mounted or unmounted under
+ /mnt or /tmp reflect in all the other mounts of its peer
+ group.
- (2) Slave mounts
+ (2) Slave mounts
- A 'slave mount' is defined as a vfsmount that receives
- propagation events and does not forward propagation events.
+ A **slave mount** is defined as a vfsmount that receives
+ propagation events and does not forward propagation events.
- A slave mount as the name implies has a master mount from which
- mount/unmount events are received. Events do not propagate from
- the slave mount to the master. Only a shared mount can be made
- a slave by executing the following command::
+ A slave mount as the name implies has a master mount from which
+ mount/unmount events are received. Events do not propagate from
+ the slave mount to the master. Only a shared mount can be made
+ a slave by executing the following command::
- mount --make-slave mount
+ mount --make-slave mount
- A shared mount that is made as a slave is no more shared unless
- modified to become shared.
+ A shared mount that is made as a slave is no more shared unless
+ modified to become shared.
- (3) Shared and Slave
+ (3) Shared and Slave
- A vfsmount can be both shared as well as slave. This state
- indicates that the mount is a slave of some vfsmount, and
- has its own peer group too. This vfsmount receives propagation
- events from its master vfsmount, and also forwards propagation
- events to its 'peer group' and to its slave vfsmounts.
+ A vfsmount can be both **shared** as well as **slave**. This state
+ indicates that the mount is a slave of some vfsmount, and
+ has its own peer group too. This vfsmount receives propagation
+ events from its master vfsmount, and also forwards propagation
+ events to its 'peer group' and to its slave vfsmounts.
- Strictly speaking, the vfsmount is shared having its own
- peer group, and this peer-group is a slave of some other
- peer group.
+ Strictly speaking, the vfsmount is shared having its own
+ peer group, and this peer-group is a slave of some other
+ peer group.
- Only a slave vfsmount can be made as 'shared and slave' by
- either executing the following command::
+ Only a slave vfsmount can be made as 'shared and slave' by
+ either executing the following command::
- mount --make-shared mount
+ mount --make-shared mount
- or by moving the slave vfsmount under a shared vfsmount.
+ or by moving the slave vfsmount under a shared vfsmount.
- (4) Private mount
+ (4) Private mount
- A 'private mount' is defined as vfsmount that does not
- receive or forward any propagation events.
+ A **private mount** is defined as vfsmount that does not
+ receive or forward any propagation events.
- (5) Unbindable mount
+ (5) Unbindable mount
- A 'unbindable mount' is defined as vfsmount that does not
- receive or forward any propagation events and cannot
- be bind mounted.
+ A **unbindable mount** is defined as vfsmount that does not
+ receive or forward any propagation events and cannot
+ be bind mounted.
- State diagram:
+ State diagram:
- The state diagram below explains the state transition of a mount,
- in response to various commands::
+ The state diagram below explains the state transition of a mount,
+ in response to various commands::
- -----------------------------------------------------------------------
- | |make-shared | make-slave | make-private |make-unbindab|
- --------------|------------|--------------|--------------|-------------|
- |shared |shared |*slave/private| private | unbindable |
- | | | | | |
- |-------------|------------|--------------|--------------|-------------|
- |slave |shared | **slave | private | unbindable |
- | |and slave | | | |
- |-------------|------------|--------------|--------------|-------------|
- |shared |shared | slave | private | unbindable |
- |and slave |and slave | | | |
- |-------------|------------|--------------|--------------|-------------|
- |private |shared | **private | private | unbindable |
- |-------------|------------|--------------|--------------|-------------|
- |unbindable |shared |**unbindable | private | unbindable |
- ------------------------------------------------------------------------
+ -----------------------------------------------------------------------
+ | |make-shared | make-slave | make-private |make-unbindab|
+ --------------|------------|--------------|--------------|-------------|
+ |shared |shared |*slave/private| private | unbindable |
+ | | | | | |
+ |-------------|------------|--------------|--------------|-------------|
+ |slave |shared | **slave | private | unbindable |
+ | |and slave | | | |
+ |-------------|------------|--------------|--------------|-------------|
+ |shared |shared | slave | private | unbindable |
+ |and slave |and slave | | | |
+ |-------------|------------|--------------|--------------|-------------|
+ |private |shared | **private | private | unbindable |
+ |-------------|------------|--------------|--------------|-------------|
+ |unbindable |shared |**unbindable | private | unbindable |
+ ------------------------------------------------------------------------
- * if the shared mount is the only mount in its peer group, making it
- slave, makes it private automatically. Note that there is no master to
- which it can be slaved to.
+ * if the shared mount is the only mount in its peer group, making it
+ slave, makes it private automatically. Note that there is no master to
+ which it can be slaved to.
- ** slaving a non-shared mount has no effect on the mount.
+ ** slaving a non-shared mount has no effect on the mount.
- Apart from the commands listed below, the 'move' operation also changes
- the state of a mount depending on type of the destination mount. Its
- explained in section 5d.
+ Apart from the commands listed below, the 'move' operation also changes
+ the state of a mount depending on type of the destination mount. Its
+ explained in section 5d.
-5b) Bind semantics
+b) Bind semantics
- Consider the following command::
+ Consider the following command::
- mount --bind A/a B/b
+ mount --bind A/a B/b
- where 'A' is the source mount, 'a' is the dentry in the mount 'A', 'B'
- is the destination mount and 'b' is the dentry in the destination mount.
+ where 'A' is the source mount, 'a' is the dentry in the mount 'A', 'B'
+ is the destination mount and 'b' is the dentry in the destination mount.
- The outcome depends on the type of mount of 'A' and 'B'. The table
- below contains quick reference::
+ The outcome depends on the type of mount of 'A' and 'B'. The table
+ below contains quick reference::
- --------------------------------------------------------------------------
- | BIND MOUNT OPERATION |
- |************************************************************************|
- |source(A)->| shared | private | slave | unbindable |
- | dest(B) | | | | |
- | | | | | | |
- | v | | | | |
- |************************************************************************|
- | shared | shared | shared | shared & slave | invalid |
- | | | | | |
- |non-shared| shared | private | slave | invalid |
- **************************************************************************
+ --------------------------------------------------------------------------
+ | BIND MOUNT OPERATION |
+ |************************************************************************|
+ |source(A)->| shared | private | slave | unbindable |
+ | dest(B) | | | | |
+ | | | | | | |
+ | v | | | | |
+ |************************************************************************|
+ | shared | shared | shared | shared & slave | invalid |
+ | | | | | |
+ |non-shared| shared | private | slave | invalid |
+ **************************************************************************
- Details:
+ Details:
- 1. 'A' is a shared mount and 'B' is a shared mount. A new mount 'C'
- which is clone of 'A', is created. Its root dentry is 'a' . 'C' is
- mounted on mount 'B' at dentry 'b'. Also new mount 'C1', 'C2', 'C3' ...
- are created and mounted at the dentry 'b' on all mounts where 'B'
- propagates to. A new propagation tree containing 'C1',..,'Cn' is
- created. This propagation tree is identical to the propagation tree of
- 'B'. And finally the peer-group of 'C' is merged with the peer group
- of 'A'.
+ 1. 'A' is a shared mount and 'B' is a shared mount. A new mount 'C'
+ which is clone of 'A', is created. Its root dentry is 'a' . 'C' is
+ mounted on mount 'B' at dentry 'b'. Also new mount 'C1', 'C2', 'C3' ...
+ are created and mounted at the dentry 'b' on all mounts where 'B'
+ propagates to. A new propagation tree containing 'C1',..,'Cn' is
+ created. This propagation tree is identical to the propagation tree of
+ 'B'. And finally the peer-group of 'C' is merged with the peer group
+ of 'A'.
- 2. 'A' is a private mount and 'B' is a shared mount. A new mount 'C'
- which is clone of 'A', is created. Its root dentry is 'a'. 'C' is
- mounted on mount 'B' at dentry 'b'. Also new mount 'C1', 'C2', 'C3' ...
- are created and mounted at the dentry 'b' on all mounts where 'B'
- propagates to. A new propagation tree is set containing all new mounts
- 'C', 'C1', .., 'Cn' with exactly the same configuration as the
- propagation tree for 'B'.
+ 2. 'A' is a private mount and 'B' is a shared mount. A new mount 'C'
+ which is clone of 'A', is created. Its root dentry is 'a'. 'C' is
+ mounted on mount 'B' at dentry 'b'. Also new mount 'C1', 'C2', 'C3' ...
+ are created and mounted at the dentry 'b' on all mounts where 'B'
+ propagates to. A new propagation tree is set containing all new mounts
+ 'C', 'C1', .., 'Cn' with exactly the same configuration as the
+ propagation tree for 'B'.
- 3. 'A' is a slave mount of mount 'Z' and 'B' is a shared mount. A new
- mount 'C' which is clone of 'A', is created. Its root dentry is 'a' .
- 'C' is mounted on mount 'B' at dentry 'b'. Also new mounts 'C1', 'C2',
- 'C3' ... are created and mounted at the dentry 'b' on all mounts where
- 'B' propagates to. A new propagation tree containing the new mounts
- 'C','C1',.. 'Cn' is created. This propagation tree is identical to the
- propagation tree for 'B'. And finally the mount 'C' and its peer group
- is made the slave of mount 'Z'. In other words, mount 'C' is in the
- state 'slave and shared'.
-
- 4. 'A' is a unbindable mount and 'B' is a shared mount. This is a
- invalid operation.
-
- 5. 'A' is a private mount and 'B' is a non-shared(private or slave or
- unbindable) mount. A new mount 'C' which is clone of 'A', is created.
- Its root dentry is 'a'. 'C' is mounted on mount 'B' at dentry 'b'.
-
- 6. 'A' is a shared mount and 'B' is a non-shared mount. A new mount 'C'
- which is a clone of 'A' is created. Its root dentry is 'a'. 'C' is
- mounted on mount 'B' at dentry 'b'. 'C' is made a member of the
- peer-group of 'A'.
-
- 7. 'A' is a slave mount of mount 'Z' and 'B' is a non-shared mount. A
- new mount 'C' which is a clone of 'A' is created. Its root dentry is
- 'a'. 'C' is mounted on mount 'B' at dentry 'b'. Also 'C' is set as a
- slave mount of 'Z'. In other words 'A' and 'C' are both slave mounts of
- 'Z'. All mount/unmount events on 'Z' propagates to 'A' and 'C'. But
- mount/unmount on 'A' do not propagate anywhere else. Similarly
- mount/unmount on 'C' do not propagate anywhere else.
-
- 8. 'A' is a unbindable mount and 'B' is a non-shared mount. This is a
- invalid operation. A unbindable mount cannot be bind mounted.
-
-5c) Rbind semantics
-
- rbind is same as bind. Bind replicates the specified mount. Rbind
- replicates all the mounts in the tree belonging to the specified mount.
- Rbind mount is bind mount applied to all the mounts in the tree.
-
- If the source tree that is rbind has some unbindable mounts,
- then the subtree under the unbindable mount is pruned in the new
- location.
-
- eg:
-
- let's say we have the following mount tree::
-
- A
- / \
- B C
- / \ / \
- D E F G
-
- Let's say all the mount except the mount C in the tree are
- of a type other than unbindable.
-
- If this tree is rbound to say Z
-
- We will have the following tree at the new location::
-
- Z
- |
- A'
- /
- B' Note how the tree under C is pruned
- / \ in the new location.
- D' E'
-
-
-
-5d) Move semantics
-
- Consider the following command
-
- mount --move A B/b
+ 3. 'A' is a slave mount of mount 'Z' and 'B' is a shared mount. A new
+ mount 'C' which is clone of 'A', is created. Its root dentry is 'a' .
+ 'C' is mounted on mount 'B' at dentry 'b'. Also new mounts 'C1', 'C2',
+ 'C3' ... are created and mounted at the dentry 'b' on all mounts where
+ 'B' propagates to. A new propagation tree containing the new mounts
+ 'C','C1',.. 'Cn' is created. This propagation tree is identical to the
+ propagation tree for 'B'. And finally the mount 'C' and its peer group
+ is made the slave of mount 'Z'. In other words, mount 'C' is in the
+ state 'slave and shared'.
+
+ 4. 'A' is a unbindable mount and 'B' is a shared mount. This is a
+ invalid operation.
+
+ 5. 'A' is a private mount and 'B' is a non-shared(private or slave or
+ unbindable) mount. A new mount 'C' which is clone of 'A', is created.
+ Its root dentry is 'a'. 'C' is mounted on mount 'B' at dentry 'b'.
+
+ 6. 'A' is a shared mount and 'B' is a non-shared mount. A new mount 'C'
+ which is a clone of 'A' is created. Its root dentry is 'a'. 'C' is
+ mounted on mount 'B' at dentry 'b'. 'C' is made a member of the
+ peer-group of 'A'.
+
+ 7. 'A' is a slave mount of mount 'Z' and 'B' is a non-shared mount. A
+ new mount 'C' which is a clone of 'A' is created. Its root dentry is
+ 'a'. 'C' is mounted on mount 'B' at dentry 'b'. Also 'C' is set as a
+ slave mount of 'Z'. In other words 'A' and 'C' are both slave mounts of
+ 'Z'. All mount/unmount events on 'Z' propagates to 'A' and 'C'. But
+ mount/unmount on 'A' do not propagate anywhere else. Similarly
+ mount/unmount on 'C' do not propagate anywhere else.
+
+ 8. 'A' is a unbindable mount and 'B' is a non-shared mount. This is a
+ invalid operation. A unbindable mount cannot be bind mounted.
+
+c) Rbind semantics
+
+ rbind is same as bind. Bind replicates the specified mount. Rbind
+ replicates all the mounts in the tree belonging to the specified mount.
+ Rbind mount is bind mount applied to all the mounts in the tree.
+
+ If the source tree that is rbind has some unbindable mounts,
+ then the subtree under the unbindable mount is pruned in the new
+ location.
+
+ eg:
+
+ let's say we have the following mount tree::
+
+ A
+ / \
+ B C
+ / \ / \
+ D E F G
+
+ Let's say all the mount except the mount C in the tree are
+ of a type other than unbindable.
+
+ If this tree is rbound to say Z
+
+ We will have the following tree at the new location::
+
+ Z
+ |
+ A'
+ /
+ B' Note how the tree under C is pruned
+ / \ in the new location.
+ D' E'
+
+
+
+d) Move semantics
+
+ Consider the following command::
+
+ mount --move A B/b
- where 'A' is the source mount, 'B' is the destination mount and 'b' is
- the dentry in the destination mount.
+ where 'A' is the source mount, 'B' is the destination mount and 'b' is
+ the dentry in the destination mount.
- The outcome depends on the type of the mount of 'A' and 'B'. The table
- below is a quick reference::
+ The outcome depends on the type of the mount of 'A' and 'B'. The table
+ below is a quick reference::
- ---------------------------------------------------------------------------
- | MOVE MOUNT OPERATION |
- |**************************************************************************
- | source(A)->| shared | private | slave | unbindable |
- | dest(B) | | | | |
- | | | | | | |
- | v | | | | |
- |**************************************************************************
- | shared | shared | shared |shared and slave| invalid |
- | | | | | |
- |non-shared| shared | private | slave | unbindable |
- ***************************************************************************
+ ---------------------------------------------------------------------------
+ | MOVE MOUNT OPERATION |
+ |**************************************************************************
+ | source(A)->| shared | private | slave | unbindable |
+ | dest(B) | | | | |
+ | | | | | | |
+ | v | | | | |
+ |**************************************************************************
+ | shared | shared | shared |shared and slave| invalid |
+ | | | | | |
+ |non-shared| shared | private | slave | unbindable |
+ ***************************************************************************
- .. Note:: moving a mount residing under a shared mount is invalid.
+ .. Note:: moving a mount residing under a shared mount is invalid.
- Details follow:
+ Details follow:
- 1. 'A' is a shared mount and 'B' is a shared mount. The mount 'A' is
- mounted on mount 'B' at dentry 'b'. Also new mounts 'A1', 'A2'...'An'
- are created and mounted at dentry 'b' on all mounts that receive
- propagation from mount 'B'. A new propagation tree is created in the
- exact same configuration as that of 'B'. This new propagation tree
- contains all the new mounts 'A1', 'A2'... 'An'. And this new
- propagation tree is appended to the already existing propagation tree
- of 'A'.
+ 1. 'A' is a shared mount and 'B' is a shared mount. The mount 'A' is
+ mounted on mount 'B' at dentry 'b'. Also new mounts 'A1', 'A2'...'An'
+ are created and mounted at dentry 'b' on all mounts that receive
+ propagation from mount 'B'. A new propagation tree is created in the
+ exact same configuration as that of 'B'. This new propagation tree
+ contains all the new mounts 'A1', 'A2'... 'An'. And this new
+ propagation tree is appended to the already existing propagation tree
+ of 'A'.
- 2. 'A' is a private mount and 'B' is a shared mount. The mount 'A' is
- mounted on mount 'B' at dentry 'b'. Also new mount 'A1', 'A2'... 'An'
- are created and mounted at dentry 'b' on all mounts that receive
- propagation from mount 'B'. The mount 'A' becomes a shared mount and a
- propagation tree is created which is identical to that of
- 'B'. This new propagation tree contains all the new mounts 'A1',
- 'A2'... 'An'.
+ 2. 'A' is a private mount and 'B' is a shared mount. The mount 'A' is
+ mounted on mount 'B' at dentry 'b'. Also new mount 'A1', 'A2'... 'An'
+ are created and mounted at dentry 'b' on all mounts that receive
+ propagation from mount 'B'. The mount 'A' becomes a shared mount and a
+ propagation tree is created which is identical to that of
+ 'B'. This new propagation tree contains all the new mounts 'A1',
+ 'A2'... 'An'.
- 3. 'A' is a slave mount of mount 'Z' and 'B' is a shared mount. The
- mount 'A' is mounted on mount 'B' at dentry 'b'. Also new mounts 'A1',
- 'A2'... 'An' are created and mounted at dentry 'b' on all mounts that
- receive propagation from mount 'B'. A new propagation tree is created
- in the exact same configuration as that of 'B'. This new propagation
- tree contains all the new mounts 'A1', 'A2'... 'An'. And this new
- propagation tree is appended to the already existing propagation tree of
- 'A'. Mount 'A' continues to be the slave mount of 'Z' but it also
- becomes 'shared'.
+ 3. 'A' is a slave mount of mount 'Z' and 'B' is a shared mount. The
+ mount 'A' is mounted on mount 'B' at dentry 'b'. Also new mounts 'A1',
+ 'A2'... 'An' are created and mounted at dentry 'b' on all mounts that
+ receive propagation from mount 'B'. A new propagation tree is created
+ in the exact same configuration as that of 'B'. This new propagation
+ tree contains all the new mounts 'A1', 'A2'... 'An'. And this new
+ propagation tree is appended to the already existing propagation tree of
+ 'A'. Mount 'A' continues to be the slave mount of 'Z' but it also
+ becomes 'shared'.
- 4. 'A' is a unbindable mount and 'B' is a shared mount. The operation
- is invalid. Because mounting anything on the shared mount 'B' can
- create new mounts that get mounted on the mounts that receive
- propagation from 'B'. And since the mount 'A' is unbindable, cloning
- it to mount at other mountpoints is not possible.
+ 4. 'A' is a unbindable mount and 'B' is a shared mount. The operation
+ is invalid. Because mounting anything on the shared mount 'B' can
+ create new mounts that get mounted on the mounts that receive
+ propagation from 'B'. And since the mount 'A' is unbindable, cloning
+ it to mount at other mountpoints is not possible.
- 5. 'A' is a private mount and 'B' is a non-shared(private or slave or
- unbindable) mount. The mount 'A' is mounted on mount 'B' at dentry 'b'.
+ 5. 'A' is a private mount and 'B' is a non-shared(private or slave or
+ unbindable) mount. The mount 'A' is mounted on mount 'B' at dentry 'b'.
- 6. 'A' is a shared mount and 'B' is a non-shared mount. The mount 'A'
- is mounted on mount 'B' at dentry 'b'. Mount 'A' continues to be a
- shared mount.
+ 6. 'A' is a shared mount and 'B' is a non-shared mount. The mount 'A'
+ is mounted on mount 'B' at dentry 'b'. Mount 'A' continues to be a
+ shared mount.
- 7. 'A' is a slave mount of mount 'Z' and 'B' is a non-shared mount.
- The mount 'A' is mounted on mount 'B' at dentry 'b'. Mount 'A'
- continues to be a slave mount of mount 'Z'.
+ 7. 'A' is a slave mount of mount 'Z' and 'B' is a non-shared mount.
+ The mount 'A' is mounted on mount 'B' at dentry 'b'. Mount 'A'
+ continues to be a slave mount of mount 'Z'.
- 8. 'A' is a unbindable mount and 'B' is a non-shared mount. The mount
- 'A' is mounted on mount 'B' at dentry 'b'. Mount 'A' continues to be a
- unbindable mount.
+ 8. 'A' is a unbindable mount and 'B' is a non-shared mount. The mount
+ 'A' is mounted on mount 'B' at dentry 'b'. Mount 'A' continues to be a
+ unbindable mount.
-5e) Mount semantics
+e) Mount semantics
- Consider the following command::
+ Consider the following command::
- mount device B/b
+ mount device B/b
- 'B' is the destination mount and 'b' is the dentry in the destination
- mount.
+ 'B' is the destination mount and 'b' is the dentry in the destination
+ mount.
- The above operation is the same as bind operation with the exception
- that the source mount is always a private mount.
+ The above operation is the same as bind operation with the exception
+ that the source mount is always a private mount.
-5f) Unmount semantics
+f) Unmount semantics
- Consider the following command::
+ Consider the following command::
- umount A
+ umount A
- where 'A' is a mount mounted on mount 'B' at dentry 'b'.
+ where 'A' is a mount mounted on mount 'B' at dentry 'b'.
- If mount 'B' is shared, then all most-recently-mounted mounts at dentry
- 'b' on mounts that receive propagation from mount 'B' and does not have
- sub-mounts within them are unmounted.
+ If mount 'B' is shared, then all most-recently-mounted mounts at dentry
+ 'b' on mounts that receive propagation from mount 'B' and does not have
+ sub-mounts within them are unmounted.
- Example: Let's say 'B1', 'B2', 'B3' are shared mounts that propagate to
- each other.
+ Example: Let's say 'B1', 'B2', 'B3' are shared mounts that propagate to
+ each other.
- let's say 'A1', 'A2', 'A3' are first mounted at dentry 'b' on mount
- 'B1', 'B2' and 'B3' respectively.
+ let's say 'A1', 'A2', 'A3' are first mounted at dentry 'b' on mount
+ 'B1', 'B2' and 'B3' respectively.
- let's say 'C1', 'C2', 'C3' are next mounted at the same dentry 'b' on
- mount 'B1', 'B2' and 'B3' respectively.
+ let's say 'C1', 'C2', 'C3' are next mounted at the same dentry 'b' on
+ mount 'B1', 'B2' and 'B3' respectively.
- if 'C1' is unmounted, all the mounts that are most-recently-mounted on
- 'B1' and on the mounts that 'B1' propagates-to are unmounted.
+ if 'C1' is unmounted, all the mounts that are most-recently-mounted on
+ 'B1' and on the mounts that 'B1' propagates-to are unmounted.
- 'B1' propagates to 'B2' and 'B3'. And the most recently mounted mount
- on 'B2' at dentry 'b' is 'C2', and that of mount 'B3' is 'C3'.
+ 'B1' propagates to 'B2' and 'B3'. And the most recently mounted mount
+ on 'B2' at dentry 'b' is 'C2', and that of mount 'B3' is 'C3'.
- So all 'C1', 'C2' and 'C3' should be unmounted.
+ So all 'C1', 'C2' and 'C3' should be unmounted.
- If any of 'C2' or 'C3' has some child mounts, then that mount is not
- unmounted, but all other mounts are unmounted. However if 'C1' is told
- to be unmounted and 'C1' has some sub-mounts, the umount operation is
- failed entirely.
+ If any of 'C2' or 'C3' has some child mounts, then that mount is not
+ unmounted, but all other mounts are unmounted. However if 'C1' is told
+ to be unmounted and 'C1' has some sub-mounts, the umount operation is
+ failed entirely.
-5g) Clone Namespace
+g) Clone Namespace
- A cloned namespace contains all the mounts as that of the parent
- namespace.
+ A cloned namespace contains all the mounts as that of the parent
+ namespace.
- Let's say 'A' and 'B' are the corresponding mounts in the parent and the
- child namespace.
+ Let's say 'A' and 'B' are the corresponding mounts in the parent and the
+ child namespace.
- If 'A' is shared, then 'B' is also shared and 'A' and 'B' propagate to
- each other.
+ If 'A' is shared, then 'B' is also shared and 'A' and 'B' propagate to
+ each other.
- If 'A' is a slave mount of 'Z', then 'B' is also the slave mount of
- 'Z'.
+ If 'A' is a slave mount of 'Z', then 'B' is also the slave mount of
+ 'Z'.
- If 'A' is a private mount, then 'B' is a private mount too.
+ If 'A' is a private mount, then 'B' is a private mount too.
- If 'A' is unbindable mount, then 'B' is a unbindable mount too.
+ If 'A' is unbindable mount, then 'B' is a unbindable mount too.
6) Quiz
+-------
- A. What is the result of the following command sequence?
+A. What is the result of the following command sequence?
- ::
+ ::
- mount --bind /mnt /mnt
- mount --make-shared /mnt
- mount --bind /mnt /tmp
- mount --move /tmp /mnt/1
+ mount --bind /mnt /mnt
+ mount --make-shared /mnt
+ mount --bind /mnt /tmp
+ mount --move /tmp /mnt/1
- what should be the contents of /mnt /mnt/1 /mnt/1/1 should be?
- Should they all be identical? or should /mnt and /mnt/1 be
- identical only?
+ what should be the contents of /mnt /mnt/1 /mnt/1/1 should be?
+ Should they all be identical? or should /mnt and /mnt/1 be
+ identical only?
- B. What is the result of the following command sequence?
+B. What is the result of the following command sequence?
- ::
+ ::
- mount --make-rshared /
- mkdir -p /v/1
- mount --rbind / /v/1
+ mount --make-rshared /
+ mkdir -p /v/1
+ mount --rbind / /v/1
- what should be the content of /v/1/v/1 be?
+ what should be the content of /v/1/v/1 be?
- C. What is the result of the following command sequence?
+C. What is the result of the following command sequence?
- ::
+ ::
- mount --bind /mnt /mnt
- mount --make-shared /mnt
- mkdir -p /mnt/1/2/3 /mnt/1/test
- mount --bind /mnt/1 /tmp
- mount --make-slave /mnt
- mount --make-shared /mnt
- mount --bind /mnt/1/2 /tmp1
- mount --make-slave /mnt
+ mount --bind /mnt /mnt
+ mount --make-shared /mnt
+ mkdir -p /mnt/1/2/3 /mnt/1/test
+ mount --bind /mnt/1 /tmp
+ mount --make-slave /mnt
+ mount --make-shared /mnt
+ mount --bind /mnt/1/2 /tmp1
+ mount --make-slave /mnt
- At this point we have the first mount at /tmp and
- its root dentry is 1. Let's call this mount 'A'
- And then we have a second mount at /tmp1 with root
- dentry 2. Let's call this mount 'B'
- Next we have a third mount at /mnt with root dentry
- mnt. Let's call this mount 'C'
+ At this point we have the first mount at /tmp and
+ its root dentry is 1. Let's call this mount 'A'
+ And then we have a second mount at /tmp1 with root
+ dentry 2. Let's call this mount 'B'
+ Next we have a third mount at /mnt with root dentry
+ mnt. Let's call this mount 'C'
- 'B' is the slave of 'A' and 'C' is a slave of 'B'
- A -> B -> C
+ 'B' is the slave of 'A' and 'C' is a slave of 'B'
+ A -> B -> C
- at this point if we execute the following command
+ at this point if we execute the following command::
- mount --bind /bin /tmp/test
+ mount --bind /bin /tmp/test
- The mount is attempted on 'A'
+ The mount is attempted on 'A'
- will the mount propagate to 'B' and 'C' ?
+ will the mount propagate to 'B' and 'C' ?
- what would be the contents of
- /mnt/1/test be?
+ what would be the contents of
+ /mnt/1/test be?
7) FAQ
+------
- Q1. Why is bind mount needed? How is it different from symbolic links?
- symbolic links can get stale if the destination mount gets
- unmounted or moved. Bind mounts continue to exist even if the
- other mount is unmounted or moved.
+1. Why is bind mount needed? How is it different from symbolic links?
- Q2. Why can't the shared subtree be implemented using exportfs?
+ symbolic links can get stale if the destination mount gets
+ unmounted or moved. Bind mounts continue to exist even if the
+ other mount is unmounted or moved.
- exportfs is a heavyweight way of accomplishing part of what
- shared subtree can do. I cannot imagine a way to implement the
- semantics of slave mount using exportfs?
+2. Why can't the shared subtree be implemented using exportfs?
- Q3 Why is unbindable mount needed?
+ exportfs is a heavyweight way of accomplishing part of what
+ shared subtree can do. I cannot imagine a way to implement the
+ semantics of slave mount using exportfs?
- Let's say we want to replicate the mount tree at multiple
- locations within the same subtree.
+3. Why is unbindable mount needed?
- if one rbind mounts a tree within the same subtree 'n' times
- the number of mounts created is an exponential function of 'n'.
- Having unbindable mount can help prune the unneeded bind
- mounts. Here is an example.
+ Let's say we want to replicate the mount tree at multiple
+ locations within the same subtree.
- step 1:
- let's say the root tree has just two directories with
- one vfsmount::
+ if one rbind mounts a tree within the same subtree 'n' times
+ the number of mounts created is an exponential function of 'n'.
+ Having unbindable mount can help prune the unneeded bind
+ mounts. Here is an example.
- root
- / \
- tmp usr
+ step 1:
+ let's say the root tree has just two directories with
+ one vfsmount::
- And we want to replicate the tree at multiple
- mountpoints under /root/tmp
+ root
+ / \
+ tmp usr
- step 2:
- ::
+ And we want to replicate the tree at multiple
+ mountpoints under /root/tmp
+ step 2:
+ ::
- mount --make-shared /root
- mkdir -p /tmp/m1
+ mount --make-shared /root
- mount --rbind /root /tmp/m1
+ mkdir -p /tmp/m1
- the new tree now looks like this::
+ mount --rbind /root /tmp/m1
- root
- / \
- tmp usr
- /
- m1
- / \
- tmp usr
- /
- m1
+ the new tree now looks like this::
- it has two vfsmounts
+ root
+ / \
+ tmp usr
+ /
+ m1
+ / \
+ tmp usr
+ /
+ m1
- step 3:
- ::
+ it has two vfsmounts
- mkdir -p /tmp/m2
- mount --rbind /root /tmp/m2
+ step 3:
+ ::
- the new tree now looks like this::
+ mkdir -p /tmp/m2
+ mount --rbind /root /tmp/m2
- root
- / \
- tmp usr
- / \
- m1 m2
- / \ / \
- tmp usr tmp usr
- / \ /
- m1 m2 m1
- / \ / \
- tmp usr tmp usr
- / / \
- m1 m1 m2
- / \
- tmp usr
- / \
- m1 m2
+ the new tree now looks like this::
- it has 6 vfsmounts
+ root
+ / \
+ tmp usr
+ / \
+ m1 m2
+ / \ / \
+ tmp usr tmp usr
+ / \ /
+ m1 m2 m1
+ / \ / \
+ tmp usr tmp usr
+ / / \
+ m1 m1 m2
+ / \
+ tmp usr
+ / \
+ m1 m2
- step 4:
- ::
- mkdir -p /tmp/m3
- mount --rbind /root /tmp/m3
+ it has 6 vfsmounts
- I won't draw the tree..but it has 24 vfsmounts
+ step 4:
+ ::
+ mkdir -p /tmp/m3
+ mount --rbind /root /tmp/m3
- at step i the number of vfsmounts is V[i] = i*V[i-1].
- This is an exponential function. And this tree has way more
- mounts than what we really needed in the first place.
+ I won't draw the tree..but it has 24 vfsmounts
- One could use a series of umount at each step to prune
- out the unneeded mounts. But there is a better solution.
- Unclonable mounts come in handy here.
- step 1:
- let's say the root tree has just two directories with
- one vfsmount::
+ at step i the number of vfsmounts is V[i] = i*V[i-1].
+ This is an exponential function. And this tree has way more
+ mounts than what we really needed in the first place.
- root
- / \
- tmp usr
+ One could use a series of umount at each step to prune
+ out the unneeded mounts. But there is a better solution.
+ Unclonable mounts come in handy here.
- How do we set up the same tree at multiple locations under
- /root/tmp
+ step 1:
+ let's say the root tree has just two directories with
+ one vfsmount::
- step 2:
- ::
+ root
+ / \
+ tmp usr
+ How do we set up the same tree at multiple locations under
+ /root/tmp
- mount --bind /root/tmp /root/tmp
+ step 2:
+ ::
- mount --make-rshared /root
- mount --make-unbindable /root/tmp
- mkdir -p /tmp/m1
+ mount --bind /root/tmp /root/tmp
- mount --rbind /root /tmp/m1
+ mount --make-rshared /root
+ mount --make-unbindable /root/tmp
- the new tree now looks like this::
+ mkdir -p /tmp/m1
- root
- / \
- tmp usr
- /
- m1
- / \
- tmp usr
+ mount --rbind /root /tmp/m1
- step 3:
- ::
+ the new tree now looks like this::
- mkdir -p /tmp/m2
- mount --rbind /root /tmp/m2
+ root
+ / \
+ tmp usr
+ /
+ m1
+ / \
+ tmp usr
- the new tree now looks like this::
+ step 3:
+ ::
- root
- / \
- tmp usr
- / \
- m1 m2
- / \ / \
- tmp usr tmp usr
+ mkdir -p /tmp/m2
+ mount --rbind /root /tmp/m2
- step 4:
- ::
+ the new tree now looks like this::
- mkdir -p /tmp/m3
- mount --rbind /root /tmp/m3
+ root
+ / \
+ tmp usr
+ / \
+ m1 m2
+ / \ / \
+ tmp usr tmp usr
- the new tree now looks like this::
+ step 4:
+ ::
- root
- / \
- tmp usr
- / \ \
- m1 m2 m3
- / \ / \ / \
- tmp usr tmp usr tmp usr
+ mkdir -p /tmp/m3
+ mount --rbind /root /tmp/m3
+
+ the new tree now looks like this::
+
+ root
+ / \
+ tmp usr
+ / \ \
+ m1 m2 m3
+ / \ / \ / \
+ tmp usr tmp usr tmp usr
8) Implementation
+-----------------
+
+A) Datastructure
+
+ Several new fields are introduced to struct vfsmount:
-8A) Datastructure
+ ->mnt_share
+ Links together all the mount to/from which this vfsmount
+ send/receives propagation events.
- 4 new fields are introduced to struct vfsmount:
+ ->mnt_slave_list
+ Links all the mounts to which this vfsmount propagates
+ to.
- * ->mnt_share
- * ->mnt_slave_list
- * ->mnt_slave
- * ->mnt_master
+ ->mnt_slave
+ Links together all the slaves that its master vfsmount
+ propagates to.
- ->mnt_share
- links together all the mount to/from which this vfsmount
- send/receives propagation events.
+ ->mnt_master
+ Points to the master vfsmount from which this vfsmount
+ receives propagation.
- ->mnt_slave_list
- links all the mounts to which this vfsmount propagates
- to.
+ ->mnt_flags
+ Takes two more flags to indicate the propagation status of
+ the vfsmount. MNT_SHARE indicates that the vfsmount is a shared
+ vfsmount. MNT_UNCLONABLE indicates that the vfsmount cannot be
+ replicated.
- ->mnt_slave
- links together all the slaves that its master vfsmount
- propagates to.
+ All the shared vfsmounts in a peer group form a cyclic list through
+ ->mnt_share.
- ->mnt_master
- points to the master vfsmount from which this vfsmount
- receives propagation.
+ All vfsmounts with the same ->mnt_master form on a cyclic list anchored
+ in ->mnt_master->mnt_slave_list and going through ->mnt_slave.
- ->mnt_flags
- takes two more flags to indicate the propagation status of
- the vfsmount. MNT_SHARE indicates that the vfsmount is a shared
- vfsmount. MNT_UNCLONABLE indicates that the vfsmount cannot be
- replicated.
+ ->mnt_master can point to arbitrary (and possibly different) members
+ of master peer group. To find all immediate slaves of a peer group
+ you need to go through _all_ ->mnt_slave_list of its members.
+ Conceptually it's just a single set - distribution among the
+ individual lists does not affect propagation or the way propagation
+ tree is modified by operations.
- All the shared vfsmounts in a peer group form a cyclic list through
- ->mnt_share.
+ All vfsmounts in a peer group have the same ->mnt_master. If it is
+ non-NULL, they form a contiguous (ordered) segment of slave list.
- All vfsmounts with the same ->mnt_master form on a cyclic list anchored
- in ->mnt_master->mnt_slave_list and going through ->mnt_slave.
+ A example propagation tree looks as shown in the figure below.
- ->mnt_master can point to arbitrary (and possibly different) members
- of master peer group. To find all immediate slaves of a peer group
- you need to go through _all_ ->mnt_slave_list of its members.
- Conceptually it's just a single set - distribution among the
- individual lists does not affect propagation or the way propagation
- tree is modified by operations.
+ .. note::
+ Though it looks like a forest, if we consider all the shared
+ mounts as a conceptual entity called 'pnode', it becomes a tree.
- All vfsmounts in a peer group have the same ->mnt_master. If it is
- non-NULL, they form a contiguous (ordered) segment of slave list.
+ ::
- A example propagation tree looks as shown in the figure below.
- [ NOTE: Though it looks like a forest, if we consider all the shared
- mounts as a conceptual entity called 'pnode', it becomes a tree]::
+ A <--> B <--> C <---> D
+ /|\ /| |\
+ / F G J K H I
+ /
+ E<-->K
+ /|\
+ M L N
- A <--> B <--> C <---> D
- /|\ /| |\
- / F G J K H I
- /
- E<-->K
- /|\
- M L N
+ In the above figure A,B,C and D all are shared and propagate to each
+ other. 'A' has got 3 slave mounts 'E' 'F' and 'G' 'C' has got 2 slave
+ mounts 'J' and 'K' and 'D' has got two slave mounts 'H' and 'I'.
+ 'E' is also shared with 'K' and they propagate to each other. And
+ 'K' has 3 slaves 'M', 'L' and 'N'
- In the above figure A,B,C and D all are shared and propagate to each
- other. 'A' has got 3 slave mounts 'E' 'F' and 'G' 'C' has got 2 slave
- mounts 'J' and 'K' and 'D' has got two slave mounts 'H' and 'I'.
- 'E' is also shared with 'K' and they propagate to each other. And
- 'K' has 3 slaves 'M', 'L' and 'N'
+ A's ->mnt_share links with the ->mnt_share of 'B' 'C' and 'D'
- A's ->mnt_share links with the ->mnt_share of 'B' 'C' and 'D'
+ A's ->mnt_slave_list links with ->mnt_slave of 'E', 'K', 'F' and 'G'
- A's ->mnt_slave_list links with ->mnt_slave of 'E', 'K', 'F' and 'G'
+ E's ->mnt_share links with ->mnt_share of K
- E's ->mnt_share links with ->mnt_share of K
+ 'E', 'K', 'F', 'G' have their ->mnt_master point to struct vfsmount of 'A'
- 'E', 'K', 'F', 'G' have their ->mnt_master point to struct vfsmount of 'A'
+ 'M', 'L', 'N' have their ->mnt_master point to struct vfsmount of 'K'
- 'M', 'L', 'N' have their ->mnt_master point to struct vfsmount of 'K'
+ K's ->mnt_slave_list links with ->mnt_slave of 'M', 'L' and 'N'
- K's ->mnt_slave_list links with ->mnt_slave of 'M', 'L' and 'N'
+ C's ->mnt_slave_list links with ->mnt_slave of 'J' and 'K'
- C's ->mnt_slave_list links with ->mnt_slave of 'J' and 'K'
+ J and K's ->mnt_master points to struct vfsmount of C
- J and K's ->mnt_master points to struct vfsmount of C
+ and finally D's ->mnt_slave_list links with ->mnt_slave of 'H' and 'I'
- and finally D's ->mnt_slave_list links with ->mnt_slave of 'H' and 'I'
+ 'H' and 'I' have their ->mnt_master pointing to struct vfsmount of 'D'.
- 'H' and 'I' have their ->mnt_master pointing to struct vfsmount of 'D'.
+ NOTE: The propagation tree is orthogonal to the mount tree.
- NOTE: The propagation tree is orthogonal to the mount tree.
+B) Locking:
-8B Locking:
+ ->mnt_share, ->mnt_slave, ->mnt_slave_list, ->mnt_master are protected
+ by namespace_sem (exclusive for modifications, shared for reading).
- ->mnt_share, ->mnt_slave, ->mnt_slave_list, ->mnt_master are protected
- by namespace_sem (exclusive for modifications, shared for reading).
+ Normally we have ->mnt_flags modifications serialized by vfsmount_lock.
+ There are two exceptions: do_add_mount() and clone_mnt().
+ The former modifies a vfsmount that has not been visible in any shared
+ data structures yet.
+ The latter holds namespace_sem and the only references to vfsmount
+ are in lists that can't be traversed without namespace_sem.
- Normally we have ->mnt_flags modifications serialized by vfsmount_lock.
- There are two exceptions: do_add_mount() and clone_mnt().
- The former modifies a vfsmount that has not been visible in any shared
- data structures yet.
- The latter holds namespace_sem and the only references to vfsmount
- are in lists that can't be traversed without namespace_sem.
+C) Algorithm:
-8C Algorithm:
+ The crux of the implementation resides in rbind/move operation.
- The crux of the implementation resides in rbind/move operation.
+ The overall algorithm breaks the operation into 3 phases: (look at
+ attach_recursive_mnt() and propagate_mnt())
- The overall algorithm breaks the operation into 3 phases: (look at
- attach_recursive_mnt() and propagate_mnt())
+ 1. Prepare phase.
- 1. prepare phase.
- 2. commit phases.
- 3. abort phases.
+ For each mount in the source tree:
- Prepare phase:
+ a) Create the necessary number of mount trees to
+ be attached to each of the mounts that receive
+ propagation from the destination mount.
+ b) Do not attach any of the trees to its destination.
+ However note down its ->mnt_parent and ->mnt_mountpoint
+ c) Link all the new mounts to form a propagation tree that
+ is identical to the propagation tree of the destination
+ mount.
- for each mount in the source tree:
+ If this phase is successful, there should be 'n' new
+ propagation trees; where 'n' is the number of mounts in the
+ source tree. Go to the commit phase
- a) Create the necessary number of mount trees to
- be attached to each of the mounts that receive
- propagation from the destination mount.
- b) Do not attach any of the trees to its destination.
- However note down its ->mnt_parent and ->mnt_mountpoint
- c) Link all the new mounts to form a propagation tree that
- is identical to the propagation tree of the destination
- mount.
+ Also there should be 'm' new mount trees, where 'm' is
+ the number of mounts to which the destination mount
+ propagates to.
- If this phase is successful, there should be 'n' new
- propagation trees; where 'n' is the number of mounts in the
- source tree. Go to the commit phase
+ If any memory allocations fail, go to the abort phase.
- Also there should be 'm' new mount trees, where 'm' is
- the number of mounts to which the destination mount
- propagates to.
+ 2. Commit phase.
- if any memory allocations fail, go to the abort phase.
+ Attach each of the mount trees to their corresponding
+ destination mounts.
- Commit phase
- attach each of the mount trees to their corresponding
- destination mounts.
+ 3. Abort phase.
- Abort phase
- delete all the newly created trees.
+ Delete all the newly created trees.
- .. Note::
- all the propagation related functionality resides in the file pnode.c
+ .. Note::
+ all the propagation related functionality resides in the file pnode.c
------------------------------------------------------------------------
diff --git a/Documentation/filesystems/cifs/cifsroot.rst b/Documentation/filesystems/smb/cifsroot.rst
index 4930bb443134..bf2d9db3acb9 100644
--- a/Documentation/filesystems/cifs/cifsroot.rst
+++ b/Documentation/filesystems/smb/cifsroot.rst
@@ -59,7 +59,7 @@ the root file system via SMB protocol.
Enables the kernel to mount the root file system via SMB that are
located in the <server-ip> and <share> specified in this option.
-The default mount options are set in fs/cifs/cifsroot.c.
+The default mount options are set in fs/smb/client/cifsroot.c.
server-ip
IPv4 address of the server.
diff --git a/Documentation/filesystems/smb/index.rst b/Documentation/filesystems/smb/index.rst
new file mode 100644
index 000000000000..6df23b0e45c8
--- /dev/null
+++ b/Documentation/filesystems/smb/index.rst
@@ -0,0 +1,11 @@
+===============================
+CIFS
+===============================
+
+
+.. toctree::
+ :maxdepth: 1
+
+ ksmbd
+ cifsroot
+ smbdirect
diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/smb/ksmbd.rst
index 7bed96d794fc..67cb68ea6e68 100644
--- a/Documentation/filesystems/cifs/ksmbd.rst
+++ b/Documentation/filesystems/smb/ksmbd.rst
@@ -13,7 +13,7 @@ KSMBD architecture
The subset of performance related operations belong in kernelspace and
the other subset which belong to operations which are not really related with
performance in userspace. So, DCE/RPC management that has historically resulted
-into number of buffer overflow issues and dangerous security bugs and user
+into a number of buffer overflow issues and dangerous security bugs and user
account management are implemented in user space as ksmbd.mountd.
File operations that are related with performance (open/read/write/close etc.)
in kernel space (ksmbd). This also allows for easier integration with VFS
@@ -24,8 +24,8 @@ ksmbd (kernel daemon)
When the server daemon is started, It starts up a forker thread
(ksmbd/interface name) at initialization time and open a dedicated port 445
-for listening to SMB requests. Whenever new clients make request, Forker
-thread will accept the client connection and fork a new thread for dedicated
+for listening to SMB requests. Whenever new clients make a request, the Forker
+thread will accept the client connection and fork a new thread for a dedicated
communication channel between the client and the server. It allows for parallel
processing of SMB requests(commands) from clients as well as allowing for new
clients to make new connections. Each instance is named ksmbd/1~n(port number)
@@ -34,12 +34,12 @@ thread can decide to pass through the commands to the user space (ksmbd.mountd),
currently DCE/RPC commands are identified to be handled through the user space.
To further utilize the linux kernel, it has been chosen to process the commands
as workitems and to be executed in the handlers of the ksmbd-io kworker threads.
-It allows for multiplexing of the handlers as the kernel take care of initiating
+It allows for multiplexing of the handlers as the kernel takes care of initiating
extra worker threads if the load is increased and vice versa, if the load is
-decreased it destroys the extra worker threads. So, after connection is
-established with client. Dedicated ksmbd/1..n(port number) takes complete
+decreased it destroys the extra worker threads. So, after the connection is
+established with the client. Dedicated ksmbd/1..n(port number) takes complete
ownership of receiving/parsing of SMB commands. Each received command is worked
-in parallel i.e., There can be multiple clients commands which are worked in
+in parallel i.e., there can be multiple client commands which are worked in
parallel. After receiving each command a separated kernel workitem is prepared
for each command which is further queued to be handled by ksmbd-io kworkers.
So, each SMB workitem is queued to the kworkers. This allows the benefit of load
@@ -49,9 +49,9 @@ performance by handling client commands in parallel.
ksmbd.mountd (user space daemon)
--------------------------------
-ksmbd.mountd is userspace process to, transfer user account and password that
+ksmbd.mountd is a userspace process to, transfer the user account and password that
are registered using ksmbd.adduser (part of utils for user space). Further it
-allows sharing information parameters that parsed from smb.conf to ksmbd in
+allows sharing information parameters that are parsed from smb.conf to ksmbd in
kernel. For the execution part it has a daemon which is continuously running
and connected to the kernel interface using netlink socket, it waits for the
requests (dcerpc and share/user info). It handles RPC calls (at a minimum few
@@ -73,15 +73,14 @@ Auto Negotiation Supported.
Compound Request Supported.
Oplock Cache Mechanism Supported.
SMB2 leases(v1 lease) Supported.
-Directory leases(v2 lease) Planned for future.
+Directory leases(v2 lease) Supported.
Multi-credits Supported.
NTLM/NTLMv2 Supported.
HMAC-SHA256 Signing Supported.
Secure negotiate Supported.
Signing Update Supported.
Pre-authentication integrity Supported.
-SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in
- progress)
+SMB3 encryption(CCM, GCM) Supported. (CCM/GCM128 and CCM/GCM256 supported)
SMB direct(RDMA) Supported.
SMB3 Multi-channel Partially Supported. Planned to implement
replay/retry mechanisms for future.
@@ -112,6 +111,10 @@ DCE/RPC support Partially Supported. a few calls(NetShareEnumAll,
for Witness protocol e.g.)
ksmbd/nfsd interoperability Planned for future. The features that ksmbd
support are Leases, Notify, ACLs and Share modes.
+SMB3.1.1 Compression Planned for future.
+SMB3.1.1 over QUIC Planned for future.
+Signing/Encryption over RDMA Planned for future.
+SMB3.1.1 GMAC signing support Planned for future.
============================== =================================================
@@ -121,7 +124,7 @@ How to run
1. Download ksmbd-tools(https://github.com/cifsd-team/ksmbd-tools/releases) and
compile them.
- - Refer README(https://github.com/cifsd-team/ksmbd-tools/blob/master/README.md)
+ - Refer to README(https://github.com/cifsd-team/ksmbd-tools/blob/master/README.md)
to know how to use ksmbd.mountd/adduser/addshare/control utils
$ ./autogen.sh
@@ -130,7 +133,7 @@ How to run
2. Create /usr/local/etc/ksmbd/ksmbd.conf file, add SMB share in ksmbd.conf file.
- - Refer ksmbd.conf.example in ksmbd-utils, See ksmbd.conf manpage
+ - Refer to ksmbd.conf.example in ksmbd-utils, See ksmbd.conf manpage
for details to configure shares.
$ man ksmbd.conf
@@ -142,7 +145,7 @@ How to run
$ man ksmbd.adduser
$ sudo ksmbd.adduser -a <Enter USERNAME for SMB share access>
-4. Insert ksmbd.ko module after build your kernel. No need to load module
+4. Insert the ksmbd.ko module after you build your kernel. No need to load the module
if ksmbd is built into the kernel.
- Set ksmbd in menuconfig(e.g. $ make menuconfig)
@@ -172,7 +175,7 @@ Each layer
1. Enable all component prints
# sudo ksmbd.control -d "all"
-2. Enable one of components (smb, auth, vfs, oplock, ipc, conn, rdma)
+2. Enable one of the components (smb, auth, vfs, oplock, ipc, conn, rdma)
# sudo ksmbd.control -d "smb"
3. Show what prints are enabled.
diff --git a/Documentation/filesystems/smb/smbdirect.rst b/Documentation/filesystems/smb/smbdirect.rst
new file mode 100644
index 000000000000..ca6927c0b2c0
--- /dev/null
+++ b/Documentation/filesystems/smb/smbdirect.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+SMB Direct - SMB3 over RDMA
+===========================
+
+This document describes how to set up the Linux SMB client and server to
+use RDMA.
+
+Overview
+========
+The Linux SMB kernel client supports SMB Direct, which is a transport
+scheme for SMB3 that uses RDMA (Remote Direct Memory Access) to provide
+high throughput and low latencies by bypassing the traditional TCP/IP
+stack.
+SMB Direct on the Linux SMB client can be tested against KSMBD - a
+kernel-space SMB server.
+
+Installation
+=============
+- Install an RDMA device. As long as the RDMA device driver is supported
+ by the kernel, it should work. This includes both software emulators (soft
+ RoCE, soft iWARP) and hardware devices (InfiniBand, RoCE, iWARP).
+
+- Install a kernel with SMB Direct support. The first kernel release to
+ support SMB Direct on both the client and server side is 5.15. Therefore,
+ a distribution compatible with kernel 5.15 or later is required.
+
+- Install cifs-utils, which provides the `mount.cifs` command to mount SMB
+ shares.
+
+- Configure the RDMA stack
+
+ Make sure that your kernel configuration has RDMA support enabled. Under
+ Device Drivers -> Infiniband support, update the kernel configuration to
+ enable Infiniband support.
+
+ Enable the appropriate IB HCA support or iWARP adapter support,
+ depending on your hardware.
+
+ If you are using InfiniBand, enable IP-over-InfiniBand support.
+
+ For soft RDMA, enable either the soft iWARP (`RDMA _SIW`) or soft RoCE
+ (`RDMA_RXE`) module. Install the `iproute2` package and use the
+ `rdma link add` command to load the module and create an
+ RDMA interface.
+
+ e.g. if your local ethernet interface is `eth0`, you can use:
+
+ .. code-block:: bash
+
+ sudo rdma link add siw0 type siw netdev eth0
+
+- Enable SMB Direct support for both the server and the client in the kernel
+ configuration.
+
+ Server Setup
+
+ .. code-block:: text
+
+ Network File Systems --->
+ <M> SMB3 server support
+ [*] Support for SMB Direct protocol
+
+ Client Setup
+
+ .. code-block:: text
+
+ Network File Systems --->
+ <M> SMB3 and CIFS support (advanced network filesystem)
+ [*] SMB Direct support
+
+- Build and install the kernel. SMB Direct support will be enabled in the
+ cifs.ko and ksmbd.ko modules.
+
+Setup and Usage
+================
+
+- Set up and start a KSMBD server as described in the `KSMBD documentation
+ <https://www.kernel.org/doc/Documentation/filesystems/smb/ksmbd.rst>`_.
+ Also add the "server multi channel support = yes" parameter to ksmbd.conf.
+
+- On the client, mount the share with `rdma` mount option to use SMB Direct
+ (specify a SMB version 3.0 or higher using `vers`).
+
+ For example:
+
+ .. code-block:: bash
+
+ mount -t cifs //server/share /mnt/point -o vers=3.1.1,rdma
+
+- To verify that the mount is using SMB Direct, you can check dmesg for the
+ following log line after mounting:
+
+ .. code-block:: text
+
+ CIFS: VFS: RDMA transport established
+
+ Or, verify `rdma` mount option for the share in `/proc/mounts`:
+
+ .. code-block:: bash
+
+ cat /proc/mounts | grep cifs
diff --git a/Documentation/filesystems/squashfs.rst b/Documentation/filesystems/squashfs.rst
index df42106bae71..45653b3228f9 100644
--- a/Documentation/filesystems/squashfs.rst
+++ b/Documentation/filesystems/squashfs.rst
@@ -6,7 +6,7 @@ Squashfs 4.0 Filesystem
Squashfs is a compressed read-only filesystem for Linux.
-It uses zlib, lz4, lzo, or xz compression to compress files, inodes and
+It uses zlib, lz4, lzo, xz or zstd compression to compress files, inodes and
directories. Inodes in the system are very small and all blocks are packed to
minimise data overhead. Block sizes greater than 4K are supported up to a
maximum of 1Mbytes (default block size 128K).
@@ -16,8 +16,8 @@ use (i.e. in cases where a .tar.gz file may be used), and in constrained
block device/memory systems (e.g. embedded systems) where low overhead is
needed.
-Mailing list: squashfs-devel@lists.sourceforge.net
-Web site: www.squashfs.org
+Mailing list (kernel code): linux-fsdevel@vger.kernel.org
+Web site: github.com/plougher/squashfs-tools
1. Filesystem Features
----------------------
@@ -58,11 +58,69 @@ inodes have different sizes).
As squashfs is a read-only filesystem, the mksquashfs program must be used to
create populated squashfs filesystems. This and other squashfs utilities
-can be obtained from http://www.squashfs.org. Usage instructions can be
-obtained from this site also.
+are very likely packaged by your linux distribution (called squashfs-tools).
+The source code can be obtained from github.com/plougher/squashfs-tools.
+Usage instructions can also be obtained from this site.
-The squashfs-tools development tree is now located on kernel.org
- git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
+2.1 Mount options
+-----------------
+=================== =========================================================
+errors=%s Specify whether squashfs errors trigger a kernel panic
+ or not
+
+ ========== =============================================
+ continue errors don't trigger a panic (default)
+ panic trigger a panic when errors are encountered,
+ similar to several other filesystems (e.g.
+ btrfs, ext4, f2fs, GFS2, jfs, ntfs, ubifs)
+
+ This allows a kernel dump to be saved,
+ useful for analyzing and debugging the
+ corruption.
+ ========== =============================================
+threads=%s Select the decompression mode or the number of threads
+
+ If SQUASHFS_CHOICE_DECOMP_BY_MOUNT is set:
+
+ ========== =============================================
+ single use single-threaded decompression (default)
+
+ Only one block (data or metadata) can be
+ decompressed at any one time. This limits
+ CPU and memory usage to a minimum, but it
+ also gives poor performance on parallel I/O
+ workloads when using multiple CPU machines
+ due to waiting on decompressor availability.
+ multi use up to two parallel decompressors per core
+
+ If you have a parallel I/O workload and your
+ system has enough memory, using this option
+ may improve overall I/O performance. It
+ dynamically allocates decompressors on a
+ demand basis.
+ percpu use a maximum of one decompressor per core
+
+ It uses percpu variables to ensure
+ decompression is load-balanced across the
+ cores.
+ 1|2|3|... configure the number of threads used for
+ decompression
+
+ The upper limit is num_online_cpus() * 2.
+ ========== =============================================
+
+ If SQUASHFS_CHOICE_DECOMP_BY_MOUNT is **not** set and
+ SQUASHFS_DECOMP_MULTI, SQUASHFS_MOUNT_DECOMP_THREADS are
+ both set:
+
+ ========== =============================================
+ 2|3|... configure the number of threads used for
+ decompression
+
+ The upper limit is num_online_cpus() * 2.
+ ========== =============================================
+
+=================== =========================================================
3. Squashfs Filesystem Design
-----------------------------
diff --git a/Documentation/filesystems/sysfs.rst b/Documentation/filesystems/sysfs.rst
index 004d490179f3..2703c04af7d0 100644
--- a/Documentation/filesystems/sysfs.rst
+++ b/Documentation/filesystems/sysfs.rst
@@ -12,10 +12,10 @@ Mike Murphy <mamurph@cs.clemson.edu>
:Original: 10 January 2003
-What it is:
-~~~~~~~~~~~
+What it is
+~~~~~~~~~~
-sysfs is a ram-based filesystem initially based on ramfs. It provides
+sysfs is a RAM-based filesystem initially based on ramfs. It provides
a means to export kernel data structures, their attributes, and the
linkages between them to userspace.
@@ -43,7 +43,7 @@ userspace. Top-level directories in sysfs represent the common
ancestors of object hierarchies; i.e. the subsystems the objects
belong to.
-Sysfs internally stores a pointer to the kobject that implements a
+sysfs internally stores a pointer to the kobject that implements a
directory in the kernfs_node object associated with the directory. In
the past this kobject pointer has been used by sysfs to do reference
counting directly on the kobject whenever the file is opened or closed.
@@ -55,7 +55,7 @@ Attributes
~~~~~~~~~~
Attributes can be exported for kobjects in the form of regular files in
-the filesystem. Sysfs forwards file I/O operations to methods defined
+the filesystem. sysfs forwards file I/O operations to methods defined
for the attributes, providing a means to read and write kernel
attributes.
@@ -72,8 +72,8 @@ you publicly humiliated and your code rewritten without notice.
An attribute definition is simply::
struct attribute {
- char * name;
- struct module *owner;
+ char *name;
+ struct module *owner;
umode_t mode;
};
@@ -138,7 +138,7 @@ __ATTR_WO(name):
assumes a name_store only and is restricted to mode
0200 that is root write access only.
__ATTR_RO_MODE(name, mode):
- fore more restrictive RO access currently
+ for more restrictive RO access; currently
only use case is the EFI System Resource Table
(see drivers/firmware/efi/esrt.c)
__ATTR_RW(name):
@@ -207,7 +207,7 @@ IOW, they should take only an object, an attribute, and a buffer as parameters.
sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the
-method. Sysfs will call the method exactly once for each read or
+method. sysfs will call the method exactly once for each read or
write. This forces the following behavior on the method
implementations:
@@ -221,7 +221,7 @@ implementations:
be called again, rearmed, to fill the buffer.
- On write(2), sysfs expects the entire buffer to be passed during the
- first write. Sysfs then passes the entire buffer to the store() method.
+ first write. sysfs then passes the entire buffer to the store() method.
A terminating null is added after the data on stores. This makes
functions like sysfs_streq() safe to use.
@@ -237,14 +237,14 @@ Other notes:
- Writing causes the show() method to be rearmed regardless of current
file position.
-- The buffer will always be PAGE_SIZE bytes in length. On i386, this
+- The buffer will always be PAGE_SIZE bytes in length. On x86, this
is 4096.
- show() methods should return the number of bytes printed into the
buffer.
-- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
- the value to be returned to user space.
+- New implementations of show() methods should only use sysfs_emit() or
+ sysfs_emit_at() when formatting the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
@@ -253,7 +253,7 @@ Other notes:
through, be sure to return an error.
- The object passed to the methods will be pinned in memory via sysfs
- referencing counting its embedded object. However, the physical
+ reference counting its embedded object. However, the physical
entity (e.g. device) the object represents may not be present. Be
sure to have a way to check this, if necessary.
@@ -263,7 +263,7 @@ A very simple (and naive) implementation of a device attribute is::
static ssize_t show_name(struct device *dev, struct device_attribute *attr,
char *buf)
{
- return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
+ return sysfs_emit(buf, "%s\n", dev->name);
}
static ssize_t store_name(struct device *dev, struct device_attribute *attr,
@@ -295,8 +295,11 @@ The top level sysfs directory looks like::
dev/
devices/
firmware/
- net/
fs/
+ hypervisor/
+ kernel/
+ module/
+ power/
devices/ contains a filesystem representation of the device tree. It maps
directly to the internal kernel device tree, which is a hierarchy of
@@ -309,7 +312,7 @@ kernel. Each bus's directory contains two subdirectories::
drivers/
devices/ contains symlinks for each device discovered in the system
-that point to the device's directory under root/.
+that point to the device's directory under /sys/devices.
drivers/ contains a directory for each device driver that is loaded
for devices on that particular bus (this assumes that drivers do not
@@ -317,25 +320,42 @@ span multiple bus types).
fs/ contains a directory for some filesystems. Currently each
filesystem wanting to export attributes must create its own hierarchy
-below fs/ (see ./fuse.txt for an example).
+below fs/ (see fuse/fuse.rst for an example).
-dev/ contains two directories char/ and block/. Inside these two
+module/ contains parameter values and state information for all
+loaded system modules, for both builtin and loadable modules.
+
+dev/ contains two directories: char/ and block/. Inside these two
directories there are symlinks named <major>:<minor>. These symlinks
-point to the sysfs directory for the given device. /sys/dev provides a
+point to the directories under /sys/devices for each device. /sys/dev provides a
quick way to lookup the sysfs interface for a device from the result of
a stat(2) operation.
-More information can driver-model specific features can be found in
+More information on driver-model specific features can be found in
Documentation/driver-api/driver-model/.
+block/ contains symlinks to all the block devices discovered on the system.
+These symlinks point to directories under /sys/devices.
+
+class/ contains a directory for each device class, grouped by functional type.
+Each directory in class/ contains symlinks to devices in the /sys/devices directory.
+
+firmware/ contains system firmware data and configuration such as firmware tables,
+ACPI information, and device tree data.
+
+hypervisor/ contains virtualization platform information and provides an interface to
+the underlying hypervisor. It is only present when running on a virtual machine.
+
+kernel/ contains runtime kernel parameters, configuration settings, and status.
-TODO: Finish this section.
+power/ contains power management subsystem information including
+sleep states, suspend/resume capabilities, and policies.
Current Interfaces
~~~~~~~~~~~~~~~~~~
-The following interface layers currently exist in sysfs:
+The following interface layers currently exist in sysfs.
devices (include/linux/device.h)
@@ -366,8 +386,8 @@ Structure::
struct bus_attribute {
struct attribute attr;
- ssize_t (*show)(struct bus_type *, char * buf);
- ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
+ ssize_t (*show)(const struct bus_type *, char * buf);
+ ssize_t (*store)(const struct bus_type *, const char * buf, size_t count);
};
Declaring::
diff --git a/Documentation/filesystems/sysv-fs.rst b/Documentation/filesystems/sysv-fs.rst
deleted file mode 100644
index 89e40911ad7c..000000000000
--- a/Documentation/filesystems/sysv-fs.rst
+++ /dev/null
@@ -1,264 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-==================
-SystemV Filesystem
-==================
-
-It implements all of
- - Xenix FS,
- - SystemV/386 FS,
- - Coherent FS.
-
-To install:
-
-* Answer the 'System V and Coherent filesystem support' question with 'y'
- when configuring the kernel.
-* To mount a disk or a partition, use::
-
- mount [-r] -t sysv device mountpoint
-
- The file system type names::
-
- -t sysv
- -t xenix
- -t coherent
-
- may be used interchangeably, but the last two will eventually disappear.
-
-Bugs in the present implementation:
-
-- Coherent FS:
-
- - The "free list interleave" n:m is currently ignored.
- - Only file systems with no filesystem name and no pack name are recognized.
- (See Coherent "man mkfs" for a description of these features.)
-
-- SystemV Release 2 FS:
-
- The superblock is only searched in the blocks 9, 15, 18, which
- corresponds to the beginning of track 1 on floppy disks. No support
- for this FS on hard disk yet.
-
-
-These filesystems are rather similar. Here is a comparison with Minix FS:
-
-* Linux fdisk reports on partitions
-
- - Minix FS 0x81 Linux/Minix
- - Xenix FS ??
- - SystemV FS ??
- - Coherent FS 0x08 AIX bootable
-
-* Size of a block or zone (data allocation unit on disk)
-
- - Minix FS 1024
- - Xenix FS 1024 (also 512 ??)
- - SystemV FS 1024 (also 512 and 2048)
- - Coherent FS 512
-
-* General layout: all have one boot block, one super block and
- separate areas for inodes and for directories/data.
- On SystemV Release 2 FS (e.g. Microport) the first track is reserved and
- all the block numbers (including the super block) are offset by one track.
-
-* Byte ordering of "short" (16 bit entities) on disk:
-
- - Minix FS little endian 0 1
- - Xenix FS little endian 0 1
- - SystemV FS little endian 0 1
- - Coherent FS little endian 0 1
-
- Of course, this affects only the file system, not the data of files on it!
-
-* Byte ordering of "long" (32 bit entities) on disk:
-
- - Minix FS little endian 0 1 2 3
- - Xenix FS little endian 0 1 2 3
- - SystemV FS little endian 0 1 2 3
- - Coherent FS PDP-11 2 3 0 1
-
- Of course, this affects only the file system, not the data of files on it!
-
-* Inode on disk: "short", 0 means non-existent, the root dir ino is:
-
- ================================= ==
- Minix FS 1
- Xenix FS, SystemV FS, Coherent FS 2
- ================================= ==
-
-* Maximum number of hard links to a file:
-
- =========== =========
- Minix FS 250
- Xenix FS ??
- SystemV FS ??
- Coherent FS >=10000
- =========== =========
-
-* Free inode management:
-
- - Minix FS
- a bitmap
- - Xenix FS, SystemV FS, Coherent FS
- There is a cache of a certain number of free inodes in the super-block.
- When it is exhausted, new free inodes are found using a linear search.
-
-* Free block management:
-
- - Minix FS
- a bitmap
- - Xenix FS, SystemV FS, Coherent FS
- Free blocks are organized in a "free list". Maybe a misleading term,
- since it is not true that every free block contains a pointer to
- the next free block. Rather, the free blocks are organized in chunks
- of limited size, and every now and then a free block contains pointers
- to the free blocks pertaining to the next chunk; the first of these
- contains pointers and so on. The list terminates with a "block number"
- 0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS.
-
-* Super-block location:
-
- =========== ==========================
- Minix FS block 1 = bytes 1024..2047
- Xenix FS block 1 = bytes 1024..2047
- SystemV FS bytes 512..1023
- Coherent FS block 1 = bytes 512..1023
- =========== ==========================
-
-* Super-block layout:
-
- - Minix FS::
-
- unsigned short s_ninodes;
- unsigned short s_nzones;
- unsigned short s_imap_blocks;
- unsigned short s_zmap_blocks;
- unsigned short s_firstdatazone;
- unsigned short s_log_zone_size;
- unsigned long s_max_size;
- unsigned short s_magic;
-
- - Xenix FS, SystemV FS, Coherent FS::
-
- unsigned short s_firstdatazone;
- unsigned long s_nzones;
- unsigned short s_fzone_count;
- unsigned long s_fzones[NICFREE];
- unsigned short s_finode_count;
- unsigned short s_finodes[NICINOD];
- char s_flock;
- char s_ilock;
- char s_modified;
- char s_rdonly;
- unsigned long s_time;
- short s_dinfo[4]; -- SystemV FS only
- unsigned long s_free_zones;
- unsigned short s_free_inodes;
- short s_dinfo[4]; -- Xenix FS only
- unsigned short s_interleave_m,s_interleave_n; -- Coherent FS only
- char s_fname[6];
- char s_fpack[6];
-
- then they differ considerably:
-
- Xenix FS::
-
- char s_clean;
- char s_fill[371];
- long s_magic;
- long s_type;
-
- SystemV FS::
-
- long s_fill[12 or 14];
- long s_state;
- long s_magic;
- long s_type;
-
- Coherent FS::
-
- unsigned long s_unique;
-
- Note that Coherent FS has no magic.
-
-* Inode layout:
-
- - Minix FS::
-
- unsigned short i_mode;
- unsigned short i_uid;
- unsigned long i_size;
- unsigned long i_time;
- unsigned char i_gid;
- unsigned char i_nlinks;
- unsigned short i_zone[7+1+1];
-
- - Xenix FS, SystemV FS, Coherent FS::
-
- unsigned short i_mode;
- unsigned short i_nlink;
- unsigned short i_uid;
- unsigned short i_gid;
- unsigned long i_size;
- unsigned char i_zone[3*(10+1+1+1)];
- unsigned long i_atime;
- unsigned long i_mtime;
- unsigned long i_ctime;
-
-
-* Regular file data blocks are organized as
-
- - Minix FS:
-
- - 7 direct blocks
- - 1 indirect block (pointers to blocks)
- - 1 double-indirect block (pointer to pointers to blocks)
-
- - Xenix FS, SystemV FS, Coherent FS:
-
- - 10 direct blocks
- - 1 indirect block (pointers to blocks)
- - 1 double-indirect block (pointer to pointers to blocks)
- - 1 triple-indirect block (pointer to pointers to pointers to blocks)
-
-
- =========== ========== ================
- Inode size inodes per block
- =========== ========== ================
- Minix FS 32 32
- Xenix FS 64 16
- SystemV FS 64 16
- Coherent FS 64 8
- =========== ========== ================
-
-* Directory entry on disk
-
- - Minix FS::
-
- unsigned short inode;
- char name[14/30];
-
- - Xenix FS, SystemV FS, Coherent FS::
-
- unsigned short inode;
- char name[14];
-
- =========== ============== =====================
- Dir entry size dir entries per block
- =========== ============== =====================
- Minix FS 16/32 64/32
- Xenix FS 16 64
- SystemV FS 16 64
- Coherent FS 16 32
- =========== ============== =====================
-
-* How to implement symbolic links such that the host fsck doesn't scream:
-
- - Minix FS normal
- - Xenix FS kludge: as regular files with chmod 1000
- - SystemV FS ??
- - Coherent FS kludge: as regular files with chmod 1000
-
-
-Notation: We often speak of a "block" but mean a zone (the allocation unit)
-and not the disk driver's notion of "block".
diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst
index 0408c245785e..d677e0428c3f 100644
--- a/Documentation/filesystems/tmpfs.rst
+++ b/Documentation/filesystems/tmpfs.rst
@@ -13,17 +13,29 @@ everything stored therein is lost.
tmpfs puts everything into the kernel internal caches and grows and
shrinks to accommodate the files it contains and is able to swap
-unneeded pages out to swap space. It has maximum size limits which can
-be adjusted on the fly via 'mount -o remount ...'
-
-If you compare it to ramfs (which was the template to create tmpfs)
-you gain swapping and limit checking. Another similar thing is the RAM
-disk (/dev/ram*), which simulates a fixed size hard disk in physical
-RAM, where you have to create an ordinary filesystem on top. Ramdisks
-cannot swap and you do not have the possibility to resize them.
-
-Since tmpfs lives completely in the page cache and on swap, all tmpfs
-pages will be shown as "Shmem" in /proc/meminfo and "Shared" in
+unneeded pages out to swap space, if swap was enabled for the tmpfs
+mount. tmpfs also supports THP.
+
+tmpfs extends ramfs with a few userspace configurable options listed and
+explained further below, some of which can be reconfigured dynamically on the
+fly using a remount ('mount -o remount ...') of the filesystem. A tmpfs
+filesystem can be resized but it cannot be resized to a size below its current
+usage. tmpfs also supports POSIX ACLs, and extended attributes for the
+trusted.*, security.* and user.* namespaces. ramfs does not use swap and you
+cannot modify any parameter for a ramfs filesystem. The size limit of a ramfs
+filesystem is how much memory you have available, and so care must be taken if
+used so to not run out of memory.
+
+An alternative to tmpfs and ramfs is to use brd to create RAM disks
+(/dev/ram*), which allows you to simulate a block device disk in physical RAM.
+To write data you would just then need to create an regular filesystem on top
+this ramdisk. As with ramfs, brd ramdisks cannot swap. brd ramdisks are also
+configured in size at initialization and you cannot dynamically resize them.
+Contrary to brd ramdisks, tmpfs has its own filesystem, it does not rely on the
+block layer at all.
+
+Since tmpfs lives completely in the page cache and optionally on swap,
+all tmpfs pages will be shown as "Shmem" in /proc/meminfo and "Shared" in
free(1). Notice that these counters also include shared memory
(shmem, see ipcs(1)). The most reliable way to get the count is
using df(1) and du(1).
@@ -85,6 +97,65 @@ mount with such options, since it allows any user with write access to
use up all the memory on the machine; but enhances the scalability of
that instance in a system with many CPUs making intensive use of it.
+If nr_inodes is not 0, that limited space for inodes is also used up by
+extended attributes: "df -i"'s IUsed and IUse% increase, IFree decreases.
+
+tmpfs blocks may be swapped out, when there is a shortage of memory.
+tmpfs has a mount option to disable its use of swap:
+
+====== ===========================================================
+noswap Disables swap. Remounts must respect the original settings.
+ By default swap is enabled.
+====== ===========================================================
+
+tmpfs also supports Transparent Huge Pages which requires a kernel
+configured with CONFIG_TRANSPARENT_HUGEPAGE and with huge supported for
+your system (has_transparent_hugepage(), which is architecture specific).
+The mount options for this are:
+
+================ ==============================================================
+huge=never Do not allocate huge pages. This is the default.
+huge=always Attempt to allocate huge page every time a new page is needed.
+huge=within_size Only allocate huge page if it will be fully within i_size.
+ Also respect madvise(2) hints.
+huge=advise Only allocate huge page if requested with madvise(2).
+================ ==============================================================
+
+See also Documentation/admin-guide/mm/transhuge.rst, which describes the
+sysfs file /sys/kernel/mm/transparent_hugepage/shmem_enabled: which can
+be used to deny huge pages on all tmpfs mounts in an emergency, or to
+force huge pages on all tmpfs mounts for testing.
+
+tmpfs also supports quota with the following mount options
+
+======================== =================================================
+quota User and group quota accounting and enforcement
+ is enabled on the mount. Tmpfs is using hidden
+ system quota files that are initialized on mount.
+usrquota User quota accounting and enforcement is enabled
+ on the mount.
+grpquota Group quota accounting and enforcement is enabled
+ on the mount.
+usrquota_block_hardlimit Set global user quota block hard limit.
+usrquota_inode_hardlimit Set global user quota inode hard limit.
+grpquota_block_hardlimit Set global group quota block hard limit.
+grpquota_inode_hardlimit Set global group quota inode hard limit.
+======================== =================================================
+
+None of the quota related mount options can be set or changed on remount.
+
+Quota limit parameters accept a suffix k, m or g for kilo, mega and giga
+and can't be changed on remount. Default global quota limits are taking
+effect for any and all user/group/project except root the first time the
+quota entry for user/group/project id is being accessed - typically the
+first time an inode with a particular id ownership is being created after
+the mount. In other words, instead of the limits being initialized to zero,
+they are initialized with the particular value provided with these mount
+options. The limits can be changed for any user/group id at any time as they
+normally can be.
+
+Note that tmpfs quotas do not support user namespaces so no uid/gid
+translation is done if quotas are enabled inside user namespaces.
tmpfs has a mount option to set the NUMA memory allocation policy for
all files in that instance (if CONFIG_NUMA is enabled) - which can be
@@ -170,6 +241,28 @@ So 'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'
will give you tmpfs instance on /mytmpfs which can allocate 10GB
RAM/SWAP in 10240 inodes and it is only accessible by root.
+tmpfs has the following mounting options for case-insensitive lookup support:
+
+================= ==============================================================
+casefold Enable casefold support at this mount point using the given
+ argument as the encoding standard. Currently only UTF-8
+ encodings are supported. If no argument is used, it will load
+ the latest UTF-8 encoding available.
+strict_encoding Enable strict encoding at this mount point (disabled by
+ default). In this mode, the filesystem refuses to create file
+ and directory with names containing invalid UTF-8 characters.
+================= ==============================================================
+
+This option doesn't render the entire filesystem case-insensitive. One needs to
+still set the casefold flag per directory, by flipping the +F attribute in an
+empty directory. Nevertheless, new directories will inherit the attribute. The
+mountpoint itself cannot be made case-insensitive.
+
+Example::
+
+ $ mount -t tmpfs -o casefold=utf8-12.1.0,strict_encoding fs_name /mytmpfs
+ $ mount -t tmpfs -o casefold fs_name /mytmpfs
+
:Author:
Christoph Rohland <cr@sap.com>, 1.12.01
@@ -179,3 +272,5 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
KOSAKI Motohiro, 16 Mar 2010
:Updated:
Chris Down, 13 July 2020
+:Updated:
+ André Almeida, 23 Aug 2024
diff --git a/Documentation/filesystems/ubifs-authentication.rst b/Documentation/filesystems/ubifs-authentication.rst
index 5210aed2afbc..106bb9c056f6 100644
--- a/Documentation/filesystems/ubifs-authentication.rst
+++ b/Documentation/filesystems/ubifs-authentication.rst
@@ -130,7 +130,7 @@ marked as dirty are written to the flash to update the persisted index.
Journal
~~~~~~~
-To avoid wearing out the flash, the index is only persisted (*commited*) when
+To avoid wearing out the flash, the index is only persisted (*committed*) when
certain conditions are met (eg. ``fsync(2)``). The journal is used to record
any changes (in form of inode nodes, data nodes etc.) between commits
of the index. During mount, the journal is read from the flash and replayed
@@ -443,6 +443,6 @@ References
[DM-VERITY] https://www.kernel.org/doc/Documentation/device-mapper/verity.rst
-[FSCRYPT-POLICY2] https://www.spinics.net/lists/linux-ext4/msg58710.html
+[FSCRYPT-POLICY2] https://lore.kernel.org/r/20171023214058.128121-1-ebiggers3@gmail.com/
[UBIFS-WP] http://www.linux-mtd.infradead.org/doc/ubifs_whitepaper.pdf
diff --git a/Documentation/filesystems/ubifs.rst b/Documentation/filesystems/ubifs.rst
index e6ee99762534..ced2f7679ddb 100644
--- a/Documentation/filesystems/ubifs.rst
+++ b/Documentation/filesystems/ubifs.rst
@@ -59,7 +59,7 @@ differences.
* JFFS2 is a write-through file-system, while UBIFS supports write-back,
which makes UBIFS much faster on writes.
-Similarly to JFFS2, UBIFS supports on-the-flight compression which makes
+Similarly to JFFS2, UBIFS supports on-the-fly compression which makes
it possible to fit quite a lot of data to the flash.
Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.
diff --git a/Documentation/filesystems/vfat.rst b/Documentation/filesystems/vfat.rst
index 760a4d83fdf9..b289c4449cd0 100644
--- a/Documentation/filesystems/vfat.rst
+++ b/Documentation/filesystems/vfat.rst
@@ -50,7 +50,7 @@ VFAT MOUNT OPTIONS
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
- check is too unflexible. With this option you can
+ check is too inflexible. With this option you can
relax it.
**codepage=###**
diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst
index b2ef2449aed9..670ba66b60e4 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -107,7 +107,7 @@ file /proc/filesystems.
struct file_system_type
-----------------------
-This describes the filesystem. As of kernel 2.6.39, the following
+This describes the filesystem. The following
members are defined:
.. code-block:: c
@@ -115,14 +115,24 @@ members are defined:
struct file_system_type {
const char *name;
int fs_flags;
+ int (*init_fs_context)(struct fs_context *);
+ const struct fs_parameter_spec *parameters;
struct dentry *(*mount) (struct file_system_type *, int,
- const char *, void *);
+ const char *, void *);
void (*kill_sb) (struct super_block *);
struct module *owner;
struct file_system_type * next;
- struct list_head fs_supers;
+ struct hlist_head fs_supers;
+
struct lock_class_key s_lock_key;
struct lock_class_key s_umount_key;
+ struct lock_class_key s_vfs_rename_key;
+ struct lock_class_key s_writers_key[SB_FREEZE_LEVELS];
+
+ struct lock_class_key i_lock_key;
+ struct lock_class_key i_mutex_key;
+ struct lock_class_key invalidate_lock_key;
+ struct lock_class_key i_mutex_dir_key;
};
``name``
@@ -132,6 +142,15 @@ members are defined:
``fs_flags``
various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
+``init_fs_context``
+ Initializes 'struct fs_context' ->ops and ->fs_private fields with
+ filesystem-specific data.
+
+``parameters``
+ Pointer to the array of filesystem parameters descriptors
+ 'struct fs_parameter_spec'.
+ More info in Documentation/filesystems/mount_api.rst.
+
``mount``
the method to call when a new instance of this filesystem should
be mounted
@@ -148,7 +167,11 @@ members are defined:
``next``
for internal VFS use: you should initialize this to NULL
- s_lock_key, s_umount_key: lockdep-specific
+``fs_supers``
+ for internal VFS use: hlist of filesystem instances (superblocks)
+
+ s_lock_key, s_umount_key, s_vfs_rename_key, s_writers_key,
+ i_lock_key, i_mutex_key, invalidate_lock_key, i_mutex_dir_key: lockdep-specific
The mount() method has the following arguments:
@@ -186,31 +209,8 @@ method fills in is the "s_op" field. This is a pointer to a "struct
super_operations" which describes the next level of the filesystem
implementation.
-Usually, a filesystem uses one of the generic mount() implementations
-and provides a fill_super() callback instead. The generic variants are:
-
-``mount_bdev``
- mount a filesystem residing on a block device
-
-``mount_nodev``
- mount a filesystem that is not backed by a device
-
-``mount_single``
- mount a filesystem which shares the instance between all mounts
-
-A fill_super() callback implementation has the following arguments:
-
-``struct super_block *sb``
- the superblock structure. The callback must initialize this
- properly.
-
-``void *data``
- arbitrary mount options, usually comes as an ASCII string (see
- "Mount Options" section)
-
-``int silent``
- whether or not to be silent on error
-
+For more information on mounting (and the new mount API), see
+Documentation/filesystems/mount_api.rst.
The Superblock Object
=====================
@@ -222,33 +222,44 @@ struct super_operations
-----------------------
This describes how the VFS can manipulate the superblock of your
-filesystem. As of kernel 2.6.22, the following members are defined:
+filesystem. The following members are defined:
.. code-block:: c
struct super_operations {
struct inode *(*alloc_inode)(struct super_block *sb);
void (*destroy_inode)(struct inode *);
+ void (*free_inode)(struct inode *);
void (*dirty_inode) (struct inode *, int flags);
- int (*write_inode) (struct inode *, int);
- void (*drop_inode) (struct inode *);
- void (*delete_inode) (struct inode *);
+ int (*write_inode) (struct inode *, struct writeback_control *wbc);
+ int (*drop_inode) (struct inode *);
+ void (*evict_inode) (struct inode *);
void (*put_super) (struct super_block *);
int (*sync_fs)(struct super_block *sb, int wait);
+ int (*freeze_super) (struct super_block *sb,
+ enum freeze_holder who);
int (*freeze_fs) (struct super_block *);
+ int (*thaw_super) (struct super_block *sb,
+ enum freeze_wholder who);
int (*unfreeze_fs) (struct super_block *);
int (*statfs) (struct dentry *, struct kstatfs *);
int (*remount_fs) (struct super_block *, int *, char *);
- void (*clear_inode) (struct inode *);
void (*umount_begin) (struct super_block *);
int (*show_options)(struct seq_file *, struct dentry *);
+ int (*show_devname)(struct seq_file *, struct dentry *);
+ int (*show_path)(struct seq_file *, struct dentry *);
+ int (*show_stats)(struct seq_file *, struct dentry *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
- int (*nr_cached_objects)(struct super_block *);
- void (*free_cached_objects)(struct super_block *, int);
+ struct dquot **(*get_dquots)(struct inode *);
+
+ long (*nr_cached_objects)(struct super_block *,
+ struct shrink_control *);
+ long (*free_cached_objects)(struct super_block *,
+ struct shrink_control *);
};
All methods are called without any locks being held, unless otherwise
@@ -269,6 +280,11 @@ or bottom half).
->alloc_inode was defined and simply undoes anything done by
->alloc_inode.
+``free_inode``
+ this method is called from RCU callback. If you use call_rcu()
+ in ->destroy_inode to free 'struct inode' memory, then it's
+ better to release memory in this method.
+
``dirty_inode``
this method is called by the VFS when an inode is marked dirty.
This is specifically for the inode itself being marked dirty,
@@ -288,16 +304,20 @@ or bottom half).
inode->i_lock spinlock held.
This method should be either NULL (normal UNIX filesystem
- semantics) or "generic_delete_inode" (for filesystems that do
+ semantics) or "inode_just_drop" (for filesystems that do
not want to cache inodes - causing "delete_inode" to always be
called regardless of the value of i_nlink)
- The "generic_delete_inode()" behavior is equivalent to the old
+ The "inode_just_drop()" behavior is equivalent to the old
practice of using "force_delete" in the put_inode() case, but
does not have the races that the "force_delete()" approach had.
-``delete_inode``
- called when the VFS wants to delete an inode
+``evict_inode``
+ called when the VFS wants to evict an inode. Caller does
+ *not* evict the pagecache or inode-associated metadata buffers;
+ the method has to use truncate_inode_pages_final() to get rid
+ of those. Caller makes sure async writeback cannot be running for
+ the inode while (or after) ->evict_inode() is called. Optional.
``put_super``
called when the VFS wishes to free the superblock
@@ -308,14 +328,25 @@ or bottom half).
superblock. The second parameter indicates whether the method
should wait until the write out has been completed. Optional.
+``freeze_super``
+ Called instead of ->freeze_fs callback if provided.
+ Main difference is that ->freeze_super is called without taking
+ down_write(&sb->s_umount). If filesystem implements it and wants
+ ->freeze_fs to be called too, then it has to call ->freeze_fs
+ explicitly from this callback. Optional.
+
``freeze_fs``
called when VFS is locking a filesystem and forcing it into a
consistent state. This method is currently used by the Logical
- Volume Manager (LVM).
+ Volume Manager (LVM) and ioctl(FIFREEZE). Optional.
+
+``thaw_super``
+ called when VFS is unlocking a filesystem and making it writable
+ again after ->freeze_super. Optional.
``unfreeze_fs``
called when VFS is unlocking a filesystem and making it writable
- again.
+ again after ->freeze_fs. Optional.
``statfs``
called when the VFS needs to get filesystem statistics.
@@ -324,22 +355,37 @@ or bottom half).
called when the filesystem is remounted. This is called with
the kernel lock held
-``clear_inode``
- called then the VFS clears the inode. Optional
-
``umount_begin``
called when the VFS is unmounting a filesystem.
``show_options``
- called by the VFS to show mount options for /proc/<pid>/mounts.
+ called by the VFS to show mount options for /proc/<pid>/mounts
+ and /proc/<pid>/mountinfo.
(see "Mount Options" section)
+``show_devname``
+ Optional. Called by the VFS to show device name for
+ /proc/<pid>/{mounts,mountinfo,mountstats}. If not provided then
+ '(struct mount).mnt_devname' will be used.
+
+``show_path``
+ Optional. Called by the VFS (for /proc/<pid>/mountinfo) to show
+ the mount root dentry path relative to the filesystem root.
+
+``show_stats``
+ Optional. Called by the VFS (for /proc/<pid>/mountstats) to show
+ filesystem-specific mount statistics.
+
``quota_read``
called by the VFS to read from filesystem quota file.
``quota_write``
called by the VFS to write to filesystem quota file.
+``get_dquots``
+ called by quota to get 'struct dquot' array for a particular inode.
+ Optional.
+
``nr_cached_objects``
called by the sb cache shrinking function for the filesystem to
return the number of freeable cached objects it contains.
@@ -368,7 +414,7 @@ field. This is a pointer to a "struct inode_operations" which describes
the methods that can be performed on individual inodes.
-struct xattr_handlers
+struct xattr_handler
---------------------
On filesystems that support extended attributes (xattrs), the s_xattr
@@ -421,32 +467,34 @@ As of kernel 2.6.22, the following members are defined:
.. code-block:: c
struct inode_operations {
- int (*create) (struct user_namespace *, struct inode *,struct dentry *, umode_t, bool);
+ int (*create) (struct mnt_idmap *, struct inode *,struct dentry *, umode_t, bool);
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
- int (*symlink) (struct user_namespace *, struct inode *,struct dentry *,const char *);
- int (*mkdir) (struct user_namespace *, struct inode *,struct dentry *,umode_t);
+ int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *);
+ struct dentry *(*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
- int (*mknod) (struct user_namespace *, struct inode *,struct dentry *,umode_t,dev_t);
- int (*rename) (struct user_namespace *, struct inode *, struct dentry *,
+ int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t);
+ int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *,
struct inode *, struct dentry *, unsigned int);
int (*readlink) (struct dentry *, char __user *,int);
const char *(*get_link) (struct dentry *, struct inode *,
struct delayed_call *);
- int (*permission) (struct user_namespace *, struct inode *, int);
- struct posix_acl * (*get_acl)(struct inode *, int, bool);
- int (*setattr) (struct user_namespace *, struct dentry *, struct iattr *);
- int (*getattr) (struct user_namespace *, const struct path *, struct kstat *, u32, unsigned int);
+ int (*permission) (struct mnt_idmap *, struct inode *, int);
+ struct posix_acl * (*get_inode_acl)(struct inode *, int, bool);
+ int (*setattr) (struct mnt_idmap *, struct dentry *, struct iattr *);
+ int (*getattr) (struct mnt_idmap *, const struct path *, struct kstat *, u32, unsigned int);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *, struct file *,
unsigned open_flag, umode_t create_mode);
- int (*tmpfile) (struct user_namespace *, struct inode *, struct dentry *, umode_t);
- int (*set_acl)(struct user_namespace *, struct inode *, struct posix_acl *, int);
- int (*fileattr_set)(struct user_namespace *mnt_userns,
- struct dentry *dentry, struct fileattr *fa);
- int (*fileattr_get)(struct dentry *dentry, struct fileattr *fa);
+ int (*tmpfile) (struct mnt_idmap *, struct inode *, struct file *, umode_t);
+ struct posix_acl * (*get_acl)(struct mnt_idmap *, struct dentry *, int);
+ int (*set_acl)(struct mnt_idmap *, struct dentry *, struct posix_acl *, int);
+ int (*fileattr_set)(struct mnt_idmap *idmap,
+ struct dentry *dentry, struct file_kattr *fa);
+ int (*fileattr_get)(struct dentry *dentry, struct file_kattr *fa);
+ struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
};
Again, all methods are called without any locks being held, unless
@@ -491,7 +539,26 @@ otherwise noted.
``mkdir``
called by the mkdir(2) system call. Only required if you want
to support creating subdirectories. You will probably need to
- call d_instantiate() just as you would in the create() method
+ call d_instantiate_new() just as you would in the create() method.
+
+ If d_instantiate_new() is not used and if the fh_to_dentry()
+ export operation is provided, or if the storage might be
+ accessible by another path (e.g. with a network filesystem)
+ then more care may be needed. Importantly d_instantate()
+ should not be used with an inode that is no longer I_NEW if there
+ any chance that the inode could already be attached to a dentry.
+ This is because of a hard rule in the VFS that a directory must
+ only ever have one dentry.
+
+ For example, if an NFS filesystem is mounted twice the new directory
+ could be visible on the other mount before it is on the original
+ mount, and a pair of name_to_handle_at(), open_by_handle_at()
+ calls could instantiate the directory inode with an IS_ROOT()
+ dentry before the first mkdir returns.
+
+ If there is any chance this could happen, then the new inode
+ should be d_drop()ed and attached with d_splice_alias(). The
+ returned dentry (if any) should be returned by ->mkdir().
``rmdir``
called by the rmdir(2) system call. Only required if you want
@@ -592,7 +659,9 @@ otherwise noted.
``tmpfile``
called in the end of O_TMPFILE open(). Optional, equivalent to
atomically creating, opening and unlinking a file in given
- directory.
+ directory. On success needs to return with the file already
+ open; this can be done by calling finish_open_simple() right at
+ the end.
``fileattr_get``
called on ioctl(FS_IOC_GETFLAGS) and ioctl(FS_IOC_FSGETXATTR) to
@@ -605,7 +674,10 @@ otherwise noted.
called on ioctl(FS_IOC_SETFLAGS) and ioctl(FS_IOC_FSSETXATTR) to
change miscellaneous file flags and attributes. Callers hold
i_rwsem exclusive. If unset, then fall back to f_op->ioctl().
-
+``get_offset_ctx``
+ called to get the offset context for a directory inode. A
+ filesystem must define this operation to use
+ simple_offset_dir_operations.
The Address Space Object
========================
@@ -621,9 +693,8 @@ page lookup by address, and keeping track of pages tagged as Dirty or
Writeback.
The first can be used independently to the others. The VM can try to
-either write dirty pages in order to clean them, or release clean pages
-in order to reuse them. To do this it can call the ->writepage method
-on dirty pages, and ->release_folio on clean folios with the private
+release clean pages in order to reuse them. To do this it can call
+->release_folio on clean folios with the private
flag set. Clean pages without PagePrivate and with no external references
will be released without notice being given to the address_space.
@@ -636,8 +707,8 @@ maintains information about the PG_Dirty and PG_Writeback status of each
page, so that pages with either of these flags can be found quickly.
The Dirty tag is primarily used by mpage_writepages - the default
-->writepages method. It uses the tag to find dirty pages to call
-->writepage on. If mpage_writepages is not used (i.e. the address
+->writepages method. It uses the tag to find dirty pages to
+write back. If mpage_writepages is not used (i.e. the address
provides its own ->writepages) , the PAGECACHE_TAG_DIRTY tag is almost
unused. write_inode_now and sync_inode do use it (through
__sync_single_inode) to check if ->writepages has been successful in
@@ -661,23 +732,24 @@ pages, however the address_space has finer control of write sizes.
The read process essentially only requires 'read_folio'. The write
process is more complicated and uses write_begin/write_end or
-dirty_folio to write data into the address_space, and writepage and
+dirty_folio to write data into the address_space, and
writepages to writeback data to storage.
-Adding and removing pages to/from an address_space is protected by the
-inode's i_mutex.
+Removing pages from an address_space requires holding the inode's i_rwsem
+exclusively, while adding pages to the address_space requires holding the
+inode's i_mapping->invalidate_lock exclusively.
When data is written to a page, the PG_Dirty flag should be set. It
-typically remains set until writepage asks for it to be written. This
+typically remains set until writepages asks for it to be written. This
should clear PG_Dirty and set PG_Writeback. It can be actually written
at any point after PG_Dirty is clear. Once it is known to be safe,
PG_Writeback is cleared.
Writeback makes use of a writeback_control structure to direct the
-operations. This gives the writepage and writepages operations some
+operations. This gives the writepages operation some
information about the nature of and reason for the writeback request,
and the constraints under which it is being done. It is also used to
-return information back to the caller about the result of a writepage or
+return information back to the caller about the result of a
writepages request.
@@ -691,7 +763,7 @@ is an error during writeback, they expect that error to be reported when
a file sync request is made. After an error has been reported on one
request, subsequent requests on the same file descriptor should return
0, unless further writeback errors have occurred since the previous file
-syncronization.
+synchronization.
Ideally, the kernel would report errors only on file descriptions on
which writes were done that subsequently failed to be written back. The
@@ -724,17 +796,16 @@ cache in your filesystem. The following members are defined:
.. code-block:: c
struct address_space_operations {
- int (*writepage)(struct page *page, struct writeback_control *wbc);
int (*read_folio)(struct file *, struct folio *);
int (*writepages)(struct address_space *, struct writeback_control *);
bool (*dirty_folio)(struct address_space *, struct folio *);
void (*readahead)(struct readahead_control *);
- int (*write_begin)(struct file *, struct address_space *mapping,
+ int (*write_begin)(const struct kiocb *, struct address_space *mapping,
loff_t pos, unsigned len,
- struct page **pagep, void **fsdata);
- int (*write_end)(struct file *, struct address_space *mapping,
+ struct page **pagep, void **fsdata);
+ int (*write_end)(const struct kiocb *, struct address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
- struct page *page, void *fsdata);
+ struct folio *folio, void *fsdata);
sector_t (*bmap)(struct address_space *, sector_t);
void (*invalidate_folio) (struct folio *, size_t start, size_t len);
bool (*release_folio)(struct folio *, gfp_t);
@@ -747,31 +818,12 @@ cache in your filesystem. The following members are defined:
bool (*is_partially_uptodate) (struct folio *, size_t from,
size_t count);
void (*is_dirty_writeback)(struct folio *, bool *, bool *);
- int (*error_remove_page) (struct mapping *mapping, struct page *page);
+ int (*error_remove_folio)(struct mapping *mapping, struct folio *);
int (*swap_activate)(struct swap_info_struct *sis, struct file *f, sector_t *span)
int (*swap_deactivate)(struct file *);
int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter);
};
-``writepage``
- called by the VM to write a dirty page to backing store. This
- may happen for data integrity reasons (i.e. 'sync'), or to free
- up memory (flush). The difference can be seen in
- wbc->sync_mode. The PG_Dirty flag has been cleared and
- PageLocked is true. writepage should start writeout, should set
- PG_Writeback, and should make sure the page is unlocked, either
- synchronously or asynchronously when the write operation
- completes.
-
- If wbc->sync_mode is WB_SYNC_NONE, ->writepage doesn't have to
- try too hard if there are problems, and may choose to write out
- other pages from the mapping if that is easier (e.g. due to
- internal dependencies). If it chooses not to start writeout, it
- should return AOP_WRITEPAGE_ACTIVATE so that the VM will not
- keep calling ->writepage on that page.
-
- See the file "Locking" for more details.
-
``read_folio``
Called by the page cache to read a folio from the backing store.
The 'file' argument supplies authentication information to network
@@ -814,7 +866,7 @@ cache in your filesystem. The following members are defined:
given and that many pages should be written if possible. If no
->writepages is given, then mpage_writepages is used instead.
This will choose pages from the address space that are tagged as
- DIRTY and will pass them to ->writepage.
+ DIRTY and will write them back.
``dirty_folio``
called by the VM to mark a folio as dirty. This is particularly
@@ -837,8 +889,7 @@ cache in your filesystem. The following members are defined:
stop attempting I/O, it can simply return. The caller will
remove the remaining pages from the address space, unlock them
and decrement the page refcount. Set PageUptodate if the I/O
- completes successfully. Setting PageError on any page will be
- ignored; simply unlock the page if an I/O error occurs.
+ completes successfully.
``write_begin``
Called by the generic buffered write code to ask the filesystem
@@ -850,12 +901,12 @@ cache in your filesystem. The following members are defined:
(if they haven't been read already) so that the updated blocks
can be written out properly.
- The filesystem must return the locked pagecache page for the
- specified offset, in ``*pagep``, for the caller to write into.
+ The filesystem must return the locked pagecache folio for the
+ specified offset, in ``*foliop``, for the caller to write into.
It must be able to cope with short writes (where the length
passed to write_begin is greater than the number of bytes copied
- into the page).
+ into the folio).
A void * may be returned in fsdata, which then gets passed into
write_end.
@@ -868,8 +919,8 @@ cache in your filesystem. The following members are defined:
called. len is the original len passed to write_begin, and
copied is the amount that was able to be copied.
- The filesystem must take care of unlocking the page and
- releasing it refcount, and updating i_size.
+ The filesystem must take care of unlocking the folio,
+ decrementing its refcount, and updating i_size.
Returns < 0 on failure, otherwise the number of bytes (<=
'copied') that were able to be copied into pagecache.
@@ -958,8 +1009,8 @@ cache in your filesystem. The following members are defined:
VM if a folio should be treated as dirty or writeback for the
purposes of stalling.
-``error_remove_page``
- normally set to generic_error_remove_page if truncation is ok
+``error_remove_folio``
+ normally set to generic_error_remove_folio if truncation is ok
for this address space. Used for memory failure handling.
Setting this implies you deal with pages going away under you,
unless you have them locked or reference counts increased.
@@ -998,13 +1049,14 @@ This describes how the VFS can manipulate an open file. As of kernel
struct file_operations {
struct module *owner;
+ fop_flags_t fop_flags;
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
- int (*iopoll)(struct kiocb *kiocb, bool spin);
- int (*iterate) (struct file *, struct dir_context *);
+ int (*iopoll)(struct kiocb *kiocb, struct io_comp_batch *,
+ unsigned int flags);
int (*iterate_shared) (struct file *, struct dir_context *);
__poll_t (*poll) (struct file *, struct poll_table_struct *);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
@@ -1016,24 +1068,29 @@ This describes how the VFS can manipulate an open file. As of kernel
int (*fsync) (struct file *, loff_t, loff_t, int datasync);
int (*fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
- ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
int (*check_flags)(int);
int (*flock) (struct file *, int, struct file_lock *);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
- int (*setlease)(struct file *, long, struct file_lock **, void **);
+ void (*splice_eof)(struct file *file);
+ int (*setlease)(struct file *, int, struct file_lease **, void **);
long (*fallocate)(struct file *file, int mode, loff_t offset,
loff_t len);
void (*show_fdinfo)(struct seq_file *m, struct file *f);
#ifndef CONFIG_MMU
unsigned (*mmap_capabilities)(struct file *);
#endif
- ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int);
+ ssize_t (*copy_file_range)(struct file *, loff_t, struct file *,
+ loff_t, size_t, unsigned int);
loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in,
struct file *file_out, loff_t pos_out,
loff_t len, unsigned int remap_flags);
int (*fadvise)(struct file *, loff_t, loff_t, int);
+ int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
+ int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
+ unsigned int poll_flags);
+ int (*mmap_prepare)(struct vm_area_desc *);
};
Again, all methods are called without any locks being held, unless
@@ -1057,12 +1114,8 @@ otherwise noted.
``iopoll``
called when aio wants to poll for completions on HIPRI iocbs
-``iterate``
- called when the VFS needs to read the directory contents
-
``iterate_shared``
- called when the VFS needs to read the directory contents when
- filesystem supports concurrent dir iterators
+ called when the VFS needs to read the directory contents
``poll``
called by the VFS when a process wants to check if there is
@@ -1077,7 +1130,8 @@ otherwise noted.
used on 64 bit kernels.
``mmap``
- called by the mmap(2) system call
+ called by the mmap(2) system call. Deprecated in favour of
+ ``mmap_prepare``.
``open``
called by the VFS when an inode should be opened. When the VFS
@@ -1154,6 +1208,15 @@ otherwise noted.
``fadvise``
possibly called by the fadvise64() system call.
+``mmap_prepare``
+ Called by the mmap(2) system call. Allows a VFS to set up a
+ file-backed memory mapping, most notably establishing relevant
+ private state and VMA callbacks.
+
+ If further action such as pre-population of page tables is required,
+ this can be specified by the vm_area_desc->action field and related
+ parameters.
+
Note that the file operations are implemented by the specific
filesystem in which the inode resides. When opening a device node
(character or block special) most filesystems will call special
@@ -1182,7 +1245,8 @@ defined:
.. code-block:: c
struct dentry_operations {
- int (*d_revalidate)(struct dentry *, unsigned int);
+ int (*d_revalidate)(struct inode *, const struct qstr *,
+ struct dentry *, unsigned int);
int (*d_weak_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, struct qstr *);
int (*d_compare)(const struct dentry *,
@@ -1194,7 +1258,9 @@ defined:
char *(*d_dname)(struct dentry *, char *, int);
struct vfsmount *(*d_automount)(struct path *);
int (*d_manage)(const struct path *, bool);
- struct dentry *(*d_real)(struct dentry *, const struct inode *);
+ struct dentry *(*d_real)(struct dentry *, enum d_real_type type);
+ bool (*d_unalias_trylock)(const struct dentry *);
+ void (*d_unalias_unlock)(const struct dentry *);
};
``d_revalidate``
@@ -1219,7 +1285,7 @@ defined:
return
-ECHILD and it will be called again in ref-walk mode.
-``_weak_revalidate``
+``d_weak_revalidate``
called when the VFS needs to revalidate a "jumped" dentry. This
is called when a path-walk ends at dentry that was not acquired
by doing a lookup in the parent directory. This includes "/",
@@ -1320,9 +1386,7 @@ defined:
If a vfsmount is returned, the caller will attempt to mount it
on the mountpoint and will remove the vfsmount from its
- expiration list in the case of failure. The vfsmount should be
- returned with 2 refs on it to prevent automatic expiration - the
- caller will clean up the additional ref.
+ expiration list in the case of failure.
This function is only used if DCACHE_NEED_AUTOMOUNT is set on
the dentry. This is set by __d_instantiate() if S_AUTOMOUNT is
@@ -1349,16 +1413,33 @@ defined:
the dentry being transited from.
``d_real``
- overlay/union type filesystems implement this method to return
- one of the underlying dentries hidden by the overlay. It is
- used in two different modes:
+ overlay/union type filesystems implement this method to return one
+ of the underlying dentries of a regular file hidden by the overlay.
+
+ The 'type' argument takes the values D_REAL_DATA or D_REAL_METADATA
+ for returning the real underlying dentry that refers to the inode
+ hosting the file's data or metadata respectively.
+
+ For non-regular files, the 'dentry' argument is returned.
+
+``d_unalias_trylock``
+ if present, will be called by d_splice_alias() before moving a
+ preexisting attached alias. Returning false prevents __d_move(),
+ making d_splice_alias() fail with -ESTALE.
+
+ Rationale: setting FS_RENAME_DOES_D_MOVE will prevent d_move()
+ and d_exchange() calls from the outside of filesystem methods;
+ however, it does not guarantee that attached dentries won't
+ be renamed or moved by d_splice_alias() finding a preexisting
+ alias for a directory inode. Normally we would not care;
+ however, something that wants to stabilize the entire path to
+ root over a blocking operation might need that. See 9p for one
+ (and hopefully only) example.
- Called from file_dentry() it returns the real dentry matching
- the inode argument. The real dentry may be from a lower layer
- already copied up, but still referenced from the file. This
- mode is selected with a non-NULL inode argument.
+``d_unalias_unlock``
+ should be paired with ``d_unalias_trylock``; that one is called after
+ __d_move() call in __d_unalias().
- With NULL inode the topmost real underlying dentry is returned.
Each dentry has a pointer to its parent dentry, as well as a hash list
of child dentries. Child dentries are basically like files in a
diff --git a/Documentation/filesystems/xfs/index.rst b/Documentation/filesystems/xfs/index.rst
new file mode 100644
index 000000000000..ab66c57a5d18
--- /dev/null
+++ b/Documentation/filesystems/xfs/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+XFS Filesystem Documentation
+============================
+
+.. toctree::
+ :maxdepth: 2
+ :numbered:
+
+ xfs-delayed-logging-design
+ xfs-maintainer-entry-profile
+ xfs-self-describing-metadata
+ xfs-online-fsck-design
diff --git a/Documentation/filesystems/xfs-delayed-logging-design.rst b/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst
index 6402ab8e370c..2a2705e975e8 100644
--- a/Documentation/filesystems/xfs-delayed-logging-design.rst
+++ b/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst
@@ -219,7 +219,7 @@ The log is circular, so the positions in the log are defined by the combination
of a cycle number - the number of times the log has been overwritten - and the
offset into the log. A LSN carries the cycle in the upper 32 bits and the
offset in the lower 32 bits. The offset is in units of "basic blocks" (512
-bytes). Hence we can do realtively simple LSN based math to keep track of
+bytes). Hence we can do relatively simple LSN based math to keep track of
available space in the log.
Log space accounting is done via a pair of constructs called "grant heads". The
diff --git a/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst
new file mode 100644
index 000000000000..ce4584fb3103
--- /dev/null
+++ b/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst
@@ -0,0 +1,194 @@
+XFS Maintainer Entry Profile
+============================
+
+Overview
+--------
+XFS is a well known high-performance filesystem in the Linux kernel.
+The aim of this project is to provide and maintain a robust and
+performant filesystem.
+
+Patches are generally merged to the for-next branch of the appropriate
+git repository.
+After a testing period, the for-next branch is merged to the master
+branch.
+
+Kernel code are merged to the xfs-linux tree[0].
+Userspace code are merged to the xfsprogs tree[1].
+Test cases are merged to the xfstests tree[2].
+Ondisk format documentation are merged to the xfs-documentation tree[3].
+
+All patchsets involving XFS *must* be cc'd in their entirety to the mailing
+list linux-xfs@vger.kernel.org.
+
+Roles
+-----
+There are eight key roles in the XFS project.
+A person can take on multiple roles, and a role can be filled by
+multiple people.
+Anyone taking on a role is advised to check in with themselves and
+others on a regular basis about burnout.
+
+- **Outside Contributor**: Anyone who sends a patch but is not involved
+ in the XFS project on a regular basis.
+ These folks are usually people who work on other filesystems or
+ elsewhere in the kernel community.
+
+- **Developer**: Someone who is familiar with the XFS codebase enough to
+ write new code, documentation, and tests.
+
+ Developers can often be found in the IRC channel mentioned by the ``C:``
+ entry in the kernel MAINTAINERS file.
+
+- **Senior Developer**: A developer who is very familiar with at least
+ some part of the XFS codebase and/or other subsystems in the kernel.
+ These people collectively decide the long term goals of the project
+ and nudge the community in that direction.
+ They should help prioritize development and review work for each release
+ cycle.
+
+ Senior developers tend to be more active participants in the IRC channel.
+
+- **Reviewer**: Someone (most likely also a developer) who reads code
+ submissions to decide:
+
+ 0. Is the idea behind the contribution sound?
+ 1. Does the idea fit the goals of the project?
+ 2. Is the contribution designed correctly?
+ 3. Is the contribution polished?
+ 4. Can the contribution be tested effectively?
+
+ Reviewers should identify themselves with an ``R:`` entry in the kernel
+ and fstests MAINTAINERS files.
+
+- **Testing Lead**: This person is responsible for setting the test
+ coverage goals of the project, negotiating with developers to decide
+ on new tests for new features, and making sure that developers and
+ release managers execute on the testing.
+
+ The testing lead should identify themselves with an ``M:`` entry in
+ the XFS section of the fstests MAINTAINERS file.
+
+- **Bug Triager**: Someone who examines incoming bug reports in just
+ enough detail to identify the person to whom the report should be
+ forwarded.
+
+ The bug triagers should identify themselves with a ``B:`` entry in
+ the kernel MAINTAINERS file.
+
+- **Release Manager**: This person merges reviewed patchsets into an
+ integration branch, tests the result locally, pushes the branch to a
+ public git repository, and sends pull requests further upstream.
+ The release manager is not expected to work on new feature patchsets.
+ If a developer and a reviewer fail to reach a resolution on some point,
+ the release manager must have the ability to intervene to try to drive a
+ resolution.
+
+ The release manager should identify themselves with an ``M:`` entry in
+ the kernel MAINTAINERS file.
+
+- **Community Manager**: This person calls and moderates meetings of as many
+ XFS participants as they can get when mailing list discussions prove
+ insufficient for collective decisionmaking.
+ They may also serve as liaison between managers of the organizations
+ sponsoring work on any part of XFS.
+
+- **LTS Maintainer**: Someone who backports and tests bug fixes from
+ upstream to the LTS kernels.
+ There tend to be six separate LTS trees at any given time.
+
+ The maintainer for a given LTS release should identify themselves with an
+ ``M:`` entry in the MAINTAINERS file for that LTS tree.
+ Unmaintained LTS kernels should be marked with status ``S: Orphan`` in that
+ same file.
+
+Submission Checklist Addendum
+-----------------------------
+Please follow these additional rules when submitting to XFS:
+
+- Patches affecting only the filesystem itself should be based against
+ the latest -rc or the for-next branch.
+ These patches will be merged back to the for-next branch.
+
+- Authors of patches touching other subsystems need to coordinate with
+ the maintainers of XFS and the relevant subsystems to decide how to
+ proceed with a merge.
+
+- Any patchset changing XFS should be cc'd in its entirety to linux-xfs.
+ Do not send partial patchsets; that makes analysis of the broader
+ context of the changes unnecessarily difficult.
+
+- Anyone making kernel changes that have corresponding changes to the
+ userspace utilities should send the userspace changes as separate
+ patchsets immediately after the kernel patchsets.
+
+- Authors of bug fix patches are expected to use fstests[2] to perform
+ an A/B test of the patch to determine that there are no regressions.
+ When possible, a new regression test case should be written for
+ fstests.
+
+- Authors of new feature patchsets must ensure that fstests will have
+ appropriate functional and input corner-case test cases for the new
+ feature.
+
+- When implementing a new feature, it is strongly suggested that the
+ developers write a design document to answer the following questions:
+
+ * **What** problem is this trying to solve?
+
+ * **Who** will benefit from this solution, and **where** will they
+ access it?
+
+ * **How** will this new feature work? This should touch on major data
+ structures and algorithms supporting the solution at a higher level
+ than code comments.
+
+ * **What** userspace interfaces are necessary to build off of the new
+ features?
+
+ * **How** will this work be tested to ensure that it solves the
+ problems laid out in the design document without causing new
+ problems?
+
+ The design document should be committed in the kernel documentation
+ directory.
+ It may be omitted if the feature is already well known to the
+ community.
+
+- Patchsets for the new tests should be submitted as separate patchsets
+ immediately after the kernel and userspace code patchsets.
+
+- Changes to the on-disk format of XFS must be described in the ondisk
+ format document[3] and submitted as a patchset after the fstests
+ patchsets.
+
+- Patchsets implementing bug fixes and further code cleanups should put
+ the bug fixes at the beginning of the series to ease backporting.
+
+Key Release Cycle Dates
+-----------------------
+Bug fixes may be sent at any time, though the release manager may decide to
+defer a patch when the next merge window is close.
+
+Code submissions targeting the next merge window should be sent between
+-rc1 and -rc6.
+This gives the community time to review the changes, to suggest other changes,
+and for the author to retest those changes.
+
+Code submissions also requiring changes to fs/iomap and targeting the
+next merge window should be sent between -rc1 and -rc4.
+This allows the broader kernel community adequate time to test the
+infrastructure changes.
+
+Review Cadence
+--------------
+In general, please wait at least one week before pinging for feedback.
+To find reviewers, either consult the MAINTAINERS file, or ask
+developers that have Reviewed-by tags for XFS changes to take a look and
+offer their opinion.
+
+References
+----------
+| [0] https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/
+| [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/
+| [2] https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
+| [3] https://git.kernel.org/pub/scm/fs/xfs/xfs-documentation.git/
diff --git a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
new file mode 100644
index 000000000000..3d9233f403db
--- /dev/null
+++ b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst
@@ -0,0 +1,5279 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _xfs_online_fsck_design:
+
+..
+ Mapping of heading styles within this document:
+ Heading 1 uses "====" above and below
+ Heading 2 uses "===="
+ Heading 3 uses "----"
+ Heading 4 uses "````"
+ Heading 5 uses "^^^^"
+ Heading 6 uses "~~~~"
+ Heading 7 uses "...."
+
+ Sections are manually numbered because apparently that's what everyone
+ does in the kernel.
+
+======================
+XFS Online Fsck Design
+======================
+
+This document captures the design of the online filesystem check feature for
+XFS.
+The purpose of this document is threefold:
+
+- To help kernel distributors understand exactly what the XFS online fsck
+ feature is, and issues about which they should be aware.
+
+- To help people reading the code to familiarize themselves with the relevant
+ concepts and design points before they start digging into the code.
+
+- To help developers maintaining the system by capturing the reasons
+ supporting higher level decision making.
+
+As the online fsck code is merged, the links in this document to topic branches
+will be replaced with links to code.
+
+This document is licensed under the terms of the GNU Public License, v2.
+The primary author is Darrick J. Wong.
+
+This design document is split into seven parts.
+Part 1 defines what fsck tools are and the motivations for writing a new one.
+Parts 2 and 3 present a high level overview of how online fsck process works
+and how it is tested to ensure correct functionality.
+Part 4 discusses the user interface and the intended usage modes of the new
+program.
+Parts 5 and 6 show off the high level components and how they fit together, and
+then present case studies of how each repair function actually works.
+Part 7 sums up what has been discussed so far and speculates about what else
+might be built atop online fsck.
+
+.. contents:: Table of Contents
+ :local:
+
+1. What is a Filesystem Check?
+==============================
+
+A Unix filesystem has four main responsibilities:
+
+- Provide a hierarchy of names through which application programs can associate
+ arbitrary blobs of data for any length of time,
+
+- Virtualize physical storage media across those names, and
+
+- Retrieve the named data blobs at any time.
+
+- Examine resource usage.
+
+Metadata directly supporting these functions (e.g. files, directories, space
+mappings) are sometimes called primary metadata.
+Secondary metadata (e.g. reverse mapping and directory parent pointers) support
+operations internal to the filesystem, such as internal consistency checking
+and reorganization.
+Summary metadata, as the name implies, condense information contained in
+primary metadata for performance reasons.
+
+The filesystem check (fsck) tool examines all the metadata in a filesystem
+to look for errors.
+In addition to looking for obvious metadata corruptions, fsck also
+cross-references different types of metadata records with each other to look
+for inconsistencies.
+People do not like losing data, so most fsck tools also contains some ability
+to correct any problems found.
+As a word of caution -- the primary goal of most Linux fsck tools is to restore
+the filesystem metadata to a consistent state, not to maximize the data
+recovered.
+That precedent will not be challenged here.
+
+Filesystems of the 20th century generally lacked any redundancy in the ondisk
+format, which means that fsck can only respond to errors by erasing files until
+errors are no longer detected.
+More recent filesystem designs contain enough redundancy in their metadata that
+it is now possible to regenerate data structures when non-catastrophic errors
+occur; this capability aids both strategies.
+
++--------------------------------------------------------------------------+
+| **Note**: |
++--------------------------------------------------------------------------+
+| System administrators avoid data loss by increasing the number of |
+| separate storage systems through the creation of backups; and they avoid |
+| downtime by increasing the redundancy of each storage system through the |
+| creation of RAID arrays. |
+| fsck tools address only the first problem. |
++--------------------------------------------------------------------------+
+
+TLDR; Show Me the Code!
+-----------------------
+
+Kernel and userspace code has been fully merged as of October 2025.
+
+Each kernel patchset adding an online repair function will use the same branch
+name across the kernel, xfsprogs, and fstests git repos.
+
+Existing Tools
+--------------
+
+The online fsck tool described here will be the third tool in the history of
+XFS (on Linux) to check and repair filesystems.
+Two programs precede it:
+
+The first program, ``xfs_check``, was created as part of the XFS debugger
+(``xfs_db``) and can only be used with unmounted filesystems.
+It walks all metadata in the filesystem looking for inconsistencies in the
+metadata, though it lacks any ability to repair what it finds.
+Due to its high memory requirements and inability to repair things, this
+program is now deprecated and will not be discussed further.
+
+The second program, ``xfs_repair``, was created to be faster and more robust
+than the first program.
+Like its predecessor, it can only be used with unmounted filesystems.
+It uses extent-based in-memory data structures to reduce memory consumption,
+and tries to schedule readahead IO appropriately to reduce I/O waiting time
+while it scans the metadata of the entire filesystem.
+The most important feature of this tool is its ability to respond to
+inconsistencies in file metadata and directory tree by erasing things as needed
+to eliminate problems.
+Space usage metadata are rebuilt from the observed file metadata.
+
+Problem Statement
+-----------------
+
+The current XFS tools leave several problems unsolved:
+
+1. **User programs** suddenly **lose access** to the filesystem when unexpected
+ shutdowns occur as a result of silent corruptions in the metadata.
+ These occur **unpredictably** and often without warning.
+
+2. **Users** experience a **total loss of service** during the recovery period
+ after an **unexpected shutdown** occurs.
+
+3. **Users** experience a **total loss of service** if the filesystem is taken
+ offline to **look for problems** proactively.
+
+4. **Data owners** cannot **check the integrity** of their stored data without
+ reading all of it.
+ This may expose them to substantial billing costs when a linear media scan
+ performed by the storage system administrator might suffice.
+
+5. **System administrators** cannot **schedule** a maintenance window to deal
+ with corruptions if they **lack the means** to assess filesystem health
+ while the filesystem is online.
+
+6. **Fleet monitoring tools** cannot **automate periodic checks** of filesystem
+ health when doing so requires **manual intervention** and downtime.
+
+7. **Users** can be tricked into **doing things they do not desire** when
+ malicious actors **exploit quirks of Unicode** to place misleading names
+ in directories.
+
+Given this definition of the problems to be solved and the actors who would
+benefit, the proposed solution is a third fsck tool that acts on a running
+filesystem.
+
+This new third program has three components: an in-kernel facility to check
+metadata, an in-kernel facility to repair metadata, and a userspace driver
+program to drive fsck activity on a live filesystem.
+``xfs_scrub`` is the name of the driver program.
+The rest of this document presents the goals and use cases of the new fsck
+tool, describes its major design points in connection to those goals, and
+discusses the similarities and differences with existing tools.
+
++--------------------------------------------------------------------------+
+| **Note**: |
++--------------------------------------------------------------------------+
+| Throughout this document, the existing offline fsck tool can also be |
+| referred to by its current name "``xfs_repair``". |
+| The userspace driver program for the new online fsck tool can be |
+| referred to as "``xfs_scrub``". |
+| The kernel portion of online fsck that validates metadata is called |
+| "online scrub", and portion of the kernel that fixes metadata is called |
+| "online repair". |
++--------------------------------------------------------------------------+
+
+The naming hierarchy is broken up into objects known as directories and files
+and the physical space is split into pieces known as allocation groups.
+Sharding enables better performance on highly parallel systems and helps to
+contain the damage when corruptions occur.
+The division of the filesystem into principal objects (allocation groups and
+inodes) means that there are ample opportunities to perform targeted checks and
+repairs on a subset of the filesystem.
+
+While this is going on, other parts continue processing IO requests.
+Even if a piece of filesystem metadata can only be regenerated by scanning the
+entire system, the scan can still be done in the background while other file
+operations continue.
+
+In summary, online fsck takes advantage of resource sharding and redundant
+metadata to enable targeted checking and repair operations while the system
+is running.
+This capability will be coupled to automatic system management so that
+autonomous self-healing of XFS maximizes service availability.
+
+2. Theory of Operation
+======================
+
+Because it is necessary for online fsck to lock and scan live metadata objects,
+online fsck consists of three separate code components.
+The first is the userspace driver program ``xfs_scrub``, which is responsible
+for identifying individual metadata items, scheduling work items for them,
+reacting to the outcomes appropriately, and reporting results to the system
+administrator.
+The second and third are in the kernel, which implements functions to check
+and repair each type of online fsck work item.
+
++------------------------------------------------------------------+
+| **Note**: |
++------------------------------------------------------------------+
+| For brevity, this document shortens the phrase "online fsck work |
+| item" to "scrub item". |
++------------------------------------------------------------------+
+
+Scrub item types are delineated in a manner consistent with the Unix design
+philosophy, which is to say that each item should handle one aspect of a
+metadata structure, and handle it well.
+
+Scope
+-----
+
+In principle, online fsck should be able to check and to repair everything that
+the offline fsck program can handle.
+However, online fsck cannot be running 100% of the time, which means that
+latent errors may creep in after a scrub completes.
+If these errors cause the next mount to fail, offline fsck is the only
+solution.
+This limitation means that maintenance of the offline fsck tool will continue.
+A second limitation of online fsck is that it must follow the same resource
+sharing and lock acquisition rules as the regular filesystem.
+This means that scrub cannot take *any* shortcuts to save time, because doing
+so could lead to concurrency problems.
+In other words, online fsck is not a complete replacement for offline fsck, and
+a complete run of online fsck may take longer than offline fsck.
+However, both of these limitations are acceptable tradeoffs to satisfy the
+different motivations of online fsck, which are to **minimize system downtime**
+and to **increase predictability of operation**.
+
+.. _scrubphases:
+
+Phases of Work
+--------------
+
+The userspace driver program ``xfs_scrub`` splits the work of checking and
+repairing an entire filesystem into seven phases.
+Each phase concentrates on checking specific types of scrub items and depends
+on the success of all previous phases.
+The seven phases are as follows:
+
+1. Collect geometry information about the mounted filesystem and computer,
+ discover the online fsck capabilities of the kernel, and open the
+ underlying storage devices.
+
+2. Check allocation group metadata, all realtime volume metadata, and all quota
+ files.
+ Each metadata structure is scheduled as a separate scrub item.
+ If corruption is found in the inode header or inode btree and ``xfs_scrub``
+ is permitted to perform repairs, then those scrub items are repaired to
+ prepare for phase 3.
+ Repairs are implemented by using the information in the scrub item to
+ resubmit the kernel scrub call with the repair flag enabled; this is
+ discussed in the next section.
+ Optimizations and all other repairs are deferred to phase 4.
+
+3. Check all metadata of every file in the filesystem.
+ Each metadata structure is also scheduled as a separate scrub item.
+ If repairs are needed and ``xfs_scrub`` is permitted to perform repairs,
+ and there were no problems detected during phase 2, then those scrub items
+ are repaired immediately.
+ Optimizations, deferred repairs, and unsuccessful repairs are deferred to
+ phase 4.
+
+4. All remaining repairs and scheduled optimizations are performed during this
+ phase, if the caller permits them.
+ Before starting repairs, the summary counters are checked and any necessary
+ repairs are performed so that subsequent repairs will not fail the resource
+ reservation step due to wildly incorrect summary counters.
+ Unsuccessful repairs are requeued as long as forward progress on repairs is
+ made somewhere in the filesystem.
+ Free space in the filesystem is trimmed at the end of phase 4 if the
+ filesystem is clean.
+
+5. By the start of this phase, all primary and secondary filesystem metadata
+ must be correct.
+ Summary counters such as the free space counts and quota resource counts
+ are checked and corrected.
+ Directory entry names and extended attribute names are checked for
+ suspicious entries such as control characters or confusing Unicode sequences
+ appearing in names.
+
+6. If the caller asks for a media scan, read all allocated and written data
+ file extents in the filesystem.
+ The ability to use hardware-assisted data file integrity checking is new
+ to online fsck; neither of the previous tools have this capability.
+ If media errors occur, they will be mapped to the owning files and reported.
+
+7. Re-check the summary counters and presents the caller with a summary of
+ space usage and file counts.
+
+This allocation of responsibilities will be :ref:`revisited <scrubcheck>`
+later in this document.
+
+Steps for Each Scrub Item
+-------------------------
+
+The kernel scrub code uses a three-step strategy for checking and repairing
+the one aspect of a metadata object represented by a scrub item:
+
+1. The scrub item of interest is checked for corruptions; opportunities for
+ optimization; and for values that are directly controlled by the system
+ administrator but look suspicious.
+ If the item is not corrupt or does not need optimization, resource are
+ released and the positive scan results are returned to userspace.
+ If the item is corrupt or could be optimized but the caller does not permit
+ this, resources are released and the negative scan results are returned to
+ userspace.
+ Otherwise, the kernel moves on to the second step.
+
+2. The repair function is called to rebuild the data structure.
+ Repair functions generally choose rebuild a structure from other metadata
+ rather than try to salvage the existing structure.
+ If the repair fails, the scan results from the first step are returned to
+ userspace.
+ Otherwise, the kernel moves on to the third step.
+
+3. In the third step, the kernel runs the same checks over the new metadata
+ item to assess the efficacy of the repairs.
+ The results of the reassessment are returned to userspace.
+
+Classification of Metadata
+--------------------------
+
+Each type of metadata object (and therefore each type of scrub item) is
+classified as follows:
+
+Primary Metadata
+````````````````
+
+Metadata structures in this category should be most familiar to filesystem
+users either because they are directly created by the user or they index
+objects created by the user
+Most filesystem objects fall into this class:
+
+- Free space and reference count information
+
+- Inode records and indexes
+
+- Storage mapping information for file data
+
+- Directories
+
+- Extended attributes
+
+- Symbolic links
+
+- Quota limits
+
+Scrub obeys the same rules as regular filesystem accesses for resource and lock
+acquisition.
+
+Primary metadata objects are the simplest for scrub to process.
+The principal filesystem object (either an allocation group or an inode) that
+owns the item being scrubbed is locked to guard against concurrent updates.
+The check function examines every record associated with the type for obvious
+errors and cross-references healthy records against other metadata to look for
+inconsistencies.
+Repairs for this class of scrub item are simple, since the repair function
+starts by holding all the resources acquired in the previous step.
+The repair function scans available metadata as needed to record all the
+observations needed to complete the structure.
+Next, it stages the observations in a new ondisk structure and commits it
+atomically to complete the repair.
+Finally, the storage from the old data structure are carefully reaped.
+
+Because ``xfs_scrub`` locks a primary object for the duration of the repair,
+this is effectively an offline repair operation performed on a subset of the
+filesystem.
+This minimizes the complexity of the repair code because it is not necessary to
+handle concurrent updates from other threads, nor is it necessary to access
+any other part of the filesystem.
+As a result, indexed structures can be rebuilt very quickly, and programs
+trying to access the damaged structure will be blocked until repairs complete.
+The only infrastructure needed by the repair code are the staging area for
+observations and a means to write new structures to disk.
+Despite these limitations, the advantage that online repair holds is clear:
+targeted work on individual shards of the filesystem avoids total loss of
+service.
+
+This mechanism is described in section 2.1 ("Off-Line Algorithm") of
+V. Srinivasan and M. J. Carey, `"Performance of On-Line Index Construction
+Algorithms" <https://minds.wisconsin.edu/bitstream/handle/1793/59524/TR1047.pdf>`_,
+*Extending Database Technology*, pp. 293-309, 1992.
+
+Most primary metadata repair functions stage their intermediate results in an
+in-memory array prior to formatting the new ondisk structure, which is very
+similar to the list-based algorithm discussed in section 2.3 ("List-Based
+Algorithms") of Srinivasan.
+However, any data structure builder that maintains a resource lock for the
+duration of the repair is *always* an offline algorithm.
+
+.. _secondary_metadata:
+
+Secondary Metadata
+``````````````````
+
+Metadata structures in this category reflect records found in primary metadata,
+but are only needed for online fsck or for reorganization of the filesystem.
+
+Secondary metadata include:
+
+- Reverse mapping information
+
+- Directory parent pointers
+
+This class of metadata is difficult for scrub to process because scrub attaches
+to the secondary object but needs to check primary metadata, which runs counter
+to the usual order of resource acquisition.
+Frequently, this means that full filesystems scans are necessary to rebuild the
+metadata.
+Check functions can be limited in scope to reduce runtime.
+Repairs, however, require a full scan of primary metadata, which can take a
+long time to complete.
+Under these conditions, ``xfs_scrub`` cannot lock resources for the entire
+duration of the repair.
+
+Instead, repair functions set up an in-memory staging structure to store
+observations.
+Depending on the requirements of the specific repair function, the staging
+index will either have the same format as the ondisk structure or a design
+specific to that repair function.
+The next step is to release all locks and start the filesystem scan.
+When the repair scanner needs to record an observation, the staging data are
+locked long enough to apply the update.
+While the filesystem scan is in progress, the repair function hooks the
+filesystem so that it can apply pending filesystem updates to the staging
+information.
+Once the scan is done, the owning object is re-locked, the live data is used to
+write a new ondisk structure, and the repairs are committed atomically.
+The hooks are disabled and the staging area is freed.
+Finally, the storage from the old data structure are carefully reaped.
+
+Introducing concurrency helps online repair avoid various locking problems, but
+comes at a high cost to code complexity.
+Live filesystem code has to be hooked so that the repair function can observe
+updates in progress.
+The staging area has to become a fully functional parallel structure so that
+updates can be merged from the hooks.
+Finally, the hook, the filesystem scan, and the inode locking model must be
+sufficiently well integrated that a hook event can decide if a given update
+should be applied to the staging structure.
+
+In theory, the scrub implementation could apply these same techniques for
+primary metadata, but doing so would make it massively more complex and less
+performant.
+Programs attempting to access the damaged structures are not blocked from
+operation, which may cause application failure or an unplanned filesystem
+shutdown.
+
+Inspiration for the secondary metadata repair strategy was drawn from section
+2.4 of Srinivasan above, and sections 2 ("NSF: Index Build Without Side-File")
+and 3.1.1 ("Duplicate Key Insert Problem") in C. Mohan, `"Algorithms for
+Creating Indexes for Very Large Tables Without Quiescing Updates"
+<https://dl.acm.org/doi/10.1145/130283.130337>`_, 1992.
+
+The sidecar index mentioned above bears some resemblance to the side file
+method mentioned in Srinivasan and Mohan.
+Their method consists of an index builder that extracts relevant record data to
+build the new structure as quickly as possible; and an auxiliary structure that
+captures all updates that would be committed to the index by other threads were
+the new index already online.
+After the index building scan finishes, the updates recorded in the side file
+are applied to the new index.
+To avoid conflicts between the index builder and other writer threads, the
+builder maintains a publicly visible cursor that tracks the progress of the
+scan through the record space.
+To avoid duplication of work between the side file and the index builder, side
+file updates are elided when the record ID for the update is greater than the
+cursor position within the record ID space.
+
+To minimize changes to the rest of the codebase, XFS online repair keeps the
+replacement index hidden until it's completely ready to go.
+In other words, there is no attempt to expose the keyspace of the new index
+while repair is running.
+The complexity of such an approach would be very high and perhaps more
+appropriate to building *new* indices.
+
+**Future Work Question**: Can the full scan and live update code used to
+facilitate a repair also be used to implement a comprehensive check?
+
+*Answer*: In theory, yes. Check would be much stronger if each scrub function
+employed these live scans to build a shadow copy of the metadata and then
+compared the shadow records to the ondisk records.
+However, doing that is a fair amount more work than what the checking functions
+do now.
+The live scans and hooks were developed much later.
+That in turn increases the runtime of those scrub functions.
+
+Summary Information
+```````````````````
+
+Metadata structures in this last category summarize the contents of primary
+metadata records.
+These are often used to speed up resource usage queries, and are many times
+smaller than the primary metadata which they represent.
+
+Examples of summary information include:
+
+- Summary counts of free space and inodes
+
+- File link counts from directories
+
+- Quota resource usage counts
+
+Check and repair require full filesystem scans, but resource and lock
+acquisition follow the same paths as regular filesystem accesses.
+
+The superblock summary counters have special requirements due to the underlying
+implementation of the incore counters, and will be treated separately.
+Check and repair of the other types of summary counters (quota resource counts
+and file link counts) employ the same filesystem scanning and hooking
+techniques as outlined above, but because the underlying data are sets of
+integer counters, the staging data need not be a fully functional mirror of the
+ondisk structure.
+
+Inspiration for quota and file link count repair strategies were drawn from
+sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View
+Maintenance") of G. Graefe, `"Concurrent Queries and Updates in Summary Views
+and Their Indexes"
+<http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011.
+
+Since quotas are non-negative integer counts of resource usage, online
+quotacheck can use the incremental view deltas described in section 2.14 to
+track pending changes to the block and inode usage counts in each transaction,
+and commit those changes to a dquot side file when the transaction commits.
+Delta tracking is necessary for dquots because the index builder scans inodes,
+whereas the data structure being rebuilt is an index of dquots.
+Link count checking combines the view deltas and commit step into one because
+it sets attributes of the objects being scanned instead of writing them to a
+separate data structure.
+Each online fsck function will be discussed as case studies later in this
+document.
+
+Risk Management
+---------------
+
+During the development of online fsck, several risk factors were identified
+that may make the feature unsuitable for certain distributors and users.
+Steps can be taken to mitigate or eliminate those risks, though at a cost to
+functionality.
+
+- **Decreased performance**: Adding metadata indices to the filesystem
+ increases the time cost of persisting changes to disk, and the reverse space
+ mapping and directory parent pointers are no exception.
+ System administrators who require the maximum performance can disable the
+ reverse mapping features at format time, though this choice dramatically
+ reduces the ability of online fsck to find inconsistencies and repair them.
+
+- **Incorrect repairs**: As with all software, there might be defects in the
+ software that result in incorrect repairs being written to the filesystem.
+ Systematic fuzz testing (detailed in the next section) is employed by the
+ authors to find bugs early, but it might not catch everything.
+ The kernel build system provides Kconfig options (``CONFIG_XFS_ONLINE_SCRUB``
+ and ``CONFIG_XFS_ONLINE_REPAIR``) to enable distributors to choose not to
+ accept this risk.
+ The xfsprogs build system has a configure option (``--enable-scrub=no``) that
+ disables building of the ``xfs_scrub`` binary, though this is not a risk
+ mitigation if the kernel functionality remains enabled.
+
+- **Inability to repair**: Sometimes, a filesystem is too badly damaged to be
+ repairable.
+ If the keyspaces of several metadata indices overlap in some manner but a
+ coherent narrative cannot be formed from records collected, then the repair
+ fails.
+ To reduce the chance that a repair will fail with a dirty transaction and
+ render the filesystem unusable, the online repair functions have been
+ designed to stage and validate all new records before committing the new
+ structure.
+
+- **Misbehavior**: Online fsck requires many privileges -- raw IO to block
+ devices, opening files by handle, ignoring Unix discretionary access control,
+ and the ability to perform administrative changes.
+ Running this automatically in the background scares people, so the systemd
+ background service is configured to run with only the privileges required.
+ Obviously, this cannot address certain problems like the kernel crashing or
+ deadlocking, but it should be sufficient to prevent the scrub process from
+ escaping and reconfiguring the system.
+ The cron job does not have this protection.
+
+- **Fuzz Kiddiez**: There are many people now who seem to think that running
+ automated fuzz testing of ondisk artifacts to find mischievous behavior and
+ spraying exploit code onto the public mailing list for instant zero-day
+ disclosure is somehow of some social benefit.
+ In the view of this author, the benefit is realized only when the fuzz
+ operators help to **fix** the flaws, but this opinion apparently is not
+ widely shared among security "researchers".
+ The XFS maintainers' continuing ability to manage these events presents an
+ ongoing risk to the stability of the development process.
+ Automated testing should front-load some of the risk while the feature is
+ considered EXPERIMENTAL.
+
+Many of these risks are inherent to software programming.
+Despite this, it is hoped that this new functionality will prove useful in
+reducing unexpected downtime.
+
+3. Testing Plan
+===============
+
+As stated before, fsck tools have three main goals:
+
+1. Detect inconsistencies in the metadata;
+
+2. Eliminate those inconsistencies; and
+
+3. Minimize further loss of data.
+
+Demonstrations of correct operation are necessary to build users' confidence
+that the software behaves within expectations.
+Unfortunately, it was not really feasible to perform regular exhaustive testing
+of every aspect of a fsck tool until the introduction of low-cost virtual
+machines with high-IOPS storage.
+With ample hardware availability in mind, the testing strategy for the online
+fsck project involves differential analysis against the existing fsck tools and
+systematic testing of every attribute of every type of metadata object.
+Testing can be split into four major categories, as discussed below.
+
+Integrated Testing with fstests
+-------------------------------
+
+The primary goal of any free software QA effort is to make testing as
+inexpensive and widespread as possible to maximize the scaling advantages of
+community.
+In other words, testing should maximize the breadth of filesystem configuration
+scenarios and hardware setups.
+This improves code quality by enabling the authors of online fsck to find and
+fix bugs early, and helps developers of new features to find integration
+issues earlier in their development effort.
+
+The Linux filesystem community shares a common QA testing suite,
+`fstests <https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/>`_, for
+functional and regression testing.
+Even before development work began on online fsck, fstests (when run on XFS)
+would run both the ``xfs_check`` and ``xfs_repair -n`` commands on the test and
+scratch filesystems between each test.
+This provides a level of assurance that the kernel and the fsck tools stay in
+alignment about what constitutes consistent metadata.
+During development of the online checking code, fstests was modified to run
+``xfs_scrub -n`` between each test to ensure that the new checking code
+produces the same results as the two existing fsck tools.
+
+To start development of online repair, fstests was modified to run
+``xfs_repair`` to rebuild the filesystem's metadata indices between tests.
+This ensures that offline repair does not crash, leave a corrupt filesystem
+after it exists, or trigger complaints from the online check.
+This also established a baseline for what can and cannot be repaired offline.
+To complete the first phase of development of online repair, fstests was
+modified to be able to run ``xfs_scrub`` in a "force rebuild" mode.
+This enables a comparison of the effectiveness of online repair as compared to
+the existing offline repair tools.
+
+General Fuzz Testing of Metadata Blocks
+---------------------------------------
+
+XFS benefits greatly from having a very robust debugging tool, ``xfs_db``.
+
+Before development of online fsck even began, a set of fstests were created
+to test the rather common fault that entire metadata blocks get corrupted.
+This required the creation of fstests library code that can create a filesystem
+containing every possible type of metadata object.
+Next, individual test cases were created to create a test filesystem, identify
+a single block of a specific type of metadata object, trash it with the
+existing ``blocktrash`` command in ``xfs_db``, and test the reaction of a
+particular metadata validation strategy.
+
+This earlier test suite enabled XFS developers to test the ability of the
+in-kernel validation functions and the ability of the offline fsck tool to
+detect and eliminate the inconsistent metadata.
+This part of the test suite was extended to cover online fsck in exactly the
+same manner.
+
+In other words, for a given fstests filesystem configuration:
+
+* For each metadata object existing on the filesystem:
+
+ * Write garbage to it
+
+ * Test the reactions of:
+
+ 1. The kernel verifiers to stop obviously bad metadata
+ 2. Offline repair (``xfs_repair``) to detect and fix
+ 3. Online repair (``xfs_scrub``) to detect and fix
+
+Targeted Fuzz Testing of Metadata Records
+-----------------------------------------
+
+The testing plan for online fsck includes extending the existing fs testing
+infrastructure to provide a much more powerful facility: targeted fuzz testing
+of every metadata field of every metadata object in the filesystem.
+``xfs_db`` can modify every field of every metadata structure in every
+block in the filesystem to simulate the effects of memory corruption and
+software bugs.
+Given that fstests already contains the ability to create a filesystem
+containing every metadata format known to the filesystem, ``xfs_db`` can be
+used to perform exhaustive fuzz testing!
+
+For a given fstests filesystem configuration:
+
+* For each metadata object existing on the filesystem...
+
+ * For each record inside that metadata object...
+
+ * For each field inside that record...
+
+ * For each conceivable type of transformation that can be applied to a bit field...
+
+ 1. Clear all bits
+ 2. Set all bits
+ 3. Toggle the most significant bit
+ 4. Toggle the middle bit
+ 5. Toggle the least significant bit
+ 6. Add a small quantity
+ 7. Subtract a small quantity
+ 8. Randomize the contents
+
+ * ...test the reactions of:
+
+ 1. The kernel verifiers to stop obviously bad metadata
+ 2. Offline checking (``xfs_repair -n``)
+ 3. Offline repair (``xfs_repair``)
+ 4. Online checking (``xfs_scrub -n``)
+ 5. Online repair (``xfs_scrub``)
+ 6. Both repair tools (``xfs_scrub`` and then ``xfs_repair`` if online repair doesn't succeed)
+
+This is quite the combinatoric explosion!
+
+Fortunately, having this much test coverage makes it easy for XFS developers to
+check the responses of XFS' fsck tools.
+Since the introduction of the fuzz testing framework, these tests have been
+used to discover incorrect repair code and missing functionality for entire
+classes of metadata objects in ``xfs_repair``.
+The enhanced testing was used to finalize the deprecation of ``xfs_check`` by
+confirming that ``xfs_repair`` could detect at least as many corruptions as
+the older tool.
+
+These tests have been very valuable for ``xfs_scrub`` in the same ways -- they
+allow the online fsck developers to compare online fsck against offline fsck,
+and they enable XFS developers to find deficiencies in the code base.
+
+Proposed patchsets include
+`fuzzing baselines
+<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuzz-baseline>`_.
+
+Stress Testing
+--------------
+
+A unique requirement to online fsck is the ability to operate on a filesystem
+concurrently with regular workloads.
+Although it is of course impossible to run ``xfs_scrub`` with *zero* observable
+impact on the running system, the online repair code should never introduce
+inconsistencies into the filesystem metadata, and regular workloads should
+never notice resource starvation.
+To verify that these conditions are being met, fstests has been enhanced in
+the following ways:
+
+* For each scrub item type, create a test to exercise checking that item type
+ while running ``fsstress``.
+* For each scrub item type, create a test to exercise repairing that item type
+ while running ``fsstress``.
+* Race ``fsstress`` and ``xfs_scrub -n`` to ensure that checking the whole
+ filesystem doesn't cause problems.
+* Race ``fsstress`` and ``xfs_scrub`` in force-rebuild mode to ensure that
+ force-repairing the whole filesystem doesn't cause problems.
+* Race ``xfs_scrub`` in check and force-repair mode against ``fsstress`` while
+ freezing and thawing the filesystem.
+* Race ``xfs_scrub`` in check and force-repair mode against ``fsstress`` while
+ remounting the filesystem read-only and read-write.
+* The same, but running ``fsx`` instead of ``fsstress``. (Not done yet?)
+
+Success is defined by the ability to run all of these tests without observing
+any unexpected filesystem shutdowns due to corrupted metadata, kernel hang
+check warnings, or any other sort of mischief.
+
+4. User Interface
+=================
+
+The primary user of online fsck is the system administrator, just like offline
+repair.
+Online fsck presents two modes of operation to administrators:
+A foreground CLI process for online fsck on demand, and a background service
+that performs autonomous checking and repair.
+
+Checking on Demand
+------------------
+
+For administrators who want the absolute freshest information about the
+metadata in a filesystem, ``xfs_scrub`` can be run as a foreground process on
+a command line.
+The program checks every piece of metadata in the filesystem while the
+administrator waits for the results to be reported, just like the existing
+``xfs_repair`` tool.
+Both tools share a ``-n`` option to perform a read-only scan, and a ``-v``
+option to increase the verbosity of the information reported.
+
+A new feature of ``xfs_scrub`` is the ``-x`` option, which employs the error
+correction capabilities of the hardware to check data file contents.
+The media scan is not enabled by default because it may dramatically increase
+program runtime and consume a lot of bandwidth on older storage hardware.
+
+The output of a foreground invocation is captured in the system log.
+
+The ``xfs_scrub_all`` program walks the list of mounted filesystems and
+initiates ``xfs_scrub`` for each of them in parallel.
+It serializes scans for any filesystems that resolve to the same top level
+kernel block device to prevent resource overconsumption.
+
+Background Service
+------------------
+
+To reduce the workload of system administrators, the ``xfs_scrub`` package
+provides a suite of `systemd <https://systemd.io/>`_ timers and services that
+run online fsck automatically on weekends by default.
+The background service configures scrub to run with as little privilege as
+possible, the lowest CPU and IO priority, and in a CPU-constrained single
+threaded mode.
+This can be tuned by the systemd administrator at any time to suit the latency
+and throughput requirements of customer workloads.
+
+The output of the background service is also captured in the system log.
+If desired, reports of failures (either due to inconsistencies or mere runtime
+errors) can be emailed automatically by setting the ``EMAIL_ADDR`` environment
+variable in the following service files:
+
+* ``xfs_scrub_fail@.service``
+* ``xfs_scrub_media_fail@.service``
+* ``xfs_scrub_all_fail.service``
+
+The decision to enable the background scan is left to the system administrator.
+This can be done by enabling either of the following services:
+
+* ``xfs_scrub_all.timer`` on systemd systems
+* ``xfs_scrub_all.cron`` on non-systemd systems
+
+This automatic weekly scan is configured out of the box to perform an
+additional media scan of all file data once per month.
+This is less foolproof than, say, storing file data block checksums, but much
+more performant if application software provides its own integrity checking,
+redundancy can be provided elsewhere above the filesystem, or the storage
+device's integrity guarantees are deemed sufficient.
+
+The systemd unit file definitions have been subjected to a security audit
+(as of systemd 249) to ensure that the xfs_scrub processes have as little
+access to the rest of the system as possible.
+This was performed via ``systemd-analyze security``, after which privileges
+were restricted to the minimum required, sandboxing was set up to the maximal
+extent possible with sandboxing and system call filtering; and access to the
+filesystem tree was restricted to the minimum needed to start the program and
+access the filesystem being scanned.
+The service definition files restrict CPU usage to 80% of one CPU core, and
+apply as nice of a priority to IO and CPU scheduling as possible.
+This measure was taken to minimize delays in the rest of the filesystem.
+No such hardening has been performed for the cron job.
+
+Health Reporting
+----------------
+
+XFS caches a summary of each filesystem's health status in memory.
+The information is updated whenever ``xfs_scrub`` is run, or whenever
+inconsistencies are detected in the filesystem metadata during regular
+operations.
+System administrators should use the ``health`` command of ``xfs_spaceman`` to
+download this information into a human-readable format.
+If problems have been observed, the administrator can schedule a reduced
+service window to run the online repair tool to correct the problem.
+Failing that, the administrator can decide to schedule a maintenance window to
+run the traditional offline repair tool to correct the problem.
+
+**Future Work Question**: Should the health reporting integrate with the new
+inotify fs error notification system?
+Would it be helpful for sysadmins to have a daemon to listen for corruption
+notifications and initiate a repair?
+
+*Answer*: These questions remain unanswered, but should be a part of the
+conversation with early adopters and potential downstream users of XFS.
+
+5. Kernel Algorithms and Data Structures
+========================================
+
+This section discusses the key algorithms and data structures of the kernel
+code that provide the ability to check and repair metadata while the system
+is running.
+The first chapters in this section reveal the pieces that provide the
+foundation for checking metadata.
+The remainder of this section presents the mechanisms through which XFS
+regenerates itself.
+
+Self Describing Metadata
+------------------------
+
+Starting with XFS version 5 in 2012, XFS updated the format of nearly every
+ondisk block header to record a magic number, a checksum, a universally
+"unique" identifier (UUID), an owner code, the ondisk address of the block,
+and a log sequence number.
+When loading a block buffer from disk, the magic number, UUID, owner, and
+ondisk address confirm that the retrieved block matches the specific owner of
+the current filesystem, and that the information contained in the block is
+supposed to be found at the ondisk address.
+The first three components enable checking tools to disregard alleged metadata
+that doesn't belong to the filesystem, and the fourth component enables the
+filesystem to detect lost writes.
+
+Whenever a file system operation modifies a block, the change is submitted
+to the log as part of a transaction.
+The log then processes these transactions marking them done once they are
+safely persisted to storage.
+The logging code maintains the checksum and the log sequence number of the last
+transactional update.
+Checksums are useful for detecting torn writes and other discrepancies that can
+be introduced between the computer and its storage devices.
+Sequence number tracking enables log recovery to avoid applying out of date
+log updates to the filesystem.
+
+These two features improve overall runtime resiliency by providing a means for
+the filesystem to detect obvious corruption when reading metadata blocks from
+disk, but these buffer verifiers cannot provide any consistency checking
+between metadata structures.
+
+For more information, please see the documentation for
+Documentation/filesystems/xfs/xfs-self-describing-metadata.rst
+
+Reverse Mapping
+---------------
+
+The original design of XFS (circa 1993) is an improvement upon 1980s Unix
+filesystem design.
+In those days, storage density was expensive, CPU time was scarce, and
+excessive seek time could kill performance.
+For performance reasons, filesystem authors were reluctant to add redundancy to
+the filesystem, even at the cost of data integrity.
+Filesystems designers in the early 21st century choose different strategies to
+increase internal redundancy -- either storing nearly identical copies of
+metadata, or more space-efficient encoding techniques.
+
+For XFS, a different redundancy strategy was chosen to modernize the design:
+a secondary space usage index that maps allocated disk extents back to their
+owners.
+By adding a new index, the filesystem retains most of its ability to scale
+well to heavily threaded workloads involving large datasets, since the primary
+file metadata (the directory tree, the file block map, and the allocation
+groups) remain unchanged.
+Like any system that improves redundancy, the reverse-mapping feature increases
+overhead costs for space mapping activities.
+However, it has two critical advantages: first, the reverse index is key to
+enabling online fsck and other requested functionality such as free space
+defragmentation, better media failure reporting, and filesystem shrinking.
+Second, the different ondisk storage format of the reverse mapping btree
+defeats device-level deduplication because the filesystem requires real
+redundancy.
+
++--------------------------------------------------------------------------+
+| **Sidebar**: |
++--------------------------------------------------------------------------+
+| A criticism of adding the secondary index is that it does nothing to |
+| improve the robustness of user data storage itself. |
+| This is a valid point, but adding a new index for file data block |
+| checksums increases write amplification by turning data overwrites into |
+| copy-writes, which age the filesystem prematurely. |
+| In keeping with thirty years of precedent, users who want file data |
+| integrity can supply as powerful a solution as they require. |
+| As for metadata, the complexity of adding a new secondary index of space |
+| usage is much less than adding volume management and storage device |
+| mirroring to XFS itself. |
+| Perfection of RAID and volume management are best left to existing |
+| layers in the kernel. |
++--------------------------------------------------------------------------+
+
+The information captured in a reverse space mapping record is as follows:
+
+.. code-block:: c
+
+ struct xfs_rmap_irec {
+ xfs_agblock_t rm_startblock; /* extent start block */
+ xfs_extlen_t rm_blockcount; /* extent length */
+ uint64_t rm_owner; /* extent owner */
+ uint64_t rm_offset; /* offset within the owner */
+ unsigned int rm_flags; /* state flags */
+ };
+
+The first two fields capture the location and size of the physical space,
+in units of filesystem blocks.
+The owner field tells scrub which metadata structure or file inode have been
+assigned this space.
+For space allocated to files, the offset field tells scrub where the space was
+mapped within the file fork.
+Finally, the flags field provides extra information about the space usage --
+is this an attribute fork extent? A file mapping btree extent? Or an
+unwritten data extent?
+
+Online filesystem checking judges the consistency of each primary metadata
+record by comparing its information against all other space indices.
+The reverse mapping index plays a key role in the consistency checking process
+because it contains a centralized alternate copy of all space allocation
+information.
+Program runtime and ease of resource acquisition are the only real limits to
+what online checking can consult.
+For example, a file data extent mapping can be checked against:
+
+* The absence of an entry in the free space information.
+* The absence of an entry in the inode index.
+* The absence of an entry in the reference count data if the file is not
+ marked as having shared extents.
+* The correspondence of an entry in the reverse mapping information.
+
+There are several observations to make about reverse mapping indices:
+
+1. Reverse mappings can provide a positive affirmation of correctness if any of
+ the above primary metadata are in doubt.
+ The checking code for most primary metadata follows a path similar to the
+ one outlined above.
+
+2. Proving the consistency of secondary metadata with the primary metadata is
+ difficult because that requires a full scan of all primary space metadata,
+ which is very time intensive.
+ For example, checking a reverse mapping record for a file extent mapping
+ btree block requires locking the file and searching the entire btree to
+ confirm the block.
+ Instead, scrub relies on rigorous cross-referencing during the primary space
+ mapping structure checks.
+
+3. Consistency scans must use non-blocking lock acquisition primitives if the
+ required locking order is not the same order used by regular filesystem
+ operations.
+ For example, if the filesystem normally takes a file ILOCK before taking
+ the AGF buffer lock but scrub wants to take a file ILOCK while holding
+ an AGF buffer lock, scrub cannot block on that second acquisition.
+ This means that forward progress during this part of a scan of the reverse
+ mapping data cannot be guaranteed if system load is heavy.
+
+In summary, reverse mappings play a key role in reconstruction of primary
+metadata.
+The details of how these records are staged, written to disk, and committed
+into the filesystem are covered in subsequent sections.
+
+Checking and Cross-Referencing
+------------------------------
+
+The first step of checking a metadata structure is to examine every record
+contained within the structure and its relationship with the rest of the
+system.
+XFS contains multiple layers of checking to try to prevent inconsistent
+metadata from wreaking havoc on the system.
+Each of these layers contributes information that helps the kernel to make
+three decisions about the health of a metadata structure:
+
+- Is a part of this structure obviously corrupt (``XFS_SCRUB_OFLAG_CORRUPT``) ?
+- Is this structure inconsistent with the rest of the system
+ (``XFS_SCRUB_OFLAG_XCORRUPT``) ?
+- Is there so much damage around the filesystem that cross-referencing is not
+ possible (``XFS_SCRUB_OFLAG_XFAIL``) ?
+- Can the structure be optimized to improve performance or reduce the size of
+ metadata (``XFS_SCRUB_OFLAG_PREEN``) ?
+- Does the structure contain data that is not inconsistent but deserves review
+ by the system administrator (``XFS_SCRUB_OFLAG_WARNING``) ?
+
+The following sections describe how the metadata scrubbing process works.
+
+Metadata Buffer Verification
+````````````````````````````
+
+The lowest layer of metadata protection in XFS are the metadata verifiers built
+into the buffer cache.
+These functions perform inexpensive internal consistency checking of the block
+itself, and answer these questions:
+
+- Does the block belong to this filesystem?
+
+- Does the block belong to the structure that asked for the read?
+ This assumes that metadata blocks only have one owner, which is always true
+ in XFS.
+
+- Is the type of data stored in the block within a reasonable range of what
+ scrub is expecting?
+
+- Does the physical location of the block match the location it was read from?
+
+- Does the block checksum match the data?
+
+The scope of the protections here are very limited -- verifiers can only
+establish that the filesystem code is reasonably free of gross corruption bugs
+and that the storage system is reasonably competent at retrieval.
+Corruption problems observed at runtime cause the generation of health reports,
+failed system calls, and in the extreme case, filesystem shutdowns if the
+corrupt metadata force the cancellation of a dirty transaction.
+
+Every online fsck scrubbing function is expected to read every ondisk metadata
+block of a structure in the course of checking the structure.
+Corruption problems observed during a check are immediately reported to
+userspace as corruption; during a cross-reference, they are reported as a
+failure to cross-reference once the full examination is complete.
+Reads satisfied by a buffer already in cache (and hence already verified)
+bypass these checks.
+
+Internal Consistency Checks
+```````````````````````````
+
+After the buffer cache, the next level of metadata protection is the internal
+record verification code built into the filesystem.
+These checks are split between the buffer verifiers, the in-filesystem users of
+the buffer cache, and the scrub code itself, depending on the amount of higher
+level context required.
+The scope of checking is still internal to the block.
+These higher level checking functions answer these questions:
+
+- Does the type of data stored in the block match what scrub is expecting?
+
+- Does the block belong to the owning structure that asked for the read?
+
+- If the block contains records, do the records fit within the block?
+
+- If the block tracks internal free space information, is it consistent with
+ the record areas?
+
+- Are the records contained inside the block free of obvious corruptions?
+
+Record checks in this category are more rigorous and more time-intensive.
+For example, block pointers and inumbers are checked to ensure that they point
+within the dynamically allocated parts of an allocation group and within
+the filesystem.
+Names are checked for invalid characters, and flags are checked for invalid
+combinations.
+Other record attributes are checked for sensible values.
+Btree records spanning an interval of the btree keyspace are checked for
+correct order and lack of mergeability (except for file fork mappings).
+For performance reasons, regular code may skip some of these checks unless
+debugging is enabled or a write is about to occur.
+Scrub functions, of course, must check all possible problems.
+
+Validation of Userspace-Controlled Record Attributes
+````````````````````````````````````````````````````
+
+Various pieces of filesystem metadata are directly controlled by userspace.
+Because of this nature, validation work cannot be more precise than checking
+that a value is within the possible range.
+These fields include:
+
+- Superblock fields controlled by mount options
+- Filesystem labels
+- File timestamps
+- File permissions
+- File size
+- File flags
+- Names present in directory entries, extended attribute keys, and filesystem
+ labels
+- Extended attribute key namespaces
+- Extended attribute values
+- File data block contents
+- Quota limits
+- Quota timer expiration (if resource usage exceeds the soft limit)
+
+Cross-Referencing Space Metadata
+````````````````````````````````
+
+After internal block checks, the next higher level of checking is
+cross-referencing records between metadata structures.
+For regular runtime code, the cost of these checks is considered to be
+prohibitively expensive, but as scrub is dedicated to rooting out
+inconsistencies, it must pursue all avenues of inquiry.
+The exact set of cross-referencing is highly dependent on the context of the
+data structure being checked.
+
+The XFS btree code has keyspace scanning functions that online fsck uses to
+cross reference one structure with another.
+Specifically, scrub can scan the key space of an index to determine if that
+keyspace is fully, sparsely, or not at all mapped to records.
+For the reverse mapping btree, it is possible to mask parts of the key for the
+purposes of performing a keyspace scan so that scrub can decide if the rmap
+btree contains records mapping a certain extent of physical space without the
+sparsenses of the rest of the rmap keyspace getting in the way.
+
+Btree blocks undergo the following checks before cross-referencing:
+
+- Does the type of data stored in the block match what scrub is expecting?
+
+- Does the block belong to the owning structure that asked for the read?
+
+- Do the records fit within the block?
+
+- Are the records contained inside the block free of obvious corruptions?
+
+- Are the name hashes in the correct order?
+
+- Do node pointers within the btree point to valid block addresses for the type
+ of btree?
+
+- Do child pointers point towards the leaves?
+
+- Do sibling pointers point across the same level?
+
+- For each node block record, does the record key accurate reflect the contents
+ of the child block?
+
+Space allocation records are cross-referenced as follows:
+
+1. Any space mentioned by any metadata structure are cross-referenced as
+ follows:
+
+ - Does the reverse mapping index list only the appropriate owner as the
+ owner of each block?
+
+ - Are none of the blocks claimed as free space?
+
+ - If these aren't file data blocks, are none of the blocks claimed as space
+ shared by different owners?
+
+2. Btree blocks are cross-referenced as follows:
+
+ - Everything in class 1 above.
+
+ - If there's a parent node block, do the keys listed for this block match the
+ keyspace of this block?
+
+ - Do the sibling pointers point to valid blocks? Of the same level?
+
+ - Do the child pointers point to valid blocks? Of the next level down?
+
+3. Free space btree records are cross-referenced as follows:
+
+ - Everything in class 1 and 2 above.
+
+ - Does the reverse mapping index list no owners of this space?
+
+ - Is this space not claimed by the inode index for inodes?
+
+ - Is it not mentioned by the reference count index?
+
+ - Is there a matching record in the other free space btree?
+
+4. Inode btree records are cross-referenced as follows:
+
+ - Everything in class 1 and 2 above.
+
+ - Is there a matching record in free inode btree?
+
+ - Do cleared bits in the holemask correspond with inode clusters?
+
+ - Do set bits in the freemask correspond with inode records with zero link
+ count?
+
+5. Inode records are cross-referenced as follows:
+
+ - Everything in class 1.
+
+ - Do all the fields that summarize information about the file forks actually
+ match those forks?
+
+ - Does each inode with zero link count correspond to a record in the free
+ inode btree?
+
+6. File fork space mapping records are cross-referenced as follows:
+
+ - Everything in class 1 and 2 above.
+
+ - Is this space not mentioned by the inode btrees?
+
+ - If this is a CoW fork mapping, does it correspond to a CoW entry in the
+ reference count btree?
+
+7. Reference count records are cross-referenced as follows:
+
+ - Everything in class 1 and 2 above.
+
+ - Within the space subkeyspace of the rmap btree (that is to say, all
+ records mapped to a particular space extent and ignoring the owner info),
+ are there the same number of reverse mapping records for each block as the
+ reference count record claims?
+
+Checking Extended Attributes
+````````````````````````````
+
+Extended attributes implement a key-value store that enable fragments of data
+to be attached to any file.
+Both the kernel and userspace can access the keys and values, subject to
+namespace and privilege restrictions.
+Most typically these fragments are metadata about the file -- origins, security
+contexts, user-supplied labels, indexing information, etc.
+
+Names can be as long as 255 bytes and can exist in several different
+namespaces.
+Values can be as large as 64KB.
+A file's extended attributes are stored in blocks mapped by the attr fork.
+The mappings point to leaf blocks, remote value blocks, or dabtree blocks.
+Block 0 in the attribute fork is always the top of the structure, but otherwise
+each of the three types of blocks can be found at any offset in the attr fork.
+Leaf blocks contain attribute key records that point to the name and the value.
+Names are always stored elsewhere in the same leaf block.
+Values that are less than 3/4 the size of a filesystem block are also stored
+elsewhere in the same leaf block.
+Remote value blocks contain values that are too large to fit inside a leaf.
+If the leaf information exceeds a single filesystem block, a dabtree (also
+rooted at block 0) is created to map hashes of the attribute names to leaf
+blocks in the attr fork.
+
+Checking an extended attribute structure is not so straightforward due to the
+lack of separation between attr blocks and index blocks.
+Scrub must read each block mapped by the attr fork and ignore the non-leaf
+blocks:
+
+1. Walk the dabtree in the attr fork (if present) to ensure that there are no
+ irregularities in the blocks or dabtree mappings that do not point to
+ attr leaf blocks.
+
+2. Walk the blocks of the attr fork looking for leaf blocks.
+ For each entry inside a leaf:
+
+ a. Validate that the name does not contain invalid characters.
+
+ b. Read the attr value.
+ This performs a named lookup of the attr name to ensure the correctness
+ of the dabtree.
+ If the value is stored in a remote block, this also validates the
+ integrity of the remote value block.
+
+Checking and Cross-Referencing Directories
+``````````````````````````````````````````
+
+The filesystem directory tree is a directed acylic graph structure, with files
+constituting the nodes, and directory entries (dirents) constituting the edges.
+Directories are a special type of file containing a set of mappings from a
+255-byte sequence (name) to an inumber.
+These are called directory entries, or dirents for short.
+Each directory file must have exactly one directory pointing to the file.
+A root directory points to itself.
+Directory entries point to files of any type.
+Each non-directory file may have multiple directories point to it.
+
+In XFS, directories are implemented as a file containing up to three 32GB
+partitions.
+The first partition contains directory entry data blocks.
+Each data block contains variable-sized records associating a user-provided
+name with an inumber and, optionally, a file type.
+If the directory entry data grows beyond one block, the second partition (which
+exists as post-EOF extents) is populated with a block containing free space
+information and an index that maps hashes of the dirent names to directory data
+blocks in the first partition.
+This makes directory name lookups very fast.
+If this second partition grows beyond one block, the third partition is
+populated with a linear array of free space information for faster
+expansions.
+If the free space has been separated and the second partition grows again
+beyond one block, then a dabtree is used to map hashes of dirent names to
+directory data blocks.
+
+Checking a directory is pretty straightforward:
+
+1. Walk the dabtree in the second partition (if present) to ensure that there
+ are no irregularities in the blocks or dabtree mappings that do not point to
+ dirent blocks.
+
+2. Walk the blocks of the first partition looking for directory entries.
+ Each dirent is checked as follows:
+
+ a. Does the name contain no invalid characters?
+
+ b. Does the inumber correspond to an actual, allocated inode?
+
+ c. Does the child inode have a nonzero link count?
+
+ d. If a file type is included in the dirent, does it match the type of the
+ inode?
+
+ e. If the child is a subdirectory, does the child's dotdot pointer point
+ back to the parent?
+
+ f. If the directory has a second partition, perform a named lookup of the
+ dirent name to ensure the correctness of the dabtree.
+
+3. Walk the free space list in the third partition (if present) to ensure that
+ the free spaces it describes are really unused.
+
+Checking operations involving :ref:`parents <dirparent>` and
+:ref:`file link counts <nlinks>` are discussed in more detail in later
+sections.
+
+Checking Directory/Attribute Btrees
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As stated in previous sections, the directory/attribute btree (dabtree) index
+maps user-provided names to improve lookup times by avoiding linear scans.
+Internally, it maps a 32-bit hash of the name to a block offset within the
+appropriate file fork.
+
+The internal structure of a dabtree closely resembles the btrees that record
+fixed-size metadata records -- each dabtree block contains a magic number, a
+checksum, sibling pointers, a UUID, a tree level, and a log sequence number.
+The format of leaf and node records are the same -- each entry points to the
+next level down in the hierarchy, with dabtree node records pointing to dabtree
+leaf blocks, and dabtree leaf records pointing to non-dabtree blocks elsewhere
+in the fork.
+
+Checking and cross-referencing the dabtree is very similar to what is done for
+space btrees:
+
+- Does the type of data stored in the block match what scrub is expecting?
+
+- Does the block belong to the owning structure that asked for the read?
+
+- Do the records fit within the block?
+
+- Are the records contained inside the block free of obvious corruptions?
+
+- Are the name hashes in the correct order?
+
+- Do node pointers within the dabtree point to valid fork offsets for dabtree
+ blocks?
+
+- Do leaf pointers within the dabtree point to valid fork offsets for directory
+ or attr leaf blocks?
+
+- Do child pointers point towards the leaves?
+
+- Do sibling pointers point across the same level?
+
+- For each dabtree node record, does the record key accurate reflect the
+ contents of the child dabtree block?
+
+- For each dabtree leaf record, does the record key accurate reflect the
+ contents of the directory or attr block?
+
+Cross-Referencing Summary Counters
+``````````````````````````````````
+
+XFS maintains three classes of summary counters: available resources, quota
+resource usage, and file link counts.
+
+In theory, the amount of available resources (data blocks, inodes, realtime
+extents) can be found by walking the entire filesystem.
+This would make for very slow reporting, so a transactional filesystem can
+maintain summaries of this information in the superblock.
+Cross-referencing these values against the filesystem metadata should be a
+simple matter of walking the free space and inode metadata in each AG and the
+realtime bitmap, but there are complications that will be discussed in
+:ref:`more detail <fscounters>` later.
+
+:ref:`Quota usage <quotacheck>` and :ref:`file link count <nlinks>`
+checking are sufficiently complicated to warrant separate sections.
+
+Post-Repair Reverification
+``````````````````````````
+
+After performing a repair, the checking code is run a second time to validate
+the new structure, and the results of the health assessment are recorded
+internally and returned to the calling process.
+This step is critical for enabling system administrator to monitor the status
+of the filesystem and the progress of any repairs.
+For developers, it is a useful means to judge the efficacy of error detection
+and correction in the online and offline checking tools.
+
+Eventual Consistency vs. Online Fsck
+------------------------------------
+
+Complex operations can make modifications to multiple per-AG data structures
+with a chain of transactions.
+These chains, once committed to the log, are restarted during log recovery if
+the system crashes while processing the chain.
+Because the AG header buffers are unlocked between transactions within a chain,
+online checking must coordinate with chained operations that are in progress to
+avoid incorrectly detecting inconsistencies due to pending chains.
+Furthermore, online repair must not run when operations are pending because
+the metadata are temporarily inconsistent with each other, and rebuilding is
+not possible.
+
+Only online fsck has this requirement of total consistency of AG metadata, and
+should be relatively rare as compared to filesystem change operations.
+Online fsck coordinates with transaction chains as follows:
+
+* For each AG, maintain a count of intent items targeting that AG.
+ The count should be bumped whenever a new item is added to the chain.
+ The count should be dropped when the filesystem has locked the AG header
+ buffers and finished the work.
+
+* When online fsck wants to examine an AG, it should lock the AG header
+ buffers to quiesce all transaction chains that want to modify that AG.
+ If the count is zero, proceed with the checking operation.
+ If it is nonzero, cycle the buffer locks to allow the chain to make forward
+ progress.
+
+This may lead to online fsck taking a long time to complete, but regular
+filesystem updates take precedence over background checking activity.
+Details about the discovery of this situation are presented in the
+:ref:`next section <chain_coordination>`, and details about the solution
+are presented :ref:`after that<intent_drains>`.
+
+.. _chain_coordination:
+
+Discovery of the Problem
+````````````````````````
+
+Midway through the development of online scrubbing, the fsstress tests
+uncovered a misinteraction between online fsck and compound transaction chains
+created by other writer threads that resulted in false reports of metadata
+inconsistency.
+The root cause of these reports is the eventual consistency model introduced by
+the expansion of deferred work items and compound transaction chains when
+reverse mapping and reflink were introduced.
+
+Originally, transaction chains were added to XFS to avoid deadlocks when
+unmapping space from files.
+Deadlock avoidance rules require that AGs only be locked in increasing order,
+which makes it impossible (say) to use a single transaction to free a space
+extent in AG 7 and then try to free a now superfluous block mapping btree block
+in AG 3.
+To avoid these kinds of deadlocks, XFS creates Extent Freeing Intent (EFI) log
+items to commit to freeing some space in one transaction while deferring the
+actual metadata updates to a fresh transaction.
+The transaction sequence looks like this:
+
+1. The first transaction contains a physical update to the file's block mapping
+ structures to remove the mapping from the btree blocks.
+ It then attaches to the in-memory transaction an action item to schedule
+ deferred freeing of space.
+ Concretely, each transaction maintains a list of ``struct
+ xfs_defer_pending`` objects, each of which maintains a list of ``struct
+ xfs_extent_free_item`` objects.
+ Returning to the example above, the action item tracks the freeing of both
+ the unmapped space from AG 7 and the block mapping btree (BMBT) block from
+ AG 3.
+ Deferred frees recorded in this manner are committed in the log by creating
+ an EFI log item from the ``struct xfs_extent_free_item`` object and
+ attaching the log item to the transaction.
+ When the log is persisted to disk, the EFI item is written into the ondisk
+ transaction record.
+ EFIs can list up to 16 extents to free, all sorted in AG order.
+
+2. The second transaction contains a physical update to the free space btrees
+ of AG 3 to release the former BMBT block and a second physical update to the
+ free space btrees of AG 7 to release the unmapped file space.
+ Observe that the physical updates are resequenced in the correct order
+ when possible.
+ Attached to the transaction is a an extent free done (EFD) log item.
+ The EFD contains a pointer to the EFI logged in transaction #1 so that log
+ recovery can tell if the EFI needs to be replayed.
+
+If the system goes down after transaction #1 is written back to the filesystem
+but before #2 is committed, a scan of the filesystem metadata would show
+inconsistent filesystem metadata because there would not appear to be any owner
+of the unmapped space.
+Happily, log recovery corrects this inconsistency for us -- when recovery finds
+an intent log item but does not find a corresponding intent done item, it will
+reconstruct the incore state of the intent item and finish it.
+In the example above, the log must replay both frees described in the recovered
+EFI to complete the recovery phase.
+
+There are subtleties to XFS' transaction chaining strategy to consider:
+
+* Log items must be added to a transaction in the correct order to prevent
+ conflicts with principal objects that are not held by the transaction.
+ In other words, all per-AG metadata updates for an unmapped block must be
+ completed before the last update to free the extent, and extents should not
+ be reallocated until that last update commits to the log.
+
+* AG header buffers are released between each transaction in a chain.
+ This means that other threads can observe an AG in an intermediate state,
+ but as long as the first subtlety is handled, this should not affect the
+ correctness of filesystem operations.
+
+* Unmounting the filesystem flushes all pending work to disk, which means that
+ offline fsck never sees the temporary inconsistencies caused by deferred
+ work item processing.
+
+In this manner, XFS employs a form of eventual consistency to avoid deadlocks
+and increase parallelism.
+
+During the design phase of the reverse mapping and reflink features, it was
+decided that it was impractical to cram all the reverse mapping updates for a
+single filesystem change into a single transaction because a single file
+mapping operation can explode into many small updates:
+
+* The block mapping update itself
+* A reverse mapping update for the block mapping update
+* Fixing the freelist
+* A reverse mapping update for the freelist fix
+
+* A shape change to the block mapping btree
+* A reverse mapping update for the btree update
+* Fixing the freelist (again)
+* A reverse mapping update for the freelist fix
+
+* An update to the reference counting information
+* A reverse mapping update for the refcount update
+* Fixing the freelist (a third time)
+* A reverse mapping update for the freelist fix
+
+* Freeing any space that was unmapped and not owned by any other file
+* Fixing the freelist (a fourth time)
+* A reverse mapping update for the freelist fix
+
+* Freeing the space used by the block mapping btree
+* Fixing the freelist (a fifth time)
+* A reverse mapping update for the freelist fix
+
+Free list fixups are not usually needed more than once per AG per transaction
+chain, but it is theoretically possible if space is very tight.
+For copy-on-write updates this is even worse, because this must be done once to
+remove the space from a staging area and again to map it into the file!
+
+To deal with this explosion in a calm manner, XFS expands its use of deferred
+work items to cover most reverse mapping updates and all refcount updates.
+This reduces the worst case size of transaction reservations by breaking the
+work into a long chain of small updates, which increases the degree of eventual
+consistency in the system.
+Again, this generally isn't a problem because XFS orders its deferred work
+items carefully to avoid resource reuse conflicts between unsuspecting threads.
+
+However, online fsck changes the rules -- remember that although physical
+updates to per-AG structures are coordinated by locking the buffers for AG
+headers, buffer locks are dropped between transactions.
+Once scrub acquires resources and takes locks for a data structure, it must do
+all the validation work without releasing the lock.
+If the main lock for a space btree is an AG header buffer lock, scrub may have
+interrupted another thread that is midway through finishing a chain.
+For example, if a thread performing a copy-on-write has completed a reverse
+mapping update but not the corresponding refcount update, the two AG btrees
+will appear inconsistent to scrub and an observation of corruption will be
+recorded. This observation will not be correct.
+If a repair is attempted in this state, the results will be catastrophic!
+
+Several other solutions to this problem were evaluated upon discovery of this
+flaw and rejected:
+
+1. Add a higher level lock to allocation groups and require writer threads to
+ acquire the higher level lock in AG order before making any changes.
+ This would be very difficult to implement in practice because it is
+ difficult to determine which locks need to be obtained, and in what order,
+ without simulating the entire operation.
+ Performing a dry run of a file operation to discover necessary locks would
+ make the filesystem very slow.
+
+2. Make the deferred work coordinator code aware of consecutive intent items
+ targeting the same AG and have it hold the AG header buffers locked across
+ the transaction roll between updates.
+ This would introduce a lot of complexity into the coordinator since it is
+ only loosely coupled with the actual deferred work items.
+ It would also fail to solve the problem because deferred work items can
+ generate new deferred subtasks, but all subtasks must be complete before
+ work can start on a new sibling task.
+
+3. Teach online fsck to walk all transactions waiting for whichever lock(s)
+ protect the data structure being scrubbed to look for pending operations.
+ The checking and repair operations must factor these pending operations into
+ the evaluations being performed.
+ This solution is a nonstarter because it is *extremely* invasive to the main
+ filesystem.
+
+.. _intent_drains:
+
+Intent Drains
+`````````````
+
+Online fsck uses an atomic intent item counter and lock cycling to coordinate
+with transaction chains.
+There are two key properties to the drain mechanism.
+First, the counter is incremented when a deferred work item is *queued* to a
+transaction, and it is decremented after the associated intent done log item is
+*committed* to another transaction.
+The second property is that deferred work can be added to a transaction without
+holding an AG header lock, but per-AG work items cannot be marked done without
+locking that AG header buffer to log the physical updates and the intent done
+log item.
+The first property enables scrub to yield to running transaction chains, which
+is an explicit deprioritization of online fsck to benefit file operations.
+The second property of the drain is key to the correct coordination of scrub,
+since scrub will always be able to decide if a conflict is possible.
+
+For regular filesystem code, the drain works as follows:
+
+1. Call the appropriate subsystem function to add a deferred work item to a
+ transaction.
+
+2. The function calls ``xfs_defer_drain_bump`` to increase the counter.
+
+3. When the deferred item manager wants to finish the deferred work item, it
+ calls ``->finish_item`` to complete it.
+
+4. The ``->finish_item`` implementation logs some changes and calls
+ ``xfs_defer_drain_drop`` to decrease the sloppy counter and wake up any threads
+ waiting on the drain.
+
+5. The subtransaction commits, which unlocks the resource associated with the
+ intent item.
+
+For scrub, the drain works as follows:
+
+1. Lock the resource(s) associated with the metadata being scrubbed.
+ For example, a scan of the refcount btree would lock the AGI and AGF header
+ buffers.
+
+2. If the counter is zero (``xfs_defer_drain_busy`` returns false), there are no
+ chains in progress and the operation may proceed.
+
+3. Otherwise, release the resources grabbed in step 1.
+
+4. Wait for the intent counter to reach zero (``xfs_defer_drain_intents``), then go
+ back to step 1 unless a signal has been caught.
+
+To avoid polling in step 4, the drain provides a waitqueue for scrub threads to
+be woken up whenever the intent count drops to zero.
+
+.. _jump_labels:
+
+Static Keys (aka Jump Label Patching)
+`````````````````````````````````````
+
+Online fsck for XFS separates the regular filesystem from the checking and
+repair code as much as possible.
+However, there are a few parts of online fsck (such as the intent drains, and
+later, live update hooks) where it is useful for the online fsck code to know
+what's going on in the rest of the filesystem.
+Since it is not expected that online fsck will be constantly running in the
+background, it is very important to minimize the runtime overhead imposed by
+these hooks when online fsck is compiled into the kernel but not actively
+running on behalf of userspace.
+Taking locks in the hot path of a writer thread to access a data structure only
+to find that no further action is necessary is expensive -- on the author's
+computer, this have an overhead of 40-50ns per access.
+Fortunately, the kernel supports dynamic code patching, which enables XFS to
+replace a static branch to hook code with ``nop`` sleds when online fsck isn't
+running.
+This sled has an overhead of however long it takes the instruction decoder to
+skip past the sled, which seems to be on the order of less than 1ns and
+does not access memory outside of instruction fetching.
+
+When online fsck enables the static key, the sled is replaced with an
+unconditional branch to call the hook code.
+The switchover is quite expensive (~22000ns) but is paid entirely by the
+program that invoked online fsck, and can be amortized if multiple threads
+enter online fsck at the same time, or if multiple filesystems are being
+checked at the same time.
+Changing the branch direction requires taking the CPU hotplug lock, and since
+CPU initialization requires memory allocation, online fsck must be careful not
+to change a static key while holding any locks or resources that could be
+accessed in the memory reclaim paths.
+To minimize contention on the CPU hotplug lock, care should be taken not to
+enable or disable static keys unnecessarily.
+
+Because static keys are intended to minimize hook overhead for regular
+filesystem operations when xfs_scrub is not running, the intended usage
+patterns are as follows:
+
+- The hooked part of XFS should declare a static-scoped static key that
+ defaults to false.
+ The ``DEFINE_STATIC_KEY_FALSE`` macro takes care of this.
+ The static key itself should be declared as a ``static`` variable.
+
+- When deciding to invoke code that's only used by scrub, the regular
+ filesystem should call the ``static_branch_unlikely`` predicate to avoid the
+ scrub-only hook code if the static key is not enabled.
+
+- The regular filesystem should export helper functions that call
+ ``static_branch_inc`` to enable and ``static_branch_dec`` to disable the
+ static key.
+ Wrapper functions make it easy to compile out the relevant code if the kernel
+ distributor turns off online fsck at build time.
+
+- Scrub functions wanting to turn on scrub-only XFS functionality should call
+ the ``xchk_fsgates_enable`` from the setup function to enable a specific
+ hook.
+ This must be done before obtaining any resources that are used by memory
+ reclaim.
+ Callers had better be sure they really need the functionality gated by the
+ static key; the ``TRY_HARDER`` flag is useful here.
+
+Online scrub has resource acquisition helpers (e.g. ``xchk_perag_lock``) to
+handle locking AGI and AGF buffers for all scrubber functions.
+If it detects a conflict between scrub and the running transactions, it will
+try to wait for intents to complete.
+If the caller of the helper has not enabled the static key, the helper will
+return -EDEADLOCK, which should result in the scrub being restarted with the
+``TRY_HARDER`` flag set.
+The scrub setup function should detect that flag, enable the static key, and
+try the scrub again.
+Scrub teardown disables all static keys obtained by ``xchk_fsgates_enable``.
+
+For more information, please see the kernel documentation of
+Documentation/staging/static-keys.rst.
+
+.. _xfile:
+
+Pageable Kernel Memory
+----------------------
+
+Some online checking functions work by scanning the filesystem to build a
+shadow copy of an ondisk metadata structure in memory and comparing the two
+copies.
+For online repair to rebuild a metadata structure, it must compute the record
+set that will be stored in the new structure before it can persist that new
+structure to disk.
+Ideally, repairs complete with a single atomic commit that introduces
+a new data structure.
+To meet these goals, the kernel needs to collect a large amount of information
+in a place that doesn't require the correct operation of the filesystem.
+
+Kernel memory isn't suitable because:
+
+* Allocating a contiguous region of memory to create a C array is very
+ difficult, especially on 32-bit systems.
+
+* Linked lists of records introduce double pointer overhead which is very high
+ and eliminate the possibility of indexed lookups.
+
+* Kernel memory is pinned, which can drive the system into OOM conditions.
+
+* The system might not have sufficient memory to stage all the information.
+
+At any given time, online fsck does not need to keep the entire record set in
+memory, which means that individual records can be paged out if necessary.
+Continued development of online fsck demonstrated that the ability to perform
+indexed data storage would also be very useful.
+Fortunately, the Linux kernel already has a facility for byte-addressable and
+pageable storage: tmpfs.
+In-kernel graphics drivers (most notably i915) take advantage of tmpfs files
+to store intermediate data that doesn't need to be in memory at all times, so
+that usage precedent is already established.
+Hence, the ``xfile`` was born!
+
++--------------------------------------------------------------------------+
+| **Historical Sidebar**: |
++--------------------------------------------------------------------------+
+| The first edition of online repair inserted records into a new btree as |
+| it found them, which failed because filesystem could shut down with a |
+| built data structure, which would be live after recovery finished. |
+| |
+| The second edition solved the half-rebuilt structure problem by storing |
+| everything in memory, but frequently ran the system out of memory. |
+| |
+| The third edition solved the OOM problem by using linked lists, but the |
+| memory overhead of the list pointers was extreme. |
++--------------------------------------------------------------------------+
+
+xfile Access Models
+```````````````````
+
+A survey of the intended uses of xfiles suggested these use cases:
+
+1. Arrays of fixed-sized records (space management btrees, directory and
+ extended attribute entries)
+
+2. Sparse arrays of fixed-sized records (quotas and link counts)
+
+3. Large binary objects (BLOBs) of variable sizes (directory and extended
+ attribute names and values)
+
+4. Staging btrees in memory (reverse mapping btrees)
+
+5. Arbitrary contents (realtime space management)
+
+To support the first four use cases, high level data structures wrap the xfile
+to share functionality between online fsck functions.
+The rest of this section discusses the interfaces that the xfile presents to
+four of those five higher level data structures.
+The fifth use case is discussed in the :ref:`realtime summary <rtsummary>` case
+study.
+
+XFS is very record-based, which suggests that the ability to load and store
+complete records is important.
+To support these cases, a pair of ``xfile_load`` and ``xfile_store``
+functions are provided to read and persist objects into an xfile that treat any
+error as an out of memory error. For online repair, squashing error conditions
+in this manner is an acceptable behavior because the only reaction is to abort
+the operation back to userspace.
+
+However, no discussion of file access idioms is complete without answering the
+question, "But what about mmap?"
+It is convenient to access storage directly with pointers, just like userspace
+code does with regular memory.
+Online fsck must not drive the system into OOM conditions, which means that
+xfiles must be responsive to memory reclamation.
+tmpfs can only push a pagecache folio to the swap cache if the folio is neither
+pinned nor locked, which means the xfile must not pin too many folios.
+
+Short term direct access to xfile contents is done by locking the pagecache
+folio and mapping it into kernel address space. Object load and store uses this
+mechanism. Folio locks are not supposed to be held for long periods of time, so
+long term direct access to xfile contents is done by bumping the folio refcount,
+mapping it into kernel address space, and dropping the folio lock.
+These long term users *must* be responsive to memory reclaim by hooking into
+the shrinker infrastructure to know when to release folios.
+
+The ``xfile_get_folio`` and ``xfile_put_folio`` functions are provided to
+retrieve the (locked) folio that backs part of an xfile and to release it.
+The only code to use these folio lease functions are the xfarray
+:ref:`sorting<xfarray_sort>` algorithms and the :ref:`in-memory
+btrees<xfbtree>`.
+
+xfile Access Coordination
+`````````````````````````
+
+For security reasons, xfiles must be owned privately by the kernel.
+They are marked ``S_PRIVATE`` to prevent interference from the security system,
+must never be mapped into process file descriptor tables, and their pages must
+never be mapped into userspace processes.
+
+To avoid locking recursion issues with the VFS, all accesses to the shmfs file
+are performed by manipulating the page cache directly.
+xfile writers call the ``->write_begin`` and ``->write_end`` functions of the
+xfile's address space to grab writable pages, copy the caller's buffer into the
+page, and release the pages.
+xfile readers call ``shmem_read_mapping_page_gfp`` to grab pages directly
+before copying the contents into the caller's buffer.
+In other words, xfiles ignore the VFS read and write code paths to avoid
+having to create a dummy ``struct kiocb`` and to avoid taking inode and
+freeze locks.
+tmpfs cannot be frozen, and xfiles must not be exposed to userspace.
+
+If an xfile is shared between threads to stage repairs, the caller must provide
+its own locks to coordinate access.
+For example, if a scrub function stores scan results in an xfile and needs
+other threads to provide updates to the scanned data, the scrub function must
+provide a lock for all threads to share.
+
+.. _xfarray:
+
+Arrays of Fixed-Sized Records
+`````````````````````````````
+
+In XFS, each type of indexed space metadata (free space, inodes, reference
+counts, file fork space, and reverse mappings) consists of a set of fixed-size
+records indexed with a classic B+ tree.
+Directories have a set of fixed-size dirent records that point to the names,
+and extended attributes have a set of fixed-size attribute keys that point to
+names and values.
+Quota counters and file link counters index records with numbers.
+During a repair, scrub needs to stage new records during the gathering step and
+retrieve them during the btree building step.
+
+Although this requirement can be satisfied by calling the read and write
+methods of the xfile directly, it is simpler for callers for there to be a
+higher level abstraction to take care of computing array offsets, to provide
+iterator functions, and to deal with sparse records and sorting.
+The ``xfarray`` abstraction presents a linear array for fixed-size records atop
+the byte-accessible xfile.
+
+.. _xfarray_access_patterns:
+
+Array Access Patterns
+^^^^^^^^^^^^^^^^^^^^^
+
+Array access patterns in online fsck tend to fall into three categories.
+Iteration of records is assumed to be necessary for all cases and will be
+covered in the next section.
+
+The first type of caller handles records that are indexed by position.
+Gaps may exist between records, and a record may be updated multiple times
+during the collection step.
+In other words, these callers want a sparse linearly addressed table file.
+The typical use case are quota records or file link count records.
+Access to array elements is performed programmatically via ``xfarray_load`` and
+``xfarray_store`` functions, which wrap the similarly-named xfile functions to
+provide loading and storing of array elements at arbitrary array indices.
+Gaps are defined to be null records, and null records are defined to be a
+sequence of all zero bytes.
+Null records are detected by calling ``xfarray_element_is_null``.
+They are created either by calling ``xfarray_unset`` to null out an existing
+record or by never storing anything to an array index.
+
+The second type of caller handles records that are not indexed by position
+and do not require multiple updates to a record.
+The typical use case here is rebuilding space btrees and key/value btrees.
+These callers can add records to the array without caring about array indices
+via the ``xfarray_append`` function, which stores a record at the end of the
+array.
+For callers that require records to be presentable in a specific order (e.g.
+rebuilding btree data), the ``xfarray_sort`` function can arrange the sorted
+records; this function will be covered later.
+
+The third type of caller is a bag, which is useful for counting records.
+The typical use case here is constructing space extent reference counts from
+reverse mapping information.
+Records can be put in the bag in any order, they can be removed from the bag
+at any time, and uniqueness of records is left to callers.
+The ``xfarray_store_anywhere`` function is used to insert a record in any
+null record slot in the bag; and the ``xfarray_unset`` function removes a
+record from the bag.
+
+Iterating Array Elements
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most users of the xfarray require the ability to iterate the records stored in
+the array.
+Callers can probe every possible array index with the following:
+
+.. code-block:: c
+
+ xfarray_idx_t i;
+ foreach_xfarray_idx(array, i) {
+ xfarray_load(array, i, &rec);
+
+ /* do something with rec */
+ }
+
+All users of this idiom must be prepared to handle null records or must already
+know that there aren't any.
+
+For xfarray users that want to iterate a sparse array, the ``xfarray_iter``
+function ignores indices in the xfarray that have never been written to by
+calling ``xfile_seek_data`` (which internally uses ``SEEK_DATA``) to skip areas
+of the array that are not populated with memory pages.
+Once it finds a page, it will skip the zeroed areas of the page.
+
+.. code-block:: c
+
+ xfarray_idx_t i = XFARRAY_CURSOR_INIT;
+ while ((ret = xfarray_iter(array, &i, &rec)) == 1) {
+ /* do something with rec */
+ }
+
+.. _xfarray_sort:
+
+Sorting Array Elements
+^^^^^^^^^^^^^^^^^^^^^^
+
+During the fourth demonstration of online repair, a community reviewer remarked
+that for performance reasons, online repair ought to load batches of records
+into btree record blocks instead of inserting records into a new btree one at a
+time.
+The btree insertion code in XFS is responsible for maintaining correct ordering
+of the records, so naturally the xfarray must also support sorting the record
+set prior to bulk loading.
+
+Case Study: Sorting xfarrays
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The sorting algorithm used in the xfarray is actually a combination of adaptive
+quicksort and a heapsort subalgorithm in the spirit of
+`Sedgewick <https://algs4.cs.princeton.edu/23quicksort/>`_ and
+`pdqsort <https://github.com/orlp/pdqsort>`_, with customizations for the Linux
+kernel.
+To sort records in a reasonably short amount of time, ``xfarray`` takes
+advantage of the binary subpartitioning offered by quicksort, but it also uses
+heapsort to hedge against performance collapse if the chosen quicksort pivots
+are poor.
+Both algorithms are (in general) O(n * lg(n)), but there is a wide performance
+gulf between the two implementations.
+
+The Linux kernel already contains a reasonably fast implementation of heapsort.
+It only operates on regular C arrays, which limits the scope of its usefulness.
+There are two key places where the xfarray uses it:
+
+* Sorting any record subset backed by a single xfile page.
+
+* Loading a small number of xfarray records from potentially disparate parts
+ of the xfarray into a memory buffer, and sorting the buffer.
+
+In other words, ``xfarray`` uses heapsort to constrain the nested recursion of
+quicksort, thereby mitigating quicksort's worst runtime behavior.
+
+Choosing a quicksort pivot is a tricky business.
+A good pivot splits the set to sort in half, leading to the divide and conquer
+behavior that is crucial to O(n * lg(n)) performance.
+A poor pivot barely splits the subset at all, leading to O(n\ :sup:`2`)
+runtime.
+The xfarray sort routine tries to avoid picking a bad pivot by sampling nine
+records into a memory buffer and using the kernel heapsort to identify the
+median of the nine.
+
+Most modern quicksort implementations employ Tukey's "ninther" to select a
+pivot from a classic C array.
+Typical ninther implementations pick three unique triads of records, sort each
+of the triads, and then sort the middle value of each triad to determine the
+ninther value.
+As stated previously, however, xfile accesses are not entirely cheap.
+It turned out to be much more performant to read the nine elements into a
+memory buffer, run the kernel's in-memory heapsort on the buffer, and choose
+the 4th element of that buffer as the pivot.
+Tukey's ninthers are described in J. W. Tukey, `The ninther, a technique for
+low-effort robust (resistant) location in large samples`, in *Contributions to
+Survey Sampling and Applied Statistics*, edited by H. David, (Academic Press,
+1978), pp. 251–257.
+
+The partitioning of quicksort is fairly textbook -- rearrange the record
+subset around the pivot, then set up the current and next stack frames to
+sort with the larger and the smaller halves of the pivot, respectively.
+This keeps the stack space requirements to log2(record count).
+
+As a final performance optimization, the hi and lo scanning phase of quicksort
+keeps examined xfile pages mapped in the kernel for as long as possible to
+reduce map/unmap cycles.
+Surprisingly, this reduces overall sort runtime by nearly half again after
+accounting for the application of heapsort directly onto xfile pages.
+
+.. _xfblob:
+
+Blob Storage
+````````````
+
+Extended attributes and directories add an additional requirement for staging
+records: arbitrary byte sequences of finite length.
+Each directory entry record needs to store entry name,
+and each extended attribute needs to store both the attribute name and value.
+The names, keys, and values can consume a large amount of memory, so the
+``xfblob`` abstraction was created to simplify management of these blobs
+atop an xfile.
+
+Blob arrays provide ``xfblob_load`` and ``xfblob_store`` functions to retrieve
+and persist objects.
+The store function returns a magic cookie for every object that it persists.
+Later, callers provide this cookie to the ``xblob_load`` to recall the object.
+The ``xfblob_free`` function frees a specific blob, and the ``xfblob_truncate``
+function frees them all because compaction is not needed.
+
+The details of repairing directories and extended attributes will be discussed
+in a subsequent section about atomic file content exchanges.
+However, it should be noted that these repair functions only use blob storage
+to cache a small number of entries before adding them to a temporary ondisk
+file, which is why compaction is not required.
+
+.. _xfbtree:
+
+In-Memory B+Trees
+`````````````````
+
+The chapter about :ref:`secondary metadata<secondary_metadata>` mentioned that
+checking and repairing of secondary metadata commonly requires coordination
+between a live metadata scan of the filesystem and writer threads that are
+updating that metadata.
+Keeping the scan data up to date requires the ability to propagate
+metadata updates from the filesystem into the data being collected by the scan.
+This *can* be done by appending concurrent updates into a separate log file and
+applying them before writing the new metadata to disk, but this leads to
+unbounded memory consumption if the rest of the system is very busy.
+Another option is to skip the side-log and commit live updates from the
+filesystem directly into the scan data, which trades more overhead for a lower
+maximum memory requirement.
+In both cases, the data structure holding the scan results must support indexed
+access to perform well.
+
+Given that indexed lookups of scan data is required for both strategies, online
+fsck employs the second strategy of committing live updates directly into
+scan data.
+Because xfarrays are not indexed and do not enforce record ordering, they
+are not suitable for this task.
+Conveniently, however, XFS has a library to create and maintain ordered reverse
+mapping records: the existing rmap btree code!
+If only there was a means to create one in memory.
+
+Recall that the :ref:`xfile <xfile>` abstraction represents memory pages as a
+regular file, which means that the kernel can create byte or block addressable
+virtual address spaces at will.
+The XFS buffer cache specializes in abstracting IO to block-oriented address
+spaces, which means that adaptation of the buffer cache to interface with
+xfiles enables reuse of the entire btree library.
+Btrees built atop an xfile are collectively known as ``xfbtrees``.
+The next few sections describe how they actually work.
+
+Using xfiles as a Buffer Cache Target
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Two modifications are necessary to support xfiles as a buffer cache target.
+The first is to make it possible for the ``struct xfs_buftarg`` structure to
+host the ``struct xfs_buf`` rhashtable, because normally those are held by a
+per-AG structure.
+The second change is to modify the buffer ``ioapply`` function to "read" cached
+pages from the xfile and "write" cached pages back to the xfile.
+Multiple access to individual buffers is controlled by the ``xfs_buf`` lock,
+since the xfile does not provide any locking on its own.
+With this adaptation in place, users of the xfile-backed buffer cache use
+exactly the same APIs as users of the disk-backed buffer cache.
+The separation between xfile and buffer cache implies higher memory usage since
+they do not share pages, but this property could some day enable transactional
+updates to an in-memory btree.
+Today, however, it simply eliminates the need for new code.
+
+Space Management with an xfbtree
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Space management for an xfile is very simple -- each btree block is one memory
+page in size.
+These blocks use the same header format as an on-disk btree, but the in-memory
+block verifiers ignore the checksums, assuming that xfile memory is no more
+corruption-prone than regular DRAM.
+Reusing existing code here is more important than absolute memory efficiency.
+
+The very first block of an xfile backing an xfbtree contains a header block.
+The header describes the owner, height, and the block number of the root
+xfbtree block.
+
+To allocate a btree block, use ``xfile_seek_data`` to find a gap in the file.
+If there are no gaps, create one by extending the length of the xfile.
+Preallocate space for the block with ``xfile_prealloc``, and hand back the
+location.
+To free an xfbtree block, use ``xfile_discard`` (which internally uses
+``FALLOC_FL_PUNCH_HOLE``) to remove the memory page from the xfile.
+
+Populating an xfbtree
+^^^^^^^^^^^^^^^^^^^^^
+
+An online fsck function that wants to create an xfbtree should proceed as
+follows:
+
+1. Call ``xfile_create`` to create an xfile.
+
+2. Call ``xfs_alloc_memory_buftarg`` to create a buffer cache target structure
+ pointing to the xfile.
+
+3. Pass the buffer cache target, buffer ops, and other information to
+ ``xfbtree_init`` to initialize the passed in ``struct xfbtree`` and write an
+ initial root block to the xfile.
+ Each btree type should define a wrapper that passes necessary arguments to
+ the creation function.
+ For example, rmap btrees define ``xfs_rmapbt_mem_create`` to take care of
+ all the necessary details for callers.
+
+4. Pass the xfbtree object to the btree cursor creation function for the
+ btree type.
+ Following the example above, ``xfs_rmapbt_mem_cursor`` takes care of this
+ for callers.
+
+5. Pass the btree cursor to the regular btree functions to make queries against
+ and to update the in-memory btree.
+ For example, a btree cursor for an rmap xfbtree can be passed to the
+ ``xfs_rmap_*`` functions just like any other btree cursor.
+ See the :ref:`next section<xfbtree_commit>` for information on dealing with
+ xfbtree updates that are logged to a transaction.
+
+6. When finished, delete the btree cursor, destroy the xfbtree object, free the
+ buffer target, and the destroy the xfile to release all resources.
+
+.. _xfbtree_commit:
+
+Committing Logged xfbtree Buffers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Although it is a clever hack to reuse the rmap btree code to handle the staging
+structure, the ephemeral nature of the in-memory btree block storage presents
+some challenges of its own.
+The XFS transaction manager must not commit buffer log items for buffers backed
+by an xfile because the log format does not understand updates for devices
+other than the data device.
+An ephemeral xfbtree probably will not exist by the time the AIL checkpoints
+log transactions back into the filesystem, and certainly won't exist during
+log recovery.
+For these reasons, any code updating an xfbtree in transaction context must
+remove the buffer log items from the transaction and write the updates into the
+backing xfile before committing or cancelling the transaction.
+
+The ``xfbtree_trans_commit`` and ``xfbtree_trans_cancel`` functions implement
+this functionality as follows:
+
+1. Find each buffer log item whose buffer targets the xfile.
+
+2. Record the dirty/ordered status of the log item.
+
+3. Detach the log item from the buffer.
+
+4. Queue the buffer to a special delwri list.
+
+5. Clear the transaction dirty flag if the only dirty log items were the ones
+ that were detached in step 3.
+
+6. Submit the delwri list to commit the changes to the xfile, if the updates
+ are being committed.
+
+After removing xfile logged buffers from the transaction in this manner, the
+transaction can be committed or cancelled.
+
+Bulk Loading of Ondisk B+Trees
+------------------------------
+
+As mentioned previously, early iterations of online repair built new btree
+structures by creating a new btree and adding observations individually.
+Loading a btree one record at a time had a slight advantage of not requiring
+the incore records to be sorted prior to commit, but was very slow and leaked
+blocks if the system went down during a repair.
+Loading records one at a time also meant that repair could not control the
+loading factor of the blocks in the new btree.
+
+Fortunately, the venerable ``xfs_repair`` tool had a more efficient means for
+rebuilding a btree index from a collection of records -- bulk btree loading.
+This was implemented rather inefficiently code-wise, since ``xfs_repair``
+had separate copy-pasted implementations for each btree type.
+
+To prepare for online fsck, each of the four bulk loaders were studied, notes
+were taken, and the four were refactored into a single generic btree bulk
+loading mechanism.
+Those notes in turn have been refreshed and are presented below.
+
+Geometry Computation
+````````````````````
+
+The zeroth step of bulk loading is to assemble the entire record set that will
+be stored in the new btree, and sort the records.
+Next, call ``xfs_btree_bload_compute_geometry`` to compute the shape of the
+btree from the record set, the type of btree, and any load factor preferences.
+This information is required for resource reservation.
+
+First, the geometry computation computes the minimum and maximum records that
+will fit in a leaf block from the size of a btree block and the size of the
+block header.
+Roughly speaking, the maximum number of records is::
+
+ maxrecs = (block_size - header_size) / record_size
+
+The XFS design specifies that btree blocks should be merged when possible,
+which means the minimum number of records is half of maxrecs::
+
+ minrecs = maxrecs / 2
+
+The next variable to determine is the desired loading factor.
+This must be at least minrecs and no more than maxrecs.
+Choosing minrecs is undesirable because it wastes half the block.
+Choosing maxrecs is also undesirable because adding a single record to each
+newly rebuilt leaf block will cause a tree split, which causes a noticeable
+drop in performance immediately afterwards.
+The default loading factor was chosen to be 75% of maxrecs, which provides a
+reasonably compact structure without any immediate split penalties::
+
+ default_load_factor = (maxrecs + minrecs) / 2
+
+If space is tight, the loading factor will be set to maxrecs to try to avoid
+running out of space::
+
+ leaf_load_factor = enough space ? default_load_factor : maxrecs
+
+Load factor is computed for btree node blocks using the combined size of the
+btree key and pointer as the record size::
+
+ maxrecs = (block_size - header_size) / (key_size + ptr_size)
+ minrecs = maxrecs / 2
+ node_load_factor = enough space ? default_load_factor : maxrecs
+
+Once that's done, the number of leaf blocks required to store the record set
+can be computed as::
+
+ leaf_blocks = ceil(record_count / leaf_load_factor)
+
+The number of node blocks needed to point to the next level down in the tree
+is computed as::
+
+ n_blocks = (n == 0 ? leaf_blocks : node_blocks[n])
+ node_blocks[n + 1] = ceil(n_blocks / node_load_factor)
+
+The entire computation is performed recursively until the current level only
+needs one block.
+The resulting geometry is as follows:
+
+- For AG-rooted btrees, this level is the root level, so the height of the new
+ tree is ``level + 1`` and the space needed is the summation of the number of
+ blocks on each level.
+
+- For inode-rooted btrees where the records in the top level do not fit in the
+ inode fork area, the height is ``level + 2``, the space needed is the
+ summation of the number of blocks on each level, and the inode fork points to
+ the root block.
+
+- For inode-rooted btrees where the records in the top level can be stored in
+ the inode fork area, then the root block can be stored in the inode, the
+ height is ``level + 1``, and the space needed is one less than the summation
+ of the number of blocks on each level.
+ This only becomes relevant when non-bmap btrees gain the ability to root in
+ an inode, which is a future patchset and only included here for completeness.
+
+.. _newbt:
+
+Reserving New B+Tree Blocks
+```````````````````````````
+
+Once repair knows the number of blocks needed for the new btree, it allocates
+those blocks using the free space information.
+Each reserved extent is tracked separately by the btree builder state data.
+To improve crash resilience, the reservation code also logs an Extent Freeing
+Intent (EFI) item in the same transaction as each space allocation and attaches
+its in-memory ``struct xfs_extent_free_item`` object to the space reservation.
+If the system goes down, log recovery will use the unfinished EFIs to free the
+unused space, the free space, leaving the filesystem unchanged.
+
+Each time the btree builder claims a block for the btree from a reserved
+extent, it updates the in-memory reservation to reflect the claimed space.
+Block reservation tries to allocate as much contiguous space as possible to
+reduce the number of EFIs in play.
+
+While repair is writing these new btree blocks, the EFIs created for the space
+reservations pin the tail of the ondisk log.
+It's possible that other parts of the system will remain busy and push the head
+of the log towards the pinned tail.
+To avoid livelocking the filesystem, the EFIs must not pin the tail of the log
+for too long.
+To alleviate this problem, the dynamic relogging capability of the deferred ops
+mechanism is reused here to commit a transaction at the log head containing an
+EFD for the old EFI and new EFI at the head.
+This enables the log to release the old EFI to keep the log moving forwards.
+
+EFIs have a role to play during the commit and reaping phases; please see the
+next section and the section about :ref:`reaping<reaping>` for more details.
+
+Writing the New Tree
+````````````````````
+
+This part is pretty simple -- the btree builder (``xfs_btree_bulkload``) claims
+a block from the reserved list, writes the new btree block header, fills the
+rest of the block with records, and adds the new leaf block to a list of
+written blocks::
+
+ ┌────┐
+ │leaf│
+ │RRR │
+ └────┘
+
+Sibling pointers are set every time a new block is added to the level::
+
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │leaf│→│leaf│→│leaf│→│leaf│
+ │RRR │←│RRR │←│RRR │←│RRR │
+ └────┘ └────┘ └────┘ └────┘
+
+When it finishes writing the record leaf blocks, it moves on to the node
+blocks
+To fill a node block, it walks each block in the next level down in the tree
+to compute the relevant keys and write them into the parent node::
+
+ ┌────┐ ┌────┐
+ │node│──────→│node│
+ │PP │←──────│PP │
+ └────┘ └────┘
+ ↙ ↘ ↙ ↘
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │leaf│→│leaf│→│leaf│→│leaf│
+ │RRR │←│RRR │←│RRR │←│RRR │
+ └────┘ └────┘ └────┘ └────┘
+
+When it reaches the root level, it is ready to commit the new btree!::
+
+ ┌─────────┐
+ │ root │
+ │ PP │
+ └─────────┘
+ ↙ ↘
+ ┌────┐ ┌────┐
+ │node│──────→│node│
+ │PP │←──────│PP │
+ └────┘ └────┘
+ ↙ ↘ ↙ ↘
+ ┌────┐ ┌────┐ ┌────┐ ┌────┐
+ │leaf│→│leaf│→│leaf│→│leaf│
+ │RRR │←│RRR │←│RRR │←│RRR │
+ └────┘ └────┘ └────┘ └────┘
+
+The first step to commit the new btree is to persist the btree blocks to disk
+synchronously.
+This is a little complicated because a new btree block could have been freed
+in the recent past, so the builder must use ``xfs_buf_delwri_queue_here`` to
+remove the (stale) buffer from the AIL list before it can write the new blocks
+to disk.
+Blocks are queued for IO using a delwri list and written in one large batch
+with ``xfs_buf_delwri_submit``.
+
+Once the new blocks have been persisted to disk, control returns to the
+individual repair function that called the bulk loader.
+The repair function must log the location of the new root in a transaction,
+clean up the space reservations that were made for the new btree, and reap the
+old metadata blocks:
+
+1. Commit the location of the new btree root.
+
+2. For each incore reservation:
+
+ a. Log Extent Freeing Done (EFD) items for all the space that was consumed
+ by the btree builder. The new EFDs must point to the EFIs attached to
+ the reservation to prevent log recovery from freeing the new blocks.
+
+ b. For unclaimed portions of incore reservations, create a regular deferred
+ extent free work item to be free the unused space later in the
+ transaction chain.
+
+ c. The EFDs and EFIs logged in steps 2a and 2b must not overrun the
+ reservation of the committing transaction.
+ If the btree loading code suspects this might be about to happen, it must
+ call ``xrep_defer_finish`` to clear out the deferred work and obtain a
+ fresh transaction.
+
+3. Clear out the deferred work a second time to finish the commit and clean
+ the repair transaction.
+
+The transaction rolling in steps 2c and 3 represent a weakness in the repair
+algorithm, because a log flush and a crash before the end of the reap step can
+result in space leaking.
+Online repair functions minimize the chances of this occurring by using very
+large transactions, which each can accommodate many thousands of block freeing
+instructions.
+Repair moves on to reaping the old blocks, which will be presented in a
+subsequent :ref:`section<reaping>` after a few case studies of bulk loading.
+
+Case Study: Rebuilding the Inode Index
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The high level process to rebuild the inode index btree is:
+
+1. Walk the reverse mapping records to generate ``struct xfs_inobt_rec``
+ records from the inode chunk information and a bitmap of the old inode btree
+ blocks.
+
+2. Append the records to an xfarray in inode order.
+
+3. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number
+ of blocks needed for the inode btree.
+ If the free space inode btree is enabled, call it again to estimate the
+ geometry of the finobt.
+
+4. Allocate the number of blocks computed in the previous step.
+
+5. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and
+ generate the internal node blocks.
+ If the free space inode btree is enabled, call it again to load the finobt.
+
+6. Commit the location of the new btree root block(s) to the AGI.
+
+7. Reap the old btree blocks using the bitmap created in step 1.
+
+Details are as follows.
+
+The inode btree maps inumbers to the ondisk location of the associated
+inode records, which means that the inode btrees can be rebuilt from the
+reverse mapping information.
+Reverse mapping records with an owner of ``XFS_RMAP_OWN_INOBT`` marks the
+location of the old inode btree blocks.
+Each reverse mapping record with an owner of ``XFS_RMAP_OWN_INODES`` marks the
+location of at least one inode cluster buffer.
+A cluster is the smallest number of ondisk inodes that can be allocated or
+freed in a single transaction; it is never smaller than 1 fs block or 4 inodes.
+
+For the space represented by each inode cluster, ensure that there are no
+records in the free space btrees nor any records in the reference count btree.
+If there are, the space metadata inconsistencies are reason enough to abort the
+operation.
+Otherwise, read each cluster buffer to check that its contents appear to be
+ondisk inodes and to decide if the file is allocated
+(``xfs_dinode.i_mode != 0``) or free (``xfs_dinode.i_mode == 0``).
+Accumulate the results of successive inode cluster buffer reads until there is
+enough information to fill a single inode chunk record, which is 64 consecutive
+numbers in the inumber keyspace.
+If the chunk is sparse, the chunk record may include holes.
+
+Once the repair function accumulates one chunk's worth of data, it calls
+``xfarray_append`` to add the inode btree record to the xfarray.
+This xfarray is walked twice during the btree creation step -- once to populate
+the inode btree with all inode chunk records, and a second time to populate the
+free inode btree with records for chunks that have free non-sparse inodes.
+The number of records for the inode btree is the number of xfarray records,
+but the record count for the free inode btree has to be computed as inode chunk
+records are stored in the xfarray.
+
+Case Study: Rebuilding the Space Reference Counts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Reverse mapping records are used to rebuild the reference count information.
+Reference counts are required for correct operation of copy on write for shared
+file data.
+Imagine the reverse mapping entries as rectangles representing extents of
+physical blocks, and that the rectangles can be laid down to allow them to
+overlap each other.
+From the diagram below, it is apparent that a reference count record must start
+or end wherever the height of the stack changes.
+In other words, the record emission stimulus is level-triggered::
+
+ █ ███
+ ██ █████ ████ ███ ██████
+ ██ ████ ███████████ ████ █████████
+ ████████████████████████████████ ███████████
+ ^ ^ ^^ ^^ ^ ^^ ^^^ ^^^^ ^ ^^ ^ ^ ^
+ 2 1 23 21 3 43 234 2123 1 01 2 3 0
+
+The ondisk reference count btree does not store the refcount == 0 cases because
+the free space btree already records which blocks are free.
+Extents being used to stage copy-on-write operations should be the only records
+with refcount == 1.
+Single-owner file blocks aren't recorded in either the free space or the
+reference count btrees.
+
+The high level process to rebuild the reference count btree is:
+
+1. Walk the reverse mapping records to generate ``struct xfs_refcount_irec``
+ records for any space having more than one reverse mapping and add them to
+ the xfarray.
+ Any records owned by ``XFS_RMAP_OWN_COW`` are also added to the xfarray
+ because these are extents allocated to stage a copy on write operation and
+ are tracked in the refcount btree.
+
+ Use any records owned by ``XFS_RMAP_OWN_REFC`` to create a bitmap of old
+ refcount btree blocks.
+
+2. Sort the records in physical extent order, putting the CoW staging extents
+ at the end of the xfarray.
+ This matches the sorting order of records in the refcount btree.
+
+3. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number
+ of blocks needed for the new tree.
+
+4. Allocate the number of blocks computed in the previous step.
+
+5. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and
+ generate the internal node blocks.
+
+6. Commit the location of new btree root block to the AGF.
+
+7. Reap the old btree blocks using the bitmap created in step 1.
+
+Details are as follows; the same algorithm is used by ``xfs_repair`` to
+generate refcount information from reverse mapping records.
+
+- Until the reverse mapping btree runs out of records:
+
+ - Retrieve the next record from the btree and put it in a bag.
+
+ - Collect all records with the same starting block from the btree and put
+ them in the bag.
+
+ - While the bag isn't empty:
+
+ - Among the mappings in the bag, compute the lowest block number where the
+ reference count changes.
+ This position will be either the starting block number of the next
+ unprocessed reverse mapping or the next block after the shortest mapping
+ in the bag.
+
+ - Remove all mappings from the bag that end at this position.
+
+ - Collect all reverse mappings that start at this position from the btree
+ and put them in the bag.
+
+ - If the size of the bag changed and is greater than one, create a new
+ refcount record associating the block number range that we just walked to
+ the size of the bag.
+
+The bag-like structure in this case is a type 2 xfarray as discussed in the
+:ref:`xfarray access patterns<xfarray_access_patterns>` section.
+Reverse mappings are added to the bag using ``xfarray_store_anywhere`` and
+removed via ``xfarray_unset``.
+Bag members are examined through ``xfarray_iter`` loops.
+
+Case Study: Rebuilding File Fork Mapping Indices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The high level process to rebuild a data/attr fork mapping btree is:
+
+1. Walk the reverse mapping records to generate ``struct xfs_bmbt_rec``
+ records from the reverse mapping records for that inode and fork.
+ Append these records to an xfarray.
+ Compute the bitmap of the old bmap btree blocks from the ``BMBT_BLOCK``
+ records.
+
+2. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number
+ of blocks needed for the new tree.
+
+3. Sort the records in file offset order.
+
+4. If the extent records would fit in the inode fork immediate area, commit the
+ records to that immediate area and skip to step 8.
+
+5. Allocate the number of blocks computed in the previous step.
+
+6. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and
+ generate the internal node blocks.
+
+7. Commit the new btree root block to the inode fork immediate area.
+
+8. Reap the old btree blocks using the bitmap created in step 1.
+
+There are some complications here:
+First, it's possible to move the fork offset to adjust the sizes of the
+immediate areas if the data and attr forks are not both in BMBT format.
+Second, if there are sufficiently few fork mappings, it may be possible to use
+EXTENTS format instead of BMBT, which may require a conversion.
+Third, the incore extent map must be reloaded carefully to avoid disturbing
+any delayed allocation extents.
+
+.. _reaping:
+
+Reaping Old Metadata Blocks
+---------------------------
+
+Whenever online fsck builds a new data structure to replace one that is
+suspect, there is a question of how to find and dispose of the blocks that
+belonged to the old structure.
+The laziest method of course is not to deal with them at all, but this slowly
+leads to service degradations as space leaks out of the filesystem.
+Hopefully, someone will schedule a rebuild of the free space information to
+plug all those leaks.
+Offline repair rebuilds all space metadata after recording the usage of
+the files and directories that it decides not to clear, hence it can build new
+structures in the discovered free space and avoid the question of reaping.
+
+As part of a repair, online fsck relies heavily on the reverse mapping records
+to find space that is owned by the corresponding rmap owner yet truly free.
+Cross referencing rmap records with other rmap records is necessary because
+there may be other data structures that also think they own some of those
+blocks (e.g. crosslinked trees).
+Permitting the block allocator to hand them out again will not push the system
+towards consistency.
+
+For space metadata, the process of finding extents to dispose of generally
+follows this format:
+
+1. Create a bitmap of space used by data structures that must be preserved.
+ The space reservations used to create the new metadata can be used here if
+ the same rmap owner code is used to denote all of the objects being rebuilt.
+
+2. Survey the reverse mapping data to create a bitmap of space owned by the
+ same ``XFS_RMAP_OWN_*`` number for the metadata that is being preserved.
+
+3. Use the bitmap disunion operator to subtract (1) from (2).
+ The remaining set bits represent candidate extents that could be freed.
+ The process moves on to step 4 below.
+
+Repairs for file-based metadata such as extended attributes, directories,
+symbolic links, quota files and realtime bitmaps are performed by building a
+new structure attached to a temporary file and exchanging all mappings in the
+file forks.
+Afterward, the mappings in the old file fork are the candidate blocks for
+disposal.
+
+The process for disposing of old extents is as follows:
+
+4. For each candidate extent, count the number of reverse mapping records for
+ the first block in that extent that do not have the same rmap owner for the
+ data structure being repaired.
+
+ - If zero, the block has a single owner and can be freed.
+
+ - If not, the block is part of a crosslinked structure and must not be
+ freed.
+
+5. Starting with the next block in the extent, figure out how many more blocks
+ have the same zero/nonzero other owner status as that first block.
+
+6. If the region is crosslinked, delete the reverse mapping entry for the
+ structure being repaired and move on to the next region.
+
+7. If the region is to be freed, mark any corresponding buffers in the buffer
+ cache as stale to prevent log writeback.
+
+8. Free the region and move on.
+
+However, there is one complication to this procedure.
+Transactions are of finite size, so the reaping process must be careful to roll
+the transactions to avoid overruns.
+Overruns come from two sources:
+
+a. EFIs logged on behalf of space that is no longer occupied
+
+b. Log items for buffer invalidations
+
+This is also a window in which a crash during the reaping process can leak
+blocks.
+As stated earlier, online repair functions use very large transactions to
+minimize the chances of this occurring.
+
+Case Study: Reaping After a Regular Btree Repair
+````````````````````````````````````````````````
+
+Old reference count and inode btrees are the easiest to reap because they have
+rmap records with special owner codes: ``XFS_RMAP_OWN_REFC`` for the refcount
+btree, and ``XFS_RMAP_OWN_INOBT`` for the inode and free inode btrees.
+Creating a list of extents to reap the old btree blocks is quite simple,
+conceptually:
+
+1. Lock the relevant AGI/AGF header buffers to prevent allocation and frees.
+
+2. For each reverse mapping record with an rmap owner corresponding to the
+ metadata structure being rebuilt, set the corresponding range in a bitmap.
+
+3. Walk the current data structures that have the same rmap owner.
+ For each block visited, clear that range in the above bitmap.
+
+4. Each set bit in the bitmap represents a block that could be a block from the
+ old data structures and hence is a candidate for reaping.
+ In other words, ``(rmap_records_owned_by & ~blocks_reachable_by_walk)``
+ are the blocks that might be freeable.
+
+If it is possible to maintain the AGF lock throughout the repair (which is the
+common case), then step 2 can be performed at the same time as the reverse
+mapping record walk that creates the records for the new btree.
+
+Case Study: Rebuilding the Free Space Indices
+`````````````````````````````````````````````
+
+The high level process to rebuild the free space indices is:
+
+1. Walk the reverse mapping records to generate ``struct xfs_alloc_rec_incore``
+ records from the gaps in the reverse mapping btree.
+
+2. Append the records to an xfarray.
+
+3. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number
+ of blocks needed for each new tree.
+
+4. Allocate the number of blocks computed in the previous step from the free
+ space information collected.
+
+5. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and
+ generate the internal node blocks for the free space by length index.
+ Call it again for the free space by block number index.
+
+6. Commit the locations of the new btree root blocks to the AGF.
+
+7. Reap the old btree blocks by looking for space that is not recorded by the
+ reverse mapping btree, the new free space btrees, or the AGFL.
+
+Repairing the free space btrees has three key complications over a regular
+btree repair:
+
+First, free space is not explicitly tracked in the reverse mapping records.
+Hence, the new free space records must be inferred from gaps in the physical
+space component of the keyspace of the reverse mapping btree.
+
+Second, free space repairs cannot use the common btree reservation code because
+new blocks are reserved out of the free space btrees.
+This is impossible when repairing the free space btrees themselves.
+However, repair holds the AGF buffer lock for the duration of the free space
+index reconstruction, so it can use the collected free space information to
+supply the blocks for the new free space btrees.
+It is not necessary to back each reserved extent with an EFI because the new
+free space btrees are constructed in what the ondisk filesystem thinks is
+unowned space.
+However, if reserving blocks for the new btrees from the collected free space
+information changes the number of free space records, repair must re-estimate
+the new free space btree geometry with the new record count until the
+reservation is sufficient.
+As part of committing the new btrees, repair must ensure that reverse mappings
+are created for the reserved blocks and that unused reserved blocks are
+inserted into the free space btrees.
+Deferrred rmap and freeing operations are used to ensure that this transition
+is atomic, similar to the other btree repair functions.
+
+Third, finding the blocks to reap after the repair is not overly
+straightforward.
+Blocks for the free space btrees and the reverse mapping btrees are supplied by
+the AGFL.
+Blocks put onto the AGFL have reverse mapping records with the owner
+``XFS_RMAP_OWN_AG``.
+This ownership is retained when blocks move from the AGFL into the free space
+btrees or the reverse mapping btrees.
+When repair walks reverse mapping records to synthesize free space records, it
+creates a bitmap (``ag_owner_bitmap``) of all the space claimed by
+``XFS_RMAP_OWN_AG`` records.
+The repair context maintains a second bitmap corresponding to the rmap btree
+blocks and the AGFL blocks (``rmap_agfl_bitmap``).
+When the walk is complete, the bitmap disunion operation ``(ag_owner_bitmap &
+~rmap_agfl_bitmap)`` computes the extents that are used by the old free space
+btrees.
+These blocks can then be reaped using the methods outlined above.
+
+.. _rmap_reap:
+
+Case Study: Reaping After Repairing Reverse Mapping Btrees
+``````````````````````````````````````````````````````````
+
+Old reverse mapping btrees are less difficult to reap after a repair.
+As mentioned in the previous section, blocks on the AGFL, the two free space
+btree blocks, and the reverse mapping btree blocks all have reverse mapping
+records with ``XFS_RMAP_OWN_AG`` as the owner.
+The full process of gathering reverse mapping records and building a new btree
+are described in the case study of
+:ref:`live rebuilds of rmap data <rmap_repair>`, but a crucial point from that
+discussion is that the new rmap btree will not contain any records for the old
+rmap btree, nor will the old btree blocks be tracked in the free space btrees.
+The list of candidate reaping blocks is computed by setting the bits
+corresponding to the gaps in the new rmap btree records, and then clearing the
+bits corresponding to extents in the free space btrees and the current AGFL
+blocks.
+The result ``(new_rmapbt_gaps & ~(agfl | bnobt_records))`` are reaped using the
+methods outlined above.
+
+The rest of the process of rebuildng the reverse mapping btree is discussed
+in a separate :ref:`case study<rmap_repair>`.
+
+Case Study: Rebuilding the AGFL
+```````````````````````````````
+
+The allocation group free block list (AGFL) is repaired as follows:
+
+1. Create a bitmap for all the space that the reverse mapping data claims is
+ owned by ``XFS_RMAP_OWN_AG``.
+
+2. Subtract the space used by the two free space btrees and the rmap btree.
+
+3. Subtract any space that the reverse mapping data claims is owned by any
+ other owner, to avoid re-adding crosslinked blocks to the AGFL.
+
+4. Once the AGFL is full, reap any blocks leftover.
+
+5. The next operation to fix the freelist will right-size the list.
+
+See `fs/xfs/scrub/agheader_repair.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/scrub/agheader_repair.c>`_ for more details.
+
+Inode Record Repairs
+--------------------
+
+Inode records must be handled carefully, because they have both ondisk records
+("dinodes") and an in-memory ("cached") representation.
+There is a very high potential for cache coherency issues if online fsck is not
+careful to access the ondisk metadata *only* when the ondisk metadata is so
+badly damaged that the filesystem cannot load the in-memory representation.
+When online fsck wants to open a damaged file for scrubbing, it must use
+specialized resource acquisition functions that return either the in-memory
+representation *or* a lock on whichever object is necessary to prevent any
+update to the ondisk location.
+
+The only repairs that should be made to the ondisk inode buffers are whatever
+is necessary to get the in-core structure loaded.
+This means fixing whatever is caught by the inode cluster buffer and inode fork
+verifiers, and retrying the ``iget`` operation.
+If the second ``iget`` fails, the repair has failed.
+
+Once the in-memory representation is loaded, repair can lock the inode and can
+subject it to comprehensive checks, repairs, and optimizations.
+Most inode attributes are easy to check and constrain, or are user-controlled
+arbitrary bit patterns; these are both easy to fix.
+Dealing with the data and attr fork extent counts and the file block counts is
+more complicated, because computing the correct value requires traversing the
+forks, or if that fails, leaving the fields invalid and waiting for the fork
+fsck functions to run.
+
+Quota Record Repairs
+--------------------
+
+Similar to inodes, quota records ("dquots") also have both ondisk records and
+an in-memory representation, and hence are subject to the same cache coherency
+issues.
+Somewhat confusingly, both are known as dquots in the XFS codebase.
+
+The only repairs that should be made to the ondisk quota record buffers are
+whatever is necessary to get the in-core structure loaded.
+Once the in-memory representation is loaded, the only attributes needing
+checking are obviously bad limits and timer values.
+
+Quota usage counters are checked, repaired, and discussed separately in the
+section about :ref:`live quotacheck <quotacheck>`.
+
+.. _fscounters:
+
+Freezing to Fix Summary Counters
+--------------------------------
+
+Filesystem summary counters track availability of filesystem resources such
+as free blocks, free inodes, and allocated inodes.
+This information could be compiled by walking the free space and inode indexes,
+but this is a slow process, so XFS maintains a copy in the ondisk superblock
+that should reflect the ondisk metadata, at least when the filesystem has been
+unmounted cleanly.
+For performance reasons, XFS also maintains incore copies of those counters,
+which are key to enabling resource reservations for active transactions.
+Writer threads reserve the worst-case quantities of resources from the
+incore counter and give back whatever they don't use at commit time.
+It is therefore only necessary to serialize on the superblock when the
+superblock is being committed to disk.
+
+The lazy superblock counter feature introduced in XFS v5 took this even further
+by training log recovery to recompute the summary counters from the AG headers,
+which eliminated the need for most transactions even to touch the superblock.
+The only time XFS commits the summary counters is at filesystem unmount.
+To reduce contention even further, the incore counter is implemented as a
+percpu counter, which means that each CPU is allocated a batch of blocks from a
+global incore counter and can satisfy small allocations from the local batch.
+
+The high-performance nature of the summary counters makes it difficult for
+online fsck to check them, since there is no way to quiesce a percpu counter
+while the system is running.
+Although online fsck can read the filesystem metadata to compute the correct
+values of the summary counters, there's no way to hold the value of a percpu
+counter stable, so it's quite possible that the counter will be out of date by
+the time the walk is complete.
+Earlier versions of online scrub would return to userspace with an incomplete
+scan flag, but this is not a satisfying outcome for a system administrator.
+For repairs, the in-memory counters must be stabilized while walking the
+filesystem metadata to get an accurate reading and install it in the percpu
+counter.
+
+To satisfy this requirement, online fsck must prevent other programs in the
+system from initiating new writes to the filesystem, it must disable background
+garbage collection threads, and it must wait for existing writer programs to
+exit the kernel.
+Once that has been established, scrub can walk the AG free space indexes, the
+inode btrees, and the realtime bitmap to compute the correct value of all
+four summary counters.
+This is very similar to a filesystem freeze, though not all of the pieces are
+necessary:
+
+- The final freeze state is set one higher than ``SB_FREEZE_COMPLETE`` to
+ prevent other threads from thawing the filesystem, or other scrub threads
+ from initiating another fscounters freeze.
+
+- It does not quiesce the log.
+
+With this code in place, it is now possible to pause the filesystem for just
+long enough to check and correct the summary counters.
+
++--------------------------------------------------------------------------+
+| **Historical Sidebar**: |
++--------------------------------------------------------------------------+
+| The initial implementation used the actual VFS filesystem freeze |
+| mechanism to quiesce filesystem activity. |
+| With the filesystem frozen, it is possible to resolve the counter values |
+| with exact precision, but there are many problems with calling the VFS |
+| methods directly: |
+| |
+| - Other programs can unfreeze the filesystem without our knowledge. |
+| This leads to incorrect scan results and incorrect repairs. |
+| |
+| - Adding an extra lock to prevent others from thawing the filesystem |
+| required the addition of a ``->freeze_super`` function to wrap |
+| ``freeze_fs()``. |
+| This in turn caused other subtle problems because it turns out that |
+| the VFS ``freeze_super`` and ``thaw_super`` functions can drop the |
+| last reference to the VFS superblock, and any subsequent access |
+| becomes a UAF bug! |
+| This can happen if the filesystem is unmounted while the underlying |
+| block device has frozen the filesystem. |
+| This problem could be solved by grabbing extra references to the |
+| superblock, but it felt suboptimal given the other inadequacies of |
+| this approach. |
+| |
+| - The log need not be quiesced to check the summary counters, but a VFS |
+| freeze initiates one anyway. |
+| This adds unnecessary runtime to live fscounter fsck operations. |
+| |
+| - Quiescing the log means that XFS flushes the (possibly incorrect) |
+| counters to disk as part of cleaning the log. |
+| |
+| - A bug in the VFS meant that freeze could complete even when |
+| sync_filesystem fails to flush the filesystem and returns an error. |
+| This bug was fixed in Linux 5.17. |
++--------------------------------------------------------------------------+
+
+Full Filesystem Scans
+---------------------
+
+Certain types of metadata can only be checked by walking every file in the
+entire filesystem to record observations and comparing the observations against
+what's recorded on disk.
+Like every other type of online repair, repairs are made by writing those
+observations to disk in a replacement structure and committing it atomically.
+However, it is not practical to shut down the entire filesystem to examine
+hundreds of billions of files because the downtime would be excessive.
+Therefore, online fsck must build the infrastructure to manage a live scan of
+all the files in the filesystem.
+There are two questions that need to be solved to perform a live walk:
+
+- How does scrub manage the scan while it is collecting data?
+
+- How does the scan keep abreast of changes being made to the system by other
+ threads?
+
+.. _iscan:
+
+Coordinated Inode Scans
+```````````````````````
+
+In the original Unix filesystems of the 1970s, each directory entry contained
+an index number (*inumber*) which was used as an index into on ondisk array
+(*itable*) of fixed-size records (*inodes*) describing a file's attributes and
+its data block mapping.
+This system is described by J. Lions, `"inode (5659)"
+<http://www.lemis.com/grog/Documentation/Lions/>`_ in *Lions' Commentary on
+UNIX, 6th Edition*, (Dept. of Computer Science, the University of New South
+Wales, November 1977), pp. 18-2; and later by D. Ritchie and K. Thompson,
+`"Implementation of the File System"
+<https://archive.org/details/bstj57-6-1905/page/n8/mode/1up>`_, from *The UNIX
+Time-Sharing System*, (The Bell System Technical Journal, July 1978), pp.
+1913-4.
+
+XFS retains most of this design, except now inumbers are search keys over all
+the space in the data section filesystem.
+They form a continuous keyspace that can be expressed as a 64-bit integer,
+though the inodes themselves are sparsely distributed within the keyspace.
+Scans proceed in a linear fashion across the inumber keyspace, starting from
+``0x0`` and ending at ``0xFFFFFFFFFFFFFFFF``.
+Naturally, a scan through a keyspace requires a scan cursor object to track the
+scan progress.
+Because this keyspace is sparse, this cursor contains two parts.
+The first part of this scan cursor object tracks the inode that will be
+examined next; call this the examination cursor.
+Somewhat less obviously, the scan cursor object must also track which parts of
+the keyspace have already been visited, which is critical for deciding if a
+concurrent filesystem update needs to be incorporated into the scan data.
+Call this the visited inode cursor.
+
+Advancing the scan cursor is a multi-step process encapsulated in
+``xchk_iscan_iter``:
+
+1. Lock the AGI buffer of the AG containing the inode pointed to by the visited
+ inode cursor.
+ This guarantee that inodes in this AG cannot be allocated or freed while
+ advancing the cursor.
+
+2. Use the per-AG inode btree to look up the next inumber after the one that
+ was just visited, since it may not be keyspace adjacent.
+
+3. If there are no more inodes left in this AG:
+
+ a. Move the examination cursor to the point of the inumber keyspace that
+ corresponds to the start of the next AG.
+
+ b. Adjust the visited inode cursor to indicate that it has "visited" the
+ last possible inode in the current AG's inode keyspace.
+ XFS inumbers are segmented, so the cursor needs to be marked as having
+ visited the entire keyspace up to just before the start of the next AG's
+ inode keyspace.
+
+ c. Unlock the AGI and return to step 1 if there are unexamined AGs in the
+ filesystem.
+
+ d. If there are no more AGs to examine, set both cursors to the end of the
+ inumber keyspace.
+ The scan is now complete.
+
+4. Otherwise, there is at least one more inode to scan in this AG:
+
+ a. Move the examination cursor ahead to the next inode marked as allocated
+ by the inode btree.
+
+ b. Adjust the visited inode cursor to point to the inode just prior to where
+ the examination cursor is now.
+ Because the scanner holds the AGI buffer lock, no inodes could have been
+ created in the part of the inode keyspace that the visited inode cursor
+ just advanced.
+
+5. Get the incore inode for the inumber of the examination cursor.
+ By maintaining the AGI buffer lock until this point, the scanner knows that
+ it was safe to advance the examination cursor across the entire keyspace,
+ and that it has stabilized this next inode so that it cannot disappear from
+ the filesystem until the scan releases the incore inode.
+
+6. Drop the AGI lock and return the incore inode to the caller.
+
+Online fsck functions scan all files in the filesystem as follows:
+
+1. Start a scan by calling ``xchk_iscan_start``.
+
+2. Advance the scan cursor (``xchk_iscan_iter``) to get the next inode.
+ If one is provided:
+
+ a. Lock the inode to prevent updates during the scan.
+
+ b. Scan the inode.
+
+ c. While still holding the inode lock, adjust the visited inode cursor
+ (``xchk_iscan_mark_visited``) to point to this inode.
+
+ d. Unlock and release the inode.
+
+8. Call ``xchk_iscan_teardown`` to complete the scan.
+
+There are subtleties with the inode cache that complicate grabbing the incore
+inode for the caller.
+Obviously, it is an absolute requirement that the inode metadata be consistent
+enough to load it into the inode cache.
+Second, if the incore inode is stuck in some intermediate state, the scan
+coordinator must release the AGI and push the main filesystem to get the inode
+back into a loadable state.
+
+Inode Management
+````````````````
+
+In regular filesystem code, references to allocated XFS incore inodes are
+always obtained (``xfs_iget``) outside of transaction context because the
+creation of the incore context for an existing file does not require metadata
+updates.
+However, it is important to note that references to incore inodes obtained as
+part of file creation must be performed in transaction context because the
+filesystem must ensure the atomicity of the ondisk inode btree index updates
+and the initialization of the actual ondisk inode.
+
+References to incore inodes are always released (``xfs_irele``) outside of
+transaction context because there are a handful of activities that might
+require ondisk updates:
+
+- The VFS may decide to kick off writeback as part of a ``DONTCACHE`` inode
+ release.
+
+- Speculative preallocations need to be unreserved.
+
+- An unlinked file may have lost its last reference, in which case the entire
+ file must be inactivated, which involves releasing all of its resources in
+ the ondisk metadata and freeing the inode.
+
+These activities are collectively called inode inactivation.
+Inactivation has two parts -- the VFS part, which initiates writeback on all
+dirty file pages, and the XFS part, which cleans up XFS-specific information
+and frees the inode if it was unlinked.
+If the inode is unlinked (or unconnected after a file handle operation), the
+kernel drops the inode into the inactivation machinery immediately.
+
+During normal operation, resource acquisition for an update follows this order
+to avoid deadlocks:
+
+1. Inode reference (``iget``).
+
+2. Filesystem freeze protection, if repairing (``mnt_want_write_file``).
+
+3. Inode ``IOLOCK`` (VFS ``i_rwsem``) lock to control file IO.
+
+4. Inode ``MMAPLOCK`` (page cache ``invalidate_lock``) lock for operations that
+ can update page cache mappings.
+
+5. Log feature enablement.
+
+6. Transaction log space grant.
+
+7. Space on the data and realtime devices for the transaction.
+
+8. Incore dquot references, if a file is being repaired.
+ Note that they are not locked, merely acquired.
+
+9. Inode ``ILOCK`` for file metadata updates.
+
+10. AG header buffer locks / Realtime metadata inode ILOCK.
+
+11. Realtime metadata buffer locks, if applicable.
+
+12. Extent mapping btree blocks, if applicable.
+
+Resources are often released in the reverse order, though this is not required.
+However, online fsck differs from regular XFS operations because it may examine
+an object that normally is acquired in a later stage of the locking order, and
+then decide to cross-reference the object with an object that is acquired
+earlier in the order.
+The next few sections detail the specific ways in which online fsck takes care
+to avoid deadlocks.
+
+iget and irele During a Scrub
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An inode scan performed on behalf of a scrub operation runs in transaction
+context, and possibly with resources already locked and bound to it.
+This isn't much of a problem for ``iget`` since it can operate in the context
+of an existing transaction, as long as all of the bound resources are acquired
+before the inode reference in the regular filesystem.
+
+When the VFS ``iput`` function is given a linked inode with no other
+references, it normally puts the inode on an LRU list in the hope that it can
+save time if another process re-opens the file before the system runs out
+of memory and frees it.
+Filesystem callers can short-circuit the LRU process by setting a ``DONTCACHE``
+flag on the inode to cause the kernel to try to drop the inode into the
+inactivation machinery immediately.
+
+In the past, inactivation was always done from the process that dropped the
+inode, which was a problem for scrub because scrub may already hold a
+transaction, and XFS does not support nesting transactions.
+On the other hand, if there is no scrub transaction, it is desirable to drop
+otherwise unused inodes immediately to avoid polluting caches.
+To capture these nuances, the online fsck code has a separate ``xchk_irele``
+function to set or clear the ``DONTCACHE`` flag to get the required release
+behavior.
+
+.. _ilocking:
+
+Locking Inodes
+^^^^^^^^^^^^^^
+
+In regular filesystem code, the VFS and XFS will acquire multiple IOLOCK locks
+in a well-known order: parent → child when updating the directory tree, and
+in numerical order of the addresses of their ``struct inode`` object otherwise.
+For regular files, the MMAPLOCK can be acquired after the IOLOCK to stop page
+faults.
+If two MMAPLOCKs must be acquired, they are acquired in numerical order of
+the addresses of their ``struct address_space`` objects.
+Due to the structure of existing filesystem code, IOLOCKs and MMAPLOCKs must be
+acquired before transactions are allocated.
+If two ILOCKs must be acquired, they are acquired in inumber order.
+
+Inode lock acquisition must be done carefully during a coordinated inode scan.
+Online fsck cannot abide these conventions, because for a directory tree
+scanner, the scrub process holds the IOLOCK of the file being scanned and it
+needs to take the IOLOCK of the file at the other end of the directory link.
+If the directory tree is corrupt because it contains a cycle, ``xfs_scrub``
+cannot use the regular inode locking functions and avoid becoming trapped in an
+ABBA deadlock.
+
+Solving both of these problems is straightforward -- any time online fsck
+needs to take a second lock of the same class, it uses trylock to avoid an ABBA
+deadlock.
+If the trylock fails, scrub drops all inode locks and use trylock loops to
+(re)acquire all necessary resources.
+Trylock loops enable scrub to check for pending fatal signals, which is how
+scrub avoids deadlocking the filesystem or becoming an unresponsive process.
+However, trylock loops means that online fsck must be prepared to measure the
+resource being scrubbed before and after the lock cycle to detect changes and
+react accordingly.
+
+.. _dirparent:
+
+Case Study: Finding a Directory Parent
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Consider the directory parent pointer repair code as an example.
+Online fsck must verify that the dotdot dirent of a directory points up to a
+parent directory, and that the parent directory contains exactly one dirent
+pointing down to the child directory.
+Fully validating this relationship (and repairing it if possible) requires a
+walk of every directory on the filesystem while holding the child locked, and
+while updates to the directory tree are being made.
+The coordinated inode scan provides a way to walk the filesystem without the
+possibility of missing an inode.
+The child directory is kept locked to prevent updates to the dotdot dirent, but
+if the scanner fails to lock a parent, it can drop and relock both the child
+and the prospective parent.
+If the dotdot entry changes while the directory is unlocked, then a move or
+rename operation must have changed the child's parentage, and the scan can
+exit early.
+
+.. _fshooks:
+
+Filesystem Hooks
+`````````````````
+
+The second piece of support that online fsck functions need during a full
+filesystem scan is the ability to stay informed about updates being made by
+other threads in the filesystem, since comparisons against the past are useless
+in a dynamic environment.
+Two pieces of Linux kernel infrastructure enable online fsck to monitor regular
+filesystem operations: filesystem hooks and :ref:`static keys<jump_labels>`.
+
+Filesystem hooks convey information about an ongoing filesystem operation to
+a downstream consumer.
+In this case, the downstream consumer is always an online fsck function.
+Because multiple fsck functions can run in parallel, online fsck uses the Linux
+notifier call chain facility to dispatch updates to any number of interested
+fsck processes.
+Call chains are a dynamic list, which means that they can be configured at
+run time.
+Because these hooks are private to the XFS module, the information passed along
+contains exactly what the checking function needs to update its observations.
+
+The current implementation of XFS hooks uses SRCU notifier chains to reduce the
+impact to highly threaded workloads.
+Regular blocking notifier chains use a rwsem and seem to have a much lower
+overhead for single-threaded applications.
+However, it may turn out that the combination of blocking chains and static
+keys are a more performant combination; more study is needed here.
+
+The following pieces are necessary to hook a certain point in the filesystem:
+
+- A ``struct xfs_hooks`` object must be embedded in a convenient place such as
+ a well-known incore filesystem object.
+
+- Each hook must define an action code and a structure containing more context
+ about the action.
+
+- Hook providers should provide appropriate wrapper functions and structs
+ around the ``xfs_hooks`` and ``xfs_hook`` objects to take advantage of type
+ checking to ensure correct usage.
+
+- A callsite in the regular filesystem code must be chosen to call
+ ``xfs_hooks_call`` with the action code and data structure.
+ This place should be adjacent to (and not earlier than) the place where
+ the filesystem update is committed to the transaction.
+ In general, when the filesystem calls a hook chain, it should be able to
+ handle sleeping and should not be vulnerable to memory reclaim or locking
+ recursion.
+ However, the exact requirements are very dependent on the context of the hook
+ caller and the callee.
+
+- The online fsck function should define a structure to hold scan data, a lock
+ to coordinate access to the scan data, and a ``struct xfs_hook`` object.
+ The scanner function and the regular filesystem code must acquire resources
+ in the same order; see the next section for details.
+
+- The online fsck code must contain a C function to catch the hook action code
+ and data structure.
+ If the object being updated has already been visited by the scan, then the
+ hook information must be applied to the scan data.
+
+- Prior to unlocking inodes to start the scan, online fsck must call
+ ``xfs_hooks_setup`` to initialize the ``struct xfs_hook``, and
+ ``xfs_hooks_add`` to enable the hook.
+
+- Online fsck must call ``xfs_hooks_del`` to disable the hook once the scan is
+ complete.
+
+The number of hooks should be kept to a minimum to reduce complexity.
+Static keys are used to reduce the overhead of filesystem hooks to nearly
+zero when online fsck is not running.
+
+.. _liveupdate:
+
+Live Updates During a Scan
+``````````````````````````
+
+The code paths of the online fsck scanning code and the :ref:`hooked<fshooks>`
+filesystem code look like this::
+
+ other program
+ ↓
+ inode lock ←────────────────────┐
+ ↓ │
+ AG header lock │
+ ↓ │
+ filesystem function │
+ ↓ │
+ notifier call chain │ same
+ ↓ ├─── inode
+ scrub hook function │ lock
+ ↓ │
+ scan data mutex ←──┐ same │
+ ↓ ├─── scan │
+ update scan data │ lock │
+ ↑ │ │
+ scan data mutex ←──┘ │
+ ↑ │
+ inode lock ←────────────────────┘
+ ↑
+ scrub function
+ ↑
+ inode scanner
+ ↑
+ xfs_scrub
+
+These rules must be followed to ensure correct interactions between the
+checking code and the code making an update to the filesystem:
+
+- Prior to invoking the notifier call chain, the filesystem function being
+ hooked must acquire the same lock that the scrub scanning function acquires
+ to scan the inode.
+
+- The scanning function and the scrub hook function must coordinate access to
+ the scan data by acquiring a lock on the scan data.
+
+- Scrub hook function must not add the live update information to the scan
+ observations unless the inode being updated has already been scanned.
+ The scan coordinator has a helper predicate (``xchk_iscan_want_live_update``)
+ for this.
+
+- Scrub hook functions must not change the caller's state, including the
+ transaction that it is running.
+ They must not acquire any resources that might conflict with the filesystem
+ function being hooked.
+
+- The hook function can abort the inode scan to avoid breaking the other rules.
+
+The inode scan APIs are pretty simple:
+
+- ``xchk_iscan_start`` starts a scan
+
+- ``xchk_iscan_iter`` grabs a reference to the next inode in the scan or
+ returns zero if there is nothing left to scan
+
+- ``xchk_iscan_want_live_update`` to decide if an inode has already been
+ visited in the scan.
+ This is critical for hook functions to decide if they need to update the
+ in-memory scan information.
+
+- ``xchk_iscan_mark_visited`` to mark an inode as having been visited in the
+ scan
+
+- ``xchk_iscan_teardown`` to finish the scan
+
+.. _quotacheck:
+
+Case Study: Quota Counter Checking
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+It is useful to compare the mount time quotacheck code to the online repair
+quotacheck code.
+Mount time quotacheck does not have to contend with concurrent operations, so
+it does the following:
+
+1. Make sure the ondisk dquots are in good enough shape that all the incore
+ dquots will actually load, and zero the resource usage counters in the
+ ondisk buffer.
+
+2. Walk every inode in the filesystem.
+ Add each file's resource usage to the incore dquot.
+
+3. Walk each incore dquot.
+ If the incore dquot is not being flushed, add the ondisk buffer backing the
+ incore dquot to a delayed write (delwri) list.
+
+4. Write the buffer list to disk.
+
+Like most online fsck functions, online quotacheck can't write to regular
+filesystem objects until the newly collected metadata reflect all filesystem
+state.
+Therefore, online quotacheck records file resource usage to a shadow dquot
+index implemented with a sparse ``xfarray``, and only writes to the real dquots
+once the scan is complete.
+Handling transactional updates is tricky because quota resource usage updates
+are handled in phases to minimize contention on dquots:
+
+1. The inodes involved are joined and locked to a transaction.
+
+2. For each dquot attached to the file:
+
+ a. The dquot is locked.
+
+ b. A quota reservation is added to the dquot's resource usage.
+ The reservation is recorded in the transaction.
+
+ c. The dquot is unlocked.
+
+3. Changes in actual quota usage are tracked in the transaction.
+
+4. At transaction commit time, each dquot is examined again:
+
+ a. The dquot is locked again.
+
+ b. Quota usage changes are logged and unused reservation is given back to
+ the dquot.
+
+ c. The dquot is unlocked.
+
+For online quotacheck, hooks are placed in steps 2 and 4.
+The step 2 hook creates a shadow version of the transaction dquot context
+(``dqtrx``) that operates in a similar manner to the regular code.
+The step 4 hook commits the shadow ``dqtrx`` changes to the shadow dquots.
+Notice that both hooks are called with the inode locked, which is how the
+live update coordinates with the inode scanner.
+
+The quotacheck scan looks like this:
+
+1. Set up a coordinated inode scan.
+
+2. For each inode returned by the inode scan iterator:
+
+ a. Grab and lock the inode.
+
+ b. Determine that inode's resource usage (data blocks, inode counts,
+ realtime blocks) and add that to the shadow dquots for the user, group,
+ and project ids associated with the inode.
+
+ c. Unlock and release the inode.
+
+3. For each dquot in the system:
+
+ a. Grab and lock the dquot.
+
+ b. Check the dquot against the shadow dquots created by the scan and updated
+ by the live hooks.
+
+Live updates are key to being able to walk every quota record without
+needing to hold any locks for a long duration.
+If repairs are desired, the real and shadow dquots are locked and their
+resource counts are set to the values in the shadow dquot.
+
+.. _nlinks:
+
+Case Study: File Link Count Checking
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+File link count checking also uses live update hooks.
+The coordinated inode scanner is used to visit all directories on the
+filesystem, and per-file link count records are stored in a sparse ``xfarray``
+indexed by inumber.
+During the scanning phase, each entry in a directory generates observation
+data as follows:
+
+1. If the entry is a dotdot (``'..'``) entry of the root directory, the
+ directory's parent link count is bumped because the root directory's dotdot
+ entry is self referential.
+
+2. If the entry is a dotdot entry of a subdirectory, the parent's backref
+ count is bumped.
+
+3. If the entry is neither a dot nor a dotdot entry, the target file's parent
+ count is bumped.
+
+4. If the target is a subdirectory, the parent's child link count is bumped.
+
+A crucial point to understand about how the link count inode scanner interacts
+with the live update hooks is that the scan cursor tracks which *parent*
+directories have been scanned.
+In other words, the live updates ignore any update about ``A → B`` when A has
+not been scanned, even if B has been scanned.
+Furthermore, a subdirectory A with a dotdot entry pointing back to B is
+accounted as a backref counter in the shadow data for A, since child dotdot
+entries affect the parent's link count.
+Live update hooks are carefully placed in all parts of the filesystem that
+create, change, or remove directory entries, since those operations involve
+bumplink and droplink.
+
+For any file, the correct link count is the number of parents plus the number
+of child subdirectories.
+Non-directories never have children of any kind.
+The backref information is used to detect inconsistencies in the number of
+links pointing to child subdirectories and the number of dotdot entries
+pointing back.
+
+After the scan completes, the link count of each file can be checked by locking
+both the inode and the shadow data, and comparing the link counts.
+A second coordinated inode scan cursor is used for comparisons.
+Live updates are key to being able to walk every inode without needing to hold
+any locks between inodes.
+If repairs are desired, the inode's link count is set to the value in the
+shadow information.
+If no parents are found, the file must be :ref:`reparented <orphanage>` to the
+orphanage to prevent the file from being lost forever.
+
+.. _rmap_repair:
+
+Case Study: Rebuilding Reverse Mapping Records
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most repair functions follow the same pattern: lock filesystem resources,
+walk the surviving ondisk metadata looking for replacement metadata records,
+and use an :ref:`in-memory array <xfarray>` to store the gathered observations.
+The primary advantage of this approach is the simplicity and modularity of the
+repair code -- code and data are entirely contained within the scrub module,
+do not require hooks in the main filesystem, and are usually the most efficient
+in memory use.
+A secondary advantage of this repair approach is atomicity -- once the kernel
+decides a structure is corrupt, no other threads can access the metadata until
+the kernel finishes repairing and revalidating the metadata.
+
+For repairs going on within a shard of the filesystem, these advantages
+outweigh the delays inherent in locking the shard while repairing parts of the
+shard.
+Unfortunately, repairs to the reverse mapping btree cannot use the "standard"
+btree repair strategy because it must scan every space mapping of every fork of
+every file in the filesystem, and the filesystem cannot stop.
+Therefore, rmap repair foregoes atomicity between scrub and repair.
+It combines a :ref:`coordinated inode scanner <iscan>`, :ref:`live update hooks
+<liveupdate>`, and an :ref:`in-memory rmap btree <xfbtree>` to complete the
+scan for reverse mapping records.
+
+1. Set up an xfbtree to stage rmap records.
+
+2. While holding the locks on the AGI and AGF buffers acquired during the
+ scrub, generate reverse mappings for all AG metadata: inodes, btrees, CoW
+ staging extents, and the internal log.
+
+3. Set up an inode scanner.
+
+4. Hook into rmap updates for the AG being repaired so that the live scan data
+ can receive updates to the rmap btree from the rest of the filesystem during
+ the file scan.
+
+5. For each space mapping found in either fork of each file scanned,
+ decide if the mapping matches the AG of interest.
+ If so:
+
+ a. Create a btree cursor for the in-memory btree.
+
+ b. Use the rmap code to add the record to the in-memory btree.
+
+ c. Use the :ref:`special commit function <xfbtree_commit>` to write the
+ xfbtree changes to the xfile.
+
+6. For each live update received via the hook, decide if the owner has already
+ been scanned.
+ If so, apply the live update into the scan data:
+
+ a. Create a btree cursor for the in-memory btree.
+
+ b. Replay the operation into the in-memory btree.
+
+ c. Use the :ref:`special commit function <xfbtree_commit>` to write the
+ xfbtree changes to the xfile.
+ This is performed with an empty transaction to avoid changing the
+ caller's state.
+
+7. When the inode scan finishes, create a new scrub transaction and relock the
+ two AG headers.
+
+8. Compute the new btree geometry using the number of rmap records in the
+ shadow btree, like all other btree rebuilding functions.
+
+9. Allocate the number of blocks computed in the previous step.
+
+10. Perform the usual btree bulk loading and commit to install the new rmap
+ btree.
+
+11. Reap the old rmap btree blocks as discussed in the case study about how
+ to :ref:`reap after rmap btree repair <rmap_reap>`.
+
+12. Free the xfbtree now that it not needed.
+
+Staging Repairs with Temporary Files on Disk
+--------------------------------------------
+
+XFS stores a substantial amount of metadata in file forks: directories,
+extended attributes, symbolic link targets, free space bitmaps and summary
+information for the realtime volume, and quota records.
+File forks map 64-bit logical file fork space extents to physical storage space
+extents, similar to how a memory management unit maps 64-bit virtual addresses
+to physical memory addresses.
+Therefore, file-based tree structures (such as directories and extended
+attributes) use blocks mapped in the file fork offset address space that point
+to other blocks mapped within that same address space, and file-based linear
+structures (such as bitmaps and quota records) compute array element offsets in
+the file fork offset address space.
+
+Because file forks can consume as much space as the entire filesystem, repairs
+cannot be staged in memory, even when a paging scheme is available.
+Therefore, online repair of file-based metadata createas a temporary file in
+the XFS filesystem, writes a new structure at the correct offsets into the
+temporary file, and atomically exchanges all file fork mappings (and hence the
+fork contents) to commit the repair.
+Once the repair is complete, the old fork can be reaped as necessary; if the
+system goes down during the reap, the iunlink code will delete the blocks
+during log recovery.
+
+**Note**: All space usage and inode indices in the filesystem *must* be
+consistent to use a temporary file safely!
+This dependency is the reason why online repair can only use pageable kernel
+memory to stage ondisk space usage information.
+
+Exchanging metadata file mappings with a temporary file requires the owner
+field of the block headers to match the file being repaired and not the
+temporary file.
+The directory, extended attribute, and symbolic link functions were all
+modified to allow callers to specify owner numbers explicitly.
+
+There is a downside to the reaping process -- if the system crashes during the
+reap phase and the fork extents are crosslinked, the iunlink processing will
+fail because freeing space will find the extra reverse mappings and abort.
+
+Temporary files created for repair are similar to ``O_TMPFILE`` files created
+by userspace.
+They are not linked into a directory and the entire file will be reaped when
+the last reference to the file is lost.
+The key differences are that these files must have no access permission outside
+the kernel at all, they must be specially marked to prevent them from being
+opened by handle, and they must never be linked into the directory tree.
+
++--------------------------------------------------------------------------+
+| **Historical Sidebar**: |
++--------------------------------------------------------------------------+
+| In the initial iteration of file metadata repair, the damaged metadata |
+| blocks would be scanned for salvageable data; the extents in the file |
+| fork would be reaped; and then a new structure would be built in its |
+| place. |
+| This strategy did not survive the introduction of the atomic repair |
+| requirement expressed earlier in this document. |
+| |
+| The second iteration explored building a second structure at a high |
+| offset in the fork from the salvage data, reaping the old extents, and |
+| using a ``COLLAPSE_RANGE`` operation to slide the new extents into |
+| place. |
+| |
+| This had many drawbacks: |
+| |
+| - Array structures are linearly addressed, and the regular filesystem |
+| codebase does not have the concept of a linear offset that could be |
+| applied to the record offset computation to build an alternate copy. |
+| |
+| - Extended attributes are allowed to use the entire attr fork offset |
+| address space. |
+| |
+| - Even if repair could build an alternate copy of a data structure in a |
+| different part of the fork address space, the atomic repair commit |
+| requirement means that online repair would have to be able to perform |
+| a log assisted ``COLLAPSE_RANGE`` operation to ensure that the old |
+| structure was completely replaced. |
+| |
+| - A crash after construction of the secondary tree but before the range |
+| collapse would leave unreachable blocks in the file fork. |
+| This would likely confuse things further. |
+| |
+| - Reaping blocks after a repair is not a simple operation, and |
+| initiating a reap operation from a restarted range collapse operation |
+| during log recovery is daunting. |
+| |
+| - Directory entry blocks and quota records record the file fork offset |
+| in the header area of each block. |
+| An atomic range collapse operation would have to rewrite this part of |
+| each block header. |
+| Rewriting a single field in block headers is not a huge problem, but |
+| it's something to be aware of. |
+| |
+| - Each block in a directory or extended attributes btree index contains |
+| sibling and child block pointers. |
+| Were the atomic commit to use a range collapse operation, each block |
+| would have to be rewritten very carefully to preserve the graph |
+| structure. |
+| Doing this as part of a range collapse means rewriting a large number |
+| of blocks repeatedly, which is not conducive to quick repairs. |
+| |
+| This lead to the introduction of temporary file staging. |
++--------------------------------------------------------------------------+
+
+Using a Temporary File
+``````````````````````
+
+Online repair code should use the ``xrep_tempfile_create`` function to create a
+temporary file inside the filesystem.
+This allocates an inode, marks the in-core inode private, and attaches it to
+the scrub context.
+These files are hidden from userspace, may not be added to the directory tree,
+and must be kept private.
+
+Temporary files only use two inode locks: the IOLOCK and the ILOCK.
+The MMAPLOCK is not needed here, because there must not be page faults from
+userspace for data fork blocks.
+The usage patterns of these two locks are the same as for any other XFS file --
+access to file data are controlled via the IOLOCK, and access to file metadata
+are controlled via the ILOCK.
+Locking helpers are provided so that the temporary file and its lock state can
+be cleaned up by the scrub context.
+To comply with the nested locking strategy laid out in the :ref:`inode
+locking<ilocking>` section, it is recommended that scrub functions use the
+xrep_tempfile_ilock*_nowait lock helpers.
+
+Data can be written to a temporary file by two means:
+
+1. ``xrep_tempfile_copyin`` can be used to set the contents of a regular
+ temporary file from an xfile.
+
+2. The regular directory, symbolic link, and extended attribute functions can
+ be used to write to the temporary file.
+
+Once a good copy of a data file has been constructed in a temporary file, it
+must be conveyed to the file being repaired, which is the topic of the next
+section.
+
+Logged File Content Exchanges
+-----------------------------
+
+Once repair builds a temporary file with a new data structure written into
+it, it must commit the new changes into the existing file.
+It is not possible to swap the inumbers of two files, so instead the new
+metadata must replace the old.
+This suggests the need for the ability to swap extents, but the existing extent
+swapping code used by the file defragmenting tool ``xfs_fsr`` is not sufficient
+for online repair because:
+
+a. When the reverse-mapping btree is enabled, the swap code must keep the
+ reverse mapping information up to date with every exchange of mappings.
+ Therefore, it can only exchange one mapping per transaction, and each
+ transaction is independent.
+
+b. Reverse-mapping is critical for the operation of online fsck, so the old
+ defragmentation code (which swapped entire extent forks in a single
+ operation) is not useful here.
+
+c. Defragmentation is assumed to occur between two files with identical
+ contents.
+ For this use case, an incomplete exchange will not result in a user-visible
+ change in file contents, even if the operation is interrupted.
+
+d. Online repair needs to swap the contents of two files that are by definition
+ *not* identical.
+ For directory and xattr repairs, the user-visible contents might be the
+ same, but the contents of individual blocks may be very different.
+
+e. Old blocks in the file may be cross-linked with another structure and must
+ not reappear if the system goes down mid-repair.
+
+These problems are overcome by creating a new deferred operation and a new type
+of log intent item to track the progress of an operation to exchange two file
+ranges.
+The new exchange operation type chains together the same transactions used by
+the reverse-mapping extent swap code, but records intermedia progress in the
+log so that operations can be restarted after a crash.
+This new functionality is called the file contents exchange (xfs_exchrange)
+code.
+The underlying implementation exchanges file fork mappings (xfs_exchmaps).
+The new log item records the progress of the exchange to ensure that once an
+exchange begins, it will always run to completion, even there are
+interruptions.
+The new ``XFS_SB_FEAT_INCOMPAT_EXCHRANGE`` incompatible feature flag
+in the superblock protects these new log item records from being replayed on
+old kernels.
+
++--------------------------------------------------------------------------+
+| **Sidebar: Using Log-Incompatible Feature Flags** |
++--------------------------------------------------------------------------+
+| Starting with XFS v5, the superblock contains a |
+| ``sb_features_log_incompat`` field to indicate that the log contains |
+| records that might not readable by all kernels that could mount this |
+| filesystem. |
+| In short, log incompat features protect the log contents against kernels |
+| that will not understand the contents. |
+| Unlike the other superblock feature bits, log incompat bits are |
+| ephemeral because an empty (clean) log does not need protection. |
+| The log cleans itself after its contents have been committed into the |
+| filesystem, either as part of an unmount or because the system is |
+| otherwise idle. |
+| Because upper level code can be working on a transaction at the same |
+| time that the log cleans itself, it is necessary for upper level code to |
+| communicate to the log when it is going to use a log incompatible |
+| feature. |
+| |
+| The log coordinates access to incompatible features through the use of |
+| one ``struct rw_semaphore`` for each feature. |
+| The log cleaning code tries to take this rwsem in exclusive mode to |
+| clear the bit; if the lock attempt fails, the feature bit remains set. |
+| The code supporting a log incompat feature should create wrapper |
+| functions to obtain the log feature and call |
+| ``xfs_add_incompat_log_feature`` to set the feature bits in the primary |
+| superblock. |
+| The superblock update is performed transactionally, so the wrapper to |
+| obtain log assistance must be called just prior to the creation of the |
+| transaction that uses the functionality. |
+| For a file operation, this step must happen after taking the IOLOCK |
+| and the MMAPLOCK, but before allocating the transaction. |
+| When the transaction is complete, the ``xlog_drop_incompat_feat`` |
+| function is called to release the feature. |
+| The feature bit will not be cleared from the superblock until the log |
+| becomes clean. |
+| |
+| Log-assisted extended attribute updates and file content exchanges bothe |
+| use log incompat features and provide convenience wrappers around the |
+| functionality. |
++--------------------------------------------------------------------------+
+
+Mechanics of a Logged File Content Exchange
+```````````````````````````````````````````
+
+Exchanging contents between file forks is a complex task.
+The goal is to exchange all file fork mappings between two file fork offset
+ranges.
+There are likely to be many extent mappings in each fork, and the edges of
+the mappings aren't necessarily aligned.
+Furthermore, there may be other updates that need to happen after the exchange,
+such as exchanging file sizes, inode flags, or conversion of fork data to local
+format.
+This is roughly the format of the new deferred exchange-mapping work item:
+
+.. code-block:: c
+
+ struct xfs_exchmaps_intent {
+ /* Inodes participating in the operation. */
+ struct xfs_inode *xmi_ip1;
+ struct xfs_inode *xmi_ip2;
+
+ /* File offset range information. */
+ xfs_fileoff_t xmi_startoff1;
+ xfs_fileoff_t xmi_startoff2;
+ xfs_filblks_t xmi_blockcount;
+
+ /* Set these file sizes after the operation, unless negative. */
+ xfs_fsize_t xmi_isize1;
+ xfs_fsize_t xmi_isize2;
+
+ /* XFS_EXCHMAPS_* log operation flags */
+ uint64_t xmi_flags;
+ };
+
+The new log intent item contains enough information to track two logical fork
+offset ranges: ``(inode1, startoff1, blockcount)`` and ``(inode2, startoff2,
+blockcount)``.
+Each step of an exchange operation exchanges the largest file range mapping
+possible from one file to the other.
+After each step in the exchange operation, the two startoff fields are
+incremented and the blockcount field is decremented to reflect the progress
+made.
+The flags field captures behavioral parameters such as exchanging attr fork
+mappings instead of the data fork and other work to be done after the exchange.
+The two isize fields are used to exchange the file sizes at the end of the
+operation if the file data fork is the target of the operation.
+
+When the exchange is initiated, the sequence of operations is as follows:
+
+1. Create a deferred work item for the file mapping exchange.
+ At the start, it should contain the entirety of the file block ranges to be
+ exchanged.
+
+2. Call ``xfs_defer_finish`` to process the exchange.
+ This is encapsulated in ``xrep_tempexch_contents`` for scrub operations.
+ This will log an extent swap intent item to the transaction for the deferred
+ mapping exchange work item.
+
+3. Until ``xmi_blockcount`` of the deferred mapping exchange work item is zero,
+
+ a. Read the block maps of both file ranges starting at ``xmi_startoff1`` and
+ ``xmi_startoff2``, respectively, and compute the longest extent that can
+ be exchanged in a single step.
+ This is the minimum of the two ``br_blockcount`` s in the mappings.
+ Keep advancing through the file forks until at least one of the mappings
+ contains written blocks.
+ Mutual holes, unwritten extents, and extent mappings to the same physical
+ space are not exchanged.
+
+ For the next few steps, this document will refer to the mapping that came
+ from file 1 as "map1", and the mapping that came from file 2 as "map2".
+
+ b. Create a deferred block mapping update to unmap map1 from file 1.
+
+ c. Create a deferred block mapping update to unmap map2 from file 2.
+
+ d. Create a deferred block mapping update to map map1 into file 2.
+
+ e. Create a deferred block mapping update to map map2 into file 1.
+
+ f. Log the block, quota, and extent count updates for both files.
+
+ g. Extend the ondisk size of either file if necessary.
+
+ h. Log a mapping exchange done log item for th mapping exchange intent log
+ item that was read at the start of step 3.
+
+ i. Compute the amount of file range that has just been covered.
+ This quantity is ``(map1.br_startoff + map1.br_blockcount -
+ xmi_startoff1)``, because step 3a could have skipped holes.
+
+ j. Increase the starting offsets of ``xmi_startoff1`` and ``xmi_startoff2``
+ by the number of blocks computed in the previous step, and decrease
+ ``xmi_blockcount`` by the same quantity.
+ This advances the cursor.
+
+ k. Log a new mapping exchange intent log item reflecting the advanced state
+ of the work item.
+
+ l. Return the proper error code (EAGAIN) to the deferred operation manager
+ to inform it that there is more work to be done.
+ The operation manager completes the deferred work in steps 3b-3e before
+ moving back to the start of step 3.
+
+4. Perform any post-processing.
+ This will be discussed in more detail in subsequent sections.
+
+If the filesystem goes down in the middle of an operation, log recovery will
+find the most recent unfinished mapping exchange log intent item and restart
+from there.
+This is how atomic file mapping exchanges guarantees that an outside observer
+will either see the old broken structure or the new one, and never a mismash of
+both.
+
+Preparation for File Content Exchanges
+``````````````````````````````````````
+
+There are a few things that need to be taken care of before initiating an
+atomic file mapping exchange operation.
+First, regular files require the page cache to be flushed to disk before the
+operation begins, and directio writes to be quiesced.
+Like any filesystem operation, file mapping exchanges must determine the
+maximum amount of disk space and quota that can be consumed on behalf of both
+files in the operation, and reserve that quantity of resources to avoid an
+unrecoverable out of space failure once it starts dirtying metadata.
+The preparation step scans the ranges of both files to estimate:
+
+- Data device blocks needed to handle the repeated updates to the fork
+ mappings.
+- Change in data and realtime block counts for both files.
+- Increase in quota usage for both files, if the two files do not share the
+ same set of quota ids.
+- The number of extent mappings that will be added to each file.
+- Whether or not there are partially written realtime extents.
+ User programs must never be able to access a realtime file extent that maps
+ to different extents on the realtime volume, which could happen if the
+ operation fails to run to completion.
+
+The need for precise estimation increases the run time of the exchange
+operation, but it is very important to maintain correct accounting.
+The filesystem must not run completely out of free space, nor can the mapping
+exchange ever add more extent mappings to a fork than it can support.
+Regular users are required to abide the quota limits, though metadata repairs
+may exceed quota to resolve inconsistent metadata elsewhere.
+
+Special Features for Exchanging Metadata File Contents
+``````````````````````````````````````````````````````
+
+Extended attributes, symbolic links, and directories can set the fork format to
+"local" and treat the fork as a literal area for data storage.
+Metadata repairs must take extra steps to support these cases:
+
+- If both forks are in local format and the fork areas are large enough, the
+ exchange is performed by copying the incore fork contents, logging both
+ forks, and committing.
+ The atomic file mapping exchange mechanism is not necessary, since this can
+ be done with a single transaction.
+
+- If both forks map blocks, then the regular atomic file mapping exchange is
+ used.
+
+- Otherwise, only one fork is in local format.
+ The contents of the local format fork are converted to a block to perform the
+ exchange.
+ The conversion to block format must be done in the same transaction that
+ logs the initial mapping exchange intent log item.
+ The regular atomic mapping exchange is used to exchange the metadata file
+ mappings.
+ Special flags are set on the exchange operation so that the transaction can
+ be rolled one more time to convert the second file's fork back to local
+ format so that the second file will be ready to go as soon as the ILOCK is
+ dropped.
+
+Extended attributes and directories stamp the owning inode into every block,
+but the buffer verifiers do not actually check the inode number!
+Although there is no verification, it is still important to maintain
+referential integrity, so prior to performing the mapping exchange, online
+repair builds every block in the new data structure with the owner field of the
+file being repaired.
+
+After a successful exchange operation, the repair operation must reap the old
+fork blocks by processing each fork mapping through the standard :ref:`file
+extent reaping <reaping>` mechanism that is done post-repair.
+If the filesystem should go down during the reap part of the repair, the
+iunlink processing at the end of recovery will free both the temporary file and
+whatever blocks were not reaped.
+However, this iunlink processing omits the cross-link detection of online
+repair, and is not completely foolproof.
+
+Exchanging Temporary File Contents
+``````````````````````````````````
+
+To repair a metadata file, online repair proceeds as follows:
+
+1. Create a temporary repair file.
+
+2. Use the staging data to write out new contents into the temporary repair
+ file.
+ The same fork must be written to as is being repaired.
+
+3. Commit the scrub transaction, since the exchange resource estimation step
+ must be completed before transaction reservations are made.
+
+4. Call ``xrep_tempexch_trans_alloc`` to allocate a new scrub transaction with
+ the appropriate resource reservations, locks, and fill out a ``struct
+ xfs_exchmaps_req`` with the details of the exchange operation.
+
+5. Call ``xrep_tempexch_contents`` to exchange the contents.
+
+6. Commit the transaction to complete the repair.
+
+.. _rtsummary:
+
+Case Study: Repairing the Realtime Summary File
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In the "realtime" section of an XFS filesystem, free space is tracked via a
+bitmap, similar to Unix FFS.
+Each bit in the bitmap represents one realtime extent, which is a multiple of
+the filesystem block size between 4KiB and 1GiB in size.
+The realtime summary file indexes the number of free extents of a given size to
+the offset of the block within the realtime free space bitmap where those free
+extents begin.
+In other words, the summary file helps the allocator find free extents by
+length, similar to what the free space by count (cntbt) btree does for the data
+section.
+
+The summary file itself is a flat file (with no block headers or checksums!)
+partitioned into ``log2(total rt extents)`` sections containing enough 32-bit
+counters to match the number of blocks in the rt bitmap.
+Each counter records the number of free extents that start in that bitmap block
+and can satisfy a power-of-two allocation request.
+
+To check the summary file against the bitmap:
+
+1. Take the ILOCK of both the realtime bitmap and summary files.
+
+2. For each free space extent recorded in the bitmap:
+
+ a. Compute the position in the summary file that contains a counter that
+ represents this free extent.
+
+ b. Read the counter from the xfile.
+
+ c. Increment it, and write it back to the xfile.
+
+3. Compare the contents of the xfile against the ondisk file.
+
+To repair the summary file, write the xfile contents into the temporary file
+and use atomic mapping exchange to commit the new contents.
+The temporary file is then reaped.
+
+Case Study: Salvaging Extended Attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In XFS, extended attributes are implemented as a namespaced name-value store.
+Values are limited in size to 64KiB, but there is no limit in the number of
+names.
+The attribute fork is unpartitioned, which means that the root of the attribute
+structure is always in logical block zero, but attribute leaf blocks, dabtree
+index blocks, and remote value blocks are intermixed.
+Attribute leaf blocks contain variable-sized records that associate
+user-provided names with the user-provided values.
+Values larger than a block are allocated separate extents and written there.
+If the leaf information expands beyond a single block, a directory/attribute
+btree (``dabtree``) is created to map hashes of attribute names to entries
+for fast lookup.
+
+Salvaging extended attributes is done as follows:
+
+1. Walk the attr fork mappings of the file being repaired to find the attribute
+ leaf blocks.
+ When one is found,
+
+ a. Walk the attr leaf block to find candidate keys.
+ When one is found,
+
+ 1. Check the name for problems, and ignore the name if there are.
+
+ 2. Retrieve the value.
+ If that succeeds, add the name and value to the staging xfarray and
+ xfblob.
+
+2. If the memory usage of the xfarray and xfblob exceed a certain amount of
+ memory or there are no more attr fork blocks to examine, unlock the file and
+ add the staged extended attributes to the temporary file.
+
+3. Use atomic file mapping exchange to exchange the new and old extended
+ attribute structures.
+ The old attribute blocks are now attached to the temporary file.
+
+4. Reap the temporary file.
+
+Fixing Directories
+------------------
+
+Fixing directories is difficult with currently available filesystem features,
+since directory entries are not redundant.
+The offline repair tool scans all inodes to find files with nonzero link count,
+and then it scans all directories to establish parentage of those linked files.
+Damaged files and directories are zapped, and files with no parent are
+moved to the ``/lost+found`` directory.
+It does not try to salvage anything.
+
+The best that online repair can do at this time is to read directory data
+blocks and salvage any dirents that look plausible, correct link counts, and
+move orphans back into the directory tree.
+The salvage process is discussed in the case study at the end of this section.
+The :ref:`file link count fsck <nlinks>` code takes care of fixing link counts
+and moving orphans to the ``/lost+found`` directory.
+
+Case Study: Salvaging Directories
+`````````````````````````````````
+
+Unlike extended attributes, directory blocks are all the same size, so
+salvaging directories is straightforward:
+
+1. Find the parent of the directory.
+ If the dotdot entry is not unreadable, try to confirm that the alleged
+ parent has a child entry pointing back to the directory being repaired.
+ Otherwise, walk the filesystem to find it.
+
+2. Walk the first partition of data fork of the directory to find the directory
+ entry data blocks.
+ When one is found,
+
+ a. Walk the directory data block to find candidate entries.
+ When an entry is found:
+
+ i. Check the name for problems, and ignore the name if there are.
+
+ ii. Retrieve the inumber and grab the inode.
+ If that succeeds, add the name, inode number, and file type to the
+ staging xfarray and xblob.
+
+3. If the memory usage of the xfarray and xfblob exceed a certain amount of
+ memory or there are no more directory data blocks to examine, unlock the
+ directory and add the staged dirents into the temporary directory.
+ Truncate the staging files.
+
+4. Use atomic file mapping exchange to exchange the new and old directory
+ structures.
+ The old directory blocks are now attached to the temporary file.
+
+5. Reap the temporary file.
+
+**Future Work Question**: Should repair revalidate the dentry cache when
+rebuilding a directory?
+
+*Answer*: Yes, it should.
+
+In theory it is necessary to scan all dentry cache entries for a directory to
+ensure that one of the following apply:
+
+1. The cached dentry reflects an ondisk dirent in the new directory.
+
+2. The cached dentry no longer has a corresponding ondisk dirent in the new
+ directory and the dentry can be purged from the cache.
+
+3. The cached dentry no longer has an ondisk dirent but the dentry cannot be
+ purged.
+ This is the problem case.
+
+Unfortunately, the current dentry cache design doesn't provide a means to walk
+every child dentry of a specific directory, which makes this a hard problem.
+There is no known solution.
+
+Parent Pointers
+```````````````
+
+A parent pointer is a piece of file metadata that enables a user to locate the
+file's parent directory without having to traverse the directory tree from the
+root.
+Without them, reconstruction of directory trees is hindered in much the same
+way that the historic lack of reverse space mapping information once hindered
+reconstruction of filesystem space metadata.
+The parent pointer feature, however, makes total directory reconstruction
+possible.
+
+XFS parent pointers contain the information needed to identify the
+corresponding directory entry in the parent directory.
+In other words, child files use extended attributes to store pointers to
+parents in the form ``(dirent_name) → (parent_inum, parent_gen)``.
+The directory checking process can be strengthened to ensure that the target of
+each dirent also contains a parent pointer pointing back to the dirent.
+Likewise, each parent pointer can be checked by ensuring that the target of
+each parent pointer is a directory and that it contains a dirent matching
+the parent pointer.
+Both online and offline repair can use this strategy.
+
++--------------------------------------------------------------------------+
+| **Historical Sidebar**: |
++--------------------------------------------------------------------------+
+| Directory parent pointers were first proposed as an XFS feature more |
+| than a decade ago by SGI. |
+| Each link from a parent directory to a child file is mirrored with an |
+| extended attribute in the child that could be used to identify the |
+| parent directory. |
+| Unfortunately, this early implementation had major shortcomings and was |
+| never merged into Linux XFS: |
+| |
+| 1. The XFS codebase of the late 2000s did not have the infrastructure to |
+| enforce strong referential integrity in the directory tree. |
+| It did not guarantee that a change in a forward link would always be |
+| followed up with the corresponding change to the reverse links. |
+| |
+| 2. Referential integrity was not integrated into offline repair. |
+| Checking and repairs were performed on mounted filesystems without |
+| taking any kernel or inode locks to coordinate access. |
+| It is not clear how this actually worked properly. |
+| |
+| 3. The extended attribute did not record the name of the directory entry |
+| in the parent, so the SGI parent pointer implementation cannot be |
+| used to reconnect the directory tree. |
+| |
+| 4. Extended attribute forks only support 65,536 extents, which means |
+| that parent pointer attribute creation is likely to fail at some |
+| point before the maximum file link count is achieved. |
+| |
+| The original parent pointer design was too unstable for something like |
+| a file system repair to depend on. |
+| Allison Henderson, Chandan Babu, and Catherine Hoang are working on a |
+| second implementation that solves all shortcomings of the first. |
+| During 2022, Allison introduced log intent items to track physical |
+| manipulations of the extended attribute structures. |
+| This solves the referential integrity problem by making it possible to |
+| commit a dirent update and a parent pointer update in the same |
+| transaction. |
+| Chandan increased the maximum extent counts of both data and attribute |
+| forks, thereby ensuring that the extended attribute structure can grow |
+| to handle the maximum hardlink count of any file. |
+| |
+| For this second effort, the ondisk parent pointer format as originally |
+| proposed was ``(parent_inum, parent_gen, dirent_pos) → (dirent_name)``. |
+| The format was changed during development to eliminate the requirement |
+| of repair tools needing to ensure that the ``dirent_pos`` field always |
+| matched when reconstructing a directory. |
+| |
+| There were a few other ways to have solved that problem: |
+| |
+| 1. The field could be designated advisory, since the other three values |
+| are sufficient to find the entry in the parent. |
+| However, this makes indexed key lookup impossible while repairs are |
+| ongoing. |
+| |
+| 2. We could allow creating directory entries at specified offsets, which |
+| solves the referential integrity problem but runs the risk that |
+| dirent creation will fail due to conflicts with the free space in the |
+| directory. |
+| |
+| These conflicts could be resolved by appending the directory entry |
+| and amending the xattr code to support updating an xattr key and |
+| reindexing the dabtree, though this would have to be performed with |
+| the parent directory still locked. |
+| |
+| 3. Same as above, but remove the old parent pointer entry and add a new |
+| one atomically. |
+| |
+| 4. Change the ondisk xattr format to |
+| ``(parent_inum, name) → (parent_gen)``, which would provide the attr |
+| name uniqueness that we require, without forcing repair code to |
+| update the dirent position. |
+| Unfortunately, this requires changes to the xattr code to support |
+| attr names as long as 263 bytes. |
+| |
+| 5. Change the ondisk xattr format to ``(parent_inum, hash(name)) → |
+| (name, parent_gen)``. |
+| If the hash is sufficiently resistant to collisions (e.g. sha256) |
+| then this should provide the attr name uniqueness that we require. |
+| Names shorter than 247 bytes could be stored directly. |
+| |
+| 6. Change the ondisk xattr format to ``(dirent_name) → (parent_ino, |
+| parent_gen)``. This format doesn't require any of the complicated |
+| nested name hashing of the previous suggestions. However, it was |
+| discovered that multiple hardlinks to the same inode with the same |
+| filename caused performance problems with hashed xattr lookups, so |
+| the parent inumber is now xor'd into the hash index. |
+| |
+| In the end, it was decided that solution #6 was the most compact and the |
+| most performant. A new hash function was designed for parent pointers. |
++--------------------------------------------------------------------------+
+
+
+Case Study: Repairing Directories with Parent Pointers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Directory rebuilding uses a :ref:`coordinated inode scan <iscan>` and
+a :ref:`directory entry live update hook <liveupdate>` as follows:
+
+1. Set up a temporary directory for generating the new directory structure,
+ an xfblob for storing entry names, and an xfarray for stashing the fixed
+ size fields involved in a directory update: ``(child inumber, add vs.
+ remove, name cookie, ftype)``.
+
+2. Set up an inode scanner and hook into the directory entry code to receive
+ updates on directory operations.
+
+3. For each parent pointer found in each file scanned, decide if the parent
+ pointer references the directory of interest.
+ If so:
+
+ a. Stash the parent pointer name and an addname entry for this dirent in the
+ xfblob and xfarray, respectively.
+
+ b. When finished scanning that file or the kernel memory consumption exceeds
+ a threshold, flush the stashed updates to the temporary directory.
+
+4. For each live directory update received via the hook, decide if the child
+ has already been scanned.
+ If so:
+
+ a. Stash the parent pointer name an addname or removename entry for this
+ dirent update in the xfblob and xfarray for later.
+ We cannot write directly to the temporary directory because hook
+ functions are not allowed to modify filesystem metadata.
+ Instead, we stash updates in the xfarray and rely on the scanner thread
+ to apply the stashed updates to the temporary directory.
+
+5. When the scan is complete, replay any stashed entries in the xfarray.
+
+6. When the scan is complete, atomically exchange the contents of the temporary
+ directory and the directory being repaired.
+ The temporary directory now contains the damaged directory structure.
+
+7. Reap the temporary directory.
+
+Case Study: Repairing Parent Pointers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Online reconstruction of a file's parent pointer information works similarly to
+directory reconstruction:
+
+1. Set up a temporary file for generating a new extended attribute structure,
+ an xfblob for storing parent pointer names, and an xfarray for stashing the
+ fixed size fields involved in a parent pointer update: ``(parent inumber,
+ parent generation, add vs. remove, name cookie)``.
+
+2. Set up an inode scanner and hook into the directory entry code to receive
+ updates on directory operations.
+
+3. For each directory entry found in each directory scanned, decide if the
+ dirent references the file of interest.
+ If so:
+
+ a. Stash the dirent name and an addpptr entry for this parent pointer in the
+ xfblob and xfarray, respectively.
+
+ b. When finished scanning the directory or the kernel memory consumption
+ exceeds a threshold, flush the stashed updates to the temporary file.
+
+4. For each live directory update received via the hook, decide if the parent
+ has already been scanned.
+ If so:
+
+ a. Stash the dirent name and an addpptr or removepptr entry for this dirent
+ update in the xfblob and xfarray for later.
+ We cannot write parent pointers directly to the temporary file because
+ hook functions are not allowed to modify filesystem metadata.
+ Instead, we stash updates in the xfarray and rely on the scanner thread
+ to apply the stashed parent pointer updates to the temporary file.
+
+5. When the scan is complete, replay any stashed entries in the xfarray.
+
+6. Copy all non-parent pointer extended attributes to the temporary file.
+
+7. When the scan is complete, atomically exchange the mappings of the attribute
+ forks of the temporary file and the file being repaired.
+ The temporary file now contains the damaged extended attribute structure.
+
+8. Reap the temporary file.
+
+Digression: Offline Checking of Parent Pointers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Examining parent pointers in offline repair works differently because corrupt
+files are erased long before directory tree connectivity checks are performed.
+Parent pointer checks are therefore a second pass to be added to the existing
+connectivity checks:
+
+1. After the set of surviving files has been established (phase 6),
+ walk the surviving directories of each AG in the filesystem.
+ This is already performed as part of the connectivity checks.
+
+2. For each directory entry found,
+
+ a. If the name has already been stored in the xfblob, then use that cookie
+ and skip the next step.
+
+ b. Otherwise, record the name in an xfblob, and remember the xfblob cookie.
+ Unique mappings are critical for
+
+ 1. Deduplicating names to reduce memory usage, and
+
+ 2. Creating a stable sort key for the parent pointer indexes so that the
+ parent pointer validation described below will work.
+
+ c. Store ``(child_ag_inum, parent_inum, parent_gen, name_hash, name_len,
+ name_cookie)`` tuples in a per-AG in-memory slab. The ``name_hash``
+ referenced in this section is the regular directory entry name hash, not
+ the specialized one used for parent pointer xattrs.
+
+3. For each AG in the filesystem,
+
+ a. Sort the per-AG tuple set in order of ``child_ag_inum``, ``parent_inum``,
+ ``name_hash``, and ``name_cookie``.
+ Having a single ``name_cookie`` for each ``name`` is critical for
+ handling the uncommon case of a directory containing multiple hardlinks
+ to the same file where all the names hash to the same value.
+
+ b. For each inode in the AG,
+
+ 1. Scan the inode for parent pointers.
+ For each parent pointer found,
+
+ a. Validate the ondisk parent pointer.
+ If validation fails, move on to the next parent pointer in the
+ file.
+
+ b. If the name has already been stored in the xfblob, then use that
+ cookie and skip the next step.
+
+ c. Record the name in a per-file xfblob, and remember the xfblob
+ cookie.
+
+ d. Store ``(parent_inum, parent_gen, name_hash, name_len,
+ name_cookie)`` tuples in a per-file slab.
+
+ 2. Sort the per-file tuples in order of ``parent_inum``, ``name_hash``,
+ and ``name_cookie``.
+
+ 3. Position one slab cursor at the start of the inode's records in the
+ per-AG tuple slab.
+ This should be trivial since the per-AG tuples are in child inumber
+ order.
+
+ 4. Position a second slab cursor at the start of the per-file tuple slab.
+
+ 5. Iterate the two cursors in lockstep, comparing the ``parent_ino``,
+ ``name_hash``, and ``name_cookie`` fields of the records under each
+ cursor:
+
+ a. If the per-AG cursor is at a lower point in the keyspace than the
+ per-file cursor, then the per-AG cursor points to a missing parent
+ pointer.
+ Add the parent pointer to the inode and advance the per-AG
+ cursor.
+
+ b. If the per-file cursor is at a lower point in the keyspace than
+ the per-AG cursor, then the per-file cursor points to a dangling
+ parent pointer.
+ Remove the parent pointer from the inode and advance the per-file
+ cursor.
+
+ c. Otherwise, both cursors point at the same parent pointer.
+ Update the parent_gen component if necessary.
+ Advance both cursors.
+
+4. Move on to examining link counts, as we do today.
+
+Rebuilding directories from parent pointers in offline repair would be very
+challenging because xfs_repair currently uses two single-pass scans of the
+filesystem during phases 3 and 4 to decide which files are corrupt enough to be
+zapped.
+This scan would have to be converted into a multi-pass scan:
+
+1. The first pass of the scan zaps corrupt inodes, forks, and attributes
+ much as it does now.
+ Corrupt directories are noted but not zapped.
+
+2. The next pass records parent pointers pointing to the directories noted
+ as being corrupt in the first pass.
+ This second pass may have to happen after the phase 4 scan for duplicate
+ blocks, if phase 4 is also capable of zapping directories.
+
+3. The third pass resets corrupt directories to an empty shortform directory.
+ Free space metadata has not been ensured yet, so repair cannot yet use the
+ directory building code in libxfs.
+
+4. At the start of phase 6, space metadata have been rebuilt.
+ Use the parent pointer information recorded during step 2 to reconstruct
+ the dirents and add them to the now-empty directories.
+
+This code has not yet been constructed.
+
+.. _dirtree:
+
+Case Study: Directory Tree Structure
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As mentioned earlier, the filesystem directory tree is supposed to be a
+directed acylic graph structure.
+However, each node in this graph is a separate ``xfs_inode`` object with its
+own locks, which makes validating the tree qualities difficult.
+Fortunately, non-directories are allowed to have multiple parents and cannot
+have children, so only directories need to be scanned.
+Directories typically constitute 5-10% of the files in a filesystem, which
+reduces the amount of work dramatically.
+
+If the directory tree could be frozen, it would be easy to discover cycles and
+disconnected regions by running a depth (or breadth) first search downwards
+from the root directory and marking a bitmap for each directory found.
+At any point in the walk, trying to set an already set bit means there is a
+cycle.
+After the scan completes, XORing the marked inode bitmap with the inode
+allocation bitmap reveals disconnected inodes.
+However, one of online repair's design goals is to avoid locking the entire
+filesystem unless it's absolutely necessary.
+Directory tree updates can move subtrees across the scanner wavefront on a live
+filesystem, so the bitmap algorithm cannot be applied.
+
+Directory parent pointers enable an incremental approach to validation of the
+tree structure.
+Instead of using one thread to scan the entire filesystem, multiple threads can
+walk from individual subdirectories upwards towards the root.
+For this to work, all directory entries and parent pointers must be internally
+consistent, each directory entry must have a parent pointer, and the link
+counts of all directories must be correct.
+Each scanner thread must be able to take the IOLOCK of an alleged parent
+directory while holding the IOLOCK of the child directory to prevent either
+directory from being moved within the tree.
+This is not possible since the VFS does not take the IOLOCK of a child
+subdirectory when moving that subdirectory, so instead the scanner stabilizes
+the parent -> child relationship by taking the ILOCKs and installing a dirent
+update hook to detect changes.
+
+The scanning process uses a dirent hook to detect changes to the directories
+mentioned in the scan data.
+The scan works as follows:
+
+1. For each subdirectory in the filesystem,
+
+ a. For each parent pointer of that subdirectory,
+
+ 1. Create a path object for that parent pointer, and mark the
+ subdirectory inode number in the path object's bitmap.
+
+ 2. Record the parent pointer name and inode number in a path structure.
+
+ 3. If the alleged parent is the subdirectory being scrubbed, the path is
+ a cycle.
+ Mark the path for deletion and repeat step 1a with the next
+ subdirectory parent pointer.
+
+ 4. Try to mark the alleged parent inode number in a bitmap in the path
+ object.
+ If the bit is already set, then there is a cycle in the directory
+ tree.
+ Mark the path as a cycle and repeat step 1a with the next subdirectory
+ parent pointer.
+
+ 5. Load the alleged parent.
+ If the alleged parent is not a linked directory, abort the scan
+ because the parent pointer information is inconsistent.
+
+ 6. For each parent pointer of this alleged ancestor directory,
+
+ a. Record the parent pointer name and inode number in the path object
+ if no parent has been set for that level.
+
+ b. If an ancestor has more than one parent, mark the path as corrupt.
+ Repeat step 1a with the next subdirectory parent pointer.
+
+ c. Repeat steps 1a3-1a6 for the ancestor identified in step 1a6a.
+ This repeats until the directory tree root is reached or no parents
+ are found.
+
+ 7. If the walk terminates at the root directory, mark the path as ok.
+
+ 8. If the walk terminates without reaching the root, mark the path as
+ disconnected.
+
+2. If the directory entry update hook triggers, check all paths already found
+ by the scan.
+ If the entry matches part of a path, mark that path and the scan stale.
+ When the scanner thread sees that the scan has been marked stale, it deletes
+ all scan data and starts over.
+
+Repairing the directory tree works as follows:
+
+1. Walk each path of the target subdirectory.
+
+ a. Corrupt paths and cycle paths are counted as suspect.
+
+ b. Paths already marked for deletion are counted as bad.
+
+ c. Paths that reached the root are counted as good.
+
+2. If the subdirectory is either the root directory or has zero link count,
+ delete all incoming directory entries in the immediate parents.
+ Repairs are complete.
+
+3. If the subdirectory has exactly one path, set the dotdot entry to the
+ parent and exit.
+
+4. If the subdirectory has at least one good path, delete all the other
+ incoming directory entries in the immediate parents.
+
+5. If the subdirectory has no good paths and more than one suspect path, delete
+ all the other incoming directory entries in the immediate parents.
+
+6. If the subdirectory has zero paths, attach it to the lost and found.
+
+.. _orphanage:
+
+The Orphanage
+-------------
+
+Filesystems present files as a directed, and hopefully acyclic, graph.
+In other words, a tree.
+The root of the filesystem is a directory, and each entry in a directory points
+downwards either to more subdirectories or to non-directory files.
+Unfortunately, a disruption in the directory graph pointers result in a
+disconnected graph, which makes files impossible to access via regular path
+resolution.
+
+Without parent pointers, the directory parent pointer online scrub code can
+detect a dotdot entry pointing to a parent directory that doesn't have a link
+back to the child directory and the file link count checker can detect a file
+that isn't pointed to by any directory in the filesystem.
+If such a file has a positive link count, the file is an orphan.
+
+With parent pointers, directories can be rebuilt by scanning parent pointers
+and parent pointers can be rebuilt by scanning directories.
+This should reduce the incidence of files ending up in ``/lost+found``.
+
+When orphans are found, they should be reconnected to the directory tree.
+Offline fsck solves the problem by creating a directory ``/lost+found`` to
+serve as an orphanage, and linking orphan files into the orphanage by using the
+inumber as the name.
+Reparenting a file to the orphanage does not reset any of its permissions or
+ACLs.
+
+This process is more involved in the kernel than it is in userspace.
+The directory and file link count repair setup functions must use the regular
+VFS mechanisms to create the orphanage directory with all the necessary
+security attributes and dentry cache entries, just like a regular directory
+tree modification.
+
+Orphaned files are adopted by the orphanage as follows:
+
+1. Call ``xrep_orphanage_try_create`` at the start of the scrub setup function
+ to try to ensure that the lost and found directory actually exists.
+ This also attaches the orphanage directory to the scrub context.
+
+2. If the decision is made to reconnect a file, take the IOLOCK of both the
+ orphanage and the file being reattached.
+ The ``xrep_orphanage_iolock_two`` function follows the inode locking
+ strategy discussed earlier.
+
+3. Use ``xrep_adoption_trans_alloc`` to reserve resources to the repair
+ transaction.
+
+4. Call ``xrep_orphanage_compute_name`` to compute the new name in the
+ orphanage.
+
+5. If the adoption is going to happen, call ``xrep_adoption_reparent`` to
+ reparent the orphaned file into the lost and found and invalidate the dentry
+ cache.
+
+6. Call ``xrep_adoption_finish`` to commit any filesystem updates, release the
+ orphanage ILOCK, and clean the scrub transaction. Call
+ ``xrep_adoption_commit`` to commit the updates and the scrub transaction.
+
+7. If a runtime error happens, call ``xrep_adoption_cancel`` to release all
+ resources.
+
+6. Userspace Algorithms and Data Structures
+===========================================
+
+This section discusses the key algorithms and data structures of the userspace
+program, ``xfs_scrub``, that provide the ability to drive metadata checks and
+repairs in the kernel, verify file data, and look for other potential problems.
+
+.. _scrubcheck:
+
+Checking Metadata
+-----------------
+
+Recall the :ref:`phases of fsck work<scrubphases>` outlined earlier.
+That structure follows naturally from the data dependencies designed into the
+filesystem from its beginnings in 1993.
+In XFS, there are several groups of metadata dependencies:
+
+a. Filesystem summary counts depend on consistency within the inode indices,
+ the allocation group space btrees, and the realtime volume space
+ information.
+
+b. Quota resource counts depend on consistency within the quota file data
+ forks, inode indices, inode records, and the forks of every file on the
+ system.
+
+c. The naming hierarchy depends on consistency within the directory and
+ extended attribute structures.
+ This includes file link counts.
+
+d. Directories, extended attributes, and file data depend on consistency within
+ the file forks that map directory and extended attribute data to physical
+ storage media.
+
+e. The file forks depends on consistency within inode records and the space
+ metadata indices of the allocation groups and the realtime volume.
+ This includes quota and realtime metadata files.
+
+f. Inode records depends on consistency within the inode metadata indices.
+
+g. Realtime space metadata depend on the inode records and data forks of the
+ realtime metadata inodes.
+
+h. The allocation group metadata indices (free space, inodes, reference count,
+ and reverse mapping btrees) depend on consistency within the AG headers and
+ between all the AG metadata btrees.
+
+i. ``xfs_scrub`` depends on the filesystem being mounted and kernel support
+ for online fsck functionality.
+
+Therefore, a metadata dependency graph is a convenient way to schedule checking
+operations in the ``xfs_scrub`` program:
+
+- Phase 1 checks that the provided path maps to an XFS filesystem and detect
+ the kernel's scrubbing abilities, which validates group (i).
+
+- Phase 2 scrubs groups (g) and (h) in parallel using a threaded workqueue.
+
+- Phase 3 scans inodes in parallel.
+ For each inode, groups (f), (e), and (d) are checked, in that order.
+
+- Phase 4 repairs everything in groups (i) through (d) so that phases 5 and 6
+ may run reliably.
+
+- Phase 5 starts by checking groups (b) and (c) in parallel before moving on
+ to checking names.
+
+- Phase 6 depends on groups (i) through (b) to find file data blocks to verify,
+ to read them, and to report which blocks of which files are affected.
+
+- Phase 7 checks group (a), having validated everything else.
+
+Notice that the data dependencies between groups are enforced by the structure
+of the program flow.
+
+Parallel Inode Scans
+--------------------
+
+An XFS filesystem can easily contain hundreds of millions of inodes.
+Given that XFS targets installations with large high-performance storage,
+it is desirable to scrub inodes in parallel to minimize runtime, particularly
+if the program has been invoked manually from a command line.
+This requires careful scheduling to keep the threads as evenly loaded as
+possible.
+
+Early iterations of the ``xfs_scrub`` inode scanner naïvely created a single
+workqueue and scheduled a single workqueue item per AG.
+Each workqueue item walked the inode btree (with ``XFS_IOC_INUMBERS``) to find
+inode chunks and then called bulkstat (``XFS_IOC_BULKSTAT``) to gather enough
+information to construct file handles.
+The file handle was then passed to a function to generate scrub items for each
+metadata object of each inode.
+This simple algorithm leads to thread balancing problems in phase 3 if the
+filesystem contains one AG with a few large sparse files and the rest of the
+AGs contain many smaller files.
+The inode scan dispatch function was not sufficiently granular; it should have
+been dispatching at the level of individual inodes, or, to constrain memory
+consumption, inode btree records.
+
+Thanks to Dave Chinner, bounded workqueues in userspace enable ``xfs_scrub`` to
+avoid this problem with ease by adding a second workqueue.
+Just like before, the first workqueue is seeded with one workqueue item per AG,
+and it uses INUMBERS to find inode btree chunks.
+The second workqueue, however, is configured with an upper bound on the number
+of items that can be waiting to be run.
+Each inode btree chunk found by the first workqueue's workers are queued to the
+second workqueue, and it is this second workqueue that queries BULKSTAT,
+creates a file handle, and passes it to a function to generate scrub items for
+each metadata object of each inode.
+If the second workqueue is too full, the workqueue add function blocks the
+first workqueue's workers until the backlog eases.
+This doesn't completely solve the balancing problem, but reduces it enough to
+move on to more pressing issues.
+
+.. _scrubrepair:
+
+Scheduling Repairs
+------------------
+
+During phase 2, corruptions and inconsistencies reported in any AGI header or
+inode btree are repaired immediately, because phase 3 relies on proper
+functioning of the inode indices to find inodes to scan.
+Failed repairs are rescheduled to phase 4.
+Problems reported in any other space metadata are deferred to phase 4.
+Optimization opportunities are always deferred to phase 4, no matter their
+origin.
+
+During phase 3, corruptions and inconsistencies reported in any part of a
+file's metadata are repaired immediately if all space metadata were validated
+during phase 2.
+Repairs that fail or cannot be repaired immediately are scheduled for phase 4.
+
+In the original design of ``xfs_scrub``, it was thought that repairs would be
+so infrequent that the ``struct xfs_scrub_metadata`` objects used to
+communicate with the kernel could also be used as the primary object to
+schedule repairs.
+With recent increases in the number of optimizations possible for a given
+filesystem object, it became much more memory-efficient to track all eligible
+repairs for a given filesystem object with a single repair item.
+Each repair item represents a single lockable object -- AGs, metadata files,
+individual inodes, or a class of summary information.
+
+Phase 4 is responsible for scheduling a lot of repair work in as quick a
+manner as is practical.
+The :ref:`data dependencies <scrubcheck>` outlined earlier still apply, which
+means that ``xfs_scrub`` must try to complete the repair work scheduled by
+phase 2 before trying repair work scheduled by phase 3.
+The repair process is as follows:
+
+1. Start a round of repair with a workqueue and enough workers to keep the CPUs
+ as busy as the user desires.
+
+ a. For each repair item queued by phase 2,
+
+ i. Ask the kernel to repair everything listed in the repair item for a
+ given filesystem object.
+
+ ii. Make a note if the kernel made any progress in reducing the number
+ of repairs needed for this object.
+
+ iii. If the object no longer requires repairs, revalidate all metadata
+ associated with this object.
+ If the revalidation succeeds, drop the repair item.
+ If not, requeue the item for more repairs.
+
+ b. If any repairs were made, jump back to 1a to retry all the phase 2 items.
+
+ c. For each repair item queued by phase 3,
+
+ i. Ask the kernel to repair everything listed in the repair item for a
+ given filesystem object.
+
+ ii. Make a note if the kernel made any progress in reducing the number
+ of repairs needed for this object.
+
+ iii. If the object no longer requires repairs, revalidate all metadata
+ associated with this object.
+ If the revalidation succeeds, drop the repair item.
+ If not, requeue the item for more repairs.
+
+ d. If any repairs were made, jump back to 1c to retry all the phase 3 items.
+
+2. If step 1 made any repair progress of any kind, jump back to step 1 to start
+ another round of repair.
+
+3. If there are items left to repair, run them all serially one more time.
+ Complain if the repairs were not successful, since this is the last chance
+ to repair anything.
+
+Corruptions and inconsistencies encountered during phases 5 and 7 are repaired
+immediately.
+Corrupt file data blocks reported by phase 6 cannot be recovered by the
+filesystem.
+
+Checking Names for Confusable Unicode Sequences
+-----------------------------------------------
+
+If ``xfs_scrub`` succeeds in validating the filesystem metadata by the end of
+phase 4, it moves on to phase 5, which checks for suspicious looking names in
+the filesystem.
+These names consist of the filesystem label, names in directory entries, and
+the names of extended attributes.
+Like most Unix filesystems, XFS imposes the sparest of constraints on the
+contents of a name:
+
+- Slashes and null bytes are not allowed in directory entries.
+
+- Null bytes are not allowed in userspace-visible extended attributes.
+
+- Null bytes are not allowed in the filesystem label.
+
+Directory entries and attribute keys store the length of the name explicitly
+ondisk, which means that nulls are not name terminators.
+For this section, the term "naming domain" refers to any place where names are
+presented together -- all the names in a directory, or all the attributes of a
+file.
+
+Although the Unix naming constraints are very permissive, the reality of most
+modern-day Linux systems is that programs work with Unicode character code
+points to support international languages.
+These programs typically encode those code points in UTF-8 when interfacing
+with the C library because the kernel expects null-terminated names.
+In the common case, therefore, names found in an XFS filesystem are actually
+UTF-8 encoded Unicode data.
+
+To maximize its expressiveness, the Unicode standard defines separate control
+points for various characters that render similarly or identically in writing
+systems around the world.
+For example, the character "Cyrillic Small Letter A" U+0430 "а" often renders
+identically to "Latin Small Letter A" U+0061 "a".
+
+The standard also permits characters to be constructed in multiple ways --
+either by using a defined code point, or by combining one code point with
+various combining marks.
+For example, the character "Angstrom Sign U+212B "Å" can also be expressed
+as "Latin Capital Letter A" U+0041 "A" followed by "Combining Ring Above"
+U+030A "◌̊".
+Both sequences render identically.
+
+Like the standards that preceded it, Unicode also defines various control
+characters to alter the presentation of text.
+For example, the character "Right-to-Left Override" U+202E can trick some
+programs into rendering "moo\\xe2\\x80\\xaegnp.txt" as "mootxt.png".
+A second category of rendering problems involves whitespace characters.
+If the character "Zero Width Space" U+200B is encountered in a file name, the
+name will render identically to a name that does not have the zero width
+space.
+
+If two names within a naming domain have different byte sequences but render
+identically, a user may be confused by it.
+The kernel, in its indifference to upper level encoding schemes, permits this.
+Most filesystem drivers persist the byte sequence names that are given to them
+by the VFS.
+
+Techniques for detecting confusable names are explained in great detail in
+sections 4 and 5 of the
+`Unicode Security Mechanisms <https://unicode.org/reports/tr39/>`_
+document.
+When ``xfs_scrub`` detects UTF-8 encoding in use on a system, it uses the
+Unicode normalization form NFD in conjunction with the confusable name
+detection component of
+`libicu <https://github.com/unicode-org/icu>`_
+to identify names with a directory or within a file's extended attributes that
+could be confused for each other.
+Names are also checked for control characters, non-rendering characters, and
+mixing of bidirectional characters.
+All of these potential issues are reported to the system administrator during
+phase 5.
+
+Media Verification of File Data Extents
+---------------------------------------
+
+The system administrator can elect to initiate a media scan of all file data
+blocks.
+This scan after validation of all filesystem metadata (except for the summary
+counters) as phase 6.
+The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map
+to find areas that are allocated to file data fork extents.
+Gaps between data fork extents that are smaller than 64k are treated as if
+they were data fork extents to reduce the command setup overhead.
+When the space map scan accumulates a region larger than 32MB, a media
+verification request is sent to the disk as a directio read of the raw block
+device.
+
+If the verification read fails, ``xfs_scrub`` retries with single-block reads
+to narrow down the failure to the specific region of the media and recorded.
+When it has finished issuing verification requests, it again uses the space
+mapping ioctl to map the recorded media errors back to metadata structures
+and report what has been lost.
+For media errors in blocks owned by files, parent pointers can be used to
+construct file paths from inode numbers for user-friendly reporting.
+
+7. Conclusion and Future Work
+=============================
+
+It is hoped that the reader of this document has followed the designs laid out
+in this document and now has some familiarity with how XFS performs online
+rebuilding of its metadata indices, and how filesystem users can interact with
+that functionality.
+Although the scope of this work is daunting, it is hoped that this guide will
+make it easier for code readers to understand what has been built, for whom it
+has been built, and why.
+Please feel free to contact the XFS mailing list with questions.
+
+XFS_IOC_EXCHANGE_RANGE
+----------------------
+
+As discussed earlier, a second frontend to the atomic file mapping exchange
+mechanism is a new ioctl call that userspace programs can use to commit updates
+to files atomically.
+This frontend has been out for review for several years now, though the
+necessary refinements to online repair and lack of customer demand mean that
+the proposal has not been pushed very hard.
+
+File Content Exchanges with Regular User Files
+``````````````````````````````````````````````
+
+As mentioned earlier, XFS has long had the ability to swap extents between
+files, which is used almost exclusively by ``xfs_fsr`` to defragment files.
+The earliest form of this was the fork swap mechanism, where the entire
+contents of data forks could be exchanged between two files by exchanging the
+raw bytes in each inode fork's immediate area.
+When XFS v5 came along with self-describing metadata, this old mechanism grew
+some log support to continue rewriting the owner fields of BMBT blocks during
+log recovery.
+When the reverse mapping btree was later added to XFS, the only way to maintain
+the consistency of the fork mappings with the reverse mapping index was to
+develop an iterative mechanism that used deferred bmap and rmap operations to
+swap mappings one at a time.
+This mechanism is identical to steps 2-3 from the procedure above except for
+the new tracking items, because the atomic file mapping exchange mechanism is
+an iteration of an existing mechanism and not something totally novel.
+For the narrow case of file defragmentation, the file contents must be
+identical, so the recovery guarantees are not much of a gain.
+
+Atomic file content exchanges are much more flexible than the existing swapext
+implementations because it can guarantee that the caller never sees a mix of
+old and new contents even after a crash, and it can operate on two arbitrary
+file fork ranges.
+The extra flexibility enables several new use cases:
+
+- **Atomic commit of file writes**: A userspace process opens a file that it
+ wants to update.
+ Next, it opens a temporary file and calls the file clone operation to reflink
+ the first file's contents into the temporary file.
+ Writes to the original file should instead be written to the temporary file.
+ Finally, the process calls the atomic file mapping exchange system call
+ (``XFS_IOC_EXCHANGE_RANGE``) to exchange the file contents, thereby
+ committing all of the updates to the original file, or none of them.
+
+.. _exchrange_if_unchanged:
+
+- **Transactional file updates**: The same mechanism as above, but the caller
+ only wants the commit to occur if the original file's contents have not
+ changed.
+ To make this happen, the calling process snapshots the file modification and
+ change timestamps of the original file before reflinking its data to the
+ temporary file.
+ When the program is ready to commit the changes, it passes the timestamps
+ into the kernel as arguments to the atomic file mapping exchange system call.
+ The kernel only commits the changes if the provided timestamps match the
+ original file.
+ A new ioctl (``XFS_IOC_COMMIT_RANGE``) is provided to perform this.
+
+- **Emulation of atomic block device writes**: Export a block device with a
+ logical sector size matching the filesystem block size to force all writes
+ to be aligned to the filesystem block size.
+ Stage all writes to a temporary file, and when that is complete, call the
+ atomic file mapping exchange system call with a flag to indicate that holes
+ in the temporary file should be ignored.
+ This emulates an atomic device write in software, and can support arbitrary
+ scattered writes.
+
+(This functionality was merged into mainline as of 2025)
+
+Vectorized Scrub
+----------------
+
+As it turns out, the :ref:`refactoring <scrubrepair>` of repair items mentioned
+earlier was a catalyst for enabling a vectorized scrub system call.
+Since 2018, the cost of making a kernel call has increased considerably on some
+systems to mitigate the effects of speculative execution attacks.
+This incentivizes program authors to make as few system calls as possible to
+reduce the number of times an execution path crosses a security boundary.
+
+With vectorized scrub, userspace pushes to the kernel the identity of a
+filesystem object, a list of scrub types to run against that object, and a
+simple representation of the data dependencies between the selected scrub
+types.
+The kernel executes as much of the caller's plan as it can until it hits a
+dependency that cannot be satisfied due to a corruption, and tells userspace
+how much was accomplished.
+It is hoped that ``io_uring`` will pick up enough of this functionality that
+online fsck can use that instead of adding a separate vectored scrub system
+call to XFS.
+
+(This functionality was merged into mainline as of 2025)
+
+Quality of Service Targets for Scrub
+------------------------------------
+
+One serious shortcoming of the online fsck code is that the amount of time that
+it can spend in the kernel holding resource locks is basically unbounded.
+Userspace is allowed to send a fatal signal to the process which will cause
+``xfs_scrub`` to exit when it reaches a good stopping point, but there's no way
+for userspace to provide a time budget to the kernel.
+Given that the scrub codebase has helpers to detect fatal signals, it shouldn't
+be too much work to allow userspace to specify a timeout for a scrub/repair
+operation and abort the operation if it exceeds budget.
+However, most repair functions have the property that once they begin to touch
+ondisk metadata, the operation cannot be cancelled cleanly, after which a QoS
+timeout is no longer useful.
+
+Defragmenting Free Space
+------------------------
+
+Over the years, many XFS users have requested the creation of a program to
+clear a portion of the physical storage underlying a filesystem so that it
+becomes a contiguous chunk of free space.
+Call this free space defragmenter ``clearspace`` for short.
+
+The first piece the ``clearspace`` program needs is the ability to read the
+reverse mapping index from userspace.
+This already exists in the form of the ``FS_IOC_GETFSMAP`` ioctl.
+The second piece it needs is a new fallocate mode
+(``FALLOC_FL_MAP_FREE_SPACE``) that allocates the free space in a region and
+maps it to a file.
+Call this file the "space collector" file.
+The third piece is the ability to force an online repair.
+
+To clear all the metadata out of a portion of physical storage, clearspace
+uses the new fallocate map-freespace call to map any free space in that region
+to the space collector file.
+Next, clearspace finds all metadata blocks in that region by way of
+``GETFSMAP`` and issues forced repair requests on the data structure.
+This often results in the metadata being rebuilt somewhere that is not being
+cleared.
+After each relocation, clearspace calls the "map free space" function again to
+collect any newly freed space in the region being cleared.
+
+To clear all the file data out of a portion of the physical storage, clearspace
+uses the FSMAP information to find relevant file data blocks.
+Having identified a good target, it uses the ``FICLONERANGE`` call on that part
+of the file to try to share the physical space with a dummy file.
+Cloning the extent means that the original owners cannot overwrite the
+contents; any changes will be written somewhere else via copy-on-write.
+Clearspace makes its own copy of the frozen extent in an area that is not being
+cleared, and uses ``FIEDEUPRANGE`` (or the :ref:`atomic file content exchanges
+<exchrange_if_unchanged>` feature) to change the target file's data extent
+mapping away from the area being cleared.
+When all other mappings have been moved, clearspace reflinks the space into the
+space collector file so that it becomes unavailable.
+
+There are further optimizations that could apply to the above algorithm.
+To clear a piece of physical storage that has a high sharing factor, it is
+strongly desirable to retain this sharing factor.
+In fact, these extents should be moved first to maximize sharing factor after
+the operation completes.
+To make this work smoothly, clearspace needs a new ioctl
+(``FS_IOC_GETREFCOUNTS``) to report reference count information to userspace.
+With the refcount information exposed, clearspace can quickly find the longest,
+most shared data extents in the filesystem, and target them first.
+
+**Future Work Question**: How might the filesystem move inode chunks?
+
+*Answer*: To move inode chunks, Dave Chinner constructed a prototype program
+that creates a new file with the old contents and then locklessly runs around
+the filesystem updating directory entries.
+The operation cannot complete if the filesystem goes down.
+That problem isn't totally insurmountable: create an inode remapping table
+hidden behind a jump label, and a log item that tracks the kernel walking the
+filesystem to update directory entries.
+The trouble is, the kernel can't do anything about open files, since it cannot
+revoke them.
+
+**Future Work Question**: Can static keys be used to minimize the cost of
+supporting ``revoke()`` on XFS files?
+
+*Answer*: Yes.
+Until the first revocation, the bailout code need not be in the call path at
+all.
+
+The relevant patchsets are the
+`kernel freespace defrag
+<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=defrag-freespace>`_
+and
+`userspace freespace defrag
+<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=defrag-freespace>`_
+series.
+
+Shrinking Filesystems
+---------------------
+
+Removing the end of the filesystem ought to be a simple matter of evacuating
+the data and metadata at the end of the filesystem, and handing the freed space
+to the shrink code.
+That requires an evacuation of the space at end of the filesystem, which is a
+use of free space defragmentation!
diff --git a/Documentation/filesystems/xfs-self-describing-metadata.rst b/Documentation/filesystems/xfs/xfs-self-describing-metadata.rst
index b79dbf36dc94..a10c4ae6955e 100644
--- a/Documentation/filesystems/xfs-self-describing-metadata.rst
+++ b/Documentation/filesystems/xfs/xfs-self-describing-metadata.rst
@@ -1,4 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
+.. _xfs_self_describing_metadata:
============================
XFS Self Describing Metadata
diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst
index 394b9f15dce0..c22124c2213d 100644
--- a/Documentation/filesystems/zonefs.rst
+++ b/Documentation/filesystems/zonefs.rst
@@ -378,7 +378,7 @@ The attributes defined are as follows.
sequential zone files. Failure to do so can result in write errors.
* **max_active_seq_files**: This attribute reports the maximum number of
sequential zone files that are in an active state, that is, sequential zone
- files that are partially writen (not empty nor full) or that have a zone that
+ files that are partially written (not empty nor full) or that have a zone that
is explicitly open (which happens only if the *explicit-open* mount option is
used). This number is always equal to the maximum number of active zones that
the device supports. A value of 0 means that the mounted device has no limit
diff --git a/Documentation/firmware-guide/acpi/acpi-lid.rst b/Documentation/firmware-guide/acpi/acpi-lid.rst
index 71b9af13a048..03cbad6c6730 100644
--- a/Documentation/firmware-guide/acpi/acpi-lid.rst
+++ b/Documentation/firmware-guide/acpi/acpi-lid.rst
@@ -34,7 +34,7 @@ state upon the last _LID evaluation. There won't be difference when the
_LID control method is evaluated during the runtime, the problem is its
initial returning value. When the AML tables implement this control method
with cached value, the initial returning value is likely not reliable.
-There are platforms always retun "closed" as initial lid state.
+There are platforms always return "closed" as initial lid state.
Restrictions of the lid state change notifications
==================================================
diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst
index d6b61d22f525..7d8435d35a18 100644
--- a/Documentation/firmware-guide/acpi/apei/einj.rst
+++ b/Documentation/firmware-guide/acpi/apei/einj.rst
@@ -32,6 +32,10 @@ configuration::
CONFIG_ACPI_APEI
CONFIG_ACPI_APEI_EINJ
+...and to (optionally) enable CXL protocol error injection set::
+
+ CONFIG_ACPI_APEI_EINJ_CXL
+
The EINJ user interface is in <debugfs mount point>/apei/einj.
The following files belong to it:
@@ -55,6 +59,9 @@ The following files belong to it:
0x00000200 Platform Correctable
0x00000400 Platform Uncorrectable non-fatal
0x00000800 Platform Uncorrectable fatal
+ V2_0x00000001 EINJV2 Processor Error
+ V2_0x00000002 EINJV2 Memory Error
+ V2_0x00000004 EINJV2 PCI Express Error
================ ===================================
The format of the file contents are as above, except present are only
@@ -84,6 +91,8 @@ The following files belong to it:
Memory address and mask valid (param1 and param2).
Bit 2
PCIe (seg,bus,dev,fn) valid (see param4 below).
+ Bit 3
+ EINJv2 extension structure is valid
If set to zero, legacy behavior is mimicked where the type of
injection specifies just one bit set, and param1 is multiplexed.
@@ -118,6 +127,31 @@ The following files belong to it:
this actually works depends on what operations the BIOS actually
includes in the trigger phase.
+- component_id0 .. component_idN, component_syndrome0 .. component_syndromeN
+
+ These files are used to set the "Component Array" field
+ of the EINJv2 Extension Structure. Each holds a 128-bit
+ hex value. Writing just a newline to any of these files
+ sets an invalid (all-ones) value.
+
+CXL error types are supported from ACPI 6.5 onwards (given a CXL port
+is present). The EINJ user interface for CXL error types is at
+<debugfs mount point>/cxl. The following files belong to it:
+
+- einj_types:
+
+ Provides the same functionality as available_error_types above, but
+ for CXL error types
+
+- $dport_dev/einj_inject:
+
+ Injects a CXL error type into the CXL port represented by $dport_dev,
+ where $dport_dev is the name of the CXL port (usually a PCIe device name).
+ Error injections targeting a CXL 2.0+ port can use the legacy interface
+ under <debugfs mount point>/apei/einj, while CXL 1.1/1.0 port injections
+ must use this file.
+
+
BIOS versions based on the ACPI 4.0 specification have limited options
in controlling where the errors are injected. Your BIOS may support an
extension (enabled with the param_extension=1 module parameter, or boot
@@ -172,6 +206,27 @@ An error injection example::
# echo 0x8 > error_type # Choose correctable memory error
# echo 1 > error_inject # Inject now
+An EINJv2 error injection example::
+
+ # cd /sys/kernel/debug/apei/einj
+ # cat available_error_type # See which errors can be injected
+ 0x00000002 Processor Uncorrectable non-fatal
+ 0x00000008 Memory Correctable
+ 0x00000010 Memory Uncorrectable non-fatal
+ V2_0x00000001 EINJV2 Processor Error
+ V2_0x00000002 EINJV2 Memory Error
+
+ # echo 0x12345000 > param1 # Set memory address for injection
+ # echo 0xfffffffffffff000 > param2 # Range - anywhere in this page
+ # echo 0x1 > component_id0 # First device ID
+ # echo 0x4 > component_syndrome0 # First error syndrome
+ # echo 0x2 > component_id1 # Second device ID
+ # echo 0x4 > component_syndrome1 # Second error syndrome
+ # echo '' > component_id2 # Mark id2 invalid to terminate list
+ # echo V2_0x2 > error_type # Choose EINJv2 memory error
+ # echo 0xa > flags # set flags to indicate EINJv2
+ # echo 1 > error_inject # Inject now
+
You should see something like this in dmesg::
[22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR
@@ -181,6 +236,18 @@ You should see something like this in dmesg::
[22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0
[22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)
+A CXL error injection example with $dport_dev=0000:e0:01.1::
+
+ # cd /sys/kernel/debug/cxl/
+ # ls
+ 0000:e0:01.1 0000:0c:00.0
+ # cat einj_types # See which errors can be injected
+ 0x00008000 CXL.mem Protocol Correctable
+ 0x00010000 CXL.mem Protocol Uncorrectable non-fatal
+ 0x00020000 CXL.mem Protocol Uncorrectable fatal
+ # cd 0000:e0:01.1 # Navigate to dport to inject into
+ # echo 0x8000 > einj_inject # Inject error
+
Special notes for injection into SGX enclaves:
There may be a separate BIOS setup option to enable SGX injection.
diff --git a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst
index f37fc90ce340..89419e116413 100644
--- a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst
+++ b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst
@@ -5,9 +5,8 @@ Chrome OS ACPI Device
=====================
Hardware functionality specific to Chrome OS is exposed through a Chrome OS ACPI device.
-The plug and play ID of a Chrome OS ACPI device is GGL0001. GGL is a valid PNP ID of Google.
-PNP ID can be used with the ACPI devices according to the guidelines. The following ACPI
-objects are supported:
+The plug and play ID of a Chrome OS ACPI device is GGL0001 and the hardware ID is
+GOOG0016. The following ACPI objects are supported:
.. flat-table:: Supported ACPI Objects
:widths: 1 2
diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
index 8d8b53e96bcf..ccb4b153e6f2 100644
--- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
+++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
@@ -12,11 +12,14 @@ ACPI in general allows referring to device objects in the tree only.
Hierarchical data extension nodes may not be referred to directly, hence this
document defines a scheme to implement such references.
-A reference consist of the device object name followed by one or more
-hierarchical data extension [dsd-guide] keys. Specifically, the hierarchical
-data extension node which is referred to by the key shall lie directly under
-the parent object i.e. either the device object or another hierarchical data
-extension node.
+A reference to a _DSD hierarchical data node is a string consisting of a
+device object reference followed by a dot (".") and a relative path to a data
+node object. Do not use non-string references as this will produce a copy of
+the hierarchical data node, not a reference!
+
+The hierarchical data extension node which is referred to shall be located
+directly under its parent object i.e. either the device object or another
+hierarchical data extension node [dsd-guide].
The keys in the hierarchical data nodes shall consist of the name of the node,
"@" character and the number of the node in hexadecimal notation (without pre-
@@ -33,11 +36,9 @@ extension key.
Example
=======
-In the ASL snippet below, the "reference" _DSD property contains a
-device object reference to DEV0 and under that device object, a
-hierarchical data extension key "node@1" referring to the NOD1 object
-and lastly, a hierarchical data extension key "anothernode" referring to
-the ANOD object which is also the final target node of the reference.
+In the ASL snippet below, the "reference" _DSD property contains a string
+reference to a hierarchical data extension node ANOD under DEV0 under the parent
+of DEV1. ANOD is also the final target node of the reference.
::
Device (DEV0)
@@ -76,10 +77,7 @@ the ANOD object which is also the final target node of the reference.
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
- Package () {
- "reference", Package () {
- ^DEV0, "node@1", "anothernode"
- }
+ Package () { "reference", "^DEV0.ANOD" }
},
}
})
diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst
index b9dbfc73ed25..d6ae5ffa748c 100644
--- a/Documentation/firmware-guide/acpi/dsd/graph.rst
+++ b/Documentation/firmware-guide/acpi/dsd/graph.rst
@@ -66,12 +66,9 @@ of that port shall be zero. Similarly, if a port may only have a single
endpoint, the number of that endpoint shall be zero.
The endpoint reference uses property extension with "remote-endpoint" property
-name followed by a reference in the same package. Such references consist of
-the remote device reference, the first package entry of the port data extension
-reference under the device and finally the first package entry of the endpoint
-data extension reference under the port. Individual references thus appear as::
+name followed by a string reference in the same package. [data-node-ref]::
- Package() { device, "port@X", "endpoint@Y" }
+ "device.datanode"
In the above example, "X" is the number of the port and "Y" is the number of
the endpoint.
@@ -109,7 +106,7 @@ A simple example of this is show below::
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0 },
- Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } },
+ Package () { "remote-endpoint", "\\_SB.PCI0.ISP.EP40" },
}
})
}
@@ -141,7 +138,7 @@ A simple example of this is show below::
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0 },
- Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } },
+ Package () { "remote-endpoint", "\\_SB.PCI0.I2C2.CAM0.EP00" },
}
})
}
diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst
index 93db592c93c7..a97cd07d49be 100644
--- a/Documentation/firmware-guide/acpi/dsd/leds.rst
+++ b/Documentation/firmware-guide/acpi/dsd/leds.rst
@@ -15,11 +15,6 @@ Referring to LEDs in Device tree is documented in [video-interfaces], in
"flash-leds" property documentation. In short, LEDs are directly referred to by
using phandles.
-While Device tree allows referring to any node in the tree [devicetree], in
-ACPI references are limited to device nodes only [acpi]. For this reason using
-the same mechanism on ACPI is not possible. A mechanism to refer to non-device
-ACPI nodes is documented in [data-node-ref].
-
ACPI allows (as does DT) using integer arguments after the reference. A
combination of the LED driver device reference and an integer argument,
referring to the "reg" property of the relevant LED, is used to identify
@@ -74,7 +69,7 @@ omitted. ::
Package () {
Package () {
"flash-leds",
- Package () { ^LED, "led@0", ^LED, "led@1" },
+ Package () { "^LED.LED0", "^LED.LED1" },
}
}
})
diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index b9dc0c603f36..0165b09c0957 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -19,7 +19,7 @@ possible we decided to do following:
platform devices.
- Devices behind real busses where there is a connector resource
- are represented as struct spi_device or struct i2c_device. Note
+ are represented as struct spi_device or struct i2c_client. Note
that standard UARTs are not busses so there is no struct uart_device,
although some of them may be represented by struct serdev_device.
@@ -64,6 +64,49 @@ If the driver needs to perform more complex initialization like getting and
configuring GPIOs it can get its ACPI handle and extract this information
from ACPI tables.
+ACPI device objects
+===================
+
+Generally speaking, there are two categories of devices in a system in which
+ACPI is used as an interface between the platform firmware and the OS: Devices
+that can be discovered and enumerated natively, through a protocol defined for
+the specific bus that they are on (for example, configuration space in PCI),
+without the platform firmware assistance, and devices that need to be described
+by the platform firmware so that they can be discovered. Still, for any device
+known to the platform firmware, regardless of which category it falls into,
+there can be a corresponding ACPI device object in the ACPI Namespace in which
+case the Linux kernel will create a struct acpi_device object based on it for
+that device.
+
+Those struct acpi_device objects are never used for binding drivers to natively
+discoverable devices, because they are represented by other types of device
+objects (for example, struct pci_dev for PCI devices) that are bound to by
+device drivers (the corresponding struct acpi_device object is then used as
+an additional source of information on the configuration of the given device).
+Moreover, the core ACPI device enumeration code creates struct platform_device
+objects for the majority of devices that are discovered and enumerated with the
+help of the platform firmware and those platform device objects can be bound to
+by platform drivers in direct analogy with the natively enumerable devices
+case. Therefore it is logically inconsistent and so generally invalid to bind
+drivers to struct acpi_device objects, including drivers for devices that are
+discovered with the help of the platform firmware.
+
+Historically, ACPI drivers that bound directly to struct acpi_device objects
+were implemented for some devices enumerated with the help of the platform
+firmware, but this is not recommended for any new drivers. As explained above,
+platform device objects are created for those devices as a rule (with a few
+exceptions that are not relevant here) and so platform drivers should be used
+for handling them, even though the corresponding ACPI device objects are the
+only source of device configuration information in that case.
+
+For every device having a corresponding struct acpi_device object, the pointer
+to it is returned by the ACPI_COMPANION() macro, so it is always possible to
+get to the device configuration information stored in the ACPI device object
+this way. Accordingly, struct acpi_device can be regarded as a part of the
+interface between the kernel and the ACPI Namespace, whereas device objects of
+other types (for example, struct pci_dev or struct platform_device) are used
+for interacting with the rest of the system.
+
DMA support
===========
@@ -552,7 +595,7 @@ bridges/switches of the board.
For example, let's assume we have a system with a PCIe serial port, an
Exar XR17V3521, soldered on the main board. This UART chip also includes
-16 GPIOs and we want to add the property ``gpio-line-names`` [1] to these pins.
+16 GPIOs and we want to add the property ``gpio-line-names`` [1]_ to these pins.
In this case, the ``lspci`` output for this component is::
07:00.0 Serial controller: Exar Corp. XR17V3521 Dual PCIe UART (rev 03)
@@ -594,7 +637,7 @@ of the chipset bridge (also called "root port") with address::
Bus: 0 - Device: 14 - Function: 1
To find this information, it is necessary to disassemble the BIOS ACPI tables,
-in particular the DSDT (see also [2])::
+in particular the DSDT (see also [2]_)::
mkdir ~/tables/
cd ~/tables/
@@ -624,7 +667,7 @@ device::
}
... other definitions follow ...
-and the _ADR method [3] returns exactly the device/function couple that
+and the _ADR method [3]_ returns exactly the device/function couple that
we are looking for. With this information and analyzing the above ``lspci``
output (both the devices list and the devices tree), we can write the following
ACPI description for the Exar PCIe UART, also adding the list of its GPIO line
@@ -681,10 +724,10 @@ created analyzing the position of the Exar UART in the PCI bus topology.
References
==========
-[1] Documentation/firmware-guide/acpi/gpio-properties.rst
+.. [1] Documentation/firmware-guide/acpi/gpio-properties.rst
-[2] Documentation/admin-guide/acpi/initrd_table_override.rst
+.. [2] Documentation/admin-guide/acpi/initrd_table_override.rst
-[3] ACPI Specifications, Version 6.3 - Paragraph 6.1.1 _ADR Address)
+.. [3] ACPI Specifications, Version 6.3 - Paragraph 6.1.1 _ADR Address)
https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf,
referenced 2020-11-18
diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
index eaec732cc77c..a0983b4213ea 100644
--- a/Documentation/firmware-guide/acpi/gpio-properties.rst
+++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
@@ -6,7 +6,7 @@ _DSD Device Properties Related to GPIO
With the release of ACPI 5.1, the _DSD configuration object finally
allows names to be given to GPIOs (and other things as well) returned
-by _CRS. Previously, we were only able to use an integer index to find
+by _CRS. Previously we were only able to use an integer index to find
the corresponding GPIO, which is pretty error prone (it depends on
the _CRS output ordering, for example).
@@ -49,11 +49,11 @@ index
pin
Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low
- If 1, the GPIO is marked as active_low.
+ If 1, the GPIO is marked as active-low.
Since ACPI GpioIo() resource does not have a field saying whether it is
-active low or high, the "active_low" argument can be used here. Setting
-it to 1 marks the GPIO as active low.
+active-low or active-high, the "active_low" argument can be used here.
+Setting it to 1 marks the GPIO as active-low.
Note, active_low in _DSD does not make sense for GpioInt() resource and
must be 0. GpioInt() resource has its own means of defining it.
@@ -67,20 +67,33 @@ state of the output pin which driver should use during its initialization.
Linux tries to use common sense here and derives the state from the bias
and polarity settings. The table below shows the expectations:
-========= ============= ==============
-Pull Bias Polarity Requested...
-========= ============= ==============
-Implicit x AS IS (assumed firmware configured for us)
-Explicit x (no _DSD) as Pull Bias (Up == High, Down == Low),
- assuming non-active (Polarity = !Pull Bias)
-Down Low as low, assuming active
-Down High as low, assuming non-active
-Up Low as high, assuming non-active
-Up High as high, assuming active
-========= ============= ==============
-
-That said, for our above example the both GPIOs, since the bias setting
-is explicit and _DSD is present, will be treated as active with a high
++-------------+-------------+-----------------------------------------------+
+| Pull Bias | Polarity | Requested... |
++=============+=============+===============================================+
+| Implicit |
++-------------+-------------+-----------------------------------------------+
+| **Default** | x | AS IS (assumed firmware configured it for us) |
++-------------+-------------+-----------------------------------------------+
+| Explicit |
++-------------+-------------+-----------------------------------------------+
+| **None** | x | AS IS (assumed firmware configured it for us) |
+| | | with no Pull Bias |
++-------------+-------------+-----------------------------------------------+
+| **Up** | x (no _DSD) | |
+| +-------------+ as high, assuming non-active |
+| | Low | |
+| +-------------+-----------------------------------------------+
+| | High | as high, assuming active |
++-------------+-------------+-----------------------------------------------+
+| **Down** | x (no _DSD) | |
+| +-------------+ as low, assuming non-active |
+| | High | |
+| +-------------+-----------------------------------------------+
+| | Low | as low, assuming active |
++-------------+-------------+-----------------------------------------------+
+
+That said, for our above example, since the bias setting is explicit and
+_DSD is present, both GPIOs will be treated as active with a high
polarity and Linux will configure the pins in this state until a driver
reprograms them differently.
@@ -218,8 +231,8 @@ In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV,
available to the driver can be used to identify the device and that is supposed
to be sufficient to determine the meaning and purpose of all of the GPIO lines
listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words,
-the driver is supposed to know what to use the GpioIo()/GpioInt() resources for
-once it has identified the device. Having done that, it can simply assign names
+the driver is supposed to know what to use from the GpioIo()/GpioInt() resources
+for once it has identified the device. Having done that, it can simply assign names
to the GPIO lines it is going to use and provide the GPIO subsystem with a
mapping between those names and the ACPI GPIO resources corresponding to them.
@@ -239,9 +252,9 @@ question would look like this::
static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
- { "reset-gpios", &reset_gpio, 1 },
- { "shutdown-gpios", &shutdown_gpio, 1 },
- { }
+ { "reset-gpios", &reset_gpio, 1 },
+ { "shutdown-gpios", &shutdown_gpio, 1 },
+ { }
};
Next, the mapping table needs to be passed as the second argument to
@@ -257,7 +270,7 @@ Using the _CRS fallback
If a device does not have _DSD or the driver does not create ACPI GPIO
mapping, the Linux GPIO framework refuses to return any GPIOs. This is
-because the driver does not know what it actually gets. For example if we
+because the driver does not know what it actually gets. For example, if we
have a device like below::
Device (BTH)
@@ -279,7 +292,7 @@ The driver might expect to get the right GPIO when it does::
...error handling...
but since there is no way to know the mapping between "reset" and
-the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT).
+the GpioIo() in _CRS the desc will hold ERR_PTR(-ENOENT).
The driver author can solve this by passing the mapping explicitly
(this is the recommended way and it's documented in the above chapter).
@@ -305,15 +318,15 @@ Case 1::
desc = gpiod_get(dev, "non-null-connection-id", flags);
desc = gpiod_get_index(dev, "non-null-connection-id", index, flags);
+Case 1 assumes that corresponding ACPI device description must have
+defined device properties and will prevent from getting any GPIO resources
+otherwise.
+
Case 2::
desc = gpiod_get(dev, NULL, flags);
desc = gpiod_get_index(dev, NULL, index, flags);
-Case 1 assumes that corresponding ACPI device description must have
-defined device properties and will prevent to getting any GPIO resources
-otherwise.
-
Case 2 explicitly tells GPIO core to look for resources in _CRS.
Be aware that gpiod_get_index() in cases 1 and 2, assuming that there
diff --git a/Documentation/firmware-guide/acpi/i2c-muxes.rst b/Documentation/firmware-guide/acpi/i2c-muxes.rst
index 3a8997ccd7c4..96ef4012d78f 100644
--- a/Documentation/firmware-guide/acpi/i2c-muxes.rst
+++ b/Documentation/firmware-guide/acpi/i2c-muxes.rst
@@ -14,7 +14,7 @@ Consider this topology::
| | | 0x70 |--CH01--> i2c client B (0x50)
+------+ +------+
-which corresponds to the following ASL::
+which corresponds to the following ASL (in the scope of \_SB)::
Device (SMB1)
{
@@ -24,7 +24,7 @@ which corresponds to the following ASL::
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
- AddressingMode7Bit, "^SMB1", 0x00,
+ AddressingMode7Bit, "\\_SB.SMB1", 0x00,
ResourceConsumer,,)
}
@@ -37,8 +37,8 @@ which corresponds to the following ASL::
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
- AddressingMode7Bit, "^CH00", 0x00,
- ResourceConsumer,,)
+ AddressingMode7Bit, "\\_SB.SMB1.MUX0.CH00",
+ 0x00, ResourceConsumer,,)
}
}
}
@@ -52,8 +52,8 @@ which corresponds to the following ASL::
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
- AddressingMode7Bit, "^CH01", 0x00,
- ResourceConsumer,,)
+ AddressingMode7Bit, "\\_SB.SMB1.MUX0.CH01",
+ 0x00, ResourceConsumer,,)
}
}
}
diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
index b6a42f4ffe03..b246902f523f 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -14,7 +14,6 @@ ACPI Support
dsd/phy
enumeration
osi
- method-customizing
method-tracing
DSD-properties-rules
debug
diff --git a/Documentation/firmware-guide/acpi/method-customizing.rst b/Documentation/firmware-guide/acpi/method-customizing.rst
deleted file mode 100644
index de3ebcaed4cf..000000000000
--- a/Documentation/firmware-guide/acpi/method-customizing.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=======================================
-Linux ACPI Custom Control Method How To
-=======================================
-
-:Author: Zhang Rui <rui.zhang@intel.com>
-
-
-Linux supports customizing ACPI control methods at runtime.
-
-Users can use this to:
-
-1. override an existing method which may not work correctly,
- or just for debugging purposes.
-2. insert a completely new method in order to create a missing
- method such as _OFF, _ON, _STA, _INI, etc.
-
-For these cases, it is far simpler to dynamically install a single
-control method rather than override the entire DSDT, because kernel
-rebuild/reboot is not needed and test result can be got in minutes.
-
-.. note::
-
- - Only ACPI METHOD can be overridden, any other object types like
- "Device", "OperationRegion", are not recognized. Methods
- declared inside scope operators are also not supported.
-
- - The same ACPI control method can be overridden for many times,
- and it's always the latest one that used by Linux/kernel.
-
- - To get the ACPI debug object output (Store (AAAA, Debug)),
- please run::
-
- echo 1 > /sys/module/acpi/parameters/aml_debug_output
-
-
-1. override an existing method
-==============================
-a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT,
- just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat"
-b) disassemble the table by running "iasl -d dsdt.dat".
-c) rewrite the ASL code of the method and save it in a new file,
-d) package the new file (psr.asl) to an ACPI table format.
- Here is an example of a customized \_SB._AC._PSR method::
-
- DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
- {
- Method (\_SB_.AC._PSR, 0, NotSerialized)
- {
- Store ("In AC _PSR", Debug)
- Return (ACON)
- }
- }
-
- Note that the full pathname of the method in ACPI namespace
- should be used.
-e) assemble the file to generate the AML code of the method.
- e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result)
- If parameter "-vw 6084" is not supported by your iASL compiler,
- please try a newer version.
-f) mount debugfs by "mount -t debugfs none /sys/kernel/debug"
-g) override the old method via the debugfs by running
- "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method"
-
-2. insert a new method
-======================
-This is easier than overriding an existing method.
-We just need to create the ASL code of the method we want to
-insert and then follow the step c) ~ g) in section 1.
-
-3. undo your changes
-====================
-The "undo" operation is not supported for a new inserted method
-right now, i.e. we can not remove a method currently.
-For an overridden method, in order to undo your changes, please
-save a copy of the method original ASL code in step c) section 1,
-and redo step c) ~ g) to override the method with the original one.
-
-
-.. note:: We can use a kernel with multiple custom ACPI method running,
- But each individual write to debugfs can implement a SINGLE
- method override. i.e. if we want to insert/override multiple
- ACPI methods, we need to redo step c) ~ g) for multiple times.
-
-.. note:: Be aware that root can mis-use this driver to modify arbitrary
- memory and gain additional rights, if root's privileges got
- restricted (for example if root is not allowed to load additional
- modules after boot).
diff --git a/Documentation/firmware-guide/acpi/namespace.rst b/Documentation/firmware-guide/acpi/namespace.rst
index 6193582a2204..5021843b526b 100644
--- a/Documentation/firmware-guide/acpi/namespace.rst
+++ b/Documentation/firmware-guide/acpi/namespace.rst
@@ -15,7 +15,7 @@ ACPI Device Tree - Representation of ACPI Namespace
Abstract
========
The Linux ACPI subsystem converts ACPI namespace objects into a Linux
-device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
+device tree under the /sys/devices/LNXSYSTM:00 and updates it upon
receiving ACPI hotplug notification events. For each device object
in this hierarchy there is a corresponding symbolic link in the
/sys/bus/acpi/devices.
@@ -31,7 +31,7 @@ Description Table). The XSDT always points to the FADT (Fixed ACPI
Description Table) using its first entry, the data within the FADT
includes various fixed-length entries that describe fixed ACPI features
of the hardware. The FADT contains a pointer to the DSDT
-(Differentiated System Descripition Table). The XSDT also contains
+(Differentiated System Description Table). The XSDT also contains
entries pointing to possibly multiple SSDTs (Secondary System
Description Table).
@@ -326,7 +326,7 @@ example ACPI namespace illustrated in Figure 2 with the addition of
fixed PWR_BUTTON/SLP_BUTTON devices is shown below::
+--------------+---+-----------------+
- | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
+ | LNXSYSTM:00 | \ | acpi:LNXSYSTM: |
+--------------+---+-----------------+
|
| +-------------+-----+----------------+
diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst
index 784850adfcb6..868a0a40bb76 100644
--- a/Documentation/firmware-guide/acpi/osi.rst
+++ b/Documentation/firmware-guide/acpi/osi.rst
@@ -55,7 +55,7 @@ quirk, a bug, or a bug-fix.
However this was discovered to be abused by other BIOS vendors to change
completely unrelated code on completely unrelated systems. This prompted
-an evaluation of all of it's uses. This uncovered that they aren't needed
+an evaluation of all of its uses. This uncovered that they aren't needed
for any of the original reasons. As such, the kernel will not respond to
any custom Linux-* strings by default.
diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 15b670926084..80255e2dc3e6 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -75,6 +75,125 @@ convenient for software to locate each feature by walking through this list,
and can be implemented in register regions of any FPGA device.
+Device Feature Header - Version 0
+=================================
+Version 0 (DFHv0) is the original version of the Device Feature Header.
+All multi-byte quantities in DFHv0 are little-endian.
+The format of DFHv0 is shown below::
+
+ +-----------------------------------------------------------------------+
+ |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
+ +-----------------------------------------------------------------------+
+ |63 GUID_L 0| 0x08
+ +-----------------------------------------------------------------------+
+ |63 GUID_H 0| 0x10
+ +-----------------------------------------------------------------------+
+
+- Offset 0x00
+
+ * Type - The type of DFH (e.g. FME, AFU, or private feature).
+ * DFH VER - The version of the DFH.
+ * Rsvd - Currently unused.
+ * EOL - Set if the DFH is the end of the Device Feature List (DFL).
+ * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
+ and the start of a DFH must be aligned to an 8 byte boundary.
+ If EOL is set, Next is the size of MMIO of the last feature in the list.
+ * REV - The revision of the feature associated with this header.
+ * ID - The feature ID if Type is private feature.
+
+- Offset 0x08
+
+ * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier
+ (present only if Type is FME or AFU).
+
+- Offset 0x10
+
+ * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier
+ (present only if Type is FME or AFU).
+
+
+Device Feature Header - Version 1
+=================================
+Version 1 (DFHv1) of the Device Feature Header adds the following functionality:
+
+* Provides a standardized mechanism for features to describe
+ parameters/capabilities to software.
+* Standardize the use of a GUID for all DFHv1 types.
+* Decouples the DFH location from the register space of the feature itself.
+
+All multi-byte quantities in DFHv1 are little-endian.
+The format of Version 1 of the Device Feature Header (DFH) is shown below::
+
+ +-----------------------------------------------------------------------+
+ |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 REV 12|11 ID 0| 0x00
+ +-----------------------------------------------------------------------+
+ |63 GUID_L 0| 0x08
+ +-----------------------------------------------------------------------+
+ |63 GUID_H 0| 0x10
+ +-----------------------------------------------------------------------+
+ |63 Reg Address/Offset 1| Rel 0| 0x18
+ +-----------------------------------------------------------------------+
+ |63 Reg Size 32|Params 31|30 Group 16|15 Instance 0| 0x20
+ +-----------------------------------------------------------------------+
+ |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0| 0x28
+ +-----------------------------------------------------------------------+
+ |63 Parameter Data 0| 0x30
+ +-----------------------------------------------------------------------+
+
+ ...
+
+ +-----------------------------------------------------------------------+
+ |63 Next 35|34RSV33|EOP32|31 Param Version 16|15 Param ID 0|
+ +-----------------------------------------------------------------------+
+ |63 Parameter Data 0|
+ +-----------------------------------------------------------------------+
+
+- Offset 0x00
+
+ * Type - The type of DFH (e.g. FME, AFU, or private feature).
+ * DFH VER - The version of the DFH.
+ * Rsvd - Currently unused.
+ * EOL - Set if the DFH is the end of the Device Feature List (DFL).
+ * Next - The offset in bytes of the next DFH in the DFL from the DFH start,
+ and the start of a DFH must be aligned to an 8 byte boundary.
+ If EOL is set, Next is the size of MMIO of the last feature in the list.
+ * REV - The revision of the feature associated with this header.
+ * ID - The feature ID if Type is private feature.
+
+- Offset 0x08
+
+ * GUID_L - Least significant 64 bits of a 128-bit Globally Unique Identifier.
+
+- Offset 0x10
+
+ * GUID_H - Most significant 64 bits of a 128-bit Globally Unique Identifier.
+
+- Offset 0x18
+
+ * Reg Address/Offset - If Rel bit is set, then the value is the high 63 bits
+ of a 16-bit aligned absolute address of the feature's registers. Otherwise
+ the value is the offset from the start of the DFH of the feature's registers.
+
+- Offset 0x20
+
+ * Reg Size - Size of feature's register set in bytes.
+ * Params - Set if DFH has a list of parameter blocks.
+ * Group - Id of group if feature is part of a group.
+ * Instance - Id of feature instance within a group.
+
+- Offset 0x28 if feature has parameters
+
+ * Next - Offset to the next parameter block in 8 byte words. If EOP set,
+ size in 8 byte words of last parameter.
+ * Param Version - Version of Param ID.
+ * Param ID - ID of parameter.
+
+- Offset 0x30
+
+ * Parameter Data - Parameter data whose size and format is defined by
+ version and ID of the parameter.
+
+
FIU - FME (FPGA Management Engine)
==================================
The FPGA Management Engine performs reconfiguration and other infrastructure
diff --git a/Documentation/fpga/index.rst b/Documentation/fpga/index.rst
index f80f95667ca2..43c968871d99 100644
--- a/Documentation/fpga/index.rst
+++ b/Documentation/fpga/index.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
====
-fpga
+FPGA
====
.. toctree::
diff --git a/Documentation/gpu/amdgpu/amd-hardware-list-info.rst b/Documentation/gpu/amdgpu/amd-hardware-list-info.rst
new file mode 100644
index 000000000000..e72f4ff770c4
--- /dev/null
+++ b/Documentation/gpu/amdgpu/amd-hardware-list-info.rst
@@ -0,0 +1,23 @@
+=================================================
+ AMD Hardware Components Information per Product
+=================================================
+
+On this page, you can find the AMD product name and which component version is
+part of it.
+
+Accelerated Processing Units (APU) Info
+---------------------------------------
+
+.. csv-table::
+ :header-rows: 1
+ :widths: 3, 2, 2, 1, 1, 1, 1, 1
+ :file: ./apu-asic-info-table.csv
+
+Discrete GPU Info
+-----------------
+
+.. csv-table::
+ :header-rows: 1
+ :widths: 3, 2, 2, 1, 1, 1, 1, 1
+ :file: ./dgpu-asic-info-table.csv
+
diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst
index 326896e9800d..30812d9d53c6 100644
--- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst
+++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst
@@ -12,15 +12,39 @@ we have a dedicated glossary for Display Core at
The number of CUs that are active on the system. The number of active
CUs may be less than SE * SH * CU depending on the board configuration.
+ BACO
+ Bus Alive, Chip Off
+
+ BOCO
+ Bus Off, Chip Off
+
+ CE
+ Constant Engine
+
+ CIK
+ Sea Islands
+
+ CB
+ Color Buffer
+
CP
Command Processor
CPLIB
Content Protection Library
+ CS
+ Command Submission
+
+ CSB
+ Clear State Indirect Buffer
+
CU
Compute Unit
+ DB
+ Depth Buffer
+
DFS
Digital Frequency Synthesizer
@@ -30,12 +54,44 @@ we have a dedicated glossary for Display Core at
EOP
End Of Pipe/Pipeline
+ FLR
+ Function Level Reset
+
+ GART
+ Graphics Address Remapping Table. This is the name we use for the GPUVM
+ page table used by the GPU kernel driver. It remaps system resources
+ (memory or MMIO space) into the GPU's address space so the GPU can access
+ them. The name GART harkens back to the days of AGP when the platform
+ provided an MMU that the GPU could use to get a contiguous view of
+ scattered pages for DMA. The MMU has since moved on to the GPU, but the
+ name stuck.
+
GC
Graphics and Compute
+ GDS
+ Global Data Share
+
+ GE
+ Geometry Engine
+
GMC
Graphic Memory Controller
+ GPUVM
+ GPU Virtual Memory. This is the GPU's MMU. The GPU supports multiple
+ virtual address spaces that can be in flight at any given time. These
+ allow the GPU to remap VRAM and system resources into GPU virtual address
+ spaces for use by the GPU kernel driver and applications using the GPU.
+ These provide memory protection for different applications using the GPU.
+
+ GTT
+ Graphics Translation Tables. This is a memory pool managed through TTM
+ which provides access to system resources (memory or MMIO space) for
+ use by the GPU. These addresses can be mapped into the "GART" GPUVM page
+ table for use by the kernel driver or into per process GPUVM page tables
+ for application usage.
+
IH
Interrupt Handler
@@ -45,18 +101,33 @@ we have a dedicated glossary for Display Core at
IB
Indirect Buffer
+ IMU
+ Integrated Management Unit (Power Management support)
+
IP
Intellectual Property blocks
KCQ
Kernel Compute Queue
+ KFD
+ Kernel Fusion Driver
+
KGQ
Kernel Graphics Queue
KIQ
Kernel Interface Queue
+ MC
+ Memory Controller
+
+ MCBP
+ Mid Command Buffer Preemption
+
+ ME
+ MicroEngine (Graphics)
+
MEC
MicroEngine Compute
@@ -69,14 +140,29 @@ we have a dedicated glossary for Display Core at
MQD
Memory Queue Descriptor
+ PA
+ Primitive Assembler / Physical Address
+
+ PFP
+ Pre-Fetch Parser (Graphics)
+
PPLib
PowerPlay Library - PowerPlay is the power management component.
PSP
Platform Security Processor
+ RB
+ Render Backends. Some people called it ROPs.
+
RLC
- RunList Controller
+ RunList Controller. This name is a remnant of past ages and doesn't have
+ much meaning today. It's a group of general-purpose helper engines for
+ the GFX block. It's involved in GFX power management and SR-IOV, among
+ other things.
+
+ SC
+ Scan Converter
SDMA
System DMA
@@ -84,17 +170,68 @@ we have a dedicated glossary for Display Core at
SE
Shader Engine
+ SGPR
+ Scalar General-Purpose Registers
+
SH
SHader array
- SMU
- System Management Unit
+ SI
+ Southern Islands
+
+ SMU/SMC
+ System Management Unit / System Management Controller
+
+ SPI (AMDGPU)
+ Shader Processor Input
+
+ SRLC
+ Save/Restore List Control
+
+ SRLG
+ Save/Restore List GPM_MEM
+
+ SRLS
+ Save/Restore List SRM_MEM
SS
Spread Spectrum
+ SX
+ Shader Export
+
+ TA
+ Trusted Application
+
+ TC
+ Texture Cache
+
+ TOC
+ Table of Contents
+
+ UMSCH
+ User Mode Scheduler
+
+ UVD
+ Unified Video Decoder
+
VCE
Video Compression Engine
VCN
Video Codec Next
+
+ VGPR
+ Vector General-Purpose Registers
+
+ VMID
+ Virtual Memory ID
+
+ VPE
+ Video Processing Engine
+
+ XCC
+ Accelerator Core Complex
+
+ XCP
+ Accelerator Core Partition
diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv
index 98c6988e424e..dee5f663a47f 100644
--- a/Documentation/gpu/amdgpu/apu-asic-info-table.csv
+++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv
@@ -1,8 +1,18 @@
-Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN version, SDMA version
-Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3
-Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0
-Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2
-Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1
-SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1
-Ryzen 5000 series, GREEN SARDINE, DCN 2.1, 9.3, VCN 2.2, 4.1.1
-Ryzen 6000 Zen, YELLOW CARP, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3
+Product Name, Code Reference, DCN/DCE version, GC version, VCE/UVD/VCN version, SDMA version, MP0 version, MP1 version
+Radeon R* Graphics, CARRIZO/STONEY, DCE 11, 8, VCE 3 / UVD 6, 3, n/a, 8
+Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN/PICASSO, DCN 1.0, 9.1.0, VCN 1.0, 4.1.0, 10.0.0, 10.0.0
+Ryzen 4000 series, RENOIR, DCN 2.1, 9.3, VCN 2.2, 4.1.2, 11.0.3, 12.0.1
+Ryzen 3000 series / AMD Ryzen Embedded V1*/R1* with Radeon Vega Gfx, RAVEN2, DCN 1.0, 9.2.2, VCN 1.0.1, 4.1.1, 10.0.1, 10.0.1
+SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1, 11.5.0, 11.5.0
+Ryzen 5000 series / Ryzen 7x30 series, GREEN SARDINE / Cezanne / Barcelo / Barcelo-R, DCN 2.1, 9.3, VCN 2.2, 4.1.1, 12.0.1, 12.0.1
+Ryzen 6000 series / Ryzen 7x35 series / Ryzen 7x36 series, YELLOW CARP / Rembrandt / Rembrandt-R, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3, 13.0.3
+Ryzen 7000 series (AM5), Raphael, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5, 13.0.5
+Ryzen 9000 series (AM5), Granite Ridge, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5, 13.0.5
+Ryzen 7x45 series (FL1), Dragon Range, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5, 13.0.5
+Ryzen 7x20 series, Mendocino, 3.1.6, 10.3.7, 3.1.1, 5.2.7, 13.0.8, 13.0.8
+Ryzen 7x40 series, Phoenix, 3.1.4, 11.0.1 / 11.0.4, 4.0.2, 6.0.1, 13.0.4 / 13.0.11, 13.0.4 / 13.0.11
+Ryzen 8x40 series, Hawk Point, 3.1.4, 11.0.1 / 11.0.4, 4.0.2, 6.0.1, 13.0.4 / 13.0.11, 13.0.4 / 13.0.11
+Ryzen AI 300 series, Strix Point, 3.5.0, 11.5.0, 4.0.5, 6.1.0, 14.0.0, 14.0.0
+Ryzen AI 330 series, Krackan Point, 3.6.0, 11.5.3, 4.0.5, 6.1.3, 14.0.5, 14.0.5
+Ryzen AI 350 series, Krackan Point, 3.5.0, 11.5.2, 4.0.5, 6.1.2, 14.0.4, 14.0.4
+Ryzen AI Max 300 series, Strix Halo, 3.5.1, 11.5.1, 4.0.6, 6.1.1, 14.0.1, 14.0.1
diff --git a/Documentation/gpu/amdgpu/debugfs.rst b/Documentation/gpu/amdgpu/debugfs.rst
new file mode 100644
index 000000000000..151d8bfc79e2
--- /dev/null
+++ b/Documentation/gpu/amdgpu/debugfs.rst
@@ -0,0 +1,210 @@
+==============
+AMDGPU DebugFS
+==============
+
+The amdgpu driver provides a number of debugfs files to aid in debugging
+issues in the driver. These are usually found in
+/sys/kernel/debug/dri/<num>.
+
+DebugFS Files
+=============
+
+amdgpu_benchmark
+----------------
+
+Run benchmarks using the DMA engine the driver uses for GPU memory paging.
+Write a number to the file to run the test. The results are written to the
+kernel log. VRAM is on device memory (dGPUs) or carve out (APUs) and GTT
+(Graphics Translation Tables) is system memory that is accessible by the GPU.
+The following tests are available:
+
+- 1: simple test, VRAM to GTT and GTT to VRAM
+- 2: simple test, VRAM to VRAM
+- 3: GTT to VRAM, buffer size sweep, powers of 2
+- 4: VRAM to GTT, buffer size sweep, powers of 2
+- 5: VRAM to VRAM, buffer size sweep, powers of 2
+- 6: GTT to VRAM, buffer size sweep, common display sizes
+- 7: VRAM to GTT, buffer size sweep, common display sizes
+- 8: VRAM to VRAM, buffer size sweep, common display sizes
+
+amdgpu_test_ib
+--------------
+
+Read this file to run simple IB (Indirect Buffer) tests on all kernel managed
+rings. IBs are command buffers usually generated by userspace applications
+which are submitted to the kernel for execution on an particular GPU engine.
+This just runs the simple IB tests included in the kernel. These tests
+are engine specific and verify that IB submission works.
+
+amdgpu_discovery
+----------------
+
+Provides raw access to the IP discovery binary provided by the GPU. Read this
+file to access the raw binary. This is useful for verifying the contents of
+the IP discovery table. It is chip specific.
+
+amdgpu_vbios
+------------
+
+Provides raw access to the ROM binary image from the GPU. Read this file to
+access the raw binary. This is useful for verifying the contents of the
+video BIOS ROM. It is board specific.
+
+amdgpu_evict_gtt
+----------------
+
+Evict all buffers from the GTT memory pool. Read this file to evict all
+buffers from this pool.
+
+amdgpu_evict_vram
+-----------------
+
+Evict all buffers from the VRAM memory pool. Read this file to evict all
+buffers from this pool.
+
+amdgpu_gpu_recover
+------------------
+
+Trigger a GPU reset. Read this file to trigger reset the entire GPU.
+All work currently running on the GPU will be lost.
+
+amdgpu_ring_<name>
+------------------
+
+Provides read access to the kernel managed ring buffers for each ring <name>.
+These are useful for debugging problems on a particular ring. The ring buffer
+is how the CPU sends commands to the GPU. The CPU writes commands into the
+buffer and then asks the GPU engine to process it. This is the raw binary
+contents of the ring buffer. Use a tool like UMR to decode the rings into human
+readable form.
+
+amdgpu_mqd_<name>
+-----------------
+
+Provides read access to the kernel managed MQD (Memory Queue Descriptor) for
+ring <name> managed by the kernel driver. MQDs define the features of the ring
+and are used to store the ring's state when it is not connected to hardware.
+The driver writes the requested ring features and metadata (GPU addresses of
+the ring itself and associated buffers) to the MQD and the firmware uses the MQD
+to populate the hardware when the ring is mapped to a hardware slot. Only
+available on engines which use MQDs. This provides access to the raw MQD
+binary.
+
+amdgpu_error_<name>
+-------------------
+
+Provides an interface to set an error code on the dma fences associated with
+ring <name>. The error code specified is propagated to all fences associated
+with the ring. Use this to inject a fence error into a ring.
+
+amdgpu_pm_info
+--------------
+
+Provides human readable information about the power management features
+and state of the GPU. This includes current GFX clock, Memory clock,
+voltages, average SoC power, temperature, GFX load, Memory load, SMU
+feature mask, VCN power state, clock and power gating features.
+
+amdgpu_firmware_info
+--------------------
+
+Lists the firmware versions for all firmwares used by the GPU. Only
+entries with a non-0 version are valid. If the version is 0, the firmware
+is not valid for the GPU.
+
+amdgpu_fence_info
+-----------------
+
+Shows the last signalled and emitted fence sequence numbers for each
+kernel driver managed ring. Fences are associated with submissions
+to the engine. Emitted fences have been submitted to the ring
+and signalled fences have been signalled by the GPU. Rings with a
+larger emitted fence value have outstanding work that is still being
+processed by the engine that owns that ring. When the emitted and
+signalled fence values are equal, the ring is idle.
+
+amdgpu_gem_info
+---------------
+
+Lists all of the PIDs using the GPU and the GPU buffers that they have
+allocated. This lists the buffer size, pool (VRAM, GTT, etc.), and buffer
+attributes (CPU access required, CPU cache attributes, etc.).
+
+amdgpu_vm_info
+--------------
+
+Lists all of the PIDs using the GPU and the GPU buffers that they have
+allocated as well as the status of those buffers relative to that process'
+GPU virtual address space (e.g., evicted, idle, invalidated, etc.).
+
+amdgpu_sa_info
+--------------
+
+Prints out all of the suballocations (sa) by the suballocation manager in the
+kernel driver. Prints the GPU address, size, and fence info associated
+with each suballocation. The suballocations are used internally within
+the kernel driver for various things.
+
+amdgpu_<pool>_mm
+----------------
+
+Prints TTM information about the memory pool <pool>.
+
+amdgpu_vram
+-----------
+
+Provides direct access to VRAM. Used by tools like UMR to inspect
+objects in VRAM.
+
+amdgpu_iomem
+------------
+
+Provides direct access to GTT memory. Used by tools like UMR to inspect
+GTT memory.
+
+amdgpu_regs_*
+-------------
+
+Provides direct access to various register apertures on the GPU. Used
+by tools like UMR to access GPU registers.
+
+amdgpu_regs2
+------------
+
+Provides an IOCTL interface used by UMR for interacting with GPU registers.
+
+
+amdgpu_sensors
+--------------
+
+Provides an interface to query GPU power metrics (temperature, average
+power, etc.). Used by tools like UMR to query GPU power metrics.
+
+
+amdgpu_gca_config
+-----------------
+
+Provides an interface to query GPU details (Graphics/Compute Array config,
+PCI config, GPU family, etc.). Used by tools like UMR to query GPU details.
+
+amdgpu_wave
+-----------
+
+Used to query GFX/compute wave information from the hardware. Used by tools
+like UMR to query GFX/compute wave information.
+
+amdgpu_gpr
+----------
+
+Used to query GFX/compute GPR (General Purpose Register) information from the
+hardware. Used by tools like UMR to query GPRs when debugging shaders.
+
+amdgpu_gprwave
+--------------
+
+Provides an IOCTL interface used by UMR for interacting with shader waves.
+
+amdgpu_fw_attestation
+---------------------
+
+Provides an interface for reading back firmware attestation records.
diff --git a/Documentation/gpu/amdgpu/debugging.rst b/Documentation/gpu/amdgpu/debugging.rst
new file mode 100644
index 000000000000..ac914d524741
--- /dev/null
+++ b/Documentation/gpu/amdgpu/debugging.rst
@@ -0,0 +1,105 @@
+===============
+ GPU Debugging
+===============
+
+General Debugging Options
+=========================
+
+The DebugFS section provides documentation on a number files to aid in debugging
+issues on the GPU.
+
+
+GPUVM Debugging
+===============
+
+To aid in debugging GPU virtual memory related problems, the driver supports a
+number of options module parameters:
+
+`vm_fault_stop` - If non-0, halt the GPU memory controller on a GPU page fault.
+
+`vm_update_mode` - If non-0, use the CPU to update GPU page tables rather than
+the GPU.
+
+
+Decoding a GPUVM Page Fault
+===========================
+
+If you see a GPU page fault in the kernel log, you can decode it to figure
+out what is going wrong in your application. A page fault in your kernel
+log may look something like this:
+
+::
+
+ [gfxhub0] no-retry page fault (src_id:0 ring:24 vmid:3 pasid:32777, for process glxinfo pid 2424 thread glxinfo:cs0 pid 2425)
+ in page starting at address 0x0000800102800000 from IH client 0x1b (UTCL2)
+ VM_L2_PROTECTION_FAULT_STATUS:0x00301030
+ Faulty UTCL2 client ID: TCP (0x8)
+ MORE_FAULTS: 0x0
+ WALKER_ERROR: 0x0
+ PERMISSION_FAULTS: 0x3
+ MAPPING_ERROR: 0x0
+ RW: 0x0
+
+First you have the memory hub, gfxhub and mmhub. gfxhub is the memory
+hub used for graphics, compute, and sdma on some chips. mmhub is the
+memory hub used for multi-media and sdma on some chips.
+
+Next you have the vmid and pasid. If the vmid is 0, this fault was likely
+caused by the kernel driver or firmware. If the vmid is non-0, it is generally
+a fault in a user application. The pasid is used to link a vmid to a system
+process id. If the process is active when the fault happens, the process
+information will be printed.
+
+The GPU virtual address that caused the fault comes next.
+
+The client ID indicates the GPU block that caused the fault.
+Some common client IDs:
+
+- CB/DB: The color/depth backend of the graphics pipe
+- CPF: Command Processor Frontend
+- CPC: Command Processor Compute
+- CPG: Command Processor Graphics
+- TCP/SQC/SQG: Shaders
+- SDMA: SDMA engines
+- VCN: Video encode/decode engines
+- JPEG: JPEG engines
+
+PERMISSION_FAULTS describe what faults were encountered:
+
+- bit 0: the PTE was not valid
+- bit 1: the PTE read bit was not set
+- bit 2: the PTE write bit was not set
+- bit 3: the PTE execute bit was not set
+
+Finally, RW, indicates whether the access was a read (0) or a write (1).
+
+In the example above, a shader (cliend id = TCP) generated a read (RW = 0x0) to
+an invalid page (PERMISSION_FAULTS = 0x3) at GPU virtual address
+0x0000800102800000. The user can then inspect their shader code and resource
+descriptor state to determine what caused the GPU page fault.
+
+UMR
+===
+
+`umr <https://gitlab.freedesktop.org/tomstdenis/umr>`_ is a general purpose
+GPU debugging and diagnostics tool. Please see the umr
+`documentation <https://umr.readthedocs.io/en/main/>`_ for more information
+about its capabilities.
+
+Debugging backlight brightness
+==============================
+Default backlight brightness is intended to be set via the policy advertised
+by the firmware. Firmware will often provide different defaults for AC or DC.
+Furthermore, some userspace software will save backlight brightness during
+the previous boot and attempt to restore it.
+
+Some firmware also has support for a feature called "Custom Backlight Curves"
+where an input value for brightness is mapped along a linearly interpolated
+curve of brightness values that better match display characteristics.
+
+In the event of problems happening with backlight, there is a trace event
+that can be enabled at bootup to log every brightness change request.
+This can help isolate where the problem is. To enable the trace event add
+the following to the kernel command line:
+
+ tp_printk trace_event=amdgpu_dm:amdgpu_dm_brightness:mod:amdgpu trace_buf_size=1M
diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv
index 84617aa35dab..bfd44c6e052a 100644
--- a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv
+++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv
@@ -1,24 +1,30 @@
-Product Name, Code Reference, DCN/DCE version, GC version, VCN version, SDMA version
-AMD Radeon (TM) HD 8500M/ 8600M /M200 /M320 /M330 /M335 Series, HAINAN, --, 6, --, --
-AMD Radeon HD 7800 /7900 /FireGL Series, TAHITI, DCE 6, 6, VCE 1 / UVD 3, --
-AMD Radeon R7 (TM|HD) M265 /M370 /8500M /8600 /8700 /8700M, OLAND, DCE 6, 6, VCE 1 / UVD 3, --
-AMD Radeon (TM) (HD|R7) 7800 /7970 /8800 /8970 /370/ Series, PITCAIRN, DCE 6, 6, VCE 1 / UVD 3, --
-AMD Radeon (TM|R7|R9|HD) E8860 /M360 /7700 /7800 /8800 /9000(M) /W4100 Series, VERDE, DCE 6, 6, VCE 1 / UVD 3, --
-AMD Radeon HD M280X /M380 /7700 /8950 /W5100, BONAIRE, DCE 8, 7, VCE 2 / UVD 4.2, 1
-AMD Radeon (R9|TM) 200 /390 /W8100 /W9100 Series, HAWAII, DCE 8, 7, VCE 2 / UVD 4.2, 1
-AMD Radeon (TM) R(5|7) M315 /M340 /M360, TOPAZ, *, 8, --, 2
-AMD Radeon (TM) R9 200 /380 /W7100 /S7150 /M390 /M395 Series, TONGA, DCE 10, 8, VCE 3 / UVD 5, 3
-AMD Radeon (FirePro) (TM) R9 Fury Series, FIJI, DCE 10, 8, VCE 3 / UVD 6, 3
-Radeon RX 470 /480 /570 /580 /590 Series - AMD Radeon (TM) (Pro WX) 5100 /E9390 /E9560 /E9565 /V7350 /7100 /P30PH, POLARIS10, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3
-Radeon (TM) (RX|Pro WX) E9260 /460 /V5300X /550 /560(X) Series, POLARIS11, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3
-Radeon (RX/Pro) 500 /540(X) /550 /640 /WX2100 /WX3100 /WX200 Series, POLARIS12, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3
-Radeon (RX|TM) (PRO|WX) Vega /MI25 /V320 /V340L /8200 /9100 /SSG MxGPU, VEGA10, DCE 12, 9.0.1, VCE 4.0.0 / UVD 7.0.0, 4.0.0
-AMD Radeon (Pro) VII /MI50 /MI60, VEGA20, DCE 12, 9.4.0, VCE 4.1.0 / UVD 7.2.0, 4.2.0
-MI100, ARCTURUS, *, 9.4.1, VCN 2.5.0, 4.2.2
-MI200, ALDEBARAN, *, 9.4.2, VCN 2.6.0, 4.4.0
-AMD Radeon (RX|Pro) 5600(M|XT) /5700 (M|XT|XTB) /W5700, NAVI10, DCN 2.0.0, 10.1.10, VCN 2.0.0, 5.0.0
-AMD Radeon (Pro) 5300 /5500XTB/5500(XT|M) /W5500M /W5500, NAVI14, DCN 2.0.0, 10.1.1, VCN 2.0.2, 5.0.2
-AMD Radeon RX 6800(XT) /6900(XT) /W6800, SIENNA_CICHLID, DCN 3.0.0, 10.3.0, VCN 3.0.0, 5.2.0
-AMD Radeon RX 6700 XT / 6800M / 6700M, NAVY_FLOUNDER, DCN 3.0.0, 10.3.2, VCN 3.0.0, 5.2.2
-AMD Radeon RX 6600(XT) /6600M /W6600 /W6600M, DIMGREY_CAVEFISH, DCN 3.0.2, 10.3.4, VCN 3.0.16, 5.2.4
-AMD Radeon RX 6500M /6300M /W6500M /W6300M, BEIGE_GOBY, DCN 3.0.3, 10.3.5, VCN 3.0.33, 5.2.5
+Product Name, Code Reference, DCN/DCE version, GC version, VCN version, SDMA version, MP0 version, MP1 version
+AMD Radeon (TM) HD 8500M/ 8600M /M200 /M320 /M330 /M335 Series, HAINAN, --, 6, --, --, --, 6
+AMD Radeon HD 7800 /7900 /FireGL Series, TAHITI, DCE 6, 6, VCE 1 / UVD 3, --, --, 6
+AMD Radeon R7 (TM|HD) M265 /M370 /8500M /8600 /8700 /8700M, OLAND, DCE 6, 6, -- / UVD 3, --, --, 6
+AMD Radeon (TM) (HD|R7) 7800 /7970 /8800 /8970 /370/ Series, PITCAIRN, DCE 6, 6, VCE 1 / UVD 3, --, --, 6
+AMD Radeon (TM|R7|R9|HD) E8860 /M360 /7700 /7800 /8800 /9000(M) /W4100 Series, VERDE, DCE 6, 6, VCE 1 / UVD 3, --, --, 6
+AMD Radeon HD M280X /M380 /7700 /8950 /W5100, BONAIRE, DCE 8, 7, VCE 2 / UVD 4.2, 1, --, 7
+AMD Radeon (R9|TM) 200 /390 /W8100 /W9100 Series, HAWAII, DCE 8, 7, VCE 2 / UVD 4.2, 1, --, 7
+AMD Radeon (TM) R(5|7) M315 /M340 /M360, TOPAZ, *, 8, --, 2, n/a, 7
+AMD Radeon (TM) R9 200 /380 /W7100 /S7150 /M390 /M395 Series, TONGA, DCE 10, 8, VCE 3 / UVD 5, 3, n/a, 7
+AMD Radeon (FirePro) (TM) R9 Fury Series, FIJI, DCE 10, 8, VCE 3 / UVD 6, 3, n/a, 7
+Radeon RX 470 /480 /570 /580 /590 Series - AMD Radeon (TM) (Pro WX) 5100 /E9390 /E9560 /E9565 /V7350 /7100 /P30PH, POLARIS10, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3, n/a, 7
+Radeon (TM) (RX|Pro WX) E9260 /460 /V5300X /550 /560(X) Series, POLARIS11, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3, n/a, 7
+Radeon (RX/Pro) 500 /540(X) /550 /640 /WX2100 /WX3100 /WX200 Series, POLARIS12, DCE 11.2, 8, VCE 3.4 / UVD 6.3, 3, n/a, 7
+Radeon (RX|TM) (PRO|WX) Vega /MI25 /V320 /V340L /8200 /9100 /SSG MxGPU, VEGA10, DCE 12, 9.0.1, VCE 4.0.0 / UVD 7.0.0, 4.0.0, 9.0.0, 9.0.0
+AMD Radeon (Pro) VII /MI50 /MI60, VEGA20, DCE 12, 9.4.0, VCE 4.1.0 / UVD 7.2.0, 4.2.0, 11.0.2, 11.0.2
+MI100, ARCTURUS, *, 9.4.1, VCN 2.5.0, 4.2.2, 11.0.4, 11.0.2
+MI200 Series, ALDEBARAN, *, 9.4.2, VCN 2.6.0, 4.4.0, 13.0.2, 13.0.2
+MI300 Series, AQUA_VANJARAM, *, 9.4.3, VCN 4.0.3, 4.4.2, 13.0.6, 13.0.6
+AMD Radeon (RX|Pro) 5600(M|XT) /5700 (M|XT|XTB) /W5700, NAVI10, DCN 2.0.0, 10.1.10, VCN 2.0.0, 5.0.0, 11.0.0, 11.0.0
+AMD Radeon (Pro) 5300 /5500XTB/5500(XT|M) /W5500M /W5500, NAVI14, DCN 2.0.0, 10.1.1, VCN 2.0.2, 5.0.2, 11.0.5, 11.0.5
+AMD Radeon RX 6800(XT) /6900(XT) /W6800, SIENNA_CICHLID, DCN 3.0.0, 10.3.0, VCN 3.0.0, 5.2.0, 11.0.7, 11.0.7
+AMD Radeon RX 6700 XT / 6800M / 6700M, NAVY_FLOUNDER, DCN 3.0.0, 10.3.2, VCN 3.0.0, 5.2.2, 11.0.11, 11.0.11
+AMD Radeon RX 6600(XT) /6600M /W6600 /W6600M, DIMGREY_CAVEFISH, DCN 3.0.2, 10.3.4, VCN 3.0.16, 5.2.4, 11.0.12, 11.0.12
+AMD Radeon RX 6500M /6300M /W6500M /W6300M, BEIGE_GOBY, DCN 3.0.3, 10.3.5, VCN 3.0.33, 5.2.5, 11.0.13, 11.0.13
+AMD Radeon RX 7900 XT /XTX, , DCN 3.2.0, 11.0.0, VCN 4.0.0, 6.0.0, 13.0.0, 13.0.0
+AMD Radeon RX 7800 XT, , DCN 3.2.0, 11.0.3, VCN 4.0.0, 6.0.3, 13.0.10, 13.0.10
+AMD Radeon RX 7600M (XT) /7700S /7600S, , DCN 3.2.1, 11.0.2, VCN 4.0.4, 6.0.2, 13.0.7, 13.0.7
+AMD Radeon RX 9070 (XT), , DCN 4.0.1, 12.0.1, VCN 5.0.0, 7.0.1, 14.0.3, 14.0.3
+AMD Radeon RX 9060 XT, , DCN 4.0.1, 12.0.0, VCN 5.0.0, 7.0.0, 14.0.2, 14.0.2
diff --git a/Documentation/gpu/amdgpu/display/dc-arch-overview.svg b/Documentation/gpu/amdgpu/display/dc-arch-overview.svg
new file mode 100644
index 000000000000..23394931cf26
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dc-arch-overview.svg
@@ -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>
diff --git a/Documentation/gpu/amdgpu/display/dc-components.svg b/Documentation/gpu/amdgpu/display/dc-components.svg
new file mode 100644
index 000000000000..f84bb2a57c05
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dc-components.svg
@@ -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>
diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst
index 40c55a618918..605dca21f4ae 100644
--- a/Documentation/gpu/amdgpu/display/dc-debug.rst
+++ b/Documentation/gpu/amdgpu/display/dc-debug.rst
@@ -2,6 +2,181 @@
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 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
======================
@@ -75,3 +250,56 @@ change in real-time by using something like::
When reporting a bug related to DC, consider attaching this log before and
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
+===================
+
+Sometimes, dmesg logs aren't enough. This is especially true if a feature is
+implemented primarily in DMUB firmware. In such cases, all we see in dmesg when
+an issue arises is some generic timeout error. So, to get more relevant
+information, we can trace DMUB commands by enabling the relevant bits in
+`amdgpu_dm_dmub_trace_mask`.
+
+Currently, we support the tracing of the following groups:
+
+Trace Groups
+------------
+
+.. csv-table::
+ :header-rows: 1
+ :widths: 1, 1
+ :file: ./trace-groups-table.csv
+
+**Note: Not all ASICs support all of the listed trace groups**
+
+So, to enable just PSR tracing you can use the following command::
+
+ # echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask
+
+Then, you need to enable logging trace events to the buffer, which you can do
+using the following::
+
+ # echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
+
+Lastly, after you are able to reproduce the issue you are trying to debug,
+you can disable tracing and read the trace log by using the following::
+
+ # echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
+ # cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer
+
+So, when reporting bugs related to features such as PSR and ABM, consider
+enabling the relevant bits in the mask before reproducing the issue and
+attach the log that you obtain from the trace buffer in any bug reports that you
+create.
diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst b/Documentation/gpu/amdgpu/display/dc-glossary.rst
index 0b0ffd428dd2..cbe737d1fcea 100644
--- a/Documentation/gpu/amdgpu/display/dc-glossary.rst
+++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst
@@ -5,7 +5,7 @@ DC Glossary
On this page, we try to keep track of acronyms related to the display
component. If you do not find what you are looking for, look at the
'Documentation/gpu/amdgpu/amdgpu-glossary.rst'; if you cannot find it anywhere,
-consider asking in the amdgfx and update this page.
+consider asking on the amd-gfx mailing list and update this page.
.. glossary::
@@ -167,9 +167,6 @@ consider asking in the amdgfx and update this page.
MALL
Memory Access at Last Level
- MC
- Memory Controller
-
MPC/MPCC
Multiple pipes and plane combine
@@ -232,6 +229,3 @@ consider asking in the amdgfx and update this page.
VRR
Variable Refresh Rate
-
- UVD
- Unified Video Decoder
diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst
new file mode 100644
index 000000000000..756957128dad
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst
@@ -0,0 +1,57 @@
+.. _dcn_blocks:
+
+==========
+DCN Blocks
+==========
+
+In this section, you will find some extra details about some of the DCN blocks
+and the code documentation when it is automatically generated.
+
+DCHUBBUB
+--------
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h
+ :doc: overview
+
+HUBP
+----
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
+ :doc: overview
+
+DPP
+---
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+ :internal:
+
+MPC
+---
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+ :internal:
+ :no-identifiers: mpcc_blnd_cfg mpcc_alpha_blend_mode
+
+OPP
+---
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h
+ :internal:
+
+DIO
+---
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.c
+ :internal:
diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst
index 9fea6500448b..eb54a6802e04 100644
--- a/Documentation/gpu/amdgpu/display/dcn-overview.rst
+++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst
@@ -1,3 +1,5 @@
+.. _dcn_overview:
+
=======================
Display Core Next (DCN)
=======================
diff --git a/Documentation/gpu/amdgpu/display/display-contributing.rst b/Documentation/gpu/amdgpu/display/display-contributing.rst
new file mode 100644
index 000000000000..2f741c52dce5
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/display-contributing.rst
@@ -0,0 +1,168 @@
+.. _display_todos:
+
+==============================
+AMDGPU - Display Contributions
+==============================
+
+First of all, if you are here, you probably want to give some technical
+contribution to the display code, and for that, we say thank you :)
+
+This page summarizes some of the issues you can help with; keep in mind that
+this is a static page, and it is always a good idea to try to reach developers
+on the amd-gfx mailing list or some of the maintainers. Finally, this page
+follows the DRM way of creating a TODO list; for more information, check
+'Documentation/gpu/todo.rst'.
+
+Gitlab issues
+=============
+
+Users can report issues associated with AMD GPUs at:
+
+- https://gitlab.freedesktop.org/drm/amd
+
+Usually, we try to add a proper label to all new tickets to make it easy to
+filter issues. If you can reproduce any problem, you could help by adding more
+information or fixing the issue.
+
+Level: diverse
+
+IGT
+===
+
+`IGT`_ provides many integration tests that can be run on your GPU. We always
+want to pass a large set of tests to increase the test coverage in our CI. If
+you wish to contribute to the display code but are unsure where a good place
+is, we recommend you run all IGT tests and try to fix any failure you see in
+your hardware. Keep in mind that this failure can be an IGT problem or a kernel
+issue; it is necessary to analyze case-by-case.
+
+Level: diverse
+
+.. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools
+
+Compilation
+===========
+
+Fix compilation warnings
+------------------------
+
+Enable the W1 or W2 warning level in the kernel compilation and try to fix the
+issues on the display side.
+
+Level: Starter
+
+Fix compilation issues when using um architecture
+-------------------------------------------------
+
+Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to
+the **um** architecture. Compiling for **um** can bring multiple advantages
+from the test perspective. We currently have some compilation issues in this
+area that we need to fix.
+
+Level: Intermediate
+
+Code Refactor
+=============
+
+Add prefix to DC functions to improve the debug with ftrace
+-----------------------------------------------------------
+
+The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a
+fantastic way to check the code path when developers try to make sense of a
+bug. Ftrace provides a filter mechanism that can be useful when the developer
+has some hunch of which part of the code can cause the issue; for this reason,
+if a set of functions has a proper prefix, it becomes easy to create a good
+filter. Additionally, prefixes can improve stack trace readability.
+
+The DC code does not follow some prefix rules, which makes the Ftrace filter
+more complicated and reduces the readability of the stack trace. If you want
+something simple to start contributing to the display, you can make patches for
+adding prefixes to DC functions. To create those prefixes, use part of the file
+name as a prefix for all functions in the target file. Check the
+'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we
+strongly advise not to send huge patches changing these prefixes; otherwise, it
+will be hard to review and test, which can generate second thoughts from
+maintainers. Try small steps; in case of double, you can ask before you put in
+effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics,
+bios, core, clk_mgr, hwss, resource, and irq.
+
+Level: Starter
+
+Reduce code duplication
+-----------------------
+
+AMD has an extensive portfolio with various dGPUs and APUs that amdgpu
+supports. To maintain the new hardware release cadence, DCE/DCN was designed in
+a modular design, making the bring-up for new hardware fast. Over the years,
+amdgpu accumulated some technical debt in the code duplication area. For this
+task, it would be a good idea to find a tool that can discover code duplication
+(including patterns) and use it as guidance to reduce duplications.
+
+Level: Intermediate
+
+Make atomic_commit_[check|tail] more readable
+---------------------------------------------
+
+The functions responsible for atomic commit and tail are intricate and
+extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and
+could benefit from being split into smaller helpers. Improvements in this area
+are more than welcome, but keep in mind that changes in this area will affect
+all ASICs, meaning that refactoring requires a comprehensive verification; in
+other words, this effort can take some time for validation.
+
+Level: Advanced
+
+Documentation
+=============
+
+Expand kernel-doc
+-----------------
+
+Many DC functions do not have a proper kernel-doc; understanding a function and
+adding documentation is a great way to learn more about the amdgpu driver and
+also leave an outstanding contribution to the entire community.
+
+Level: Starter
+
+Beyond AMDGPU
+=============
+
+AMDGPU provides features that are not yet enabled in the userspace. This
+section highlights some of the coolest display features, which could be enabled
+with the userspace developer helper.
+
+Enable underlay
+---------------
+
+AMD display has this feature called underlay (which you can read more about at
+'Documentation/gpu/amdgpu/display/mpo-overview.rst') which is intended to
+save power when playing a video. The basic idea is to put a video in the
+underlay plane at the bottom and the desktop in the plane above it with a hole
+in the video area. This feature is enabled in ChromeOS, and from our data
+measurement, it can save power.
+
+Level: Unknown
+
+Adaptive Backlight Modulation (ABM)
+-----------------------------------
+
+ABM is a feature that adjusts the display panel's backlight level and pixel
+values depending on the displayed image. This power-saving feature can be very
+useful when the system starts to run off battery; since this will impact the
+display output fidelity, it would be good if this option was something that
+users could turn on or off.
+
+Level: Unknown
+
+
+HDR & Color management & VRR
+----------------------------
+
+HDR, Color Management, and VRR are huge topics and it's hard to put these into
+concise ToDos. If you are interested in this topic, we recommend checking some
+blog posts from the community developers to better understand some of the
+specific challenges and people working on the subject. If anyone wants to work
+on some particular part, we can try to help with some basic guidance. Finally,
+keep in mind that we already have some kernel-doc in place for those areas.
+
+Level: Unknown
diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst
index b7abb18cfc82..b269ff3f7a54 100644
--- a/Documentation/gpu/amdgpu/display/display-manager.rst
+++ b/Documentation/gpu/amdgpu/display/display-manager.rst
@@ -132,10 +132,7 @@ The DRM blend mode and its elements are then mapped by AMDGPU display manager
(MPC), as follows:
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
- :doc: mpc-overview
-
-.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
- :functions: mpcc_blnd_cfg
+ :identifiers: mpcc_blnd_cfg
Therefore, the blending configuration for a single MPCC instance on the MPC
tree is defined by :c:type:`mpcc_blnd_cfg`, where
@@ -147,7 +144,7 @@ alpha and plane alpha values. It sets one of the three modes for
:c:type:`MPCC_ALPHA_BLND_MODE`, as described below.
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
- :functions: mpcc_alpha_blend_mode
+ :identifiers: mpcc_alpha_blend_mode
DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM
blend formula, as follows:
@@ -173,7 +170,7 @@ The alpha blending equation is configured from DRM to DC interface by the
following path:
1. When updating a :c:type:`drm_plane_state <drm_plane_state>`, DM calls
- :c:type:`fill_blending_from_plane_state()` that maps
+ :c:type:`amdgpu_dm_plane_fill_blending_from_plane_state()` that maps
:c:type:`drm_plane_state <drm_plane_state>` attributes to
:c:type:`dc_plane_info <dc_plane_info>` struct to be handled in the
OS-agnostic component (DC).
diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst
index f8a4f53d70d8..bd2d797c123e 100644
--- a/Documentation/gpu/amdgpu/display/index.rst
+++ b/Documentation/gpu/amdgpu/display/index.rst
@@ -7,18 +7,80 @@ drm/amd/display - Display Core (DC)
AMD display engine is partially shared with other operating systems; for this
reason, our Display Core Driver is divided into two pieces:
-1. **Display Core (DC)** contains the OS-agnostic components. Things like
+#. **Display Core (DC)** contains the OS-agnostic components. Things like
hardware programming and resource management are handled here.
-2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the
- amdgpu base driver and DRM are implemented here.
+#. **Display Manager (DM)** contains the OS-dependent components. Hooks to the
+ amdgpu base driver and DRM are implemented here. For example, you can check
+ display/amdgpu_dm/ folder.
+
+------------------
+DC Code validation
+------------------
+
+Maintaining the same code base across multiple OSes requires a lot of
+synchronization effort between repositories and exhaustive validation. In the
+DC case, we maintain a tree to centralize code from different parts. The shared
+repository has integration tests with our Internal Linux CI farm, and we run a
+comprehensive set of IGT tests in various AMD GPUs/APUs (mostly recent dGPUs
+and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation
+with DCN enabled and disabled.
+
+When we upstream a new feature or some patches, we pack them in a patchset with
+the prefix **DC Patches for <DATE>**, which is created based on the latest
+`amd-staging-drm-next <https://gitlab.freedesktop.org/agd5f/linux>`_. All of
+those patches are under a DC version tested as follows:
+
+* Ensure that every patch compiles and the entire series pass our set of IGT
+ test in different hardware.
+* Prepare a branch with those patches for our validation team. If there is an
+ error, a developer will debug as fast as possible; usually, a simple bisect
+ in the series is enough to point to a bad change, and two possible actions
+ emerge: fix the issue or drop the patch. If it is not an easy fix, the bad
+ patch is dropped.
+* Finally, developers wait a few days for community feedback before we merge
+ the series.
+
+It is good to stress that the test phase is something that we take extremely
+seriously, and we never merge anything that fails our validation. Follows an
+overview of our test set:
+
+#. Manual test
+ * Multiple Hotplugs with DP and HDMI.
+ * Stress test with multiple display configuration changes via the user interface.
+ * Validate VRR behaviour.
+ * Check PSR.
+ * Validate MPO when playing video.
+ * Test more than two displays connected at the same time.
+ * Check suspend/resume.
+ * Validate FPO.
+ * Check MST.
+#. Automated test
+ * IGT tests in a farm with GPUs and APUs that support DCN and DCE.
+ * Compilation validation with the latest GCC and Clang from LTS distro.
+ * Cross-compilation for PowerPC 64/32, ARM 64/32, and x86 32.
+
+In terms of test setup for CI and manual tests, we usually use:
+
+#. The latest Ubuntu LTS.
+#. In terms of userspace, we only use fully updated open-source components
+ provided by the distribution official package manager.
+#. Regarding IGT, we use the latest code from the upstream.
+#. Most of the manual tests are conducted in the GNome but we also use KDE.
+
+Notice that someone from our test team will always reply to the cover letter
+with the test report.
+
+--------------
+DC Information
+--------------
The display pipe is responsible for "scanning out" a rendered frame from the
GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words,
it would:
-1. Read frame information from memory;
-2. Perform required transformation;
-3. Send pixel data to sink devices.
+#. Read frame information from memory;
+#. Perform required transformation;
+#. Send pixel data to sink devices.
If you want to learn more about our driver details, take a look at the below
table of content:
@@ -26,7 +88,10 @@ table of content:
.. toctree::
display-manager.rst
- dc-debug.rst
dcn-overview.rst
+ dcn-blocks.rst
+ programming-model-dcn.rst
mpo-overview.rst
+ dc-debug.rst
+ display-contributing.rst
dc-glossary.rst
diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst
index 0499aa92d08d..59a4f54a3ac7 100644
--- a/Documentation/gpu/amdgpu/display/mpo-overview.rst
+++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst
@@ -178,7 +178,7 @@ Multiple Display MPO
AMDGPU supports display MPO when using multiple displays; however, this feature
behavior heavily relies on the compositor implementation. Keep in mind that
-usespace can define different policies. For example, some OSes can use MPO to
+userspace can define different policies. For example, some OSes can use MPO to
protect the plane that handles the video playback; notice that we don't have
many limitations for a single display. Nonetheless, this manipulation can have
many more restrictions for a multi-display scenario. The below example shows a
diff --git a/Documentation/gpu/amdgpu/display/programming-model-dcn.rst b/Documentation/gpu/amdgpu/display/programming-model-dcn.rst
new file mode 100644
index 000000000000..bc7de97a746f
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/programming-model-dcn.rst
@@ -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
+ connections 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.
+
diff --git a/Documentation/gpu/amdgpu/display/trace-groups-table.csv b/Documentation/gpu/amdgpu/display/trace-groups-table.csv
new file mode 100644
index 000000000000..3f6a50d1d883
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/trace-groups-table.csv
@@ -0,0 +1,29 @@
+Name, Mask Value
+INFO, 0x1
+IRQ SVC, 0x2
+VBIOS, 0x4
+REGISTER, 0x8
+PHY DBG, 0x10
+PSR, 0x20
+AUX, 0x40
+SMU, 0x80
+MALL, 0x100
+ABM, 0x200
+ALPM, 0x400
+TIMER, 0x800
+HW LOCK MGR, 0x1000
+INBOX1, 0x2000
+PHY SEQ, 0x4000
+PSR STATE, 0x8000
+ZSTATE, 0x10000
+TRANSMITTER CTL, 0x20000
+PANEL CNTL, 0x40000
+FAMS, 0x80000
+DPIA, 0x100000
+SUBVP, 0x200000
+INBOX0, 0x400000
+SDP, 0x4000000
+REPLAY, 0x8000000
+REPLAY RESIDENCY, 0x20000000
+CURSOR INFO, 0x80000000
+IPS, 0x100000000
diff --git a/Documentation/gpu/amdgpu/driver-core.rst b/Documentation/gpu/amdgpu/driver-core.rst
index ebf5932845a9..3ce276272171 100644
--- a/Documentation/gpu/amdgpu/driver-core.rst
+++ b/Documentation/gpu/amdgpu/driver-core.rst
@@ -65,38 +65,68 @@ SDMA (System DMA)
GC (Graphics and Compute)
This is the graphics and compute engine, i.e., the block that
- encompasses the 3D pipeline and and shader blocks. This is by far the
+ encompasses the 3D pipeline and shader blocks. This is by far the
largest block on the GPU. The 3D pipeline has tons of sub-blocks. In
- addition to that, it also contains the CP microcontrollers (ME, PFP,
- CE, MEC) and the RLC microcontroller. It's exposed to userspace for
- user mode drivers (OpenGL, Vulkan, OpenCL, etc.)
+ addition to that, it also contains the CP microcontrollers (ME, PFP, CE,
+ MEC) and the RLC microcontroller. It's exposed to userspace for user mode
+ drivers (OpenGL, Vulkan, OpenCL, etc.). More details in :ref:`Graphics (GFX)
+ and Compute <amdgpu-gc>`.
VCN (Video Core Next)
This is the multi-media engine. It handles video and image encode and
decode. It's exposed to userspace for user mode drivers (VA-API,
OpenMAX, etc.)
-Graphics and Compute Microcontrollers
--------------------------------------
-
-CP (Command Processor)
- The name for the hardware block that encompasses the front end of the
- GFX/Compute pipeline. Consists mainly of a bunch of microcontrollers
- (PFP, ME, CE, MEC). The firmware that runs on these microcontrollers
- provides the driver interface to interact with the GFX/Compute engine.
-
- MEC (MicroEngine Compute)
- This is the microcontroller that controls the compute queues on the
- GFX/compute engine.
-
- MES (MicroEngine Scheduler)
- This is a new engine for managing queues. This is currently unused.
-
-RLC (RunList Controller)
- This is another microcontroller in the GFX/Compute engine. It handles
- power management related functionality within the GFX/Compute engine.
- The name is a vestige of old hardware where it was originally added
- and doesn't really have much relation to what the engine does now.
+.. _pipes-and-queues-description:
+
+GFX, Compute, and SDMA Overall Behavior
+=======================================
+
+.. note:: For simplicity, whenever the term block is used in this section, it
+ means GFX, Compute, and SDMA.
+
+GFX, Compute and SDMA share a similar form of operation that can be abstracted
+to facilitate understanding of the behavior of these blocks. See the figure
+below illustrating the common components of these blocks:
+
+.. kernel-figure:: pipe_and_queue_abstraction.svg
+
+In the central part of this figure, you can see two hardware elements, one called
+**Pipes** and another called **Queues**; it is important to highlight that Queues
+must be associated with a Pipe and vice-versa. Every specific hardware IP may have
+a different number of Pipes and, in turn, a different number of Queues; for
+example, GFX 11 has two Pipes and two Queues per Pipe for the GFX front end.
+
+Pipe is the hardware that processes the instructions available in the Queues;
+in other words, it is a thread executing the operations inserted in the Queue.
+One crucial characteristic of Pipes is that they can only execute one Queue at
+a time; no matter if the hardware has multiple Queues in the Pipe, it only runs
+one Queue per Pipe.
+
+Pipes have the mechanics of swapping between queues at the hardware level.
+Nonetheless, they only make use of Queues that are considered mapped. Pipes can
+switch between queues based on any of the following inputs:
+
+1. Command Stream;
+2. Packet by Packet;
+3. Other hardware requests the change (e.g., MES).
+
+Queues within Pipes are defined by the Hardware Queue Descriptors (HQD).
+Associated with the HQD concept, we have the Memory Queue Descriptor (MQD),
+which is responsible for storing information about the state of each of the
+available Queues in the memory. The state of a Queue contains information such
+as the GPU virtual address of the queue itself, save areas, doorbell, etc. The
+MQD also stores the HQD registers, which are vital for activating or
+deactivating a given Queue. The scheduling firmware (e.g., MES) is responsible
+for loading HQDs from MQDs and vice versa.
+
+The Queue-switching process can also happen with the firmware requesting the
+preemption or unmapping of a Queue. The firmware waits for the HQD_ACTIVE bit
+to change to low before saving the state into the MQD. To make a different
+Queue become active, the firmware copies the MQD state into the HQD registers
+and loads any additional state. Finally, it sets the HQD_ACTIVE bit to high to
+indicate that the queue is active. The Pipe will then execute work from active
+Queues.
Driver Structure
================
@@ -110,7 +140,8 @@ Some useful constructs:
KIQ (Kernel Interface Queue)
This is a control queue used by the kernel driver to manage other gfx
and compute queues on the GFX/compute engine. You can use it to
- map/unmap additional queues, etc.
+ map/unmap additional queues, etc. This is replaced by MES on
+ GFX 11 and newer hardware.
IB (Indirect Buffer)
A command buffer for a particular engine. Rather than writing
@@ -148,10 +179,10 @@ PRIME Buffer Sharing
MMU Notifier
============
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
:doc: MMU Notifier
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
:internal:
AMDGPU Virtual Memory
@@ -179,4 +210,4 @@ IP Blocks
:doc: IP Blocks
.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h
- :identifiers: amd_ip_block_type amd_ip_funcs
+ :identifiers: amd_ip_block_type amd_ip_funcs DC_FEATURE_MASK DC_DEBUG_MASK
diff --git a/Documentation/gpu/amdgpu/driver-misc.rst b/Documentation/gpu/amdgpu/driver-misc.rst
index 1800543d45f7..25b0c857816e 100644
--- a/Documentation/gpu/amdgpu/driver-misc.rst
+++ b/Documentation/gpu/amdgpu/driver-misc.rst
@@ -11,43 +11,44 @@ via sysfs
product_name
------------
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: product_name
product_number
--------------
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
- :doc: product_name
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+ :doc: product_number
serial_number
-------------
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
:doc: serial_number
+fru_id
+-------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+ :doc: fru_id
+
+manufacturer
+-------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c
+ :doc: manufacturer
+
unique_id
---------
.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: unique_id
-Accelerated Processing Units (APU) Info
----------------------------------------
-
-.. csv-table::
- :header-rows: 1
- :widths: 3, 2, 2, 1, 1, 1
- :file: ./apu-asic-info-table.csv
-
-Discrete GPU Info
------------------
-
-.. csv-table::
- :header-rows: 1
- :widths: 3, 2, 2, 1, 1, 1
- :file: ./dgpu-asic-info-table.csv
+board_info
+----------
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+ :doc: board_info
GPU Memory Usage Information
============================
diff --git a/Documentation/gpu/amdgpu/flashing.rst b/Documentation/gpu/amdgpu/flashing.rst
new file mode 100644
index 000000000000..bd745c42a538
--- /dev/null
+++ b/Documentation/gpu/amdgpu/flashing.rst
@@ -0,0 +1,33 @@
+=======================
+ dGPU firmware flashing
+=======================
+
+IFWI
+----
+Flashing the dGPU integrated firmware image (IFWI) is supported by GPUs that
+use the PSP to orchestrate the update (Navi3x or newer GPUs).
+For supported GPUs, `amdgpu` will export a series of sysfs files that can be
+used for the flash process.
+
+The IFWI flash process is:
+
+1. Ensure the IFWI image is intended for the dGPU on the system.
+2. "Write" the IFWI image to the sysfs file `psp_vbflash`. This will stage the IFWI in memory.
+3. "Read" from the `psp_vbflash` sysfs file to initiate the flash process.
+4. Poll the `psp_vbflash_status` sysfs file to determine when the flash process completes.
+
+USB-C PD F/W
+------------
+On GPUs that support flashing an updated USB-C PD firmware image, the process
+is done using the `usbc_pd_fw` sysfs file.
+
+* Reading the file will provide the current firmware version.
+* Writing the name of a firmware payload stored in `/lib/firmware/amdgpu` to the sysfs file will initiate the flash process.
+
+The firmware payload stored in `/lib/firmware/amdgpu` can be named any name
+as long as it doesn't conflict with other existing binaries that are used by
+`amdgpu`.
+
+sysfs files
+-----------
+.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
diff --git a/Documentation/gpu/amdgpu/gc/index.rst b/Documentation/gpu/amdgpu/gc/index.rst
new file mode 100644
index 000000000000..ff6e9ef5cbee
--- /dev/null
+++ b/Documentation/gpu/amdgpu/gc/index.rst
@@ -0,0 +1,52 @@
+.. _amdgpu-gc:
+
+========================================
+ drm/amdgpu - Graphics and Compute (GC)
+========================================
+
+The relationship between the CPU and GPU can be described as the
+producer-consumer problem, where the CPU fills out a buffer with operations
+(producer) to be executed by the GPU (consumer). The requested operations in
+the buffer are called Command Packets, which can be summarized as a compressed
+way of transmitting command information to the graphics controller.
+
+The component that acts as the front end between the CPU and the GPU is called
+the Command Processor (CP). This component is responsible for providing greater
+flexibility to the GC since CP makes it possible to program various aspects of
+the GPU pipeline. CP also coordinates the communication between the CPU and GPU
+via a mechanism named **Ring Buffers**, where the CPU appends information to
+the buffer while the GPU removes operations. It is relevant to highlight that a
+CPU can add a pointer to the Ring Buffer that points to another region of
+memory outside the Ring Buffer, and CP can handle it; this mechanism is called
+**Indirect Buffer (IB)**. CP receives and parses the Command Streams (CS), and
+writes the operations to the correct hardware blocks.
+
+Graphics (GFX) and Compute Microcontrollers
+-------------------------------------------
+
+GC is a large block, and as a result, it has multiple firmware associated with
+it. Some of them are:
+
+CP (Command Processor)
+ The name for the hardware block that encompasses the front end of the
+ GFX/Compute pipeline. Consists mainly of a bunch of microcontrollers
+ (PFP, ME, CE, MEC). The firmware that runs on these microcontrollers
+ provides the driver interface to interact with the GFX/Compute engine.
+
+ MEC (MicroEngine Compute)
+ This is the microcontroller that controls the compute queues on the
+ GFX/compute engine.
+
+ MES (MicroEngine Scheduler)
+ This is the engine for managing queues. For more details check
+ :ref:`MicroEngine Scheduler (MES) <amdgpu-mes>`.
+
+RLC (RunList Controller)
+ This is another microcontroller in the GFX/Compute engine. It handles
+ power management related functionality within the GFX/Compute engine.
+ The name is a vestige of old hardware where it was originally added
+ and doesn't really have much relation to what the engine does now.
+
+.. toctree::
+
+ mes.rst
diff --git a/Documentation/gpu/amdgpu/gc/mes.rst b/Documentation/gpu/amdgpu/gc/mes.rst
new file mode 100644
index 000000000000..b99eb211b179
--- /dev/null
+++ b/Documentation/gpu/amdgpu/gc/mes.rst
@@ -0,0 +1,38 @@
+.. _amdgpu-mes:
+
+=============================
+ MicroEngine Scheduler (MES)
+=============================
+
+.. note::
+ Queue and ring buffer are used as a synonymous.
+
+.. note::
+ This section assumes that you are familiar with the concept of Pipes, Queues, and GC.
+ If not, check :ref:`GFX, Compute, and SDMA Overall Behavior<pipes-and-queues-description>`
+ and :ref:`drm/amdgpu - Graphics and Compute (GC) <amdgpu-gc>`.
+
+Every GFX has a pipe component with one or more hardware queues. Pipes can
+switch between queues depending on certain conditions, and one of the
+components that can request a queue switch to a pipe is the MicroEngine
+Scheduler (MES). Whenever the driver is initialized, it creates one MQD per
+hardware queue, and then the MQDs are handed to the MES firmware for mapping
+to:
+
+1. Kernel Queues (legacy): This queue is statically mapped to HQDs and never
+ preempted. Even though this is a legacy feature, it is the current default, and
+ most existing hardware supports it. When an application submits work to the
+ kernel driver, it submits all of the application command buffers to the kernel
+ queues. The CS IOCTL takes the command buffer from the applications and
+ schedules them on the kernel queue.
+
+2. User Queues: These queues are dynamically mapped to the HQDs. Regarding the
+ utilization of User Queues, the userspace application will create its user
+ queues and submit work directly to its user queues with no need to IOCTL for
+ each submission and no need to share a single kernel queue.
+
+In terms of User Queues, MES can dynamically map them to the HQD. If there are
+more MQDs than HQDs, the MES firmware will preempt other user queues to make
+sure each queues get a time slice; in other words, MES is a microcontroller
+that handles the mapping and unmapping of MQDs into HQDs, as well as the
+priorities and oversubscription of MQDs.
diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst
index a24e1cfa7407..45523e9860fc 100644
--- a/Documentation/gpu/amdgpu/index.rst
+++ b/Documentation/gpu/amdgpu/index.rst
@@ -3,15 +3,22 @@
==========================
The drm/amdgpu driver supports all AMD Radeon GPUs based on the Graphics Core
-Next (GCN) architecture.
+Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures.
.. toctree::
- module-parameters
driver-core
+ amd-hardware-list-info
+ module-parameters
+ gc/index
display/index
+ userq
+ flashing
xgmi
ras
thermal
driver-misc
+ debugging
+ debugfs
+ process-isolation
amdgpu-glossary
diff --git a/Documentation/gpu/amdgpu/pipe_and_queue_abstraction.svg b/Documentation/gpu/amdgpu/pipe_and_queue_abstraction.svg
new file mode 100644
index 000000000000..0df3c6b3000b
--- /dev/null
+++ b/Documentation/gpu/amdgpu/pipe_and_queue_abstraction.svg
@@ -0,0 +1,1279 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ width="395.47891mm"
+ height="234.73715mm"
+ viewBox="0 0 395.47891 234.73714"
+ version="1.1"
+ id="svg1"
+ inkscape:version="1.4 (e7c3feb100, 2024-10-09)"
+ sodipodi:docname="pipe_and_queue_abstraction.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">
+ <sodipodi:namedview
+ id="namedview1"
+ pagecolor="#ffffff"
+ bordercolor="#000000"
+ borderopacity="0.25"
+ inkscape:showpageshadow="2"
+ inkscape:pageopacity="0.0"
+ inkscape:pagecheckerboard="0"
+ inkscape:deskcolor="#d1d1d1"
+ inkscape:document-units="mm"
+ inkscape:zoom="1.6489689"
+ inkscape:cx="713.17296"
+ inkscape:cy="466.65527"
+ inkscape:window-width="3840"
+ inkscape:window-height="2083"
+ inkscape:window-x="0"
+ inkscape:window-y="0"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="layer1" />
+ <defs
+ id="defs1">
+ <marker
+ style="overflow:visible"
+ id="Dot"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Dot"
+ markerWidth="1"
+ markerHeight="1"
+ viewBox="0 0 1 1"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid">
+ <path
+ transform="scale(0.5)"
+ style="fill:context-stroke;fill-rule:evenodd;stroke:none"
+ d="M 5,0 C 5,2.76 2.76,5 0,5 -2.76,5 -5,2.76 -5,0 c 0,-2.76 2.3,-5 5,-5 2.76,0 5,2.24 5,5 z"
+ sodipodi:nodetypes="sssss"
+ id="path110" />
+ </marker>
+ <marker
+ style="overflow:visible"
+ id="marker109"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="Stylized triangle arrow"
+ markerWidth="1"
+ markerHeight="1"
+ viewBox="0 0 1 1"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid">
+ <path
+ transform="scale(0.5)"
+ style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="m 6,0 c -3,1 -7,3 -9,5 0,0 0,-4 2,-5 -2,-1 -2,-5 -2,-5 2,2 6,4 9,5 z"
+ id="path109" />
+ </marker>
+ <marker
+ style="overflow:visible"
+ id="ArrowTriangleStylized"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="Stylized triangle arrow"
+ markerWidth="1"
+ markerHeight="1"
+ viewBox="0 0 1 1"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid">
+ <path
+ transform="scale(0.5)"
+ style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="m 6,0 c -3,1 -7,3 -9,5 0,0 0,-4 2,-5 -2,-1 -2,-5 -2,-5 2,2 6,4 9,5 z"
+ id="path108" />
+ </marker>
+ <marker
+ style="overflow:visible"
+ id="ArrowWide"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="Wide arrow"
+ markerWidth="1"
+ markerHeight="1"
+ viewBox="0 0 1 1"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid">
+ <path
+ style="fill:none;stroke:context-stroke;stroke-width:1;stroke-linecap:butt"
+ d="M 3,-3 0,0 3,3"
+ transform="rotate(180,0.125,0)"
+ sodipodi:nodetypes="ccc"
+ id="path1" />
+ </marker>
+ <marker
+ style="overflow:visible"
+ id="Triangle"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="Triangle arrow"
+ markerWidth="1"
+ markerHeight="1"
+ viewBox="0 0 1 1"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid">
+ <path
+ transform="scale(0.5)"
+ style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+ d="M 5.77,0 -2.88,5 V -5 Z"
+ id="path135" />
+ </marker>
+ <marker
+ style="overflow:visible"
+ id="ArrowWideHeavy"
+ refX="0"
+ refY="0"
+ orient="auto-start-reverse"
+ inkscape:stockid="Wide, heavy arrow"
+ markerWidth="1"
+ markerHeight="1"
+ viewBox="0 0 1 1"
+ inkscape:isstock="true"
+ inkscape:collect="always"
+ preserveAspectRatio="xMidYMid">
+ <path
+ style="fill:context-stroke;fill-rule:evenodd;stroke:none"
+ d="m 1,0 -3,3 h -2 l 3,-3 -3,-3 h 2 z"
+ id="path71" />
+ </marker>
+ </defs>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1"
+ transform="translate(149.03517,55.110629)">
+ <circle
+ style="fill:#ffeeaa;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.733436;stroke-dasharray:none;stroke-dashoffset:0"
+ id="path98"
+ cx="-35.757576"
+ cy="-10.495151"
+ r="44.24876" />
+ <rect
+ style="fill:none;stroke:#000000;stroke-width:0.878057;stroke-dasharray:none"
+ id="rect1"
+ width="167.79619"
+ height="24.831829"
+ x="14.21942"
+ y="57.862854" />
+ <g
+ id="g11"
+ transform="translate(24.021362,-46.545299)">
+ <rect
+ style="fill:none;stroke:#006680;stroke-width:0.459999;stroke-dasharray:none"
+ id="rect2"
+ width="131.09708"
+ height="5.8163381"
+ x="23.245802"
+ y="107.16314" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 37.884707,107.26337 v 5.53565"
+ id="path2"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 52.466233,107.26337 v 5.53565"
+ id="path3"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 67.047758,107.26337 v 5.53565"
+ id="path4"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 81.629283,107.26337 v 5.53565"
+ id="path5"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 96.210809,107.26337 v 5.53565"
+ id="path6"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 110.79233,107.26337 v 5.53565"
+ id="path7"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 125.37386,107.26337 v 5.53565"
+ id="path8"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 139.95538,107.26337 v 5.53565"
+ id="path9"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="86.713425"
+ y="110.1963"
+ id="text11"><tspan
+ sodipodi:role="line"
+ id="tspan11"
+ style="stroke:#006680;stroke-width:0.5"
+ x="86.713425"
+ y="110.1963">. . .</tspan></text>
+ </g>
+ <g
+ id="g18"
+ transform="translate(24.021362,-32.25779)">
+ <rect
+ style="fill:none;stroke:#006680;stroke-width:0.459999;stroke-dasharray:none"
+ id="rect11"
+ width="131.09708"
+ height="5.8163381"
+ x="23.245802"
+ y="107.16314" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 37.884707,107.26337 v 5.53565"
+ id="path11"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 52.466233,107.26337 v 5.53565"
+ id="path12"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 67.047758,107.26337 v 5.53565"
+ id="path13"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 81.629283,107.26337 v 5.53565"
+ id="path14"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 96.210809,107.26337 v 5.53565"
+ id="path15"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 110.79233,107.26337 v 5.53565"
+ id="path16"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 125.37386,107.26337 v 5.53565"
+ id="path17"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 139.95538,107.26337 v 5.53565"
+ id="path18"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="86.713425"
+ y="110.1963"
+ id="text18"><tspan
+ sodipodi:role="line"
+ id="tspan18"
+ style="stroke:#006680;stroke-width:0.5"
+ x="86.713425"
+ y="110.1963">. . .</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="113.37768"
+ y="68.463142"
+ id="text19"><tspan
+ sodipodi:role="line"
+ id="tspan19"
+ style="writing-mode:tb-rl;stroke-width:0.5"
+ x="113.37768"
+ y="68.463142">. . .</tspan></text>
+ <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.0690111"
+ x="25.005701"
+ y="55.308445"
+ id="text844-2-9"><tspan
+ sodipodi:role="line"
+ x="25.005701"
+ y="55.308445"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan2868">Pipe[0]</tspan></text>
+ <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.0690111"
+ x="-74.441521"
+ y="63.075123"
+ id="text844-2-9-4"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="63.075123"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan2868-7">MQD</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="65.490654"
+ id="text20"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="65.490654"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan20">Queue[0]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="79.249001"
+ id="text21"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="79.249001"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan21">Queue[n]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="71.84066"
+ id="text22"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="71.84066"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan22">...</tspan></text>
+ <g
+ id="g71"
+ transform="translate(-23.283342)">
+ <rect
+ style="fill:#ffffff;fill-opacity:0;stroke:#000000;stroke-width:0.5;stroke-dasharray:0.5, 0.5;stroke-dashoffset:0"
+ id="rect67"
+ width="18.533583"
+ height="114.96632"
+ x="250.9435"
+ y="54.754276"
+ ry="6.0427966" />
+ </g>
+ <rect
+ style="fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:0.499999;stroke-dasharray:none;stroke-dashoffset:0"
+ id="rect68"
+ width="188.21231"
+ height="139.5948"
+ x="4.0113592"
+ y="37.597778"
+ ry="0" />
+ <g
+ id="g43"
+ transform="translate(0,40.745853)">
+ <rect
+ style="fill:none;stroke:#000000;stroke-width:0.878057;stroke-dasharray:none"
+ id="rect22"
+ width="167.79619"
+ height="24.831829"
+ x="14.21942"
+ y="57.862854" />
+ <g
+ id="g30"
+ transform="translate(24.021362,-46.545299)">
+ <rect
+ style="fill:none;stroke:#006680;stroke-width:0.459999;stroke-dasharray:none"
+ id="rect23"
+ width="131.09708"
+ height="5.8163381"
+ x="23.245802"
+ y="107.16314" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 37.884707,107.26337 v 5.53565"
+ id="path23"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 52.466233,107.26337 v 5.53565"
+ id="path24"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 67.047758,107.26337 v 5.53565"
+ id="path25"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 81.629283,107.26337 v 5.53565"
+ id="path26"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 96.210809,107.26337 v 5.53565"
+ id="path27"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 110.79233,107.26337 v 5.53565"
+ id="path28"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 125.37386,107.26337 v 5.53565"
+ id="path29"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 139.95538,107.26337 v 5.53565"
+ id="path30"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="86.713425"
+ y="110.1963"
+ id="text30"><tspan
+ sodipodi:role="line"
+ id="tspan30"
+ style="stroke:#006680;stroke-width:0.5"
+ x="86.713425"
+ y="110.1963">. . .</tspan></text>
+ </g>
+ <g
+ id="g38"
+ transform="translate(24.021362,-32.25779)">
+ <rect
+ style="fill:none;stroke:#006680;stroke-width:0.459999;stroke-dasharray:none"
+ id="rect30"
+ width="131.09708"
+ height="5.8163381"
+ x="23.245802"
+ y="107.16314" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 37.884707,107.26337 v 5.53565"
+ id="path31"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 52.466233,107.26337 v 5.53565"
+ id="path32"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 67.047758,107.26337 v 5.53565"
+ id="path33"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 81.629283,107.26337 v 5.53565"
+ id="path34"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 96.210809,107.26337 v 5.53565"
+ id="path35"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 110.79233,107.26337 v 5.53565"
+ id="path36"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 125.37386,107.26337 v 5.53565"
+ id="path37"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 139.95538,107.26337 v 5.53565"
+ id="path38"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="86.713425"
+ y="110.1963"
+ id="text38"><tspan
+ sodipodi:role="line"
+ id="tspan38"
+ style="stroke:#006680;stroke-width:0.5"
+ x="86.713425"
+ y="110.1963">. . .</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="113.37768"
+ y="68.463142"
+ id="text39"><tspan
+ sodipodi:role="line"
+ id="tspan39"
+ style="writing-mode:tb-rl;stroke-width:0.5"
+ x="113.37768"
+ y="68.463142">. . .</tspan></text>
+ <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.0690111"
+ x="25.005701"
+ y="55.308445"
+ id="text40"><tspan
+ sodipodi:role="line"
+ x="25.005701"
+ y="55.308445"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan40">Pipe[1]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="65.490654"
+ id="text41"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="65.490654"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan41">Queue[0]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="79.249001"
+ id="text42"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="79.249001"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan42">Queue[n]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="71.84066"
+ id="text43"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="71.84066"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan43">...</tspan></text>
+ </g>
+ <g
+ id="g64"
+ transform="translate(0,85.195881)">
+ <rect
+ style="fill:none;stroke:#000000;stroke-width:0.878057;stroke-dasharray:none"
+ id="rect43"
+ width="167.79619"
+ height="24.831829"
+ x="14.21942"
+ y="57.862854" />
+ <g
+ id="g51"
+ transform="translate(24.021362,-46.545299)">
+ <rect
+ style="fill:none;stroke:#006680;stroke-width:0.459999;stroke-dasharray:none"
+ id="rect44"
+ width="131.09708"
+ height="5.8163381"
+ x="23.245802"
+ y="107.16314" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 37.884707,107.26337 v 5.53565"
+ id="path44"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 52.466233,107.26337 v 5.53565"
+ id="path45"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 67.047758,107.26337 v 5.53565"
+ id="path46"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 81.629283,107.26337 v 5.53565"
+ id="path47"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 96.210809,107.26337 v 5.53565"
+ id="path48"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 110.79233,107.26337 v 5.53565"
+ id="path49"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 125.37386,107.26337 v 5.53565"
+ id="path50"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 139.95538,107.26337 v 5.53565"
+ id="path51"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="86.713425"
+ y="110.1963"
+ id="text51"><tspan
+ sodipodi:role="line"
+ id="tspan51"
+ style="stroke:#006680;stroke-width:0.5"
+ x="86.713425"
+ y="110.1963">. . .</tspan></text>
+ </g>
+ <g
+ id="g59"
+ transform="translate(24.021362,-32.25779)">
+ <rect
+ style="fill:none;stroke:#006680;stroke-width:0.459999;stroke-dasharray:none"
+ id="rect51"
+ width="131.09708"
+ height="5.8163381"
+ x="23.245802"
+ y="107.16314" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 37.884707,107.26337 v 5.53565"
+ id="path52"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 52.466233,107.26337 v 5.53565"
+ id="path53"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 67.047758,107.26337 v 5.53565"
+ id="path54"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 81.629283,107.26337 v 5.53565"
+ id="path55"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 96.210809,107.26337 v 5.53565"
+ id="path56"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 110.79233,107.26337 v 5.53565"
+ id="path57"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 125.37386,107.26337 v 5.53565"
+ id="path58"
+ sodipodi:nodetypes="cc" />
+ <path
+ style="fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ d="m 139.95538,107.26337 v 5.53565"
+ id="path59"
+ sodipodi:nodetypes="cc" />
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="86.713425"
+ y="110.1963"
+ id="text59"><tspan
+ sodipodi:role="line"
+ id="tspan59"
+ style="stroke:#006680;stroke-width:0.5"
+ x="86.713425"
+ y="110.1963">. . .</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:3.175px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:none;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="113.37768"
+ y="68.463142"
+ id="text60"><tspan
+ sodipodi:role="line"
+ id="tspan60"
+ style="writing-mode:tb-rl;stroke-width:0.5"
+ x="113.37768"
+ y="68.463142">. . .</tspan></text>
+ <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.0690111"
+ x="25.005701"
+ y="55.308445"
+ id="text61"><tspan
+ sodipodi:role="line"
+ x="25.005701"
+ y="55.308445"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan61">Pipe[n]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="65.490654"
+ id="text62"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="65.490654"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan62">Queue[0]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="79.249001"
+ id="text63"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="79.249001"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan63">Queue[n]</tspan></text>
+ <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.0690111"
+ x="30.264952"
+ y="71.84066"
+ id="text64"><tspan
+ sodipodi:role="line"
+ x="30.264952"
+ y="71.84066"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan64">...</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.76111px;font-family:Serif;-inkscape-font-specification:Serif;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;fill-opacity:0;stroke:#006680;stroke-width:0.499999;stroke-dasharray:none"
+ x="92.18071"
+ y="128.21965"
+ id="text65"><tspan
+ sodipodi:role="line"
+ id="tspan65"
+ style="font-size:7.76111px;writing-mode:tb-rl;fill:#1a1a1a;stroke:#000000;stroke-width:0.5"
+ x="92.18071"
+ y="128.21965">...</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.7611px;font-family:Serif;-inkscape-font-specification:Serif;text-align:start;writing-mode:tb-rl;direction:ltr;text-anchor:start;fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:0.499999;stroke-dasharray:none"
+ x="198.72205"
+ y="80.708267"
+ id="text66"><tspan
+ sodipodi:role="line"
+ id="tspan66"
+ style="stroke-width:0.5"
+ x="198.72205"
+ y="80.708267" /></text>
+ <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.0690111"
+ x="97.905846"
+ y="44.725101"
+ id="text68"><tspan
+ sodipodi:role="line"
+ x="97.905846"
+ y="44.725101"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan68">Hardware Block</tspan></text>
+ <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;writing-mode:vertical-lr;text-orientation:upright;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="236.36934"
+ y="112.10503"
+ id="text68-7"><tspan
+ sodipodi:role="line"
+ x="236.36934"
+ y="112.10503"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;writing-mode:vertical-lr;text-orientation:upright;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan68-4">EXECUTION</tspan></text>
+ <rect
+ style="fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:0.940575;stroke-dasharray:7.5246, 0.940575;stroke-dashoffset:0"
+ id="rect68-1"
+ width="68.749969"
+ height="141.2751"
+ x="-129.49162"
+ y="37.881134"
+ ry="0" />
+ <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.0690111"
+ x="-114.4223"
+ y="44.966106"
+ id="text68-2"><tspan
+ sodipodi:role="line"
+ x="-114.4223"
+ y="44.966106"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan68-9">Memory</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.7px;font-family:Serif;-inkscape-font-specification:Serif;text-align:start;writing-mode:tb-rl;direction:ltr;text-orientation:upright;text-anchor:start;fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:0.499999;stroke-dasharray:none;stroke-dashoffset:0"
+ x="212.6013"
+ y="64.823341"
+ id="text69"><tspan
+ sodipodi:role="line"
+ id="tspan69"
+ style="font-size:12.7px;stroke-width:0.5"
+ x="212.6013"
+ y="64.823341" /></text>
+ <g
+ id="g72">
+ <path
+ style="font-weight:bold;font-size:16.9333px;line-height:1.25;-inkscape-font-specification:'sans-serif Bold';text-align:center;letter-spacing:0px;word-spacing:0px;text-anchor:middle;stroke-width:0.0690111"
+ d="m 185.24734,83.96512 h 1.28693 c 1.20226,0.01693 2.09973,-1.015998 2.0828,-2.370662 v -9.393759 c -0.0169,-0.711199 0.33866,-1.066798 1.10066,-1.066798 h 0.2032 0.0677 v -1.557864 c -1.0668,0.01693 -1.38853,-0.270933 -1.37159,-1.236131 V 58.96308 c 0.0339,-1.354664 -0.88054,-2.387595 -2.0828,-2.370662 h -1.28693 v 1.676397 h 0.62653 c 0.57573,0 0.77893,0.321733 0.762,1.100664 v 9.122827 c 0,1.219198 0.44027,1.710263 1.64253,1.862663 -1.20226,0.135466 -1.64253,0.626532 -1.64253,1.84573 v 9.122826 c 0.0169,0.660399 -0.23707,0.965198 -0.762,0.965198 h -0.62653 z"
+ id="text70"
+ aria-label="}"
+ sodipodi:nodetypes="ccccsccccccccscscscscc" />
+ <path
+ style="fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:1.25;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#ArrowWideHeavy)"
+ d="M 190.40199,70.278769 H 224.6663"
+ id="path70" />
+ </g>
+ <path
+ style="font-weight:bold;font-size:16.9333px;line-height:1.25;-inkscape-font-specification:'sans-serif Bold';text-align:center;letter-spacing:0px;word-spacing:0px;text-anchor:middle;stroke-width:0.0690111"
+ d="m -88.44114,74.337891 h 1.28693 c 1.20226,0.01693 2.09973,-1.015998 2.0828,-2.370662 V 62.57347 c -0.0169,-0.711199 0.33866,-1.066798 1.10066,-1.066798 h 0.2032 0.0677 v -1.557864 c -1.0668,0.01693 -1.38853,-0.270933 -1.37159,-1.236131 v -9.376826 c 0.0339,-1.354664 -0.88054,-2.387595 -2.0828,-2.370662 h -1.28693 v 1.676397 h 0.62653 c 0.57573,0 0.77893,0.321733 0.762,1.100664 v 9.122827 c 0,1.219198 0.44027,1.710263 1.64253,1.862663 -1.20226,0.135466 -1.64253,0.626532 -1.64253,1.84573 v 9.122826 c 0.0169,0.660399 -0.23707,0.965198 -0.762,0.965198 h -0.62653 z"
+ id="text70-1"
+ aria-label="}"
+ sodipodi:nodetypes="ccccsccccccccscscscscc" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:16.9333px;font-family:Serif;-inkscape-font-specification:Serif;text-align:start;writing-mode:tb-rl;direction:ltr;text-orientation:upright;text-anchor:start;fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:1.25;stroke-dasharray:none;stroke-dashoffset:0"
+ x="200.88817"
+ y="38.990276"
+ id="text72"><tspan
+ sodipodi:role="line"
+ id="tspan72"
+ style="stroke-width:1.25"
+ x="200.88817"
+ y="38.990276" /></text>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:6.35px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="205.12828"
+ y="60.090775"
+ id="text73"><tspan
+ sodipodi:role="line"
+ x="205.12828"
+ y="60.090775"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.35px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan73">e.g.,:</tspan><tspan
+ sodipodi:role="line"
+ x="205.12828"
+ y="68.028275"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.35px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan74">queue[0]</tspan></text>
+ <g
+ id="g75"
+ transform="translate(0,40.745853)">
+ <path
+ style="font-weight:bold;font-size:16.9333px;line-height:1.25;-inkscape-font-specification:'sans-serif Bold';text-align:center;letter-spacing:0px;word-spacing:0px;text-anchor:middle;stroke-width:0.0690111"
+ d="m 185.24734,83.96512 h 1.28693 c 1.20226,0.01693 2.09973,-1.015998 2.0828,-2.370662 v -9.393759 c -0.0169,-0.711199 0.33866,-1.066798 1.10066,-1.066798 h 0.2032 0.0677 v -1.557864 c -1.0668,0.01693 -1.38853,-0.270933 -1.37159,-1.236131 V 58.96308 c 0.0339,-1.354664 -0.88054,-2.387595 -2.0828,-2.370662 h -1.28693 v 1.676397 h 0.62653 c 0.57573,0 0.77893,0.321733 0.762,1.100664 v 9.122827 c 0,1.219198 0.44027,1.710263 1.64253,1.862663 -1.20226,0.135466 -1.64253,0.626532 -1.64253,1.84573 v 9.122826 c 0.0169,0.660399 -0.23707,0.965198 -0.762,0.965198 h -0.62653 z"
+ id="path74"
+ aria-label="}"
+ sodipodi:nodetypes="ccccsccccccccscscscscc" />
+ <path
+ style="fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:1.25;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#ArrowWideHeavy)"
+ d="M 190.40199,70.278769 H 224.6663"
+ id="path75" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:6.35px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="205.12828"
+ y="100.83664"
+ id="text76"><tspan
+ sodipodi:role="line"
+ x="205.12828"
+ y="100.83664"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.35px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan75">e.g.,:</tspan><tspan
+ sodipodi:role="line"
+ x="205.12828"
+ y="108.77414"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.35px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan76">queue[4]</tspan></text>
+ <g
+ id="g77"
+ transform="translate(0,85.725048)">
+ <path
+ style="font-weight:bold;font-size:16.9333px;line-height:1.25;-inkscape-font-specification:'sans-serif Bold';text-align:center;letter-spacing:0px;word-spacing:0px;text-anchor:middle;stroke-width:0.0690111"
+ d="m 185.24734,83.96512 h 1.28693 c 1.20226,0.01693 2.09973,-1.015998 2.0828,-2.370662 v -9.393759 c -0.0169,-0.711199 0.33866,-1.066798 1.10066,-1.066798 h 0.2032 0.0677 v -1.557864 c -1.0668,0.01693 -1.38853,-0.270933 -1.37159,-1.236131 V 58.96308 c 0.0339,-1.354664 -0.88054,-2.387595 -2.0828,-2.370662 h -1.28693 v 1.676397 h 0.62653 c 0.57573,0 0.77893,0.321733 0.762,1.100664 v 9.122827 c 0,1.219198 0.44027,1.710263 1.64253,1.862663 -1.20226,0.135466 -1.64253,0.626532 -1.64253,1.84573 v 9.122826 c 0.0169,0.660399 -0.23707,0.965198 -0.762,0.965198 h -0.62653 z"
+ id="path76"
+ aria-label="}"
+ sodipodi:nodetypes="ccccsccccccccscscscscc" />
+ <path
+ style="fill:#1a1a1a;fill-opacity:0;stroke:#000000;stroke-width:1.25;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#ArrowWideHeavy)"
+ d="M 190.40199,70.278769 H 224.6663"
+ id="path77" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:6.35px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="205.12828"
+ y="145.81558"
+ id="text78"><tspan
+ sodipodi:role="line"
+ x="205.12828"
+ y="145.81558"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.35px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan77">e.g.,:</tspan><tspan
+ sodipodi:role="line"
+ x="205.12828"
+ y="153.75308"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.35px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan78">queue[n]</tspan></text>
+ <g
+ id="g81">
+ <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.0690111"
+ x="-18.502264"
+ y="65.642387"
+ id="text79"><tspan
+ sodipodi:role="line"
+ x="-18.502264"
+ y="65.642387"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;fill:#800000;stroke-width:0.0690111"
+ id="tspan79">HQD</tspan></text>
+ <ellipse
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0"
+ id="path79"
+ cx="-18.407015"
+ cy="63.2188"
+ rx="13.317666"
+ ry="4.4124799" />
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+ d="M -4.6361224,63.2188 H 10.606988"
+ id="path80" />
+ </g>
+ <g
+ id="g82"
+ transform="translate(0,14.287503)">
+ <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.0690111"
+ x="-18.502264"
+ y="65.642387"
+ id="text81"><tspan
+ sodipodi:role="line"
+ x="-18.502264"
+ y="65.642387"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;fill:#800000;stroke-width:0.0690111"
+ id="tspan81">HQD</tspan></text>
+ <ellipse
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0"
+ id="ellipse81"
+ cx="-18.407015"
+ cy="63.2188"
+ rx="13.317666"
+ ry="4.4124799" />
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+ d="M -4.6361224,63.2188 H 10.606988"
+ id="path81" />
+ </g>
+ <g
+ id="g83"
+ transform="translate(0,40.745853)">
+ <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.0690111"
+ x="-18.502264"
+ y="65.642387"
+ id="text82"><tspan
+ sodipodi:role="line"
+ x="-18.502264"
+ y="65.642387"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;fill:#800000;stroke-width:0.0690111"
+ id="tspan82">HQD</tspan></text>
+ <ellipse
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0"
+ id="ellipse82"
+ cx="-18.407015"
+ cy="63.2188"
+ rx="13.317666"
+ ry="4.4124799" />
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+ d="M -4.6361224,63.2188 H 10.606988"
+ id="path82" />
+ </g>
+ <g
+ id="g84"
+ transform="translate(0,55.033362)">
+ <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.0690111"
+ x="-18.502264"
+ y="65.642387"
+ id="text83"><tspan
+ sodipodi:role="line"
+ x="-18.502264"
+ y="65.642387"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;fill:#800000;stroke-width:0.0690111"
+ id="tspan83">HQD</tspan></text>
+ <ellipse
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0"
+ id="ellipse83"
+ cx="-18.407015"
+ cy="63.2188"
+ rx="13.317666"
+ ry="4.4124799" />
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+ d="M -4.6361224,63.2188 H 10.606988"
+ id="path83" />
+ </g>
+ <g
+ id="g85"
+ transform="translate(0,85.195881)">
+ <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.0690111"
+ x="-18.502264"
+ y="65.642387"
+ id="text84"><tspan
+ sodipodi:role="line"
+ x="-18.502264"
+ y="65.642387"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;fill:#800000;stroke-width:0.0690111"
+ id="tspan84">HQD</tspan></text>
+ <ellipse
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0"
+ id="ellipse84"
+ cx="-18.407015"
+ cy="63.2188"
+ rx="13.317666"
+ ry="4.4124799" />
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+ d="M -4.6361224,63.2188 H 10.606988"
+ id="path84" />
+ </g>
+ <g
+ id="g86"
+ transform="translate(0,99.48339)">
+ <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.0690111"
+ x="-18.502264"
+ y="65.642387"
+ id="text85"><tspan
+ sodipodi:role="line"
+ x="-18.502264"
+ y="65.642387"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;fill:#800000;stroke-width:0.0690111"
+ id="tspan85">HQD</tspan></text>
+ <ellipse
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0"
+ id="ellipse85"
+ cx="-18.407015"
+ cy="63.2188"
+ rx="13.317666"
+ ry="4.4124799" />
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#800000;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+ d="M -4.6361224,63.2188 H 10.606988"
+ id="path85" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:5.64444px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="-35.2131"
+ y="54.673237"
+ id="text86"><tspan
+ sodipodi:role="line"
+ x="-35.2131"
+ y="54.673237"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:5.64444px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan86">Registers</tspan></text>
+ <path
+ style="fill:#800000;fill-opacity:0;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:1, 1;stroke-dashoffset:0;marker-end:url(#ArrowWide)"
+ d="m -45.247972,57.442462 v 5.888987 h 11.344412"
+ id="path86"
+ sodipodi:nodetypes="ccc" />
+ <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.0690111"
+ x="-74.441521"
+ y="82.441582"
+ id="text87"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="82.441582"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan87">MQD</tspan></text>
+ <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.0690111"
+ x="-74.441521"
+ y="99.240776"
+ id="text88"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="99.240776"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan88">MQD</tspan></text>
+ <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.0690111"
+ x="-74.441521"
+ y="116.03998"
+ id="text89"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="116.03998"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan89">MQD</tspan></text>
+ <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.0690111"
+ x="-74.441521"
+ y="132.83917"
+ id="text90"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="132.83917"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan90">MQD</tspan></text>
+ <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.0690111"
+ x="-74.441521"
+ y="168.3002"
+ id="text91"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="168.3002"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:7.05556px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan91">MQD</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:10.5833px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="-74.441521"
+ y="148.1461"
+ id="text92"><tspan
+ sodipodi:role="line"
+ x="-74.441521"
+ y="148.1461"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:10.5833px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;writing-mode:tb-rl;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan92">...</tspan></text>
+ <g
+ id="g97"
+ transform="translate(-5.8208336)">
+ <rect
+ style="fill:#aaffcc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;stroke-dashoffset:0"
+ id="rect96"
+ width="58.726093"
+ height="27.598055"
+ x="-142.96434"
+ y="46.852512" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:4.23333px;line-height:1.25;font-family:sans-serif;text-align:start;letter-spacing:0px;word-spacing:0px;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="-139.74622"
+ y="52.62756"
+ id="text93"><tspan
+ sodipodi:role="line"
+ x="-139.74622"
+ y="52.62756"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan93">HQD Registers</tspan><tspan
+ sodipodi:role="line"
+ x="-139.74622"
+ y="57.91922"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan95">Queue Address in the GPU</tspan><tspan
+ sodipodi:role="line"
+ x="-139.74622"
+ y="63.210884"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan96">Doorbell</tspan><tspan
+ sodipodi:role="line"
+ x="-139.74622"
+ y="68.502548"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan97">...</tspan><tspan
+ sodipodi:role="line"
+ x="-139.74622"
+ y="73.794212"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan94" /></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:4.23333px;line-height:1.25;font-family:sans-serif;text-align:start;letter-spacing:0px;word-spacing:0px;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="-61.293022"
+ y="-19.380915"
+ id="text93-1"><tspan
+ sodipodi:role="line"
+ x="-61.293022"
+ y="-19.380915"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan104">SWITCH QUEUE:</tspan><tspan
+ sodipodi:role="line"
+ x="-61.293022"
+ y="-14.089252"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan101">WAIT FOR HQD_ACTIVE = 0</tspan><tspan
+ sodipodi:role="line"
+ x="-61.293022"
+ y="-8.7975903"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan105">SAVE QUEUE STATE TO THE MQD</tspan><tspan
+ sodipodi:role="line"
+ x="-61.293022"
+ y="-3.505928"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan102">COPY NEW MQD STATE</tspan><tspan
+ sodipodi:role="line"
+ x="-61.293022"
+ y="1.7857342"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:4.23333px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:start;text-anchor:start;stroke-width:0.0690111"
+ id="tspan103">SET HQD_ACTIVE = 1</tspan></text>
+ <circle
+ style="fill:#ffeeaa;fill-opacity:1;stroke:#1a1a1a;stroke-width:1.88976;stroke-dasharray:none;stroke-dashoffset:0"
+ id="path97"
+ cx="0"
+ cy="0"
+ r="0"
+ transform="matrix(0.26458333,0,0,0.26458333,-149.03517,37.347779)" />
+ <text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:5.64444px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.0690111"
+ x="-36.659206"
+ y="-44.828983"
+ id="text106"><tspan
+ sodipodi:role="line"
+ x="-36.659206"
+ y="-44.828983"
+ style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:5.64444px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';text-align:center;text-anchor:middle;stroke-width:0.0690111"
+ id="tspan106">Firmware</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#marker109);marker-end:url(#ArrowTriangleStylized)"
+ d="M -84.242601,-9.1838245 H -98.041629 V 33.17598"
+ id="path106" />
+ <path
+ style="fill:none;fill-opacity:1;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Dot)"
+ d="M 9.9745536,-9.3442784 H 29.549918 V 37.170287"
+ id="path107"
+ sodipodi:nodetypes="ccc" />
+ </g>
+</svg>
diff --git a/Documentation/gpu/amdgpu/process-isolation.rst b/Documentation/gpu/amdgpu/process-isolation.rst
new file mode 100644
index 000000000000..25b06ffefc33
--- /dev/null
+++ b/Documentation/gpu/amdgpu/process-isolation.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================
+ AMDGPU Process Isolation
+=========================
+
+The AMDGPU driver includes a feature that enables automatic process isolation on the graphics engine. This feature serializes access to the graphics engine and adds a cleaner shader which clears the Local Data Store (LDS) and General Purpose Registers (GPRs) between jobs. All processes using the GPU, including both graphics and compute workloads, are serialized when this feature is enabled. On GPUs that support partitionable graphics engines, this feature can be enabled on a per-partition basis.
+
+In addition, there is an interface to manually run the cleaner shader when the use of the GPU is complete. This may be preferable in some use cases, such as a single-user system where the login manager triggers the cleaner shader when the user logs out.
+
+Process Isolation
+=================
+
+The `run_cleaner_shader` and `enforce_isolation` sysfs interfaces allow users to manually execute the cleaner shader and control the process isolation feature, respectively.
+
+Partition Handling
+------------------
+
+The `enforce_isolation` file in sysfs can be used to enable process isolation and automatic shader cleanup between processes. On GPUs that support graphics engine partitioning, this can be enabled per partition. The partition and its current setting (0 disabled, 1 enabled) can be read from sysfs. On GPUs that do not support graphics engine partitioning, only a single partition will be present. Writing 1 to the partition position enables enforce isolation, writing 0 disables it.
+
+Example of enabling enforce isolation on a GPU with multiple partitions:
+
+.. code-block:: console
+
+ $ echo 1 0 1 0 > /sys/class/drm/card0/device/enforce_isolation
+ $ cat /sys/class/drm/card0/device/enforce_isolation
+ 1 0 1 0
+
+The output indicates that enforce isolation is enabled on zeroth and second partition and disabled on first and third partition.
+
+For devices with a single partition or those that do not support partitions, there will be only one element:
+
+.. code-block:: console
+
+ $ echo 1 > /sys/class/drm/card0/device/enforce_isolation
+ $ cat /sys/class/drm/card0/device/enforce_isolation
+ 1
+
+Cleaner Shader Execution
+========================
+
+The driver can trigger a cleaner shader to clean up the LDS and GPR state on the graphics engine. When process isolation is enabled, this happens automatically between processes. In addition, there is a sysfs file to manually trigger cleaner shader execution.
+
+To manually trigger the execution of the cleaner shader, write `0` to the `run_cleaner_shader` sysfs file:
+
+.. code-block:: console
+
+ $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader
+
+For multi-partition devices, you can specify the partition index when triggering the cleaner shader:
+
+.. code-block:: console
+
+ $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 0
+ $ echo 1 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 1
+ $ echo 2 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 2
+ # ... and so on for each partition
+
+This command initiates the cleaner shader, which will run and complete before any new tasks are scheduled on the GPU.
diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst
index 5e27e4eb3959..1768a106aab1 100644
--- a/Documentation/gpu/amdgpu/thermal.rst
+++ b/Documentation/gpu/amdgpu/thermal.rst
@@ -49,6 +49,12 @@ pp_power_profile_mode
.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: pp_power_profile_mode
+pm_policy
+---------------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: pm_policy
+
\*_busy_percent
---------------
@@ -64,6 +70,48 @@ gpu_metrics
.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: gpu_metrics
+fan_curve
+---------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: fan_curve
+
+acoustic_limit_rpm_threshold
+----------------------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: acoustic_limit_rpm_threshold
+
+acoustic_target_rpm_threshold
+-----------------------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: acoustic_target_rpm_threshold
+
+fan_target_temperature
+----------------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: fan_target_temperature
+
+fan_minimum_pwm
+---------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: fan_minimum_pwm
+
+fan_zero_rpm_enable
+----------------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: fan_zero_rpm_enable
+
+fan_zero_rpm_stop_temperature
+-----------------------------
+
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
+ :doc: fan_zero_rpm_stop_temperature
+
GFXOFF
======
diff --git a/Documentation/gpu/amdgpu/userq.rst b/Documentation/gpu/amdgpu/userq.rst
new file mode 100644
index 000000000000..ca3ea71f7888
--- /dev/null
+++ b/Documentation/gpu/amdgpu/userq.rst
@@ -0,0 +1,203 @@
+==================
+ User Mode Queues
+==================
+
+Introduction
+============
+
+Similar to the KFD, GPU engine queues move into userspace. The idea is to let
+user processes manage their submissions to the GPU engines directly, bypassing
+IOCTL calls to the driver to submit work. This reduces overhead and also allows
+the GPU to submit work to itself. Applications can set up work graphs of jobs
+across multiple GPU engines without needing trips through the CPU.
+
+UMDs directly interface with firmware via per application shared memory areas.
+The main vehicle for this is queue. A queue is a ring buffer with a read
+pointer (rptr) and a write pointer (wptr). The UMD writes IP specific packets
+into the queue and the firmware processes those packets, kicking off work on the
+GPU engines. The CPU in the application (or another queue or device) updates
+the wptr to tell the firmware how far into the ring buffer to process packets
+and the rtpr provides feedback to the UMD on how far the firmware has progressed
+in executing those packets. When the wptr and the rptr are equal, the queue is
+idle.
+
+Theory of Operation
+===================
+
+The various engines on modern AMD GPUs support multiple queues per engine with a
+scheduling firmware which handles dynamically scheduling user queues on the
+available hardware queue slots. When the number of user queues outnumbers the
+available hardware queue slots, the scheduling firmware dynamically maps and
+unmaps queues based on priority and time quanta. The state of each user queue
+is managed in the kernel driver in an MQD (Memory Queue Descriptor). This is a
+buffer in GPU accessible memory that stores the state of a user queue. The
+scheduling firmware uses the MQD to load the queue state into an HQD (Hardware
+Queue Descriptor) when a user queue is mapped. Each user queue requires a
+number of additional buffers which represent the ring buffer and any metadata
+needed by the engine for runtime operation. On most engines this consists of
+the ring buffer itself, a rptr buffer (where the firmware will shadow the rptr
+to userspace), a wptr buffer (where the application will write the wptr for the
+firmware to fetch it), and a doorbell. A doorbell is a piece of one of the
+device's MMIO BARs which can be mapped to specific user queues. When the
+application writes to the doorbell, it will signal the firmware to take some
+action. Writing to the doorbell wakes the firmware and causes it to fetch the
+wptr and start processing the packets in the queue. Each 4K page of the doorbell
+BAR supports specific offset ranges for specific engines. The doorbell of a
+queue must be mapped into the aperture aligned to the IP used by the queue
+(e.g., GFX, VCN, SDMA, etc.). These doorbell apertures are set up via NBIO
+registers. Doorbells are 32 bit or 64 bit (depending on the engine) chunks of
+the doorbell BAR. A 4K doorbell page provides 512 64-bit doorbells for up to
+512 user queues. A subset of each page is reserved for each IP type supported
+on the device. The user can query the doorbell ranges for each IP via the INFO
+IOCTL. See the IOCTL Interfaces section for more information.
+
+When an application wants to create a user queue, it allocates the necessary
+buffers for the queue (ring buffer, wptr and rptr, context save areas, etc.).
+These can be separate buffers or all part of one larger buffer. The application
+would map the buffer(s) into its GPUVM and use the GPU virtual addresses of for
+the areas of memory they want to use for the user queue. They would also
+allocate a doorbell page for the doorbells used by the user queues. The
+application would then populate the MQD in the USERQ IOCTL structure with the
+GPU virtual addresses and doorbell index they want to use. The user can also
+specify the attributes for the user queue (priority, whether the queue is secure
+for protected content, etc.). The application would then call the USERQ
+CREATE IOCTL to create the queue using the specified MQD details in the IOCTL.
+The kernel driver then validates the MQD provided by the application and
+translates the MQD into the engine specific MQD format for the IP. The IP
+specific MQD would be allocated and the queue would be added to the run list
+maintained by the scheduling firmware. Once the queue has been created, the
+application can write packets directly into the queue, update the wptr, and
+write to the doorbell offset to kick off work in the user queue.
+
+When the application is done with the user queue, it would call the USERQ
+FREE IOCTL to destroy it. The kernel driver would preempt the queue and
+remove it from the scheduling firmware's run list. Then the IP specific MQD
+would be freed and the user queue state would be cleaned up.
+
+Some engines may require the aggregated doorbell too if the engine does not
+support doorbells from unmapped queues. The aggregated doorbell is a special
+page of doorbell space which wakes the scheduler. In cases where the engine may
+be oversubscribed, some queues may not be mapped. If the doorbell is rung when
+the queue is not mapped, the engine firmware may miss the request. Some
+scheduling firmware may work around this by polling wptr shadows when the
+hardware is oversubscribed, other engines may support doorbell updates from
+unmapped queues. In the event that one of these options is not available, the
+kernel driver will map a page of aggregated doorbell space into each GPUVM
+space. The UMD will then update the doorbell and wptr as normal and then write
+to the aggregated doorbell as well.
+
+Special Packets
+---------------
+
+In order to support legacy implicit synchronization, as well as mixed user and
+kernel queues, we need a synchronization mechanism that is secure. Because
+kernel queues or memory management tasks depend on kernel fences, we need a way
+for user queues to update memory that the kernel can use for a fence, that can't
+be messed with by a bad actor. To support this, we've added a protected fence
+packet. This packet works by writing a monotonically increasing value to
+a memory location that only privileged clients have write access to. User
+queues only have read access. When this packet is executed, the memory location
+is updated and other queues (kernel or user) can see the results. The
+user application would submit this packet in their command stream. The actual
+packet format varies from IP to IP (GFX/Compute, SDMA, VCN, etc.), but the
+behavior is the same. The packet submission is handled in userspace. The
+kernel driver sets up the privileged memory used for each user queue when it
+sets the queues up when the application creates them.
+
+
+Memory Management
+=================
+
+It is assumed that all buffers mapped into the GPUVM space for the process are
+valid when engines on the GPU are running. The kernel driver will only allow
+user queues to run when all buffers are mapped. If there is a memory event that
+requires buffer migration, the kernel driver will preempt the user queues,
+migrate buffers to where they need to be, update the GPUVM page tables and
+invaldidate the TLB, and then resume the user queues.
+
+Interaction with Kernel Queues
+==============================
+
+Depending on the IP and the scheduling firmware, you can enable kernel queues
+and user queues at the same time, however, you are limited by the HQD slots.
+Kernel queues are always mapped so any work that goes into kernel queues will
+take priority. This limits the available HQD slots for user queues.
+
+Not all IPs will support user queues on all GPUs. As such, UMDs will need to
+support both user queues and kernel queues depending on the IP. For example, a
+GPU may support user queues for GFX, compute, and SDMA, but not for VCN, JPEG,
+and VPE. UMDs need to support both. The kernel driver provides a way to
+determine if user queues and kernel queues are supported on a per IP basis.
+UMDs can query this information via the INFO IOCTL and determine whether to use
+kernel queues or user queues for each IP.
+
+Queue Resets
+============
+
+For most engines, queues can be reset individually. GFX, compute, and SDMA
+queues can be reset individually. When a hung queue is detected, it can be
+reset either via the scheduling firmware or MMIO. Since there are no kernel
+fences for most user queues, they will usually only be detected when some other
+event happens; e.g., a memory event which requires migration of buffers. When
+the queues are preempted, if the queue is hung, the preemption will fail.
+Driver will then look up the queues that failed to preempt and reset them and
+record which queues are hung.
+
+On the UMD side, we will add a USERQ QUERY_STATUS IOCTL to query the queue
+status. UMD will provide the queue id in the IOCTL and the kernel driver
+will check if it has already recorded the queue as hung (e.g., due to failed
+peemption) and report back the status.
+
+IOCTL Interfaces
+================
+
+GPU virtual addresses used for queues and related data (rptrs, wptrs, context
+save areas, etc.) should be validated by the kernel mode driver to prevent the
+user from specifying invalid GPU virtual addresses. If the user provides
+invalid GPU virtual addresses or doorbell indicies, the IOCTL should return an
+error message. These buffers should also be tracked in the kernel driver so
+that if the user attempts to unmap the buffer(s) from the GPUVM, the umap call
+would return an error.
+
+INFO
+----
+There are several new INFO queries related to user queues in order to query the
+size of user queue meta data needed for a user queue (e.g., context save areas
+or shadow buffers), whether kernel or user queues or both are supported
+for each IP type, and the offsets for each IP type in each doorbell page.
+
+USERQ
+-----
+The USERQ IOCTL is used for creating, freeing, and querying the status of user
+queues. It supports 3 opcodes:
+
+1. CREATE - Create a user queue. The application provides an MQD-like structure
+ that defines the type of queue and associated metadata and flags for that
+ queue type. Returns the queue id.
+2. FREE - Free a user queue.
+3. QUERY_STATUS - Query that status of a queue. Used to check if the queue is
+ healthy or not. E.g., if the queue has been reset. (WIP)
+
+USERQ_SIGNAL
+------------
+The USERQ_SIGNAL IOCTL is used to provide a list of sync objects to be signaled.
+
+USERQ_WAIT
+----------
+The USERQ_WAIT IOCTL is used to provide a list of sync object to be waited on.
+
+Kernel and User Queues
+======================
+
+In order to properly validate and test performance, we have a driver option to
+select what type of queues are enabled (kernel queues, user queues or both).
+The user_queue driver parameter allows you to enable kernel queues only (0),
+user queues and kernel queues (1), and user queues only (2). Enabling user
+queues only will free up static queue assignments that would otherwise be used
+by kernel queues for use by the scheduling firmware. Some kernel queues are
+required for kernel driver operation and they will always be created. When the
+kernel queues are not enabled, they are not registered with the drm scheduler
+and the CS IOCTL will reject any incoming command submissions which target those
+queue types. Kernel queues only mirrors the behavior on all existing GPUs.
+Enabling both queues allows for backwards compatibility with old userspace while
+still supporting user queues.
diff --git a/Documentation/gpu/automated_testing.rst b/Documentation/gpu/automated_testing.rst
new file mode 100644
index 000000000000..62aa3ede02a5
--- /dev/null
+++ b/Documentation/gpu/automated_testing.rst
@@ -0,0 +1,171 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+=========================================
+Automated testing of the DRM subsystem
+=========================================
+
+Introduction
+============
+
+Making sure that changes to the core or drivers don't introduce regressions can
+be very time-consuming when lots of different hardware configurations need to
+be tested. Moreover, it isn't practical for each person interested in this
+testing to have to acquire and maintain what can be a considerable amount of
+hardware.
+
+Also, it is desirable for developers to check for regressions in their code by
+themselves, instead of relying on the maintainers to find them and then
+reporting back.
+
+There are facilities in gitlab.freedesktop.org to automatically test Mesa that
+can be used as well for testing the DRM subsystem. This document explains how
+people interested in testing it can use this shared infrastructure to save
+quite some time and effort.
+
+
+Relevant files
+==============
+
+drivers/gpu/drm/ci/gitlab-ci.yml
+--------------------------------
+
+This is the root configuration file for GitLab CI. Among other less interesting
+bits, it specifies the specific version of the scripts to be used. There are
+some variables that can be modified to change the behavior of the pipeline:
+
+DRM_CI_PROJECT_PATH
+ Repository that contains the Mesa software infrastructure for CI
+
+DRM_CI_COMMIT_SHA
+ A particular revision to use from that repository
+
+UPSTREAM_REPO
+ URL to git repository containing the target branch
+
+TARGET_BRANCH
+ Branch to which this branch is to be merged into
+
+IGT_VERSION
+ Revision of igt-gpu-tools being used, from
+ https://gitlab.freedesktop.org/drm/igt-gpu-tools
+
+drivers/gpu/drm/ci/testlist.txt
+-------------------------------
+
+IGT tests to be run on all drivers (unless mentioned in a driver's \*-skips.txt
+file, see below).
+
+drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-fails.txt
+----------------------------------------------------------
+
+Lists the known failures for a given driver on a specific hardware revision.
+
+drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-flakes.txt
+-----------------------------------------------------------
+
+Lists the tests that for a given driver on a specific hardware revision are
+known to behave unreliably. These tests won't cause a job to fail regardless of
+the result. They will still be run.
+
+Each new flake entry must be associated with a link to the email reporting the
+bug to the author of the affected driver or the relevant GitLab issue. The entry
+must also include the board name or Device Tree name, the first kernel version
+affected, the IGT version used for tests, and an approximation of the failure rate.
+
+They should be provided under the following format::
+
+ # Bug Report: $LORE_URL_OR_GITLAB_ISSUE
+ # Board Name: broken-board.dtb
+ # Linux Version: 6.6-rc1
+ # IGT Version: 1.28-gd2af13d9f
+ # Failure Rate: 100
+ 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
+-----------------------------------------------------------
+
+Lists the tests that won't be run for a given driver on a specific hardware
+revision. These are usually tests that interfere with the running of the test
+list due to hanging the machine, causing OOM, taking too long, etc.
+
+
+How to enable automated testing on your tree
+============================================
+
+1. Create a Linux tree in https://gitlab.freedesktop.org/ if you don't have one
+yet
+
+2. In your kernel repo's configuration (eg.
+https://gitlab.freedesktop.org/janedoe/linux/-/settings/ci_cd), change the
+CI/CD configuration file from .gitlab-ci.yml to
+drivers/gpu/drm/ci/gitlab-ci.yml.
+
+3. Request to be added to the drm/ci-ok group so that your user has the
+necessary privileges to run the CI on https://gitlab.freedesktop.org/drm/ci-ok
+
+4. Next time you push to this repository, you will see a CI pipeline being
+created (eg. https://gitlab.freedesktop.org/janedoe/linux/-/pipelines)
+
+5. The various jobs will be run and when the pipeline is finished, all jobs
+should be green unless a regression has been found.
+
+6. Warnings in the pipeline indicate that lockdep
+(see Documentation/locking/lockdep-design.rst) issues have been detected
+during the tests.
+
+
+How to update test expectations
+===============================
+
+If your changes to the code fix any tests, you will have to remove one or more
+lines from one or more of the files in
+drivers/gpu/drm/ci/${DRIVER_NAME}_*_fails.txt, for each of the test platforms
+affected by the change.
+
+
+How to expand coverage
+======================
+
+If your code changes make it possible to run more tests (by solving reliability
+issues, for example), you can remove tests from the flakes and/or skips lists,
+and then the expected results if there are any known failures.
+
+If there is a need for updating the version of IGT being used (maybe you have
+added more tests to it), update the IGT_VERSION variable at the top of the
+gitlab-ci.yml file.
+
+
+How to test your changes to the scripts
+=======================================
+
+For testing changes to the scripts in the drm-ci repo, change the
+DRM_CI_PROJECT_PATH and DRM_CI_COMMIT_SHA variables in
+drivers/gpu/drm/ci/gitlab-ci.yml to match your fork of the project (eg.
+janedoe/drm-ci). This fork needs to be in https://gitlab.freedesktop.org/.
+
+
+How to incorporate external fixes in your testing
+=================================================
+
+Often, regressions in other trees will prevent testing changes local to the
+tree under test. These fixes will be automatically merged in during the build
+jobs from a branch in the target tree that is named as
+${TARGET_BRANCH}-external-fixes.
+
+If the pipeline is not in a merge request and a branch with the same name
+exists in the local tree, commits from that branch will be merged in as well.
+
+
+How to deal with automated testing labs that may be down
+========================================================
+
+If a hardware farm is down and thus causing pipelines to fail that would
+otherwise pass, one can disable all jobs that would be submitted to that farm
+by editing the file at
+https://gitlab.freedesktop.org/gfx-ci/lab-status/-/blob/main/lab-status.yml.
diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst
index 4411e6919a3d..1f15a8ca1265 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,29 @@ drm/i915 uAPI
=============
.. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+================
+
+VM_BIND / EXEC uAPI
+-------------------
+
+.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
+
+drm/panthor uAPI
+================
+
+.. kernel-doc:: include/uapi/drm/panthor_drm.h
+
+drm/xe uAPI
+===========
+
+.. kernel-doc:: include/uapi/drm/xe_drm.h
+
+drm/asahi uAPI
+================
+
+.. kernel-doc:: include/uapi/drm/asahi_drm.h
diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
index 3a52f48215a3..78b80be17f21 100644
--- a/Documentation/gpu/drivers.rst
+++ b/Documentation/gpu/drivers.rst
@@ -3,11 +3,14 @@ GPU Driver Documentation
========================
.. toctree::
+ :maxdepth: 3
amdgpu/index
i915
+ imagination/index
mcde
meson
+ nouveau
pl111
tegra
tve200
@@ -16,8 +19,13 @@ GPU Driver Documentation
vkms
bridge/dw-hdmi
xen-front
+ xe/index
afbc
komeda-kms
+ panfrost
+ panthor
+ zynqmp
+ nova/index
.. only:: subproject and html
diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst
index 58b5a1d1219d..cbcfe30de777 100644
--- a/Documentation/gpu/drm-client.rst
+++ b/Documentation/gpu/drm-client.rst
@@ -13,3 +13,6 @@ Kernel clients
.. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c
:export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_client_event.c
+ :export:
diff --git a/Documentation/gpu/drm-compute.rst b/Documentation/gpu/drm-compute.rst
new file mode 100644
index 000000000000..f90c3e63aa9e
--- /dev/null
+++ b/Documentation/gpu/drm-compute.rst
@@ -0,0 +1,54 @@
+==================================
+Long running workloads and compute
+==================================
+
+Long running workloads (compute) are workloads that will not complete in 10
+seconds. (The time let the user wait before he reaches for the power button).
+This means that other techniques need to be used to manage those workloads,
+that cannot use fences.
+
+Some hardware may schedule compute jobs, and have no way to pre-empt them, or
+have their memory swapped out from them. Or they simply want their workload
+not to be preempted or swapped out at all.
+
+This means that it differs from what is described in driver-api/dma-buf.rst.
+
+As with normal compute jobs, dma-fence may not be used at all. In this case,
+not even to force preemption. The driver with is simply forced to unmap a BO
+from the long compute job's address space on unbind immediately, not even
+waiting for the workload to complete. Effectively this terminates the workload
+when there is no hardware support to recover.
+
+Since this is undesirable, there need to be mitigations to prevent a workload
+from being terminated. There are several possible approach, all with their
+advantages and drawbacks.
+
+The first approach you will likely try is to pin all buffers used by compute.
+This guarantees that the job will run uninterrupted, but also allows a very
+denial of service attack by pinning as much memory as possible, hogging the
+all GPU memory, and possibly a huge chunk of CPU memory.
+
+A second approach that will work slightly better on its own is adding an option
+not to evict when creating a new job (any kind). If all of userspace opts in
+to this flag, it would prevent cooperating userspace from forced terminating
+older compute jobs to start a new one.
+
+If job preemption and recoverable pagefaults are not available, those are the
+only approaches possible. So even with those, you want a separate way of
+controlling resources. The standard kernel way of doing so is cgroups.
+
+This creates a third option, using cgroups to prevent eviction. Both GPU and
+driver-allocated CPU memory would be accounted to the correct cgroup, and
+eviction would be made cgroup aware. This allows the GPU to be partitioned
+into cgroups, that will allow jobs to run next to each other without
+interference.
+
+The interface to the cgroup would be similar to the current CPU memory
+interface, with similar semantics for min/low/high/max, if eviction can
+be made cgroup aware.
+
+What should be noted is that each memory region (tiled memory for example)
+should have its own accounting.
+
+The key is set to the regionid set by the driver, for example "tile0".
+For the value of $card, we use drmGetUnique().
diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
index 5fd20a306718..94f93fd3b8a0 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -57,8 +57,8 @@ is larger than the driver minor, the DRM_IOCTL_SET_VERSION call will
return an error. Otherwise the driver's set_version() method will be
called with the requested version.
-Name, Description and Date
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Name and Description
+~~~~~~~~~~~~~~~~~~~~
char \*name; char \*desc; char \*date;
The driver name is printed to the kernel log at initialization time,
@@ -69,30 +69,12 @@ The driver description is a purely informative string passed to
userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by
the kernel.
-The driver date, formatted as YYYYMMDD, is meant to identify the date of
-the latest modification to the driver. However, as most drivers fail to
-update it, its value is mostly useless. The DRM core prints it to the
-kernel log at initialization time and passes it to userspace through the
-DRM_IOCTL_VERSION ioctl.
-
Module Initialization
---------------------
.. kernel-doc:: include/drm/drm_module.h
: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
-----------------------------------
@@ -153,18 +135,6 @@ Managed Resources
.. kernel-doc:: include/drm/drm_managed.h
:internal:
-Bus-specific Device Registration and PCI Support
-------------------------------------------------
-
-A number of functions are provided to help with device registration. The
-functions deal with PCI and platform devices respectively and are only
-provided for historical reasons. These are all deprecated and shouldn't
-be used in new drivers. Besides that there's a few helpers for pci
-drivers.
-
-.. kernel-doc:: drivers/gpu/drm/drm_pci.c
- :export:
-
Open/Close, File Operations and IOCTLs
======================================
@@ -238,6 +208,13 @@ follows:
``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not
included in it because they are only required for User Mode Linux.
+KUnit Coverage Rules
+~~~~~~~~~~~~~~~~~~~~
+
+KUnit support is gradually added to the DRM framework and helpers. There's no
+general requirement for the framework and helpers to have KUnit tests at the
+moment. However, patches that are affecting a function or helper already
+covered by KUnit tests must provide tests if the change calls for one.
Legacy Support Code
===================
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index dbc85fd7a971..781129f78b06 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -92,6 +92,18 @@ GEM Atomic Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c
:export:
+VBLANK Helper Reference
+-----------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_vblank_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c
+ :export:
+
Simple KMS Helper Reference
===========================
@@ -172,7 +184,7 @@ Bridge Operations
Bridge Connector Helper
-----------------------
-.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c
:doc: overview
@@ -185,10 +197,17 @@ Bridge Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:
+MIPI-DSI bridge operation
+-------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+ :doc: dsi bridge operations
+
+
Bridge Connector Helper Reference
---------------------------------
-.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c
+.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c
:export:
Panel-Bridge Helper Reference
@@ -214,6 +233,9 @@ Panel Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
+.. kernel-doc:: drivers/gpu/drm/drm_panel_backlight_quirks.c
+ :export:
+
Panel Self Refresh Helper Reference
===================================
@@ -223,6 +245,21 @@ Panel Self Refresh Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_self_refresh_helper.c
:export:
+HDMI Atomic State Helpers
+=========================
+
+Overview
+--------
+
+.. kernel-doc:: drivers/gpu/drm/display/drm_hdmi_state_helper.c
+ :doc: hdmi helpers
+
+Functions Reference
+-------------------
+
+.. kernel-doc:: drivers/gpu/drm/display/drm_hdmi_state_helper.c
+ :export:
+
HDCP Helper Functions Reference
===============================
@@ -353,6 +390,12 @@ EDID Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:
+.. kernel-doc:: include/drm/drm_eld.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_eld.c
+ :export:
+
SCDC Helper Functions Reference
===============================
@@ -368,7 +411,7 @@ SCDC Helper Functions Reference
HDMI Infoframes Helper Reference
================================
-Strictly speaking this is not a DRM helper library but generally useable
+Strictly speaking this is not a DRM helper library but generally usable
by any driver interfacing with HDMI outputs like v4l or alsa drivers.
But it nicely fits into the overall topic of mode setting helper
libraries and hence is also included here.
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index b4377a545425..2292e65f044c 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -66,11 +66,11 @@ Composition Properties`_ and related chapters.
For the output routing the first step is encoders (represented by
:c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those
are really just internal artifacts of the helper libraries used to implement KMS
-drivers. Besides that they make it unecessarily more complicated for userspace
+drivers. Besides that they make it unnecessarily more complicated for userspace
to figure out which connections between a CRTC and a connector are possible, and
what kind of cloning is supported, they serve no purpose in the userspace API.
Unfortunately encoders have been exposed to userspace, hence can't remove them
-at this point. Futhermore the exposed restrictions are often wrongly set by
+at this point. Furthermore the exposed restrictions are often wrongly set by
drivers, and in many cases not powerful enough to express the real restrictions.
A CRTC can be connected to multiple encoders, and for an active CRTC there must
be at least one encoder.
@@ -260,7 +260,7 @@ Taken all together there's two consequences for the atomic design:
drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct
drm_connector_state <drm_connector_state>` for connectors. These are the only
objects with userspace-visible and settable state. For internal state drivers
- can subclass these structures through embeddeding, or add entirely new state
+ can subclass these structures through embedding, or add entirely new state
structures for their globally shared hardware functions, see :c:type:`struct
drm_private_state<drm_private_state>`.
@@ -360,6 +360,8 @@ Format Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_fourcc.c
:export:
+.. _kms_dumb_buffer_objects:
+
Dumb Buffer Objects
===================
@@ -396,6 +398,36 @@ Plane Damage Tracking Functions Reference
.. kernel-doc:: include/drm/drm_damage_helper.h
:internal:
+Plane Panic Feature
+-------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_panic.c
+ :doc: overview
+
+Plane Panic Functions Reference
+-------------------------------
+
+.. kernel-doc:: include/drm/drm_panic.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_panic.c
+ :export:
+
+Colorop Abstraction
+===================
+
+.. kernel-doc:: drivers/gpu/drm/drm_colorop.c
+ :doc: overview
+
+Colorop Functions Reference
+---------------------------
+
+.. kernel-doc:: include/drm/drm_colorop.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_colorop.c
+ :export:
+
Display Modes Function Reference
================================
@@ -494,6 +526,13 @@ addition to the one mentioned above:
* An IGT test must be submitted where reasonable.
+For historical reasons, non-standard, driver-specific properties exist. If a KMS
+driver wants to add support for one of those properties, the requirements for
+new properties apply where possible. Additionally, the documented behavior must
+match the de facto semantics of the existing property to ensure compatibility.
+Developers of the driver that first added the property should help with those
+tasks and must ACK the documented behavior if possible.
+
Property Types and Blob Property Support
----------------------------------------
@@ -520,6 +559,12 @@ HDMI Specific Connector Properties
.. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: HDMI connector properties
+Analog TV Specific Connector Properties
+---------------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: Analog TV Connector Properties
+
Standard CRTC Properties
------------------------
@@ -540,6 +585,8 @@ Plane Composition Properties
.. kernel-doc:: drivers/gpu/drm/drm_blend.c
:doc: overview
+.. _damage_tracking_properties:
+
Damage Tracking Properties
--------------------------
@@ -571,6 +618,12 @@ Variable Refresh Properties
.. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: Variable refresh properties
+Cursor Hotspot Properties
+---------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: hotspot properties
+
Existing KMS Properties
-----------------------
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd3549ff8..d55751cad67c 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,46 @@ DRM MM Range Allocator Function References
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
+.. _drm_gpuvm:
+
+DRM GPUVM
+=========
+
+Overview
+--------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
+ :doc: Overview
+
+Split and Merge
+---------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
+ :doc: Split and Merge
+
+.. _drm_gpuvm_locking:
+
+Locking
+-------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
+ :doc: Locking
+
+Examples
+--------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
+ :doc: Examples
+
+DRM GPUVM Function References
+-----------------------------
+
+.. kernel-doc:: include/drm/drm_gpuvm.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
+ :export:
+
DRM Buddy Allocator
===================
@@ -481,8 +521,10 @@ DRM Cache Handling and Fast WC memcpy()
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+.. _drm_sync_objects:
+
DRM Sync Objects
-===========================
+================
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:doc: Overview
@@ -493,6 +535,18 @@ DRM Sync Objects
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
+DRM Execution context
+=====================
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+ :export:
+
GPU Scheduler
=============
@@ -502,6 +556,12 @@ Overview
.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
:doc: Overview
+Flow Control
+------------
+
+.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
+ :doc: Flow Control
+
Scheduler Function References
-----------------------------
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index ce47b4292481..d98428a592f1 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -285,6 +285,256 @@ for GPU1 and GPU2 from different vendors, and a third handler for
mmapped regular files. Threads cause additional pain with signal
handling as well.
+Device reset
+============
+
+The GPU stack is really complex and is prone to errors, from hardware bugs,
+faulty applications and everything in between the many layers. Some errors
+require resetting the device in order to make the device usable again. This
+section describes the expectations for DRM and usermode drivers when a
+device resets and how to propagate the reset status.
+
+Device resets can not be disabled without tainting the kernel, which can lead to
+hanging the entire kernel through shrinkers/mmu_notifiers. Userspace role in
+device resets is to propagate the message to the application and apply any
+special policy for blocking guilty applications, if any. Corollary is that
+debugging a hung GPU context require hardware support to be able to preempt such
+a GPU context while it's stopped.
+
+Kernel Mode Driver
+------------------
+
+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.
+
+Propagation of errors to userspace has proven to be tricky since it goes in
+the opposite direction of the usual flow of commands. Because of this vendor
+independent error handling was added to the &dma_fence object, this way drivers
+can add an error code to their fences before signaling them. See function
+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
+----------------
+
+After command submission, UMD should check if the submission was accepted or
+rejected. After a reset, KMD should reject submissions, and UMD can issue an
+ioctl to the KMD to check the reset status, and this can be checked more often
+if the UMD requires it. After detecting a reset, UMD will then proceed to report
+it to the application using the appropriate API error code, as explained in the
+section below about robustness.
+
+Robustness
+----------
+
+The only way to try to keep a graphical API context working after a reset is if
+it complies with the robustness aspects of the graphical API that it is using.
+
+Graphical APIs provide ways to applications to deal with device resets. However,
+there is no guarantee that the app will use such features correctly, and a
+userspace that doesn't support robust interfaces (like a non-robust
+OpenGL context or API without any robustness support like libva) leave the
+robustness handling entirely to the userspace driver. There is no strong
+community consensus on what the userspace driver should do in that case,
+since all reasonable approaches have some clear downsides.
+
+OpenGL
+~~~~~~
+
+Apps using OpenGL should use the available robust interfaces, like the
+extension ``GL_ARB_robustness`` (or ``GL_EXT_robustness`` for OpenGL ES). This
+interface tells if a reset has happened, and if so, all the context state is
+considered lost and the app proceeds by creating new ones. There's no consensus
+on what to do to if robustness is not in use.
+
+Vulkan
+~~~~~~
+
+Apps using Vulkan should check for ``VK_ERROR_DEVICE_LOST`` for submissions.
+This error code means, among other things, that a device reset has happened and
+it needs to recreate the contexts to keep going.
+
+Reporting causes of resets
+--------------------------
+
+Apart from propagating the reset through the stack so apps can recover, it's
+really useful for driver developers to learn more about what caused the reset in
+the first place. For this, drivers can make use of devcoredump to store relevant
+information about the reset and send device wedged event with ``none`` recovery
+method (as explained in "Device Wedging" chapter) to notify userspace, so this
+information can be collected and added to user bug reports.
+
+Device Wedging
+==============
+
+Drivers can optionally make use of device wedged event (implemented as
+drm_dev_wedged_event() in DRM subsystem), which notifies userspace of 'wedged'
+(hanged/unusable) state of the DRM device through a uevent. This is useful
+especially in cases where the device is no longer operating as expected and has
+become unrecoverable from driver context. Purpose of this implementation is to
+provide drivers a generic way to recover the device with the help of userspace
+intervention, without taking any drastic measures (like resetting or
+re-enumerating the full bus, on which the underlying physical device is sitting)
+in the driver.
+
+A 'wedged' device is basically a device that is declared dead by the driver
+after exhausting all possible attempts to recover it from driver context. The
+uevent is the notification that is sent to userspace along with a hint about
+what could possibly be attempted to recover the device from userspace and bring
+it back to usable state. Different drivers may have different ideas of a
+'wedged' device depending on hardware implementation of the underlying physical
+device, and hence the vendor agnostic nature of the event. It is up to the
+drivers to decide when they see the need for device recovery and how they want
+to recover from the available methods.
+
+Driver prerequisites
+--------------------
+
+The driver, before opting for recovery, needs to make sure that the 'wedged'
+device doesn't harm the system as a whole by taking care of the prerequisites.
+Necessary actions must include disabling DMA to system memory as well as any
+communication channels with other devices. Further, the driver must ensure
+that all dma_fences are signalled and any device state that the core kernel
+might depend on is cleaned up. All existing mmaps should be invalidated and
+page faults should be redirected to a dummy page. Once the event is sent, the
+device must be kept in 'wedged' state until the recovery is performed. New
+accesses to the device (IOCTLs) should be rejected, preferably with an error
+code that resembles the type of failure the device has encountered. This will
+signify the reason for wedging, which can be reported to the application if
+needed.
+
+Recovery
+--------
+
+Current implementation defines four recovery methods, out of which, drivers
+can use any one, multiple or none. Method(s) of choice will be sent in the
+uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in order of less to
+more side-effects. See the section `Vendor Specific Recovery`_
+for ``WEDGED=vendor-specific``. If driver is unsure about recovery or
+method is unknown, ``WEDGED=unknown`` will be sent instead.
+
+Userspace consumers can parse this event and attempt recovery as per the
+following expectations.
+
+ =============== ========================================
+ Recovery method Consumer expectations
+ =============== ========================================
+ none optional telemetry collection
+ rebind unbind + bind driver
+ bus-reset unbind + bus reset/re-enumeration + bind
+ vendor-specific vendor specific recovery method
+ unknown consumer policy
+ =============== ========================================
+
+The only exception to this is ``WEDGED=none``, which signifies that the device
+was temporarily 'wedged' at some point but was recovered from driver context
+using device specific methods like reset. No explicit recovery is expected from
+the consumer in this case, but it can still take additional steps like gathering
+telemetry information (devcoredump, syslog). This is useful because the first
+hang is usually the most critical one which can result in consequential hangs or
+complete wedging.
+
+
+Vendor Specific Recovery
+------------------------
+
+When ``WEDGED=vendor-specific`` is sent, it indicates that the device requires
+a recovery procedure specific to the hardware vendor and is not one of the
+standardized approaches.
+
+``WEDGED=vendor-specific`` may be used to indicate different cases within a
+single vendor driver, each requiring a distinct recovery procedure.
+In such scenarios, the vendor driver must provide comprehensive documentation
+that describes each case, include additional hints to identify specific case and
+outline the corresponding recovery procedure. The documentation includes:
+
+Case - A list of all cases that sends the ``WEDGED=vendor-specific`` recovery method.
+
+Hints - Additional Information to assist the userspace consumer in identifying and
+differentiating between different cases. This can be exposed through sysfs, debugfs,
+traces, dmesg etc.
+
+Recovery Procedure - Clear instructions and guidance for recovering each case.
+This may include userspace scripts, tools needed for the recovery procedure.
+
+It is the responsibility of the admin/userspace consumer to identify the case and
+verify additional identification hints before attempting a recovery procedure.
+
+Example: If the device uses the Xe driver, then userspace consumer should refer to
+:ref:`Xe Device Wedging <xe-device-wedging>` for the detailed documentation.
+
+Task information
+----------------
+
+The information about which application (if any) was involved in the device
+wedging is useful for userspace if they want to notify the user about what
+happened (e.g. the compositor display a message to the user "The <task name>
+caused a graphical error and the system recovered") or to implement policies
+(e.g. the daemon may "ban" an task that keeps resetting the device). If the task
+information is available, the uevent will display as ``PID=<pid>`` and
+``TASK=<task name>``. Otherwise, ``PID`` and ``TASK`` will not appear in the
+event string.
+
+The reliability of this information is driver and hardware specific, and should
+be taken with a caution regarding it's precision. To have a big picture of what
+really happened, the devcoredump file provides much more detailed information
+about the device state and about the event.
+
+Consumer prerequisites
+----------------------
+
+It is the responsibility of the consumer to make sure that the device or its
+resources are not in use by any process before attempting recovery. With IOCTLs
+erroring out, all device memory should be unmapped and file descriptors should
+be closed to prevent leaks or undefined behaviour. The idea here is to clear the
+device of all user context beforehand and set the stage for a clean recovery.
+
+For ``WEDGED=vendor-specific`` recovery method, it is the responsibility of the
+consumer to check the driver documentation and the usecase before attempting
+a recovery.
+
+Example - rebind
+----------------
+
+Udev rule::
+
+ SUBSYSTEM=="drm", ENV{WEDGED}=="rebind", DEVPATH=="*/drm/card[0-9]",
+ RUN+="/path/to/rebind.sh $env{DEVPATH}"
+
+Recovery script::
+
+ #!/bin/sh
+
+ DEVPATH=$(readlink -f /sys/$1/device)
+ DEVICE=$(basename $DEVPATH)
+ DRIVER=$(readlink -f $DEVPATH/driver)
+
+ echo -n $DEVICE > $DRIVER/unbind
+ echo -n $DEVICE > $DRIVER/bind
+
+Customization
+-------------
+
+Although basic recovery is possible with a simple script, consumers can define
+custom policies around recovery. For example, if the driver supports multiple
+recovery methods, consumers can opt for the suitable one depending on scenarios
+like repeat offences or vendor specific failures. Consumers can also choose to
+have the device available for debugging or telemetry collection and base their
+recovery decision on the findings. This is useful especially when the driver is
+unsure about recovery or method is unknown.
+
.. _drm_driver_ioctl:
IOCTL Support on Device Nodes
@@ -402,19 +652,19 @@ It's possible to run the IGT-tests in a VM in two ways:
1. Use IGT inside a VM
2. Use IGT from the host machine and write the results in a shared directory.
-As follow, there is an example of using a VM with a shared directory with
-the host machine to run igt-tests. As an example it's used virtme::
+Following is an example of using a VM with a shared directory with
+the host machine to run igt-tests. This example uses virtme::
$ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto
-Run the igt-tests in the guest machine, as example it's ran the 'kms_flip'
+Run the igt-tests in the guest machine. This example runs the 'kms_flip'
tests::
$ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v
-In this example, instead of build the igt_runner, Piglit is used
-(-p option); it's created html summary of the tests results and it's saved
-in the folder "igt-gpu-tools/results"; it's executed only the igt-tests
+In this example, instead of building the igt_runner, Piglit is used
+(-p option). It creates an HTML summary of the test results and saves
+them in the folder "igt-gpu-tools/results". It executes only the igt-tests
matching the -t option.
Display CRC Support
@@ -450,12 +700,12 @@ VBlank event handling
The DRM core exposes two vertical blank related ioctls:
-DRM_IOCTL_WAIT_VBLANK
+:c:macro:`DRM_IOCTL_WAIT_VBLANK`
This takes a struct drm_wait_vblank structure as its argument, and
it is used to block or request a signal when a specified vblank
event occurs.
-DRM_IOCTL_MODESET_CTL
+:c:macro:`DRM_IOCTL_MODESET_CTL`
This was only used for user-mode-settind drivers around modesetting
changes to allow the kernel to update the vblank interrupt after
mode setting, since on many devices the vertical blank counter is
@@ -478,11 +728,37 @@ The index is used in cases where a densely packed identifier for a CRTC is
needed, for instance a bitmask of CRTC's. The member possible_crtcs of struct
drm_mode_get_plane is an example.
-DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC ID's,
-and the CRTC index is its position in this array.
+:c:macro:`DRM_IOCTL_MODE_GETRESOURCES` populates a structure with an array of
+CRTC ID's, and the CRTC index is its position in this array.
.. kernel-doc:: include/uapi/drm/drm.h
:internal:
.. kernel-doc:: include/uapi/drm/drm_mode.h
:internal:
+
+
+dma-buf interoperability
+========================
+
+Please see Documentation/userspace-api/dma-buf-alloc-exchange.rst for
+information on how dma-buf is integrated and exposed within DRM.
+
+
+Trace events
+============
+
+See Documentation/trace/tracepoints.rst for information about using
+Linux Kernel Tracepoints.
+In the DRM subsystem, some events are considered stable uAPI to avoid
+breaking tools (e.g.: GPUVis, umr) relying on them. Stable means that fields
+cannot be removed, nor their formatting updated. Adding new fields is
+possible, under the normal uAPI requirements.
+
+Stable uAPI events
+------------------
+
+From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h``
+
+.. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
+ :doc: uAPI trace events \ No newline at end of file
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
index 92c5117368d7..63d6b2abe5ad 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -8,7 +8,7 @@ DRM drivers can choose to export partly standardised text output via the
`fops->show_fdinfo()` as part of the driver specific file operations registered
in the `struct drm_driver` object registered with the DRM core.
-One purpose of this output is to enable writing as generic as practicaly
+One purpose of this output is to enable writing as generic as practically
feasible `top(1)` like userspace monitoring tools.
Given the differences between various DRM drivers the specification of the
@@ -21,10 +21,13 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
-- All keys shall be prefixed with `drm-`.
+- All standardised keys shall be prefixed with `drm-`.
+- Driver-specific keys shall be prefixed with `driver_name-`, where
+ driver_name should ideally be the same as the `name` field in
+ `struct drm_driver`, although this is not mandatory.
- Whitespace between the delimiter and first non-whitespace character shall be
ignored when parsing.
-- Neither keys or values are allowed to contain whitespace characters.
+- Keys are not allowed to contain whitespace characters.
- Numerical key value pairs can end with optional unit string.
- Data type of the value is fixed as defined in the specification.
@@ -39,12 +42,13 @@ Data types
----------
- <uint> - Unsigned integer without defining the maximum value.
-- <str> - String excluding any above defined reserved characters or whitespace.
+- <keystr> - String excluding any above defined reserved characters or whitespace.
+- <valstr> - String.
Mandatory fully standardised keys
---------------------------------
-- drm-driver: <str>
+- drm-driver: <valstr>
String shall contain the name this driver registered as via the respective
`struct drm_driver` data structure.
@@ -52,6 +56,9 @@ String shall contain the name this driver registered as via the respective
Optional fully standardised keys
--------------------------------
+Identification
+^^^^^^^^^^^^^^
+
- drm-pdev: <aaaa:bb.cc.d>
For PCI devices this should contain the PCI slot address of the device in
@@ -69,10 +76,18 @@ 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
the above described criteria in order to associate data to individual clients.
-- drm-engine-<str>: <uint> ns
+- drm-client-name: <valstr>
+
+String optionally set by userspace using DRM_IOCTL_SET_CLIENT_NAME.
+
+
+Utilization
+^^^^^^^^^^^
+
+- drm-engine-<keystr>: <uint> ns
GPUs usually contain multiple execution engines. Each shall be given a stable
-and unique name (str), with possible values documented in the driver specific
+and unique name (keystr), with possible values documented in the driver specific
documentation.
Value shall be in specified time units which the respective GPU engine spent
@@ -84,31 +99,19 @@ larger value within a reasonable period. Upon observing a value lower than what
was previously read, userspace is expected to stay with that larger previous
value until a monotonic update is seen.
-- drm-engine-capacity-<str>: <uint>
+- drm-engine-capacity-<keystr>: <uint>
Engine identifier string must be the same as the one specified in the
-drm-engine-<str> tag and shall contain a greater than zero number in case the
+drm-engine-<keystr> tag and shall contain a greater than zero number in case the
exported engine corresponds to a group of identical hardware engines.
In the absence of this tag parser shall assume capacity of one. Zero capacity
is not allowed.
-- drm-memory-<str>: <uint> [KiB|MiB]
-
-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
-string here.
-
-Value shall reflect the amount of storage currently consumed by the buffer
-object belong to this client, in the respective memory region.
-
-Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
-indicating kibi- or mebi-bytes.
-
-- drm-cycles-<str> <uint>
+- drm-cycles-<keystr>: <uint>
Engine identifier string must be the same as the one specified in the
-drm-engine-<str> tag and shall contain the number of busy cycles for the given
+drm-engine-<keystr> tag and shall contain the number of busy cycles for the given
engine.
Values are not required to be constantly monotonic if it makes the driver
@@ -117,17 +120,98 @@ larger value within a reasonable period. Upon observing a value lower than what
was previously read, userspace is expected to stay with that larger previous
value until a monotonic update is seen.
-- drm-maxfreq-<str> <uint> [Hz|MHz|KHz]
+- drm-total-cycles-<keystr>: <uint>
Engine identifier string must be the same as the one specified in the
-drm-engine-<str> tag and shall contain the maximum frequency for the given
-engine. Taken together with drm-cycles-<str>, this can be used to calculate
-percentage utilization of the engine, whereas drm-engine-<str> only reflects
+drm-cycles-<keystr> tag and shall contain the total number cycles for the given
+engine.
+
+This is a timestamp in GPU unspecified unit that matches the update rate
+of drm-cycles-<keystr>. For drivers that implement this interface, the engine
+utilization can be calculated entirely on the GPU clock domain, without
+considering the CPU sleep time between 2 samples.
+
+A driver may implement either this key or drm-maxfreq-<keystr>, but not both.
+
+- drm-maxfreq-<keystr>: <uint> [Hz|MHz|KHz]
+
+Engine identifier string must be the same as the one specified in the
+drm-engine-<keystr> tag and shall contain the maximum frequency for the given
+engine. Taken together with drm-cycles-<keystr>, this can be used to calculate
+percentage utilization of the engine, whereas drm-engine-<keystr> only reflects
time active without considering what frequency the engine is operating as a
-percentage of it's maximum frequency.
+percentage of its maximum frequency.
+
+A driver may implement either this key or drm-total-cycles-<keystr>, but not
+both.
+
+Memory
+^^^^^^
+
+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 used as the "<region>"
+string.
+
+The region name "memory" is reserved to refer to normal system memory.
+
+The value shall reflect the amount of storage currently consumed by the buffer
+objects belong to this client, in the respective memory region.
+
+Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
+indicating kibi- or mebi-bytes.
+
+- drm-total-<region>: <uint> [KiB|MiB]
+
+The total size of all requested buffers, including both shared and private
+memory. The backing store for the buffers does not need to be currently
+instantiated to count under this category. To avoid double-counting, if a buffer
+has multiple regions where it can be allocated to, the implementation should
+consistently select a single region for accounting purposes.
+
+- drm-shared-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are shared with another file (i.e., have more
+than one handle). The same requirement to avoid double-counting that applies to
+drm-total-<region> also applies here.
+
+- drm-resident-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are resident (i.e., have their backing store
+present or instantiated) in the specified region.
+
+- drm-memory-<region>: <uint> [KiB|MiB]
+
+This key is deprecated and is only printed by amdgpu; it is an alias for
+drm-resident-<region>.
+
+- drm-purgeable-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are resident and purgeable.
+
+For example, drivers that implement functionality similar to 'madvise' can count
+buffers that have instantiated backing stores but have been marked with an
+equivalent of MADV_DONTNEED.
+
+- drm-active-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that are active on one or more engines.
+
+One practical example of this could be the presence of unsignaled fences in a
+GEM buffer reservation object. Therefore, the active category is a subset of the
+resident category.
+
+Implementation Details
+======================
+
+Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
+implement &drm_driver.show_fdinfo if they wish to provide any stats which
+are not provided by drm_show_fdinfo(). But even driver specific stats should
+be documented above and where possible, aligned with other drivers.
-===============================
Driver specific implementations
-===============================
+-------------------------------
-:ref:`i915-usage-stats`
+* :ref:`i915-usage-stats`
+* :ref:`panfrost-usage-stats`
+* :ref:`panthor-usage-stats`
+* :ref:`xe-usage-stats`
diff --git a/Documentation/gpu/drm-vm-bind-async.rst b/Documentation/gpu/drm-vm-bind-async.rst
new file mode 100644
index 000000000000..3d709d02099c
--- /dev/null
+++ b/Documentation/gpu/drm-vm-bind-async.rst
@@ -0,0 +1,309 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+====================
+Asynchronous VM_BIND
+====================
+
+Nomenclature:
+=============
+
+* ``VRAM``: On-device memory. Sometimes referred to as device local memory.
+
+* ``gpu_vm``: A virtual GPU address space. Typically per process, but
+ can be shared by multiple processes.
+
+* ``VM_BIND``: An operation or a list of operations to modify a gpu_vm using
+ an IOCTL. The operations include mapping and unmapping system- or
+ VRAM memory.
+
+* ``syncobj``: A container that abstracts synchronization objects. The
+ synchronization objects can be either generic, like dma-fences or
+ driver specific. A syncobj typically indicates the type of the
+ underlying synchronization object.
+
+* ``in-syncobj``: Argument to a VM_BIND IOCTL, the VM_BIND operation waits
+ for these before starting.
+
+* ``out-syncobj``: Argument to a VM_BIND_IOCTL, the VM_BIND operation
+ signals these when the bind operation is complete.
+
+* ``dma-fence``: A cross-driver synchronization object. A basic
+ understanding of dma-fences is required to digest this
+ document. Please refer to the ``DMA Fences`` section of the
+ :doc:`dma-buf doc </driver-api/dma-buf>`.
+
+* ``memory fence``: A synchronization object, different from a dma-fence.
+ A memory fence uses the value of a specified memory location to determine
+ signaled status. A memory fence can be awaited and signaled by both
+ the GPU and CPU. Memory fences are sometimes referred to as
+ user-fences, userspace-fences or gpu futexes and do not necessarily obey
+ the dma-fence rule of signaling within a "reasonable amount of time".
+ The kernel should thus avoid waiting for memory fences with locks held.
+
+* ``long-running workload``: A workload that may take more than the
+ current stipulated dma-fence maximum signal delay to complete and
+ which therefore needs to set the gpu_vm or the GPU execution context in
+ a certain mode that disallows completion dma-fences.
+
+* ``exec function``: An exec function is a function that revalidates all
+ affected gpu_vmas, submits a GPU command batch and registers the
+ dma_fence representing the GPU command's activity with all affected
+ dma_resvs. For completeness, although not covered by this document,
+ it's worth mentioning that an exec function may also be the
+ revalidation worker that is used by some drivers in compute /
+ long-running mode.
+
+* ``bind context``: A context identifier used for the VM_BIND
+ operation. VM_BIND operations that use the same bind context can be
+ assumed, where it matters, to complete in order of submission. No such
+ assumptions can be made for VM_BIND operations using separate bind contexts.
+
+* ``UMD``: User-mode driver.
+
+* ``KMD``: Kernel-mode driver.
+
+
+Synchronous / Asynchronous VM_BIND operation
+============================================
+
+Synchronous VM_BIND
+___________________
+With Synchronous VM_BIND, the VM_BIND operations all complete before the
+IOCTL returns. A synchronous VM_BIND takes neither in-fences nor
+out-fences. Synchronous VM_BIND may block and wait for GPU operations;
+for example swap-in or clearing, or even previous binds.
+
+Asynchronous VM_BIND
+____________________
+Asynchronous VM_BIND accepts both in-syncobjs and out-syncobjs. While the
+IOCTL may return immediately, the VM_BIND operations wait for the in-syncobjs
+before modifying the GPU page-tables, and signal the out-syncobjs when
+the modification is done in the sense that the next exec function that
+awaits for the out-syncobjs will see the change. Errors are reported
+synchronously.
+In low-memory situations the implementation may block, performing the
+VM_BIND synchronously, because there might not be enough memory
+immediately available for preparing the asynchronous operation.
+
+If the VM_BIND IOCTL takes a list or an array of operations as an argument,
+the in-syncobjs needs to signal before the first operation starts to
+execute, and the out-syncobjs signal after the last operation
+completes. Operations in the operation list can be assumed, where it
+matters, to complete in order.
+
+Since asynchronous VM_BIND operations may use dma-fences embedded in
+out-syncobjs and internally in KMD to signal bind completion, any
+memory fences given as VM_BIND in-fences need to be awaited
+synchronously before the VM_BIND ioctl returns, since dma-fences,
+required to signal in a reasonable amount of time, can never be made
+to depend on memory fences that don't have such a restriction.
+
+The purpose of an Asynchronous VM_BIND operation is for user-mode
+drivers to be able to pipeline interleaved gpu_vm modifications and
+exec functions. For long-running workloads, such pipelining of a bind
+operation is not allowed and any in-fences need to be awaited
+synchronously. The reason for this is twofold. First, any memory
+fences gated by a long-running workload and used as in-syncobjs for the
+VM_BIND operation will need to be awaited synchronously anyway (see
+above). Second, any dma-fences used as in-syncobjs for VM_BIND
+operations for long-running workloads will not allow for pipelining
+anyway since long-running workloads don't allow for dma-fences as
+out-syncobjs, so while theoretically possible the use of them is
+questionable and should be rejected until there is a valuable use-case.
+Note that this is not a limitation imposed by dma-fence rules, but
+rather a limitation imposed to keep KMD implementation simple. It does
+not affect using dma-fences as dependencies for the long-running
+workload itself, which is allowed by dma-fence rules, but rather for
+the VM_BIND operation only.
+
+An asynchronous VM_BIND operation may take substantial time to
+complete and signal the out_fence. In particular if the operation is
+deeply pipelined behind other VM_BIND operations and workloads
+submitted using exec functions. In that case, UMD might want to avoid a
+subsequent VM_BIND operation to be queued behind the first one if
+there are no explicit dependencies. In order to circumvent such a queue-up, a
+VM_BIND implementation may allow for VM_BIND contexts to be
+created. For each context, VM_BIND operations will be guaranteed to
+complete in the order they were submitted, but that is not the case
+for VM_BIND operations executing on separate VM_BIND contexts. Instead
+KMD will attempt to execute such VM_BIND operations in parallel but
+leaving no guarantee that they will actually be executed in
+parallel. There may be internal implicit dependencies that only KMD knows
+about, for example page-table structure changes. A way to attempt
+to avoid such internal dependencies is to have different VM_BIND
+contexts use separate regions of a VM.
+
+Also for VM_BINDS for long-running gpu_vms the user-mode driver should typically
+select memory fences as out-fences since that gives greater flexibility for
+the kernel mode driver to inject other operations into the bind /
+unbind operations. Like for example inserting breakpoints into batch
+buffers. The workload execution can then easily be pipelined behind
+the bind completion using the memory out-fence as the signal condition
+for a GPU semaphore embedded by UMD in the workload.
+
+There is no difference in the operations supported or in
+multi-operation support between asynchronous VM_BIND and synchronous VM_BIND.
+
+Multi-operation VM_BIND IOCTL error handling and interrupts
+===========================================================
+
+The VM_BIND operations of the IOCTL may error for various reasons, for
+example due to lack of resources to complete and due to interrupted
+waits.
+In these situations UMD should preferably restart the IOCTL after
+taking suitable action.
+If UMD has over-committed a memory resource, an -ENOSPC error will be
+returned, and UMD may then unbind resources that are not used at the
+moment and rerun the IOCTL. On -EINTR, UMD should simply rerun the
+IOCTL and on -ENOMEM user-space may either attempt to free known
+system memory resources or fail. In case of UMD deciding to fail a
+bind operation, due to an error return, no additional action is needed
+to clean up the failed operation, and the VM is left in the same state
+as it was before the failing IOCTL.
+Unbind operations are guaranteed not to return any errors due to
+resource constraints, but may return errors due to, for example,
+invalid arguments or the gpu_vm being banned.
+In the case an unexpected error happens during the asynchronous bind
+process, the gpu_vm will be banned, and attempts to use it after banning
+will return -ENOENT.
+
+Example: The Xe VM_BIND uAPI
+============================
+
+Starting with the VM_BIND operation struct, the IOCTL call can take
+zero, one or many such operations. A zero number means only the
+synchronization part of the IOCTL is carried out: an asynchronous
+VM_BIND updates the syncobjects, whereas a sync VM_BIND waits for the
+implicit dependencies to be fulfilled.
+
+.. code-block:: c
+
+ struct drm_xe_vm_bind_op {
+ /**
+ * @obj: GEM object to operate on, MBZ for MAP_USERPTR, MBZ for UNMAP
+ */
+ __u32 obj;
+
+ /** @pad: MBZ */
+ __u32 pad;
+
+ union {
+ /**
+ * @obj_offset: Offset into the object for MAP.
+ */
+ __u64 obj_offset;
+
+ /** @userptr: user virtual address for MAP_USERPTR */
+ __u64 userptr;
+ };
+
+ /**
+ * @range: Number of bytes from the object to bind to addr, MBZ for UNMAP_ALL
+ */
+ __u64 range;
+
+ /** @addr: Address to operate on, MBZ for UNMAP_ALL */
+ __u64 addr;
+
+ /**
+ * @tile_mask: Mask for which tiles to create binds for, 0 == All tiles,
+ * only applies to creating new VMAs
+ */
+ __u64 tile_mask;
+
+ /* Map (parts of) an object into the GPU virtual address range.
+ #define XE_VM_BIND_OP_MAP 0x0
+ /* Unmap a GPU virtual address range */
+ #define XE_VM_BIND_OP_UNMAP 0x1
+ /*
+ * Map a CPU virtual address range into a GPU virtual
+ * address range.
+ */
+ #define XE_VM_BIND_OP_MAP_USERPTR 0x2
+ /* Unmap a gem object from the VM. */
+ #define XE_VM_BIND_OP_UNMAP_ALL 0x3
+ /*
+ * Make the backing memory of an address range resident if
+ * possible. Note that this doesn't pin backing memory.
+ */
+ #define XE_VM_BIND_OP_PREFETCH 0x4
+
+ /* Make the GPU map readonly. */
+ #define XE_VM_BIND_FLAG_READONLY (0x1 << 16)
+ /*
+ * Valid on a faulting VM only, do the MAP operation immediately rather
+ * than deferring the MAP to the page fault handler.
+ */
+ #define XE_VM_BIND_FLAG_IMMEDIATE (0x1 << 17)
+ /*
+ * When the NULL flag is set, the page tables are setup with a special
+ * bit which indicates writes are dropped and all reads return zero. In
+ * the future, the NULL flags will only be valid for XE_VM_BIND_OP_MAP
+ * operations, the BO handle MBZ, and the BO offset MBZ. This flag is
+ * intended to implement VK sparse bindings.
+ */
+ #define XE_VM_BIND_FLAG_NULL (0x1 << 18)
+ /** @op: Operation to perform (lower 16 bits) and flags (upper 16 bits) */
+ __u32 op;
+
+ /** @mem_region: Memory region to prefetch VMA to, instance not a mask */
+ __u32 region;
+
+ /** @reserved: Reserved */
+ __u64 reserved[2];
+ };
+
+
+The VM_BIND IOCTL argument itself, looks like follows. Note that for
+synchronous VM_BIND, the num_syncs and syncs fields must be zero. Here
+the ``exec_queue_id`` field is the VM_BIND context discussed previously
+that is used to facilitate out-of-order VM_BINDs.
+
+.. code-block:: c
+
+ struct drm_xe_vm_bind {
+ /** @extensions: Pointer to the first extension struct, if any */
+ __u64 extensions;
+
+ /** @vm_id: The ID of the VM to bind to */
+ __u32 vm_id;
+
+ /**
+ * @exec_queue_id: exec_queue_id, must be of class DRM_XE_ENGINE_CLASS_VM_BIND
+ * and exec queue must have same vm_id. If zero, the default VM bind engine
+ * is used.
+ */
+ __u32 exec_queue_id;
+
+ /** @num_binds: number of binds in this IOCTL */
+ __u32 num_binds;
+
+ /* If set, perform an async VM_BIND, if clear a sync VM_BIND */
+ #define XE_VM_BIND_IOCTL_FLAG_ASYNC (0x1 << 0)
+
+ /** @flag: Flags controlling all operations in this ioctl. */
+ __u32 flags;
+
+ union {
+ /** @bind: used if num_binds == 1 */
+ struct drm_xe_vm_bind_op bind;
+
+ /**
+ * @vector_of_binds: userptr to array of struct
+ * drm_xe_vm_bind_op if num_binds > 1
+ */
+ __u64 vector_of_binds;
+ };
+
+ /** @num_syncs: amount of syncs to wait for or to signal on completion. */
+ __u32 num_syncs;
+
+ /** @pad2: MBZ */
+ __u32 pad2;
+
+ /** @syncs: pointer to struct drm_xe_sync array */
+ __u64 syncs;
+
+ /** @reserved: Reserved */
+ __u64 reserved[2];
+ };
diff --git a/Documentation/gpu/drm-vm-bind-locking.rst b/Documentation/gpu/drm-vm-bind-locking.rst
new file mode 100644
index 000000000000..a345aa513d12
--- /dev/null
+++ b/Documentation/gpu/drm-vm-bind-locking.rst
@@ -0,0 +1,582 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===============
+VM_BIND locking
+===============
+
+This document attempts to describe what's needed to get VM_BIND locking right,
+including the userptr mmu_notifier locking. It also discusses some
+optimizations to get rid of the looping through of all userptr mappings and
+external / shared object mappings that is needed in the simplest
+implementation. In addition, there is a section describing the VM_BIND locking
+required for implementing recoverable pagefaults.
+
+The DRM GPUVM set of helpers
+============================
+
+There is a set of helpers for drivers implementing VM_BIND, and this
+set of helpers implements much, but not all of the locking described
+in this document. In particular, it is currently lacking a userptr
+implementation. This document does not intend to describe the DRM GPUVM
+implementation in detail, but it is covered in :ref:`its own
+documentation <drm_gpuvm>`. It is highly recommended for any driver
+implementing VM_BIND to use the DRM GPUVM helpers and to extend it if
+common functionality is missing.
+
+Nomenclature
+============
+
+* ``gpu_vm``: Abstraction of a virtual GPU address space with
+ meta-data. Typically one per client (DRM file-private), or one per
+ execution context.
+* ``gpu_vma``: Abstraction of a GPU address range within a gpu_vm with
+ associated meta-data. The backing storage of a gpu_vma can either be
+ a GEM object or anonymous or page-cache pages mapped also into the CPU
+ address space for the process.
+* ``gpu_vm_bo``: Abstracts the association of a GEM object and
+ a VM. The GEM object maintains a list of gpu_vm_bos, where each gpu_vm_bo
+ maintains a list of gpu_vmas.
+* ``userptr gpu_vma or just userptr``: A gpu_vma, whose backing store
+ is anonymous or page-cache pages as described above.
+* ``revalidating``: Revalidating a gpu_vma means making the latest version
+ of the backing store resident and making sure the gpu_vma's
+ page-table entries point to that backing store.
+* ``dma_fence``: A struct dma_fence that is similar to a struct completion
+ and which tracks GPU activity. When the GPU activity is finished,
+ the dma_fence signals. Please refer to the ``DMA Fences`` section of
+ the :doc:`dma-buf doc </driver-api/dma-buf>`.
+* ``dma_resv``: A struct dma_resv (a.k.a reservation object) that is used
+ to track GPU activity in the form of multiple dma_fences on a
+ gpu_vm or a GEM object. The dma_resv contains an array / list
+ of dma_fences and a lock that needs to be held when adding
+ additional dma_fences to the dma_resv. The lock is of a type that
+ allows deadlock-safe locking of multiple dma_resvs in arbitrary
+ order. Please refer to the ``Reservation Objects`` section of the
+ :doc:`dma-buf doc </driver-api/dma-buf>`.
+* ``exec function``: An exec function is a function that revalidates all
+ affected gpu_vmas, submits a GPU command batch and registers the
+ dma_fence representing the GPU command's activity with all affected
+ dma_resvs. For completeness, although not covered by this document,
+ it's worth mentioning that an exec function may also be the
+ revalidation worker that is used by some drivers in compute /
+ long-running mode.
+* ``local object``: A GEM object which is only mapped within a
+ single VM. Local GEM objects share the gpu_vm's dma_resv.
+* ``external object``: a.k.a shared object: A GEM object which may be shared
+ by multiple gpu_vms and whose backing storage may be shared with
+ other drivers.
+
+Locks and locking order
+=======================
+
+One of the benefits of VM_BIND is that local GEM objects share the gpu_vm's
+dma_resv object and hence the dma_resv lock. So, even with a huge
+number of local GEM objects, only one lock is needed to make the exec
+sequence atomic.
+
+The following locks and locking orders are used:
+
+* The ``gpu_vm->lock`` (optionally an rwsem). Protects the gpu_vm's
+ data structure keeping track of gpu_vmas. It can also protect the
+ gpu_vm's list of userptr gpu_vmas. With a CPU mm analogy this would
+ correspond to the mmap_lock. An rwsem allows several readers to walk
+ the VM tree concurrently, but the benefit of that concurrency most
+ likely varies from driver to driver.
+* The ``userptr_seqlock``. This lock is taken in read mode for each
+ userptr gpu_vma on the gpu_vm's userptr list, and in write mode during mmu
+ notifier invalidation. This is not a real seqlock but described in
+ ``mm/mmu_notifier.c`` as a "Collision-retry read-side/write-side
+ 'lock' a lot like a seqcount. However this allows multiple
+ write-sides to hold it at once...". The read side critical section
+ is enclosed by ``mmu_interval_read_begin() /
+ mmu_interval_read_retry()`` with ``mmu_interval_read_begin()``
+ sleeping if the write side is held.
+ The write side is held by the core mm while calling mmu interval
+ invalidation notifiers.
+* The ``gpu_vm->resv`` lock. Protects the gpu_vm's list of gpu_vmas needing
+ rebinding, as well as the residency state of all the gpu_vm's local
+ GEM objects.
+ Furthermore, it typically protects the gpu_vm's list of evicted and
+ external GEM objects.
+* The ``gpu_vm->userptr_notifier_lock``. This is an rwsem that is
+ taken in read mode during exec and write mode during a mmu notifier
+ invalidation. The userptr notifier lock is per gpu_vm.
+* The ``gem_object->gpuva_lock`` This lock protects the GEM object's
+ list of gpu_vm_bos. This is usually the same lock as the GEM
+ object's dma_resv, but some drivers protects this list differently,
+ see below.
+* The ``gpu_vm list spinlocks``. With some implementations they are needed
+ to be able to update the gpu_vm evicted- and external object
+ list. For those implementations, the spinlocks are grabbed when the
+ lists are manipulated. However, to avoid locking order violations
+ with the dma_resv locks, a special scheme is needed when iterating
+ over the lists.
+
+.. _gpu_vma lifetime:
+
+Protection and lifetime of gpu_vm_bos and gpu_vmas
+==================================================
+
+The GEM object's list of gpu_vm_bos, and the gpu_vm_bo's list of gpu_vmas
+is protected by the ``gem_object->gpuva_lock``, which is typically the
+same as the GEM object's dma_resv, but if the driver
+needs to access these lists from within a dma_fence signalling
+critical section, it can instead choose to protect it with a
+separate lock, which can be locked from within the dma_fence signalling
+critical section. Such drivers then need to pay additional attention
+to what locks need to be taken from within the loop when iterating
+over the gpu_vm_bo and gpu_vma lists to avoid locking-order violations.
+
+The DRM GPUVM set of helpers provide lockdep asserts that this lock is
+held in relevant situations and also provides a means of making itself
+aware of which lock is actually used: :c:func:`drm_gem_gpuva_set_lock`.
+
+Each gpu_vm_bo holds a reference counted pointer to the underlying GEM
+object, and each gpu_vma holds a reference counted pointer to the
+gpu_vm_bo. When iterating over the GEM object's list of gpu_vm_bos and
+over the gpu_vm_bo's list of gpu_vmas, the ``gem_object->gpuva_lock`` must
+not be dropped, otherwise, gpu_vmas attached to a gpu_vm_bo may
+disappear without notice since those are not reference-counted. A
+driver may implement its own scheme to allow this at the expense of
+additional complexity, but this is outside the scope of this document.
+
+In the DRM GPUVM implementation, each gpu_vm_bo and each gpu_vma
+holds a reference count on the gpu_vm itself. Due to this, and to avoid circular
+reference counting, cleanup of the gpu_vm's gpu_vmas must not be done from the
+gpu_vm's destructor. Drivers typically implements a gpu_vm close
+function for this cleanup. The gpu_vm close function will abort gpu
+execution using this VM, unmap all gpu_vmas and release page-table memory.
+
+Revalidation and eviction of local objects
+==========================================
+
+Note that in all the code examples given below we use simplified
+pseudo-code. In particular, the dma_resv deadlock avoidance algorithm
+as well as reserving memory for dma_resv fences is left out.
+
+Revalidation
+____________
+With VM_BIND, all local objects need to be resident when the gpu is
+executing using the gpu_vm, and the objects need to have valid
+gpu_vmas set up pointing to them. Typically, each gpu command buffer
+submission is therefore preceded with a re-validation section:
+
+.. code-block:: C
+
+ dma_resv_lock(gpu_vm->resv);
+
+ // Validation section starts here.
+ for_each_gpu_vm_bo_on_evict_list(&gpu_vm->evict_list, &gpu_vm_bo) {
+ validate_gem_bo(&gpu_vm_bo->gem_bo);
+
+ // The following list iteration needs the Gem object's
+ // dma_resv to be held (it protects the gpu_vm_bo's list of
+ // gpu_vmas, but since local gem objects share the gpu_vm's
+ // dma_resv, it is already held at this point.
+ for_each_gpu_vma_of_gpu_vm_bo(&gpu_vm_bo, &gpu_vma)
+ move_gpu_vma_to_rebind_list(&gpu_vma, &gpu_vm->rebind_list);
+ }
+
+ for_each_gpu_vma_on_rebind_list(&gpu vm->rebind_list, &gpu_vma) {
+ rebind_gpu_vma(&gpu_vma);
+ remove_gpu_vma_from_rebind_list(&gpu_vma);
+ }
+ // Validation section ends here, and job submission starts.
+
+ add_dependencies(&gpu_job, &gpu_vm->resv);
+ job_dma_fence = gpu_submit(&gpu_job));
+
+ add_dma_fence(job_dma_fence, &gpu_vm->resv);
+ dma_resv_unlock(gpu_vm->resv);
+
+The reason for having a separate gpu_vm rebind list is that there
+might be userptr gpu_vmas that are not mapping a buffer object that
+also need rebinding.
+
+Eviction
+________
+
+Eviction of one of these local objects will then look similar to the
+following:
+
+.. code-block:: C
+
+ obj = get_object_from_lru();
+
+ dma_resv_lock(obj->resv);
+ for_each_gpu_vm_bo_of_obj(obj, &gpu_vm_bo);
+ add_gpu_vm_bo_to_evict_list(&gpu_vm_bo, &gpu_vm->evict_list);
+
+ add_dependencies(&eviction_job, &obj->resv);
+ job_dma_fence = gpu_submit(&eviction_job);
+ add_dma_fence(&obj->resv, job_dma_fence);
+
+ dma_resv_unlock(&obj->resv);
+ put_object(obj);
+
+Note that since the object is local to the gpu_vm, it will share the gpu_vm's
+dma_resv lock such that ``obj->resv == gpu_vm->resv``.
+The gpu_vm_bos marked for eviction are put on the gpu_vm's evict list,
+which is protected by ``gpu_vm->resv``. During eviction all local
+objects have their dma_resv locked and, due to the above equality, also
+the gpu_vm's dma_resv protecting the gpu_vm's evict list is locked.
+
+With VM_BIND, gpu_vmas don't need to be unbound before eviction,
+since the driver must ensure that the eviction blit or copy will wait
+for GPU idle or depend on all previous GPU activity. Furthermore, any
+subsequent attempt by the GPU to access freed memory through the
+gpu_vma will be preceded by a new exec function, with a revalidation
+section which will make sure all gpu_vmas are rebound. The eviction
+code holding the object's dma_resv while revalidating will ensure a
+new exec function may not race with the eviction.
+
+A driver can be implemented in such a way that, on each exec function,
+only a subset of vmas are selected for rebind. In this case, all vmas that are
+*not* selected for rebind must be unbound before the exec
+function workload is submitted.
+
+Locking with external buffer objects
+====================================
+
+Since external buffer objects may be shared by multiple gpu_vm's they
+can't share their reservation object with a single gpu_vm. Instead
+they need to have a reservation object of their own. The external
+objects bound to a gpu_vm using one or many gpu_vmas are therefore put on a
+per-gpu_vm list which is protected by the gpu_vm's dma_resv lock or
+one of the :ref:`gpu_vm list spinlocks <Spinlock iteration>`. Once
+the gpu_vm's reservation object is locked, it is safe to traverse the
+external object list and lock the dma_resvs of all external
+objects. However, if instead a list spinlock is used, a more elaborate
+iteration scheme needs to be used.
+
+At eviction time, the gpu_vm_bos of *all* the gpu_vms an external
+object is bound to need to be put on their gpu_vm's evict list.
+However, when evicting an external object, the dma_resvs of the
+gpu_vms the object is bound to are typically not held. Only
+the object's private dma_resv can be guaranteed to be held. If there
+is a ww_acquire context at hand at eviction time we could grab those
+dma_resvs but that could cause expensive ww_mutex rollbacks. A simple
+option is to just mark the gpu_vm_bos of the evicted gem object with
+an ``evicted`` bool that is inspected before the next time the
+corresponding gpu_vm evicted list needs to be traversed. For example, when
+traversing the list of external objects and locking them. At that time,
+both the gpu_vm's dma_resv and the object's dma_resv is held, and the
+gpu_vm_bo marked evicted, can then be added to the gpu_vm's list of
+evicted gpu_vm_bos. The ``evicted`` bool is formally protected by the
+object's dma_resv.
+
+The exec function becomes
+
+.. code-block:: C
+
+ dma_resv_lock(gpu_vm->resv);
+
+ // External object list is protected by the gpu_vm->resv lock.
+ for_each_gpu_vm_bo_on_extobj_list(gpu_vm, &gpu_vm_bo) {
+ dma_resv_lock(gpu_vm_bo.gem_obj->resv);
+ if (gpu_vm_bo_marked_evicted(&gpu_vm_bo))
+ add_gpu_vm_bo_to_evict_list(&gpu_vm_bo, &gpu_vm->evict_list);
+ }
+
+ for_each_gpu_vm_bo_on_evict_list(&gpu_vm->evict_list, &gpu_vm_bo) {
+ validate_gem_bo(&gpu_vm_bo->gem_bo);
+
+ for_each_gpu_vma_of_gpu_vm_bo(&gpu_vm_bo, &gpu_vma)
+ move_gpu_vma_to_rebind_list(&gpu_vma, &gpu_vm->rebind_list);
+ }
+
+ for_each_gpu_vma_on_rebind_list(&gpu vm->rebind_list, &gpu_vma) {
+ rebind_gpu_vma(&gpu_vma);
+ remove_gpu_vma_from_rebind_list(&gpu_vma);
+ }
+
+ add_dependencies(&gpu_job, &gpu_vm->resv);
+ job_dma_fence = gpu_submit(&gpu_job));
+
+ add_dma_fence(job_dma_fence, &gpu_vm->resv);
+ for_each_external_obj(gpu_vm, &obj)
+ add_dma_fence(job_dma_fence, &obj->resv);
+ dma_resv_unlock_all_resv_locks();
+
+And the corresponding shared-object aware eviction would look like:
+
+.. code-block:: C
+
+ obj = get_object_from_lru();
+
+ dma_resv_lock(obj->resv);
+ for_each_gpu_vm_bo_of_obj(obj, &gpu_vm_bo)
+ if (object_is_vm_local(obj))
+ add_gpu_vm_bo_to_evict_list(&gpu_vm_bo, &gpu_vm->evict_list);
+ else
+ mark_gpu_vm_bo_evicted(&gpu_vm_bo);
+
+ add_dependencies(&eviction_job, &obj->resv);
+ job_dma_fence = gpu_submit(&eviction_job);
+ add_dma_fence(&obj->resv, job_dma_fence);
+
+ dma_resv_unlock(&obj->resv);
+ put_object(obj);
+
+.. _Spinlock iteration:
+
+Accessing the gpu_vm's lists without the dma_resv lock held
+===========================================================
+
+Some drivers will hold the gpu_vm's dma_resv lock when accessing the
+gpu_vm's evict list and external objects lists. However, there are
+drivers that need to access these lists without the dma_resv lock
+held, for example due to asynchronous state updates from within the
+dma_fence signalling critical path. In such cases, a spinlock can be
+used to protect manipulation of the lists. However, since higher level
+sleeping locks need to be taken for each list item while iterating
+over the lists, the items already iterated over need to be
+temporarily moved to a private list and the spinlock released
+while processing each item:
+
+.. code block:: C
+
+ struct list_head still_in_list;
+
+ INIT_LIST_HEAD(&still_in_list);
+
+ spin_lock(&gpu_vm->list_lock);
+ do {
+ struct list_head *entry = list_first_entry_or_null(&gpu_vm->list, head);
+
+ if (!entry)
+ break;
+
+ list_move_tail(&entry->head, &still_in_list);
+ list_entry_get_unless_zero(entry);
+ spin_unlock(&gpu_vm->list_lock);
+
+ process(entry);
+
+ spin_lock(&gpu_vm->list_lock);
+ list_entry_put(entry);
+ } while (true);
+
+ list_splice_tail(&still_in_list, &gpu_vm->list);
+ spin_unlock(&gpu_vm->list_lock);
+
+Due to the additional locking and atomic operations, drivers that *can*
+avoid accessing the gpu_vm's list outside of the dma_resv lock
+might want to avoid also this iteration scheme. Particularly, if the
+driver anticipates a large number of list items. For lists where the
+anticipated number of list items is small, where list iteration doesn't
+happen very often or if there is a significant additional cost
+associated with each iteration, the atomic operation overhead
+associated with this type of iteration is, most likely, negligible. Note that
+if this scheme is used, it is necessary to make sure this list
+iteration is protected by an outer level lock or semaphore, since list
+items are temporarily pulled off the list while iterating, and it is
+also worth mentioning that the local list ``still_in_list`` should
+also be considered protected by the ``gpu_vm->list_lock``, and it is
+thus possible that items can be removed also from the local list
+concurrently with list iteration.
+
+Please refer to the :ref:`DRM GPUVM locking section
+<drm_gpuvm_locking>` and its internal
+:c:func:`get_next_vm_bo_from_list` function.
+
+
+userptr gpu_vmas
+================
+
+A userptr gpu_vma is a gpu_vma that, instead of mapping a buffer object to a
+GPU virtual address range, directly maps a CPU mm range of anonymous-
+or file page-cache pages.
+A very simple approach would be to just pin the pages using
+pin_user_pages() at bind time and unpin them at unbind time, but this
+creates a Denial-Of-Service vector since a single user-space process
+would be able to pin down all of system memory, which is not
+desirable. (For special use-cases and assuming proper accounting pinning might
+still be a desirable feature, though). What we need to do in the
+general case is to obtain a reference to the desired pages, make sure
+we are notified using a MMU notifier just before the CPU mm unmaps the
+pages, dirty them if they are not mapped read-only to the GPU, and
+then drop the reference.
+When we are notified by the MMU notifier that CPU mm is about to drop the
+pages, we need to stop GPU access to the pages by waiting for VM idle
+in the MMU notifier and make sure that before the next time the GPU
+tries to access whatever is now present in the CPU mm range, we unmap
+the old pages from the GPU page tables and repeat the process of
+obtaining new page references. (See the :ref:`notifier example
+<Invalidation example>` below). Note that when the core mm decides to
+laundry pages, we get such an unmap MMU notification and can mark the
+pages dirty again before the next GPU access. We also get similar MMU
+notifications for NUMA accounting which the GPU driver doesn't really
+need to care about, but so far it has proven difficult to exclude
+certain notifications.
+
+Using a MMU notifier for device DMA (and other methods) is described in
+:ref:`the pin_user_pages() documentation <mmu-notifier-registration-case>`.
+
+Now, the method of obtaining struct page references using
+get_user_pages() unfortunately can't be used under a dma_resv lock
+since that would violate the locking order of the dma_resv lock vs the
+mmap_lock that is grabbed when resolving a CPU pagefault. This means
+the gpu_vm's list of userptr gpu_vmas needs to be protected by an
+outer lock, which in our example below is the ``gpu_vm->lock``.
+
+The MMU interval seqlock for a userptr gpu_vma is used in the following
+way:
+
+.. code-block:: C
+
+ // Exclusive locking mode here is strictly needed only if there are
+ // invalidated userptr gpu_vmas present, to avoid concurrent userptr
+ // revalidations of the same userptr gpu_vma.
+ down_write(&gpu_vm->lock);
+ retry:
+
+ // Note: mmu_interval_read_begin() blocks until there is no
+ // invalidation notifier running anymore.
+ seq = mmu_interval_read_begin(&gpu_vma->userptr_interval);
+ if (seq != gpu_vma->saved_seq) {
+ obtain_new_page_pointers(&gpu_vma);
+ dma_resv_lock(&gpu_vm->resv);
+ add_gpu_vma_to_revalidate_list(&gpu_vma, &gpu_vm);
+ dma_resv_unlock(&gpu_vm->resv);
+ gpu_vma->saved_seq = seq;
+ }
+
+ // The usual revalidation goes here.
+
+ // Final userptr sequence validation may not happen before the
+ // submission dma_fence is added to the gpu_vm's resv, from the POW
+ // of the MMU invalidation notifier. Hence the
+ // userptr_notifier_lock that will make them appear atomic.
+
+ add_dependencies(&gpu_job, &gpu_vm->resv);
+ down_read(&gpu_vm->userptr_notifier_lock);
+ if (mmu_interval_read_retry(&gpu_vma->userptr_interval, gpu_vma->saved_seq)) {
+ up_read(&gpu_vm->userptr_notifier_lock);
+ goto retry;
+ }
+
+ job_dma_fence = gpu_submit(&gpu_job));
+
+ add_dma_fence(job_dma_fence, &gpu_vm->resv);
+
+ for_each_external_obj(gpu_vm, &obj)
+ add_dma_fence(job_dma_fence, &obj->resv);
+
+ dma_resv_unlock_all_resv_locks();
+ up_read(&gpu_vm->userptr_notifier_lock);
+ up_write(&gpu_vm->lock);
+
+The code between ``mmu_interval_read_begin()`` and the
+``mmu_interval_read_retry()`` marks the read side critical section of
+what we call the ``userptr_seqlock``. In reality, the gpu_vm's userptr
+gpu_vma list is looped through, and the check is done for *all* of its
+userptr gpu_vmas, although we only show a single one here.
+
+The userptr gpu_vma MMU invalidation notifier might be called from
+reclaim context and, again, to avoid locking order violations, we can't
+take any dma_resv lock nor the gpu_vm->lock from within it.
+
+.. _Invalidation example:
+.. code-block:: C
+
+ bool gpu_vma_userptr_invalidate(userptr_interval, cur_seq)
+ {
+ // Make sure the exec function either sees the new sequence
+ // and backs off or we wait for the dma-fence:
+
+ down_write(&gpu_vm->userptr_notifier_lock);
+ mmu_interval_set_seq(userptr_interval, cur_seq);
+ up_write(&gpu_vm->userptr_notifier_lock);
+
+ // At this point, the exec function can't succeed in
+ // submitting a new job, because cur_seq is an invalid
+ // sequence number and will always cause a retry. When all
+ // invalidation callbacks, the mmu notifier core will flip
+ // the sequence number to a valid one. However we need to
+ // stop gpu access to the old pages here.
+
+ dma_resv_wait_timeout(&gpu_vm->resv, DMA_RESV_USAGE_BOOKKEEP,
+ false, MAX_SCHEDULE_TIMEOUT);
+ return true;
+ }
+
+When this invalidation notifier returns, the GPU can no longer be
+accessing the old pages of the userptr gpu_vma and needs to redo the
+page-binding before a new GPU submission can succeed.
+
+Efficient userptr gpu_vma exec_function iteration
+_________________________________________________
+
+If the gpu_vm's list of userptr gpu_vmas becomes large, it's
+inefficient to iterate through the complete lists of userptrs on each
+exec function to check whether each userptr gpu_vma's saved
+sequence number is stale. A solution to this is to put all
+*invalidated* userptr gpu_vmas on a separate gpu_vm list and
+only check the gpu_vmas present on this list on each exec
+function. This list will then lend itself very-well to the spinlock
+locking scheme that is
+:ref:`described in the spinlock iteration section <Spinlock iteration>`, since
+in the mmu notifier, where we add the invalidated gpu_vmas to the
+list, it's not possible to take any outer locks like the
+``gpu_vm->lock`` or the ``gpu_vm->resv`` lock. Note that the
+``gpu_vm->lock`` still needs to be taken while iterating to ensure the list is
+complete, as also mentioned in that section.
+
+If using an invalidated userptr list like this, the retry check in the
+exec function trivially becomes a check for invalidated list empty.
+
+Locking at bind and unbind time
+===============================
+
+At bind time, assuming a GEM object backed gpu_vma, each
+gpu_vma needs to be associated with a gpu_vm_bo and that
+gpu_vm_bo in turn needs to be added to the GEM object's
+gpu_vm_bo list, and possibly to the gpu_vm's external object
+list. This is referred to as *linking* the gpu_vma, and typically
+requires that the ``gpu_vm->lock`` and the ``gem_object->gpuva_lock``
+are held. When unlinking a gpu_vma the same locks should be held,
+and that ensures that when iterating over ``gpu_vmas`, either under
+the ``gpu_vm->resv`` or the GEM object's dma_resv, that the gpu_vmas
+stay alive as long as the lock under which we iterate is not released. For
+userptr gpu_vmas it's similarly required that during vma destroy, the
+outer ``gpu_vm->lock`` is held, since otherwise when iterating over
+the invalidated userptr list as described in the previous section,
+there is nothing keeping those userptr gpu_vmas alive.
+
+Locking for recoverable page-fault page-table updates
+=====================================================
+
+There are two important things we need to ensure with locking for
+recoverable page-faults:
+
+* At the time we return pages back to the system / allocator for
+ reuse, there should be no remaining GPU mappings and any GPU TLB
+ must have been flushed.
+* The unmapping and mapping of a gpu_vma must not race.
+
+Since the unmapping (or zapping) of GPU ptes is typically taking place
+where it is hard or even impossible to take any outer level locks we
+must either introduce a new lock that is held at both mapping and
+unmapping time, or look at the locks we do hold at unmapping time and
+make sure that they are held also at mapping time. For userptr
+gpu_vmas, the ``userptr_seqlock`` is held in write mode in the mmu
+invalidation notifier where zapping happens. Hence, if the
+``userptr_seqlock`` as well as the ``gpu_vm->userptr_notifier_lock``
+is held in read mode during mapping, it will not race with the
+zapping. For GEM object backed gpu_vmas, zapping will take place under
+the GEM object's dma_resv and ensuring that the dma_resv is held also
+when populating the page-tables for any gpu_vma pointing to the GEM
+object, will similarly ensure we are race-free.
+
+If any part of the mapping is performed asynchronously
+under a dma-fence with these locks released, the zapping will need to
+wait for that dma-fence to signal under the relevant lock before
+starting to modify the page-table.
+
+Since modifying the
+page-table structure in a way that frees up page-table memory
+might also require outer level locks, the zapping of GPU ptes
+typically focuses only on zeroing page-table or page-directory entries
+and flushing TLB, whereas freeing of page-table memory is deferred to
+unbind or rebind time.
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..eba09c3ddce4 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -35,10 +35,10 @@ Interrupt Handling
:functions: intel_irq_init intel_irq_init_hw intel_hpd_init
.. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c
- :functions: intel_runtime_pm_disable_interrupts
+ :functions: intel_irq_suspend
.. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c
- :functions: intel_runtime_pm_enable_interrupts
+ :functions: intel_irq_resume
Intel GVT-g Guest Support(vGPU)
-------------------------------
@@ -112,10 +112,10 @@ panel self refresh.
Atomic Plane Helpers
--------------------
-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
:doc: atomic plane helpers
-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_plane.c
:internal:
Asynchronous Page Flip
@@ -150,7 +150,7 @@ High Definition Audio
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c
:internal:
-.. kernel-doc:: include/drm/i915_component.h
+.. kernel-doc:: include/drm/intel/i915_component.h
:internal:
Intel HDMI LPE Audio Support
@@ -204,6 +204,18 @@ DMC Firmware Support
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
:internal:
+DMC Flip Queue
+--------------------
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_flipq.c
+ :doc: DMC Flip Queue
+
+DMC wakelock support
+--------------------
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c
+ :doc: DMC wakelock support
+
Video BIOS Table (VBT)
----------------------
@@ -267,19 +279,22 @@ i915 driver.
Intel GPU Basics
----------------
-An Intel GPU has multiple engines. There are several engine types.
-
-- RCS engine is for rendering 3D and performing compute, this is named
- `I915_EXEC_RENDER` in user space.
-- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user
- space.
-- VCS is a video encode and decode engine, this is named `I915_EXEC_BSD`
- in user space
-- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user
- space.
-- The enumeration `I915_EXEC_DEFAULT` does not refer to specific engine;
- instead it is to be used by user space to specify a default rendering
- engine (for 3D) that may or may not be the same as RCS.
+An Intel GPU has multiple engines. There are several engine types:
+
+- Render Command Streamer (RCS). An engine for rendering 3D and
+ performing compute.
+- Blitting Command Streamer (BCS). An engine for performing blitting and/or
+ copying operations.
+- Video Command Streamer. An engine used for video encoding and decoding. Also
+ sometimes called 'BSD' in hardware documentation.
+- Video Enhancement Command Streamer (VECS). An engine for video enhancement.
+ Also sometimes called 'VEBOX' in hardware documentation.
+- Compute Command Streamer (CCS). An engine that has access to the media and
+ GPGPU pipelines, but not the 3D pipeline.
+- Graphics Security Controller (GSCCS). A dedicated engine for internal
+ communication with GSC controller on security related tasks like
+ High-bandwidth Digital Content Protection (HDCP), Protected Xe Path (PXP),
+ and HuC firmware authentication.
The Intel GPU family is a family of integrated GPU's using Unified
Memory Access. For having the GPU "do work", user space will feed the
@@ -304,10 +319,10 @@ reads of following commands. Actions issued between different contexts
and the only way to synchronize across contexts (even from the same
file descriptor) is through the use of fences. At least as far back as
Gen4, also have that a context carries with it a GPU HW context;
-the HW context is essentially (most of atleast) the state of a GPU.
+the HW context is essentially (most of at least) the state of a GPU.
In addition to the ordering guarantees, the kernel will restore GPU
state via HW context when commands are issued to a context, this saves
-user space the need to restore (most of atleast) the GPU state at the
+user space the need to restore (most of at least) the GPU state at the
start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer
work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1)
to identify what context to use with the command.
@@ -343,8 +358,6 @@ Locking Guidelines
#. All locking rules and interface contracts with cross-driver interfaces
(dma-buf, dma_fence) need to be followed.
-#. No struct_mutex anywhere in the code
-
#. dma_resv will be the outermost lock (when needed) and ww_acquire_ctx
is to be hoisted at highest level and passed down within i915_gem_ctx
in the call chain
@@ -352,11 +365,6 @@ Locking Guidelines
#. While holding lru/memory manager (buddy, drm_mm, whatever) locks
system memory allocations are not allowed
- * Enforce this by priming lockdep (with fs_reclaim). If we
- allocate memory while holding these looks we get a rehash
- of the shrinker vs. struct_mutex saga, and that would be
- real bad.
-
#. Do not nest different lru/memory manager locks within each other.
Take them in turn to update memory allocations, relying on the object’s
dma_resv ww_mutex to serialize against other operations.
@@ -494,7 +502,7 @@ WOPCM
WOPCM Layout
~~~~~~~~~~~~
-.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_wopcm.c
:doc: WOPCM Layout
GuC
diff --git a/Documentation/gpu/imagination/index.rst b/Documentation/gpu/imagination/index.rst
new file mode 100644
index 000000000000..0c1e247cea41
--- /dev/null
+++ b/Documentation/gpu/imagination/index.rst
@@ -0,0 +1,13 @@
+=======================================
+drm/imagination PowerVR Graphics Driver
+=======================================
+
+.. kernel-doc:: drivers/gpu/drm/imagination/pvr_drv.c
+ :doc: PowerVR (Series 6 and later) and IMG Graphics Driver
+
+Contents
+========
+.. toctree::
+ :maxdepth: 2
+
+ uapi
diff --git a/Documentation/gpu/imagination/uapi.rst b/Documentation/gpu/imagination/uapi.rst
new file mode 100644
index 000000000000..7502413d0a93
--- /dev/null
+++ b/Documentation/gpu/imagination/uapi.rst
@@ -0,0 +1,171 @@
+====
+UAPI
+====
+The sources associated with this section can be found in ``pvr_drm.h``.
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR UAPI
+
+OBJECT ARRAYS
+=============
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_obj_array
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: DRM_PVR_OBJ_ARRAY
+
+IOCTLS
+======
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL interface
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: PVR_IOCTL
+
+DEV_QUERY
+---------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL DEV_QUERY interface
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_dev_query
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_dev_query_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_dev_query_gpu_info
+ drm_pvr_dev_query_runtime_info
+ drm_pvr_dev_query_hwrt_info
+ drm_pvr_dev_query_quirks
+ drm_pvr_dev_query_enhancements
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_heap_id
+ drm_pvr_heap
+ drm_pvr_dev_query_heap_info
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_static_data_area_usage
+ drm_pvr_static_data_area
+ drm_pvr_dev_query_static_data_areas
+
+CREATE_BO
+---------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL CREATE_BO interface
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_create_bo_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: Flags for CREATE_BO
+
+GET_BO_MMAP_OFFSET
+------------------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL GET_BO_MMAP_OFFSET interface
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_get_bo_mmap_offset_args
+
+CREATE_VM_CONTEXT and DESTROY_VM_CONTEXT
+----------------------------------------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL CREATE_VM_CONTEXT and DESTROY_VM_CONTEXT interfaces
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_create_vm_context_args
+ drm_pvr_ioctl_destroy_vm_context_args
+
+VM_MAP and VM_UNMAP
+-------------------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL VM_MAP and VM_UNMAP interfaces
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_vm_map_args
+ drm_pvr_ioctl_vm_unmap_args
+
+CREATE_CONTEXT and DESTROY_CONTEXT
+----------------------------------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL CREATE_CONTEXT and DESTROY_CONTEXT interfaces
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_create_context_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ctx_priority
+ drm_pvr_ctx_type
+ drm_pvr_static_render_context_state
+ drm_pvr_static_render_context_state_format
+ drm_pvr_reset_framework
+ drm_pvr_reset_framework_format
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_destroy_context_args
+
+CREATE_FREE_LIST and DESTROY_FREE_LIST
+--------------------------------------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL CREATE_FREE_LIST and DESTROY_FREE_LIST interfaces
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_create_free_list_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_destroy_free_list_args
+
+CREATE_HWRT_DATASET and DESTROY_HWRT_DATASET
+--------------------------------------------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL CREATE_HWRT_DATASET and DESTROY_HWRT_DATASET interfaces
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_create_hwrt_dataset_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_create_hwrt_geom_data_args
+ drm_pvr_create_hwrt_rt_data_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_destroy_hwrt_dataset_args
+
+SUBMIT_JOBS
+-----------
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: PowerVR IOCTL SUBMIT_JOBS interface
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: Flags for the drm_pvr_sync_op object.
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_ioctl_submit_jobs_args
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: Flags for SUBMIT_JOB ioctl geometry command.
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: Flags for SUBMIT_JOB ioctl fragment command.
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: Flags for SUBMIT_JOB ioctl compute command.
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :doc: Flags for SUBMIT_JOB ioctl transfer command.
+
+.. kernel-doc:: include/uapi/drm/pvr_drm.h
+ :identifiers: drm_pvr_sync_op
+ drm_pvr_job_type
+ drm_pvr_hwrt_data_ref
+ drm_pvr_job
+
+Internal notes
+==============
+.. kernel-doc:: drivers/gpu/drm/imagination/pvr_device.h
+ :doc: IOCTL validation helpers
+
+.. kernel-doc:: drivers/gpu/drm/imagination/pvr_device.h
+ :identifiers: PVR_STATIC_ASSERT_64BIT_ALIGNED PVR_IOCTL_UNION_PADDING_CHECK
+ pvr_ioctl_union_padding_check
diff --git a/Documentation/gpu/implementation_guidelines.rst b/Documentation/gpu/implementation_guidelines.rst
new file mode 100644
index 000000000000..dbccfa72f1c9
--- /dev/null
+++ b/Documentation/gpu/implementation_guidelines.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===========================================================
+Misc DRM driver uAPI- and feature implementation guidelines
+===========================================================
+
+.. toctree::
+
+ drm-vm-bind-async
+ drm-vm-bind-locking
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index b99dede9a5b1..7dcb15850afd 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -1,6 +1,6 @@
-==================================
-Linux GPU Driver Developer's Guide
-==================================
+============================
+GPU Driver Developer's Guide
+============================
.. toctree::
@@ -13,10 +13,13 @@ Linux GPU Driver Developer's Guide
drm-usage-stats
driver-uapi
drm-client
+ drm-compute
drivers
backlight
vga-switcheroo
vgaarbiter
+ automated_testing
+ implementation_guidelines
todo
rfc/index
diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst
index f05eccd2c07c..3cd0c8860b94 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -154,21 +154,23 @@ Conference talks
* `An Overview of the Linux and Userspace Graphics Stack <https://www.youtube.com/watch?v=wjAJmqwg47k>`_ - Paul Kocialkowski (2020)
* `Getting pixels on screen on Linux: introduction to Kernel Mode Setting <https://www.youtube.com/watch?v=haes4_Xnc5Q>`_ - Simon Ser (2020)
-* `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Daniel Vetter (2019)
+* `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Simona Vetter (2019)
* `An introduction to the Linux DRM subsystem <https://www.youtube.com/watch?v=LbDOCJcDRoo>`_ - Maxime Ripard (2017)
-* `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Daniel Vetter (2016)
+* `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Simona Vetter (2016)
* `Anatomy of an Atomic KMS Driver <https://www.youtube.com/watch?v=lihqR9sENpc>`_ - Laurent Pinchart (2015)
-* `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Daniel Vetter (2015)
+* `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Simona Vetter (2015)
* `Anatomy of an Embedded KMS Driver <https://www.youtube.com/watch?v=Ja8fM7rTae4>`_ - Laurent Pinchart (2013)
Slides and articles
-------------------
+* `The Linux graphics stack in a nutshell, part 1 <https://lwn.net/Articles/955376/>`_ - Thomas Zimmermann (2023)
+* `The Linux graphics stack in a nutshell, part 2 <https://lwn.net/Articles/955708/>`_ - Thomas Zimmermann (2023)
* `Understanding the Linux Graphics Stack <https://bootlin.com/doc/training/graphics/graphics-slides.pdf>`_ - Bootlin (2022)
* `DRM KMS overview <https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview>`_ - STMicroelectronics (2021)
* `Linux graphic stack <https://studiopixl.com/2017-05-13/linux-graphic-stack-an-overview>`_ - Nathan Gauër (2017)
-* `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Daniel Vetter (2015)
-* `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Daniel Vetter (2015)
+* `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Simona Vetter (2015)
+* `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Simona Vetter (2015)
* `The DRM/KMS subsystem from a newbie’s point of view <https://bootlin.com/pub/conferences/2014/elce/brezillon-drm-kms/brezillon-drm-kms.pdf>`_ - Boris Brezillon (2014)
* `A brief introduction to the Linux graphics stack <https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/>`_ - Iago Toral (2014)
* `The Linux Graphics Stack <https://blog.mecheye.net/2012/06/the-linux-graphics-stack/>`_ - Jasper St. Pierre (2012)
diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd6..bfbfbf4f102d 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De
,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector
,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB
-i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255."
,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD
,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
@@ -38,7 +37,6 @@ i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:2
,,“dot_crawl”,RANGE,"Min=0, Max=1",Connector,TBD
,SDVO-TV/LVDS,“brightness”,RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
CDV gma-500,Generic,"""Broadcast RGB""",ENUM,"{ “Full”, “Limited 16:235” }",Connector,TBD
-,,"""Broadcast RGB""",ENUM,"{ “off”, “auto”, “on” }",Connector,TBD
Poulsbo,Generic,“backlight”,RANGE,"Min=0, Max=100",Connector,TBD
,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD
,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d..eaea40eb725b 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -86,7 +86,7 @@ types of working mode:
- Single display mode
Two pipelines work together to drive only one display output.
- On this mode, pipeline_B doesn't work indenpendently, but outputs its
+ On this mode, pipeline_B doesn't work independently, but outputs its
composition result into pipeline_A, and its pixel timing also derived from
pipeline_A.timing_ctrlr. The pipeline_B works just like a "slave" of
pipeline_A(master)
@@ -328,7 +328,7 @@ of course we’d better share as much as possible between different products. To
achieve this, split the komeda device into two layers: CORE and CHIP.
- CORE: for common features and capabilities handling.
-- CHIP: for register programing and HW specific feature (limitation) handling.
+- CHIP: for register programming and HW specific feature (limitation) handling.
CORE can access CHIP by three chip function structures:
@@ -481,7 +481,7 @@ Build komeda to be a Linux module driver
Now we have two level devices:
- komeda_dev: describes the real display hardware.
-- komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS.
+- komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS.
All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev,
the module driver is only a simple wrapper to pass the Linux command
diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
index 240ef200f76c..9509cc4224f4 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -23,7 +23,7 @@ module
The module that generated the crashdump.
time
- The kernel time at crash formated as seconds.microseconds.
+ The kernel time at crash formatted as seconds.microseconds.
comm
Comm string for the binary that generated the fault.
diff --git a/Documentation/gpu/msm-preemption.rst b/Documentation/gpu/msm-preemption.rst
new file mode 100644
index 000000000000..d768ca09fdec
--- /dev/null
+++ b/Documentation/gpu/msm-preemption.rst
@@ -0,0 +1,99 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+:orphan:
+
+==============
+MSM Preemption
+==============
+
+Preemption allows Adreno GPUs to switch to a higher priority ring when work is
+pushed to it, reducing latency for high priority submissions.
+
+When preemption is enabled 4 rings are initialized, corresponding to different
+priority levels. Having multiple rings is purely a software concept as the GPU
+only has registers to keep track of one graphics ring.
+The kernel is able to switch which ring is currently being processed by
+requesting preemption. When certain conditions are met, depending on the
+priority level, the GPU will save its current state in a series of buffers,
+then restores state from a similar set of buffers specified by the kernel. It
+then resumes execution and fires an IRQ to let the kernel know the context
+switch has completed.
+
+This mechanism can be used by the kernel to switch between rings. Whenever a
+submission occurs the kernel finds the highest priority ring which isn't empty
+and preempts to it if said ring is not the one being currently executed. This is
+also done whenever a submission completes to make sure execution resumes on a
+lower priority ring when a higher priority ring is done.
+
+Preemption levels
+-----------------
+
+Preemption can only occur at certain boundaries. The exact conditions can be
+configured by changing the preemption level, this allows to compromise between
+latency (ie. the time that passes between when the kernel requests preemption
+and when the SQE begins saving state) and overhead (the amount of state that
+needs to be saved).
+
+The GPU offers 3 levels:
+
+Level 0
+ Preemption only occurs at the submission level. This requires the least amount
+ of state to be saved as the execution of userspace submitted IBs is never
+ interrupted, however it offers very little benefit compared to not enabling
+ preemption of any kind.
+
+Level 1
+ Preemption occurs at either bin level, if using GMEM rendering, or draw level
+ in the sysmem rendering case.
+
+Level 2
+ Preemption occurs at draw level.
+
+Level 1 is the mode that is used by the msm driver.
+
+Additionally the GPU allows to specify a `skip_save_restore` option. This
+disables the saving and restoring of all registers except those relating to the
+operation of the SQE itself, reducing overhead. Saving and restoring is only
+skipped when using GMEM with Level 1 preemption. When enabling this userspace is
+expected to set the state that isn't preserved whenever preemption occurs which
+is done by specifying preamble and postambles. Those are IBs that are executed
+before and after preemption.
+
+Preemption buffers
+------------------
+
+A series of buffers are necessary to store the state of rings while they are not
+being executed. There are different kinds of preemption records and most of
+those require one buffer per ring. This is because preemption never occurs
+between submissions on the same ring, which always run in sequence when the ring
+is active. This means that only one context per ring is effectively active.
+
+SMMU_INFO
+ This buffer contains info about the current SMMU configuration such as the
+ ttbr0 register. The SQE firmware isn't actually able to save this record.
+ As a result SMMU info must be saved manually from the CP to a buffer and the
+ SMMU record updated with info from said buffer before triggering
+ preemption.
+
+NON_SECURE
+ This is the main preemption record where most state is saved. It is mostly
+ opaque to the kernel except for the first few words that must be initialized
+ by the kernel.
+
+SECURE
+ This saves state related to the GPU's secure mode.
+
+NON_PRIV
+ The intended purpose of this record is unknown. The SQE firmware actually
+ ignores it and therefore msm doesn't handle it.
+
+COUNTER
+ This record is used to save and restore performance counters.
+
+Handling the permissions of those buffers is critical for security. All but the
+NON_PRIV records need to be inaccessible from userspace, so they must be mapped
+in the kernel address space with the MSM_BO_MAP_PRIV flag.
+For example, making the NON_SECURE record accessible from userspace would allow
+any process to manipulate a saved ring's RPTR which can be used to skip the
+execution of some packets in a ring and execute user commands with higher
+privileges.
diff --git a/Documentation/gpu/nouveau.rst b/Documentation/gpu/nouveau.rst
new file mode 100644
index 000000000000..cab2e81013bc
--- /dev/null
+++ b/Documentation/gpu/nouveau.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===============================
+ drm/nouveau NVIDIA GPU Driver
+===============================
+
+The drm/nouveau driver provides support for a wide range of NVIDIA GPUs,
+covering GeForce, Quadro, and Tesla series, from the NV04 architecture up
+to the latest Turing, Ampere, Ada families.
+
+NVKM: NVIDIA Kernel Manager
+===========================
+
+The NVKM component serves as the core abstraction layer within the nouveau
+driver, responsible for managing NVIDIA GPU hardware at the kernel level.
+NVKM provides a unified interface for handling various GPU architectures.
+
+It enables resource management, power control, memory handling, and command
+submission required for the proper functioning of NVIDIA GPUs under the
+nouveau driver.
+
+NVKM plays a critical role in abstracting hardware complexities and
+providing a consistent API to upper layers of the driver stack.
+
+GSP Support
+------------------------
+
+.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c
+ :doc: GSP message queue element
+
+.. kernel-doc:: drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h
+ :doc: GSP message handling policy
diff --git a/Documentation/gpu/nova/core/devinit.rst b/Documentation/gpu/nova/core/devinit.rst
new file mode 100644
index 000000000000..70c819a96a00
--- /dev/null
+++ b/Documentation/gpu/nova/core/devinit.rst
@@ -0,0 +1,61 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================================
+Device Initialization (devinit)
+==================================
+The devinit process is complex and subject to change. This document provides a high-level
+overview using the Ampere GPU family as an example. The goal is to provide a conceptual
+overview of the process to aid in understanding the corresponding kernel code.
+
+Device initialization (devinit) is a crucial sequence of register read/write operations
+that occur after a GPU reset. The devinit sequence is essential for properly configuring
+the GPU hardware before it can be used.
+
+The devinit engine is an interpreter program that typically runs on the PMU (Power Management
+Unit) microcontroller of the GPU. This interpreter executes a "script" of initialization
+commands. The devinit engine itself is part of the VBIOS ROM in the same ROM image as the
+FWSEC (Firmware Security) image (see fwsec.rst and vbios.rst) and it runs before the
+nova-core driver is even loaded. On an Ampere GPU, the devinit ucode is separate from the
+FWSEC ucode. It is launched by FWSEC, which runs on the GSP in 'heavy-secure' mode, while
+devinit runs on the PMU in 'light-secure' mode.
+
+Key Functions of devinit
+------------------------
+devinit performs several critical tasks:
+
+1. Programming VRAM memory controller timings
+2. Power sequencing
+3. Clock and PLL (Phase-Locked Loop) configuration
+4. Thermal management
+
+Low-level Firmware Initialization Flow
+--------------------------------------
+Upon reset, several microcontrollers on the GPU (such as PMU, SEC2, GSP, etc.) run GPU
+firmware (gfw) code to set up the GPU and its core parameters. Most of the GPU is
+considered unusable until this initialization process completes.
+
+These low-level GPU firmware components are typically:
+
+1. Located in the VBIOS ROM in the same ROM partition (see vbios.rst and fwsec.rst).
+2. Executed in sequence on different microcontrollers:
+
+ - The devinit engine typically but not necessarily runs on the PMU.
+ - On an Ampere GPU, the FWSEC typically runs on the GSP (GPU System Processor) in
+ heavy-secure mode.
+
+Before the driver can proceed with further initialization, it must wait for a signal
+indicating that core initialization is complete (known as GFW_BOOT). This signal is
+asserted by the FWSEC running on the GSP in heavy-secure mode.
+
+Runtime Considerations
+----------------------
+It's important to note that the devinit sequence also needs to run during suspend/resume
+operations at runtime, not just during initial boot, as it is critical to power management.
+
+Security and Access Control
+---------------------------
+The initialization process involves careful privilege management. For example, before
+accessing certain completion status registers, the driver must check privilege level
+masks. Some registers are only accessible after secure firmware (FWSEC) lowers the
+privilege level to allow CPU (LS/low-secure) access. This is the case, for example,
+when receiving the GFW_BOOT signal. \ No newline at end of file
diff --git a/Documentation/gpu/nova/core/falcon.rst b/Documentation/gpu/nova/core/falcon.rst
new file mode 100644
index 000000000000..33137082eb6c
--- /dev/null
+++ b/Documentation/gpu/nova/core/falcon.rst
@@ -0,0 +1,158 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Falcon (FAst Logic Controller)
+==============================
+The following sections describe the Falcon core and the ucode running on it.
+The descriptions are based on the Ampere GPU or earlier designs; however, they
+should mostly apply to future designs as well, but everything is subject to
+change. The overview provided here is mainly tailored towards understanding the
+interactions of nova-core driver with the Falcon.
+
+NVIDIA GPUs embed small RISC-like microcontrollers called Falcon cores, which
+handle secure firmware tasks, initialization, and power management. Modern
+NVIDIA GPUs may have multiple such Falcon instances (e.g., GSP (the GPU system
+processor) and SEC2 (the security engine)) and also may integrate a RISC-V core.
+This core is capable of running both RISC-V and Falcon code.
+
+The code running on the Falcon cores is also called 'ucode', and will be
+referred to as such in the following sections.
+
+Falcons have separate instruction and data memories (IMEM/DMEM) and provide a
+small DMA engine (via the FBIF - "Frame Buffer Interface") to load code from
+system memory. The nova-core driver must reset and configure the Falcon, load
+its firmware via DMA, and start its CPU.
+
+Falcon security levels
+======================
+Falcons can run in Non-secure (NS), Light Secure (LS), or Heavy Secure (HS)
+modes.
+
+Heavy Secured (HS) also known as Privilege Level 3 (PL3)
+--------------------------------------------------------
+HS ucode is the most trusted code and has access to pretty much everything on
+the chip. The HS binary includes a signature in it which is verified at boot.
+This signature verification is done by the hardware itself, thus establishing a
+root of trust. For example, the FWSEC-FRTS command (see fwsec.rst) runs on the
+GSP in HS mode. FRTS, which involves setting up and loading content into the WPR
+(Write Protect Region), has to be done by the HS ucode and cannot be done by the
+host CPU or LS ucode.
+
+Light Secured (LS or PL2) and Non Secured (NS or PL0)
+-----------------------------------------------------
+These modes are less secure than HS. Like HS, the LS or NS ucode binary also
+typically includes a signature in it. To load firmware in LS or NS mode onto a
+Falcon, another Falcon needs to be running in HS mode, which also establishes the
+root of trust. For example, in the case of an Ampere GPU, the CPU runs the "Booter"
+ucode in HS mode on the SEC2 Falcon, which then authenticates and runs the
+run-time GSP binary (GSP-RM) in LS mode on the GSP Falcon. Similarly, as an
+example, after reset on an Ampere, FWSEC runs on the GSP which then loads the
+devinit engine onto the PMU in LS mode.
+
+Root of trust establishment
+---------------------------
+To establish a root of trust, the code running on a Falcon must be immutable and
+hardwired into a read-only memory (ROM). This follows industry norms for
+verification of firmware. This code is called the Boot ROM (BROM). The nova-core
+driver on the CPU communicates with Falcon's Boot ROM through various Falcon
+registers prefixed with "BROM" (see regs.rs).
+
+After nova-core driver reads the necessary ucode from VBIOS, it programs the
+BROM and DMA registers to trigger the Falcon to load the HS ucode from the system
+memory into the Falcon's IMEM/DMEM. Once the HS ucode is loaded, it is verified
+by the Falcon's Boot ROM.
+
+Once the verified HS code is running on a Falcon, it can verify and load other
+LS/NS ucode binaries onto other Falcons and start them. The process of signature
+verification is the same as HS; just in this case, the hardware (BROM) doesn't
+compute the signature, but the HS ucode does.
+
+The root of trust is therefore established as follows:
+ Hardware (Boot ROM running on the Falcon) -> HS ucode -> LS/NS ucode.
+
+On an Ampere GPU, for example, the boot verification flow is:
+ Hardware (Boot ROM running on the SEC2) ->
+ HS ucode (Booter running on the SEC2) ->
+ LS ucode (GSP-RM running on the GSP)
+
+.. note::
+ While the CPU can load HS ucode onto a Falcon microcontroller and have it
+ verified by the hardware and run, the CPU itself typically does not load
+ LS or NS ucode and run it. Loading of LS or NS ucode is done mainly by the
+ HS ucode. For example, on an Ampere GPU, after the Booter ucode runs on the
+ SEC2 in HS mode and loads the GSP-RM binary onto the GSP, it needs to run
+ the "SEC2-RTOS" ucode at runtime. This presents a problem: there is no
+ component to load the SEC2-RTOS ucode onto the SEC2. The CPU cannot load
+ LS code, and GSP-RM must run in LS mode. To overcome this, the GSP is
+ temporarily made to run HS ucode (which is itself loaded by the CPU via
+ the nova-core driver using a "GSP-provided sequencer") which then loads
+ the SEC2-RTOS ucode onto the SEC2 in LS mode. The GSP then resumes
+ running its own GSP-RM LS ucode.
+
+Falcon memory subsystem and DMA engine
+======================================
+Falcons have separate instruction and data memories (IMEM/DMEM)
+and contains a small DMA engine called FBDMA (Framebuffer DMA) which does
+DMA transfers to/from the IMEM/DMEM memory inside the Falcon via the FBIF
+(Framebuffer Interface), to external memory.
+
+DMA transfers are possible from the Falcon's memory to both the system memory
+and the framebuffer memory (VRAM).
+
+To perform a DMA via the FBDMA, the FBIF is configured to decide how the memory
+is accessed (also known as aperture type). In the nova-core driver, this is
+determined by the `FalconFbifTarget` enum.
+
+The IO-PMP block (Input/Output Physical Memory Protection) unit in the Falcon
+controls access by the FBDMA to the external memory.
+
+Conceptual diagram (not exact) of the Falcon and its memory subsystem is as follows::
+
+ External Memory (Framebuffer / System DRAM)
+ ^ |
+ | |
+ | v
+ +-----------------------------------------------------+
+ | | |
+ | +---------------+ | |
+ | | FBIF |-------+ | FALCON
+ | | (FrameBuffer | Memory Interface | PROCESSOR
+ | | InterFace) | |
+ | | Apertures | |
+ | | Configures | |
+ | | mem access | |
+ | +-------^-------+ |
+ | | |
+ | | FBDMA uses configured FBIF apertures |
+ | | to access External Memory
+ | |
+ | +-------v--------+ +---------------+
+ | | FBDMA | cfg | RISC |
+ | | (FrameBuffer |<---->| CORE |----->. Direct Core Access
+ | | DMA Engine) | | | |
+ | | - Master dev. | | (can run both | |
+ | +-------^--------+ | Falcon and | |
+ | | cfg--->| RISC-V code) | |
+ | | / | | |
+ | | | +---------------+ | +------------+
+ | | | | | BROM |
+ | | | <--->| (Boot ROM) |
+ | | / | +------------+
+ | | v |
+ | +---------------+ |
+ | | IO-PMP | Controls access by FBDMA |
+ | | (IO Physical | and other IO Masters |
+ | | Memory Protect) |
+ | +-------^-------+ |
+ | | |
+ | | Protected Access Path for FBDMA |
+ | v |
+ | +---------------------------------------+ |
+ | | Memory | |
+ | | +---------------+ +------------+ | |
+ | | | IMEM | | DMEM | |<-----+
+ | | | (Instruction | | (Data | |
+ | | | Memory) | | Memory) | |
+ | | +---------------+ +------------+ |
+ | +---------------------------------------+
+ +-----------------------------------------------------+
diff --git a/Documentation/gpu/nova/core/fwsec.rst b/Documentation/gpu/nova/core/fwsec.rst
new file mode 100644
index 000000000000..c440edbe420c
--- /dev/null
+++ b/Documentation/gpu/nova/core/fwsec.rst
@@ -0,0 +1,181 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=========================
+FWSEC (Firmware Security)
+=========================
+This document briefly/conceptually describes the FWSEC (Firmware Security) image
+and its role in the GPU boot sequence. As such, this information is subject to
+change in the future and is only current as of the Ampere GPU family. However,
+hopefully the concepts described will be useful for understanding the kernel code
+that deals with it. All the information is derived from publicly available
+sources such as public drivers and documentation.
+
+The role of FWSEC is to provide a secure boot process. It runs in
+'Heavy-secure' mode, and performs firmware verification after a GPU reset
+before loading various ucode images onto other microcontrollers on the GPU,
+such as the PMU and GSP.
+
+FWSEC itself is an application stored in the VBIOS ROM in the FWSEC partition of
+ROM (see vbios.rst for more details). It contains different commands like FRTS
+(Firmware Runtime Services) and SB (Secure Booting other microcontrollers after
+reset and loading them with other non-FWSEC ucode). The kernel driver only needs
+to perform FRTS, since Secure Boot (SB) has already completed by the time the driver
+is loaded.
+
+The FRTS command carves out the WPR2 region (Write protected region) which contains
+data required for power management. Once setup, only HS mode ucode can access it
+(see falcon.rst for privilege levels).
+
+The FWSEC image is located in the VBIOS ROM in the partition of the ROM that contains
+various ucode images (also known as applications) -- one of them being FWSEC. For how
+it is extracted, see vbios.rst and the vbios.rs source code.
+
+The Falcon data for each ucode images (including the FWSEC image) is a combination
+of headers, data sections (DMEM) and instruction code sections (IMEM). All these
+ucode images are stored in the same ROM partition and the PMU table is used to look
+up the application to load it based on its application ID (see vbios.rs).
+
+For the nova-core driver, the FWSEC contains an 'application interface' called
+DMEMMAPPER. This interface is used to execute the 'FWSEC-FRTS' command, among others.
+For Ampere, FWSEC is running on the GSP in Heavy-secure mode and runs FRTS.
+
+FWSEC Memory Layout
+-------------------
+The memory layout of the FWSEC image is as follows::
+
+ +---------------------------------------------------------------+
+ | FWSEC ROM image (type 0xE0) |
+ | |
+ | +---------------------------------+ |
+ | | PMU Falcon Ucode Table | |
+ | | (PmuLookupTable) | |
+ | | +-------------------------+ | |
+ | | | Table Header | | |
+ | | | - version: 0x01 | | |
+ | | | - header_size: 6 | | |
+ | | | - entry_size: 6 | | |
+ | | | - entry_count: N | | |
+ | | | - desc_version:3(unused)| | |
+ | | +-------------------------+ | |
+ | | ... | |
+ | | +-------------------------+ | |
+ | | | Entry for FWSEC (0x85) | | |
+ | | | (PmuLookupTableEntry) | | |
+ | | | - app_id: 0x85 (FWSEC) |----|----+ |
+ | | | - target_id: 0x01 (PMU) | | | |
+ | | | - data: offset ---------|----|----|---+ look up FWSEC |
+ | | +-------------------------+ | | | |
+ | +---------------------------------+ | | |
+ | | | |
+ | | | |
+ | +---------------------------------+ | | |
+ | | FWSEC Ucode Component |<---+ | |
+ | | (aka Falcon data) | | |
+ | | +-------------------------+ | | |
+ | | | FalconUCodeDescV3 |<---|--------+ |
+ | | | - hdr | | |
+ | | | - stored_size | | |
+ | | | - pkc_data_offset | | |
+ | | | - interface_offset -----|----|----------------+ |
+ | | | - imem_phys_base | | | |
+ | | | - imem_load_size | | | |
+ | | | - imem_virt_base | | | |
+ | | | - dmem_phys_base | | | |
+ | | | - dmem_load_size | | | |
+ | | | - engine_id_mask | | | |
+ | | | - ucode_id | | | |
+ | | | - signature_count | | look up sig | |
+ | | | - signature_versions --------------+ | |
+ | | +-------------------------+ | | | |
+ | | (no gap) | | | |
+ | | +-------------------------+ | | | |
+ | | | Signatures Section |<---|-----+ | |
+ | | | (384 bytes per sig) | | | |
+ | | | - RSA-3K Signature 1 | | | |
+ | | | - RSA-3K Signature 2 | | | |
+ | | | ... | | | |
+ | | +-------------------------+ | | |
+ | | | | |
+ | | +-------------------------+ | | |
+ | | | IMEM Section (Code) | | | |
+ | | | | | | |
+ | | | Contains instruction | | | |
+ | | | code etc. | | | |
+ | | +-------------------------+ | | |
+ | | | | |
+ | | +-------------------------+ | | |
+ | | | DMEM Section (Data) | | | |
+ | | | | | | |
+ | | | +---------------------+ | | | |
+ | | | | Application | |<---|----------------+ |
+ | | | | Interface Table | | | |
+ | | | | (FalconAppifHdrV1) | | | |
+ | | | | Header: | | | |
+ | | | | - version: 0x01 | | | |
+ | | | | - header_size: 4 | | | |
+ | | | | - entry_size: 8 | | | |
+ | | | | - entry_count: N | | | |
+ | | | | | | | |
+ | | | | Entries: | | | |
+ | | | | +-----------------+ | | | |
+ | | | | | DEVINIT (ID 1) | | | | |
+ | | | | | - id: 0x01 | | | | |
+ | | | | | - dmemOffset X -|-|-|----+ |
+ | | | | +-----------------+ | | | |
+ | | | | +-----------------+ | | | |
+ | | | | | DMEMMAPPER(ID 4)| | | | |
+ | | | | | - id: 0x04 | | | | Used only for DevInit |
+ | | | | | (NVFW_FALCON_ | | | | application (not FWSEC) |
+ | | | | | APPIF_ID_DMEMMAPPER) | |
+ | | | | | - dmemOffset Y -|-|-|----|-----+ |
+ | | | | +-----------------+ | | | | |
+ | | | +---------------------+ | | | |
+ | | | | | | |
+ | | | +---------------------+ | | | |
+ | | | | DEVINIT Engine |<|----+ | Used by FWSEC |
+ | | | | Interface | | | | app. |
+ | | | +---------------------+ | | | |
+ | | | | | | |
+ | | | +---------------------+ | | | |
+ | | | | DMEM Mapper (ID 4) |<|----+-----+ |
+ | | | | (FalconAppifDmemmapperV3) | |
+ | | | | - signature: "DMAP" | | | |
+ | | | | - version: 0x0003 | | | |
+ | | | | - Size: 64 bytes | | | |
+ | | | | - cmd_in_buffer_off | |----|------------+ |
+ | | | | - cmd_in_buffer_size| | | | |
+ | | | | - cmd_out_buffer_off| |----|------------|-----+ |
+ | | | | - cmd_out_buffer_sz | | | | | |
+ | | | | - init_cmd | | | | | |
+ | | | | - features | | | | | |
+ | | | | - cmd_mask0/1 | | | | | |
+ | | | +---------------------+ | | | | |
+ | | | | | | | |
+ | | | +---------------------+ | | | | |
+ | | | | Command Input Buffer|<|----|------------+ | |
+ | | | | - Command data | | | | |
+ | | | | - Arguments | | | | |
+ | | | +---------------------+ | | | |
+ | | | | | | |
+ | | | +---------------------+ | | | |
+ | | | | Command Output |<|----|------------------+ |
+ | | | | Buffer | | | |
+ | | | | - Results | | | |
+ | | | | - Status | | | |
+ | | | +---------------------+ | | |
+ | | +-------------------------+ | |
+ | +---------------------------------+ |
+ | |
+ +---------------------------------------------------------------+
+
+.. note::
+ This is using an GA-102 Ampere GPU as an example and could vary for future GPUs.
+
+.. note::
+ The FWSEC image also plays a role in memory scrubbing (ECC initialization) and VPR
+ (Video Protected Region) initialization as well. Before the nova-core driver is even
+ loaded, the FWSEC image is running on the GSP in heavy-secure mode. After the devinit
+ sequence completes, it does VRAM memory scrubbing (ECC initialization). On consumer
+ GPUs, it scrubs only part of memory and then initiates 'async scrubbing'. Before this
+ async scrubbing completes, the unscrubbed VRAM cannot be used for allocation (thus DRM
+ memory allocators need to wait for this scrubbing to complete).
diff --git a/Documentation/gpu/nova/core/guidelines.rst b/Documentation/gpu/nova/core/guidelines.rst
new file mode 100644
index 000000000000..a389d65d7982
--- /dev/null
+++ b/Documentation/gpu/nova/core/guidelines.rst
@@ -0,0 +1,24 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==========
+Guidelines
+==========
+
+This documents contains the guidelines for nova-core. Additionally, all common
+guidelines of the Nova project do apply.
+
+Driver API
+==========
+
+One main purpose of nova-core is to implement the abstraction around the
+firmware interface of GSP and provide a firmware (version) independent API for
+2nd level drivers, such as nova-drm or the vGPU manager VFIO driver.
+
+Therefore, it is not permitted to leak firmware (version) specifics, through the
+driver API, to 2nd level drivers.
+
+Acceptance Criteria
+===================
+
+- To the extend possible, patches submitted to nova-core must be tested for
+ regressions with all 2nd level drivers.
diff --git a/Documentation/gpu/nova/core/todo.rst b/Documentation/gpu/nova/core/todo.rst
new file mode 100644
index 000000000000..35cc7c31d423
--- /dev/null
+++ b/Documentation/gpu/nova/core/todo.rst
@@ -0,0 +1,399 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=========
+Task List
+=========
+
+Tasks may have the following fields:
+
+- ``Complexity``: Describes the required familiarity with Rust and / or the
+ corresponding kernel APIs or subsystems. There are four different complexities,
+ ``Beginner``, ``Intermediate``, ``Advanced`` and ``Expert``.
+- ``Reference``: References to other tasks.
+- ``Link``: Links to external resources.
+- ``Contact``: The person that can be contacted for further information about
+ the task.
+
+A task might have `[ABCD]` code after its name. This code can be used to grep
+into the code for `TODO` entries related to it.
+
+Enablement (Rust)
+=================
+
+Tasks that are not directly related to nova-core, but are preconditions in terms
+of required APIs.
+
+FromPrimitive API [FPRI]
+------------------------
+
+Sometimes the need arises to convert a number to a value of an enum or a
+structure.
+
+A good example from nova-core would be the ``Chipset`` enum type, which defines
+the value ``AD102``. When probing the GPU the value ``0x192`` can be read from a
+certain register indication the chipset AD102. Hence, the enum value ``AD102``
+should be derived from the number ``0x192``. Currently, nova-core uses a custom
+implementation (``Chipset::from_u32`` for this.
+
+Instead, it would be desirable to have something like the ``FromPrimitive``
+trait [1] from the num crate.
+
+Having this generalization also helps with implementing a generic macro that
+automatically generates the corresponding mappings between a value and a number.
+
+| Complexity: Beginner
+| Link: https://docs.rs/num/latest/num/trait.FromPrimitive.html
+
+Generic register abstraction [REGA]
+-----------------------------------
+
+Work out how register constants and structures can be automatically generated
+through generalized macros.
+
+Example:
+
+.. code-block:: rust
+
+ register!(BOOT0, 0x0, u32, pci::Bar<SIZE>, Fields [
+ MINOR_REVISION(3:0, RO),
+ MAJOR_REVISION(7:4, RO),
+ REVISION(7:0, RO), // Virtual register combining major and minor rev.
+ ])
+
+This could expand to something like:
+
+.. code-block:: rust
+
+ const BOOT0_OFFSET: usize = 0x00000000;
+ const BOOT0_MINOR_REVISION_SHIFT: u8 = 0;
+ const BOOT0_MINOR_REVISION_MASK: u32 = 0x0000000f;
+ const BOOT0_MAJOR_REVISION_SHIFT: u8 = 4;
+ const BOOT0_MAJOR_REVISION_MASK: u32 = 0x000000f0;
+ const BOOT0_REVISION_SHIFT: u8 = BOOT0_MINOR_REVISION_SHIFT;
+ const BOOT0_REVISION_MASK: u32 = BOOT0_MINOR_REVISION_MASK | BOOT0_MAJOR_REVISION_MASK;
+
+ struct Boot0(u32);
+
+ impl Boot0 {
+ #[inline]
+ fn read(bar: &RevocableGuard<'_, pci::Bar<SIZE>>) -> Self {
+ Self(bar.readl(BOOT0_OFFSET))
+ }
+
+ #[inline]
+ fn minor_revision(&self) -> u32 {
+ (self.0 & BOOT0_MINOR_REVISION_MASK) >> BOOT0_MINOR_REVISION_SHIFT
+ }
+
+ #[inline]
+ fn major_revision(&self) -> u32 {
+ (self.0 & BOOT0_MAJOR_REVISION_MASK) >> BOOT0_MAJOR_REVISION_SHIFT
+ }
+
+ #[inline]
+ fn revision(&self) -> u32 {
+ (self.0 & BOOT0_REVISION_MASK) >> BOOT0_REVISION_SHIFT
+ }
+ }
+
+Usage:
+
+.. code-block:: rust
+
+ let bar = bar.try_access().ok_or(ENXIO)?;
+
+ let boot0 = Boot0::read(&bar);
+ pr_info!("Revision: {}\n", boot0.revision());
+
+A work-in-progress implementation currently resides in
+`drivers/gpu/nova-core/regs/macros.rs` and is used in nova-core. It would be
+nice to improve it (possibly using proc macros) and move it to the `kernel`
+crate so it can be used by other components as well.
+
+Features desired before this happens:
+
+* Make I/O optional I/O (for field values that are not registers),
+* Support other sizes than `u32`,
+* Allow visibility control for registers and individual fields,
+* Use Rust slice syntax to express fields ranges.
+
+| Complexity: Advanced
+| Contact: Alexandre Courbot
+
+Numerical operations [NUMM]
+---------------------------
+
+Nova uses integer operations that are not part of the standard library (or not
+implemented in an optimized way for the kernel). These include:
+
+- The "Find Last Set Bit" (`fls` function of the C part of the kernel)
+ operation.
+
+A `num` core kernel module is being designed to provide these operations.
+
+| Complexity: Intermediate
+| Contact: Alexandre Courbot
+
+IRQ abstractions
+----------------
+
+Rust abstractions for IRQ handling.
+
+There is active ongoing work from Daniel Almeida [1] for the "core" abstractions
+to request IRQs.
+
+Besides optional review and testing work, the required ``pci::Device`` code
+around those core abstractions needs to be worked out.
+
+| Complexity: Intermediate
+| Link: https://lore.kernel.org/lkml/20250122163932.46697-1-daniel.almeida@collabora.com/ [1]
+| Contact: Daniel Almeida
+
+Page abstraction for foreign pages
+----------------------------------
+
+Rust abstractions for pages not created by the Rust page abstraction without
+direct ownership.
+
+There is active onging work from Abdiel Janulgue [1] and Lina [2].
+
+| Complexity: Advanced
+| Link: https://lore.kernel.org/linux-mm/20241119112408.779243-1-abdiel.janulgue@gmail.com/ [1]
+| Link: https://lore.kernel.org/rust-for-linux/20250202-rust-page-v1-0-e3170d7fe55e@asahilina.net/ [2]
+
+Scatterlist / sg_table abstractions
+-----------------------------------
+
+Rust abstractions for scatterlist / sg_table.
+
+There is preceding work from Abdiel Janulgue, which hasn't made it to the
+mailing list yet.
+
+| Complexity: Intermediate
+| Contact: Abdiel Janulgue
+
+PCI MISC APIs
+-------------
+
+Extend the existing PCI device / driver abstractions by SR-IOV, config space,
+capability, MSI API abstractions.
+
+| Complexity: Beginner
+
+XArray bindings [XARR]
+----------------------
+
+We need bindings for `xa_alloc`/`xa_alloc_cyclic` in order to generate the
+auxiliary device IDs.
+
+| Complexity: Intermediate
+
+Debugfs abstractions
+--------------------
+
+Rust abstraction for debugfs APIs.
+
+| Reference: Export GSP log buffers
+| Complexity: Intermediate
+
+GPU (general)
+=============
+
+Initial Devinit support
+-----------------------
+
+Implement BIOS Device Initialization, i.e. memory sizing, waiting, PLL
+configuration.
+
+| Contact: Dave Airlie
+| Complexity: Beginner
+
+MMU / PT management
+-------------------
+
+Work out the architecture for MMU / page table management.
+
+We need to consider that nova-drm will need rather fine-grained control,
+especially in terms of locking, in order to be able to implement asynchronous
+Vulkan queues.
+
+While generally sharing the corresponding code is desirable, it needs to be
+evaluated how (and if at all) sharing the corresponding code is expedient.
+
+| Complexity: Expert
+
+VRAM memory allocator
+---------------------
+
+Investigate options for a VRAM memory allocator.
+
+Some possible options:
+ - Rust abstractions for
+ - RB tree (interval tree) / drm_mm
+ - maple_tree
+ - native Rust collections
+
+| Complexity: Advanced
+
+Instance Memory
+---------------
+
+Implement support for instmem (bar2) used to store page tables.
+
+| Complexity: Intermediate
+| Contact: Dave Airlie
+
+GPU System Processor (GSP)
+==========================
+
+Export GSP log buffers
+----------------------
+
+Recent patches from Timur Tabi [1] added support to expose GSP-RM log buffers
+(even after failure to probe the driver) through debugfs.
+
+This is also an interesting feature for nova-core, especially in the early days.
+
+| Link: https://lore.kernel.org/nouveau/20241030202952.694055-2-ttabi@nvidia.com/ [1]
+| Reference: Debugfs abstractions
+| Complexity: Intermediate
+
+GSP firmware abstraction
+------------------------
+
+The GSP-RM firmware API is unstable and may incompatibly change from version to
+version, in terms of data structures and semantics.
+
+This problem is one of the big motivations for using Rust for nova-core, since
+it turns out that Rust's procedural macro feature provides a rather elegant way
+to address this issue:
+
+1. generate Rust structures from the C headers in a separate namespace per version
+2. build abstraction structures (within a generic namespace) that implement the
+ firmware interfaces; annotate the differences in implementation with version
+ identifiers
+3. use a procedural macro to generate the actual per version implementation out
+ of this abstraction
+4. instantiate the correct version type one on runtime (can be sure that all
+ have the same interface because it's defined by a common trait)
+
+There is a PoC implementation of this pattern, in the context of the nova-core
+PoC driver.
+
+This task aims at refining the feature and ideally generalize it, to be usable
+by other drivers as well.
+
+| Complexity: Expert
+
+GSP message queue
+-----------------
+
+Implement low level GSP message queue (command, status) for communication
+between the kernel driver and GSP.
+
+| Complexity: Advanced
+| Contact: Dave Airlie
+
+Bootstrap GSP
+-------------
+
+Call the boot firmware to boot the GSP processor; execute initial control
+messages.
+
+| Complexity: Intermediate
+| Contact: Dave Airlie
+
+Client / Device APIs
+--------------------
+
+Implement the GSP message interface for client / device allocation and the
+corresponding client and device allocation APIs.
+
+| Complexity: Intermediate
+| Contact: Dave Airlie
+
+Bar PDE handling
+----------------
+
+Synchronize page table handling for BARs between the kernel driver and GSP.
+
+| Complexity: Beginner
+| Contact: Dave Airlie
+
+FIFO engine
+-----------
+
+Implement support for the FIFO engine, i.e. the corresponding GSP message
+interface and provide an API for chid allocation and channel handling.
+
+| Complexity: Advanced
+| Contact: Dave Airlie
+
+GR engine
+---------
+
+Implement support for the graphics engine, i.e. the corresponding GSP message
+interface and provide an API for (golden) context creation and promotion.
+
+| Complexity: Advanced
+| Contact: Dave Airlie
+
+CE engine
+---------
+
+Implement support for the copy engine, i.e. the corresponding GSP message
+interface.
+
+| Complexity: Intermediate
+| Contact: Dave Airlie
+
+VFN IRQ controller
+------------------
+
+Support for the VFN interrupt controller.
+
+| Complexity: Intermediate
+| Contact: Dave Airlie
+
+External APIs
+=============
+
+nova-core base API
+------------------
+
+Work out the common pieces of the API to connect 2nd level drivers, i.e. vGPU
+manager and nova-drm.
+
+| Complexity: Advanced
+
+vGPU manager API
+----------------
+
+Work out the API parts required by the vGPU manager, which are not covered by
+the base API.
+
+| Complexity: Advanced
+
+nova-core C API
+---------------
+
+Implement a C wrapper for the APIs required by the vGPU manager driver.
+
+| Complexity: Intermediate
+
+Testing
+=======
+
+CI pipeline
+-----------
+
+Investigate option for continuous integration testing.
+
+This can go from as simple as running KUnit tests over running (graphics) CTS to
+booting up (multiple) guest VMs to test VFIO use-cases.
+
+It might also be worth to consider the introduction of a new test suite directly
+sitting on top of the uAPI for more targeted testing and debugging. There may be
+options for collaboration / shared code with the Mesa project.
+
+| Complexity: Advanced
diff --git a/Documentation/gpu/nova/core/vbios.rst b/Documentation/gpu/nova/core/vbios.rst
new file mode 100644
index 000000000000..efd40087480c
--- /dev/null
+++ b/Documentation/gpu/nova/core/vbios.rst
@@ -0,0 +1,181 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==========
+VBIOS
+==========
+This document describes the layout of the VBIOS image which is a series of concatenated
+images in the ROM of the GPU. The VBIOS is mirrored onto the BAR 0 space and is read
+by both Boot ROM firmware (also known as IFR or init-from-rom firmware) on the GPU to
+bootstrap various microcontrollers (PMU, SEC, GSP) with critical initialization before
+the driver loads, as well as by the nova-core driver in the kernel to boot the GSP.
+
+The format of the images in the ROM follow the "BIOS Specification" part of the
+PCI specification, with Nvidia-specific extensions. The ROM images of type FwSec
+are the ones that contain Falcon ucode and what we are mainly looking for.
+
+As an example, the following are the different image types that can be found in the
+VBIOS of an Ampere GA102 GPU which is supported by the nova-core driver.
+
+- PciAt Image (Type 0x00) - This is the standard PCI BIOS image, whose name
+ likely comes from the "IBM PC/AT" architecture.
+
+- EFI Image (Type 0x03) - This is the EFI BIOS image. It contains the UEFI GOP
+ driver that is used to display UEFI graphics output.
+
+- First FwSec Image (Type 0xE0) - The first FwSec image (Secure Firmware)
+
+- Second FwSec Image (Type 0xE0) - The second FwSec image (Secure Firmware)
+ contains various microcodes (also known as an applications) that do a range
+ of different functions. The FWSEC ucode is run in heavy-secure mode and
+ typically runs directly on the GSP (it could be running on a different
+ designated processor in future generations but as of Ampere, it is the GSP).
+ This firmware then loads other firmware ucodes onto the PMU and SEC2
+ microcontrollers for gfw initialization after GPU reset and before the driver
+ loads (see devinit.rst). The DEVINIT ucode is itself another ucode that is
+ stored in this ROM partition.
+
+Once located, the Falcon ucodes have "Application Interfaces" in their data
+memory (DMEM). For FWSEC, the application interface we use for FWSEC is the
+"DMEM mapper" interface which is configured to run the "FRTS" command. This
+command carves out the WPR2 (Write-Protected Region) in VRAM. It then places
+important power-management data, called 'FRTS', into this region. The WPR2
+region is only accessible to heavy-secure ucode.
+
+.. note::
+ It is not clear why FwSec has 2 different partitions in the ROM, but they both
+ are of type 0xE0 and can be identified as such. This could be subject to change
+ in future generations.
+
+VBIOS ROM Layout
+----------------
+The VBIOS layout is roughly a series of concatenated images laid out as follows::
+
+ +----------------------------------------------------------------------------+
+ | VBIOS (Starting at ROM_OFFSET: 0x300000) |
+ +----------------------------------------------------------------------------+
+ | +-----------------------------------------------+ |
+ | | PciAt Image (Type 0x00) | |
+ | +-----------------------------------------------+ |
+ | | +-------------------+ | |
+ | | | ROM Header | | |
+ | | | (Signature 0xAA55)| | |
+ | | +-------------------+ | |
+ | | | rom header's pci_data_struct_offset | |
+ | | | points to the PCIR structure | |
+ | | V | |
+ | | +-------------------+ | |
+ | | | PCIR Structure | | |
+ | | | (Signature "PCIR")| | |
+ | | | last_image: 0x80 | | |
+ | | | image_len: size | | |
+ | | | in 512-byte units | | |
+ | | +-------------------+ | |
+ | | | | |
+ | | | NPDE immediately follows PCIR | |
+ | | V | |
+ | | +-------------------+ | |
+ | | | NPDE Structure | | |
+ | | | (Signature "NPDE")| | |
+ | | | last_image: 0x00 | | |
+ | | +-------------------+ | |
+ | | | |
+ | | +-------------------+ | |
+ | | | BIT Header | (Signature scanning | |
+ | | | (Signature "BIT") | provides the location | |
+ | | +-------------------+ of the BIT table) | |
+ | | | header is | |
+ | | | followed by a table of tokens | |
+ | | V one of which is for falcon data. | |
+ | | +-------------------+ | |
+ | | | BIT Tokens | | |
+ | | | ______________ | | |
+ | | | | Falcon Data | | | |
+ | | | | Token (0x70)|---+------------>------------+--+ |
+ | | | +-------------+ | falcon_data_ptr() | | |
+ | | +-------------------+ | V |
+ | +-----------------------------------------------+ | |
+ | (no gap between images) | |
+ | +-----------------------------------------------+ | |
+ | | EFI Image (Type 0x03) | | |
+ | +-----------------------------------------------+ | |
+ | | Contains the UEFI GOP driver (Graphics Output)| | |
+ | | +-------------------+ | | |
+ | | | ROM Header | | | |
+ | | +-------------------+ | | |
+ | | | PCIR Structure | | | |
+ | | +-------------------+ | | |
+ | | | NPDE Structure | | | |
+ | | +-------------------+ | | |
+ | | | Image data | | | |
+ | | +-------------------+ | | |
+ | +-----------------------------------------------+ | |
+ | (no gap between images) | |
+ | +-----------------------------------------------+ | |
+ | | First FwSec Image (Type 0xE0) | | |
+ | +-----------------------------------------------+ | |
+ | | +-------------------+ | | |
+ | | | ROM Header | | | |
+ | | +-------------------+ | | |
+ | | | PCIR Structure | | | |
+ | | +-------------------+ | | |
+ | | | NPDE Structure | | | |
+ | | +-------------------+ | | |
+ | | | Image data | | | |
+ | | +-------------------+ | | |
+ | +-----------------------------------------------+ | |
+ | (no gap between images) | |
+ | +-----------------------------------------------+ | |
+ | | Second FwSec Image (Type 0xE0) | | |
+ | +-----------------------------------------------+ | |
+ | | +-------------------+ | | |
+ | | | ROM Header | | | |
+ | | +-------------------+ | | |
+ | | | PCIR Structure | | | |
+ | | +-------------------+ | | |
+ | | | NPDE Structure | | | |
+ | | +-------------------+ | | |
+ | | | | |
+ | | +-------------------+ | | |
+ | | | PMU Lookup Table | <- falcon_data_offset <----+ |
+ | | | +-------------+ | pmu_lookup_table | |
+ | | | | Entry 0x85 | | | |
+ | | | | FWSEC_PROD | | | |
+ | | | +-------------+ | | |
+ | | +-------------------+ | |
+ | | | | |
+ | | | points to | |
+ | | V | |
+ | | +-------------------+ | |
+ | | | FalconUCodeDescV3 | <- falcon_ucode_offset | |
+ | | | (FWSEC Firmware) | fwsec_header() | |
+ | | +-------------------+ | |
+ | | | immediately followed by... | |
+ | | V | |
+ | | +----------------------------+ | |
+ | | | Signatures + FWSEC Ucode | | |
+ | | | fwsec_sigs(), fwsec_ucode()| | |
+ | | +----------------------------+ | |
+ | +-----------------------------------------------+ |
+ | |
+ +----------------------------------------------------------------------------+
+
+.. note::
+ This diagram is created based on an GA-102 Ampere GPU as an example and could
+ vary for future or other GPUs.
+
+.. note::
+ For more explanations of acronyms, see the detailed descriptions in `vbios.rs`.
+
+Falcon data Lookup
+------------------
+A key part of the VBIOS extraction code (vbios.rs) is to find the location of the
+Falcon data in the VBIOS which contains the PMU lookup table. This lookup table is
+used to find the required Falcon ucode based on an application ID.
+
+The location of the PMU lookup table is found by scanning the BIT (`BIOS Information Table`_)
+tokens for a token with the id `BIT_TOKEN_ID_FALCON_DATA` (0x70) which indicates the
+offset of the same from the start of the VBIOS image. Unfortunately, the offset
+does not account for the EFI image located between the PciAt and FwSec images.
+The `vbios.rs` code compensates for this with appropriate arithmetic.
+
+.. _`BIOS Information Table`: https://download.nvidia.com/open-gpu-doc/BIOS-Information-Table/1/BIOS-Information-Table.html
diff --git a/Documentation/gpu/nova/guidelines.rst b/Documentation/gpu/nova/guidelines.rst
new file mode 100644
index 000000000000..13ab13984a18
--- /dev/null
+++ b/Documentation/gpu/nova/guidelines.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==========
+Guidelines
+==========
+
+This document describes the general project guidelines that apply to nova-core
+and nova-drm.
+
+Language
+========
+
+The Nova project uses the Rust programming language. In this context, all rules
+of the Rust for Linux project as documented in
+:doc:`../../rust/general-information` apply. Additionally, the following rules
+apply.
+
+- Unless technically necessary otherwise (e.g. uAPI), any driver code is written
+ in Rust.
+
+- Unless technically necessary, unsafe Rust code must be avoided. In case of
+ technical necessity, unsafe code should be isolated in a separate component
+ providing a safe API for other driver code to use.
+
+Style
+-----
+
+All rules of the Rust for Linux project as documented in
+:doc:`../../rust/coding-guidelines` apply.
+
+For a submit checklist, please also see the `Rust for Linux Submit checklist
+addendum <https://rust-for-linux.com/contributing#submit-checklist-addendum>`_.
+
+Documentation
+=============
+
+The availability of proper documentation is essential in terms of scalability,
+accessibility for new contributors and maintainability of a project in general,
+but especially for a driver running as complex hardware as Nova is targeting.
+
+Hence, adding documentation of any kind is very much encouraged by the project.
+
+Besides that, there are some minimum requirements.
+
+- Every non-private structure needs at least a brief doc comment explaining the
+ semantical sense of the structure, as well as potential locking and lifetime
+ requirements. It is encouraged to have the same minimum documentation for
+ non-trivial private structures.
+
+- uAPIs must be fully documented with kernel-doc comments; additionally, the
+ semantical behavior must be explained including potential special or corner
+ cases.
+
+- The APIs connecting the 1st level driver (nova-core) with 2nd level drivers
+ must be fully documented. This includes doc comments, potential locking and
+ lifetime requirements, as well as example code if applicable.
+
+- Abbreviations must be explained when introduced; terminology must be uniquely
+ defined.
+
+- Register addresses, layouts, shift values and masks must be defined properly;
+ unless obvious, the semantical sense must be documented. This only applies if
+ the author is able to obtain the corresponding information.
+
+Acceptance Criteria
+===================
+
+- Patches must only be applied if reviewed by at least one other person on the
+ mailing list; this also applies for maintainers.
diff --git a/Documentation/gpu/nova/index.rst b/Documentation/gpu/nova/index.rst
new file mode 100644
index 000000000000..e39cb3163581
--- /dev/null
+++ b/Documentation/gpu/nova/index.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=======================
+nova NVIDIA GPU drivers
+=======================
+
+The nova driver project consists out of two separate drivers nova-core and
+nova-drm and intends to supersede the nouveau driver for NVIDIA GPUs based on
+the GPU System Processor (GSP).
+
+The following documents apply to both nova-core and nova-drm.
+
+.. toctree::
+ :titlesonly:
+
+ guidelines
+
+nova-core
+=========
+
+The nova-core driver is the core driver for NVIDIA GPUs based on GSP. nova-core,
+as the 1st level driver, provides an abstraction around the GPUs hard- and
+firmware interfaces providing a common base for 2nd level drivers, such as the
+vGPU manager VFIO driver and the nova-drm driver.
+
+.. toctree::
+ :titlesonly:
+
+ core/guidelines
+ core/todo
+ core/vbios
+ core/devinit
+ core/fwsec
+ core/falcon
diff --git a/Documentation/gpu/panfrost.rst b/Documentation/gpu/panfrost.rst
new file mode 100644
index 000000000000..51ba375fd80d
--- /dev/null
+++ b/Documentation/gpu/panfrost.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+=========================
+ drm/Panfrost Mali Driver
+=========================
+
+.. _panfrost-usage-stats:
+
+Panfrost DRM client usage stats implementation
+==============================================
+
+The drm/Panfrost 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: 27
+ ino: 531
+ drm-driver: panfrost
+ drm-client-id: 14
+ drm-engine-fragment: 1846584880 ns
+ drm-cycles-fragment: 1424359409
+ drm-maxfreq-fragment: 799999987 Hz
+ drm-curfreq-fragment: 799999987 Hz
+ drm-engine-vertex-tiler: 71932239 ns
+ drm-cycles-vertex-tiler: 52617357
+ drm-maxfreq-vertex-tiler: 799999987 Hz
+ drm-curfreq-vertex-tiler: 799999987 Hz
+ drm-total-memory: 290 MiB
+ drm-shared-memory: 0 MiB
+ drm-active-memory: 226 MiB
+ drm-resident-memory: 36496 KiB
+ drm-purgeable-memory: 128 KiB
+
+Possible `drm-engine-` key names are: `fragment`, and `vertex-tiler`.
+`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/panfrost/[a-f0-9]*.gpu/profiling
+
+Where `N` is either `0` or `1`, depending on the desired enablement status.
diff --git a/Documentation/gpu/panthor.rst b/Documentation/gpu/panthor.rst
new file mode 100644
index 000000000000..7a841741278f
--- /dev/null
+++ b/Documentation/gpu/panthor.rst
@@ -0,0 +1,56 @@
+.. 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
+ panthor-resident-memory: 10396 KiB
+ panthor-active-memory: 10396 KiB
+ 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.
+
+Possible `panthor-*-memory` keys are: `active` and `resident`.
+These values convey the sizes of the internal driver-owned shmem BO's that
+aren't exposed to user-space through a DRM handle, like queue ring buffers,
+sync object arrays and heap chunks. Because they are all allocated and pinned
+at creation time, only `panthor-resident-memory` is necessary to tell us their
+size. `panthor-active-memory` shows the size of kernel BO's associated with
+VM's and groups currently being scheduled for execution by the GPU.
diff --git a/Documentation/gpu/rfc/color_pipeline.rst b/Documentation/gpu/rfc/color_pipeline.rst
new file mode 100644
index 000000000000..cd1cc2d0f988
--- /dev/null
+++ b/Documentation/gpu/rfc/color_pipeline.rst
@@ -0,0 +1,378 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+Linux Color Pipeline API
+========================
+
+What problem are we solving?
+============================
+
+We would like to support pre-, and post-blending complex color
+transformations in display controller hardware in order to allow for
+HW-supported HDR use-cases, as well as to provide support to
+color-managed applications, such as video or image editors.
+
+It is possible to support an HDR output on HW supporting the Colorspace
+and HDR Metadata drm_connector properties, but that requires the
+compositor or application to render and compose the content into one
+final buffer intended for display. Doing so is costly.
+
+Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other
+operations to support color transformations. These operations are often
+implemented in fixed-function HW and therefore much more power efficient than
+performing similar operations via shaders or CPU.
+
+We would like to make use of this HW functionality to support complex color
+transformations with no, or minimal CPU or shader load. The switch between HW
+fixed-function blocks and shaders/CPU must be seamless with no visible
+difference when fallback to shaders/CPU is neceesary at any time.
+
+
+How are other OSes solving this problem?
+========================================
+
+The most widely supported use-cases regard HDR content, whether video or
+gaming.
+
+Most OSes will specify the source content format (color gamut, encoding transfer
+function, and other metadata, such as max and average light levels) to a driver.
+Drivers will then program their fixed-function HW accordingly to map from a
+source content buffer's space to a display's space.
+
+When fixed-function HW is not available the compositor will assemble a shader to
+ask the GPU to perform the transformation from the source content format to the
+display's format.
+
+A compositor's mapping function and a driver's mapping function are usually
+entirely separate concepts. On OSes where a HW vendor has no insight into
+closed-source compositor code such a vendor will tune their color management
+code to visually match the compositor's. On other OSes, where both mapping
+functions are open to an implementer they will ensure both mappings match.
+
+This results in mapping algorithm lock-in, meaning that no-one alone can
+experiment with or introduce new mapping algorithms and achieve
+consistent results regardless of which implementation path is taken.
+
+Why is Linux different?
+=======================
+
+Unlike other OSes, where there is one compositor for one or more drivers, on
+Linux we have a many-to-many relationship. Many compositors; many drivers.
+In addition each compositor vendor or community has their own view of how
+color management should be done. This is what makes Linux so beautiful.
+
+This means that a HW vendor can now no longer tune their driver to one
+compositor, as tuning it to one could make it look fairly different from
+another compositor's color mapping.
+
+We need a better solution.
+
+
+Descriptive API
+===============
+
+An API that describes the source and destination colorspaces is a descriptive
+API. It describes the input and output color spaces but does not describe
+how precisely they should be mapped. Such a mapping includes many minute
+design decision that can greatly affect the look of the final result.
+
+It is not feasible to describe such mapping with enough detail to ensure the
+same result from each implementation. In fact, these mappings are a very active
+research area.
+
+
+Prescriptive API
+================
+
+A prescriptive API describes not the source and destination colorspaces. It
+instead prescribes a recipe for how to manipulate pixel values to arrive at the
+desired outcome.
+
+This recipe is generally an ordered list of straight-forward operations,
+with clear mathematical definitions, such as 1D LUTs, 3D LUTs, matrices,
+or other operations that can be described in a precise manner.
+
+
+The Color Pipeline API
+======================
+
+HW color management pipelines can significantly differ between HW
+vendors in terms of availability, ordering, and capabilities of HW
+blocks. This makes a common definition of color management blocks and
+their ordering nigh impossible. Instead we are defining an API that
+allows user space to discover the HW capabilities in a generic manner,
+agnostic of specific drivers and hardware.
+
+
+drm_colorop Object
+==================
+
+To support the definition of color pipelines we define the DRM core
+object type drm_colorop. Individual drm_colorop objects will be chained
+via the NEXT property of a drm_colorop to constitute a color pipeline.
+Each drm_colorop object is unique, i.e., even if multiple color
+pipelines have the same operation they won't share the same drm_colorop
+object to describe that operation.
+
+Note that drivers are not expected to map drm_colorop objects statically
+to specific HW blocks. The mapping of drm_colorop objects is entirely a
+driver-internal detail and can be as dynamic or static as a driver needs
+it to be. See more in the Driver Implementation Guide section below.
+
+Each drm_colorop has three core properties:
+
+TYPE: An enumeration property, defining the type of transformation, such as
+* enumerated curve
+* custom (uniform) 1D LUT
+* 3x3 matrix
+* 3x4 matrix
+* 3D LUT
+* etc.
+
+Depending on the type of transformation other properties will describe
+more details.
+
+BYPASS: A boolean property that can be used to easily put a block into
+bypass mode. The BYPASS property is not mandatory for a colorop, as long
+as the entire pipeline can get bypassed by setting the COLOR_PIPELINE on
+a plane to '0'.
+
+NEXT: The ID of the next drm_colorop in a color pipeline, or 0 if this
+drm_colorop is the last in the chain.
+
+An example of a drm_colorop object might look like one of these::
+
+ /* 1D enumerated curve */
+ Color operation 42
+ ├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve
+ ├─ "BYPASS": bool {true, false}
+ ├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ EOTF, PQ inverse EOTF, …}
+ └─ "NEXT": immutable color operation ID = 43
+
+ /* custom 4k entry 1D LUT */
+ Color operation 52
+ ├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 1D LUT
+ ├─ "BYPASS": bool {true, false}
+ ├─ "SIZE": immutable range = 4096
+ ├─ "DATA": blob
+ └─ "NEXT": immutable color operation ID = 0
+
+ /* 17^3 3D LUT */
+ Color operation 72
+ ├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 3D LUT
+ ├─ "BYPASS": bool {true, false}
+ ├─ "SIZE": immutable range = 17
+ ├─ "DATA": blob
+ └─ "NEXT": immutable color operation ID = 73
+
+drm_colorop extensibility
+-------------------------
+
+Unlike existing DRM core objects, like &drm_plane, drm_colorop is not
+extensible. This simplifies implementations and keeps all functionality
+for managing &drm_colorop objects in the DRM core.
+
+If there is a need one may introduce a simple &drm_colorop_funcs
+function table in the future, for example to support an IN_FORMATS
+property on a &drm_colorop.
+
+If a driver requires the ability to create a driver-specific colorop
+object they will need to add &drm_colorop func table support with
+support for the usual functions, like destroy, atomic_duplicate_state,
+and atomic_destroy_state.
+
+
+COLOR_PIPELINE Plane Property
+=============================
+
+Color Pipelines are created by a driver and advertised via a new
+COLOR_PIPELINE enum property on each plane. Values of the property
+always include object id 0, which is the default and means all color
+processing is disabled. Additional values will be the object IDs of the
+first drm_colorop in a pipeline. A driver can create and advertise none,
+one, or more possible color pipelines. A DRM client will select a color
+pipeline by setting the COLOR PIPELINE to the respective value.
+
+NOTE: Many DRM clients will set enumeration properties via the string
+value, often hard-coding it. Since this enumeration is generated based
+on the colorop object IDs it is important to perform the Color Pipeline
+Discovery, described below, instead of hard-coding color pipeline
+assignment. Drivers might generate the enum strings dynamically.
+Hard-coded strings might only work for specific drivers on a specific
+pieces of HW. Color Pipeline Discovery can work universally, as long as
+drivers implement the required color operations.
+
+The COLOR_PIPELINE property is only exposed when the
+DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set. Drivers shall ignore any
+existing pre-blend color operations when this cap is set, such as
+COLOR_RANGE and COLOR_ENCODING. If drivers want to support COLOR_RANGE
+or COLOR_ENCODING functionality when the color pipeline client cap is
+set, they are expected to expose colorops in the pipeline to allow for
+the appropriate color transformation.
+
+Setting of the COLOR_PIPELINE plane property or drm_colorop properties
+is only allowed for userspace that sets this client cap.
+
+An example of a COLOR_PIPELINE property on a plane might look like this::
+
+ Plane 10
+ ├─ "TYPE": immutable enum {Overlay, Primary, Cursor} = Primary
+ ├─ …
+ └─ "COLOR_PIPELINE": enum {0, 42, 52} = 0
+
+
+Color Pipeline Discovery
+========================
+
+A DRM client wanting color management on a drm_plane will:
+
+1. Get the COLOR_PIPELINE property of the plane
+2. iterate all COLOR_PIPELINE enum values
+3. for each enum value walk the color pipeline (via the NEXT pointers)
+ and see if the available color operations are suitable for the
+ desired color management operations
+
+If userspace encounters an unknown or unsuitable color operation during
+discovery it does not need to reject the entire color pipeline outright,
+as long as the unknown or unsuitable colorop has a "BYPASS" property.
+Drivers will ensure that a bypassed block does not have any effect.
+
+An example of chained properties to define an AMD pre-blending color
+pipeline might look like this::
+
+ Plane 10
+ ├─ "TYPE" (immutable) = Primary
+ └─ "COLOR_PIPELINE": enum {0, 44} = 0
+
+ Color operation 44
+ ├─ "TYPE" (immutable) = 1D enumerated curve
+ ├─ "BYPASS": bool
+ ├─ "CURVE_1D_TYPE": enum {sRGB EOTF, PQ EOTF} = sRGB EOTF
+ └─ "NEXT" (immutable) = 45
+
+ Color operation 45
+ ├─ "TYPE" (immutable) = 3x4 Matrix
+ ├─ "BYPASS": bool
+ ├─ "DATA": blob
+ └─ "NEXT" (immutable) = 46
+
+ Color operation 46
+ ├─ "TYPE" (immutable) = 1D enumerated curve
+ ├─ "BYPASS": bool
+ ├─ "CURVE_1D_TYPE": enum {sRGB Inverse EOTF, PQ Inverse EOTF} = sRGB EOTF
+ └─ "NEXT" (immutable) = 47
+
+ Color operation 47
+ ├─ "TYPE" (immutable) = 1D LUT
+ ├─ "SIZE": immutable range = 4096
+ ├─ "DATA": blob
+ └─ "NEXT" (immutable) = 48
+
+ Color operation 48
+ ├─ "TYPE" (immutable) = 3D LUT
+ ├─ "DATA": blob
+ └─ "NEXT" (immutable) = 49
+
+ Color operation 49
+ ├─ "TYPE" (immutable) = 1D enumerated curve
+ ├─ "BYPASS": bool
+ ├─ "CURVE_1D_TYPE": enum {sRGB EOTF, PQ EOTF} = sRGB EOTF
+ └─ "NEXT" (immutable) = 0
+
+
+Color Pipeline Programming
+==========================
+
+Once a DRM client has found a suitable pipeline it will:
+
+1. Set the COLOR_PIPELINE enum value to the one pointing at the first
+ drm_colorop object of the desired pipeline
+2. Set the properties for all drm_colorop objects in the pipeline to the
+ desired values, setting BYPASS to true for unused drm_colorop blocks,
+ and false for enabled drm_colorop blocks
+3. Perform (TEST_ONLY or not) atomic commit with all the other KMS
+ states it wishes to change
+
+To configure the pipeline for an HDR10 PQ plane and blending in linear
+space, a compositor might perform an atomic commit with the following
+property values::
+
+ Plane 10
+ └─ "COLOR_PIPELINE" = 42
+
+ Color operation 42
+ └─ "BYPASS" = true
+
+ Color operation 44
+ └─ "BYPASS" = true
+
+ Color operation 45
+ └─ "BYPASS" = true
+
+ Color operation 46
+ └─ "BYPASS" = true
+
+ Color operation 47
+ ├─ "DATA" = Gamut mapping + tone mapping + night mode
+ └─ "BYPASS" = false
+
+ Color operation 48
+ ├─ "CURVE_1D_TYPE" = PQ EOTF
+ └─ "BYPASS" = false
+
+
+Driver Implementer's Guide
+==========================
+
+What does this all mean for driver implementations? As noted above the
+colorops can map to HW directly but don't need to do so. Here are some
+suggestions on how to think about creating your color pipelines:
+
+- Try to expose pipelines that use already defined colorops, even if
+ your hardware pipeline is split differently. This allows existing
+ userspace to immediately take advantage of the hardware.
+
+- Additionally, try to expose your actual hardware blocks as colorops.
+ Define new colorop types where you believe it can offer significant
+ benefits if userspace learns to program them.
+
+- Avoid defining new colorops for compound operations with very narrow
+ scope. If you have a hardware block for a special operation that
+ cannot be split further, you can expose that as a new colorop type.
+ However, try to not define colorops for "use cases", especially if
+ they require you to combine multiple hardware blocks.
+
+- Design new colorops as prescriptive, not descriptive; by the
+ mathematical formula, not by the assumed input and output.
+
+A defined colorop type must be deterministic. The exact behavior of the
+colorop must be documented entirely, whether via a mathematical formula
+or some other description. Its operation can depend only on its
+properties and input and nothing else, allowed error tolerance
+notwithstanding.
+
+
+Driver Forward/Backward Compatibility
+=====================================
+
+As this is uAPI drivers can't regress color pipelines that have been
+introduced for a given HW generation. New HW generations are free to
+abandon color pipelines advertised for previous generations.
+Nevertheless, it can be beneficial to carry support for existing color
+pipelines forward as those will likely already have support in DRM
+clients.
+
+Introducing new colorops to a pipeline is fine, as long as they can be
+bypassed or are purely informational. DRM clients implementing support
+for the pipeline can always skip unknown properties as long as they can
+be confident that doing so will not cause unexpected results.
+
+If a new colorop doesn't fall into one of the above categories
+(bypassable or informational) the modified pipeline would be unusable
+for user space. In this case a new pipeline should be defined.
+
+
+References
+==========
+
+1. https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/ \ No newline at end of file
diff --git a/Documentation/gpu/rfc/gpusvm.rst b/Documentation/gpu/rfc/gpusvm.rst
new file mode 100644
index 000000000000..469db1372f16
--- /dev/null
+++ b/Documentation/gpu/rfc/gpusvm.rst
@@ -0,0 +1,118 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===============
+GPU SVM Section
+===============
+
+Agreed upon design principles
+=============================
+
+* migrate_to_ram path
+ * Rely only on core MM concepts (migration PTEs, page references, and
+ page locking).
+ * No driver specific locks other than locks for hardware interaction in
+ this path. These are not required and generally a bad idea to
+ invent driver defined locks to seal core MM races.
+ * An example of a driver-specific lock causing issues occurred before
+ fixing do_swap_page to lock the faulting page. A driver-exclusive lock
+ in migrate_to_ram produced a stable livelock if enough threads read
+ the faulting page.
+ * Partial migration is supported (i.e., a subset of pages attempting to
+ migrate can actually migrate, with only the faulting page guaranteed
+ to migrate).
+ * Driver handles mixed migrations via retry loops rather than locking.
+* Eviction
+ * Eviction is defined as migrating data from the GPU back to the
+ CPU without a virtual address to free up GPU memory.
+ * Only looking at physical memory data structures and locks as opposed to
+ looking at virtual memory data structures and locks.
+ * No looking at mm/vma structs or relying on those being locked.
+ * The rationale for the above two points is that CPU virtual addresses
+ can change at any moment, while the physical pages remain stable.
+ * GPU page table invalidation, which requires a GPU virtual address, is
+ handled via the notifier that has access to the GPU virtual address.
+* GPU fault side
+ * mmap_read only used around core MM functions which require this lock
+ and should strive to take mmap_read lock only in GPU SVM layer.
+ * Big retry loop to handle all races with the mmu notifier under the gpu
+ pagetable locks/mmu notifier range lock/whatever we end up calling
+ those.
+ * Races (especially against concurrent eviction or migrate_to_ram)
+ should not be handled on the fault side by trying to hold locks;
+ rather, they should be handled using retry loops. One possible
+ exception is holding a BO's dma-resv lock during the initial migration
+ to VRAM, as this is a well-defined lock that can be taken underneath
+ the mmap_read lock.
+ * One possible issue with the above approach is if a driver has a strict
+ migration policy requiring GPU access to occur in GPU memory.
+ Concurrent CPU access could cause a livelock due to endless retries.
+ While no current user (Xe) of GPU SVM has such a policy, it is likely
+ to be added in the future. Ideally, this should be resolved on the
+ core-MM side rather than through a driver-side lock.
+* Physical memory to virtual backpointer
+ * This does not work, as no pointers from physical memory to virtual
+ memory should exist. mremap() is an example of the core MM updating
+ the virtual address without notifying the driver of address
+ change rather the driver only receiving the invalidation notifier.
+ * The physical memory backpointer (page->zone_device_data) should remain
+ stable from allocation to page free. Safely updating this against a
+ concurrent user would be very difficult unless the page is free.
+* GPU pagetable locking
+ * Notifier lock only protects range tree, pages valid state for a range
+ (rather than seqno due to wider notifiers), pagetable entries, and
+ mmu notifier seqno tracking, it is not a global lock to protect
+ against races.
+ * All races handled with big retry as mentioned above.
+
+Overview of baseline design
+===========================
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
+ :doc: Overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
+ :doc: Locking
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
+ :doc: Partial Unmapping of Ranges
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c
+ :doc: Examples
+
+Overview of drm_pagemap design
+==============================
+
+.. kernel-doc:: drivers/gpu/drm/drm_pagemap.c
+ :doc: Overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_pagemap.c
+ :doc: Migration
+
+Possible future design features
+===============================
+
+* Concurrent GPU faults
+ * CPU faults are concurrent so makes sense to have concurrent GPU
+ faults.
+ * Should be possible with fined grained locking in the driver GPU
+ fault handler.
+ * No expected GPU SVM changes required.
+* Ranges with mixed system and device pages
+ * Can be added if required to drm_gpusvm_get_pages fairly easily.
+* Multi-GPU support
+ * Work in progress and patches expected after initially landing on GPU
+ SVM.
+ * Ideally can be done with little to no changes to GPU SVM.
+* Drop ranges in favor of radix tree
+ * May be desirable for faster notifiers.
+* Compound device pages
+ * Nvidia, AMD, and Intel all have agreed expensive core MM functions in
+ migrate device layer are a performance bottleneck, having compound
+ device pages should help increase performance by reducing the number
+ of these expensive calls.
+* Higher order dma mapping for migration
+ * 4k dma mapping adversely affects migration performance on Intel
+ hardware, higher order (2M) dma mapping should help here.
+* Build common userptr implementation on top of GPU SVM
+* Driver side madvise implementation and migration policies
+* Pull in pending dma-mapping API changes from Leon / Nvidia when these land
diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst
index d630f15ab795..2974525f0ac5 100644
--- a/Documentation/gpu/rfc/i915_scheduler.rst
+++ b/Documentation/gpu/rfc/i915_scheduler.rst
@@ -26,7 +26,7 @@ i915 with the DRM scheduler is:
which configures a slot with N contexts
* After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to
a slot in a single execbuf IOCTL and the batches run on the GPU in
- paralllel
+ parallel
* Initially only for GuC submission but execlists can be supported if
needed
* Convert the i915 to use the DRM scheduler
@@ -37,7 +37,7 @@ i915 with the DRM scheduler is:
* Watchdog hooks into DRM scheduler
* Lots of complexity of the GuC backend can be pulled out once
integrated with DRM scheduler (e.g. state machine gets
- simplier, locking gets simplier, etc...)
+ simpler, locking gets simpler, etc...)
* Execlists backend will minimum required to hook in the DRM scheduler
* Legacy interface
* Features like timeslicing / preemption / virtual engines would
@@ -135,9 +135,13 @@ Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
drm_i915_context_engines_parallel_submit to the uAPI to implement this
extension.
+.. c:namespace-push:: rfc
+
.. kernel-doc:: include/uapi/drm/i915_drm.h
:functions: i915_context_engines_parallel_submit
+.. c:namespace-pop::
+
Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
-------------------------------------------------------------------
Contexts that have been configured with the 'set_parallel' extension can only
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h
index 8a8fcd4fceac..bc26dc126104 100644
--- a/Documentation/gpu/rfc/i915_vm_bind.h
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence {
* Multiple VA mappings can be created to the same section of the object
* (aliasing).
*
- * The @start, @offset and @length must be 4K page aligned. However the DG2
- * and XEHPSDV has 64K page size for device local memory and has compact page
- * table. On those platforms, for binding device local-memory objects, the
- * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix
- * the local memory 64K page and the system memory 4K page bindings in the same
- * 2M range.
+ * The @start, @offset and @length must be 4K page aligned. However the DG2 has
+ * 64K page size for device local memory and has compact page table. On that
+ * platform, for binding device local-memory objects, the @start, @offset and
+ * @length must be 64K aligned. Also, UMDs should not mix the local memory 64K
+ * page and the system memory 4K page bindings in the same 2M range.
*
* Error code -EINVAL will be returned if @start, @offset and @length are not
* properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code
diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst
index 9a1dcdf2799e..0b3b525ac620 100644
--- a/Documentation/gpu/rfc/i915_vm_bind.rst
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -90,7 +90,7 @@ submission, they need only one dma-resv fence list updated. Thus, the fast
path (where required mappings are already bound) submission latency is O(1)
w.r.t the number of VM private BOs.
-VM_BIND locking hirarchy
+VM_BIND locking hierarchy
-------------------------
The locking design here supports the older (execlist based) execbuf mode, the
newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 476719771eef..ef19b0ba2a3e 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -18,6 +18,10 @@ host such documentation:
.. toctree::
+ gpusvm.rst
+
+.. toctree::
+
i915_gem_lmem.rst
.. toctree::
@@ -31,3 +35,6 @@ host such documentation:
.. toctree::
i915_vm_bind.rst
+
+.. toctree::
+ color_pipeline.rst \ No newline at end of file
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 393d218e4a0c..9013ced318cb 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -37,7 +37,7 @@ Audit each individual driver, make sure it'll work with the generic
implementation (there's lots of outdated locking leftovers in various
implementations), and then remove it.
-Contact: Daniel Vetter, respective driver maintainers
+Contact: Simona Vetter, respective driver maintainers
Level: Intermediate
@@ -49,15 +49,19 @@ converted over. Modern compositors like Wayland or Surfaceflinger on Android
really want an atomic modeset interface, so this is all about the bright
future.
-There is a conversion guide for atomic and all you need is a GPU for a
-non-converted driver (again virtual HW drivers for KVM are still all
-suitable).
+There is a conversion guide for atomic [1]_ and all you need is a GPU for a
+non-converted driver. The "Atomic mode setting design overview" series [2]_
+[3]_ at LWN.net can also be helpful.
As part of this drivers also need to convert to universal plane (which means
exposing primary & cursor as proper plane objects). But that's much easier to
do by directly using the new atomic helper driver callbacks.
-Contact: Daniel Vetter, respective driver maintainers
+ .. [1] https://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
+ .. [2] https://lwn.net/Articles/653071/
+ .. [3] https://lwn.net/Articles/653466/
+
+Contact: Simona Vetter, respective driver maintainers
Level: Advanced
@@ -65,13 +69,13 @@ Clean up the clipped coordination confusion around planes
---------------------------------------------------------
We have a helper to get this right with drm_plane_helper_check_update(), but
-it's not consistently used. This should be fixed, preferrably in the atomic
+it's not consistently used. This should be fixed, preferably in the atomic
helpers (and drivers then moved over to clipped coordinates). Probably the
helper should also be moved from drm_plane_helper.c to the atomic helpers, to
avoid confusion - the other helpers in that file are all deprecated legacy
helpers.
-Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
+Contact: Ville Syrjälä, Simona Vetter, driver maintainers
Level: Advanced
@@ -93,7 +97,7 @@ with the current helpers:
- Then we could go through all the drivers and remove the more-or-less confused
checks for plane_state->fb and plane_state->crtc.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Advanced
@@ -112,7 +116,30 @@ Somewhat related is the legacy_cursor_update hack, which should be replaced with
the new atomic_async_check/commit functionality in the helpers in drivers that
still look at that flag.
-Contact: Daniel Vetter, respective driver maintainers
+Contact: Simona Vetter, respective driver maintainers
+
+Level: Advanced
+
+Rename drm_atomic_state
+-----------------------
+
+The KMS framework uses two slightly different definitions for the ``state``
+concept. For a given object (plane, CRTC, encoder, etc., so
+``drm_$OBJECT_state``), the state is the entire state of that object. However,
+at the device level, ``drm_atomic_state`` refers to a state update for a
+limited number of objects.
+
+The state isn't the entire device state, but only the full state of some
+objects in that device. This is confusing to newcomers, and
+``drm_atomic_state`` should be renamed to something clearer like
+``drm_atomic_commit``.
+
+In addition to renaming the structure itself, it would also imply renaming some
+related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``,
+``drm_atomic_state_put``, ``drm_atomic_state_init``,
+``__drm_atomic_state_free``, etc.).
+
+Contact: Maxime Ripard <mripard@kernel.org>
Level: Advanced
@@ -142,35 +169,10 @@ interfaces to fix these issues:
``_helper_funcs`` since they are not part of the core ABI. There's a
``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Intermediate
-Get rid of dev->struct_mutex from GEM drivers
----------------------------------------------
-
-``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested
-everything. Nowadays in modern drivers the only bit where it's mandatory is
-serializing GEM buffer object destruction. Which unfortunately means drivers
-have to keep track of that lock and either call ``unreference`` or
-``unreference_locked`` depending upon context.
-
-Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
-and there's a GEM object ``free`` callback for any drivers which are
-entirely ``struct_mutex`` free.
-
-For drivers that need ``struct_mutex`` it should be replaced with a driver-
-private lock. The tricky part is the BO free functions, since those can't
-reliably take that lock any more. Instead state needs to be protected with
-suitable subordinate locks or some cleanup work pushed to a worker thread. For
-performance-critical drivers it might also be better to go with a more
-fine-grained per-buffer object and per-context lockings scheme. Currently only
-the ``msm`` and `i915` drivers use ``struct_mutex``.
-
-Contact: Daniel Vetter, respective driver maintainers
-
-Level: Advanced
-
Move Buffer Object Locking to dma_resv_lock()
---------------------------------------------
@@ -181,13 +183,13 @@ reversed.
To solve this we need one standard per-object locking mechanism, which is
dma_resv_lock(). This lock needs to be called as the outermost lock, with all
-other driver specific per-object locks removed. The problem is tha rolling out
+other driver specific per-object locks removed. The problem is that rolling out
the actual change to the locking contract is a flag day, due to struct dma_buf
buffer sharing.
Level: Expert
-Convert logging to drm_* functions with drm_device paramater
+Convert logging to drm_* functions with drm_device parameter
------------------------------------------------------------
For drivers which could have multiple instances, it is necessary to
@@ -216,19 +218,6 @@ Contact: Maintainer of the driver you plan to convert
Level: Intermediate
-Convert drivers to use drm_fbdev_generic_setup()
-------------------------------------------------
-
-Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
-atomic modesetting and GEM vmap support. Historically, generic fbdev emulation
-expected the framebuffer in system memory or system-like memory. By employing
-struct iosys_map, drivers with frambuffers in I/O memory can be supported
-as well.
-
-Contact: Maintainer of the driver you plan to convert
-
-Level: Intermediate
-
Reimplement functions in drm_fbdev_fb_ops without fbdev
-------------------------------------------------------
@@ -237,14 +226,14 @@ being rewritten without dependencies on the fbdev module. Some of the
helpers could further benefit from using struct iosys_map instead of
raw pointers.
-Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
+Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter
Level: Advanced
Benchmark and optimize blitting and format-conversion function
--------------------------------------------------------------
-Drawing to dispay memory quickly is crucial for many applications'
+Drawing to display memory quickly is crucial for many applications'
performance.
On at least x86-64, sys_imageblit() is significantly slower than
@@ -276,17 +265,14 @@ Various hold-ups:
- Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
setup code can't be deleted.
-- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
- atomic drivers we could check for valid formats by calling
- drm_plane_check_pixel_format() against all planes, and pass if any plane
- supports the format. For non-atomic that's not possible since like the format
- list for the primary plane is fake and we'd therefor reject valid formats.
+- Need to switch to drm_gem_fb_create(), as now drm_gem_fb_create() checks for
+ valid formats for atomic drivers.
- Many drivers subclass drm_framebuffer, we'd need a embedding compatible
version of the varios drm_gem_fb_create functions. Maybe called
drm_gem_fb_create/_with_dirty/_with_funcs as needed.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Intermediate
@@ -318,19 +304,10 @@ everything after it has done the write-protect/mkwrite trickery:
Might be good to also have some igt testcases for this.
-Contact: Daniel Vetter, Noralf Tronnes
+Contact: Simona Vetter, Noralf Tronnes
Level: Advanced
-struct drm_gem_object_funcs
----------------------------
-
-GEM objects can now have a function table instead of having the callbacks on the
-DRM driver struct. This is now the preferred way. Callbacks in drivers have been
-converted, except for struct drm_driver.gem_prime_mmap.
-
-Level: Intermediate
-
connector register/unregister fixes
-----------------------------------
@@ -345,8 +322,8 @@ connector register/unregister fixes
Level: Intermediate
-Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
----------------------------------------------------------------
+Remove load/unload callbacks
+----------------------------
The load/unload callbacks in struct &drm_driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
@@ -355,10 +332,9 @@ between setting up the &drm_driver structure and calling drm_dev_register().
- Rework drivers to no longer use the load/unload callbacks, directly coding the
load/unload sequence into the driver's probe function.
-- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
- callbacks for all modern drivers.
+- Once all drivers are converted, remove the load/unload callbacks.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Intermediate
@@ -421,7 +397,7 @@ The task is to use struct iosys_map where it makes sense.
* TTM might benefit from using struct iosys_map internally.
* Framebuffer copying and blitting helpers should operate on struct iosys_map.
-Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter
+Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Simona Vetter
Level: Intermediate
@@ -440,14 +416,15 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
Level: Intermediate
-Request memory regions in all drivers
--------------------------------------
+Request memory regions in all fbdev drivers
+--------------------------------------------
-Go through all drivers and add code to request the memory regions that the
-driver uses. This requires adding calls to request_mem_region(),
+Old/ancient fbdev drivers do not request their memory properly.
+Go through these drivers and add code to request the memory regions
+that the driver uses. This requires adding calls to request_mem_region(),
pci_request_region() or similar functions. Use helpers for managed cleanup
-where possible.
-
+where possible. Problematic areas include hardware that has exclusive ranges
+like VGA. VGA16fb does not request the range as it is expected.
Drivers are pretty bad at doing this and there used to be conflicts among
DRM and fbdev drivers. Still, it's the correct thing to do.
@@ -455,6 +432,79 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
Level: Starter
+Remove driver dependencies on FB_DEVICE
+---------------------------------------
+
+A number of fbdev drivers provide attributes via sysfs and therefore depend
+on CONFIG_FB_DEVICE to be selected. Review each driver and attempt to make
+any dependencies on CONFIG_FB_DEVICE optional. At the minimum, the respective
+code in the driver could be conditionalized via ifdef CONFIG_FB_DEVICE. Not
+all drivers might be able to drop CONFIG_FB_DEVICE.
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>
+
+Level: Starter
+
+Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp
+-------------------------------------------------------------------------
+
+As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
+drm_panel"), we have a check in the drm_panel core to make sure nobody
+double-calls prepare/enable/disable/unprepare. Eventually that should probably
+be turned into a WARN_ON() or somehow made louder.
+
+At the moment, we expect that we may still encounter the warnings in the
+drm_panel core when using panel-simple and panel-edp. Since those panel
+drivers are used with a lot of different DRM modeset drivers they still
+make an extra effort to disable/unprepare the panel themsevles at shutdown
+time. Specifically we could still encounter those warnings if the panel
+driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset
+driver properly calls drm_atomic_helper_shutdown() in its own shutdown()
+callback. Warnings could be avoided in such a case by using something like
+device links to ensure that the panel gets shutdown() after the DRM modeset
+driver.
+
+Once all DRM modeset drivers are known to shutdown properly, the extra
+calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp
+should be removed and this TODO item marked complete.
+
+Contact: Douglas Anderson <dianders@chromium.org>
+
+Level: Intermediate
+
+Transition away from using deprecated MIPI DSI functions
+--------------------------------------------------------
+
+There are many functions defined in ``drm_mipi_dsi.c`` which have been
+deprecated. Each deprecated function was deprecated in favor of its `multi`
+variant (e.g. `mipi_dsi_generic_write()` and `mipi_dsi_generic_write_multi()`).
+The `multi` variant of a function includes improved error handling and logic
+which makes it more convenient to make several calls in a row, as most MIPI
+drivers do.
+
+Drivers should be updated to use undeprecated functions. Once all usages of the
+deprecated MIPI DSI functions have been removed, their definitions may be
+removed from ``drm_mipi_dsi.c``.
+
+Contact: Douglas Anderson <dianders@chromium.org>
+
+Level: Starter
+
+Remove devm_drm_put_bridge()
+----------------------------
+
+Due to how the panel bridge handles the drm_bridge object lifetime, special
+care must be taken to dispose of the drm_bridge object when the
+panel_bridge is removed. This is currently managed using
+devm_drm_put_bridge(), but that is an unsafe, temporary workaround. To fix
+that, the DRM panel lifetime needs to be reworked. After the rework is
+done, remove devm_drm_put_bridge() and the TODO in
+drm_panel_bridge_remove().
+
+Contact: Maxime Ripard <mripard@kernel.org>,
+ Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+Level: Intermediate
Core refactorings
=================
@@ -499,7 +549,7 @@ This is a really varied tasks with lots of little bits and pieces:
<https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_
for some example code that could be reused.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Advanced
@@ -508,17 +558,18 @@ Clean up the debugfs support
There's a bunch of issues with it:
-- The drm_info_list ->show() function doesn't even bother to cast to the drm
- structure for you. This is lazy.
+- Convert drivers to support the drm_debugfs_add_files() function instead of
+ the drm_debugfs_create_files() function.
+
+- Improve late-register debugfs by rolling out the same debugfs pre-register
+ infrastructure for connector and crtc too. That way, the drivers won't need to
+ split their setup code into init and register anymore.
- We probably want to have some support for debugfs files on crtc/connectors and
maybe other kms objects directly in core. There's even drm_print support in
the funcs for these objects to dump kms state, so it's all there. And then the
->show() functions should obviously give you a pointer to the right object.
-- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
- anything we want to print drm_device (or maybe drm_file) is the right thing.
-
- The drm_driver->debugfs_init hooks we have is just an artifact of the old
midlayered load sequence. DRM debugfs should work more like sysfs, where you
can create properties/files for an object anytime you want, and the core
@@ -527,9 +578,7 @@ There's a bunch of issues with it:
this (together with the drm_minor->drm_device move) would allow us to remove
debugfs_init.
-Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/
-
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Intermediate
@@ -550,7 +599,7 @@ Both these problems can be solved by switching over to drmm_kzalloc(), and the
various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(),
drmm_universal_plane_alloc(), ... and so on.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Intermediate
@@ -570,10 +619,47 @@ cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over
this problem for USB devices by fishing out the USB host controller device, as
long as that supports DMA. Otherwise importing can still needlessly fail.
-Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
+Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter
Level: Advanced
+Implement a new DUMB_CREATE2 ioctl
+----------------------------------
+
+The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
+framebuffer format, it only accepts a color mode of vague semantics. Assuming
+a linear framebuffer, the color mode gives an idea of the supported pixel
+format. But userspace effectively has to guess the correct values. It really
+only works reliably with framebuffers in XRGB8888. Userspace has begun to
+workaround these limitations by computing arbitrary format's buffer sizes and
+calculating their sizes in terms of XRGB8888 pixels.
+
+One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
+format and a format modifier to resolve the color mode's ambiguity. As
+framebuffers can be multi-planar, the new ioctl has to return the buffer size,
+pitch and GEM handle for each individual color plane.
+
+In the first step, the new ioctl can be limited to the current features of
+the existing DUMB_CREATE. Individual drivers can then be extended to support
+multi-planar formats. Rockchip might require this and would be a good candidate.
+
+It might also be helpful to userspace to query information about the size of
+a potential buffer, if allocated. Userspace would supply geometry and format;
+the kernel would return minimal allocation sizes and scanline pitch. There is
+interest to allocate that memory from another device and provide it to the
+DRM driver (say via dma-buf).
+
+Another requested feature is the ability to allocate a buffer by size, without
+format. Accelators use this for their buffer allocation and it could likely be
+generalized.
+
+In addition to the kernel implementation, there must be user-space support
+for the new ioctl. There's code in Mesa that might be able to use the new
+call.
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>
+
+Level: Advanced
Better Testing
==============
@@ -592,6 +678,23 @@ Contact: Javier Martinez Canillas <javierm@redhat.com>
Level: Intermediate
+Clean up and document former selftests suites
+---------------------------------------------
+
+Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper,
+drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and
+drm_rect) are former selftests suites that have been converted over when KUnit
+was first introduced.
+
+These suites were fairly undocumented, and with different goals than what unit
+tests can be. Trying to identify what each test in these suites actually test
+for, whether that makes sense for a unit test, and either remove it if it
+doesn't or document it if it does would be of great help.
+
+Contact: Maxime Ripard <mripard@kernel.org>
+
+Level: Intermediate
+
Enable trinity for DRM
----------------------
@@ -634,7 +737,7 @@ Plan to fix this:
2. In all, only look at one of the three status bits set by the above helpers.
3. Remove the other two status bits.
-Contact: Daniel Vetter
+Contact: Simona Vetter
Level: Intermediate
@@ -651,17 +754,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks.
Contact: Harry Wentland, Alex Deucher
-vmwgfx: Replace hashtable with Linux' implementation
-----------------------------------------------------
-
-The vmwgfx driver uses its own hashtable implementation. Replace the
-code with Linux' implementation and update the callers. It's mostly a
-refactoring task, but the interfaces are different.
-
-Contact: Zack Rusin, Thomas Zimmermann <tzimmermann@suse.de>
-
-Level: Intermediate
-
Bootsplash
==========
@@ -747,6 +839,45 @@ Contact: Hans de Goede
Level: Advanced
+Buffer age or other damage accumulation algorithm for buffer damage
+===================================================================
+
+Drivers that do per-buffer uploads, need a buffer damage handling (rather than
+frame damage like drivers that do per-plane or per-CRTC uploads), but there is
+no support to get the buffer age or any other damage accumulation algorithm.
+
+For this reason, the damage helpers just fallback to a full plane update if the
+framebuffer attached to a plane has changed since the last page-flip. Drivers
+set &drm_plane_state.ignore_damage_clips to true as indication to
+drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next()
+helpers that the damage clips should be ignored.
+
+This should be improved to get damage tracking properly working on drivers that
+do per-buffer uploads.
+
+More information about damage tracking and references to learning materials can
+be found in :ref:`damage_tracking_properties`.
+
+Contact: Javier Martinez Canillas <javierm@redhat.com>
+
+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
===========
@@ -764,16 +895,16 @@ existing hardware. The new driver's call-back functions are filled from
existing fbdev code.
More complex fbdev drivers can be refactored step-by-step into a DRM
-driver with the help of the DRM fbconv helpers. [1] These helpers provide
+driver with the help of the DRM fbconv helpers [4]_. These helpers provide
the transition layer between the DRM core infrastructure and the fbdev
driver interface. Create a new DRM driver on top of the fbconv helpers,
copy over the fbdev driver, and hook it up to the DRM code. Examples for
-several fbdev drivers are available at [1] and a tutorial of this process
-available at [2]. The result is a primitive DRM driver that can run X11
-and Weston.
+several fbdev drivers are available in Thomas Zimmermann's fbconv tree
+[4]_, as well as a tutorial of this process [5]_. The result is a primitive
+DRM driver that can run X11 and Weston.
- - [1] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
- - [2] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
+ .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
+ .. [5] https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
Contact: Thomas Zimmermann <tzimmermann@suse.de>
diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst
index 5df1d98b9544..5e5e92e40919 100644
--- a/Documentation/gpu/vc4.rst
+++ b/Documentation/gpu/vc4.rst
@@ -54,6 +54,25 @@ VEC (Composite TV out) encoder
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_vec.c
:doc: VC4 SDTV module
+KUnit Tests
+===========
+
+The VC4 Driver uses KUnit to perform driver-specific unit and
+integration tests.
+
+These tests are using a mock driver and can be ran using the
+command below, on either arm or arm64 architectures,
+
+.. code-block:: bash
+
+ $ ./tools/testing/kunit/kunit.py run \
+ --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \
+ --cross_compile aarch64-linux-gnu- --arch arm64
+
+Parts of the driver that are currently covered by tests are:
+ * The HVS to PixelValve dynamic FIFO assignment, for the BCM2835-7
+ and BCM2711.
+
Memory Management and 3D Command Submission
===========================================
diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst
index bde3c0afb059..d1e953712cc2 100644
--- a/Documentation/gpu/vgaarbiter.rst
+++ b/Documentation/gpu/vgaarbiter.rst
@@ -11,9 +11,9 @@ Section 7, Legacy Devices.
The Resource Access Control (RAC) module inside the X server [0] existed for
the legacy VGA arbitration task (besides other bus management tasks) when more
-than one legacy device co-exists on the same machine. But the problem happens
+than one legacy device co-exist on the same machine. But the problem happens
when these devices are trying to be accessed by different userspace clients
-(e.g. two server in parallel). Their address assignments conflict. Moreover,
+(e.g. two servers in parallel). Their address assignments conflict. Moreover,
ideally, being a userspace application, it is not the role of the X server to
control bus resources. Therefore an arbitration scheme outside of the X server
is needed to control the sharing of these resources. This document introduces
@@ -106,7 +106,7 @@ In-kernel interface
libpciaccess
------------
-To use the vga arbiter char device it was implemented an API inside the
+To use the vga arbiter char device, an API was implemented inside the
libpciaccess library. One field was added to struct pci_device (each device
on the system)::
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 49db221c0f52..1e79e62a6bc4 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -51,6 +51,97 @@ To disable the driver, use ::
sudo modprobe -r vkms
+Configuring With Configfs
+=========================
+
+It is possible to create and configure multiple VKMS instances via configfs.
+
+Start by mounting configfs and loading VKMS::
+
+ sudo mount -t configfs none /config
+ sudo modprobe vkms
+
+Once VKMS is loaded, ``/config/vkms`` is created automatically. Each directory
+under ``/config/vkms`` represents a VKMS instance, create a new one::
+
+ sudo mkdir /config/vkms/my-vkms
+
+By default, the instance is disabled::
+
+ cat /config/vkms/my-vkms/enabled
+ 0
+
+And directories are created for each configurable item of the display pipeline::
+
+ tree /config/vkms/my-vkms
+ ├── connectors
+ ├── crtcs
+ ├── enabled
+ ├── encoders
+ └── planes
+
+To add items to the display pipeline, create one or more directories under the
+available paths.
+
+Start by creating one or more planes::
+
+ sudo mkdir /config/vkms/my-vkms/planes/plane0
+
+Planes have 1 configurable attribute:
+
+- type: Plane type: 0 overlay, 1 primary, 2 cursor (same values as those
+ exposed by the "type" property of a plane)
+
+Continue by creating one or more CRTCs::
+
+ sudo mkdir /config/vkms/my-vkms/crtcs/crtc0
+
+CRTCs have 1 configurable attribute:
+
+- writeback: Enable or disable writeback connector support by writing 1 or 0
+
+Next, create one or more encoders::
+
+ sudo mkdir /config/vkms/my-vkms/encoders/encoder0
+
+Last but not least, create one or more connectors::
+
+ sudo mkdir /config/vkms/my-vkms/connectors/connector0
+
+Connectors have 1 configurable attribute:
+
+- status: Connection status: 1 connected, 2 disconnected, 3 unknown (same values
+ as those exposed by the "status" property of a connector)
+
+To finish the configuration, link the different pipeline items::
+
+ sudo ln -s /config/vkms/my-vkms/crtcs/crtc0 /config/vkms/my-vkms/planes/plane0/possible_crtcs
+ sudo ln -s /config/vkms/my-vkms/crtcs/crtc0 /config/vkms/my-vkms/encoders/encoder0/possible_crtcs
+ sudo ln -s /config/vkms/my-vkms/encoders/encoder0 /config/vkms/my-vkms/connectors/connector0/possible_encoders
+
+Since at least one primary plane is required, make sure to set the right type::
+
+ echo "1" | sudo tee /config/vkms/my-vkms/planes/plane0/type
+
+Once you are done configuring the VKMS instance, enable it::
+
+ echo "1" | sudo tee /config/vkms/my-vkms/enabled
+
+Finally, you can remove the VKMS instance disabling it::
+
+ echo "0" | sudo tee /config/vkms/my-vkms/enabled
+
+And removing the top level directory and its subdirectories::
+
+ sudo rm /config/vkms/my-vkms/planes/*/possible_crtcs/*
+ sudo rm /config/vkms/my-vkms/encoders/*/possible_crtcs/*
+ sudo rm /config/vkms/my-vkms/connectors/*/possible_encoders/*
+ sudo rmdir /config/vkms/my-vkms/planes/*
+ sudo rmdir /config/vkms/my-vkms/crtcs/*
+ sudo rmdir /config/vkms/my-vkms/encoders/*
+ sudo rmdir /config/vkms/my-vkms/connectors/*
+ sudo rmdir /config/vkms/my-vkms
+
Testing With IGT
================
@@ -68,26 +159,34 @@ To return to graphical mode, do::
sudo systemctl isolate graphical.target
-Once you are in text only mode, you can run tests using the --device switch
-or IGT_DEVICE variable to specify the device filter for the driver we want
-to test. IGT_DEVICE can also be used with the run-test.sh script to run the
+Once you are in text only mode, you can run tests using the IGT_FORCE_DRIVER
+variable to specify the device filter for the driver we want to test.
+IGT_FORCE_DRIVER can also be used with the run-tests.sh script to run the
tests for a specific driver::
- sudo ./build/tests/<name of test> --device "sys:/sys/devices/platform/vkms"
- sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/<name of test>
- sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t <name of test>
+ sudo IGT_FORCE_DRIVER="vkms" ./build/tests/<name of test>
+ sudo IGT_FORCE_DRIVER="vkms" ./scripts/run-tests.sh -t <name of test>
For example, to test the functionality of the writeback library,
we can run the kms_writeback test::
- sudo ./build/tests/kms_writeback --device "sys:/sys/devices/platform/vkms"
- sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_writeback
- sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t kms_writeback
+ sudo IGT_FORCE_DRIVER="vkms" ./build/tests/kms_writeback
+ sudo IGT_FORCE_DRIVER="vkms" ./scripts/run-tests.sh -t kms_writeback
You can also run subtests if you do not want to run the entire test::
- sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device "sys:/sys/devices/platform/vkms"
- sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_flip --run-subtest basic-plain-flip
+ sudo IGT_FORCE_DRIVER="vkms" ./build/tests/kms_flip --run-subtest basic-plain-flip
+
+Testing With KUnit
+==================
+
+KUnit (Kernel unit testing framework) provides a common framework for unit tests
+within the Linux kernel.
+More information in ../dev-tools/kunit/index.rst .
+
+To run the VKMS KUnit tests::
+
+ tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/vkms/tests
TODO
====
@@ -118,17 +217,12 @@ Add Plane Features
There's lots of plane features we could add support for:
-- ARGB format on primary plane: blend the primary plane into background with
- translucent alpha.
-
- Add background color KMS property[Good to get started].
-- Full alpha blending on all planes.
-
-- Rotation, scaling.
+- Scaling.
-- Additional buffer formats, especially YUV formats for video like NV12.
- Low/high bpp RGB formats would also be interesting.
+- Additional buffer formats. Low/high bpp RGB formats would be interesting
+ [Good to get started].
- Async updates (currently only possible on cursor plane using the legacy
cursor api).
@@ -141,21 +235,14 @@ Runtime Configuration
---------------------
We want to be able to reconfigure vkms instance without having to reload the
-module. Use/Test-cases:
+module through configfs. Use/Test-cases:
- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling
of compositors).
-- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
- them first).
-
- Change output configuration: Plug/unplug screens, change EDID, allow changing
the refresh rate.
-The currently proposed solution is to expose vkms configuration through
-configfs. All existing module options should be supported through configfs
-too.
-
Writeback support
-----------------
diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst
new file mode 100644
index 000000000000..bc432c95d1a3
--- /dev/null
+++ b/Documentation/gpu/xe/index.rst
@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=======================
+drm/xe Intel GFX Driver
+=======================
+
+The drm/xe driver supports some future GFX cards with rendering, display,
+compute and media. Support for currently available platforms like TGL, ADL,
+DG2, etc is provided to prototype the driver.
+
+.. toctree::
+ :titlesonly:
+
+ xe_mm
+ xe_map
+ xe_migrate
+ xe_exec_queue
+ xe_cs
+ xe_pm
+ xe_gt_freq
+ xe_pcode
+ xe_gt_mcr
+ xe_wa
+ xe_rtp
+ xe_firmware
+ xe_tile
+ xe_debugging
+ xe_devcoredump
+ xe_device
+ xe-drm-usage-stats.rst
+ xe_configfs
diff --git a/Documentation/gpu/xe/xe-drm-usage-stats.rst b/Documentation/gpu/xe/xe-drm-usage-stats.rst
new file mode 100644
index 000000000000..482d503ae68a
--- /dev/null
+++ b/Documentation/gpu/xe/xe-drm-usage-stats.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+.. _xe-usage-stats:
+
+========================================
+Xe DRM client usage stats implementation
+========================================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_drm_client.c
+ :doc: DRM Client usage stats
diff --git a/Documentation/gpu/xe/xe_configfs.rst b/Documentation/gpu/xe/xe_configfs.rst
new file mode 100644
index 000000000000..7f8ec39dc6dd
--- /dev/null
+++ b/Documentation/gpu/xe/xe_configfs.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+.. _xe_configfs:
+
+===========
+Xe Configfs
+===========
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_configfs.c
+ :doc: Xe Configfs
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_configfs.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_cs.rst b/Documentation/gpu/xe/xe_cs.rst
new file mode 100644
index 000000000000..e379aed4f5a8
--- /dev/null
+++ b/Documentation/gpu/xe/xe_cs.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==================
+Command submission
+==================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_exec.c
+ :doc: Execbuf (User GPU command submission)
diff --git a/Documentation/gpu/xe/xe_debugging.rst b/Documentation/gpu/xe/xe_debugging.rst
new file mode 100644
index 000000000000..d65e56ff3500
--- /dev/null
+++ b/Documentation/gpu/xe/xe_debugging.rst
@@ -0,0 +1,7 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=========
+Debugging
+=========
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_assert.h
diff --git a/Documentation/gpu/xe/xe_devcoredump.rst b/Documentation/gpu/xe/xe_devcoredump.rst
new file mode 100644
index 000000000000..ae4ec0e34dc0
--- /dev/null
+++ b/Documentation/gpu/xe/xe_devcoredump.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==================
+Xe Device Coredump
+==================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_devcoredump.c
+ :doc: Xe device coredump
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_devcoredump.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_device.rst b/Documentation/gpu/xe/xe_device.rst
new file mode 100644
index 000000000000..39a937b97cd3
--- /dev/null
+++ b/Documentation/gpu/xe/xe_device.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+.. _xe-device-wedging:
+
+==================
+Xe Device Wedging
+==================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_device.c
+ :doc: Xe Device Wedging
diff --git a/Documentation/gpu/xe/xe_exec_queue.rst b/Documentation/gpu/xe/xe_exec_queue.rst
new file mode 100644
index 000000000000..6076569e311c
--- /dev/null
+++ b/Documentation/gpu/xe/xe_exec_queue.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===============
+Execution Queue
+===============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.c
+ :doc: Execution Queue
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue_types.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_firmware.rst b/Documentation/gpu/xe/xe_firmware.rst
new file mode 100644
index 000000000000..5d23e9f27391
--- /dev/null
+++ b/Documentation/gpu/xe/xe_firmware.rst
@@ -0,0 +1,43 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+========
+Firmware
+========
+
+Firmware Layout
+===============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_uc_fw_abi.h
+ :doc: CSS-based Firmware Layout
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_uc_fw_abi.h
+ :doc: GSC-based Firmware Layout
+
+Write Once Protected Content Memory (WOPCM) Layout
+==================================================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_wopcm.c
+ :doc: Write Once Protected Content Memory (WOPCM) Layout
+
+GuC CTB Blob
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_guc_ct.c
+ :doc: GuC CTB Blob
+
+GuC Power Conservation (PC)
+===========================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_guc_pc.c
+ :doc: GuC Power Conservation (PC)
+
+PCIe Gen5 Limitations
+=====================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_device_sysfs.c
+ :doc: PCIe Gen5 Limitations
+
+Internal API
+============
+
+TODO
diff --git a/Documentation/gpu/xe/xe_gt_freq.rst b/Documentation/gpu/xe/xe_gt_freq.rst
new file mode 100644
index 000000000000..182d6aabeee1
--- /dev/null
+++ b/Documentation/gpu/xe/xe_gt_freq.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==========================
+Xe GT Frequency Management
+==========================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_freq.c
+ :doc: Xe GT Frequency Management
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_throttle.c
+ :doc: Xe GT Throttle
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_freq.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_gt_mcr.rst b/Documentation/gpu/xe/xe_gt_mcr.rst
new file mode 100644
index 000000000000..848c07bc36d0
--- /dev/null
+++ b/Documentation/gpu/xe/xe_gt_mcr.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==============================================
+GT Multicast/Replicated (MCR) Register Support
+==============================================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_mcr.c
+ :doc: GT Multicast/Replicated (MCR) Register Support
+
+Internal API
+============
+
+TODO
diff --git a/Documentation/gpu/xe/xe_map.rst b/Documentation/gpu/xe/xe_map.rst
new file mode 100644
index 000000000000..a098cfd2df04
--- /dev/null
+++ b/Documentation/gpu/xe/xe_map.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=========
+Map Layer
+=========
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_map.h
+ :doc: Map layer
diff --git a/Documentation/gpu/xe/xe_migrate.rst b/Documentation/gpu/xe/xe_migrate.rst
new file mode 100644
index 000000000000..f92faec0ac94
--- /dev/null
+++ b/Documentation/gpu/xe/xe_migrate.rst
@@ -0,0 +1,8 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=============
+Migrate Layer
+=============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_migrate_doc.h
+ :doc: Migrate Layer
diff --git a/Documentation/gpu/xe/xe_mm.rst b/Documentation/gpu/xe/xe_mm.rst
new file mode 100644
index 000000000000..95864a4502dd
--- /dev/null
+++ b/Documentation/gpu/xe/xe_mm.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=================
+Memory Management
+=================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_bo_doc.h
+ :doc: Buffer Objects (BO)
+
+GGTT
+====
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_ggtt.c
+ :doc: Global Graphics Translation Table (GGTT)
+
+GGTT Internal API
+-----------------
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_ggtt_types.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_ggtt.c
+ :internal:
+
+Pagetable building
+==================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_pt.c
+ :doc: Pagetable building
diff --git a/Documentation/gpu/xe/xe_pcode.rst b/Documentation/gpu/xe/xe_pcode.rst
new file mode 100644
index 000000000000..2a43601123cb
--- /dev/null
+++ b/Documentation/gpu/xe/xe_pcode.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=====
+Pcode
+=====
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_pcode.c
+ :doc: PCODE
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_pcode.c
+ :internal:
+
+.. _xe-survivability-mode:
+
+==================
+Survivability Mode
+==================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_survivability_mode.c
+ :doc: Survivability Mode
diff --git a/Documentation/gpu/xe/xe_pm.rst b/Documentation/gpu/xe/xe_pm.rst
new file mode 100644
index 000000000000..6781cdfb24f6
--- /dev/null
+++ b/Documentation/gpu/xe/xe_pm.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+========================
+Runtime Power Management
+========================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_pm.c
+ :doc: Xe Power Management
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_pm.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_rtp.rst b/Documentation/gpu/xe/xe_rtp.rst
new file mode 100644
index 000000000000..7fdf4b6c1a04
--- /dev/null
+++ b/Documentation/gpu/xe/xe_rtp.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+=========================
+Register Table Processing
+=========================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_rtp.c
+ :doc: Register Table Processing
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_rtp_types.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_rtp.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_rtp.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_tile.rst b/Documentation/gpu/xe/xe_tile.rst
new file mode 100644
index 000000000000..c33f68dd95b6
--- /dev/null
+++ b/Documentation/gpu/xe/xe_tile.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+==================
+Multi-tile Devices
+==================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_tile.c
+ :doc: Multi-tile Design
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_tile.c
+ :internal:
diff --git a/Documentation/gpu/xe/xe_wa.rst b/Documentation/gpu/xe/xe_wa.rst
new file mode 100644
index 000000000000..f8811cc6adcc
--- /dev/null
+++ b/Documentation/gpu/xe/xe_wa.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+====================
+Hardware workarounds
+====================
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_wa.c
+ :doc: Hardware workarounds
+
+Internal API
+============
+
+.. kernel-doc:: drivers/gpu/drm/xe/xe_wa.c
+ :internal:
diff --git a/Documentation/gpu/zynqmp.rst b/Documentation/gpu/zynqmp.rst
new file mode 100644
index 000000000000..1a6f9193de22
--- /dev/null
+++ b/Documentation/gpu/zynqmp.rst
@@ -0,0 +1,147 @@
+.. 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_kms.c
diff --git a/Documentation/hid/hid-alps.rst b/Documentation/hid/hid-alps.rst
index 767c96bcbb7c..4a22a357f00c 100644
--- a/Documentation/hid/hid-alps.rst
+++ b/Documentation/hid/hid-alps.rst
@@ -9,7 +9,7 @@ Currently ALPS HID driver supports U1 Touchpad device.
U1 device basic information.
========== ======
-Vender ID 0x044E
+Vendor ID 0x044E
Product ID 0x120B
Version ID 0x0121
========== ======
@@ -69,6 +69,7 @@ To read/write to RAM, need to send a command to the device.
The command format is as below.
DataByte(SET_REPORT)
+~~~~~~~~~~~~~~~~~~~~
===== ======================
Byte1 Command Byte
@@ -89,6 +90,7 @@ Value Byte is writing data when you send the write commands.
When you read RAM, there is no meaning.
DataByte(GET_REPORT)
+~~~~~~~~~~~~~~~~~~~~
===== ======================
Byte1 Response Byte
@@ -104,8 +106,10 @@ Read value is stored in Value Byte.
Packet Format
+-------------
+
Touchpad data byte
-------------------
+~~~~~~~~~~~~~~~~~~
======= ======= ======= ======= ======= ======= ======= ======= =====
@@ -156,7 +160,7 @@ Zsn_6-0(7bit):
StickPointer data byte
-----------------------
+~~~~~~~~~~~~~~~~~~~~~~
======= ======= ======= ======= ======= ======= ======= ======= =====
- b7 b6 b5 b4 b3 b2 b1 b0
diff --git a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-bpf.rst
new file mode 100644
index 000000000000..5939eeafb361
--- /dev/null
+++ b/Documentation/hid/hid-bpf.rst
@@ -0,0 +1,527 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======
+HID-BPF
+=======
+
+HID is a standard protocol for input devices but some devices may require
+custom tweaks, traditionally done with a kernel driver fix. Using the eBPF
+capabilities instead speeds up development and adds new capabilities to the
+existing HID interfaces.
+
+.. contents::
+ :local:
+ :depth: 2
+
+
+When (and why) to use HID-BPF
+=============================
+
+There are several use cases when using HID-BPF is better
+than standard kernel driver fix:
+
+Dead zone of a joystick
+-----------------------
+
+Assuming you have a joystick that is getting older, it is common to see it
+wobbling around its neutral point. This is usually filtered at the application
+level by adding a *dead zone* for this specific axis.
+
+With HID-BPF, we can apply this filtering in the kernel directly so userspace
+does not get woken up when nothing else is happening on the input controller.
+
+Of course, given that this dead zone is specific to an individual device, we
+can not create a generic fix for all of the same joysticks. Adding a custom
+kernel API for this (e.g. by adding a sysfs entry) does not guarantee this new
+kernel API will be broadly adopted and maintained.
+
+HID-BPF allows the userspace program to load the program itself, ensuring we
+only load the custom API when we have a user.
+
+Simple fixup of report descriptor
+---------------------------------
+
+In the HID tree, half of the drivers only fix one key or one byte
+in the report descriptor. These fixes all require a kernel patch and the
+subsequent shepherding into a release, a long and painful process for users.
+
+We can reduce this burden by providing an eBPF program instead. Once such a
+program has been verified by the user, we can embed the source code into the
+kernel tree and ship the eBPF program and load it directly instead of loading
+a specific kernel module for it.
+
+Note: distribution of eBPF programs and their inclusion in the kernel is not
+yet fully implemented
+
+Add a new feature that requires a new kernel API
+------------------------------------------------
+
+An example for such a feature are the Universal Stylus Interface (USI) pens.
+Basically, USI pens require a new kernel API because there are new
+channels of communication that our HID and input stack do not support.
+Instead of using hidraw or creating new sysfs entries or ioctls, we can rely
+on eBPF to have the kernel API controlled by the consumer and to not
+impact the performances by waking up userspace every time there is an
+event.
+
+Morph a device into something else and control that from userspace
+------------------------------------------------------------------
+
+The kernel has a relatively static mapping of HID items to evdev bits.
+It cannot decide to dynamically transform a given device into something else
+as it does not have the required context and any such transformation cannot be
+undone (or even discovered) by userspace.
+
+However, some devices are useless with that static way of defining devices. For
+example, the Microsoft Surface Dial is a pushbutton with haptic feedback that
+is barely usable as of today.
+
+With eBPF, userspace can morph that device into a mouse, and convert the dial
+events into wheel events. Also, the userspace program can set/unset the haptic
+feedback depending on the context. For example, if a menu is visible on the
+screen we likely need to have a haptic click every 15 degrees. But when
+scrolling in a web page the user experience is better when the device emits
+events at the highest resolution.
+
+Firewall
+--------
+
+What if we want to prevent other users to access a specific feature of a
+device? (think a possibly broken firmware update entry point)
+
+With eBPF, we can intercept any HID command emitted to the device and
+validate it or not.
+
+This also allows to sync the state between the userspace and the
+kernel/bpf program because we can intercept any incoming command.
+
+Tracing
+-------
+
+The last usage is tracing events and all the fun we can do we BPF to summarize
+and analyze events.
+
+Right now, tracing relies on hidraw. It works well except for a couple
+of issues:
+
+1. if the driver doesn't export a hidraw node, we can't trace anything
+ (eBPF will be a "god-mode" there, so this may raise some eyebrows)
+2. hidraw doesn't catch other processes' requests to the device, which
+ means that we have cases where we need to add printks to the kernel
+ to understand what is happening.
+
+High-level view of HID-BPF
+==========================
+
+The main idea behind HID-BPF is that it works at an array of bytes level.
+Thus, all of the parsing of the HID report and the HID report descriptor
+must be implemented in the userspace component that loads the eBPF
+program.
+
+For example, in the dead zone joystick from above, knowing which fields
+in the data stream needs to be set to ``0`` needs to be computed by userspace.
+
+A corollary of this is that HID-BPF doesn't know about the other subsystems
+available in the kernel. *You can not directly emit input event through the
+input API from eBPF*.
+
+When a BPF program needs to emit input events, it needs to talk with the HID
+protocol, and rely on the HID kernel processing to translate the HID data into
+input events.
+
+In-tree HID-BPF programs and ``udev-hid-bpf``
+=============================================
+
+Official device fixes are shipped in the kernel tree as source in the
+``drivers/hid/bpf/progs`` directory. This allows to add selftests to them in
+``tools/testing/selftests/hid``.
+
+However, the compilation of these objects is not part of a regular kernel compilation
+given that they need an external tool to be loaded. This tool is currently
+`udev-hid-bpf <https://libevdev.pages.freedesktop.org/udev-hid-bpf/index.html>`_.
+
+For convenience, that external repository duplicates the files from here in
+``drivers/hid/bpf/progs`` into its own ``src/bpf/stable`` directory. This allows
+distributions to not have to pull the entire kernel source tree to ship and package
+those HID-BPF fixes. ``udev-hid-bpf`` also has capabilities of handling multiple
+objects files depending on the kernel the user is running.
+
+Available types of programs
+===========================
+
+HID-BPF is built "on top" of BPF, meaning that we use bpf struct_ops method to
+declare our programs.
+
+HID-BPF has the following attachment types available:
+
+1. event processing/filtering with ``SEC("struct_ops/hid_device_event")`` in libbpf
+2. actions coming from userspace with ``SEC("syscall")`` in libbpf
+3. change of the report descriptor with ``SEC("struct_ops/hid_rdesc_fixup")`` or
+ ``SEC("struct_ops.s/hid_rdesc_fixup")`` in libbpf
+
+A ``hid_device_event`` is calling a BPF program when an event is received from
+the device. Thus we are in IRQ context and can act on the data or notify userspace.
+And given that we are in IRQ context, we can not talk back to the device.
+
+A ``syscall`` means that userspace called the syscall ``BPF_PROG_RUN`` facility.
+This time, we can do any operations allowed by HID-BPF, and talking to the device is
+allowed.
+
+Last, ``hid_rdesc_fixup`` is different from the others as there can be only one
+BPF program of this type. This is called on ``probe`` from the driver and allows to
+change the report descriptor from the BPF program. Once a ``hid_rdesc_fixup``
+program has been loaded, it is not possible to overwrite it unless the program which
+inserted it allows us by pinning the program and closing all of its fds pointing to it.
+
+Note that ``hid_rdesc_fixup`` can be declared as sleepable (``SEC("struct_ops.s/hid_rdesc_fixup")``).
+
+
+Developer API:
+==============
+
+Available ``struct_ops`` for HID-BPF:
+-------------------------------------
+
+.. kernel-doc:: include/linux/hid_bpf.h
+ :identifiers: hid_bpf_ops
+
+
+User API data structures available in programs:
+-----------------------------------------------
+
+.. kernel-doc:: include/linux/hid_bpf.h
+ :identifiers: hid_bpf_ctx
+
+Available API that can be used in all HID-BPF struct_ops programs:
+------------------------------------------------------------------
+
+.. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
+ :identifiers: hid_bpf_get_data
+
+Available API that can be used in syscall HID-BPF programs or in sleepable HID-BPF struct_ops programs:
+-------------------------------------------------------------------------------------------------------
+
+.. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
+ :identifiers: hid_bpf_hw_request hid_bpf_hw_output_report hid_bpf_input_report hid_bpf_try_input_report hid_bpf_allocate_context hid_bpf_release_context
+
+General overview of a HID-BPF program
+=====================================
+
+Accessing the data attached to the context
+------------------------------------------
+
+The ``struct hid_bpf_ctx`` doesn't export the ``data`` fields directly and to access
+it, a bpf program needs to first call :c:func:`hid_bpf_get_data`.
+
+``offset`` can be any integer, but ``size`` needs to be constant, known at compile
+time.
+
+This allows the following:
+
+1. for a given device, if we know that the report length will always be of a certain value,
+ we can request the ``data`` pointer to point at the full report length.
+
+ The kernel will ensure we are using a correct size and offset and eBPF will ensure
+ the code will not attempt to read or write outside of the boundaries::
+
+ __u8 *data = hid_bpf_get_data(ctx, 0 /* offset */, 256 /* size */);
+
+ if (!data)
+ return 0; /* ensure data is correct, now the verifier knows we
+ * have 256 bytes available */
+
+ bpf_printk("hello world: %02x %02x %02x", data[0], data[128], data[255]);
+
+2. if the report length is variable, but we know the value of ``X`` is always a 16-bit
+ integer, we can then have a pointer to that value only::
+
+ __u16 *x = hid_bpf_get_data(ctx, offset, sizeof(*x));
+
+ if (!x)
+ return 0; /* something went wrong */
+
+ *x += 1; /* increment X by one */
+
+Effect of a HID-BPF program
+---------------------------
+
+For all HID-BPF attachment types except for :c:func:`hid_rdesc_fixup`, several eBPF
+programs can be attached to the same device. If a HID-BPF struct_ops has a
+:c:func:`hid_rdesc_fixup` while another is already attached to the device, the
+kernel will return `-EINVAL` when attaching the struct_ops.
+
+Unless ``BPF_F_BEFORE`` is added to the flags while attaching the program, the new
+program is appended at the end of the list.
+``BPF_F_BEFORE`` will insert the new program at the beginning of the list which is
+useful for e.g. tracing where we need to get the unprocessed events from the device.
+
+Note that if there are multiple programs using the ``BPF_F_BEFORE`` flag,
+only the most recently loaded one is actually the first in the list.
+
+``SEC("struct_ops/hid_device_event")``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Whenever a matching event is raised, the eBPF programs are called one after the other
+and are working on the same data buffer.
+
+If a program changes the data associated with the context, the next one will see
+the modified data but it will have *no* idea of what the original data was.
+
+Once all the programs are run and return ``0`` or a positive value, the rest of the
+HID stack will work on the modified data, with the ``size`` field of the last hid_bpf_ctx
+being the new size of the input stream of data.
+
+A BPF program returning a negative error discards the event, i.e. this event will not be
+processed by the HID stack. Clients (hidraw, input, LEDs) will **not** see this event.
+
+``SEC("syscall")``
+~~~~~~~~~~~~~~~~~~
+
+``syscall`` are not attached to a given device. To tell which device we are working
+with, userspace needs to refer to the device by its unique system id (the last 4 numbers
+in the sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``).
+
+To retrieve a context associated with the device, the program must call
+hid_bpf_allocate_context() and must release it with hid_bpf_release_context()
+before returning.
+Once the context is retrieved, one can also request a pointer to kernel memory with
+hid_bpf_get_data(). This memory is big enough to support all input/output/feature
+reports of the given device.
+
+``SEC("struct_ops/hid_rdesc_fixup")``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``hid_rdesc_fixup`` program works in a similar manner to ``.report_fixup``
+of ``struct hid_driver``.
+
+When the device is probed, the kernel sets the data buffer of the context with the
+content of the report descriptor. The memory associated with that buffer is
+``HID_MAX_DESCRIPTOR_SIZE`` (currently 4kB).
+
+The eBPF program can modify the data buffer at-will and the kernel uses the
+modified content and size as the report descriptor.
+
+Whenever a struct_ops containing a ``SEC("struct_ops/hid_rdesc_fixup")`` program
+is attached (if no program was attached before), the kernel immediately disconnects
+the HID device and does a reprobe.
+
+In the same way, when this struct_ops is detached, the kernel issues a disconnect
+on the device.
+
+There is no ``detach`` facility in HID-BPF. Detaching a program happens when
+all the user space file descriptors pointing at a HID-BPF struct_ops link are closed.
+Thus, if we need to replace a report descriptor fixup, some cooperation is
+required from the owner of the original report descriptor fixup.
+The previous owner will likely pin the struct_ops link in the bpffs, and we can then
+replace it through normal bpf operations.
+
+Attaching a bpf program to a device
+===================================
+
+We now use standard struct_ops attachment through ``bpf_map__attach_struct_ops()``.
+But given that we need to attach a struct_ops to a dedicated HID device, the caller
+must set ``hid_id`` in the struct_ops map before loading the program in the kernel.
+
+``hid_id`` is the unique system ID of the HID device (the last 4 numbers in the
+sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``)
+
+One can also set ``flags``, which is of type ``enum hid_bpf_attach_flags``.
+
+We can not rely on hidraw to bind a BPF program to a HID device. hidraw is an
+artefact of the processing of the HID device, and is not stable. Some drivers
+even disable it, so that removes the tracing capabilities on those devices
+(where it is interesting to get the non-hidraw traces).
+
+On the other hand, the ``hid_id`` is stable for the entire life of the HID device,
+even if we change its report descriptor.
+
+Given that hidraw is not stable when the device disconnects/reconnects, we recommend
+accessing the current report descriptor of the device through the sysfs.
+This is available at ``/sys/bus/hid/devices/BUS:VID:PID.000N/report_descriptor`` as a
+binary stream.
+
+Parsing the report descriptor is the responsibility of the BPF programmer or the userspace
+component that loads the eBPF program.
+
+An (almost) complete example of a BPF enhanced HID device
+=========================================================
+
+*Foreword: for most parts, this could be implemented as a kernel driver*
+
+Let's imagine we have a new tablet device that has some haptic capabilities
+to simulate the surface the user is scratching on. This device would also have
+a specific 3 positions switch to toggle between *pencil on paper*, *cray on a wall*
+and *brush on a painting canvas*. To make things even better, we can control the
+physical position of the switch through a feature report.
+
+And of course, the switch is relying on some userspace component to control the
+haptic feature of the device itself.
+
+Filtering events
+----------------
+
+The first step consists in filtering events from the device. Given that the switch
+position is actually reported in the flow of the pen events, using hidraw to implement
+that filtering would mean that we wake up userspace for every single event.
+
+This is OK for libinput, but having an external library that is just interested in
+one byte in the report is less than ideal.
+
+For that, we can create a basic skeleton for our BPF program::
+
+ #include "vmlinux.h"
+ #include <bpf/bpf_helpers.h>
+ #include <bpf/bpf_tracing.h>
+
+ /* HID programs need to be GPL */
+ char _license[] SEC("license") = "GPL";
+
+ /* HID-BPF kfunc API definitions */
+ extern __u8 *hid_bpf_get_data(struct hid_bpf_ctx *ctx,
+ unsigned int offset,
+ const size_t __sz) __ksym;
+
+ struct {
+ __uint(type, BPF_MAP_TYPE_RINGBUF);
+ __uint(max_entries, 4096 * 64);
+ } ringbuf SEC(".maps");
+
+ __u8 current_value = 0;
+
+ SEC("struct_ops/hid_device_event")
+ int BPF_PROG(filter_switch, struct hid_bpf_ctx *hid_ctx)
+ {
+ __u8 *data = hid_bpf_get_data(hid_ctx, 0 /* offset */, 192 /* size */);
+ __u8 *buf;
+
+ if (!data)
+ return 0; /* EPERM check */
+
+ if (current_value != data[152]) {
+ buf = bpf_ringbuf_reserve(&ringbuf, 1, 0);
+ if (!buf)
+ return 0;
+
+ *buf = data[152];
+
+ bpf_ringbuf_commit(buf, 0);
+
+ current_value = data[152];
+ }
+
+ return 0;
+ }
+
+ SEC(".struct_ops.link")
+ struct hid_bpf_ops haptic_tablet = {
+ .hid_device_event = (void *)filter_switch,
+ };
+
+
+To attach ``haptic_tablet``, userspace needs to set ``hid_id`` first::
+
+ static int attach_filter(struct hid *hid_skel, int hid_id)
+ {
+ int err, link_fd;
+
+ hid_skel->struct_ops.haptic_tablet->hid_id = hid_id;
+ err = hid__load(skel);
+ if (err)
+ return err;
+
+ link_fd = bpf_map__attach_struct_ops(hid_skel->maps.haptic_tablet);
+ if (!link_fd) {
+ fprintf(stderr, "can not attach HID-BPF program: %m\n");
+ return -1;
+ }
+
+ return link_fd; /* the fd of the created bpf_link */
+ }
+
+Our userspace program can now listen to notifications on the ring buffer, and
+is awaken only when the value changes.
+
+When the userspace program doesn't need to listen to events anymore, it can just
+close the returned bpf link from :c:func:`attach_filter`, which will tell the kernel to
+detach the program from the HID device.
+
+Of course, in other use cases, the userspace program can also pin the fd to the
+BPF filesystem through a call to :c:func:`bpf_obj_pin`, as with any bpf_link.
+
+Controlling the device
+----------------------
+
+To be able to change the haptic feedback from the tablet, the userspace program
+needs to emit a feature report on the device itself.
+
+Instead of using hidraw for that, we can create a ``SEC("syscall")`` program
+that talks to the device::
+
+ /* some more HID-BPF kfunc API definitions */
+ extern struct hid_bpf_ctx *hid_bpf_allocate_context(unsigned int hid_id) __ksym;
+ extern void hid_bpf_release_context(struct hid_bpf_ctx *ctx) __ksym;
+ extern int hid_bpf_hw_request(struct hid_bpf_ctx *ctx,
+ __u8* data,
+ size_t len,
+ enum hid_report_type type,
+ enum hid_class_request reqtype) __ksym;
+
+
+ struct hid_send_haptics_args {
+ /* data needs to come at offset 0 so we can do a memcpy into it */
+ __u8 data[10];
+ unsigned int hid;
+ };
+
+ SEC("syscall")
+ int send_haptic(struct hid_send_haptics_args *args)
+ {
+ struct hid_bpf_ctx *ctx;
+ int ret = 0;
+
+ ctx = hid_bpf_allocate_context(args->hid);
+ if (!ctx)
+ return 0; /* EPERM check */
+
+ ret = hid_bpf_hw_request(ctx,
+ args->data,
+ 10,
+ HID_FEATURE_REPORT,
+ HID_REQ_SET_REPORT);
+
+ hid_bpf_release_context(ctx);
+
+ return ret;
+ }
+
+And then userspace needs to call that program directly::
+
+ static int set_haptic(struct hid *hid_skel, int hid_id, __u8 haptic_value)
+ {
+ int err, prog_fd;
+ int ret = -1;
+ struct hid_send_haptics_args args = {
+ .hid = hid_id,
+ };
+ DECLARE_LIBBPF_OPTS(bpf_test_run_opts, tattrs,
+ .ctx_in = &args,
+ .ctx_size_in = sizeof(args),
+ );
+
+ args.data[0] = 0x02; /* report ID of the feature on our device */
+ args.data[1] = haptic_value;
+
+ prog_fd = bpf_program__fd(hid_skel->progs.set_haptic);
+
+ err = bpf_prog_test_run_opts(prog_fd, &tattrs);
+ return err;
+ }
+
+Now our userspace program is aware of the haptic state and can control it. The
+program could make this state further available to other userspace programs
+(e.g. via a DBus API).
+
+The interesting bit here is that we did not created a new kernel API for this.
+Which means that if there is a bug in our implementation, we can change the
+interface with the kernel at-will, because the userspace application is
+responsible for its own usage.
diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
index caebc6266603..9b82c7f896aa 100644
--- a/Documentation/hid/hiddev.rst
+++ b/Documentation/hid/hiddev.rst
@@ -8,7 +8,7 @@ Introduction
In addition to the normal input type HID devices, USB also uses the
human interface device protocols for things that are not really human
interfaces, but have similar sorts of communication needs. The two big
-examples for this are power devices (especially uninterruptable power
+examples for this are power devices (especially uninterruptible power
supplies) and monitor control on higher end monitors.
To support these disparate requirements, the Linux USB system provides
diff --git a/Documentation/hid/hidintro.rst b/Documentation/hid/hidintro.rst
new file mode 100644
index 000000000000..73523e315ebd
--- /dev/null
+++ b/Documentation/hid/hidintro.rst
@@ -0,0 +1,524 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Introduction to HID report descriptors
+======================================
+
+This chapter is meant to give a broad overview of what HID report
+descriptors are, and of how a casual (non-kernel) programmer can deal
+with HID devices that are not working well with Linux.
+
+.. contents::
+ :local:
+ :depth: 2
+
+.. toctree::
+ :maxdepth: 2
+
+ hidreport-parsing
+
+
+Introduction
+============
+
+HID stands for Human Interface Device, and can be whatever device you
+are using to interact with a computer, be it a mouse, a touchpad, a
+tablet, a microphone.
+
+Many HID devices work out the box, even if their hardware is different.
+For example, mice can have any number of buttons; they may have a
+wheel; movement sensitivity differs between different models, and so
+on. Nonetheless, most of the time everything just works, without the
+need to have specialized code in the kernel for every mouse model
+developed since 1970.
+
+This is because modern HID devices do advertise their capabilities
+through the *HID report descriptor*, a fixed set of bytes describing
+exactly what *HID reports* may be sent between the device and the host
+and the meaning of each individual bit in those reports. For example,
+a HID Report Descriptor may specify that "in a report with ID 3 the
+bits from 8 to 15 is the delta x coordinate of a mouse".
+
+The HID report itself then merely carries the actual data values
+without any extra meta information. Note that HID reports may be sent
+from the device ("Input Reports", i.e. input events), to the device
+("Output Reports" to e.g. change LEDs) or used for device configuration
+("Feature reports"). A device may support one or more HID reports.
+
+The HID subsystem is in charge of parsing the HID report descriptors,
+and converts HID events into normal input device interfaces (see
+Documentation/hid/hid-transport.rst). Devices may misbehave because the
+HID report descriptor provided by the device is wrong, or because it
+needs to be dealt with in a special way, or because some special
+device or interaction mode is not handled by the default code.
+
+The format of HID report descriptors is described by two documents,
+available from the `USB Implementers Forum <https://www.usb.org/>`_
+`HID web page <https://www.usb.org/hid>`_ address:
+
+ * the `HID USB Device Class Definition
+ <https://www.usb.org/document-library/device-class-definition-hid-111>`_ (HID Spec from now on)
+ * the `HID Usage Tables <https://usb.org/document-library/hid-usage-tables-14>`_ (HUT from now on)
+
+The HID subsystem can deal with different transport drivers
+(USB, I2C, Bluetooth, etc.). See Documentation/hid/hid-transport.rst.
+
+Parsing HID report descriptors
+==============================
+
+The current list of HID devices can be found at ``/sys/bus/hid/devices/``.
+For each device, say ``/sys/bus/hid/devices/0003\:093A\:2510.0002/``,
+one can read the corresponding report descriptor::
+
+ $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
+ 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
+ 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
+ 00000030 81 06 c0 c0 |....|
+ 00000034
+
+Optional: the HID report descriptor can be read also by
+directly accessing the hidraw driver [#hidraw]_.
+
+The basic structure of HID report descriptors is defined in the HID
+spec, while HUT "defines constants that can be interpreted by an
+application to identify the purpose and meaning of a data field in a
+HID report". Each entry is defined by at least two bytes, where the
+first one defines what type of value is following and is described in
+the HID spec, while the second one carries the actual value and is
+described in the HUT.
+
+HID report descriptors can, in principle, be painstakingly parsed by
+hand, byte by byte.
+
+A short introduction on how to do this is sketched in
+Documentation/hid/hidreport-parsing.rst; you only need to understand it
+if you need to patch HID report descriptors.
+
+In practice you should not parse HID report descriptors by hand; rather,
+you should use an existing parser. Among all the available ones
+
+ * the online `USB Descriptor and Request Parser
+ <http://eleccelerator.com/usbdescreqparser/>`_;
+ * `hidrdd <https://github.com/abend0c1/hidrdd>`_,
+ that provides very detailed and somewhat verbose descriptions
+ (verbosity can be useful if you are not familiar with HID report
+ descriptors);
+ * `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_,
+ a complete utility set that allows, among other things,
+ to record and replay the raw HID reports and to debug
+ and replay HID devices.
+ It is being actively developed by the Linux HID subsystem maintainers.
+
+Parsing the mouse HID report descriptor with `hid-tools
+<https://gitlab.freedesktop.org/libevdev/hid-tools>`_ leads to
+(explanations interposed)::
+
+ $ ./hid-decode /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ # device 0:0
+ # 0x05, 0x01, // Usage Page (Generic Desktop) 0
+ # 0x09, 0x02, // Usage (Mouse) 2
+ # 0xa1, 0x01, // Collection (Application) 4
+ # 0x09, 0x01, // Usage (Pointer) 6
+ # 0xa1, 0x00, // Collection (Physical) 8
+ # 0x05, 0x09, // Usage Page (Button) 10
+
+what follows is a button ::
+
+ # 0x19, 0x01, // Usage Minimum (1) 12
+ # 0x29, 0x03, // Usage Maximum (3) 14
+
+first button is button number 1, last button is button number 3 ::
+
+ # 0x15, 0x00, // Logical Minimum (0) 16
+ # 0x25, 0x01, // Logical Maximum (1) 18
+
+each button can send values from 0 up to including 1
+(i.e. they are binary buttons) ::
+
+ # 0x75, 0x01, // Report Size (1) 20
+
+each button is sent as exactly one bit ::
+
+ # 0x95, 0x03, // Report Count (3) 22
+
+and there are three of those bits (matching the three buttons) ::
+
+ # 0x81, 0x02, // Input (Data,Var,Abs) 24
+
+it's actual Data (not constant padding), they represent
+a single variable (Var) and their values are Absolute (not relative);
+See HID spec Sec. 6.2.2.5 "Input, Output, and Feature Items" ::
+
+ # 0x75, 0x05, // Report Size (5) 26
+
+five additional padding bits, needed to reach a byte ::
+
+ # 0x95, 0x01, // Report Count (1) 28
+
+those five bits are repeated only once ::
+
+ # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
+
+and take Constant (Cnst) values i.e. they can be ignored. ::
+
+ # 0x05, 0x01, // Usage Page (Generic Desktop) 32
+ # 0x09, 0x30, // Usage (X) 34
+ # 0x09, 0x31, // Usage (Y) 36
+ # 0x09, 0x38, // Usage (Wheel) 38
+
+The mouse has also two physical positions (Usage (X), Usage (Y))
+and a wheel (Usage (Wheel)) ::
+
+ # 0x15, 0x81, // Logical Minimum (-127) 40
+ # 0x25, 0x7f, // Logical Maximum (127) 42
+
+each of them can send values ranging from -127 up to including 127 ::
+
+ # 0x75, 0x08, // Report Size (8) 44
+
+which is represented by eight bits ::
+
+ # 0x95, 0x03, // Report Count (3) 46
+
+and there are three of those eight bits, matching X, Y and Wheel. ::
+
+ # 0x81, 0x06, // Input (Data,Var,Rel) 48
+
+This time the data values are Relative (Rel), i.e. they represent
+the change from the previously sent report (event) ::
+
+ # 0xc0, // End Collection 50
+ # 0xc0, // End Collection 51
+ #
+ R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0
+ N: device 0:0
+ I: 3 0001 0001
+
+
+This Report Descriptor tells us that the mouse input will be
+transmitted using four bytes: the first one for the buttons (three
+bits used, five for padding), the last three for the mouse X, Y and
+wheel changes, respectively.
+
+Indeed, for any event, the mouse will send a *report* of four bytes.
+We can check the values sent by resorting e.g. to the `hid-recorder`
+tool, from `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_:
+The sequence of bytes sent by clicking and releasing button 1, then button 2, then button 3 is::
+
+ $ sudo ./hid-recorder /dev/hidraw1
+
+ ....
+ output of hid-decode
+ ....
+
+ # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000000.000000 4 01 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000000.183949 4 00 00 00 00
+ # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000001.959698 4 02 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000002.103899 4 00 00 00 00
+ # Button: 0 0 1 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000004.855799 4 04 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000005.103864 4 00 00 00 00
+
+This example shows that when button 2 is clicked,
+the bytes ``02 00 00 00`` are sent, and the immediately subsequent
+event (``00 00 00 00``) is the release of button 2 (no buttons are
+pressed, remember that the data values are *absolute*).
+
+If instead one clicks and holds button 1, then clicks and holds button
+2, releases button 1, and finally releases button 2, the reports are::
+
+ # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000044.175830 4 01 00 00 00
+ # Button: 1 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000045.975997 4 03 00 00 00
+ # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000047.407930 4 02 00 00 00
+ # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
+ E: 000049.199919 4 00 00 00 00
+
+where with ``03 00 00 00`` both buttons are pressed, and with the
+subsequent ``02 00 00 00`` button 1 is released while button 2 is still
+active.
+
+Output, Input and Feature Reports
+---------------------------------
+
+HID devices can have Input Reports, like in the mouse example, Output
+Reports, and Feature Reports. "Output" means that the information is
+sent to the device. For example, a joystick with force feedback will
+have some output; the led of a keyboard would need an output as well.
+"Input" means that data come from the device.
+
+"Feature"s are not meant to be consumed by the end user and define
+configuration options for the device. They can be queried from the host;
+when declared as *Volatile* they should be changed by the host.
+
+
+Collections, Report IDs and Evdev events
+========================================
+
+A single device can logically group data into different independent
+sets, called a *Collection*. Collections can be nested and there are
+different types of collections (see the HID spec 6.2.2.6
+"Collection, End Collection Items" for details).
+
+Different reports are identified by means of different *Report ID*
+fields, i.e. a number identifying the structure of the immediately
+following report.
+Whenever a Report ID is needed it is transmitted as the first byte of
+any report. A device with only one supported HID report (like the mouse
+example above) may omit the report ID.
+
+Consider the following HID report descriptor::
+
+ 05 01 09 02 A1 01 85 01 05 09 19 01 29 05 15 00
+ 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01
+ 09 30 09 31 16 00 F8 26 FF 07 75 0C 95 02 81 06
+ 09 38 15 80 25 7F 75 08 95 01 81 06 05 0C 0A 38
+ 02 15 80 25 7F 75 08 95 01 81 06 C0 05 01 09 02
+ A1 01 85 02 05 09 19 01 29 05 15 00 25 01 95 05
+ 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31
+ 16 00 F8 26 FF 07 75 0C 95 02 81 06 09 38 15 80
+ 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 80 25
+ 7F 75 08 95 01 81 06 C0 05 01 09 07 A1 01 85 05
+ 05 07 15 00 25 01 09 29 09 3E 09 4B 09 4E 09 E3
+ 09 E8 09 E8 09 E8 75 01 95 08 81 02 95 00 81 01
+ C0 05 0C 09 01 A1 01 85 06 15 00 25 01 75 01 95
+ 01 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
+ 06 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
+ 06 C0 05 0C 09 01 A1 01 85 03 09 05 15 00 26 FF
+ 00 75 08 95 02 B1 02 C0
+
+After parsing it (try to parse it on your own using the suggested
+tools!) one can see that the device presents two ``Mouse`` Application
+Collections (with reports identified by Reports IDs 1 and 2,
+respectively), a ``Keypad`` Application Collection (whose report is
+identified by the Report ID 5) and two ``Consumer Controls`` Application
+Collections, (with Report IDs 6 and 3, respectively). Note, however,
+that a device can have different Report IDs for the same Application
+Collection.
+
+The data sent will begin with the Report ID byte, and will be followed
+by the corresponding information. For example, the data transmitted for
+the last consumer control::
+
+ 0x05, 0x0C, // Usage Page (Consumer)
+ 0x09, 0x01, // Usage (Consumer Control)
+ 0xA1, 0x01, // Collection (Application)
+ 0x85, 0x03, // Report ID (3)
+ 0x09, 0x05, // Usage (Headphone)
+ 0x15, 0x00, // Logical Minimum (0)
+ 0x26, 0xFF, 0x00, // Logical Maximum (255)
+ 0x75, 0x08, // Report Size (8)
+ 0x95, 0x02, // Report Count (2)
+ 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
+ 0xC0, // End Collection
+
+will be of three bytes: the first for the Report ID (3), the next two
+for the headphone, with two (``Report Count (2)``) bytes
+(``Report Size (8)``), each ranging from 0 (``Logical Minimum (0)``)
+to 255 (``Logical Maximum (255)``).
+
+All the Input data sent by the device should be translated into
+corresponding Evdev events, so that the remaining part of the stack can
+know what is going on, e.g. the bit for the first button translates into
+the ``EV_KEY/BTN_LEFT`` evdev event and relative X movement translates
+into the ``EV_REL/REL_X`` evdev event".
+
+Events
+======
+
+In Linux, one ``/dev/input/event*`` is created for each ``Application
+Collection``. Going back to the mouse example, and repeating the
+sequence where one clicks and holds button 1, then clicks and holds
+button 2, releases button 1, and finally releases button 2, one gets::
+
+ $ sudo libinput record /dev/input/event1
+ # libinput record
+ version: 1
+ ndevices: 1
+ libinput:
+ version: "1.23.0"
+ git: "unknown"
+ system:
+ os: "opensuse-tumbleweed:20230619"
+ kernel: "6.3.7-1-default"
+ dmi: "dmi:bvnHP:bvrU77Ver.01.05.00:bd03/24/2022:br5.0:efr20.29:svnHP:pnHPEliteBook64514inchG9NotebookPC:pvr:rvnHP:rn89D2:rvrKBCVersion14.1D.00:cvnHP:ct10:cvr:sku5Y3J1EA#ABZ:"
+ devices:
+ - node: /dev/input/event1
+ evdev:
+ # Name: PixArt HP USB Optical Mouse
+ # ID: bus 0x3 vendor 0x3f0 product 0x94a version 0x111
+ # Supported Events:
+ # Event type 0 (EV_SYN)
+ # Event type 1 (EV_KEY)
+ # Event code 272 (BTN_LEFT)
+ # Event code 273 (BTN_RIGHT)
+ # Event code 274 (BTN_MIDDLE)
+ # Event type 2 (EV_REL)
+ # Event code 0 (REL_X)
+ # Event code 1 (REL_Y)
+ # Event code 8 (REL_WHEEL)
+ # Event code 11 (REL_WHEEL_HI_RES)
+ # Event type 4 (EV_MSC)
+ # Event code 4 (MSC_SCAN)
+ # Properties:
+ name: "PixArt HP USB Optical Mouse"
+ id: [3, 1008, 2378, 273]
+ codes:
+ 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN
+ 1: [272, 273, 274] # EV_KEY
+ 2: [0, 1, 8, 11] # EV_REL
+ 4: [4] # EV_MSC
+ properties: []
+ hid: [
+ 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01, 0x09, 0x01, 0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
+ 0x15, 0x00, 0x25, 0x01, 0x95, 0x08, 0x75, 0x01, 0x81, 0x02, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31,
+ 0x09, 0x38, 0x15, 0x81, 0x25, 0x7f, 0x75, 0x08, 0x95, 0x03, 0x81, 0x06, 0xc0, 0xc0
+ ]
+ udev:
+ properties:
+ - ID_INPUT=1
+ - ID_INPUT_MOUSE=1
+ - LIBINPUT_DEVICE_GROUP=3/3f0/94a:usb-0000:05:00.3-2
+ quirks:
+ events:
+ # Current time is 12:31:56
+ - evdev:
+ - [ 0, 0, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 0, 0, 1, 272, 1] # EV_KEY / BTN_LEFT 1
+ - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
+ - evdev:
+ - [ 1, 207892, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 1, 207892, 1, 273, 1] # EV_KEY / BTN_RIGHT 1
+ - [ 1, 207892, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1207ms
+ - evdev:
+ - [ 2, 367823, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 2, 367823, 1, 272, 0] # EV_KEY / BTN_LEFT 0
+ - [ 2, 367823, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1160ms
+ # Current time is 12:32:00
+ - evdev:
+ - [ 3, 247617, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
+ - [ 3, 247617, 1, 273, 0] # EV_KEY / BTN_RIGHT 0
+ - [ 3, 247617, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +880ms
+
+Note: if ``libinput record`` is not available on your system try using
+``evemu-record``.
+
+When something does not work
+============================
+
+There can be a number of reasons why a device does not behave
+correctly. For example
+
+* The HID report descriptor provided by the HID device may be wrong
+ because e.g.
+
+ * it does not follow the standard, so that the kernel
+ will not able to make sense of the HID report descriptor;
+ * the HID report descriptor *does not match* what is actually
+ sent by the device (this can be verified by reading the raw HID
+ data);
+* the HID report descriptor may need some "quirks" (see later on).
+
+As a consequence, a ``/dev/input/event*`` may not be created
+for each Application Collection, and/or the events
+there may not match what you would expect.
+
+
+Quirks
+------
+
+There are some known peculiarities of HID devices that the kernel
+knows how to fix - these are called the HID quirks and a list of those
+is available in `include/linux/hid.h`.
+
+Should this be the case, it should be enough to add the required quirk
+in the kernel, for the HID device at hand. This can be done in the file
+`drivers/hid/hid-quirks.c`. How to do it should be relatively
+straightforward after looking into the file.
+
+The list of currently defined quirks, from `include/linux/hid.h`, is
+
+.. kernel-doc:: include/linux/hid.h
+ :doc: HID quirks
+
+Quirks for USB devices can be specified while loading the usbhid module,
+see ``modinfo usbhid``, although the proper fix should go into
+hid-quirks.c and **be submitted upstream**.
+See Documentation/process/submitting-patches.rst for guidelines on how
+to submit a patch. Quirks for other busses need to go into hid-quirks.c.
+
+Fixing HID report descriptors
+-----------------------------
+
+Should you need to patch HID report descriptors the easiest way is to
+resort to eBPF, as described in Documentation/hid/hid-bpf.rst.
+
+Basically, you can change any byte of the original HID report
+descriptor. The examples in samples/hid should be a good starting point
+for your code, see e.g. `samples/hid/hid_mouse.bpf.c`::
+
+ SEC("fmod_ret/hid_bpf_rdesc_fixup")
+ int BPF_PROG(hid_rdesc_fixup, struct hid_bpf_ctx *hctx)
+ {
+ ....
+ data[39] = 0x31;
+ data[41] = 0x30;
+ return 0;
+ }
+
+Of course this can be also done within the kernel source code, see e.g.
+`drivers/hid/hid-aureal.c` or `drivers/hid/hid-samsung.c` for a slightly
+more complex file.
+
+Check Documentation/hid/hidreport-parsing.rst if you need any help
+navigating the HID manuals and understanding the exact meaning of
+the HID report descriptor hex numbers.
+
+Whatever solution you come up with, please remember to **submit the
+fix to the HID maintainers**, so that it can be directly integrated in
+the kernel and that particular HID device will start working for
+everyone else. See Documentation/process/submitting-patches.rst for
+guidelines on how to do this.
+
+
+Modifying the transmitted data on the fly
+-----------------------------------------
+
+Using eBPF it is also possible to modify the data exchanged with the
+device. See again the examples in `samples/hid`.
+
+Again, **please post your fix**, so that it can be integrated in the
+kernel!
+
+Writing a specialized driver
+----------------------------
+
+This should really be your last resort.
+
+
+.. rubric:: Footnotes
+
+.. [#hidraw] read hidraw: see Documentation/hid/hidraw.rst and
+ file `samples/hidraw/hid-example.c` for an example.
+ The output of ``hid-example`` would be, for the same mouse::
+
+ $ sudo ./hid-example
+ Report Descriptor Size: 52
+ Report Descriptor:
+ 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 25 1 75 1 95 3 81 2 75 5 95 1 81 1 5 1 9 30 9 31 9 38 15 81 25 7f 75 8 95 3 81 6 c0 c0
+
+ Raw Name: PixArt USB Optical Mouse
+ Raw Phys: usb-0000:05:00.4-2.3/input0
+ Raw Info:
+ bustype: 3 (USB)
+ vendor: 0x093a
+ product: 0x2510
+ ...
diff --git a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst
index b717ee5cdaef..14d076753b85 100644
--- a/Documentation/hid/hidraw.rst
+++ b/Documentation/hid/hidraw.rst
@@ -163,7 +163,7 @@ HIDIOCGOUTPUT(len):
Get an Output Report
This ioctl will request an output report from the device using the control
-endpoint. Typically, this is used to retrive the initial state of
+endpoint. Typically, this is used to retrieve the initial state of
an output report of a device, before an application updates it as necessary either
via a HIDIOCSOUTPUT request, or the regular device write() interface. The format
of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
diff --git a/Documentation/hid/hidreport-parsing.rst b/Documentation/hid/hidreport-parsing.rst
new file mode 100644
index 000000000000..1d3c17f29f2b
--- /dev/null
+++ b/Documentation/hid/hidreport-parsing.rst
@@ -0,0 +1,49 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+========================================
+Manual parsing of HID report descriptors
+========================================
+
+Consider again the mouse HID report descriptor
+introduced in Documentation/hid/hidintro.rst::
+
+ $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
+ 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
+ 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
+ 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
+ 00000030 81 06 c0 c0 |....|
+ 00000034
+
+and try to parse it by hand.
+
+Start with the first number, 0x05: it carries 2 bits for the
+length of the item, 2 bits for the type of the item and 4 bits for the
+function::
+
+ +----------+
+ | 00000101 |
+ +----------+
+ ^^
+ ---- Length of data (see HID spec 6.2.2.2)
+ ^^
+ ------ Type of the item (see HID spec 6.2.2.2, then jump to 6.2.2.7)
+ ^^^^
+ --------- Function of the item (see HID spec 6.2.2.7, then HUT Sec 3)
+
+In our case, the length is 1 byte, the type is ``Global`` and the
+function is ``Usage Page``, thus for parsing the value 0x01 in the second byte
+we need to refer to HUT Sec 3.
+
+The second number is the actual data, and its meaning can be found in
+the HUT. We have a ``Usage Page``, thus we need to refer to HUT
+Sec. 3, "Usage Pages"; from there, one sees that ``0x01`` stands for
+``Generic Desktop Page``.
+
+Moving now to the second two bytes, and following the same scheme,
+``0x09`` (i.e. ``00001001``) will be followed by one byte (``01``)
+and is a ``Local`` item (``10``). Thus, the meaning of the remaining four bits
+(``0000``) is given in the HID spec Sec. 6.2.2.8 "Local Items", so that
+we have a ``Usage``. From HUT, Sec. 4, "Generic Desktop Page", we see that
+0x02 stands for ``Mouse``.
+
+The following numbers can be parsed in the same way.
diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst
index e50f513c579c..baf156b44b58 100644
--- a/Documentation/hid/index.rst
+++ b/Documentation/hid/index.rst
@@ -7,13 +7,16 @@ Human Interface Devices (HID)
.. toctree::
:maxdepth: 1
+ hidintro
hiddev
hidraw
hid-sensor
hid-transport
+ hid-bpf
uhid
hid-alps
intel-ish-hid
+ intel-thc-hid
amd-sfh-hid
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 7a851252267a..2adc174fb576 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -18,8 +18,8 @@ These ISH also comply to HID sensor specification, but the difference is the
transport protocol used for communication. The current external sensor hubs
mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
-1. Overview
-===========
+Overview
+========
Using a analogy with a usbhid implementation, the ISH follows a similar model
for a very high speed communication::
@@ -58,8 +58,8 @@ implemented as a bus. Each client application executing in the ISH processor
is registered as a device on this bus. The driver, which binds each device
(ISH HID driver) identifies the device type and registers with the HID core.
-2. ISH Implementation: Block Diagram
-====================================
+ISH Implementation: Block Diagram
+=================================
::
@@ -96,27 +96,27 @@ is registered as a device on this bus. The driver, which binds each device
| ISH Hardware/Firmware(FW) |
----------------------------
-3. High level processing in above blocks
-========================================
+High level processing in above blocks
+=====================================
-3.1 Hardware Interface
-----------------------
+Hardware Interface
+------------------
The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI
product and vendor IDs are changed from different generations of processors. So
the source code which enumerates drivers needs to update from generation to
generation.
-3.2 Inter Processor Communication (IPC) driver
-----------------------------------------------
+Inter Processor Communication (IPC) driver
+------------------------------------------
Location: drivers/hid/intel-ish-hid/ipc
The IPC message uses memory mapped I/O. The registers are defined in
hw-ish-regs.h.
-3.2.1 IPC/FW message types
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+IPC/FW message types
+^^^^^^^^^^^^^^^^^^^^
There are two types of messages, one for management of link and another for
messages to and from transport layers.
@@ -142,20 +142,20 @@ register has the following format::
Bit 31: doorbell trigger (signal H/W interrupt to the other side)
Other bits are reserved, should be 0.
-3.2.2 Transport layer interface
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Transport layer interface
+^^^^^^^^^^^^^^^^^^^^^^^^^
To abstract HW level IPC communication, a set of callbacks is registered.
The transport layer uses them to send and receive messages.
Refer to struct ishtp_hw_ops for callbacks.
-3.3 ISH Transport layer
------------------------
+ISH Transport layer
+-------------------
Location: drivers/hid/intel-ish-hid/ishtp/
-3.3.1 A Generic Transport Layer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A Generic Transport Layer
+^^^^^^^^^^^^^^^^^^^^^^^^^
The transport layer is a bi-directional protocol, which defines:
- Set of commands to start, stop, connect, disconnect and flow control
@@ -166,8 +166,8 @@ This protocol resembles bus messages described in the following document:
http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer"
-3.3.2 Connection and Flow Control Mechanism
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Connection and Flow Control Mechanism
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Each FW client and a protocol is identified by a UUID. In order to communicate
to a FW client, a connection must be established using connect request and
@@ -181,8 +181,8 @@ before receiving the next flow control credit.
Either side can send disconnect request bus message to end communication. Also
the link will be dropped if major FW reset occurs.
-3.3.3 Peer to Peer data transfer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Peer to Peer data transfer
+^^^^^^^^^^^^^^^^^^^^^^^^^^
Peer to Peer data transfer can happen with or without using DMA. Depending on
the sensor bandwidth requirement DMA can be enabled by using module parameter
@@ -199,7 +199,7 @@ the sender that the memory region for that message may be reused.
DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message
(that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK.
Additionally to DMA address communication, this sequence checks capabilities:
-if thw host doesn't support DMA, then it won't send DMA allocation, so FW can't
+if the host doesn't support DMA, then it won't send DMA allocation, so FW can't
send DMA; if FW doesn't support DMA then it won't respond with
DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers.
Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER,
@@ -217,8 +217,8 @@ In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once
Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC
fragments and via IPC otherwise.
-3.3.4 Ring Buffers
-^^^^^^^^^^^^^^^^^^
+Ring Buffers
+^^^^^^^^^^^^
When a client initiates a connection, a ring of RX and TX buffers is allocated.
The size of ring can be specified by the client. HID client sets 16 and 32 for
@@ -228,8 +228,8 @@ bus message protocol. These buffers are required because the FW may have not
have processed the last message and may not have enough flow control credits
to send. Same thing holds true on receive side and flow control is required.
-3.3.5 Host Enumeration
-^^^^^^^^^^^^^^^^^^^^^^
+Host Enumeration
+^^^^^^^^^^^^^^^^
The host enumeration bus command allows discovery of clients present in the FW.
There can be multiple sensor clients and clients for calibration function.
@@ -252,8 +252,8 @@ Enumeration sequence of messages:
- Once host received properties for that last discovered client, it considers
ISHTP device fully functional (and allocates DMA buffers)
-3.4 HID over ISH Client
------------------------
+HID over ISH Client
+-------------------
Location: drivers/hid/intel-ish-hid
@@ -265,16 +265,16 @@ The ISHTP client driver is responsible for:
- Process Get/Set feature request
- Get input reports
-3.5 HID Sensor Hub MFD and IIO sensor drivers
----------------------------------------------
+HID Sensor Hub MFD and IIO sensor drivers
+-----------------------------------------
The functionality in these drivers is the same as an external sensor hub.
Refer to
Documentation/hid/hid-sensor.rst for HID sensor
Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space.
-3.6 End to End HID transport Sequence Diagram
----------------------------------------------
+End to End HID transport Sequence Diagram
+-----------------------------------------
::
@@ -339,16 +339,110 @@ Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space.
| | | |
-3.7 ISH Debugging
------------------
+ISH Firmware Loading from Host Flow
+-----------------------------------
+
+Starting from the Lunar Lake generation, the ISH firmware has been divided into two components for better space optimization and increased flexibility. These components include a bootloader that is integrated into the BIOS, and a main firmware that is stored within the operating system's file system.
+
+The process works as follows:
+
+- Initially, the ISHTP driver sends a command, HOST_START_REQ_CMD, to the ISH bootloader. In response, the bootloader sends back a HOST_START_RES_CMD. This response includes the ISHTP_SUPPORT_CAP_LOADER bit. Subsequently, the ISHTP driver checks if this bit is set. If it is, the firmware loading process from the host begins.
+
+- During this process, the ISHTP driver first invokes the request_firmware() function, followed by sending a LOADER_CMD_XFER_QUERY command. Upon receiving a response from the bootloader, the ISHTP driver sends a LOADER_CMD_XFER_FRAGMENT command. After receiving another response, the ISHTP driver sends a LOADER_CMD_START command. The bootloader responds and then proceeds to the Main Firmware.
+
+- After the process concludes, the ISHTP driver calls the release_firmware() function.
+
+For more detailed information, please refer to the flow descriptions provided below:
+
+::
+
+ +---------------+ +-----------------+
+ | ISHTP Driver | | ISH Bootloader |
+ +---------------+ +-----------------+
+ | |
+ |~~~Send HOST_START_REQ_CMD~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send HOST_START_RES_CMD(Includes ISHTP_SUPPORT_CAP_LOADER bit)----|
+ | |
+ ****************************************************************************************
+ * if ISHTP_SUPPORT_CAP_LOADER bit is set *
+ ****************************************************************************************
+ | |
+ |~~~start loading firmware from host process~~~+ |
+ | | |
+ |<---------------------------------------------+ |
+ | |
+ --------------------------- |
+ | Call request_firmware() | |
+ --------------------------- |
+ | |
+ |~~~Send LOADER_CMD_XFER_QUERY~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send response-----------------------------------------------------|
+ | |
+ |~~~Send LOADER_CMD_XFER_FRAGMENT~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send response-----------------------------------------------------|
+ | |
+ |~~~Send LOADER_CMD_START~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send response-----------------------------------------------------|
+ | |
+ | |~~~Jump to Main Firmware~~~+
+ | | |
+ | |<--------------------------+
+ | |
+ --------------------------- |
+ | Call release_firmware() | |
+ --------------------------- |
+ | |
+ ****************************************************************************************
+ * end if *
+ ****************************************************************************************
+ | |
+ +---------------+ +-----------------+
+ | ISHTP Driver | | ISH Bootloader |
+ +---------------+ +-----------------+
+
+Vendor Custom Firmware Loading
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The firmware running inside ISH can be provided by Intel or developed by vendors using the Firmware Development Kit (FDK) provided by Intel.
+Intel will upstream the Intel-built firmware to the ``linux-firmware.git`` repository, located under the path ``intel/ish/``. For the Lunar Lake platform, the Intel-built ISH firmware will be named ``ish_lnlm.bin``.
+Vendors who wish to upstream their custom firmware should follow these guidelines for naming their firmware files:
+
+- The firmware filename should use one of the following patterns:
+
+ - ``ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}_${PRODUCT_NAME_CRC32}_${PRODUCT_SKU_CRC32}.bin``
+ - ``ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}_${PRODUCT_SKU_CRC32}.bin``
+ - ``ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}_${PRODUCT_NAME_CRC32}.bin``
+ - ``ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}.bin``
+
+- ``${intel_plat_gen}`` indicates the Intel platform generation (e.g., ``lnlm`` for Lunar Lake) and must not exceed 8 characters in length.
+- ``${SYS_VENDOR_CRC32}`` is the CRC32 checksum of the ``sys_vendor`` value from the DMI field ``DMI_SYS_VENDOR``.
+- ``${PRODUCT_NAME_CRC32}`` is the CRC32 checksum of the ``product_name`` value from the DMI field ``DMI_PRODUCT_NAME``.
+- ``${PRODUCT_SKU_CRC32}`` is the CRC32 checksum of the ``product_sku`` value from the DMI field ``DMI_PRODUCT_SKU``.
+
+During system boot, the ISH Linux driver will attempt to load the firmware in the following order, prioritizing custom firmware with more precise matching patterns:
+
+1. ``intel/ish/ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}_${PRODUCT_NAME_CRC32}_${PRODUCT_SKU_CRC32}.bin``
+2. ``intel/ish/ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}_${PRODUCT_SKU_CRC32}.bin``
+3. ``intel/ish/ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}_${PRODUCT_NAME_CRC32}.bin``
+4. ``intel/ish/ish_${intel_plat_gen}_${SYS_VENDOR_CRC32}.bin``
+5. ``intel/ish/ish_${intel_plat_gen}.bin``
+
+The driver will load the first matching firmware and skip the rest. If no matching firmware is found, it will proceed to the next pattern in the specified order. If all searches fail, the default Intel firmware, listed last in the order above, will be loaded.
+
+ISH Debugging
+-------------
To debug ISH, event tracing mechanism is used. To enable debug logs::
- echo 1 > /sys/kernel/debug/tracing/events/intel_ish/enable
- cat /sys/kernel/debug/tracing/trace
+ echo 1 > /sys/kernel/tracing/events/intel_ish/enable
+ cat /sys/kernel/tracing/trace
-3.8 ISH IIO sysfs Example on Lenovo thinkpad Yoga 260
------------------------------------------------------
+ISH IIO sysfs Example on Lenovo thinkpad Yoga 260
+-------------------------------------------------
::
diff --git a/Documentation/hid/intel-thc-hid.rst b/Documentation/hid/intel-thc-hid.rst
new file mode 100644
index 000000000000..8b378c57b5aa
--- /dev/null
+++ b/Documentation/hid/intel-thc-hid.rst
@@ -0,0 +1,596 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================
+Intel Touch Host Controller (THC)
+=================================
+
+Touch Host Controller is the name of the IP block in PCH that interface with Touch Devices (ex:
+touchscreen, touchpad etc.). It is comprised of 3 key functional blocks:
+
+- A natively half-duplex Quad I/O capable SPI master
+- Low latency I2C interface to support HIDI2C compliant devices
+- A HW sequencer with RW DMA capability to system memory
+
+It has a single root space IOSF Primary interface that supports transactions to/from touch devices.
+Host driver configures and controls the touch devices over THC interface. THC provides high
+bandwidth DMA services to the touch driver and transfers the HID report to host system main memory.
+
+Hardware sequencer within the THC is responsible for transferring (via DMA) data from touch devices
+into system memory. A ring buffer is used to avoid data loss due to asynchronous nature of data
+consumption (by host) in relation to data production (by touch device via DMA).
+
+Unlike other common SPI/I2C controllers, THC handles the HID device data interrupt and reset
+signals directly.
+
+1. Overview
+===========
+
+1.1 THC software/hardware stack
+-------------------------------
+
+Below diagram illustrates the high-level architecture of THC software/hardware stack, which is fully
+capable of supporting HIDSPI/HIDI2C protocol in Linux OS.
+
+::
+
+ ----------------------------------------------
+ | +-----------------------------------+ |
+ | | Input Device | |
+ | +-----------------------------------+ |
+ | +-----------------------------------+ |
+ | | HID Multi-touch Driver | |
+ | +-----------------------------------+ |
+ | +-----------------------------------+ |
+ | | HID Core | |
+ | +-----------------------------------+ |
+ | +-----------------------------------+ |
+ | | THC QuickSPI/QuickI2C Driver | |
+ | +-----------------------------------+ |
+ | +-----------------------------------+ |
+ | | THC Hardware Driver | |
+ | +-----------------------------------+ |
+ | +----------------+ +----------------+ |
+ | SW | PCI Bus Driver | | ACPI Resource | |
+ | +----------------+ +----------------+ |
+ ----------------------------------------------
+ ----------------------------------------------
+ | +-----------------------------------+ |
+ | HW | PCI Bus | |
+ | +-----------------------------------+ |
+ | +-----------------------------------+ |
+ | | THC Controller | |
+ | +-----------------------------------+ |
+ | +-----------------------------------+ |
+ | | Touch IC | |
+ | +-----------------------------------+ |
+ ----------------------------------------------
+
+Touch IC (TIC), also as known as the Touch devices (touchscreen or touchpad). The discrete analog
+components that sense and transfer either discrete touch data or heatmap data in the form of HID
+reports over the SPI/I2C bus to the THC Controller on the host.
+
+THC Host Controller, which is a PCI device HBA (host bus adapter), integrated into the PCH, that
+serves as a bridge between the Touch ICs and the host.
+
+THC Hardware Driver, provides THC hardware operation APIs for above QuickSPI/QuickI2C driver, it
+accesses THC MMIO registers to configure and control THC hardware.
+
+THC QuickSPI/QuickI2C driver, also as known as HIDSPI/HIDI2C driver, is registered as a HID
+low-level driver that manages the THC Controller and implements HIDSPI/HIDI2C protocol.
+
+
+1.2 THC hardware diagram
+------------------------
+Below diagram shows THC hardware components::
+
+ ---------------------------------
+ | THC Controller |
+ | +---------------------------+ |
+ | | PCI Config Space | |
+ | +---------------------------+ |
+ | +---------------------------+ |
+ | + MMIO Registers | |
+ | +---------------------------+ |
+ +---------------+ | +------------+ +------------+ |
+ | System Memory +---+--+ DMA | | PIO | |
+ +---------------+ | +------------+ +------------+ |
+ | +---------------------------+ |
+ | | HW Sequencer | |
+ | +---------------------------+ |
+ | +------------+ +------------+ |
+ | | SPI/I2C | | GPIO | |
+ | | Controller | | Controller | |
+ | +------------+ +------------+ |
+ ---------------------------------
+
+As THC is exposed as a PCI devices, so it has standard PCI config space registers for PCI
+enumeration and configuration.
+
+MMIO Registers, which provide registers access for driver to configure and control THC hardware,
+the registers include several categories: Interrupt status and control, DMA configure,
+PIO (Programmed I/O, defined in section 3.2) status and control, SPI bus configure, I2C subIP
+status and control, reset status and control...
+
+THC provides two ways for driver to communicate with external Touch ICs: PIO and DMA.
+PIO can let driver manually write/read data to/from Touch ICs, instead, THC DMA can
+automatically write/read data without driver involved.
+
+HW Sequencer includes THC major logic, it gets instruction from MMIO registers to control
+SPI bus and I2C bus to finish a bus data transaction, it also can automatically handle
+Touch ICs interrupt and start DMA receive/send data from/to Touch ICs according to interrupt
+type. That means THC HW Sequencer understands HIDSPI/HIDI2C transfer protocol, and handle
+the communication without driver involved, what driver needs to do is just configure the THC
+properly, and prepare the formatted data packet or handle received data packet.
+
+As THC supports HIDSPI/HIDI2C protocols, it has SPI controller and I2C subIP in it to expose
+SPI bus and I2C bus. THC also integrates a GPIO controller to provide interrupt line support
+and reset line support.
+
+2. THC Hardware Interface
+=========================
+
+2.1 Host Interface
+------------------
+
+THC is exposed as "PCI Digitizer device" to the host. The PCI product and device IDs are
+changed from different generations of processors. So the source code which enumerates drivers
+needs to update from generation to generation.
+
+
+2.2 Device Interface
+--------------------
+
+THC supports two types of bus for Touch IC connection: Enhanced SPI bus and I2C bus.
+
+2.2.1 SPI Port
+~~~~~~~~~~~~~~
+
+When PORT_TYPE = 00b in MMIO registers, THC uses SPI interfaces to communicate with external
+Touch IC. THC enhanced SPI Bus supports different SPI modes: standard Single IO mode,
+Dual IO mode and Quad IO mode.
+
+In Single IO mode, THC drives MOSI line to send data to Touch ICs, and receives data from Touch
+ICs data from MISO line. In Dual IO mode, THC drivers MOSI and MISO both for data sending, and
+also receives the data on both line. In Quad IO mode, there are other two lines (IO2 and IO3)
+are added, THC drives MOSI (IO0), MISO (IO1), IO2 and IO3 at the same time for data sending, and
+also receives the data on those 4 lines. Driver needs to configure THC in different mode by
+setting different opcode.
+
+Beside IO mode, driver also needs to configure SPI bus speed. THC supports up to 42MHz SPI clock
+on Intel Lunar Lake platform.
+
+For THC sending data to Touch IC, the data flow on SPI bus::
+
+ | --------------------THC sends---------------------------------|
+ <8Bits OPCode><24Bits Slave Address><Data><Data><Data>...........
+
+For THC receiving data from Touch IC, the data flow on SPI bus::
+
+ | ---------THC Sends---------------||-----Touch IC sends--------|
+ <8Bits OPCode><24Bits Slave Address><Data><Data><Data>...........
+
+2.2.2 I2C Port
+~~~~~~~~~~~~~~
+
+THC also integrates I2C controller in it, it's called I2C SubSystem. When PORT_TYPE = 01, THC
+is configured to I2C mode. Comparing to SPI mode which can be configured through MMIO registers
+directly, THC needs to use PIO read (by setting SubIP read opcode) to I2C subIP APB registers'
+value and use PIO write (by setting SubIP write opcode) to do a write operation.
+
+2.2.3 GPIO interface
+~~~~~~~~~~~~~~~~~~~~
+
+THC also includes two GPIO pins, one for interrupt and the other for device reset control.
+
+Interrupt line can be configured to either level triggered or edge triggered by setting MMIO
+Control register.
+
+Reset line is controlled by BIOS (or EFI) through ACPI _RST method, driver needs to call this
+device ACPI _RST method to reset touch IC during initialization.
+
+2.3 Max input size control
+--------------------------
+
+This is a new feature introduced in Panther Lake platform, THC hardware allows driver to set
+a max input size for RxDMA. After this max size gets set and enabled, for every input report
+packet reading, THC hardware sequencer will first read incoming input packet size, then compare
+input packet size with the given max size:
+
+- if input packet size <= max size, THC continues using input packet size to finish the reading
+- if input packet size > max size, there is potential input data crash risk during
+ transferring, THC will use max size instead of input packet size for reading
+
+This feature is used to avoid data corruption which will cause RxDMA buffer overrun issue for
+I2C bus, and enhance whole system stability.
+
+2.4 Interrupt delay
+-------------------
+
+Because of MCU performance limitation, some touch devices cannot de-assert interrupt pin
+immediately after input data is transferred, which cause an interrupt toggle delay. But THC
+always detects next interrupt immediately after last input interrupt is handled. In this
+case, the delayed interrupt de-assertion will be recognized as a new interrupt signal by THC,
+and causes THC to start an input report reading spuriously.
+
+In order to avoid this situation, THC introduced interrupt delay new feature in Panther Lake
+platform, where THC allows driver to set an interrupt delay. After this feature is enabled,
+THC will delay this given time for next interrupt detection.
+
+3. High level concept
+=====================
+
+3.1 Opcode
+----------
+
+Opcode (operation code) is used to tell THC or Touch IC what the operation will be, such as PIO
+read or PIO write.
+
+When THC is configured to SPI mode, opcodes are used for determining the read/write IO mode.
+There are some OPCode examples for SPI IO mode:
+
+======= ==============================
+opcode Corresponding SPI command
+======= ==============================
+0x0B Read Single I/O
+0x02 Write Single I/O
+0xBB Read Dual I/O
+0xB2 Write Dual I/O
+0xEB Read Quad I/O
+0xE2 Write Quad I/O
+======= ==============================
+
+In general, different touch IC has different OPCode definition. According to HIDSPI
+protocol whitepaper, those OPCodes are defined in device ACPI table, and driver needs to
+query those information through OS ACPI APIs during driver initialization, then configures
+THC MMIO OPCode registers with correct setting.
+
+When THC is working in I2C mode, opcodes are used to tell THC what's the next PIO type:
+I2C SubIP APB register read, I2C SubIP APB register write, I2C touch IC device read,
+I2C touch IC device write, I2C touch IC device write followed by read.
+
+Here are the THC pre-defined opcodes for I2C mode:
+
+======= =================================================== ===========
+opcode Corresponding I2C command Address
+======= =================================================== ===========
+0x12 Read I2C SubIP APB internal registers 0h - FFh
+0x13 Write I2C SubIP APB internal registers 0h - FFh
+0x14 Read external Touch IC through I2C bus N/A
+0x18 Write external Touch IC through I2C bus N/A
+0x1C Write then read external Touch IC through I2C bus N/A
+======= =================================================== ===========
+
+3.2 PIO
+-------
+
+THC provides a programmed I/O (PIO) access interface for the driver to access the touch IC's
+configuration registers, or access I2C subIP's configuration registers. To use PIO to perform
+I/O operations, driver should pre-program PIO control registers and PIO data registers and kick
+off the sequencing cycle. THC uses different PIO opcodes to distinguish different PIO
+operations (PIO read/write/write followed by read).
+
+If there is a Sequencing Cycle In Progress and an attempt is made to program any of the control,
+address, or data register the cycle is blocked and a sequence error will be encountered.
+
+A status bit indicates when the cycle has completed allowing the driver to know when read results
+can be checked and/or when to initiate a new command. If enabled, the cycle done assertion can
+interrupt driver with an interrupt.
+
+Because THC only has 16 FIFO registers for PIO, so all the data transfer through PIO shouldn't
+exceed 64 bytes.
+
+As DMA needs max packet size for transferring configuration, and the max packet size information
+always in HID device descriptor which needs THC driver to read it out from HID Device (Touch IC).
+So PIO typical use case is, before DMA initialization, write RESET command (PIO write), read
+RESET response (PIO read or PIO write followed by read), write Power ON command (PIO write), read
+device descriptor (PIO read).
+
+For how to issue a PIO operation, here is the steps which driver needs follow:
+
+- Program read/write data size in THC_SS_BC.
+- Program I/O target address in THC_SW_SEQ_DATA0_ADDR.
+- If write, program the write data in THC_SW_SEQ_DATA0..THC_SW_SEQ_DATAn.
+- Program the PIO opcode in THC_SS_CMD.
+- Set TSSGO = 1 to start the PIO write sequence.
+- If THC_SS_CD_IE = 1, SW will receives a MSI when the PIO is completed.
+- If read, read out the data in THC_SW_SEQ_DATA0..THC_SW_SEQ_DATAn.
+
+3.3 DMA
+-------
+
+THC has 4 DMA channels: Read DMA1, Read DMA2, Write DMA and Software DMA.
+
+3.3.1 Read DMA Channel
+~~~~~~~~~~~~~~~~~~~~~~
+
+THC has two Read DMA engines: 1st RxDMA (RxDMA1) and 2nd RxDMA (RxDMA2). RxDMA1 is reserved for
+raw data mode. RxDMA2 is used for HID data mode and it is the RxDMA engine currently driver uses
+for HID input report data retrieval.
+
+RxDMA's typical use case is auto receiving the data from Touch IC. Once RxDMA is enabled by
+software, THC will start auto-handling receiving logic.
+
+For SPI mode, THC RxDMA sequence is: when Touch IC triggers a interrupt to THC, THC reads out
+report header to identify what's the report type, and what's the report length, according to
+above information, THC reads out report body to internal FIFO and start RxDMA coping the data
+to system memory. After that, THC update interrupt cause register with report type, and update
+RxDMA PRD table read pointer, then trigger a MSI interrupt to notify driver RxDMA finishing
+data receiving.
+
+For I2C mode, THC RxDMA's behavior is a little bit different, because of HIDI2C protocol difference
+with HIDSPI protocol, RxDMA only be used to receive input report. The sequence is, when Touch IC
+triggers a interrupt to THC, THC first reads out 2 bytes from input report address to determine the
+packet length, then use this packet length to start a DMA reading from input report address for
+input report data. After that, THC update RxDMA PRD table read pointer, then trigger a MSI interrupt
+to notify driver input report data is ready in system memory.
+
+All above sequence is hardware automatically handled, all driver needs to do is configure RxDMA and
+waiting for interrupt ready then read out the data from system memory.
+
+3.3.2 Software DMA channel
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+THC supports a software triggered RxDMA mode to read the touch data from touch IC. This SW RxDMA
+is the 3rd THC RxDMA engine with the similar functionalities as the existing two RxDMAs, the only
+difference is this SW RxDMA is triggered by software, and RxDMA2 is triggered by external Touch IC
+interrupt. It gives a flexibility to software driver to use RxDMA read Touch IC data in any time.
+
+Before software starts a SW RxDMA, it shall stop the 1st and 2nd RxDMA, clear PRD read/write pointer
+and quiesce the device interrupt (THC_DEVINT_QUIESCE_HW_STS = 1), other operations are the same with
+RxDMA.
+
+3.3.3 Write DMA Channel
+~~~~~~~~~~~~~~~~~~~~~~~
+
+THC has one write DMA engine, which can be used for sending data to Touch IC automatically.
+According to HIDSPI and HIDI2C protocol, every time only one command can be sent to touch IC, and
+before last command is completely handled, next command cannot be sent, THC write DMA engine only
+supports single PRD table.
+
+What driver needs to do is, preparing PRD table and DMA buffer, then copy data to DMA buffer and
+update PRD table with buffer address and buffer length, then start write DMA. THC will
+automatically send the data to touch IC, and trigger a DMA completion interrupt once transferring
+is done.
+
+3.4 PRD
+-------
+
+Physical Region Descriptor (PRD) provides the memory mapping description for THC DMAs.
+
+3.4.1 PRD table and entry
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to improve physical DMA memory usage, modern drivers trend to allocate a virtually
+contiguous, but physically fragmented buffer of memory for each data buffer. Linux OS also
+provide SGL (scatter gather list) APIs to support this usage.
+
+THC uses PRD table (physical region descriptor) to support the corresponding OS kernel
+SGL that describes the virtual to physical buffer mapping.
+
+::
+
+ ------------------------ -------------- --------------
+ | PRD table base address +----+ PRD table #1 +-----+ PRD Entry #1 |
+ ------------------------ -------------- --------------
+ --------------
+ | PRD Entry #2 |
+ --------------
+ --------------
+ | PRD Entry #n |
+ --------------
+
+The read DMA engine supports multiple PRD tables held within a circular buffer that allow the THC
+to support multiple data buffers from the Touch IC. This allows host SW to arm the Read DMA engine
+with multiple buffers, allowing the Touch IC to send multiple data frames to the THC without SW
+interaction. This capability is required when the CPU processes touch frames slower than the
+Touch IC can send them.
+
+To simplify the design, SW assumes worst-case memory fragmentation. Therefore,each PRD table shall
+contain the same number of PRD entries, allowing for a global register (per Touch IC) to hold the
+number of PRD-entries per PRD table.
+
+SW allocates up to 128 PRD tables per Read DMA engine as specified in the THC_M_PRT_RPRD_CNTRL.PCD
+register field. The number of PRD tables should equal the number of data buffers.
+
+Max OS memory fragmentation will be at a 4KB boundary, thus to address 1MB of virtually contiguous
+memory 256 PRD entries are required for a single PRD Table. SW writes the number of PRD entries
+for each PRD table in the THC_M_PRT_RPRD_CNTRL.PTEC register field. The PRD entry's length must be
+multiple of 4KB except for the last entry in a PRD table.
+
+SW allocates all the data buffers and PRD tables only once at host initialization.
+
+3.4.2 PRD Write pointer and read pointer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As PRD tables are organized as a Circular Buffer (CB), a read pointer and a write pointer for a CB
+are needed.
+
+DMA HW consumes the PRD tables in the CB, one PRD entry at a time until the EOP bit is found set
+in a PRD entry. At this point HW increments the PRD read pointer. Thus, the read pointer points
+to the PRD which the DMA engine is currently processing. This pointer rolls over once the circular
+buffer's depth has been traversed with bit[7] the Rollover bit. E.g. if the DMA CB depth is equal
+to 4 entries (0011b), then the read pointers will follow this pattern (HW is required to honor
+this behavior): 00h 01h 02h 03h 80h 81h 82h 83h 00h 01h ...
+
+The write pointer is updated by SW. The write pointer points to location in the DMA CB, where the
+next PRD table is going to be stored. SW needs to ensure that this pointer rolls over once the
+circular buffer's depth has been traversed with Bit[7] as the rollover bit. E.g. if the DMA CB
+depth is equal to 5 entries (0100b), then the write pointers will follow this pattern (SW is
+required to honor this behavior): 00h 01h 02h 03h 04h 80h 81h 82h 83h 84h 00h 01h ..
+
+3.4.3 PRD descriptor structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Intel THC uses PRD entry descriptor for every PRD entry. Every PRD entry descriptor occupies
+128 bits memories:
+
+=================== ======== ===============================================
+struct field bit(s) description
+=================== ======== ===============================================
+dest_addr 53..0 destination memory address, as every entry
+ is 4KB, ignore lowest 10 bits of address.
+reserved1 54..62 reserved
+int_on_completion 63 completion interrupt enable bit, if this bit
+ set it means THC will trigger a completion
+ interrupt. This bit is set by SW driver.
+len 87..64 how many bytes of data in this entry.
+end_of_prd 88 end of PRD table bit, if this bit is set,
+ it means this entry is last entry in this PRD
+ table. This bit is set by SW driver.
+hw_status 90..89 HW status bits
+reserved2 127..91 reserved
+=================== ======== ===============================================
+
+And one PRD table can include up to 256 PRD entries, as every entries is 4K bytes, so every
+PRD table can describe 1M bytes memory.
+
+.. code-block:: c
+
+ struct thc_prd_table {
+ struct thc_prd_entry entries[PRD_ENTRIES_NUM];
+ };
+
+In general, every PRD table means one HID touch data packet. Every DMA engine can support
+up to 128 PRD tables (except write DMA, write DMA only has one PRD table). SW driver is responsible
+to get max packet length from touch IC, and use this max packet length to create PRD entries for
+each PRD table.
+
+4. HIDSPI support (QuickSPI)
+============================
+
+Intel THC is total compatible with HIDSPI protocol, THC HW sequenser can accelerate HIDSPI
+protocol transferring.
+
+4.1 Reset Flow
+--------------
+
+- Call ACPI _RST method to reset Touch IC device.
+- Read the reset response from TIC through PIO read.
+- Issue a command to retrieve device descriptor from Touch IC through PIO write.
+- Read the device descriptor from Touch IC through PIO read.
+- If the device descriptor is valid, allocate DMA buffers and configure all DMA channels.
+- Issue a command to retrieve report descriptor from Touch IC through DMA.
+
+4.2 Input Report Data Flow
+--------------------------
+
+Basic Flow:
+
+- Touch IC interrupts the THC Controller using an in-band THC interrupt.
+- THC Sequencer reads the input report header by transmitting read approval as a signal
+ to the Touch IC to prepare for host to read from the device.
+- THC Sequencer executes a Input Report Body Read operation corresponding to the value
+ reflected in “Input Report Length” field of the Input Report Header.
+- THC DMA engine begins fetching data from the THC Sequencer and writes to host memory
+ at PRD entry 0 for the current CB PRD table entry. This process continues until the
+ THC Sequencer signals all data has been read or the THC DMA Read Engine reaches the
+ end of it's last PRD entry (or both).
+- The THC Sequencer checks for the “Last Fragment Flag” bit in the Input Report Header.
+ If it is clear, the THC Sequencer enters an idle state.
+- If the “Last Fragment Flag” bit is enabled the THC Sequencer enters End-of-Frame Processing.
+
+THC Sequencer End of Frame Processing:
+
+- THC DMA engine increments the read pointer of the Read PRD CB, sets EOF interrupt status
+ in RxDMA2 register (THC_M_PRT_READ_DMA_INT_STS_2).
+- If THC EOF interrupt is enabled by the driver in the control register (THC_M_PRT_READ_DMA_CNTRL_2),
+ generates interrupt to software.
+
+Sequence of steps to read data from RX DMA buffer:
+
+- THC QuickSPI driver checks CB write Ptr and CB read Ptr to identify if any data frame in DMA
+ circular buffers.
+- THC QuickSPI driver gets first unprocessed PRD table.
+- THC QuickSPI driver scans all PRD entries in this PRD table to calculate the total frame size.
+- THC QuickSPI driver copies all frame data out.
+- THC QuickSPI driver checks the data type according to input report body, and calls related
+ callbacks to process the data.
+- THC QuickSPI driver updates write Ptr.
+
+4.3 Output Report Data Flow
+---------------------------
+
+Generic Output Report Flow:
+
+- HID core calls raw_request callback with a request to THC QuickSPI driver.
+- THC QuickSPI Driver converts request provided data into the output report packet and copies it
+ to THC's write DMA buffer.
+- Start TxDMA to complete the write operation.
+
+5. HIDI2C support (QuickI2C)
+============================
+
+5.1 Reset Flow
+--------------
+
+- Read device descriptor from Touch IC device through PIO write followed by read.
+- If the device descriptor is valid, allocate DMA buffers and configure all DMA channels.
+- Use PIO or TxDMA to write a SET_POWER request to TIC's command register, and check if the
+ write operation is successfully completed.
+- Use PIO or TxDMA to write a RESET request to TIC's command register. If the write operation
+ is successfully completed, wait for reset response from TIC.
+- Use SWDMA to read report descriptor through TIC's report descriptor register.
+
+5.2 Input Report Data Flow
+--------------------------
+
+Basic Flow:
+
+- Touch IC asserts the interrupt indicating that it has an interrupt to send to HOST.
+ THC Sequencer issues a READ request over the I2C bus. The HIDI2C device returns the
+ first 2 bytes from the HIDI2C device which contains the length of the received data.
+- THC Sequencer continues the Read operation as per the size of data indicated in the
+ length field.
+- THC DMA engine begins fetching data from the THC Sequencer and writes to host memory
+ at PRD entry 0 for the current CB PRD table entry. THC writes 2Bytes for length field
+ plus the remaining data to RxDMA buffer. This process continues until the THC Sequencer
+ signals all data has been read or the THC DMA Read Engine reaches the end of it's last
+ PRD entry (or both).
+- THC Sequencer enters End-of-Input Report Processing.
+- If the device has no more input reports to send to the host, it de-asserts the interrupt
+ line. For any additional input reports, device keeps the interrupt line asserted and
+ steps 1 through 4 in the flow are repeated.
+
+THC Sequencer End of Input Report Processing:
+
+- THC DMA engine increments the read pointer of the Read PRD CB, sets EOF interrupt status
+ in RxDMA 2 register (THC_M_PRT_READ_DMA_INT_STS_2).
+- If THC EOF interrupt is enabled by the driver in the control register
+ (THC_M_PRT_READ_DMA_CNTRL_2), generates interrupt to software.
+
+Sequence of steps to read data from RX DMA buffer:
+
+- THC QuickI2C driver checks CB write Ptr and CB read Ptr to identify if any data frame in DMA
+ circular buffers.
+- THC QuickI2C driver gets first unprocessed PRD table.
+- THC QuickI2C driver scans all PRD entries in this PRD table to calculate the total frame size.
+- THC QuickI2C driver copies all frame data out.
+- THC QuickI2C driver call hid_input_report to send the input report content to HID core, which
+ includes Report ID + Report Data Content (remove the length field from the original report
+ data).
+- THC QuickI2C driver updates write Ptr.
+
+5.3 Output Report Data Flow
+---------------------------
+
+Generic Output Report Flow:
+
+- HID core call THC QuickI2C raw_request callback.
+- THC QuickI2C uses PIO or TXDMA to write a SET_REPORT request to TIC's command register. Report
+ type in SET_REPORT should be set to Output.
+- THC QuickI2C programs TxDMA buffer with TX Data to be written to TIC's data register. The first
+ 2 bytes should indicate the length of the report followed by the report contents including
+ Report ID.
+
+6. THC Debugging
+================
+
+To debug THC, event tracing mechanism is used. To enable debug logs::
+
+ echo 1 > /sys/kernel/debug/tracing/events/intel_thc/enable
+ cat /sys/kernel/debug/tracing/trace
+
+7. Reference
+============
+- HIDSPI: https://download.microsoft.com/download/c/a/0/ca07aef3-3e10-4022-b1e9-c98cea99465d/HidSpiProtocolSpec.pdf
+- HIDI2C: https://download.microsoft.com/download/7/d/d/7dd44bb7-2a7a-4505-ac1c-7227d3d96d5b/hid-over-i2c-protocol-spec-v1-0.docx
diff --git a/Documentation/hwmon/abituguru-datasheet.rst b/Documentation/hwmon/abituguru-datasheet.rst
index 0cd61471d2a2..19ba4b4cd034 100644
--- a/Documentation/hwmon/abituguru-datasheet.rst
+++ b/Documentation/hwmon/abituguru-datasheet.rst
@@ -6,9 +6,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or
datasheet from Abit. The data I have got on uGuru have I assembled through
my weak knowledge in "backwards engineering".
And just for the record, you may have noticed uGuru isn't a chip developed by
-Abit, as they claim it to be. It's really just an microprocessor (uC) created by
+Abit, as they claim it to be. It's really just a microprocessor (uC) created by
Winbond (W83L950D). And no, reading the manual for this specific uC or
-mailing Windbond for help won't give any useful data about uGuru, as it is
+mailing Winbond for help won't give any useful data about uGuru, as it is
the program inside the uC that is responding to calls.
Olle Sandberg <ollebull@gmail.com>, 2005-05-25
@@ -35,7 +35,7 @@ As far as known the uGuru is always placed at and using the (ISA) I/O-ports
ports are holding for detection. We will refer to 0xE0 as CMD (command-port)
and 0xE4 as DATA because Abit refers to them with these names.
-If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be
+If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC a uGuru could be
present. We have to check for two different values at data-port, because
after a reboot uGuru will hold 0x00 here, but if the driver is removed and
later on attached again data-port will hold 0x08, more about this later.
@@ -46,7 +46,7 @@ have to test CMD for two different values. On these uGuru's DATA will initially
hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
first!
-To be really sure an uGuru is present a test read of one or more register
+To be really sure a uGuru is present a test read of one or more register
sets should be done.
diff --git a/Documentation/hwmon/abituguru.rst b/Documentation/hwmon/abituguru.rst
index cfda60b757ce..4a5ee16b1048 100644
--- a/Documentation/hwmon/abituguru.rst
+++ b/Documentation/hwmon/abituguru.rst
@@ -40,7 +40,7 @@ Supported chips:
.. [2] There is a separate abituguru3 driver for these motherboards,
the abituguru (without the 3 !) driver will not work on these
- motherboards (and visa versa)!
+ motherboards (and vice versa)!
Authors:
- Hans de Goede <j.w.r.degoede@hhs.nl>,
diff --git a/Documentation/hwmon/acbel-fsg032.rst b/Documentation/hwmon/acbel-fsg032.rst
new file mode 100644
index 000000000000..f1684b95e103
--- /dev/null
+++ b/Documentation/hwmon/acbel-fsg032.rst
@@ -0,0 +1,80 @@
+Kernel driver acbel-fsg032
+==========================
+
+Supported chips:
+
+ * ACBEL FSG032-00xG power supply.
+
+Author: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+
+Description
+-----------
+
+This driver supports ACBEL FSG032-00xG Power Supply. This driver
+is a client to the core PMBus driver.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
+details.
+
+Sysfs entries
+-------------
+
+The following attributes are supported:
+
+======================= ======================================================
+curr1_crit Critical maximum current.
+curr1_crit_alarm Input current critical alarm.
+curr1_input Measured output current.
+curr1_label "iin"
+curr1_max Maximum input current.
+curr1_max_alarm Maximum input current high alarm.
+curr1_rated_max Maximum rated input current.
+curr2_crit Critical maximum current.
+curr2_crit_alarm Output current critical alarm.
+curr2_input Measured output current.
+curr2_label "iout1"
+curr2_max Maximum output current.
+curr2_max_alarm Output current high alarm.
+curr2_rated_max Maximum rated output current.
+
+
+fan1_alarm Fan 1 warning.
+fan1_fault Fan 1 fault.
+fan1_input Fan 1 speed in RPM.
+fan1_target Set fan speed reference.
+
+in1_alarm Input voltage under-voltage alarm.
+in1_input Measured input voltage.
+in1_label "vin"
+in1_rated_max Maximum rated input voltage.
+in1_rated_min Minimum rated input voltage.
+in2_crit Critical maximum output voltage.
+in2_crit_alarm Output voltage critical high alarm.
+in2_input Measured output voltage.
+in2_label "vout1"
+in2_lcrit Critical minimum output voltage.
+in2_lcrit_alarm Output voltage critical low alarm.
+in2_rated_max Maximum rated output voltage.
+in2_rated_min Minimum rated output voltage.
+
+power1_alarm Input fault or alarm.
+power1_input Measured input power.
+power1_label "pin"
+power1_max Input power limit.
+power1_rated_max Maximum rated input power.
+power2_crit Critical output power limit.
+power2_crit_alarm Output power crit alarm limit exceeded.
+power2_input Measured output power.
+power2_label "pout"
+power2_max Output power limit.
+power2_max_alarm Output power high alarm.
+power2_rated_max Maximum rated output power.
+
+temp[1-3]_input Measured temperature.
+temp[1-2]_max Maximum temperature.
+temp[1-3]_rated_max Temperature high alarm.
+======================= ======================================================
diff --git a/Documentation/hwmon/acpi_power_meter.rst b/Documentation/hwmon/acpi_power_meter.rst
index 8628c1161015..a91403a2a26f 100644
--- a/Documentation/hwmon/acpi_power_meter.rst
+++ b/Documentation/hwmon/acpi_power_meter.rst
@@ -37,9 +37,16 @@ arbitrary strings that ACPI provides with the meter. The measures/ directory
contains symlinks to the devices that this meter measures.
Some computers have the ability to enforce a power cap in hardware. If this is
-the case, the `power[1-*]_cap` and related sysfs files will appear. When the
-average power consumption exceeds the cap, an ACPI event will be broadcast on
-the netlink event socket and a poll notification will be sent to the
+the case, the `power[1-*]_cap` and related sysfs files will appear.
+For information on enabling the power cap feature, refer to the description
+of the "force_on_cap" option in the "Module Parameters" chapter.
+To use the power cap feature properly, you need to set appropriate value
+(in microWatts) to the `power[1-*]_cap` sysfs files.
+The value must be within the range between the minimum value at `power[1-]_cap_min`
+and the maximum value at `power[1-]_cap_max (both in microWatts)`.
+
+When the average power consumption exceeds the cap, an ACPI event will be
+broadcast on the netlink event socket and a poll notification will be sent to the
appropriate `power[1-*]_alarm` file to indicate that capping has begun, and the
hardware has taken action to reduce power consumption. Most likely this will
result in reduced performance.
@@ -52,3 +59,19 @@ follows:
`power[1-*]_cap` will be notified if the firmware changes the power cap.
`power[1-*]_interval` will be notified if the firmware changes the averaging
interval.
+
+Module Parameters
+-----------------
+
+* force_cap_on: bool
+ Forcefully enable the power capping feature to specify
+ the upper limit of the system's power consumption.
+
+ By default, the driver's power capping feature is only
+ enabled on IBM products.
+ Therefore, on other systems that support power capping,
+ you will need to use the option to enable it.
+
+ Note: power capping is potentially unsafe feature.
+ Please check the platform specifications to make sure
+ that capping is supported before using this option.
diff --git a/Documentation/hwmon/adm1021.rst b/Documentation/hwmon/adm1021.rst
deleted file mode 100644
index 116fb2019956..000000000000
--- a/Documentation/hwmon/adm1021.rst
+++ /dev/null
@@ -1,153 +0,0 @@
-Kernel driver adm1021
-=====================
-
-Supported chips:
-
- * Analog Devices ADM1021
-
- Prefix: 'adm1021'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Analog Devices website
-
- * Analog Devices ADM1021A/ADM1023
-
- Prefix: 'adm1023'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Analog Devices website
-
- * Genesys Logic GL523SM
-
- Prefix: 'gl523sm'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet:
-
- * Maxim MAX1617
-
- Prefix: 'max1617'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Maxim website
-
- * Maxim MAX1617A
-
- Prefix: 'max1617a'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Maxim website
-
- * National Semiconductor LM84
-
- Prefix: 'lm84'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the National Semiconductor website
-
- * Philips NE1617
-
- Prefix: 'max1617' (probably detected as a max1617)
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Philips website
-
- * Philips NE1617A
-
- Prefix: 'max1617' (probably detected as a max1617)
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Philips website
-
- * TI THMC10
-
- Prefix: 'thmc10'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the TI website
-
- * Onsemi MC1066
-
- Prefix: 'mc1066'
-
- Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
-
- Datasheet: Publicly available at the Onsemi website
-
-
-Authors:
- - Frodo Looijaard <frodol@dds.nl>,
- - Philip Edelbrock <phil@netroedge.com>
-
-Module Parameters
------------------
-
-* read_only: int
- Don't set any values, read only mode
-
-
-Description
------------
-
-The chips supported by this driver are very similar. The Maxim MAX1617 is
-the oldest; it has the problem that it is not very well detectable. The
-MAX1617A solves that. The ADM1021 is a straight clone of the MAX1617A.
-Ditto for the THMC10. From here on, we will refer to all these chips as
-ADM1021-clones.
-
-The ADM1021 and MAX1617A reports a die code, which is a sort of revision
-code. This can help us pinpoint problems; it is not very useful
-otherwise.
-
-ADM1021-clones implement two temperature sensors. One of them is internal,
-and measures the temperature of the chip itself; the other is external and
-is realised in the form of a transistor-like device. A special alarm
-indicates whether the remote sensor is connected.
-
-Each sensor has its own low and high limits. When they are crossed, the
-corresponding alarm is set and remains on as long as the temperature stays
-out of range. Temperatures are measured in degrees Celsius. Measurements
-are possible between -65 and +127 degrees, with a resolution of one degree.
-
-If an alarm triggers, it will remain triggered until the hardware register
-is read at least once. This means that the cause for the alarm may already
-have disappeared!
-
-This driver only updates its values each 1.5 seconds; reading it more often
-will do no harm, but will return 'old' values. It is possible to make
-ADM1021-clones do faster measurements, but there is really no good reason
-for that.
-
-
-Netburst-based Xeon support
----------------------------
-
-Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
-2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
-within them, with two temperature sensors. Other Xeon processors of this
-era (with 400 MHz FSB) had chips with only one temperature sensor.
-
-If you have such an old Xeon, and you get two valid temperatures when
-loading the adm1021 module, then things are good.
-
-If nothing happens when loading the adm1021 module, and you are certain
-that your specific Xeon processor model includes compatible sensors, you
-will have to explicitly instantiate the sensor chips from user-space. See
-method 4 in Documentation/i2c/instantiating-devices.rst. Possible slave
-addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
-only temp2 will be correct and temp1 will have to be ignored.
-
-Previous generations of the Xeon processor (based on Pentium II/III)
-didn't have these sensors. Next generations of Xeon processors (533 MHz
-FSB and faster) lost them, until the Core-based generation which
-introduced integrated digital thermal sensors. These are supported by
-the coretemp driver.
diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst
index 804590eeabdc..cf923f20fa52 100644
--- a/Documentation/hwmon/adm1275.rst
+++ b/Documentation/hwmon/adm1275.rst
@@ -19,6 +19,14 @@ Supported chips:
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1272.pdf
+ * Analog Devices ADM1273
+
+ Prefix: 'adm1273'
+
+ Addresses scanned: -
+
+ Datasheet: Not yet publicly available
+
* Analog Devices ADM1275
Prefix: 'adm1275'
@@ -43,6 +51,14 @@ Supported chips:
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1278.pdf
+ * Analog Devices ADM1281
+
+ Prefix: 'adm1281'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/adm1281.pdf
+
* Analog Devices ADM1293/ADM1294
Prefix: 'adm1293', 'adm1294'
@@ -51,6 +67,14 @@ Supported chips:
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1293_1294.pdf
+ * Silergy SQ24905C
+
+ Prefix: 'mc09c'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.silergy.com/download/downloadFile?id=5669&type=product&ftype=note
+
Author: Guenter Roeck <linux@roeck-us.net>
@@ -58,14 +82,14 @@ Description
-----------
This driver supports hardware monitoring for Analog Devices ADM1075, ADM1272,
-ADM1275, ADM1276, ADM1278, ADM1293, and ADM1294 Hot-Swap Controller and
-Digital Power Monitors.
+ADM1273, ADM1275, ADM1276, ADM1278, ADM1281, ADM1293, ADM1294, and SQ24905C
+Hot-Swap Controller and Digital Power Monitors.
-ADM1075, ADM1272, ADM1275, ADM1276, ADM1278, ADM1293, and ADM1294 are hot-swap
-controllers that allow a circuit board to be removed from or inserted into
-a live backplane. They also feature current and voltage readback via an
-integrated 12 bit analog-to-digital converter (ADC), accessed using a
-PMBus interface.
+ADM1075, ADM1272, ADM1273, ADM1275, ADM1276, ADM1278, ADM1281, ADM1293,
+ADM1294 and SQ24905C are hot-swap controllers that allow a circuit board to be
+removed from or inserted into a live backplane. They also feature current and
+voltage readback via an integrated 12 bit analog-to-digital converter (ADC),
+accessed using a PMBus interface.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
@@ -133,7 +157,7 @@ power1_input_highest Highest observed input power.
power1_reset_history Write any value to reset history.
Power attributes are supported on ADM1075, ADM1272,
- ADM1276, ADM1293, and ADM1294.
+ ADM1273, ADM1276, ADM1293, and ADM1294.
temp1_input Chip temperature.
temp1_max Maximum chip temperature.
@@ -143,6 +167,6 @@ temp1_crit_alarm Critical temperature high alarm.
temp1_highest Highest observed temperature.
temp1_reset_history Write any value to reset history.
- Temperature attributes are supported on ADM1272 and
- ADM1278.
+ Temperature attributes are supported on ADM1272,
+ ADM1273, ADM1278, ADM1281 and SQ24905C.
======================= =======================================================
diff --git a/Documentation/hwmon/adp1050.rst b/Documentation/hwmon/adp1050.rst
new file mode 100644
index 000000000000..32514084fbdc
--- /dev/null
+++ b/Documentation/hwmon/adp1050.rst
@@ -0,0 +1,123 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver adp1050
+=====================
+
+Supported chips:
+
+ * Analog Devices ADP1050
+
+ Prefix: 'adp1050'
+
+ Addresses scanned: I2C 0x70 - 0x77
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADP1050.pdf
+
+ * Analog Devices ADP1051
+
+ Prefix: 'adp1051'
+
+ Addresses scanned: I2C 0x70 - 0x77
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADP1051.pdf
+
+ * Analog Devices ADP1055
+
+ Prefix: 'adp1055'
+
+ Addresses scanned: I2C 0x4B - 0x77
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADP1055.pdf
+
+ * Analog Devices LTP8800-1A/-2/-4A
+
+ Prefix: 'ltp8800'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/LTP8800-1A.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/LTP8800-2.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/LTP8800-4A.pdf
+
+Authors:
+
+ - Radu Sabau <radu.sabau@analog.com>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices ADP1050, ADP1051,
+and ADP1055 Digital Controller for Isolated Power Supply with PMBus interface,
+and the LTP8800 step-down μModule regulators.
+
+The ADP1050, ADP1051, and ADP1055 are advanced digital controllers with PMBus™
+interface targeting high density, high efficiency dc-to-dc power
+conversion used to monitor system temperatures, voltages and currents. The
+LTP8800 is a family of step-down μModule regulators that provides microprocessor
+core voltage from 54V power distribution architecture. Through the PMBus
+interface, the device can monitor input/output voltages, input current and
+temperature.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate
+the devices explicitly.
+Please see Documentation/i2c/instantiating-devices.rst for details.
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+Sysfs Attributes
+----------------
+
+================= ========================================
+in1_label "vin"
+in1_input Measured input voltage
+in1_alarm Input voltage alarm
+in1_crit Critical maximum input voltage
+in1_crit_alarm Input voltage high alarm
+in1_lcrit Critical minimum input voltage
+in1_lcrit_alarm Input voltage critical low alarm
+in2_label "vout1"
+in2_input Measured output voltage
+in2_crit Critical maximum output voltage
+in2_crit_alarm Output voltage high alarm
+in2_lcrit Critical minimum output voltage
+in2_lcrit_alarm Output voltage critical low alarm
+in2_max Critical maximum output voltage
+in2_max_alarm Output voltage critical max alarm
+in2_min Critical minimum output voltage
+in2_min_alarm Output voltage critical min alarm
+curr1_label "iin"
+curr1_input Measured input current.
+curr1_alarm Input current alarm
+curr1_crit Critical maximum input current
+curr1_crit_alarm Input current high alarm
+curr2_label "iout1"
+curr2_input Measured output current
+curr2_alarm Output current alarm
+curr2_crit Critical maximum output current
+curr2_crit_alarm Output current high alarm
+curr2_lcrit Critical minimum output current
+curr2_lcrit_alarm Output current critical low alarm
+curr2_max Critical maximum output current
+curr2_max_alarm Output current critical max alarm
+power1_label "pout1"
+power1_input Measured output power
+power1_crit Critical maximum output power
+power1_crit_alarm Output power high alarm
+temp1_input Measured temperature
+temp1_crit Critical high temperature
+temp1_crit_alarm Chip temperature critical high alarm
+temp1_max Critical maximum temperature
+temp1_max_alarm Temperature critical max alarm
+temp2_input Measured temperature
+temp2_crit Critical high temperature
+temp2_crit_alarm Chip temperature critical high alarm
+temp2_max Critical maximum temperature
+temp2_max_alarm Temperature critical max alarm
+================= ========================================
diff --git a/Documentation/hwmon/adt7475.rst b/Documentation/hwmon/adt7475.rst
index ef3ea1ea9bc1..f90f769d82d6 100644
--- a/Documentation/hwmon/adt7475.rst
+++ b/Documentation/hwmon/adt7475.rst
@@ -90,7 +90,7 @@ ADT7476:
ADT7490:
* 6 voltage inputs
- * 1 Imon input (not implemented)
+ * 1 Imon input
* PECI support (not implemented)
* 2 GPIO pins (not implemented)
* system acoustics optimizations (not implemented)
@@ -107,6 +107,7 @@ in2 VCC (4) VCC (4) VCC (4) VCC (3)
in3 5VIN (20) 5VIN (20)
in4 12VIN (21) 12VIN (21)
in5 VTT (8)
+in6 Imon (19)
==== =========== =========== ========= ==========
Special Features
diff --git a/Documentation/hwmon/aht10.rst b/Documentation/hwmon/aht10.rst
index 482262ca117c..7903b6434326 100644
--- a/Documentation/hwmon/aht10.rst
+++ b/Documentation/hwmon/aht10.rst
@@ -5,32 +5,50 @@ Kernel driver aht10
Supported chips:
- * Aosong AHT10
+ * Aosong AHT10/AHT20
Prefix: 'aht10'
Addresses scanned: None
- Datasheet:
+ Datasheet(AHT10):
Chinese: http://www.aosong.com/userfiles/files/media/AHT10%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C%20A3%2020201210.pdf
English: https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf
+ Datasheet(AHT20):
+
+ English: http://www.aosong.com/userfiles/files/media/Data%20Sheet%20AHT20.pdf
+
+ * Aosong DHT20
+
+ Prefix: 'dht20'
+
+ Addresses scanned: None
+
+ Datasheet: https://www.digikey.co.nz/en/htmldatasheets/production/9184855/0/0/1/101020932
+
Author: Johannes Cornelis Draaijer <jcdra1@gmail.com>
Description
-----------
-The AHT10 is a Temperature and Humidity sensor
+The AHT10/AHT20 is a Temperature and Humidity sensor
The address of this i2c device may only be 0x38
+Special Features
+----------------
+
+AHT20, DHT20 has additional CRC8 support which is sent as the last byte of the sensor
+values.
+
Usage Notes
-----------
-This driver does not probe for AHT10 devices, as there is no reliable
-way to determine if an i2c chip is or isn't an AHT10. The device has
+This driver does not probe for AHT10/ATH20 devices, as there is no reliable
+way to determine if an i2c chip is or isn't an AHT10/AHT20. The device has
to be instantiated explicitly with the address 0x38. See
Documentation/i2c/instantiating-devices.rst for details.
@@ -38,7 +56,7 @@ Sysfs entries
-------------
=============== ============================================
-temp1_input Measured temperature in millidegrees Celcius
+temp1_input Measured temperature in millidegrees Celsius
humidity1_input Measured humidity in %H
update_interval The minimum interval for polling the sensor,
in milliseconds. Writable. Must be at
diff --git a/Documentation/hwmon/amc6821.rst b/Documentation/hwmon/amc6821.rst
index 5ddb2849da90..dbd544cd1160 100644
--- a/Documentation/hwmon/amc6821.rst
+++ b/Documentation/hwmon/amc6821.rst
@@ -47,13 +47,18 @@ fan1_input ro tachometer speed
fan1_min rw "
fan1_max rw "
fan1_fault ro "
-fan1_div rw Fan divisor can be either 2 or 4.
+fan1_pulses rw Pulses per revolution can be either 2 or 4.
+fan1_target rw Target fan speed, to be used with pwm1_enable
+ mode 4.
pwm1 rw pwm1
pwm1_enable rw regulator mode, 1=open loop, 2=fan controlled
by remote temperature, 3=fan controlled by
combination of the on-chip temperature and
remote-sensor temperature,
+ 4=fan controlled by target rpm set with
+ fan1_target attribute.
+pwm1_mode rw Fan duty control mode (0=DC, 1=PWM)
pwm1_auto_channels_temp ro 1 if pwm_enable==2, 3 if pwm_enable==3
pwm1_auto_point1_pwm ro Hardwired to 0, shared for both
temperature channels.
diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst
index e238533b5fe0..49163f387b90 100644
--- a/Documentation/hwmon/aquacomputer_d5next.rst
+++ b/Documentation/hwmon/aquacomputer_d5next.rst
@@ -5,12 +5,19 @@ Kernel driver aquacomputer-d5next
Supported devices:
+* Aquacomputer Aquaero 5/6 fan controllers
* Aquacomputer D5 Next watercooling pump
* Aquacomputer Farbwerk RGB controller
* Aquacomputer Farbwerk 360 RGB controller
* Aquacomputer Octo fan controller
* Aquacomputer Quadro fan controller
* Aquacomputer High Flow Next sensor
+* Aquacomputer Leakshield leak prevention system
+* Aquacomputer Aquastream XT watercooling pump
+* Aquacomputer Aquastream Ultimate watercooling pump
+* Aquacomputer Poweradjust 3 fan controller
+* Aquacomputer High Flow USB flow meter
+* Aquacomputer MPS Flow devices
Author: Aleksa Savic
@@ -20,6 +27,11 @@ Description
This driver exposes hardware sensors of listed Aquacomputer devices, which
communicate through proprietary USB HID protocols.
+The Aquaero devices expose eight physical, eight virtual and four calculated
+virtual temperature sensors, as well as two flow sensors. The fans expose their
+speed (in RPM), power, voltage and current. Temperature offsets and fan speeds
+can be controlled.
+
For the D5 Next pump, available sensors are pump and fan speed, power, voltage
and current, as well as coolant temperature and eight virtual temp sensors. Also
available through debugfs are the serial number, firmware version and power-on
@@ -33,13 +45,13 @@ seems to require sending it a complete configuration. That includes addressable
RGB LEDs, for which there is no standard sysfs interface. Thus, that task is
better suited for userspace tools.
-The Octo exposes four physical and sixteen virtual temperature sensors, as well as
-eight PWM controllable fans, along with their speed (in RPM), power, voltage and
-current.
+The Octo exposes four physical and sixteen virtual temperature sensors, a flow sensor
+as well as eight PWM controllable fans, along with their speed (in RPM), power, voltage
+and current. Flow sensor pulses are also available.
The Quadro exposes four physical and sixteen virtual temperature sensors, a flow
sensor and four PWM controllable fans, along with their speed (in RPM), power,
-voltage and current.
+voltage and current. Flow sensor pulses are also available.
The Farbwerk and Farbwerk 360 expose four temperature sensors. Additionally,
sixteen virtual temperature sensors of the Farbwerk 360 are exposed.
@@ -48,6 +60,26 @@ The High Flow Next exposes +5V voltages, water quality, conductivity and flow re
A temperature sensor can be connected to it, in which case it provides its reading
and an estimation of the dissipated/absorbed power in the liquid cooling loop.
+The Leakshield exposes two temperature sensors and coolant pressure (current, min, max and
+target readings). It also exposes the estimated reservoir volume and how much of it is
+filled with coolant. Pump RPM and flow can be set to enhance on-device calculations,
+but this is not yet implemented here.
+
+The Aquastream XT pump exposes temperature readings for the coolant, external sensor
+and fan IC. It also exposes pump and fan speeds (in RPM), voltages, as well as pump
+current.
+
+The Aquastream Ultimate pump exposes coolant temp and an external temp sensor, along
+with speed, power, voltage and current of both the pump and optionally connected fan.
+It also exposes pressure and flow speed readings.
+
+The Poweradjust 3 controller exposes a single external temperature sensor.
+
+The High Flow USB exposes an internal and external temperature sensor, and a flow meter.
+
+The MPS Flow devices expose the same entries as the High Flow USB because they have
+the same USB product ID and report sensors equivalently.
+
Depending on the device, not all sysfs and debugfs entries will be available.
Writing to virtual temperature sensors is not currently supported.
@@ -62,7 +94,13 @@ Sysfs entries
================ ==============================================================
temp[1-20]_input Physical/virtual temperature sensors (in millidegrees Celsius)
-fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h)
+temp[1-8]_offset Temperature sensor correction offset (in millidegrees Celsius)
+fan[1-9]_input Pump/fan speed (in RPM) / Flow speed (in dL/h)
+fan1_min Minimal fan speed (in RPM)
+fan1_max Maximal fan speed (in RPM)
+fan1_target Target fan speed (in RPM)
+fan5_pulses Quadro flow sensor pulses
+fan9_pulses Octo flow sensor pulses
power[1-8]_input Pump/fan power (in micro Watts)
in[0-7]_input Pump/fan voltage (in milli Volts)
curr[1-8]_input Pump/fan current (in milli Amperes)
diff --git a/Documentation/hwmon/aspeed-g6-pwm-tach.rst b/Documentation/hwmon/aspeed-g6-pwm-tach.rst
new file mode 100644
index 000000000000..17398fe397fe
--- /dev/null
+++ b/Documentation/hwmon/aspeed-g6-pwm-tach.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver aspeed-g6-pwm-tach
+=================================
+
+Supported chips:
+ ASPEED AST2600
+
+Authors:
+ <billy_tsai@aspeedtech.com>
+
+Description:
+------------
+This driver implements support for ASPEED AST2600 Fan Tacho controller.
+The controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+=============== ======= ======================================================
+fanX_input ro provide current fan rotation value in RPM as reported
+ by the fan to the device.
+fanX_div rw Fan divisor: Supported value are power of 4 (1, 4, 16
+ 64, ... 4194304)
+ The larger divisor, the less rpm accuracy and the less
+ affected by fan signal glitch.
+=============== ======= ======================================================
diff --git a/Documentation/hwmon/aspeed-pwm-tacho.rst b/Documentation/hwmon/aspeed-pwm-tacho.rst
index 6dcec845fbc7..f7bbe96f4bc8 100644
--- a/Documentation/hwmon/aspeed-pwm-tacho.rst
+++ b/Documentation/hwmon/aspeed-pwm-tacho.rst
@@ -10,7 +10,7 @@ Authors:
Description:
------------
This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
-controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller. The PWM controller supports up to 8 PWM outputs. The Fan tacho
controller supports up to 16 tachometer inputs.
The driver provides the following sensor accesses in sysfs:
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 02f4ad314a1e..232885f24430 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -4,25 +4,53 @@ Kernel driver asus_ec_sensors
=================================
Supported boards:
+ * MAXIMUS VI HERO
* PRIME X470-PRO
* PRIME X570-PRO
+ * PRIME X670E-PRO WIFI
+ * PRIME Z270-A
+ * Pro WS TRX50-SAGE WIFI
* Pro WS X570-ACE
+ * Pro WS WRX90E-SAGE SE
* ProArt X570-CREATOR WIFI
+ * ProArt X670E-CREATOR WIFI
+ * ProArt X870E-CREATOR WIFI
+ * ProArt B550-CREATOR
* ROG CROSSHAIR VIII DARK HERO
* ROG CROSSHAIR VIII HERO (WI-FI)
* ROG CROSSHAIR VIII FORMULA
* ROG CROSSHAIR VIII HERO
* ROG CROSSHAIR VIII IMPACT
+ * ROG CROSSHAIR X670E HERO
+ * ROG CROSSHAIR X670E GENE
* ROG MAXIMUS XI HERO
* ROG MAXIMUS XI HERO (WI-FI)
+ * ROG MAXIMUS Z690 FORMULA
* ROG STRIX B550-E GAMING
* ROG STRIX B550-I GAMING
+ * ROG STRIX B650E-I GAMING WIFI
+ * ROG STRIX B850-I GAMING WIFI
+ * ROG STRIX X470-I GAMING
* ROG STRIX X570-E GAMING
* ROG STRIX X570-E GAMING WIFI II
* ROG STRIX X570-F GAMING
* ROG STRIX X570-I GAMING
+ * ROG STRIX X670E-E GAMING WIFI
+ * ROG STRIX X670E-I GAMING WIFI
+ * ROG STRIX X870-F GAMING WIFI
+ * ROG STRIX X870-I GAMING WIFI
+ * ROG STRIX X870E-E GAMING WIFI
+ * ROG STRIX X870E-H GAMING WIFI7
+ * ROG STRIX Z390-F GAMING
+ * ROG STRIX Z490-F GAMING
* ROG STRIX Z690-A GAMING WIFI D4
+ * ROG STRIX Z690-E GAMING WIFI
+ * ROG STRIX Z790-E GAMING WIFI II
+ * ROG STRIX Z790-I GAMING WIFI
* ROG ZENITH II EXTREME
+ * ROG ZENITH II EXTREME ALPHA
+ * TUF GAMING X670E PLUS
+ * TUF GAMING X670E PLUS WIFI
Authors:
- Eugene Shalygin <eugene.shalygin@gmail.com>
diff --git a/Documentation/hwmon/asus_rog_ryujin.rst b/Documentation/hwmon/asus_rog_ryujin.rst
new file mode 100644
index 000000000000..9f77da070022
--- /dev/null
+++ b/Documentation/hwmon/asus_rog_ryujin.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver asus_rog_ryujin
+=============================
+
+Supported devices:
+
+* ASUS ROG RYUJIN II 360
+
+Author: Aleksa Savic
+
+Description
+-----------
+
+This driver enables hardware monitoring support for the listed ASUS ROG RYUJIN
+all-in-one CPU liquid coolers. Available sensors are pump, internal and external
+(controller) fan speed in RPM, their duties in PWM, as well as coolant temperature.
+
+Attaching external fans to the controller is optional and allows them to be
+controlled from the device. If not connected, the fan-related sensors will
+report zeroes. The controller is a separate hardware unit that comes bundled
+with the AIO and connects to it to allow fan control.
+
+The addressable LCD screen is not supported in this driver and should
+be controlled through userspace tools.
+
+Usage notes
+-----------
+
+As these are USB HIDs, the driver can be loaded automatically by the kernel and
+supports hot swapping.
+
+Sysfs entries
+-------------
+
+=========== =============================================
+fan1_input Pump speed (in rpm)
+fan2_input Internal fan speed (in rpm)
+fan3_input External (controller) fan 1 speed (in rpm)
+fan4_input External (controller) fan 2 speed (in rpm)
+fan5_input External (controller) fan 3 speed (in rpm)
+fan6_input External (controller) fan 4 speed (in rpm)
+temp1_input Coolant temperature (in millidegrees Celsius)
+pwm1 Pump duty
+pwm2 Internal fan duty
+pwm3 External (controller) fan duty
+=========== =============================================
diff --git a/Documentation/hwmon/cgbc-hwmon.rst b/Documentation/hwmon/cgbc-hwmon.rst
new file mode 100644
index 000000000000..3a5e6e6e8639
--- /dev/null
+++ b/Documentation/hwmon/cgbc-hwmon.rst
@@ -0,0 +1,63 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver cgbc-hwmon
+========================
+
+Supported chips:
+
+ * Congatec Board Controller.
+
+ Prefix: 'cgbc-hwmon'
+
+Author: Thomas Richard <thomas.richard@bootlin.com>
+
+Description
+-----------
+
+This driver enables monitoring support for the Congatec Board Controller.
+This controller is embedded on the x86 SoMs of Congatec.
+
+Sysfs entries
+-------------
+
+The following sysfs entries list contains all sensors defined in the Board
+Controller. The available sensors in sysfs depend on the SoM and the
+system.
+
+============= ======================
+Name Description
+============= ======================
+temp1_input CPU temperature
+temp2_input Box temperature
+temp3_input Ambient temperature
+temp4_input Board temperature
+temp5_input Carrier temperature
+temp6_input Chipset temperature
+temp7_input Video temperature
+temp8_input Other temperature
+temp9_input TOPDIM temperature
+temp10_input BOTTOMDIM temperature
+in0_input CPU voltage
+in1_input DC Runtime voltage
+in2_input DC Standby voltage
+in3_input CMOS Battery voltage
+in4_input Battery voltage
+in5_input AC voltage
+in6_input Other voltage
+in7_input 5V voltage
+in8_input 5V Standby voltage
+in9_input 3V3 voltage
+in10_input 3V3 Standby voltage
+in11_input VCore A voltage
+in12_input VCore B voltage
+in13_input 12V voltage
+curr1_input DC current
+curr2_input 5V current
+curr3_input 12V current
+fan1_input CPU fan
+fan2_input Box fan
+fan3_input Ambient fan
+fan4_input Chiptset fan
+fan5_input Video fan
+fan6_input Other fan
+============= ======================
diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
new file mode 100644
index 000000000000..dc165becc64c
--- /dev/null
+++ b/Documentation/hwmon/chipcap2.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver ChipCap2
+======================
+
+Supported chips:
+
+ * Amphenol CC2D23, CC2D23S, CC2D25, CC2D25S, CC2D33, CC2D33S, CC2D35, CC2D35S
+
+ Prefix: 'chipcap2'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+
+Author:
+
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+Description
+-----------
+
+This driver implements support for the Amphenol ChipCap 2, a humidity and
+temperature chip family. Temperature is measured in milli degrees celsius,
+relative humidity is expressed as a per cent mille. The measurement ranges
+are the following:
+
+ - Relative humidity: 0 to 100000 pcm (14-bit resolution)
+ - Temperature: -40000 to +125000 m°C (14-bit resolution)
+
+The device communicates with the I2C protocol and uses the I2C address 0x28
+by default.
+
+Depending on the hardware configuration, up to two humidity alarms to control
+minimum and maximum values are provided. Their thresholds and hystersis can be
+configured via sysfs.
+
+Thresholds and hysteris must be provided as a per cent mille. These values
+might be truncated to match the 14-bit device resolution (6.1 pcm/LSB)
+
+Known Issues
+------------
+
+The driver does not support I2C address and command window length modification.
+
+sysfs-Interface
+---------------
+
+The following list includes the sysfs attributes that the driver always provides,
+their permissions and a short description:
+
+=============================== ======= ========================================
+Name Perm Description
+=============================== ======= ========================================
+temp1_input: RO temperature input
+humidity1_input: RO humidity input
+=============================== ======= ========================================
+
+The following list includes the sysfs attributes that the driver may provide
+depending on the hardware configuration:
+
+=============================== ======= ========================================
+Name Perm Description
+=============================== ======= ========================================
+humidity1_min: RW humidity low limit. Measurements under
+ this limit trigger a humidity low alarm
+humidity1_max: RW humidity high limit. Measurements above
+ this limit trigger a humidity high alarm
+humidity1_min_hyst: RW humidity low hystersis
+humidity1_max_hyst: RW humidity high hystersis
+humidity1_min_alarm: RO humidity low alarm indicator
+humidity1_max_alarm: RO humidity high alarm indicator
+=============================== ======= ========================================
diff --git a/Documentation/hwmon/corsair-cpro.rst b/Documentation/hwmon/corsair-cpro.rst
index 751f95476b57..15077203a2f8 100644
--- a/Documentation/hwmon/corsair-cpro.rst
+++ b/Documentation/hwmon/corsair-cpro.rst
@@ -39,3 +39,11 @@ fan[1-6]_target Sets fan speed target rpm.
pwm[1-6] Sets the fan speed. Values from 0-255. Can only be read if pwm
was set directly.
======================= =====================================================================
+
+Debugfs entries
+---------------
+
+======================= ===================
+firmware_version Firmware version
+bootloader_version Bootloader version
+======================= ===================
diff --git a/Documentation/hwmon/corsair-psu.rst b/Documentation/hwmon/corsair-psu.rst
index 3c1b164eb3c0..2e99cfd556a0 100644
--- a/Documentation/hwmon/corsair-psu.rst
+++ b/Documentation/hwmon/corsair-psu.rst
@@ -15,9 +15,11 @@ Supported devices:
Corsair HX850i
- Corsair HX1000i (revision 1 and 2)
+ Corsair HX1000i (Legacy and Series 2023)
- Corsair HX1200i
+ Corsair HX1200i (Legacy, Series 2023 and Series 2025)
+
+ Corsair HX1500i (Legacy and Series 2023)
Corsair RM550i
@@ -38,7 +40,7 @@ This driver implements the sysfs interface for the Corsair PSUs with a HID proto
interface of the HXi and RMi series.
These power supplies provide access to a micro-controller with 2 attached
temperature sensors, 1 fan rpm sensor, 4 sensors for volt levels, 4 sensors for
-power usage and 4 sensors for current levels and addtional non-sensor information
+power usage and 4 sensors for current levels and additional non-sensor information
like uptimes.
Sysfs entries
@@ -67,6 +69,8 @@ power1_input Total power usage
power2_input Power usage of the 12v psu rail
power3_input Power usage of the 5v psu rail
power4_input Power usage of the 3.3v psu rail
+pwm1 PWM value, read only
+pwm1_enable PWM mode, read only
temp1_input Temperature of the psu vrm component
temp1_crit Temperature max cirtical value of the psu vrm component
temp2_input Temperature of the psu case
@@ -76,11 +80,14 @@ temp2_crit Temperature max critical value of psu case
Usage Notes
-----------
-It is an USB HID device, so it is auto-detected and supports hot-swapping.
+It is an USB HID device, so it is auto-detected, supports hot-swapping and
+several devices at once.
Flickering values in the rail voltage levels can be an indicator for a failing
-PSU. The driver also provides some additional useful values via debugfs, which
-do not fit into the hwmon class.
+PSU. Accordingly to the default automatic fan speed plan the fan starts at about
+30% of the wattage rating. If this does not happen, a fan failure is likely. The
+driver also provides some additional useful values via debugfs, which do not fit
+into the hwmon class.
Debugfs entries
---------------
diff --git a/Documentation/hwmon/cros_ec_hwmon.rst b/Documentation/hwmon/cros_ec_hwmon.rst
new file mode 100644
index 000000000000..6db812708325
--- /dev/null
+++ b/Documentation/hwmon/cros_ec_hwmon.rst
@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver cros_ec_hwmon
+===========================
+
+Supported chips:
+
+ * ChromeOS embedded controllers.
+
+ Prefix: 'cros_ec'
+
+ Addresses scanned: -
+
+Author:
+
+ - Thomas Weißschuh <linux@weissschuh.net>
+
+Description
+-----------
+
+This driver implements support for hardware monitoring commands exposed by the
+ChromeOS embedded controller used in Chromebooks and other devices.
+
+The channel labels exposed via hwmon are retrieved from the EC itself.
+
+Fan and temperature readings are supported. PWM fan control is also supported if
+the EC also supports setting fan PWM values and fan mode. Note that EC will
+switch fan control mode back to auto when suspended. This driver will restore
+the fan state to what they were before suspended when resumed.
+If a fan is controllable, this driver will register that fan as a cooling device
+in the thermal framework as well.
diff --git a/Documentation/hwmon/crps.rst b/Documentation/hwmon/crps.rst
new file mode 100644
index 000000000000..d42ea59d2dae
--- /dev/null
+++ b/Documentation/hwmon/crps.rst
@@ -0,0 +1,97 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver crps
+==================
+
+Supported chips:
+
+ * Intel CRPS185
+
+ Prefix: 'crps185'
+
+ Addresses scanned: -
+
+ Datasheet: Only available under NDA.
+
+Authors:
+ Ninad Palsule <ninad@linux.ibm.com>
+
+
+Description
+-----------
+
+This driver implements support for Intel Common Redundant Power supply with
+PMBus support.
+
+The driver is a client driver to the core PMBus driver.
+Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
+details.
+
+
+Sysfs entries
+-------------
+
+======================= ======================================================
+curr1_label "iin"
+curr1_input Measured input current
+curr1_max Maximum input current
+curr1_max_alarm Input maximum current high alarm
+curr1_crit Critical high input current
+curr1_crit_alarm Input critical current high alarm
+curr1_rated_max Maximum rated input current
+
+curr2_label "iout1"
+curr2_input Measured output current
+curr2_max Maximum output current
+curr2_max_alarm Output maximum current high alarm
+curr2_crit Critical high output current
+curr2_crit_alarm Output critical current high alarm
+curr2_rated_max Maximum rated output current
+
+in1_label "vin"
+in1_input Measured input voltage
+in1_crit Critical input over voltage
+in1_crit_alarm Critical input over voltage alarm
+in1_max Maximum input over voltage
+in1_max_alarm Maximum input over voltage alarm
+in1_rated_min Minimum rated input voltage
+in1_rated_max Maximum rated input voltage
+
+in2_label "vout1"
+in2_input Measured input voltage
+in2_crit Critical input over voltage
+in2_crit_alarm Critical input over voltage alarm
+in2_lcrit Critical input under voltage fault
+in2_lcrit_alarm Critical input under voltage fault alarm
+in2_max Maximum input over voltage
+in2_max_alarm Maximum input over voltage alarm
+in2_min Minimum input under voltage warning
+in2_min_alarm Minimum input under voltage warning alarm
+in2_rated_min Minimum rated input voltage
+in2_rated_max Maximum rated input voltage
+
+power1_label "pin"
+power1_input Measured input power
+power1_alarm Input power high alarm
+power1_max Maximum input power
+power1_rated_max Maximum rated input power
+
+temp[1-2]_input Measured temperature
+temp[1-2]_crit Critical temperature
+temp[1-2]_crit_alarm Critical temperature alarm
+temp[1-2]_max Maximum temperature
+temp[1-2]_max_alarm Maximum temperature alarm
+temp[1-2]_rated_max Maximum rated temperature
+
+fan1_alarm Fan 1 warning.
+fan1_fault Fan 1 fault.
+fan1_input Fan 1 speed in RPM.
+fan1_target Fan 1 target.
+======================= ======================================================
diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst
index d8f1d6859b96..3e4e2d916ac5 100644
--- a/Documentation/hwmon/dell-smm-hwmon.rst
+++ b/Documentation/hwmon/dell-smm-hwmon.rst
@@ -32,13 +32,13 @@ Temperature sensors and fans can be queried and set via the standard
=============================== ======= =======================================
Name Perm Description
=============================== ======= =======================================
-fan[1-3]_input RO Fan speed in RPM.
-fan[1-3]_label RO Fan label.
-fan[1-3]_min RO Minimal Fan speed in RPM
-fan[1-3]_max RO Maximal Fan speed in RPM
-fan[1-3]_target RO Expected Fan speed in RPM
-pwm[1-3] RW Control the fan PWM duty-cycle.
-pwm1_enable WO Enable or disable automatic BIOS fan
+fan[1-4]_input RO Fan speed in RPM.
+fan[1-4]_label RO Fan label.
+fan[1-4]_min RO Minimal Fan speed in RPM
+fan[1-4]_max RO Maximal Fan speed in RPM
+fan[1-4]_target RO Expected Fan speed in RPM
+pwm[1-4] RW Control the fan PWM duty-cycle.
+pwm[1-4]_enable RW/WO Enable or disable automatic BIOS fan
control (not supported on all laptops,
see below for details).
temp[1-10]_input RO Temperature reading in milli-degrees
@@ -49,26 +49,40 @@ temp[1-10]_label RO Temperature sensor label.
Due to the nature of the SMM interface, each pwmX attribute controls
fan number X.
-Disabling automatic BIOS fan control
-------------------------------------
+Enabling/Disabling automatic BIOS fan control
+---------------------------------------------
-On some laptops the BIOS automatically sets fan speed every few
-seconds. Therefore the fan speed set by mean of this driver is quickly
-overwritten.
+There exist two methods for enabling/disabling automatic BIOS fan control:
-There is experimental support for disabling automatic BIOS fan
-control, at least on laptops where the corresponding SMM command is
-known, by writing the value ``1`` in the attribute ``pwm1_enable``
-(writing ``2`` enables automatic BIOS control again). Even if you have
-more than one fan, all of them are set to either enabled or disabled
-automatic fan control at the same time and, notwithstanding the name,
-``pwm1_enable`` sets automatic control for all fans.
+1. Separate SMM commands to enable/disable automatic BIOS fan control for all fans.
-If ``pwm1_enable`` is not available, then it means that SMM codes for
-enabling and disabling automatic BIOS fan control are not whitelisted
-for your hardware. It is possible that codes that work for other
-laptops actually work for yours as well, or that you have to discover
-new codes.
+2. A special fan state that enables automatic BIOS fan control for a individual fan.
+
+The driver cannot reliably detect what method should be used on a given
+device, so instead the following heuristic is used:
+
+- use fan state 3 for enabling BIOS fan control if the maximum fan state
+ setable by the user is smaller than 3 (default setting).
+
+- use separate SMM commands if device is whitelisted to support them.
+
+When using the first method, each fan will have a standard ``pwmX_enable``
+sysfs attribute. Writing ``1`` into this attribute will disable automatic
+BIOS fan control for the associated fan and set it to maximum speed. Enabling
+BIOS fan control again can be achieved by writing ``2`` into this attribute.
+Reading this sysfs attributes returns the current setting as reported by
+the underlying hardware.
+
+When using the second method however, only the ``pwm1_enable`` sysfs attribute
+will be available to enable/disable automatic BIOS fan control globaly for all
+fans available on a given device. Additionally, this sysfs attribute is write-only
+as there exists no SMM command for reading the current fan control setting.
+
+If no ``pwmX_enable`` attributes are available, then it means that the driver
+cannot use the first method and the SMM codes for enabling and disabling automatic
+BIOS fan control are not whitelisted for your device. It is possible that codes
+that work for other laptops actually work for yours as well, or that you have to
+discover new codes.
Check the list ``i8k_whitelist_fan_control`` in file
``drivers/hwmon/dell-smm-hwmon.c`` in the kernel tree: as a first
@@ -93,7 +107,7 @@ Again, when you find new codes, we'd be happy to have your patches!
---------------------------
The driver also exports the fans as thermal cooling devices with
-``type`` set to ``dell-smm-fan[1-3]``. This allows for easy fan control
+``type`` set to ``dell-smm-fan[1-4]``. This allows for easy fan control
using one of the thermal governors.
Module parameters
@@ -186,8 +200,7 @@ SMM Interface
The driver uses the SMM interface to send commands to the system BIOS.
This interface is normally used by Dell's 32-bit diagnostic program or
on newer notebook models by the buildin BIOS diagnostics.
-The SMM is triggered by writing to the special ioports ``0xb2`` and ``0x84``,
-and may cause short hangs when the BIOS code is taking too long to
+The SMM may cause short hangs when the BIOS code is taking too long to
execute.
The SMM handler inside the system BIOS looks at the contents of the
@@ -210,7 +223,40 @@ The SMM handler can signal a failure by either:
- setting the lower sixteen bits of ``eax`` to ``0xffff``
- not modifying ``eax`` at all
-- setting the carry flag
+- setting the carry flag (legacy SMM interface only)
+
+Legacy SMM Interface
+--------------------
+
+When using the legacy SMM interface, a SMM is triggered by writing the least significant byte
+of the command code to the special ioports ``0xb2`` and ``0x84``. This interface is not
+described inside the ACPI tables and can thus only be detected by issuing a test SMM call.
+
+WMI SMM Interface
+-----------------
+
+On modern Dell machines, the SMM calls are done over ACPI WMI:
+
+::
+
+ #pragma namespace("\\\\.\\root\\dcim\\sysman\\diagnostics")
+ [WMI, Provider("Provider_DiagnosticsServices"), Dynamic, Locale("MS\\0x409"),
+ Description("RunDellDiag"), guid("{F1DDEE52-063C-4784-A11E-8A06684B9B01}")]
+ class LegacyDiags {
+ [key, read] string InstanceName;
+ [read] boolean Active;
+
+ [WmiMethodId(1), Implemented, read, write, Description("Legacy Method ")]
+ void Execute([in, out] uint32 EaxLen, [in, out, WmiSizeIs("EaxLen") : ToInstance] uint8 EaxVal[],
+ [in, out] uint32 EbxLen, [in, out, WmiSizeIs("EbxLen") : ToInstance] uint8 EbxVal[],
+ [in, out] uint32 EcxLen, [in, out, WmiSizeIs("EcxLen") : ToInstance] uint8 EcxVal[],
+ [in, out] uint32 EdxLen, [in, out, WmiSizeIs("EdxLen") : ToInstance] uint8 EdxVal[]);
+ };
+
+Some machines support only the WMI SMM interface, while some machines support both interfaces.
+The driver automatically detects which interfaces are present and will use the WMI SMM interface
+if the legacy SMM interface is not present. The WMI SMM interface is usually slower than the
+legacy SMM interface since ACPI methods need to be called in order to trigger a SMM.
SMM command codes
-----------------
@@ -328,6 +374,8 @@ Firmware Bug Affected Machines
======================================================= =================
Reading of fan states return spurious errors. Precision 490
+ OptiPlex 7060
+
Reading of fan types causes erratic fan behaviour. Studio XPS 8000
Studio XPS 8100
diff --git a/Documentation/hwmon/ds1621.rst b/Documentation/hwmon/ds1621.rst
index 552b37e9dd34..d0808720aa07 100644
--- a/Documentation/hwmon/ds1621.rst
+++ b/Documentation/hwmon/ds1621.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: Publicly available from www.maximintegrated.com
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/DS1621.pdf
* Dallas Semiconductor DS1625
@@ -17,7 +17,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: Publicly available from www.datasheetarchive.com
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/DS1620.pdf
* Maxim Integrated DS1631
@@ -25,7 +25,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: Publicly available from www.maximintegrated.com
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/DS1631-DS1731.pdf
* Maxim Integrated DS1721
@@ -33,7 +33,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: Publicly available from www.maximintegrated.com
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/DS1721.pdf
* Maxim Integrated DS1731
@@ -41,7 +41,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: Publicly available from www.maximintegrated.com
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/DS1631-DS1731.pdf
Authors:
- Christian W. Zuckschwerdt <zany@triq.net>
diff --git a/Documentation/hwmon/emc1403.rst b/Documentation/hwmon/emc1403.rst
index 0de9616b24ed..57f833b1a800 100644
--- a/Documentation/hwmon/emc1403.rst
+++ b/Documentation/hwmon/emc1403.rst
@@ -45,6 +45,17 @@ Supported chips:
- https://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf
+ * SMSC / Microchip EMC1428, EMC1438
+
+ Addresses scanned: I2C 0x18, 0x4c, 0x4d
+
+ Prefix: 'emc1428', 'emc1438'
+
+ Datasheets:
+
+ - https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/20005275A.pdf
+ - https://ww1.microchip.com/downloads/en/DeviceDoc/EMC1438%20DS%20Rev.%201.0%20(04-29-10).pdf
+
Author:
Kalhan Trisal <kalhan.trisal@intel.com
@@ -53,10 +64,10 @@ Description
-----------
The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips
-contain up to four temperature sensors. EMC14x2 support two sensors
+contain up to eight temperature sensors. EMC14x2 support two sensors
(one internal, one external). EMC14x3 support three sensors (one internal,
-two external), and EMC14x4 support four sensors (one internal, three
-external).
+two external), EMC14x4 support four sensors (one internal, three external),
+and EMC14x8 support eight sensors (one internal, seven external).
The chips implement three limits for each sensor: low (tempX_min), high
(tempX_max) and critical (tempX_crit.) The chips also implement an
diff --git a/Documentation/hwmon/emc2305.rst b/Documentation/hwmon/emc2305.rst
index 2403dbaf2728..d0bfffe46358 100644
--- a/Documentation/hwmon/emc2305.rst
+++ b/Documentation/hwmon/emc2305.rst
@@ -6,7 +6,6 @@ Kernel driver emc2305
Supported chips:
Microchip EMC2305, EMC2303, EMC2302, EMC2301
- Addresses scanned: I2C 0x27, 0x2c, 0x2d, 0x2e, 0x2f, 0x4c, 0x4d
Prefixes: 'emc2305'
Datasheet: Publicly available at the Microchip website :
diff --git a/Documentation/hwmon/f71882fg.rst b/Documentation/hwmon/f71882fg.rst
index 38e30fbd4806..53d32bf06b70 100644
--- a/Documentation/hwmon/f71882fg.rst
+++ b/Documentation/hwmon/f71882fg.rst
@@ -178,10 +178,11 @@ Writing an unsupported mode will result in an invalid parameter error.
available on the F71858FG / F8000 if the fan channel is in RPM mode.
* 2: Normal auto mode
- You can define a number of temperature/fan speed trip points, which % the
- fan should run at at this temp and which temp a fan should follow using the
- standard sysfs interface. The number and type of trip points is chip
- depended, see which files are available in sysfs.
+ You can define a number of temperature/fan speed trip points that specify
+ the percentage at which the fan should run at each temperature, and which
+ temperature sensor a fan should follow, using the standard sysfs interface.
+ The number and type of trip points are chip dependent - see the available
+ files in sysfs.
Fan/PWM channel 3 of the F8000 is always in this mode!
* 3: Thermostat mode (Only available on the F8000 when in duty cycle mode)
diff --git a/Documentation/hwmon/ftsteutates.rst b/Documentation/hwmon/ftsteutates.rst
index 58a2483d8d0d..2abd16830c99 100644
--- a/Documentation/hwmon/ftsteutates.rst
+++ b/Documentation/hwmon/ftsteutates.rst
@@ -22,12 +22,21 @@ enhancements. It can monitor up to 4 voltages, 16 temperatures and
8 fans. It also contains an integrated watchdog which is currently
implemented in this driver.
+The ``pwmX_auto_channels_temp`` attributes show which temperature sensor
+is currently driving which fan channel. This value might dynamically change
+during runtime depending on the temperature sensor selected by
+the fan control circuit.
+
+The 4 voltages require a board-specific multiplier, since the BMC can
+only measure voltages up to 3.3V and thus relies on voltage dividers.
+Consult your motherboard manual for details.
+
To clear a temperature or fan alarm, execute the following command with the
correct path to the alarm file::
echo 0 >XXXX_alarm
-Specification of the chip can be found here:
+Specifications of the chip can be found at the `Kontron FTP Server <http://ftp.kontron.com/>`_ (username = "anonymous", no password required)
+under the following path:
-- ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf
-- ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf
+ /Services/Software_Tools/Linux_SystemMonitoring_Watchdog_GPIO/BMC-Teutates_Specification_V1.21.pdf
diff --git a/Documentation/hwmon/g762.rst b/Documentation/hwmon/g762.rst
index 0371b3365c48..f224552a2d3c 100644
--- a/Documentation/hwmon/g762.rst
+++ b/Documentation/hwmon/g762.rst
@@ -17,7 +17,7 @@ done via a userland daemon like fancontrol.
Note that those entries do not provide ways to setup the specific
hardware characteristics of the system (reference clock, pulses per
fan revolution, ...); Those can be modified via devicetree bindings
-documented in Documentation/devicetree/bindings/hwmon/g762.txt or
+documented in Documentation/devicetree/bindings/hwmon/gmt,g762.yaml or
using a specific platform_data structure in board initialization
file (see include/linux/platform_data/g762.h).
diff --git a/Documentation/hwmon/gigabyte_waterforce.rst b/Documentation/hwmon/gigabyte_waterforce.rst
new file mode 100644
index 000000000000..d47f3e8516ee
--- /dev/null
+++ b/Documentation/hwmon/gigabyte_waterforce.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver gigabyte_waterforce
+=================================
+
+Supported devices:
+
+* Gigabyte AORUS WATERFORCE X240
+* Gigabyte AORUS WATERFORCE X280
+* Gigabyte AORUS WATERFORCE X360
+
+Author: Aleksa Savic
+
+Description
+-----------
+
+This driver enables hardware monitoring support for the listed Gigabyte Waterforce
+all-in-one CPU liquid coolers. Available sensors are pump and fan speed in RPM, as
+well as coolant temperature. Also available through debugfs is the firmware version.
+
+Attaching a fan is optional and allows it to be controlled from the device. If
+it's not connected, the fan-related sensors will report zeroes.
+
+The addressable RGB LEDs and LCD screen are not supported in this driver and should
+be controlled through userspace tools.
+
+Usage notes
+-----------
+
+As these are USB HIDs, the driver can be loaded automatically by the kernel and
+supports hot swapping.
+
+Sysfs entries
+-------------
+
+=========== =============================================
+fan1_input Fan speed (in rpm)
+fan2_input Pump speed (in rpm)
+temp1_input Coolant temperature (in millidegrees Celsius)
+=========== =============================================
+
+Debugfs entries
+---------------
+
+================ =======================
+firmware_version Device firmware version
+================ =======================
diff --git a/Documentation/hwmon/gpd-fan.rst b/Documentation/hwmon/gpd-fan.rst
new file mode 100644
index 000000000000..0b56b70e6264
--- /dev/null
+++ b/Documentation/hwmon/gpd-fan.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver gpd-fan
+=========================
+
+Author:
+ - Cryolitia PukNgae <cryolitia@uniontech.com>
+
+Description
+------------
+
+Handheld devices from Shenzhen GPD Technology Co., Ltd. provide fan readings
+and fan control through their embedded controllers.
+
+Supported devices
+-----------------
+
+Currently the driver supports the following handhelds:
+
+ - GPD Win Mini (7840U)
+ - GPD Win Mini (8840U)
+ - GPD Win Mini (HX370)
+ - GPD Pocket 4
+ - GPD Duo
+ - GPD Win Max 2 (6800U)
+ - GPD Win Max 2 2023 (7840U)
+ - GPD Win Max 2 2024 (8840U)
+ - GPD Win Max 2 2025 (HX370)
+ - GPD Win 4 (6800U)
+ - GPD Win 4 (7840U)
+
+Module parameters
+-----------------
+
+gpd_fan_board
+ Force specific which module quirk should be used.
+ Use it like "gpd_fan_board=wm2".
+
+ - wm2
+ - GPD Win 4 (7840U)
+ - GPD Win Max 2 (6800U)
+ - GPD Win Max 2 2023 (7840U)
+ - GPD Win Max 2 2024 (8840U)
+ - GPD Win Max 2 2025 (HX370)
+ - win4
+ - GPD Win 4 (6800U)
+ - win_mini
+ - GPD Win Mini (7840U)
+ - GPD Win Mini (8840U)
+ - GPD Win Mini (HX370)
+ - GPD Pocket 4
+ - GPD Duo
+
+Sysfs entries
+-------------
+
+The following attributes are supported:
+
+fan1_input
+ Read Only. Reads current fan RPM.
+
+pwm1_enable
+ Read/Write. Enable manual fan control. Write "0" to disable control and run
+ at full speed. Write "1" to set to manual, write "2" to let the EC control
+ decide fan speed. Read this attribute to see current status.
+
+ NB:In consideration of the safety of the device, when setting to manual mode,
+ the pwm speed will be set to the maximum value (255) by default. You can set
+ a different value by writing pwm1 later.
+
+pwm1
+ Read/Write. Read this attribute to see current duty cycle in the range
+ [0-255]. When pwm1_enable is set to "1" (manual) write any value in the
+ range [0-255] to set fan speed.
+
+ NB: Many boards (except listed under wm2 above) don't support reading the
+ current pwm value in auto mode. That will just return EOPNOTSUPP. In manual
+ mode it will always return the real value.
diff --git a/Documentation/hwmon/gsc-hwmon.rst b/Documentation/hwmon/gsc-hwmon.rst
index ffac392a7129..e9ab27940d02 100644
--- a/Documentation/hwmon/gsc-hwmon.rst
+++ b/Documentation/hwmon/gsc-hwmon.rst
@@ -31,7 +31,7 @@ Temperature Monitoring
Temperatures are measured with 12-bit or 10-bit resolution and are scaled
either internally or by the driver depending on the GSC version and firmware.
-The values returned by the driver reflect millidegree Celcius:
+The values returned by the driver reflect millidegree Celsius:
tempX_input Measured temperature.
tempX_label Name of temperature input.
@@ -41,8 +41,8 @@ PWM Output Control
------------------
The GSC features 1 PWM output that operates in automatic mode where the
-PWM value will be scalled depending on 6 temperature boundaries.
-The tempeature boundaries are read-write and in millidegree Celcius and the
+PWM value will be scaled depending on 6 temperature boundaries.
+The tempeature boundaries are read-write and in millidegree Celsius and the
read-only PWM values range from 0 (off) to 255 (full speed).
Fan speed will be set to minimum (off) when the temperature sensor reads
less than pwm1_auto_point1_temp and maximum when the temperature sensor
diff --git a/Documentation/hwmon/gxp-fan-ctrl.rst b/Documentation/hwmon/gxp-fan-ctrl.rst
new file mode 100644
index 000000000000..ae3397e81c04
--- /dev/null
+++ b/Documentation/hwmon/gxp-fan-ctrl.rst
@@ -0,0 +1,28 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver gxp-fan-ctrl
+==========================
+
+Supported chips:
+
+ * HPE GXP SOC
+
+Author: Nick Hawkins <nick.hawkins@hpe.com>
+
+
+Description
+-----------
+
+gxp-fan-ctrl is a driver which provides fan control for the hpe gxp soc.
+The driver allows the gathering of fan status and the use of fan
+PWM control.
+
+
+Sysfs attributes
+----------------
+
+======================= ===========================================================
+pwm[0-7] Fan 0 to 7 respective PWM value (0-255)
+fan[0-7]_fault Fan 0 to 7 respective fault status: 1 fail, 0 ok
+fan[0-7]_enable Fan 0 to 7 respective enabled status: 1 enabled, 0 disabled
+======================= ===========================================================
diff --git a/Documentation/hwmon/hp-wmi-sensors.rst b/Documentation/hwmon/hp-wmi-sensors.rst
new file mode 100644
index 000000000000..a6bca9aecdde
--- /dev/null
+++ b/Documentation/hwmon/hp-wmi-sensors.rst
@@ -0,0 +1,140 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+.. include:: <isonum.txt>
+
+===========================
+Linux HP WMI Sensors Driver
+===========================
+
+:Copyright: |copy| 2023 James Seo <james@equiv.tech>
+
+Description
+===========
+
+Hewlett-Packard (and some HP Compaq) business-class computers report hardware
+monitoring information via Windows Management Instrumentation (WMI).
+This driver exposes that information to the Linux hwmon subsystem, allowing
+userspace utilities like ``sensors`` to gather numeric sensor readings.
+
+sysfs interface
+===============
+
+When the driver is loaded, it discovers the sensors available on the
+system and creates the following sysfs attributes as necessary within
+``/sys/class/hwmon/hwmon[X]``:
+
+(``[X]`` is some number that depends on other system components.)
+
+======================= ======= ===================================
+Name Perm Description
+======================= ======= ===================================
+``curr[X]_input`` RO Current in milliamperes (mA).
+``curr[X]_label`` RO Current sensor label.
+``fan[X]_input`` RO Fan speed in RPM.
+``fan[X]_label`` RO Fan sensor label.
+``fan[X]_fault`` RO Fan sensor fault indicator.
+``fan[X]_alarm`` RO Fan sensor alarm indicator.
+``in[X]_input`` RO Voltage in millivolts (mV).
+``in[X]_label`` RO Voltage sensor label.
+``temp[X]_input`` RO Temperature in millidegrees Celsius
+ (m\ |deg|\ C).
+``temp[X]_label`` RO Temperature sensor label.
+``temp[X]_fault`` RO Temperature sensor fault indicator.
+``temp[X]_alarm`` RO Temperature sensor alarm indicator.
+``intrusion[X]_alarm`` RW Chassis intrusion alarm indicator.
+======================= ======= ===================================
+
+``fault`` attributes
+ Reading ``1`` instead of ``0`` as the ``fault`` attribute for a sensor
+ indicates that it has encountered some issue during operation such that
+ measurements from it should not be trusted. If a sensor with the fault
+ condition recovers later, reading this attribute will return ``0`` again.
+
+``alarm`` attributes
+ Reading ``1`` instead of ``0`` as the ``alarm`` attribute for a sensor
+ indicates that one of the following has occurred, depending on its type:
+
+ - ``fan``: The fan has stalled or has been disconnected while running.
+ - ``temp``: The sensor reading has reached a critical threshold.
+ The exact threshold is system-dependent.
+ - ``intrusion``: The system's chassis has been opened.
+
+ After ``1`` is read from an ``alarm`` attribute, the attribute resets itself
+ and returns ``0`` on subsequent reads. As an exception, an
+ ``intrusion[X]_alarm`` can only be manually reset by writing ``0`` to it.
+
+debugfs interface
+=================
+
+.. warning:: The debugfs interface is subject to change without notice
+ and is only available when the kernel is compiled with
+ ``CONFIG_DEBUG_FS`` defined.
+
+The standard hwmon interface in sysfs exposes sensors of several common types
+that are connected as of driver initialization. However, there are usually
+other sensors in WMI that do not meet these criteria. In addition, a number of
+system-dependent "platform events objects" used for ``alarm`` attributes may
+be present. A debugfs interface is therefore provided for read-only access to
+all available HP WMI sensors and platform events objects.
+
+``/sys/kernel/debug/hp-wmi-sensors-[X]/sensor``
+contains one numbered entry per sensor with the following attributes:
+
+=============================== =======================================
+Name Example
+=============================== =======================================
+``name`` ``CPU0 Fan``
+``description`` ``Reports CPU0 fan speed``
+``sensor_type`` ``12``
+``other_sensor_type`` (an empty string)
+``operational_status`` ``2``
+``possible_states`` ``Normal,Caution,Critical,Not Present``
+``current_state`` ``Normal``
+``base_units`` ``19``
+``unit_modifier`` ``0``
+``current_reading`` ``1008``
+``rate_units`` ``0`` (only exists on some systems)
+=============================== =======================================
+
+If platform events objects are available,
+``/sys/kernel/debug/hp-wmi-sensors-[X]/platform_events``
+contains one numbered entry per object with the following attributes:
+
+=============================== ====================
+Name Example
+=============================== ====================
+``name`` ``CPU0 Fan Stall``
+``description`` ``CPU0 Fan Speed``
+``source_namespace`` ``root\wmi``
+``source_class`` ``HPBIOS_BIOSEvent``
+``category`` ``3``
+``possible_severity`` ``25``
+``possible_status`` ``5``
+=============================== ====================
+
+These represent the properties of the underlying ``HPBIOS_BIOSNumericSensor``
+and ``HPBIOS_PlatformEvents`` WMI objects, which vary between systems.
+See [#]_ for more details and Managed Object Format (MOF) definitions.
+
+Known issues and limitations
+============================
+
+- If the existing hp-wmi driver for non-business-class HP systems is already
+ loaded, ``alarm`` attributes will be unavailable even on systems that
+ support them. This is because the same WMI event GUID used by this driver
+ for ``alarm`` attributes is used on those systems for e.g. laptop hotkeys.
+- Dubious sensor hardware and inconsistent BIOS WMI implementations have been
+ observed to cause inaccurate readings and peculiar behavior, such as alarms
+ failing to occur or occurring only once per boot.
+- Only temperature, fan speed, and intrusion sensor types have been seen in
+ the wild so far. Support for voltage and current sensors is therefore
+ provisional.
+- Although HP WMI sensors may claim to be of any type, any oddball sensor
+ types unknown to hwmon will not be supported.
+
+References
+==========
+
+.. [#] Hewlett-Packard Development Company, L.P.,
+ "HP Client Management Interface Technical White Paper", 2005. [Online].
+ Available: https://h20331.www2.hp.com/hpsub/downloads/cmi_whitepaper.pdf
diff --git a/Documentation/hwmon/hs3001.rst b/Documentation/hwmon/hs3001.rst
new file mode 100644
index 000000000000..9f59dfc212d9
--- /dev/null
+++ b/Documentation/hwmon/hs3001.rst
@@ -0,0 +1,37 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver HS3001
+====================
+
+Supported chips:
+
+ * Renesas HS3001, HS3002, HS3003, HS3004
+
+ Prefix: 'hs3001'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.renesas.com/us/en/document/dst/hs300x-datasheet?r=417401
+
+Author:
+
+ - Andre Werner <andre.werner@systec-electronic.com>
+
+Description
+-----------
+
+This driver implements support for the Renesas HS3001 chips, a humidity
+and temperature family. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. In the sysfs interface, all values are
+scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+
+The device communicates with the I2C protocol. Sensors have the I2C
+address 0x44 by default.
+
+sysfs-Interface
+---------------
+
+=================== =================
+temp1_input: temperature input
+humidity1_input: humidity input
+=================== =================
diff --git a/Documentation/hwmon/htu31.rst b/Documentation/hwmon/htu31.rst
new file mode 100644
index 000000000000..ccde84264643
--- /dev/null
+++ b/Documentation/hwmon/htu31.rst
@@ -0,0 +1,37 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver HTU31
+====================
+
+Supported chips:
+
+ * Measurement Specialties HTU31
+
+ Prefix: 'htu31'
+
+ Addresses scanned: -
+
+ Datasheet: Publicly available from https://www.te.com/en/product-CAT-HSC0007.html
+
+Author:
+
+ - Andrei Lalaev <andrey.lalaev@gmail.com>
+
+Description
+-----------
+
+HTU31 is a humidity and temperature sensor.
+
+Supported temperature range is from -40 to 125 degrees Celsius.
+
+Communication with the device is performed via I2C protocol. Sensor's default address
+is 0x40.
+
+sysfs-Interface
+---------------
+
+=================== =================
+temp1_input: temperature input
+humidity1_input: humidity input
+heater_enable: heater control
+=================== =================
diff --git a/Documentation/hwmon/hwmon-kernel-api.rst b/Documentation/hwmon/hwmon-kernel-api.rst
index f3276b3a381a..1d7f1397a827 100644
--- a/Documentation/hwmon/hwmon-kernel-api.rst
+++ b/Documentation/hwmon/hwmon-kernel-api.rst
@@ -19,21 +19,11 @@ also read Documentation/hwmon/submitting-patches.rst.
The API
-------
-Each hardware monitoring driver must #include <linux/hwmon.h> and, in most
+Each hardware monitoring driver must #include <linux/hwmon.h> and, in some
cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following
register/unregister functions::
struct device *
- hwmon_device_register_with_groups(struct device *dev, const char *name,
- void *drvdata,
- const struct attribute_group **groups);
-
- struct device *
- devm_hwmon_device_register_with_groups(struct device *dev,
- const char *name, void *drvdata,
- const struct attribute_group **groups);
-
- struct device *
hwmon_device_register_with_info(struct device *dev,
const char *name, void *drvdata,
const struct hwmon_chip_info *info,
@@ -48,56 +38,37 @@ register/unregister functions::
void hwmon_device_unregister(struct device *dev);
- void devm_hwmon_device_unregister(struct device *dev);
-
char *hwmon_sanitize_name(const char *name);
char *devm_hwmon_sanitize_name(struct device *dev, const char *name);
-hwmon_device_register_with_groups registers a hardware monitoring device.
-The first parameter of this function is a pointer to the parent device.
-The name parameter is a pointer to the hwmon device name. The registration
-function wil create a name sysfs attribute pointing to this name.
-The drvdata parameter is the pointer to the local driver data.
-hwmon_device_register_with_groups will attach this pointer to the newly
-allocated hwmon device. The pointer can be retrieved by the driver using
-dev_get_drvdata() on the hwmon device pointer. The groups parameter is
-a pointer to a list of sysfs attribute groups. The list must be NULL terminated.
-hwmon_device_register_with_groups creates the hwmon device with name attribute
-as well as all sysfs attributes attached to the hwmon device.
-This function returns a pointer to the newly created hardware monitoring device
-or PTR_ERR for failure.
-
-devm_hwmon_device_register_with_groups is similar to
-hwmon_device_register_with_groups. However, it is device managed, meaning the
-hwmon device does not have to be removed explicitly by the removal function.
+ void hwmon_lock(struct device *dev);
+ void hwmon_unlock(struct device *dev);
-hwmon_device_register_with_info is the most comprehensive and preferred means
-to register a hardware monitoring device. It creates the standard sysfs
-attributes in the hardware monitoring core, letting the driver focus on reading
-from and writing to the chip instead of having to bother with sysfs attributes.
-The parent device parameter as well as the chip parameter must not be NULL. Its
-parameters are described in more detail below.
+hwmon_device_register_with_info registers a hardware monitoring device.
+It creates the standard sysfs attributes in the hardware monitoring core,
+letting the driver focus on reading from and writing to the chip instead
+of having to bother with sysfs attributes. The parent device parameter
+as well as the chip parameter must not be NULL. Its parameters are described
+in more detail below.
devm_hwmon_device_register_with_info is similar to
hwmon_device_register_with_info. However, it is device managed, meaning the
hwmon device does not have to be removed explicitly by the removal function.
+All other hardware monitoring device registration functions are deprecated
+and must not be used in new drivers.
+
hwmon_device_unregister deregisters a registered hardware monitoring device.
The parameter of this function is the pointer to the registered hardware
monitoring device structure. This function must be called from the driver
remove function if the hardware monitoring device was registered with
-hwmon_device_register_with_groups or hwmon_device_register_with_info.
-
-devm_hwmon_device_unregister does not normally have to be called. It is only
-needed for error handling, and only needed if the driver probe fails after
-the call to devm_hwmon_device_register_with_groups or
-hwmon_device_register_with_info and if the automatic (device managed)
-removal would be too late.
+hwmon_device_register_with_info.
All supported hwmon device registration functions only accept valid device
names. Device names including invalid characters (whitespace, '*', or '-')
-will be rejected. The 'name' parameter is mandatory.
+will be rejected. If NULL is passed as name parameter, the hardware monitoring
+device name will be derived from the parent device name.
If the driver doesn't use a static device name (for example it uses
dev_name()), and therefore cannot make sure the name only contains valid
@@ -111,6 +82,13 @@ devm_hwmon_sanitize_name is the resource managed version of
hwmon_sanitize_name; the memory will be freed automatically on device
removal.
+When using ``[devm_]hwmon_device_register_with_info()`` to register the
+hardware monitoring device, accesses using the associated access functions
+are serialised by the hardware monitoring core. If a driver needs locking
+for other functions such as interrupt handlers or for attributes which are
+fully implemented in the driver, hwmon_lock() and hwmon_unlock() can be used
+to ensure that calls to those functions are serialized.
+
Using devm_hwmon_device_register_with_info()
--------------------------------------------
@@ -133,7 +111,7 @@ The hwmon_chip_info structure looks as follows::
struct hwmon_chip_info {
const struct hwmon_ops *ops;
- const struct hwmon_channel_info **info;
+ const struct hwmon_channel_info * const *info;
};
It contains the following fields:
@@ -191,6 +169,7 @@ It contains following fields:
hwmon_curr Current sensor
hwmon_power Power sensor
hwmon_energy Energy sensor
+ hwmon_energy64 Energy sensor, reported as 64-bit signed value
hwmon_humidity Humidity sensor
hwmon_fan Fan speed sensor
hwmon_pwm PWM control
@@ -229,7 +208,7 @@ register (HWMON_T_MAX) as well as a maximum temperature hysteresis register
.config = lm75_temp_config,
};
- static const struct hwmon_channel_info *lm75_info[] = {
+ static const struct hwmon_channel_info * const lm75_info[] = {
&lm75_chip,
&lm75_temp,
NULL
@@ -238,7 +217,7 @@ register (HWMON_T_MAX) as well as a maximum temperature hysteresis register
The HWMON_CHANNEL_INFO() macro can and should be used when possible.
With this macro, the above example can be simplified to
- static const struct hwmon_channel_info *lm75_info[] = {
+ static const struct hwmon_channel_info * const lm75_info[] = {
HWMON_CHANNEL_INFO(chip,
HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
HWMON_CHANNEL_INFO(temp,
@@ -299,7 +278,7 @@ Parameters:
Return value:
The file mode for this attribute. Typically, this will be 0 (the
- attribute will not be created), S_IRUGO, or 'S_IRUGO | S_IWUSR'.
+ attribute will not be created), 0444, or 0644.
::
@@ -320,6 +299,8 @@ Parameters:
The sensor channel number.
val:
Pointer to attribute value.
+ For hwmon_energy64, `'val`' is passed as `long *` but needs
+ a typecast to `s64 *`.
Return value:
0 on success, a negative error number otherwise.
@@ -351,16 +332,14 @@ Return value:
Driver-provided sysfs attributes
--------------------------------
-If the hardware monitoring device is registered with
-hwmon_device_register_with_info or devm_hwmon_device_register_with_info,
-it is most likely not necessary to provide sysfs attributes. Only additional
-non-standard sysfs attributes need to be provided when one of those registration
-functions is used.
+In most situations it should not be necessary for a driver to provide sysfs
+attributes since the hardware monitoring core creates those internally.
+Only additional non-standard sysfs attributes need to be provided.
The header file linux/hwmon-sysfs.h provides a number of useful macros to
declare and use hardware monitoring sysfs attributes.
-In many cases, you can use the exsting define DEVICE_ATTR or its variants
+In many cases, you can use the existing define DEVICE_ATTR or its variants
DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an
attribute has no additional context. However, in many cases there will be
additional information such as a sensor index which will need to be passed
diff --git a/Documentation/hwmon/ina233.rst b/Documentation/hwmon/ina233.rst
new file mode 100644
index 000000000000..42323162e6db
--- /dev/null
+++ b/Documentation/hwmon/ina233.rst
@@ -0,0 +1,75 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver ina233
+====================
+
+Supported chips:
+
+ * TI INA233
+
+ Prefix: 'ina233'
+
+ * Datasheet
+
+ Publicly available at the TI website : https://www.ti.com/lit/ds/symlink/ina233.pdf
+
+Author: Leo Yang <leo.yang.sy0@gmail.com>
+
+Usage Notes
+-----------
+
+The shunt resistor value can be configured by a device tree property;
+see Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for details.
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for TI INA233.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+The driver provides the following attributes for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for shunt voltage:
+
+**in2_input**
+
+**in2_label**
+
+The driver provides the following attributes for output voltage:
+
+**in3_input**
+
+**in3_label**
+
+**in3_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
diff --git a/Documentation/hwmon/ina238.rst b/Documentation/hwmon/ina238.rst
index d9f479984420..43950d1ec551 100644
--- a/Documentation/hwmon/ina238.rst
+++ b/Documentation/hwmon/ina238.rst
@@ -5,6 +5,24 @@ Kernel driver ina238
Supported chips:
+ * Texas Instruments INA228
+
+ Prefix: 'ina228'
+
+ Addresses: I2C 0x40 - 0x4f
+
+ Datasheet:
+ https://www.ti.com/lit/gpn/ina228
+
+ * Texas Instruments INA237
+
+ Prefix: 'ina237'
+
+ Addresses: I2C 0x40 - 0x4f
+
+ Datasheet:
+ https://www.ti.com/lit/gpn/ina237
+
* Texas Instruments INA238
Prefix: 'ina238'
@@ -14,6 +32,22 @@ Supported chips:
Datasheet:
https://www.ti.com/lit/gpn/ina238
+ * Texas Instruments INA700
+
+ Datasheet:
+ https://www.ti.com/product/ina700
+
+ * Texas Instruments INA780
+
+ Datasheet:
+ https://www.ti.com/product/ina780a
+
+ * Silergy SQ52206
+
+ Prefix: 'SQ52206'
+
+ Addresses: I2C 0x40 - 0x4f
+
Author: Nathan Rossi <nathan.rossi@digi.com>
Description
@@ -23,10 +57,20 @@ The INA238 is a current shunt, power and temperature monitor with an I2C
interface. It includes a number of programmable functions including alerts,
conversion rate, sample averaging and selectable shunt voltage accuracy.
-The shunt value in micro-ohms can be set via platform data or device tree at
-compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
-refer to the Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for bindings
-if the device tree is used.
+The shunt value in micro-ohms can be set via device properties, either from
+platform code or from device tree data. Please refer to
+Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for bindings if
+device tree is used.
+
+INA237 is a functionally equivalent variant of INA238 with slightly
+different accuracy. INA228 is another variant of INA238 with higher ADC
+resolution. This chip also reports the energy.
+
+INA700 and INA780 are variants of the chip series with built-in shunt resistor.
+They also report the energy.
+
+SQ52206 is a mostly compatible chip from Sylergy. It reports the energy
+as well as the peak power consumption.
Sysfs entries
-------------
@@ -47,8 +91,17 @@ in1_max_alarm Maximum shunt voltage alarm
power1_input Power measurement (uW)
power1_max Maximum power threshold (uW)
power1_max_alarm Maximum power alarm
+power1_input_highest Peak Power (uW)
+ (SQ52206 only)
curr1_input Current measurement (mA)
+curr1_min Minimum current threshold (mA)
+curr1_min_alarm Minimum current alarm
+curr1_max Maximum current threshold (mA)
+curr1_max_alarm Maximum current alarm
+
+energy1_input Energy measurement (uJ)
+ (SQ52206, INA237, and INA780 only)
temp1_input Die temperature measurement (mC)
temp1_max Maximum die temperature threshold (mC)
diff --git a/Documentation/hwmon/ina2xx.rst b/Documentation/hwmon/ina2xx.rst
index 27d2e39bc8ac..a3860aae444c 100644
--- a/Documentation/hwmon/ina2xx.rst
+++ b/Documentation/hwmon/ina2xx.rst
@@ -53,6 +53,27 @@ Supported chips:
https://www.ti.com/
+ * Texas Instruments INA260
+
+ Prefix: 'ina260'
+
+ Addresses: I2C 0x40 - 0x4f
+
+ Datasheet: Publicly available at the Texas Instruments website
+
+ https://www.ti.com/
+
+ * Silergy SY24655
+
+ Prefix: 'sy24655'
+
+ Addresses: I2C 0x40 - 0x4f
+
+ Datasheet: Publicly available at the Silergy website
+
+ https://us1.silergy.com/
+
+
Author: Lothar Felten <lothar.felten@gmail.com>
Description
@@ -72,6 +93,14 @@ INA230 and INA231 are high or low side current shunt and power monitors
with an I2C interface. The chips monitor both a shunt voltage drop and
bus supply voltage.
+INA260 is a high or low side current and power monitor with integrated shunt
+resistor.
+
+The SY24655 is a high- and low-side current shunt and power monitor with an I2C
+interface. The SY24655 supports both shunt drop and supply voltage, with
+programmable calibration value and conversion times. The SY24655 can also
+calculate average power for use in energy conversion.
+
The shunt value in micro-ohms can be set via platform data or device tree at
compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
refer to the Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for bindings
@@ -87,18 +116,22 @@ The actual programmed interval may vary from the desired value.
General sysfs entries
---------------------
-======================= ===============================
+======================= ===============================================
in0_input Shunt voltage(mV) channel
in1_input Bus voltage(mV) channel
curr1_input Current(mA) measurement channel
power1_input Power(uW) measurement channel
-shunt_resistor Shunt resistance(uOhm) channel
-======================= ===============================
+shunt_resistor Shunt resistance(uOhm) channel (not for ina260)
+======================= ===============================================
-Sysfs entries for ina226, ina230 and ina231 only
-------------------------------------------------
+Additional sysfs entries for ina226, ina230, ina231, ina260, and sy24655
+------------------------------------------------------------------------
======================= ====================================================
+curr1_lcrit Critical low current
+curr1_crit Critical high current
+curr1_lcrit_alarm Current critical low alarm
+curr1_crit_alarm Current critical high alarm
in0_lcrit Critical low shunt voltage
in0_crit Critical high shunt voltage
in0_lcrit_alarm Shunt voltage critical low alarm
@@ -113,6 +146,13 @@ update_interval data conversion time; affects number of samples used
to average results for shunt and bus voltages.
======================= ====================================================
+Sysfs entries for sy24655 only
+------------------------------
+
+======================= ====================================================
+power1_average average power from last reading to the present.
+======================= ====================================================
+
.. note::
- Configure `shunt_resistor` before configure `power1_crit`, because power
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index c1d11cf13eef..85d7a686883e 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -1,13 +1,14 @@
-=========================
-Linux Hardware Monitoring
-=========================
+.. SPDX-License-Identifier: GPL-2.0
+
+===================
+Hardware Monitoring
+===================
.. toctree::
:maxdepth: 1
hwmon-kernel-api
pmbus-core
- inspur-ipsps1
submitting-patches
sysfs-interface
userspace-tools
@@ -20,10 +21,10 @@ Hardware Monitoring Kernel Drivers
abituguru
abituguru3
+ acbel-fsg032
acpi_power_meter
ad7314
adc128d818
- adm1021
adm1025
adm1026
adm1031
@@ -31,6 +32,7 @@ Hardware Monitoring Kernel Drivers
adm1266
adm1275
adm9240
+ adp1050
ads7828
adt7410
adt7411
@@ -42,16 +44,22 @@ Hardware Monitoring Kernel Drivers
aquacomputer_d5next
asb100
asc7621
+ aspeed-g6-pwm-tach
aspeed-pwm-tacho
asus_ec_sensors
+ asus_rog_ryujin
asus_wmi_sensors
bcm54140
bel-pfe
bpa-rs600
bt1-pvt
+ cgbc-hwmon
+ chipcap2
coretemp
corsair-cpro
corsair-psu
+ cros_ec_hwmon
+ crps
da9052
da9055
dell-smm-hwmon
@@ -71,25 +79,36 @@ Hardware Monitoring Kernel Drivers
ftsteutates
g760a
g762
+ gigabyte_waterforce
gsc-hwmon
gl518sm
+ gpd-fan
+ gxp-fan-ctrl
hih6130
+ hp-wmi-sensors
+ hs3001
+ htu31
ibmaem
ibm-cffps
ibmpowernv
ina209
ina2xx
+ ina233
ina238
ina3221
+ inspur-ipsps1
intel-m10-bmc-hwmon
ir35221
ir38064
ir36021
+ isl28022
isl68137
it87
jc42
k10temp
k8temp
+ kbatt
+ kfan
lan966x
lineage-pem
lm25066
@@ -109,18 +128,23 @@ Hardware Monitoring Kernel Drivers
lm95234
lm95245
lochnagar
+ lt3074
lt7182s
ltc2992
ltc2945
ltc2947
ltc2978
ltc2990
+ ltc2991
ltc3815
ltc4151
ltc4215
ltc4245
ltc4260
ltc4261
+ ltc4282
+ ltc4286
+ macsmc-hwmon
max127
max15301
max16064
@@ -128,6 +152,7 @@ Hardware Monitoring Kernel Drivers
max1619
max16601
max1668
+ max17616
max197
max20730
max20751
@@ -136,28 +161,44 @@ Hardware Monitoring Kernel Drivers
max31760
max31785
max31790
+ max31827
max34440
max6620
max6639
- max6642
max6650
max6697
+ max77705
max8688
mc13783-adc
+ mc33xs2410_hwmon
+ mc34vr500
mcp3021
menf21bmc
mlxreg-fan
+ mp2856
+ mp2869
mp2888
+ mp2891
+ mp2925
+ mp29502
mp2975
+ mp2993
mp5023
+ mp5920
+ mp5990
+ mp9941
+ mp9945
+ mpq8785
nct6683
nct6775
+ nct7363
nct7802
nct7904
npcm750-pwm-fan
nsa320
ntc_thermistor
nzxt-kraken2
+ nzxt-kraken3
nzxt-smart2
occ
pc87360
@@ -169,16 +210,22 @@ Hardware Monitoring Kernel Drivers
peci-cputemp
peci-dimmtemp
pmbus
+ powerz
powr1220
+ pt5161l
pxe1610
pwm-fan
q54sj108a2
+ qnap-mcu-hwmon
raspberrypi-hwmon
+ sa67
sbrmi
sbtsi_temp
sch5627
sch5636
scpi-hwmon
+ sfctemp
+ sg2042-mcu
sht15
sht21
sht3x
@@ -186,12 +233,14 @@ Hardware Monitoring Kernel Drivers
shtc1
sis5595
sl28cpld
- smm665
+ smpro-hwmon
smsc47b397
smsc47m192
smsc47m1
sparx5-temp
+ spd5118
stpddc60
+ surface_fan
sy7636a-hwmon
tc654
tc74
@@ -204,9 +253,11 @@ Hardware Monitoring Kernel Drivers
tmp464
tmp513
tps23861
+ tps25990
tps40422
tps53679
tps546d24
+ tsc1641
twl4030-madc-hwmon
ucd9000
ucd9200
@@ -226,6 +277,7 @@ Hardware Monitoring Kernel Drivers
wm831x
wm8350
xgene-hwmon
+ xdp710
xdpe12284
xdpe152c4
zl6100
diff --git a/Documentation/hwmon/isl28022.rst b/Documentation/hwmon/isl28022.rst
new file mode 100644
index 000000000000..273ce5460135
--- /dev/null
+++ b/Documentation/hwmon/isl28022.rst
@@ -0,0 +1,64 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver isl28022
+======================
+
+Supported chips:
+
+ * Renesas ISL28022
+
+ Prefix: 'isl28022'
+
+ Addresses scanned: none
+
+ Datasheet: Publicly available at the Renesas website
+
+ https://www.renesas.com/us/en/www/doc/datasheet/isl28022.pdf
+
+Author:
+ Carsten Spieß <mail@carsten-spiess.de>
+
+Description
+-----------
+
+The ISL28022 is a power monitor with I2C interface. The device monitors
+voltage, current via shunt resistor and calculated power.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+device explicitly. Please see Documentation/i2c/instantiating-devices.rst for
+details.
+
+The shunt value in micro-ohms, shunt voltage range and averaging can be set
+with device properties.
+Please refer to the Documentation/devicetree/bindings/hwmon/renesas,isl28022.yaml
+for bindings if the device tree is used.
+
+The driver supports only shunt and bus continuous ADC mode at 15bit resolution.
+Averaging can be set from 1 to 128 samples (power of 2) on both channels.
+Shunt voltage range of 40, 80, 160 or 320mV is allowed
+The bus voltage range is 60V fixed.
+
+Sysfs entries
+-------------
+
+The following attributes are supported. All attributes are read-only.
+
+======================= =======================================================
+in0_input bus voltage (milli Volt)
+in1_input shunt voltage (milli Volt)
+
+curr1_input current (milli Ampere)
+power1_input power (micro Watt)
+======================= =======================================================
+
+Debugfs entries
+---------------
+
+The following attributes are supported. All attributes are read-only.
+
+======================= =======================================================
+shunt_voltage shunt voltage (micro Volt)
+======================= =======================================================
diff --git a/Documentation/hwmon/isl68137.rst b/Documentation/hwmon/isl68137.rst
index 0e71b22047f8..e77f582c2850 100644
--- a/Documentation/hwmon/isl68137.rst
+++ b/Documentation/hwmon/isl68137.rst
@@ -374,6 +374,26 @@ Supported chips:
Publicly available (after August 2020 launch) at the Renesas website
+ * Renesas RAA228244
+
+ Prefix: 'raa228244'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
+ * Renesas RAA228246
+
+ Prefix: 'raa228246'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
* Renesas RAA229001
Prefix: 'raa229001'
@@ -394,6 +414,16 @@ Supported chips:
Publicly available (after August 2020 launch) at the Renesas website
+ * Renesas RAA229141
+
+ Prefix: 'raa229141'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
Authors:
- Maxim Sloyko <maxims@google.com>
- Robert Lippert <rlippert@google.com>
diff --git a/Documentation/hwmon/it87.rst b/Documentation/hwmon/it87.rst
index 2d83f23bee93..5cef4f265000 100644
--- a/Documentation/hwmon/it87.rst
+++ b/Documentation/hwmon/it87.rst
@@ -145,6 +145,22 @@ Supported chips:
Datasheet: Not publicly available
+ * IT8792E/IT8795E
+
+ Prefix: 'it8792'
+
+ Addresses scanned: from Super I/O config space (8 I/O ports)
+
+ Datasheet: Not publicly available
+
+ * IT87952E
+
+ Prefix: 'it87952'
+
+ Addresses scanned: from Super I/O config space (8 I/O ports)
+
+ Datasheet: Not publicly available
+
* SiS950 [clone of IT8705F]
Prefix: 'it87'
@@ -162,7 +178,7 @@ Authors:
Module Parameters
-----------------
-* update_vbat: int
+* update_vbat bool
0 if vbat should report power on value, 1 if vbat should be updated after
each read. Default is 0. On some boards the battery voltage is provided
by either the battery or the onboard power supply. Only the first reading
@@ -171,11 +187,31 @@ Module Parameters
the chip so can be read at any time. Excessive reading may decrease
battery life but no information is given in the datasheet.
-* fix_pwm_polarity int
+* fix_pwm_polarity bool
Force PWM polarity to active high (DANGEROUS). Some chips are
misconfigured by BIOS - PWM values would be inverted. This option tries
to fix this. Please contact your BIOS manufacturer and ask him for fix.
+* force_id short, short
+
+ Force multiple chip ID to specified value, separated by ','.
+ For example "force_id=0x8689,0x8633". A value of 0 is ignored
+ for that chip.
+ Note: A single force_id value (e.g. "force_id=0x8689") is used for
+ all chips, to only set the first chip use "force_id=0x8689,0".
+ Should only be used for testing.
+
+* ignore_resource_conflict bool
+
+ Similar to acpi_enforce_resources=lax, but only affects this driver.
+ ACPI resource conflicts are ignored if this parameter is provided and
+ set to 1.
+ Provided since there are reports that system-wide acpi_enfore_resources=lax
+ can result in boot failures on some systems.
+ Note: This is inherently risky since it means that both ACPI and this driver
+ may access the chip at the same time. This can result in race conditions and,
+ worst case, result in unexpected system reboots.
+
Hardware Interfaces
-------------------
@@ -193,8 +229,8 @@ Description
This driver implements support for the IT8603E, IT8620E, IT8623E, IT8628E,
IT8705F, IT8712F, IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8732F,
-IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, IT8786E, IT8790E, and
-SiS950 chips.
+IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, IT8786E, IT8790E,
+IT8792E/IT8795E, IT87952E and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -238,7 +274,8 @@ of the fan is not supported (value 0 of pwmX_enable).
The IT8620E and IT8628E are custom designs, hardware monitoring part is similar
to IT8728F. It only supports 16-bit fan mode. Both chips support up to 6 fans.
-The IT8790E supports up to 3 fans. 16-bit fan mode is always enabled.
+The IT8790E, IT8792E/IT8795E and IT87952E support up to 3 fans. 16-bit fan
+mode is always enabled.
The IT8732F supports a closed-loop mode for fan control, but this is not
currently implemented by the driver.
diff --git a/Documentation/hwmon/jc42.rst b/Documentation/hwmon/jc42.rst
index 19d10512f6c0..3736e63db2a8 100644
--- a/Documentation/hwmon/jc42.rst
+++ b/Documentation/hwmon/jc42.rst
@@ -33,7 +33,7 @@ Supported chips:
Datasheets:
- http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6604.pdf
* Microchip MCP9804, MCP9805, MCP9808, MCP98242, MCP98243, MCP98244, MCP9843
diff --git a/Documentation/hwmon/kbatt.rst b/Documentation/hwmon/kbatt.rst
new file mode 100644
index 000000000000..b72718c5ede3
--- /dev/null
+++ b/Documentation/hwmon/kbatt.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver kbatt
+===================
+
+Supported chips:
+
+ * KEBA battery monitoring controller (IP core in FPGA)
+
+ Prefix: 'kbatt'
+
+Authors:
+
+ Gerhard Engleder <eg@keba.com>
+ Petar Bojanic <boja@keba.com>
+
+Description
+-----------
+
+The KEBA battery monitoring controller is an IP core for FPGAs, which
+monitors the health of a coin cell battery. The coin cell battery is
+typically used to supply the RTC during power off to keep the current
+time. E.g., the CP500 FPGA includes this IP core to monitor the coin cell
+battery of PLCs and the corresponding cp500 driver creates an auxiliary
+device for the kbatt driver.
+
+This driver provides information about the coin cell battery health to
+user space. Actually the user space shall be informed that the coin cell
+battery is nearly empty and needs to be replaced.
+
+The coin cell battery must be tested actively to get to know if its nearly
+empty or not. Therefore, a load is put on the coin cell battery and the
+resulting voltage is evaluated. This evaluation is done by some hard wired
+analog logic, which compares the voltage to a defined limit. If the
+voltage is above the limit, then the coin cell battery is assumed to be
+ok. If the voltage is below the limit, then the coin cell battery is
+nearly empty (or broken, removed, ...) and shall be replaced by a new one.
+The KEBA battery monitoring controller allows to start the test of the
+coin cell battery and to get the result if the voltage is above or below
+the limit. The actual voltage is not available. Only the information if
+the voltage is below a limit is available.
+
+The test load, which is put on the coin cell battery for the health check,
+is similar to the load during power off. Therefore, the lifetime of the
+coin cell battery is reduced directly by the duration of each test. To
+limit the negative impact to the lifetime the test is limited to at most
+once every 10 seconds. The test load is put on the coin cell battery for
+100ms. Thus, in worst case the coin cell battery lifetime is reduced by
+1% of the uptime or 3.65 days per year. As the coin cell battery lasts
+multiple years, this lifetime reduction negligible.
+
+This driver only provides a single alarm attribute, which is raised when
+the coin cell battery is nearly empty.
+
+====================== ==== ===================================================
+Attribute R/W Contents
+====================== ==== ===================================================
+in0_min_alarm R voltage of coin cell battery under load is below
+ limit
+====================== ==== ===================================================
diff --git a/Documentation/hwmon/kfan.rst b/Documentation/hwmon/kfan.rst
new file mode 100644
index 000000000000..ce02dddfb4b8
--- /dev/null
+++ b/Documentation/hwmon/kfan.rst
@@ -0,0 +1,39 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver kfan
+==================
+
+Supported chips:
+
+ * KEBA fan controller (IP core in FPGA)
+
+ Prefix: 'kfan'
+
+Authors:
+
+ Gerhard Engleder <eg@keba.com>
+ Petar Bojanic <boja@keba.com>
+
+Description
+-----------
+
+The KEBA fan controller is an IP core for FPGAs, which monitors the health
+and controls the speed of a fan. The fan is typically used to cool the CPU
+and the whole device. E.g., the CP500 FPGA includes this IP core to monitor
+and control the fan of PLCs and the corresponding cp500 driver creates an
+auxiliary device for the kfan driver.
+
+This driver provides information about the fan health to user space.
+The user space shall be informed if the fan is removed or blocked.
+Additionally, the speed in RPM is reported for fans with tacho signal.
+
+For fan control PWM is supported. For PWM 255 equals 100%. None-regulable
+fans can be turned on with PWM 255 and turned off with PWM 0.
+
+====================== ==== ===================================================
+Attribute R/W Contents
+====================== ==== ===================================================
+fan1_fault R Fan fault
+fan1_input R Fan tachometer input (in RPM)
+pwm1 RW Fan target duty cycle (0..255)
+====================== ==== ===================================================
diff --git a/Documentation/hwmon/lm70.rst b/Documentation/hwmon/lm70.rst
index 11303a7e16a8..02ed60dddffb 100644
--- a/Documentation/hwmon/lm70.rst
+++ b/Documentation/hwmon/lm70.rst
@@ -5,7 +5,7 @@ Supported chips:
* National Semiconductor LM70
- Datasheet: http://www.national.com/pf/LM/LM70.html
+ Datasheet: https://www.ti.com/product/LM70
* Texas Instruments TMP121/TMP123
diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst
index 8d0ab4ad5fb5..4269da04508e 100644
--- a/Documentation/hwmon/lm75.rst
+++ b/Documentation/hwmon/lm75.rst
@@ -23,15 +23,17 @@ Supported chips:
http://www.national.com/
- * Dallas Semiconductor (now Maxim) DS75, DS1775, DS7505
+ * Dallas Semiconductor (now Analog Devices) DS75, DS1775, DS7505
Prefixes: 'ds75', 'ds1775', 'ds7505'
Addresses scanned: none
- Datasheet: Publicly available at the Maxim website
+ Datasheets:
- https://www.maximintegrated.com/
+ https://www.analog.com/media/en/technical-documentation/data-sheets/DS75.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/DS1775.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/DS7505.pdf
* Maxim MAX6625, MAX6626, MAX31725, MAX31726
@@ -39,9 +41,10 @@ Supported chips:
Addresses scanned: none
- Datasheet: Publicly available at the Maxim website
+ Datasheets:
- http://www.maxim-ic.com/
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6625-MAX6626.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31725-MAX31726.pdf
* Microchip (TelCom) TCN75
@@ -121,18 +124,32 @@ Supported chips:
https://www.ti.com/product/TMP1075
- * NXP LM75B, PCT2075
+ * NXP LM75B, P3T1750, P3T1755, PCT2075
- Prefix: 'lm75b', 'pct2075'
+ Prefix: 'lm75b', 'p3t1750', 'p3t1755', 'pct2075'
Addresses scanned: none
Datasheet: Publicly available at the NXP website
- https://www.nxp.com/documents/data_sheet/LM75B.pdf
+ https://www.nxp.com/docs/en/data-sheet/LM75B.pdf
+
+ https://www.nxp.com/docs/en/data-sheet/P3T1750DP.pdf
+
+ https://www.nxp.com/docs/en/data-sheet/P3T1755.pdf
https://www.nxp.com/docs/en/data-sheet/PCT2075.pdf
+ * AMS OSRAM AS6200
+
+ Prefix: 'as6200'
+
+ Addresses scanned: none
+
+ Datasheet: Publicly available at the AMS website
+
+ https://ams.com/documents/20143/36005/AS6200_DS000449_4-00.pdf
+
Author: Frodo Looijaard <frodol@dds.nl>
Description
diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst
index 23af17a0ab44..79c023521d39 100644
--- a/Documentation/hwmon/lm90.rst
+++ b/Documentation/hwmon/lm90.rst
@@ -9,7 +9,9 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet: Publicly available at the National Semiconductor website
+ Datasheet: Publicly available at the TI website
+
+ https://www.ti.com/lit/ds/symlink/lm84.pdf
* National Semiconductor LM90
@@ -17,9 +19,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the National Semiconductor website
+ Datasheet: Publicly available at the TI website
- http://www.national.com/pf/LM/LM90.html
+ https://www.ti.com/lit/ds/symlink/lm90.pdf
* National Semiconductor LM89
@@ -27,9 +29,9 @@ Supported chips:
Addresses scanned: I2C 0x4c and 0x4d
- Datasheet: Publicly available at the National Semiconductor website
+ Datasheet: Publicly available at the TI website
- http://www.national.com/mpf/LM/LM89.html
+ https://www.ti.com/lit/ds/symlink/lm89.pdf
* National Semiconductor LM99
@@ -37,9 +39,9 @@ Supported chips:
Addresses scanned: I2C 0x4c and 0x4d
- Datasheet: Publicly available at the National Semiconductor website
+ Datasheet: Publicly available at the TI website
- http://www.national.com/pf/LM/LM99.html
+ https://www.ti.com/lit/ds/symlink/lm99.pdf
* National Semiconductor LM86
@@ -47,9 +49,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the National Semiconductor website
+ Datasheet: Publicly available at the TI website
- http://www.national.com/mpf/LM/LM86.html
+ https://www.ti.com/lit/ds/symlink/lm86.pdf
* Analog Devices ADM1020
@@ -57,7 +59,9 @@ Supported chips:
Addresses scanned: I2C 0x4c - 0x4e
- Datasheet: Publicly available at the Analog Devices website
+ Datasheet: Publicly available at the DigiKey website
+
+ https://media.digikey.com/pdf/Data%20Sheets/Analog%20Devices%20PDFs/ADM1020.pdf
* Analog Devices ADM1021
@@ -65,7 +69,9 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet: Publicly available at the Analog Devices website
+ Datasheet: Publicly available at the DigiKey website
+
+ https://media.digikey.com/pdf/Data%20Sheets/Analog%20Devices%20PDFs/ADM1021.pdf
* Analog Devices ADM1021A/ADM1023
@@ -75,15 +81,18 @@ Supported chips:
Datasheet: Publicly available at the Analog Devices website
+ https://media.digikey.com/pdf/Data%20Sheets/Analog%20Devices%20PDFs/ADM1021A.pdf
+ https://media.digikey.com/pdf/Data%20Sheets/Analog%20Devices%20PDFs/ADM1023.pdf
+
* Analog Devices ADM1032
Prefix: 'adm1032'
Addresses scanned: I2C 0x4c and 0x4d
- Datasheet: Publicly available at the ON Semiconductor website
+ Datasheet: Publicly available at the DigiKey website
- https://www.onsemi.com/PowerSolutions/product.do?id=ADM1032
+ https://www.digikey.com/htmldatasheets/production/53140/0/0/1/ADM1032.pdf
* Analog Devices ADT7461
@@ -111,9 +120,9 @@ Supported chips:
Addresses scanned: I2C 0x4b and 0x4c
- Datasheet: Publicly available at the ON Semiconductor website
+ Datasheet: Publicly available at the DigiKey website
- https://www.onsemi.com/PowerSolutions/product.do?id=ADT7481
+ https://www.digikey.com/htmldatasheets/production/234607/0/0/1/ADT7481.pdf
* Analog Devices ADT7482
@@ -191,7 +200,9 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1617.pdf
* Maxim MAX1617A
@@ -199,7 +210,9 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1617A.pdf
* Maxim MAX6642
@@ -207,9 +220,9 @@ Supported chips:
Addresses scanned: I2C 0x48-0x4f
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://datasheets.maxim-ic.com/en/ds/MAX6642.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6642.pdf
* Maxim MAX6646
@@ -217,9 +230,9 @@ Supported chips:
Addresses scanned: I2C 0x4d
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6646-MAX6649.pdf
* Maxim MAX6647
@@ -227,9 +240,9 @@ Supported chips:
Addresses scanned: I2C 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6646-MAX6649.pdf
* Maxim MAX6648
@@ -237,9 +250,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6648-MAX6692.pdf
* Maxim MAX6649
@@ -247,9 +260,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1617.pdf
* Maxim MAX6654
@@ -259,9 +272,9 @@ Supported chips:
0x4c, 0x4d and 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- https://www.maximintegrated.com/en/products/sensors/MAX6654.html
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6654.pdf
* Maxim MAX6657
@@ -269,9 +282,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6657-MAX6659.pdf
* Maxim MAX6658
@@ -279,9 +292,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6657-MAX6659.pdf
* Maxim MAX6659
@@ -289,9 +302,9 @@ Supported chips:
Addresses scanned: I2C 0x4c, 0x4d, 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6657-MAX6659.pdf
* Maxim MAX6680
@@ -301,9 +314,9 @@ Supported chips:
0x4c, 0x4d and 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6680-MAX6681.pdf
* Maxim MAX6681
@@ -313,9 +326,9 @@ Supported chips:
0x4c, 0x4d and 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6680-MAX6681.pdf
* Maxim MAX6692
@@ -323,9 +336,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6648-MAX6692.pdf
* Maxim MAX6695
@@ -333,9 +346,9 @@ Supported chips:
Addresses scanned: I2C 0x18
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/datasheet/index.mvp/id/4199
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6695-MAX6696.pdf
* Maxim MAX6696
@@ -345,9 +358,9 @@ Supported chips:
0x4c, 0x4d and 0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet: Publicly available at the Analog Devices website
- http://www.maxim-ic.com/datasheet/index.mvp/id/4199
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6695-MAX6696.pdf
* Winbond/Nuvoton W83L771W/G
@@ -355,7 +368,9 @@ Supported chips:
Addresses scanned: I2C 0x4c
- Datasheet: No longer available
+ Datasheet: Publicly available at the DigiKey website
+
+ https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/1128/W83L771W%2CW83L771G.pdf
* Winbond/Nuvoton W83L771AWG/ASG
@@ -365,6 +380,34 @@ Supported chips:
Datasheet: Not publicly available, can be requested from Nuvoton
+ * Nuvoton NCT7716
+
+ Prefix: 'nct7716'
+
+ Addresses scanned: I2C 0x48, 0x49
+
+ Datasheet: Not publicly available, can be requested from Nuvoton
+
+ * Nuvoton NCT7717
+
+ Prefix: 'nct7717'
+
+ Addresses scanned: I2C 0x48
+
+ Datasheet: Publicly available at Nuvoton website
+
+ https://www.nuvoton.com/resource-files/Nuvoton_NCT7717U_Datasheet_V111.pdf
+
+ * Nuvoton NCT7718
+
+ Prefix: 'nct7718'
+
+ Addresses scanned: I2C 0x4c
+
+ Datasheet: Publicly available at Nuvoton website
+
+ https://www.nuvoton.com/resource-files/Nuvoton_NCT7718W_Datasheet_V11.pdf
+
* Philips/NXP SA56004X
Prefix: 'sa56004'
@@ -373,7 +416,7 @@ Supported chips:
Datasheet: Publicly available at NXP website
- http://ics.nxp.com/products/interface/datasheet/sa56004x.pdf
+ https://www.nxp.com/docs/en/data-sheet/SA56004X.pdf
* GMT G781
@@ -409,7 +452,9 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheets: Publicly available at the Philips website
+ Datasheets: Publicly available at the DigiKey website
+
+ https://www.digikey.com/htmldatasheets/production/97606/0/0/1/ne1617.pdf
* Philips NE1618
@@ -417,7 +462,9 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheets: Publicly available at the Philips website
+ Datasheets: Publicly available at the DigiKey website
+
+ https://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/NE1618.pdf
* Genesys Logic GL523SM
@@ -425,7 +472,7 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet:
+ Datasheet: No longer available at Genesys Logic website
* TI THMC10
@@ -433,7 +480,7 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet: Publicly available at the TI website
+ Datasheet: No longer available at the TI website
* Onsemi MC1066
@@ -441,7 +488,7 @@ Supported chips:
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
- Datasheet: Publicly available at the Onsemi website
+ Datasheet: No longer available at the Onsemi website
Author: Jean Delvare <jdelvare@suse.de>
@@ -573,6 +620,21 @@ W83L771AWG/ASG
* The AWG and ASG variants only differ in package format.
* Diode ideality factor configuration (remote sensor) at 0xE3
+NCT7716:
+ * 8 bit sensor resolution
+ * Selectable address
+ * Configurable conversion rate
+
+NCT7717:
+ * 8 bit sensor resolution
+ * Configurable conversion rate
+
+NCT7718:
+ * Temperature offset register for remote temperature sensor
+ * 11 bit resolution for remote temperature sensor
+ * Low temperature limits
+ * Configurable conversion rate
+
SA56004X:
* Better local resolution
diff --git a/Documentation/hwmon/lm92.rst b/Documentation/hwmon/lm92.rst
index c131b923ed36..d71cdb2af339 100644
--- a/Documentation/hwmon/lm92.rst
+++ b/Documentation/hwmon/lm92.rst
@@ -3,29 +3,29 @@ Kernel driver lm92
Supported chips:
- * National Semiconductor LM92
+ * National Semiconductor / Texas Instruments LM92
Prefix: 'lm92'
Addresses scanned: I2C 0x48 - 0x4b
- Datasheet: http://www.national.com/pf/LM/LM92.html
+ Datasheet: https://www.ti.com/lit/gpn/LM92
- * National Semiconductor LM76
+ * National Semiconductor / Texas Instruments LM76
Prefix: 'lm92'
- Addresses scanned: none, force parameter needed
+ Addresses scanned: none, must be instantiated explicitly
- Datasheet: http://www.national.com/pf/LM/LM76.html
+ Datasheet: https://www.ti.com/lit/gpn/LM76
- * Maxim MAX6633/MAX6634/MAX6635
+ * Maxim /Analog Devices MAX6633/MAX6634/MAX6635
Prefix: 'max6635'
- Addresses scanned: none, force parameter needed
+ Addresses scanned: none, must be instantiated explicitly
- Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6633-max6635.pdf
Authors:
@@ -36,13 +36,13 @@ Authors:
Description
-----------
-This driver implements support for the National Semiconductor LM92
-temperature sensor.
+This driver implements support for the National Semiconductor / Texas
+Instruments LM92 temperature sensor.
Each LM92 temperature sensor supports a single temperature sensor. There are
alarms for high, low, and critical thresholds. There's also an hysteresis to
control the thresholds for resetting alarms.
-Support was added later for the LM76 and Maxim MAX6633/MAX6634/MAX6635,
-which are mostly compatible. They have not all been tested, so you
-may need to use the force parameter.
+The driver also supports LM76 and Maxim MAX6633/MAX6634/MAX6635, which are
+mostly compatible but do not have a vendor ID register and therefore must be
+instantiated explicitly.
diff --git a/Documentation/hwmon/lt3074.rst b/Documentation/hwmon/lt3074.rst
new file mode 100644
index 000000000000..234f369153cf
--- /dev/null
+++ b/Documentation/hwmon/lt3074.rst
@@ -0,0 +1,72 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver lt3074
+====================
+
+Supported chips:
+
+ * Analog Devices LT3074
+
+ Prefix: 'lt3074'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/lt3074.html
+
+Authors: Cedric Encarnacion <cedricjustine.encarnacion@analog.com>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices LT3074 Linear
+Regulator with PMBus interface.
+
+The LT3074 is a low voltage, ultra-low noise and ultra-fast transient
+response linear regulator with PMBus serial interface. PMBus telemetry
+feature provides information regarding the output voltage and current,
+input voltage, bias voltage and die temperature.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate
+the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst
+for details.
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+Sysfs entries
+-------------
+
+======================= =======================================================
+in1_label "vin"
+in1_input Measured input voltage
+in1_max Input overvoltage warning limit
+in1_max_alarm Input overvoltage warning status
+in1_min Input undervoltage warning limit
+in1_min_alarm Input undervoltage warning status
+in2_label "vmon"
+in2_input Measured bias voltage
+in2_max Bias overvoltage warning limit
+in2_min Bias undervoltage warning limit
+in3_label "vout1"
+in3_input Measured output voltage
+in3_max Output overvoltage warning limit
+in3_max_alarm Output overvoltage warning status
+in3_min Output undervoltage warning limit
+in3_min_alarm Output undervoltage warning status
+curr1_label "iout1"
+curr1_input Measured output current.
+curr1_crit Output overcurrent fault limit
+curr1_crit_alarm Output overcurrent fault status
+temp1_input Measured temperature
+temp1_max Maximum temperature limit
+temp1_max_alarm Overtemperature warning status
+======================= =======================================================
diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst
index b99a63965cfb..0b72d566cac7 100644
--- a/Documentation/hwmon/ltc2978.rst
+++ b/Documentation/hwmon/ltc2978.rst
@@ -1,8 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
Kernel driver ltc2978
=====================
Supported chips:
+ * Analog Devices LT7170
+
+ Prefix: 'lt7170'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/lt7170.html
+
+ * Analog Devices LT7171
+
+ Prefix: 'lt7171'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/lt7171.html
+
* Linear Technology LTC2972
Prefix: 'ltc2972'
@@ -117,6 +135,14 @@ Supported chips:
Datasheet: https://www.analog.com/en/products/ltc3889
+ * Linear Technology LTC7841
+
+ Prefix: 'ltc7841'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltc7841
+
* Linear Technology LTC7880
Prefix: 'ltc7880'
@@ -141,6 +167,14 @@ Supported chips:
Datasheet: https://www.analog.com/en/products/ltm4644
+ * Linear Technology LTM4673
+
+ Prefix: 'ltm4673'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltm4673
+
* Linear Technology LTM4675
Prefix: 'ltm4675'
@@ -205,6 +239,8 @@ Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
+- LT7170 and LT7171 are 20 A, 16 V, single- or dual-phase Silent Switcher
+- step-down regulators with Digital Power System Management.
- LTC2974 and LTC2975 are quad digital power supply managers.
- LTC2978 is an octal power supply monitor.
- LTC2977 is a pin compatible replacement for LTC2978.
@@ -282,6 +318,7 @@ in1_reset_history Reset input voltage history.
in[N]_label "vout[1-8]".
+ - LT7170, LT7171: N=2
- LTC2972: N=2-3
- LTC2974, LTC2975: N=2-5
- LTC2977, LTC2979, LTC2980, LTM2987: N=2-9
@@ -290,6 +327,7 @@ in[N]_label "vout[1-8]".
LTC7880, LTM4644, LTM4675, LTM4676, LTM4677, LTM4678,
LTM4680, LTM4700: N=2-3
- LTC3883: N=2
+ - LTC7841: N=2
in[N]_input Measured output voltage.
@@ -319,6 +357,8 @@ in[N]_reset_history Reset output voltage history.
temp[N]_input Measured temperature.
+ - On LT7170 and LT7171, temp1 reports the chip
+ temperature.
- On LTC2972, temp[1-2] report external temperatures,
and temp 3 reports the chip temperature.
- On LTC2974 and LTC2975, temp[1-4] report external
@@ -333,7 +373,7 @@ temp[N]_input Measured temperature.
- On LTC3883, temp1 reports an external temperature,
and temp2 reports the chip temperature.
-temp[N]_min Mimimum temperature.
+temp[N]_min Minimum temperature.
LTC2972, LTC2974, LCT2977, LTM2980, LTC2978,
LTC2979, and LTM2987 only.
@@ -392,9 +432,9 @@ power[N]_input Measured output power.
curr1_label "iin".
- LTC3880, LTC3883, LTC3884, LTC3886, LTC3887, LTC3889,
- LTM4644, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680,
- and LTM4700 only.
+ LT7170, LT7171, LTC3880, LTC3883, LTC3884, LTC3886,
+ LTC3887, LTC3889, LTM4644, LTM4675, LTM4676, LTM4677,
+ LTM4678, LTM4680, and LTM4700 only.
curr1_input Measured input current.
@@ -412,6 +452,7 @@ curr1_reset_history Reset input current history.
curr[N]_label "iout[1-4]".
+ - LT7170, LT7171: N=1
- LTC2972: N-1-2
- LTC2974, LTC2975: N=1-4
- LTC2977, LTC2979, LTC2980, LTM2987: not supported
@@ -420,6 +461,7 @@ curr[N]_label "iout[1-4]".
LTM4664, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680,
LTM4700: N=2-3
- LTC3883: N=2
+ - LTC7841: N=2
curr[N]_input Measured output current.
diff --git a/Documentation/hwmon/ltc2991.rst b/Documentation/hwmon/ltc2991.rst
new file mode 100644
index 000000000000..15d8b4d7e471
--- /dev/null
+++ b/Documentation/hwmon/ltc2991.rst
@@ -0,0 +1,43 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver ltc2991
+=====================
+
+Supported chips:
+
+ * Analog Devices LTC2991
+
+ Prefix: 'ltc2991'
+
+ Addresses scanned: I2C 0x48 - 0x4f
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/2991ff.pdf
+
+Authors:
+
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices LTC2991 Octal I2C
+Voltage, Current and Temperature Monitor.
+
+The LTC2991 is used to monitor system temperatures, voltages and currents.
+Through the I2C serial interface, the eight monitors can individually measure
+supply voltages and can be paired for differential measurements of current sense
+resistors or temperature sensing transistors. Additional measurements include
+internal temperatureand internal VCC.
+
+
+sysfs-Interface
+---------------
+
+The following attributes are supported. Limits are read-only.
+
+=============== =================
+inX_input: voltage input
+currX_input: current input
+tempX_input: temperature input
+=============== =================
diff --git a/Documentation/hwmon/ltc4282.rst b/Documentation/hwmon/ltc4282.rst
new file mode 100644
index 000000000000..a87ec3564998
--- /dev/null
+++ b/Documentation/hwmon/ltc4282.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel drivers ltc4282
+==========================================
+
+Supported chips:
+
+ * Analog Devices LTC4282
+
+ Prefix: 'ltc4282'
+
+ Addresses scanned: - I2C 0x40 - 0x5A (7-bit)
+ Addresses scanned: - I2C 0x80 - 0xB4 with a step of 2 (8-bit)
+
+ Datasheet:
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4282.pdf
+
+Author: Nuno Sá <nuno.sa@analog.com>
+
+Description
+___________
+
+The LTC4282 hot swap controller allows a board to be safely inserted and removed
+from a live backplane. Using one or more external N-channel pass transistors,
+board supply voltage and inrush current are ramped up at an adjustable rate. An
+I2C interface and onboard ADC allows for monitoring of board current, voltage,
+power, energy and fault status. The device features analog foldback current
+limiting and supply monitoring for applications from 2.9V to 33V. Dual 12V gate
+drive allows high power applications to either share safe operating area across
+parallel MOSFETs or support a 2-stage start-up that first charges the load
+capacitance followed by enabling a low on-resistance path to the load. The
+LTC4282 is well suited to high power applications because the precise monitoring
+capability and accurate current limiting reduce the extremes in which both loads
+and power supplies must safely operate. Non-volatile configuration allows for
+flexibility in the autonomous generation of alerts and response to faults.
+
+Sysfs entries
+_____________
+
+The following attributes are supported. Limits are read-write and all the other
+attributes are read-only. Note that in0 and in1 are mutually exclusive. Enabling
+one disables the other and disabling one enables the other.
+
+======================= ==========================================
+in0_input Output voltage (mV).
+in0_min Undervoltage threshold
+in0_max Overvoltage threshold
+in0_lowest Lowest measured voltage
+in0_highest Highest measured voltage
+in0_reset_history Write 1 to reset in0 history.
+ Also clears fet bad and short fault logs.
+in0_min_alarm Undervoltage alarm
+in0_max_alarm Overvoltage alarm
+in0_enable Enable/Disable VSOURCE monitoring
+in0_fault Failure in the MOSFETs. Either bad or shorted FET.
+in0_label Channel label (VSOURCE)
+
+in1_input Input voltage (mV).
+in1_min Undervoltage threshold
+in1_max Overvoltage threshold
+in1_lowest Lowest measured voltage
+in1_highest Highest measured voltage
+in1_reset_history Write 1 to reset in1 history.
+ Also clears over/undervoltage fault logs.
+in1_min_alarm Undervoltage alarm
+in1_max_alarm Overvoltage alarm
+in1_lcrit_alarm Critical Undervoltage alarm
+in1_crit_alarm Critical Overvoltage alarm
+in1_enable Enable/Disable VDD monitoring
+in1_label Channel label (VDD)
+
+in2_input GPIO voltage (mV)
+in2_min Undervoltage threshold
+in2_max Overvoltage threshold
+in2_lowest Lowest measured voltage
+in2_highest Highest measured voltage
+in2_reset_history Write 1 to reset in2 history
+in2_min_alarm Undervoltage alarm
+in2_max_alarm Overvoltage alarm
+in2_label Channel label (VGPIO)
+
+curr1_input Sense current (mA)
+curr1_min Undercurrent threshold
+curr1_max Overcurrent threshold
+curr1_lowest Lowest measured current
+curr1_highest Highest measured current
+curr1_reset_history Write 1 to reset curr1 history.
+ Also clears overcurrent fault logs.
+curr1_min_alarm Undercurrent alarm
+curr1_max_alarm Overcurrent alarm
+curr1_crit_alarm Critical Overcurrent alarm
+curr1_label Channel label (ISENSE)
+
+power1_input Power (in uW)
+power1_min Low power threshold
+power1_max High power threshold
+power1_input_lowest Historical minimum power use
+power1_input_highest Historical maximum power use
+power1_reset_history Write 1 to reset power1 history.
+ Also clears power bad fault logs.
+power1_min_alarm Low power alarm
+power1_max_alarm High power alarm
+power1_label Channel label (Power)
+
+energy1_input Measured energy over time (in microJoule)
+energy1_enable Enable/Disable Energy accumulation
+======================= ==========================================
+
+DebugFs entries
+_______________
+
+The chip also has a fault log register where failures can be logged. Hence,
+as these are logging events, we give access to them in debugfs. Note that
+even if some failure is detected in these logs, it does necessarily mean
+that the failure is still present. As mentioned in the proper Sysfs entries,
+these logs can be cleared by writing in the proper reset_history attribute.
+
+.. warning:: The debugfs interface is subject to change without notice
+ and is only available when the kernel is compiled with
+ ``CONFIG_DEBUG_FS`` defined.
+
+``/sys/kernel/debug/ltc4282-hwmon[X]/``
+contains the following attributes:
+
+======================= ==========================================
+power1_bad_fault_log Set to 1 by a power1 bad fault occurring.
+in0_fet_short_fault_log Set to 1 when the ADC detects a FET-short fault.
+in0_fet_bad_fault_log Set to 1 when a FET-BAD fault occurs.
+in1_crit_fault_log Set to 1 by a VDD overvoltage fault occurring.
+in1_lcrit_fault_log Set to 1 by a VDD undervoltage fault occurring.
+curr1_crit_fault_log Set to 1 by an overcurrent fault occurring.
+======================= ==========================================
diff --git a/Documentation/hwmon/ltc4286.rst b/Documentation/hwmon/ltc4286.rst
new file mode 100644
index 000000000000..2cd149676d86
--- /dev/null
+++ b/Documentation/hwmon/ltc4286.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver ltc4286
+=====================
+
+Supported chips:
+
+ * Analog Devices LTC4286
+
+ Prefix: 'ltc4286'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4286.pdf
+
+ * Analog Devices LTC4287
+
+ Prefix: 'ltc4287'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4287.pdf
+
+Author: Delphine CC Chiu <Delphine_CC_Chiu@Wiwynn.com>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices LTC4286
+and LTC4287 Hot-Swap Controller and Digital Power Monitors.
+
+LTC4286 and LTC4287 are hot-swap controllers that allow a circuit board
+to be removed from or inserted into a live backplane. They also feature
+current and voltage readback via an integrated 12 bit analog-to-digital
+converter (ADC), accessed using a PMBus interface.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
+details.
+
+The shunt value in micro-ohms can be set via device tree at compile-time. Please
+refer to the Documentation/devicetree/bindings/hwmon/lltc,ltc4286.yaml for bindings
+if the device tree is used.
+
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data. Please see
+Documentation/hwmon/pmbus.rst for details.
+
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write, history reset
+attributes are write-only, all other attributes are read-only.
+
+======================= =======================================================
+in1_label "vin"
+in1_input Measured voltage.
+in1_alarm Input voltage alarm.
+in1_min Minimum input voltage.
+in1_max Maximum input voltage.
+
+in2_label "vout1"
+in2_input Measured voltage.
+in2_alarm Output voltage alarm.
+in2_min Minimum output voltage.
+in2_max Maximum output voltage.
+
+curr1_label "iout1"
+curr1_input Measured current.
+curr1_alarm Output current alarm.
+curr1_max Maximum current.
+
+power1_label "pin"
+power1_input Input power.
+power1_alarm Input power alarm.
+power1_max Maximum poewr.
+
+temp1_input Chip temperature.
+temp1_min Minimum chip temperature.
+temp1_max Maximum chip temperature.
+temp1_crit Critical chip temperature.
+temp1_alarm Chip temperature alarm.
+======================= =======================================================
diff --git a/Documentation/hwmon/macsmc-hwmon.rst b/Documentation/hwmon/macsmc-hwmon.rst
new file mode 100644
index 000000000000..6903f76df62b
--- /dev/null
+++ b/Documentation/hwmon/macsmc-hwmon.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver macsmc-hwmon
+==========================
+
+Supported hardware
+
+ * Apple Silicon Macs (M1 and up)
+
+Author: James Calligeros <jcalligeros99@gmail.com>
+
+Description
+-----------
+
+macsmc-hwmon exposes the Apple System Management controller's
+temperature, voltage, current and power sensors, as well as
+fan speed and control capabilities, via hwmon.
+
+Because each Apple Silicon Mac exposes a different set of sensors
+(e.g. the MacBooks expose battery telemetry that is not present on
+the desktop Macs), sensors present on any given machine are described
+via Devicetree. The driver picks these up and registers them with
+hwmon when probed.
+
+Manual fan speed is supported via the fan_control module parameter. This
+is disabled by default and marked as unsafe, as it cannot be proven that
+the system will fail safe if overheating due to manual fan control being
+used.
+
+sysfs interface
+---------------
+
+currX_input
+ Ammeter value
+
+currX_label
+ Ammeter label
+
+fanX_input
+ Current fan speed
+
+fanX_label
+ Fan label
+
+fanX_min
+ Minimum possible fan speed
+
+fanX_max
+ Maximum possible fan speed
+
+fanX_target
+ Current fan setpoint
+
+inX_input
+ Voltmeter value
+
+inX_label
+ Voltmeter label
+
+powerX_input
+ Power meter value
+
+powerX_label
+ Power meter label
+
+tempX_input
+ Temperature sensor value
+
+tempX_label
+ Temperature sensor label
+
diff --git a/Documentation/hwmon/max127.rst b/Documentation/hwmon/max127.rst
index dc192dd9c37c..09204b45f27b 100644
--- a/Documentation/hwmon/max127.rst
+++ b/Documentation/hwmon/max127.rst
@@ -13,7 +13,7 @@ Supported chips:
Prefix: 'max127'
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX127-MAX128.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max127-max128.pdf
Description
-----------
diff --git a/Documentation/hwmon/max15301.rst b/Documentation/hwmon/max15301.rst
index e3dc22fe1c6d..a0a993195cd1 100644
--- a/Documentation/hwmon/max15301.rst
+++ b/Documentation/hwmon/max15301.rst
@@ -11,7 +11,15 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX15301.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max15301.pdf
+
+ * Maxim MAX15303
+
+ Prefix: 'max15303'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max15303.pdf
Author: Erik Rosen <erik.rosen@metormote.com>
diff --git a/Documentation/hwmon/max16064.rst b/Documentation/hwmon/max16064.rst
index c06249292557..2a8a76d7b230 100644
--- a/Documentation/hwmon/max16064.rst
+++ b/Documentation/hwmon/max16064.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
+ Datasheet: https://www.digikey.com/en/htmldatasheets/production/701833/0/0/1/max16064
Author: Guenter Roeck <linux@roeck-us.net>
diff --git a/Documentation/hwmon/max16065.rst b/Documentation/hwmon/max16065.rst
index 45f69f334f25..ac3dc6f023dd 100644
--- a/Documentation/hwmon/max16065.rst
+++ b/Documentation/hwmon/max16065.rst
@@ -12,7 +12,7 @@ Supported chips:
Datasheet:
- http://datasheets.maxim-ic.com/en/ds/MAX16065-MAX16066.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/max16065-max16066.pdf
* Maxim MAX16067
@@ -22,7 +22,7 @@ Supported chips:
Datasheet:
- http://datasheets.maxim-ic.com/en/ds/MAX16067.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/max16067.pdf
* Maxim MAX16068
@@ -32,7 +32,7 @@ Supported chips:
Datasheet:
- http://datasheets.maxim-ic.com/en/ds/MAX16068.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/max16068.pdf
* Maxim MAX16070/MAX16071
@@ -42,7 +42,7 @@ Supported chips:
Datasheet:
- http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/max16070-max16071.pdf
Author: Guenter Roeck <linux@roeck-us.net>
diff --git a/Documentation/hwmon/max1619.rst b/Documentation/hwmon/max1619.rst
index e25956e70f73..f134d0fa9bfd 100644
--- a/Documentation/hwmon/max1619.rst
+++ b/Documentation/hwmon/max1619.rst
@@ -9,9 +9,9 @@ Supported chips:
Addresses scanned: I2C 0x18-0x1a, 0x29-0x2b, 0x4c-0x4e
- Datasheet: Publicly available at the Maxim website
+ Datasheet:
- http://pdfserv.maxim-ic.com/en/ds/MAX1619.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1619.pdf
Authors:
- Oleksij Rempel <bug-track@fisher-privat.net>,
@@ -27,7 +27,3 @@ All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature and for the remote temperature.
Only the external sensor has high and low limits.
-
-The max1619 driver will not update its values more frequently than every
-other second; reading them more often will do no harm, but will return
-'old' values.
diff --git a/Documentation/hwmon/max16601.rst b/Documentation/hwmon/max16601.rst
index 6a4eef8efbaf..3b1392bf547e 100644
--- a/Documentation/hwmon/max16601.rst
+++ b/Documentation/hwmon/max16601.rst
@@ -13,6 +13,14 @@ Supported chips:
Datasheet: Not published
+ * Maxim MAX16600
+
+ Prefix: 'max16600'
+
+ Addresses scanned: -
+
+ Datasheet: Not published
+
* Maxim MAX16601
Prefix: 'max16601'
@@ -27,7 +35,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX16602.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max16602.pdf
Author: Guenter Roeck <linux@roeck-us.net>
@@ -36,7 +44,8 @@ Description
-----------
This driver supports the MAX16508 VR13 Dual-Output Voltage Regulator
-as well as the MAX16601 VR13.HC Dual-Output Voltage Regulator chipsets.
+as well as the MAX16600, MAX16601, and MAX16602 VR13.HC Dual-Output
+Voltage Regulator chipsets.
The driver is a client driver to the core PMBus driver.
Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
diff --git a/Documentation/hwmon/max1668.rst b/Documentation/hwmon/max1668.rst
index 417f17d750e6..e2b8a4056abe 100644
--- a/Documentation/hwmon/max1668.rst
+++ b/Documentation/hwmon/max1668.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b, 0x4c, 0x4d, 0x4e
- Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX1668-MAX1989.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX1668-MAX1989.pdf
Author:
diff --git a/Documentation/hwmon/max17616.rst b/Documentation/hwmon/max17616.rst
new file mode 100644
index 000000000000..a3dc429048ae
--- /dev/null
+++ b/Documentation/hwmon/max17616.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver max17616
+======================
+
+Supported chips:
+
+ * Analog Devices MAX17616/MAX17616A
+
+ Prefix: 'max17616'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max17616-max17616a.pdf
+
+Author:
+
+ - Kim Seer Paller <kimseer.paller@analog.com>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices MAX17616/MAX17616A
+Current-Limiter with OV/Surge, UV, Reverse Polarity, Loss of Ground Protection
+with PMBus Interface.
+
+The MAX17616/MAX17616A is a 3V to 80V, 7A current-limiter with overvoltage,
+surge, undervoltage, reverse polarity, and loss of ground protection. Through
+the PMBus interface, the device can monitor input/output voltages, output current
+and temperature.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate
+the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst
+for details.
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+Sysfs entries
+-------------
+
+================= ========================================
+in1_label "vin"
+in1_input Measured input voltage
+in1_alarm Input voltage alarm
+in2_label "vout1"
+in2_input Measured output voltage
+curr1_label "iout1"
+curr1_input Measured output current.
+curr1_alarm Output current alarm
+temp1_input Measured temperature
+temp1_alarm Chip temperature alarm
+================= ========================================
diff --git a/Documentation/hwmon/max197.rst b/Documentation/hwmon/max197.rst
index 02fe19bc3428..00e16056823f 100644
--- a/Documentation/hwmon/max197.rst
+++ b/Documentation/hwmon/max197.rst
@@ -11,13 +11,13 @@ Supported chips:
Prefix: 'max197'
- Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX197.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX197.pdf
* Maxim MAX199
Prefix: 'max199'
- Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX199.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX199.pdf
Description
-----------
diff --git a/Documentation/hwmon/max20730.rst b/Documentation/hwmon/max20730.rst
index cb0c95b2b1f6..0ce473bca889 100644
--- a/Documentation/hwmon/max20730.rst
+++ b/Documentation/hwmon/max20730.rst
@@ -11,7 +11,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20710.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20710.pdf
* Maxim MAX20730
@@ -19,7 +19,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20730.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20730.pdf
* Maxim MAX20734
@@ -27,7 +27,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20734.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20734.pdf
* Maxim MAX20743
@@ -35,7 +35,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20743.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20743.pdf
Author: Guenter Roeck <linux@roeck-us.net>
diff --git a/Documentation/hwmon/max31722.rst b/Documentation/hwmon/max31722.rst
index 0ab15c00b226..b9d176ee7a69 100644
--- a/Documentation/hwmon/max31722.rst
+++ b/Documentation/hwmon/max31722.rst
@@ -11,7 +11,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31722-MAX31723.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max31722-max31723.pdf
* Maxim Integrated MAX31723
@@ -21,7 +21,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31722-MAX31723.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max31722-max31723.pdf
Author: Tiberiu Breana <tiberiu.a.breana@intel.com>
diff --git a/Documentation/hwmon/max31730.rst b/Documentation/hwmon/max31730.rst
index def0de19dbd2..1c5a32b64187 100644
--- a/Documentation/hwmon/max31730.rst
+++ b/Documentation/hwmon/max31730.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: 0x1c, 0x1d, 0x1e, 0x1f, 0x4c, 0x4d, 0x4e, 0x4f
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31730.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max31730.pdf
Author: Guenter Roeck <linux@roeck-us.net>
diff --git a/Documentation/hwmon/max31785.rst b/Documentation/hwmon/max31785.rst
index c8c6756d0ee1..92817436759e 100644
--- a/Documentation/hwmon/max31785.rst
+++ b/Documentation/hwmon/max31785.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max31785.pdf
Author: Andrew Jeffery <andrew@aj.id.au>
diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst
index 33c5c7330efc..b8af2d907b6e 100644
--- a/Documentation/hwmon/max31790.rst
+++ b/Documentation/hwmon/max31790.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://pdfserv.maximintegrated.com/en/ds/MAX31790.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31790.pdf
Author: Il Han <corone.il.han@gmail.com>
diff --git a/Documentation/hwmon/max31827.rst b/Documentation/hwmon/max31827.rst
new file mode 100644
index 000000000000..ddd039529077
--- /dev/null
+++ b/Documentation/hwmon/max31827.rst
@@ -0,0 +1,144 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver max31827
+======================
+
+Supported chips:
+
+ * Maxim MAX31827
+
+ Prefix: 'max31827'
+
+ Addresses scanned: I2C 0x40 - 0x5f
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31827-MAX31829.pdf
+
+ * Maxim MAX31828
+
+ Prefix: 'max31828'
+
+ Addresses scanned: I2C 0x40 - 0x5f
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31827-MAX31829.pdf
+
+ * Maxim MAX31829
+
+ Prefix: 'max31829'
+
+ Addresses scanned: I2C 0x40 - 0x5f
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31827-MAX31829.pdf
+
+
+Authors:
+ - Daniel Matyas <daniel.matyas@analog.com>
+
+Description
+-----------
+
+The chips supported by this driver are quite similar. The only difference
+between them is found in the default power-on behaviour of the chips. While the
+MAX31827's fault queue is set to 1, the other two chip's fault queue is set to
+4. Besides this, the MAX31829's alarm active state is high, while the other two
+chip's alarms are active on low. It is important to note that the chips can be
+configured to operate in the same manner with 1 write operation to the
+configuration register. From here on, we will refer to all these chips as
+MAX31827.
+
+MAX31827 implements a temperature sensor with a 6 WLP packaging scheme. This
+sensor measures the temperature of the chip itself.
+
+MAX31827 has low and over temperature alarms with an effective value and a
+hysteresis value: -40 and -30 degrees for under temperature alarm and +100 and
++90 degrees for over temperature alarm.
+
+The alarm can be configured in comparator and interrupt mode from the
+devicetree. In Comparator mode, the OT/UT status bits have a value of 1 when the
+temperature rises above the TH value or falls below TL, which is also subject to
+the Fault Queue selection. OT status returns to 0 when the temperature drops
+below the TH_HYST value or when shutdown mode is entered. Similarly, UT status
+returns to 0 when the temperature rises above TL_HYST value or when shutdown
+mode is entered.
+
+In interrupt mode exceeding TH also sets OT status to 1, which remains set until
+a read operation is performed on the configuration/status register (max or min
+attribute); at this point, it returns to 0. Once OT status is set to 1 from
+exceeding TH and reset, it is set to 1 again only when the temperature drops
+below TH_HYST. The output remains asserted until it is reset by a read. It is
+set again if the temperature rises above TH, and so on. The same logic applies
+to the operation of the UT status bit.
+
+Putting the MAX31827 into shutdown mode also resets the OT/UT status bits. Note
+that if the mode is changed while OT/UT status bits are set, an OT/UT status
+reset may be required before it begins to behave normally. To prevent this,
+it is recommended to perform a read of the configuration/status register to
+clear the status bits before changing the operating mode.
+
+The conversions can be manual with the one-shot functionality and automatic with
+a set frequency. When powered on, the chip measures temperatures with 1 conv/s.
+The conversion rate can be modified with update_interval attribute of the chip.
+Conversion/second = 1/update_interval. Thus, the available options according to
+the data sheet are:
+
+- 64000 (ms) = 1 conv/64 sec
+- 32000 (ms) = 1 conv/32 sec
+- 16000 (ms) = 1 conv/16 sec
+- 4000 (ms) = 1 conv/4 sec
+- 1000 (ms) = 1 conv/sec (default)
+- 250 (ms) = 4 conv/sec
+- 125 (ms) = 8 conv/sec
+
+Enabling the device when it is already enabled has the side effect of setting
+the conversion frequency to 1 conv/s. The conversion time varies depending on
+the resolution.
+
+The conversion time doubles with every bit of increased resolution. The
+available resolutions are:
+
+- 8 bit -> 8.75 ms conversion time
+- 9 bit -> 17.5 ms conversion time
+- 10 bit -> 35 ms conversion time
+- 12 bit (default) -> 140 ms conversion time
+
+There is a temp1_resolution attribute which indicates the unit change in the
+input temperature in milli-degrees C.
+
+- 1000 mC -> 8 bit
+- 500 mC -> 9 bit
+- 250 mC -> 10 bit
+- 62 mC -> 12 bit (default) - actually this is 62.5, but the fil returns 62
+
+When chip is in shutdown mode and a read operation is requested, one-shot is
+triggered, the device waits for <conversion time> ms, and only after that is
+the temperature value register read. Note that the conversion times are rounded
+up to the nearest possible integer.
+
+The LSB of the temperature values is 0.0625 degrees Celsius, but the values of
+the temperatures are displayed in milli-degrees. This means, that some data is
+lost. The step between 2 consecutive values is 62 or 63. This effect can be seen
+in the writing of alarm values too. For positive numbers the user-input value
+will always be rounded down to the nearest possible value, for negative numbers
+the user-input will always be rounded up to the nearest possible value.
+
+Bus timeout resets the I2C-compatible interface when SCL is low for more than
+30ms (nominal).
+
+Alarm polarity determines if the active state of the alarm is low or high. The
+behavior for both settings is dependent on the Fault Queue setting. The ALARM
+pin is an open-drain output and requires a pullup resistor to operate.
+
+The Fault Queue bits select how many consecutive temperature faults must occur
+before overtemperature or undertemperature faults are indicated in the
+corresponding status bits.
+
+PEC Support
+-----------
+
+When reading a register value, the PEC byte is computed and sent by the chip.
+
+PEC on word data transaction represents a significant increase in bandwidth
+usage (+33% for both write and reads) in normal conditions.
+
+Since this operation implies there will be an extra delay to each
+transaction, PEC can be disabled or enabled through sysfs.
+Just write 1 to the "pec" file for enabling PEC and 0 for disabling it.
diff --git a/Documentation/hwmon/max34440.rst b/Documentation/hwmon/max34440.rst
index 162d289f0814..d6d4fbc863d9 100644
--- a/Documentation/hwmon/max34440.rst
+++ b/Documentation/hwmon/max34440.rst
@@ -3,13 +3,29 @@ Kernel driver max34440
Supported chips:
+ * ADI ADPM12160
+
+ Prefixes: 'adpm12160'
+
+ Addresses scanned: -
+
+ Datasheet: -
+
+ * ADI ADPM12200
+
+ Prefixes: 'adpm12200'
+
+ Addresses scanned: -
+
+ Datasheet: -
+
* Maxim MAX34440
Prefixes: 'max34440'
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34440.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max34440.pdf
* Maxim MAX34441
@@ -19,7 +35,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34441.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max34441.pdf
* Maxim MAX34446
@@ -29,7 +45,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34446.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max34446.pdf
* Maxim MAX34451
@@ -39,7 +55,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34451.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max34451.pdf
* Maxim MAX34460
@@ -49,7 +65,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34460.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max34460.pdf
* Maxim MAX34461
@@ -59,7 +75,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max34461.pdf
Author: Guenter Roeck <linux@roeck-us.net>
@@ -67,13 +83,15 @@ Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
-This driver supports hardware monitoring for Maxim MAX34440 PMBus 6-Channel
-Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
-and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
-It also supports the MAX34451, MAX34460, and MAX34461 PMBus Voltage Monitor &
-Sequencers. The MAX34451 supports monitoring voltage or current of 12 channels
-based on GIN pins. The MAX34460 supports 12 voltage channels, and the MAX34461
-supports 16 voltage channels.
+This driver supports multiple devices: hardware monitoring for Maxim MAX34440
+PMBus 6-Channel Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply
+Manager and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data
+Logger; PMBus Voltage Monitor and Sequencers for MAX34451, MAX34460, and
+MAX34461; PMBus DC/DC Power Module ADPM12160, and ADPM12200. The MAX34451
+supports monitoring voltage or current of 12 channels based on GIN pins. The
+MAX34460 supports 12 voltage channels, and the MAX34461 supports 16 voltage
+channels. The ADPM12160, and ADPM12200 also monitors both input and output
+of voltage and current.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
@@ -128,7 +146,11 @@ in[1-6]_highest Historical maximum voltage.
in[1-6]_reset_history Write any value to reset history.
======================= =======================================================
-.. note:: MAX34446 only supports in[1-4].
+.. note::
+
+ - MAX34446 only supports in[1-4].
+ - ADPM12160, and ADPM12200 only supports in[1-2]. Label is "vin1"
+ and "vout1" respectively.
Curr
~~~~
@@ -150,6 +172,8 @@ curr[1-6]_reset_history Write any value to reset history.
- in6 and curr6 attributes only exist for MAX34440.
- MAX34446 only supports curr[1-4].
+ - For ADPM12160, and ADPM12200, curr[1] is "iin1" and curr[2-6]
+ are "iout[1-5]".
Power
~~~~~
@@ -185,6 +209,7 @@ temp[1-8]_reset_history Write any value to reset history.
.. note::
- temp7 and temp8 attributes only exist for MAX34440.
- MAX34446 only supports temp[1-3].
+ - ADPM12160, and ADPM12200 only supports temp[1].
.. note::
diff --git a/Documentation/hwmon/max6620.rst b/Documentation/hwmon/max6620.rst
index 84c1c44d3de4..d70173bf0242 100644
--- a/Documentation/hwmon/max6620.rst
+++ b/Documentation/hwmon/max6620.rst
@@ -11,7 +11,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6620.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6620.pdf
Authors:
- L\. Grunenberg <contact@lgrunenberg.de>
diff --git a/Documentation/hwmon/max6639.rst b/Documentation/hwmon/max6639.rst
index c85d285a3489..492c13a5880d 100644
--- a/Documentation/hwmon/max6639.rst
+++ b/Documentation/hwmon/max6639.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: I2C 0x2c, 0x2e, 0x2f
- Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX6639-MAX6639F.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6639-max6639f.pdf
Authors:
- He Changqing <hechangqing@semptian.com>
diff --git a/Documentation/hwmon/max6642.rst b/Documentation/hwmon/max6642.rst
deleted file mode 100644
index 7e5b7d4f9492..000000000000
--- a/Documentation/hwmon/max6642.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-Kernel driver max6642
-=====================
-
-Supported chips:
-
- * Maxim MAX6642
-
- Prefix: 'max6642'
-
- Addresses scanned: I2C 0x48-0x4f
-
- Datasheet: Publicly available at the Maxim website
-
- http://datasheets.maxim-ic.com/en/ds/MAX6642.pdf
-
-Authors:
-
- Per Dalen <per.dalen@appeartv.com>
-
-Description
------------
-
-The MAX6642 is a digital temperature sensor. It senses its own temperature as
-well as the temperature on one external diode.
-
-All temperature values are given in degrees Celsius. Resolution
-is 0.25 degree for the local temperature and for the remote temperature.
diff --git a/Documentation/hwmon/max6650.rst b/Documentation/hwmon/max6650.rst
index 7952b6ecaa2d..427f353c5e9c 100644
--- a/Documentation/hwmon/max6650.rst
+++ b/Documentation/hwmon/max6650.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6650-MAX6651.pdf
* Maxim MAX6651
@@ -17,7 +17,7 @@ Supported chips:
Addresses scanned: none
- Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX6650-MAX6651.pdf
Authors:
- Hans J. Koch <hjk@hansjkoch.de>
diff --git a/Documentation/hwmon/max6697.rst b/Documentation/hwmon/max6697.rst
index ffc5a7d8d33b..5b37ff08ff44 100644
--- a/Documentation/hwmon/max6697.rst
+++ b/Documentation/hwmon/max6697.rst
@@ -7,61 +7,61 @@ Supported chips:
Prefix: 'max6581'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6581.pdf
* Maxim MAX6602
Prefix: 'max6602'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6602.pdf
* Maxim MAX6622
Prefix: 'max6622'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6622.pdf
* Maxim MAX6636
Prefix: 'max6636'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6636.pdf
* Maxim MAX6689
Prefix: 'max6689'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6689.pdf
* Maxim MAX6693
Prefix: 'max6693'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6693.pdf
* Maxim MAX6694
Prefix: 'max6694'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6694.pdf
* Maxim MAX6697
Prefix: 'max6697'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6697.pdf
* Maxim MAX6698
Prefix: 'max6698'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6698.pdf
* Maxim MAX6699
Prefix: 'max6699'
- Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max6699.pdf
Author:
@@ -73,7 +73,7 @@ Description
This driver implements support for several MAX6697 compatible temperature sensor
chips. The chips support one local temperature sensor plus four, six, or seven
remote temperature sensors. Remote temperature sensors are diode-connected
-thermal transitors, except for MAX6698 which supports three diode-connected
+thermal transistors, except for MAX6698 which supports three diode-connected
thermal transistors plus three thermistors in addition to the local temperature
sensor.
diff --git a/Documentation/hwmon/max77705.rst b/Documentation/hwmon/max77705.rst
new file mode 100644
index 000000000000..5202de614647
--- /dev/null
+++ b/Documentation/hwmon/max77705.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver max77705
+======================
+
+Supported chips:
+
+ * Maxim Integrated MAX77705
+
+ Prefix: 'max77705'
+
+ Addresses scanned: none
+
+ Datasheet:
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/max77505.pdf
+
+Authors:
+ - Dzmitry Sankouski <dsankouski@gmail.com>
+
+Description
+-----------
+
+The MAX77705 PMIC provides current and voltage measurements besides fuelgauge:
+- chip input current
+- system bus current and voltage
+- VBYP voltage
+
+Sysfs Attributes
+----------------
+
+================= ========================================
+in1_label "vbyp"
+in1_input Measured chip vbyp voltage
+in2_label "vsys"
+in2_input Measured chip system bus voltage
+curr1_label "iin"
+curr1_input Measured chip input current.
+curr2_label "isys"
+curr2_input Measured chip system bus current.
+================= ========================================
diff --git a/Documentation/hwmon/max8688.rst b/Documentation/hwmon/max8688.rst
index 71e7f2cbe2e2..71b6b9ee90ab 100644
--- a/Documentation/hwmon/max8688.rst
+++ b/Documentation/hwmon/max8688.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max8688.pdf
Author: Guenter Roeck <linux@roeck-us.net>
diff --git a/Documentation/hwmon/mc33xs2410_hwmon.rst b/Documentation/hwmon/mc33xs2410_hwmon.rst
new file mode 100644
index 000000000000..8a2136ef9139
--- /dev/null
+++ b/Documentation/hwmon/mc33xs2410_hwmon.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mc33xs2410_hwmon
+==============================
+
+Supported devices:
+
+ * NXPs MC33XS2410
+
+ Datasheet: https://www.nxp.com/docs/en/data-sheet/MC33XS2410.pdf
+
+Authors:
+
+ Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+
+Description
+-----------
+
+The MC33XS2410 is a four channel self-protected high-side switch featuring
+hardware monitoring functions such as temperature, current and voltages for each
+of the four channels.
+
+Sysfs entries
+-------------
+
+======================= ======================================================
+temp1_label "Central die temperature"
+temp1_input Measured temperature of central die
+
+temp[2-5]_label "Channel [1-4] temperature"
+temp[2-5]_input Measured temperature of a single channel
+temp[2-5]_alarm Temperature alarm
+temp[2-5]_max Maximal temperature
+======================= ======================================================
diff --git a/Documentation/hwmon/mc34vr500.rst b/Documentation/hwmon/mc34vr500.rst
new file mode 100644
index 000000000000..f82d872477ac
--- /dev/null
+++ b/Documentation/hwmon/mc34vr500.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver mc34vr500
+=======================
+
+Supported Chips:
+
+ * NXP MC34VR500
+
+ Prefix: 'mc34vr500'
+
+ Datasheet: https://www.nxp.com/docs/en/data-sheet/MC34VR500.pdf
+
+Author: Mario Kicherer <dev@kicherer.org>
+
+Description
+-----------
+
+This driver implements initial support for the NXP MC34VR500 PMIC. The MC34VR500
+monitors the temperature, input voltage and output currents and provides
+corresponding alarms. For the temperature, the chip can send interrupts if
+the temperature rises above one of the following values: 110°, 120°, 125° and
+130° Celsius. For the input voltage, an interrupt is sent when the voltage
+drops below 2.8V.
+
+Currently, this driver only implements the input voltage and temperature
+alarms. The interrupts are mapped as follows:
+
+<= 2.8V -> in0_min_alarm
+>110°c -> temp1_max_alarm
+>120°c -> temp1_crit_alarm
+>130°c -> temp1_emergency_alarm
diff --git a/Documentation/hwmon/menf21bmc.rst b/Documentation/hwmon/menf21bmc.rst
index 978691d5956d..e7f3f67b38d4 100644
--- a/Documentation/hwmon/menf21bmc.rst
+++ b/Documentation/hwmon/menf21bmc.rst
@@ -7,7 +7,7 @@ Supported chips:
Prefix: 'menf21bmc_hwmon'
- Adresses scanned: -
+ Addresses scanned: -
Author: Andreas Werner <andreas.werner@men.de>
diff --git a/Documentation/hwmon/mp2856.rst b/Documentation/hwmon/mp2856.rst
new file mode 100644
index 000000000000..af625c22b6ea
--- /dev/null
+++ b/Documentation/hwmon/mp2856.rst
@@ -0,0 +1,98 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp2856
+====================
+
+Supported chips:
+
+ * MPS MP2856
+
+ Prefix: 'mp2856'
+
+ * MPS MP2857
+
+ Prefix: 'mp2857'
+
+Author:
+
+ Peter Yin <peter.yin@quantatw.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+vendor dual-loop, digital, multi-phase controller MP2856/MP2857
+
+This device:
+
+- Supports up to two power rail.
+- Supports two pages 0 and 1 for and also pages 2 for configuration.
+- Can configured VOUT readout in direct or VID format and allows
+ setting of different formats on rails 1 and 2. For VID the following
+ protocols are available: AMD SVI3 mode with 5-mV/LSB.
+
+Device supports:
+
+- SVID interface.
+- AVSBus interface.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Device supports direct format for reading output current, output voltage,
+input and output power and temperature.
+Device supports linear format for reading input voltage and input power.
+Device supports VID and direct formats for reading output voltage.
+The below VID modes are supported: AMD SVI3.
+
+The driver provides the following sysfs attributes for current measurements:
+
+- indexes 1 for "iin";
+- indexes 2, 3 for "iout";
+
+**curr[1-3]_alarm**
+
+**curr[1-3]_input**
+
+**curr[1-3]_label**
+
+The driver provides the following sysfs attributes for voltage measurements.
+
+- indexes 1 for "vin";
+- indexes 2, 3 for "vout";
+
+**in[1-3]_crit**
+
+**in[1-3]_crit_alarm**
+
+**in[1-3]_input**
+
+**in[1-3]_label**
+
+**in[1-3]_lcrit**
+
+**in[1-3]_lcrit_alarm**
+
+The driver provides the following sysfs attributes for power measurements.
+
+- indexes 1 for "pin";
+- indexes 2, 3 for "pout";
+
+**power[1-3]_alarm**
+
+**power[1-3]_input**
+
+**power[1-3]_label**
+
+The driver provides the following sysfs attributes for temperature measurements.
+
+**temp[1-2]_crit**
+
+**temp[1-2]_crit_alarm**
+
+**temp[1-2]_input**
+
+**temp[1-2]_max**
+
+**temp[1-2]_max_alarm**
diff --git a/Documentation/hwmon/mp2869.rst b/Documentation/hwmon/mp2869.rst
new file mode 100644
index 000000000000..2d9d65fc86b6
--- /dev/null
+++ b/Documentation/hwmon/mp2869.rst
@@ -0,0 +1,175 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp2869
+====================
+
+Supported chips:
+
+ * MPS mp2869
+
+ Prefix: 'mp2869'
+
+ * MPS mp29608
+
+ Prefix: 'mp29608'
+
+ * MPS mp29612
+
+ Prefix: 'mp29612'
+
+ * MPS mp29816
+
+ Prefix: 'mp29816'
+
+Author:
+
+ Wensheng Wang <wenswang@yeah.net>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP2869 Dual Loop Digital Multi-phase Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in3_input**
+
+**in3_label**
+
+**in3_crit**
+
+**in3_crit_alarm**
+
+**in3_lcrit**
+
+**in3_lcrit_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr2_input**
+
+**curr2_label**
+
+The driver provides the following attributes for output current:
+
+**curr3_input**
+
+**curr3_label**
+
+**curr3_crit**
+
+**curr3_crit_alarm**
+
+**curr3_max**
+
+**curr3_max_alarm**
+
+**curr4_input**
+
+**curr4_label**
+
+**curr4_crit**
+
+**curr4_crit_alarm**
+
+**curr4_max**
+
+**curr4_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power2_input**
+
+**power2_label**
+
+The driver provides the following attributes for output power:
+
+**power3_input**
+
+**power3_label**
+
+**power3_input**
+
+**power3_label**
+
+**power3_max**
+
+**power3_max_alarm**
+
+**power4_input**
+
+**power4_label**
+
+**power4_input**
+
+**power4_label**
+
+**power4_max**
+
+**power4_max_alarm**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp2_input**
+
+**temp2_crit**
+
+**temp2_crit_alarm**
+
+**temp2_max**
+
+**temp2_max_alarm**
diff --git a/Documentation/hwmon/mp2891.rst b/Documentation/hwmon/mp2891.rst
new file mode 100644
index 000000000000..55944d1b5457
--- /dev/null
+++ b/Documentation/hwmon/mp2891.rst
@@ -0,0 +1,179 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp2891
+====================
+
+Supported chips:
+
+ * MPS mp2891
+
+ Prefix: 'mp2891'
+
+ * Datasheet
+
+ Publicly available at the MPS website : https://www.monolithicpower.com/en/mp2891.html
+
+Author:
+
+ Noah Wang <noahwang.wang@outlook.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP2891 Multi-phase Digital VR Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Device supports direct and linear format for reading input voltage,
+output voltage, input current, output current, input power, output
+power, and temperature.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in2_min**
+
+**in2_min_alarm**
+
+**in3_input**
+
+**in3_label**
+
+**in3_crit**
+
+**in3_crit_alarm**
+
+**in3_lcrit**
+
+**in3_lcrit_alarm**
+
+**in3_min**
+
+**in3_min_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr3_input**
+
+**curr3_label**
+
+**curr3_crit**
+
+**curr3_crit_alarm**
+
+**curr3_max**
+
+**curr3_max_alarm**
+
+**curr4_input**
+
+**curr4_label**
+
+**curr4_crit**
+
+**curr4_crit_alarm**
+
+**curr4_max**
+
+**curr4_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power1_max**
+
+**power1_alarm**
+
+**power2_input**
+
+**power2_label**
+
+**power2_max**
+
+**power2_alarm**
+
+The driver provides the following attributes for output power:
+
+**power3_input**
+
+**power3_label**
+
+**power4_input**
+
+**power4_label**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp2_input**
+
+**temp2_crit**
+
+**temp2_crit_alarm**
+
+**temp2_max**
+
+**temp2_max_alarm**
diff --git a/Documentation/hwmon/mp2925.rst b/Documentation/hwmon/mp2925.rst
new file mode 100644
index 000000000000..63eda215b6cb
--- /dev/null
+++ b/Documentation/hwmon/mp2925.rst
@@ -0,0 +1,151 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp2925
+====================
+
+Supported chips:
+
+ * MPS mp2925
+
+ Prefix: 'mp2925'
+
+ * MPS mp2929
+
+ Prefix: 'mp2929'
+
+Author:
+
+ Wensheng Wang <wenswang@yeah.net>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP2925 Dual Loop Digital Multi-phase Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in3_input**
+
+**in3_label**
+
+**in3_crit**
+
+**in3_crit_alarm**
+
+**in3_lcrit**
+
+**in3_lcrit_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+The driver provides the following attributes for output current:
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_crit**
+
+**curr2_crit_alarm**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+**curr3_input**
+
+**curr3_label**
+
+**curr3_crit**
+
+**curr3_crit_alarm**
+
+**curr3_max**
+
+**curr3_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power2_input**
+
+**power2_label**
+
+The driver provides the following attributes for output power:
+
+**power3_input**
+
+**power3_label**
+
+**power4_input**
+
+**power4_label**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp2_input**
+
+**temp2_crit**
+
+**temp2_crit_alarm**
+
+**temp2_max**
+
+**temp2_max_alarm**
diff --git a/Documentation/hwmon/mp29502.rst b/Documentation/hwmon/mp29502.rst
new file mode 100644
index 000000000000..893e741a6b71
--- /dev/null
+++ b/Documentation/hwmon/mp29502.rst
@@ -0,0 +1,93 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp29502
+=====================
+
+Supported chips:
+
+ * MPS mp29502
+
+ Prefix: 'mp29502'
+
+Author:
+
+ Wensheng Wang <wenswang@yeah.net>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP29502 Digital Multi-phase Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+The driver provides the following attributes for output current:
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_crit**
+
+**curr2_crit_alarm**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+The driver provides the following attributes for output power:
+
+**power2_input**
+
+**power2_label**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
diff --git a/Documentation/hwmon/mp2993.rst b/Documentation/hwmon/mp2993.rst
new file mode 100644
index 000000000000..7a4fe0d946e0
--- /dev/null
+++ b/Documentation/hwmon/mp2993.rst
@@ -0,0 +1,150 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp2993
+====================
+
+Supported chips:
+
+ * MPS mp2993
+
+ Prefix: 'mp2993'
+
+ * Datasheet
+ https://scnbwymvp-my.sharepoint.com/:f:/g/personal/admin_scnbwy_com/Eth4kX1_J1hMsaASHiOYL4QBHU5a75r-tRfLKbHnJFdKLQ?e=vxj3DF
+
+Author:
+
+ Noah Wang <noahwang.wang@outlook.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP2993 Dual Loop Digital Multi-phase Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in3_input**
+
+**in3_label**
+
+**in3_crit**
+
+**in3_crit_alarm**
+
+**in3_lcrit**
+
+**in3_lcrit_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_crit**
+
+**curr2_crit_alarm**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+**curr3_input**
+
+**curr3_label**
+
+**curr3_crit**
+
+**curr3_crit_alarm**
+
+**curr3_max**
+
+**curr3_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+The driver provides the following attributes for output power:
+
+**power2_input**
+
+**power2_label**
+
+**power3_input**
+
+**power3_label**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp2_input**
+
+**temp2_crit**
+
+**temp2_crit_alarm**
+
+**temp2_max**
+
+**temp2_max_alarm**
diff --git a/Documentation/hwmon/mp5920.rst b/Documentation/hwmon/mp5920.rst
new file mode 100644
index 000000000000..98946e7cf54e
--- /dev/null
+++ b/Documentation/hwmon/mp5920.rst
@@ -0,0 +1,91 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp5920
+====================
+
+Supported chips:
+
+ * MPS MP5920
+
+ Prefix: 'mp5920'
+
+ * Datasheet
+
+ Publicly available at the MPS website : https://www.monolithicpower.com/en/mp5920.html
+
+Authors:
+
+ Tony Ao <tony_ao@wiwynn.com>
+ Alex Vdovydchenko <xzeol@yahoo.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP5920 Hot-Swap Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Device supports direct and linear format for reading input voltage,
+output voltage, output current, input power and temperature.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_rated_max**
+
+**in1_rated_min**
+
+**in1_crit**
+
+**in1_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_rated_max**
+
+**in2_rated_min**
+
+**in2_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_crit**
+
+**curr1_alarm**
+
+**curr1_rated_max**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power1_max**
+
+**power1_rated_max**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_max**
+
+**temp1_crit**
+
+**temp1_alarm**
diff --git a/Documentation/hwmon/mp5990.rst b/Documentation/hwmon/mp5990.rst
new file mode 100644
index 000000000000..7fd536757ff2
--- /dev/null
+++ b/Documentation/hwmon/mp5990.rst
@@ -0,0 +1,106 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp5990
+====================
+
+Supported chips:
+
+ * MPS MP5990
+
+ Prefix: 'mp5990'
+
+ Datasheet: Publicly available at the MPS website: https://www.monolithicpower.com/en/mp5990.html
+
+ * MPS MP5998
+
+ Prefix: 'mp5998'
+
+ Datasheet: Not publicly available
+
+Author:
+
+ Peter Yin <peteryin.openbmc@gmail.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP5990 and MP5998 Hot-Swap Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Device supports direct and linear format for reading input voltage,
+output voltage, output current, input power and temperature.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_alarm**
+
+The driver provides the following attributes for current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_alarm**
+
+**curr1_max**
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power1_alarm**
+
+The driver provides the following attributes for output power:
+
+**power2_input**
+
+**power2_label**
+
+**power2_max**
+
+**power2_max_alarm**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
diff --git a/Documentation/hwmon/mp9941.rst b/Documentation/hwmon/mp9941.rst
new file mode 100644
index 000000000000..1274fa20e256
--- /dev/null
+++ b/Documentation/hwmon/mp9941.rst
@@ -0,0 +1,92 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp9941
+====================
+
+Supported chips:
+
+ * MPS mp9941
+
+ Prefix: 'mp9941'
+
+ * Datasheet
+ https://scnbwymvp-my.sharepoint.com/:f:/g/personal/admin_scnbwy_com/Eth4kX1_J1hMsaASHiOYL4QBHU5a75r-tRfLKbHnJFdKLQ?e=vxj3DF
+
+Author:
+
+ Noah Wang <noahwang.wang@outlook.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP9941 digital step-down converter.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in2_rated_max**
+
+**in2_rated_min**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr2_input**
+
+**curr2_label**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+The driver provides the following attributes for output power:
+
+**power2_input**
+
+**power2_label**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
diff --git a/Documentation/hwmon/mp9945.rst b/Documentation/hwmon/mp9945.rst
new file mode 100644
index 000000000000..f406f96efcf9
--- /dev/null
+++ b/Documentation/hwmon/mp9945.rst
@@ -0,0 +1,117 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp9945
+=====================
+
+Supported chips:
+
+ * MPS mp9945
+
+ Prefix: 'mp9945'
+
+Author:
+
+ Cosmo Chou <chou.cosmo@gmail.com>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP9945 Digital Single-phase Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in2_min**
+
+**in2_min_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_crit**
+
+**curr2_crit_alarm**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+The driver provides the following attributes for output power:
+
+**power2_input**
+
+**power2_label**
+
+**power2_max**
+
+**power2_max_alarm**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
diff --git a/Documentation/hwmon/mpq8785.rst b/Documentation/hwmon/mpq8785.rst
new file mode 100644
index 000000000000..198d5dfd7c30
--- /dev/null
+++ b/Documentation/hwmon/mpq8785.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver mpq8785
+=======================
+
+Supported chips:
+
+ * MPS MPM3695 family
+ * MPS MPM82504
+ * MPS MPQ8785
+
+ Prefix: 'mpq8785'
+
+Author: Charles Hsu <ythsu0511@gmail.com>
+
+Description
+-----------
+
+The MPM3695 family is a scalable, ultra-thin, fully integrated power module with
+a PMBus interface. It offers a complete power solution that achieves up to
+10A (-10 variant), 20A (-25 variant), 25A (-20 variant), 100A (-100 variant)
+of output current with excellent load and line regulation across a wide input
+voltage range. It operates at high efficiency over a wide load range, and can
+be parallled to deliver higher current. Variants -10,-20 and -100 have different
+voltage scale configuration register range (10 bits) than -25 version (11 bits).
+
+The MPM82504 is a quad 25A, scalable, fully integrated power module with a PMBus
+interface. The device offers a complete power solution that achieves up to 25A
+per output channel. The MPM82504 has four output channels that can be paralleled
+to provide 50A, 75A, or 100A of output current for flexible configurations.
+The device can also operate in parallel with the MPM3695-100 and additional
+MPM82504 devices to provide a higher output current. The MPM82504 operates
+at high efficiency across a wide load range.
+
+The MPQ8785 is a fully integrated, PMBus-compatible, high-frequency, synchronous
+buck converter. The MPQ8785 offers a very compact solution that achieves up to
+40A output current per phase, with excellent load and line regulation over a
+wide input supply range. The MPQ8785 operates at high efficiency over a wide
+output current load range.
+
+The PMBus interface provides converter configurations and key parameters
+monitoring.
+
+The devices adopts MPS's proprietary multi-phase digital constant-on-time (MCOT)
+control, which provides fast transient response and eases loop stabilization.
+The MCOT scheme also allows multiple devices or channels to be connected in
+parallel with excellent current sharing and phase interleaving for high-current
+applications.
+
+Fully integrated protection features include over-current protection (OCP),
+over-voltage protection (OVP), under-voltage protection (UVP), and
+over-temperature protection (OTP).
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+**curr1_crit**
+
+**curr1_crit_alarm**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
diff --git a/Documentation/hwmon/nct6683.rst b/Documentation/hwmon/nct6683.rst
index 2e1408d174bd..3e549ba95a15 100644
--- a/Documentation/hwmon/nct6683.rst
+++ b/Documentation/hwmon/nct6683.rst
@@ -3,7 +3,7 @@ Kernel driver nct6683
Supported chips:
- * Nuvoton NCT6683D/NCT6687D
+ * Nuvoton NCT6683D/NCT6686D/NCT6687D
Prefix: 'nct6683'
@@ -55,12 +55,17 @@ Tested Boards and Firmware Versions
The driver has been reported to work with the following boards and
firmware versions.
-=============== ===============================================
-Board Firmware version
-=============== ===============================================
-Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13
-Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13
-Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13
-ASRock X570 NCT6683D EC firmware version 1.0 build 06/28/19
-MSI B550 NCT6687D EC firmware version 1.0 build 05/07/20
-=============== ===============================================
+=============================== ===============================================
+Board Firmware version
+=============================== ===============================================
+Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13
+Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13
+Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13
+AMD BC-250 NCT6686D EC firmware version 1.0 build 07/28/21
+ASRock X570 NCT6683D EC firmware version 1.0 build 06/28/19
+ASRock X670E NCT6686D EC firmware version 1.0 build 05/19/22
+ASRock B650 Steel Legend WiFi NCT6686D EC firmware version 1.0 build 11/09/23
+MSI B550 NCT6687D EC firmware version 1.0 build 05/07/20
+MSI X670-P NCT6687D EC firmware version 0.0 build 09/27/22
+MSI X870E NCT6687D EC firmware version 0.0 build 11/13/24
+=============================== ===============================================
diff --git a/Documentation/hwmon/nct6775.rst b/Documentation/hwmon/nct6775.rst
index 5ba8276aad4b..9d7a10de61a7 100644
--- a/Documentation/hwmon/nct6775.rst
+++ b/Documentation/hwmon/nct6775.rst
@@ -80,7 +80,13 @@ Supported chips:
Datasheet: Available from Nuvoton upon request
+ * Nuvoton NCT6796D-S/NCT6799D-R
+ Prefix: 'nct6799'
+
+ Addresses scanned: ISA address retrieved from Super I/O registers
+
+ Datasheet: Available from Nuvoton upon request
Authors:
@@ -277,4 +283,7 @@ will not reflect a usable value. It often reports unreasonably high
temperatures, and in some cases the reported temperature declines if the actual
temperature increases (similar to the raw PECI temperature value - see PECI
specification for details). CPUTIN should therefore be ignored on ASUS
-boards. The CPU temperature on ASUS boards is reported from PECI 0.
+boards. The CPU temperature on ASUS boards is reported from PECI 0 or TSI 0.
+
+NCT6796D-S and NCT6799D-R chips are very similar and their chip_id indicates
+they are different versions. This driver treats them the same way.
diff --git a/Documentation/hwmon/nct7363.rst b/Documentation/hwmon/nct7363.rst
new file mode 100644
index 000000000000..623cb4f0c8ce
--- /dev/null
+++ b/Documentation/hwmon/nct7363.rst
@@ -0,0 +1,35 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver nct7363
+=====================
+
+Supported chip:
+
+ * Nuvoton NCT7363Y
+
+ Prefix: nct7363
+
+ Addresses: I2C 0x20, 0x21, 0x22, 0x23
+
+Author: Ban Feng <kcfeng0@nuvoton.com>
+
+
+Description
+-----------
+
+The NCT7363Y is a fan controller which provides up to 16 independent
+FAN input monitors, and up to 16 independent PWM outputs with SMBus interface.
+
+
+Sysfs entries
+-------------
+
+Currently, the driver supports the following features:
+
+========== ==========================================
+fanX_input provide current fan rotation value in RPM
+fanX_alarm report fan low speed real status
+fanX_min get or set fan count threshold
+
+pwmX get or set PWM fan control value.
+========== ==========================================
diff --git a/Documentation/hwmon/nzxt-kraken3.rst b/Documentation/hwmon/nzxt-kraken3.rst
new file mode 100644
index 000000000000..57fe99d23301
--- /dev/null
+++ b/Documentation/hwmon/nzxt-kraken3.rst
@@ -0,0 +1,77 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver nzxt-kraken3
+==========================
+
+Supported devices:
+
+* NZXT Kraken X53
+* NZXT Kraken X63
+* NZXT Kraken X73
+* NZXT Kraken Z53
+* NZXT Kraken Z63
+* NZXT Kraken Z73
+* NZXT Kraken 2023
+* NZXT Kraken 2023 Elite
+
+Author: Jonas Malaco, Aleksa Savic
+
+Description
+-----------
+
+This driver enables hardware monitoring support for NZXT Kraken X53/X63/X73,
+Z53/Z63/Z73 and Kraken 2023 (standard and Elite) all-in-one CPU liquid coolers.
+All models expose liquid temperature and pump speed (in RPM), as well as PWM
+control (either as a fixed value or through a temp-PWM curve). The Z-series and
+Kraken 2023 models additionally expose the speed and duty of an optionally connected
+fan, with the same PWM control capabilities.
+
+Pump and fan duty control mode can be set through pwm[1-2]_enable, where 1 is
+for the manual control mode and 2 is for the liquid temp to PWM curve mode.
+Writing a 0 disables control of the channel through the driver after setting its
+duty to 100%.
+
+The temperature of the curves relates to the fixed [20-59] range, correlating to
+the detected liquid temperature. Only PWM values (ranging from 0-255) can be set.
+If in curve mode, setting point values should be done in moderation - the devices
+require complete curves to be sent for each change; they can lock up or discard
+the changes if they are too numerous at once. Suggestion is to set them while
+in an another mode, and then apply them by switching to curve.
+
+The devices can report if they are faulty. The driver supports that situation
+and will issue a warning. This can also happen when the USB cable is connected,
+but SATA power is not.
+
+The addressable RGB LEDs and LCD screen (only on Z-series and Kraken 2023 models)
+are not supported in this driver, but can be controlled through existing userspace
+tools, such as `liquidctl`_.
+
+.. _liquidctl: https://github.com/liquidctl/liquidctl
+
+Usage Notes
+-----------
+
+As these are USB HIDs, the driver can be loaded automatically by the kernel and
+supports hot swapping.
+
+Possible pwm_enable values are:
+
+====== ==========================================================================
+0 Set fan to 100%
+1 Direct PWM mode (applies value in corresponding PWM entry)
+2 Curve control mode (applies the temp-PWM duty curve based on coolant temp)
+====== ==========================================================================
+
+Sysfs entries
+-------------
+
+============================== ================================================================
+fan1_input Pump speed (in rpm)
+fan2_input Fan speed (in rpm)
+temp1_input Coolant temperature (in millidegrees Celsius)
+pwm1 Pump duty (value between 0-255)
+pwm1_enable Pump duty control mode (0: disabled, 1: manual, 2: curve)
+pwm2 Fan duty (value between 0-255)
+pwm2_enable Fan duty control mode (0: disabled, 1: manual, 2: curve)
+temp[1-2]_auto_point[1-40]_pwm Temp-PWM duty curves (for pump and fan), related to coolant temp
+============================== ================================================================
diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst
index 84c5a4e40c40..fdfb23773148 100644
--- a/Documentation/hwmon/pmbus-core.rst
+++ b/Documentation/hwmon/pmbus-core.rst
@@ -174,7 +174,7 @@ Read byte from page <page>, register <reg>.
int (*read_word_data)(struct i2c_client *client, int page, int phase,
int reg);
-Read word from page <page>, phase <pase>, register <reg>. If the chip does not
+Read word from page <page>, phase <phase>, register <reg>. If the chip does not
support multiple phases, the phase parameter can be ignored. If the chip
supports multiple phases, a phase value of 0xff indicates all phases.
@@ -308,6 +308,14 @@ currently provides a flags field with four bits used::
#define PMBUS_READ_STATUS_AFTER_FAILED_CHECK BIT(3)
+ #define PMBUS_NO_WRITE_PROTECT BIT(4)
+
+ #define PMBUS_USE_COEFFICIENTS_CMD BIT(5)
+
+ #define PMBUS_OP_PROTECTED BIT(6)
+
+ #define PMBUS_VOUT_PROTECTED BIT(7)
+
struct pmbus_platform_data {
u32 flags; /* Device specific flags */
@@ -345,7 +353,7 @@ PMBUS_NO_CAPABILITY
Some PMBus chips don't respond with valid data when reading the CAPABILITY
register. For such chips, this flag should be set so that the PMBus core
-driver doesn't use CAPABILITY to determine it's behavior.
+driver doesn't use CAPABILITY to determine its behavior.
PMBUS_READ_STATUS_AFTER_FAILED_CHECK
@@ -358,3 +366,45 @@ This can be done by reading a known register. By setting this flag the
driver will try to read the STATUS register after each failed
register check. This read may fail, but it will put the chip into a
known state.
+
+PMBUS_NO_WRITE_PROTECT
+
+Some PMBus chips respond with invalid data when reading the WRITE_PROTECT
+register. For such chips, this flag should be set so that the PMBus core
+driver doesn't use the WRITE_PROTECT command to determine its behavior.
+
+PMBUS_USE_COEFFICIENTS_CMD
+
+When this flag is set the PMBus core driver will use the COEFFICIENTS
+register to initialize the coefficients for the direct mode format.
+
+PMBUS_OP_PROTECTED
+
+Set if the chip OPERATION command is protected and protection is not
+determined by the standard WRITE_PROTECT command.
+
+PMBUS_VOUT_PROTECTED
+
+Set if the chip VOUT_COMMAND command is protected and protection is not
+determined by the standard WRITE_PROTECT command.
+
+Module parameter
+----------------
+
+pmbus_core.wp: PMBus write protect forced mode
+
+PMBus may come up with a variety of write protection configuration.
+'pmbus_core.wp' may be used if a particular write protection is necessary.
+The ability to actually alter the protection may also depend on the chip
+so the actual runtime write protection configuration may differ from
+the requested one. pmbus_core currently support the following value:
+
+* 0: write protection removed.
+* 1: Disable all writes except to the WRITE_PROTECT, OPERATION,
+ PAGE, ON_OFF_CONFIG and VOUT_COMMAND commands.
+* 2: Disable all writes except to the WRITE_PROTECT, OPERATION and
+ PAGE commands.
+* 3: Disable all writes except to the WRITE_PROTECT command. Note that
+ protection should include the PAGE register. This may be problematic
+ for multi-page chips, if the chips strictly follows the PMBus
+ specification, preventing the chip from changing the active page.
diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst
index 7ecfec6ca2db..a8e01a5b96da 100644
--- a/Documentation/hwmon/pmbus.rst
+++ b/Documentation/hwmon/pmbus.rst
@@ -74,7 +74,7 @@ Supported chips:
Datasheet:
- Not published
+ https://www.analog.com/media/en/technical-documentation/data-sheets/MAX20796.pdf
* Generic PMBus devices
@@ -152,7 +152,7 @@ Emerson DS1200 power modules might look as follows::
}
static const struct i2c_device_id ds1200_id[] = {
- {"ds1200", 0},
+ {"ds1200"},
{}
};
@@ -163,7 +163,7 @@ Emerson DS1200 power modules might look as follows::
.driver = {
.name = "ds1200",
},
- .probe_new = ds1200_probe,
+ .probe = ds1200_probe,
.id_table = ds1200_id,
};
diff --git a/Documentation/hwmon/powerz.rst b/Documentation/hwmon/powerz.rst
new file mode 100644
index 000000000000..317084e0b76b
--- /dev/null
+++ b/Documentation/hwmon/powerz.rst
@@ -0,0 +1,30 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver POWERZ
+====================
+
+Supported chips:
+
+ * ChargerLAB POWER-Z KM003C
+
+ Prefix: 'powerz'
+
+ Addresses scanned: -
+
+Author:
+
+ - Thomas Weißschuh <linux@weissschuh.net>
+
+Description
+-----------
+
+This driver implements support for the ChargerLAB POWER-Z USB-C power testing
+family.
+
+The device communicates with the custom protocol over USB.
+
+The channel labels exposed via hwmon match the labels used by the on-device
+display and the official POWER-Z PC software.
+
+As current can flow in both directions through the tester the sign of the
+channel "curr1_input" (label "IBUS") indicates the direction.
diff --git a/Documentation/hwmon/pt5161l.rst b/Documentation/hwmon/pt5161l.rst
new file mode 100644
index 000000000000..1b97336991ea
--- /dev/null
+++ b/Documentation/hwmon/pt5161l.rst
@@ -0,0 +1,42 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver pt5161l
+=====================
+
+Supported chips:
+
+ * Astera Labs PT5161L
+
+ Prefix: 'pt5161l'
+
+ Addresses scanned: I2C 0x20 - 0x27
+
+ Datasheet: Not publicly available.
+
+Authors: Cosmo Chou <cosmo.chou@quantatw.com>
+
+Description
+-----------
+
+This driver implements support for temperature monitoring of Astera Labs
+PT5161L series PCIe retimer chips.
+
+This driver implementation originates from the CSDK available at
+https://github.com/facebook/openbmc/tree/helium/common/recipes-lib/retimer-v2.14
+The communication protocol utilized is based on the I2C/SMBus standard.
+
+Sysfs entries
+----------------
+
+================ ==============================================
+temp1_input Measured temperature (in millidegrees Celsius)
+================ ==============================================
+
+Debugfs entries
+----------------
+
+================ ===============================
+fw_load_status Firmware load status
+fw_ver Firmware version of the retimer
+heartbeat_status Heartbeat status
+================ ===============================
diff --git a/Documentation/hwmon/qnap-mcu-hwmon.rst b/Documentation/hwmon/qnap-mcu-hwmon.rst
new file mode 100644
index 000000000000..83407e3408f2
--- /dev/null
+++ b/Documentation/hwmon/qnap-mcu-hwmon.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver qnap-mcu-hwmon
+============================
+
+This driver enables the use of the hardware monitoring and fan control
+of the MCU used on some QNAP network attached storage devices.
+
+Author: Heiko Stuebner <heiko@sntech.de>
+
+Description
+-----------
+
+The driver implements a simple interface for driving the fan controlled by
+setting its PWM output value and exposes the fan rpm and case-temperature
+to user space through hwmon's sysfs interface.
+
+The fan rotation speed returned via the optional 'fan1_input' is calculated
+inside the MCU device.
+
+The driver provides the following sensor accesses in sysfs:
+
+=============== ======= =======================================================
+fan1_input ro fan tachometer speed in RPM
+pwm1 rw relative speed (0-255), 255=max. speed.
+temp1_input ro Measured temperature in millicelsius
+=============== ======= =======================================================
diff --git a/Documentation/hwmon/sa67.rst b/Documentation/hwmon/sa67.rst
new file mode 100644
index 000000000000..029c7c169b7f
--- /dev/null
+++ b/Documentation/hwmon/sa67.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver sa67mcu
+=====================
+
+Supported chips:
+
+ * Kontron sa67mcu
+
+ Prefix: 'sa67mcu'
+
+ Datasheet: not available
+
+Authors: Michael Walle <mwalle@kernel.org>
+
+Description
+-----------
+
+The sa67mcu is a board management controller which also exposes a hardware
+monitoring controller.
+
+The controller has two voltage and one temperature sensor. The values are
+hold in two 8 bit registers to form one 16 bit value. Reading the lower byte
+will also capture the high byte to make the access atomic. The unit of the
+volatge sensors are 1mV and the unit of the temperature sensor is 0.1degC.
+
+Sysfs entries
+-------------
+
+The following attributes are supported.
+
+======================= ========================================================
+in0_label "VDDIN"
+in0_input Measured VDDIN voltage.
+
+in1_label "VDD_RTC"
+in1_input Measured VDD_RTC voltage.
+
+temp1_input MCU temperature. Roughly the board temperature.
+======================= ========================================================
+
diff --git a/Documentation/hwmon/sch5627.rst b/Documentation/hwmon/sch5627.rst
index ecb4fc84d045..5f521c6e90ab 100644
--- a/Documentation/hwmon/sch5627.rst
+++ b/Documentation/hwmon/sch5627.rst
@@ -33,3 +33,13 @@ The hardware monitoring part of the SMSC SCH5627 is accessed by talking
through an embedded microcontroller. An application note describing the
protocol for communicating with the microcontroller is available upon
request. Please mail me if you want a copy.
+
+
+Controlling fan speed
+---------------------
+
+The SCH5627 allows for partially controlling the fan speed. If a temperature
+channel exceeds tempX_max, all fans are forced to maximum speed. The same is not
+true for tempX_crit, presumably some other measures to cool down the system are
+take in this case.
+In which way the value of fanX_min affects the fan speed is currently unknown.
diff --git a/Documentation/hwmon/sfctemp.rst b/Documentation/hwmon/sfctemp.rst
new file mode 100644
index 000000000000..9fbd5bb1f356
--- /dev/null
+++ b/Documentation/hwmon/sfctemp.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver sfctemp
+=====================
+
+Supported chips:
+ - StarFive JH7100
+ - StarFive JH7110
+
+Authors:
+ - Emil Renner Berthing <kernel@esmil.dk>
+
+Description
+-----------
+
+This driver adds support for reading the built-in temperature sensor on the
+JH7100 and JH7110 RISC-V SoCs by StarFive Technology Co. Ltd.
+
+``sysfs`` interface
+-------------------
+
+The temperature sensor can be enabled, disabled and queried via the standard
+hwmon interface in sysfs under ``/sys/class/hwmon/hwmonX`` for some value of
+``X``:
+
+================ ==== =============================================
+Name Perm Description
+================ ==== =============================================
+temp1_enable RW Enable or disable temperature sensor.
+ Automatically enabled by the driver,
+ but may be disabled to save power.
+temp1_input RO Temperature reading in milli-degrees Celsius.
+================ ==== =============================================
diff --git a/Documentation/hwmon/sg2042-mcu.rst b/Documentation/hwmon/sg2042-mcu.rst
new file mode 100644
index 000000000000..077e79841d2e
--- /dev/null
+++ b/Documentation/hwmon/sg2042-mcu.rst
@@ -0,0 +1,78 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver sg2042-mcu
+========================
+
+Supported chips:
+
+ * Onboard MCU for sg2042
+
+ Addresses scanned: -
+
+ Prefix: 'sg2042-mcu'
+
+Authors:
+
+ - Inochi Amaoto <inochiama@outlook.com>
+
+Description
+-----------
+
+This driver supprts hardware monitoring for onboard MCU with
+i2c interface.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate
+the devices explicitly.
+Please see Documentation/i2c/instantiating-devices.rst for details.
+
+Sysfs Attributes
+----------------
+
+The following table shows the standard entries support by the driver:
+
+================= =====================================================
+Name Description
+================= =====================================================
+temp1_input Measured temperature of SoC
+temp1_crit Critical high temperature
+temp1_crit_hyst hysteresis temperature restore from Critical
+temp2_input Measured temperature of the base board
+================= =====================================================
+
+The following table shows the extra entries support by the driver
+(the MCU device is in i2c subsystem):
+
+================= ======= =============================================
+Name Perm Description
+================= ======= =============================================
+reset_count RO Reset count of the SoC
+uptime RO Seconds after the MCU is powered
+reset_reason RO Reset reason for the last reset
+repower_policy RW Execution policy when triggering repower
+================= ======= =============================================
+
+``repower_policy``
+ The repower is triggered when the temperature of the SoC falls below
+ the hysteresis temperature after triggering a shutdown due to
+ reaching the critical temperature.
+ The valid values for this entry are "repower" and "keep". "keep" will
+ leave the SoC down when the triggering repower, and "repower" will
+ boot the SoC.
+
+Debugfs Interfaces
+------------------
+
+If debugfs is available, this driver exposes some hardware specific
+data in ``/sys/kernel/debug/sg2042-mcu/*/``.
+
+================= ======= =============================================
+Name Format Description
+================= ======= =============================================
+firmware_version 0x%02x firmware version of the MCU
+pcb_version 0x%02x version number of the base board
+board_type 0x%02x identifiers for the base board
+mcu_type %d type of the MCU: 0 is STM32, 1 is GD32
+================= ======= =============================================
diff --git a/Documentation/hwmon/sht21.rst b/Documentation/hwmon/sht21.rst
index 1bccc8e8aac8..d20e8a460ba6 100644
--- a/Documentation/hwmon/sht21.rst
+++ b/Documentation/hwmon/sht21.rst
@@ -3,6 +3,16 @@ Kernel driver sht21
Supported chips:
+ * Sensirion SHT20
+
+ Prefix: 'sht20'
+
+ Addresses scanned: none
+
+ Datasheet: Publicly available at the Sensirion website
+
+ https://www.sensirion.com/file/datasheet_sht20
+
* Sensirion SHT21
Prefix: 'sht21'
@@ -13,8 +23,6 @@ Supported chips:
https://www.sensirion.com/file/datasheet_sht21
-
-
* Sensirion SHT25
Prefix: 'sht25'
@@ -25,8 +33,6 @@ Supported chips:
https://www.sensirion.com/file/datasheet_sht25
-
-
Author:
Urs Fleisch <urs.fleisch@sensirion.com>
@@ -47,13 +53,11 @@ in the board setup code.
sysfs-Interface
---------------
-temp1_input
- - temperature input
-
-humidity1_input
- - humidity input
-eic
- - Electronic Identification Code
+=================== ============================================================
+temp1_input Temperature input
+humidity1_input Humidity input
+eic Electronic Identification Code
+=================== ============================================================
Notes
-----
diff --git a/Documentation/hwmon/sht3x.rst b/Documentation/hwmon/sht3x.rst
index 95a850d5b2c1..9585fa7c5a5d 100644
--- a/Documentation/hwmon/sht3x.rst
+++ b/Documentation/hwmon/sht3x.rst
@@ -9,7 +9,19 @@ Supported chips:
Addresses scanned: none
- Datasheet: https://www.sensirion.com/file/datasheet_sht3x_digital
+ Datasheets:
+ - https://sensirion.com/media/documents/213E6A3B/63A5A569/Datasheet_SHT3x_DIS.pdf
+ - https://sensirion.com/media/documents/051DF50B/639C8101/Sensirion_Humidity_and_Temperature_Sensors_Datasheet_SHT33.pdf
+
+ * Sensirion STS3x-DIS
+
+ Prefix: 'sts3x'
+
+ Addresses scanned: none
+
+ Datasheets:
+ - https://sensirion.com/media/documents/1DA31AFD/61641F76/Sensirion_Temperature_Sensors_STS3x_Datasheet.pdf
+ - https://sensirion.com/media/documents/292A335C/65537BAF/Sensirion_Datasheet_STS32_STS33.pdf
Author:
@@ -19,24 +31,18 @@ Author:
Description
-----------
-This driver implements support for the Sensirion SHT3x-DIS chip, a humidity
-and temperature sensor. Temperature is measured in degrees celsius, relative
-humidity is expressed as a percentage. In the sysfs interface, all values are
-scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+This driver implements support for the Sensirion SHT3x-DIS and STS3x-DIS
+series of humidity and temperature sensors. Temperature is measured in degrees
+celsius, relative humidity is expressed as a percentage. In the sysfs interface,
+all values are scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
The device communicates with the I2C protocol. Sensors can have the I2C
-addresses 0x44 or 0x45, depending on the wiring. See
-Documentation/i2c/instantiating-devices.rst for methods to instantiate the device.
-
-There are two options configurable by means of sht3x_platform_data:
+addresses 0x44 or 0x45 (0x4a or 0x4b for sts3x), depending on the wiring. See
+Documentation/i2c/instantiating-devices.rst for methods to instantiate the
+device.
-1. blocking (pull the I2C clock line down while performing the measurement) or
- non-blocking mode. Blocking mode will guarantee the fastest result but
- the I2C bus will be busy during that time. By default, non-blocking mode
- is used. Make sure clock-stretching works properly on your device if you
- want to use blocking mode.
-2. high or low accuracy. High accuracy is used by default and using it is
- strongly recommended.
+Even if sht3x sensor supports clock-stretch (blocking mode) and non-stretch
+(non-blocking mode) in single-shot mode, this driver only supports the latter.
The sht3x sensor supports a single shot mode as well as 5 periodic measure
modes, which can be controlled with the update_interval sysfs interface.
@@ -59,6 +65,10 @@ When the temperature and humidity readings move back between the hysteresis
values, the alert bit is set to 0 and the alert pin on the sensor is set to
low.
+The serial number exposed to debugfs allows for unique identification of the
+sensors. For sts32, sts33 and sht33, the manufacturer provides calibration
+certificates through an API.
+
sysfs-Interface
---------------
@@ -85,4 +95,18 @@ heater_enable: heater enable, heating element removes excess humidity from
update_interval: update interval, 0 for single shot, interval in msec
for periodic measurement. If the interval is not supported
by the sensor, the next faster interval is chosen
+repeatability: write or read repeatability, higher repeatability means
+ longer measurement duration, lower noise level and
+ larger energy consumption:
+
+ - 0: low repeatability
+ - 1: medium repeatability
+ - 2: high repeatability
+=================== ============================================================
+
+debugfs-Interface
+-----------------
+
+=================== ============================================================
+serial_number: unique serial number of the sensor in decimal
=================== ============================================================
diff --git a/Documentation/hwmon/sht4x.rst b/Documentation/hwmon/sht4x.rst
index c318e5582ead..ba094ad0e281 100644
--- a/Documentation/hwmon/sht4x.rst
+++ b/Documentation/hwmon/sht4x.rst
@@ -37,9 +37,23 @@ Sysfs entries
-------------
=============== ============================================
-temp1_input Measured temperature in millidegrees Celcius
+temp1_input Measured temperature in millidegrees Celsius
humidity1_input Measured humidity in %H
update_interval The minimum interval for polling the sensor,
in milliseconds. Writable. Must be at least
2000.
+heater_power The requested heater power, in milliwatts.
+ Available values: 20, 110, 200 (default: 200).
+heater_time The requested operating time of the heater,
+ in milliseconds.
+ Available values: 100, 1000 (default 1000).
+heater_enable Enable the heater with the selected power
+ and for the selected time in order to remove
+ condensed water from the sensor surface. The
+ heater cannot be manually turned off once
+ enabled (it will automatically turn off
+ after completing its operation).
+
+ - 0: turned off (read-only value)
+ - 1: turn on
=============== ============================================
diff --git a/Documentation/hwmon/smm665.rst b/Documentation/hwmon/smm665.rst
deleted file mode 100644
index a0e27f62b57b..000000000000
--- a/Documentation/hwmon/smm665.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-Kernel driver smm665
-====================
-
-Supported chips:
-
- * Summit Microelectronics SMM465
-
- Prefix: 'smm465'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM465/SMM465DS.pdf
-
- * Summit Microelectronics SMM665, SMM665B
-
- Prefix: 'smm665'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM665/SMM665B_2089_20.pdf
-
- * Summit Microelectronics SMM665C
-
- Prefix: 'smm665c'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM665C/SMM665C_2125.pdf
-
- * Summit Microelectronics SMM764
-
- Prefix: 'smm764'
-
- Addresses scanned: -
-
- Datasheet:
-
- http://www.summitmicro.com/prod_select/summary/SMM764/SMM764_2098.pdf
-
- * Summit Microelectronics SMM766, SMM766B
-
- Prefix: 'smm766'
-
- Addresses scanned: -
-
- Datasheets:
-
- http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
-
- http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
-
-Author: Guenter Roeck <linux@roeck-us.net>
-
-
-Module Parameters
------------------
-
-* vref: int
- Default: 1250 (mV)
-
- Reference voltage on VREF_ADC pin in mV. It should not be necessary to set
- this parameter unless a non-default reference voltage is used.
-
-
-Description
------------
-
-[From datasheet] The SMM665 is an Active DC Output power supply Controller
-that monitors, margins and cascade sequences power. The part monitors six
-power supply channels as well as VDD, 12V input, two general-purpose analog
-inputs and an internal temperature sensor using a 10-bit ADC.
-
-Each monitored channel has its own high and low limits, plus a critical
-limit.
-
-Support for SMM465, SMM764, and SMM766 has been implemented but is untested.
-
-
-Usage Notes
------------
-
-This driver does not probe for devices, since there is no register which
-can be safely used to identify the chip. You will have to instantiate
-the devices explicitly. When instantiating the device, you have to specify
-its configuration register address.
-
-Example: the following will load the driver for an SMM665 at address 0x57
-on I2C bus #1::
-
- $ modprobe smm665
- $ echo smm665 0x57 > /sys/bus/i2c/devices/i2c-1/new_device
-
-
-Sysfs entries
--------------
-
-This driver uses the values in the datasheet to convert ADC register values
-into the values specified in the sysfs-interface document. All attributes are
-read only.
-
-Min, max, lcrit, and crit values are used by the chip to trigger external signals
-and/or other activity. Triggered signals can include HEALTHY, RST, Power Off,
-or Fault depending on the chip configuration. The driver reports values as lcrit
-or crit if exceeding the limits triggers RST, Power Off, or Fault, and as min or
-max otherwise. For details please see the SMM665 datasheet.
-
-For SMM465 and SMM764, values for Channel E and F are reported but undefined.
-
-======================= =======================================================
-in1_input 12V input voltage (mV)
-in2_input 3.3V (VDD) input voltage (mV)
-in3_input Channel A voltage (mV)
-in4_input Channel B voltage (mV)
-in5_input Channel C voltage (mV)
-in6_input Channel D voltage (mV)
-in7_input Channel E voltage (mV)
-in8_input Channel F voltage (mV)
-in9_input AIN1 voltage (mV)
-in10_input AIN2 voltage (mV)
-
-in1_min 12v input minimum voltage (mV)
-in2_min 3.3V (VDD) input minimum voltage (mV)
-in3_min Channel A minimum voltage (mV)
-in4_min Channel B minimum voltage (mV)
-in5_min Channel C minimum voltage (mV)
-in6_min Channel D minimum voltage (mV)
-in7_min Channel E minimum voltage (mV)
-in8_min Channel F minimum voltage (mV)
-in9_min AIN1 minimum voltage (mV)
-in10_min AIN2 minimum voltage (mV)
-
-in1_max 12v input maximum voltage (mV)
-in2_max 3.3V (VDD) input maximum voltage (mV)
-in3_max Channel A maximum voltage (mV)
-in4_max Channel B maximum voltage (mV)
-in5_max Channel C maximum voltage (mV)
-in6_max Channel D maximum voltage (mV)
-in7_max Channel E maximum voltage (mV)
-in8_max Channel F maximum voltage (mV)
-in9_max AIN1 maximum voltage (mV)
-in10_max AIN2 maximum voltage (mV)
-
-in1_lcrit 12v input critical minimum voltage (mV)
-in2_lcrit 3.3V (VDD) input critical minimum voltage (mV)
-in3_lcrit Channel A critical minimum voltage (mV)
-in4_lcrit Channel B critical minimum voltage (mV)
-in5_lcrit Channel C critical minimum voltage (mV)
-in6_lcrit Channel D critical minimum voltage (mV)
-in7_lcrit Channel E critical minimum voltage (mV)
-in8_lcrit Channel F critical minimum voltage (mV)
-in9_lcrit AIN1 critical minimum voltage (mV)
-in10_lcrit AIN2 critical minimum voltage (mV)
-
-in1_crit 12v input critical maximum voltage (mV)
-in2_crit 3.3V (VDD) input critical maximum voltage (mV)
-in3_crit Channel A critical maximum voltage (mV)
-in4_crit Channel B critical maximum voltage (mV)
-in5_crit Channel C critical maximum voltage (mV)
-in6_crit Channel D critical maximum voltage (mV)
-in7_crit Channel E critical maximum voltage (mV)
-in8_crit Channel F critical maximum voltage (mV)
-in9_crit AIN1 critical maximum voltage (mV)
-in10_crit AIN2 critical maximum voltage (mV)
-
-in1_crit_alarm 12v input critical alarm
-in2_crit_alarm 3.3V (VDD) input critical alarm
-in3_crit_alarm Channel A critical alarm
-in4_crit_alarm Channel B critical alarm
-in5_crit_alarm Channel C critical alarm
-in6_crit_alarm Channel D critical alarm
-in7_crit_alarm Channel E critical alarm
-in8_crit_alarm Channel F critical alarm
-in9_crit_alarm AIN1 critical alarm
-in10_crit_alarm AIN2 critical alarm
-
-temp1_input Chip temperature
-temp1_min Mimimum chip temperature
-temp1_max Maximum chip temperature
-temp1_crit Critical chip temperature
-temp1_crit_alarm Temperature critical alarm
-======================= =======================================================
diff --git a/Documentation/hwmon/smpro-hwmon.rst b/Documentation/hwmon/smpro-hwmon.rst
new file mode 100644
index 000000000000..fb7b3665735b
--- /dev/null
+++ b/Documentation/hwmon/smpro-hwmon.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver Ampere(R)'s Altra(R) SMpro hwmon
+==============================================
+
+Supported chips:
+
+ * Ampere(R) Altra(R)
+
+ Prefix: ``smpro``
+
+ Reference: `Altra SoC BMC Interface Specification`
+
+Author: Thu Nguyen <thu@os.amperecomputing.com>
+
+Description
+-----------
+The smpro-hwmon driver supports hardware monitoring for Ampere(R) Altra(R)
+SoCs based on the SMpro co-processor (SMpro). The following sensor metrics
+are supported by the driver:
+
+ * temperature
+ * voltage
+ * current
+ * power
+
+The interface provides the registers to query the various sensors and
+their values which are then exported to userspace by this driver.
+
+Usage Notes
+-----------
+
+The driver creates at least two sysfs files for each sensor.
+
+* ``<sensor_type><idx>_label`` reports the sensor label.
+* ``<sensor_type><idx>_input`` returns the sensor value.
+
+The sysfs files are allocated in the SMpro rootfs folder, with one root
+directory for each instance.
+
+When the SoC is turned off, the driver will fail to read registers and
+return ``-ENXIO``.
+
+Sysfs entries
+-------------
+
+The following sysfs files are supported:
+
+* Ampere(R) Altra(R):
+
+ ============ ============= ====== ===============================================
+ Name Unit Perm Description
+ ============ ============= ====== ===============================================
+ temp1_input millicelsius RO SoC temperature
+ temp2_input millicelsius RO Max temperature reported among SoC VRDs
+ temp2_crit millicelsius RO SoC VRD HOT Threshold temperature
+ temp3_input millicelsius RO Max temperature reported among DIMM VRDs
+ temp4_input millicelsius RO Max temperature reported among Core VRDs
+ temp5_input millicelsius RO Temperature of DIMM0 on CH0
+ temp5_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp6_input millicelsius RO Temperature of DIMM0 on CH1
+ temp6_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp7_input millicelsius RO Temperature of DIMM0 on CH2
+ temp7_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp8_input millicelsius RO Temperature of DIMM0 on CH3
+ temp8_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp9_input millicelsius RO Temperature of DIMM0 on CH4
+ temp9_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp10_input millicelsius RO Temperature of DIMM0 on CH5
+ temp10_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp11_input millicelsius RO Temperature of DIMM0 on CH6
+ temp11_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp12_input millicelsius RO Temperature of DIMM0 on CH7
+ temp12_crit millicelsius RO MEM HOT Threshold for all DIMMs
+ temp13_input millicelsius RO Max temperature reported among RCA VRDs
+ in0_input millivolts RO Core voltage
+ in1_input millivolts RO SoC voltage
+ in2_input millivolts RO DIMM VRD1 voltage
+ in3_input millivolts RO DIMM VRD2 voltage
+ in4_input millivolts RO RCA VRD voltage
+ cur1_input milliamperes RO Core VRD current
+ cur2_input milliamperes RO SoC VRD current
+ cur3_input milliamperes RO DIMM VRD1 current
+ cur4_input milliamperes RO DIMM VRD2 current
+ cur5_input milliamperes RO RCA VRD current
+ power1_input microwatts RO Core VRD power
+ power2_input microwatts RO SoC VRD power
+ power3_input microwatts RO DIMM VRD1 power
+ power4_input microwatts RO DIMM VRD2 power
+ power5_input microwatts RO RCA VRD power
+ ============ ============= ====== ===============================================
+
+ Example::
+
+ # cat in0_input
+ 830
+ # cat temp1_input
+ 37000
+ # cat curr1_input
+ 9000
+ # cat power5_input
+ 19500000
diff --git a/Documentation/hwmon/spd5118.rst b/Documentation/hwmon/spd5118.rst
new file mode 100644
index 000000000000..ef7338f46575
--- /dev/null
+++ b/Documentation/hwmon/spd5118.rst
@@ -0,0 +1,63 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver spd5118
+=====================
+
+Supported chips:
+
+ * SPD5118 (JEDEC JESD300) compliant temperature sensor chips
+
+ JEDEC standard download:
+ https://www.jedec.org/standards-documents/docs/jesd300-5b01
+ (account required)
+
+
+ Prefix: 'spd5118'
+
+ Addresses scanned: I2C 0x50 - 0x57
+
+Author:
+ Guenter Roeck <linux@roeck-us.net>
+
+
+Description
+-----------
+
+This driver implements support for SPD5118 (JEDEC JESD300) compliant temperature
+sensors, which are used on many DDR5 memory modules. Some systems use the sensor
+to prevent memory overheating by automatically throttling the memory controller.
+
+The driver auto-detects SPD5118 compliant chips, but can also be instantiated
+using devicetree/firmware nodes.
+
+A SPD5118 compliant chip supports a single temperature sensor. Critical minimum,
+minimum, maximum, and critical temperature can be configured. There are alarms
+for low critical, low, high, and critical thresholds.
+
+
+Hardware monitoring sysfs entries
+---------------------------------
+
+======================= ==================================
+temp1_input Temperature (RO)
+temp1_lcrit Low critical high temperature (RW)
+temp1_min Minimum temperature (RW)
+temp1_max Maximum temperature (RW)
+temp1_crit Critical high temperature (RW)
+
+temp1_lcrit_alarm Temperature low critical alarm
+temp1_min_alarm Temperature low alarm
+temp1_max_alarm Temperature high alarm
+temp1_crit_alarm Temperature critical alarm
+======================= ==================================
+
+Alarm attributes are sticky until read and will be cleared afterwards
+unless the alarm condition still applies.
+
+
+SPD (Serial Presence Detect) support
+------------------------------------
+
+The driver also supports reading the SPD NVRAM on SPD5118 compatible chips.
+SPD data is available from the 'eeprom' binary attribute file attached to the
+chip's I2C device.
diff --git a/Documentation/hwmon/stpddc60.rst b/Documentation/hwmon/stpddc60.rst
index 7f7ce7f7871b..0c31f78fe58b 100644
--- a/Documentation/hwmon/stpddc60.rst
+++ b/Documentation/hwmon/stpddc60.rst
@@ -39,7 +39,7 @@ output voltage as a positive or negative offset in the interval 50mV to 400mV
in 50mV steps. This means that the absolute values of the limits will change
when the commanded output voltage changes. Also, care should be taken when
writing to those limits since in the worst case the commanded output voltage
-could change at the same time as the limit is written to, wich will lead to
+could change at the same time as the limit is written to, which will lead to
unpredictable results.
diff --git a/Documentation/hwmon/submitting-patches.rst b/Documentation/hwmon/submitting-patches.rst
index d953ee763c96..6482c4f137dc 100644
--- a/Documentation/hwmon/submitting-patches.rst
+++ b/Documentation/hwmon/submitting-patches.rst
@@ -126,7 +126,7 @@ increase the chances of your change being accepted.
* Use devm_hwmon_device_register_with_info() or, if your driver needs a remove
function, hwmon_device_register_with_info() to register your driver with the
hwmon subsystem. Try using devm_add_action() instead of a remove function if
- possible. Do not use hwmon_device_register().
+ possible. Do not use any of the deprecated registration functions.
* Your driver should be buildable as module. If not, please be prepared to
explain why it has to be built into the kernel.
diff --git a/Documentation/hwmon/surface_fan.rst b/Documentation/hwmon/surface_fan.rst
new file mode 100644
index 000000000000..07942574c4f0
--- /dev/null
+++ b/Documentation/hwmon/surface_fan.rst
@@ -0,0 +1,25 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver surface_fan
+=========================
+
+Supported Devices:
+
+ * Microsoft Surface Pro 9
+
+Author: Ivor Wanders <ivor@iwanders.net>
+
+Description
+-----------
+
+This provides monitoring of the fan found in some Microsoft Surface Pro devices,
+like the Surface Pro 9. The fan is always controlled by the onboard controller.
+
+Sysfs interface
+---------------
+
+======================= ======= =========================================
+Name Perm Description
+======================= ======= =========================================
+``fan1_input`` RO Current fan speed in RPM.
+======================= ======= =========================================
diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst
index c85db7b32941..0143ce0e5db7 100644
--- a/Documentation/hwmon/sy7636a-hwmon.rst
+++ b/Documentation/hwmon/sy7636a-hwmon.rst
@@ -17,10 +17,10 @@ the Silergy SY7636A PMIC.
The following sensors are supported
* Temperature
- - SoC on-die temperature in milli-degree C
+ - Temperature of external NTC in milli-degree C
sysfs-Interface
---------------
temp0_input
- - SoC on-die temperature (milli-degree C)
+ - Temperature of external NTC (milli-degree C)
diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst
index 209626fb2405..f76e9f8cc1ad 100644
--- a/Documentation/hwmon/sysfs-interface.rst
+++ b/Documentation/hwmon/sysfs-interface.rst
@@ -201,7 +201,7 @@ PWM
Pulse width modulation fan control.
`pwm[1-*]_enable`
- Fan speed control method:
+ Fan speed control method.
`pwm[1-*]_mode`
direct current or pulse-width modulation.
diff --git a/Documentation/hwmon/tmp108.rst b/Documentation/hwmon/tmp108.rst
index 6df7cf1b42f4..bc4941d98268 100644
--- a/Documentation/hwmon/tmp108.rst
+++ b/Documentation/hwmon/tmp108.rst
@@ -3,6 +3,14 @@ Kernel driver tmp108
Supported chips:
+ * NXP P3T1085
+
+ Prefix: 'p3t1085'
+
+ Addresses scanned: none
+
+ Datasheet: https://www.nxp.com/docs/en/data-sheet/P3T1085UK.pdf
+
* Texas Instruments TMP108
Prefix: 'tmp108'
diff --git a/Documentation/hwmon/tps25990.rst b/Documentation/hwmon/tps25990.rst
new file mode 100644
index 000000000000..04faec780d26
--- /dev/null
+++ b/Documentation/hwmon/tps25990.rst
@@ -0,0 +1,147 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver tps25990
+======================
+
+Supported chips:
+
+ * TI TPS25990
+
+ Prefix: 'tps25990'
+
+ * Datasheet
+
+ Publicly available at Texas Instruments website: https://www.ti.com/lit/gpn/tps25990
+
+Author:
+
+ Jerome Brunet <jbrunet@baylibre.com>
+
+Description
+-----------
+
+This driver implements support for TI TPS25990 eFuse.
+This is an integrated, high-current circuit protection and power
+management device with PMBUS interface
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Device supports direct format for reading input voltages,
+output voltage, input current, input power and temperature.
+
+Due to the specificities of the chip, all history reset attributes
+are tied together. Resetting the history of a sensor, resets the
+history of all the sensors.
+
+The driver exports the following attributes via the 'sysfs' files
+for input current:
+
+**curr1_average**
+
+**curr1_crit**
+
+**curr1_crit_alarm**
+
+**curr1_highest**
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_max**
+
+**curr1_max_alarm**
+
+**curr1_reset_history**
+
+The driver provides the following attributes for main input voltage:
+
+**in1_average**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_highest**
+
+**in1_input**
+
+**in1_label**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_lowest**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+**in1_reset_history**
+
+The driver provides the following attributes for auxiliary input voltage:
+
+**in2_input**
+
+**in2_label**
+
+The driver provides the following attributes for output voltage:
+
+**in3_average**
+
+**in3_input**
+
+**in3_label**
+
+**in3_lowest**
+
+**in3_min**
+
+**in3_min_alarm**
+
+**in3_reset_history**
+
+The driver provides the following attributes for input power:
+
+**power1_alarm**
+
+**power1_average**
+
+**power1_input**
+
+**power1_input_highest**
+
+**power1_label**
+
+**power1_max**
+
+**power1_reset_history**
+
+The driver provides the following attributes for temperature:
+
+**temp1_average**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_highest**
+
+**temp1_input**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp1_reset_history**
+
+The driver provides the following attributes for sampling:
+
+**samples**
diff --git a/Documentation/hwmon/tps53679.rst b/Documentation/hwmon/tps53679.rst
index 3b9561648c24..dd5e4a37375d 100644
--- a/Documentation/hwmon/tps53679.rst
+++ b/Documentation/hwmon/tps53679.rst
@@ -43,6 +43,14 @@ Supported chips:
Datasheet: https://www.ti.com/lit/gpn/TPS53681
+ * Texas Instruments TPS53685
+
+ Prefix: 'tps53685'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.ti.com/lit/gpn/TPS53685
+
* Texas Instruments TPS53688
Prefix: 'tps53688'
diff --git a/Documentation/hwmon/tsc1641.rst b/Documentation/hwmon/tsc1641.rst
new file mode 100644
index 000000000000..425e25f7a7d1
--- /dev/null
+++ b/Documentation/hwmon/tsc1641.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver tsc1641
+=====================
+
+Supported chips:
+
+ * ST TSC1641
+
+ Prefix: 'tsc1641'
+
+ Addresses scanned: -
+
+ Datasheet:
+ https://www.st.com/resource/en/datasheet/tsc1641.pdf
+
+Author:
+ - Igor Reznichenko <igor@reznichenko.net>
+
+
+Description
+-----------
+
+The TSC1641 is a high-precision current, voltage, power, and temperature
+monitoring analog front-end (AFE). It monitors bidirectional current into a
+shunt resistor and load voltage up to 60 V in a synchronized way. Digital bus
+interface is I2C/SMbus. The TSC1641 allows the assertion of several alerts
+regarding the voltage, current, power and temperature.
+
+Usage Notes
+-----------
+
+The TSC1641 driver requires the value of the external shunt resistor to
+correctly compute current and power measurements. The resistor value, in
+micro-ohms, should be provided either through the device tree property
+"shunt-resistor-micro-ohms" or via writable sysfs attribute "shunt_resistor".
+Please refer to the Documentation/devicetree/bindings/hwmon/st,tsc1641.yaml
+for bindings if the device tree is used.
+
+Supported range of shunt resistor values is from 100 uOhm to 655.35 mOhm, in
+10 uOhm steps.
+When selecting the value keep in mind device maximum DC power measurement is
+1600W. See datasheet p.22 for ST recommendations on selecting shunt value.
+
+If the shunt resistor value is not specified in the device tree, the driver
+initializes it to 1000 uOhm by default. Users may configure the correct shunt
+resistor value at runtime by writing to the "shunt_resistor" sysfs attribute.
+
+The driver only supports continuous operating mode.
+Measurement ranges:
+
+================ ===============================================================
+Current Bidirectional, dependent on shunt
+Bus voltage 0-60V
+Maximum DC power 1600W
+Temperature -40C to +125C
+================ ===============================================================
+
+Sysfs entries
+-------------
+
+==================== ===========================================================
+in0_input bus voltage (mV)
+in0_max bus voltage max alarm limit (mV)
+in0_max_alarm bus voltage max alarm limit exceeded
+in0_min bus voltage min alarm limit (mV)
+in0_min_alarm bus voltage min alarm limit exceeded
+
+curr1_input current measurement (mA)
+curr1_max current max alarm limit (mA)
+curr1_max_alarm current max alarm limit exceeded
+curr1_min current min alarm limit (mA)
+curr1_min_alarm current min alarm limit exceeded
+
+power1_input power measurement (uW)
+power1_max power max alarm limit (uW)
+power1_max_alarm power max alarm limit exceeded
+
+shunt_resistor shunt resistor value (uOhms)
+
+temp1_input temperature measurement (mdegC)
+temp1_max temperature max alarm limit (mdegC)
+temp1_max_alarm temperature max alarm limit exceeded
+
+update_interval data conversion time (1 - 33ms), longer conversion time
+ corresponds to higher effective resolution in bits
+==================== =========================================================== \ No newline at end of file
diff --git a/Documentation/hwmon/vexpress.rst b/Documentation/hwmon/vexpress.rst
index 8c861c8151ac..7fc99f75b3b1 100644
--- a/Documentation/hwmon/vexpress.rst
+++ b/Documentation/hwmon/vexpress.rst
@@ -27,7 +27,7 @@ Versatile Express platform (http://www.arm.com/versatileexpress/) is a
reference & prototyping system for ARM Ltd. processors. It can be set up
from a wide range of boards, each of them containing (apart of the main
chip/FPGA) a number of microcontrollers responsible for platform
-configuration and control. Theses microcontrollers can also monitor the
+configuration and control. These microcontrollers can also monitor the
board and its environment by a number of internal and external sensors,
providing information about power lines voltages and currents, board
temperature and power usage. Some of them also calculate consumed energy
diff --git a/Documentation/hwmon/via686a.rst b/Documentation/hwmon/via686a.rst
index 7ab9ddebcf79..8c52a9207bcb 100644
--- a/Documentation/hwmon/via686a.rst
+++ b/Documentation/hwmon/via686a.rst
@@ -58,7 +58,7 @@ representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum
-or maximum limit. Voltages are internally scalled, so each voltage channel
+or maximum limit. Voltages are internally scaled, so each voltage channel
has a different resolution and range.
If an alarm triggers, it will remain triggered until the hardware register
diff --git a/Documentation/hwmon/xdp710.rst b/Documentation/hwmon/xdp710.rst
new file mode 100644
index 000000000000..083891f27818
--- /dev/null
+++ b/Documentation/hwmon/xdp710.rst
@@ -0,0 +1,83 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver xdp710
+====================
+
+Supported chips:
+
+ * Infineon XDP710
+
+ Prefix: 'xdp710'
+
+ * Datasheet
+
+ Publicly available at the Infineon website : https://www.infineon.com/dgdl/Infineon-XDP710-001-DataSheet-v01_00-EN.pdf?fileId=8ac78c8c8412f8d301848a5316290b97
+
+Author:
+
+ Peter Yin <peteryin.openbmc@gmail.com>
+
+Description
+-----------
+
+This driver implements support for Infineon XDP710 Hot-Swap Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+Device supports direct and linear format for reading input voltage,
+output voltage, output current, input power and temperature.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_alarm**
+
+The driver provides the following attributes for output current:
+
+**curr1_input**
+
+**curr1_label**
+
+**curr1_alarm**
+
+**curr1_max**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power1_alarm**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
diff --git a/Documentation/hwmon/zl6100.rst b/Documentation/hwmon/zl6100.rst
index d42ed9d3ac69..1513c9d2d461 100644
--- a/Documentation/hwmon/zl6100.rst
+++ b/Documentation/hwmon/zl6100.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl2004-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl2004-datasheet
* Renesas / Intersil / Zilker Labs ZL2005
@@ -17,7 +17,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl2005-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl2005-datasheet
* Renesas / Intersil / Zilker Labs ZL2006
@@ -25,7 +25,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl2006-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl2006-datasheet
* Renesas / Intersil / Zilker Labs ZL2008
@@ -33,7 +33,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl2008-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl2008-datasheet
* Renesas / Intersil / Zilker Labs ZL2105
@@ -41,7 +41,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl2105-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl2105-datasheet
* Renesas / Intersil / Zilker Labs ZL2106
@@ -49,7 +49,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl2106-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl2106-datasheet
* Renesas / Intersil / Zilker Labs ZL6100
@@ -57,7 +57,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl6100-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl6100-datasheet
* Renesas / Intersil / Zilker Labs ZL6105
@@ -65,7 +65,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: https://www.renesas.com/us/en/document/dst/zl6105-datasheet.pdf
+ Datasheet: https://www.renesas.com/us/en/document/dst/zl6105-datasheet
* Renesas / Intersil / Zilker Labs ZL8802
diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst
index ab9e850e8fe0..c939a5bfc8d0 100644
--- a/Documentation/i2c/busses/i2c-i801.rst
+++ b/Documentation/i2c/busses/i2c-i801.rst
@@ -46,7 +46,12 @@ Supported adapters:
* Intel Emmitsburg (PCH)
* Intel Alder Lake (PCH)
* Intel Raptor Lake (PCH)
- * Intel Meteor Lake (SOC)
+ * Intel Meteor Lake (SOC and PCH)
+ * Intel Birch Stream (SOC)
+ * Intel Arrow Lake (SOC)
+ * Intel Panther Lake (SOC)
+ * Intel Wildcat Lake (SOC)
+ * Intel Diamond Rapids (SOC)
Datasheets: Publicly available at the Intel website
diff --git a/Documentation/i2c/busses/i2c-parport.rst b/Documentation/i2c/busses/i2c-parport.rst
index a9b4e8133700..4cbf45952d52 100644
--- a/Documentation/i2c/busses/i2c-parport.rst
+++ b/Documentation/i2c/busses/i2c-parport.rst
@@ -84,7 +84,7 @@ Remarks:
\|
must be 74HC05, they must be open collector output.
- - All resitors are 10k.
+ - All resistors are 10k.
- Pins 18-25 of the parallel port connected to GND.
- Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high.
The ADM1032 evaluation board uses D4-D7. Beware that the amount of
diff --git a/Documentation/i2c/busses/i2c-piix4.rst b/Documentation/i2c/busses/i2c-piix4.rst
index 07fe6f6f4b18..94e20b18c59a 100644
--- a/Documentation/i2c/busses/i2c-piix4.rst
+++ b/Documentation/i2c/busses/i2c-piix4.rst
@@ -109,3 +109,66 @@ which can easily get corrupted due to a state machine bug. These are mostly
Thinkpad laptops, but desktop systems may also be affected. We have no list
of all affected systems, so the only safe solution was to prevent access to
the SMBus on all IBM systems (detected using DMI data.)
+
+
+Description in the ACPI code
+----------------------------
+
+Device driver for the PIIX4 chip creates a separate I2C bus for each of its
+ports::
+
+ $ i2cdetect -l
+ ...
+ i2c-7 unknown SMBus PIIX4 adapter port 0 at 0b00 N/A
+ i2c-8 unknown SMBus PIIX4 adapter port 2 at 0b00 N/A
+ i2c-9 unknown SMBus PIIX4 adapter port 1 at 0b20 N/A
+ ...
+
+Therefore if you want to access one of these busses in the ACPI code, port
+subdevices are needed to be declared inside the PIIX device::
+
+ Scope (\_SB_.PCI0.SMBS)
+ {
+ Name (_ADR, 0x00140000)
+
+ Device (SMB0) {
+ Name (_ADR, 0)
+ }
+ Device (SMB1) {
+ Name (_ADR, 1)
+ }
+ Device (SMB2) {
+ Name (_ADR, 2)
+ }
+ }
+
+If this is not the case for your UEFI firmware and you don't have access to the
+source code, you can use ACPI SSDT Overlays to provide the missing parts. Just
+keep in mind that in this case you would need to load your extra SSDT table
+before the piix4 driver starts, i.e. you should provide SSDT via initrd or EFI
+variable methods and not via configfs.
+
+As an example of usage here is the ACPI snippet code that would assign jc42
+driver to the 0x1C device on the I2C bus created by the PIIX port 0::
+
+ Device (JC42) {
+ Name (_HID, "PRP0001")
+ Name (_DDN, "JC42 Temperature sensor")
+ Name (_CRS, ResourceTemplate () {
+ I2cSerialBusV2 (
+ 0x001c,
+ ControllerInitiated,
+ 100000,
+ AddressingMode7Bit,
+ "\\_SB.PCI0.SMBS.SMB0",
+ 0
+ )
+ })
+
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package () { "compatible", Package() { "jedec,jc-42.4-temp" } },
+ }
+ })
+ }
diff --git a/Documentation/i2c/fault-codes.rst b/Documentation/i2c/fault-codes.rst
index 80b14e718b52..b0864d1268bd 100644
--- a/Documentation/i2c/fault-codes.rst
+++ b/Documentation/i2c/fault-codes.rst
@@ -39,6 +39,10 @@ Also, codes returned by adapter probe methods follow rules which are
specific to their host bus (such as PCI, or the platform bus).
+EAFNOSUPPORT
+ Returned by I2C adapters not supporting 10 bit addresses when
+ they are requested to use such an address.
+
EAGAIN
Returned by I2C adapters when they lose arbitration in master
transmit mode: some other master was transmitting different
diff --git a/Documentation/i2c/gpio-fault-injection.rst b/Documentation/i2c/gpio-fault-injection.rst
index 9dca6ec7d266..91d23889abd5 100644
--- a/Documentation/i2c/gpio-fault-injection.rst
+++ b/Documentation/i2c/gpio-fault-injection.rst
@@ -93,7 +93,7 @@ bus arbitration against another master in a multi-master setup.
------------------
This file is write only and you need to write the duration of the arbitration
-intereference (in µs, maximum is 100ms). The calling process will then sleep
+interference (in µs, maximum is 100ms). The calling process will then sleep
and wait for the next bus clock. The process is interruptible, though.
Arbitration lost is achieved by waiting for SCL going down by the master under
diff --git a/Documentation/i2c/i2c-address-translators.rst b/Documentation/i2c/i2c-address-translators.rst
new file mode 100644
index 000000000000..6845c114e472
--- /dev/null
+++ b/Documentation/i2c/i2c-address-translators.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+I2C Address Translators
+=======================
+
+Author: Luca Ceresoli <luca@lucaceresoli.net>
+Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+
+Description
+-----------
+
+An I2C Address Translator (ATR) is a device with an I2C slave parent
+("upstream") port and N I2C master child ("downstream") ports, and
+forwards transactions from upstream to the appropriate downstream port
+with a modified slave address. The address used on the parent bus is
+called the "alias" and is (potentially) different from the physical
+slave address of the child bus. Address translation is done by the
+hardware.
+
+An ATR looks similar to an i2c-mux except:
+ - the address on the parent and child busses can be different
+ - there is normally no need to select the child port; the alias used on the
+ parent bus implies it
+
+The ATR functionality can be provided by a chip with many other features.
+The kernel i2c-atr provides a helper to implement an ATR within a driver.
+
+The ATR creates a new I2C "child" adapter on each child bus. Adding
+devices on the child bus ends up in invoking the driver code to select
+an available alias. Maintaining an appropriate pool of available aliases
+and picking one for each new device is up to the driver implementer. The
+ATR maintains a table of currently assigned alias and uses it to modify
+all I2C transactions directed to devices on the child buses.
+
+A typical example follows.
+
+Topology::
+
+ Slave X @ 0x10
+ .-----. |
+ .-----. | |---+---- B
+ | CPU |--A--| ATR |
+ `-----' | |---+---- C
+ `-----' |
+ Slave Y @ 0x10
+
+Alias table:
+
+A, B and C are three physical I2C busses, electrically independent from
+each other. The ATR receives the transactions initiated on bus A and
+propagates them on bus B or bus C or none depending on the device address
+in the transaction and based on the alias table.
+
+Alias table:
+
+.. table::
+
+ =============== =====
+ Client Alias
+ =============== =====
+ X (bus B, 0x10) 0x20
+ Y (bus C, 0x10) 0x30
+ =============== =====
+
+Transaction:
+
+ - Slave X driver requests a transaction (on adapter B), slave address 0x10
+ - ATR driver finds slave X is on bus B and has alias 0x20, rewrites
+ messages with address 0x20, forwards to adapter A
+ - Physical I2C transaction on bus A, slave address 0x20
+ - ATR chip detects transaction on address 0x20, finds it in table,
+ propagates transaction on bus B with address translated to 0x10,
+ keeps clock stretched on bus A waiting for reply
+ - Slave X chip (on bus B) detects transaction at its own physical
+ address 0x10 and replies normally
+ - ATR chip stops clock stretching and forwards reply on bus A,
+ with address translated back to 0x20
+ - ATR driver receives the reply, rewrites messages with address 0x10
+ as they were initially
+ - Slave X driver gets back the msgs[], with reply and address 0x10
+
+Usage:
+
+ 1. In the driver (typically in the probe function) add an ATR by
+ calling i2c_atr_new() passing attach/detach callbacks
+ 2. When the attach callback is called pick an appropriate alias,
+ configure it in the chip and return the chosen alias in the
+ alias_id parameter
+ 3. When the detach callback is called, deconfigure the alias from
+ the chip and put the alias back in the pool for later usage
+
+I2C ATR functions and data structures
+-------------------------------------
+
+.. kernel-doc:: include/linux/i2c-atr.h
diff --git a/Documentation/i2c/i2c_bus.svg b/Documentation/i2c/i2c_bus.svg
index 3170de976373..45801de4af7d 100644
--- a/Documentation/i2c/i2c_bus.svg
+++ b/Documentation/i2c/i2c_bus.svg
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<!-- Updated to inclusive terminology by Wolfram Sang -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
@@ -1120,7 +1121,7 @@
<rect
style="opacity:1;fill:#ffb9b9;fill-opacity:1;stroke:#f00000;stroke-width:2.8125;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4424-3-2-9-7"
- width="112.5"
+ width="134.5"
height="113.75008"
x="112.5"
y="471.11221"
@@ -1133,15 +1134,15 @@
y="521.46259"
id="text4349"><tspan
sodipodi:role="line"
- x="167.5354"
+ x="178.5354"
y="521.46259"
style="font-size:25px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle"
id="tspan1273">I2C</tspan><tspan
sodipodi:role="line"
- x="167.5354"
+ x="178.5354"
y="552.71259"
style="font-size:25px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle"
- id="tspan1285">Master</tspan></text>
+ id="tspan1285">Controller</tspan></text>
<rect
style="color:#000000;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;fill:#b9ffb9;fill-opacity:1;fill-rule:nonzero;stroke:#006400;stroke-width:2.8125;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
id="rect4424-3-2-9-7-3-3-5-3"
@@ -1171,7 +1172,7 @@
x="318.59131"
y="552.08752"
style="font-size:25.00000191px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle;stroke-width:1px"
- id="tspan1287">Slave</tspan></text>
+ id="tspan1287">Target</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.99968767;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 112.49995,677.36223 c 712.50005,0 712.50005,0 712.50005,0"
@@ -1233,7 +1234,7 @@
x="468.59131"
y="552.08746"
style="font-size:25.00000191px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle;stroke-width:1px"
- id="tspan1287-6">Slave</tspan></text>
+ id="tspan1287-6">Target</tspan></text>
<rect
style="color:#000000;clip-rule:nonzero;display:inline;overflow:visible;visibility:visible;opacity:1;isolation:auto;mix-blend-mode:normal;color-interpolation:sRGB;color-interpolation-filters:linearRGB;solid-color:#000000;solid-opacity:1;vector-effect:none;fill:#b9ffb9;fill-opacity:1;fill-rule:nonzero;stroke:#006400;stroke-width:2.8125;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;color-rendering:auto;image-rendering:auto;shape-rendering:auto;text-rendering:auto;enable-background:accumulate"
id="rect4424-3-2-9-7-3-3-5-3-1"
@@ -1258,7 +1259,7 @@
x="618.59131"
y="552.08746"
style="font-size:25.00000191px;line-height:1.25;font-family:sans-serif;text-align:center;text-anchor:middle;stroke-width:1px"
- id="tspan1287-9">Slave</tspan></text>
+ id="tspan1287-9">Target</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.99968743;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#DotM)"
d="m 150,583.61221 v 93.75"
diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst
index 6270f1fd7d4e..2b213d4ce89c 100644
--- a/Documentation/i2c/index.rst
+++ b/Documentation/i2c/index.rst
@@ -18,6 +18,7 @@ Introduction
i2c-topology
muxes/i2c-mux-gpio
i2c-sysfs
+ i2c-address-translators
Writing device drivers
======================
diff --git a/Documentation/i2c/slave-testunit-backend.rst b/Documentation/i2c/slave-testunit-backend.rst
index ecfc2abec32d..d752f433be07 100644
--- a/Documentation/i2c/slave-testunit-backend.rst
+++ b/Documentation/i2c/slave-testunit-backend.rst
@@ -16,24 +16,41 @@ Note that this is a device for testing and debugging. It should not be enabled
in a production build. And while there is some versioning and we try hard to
keep backward compatibility, there is no stable ABI guaranteed!
-Instantiating the device is regular. Example for bus 0, address 0x30:
+Instantiating the device is regular. Example for bus 0, address 0x30::
-# echo "slave-testunit 0x1030" > /sys/bus/i2c/devices/i2c-0/new_device
+ # echo "slave-testunit 0x1030" > /sys/bus/i2c/devices/i2c-0/new_device
-After that, you will have a write-only device listening. Reads will just return
-an 8-bit version number of the testunit. When writing, the device consists of 4
-8-bit registers and, except for some "partial" commands, all registers must be
-written to start a testcase, i.e. you usually write 4 bytes to the device. The
-registers are:
+Or using firmware nodes. Here is a devicetree example (note this is only a
+debug device, so there are no official DT bindings)::
-0x00 CMD - which test to trigger
-0x01 DATAL - configuration byte 1 for the test
-0x02 DATAH - configuration byte 2 for the test
-0x03 DELAY - delay in n * 10ms until test is started
+ &i2c0 {
+ ...
-Using 'i2cset' from the i2c-tools package, the generic command looks like:
+ testunit@30 {
+ compatible = "slave-testunit";
+ reg = <(0x30 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+ };
-# i2cset -y <bus_num> <testunit_address> <CMD> <DATAL> <DATAH> <DELAY> i
+After that, you will have the device listening. Reading will return a single
+byte. Its value is 0 if the testunit is idle, otherwise the command number of
+the currently running command.
+
+When writing, the device consists of 4 8-bit registers and, except for some
+"partial" commands, all registers must be written to start a testcase, i.e. you
+usually write 4 bytes to the device. The registers are:
+
+.. csv-table::
+ :header: "Offset", "Name", "Description"
+
+ 0x00, CMD, which test to trigger
+ 0x01, DATAL, configuration byte 1 for the test
+ 0x02, DATAH, configuration byte 2 for the test
+ 0x03, DELAY, delay in n * 10ms until test is started
+
+Using 'i2cset' from the i2c-tools package, the generic command looks like::
+
+ # i2cset -y <bus_num> <testunit_address> <CMD> <DATAL> <DATAH> <DELAY> i
DELAY is a generic parameter which will delay the execution of the test in CMD.
While a command is running (including the delay), new commands will not be
@@ -45,44 +62,174 @@ result in the transfer not being acknowledged.
Commands
--------
-0x00 NOOP (reserved for future use)
+0x00 NOOP
+~~~~~~~~~
+
+Reserved for future use.
+
+0x01 READ_BYTES
+~~~~~~~~~~~~~~~
+
+.. list-table::
+ :header-rows: 1
+
+ * - CMD
+ - DATAL
+ - DATAH
+ - DELAY
+
+ * - 0x01
+ - address to read data from (lower 7 bits, highest bit currently unused)
+ - number of bytes to read
+ - n * 10ms
+
+Also needs master mode. This is useful to test if your bus master driver is
+handling multi-master correctly. You can trigger the testunit to read bytes
+from another device on the bus. If the bus master under test also wants to
+access the bus at the same time, the bus will be busy. Example to read 128
+bytes from device 0x50 after 50ms of delay::
+
+ # i2cset -y 0 0x30 1 0x50 0x80 5 i
+
+0x02 SMBUS_HOST_NOTIFY
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. list-table::
+ :header-rows: 1
+
+ * - CMD
+ - DATAL
+ - DATAH
+ - DELAY
+
+ * - 0x02
+ - low byte of the status word to send
+ - high byte of the status word to send
+ - n * 10ms
+
+Also needs master mode. This test will send an SMBUS_HOST_NOTIFY message to the
+host. Note that the status word is currently ignored in the Linux Kernel.
+Example to send a notification with status word 0x6442 after 10ms::
+
+ # i2cset -y 0 0x30 2 0x42 0x64 1 i
+
+If the host controller supports HostNotify, this message with debug level
+should appear (Linux 6.11 and later)::
+
+ Detected HostNotify from address 0x30
+
+0x03 SMBUS_BLOCK_PROC_CALL
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. list-table::
+ :header-rows: 1
+
+ * - CMD
+ - DATAL
+ - DATAH
+ - DELAY
+
+ * - 0x03
+ - 0x01 (i.e. one further byte will be written)
+ - number of bytes to be sent back
+ - leave out, partial command!
+
+Partial command. This test will respond to a block process call as defined by
+the SMBus specification. The one data byte written specifies how many bytes
+will be sent back in the following read transfer. Note that in this read
+transfer, the testunit will prefix the length of the bytes to follow. So, if
+your host bus driver emulates SMBus calls like the majority does, it needs to
+support the I2C_M_RECV_LEN flag of an i2c_msg. This is a good testcase for it.
+The returned data consists of the length first, and then of an array of bytes
+from length-1 to 0. Here is an example which emulates
+i2c_smbus_block_process_call() using i2ctransfer (you need i2c-tools v4.2 or
+later)::
+
+ # i2ctransfer -y 0 w3@0x30 3 1 0x10 r?
+ 0x10 0x0f 0x0e 0x0d 0x0c 0x0b 0x0a 0x09 0x08 0x07 0x06 0x05 0x04 0x03 0x02 0x01 0x00
+
+0x04 GET_VERSION_WITH_REP_START
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. list-table::
+ :header-rows: 1
+
+ * - CMD
+ - DATAL
+ - DATAH
+ - DELAY
+
+ * - 0x04
+ - currently unused
+ - currently unused
+ - leave out, partial command!
+
+Partial command. After sending this command, the testunit will reply to a read
+message with a NUL terminated version string based on UTS_RELEASE. The first
+character is always a 'v' and the length of the version string is at maximum
+128 bytes. However, it will only respond if the read message is connected to
+the write message via repeated start. If your controller driver handles
+repeated start correctly, this will work::
+
+ # i2ctransfer -y 0 w3@0x30 4 0 0 r128
+ 0x76 0x36 0x2e 0x31 0x31 0x2e 0x30 0x2d 0x72 0x63 0x31 0x2d 0x30 0x30 0x30 0x30 ...
+
+If you have i2c-tools 4.4 or later, you can print out the data right away::
+
+ # i2ctransfer -y -b 0 w3@0x30 4 0 0 r128
+ v6.11.0-rc1-00009-gd37a1b4d3fd0
+
+STOP/START combinations between the two messages will *not* work because they
+are not equivalent to a REPEATED START. As an example, this returns just the
+default response::
+
+ # i2cset -y 0 0x30 4 0 0 i; i2cget -y 0 0x30
+ 0x00
+
+0x05 SMBUS_ALERT_REQUEST
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. list-table::
+ :header-rows: 1
+
+ * - CMD
+ - DATAL
+ - DATAH
+ - DELAY
+
+ * - 0x05
+ - response value (7 MSBs interpreted as I2C address)
+ - currently unused
+ - n * 10ms
+
+This test raises an interrupt via the SMBAlert pin which the host controller
+must handle. The pin must be connected to the testunit as a GPIO. GPIO access
+is not allowed to sleep. Currently, this can only be described using firmware
+nodes. So, for devicetree, you would add something like this to the testunit
+node::
-0x01 READ_BYTES (also needs master mode)
- DATAL - address to read data from (lower 7 bits, highest bit currently unused)
- DATAH - number of bytes to read
+ gpios = <&gpio1 24 GPIO_ACTIVE_LOW>;
-This is useful to test if your bus master driver is handling multi-master
-correctly. You can trigger the testunit to read bytes from another device on
-the bus. If the bus master under test also wants to access the bus at the same
-time, the bus will be busy. Example to read 128 bytes from device 0x50 after
-50ms of delay:
+The following command will trigger the alert with a response of 0xc9 after 1
+second of delay::
-# i2cset -y 0 0x30 0x01 0x50 0x80 0x05 i
+ # i2cset -y 0 0x30 5 0xc9 0x00 100 i
-0x02 SMBUS_HOST_NOTIFY (also needs master mode)
- DATAL - low byte of the status word to send
- DATAH - high byte of the status word to send
+If the host controller supports SMBusAlert, this message with debug level
+should appear::
-This test will send an SMBUS_HOST_NOTIFY message to the host. Note that the
-status word is currently ignored in the Linux Kernel. Example to send a
-notification after 10ms:
+ smbus_alert 0-000c: SMBALERT# from dev 0x64, flag 1
-# i2cset -y 0 0x30 0x02 0x42 0x64 0x01 i
+This message may appear more than once because the testunit is software not
+hardware and, thus, may not be able to react to the response of the host fast
+enough. The interrupt count should increase only by one, though::
-0x03 SMBUS_BLOCK_PROC_CALL (partial command)
- DATAL - must be '1', i.e. one further byte will be written
- DATAH - number of bytes to be sent back
- DELAY - not applicable, partial command!
+ # cat /proc/interrupts | grep smbus_alert
+ 93: 1 gpio-rcar 26 Edge smbus_alert
-This test will respond to a block process call as defined by the SMBus
-specification. The one data byte written specifies how many bytes will be sent
-back in the following read transfer. Note that in this read transfer, the
-testunit will prefix the length of the bytes to follow. So, if your host bus
-driver emulates SMBus calls like the majority does, it needs to support the
-I2C_M_RECV_LEN flag of an i2c_msg. This is a good testcase for it. The returned
-data consists of the length first, and then of an array of bytes from length-1
-to 0. Here is an example which emulates i2c_smbus_block_process_call() using
-i2ctransfer (you need i2c-tools v4.2 or later):
+If the host does not respond to the alert within 1 second, the test will be
+aborted and the testunit will report an error.
-# i2ctransfer -y 0 w3@0x30 0x03 0x01 0x10 r?
-0x10 0x0f 0x0e 0x0d 0x0c 0x0b 0x0a 0x09 0x08 0x07 0x06 0x05 0x04 0x03 0x02 0x01 0x00
+For this test, the testunit will shortly drop its assigned address and listen
+on the SMBus Alert Response Address (0x0c). It will reassign its original
+address afterwards.
diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst
index 4942c4cad4ad..adc87456c99d 100644
--- a/Documentation/i2c/smbus-protocol.rst
+++ b/Documentation/i2c/smbus-protocol.rst
@@ -238,7 +238,7 @@ This is implemented in the following way in the Linux kernel:
* I2C bus drivers trigger SMBus Host Notify by a call to
i2c_handle_smbus_host_notify().
* I2C drivers for devices which can trigger SMBus Host Notify will have
- client->irq assigned to a Host Notify IRQ if noone else specified an other.
+ client->irq assigned to a Host Notify IRQ if no one else specified another.
There is currently no way to retrieve the data parameter from the client.
diff --git a/Documentation/i2c/summary.rst b/Documentation/i2c/summary.rst
index 786c618ba3be..579a1c7df200 100644
--- a/Documentation/i2c/summary.rst
+++ b/Documentation/i2c/summary.rst
@@ -3,29 +3,27 @@ Introduction to I2C and SMBus
=============================
I²C (pronounce: I squared C and written I2C in the kernel documentation) is
-a protocol developed by Philips. It is a slow two-wire protocol (variable
-speed, up to 400 kHz), with a high speed extension (3.4 MHz). It provides
+a protocol developed by Philips. It is a two-wire protocol with variable
+speed (typically up to 400 kHz, high speed modes up to 5 MHz). It provides
an inexpensive bus for connecting many types of devices with infrequent or
-low bandwidth communications needs. I2C is widely used with embedded
-systems. Some systems use variants that don't meet branding requirements,
+low bandwidth communications needs. I2C is widely used with embedded
+systems. Some systems use variants that don't meet branding requirements,
and so are not advertised as being I2C but come under different names,
e.g. TWI (Two Wire Interface), IIC.
-The latest official I2C specification is the `"I2C-bus specification and user
-manual" (UM10204) <https://www.nxp.com/webapp/Download?colCode=UM10204>`_
-published by NXP Semiconductors. However, you need to log-in to the site to
-access the PDF. An older version of the specification (revision 6) is archived
-`here <https://web.archive.org/web/20210813122132/https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_.
+The latest official I2C specification is the `"I²C-bus specification and user
+manual" (UM10204) <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_
+published by NXP Semiconductors, version 7 as of this writing.
SMBus (System Management Bus) is based on the I2C protocol, and is mostly
-a subset of I2C protocols and signaling. Many I2C devices will work on an
+a subset of I2C protocols and signaling. Many I2C devices will work on an
SMBus, but some SMBus protocols add semantics beyond what is required to
-achieve I2C branding. Modern PC mainboards rely on SMBus. The most common
+achieve I2C branding. Modern PC mainboards rely on SMBus. The most common
devices connected through SMBus are RAM modules configured using I2C EEPROMs,
and hardware monitoring chips.
Because the SMBus is mostly a subset of the generalized I2C bus, we can
-use its protocols on many I2C systems. However, there are systems that don't
+use its protocols on many I2C systems. However, there are systems that don't
meet both SMBus and I2C electrical constraints; and others which can't
implement all the common SMBus protocol semantics or messages.
@@ -33,29 +31,52 @@ implement all the common SMBus protocol semantics or messages.
Terminology
===========
-Using the terminology from the official documentation, the I2C bus connects
-one or more *master* chips and one or more *slave* chips.
+The I2C bus connects one or more controller chips and one or more target chips.
.. kernel-figure:: i2c_bus.svg
- :alt: Simple I2C bus with one master and 3 slaves
+ :alt: Simple I2C bus with one controller and 3 targets
Simple I2C bus
-A **master** chip is a node that starts communications with slaves. In the
-Linux kernel implementation it is called an **adapter** or bus. Adapter
-drivers are in the ``drivers/i2c/busses/`` subdirectory.
+A **controller** chip is a node that starts communications with targets. In the
+Linux kernel implementation it is also called an "adapter" or "bus". Controller
+drivers are usually in the ``drivers/i2c/busses/`` subdirectory.
-An **algorithm** contains general code that can be used to implement a
-whole class of I2C adapters. Each specific adapter driver either depends on
-an algorithm driver in the ``drivers/i2c/algos/`` subdirectory, or includes
-its own implementation.
+An **algorithm** contains general code that can be used to implement a whole
+class of I2C controllers. Each specific controller driver either depends on an
+algorithm driver in the ``drivers/i2c/algos/`` subdirectory, or includes its
+own implementation.
-A **slave** chip is a node that responds to communications when addressed
-by the master. In Linux it is called a **client**. Client drivers are kept
-in a directory specific to the feature they provide, for example
-``drivers/media/gpio/`` for GPIO expanders and ``drivers/media/i2c/`` for
+A **target** chip is a node that responds to communications when addressed by a
+controller. In the Linux kernel implementation it is also called a "client".
+While targets are usually separate external chips, Linux can also act as a
+target (needs hardware support) and respond to another controller on the bus.
+This is then called a **local target**. In contrast, an external chip is called
+a **remote target**.
+
+Target drivers are kept in a directory specific to the feature they provide,
+for example ``drivers/gpio/`` for GPIO expanders and ``drivers/media/i2c/`` for
video-related chips.
-For the example configuration in figure, you will need a driver for your
-I2C adapter, and drivers for your I2C devices (usually one driver for each
-device).
+For the example configuration in the figure above, you will need one driver for
+the I2C controller, and drivers for your I2C targets. Usually one driver for
+each target.
+
+Synonyms
+--------
+
+As mentioned above, the Linux I2C implementation historically uses the terms
+"adapter" for controller and "client" for target. A number of data structures
+have these synonyms in their name. So, when discussing implementation details,
+you should be aware of these terms as well. The official wording is preferred,
+though.
+
+Outdated terminology
+--------------------
+
+In earlier I2C specifications, controller was named "master" and target was
+named "slave". These terms have been obsoleted with v7 of the specification and
+their use is also discouraged by the Linux Kernel Code of Conduct. You may
+still find them in references to documentation which has not been updated. The
+general attitude, however, is to use the inclusive terms: controller and
+target. Work to replace the old terminology in the Linux Kernel is on-going.
diff --git a/Documentation/i2c/writing-clients.rst b/Documentation/i2c/writing-clients.rst
index b7d3ae7458f8..121e618e72ec 100644
--- a/Documentation/i2c/writing-clients.rst
+++ b/Documentation/i2c/writing-clients.rst
@@ -31,12 +31,11 @@ driver model device node, and its I2C address.
::
- static struct i2c_device_id foo_idtable[] = {
+ static const struct i2c_device_id foo_idtable[] = {
{ "foo", my_id_for_foo },
{ "bar", my_id_for_bar },
{ }
};
-
MODULE_DEVICE_TABLE(i2c, foo_idtable);
static struct i2c_driver foo_driver = {
@@ -46,12 +45,8 @@ driver model device node, and its I2C address.
},
.id_table = foo_idtable,
- .probe_new = foo_probe,
+ .probe = foo_probe,
.remove = foo_remove,
- /* if device autodetection is needed: */
- .class = I2C_CLASS_SOMETHING,
- .detect = foo_detect,
- .address_list = normal_i2c,
.shutdown = foo_shutdown, /* optional */
.command = foo_command, /* optional, deprecated */
@@ -203,27 +198,8 @@ reference for later use.
Device Detection
----------------
-Sometimes you do not know in advance which I2C devices are connected to
-a given I2C bus. This is for example the case of hardware monitoring
-devices on a PC's SMBus. In that case, you may want to let your driver
-detect supported devices automatically. This is how the legacy model
-was working, and is now available as an extension to the standard
-driver model.
-
-You simply have to define a detect callback which will attempt to
-identify supported devices (returning 0 for supported ones and -ENODEV
-for unsupported ones), a list of addresses to probe, and a device type
-(or class) so that only I2C buses which may have that type of device
-connected (and not otherwise enumerated) will be probed. For example,
-a driver for a hardware monitoring chip for which auto-detection is
-needed would set its class to I2C_CLASS_HWMON, and only I2C adapters
-with a class including I2C_CLASS_HWMON would be probed by this driver.
-Note that the absence of matching classes does not prevent the use of
-a device of that type on the given I2C adapter. All it prevents is
-auto-detection; explicit instantiation of devices is still possible.
-
-Note that this mechanism is purely optional and not suitable for all
-devices. You need some reliable way to identify the supported devices
+The device detection mechanism comes with a number of disadvantages.
+You need some reliable way to identify the supported devices
(typically using device-specific, dedicated identification registers),
otherwise misdetections are likely to occur and things can get wrong
quickly. Keep in mind that the I2C protocol doesn't include any
@@ -231,9 +207,8 @@ standard way to detect the presence of a chip at a given address, let
alone a standard way to identify devices. Even worse is the lack of
semantics associated to bus transfers, which means that the same
transfer can be seen as a read operation by a chip and as a write
-operation by another chip. For these reasons, explicit device
-instantiation should always be preferred to auto-detection where
-possible.
+operation by another chip. For these reasons, device detection is
+considered a legacy mechanism and shouldn't be used in new code.
Device Deletion
diff --git a/Documentation/ia64/aliasing.rst b/Documentation/ia64/aliasing.rst
deleted file mode 100644
index a08b36aba015..000000000000
--- a/Documentation/ia64/aliasing.rst
+++ /dev/null
@@ -1,246 +0,0 @@
-==================================
-Memory Attribute Aliasing on IA-64
-==================================
-
-Bjorn Helgaas <bjorn.helgaas@hp.com>
-
-May 4, 2006
-
-
-Memory Attributes
-=================
-
- Itanium supports several attributes for virtual memory references.
- The attribute is part of the virtual translation, i.e., it is
- contained in the TLB entry. The ones of most interest to the Linux
- kernel are:
-
- == ======================
- WB Write-back (cacheable)
- UC Uncacheable
- WC Write-coalescing
- == ======================
-
- System memory typically uses the WB attribute. The UC attribute is
- used for memory-mapped I/O devices. The WC attribute is uncacheable
- like UC is, but writes may be delayed and combined to increase
- performance for things like frame buffers.
-
- The Itanium architecture requires that we avoid accessing the same
- page with both a cacheable mapping and an uncacheable mapping[1].
-
- The design of the chipset determines which attributes are supported
- on which regions of the address space. For example, some chipsets
- support either WB or UC access to main memory, while others support
- only WB access.
-
-Memory Map
-==========
-
- Platform firmware describes the physical memory map and the
- supported attributes for each region. At boot-time, the kernel uses
- the EFI GetMemoryMap() interface. ACPI can also describe memory
- devices and the attributes they support, but Linux/ia64 currently
- doesn't use this information.
-
- The kernel uses the efi_memmap table returned from GetMemoryMap() to
- learn the attributes supported by each region of physical address
- space. Unfortunately, this table does not completely describe the
- address space because some machines omit some or all of the MMIO
- regions from the map.
-
- The kernel maintains another table, kern_memmap, which describes the
- memory Linux is actually using and the attribute for each region.
- This contains only system memory; it does not contain MMIO space.
-
- The kern_memmap table typically contains only a subset of the system
- memory described by the efi_memmap. Linux/ia64 can't use all memory
- in the system because of constraints imposed by the identity mapping
- scheme.
-
- The efi_memmap table is preserved unmodified because the original
- boot-time information is required for kexec.
-
-Kernel Identify Mappings
-========================
-
- Linux/ia64 identity mappings are done with large pages, currently
- either 16MB or 64MB, referred to as "granules." Cacheable mappings
- are speculative[2], so the processor can read any location in the
- page at any time, independent of the programmer's intentions. This
- means that to avoid attribute aliasing, Linux can create a cacheable
- identity mapping only when the entire granule supports cacheable
- access.
-
- Therefore, kern_memmap contains only full granule-sized regions that
- can referenced safely by an identity mapping.
-
- Uncacheable mappings are not speculative, so the processor will
- generate UC accesses only to locations explicitly referenced by
- software. This allows UC identity mappings to cover granules that
- are only partially populated, or populated with a combination of UC
- and WB regions.
-
-User Mappings
-=============
-
- User mappings are typically done with 16K or 64K pages. The smaller
- page size allows more flexibility because only 16K or 64K has to be
- homogeneous with respect to memory attributes.
-
-Potential Attribute Aliasing Cases
-==================================
-
- There are several ways the kernel creates new mappings:
-
-mmap of /dev/mem
-----------------
-
- This uses remap_pfn_range(), which creates user mappings. These
- mappings may be either WB or UC. If the region being mapped
- happens to be in kern_memmap, meaning that it may also be mapped
- by a kernel identity mapping, the user mapping must use the same
- attribute as the kernel mapping.
-
- If the region is not in kern_memmap, the user mapping should use
- an attribute reported as being supported in the EFI memory map.
-
- Since the EFI memory map does not describe MMIO on some
- machines, this should use an uncacheable mapping as a fallback.
-
-mmap of /sys/class/pci_bus/.../legacy_mem
------------------------------------------
-
- This is very similar to mmap of /dev/mem, except that legacy_mem
- only allows mmap of the one megabyte "legacy MMIO" area for a
- specific PCI bus. Typically this is the first megabyte of
- physical address space, but it may be different on machines with
- several VGA devices.
-
- "X" uses this to access VGA frame buffers. Using legacy_mem
- rather than /dev/mem allows multiple instances of X to talk to
- different VGA cards.
-
- The /dev/mem mmap constraints apply.
-
-mmap of /proc/bus/pci/.../??.?
-------------------------------
-
- This is an MMIO mmap of PCI functions, which additionally may or
- may not be requested as using the WC attribute.
-
- If WC is requested, and the region in kern_memmap is either WC
- or UC, and the EFI memory map designates the region as WC, then
- the WC mapping is allowed.
-
- Otherwise, the user mapping must use the same attribute as the
- kernel mapping.
-
-read/write of /dev/mem
-----------------------
-
- This uses copy_from_user(), which implicitly uses a kernel
- identity mapping. This is obviously safe for things in
- kern_memmap.
-
- There may be corner cases of things that are not in kern_memmap,
- but could be accessed this way. For example, registers in MMIO
- space are not in kern_memmap, but could be accessed with a UC
- mapping. This would not cause attribute aliasing. But
- registers typically can be accessed only with four-byte or
- eight-byte accesses, and the copy_from_user() path doesn't allow
- any control over the access size, so this would be dangerous.
-
-ioremap()
----------
-
- This returns a mapping for use inside the kernel.
-
- If the region is in kern_memmap, we should use the attribute
- specified there.
-
- If the EFI memory map reports that the entire granule supports
- WB, we should use that (granules that are partially reserved
- or occupied by firmware do not appear in kern_memmap).
-
- If the granule contains non-WB memory, but we can cover the
- region safely with kernel page table mappings, we can use
- ioremap_page_range() as most other architectures do.
-
- Failing all of the above, we have to fall back to a UC mapping.
-
-Past Problem Cases
-==================
-
-mmap of various MMIO regions from /dev/mem by "X" on Intel platforms
---------------------------------------------------------------------
-
- The EFI memory map may not report these MMIO regions.
-
- These must be allowed so that X will work. This means that
- when the EFI memory map is incomplete, every /dev/mem mmap must
- succeed. It may create either WB or UC user mappings, depending
- on whether the region is in kern_memmap or the EFI memory map.
-
-mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
-----------------------------------------------------------------------
-
- The EFI memory map reports the following attributes:
-
- =============== ======= ==================
- 0x00000-0x9FFFF WB only
- 0xA0000-0xBFFFF UC only (VGA frame buffer)
- 0xC0000-0xFFFFF WB only
- =============== ======= ==================
-
- This mmap is done with user pages, not kernel identity mappings,
- so it is safe to use WB mappings.
-
- The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
- which uses a granule-sized UC mapping. This granule will cover some
- WB-only memory, but since UC is non-speculative, the processor will
- never generate an uncacheable reference to the WB-only areas unless
- the driver explicitly touches them.
-
-mmap of 0x0-0xFFFFF legacy_mem by "X"
--------------------------------------
-
- If the EFI memory map reports that the entire range supports the
- same attributes, we can allow the mmap (and we will prefer WB if
- supported, as is the case with HP sx[12]000 machines with VGA
- disabled).
-
- If EFI reports the range as partly WB and partly UC (as on sx[12]000
- machines with VGA enabled), we must fail the mmap because there's no
- safe attribute to use.
-
- If EFI reports some of the range but not all (as on Intel firmware
- that doesn't report the VGA frame buffer at all), we should fail the
- mmap and force the user to map just the specific region of interest.
-
-mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
-------------------------------------------------------------------------
-
- The EFI memory map reports the following attributes::
-
- 0x00000-0xFFFFF WB only (no VGA MMIO hole)
-
- This is a special case of the previous case, and the mmap should
- fail for the same reason as above.
-
-read of /sys/devices/.../rom
-----------------------------
-
- For VGA devices, this may cause an ioremap() of 0xC0000. This
- used to be done with a UC mapping, because the VGA frame buffer
- at 0xA0000 prevents use of a WB granule. The UC mapping causes
- an MCA on HP sx[12]000 chipsets.
-
- We should use WB page table mappings to avoid covering the VGA
- frame buffer.
-
-Notes
-=====
-
- [1] SDM rev 2.2, vol 2, sec 4.4.1.
- [2] SDM rev 2.2, vol 2, sec 4.4.6.
diff --git a/Documentation/ia64/efirtc.rst b/Documentation/ia64/efirtc.rst
deleted file mode 100644
index fd8328408301..000000000000
--- a/Documentation/ia64/efirtc.rst
+++ /dev/null
@@ -1,144 +0,0 @@
-==========================
-EFI Real Time Clock driver
-==========================
-
-S. Eranian <eranian@hpl.hp.com>
-
-March 2000
-
-1. Introduction
-===============
-
-This document describes the efirtc.c driver has provided for
-the IA-64 platform.
-
-The purpose of this driver is to supply an API for kernel and user applications
-to get access to the Time Service offered by EFI version 0.92.
-
-EFI provides 4 calls one can make once the OS is booted: GetTime(),
-SetTime(), GetWakeupTime(), SetWakeupTime() which are all supported by this
-driver. We describe those calls as well the design of the driver in the
-following sections.
-
-2. Design Decisions
-===================
-
-The original ideas was to provide a very simple driver to get access to,
-at first, the time of day service. This is required in order to access, in a
-portable way, the CMOS clock. A program like /sbin/hwclock uses such a clock
-to initialize the system view of the time during boot.
-
-Because we wanted to minimize the impact on existing user-level apps using
-the CMOS clock, we decided to expose an API that was very similar to the one
-used today with the legacy RTC driver (driver/char/rtc.c). However, because
-EFI provides a simpler services, not all ioctl() are available. Also
-new ioctl()s have been introduced for things that EFI provides but not the
-legacy.
-
-EFI uses a slightly different way of representing the time, noticeably
-the reference date is different. Year is the using the full 4-digit format.
-The Epoch is January 1st 1998. For backward compatibility reasons we don't
-expose this new way of representing time. Instead we use something very
-similar to the struct tm, i.e. struct rtc_time, as used by hwclock.
-One of the reasons for doing it this way is to allow for EFI to still evolve
-without necessarily impacting any of the user applications. The decoupling
-enables flexibility and permits writing wrapper code is ncase things change.
-
-The driver exposes two interfaces, one via the device file and a set of
-ioctl()s. The other is read-only via the /proc filesystem.
-
-As of today we don't offer a /proc/sys interface.
-
-To allow for a uniform interface between the legacy RTC and EFI time service,
-we have created the include/linux/rtc.h header file to contain only the
-"public" API of the two drivers. The specifics of the legacy RTC are still
-in include/linux/mc146818rtc.h.
-
-
-3. Time of day service
-======================
-
-The part of the driver gives access to the time of day service of EFI.
-Two ioctl()s, compatible with the legacy RTC calls:
-
- Read the CMOS clock::
-
- ioctl(d, RTC_RD_TIME, &rtc);
-
- Write the CMOS clock::
-
- ioctl(d, RTC_SET_TIME, &rtc);
-
-The rtc is a pointer to a data structure defined in rtc.h which is close
-to a struct tm::
-
- struct rtc_time {
- int tm_sec;
- int tm_min;
- int tm_hour;
- int tm_mday;
- int tm_mon;
- int tm_year;
- int tm_wday;
- int tm_yday;
- int tm_isdst;
- };
-
-The driver takes care of converting back an forth between the EFI time and
-this format.
-
-Those two ioctl()s can be exercised with the hwclock command:
-
-For reading::
-
- # /sbin/hwclock --show
- Mon Mar 6 15:32:32 2000 -0.910248 seconds
-
-For setting::
-
- # /sbin/hwclock --systohc
-
-Root privileges are required to be able to set the time of day.
-
-4. Wakeup Alarm service
-=======================
-
-EFI provides an API by which one can program when a machine should wakeup,
-i.e. reboot. This is very different from the alarm provided by the legacy
-RTC which is some kind of interval timer alarm. For this reason we don't use
-the same ioctl()s to get access to the service. Instead we have
-introduced 2 news ioctl()s to the interface of an RTC.
-
-We have added 2 new ioctl()s that are specific to the EFI driver:
-
- Read the current state of the alarm::
-
- ioctl(d, RTC_WKALM_RD, &wkt)
-
- Set the alarm or change its status::
-
- ioctl(d, RTC_WKALM_SET, &wkt)
-
-The wkt structure encapsulates a struct rtc_time + 2 extra fields to get
-status information::
-
- struct rtc_wkalrm {
-
- unsigned char enabled; /* =1 if alarm is enabled */
- unsigned char pending; /* =1 if alarm is pending */
-
- struct rtc_time time;
- }
-
-As of today, none of the existing user-level apps supports this feature.
-However writing such a program should be hard by simply using those two
-ioctl().
-
-Root privileges are required to be able to set the alarm.
-
-5. References
-=============
-
-Checkout the following Web site for more information on EFI:
-
-http://developer.intel.com/technology/efi/
diff --git a/Documentation/ia64/err_inject.rst b/Documentation/ia64/err_inject.rst
deleted file mode 100644
index 900f71e93a29..000000000000
--- a/Documentation/ia64/err_inject.rst
+++ /dev/null
@@ -1,1067 +0,0 @@
-========================================
-IPF Machine Check (MC) error inject tool
-========================================
-
-IPF Machine Check (MC) error inject tool is used to inject MC
-errors from Linux. The tool is a test bed for IPF MC work flow including
-hardware correctable error handling, OS recoverable error handling, MC
-event logging, etc.
-
-The tool includes two parts: a kernel driver and a user application
-sample. The driver provides interface to PAL to inject error
-and query error injection capabilities. The driver code is in
-arch/ia64/kernel/err_inject.c. The application sample (shown below)
-provides a combination of various errors and calls the driver's interface
-(sysfs interface) to inject errors or query error injection capabilities.
-
-The tool can be used to test Intel IPF machine MC handling capabilities.
-It's especially useful for people who can not access hardware MC injection
-tool to inject error. It's also very useful to integrate with other
-software test suits to do stressful testing on IPF.
-
-Below is a sample application as part of the whole tool. The sample
-can be used as a working test tool. Or it can be expanded to include
-more features. It also can be a integrated into a library or other user
-application to have more thorough test.
-
-The sample application takes err.conf as error configuration input. GCC
-compiles the code. After you install err_inject driver, you can run
-this sample application to inject errors.
-
-Errata: Itanium 2 Processors Specification Update lists some errata against
-the pal_mc_error_inject PAL procedure. The following err.conf has been tested
-on latest Montecito PAL.
-
-err.conf::
-
- #This is configuration file for err_inject_tool.
- #The format of the each line is:
- #cpu, loop, interval, err_type_info, err_struct_info, err_data_buffer
- #where
- # cpu: logical cpu number the error will be inject in.
- # loop: times the error will be injected.
- # interval: In second. every so often one error is injected.
- # err_type_info, err_struct_info: PAL parameters.
- #
- #Note: All values are hex w/o or w/ 0x prefix.
-
-
- #On cpu2, inject only total 0x10 errors, interval 5 seconds
- #corrected, data cache, hier-2, physical addr(assigned by tool code).
- #working on Montecito latest PAL.
- 2, 10, 5, 4101, 95
-
- #On cpu4, inject and consume total 0x10 errors, interval 5 seconds
- #corrected, data cache, hier-2, physical addr(assigned by tool code).
- #working on Montecito latest PAL.
- 4, 10, 5, 4109, 95
-
- #On cpu15, inject and consume total 0x10 errors, interval 5 seconds
- #recoverable, DTR0, hier-2.
- #working on Montecito latest PAL.
- 0xf, 0x10, 5, 4249, 15
-
-The sample application source code:
-
-err_injection_tool.c::
-
- /*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
- * NON INFRINGEMENT. See the GNU General Public License for more
- * details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- * Copyright (C) 2006 Intel Co
- * Fenghua Yu <fenghua.yu@intel.com>
- *
- */
- #include <sys/types.h>
- #include <sys/stat.h>
- #include <fcntl.h>
- #include <stdio.h>
- #include <sched.h>
- #include <unistd.h>
- #include <stdlib.h>
- #include <stdarg.h>
- #include <string.h>
- #include <errno.h>
- #include <time.h>
- #include <sys/ipc.h>
- #include <sys/sem.h>
- #include <sys/wait.h>
- #include <sys/mman.h>
- #include <sys/shm.h>
-
- #define MAX_FN_SIZE 256
- #define MAX_BUF_SIZE 256
- #define DATA_BUF_SIZE 256
- #define NR_CPUS 512
- #define MAX_TASK_NUM 2048
- #define MIN_INTERVAL 5 // seconds
- #define ERR_DATA_BUFFER_SIZE 3 // Three 8-byte.
- #define PARA_FIELD_NUM 5
- #define MASK_SIZE (NR_CPUS/64)
- #define PATH_FORMAT "/sys/devices/system/cpu/cpu%d/err_inject/"
-
- int sched_setaffinity(pid_t pid, unsigned int len, unsigned long *mask);
-
- int verbose;
- #define vbprintf if (verbose) printf
-
- int log_info(int cpu, const char *fmt, ...)
- {
- FILE *log;
- char fn[MAX_FN_SIZE];
- char buf[MAX_BUF_SIZE];
- va_list args;
-
- sprintf(fn, "%d.log", cpu);
- log=fopen(fn, "a+");
- if (log==NULL) {
- perror("Error open:");
- return -1;
- }
-
- va_start(args, fmt);
- vprintf(fmt, args);
- memset(buf, 0, MAX_BUF_SIZE);
- vsprintf(buf, fmt, args);
- va_end(args);
-
- fwrite(buf, sizeof(buf), 1, log);
- fclose(log);
-
- return 0;
- }
-
- typedef unsigned long u64;
- typedef unsigned int u32;
-
- typedef union err_type_info_u {
- struct {
- u64 mode : 3, /* 0-2 */
- err_inj : 3, /* 3-5 */
- err_sev : 2, /* 6-7 */
- err_struct : 5, /* 8-12 */
- struct_hier : 3, /* 13-15 */
- reserved : 48; /* 16-63 */
- } err_type_info_u;
- u64 err_type_info;
- } err_type_info_t;
-
- typedef union err_struct_info_u {
- struct {
- u64 siv : 1, /* 0 */
- c_t : 2, /* 1-2 */
- cl_p : 3, /* 3-5 */
- cl_id : 3, /* 6-8 */
- cl_dp : 1, /* 9 */
- reserved1 : 22, /* 10-31 */
- tiv : 1, /* 32 */
- trigger : 4, /* 33-36 */
- trigger_pl : 3, /* 37-39 */
- reserved2 : 24; /* 40-63 */
- } err_struct_info_cache;
- struct {
- u64 siv : 1, /* 0 */
- tt : 2, /* 1-2 */
- tc_tr : 2, /* 3-4 */
- tr_slot : 8, /* 5-12 */
- reserved1 : 19, /* 13-31 */
- tiv : 1, /* 32 */
- trigger : 4, /* 33-36 */
- trigger_pl : 3, /* 37-39 */
- reserved2 : 24; /* 40-63 */
- } err_struct_info_tlb;
- struct {
- u64 siv : 1, /* 0 */
- regfile_id : 4, /* 1-4 */
- reg_num : 7, /* 5-11 */
- reserved1 : 20, /* 12-31 */
- tiv : 1, /* 32 */
- trigger : 4, /* 33-36 */
- trigger_pl : 3, /* 37-39 */
- reserved2 : 24; /* 40-63 */
- } err_struct_info_register;
- struct {
- u64 reserved;
- } err_struct_info_bus_processor_interconnect;
- u64 err_struct_info;
- } err_struct_info_t;
-
- typedef union err_data_buffer_u {
- struct {
- u64 trigger_addr; /* 0-63 */
- u64 inj_addr; /* 64-127 */
- u64 way : 5, /* 128-132 */
- index : 20, /* 133-152 */
- : 39; /* 153-191 */
- } err_data_buffer_cache;
- struct {
- u64 trigger_addr; /* 0-63 */
- u64 inj_addr; /* 64-127 */
- u64 way : 5, /* 128-132 */
- index : 20, /* 133-152 */
- reserved : 39; /* 153-191 */
- } err_data_buffer_tlb;
- struct {
- u64 trigger_addr; /* 0-63 */
- } err_data_buffer_register;
- struct {
- u64 reserved; /* 0-63 */
- } err_data_buffer_bus_processor_interconnect;
- u64 err_data_buffer[ERR_DATA_BUFFER_SIZE];
- } err_data_buffer_t;
-
- typedef union capabilities_u {
- struct {
- u64 i : 1,
- d : 1,
- rv : 1,
- tag : 1,
- data : 1,
- mesi : 1,
- dp : 1,
- reserved1 : 3,
- pa : 1,
- va : 1,
- wi : 1,
- reserved2 : 20,
- trigger : 1,
- trigger_pl : 1,
- reserved3 : 30;
- } capabilities_cache;
- struct {
- u64 d : 1,
- i : 1,
- rv : 1,
- tc : 1,
- tr : 1,
- reserved1 : 27,
- trigger : 1,
- trigger_pl : 1,
- reserved2 : 30;
- } capabilities_tlb;
- struct {
- u64 gr_b0 : 1,
- gr_b1 : 1,
- fr : 1,
- br : 1,
- pr : 1,
- ar : 1,
- cr : 1,
- rr : 1,
- pkr : 1,
- dbr : 1,
- ibr : 1,
- pmc : 1,
- pmd : 1,
- reserved1 : 3,
- regnum : 1,
- reserved2 : 15,
- trigger : 1,
- trigger_pl : 1,
- reserved3 : 30;
- } capabilities_register;
- struct {
- u64 reserved;
- } capabilities_bus_processor_interconnect;
- } capabilities_t;
-
- typedef struct resources_s {
- u64 ibr0 : 1,
- ibr2 : 1,
- ibr4 : 1,
- ibr6 : 1,
- dbr0 : 1,
- dbr2 : 1,
- dbr4 : 1,
- dbr6 : 1,
- reserved : 48;
- } resources_t;
-
-
- long get_page_size(void)
- {
- long page_size=sysconf(_SC_PAGESIZE);
- return page_size;
- }
-
- #define PAGE_SIZE (get_page_size()==-1?0x4000:get_page_size())
- #define SHM_SIZE (2*PAGE_SIZE*NR_CPUS)
- #define SHM_VA 0x2000000100000000
-
- int shmid;
- void *shmaddr;
-
- int create_shm(void)
- {
- key_t key;
- char fn[MAX_FN_SIZE];
-
- /* cpu0 is always existing */
- sprintf(fn, PATH_FORMAT, 0);
- if ((key = ftok(fn, 's')) == -1) {
- perror("ftok");
- return -1;
- }
-
- shmid = shmget(key, SHM_SIZE, 0644 | IPC_CREAT);
- if (shmid == -1) {
- if (errno==EEXIST) {
- shmid = shmget(key, SHM_SIZE, 0);
- if (shmid == -1) {
- perror("shmget");
- return -1;
- }
- }
- else {
- perror("shmget");
- return -1;
- }
- }
- vbprintf("shmid=%d", shmid);
-
- /* connect to the segment: */
- shmaddr = shmat(shmid, (void *)SHM_VA, 0);
- if (shmaddr == (void*)-1) {
- perror("shmat");
- return -1;
- }
-
- memset(shmaddr, 0, SHM_SIZE);
- mlock(shmaddr, SHM_SIZE);
-
- return 0;
- }
-
- int free_shm()
- {
- munlock(shmaddr, SHM_SIZE);
- shmdt(shmaddr);
- semctl(shmid, 0, IPC_RMID);
-
- return 0;
- }
-
- #ifdef _SEM_SEMUN_UNDEFINED
- union semun
- {
- int val;
- struct semid_ds *buf;
- unsigned short int *array;
- struct seminfo *__buf;
- };
- #endif
-
- u32 mode=1; /* 1: physical mode; 2: virtual mode. */
- int one_lock=1;
- key_t key[NR_CPUS];
- int semid[NR_CPUS];
-
- int create_sem(int cpu)
- {
- union semun arg;
- char fn[MAX_FN_SIZE];
- int sid;
-
- sprintf(fn, PATH_FORMAT, cpu);
- sprintf(fn, "%s/%s", fn, "err_type_info");
- if ((key[cpu] = ftok(fn, 'e')) == -1) {
- perror("ftok");
- return -1;
- }
-
- if (semid[cpu]!=0)
- return 0;
-
- /* clear old semaphore */
- if ((sid = semget(key[cpu], 1, 0)) != -1)
- semctl(sid, 0, IPC_RMID);
-
- /* get one semaphore */
- if ((semid[cpu] = semget(key[cpu], 1, IPC_CREAT | IPC_EXCL)) == -1) {
- perror("semget");
- printf("Please remove semaphore with key=0x%lx, then run the tool.\n",
- (u64)key[cpu]);
- return -1;
- }
-
- vbprintf("semid[%d]=0x%lx, key[%d]=%lx\n",cpu,(u64)semid[cpu],cpu,
- (u64)key[cpu]);
- /* initialize the semaphore to 1: */
- arg.val = 1;
- if (semctl(semid[cpu], 0, SETVAL, arg) == -1) {
- perror("semctl");
- return -1;
- }
-
- return 0;
- }
-
- static int lock(int cpu)
- {
- struct sembuf lock;
-
- lock.sem_num = cpu;
- lock.sem_op = 1;
- semop(semid[cpu], &lock, 1);
-
- return 0;
- }
-
- static int unlock(int cpu)
- {
- struct sembuf unlock;
-
- unlock.sem_num = cpu;
- unlock.sem_op = -1;
- semop(semid[cpu], &unlock, 1);
-
- return 0;
- }
-
- void free_sem(int cpu)
- {
- semctl(semid[cpu], 0, IPC_RMID);
- }
-
- int wr_multi(char *fn, unsigned long *data, int size)
- {
- int fd;
- char buf[MAX_BUF_SIZE];
- int ret;
-
- if (size==1)
- sprintf(buf, "%lx", *data);
- else if (size==3)
- sprintf(buf, "%lx,%lx,%lx", data[0], data[1], data[2]);
- else {
- fprintf(stderr,"write to file with wrong size!\n");
- return -1;
- }
-
- fd=open(fn, O_RDWR);
- if (!fd) {
- perror("Error:");
- return -1;
- }
- ret=write(fd, buf, sizeof(buf));
- close(fd);
- return ret;
- }
-
- int wr(char *fn, unsigned long data)
- {
- return wr_multi(fn, &data, 1);
- }
-
- int rd(char *fn, unsigned long *data)
- {
- int fd;
- char buf[MAX_BUF_SIZE];
-
- fd=open(fn, O_RDONLY);
- if (fd<0) {
- perror("Error:");
- return -1;
- }
- read(fd, buf, MAX_BUF_SIZE);
- *data=strtoul(buf, NULL, 16);
- close(fd);
- return 0;
- }
-
- int rd_status(char *path, int *status)
- {
- char fn[MAX_FN_SIZE];
- sprintf(fn, "%s/status", path);
- if (rd(fn, (u64*)status)<0) {
- perror("status reading error.\n");
- return -1;
- }
-
- return 0;
- }
-
- int rd_capabilities(char *path, u64 *capabilities)
- {
- char fn[MAX_FN_SIZE];
- sprintf(fn, "%s/capabilities", path);
- if (rd(fn, capabilities)<0) {
- perror("capabilities reading error.\n");
- return -1;
- }
-
- return 0;
- }
-
- int rd_all(char *path)
- {
- unsigned long err_type_info, err_struct_info, err_data_buffer;
- int status;
- unsigned long capabilities, resources;
- char fn[MAX_FN_SIZE];
-
- sprintf(fn, "%s/err_type_info", path);
- if (rd(fn, &err_type_info)<0) {
- perror("err_type_info reading error.\n");
- return -1;
- }
- printf("err_type_info=%lx\n", err_type_info);
-
- sprintf(fn, "%s/err_struct_info", path);
- if (rd(fn, &err_struct_info)<0) {
- perror("err_struct_info reading error.\n");
- return -1;
- }
- printf("err_struct_info=%lx\n", err_struct_info);
-
- sprintf(fn, "%s/err_data_buffer", path);
- if (rd(fn, &err_data_buffer)<0) {
- perror("err_data_buffer reading error.\n");
- return -1;
- }
- printf("err_data_buffer=%lx\n", err_data_buffer);
-
- sprintf(fn, "%s/status", path);
- if (rd("status", (u64*)&status)<0) {
- perror("status reading error.\n");
- return -1;
- }
- printf("status=%d\n", status);
-
- sprintf(fn, "%s/capabilities", path);
- if (rd(fn,&capabilities)<0) {
- perror("capabilities reading error.\n");
- return -1;
- }
- printf("capabilities=%lx\n", capabilities);
-
- sprintf(fn, "%s/resources", path);
- if (rd(fn, &resources)<0) {
- perror("resources reading error.\n");
- return -1;
- }
- printf("resources=%lx\n", resources);
-
- return 0;
- }
-
- int query_capabilities(char *path, err_type_info_t err_type_info,
- u64 *capabilities)
- {
- char fn[MAX_FN_SIZE];
- err_struct_info_t err_struct_info;
- err_data_buffer_t err_data_buffer;
-
- err_struct_info.err_struct_info=0;
- memset(err_data_buffer.err_data_buffer, -1, ERR_DATA_BUFFER_SIZE*8);
-
- sprintf(fn, "%s/err_type_info", path);
- wr(fn, err_type_info.err_type_info);
- sprintf(fn, "%s/err_struct_info", path);
- wr(fn, 0x0);
- sprintf(fn, "%s/err_data_buffer", path);
- wr_multi(fn, err_data_buffer.err_data_buffer, ERR_DATA_BUFFER_SIZE);
-
- // Fire pal_mc_error_inject procedure.
- sprintf(fn, "%s/call_start", path);
- wr(fn, mode);
-
- if (rd_capabilities(path, capabilities)<0)
- return -1;
-
- return 0;
- }
-
- int query_all_capabilities()
- {
- int status;
- err_type_info_t err_type_info;
- int err_sev, err_struct, struct_hier;
- int cap=0;
- u64 capabilities;
- char path[MAX_FN_SIZE];
-
- err_type_info.err_type_info=0; // Initial
- err_type_info.err_type_info_u.mode=0; // Query mode;
- err_type_info.err_type_info_u.err_inj=0;
-
- printf("All capabilities implemented in pal_mc_error_inject:\n");
- sprintf(path, PATH_FORMAT ,0);
- for (err_sev=0;err_sev<3;err_sev++)
- for (err_struct=0;err_struct<5;err_struct++)
- for (struct_hier=0;struct_hier<5;struct_hier++)
- {
- status=-1;
- capabilities=0;
- err_type_info.err_type_info_u.err_sev=err_sev;
- err_type_info.err_type_info_u.err_struct=err_struct;
- err_type_info.err_type_info_u.struct_hier=struct_hier;
-
- if (query_capabilities(path, err_type_info, &capabilities)<0)
- continue;
-
- if (rd_status(path, &status)<0)
- continue;
-
- if (status==0) {
- cap=1;
- printf("For err_sev=%d, err_struct=%d, struct_hier=%d: ",
- err_sev, err_struct, struct_hier);
- printf("capabilities 0x%lx\n", capabilities);
- }
- }
- if (!cap) {
- printf("No capabilities supported.\n");
- return 0;
- }
-
- return 0;
- }
-
- int err_inject(int cpu, char *path, err_type_info_t err_type_info,
- err_struct_info_t err_struct_info,
- err_data_buffer_t err_data_buffer)
- {
- int status;
- char fn[MAX_FN_SIZE];
-
- log_info(cpu, "err_type_info=%lx, err_struct_info=%lx, ",
- err_type_info.err_type_info,
- err_struct_info.err_struct_info);
- log_info(cpu,"err_data_buffer=[%lx,%lx,%lx]\n",
- err_data_buffer.err_data_buffer[0],
- err_data_buffer.err_data_buffer[1],
- err_data_buffer.err_data_buffer[2]);
- sprintf(fn, "%s/err_type_info", path);
- wr(fn, err_type_info.err_type_info);
- sprintf(fn, "%s/err_struct_info", path);
- wr(fn, err_struct_info.err_struct_info);
- sprintf(fn, "%s/err_data_buffer", path);
- wr_multi(fn, err_data_buffer.err_data_buffer, ERR_DATA_BUFFER_SIZE);
-
- // Fire pal_mc_error_inject procedure.
- sprintf(fn, "%s/call_start", path);
- wr(fn,mode);
-
- if (rd_status(path, &status)<0) {
- vbprintf("fail: read status\n");
- return -100;
- }
-
- if (status!=0) {
- log_info(cpu, "fail: status=%d\n", status);
- return status;
- }
-
- return status;
- }
-
- static int construct_data_buf(char *path, err_type_info_t err_type_info,
- err_struct_info_t err_struct_info,
- err_data_buffer_t *err_data_buffer,
- void *va1)
- {
- char fn[MAX_FN_SIZE];
- u64 virt_addr=0, phys_addr=0;
-
- vbprintf("va1=%lx\n", (u64)va1);
- memset(&err_data_buffer->err_data_buffer_cache, 0, ERR_DATA_BUFFER_SIZE*8);
-
- switch (err_type_info.err_type_info_u.err_struct) {
- case 1: // Cache
- switch (err_struct_info.err_struct_info_cache.cl_id) {
- case 1: //Virtual addr
- err_data_buffer->err_data_buffer_cache.inj_addr=(u64)va1;
- break;
- case 2: //Phys addr
- sprintf(fn, "%s/virtual_to_phys", path);
- virt_addr=(u64)va1;
- if (wr(fn,virt_addr)<0)
- return -1;
- rd(fn, &phys_addr);
- err_data_buffer->err_data_buffer_cache.inj_addr=phys_addr;
- break;
- default:
- printf("Not supported cl_id\n");
- break;
- }
- break;
- case 2: // TLB
- break;
- case 3: // Register file
- break;
- case 4: // Bus/system interconnect
- default:
- printf("Not supported err_struct\n");
- break;
- }
-
- return 0;
- }
-
- typedef struct {
- u64 cpu;
- u64 loop;
- u64 interval;
- u64 err_type_info;
- u64 err_struct_info;
- u64 err_data_buffer[ERR_DATA_BUFFER_SIZE];
- } parameters_t;
-
- parameters_t line_para;
- int para;
-
- static int empty_data_buffer(u64 *err_data_buffer)
- {
- int empty=1;
- int i;
-
- for (i=0;i<ERR_DATA_BUFFER_SIZE; i++)
- if (err_data_buffer[i]!=-1)
- empty=0;
-
- return empty;
- }
-
- int err_inj()
- {
- err_type_info_t err_type_info;
- err_struct_info_t err_struct_info;
- err_data_buffer_t err_data_buffer;
- int count;
- FILE *fp;
- unsigned long cpu, loop, interval, err_type_info_conf, err_struct_info_conf;
- u64 err_data_buffer_conf[ERR_DATA_BUFFER_SIZE];
- int num;
- int i;
- char path[MAX_FN_SIZE];
- parameters_t parameters[MAX_TASK_NUM]={};
- pid_t child_pid[MAX_TASK_NUM];
- time_t current_time;
- int status;
-
- if (!para) {
- fp=fopen("err.conf", "r");
- if (fp==NULL) {
- perror("Error open err.conf");
- return -1;
- }
-
- num=0;
- while (!feof(fp)) {
- char buf[256];
- memset(buf,0,256);
- fgets(buf, 256, fp);
- count=sscanf(buf, "%lx, %lx, %lx, %lx, %lx, %lx, %lx, %lx\n",
- &cpu, &loop, &interval,&err_type_info_conf,
- &err_struct_info_conf,
- &err_data_buffer_conf[0],
- &err_data_buffer_conf[1],
- &err_data_buffer_conf[2]);
- if (count!=PARA_FIELD_NUM+3) {
- err_data_buffer_conf[0]=-1;
- err_data_buffer_conf[1]=-1;
- err_data_buffer_conf[2]=-1;
- count=sscanf(buf, "%lx, %lx, %lx, %lx, %lx\n",
- &cpu, &loop, &interval,&err_type_info_conf,
- &err_struct_info_conf);
- if (count!=PARA_FIELD_NUM)
- continue;
- }
-
- parameters[num].cpu=cpu;
- parameters[num].loop=loop;
- parameters[num].interval= interval>MIN_INTERVAL
- ?interval:MIN_INTERVAL;
- parameters[num].err_type_info=err_type_info_conf;
- parameters[num].err_struct_info=err_struct_info_conf;
- memcpy(parameters[num++].err_data_buffer,
- err_data_buffer_conf,ERR_DATA_BUFFER_SIZE*8) ;
-
- if (num>=MAX_TASK_NUM)
- break;
- }
- }
- else {
- parameters[0].cpu=line_para.cpu;
- parameters[0].loop=line_para.loop;
- parameters[0].interval= line_para.interval>MIN_INTERVAL
- ?line_para.interval:MIN_INTERVAL;
- parameters[0].err_type_info=line_para.err_type_info;
- parameters[0].err_struct_info=line_para.err_struct_info;
- memcpy(parameters[0].err_data_buffer,
- line_para.err_data_buffer,ERR_DATA_BUFFER_SIZE*8) ;
-
- num=1;
- }
-
- /* Create semaphore: If one_lock, one semaphore for all processors.
- Otherwise, one semaphore for each processor. */
- if (one_lock) {
- if (create_sem(0)) {
- printf("Can not create semaphore...exit\n");
- free_sem(0);
- return -1;
- }
- }
- else {
- for (i=0;i<num;i++) {
- if (create_sem(parameters[i].cpu)) {
- printf("Can not create semaphore for cpu%d...exit\n",i);
- free_sem(parameters[num].cpu);
- return -1;
- }
- }
- }
-
- /* Create a shm segment which will be used to inject/consume errors on.*/
- if (create_shm()==-1) {
- printf("Error to create shm...exit\n");
- return -1;
- }
-
- for (i=0;i<num;i++) {
- pid_t pid;
-
- current_time=time(NULL);
- log_info(parameters[i].cpu, "\nBegine at %s", ctime(&current_time));
- log_info(parameters[i].cpu, "Configurations:\n");
- log_info(parameters[i].cpu,"On cpu%ld: loop=%lx, interval=%lx(s)",
- parameters[i].cpu,
- parameters[i].loop,
- parameters[i].interval);
- log_info(parameters[i].cpu," err_type_info=%lx,err_struct_info=%lx\n",
- parameters[i].err_type_info,
- parameters[i].err_struct_info);
-
- sprintf(path, PATH_FORMAT, (int)parameters[i].cpu);
- err_type_info.err_type_info=parameters[i].err_type_info;
- err_struct_info.err_struct_info=parameters[i].err_struct_info;
- memcpy(err_data_buffer.err_data_buffer,
- parameters[i].err_data_buffer,
- ERR_DATA_BUFFER_SIZE*8);
-
- pid=fork();
- if (pid==0) {
- unsigned long mask[MASK_SIZE];
- int j, k;
-
- void *va1, *va2;
-
- /* Allocate two memory areas va1 and va2 in shm */
- va1=shmaddr+parameters[i].cpu*PAGE_SIZE;
- va2=shmaddr+parameters[i].cpu*PAGE_SIZE+PAGE_SIZE;
-
- vbprintf("va1=%lx, va2=%lx\n", (u64)va1, (u64)va2);
- memset(va1, 0x1, PAGE_SIZE);
- memset(va2, 0x2, PAGE_SIZE);
-
- if (empty_data_buffer(err_data_buffer.err_data_buffer))
- /* If not specified yet, construct data buffer
- * with va1
- */
- construct_data_buf(path, err_type_info,
- err_struct_info, &err_data_buffer,va1);
-
- for (j=0;j<MASK_SIZE;j++)
- mask[j]=0;
-
- cpu=parameters[i].cpu;
- k = cpu%64;
- j = cpu/64;
- mask[j] = 1UL << k;
-
- if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
- perror("Error sched_setaffinity:");
- return -1;
- }
-
- for (j=0; j<parameters[i].loop; j++) {
- log_info(parameters[i].cpu,"Injection ");
- log_info(parameters[i].cpu,"on cpu%ld: #%d/%ld ",
-
- parameters[i].cpu,j+1, parameters[i].loop);
-
- /* Hold the lock */
- if (one_lock)
- lock(0);
- else
- /* Hold lock on this cpu */
- lock(parameters[i].cpu);
-
- if ((status=err_inject(parameters[i].cpu,
- path, err_type_info,
- err_struct_info, err_data_buffer))
- ==0) {
- /* consume the error for "inject only"*/
- memcpy(va2, va1, PAGE_SIZE);
- memcpy(va1, va2, PAGE_SIZE);
- log_info(parameters[i].cpu,
- "successful\n");
- }
- else {
- log_info(parameters[i].cpu,"fail:");
- log_info(parameters[i].cpu,
- "status=%d\n", status);
- unlock(parameters[i].cpu);
- break;
- }
- if (one_lock)
- /* Release the lock */
- unlock(0);
- /* Release lock on this cpu */
- else
- unlock(parameters[i].cpu);
-
- if (j < parameters[i].loop-1)
- sleep(parameters[i].interval);
- }
- current_time=time(NULL);
- log_info(parameters[i].cpu, "Done at %s", ctime(&current_time));
- return 0;
- }
- else if (pid<0) {
- perror("Error fork:");
- continue;
- }
- child_pid[i]=pid;
- }
- for (i=0;i<num;i++)
- waitpid(child_pid[i], NULL, 0);
-
- if (one_lock)
- free_sem(0);
- else
- for (i=0;i<num;i++)
- free_sem(parameters[i].cpu);
-
- printf("All done.\n");
-
- return 0;
- }
-
- void help()
- {
- printf("err_inject_tool:\n");
- printf("\t-q: query all capabilities. default: off\n");
- printf("\t-m: procedure mode. 1: physical 2: virtual. default: 1\n");
- printf("\t-i: inject errors. default: off\n");
- printf("\t-l: one lock per cpu. default: one lock for all\n");
- printf("\t-e: error parameters:\n");
- printf("\t\tcpu,loop,interval,err_type_info,err_struct_info[,err_data_buffer[0],err_data_buffer[1],err_data_buffer[2]]\n");
- printf("\t\t cpu: logical cpu number the error will be inject in.\n");
- printf("\t\t loop: times the error will be injected.\n");
- printf("\t\t interval: In second. every so often one error is injected.\n");
- printf("\t\t err_type_info, err_struct_info: PAL parameters.\n");
- printf("\t\t err_data_buffer: PAL parameter. Optional. If not present,\n");
- printf("\t\t it's constructed by tool automatically. Be\n");
- printf("\t\t careful to provide err_data_buffer and make\n");
- printf("\t\t sure it's working with the environment.\n");
- printf("\t Note:no space between error parameters.\n");
- printf("\t default: Take error parameters from err.conf instead of command line.\n");
- printf("\t-v: verbose. default: off\n");
- printf("\t-h: help\n\n");
- printf("The tool will take err.conf file as ");
- printf("input to inject single or multiple errors ");
- printf("on one or multiple cpus in parallel.\n");
- }
-
- int main(int argc, char **argv)
- {
- char c;
- int do_err_inj=0;
- int do_query_all=0;
- int count;
- u32 m;
-
- /* Default one lock for all cpu's */
- one_lock=1;
- while ((c = getopt(argc, argv, "m:iqvhle:")) != EOF)
- switch (c) {
- case 'm': /* Procedure mode. 1: phys 2: virt */
- count=sscanf(optarg, "%x", &m);
- if (count!=1 || (m!=1 && m!=2)) {
- printf("Wrong mode number.\n");
- help();
- return -1;
- }
- mode=m;
- break;
- case 'i': /* Inject errors */
- do_err_inj=1;
- break;
- case 'q': /* Query */
- do_query_all=1;
- break;
- case 'v': /* Verbose */
- verbose=1;
- break;
- case 'l': /* One lock per cpu */
- one_lock=0;
- break;
- case 'e': /* error arguments */
- /* Take parameters:
- * #cpu, loop, interval, err_type_info, err_struct_info[, err_data_buffer]
- * err_data_buffer is optional. Recommend not to specify
- * err_data_buffer. Better to use tool to generate it.
- */
- count=sscanf(optarg,
- "%lx, %lx, %lx, %lx, %lx, %lx, %lx, %lx\n",
- &line_para.cpu,
- &line_para.loop,
- &line_para.interval,
- &line_para.err_type_info,
- &line_para.err_struct_info,
- &line_para.err_data_buffer[0],
- &line_para.err_data_buffer[1],
- &line_para.err_data_buffer[2]);
- if (count!=PARA_FIELD_NUM+3) {
- line_para.err_data_buffer[0]=-1,
- line_para.err_data_buffer[1]=-1,
- line_para.err_data_buffer[2]=-1;
- count=sscanf(optarg, "%lx, %lx, %lx, %lx, %lx\n",
- &line_para.cpu,
- &line_para.loop,
- &line_para.interval,
- &line_para.err_type_info,
- &line_para.err_struct_info);
- if (count!=PARA_FIELD_NUM) {
- printf("Wrong error arguments.\n");
- help();
- return -1;
- }
- }
- para=1;
- break;
- continue;
- break;
- case 'h':
- help();
- return 0;
- default:
- break;
- }
-
- if (do_query_all)
- query_all_capabilities();
- if (do_err_inj)
- err_inj();
-
- if (!do_query_all && !do_err_inj)
- help();
-
- return 0;
- }
diff --git a/Documentation/ia64/features.rst b/Documentation/ia64/features.rst
deleted file mode 100644
index d7226fdcf5f8..000000000000
--- a/Documentation/ia64/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features ia64
diff --git a/Documentation/ia64/fsys.rst b/Documentation/ia64/fsys.rst
deleted file mode 100644
index a702d2cc94b6..000000000000
--- a/Documentation/ia64/fsys.rst
+++ /dev/null
@@ -1,303 +0,0 @@
-===================================
-Light-weight System Calls for IA-64
-===================================
-
- Started: 13-Jan-2003
-
- Last update: 27-Sep-2003
-
- David Mosberger-Tang
- <davidm@hpl.hp.com>
-
-Using the "epc" instruction effectively introduces a new mode of
-execution to the ia64 linux kernel. We call this mode the
-"fsys-mode". To recap, the normal states of execution are:
-
- - kernel mode:
- Both the register stack and the memory stack have been
- switched over to kernel memory. The user-level state is saved
- in a pt-regs structure at the top of the kernel memory stack.
-
- - user mode:
- Both the register stack and the kernel stack are in
- user memory. The user-level state is contained in the
- CPU registers.
-
- - bank 0 interruption-handling mode:
- This is the non-interruptible state which all
- interruption-handlers start execution in. The user-level
- state remains in the CPU registers and some kernel state may
- be stored in bank 0 of registers r16-r31.
-
-In contrast, fsys-mode has the following special properties:
-
- - execution is at privilege level 0 (most-privileged)
-
- - CPU registers may contain a mixture of user-level and kernel-level
- state (it is the responsibility of the kernel to ensure that no
- security-sensitive kernel-level state is leaked back to
- user-level)
-
- - execution is interruptible and preemptible (an fsys-mode handler
- can disable interrupts and avoid all other interruption-sources
- to avoid preemption)
-
- - neither the memory-stack nor the register-stack can be trusted while
- in fsys-mode (they point to the user-level stacks, which may
- be invalid, or completely bogus addresses)
-
-In summary, fsys-mode is much more similar to running in user-mode
-than it is to running in kernel-mode. Of course, given that the
-privilege level is at level 0, this means that fsys-mode requires some
-care (see below).
-
-
-How to tell fsys-mode
-=====================
-
-Linux operates in fsys-mode when (a) the privilege level is 0 (most
-privileged) and (b) the stacks have NOT been switched to kernel memory
-yet. For convenience, the header file <asm-ia64/ptrace.h> provides
-three macros::
-
- user_mode(regs)
- user_stack(task,regs)
- fsys_mode(task,regs)
-
-The "regs" argument is a pointer to a pt_regs structure. The "task"
-argument is a pointer to the task structure to which the "regs"
-pointer belongs to. user_mode() returns TRUE if the CPU state pointed
-to by "regs" was executing in user mode (privilege level 3).
-user_stack() returns TRUE if the state pointed to by "regs" was
-executing on the user-level stack(s). Finally, fsys_mode() returns
-TRUE if the CPU state pointed to by "regs" was executing in fsys-mode.
-The fsys_mode() macro is equivalent to the expression::
-
- !user_mode(regs) && user_stack(task,regs)
-
-How to write an fsyscall handler
-================================
-
-The file arch/ia64/kernel/fsys.S contains a table of fsyscall-handlers
-(fsyscall_table). This table contains one entry for each system call.
-By default, a system call is handled by fsys_fallback_syscall(). This
-routine takes care of entering (full) kernel mode and calling the
-normal Linux system call handler. For performance-critical system
-calls, it is possible to write a hand-tuned fsyscall_handler. For
-example, fsys.S contains fsys_getpid(), which is a hand-tuned version
-of the getpid() system call.
-
-The entry and exit-state of an fsyscall handler is as follows:
-
-Machine state on entry to fsyscall handler
-------------------------------------------
-
- ========= ===============================================================
- r10 0
- r11 saved ar.pfs (a user-level value)
- r15 system call number
- r16 "current" task pointer (in normal kernel-mode, this is in r13)
- r32-r39 system call arguments
- b6 return address (a user-level value)
- ar.pfs previous frame-state (a user-level value)
- PSR.be cleared to zero (i.e., little-endian byte order is in effect)
- - all other registers may contain values passed in from user-mode
- ========= ===============================================================
-
-Required machine state on exit to fsyscall handler
---------------------------------------------------
-
- ========= ===========================================================
- r11 saved ar.pfs (as passed into the fsyscall handler)
- r15 system call number (as passed into the fsyscall handler)
- r32-r39 system call arguments (as passed into the fsyscall handler)
- b6 return address (as passed into the fsyscall handler)
- ar.pfs previous frame-state (as passed into the fsyscall handler)
- ========= ===========================================================
-
-Fsyscall handlers can execute with very little overhead, but with that
-speed comes a set of restrictions:
-
- * Fsyscall-handlers MUST check for any pending work in the flags
- member of the thread-info structure and if any of the
- TIF_ALLWORK_MASK flags are set, the handler needs to fall back on
- doing a full system call (by calling fsys_fallback_syscall).
-
- * Fsyscall-handlers MUST preserve incoming arguments (r32-r39, r11,
- r15, b6, and ar.pfs) because they will be needed in case of a
- system call restart. Of course, all "preserved" registers also
- must be preserved, in accordance to the normal calling conventions.
-
- * Fsyscall-handlers MUST check argument registers for containing a
- NaT value before using them in any way that could trigger a
- NaT-consumption fault. If a system call argument is found to
- contain a NaT value, an fsyscall-handler may return immediately
- with r8=EINVAL, r10=-1.
-
- * Fsyscall-handlers MUST NOT use the "alloc" instruction or perform
- any other operation that would trigger mandatory RSE
- (register-stack engine) traffic.
-
- * Fsyscall-handlers MUST NOT write to any stacked registers because
- it is not safe to assume that user-level called a handler with the
- proper number of arguments.
-
- * Fsyscall-handlers need to be careful when accessing per-CPU variables:
- unless proper safe-guards are taken (e.g., interruptions are avoided),
- execution may be pre-empted and resumed on another CPU at any given
- time.
-
- * Fsyscall-handlers must be careful not to leak sensitive kernel'
- information back to user-level. In particular, before returning to
- user-level, care needs to be taken to clear any scratch registers
- that could contain sensitive information (note that the current
- task pointer is not considered sensitive: it's already exposed
- through ar.k6).
-
- * Fsyscall-handlers MUST NOT access user-memory without first
- validating access-permission (this can be done typically via
- probe.r.fault and/or probe.w.fault) and without guarding against
- memory access exceptions (this can be done with the EX() macros
- defined by asmmacro.h).
-
-The above restrictions may seem draconian, but remember that it's
-possible to trade off some of the restrictions by paying a slightly
-higher overhead. For example, if an fsyscall-handler could benefit
-from the shadow register bank, it could temporarily disable PSR.i and
-PSR.ic, switch to bank 0 (bsw.0) and then use the shadow registers as
-needed. In other words, following the above rules yields extremely
-fast system call execution (while fully preserving system call
-semantics), but there is also a lot of flexibility in handling more
-complicated cases.
-
-Signal handling
-===============
-
-The delivery of (asynchronous) signals must be delayed until fsys-mode
-is exited. This is accomplished with the help of the lower-privilege
-transfer trap: arch/ia64/kernel/process.c:do_notify_resume_user()
-checks whether the interrupted task was in fsys-mode and, if so, sets
-PSR.lp and returns immediately. When fsys-mode is exited via the
-"br.ret" instruction that lowers the privilege level, a trap will
-occur. The trap handler clears PSR.lp again and returns immediately.
-The kernel exit path then checks for and delivers any pending signals.
-
-PSR Handling
-============
-
-The "epc" instruction doesn't change the contents of PSR at all. This
-is in contrast to a regular interruption, which clears almost all
-bits. Because of that, some care needs to be taken to ensure things
-work as expected. The following discussion describes how each PSR bit
-is handled.
-
-======= =======================================================================
-PSR.be Cleared when entering fsys-mode. A srlz.d instruction is used
- to ensure the CPU is in little-endian mode before the first
- load/store instruction is executed. PSR.be is normally NOT
- restored upon return from an fsys-mode handler. In other
- words, user-level code must not rely on PSR.be being preserved
- across a system call.
-PSR.up Unchanged.
-PSR.ac Unchanged.
-PSR.mfl Unchanged. Note: fsys-mode handlers must not write-registers!
-PSR.mfh Unchanged. Note: fsys-mode handlers must not write-registers!
-PSR.ic Unchanged. Note: fsys-mode handlers can clear the bit, if needed.
-PSR.i Unchanged. Note: fsys-mode handlers can clear the bit, if needed.
-PSR.pk Unchanged.
-PSR.dt Unchanged.
-PSR.dfl Unchanged. Note: fsys-mode handlers must not write-registers!
-PSR.dfh Unchanged. Note: fsys-mode handlers must not write-registers!
-PSR.sp Unchanged.
-PSR.pp Unchanged.
-PSR.di Unchanged.
-PSR.si Unchanged.
-PSR.db Unchanged. The kernel prevents user-level from setting a hardware
- breakpoint that triggers at any privilege level other than
- 3 (user-mode).
-PSR.lp Unchanged.
-PSR.tb Lazy redirect. If a taken-branch trap occurs while in
- fsys-mode, the trap-handler modifies the saved machine state
- such that execution resumes in the gate page at
- syscall_via_break(), with privilege level 3. Note: the
- taken branch would occur on the branch invoking the
- fsyscall-handler, at which point, by definition, a syscall
- restart is still safe. If the system call number is invalid,
- the fsys-mode handler will return directly to user-level. This
- return will trigger a taken-branch trap, but since the trap is
- taken _after_ restoring the privilege level, the CPU has already
- left fsys-mode, so no special treatment is needed.
-PSR.rt Unchanged.
-PSR.cpl Cleared to 0.
-PSR.is Unchanged (guaranteed to be 0 on entry to the gate page).
-PSR.mc Unchanged.
-PSR.it Unchanged (guaranteed to be 1).
-PSR.id Unchanged. Note: the ia64 linux kernel never sets this bit.
-PSR.da Unchanged. Note: the ia64 linux kernel never sets this bit.
-PSR.dd Unchanged. Note: the ia64 linux kernel never sets this bit.
-PSR.ss Lazy redirect. If set, "epc" will cause a Single Step Trap to
- be taken. The trap handler then modifies the saved machine
- state such that execution resumes in the gate page at
- syscall_via_break(), with privilege level 3.
-PSR.ri Unchanged.
-PSR.ed Unchanged. Note: This bit could only have an effect if an fsys-mode
- handler performed a speculative load that gets NaTted. If so, this
- would be the normal & expected behavior, so no special treatment is
- needed.
-PSR.bn Unchanged. Note: fsys-mode handlers may clear the bit, if needed.
- Doing so requires clearing PSR.i and PSR.ic as well.
-PSR.ia Unchanged. Note: the ia64 linux kernel never sets this bit.
-======= =======================================================================
-
-Using fast system calls
-=======================
-
-To use fast system calls, userspace applications need simply call
-__kernel_syscall_via_epc(). For example
-
--- example fgettimeofday() call --
-
--- fgettimeofday.S --
-
-::
-
- #include <asm/asmmacro.h>
-
- GLOBAL_ENTRY(fgettimeofday)
- .prologue
- .save ar.pfs, r11
- mov r11 = ar.pfs
- .body
-
- mov r2 = 0xa000000000020660;; // gate address
- // found by inspection of System.map for the
- // __kernel_syscall_via_epc() function. See
- // below for how to do this for real.
-
- mov b7 = r2
- mov r15 = 1087 // gettimeofday syscall
- ;;
- br.call.sptk.many b6 = b7
- ;;
-
- .restore sp
-
- mov ar.pfs = r11
- br.ret.sptk.many rp;; // return to caller
- END(fgettimeofday)
-
--- end fgettimeofday.S --
-
-In reality, getting the gate address is accomplished by two extra
-values passed via the ELF auxiliary vector (include/asm-ia64/elf.h)
-
- * AT_SYSINFO : is the address of __kernel_syscall_via_epc()
- * AT_SYSINFO_EHDR : is the address of the kernel gate ELF DSO
-
-The ELF DSO is a pre-linked library that is mapped in by the kernel at
-the gate page. It is a proper ELF shared object so, with a dynamic
-loader that recognises the library, you should be able to make calls to
-the exported functions within it as with any other shared library.
-AT_SYSINFO points into the kernel DSO at the
-__kernel_syscall_via_epc() function for historical reasons (it was
-used before the kernel DSO) and as a convenience.
diff --git a/Documentation/ia64/ia64.rst b/Documentation/ia64/ia64.rst
deleted file mode 100644
index b725019a9492..000000000000
--- a/Documentation/ia64/ia64.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-===========================================
-Linux kernel release for the IA-64 Platform
-===========================================
-
- These are the release notes for Linux since version 2.4 for IA-64
- platform. This document provides information specific to IA-64
- ONLY, to get additional information about the Linux kernel also
- read the original Linux README provided with the kernel.
-
-Installing the Kernel
-=====================
-
- - IA-64 kernel installation is the same as the other platforms, see
- original README for details.
-
-
-Software Requirements
-=====================
-
- Compiling and running this kernel requires an IA-64 compliant GCC
- compiler. And various software packages also compiled with an
- IA-64 compliant GCC compiler.
-
-
-Configuring the Kernel
-======================
-
- Configuration is the same, see original README for details.
-
-
-Compiling the Kernel:
-
- - Compiling this kernel doesn't differ from other platform so read
- the original README for details BUT make sure you have an IA-64
- compliant GCC compiler.
-
-IA-64 Specifics
-===============
-
- - General issues:
-
- * Hardly any performance tuning has been done. Obvious targets
- include the library routines (IP checksum, etc.). Less
- obvious targets include making sure we don't flush the TLB
- needlessly, etc.
-
- * SMP locks cleanup/optimization
-
- * IA32 support. Currently experimental. It mostly works.
diff --git a/Documentation/ia64/index.rst b/Documentation/ia64/index.rst
deleted file mode 100644
index 761f2154dfa2..000000000000
--- a/Documentation/ia64/index.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-==================
-IA-64 Architecture
-==================
-
-.. toctree::
- :maxdepth: 1
-
- ia64
- aliasing
- efirtc
- err_inject
- fsys
- irq-redir
- mca
- serial
-
- features
diff --git a/Documentation/ia64/irq-redir.rst b/Documentation/ia64/irq-redir.rst
deleted file mode 100644
index 6bbbbe4f73ef..000000000000
--- a/Documentation/ia64/irq-redir.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-==============================
-IRQ affinity on IA64 platforms
-==============================
-
-07.01.2002, Erich Focht <efocht@ess.nec.de>
-
-
-By writing to /proc/irq/IRQ#/smp_affinity the interrupt routing can be
-controlled. The behavior on IA64 platforms is slightly different from
-that described in Documentation/core-api/irq/irq-affinity.rst for i386 systems.
-
-Because of the usage of SAPIC mode and physical destination mode the
-IRQ target is one particular CPU and cannot be a mask of several
-CPUs. Only the first non-zero bit is taken into account.
-
-
-Usage examples
-==============
-
-The target CPU has to be specified as a hexadecimal CPU mask. The
-first non-zero bit is the selected CPU. This format has been kept for
-compatibility reasons with i386.
-
-Set the delivery mode of interrupt 41 to fixed and route the
-interrupts to CPU #3 (logical CPU number) (2^3=0x08)::
-
- echo "8" >/proc/irq/41/smp_affinity
-
-Set the default route for IRQ number 41 to CPU 6 in lowest priority
-delivery mode (redirectable)::
-
- echo "r 40" >/proc/irq/41/smp_affinity
-
-The output of the command::
-
- cat /proc/irq/IRQ#/smp_affinity
-
-gives the target CPU mask for the specified interrupt vector. If the CPU
-mask is preceded by the character "r", the interrupt is redirectable
-(i.e. lowest priority mode routing is used), otherwise its route is
-fixed.
-
-
-
-Initialization and default behavior
-===================================
-
-If the platform features IRQ redirection (info provided by SAL) all
-IO-SAPIC interrupts are initialized with CPU#0 as their default target
-and the routing is the so called "lowest priority mode" (actually
-fixed SAPIC mode with hint). The XTP chipset registers are used as hints
-for the IRQ routing. Currently in Linux XTP registers can have three
-values:
-
- - minimal for an idle task,
- - normal if any other task runs,
- - maximal if the CPU is going to be switched off.
-
-The IRQ is routed to the CPU with lowest XTP register value, the
-search begins at the default CPU. Therefore most of the interrupts
-will be handled by CPU #0.
-
-If the platform doesn't feature interrupt redirection IOSAPIC fixed
-routing is used. The target CPUs are distributed in a round robin
-manner. IRQs will be routed only to the selected target CPUs. Check
-with::
-
- cat /proc/interrupts
-
-
-
-Comments
-========
-
-On large (multi-node) systems it is recommended to route the IRQs to
-the node to which the corresponding device is connected.
-For systems like the NEC AzusA we get IRQ node-affinity for free. This
-is because usually the chipsets on each node redirect the interrupts
-only to their own CPUs (as they cannot see the XTP registers on the
-other nodes).
diff --git a/Documentation/ia64/mca.rst b/Documentation/ia64/mca.rst
deleted file mode 100644
index 08270bba44a4..000000000000
--- a/Documentation/ia64/mca.rst
+++ /dev/null
@@ -1,198 +0,0 @@
-=============================================================
-An ad-hoc collection of notes on IA64 MCA and INIT processing
-=============================================================
-
-Feel free to update it with notes about any area that is not clear.
-
----
-
-MCA/INIT are completely asynchronous. They can occur at any time, when
-the OS is in any state. Including when one of the cpus is already
-holding a spinlock. Trying to get any lock from MCA/INIT state is
-asking for deadlock. Also the state of structures that are protected
-by locks is indeterminate, including linked lists.
-
----
-
-The complicated ia64 MCA process. All of this is mandated by Intel's
-specification for ia64 SAL, error recovery and unwind, it is not as
-if we have a choice here.
-
-* MCA occurs on one cpu, usually due to a double bit memory error.
- This is the monarch cpu.
-
-* SAL sends an MCA rendezvous interrupt (which is a normal interrupt)
- to all the other cpus, the slaves.
-
-* Slave cpus that receive the MCA interrupt call down into SAL, they
- end up spinning disabled while the MCA is being serviced.
-
-* If any slave cpu was already spinning disabled when the MCA occurred
- then it cannot service the MCA interrupt. SAL waits ~20 seconds then
- sends an unmaskable INIT event to the slave cpus that have not
- already rendezvoused.
-
-* Because MCA/INIT can be delivered at any time, including when the cpu
- is down in PAL in physical mode, the registers at the time of the
- event are _completely_ undefined. In particular the MCA/INIT
- handlers cannot rely on the thread pointer, PAL physical mode can
- (and does) modify TP. It is allowed to do that as long as it resets
- TP on return. However MCA/INIT events expose us to these PAL
- internal TP changes. Hence curr_task().
-
-* If an MCA/INIT event occurs while the kernel was running (not user
- space) and the kernel has called PAL then the MCA/INIT handler cannot
- assume that the kernel stack is in a fit state to be used. Mainly
- because PAL may or may not maintain the stack pointer internally.
- Because the MCA/INIT handlers cannot trust the kernel stack, they
- have to use their own, per-cpu stacks. The MCA/INIT stacks are
- preformatted with just enough task state to let the relevant handlers
- do their job.
-
-* Unlike most other architectures, the ia64 struct task is embedded in
- the kernel stack[1]. So switching to a new kernel stack means that
- we switch to a new task as well. Because various bits of the kernel
- assume that current points into the struct task, switching to a new
- stack also means a new value for current.
-
-* Once all slaves have rendezvoused and are spinning disabled, the
- monarch is entered. The monarch now tries to diagnose the problem
- and decide if it can recover or not.
-
-* Part of the monarch's job is to look at the state of all the other
- tasks. The only way to do that on ia64 is to call the unwinder,
- as mandated by Intel.
-
-* The starting point for the unwind depends on whether a task is
- running or not. That is, whether it is on a cpu or is blocked. The
- monarch has to determine whether or not a task is on a cpu before it
- knows how to start unwinding it. The tasks that received an MCA or
- INIT event are no longer running, they have been converted to blocked
- tasks. But (and its a big but), the cpus that received the MCA
- rendezvous interrupt are still running on their normal kernel stacks!
-
-* To distinguish between these two cases, the monarch must know which
- tasks are on a cpu and which are not. Hence each slave cpu that
- switches to an MCA/INIT stack, registers its new stack using
- set_curr_task(), so the monarch can tell that the _original_ task is
- no longer running on that cpu. That gives us a decent chance of
- getting a valid backtrace of the _original_ task.
-
-* MCA/INIT can be nested, to a depth of 2 on any cpu. In the case of a
- nested error, we want diagnostics on the MCA/INIT handler that
- failed, not on the task that was originally running. Again this
- requires set_curr_task() so the MCA/INIT handlers can register their
- own stack as running on that cpu. Then a recursive error gets a
- trace of the failing handler's "task".
-
-[1]
- My (Keith Owens) original design called for ia64 to separate its
- struct task and the kernel stacks. Then the MCA/INIT data would be
- chained stacks like i386 interrupt stacks. But that required
- radical surgery on the rest of ia64, plus extra hard wired TLB
- entries with its associated performance degradation. David
- Mosberger vetoed that approach. Which meant that separate kernel
- stacks meant separate "tasks" for the MCA/INIT handlers.
-
----
-
-INIT is less complicated than MCA. Pressing the nmi button or using
-the equivalent command on the management console sends INIT to all
-cpus. SAL picks one of the cpus as the monarch and the rest are
-slaves. All the OS INIT handlers are entered at approximately the same
-time. The OS monarch prints the state of all tasks and returns, after
-which the slaves return and the system resumes.
-
-At least that is what is supposed to happen. Alas there are broken
-versions of SAL out there. Some drive all the cpus as monarchs. Some
-drive them all as slaves. Some drive one cpu as monarch, wait for that
-cpu to return from the OS then drive the rest as slaves. Some versions
-of SAL cannot even cope with returning from the OS, they spin inside
-SAL on resume. The OS INIT code has workarounds for some of these
-broken SAL symptoms, but some simply cannot be fixed from the OS side.
-
----
-
-The scheduler hooks used by ia64 (curr_task, set_curr_task) are layer
-violations. Unfortunately MCA/INIT start off as massive layer
-violations (can occur at _any_ time) and they build from there.
-
-At least ia64 makes an attempt at recovering from hardware errors, but
-it is a difficult problem because of the asynchronous nature of these
-errors. When processing an unmaskable interrupt we sometimes need
-special code to cope with our inability to take any locks.
-
----
-
-How is ia64 MCA/INIT different from x86 NMI?
-
-* x86 NMI typically gets delivered to one cpu. MCA/INIT gets sent to
- all cpus.
-
-* x86 NMI cannot be nested. MCA/INIT can be nested, to a depth of 2
- per cpu.
-
-* x86 has a separate struct task which points to one of multiple kernel
- stacks. ia64 has the struct task embedded in the single kernel
- stack, so switching stack means switching task.
-
-* x86 does not call the BIOS so the NMI handler does not have to worry
- about any registers having changed. MCA/INIT can occur while the cpu
- is in PAL in physical mode, with undefined registers and an undefined
- kernel stack.
-
-* i386 backtrace is not very sensitive to whether a process is running
- or not. ia64 unwind is very, very sensitive to whether a process is
- running or not.
-
----
-
-What happens when MCA/INIT is delivered what a cpu is running user
-space code?
-
-The user mode registers are stored in the RSE area of the MCA/INIT on
-entry to the OS and are restored from there on return to SAL, so user
-mode registers are preserved across a recoverable MCA/INIT. Since the
-OS has no idea what unwind data is available for the user space stack,
-MCA/INIT never tries to backtrace user space. Which means that the OS
-does not bother making the user space process look like a blocked task,
-i.e. the OS does not copy pt_regs and switch_stack to the user space
-stack. Also the OS has no idea how big the user space RSE and memory
-stacks are, which makes it too risky to copy the saved state to a user
-mode stack.
-
----
-
-How do we get a backtrace on the tasks that were running when MCA/INIT
-was delivered?
-
-mca.c:::ia64_mca_modify_original_stack(). That identifies and
-verifies the original kernel stack, copies the dirty registers from
-the MCA/INIT stack's RSE to the original stack's RSE, copies the
-skeleton struct pt_regs and switch_stack to the original stack, fills
-in the skeleton structures from the PAL minstate area and updates the
-original stack's thread.ksp. That makes the original stack look
-exactly like any other blocked task, i.e. it now appears to be
-sleeping. To get a backtrace, just start with thread.ksp for the
-original task and unwind like any other sleeping task.
-
----
-
-How do we identify the tasks that were running when MCA/INIT was
-delivered?
-
-If the previous task has been verified and converted to a blocked
-state, then sos->prev_task on the MCA/INIT stack is updated to point to
-the previous task. You can look at that field in dumps or debuggers.
-To help distinguish between the handler and the original tasks,
-handlers have _TIF_MCA_INIT set in thread_info.flags.
-
-The sos data is always in the MCA/INIT handler stack, at offset
-MCA_SOS_OFFSET. You can get that value from mca_asm.h or calculate it
-as KERNEL_STACK_SIZE - sizeof(struct pt_regs) - sizeof(struct
-ia64_sal_os_state), with 16 byte alignment for all structures.
-
-Also the comm field of the MCA/INIT task is modified to include the pid
-of the original task, for humans to use. For example, a comm field of
-'MCA 12159' means that pid 12159 was running when the MCA was
-delivered.
diff --git a/Documentation/ia64/serial.rst b/Documentation/ia64/serial.rst
deleted file mode 100644
index 1de70c305a79..000000000000
--- a/Documentation/ia64/serial.rst
+++ /dev/null
@@ -1,165 +0,0 @@
-==============
-Serial Devices
-==============
-
-Serial Device Naming
-====================
-
- As of 2.6.10, serial devices on ia64 are named based on the
- order of ACPI and PCI enumeration. The first device in the
- ACPI namespace (if any) becomes /dev/ttyS0, the second becomes
- /dev/ttyS1, etc., and PCI devices are named sequentially
- starting after the ACPI devices.
-
- Prior to 2.6.10, there were confusing exceptions to this:
-
- - Firmware on some machines (mostly from HP) provides an HCDP
- table[1] that tells the kernel about devices that can be used
- as a serial console. If the user specified "console=ttyS0"
- or the EFI ConOut path contained only UART devices, the
- kernel registered the device described by the HCDP as
- /dev/ttyS0.
-
- - If there was no HCDP, we assumed there were UARTs at the
- legacy COM port addresses (I/O ports 0x3f8 and 0x2f8), so
- the kernel registered those as /dev/ttyS0 and /dev/ttyS1.
-
- Any additional ACPI or PCI devices were registered sequentially
- after /dev/ttyS0 as they were discovered.
-
- With an HCDP, device names changed depending on EFI configuration
- and "console=" arguments. Without an HCDP, device names didn't
- change, but we registered devices that might not really exist.
-
- For example, an HP rx1600 with a single built-in serial port
- (described in the ACPI namespace) plus an MP[2] (a PCI device) has
- these ports:
-
- ========== ========== ============ ============ =======
- Type MMIO pre-2.6.10 pre-2.6.10 2.6.10+
- address
- (EFI console (EFI console
- on builtin) on MP port)
- ========== ========== ============ ============ =======
- builtin 0xff5e0000 ttyS0 ttyS1 ttyS0
- MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1
- MP Console 0xf8030000 ttyS2 ttyS0 ttyS2
- MP 2 0xf8030010 ttyS3 ttyS3 ttyS3
- MP 3 0xf8030038 ttyS4 ttyS4 ttyS4
- ========== ========== ============ ============ =======
-
-Console Selection
-=================
-
- EFI knows what your console devices are, but it doesn't tell the
- kernel quite enough to actually locate them. The DIG64 HCDP
- table[1] does tell the kernel where potential serial console
- devices are, but not all firmware supplies it. Also, EFI supports
- multiple simultaneous consoles and doesn't tell the kernel which
- should be the "primary" one.
-
- So how do you tell Linux which console device to use?
-
- - If your firmware supplies the HCDP, it is simplest to
- configure EFI with a single device (either a UART or a VGA
- card) as the console. Then you don't need to tell Linux
- anything; the kernel will automatically use the EFI console.
-
- (This works only in 2.6.6 or later; prior to that you had
- to specify "console=ttyS0" to get a serial console.)
-
- - Without an HCDP, Linux defaults to a VGA console unless you
- specify a "console=" argument.
-
- NOTE: Don't assume that a serial console device will be /dev/ttyS0.
- It might be ttyS1, ttyS2, etc. Make sure you have the appropriate
- entries in /etc/inittab (for getty) and /etc/securetty (to allow
- root login).
-
-Early Serial Console
-====================
-
- The kernel can't start using a serial console until it knows where
- the device lives. Normally this happens when the driver enumerates
- all the serial devices, which can happen a minute or more after the
- kernel starts booting.
-
- 2.6.10 and later kernels have an "early uart" driver that works
- very early in the boot process. The kernel will automatically use
- this if the user supplies an argument like "console=uart,io,0x3f8",
- or if the EFI console path contains only a UART device and the
- firmware supplies an HCDP.
-
-Troubleshooting Serial Console Problems
-=======================================
-
- No kernel output after elilo prints "Uncompressing Linux... done":
-
- - You specified "console=ttyS0" but Linux changed the device
- to which ttyS0 refers. Configure exactly one EFI console
- device[3] and remove the "console=" option.
-
- - The EFI console path contains both a VGA device and a UART.
- EFI and elilo use both, but Linux defaults to VGA. Remove
- the VGA device from the EFI console path[3].
-
- - Multiple UARTs selected as EFI console devices. EFI and
- elilo use all selected devices, but Linux uses only one.
- Make sure only one UART is selected in the EFI console
- path[3].
-
- - You're connected to an HP MP port[2] but have a non-MP UART
- selected as EFI console device. EFI uses the MP as a
- console device even when it isn't explicitly selected.
- Either move the console cable to the non-MP UART, or change
- the EFI console path[3] to the MP UART.
-
- Long pause (60+ seconds) between "Uncompressing Linux... done" and
- start of kernel output:
-
- - No early console because you used "console=ttyS<n>". Remove
- the "console=" option if your firmware supplies an HCDP.
-
- - If you don't have an HCDP, the kernel doesn't know where
- your console lives until the driver discovers serial
- devices. Use "console=uart,io,0x3f8" (or appropriate
- address for your machine).
-
- Kernel and init script output works fine, but no "login:" prompt:
-
- - Add getty entry to /etc/inittab for console tty. Look for
- the "Adding console on ttyS<n>" message that tells you which
- device is the console.
-
- "login:" prompt, but can't login as root:
-
- - Add entry to /etc/securetty for console tty.
-
- No ACPI serial devices found in 2.6.17 or later:
-
- - Turn on CONFIG_PNP and CONFIG_PNPACPI. Prior to 2.6.17, ACPI
- serial devices were discovered by 8250_acpi. In 2.6.17,
- 8250_acpi was replaced by the combination of 8250_pnp and
- CONFIG_PNPACPI.
-
-
-
-[1]
- http://www.dig64.org/specifications/agreement
- The table was originally defined as the "HCDP" for "Headless
- Console/Debug Port." The current version is the "PCDP" for
- "Primary Console and Debug Port Devices."
-
-[2]
- The HP MP (management processor) is a PCI device that provides
- several UARTs. One of the UARTs is often used as a console; the
- EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart".
- The external connection is usually a 25-pin connector, and a
- special dongle converts that to three 9-pin connectors, one of
- which is labelled "Console."
-
-[3]
- EFI console devices are configured using the EFI Boot Manager
- "Boot option maintenance" menu. You may have to interrupt the
- boot sequence to use this menu, and you will have to reset the
- box after changing console configuration.
diff --git a/Documentation/iio/ad3552r.rst b/Documentation/iio/ad3552r.rst
new file mode 100644
index 000000000000..4274e35f503d
--- /dev/null
+++ b/Documentation/iio/ad3552r.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+==============
+AD3552R driver
+==============
+
+Device driver for Analog Devices Inc. AD35XXR series of DACs. The module name
+is ``ad3552r``.
+With the same module name, two different driver variants are available, the
+``generic spi`` variant, to be used with any classic SPI controllers, and the
+``hs`` (high speed) variant, for an ADI ``axi-dac`` (IP core) based controller
+that allows to reach the maximum sample rate supported from the DACs, using the
+DMA transfer and all the SPI lines available (D/QDSPI)..
+The high speed driver variant is intended to be used with the ``adi-axi-dac``
+backend support enabled, that is enabled by default when the driver is selected.
+
+Supported devices
+=================
+
+* `AD3541R <https://www.analog.com/en/products/ad3541r.html>`_
+* `AD3542R <https://www.analog.com/en/products/ad3542r.html>`_
+* `AD3551R <https://www.analog.com/en/products/ad3551r.html>`_
+* `AD3552R <https://www.analog.com/en/products/ad3552r.html>`_
+
+Wiring connections
+==================
+
+Generic SPI
+-----------
+Use the classic SPI S_CLK/CS/SDO/SDI connection.
+
+High speed (using axi-dac backend)
+----------------------------------
+
+::
+
+ .-----------------. .-------.
+ | |--- D/QSPI -----| |
+ | DAC IP CORE |--- SPI S_CLK --| DAC |
+ | |--- SPI CS -----| |
+ | |--- LDAC -------| |
+ | |--- RESET ------| |
+ |_________________| |_______|
+
+
+High speed features
+===================
+
+Device attributes
+-----------------
+
+The following table shows the ad35xxr related device debug files, found in the
+specific debugfs path ``/sys/kernel/debug/iio/iio:deviceX``.
+
++-----------------------+------------------------------------------------------+
+| Debugfs device files | Description |
++-----------------------+------------------------------------------------------+
+| data_source | The used data source, as |
+| | ``normal``, ``ramp-16bit``, etc. |
++-----------------------+------------------------------------------------------+
+| data_source_available | The available data sources. |
++-----------------------+------------------------------------------------------+
+
+Usage examples
+--------------
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0# cat data_source
+ normal
+ root:/sys/bus/iio/devices/iio:device0# echo -n ramp-16bit > data_source
+ root:/sys/bus/iio/devices/iio:device0# cat data_source
+ ramp-16bit
diff --git a/Documentation/iio/ad4000.rst b/Documentation/iio/ad4000.rst
new file mode 100644
index 000000000000..c1d04d3436d2
--- /dev/null
+++ b/Documentation/iio/ad4000.rst
@@ -0,0 +1,220 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD4000 driver
+=============
+
+Device driver for Analog Devices Inc. AD4000 series of ADCs and similar devices.
+
+Supported devices
+=================
+
+* `AD4000 <https://www.analog.com/AD4000>`_
+* `AD4001 <https://www.analog.com/AD4001>`_
+* `AD4002 <https://www.analog.com/AD4002>`_
+* `AD4003 <https://www.analog.com/AD4003>`_
+* `AD4004 <https://www.analog.com/AD4004>`_
+* `AD4005 <https://www.analog.com/AD4005>`_
+* `AD4006 <https://www.analog.com/AD4006>`_
+* `AD4007 <https://www.analog.com/AD4007>`_
+* `AD4008 <https://www.analog.com/AD4008>`_
+* `AD4010 <https://www.analog.com/AD4010>`_
+* `AD4011 <https://www.analog.com/AD4011>`_
+* `AD4020 <https://www.analog.com/AD4020>`_
+* `AD4021 <https://www.analog.com/AD4021>`_
+* `AD4022 <https://www.analog.com/AD4022>`_
+* `ADAQ4001 <https://www.analog.com/ADAQ4001>`_
+* `ADAQ4003 <https://www.analog.com/ADAQ4003>`_
+* `AD7685 <https://www.analog.com/AD7685>`_
+* `AD7686 <https://www.analog.com/AD7686>`_
+* `AD7687 <https://www.analog.com/AD7687>`_
+* `AD7688 <https://www.analog.com/AD7688>`_
+* `AD7690 <https://www.analog.com/AD7690>`_
+* `AD7691 <https://www.analog.com/AD7691>`_
+* `AD7693 <https://www.analog.com/AD7693>`_
+* `AD7942 <https://www.analog.com/AD7942>`_
+* `AD7946 <https://www.analog.com/AD7946>`_
+* `AD7980 <https://www.analog.com/AD7980>`_
+* `AD7982 <https://www.analog.com/AD7982>`_
+* `AD7983 <https://www.analog.com/AD7983>`_
+* `AD7984 <https://www.analog.com/AD7984>`_
+* `AD7988-1 <https://www.analog.com/AD7988-1>`_
+* `AD7988-5 <https://www.analog.com/AD7988-5>`_
+
+Wiring connections
+------------------
+
+Devices of the AD4000 series can be connected to the SPI host controller in a
+few different modes.
+
+CS mode, 3-wire turbo mode
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Datasheet "3-wire" mode is what most resembles standard SPI connection which,
+for these devices, comprises of connecting the controller CS line to device CNV
+pin and other SPI lines as usual. This configuration is (misleadingly) called
+"CS Mode, 3-Wire Turbo Mode" connection in datasheets.
+NOTE: The datasheet definition of 3-wire mode for the AD4000 series is NOT the
+same of standard spi-3wire mode.
+This is the only connection mode that allows configuration register access but
+it requires the SPI controller to support the ``SPI_MOSI_IDLE_HIGH`` feature.
+
+Omit the ``adi,sdi-pin`` property in device tree to select this mode.
+
+::
+
+ +-------------+
+ + ----------------------------------| SDO |
+ | | |
+ | +-------------------| CS |
+ | v | |
+ | +--------------------+ | HOST |
+ | | CNV | | |
+ +--->| SDI AD4000 SDO |-------->| SDI |
+ | SCK | | |
+ +--------------------+ | |
+ ^ | |
+ +--------------------| SCLK |
+ +-------------+
+
+CS mode, 3-wire, without busy indicator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Another wiring configuration supported as "3-wire" mode has the SDI pin
+hard-wired to digital input/output interface supply (VIO). In this setup, the
+controller is not required to support ``SPI_MOSI_IDLE_HIGH`` but register access
+is not possible. This connection mode saves one wire and works with any SPI
+controller.
+
+Set the ``adi,sdi-pin`` device tree property to ``"high"`` to select this mode.
+
+::
+
+ +-------------+
+ +--------------------| CS |
+ v | |
+ VIO +--------------------+ | HOST |
+ | | CNV | | |
+ +--->| SDI AD4000 SDO |-------->| SDI |
+ | SCK | | |
+ +--------------------+ | |
+ ^ | |
+ +--------------------| SCLK |
+ +-------------+
+
+Alternatively, a GPIO may be connected to the device CNV pin. This is similar to
+the previous wiring configuration but saves the use of a CS line.
+
+::
+
+ +-------------+
+ +--------------------| GPIO |
+ v | |
+ VIO +--------------------+ | HOST |
+ | | CNV | | |
+ +--->| SDI AD4000 SDO |-------->| SDI |
+ | SCK | | |
+ +--------------------+ | |
+ ^ | |
+ +--------------------| SCLK |
+ +-------------+
+
+CS mode, 4-wire without busy indicator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In datasheet "4-wire" mode, the controller CS line is connected to the ADC SDI
+pin and a GPIO is connected to the ADC CNV pin. This connection mode may better
+suit scenarios where multiple ADCs can share one CNV trigger.
+
+Set ``adi,sdi-pin`` to ``"cs"`` to select this mode.
+
+
+::
+
+ +-------------+
+ + ----------------------------------| CS |
+ | | |
+ | +-------------------| GPIO |
+ | v | |
+ | +--------------------+ | HOST |
+ | | CNV | | |
+ +--->| SDI AD4000 SDO |-------->| SDI |
+ | SCK | | |
+ +--------------------+ | |
+ ^ | |
+ +--------------------| SCLK |
+ +-------------+
+
+IIO Device characteristics
+==========================
+
+The AD4000 series driver supports differential and pseudo-differential ADCs.
+
+The span compression feature available in AD4000 series devices can be
+enabled/disabled by changing the ``_scale_available`` attribute of the voltage
+channel. Note that span compression configuration requires writing to AD4000
+configuration register, which is only possible when the ADC is wired in 3-wire
+turbo mode, and the SPI controller is ``SPI_MOSI_IDLE_HIGH`` capable. If those
+conditions are not met, no ``_scale_available`` attribute is provided.
+
+Besides that, differential and pseudo-differential voltage channels present
+slightly different sysfs interfaces.
+
+Pseudo-differential ADCs
+------------------------
+
+Typical voltage channel attributes of a pseudo-differential AD4000 series device:
+
++-------------------------------------------+------------------------------------------+
+| Voltage Channel Attributes | Description |
++===========================================+==========================================+
+| ``in_voltage0_raw`` | Raw ADC output code. |
++-------------------------------------------+------------------------------------------+
+| ``in_voltage0_offset`` | Offset to convert raw value to mV. |
++-------------------------------------------+------------------------------------------+
+| ``in_voltage0_scale`` | Scale factor to convert raw value to mV. |
++-------------------------------------------+------------------------------------------+
+| ``in_voltage0_scale_available`` | Toggles input span compression |
++-------------------------------------------+------------------------------------------+
+
+Differential ADCs
+-----------------
+
+Typical voltage channel attributes of a differential AD4000 series device:
+
++-------------------------------------------+------------------------------------------+
+| Voltage Channel Attributes | Description |
++===========================================+==========================================+
+| ``in_voltage0-voltage1_raw`` | Raw ADC output code. |
++-------------------------------------------+------------------------------------------+
+| ``in_voltage0-voltage1_scale`` | Scale factor to convert raw value to mV. |
++-------------------------------------------+------------------------------------------+
+| ``in_voltage0-voltage1_scale_available`` | Toggles input span compression |
++-------------------------------------------+------------------------------------------+
+
+SPI offload support
+-------------------
+
+To be able to achieve the maximum sample rate, the driver can be used with SPI
+offload engines such as the one usually present in `AXI SPI Engine`_, to provide
+SPI offload support.
+
+.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/pulsar_adc/index.html
+
+To keep up with SPI offloading transfer speeds, the ADC must be connected either
+in 3-wire turbo mode or in 3-wire without busy indicator mode and have SPI
+controller CS line connected to the CNV pin.
+
+When set for SPI offload support, the IIO device will provide different
+interfaces.
+
+* Either ``in_voltage0_sampling_frequency`` or
+ ``in_voltage0-voltage1_sampling_frequency`` file is provided to allow setting
+ the sample rate.
+* IIO trigger device is not provided (no ``trigger`` directory).
+* ``timestamp`` channel is not provided.
+
+Also, because the ADC output has a one sample latency (delay) when the device is
+wired in "3-wire" mode and only one transfer per sample is done when using SPI
+offloading, the first data sample in the buffer is not valid because it contains
+the output of an earlier conversion result.
diff --git a/Documentation/iio/ad4030.rst b/Documentation/iio/ad4030.rst
new file mode 100644
index 000000000000..b57424b650a8
--- /dev/null
+++ b/Documentation/iio/ad4030.rst
@@ -0,0 +1,180 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD4030 driver
+=============
+
+ADC driver for Analog Devices Inc. AD4030 and similar devices. The module name
+is ``ad4030``.
+
+
+Supported devices
+=================
+
+The following chips are supported by this driver:
+
+* `AD4030-24 <https://www.analog.com/AD4030-24>`_
+* `AD4032-24 <https://www.analog.com/AD4032-24>`_
+* `AD4630-16 <https://www.analog.com/AD4630-16>`_
+* `AD4630-24 <https://www.analog.com/AD4630-24>`_
+* `AD4632-16 <https://www.analog.com/AD4632-16>`_
+* `AD4632-24 <https://www.analog.com/AD4632-24>`_
+
+IIO channels
+============
+
+Each "hardware" channel as described in the datasheet is split in 2 IIO
+channels:
+
+- One channel for the differential data
+- One channel for the common byte.
+
+The possible IIO channels depending on the numbers of "hardware" channel are:
+
++------------------------------------+------------------------------------+
+| 1 channel ADC | 2 channels ADC |
++====================================+====================================+
+| - voltage0-voltage1 (differential) | - voltage0-voltage1 (differential) |
+| - voltage2 (common-mode) | - voltage2-voltage3 (differential) |
+| | - voltage4 (common-mode) |
+| | - voltage5 (common-mode) |
++------------------------------------+------------------------------------+
+
+Labels
+------
+
+For ease of use, the IIO channels provide a label. For a differential channel,
+the label is ``differentialN`` where ``N`` is the "hardware" channel id. For a
+common-mode channel, the label is ``common-modeN`` where ``N`` is the
+"hardware" channel id.
+
+The possible labels are:
+
++-----------------+-----------------+
+| 1 channel ADC | 2 channels ADC |
++=================+=================+
+| - differential0 | - differential0 |
+| - common-mode0 | - differential1 |
+| | - common-mode0 |
+| | - common-mode1 |
++-----------------+-----------------+
+
+Supported features
+==================
+
+SPI wiring modes
+----------------
+
+The driver currently supports the following SPI wiring configurations:
+
+One lane mode
+^^^^^^^^^^^^^
+
+In this mode, each channel has its own SDO line to send the conversion results.
+At the moment this mode can only be used on AD4030 which has one channel so only
+one SDO line is used.
+
+.. code-block::
+
+ +-------------+ +-------------+
+ | ADC | | HOST |
+ | | | |
+ | CNV |<--------| CNV |
+ | CS |<--------| CS |
+ | SDI |<--------| SDO |
+ | SDO0 |-------->| SDI |
+ | SCLK |<--------| SCLK |
+ +-------------+ +-------------+
+
+Interleaved mode
+^^^^^^^^^^^^^^^^
+
+In this mode, both channels conversion results are bit interleaved one SDO line.
+As such the wiring is the same as `One lane mode`_.
+
+SPI Clock mode
+--------------
+
+Only the SPI clocking mode is supported.
+
+Output modes
+------------
+
+There are more exposed IIO channels than channels as describe in the devices
+datasheet. This is due to the `Differential data + common-mode`_ encoding
+2 types of information in one conversion result. As such a "device" channel
+provides 2 IIO channels, one for the differential data and one for the common
+byte.
+
+Differential data
+^^^^^^^^^^^^^^^^^
+
+This mode is selected when:
+
+- Only differential channels are enabled in a buffered read
+- Oversampling attribute is set to 1
+
+Differential data + common-mode
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This mode is selected when:
+
+- Differential and common-mode channels are enabled in a buffered read
+- Oversampling attribute is set to 1
+
+For the 24-bits chips, this mode is also available with 16-bits differential
+data but is not selectable yet.
+
+Averaged differential data
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This mode is selected when:
+
+- Only differential channels are selected enabled in a buffered read
+- Oversampling attribute is greater than 1
+
+Digital Gain and Offset
+-----------------------
+
+Each differential data channel has a 16-bits unsigned configurable hardware
+gain applied to it. By default it's equal to 1. Note that applying gain can
+cause numerical saturation.
+
+Each differential data channel has a signed configurable hardware offset.
+For the ADCs ending in ``-24``, the gain is encoded on 24-bits.
+Likewise, the ADCs ending in ``-16`` have a gain encoded on 16-bits. Note that
+applying an offset can cause numerical saturation.
+
+The final differential data returned by the ADC is computed by first applying
+the gain, then the offset.
+
+The gain is controlled by the ``calibscale`` IIO attribute while the offset is
+controlled by the ``calibbias`` attribute.
+
+Reference voltage
+-----------------
+
+The chip supports an external reference voltage via the ``REF`` input or an
+internal buffered reference voltage via the ``REFIN`` input. The driver looks
+at the device tree to determine which is being used. If ``ref-supply`` is
+present, then the external reference voltage is used and the internal buffer is
+disabled. If ``refin-supply`` is present, then the internal buffered reference
+voltage is used.
+
+Reset
+-----
+
+Both hardware and software reset are supported. The driver looks first at the
+device tree to see if the ``reset-gpio`` is populated.
+If not present, the driver will fallback to a software reset by wiring to the
+device's registers.
+
+Unimplemented features
+----------------------
+
+- ``BUSY`` indication
+- Additional wiring modes
+- Additional clock modes
+- Differential data 16-bits + common-mode for 24-bits chips
+- Overrange events
+- Test patterns
diff --git a/Documentation/iio/ad4695.rst b/Documentation/iio/ad4695.rst
new file mode 100644
index 000000000000..f40593bcc37d
--- /dev/null
+++ b/Documentation/iio/ad4695.rst
@@ -0,0 +1,269 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD4695 driver
+=============
+
+ADC driver for Analog Devices Inc. AD4695 and similar devices. The module name
+is ``ad4695``.
+
+
+Supported devices
+=================
+
+The following chips are supported by this driver:
+
+* `AD4695 <https://www.analog.com/AD4695>`_
+* `AD4696 <https://www.analog.com/AD4696>`_
+* `AD4697 <https://www.analog.com/AD4697>`_
+* `AD4698 <https://www.analog.com/AD4698>`_
+
+
+Supported features
+==================
+
+SPI wiring modes
+----------------
+
+The driver currently supports the following SPI wiring configuration:
+
+4-wire mode
+^^^^^^^^^^^
+
+In this mode, CNV and CS are tied together and there is a single SDO line.
+
+.. code-block::
+
+ +-------------+ +-------------+
+ | CS |<-+------| CS |
+ | CNV |<-+ | |
+ | ADC | | HOST |
+ | | | |
+ | SDI |<--------| SDO |
+ | SDO |-------->| SDI |
+ | SCLK |<--------| SCLK |
+ +-------------+ +-------------+
+
+To use this mode, in the device tree, omit the ``cnv-gpios`` and
+``spi-rx-bus-width`` properties.
+
+SPI offload wiring
+^^^^^^^^^^^^^^^^^^
+
+When used with a SPI offload, the supported wiring configuration is:
+
+.. code-block::
+
+ +-------------+ +-------------+
+ | GP0/BUSY |-------->| TRIGGER |
+ | CS |<--------| CS |
+ | | | |
+ | ADC | | SPI |
+ | | | |
+ | SDI |<--------| SDO |
+ | SDO |-------->| SDI |
+ | SCLK |<--------| SCLK |
+ | | | |
+ | | +-------------+
+ | CNV |<-----+--| PWM |
+ | | +--| GPIO |
+ +-------------+ +-------------+
+
+In this case, both the ``cnv-gpios`` and ``pwms`` properties are required.
+The ``#trigger-source-cells = <2>`` property is also required to connect back
+to the SPI offload. The SPI offload will have ``trigger-sources`` property
+with cells to indicate the busy signal and which GPx pin is used, e.g
+``<&ad4695 AD4695_TRIGGER_EVENT_BUSY AD4695_TRIGGER_PIN_GP0>``.
+
+.. seealso:: `SPI offload support`_
+
+Channel configuration
+---------------------
+
+Since the chip supports multiple ways to configure each channel, this must be
+described in the device tree based on what is actually wired up to the inputs.
+
+There are three typical configurations:
+
+An ``INx`` pin is used as the positive input with the ``REFGND``, ``COM`` or
+the next ``INx`` pin as the negative input.
+
+Pairing with REFGND
+^^^^^^^^^^^^^^^^^^^
+
+Each ``INx`` pin can be used as a pseudo-differential input in conjunction with
+the ``REFGND`` pin. The device tree will look like this:
+
+.. code-block::
+
+ channel@0 {
+ reg = <0>; /* IN0 */
+ };
+
+If no other channel properties are needed (e.g. ``adi,no-high-z``), the channel
+node can be omitted entirely.
+
+This will appear on the IIO bus as the ``voltage0`` channel. The processed value
+(*raw × scale*) will be the voltage present on the ``IN0`` pin relative to
+``REFGND``. (Offset is always 0 when pairing with ``REFGND``.)
+
+Pairing with COM
+^^^^^^^^^^^^^^^^
+
+Each ``INx`` pin can be used as a pseudo-differential input in conjunction with
+the ``COM`` pin. The device tree will look like this:
+
+.. code-block::
+
+ com-supply = <&vref_div_2>;
+
+ channel@1 {
+ reg = <1>; /* IN1 */
+ common-mode-channel = <AD4695_COMMON_MODE_COM>;
+ bipolar;
+ };
+
+This will appear on the IIO bus as the ``voltage1`` channel. The processed value
+(*(raw + offset) × scale*) will be the voltage measured on the ``IN1`` pin
+relative to ``REFGND``. (The offset is determined by the ``com-supply`` voltage.)
+
+The macro comes from:
+
+.. code-block::
+
+ #include <dt-bindings/iio/adc/adi,ad4695.h>
+
+Pairing two INx pins
+^^^^^^^^^^^^^^^^^^^^
+
+An even-numbered ``INx`` pin and the following odd-numbered ``INx`` pin can be
+used as a pseudo-differential input. The device tree for using ``IN2`` as the
+positive input and ``IN3`` as the negative input will look like this:
+
+.. code-block::
+
+ in3-supply = <&vref_div_2>;
+
+ channel@2 {
+ reg = <2>; /* IN2 */
+ common-mode-channel = <3>; /* IN3 */
+ bipolar;
+ };
+
+This will appear on the IIO bus as the ``voltage2`` channel. The processed value
+(*(raw + offset) × scale*) will be the voltage measured on the ``IN1`` pin
+relative to ``REFGND``. (Offset is determined by the ``in3-supply`` voltage.)
+
+VCC supply
+----------
+
+The chip supports being powered by an external LDO via the ``VCC`` input or an
+internal LDO via the ``LDO_IN`` input. The driver looks at the device tree to
+determine which is being used. If ``ldo-supply`` is present, then the internal
+LDO is used. If ``vcc-supply`` is present, then the external LDO is used and
+the internal LDO is disabled.
+
+Reference voltage
+-----------------
+
+The chip supports an external reference voltage via the ``REF`` input or an
+internal buffered reference voltage via the ``REFIN`` input. The driver looks
+at the device tree to determine which is being used. If ``ref-supply`` is
+present, then the external reference voltage is used and the internal buffer is
+disabled. If ``refin-supply`` is present, then the internal buffered reference
+voltage is used.
+
+Gain/offset calibration
+-----------------------
+
+System calibration is supported using the channel gain and offset registers via
+the ``calibscale`` and ``calibbias`` attributes respectively.
+
+Oversampling
+------------
+
+The chip supports per-channel oversampling when SPI offload is being used, with
+available oversampling ratios (OSR) of 1 (default), 4, 16, and 64. Enabling
+oversampling on a channel raises the effective number of bits of sampled data to
+17 (OSR == 4), 18 (16), or 19 (64), respectively. This can be set via the
+``oversampling_ratio`` attribute.
+
+Setting the oversampling ratio for a channel also changes the sample rate for
+that channel, since it requires multiple conversions per 1 sample. Specifically,
+the new sampling frequency is the PWM sampling frequency divided by the
+particular OSR. This is set automatically by the driver when setting the
+``oversampling_ratio`` attribute. For example, if the device's current
+``sampling_frequency`` is 10000 and an OSR of 4 is set on channel ``voltage0``,
+the new reported sampling rate for that channel will be 2500 (ignoring PWM API
+rounding), while all others will remain at 10000. Subsequently setting the
+sampling frequency to a higher value on that channel will adjust the CNV trigger
+period for all channels, e.g. if ``voltage0``'s sampling frequency is adjusted
+from 2500 (with an OSR of 4) to 10000, the value reported by
+``in_voltage0_sampling_frequency`` will be 10000, but all other channels will
+now report 40000.
+
+For simplicity, the sampling frequency of the device should be set (considering
+the highest desired OSR value to be used) first, before configuring oversampling
+for specific channels.
+
+Unimplemented features
+----------------------
+
+- Additional wiring modes
+- Threshold events
+- GPIO support
+- CRC support
+
+SPI offload support
+===================
+
+To be able to achieve the maximum sample rate, the driver can be used with the
+`AXI SPI Engine`_ to provide SPI offload support.
+
+.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/ad469x_fmc/index.html
+
+.. seealso:: `SPI offload wiring`_
+
+When SPI offload is being used, some attributes will be different.
+
+* ``trigger`` directory is removed.
+* ``in_voltage0_sampling_frequency`` attributes are added for setting the sample
+ rate.
+* ``in_voltage0_sampling_frequency_available`` attributes are added for querying
+ the max sample rate.
+* ``timestamp`` channel is removed.
+* Buffer data format may be different compared to when offload is not used,
+ e.g. the ``buffer0/in_voltage0_type`` attribute.
+
+Device buffers
+==============
+
+This driver supports hardware triggered buffers. This uses the "advanced
+sequencer" feature of the chip to trigger a burst of conversions.
+
+Also see :doc:`iio_devbuf` for more general information.
+
+Effective sample rate for buffered reads
+----------------------------------------
+
+When SPI offload is not used, the sample rate is determined by the trigger that
+is manually configured in userspace. All enabled channels will be read in a
+burst when the trigger is received.
+
+When SPI offload is used, the sample rate is configured per channel. All
+channels will have the same rate, so only one ``in_voltageY_sampling_frequency``
+attribute needs to be set. Since this rate determines the delay between each
+individual conversion, the effective sample rate for each sample is actually
+the sum of the periods of each enabled channel in a buffered read. In other
+words, it is the value of the ``in_voltageY_sampling_frequency`` attribute
+divided by the number of enabled channels. So if 4 channels are enabled, with
+the ``in_voltageY_sampling_frequency`` attributes set to 1 MHz, the effective
+sample rate is 250 kHz.
+
+With oversampling enabled, the effective sample rate also depends on the OSR
+assigned to each channel. For example, if one of the 4 channels mentioned in the
+previous case is configured with an OSR of 4, the effective sample rate for that
+channel becomes (1 MHz / 4 ) = 250 kHz. The effective sample rate for all
+four channels is then 1 / ( (3 / 1 MHz) + ( 1 / 250 kHz) ) ~= 142.9 kHz. Note
+that in this case "sample" refers to one read of all enabled channels (i.e. one
+full cycle through the auto-sequencer).
diff --git a/Documentation/iio/ad7191.rst b/Documentation/iio/ad7191.rst
new file mode 100644
index 000000000000..977d4fea14b0
--- /dev/null
+++ b/Documentation/iio/ad7191.rst
@@ -0,0 +1,119 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD7191 driver
+=============
+
+Device driver for Analog Devices AD7191 ADC.
+
+Supported devices
+=================
+
+* `AD7191 <https://www.analog.com/AD7191>`_
+
+The AD7191 is a high precision, low noise, 24-bit Σ-Δ ADC with integrated PGA.
+It features two differential input channels, an internal temperature sensor, and
+configurable sampling rates.
+
+Devicetree
+==========
+
+Pin Configuration
+-----------------
+
+The driver supports both pin-strapped and GPIO-controlled configurations for ODR
+(Output Data Rate) and PGA (Programmable Gain Amplifier) settings. These
+configurations are mutually exclusive - you must use either pin-strapped or GPIO
+control for each setting, not both.
+
+ODR Configuration
+^^^^^^^^^^^^^^^^^
+
+The ODR can be configured either through GPIO control or pin-strapping:
+
+- When using GPIO control, specify the "odr-gpios" property in the device tree
+- For pin-strapped configuration, specify the "adi,odr-value" property in the
+ device tree
+
+Available ODR settings:
+
+ - 120 Hz (ODR1=0, ODR2=0)
+ - 60 Hz (ODR1=0, ODR2=1)
+ - 50 Hz (ODR1=1, ODR2=0)
+ - 10 Hz (ODR1=1, ODR2=1)
+
+PGA Configuration
+^^^^^^^^^^^^^^^^^
+
+The PGA can be configured either through GPIO control or pin-strapping:
+
+- When using GPIO control, specify the "pga-gpios" property in the device tree
+- For pin-strapped configuration, specify the "adi,pga-value" property in the
+ device tree
+
+Available PGA gain settings:
+
+ - 1x (PGA1=0, PGA2=0)
+ - 8x (PGA1=0, PGA2=1)
+ - 64x (PGA1=1, PGA2=0)
+ - 128x (PGA1=1, PGA2=1)
+
+Clock Configuration
+-------------------
+
+The AD7191 supports both internal and external clock sources:
+
+- When CLKSEL pin is tied LOW: Uses internal 4.92MHz clock (no clock property
+ needed)
+- When CLKSEL pin is tied HIGH: Requires external clock source
+ - Can be a crystal between MCLK1 and MCLK2 pins
+ - Or a CMOS-compatible clock driving MCLK2 pin
+ - Must specify the "clocks" property in device tree when using external clock
+
+SPI Interface Requirements
+--------------------------
+
+The AD7191 has specific SPI interface requirements:
+
+- The DOUT/RDY output is dual-purpose and requires SPI bus locking
+- DOUT/RDY must be connected to an interrupt-capable GPIO
+- The SPI controller's chip select must be connected to the PDOWN pin of the ADC
+- When CS (PDOWN) is high, the device powers down and resets internal circuitry
+- SPI mode 3 operation (CPOL=1, CPHA=1) is required
+
+Power Supply Requirements
+-------------------------
+
+The device requires the following power supplies:
+
+- AVdd: Analog power supply
+- DVdd: Digital power supply
+- Vref: Reference voltage supply (external)
+
+All power supplies must be specified in the device tree.
+
+Channel Configuration
+=====================
+
+The device provides three channels:
+
+1. Temperature Sensor
+ - 24-bit unsigned
+ - Internal temperature measurement
+ - Temperature in millidegrees Celsius
+
+2. Differential Input (AIN1-AIN2)
+ - 24-bit unsigned
+ - Differential voltage measurement
+ - Configurable gain via PGA
+
+3. Differential Input (AIN3-AIN4)
+ - 24-bit unsigned
+ - Differential voltage measurement
+ - Configurable gain via PGA
+
+Buffer Support
+==============
+
+This driver supports IIO triggered buffers. See Documentation/iio/iio_devbuf.rst
+for more information about IIO triggered buffers.
diff --git a/Documentation/iio/ad7380.rst b/Documentation/iio/ad7380.rst
new file mode 100644
index 000000000000..d51f9ee3e939
--- /dev/null
+++ b/Documentation/iio/ad7380.rst
@@ -0,0 +1,212 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD7380 driver
+=============
+
+ADC driver for Analog Devices Inc. AD7380 and similar devices. The module name
+is ``ad7380``.
+
+
+Supported devices
+=================
+
+The following chips are supported by this driver:
+
+* `AD7380 <https://www.analog.com/en/products/ad7380.html>`_
+* `AD7381 <https://www.analog.com/en/products/ad7381.html>`_
+* `AD7383 <https://www.analog.com/en/products/ad7383.html>`_
+* `AD7384 <https://www.analog.com/en/products/ad7384.html>`_
+* `AD7386 <https://www.analog.com/en/products/ad7386.html>`_
+* `AD7387 <https://www.analog.com/en/products/ad7387.html>`_
+* `AD7388 <https://www.analog.com/en/products/ad7388.html>`_
+* `AD7380-4 <https://www.analog.com/en/products/ad7380-4.html>`_
+* `AD7381-4 <https://www.analog.com/en/products/ad7381-4.html>`_
+* `AD7383-4 <https://www.analog.com/en/products/ad7383-4.html>`_
+* `AD7384-4 <https://www.analog.com/en/products/ad7384-4.html>`_
+* `AD7386-4 <https://www.analog.com/en/products/ad7386-4.html>`_
+* `AD7387-4 <https://www.analog.com/en/products/ad7387-4.html>`_
+* `AD7388-4 <https://www.analog.com/en/products/ad7388-4.html>`_
+* `AD7389-4 <https://www.analog.com/en/products/ad7389-4.html>`_
+* `ADAQ4370-4 <https://www.analog.com/en/products/adaq4370-4.html>`_
+* `ADAQ4380-4 <https://www.analog.com/en/products/adaq4380-4.html>`_
+* `ADAQ4381-4 <https://www.analog.com/en/products/adaq4381-4.html>`_
+
+
+Supported features
+==================
+
+SPI wiring modes
+----------------
+
+ad738x ADCs can output data on several SDO lines (1/2/4). The driver currently
+supports only 1 SDO line.
+
+Reference voltage
+-----------------
+
+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``.
+
+ad7389-4
+~~~~~~~~
+
+ad7389-4 supports only an internal reference voltage. ``refin-supply`` and
+``refio-supply`` properties are both omitted in this case.
+
+ADAQ devices
+~~~~~~~~~~~~
+
+ADAQ devices don't have an external reference, but use a 3.3V internal reference
+derived from one of its supplies (``refin-supply``)
+
+All other devices from ad738x family
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All other devices from ad738x support 2 possible reference voltage sources:
+
+- Internal reference (2.5V)
+- External reference (2.5V to 3.3V)
+
+The source is determined by the device tree. If ``refio-supply`` is present,
+then it is used as external reference, else the internal reference is used.
+
+Oversampling and resolution boost
+---------------------------------
+
+This family supports 2 types of oversampling: normal average and rolling
+average. Only normal average is supported by the driver, as rolling average can
+be achieved by processing a captured data buffer. The following ratios are
+available: 1 (oversampling disabled)/2/4/8/16/32.
+
+When the on-chip oversampling function is enabled the performance of the ADC can
+exceed the default resolution. To accommodate the performance boost achievable,
+it is possible to enable an additional two bits of resolution. Because the
+resolution boost feature can only be enabled when oversampling is enabled and
+oversampling is not as useful without the resolution boost, the driver
+automatically enables the resolution boost if and only if oversampling is
+enabled.
+
+Since the resolution boost feature causes 16-bit chips to now have 18-bit data
+which means the storagebits has to change from 16 to 32 bits, we use the new
+ext_scan_type feature to allow changing the scan_type at runtime. Unfortunately
+libiio does not support it. So when enabling or disabling oversampling, user
+must restart iiod using the following command:
+
+.. code-block:: bash
+
+ root:~# systemctl restart iiod
+
+Alert
+-----
+
+2 channels variants of the ad738x family, can use the SDOB line as an alert pin
+when configured in 1 SDO line mode. 4 channels variants, can use SDOD as an
+alert pin when configured in 1 or 2 SDO line(s) mode, although only 1 SDO line
+mode is currently supported by the driver (see `SPI wiring modes`_).
+
+At the end of a conversion the active-low alert pin gets asserted if the
+conversion result exceeds the alert high limit or falls below the alert low
+limit. It is cleared, on a falling edge of CS. The alert pin is common to all
+channels.
+
+User can enable alert using the regular iio events attribute:
+
+.. code-block:: bash
+
+ events/thresh_either_en
+
+The high and low thresholds are common to all channels and can also be set using
+regular iio events attributes:
+
+.. code-block:: bash
+
+ events/in_thresh_falling_value
+ events/in_thresh_rising_value
+
+If debugfs is available, user can read the ALERT register to determine the
+faulty channel and direction.
+
+In most use cases, user will hardwire the alert pin to trigger a shutdown.
+
+Channel selection and sequencer (single-end chips only)
+-------------------------------------------------------
+
+Single-ended chips of this family (ad7386/7/8(-4)) have a 2:1 multiplexer in
+front of each ADC. They also include additional configuration registers that
+allow for either manual selection or automatic switching (sequencer mode), of
+the multiplexer inputs.
+
+From an IIO point of view, all inputs are exported, i.e ad7386/7/8
+export 4 channels and ad7386-4/7-4/8-4 export 8 channels.
+
+Inputs ``AinX0`` of multiplexers correspond to the first half of IIO channels (i.e
+0-1 or 0-3) and inputs ``AinX1`` correspond to second half (i.e 2-3 or 4-7).
+Example for AD7386/7/8 (2 channels parts):
+
+.. code-block::
+
+ IIO | AD7386/7/8
+ | +----------------------------
+ | | _____ ______
+ | | | | | |
+ voltage0 | AinA0 --|--->| | | |
+ | | | mux |----->| ADCA |---
+ voltage2 | AinA1 --|--->| | | |
+ | | |_____| |_____ |
+ | | _____ ______
+ | | | | | |
+ voltage1 | AinB0 --|--->| | | |
+ | | | mux |----->| ADCB |---
+ voltage3 | AinB1 --|--->| | | |
+ | | |_____| |______|
+ | |
+ | +----------------------------
+
+
+When enabling sequencer mode, the effective sampling rate is divided by two.
+
+Gain (ADAQ devices only)
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+ADAQ devices have a pin selectable gain in front of each ADC. The appropriate
+gain is selectable from device tree using the ``adi,gain-milli`` property.
+Refer to the typical connection diagrams section of the datasheet for pin
+wiring.
+
+Unimplemented features
+----------------------
+
+- 2/4 SDO lines
+- Rolling average oversampling
+- Power down mode
+- CRC indication
+
+SPI offload support
+===================
+
+To be able to achieve the maximum sample rate, the driver can be used with the
+`AXI SPI Engine`_ to provide SPI offload support.
+
+.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/pulsar_adc/index.html
+
+When SPI offload is being used, some attributes will be different.
+
+* ``trigger`` directory is removed.
+* ``in_voltage0_sampling_frequency`` attribute is added for setting the sample
+ rate.
+* ``in_voltage0_sampling_frequency_available`` attribute is added for querying
+ the max sample rate.
+* ``timestamp`` channel is removed.
+* Buffer data format may be different compared to when offload is not used,
+ e.g. the ``in_voltage0_type`` attribute.
+
+Device buffers
+==============
+
+This driver supports IIO triggered buffers.
+
+See :doc:`iio_devbuf` for more information.
diff --git a/Documentation/iio/ad7606.rst b/Documentation/iio/ad7606.rst
new file mode 100644
index 000000000000..5e02516bab40
--- /dev/null
+++ b/Documentation/iio/ad7606.rst
@@ -0,0 +1,189 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD7606 driver
+=============
+
+ADC driver for Analog Devices Inc. AD7606 and similar devices. The module name
+is ``ad7606``.
+
+Supported devices
+=================
+
+The following chips are supported by this driver:
+
+* `AD7605 <https://www.analog.com/en/products/ad7605.html>`_
+* `AD7606 <https://www.analog.com/en/products/ad7606.html>`_
+* `AD7606B <https://www.analog.com/en/products/ad7606b.html>`_
+* `AD7616 <https://www.analog.com/en/products/ad7616.html>`_
+
+Supported features
+==================
+
+SPI wiring modes
+----------------
+
+These ADCs can output data on several SDO lines (1/2/4/8). The driver
+currently supports only 1 SDO line.
+
+SPI offload wiring
+------------------
+When used with a SPI offload, the supported wiring configuration is:
+
+.. code-block::
+
+ +-------------+ +-------------+
+ | BUSY |-------->| TRIGGER |
+ | CS |<--------| CS |
+ | | | |
+ | ADC | | SPI |
+ | | | |
+ | SDI |<--------| SDO |
+ | DOUTA |-------->| SDI |
+ | SCLK |<--------| SCLK |
+ | | | |
+ | | +-------------+
+ | CONVST |<--------| PWM |
+ +-------------+ +-------------+
+
+In this case, the ``pwms`` property is required.
+The ``#trigger-source-cells = <1>`` property is also required to connect back
+to the SPI offload. The SPI offload will have ``trigger-sources`` property
+with a cell to indicate the busy signal:
+``<&ad7606 AD4695_TRIGGER_EVENT_BUSY>``.
+
+.. seealso:: `SPI offload support`_
+
+
+Parallel wiring mode
+--------------------
+
+There is also a parallel interface, with 16 lines (that can be reduced to 8 in
+byte mode). The parallel interface is selected by declaring the device as
+platform in the device tree (with no io-backends node defined, see below).
+
+IIO-backend mode
+----------------
+
+This mode allows to reach the best sample rates, but it requires an external
+hardware (eg HDL or APU) to handle the low level communication.
+The backend mode is enabled when through the definition of the "io-backends"
+property in the device tree.
+
+The reference configuration for the current implementation of IIO-backend mode
+is the HDL reference provided by ADI:
+https://wiki.analog.com/resources/eval/user-guides/ad7606x-fmc/hdl
+
+This implementation embeds an IIO-backend compatible IP (adi-axi-adc) and a PWM
+connected to the conversion trigger pin.
+
+.. code-block::
+
+ +---+ +----------------------------
+ | | +-------+ |AD76xx
+ | A | controls | | |
+ | D |-------------->| PWM |-------------->| cnvst
+ | 7 | | | |
+ | 6 | +-------+ |
+ | 0 | controls +-----------+-----------+ |
+ | 6 |---------->| | |<--| frstdata
+ | | | Backend | Backend |<--| busy
+ | D | | Driver | | |
+ | R | | | |-->| clk
+ | I | requests |+---------+| DMA | |
+ | V |----------->| Buffer ||<---- |<=>| DATA
+ | E | |+---------+| | |
+ | R | +-----------+-----------+ |
+ | |-------------------------------------->| reset/configuration gpios
+ +---+ +-----------------------------
+
+
+Software and hardware modes
+---------------------------
+
+While all the AD7606/AD7616 series parts can be configured using GPIOs, some of
+them can be configured using register.
+
+The chips that support software mode have more values available for configuring
+the device, as well as more settings, and allow to control the range and
+calibration per channel.
+
+The following settings are available per channel in software mode:
+ - Scale
+
+Also, there is a broader choice of oversampling ratios in software mode.
+
+Conversion triggering
+---------------------
+
+The conversion can be triggered by two distinct ways:
+
+ - A GPIO is connected to the conversion trigger pin, and this GPIO is controlled
+ by the driver directly. In this configuration, the driver sets back the
+ conversion trigger pin to high as soon as it has read all the conversions.
+
+ - An external source is connected to the conversion trigger pin. In the
+ current implementation, it must be a PWM. In this configuration, the driver
+ does not control directly the conversion trigger pin. Instead, it can
+ control the PWM's frequency. This trigger is enabled only for iio-backend.
+
+Reference voltage
+-----------------
+
+2 possible reference voltage sources are supported:
+
+ - Internal reference (2.5V)
+ - External reference (2.5V)
+
+The source is determined by the device tree. If ``refin-supply`` is present,
+then the external reference is used, otherwise the internal reference is used.
+
+Oversampling
+------------
+
+This family supports oversampling to improve SNR.
+In software mode, the following ratios are available:
+1 (oversampling disabled)/2/4/8/16/32/64/128/256.
+
+Unimplemented features
+----------------------
+
+- 2/4/8 SDO lines
+- CRC indication
+- Calibration
+
+SPI offload support
+===================
+
+To be able to achieve the maximum sample rate, the driver can be used with the
+`AXI SPI Engine`_ to provide SPI offload support.
+
+.. _AXI SPI Engine: https://analogdevicesinc.github.io/hdl/library/spi_engine/index.html
+
+When SPI offload is being used, some attributes will be different.
+
+* ``trigger`` directory is removed.
+* ``sampling_frequency`` attribute is added for setting the sample rate.
+* ``timestamp`` channel is removed.
+* Buffer data format may be different compared to when offload is not used,
+ e.g. the ``in_voltage0_type`` attribute.
+
+Device buffers
+==============
+
+IIO triggered buffer
+--------------------
+
+This driver supports IIO triggered buffers, with a "built in" trigger, i.e the
+trigger is allocated and linked by the driver, and a new conversion is triggered
+as soon as the samples are transferred, and a timestamp channel is added to make
+up for the potential jitter induced by the delays in the interrupt handling.
+
+IIO backend buffer
+------------------
+
+When IIO backend is used, the trigger is not needed, and the sample rate is
+considered as stable. There is no timestamp channel. The communication is
+delegated to an external logic, called a backend, and the backend's driver
+handles the buffer. When this mode is enabled, the driver cannot control the
+conversion pin, because the busy pin is bound to the backend.
diff --git a/Documentation/iio/ad7625.rst b/Documentation/iio/ad7625.rst
new file mode 100644
index 000000000000..61761e3b75c3
--- /dev/null
+++ b/Documentation/iio/ad7625.rst
@@ -0,0 +1,91 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+====================
+AD7625 driver
+====================
+
+ADC driver for Analog Devices Inc. AD7625, AD7626, AD7960, and AD7961
+devices. The module name is ``ad7625``.
+
+Supported devices
+=================
+
+The following chips are supported by this driver:
+
+* `AD7625 <https://www.analog.com/AD7625>`_
+* `AD7626 <https://www.analog.com/AD7626>`_
+* `AD7960 <https://www.analog.com/AD7960>`_
+* `AD7961 <https://www.analog.com/AD7961>`_
+
+The driver requires use of the Pulsar LVDS HDL project:
+
+* `Pulsar LVDS HDL <http://analogdevicesinc.github.io/hdl/projects/pulsar_lvds/index.html>`_
+
+To trigger conversions and enable subsequent data transfer, the devices
+require coupled PWM signals with a phase offset.
+
+Supported features
+==================
+
+Conversion control modes
+------------------------
+
+The driver currently supports one of two possible LVDS conversion control methods.
+
+Echoed-Clock interface mode
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block::
+
+ +----------------+
+ +xxxxxxxxxxxxxxxxxxxxxxxxxx| CNV |
+ X | |
+ v | HOST |
+ +----------------------------+ | |
+ | CNV+/CNV- DCO+/DCO- |xxxxxxx>| CLK_IN |
+ | | | |
+ | | | |
+ | AD7625 D+/D- |xxxxxxx>| DATA_IN |
+ | | | |
+ | | | |
+ | CLK+/CLK- |<xxxxxxx| CLK & CLK_GATE |
+ +----------------------------+ | |
+ +----------------+
+
+Reference voltage
+-----------------
+
+Three possible reference voltage sources are supported:
+
+- Internal reference (only available on AD7625 and AD7626)
+- External reference and internal buffer
+- External reference
+
+The source is determined by the device tree. If ``ref-supply`` is present, then
+the external reference is used. If ``refin-supply`` is present, then the internal
+buffer is used. If neither is present, then the internal reference is used.
+
+Unimplemented features
+----------------------
+
+- Self-clocked mode
+
+
+Device attributes
+=================
+
+The AD762x is a fully-differential ADC and has the following attributes:
+
++---------------------------------------+--------------------------------------------------------------+
+| Attribute | Description |
++=======================================+==============================================================+
+| ``scale`` | Scale factor to convert raw value from buffered reads to mV. |
++---------------------------------------+--------------------------------------------------------------+
+
+
+Device buffers
+==============
+
+This driver supports IIO triggered buffers.
+
+See :doc:`iio_devbuf` for more information.
diff --git a/Documentation/iio/ad7944.rst b/Documentation/iio/ad7944.rst
new file mode 100644
index 000000000000..e6dbe4d7f58c
--- /dev/null
+++ b/Documentation/iio/ad7944.rst
@@ -0,0 +1,178 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD7944 driver
+=============
+
+ADC driver for Analog Devices Inc. AD7944 and similar devices. The module name
+is ``ad7944``.
+
+
+Supported devices
+=================
+
+The following chips are supported by this driver:
+
+* `AD7944 <https://www.analog.com/AD7944>`_
+* `AD7985 <https://www.analog.com/AD7985>`_
+* `AD7986 <https://www.analog.com/AD7986>`_
+
+
+Supported features
+==================
+
+SPI wiring modes
+----------------
+
+The driver currently supports three of the many possible SPI wiring configurations.
+
+CS mode, 3-wire, without busy indicator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block::
+
+ +-------------+
+ +--------------------| CS |
+ v | |
+ VIO +--------------------+ | HOST |
+ | | CNV | | |
+ +--->| SDI AD7944 SDO |-------->| SDI |
+ | SCK | | |
+ +--------------------+ | |
+ ^ | |
+ +--------------------| SCLK |
+ +-------------+
+
+To select this mode in the device tree, set the ``adi,spi-mode`` property to
+``"single"`` and omit the ``cnv-gpios`` property.
+
+This is the only wiring configuration supported when using `SPI offload support`_.
+
+CS mode, 4-wire, without busy indicator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block::
+
+ +-------------+
+ +-----------------------------------| CS |
+ | | |
+ | +--------------------| GPIO |
+ | v | |
+ | +--------------------+ | HOST |
+ | | CNV | | |
+ +--->| SDI AD7944 SDO |-------->| SDI |
+ | SCK | | |
+ +--------------------+ | |
+ ^ | |
+ +--------------------| SCLK |
+ +-------------+
+
+To select this mode in the device tree, omit the ``adi,spi-mode`` property and
+provide the ``cnv-gpios`` property.
+
+Chain mode, without busy indicator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block::
+
+ +-------------+
+ +-------------------------+--------------------| CS |
+ v v | |
+ +--------------------+ +--------------------+ | HOST |
+ | CNV | | CNV | | |
+ +--->| SDI AD7944 SDO |--->| SDI AD7944 SDO |-------->| SDI |
+ | | SCK | | SCK | | |
+ GND +--------------------+ +--------------------+ | |
+ ^ ^ | |
+ +-------------------------+--------------------| SCLK |
+ +-------------+
+
+To select this mode in the device tree, set the ``adi,spi-mode`` property to
+``"chain"``, add the ``spi-cs-high`` flag, add the ``#daisy-chained-devices``
+property, and omit the ``cnv-gpios`` property.
+
+Reference voltage
+-----------------
+
+All 3 possible reference voltage sources are supported:
+
+- Internal reference
+- External 1.2V reference and internal buffer
+- External reference
+
+The source is determined by the device tree. If ``ref-supply`` is present, then
+the external reference is used. If ``refin-supply`` is present, then the internal
+buffer is used. If neither is present, then the internal reference is used.
+
+Unimplemented features
+----------------------
+
+- ``BUSY`` indication
+
+
+Device attributes
+=================
+
+There are two types of ADCs in this family, pseudo-differential and fully
+differential. The channel name is different depending on the type of ADC.
+
+Pseudo-differential ADCs
+------------------------
+
+AD7944 and AD7985 are pseudo-differential ADCs and have the following attributes:
+
++---------------------------------------+--------------------------------------------------------------+
+| Attribute | Description |
++=======================================+==============================================================+
+| ``in_voltage0_raw`` | Raw ADC voltage value (*IN+* referenced to ground sense). |
++---------------------------------------+--------------------------------------------------------------+
+| ``in_voltage0_scale`` | Scale factor to convert raw value to mV. |
++---------------------------------------+--------------------------------------------------------------+
+
+In "chain" mode, additional chips will appear as additional voltage input
+channels, e.g. ``in_voltage1_raw``.
+
+Fully-differential ADCs
+-----------------------
+
+AD7986 is a fully-differential ADC and has the following attributes:
+
++---------------------------------------+--------------------------------------------------------------+
+| Attribute | Description |
++=======================================+==============================================================+
+| ``in_voltage0-voltage1_raw`` | Raw ADC voltage value (*IN+* - *IN-*). |
++---------------------------------------+--------------------------------------------------------------+
+| ``in_voltage0-voltage1_scale`` | Scale factor to convert raw value to mV. |
++---------------------------------------+--------------------------------------------------------------+
+
+In "chain" mode, additional chips will appear as additional voltage input
+channels, e.g. ``in_voltage2-voltage3_raw``.
+
+SPI offload support
+===================
+
+To be able to achieve the maximum sample rate, the driver can be used with the
+`AXI SPI Engine`_ to provide SPI offload support.
+
+.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/pulsar_adc/index.html
+
+When SPI offload is being used, some attributes will be different.
+
+* ``trigger`` directory is removed.
+* ``in_voltage0_sampling_frequency`` attribute is added for setting the sample
+ rate.
+* ``in_voltage0_sampling_frequency_available`` attribute is added for querying
+ the max sample rate.
+* ``timestamp`` channel is removed.
+* Buffer data format may be different compared to when offload is not used,
+ e.g. the ``in_voltage0_type`` attribute.
+
+If the ``turbo-gpios`` property is present in the device tree, the driver will
+turn on TURBO during buffered reads and turn it off otherwise.
+
+Device buffers
+==============
+
+This driver supports IIO triggered buffers.
+
+See :doc:`iio_devbuf` for more information.
diff --git a/Documentation/iio/ade9000.rst b/Documentation/iio/ade9000.rst
new file mode 100644
index 000000000000..c9ff702a4251
--- /dev/null
+++ b/Documentation/iio/ade9000.rst
@@ -0,0 +1,268 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+ADE9000 driver
+===============
+
+This driver supports Analog Device's ADE9000 energy measurement IC on SPI bus.
+
+1. Supported devices
+====================
+
+* `ADE9000 <https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9000.pdf>`_
+
+The ADE9000 is a highly accurate, fully integrated, multiphase energy and power
+quality monitoring device. Superior analog performance and a digital signal
+processing (DSP) core enable accurate energy monitoring over a wide dynamic
+range. An integrated high end reference ensures low drift over temperature
+with a combined drift of less than ±25 ppm/°C maximum for the entire channel
+including a programmable gain amplifier (PGA) and an analog-to-digital
+converter (ADC).
+
+2. Device attributes
+====================
+
+Power and energy measurements are provided for voltage, current, active power,
+reactive power, apparent power, and power factor across three phases.
+
+Each IIO device has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in question. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following tables show the ADE9000 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
++---------------------------------------------------+----------------------------------------------------------+
+| Current measurement related device files | Description |
++---------------------------------------------------+----------------------------------------------------------+
+| in_current[0-2]_raw | Raw current measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_current[0-2]_scale | Scale for current channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_current[0-2]_calibscale | Calibration gain for current channels (AIGAIN reg). |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altcurrent[0-2]_rms_raw | RMS current measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altcurrent[0-2]_rms_scale | Scale for RMS current channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altcurrent[0-2]_rms_calibbias | RMS offset correction for current channels (IRMSOS reg). |
++---------------------------------------------------+----------------------------------------------------------+
+
++---------------------------------------------------+----------------------------------------------------------+
+| Voltage measurement related device files | Description |
++---------------------------------------------------+----------------------------------------------------------+
+| in_voltage[0-2]_raw | Raw voltage measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_voltage[0-2]_scale | Scale for voltage channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_voltage[0-2]_calibscale | Calibration gain for voltage channels (AVGAIN reg). |
++---------------------------------------------------+----------------------------------------------------------+
+| in_voltage[0-2]_frequency | Measured line frequency from instantaneous voltage. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_raw | RMS voltage measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_scale | Scale for RMS voltage channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_calibbias | RMS offset correction for voltage channels (VRMSOS reg). |
++---------------------------------------------------+----------------------------------------------------------+
+
++---------------------------------------------------+----------------------------------------------------------+
+| Power measurement related device files | Description |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_active_raw | Active power measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_active_scale | Scale for active power channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_active_calibbias | Calibration offset for active power (xWATTOS regs). |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_active_calibscale | Calibration gain for active power (APGAIN reg). |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_reactive_raw | Reactive power measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_reactive_scale | Scale for reactive power channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_reactive_calibbias | Calibration offset for reactive power (xVAROS regs). |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_apparent_raw | Apparent power measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_apparent_scale | Scale for apparent power channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_power[0-2]_powerfactor | Power factor for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+
++---------------------------------------------------+----------------------------------------------------------+
+| Energy measurement related device files | Description |
++---------------------------------------------------+----------------------------------------------------------+
+| in_energy[0-2]_active_raw | Active energy measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_energy[0-2]_reactive_raw | Reactive energy measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_energy[0-2]_apparent_raw | Apparent energy measurement for phases A, B, C. |
++---------------------------------------------------+----------------------------------------------------------+
+
++------------------------------+------------------------------------------------------------------+
+| Shared device attributes | Description |
++------------------------------+------------------------------------------------------------------+
+| name | Name of the IIO device. |
++------------------------------+------------------------------------------------------------------+
+| filter_type | Waveform buffer filter type (sinc4, sinc4+lp). |
++------------------------------+------------------------------------------------------------------+
+| filter_type_available | Available filter types for waveform buffer. |
++------------------------------+------------------------------------------------------------------+
+
+3. Calibration and scaling
+===========================
+
+The ADE9000 provides multiple levels of gain and offset correction:
+
+**Calibration Gain (per-channel)**
+ Fine-tuning calibration gains applied in the digital domain for each channel type.
+ Controlled via ``calibscale`` attributes (AIGAIN, AVGAIN, APGAIN registers).
+
+**Calibration Bias (per-channel)**
+ Hardware calibration offsets applied by the device internally:
+
+ - Power measurements: Controlled via ``calibbias`` attributes for power channels (xWATTOS, xVAROS registers).
+ - RMS measurements: Controlled via ``calibbias`` attributes for RMS channels (IRMSOS, VRMSOS registers).
+
+ These are internal chip calibrations, not userspace-applied offsets.
+
+4. Event attributes
+===================
+
+The ADE9000 provides various interrupts that are mapped to IIO events.
+Event functionality is only available if the corresponding interrupts are
+connected in the device tree.
+
++---------------------------------------------------+----------------------------------------------------------+
+| IIO Event Attribute | ADE9000 Datasheet Equivalent |
++---------------------------------------------------+----------------------------------------------------------+
+| in_voltage[0-2]_thresh_either_en | Zero crossing detection interrupt (ZXVx) |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_thresh_rising_en | RMS swell detection interrupt (SWELLx) |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_thresh_rising_value | RMS swell threshold (SWELL_LVL register) |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_thresh_falling_en | RMS sag/dip detection interrupt (DIPx) |
++---------------------------------------------------+----------------------------------------------------------+
+| in_altvoltage[0-2]_rms_thresh_falling_value | RMS sag/dip threshold (DIP_LVL register) |
++---------------------------------------------------+----------------------------------------------------------+
+| in_current[0-2]_thresh_either_en | Current zero crossing detection interrupt (ZXIx) |
++---------------------------------------------------+----------------------------------------------------------+
+
+Event directions:
+
+- ``rising``: Upper threshold crossing (swell detection)
+- ``falling``: Lower threshold crossing (sag/dip detection)
+- ``either``: Any threshold crossing (zero crossing detection)
+- ``none``: Timeout or non-directional events
+
+**Note**: Event attributes are only available if the corresponding interrupts
+(irq0, irq1, dready) are specified in the device tree. The driver works without
+interrupts but with reduced functionality.
+
+5. Device buffers
+=================
+
+This driver supports IIO buffers for waveform capture. Buffer functionality
+requires the dready interrupt to be connected.
+
+The device supports capturing voltage and current waveforms for power quality
+analysis. The waveform buffer can be configured to capture data from different
+channel combinations.
+
+Supported channel combinations for buffered capture:
+
+- Phase A: voltage and current (IA + VA)
+- Phase B: voltage and current (IB + VB)
+- Phase C: voltage and current (IC + VC)
+- All phases: all voltage and current channels
+- Individual channels: IA, VA, IB, VB, IC, VC
+
+Usage examples
+--------------
+
+Enable waveform capture for Phase A:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_current0_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_voltage0_en
+
+Set buffer length and enable:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 100 > buffer/length
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+6. Clock output
+===============
+
+The ADE9000 can provide a clock output via the CLKOUT pin when using an external
+crystal/clock source. This feature is enabled by specifying ``#clock-cells = <0>``
+in the device tree. The output clock will be registered as "clkout" and can be
+referenced by other devices.
+
+7. Usage examples
+=================
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ ade9000
+
+Read voltage measurements:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_voltage0_raw
+ 12345
+ root:/sys/bus/iio/devices/iio:device0> cat in_voltage0_scale
+ 0.000030517
+
+- Phase A voltage = in_voltage0_raw * in_voltage0_scale = 0.3769 V
+
+Read power measurements:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_power0_active_raw
+ 5678
+ root:/sys/bus/iio/devices/iio:device0> cat in_power0_scale
+ 0.000244140
+
+- Phase A active power = in_power0_active_raw * in_power0_scale = 1.386 W
+
+Configure calibration gains:
+
+.. code-block:: bash
+
+ # Set current channel 0 calibration gain
+ root:/sys/bus/iio/devices/iio:device0> echo 0x800000 > in_current0_calibscale
+ # Set voltage channel 0 calibration gain
+ root:/sys/bus/iio/devices/iio:device0> echo 0x7FFFFF > in_voltage0_calibscale
+
+Configure RMS voltage event thresholds (requires interrupts):
+
+.. code-block:: bash
+
+ # Set RMS sag detection threshold
+ root:/sys/bus/iio/devices/iio:device0> echo 180000 > events/in_altvoltage0_rms_thresh_falling_value
+ # Enable RMS sag detection
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > events/in_altvoltage0_rms_thresh_falling_en
+
+ # Set RMS swell detection threshold
+ root:/sys/bus/iio/devices/iio:device0> echo 260000 > events/in_altvoltage0_rms_thresh_rising_value
+ # Enable RMS swell detection
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > events/in_altvoltage0_rms_thresh_rising_en
+
+8. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/adis16475.rst b/Documentation/iio/adis16475.rst
new file mode 100644
index 000000000000..89a388490ab7
--- /dev/null
+++ b/Documentation/iio/adis16475.rst
@@ -0,0 +1,384 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================
+ADIS16475 driver
+================
+
+This driver supports Analog Device's IMUs on SPI bus.
+
+1. Supported devices
+====================
+
+* `ADIS16465 <https://www.analog.com/ADIS16465>`_
+* `ADIS16467 <https://www.analog.com/ADIS16467>`_
+* `ADIS16470 <https://www.analog.com/ADIS16470>`_
+* `ADIS16475 <https://www.analog.com/ADIS16475>`_
+* `ADIS16477 <https://www.analog.com/ADIS16477>`_
+* `ADIS16500 <https://www.analog.com/ADIS16500>`_
+* `ADIS16505 <https://www.analog.com/ADIS16505>`_
+* `ADIS16507 <https://www.analog.com/ADIS16507>`_
+
+Each supported device is a precision, miniature microelectromechanical system
+(MEMS) inertial measurement unit (IMU) that includes a triaxial gyroscope and a
+triaxial accelerometer. Each inertial sensor in the IMU device combines with
+signal conditioning that optimizes dynamic performance. The factory calibration
+characterizes each sensor for sensitivity, bias, alignment, linear acceleration
+(gyroscope bias), and point of percussion (accelerometer location). As a result,
+each sensor has dynamic compensation formulas that provide accurate sensor
+measurements over a broad set of conditions.
+
+2. Device attributes
+====================
+
+Accelerometer, gyroscope measurements are always provided. Furthermore, the
+driver offers the capability to retrieve the delta angle and the delta velocity
+measurements computed by the device.
+
+The delta angle measurements represent a calculation of angular displacement
+between each sample update, while the delta velocity measurements represent a
+calculation of linear velocity change between each sample update.
+
+Finally, temperature data are provided which show a coarse measurement of
+the temperature inside of the IMU device. This data is most useful for
+monitoring relative changes in the thermal environment.
+
+The signal chain of each inertial sensor (accelerometers and gyroscopes)
+includes the application of unique correction formulas, which are derived from
+extensive characterization of bias, sensitivity, alignment, response to linear
+acceleration (gyroscopes), and point of percussion (accelerometer location)
+over a temperature range of −40°C to +85°C, for each ADIS device. These
+correction formulas are not accessible, but users do have the opportunity to
+adjust the bias for each sensor individually through the calibbias attribute.
+
+Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in questions. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following tables show the adis16475 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
++-------------------------------------------+----------------------------------------------------------+
+| 3-Axis Accelerometer related device files | Description |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_scale | Scale for the accelerometer channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_raw | Raw X-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibbias | Calibration offset for the Y-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_raw | Raw Y-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_raw | Raw Z-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_scale | Scale for delta velocity channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_x_raw | Raw X-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_y_raw | Raw Y-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_z_raw | Raw Z-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+
++---------------------------------------+------------------------------------------------------+
+| 3-Axis Gyroscope related device files | Description |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_scale | Scale for the gyroscope channels. |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_x_calibbias | Calibration offset for the X-axis gyroscope channel. |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_x_raw | Raw X-axis gyroscope channel value. |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_y_calibbias | Calibration offset for the Y-axis gyroscope channel. |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_y_raw | Raw Y-axis gyroscope channel value. |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_z_calibbias | Calibration offset for the Z-axis gyroscope channel. |
++---------------------------------------+------------------------------------------------------+
+| in_anglvel_z_raw | Raw Z-axis gyroscope channel value. |
++---------------------------------------+------------------------------------------------------+
+| in_deltaangl_scale | Scale for delta angle channels. |
++---------------------------------------+------------------------------------------------------+
+| in_deltaangl_x_raw | Raw X-axis delta angle channel value. |
++---------------------------------------+------------------------------------------------------+
+| in_deltaangl_y_raw | Raw Y-axis delta angle channel value. |
++---------------------------------------+------------------------------------------------------+
+| in_deltaangl_z_raw | Raw Z-axis delta angle channel value. |
++---------------------------------------+------------------------------------------------------+
+
++----------------------------------+-------------------------------------------+
+| Temperature sensor related files | Description |
++----------------------------------+-------------------------------------------+
+| in_temp0_raw | Raw temperature channel value. |
++----------------------------------+-------------------------------------------+
+| in_temp0_scale | Scale for the temperature sensor channel. |
++----------------------------------+-------------------------------------------+
+
++-------------------------------+---------------------------------------------------------+
+| Miscellaneous device files | Description |
++-------------------------------+---------------------------------------------------------+
+| name | Name of the IIO device. |
++-------------------------------+---------------------------------------------------------+
+| sampling_frequency | Currently selected sample rate. |
++-------------------------------+---------------------------------------------------------+
+| filter_low_pass_3db_frequency | Bandwidth for the accelerometer and gyroscope channels. |
++-------------------------------+---------------------------------------------------------+
+
+The following table shows the adis16475 related device debug files, found in the
+specific device debug folder path ``/sys/kernel/debug/iio/iio:deviceX``.
+
++----------------------+-------------------------------------------------------------------------+
+| Debugfs device files | Description |
++----------------------+-------------------------------------------------------------------------+
+| serial_number | The serial number of the chip in hexadecimal format. |
++----------------------+-------------------------------------------------------------------------+
+| product_id | Chip specific product id (e.g. 16475, 16500, 16505, etc.). |
++----------------------+-------------------------------------------------------------------------+
+| flash_count | The number of flash writes performed on the device. |
++----------------------+-------------------------------------------------------------------------+
+| firmware_revision | String containing the firmware revision in the following format ##.##. |
++----------------------+-------------------------------------------------------------------------+
+| firmware_date | String containing the firmware date in the following format mm-dd-yyyy. |
++----------------------+-------------------------------------------------------------------------+
+
+Channels processed values
+-------------------------
+
+A channel value can be read from its _raw attribute. The value returned is the
+raw value as reported by the devices. To get the processed value of the channel,
+apply the following formula:
+
+.. code-block:: bash
+
+ processed value = (_raw + _offset) * _scale
+
+Where _offset and _scale are device attributes. If no _offset attribute is
+present, simply assume its value is 0.
+
+The adis16475 driver offers data for 5 types of channels, the table below shows
+the measurement units for the processed value, which are defined by the IIO
+framework:
+
++-------------------------------------+---------------------------+
+| Channel type | Measurement unit |
++-------------------------------------+---------------------------+
+| Acceleration on X, Y, and Z axis | Meters per Second squared |
++-------------------------------------+---------------------------+
+| Angular velocity on X, Y and Z axis | Radians per second |
++-------------------------------------+---------------------------+
+| Delta velocity on X. Y, and Z axis | Meters per Second |
++-------------------------------------+---------------------------+
+| Delta angle on X, Y, and Z axis | Radians |
++-------------------------------------+---------------------------+
+| Temperature | Millidegrees Celsius |
++-------------------------------------+---------------------------+
+
+Usage examples
+--------------
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ adis16505-2
+
+Show accelerometer channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw
+ -275924
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw
+ -30142222
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw
+ 261265769
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale
+ 0.000000037
+
+- X-axis acceleration = in_accel_x_raw * in_accel_scale = −0.010209188 m/s^2
+- Y-axis acceleration = in_accel_y_raw * in_accel_scale = −1.115262214 m/s^2
+- Z-axis acceleration = in_accel_z_raw * in_accel_scale = 9.666833453 m/s^2
+
+Show gyroscope channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_x_raw
+ -3324626
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_raw
+ 1336980
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_z_raw
+ -602983
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_scale
+ 0.000000006
+
+- X-axis angular velocity = in_anglvel_x_raw * in_anglvel_scale = −0.019947756 rad/s
+- Y-axis angular velocity = in_anglvel_y_raw * in_anglvel_scale = 0.00802188 rad/s
+- Z-axis angular velocity = in_anglvel_z_raw * in_anglvel_scale = −0.003617898 rad/s
+
+Set calibration offset for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 5000 > in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 5000
+
+Set calibration offset for gyroscope channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo -5000 > in_anglvel_y_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias
+ -5000
+
+Set sampling frequency:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency
+ 2000.000000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1000 > sampling_frequency
+ 1000.000000
+
+Set bandwidth for accelerometer and gyroscope:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat filter_low_pass_3db_frequency
+ 720
+
+ root:/sys/bus/iio/devices/iio:device0> echo 360 > filter_low_pass_3db_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat filter_low_pass_3db_frequency
+ 360
+
+Show serial number:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat serial_number
+ 0x04f9
+
+Show product id:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat product_id
+ 16505
+
+Show flash count:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat flash_count
+ 150
+
+Show firmware revision:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat firmware_revision
+ 1.6
+
+Show firmware date:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat firmware_date
+ 06-27-2019
+
+3. Device buffers
+=================
+
+This driver supports IIO buffers.
+
+All devices support retrieving the raw acceleration, gyroscope and temperature
+measurements using buffers.
+
+The following device families also support retrieving the delta velocity, delta
+angle and temperature measurements using buffers:
+
+- ADIS16477
+- ADIS16500
+- ADIS16505
+- ADIS16507
+
+However, when retrieving acceleration or gyroscope data using buffers, delta
+readings will not be available and vice versa.
+
+Usage examples
+--------------
+
+Set device trigger in current_trigger, if not already set:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
+
+ root:/sys/bus/iio/devices/iio:device0> echo adis16505-2-dev0 > trigger/current_trigger
+ root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
+ adis16505-2-dev0
+
+Select channels for buffer read:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_z_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp0_en
+
+Set the number of samples to be stored in the buffer:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
+
+Enable buffer readings:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+Obtain buffered data:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0
+ ...
+ 00001680 01 1f 00 00 ff ff fe ef 00 00 47 bf 00 03 35 55 |..........G...5U|
+ 00001690 01 1f 00 00 ff ff ff d9 00 00 46 f1 00 03 35 35 |..........F...55|
+ 000016a0 01 1f 00 00 ff ff fe fc 00 00 46 cb 00 03 35 7b |..........F...5{|
+ 000016b0 01 1f 00 00 ff ff fe 41 00 00 47 0d 00 03 35 8b |.......A..G...5.|
+ 000016c0 01 1f 00 00 ff ff fe 37 00 00 46 b4 00 03 35 90 |.......7..F...5.|
+ 000016d0 01 1d 00 00 ff ff fe 5a 00 00 45 d7 00 03 36 08 |.......Z..E...6.|
+ 000016e0 01 1b 00 00 ff ff fe fb 00 00 45 e7 00 03 36 60 |..........E...6`|
+ 000016f0 01 1a 00 00 ff ff ff 17 00 00 46 bc 00 03 36 de |..........F...6.|
+ 00001700 01 1a 00 00 ff ff fe 59 00 00 46 d7 00 03 37 b8 |.......Y..F...7.|
+ 00001710 01 1a 00 00 ff ff fe ae 00 00 46 95 00 03 37 ba |..........F...7.|
+ 00001720 01 1a 00 00 ff ff fe c5 00 00 46 63 00 03 37 9f |..........Fc..7.|
+ 00001730 01 1a 00 00 ff ff fe 55 00 00 46 89 00 03 37 c1 |.......U..F...7.|
+ 00001740 01 1a 00 00 ff ff fe 31 00 00 46 aa 00 03 37 f7 |.......1..F...7.|
+ ...
+
+See Documentation/iio/iio_devbuf.rst for more information about how buffered
+data is structured.
+
+4. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/adis16480.rst b/Documentation/iio/adis16480.rst
new file mode 100644
index 000000000000..cce5f3e01741
--- /dev/null
+++ b/Documentation/iio/adis16480.rst
@@ -0,0 +1,446 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================
+ADIS16480 driver
+================
+
+This driver supports Analog Device's IMUs on SPI bus.
+
+1. Supported devices
+====================
+
+* `ADIS16375 <https://www.analog.com/ADIS16375>`_
+* `ADIS16480 <https://www.analog.com/ADIS16480>`_
+* `ADIS16485 <https://www.analog.com/ADIS16485>`_
+* `ADIS16486 <https://www.analog.com/ADIS16486>`_
+* `ADIS16487 <https://www.analog.com/ADIS16487>`_
+* `ADIS16488 <https://www.analog.com/ADIS16488>`_
+* `ADIS16489 <https://www.analog.com/ADIS16489>`_
+* `ADIS16490 <https://www.analog.com/ADIS16490>`_
+* `ADIS16495 <https://www.analog.com/ADIS16495>`_
+* `ADIS16497 <https://www.analog.com/ADIS16497>`_
+* `ADIS16545 <https://www.analog.com/ADIS16545>`_
+* `ADIS16547 <https://www.analog.com/ADIS16547>`_
+
+Each supported device is a complete inertial system that includes a triaxial
+gyroscope and a triaxial accelerometer. Each inertial sensor in device combines
+with signal conditioning that optimizes dynamic performance. The factory
+calibration characterizes each sensor for sensitivity, bias, and alignment. As
+a result, each sensor has its own dynamic compensation formulas that provide
+accurate sensor measurements.
+
+2. Device attributes
+====================
+
+Accelerometer, gyroscope measurements are always provided. Furthermore, the
+driver offers the capability to retrieve the delta angle and the delta velocity
+measurements computed by the device.
+
+The delta angle measurements represent a calculation of angular displacement
+between each sample update, while the delta velocity measurements represent a
+calculation of linear velocity change between each sample update.
+
+Finally, temperature data are provided which show a coarse measurement of
+the temperature inside of the IMU device. This data is most useful for
+monitoring relative changes in the thermal environment.
+
+ADIS16480 and ADIS16488 also provide access to barometric pressure data and
+triaxial magnetometer measurements.
+
+Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in questions. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following tables show the adis16480 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
+**Available only for ADIS16480 and ADIS16488:**
+
++------------------------------------------+---------------------------------------------------------+
+| 3-Axis Magnetometer related device files | Description |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_scale | Scale for the magnetometer channels. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_x_calibbias | Calibration offset for the X-axis magnetometer channel. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_x_filter_low_pass_3db_frequency | Bandwidth for the X-axis magnetometer channel. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_x_raw | Raw X-axis magnetometer channel value. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_y_calibbias | Calibration offset for the Y-axis magnetometer channel. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_y_filter_low_pass_3db_frequency | Bandwidth for the Y-axis magnetometer channel. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_y_raw | Raw Y-axis magnetometer channel value. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_z_calibbias | Calibration offset for the Z-axis magnetometer channel. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_z_filter_low_pass_3db_frequency | Bandwidth for the Z-axis magnetometer channel. |
++------------------------------------------+---------------------------------------------------------+
+| in_magn_z_raw | Raw Z-axis magnetometer channel value. |
++------------------------------------------+---------------------------------------------------------+
+
++------------------------------------------+-----------------------------------------------------+
+| Barometric pressure sensor related files | Description |
++------------------------------------------+-----------------------------------------------------+
+| in_pressure0_calibbias | Calibration offset for barometric pressure channel. |
++------------------------------------------+-----------------------------------------------------+
+| in_pressure0_raw | Raw barometric pressure channel value. |
++------------------------------------------+-----------------------------------------------------+
+| in_pressure0_scale | Scale for the barometric pressure sensor channel. |
++------------------------------------------+-----------------------------------------------------+
+
+**Available for all supported devices:**
+
++-------------------------------------------+----------------------------------------------------------+
+| 3-Axis Accelerometer related device files | Description |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_scale | Scale for the accelerometer channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibscale | Calibration scale for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_filter_low_pass_3db_frequency | Bandwidth for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_raw | Raw X-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibbias | Calibration offset for the Y-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibscale | Calibration scale for the Y-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_filter_low_pass_3db_frequency | Bandwidth for the Y-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_raw | Raw Y-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibscale | Calibration scale for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_filter_low_pass_3db_frequency | Bandwidth for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_raw | Raw Z-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_scale | Scale for delta velocity channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_x_raw | Raw X-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_y_raw | Raw Y-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_z_raw | Raw Z-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+
++--------------------------------------------+------------------------------------------------------+
+| 3-Axis Gyroscope related device files | Description |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_scale | Scale for the gyroscope channels. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_calibbias | Calibration offset for the X-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_calibscale | Calibration scale for the X-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_filter_low_pass_3db_frequency | Bandwidth for the X-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_raw | Raw X-axis gyroscope channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_calibbias | Calibration offset for the Y-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_calibscale | Calibration scale for the Y-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_filter_low_pass_3db_frequency | Bandwidth for the Y-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_raw | Raw Y-axis gyroscope channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_calibbias | Calibration offset for the Z-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_calibscale | Calibration scale for the Z-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_filter_low_pass_3db_frequency | Bandwidth for the Z-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_raw | Raw Z-axis gyroscope channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_scale | Scale for delta angle channels. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_x_raw | Raw X-axis delta angle channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_y_raw | Raw Y-axis delta angle channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_z_raw | Raw Z-axis delta angle channel value. |
++--------------------------------------------+------------------------------------------------------+
+
++----------------------------------+-------------------------------------------+
+| Temperature sensor related files | Description |
++----------------------------------+-------------------------------------------+
+| in_temp0_raw | Raw temperature channel value. |
++----------------------------------+-------------------------------------------+
+| in_temp0_offset | Offset for the temperature sensor channel.|
++----------------------------------+-------------------------------------------+
+| in_temp0_scale | Scale for the temperature sensor channel. |
++----------------------------------+-------------------------------------------+
+
++-------------------------------+---------------------------------------------------------+
+| Miscellaneous device files | Description |
++-------------------------------+---------------------------------------------------------+
+| name | Name of the IIO device. |
++-------------------------------+---------------------------------------------------------+
+| sampling_frequency | Currently selected sample rate. |
++-------------------------------+---------------------------------------------------------+
+
+The following table shows the adis16480 related device debug files, found in the
+specific device debug folder path ``/sys/kernel/debug/iio/iio:deviceX``.
+
++----------------------+-------------------------------------------------------------------------+
+| Debugfs device files | Description |
++----------------------+-------------------------------------------------------------------------+
+| serial_number | The serial number of the chip in hexadecimal format. |
++----------------------+-------------------------------------------------------------------------+
+| product_id | Chip specific product id (e.g. 16480, 16488, 16545, etc.). |
++----------------------+-------------------------------------------------------------------------+
+| flash_count | The number of flash writes performed on the device. |
++----------------------+-------------------------------------------------------------------------+
+| firmware_revision | String containing the firmware revision in the following format ##.##. |
++----------------------+-------------------------------------------------------------------------+
+| firmware_date | String containing the firmware date in the following format mm-dd-yyyy. |
++----------------------+-------------------------------------------------------------------------+
+
+Channels processed values
+-------------------------
+
+A channel value can be read from its _raw attribute. The value returned is the
+raw value as reported by the devices. To get the processed value of the channel,
+apply the following formula:
+
+.. code-block:: bash
+
+ processed value = (_raw + _offset) * _scale
+
+Where _offset and _scale are device attributes. If no _offset attribute is
+present, simply assume its value is 0.
+
+The adis16480 driver offers data for 7 types of channels, the table below shows
+the measurement units for the processed value, which are defined by the IIO
+framework:
+
++--------------------------------------+---------------------------+
+| Channel type | Measurement unit |
++--------------------------------------+---------------------------+
+| Acceleration on X, Y, and Z axis | Meters per Second squared |
++--------------------------------------+---------------------------+
+| Angular velocity on X, Y and Z axis | Radians per second |
++--------------------------------------+---------------------------+
+| Delta velocity on X. Y, and Z axis | Meters per Second |
++--------------------------------------+---------------------------+
+| Delta angle on X, Y, and Z axis | Radians |
++--------------------------------------+---------------------------+
+| Temperature | Millidegrees Celsius |
++--------------------------------------+---------------------------+
+| Magnetic field along X, Y and Z axis | Gauss |
++--------------------------------------+---------------------------+
+| Barometric pressure | kilo Pascal |
++--------------------------------------+---------------------------+
+
+Usage examples
+--------------
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ adis16545-1
+
+Show accelerometer channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw
+ 1376728
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw
+ 4487621
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw
+ 262773792
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale
+ 0.000000037
+
+- X-axis acceleration = in_accel_x_raw * in_accel_scale = 0.050938936 m/s^2
+- Y-axis acceleration = in_accel_y_raw * in_accel_scale = 0.166041977 m/s^2
+- Z-axis acceleration = in_accel_z_raw * in_accel_scale = 9.722630304 m/s^2
+
+Show gyroscope channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_x_raw
+ -1041702
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_raw
+ -273013
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_z_raw
+ 2745116
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_scale
+ 0.000000001
+
+- X-axis angular velocity = in_anglvel_x_raw * in_anglvel_scale = −0.001041702 rad/s
+- Y-axis angular velocity = in_anglvel_y_raw * in_anglvel_scale = −0.000273013 rad/s
+- Z-axis angular velocity = in_anglvel_z_raw * in_anglvel_scale = 0.002745116 rad/s
+
+Set calibration offset for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 5000 > in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 5000
+
+Set calibration offset for gyroscope channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo -5000 > in_anglvel_y_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias
+ -5000
+
+Set sampling frequency:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency
+ 4250.000000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1000 > sampling_frequency
+ 1062.500000
+
+Set bandwidth for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_filter_low_pass_3db_frequency
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 300 > in_accel_x_filter_low_pass_3db_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_filter_low_pass_3db_frequency
+ 300
+
+Show serial number:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat serial_number
+ 0x000c
+
+Show product id:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat product_id
+ 16545
+
+Show flash count:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat flash_count
+ 88
+
+Show firmware revision:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat firmware_revision
+ 1.4
+
+Show firmware date:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat firmware_date
+ 09-23-2023
+
+3. Device buffers
+=================
+
+This driver supports IIO buffers.
+
+All devices support retrieving the raw acceleration, gyroscope and temperature
+measurements using buffers.
+
+The following device families also support retrieving the delta velocity, delta
+angle and temperature measurements using buffers:
+
+- ADIS16545
+- ADIS16547
+
+However, when retrieving acceleration or gyroscope data using buffers, delta
+readings will not be available and vice versa. This is because the device only
+allows to read either acceleration and gyroscope data or delta velocity and
+delta angle data at a time and switching between these two burst data selection
+modes is time consuming.
+
+Usage examples
+--------------
+
+Set device trigger in current_trigger, if not already set:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
+
+ root:/sys/bus/iio/devices/iio:device0> echo adis16545-1-dev0 > trigger/current_trigger
+ root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
+ adis16545-1-dev0
+
+Select channels for buffer read:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_z_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp0_en
+
+Set the number of samples to be stored in the buffer:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
+
+Enable buffer readings:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+Obtain buffered data::
+
+ root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0
+ ...
+ 00006aa0 09 62 00 00 ff ff fc a4 00 00 01 69 00 03 3c 08 |.b.........i..<.|
+ 00006ab0 09 61 00 00 00 00 02 96 00 00 02 8f 00 03 37 50 |.a............7P|
+ 00006ac0 09 61 00 00 00 00 12 3d 00 00 0b 89 00 03 2c 0b |.a.....=......,.|
+ 00006ad0 09 61 00 00 00 00 1e dc 00 00 16 dd 00 03 25 bf |.a............%.|
+ 00006ae0 09 61 00 00 00 00 1e e3 00 00 1b bf 00 03 27 0b |.a............'.|
+ 00006af0 09 61 00 00 00 00 15 50 00 00 19 44 00 03 30 fd |.a.....P...D..0.|
+ 00006b00 09 61 00 00 00 00 09 0e 00 00 14 41 00 03 3d 7f |.a.........A..=.|
+ 00006b10 09 61 00 00 ff ff ff f0 00 00 0e bc 00 03 48 d0 |.a............H.|
+ 00006b20 09 63 00 00 00 00 00 9f 00 00 0f 37 00 03 4c fe |.c.........7..L.|
+ 00006b30 09 64 00 00 00 00 0b f6 00 00 18 92 00 03 43 22 |.d............C"|
+ 00006b40 09 64 00 00 00 00 18 df 00 00 22 33 00 03 33 ab |.d........"3..3.|
+ 00006b50 09 63 00 00 00 00 1e 81 00 00 26 be 00 03 29 60 |.c........&...)`|
+ 00006b60 09 63 00 00 00 00 1b 13 00 00 22 2f 00 03 23 91 |.c........"/..#.|
+ ...
+
+See Documentation/iio/iio_devbuf.rst for more information about how buffered
+data is structured.
+
+4. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/adis16550.rst b/Documentation/iio/adis16550.rst
new file mode 100644
index 000000000000..c9bbc0a857b0
--- /dev/null
+++ b/Documentation/iio/adis16550.rst
@@ -0,0 +1,376 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================
+ADIS16550 driver
+================
+
+This driver supports Analog Device's IMUs on SPI bus.
+
+1. Supported devices
+====================
+
+* `ADIS16550 <https://www.analog.com/ADIS16550>`_
+
+The ADIS16550 is a complete inertial system that includes a triaxis gyroscope
+and a triaxis accelerometer. The factory calibration characterizes each sensor for
+sensitivity, bias, and alignment. As a result, each sensor has its own dynamic
+compensation formulas that provide accurate sensor measurements.
+
+2. Device attributes
+====================
+
+Accelerometer, gyroscope measurements are always provided. Furthermore, the
+driver offers the capability to retrieve the delta angle and the delta velocity
+measurements computed by the device.
+
+The delta angle measurements represent a calculation of angular displacement
+between each sample update, while the delta velocity measurements represent a
+calculation of linear velocity change between each sample update.
+
+Finally, temperature data are provided which show a coarse measurement of
+the temperature inside of the IMU device. This data is most useful for
+monitoring relative changes in the thermal environment.
+
+Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in questions. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following tables show the adis16550 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
++-------------------------------------------+----------------------------------------------------------+
+| 3-Axis Accelerometer related device files | Description |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_scale | Scale for the accelerometer channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_filter_low_pass_3db_frequency | Bandwidth for the accelerometer channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibscale | Calibration scale for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_raw | Raw X-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibbias | Calibration offset for the Y-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibscale | Calibration scale for the Y-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_raw | Raw Y-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibscale | Calibration scale for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_raw | Raw Z-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_scale | Scale for delta velocity channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_x_raw | Raw X-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_y_raw | Raw Y-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_deltavelocity_z_raw | Raw Z-axis delta velocity channel value. |
++-------------------------------------------+----------------------------------------------------------+
+
++--------------------------------------------+------------------------------------------------------+
+| 3-Axis Gyroscope related device files | Description |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_scale | Scale for the gyroscope channels. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_filter_low_pass_3db_frequency | Scale for the gyroscope channels. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_calibbias | Calibration offset for the X-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_calibscale | Calibration scale for the X-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_x_raw | Raw X-axis gyroscope channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_calibbias | Calibration offset for the Y-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_calibscale | Calibration scale for the Y-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_y_raw | Raw Y-axis gyroscope channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_calibbias | Calibration offset for the Z-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_calibscale | Calibration scale for the Z-axis gyroscope channel. |
++--------------------------------------------+------------------------------------------------------+
+| in_anglvel_z_raw | Raw Z-axis gyroscope channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_scale | Scale for delta angle channels. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_x_raw | Raw X-axis delta angle channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_y_raw | Raw Y-axis delta angle channel value. |
++--------------------------------------------+------------------------------------------------------+
+| in_deltaangl_z_raw | Raw Z-axis delta angle channel value. |
++--------------------------------------------+------------------------------------------------------+
+
++----------------------------------+-------------------------------------------+
+| Temperature sensor related files | Description |
++----------------------------------+-------------------------------------------+
+| in_temp0_raw | Raw temperature channel value. |
++----------------------------------+-------------------------------------------+
+| in_temp0_offset | Offset for the temperature sensor channel.|
++----------------------------------+-------------------------------------------+
+| in_temp0_scale | Scale for the temperature sensor channel. |
++----------------------------------+-------------------------------------------+
+
++----------------------------+--------------------------------------------------------------------------------+
+| Miscellaneous device files | Description |
++----------------------------+--------------------------------------------------------------------------------+
+| name | Name of the IIO device. |
++----------------------------+--------------------------------------------------------------------------------+
+| sampling_frequency | Currently selected sample rate. |
++----------------------------+--------------------------------------------------------------------------------+
+
+The following table shows the adis16550 related device debug files, found in the
+specific device debug folder path ``/sys/kernel/debug/iio/iio:deviceX``.
+
++----------------------+-------------------------------------------------------------------------+
+| Debugfs device files | Description |
++----------------------+-------------------------------------------------------------------------+
+| serial_number | The serial number of the chip in hexadecimal format. |
++----------------------+-------------------------------------------------------------------------+
+| product_id | Chip specific product id (16550). |
++----------------------+-------------------------------------------------------------------------+
+| flash_count | The number of flash writes performed on the device. |
++----------------------+-------------------------------------------------------------------------+
+| firmware_revision | String containing the firmware revision in the following format ##.##. |
++----------------------+-------------------------------------------------------------------------+
+| firmware_date | String containing the firmware date in the following format mm-dd-yyyy. |
++----------------------+-------------------------------------------------------------------------+
+
+Channels processed values
+-------------------------
+
+A channel value can be read from its _raw attribute. The value returned is the
+raw value as reported by the devices. To get the processed value of the channel,
+apply the following formula:
+
+.. code-block:: bash
+
+ processed value = (_raw + _offset) * _scale
+
+Where _offset and _scale are device attributes. If no _offset attribute is
+present, simply assume its value is 0.
+
+The adis16550 driver offers data for 5 types of channels, the table below shows
+the measurement units for the processed value, which are defined by the IIO
+framework:
+
++--------------------------------------+---------------------------+
+| Channel type | Measurement unit |
++--------------------------------------+---------------------------+
+| Acceleration on X, Y, and Z axis | Meters per Second squared |
++--------------------------------------+---------------------------+
+| Angular velocity on X, Y and Z axis | Radians per second |
++--------------------------------------+---------------------------+
+| Delta velocity on X. Y, and Z axis | Meters per Second |
++--------------------------------------+---------------------------+
+| Delta angle on X, Y, and Z axis | Radians |
++--------------------------------------+---------------------------+
+| Temperature | Millidegrees Celsius |
++--------------------------------------+---------------------------+
+
+Usage examples
+--------------
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ adis16550
+
+Show accelerometer channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw
+ 6903851
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw
+ 5650550
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw
+ 104873530
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale
+ 0.000000095
+
+- X-axis acceleration = in_accel_x_raw * in_accel_scale = 0.655865845 m/s^2
+- Y-axis acceleration = in_accel_y_raw * in_accel_scale = 0.53680225 m/s^2
+- Z-axis acceleration = in_accel_z_raw * in_accel_scale = 9.96298535 m/s^2
+
+Show gyroscope channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_x_raw
+ 193309
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_raw
+ -763676
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_z_raw
+ -358108
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_scale
+ 0.000000003
+
+- X-axis angular velocity = in_anglvel_x_raw * in_anglvel_scale = 0.000579927 rad/s
+- Y-axis angular velocity = in_anglvel_y_raw * in_anglvel_scale = −0.002291028 rad/s
+- Z-axis angular velocity = in_anglvel_z_raw * in_anglvel_scale = −0.001074324 rad/s
+
+Set calibration offset for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 5000 > in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 5000
+
+Set calibration offset for gyroscope channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo -5000 > in_anglvel_y_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias
+ -5000
+
+Set sampling frequency:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency
+ 4000.000000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1000 > sampling_frequency
+ 1000.000000
+
+Set bandwidth for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 100 > in_accel_filter_low_pass_3db_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency
+ 100
+
+Show serial number:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat serial_number
+ 0x000000b6
+
+Show product id:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat product_id
+ 16550
+
+Show flash count:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat flash_count
+ 13
+
+Show firmware revision:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat firmware_revision
+ 1.5
+
+Show firmware date:
+
+.. code-block:: bash
+
+ root:/sys/kernel/debug/iio/iio:device0> cat firmware_date
+ 28-04-2021
+
+3. Device buffers
+=================
+
+This driver supports IIO buffers.
+
+The device supports retrieving the raw acceleration, gyroscope, delta velocity,
+delta angle and temperature measurements using buffers.
+
+However, when retrieving acceleration or gyroscope data using buffers, delta
+readings will not be available and vice versa. This is because the device only
+allows to read either acceleration and gyroscope data or delta velocity and
+delta angle data at a time and switching between these two burst data selection
+modes is time consuming.
+
+Usage examples
+--------------
+
+Set device trigger in current_trigger, if not already set:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
+
+ root:/sys/bus/iio/devices/iio:device0> echo adis16550-dev0 > trigger/current_trigger
+ root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger
+ adis16550-dev0
+
+Select channels for buffer read:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_z_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp0_en
+
+Set the number of samples to be stored in the buffer:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
+
+Enable buffer readings:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+Obtain buffered data:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0
+ ...
+ 0000cdf0 00 00 0d 2f 00 00 08 43 00 00 09 09 00 00 a4 5f |.../...C......._|
+ 0000ce00 00 00 0d 2f 00 00 07 de 00 00 08 db 00 00 a4 4b |.../...........K|
+ 0000ce10 00 00 0d 2f 00 00 07 58 00 00 08 a3 00 00 a4 55 |.../...X.......U|
+ 0000ce20 00 00 0d 2f 00 00 06 d6 00 00 08 5c 00 00 a4 62 |.../.......\...b|
+ 0000ce30 00 00 0d 2f 00 00 06 45 00 00 08 37 00 00 a4 47 |.../...E...7...G|
+ 0000ce40 00 00 0d 2f 00 00 05 d4 00 00 08 30 00 00 a3 fa |.../.......0....|
+ 0000ce50 00 00 0d 2f 00 00 05 d0 00 00 08 12 00 00 a3 d3 |.../............|
+ 0000ce60 00 00 0d 2f 00 00 05 dd 00 00 08 2e 00 00 a3 e9 |.../............|
+ 0000ce70 00 00 0d 2f 00 00 05 cc 00 00 08 51 00 00 a3 d5 |.../.......Q....|
+ 0000ce80 00 00 0d 2f 00 00 05 ba 00 00 08 22 00 00 a3 9a |.../......."....|
+ 0000ce90 00 00 0d 2f 00 00 05 9c 00 00 07 d9 00 00 a3 40 |.../...........@|
+ 0000cea0 00 00 0d 2f 00 00 05 68 00 00 07 94 00 00 a2 e4 |.../...h........|
+ 0000ceb0 00 00 0d 2f 00 00 05 25 00 00 07 8d 00 00 a2 ce |.../...%........|
+ ...
+
+See Documentation/iio/iio_devbuf.rst for more information about how buffered
+data is structured.
+
+4. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/adxl313.rst b/Documentation/iio/adxl313.rst
new file mode 100644
index 000000000000..966e72c0109a
--- /dev/null
+++ b/Documentation/iio/adxl313.rst
@@ -0,0 +1,293 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+ADXL313 driver
+===============
+
+This driver supports Analog Device's ADXL313 on SPI/I2C bus.
+
+1. Supported devices
+====================
+
+* `ADXL313 <https://www.analog.com/ADXL313>`_
+
+The ADXL313is a low noise density, low power, 3-axis accelerometer with
+selectable measurement ranges. The ADXL313 supports the ±0.5 g, ±1 g, ±2 g and
+±4 g ranges.
+
+2. Device attributes
+====================
+
+Accelerometer measurements are always provided.
+
+Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in questions. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following tables show the adxl313 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
++---------------------------------------------------+----------------------------------------------------------+
+| 3-Axis Accelerometer related device files | Description |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_scale | Scale for the accelerometer channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x_raw | Raw X-axis accelerometer channel value. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibbias | y-axis acceleration offset correction |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_y_raw | Raw Y-axis accelerometer channel value. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_z_raw | Raw Z-axis accelerometer channel value. |
++---------------------------------------------------+----------------------------------------------------------+
+
++---------------------------------------+----------------------------------------------+
+| Miscellaneous device files | Description |
++---------------------------------------+----------------------------------------------+
+| name | Name of the IIO device. |
++---------------------------------------+----------------------------------------------+
+| in_accel_sampling_frequency | Currently selected sample rate. |
++---------------------------------------+----------------------------------------------+
+| in_accel_sampling_frequency_available | Available sampling frequency configurations. |
++---------------------------------------+----------------------------------------------+
+
+The iio event related settings, found in ``/sys/bus/iio/devices/iio:deviceX/events``.
+
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_mag_adaptive_falling_period | AC coupled inactivity time. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_mag_adaptive_falling_value | AC coupled inactivity threshold. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_mag_adaptive_rising_value | AC coupled activity threshold. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_mag_falling_period | Inactivity time. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_mag_falling_value | Inactivity threshold. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_mag_rising_value | Activity threshold. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x\&y\&z_mag_adaptive_falling_en | Enable or disable AC coupled inactivity events. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x\|y\|z_mag_adaptive_rising_en | Enable or disable AC coupled activity events. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x\&y\&z_mag_falling_en | Enable or disable inactivity events. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x\|y\|z_mag_rising_en | Enable or disable activity events. |
++---------------------------------------------------+----------------------------------------------------------+
+
+The default coupling is DC coupled events. In this case the threshold will
+be in place as such, where for the AC coupled case an adaptive threshold
+(described in the datasheet) will be applied by the sensor. In general activity,
+i.e. ``ACTIVITY`` or ``ACTIVITY_AC`` and inactivity i.e. ``INACTIVITY`` or
+``INACTIVITY_AC``, will be linked with auto-sleep enabled when both are enabled.
+This means in particular ``ACTIVITY`` can also be linked to ``INACTIVITY_AC``
+and vice versa, without problem.
+
+Note here, that ``ACTIVITY`` and ``ACTIVITY_AC`` are mutually exclusive. This
+means, that the most recent configuration will be set. For instance, if
+``ACTIVITY`` is enabled, and ``ACTIVITY_AC`` will be enabled, the sensor driver
+will have ``ACTIVITY`` disabled, but ``ACTIVITY_AC`` enabled. The same is valid
+for inactivity. In case of turning off an event, it has to match to what is
+actually enabled, i.e. enabling ``ACTIVITY_AC`` and then disabling ``ACTIVITY``
+is simply ignored as it is already disabled. Or, as if it was any other not
+enabled event, too.
+
+Channels processed values
+-------------------------
+
+A channel value can be read from its _raw attribute. The value returned is the
+raw value as reported by the devices. To get the processed value of the channel,
+apply the following formula:
+
+.. code-block::
+
+ processed value = (_raw + _offset) * _scale
+
+Where _offset and _scale are device attributes. If no _offset attribute is
+present, simply assume its value is 0.
+
+The ADXL313 driver offers data for a single types of channels, the table below
+shows the measurement units for the processed value, which are defined by the
+IIO framework:
+
++-------------------------------------+---------------------------+
+| Channel type | Measurement unit |
++-------------------------------------+---------------------------+
+| Acceleration on X, Y, and Z axis | Meters per Second squared |
++-------------------------------------+---------------------------+
+
+Usage examples
+--------------
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ adxl313
+
+Show accelerometer channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw
+ 2
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw
+ -57
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw
+ 2
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale
+ 0.009576806
+
+The accelerometer values will be:
+
+- X-axis acceleration = in_accel_x_raw * in_accel_scale = 0.0191536 m/s^2
+- Y-axis acceleration = in_accel_y_raw * in_accel_scale = -0.5458779 m/s^2
+- Z-axis acceleration = in_accel_z_raw * in_accel_scale = 0.0191536 m/s^2
+
+Set calibration offset for accelerometer channels. Note, that the calibration
+will be rounded according to the graduation of LSB units:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 50 > in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 48
+
+Set sampling frequency:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_sampling_frequency
+ 100.000000
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_sampling_frequency_available
+ 6.250000 12.500000 25.000000 50.000000 100.000000 200.000000 400.000000 800.000000 1600.000000 3200.000000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 400 > in_accel_sampling_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_sampling_frequency
+ 400.000000
+
+3. Device buffers and triggers
+==============================
+
+This driver supports IIO buffers.
+
+All devices support retrieving the raw acceleration measurements using buffers.
+
+Usage examples
+--------------
+
+Select channels for buffer read:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_z_en
+
+Set the number of samples to be stored in the buffer:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
+
+Enable buffer readings:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+Obtain buffered data:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0
+ ...
+ 000000d0 01 fc 31 00 c7 ff 03 fc 31 00 c7 ff 04 fc 33 00 |..1.....1.....3.|
+ 000000e0 c8 ff 03 fc 32 00 c5 ff ff fc 32 00 c7 ff 0a fc |....2.....2.....|
+ 000000f0 30 00 c8 ff 06 fc 33 00 c7 ff 01 fc 2f 00 c8 ff |0.....3...../...|
+ 00000100 02 fc 32 00 c6 ff 04 fc 33 00 c8 ff 05 fc 33 00 |..2.....3.....3.|
+ 00000110 ca ff 02 fc 31 00 c7 ff 02 fc 30 00 c9 ff 09 fc |....1.....0.....|
+ 00000120 35 00 c9 ff 08 fc 35 00 c8 ff 02 fc 31 00 c5 ff |5.....5.....1...|
+ 00000130 03 fc 32 00 c7 ff 04 fc 32 00 c7 ff 02 fc 31 00 |..2.....2.....1.|
+ 00000140 c7 ff 08 fc 30 00 c7 ff 02 fc 32 00 c5 ff ff fc |....0.....2.....|
+ 00000150 31 00 c5 ff 04 fc 31 00 c8 ff 03 fc 32 00 c8 ff |1.....1.....2...|
+ 00000160 01 fc 31 00 c7 ff 05 fc 31 00 c3 ff 04 fc 31 00 |..1.....1.....1.|
+ 00000170 c5 ff 04 fc 30 00 c7 ff 03 fc 31 00 c9 ff 03 fc |....0.....1.....|
+ ...
+
+Enabling activity detection:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1.28125 > ./events/in_accel_mag_rising_value
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_x\|y\|z_mag_rising_en
+
+ root:/sys/bus/iio/devices/iio:device0> iio_event_monitor adxl313
+ Found IIO device with name adxl313 with device number 0
+ <only while moving the sensor>
+ Event: time: 1748795762298351281, type: accel(x|y|z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1748795762302653704, type: accel(x|y|z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1748795762304340726, type: accel(x|y|z), channel: 0, evtype: mag, direction: rising
+ ...
+
+Disabling activity detection:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 0 > ./events/in_accel_x\|y\|z_mag_rising_en
+ root:/sys/bus/iio/devices/iio:device0> iio_event_monitor adxl313
+ <nothing>
+
+Enabling inactivity detection:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1.234375 > ./events/in_accel_mag_falling_value
+ root:/sys/bus/iio/devices/iio:device0> echo 5 > ./events/in_accel_mag_falling_period
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_x\&y\&z_mag_falling_en
+
+ root:/sys/bus/iio/devices/iio:device0> iio_event_monitor adxl313
+ Found IIO device with name adxl313 with device number 0
+ Event: time: 1748796324115962975, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ Event: time: 1748796329329981772, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ Event: time: 1748796334543399706, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ ...
+ <every 5s now indicates inactivity>
+
+Now, enabling activity, e.g. the AC coupled counter-part ``ACTIVITY_AC``
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1.28125 > ./events/in_accel_mag_rising_value
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_x\|y\|z_mag_rising_en
+
+ root:/sys/bus/iio/devices/iio:device0> iio_event_monitor adxl313
+ Found IIO device with name adxl313 with device number 0
+ <some activity with the sensor>
+ Event: time: 1748796880354686777, type: accel(x|y|z), channel: 0, evtype: mag_adaptive, direction: rising
+ <5s of inactivity, then>
+ Event: time: 1748796885543252017, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ <some other activity detected by accelerating the sensor>
+ Event: time: 1748796887756634678, type: accel(x|y|z), channel: 0, evtype: mag_adaptive, direction: rising
+ <again, 5s of inactivity>
+ Event: time: 1748796892964368352, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ <stays like this until next activity in auto-sleep>
+
+Note, when AC coupling is in place, the event type will be of ``mag_adaptive``.
+AC- or DC-coupled (the default) events are used similarly.
+
+4. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/adxl345.rst b/Documentation/iio/adxl345.rst
new file mode 100644
index 000000000000..bb19d64f67c3
--- /dev/null
+++ b/Documentation/iio/adxl345.rst
@@ -0,0 +1,443 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+ADXL345 driver
+===============
+
+This driver supports Analog Device's ADXL345/375 on SPI/I2C bus.
+
+1. Supported Devices
+====================
+
+* `ADXL345 <https://www.analog.com/ADXL345>`_
+* `ADXL375 <https://www.analog.com/ADXL375>`_
+
+The ADXL345 is a generic purpose low power, 3-axis accelerometer with selectable
+measurement ranges. The ADXL345 supports the ±2 g, ±4 g, ±8 g, and ±16 g ranges.
+
+2. Device Attributes
+====================
+
+Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in questions. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following table shows the ADXL345 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
++-------------------------------------------+----------------------------------------------------------+
+| 3-Axis Accelerometer related device files | Description |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_sampling_frequency | Currently selected sample rate. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_sampling_frequency_available | Available sampling frequency configurations. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_scale | Scale/range for the accelerometer channels. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_scale_available | Available scale ranges for the accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_x_raw | Raw X-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibbias | y-axis acceleration offset correction |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_y_raw | Raw Y-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. |
++-------------------------------------------+----------------------------------------------------------+
+| in_accel_z_raw | Raw Z-axis accelerometer channel value. |
++-------------------------------------------+----------------------------------------------------------+
+
+Channel Processed Values
+-------------------------
+
+A channel value can be read from its _raw attribute. The value returned is the
+raw value as reported by the devices. To get the processed value of the channel,
+apply the following formula:
+
+.. code-block:: bash
+
+ processed value = (_raw + _offset) * _scale
+
+Where _offset and _scale are device attributes. If no _offset attribute is
+present, simply assume its value is 0.
+
++-------------------------------------+---------------------------+
+| Channel type | Measurement unit |
++-------------------------------------+---------------------------+
+| Acceleration on X, Y, and Z axis | Meters per second squared |
++-------------------------------------+---------------------------+
+
+Sensor Events
+-------------
+
+Specific IIO events are triggered by their corresponding interrupts. The sensor
+driver supports either none or a single active interrupt (INT) line, selectable
+from the two available options: INT1 or INT2. The active INT line should be
+specified in the device tree. If no INT line is configured, the sensor defaults
+to FIFO bypass mode, where event detection is disabled and only X, Y, and Z axis
+measurements are available.
+
+The table below lists the ADXL345-related device files located in the
+device-specific path: ``/sys/bus/iio/devices/iio:deviceX/events``.
+Note that activity and inactivity detection are DC-coupled by default;
+therefore, only the AC-coupled activity and inactivity events are explicitly
+listed.
+
++---------------------------------------------+---------------------------------------------+
+| Event handle | Description |
++---------------------------------------------+---------------------------------------------+
+| in_accel_gesture_doubletap_en | Enable double tap detection on all axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_gesture_doubletap_reset_timeout | Double tap window in [us] |
++---------------------------------------------+---------------------------------------------+
+| in_accel_gesture_doubletap_tap2_min_delay | Double tap latent in [us] |
++---------------------------------------------+---------------------------------------------+
+| in_accel_gesture_singletap_timeout | Single tap duration in [us] |
++---------------------------------------------+---------------------------------------------+
+| in_accel_gesture_singletap_value | Single tap threshold value in 62.5/LSB |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_falling_period | Inactivity time in seconds |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_falling_value | Inactivity threshold value in 62.5/LSB |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_adaptive_rising_en | Enable AC coupled activity on X axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_adaptive_falling_period | AC coupled inactivity time in seconds |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_adaptive_falling_value | AC coupled inactivity threshold in 62.5/LSB |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_adaptive_rising_value | AC coupled activity threshold in 62.5/LSB |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_rising_en | Enable activity detection on X axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_mag_rising_value | Activity threshold value in 62.5/LSB |
++---------------------------------------------+---------------------------------------------+
+| in_accel_x_gesture_singletap_en | Enable single tap detection on X axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_x&y&z_mag_falling_en | Enable inactivity detection on all axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_x&y&z_mag_adaptive_falling_en | Enable AC coupled inactivity on all axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_y_gesture_singletap_en | Enable single tap detection on Y axis |
++---------------------------------------------+---------------------------------------------+
+| in_accel_z_gesture_singletap_en | Enable single tap detection on Z axis |
++---------------------------------------------+---------------------------------------------+
+
+Please refer to the sensor's datasheet for a detailed description of this
+functionality.
+
+Manually setting the **ODR** will cause the driver to estimate default values
+for inactivity detection timing, where higher ODR values correspond to longer
+default wait times, and lower ODR values to shorter ones. If these defaults do
+not meet your application’s needs, you can explicitly configure the inactivity
+wait time. Setting this value to 0 will revert to the default behavior.
+
+When changing the **g range** configuration, the driver attempts to estimate
+appropriate activity and inactivity thresholds by scaling the default values
+based on the ratio of the previous range to the new one. The resulting threshold
+will never be zero and will always fall between 1 and 255, corresponding to up
+to 62.5 g/LSB as specified in the datasheet. However, you can override these
+estimated thresholds by setting explicit values.
+
+When **activity** and **inactivity** events are enabled, the driver
+automatically manages hysteresis behavior by setting the **link** and
+**auto-sleep** bits. The link bit connects the activity and inactivity
+functions, so that one follows the other. The auto-sleep function puts the
+sensor into sleep mode when inactivity is detected, reducing power consumption
+to the sub-12.5 Hz rate.
+
+The inactivity time is configurable between 1 and 255 seconds. In addition to
+inactivity detection, the sensor also supports free-fall detection, which, from
+the IIO perspective, is treated as a fall in magnitude across all axes. In
+sensor terms, free-fall is defined using an inactivity period ranging from 0.000
+to 1.000 seconds.
+
+The driver behaves as follows:
+
+* If the configured inactivity period is 1 second or more, the driver uses the
+ sensor's inactivity register. This allows the event to be linked with
+ activity detection, use auto-sleep, and be either AC- or DC-coupled.
+
+* If the inactivity period is less than 1 second, the event is treated as plain
+ inactivity or free-fall detection. In this case, auto-sleep and coupling
+ (AC/DC) are not applied.
+
+* If an inactivity time of 0 seconds is configured, the driver selects a
+ heuristically determined default period (greater than 1 second) to optimize
+ power consumption. This also uses the inactivity register.
+
+Note: According to the datasheet, the optimal ODR for detecting activity,
+or inactivity (or when operating with the free-fall register) should fall within
+the range of 12.5 Hz to 400 Hz. The recommended free-fall threshold is between
+300 mg and 600 mg (register values 0x05 to 0x09).
+
+In DC-coupled mode, the current acceleration magnitude is directly compared to
+the values in the THRESH_ACT and THRESH_INACT registers to determine activity or
+inactivity. In contrast, AC-coupled activity detection uses the acceleration
+value at the start of detection as a reference point, and subsequent samples are
+compared against this reference. While DC-coupling is the default mode-comparing
+live values to fixed thresholds-AC-coupling relies on an internal filter
+relative to the configured threshold.
+
+AC and DC coupling modes are configured separately for activity and inactivity
+detection, but only one mode can be active at a time for each. For example, if
+AC-coupled activity detection is enabled and then DC-coupled mode is set, only
+DC-coupled activity detection will be active. In other words, only the most
+recent configuration is applied.
+
+**Single tap** detection can be configured per the datasheet by setting the
+threshold and duration parameters. When only single tap detection is enabled,
+the single tap interrupt triggers as soon as the acceleration exceeds the
+threshold (marking the start of the duration) and then falls below it, provided
+the duration limit is not exceeded. If both single tap and double tap detections
+are enabled, the single tap interrupt is triggered only after the double tap
+event has been either confirmed or dismissed.
+
+To configure **double tap** detection, you must also set the window and latency
+parameters in microseconds (µs). The latency period begins once the single tap
+signal drops below the threshold and acts as a waiting time during which any
+spikes are ignored for double tap detection. After the latency period ends, the
+detection window starts. If the acceleration rises above the threshold and then
+falls below it again within this window, a double tap event is triggered upon
+the fall below the threshold.
+
+Double tap event detection is thoroughly explained in the datasheet. After a
+single tap event is detected, a double tap event may follow, provided the signal
+meets certain criteria. However, double tap detection can be invalidated for
+three reasons:
+
+* If the **suppress bit** is set, any acceleration spike above the tap
+ threshold during the tap latency period immediately invalidates the double tap
+ detection. In other words, no spikes are allowed during latency when the
+ suppress bit is active.
+
+* The double tap event is invalid if the acceleration is above the threshold at
+ the start of the double tap window.
+
+* Double tap detection is also invalidated if the acceleration duration exceeds
+ the limit set by the duration register.
+
+For double tap detection, the same duration applies as for single tap: the
+acceleration must rise above the threshold and then fall below it within the
+specified duration. Note that the suppress bit is typically enabled when double
+tap detection is active.
+
+Usage Examples
+--------------
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ adxl345
+
+Show accelerometer channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw
+ -1
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw
+ 2
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw
+ -253
+
+Set calibration offset for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 50 > in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 50
+
+Given the 13-bit full resolution, the available ranges are calculated by the
+following formula:
+
+.. code-block:: bash
+
+ (g * 2 * 9.80665) / (2^(resolution) - 1) * 100; for g := 2|4|8|16
+
+Scale range configuration:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat ./in_accel_scale
+ 0.478899
+ root:/sys/bus/iio/devices/iio:device0> cat ./in_accel_scale_available
+ 0.478899 0.957798 1.915595 3.831190
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1.915595 > ./in_accel_scale
+ root:/sys/bus/iio/devices/iio:device0> cat ./in_accel_scale
+ 1.915595
+
+Set output data rate (ODR):
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat ./in_accel_sampling_frequency
+ 200.000000
+
+ root:/sys/bus/iio/devices/iio:device0> cat ./in_accel_sampling_frequency_available
+ 0.097000 0.195000 0.390000 0.781000 1.562000 3.125000 6.250000 12.500000 25.000000 50.000000 100.000000 200.000000 400.000000 800.000000 1600.000000 3200.000000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1.562000 > ./in_accel_sampling_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat ./in_accel_sampling_frequency
+ 1.562000
+
+Configure one or several events:
+
+.. code-block:: bash
+
+ root:> cd /sys/bus/iio/devices/iio:device0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./buffer0/in_accel_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./buffer0/in_accel_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./buffer0/in_accel_z_en
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./scan_elements/in_accel_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./scan_elements/in_accel_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./scan_elements/in_accel_z_en
+
+ root:/sys/bus/iio/devices/iio:device0> echo 14 > ./in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> echo 2 > ./in_accel_y_calibbias
+ root:/sys/bus/iio/devices/iio:device0> echo -250 > ./in_accel_z_calibbias
+
+ root:/sys/bus/iio/devices/iio:device0> echo 24 > ./buffer0/length
+
+ ## AC coupled activity, threshold [62.5/LSB]
+ root:/sys/bus/iio/devices/iio:device0> echo 6 > ./events/in_accel_mag_adaptive_rising_value
+
+ ## AC coupled inactivity, threshold, [62.5/LSB]
+ root:/sys/bus/iio/devices/iio:device0> echo 4 > ./events/in_accel_mag_adaptive_falling_value
+
+ ## AC coupled inactivity, time [s]
+ root:/sys/bus/iio/devices/iio:device0> echo 3 > ./events/in_accel_mag_adaptive_falling_period
+
+ ## singletap, threshold
+ root:/sys/bus/iio/devices/iio:device0> echo 35 > ./events/in_accel_gesture_singletap_value
+
+ ## singletap, duration [us]
+ root:/sys/bus/iio/devices/iio:device0> echo 0.001875 > ./events/in_accel_gesture_singletap_timeout
+
+ ## doubletap, window [us]
+ root:/sys/bus/iio/devices/iio:device0> echo 0.025 > ./events/in_accel_gesture_doubletap_reset_timeout
+
+ ## doubletap, latent [us]
+ root:/sys/bus/iio/devices/iio:device0> echo 0.025 > ./events/in_accel_gesture_doubletap_tap2_min_delay
+
+ ## AC coupled activity, enable
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_mag_adaptive_rising_en
+
+ ## AC coupled inactivity, enable
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_x\&y\&z_mag_adaptive_falling_en
+
+ ## singletap, enable
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_x_gesture_singletap_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_y_gesture_singletap_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_z_gesture_singletap_en
+
+ ## doubletap, enable
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > ./events/in_accel_gesture_doubletap_en
+
+Verify incoming events:
+
+.. code-block:: bash
+
+ root:# iio_event_monitor adxl345
+ Found IIO device with name adxl345 with device number 0
+ Event: time: 1739063415957073383, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063415963770218, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063416002563061, type: accel(z), channel: 0, evtype: gesture, direction: singletap
+ Event: time: 1739063426271128739, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ Event: time: 1739063436539080713, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ Event: time: 1739063438357970381, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063446726161586, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063446727892670, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063446743019768, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063446744650696, type: accel(z), channel: 0, evtype: mag, direction: rising
+ Event: time: 1739063446763559386, type: accel(z), channel: 0, evtype: gesture, direction: singletap
+ Event: time: 1739063448818126480, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ ...
+
+Activity and inactivity belong together and indicate state changes as follows
+
+.. code-block:: bash
+
+ root:# iio_event_monitor adxl345
+ Found IIO device with name adxl345 with device number 0
+ Event: time: 1744648001133946293, type: accel(x), channel: 0, evtype: mag, direction: rising
+ <after inactivity time elapsed>
+ Event: time: 1744648057724775499, type: accel(x&y&z), channel: 0, evtype: mag, direction: falling
+ ...
+
+3. Device Buffers
+=================
+
+This driver supports IIO buffers.
+
+All devices support retrieving the raw acceleration and temperature measurements
+using buffers.
+
+Usage examples
+--------------
+
+Select channels for buffer read:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_z_en
+
+Set the number of samples to be stored in the buffer:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
+
+Enable buffer readings:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+Obtain buffered data:
+
+.. code-block:: bash
+
+ root:> iio_readdev -b 16 -s 1024 adxl345 | hexdump -d
+ WARNING: High-speed mode not enabled
+ 0000000 00003 00012 00013 00005 00010 00011 00005 00011
+ 0000010 00013 00004 00012 00011 00003 00012 00014 00007
+ 0000020 00011 00013 00004 00013 00014 00003 00012 00013
+ 0000030 00004 00012 00013 00005 00011 00011 00005 00012
+ 0000040 00014 00005 00012 00014 00004 00010 00012 00004
+ 0000050 00013 00011 00003 00011 00012 00005 00011 00013
+ 0000060 00003 00012 00012 00003 00012 00012 00004 00012
+ 0000070 00012 00003 00013 00013 00003 00013 00012 00005
+ 0000080 00012 00013 00003 00011 00012 00005 00012 00013
+ 0000090 00003 00013 00011 00005 00013 00014 00003 00012
+ 00000a0 00012 00003 00012 00013 00004 00012 00015 00004
+ 00000b0 00014 00011 00003 00014 00013 00004 00012 00011
+ 00000c0 00004 00012 00013 00004 00014 00011 00004 00013
+ 00000d0 00012 00002 00014 00012 00005 00012 00013 00005
+ 00000e0 00013 00013 00003 00013 00013 00005 00012 00013
+ 00000f0 00004 00014 00015 00005 00012 00011 00005 00012
+ ...
+
+See Documentation/iio/iio_devbuf.rst for more information about how buffered
+data is structured.
+
+4. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/adxl380.rst b/Documentation/iio/adxl380.rst
new file mode 100644
index 000000000000..61cafa2f98bf
--- /dev/null
+++ b/Documentation/iio/adxl380.rst
@@ -0,0 +1,233 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+ADXL380 driver
+===============
+
+This driver supports Analog Device's ADXL380/382 on SPI/I2C bus.
+
+1. Supported devices
+====================
+
+* `ADXL380 <https://www.analog.com/ADXL380>`_
+* `ADXL382 <https://www.analog.com/ADXL382>`_
+
+The ADXL380/ADXL382 is a low noise density, low power, 3-axis accelerometer with
+selectable measurement ranges. The ADXL380 supports the ±4 g, ±8 g, and ±16 g
+ranges, and the ADXL382 supports ±15 g, ±30 g, and ±60 g ranges.
+
+2. Device attributes
+====================
+
+Accelerometer measurements are always provided.
+
+Temperature data are also provided. This data can be used to monitor the
+internal system temperature or to improve the temperature stability of the
+device via calibration.
+
+Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``,
+where X is the IIO index of the device. Under these folders reside a set of
+device files, depending on the characteristics and features of the hardware
+device in questions. These files are consistently generalized and documented in
+the IIO ABI documentation.
+
+The following tables show the adxl380 related device files, found in the
+specific device folder path ``/sys/bus/iio/devices/iio:deviceX``.
+
++---------------------------------------------------+----------------------------------------------------------+
+| 3-Axis Accelerometer related device files | Description |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_scale | Scale for the accelerometer channels. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_filter_high_pass_3db_frequency | Low pass filter bandwidth. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_filter_high_pass_3db_frequency_available | Available low pass filter bandwidth configurations. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_filter_low_pass_3db_frequency | High pass filter bandwidth. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_filter_low_pass_3db_frequency_available | Available high pass filter bandwidth configurations. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_x_raw | Raw X-axis accelerometer channel value. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_y_calibbias | y-axis acceleration offset correction |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_y_raw | Raw Y-axis accelerometer channel value. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. |
++---------------------------------------------------+----------------------------------------------------------+
+| in_accel_z_raw | Raw Z-axis accelerometer channel value. |
++---------------------------------------------------+----------------------------------------------------------+
+
++----------------------------------+--------------------------------------------+
+| Temperature sensor related files | Description |
++----------------------------------+--------------------------------------------+
+| in_temp_raw | Raw temperature channel value. |
++----------------------------------+--------------------------------------------+
+| in_temp_offset | Offset for the temperature sensor channel. |
++----------------------------------+--------------------------------------------+
+| in_temp_scale | Scale for the temperature sensor channel. |
++----------------------------------+--------------------------------------------+
+
++------------------------------+----------------------------------------------+
+| Miscellaneous device files | Description |
++------------------------------+----------------------------------------------+
+| name | Name of the IIO device. |
++------------------------------+----------------------------------------------+
+| sampling_frequency | Currently selected sample rate. |
++------------------------------+----------------------------------------------+
+| sampling_frequency_available | Available sampling frequency configurations. |
++------------------------------+----------------------------------------------+
+
+Channels processed values
+-------------------------
+
+A channel value can be read from its _raw attribute. The value returned is the
+raw value as reported by the devices. To get the processed value of the channel,
+apply the following formula:
+
+.. code-block:: bash
+
+ processed value = (_raw + _offset) * _scale
+
+Where _offset and _scale are device attributes. If no _offset attribute is
+present, simply assume its value is 0.
+
+The ADXL380 driver offers data for 2 types of channels, the table below shows
+the measurement units for the processed value, which are defined by the IIO
+framework:
+
++-------------------------------------+---------------------------+
+| Channel type | Measurement unit |
++-------------------------------------+---------------------------+
+| Acceleration on X, Y, and Z axis | Meters per Second squared |
++-------------------------------------+---------------------------+
+| Temperature | Millidegrees Celsius |
++-------------------------------------+---------------------------+
+
+Usage examples
+--------------
+
+Show device name:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat name
+ adxl382
+
+Show accelerometer channels value:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw
+ -1771
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw
+ 282
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw
+ -1523
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale
+ 0.004903325
+
+- X-axis acceleration = in_accel_x_raw * in_accel_scale = −8.683788575 m/s^2
+- Y-axis acceleration = in_accel_y_raw * in_accel_scale = 1.38273765 m/s^2
+- Z-axis acceleration = in_accel_z_raw * in_accel_scale = -7.467763975 m/s^2
+
+Set calibration offset for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 0
+
+ root:/sys/bus/iio/devices/iio:device0> echo 50 > in_accel_x_calibbias
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias
+ 50
+
+Set sampling frequency:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency
+ 16000
+ root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency_available
+ 16000 32000 64000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 32000 > sampling_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency
+ 32000
+
+Set low pass filter bandwidth for accelerometer channels:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency
+ 32000
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency_available
+ 32000 8000 4000 2000
+
+ root:/sys/bus/iio/devices/iio:device0> echo 2000 > in_accel_filter_low_pass_3db_frequency
+ root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency
+ 2000
+
+3. Device buffers
+=================
+
+This driver supports IIO buffers.
+
+All devices support retrieving the raw acceleration and temperature measurements
+using buffers.
+
+Usage examples
+--------------
+
+Select channels for buffer read:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_x_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_y_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_accel_z_en
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp_en
+
+Set the number of samples to be stored in the buffer:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length
+
+Enable buffer readings:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable
+
+Obtain buffered data:
+
+.. code-block:: bash
+
+ root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0
+ ...
+ 002bc300 f7 e7 00 a8 fb c5 24 80 f7 e7 01 04 fb d6 24 80 |......$.......$.|
+ 002bc310 f7 f9 00 ab fb dc 24 80 f7 c3 00 b8 fb e2 24 80 |......$.......$.|
+ 002bc320 f7 fb 00 bb fb d1 24 80 f7 b1 00 5f fb d1 24 80 |......$...._..$.|
+ 002bc330 f7 c4 00 c6 fb a6 24 80 f7 a6 00 68 fb f1 24 80 |......$....h..$.|
+ 002bc340 f7 b8 00 a3 fb e7 24 80 f7 9a 00 b1 fb af 24 80 |......$.......$.|
+ 002bc350 f7 b1 00 67 fb ee 24 80 f7 96 00 be fb 92 24 80 |...g..$.......$.|
+ 002bc360 f7 ab 00 7a fc 1b 24 80 f7 b6 00 ae fb 76 24 80 |...z..$......v$.|
+ 002bc370 f7 ce 00 a3 fc 02 24 80 f7 c0 00 be fb 8b 24 80 |......$.......$.|
+ 002bc380 f7 c3 00 93 fb d0 24 80 f7 ce 00 d8 fb c8 24 80 |......$.......$.|
+ 002bc390 f7 bd 00 c0 fb 82 24 80 f8 00 00 e8 fb db 24 80 |......$.......$.|
+ 002bc3a0 f7 d8 00 d3 fb b4 24 80 f8 0b 00 e5 fb c3 24 80 |......$.......$.|
+ 002bc3b0 f7 eb 00 c8 fb 92 24 80 f7 e7 00 ea fb cb 24 80 |......$.......$.|
+ 002bc3c0 f7 fd 00 cb fb 94 24 80 f7 e3 00 f2 fb b8 24 80 |......$.......$.|
+ ...
+
+See Documentation/iio/iio_devbuf.rst for more information about how buffered
+data is structured.
+
+4. IIO Interfacing Tools
+========================
+
+See Documentation/iio/iio_tools.rst for the description of the available IIO
+interfacing tools.
diff --git a/Documentation/iio/bno055.rst b/Documentation/iio/bno055.rst
new file mode 100644
index 000000000000..c6042586b2ae
--- /dev/null
+++ b/Documentation/iio/bno055.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+BNO055 driver
+==============================
+
+1. Overview
+===========
+
+This driver supports Bosch BNO055 IMUs (on both serial and I2C busses).
+
+Accelerometer, magnetometer and gyroscope measurements are always available.
+When "fusion_enable" sysfs attribute is set to 1, orientation (both Euler
+angles and quaternion), linear velocity and gravity vector are also
+provided, but some sensor settings (e.g. low pass filtering and range)
+become locked (the IMU firmware controls them).
+
+This driver supports also IIO buffers.
+
+2. Calibration
+==============
+
+The IMU continuously performs an autocalibration procedure if (and only if)
+operating in fusion mode. The magnetometer autocalibration can however be
+disabled by writing 0 in the sysfs in_magn_calibration_fast_enable attribute.
+
+The driver provides access to autocalibration flags (i.e. you can determine
+if the IMU has successfully autocalibrated) and to the calibration data blob.
+
+The user can save this blob in a firmware file (i.e. in /lib/firmware) that
+the driver looks for at probe time. If found, then the IMU is initialized
+with this calibration data. This saves the user from performing the
+calibration procedure every time (which consists of moving the IMU in
+various ways).
+
+The driver looks for calibration data file using two different names: first
+a file whose name is suffixed with the IMU unique ID (exposed in sysfs as
+serial_number) is searched for; this is useful when there is more than one
+IMU instance. If this file is not found, then a "generic" calibration file
+is searched for (which can be used when only one IMU is present, without
+struggling with fancy names, that change on each device).
+
+Valid calibration file names would be e.g.
+ bno055-caldata-0e7c26a33541515120204a35342b04ff.dat
+ bno055-caldata.dat
+
+In non-fusion mode the IIO 'offset' attributes provide access to the
+offsets from calibration data (if any), so that the user can apply them to
+the accel, angvel and magn IIO attributes. In fusion mode they are not
+needed (the IMU firmware internally applies those corrections) and they
+read as zero.
diff --git a/Documentation/iio/iio_adc.rst b/Documentation/iio/iio_adc.rst
new file mode 100644
index 000000000000..f2f19a691907
--- /dev/null
+++ b/Documentation/iio/iio_adc.rst
@@ -0,0 +1,305 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=========================
+IIO Abstractions for ADCs
+=========================
+
+1. Overview
+===========
+
+The IIO subsystem supports many Analog to Digital Converters (ADCs). Some ADCs
+have features and characteristics that are supported in specific ways by IIO
+device drivers. This documentation describes common ADC features and explains
+how they are supported by the IIO subsystem.
+
+1. ADC Channel Types
+====================
+
+ADCs can have distinct types of inputs, each of them measuring analog voltages
+in a slightly different way. An ADC digitizes the analog input voltage over a
+span that is often given by the provided voltage reference, the input type, and
+the input polarity. The input range allowed to an ADC channel is needed to
+determine the scale factor and offset needed to obtain the measured value in
+real-world units (millivolts for voltage measurement, milliamps for current
+measurement, etc.).
+
+Elaborate designs may have nonlinear characteristics or integrated components
+(such as amplifiers and reference buffers) that might also have to be considered
+to derive the allowed input range for an ADC. For clarity, the sections below
+assume the input range only depends on the provided voltage references, input
+type, and input polarity.
+
+There are three general types of ADC inputs (single-ended, differential,
+pseudo-differential) and two possible polarities (unipolar, bipolar). The input
+type (single-ended, differential, pseudo-differential) is one channel
+characteristic, and is completely independent of the polarity (unipolar,
+bipolar) aspect. A comprehensive article about ADC input types (on which this
+doc is heavily based on) can be found at
+https://www.analog.com/en/resources/technical-articles/sar-adc-input-types.html.
+
+1.1 Single-ended channels
+-------------------------
+
+Single-ended channels digitize the analog input voltage relative to ground and
+can be either unipolar or bipolar.
+
+1.1.1 Single-ended Unipolar Channels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ ---------- VREF -------------
+ ´ ` ´ ` _____________
+ / \ / \ / |
+ / \ / \ --- < IN ADC |
+ \ / \ / \ |
+ `-´ `-´ \ VREF |
+ -------- GND (0V) ----------- +-----------+
+ ^
+ |
+ External VREF
+
+The input voltage to a **single-ended unipolar** channel is allowed to swing
+from GND to VREF (where VREF is a voltage reference with electrical potential
+higher than system ground). The maximum input voltage is also called VFS
+(Voltage input Full-Scale), with VFS being determined by VREF. The voltage
+reference may be provided from an external supply or derived from the chip power
+source.
+
+A single-ended unipolar channel could be described in device tree like the
+following example::
+
+ adc@0 {
+ ...
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ };
+ };
+
+One is always allowed to include ADC channel nodes in the device tree. Though,
+if the device has a uniform set of inputs (e.g. all inputs are single-ended),
+then declaring the channel nodes is optional.
+
+One caveat for devices that support mixed single-ended and differential channels
+is that single-ended channel nodes also need to provide a ``single-channel``
+property when ``reg`` is an arbitrary number that doesn't match the input pin
+number.
+
+See ``Documentation/devicetree/bindings/iio/adc/adc.yaml`` for the complete
+documentation of ADC specific device tree properties.
+
+
+1.1.2 Single-ended Bipolar Channels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ ---------- +VREF ------------
+ ´ ` ´ ` _____________________
+ / \ / \ / |
+ / \ / \ --- < IN ADC |
+ \ / \ / \ |
+ `-´ `-´ \ +VREF -VREF |
+ ---------- -VREF ------------ +-------------------+
+ ^ ^
+ | |
+ External +VREF ------+ External -VREF
+
+For a **single-ended bipolar** channel, the analog voltage input can go from
+-VREF to +VREF (where -VREF is the voltage reference that has the lower
+electrical potential while +VREF is the reference with the higher one). Some ADC
+chips derive the lower reference from +VREF, others get it from a separate
+input. Often, +VREF and -VREF are symmetric but they don't need to be so. When
+-VREF is lower than system ground, these inputs are also called single-ended
+true bipolar. Also, while there is a relevant difference between bipolar and
+true bipolar from the electrical perspective, IIO makes no explicit distinction
+between them.
+
+Here's an example device tree description of a single-ended bipolar channel::
+
+ adc@0 {
+ ...
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ bipolar;
+ };
+ };
+
+1.2 Differential channels
+-------------------------
+
+A differential voltage measurement digitizes the voltage level at the positive
+input (IN+) relative to the negative input (IN-) over the -VREF to +VREF span.
+In other words, a differential channel measures the potential difference between
+IN+ and IN-, which is often denoted by the IN+ - IN- formula.
+
+1.2.1 Differential Bipolar Channels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ -------- +VREF ------ +-------------------+
+ ´ ` ´ ` / |
+ / \ / \ / --- < IN+ |
+ `-´ `-´ | |
+ -------- -VREF ------ | |
+ | ADC |
+ -------- +VREF ------ | |
+ ´ ` ´ ` | |
+ \ / \ / \ --- < IN- |
+ `-´ `-´ \ +VREF -VREF |
+ -------- -VREF ------ +-------------------+
+ ^ ^
+ | +---- External -VREF
+ External +VREF
+
+The analog signals to **differential bipolar** inputs are also allowed to swing
+from -VREF to +VREF. The bipolar part of the name means that the resulting value
+of the difference (IN+ - IN-) can be positive or negative. If -VREF is below
+system GND, these are also called differential true bipolar inputs.
+
+Device tree example of a differential bipolar channel::
+
+ adc@0 {
+ ...
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ bipolar;
+ diff-channels = <0 1>;
+ };
+ };
+
+In the ADC driver, ``differential = 1`` is set into ``struct iio_chan_spec`` for
+the channel. Even though, there are three general input types, ``differential``
+is only used to distinguish between differential and non-differential (either
+single-ended or pseudo-differential) input types. See
+``include/linux/iio/iio.h`` for more information.
+
+1.2.2 Differential Unipolar Channels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For **differential unipolar** channels, the analog voltage at the positive input
+must also be higher than the voltage at the negative input. Thus, the actual
+input range allowed to a differential unipolar channel is IN- to +VREF. Because
+IN+ is allowed to swing with the measured analog signal and the input setup must
+guarantee IN+ will not go below IN- (nor IN- will raise above IN+), most
+differential unipolar channel setups have IN- fixed to a known voltage that does
+not fall within the voltage range expected for the measured signal. That leads
+to a setup that is equivalent to a pseudo-differential channel. Thus,
+differential unipolar setups can often be supported as pseudo-differential
+unipolar channels.
+
+1.3 Pseudo-differential Channels
+--------------------------------
+
+There is a third ADC input type which is called pseudo-differential or
+single-ended to differential configuration. A pseudo-differential channel is
+similar to a differential channel in that it also measures IN+ relative to IN-.
+However, unlike bipolar differential channels, the negative input is limited to
+a narrow voltage range (taken as a constant voltage) while only IN+ is allowed
+to swing. A pseudo-differential channel can be made out from a differential pair
+of inputs by restricting the negative input to a known voltage while allowing
+only the positive input to swing. Sometimes, the input provided to IN- is called
+common-mode voltage. Besides, some parts have a COM pin that allows single-ended
+inputs to be referenced to a common-mode voltage, making them
+pseudo-differential channels. Often, the common mode input voltage can be
+described in the device tree as a voltage regulator (e.g. ``com-supply``) since
+it is basically a constant voltage source.
+
+1.3.1 Pseudo-differential Unipolar Channels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ -------- +VREF ------ +-------------------+
+ ´ ` ´ ` / |
+ / \ / \ / --- < IN+ |
+ `-´ `-´ | |
+ --------- IN- ------- | ADC |
+ | |
+ Common-mode voltage --> --- < IN- |
+ \ +VREF -VREF |
+ +-------------------+
+ ^ ^
+ | +---- External -VREF
+ External +VREF
+
+A **pseudo-differential unipolar** input has the limitations a differential
+unipolar channel would have, meaning the analog voltage to the positive input
+IN+ must stay within IN- to +VREF. The fixed voltage to IN- is often called
+common-mode voltage and it must be within -VREF to +VREF as would be expected
+from the signal to any differential channel negative input.
+
+The voltage measured from IN+ is relative to IN- but, unlike differential
+channels, pseudo-differential setups are intended to gauge single-ended input
+signals. To enable applications to calculate IN+ voltage with respect to system
+ground, the IIO channel may provide an ``_offset`` sysfs attribute to be added
+to ADC output when converting raw data to voltage units. In many setups, the
+common-mode voltage input is at GND level and the ``_offset`` attribute is
+omitted due to being always zero.
+
+Device tree example for pseudo-differential unipolar channel::
+
+ adc@0 {
+ ...
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ single-channel = <0>;
+ common-mode-channel = <1>;
+ };
+ };
+
+Do not set ``differential`` in the channel ``iio_chan_spec`` struct of
+pseudo-differential channels.
+
+1.3.2 Pseudo-differential Bipolar Channels
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ -------- +VREF ------ +-------------------+
+ ´ ` ´ ` / |
+ / \ / \ / --- < IN+ |
+ `-´ `-´ | |
+ -------- -VREF ------ | ADC |
+ | |
+ Common-mode voltage --> --- < IN- |
+ \ +VREF -VREF |
+ +-------------------+
+ ^ ^
+ | +---- External -VREF
+ External +VREF
+
+A **pseudo-differential bipolar** input is not limited by the level at IN- but
+it will be limited to -VREF or to GND on the lower end of the input range
+depending on the particular ADC. Similar to their unipolar counter parts,
+pseudo-differential bipolar channels ought to declare an ``_offset`` attribute
+to enable the conversion of raw ADC data to voltage units. For the setup with
+IN- connected to GND, ``_offset`` is often omitted.
+
+Device tree example for pseudo-differential bipolar channel::
+
+ adc@0 {
+ ...
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ bipolar;
+ single-channel = <0>;
+ common-mode-channel = <1>;
+ };
+ };
diff --git a/Documentation/iio/iio_devbuf.rst b/Documentation/iio/iio_devbuf.rst
new file mode 100644
index 000000000000..dca1f0200b0d
--- /dev/null
+++ b/Documentation/iio/iio_devbuf.rst
@@ -0,0 +1,152 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================
+Industrial IIO device buffers
+=============================
+
+1. Overview
+===========
+
+The Industrial I/O core offers a way for continuous data capture based on a
+trigger source. Multiple data channels can be read at once from
+``/dev/iio:deviceX`` character device node, thus reducing the CPU load.
+
+Devices with buffer support feature an additional sub-directory in the
+``/sys/bus/iio/devices/iio:deviceX/`` directory hierarchy, called bufferY, where
+Y defaults to 0, for devices with a single buffer.
+
+2. Buffer attributes
+====================
+
+An IIO buffer has an associated attributes directory under
+``/sys/bus/iio/iio:deviceX/bufferY/``. The attributes are described below.
+
+``length``
+----------
+
+Read / Write attribute which states the total number of data samples (capacity)
+that can be stored by the buffer.
+
+``enable``
+----------
+
+Read / Write attribute which starts / stops the buffer capture. This file should
+be written last, after length and selection of scan elements. Writing a non-zero
+value may result in an error, such as EINVAL, if, for example, an unsupported
+combination of channels is given.
+
+``watermark``
+-------------
+
+Read / Write positive integer attribute specifying the maximum number of scan
+elements to wait for.
+
+Poll will block until the watermark is reached.
+
+Blocking read will wait until the minimum between the requested read amount or
+the low watermark is available.
+
+Non-blocking read will retrieve the available samples from the buffer even if
+there are less samples than the watermark level. This allows the application to
+block on poll with a timeout and read the available samples after the timeout
+expires and thus have a maximum delay guarantee.
+
+Data available
+--------------
+
+Read-only attribute indicating the bytes of data available in the buffer. In the
+case of an output buffer, this indicates the amount of empty space available to
+write data to. In the case of an input buffer, this indicates the amount of data
+available for reading.
+
+Scan elements
+-------------
+
+The meta information associated with a channel data placed in a buffer is called
+a scan element. The scan elements attributes are presented below.
+
+**_en**
+
+Read / Write attribute used for enabling a channel. If and only if its value
+is non-zero, then a triggered capture will contain data samples for this
+channel.
+
+**_index**
+
+Read-only unsigned integer attribute specifying the position of the channel in
+the buffer. Note these are not dependent on what is enabled and may not be
+contiguous. Thus for userspace to establish the full layout these must be used
+in conjunction with all _en attributes to establish which channels are present,
+and the relevant _type attributes to establish the data storage format.
+
+**_type**
+
+Read-only attribute containing the description of the scan element data storage
+within the buffer and hence the form in which it is read from userspace. Format
+is [be|le]:[s|u]bits/storagebits[Xrepeat][>>shift], where:
+
+- **be** or **le** specifies big or little-endian.
+- **s** or **u** specifies if signed (2's complement) or unsigned.
+- **bits** is the number of valid data bits.
+- **storagebits** is the number of bits (after padding) that it occupies in the
+ buffer.
+- **repeat** specifies the number of bits/storagebits repetitions. When the
+ repeat element is 0 or 1, then the repeat value is omitted.
+- **shift** if specified, is the shift that needs to be applied prior to
+ masking out unused bits.
+
+For example, a driver for a 3-axis accelerometer with 12-bit resolution where
+data is stored in two 8-bit registers is as follows::
+
+ 7 6 5 4 3 2 1 0
+ +---+---+---+---+---+---+---+---+
+ |D3 |D2 |D1 |D0 | X | X | X | X | (LOW byte, address 0x06)
+ +---+---+---+---+---+---+---+---+
+
+ 7 6 5 4 3 2 1 0
+ +---+---+---+---+---+---+---+---+
+ |D11|D10|D9 |D8 |D7 |D6 |D5 |D4 | (HIGH byte, address 0x07)
+ +---+---+---+---+---+---+---+---+
+
+will have the following scan element type for each axis:
+
+.. code-block:: bash
+
+ $ cat /sys/bus/iio/devices/iio:device0/buffer0/in_accel_y_type
+ le:s12/16>>4
+
+A userspace application will interpret data samples read from the buffer as
+two-byte little-endian signed data, that needs a 4 bits right shift before
+masking out the 12 valid bits of data.
+
+It is also worth mentioning that the data in the buffer will be naturally
+aligned, so the userspace application has to handle the buffers accordingly.
+
+Take for example, a driver with four channels with the following description:
+- channel0: index: 0, type: be:u16/16>>0
+- channel1: index: 1, type: be:u32/32>>0
+- channel2: index: 2, type: be:u32/32>>0
+- channel3: index: 3, type: be:u64/64>>0
+
+If all channels are enabled, the data will be aligned in the buffer as follows::
+
+ 0-1 2 3 4-7 8-11 12 13 14 15 16-23 -> buffer byte number
+ +-----+---+---+-----+-----+---+---+---+---+-----+
+ |CHN_0|PAD|PAD|CHN_1|CHN_2|PAD|PAD|PAD|PAD|CHN_3| -> buffer content
+ +-----+---+---+-----+-----+---+---+---+---+-----+
+
+If only channel0 and channel3 are enabled, the data will be aligned in the
+buffer as follows::
+
+ 0-1 2 3 4 5 6 7 8-15 -> buffer byte number
+ +-----+---+---+---+---+---+---+-----+
+ |CHN_0|PAD|PAD|PAD|PAD|PAD|PAD|CHN_3| -> buffer content
+ +-----+---+---+---+---+---+---+-----+
+
+Typically the buffered data is found in raw format (unscaled with no offset
+applied), however there are corner cases in which the buffered data may be found
+in a processed form. Please note that these corner cases are not addressed by
+this documentation.
+
+Please see Documentation/ABI/testing/sysfs-bus-iio for a complete
+description of the attributes.
diff --git a/Documentation/iio/iio_dmabuf_api.rst b/Documentation/iio/iio_dmabuf_api.rst
new file mode 100644
index 000000000000..2836cadbd495
--- /dev/null
+++ b/Documentation/iio/iio_dmabuf_api.rst
@@ -0,0 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===================================
+High-speed DMABUF interface for IIO
+===================================
+
+1. Overview
+===========
+
+The Industrial I/O subsystem supports access to buffers through a
+file-based interface, with read() and write() access calls through the
+IIO device's dev node.
+
+It additionally supports a DMABUF based interface, where the userspace
+can attach DMABUF objects (externally created) to an IIO buffer, and
+subsequently use them for data transfers.
+
+A userspace application can then use this interface to share DMABUF
+objects between several interfaces, allowing it to transfer data in a
+zero-copy fashion, for instance between IIO and the USB stack.
+
+The userspace application can also memory-map the DMABUF objects, and
+access the sample data directly. The advantage of doing this vs. the
+read() interface is that it avoids an extra copy of the data between the
+kernel and userspace. This is particularly useful for high-speed devices
+which produce several megabytes or even gigabytes of data per second.
+It does however increase the userspace-kernelspace synchronization
+overhead, as the DMA_BUF_SYNC_START and DMA_BUF_SYNC_END IOCTLs have to
+be used for data integrity.
+
+2. User API
+===========
+
+As part of this interface, three new IOCTLs have been added. These three
+IOCTLs have to be performed on the IIO buffer's file descriptor, which
+can be obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
+
+ ``IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd)``
+ Attach the DMABUF object, identified by its file descriptor, to the
+ IIO buffer. Returns zero on success, and a negative errno value on
+ error.
+
+ ``IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd)``
+ Detach the given DMABUF object, identified by its file descriptor,
+ from the IIO buffer. Returns zero on success, and a negative errno
+ value on error.
+
+ Note that closing the IIO buffer's file descriptor will
+ automatically detach all previously attached DMABUF objects.
+
+ ``IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *iio_dmabuf)``
+ Enqueue a previously attached DMABUF object to the buffer queue.
+ Enqueued DMABUFs will be read from (if output buffer) or written to
+ (if input buffer) as long as the buffer is enabled.
diff --git a/Documentation/iio/iio_tools.rst b/Documentation/iio/iio_tools.rst
new file mode 100644
index 000000000000..cc691c7f6365
--- /dev/null
+++ b/Documentation/iio/iio_tools.rst
@@ -0,0 +1,27 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+IIO Interfacing Tools
+=====================
+
+1. Linux Kernel Tools
+=====================
+
+Linux Kernel provides some userspace tools that can be used to retrieve data
+from IIO sysfs:
+
+* lsiio: example application that provides a list of IIO devices and triggers
+* iio_event_monitor: example application that reads events from an IIO device
+ and prints them
+* iio_generic_buffer: example application that reads data from buffer
+* iio_utils: set of APIs, typically used to access sysfs files.
+
+2. LibIIO
+=========
+
+LibIIO is a C/C++ library that provides generic access to IIO devices. The
+library abstracts the low-level details of the hardware, and provides a simple
+yet complete programming interface that can be used for advanced projects.
+
+For more information about LibIIO, please see:
+https://github.com/analogdevicesinc/libiio
diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index 58b7a4ebac51..315ae37d6fd4 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -7,6 +7,34 @@ Industrial I/O
.. toctree::
:maxdepth: 1
+ iio_adc
iio_configfs
+ iio_devbuf
+ iio_dmabuf_api
+ iio_tools
+Industrial I/O Kernel Drivers
+=============================
+
+.. toctree::
+ :maxdepth: 1
+
+ ad3552r
+ ad4000
+ ad4030
+ ad4695
+ ad7191
+ ad7380
+ ad7606
+ ad7625
+ ad7944
+ ade9000
+ adis16475
+ adis16480
+ adis16550
+ adxl313
+ adxl380
+ adxl345
+ bno055
ep93xx_adc
+ opt4060
diff --git a/Documentation/iio/opt4060.rst b/Documentation/iio/opt4060.rst
new file mode 100644
index 000000000000..eb155089b6d2
--- /dev/null
+++ b/Documentation/iio/opt4060.rst
@@ -0,0 +1,61 @@
+==============================
+OPT4060 driver
+==============================
+
+1. Overview
+=============================
+
+This driver supports the Texas Instrument RGBW high resolution color sensor over
+I2C.
+https://www.ti.com/lit/gpn/opt4060
+
+The driver supports:
+- Raw values for red, green, blue and clear.
+- Illuminance values.
+- Scaled color values for red, green and blue.
+- IIO events for thresholds.
+- IIO triggered buffer using both its own data ready trigger and triggers from
+other drivers.
+
+2. Illuminance calculation
+=============================
+
+Illuminance is calculated using the wide spectrum green channel.
+
+lux = GREEN_RAW x 2.15e-3
+
+The value is accessed from:
+/sys/bus/iio/devices/iio:deviceX/in_illuminance_input
+
+See section 8.4.5.2 in the data sheet for additional details.
+
+3. Color scale values
+=============================
+
+The sensor has different sensitivity for the different color components and
+compensating factors are exposed from the driver.
+
+The values are accessed from:
+/sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
+/sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
+/sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
+
+A userspace application can multiply the raw values with the scale values so
+that for a particular test light source, typically white, the measurement
+intensity is the same across the different color channels. This is calculated
+in the following way:
+
+R = RED_RAW x SCALE_RED(2.4)
+G = GREEN_RAW x SCALE_GREEN(1.0)
+B = BLUE_RAW x SCALE_BLUE(1.3)
+
+The data sheet suggests using the scaled values to normalize the scaled R, G
+and B values. This is useful to get a value for the ratio between colors
+independent of light intensity. A userspace application can do this in the
+following way:
+
+R_NORMALIZED = R / (R + G + B)
+G_NORMALIZED = G / (R + G + B)
+B_NORMALIZED = B / (R + G + B)
+
+See section 8.4.5.2 in the data sheet for additional details.
diff --git a/Documentation/index.rst b/Documentation/index.rst
index bf6aa681c960..c0cf79a87c3a 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -2,6 +2,7 @@
.. _linux_doc:
+==============================
The Linux Kernel documentation
==============================
@@ -13,7 +14,7 @@ documentation are welcome; join the linux-doc list at vger.kernel.org if
you want to help out.
Working with the development community
---------------------------------------
+======================================
The essential guides for interacting with the kernel's development
community and getting your work upstream.
@@ -21,15 +22,15 @@ community and getting your work upstream.
.. toctree::
:maxdepth: 1
- process/development-process
- process/submitting-patches
+ Development process <process/development-process>
+ Submitting patches <process/submitting-patches>
Code of conduct <process/code-of-conduct>
- maintainer/index
+ Maintainer handbook <maintainer/index>
All development-process docs <process/index>
Internal API manuals
---------------------
+====================
Manuals for use by developers working to interface with the rest of the
kernel.
@@ -37,32 +38,32 @@ kernel.
.. toctree::
:maxdepth: 1
- core-api/index
- driver-api/index
- subsystem-apis
- Locking in the kernel <locking/index>
+ Core API <core-api/index>
+ Driver APIs <driver-api/index>
+ Subsystems <subsystem-apis>
+ Locking <locking/index>
Development tools and processes
--------------------------------
+===============================
Various other manuals with useful information for all kernel developers.
.. toctree::
:maxdepth: 1
- process/license-rules
- doc-guide/index
- dev-tools/index
- dev-tools/testing-overview
- kernel-hacking/index
- trace/index
- fault-injection/index
- livepatch/index
- rust/index
+ Licensing rules <process/license-rules>
+ Writing documentation <doc-guide/index>
+ Development tools <dev-tools/index>
+ Testing guide <dev-tools/testing-overview>
+ Hacking guide <kernel-hacking/index>
+ Tracing <trace/index>
+ Fault injection <fault-injection/index>
+ Livepatching <livepatch/index>
+ Rust <rust/index>
User-oriented documentation
----------------------------
+===========================
The following manuals are written for *users* of the kernel — those who are
trying to get it to work optimally on a given system and application
@@ -71,56 +72,56 @@ developers seeking information on the kernel's user-space APIs.
.. toctree::
:maxdepth: 1
- admin-guide/index
- The kernel build system <kbuild/index>
- admin-guide/reporting-issues.rst
- User-space tools <tools/index>
- userspace-api/index
+ Administration <admin-guide/index>
+ Build system <kbuild/index>
+ Reporting issues <admin-guide/reporting-issues.rst>
+ Userspace tools <tools/index>
+ Userspace API <userspace-api/index>
See also: the `Linux man pages <https://www.kernel.org/doc/man-pages/>`_,
which are kept separately from the kernel's own documentation.
Firmware-related documentation
-------------------------------
+==============================
The following holds information on the kernel's expectations regarding the
-platform firmwares.
+platform firmware.
.. toctree::
:maxdepth: 1
- firmware-guide/index
- devicetree/index
+ Firmware <firmware-guide/index>
+ Firmware and Devicetree <devicetree/index>
Architecture-specific documentation
------------------------------------
+===================================
.. toctree::
:maxdepth: 2
- arch
+ CPU architectures <arch/index>
Other documentation
--------------------
+===================
There are several unsorted documents that don't seem to fit on other parts
of the documentation body, or may require some adjustments and/or conversion
-to ReStructured Text format, or are simply too old.
+to reStructuredText format, or are simply too old.
.. toctree::
:maxdepth: 1
- staging/index
+ Unsorted documentation <staging/index>
Translations
-------------
+============
.. toctree::
:maxdepth: 2
- translations/index
+ Translations <translations/index>
Indices and tables
==================
diff --git a/Documentation/infiniband/index.rst b/Documentation/infiniband/index.rst
index 9cd7615438b9..5b4c24125f66 100644
--- a/Documentation/infiniband/index.rst
+++ b/Documentation/infiniband/index.rst
@@ -12,6 +12,7 @@ InfiniBand
opa_vnic
sysfs
tag_matching
+ ucaps
user_mad
user_verbs
diff --git a/Documentation/infiniband/ucaps.rst b/Documentation/infiniband/ucaps.rst
new file mode 100644
index 000000000000..b8b6927742f4
--- /dev/null
+++ b/Documentation/infiniband/ucaps.rst
@@ -0,0 +1,71 @@
+=================================
+Infiniband Userspace Capabilities
+=================================
+
+ User CAPabilities (UCAPs) provide fine-grained control over specific
+ firmware features in Infiniband (IB) devices. This approach offers
+ more granular capabilities than the existing Linux capabilities,
+ which may be too generic for certain FW features.
+
+ Each user capability is represented as a character device with root
+ read-write access. Root processes can grant users special privileges
+ by allowing access to these character devices (e.g., using chown).
+
+Usage
+=====
+
+ UCAPs allow control over specific features of an IB device using file
+ descriptors of UCAP character devices. Here is how a user enables
+ specific features of an IB device:
+
+ * A root process grants the user access to the UCAP files that
+ represents the capabilities (e.g., using chown).
+ * The user opens the UCAP files, obtaining file descriptors.
+ * When opening an IB device, include an array of the UCAP file
+ descriptors as an attribute.
+ * The ib_uverbs driver recognizes the UCAP file descriptors and enables
+ the corresponding capabilities for the IB device.
+
+Creating UCAPs
+==============
+
+ To create a new UCAP, drivers must first define a type in the
+ rdma_user_cap enum in rdma/ib_ucaps.h. The name of the UCAP character
+ device should be added to the ucap_names array in
+ drivers/infiniband/core/ucaps.c. Then, the driver can create the UCAP
+ character device by calling the ib_create_ucap API with the UCAP
+ type.
+
+ A reference count is stored for each UCAP to track creations and
+ removals of the UCAP device. If multiple creation calls are made with
+ the same type (e.g., for two IB devices), the UCAP character device
+ is created during the first call and subsequent calls increment the
+ reference count.
+
+ The UCAP character device is created under /dev/infiniband, and its
+ permissions are set to allow root read and write access only.
+
+Removing UCAPs
+==============
+
+ Each removal decrements the reference count of the UCAP. The UCAP
+ character device is removed from the filesystem only when the
+ reference count is decreased to 0.
+
+/dev and /sys/class files
+=========================
+
+ The class::
+
+ /sys/class/infiniband_ucaps
+
+ is created when the first UCAP character device is created.
+
+ The UCAP character device is created under /dev/infiniband.
+
+ For example, if mlx5_ib adds the rdma_user_cap
+ RDMA_UCAP_MLX5_CTRL_LOCAL with name "mlx5_perm_ctrl_local", this will
+ create the device node::
+
+ /dev/infiniband/mlx5_perm_ctrl_local
+
diff --git a/Documentation/input/devices/amijoy.rst b/Documentation/input/devices/amijoy.rst
index 8df7b11cd98d..a81e9de481c7 100644
--- a/Documentation/input/devices/amijoy.rst
+++ b/Documentation/input/devices/amijoy.rst
@@ -1,14 +1,15 @@
-~~~~~~~~~~~~~~~~~~~~~~~~~
-Amiga joystick extensions
-~~~~~~~~~~~~~~~~~~~~~~~~~
+===============
+Amiga joysticks
+===============
+Pinouts
+=======
-Amiga 4-joystick parport extension
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Amiga 4-joystick parallel port extension
+----------------------------------------
Parallel port pins:
-
===== ======== ==== ==========
Pin Meaning Pin Meaning
===== ======== ==== ==========
@@ -17,11 +18,11 @@ Pin Meaning Pin Meaning
4 Left1 8 Left2
5 Right1 9 Right2
13 Fire1 11 Fire2
-18 Gnd1 18 Gnd2
+19 Gnd1 18 Gnd2
===== ======== ==== ==========
-Amiga digital joystick pinout
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Amiga digital joystick
+----------------------
=== ============
Pin Meaning
@@ -37,8 +38,8 @@ Pin Meaning
9 Thumb button
=== ============
-Amiga mouse pinout
-~~~~~~~~~~~~~~~~~~
+Amiga mouse
+-----------
=== ============
Pin Meaning
@@ -54,8 +55,8 @@ Pin Meaning
9 Right button
=== ============
-Amiga analog joystick pinout
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Amiga analog joystick
+---------------------
=== ==============
Pin Meaning
@@ -71,8 +72,8 @@ Pin Meaning
9 Analog Y
=== ==============
-Amiga lightpen pinout
-~~~~~~~~~~~~~~~~~~~~~
+Amiga lightpen
+--------------
=== =============
Pin Meaning
@@ -88,19 +89,23 @@ Pin Meaning
9 Stylus button
=== =============
--------------------------------------------------------------------------------
+Register addresses
+==================
+
+JOY0DAT/JOY1DAT
+---------------
-======== === ==== ==== ====== ========================================
+======== === ==== ==== ====== ===========================================
NAME rev ADDR type chip Description
-======== === ==== ==== ====== ========================================
-JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert, horiz)
-JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz)
-======== === ==== ==== ====== ========================================
+======== === ==== ==== ====== ===========================================
+JOY0DAT 00A R Denise Joystick-mouse 0 data (left vert., horiz.)
+JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert., horiz.)
+======== === ==== ==== ====== ===========================================
These addresses each read a 16 bit register. These in turn
are loaded from the MDAT serial stream and are clocked in on
the rising edge of SCLK. MLD output is used to parallel load
- the external parallel-to-serial converter.This in turn is
+ the external parallel-to-serial converter. This in turn is
loaded with the 4 quadrature inputs from each of two game
controller ports (8 total) plus 8 miscellaneous control bits
which are new for LISA and can be read in upper 8 bits of
@@ -108,7 +113,7 @@ JOY1DAT 00C R Denise Joystick-mouse 1 data (right vert,horiz)
Register bits are as follows:
- - Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock)
+ - Mouse counter usage (pins 1,3 =Yclock, pins 2,4 =Xclock)
======== === === === === === === === === ====== === === === === === === ===
BIT# 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
@@ -123,7 +128,7 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
clocked by 2 of the signals input from the mouse serial
stream. Starting with first bit received:
- +-------------------+-----------------------------------------+
+ +--------+----------+-----------------------------------------+
| Serial | Bit Name | Description |
+========+==========+=========================================+
| 0 | M0H | JOY0DAT Horizontal Clock |
@@ -160,7 +165,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
| Right | 4 | X1 |
+------------+------+---------------------------------+
--------------------------------------------------------------------------------
+JOYTEST
+-------
======== === ==== ==== ====== =================================================
NAME rev ADDR type chip Description
@@ -177,14 +183,15 @@ JOYTEST 036 W Denise Write to all 4 joystick-mouse counters at once.
JOYxDAT Y7 Y6 Y5 Y4 Y3 Y2 xx xx X7 X6 X5 X4 X3 X2 xx xx
========= === === === === === === === === ====== === === === === === === ===
--------------------------------------------------------------------------------
+POT0DAT/POT1DAT
+---------------
-======= === ==== ==== ====== ========================================
+======= === ==== ==== ====== ===========================================
NAME rev ADDR type chip Description
-======= === ==== ==== ====== ========================================
-POT0DAT h 012 R Paula Pot counter data left pair (vert, horiz)
-POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz)
-======= === ==== ==== ====== ========================================
+======= === ==== ==== ====== ===========================================
+POT0DAT h 012 R Paula Pot counter data left pair (vert., horiz.)
+POT1DAT h 014 R Paula Pot counter data right pair (vert., horiz.)
+======= === ==== ==== ====== ===========================================
These addresses each read a pair of 8 bit pot counters.
(4 counters total). The bit assignment for both
@@ -213,12 +220,13 @@ POT1DAT h 014 R Paula Pot counter data right pair (vert,horiz)
+-------+------+-----+-----+-------+
With normal (NTSC or PAL) horiz. line rate, the pots will
- give a full scale (FF) reading with about 500kohms in one
- frame time. With proportionally faster horiz line times,
+ give a full scale (FF) reading with about 500k ohm in one
+ frame time. With proportionally faster horiz. line times,
the counters will count proportionally faster.
This should be noted when doing variable beam displays.
--------------------------------------------------------------------------------
+POTGO
+-----
====== === ==== ==== ====== ================================================
NAME rev ADDR type chip Description
@@ -227,7 +235,8 @@ POTGO 034 W Paula Pot port (4 bit) bi-direction and data, and pot
counter start.
====== === ==== ==== ====== ================================================
--------------------------------------------------------------------------------
+POTINP
+------
====== === ==== ==== ====== ================================================
NAME rev ADDR type chip Description
@@ -238,26 +247,26 @@ POTINP 016 R Paula Pot pin data read
This register controls a 4 bit bi-direction I/O port
that shares the same 4 pins as the 4 pot counters above.
- +-------+----------+---------------------------------------------+
- | BIT# | FUNCTION | DESCRIPTION |
- +=======+==========+=============================================+
- | 15 | OUTRY | Output enable for Paula pin 33 |
- +-------+----------+---------------------------------------------+
- | 14 | DATRY | I/O data Paula pin 33 |
- +-------+----------+---------------------------------------------+
- | 13 | OUTRX | Output enable for Paula pin 32 |
- +-------+----------+---------------------------------------------+
- | 12 | DATRX | I/O data Paula pin 32 |
- +-------+----------+---------------------------------------------+
- | 11 | OUTLY | Out put enable for Paula pin 36 |
- +-------+----------+---------------------------------------------+
- | 10 | DATLY | I/O data Paula pin 36 |
- +-------+----------+---------------------------------------------+
- | 09 | OUTLX | Output enable for Paula pin 35 |
- +-------+----------+---------------------------------------------+
- | 08 | DATLX | I/O data Paula pin 35 |
- +-------+----------+---------------------------------------------+
- | 07-01 | X | Not used |
- +-------+----------+---------------------------------------------+
- | 00 | START | Start pots (dump capacitors,start counters) |
- +-------+----------+---------------------------------------------+
+ +-------+----------+----------------------------------------------+
+ | BIT# | FUNCTION | DESCRIPTION |
+ +=======+==========+==============================================+
+ | 15 | OUTRY | Output enable for Paula pin 33 |
+ +-------+----------+----------------------------------------------+
+ | 14 | DATRY | I/O data Paula pin 33 |
+ +-------+----------+----------------------------------------------+
+ | 13 | OUTRX | Output enable for Paula pin 32 |
+ +-------+----------+----------------------------------------------+
+ | 12 | DATRX | I/O data Paula pin 32 |
+ +-------+----------+----------------------------------------------+
+ | 11 | OUTLY | Out put enable for Paula pin 36 |
+ +-------+----------+----------------------------------------------+
+ | 10 | DATLY | I/O data Paula pin 36 |
+ +-------+----------+----------------------------------------------+
+ | 09 | OUTLX | Output enable for Paula pin 35 |
+ +-------+----------+----------------------------------------------+
+ | 08 | DATLX | I/O data Paula pin 35 |
+ +-------+----------+----------------------------------------------+
+ | 07-01 | X | Not used |
+ +-------+----------+----------------------------------------------+
+ | 00 | START | Start pots (dump capacitors, start counters) |
+ +-------+----------+----------------------------------------------+
diff --git a/Documentation/input/devices/edt-ft5x06.rst b/Documentation/input/devices/edt-ft5x06.rst
index 1ccc94b192b7..e410d73d4841 100644
--- a/Documentation/input/devices/edt-ft5x06.rst
+++ b/Documentation/input/devices/edt-ft5x06.rst
@@ -29,8 +29,25 @@ The driver allows configuration of the touch screen via a set of sysfs files:
For debugging purposes the driver provides a few files in the debug
-filesystem (if available in the kernel). In /sys/kernel/debug/edt_ft5x06
-you'll find the following files:
+filesystem (if available in the kernel). They are located in:
+
+ /sys/kernel/debug/i2c/<i2c-bus>/<i2c-device>/
+
+If you don't know the bus and device numbers, you can look them up with this
+command:
+
+ $ ls -l /sys/bus/i2c/drivers/edt_ft5x06
+
+The dereference of the symlink will contain the needed information. You will
+need the last two elements of its path:
+
+ 0-0038 -> ../../../../devices/platform/soc/fcfee800.i2c/i2c-0/0-0038
+
+So in this case, the location for the debug files is:
+
+ /sys/kernel/debug/i2c/i2c-0/0-0038/
+
+There, you'll find the following files:
num_x, num_y:
(readonly) contains the number of sensor fields in X- and
diff --git a/Documentation/input/devices/elantech.rst b/Documentation/input/devices/elantech.rst
index c3374a7ce7af..98163a258b83 100644
--- a/Documentation/input/devices/elantech.rst
+++ b/Documentation/input/devices/elantech.rst
@@ -556,7 +556,7 @@ Note on debounce:
In case the box has unstable power supply or other electricity issues, or
when number of finger changes, F/W would send "debounce packet" to inform
driver that the hardware is in debounce status.
-The debouce packet has the following signature::
+The debounce packet has the following signature::
byte 0: 0xc4
byte 1: 0xff
diff --git a/Documentation/input/devices/iforce-protocol.rst b/Documentation/input/devices/iforce-protocol.rst
index 8634beac3fdb..52c1e0dd0ab7 100644
--- a/Documentation/input/devices/iforce-protocol.rst
+++ b/Documentation/input/devices/iforce-protocol.rst
@@ -49,7 +49,7 @@ OP DATA
== ====
The 2B, LEN and CS fields have disappeared, probably because USB handles
-frames and data corruption is handled or unsignificant.
+frames and data corruption is handled or insignificant.
First, I describe effects that are sent by the device to the computer
diff --git a/Documentation/input/devices/pxrc.rst b/Documentation/input/devices/pxrc.rst
index ca11f646bae8..5a86df4ad079 100644
--- a/Documentation/input/devices/pxrc.rst
+++ b/Documentation/input/devices/pxrc.rst
@@ -5,7 +5,7 @@ pxrc - PhoenixRC Flight Controller Adapter
:Author: Marcus Folkesson <marcus.folkesson@gmail.com>
This driver let you use your own RC controller plugged into the
-adapter that comes with PhoenixRC [1]_ or other compatible adapters.
+adapter that comes with PhoenixRC or other compatible adapters.
The adapter supports 7 analog channels and 1 digital input switch.
@@ -41,7 +41,7 @@ Manual Testing
==============
To test this driver's functionality you may use `input-event` which is part of
-the `input layer utilities` suite [2]_.
+the `input layer utilities` suite [1]_.
For example::
@@ -53,5 +53,4 @@ To print all input events from input `devnr`.
References
==========
-.. [1] http://www.phoenix-sim.com/
-.. [2] https://www.kraxel.org/cgit/input/
+.. [1] https://www.kraxel.org/cgit/input/
diff --git a/Documentation/input/devices/xpad.rst b/Documentation/input/devices/xpad.rst
index 173c2acda9fd..a480bc781565 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -4,16 +4,16 @@ xpad - Linux USB driver for Xbox compatible controllers
This driver exposes all first-party and third-party Xbox compatible
controllers. It has a long history and has enjoyed considerable usage
-as Window's xinput library caused most PC games to focus on Xbox
+as Windows' xinput library caused most PC games to focus on Xbox
controller compatibility.
Due to backwards compatibility all buttons are reported as digital.
-This only effects Original Xbox controllers. All later controller models
+This only affects Original Xbox controllers. All later controller models
have only digital face buttons.
Rumble is supported on some models of Xbox 360 controllers but not of
Original Xbox controllers nor on Xbox One controllers. As of writing
-the Xbox One's rumble protocol has not been reverse engineered but in
+the Xbox One's rumble protocol has not been reverse-engineered but in
the future could be supported.
@@ -82,7 +82,7 @@ I've tested this with Stepmania, and it works quite well.
Unknown Controllers
-------------------
-If you have an unknown xbox controller, it should work just fine with
+If you have an unknown Xbox controller, it should work just fine with
the default settings.
HOWEVER if you have an unknown dance pad not listed below, it will not
@@ -123,7 +123,7 @@ can be found on the net ([1]_, [2]_, [3]_).
Thanks to the trip splitter found on the cable you don't even need to cut the
original one. You can buy an extension cable and cut that instead. That way,
-you can still use the controller with your X-Box, if you have one ;)
+you can still use the controller with your Xbox, if you have one ;)
diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
index 8741d390b184..4424cbff251f 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -235,6 +235,12 @@ A few EV_ABS codes have special meanings:
BTN_TOOL_<name> signals the type of tool that is currently detected by the
hardware and is otherwise independent of ABS_DISTANCE and/or BTN_TOUCH.
+* ABS_PROFILE:
+
+ - Used to describe the state of a multi-value profile switch. An event is
+ emitted only when the selected profile changes, indicating the newly
+ selected profile value.
+
* ABS_MT_<name>:
- Used to describe multitouch input events. Please see
@@ -394,6 +400,31 @@ can report through the rotational axes (absolute and/or relative rx, ry, rz).
All other axes retain their meaning. A device must not mix
regular directional axes and accelerometer axes on the same event node.
+INPUT_PROP_PRESSUREPAD
+----------------------
+
+The INPUT_PROP_PRESSUREPAD property indicates that the device provides
+simulated haptic feedback (e.g. a vibrator motor situated below the surface)
+instead of physical haptic feedback (e.g. a hinge). This property is only set
+if the device:
+
+- can differentiate between at least 5 fingers
+- uses correct resolution for the X/Y (units and value)
+- follows the MT protocol type B
+
+If the simulated haptic feedback is controllable by userspace the device must:
+
+- support simple haptic auto and manual triggering, and
+- report correct force per touch, and correct units for them (newtons or grams), and
+- provide the EV_FF FF_HAPTIC force feedback effect.
+
+Summing up, such devices follow the MS spec for input devices in
+Win8 and Win8.1, and in addition may support the Simple haptic controller HID
+table, and report correct units for the pressure.
+
+Where applicable, this property is set in addition to INPUT_PROP_BUTTONPAD, it
+does not replace that property.
+
Guidelines
==========
diff --git a/Documentation/input/gamepad.rst b/Documentation/input/gamepad.rst
index 4d5e7fb80a84..0c918b6f288b 100644
--- a/Documentation/input/gamepad.rst
+++ b/Documentation/input/gamepad.rst
@@ -184,8 +184,27 @@ Gamepads report the following events:
Many pads also have a third button which is branded or has a special symbol
and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo
- "HOME" button, the XBox "X"-button or Sony "PS" button.
+ "HOME" button, the Xbox "X" button or the Sony PlayStation "PS" button.
- Rumble:
Rumble is advertised as FF_RUMBLE.
+
+- Grip buttons:
+
+ Many pads include buttons on the rear, usually referred to as either grip or
+ rear buttons, or paddles. These are often reprogrammable by the firmware to
+ appear as "normal" buttons, but are sometimes exposed to software too. Some
+ notable examples of this are the Steam Deck, which has R4, R5, L4, and L5 on
+ the back; the Xbox Elite pads, which have P1-P4; and the Switch 2 Pro
+ Controller, which has GL and GR.
+
+ For these controllers, BTN_GRIPR and BTN_GRIPR2 should be used for the top
+ and bottom (if present) right grip button(s), and BTN_GRIPL and BTN_GRIPL2
+ should be used for the top and bottom (if present) left grip button(s).
+
+- Profile:
+
+ Some pads provide a multi-value profile selection switch. Examples include
+ the Xbox Adaptive and the Xbox Elite 2 controllers. When the active profile
+ is switched, its newly selected value is emitted as an ABS_PROFILE event.
diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
index 9888f5cbf6d5..35581cd18e91 100644
--- a/Documentation/input/index.rst
+++ b/Documentation/input/index.rst
@@ -1,6 +1,6 @@
-=============================
-The Linux Input Documentation
-=============================
+===================
+Input Documentation
+===================
Contents:
diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst
index c9264814c7aa..2b3e6a34e34b 100644
--- a/Documentation/input/input-programming.rst
+++ b/Documentation/input/input-programming.rst
@@ -346,3 +346,22 @@ driver can handle these events, it has to set the respective bits in evbit,
This callback routine can be called from an interrupt or a BH (although that
isn't a rule), and thus must not sleep, and must not take too long to finish.
+
+Polled input devices
+~~~~~~~~~~~~~~~~~~~~
+
+Input polling is set up by passing an input device struct and a callback to
+the function::
+
+ int input_setup_polling(struct input_dev *dev,
+ void (*poll_fn)(struct input_dev *dev))
+
+Within the callback, devices should use the regular input_report_* functions
+and input_sync as is used by other devices.
+
+There is also the function::
+
+ void input_set_poll_interval(struct input_dev *dev, unsigned int interval)
+
+which is used to configure the interval, in milliseconds, that the device will
+be polled at.
diff --git a/Documentation/input/input.rst b/Documentation/input/input.rst
index 2c67fa904adc..d9a6de87d02d 100644
--- a/Documentation/input/input.rst
+++ b/Documentation/input/input.rst
@@ -264,7 +264,7 @@ events on a read. Their layout is::
struct timeval time;
unsigned short type;
unsigned short code;
- unsigned int value;
+ int value;
};
``time`` is the timestamp, it returns the time at which the event happened.
diff --git a/Documentation/input/input_kapi.rst b/Documentation/input/input_kapi.rst
index 41f1b7e6b78e..9937522daa9b 100644
--- a/Documentation/input/input_kapi.rst
+++ b/Documentation/input/input_kapi.rst
@@ -4,11 +4,8 @@
Linux Input Subsystem kernel API
################################
-.. class:: toc-title
-
- Table of Contents
-
.. toctree::
+ :caption: Table of Contents
:maxdepth: 2
:numbered:
diff --git a/Documentation/input/input_uapi.rst b/Documentation/input/input_uapi.rst
index 4a0391609327..8275b4223a84 100644
--- a/Documentation/input/input_uapi.rst
+++ b/Documentation/input/input_uapi.rst
@@ -4,11 +4,8 @@
Linux Input Subsystem userspace API
###################################
-.. class:: toc-title
-
- Table of Contents
-
.. toctree::
+ :caption: Table of Contents
:maxdepth: 2
:numbered:
diff --git a/Documentation/input/joydev/index.rst b/Documentation/input/joydev/index.rst
index ebcff43056e2..d03d6f6cbfab 100644
--- a/Documentation/input/joydev/index.rst
+++ b/Documentation/input/joydev/index.rst
@@ -6,11 +6,8 @@ Linux Joystick support
:Copyright: |copy| 1996-2000 Vojtech Pavlik <vojtech@ucw.cz> - Sponsored by SuSE
-.. class:: toc-title
-
- Table of Contents
-
.. toctree::
+ :caption: Table of Contents
:maxdepth: 3
joystick
diff --git a/Documentation/input/multi-touch-protocol.rst b/Documentation/input/multi-touch-protocol.rst
index 1085cbee4ee7..47d3dcb5d44b 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -383,7 +383,7 @@ Finger Tracking
---------------
The process of finger tracking, i.e., to assign a unique trackingID to each
-initiated contact on the surface, is a Euclidian Bipartite Matching
+initiated contact on the surface, is a Euclidean Bipartite Matching
problem. At each event synchronization, the set of actual contacts is
matched to the set of contacts from the previous synchronization. A full
implementation can be found in [#f3]_.
diff --git a/Documentation/isdn/interface_capi.rst b/Documentation/isdn/interface_capi.rst
index fe2421444b76..4d63b34b35cf 100644
--- a/Documentation/isdn/interface_capi.rst
+++ b/Documentation/isdn/interface_capi.rst
@@ -323,7 +323,7 @@ If the lowest bit of showcapimsgs is set, kernelcapi logs controller and
application up and down events.
In addition, every registered CAPI controller has an associated traceflag
-parameter controlling how CAPI messages sent from and to tha controller are
+parameter controlling how CAPI messages sent from and to the controller are
logged. The traceflag parameter is initialized with the value of the
showcapimsgs parameter when the controller is registered, but can later be
changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE.
diff --git a/Documentation/isdn/m_isdn.rst b/Documentation/isdn/m_isdn.rst
index 9957de349e69..5847a164287e 100644
--- a/Documentation/isdn/m_isdn.rst
+++ b/Documentation/isdn/m_isdn.rst
@@ -3,7 +3,7 @@ mISDN Driver
============
mISDN is a new modular ISDN driver, in the long term it should replace
-the old I4L driver architecture for passiv ISDN cards.
+the old I4L driver architecture for passive ISDN cards.
It was designed to allow a broad range of applications and interfaces
but only have the basic function in kernel, the interface to the user
space is based on sockets with a own address family AF_ISDN.
diff --git a/Documentation/kbuild/Kconfig.recursion-issue-01 b/Documentation/kbuild/Kconfig.recursion-issue-01
index e8877db0461f..ac49836d8ecf 100644
--- a/Documentation/kbuild/Kconfig.recursion-issue-01
+++ b/Documentation/kbuild/Kconfig.recursion-issue-01
@@ -16,13 +16,13 @@
# that are possible for CORE. So for example if CORE_BELL_A_ADVANCED is 'y',
# CORE must be 'y' too.
#
-# * What influences CORE_BELL_A_ADVANCED ?
+# * What influences CORE_BELL_A_ADVANCED?
#
# As the name implies CORE_BELL_A_ADVANCED is an advanced feature of
# CORE_BELL_A so naturally it depends on CORE_BELL_A. So if CORE_BELL_A is 'y'
# we know CORE_BELL_A_ADVANCED can be 'y' too.
#
-# * What influences CORE_BELL_A ?
+# * What influences CORE_BELL_A?
#
# CORE_BELL_A depends on CORE, so CORE influences CORE_BELL_A.
#
@@ -34,7 +34,7 @@
# the "recursive dependency detected" error.
#
# Reading the Documentation/kbuild/Kconfig.recursion-issue-01 file it may be
-# obvious that an easy to solution to this problem should just be the removal
+# obvious that an easy solution to this problem should just be the removal
# of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already
# since CORE_BELL_A depends on CORE. Recursive dependency issues are not always
# so trivial to resolve, we provide another example below of practical
diff --git a/Documentation/kbuild/bash-completion.rst b/Documentation/kbuild/bash-completion.rst
new file mode 100644
index 000000000000..2b52dbcd0933
--- /dev/null
+++ b/Documentation/kbuild/bash-completion.rst
@@ -0,0 +1,65 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+==========================
+Bash completion for Kbuild
+==========================
+
+The kernel build system is written using Makefiles, and Bash completion
+for the `make` command is available through the `bash-completion`_ project.
+
+However, the Makefiles for the kernel build are complex. The generic completion
+rules for the `make` command do not provide meaningful suggestions for the
+kernel build system, except for the options of the `make` command itself.
+
+To enhance completion for various variables and targets, the kernel source
+includes its own completion script at `scripts/bash-completion/make`.
+
+This script provides additional completions when working within the kernel tree.
+Outside the kernel tree, it defaults to the generic completion rules for the
+`make` command.
+
+Prerequisites
+=============
+
+The script relies on helper functions provided by `bash-completion`_ project.
+Please ensure it is installed on your system. On most distributions, you can
+install the `bash-completion` package through the standard package manager.
+
+How to use
+==========
+
+You can source the script directly::
+
+ $ source scripts/bash-completion/make
+
+Or, you can copy it into the search path for Bash completion scripts.
+For example::
+
+ $ mkdir -p ~/.local/share/bash-completion/completions
+ $ cp scripts/bash-completion/make ~/.local/share/bash-completion/completions/
+
+Details
+=======
+
+The additional completion for Kbuild is enabled in the following cases:
+
+ - You are in the root directory of the kernel source.
+ - You are in the top-level build directory created by the O= option
+ (checked via the `source` symlink pointing to the kernel source).
+ - The -C make option specifies the kernel source or build directory.
+ - The -f make option specifies a file in the kernel source or build directory.
+
+If none of the above are met, it falls back to the generic completion rules.
+
+The completion supports:
+
+ - Commonly used targets, such as `all`, `menuconfig`, `dtbs`, etc.
+ - Make (or environment) variables, such as `ARCH`, `LLVM`, etc.
+ - Single-target builds (`foo/bar/baz.o`)
+ - Configuration files (`*_defconfig` and `*.config`)
+
+Some variables offer intelligent behavior. For instance, `CROSS_COMPILE=`
+followed by a TAB displays installed toolchains. The list of defconfig files
+shown depends on the value of the `ARCH=` variable.
+
+.. _bash-completion: https://github.com/scop/bash-completion/
diff --git a/Documentation/kbuild/gendwarfksyms.rst b/Documentation/kbuild/gendwarfksyms.rst
new file mode 100644
index 000000000000..ed366250a54e
--- /dev/null
+++ b/Documentation/kbuild/gendwarfksyms.rst
@@ -0,0 +1,395 @@
+=======================
+DWARF module versioning
+=======================
+
+Introduction
+============
+
+When CONFIG_MODVERSIONS is enabled, symbol versions for modules
+are typically calculated from preprocessed source code using the
+**genksyms** tool. However, this is incompatible with languages such
+as Rust, where the source code has insufficient information about
+the resulting ABI. With CONFIG_GENDWARFKSYMS (and CONFIG_DEBUG_INFO)
+selected, **gendwarfksyms** is used instead to calculate symbol versions
+from the DWARF debugging information, which contains the necessary
+details about the final module ABI.
+
+Usage
+-----
+
+gendwarfksyms accepts a list of object files on the command line, and a
+list of symbol names (one per line) in standard input::
+
+ Usage: gendwarfksyms [options] elf-object-file ... < symbol-list
+
+ Options:
+ -d, --debug Print debugging information
+ --dump-dies Dump DWARF DIE contents
+ --dump-die-map Print debugging information about die_map changes
+ --dump-types Dump type strings
+ --dump-versions Dump expanded type strings used for symbol versions
+ -s, --stable Support kABI stability features
+ -T, --symtypes file Write a symtypes file
+ -h, --help Print this message
+
+
+Type information availability
+=============================
+
+While symbols are typically exported in the same translation unit (TU)
+where they're defined, it's also perfectly fine for a TU to export
+external symbols. For example, this is done when calculating symbol
+versions for exports in stand-alone assembly code.
+
+To ensure the compiler emits the necessary DWARF type information in the
+TU where symbols are actually exported, gendwarfksyms adds a pointer
+to exported symbols in the `EXPORT_SYMBOL()` macro using the following
+macro::
+
+ #define __GENDWARFKSYMS_EXPORT(sym) \
+ static typeof(sym) *__gendwarfksyms_ptr_##sym __used \
+ __section(".discard.gendwarfksyms") = &sym;
+
+
+When a symbol pointer is found in DWARF, gendwarfksyms can use its
+type for calculating symbol versions even if the symbol is defined
+elsewhere. The name of the symbol pointer is expected to start with
+`__gendwarfksyms_ptr_`, followed by the name of the exported symbol.
+
+Symtypes output format
+======================
+
+Similarly to genksyms, gendwarfksyms supports writing a symtypes
+file for each processed object that contain types for exported
+symbols and each referenced type that was used in calculating symbol
+versions. These files can be useful when trying to determine what
+exactly caused symbol versions to change between builds. To generate
+symtypes files during a kernel build, set `KBUILD_SYMTYPES=1`.
+
+Matching the existing format, the first column of each line contains
+either a type reference or a symbol name. Type references have a
+one-letter prefix followed by "#" and the name of the type. Four
+reference types are supported::
+
+ e#<type> = enum
+ s#<type> = struct
+ t#<type> = typedef
+ u#<type> = union
+
+Type names with spaces in them are wrapped in single quotes, e.g.::
+
+ s#'core::result::Result<u8, core::num::error::ParseIntError>'
+
+The rest of the line contains a type string. Unlike with genksyms that
+produces C-style type strings, gendwarfksyms uses the same simple parsed
+DWARF format produced by **--dump-dies**, but with type references
+instead of fully expanded strings.
+
+Maintaining a stable kABI
+=========================
+
+Distribution maintainers often need the ability to make ABI compatible
+changes to kernel data structures due to LTS updates or backports. Using
+the traditional `#ifndef __GENKSYMS__` to hide these changes from symbol
+versioning won't work when processing object files. To support this
+use case, gendwarfksyms provides kABI stability features designed to
+hide changes that won't affect the ABI when calculating versions. These
+features are all gated behind the **--stable** command line flag and are
+not used in the mainline kernel. To use stable features during a kernel
+build, set `KBUILD_GENDWARFKSYMS_STABLE=1`.
+
+Examples for using these features are provided in the
+**scripts/gendwarfksyms/examples** directory, including helper macros
+for source code annotation. Note that as these features are only used to
+transform the inputs for symbol versioning, the user is responsible for
+ensuring that their changes actually won't break the ABI.
+
+kABI rules
+----------
+
+kABI rules allow distributions to fine-tune certain parts
+of gendwarfksyms output and thus control how symbol
+versions are calculated. These rules are defined in the
+`.discard.gendwarfksyms.kabi_rules` section of the object file and
+consist of simple null-terminated strings with the following structure::
+
+ version\0type\0target\0value\0
+
+This string sequence is repeated as many times as needed to express all
+the rules. The fields are as follows:
+
+- `version`: Ensures backward compatibility for future changes to the
+ structure. Currently expected to be "1".
+- `type`: Indicates the type of rule being applied.
+- `target`: Specifies the target of the rule, typically the fully
+ qualified name of the DWARF Debugging Information Entry (DIE).
+- `value`: Provides rule-specific data.
+
+The following helper macros, for example, can be used to specify rules
+in the source code::
+
+ #define ___KABI_RULE(hint, target, value) \
+ static const char __PASTE(__gendwarfksyms_rule_, \
+ __COUNTER__)[] __used __aligned(1) \
+ __section(".discard.gendwarfksyms.kabi_rules") = \
+ "1\0" #hint "\0" target "\0" value
+
+ #define __KABI_RULE(hint, target, value) \
+ ___KABI_RULE(hint, #target, #value)
+
+
+Currently, only the rules discussed in this section are supported, but
+the format is extensible enough to allow further rules to be added as
+need arises.
+
+Managing definition visibility
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A declaration can change into a full definition when additional includes
+are pulled into the translation unit. This changes the versions of any
+symbol that references the type even if the ABI remains unchanged. As
+it may not be possible to drop includes without breaking the build, the
+`declonly` rule can be used to specify a type as declaration-only, even
+if the debugging information contains the full definition.
+
+The rule fields are expected to be as follows:
+
+- `type`: "declonly"
+- `target`: The fully qualified name of the target data structure
+ (as shown in **--dump-dies** output).
+- `value`: This field is ignored.
+
+Using the `__KABI_RULE` macro, this rule can be defined as::
+
+ #define KABI_DECLONLY(fqn) __KABI_RULE(declonly, fqn, )
+
+Example usage::
+
+ struct s {
+ /* definition */
+ };
+
+ KABI_DECLONLY(s);
+
+Adding enumerators
+~~~~~~~~~~~~~~~~~~
+
+For enums, all enumerators and their values are included in calculating
+symbol versions, which becomes a problem if we later need to add more
+enumerators without changing symbol versions. The `enumerator_ignore`
+rule allows us to hide named enumerators from the input.
+
+The rule fields are expected to be as follows:
+
+- `type`: "enumerator_ignore"
+- `target`: The fully qualified name of the target enum
+ (as shown in **--dump-dies** output) and the name of the
+ enumerator field separated by a space.
+- `value`: This field is ignored.
+
+Using the `__KABI_RULE` macro, this rule can be defined as::
+
+ #define KABI_ENUMERATOR_IGNORE(fqn, field) \
+ __KABI_RULE(enumerator_ignore, fqn field, )
+
+Example usage::
+
+ enum e {
+ A, B, C, D,
+ };
+
+ KABI_ENUMERATOR_IGNORE(e, B);
+ KABI_ENUMERATOR_IGNORE(e, C);
+
+If the enum additionally includes an end marker and new values must
+be added in the middle, we may need to use the old value for the last
+enumerator when calculating versions. The `enumerator_value` rule allows
+us to override the value of an enumerator for version calculation:
+
+- `type`: "enumerator_value"
+- `target`: The fully qualified name of the target enum
+ (as shown in **--dump-dies** output) and the name of the
+ enumerator field separated by a space.
+- `value`: Integer value used for the field.
+
+Using the `__KABI_RULE` macro, this rule can be defined as::
+
+ #define KABI_ENUMERATOR_VALUE(fqn, field, value) \
+ __KABI_RULE(enumerator_value, fqn field, value)
+
+Example usage::
+
+ enum e {
+ A, B, C, LAST,
+ };
+
+ KABI_ENUMERATOR_IGNORE(e, C);
+ KABI_ENUMERATOR_VALUE(e, LAST, 2);
+
+Managing structure size changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A data structure can be partially opaque to modules if its allocation is
+handled by the core kernel, and modules only need to access some of its
+members. In this situation, it's possible to append new members to the
+structure without breaking the ABI, as long as the layout for the original
+members remains unchanged.
+
+To append new members, we can hide them from symbol versioning as
+described in section :ref:`Hiding members <hiding_members>`, but we can't
+hide the increase in structure size. The `byte_size` rule allows us to
+override the structure size used for symbol versioning.
+
+The rule fields are expected to be as follows:
+
+- `type`: "byte_size"
+- `target`: The fully qualified name of the target data structure
+ (as shown in **--dump-dies** output).
+- `value`: A positive decimal number indicating the structure size
+ in bytes.
+
+Using the `__KABI_RULE` macro, this rule can be defined as::
+
+ #define KABI_BYTE_SIZE(fqn, value) \
+ __KABI_RULE(byte_size, fqn, value)
+
+Example usage::
+
+ struct s {
+ /* Unchanged original members */
+ unsigned long a;
+ void *p;
+
+ /* Appended new members */
+ KABI_IGNORE(0, unsigned long n);
+ };
+
+ KABI_BYTE_SIZE(s, 16);
+
+Overriding type strings
+~~~~~~~~~~~~~~~~~~~~~~~
+
+In rare situations where distributions must make significant changes to
+otherwise opaque data structures that have inadvertently been included
+in the published ABI, keeping symbol versions stable using the more
+targeted kABI rules can become tedious. The `type_string` rule allows us
+to override the full type string for a type or a symbol, and even add
+types for versioning that no longer exist in the kernel.
+
+The rule fields are expected to be as follows:
+
+- `type`: "type_string"
+- `target`: The fully qualified name of the target data structure
+ (as shown in **--dump-dies** output) or symbol.
+- `value`: A valid type string (as shown in **--symtypes**) output)
+ to use instead of the real type.
+
+Using the `__KABI_RULE` macro, this rule can be defined as::
+
+ #define KABI_TYPE_STRING(type, str) \
+ ___KABI_RULE("type_string", type, str)
+
+Example usage::
+
+ /* Override type for a structure */
+ KABI_TYPE_STRING("s#s",
+ "structure_type s { "
+ "member base_type int byte_size(4) "
+ "encoding(5) n "
+ "data_member_location(0) "
+ "} byte_size(8)");
+
+ /* Override type for a symbol */
+ KABI_TYPE_STRING("my_symbol", "variable s#s");
+
+The `type_string` rule should be used only as a last resort if maintaining
+a stable symbol versions cannot be reasonably achieved using other
+means. Overriding a type string increases the risk of actual ABI breakages
+going unnoticed as it hides all changes to the type.
+
+Adding structure members
+------------------------
+
+Perhaps the most common ABI compatible change is adding a member to a
+kernel data structure. When changes to a structure are anticipated,
+distribution maintainers can pre-emptively reserve space in the
+structure and take it into use later without breaking the ABI. If
+changes are needed to data structures without reserved space, existing
+alignment holes can potentially be used instead. While kABI rules could
+be added for these type of changes, using unions is typically a more
+natural method. This section describes gendwarfksyms support for using
+reserved space in data structures and hiding members that don't change
+the ABI when calculating symbol versions.
+
+Reserving space and replacing members
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Space is typically reserved for later use by appending integer types, or
+arrays, to the end of the data structure, but any type can be used. Each
+reserved member needs a unique name, but as the actual purpose is usually
+not known at the time the space is reserved, for convenience, names that
+start with `__kabi_` are left out when calculating symbol versions::
+
+ struct s {
+ long a;
+ long __kabi_reserved_0; /* reserved for future use */
+ };
+
+The reserved space can be taken into use by wrapping the member in a
+union, which includes the original type and the replacement member::
+
+ struct s {
+ long a;
+ union {
+ long __kabi_reserved_0; /* original type */
+ struct b b; /* replaced field */
+ };
+ };
+
+If the `__kabi_` naming scheme was used when reserving space, the name
+of the first member of the union must start with `__kabi_reserved`. This
+ensures the original type is used when calculating versions, but the name
+is again left out. The rest of the union is ignored.
+
+If we're replacing a member that doesn't follow this naming convention,
+we also need to preserve the original name to avoid changing versions,
+which we can do by changing the first union member's name to start with
+`__kabi_renamed` followed by the original name.
+
+The examples include `KABI_(RESERVE|USE|REPLACE)*` macros that help
+simplify the process and also ensure the replacement member is correctly
+aligned and its size won't exceed the reserved space.
+
+.. _hiding_members:
+
+Hiding members
+~~~~~~~~~~~~~~
+
+Predicting which structures will require changes during the support
+timeframe isn't always possible, in which case one might have to resort
+to placing new members into existing alignment holes::
+
+ struct s {
+ int a;
+ /* a 4-byte alignment hole */
+ unsigned long b;
+ };
+
+
+While this won't change the size of the data structure, one needs to
+be able to hide the added members from symbol versioning. Similarly
+to reserved fields, this can be accomplished by wrapping the added
+member to a union where one of the fields has a name starting with
+`__kabi_ignored`::
+
+ struct s {
+ int a;
+ union {
+ char __kabi_ignored_0;
+ int n;
+ };
+ unsigned long b;
+ };
+
+With **--stable**, both versions produce the same symbol version. The
+examples include a `KABI_IGNORE` macro to simplify the code.
diff --git a/Documentation/kbuild/index.rst b/Documentation/kbuild/index.rst
index cee2f99f734b..3731ab22bfe7 100644
--- a/Documentation/kbuild/index.rst
+++ b/Documentation/kbuild/index.rst
@@ -21,6 +21,9 @@ Kernel Build System
reproducible-builds
gcc-plugins
llvm
+ gendwarfksyms
+
+ bash-completion
.. only:: subproject and html
diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst
index 08f575e6236c..82826b0332df 100644
--- a/Documentation/kbuild/kbuild.rst
+++ b/Documentation/kbuild/kbuild.rst
@@ -22,6 +22,11 @@ modules.builtin.modinfo
This file contains modinfo from all modules that are built into the kernel.
Unlike modinfo of a separate module, all fields are prefixed with module name.
+modules.builtin.ranges
+----------------------
+This file contains address offset ranges (per ELF section) for all modules
+that are built into the kernel. Together with System.map, it can be used
+to associate module names with symbols.
Environment variables
=====================
@@ -86,6 +91,17 @@ HOSTRUSTFLAGS
-------------
Additional flags to be passed to $(HOSTRUSTC) when building host programs.
+PROCMACROLDFLAGS
+----------------
+Flags to be passed when linking Rust proc macros. Since proc macros are loaded
+by rustc at build time, they must be linked in a way that is compatible with
+the rustc toolchain being used.
+
+For instance, it can be useful when rustc uses a different C library than
+the one the user wants to use for host programs.
+
+If unset, it defaults to the flags passed when linking host programs.
+
HOSTLDFLAGS
-----------
Additional flags to be passed when linking host programs.
@@ -129,10 +145,21 @@ KBUILD_OUTPUT
-------------
Specify the output directory when building the kernel.
+This variable can also be used to point to the kernel output directory when
+building external modules against a pre-built kernel in a separate build
+directory. Please note that this does NOT specify the output directory for the
+external modules themselves. (Use KBUILD_EXTMOD_OUTPUT for that purpose.)
+
The output directory can also be specified using "O=...".
Setting "O=..." takes precedence over KBUILD_OUTPUT.
+KBUILD_EXTMOD_OUTPUT
+--------------------
+Specify the output directory for external modules.
+
+Setting "MO=..." takes precedence over KBUILD_EXTMOD_OUTPUT.
+
KBUILD_EXTRA_WARN
-----------------
Specify the extra build checks. The same value can be assigned by passing
@@ -150,6 +177,12 @@ the UTS_MACHINE variable, and on some architectures also the kernel config.
The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian
architecture.
+KDOCFLAGS
+---------
+Specify extra (warning/error) flags for kernel-doc checks during the build,
+see scripts/kernel-doc for which flags are supported. Note that this doesn't
+(currently) apply to documentation builds.
+
ARCH
----
Set ARCH to the architecture to be built.
@@ -160,7 +193,7 @@ directory name found in the arch/ directory.
But some architectures such as x86 and sparc have aliases.
- x86: i386 for 32 bit, x86_64 for 64 bit
-- sh: sh for 32 bit, sh64 for 64 bit
+- parisc: parisc64 for 64 bit
- sparc: sparc32 for 32 bit, sparc64 for 64 bit
CROSS_COMPILE
@@ -237,6 +270,12 @@ The output directory is often set using "O=..." on the commandline.
The value can be overridden in which case the default value is ignored.
+INSTALL_DTBS_PATH
+-----------------
+INSTALL_DTBS_PATH specifies where to install device tree blobs for
+relocations required by build roots. This is not defined in the
+makefile but the argument can be passed to make if needed.
+
KBUILD_ABS_SRCTREE
--------------------------------------------------
Kbuild uses a relative path to point to the tree when possible. For instance,
@@ -278,12 +317,25 @@ To get all available archs you can also specify all. E.g.::
$ make ALLSOURCE_ARCHS=all tags
+IGNORE_DIRS
+-----------
+For tags/TAGS/cscope targets, you can choose which directories won't
+be included in the databases, separated by blank space. E.g.::
+
+ $ make IGNORE_DIRS="drivers/gpu/drm/radeon tools" cscope
+
KBUILD_BUILD_TIMESTAMP
----------------------
Setting this to a date string overrides the timestamp used in the
UTS_VERSION definition (uname -v in the running kernel). The value has to
-be a string that can be passed to date -d. The default value
-is the output of the date command at one point during build.
+be a string that can be passed to date -d. E.g.::
+
+ $ KBUILD_BUILD_TIMESTAMP="Mon Oct 13 00:00:00 UTC 2025" make
+
+The default value is the output of the date command at one point during
+build. If provided, this timestamp will also be used for mtime fields
+within any initramfs archive. Initramfs mtimes are 32-bit, so dates before
+the 1970 Unix epoch, or after 2106-02-07 06:28:15 UTC will fail.
KBUILD_BUILD_USER, KBUILD_BUILD_HOST
------------------------------------
diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index 858ed5d80def..abce88f15d7c 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -70,7 +70,11 @@ applicable everywhere (see syntax).
Every menu entry can have at most one prompt, which is used to display
to the user. Optionally dependencies only for this prompt can be added
- with "if".
+ with "if". If a prompt is not present, the config option is a non-visible
+ symbol, meaning its value cannot be directly changed by the user (such as
+ altering the value in ``.config``) and the option will not appear in any
+ config menus. Its value can only be set via "default" and "select" (see
+ below).
- default value: "default" <expr> ["if" <expr>]
@@ -150,6 +154,12 @@ applicable everywhere (see syntax).
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
+ If "select" <symbol> is followed by "if" <expr>, <symbol> will be
+ selected by the logical AND of the value of the current menu symbol
+ and <expr>. This means, the lower limit can be downgraded due to the
+ presence of "if" <expr>. This behavior may seem weird, but we rely on
+ it. (The future of this behavior is undecided.)
+
- weak reverse dependencies: "imply" <symbol> ["if" <expr>]
This is similar to "select" as it enforces a lower limit on another
@@ -184,16 +194,6 @@ applicable everywhere (see syntax).
ability to hook into a secondary subsystem while allowing the user to
configure that subsystem out without also having to unset these drivers.
- Note: If the combination of FOO=y and BAR=m causes a link error,
- you can guard the function call with IS_REACHABLE()::
-
- foo_init()
- {
- if (IS_REACHABLE(CONFIG_BAZ))
- baz_register(&foo);
- ...
- }
-
Note: If the feature provided by BAZ is highly desirable for FOO,
FOO should imply not only BAZ, but also its dependency BAR::
@@ -202,6 +202,10 @@ applicable everywhere (see syntax).
imply BAR
imply BAZ
+ Note: If "imply" <symbol> is followed by "if" <expr>, the default of <symbol>
+ will be the logical AND of the value of the current menu symbol and <expr>.
+ (The future of this behavior is undecided.)
+
- limiting menu display: "visible if" <expr>
This attribute is only applicable to menu blocks, if the condition is
@@ -228,6 +232,38 @@ applicable everywhere (see syntax).
enables the third modular state for all config symbols.
At most one symbol may have the "modules" option set.
+- transitional attribute: "transitional"
+ This declares the symbol as transitional, meaning it should be processed
+ during configuration but omitted from newly written .config files.
+ Transitional symbols are useful for backward compatibility during config
+ option migrations - they allow olddefconfig to process existing .config
+ files while ensuring the old option doesn't appear in new configurations.
+
+ A transitional symbol:
+ - Has no prompt (is not visible to users in menus)
+ - Is processed normally during configuration (values are read and used)
+ - Can be referenced in default expressions of other symbols
+ - Is not written to new .config files
+ - Cannot have any other properties (it is a pass-through option)
+
+ Example migration from OLD_NAME to NEW_NAME::
+
+ config NEW_NAME
+ bool "New option name"
+ default OLD_NAME
+ help
+ This replaces the old CONFIG_OLD_NAME option.
+
+ config OLD_NAME
+ bool
+ transitional
+ help
+ Transitional config for OLD_NAME to NEW_NAME migration.
+
+ With this setup, existing .config files with "CONFIG_OLD_NAME=y" will
+ result in "CONFIG_NEW_NAME=y" being set, while CONFIG_OLD_NAME will be
+ omitted from newly written .config files.
+
Menu dependencies
-----------------
@@ -393,29 +429,15 @@ of C0, which doesn't depend on M::
choices::
- "choice" [symbol]
+ "choice"
<choice options>
<choice block>
"endchoice"
-This defines a choice group and accepts any of the above attributes as
-options. A choice can only be of type bool or tristate. If no type is
-specified for a choice, its type will be determined by the type of
-the first choice element in the group or remain unknown if none of the
-choice elements have a type specified, as well.
-
-While a boolean choice only allows a single config entry to be
-selected, a tristate choice also allows any number of config entries
-to be set to 'm'. This can be used if multiple drivers for a single
-hardware exists and only a single driver can be compiled/loaded into
-the kernel, but all drivers can be compiled as modules.
-
-A choice accepts another option "optional", which allows to set the
-choice to 'n' and no entry needs to be selected.
-If no [symbol] is associated with a choice, then you can not have multiple
-definitions of that choice. If a [symbol] is associated to the choice,
-then you may define the same choice (i.e. with the same entries) in another
-place.
+This defines a choice group and accepts "prompt", "default", "depends on", and
+"help" attributes as options.
+
+A choice only allows a single config entry to be selected.
comment::
@@ -573,6 +595,49 @@ above, leading to:
bool "Support for foo hardware"
depends on ARCH_FOO_VENDOR || COMPILE_TEST
+Optional dependencies
+~~~~~~~~~~~~~~~~~~~~~
+
+Some drivers are able to optionally use a feature from another module
+or build cleanly with that module disabled, but cause a link failure
+when trying to use that loadable module from a built-in driver.
+
+The most common way to express this optional dependency in Kconfig logic
+uses the slightly counterintuitive::
+
+ config FOO
+ tristate "Support for foo hardware"
+ depends on BAR || !BAR
+
+This means that there is either a dependency on BAR that disallows
+the combination of FOO=y with BAR=m, or BAR is completely disabled. The BAR
+module must provide all the stubs for !BAR case.
+
+For a more formalized approach if there are multiple drivers that have
+the same dependency, a helper symbol can be used, like::
+
+ config FOO
+ tristate "Support for foo hardware"
+ depends on BAR_OPTIONAL
+
+ config BAR_OPTIONAL
+ def_tristate BAR || !BAR
+
+Much less favorable way to express optional dependency is IS_REACHABLE() within
+the module code, useful for example when the module BAR does not provide
+!BAR stubs::
+
+ foo_init()
+ {
+ if (IS_REACHABLE(CONFIG_BAR))
+ bar_register(&foo);
+ ...
+ }
+
+IS_REACHABLE() is generally discouraged, because the code will be silently
+discarded, when CONFIG_BAR=m and this code is built-in. This is not what users
+usually expect when enabling BAR as module.
+
Kconfig recursive dependency limitations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/kbuild/kconfig.rst b/Documentation/kbuild/kconfig.rst
index 5967c79c3baa..d213c4f599a4 100644
--- a/Documentation/kbuild/kconfig.rst
+++ b/Documentation/kbuild/kconfig.rst
@@ -1,17 +1,20 @@
-===================
-Kconfig make config
-===================
+=================================
+Configuration targets and editors
+=================================
-This file contains some assistance for using `make *config`.
+This file contains some assistance for using ``make *config``.
-Use "make help" to list all of the possible configuration targets.
+Use ``make help`` to list all of the possible configuration targets.
The xconfig ('qconf'), menuconfig ('mconf'), and nconfig ('nconf')
programs also have embedded help text. Be sure to check that for
navigation, search, and other general help text.
+The gconfig ('gconf') program has limited help text.
+
+
General
--------
+=======
New kernel releases often introduce new config symbols. Often more
important, new kernel releases may rename config symbols. When
@@ -22,109 +25,102 @@ symbols have been introduced.
To see a list of new config symbols, use::
- cp user/some/old.config .config
- make listnewconfig
+ cp user/some/old.config .config
+ make listnewconfig
and the config program will list any new symbols, one per line.
Alternatively, you can use the brute force method::
- make oldconfig
- scripts/diffconfig .config.old .config | less
-
-----------------------------------------------------------------------
+ make oldconfig
+ scripts/diffconfig .config.old .config | less
-Environment variables for `*config`
-KCONFIG_CONFIG
---------------
-This environment variable can be used to specify a default kernel config
-file name to override the default name of ".config".
+Environment variables
+=====================
-KCONFIG_DEFCONFIG_LIST
-----------------------
+Environment variables for ``*config``:
-This environment variable specifies a list of config files which can be used
-as a base configuration in case the .config does not exist yet. Entries in
-the list are separated with whitespaces to each other, and the first one
-that exists is used.
+``KCONFIG_CONFIG``
+ This environment variable can be used to specify a default kernel config
+ file name to override the default name of ".config".
-KCONFIG_OVERWRITECONFIG
------------------------
-If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
-break symlinks when .config is a symlink to somewhere else.
+``KCONFIG_DEFCONFIG_LIST``
+ This environment variable specifies a list of config files which can be
+ used as a base configuration in case the .config does not exist yet.
+ Entries in the list are separated with whitespaces to each other, and
+ the first one that exists is used.
-`CONFIG_`
----------
-If you set `CONFIG_` in the environment, Kconfig will prefix all symbols
-with its value when saving the configuration, instead of using the default,
-`CONFIG_`.
+``KCONFIG_OVERWRITECONFIG``
+ If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
+ break symlinks when .config is a symlink to somewhere else.
-----------------------------------------------------------------------
+``KCONFIG_WARN_UNKNOWN_SYMBOLS``
+ This environment variable makes Kconfig warn about all unrecognized
+ symbols in the config input.
-Environment variables for '{allyes/allmod/allno/rand}config'
+``KCONFIG_WERROR``
+ If set, Kconfig treats warnings as errors.
-KCONFIG_ALLCONFIG
------------------
-(partially based on lkml email from/by Rob Landley, re: miniconfig)
+``CONFIG_``
+ If you set ``CONFIG_`` in the environment, Kconfig will prefix all symbols
+ with its value when saving the configuration, instead of using the
+ default, ``CONFIG_``.
---------------------------------------------------
+Environment variables for ``{allyes/allmod/allno/alldef/rand}config``:
-The allyesconfig/allmodconfig/allnoconfig/randconfig variants can also
-use the environment variable KCONFIG_ALLCONFIG as a flag or a filename
-that contains config symbols that the user requires to be set to a
-specific value. If KCONFIG_ALLCONFIG is used without a filename where
-KCONFIG_ALLCONFIG == "" or KCONFIG_ALLCONFIG == "1", `make *config`
-checks for a file named "all{yes/mod/no/def/random}.config"
-(corresponding to the `*config` command that was used) for symbol values
-that are to be forced. If this file is not found, it checks for a
-file named "all.config" to contain forced values.
+``KCONFIG_ALLCONFIG``
+ The allyesconfig/allmodconfig/alldefconfig/allnoconfig/randconfig variants
+ can also use the environment variable KCONFIG_ALLCONFIG as a flag or a
+ filename that contains config symbols that the user requires to be set to a
+ specific value. If KCONFIG_ALLCONFIG is used without a filename where
+ KCONFIG_ALLCONFIG == "" or KCONFIG_ALLCONFIG == "1", ``make *config``
+ checks for a file named "all{yes/mod/no/def/random}.config"
+ (corresponding to the ``*config`` command that was used) for symbol values
+ that are to be forced. If this file is not found, it checks for a
+ file named "all.config" to contain forced values.
-This enables you to create "miniature" config (miniconfig) or custom
-config files containing just the config symbols that you are interested
-in. Then the kernel config system generates the full .config file,
-including symbols of your miniconfig file.
+ This enables you to create "miniature" config (miniconfig) or custom
+ config files containing just the config symbols that you are interested
+ in. Then the kernel config system generates the full .config file,
+ including symbols of your miniconfig file.
-This 'KCONFIG_ALLCONFIG' file is a config file which contains
-(usually a subset of all) preset config symbols. These variable
-settings are still subject to normal dependency checks.
+ This ``KCONFIG_ALLCONFIG`` file is a config file which contains
+ (usually a subset of all) preset config symbols. These variable
+ settings are still subject to normal dependency checks.
-Examples::
-
- KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
+ Examples::
-or::
+ KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
- KCONFIG_ALLCONFIG=mini.config make allnoconfig
+ or::
-or::
+ KCONFIG_ALLCONFIG=mini.config make allnoconfig
- make KCONFIG_ALLCONFIG=mini.config allnoconfig
+ or::
-These examples will disable most options (allnoconfig) but enable or
-disable the options that are explicitly listed in the specified
-mini-config files.
+ make KCONFIG_ALLCONFIG=mini.config allnoconfig
-----------------------------------------------------------------------
+ These examples will disable most options (allnoconfig) but enable or
+ disable the options that are explicitly listed in the specified
+ mini-config files.
-Environment variables for 'randconfig'
+Environment variables for ``randconfig``:
-KCONFIG_SEED
-------------
-You can set this to the integer value used to seed the RNG, if you want
-to somehow debug the behaviour of the kconfig parser/frontends.
-If not set, the current time will be used.
+``KCONFIG_SEED``
+ You can set this to the integer value used to seed the RNG, if you want
+ to somehow debug the behaviour of the kconfig parser/frontends.
+ If not set, the current time will be used.
-KCONFIG_PROBABILITY
--------------------
-This variable can be used to skew the probabilities. This variable can
-be unset or empty, or set to three different formats:
+``KCONFIG_PROBABILITY``
+ This variable can be used to skew the probabilities. This variable can
+ be unset or empty, or set to three different formats:
======================= ================== =====================
- KCONFIG_PROBABILITY y:n split y:m:n split
+ KCONFIG_PROBABILITY y:n split y:m:n split
======================= ================== =====================
- unset or empty 50 : 50 33 : 33 : 34
- N N : 100-N N/2 : N/2 : 100-N
+ unset or empty 50 : 50 33 : 33 : 34
+ N N : 100-N N/2 : N/2 : 100-N
[1] N:M N+M : 100-(N+M) N : M : 100-(N+M)
[2] N:M:L N : 100-N M : L : 100-(M+L)
======================= ================== =====================
@@ -138,108 +134,98 @@ that:
Examples::
- KCONFIG_PROBABILITY=10
- 10% of booleans will be set to 'y', 90% to 'n'
- 5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
- KCONFIG_PROBABILITY=15:25
- 40% of booleans will be set to 'y', 60% to 'n'
- 15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
- KCONFIG_PROBABILITY=10:15:15
- 10% of booleans will be set to 'y', 90% to 'n'
- 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
-
-----------------------------------------------------------------------
+ KCONFIG_PROBABILITY=10
+ 10% of booleans will be set to 'y', 90% to 'n'
+ 5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
+ KCONFIG_PROBABILITY=15:25
+ 40% of booleans will be set to 'y', 60% to 'n'
+ 15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
+ KCONFIG_PROBABILITY=10:15:15
+ 10% of booleans will be set to 'y', 90% to 'n'
+ 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
-Environment variables for 'syncconfig'
+Environment variables for ``syncconfig``:
-KCONFIG_NOSILENTUPDATE
-----------------------
-If this variable has a non-blank value, it prevents silent kernel
-config updates (requires explicit updates).
+``KCONFIG_NOSILENTUPDATE``
+ If this variable has a non-blank value, it prevents silent kernel
+ config updates (requires explicit updates).
-KCONFIG_AUTOCONFIG
-------------------
-This environment variable can be set to specify the path & name of the
-"auto.conf" file. Its default value is "include/config/auto.conf".
+``KCONFIG_AUTOCONFIG``
+ This environment variable can be set to specify the path & name of the
+ "auto.conf" file. Its default value is "include/config/auto.conf".
-KCONFIG_AUTOHEADER
-------------------
-This environment variable can be set to specify the path & name of the
-"autoconf.h" (header) file.
-Its default value is "include/generated/autoconf.h".
+``KCONFIG_AUTOHEADER``
+ This environment variable can be set to specify the path & name of the
+ "autoconf.h" (header) file.
+ Its default value is "include/generated/autoconf.h".
-----------------------------------------------------------------------
-
menuconfig
-----------
-
-SEARCHING for CONFIG symbols
+==========
Searching in menuconfig:
- The Search function searches for kernel configuration symbol
- names, so you have to know something close to what you are
- looking for.
+ The Search function searches for kernel configuration symbol
+ names, so you have to know something close to what you are
+ looking for.
- Example::
+ Example::
- /hotplug
- This lists all config symbols that contain "hotplug",
- e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
+ /hotplug
+ This lists all config symbols that contain "hotplug",
+ e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
- For search help, enter / followed by TAB-TAB (to highlight
- <Help>) and Enter. This will tell you that you can also use
- regular expressions (regexes) in the search string, so if you
- are not interested in MEMORY_HOTPLUG, you could try::
+ For search help, enter / followed by TAB-TAB (to highlight
+ <Help>) and Enter. This will tell you that you can also use
+ regular expressions (regexes) in the search string, so if you
+ are not interested in MEMORY_HOTPLUG, you could try::
- /^hotplug
+ /^hotplug
- When searching, symbols are sorted thus:
+ When searching, symbols are sorted thus:
- - first, exact matches, sorted alphabetically (an exact match
- is when the search matches the complete symbol name);
- - then, other matches, sorted alphabetically.
+ - first, exact matches, sorted alphabetically (an exact match
+ is when the search matches the complete symbol name);
+ - then, other matches, sorted alphabetically.
- For example: ^ATH.K matches:
+ For example, ^ATH.K matches:
- ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
- [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
+ ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
+ [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
- of which only ATH5K and ATH9K match exactly and so are sorted
- first (and in alphabetical order), then come all other symbols,
- sorted in alphabetical order.
+ of which only ATH5K and ATH9K match exactly and so are sorted
+ first (and in alphabetical order), then come all other symbols,
+ sorted in alphabetical order.
-----------------------------------------------------------------------
+ In this menu, pressing the key in the (#) prefix will jump
+ directly to that location. You will be returned to the current
+ search results after exiting this new menu.
-User interface options for 'menuconfig'
+User interface options for 'menuconfig':
-MENUCONFIG_COLOR
-----------------
-It is possible to select different color themes using the variable
-MENUCONFIG_COLOR. To select a theme use::
+``MENUCONFIG_COLOR``
+ It is possible to select different color themes using the variable
+ MENUCONFIG_COLOR. To select a theme use::
- make MENUCONFIG_COLOR=<theme> menuconfig
+ make MENUCONFIG_COLOR=<theme> menuconfig
-Available themes are::
+ Available themes are::
- - mono => selects colors suitable for monochrome displays
- - blackbg => selects a color scheme with black background
- - classic => theme with blue background. The classic look
- - bluetitle => a LCD friendly version of classic. (default)
+ - mono => selects colors suitable for monochrome displays
+ - blackbg => selects a color scheme with black background
+ - classic => theme with blue background. The classic look
+ - bluetitle => a LCD friendly version of classic. (default)
-MENUCONFIG_MODE
----------------
-This mode shows all sub-menus in one large tree.
+``MENUCONFIG_MODE``
+ This mode shows all sub-menus in one large tree.
-Example::
+ Example::
- make MENUCONFIG_MODE=single_menu menuconfig
+ make MENUCONFIG_MODE=single_menu menuconfig
-----------------------------------------------------------------------
nconfig
--------
+=======
nconfig is an alternate text-based configurator. It lists function
keys across the bottom of the terminal (window) that execute commands.
@@ -251,57 +237,59 @@ Use F1 for Global help or F3 for the Short help menu.
Searching in nconfig:
- You can search either in the menu entry "prompt" strings
- or in the configuration symbols.
+ You can search either in the menu entry "prompt" strings
+ or in the configuration symbols.
+
+ Use / to begin a search through the menu entries. This does
+ not support regular expressions. Use <Down> or <Up> for
+ Next hit and Previous hit, respectively. Use <Esc> to
+ terminate the search mode.
- Use / to begin a search through the menu entries. This does
- not support regular expressions. Use <Down> or <Up> for
- Next hit and Previous hit, respectively. Use <Esc> to
- terminate the search mode.
+ F8 (SymSearch) searches the configuration symbols for the
+ given string or regular expression (regex).
- F8 (SymSearch) searches the configuration symbols for the
- given string or regular expression (regex).
+ In the SymSearch, pressing the key in the (#) prefix will
+ jump directly to that location. You will be returned to the
+ current search results after exiting this new menu.
-NCONFIG_MODE
-------------
-This mode shows all sub-menus in one large tree.
+Environment variables:
-Example::
+``NCONFIG_MODE``
+ This mode shows all sub-menus in one large tree.
- make NCONFIG_MODE=single_menu nconfig
+ Example::
+
+ make NCONFIG_MODE=single_menu nconfig
-----------------------------------------------------------------------
xconfig
--------
+=======
Searching in xconfig:
- The Search function searches for kernel configuration symbol
- names, so you have to know something close to what you are
- looking for.
-
- Example::
+ The Search function searches for kernel configuration symbol
+ names, so you have to know something close to what you are
+ looking for.
- Ctrl-F hotplug
+ Example::
- or::
+ Ctrl-F hotplug
- Menu: File, Search, hotplug
+ or::
- lists all config symbol entries that contain "hotplug" in
- the symbol name. In this Search dialog, you may change the
- config setting for any of the entries that are not grayed out.
- You can also enter a different search string without having
- to return to the main menu.
+ Menu: File, Search, hotplug
+ lists all config symbol entries that contain "hotplug" in
+ the symbol name. In this Search dialog, you may change the
+ config setting for any of the entries that are not grayed out.
+ You can also enter a different search string without having
+ to return to the main menu.
-----------------------------------------------------------------------
gconfig
--------
+=======
Searching in gconfig:
- There is no search command in gconfig. However, gconfig does
- have several different viewing choices, modes, and options.
+ There is no search command in gconfig. However, gconfig does
+ have several different viewing choices, modes, and options.
diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index 6b2bac8e9ce0..bc8a283bc44b 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -15,57 +15,48 @@ such as GCC and binutils. Ongoing work has allowed for `Clang
<https://clang.llvm.org/>`_ and `LLVM <https://llvm.org/>`_ utilities to be
used as viable substitutes. Distributions such as `Android
<https://www.android.com/>`_, `ChromeOS
-<https://www.chromium.org/chromium-os>`_, and `OpenMandriva
-<https://www.openmandriva.org/>`_ use Clang built kernels. `LLVM is a
-collection of toolchain components implemented in terms of C++ objects
-<https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM that
-supports C and the GNU C extensions required by the kernel, and is pronounced
-"klang," not "see-lang."
-
-Clang
------
-
-The compiler used can be swapped out via ``CC=`` command line argument to ``make``.
-``CC=`` should be set when selecting a config and during a build. ::
+<https://www.chromium.org/chromium-os>`_, `OpenMandriva
+<https://www.openmandriva.org/>`_, and `Chimera Linux
+<https://chimera-linux.org/>`_ use Clang built kernels. Google's and Meta's
+datacenter fleets also run kernels built with Clang.
- make CC=clang defconfig
+`LLVM is a collection of toolchain components implemented in terms of C++
+objects <https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM
+that supports C and the GNU C extensions required by the kernel, and is
+pronounced "klang," not "see-lang."
- make CC=clang
-
-Cross Compiling
----------------
+Building with LLVM
+------------------
-A single Clang compiler binary will typically contain all supported backends,
-which can help simplify cross compiling. ::
+Invoke ``make`` via::
- make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu-
+ make LLVM=1
-``CROSS_COMPILE`` is not used to prefix the Clang compiler binary, instead
-``CROSS_COMPILE`` is used to set a command line flag: ``--target=<triple>``. For
-example: ::
+to compile for the host target. For cross compiling::
- clang --target=aarch64-linux-gnu foo.c
+ make LLVM=1 ARCH=arm64
-LLVM Utilities
---------------
+The LLVM= argument
+------------------
-LLVM has substitutes for GNU binutils utilities. They can be enabled individually.
-The full list of supported make variables::
+LLVM has substitutes for GNU binutils utilities. They can be enabled
+individually. The full list of supported make variables::
make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld
-To simplify the above command, Kbuild supports the ``LLVM`` variable::
-
- make LLVM=1
+``LLVM=1`` expands to the above.
If your LLVM tools are not available in your PATH, you can supply their
location using the LLVM variable with a trailing slash::
make LLVM=/path/to/llvm/
-which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc.
+which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. The
+following may also be used::
+
+ PATH=/path/to/llvm:$PATH make LLVM=1
If your LLVM tools have a version suffix and you want to test with that
explicit version rather than the unsuffixed executables like ``LLVM=1``, you
@@ -75,31 +66,72 @@ can pass the suffix using the ``LLVM`` variable::
which will use ``clang-14``, ``ld.lld-14``, etc.
+To support combinations of out of tree paths with version suffixes, we
+recommend::
+
+ PATH=/path/to/llvm/:$PATH make LLVM=-14
+
``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like
-``LLVM=1``. If you only wish to use certain LLVM utilities, use their respective
-make variables.
+``LLVM=1``. If you only wish to use certain LLVM utilities, use their
+respective make variables.
+
+The same value used for ``LLVM=`` should be set for each invocation of ``make``
+if configuring and building via distinct commands. ``LLVM=`` should also be set
+as an environment variable when running scripts that will eventually run
+``make``.
+
+Cross Compiling
+---------------
-The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to
-disable it.
+A single Clang compiler binary (and corresponding LLVM utilities) will
+typically contain all supported back ends, which can help simplify cross
+compiling especially when ``LLVM=1`` is used. If you use only LLVM tools,
+``CROSS_COMPILE`` or target-triple-prefixes become unnecessary. Example::
-Omitting CROSS_COMPILE
+ make LLVM=1 ARCH=arm64
+
+As an example of mixing LLVM and GNU utilities, for a target like ``ARCH=s390``
+which does not yet have ``ld.lld`` or ``llvm-objcopy`` support, you could
+invoke ``make`` via::
+
+ make LLVM=1 ARCH=s390 LD=s390x-linux-gnu-ld.bfd \
+ OBJCOPY=s390x-linux-gnu-objcopy
+
+This example will invoke ``s390x-linux-gnu-ld.bfd`` as the linker and
+``s390x-linux-gnu-objcopy``, so ensure those are reachable in your ``$PATH``.
+
+``CROSS_COMPILE`` is not used to prefix the Clang compiler binary (or
+corresponding LLVM utilities) as is the case for GNU utilities when ``LLVM=1``
+is not set.
+
+The LLVM_IAS= argument
----------------------
-As explained above, ``CROSS_COMPILE`` is used to set ``--target=<triple>``.
+Clang can assemble assembler code. You can pass ``LLVM_IAS=0`` to disable this
+behavior and have Clang invoke the corresponding non-integrated assembler
+instead. Example::
+
+ make LLVM=1 LLVM_IAS=0
-If ``CROSS_COMPILE`` is not specified, the ``--target=<triple>`` is inferred
-from ``ARCH``.
+``CROSS_COMPILE`` is necessary when cross compiling and ``LLVM_IAS=0``
+is used in order to set ``--prefix=`` for the compiler to find the
+corresponding non-integrated assembler (typically, you don't want to use the
+system assembler when targeting another architecture). Example::
-That means if you use only LLVM tools, ``CROSS_COMPILE`` becomes unnecessary.
+ make LLVM=1 ARCH=arm LLVM_IAS=0 CROSS_COMPILE=arm-linux-gnueabi-
-For example, to cross-compile the arm64 kernel::
- make ARCH=arm64 LLVM=1
+Ccache
+------
-If ``LLVM_IAS=0`` is specified, ``CROSS_COMPILE`` is also used to derive
-``--prefix=<path>`` to search for the GNU assembler and linker. ::
+``ccache`` can be used with ``clang`` to improve subsequent builds, (though
+KBUILD_BUILD_TIMESTAMP_ should be set to a deterministic value between builds
+in order to avoid 100% cache misses, see Reproducible_builds_ for more info)::
- make ARCH=arm64 LLVM=1 LLVM_IAS=0 CROSS_COMPILE=aarch64-linux-gnu-
+ KBUILD_BUILD_TIMESTAMP='' make LLVM=1 CC="ccache clang"
+
+.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
+.. _Reproducible_builds: reproducible-builds.html#timestamps
Supported Architectures
-----------------------
@@ -132,18 +164,24 @@ yet. Bug reports are always welcome at the issue tracker below!
* - hexagon
- Maintained
- ``LLVM=1``
+ * - loongarch
+ - Maintained
+ - ``LLVM=1``
* - mips
- Maintained
- ``LLVM=1``
* - powerpc
- Maintained
- - ``CC=clang``
+ - ``LLVM=1``
* - riscv
- - Maintained
+ - Supported
- ``LLVM=1``
* - s390
- Maintained
- - ``CC=clang``
+ - ``LLVM=1`` (LLVM >= 18.1.0), ``CC=clang`` (LLVM < 18.1.0)
+ * - sparc (sparc64 only)
+ - Maintained
+ - ``CC=clang LLVM_IAS=0`` (LLVM >= 20)
* - um (User Mode)
- Maintained
- ``LLVM=1``
@@ -168,6 +206,14 @@ Getting Help
Getting LLVM
-------------
+We provide prebuilt stable versions of LLVM on `kernel.org
+<https://kernel.org/pub/tools/llvm/>`_. These have been optimized with profile
+data for building Linux kernels, which should improve kernel build times
+relative to other distributions of LLVM.
+
+Below are links that may be useful for building LLVM from source or procuring
+it through a distribution's package manager.
+
- https://releases.llvm.org/download.html
- https://github.com/llvm/llvm-project
- https://llvm.org/docs/GettingStarted.html
diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
index 5ea1e72d89c8..8aef3650c1f3 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -4,69 +4,8 @@ Linux Kernel Makefiles
This document describes the Linux kernel Makefiles.
-.. Table of Contents
-
- === 1 Overview
- === 2 Who does what
- === 3 The kbuild files
- --- 3.1 Goal definitions
- --- 3.2 Built-in object goals - obj-y
- --- 3.3 Loadable module goals - obj-m
- --- 3.4 <deleted>
- --- 3.5 Library file goals - lib-y
- --- 3.6 Descending down in directories
- --- 3.7 Non-builtin vmlinux targets - extra-y
- --- 3.8 Always built goals - always-y
- --- 3.9 Compilation flags
- --- 3.10 Dependency tracking
- --- 3.11 Custom Rules
- --- 3.12 Command change detection
- --- 3.13 $(CC) support functions
- --- 3.14 $(LD) support functions
- --- 3.15 Script Invocation
-
- === 4 Host Program support
- --- 4.1 Simple Host Program
- --- 4.2 Composite Host Programs
- --- 4.3 Using C++ for host programs
- --- 4.4 Using Rust for host programs
- --- 4.5 Controlling compiler options for host programs
- --- 4.6 When host programs are actually built
-
- === 5 Userspace Program support
- --- 5.1 Simple Userspace Program
- --- 5.2 Composite Userspace Programs
- --- 5.3 Controlling compiler options for userspace programs
- --- 5.4 When userspace programs are actually built
-
- === 6 Kbuild clean infrastructure
-
- === 7 Architecture Makefiles
- --- 7.1 Set variables to tweak the build to the architecture
- --- 7.2 Add prerequisites to archheaders
- --- 7.3 Add prerequisites to archprepare
- --- 7.4 List directories to visit when descending
- --- 7.5 Architecture-specific boot images
- --- 7.6 Building non-kbuild targets
- --- 7.7 Commands useful for building a boot image
- --- 7.8 <deleted>
- --- 7.9 Preprocessing linker scripts
- --- 7.10 Generic header files
- --- 7.11 Post-link pass
-
- === 8 Kbuild syntax for exported headers
- --- 8.1 no-export-headers
- --- 8.2 generic-y
- --- 8.3 generated-y
- --- 8.4 mandatory-y
-
- === 9 Kbuild Variables
- === 10 Makefile language
- === 11 Credits
- === 12 TODO
-
-1 Overview
-==========
+Overview
+========
The Makefiles have five parts::
@@ -83,6 +22,7 @@ The top Makefile is responsible for building two major products: vmlinux
(the resident kernel image) and modules (any module files).
It builds these goals by recursively descending into the subdirectories of
the kernel source tree.
+
The list of subdirectories which are visited depends upon the kernel
configuration. The top Makefile textually includes an arch Makefile
with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies
@@ -96,14 +36,13 @@ any built-in or modular targets.
scripts/Makefile.* contains all the definitions/rules etc. that
are used to build the kernel based on the kbuild makefiles.
-
-2 Who does what
-===============
+Who does what
+=============
People have four different relationships with the kernel Makefiles.
*Users* are people who build kernels. These people type commands such as
-"make menuconfig" or "make". They usually do not read or edit
+``make menuconfig`` or ``make``. They usually do not read or edit
any kernel Makefiles (or any other source files).
*Normal developers* are people who work on features such as device
@@ -114,7 +53,7 @@ knowledge about the kernel Makefiles, plus detailed knowledge about the
public interface for kbuild.
*Arch developers* are people who work on an entire architecture, such
-as sparc or ia64. Arch developers need to know about the arch Makefile
+as sparc or x86. Arch developers need to know about the arch Makefile
as well as kbuild Makefiles.
*Kbuild developers* are people who work on the kernel build system itself.
@@ -123,1412 +62,1462 @@ These people need to know about all aspects of the kernel Makefiles.
This document is aimed towards normal developers and arch developers.
-3 The kbuild files
-==================
+The kbuild files
+================
Most Makefiles within the kernel are kbuild Makefiles that use the
kbuild infrastructure. This chapter introduces the syntax used in the
kbuild makefiles.
-The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can
-be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild'
+
+The preferred name for the kbuild files are ``Makefile`` but ``Kbuild`` can
+be used and if both a ``Makefile`` and a ``Kbuild`` file exists, then the ``Kbuild``
file will be used.
-Section 3.1 "Goal definitions" is a quick intro; further chapters provide
+Section `Goal definitions`_ is a quick intro; further chapters provide
more details, with real examples.
-3.1 Goal definitions
---------------------
+Goal definitions
+----------------
- Goal definitions are the main part (heart) of the kbuild Makefile.
- These lines define the files to be built, any special compilation
- options, and any subdirectories to be entered recursively.
+Goal definitions are the main part (heart) of the kbuild Makefile.
+These lines define the files to be built, any special compilation
+options, and any subdirectories to be entered recursively.
- The most simple kbuild makefile contains one line:
+The most simple kbuild makefile contains one line:
- Example::
+Example::
- obj-y += foo.o
+ obj-y += foo.o
- This tells kbuild that there is one object in that directory, named
- foo.o. foo.o will be built from foo.c or foo.S.
+This tells kbuild that there is one object in that directory, named
+foo.o. foo.o will be built from foo.c or foo.S.
- If foo.o shall be built as a module, the variable obj-m is used.
- Therefore the following pattern is often used:
+If foo.o shall be built as a module, the variable obj-m is used.
+Therefore the following pattern is often used:
- Example::
+Example::
- obj-$(CONFIG_FOO) += foo.o
+ obj-$(CONFIG_FOO) += foo.o
- $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).
- If CONFIG_FOO is neither y nor m, then the file will not be compiled
- nor linked.
+$(CONFIG_FOO) evaluates to either y (for built-in) or m (for module).
+If CONFIG_FOO is neither y nor m, then the file will not be compiled
+nor linked.
-3.2 Built-in object goals - obj-y
----------------------------------
+Built-in object goals - obj-y
+-----------------------------
- The kbuild Makefile specifies object files for vmlinux
- in the $(obj-y) lists. These lists depend on the kernel
- configuration.
+The kbuild Makefile specifies object files for vmlinux
+in the $(obj-y) lists. These lists depend on the kernel
+configuration.
- Kbuild compiles all the $(obj-y) files. It then calls
- "$(AR) rcSTP" to merge these files into one built-in.a file.
- This is a thin archive without a symbol table. It will be later
- linked into vmlinux by scripts/link-vmlinux.sh
+Kbuild compiles all the $(obj-y) files. It then calls
+``$(AR) rcSTP`` to merge these files into one built-in.a file.
+This is a thin archive without a symbol table. It will be later
+linked into vmlinux by scripts/link-vmlinux.sh
- The order of files in $(obj-y) is significant. Duplicates in
- the lists are allowed: the first instance will be linked into
- built-in.a and succeeding instances will be ignored.
+The order of files in $(obj-y) is significant. Duplicates in
+the lists are allowed: the first instance will be linked into
+built-in.a and succeeding instances will be ignored.
- Link order is significant, because certain functions
- (module_init() / __initcall) will be called during boot in the
- order they appear. So keep in mind that changing the link
- order may e.g. change the order in which your SCSI
- controllers are detected, and thus your disks are renumbered.
+Link order is significant, because certain functions
+(module_init() / __initcall) will be called during boot in the
+order they appear. So keep in mind that changing the link
+order may e.g. change the order in which your SCSI
+controllers are detected, and thus your disks are renumbered.
- Example::
+Example::
- #drivers/isdn/i4l/Makefile
- # Makefile for the kernel ISDN subsystem and device drivers.
- # Each configuration option enables a list of files.
- obj-$(CONFIG_ISDN_I4L) += isdn.o
- obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
+ #drivers/isdn/i4l/Makefile
+ # Makefile for the kernel ISDN subsystem and device drivers.
+ # Each configuration option enables a list of files.
+ obj-$(CONFIG_ISDN_I4L) += isdn.o
+ obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
-3.3 Loadable module goals - obj-m
----------------------------------
+Loadable module goals - obj-m
+-----------------------------
+
+$(obj-m) specifies object files which are built as loadable
+kernel modules.
- $(obj-m) specifies object files which are built as loadable
- kernel modules.
+A module may be built from one source file or several source
+files. In the case of one source file, the kbuild makefile
+simply adds the file to $(obj-m).
- A module may be built from one source file or several source
- files. In the case of one source file, the kbuild makefile
- simply adds the file to $(obj-m).
+Example::
- Example::
+ #drivers/isdn/i4l/Makefile
+ obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
- #drivers/isdn/i4l/Makefile
- obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
+Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to "m"
- Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
+If a kernel module is built from several source files, you specify
+that you want to build a module in the same way as above; however,
+kbuild needs to know which object files you want to build your
+module from, so you have to tell it by setting a $(<module_name>-y)
+variable.
- If a kernel module is built from several source files, you specify
- that you want to build a module in the same way as above; however,
- kbuild needs to know which object files you want to build your
- module from, so you have to tell it by setting a $(<module_name>-y)
- variable.
+Example::
- Example::
+ #drivers/isdn/i4l/Makefile
+ obj-$(CONFIG_ISDN_I4L) += isdn.o
+ isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
- #drivers/isdn/i4l/Makefile
- obj-$(CONFIG_ISDN_I4L) += isdn.o
- isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
+In this example, the module name will be isdn.o. Kbuild will
+compile the objects listed in $(isdn-y) and then run
+``$(LD) -r`` on the list of these files to generate isdn.o.
- In this example, the module name will be isdn.o. Kbuild will
- compile the objects listed in $(isdn-y) and then run
- "$(LD) -r" on the list of these files to generate isdn.o.
+Due to kbuild recognizing $(<module_name>-y) for composite objects,
+you can use the value of a ``CONFIG_`` symbol to optionally include an
+object file as part of a composite object.
- Due to kbuild recognizing $(<module_name>-y) for composite objects,
- you can use the value of a `CONFIG_` symbol to optionally include an
- object file as part of a composite object.
+Example::
- Example::
+ #fs/ext2/Makefile
+ obj-$(CONFIG_EXT2_FS) += ext2.o
+ ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
+ namei.o super.o symlink.o
+ ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
+ xattr_trusted.o
- #fs/ext2/Makefile
- obj-$(CONFIG_EXT2_FS) += ext2.o
- ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
- namei.o super.o symlink.o
- ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
- xattr_trusted.o
+In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
+part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
+evaluates to "y".
- In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
- part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
- evaluates to 'y'.
+Note: Of course, when you are building objects into the kernel,
+the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
+kbuild will build an ext2.o file for you out of the individual
+parts and then link this into built-in.a, as you would expect.
- Note: Of course, when you are building objects into the kernel,
- the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
- kbuild will build an ext2.o file for you out of the individual
- parts and then link this into built-in.a, as you would expect.
+Library file goals - lib-y
+--------------------------
-3.5 Library file goals - lib-y
+Objects listed with obj-* are used for modules, or
+combined in a built-in.a for that specific directory.
+There is also the possibility to list objects that will
+be included in a library, lib.a.
+All objects listed with lib-y are combined in a single
+library for that directory.
+Objects that are listed in obj-y and additionally listed in
+lib-y will not be included in the library, since they will
+be accessible anyway.
+For consistency, objects listed in lib-m will be included in lib.a.
+
+Note that the same kbuild makefile may list files to be built-in
+and to be part of a library. Therefore the same directory
+may contain both a built-in.a and a lib.a file.
+
+Example::
+
+ #arch/x86/lib/Makefile
+ lib-y := delay.o
+
+This will create a library lib.a based on delay.o. For kbuild to
+actually recognize that there is a lib.a being built, the directory
+shall be listed in libs-y.
+
+See also `List directories to visit when descending`_.
+
+Use of lib-y is normally restricted to ``lib/`` and ``arch/*/lib``.
+
+Descending down in directories
------------------------------
- Objects listed with obj-* are used for modules, or
- combined in a built-in.a for that specific directory.
- There is also the possibility to list objects that will
- be included in a library, lib.a.
- All objects listed with lib-y are combined in a single
- library for that directory.
- Objects that are listed in obj-y and additionally listed in
- lib-y will not be included in the library, since they will
- be accessible anyway.
- For consistency, objects listed in lib-m will be included in lib.a.
+A Makefile is only responsible for building objects in its own
+directory. Files in subdirectories should be taken care of by
+Makefiles in these subdirs. The build system will automatically
+invoke make recursively in subdirectories, provided you let it know of
+them.
- Note that the same kbuild makefile may list files to be built-in
- and to be part of a library. Therefore the same directory
- may contain both a built-in.a and a lib.a file.
+To do so, obj-y and obj-m are used.
+ext2 lives in a separate directory, and the Makefile present in fs/
+tells kbuild to descend down using the following assignment.
- Example::
+Example::
- #arch/x86/lib/Makefile
- lib-y := delay.o
+ #fs/Makefile
+ obj-$(CONFIG_EXT2_FS) += ext2/
- This will create a library lib.a based on delay.o. For kbuild to
- actually recognize that there is a lib.a being built, the directory
- shall be listed in libs-y.
+If CONFIG_EXT2_FS is set to either "y" (built-in) or "m" (modular)
+the corresponding obj- variable will be set, and kbuild will descend
+down in the ext2 directory.
- See also "7.4 List directories to visit when descending".
+Kbuild uses this information not only to decide that it needs to visit
+the directory, but also to decide whether or not to link objects from
+the directory into vmlinux.
- Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
+When Kbuild descends into the directory with "y", all built-in objects
+from that directory are combined into the built-in.a, which will be
+eventually linked into vmlinux.
-3.6 Descending down in directories
-----------------------------------
+When Kbuild descends into the directory with "m", in contrast, nothing
+from that directory will be linked into vmlinux. If the Makefile in
+that directory specifies obj-y, those objects will be left orphan.
+It is very likely a bug of the Makefile or of dependencies in Kconfig.
- A Makefile is only responsible for building objects in its own
- directory. Files in subdirectories should be taken care of by
- Makefiles in these subdirs. The build system will automatically
- invoke make recursively in subdirectories, provided you let it know of
- them.
+Kbuild also supports dedicated syntax, subdir-y and subdir-m, for
+descending into subdirectories. It is a good fit when you know they
+do not contain kernel-space objects at all. A typical usage is to let
+Kbuild descend into subdirectories to build tools.
- To do so, obj-y and obj-m are used.
- ext2 lives in a separate directory, and the Makefile present in fs/
- tells kbuild to descend down using the following assignment.
+Examples::
- Example::
+ # scripts/Makefile
+ subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
+ subdir-$(CONFIG_MODVERSIONS) += genksyms
+ subdir-$(CONFIG_SECURITY_SELINUX) += selinux
- #fs/Makefile
- obj-$(CONFIG_EXT2_FS) += ext2/
+Unlike obj-y/m, subdir-y/m does not need the trailing slash since this
+syntax is always used for directories.
- If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular)
- the corresponding obj- variable will be set, and kbuild will descend
- down in the ext2 directory.
+It is good practice to use a ``CONFIG_`` variable when assigning directory
+names. This allows kbuild to totally skip the directory if the
+corresponding ``CONFIG_`` option is neither "y" nor "m".
- Kbuild uses this information not only to decide that it needs to visit
- the directory, but also to decide whether or not to link objects from
- the directory into vmlinux.
+Non-builtin vmlinux targets - extra-y
+-------------------------------------
- When Kbuild descends into the directory with 'y', all built-in objects
- from that directory are combined into the built-in.a, which will be
- eventually linked into vmlinux.
+extra-y specifies targets which are needed for building vmlinux,
+but not combined into built-in.a.
- When Kbuild descends into the directory with 'm', in contrast, nothing
- from that directory will be linked into vmlinux. If the Makefile in
- that directory specifies obj-y, those objects will be left orphan.
- It is very likely a bug of the Makefile or of dependencies in Kconfig.
+Examples are:
- Kbuild also supports dedicated syntax, subdir-y and subdir-m, for
- descending into subdirectories. It is a good fit when you know they
- do not contain kernel-space objects at all. A typical usage is to let
- Kbuild descend into subdirectories to build tools.
+1) vmlinux linker script
- Examples::
+ The linker script for vmlinux is located at
+ arch/$(SRCARCH)/kernel/vmlinux.lds
- # scripts/Makefile
- subdir-$(CONFIG_GCC_PLUGINS) += gcc-plugins
- subdir-$(CONFIG_MODVERSIONS) += genksyms
- subdir-$(CONFIG_SECURITY_SELINUX) += selinux
+Example::
- Unlike obj-y/m, subdir-y/m does not need the trailing slash since this
- syntax is always used for directories.
+ # arch/x86/kernel/Makefile
+ extra-y += vmlinux.lds
- It is good practice to use a `CONFIG_` variable when assigning directory
- names. This allows kbuild to totally skip the directory if the
- corresponding `CONFIG_` option is neither 'y' nor 'm'.
+extra-y is now deprecated because this is equivalent to:
-3.7 Non-builtin vmlinux targets - extra-y
------------------------------------------
+ always-$(KBUILD_BUILTIN) += vmlinux.lds
- extra-y specifies targets which are needed for building vmlinux,
- but not combined into built-in.a.
+$(extra-y) should only contain targets needed for vmlinux.
- Examples are:
+Kbuild skips extra-y when vmlinux is apparently not a final goal.
+(e.g. ``make modules``, or building external modules)
- 1) head objects
+If you intend to build targets unconditionally, always-y (explained
+in the next section) is the correct syntax to use.
- Some objects must be placed at the head of vmlinux. They are
- directly linked to vmlinux without going through built-in.a
- A typical use-case is an object that contains the entry point.
+Always built goals - always-y
+-----------------------------
- arch/$(SRCARCH)/Makefile should specify such objects as head-y.
+always-y specifies targets which are literally always built when
+Kbuild visits the Makefile.
- Discussion:
- Given that we can control the section order in the linker script,
- why do we need head-y?
+Example::
- 2) vmlinux linker script
+ # ./Kbuild
+ offsets-file := include/generated/asm-offsets.h
+ always-y += $(offsets-file)
- The linker script for vmlinux is located at
- arch/$(SRCARCH)/kernel/vmlinux.lds
+Compilation flags
+-----------------
- Example::
+ccflags-y, asflags-y and ldflags-y
+ These three flags apply only to the kbuild makefile in which they
+ are assigned. They are used for all the normal cc, as and ld
+ invocations happening during a recursive build.
- # arch/x86/kernel/Makefile
- extra-y := head_$(BITS).o
- extra-y += head$(BITS).o
- extra-y += ebda.o
- extra-y += platform-quirks.o
- extra-y += vmlinux.lds
+ ccflags-y specifies options for compiling with $(CC).
- $(extra-y) should only contain targets needed for vmlinux.
+ Example::
- Kbuild skips extra-y when vmlinux is apparently not a final goal.
- (e.g. 'make modules', or building external modules)
+ # drivers/acpi/acpica/Makefile
+ ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
+ ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
- If you intend to build targets unconditionally, always-y (explained
- in the next section) is the correct syntax to use.
+ This variable is necessary because the top Makefile owns the
+ variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
+ entire tree.
-3.8 Always built goals - always-y
----------------------------------
+ asflags-y specifies assembler options.
+
+ Example::
+
+ #arch/sparc/kernel/Makefile
+ asflags-y := -ansi
+
+ ldflags-y specifies options for linking with $(LD).
+
+ Example::
+
+ #arch/cris/boot/compressed/Makefile
+ ldflags-y += -T $(src)/decompress_$(arch-y).lds
+
+subdir-ccflags-y, subdir-asflags-y
+ The two flags listed above are similar to ccflags-y and asflags-y.
+ The difference is that the subdir- variants have effect for the kbuild
+ file where they are present and all subdirectories.
+ Options specified using subdir-* are added to the commandline before
+ the options specified using the non-subdir variants.
- always-y specifies targets which are literally always built when
- Kbuild visits the Makefile.
+ Example::
- Example::
- # ./Kbuild
- offsets-file := include/generated/asm-offsets.h
- always-y += $(offsets-file)
+ subdir-ccflags-y := -Werror
-3.9 Compilation flags
----------------------
+ccflags-remove-y, asflags-remove-y
+ These flags are used to remove particular flags for the compiler,
+ assembler invocations.
- ccflags-y, asflags-y and ldflags-y
- These three flags apply only to the kbuild makefile in which they
- are assigned. They are used for all the normal cc, as and ld
- invocations happening during a recursive build.
- Note: Flags with the same behaviour were previously named:
- EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
- They are still supported but their usage is deprecated.
+ Example::
- ccflags-y specifies options for compiling with $(CC).
+ ccflags-remove-$(CONFIG_MCOUNT) += -pg
- Example::
+CFLAGS_$@, AFLAGS_$@
+ CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
+ kbuild makefile.
- # drivers/acpi/acpica/Makefile
- ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
- ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
+ $(CFLAGS_$@) specifies per-file options for $(CC). The $@
+ part has a literal value which specifies the file that it is for.
- This variable is necessary because the top Makefile owns the
- variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
- entire tree.
+ CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@
+ can re-add compiler flags that were removed by ccflags-remove-y.
- asflags-y specifies assembler options.
+ Example::
+
+ # drivers/scsi/Makefile
+ CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
+
+ This line specify compilation flags for aha152x.o.
+
+ $(AFLAGS_$@) is a similar feature for source files in assembly
+ languages.
+
+ AFLAGS_$@ has the higher priority than asflags-remove-y; AFLAGS_$@
+ can re-add assembler flags that were removed by asflags-remove-y.
+
+ Example::
+
+ # arch/arm/kernel/Makefile
+ AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
+ AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
+ AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
+
+Dependency tracking
+-------------------
- Example::
+Kbuild tracks dependencies on the following:
- #arch/sparc/kernel/Makefile
- asflags-y := -ansi
+1) All prerequisite files (both ``*.c`` and ``*.h``)
+2) ``CONFIG_`` options used in all prerequisite files
+3) Command-line used to compile target
- ldflags-y specifies options for linking with $(LD).
+Thus, if you change an option to $(CC) all affected files will
+be re-compiled.
- Example::
+Custom Rules
+------------
- #arch/cris/boot/compressed/Makefile
- ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
+Custom rules are used when the kbuild infrastructure does
+not provide the required support. A typical example is
+header files generated during the build process.
+Another example are the architecture-specific Makefiles which
+need custom rules to prepare boot images etc.
- subdir-ccflags-y, subdir-asflags-y
- The two flags listed above are similar to ccflags-y and asflags-y.
- The difference is that the subdir- variants have effect for the kbuild
- file where they are present and all subdirectories.
- Options specified using subdir-* are added to the commandline before
- the options specified using the non-subdir variants.
+Custom rules are written as normal Make rules.
+Kbuild is not executing in the directory where the Makefile is
+located, so all custom rules shall use a relative
+path to prerequisite files and target files.
- Example::
+Two variables are used when defining custom rules:
- subdir-ccflags-y := -Werror
+$(src)
+ $(src) is the directory where the Makefile is located. Always use $(src) when
+ referring to files located in the src tree.
- ccflags-remove-y, asflags-remove-y
- These flags are used to remove particular flags for the compiler,
- assembler invocations.
+$(obj)
+ $(obj) is the directory where the target is saved. Always use $(obj) when
+ referring to generated files. Use $(obj) for pattern rules that need to work
+ for both generated files and real sources (VPATH will help to find the
+ prerequisites not only in the object tree but also in the source tree).
- Example::
+ Example::
- ccflags-remove-$(CONFIG_MCOUNT) += -pg
+ #drivers/scsi/Makefile
+ $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
+ $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
- CFLAGS_$@, AFLAGS_$@
- CFLAGS_$@ and AFLAGS_$@ only apply to commands in current
- kbuild makefile.
+ This is a custom rule, following the normal syntax
+ required by make.
- $(CFLAGS_$@) specifies per-file options for $(CC). The $@
- part has a literal value which specifies the file that it is for.
+ The target file depends on two prerequisite files. References
+ to the target file are prefixed with $(obj), references
+ to prerequisites are referenced with $(src) (because they are not
+ generated files).
- CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@
- can re-add compiler flags that were removed by ccflags-remove-y.
+$(srcroot)
+ $(srcroot) refers to the root of the source you are building, which can be
+ either the kernel source or the external modules source, depending on whether
+ KBUILD_EXTMOD is set. This can be either a relative or an absolute path, but
+ if KBUILD_ABS_SRCTREE=1 is set, it is always an absolute path.
- Example::
+$(srctree)
+ $(srctree) refers to the root of the kernel source tree. When building the
+ kernel, this is the same as $(srcroot).
- # drivers/scsi/Makefile
- CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
+$(objtree)
+ $(objtree) refers to the root of the kernel object tree. It is ``.`` when
+ building the kernel, but it is different when building external modules.
- This line specify compilation flags for aha152x.o.
+$(kecho)
+ echoing information to user in a rule is often a good practice
+ but when execution ``make -s`` one does not expect to see any output
+ except for warnings/errors.
+ To support this kbuild defines $(kecho) which will echo out the
+ text following $(kecho) to stdout except if ``make -s`` is used.
- $(AFLAGS_$@) is a similar feature for source files in assembly
- languages.
+ Example::
- AFLAGS_$@ has the higher priority than asflags-remove-y; AFLAGS_$@
- can re-add assembler flags that were removed by asflags-remove-y.
+ # arch/arm/Makefile
+ $(BOOT_TARGETS): vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+ @$(kecho) ' Kernel: $(boot)/$@ is ready'
- Example::
+ When kbuild is executing with KBUILD_VERBOSE unset, then only a shorthand
+ of a command is normally displayed.
+ To enable this behaviour for custom commands kbuild requires
+ two variables to be set::
- # arch/arm/kernel/Makefile
- AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
- AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
- AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
+ quiet_cmd_<command> - what shall be echoed
+ cmd_<command> - the command to execute
+ Example::
-3.10 Dependency tracking
+ # lib/Makefile
+ quiet_cmd_crc32 = GEN $@
+ cmd_crc32 = $< > $@
+
+ $(obj)/crc32table.h: $(obj)/gen_crc32table
+ $(call cmd,crc32)
+
+ When updating the $(obj)/crc32table.h target, the line::
+
+ GEN lib/crc32table.h
+
+ will be displayed with ``make KBUILD_VERBOSE=``.
+
+Command change detection
------------------------
- Kbuild tracks dependencies on the following:
+When the rule is evaluated, timestamps are compared between the target
+and its prerequisite files. GNU Make updates the target when any of the
+prerequisites is newer than that.
- 1) All prerequisite files (both `*.c` and `*.h`)
- 2) `CONFIG_` options used in all prerequisite files
- 3) Command-line used to compile target
+The target should be rebuilt also when the command line has changed
+since the last invocation. This is not supported by Make itself, so
+Kbuild achieves this by a kind of meta-programming.
- Thus, if you change an option to $(CC) all affected files will
- be re-compiled.
+if_changed is the macro used for this purpose, in the following form::
-3.11 Custom Rules
------------------
+ quiet_cmd_<command> = ...
+ cmd_<command> = ...
- Custom rules are used when the kbuild infrastructure does
- not provide the required support. A typical example is
- header files generated during the build process.
- Another example are the architecture-specific Makefiles which
- need custom rules to prepare boot images etc.
+ <target>: <source(s)> FORCE
+ $(call if_changed,<command>)
- Custom rules are written as normal Make rules.
- Kbuild is not executing in the directory where the Makefile is
- located, so all custom rules shall use a relative
- path to prerequisite files and target files.
+Any target that utilizes if_changed must be listed in $(targets),
+otherwise the command line check will fail, and the target will
+always be built.
- Two variables are used when defining custom rules:
+If the target is already listed in the recognized syntax such as
+obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild
+automatically adds it to $(targets). Otherwise, the target must be
+explicitly added to $(targets).
- $(src)
- $(src) is a relative path which points to the directory
- where the Makefile is located. Always use $(src) when
- referring to files located in the src tree.
+Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
+used in conjunction with custom rules as defined in `Custom Rules`_.
- $(obj)
- $(obj) is a relative path which points to the directory
- where the target is saved. Always use $(obj) when
- referring to generated files.
+Note: It is a typical mistake to forget the FORCE prerequisite.
+Another common pitfall is that whitespace is sometimes significant; for
+instance, the below will fail (note the extra space after the comma)::
- Example::
+ target: source(s) FORCE
- #drivers/scsi/Makefile
- $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
- $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
+**WRONG!** $(call if_changed, objcopy)
- This is a custom rule, following the normal syntax
- required by make.
+Note:
+ if_changed should not be used more than once per target.
+ It stores the executed command in a corresponding .cmd
+ file and multiple calls would result in overwrites and
+ unwanted results when the target is up to date and only the
+ tests on changed commands trigger execution of commands.
- The target file depends on two prerequisite files. References
- to the target file are prefixed with $(obj), references
- to prerequisites are referenced with $(src) (because they are not
- generated files).
+$(CC) support functions
+-----------------------
- $(kecho)
- echoing information to user in a rule is often a good practice
- but when execution "make -s" one does not expect to see any output
- except for warnings/errors.
- To support this kbuild defines $(kecho) which will echo out the
- text following $(kecho) to stdout except if "make -s" is used.
+The kernel may be built with several different versions of
+$(CC), each supporting a unique set of features and options.
+kbuild provides basic support to check for valid options for $(CC).
+$(CC) is usually the gcc compiler, but other alternatives are
+available.
- Example::
+as-option
+ as-option is used to check if $(CC) -- when used to compile
+ assembler (``*.S``) files -- supports the given option. An optional
+ second option may be specified if the first option is not supported.
- # arch/arm/Makefile
- $(BOOT_TARGETS): vmlinux
- $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
- @$(kecho) ' Kernel: $(boot)/$@ is ready'
+ Example::
- When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
- of a command is normally displayed.
- To enable this behaviour for custom commands kbuild requires
- two variables to be set::
+ #arch/sh/Makefile
+ cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
- quiet_cmd_<command> - what shall be echoed
- cmd_<command> - the command to execute
+ In the above example, cflags-y will be assigned the option
+ -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
+ The second argument is optional, and if supplied will be used
+ if first argument is not supported.
- Example::
+as-instr
+ as-instr checks if the assembler reports a specific instruction
+ and then outputs either option1 or option2
+ C escapes are supported in the test instruction
+ Note: as-instr-option uses KBUILD_AFLAGS for assembler options
- # lib/Makefile
- quiet_cmd_crc32 = GEN $@
- cmd_crc32 = $< > $@
+cc-option
+ cc-option is used to check if $(CC) supports a given option, and if
+ not supported to use an optional second option.
- $(obj)/crc32table.h: $(obj)/gen_crc32table
- $(call cmd,crc32)
+ Example::
- When updating the $(obj)/crc32table.h target, the line:
+ #arch/x86/Makefile
+ cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
- GEN lib/crc32table.h
+ In the above example, cflags-y will be assigned the option
+ -march=pentium-mmx if supported by $(CC), otherwise -march=i586.
+ The second argument to cc-option is optional, and if omitted,
+ cflags-y will be assigned no value if first option is not supported.
+ Note: cc-option uses KBUILD_CFLAGS for $(CC) options
- will be displayed with "make KBUILD_VERBOSE=0".
+cc-option-yn
+ cc-option-yn is used to check if $(CC) supports a given option
+ and return "y" if supported, otherwise "n".
-3.12 Command change detection
------------------------------
+ Example::
- When the rule is evaluated, timestamps are compared between the target
- and its prerequisite files. GNU Make updates the target when any of the
- prerequisites is newer than that.
+ #arch/ppc/Makefile
+ biarch := $(call cc-option-yn, -m32)
+ aflags-$(biarch) += -a32
+ cflags-$(biarch) += -m32
- The target should be rebuilt also when the command line has changed
- since the last invocation. This is not supported by Make itself, so
- Kbuild achieves this by a kind of meta-programming.
+ In the above example, $(biarch) is set to y if $(CC) supports the -m32
+ option. When $(biarch) equals "y", the expanded variables $(aflags-y)
+ and $(cflags-y) will be assigned the values -a32 and -m32,
+ respectively.
- if_changed is the macro used for this purpose, in the following form::
+ Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
- quiet_cmd_<command> = ...
- cmd_<command> = ...
+cc-disable-warning
+ cc-disable-warning checks if $(CC) supports a given warning and returns
+ the commandline switch to disable it. This special function is needed,
+ because gcc 4.4 and later accept any unknown -Wno-* option and only
+ warn about it if there is another warning in the source file.
- <target>: <source(s)> FORCE
- $(call if_changed,<command>)
+ Example::
- Any target that utilizes if_changed must be listed in $(targets),
- otherwise the command line check will fail, and the target will
- always be built.
+ KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
- If the target is already listed in the recognized syntax such as
- obj-y/m, lib-y/m, extra-y/m, always-y/m, hostprogs, userprogs, Kbuild
- automatically adds it to $(targets). Otherwise, the target must be
- explicitly added to $(targets).
+ In the above example, -Wno-unused-but-set-variable will be added to
+ KBUILD_CFLAGS only if $(CC) really accepts it.
- Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
- used in conjunction with custom rules as defined in "3.11 Custom Rules".
+gcc-min-version
+ gcc-min-version tests if the value of $(CONFIG_GCC_VERSION) is greater than
+ or equal to the provided value and evaluates to y if so.
- Note: It is a typical mistake to forget the FORCE prerequisite.
- Another common pitfall is that whitespace is sometimes significant; for
- instance, the below will fail (note the extra space after the comma)::
+ Example::
- target: source(s) FORCE
+ cflags-$(call gcc-min-version, 110100) := -foo
- **WRONG!** $(call if_changed, objcopy)
+ In this example, cflags-y will be assigned the value -foo if $(CC) is gcc and
+ $(CONFIG_GCC_VERSION) is >= 11.1.
- Note:
- if_changed should not be used more than once per target.
- It stores the executed command in a corresponding .cmd
- file and multiple calls would result in overwrites and
- unwanted results when the target is up to date and only the
- tests on changed commands trigger execution of commands.
+clang-min-version
+ clang-min-version tests if the value of $(CONFIG_CLANG_VERSION) is greater
+ than or equal to the provided value and evaluates to y if so.
-3.13 $(CC) support functions
-----------------------------
+ Example::
- The kernel may be built with several different versions of
- $(CC), each supporting a unique set of features and options.
- kbuild provides basic support to check for valid options for $(CC).
- $(CC) is usually the gcc compiler, but other alternatives are
- available.
-
- as-option
- as-option is used to check if $(CC) -- when used to compile
- assembler (`*.S`) files -- supports the given option. An optional
- second option may be specified if the first option is not supported.
-
- Example::
-
- #arch/sh/Makefile
- cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
-
- In the above example, cflags-y will be assigned the option
- -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
- The second argument is optional, and if supplied will be used
- if first argument is not supported.
-
- as-instr
- as-instr checks if the assembler reports a specific instruction
- and then outputs either option1 or option2
- C escapes are supported in the test instruction
- Note: as-instr-option uses KBUILD_AFLAGS for assembler options
-
- cc-option
- cc-option is used to check if $(CC) supports a given option, and if
- not supported to use an optional second option.
-
- Example::
-
- #arch/x86/Makefile
- cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
-
- In the above example, cflags-y will be assigned the option
- -march=pentium-mmx if supported by $(CC), otherwise -march=i586.
- The second argument to cc-option is optional, and if omitted,
- cflags-y will be assigned no value if first option is not supported.
- Note: cc-option uses KBUILD_CFLAGS for $(CC) options
-
- cc-option-yn
- cc-option-yn is used to check if gcc supports a given option
- and return 'y' if supported, otherwise 'n'.
-
- Example::
-
- #arch/ppc/Makefile
- biarch := $(call cc-option-yn, -m32)
- aflags-$(biarch) += -a32
- cflags-$(biarch) += -m32
-
- In the above example, $(biarch) is set to y if $(CC) supports the -m32
- option. When $(biarch) equals 'y', the expanded variables $(aflags-y)
- and $(cflags-y) will be assigned the values -a32 and -m32,
- respectively.
- Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
-
- cc-disable-warning
- cc-disable-warning checks if gcc supports a given warning and returns
- the commandline switch to disable it. This special function is needed,
- because gcc 4.4 and later accept any unknown -Wno-* option and only
- warn about it if there is another warning in the source file.
-
- Example::
-
- KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
-
- In the above example, -Wno-unused-but-set-variable will be added to
- KBUILD_CFLAGS only if gcc really accepts it.
-
- cc-ifversion
- cc-ifversion tests the version of $(CC) and equals the fourth parameter
- if version expression is true, or the fifth (if given) if the version
- expression is false.
-
- Example::
-
- #fs/reiserfs/Makefile
- ccflags-y := $(call cc-ifversion, -lt, 0402, -O1)
-
- In this example, ccflags-y will be assigned the value -O1 if the
- $(CC) version is less than 4.2.
- cc-ifversion takes all the shell operators:
- -eq, -ne, -lt, -le, -gt, and -ge
- The third parameter may be a text as in this example, but it may also
- be an expanded variable or a macro.
-
- cc-cross-prefix
- cc-cross-prefix is used to check if there exists a $(CC) in path with
- one of the listed prefixes. The first prefix where there exist a
- prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found
- then nothing is returned.
- Additional prefixes are separated by a single space in the
- call of cc-cross-prefix.
- This functionality is useful for architecture Makefiles that try
- to set CROSS_COMPILE to well-known values but may have several
- values to select between.
- It is recommended only to try to set CROSS_COMPILE if it is a cross
- build (host arch is different from target arch). And if CROSS_COMPILE
- is already set then leave it with the old value.
-
- Example::
-
- #arch/m68k/Makefile
- ifneq ($(SUBARCH),$(ARCH))
- ifeq ($(CROSS_COMPILE),)
- CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
- endif
- endif
-
-3.14 $(LD) support functions
-----------------------------
+ cflags-$(call clang-min-version, 110000) := -foo
- ld-option
- ld-option is used to check if $(LD) supports the supplied option.
- ld-option takes two options as arguments.
- The second argument is an optional option that can be used if the
- first option is not supported by $(LD).
+ In this example, cflags-y will be assigned the value -foo if $(CC) is clang
+ and $(CONFIG_CLANG_VERSION) is >= 11.0.0.
- Example::
+cc-cross-prefix
+ cc-cross-prefix is used to check if there exists a $(CC) in path with
+ one of the listed prefixes. The first prefix where there exist a
+ prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found
+ then nothing is returned.
- #Makefile
- LDFLAGS_vmlinux += $(call ld-option, -X)
+ Additional prefixes are separated by a single space in the
+ call of cc-cross-prefix.
-3.15 Script invocation
-----------------------
+ This functionality is useful for architecture Makefiles that try
+ to set CROSS_COMPILE to well-known values but may have several
+ values to select between.
- Make rules may invoke scripts to build the kernel. The rules shall
- always provide the appropriate interpreter to execute the script. They
- shall not rely on the execute bits being set, and shall not invoke the
- script directly. For the convenience of manual script invocation, such
- as invoking ./scripts/checkpatch.pl, it is recommended to set execute
- bits on the scripts nonetheless.
+ It is recommended only to try to set CROSS_COMPILE if it is a cross
+ build (host arch is different from target arch). And if CROSS_COMPILE
+ is already set then leave it with the old value.
- Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL),
- and $(PYTHON3) to refer to interpreters for the respective
- scripts.
+ Example::
- Example::
+ #arch/m68k/Makefile
+ ifneq ($(SUBARCH),$(ARCH))
+ ifeq ($(CROSS_COMPILE),)
+ CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-)
+ endif
+ endif
- #Makefile
- cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
- $(KERNELRELEASE)
+$(RUSTC) support functions
+--------------------------
-4 Host Program support
-======================
+rustc-min-version
+ rustc-min-version tests if the value of $(CONFIG_RUSTC_VERSION) is greater
+ than or equal to the provided value and evaluates to y if so.
+
+ Example::
+
+ rustflags-$(call rustc-min-version, 108500) := -Cfoo
+
+ In this example, rustflags-y will be assigned the value -Cfoo if
+ $(CONFIG_RUSTC_VERSION) is >= 1.85.0.
+
+$(LD) support functions
+-----------------------
+
+ld-option
+ ld-option is used to check if $(LD) supports the supplied option.
+ ld-option takes two options as arguments.
+
+ The second argument is an optional option that can be used if the
+ first option is not supported by $(LD).
+
+ Example::
+
+ #Makefile
+ LDFLAGS_vmlinux += $(call ld-option, -X)
+
+Script invocation
+-----------------
+
+Make rules may invoke scripts to build the kernel. The rules shall
+always provide the appropriate interpreter to execute the script. They
+shall not rely on the execute bits being set, and shall not invoke the
+script directly. For the convenience of manual script invocation, such
+as invoking ./scripts/checkpatch.pl, it is recommended to set execute
+bits on the scripts nonetheless.
+
+Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL),
+and $(PYTHON3) to refer to interpreters for the respective
+scripts.
+
+Example::
+
+ #Makefile
+ cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
+ $(KERNELRELEASE)
+
+Host Program support
+====================
Kbuild supports building executables on the host for use during the
compilation stage.
+
Two steps are required in order to use a host executable.
The first step is to tell kbuild that a host program exists. This is
-done utilising the variable "hostprogs".
+done utilising the variable ``hostprogs``.
The second step is to add an explicit dependency to the executable.
This can be done in two ways. Either add the dependency in a rule,
-or utilise the variable "always-y".
+or utilise the variable ``always-y``.
Both possibilities are described in the following.
-4.1 Simple Host Program
------------------------
+Simple Host Program
+-------------------
- In some cases there is a need to compile and run a program on the
- computer where the build is running.
- The following line tells kbuild that the program bin2hex shall be
- built on the build host.
+In some cases there is a need to compile and run a program on the
+computer where the build is running.
- Example::
+The following line tells kbuild that the program bin2hex shall be
+built on the build host.
- hostprogs := bin2hex
+Example::
- Kbuild assumes in the above example that bin2hex is made from a single
- c-source file named bin2hex.c located in the same directory as
- the Makefile.
+ hostprogs := bin2hex
-4.2 Composite Host Programs
----------------------------
+Kbuild assumes in the above example that bin2hex is made from a single
+c-source file named bin2hex.c located in the same directory as
+the Makefile.
- Host programs can be made up based on composite objects.
- The syntax used to define composite objects for host programs is
- similar to the syntax used for kernel objects.
- $(<executable>-objs) lists all objects used to link the final
- executable.
+Composite Host Programs
+-----------------------
- Example::
+Host programs can be made up based on composite objects.
+The syntax used to define composite objects for host programs is
+similar to the syntax used for kernel objects.
+$(<executable>-objs) lists all objects used to link the final
+executable.
- #scripts/lxdialog/Makefile
- hostprogs := lxdialog
- lxdialog-objs := checklist.o lxdialog.o
+Example::
- Objects with extension .o are compiled from the corresponding .c
- files. In the above example, checklist.c is compiled to checklist.o
- and lxdialog.c is compiled to lxdialog.o.
+ #scripts/lxdialog/Makefile
+ hostprogs := lxdialog
+ lxdialog-objs := checklist.o lxdialog.o
- Finally, the two .o files are linked to the executable, lxdialog.
- Note: The syntax <executable>-y is not permitted for host-programs.
+Objects with extension .o are compiled from the corresponding .c
+files. In the above example, checklist.c is compiled to checklist.o
+and lxdialog.c is compiled to lxdialog.o.
-4.3 Using C++ for host programs
--------------------------------
+Finally, the two .o files are linked to the executable, lxdialog.
+Note: The syntax <executable>-y is not permitted for host-programs.
- kbuild offers support for host programs written in C++. This was
- introduced solely to support kconfig, and is not recommended
- for general use.
+Using C++ for host programs
+---------------------------
- Example::
+kbuild offers support for host programs written in C++. This was
+introduced solely to support kconfig, and is not recommended
+for general use.
- #scripts/kconfig/Makefile
- hostprogs := qconf
- qconf-cxxobjs := qconf.o
+Example::
- In the example above the executable is composed of the C++ file
- qconf.cc - identified by $(qconf-cxxobjs).
+ #scripts/kconfig/Makefile
+ hostprogs := qconf
+ qconf-cxxobjs := qconf.o
- If qconf is composed of a mixture of .c and .cc files, then an
- additional line can be used to identify this.
+In the example above the executable is composed of the C++ file
+qconf.cc - identified by $(qconf-cxxobjs).
- Example::
+If qconf is composed of a mixture of .c and .cc files, then an
+additional line can be used to identify this.
- #scripts/kconfig/Makefile
- hostprogs := qconf
- qconf-cxxobjs := qconf.o
- qconf-objs := check.o
+Example::
-4.4 Using Rust for host programs
---------------------------------
+ #scripts/kconfig/Makefile
+ hostprogs := qconf
+ qconf-cxxobjs := qconf.o
+ qconf-objs := check.o
- Kbuild offers support for host programs written in Rust. However,
- since a Rust toolchain is not mandatory for kernel compilation,
- it may only be used in scenarios where Rust is required to be
- available (e.g. when ``CONFIG_RUST`` is enabled).
+Using Rust for host programs
+----------------------------
- Example::
+Kbuild offers support for host programs written in Rust. However,
+since a Rust toolchain is not mandatory for kernel compilation,
+it may only be used in scenarios where Rust is required to be
+available (e.g. when ``CONFIG_RUST`` is enabled).
- hostprogs := target
- target-rust := y
+Example::
- Kbuild will compile ``target`` using ``target.rs`` as the crate root,
- located in the same directory as the ``Makefile``. The crate may
- consist of several source files (see ``samples/rust/hostprogs``).
+ hostprogs := target
+ target-rust := y
-4.5 Controlling compiler options for host programs
---------------------------------------------------
+Kbuild will compile ``target`` using ``target.rs`` as the crate root,
+located in the same directory as the ``Makefile``. The crate may
+consist of several source files (see ``samples/rust/hostprogs``).
- When compiling host programs, it is possible to set specific flags.
- The programs will always be compiled utilising $(HOSTCC) passed
- the options specified in $(KBUILD_HOSTCFLAGS).
- To set flags that will take effect for all host programs created
- in that Makefile, use the variable HOST_EXTRACFLAGS.
+Controlling compiler options for host programs
+----------------------------------------------
- Example::
+When compiling host programs, it is possible to set specific flags.
+The programs will always be compiled utilising $(HOSTCC) passed
+the options specified in $(KBUILD_HOSTCFLAGS).
- #scripts/lxdialog/Makefile
- HOST_EXTRACFLAGS += -I/usr/include/ncurses
+To set flags that will take effect for all host programs created
+in that Makefile, use the variable HOST_EXTRACFLAGS.
- To set specific flags for a single file the following construction
- is used:
+Example::
- Example::
+ #scripts/lxdialog/Makefile
+ HOST_EXTRACFLAGS += -I/usr/include/ncurses
- #arch/ppc64/boot/Makefile
- HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
+To set specific flags for a single file the following construction
+is used:
- It is also possible to specify additional options to the linker.
+Example::
- Example::
+ #arch/ppc64/boot/Makefile
+ HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
- #scripts/kconfig/Makefile
- HOSTLDLIBS_qconf := -L$(QTDIR)/lib
+It is also possible to specify additional options to the linker.
- When linking qconf, it will be passed the extra option
- "-L$(QTDIR)/lib".
+Example::
-4.6 When host programs are actually built
------------------------------------------
+ #scripts/kconfig/Makefile
+ HOSTLDLIBS_qconf := -L$(QTDIR)/lib
- Kbuild will only build host-programs when they are referenced
- as a prerequisite.
- This is possible in two ways:
+When linking qconf, it will be passed the extra option
+``-L$(QTDIR)/lib``.
- (1) List the prerequisite explicitly in a custom rule.
+When host programs are actually built
+-------------------------------------
- Example::
+Kbuild will only build host-programs when they are referenced
+as a prerequisite.
- #drivers/pci/Makefile
- hostprogs := gen-devlist
- $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
- ( cd $(obj); ./gen-devlist ) < $<
+This is possible in two ways:
- The target $(obj)/devlist.h will not be built before
- $(obj)/gen-devlist is updated. Note that references to
- the host programs in custom rules must be prefixed with $(obj).
+(1) List the prerequisite explicitly in a custom rule.
- (2) Use always-y
+ Example::
- When there is no suitable custom rule, and the host program
- shall be built when a makefile is entered, the always-y
- variable shall be used.
+ #drivers/pci/Makefile
+ hostprogs := gen-devlist
+ $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
+ ( cd $(obj); ./gen-devlist ) < $<
- Example::
+ The target $(obj)/devlist.h will not be built before
+ $(obj)/gen-devlist is updated. Note that references to
+ the host programs in custom rules must be prefixed with $(obj).
- #scripts/lxdialog/Makefile
- hostprogs := lxdialog
- always-y := $(hostprogs)
+(2) Use always-y
- Kbuild provides the following shorthand for this:
+ When there is no suitable custom rule, and the host program
+ shall be built when a makefile is entered, the always-y
+ variable shall be used.
- hostprogs-always-y := lxdialog
+ Example::
- This will tell kbuild to build lxdialog even if not referenced in
- any rule.
+ #scripts/lxdialog/Makefile
+ hostprogs := lxdialog
+ always-y := $(hostprogs)
-5 Userspace Program support
-===========================
+ Kbuild provides the following shorthand for this::
+
+ hostprogs-always-y := lxdialog
+
+ This will tell kbuild to build lxdialog even if not referenced in
+ any rule.
+
+Userspace Program support
+=========================
Just like host programs, Kbuild also supports building userspace executables
for the target architecture (i.e. the same architecture as you are building
the kernel for).
-The syntax is quite similar. The difference is to use "userprogs" instead of
-"hostprogs".
+The syntax is quite similar. The difference is to use ``userprogs`` instead of
+``hostprogs``.
-5.1 Simple Userspace Program
-----------------------------
+Simple Userspace Program
+------------------------
- The following line tells kbuild that the program bpf-direct shall be
- built for the target architecture.
+The following line tells kbuild that the program bpf-direct shall be
+built for the target architecture.
- Example::
+Example::
- userprogs := bpf-direct
+ userprogs := bpf-direct
- Kbuild assumes in the above example that bpf-direct is made from a
- single C source file named bpf-direct.c located in the same directory
- as the Makefile.
+Kbuild assumes in the above example that bpf-direct is made from a
+single C source file named bpf-direct.c located in the same directory
+as the Makefile.
-5.2 Composite Userspace Programs
---------------------------------
+Composite Userspace Programs
+----------------------------
- Userspace programs can be made up based on composite objects.
- The syntax used to define composite objects for userspace programs is
- similar to the syntax used for kernel objects.
- $(<executable>-objs) lists all objects used to link the final
- executable.
+Userspace programs can be made up based on composite objects.
+The syntax used to define composite objects for userspace programs is
+similar to the syntax used for kernel objects.
+$(<executable>-objs) lists all objects used to link the final
+executable.
- Example::
+Example::
- #samples/seccomp/Makefile
- userprogs := bpf-fancy
- bpf-fancy-objs := bpf-fancy.o bpf-helper.o
+ #samples/seccomp/Makefile
+ userprogs := bpf-fancy
+ bpf-fancy-objs := bpf-fancy.o bpf-helper.o
- Objects with extension .o are compiled from the corresponding .c
- files. In the above example, bpf-fancy.c is compiled to bpf-fancy.o
- and bpf-helper.c is compiled to bpf-helper.o.
+Objects with extension .o are compiled from the corresponding .c
+files. In the above example, bpf-fancy.c is compiled to bpf-fancy.o
+and bpf-helper.c is compiled to bpf-helper.o.
- Finally, the two .o files are linked to the executable, bpf-fancy.
- Note: The syntax <executable>-y is not permitted for userspace programs.
+Finally, the two .o files are linked to the executable, bpf-fancy.
+Note: The syntax <executable>-y is not permitted for userspace programs.
-5.3 Controlling compiler options for userspace programs
--------------------------------------------------------
+Controlling compiler options for userspace programs
+---------------------------------------------------
- When compiling userspace programs, it is possible to set specific flags.
- The programs will always be compiled utilising $(CC) passed
- the options specified in $(KBUILD_USERCFLAGS).
- To set flags that will take effect for all userspace programs created
- in that Makefile, use the variable userccflags.
+When compiling userspace programs, it is possible to set specific flags.
+The programs will always be compiled utilising $(CC) passed
+the options specified in $(KBUILD_USERCFLAGS).
- Example::
+To set flags that will take effect for all userspace programs created
+in that Makefile, use the variable userccflags.
- # samples/seccomp/Makefile
- userccflags += -I usr/include
+Example::
- To set specific flags for a single file the following construction
- is used:
+ # samples/seccomp/Makefile
+ userccflags += -I usr/include
- Example::
+To set specific flags for a single file the following construction
+is used:
- bpf-helper-userccflags += -I user/include
+Example::
- It is also possible to specify additional options to the linker.
+ bpf-helper-userccflags += -I user/include
- Example::
+It is also possible to specify additional options to the linker.
- # net/bpfilter/Makefile
- bpfilter_umh-userldflags += -static
+Example::
- When linking bpfilter_umh, it will be passed the extra option -static.
+ # net/bpfilter/Makefile
+ bpfilter_umh-userldflags += -static
- From command line, :ref:`USERCFLAGS and USERLDFLAGS <userkbuildflags>` will also be used.
+To specify libraries linked to a userspace program, you can use
+``<executable>-userldlibs``. The ``userldlibs`` syntax specifies libraries
+linked to all userspace programs created in the current Makefile.
-5.4 When userspace programs are actually built
-----------------------------------------------
+When linking bpfilter_umh, it will be passed the extra option -static.
+
+From command line, :ref:`USERCFLAGS and USERLDFLAGS <userkbuildflags>` will also be used.
- Kbuild builds userspace programs only when told to do so.
- There are two ways to do this.
+When userspace programs are actually built
+------------------------------------------
- (1) Add it as the prerequisite of another file
+Kbuild builds userspace programs only when told to do so.
+There are two ways to do this.
- Example::
+(1) Add it as the prerequisite of another file
- #net/bpfilter/Makefile
- userprogs := bpfilter_umh
- $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
+ Example::
- $(obj)/bpfilter_umh is built before $(obj)/bpfilter_umh_blob.o
+ #net/bpfilter/Makefile
+ userprogs := bpfilter_umh
+ $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
- (2) Use always-y
+ $(obj)/bpfilter_umh is built before $(obj)/bpfilter_umh_blob.o
- Example::
+(2) Use always-y
- userprogs := binderfs_example
- always-y := $(userprogs)
+ Example::
- Kbuild provides the following shorthand for this:
+ userprogs := binderfs_example
+ always-y := $(userprogs)
- userprogs-always-y := binderfs_example
+ Kbuild provides the following shorthand for this::
- This will tell Kbuild to build binderfs_example when it visits this
- Makefile.
+ userprogs-always-y := binderfs_example
-6 Kbuild clean infrastructure
-=============================
+ This will tell Kbuild to build binderfs_example when it visits this
+ Makefile.
+
+Kbuild clean infrastructure
+===========================
-"make clean" deletes most generated files in the obj tree where the kernel
+``make clean`` deletes most generated files in the obj tree where the kernel
is compiled. This includes generated files such as host programs.
Kbuild knows targets listed in $(hostprogs), $(always-y), $(always-m),
$(always-), $(extra-y), $(extra-) and $(targets). They are all deleted
-during "make clean". Files matching the patterns "*.[oas]", "*.ko", plus
+during ``make clean``. Files matching the patterns ``*.[oas]``, ``*.ko``, plus
some additional files generated by kbuild are deleted all over the kernel
-source tree when "make clean" is executed.
+source tree when ``make clean`` is executed.
Additional files or directories can be specified in kbuild makefiles by use of
$(clean-files).
- Example::
+Example::
- #lib/Makefile
- clean-files := crc32table.h
+ #lib/Makefile
+ clean-files := crc32table.h
-When executing "make clean", the file "crc32table.h" will be deleted.
+When executing ``make clean``, the file ``crc32table.h`` will be deleted.
Kbuild will assume files to be in the same relative directory as the
-Makefile, except if prefixed with $(objtree).
+Makefile.
To exclude certain files or directories from make clean, use the
$(no-clean-files) variable.
-Usually kbuild descends down in subdirectories due to "obj-* := dir/",
+Usually kbuild descends down in subdirectories due to ``obj-* := dir/``,
but in the architecture makefiles where the kbuild infrastructure
is not sufficient this sometimes needs to be explicit.
- Example::
+Example::
- #arch/x86/boot/Makefile
- subdir- := compressed
+ #arch/x86/boot/Makefile
+ subdir- := compressed
The above assignment instructs kbuild to descend down in the
-directory compressed/ when "make clean" is executed.
+directory compressed/ when ``make clean`` is executed.
-Note 1: arch/$(SRCARCH)/Makefile cannot use "subdir-", because that file is
+Note 1: arch/$(SRCARCH)/Makefile cannot use ``subdir-``, because that file is
included in the top level makefile. Instead, arch/$(SRCARCH)/Kbuild can use
-"subdir-".
+``subdir-``.
Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will
-be visited during "make clean".
+be visited during ``make clean``.
-7 Architecture Makefiles
-========================
+Architecture Makefiles
+======================
The top level Makefile sets up the environment and does the preparation,
before starting to descend down in the individual directories.
+
The top level makefile contains the generic part, whereas
arch/$(SRCARCH)/Makefile contains what is required to set up kbuild
for said architecture.
+
To do so, arch/$(SRCARCH)/Makefile sets up a number of variables and defines
a few targets.
When kbuild executes, the following steps are followed (roughly):
1) Configuration of the kernel => produce .config
+
2) Store kernel version in include/linux/version.h
+
3) Updating all other prerequisites to the target prepare:
+
- Additional prerequisites are specified in arch/$(SRCARCH)/Makefile
+
4) Recursively descend down in all directories listed in
init-* core* drivers-* net-* libs-* and build all targets.
+
- The values of the above variables are expanded in arch/$(SRCARCH)/Makefile.
+
5) All object files are then linked and the resulting file vmlinux is
located at the root of the obj tree.
- The very first objects linked are listed in head-y, assigned by
- arch/$(SRCARCH)/Makefile.
+ The very first objects linked are listed in scripts/head-object-list.txt.
+
6) Finally, the architecture-specific part does any required post processing
and builds the final bootimage.
+
- This includes building boot records
- Preparing initrd images and the like
+Set variables to tweak the build to the architecture
+----------------------------------------------------
+
+KBUILD_LDFLAGS
+ Generic $(LD) options
+
+ Flags used for all invocations of the linker.
+ Often specifying the emulation is sufficient.
-7.1 Set variables to tweak the build to the architecture
---------------------------------------------------------
+ Example::
- KBUILD_LDFLAGS
- Generic $(LD) options
+ #arch/s390/Makefile
+ KBUILD_LDFLAGS := -m elf_s390
- Flags used for all invocations of the linker.
- Often specifying the emulation is sufficient.
+ Note: ldflags-y can be used to further customise
+ the flags used. See `Non-builtin vmlinux targets - extra-y`_.
- Example::
+LDFLAGS_vmlinux
+ Options for $(LD) when linking vmlinux
- #arch/s390/Makefile
- KBUILD_LDFLAGS := -m elf_s390
+ LDFLAGS_vmlinux is used to specify additional flags to pass to
+ the linker when linking the final vmlinux image.
- Note: ldflags-y can be used to further customise
- the flags used. See section 3.7.
+ LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
- LDFLAGS_vmlinux
- Options for $(LD) when linking vmlinux
+ Example::
- LDFLAGS_vmlinux is used to specify additional flags to pass to
- the linker when linking the final vmlinux image.
- LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
+ #arch/x86/Makefile
+ LDFLAGS_vmlinux := -e stext
- Example::
+OBJCOPYFLAGS
+ objcopy flags
- #arch/x86/Makefile
- LDFLAGS_vmlinux := -e stext
+ When $(call if_changed,objcopy) is used to translate a .o file,
+ the flags specified in OBJCOPYFLAGS will be used.
- OBJCOPYFLAGS
- objcopy flags
+ $(call if_changed,objcopy) is often used to generate raw binaries on
+ vmlinux.
- When $(call if_changed,objcopy) is used to translate a .o file,
- the flags specified in OBJCOPYFLAGS will be used.
- $(call if_changed,objcopy) is often used to generate raw binaries on
- vmlinux.
+ Example::
- Example::
+ #arch/s390/Makefile
+ OBJCOPYFLAGS := -O binary
- #arch/s390/Makefile
- OBJCOPYFLAGS := -O binary
+ #arch/s390/boot/Makefile
+ $(obj)/image: vmlinux FORCE
+ $(call if_changed,objcopy)
- #arch/s390/boot/Makefile
- $(obj)/image: vmlinux FORCE
- $(call if_changed,objcopy)
+ In this example, the binary $(obj)/image is a binary version of
+ vmlinux. The usage of $(call if_changed,xxx) will be described later.
- In this example, the binary $(obj)/image is a binary version of
- vmlinux. The usage of $(call if_changed,xxx) will be described later.
+KBUILD_AFLAGS
+ Assembler flags
- KBUILD_AFLAGS
- Assembler flags
+ Default value - see top level Makefile.
- Default value - see top level Makefile
- Append or modify as required per architecture.
+ Append or modify as required per architecture.
- Example::
+ Example::
- #arch/sparc64/Makefile
- KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
+ #arch/sparc64/Makefile
+ KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
- KBUILD_CFLAGS
- $(CC) compiler flags
+KBUILD_CFLAGS
+ $(CC) compiler flags
- Default value - see top level Makefile
- Append or modify as required per architecture.
+ Default value - see top level Makefile.
- Often, the KBUILD_CFLAGS variable depends on the configuration.
+ Append or modify as required per architecture.
- Example::
+ Often, the KBUILD_CFLAGS variable depends on the configuration.
- #arch/x86/boot/compressed/Makefile
- cflags-$(CONFIG_X86_32) := -march=i386
- cflags-$(CONFIG_X86_64) := -mcmodel=small
- KBUILD_CFLAGS += $(cflags-y)
+ Example::
- Many arch Makefiles dynamically run the target C compiler to
- probe supported options::
+ #arch/x86/boot/compressed/Makefile
+ cflags-$(CONFIG_X86_32) := -march=i386
+ cflags-$(CONFIG_X86_64) := -mcmodel=small
+ KBUILD_CFLAGS += $(cflags-y)
- #arch/x86/Makefile
+ Many arch Makefiles dynamically run the target C compiler to
+ probe supported options::
- ...
- cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
+ #arch/x86/Makefile
+
+ ...
+ cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
-march=pentium2,-march=i686)
- ...
- # Disable unit-at-a-time mode ...
- KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time)
- ...
+ ...
+ # Disable unit-at-a-time mode ...
+ KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time)
+ ...
+
+
+ The first example utilises the trick that a config option expands
+ to "y" when selected.
+
+KBUILD_RUSTFLAGS
+ $(RUSTC) compiler flags
+ Default value - see top level Makefile.
- The first example utilises the trick that a config option expands
- to 'y' when selected.
+ Append or modify as required per architecture.
- KBUILD_RUSTFLAGS
- $(RUSTC) compiler flags
+ Often, the KBUILD_RUSTFLAGS variable depends on the configuration.
- Default value - see top level Makefile
- Append or modify as required per architecture.
+ Note that target specification file generation (for ``--target``)
+ is handled in ``scripts/generate_rust_target.rs``.
- Often, the KBUILD_RUSTFLAGS variable depends on the configuration.
+KBUILD_AFLAGS_KERNEL
+ Assembler options specific for built-in
- Note that target specification file generation (for ``--target``)
- is handled in ``scripts/generate_rust_target.rs``.
+ $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
+ resident kernel code.
- KBUILD_AFLAGS_KERNEL
- Assembler options specific for built-in
+KBUILD_AFLAGS_MODULE
+ Assembler options specific for modules
- $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
- resident kernel code.
+ $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
+ are used for assembler.
- KBUILD_AFLAGS_MODULE
- Assembler options specific for modules
+ From commandline AFLAGS_MODULE shall be used (see kbuild.rst).
- $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that
- are used for assembler.
+KBUILD_CFLAGS_KERNEL
+ $(CC) options specific for built-in
- From commandline AFLAGS_MODULE shall be used (see kbuild.rst).
+ $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
+ resident kernel code.
- KBUILD_CFLAGS_KERNEL
- $(CC) options specific for built-in
+KBUILD_CFLAGS_MODULE
+ Options for $(CC) when building modules
- $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
- resident kernel code.
+ $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that
+ are used for $(CC).
- KBUILD_CFLAGS_MODULE
- Options for $(CC) when building modules
+ From commandline CFLAGS_MODULE shall be used (see kbuild.rst).
- $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that
- are used for $(CC).
- From commandline CFLAGS_MODULE shall be used (see kbuild.rst).
+KBUILD_RUSTFLAGS_KERNEL
+ $(RUSTC) options specific for built-in
- KBUILD_RUSTFLAGS_KERNEL
- $(RUSTC) options specific for built-in
+ $(KBUILD_RUSTFLAGS_KERNEL) contains extra Rust compiler flags used to
+ compile resident kernel code.
- $(KBUILD_RUSTFLAGS_KERNEL) contains extra Rust compiler flags used to
- compile resident kernel code.
+KBUILD_RUSTFLAGS_MODULE
+ Options for $(RUSTC) when building modules
- KBUILD_RUSTFLAGS_MODULE
- Options for $(RUSTC) when building modules
+ $(KBUILD_RUSTFLAGS_MODULE) is used to add arch-specific options that
+ are used for $(RUSTC).
- $(KBUILD_RUSTFLAGS_MODULE) is used to add arch-specific options that
- are used for $(RUSTC).
- From commandline RUSTFLAGS_MODULE shall be used (see kbuild.rst).
+ From commandline RUSTFLAGS_MODULE shall be used (see kbuild.rst).
- KBUILD_LDFLAGS_MODULE
- Options for $(LD) when linking modules
+KBUILD_LDFLAGS_MODULE
+ Options for $(LD) when linking modules
- $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
- used when linking modules. This is often a linker script.
+ $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
+ used when linking modules. This is often a linker script.
- From commandline LDFLAGS_MODULE shall be used (see kbuild.rst).
+ From commandline LDFLAGS_MODULE shall be used (see kbuild.rst).
- KBUILD_LDS
+KBUILD_LDS
+ The linker script with full path. Assigned by the top-level Makefile.
- The linker script with full path. Assigned by the top-level Makefile.
+KBUILD_VMLINUX_OBJS
+ All object files for vmlinux. They are linked to vmlinux in the same
+ order as listed in KBUILD_VMLINUX_OBJS.
- KBUILD_LDS_MODULE
+ The objects listed in scripts/head-object-list.txt are exceptions;
+ they are placed before the other objects.
- The module linker script with full path. Assigned by the top-level
- Makefile and additionally by the arch Makefile.
+KBUILD_VMLINUX_LIBS
+ All .a ``lib`` files for vmlinux. KBUILD_VMLINUX_OBJS and
+ KBUILD_VMLINUX_LIBS together specify all the object files used to
+ link vmlinux.
- KBUILD_VMLINUX_OBJS
+Add prerequisites to archheaders
+--------------------------------
- All object files for vmlinux. They are linked to vmlinux in the same
- order as listed in KBUILD_VMLINUX_OBJS.
+The archheaders: rule is used to generate header files that
+may be installed into user space by ``make header_install``.
- KBUILD_VMLINUX_LIBS
+It is run before ``make archprepare`` when run on the
+architecture itself.
- All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and
- KBUILD_VMLINUX_LIBS together specify all the object files used to
- link vmlinux.
+Add prerequisites to archprepare
+--------------------------------
-7.2 Add prerequisites to archheaders
-------------------------------------
+The archprepare: rule is used to list prerequisites that need to be
+built before starting to descend down in the subdirectories.
- The archheaders: rule is used to generate header files that
- may be installed into user space by "make header_install".
+This is usually used for header files containing assembler constants.
- It is run before "make archprepare" when run on the
- architecture itself.
+Example::
+ #arch/arm/Makefile
+ archprepare: maketools
-7.3 Add prerequisites to archprepare
-------------------------------------
+In this example, the file target maketools will be processed
+before descending down in the subdirectories.
- The archprepare: rule is used to list prerequisites that need to be
- built before starting to descend down in the subdirectories.
- This is usually used for header files containing assembler constants.
+See also chapter XXX-TODO that describes how kbuild supports
+generating offset header files.
- Example::
+List directories to visit when descending
+-----------------------------------------
- #arch/arm/Makefile
- archprepare: maketools
+An arch Makefile cooperates with the top Makefile to define variables
+which specify how to build the vmlinux file. Note that there is no
+corresponding arch-specific section for modules; the module-building
+machinery is all architecture-independent.
- In this example, the file target maketools will be processed
- before descending down in the subdirectories.
- See also chapter XXX-TODO that describes how kbuild supports
- generating offset header files.
+core-y, libs-y, drivers-y
+ $(libs-y) lists directories where a lib.a archive can be located.
+ The rest list directories where a built-in.a object file can be
+ located.
-7.4 List directories to visit when descending
----------------------------------------------
+ Then the rest follows in this order:
- An arch Makefile cooperates with the top Makefile to define variables
- which specify how to build the vmlinux file. Note that there is no
- corresponding arch-specific section for modules; the module-building
- machinery is all architecture-independent.
+ $(core-y), $(libs-y), $(drivers-y)
+ The top level Makefile defines values for all generic directories,
+ and arch/$(SRCARCH)/Makefile only adds architecture-specific
+ directories.
- head-y, core-y, libs-y, drivers-y
- $(head-y) lists objects to be linked first in vmlinux.
+ Example::
- $(libs-y) lists directories where a lib.a archive can be located.
+ # arch/sparc/Makefile
+ core-y += arch/sparc/
- The rest list directories where a built-in.a object file can be
- located.
+ libs-y += arch/sparc/prom/
+ libs-y += arch/sparc/lib/
- Then the rest follows in this order:
+ drivers-$(CONFIG_PM) += arch/sparc/power/
- $(core-y), $(libs-y), $(drivers-y)
+Architecture-specific boot images
+---------------------------------
- The top level Makefile defines values for all generic directories,
- and arch/$(SRCARCH)/Makefile only adds architecture-specific
- directories.
+An arch Makefile specifies goals that take the vmlinux file, compress
+it, wrap it in bootstrapping code, and copy the resulting files
+somewhere. This includes various kinds of installation commands.
+The actual goals are not standardized across architectures.
- Example::
+It is common to locate any additional processing in a boot/
+directory below arch/$(SRCARCH)/.
- # arch/sparc/Makefile
- core-y += arch/sparc/
+Kbuild does not provide any smart way to support building a
+target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall
+call make manually to build a target in boot/.
- libs-y += arch/sparc/prom/
- libs-y += arch/sparc/lib/
+The recommended approach is to include shortcuts in
+arch/$(SRCARCH)/Makefile, and use the full path when calling down
+into the arch/$(SRCARCH)/boot/Makefile.
- drivers-$(CONFIG_PM) += arch/sparc/power/
+Example::
-7.5 Architecture-specific boot images
--------------------------------------
+ #arch/x86/Makefile
+ boot := arch/x86/boot
+ bzImage: vmlinux
+ $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
- An arch Makefile specifies goals that take the vmlinux file, compress
- it, wrap it in bootstrapping code, and copy the resulting files
- somewhere. This includes various kinds of installation commands.
- The actual goals are not standardized across architectures.
+``$(Q)$(MAKE) $(build)=<dir>`` is the recommended way to invoke
+make in a subdirectory.
- It is common to locate any additional processing in a boot/
- directory below arch/$(SRCARCH)/.
+There are no rules for naming architecture-specific targets,
+but executing ``make help`` will list all relevant targets.
+To support this, $(archhelp) must be defined.
- Kbuild does not provide any smart way to support building a
- target specified in boot/. Therefore arch/$(SRCARCH)/Makefile shall
- call make manually to build a target in boot/.
+Example::
- The recommended approach is to include shortcuts in
- arch/$(SRCARCH)/Makefile, and use the full path when calling down
- into the arch/$(SRCARCH)/boot/Makefile.
+ #arch/x86/Makefile
+ define archhelp
+ echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
+ endif
- Example::
+When make is executed without arguments, the first goal encountered
+will be built. In the top level Makefile the first goal present
+is all:.
- #arch/x86/Makefile
- boot := arch/x86/boot
- bzImage: vmlinux
- $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+An architecture shall always, per default, build a bootable image.
+In ``make help``, the default goal is highlighted with a ``*``.
- "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke
- make in a subdirectory.
+Add a new prerequisite to all: to select a default goal different
+from vmlinux.
- There are no rules for naming architecture-specific targets,
- but executing "make help" will list all relevant targets.
- To support this, $(archhelp) must be defined.
+Example::
- Example::
+ #arch/x86/Makefile
+ all: bzImage
- #arch/x86/Makefile
- define archhelp
- echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)'
- endif
+When ``make`` is executed without arguments, bzImage will be built.
- When make is executed without arguments, the first goal encountered
- will be built. In the top level Makefile the first goal present
- is all:.
- An architecture shall always, per default, build a bootable image.
- In "make help", the default goal is highlighted with a '*'.
- Add a new prerequisite to all: to select a default goal different
- from vmlinux.
+Commands useful for building a boot image
+-----------------------------------------
- Example::
+Kbuild provides a few macros that are useful when building a
+boot image.
- #arch/x86/Makefile
- all: bzImage
+ld
+ Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
- When "make" is executed without arguments, bzImage will be built.
+ Example::
-7.7 Commands useful for building a boot image
----------------------------------------------
+ #arch/x86/boot/Makefile
+ LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
+ LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
- Kbuild provides a few macros that are useful when building a
- boot image.
+ targets += setup setup.o bootsect bootsect.o
+ $(obj)/setup $(obj)/bootsect: %: %.o FORCE
+ $(call if_changed,ld)
- ld
- Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
+ In this example, there are two possible targets, requiring different
+ options to the linker. The linker options are specified using the
+ LDFLAGS_$@ syntax - one for each potential target.
- Example::
+ $(targets) are assigned all potential targets, by which kbuild knows
+ the targets and will:
- #arch/x86/boot/Makefile
- LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
- LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
+ 1) check for commandline changes
+ 2) delete target during make clean
- targets += setup setup.o bootsect bootsect.o
- $(obj)/setup $(obj)/bootsect: %: %.o FORCE
- $(call if_changed,ld)
+ The ``: %: %.o`` part of the prerequisite is a shorthand that
+ frees us from listing the setup.o and bootsect.o files.
- In this example, there are two possible targets, requiring different
- options to the linker. The linker options are specified using the
- LDFLAGS_$@ syntax - one for each potential target.
- $(targets) are assigned all potential targets, by which kbuild knows
- the targets and will:
+ Note:
+ It is a common mistake to forget the ``targets :=`` assignment,
+ resulting in the target file being recompiled for no
+ obvious reason.
- 1) check for commandline changes
- 2) delete target during make clean
+objcopy
+ Copy binary. Uses OBJCOPYFLAGS usually specified in
+ arch/$(SRCARCH)/Makefile.
- The ": %: %.o" part of the prerequisite is a shorthand that
- frees us from listing the setup.o and bootsect.o files.
+ OBJCOPYFLAGS_$@ may be used to set additional options.
- Note:
- It is a common mistake to forget the "targets :=" assignment,
- resulting in the target file being recompiled for no
- obvious reason.
+gzip
+ Compress target. Use maximum compression to compress target.
- objcopy
- Copy binary. Uses OBJCOPYFLAGS usually specified in
- arch/$(SRCARCH)/Makefile.
- OBJCOPYFLAGS_$@ may be used to set additional options.
+ Example::
- gzip
- Compress target. Use maximum compression to compress target.
+ #arch/x86/boot/compressed/Makefile
+ $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
+ $(call if_changed,gzip)
- Example::
+dtc
+ Create flattened device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
- #arch/x86/boot/compressed/Makefile
- $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
- $(call if_changed,gzip)
+ To use this command, simply add ``*.dtb`` into obj-y or targets, or make
+ some other target depend on ``%.dtb``
- dtc
- Create flattened device tree blob object suitable for linking
- into vmlinux. Device tree blobs linked into vmlinux are placed
- in an init section in the image. Platform code *must* copy the
- blob to non-init memory prior to calling unflatten_device_tree().
+ A central rule exists to create ``$(obj)/%.dtb`` from ``$(src)/%.dts``;
+ architecture Makefiles do no need to explicitly write out that rule.
- To use this command, simply add `*.dtb` into obj-y or targets, or make
- some other target depend on `%.dtb`
+ Example::
- A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`;
- architecture Makefiles do no need to explicitly write out that rule.
+ targets += $(dtb-y)
+ DTC_FLAGS ?= -p 1024
- Example::
+Preprocessing linker scripts
+----------------------------
- targets += $(dtb-y)
- DTC_FLAGS ?= -p 1024
+When the vmlinux image is built, the linker script
+arch/$(SRCARCH)/kernel/vmlinux.lds is used.
-7.9 Preprocessing linker scripts
---------------------------------
+The script is a preprocessed variant of the file vmlinux.lds.S
+located in the same directory.
- When the vmlinux image is built, the linker script
- arch/$(SRCARCH)/kernel/vmlinux.lds is used.
- The script is a preprocessed variant of the file vmlinux.lds.S
- located in the same directory.
- kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`.
+kbuild knows .lds files and includes a rule ``*lds.S`` -> ``*lds``.
- Example::
+Example::
- #arch/x86/kernel/Makefile
- extra-y := vmlinux.lds
+ #arch/x86/kernel/Makefile
+ extra-y := vmlinux.lds
- The assignment to extra-y is used to tell kbuild to build the
- target vmlinux.lds.
- The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
- specified options when building the target vmlinux.lds.
+The assignment to extra-y is used to tell kbuild to build the
+target vmlinux.lds.
- When building the `*.lds` target, kbuild uses the variables::
+The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
+specified options when building the target vmlinux.lds.
- KBUILD_CPPFLAGS : Set in top-level Makefile
- cppflags-y : May be set in the kbuild makefile
- CPPFLAGS_$(@F) : Target-specific flags.
- Note that the full filename is used in this
- assignment.
+When building the ``*.lds`` target, kbuild uses the variables::
- The kbuild infrastructure for `*lds` files is used in several
- architecture-specific files.
+ KBUILD_CPPFLAGS : Set in top-level Makefile
+ cppflags-y : May be set in the kbuild makefile
+ CPPFLAGS_$(@F) : Target-specific flags.
+ Note that the full filename is used in this
+ assignment.
-7.10 Generic header files
--------------------------
+The kbuild infrastructure for ``*lds`` files is used in several
+architecture-specific files.
- The directory include/asm-generic contains the header files
- that may be shared between individual architectures.
- The recommended approach how to use a generic header file is
- to list the file in the Kbuild file.
- See "8.2 generic-y" for further info on syntax etc.
+Generic header files
+--------------------
-7.11 Post-link pass
--------------------
+The directory include/asm-generic contains the header files
+that may be shared between individual architectures.
+
+The recommended approach how to use a generic header file is
+to list the file in the Kbuild file.
+
+See `generic-y`_ for further info on syntax etc.
+
+Post-link pass
+--------------
- If the file arch/xxx/Makefile.postlink exists, this makefile
- will be invoked for post-link objects (vmlinux and modules.ko)
- for architectures to run post-link passes on. Must also handle
- the clean target.
+If the file arch/xxx/Makefile.postlink exists, this makefile
+will be invoked for post-link objects (vmlinux and modules.ko)
+for architectures to run post-link passes on. Must also handle
+the clean target.
- This pass runs after kallsyms generation. If the architecture
- needs to modify symbol locations, rather than manipulate the
- kallsyms, it may be easier to add another postlink target for
- .tmp_vmlinux? targets to be called from link-vmlinux.sh.
+This pass runs after kallsyms generation. If the architecture
+needs to modify symbol locations, rather than manipulate the
+kallsyms, it may be easier to add another postlink target for
+.tmp_vmlinux? targets to be called from link-vmlinux.sh.
- For example, powerpc uses this to check relocation sanity of
- the linked vmlinux file.
+For example, powerpc uses this to check relocation sanity of
+the linked vmlinux file.
-8 Kbuild syntax for exported headers
-------------------------------------
+Kbuild syntax for exported headers
+==================================
The kernel includes a set of headers that is exported to userspace.
Many headers can be exported as-is but other headers require a
minimal pre-processing before they are ready for user-space.
+
The pre-processing does:
- drop kernel-specific annotations
- drop include of compiler.h
-- drop all sections that are kernel internal (guarded by `ifdef __KERNEL__`)
+- drop all sections that are kernel internal (guarded by ``ifdef __KERNEL__``)
All headers under include/uapi/, include/generated/uapi/,
arch/<arch>/include/uapi/ and arch/<arch>/include/generated/uapi/
@@ -1536,139 +1525,146 @@ are exported.
A Kbuild file may be defined under arch/<arch>/include/uapi/asm/ and
arch/<arch>/include/asm/ to list asm files coming from asm-generic.
+
See subsequent chapter for the syntax of the Kbuild file.
-8.1 no-export-headers
----------------------
+no-export-headers
+-----------------
- no-export-headers is essentially used by include/uapi/linux/Kbuild to
- avoid exporting specific headers (e.g. kvm.h) on architectures that do
- not support it. It should be avoided as much as possible.
+no-export-headers is essentially used by include/uapi/linux/Kbuild to
+avoid exporting specific headers (e.g. kvm.h) on architectures that do
+not support it. It should be avoided as much as possible.
-8.2 generic-y
--------------
+generic-y
+---------
- If an architecture uses a verbatim copy of a header from
- include/asm-generic then this is listed in the file
- arch/$(SRCARCH)/include/asm/Kbuild like this:
+If an architecture uses a verbatim copy of a header from
+include/asm-generic then this is listed in the file
+arch/$(SRCARCH)/include/asm/Kbuild like this:
- Example::
+Example::
- #arch/x86/include/asm/Kbuild
- generic-y += termios.h
- generic-y += rtc.h
+ #arch/x86/include/asm/Kbuild
+ generic-y += termios.h
+ generic-y += rtc.h
- During the prepare phase of the build a wrapper include
- file is generated in the directory::
+During the prepare phase of the build a wrapper include
+file is generated in the directory::
- arch/$(SRCARCH)/include/generated/asm
+ arch/$(SRCARCH)/include/generated/asm
- When a header is exported where the architecture uses
- the generic header a similar wrapper is generated as part
- of the set of exported headers in the directory::
+When a header is exported where the architecture uses
+the generic header a similar wrapper is generated as part
+of the set of exported headers in the directory::
- usr/include/asm
+ usr/include/asm
- The generated wrapper will in both cases look like the following:
+The generated wrapper will in both cases look like the following:
- Example: termios.h::
+Example: termios.h::
- #include <asm-generic/termios.h>
+ #include <asm-generic/termios.h>
-8.3 generated-y
----------------
+generated-y
+-----------
- If an architecture generates other header files alongside generic-y
- wrappers, generated-y specifies them.
+If an architecture generates other header files alongside generic-y
+wrappers, generated-y specifies them.
- This prevents them being treated as stale asm-generic wrappers and
- removed.
+This prevents them being treated as stale asm-generic wrappers and
+removed.
- Example::
+Example::
- #arch/x86/include/asm/Kbuild
- generated-y += syscalls_32.h
+ #arch/x86/include/asm/Kbuild
+ generated-y += syscalls_32.h
-8.4 mandatory-y
----------------
+mandatory-y
+-----------
- mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild
- to define the minimum set of ASM headers that all architectures must have.
+mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild
+to define the minimum set of ASM headers that all architectures must have.
- This works like optional generic-y. If a mandatory header is missing
- in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically
- generate a wrapper of the asm-generic one.
+This works like optional generic-y. If a mandatory header is missing
+in arch/$(SRCARCH)/include/(uapi/)/asm, Kbuild will automatically
+generate a wrapper of the asm-generic one.
-9 Kbuild Variables
-==================
+Kbuild Variables
+================
The top Makefile exports the following variables:
- VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
- These variables define the current kernel version. A few arch
- Makefiles actually use these values directly; they should use
- $(KERNELRELEASE) instead.
-
- $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic
- three-part version number, such as "2", "4", and "0". These three
- values are always numeric.
-
- $(EXTRAVERSION) defines an even tinier sublevel for pre-patches
- or additional patches. It is usually some non-numeric string
- such as "-pre4", and is often blank.
-
- KERNELRELEASE
- $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable
- for constructing installation directory names or showing in
- version strings. Some arch Makefiles use it for this purpose.
-
- ARCH
- This variable defines the target architecture, such as "i386",
- "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to
- determine which files to compile.
-
- By default, the top Makefile sets $(ARCH) to be the same as the
- host system architecture. For a cross build, a user may
- override the value of $(ARCH) on the command line::
-
- make ARCH=m68k ...
-
- SRCARCH
- This variable specifies the directory in arch/ to build.
-
- ARCH and SRCARCH may not necessarily match. A couple of arch
- directories are biarch, that is, a single `arch/*/` directory supports
- both 32-bit and 64-bit.
-
- For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86.
- For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and
- x86_64.
-
- INSTALL_PATH
- This variable defines a place for the arch Makefiles to install
- the resident kernel image and System.map file.
- Use this for architecture-specific install targets.
-
- INSTALL_MOD_PATH, MODLIB
- $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module
- installation. This variable is not defined in the Makefile but
- may be passed in by the user if desired.
-
- $(MODLIB) specifies the directory for module installation.
- The top Makefile defines $(MODLIB) to
- $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may
- override this value on the command line if desired.
-
- INSTALL_MOD_STRIP
- If this variable is specified, it will cause modules to be stripped
- after they are installed. If INSTALL_MOD_STRIP is '1', then the
- default option --strip-debug will be used. Otherwise, the
- INSTALL_MOD_STRIP value will be used as the option(s) to the strip
- command.
-
-
-10 Makefile language
-====================
+VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
+ These variables define the current kernel version. A few arch
+ Makefiles actually use these values directly; they should use
+ $(KERNELRELEASE) instead.
+
+ $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic
+ three-part version number, such as "2", "4", and "0". These three
+ values are always numeric.
+
+ $(EXTRAVERSION) defines an even tinier sublevel for pre-patches
+ or additional patches. It is usually some non-numeric string
+ such as "-pre4", and is often blank.
+
+KERNELRELEASE
+ $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable
+ for constructing installation directory names or showing in
+ version strings. Some arch Makefiles use it for this purpose.
+
+ARCH
+ This variable defines the target architecture, such as "i386",
+ "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to
+ determine which files to compile.
+
+ By default, the top Makefile sets $(ARCH) to be the same as the
+ host system architecture. For a cross build, a user may
+ override the value of $(ARCH) on the command line::
+
+ make ARCH=m68k ...
+
+SRCARCH
+ This variable specifies the directory in arch/ to build.
+
+ ARCH and SRCARCH may not necessarily match. A couple of arch
+ directories are biarch, that is, a single ``arch/*/`` directory supports
+ both 32-bit and 64-bit.
+
+ For example, you can pass in ARCH=i386, ARCH=x86_64, or ARCH=x86.
+ For all of them, SRCARCH=x86 because arch/x86/ supports both i386 and
+ x86_64.
+
+INSTALL_PATH
+ This variable defines a place for the arch Makefiles to install
+ the resident kernel image and System.map file.
+ Use this for architecture-specific install targets.
+
+INSTALL_MOD_PATH, MODLIB
+ $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module
+ installation. This variable is not defined in the Makefile but
+ may be passed in by the user if desired.
+
+ $(MODLIB) specifies the directory for module installation.
+ The top Makefile defines $(MODLIB) to
+ $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may
+ override this value on the command line if desired.
+
+INSTALL_MOD_STRIP
+ If this variable is specified, it will cause modules to be stripped
+ after they are installed. If INSTALL_MOD_STRIP is "1", then the
+ default option --strip-debug will be used. Otherwise, the
+ INSTALL_MOD_STRIP value will be used as the option(s) to the strip
+ command.
+
+INSTALL_DTBS_PATH
+ This variable specifies a prefix for relocations required by build
+ roots. It defines a place for installing the device tree blobs. Like
+ INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed
+ by the user if desired. Otherwise it defaults to the kernel install
+ path.
+
+Makefile language
+=================
The kernel Makefiles are designed to be run with GNU Make. The Makefiles
use only the documented features of GNU Make, but they do use many
@@ -1676,28 +1672,27 @@ GNU extensions.
GNU Make supports elementary list-processing functions. The kernel
Makefiles use a novel style of list building and manipulation with few
-"if" statements.
+``if`` statements.
-GNU Make has two assignment operators, ":=" and "=". ":=" performs
+GNU Make has two assignment operators, ``:=`` and ``=``. ``:=`` performs
immediate evaluation of the right-hand side and stores an actual string
-into the left-hand side. "=" is like a formula definition; it stores the
+into the left-hand side. ``=`` is like a formula definition; it stores the
right-hand side in an unevaluated form and then evaluates this form each
time the left-hand side is used.
-There are some cases where "=" is appropriate. Usually, though, ":="
+There are some cases where ``=`` is appropriate. Usually, though, ``:=``
is the right choice.
-11 Credits
-==========
+Credits
+=======
- Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
- Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
- Updates by Sam Ravnborg <sam@ravnborg.org>
- Language QA by Jan Engelhardt <jengelh@gmx.de>
-12 TODO
-=======
+TODO
+====
-- Describe how kbuild supports shipped files with _shipped.
- Generating offset header files.
- Add more variables to chapters 7 or 9?
diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst
index a1f3eb7a43e2..d0703605bfa4 100644
--- a/Documentation/kbuild/modules.rst
+++ b/Documentation/kbuild/modules.rst
@@ -4,41 +4,12 @@ Building External Modules
This document describes how to build an out-of-tree kernel module.
-.. Table of Contents
-
- === 1 Introduction
- === 2 How to Build External Modules
- --- 2.1 Command Syntax
- --- 2.2 Options
- --- 2.3 Targets
- --- 2.4 Building Separate Files
- === 3. Creating a Kbuild File for an External Module
- --- 3.1 Shared Makefile
- --- 3.2 Separate Kbuild file and Makefile
- --- 3.3 Binary Blobs
- --- 3.4 Building Multiple Modules
- === 4. Include Files
- --- 4.1 Kernel Includes
- --- 4.2 Single Subdirectory
- --- 4.3 Several Subdirectories
- === 5. Module Installation
- --- 5.1 INSTALL_MOD_PATH
- --- 5.2 INSTALL_MOD_DIR
- === 6. Module Versioning
- --- 6.1 Symbols From the Kernel (vmlinux + modules)
- --- 6.2 Symbols and External Modules
- --- 6.3 Symbols From Another External Module
- === 7. Tips & Tricks
- --- 7.1 Testing for CONFIG_FOO_BAR
-
-
-
-1. Introduction
-===============
+Introduction
+============
"kbuild" is the build system used by the Linux kernel. Modules must use
kbuild to stay compatible with changes in the build infrastructure and
-to pick up the right flags to "gcc." Functionality for building modules
+to pick up the right flags to the compiler. Functionality for building modules
both in-tree and out-of-tree is provided. The method for building
either is similar, and all modules are initially developed and built
out-of-tree.
@@ -48,11 +19,11 @@ in building out-of-tree (or "external") modules. The author of an
external module should supply a makefile that hides most of the
complexity, so one only has to type "make" to build the module. This is
easily accomplished, and a complete example will be presented in
-section 3.
+section `Creating a Kbuild File for an External Module`_.
-2. How to Build External Modules
-================================
+How to Build External Modules
+=============================
To build external modules, you must have a prebuilt kernel available
that contains the configuration and header files used in the build.
@@ -69,12 +40,12 @@ NOTE: "modules_prepare" will not build Module.symvers even if
CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
executed to make module versioning work.
-2.1 Command Syntax
-==================
+Command Syntax
+--------------
The command to build an external module is::
- $ make -C <path_to_kernel_src> M=$PWD
+ $ make -C <path_to_kernel_dir> M=$PWD
The kbuild system knows that an external module is being built
due to the "M=<dir>" option given in the command.
@@ -88,15 +59,27 @@ executed to make module versioning work.
$ make -C /lib/modules/`uname -r`/build M=$PWD modules_install
-2.2 Options
-===========
+ Starting from Linux 6.13, you can use the -f option instead of -C. This
+ will avoid unnecessary change of the working directory. The external
+ module will be output to the directory where you invoke make.
+
+ $ make -f /lib/modules/`uname -r`/build/Makefile M=$PWD
+
+Options
+-------
- ($KDIR refers to the path of the kernel source directory.)
+ ($KDIR refers to the path of the kernel source directory, or the path
+ of the kernel output directory if the kernel was built in a separate
+ build directory.)
- make -C $KDIR M=$PWD
+ You can optionally pass MO= option if you want to build the modules in
+ a separate directory.
+
+ make -C $KDIR M=$PWD [MO=$BUILD_DIR]
-C $KDIR
- The directory where the kernel source is located.
+ The directory that contains the kernel and relevant build
+ artifacts used for building an external module.
"make" will actually change to the specified directory
when executing and will change back when finished.
@@ -106,8 +89,11 @@ executed to make module versioning work.
directory where the external module (kbuild file) is
located.
-2.3 Targets
-===========
+ MO=$BUILD_DIR
+ Specifies a separate output directory for the external module.
+
+Targets
+-------
When building an external module, only a subset of the "make"
targets are available.
@@ -128,8 +114,9 @@ executed to make module versioning work.
modules_install
Install the external module(s). The default location is
- /lib/modules/<kernel_release>/extra/, but a prefix may
- be added with INSTALL_MOD_PATH (discussed in section 5).
+ /lib/modules/<kernel_release>/updates/, but a prefix may
+ be added with INSTALL_MOD_PATH (discussed in section
+ `Module Installation`_).
clean
Remove all generated files in the module directory only.
@@ -137,8 +124,8 @@ executed to make module versioning work.
help
List the available targets for external modules.
-2.4 Building Separate Files
-===========================
+Building Separate Files
+-----------------------
It is possible to build single files that are part of a module.
This works equally well for the kernel, a module, and even for
@@ -152,8 +139,8 @@ executed to make module versioning work.
make -C $KDIR M=$PWD ./
-3. Creating a Kbuild File for an External Module
-================================================
+Creating a Kbuild File for an External Module
+=============================================
In the last section we saw the command to build a module for the
running kernel. The module is not actually built, however, because a
@@ -180,10 +167,9 @@ module 8123.ko, which is built from the following files::
8123_if.c
8123_if.h
8123_pci.c
- 8123_bin.o_shipped <= Binary blob
-3.1 Shared Makefile
--------------------
+Shared Makefile
+---------------
An external module always includes a wrapper makefile that
supports building the module using "make" with no arguments.
@@ -198,7 +184,7 @@ module 8123.ko, which is built from the following files::
ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m := 8123.o
- 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+ 8123-y := 8123_if.o 8123_pci.o
else
# normal makefile
@@ -207,10 +193,6 @@ module 8123.ko, which is built from the following files::
default:
$(MAKE) -C $(KDIR) M=$$PWD
- # Module specific targets
- genbin:
- echo "X" > 8123_bin.o_shipped
-
endif
The check for KERNELRELEASE is used to separate the two parts
@@ -221,19 +203,18 @@ module 8123.ko, which is built from the following files::
line; the second pass is by the kbuild system, which is
initiated by the parameterized "make" in the default target.
-3.2 Separate Kbuild File and Makefile
--------------------------------------
+Separate Kbuild File and Makefile
+---------------------------------
- In newer versions of the kernel, kbuild will first look for a
- file named "Kbuild," and only if that is not found, will it
- then look for a makefile. Utilizing a "Kbuild" file allows us
- to split up the makefile from example 1 into two files:
+ Kbuild will first look for a file named "Kbuild", and if it is not
+ found, it will then look for "Makefile". Utilizing a "Kbuild" file
+ allows us to split up the "Makefile" from example 1 into two files:
Example 2::
--> filename: Kbuild
obj-m := 8123.o
- 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+ 8123-y := 8123_if.o 8123_pci.o
--> filename: Makefile
KDIR ?= /lib/modules/`uname -r`/build
@@ -241,68 +222,28 @@ module 8123.ko, which is built from the following files::
default:
$(MAKE) -C $(KDIR) M=$$PWD
- # Module specific targets
- genbin:
- echo "X" > 8123_bin.o_shipped
-
The split in example 2 is questionable due to the simplicity of
each file; however, some external modules use makefiles
consisting of several hundred lines, and here it really pays
off to separate the kbuild part from the rest.
- The next example shows a backward compatible version.
+ Linux 6.13 and later support another way. The external module Makefile
+ can include the kernel Makefile directly, rather than invoking sub Make.
Example 3::
--> filename: Kbuild
obj-m := 8123.o
- 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+ 8123-y := 8123_if.o 8123_pci.o
--> filename: Makefile
- ifneq ($(KERNELRELEASE),)
- # kbuild part of makefile
- include Kbuild
+ KDIR ?= /lib/modules/$(shell uname -r)/build
+ export KBUILD_EXTMOD := $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
+ include $(KDIR)/Makefile
- else
- # normal makefile
- KDIR ?= /lib/modules/`uname -r`/build
-
- default:
- $(MAKE) -C $(KDIR) M=$$PWD
-
- # Module specific targets
- genbin:
- echo "X" > 8123_bin.o_shipped
- endif
-
- Here the "Kbuild" file is included from the makefile. This
- allows an older version of kbuild, which only knows of
- makefiles, to be used when the "make" and kbuild parts are
- split into separate files.
-
-3.3 Binary Blobs
-----------------
-
- Some external modules need to include an object file as a blob.
- kbuild has support for this, but requires the blob file to be
- named <filename>_shipped. When the kbuild rules kick in, a copy
- of <filename>_shipped is created with _shipped stripped off,
- giving us <filename>. This shortened filename can be used in
- the assignment to the module.
-
- Throughout this section, 8123_bin.o_shipped has been used to
- build the kernel module 8123.ko; it has been included as
- 8123_bin.o::
-
- 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
-
- Although there is no distinction between the ordinary source
- files and the binary file, kbuild will pick up different rules
- when creating the object file for the module.
-
-3.4 Building Multiple Modules
-=============================
+Building Multiple Modules
+-------------------------
kbuild supports building multiple modules with a single build
file. For example, if you wanted to build two modules, foo.ko
@@ -315,8 +256,8 @@ module 8123.ko, which is built from the following files::
It is that simple!
-4. Include Files
-================
+Include Files
+=============
Within the kernel, header files are kept in standard locations
according to the following rule:
@@ -334,19 +275,19 @@ according to the following rule:
include/scsi; and architecture specific headers are located
under arch/$(SRCARCH)/include/.
-4.1 Kernel Includes
--------------------
+Kernel Includes
+---------------
To include a header file located under include/linux/, simply
use::
#include <linux/module.h>
- kbuild will add options to "gcc" so the relevant directories
+ kbuild will add options to the compiler so the relevant directories
are searched.
-4.2 Single Subdirectory
------------------------
+Single Subdirectory
+-------------------
External modules tend to place header files in a separate
include/ directory where their source is located, although this
@@ -360,15 +301,11 @@ according to the following rule:
--> filename: Kbuild
obj-m := 8123.o
- ccflags-y := -Iinclude
- 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
+ ccflags-y := -I $(src)/include
+ 8123-y := 8123_if.o 8123_pci.o
- Note that in the assignment there is no space between -I and
- the path. This is a limitation of kbuild: there must be no
- space present.
-
-4.3 Several Subdirectories
---------------------------
+Several Subdirectories
+----------------------
kbuild can handle files that are spread over several directories.
Consider the following example::
@@ -381,7 +318,7 @@ according to the following rule:
| |__ include
| |__ hardwareif.h
|__ include
- |__ complex.h
+ |__ complex.h
To build the module complex.ko, we then need the following
kbuild file::
@@ -407,8 +344,8 @@ according to the following rule:
file is located.
-5. Module Installation
-======================
+Module Installation
+===================
Modules which are included in the kernel are installed in the
directory:
@@ -417,10 +354,10 @@ directory:
And external modules are installed in:
- /lib/modules/$(KERNELRELEASE)/extra/
+ /lib/modules/$(KERNELRELEASE)/updates/
-5.1 INSTALL_MOD_PATH
---------------------
+INSTALL_MOD_PATH
+----------------
Above are the default directories but as always some level of
customization is possible. A prefix can be added to the
@@ -434,22 +371,22 @@ And external modules are installed in:
calling "make." This has effect when installing both in-tree
and out-of-tree modules.
-5.2 INSTALL_MOD_DIR
--------------------
+INSTALL_MOD_DIR
+---------------
External modules are by default installed to a directory under
- /lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
+ /lib/modules/$(KERNELRELEASE)/updates/, but you may wish to
locate modules for a specific functionality in a separate
directory. For this purpose, use INSTALL_MOD_DIR to specify an
- alternative name to "extra."::
+ alternative name to "updates."::
$ make INSTALL_MOD_DIR=gandalf -C $KDIR \
M=$PWD modules_install
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/
-6. Module Versioning
-====================
+Module Versioning
+=================
Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
as a simple ABI consistency check. A CRC value of the full prototype
@@ -461,8 +398,8 @@ module.
Module.symvers contains a list of all exported symbols from a kernel
build.
-6.1 Symbols From the Kernel (vmlinux + modules)
------------------------------------------------
+Symbols From the Kernel (vmlinux + modules)
+-------------------------------------------
During a kernel build, a file named Module.symvers will be
generated. Module.symvers contains all exported symbols from
@@ -486,8 +423,28 @@ build.
1) It lists all exported symbols from vmlinux and all modules.
2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
-6.2 Symbols and External Modules
---------------------------------
+Version Information Formats
+---------------------------
+
+ Exported symbols have information stored in __ksymtab or __ksymtab_gpl
+ sections. Symbol names and namespaces are stored in __ksymtab_strings,
+ using a format similar to the string table used for ELF. If
+ CONFIG_MODVERSIONS is enabled, the CRCs corresponding to exported
+ symbols will be added to the __kcrctab or __kcrctab_gpl.
+
+ If CONFIG_BASIC_MODVERSIONS is enabled (default with
+ CONFIG_MODVERSIONS), imported symbols will have their symbol name and
+ CRC stored in the __versions section of the importing module. This
+ mode only supports symbols of length up to 64 bytes.
+
+ If CONFIG_EXTENDED_MODVERSIONS is enabled (required to enable both
+ CONFIG_MODVERSIONS and CONFIG_RUST at the same time), imported symbols
+ will have their symbol name recorded in the __version_ext_names
+ section as a series of concatenated, null-terminated strings. CRCs for
+ these symbols will be recorded in the __version_ext_crcs section.
+
+Symbols and External Modules
+----------------------------
When building an external module, the build system needs access
to the symbols from the kernel to check if all external symbols
@@ -496,8 +453,8 @@ build.
tree. During the MODPOST step, a new Module.symvers file will be
written containing all exported symbols from that external module.
-6.3 Symbols From Another External Module
-----------------------------------------
+Symbols From Another External Module
+------------------------------------
Sometimes, an external module uses exported symbols from
another external module. Kbuild needs to have full knowledge of
@@ -537,11 +494,11 @@ build.
initialization of its symbol tables.
-7. Tips & Tricks
-================
+Tips & Tricks
+=============
-7.1 Testing for CONFIG_FOO_BAR
-------------------------------
+Testing for CONFIG_FOO_BAR
+--------------------------
Modules often need to check for certain `CONFIG_` options to
decide if a specific feature is included in the module. In
@@ -553,9 +510,3 @@ build.
ext2-y := balloc.o bitmap.o dir.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
-
- External modules have traditionally used "grep" to check for
- specific `CONFIG_` settings directly in .config. This usage is
- broken. As introduced before, external modules should use
- kbuild for building and can therefore use the same methods as
- in-tree modules when testing for `CONFIG_` definitions.
diff --git a/Documentation/kbuild/reproducible-builds.rst b/Documentation/kbuild/reproducible-builds.rst
index 071f0151a7a4..96d208e578cd 100644
--- a/Documentation/kbuild/reproducible-builds.rst
+++ b/Documentation/kbuild/reproducible-builds.rst
@@ -61,6 +61,9 @@ supported.
The Reproducible Builds web site has more information about these
`prefix-map options`_.
+Some CONFIG options such as `CONFIG_DEBUG_EFI` embed absolute paths in
+object files. Such options should be disabled.
+
Generated files in source packages
----------------------------------
@@ -119,6 +122,16 @@ To avoid this, you can make the vDSO different for different
kernel versions by including an arbitrary string of "salt" in it.
This is specified by the Kconfig symbol ``CONFIG_BUILD_SALT``.
+Git
+---
+
+Uncommitted changes or different commit ids in git can also lead
+to different compilation results. For example, after executing
+``git reset HEAD^``, even if the code is the same, the
+``include/config/kernel.release`` generated during compilation
+will be different, which will eventually lead to binary differences.
+See ``scripts/setlocalversion`` for details.
+
.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
.. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host
.. _KCFLAGS: kbuild.html#kcflags
diff --git a/Documentation/kernel-hacking/false-sharing.rst b/Documentation/kernel-hacking/false-sharing.rst
new file mode 100644
index 000000000000..eb0596734e55
--- /dev/null
+++ b/Documentation/kernel-hacking/false-sharing.rst
@@ -0,0 +1,206 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+False Sharing
+=============
+
+What is False Sharing
+=====================
+False sharing is related with cache mechanism of maintaining the data
+coherence of one cache line stored in multiple CPU's caches; then
+academic definition for it is in [1]_. Consider a struct with a
+refcount and a string::
+
+ struct foo {
+ refcount_t refcount;
+ ...
+ char name[16];
+ } ____cacheline_internodealigned_in_smp;
+
+Member 'refcount'(A) and 'name'(B) _share_ one cache line like below::
+
+ +-----------+ +-----------+
+ | CPU 0 | | CPU 1 |
+ +-----------+ +-----------+
+ / |
+ / |
+ V V
+ +----------------------+ +----------------------+
+ | A B | Cache 0 | A B | Cache 1
+ +----------------------+ +----------------------+
+ | |
+ ---------------------------+------------------+-----------------------------
+ | |
+ +----------------------+
+ | |
+ +----------------------+
+ Main Memory | A B |
+ +----------------------+
+
+'refcount' is modified frequently, but 'name' is set once at object
+creation time and is never modified. When many CPUs access 'foo' at
+the same time, with 'refcount' being only bumped by one CPU frequently
+and 'name' being read by other CPUs, all those reading CPUs have to
+reload the whole cache line over and over due to the 'sharing', even
+though 'name' is never changed.
+
+There are many real-world cases of performance regressions caused by
+false sharing. One of these is a rw_semaphore 'mmap_lock' inside
+mm_struct struct, whose cache line layout change triggered a
+regression and Linus analyzed in [2]_.
+
+There are two key factors for a harmful false sharing:
+
+* A global datum accessed (shared) by many CPUs
+* In the concurrent accesses to the data, there is at least one write
+ operation: write/write or write/read cases.
+
+The sharing could be from totally unrelated kernel components, or
+different code paths of the same kernel component.
+
+
+False Sharing Pitfalls
+======================
+Back in time when one platform had only one or a few CPUs, hot data
+members could be purposely put in the same cache line to make them
+cache hot and save cacheline/TLB, like a lock and the data protected
+by it. But for recent large system with hundreds of CPUs, this may
+not work when the lock is heavily contended, as the lock owner CPU
+could write to the data, while other CPUs are busy spinning the lock.
+
+Looking at past cases, there are several frequently occurring patterns
+for false sharing:
+
+* lock (spinlock/mutex/semaphore) and data protected by it are
+ purposely put in one cache line.
+* global data being put together in one cache line. Some kernel
+ subsystems have many global parameters of small size (4 bytes),
+ which can easily be grouped together and put into one cache line.
+* data members of a big data structure randomly sitting together
+ without being noticed (cache line is usually 64 bytes or more),
+ like 'mem_cgroup' struct.
+
+Following 'mitigation' section provides real-world examples.
+
+False sharing could easily happen unless they are intentionally
+checked, and it is valuable to run specific tools for performance
+critical workloads to detect false sharing affecting performance case
+and optimize accordingly.
+
+
+How to detect and analyze False Sharing
+========================================
+perf record/report/stat are widely used for performance tuning, and
+once hotspots are detected, tools like 'perf-c2c' and 'pahole' can
+be further used to detect and pinpoint the possible false sharing
+data structures. 'addr2line' is also good at decoding instruction
+pointer when there are multiple layers of inline functions.
+
+perf-c2c can capture the cache lines with most false sharing hits,
+decoded functions (line number of file) accessing that cache line,
+and in-line offset of the data. Simple commands are::
+
+ $ perf c2c record -ag sleep 3
+ $ perf c2c report --call-graph none -k vmlinux
+
+When running above during testing will-it-scale's tlb_flush1 case,
+perf reports something like::
+
+ Total records : 1658231
+ Locked Load/Store Operations : 89439
+ Load Operations : 623219
+ Load Local HITM : 92117
+ Load Remote HITM : 139
+
+ #----------------------------------------------------------------------
+ 4 0 2374 0 0 0 0xff1100088366d880
+ #----------------------------------------------------------------------
+ 0.00% 42.29% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff81373b7b 0 231 129 5312 64 [k] __mod_lruvec_page_state [kernel.vmlinux] memcontrol.h:752 1
+ 0.00% 13.10% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff81374718 0 226 97 3551 64 [k] folio_lruvec_lock_irqsave [kernel.vmlinux] memcontrol.h:752 1
+ 0.00% 11.20% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff812c29bf 0 170 136 555 64 [k] lru_add_fn [kernel.vmlinux] mm_inline.h:41 1
+ 0.00% 7.62% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff812c3ec5 0 175 108 632 64 [k] release_pages [kernel.vmlinux] mm_inline.h:41 1
+ 0.00% 23.29% 0.00% 0.00% 0.00% 0x10 1 1 0xffffffff81372d0a 0 234 279 1051 64 [k] __mod_memcg_lruvec_state [kernel.vmlinux] memcontrol.c:736 1
+
+A nice introduction for perf-c2c is [3]_.
+
+'pahole' decodes data structure layouts delimited in cache line
+granularity. Users can match the offset in perf-c2c output with
+pahole's decoding to locate the exact data members. For global
+data, users can search the data address in System.map.
+
+
+Possible Mitigations
+====================
+False sharing does not always need to be mitigated. False sharing
+mitigations should balance performance gains with complexity and
+space consumption. Sometimes, lower performance is OK, and it's
+unnecessary to hyper-optimize every rarely used data structure or
+a cold data path.
+
+False sharing hurting performance cases are seen more frequently with
+core count increasing. Because of these detrimental effects, many
+patches have been proposed across variety of subsystems (like
+networking and memory management) and merged. Some common mitigations
+(with examples) are:
+
+* Separate hot global data in its own dedicated cache line, even if it
+ is just a 'short' type. The downside is more consumption of memory,
+ cache line and TLB entries.
+
+ - Commit 91b6d3256356 ("net: cache align tcp_memory_allocated, tcp_sockets_allocated")
+
+* Reorganize the data structure, separate the interfering members to
+ different cache lines. One downside is it may introduce new false
+ sharing of other members.
+
+ - Commit 802f1d522d5f ("mm: page_counter: re-layout structure to reduce false sharing")
+
+* Replace 'write' with 'read' when possible, especially in loops.
+ Like for some global variable, use compare(read)-then-write instead
+ of unconditional write. For example, use::
+
+ if (!test_bit(XXX))
+ set_bit(XXX);
+
+ instead of directly "set_bit(XXX);", similarly for atomic_t data::
+
+ if (atomic_read(XXX) == AAA)
+ atomic_set(XXX, BBB);
+
+ - Commit 7b1002f7cfe5 ("bcache: fixup bcache_dev_sectors_dirty_add() multithreaded CPU false sharing")
+ - Commit 292648ac5cf1 ("mm: gup: allow FOLL_PIN to scale in SMP")
+
+* Turn hot global data to 'per-cpu data + global data' when possible,
+ or reasonably increase the threshold for syncing per-cpu data to
+ global data, to reduce or postpone the 'write' to that global data.
+
+ - Commit 520f897a3554 ("ext4: use percpu_counters for extent_status cache hits/misses")
+ - Commit 56f3547bfa4d ("mm: adjust vm_committed_as_batch according to vm overcommit policy")
+
+Surely, all mitigations should be carefully verified to not cause side
+effects. To avoid introducing false sharing when coding, it's better
+to:
+
+* Be aware of cache line boundaries
+* Group mostly read-only fields together
+* Group things that are written at the same time together
+* Separate frequently read and frequently written fields on
+ different cache lines.
+
+and better add a comment stating the false sharing consideration.
+
+One note is, sometimes even after a severe false sharing is detected
+and solved, the performance may still have no obvious improvement as
+the hotspot switches to a new place.
+
+
+Miscellaneous
+=============
+One open issue is that the kernel has an optional data structure
+randomization mechanism, which also randomizes the situation of cache
+line sharing among data members.
+
+
+.. [1] https://en.wikipedia.org/wiki/False_sharing
+.. [2] https://lore.kernel.org/lkml/CAHk-=whoqV=cX5VC80mmR9rr+Z+yQ6fiQZm36Fb-izsanHg23w@mail.gmail.com/
+.. [3] https://joemario.github.io/blog/2016/09/01/c2c-blog/
diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
index 9a1f020c8449..0042776a9e17 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -120,7 +120,7 @@ You can tell you are in a softirq (or tasklet) using the
.. warning::
Beware that this will return a false positive if a
- :ref:`botton half lock <local_bh_disable>` is held.
+ :ref:`bottom half lock <local_bh_disable>` is held.
Some Basic Rules
================
@@ -587,7 +587,7 @@ Defined in ``include/linux/export.h``
Similar to :c:func:`EXPORT_SYMBOL()` except that the symbols
exported by :c:func:`EXPORT_SYMBOL_GPL()` can only be seen by
-modules with a :c:func:`MODULE_LICENSE()` that specifies a GPL
+modules with a :c:func:`MODULE_LICENSE()` that specifies a GPLv2
compatible license. It implies that the function is considered an
internal implementation issue, and not really an interface. Some
maintainers and developers may however require EXPORT_SYMBOL_GPL()
diff --git a/Documentation/kernel-hacking/index.rst b/Documentation/kernel-hacking/index.rst
index f53027652290..79c03bac99a2 100644
--- a/Documentation/kernel-hacking/index.rst
+++ b/Documentation/kernel-hacking/index.rst
@@ -9,3 +9,4 @@ Kernel Hacking Guides
hacking
locking
+ false-sharing
diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index 6805ae6e86e6..dff0646a717b 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -967,7 +967,7 @@ you might do the following::
while (list) {
struct foo *next = list->next;
- del_timer(&list->timer);
+ timer_delete(&list->timer);
kfree(list);
list = next;
}
@@ -981,7 +981,7 @@ the lock after we spin_unlock_bh(), and then try to free
the element (which has already been freed!).
This can be avoided by checking the result of
-del_timer(): if it returns 1, the timer has been deleted.
+timer_delete(): if it returns 1, the timer has been deleted.
If 0, it means (in this case) that it is currently running, so we can
do::
@@ -990,7 +990,7 @@ do::
while (list) {
struct foo *next = list->next;
- if (!del_timer(&list->timer)) {
+ if (!timer_delete(&list->timer)) {
/* Give timer a chance to delete this */
spin_unlock_bh(&list_lock);
goto retry;
@@ -1005,9 +1005,12 @@ do::
Another common problem is deleting timers which restart themselves (by
calling add_timer() at the end of their timer function).
Because this is a fairly common case which is prone to races, you should
-use del_timer_sync() (``include/linux/timer.h``) to
-handle this case. It returns the number of times the timer had to be
-deleted before we finally stopped it from adding itself back in.
+use timer_delete_sync() (``include/linux/timer.h``) to handle this case.
+
+Before freeing a timer, timer_shutdown() or timer_shutdown_sync() should be
+called which will keep it from being rearmed. Any subsequent attempt to
+rearm the timer will be silently ignored by the core code.
+
Locking Speed
=============
@@ -1274,11 +1277,11 @@ Manfred Spraul points out that you can still do this, even if the data
is very occasionally accessed in user context or softirqs/tasklets. The
irq handler doesn't use a lock, and all other accesses are done as so::
- spin_lock(&lock);
+ mutex_lock(&lock);
disable_irq(irq);
...
enable_irq(irq);
- spin_unlock(&lock);
+ mutex_unlock(&lock);
The disable_irq() prevents the irq handler from running
(and waits for it to finish if it's currently running on other CPUs).
@@ -1335,7 +1338,7 @@ lock.
- kfree()
-- add_timer() and del_timer()
+- add_timer() and timer_delete()
Mutex API reference
===================
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index e5d63b940045..76fae171039c 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -17,6 +17,7 @@ LEDs
uleds
leds-blinkm
+ leds-cht-wcove
leds-el15203000
leds-lm3556
leds-lp3944
@@ -25,4 +26,7 @@ LEDs
leds-lp5562
leds-lp55xx
leds-mlxcpld
+ leds-mt6370-rgb
leds-sc27xx
+ leds-st1202
+ leds-qcom-lpg
diff --git a/Documentation/leds/leds-blinkm.rst b/Documentation/leds/leds-blinkm.rst
index c74b5bc877b1..647be1c6c552 100644
--- a/Documentation/leds/leds-blinkm.rst
+++ b/Documentation/leds/leds-blinkm.rst
@@ -7,15 +7,37 @@ The leds-blinkm driver supports the devices of the BlinkM family.
They are RGB-LED modules driven by a (AT)tiny microcontroller and
communicate through I2C. The default address of these modules is
0x09 but this can be changed through a command. By this you could
-dasy-chain up to 127 BlinkMs on an I2C bus.
+daisy-chain up to 127 BlinkMs on an I2C bus.
The device accepts RGB and HSB color values through separate commands.
Also you can store blinking sequences as "scripts" in
the controller and run them. Also fading is an option.
-The interface this driver provides is 2-fold:
+The interface this driver provides is 3-fold:
-a) LED class interface for use with triggers
+a) LED multicolor class interface for use with triggers
+#######################################################
+
+The registration follows the scheme::
+
+ blinkm-<i2c-bus-nr>-<i2c-device-nr>:rgb:indicator
+
+ $ ls -h /sys/class/leds/blinkm-1-9:rgb:indicator
+ brightness device max_brightness multi_index multi_intensity power subsystem trigger uevent
+
+Hue is controlled by the multi_intensity file and lightness is controlled by
+the brightness file.
+
+The order in which to write the intensity values can be found in multi_index.
+Exactly three values between 0 and 255 must be written to multi_intensity to
+change the color::
+
+ $ echo 255 100 50 > multi_intensity
+
+The overall lightness be changed by writing a value between 0 and 255 to the
+brightness file.
+
+b) LED class interface for use with triggers
############################################
The registration follows the scheme::
@@ -79,6 +101,7 @@ E.g.::
-as of 6/2012
+as of 07/2024
dl9pf <at> gmx <dot> de
+jstrauss <at> mailbox <dot> org
diff --git a/Documentation/leds/leds-cht-wcove.rst b/Documentation/leds/leds-cht-wcove.rst
new file mode 100644
index 000000000000..5ec7cb60c4aa
--- /dev/null
+++ b/Documentation/leds/leds-cht-wcove.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================================================
+Kernel driver for Intel Cherry Trail Whiskey Cove PMIC LEDs
+===========================================================
+
+/sys/class/leds/<led>/hw_pattern
+--------------------------------
+
+Specify a hardware pattern for the Whiskey Cove PMIC LEDs.
+
+The only supported pattern is hardware breathing mode::
+
+ "0 2000 1 2000"
+
+ ^
+ |
+ Max-| ---
+ | / \
+ | / \
+ | / \ /
+ | / \ /
+ Min-|- ---
+ |
+ 0------2------4--> time (sec)
+
+The rise and fall times must be the same value.
+Supported values are 2000, 1000, 500 and 250 for
+breathing frequencies of 1/4, 1/2, 1 and 2 Hz.
+
+The set pattern only controls the timing. For max brightness the last
+set brightness is used and the max brightness can be changed
+while breathing by writing the brightness attribute.
+
+This is just like how blinking works in the LED subsystem,
+for both sw and hw blinking the brightness can also be changed
+while blinking. Breathing on this hw really is just a variant
+mode of blinking.
diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst
index c57b98bfd387..c6b47b4093c4 100644
--- a/Documentation/leds/leds-class-multicolor.rst
+++ b/Documentation/leds/leds-class-multicolor.rst
@@ -18,24 +18,28 @@ array. These files are children under the LED parent node created by the
led_class framework. The led_class framework is documented in led-class.rst
within this documentation directory.
-Each colored LED will be indexed under the multi_* files. The order of the
-colors will be arbitrary. The multi_index file can be read to determine the
+Each colored LED will be indexed under the ``multi_*`` files. The order of the
+colors will be arbitrary. The ``multi_index`` file can be read to determine the
color name to indexed value.
-The multi_index file is an array that contains the string list of the colors as
-they are defined in each multi_* array file.
+The ``multi_index`` file is an array that contains the string list of the colors as
+they are defined in each ``multi_*`` array file.
-The multi_intensity is an array that can be read or written to for the
+The ``multi_intensity`` is an array that can be read or written to for the
individual color intensities. All elements within this array must be written in
order for the color LED intensities to be updated.
Directory Layout Example
========================
-root:/sys/class/leds/multicolor:status# ls -lR
--rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness
--r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
--r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
--rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
+.. code-block:: console
+
+ root:/sys/class/leds/multicolor:status# ls -lR
+ -rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness
+ -r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
+ -r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
+ -rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
+
+..
Multicolor Class Brightness Control
===================================
@@ -43,27 +47,31 @@ The brightness level for each LED is calculated based on the color LED
intensity setting divided by the global max_brightness setting multiplied by
the requested brightness.
-led_brightness = brightness * multi_intensity/max_brightness
+``led_brightness = brightness * multi_intensity/max_brightness``
Example:
A user first writes the multi_intensity file with the brightness levels
for each LED that are necessary to achieve a certain color output from a
multicolor LED group.
-cat /sys/class/leds/multicolor:status/multi_index
-green blue red
+.. code-block:: console
+
+ # cat /sys/class/leds/multicolor:status/multi_index
+ green blue red
-echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity
+ # echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity
-red -
- intensity = 138
- max_brightness = 255
-green -
- intensity = 43
- max_brightness = 255
-blue -
- intensity = 226
- max_brightness = 255
+ red -
+ intensity = 138
+ max_brightness = 255
+ green -
+ intensity = 43
+ max_brightness = 255
+ blue -
+ intensity = 226
+ max_brightness = 255
+
+..
The user can control the brightness of that multicolor LED group by writing the
global 'brightness' control. Assuming a max_brightness of 255 the user
@@ -71,16 +79,28 @@ may want to dim the LED color group to half. The user would write a value of
128 to the global brightness file then the values written to each LED will be
adjusted base on this value.
-cat /sys/class/leds/multicolor:status/max_brightness
-255
-echo 128 > /sys/class/leds/multicolor:status/brightness
+.. code-block:: console
+
+ # cat /sys/class/leds/multicolor:status/max_brightness
+ 255
+ # echo 128 > /sys/class/leds/multicolor:status/brightness
-adjusted_red_value = 128 * 138/255 = 69
-adjusted_green_value = 128 * 43/255 = 21
-adjusted_blue_value = 128 * 226/255 = 113
+..
+
+.. code-block:: none
+
+ adjusted_red_value = 128 * 138/255 = 69
+ adjusted_green_value = 128 * 43/255 = 21
+ adjusted_blue_value = 128 * 226/255 = 113
+
+..
Reading the global brightness file will return the current brightness value of
the color LED group.
-cat /sys/class/leds/multicolor:status/brightness
-128
+.. code-block:: console
+
+ # cat /sys/class/leds/multicolor:status/brightness
+ 128
+
+..
diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index cd155ead8703..5db620ed27aa 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -169,6 +169,87 @@ Setting the brightness to zero with brightness_set() callback function
should completely turn off the LED and cancel the previously programmed
hardware blinking function, if any.
+Hardware driven LEDs
+====================
+
+Some LEDs can be programmed to be driven by hardware. This is not
+limited to blink but also to turn off or on autonomously.
+To support this feature, a LED needs to implement various additional
+ops and needs to declare specific support for the supported triggers.
+
+With hw control we refer to the LED driven by hardware.
+
+LED driver must define the following value to support hw control:
+
+ - hw_control_trigger:
+ unique trigger name supported by the LED in hw control
+ mode.
+
+LED driver must implement the following API to support hw control:
+ - hw_control_is_supported:
+ check if the flags passed by the supported trigger can
+ be parsed and activate hw control on the LED.
+
+ Return 0 if the passed flags mask is supported and
+ can be set with hw_control_set().
+
+ If the passed flags mask is not supported -EOPNOTSUPP
+ must be returned, the LED trigger will use software
+ fallback in this case.
+
+ Return a negative error in case of any other error like
+ device not ready or timeouts.
+
+ - hw_control_set:
+ activate hw control. LED driver will use the provided
+ flags passed from the supported trigger, parse them to
+ a set of mode and setup the LED to be driven by hardware
+ following the requested modes.
+
+ Set LED_OFF via the brightness_set to deactivate hw control.
+
+ Return 0 on success, a negative error number on failing to
+ apply flags.
+
+ - hw_control_get:
+ get active modes from a LED already in hw control, parse
+ them and set in flags the current active flags for the
+ supported trigger.
+
+ Return 0 on success, a negative error number on failing
+ parsing the initial mode.
+ Error from this function is NOT FATAL as the device may
+ be in a not supported initial state by the attached LED
+ trigger.
+
+ - hw_control_get_device:
+ return the device associated with the LED driver in
+ hw control. A trigger might use this to match the
+ returned device from this function with a configured
+ device for the trigger as the source for blinking
+ events and correctly enable hw control.
+ (example a netdev trigger configured to blink for a
+ particular dev match the returned dev from get_device
+ to set hw control)
+
+ Returns a pointer to a struct device or NULL if nothing
+ is currently attached.
+
+LED driver can activate additional modes by default to workaround the
+impossibility of supporting each different mode on the supported trigger.
+Examples are hardcoding the blink speed to a set interval, enable special
+feature like bypassing blink if some requirements are not met.
+
+A trigger should first check if the hw control API are supported by the LED
+driver and check if the trigger is supported to verify if hw control is possible,
+use hw_control_is_supported to check if the flags are supported and only at
+the end use hw_control_set to activate hw control.
+
+A trigger can use hw_control_get to check if a LED is already in hw control
+and init their flags.
+
+When the LED is in hw control, no software blink is possible and doing so
+will effectively disable hw control.
Known Issues
============
diff --git a/Documentation/leds/leds-lp5521.rst b/Documentation/leds/leds-lp5521.rst
index 0432615b083d..4c838c88820e 100644
--- a/Documentation/leds/leds-lp5521.rst
+++ b/Documentation/leds/leds-lp5521.rst
@@ -22,7 +22,7 @@ More details of the instructions can be found from the public data sheet.
LP5521 has the internal program memory for running various LED patterns.
There are two ways to run LED patterns.
-1) Legacy interface - enginex_mode and enginex_load
+1) sysfs interface - enginex_mode and enginex_load
Control interface for the engines:
x is 1 .. 3
diff --git a/Documentation/leds/leds-lp5523.rst b/Documentation/leds/leds-lp5523.rst
index 7d7362a1dd57..f5a87b07514a 100644
--- a/Documentation/leds/leds-lp5523.rst
+++ b/Documentation/leds/leds-lp5523.rst
@@ -35,7 +35,7 @@ If both fields are NULL, 'lp5523' is used by default.
LP5523 has the internal program memory for running various LED patterns.
There are two ways to run LED patterns.
-1) Legacy interface - enginex_mode, enginex_load and enginex_leds
+1) sysfs interface - enginex_mode, enginex_load and enginex_leds
Control interface for the engines:
diff --git a/Documentation/leds/leds-mlxcpld.rst b/Documentation/leds/leds-mlxcpld.rst
index 528582429e0b..c520a134d91e 100644
--- a/Documentation/leds/leds-mlxcpld.rst
+++ b/Documentation/leds/leds-mlxcpld.rst
@@ -115,4 +115,4 @@ Driver provides the following LEDs for the system "msn2100":
- [1,1,1,1] = Blue blink 6Hz
Driver supports HW blinking at 3Hz and 6Hz frequency (50% duty cycle).
-For 3Hz duty cylce is about 167 msec, for 6Hz is about 83 msec.
+For 3Hz duty cycle is about 167 msec, for 6Hz is about 83 msec.
diff --git a/Documentation/leds/leds-mt6370-rgb.rst b/Documentation/leds/leds-mt6370-rgb.rst
new file mode 100644
index 000000000000..152a2e592172
--- /dev/null
+++ b/Documentation/leds/leds-mt6370-rgb.rst
@@ -0,0 +1,64 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=========================================
+The device for Mediatek MT6370 RGB LED
+=========================================
+
+Description
+-----------
+
+The MT6370 integrates a four-channel RGB LED driver, designed to provide a
+variety of lighting effect for mobile device applications. The RGB LED devices
+includes a smart LED string controller and it can drive 3 channels of LEDs with
+a sink current up to 24mA and a CHG_VIN power good indicator LED with sink
+current up to 6mA. It provides three operation modes for RGB LEDs:
+PWM Dimming mode, breath pattern mode, and constant current mode. The device
+can increase or decrease the brightness of the RGB LED via an I2C interface.
+
+The breath pattern for a channel can be programmed using the "pattern" trigger,
+using the hw_pattern attribute.
+
+/sys/class/leds/<led>/hw_pattern
+--------------------------------
+
+Specify a hardware breath pattern for a MT6370 RGB LED.
+
+The breath pattern is a series of timing pairs, with the hold-time expressed in
+milliseconds. And the brightness is controlled by
+'/sys/class/leds/<led>/brightness'. The pattern doesn't include the brightness
+setting. Hardware pattern only controls the timing for each pattern stage
+depending on the current brightness setting.
+
+Pattern diagram::
+
+ "0 Tr1 0 Tr2 0 Tf1 0 Tf2 0 Ton 0 Toff" --> '0' for dummy brightness code
+
+ ^
+ | ============
+ | / \ /
+ Icurr | / \ /
+ | / \ /
+ | / \ / .....repeat
+ | / \ /
+ | --- --- ---
+ |--- --- ---
+ +----------------------------------============------------> Time
+ < Tr1><Tr2>< Ton ><Tf1><Tf2 >< Toff >< Tr1><Tr2>
+
+Timing description:
+
+ * Tr1: First rising time for 0% - 30% load.
+ * Tr2: Second rising time for 31% - 100% load.
+ * Ton: On time for 100% load.
+ * Tf1: First falling time for 100% - 31% load.
+ * Tf2: Second falling time for 30% to 0% load.
+ * Toff: Off time for 0% load.
+
+ * Tr1/Tr2/Tf1/Tf2/Ton: 125ms to 3125ms, 200ms per step.
+ * Toff: 250ms to 6250ms, 400ms per step.
+
+Pattern example::
+
+ "0 125 0 125 0 125 0 125 0 625 0 1050"
+
+This Will configure Tr1/Tr2/Tf1/Tf2 to 125m, Ton to 625ms, and Toff to 1050ms.
diff --git a/Documentation/leds/leds-qcom-lpg.rst b/Documentation/leds/leds-qcom-lpg.rst
index de7ceead9337..d6a76c38c581 100644
--- a/Documentation/leds/leds-qcom-lpg.rst
+++ b/Documentation/leds/leds-qcom-lpg.rst
@@ -34,7 +34,7 @@ Specify a hardware pattern for a Qualcomm LPG LED.
The pattern is a series of brightness and hold-time pairs, with the hold-time
expressed in milliseconds. The hold time is a property of the pattern and must
-therefor be identical for each element in the pattern (except for the pauses
+therefore be identical for each element in the pattern (except for the pauses
described below). As the LPG hardware is not able to perform the linear
transitions expected by the leds-trigger-pattern format, each entry in the
pattern must be followed a zero-length entry of the same brightness.
@@ -66,7 +66,7 @@ Low-pause pattern::
+----------------------------->
0 5 10 15 20 25 time (100ms)
-Similarily, the last entry can be stretched by using a higher hold-time on the
+Similarly, the last entry can be stretched by using a higher hold-time on the
last entry.
In order to save space in the shared lookup table the LPG supports "ping-pong"
diff --git a/Documentation/leds/leds-st1202.rst b/Documentation/leds/leds-st1202.rst
new file mode 100644
index 000000000000..1a09fbfcedcf
--- /dev/null
+++ b/Documentation/leds/leds-st1202.rst
@@ -0,0 +1,34 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================================
+Kernel driver for STMicroelectronics LED1202
+============================================
+
+/sys/class/leds/<led>/hw_pattern
+--------------------------------
+
+Specify a hardware pattern for the ST1202 LED. The LED controller
+implements 12 low-side current generators with independent dimming
+control. Internal volatile memory allows the user to store up to 8
+different patterns. Each pattern is a particular output configuration
+in terms of PWM duty-cycle and duration (ms).
+
+To be compatible with the hardware pattern format, maximum 8 tuples of
+brightness (PWM) and duration must be written to hw_pattern.
+
+- Min pattern duration: 22 ms
+- Max pattern duration: 5660 ms
+
+The format of the hardware pattern values should be:
+"brightness duration brightness duration ..."
+
+/sys/class/leds/<led>/repeat
+----------------------------
+
+Specify a pattern repeat number, which is common for all channels.
+Default is 1; negative numbers and 0 are invalid.
+
+This file will always return the originally written repeat number.
+
+When the 255 value is written to it, all patterns will repeat
+indefinitely.
diff --git a/Documentation/leds/ledtrig-oneshot.rst b/Documentation/leds/ledtrig-oneshot.rst
index 69fa3ea1d554..e044d69e9c0f 100644
--- a/Documentation/leds/ledtrig-oneshot.rst
+++ b/Documentation/leds/ledtrig-oneshot.rst
@@ -5,7 +5,7 @@ One-shot LED Trigger
This is a LED trigger useful for signaling the user of an event where there are
no clear trap points to put standard led-on and led-off settings. Using this
trigger, the application needs only to signal the trigger when an event has
-happened, than the trigger turns the LED on and than keeps it off for a
+happened, then the trigger turns the LED on and then keeps it off for a
specified amount of time.
This trigger is meant to be usable both for sporadic and dense events. In the
diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt
index 2160382c86be..17ef78faf1f3 100644
--- a/Documentation/leds/well-known-leds.txt
+++ b/Documentation/leds/well-known-leds.txt
@@ -58,6 +58,7 @@ LEDs on notebook body, indicating that sound input / output is muted.
* System notification
+Good: "rgb:status"
Legacy: "status-led:{red,green,blue}" (Motorola Droid 4)
Legacy: "lp5523:{r,g,b}" (Nokia N900)
@@ -65,8 +66,46 @@ Phones usually have multi-color status LED.
* Power management
-Good: "platform:*:charging" (allwinner sun50i)
+Good: "platform:*:charging" (allwinner sun50i, leds-cht-wcove)
* Screen
Good: ":backlight" (Motorola Droid 4)
+
+* Indicators
+
+Good: ":indicator" (Blinkm)
+
+* RGB
+
+Good: ":rgb" (Blinkm)
+
+* Ethernet LEDs
+
+Currently two types of Network LEDs are support, those controlled by
+the PHY and those by the MAC. In theory both can be present at the
+same time for one Linux netdev, hence the names need to differ between
+MAC and PHY.
+
+Do not use the netdev name, such as eth0, enp1s0. These are not stable
+and are not unique. They also don't differentiate between MAC and PHY.
+
+** MAC LEDs
+
+Good: f1070000.ethernet:white:WAN
+Good: mdio_mux-0.1:00:green:left
+Good: 0000:02:00.0:yellow:top
+
+The first part must uniquely name the MAC controller. Then follows the
+colour. WAN/LAN should be used for a single LED. If there are
+multiple LEDs, use left/right, or top/bottom to indicate their
+position on the RJ45 socket.
+
+** PHY LEDs
+
+Good: f1072004.mdio-mii:00: white:WAN
+Good: !mdio-mux!mdio@2!switch@0!mdio:01:green:right
+Good: r8169-0-200:00:yellow:bottom
+
+The first part must uniquely name the PHY. This often means uniquely
+identifying the MDIO bus controller, and the address on the bus.
diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README
index 7f5c6c3ed6c3..6c666f3422ea 100644
--- a/Documentation/litmus-tests/README
+++ b/Documentation/litmus-tests/README
@@ -9,7 +9,7 @@ a kernel test module based on a litmus test, please see
tools/memory-model/README.
-atomic (/atomic derectory)
+atomic (/atomic directory)
--------------------------
Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus
@@ -21,6 +21,51 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
Test that atomic_set() cannot break the atomicity of atomic RMWs.
NOTE: Require herd7 7.56 or later which supports "(void)expr".
+cmpxchg-fail-ordered-1.litmus
+ Demonstrate that a failing cmpxchg() operation acts as a full barrier
+ when followed by smp_mb__after_atomic().
+
+cmpxchg-fail-ordered-2.litmus
+ Demonstrate that a failing cmpxchg() operation acts as an acquire
+ operation when followed by smp_mb__after_atomic().
+
+cmpxchg-fail-unordered-1.litmus
+ Demonstrate that a failing cmpxchg() operation does not act as a
+ full barrier.
+
+cmpxchg-fail-unordered-2.litmus
+ Demonstrate that a failing cmpxchg() operation does not act as an
+ acquire operation.
+
+
+locking (/locking directory)
+----------------------------
+
+DCL-broken.litmus
+ Demonstrates that double-checked locking needs more than just
+ the obvious lock acquisitions and releases.
+
+DCL-fixed.litmus
+ Demonstrates corrected double-checked locking that uses
+ smp_store_release() and smp_load_acquire() in addition to the
+ obvious lock acquisitions and releases.
+
+RM-broken.litmus
+ Demonstrates problems with "roach motel" locking, where code is
+ freely moved into lock-based critical sections. This example also
+ shows how to use the "filter" clause to discard executions that
+ would be excluded by other code not modeled in the litmus test.
+ Note also that this "roach motel" optimization is emulated by
+ physically moving P1()'s two reads from x under the lock.
+
+ What is a roach motel? This is from an old advertisement for
+ a cockroach trap, much later featured in one of the "Men in
+ Black" movies. "The roaches check in. They don't check out."
+
+RM-fixed.litmus
+ The counterpart to RM-broken.litmus, showing P0()'s two loads from
+ x safely outside of the critical section.
+
RCU (/rcu directory)
--------------------
diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus
new file mode 100644
index 000000000000..c0f93dc07105
--- /dev/null
+++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus
@@ -0,0 +1,35 @@
+C cmpxchg-fail-ordered-1
+
+(*
+ * Result: Never
+ *
+ * Demonstrate that a failing cmpxchg() operation will act as a full
+ * barrier when followed by smp_mb__after_atomic().
+ *)
+
+{}
+
+P0(int *x, int *y, int *z)
+{
+ int r0;
+ int r1;
+
+ WRITE_ONCE(*x, 1);
+ r1 = cmpxchg(z, 1, 0);
+ smp_mb__after_atomic();
+ r0 = READ_ONCE(*y);
+}
+
+P1(int *x, int *y, int *z)
+{
+ int r0;
+ int r1;
+
+ WRITE_ONCE(*y, 1);
+ r1 = cmpxchg(z, 1, 0);
+ smp_mb__after_atomic();
+ r0 = READ_ONCE(*x);
+}
+
+locations[0:r1;1:r1]
+exists (0:r0=0 /\ 1:r0=0)
diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus
new file mode 100644
index 000000000000..5c06054f4694
--- /dev/null
+++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus
@@ -0,0 +1,30 @@
+C cmpxchg-fail-ordered-2
+
+(*
+ * Result: Never
+ *
+ * Demonstrate use of smp_mb__after_atomic() to make a failing cmpxchg
+ * operation have acquire ordering.
+ *)
+
+{}
+
+P0(int *x, int *y)
+{
+ int r1;
+
+ WRITE_ONCE(*x, 1);
+ r1 = cmpxchg(y, 0, 1);
+}
+
+P1(int *x, int *y)
+{
+ int r1;
+ int r2;
+
+ r1 = cmpxchg(y, 0, 1);
+ smp_mb__after_atomic();
+ r2 = READ_ONCE(*x);
+}
+
+exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0)
diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus
new file mode 100644
index 000000000000..39ea1f56a28d
--- /dev/null
+++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus
@@ -0,0 +1,34 @@
+C cmpxchg-fail-unordered-1
+
+(*
+ * Result: Sometimes
+ *
+ * Demonstrate that a failing cmpxchg() operation does not act as a
+ * full barrier. (In contrast, a successful cmpxchg() does act as a
+ * full barrier.)
+ *)
+
+{}
+
+P0(int *x, int *y, int *z)
+{
+ int r0;
+ int r1;
+
+ WRITE_ONCE(*x, 1);
+ r1 = cmpxchg(z, 1, 0);
+ r0 = READ_ONCE(*y);
+}
+
+P1(int *x, int *y, int *z)
+{
+ int r0;
+ int r1;
+
+ WRITE_ONCE(*y, 1);
+ r1 = cmpxchg(z, 1, 0);
+ r0 = READ_ONCE(*x);
+}
+
+locations[0:r1;1:r1]
+exists (0:r0=0 /\ 1:r0=0)
diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus
new file mode 100644
index 000000000000..61aab24a4a64
--- /dev/null
+++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus
@@ -0,0 +1,30 @@
+C cmpxchg-fail-unordered-2
+
+(*
+ * Result: Sometimes
+ *
+ * Demonstrate that a failing cmpxchg() operation does not act as either
+ * an acquire release operation. (In contrast, a successful cmpxchg()
+ * does act as both an acquire and a release operation.)
+ *)
+
+{}
+
+P0(int *x, int *y)
+{
+ int r1;
+
+ WRITE_ONCE(*x, 1);
+ r1 = cmpxchg(y, 0, 1);
+}
+
+P1(int *x, int *y)
+{
+ int r1;
+ int r2;
+
+ r1 = cmpxchg(y, 0, 1);
+ r2 = READ_ONCE(*x);
+}
+
+exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0)
diff --git a/Documentation/litmus-tests/locking/DCL-broken.litmus b/Documentation/litmus-tests/locking/DCL-broken.litmus
new file mode 100644
index 000000000000..bfb7ba4316d6
--- /dev/null
+++ b/Documentation/litmus-tests/locking/DCL-broken.litmus
@@ -0,0 +1,54 @@
+C DCL-broken
+
+(*
+ * Result: Sometimes
+ *
+ * This litmus test demonstrates more than just locking is required to
+ * correctly implement double-checked locking.
+ *)
+
+{
+ int flag;
+ int data;
+}
+
+P0(int *flag, int *data, spinlock_t *lck)
+{
+ int r0;
+ int r1;
+ int r2;
+
+ r0 = READ_ONCE(*flag);
+ if (r0 == 0) {
+ spin_lock(lck);
+ r1 = READ_ONCE(*flag);
+ if (r1 == 0) {
+ WRITE_ONCE(*data, 1);
+ WRITE_ONCE(*flag, 1);
+ }
+ spin_unlock(lck);
+ }
+ r2 = READ_ONCE(*data);
+}
+
+P1(int *flag, int *data, spinlock_t *lck)
+{
+ int r0;
+ int r1;
+ int r2;
+
+ r0 = READ_ONCE(*flag);
+ if (r0 == 0) {
+ spin_lock(lck);
+ r1 = READ_ONCE(*flag);
+ if (r1 == 0) {
+ WRITE_ONCE(*data, 1);
+ WRITE_ONCE(*flag, 1);
+ }
+ spin_unlock(lck);
+ }
+ r2 = READ_ONCE(*data);
+}
+
+locations [flag;data;0:r0;0:r1;1:r0;1:r1]
+exists (0:r2=0 \/ 1:r2=0)
diff --git a/Documentation/litmus-tests/locking/DCL-fixed.litmus b/Documentation/litmus-tests/locking/DCL-fixed.litmus
new file mode 100644
index 000000000000..d1b60bcb0c8f
--- /dev/null
+++ b/Documentation/litmus-tests/locking/DCL-fixed.litmus
@@ -0,0 +1,55 @@
+C DCL-fixed
+
+(*
+ * Result: Never
+ *
+ * This litmus test demonstrates that double-checked locking can be
+ * reliable given proper use of smp_load_acquire() and smp_store_release()
+ * in addition to the locking.
+ *)
+
+{
+ int flag;
+ int data;
+}
+
+P0(int *flag, int *data, spinlock_t *lck)
+{
+ int r0;
+ int r1;
+ int r2;
+
+ r0 = smp_load_acquire(flag);
+ if (r0 == 0) {
+ spin_lock(lck);
+ r1 = READ_ONCE(*flag);
+ if (r1 == 0) {
+ WRITE_ONCE(*data, 1);
+ smp_store_release(flag, 1);
+ }
+ spin_unlock(lck);
+ }
+ r2 = READ_ONCE(*data);
+}
+
+P1(int *flag, int *data, spinlock_t *lck)
+{
+ int r0;
+ int r1;
+ int r2;
+
+ r0 = smp_load_acquire(flag);
+ if (r0 == 0) {
+ spin_lock(lck);
+ r1 = READ_ONCE(*flag);
+ if (r1 == 0) {
+ WRITE_ONCE(*data, 1);
+ smp_store_release(flag, 1);
+ }
+ spin_unlock(lck);
+ }
+ r2 = READ_ONCE(*data);
+}
+
+locations [flag;data;0:r0;0:r1;1:r0;1:r1]
+exists (0:r2=0 \/ 1:r2=0)
diff --git a/Documentation/litmus-tests/locking/RM-broken.litmus b/Documentation/litmus-tests/locking/RM-broken.litmus
new file mode 100644
index 000000000000..b7ef30cedfe5
--- /dev/null
+++ b/Documentation/litmus-tests/locking/RM-broken.litmus
@@ -0,0 +1,41 @@
+C RM-broken
+
+(*
+ * Result: DEADLOCK
+ *
+ * This litmus test demonstrates that the old "roach motel" approach
+ * to locking, where code can be freely moved into critical sections,
+ * cannot be used in the Linux kernel.
+ *)
+
+{
+ int x;
+ atomic_t y;
+}
+
+P0(int *x, atomic_t *y, spinlock_t *lck)
+{
+ int r2;
+
+ spin_lock(lck);
+ r2 = atomic_inc_return(y);
+ WRITE_ONCE(*x, 1);
+ spin_unlock(lck);
+}
+
+P1(int *x, atomic_t *y, spinlock_t *lck)
+{
+ int r0;
+ int r1;
+ int r2;
+
+ spin_lock(lck);
+ r0 = READ_ONCE(*x);
+ r1 = READ_ONCE(*x);
+ r2 = atomic_inc_return(y);
+ spin_unlock(lck);
+}
+
+locations [x;0:r2;1:r0;1:r1;1:r2]
+filter (1:r0=0 /\ 1:r1=1)
+exists (1:r2=1)
diff --git a/Documentation/litmus-tests/locking/RM-fixed.litmus b/Documentation/litmus-tests/locking/RM-fixed.litmus
new file mode 100644
index 000000000000..b62817559616
--- /dev/null
+++ b/Documentation/litmus-tests/locking/RM-fixed.litmus
@@ -0,0 +1,41 @@
+C RM-fixed
+
+(*
+ * Result: Never
+ *
+ * This litmus test demonstrates that the old "roach motel" approach
+ * to locking, where code can be freely moved into critical sections,
+ * cannot be used in the Linux kernel.
+ *)
+
+{
+ int x;
+ atomic_t y;
+}
+
+P0(int *x, atomic_t *y, spinlock_t *lck)
+{
+ int r2;
+
+ spin_lock(lck);
+ r2 = atomic_inc_return(y);
+ WRITE_ONCE(*x, 1);
+ spin_unlock(lck);
+}
+
+P1(int *x, atomic_t *y, spinlock_t *lck)
+{
+ int r0;
+ int r1;
+ int r2;
+
+ r0 = READ_ONCE(*x);
+ r1 = READ_ONCE(*x);
+ spin_lock(lck);
+ r2 = atomic_inc_return(y);
+ spin_unlock(lck);
+}
+
+locations [x;0:r2;1:r0;1:r1;1:r2]
+filter (1:r0=0 /\ 1:r1=1)
+exists (1:r2=1)
diff --git a/Documentation/livepatch/callbacks.rst b/Documentation/livepatch/callbacks.rst
index 470944aa8658..914445784ce4 100644
--- a/Documentation/livepatch/callbacks.rst
+++ b/Documentation/livepatch/callbacks.rst
@@ -110,7 +110,7 @@ Global data update
------------------
A pre-patch callback can be useful to update a global variable. For
-example, 75ff39ccc1bd ("tcp: make challenge acks less predictable")
+example, commit 75ff39ccc1bd ("tcp: make challenge acks less predictable")
changes a global sysctl, as well as patches the tcp_send_challenge_ack()
function.
@@ -126,7 +126,7 @@ Although __init and probe functions are not directly livepatch-able, it
may be possible to implement similar updates via pre/post-patch
callbacks.
-The commit ``48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST")`` change the way that
+The commit 48900cb6af42 ("virtio-net: drop NETIF_F_FRAGLIST") change the way that
virtnet_probe() initialized its driver's net_device features. A
pre/post-patch callback could iterate over all such devices, making a
similar change to their hw_features value. (Client functions of the
diff --git a/Documentation/livepatch/livepatch.rst b/Documentation/livepatch/livepatch.rst
index 68e3651e8af9..acb90164929e 100644
--- a/Documentation/livepatch/livepatch.rst
+++ b/Documentation/livepatch/livepatch.rst
@@ -50,7 +50,7 @@ some limitations, see below.
3. Consistency model
====================
-Functions are there for a reason. They take some input parameters, get or
+Functions are there for a reason. They take some input parameters, acquire or
release locks, read, process, and even write some data in a defined way,
have return values. In other words, each function has a defined semantic.
diff --git a/Documentation/livepatch/module-elf-format.rst b/Documentation/livepatch/module-elf-format.rst
index 7347638895a0..5d48778d4dfc 100644
--- a/Documentation/livepatch/module-elf-format.rst
+++ b/Documentation/livepatch/module-elf-format.rst
@@ -1,8 +1,8 @@
===========================
-Livepatch module Elf format
+Livepatch module ELF format
===========================
-This document outlines the Elf format requirements that livepatch modules must follow.
+This document outlines the ELF format requirements that livepatch modules must follow.
.. Table of Contents
@@ -20,17 +20,17 @@ code. So, instead of duplicating code and re-implementing what the module
loader can already do, livepatch leverages existing code in the module
loader to perform the all the arch-specific relocation work. Specifically,
livepatch reuses the apply_relocate_add() function in the module loader to
-write relocations. The patch module Elf format described in this document
+write relocations. The patch module ELF format described in this document
enables livepatch to be able to do this. The hope is that this will make
livepatch more easily portable to other architectures and reduce the amount
of arch-specific code required to port livepatch to a particular
architecture.
Since apply_relocate_add() requires access to a module's section header
-table, symbol table, and relocation section indices, Elf information is
+table, symbol table, and relocation section indices, ELF information is
preserved for livepatch modules (see section 5). Livepatch manages its own
relocation sections and symbols, which are described in this document. The
-Elf constants used to mark livepatch symbols and relocation sections were
+ELF constants used to mark livepatch symbols and relocation sections were
selected from OS-specific ranges according to the definitions from glibc.
Why does livepatch need to write its own relocations?
@@ -43,7 +43,7 @@ reject the livepatch module. Furthermore, we cannot apply relocations that
affect modules not yet loaded at patch module load time (e.g. a patch to a
driver that is not loaded). Formerly, livepatch solved this problem by
embedding special "dynrela" (dynamic rela) sections in the resulting patch
-module Elf output. Using these dynrela sections, livepatch could resolve
+module ELF output. Using these dynrela sections, livepatch could resolve
symbols while taking into account its scope and what module the symbol
belongs to, and then manually apply the dynamic relocations. However this
approach required livepatch to supply arch-specific code in order to write
@@ -80,7 +80,7 @@ Example:
3. Livepatch relocation sections
================================
-A livepatch module manages its own Elf relocation sections to apply
+A livepatch module manages its own ELF relocation sections to apply
relocations to modules as well as to the kernel (vmlinux) at the
appropriate time. For example, if a patch module patches a driver that is
not currently loaded, livepatch will apply the corresponding livepatch
@@ -95,7 +95,7 @@ also possible for a livepatch module to have no livepatch relocation
sections, as in the case of the sample livepatch module (see
samples/livepatch).
-Since Elf information is preserved for livepatch modules (see Section 5), a
+Since ELF information is preserved for livepatch modules (see Section 5), a
livepatch relocation section can be applied simply by passing in the
appropriate section index to apply_relocate_add(), which then uses it to
access the relocation section and apply the relocations.
@@ -217,16 +217,19 @@ livepatch relocation section refer to their respective symbols with their symbol
indices, and the original symbol indices (and thus the symtab ordering) must be
preserved in order for apply_relocate_add() to find the right symbol.
-For example, take this particular rela from a livepatch module:::
+For example, take this particular rela from a livepatch module::
Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4
- This rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol index is encoded
- in 'Info'. Here its symbol index is 0x5e, which is 94 in decimal, which refers to the
- symbol index 94.
- And in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol:
+This rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol
+index is encoded in 'Info'. Here its symbol index is 0x5e, which is 94 in
+decimal, which refers to the symbol index 94.
+
+And in this patch module's corresponding symbol table, symbol index 94 refers
+to that very symbol::
+
[ snip ]
94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0
[ snip ]
@@ -291,19 +294,12 @@ Examples:
Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
"OS" means OS-specific.
-5. Symbol table and Elf section access
+5. Symbol table and ELF section access
======================================
A livepatch module's symbol table is accessible through module->symtab.
Since apply_relocate_add() requires access to a module's section headers,
-symbol table, and relocation section indices, Elf information is preserved for
+symbol table, and relocation section indices, ELF information is preserved for
livepatch modules and is made accessible by the module loader through
-module->klp_info, which is a klp_modinfo struct. When a livepatch module loads,
-this struct is filled in by the module loader. Its fields are documented below::
-
- struct klp_modinfo {
- Elf_Ehdr hdr; /* Elf header */
- Elf_Shdr *sechdrs; /* Section header table */
- char *secstrings; /* String table for the section headers */
- unsigned int symndx; /* The symbol table section index */
- };
+module->klp_info, which is a :c:type:`klp_modinfo` struct. When a livepatch module
+loads, this struct is filled in by the module loader.
diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst
index 67459d2ca2af..8d950f3ffedd 100644
--- a/Documentation/livepatch/reliable-stacktrace.rst
+++ b/Documentation/livepatch/reliable-stacktrace.rst
@@ -40,7 +40,7 @@ Principally, the reliable stacktrace function must ensure that either:
.. note::
In some cases it is legitimate to omit specific functions from the trace,
but all other functions must be reported. These cases are described in
- futher detail below.
+ further detail below.
Secondly, the reliable stacktrace function must be robust to cases where
the stack or other unwind state is corrupt or otherwise unreliable. The
@@ -183,7 +183,7 @@ trampoline or return trampoline. For example, considering the x86_64
.. code-block:: none
SYM_CODE_START(return_to_handler)
- UNWIND_HINT_EMPTY
+ UNWIND_HINT_UNDEFINED
subq $24, %rsp
/* Save the return values */
diff --git a/Documentation/locking/hwspinlock.rst b/Documentation/locking/hwspinlock.rst
index 6f03713b7003..a737c702a7d1 100644
--- a/Documentation/locking/hwspinlock.rst
+++ b/Documentation/locking/hwspinlock.rst
@@ -40,17 +40,6 @@ User API
::
- struct hwspinlock *hwspin_lock_request(void);
-
-Dynamically assign an hwspinlock and return its address, or NULL
-in case an unused hwspinlock isn't available. Users of this
-API will usually want to communicate the lock's id to the remote core
-before it can be used to achieve synchronization.
-
-Should be called from a process context (might sleep).
-
-::
-
struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
Assign a specific hwspinlock id and return its address, or NULL
@@ -87,6 +76,17 @@ Should be called from a process context (might sleep).
::
+ int hwspin_lock_bust(struct hwspinlock *hwlock, unsigned int id);
+
+After verifying the owner of the hwspinlock, release a previously acquired
+hwspinlock; returns 0 on success, or an appropriate error code on failure
+(e.g. -EOPNOTSUPP if the bust operation is not defined for the specific
+hwspinlock).
+
+Should be called from a process context (might sleep).
+
+::
+
int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int timeout);
Lock a previously-assigned hwspinlock with a timeout limit (specified in
@@ -301,17 +301,6 @@ The caller should **never** unlock an hwspinlock which is already unlocked.
Doing so is considered a bug (there is no protection against this).
This function will never sleep.
-::
-
- int hwspin_lock_get_id(struct hwspinlock *hwlock);
-
-Retrieve id number of a given hwspinlock. This is needed when an
-hwspinlock is dynamically assigned: before it can be used to achieve
-mutual exclusion with a remote cpu, the id number should be communicated
-to the remote task with which we want to synchronize.
-
-Returns the hwspinlock id number, or -EINVAL if hwlock is null.
-
Typical usage
=============
@@ -320,40 +309,7 @@ Typical usage
#include <linux/hwspinlock.h>
#include <linux/err.h>
- int hwspinlock_example1(void)
- {
- struct hwspinlock *hwlock;
- int ret;
-
- /* dynamically assign a hwspinlock */
- hwlock = hwspin_lock_request();
- if (!hwlock)
- ...
-
- id = hwspin_lock_get_id(hwlock);
- /* probably need to communicate id to a remote processor now */
-
- /* take the lock, spin for 1 sec if it's already taken */
- ret = hwspin_lock_timeout(hwlock, 1000);
- if (ret)
- ...
-
- /*
- * we took the lock, do our thing now, but do NOT sleep
- */
-
- /* release the lock */
- hwspin_unlock(hwlock);
-
- /* free the lock */
- ret = hwspin_lock_free(hwlock);
- if (ret)
- ...
-
- return ret;
- }
-
- int hwspinlock_example2(void)
+ int hwspinlock_example(void)
{
struct hwspinlock *hwlock;
int ret;
diff --git a/Documentation/locking/index.rst b/Documentation/locking/index.rst
index 7003bd5aeff4..6a9ea96c8bcb 100644
--- a/Documentation/locking/index.rst
+++ b/Documentation/locking/index.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
=======
-locking
+Locking
=======
.. toctree::
diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst
index 82f36cab61bd..56b90eea2731 100644
--- a/Documentation/locking/lockdep-design.rst
+++ b/Documentation/locking/lockdep-design.rst
@@ -29,7 +29,7 @@ the validator will shoot a splat if incorrect.
A lock-class's behavior is constructed by its instances collectively:
when the first instance of a lock-class is used after bootup the class
gets registered, then all (subsequent) instances will be mapped to the
-class and hence their usages and dependecies will contribute to those of
+class and hence their usages and dependencies will contribute to those of
the class. A lock-class does not go away when a lock instance does, but
it can be removed if the memory space of the lock class (static or
dynamic) is reclaimed, this happens for example when a module is
@@ -105,7 +105,7 @@ exact case is for the lock as of the reporting time.
+--------------+-------------+--------------+
The character '-' suggests irq is disabled because if otherwise the
-charactor '?' would have been shown instead. Similar deduction can be
+character '?' would have been shown instead. Similar deduction can be
applied for '+' too.
Unused locks (e.g., mutexes) cannot be part of the cause of an error.
diff --git a/Documentation/locking/locktorture.rst b/Documentation/locking/locktorture.rst
index dfaf9fc883f4..3e763f77a620 100644
--- a/Documentation/locking/locktorture.rst
+++ b/Documentation/locking/locktorture.rst
@@ -5,7 +5,7 @@ Kernel Lock Torture Test Operation
CONFIG_LOCK_TORTURE_TEST
========================
-The CONFIG LOCK_TORTURE_TEST config option provides a kernel module
+The CONFIG_LOCK_TORTURE_TEST config option provides a kernel module
that runs torture tests on core kernel locking primitives. The kernel
module, 'locktorture', may be built after the fact on the running
kernel to be tested, if desired. The tests periodically output status
@@ -67,7 +67,7 @@ torture_type
- "rtmutex_lock":
rtmutex_lock() and rtmutex_unlock() pairs.
- Kernel must have CONFIG_RT_MUTEX=y.
+ Kernel must have CONFIG_RT_MUTEXES=y.
- "rwsem_lock":
read/write down() and up() semaphore pairs.
@@ -113,7 +113,7 @@ stutter
without pausing.
shuffle_interval
- The number of seconds to keep the test threads affinitied
+ The number of seconds to keep the test threads affinitized
to a particular subset of the CPUs, defaults to 3 seconds.
Used in conjunction with test_no_idle_hz.
diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst
index 9933faad4771..37b6a5670c2f 100644
--- a/Documentation/locking/locktypes.rst
+++ b/Documentation/locking/locktypes.rst
@@ -204,6 +204,27 @@ per-CPU data structures on a non PREEMPT_RT kernel.
local_lock is not suitable to protect against preemption or interrupts on a
PREEMPT_RT kernel due to the PREEMPT_RT specific spinlock_t semantics.
+CPU local scope and bottom-half
+-------------------------------
+
+Per-CPU variables that are accessed only in softirq context should not rely on
+the assumption that this context is implicitly protected due to being
+non-preemptible. In a PREEMPT_RT kernel, softirq context is preemptible, and
+synchronizing every bottom-half-disabled section via implicit context results
+in an implicit per-CPU "big kernel lock."
+
+A local_lock_t together with local_lock_nested_bh() and
+local_unlock_nested_bh() for locking operations help to identify the locking
+scope.
+
+When lockdep is enabled, these functions verify that data structure access
+occurs within softirq context.
+Unlike local_lock(), local_unlock_nested_bh() does not disable preemption and
+does not add overhead when used without lockdep.
+
+On a PREEMPT_RT kernel, local_lock_t behaves as a real lock and
+local_unlock_nested_bh() serializes access to the data structure, which allows
+removal of serialization via local_bh_disable().
raw_spinlock_t and spinlock_t
=============================
@@ -500,7 +521,7 @@ caveats also apply to bit spinlocks.
Some bit spinlocks are replaced with regular spinlock_t for PREEMPT_RT
using conditional (#ifdef'ed) code changes at the usage site. In contrast,
usage-site changes are not needed for the spinlock_t substitution.
-Instead, conditionals in header files and the core locking implemementation
+Instead, conditionals in header files and the core locking implementation
enable the compiler to do the substitution transparently.
diff --git a/Documentation/locking/mutex-design.rst b/Documentation/locking/mutex-design.rst
index 78540cd7f54b..7c30b4aa5e28 100644
--- a/Documentation/locking/mutex-design.rst
+++ b/Documentation/locking/mutex-design.rst
@@ -101,6 +101,24 @@ features that make lock debugging easier and faster:
- Detects multi-task circular deadlocks and prints out all affected
locks and tasks (and only those tasks).
+Mutexes - and most other sleeping locks like rwsems - do not provide an
+implicit reference for the memory they occupy, which reference is released
+with mutex_unlock().
+
+[ This is in contrast with spin_unlock() [or completion_done()], which
+ APIs can be used to guarantee that the memory is not touched by the
+ lock implementation after spin_unlock()/completion_done() releases
+ the lock. ]
+
+mutex_unlock() may access the mutex structure even after it has internally
+released the lock already - so it's not safe for another context to
+acquire the mutex and assume that the mutex_unlock() context is not using
+the structure anymore.
+
+The mutex user must ensure that the mutex is not destroyed while a
+release operation is still in progress - in other words, callers of
+mutex_unlock() must ensure that the mutex stays alive until mutex_unlock()
+has returned.
Interfaces
----------
diff --git a/Documentation/locking/percpu-rw-semaphore.rst b/Documentation/locking/percpu-rw-semaphore.rst
index 247de6410855..a105bf2dd812 100644
--- a/Documentation/locking/percpu-rw-semaphore.rst
+++ b/Documentation/locking/percpu-rw-semaphore.rst
@@ -16,8 +16,8 @@ writing is very expensive, it calls synchronize_rcu() that can take
hundreds of milliseconds.
The lock is declared with "struct percpu_rw_semaphore" type.
-The lock is initialized percpu_init_rwsem, it returns 0 on success and
--ENOMEM on allocation failure.
+The lock is initialized with percpu_init_rwsem, it returns 0 on success
+and -ENOMEM on allocation failure.
The lock must be freed with percpu_free_rwsem to avoid memory leak.
The lock is locked for read with percpu_down_read, percpu_up_read and
diff --git a/Documentation/locking/seqlock.rst b/Documentation/locking/seqlock.rst
index bfda1a5fecad..9899871d3d9a 100644
--- a/Documentation/locking/seqlock.rst
+++ b/Documentation/locking/seqlock.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0
+
======================================
Sequence counters and sequential locks
======================================
@@ -153,7 +155,7 @@ Use seqcount_latch_t when the write side sections cannot be protected
from interruption by readers. This is typically the case when the read
side can be invoked from NMI handlers.
-Check `raw_write_seqcount_latch()` for more information.
+Check `write_seqcount_latch()` for more information.
.. _seqlock_t:
@@ -218,13 +220,14 @@ Read path, three categories:
according to a passed marker. This is used to avoid lockless readers
starvation (too much retry loops) in case of a sharp spike in write
activity. First, a lockless read is tried (even marker passed). If
- that trial fails (odd sequence counter is returned, which is used as
- the next iteration marker), the lockless read is transformed to a
- full locking read and no retry loop is necessary::
+ that trial fails (sequence counter doesn't match), make the marker
+ odd for the next iteration, the lockless read is transformed to a
+ full locking read and no retry loop is necessary, for example::
/* marker; even initialization */
- int seq = 0;
+ int seq = 1;
do {
+ seq++; /* 2 on the 1st/lockless path, otherwise odd */
read_seqbegin_or_lock(&foo_seqlock, &seq);
/* ... [[read-side critical section]] ... */
diff --git a/Documentation/loongarch/features.rst b/Documentation/loongarch/features.rst
deleted file mode 100644
index ebacade3ea45..000000000000
--- a/Documentation/loongarch/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features loongarch
diff --git a/Documentation/loongarch/index.rst b/Documentation/loongarch/index.rst
deleted file mode 100644
index aaba648db907..000000000000
--- a/Documentation/loongarch/index.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-======================
-LoongArch Architecture
-======================
-
-.. toctree::
- :maxdepth: 2
- :numbered:
-
- introduction
- irq-chip-model
-
- features
-
-.. only:: subproject and html
-
- Indices
- =======
-
- * :ref:`genindex`
diff --git a/Documentation/loongarch/introduction.rst b/Documentation/loongarch/introduction.rst
deleted file mode 100644
index 6c9160c4e9be..000000000000
--- a/Documentation/loongarch/introduction.rst
+++ /dev/null
@@ -1,390 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=========================
-Introduction to LoongArch
-=========================
-
-LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V. There are
-currently 3 variants: a reduced 32-bit version (LA32R), a standard 32-bit
-version (LA32S) and a 64-bit version (LA64). There are 4 privilege levels
-(PLVs) defined in LoongArch: PLV0~PLV3, from high to low. Kernel runs at PLV0
-while applications run at PLV3. This document introduces the registers, basic
-instruction set, virtual memory and some other topics of LoongArch.
-
-Registers
-=========
-
-LoongArch registers include general purpose registers (GPRs), floating point
-registers (FPRs), vector registers (VRs) and control status registers (CSRs)
-used in privileged mode (PLV0).
-
-GPRs
-----
-
-LoongArch has 32 GPRs ( ``$r0`` ~ ``$r31`` ); each one is 32-bit wide in LA32
-and 64-bit wide in LA64. ``$r0`` is hard-wired to zero, and the other registers
-are not architecturally special. (Except ``$r1``, which is hard-wired as the
-link register of the BL instruction.)
-
-The kernel uses a variant of the LoongArch register convention, as described in
-the LoongArch ELF psABI spec, in :ref:`References <loongarch-references>`:
-
-================= =============== =================== ============
-Name Alias Usage Preserved
- across calls
-================= =============== =================== ============
-``$r0`` ``$zero`` Constant zero Unused
-``$r1`` ``$ra`` Return address No
-``$r2`` ``$tp`` TLS/Thread pointer Unused
-``$r3`` ``$sp`` Stack pointer Yes
-``$r4``-``$r11`` ``$a0``-``$a7`` Argument registers No
-``$r4``-``$r5`` ``$v0``-``$v1`` Return value No
-``$r12``-``$r20`` ``$t0``-``$t8`` Temp registers No
-``$r21`` ``$u0`` Percpu base address Unused
-``$r22`` ``$fp`` Frame pointer Yes
-``$r23``-``$r31`` ``$s0``-``$s8`` Static registers Yes
-================= =============== =================== ============
-
-.. Note::
- The register ``$r21`` is reserved in the ELF psABI, but used by the Linux
- kernel for storing the percpu base address. It normally has no ABI name,
- but is called ``$u0`` in the kernel. You may also see ``$v0`` or ``$v1``
- in some old code,however they are deprecated aliases of ``$a0`` and ``$a1``
- respectively.
-
-FPRs
-----
-
-LoongArch has 32 FPRs ( ``$f0`` ~ ``$f31`` ) when FPU is present. Each one is
-64-bit wide on the LA64 cores.
-
-The floating-point register convention is the same as described in the
-LoongArch ELF psABI spec:
-
-================= ================== =================== ============
-Name Alias Usage Preserved
- across calls
-================= ================== =================== ============
-``$f0``-``$f7`` ``$fa0``-``$fa7`` Argument registers No
-``$f0``-``$f1`` ``$fv0``-``$fv1`` Return value No
-``$f8``-``$f23`` ``$ft0``-``$ft15`` Temp registers No
-``$f24``-``$f31`` ``$fs0``-``$fs7`` Static registers Yes
-================= ================== =================== ============
-
-.. Note::
- You may see ``$fv0`` or ``$fv1`` in some old code, however they are
- deprecated aliases of ``$fa0`` and ``$fa1`` respectively.
-
-VRs
-----
-
-There are currently 2 vector extensions to LoongArch:
-
-- LSX (Loongson SIMD eXtension) with 128-bit vectors,
-- LASX (Loongson Advanced SIMD eXtension) with 256-bit vectors.
-
-LSX brings ``$v0`` ~ ``$v31`` while LASX brings ``$x0`` ~ ``$x31`` as the vector
-registers.
-
-The VRs overlap with FPRs: for example, on a core implementing LSX and LASX,
-the lower 128 bits of ``$x0`` is shared with ``$v0``, and the lower 64 bits of
-``$v0`` is shared with ``$f0``; same with all other VRs.
-
-CSRs
-----
-
-CSRs can only be accessed from privileged mode (PLV0):
-
-================= ===================================== ==============
-Address Full Name Abbrev Name
-================= ===================================== ==============
-0x0 Current Mode Information CRMD
-0x1 Pre-exception Mode Information PRMD
-0x2 Extension Unit Enable EUEN
-0x3 Miscellaneous Control MISC
-0x4 Exception Configuration ECFG
-0x5 Exception Status ESTAT
-0x6 Exception Return Address ERA
-0x7 Bad (Faulting) Virtual Address BADV
-0x8 Bad (Faulting) Instruction Word BADI
-0xC Exception Entrypoint Address EENTRY
-0x10 TLB Index TLBIDX
-0x11 TLB Entry High-order Bits TLBEHI
-0x12 TLB Entry Low-order Bits 0 TLBELO0
-0x13 TLB Entry Low-order Bits 1 TLBELO1
-0x18 Address Space Identifier ASID
-0x19 Page Global Directory Address for PGDL
- Lower-half Address Space
-0x1A Page Global Directory Address for PGDH
- Higher-half Address Space
-0x1B Page Global Directory Address PGD
-0x1C Page Walk Control for Lower- PWCL
- half Address Space
-0x1D Page Walk Control for Higher- PWCH
- half Address Space
-0x1E STLB Page Size STLBPS
-0x1F Reduced Virtual Address Configuration RVACFG
-0x20 CPU Identifier CPUID
-0x21 Privileged Resource Configuration 1 PRCFG1
-0x22 Privileged Resource Configuration 2 PRCFG2
-0x23 Privileged Resource Configuration 3 PRCFG3
-0x30+n (0≤n≤15) Saved Data register SAVEn
-0x40 Timer Identifier TID
-0x41 Timer Configuration TCFG
-0x42 Timer Value TVAL
-0x43 Compensation of Timer Count CNTC
-0x44 Timer Interrupt Clearing TICLR
-0x60 LLBit Control LLBCTL
-0x80 Implementation-specific Control 1 IMPCTL1
-0x81 Implementation-specific Control 2 IMPCTL2
-0x88 TLB Refill Exception Entrypoint TLBRENTRY
- Address
-0x89 TLB Refill Exception BAD (Faulting) TLBRBADV
- Virtual Address
-0x8A TLB Refill Exception Return Address TLBRERA
-0x8B TLB Refill Exception Saved Data TLBRSAVE
- Register
-0x8C TLB Refill Exception Entry Low-order TLBRELO0
- Bits 0
-0x8D TLB Refill Exception Entry Low-order TLBRELO1
- Bits 1
-0x8E TLB Refill Exception Entry High-order TLBEHI
- Bits
-0x8F TLB Refill Exception Pre-exception TLBRPRMD
- Mode Information
-0x90 Machine Error Control MERRCTL
-0x91 Machine Error Information 1 MERRINFO1
-0x92 Machine Error Information 2 MERRINFO2
-0x93 Machine Error Exception Entrypoint MERRENTRY
- Address
-0x94 Machine Error Exception Return MERRERA
- Address
-0x95 Machine Error Exception Saved Data MERRSAVE
- Register
-0x98 Cache TAGs CTAG
-0x180+n (0≤n≤3) Direct Mapping Configuration Window n DMWn
-0x200+2n (0≤n≤31) Performance Monitor Configuration n PMCFGn
-0x201+2n (0≤n≤31) Performance Monitor Overall Counter n PMCNTn
-0x300 Memory Load/Store WatchPoint MWPC
- Overall Control
-0x301 Memory Load/Store WatchPoint MWPS
- Overall Status
-0x310+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG1
- Configuration 1
-0x311+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG2
- Configuration 2
-0x312+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG3
- Configuration 3
-0x313+8n (0≤n≤7) Memory Load/Store WatchPoint n MWPnCFG4
- Configuration 4
-0x380 Instruction Fetch WatchPoint FWPC
- Overall Control
-0x381 Instruction Fetch WatchPoint FWPS
- Overall Status
-0x390+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG1
- Configuration 1
-0x391+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG2
- Configuration 2
-0x392+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG3
- Configuration 3
-0x393+8n (0≤n≤7) Instruction Fetch WatchPoint n FWPnCFG4
- Configuration 4
-0x500 Debug Register DBG
-0x501 Debug Exception Return Address DERA
-0x502 Debug Exception Saved Data Register DSAVE
-================= ===================================== ==============
-
-ERA, TLBRERA, MERRERA and DERA are sometimes also known as EPC, TLBREPC, MERREPC
-and DEPC respectively.
-
-Basic Instruction Set
-=====================
-
-Instruction formats
--------------------
-
-LoongArch instructions are 32 bits wide, belonging to 9 basic instruction
-formats (and variants of them):
-
-=========== ==========================
-Format name Composition
-=========== ==========================
-2R Opcode + Rj + Rd
-3R Opcode + Rk + Rj + Rd
-4R Opcode + Ra + Rk + Rj + Rd
-2RI8 Opcode + I8 + Rj + Rd
-2RI12 Opcode + I12 + Rj + Rd
-2RI14 Opcode + I14 + Rj + Rd
-2RI16 Opcode + I16 + Rj + Rd
-1RI21 Opcode + I21L + Rj + I21H
-I26 Opcode + I26L + I26H
-=========== ==========================
-
-Rd is the destination register operand, while Rj, Rk and Ra ("a" stands for
-"additional") are the source register operands. I8/I12/I14/I16/I21/I26 are
-immediate operands of respective width. The longer I21 and I26 are stored
-in separate higher and lower parts in the instruction word, denoted by the "L"
-and "H" suffixes.
-
-List of Instructions
---------------------
-
-For brevity, only instruction names (mnemonics) are listed here; please see the
-:ref:`References <loongarch-references>` for details.
-
-
-1. Arithmetic Instructions::
-
- ADD.W SUB.W ADDI.W ADD.D SUB.D ADDI.D
- SLT SLTU SLTI SLTUI
- AND OR NOR XOR ANDN ORN ANDI ORI XORI
- MUL.W MULH.W MULH.WU DIV.W DIV.WU MOD.W MOD.WU
- MUL.D MULH.D MULH.DU DIV.D DIV.DU MOD.D MOD.DU
- PCADDI PCADDU12I PCADDU18I
- LU12I.W LU32I.D LU52I.D ADDU16I.D
-
-2. Bit-shift Instructions::
-
- SLL.W SRL.W SRA.W ROTR.W SLLI.W SRLI.W SRAI.W ROTRI.W
- SLL.D SRL.D SRA.D ROTR.D SLLI.D SRLI.D SRAI.D ROTRI.D
-
-3. Bit-manipulation Instructions::
-
- EXT.W.B EXT.W.H CLO.W CLO.D SLZ.W CLZ.D CTO.W CTO.D CTZ.W CTZ.D
- BYTEPICK.W BYTEPICK.D BSTRINS.W BSTRINS.D BSTRPICK.W BSTRPICK.D
- REVB.2H REVB.4H REVB.2W REVB.D REVH.2W REVH.D BITREV.4B BITREV.8B BITREV.W BITREV.D
- MASKEQZ MASKNEZ
-
-4. Branch Instructions::
-
- BEQ BNE BLT BGE BLTU BGEU BEQZ BNEZ B BL JIRL
-
-5. Load/Store Instructions::
-
- LD.B LD.BU LD.H LD.HU LD.W LD.WU LD.D ST.B ST.H ST.W ST.D
- LDX.B LDX.BU LDX.H LDX.HU LDX.W LDX.WU LDX.D STX.B STX.H STX.W STX.D
- LDPTR.W LDPTR.D STPTR.W STPTR.D
- PRELD PRELDX
-
-6. Atomic Operation Instructions::
-
- LL.W SC.W LL.D SC.D
- AMSWAP.W AMSWAP.D AMADD.W AMADD.D AMAND.W AMAND.D AMOR.W AMOR.D AMXOR.W AMXOR.D
- AMMAX.W AMMAX.D AMMIN.W AMMIN.D
-
-7. Barrier Instructions::
-
- IBAR DBAR
-
-8. Special Instructions::
-
- SYSCALL BREAK CPUCFG NOP IDLE ERTN(ERET) DBCL(DBGCALL) RDTIMEL.W RDTIMEH.W RDTIME.D
- ASRTLE.D ASRTGT.D
-
-9. Privileged Instructions::
-
- CSRRD CSRWR CSRXCHG
- IOCSRRD.B IOCSRRD.H IOCSRRD.W IOCSRRD.D IOCSRWR.B IOCSRWR.H IOCSRWR.W IOCSRWR.D
- CACOP TLBP(TLBSRCH) TLBRD TLBWR TLBFILL TLBCLR TLBFLUSH INVTLB LDDIR LDPTE
-
-Virtual Memory
-==============
-
-LoongArch supports direct-mapped virtual memory and page-mapped virtual memory.
-
-Direct-mapped virtual memory is configured by CSR.DMWn (n=0~3), it has a simple
-relationship between virtual address (VA) and physical address (PA)::
-
- VA = PA + FixedOffset
-
-Page-mapped virtual memory has arbitrary relationship between VA and PA, which
-is recorded in TLB and page tables. LoongArch's TLB includes a fully-associative
-MTLB (Multiple Page Size TLB) and set-associative STLB (Single Page Size TLB).
-
-By default, the whole virtual address space of LA32 is configured like this:
-
-============ =========================== =============================
-Name Address Range Attributes
-============ =========================== =============================
-``UVRANGE`` ``0x00000000 - 0x7FFFFFFF`` Page-mapped, Cached, PLV0~3
-``KPRANGE0`` ``0x80000000 - 0x9FFFFFFF`` Direct-mapped, Uncached, PLV0
-``KPRANGE1`` ``0xA0000000 - 0xBFFFFFFF`` Direct-mapped, Cached, PLV0
-``KVRANGE`` ``0xC0000000 - 0xFFFFFFFF`` Page-mapped, Cached, PLV0
-============ =========================== =============================
-
-User mode (PLV3) can only access UVRANGE. For direct-mapped KPRANGE0 and
-KPRANGE1, PA is equal to VA with bit30~31 cleared. For example, the uncached
-direct-mapped VA of 0x00001000 is 0x80001000, and the cached direct-mapped
-VA of 0x00001000 is 0xA0001000.
-
-By default, the whole virtual address space of LA64 is configured like this:
-
-============ ====================== ======================================
-Name Address Range Attributes
-============ ====================== ======================================
-``XUVRANGE`` ``0x0000000000000000 - Page-mapped, Cached, PLV0~3
- 0x3FFFFFFFFFFFFFFF``
-``XSPRANGE`` ``0x4000000000000000 - Direct-mapped, Cached / Uncached, PLV0
- 0x7FFFFFFFFFFFFFFF``
-``XKPRANGE`` ``0x8000000000000000 - Direct-mapped, Cached / Uncached, PLV0
- 0xBFFFFFFFFFFFFFFF``
-``XKVRANGE`` ``0xC000000000000000 - Page-mapped, Cached, PLV0
- 0xFFFFFFFFFFFFFFFF``
-============ ====================== ======================================
-
-User mode (PLV3) can only access XUVRANGE. For direct-mapped XSPRANGE and
-XKPRANGE, PA is equal to VA with bits 60~63 cleared, and the cache attribute
-is configured by bits 60~61 in VA: 0 is for strongly-ordered uncached, 1 is
-for coherent cached, and 2 is for weakly-ordered uncached.
-
-Currently we only use XKPRANGE for direct mapping and XSPRANGE is reserved.
-
-To put this in action: the strongly-ordered uncached direct-mapped VA (in
-XKPRANGE) of 0x00000000_00001000 is 0x80000000_00001000, the coherent cached
-direct-mapped VA (in XKPRANGE) of 0x00000000_00001000 is 0x90000000_00001000,
-and the weakly-ordered uncached direct-mapped VA (in XKPRANGE) of 0x00000000
-_00001000 is 0xA0000000_00001000.
-
-Relationship of Loongson and LoongArch
-======================================
-
-LoongArch is a RISC ISA which is different from any other existing ones, while
-Loongson is a family of processors. Loongson includes 3 series: Loongson-1 is
-the 32-bit processor series, Loongson-2 is the low-end 64-bit processor series,
-and Loongson-3 is the high-end 64-bit processor series. Old Loongson is based on
-MIPS, while New Loongson is based on LoongArch. Take Loongson-3 as an example:
-Loongson-3A1000/3B1500/3A2000/3A3000/3A4000 are MIPS-compatible, while Loongson-
-3A5000 (and future revisions) are all based on LoongArch.
-
-.. _loongarch-references:
-
-References
-==========
-
-Official web site of Loongson Technology Corp. Ltd.:
-
- http://www.loongson.cn/
-
-Developer web site of Loongson and LoongArch (Software and Documentation):
-
- http://www.loongnix.cn/
-
- https://github.com/loongson/
-
- https://loongson.github.io/LoongArch-Documentation/
-
-Documentation of LoongArch ISA:
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.00-CN.pdf (in Chinese)
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.00-EN.pdf (in English)
-
-Documentation of LoongArch ELF psABI:
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v1.00-CN.pdf (in Chinese)
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v1.00-EN.pdf (in English)
-
-Linux kernel repository of Loongson and LoongArch:
-
- https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
diff --git a/Documentation/loongarch/irq-chip-model.rst b/Documentation/loongarch/irq-chip-model.rst
deleted file mode 100644
index 7988f4192363..000000000000
--- a/Documentation/loongarch/irq-chip-model.rst
+++ /dev/null
@@ -1,160 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=======================================
-IRQ chip model (hierarchy) of LoongArch
-=======================================
-
-Currently, LoongArch based processors (e.g. Loongson-3A5000) can only work together
-with LS7A chipsets. The irq chips in LoongArch computers include CPUINTC (CPU Core
-Interrupt Controller), LIOINTC (Legacy I/O Interrupt Controller), EIOINTC (Extended
-I/O Interrupt Controller), HTVECINTC (Hyper-Transport Vector Interrupt Controller),
-PCH-PIC (Main Interrupt Controller in LS7A chipset), PCH-LPC (LPC Interrupt Controller
-in LS7A chipset) and PCH-MSI (MSI Interrupt Controller).
-
-CPUINTC is a per-core controller (in CPU), LIOINTC/EIOINTC/HTVECINTC are per-package
-controllers (in CPU), while PCH-PIC/PCH-LPC/PCH-MSI are controllers out of CPU (i.e.,
-in chipsets). These controllers (in other words, irqchips) are linked in a hierarchy,
-and there are two models of hierarchy (legacy model and extended model).
-
-Legacy IRQ model
-================
-
-In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go
-to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, while all other devices
-interrupts go to PCH-PIC/PCH-LPC/PCH-MSI and gathered by HTVECINTC, and then go
-to LIOINTC, and then CPUINTC::
-
- +-----+ +---------+ +-------+
- | IPI | --> | CPUINTC | <-- | Timer |
- +-----+ +---------+ +-------+
- ^
- |
- +---------+ +-------+
- | LIOINTC | <-- | UARTs |
- +---------+ +-------+
- ^
- |
- +-----------+
- | HTVECINTC |
- +-----------+
- ^ ^
- | |
- +---------+ +---------+
- | PCH-PIC | | PCH-MSI |
- +---------+ +---------+
- ^ ^ ^
- | | |
- +---------+ +---------+ +---------+
- | PCH-LPC | | Devices | | Devices |
- +---------+ +---------+ +---------+
- ^
- |
- +---------+
- | Devices |
- +---------+
-
-Extended IRQ model
-==================
-
-In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go
-to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, while all other devices
-interrupts go to PCH-PIC/PCH-LPC/PCH-MSI and gathered by EIOINTC, and then go to
-to CPUINTC directly::
-
- +-----+ +---------+ +-------+
- | IPI | --> | CPUINTC | <-- | Timer |
- +-----+ +---------+ +-------+
- ^ ^
- | |
- +---------+ +---------+ +-------+
- | EIOINTC | | LIOINTC | <-- | UARTs |
- +---------+ +---------+ +-------+
- ^ ^
- | |
- +---------+ +---------+
- | PCH-PIC | | PCH-MSI |
- +---------+ +---------+
- ^ ^ ^
- | | |
- +---------+ +---------+ +---------+
- | PCH-LPC | | Devices | | Devices |
- +---------+ +---------+ +---------+
- ^
- |
- +---------+
- | Devices |
- +---------+
-
-ACPI-related definitions
-========================
-
-CPUINTC::
-
- ACPI_MADT_TYPE_CORE_PIC;
- struct acpi_madt_core_pic;
- enum acpi_madt_core_pic_version;
-
-LIOINTC::
-
- ACPI_MADT_TYPE_LIO_PIC;
- struct acpi_madt_lio_pic;
- enum acpi_madt_lio_pic_version;
-
-EIOINTC::
-
- ACPI_MADT_TYPE_EIO_PIC;
- struct acpi_madt_eio_pic;
- enum acpi_madt_eio_pic_version;
-
-HTVECINTC::
-
- ACPI_MADT_TYPE_HT_PIC;
- struct acpi_madt_ht_pic;
- enum acpi_madt_ht_pic_version;
-
-PCH-PIC::
-
- ACPI_MADT_TYPE_BIO_PIC;
- struct acpi_madt_bio_pic;
- enum acpi_madt_bio_pic_version;
-
-PCH-MSI::
-
- ACPI_MADT_TYPE_MSI_PIC;
- struct acpi_madt_msi_pic;
- enum acpi_madt_msi_pic_version;
-
-PCH-LPC::
-
- ACPI_MADT_TYPE_LPC_PIC;
- struct acpi_madt_lpc_pic;
- enum acpi_madt_lpc_pic_version;
-
-References
-==========
-
-Documentation of Loongson-3A5000:
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-CN.pdf (in Chinese)
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-3A5000-usermanual-1.02-EN.pdf (in English)
-
-Documentation of Loongson's LS7A chipset:
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-CN.pdf (in Chinese)
-
- https://github.com/loongson/LoongArch-Documentation/releases/latest/download/Loongson-7A1000-usermanual-2.00-EN.pdf (in English)
-
-.. Note::
- - CPUINTC is CSR.ECFG/CSR.ESTAT and its interrupt controller described
- in Section 7.4 of "LoongArch Reference Manual, Vol 1";
- - LIOINTC is "Legacy I/OInterrupts" described in Section 11.1 of
- "Loongson 3A5000 Processor Reference Manual";
- - EIOINTC is "Extended I/O Interrupts" described in Section 11.2 of
- "Loongson 3A5000 Processor Reference Manual";
- - HTVECINTC is "HyperTransport Interrupts" described in Section 14.3 of
- "Loongson 3A5000 Processor Reference Manual";
- - PCH-PIC/PCH-MSI is "Interrupt Controller" described in Section 5 of
- "Loongson 7A1000 Bridge User Manual";
- - PCH-LPC is "LPC Interrupts" described in Section 24.3 of
- "Loongson 7A1000 Bridge User Manual".
diff --git a/Documentation/m68k/features.rst b/Documentation/m68k/features.rst
deleted file mode 100644
index 5107a2119472..000000000000
--- a/Documentation/m68k/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features m68k
diff --git a/Documentation/maintainer/configure-git.rst b/Documentation/maintainer/configure-git.rst
index 80ae5030a590..0c21f203cf7a 100644
--- a/Documentation/maintainer/configure-git.rst
+++ b/Documentation/maintainer/configure-git.rst
@@ -1,64 +1,30 @@
-.. _configuregit:
-
-Configure Git
-=============
+Configuring Git
+===============
This chapter describes maintainer level git configuration.
-Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst
-<pullrequests>` should be signed with the developers public GPG key. Signed
-tags can be created by passing the ``-u`` flag to ``git tag``. However,
-since you would *usually* use the same key for the same project, you can
-set it once with
-::
+Tagged branches used in pull requests (see
+Documentation/maintainer/pull-requests.rst) should be signed with the
+developers public GPG key. Signed tags can be created by passing
+``-u <key-id>`` to ``git tag``. However, since you would *usually* use the same
+key for the project, you can set it in the configuration and use the ``-s``
+flag. To set the default ``key-id`` use::
git config user.signingkey "keyname"
-Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:
-::
+Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand::
[user]
name = Jane Developer
email = jd@domain.org
signingkey = jd@domain.org
-You may need to tell ``git`` to use ``gpg2``
-::
+You may need to tell ``git`` to use ``gpg2``::
[gpg]
program = /path/to/gpg2
-You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc file)
-::
+You may also like to tell ``gpg`` which ``tty`` to use (add to your shell
+rc file)::
export GPG_TTY=$(tty)
-
-
-Creating commit links to lore.kernel.org
-----------------------------------------
-
-The web site http://lore.kernel.org is meant as a grand archive of all mail
-list traffic concerning or influencing the kernel development. Storing archives
-of patches here is a recommended practice, and when a maintainer applies a
-patch to a subsystem tree, it is a good idea to provide a Link: tag with a
-reference back to the lore archive so that people that browse the commit
-history can find related discussions and rationale behind a certain change.
-The link tag will look like this:
-
- Link: https://lore.kernel.org/r/<message-id>
-
-This can be configured to happen automatically any time you issue ``git am``
-by adding the following hook into your git:
-
-.. code-block:: none
-
- $ git config am.messageid true
- $ cat >.git/hooks/applypatch-msg <<'EOF'
- #!/bin/sh
- . git-sh-setup
- perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?$|Link: https://lore.kernel.org/r/$1|g;' "$1"
- test -x "$GIT_DIR/hooks/commit-msg" &&
- exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
- :
- EOF
- $ chmod a+x .git/hooks/applypatch-msg
diff --git a/Documentation/maintainer/feature-and-driver-maintainers.rst b/Documentation/maintainer/feature-and-driver-maintainers.rst
new file mode 100644
index 000000000000..fb94a9b29061
--- /dev/null
+++ b/Documentation/maintainer/feature-and-driver-maintainers.rst
@@ -0,0 +1,166 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Feature and driver maintainers
+==============================
+
+The term "maintainer" spans a very wide range of levels of engagement
+from people handling patches and pull requests as almost a full time job
+to people responsible for a small feature or a driver.
+
+Unlike most of the chapter, this section is meant for the latter (more
+populous) group. It provides tips and describes the expectations and
+responsibilities of maintainers of a small(ish) section of the code.
+
+Drivers and alike most often do not have their own mailing lists and
+git trees but instead send and review patches on the list of a larger
+subsystem.
+
+Responsibilities
+================
+
+The amount of maintenance work is usually proportional to the size
+and popularity of the code base. Small features and drivers should
+require relatively small amount of care and feeding. Nonetheless
+when the work does arrive (in form of patches which need review,
+user bug reports etc.) it has to be acted upon promptly.
+Even when a particular driver only sees one patch a month, or a quarter,
+a subsystem could well have a hundred such drivers. Subsystem
+maintainers cannot afford to wait a long time to hear from reviewers.
+
+The exact expectations on the response time will vary by subsystem.
+The patch review SLA the subsystem had set for itself can sometimes
+be found in the subsystem documentation. Failing that as a rule of thumb
+reviewers should try to respond quicker than what is the usual patch
+review delay of the subsystem maintainer. The resulting expectations
+may range from two working days for fast-paced subsystems (e.g. networking)
+to as long as a few weeks in slower moving parts of the kernel.
+
+Mailing list participation
+--------------------------
+
+Linux kernel uses mailing lists as the primary form of communication.
+Maintainers must be subscribed and follow the appropriate subsystem-wide
+mailing list. Either by subscribing to the whole list or using more
+modern, selective setup like
+`lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.
+
+Maintainers must know how to communicate on the list (plain text, no invasive
+legal footers, no top posting, etc.)
+
+Reviews
+-------
+
+Maintainers must review *all* patches touching exclusively their drivers,
+no matter how trivial. If the patch is a tree wide change and modifies
+multiple drivers - whether to provide a review is left to the maintainer.
+
+When there are multiple maintainers for a piece of code an ``Acked-by``
+or ``Reviewed-by`` tag (or review comments) from a single maintainer is
+enough to satisfy this requirement.
+
+If the review process or validation for a particular change will take longer
+than the expected review timeline for the subsystem, maintainer should
+reply to the submission indicating that the work is being done, and when
+to expect full results.
+
+Refactoring and core changes
+----------------------------
+
+Occasionally core code needs to be changed to improve the maintainability
+of the kernel as a whole. Maintainers are expected to be present and
+help guide and test changes to their code to fit the new infrastructure.
+
+Bug reports
+-----------
+
+Maintainers must ensure severe problems in their code reported to them
+are resolved in a timely manner: regressions, kernel crashes, kernel warnings,
+compilation errors, lockups, data loss, and other bugs of similar scope.
+
+Maintainers furthermore should respond to reports about other kinds of
+bugs as well, if the report is of reasonable quality or indicates a
+problem that might be severe -- especially if they have *Supported*
+status of the codebase in the MAINTAINERS file.
+
+Open development
+----------------
+
+Discussions about user reported issues, and development of new code
+should be conducted in a manner typical for the larger subsystem.
+It is common for development within a single company to be conducted
+behind closed doors. However, development and discussions initiated
+by community members must not be redirected from public to closed forums
+or to private email conversations. Reasonable exceptions to this guidance
+include discussions about security related issues.
+
+Selecting the maintainer
+========================
+
+The previous section described the expectations of the maintainer,
+this section provides guidance on selecting one and describes common
+misconceptions.
+
+The author
+----------
+
+Most natural and common choice of a maintainer is the author of the code.
+The author is intimately familiar with the code, so it is the best person
+to take care of it on an ongoing basis.
+
+That said, being a maintainer is an active role. The MAINTAINERS file
+is not a list of credits (in fact a separate CREDITS file exists),
+it is a list of those who will actively help with the code.
+If the author does not have the time, interest or ability to maintain
+the code, a different maintainer must be selected.
+
+Multiple maintainers
+--------------------
+
+Modern best practices dictate that there should be at least two maintainers
+for any piece of code, no matter how trivial. It spreads the burden, helps
+people take vacations and prevents burnout, trains new members of
+the community etc. etc. Even when there is clearly one perfect candidate,
+another maintainer should be found.
+
+Maintainers must be human, therefore, it is not acceptable to add a mailing
+list or a group email as a maintainer. Trust and understanding are the
+foundation of kernel maintenance and one cannot build trust with a mailing
+list. Having a mailing list *in addition* to humans is perfectly fine.
+
+Corporate structures
+--------------------
+
+To an outsider the Linux kernel may resemble a hierarchical organization
+with Linus as the CEO. While the code flows in a hierarchical fashion,
+the corporate template does not apply here. Linux is an anarchy held
+together by (rarely expressed) mutual respect, trust and convenience.
+
+All that is to say that managers almost never make good maintainers.
+The maintainer position more closely matches an on-call rotation
+than a position of power.
+
+The following characteristics of a person selected as a maintainer
+are clear red flags:
+
+ - unknown to the community, never sent an email to the list before
+ - did not author any of the code
+ - (when development is contracted) works for a company which paid
+ for the development rather than the company which did the work
+
+Non compliance
+==============
+
+Subsystem maintainers may remove inactive maintainers from the MAINTAINERS
+file. If the maintainer was a significant author or played an important
+role in the development of the code, they should be moved to the CREDITS file.
+
+Removing an inactive maintainer should not be seen as a punitive action.
+Having an inactive maintainer has a real cost as all developers have
+to remember to include the maintainers in discussions and subsystem
+maintainers spend brain power figuring out how to solicit feedback.
+
+Subsystem maintainers may remove code for lacking maintenance.
+
+Subsystem maintainers may refuse accepting code from companies
+which repeatedly neglected their maintainership duties.
diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
index 3e03283c144e..eeee27f8b18c 100644
--- a/Documentation/maintainer/index.rst
+++ b/Documentation/maintainer/index.rst
@@ -9,6 +9,7 @@ additions to this manual.
.. toctree::
:maxdepth: 2
+ feature-and-driver-maintainers
configure-git
rebasing-and-merging
pull-requests
diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst
index 93b2ae6c34a9..6020d188e13d 100644
--- a/Documentation/maintainer/maintainer-entry-profile.rst
+++ b/Documentation/maintainer/maintainer-entry-profile.rst
@@ -59,6 +59,7 @@ week) that patches might be considered for merging and when patches need to
wait for the next -rc. At a minimum:
- Last -rc for new feature submissions:
+
New feature submissions targeting the next merge window should have
their first posting for consideration before this point. Patches that
are submitted after this point should be clear that they are targeting
@@ -68,6 +69,7 @@ wait for the next -rc. At a minimum:
submissions should appear before -rc5.
- Last -rc to merge features: Deadline for merge decisions
+
Indicate to contributors the point at which an as yet un-applied patch
set will need to wait for the NEXT+1 merge window. Of course there is no
obligation to ever accept any given patchset, but if the review has not
@@ -101,6 +103,13 @@ to do something different in the near future.
../doc-guide/maintainer-profile
../nvdimm/maintainer-entry-profile
- ../riscv/patch-acceptance
+ ../arch/riscv/patch-acceptance
+ ../process/maintainer-soc
+ ../process/maintainer-soc-clean-dts
../driver-api/media/maintainer-entry-profile
+ ../process/maintainer-netdev
../driver-api/vfio-pci-device-specific-driver-acceptance
+ ../nvme/feature-and-quirk-policy
+ ../filesystems/nfs/nfsd-maintainer-entry-profile
+ ../filesystems/xfs/xfs-maintainer-entry-profile
+ ../mm/damon/maintainer-profile
diff --git a/Documentation/maintainer/pull-requests.rst b/Documentation/maintainer/pull-requests.rst
index e072de60ccb0..0d63d9d7e347 100644
--- a/Documentation/maintainer/pull-requests.rst
+++ b/Documentation/maintainer/pull-requests.rst
@@ -1,5 +1,3 @@
-.. _pullrequests:
-
Creating Pull Requests
======================
@@ -41,7 +39,7 @@ named ``char-misc-next``, you would be using the following command::
that will create a signed tag called ``char-misc-4.15-rc1`` based on the
last commit in the ``char-misc-next`` branch, and sign it with your gpg key
-(see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`).
+(see Documentation/maintainer/configure-git.rst).
Linus will only accept pull requests based on a signed tag. Other
maintainers may differ.
@@ -52,7 +50,7 @@ so outline what is contained here, why it should be merged, and what, if
any, testing has been done. All of this information will end up in the tag
itself, and then in the merge commit that the maintainer makes if/when they
merge the pull request. So write it up well, as it will be in the kernel
-tree for forever.
+tree forever.
As said by Linus::
diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst
index 09f988e7fa71..85800ce95ae5 100644
--- a/Documentation/maintainer/rebasing-and-merging.rst
+++ b/Documentation/maintainer/rebasing-and-merging.rst
@@ -213,11 +213,7 @@ point rather than some random spot. If your upstream-bound branch has
emptied entirely into the mainline during the merge window, you can pull it
forward with a command like::
- git merge v5.2-rc1^0
-
-The "^0" will cause Git to do a fast-forward merge (which should be
-possible in this situation), thus avoiding the addition of a spurious merge
-commit.
+ git merge --ff-only v5.2-rc1
The guidelines laid out above are just that: guidelines. There will always
be situations that call out for a different solution, and these guidelines
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 06f80e3785c5..61b7317bcf2e 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -88,7 +88,6 @@ CONTENTS
(*) The effects of the cpu cache.
- - Cache coherency.
- Cache coherency vs DMA.
- Cache coherency vs MMIO.
@@ -396,6 +395,11 @@ Memory barriers come in four basic varieties:
(2) Address-dependency barriers (historical).
+ [!] This section is marked as HISTORICAL: it covers the long-obsolete
+ smp_read_barrier_depends() macro, the semantics of which are now
+ implicit in all marked accesses. For more up-to-date information,
+ including how compiler transformations can sometimes break address
+ dependencies, see Documentation/RCU/rcu_dereference.rst.
An address-dependency barrier is a weaker form of read barrier. In the
case where two loads are performed such that the second depends on the
@@ -556,6 +560,11 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
ADDRESS-DEPENDENCY BARRIERS (HISTORICAL)
----------------------------------------
+[!] This section is marked as HISTORICAL: it covers the long-obsolete
+smp_read_barrier_depends() macro, the semantics of which are now implicit
+in all marked accesses. For more up-to-date information, including
+how compiler transformations can sometimes break address dependencies,
+see Documentation/RCU/rcu_dereference.rst.
As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for
DEC Alpha, which means that about the only people who need to pay attention
@@ -667,8 +676,6 @@ include/linux/rcupdate.h. This permits the current target of an RCU'd
pointer to be replaced with a new modified target, without the replacement
target appearing to be incompletely initialised.
-See also the subsection on "Cache Coherency" for a more thorough example.
-
CONTROL DEPENDENCIES
--------------------
@@ -1910,7 +1917,8 @@ There are some more advanced barrier functions:
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
- DMA capable device.
+ DMA capable device. See Documentation/core-api/dma-api.rst file for more
+ information about consistent memory.
For example, consider a device driver that shares memory with a device
and uses a descriptor status value to indicate if the descriptor belongs
@@ -1931,22 +1939,21 @@ There are some more advanced barrier functions:
/* assign ownership */
desc->status = DEVICE_OWN;
- /* notify device of new descriptors */
+ /* Make descriptor status visible to the device followed by
+ * notify device of new descriptor
+ */
writel(DESC_NOTIFY, doorbell);
}
- The dma_rmb() allows us guarantee the device has released ownership
+ The dma_rmb() allows us to guarantee that the device has released ownership
before we read the data from the descriptor, and the dma_wmb() allows
us to guarantee the data is written to the descriptor before the device
can see it now has ownership. The dma_mb() implies both a dma_rmb() and
- a dma_wmb(). Note that, when using writel(), a prior wmb() is not needed
- to guarantee that the cache coherent memory writes have completed before
- writing to the MMIO region. The cheaper writel_relaxed() does not provide
- this guarantee and must not be used here.
+ a dma_wmb().
- See the subsection "Kernel I/O barrier effects" for more information on
- relaxed I/O accessors and the Documentation/core-api/dma-api.rst file for
- more information on consistent memory.
+ Note that the dma_*() barriers do not provide any ordering guarantees for
+ accesses to MMIO regions. See the later "KERNEL I/O BARRIER EFFECTS"
+ subsection for more information about I/O accessors and MMIO ordering.
(*) pmem_wmb();
@@ -1966,7 +1973,7 @@ There are some more advanced barrier functions:
(*) io_stop_wc();
For memory accesses with write-combining attributes (e.g. those returned
- by ioremap_wc(), the CPU may wait for prior accesses to be merged with
+ by ioremap_wc()), the CPU may wait for prior accesses to be merged with
subsequent ones. io_stop_wc() can be used to prevent the merging of
write-combining memory accesses before this macro with those after it when
such wait has performance implications.
@@ -2175,9 +2182,11 @@ set_current_state() may be wrapped by:
which therefore also imply a general memory barrier after setting the state.
The whole sequence above is available in various canned forms, all of which
-interpolate the memory barrier in the right place:
+interpolate the memory barrier in the right place, for example:
wait_event();
+ wait_event_cmd();
+ wait_event_exclusive_cmd();
wait_event_interruptible();
wait_event_interruptible_exclusive();
wait_event_interruptible_timeout();
diff --git a/Documentation/mips/features.rst b/Documentation/mips/features.rst
deleted file mode 100644
index 1973d729b29a..000000000000
--- a/Documentation/mips/features.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. kernel-feat:: $srctree/Documentation/features mips
diff --git a/Documentation/misc-devices/amd-sbi.rst b/Documentation/misc-devices/amd-sbi.rst
new file mode 100644
index 000000000000..07ceb44fbe5e
--- /dev/null
+++ b/Documentation/misc-devices/amd-sbi.rst
@@ -0,0 +1,101 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================
+AMD SIDE BAND interface
+=======================
+
+Some AMD Zen based processors supports system management
+functionality via side-band interface (SBI) called
+Advanced Platform Management Link (APML). APML is an I2C/I3C
+based 2-wire processor target interface. APML is used to
+communicate with the Remote Management Interface
+(SB Remote Management Interface (SB-RMI)
+and SB Temperature Sensor Interface (SB-TSI)).
+
+More details on the interface can be found in chapter
+"5 Advanced Platform Management Link (APML)" of the family/model PPR [1]_.
+
+.. [1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/programmer-references/55898_B1_pub_0_50.zip
+
+
+SBRMI device
+============
+
+apml_sbrmi driver under the drivers/misc/amd-sbi creates miscdevice
+/dev/sbrmi-* to let user space programs run APML mailbox, CPUID,
+MCAMSR and register xfer commands.
+
+Register sets is common across APML protocols. IOCTL is providing synchronization
+among protocols as transactions may create race condition.
+
+.. code-block:: bash
+
+ $ ls -al /dev/sbrmi-3c
+ crw------- 1 root root 10, 53 Jul 10 11:13 /dev/sbrmi-3c
+
+apml_sbrmi driver registers hwmon sensors for monitoring power_cap_max,
+current power consumption and managing power_cap.
+
+Characteristics of the dev node:
+ * Differnet xfer protocols are defined:
+ * Mailbox
+ * CPUID
+ * MCA_MSR
+ * Register xfer
+
+Access restrictions:
+ * Only root user is allowed to open the file.
+ * APML Mailbox messages and Register xfer access are read-write,
+ * CPUID and MCA_MSR access is read-only.
+
+Driver IOCTLs
+=============
+
+.. c:macro:: SBRMI_IOCTL_MBOX_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+ :doc: SBRMI_IOCTL_MBOX_CMD
+.. c:macro:: SBRMI_IOCTL_CPUID_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+ :doc: SBRMI_IOCTL_CPUID_CMD
+.. c:macro:: SBRMI_IOCTL_MCAMSR_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+ :doc: SBRMI_IOCTL_MCAMSR_CMD
+.. c:macro:: SBRMI_IOCTL_REG_XFER_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+ :doc: SBRMI_IOCTL_REG_XFER_CMD
+
+User-space usage
+================
+
+To access side band interface from a C program.
+First, user need to include the headers::
+
+ #include <uapi/misc/amd-apml.h>
+
+Which defines the supported IOCTL and data structure to be passed
+from the user space.
+
+Next thing, open the device file, as follows::
+
+ int file;
+
+ file = open("/dev/sbrmi-*", O_RDWR);
+ if (file < 0) {
+ /* ERROR HANDLING */
+ exit(1);
+ }
+
+The following IOCTLs are defined:
+
+``#define SB_BASE_IOCTL_NR 0xF9``
+``#define SBRMI_IOCTL_MBOX_CMD _IOWR(SB_BASE_IOCTL_NR, 0, struct apml_mbox_msg)``
+``#define SBRMI_IOCTL_CPUID_CMD _IOWR(SB_BASE_IOCTL_NR, 1, struct apml_cpuid_msg)``
+``#define SBRMI_IOCTL_MCAMSR_CMD _IOWR(SB_BASE_IOCTL_NR, 2, struct apml_mcamsr_msg)``
+``#define SBRMI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 3, struct apml_reg_xfer_msg)``
+
+
+User space C-APIs are made available by esmi_oob_library, hosted at
+[2]_ which is provided by the E-SMS project [3]_.
+
+.. [2] https://github.com/amd/esmi_oob_library
+.. [3] https://www.amd.com/en/developer/e-sms.html
diff --git a/Documentation/misc-devices/eeprom.rst b/Documentation/misc-devices/eeprom.rst
deleted file mode 100644
index 008249675ccc..000000000000
--- a/Documentation/misc-devices/eeprom.rst
+++ /dev/null
@@ -1,107 +0,0 @@
-====================
-Kernel driver eeprom
-====================
-
-Supported chips:
-
- * Any EEPROM chip in the designated address range
-
- Prefix: 'eeprom'
-
- Addresses scanned: I2C 0x50 - 0x57
-
- Datasheets: Publicly available from:
-
- Atmel (www.atmel.com),
- Catalyst (www.catsemi.com),
- Fairchild (www.fairchildsemi.com),
- Microchip (www.microchip.com),
- Philips (www.semiconductor.philips.com),
- Rohm (www.rohm.com),
- ST (www.st.com),
- Xicor (www.xicor.com),
- and others.
-
- ========= ============= ============================================
- Chip Size (bits) Address
- ========= ============= ============================================
- 24C01 1K 0x50 (shadows at 0x51 - 0x57)
- 24C01A 1K 0x50 - 0x57 (Typical device on DIMMs)
- 24C02 2K 0x50 - 0x57
- 24C04 4K 0x50, 0x52, 0x54, 0x56
- (additional data at 0x51, 0x53, 0x55, 0x57)
- 24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52,
- 0x53, 0x55, 0x56, 0x57)
- 24C16 16K 0x50 (additional data at 0x51 - 0x57)
- Sony 2K 0x57
-
- Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37
- Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37
- Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37
- Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37
- Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37
- ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37
- ========= ============= ============================================
-
-
-Authors:
- - Frodo Looijaard <frodol@dds.nl>,
- - Philip Edelbrock <phil@netroedge.com>,
- - Jean Delvare <jdelvare@suse.de>,
- - Greg Kroah-Hartman <greg@kroah.com>,
- - IBM Corp.
-
-Description
------------
-
-This is a simple EEPROM module meant to enable reading the first 256 bytes
-of an EEPROM (on a SDRAM DIMM for example). However, it will access serial
-EEPROMs on any I2C adapter. The supported devices are generically called
-24Cxx, and are listed above; however the numbering for these
-industry-standard devices may vary by manufacturer.
-
-This module was a programming exercise to get used to the new project
-organization laid out by Frodo, but it should be at least completely
-effective for decoding the contents of EEPROMs on DIMMs.
-
-DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants.
-The other devices will not be found on a DIMM because they respond to more
-than one address.
-
-DDC Monitors may contain any device. Often a 24C01, which responds to all 8
-addresses, is found.
-
-Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the
-specification, so it is guess work and far from being complete.
-
-The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional
-software write protect register at 0x30 - 0x37 (0x20 less than the memory
-location). The chip responds to "write quick" detection at this address but
-does not respond to byte reads. If this register is present, the lower 128
-bytes of the memory array are not write protected. Any byte data write to
-this address will write protect the memory array permanently, and the
-device will no longer respond at the 0x30-37 address. The eeprom driver
-does not support this register.
-
-Lacking functionality
----------------------
-
-* Full support for larger devices (24C04, 24C08, 24C16). These are not
- typically found on a PC. These devices will appear as separate devices at
- multiple addresses.
-
-* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512).
- These devices require two-byte address fields and are not supported.
-
-* Enable Writing. Again, no technical reason why not, but making it easy
- to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy
- to disable the DIMMs (potentially preventing the computer from booting)
- until the values are restored somehow.
-
-Use
----
-
-After inserting the module (and any other required SMBus/i2c modules), you
-should have some EEPROM directories in ``/sys/bus/i2c/devices/*`` of names such
-as "0-0050". Inside each of these is a series of files, the eeprom file
-contains the binary data from EEPROM.
diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst
index 756be15a49a4..081e79415e38 100644
--- a/Documentation/misc-devices/index.rst
+++ b/Documentation/misc-devices/index.rst
@@ -7,17 +7,14 @@ Assorted Miscellaneous Devices Documentation
This documentation contains information for assorted devices that do not
fit into other categories.
-.. class:: toc-title
-
- Table of contents
-
.. toctree::
+ :caption: Table of contents
:maxdepth: 2
ad525x_dpot
+ amd-sbi
apds990x
bh1770glc
- eeprom
c2port
dw-xdata-pcie
ibmvmc
@@ -25,8 +22,10 @@ fit into other categories.
isl29003
lis3lv02d
max6875
+ mrvl_cn10k_dpi
oxsemi-tornado
pci-endpoint-test
spear-pcie-gadget
+ tps6594-pfsm
uacce
xilinx_sdfec
diff --git a/Documentation/misc-devices/lis3lv02d.rst b/Documentation/misc-devices/lis3lv02d.rst
index 959bd2b822cf..6b3b7405ebdf 100644
--- a/Documentation/misc-devices/lis3lv02d.rst
+++ b/Documentation/misc-devices/lis3lv02d.rst
@@ -22,10 +22,10 @@ sporting the feature officially called "HP Mobile Data Protection System 3D" or
models (full list can be found in drivers/platform/x86/hp_accel.c) will have
their axis automatically oriented on standard way (eg: you can directly play
neverball). The accelerometer data is readable via
-/sys/devices/platform/lis3lv02d. Reported values are scaled
+/sys/devices/faux/lis3lv02d. Reported values are scaled
to mg values (1/1000th of earth gravity).
-Sysfs attributes under /sys/devices/platform/lis3lv02d/:
+Sysfs attributes under /sys/devices/faux/lis3lv02d/:
position
- 3D position that the accelerometer reports. Format: "(x,y,z)"
@@ -85,7 +85,7 @@ the accelerometer are converted into a "standard" organisation of the axes
If your laptop model is not recognized (cf "dmesg"), you can send an
email to the maintainer to add it to the database. When reporting a new
laptop, please include the output of "dmidecode" plus the value of
-/sys/devices/platform/lis3lv02d/position in these four cases.
+/sys/devices/faux/lis3lv02d/position in these four cases.
Q&A
---
diff --git a/Documentation/misc-devices/mrvl_cn10k_dpi.rst b/Documentation/misc-devices/mrvl_cn10k_dpi.rst
new file mode 100644
index 000000000000..fa9b8cd6806f
--- /dev/null
+++ b/Documentation/misc-devices/mrvl_cn10k_dpi.rst
@@ -0,0 +1,52 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================================
+Marvell CN10K DMA packet interface (DPI) driver
+===============================================
+
+Overview
+========
+
+DPI is a DMA packet interface hardware block in Marvell's CN10K silicon.
+DPI hardware comprises a physical function (PF), its virtual functions,
+mailbox logic, and a set of DMA engines & DMA command queues.
+
+DPI PF function is an administrative function which services the mailbox
+requests from its VF functions and provisions DMA engine resources to
+it's VF functions.
+
+mrvl_cn10k_dpi.ko misc driver loads on DPI PF device and services the
+mailbox commands submitted by the VF devices and accordingly initializes
+the DMA engines and VF device's DMA command queues. Also, driver creates
+/dev/mrvl-cn10k-dpi node to set DMA engine and PEM (PCIe interface) port
+attributes like fifo length, molr, mps & mrrs.
+
+DPI PF driver is just an administrative driver to setup its VF device's
+queues and provisions the hardware resources, it cannot initiate any
+DMA operations. Only VF devices are provisioned with DMA capabilities.
+
+Driver location
+===============
+
+drivers/misc/mrvl_cn10k_dpi.c
+
+Driver IOCTLs
+=============
+
+:c:macro:`DPI_MPS_MRRS_CFG`
+ioctl that sets max payload size & max read request size parameters of
+a pem port to which DMA engines are wired.
+
+
+:c:macro:`DPI_ENGINE_CFG`
+ioctl that sets DMA engine's fifo sizes & max outstanding load request
+thresholds.
+
+User space code example
+=======================
+
+DPI VF devices are probed and accessed from user space applications using
+vfio-pci driver. Below is a sample dpi dma application to demonstrate on
+how applications use mailbox and ioctl services from DPI PF kernel driver.
+
+https://github.com/MarvellEmbeddedProcessors/dpi-sample-app
diff --git a/Documentation/misc-devices/tps6594-pfsm.rst b/Documentation/misc-devices/tps6594-pfsm.rst
new file mode 100644
index 000000000000..5f17a4fd9579
--- /dev/null
+++ b/Documentation/misc-devices/tps6594-pfsm.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Texas Instruments TPS6594 PFSM driver
+=====================================
+
+Author: Julien Panis (jpanis@baylibre.com)
+
+Overview
+========
+
+Strictly speaking, PFSM (Pre-configurable Finite State Machine) is not
+hardware. It is a piece of code.
+
+The TPS6594 PMIC (Power Management IC) integrates a state machine which
+manages operational modes. Depending on the current operational mode,
+some voltage domains remain energized while others can be off.
+
+The PFSM driver can be used to trigger transitions between configured
+states. It also provides R/W access to the device registers.
+
+Supported chips
+---------------
+
+- tps6594-q1
+- tps6593-q1
+- lp8764-q1
+
+Driver location
+===============
+
+drivers/misc/tps6594-pfsm.c
+
+Driver type definitions
+=======================
+
+include/uapi/linux/tps6594_pfsm.h
+
+Driver IOCTLs
+=============
+
+:c:macro:`PMIC_GOTO_STANDBY`
+All device resources are powered down. The processor is off, and
+no voltage domains are energized.
+
+:c:macro:`PMIC_GOTO_LP_STANDBY`
+The digital and analog functions of the PMIC, which are not
+required to be always-on, are turned off (low-power).
+
+:c:macro:`PMIC_UPDATE_PGM`
+Triggers a firmware update.
+
+:c:macro:`PMIC_SET_ACTIVE_STATE`
+One of the operational modes.
+The PMICs are fully functional and supply power to all PDN loads.
+All voltage domains are energized in both MCU and Main processor
+sections.
+
+:c:macro:`PMIC_SET_MCU_ONLY_STATE`
+One of the operational modes.
+Only the power resources assigned to the MCU Safety Island are on.
+
+:c:macro:`PMIC_SET_RETENTION_STATE`
+One of the operational modes.
+Depending on the triggers set, some DDR/GPIO voltage domains can
+remain energized, while all other domains are off to minimize
+total system power.
+
+Driver usage
+============
+
+See available PFSMs::
+
+ # ls /dev/pfsm*
+
+Dump the registers of pages 0 and 1::
+
+ # hexdump -C /dev/pfsm-0-0x48
+
+See PFSM events::
+
+ # cat /proc/interrupts
+
+Userspace code example
+----------------------
+
+samples/pfsm/pfsm-wakeup.c
diff --git a/Documentation/misc-devices/uacce.rst b/Documentation/misc-devices/uacce.rst
index 1db412e9b1a3..5f78d413e379 100644
--- a/Documentation/misc-devices/uacce.rst
+++ b/Documentation/misc-devices/uacce.rst
@@ -1,7 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0
-Introduction of Uacce
----------------------
+Uacce (Unified/User-space-access-intended Accelerator Framework)
+================================================================
+
+Introduction
+------------
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
diff --git a/Documentation/misc-devices/xilinx_sdfec.rst b/Documentation/misc-devices/xilinx_sdfec.rst
index 8c8a289d69a3..698e6630f3a7 100644
--- a/Documentation/misc-devices/xilinx_sdfec.rst
+++ b/Documentation/misc-devices/xilinx_sdfec.rst
@@ -29,7 +29,7 @@ follows:
- Does not support shared LDPC code table wraparound
The device tree entry is described in:
-`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt <https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/misc/xlnx%2Csd-fec.txt>`_
+`linux-xlnx/Documentation/devicetree/bindings/misc/xlnx,sd-fec.yaml <https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/misc/xlnx%2Csd-fec.yaml>`_
Modes of Operation
diff --git a/Documentation/mm/active_mm.rst b/Documentation/mm/active_mm.rst
index 6f8269c284ed..60d819d7d043 100644
--- a/Documentation/mm/active_mm.rst
+++ b/Documentation/mm/active_mm.rst
@@ -1,9 +1,13 @@
-.. _active_mm:
-
=========
Active MM
=========
+Note, the mm_count refcount may no longer include the "lazy" users
+(running tasks with ->active_mm == mm && ->mm == NULL) on kernels
+with CONFIG_MMU_LAZY_TLB_REFCOUNT=n. Taking and releasing these lazy
+references must be done with mmgrab_lazy_tlb() and mmdrop_lazy_tlb()
+helpers, which abstract this config option.
+
::
List: linux-kernel
@@ -88,4 +92,4 @@ Active MM
and register state is separate, the alpha PALcode joins the two, and you
need to switch both together).
- (From http://marc.info/?l=linux-kernel&m=93337278602211&w=2)
+ (From https://lore.kernel.org/lkml/Pine.LNX.4.10.9907301410280.752-100000@penguin.transmeta.com/)
diff --git a/Documentation/mm/allocation-profiling.rst b/Documentation/mm/allocation-profiling.rst
new file mode 100644
index 000000000000..316311240e6a
--- /dev/null
+++ b/Documentation/mm/allocation-profiling.rst
@@ -0,0 +1,104 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+MEMORY ALLOCATION PROFILING
+===========================
+
+Low overhead (suitable for production) accounting of all memory allocations,
+tracked by file and line number.
+
+Usage:
+kconfig options:
+- CONFIG_MEM_ALLOC_PROFILING
+
+- CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT
+
+- CONFIG_MEM_ALLOC_PROFILING_DEBUG
+ adds warnings for allocations that weren't accounted because of a
+ missing annotation
+
+Boot parameter:
+ sysctl.vm.mem_profiling={0|1|never}[,compressed]
+
+ When set to "never", memory allocation profiling overhead is minimized and it
+ cannot be enabled at runtime (sysctl becomes read-only).
+ When CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, default value is "1".
+ When CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=n, default value is "never".
+ "compressed" optional parameter will try to store page tag references in a
+ compact format, avoiding page extensions. This results in improved performance
+ and memory consumption, however it might fail depending on system configuration.
+ If compression fails, a warning is issued and memory allocation profiling gets
+ disabled.
+
+sysctl:
+ /proc/sys/vm/mem_profiling
+
+Runtime info:
+ /proc/allocinfo
+
+Example output::
+
+ root@moria-kvm:~# sort -g /proc/allocinfo|tail|numfmt --to=iec
+ 2.8M 22648 fs/kernfs/dir.c:615 func:__kernfs_new_node
+ 3.8M 953 mm/memory.c:4214 func:alloc_anon_folio
+ 4.0M 1010 drivers/staging/ctagmod/ctagmod.c:20 [ctagmod] func:ctagmod_start
+ 4.1M 4 net/netfilter/nf_conntrack_core.c:2567 func:nf_ct_alloc_hashtable
+ 6.0M 1532 mm/filemap.c:1919 func:__filemap_get_folio
+ 8.8M 2785 kernel/fork.c:307 func:alloc_thread_stack_node
+ 13M 234 block/blk-mq.c:3421 func:blk_mq_alloc_rqs
+ 14M 3520 mm/mm_init.c:2530 func:alloc_large_system_hash
+ 15M 3656 mm/readahead.c:247 func:page_cache_ra_unbounded
+ 55M 4887 mm/slub.c:2259 func:alloc_slab_page
+ 122M 31168 mm/page_ext.c:270 func:alloc_page_ext
+
+Theory of operation
+===================
+
+Memory allocation profiling builds off of code tagging, which is a library for
+declaring static structs (that typically describe a file and line number in
+some way, hence code tagging) and then finding and operating on them at runtime,
+- i.e. iterating over them to print them in debugfs/procfs.
+
+To add accounting for an allocation call, we replace it with a macro
+invocation, alloc_hooks(), that
+- declares a code tag
+- stashes a pointer to it in task_struct
+- calls the real allocation function
+- and finally, restores the task_struct alloc tag pointer to its previous value.
+
+This allows for alloc_hooks() calls to be nested, with the most recent one
+taking effect. This is important for allocations internal to the mm/ code that
+do not properly belong to the outer allocation context and should be counted
+separately: for example, slab object extension vectors, or when the slab
+allocates pages from the page allocator.
+
+Thus, proper usage requires determining which function in an allocation call
+stack should be tagged. There are many helper functions that essentially wrap
+e.g. kmalloc() and do a little more work, then are called in multiple places;
+we'll generally want the accounting to happen in the callers of these helpers,
+not in the helpers themselves.
+
+To fix up a given helper, for example foo(), do the following:
+- switch its allocation call to the _noprof() version, e.g. kmalloc_noprof()
+
+- rename it to foo_noprof()
+
+- define a macro version of foo() like so:
+
+ #define foo(...) alloc_hooks(foo_noprof(__VA_ARGS__))
+
+It's also possible to stash a pointer to an alloc tag in your own data structures.
+
+Do this when you're implementing a generic data structure that does allocations
+"on behalf of" some other code - for example, the rhashtable code. This way,
+instead of seeing a large line in /proc/allocinfo for rhashtable.c, we can
+break it out by rhashtable type.
+
+To do so:
+- Hook your data structure's init function, like any other allocation function.
+
+- Within your init function, use the convenience macro alloc_tag_record() to
+ record alloc tag in your data structure.
+
+- Then, use the following form for your allocations:
+ alloc_hooks_tag(ht->your_saved_tag, kmalloc_noprof(...))
diff --git a/Documentation/mm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst
index cbaee9e59241..2447b8a4b08c 100644
--- a/Documentation/mm/arch_pgtable_helpers.rst
+++ b/Documentation/mm/arch_pgtable_helpers.rst
@@ -1,7 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _arch_page_table_helpers:
-
===============================
Architecture Page Table Helpers
===============================
@@ -20,8 +18,6 @@ PTE Page Table Helpers
+---------------------------+--------------------------------------------------+
| pte_same | Tests whether both PTE entries are the same |
+---------------------------+--------------------------------------------------+
-| pte_bad | Tests a non-table mapped PTE |
-+---------------------------+--------------------------------------------------+
| pte_present | Tests a valid mapped PTE |
+---------------------------+--------------------------------------------------+
| pte_young | Tests a young PTE |
@@ -34,8 +30,6 @@ PTE Page Table Helpers
+---------------------------+--------------------------------------------------+
| pte_protnone | Tests a PROT_NONE PTE |
+---------------------------+--------------------------------------------------+
-| pte_devmap | Tests a ZONE_DEVICE mapped PTE |
-+---------------------------+--------------------------------------------------+
| pte_soft_dirty | Tests a soft dirty PTE |
+---------------------------+--------------------------------------------------+
| pte_swp_soft_dirty | Tests a soft dirty swapped PTE |
@@ -48,14 +42,16 @@ PTE Page Table Helpers
+---------------------------+--------------------------------------------------+
| pte_mkclean | Creates a clean PTE |
+---------------------------+--------------------------------------------------+
-| pte_mkwrite | Creates a writable PTE |
+| pte_mkwrite | Creates a writable PTE of the type specified by |
+| | the VMA. |
++---------------------------+--------------------------------------------------+
+| pte_mkwrite_novma | Creates a writable PTE, of the conventional type |
+| | of writable. |
+---------------------------+--------------------------------------------------+
| pte_wrprotect | Creates a write protected PTE |
+---------------------------+--------------------------------------------------+
| pte_mkspecial | Creates a special PTE |
+---------------------------+--------------------------------------------------+
-| pte_mkdevmap | Creates a ZONE_DEVICE mapped PTE |
-+---------------------------+--------------------------------------------------+
| pte_mksoft_dirty | Creates a soft dirty PTE |
+---------------------------+--------------------------------------------------+
| pte_clear_soft_dirty | Clears a soft dirty PTE |
@@ -90,11 +86,9 @@ PMD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pmd_leaf | Tests a leaf mapped PMD |
+---------------------------+--------------------------------------------------+
-| pmd_huge | Tests a HugeTLB mapped PMD |
-+---------------------------+--------------------------------------------------+
| pmd_trans_huge | Tests a Transparent Huge Page (THP) at PMD |
+---------------------------+--------------------------------------------------+
-| pmd_present | Tests a valid mapped PMD |
+| pmd_present | Tests whether pmd_page() points to valid memory |
+---------------------------+--------------------------------------------------+
| pmd_young | Tests a young PMD |
+---------------------------+--------------------------------------------------+
@@ -106,8 +100,6 @@ PMD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pmd_protnone | Tests a PROT_NONE PMD |
+---------------------------+--------------------------------------------------+
-| pmd_devmap | Tests a ZONE_DEVICE mapped PMD |
-+---------------------------+--------------------------------------------------+
| pmd_soft_dirty | Tests a soft dirty PMD |
+---------------------------+--------------------------------------------------+
| pmd_swp_soft_dirty | Tests a soft dirty swapped PMD |
@@ -120,14 +112,16 @@ PMD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pmd_mkclean | Creates a clean PMD |
+---------------------------+--------------------------------------------------+
-| pmd_mkwrite | Creates a writable PMD |
+| pmd_mkwrite | Creates a writable PMD of the type specified by |
+| | the VMA. |
++---------------------------+--------------------------------------------------+
+| pmd_mkwrite_novma | Creates a writable PMD, of the conventional type |
+| | of writable. |
+---------------------------+--------------------------------------------------+
| pmd_wrprotect | Creates a write protected PMD |
+---------------------------+--------------------------------------------------+
| pmd_mkspecial | Creates a special PMD |
+---------------------------+--------------------------------------------------+
-| pmd_mkdevmap | Creates a ZONE_DEVICE mapped PMD |
-+---------------------------+--------------------------------------------------+
| pmd_mksoft_dirty | Creates a soft dirty PMD |
+---------------------------+--------------------------------------------------+
| pmd_clear_soft_dirty | Clears a soft dirty PMD |
@@ -136,7 +130,8 @@ PMD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pmd_swp_clear_soft_dirty | Clears a soft dirty swapped PMD |
+---------------------------+--------------------------------------------------+
-| pmd_mkinvalid | Invalidates a mapped PMD [1] |
+| pmd_mkinvalid | Invalidates a present PMD; do not call for |
+| | non-present PMD [1] |
+---------------------------+--------------------------------------------------+
| pmd_set_huge | Creates a PMD huge mapping |
+---------------------------+--------------------------------------------------+
@@ -164,8 +159,6 @@ PUD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pud_leaf | Tests a leaf mapped PUD |
+---------------------------+--------------------------------------------------+
-| pud_huge | Tests a HugeTLB mapped PUD |
-+---------------------------+--------------------------------------------------+
| pud_trans_huge | Tests a Transparent Huge Page (THP) at PUD |
+---------------------------+--------------------------------------------------+
| pud_present | Tests a valid mapped PUD |
@@ -176,8 +169,6 @@ PUD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pud_write | Tests a writable PUD |
+---------------------------+--------------------------------------------------+
-| pud_devmap | Tests a ZONE_DEVICE mapped PUD |
-+---------------------------+--------------------------------------------------+
| pud_mkyoung | Creates a young PUD |
+---------------------------+--------------------------------------------------+
| pud_mkold | Creates an old PUD |
@@ -190,9 +181,8 @@ PUD Page Table Helpers
+---------------------------+--------------------------------------------------+
| pud_wrprotect | Creates a write protected PUD |
+---------------------------+--------------------------------------------------+
-| pud_mkdevmap | Creates a ZONE_DEVICE mapped PUD |
-+---------------------------+--------------------------------------------------+
-| pud_mkinvalid | Invalidates a mapped PUD [1] |
+| pud_mkinvalid | Invalidates a present PUD; do not call for |
+| | non-present PUD [1] |
+---------------------------+--------------------------------------------------+
| pud_set_huge | Creates a PUD huge mapping |
+---------------------------+--------------------------------------------------+
@@ -216,7 +206,7 @@ HugeTLB Page Table Helpers
+---------------------------+--------------------------------------------------+
| pte_huge | Tests a HugeTLB |
+---------------------------+--------------------------------------------------+
-| pte_mkhuge | Creates a HugeTLB |
+| arch_make_huge_pte | Creates a HugeTLB |
+---------------------------+--------------------------------------------------+
| huge_pte_dirty | Tests a dirty HugeTLB |
+---------------------------+--------------------------------------------------+
@@ -240,13 +230,13 @@ SWAP Page Table Helpers
========================
+---------------------------+--------------------------------------------------+
-| __pte_to_swp_entry | Creates a swapped entry (arch) from a mapped PTE |
+| __pte_to_swp_entry | Creates a swp_entry_t (arch) from a swap PTE |
+---------------------------+--------------------------------------------------+
-| __swp_to_pte_entry | Creates a mapped PTE from a swapped entry (arch) |
+| __swp_entry_to_pte | Creates a swap PTE from a swp_entry_t (arch) |
+---------------------------+--------------------------------------------------+
-| __pmd_to_swp_entry | Creates a swapped entry (arch) from a mapped PMD |
+| __pmd_to_swp_entry | Creates a swp_entry_t (arch) from a swap PMD |
+---------------------------+--------------------------------------------------+
-| __swp_to_pmd_entry | Creates a mapped PMD from a swapped entry (arch) |
+| __swp_entry_to_pmd | Creates a swap PMD from a swp_entry_t (arch) |
+---------------------------+--------------------------------------------------+
| is_migration_entry | Tests a migration (read or write) swapped entry |
+-------------------------------+----------------------------------------------+
diff --git a/Documentation/mm/balance.rst b/Documentation/mm/balance.rst
index 6a1fadf3e173..c4962c89a7f5 100644
--- a/Documentation/mm/balance.rst
+++ b/Documentation/mm/balance.rst
@@ -1,12 +1,10 @@
-.. _balance:
-
================
Memory Balancing
================
Started Jan 2000 by Kanoj Sarcar <kanoj@sgi.com>
-Memory balancing is needed for !__GFP_ATOMIC and !__GFP_KSWAPD_RECLAIM as
+Memory balancing is needed for !__GFP_HIGH and !__GFP_KSWAPD_RECLAIM as
well as for non __GFP_IO allocations.
The first reason why a caller may avoid reclaim is that the caller can not
@@ -83,7 +81,7 @@ Page stealing from process memory and shm is done if stealing the page would
alleviate memory pressure on any zone in the page's node that has fallen below
its watermark.
-watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd: These
+watermark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd: These
are per-zone fields, used to determine when a zone needs to be balanced. When
the number of pages falls below watermark[WMARK_MIN], the hysteric field
low_on_memory gets set. This stays set till the number of free pages becomes
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 0cff6fac6b7e..2d8d8ca1e0a3 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -4,47 +4,93 @@
Design
======
-Configurable Layers
-===================
-
-DAMON provides data access monitoring functionality while making the accuracy
-and the overhead controllable. The fundamental access monitorings require
-primitives that dependent on and optimized for the target address space. On
-the other hand, the accuracy and overhead tradeoff mechanism, which is the core
-of DAMON, is in the pure logic space. DAMON separates the two parts in
-different layers and defines its interface to allow various low level
-primitives implementations configurable with the core logic. We call the low
-level primitives implementations monitoring operations.
-
-Due to this separated design and the configurable interface, users can extend
-DAMON for any address space by configuring the core logics with appropriate
-monitoring operations. If appropriate one is not provided, users can implement
-the operations on their own.
-For example, physical memory, virtual memory, swap space, those for specific
-processes, NUMA nodes, files, and backing memory devices would be supportable.
-Also, if some architectures or devices support special optimized access check
-primitives, those will be easily configurable.
+.. _damon_design_execution_model_and_data_structures:
+
+Execution Model and Data Structures
+===================================
+
+The monitoring-related information including the monitoring request
+specification and DAMON-based operation schemes are stored in a data structure
+called DAMON ``context``. DAMON executes each context with a kernel thread
+called ``kdamond``. Multiple kdamonds could run in parallel, for different
+types of monitoring.
+
+To know how user-space can do the configurations and start/stop DAMON, refer to
+:ref:`DAMON sysfs interface <sysfs_interface>` documentation.
+
+
+Overall Architecture
+====================
+
+DAMON subsystem is configured with three layers including
+
+- :ref:`Operations Set <damon_operations_set>`: Implements fundamental
+ operations for DAMON that depends on the given monitoring target
+ address-space and available set of software/hardware primitives,
+- :ref:`Core <damon_core_logic>`: Implements core logics including monitoring
+ overhead/accuracy control and access-aware system operations on top of the
+ operations set layer, and
+- :ref:`Modules <damon_modules>`: Implements kernel modules for various
+ purposes that provides interfaces for the user space, on top of the core
+ layer.
-Reference Implementations of Address Space Specific Monitoring Operations
-=========================================================================
+.. _damon_operations_set:
-The monitoring operations are defined in two parts:
+Operations Set Layer
+====================
+
+.. _damon_design_configurable_operations_set:
+
+For data access monitoring and additional low level work, DAMON needs a set of
+implementations for specific operations that are dependent on and optimized for
+the given target address space. For example, below two operations for access
+monitoring are address-space dependent.
1. Identification of the monitoring target address range for the address space.
2. Access check of specific address range in the target space.
-DAMON currently provides the implementations of the operations for the physical
-and virtual address spaces. Below two subsections describe how those work.
+DAMON consolidates these implementations in a layer called DAMON Operations
+Set, and defines the interface between it and the upper layer. The upper layer
+is dedicated for DAMON's core logics including the mechanism for control of the
+monitoring accuracy and the overhead.
+
+Hence, DAMON can easily be extended for any address space and/or available
+hardware features by configuring the core logic to use the appropriate
+operations set. If there is no available operations set for a given purpose, a
+new operations set can be implemented following the interface between the
+layers.
+
+For example, physical memory, virtual memory, swap space, those for specific
+processes, NUMA nodes, files, and backing memory devices would be supportable.
+Also, if some architectures or devices support special optimized access check
+features, those will be easily configurable.
+
+DAMON currently provides below three operation sets. Below three subsections
+describe how those work.
+
+ - vaddr: Monitor virtual address spaces of specific processes
+ - fvaddr: Monitor fixed virtual address ranges
+ - paddr: Monitor the physical address space of the system
+To know how user-space can do the configuration via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`operations <sysfs_context>` file part of the
+documentation.
+
+
+ .. _damon_design_vaddr_target_regions_construction:
VMA-based Target Address Range Construction
-------------------------------------------
-This is only for the virtual address space monitoring operations
-implementation. That for the physical address space simply asks users to
-manually set the monitoring target address ranges.
+A mechanism of ``vaddr`` DAMON operations set that automatically initializes
+and updates the monitoring target address regions so that entire memory
+mappings of the target processes can be covered.
+
+This mechanism is only for the ``vaddr`` operations set. In cases of
+``fvaddr`` and ``paddr`` operation sets, users are asked to manually set the
+monitoring target address ranges.
Only small parts in the super-huge virtual address space of the processes are
mapped to the physical memory and accessed. Thus, tracking the unmapped
@@ -89,18 +135,43 @@ the interference is the responsibility of sysadmins. However, it solves the
conflict with the reclaim logic using ``PG_idle`` and ``PG_young`` page flags,
as Idle page tracking does.
+.. _damon_design_addr_unit:
+
+Address Unit
+------------
+
+DAMON core layer uses ``unsinged long`` type for monitoring target address
+ranges. In some cases, the address space for a given operations set could be
+too large to be handled with the type. ARM (32-bit) with large physical
+address extension is an example. For such cases, a per-operations set
+parameter called ``address unit`` is provided. It represents the scale factor
+that need to be multiplied to the core layer's address for calculating real
+address on the given address space. Support of ``address unit`` parameter is
+up to each operations set implementation. ``paddr`` is the only operations set
+implementation that supports the parameter.
-Address Space Independent Core Mechanisms
-=========================================
+.. _damon_core_logic:
+
+Core Logics
+===========
+
+.. _damon_design_monitoring:
+
+Monitoring
+----------
Below four sections describe each of the DAMON core mechanisms and the five
monitoring attributes, ``sampling interval``, ``aggregation interval``,
``update interval``, ``minimum number of regions``, and ``maximum number of
regions``.
+To know how user-space can set the attributes via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`monitoring_attrs <sysfs_monitoring_attrs>`
+part of the documentation.
+
Access Frequency Monitoring
----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
The output of DAMON says what pages are how frequently accessed for a given
duration. The resolution of the access frequency is controlled by setting
@@ -126,8 +197,10 @@ The monitoring overhead of this mechanism will arbitrarily increase as the
size of the target workload grows.
+.. _damon_design_region_based_sampling:
+
Region Based Sampling
----------------------
+~~~~~~~~~~~~~~~~~~~~~
To avoid the unbounded increase of the overhead, DAMON groups adjacent pages
that assumed to have the same access frequencies into a region. As long as the
@@ -135,16 +208,19 @@ assumption (pages in a region have the same access frequencies) is kept, only
one page in the region is required to be checked. Thus, for each ``sampling
interval``, DAMON randomly picks one page in each region, waits for one
``sampling interval``, checks whether the page is accessed meanwhile, and
-increases the access frequency of the region if so. Therefore, the monitoring
-overhead is controllable by setting the number of regions. DAMON allows users
-to set the minimum and the maximum number of regions for the trade-off.
+increases the access frequency counter of the region if so. The counter is
+called ``nr_accesses`` of the region. Therefore, the monitoring overhead is
+controllable by setting the number of regions. DAMON allows users to set the
+minimum and the maximum number of regions for the trade-off.
This scheme, however, cannot preserve the quality of the output if the
assumption is not guaranteed.
+.. _damon_design_adaptive_regions_adjustment:
+
Adaptive Regions Adjustment
----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
Even somehow the initial monitoring target regions are well constructed to
fulfill the assumption (pages in same region have similar access frequencies),
@@ -152,18 +228,41 @@ the data access pattern can be dynamically changed. This will result in low
monitoring quality. To keep the assumption as much as possible, DAMON
adaptively merges and splits each region based on their access frequency.
-For each ``aggregation interval``, it compares the access frequencies of
-adjacent regions and merges those if the frequency difference is small. Then,
-after it reports and clears the aggregated access frequency of each region, it
-splits each region into two or three regions if the total number of regions
-will not exceed the user-specified maximum number of regions after the split.
+For each ``aggregation interval``, it compares the access frequencies
+(``nr_accesses``) of adjacent regions. If the difference is small, and if the
+sum of the two regions' sizes is smaller than the size of total regions divided
+by the ``minimum number of regions``, DAMON merges the two regions. If the
+resulting number of total regions is still higher than ``maximum number of
+regions``, it repeats the merging with increasing access frequenceis difference
+threshold until the upper-limit of the number of regions is met, or the
+threshold becomes higher than possible maximum value (``aggregation interval``
+divided by ``sampling interval``). Then, after it reports and clears the
+aggregated access frequency of each region, it splits each region into two or
+three regions if the total number of regions will not exceed the user-specified
+maximum number of regions after the split.
In this way, DAMON provides its best-effort quality and minimal overhead while
keeping the bounds users set for their trade-off.
+.. _damon_design_age_tracking:
+
+Age Tracking
+~~~~~~~~~~~~
+
+By analyzing the monitoring results, users can also find how long the current
+access pattern of a region has maintained. That could be used for good
+understanding of the access pattern. For example, page placement algorithm
+utilizing both the frequency and the recency could be implemented using that.
+To make such access pattern maintained period analysis easier, DAMON maintains
+yet another counter called ``age`` in each region. For each ``aggregation
+interval``, DAMON checks if the region's size and access frequency
+(``nr_accesses``) has significantly changed. If so, the counter is reset to
+zero. Otherwise, the counter is increased.
+
+
Dynamic Target Space Updates Handling
--------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The monitoring target address range could dynamically changed. For example,
virtual memory could be dynamically mapped and unmapped. Physical memory could
@@ -174,3 +273,555 @@ monitoring operations to check dynamic changes including memory mapping changes
and applies it to monitoring operations-related data structures such as the
abstracted monitoring target memory area only for each of a user-specified time
interval (``update interval``).
+
+User-space can get the monitoring results via DAMON sysfs interface and/or
+tracepoints. For more details, please refer to the documentations for
+:ref:`DAMOS tried regions <sysfs_schemes_tried_regions>` and :ref:`tracepoint`,
+respectively.
+
+
+.. _damon_design_monitoring_params_tuning_guide:
+
+Monitoring Parameters Tuning Guide
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In short, set ``aggregation interval`` to capture meaningful amount of accesses
+for the purpose. The amount of accesses can be measured using ``nr_accesses``
+and ``age`` of regions in the aggregated monitoring results snapshot. The
+default value of the interval, ``100ms``, turns out to be too short in many
+cases. Set ``sampling interval`` proportional to ``aggregation interval``. By
+default, ``1/20`` is recommended as the ratio.
+
+``Aggregation interval`` should be set as the time interval that the workload
+can make an amount of accesses for the monitoring purpose, within the interval.
+If the interval is too short, only small number of accesses are captured. As a
+result, the monitoring results look everything is samely accessed only rarely.
+For many purposes, that would be useless. If it is too long, however, the time
+to converge regions with the :ref:`regions adjustment mechanism
+<damon_design_adaptive_regions_adjustment>` can be too long, depending on the
+time scale of the given purpose. This could happen if the workload is actually
+making only rare accesses but the user thinks the amount of accesses for the
+monitoring purpose too high. For such cases, the target amount of access to
+capture per ``aggregation interval`` should carefully reconsidered. Also, note
+that the captured amount of accesses is represented with not only
+``nr_accesses``, but also ``age``. For example, even if every region on the
+monitoring results show zero ``nr_accesses``, regions could still be
+distinguished using ``age`` values as the recency information.
+
+Hence the optimum value of ``aggregation interval`` depends on the access
+intensiveness of the workload. The user should tune the interval based on the
+amount of access that captured on each aggregated snapshot of the monitoring
+results.
+
+Note that the default value of the interval is 100 milliseconds, which is too
+short in many cases, especially on large systems.
+
+``Sampling interval`` defines the resolution of each aggregation. If it is set
+too large, monitoring results will look like every region was samely rarely
+accessed, or samely frequently accessed. That is, regions become
+undistinguishable based on access pattern, and therefore the results will be
+useless in many use cases. If ``sampling interval`` is too small, it will not
+degrade the resolution, but will increase the monitoring overhead. If it is
+appropriate enough to provide a resolution of the monitoring results that
+sufficient for the given purpose, it shouldn't be unnecessarily further
+lowered. It is recommended to be set proportional to ``aggregation interval``.
+By default, the ratio is set as ``1/20``, and it is still recommended.
+
+Based on the manual tuning guide, DAMON provides more intuitive knob-based
+intervals auto tuning mechanism. Please refer to :ref:`the design document of
+the feature <damon_design_monitoring_intervals_autotuning>` for detail.
+
+Refer to below documents for an example tuning based on the above guide.
+
+.. toctree::
+ :maxdepth: 1
+
+ monitoring_intervals_tuning_example
+
+
+.. _damon_design_monitoring_intervals_autotuning:
+
+Monitoring Intervals Auto-tuning
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DAMON provides automatic tuning of the ``sampling interval`` and ``aggregation
+interval`` based on the :ref:`the tuning guide idea
+<damon_design_monitoring_params_tuning_guide>`. The tuning mechanism allows
+users to set the aimed amount of access events to observe via DAMON within
+given time interval. The target can be specified by the user as a ratio of
+DAMON-observed access events to the theoretical maximum amount of the events
+(``access_bp``) that measured within a given number of aggregations
+(``aggrs``).
+
+The DAMON-observed access events are calculated in byte granularity based on
+DAMON :ref:`region assumption <damon_design_region_based_sampling>`. For
+example, if a region of size ``X`` bytes of ``Y`` ``nr_accesses`` is found, it
+means ``X * Y`` access events are observed by DAMON. Theoretical maximum
+access events for the region is calculated in same way, but replacing ``Y``
+with theoretical maximum ``nr_accesses``, which can be calculated as
+``aggregation interval / sampling interval``.
+
+The mechanism calculates the ratio of access events for ``aggrs`` aggregations,
+and increases or decrease the ``sampleing interval`` and ``aggregation
+interval`` in same ratio, if the observed access ratio is lower or higher than
+the target, respectively. The ratio of the intervals change is decided in
+proportion to the distance between current samples ratio and the target ratio.
+
+The user can further set the minimum and maximum ``sampling interval`` that can
+be set by the tuning mechanism using two parameters (``min_sample_us`` and
+``max_sample_us``). Because the tuning mechanism changes ``sampling interval``
+and ``aggregation interval`` in same ratio always, the minimum and maximum
+``aggregation interval`` after each of the tuning changes can automatically set
+together.
+
+The tuning is turned off by default, and need to be set explicitly by the user.
+As a rule of thumbs and the Parreto principle, 4% access samples ratio target
+is recommended. Note that Parreto principle (80/20 rule) has applied twice.
+That is, assumes 4% (20% of 20%) DAMON-observed access events ratio (source)
+to capture 64% (80% multipled by 80%) real access events (outcomes).
+
+To know how user-space can use this feature via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`intervals_goal
+<damon_usage_sysfs_monitoring_intervals_goal>` part of the documentation.
+
+
+.. _damon_design_damos:
+
+Operation Schemes
+-----------------
+
+One common purpose of data access monitoring is access-aware system efficiency
+optimizations. For example,
+
+ paging out memory regions that are not accessed for more than two minutes
+
+or
+
+ using THP for memory regions that are larger than 2 MiB and showing a high
+ access frequency for more than one minute.
+
+One straightforward approach for such schemes would be profile-guided
+optimizations. That is, getting data access monitoring results of the
+workloads or the system using DAMON, finding memory regions of special
+characteristics by profiling the monitoring results, and making system
+operation changes for the regions. The changes could be made by modifying or
+providing advice to the software (the application and/or the kernel), or
+reconfiguring the hardware. Both offline and online approaches could be
+available.
+
+Among those, providing advice to the kernel at runtime would be flexible and
+effective, and therefore widely be used. However, implementing such schemes
+could impose unnecessary redundancy and inefficiency. The profiling could be
+redundant if the type of interest is common. Exchanging the information
+including monitoring results and operation advice between kernel and user
+spaces could be inefficient.
+
+To allow users to reduce such redundancy and inefficiencies by offloading the
+works, DAMON provides a feature called Data Access Monitoring-based Operation
+Schemes (DAMOS). It lets users specify their desired schemes at a high
+level. For such specifications, DAMON starts monitoring, finds regions having
+the access pattern of interest, and applies the user-desired operation actions
+to the regions, for every user-specified time interval called
+``apply_interval``.
+
+To know how user-space can set ``apply_interval`` via :ref:`DAMON sysfs
+interface <sysfs_interface>`, refer to :ref:`apply_interval_us <sysfs_scheme>`
+part of the documentation.
+
+
+.. _damon_design_damos_action:
+
+Operation Action
+~~~~~~~~~~~~~~~~
+
+The management action that the users desire to apply to the regions of their
+interest. For example, paging out, prioritizing for next reclamation victim
+selection, advising ``khugepaged`` to collapse or split, or doing nothing but
+collecting statistics of the regions.
+
+The list of supported actions is defined in DAMOS, but the implementation of
+each action is in the DAMON operations set layer because the implementation
+normally depends on the monitoring target address space. For example, the code
+for paging specific virtual address ranges out would be different from that for
+physical address ranges. And the monitoring operations implementation sets are
+not mandated to support all actions of the list. Hence, the availability of
+specific DAMOS action depends on what operations set is selected to be used
+together.
+
+The list of the supported actions, their meaning, and DAMON operations sets
+that supports each action are as below.
+
+ - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``pageout``: Reclaim the region.
+ Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set.
+ - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``.
+ Supported by ``vaddr`` and ``fvaddr`` operations set.
+ - ``lru_prio``: Prioritize the region on its LRU lists.
+ Supported by ``paddr`` operations set.
+ - ``lru_deprio``: Deprioritize the region on its LRU lists.
+ Supported by ``paddr`` operations set.
+ - ``migrate_hot``: Migrate the regions prioritizing warmer regions.
+ Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set.
+ - ``migrate_cold``: Migrate the regions prioritizing colder regions.
+ Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set.
+ - ``stat``: Do nothing but count the statistics.
+ Supported by all operations sets.
+
+Applying the actions except ``stat`` to a region is considered as changing the
+region's characteristics. Hence, DAMOS resets the age of regions when any such
+actions are applied to those.
+
+To know how user-space can set the action via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`action <sysfs_scheme>` part of the
+documentation.
+
+
+.. _damon_design_damos_access_pattern:
+
+Target Access Pattern
+~~~~~~~~~~~~~~~~~~~~~
+
+The access pattern of the schemes' interest. The patterns are constructed with
+the properties that DAMON's monitoring results provide, specifically the size,
+the access frequency, and the age. Users can describe their access pattern of
+interest by setting minimum and maximum values of the three properties. If a
+region's three properties are in the ranges, DAMOS classifies it as one of the
+regions that the scheme is having an interest in.
+
+To know how user-space can set the access pattern via :ref:`DAMON sysfs
+interface <sysfs_interface>`, refer to :ref:`access_pattern
+<sysfs_access_pattern>` part of the documentation.
+
+
+.. _damon_design_damos_quotas:
+
+Quotas
+~~~~~~
+
+DAMOS upper-bound overhead control feature. DAMOS could incur high overhead if
+the target access pattern is not properly tuned. For example, if a huge memory
+region having the access pattern of interest is found, applying the scheme's
+action to all pages of the huge region could consume unacceptably large system
+resources. Preventing such issues by tuning the access pattern could be
+challenging, especially if the access patterns of the workloads are highly
+dynamic.
+
+To mitigate that situation, DAMOS provides an upper-bound overhead control
+feature called quotas. It lets users specify an upper limit of time that DAMOS
+can use for applying the action, and/or a maximum bytes of memory regions that
+the action can be applied within a user-specified time duration.
+
+To know how user-space can set the basic quotas via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`quotas <sysfs_quotas>` part of the
+documentation.
+
+
+.. _damon_design_damos_quotas_prioritization:
+
+Prioritization
+^^^^^^^^^^^^^^
+
+A mechanism for making a good decision under the quotas. When the action
+cannot be applied to all regions of interest due to the quotas, DAMOS
+prioritizes regions and applies the action to only regions having high enough
+priorities so that it will not exceed the quotas.
+
+The prioritization mechanism should be different for each action. For example,
+rarely accessed (colder) memory regions would be prioritized for page-out
+scheme action. In contrast, the colder regions would be deprioritized for huge
+page collapse scheme action. Hence, the prioritization mechanisms for each
+action are implemented in each DAMON operations set, together with the actions.
+
+Though the implementation is up to the DAMON operations set, it would be common
+to calculate the priority using the access pattern properties of the regions.
+Some users would want the mechanisms to be personalized for their specific
+case. For example, some users would want the mechanism to weigh the recency
+(``age``) more than the access frequency (``nr_accesses``). DAMOS allows users
+to specify the weight of each access pattern property and passes the
+information to the underlying mechanism. Nevertheless, how and even whether
+the weight will be respected are up to the underlying prioritization mechanism
+implementation.
+
+To know how user-space can set the prioritization weights via :ref:`DAMON sysfs
+interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of
+the documentation.
+
+
+.. _damon_design_damos_quotas_auto_tuning:
+
+Aim-oriented Feedback-driven Auto-tuning
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Automatic feedback-driven quota tuning. Instead of setting the absolute quota
+value, users can specify the metric of their interest, and what target value
+they want the metric value to be. DAMOS then automatically tunes the
+aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS
+is under achieving the goal, DAMOS automatically increases the quota. If DAMOS
+is over achieving the goal, it decreases the quota.
+
+The goal can be specified with five parameters, namely ``target_metric``,
+``target_value``, ``current_value``, ``nid`` and ``path``. The auto-tuning
+mechanism tries to make ``current_value`` of ``target_metric`` be same to
+``target_value``.
+
+- ``user_input``: User-provided value. Users could use any metric that they
+ has interest in for the value. Use space main workload's latency or
+ throughput, system metrics like free memory ratio or memory pressure stall
+ time (PSI) could be examples. Note that users should explicitly set
+ ``current_value`` on their own in this case. In other words, users should
+ repeatedly provide the feedback.
+- ``some_mem_psi_us``: System-wide ``some`` memory pressure stall information
+ in microseconds that measured from last quota reset to next quota reset.
+ DAMOS does the measurement on its own, so only ``target_value`` need to be
+ set by users at the initial time. In other words, DAMOS does self-feedback.
+- ``node_mem_used_bp``: Specific NUMA node's used memory ratio in bp (1/10,000).
+- ``node_mem_free_bp``: Specific NUMA node's free memory ratio in bp (1/10,000).
+- ``node_memcg_used_bp``: Specific cgroup's node used memory ratio for a
+ specific NUMA node, in bp (1/10,000).
+- ``node_memcg_free_bp``: Specific cgroup's node unused memory ratio for a
+ specific NUMA node, in bp (1/10,000).
+
+``nid`` is optionally required for only ``node_mem_used_bp``,
+``node_mem_free_bp``, ``node_memcg_used_bp`` and ``node_memcg_free_bp`` to
+point the specific NUMA node.
+
+``path`` is optionally required for only ``node_memcg_used_bp`` and
+``node_memcg_free_bp`` to point the path to the cgroup. The value should be
+the path of the memory cgroup from the cgroups mount point.
+
+To know how user-space can set the tuning goal metric, the target value, and/or
+the current value via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to
+:ref:`quota goals <sysfs_schemes_quota_goals>` part of the documentation.
+
+
+.. _damon_design_damos_watermarks:
+
+Watermarks
+~~~~~~~~~~
+
+Conditional DAMOS (de)activation automation. Users might want DAMOS to run
+only under certain situations. For example, when a sufficient amount of free
+memory is guaranteed, running a scheme for proactive reclamation would only
+consume unnecessary system resources. To avoid such consumption, the user would
+need to manually monitor some metrics such as free memory ratio, and turn
+DAMON/DAMOS on or off.
+
+DAMOS allows users to offload such works using three watermarks. It allows the
+users to configure the metric of their interest, and three watermark values,
+namely high, middle, and low. If the value of the metric becomes above the
+high watermark or below the low watermark, the scheme is deactivated. If the
+metric becomes below the mid watermark but above the low watermark, the scheme
+is activated. If all schemes are deactivated by the watermarks, the monitoring
+is also deactivated. In this case, the DAMON worker thread only periodically
+checks the watermarks and therefore incurs nearly zero overhead.
+
+To know how user-space can set the watermarks via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`watermarks <sysfs_watermarks>` part of the
+documentation.
+
+
+.. _damon_design_damos_filters:
+
+Filters
+~~~~~~~
+
+Non-access pattern-based target memory regions filtering. If users run
+self-written programs or have good profiling tools, they could know something
+more than the kernel, such as future access patterns or some special
+requirements for specific types of memory. For example, some users may know
+only anonymous pages can impact their program's performance. They can also
+have a list of latency-critical processes.
+
+To let users optimize DAMOS schemes with such special knowledge, DAMOS provides
+a feature called DAMOS filters. The feature allows users to set an arbitrary
+number of filters for each scheme. Each filter specifies
+
+- a type of memory (``type``),
+- whether it is for the memory of the type or all except the type
+ (``matching``), and
+- whether it is to allow (include) or reject (exclude) applying
+ the scheme's action to the memory (``allow``).
+
+For efficient handling of filters, some types of filters are handled by the
+core layer, while others are handled by operations set. In the latter case,
+hence, support of the filter types depends on the DAMON operations set. In
+case of the core layer-handled filters, the memory regions that excluded by the
+filter are not counted as the scheme has tried to the region. In contrast, if
+a memory regions is filtered by an operations set layer-handled filter, it is
+counted as the scheme has tried. This difference affects the statistics.
+
+When multiple filters are installed, the group of filters that handled by the
+core layer are evaluated first. After that, the group of filters that handled
+by the operations layer are evaluated. Filters in each of the groups are
+evaluated in the installed order. If a part of memory is matched to one of the
+filter, next filters are ignored. If the part passes through the filters
+evaluation stage because it is not matched to any of the filters, applying the
+scheme's action to it depends on the last filter's allowance type. If the last
+filter was for allowing, the part of memory will be rejected, and vice versa.
+
+For example, let's assume 1) a filter for allowing anonymous pages and 2)
+another filter for rejecting young pages are installed in the order. If a page
+of a region that eligible to apply the scheme's action is an anonymous page,
+the scheme's action will be applied to the page regardless of whether it is
+young or not, since it matches with the first allow-filter. If the page is
+not anonymous but young, the scheme's action will not be applied, since the
+second reject-filter blocks it. If the page is neither anonymous nor young,
+the page will pass through the filters evaluation stage since there is no
+matching filter, and the action will be applied to the page.
+
+Below ``type`` of filters are currently supported.
+
+- Core layer handled
+ - addr
+ - Applied to pages that belonging to a given address range.
+ - target
+ - Applied to pages that belonging to a given DAMON monitoring target.
+- Operations layer handled, supported by only ``paddr`` operations set.
+ - anon
+ - Applied to pages that containing data that not stored in files.
+ - active
+ - Applied to active pages.
+ - memcg
+ - Applied to pages that belonging to a given cgroup.
+ - young
+ - Applied to pages that are accessed after the last access check from the
+ scheme.
+ - hugepage_size
+ - Applied to pages that managed in a given size range.
+ - unmapped
+ - Applied to pages that unmapped.
+
+To know how user-space can set the filters via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the
+documentation.
+
+.. _damon_design_damos_stat:
+
+Statistics
+~~~~~~~~~~
+
+The statistics of DAMOS behaviors that designed to help monitoring, tuning and
+debugging of DAMOS.
+
+DAMOS accounts below statistics for each scheme, from the beginning of the
+scheme's execution.
+
+- ``nr_tried``: Total number of regions that the scheme is tried to be applied.
+- ``sz_tried``: Total size of regions that the scheme is tried to be applied.
+- ``sz_ops_filter_passed``: Total bytes that passed operations set
+ layer-handled DAMOS filters.
+- ``nr_applied``: Total number of regions that the scheme is applied.
+- ``sz_applied``: Total size of regions that the scheme is applied.
+- ``qt_exceeds``: Total number of times the quota of the scheme has exceeded.
+
+"A scheme is tried to be applied to a region" means DAMOS core logic determined
+the region is eligible to apply the scheme's :ref:`action
+<damon_design_damos_action>`. The :ref:`access pattern
+<damon_design_damos_access_pattern>`, :ref:`quotas
+<damon_design_damos_quotas>`, :ref:`watermarks
+<damon_design_damos_watermarks>`, and :ref:`filters
+<damon_design_damos_filters>` that handled on core logic could affect this.
+The core logic will only ask the underlying :ref:`operation set
+<damon_operations_set>` to do apply the action to the region, so whether the
+action is really applied or not is unclear. That's why it is called "tried".
+
+"A scheme is applied to a region" means the :ref:`operation set
+<damon_operations_set>` has applied the action to at least a part of the
+region. The :ref:`filters <damon_design_damos_filters>` that handled by the
+operation set, and the types of the :ref:`action <damon_design_damos_action>`
+and the pages of the region can affect this. For example, if a filter is set
+to exclude anonymous pages and the region has only anonymous pages, or if the
+action is ``pageout`` while all pages of the region are unreclaimable, applying
+the action to the region will fail.
+
+To know how user-space can read the stats via :ref:`DAMON sysfs interface
+<sysfs_interface>`, refer to :ref:s`stats <sysfs_stats>` part of the
+documentation.
+
+Regions Walking
+~~~~~~~~~~~~~~~
+
+DAMOS feature allowing users access each region that a DAMOS action has just
+applied. Using this feature, DAMON :ref:`API <damon_design_api>` allows users
+access full properties of the regions including the access monitoring results
+and amount of the region's internal memory that passed the DAMOS filters.
+:ref:`DAMON sysfs interface <sysfs_interface>` also allows users read the data
+via special :ref:`files <sysfs_schemes_tried_regions>`.
+
+.. _damon_design_api:
+
+Application Programming Interface
+---------------------------------
+
+The programming interface for kernel space data access-aware applications.
+DAMON is a framework, so it does nothing by itself. Instead, it only helps
+other kernel components such as subsystems and modules building their data
+access-aware applications using DAMON's core features. For this, DAMON exposes
+its all features to other kernel components via its application programming
+interface, namely ``include/linux/damon.h``. Please refer to the API
+:doc:`document </mm/damon/api>` for details of the interface.
+
+
+.. _damon_modules:
+
+Modules
+=======
+
+Because the core of DAMON is a framework for kernel components, it doesn't
+provide any direct interface for the user space. Such interfaces should be
+implemented by each DAMON API user kernel components, instead. DAMON subsystem
+itself implements such DAMON API user modules, which are supposed to be used
+for general purpose DAMON control and special purpose data access-aware system
+operations, and provides stable application binary interfaces (ABI) for the
+user space. The user space can build their efficient data access-aware
+applications using the interfaces.
+
+
+General Purpose User Interface Modules
+--------------------------------------
+
+DAMON modules that provide user space ABIs for general purpose DAMON usage in
+runtime.
+
+Like many other ABIs, the modules create files on pseudo file systems like
+'sysfs', allow users to specify their requests to and get the answers from
+DAMON by writing to and reading from the files. As a response to such I/O,
+DAMON user interface modules control DAMON and retrieve the results as user
+requested via the DAMON API, and return the results to the user-space.
+
+The ABIs are designed to be used for user space applications development,
+rather than human beings' fingers. Human users are recommended to use such
+user space tools. One such Python-written user space tool is available at
+Github (https://github.com/damonitor/damo), Pypi
+(https://pypistats.org/packages/damo), and Fedora
+(https://packages.fedoraproject.org/pkgs/python-damo/damo/).
+
+Currently, one module for this type, namely 'DAMON sysfs interface' is
+available. Please refer to the ABI :ref:`doc <sysfs_interface>` for details of
+the interfaces.
+
+
+Special-Purpose Access-aware Kernel Modules
+-------------------------------------------
+
+DAMON modules that provide user space ABI for specific purpose DAMON usage.
+
+DAMON user interface modules are for full control of all DAMON features in
+runtime. For each special-purpose system-wide data access-aware system
+operations such as proactive reclamation or LRU lists balancing, the interfaces
+could be simplified by removing unnecessary knobs for the specific purpose, and
+extended for boot-time and even compile time control. Default values of DAMON
+control parameters for the usage would also need to be optimized for the
+purpose.
+
+To support such cases, yet more DAMON API user kernel modules that provide more
+simple and optimized user space interfaces are available. Currently, two
+modules for proactive reclamation and LRU lists manipulation are provided. For
+more detail, please read the usage documents for those
+(:doc:`/admin-guide/mm/damon/reclaim` and
+:doc:`/admin-guide/mm/damon/lru_sort`).
diff --git a/Documentation/mm/damon/faq.rst b/Documentation/mm/damon/faq.rst
index dde7e2414ee6..3279dc7a8211 100644
--- a/Documentation/mm/damon/faq.rst
+++ b/Documentation/mm/damon/faq.rst
@@ -4,29 +4,6 @@
Frequently Asked Questions
==========================
-Why a new subsystem, instead of extending perf or other user space tools?
-=========================================================================
-
-First, because it needs to be lightweight as much as possible so that it can be
-used online, any unnecessary overhead such as kernel - user space context
-switching cost should be avoided. Second, DAMON aims to be used by other
-programs including the kernel. Therefore, having a dependency on specific
-tools like perf is not desirable. These are the two biggest reasons why DAMON
-is implemented in the kernel space.
-
-
-Can 'idle pages tracking' or 'perf mem' substitute DAMON?
-=========================================================
-
-Idle page tracking is a low level primitive for access check of the physical
-address space. 'perf mem' is similar, though it can use sampling to minimize
-the overhead. On the other hand, DAMON is a higher-level framework for the
-monitoring of various address spaces. It is focused on memory management
-optimization and provides sophisticated accuracy/overhead handling mechanisms.
-Therefore, 'idle pages tracking' and 'perf mem' could provide a subset of
-DAMON's output, but cannot substitute DAMON.
-
-
Does DAMON support virtual memory only?
=======================================
diff --git a/Documentation/mm/damon/index.rst b/Documentation/mm/damon/index.rst
index 48c0bbff98b2..31c1fa955b3d 100644
--- a/Documentation/mm/damon/index.rst
+++ b/Documentation/mm/damon/index.rst
@@ -1,11 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0
-==========================
-DAMON: Data Access MONitor
-==========================
+================================================================
+DAMON: Data Access MONitoring and Access-aware System Operations
+================================================================
-DAMON is a data access monitoring framework subsystem for the Linux kernel.
-The core mechanisms of DAMON (refer to :doc:`design` for the detail) make it
+DAMON is a Linux kernel subsystem that provides a framework for data access
+monitoring and the monitoring results based system operations. The core
+monitoring :ref:`mechanisms <damon_design_monitoring>` of DAMON make it
- *accurate* (the monitoring output is useful enough for DRAM level memory
management; It might not appropriate for CPU Cache levels, though),
@@ -14,12 +15,17 @@ The core mechanisms of DAMON (refer to :doc:`design` for the detail) make it
- *scalable* (the upper-bound of the overhead is in constant range regardless
of the size of target workloads).
-Using this framework, therefore, the kernel's memory management mechanisms can
-make advanced decisions. Experimental memory management optimization works
-that incurring high data accesses monitoring overhead could implemented again.
-In user space, meanwhile, users who have some special workloads can write
-personalized applications for better understanding and optimizations of their
-workloads and systems.
+Using this framework, therefore, the kernel can operate system in an
+access-aware fashion. Because the features are also exposed to the :doc:`user
+space </admin-guide/mm/damon/index>`, users who have special information about
+their workloads can write personalized applications for better understanding
+and optimizations of their workloads and systems.
+
+For easier development of such systems, DAMON provides a feature called
+:ref:`DAMOS <damon_design_damos>` (DAMon-based Operation Schemes) in addition
+to the monitoring. Using the feature, DAMON users in both kernel and :doc:`user
+spaces </admin-guide/mm/damon/index>` can do access-aware system operations
+with no code but simple configurations.
.. toctree::
:maxdepth: 2
@@ -27,3 +33,13 @@ workloads and systems.
faq
design
api
+ maintainer-profile
+
+To utilize and control DAMON from the user-space, please refer to the
+administration :doc:`guide </admin-guide/mm/damon/index>`.
+
+If you prefer academic papers for reading and citations, please use the papers
+from `HPDC'22 <https://dl.acm.org/doi/abs/10.1145/3502181.3531466>`_ and
+`Middleware19 Industry <https://dl.acm.org/doi/abs/10.1145/3366626.3368125>`_ .
+Note that those cover DAMON implementations in Linux v5.16 and v5.15,
+respectively.
diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst
new file mode 100644
index 000000000000..e761edada1e9
--- /dev/null
+++ b/Documentation/mm/damon/maintainer-profile.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+DAMON Maintainer Entry Profile
+==============================
+
+The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR'
+section of 'MAINTAINERS' file.
+
+The mailing lists for the subsystem are damon@lists.linux.dev and
+linux-mm@kvack.org. Patches should be made against the `mm-new tree
+<https://git.kernel.org/akpm/mm/h/mm-new>`_ whenever possible and posted to the
+mailing lists.
+
+SCM Trees
+---------
+
+There are multiple Linux trees for DAMON development. Patches under
+development or testing are queued in `damon/next
+<https://git.kernel.org/sj/h/damon/next>`_ by the DAMON maintainer.
+Sufficiently reviewed patches will be queued in `mm-new
+<https://git.kernel.org/akpm/mm/h/mm-new>`_ by the memory management subsystem
+maintainer. As more sufficient tests are done, the patches will move to
+`mm-unstable <https://git.kernel.org/akpm/mm/h/mm-unstable>`_ and then to
+`mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>`_. And finally those
+will be pull-requested to the mainline by the memory management subsystem
+maintainer.
+
+Note again the patches for `mm-new tree
+<https://git.kernel.org/akpm/mm/h/mm-new>`_ are queued by the memory management
+subsystem maintainer. If the patches require some patches in `damon/next tree
+<https://git.kernel.org/sj/h/damon/next>`_ which have not yet merged in mm-new,
+please make sure the requirement is clearly specified.
+
+Submit checklist addendum
+-------------------------
+
+When making DAMON changes, you should do below.
+
+- Build changes related outputs including kernel and documents.
+- Ensure the builds introduce no new errors or warnings.
+- Run and ensure no new failures for DAMON `selftests
+ <https://github.com/damonitor/damon-tests/blob/master/corr/run.sh#L49>`_ and
+ `kunittests
+ <https://github.com/damonitor/damon-tests/blob/master/corr/tests/kunit.sh>`_.
+
+Further doing below and putting the results will be helpful.
+
+- Run `damon-tests/corr
+ <https://github.com/damonitor/damon-tests/tree/master/corr>`_ for normal
+ changes.
+- Run `damon-tests/perf
+ <https://github.com/damonitor/damon-tests/tree/master/perf>`_ for performance
+ changes.
+
+Key cycle dates
+---------------
+
+Patches can be sent anytime. Key cycle dates of the `mm-new
+<https://git.kernel.org/akpm/mm/h/mm-new>`_, `mm-unstable
+<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
+management subsystem maintainer.
+
+Review cadence
+--------------
+
+The DAMON maintainer does the work on the usual work hour (09:00 to 17:00,
+Mon-Fri) in PT (Pacific Time). The response to patches will occasionally be
+slow. Do not hesitate to send a ping if you have not heard back within a week
+of sending a patch.
+
+Mailing tool
+------------
+
+Like many other Linux kernel subsystems, DAMON uses the mailing lists
+(damon@lists.linux.dev and linux-mm@kvack.org) as the major communication
+channel. There is a simple tool called `HacKerMaiL
+<https://github.com/damonitor/hackermail>`_ (``hkml``), which is for people who
+are not very familiar with the mailing lists based communication. The tool
+could be particularly helpful for DAMON community members since it is developed
+and maintained by DAMON maintainer. The tool is also officially announced to
+support DAMON and general Linux kernel development workflow.
+
+In other words, `hkml <https://github.com/damonitor/hackermail>`_ is a mailing
+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
+the maintainer.
+
+Community meetup
+----------------
+
+DAMON community has a bi-weekly meetup series for members who prefer
+synchronous conversations over mails. It is for discussions on specific topics
+between a group of members including the maintainer. The maintainer shares the
+available time slots, and attendees should reserve one of those at least 24
+hours before the time slot, by reaching out to the maintainer.
+
+Schedules and reservation status are available at the Google `doc
+<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`_.
+There is also a public Google `calendar
+<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`_
+that has the events. Anyone can subscribe to it. DAMON maintainer will also
+provide periodic reminders to the mailing list (damon@lists.linux.dev).
diff --git a/Documentation/mm/damon/monitoring_intervals_tuning_example.rst b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst
new file mode 100644
index 000000000000..7207cbed591f
--- /dev/null
+++ b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst
@@ -0,0 +1,247 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================================================
+DAMON Moniting Interval Parameters Tuning Example
+=================================================
+
+DAMON's monitoring parameters need tuning based on given workload and the
+monitoring purpose. There is a :ref:`tuning guide
+<damon_design_monitoring_params_tuning_guide>` for that. This document
+provides an example tuning based on the guide.
+
+Setup
+=====
+
+For below example, DAMON of Linux kernel v6.11 and `damo
+<https://github.com/damonitor/damo>`_ (DAMON user-space tool) v2.5.9 was used to
+monitor and visualize access patterns on the physical address space of a system
+running a real-world server workload.
+
+5ms/100ms intervals: Too Short Interval
+=======================================
+
+Let's start by capturing the access pattern snapshot on the physical address
+space of the system using DAMON, with the default interval parameters (5
+milliseconds and 100 milliseconds for the sampling and the aggregation
+intervals, respectively). Wait ten minutes between the start of DAMON and
+the capturing of the snapshot, to show a meaningful time-wise access patterns.
+::
+
+ # damo start
+ # sleep 600
+ # damo record --snapshot 0 1
+ # damo stop
+
+Then, list the DAMON-found regions of different access patterns, sorted by the
+"access temperature". "Access temperature" is a metric representing the
+access-hotness of a region. It is calculated as a weighted sum of the access
+frequency and the age of the region. If the access frequency is 0 %, the
+temperature is multiplied by minus one. That is, if a region is not accessed,
+it gets minus temperature and it gets lower as not accessed for longer time.
+The sorting is in temperature-ascendint order, so the region at the top of the
+list is the coldest, and the one at the bottom is the hottest one. ::
+
+ # damo report access --sort_regions_by temperature
+ 0 addr 16.052 GiB size 5.985 GiB access 0 % age 5.900 s # coldest
+ 1 addr 22.037 GiB size 6.029 GiB access 0 % age 5.300 s
+ 2 addr 28.065 GiB size 6.045 GiB access 0 % age 5.200 s
+ 3 addr 10.069 GiB size 5.983 GiB access 0 % age 4.500 s
+ 4 addr 4.000 GiB size 6.069 GiB access 0 % age 4.400 s
+ 5 addr 62.008 GiB size 3.992 GiB access 0 % age 3.700 s
+ 6 addr 56.795 GiB size 5.213 GiB access 0 % age 3.300 s
+ 7 addr 39.393 GiB size 6.096 GiB access 0 % age 2.800 s
+ 8 addr 50.782 GiB size 6.012 GiB access 0 % age 2.800 s
+ 9 addr 34.111 GiB size 5.282 GiB access 0 % age 2.300 s
+ 10 addr 45.489 GiB size 5.293 GiB access 0 % age 1.800 s # hottest
+ total size: 62.000 GiB
+
+The list shows not seemingly hot regions, and only minimum access pattern
+diversity. Every region has zero access frequency. The number of region is
+10, which is the default ``min_nr_regions value``. Size of each region is also
+nearly identical. We can suspect this is because “adaptive regions adjustment”
+mechanism was not well working. As the guide suggested, we can get relative
+hotness of regions using ``age`` as the recency information. That would be
+better than nothing, but given the fact that the longest age is only about 6
+seconds while we waited about ten minutes, it is unclear how useful this will
+be.
+
+The temperature ranges to total size of regions of each range histogram
+visualization of the results also shows no interesting distribution pattern. ::
+
+ # damo report access --style temperature-sz-hist
+ <temperature> <total size>
+ [-,590,000,000, -,549,000,000) 5.985 GiB |********** |
+ [-,549,000,000, -,508,000,000) 12.074 GiB |********************|
+ [-,508,000,000, -,467,000,000) 0 B | |
+ [-,467,000,000, -,426,000,000) 12.052 GiB |********************|
+ [-,426,000,000, -,385,000,000) 0 B | |
+ [-,385,000,000, -,344,000,000) 3.992 GiB |******* |
+ [-,344,000,000, -,303,000,000) 5.213 GiB |********* |
+ [-,303,000,000, -,262,000,000) 12.109 GiB |********************|
+ [-,262,000,000, -,221,000,000) 5.282 GiB |********* |
+ [-,221,000,000, -,180,000,000) 0 B | |
+ [-,180,000,000, -,139,000,000) 5.293 GiB |********* |
+ total size: 62.000 GiB
+
+In short, the parameters provide poor quality monitoring results for hot
+regions detection. According to the :ref:`guide
+<damon_design_monitoring_params_tuning_guide>`, this is due to the too short
+aggregation interval.
+
+100ms/2s intervals: Starts Showing Small Hot Regions
+====================================================
+
+Following the guide, increase the interval 20 times (100 milliseocnds and 2
+seconds for sampling and aggregation intervals, respectively). ::
+
+ # damo start -s 100ms -a 2s
+ # sleep 600
+ # damo record --snapshot 0 1
+ # damo stop
+ # damo report access --sort_regions_by temperature
+ 0 addr 10.180 GiB size 6.117 GiB access 0 % age 7 m 8 s # coldest
+ 1 addr 49.275 GiB size 6.195 GiB access 0 % age 6 m 14 s
+ 2 addr 62.421 GiB size 3.579 GiB access 0 % age 6 m 4 s
+ 3 addr 40.154 GiB size 6.127 GiB access 0 % age 5 m 40 s
+ 4 addr 16.296 GiB size 6.182 GiB access 0 % age 5 m 32 s
+ 5 addr 34.254 GiB size 5.899 GiB access 0 % age 5 m 24 s
+ 6 addr 46.281 GiB size 2.995 GiB access 0 % age 5 m 20 s
+ 7 addr 28.420 GiB size 5.835 GiB access 0 % age 5 m 6 s
+ 8 addr 4.000 GiB size 6.180 GiB access 0 % age 4 m 16 s
+ 9 addr 22.478 GiB size 5.942 GiB access 0 % age 3 m 58 s
+ 10 addr 55.470 GiB size 915.645 MiB access 0 % age 3 m 6 s
+ 11 addr 56.364 GiB size 6.056 GiB access 0 % age 2 m 8 s
+ 12 addr 56.364 GiB size 4.000 KiB access 95 % age 16 s
+ 13 addr 49.275 GiB size 4.000 KiB access 100 % age 8 m 24 s # hottest
+ total size: 62.000 GiB
+ # damo report access --style temperature-sz-hist
+ <temperature> <total size>
+ [-42,800,000,000, -33,479,999,000) 22.018 GiB |***************** |
+ [-33,479,999,000, -24,159,998,000) 27.090 GiB |********************|
+ [-24,159,998,000, -14,839,997,000) 6.836 GiB |****** |
+ [-14,839,997,000, -5,519,996,000) 6.056 GiB |***** |
+ [-5,519,996,000, 3,800,005,000) 4.000 KiB |* |
+ [3,800,005,000, 13,120,006,000) 0 B | |
+ [13,120,006,000, 22,440,007,000) 0 B | |
+ [22,440,007,000, 31,760,008,000) 0 B | |
+ [31,760,008,000, 41,080,009,000) 0 B | |
+ [41,080,009,000, 50,400,010,000) 0 B | |
+ [50,400,010,000, 59,720,011,000) 4.000 KiB |* |
+ total size: 62.000 GiB
+
+DAMON found two distinct 4 KiB regions that pretty hot. The regions are also
+well aged. The hottest 4 KiB region was keeping the access frequency for about
+8 minutes, and the coldest region was keeping no access for about 7 minutes.
+The distribution on the histogram also looks like having a pattern.
+
+Especially, the finding of the 4 KiB regions among the 62 GiB total memory
+shows DAMON’s adaptive regions adjustment is working as designed.
+
+Still the number of regions is close to the ``min_nr_regions``, and sizes of
+cold regions are similar, though. Apparently it is improved, but it still has
+rooms to improve.
+
+400ms/8s intervals: Pretty Improved Results
+===========================================
+
+Increase the intervals four times (400 milliseconds and 8 seconds
+for sampling and aggregation intervals, respectively). ::
+
+ # damo start -s 400ms -a 8s
+ # sleep 600
+ # damo record --snapshot 0 1
+ # damo stop
+ # damo report access --sort_regions_by temperature
+ 0 addr 64.492 GiB size 1.508 GiB access 0 % age 6 m 48 s # coldest
+ 1 addr 21.749 GiB size 5.674 GiB access 0 % age 6 m 8 s
+ 2 addr 27.422 GiB size 5.801 GiB access 0 % age 6 m
+ 3 addr 49.431 GiB size 8.675 GiB access 0 % age 5 m 28 s
+ 4 addr 33.223 GiB size 5.645 GiB access 0 % age 5 m 12 s
+ 5 addr 58.321 GiB size 6.170 GiB access 0 % age 5 m 4 s
+ [...]
+ 25 addr 6.615 GiB size 297.531 MiB access 15 % age 0 ns
+ 26 addr 9.513 GiB size 12.000 KiB access 20 % age 0 ns
+ 27 addr 9.511 GiB size 108.000 KiB access 25 % age 0 ns
+ 28 addr 9.513 GiB size 20.000 KiB access 25 % age 0 ns
+ 29 addr 9.511 GiB size 12.000 KiB access 30 % age 0 ns
+ 30 addr 9.520 GiB size 4.000 KiB access 40 % age 0 ns
+ [...]
+ 41 addr 9.520 GiB size 4.000 KiB access 80 % age 56 s
+ 42 addr 9.511 GiB size 12.000 KiB access 100 % age 6 m 16 s
+ 43 addr 58.321 GiB size 4.000 KiB access 100 % age 6 m 24 s
+ 44 addr 9.512 GiB size 4.000 KiB access 100 % age 6 m 48 s
+ 45 addr 58.106 GiB size 4.000 KiB access 100 % age 6 m 48 s # hottest
+ total size: 62.000 GiB
+ # damo report access --style temperature-sz-hist
+ <temperature> <total size>
+ [-40,800,000,000, -32,639,999,000) 21.657 GiB |********************|
+ [-32,639,999,000, -24,479,998,000) 17.938 GiB |***************** |
+ [-24,479,998,000, -16,319,997,000) 16.885 GiB |**************** |
+ [-16,319,997,000, -8,159,996,000) 586.879 MiB |* |
+ [-8,159,996,000, 5,000) 4.946 GiB |***** |
+ [5,000, 8,160,006,000) 260.000 KiB |* |
+ [8,160,006,000, 16,320,007,000) 0 B | |
+ [16,320,007,000, 24,480,008,000) 0 B | |
+ [24,480,008,000, 32,640,009,000) 0 B | |
+ [32,640,009,000, 40,800,010,000) 16.000 KiB |* |
+ [40,800,010,000, 48,960,011,000) 8.000 KiB |* |
+ total size: 62.000 GiB
+
+The number of regions having different access patterns has significantly
+increased. Size of each region is also more varied. Total size of non-zero
+access frequency regions is also significantly increased. Maybe this is already
+good enough to make some meaningful memory management efficiency changes.
+
+800ms/16s intervals: Another bias
+=================================
+
+Further double the intervals (800 milliseconds and 16 seconds for sampling
+and aggregation intervals, respectively). The results is more improved for the
+hot regions detection, but starts looking degrading cold regions detection. ::
+
+ # damo start -s 800ms -a 16s
+ # sleep 600
+ # damo record --snapshot 0 1
+ # damo stop
+ # damo report access --sort_regions_by temperature
+ 0 addr 64.781 GiB size 1.219 GiB access 0 % age 4 m 48 s
+ 1 addr 24.505 GiB size 2.475 GiB access 0 % age 4 m 16 s
+ 2 addr 26.980 GiB size 504.273 MiB access 0 % age 4 m
+ 3 addr 29.443 GiB size 2.462 GiB access 0 % age 4 m
+ 4 addr 37.264 GiB size 5.645 GiB access 0 % age 4 m
+ 5 addr 31.905 GiB size 5.359 GiB access 0 % age 3 m 44 s
+ [...]
+ 20 addr 8.711 GiB size 40.000 KiB access 5 % age 2 m 40 s
+ 21 addr 27.473 GiB size 1.970 GiB access 5 % age 4 m
+ 22 addr 48.185 GiB size 4.625 GiB access 5 % age 4 m
+ 23 addr 47.304 GiB size 902.117 MiB access 10 % age 4 m
+ 24 addr 8.711 GiB size 4.000 KiB access 100 % age 4 m
+ 25 addr 20.793 GiB size 3.713 GiB access 5 % age 4 m 16 s
+ 26 addr 8.773 GiB size 4.000 KiB access 100 % age 4 m 16 s
+ total size: 62.000 GiB
+ # damo report access --style temperature-sz-hist
+ <temperature> <total size>
+ [-28,800,000,000, -23,359,999,000) 12.294 GiB |***************** |
+ [-23,359,999,000, -17,919,998,000) 9.753 GiB |************* |
+ [-17,919,998,000, -12,479,997,000) 15.131 GiB |********************|
+ [-12,479,997,000, -7,039,996,000) 0 B | |
+ [-7,039,996,000, -1,599,995,000) 7.506 GiB |********** |
+ [-1,599,995,000, 3,840,006,000) 6.127 GiB |********* |
+ [3,840,006,000, 9,280,007,000) 0 B | |
+ [9,280,007,000, 14,720,008,000) 136.000 KiB |* |
+ [14,720,008,000, 20,160,009,000) 40.000 KiB |* |
+ [20,160,009,000, 25,600,010,000) 11.188 GiB |*************** |
+ [25,600,010,000, 31,040,011,000) 4.000 KiB |* |
+ total size: 62.000 GiB
+
+It found more non-zero access frequency regions. The number of regions is still
+much higher than the ``min_nr_regions``, but it is reduced from that of the
+previous setup. And apparently the distribution seems bit biased to hot
+regions.
+
+Conclusion
+==========
+
+With the above experimental tuning results, we can conclude the theory and the
+guide makes sense to at least this workload, and could be applied to similar
+cases.
diff --git a/Documentation/mm/free_page_reporting.rst b/Documentation/mm/free_page_reporting.rst
index 8c05e62d8b2b..1468f71c261f 100644
--- a/Documentation/mm/free_page_reporting.rst
+++ b/Documentation/mm/free_page_reporting.rst
@@ -1,5 +1,3 @@
-.. _free_page_reporting:
-
=====================
Free Page Reporting
=====================
diff --git a/Documentation/mm/frontswap.rst b/Documentation/mm/frontswap.rst
deleted file mode 100644
index feecc5e24477..000000000000
--- a/Documentation/mm/frontswap.rst
+++ /dev/null
@@ -1,266 +0,0 @@
-.. _frontswap:
-
-=========
-Frontswap
-=========
-
-Frontswap provides a "transcendent memory" interface for swap pages.
-In some environments, dramatic performance savings may be obtained because
-swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
-
-.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
-
-Frontswap is so named because it can be thought of as the opposite of
-a "backing" store for a swap device. The storage is assumed to be
-a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
-to the requirements of transcendent memory (such as Xen's "tmem", or
-in-kernel compressed memory, aka "zcache", or future RAM-like devices);
-this pseudo-RAM device is not directly accessible or addressable by the
-kernel and is of unknown and possibly time-varying size. The driver
-links itself to frontswap by calling frontswap_register_ops to set the
-frontswap_ops funcs appropriately and the functions it provides must
-conform to certain policies as follows:
-
-An "init" prepares the device to receive frontswap pages associated
-with the specified swap device number (aka "type"). A "store" will
-copy the page to transcendent memory and associate it with the type and
-offset associated with the page. A "load" will copy the page, if found,
-from transcendent memory into kernel memory, but will NOT remove the page
-from transcendent memory. An "invalidate_page" will remove the page
-from transcendent memory and an "invalidate_area" will remove ALL pages
-associated with the swap type (e.g., like swapoff) and notify the "device"
-to refuse further stores with that swap type.
-
-Once a page is successfully stored, a matching load on the page will normally
-succeed. So when the kernel finds itself in a situation where it needs
-to swap out a page, it first attempts to use frontswap. If the store returns
-success, the data has been successfully saved to transcendent memory and
-a disk write and, if the data is later read back, a disk read are avoided.
-If a store returns failure, transcendent memory has rejected the data, and the
-page can be written to swap as usual.
-
-Note that if a page is stored and the page already exists in transcendent memory
-(a "duplicate" store), either the store succeeds and the data is overwritten,
-or the store fails AND the page is invalidated. This ensures stale data may
-never be obtained from frontswap.
-
-If properly configured, monitoring of frontswap is done via debugfs in
-the `/sys/kernel/debug/frontswap` directory. The effectiveness of
-frontswap can be measured (across all swap devices) with:
-
-``failed_stores``
- how many store attempts have failed
-
-``loads``
- how many loads were attempted (all should succeed)
-
-``succ_stores``
- how many store attempts have succeeded
-
-``invalidates``
- how many invalidates were attempted
-
-A backend implementation may provide additional metrics.
-
-FAQ
-===
-
-* Where's the value?
-
-When a workload starts swapping, performance falls through the floor.
-Frontswap significantly increases performance in many such workloads by
-providing a clean, dynamic interface to read and write swap pages to
-"transcendent memory" that is otherwise not directly addressable to the kernel.
-This interface is ideal when data is transformed to a different form
-and size (such as with compression) or secretly moved (as might be
-useful for write-balancing for some RAM-like devices). Swap pages (and
-evicted page-cache pages) are a great use for this kind of slower-than-RAM-
-but-much-faster-than-disk "pseudo-RAM device".
-
-Frontswap with a fairly small impact on the kernel,
-provides a huge amount of flexibility for more dynamic, flexible RAM
-utilization in various system configurations:
-
-In the single kernel case, aka "zcache", pages are compressed and
-stored in local memory, thus increasing the total anonymous pages
-that can be safely kept in RAM. Zcache essentially trades off CPU
-cycles used in compression/decompression for better memory utilization.
-Benchmarks have shown little or no impact when memory pressure is
-low while providing a significant performance improvement (25%+)
-on some workloads under high memory pressure.
-
-"RAMster" builds on zcache by adding "peer-to-peer" transcendent memory
-support for clustered systems. Frontswap pages are locally compressed
-as in zcache, but then "remotified" to another system's RAM. This
-allows RAM to be dynamically load-balanced back-and-forth as needed,
-i.e. when system A is overcommitted, it can swap to system B, and
-vice versa. RAMster can also be configured as a memory server so
-many servers in a cluster can swap, dynamically as needed, to a single
-server configured with a large amount of RAM... without pre-configuring
-how much of the RAM is available for each of the clients!
-
-In the virtual case, the whole point of virtualization is to statistically
-multiplex physical resources across the varying demands of multiple
-virtual machines. This is really hard to do with RAM and efforts to do
-it well with no kernel changes have essentially failed (except in some
-well-publicized special-case workloads).
-Specifically, the Xen Transcendent Memory backend allows otherwise
-"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
-virtual machines, but the pages can be compressed and deduplicated to
-optimize RAM utilization. And when guest OS's are induced to surrender
-underutilized RAM (e.g. with "selfballooning"), sudden unexpected
-memory pressure may result in swapping; frontswap allows those pages
-to be swapped to and from hypervisor RAM (if overall host system memory
-conditions allow), thus mitigating the potentially awful performance impact
-of unplanned swapping.
-
-A KVM implementation is underway and has been RFC'ed to lkml. And,
-using frontswap, investigation is also underway on the use of NVM as
-a memory extension technology.
-
-* Sure there may be performance advantages in some situations, but
- what's the space/time overhead of frontswap?
-
-If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into
-nothingness and the only overhead is a few extra bytes per swapon'ed
-swap device. If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
-registers, there is one extra global variable compared to zero for
-every swap page read or written. If CONFIG_FRONTSWAP is enabled
-AND a frontswap backend registers AND the backend fails every "store"
-request (i.e. provides no memory despite claiming it might),
-CPU overhead is still negligible -- and since every frontswap fail
-precedes a swap page write-to-disk, the system is highly likely
-to be I/O bound and using a small fraction of a percent of a CPU
-will be irrelevant anyway.
-
-As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend
-registers, one bit is allocated for every swap page for every swap
-device that is swapon'd. This is added to the EIGHT bits (which
-was sixteen until about 2.6.34) that the kernel already allocates
-for every swap page for every swap device that is swapon'd. (Hugh
-Dickins has observed that frontswap could probably steal one of
-the existing eight bits, but let's worry about that minor optimization
-later.) For very large swap disks (which are rare) on a standard
-4K pagesize, this is 1MB per 32GB swap.
-
-When swap pages are stored in transcendent memory instead of written
-out to disk, there is a side effect that this may create more memory
-pressure that can potentially outweigh the other advantages. A
-backend, such as zcache, must implement policies to carefully (but
-dynamically) manage memory limits to ensure this doesn't happen.
-
-* OK, how about a quick overview of what this frontswap patch does
- in terms that a kernel hacker can grok?
-
-Let's assume that a frontswap "backend" has registered during
-kernel initialization; this registration indicates that this
-frontswap backend has access to some "memory" that is not directly
-accessible by the kernel. Exactly how much memory it provides is
-entirely dynamic and random.
-
-Whenever a swap-device is swapon'd frontswap_init() is called,
-passing the swap device number (aka "type") as a parameter.
-This notifies frontswap to expect attempts to "store" swap pages
-associated with that number.
-
-Whenever the swap subsystem is readying a page to write to a swap
-device (c.f swap_writepage()), frontswap_store is called. Frontswap
-consults with the frontswap backend and if the backend says it does NOT
-have room, frontswap_store returns -1 and the kernel swaps the page
-to the swap device as normal. Note that the response from the frontswap
-backend is unpredictable to the kernel; it may choose to never accept a
-page, it could accept every ninth page, or it might accept every
-page. But if the backend does accept a page, the data from the page
-has already been copied and associated with the type and offset,
-and the backend guarantees the persistence of the data. In this case,
-frontswap sets a bit in the "frontswap_map" for the swap device
-corresponding to the page offset on the swap device to which it would
-otherwise have written the data.
-
-When the swap subsystem needs to swap-in a page (swap_readpage()),
-it first calls frontswap_load() which checks the frontswap_map to
-see if the page was earlier accepted by the frontswap backend. If
-it was, the page of data is filled from the frontswap backend and
-the swap-in is complete. If not, the normal swap-in code is
-executed to obtain the page of data from the real swap device.
-
-So every time the frontswap backend accepts a page, a swap device read
-and (potentially) a swap device write are replaced by a "frontswap backend
-store" and (possibly) a "frontswap backend loads", which are presumably much
-faster.
-
-* Can't frontswap be configured as a "special" swap device that is
- just higher priority than any real swap device (e.g. like zswap,
- or maybe swap-over-nbd/NFS)?
-
-No. First, the existing swap subsystem doesn't allow for any kind of
-swap hierarchy. Perhaps it could be rewritten to accommodate a hierarchy,
-but this would require fairly drastic changes. Even if it were
-rewritten, the existing swap subsystem uses the block I/O layer which
-assumes a swap device is fixed size and any page in it is linearly
-addressable. Frontswap barely touches the existing swap subsystem,
-and works around the constraints of the block I/O subsystem to provide
-a great deal of flexibility and dynamicity.
-
-For example, the acceptance of any swap page by the frontswap backend is
-entirely unpredictable. This is critical to the definition of frontswap
-backends because it grants completely dynamic discretion to the
-backend. In zcache, one cannot know a priori how compressible a page is.
-"Poorly" compressible pages can be rejected, and "poorly" can itself be
-defined dynamically depending on current memory constraints.
-
-Further, frontswap is entirely synchronous whereas a real swap
-device is, by definition, asynchronous and uses block I/O. The
-block I/O layer is not only unnecessary, but may perform "optimizations"
-that are inappropriate for a RAM-oriented device including delaying
-the write of some pages for a significant amount of time. Synchrony is
-required to ensure the dynamicity of the backend and to avoid thorny race
-conditions that would unnecessarily and greatly complicate frontswap
-and/or the block I/O subsystem. That said, only the initial "store"
-and "load" operations need be synchronous. A separate asynchronous thread
-is free to manipulate the pages stored by frontswap. For example,
-the "remotification" thread in RAMster uses standard asynchronous
-kernel sockets to move compressed frontswap pages to a remote machine.
-Similarly, a KVM guest-side implementation could do in-guest compression
-and use "batched" hypercalls.
-
-In a virtualized environment, the dynamicity allows the hypervisor
-(or host OS) to do "intelligent overcommit". For example, it can
-choose to accept pages only until host-swapping might be imminent,
-then force guests to do their own swapping.
-
-There is a downside to the transcendent memory specifications for
-frontswap: Since any "store" might fail, there must always be a real
-slot on a real swap device to swap the page. Thus frontswap must be
-implemented as a "shadow" to every swapon'd device with the potential
-capability of holding every page that the swap device might have held
-and the possibility that it might hold no pages at all. This means
-that frontswap cannot contain more pages than the total of swapon'd
-swap devices. For example, if NO swap device is configured on some
-installation, frontswap is useless. Swapless portable devices
-can still use frontswap but a backend for such devices must configure
-some kind of "ghost" swap device and ensure that it is never used.
-
-* Why this weird definition about "duplicate stores"? If a page
- has been previously successfully stored, can't it always be
- successfully overwritten?
-
-Nearly always it can, but no, sometimes it cannot. Consider an example
-where data is compressed and the original 4K page has been compressed
-to 1K. Now an attempt is made to overwrite the page with data that
-is non-compressible and so would take the entire 4K. But the backend
-has no more space. In this case, the store must be rejected. Whenever
-frontswap rejects a store that would overwrite, it also must invalidate
-the old data and ensure that it is no longer accessible. Since the
-swap subsystem then writes the new data to the read swap device,
-this is the correct course of action to ensure coherency.
-
-* Why does the frontswap patch create the new include file swapfile.h?
-
-The frontswap code depends on some swap-subsystem-internal data
-structures that have, over the years, moved back and forth between
-static and global. This seemed a reasonable compromise: Define
-them as global but declare them in a new include file that isn't
-included by the large number of source files that include swap.h.
-
-Dan Magenheimer, last updated April 9, 2012
diff --git a/Documentation/mm/highmem.rst b/Documentation/mm/highmem.rst
index 0f731d9196b0..9d92e3f2b3d6 100644
--- a/Documentation/mm/highmem.rst
+++ b/Documentation/mm/highmem.rst
@@ -1,5 +1,3 @@
-.. _highmem:
-
====================
High Memory Handling
====================
@@ -53,11 +51,15 @@ Temporary Virtual Mappings
The kernel contains several ways of creating temporary mappings. The following
list shows them in order of preference of use.
-* kmap_local_page(). This function is used to require short term mappings.
- It can be invoked from any context (including interrupts) but the mappings
- can only be used in the context which acquired them.
+* kmap_local_page(), kmap_local_folio() - These functions are used to create
+ short term mappings. They can be invoked from any context (including
+ interrupts) but the mappings can only be used in the context which acquired
+ them. The only differences between them consist in the first taking a pointer
+ to a struct page and the second taking a pointer to struct folio and the byte
+ offset within the folio which identifies the page.
- This function should be preferred, where feasible, over all the others.
+ These functions should always be used, whereas kmap_atomic() and kmap() have
+ been deprecated.
These mappings are thread-local and CPU-local, meaning that the mapping
can only be accessed from within this thread and the thread is bound to the
@@ -73,17 +75,17 @@ list shows them in order of preference of use.
maps of the outgoing task are saved and those of the incoming one are
restored.
- kmap_local_page() always returns a valid virtual address and it is assumed
- that kunmap_local() will never fail.
+ kmap_local_page(), as well as kmap_local_folio() always returns valid virtual
+ kernel addresses and it is assumed that kunmap_local() will never fail.
- On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the
+ On CONFIG_HIGHMEM=n kernels and for low memory pages they return the
virtual address of the direct mapping. Only real highmem pages are
temporarily mapped. Therefore, users may call a plain page_address()
for pages which are known to not come from ZONE_HIGHMEM. However, it is
- always safe to use kmap_local_page() / kunmap_local().
+ always safe to use kmap_local_{page,folio}() / kunmap_local().
- While it is significantly faster than kmap(), for the higmem case it
- comes with restrictions about the pointers validity. Contrary to kmap()
+ While they are significantly faster than kmap(), for the highmem case they
+ come with restrictions about the pointers validity. Contrary to kmap()
mappings, the local mappings are only valid in the context of the caller
and cannot be handed to other contexts. This implies that users must
be absolutely sure to keep the use of the return address local to the
@@ -92,7 +94,7 @@ list shows them in order of preference of use.
Most code can be designed to use thread local mappings. User should
therefore try to design their code to avoid the use of kmap() by mapping
pages in the same thread the address will be used and prefer
- kmap_local_page().
+ kmap_local_page() or kmap_local_folio().
Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain
extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered
@@ -100,10 +102,21 @@ list shows them in order of preference of use.
(included in the "Functions" section) for details on how to manage nested
mappings.
-* kmap_atomic(). This permits a very short duration mapping of a single
- page. Since the mapping is restricted to the CPU that issued it, it
- performs well, but the issuing task is therefore required to stay on that
- CPU until it has finished, lest some other task displace its mappings.
+* kmap_atomic(). This function has been deprecated; use kmap_local_page().
+
+ NOTE: Conversions to kmap_local_page() must take care to follow the mapping
+ restrictions imposed on kmap_local_page(). Furthermore, the code between
+ calls to kmap_atomic() and kunmap_atomic() may implicitly depend on the side
+ effects of atomic mappings, i.e. disabling page faults or preemption, or both.
+ In that case, explicit calls to pagefault_disable() or preempt_disable() or
+ both must be made in conjunction with the use of kmap_local_page().
+
+ [Legacy documentation]
+
+ This permits a very short duration mapping of a single page. Since the
+ mapping is restricted to the CPU that issued it, it performs well, but
+ the issuing task is therefore required to stay on that CPU until it has
+ finished, lest some other task displace its mappings.
kmap_atomic() may also be used by interrupt contexts, since it does not
sleep and the callers too may not sleep until after kunmap_atomic() is
@@ -115,11 +128,20 @@ list shows them in order of preference of use.
It is assumed that k[un]map_atomic() won't fail.
-* kmap(). This should be used to make short duration mapping of a single
- page with no restrictions on preemption or migration. It comes with an
- overhead as mapping space is restricted and protected by a global lock
- for synchronization. When mapping is no longer needed, the address that
- the page was mapped to must be released with kunmap().
+* kmap(). This function has been deprecated; use kmap_local_page().
+
+ NOTE: Conversions to kmap_local_page() must take care to follow the mapping
+ restrictions imposed on kmap_local_page(). In particular, it is necessary to
+ make sure that the kernel virtual memory pointer is only valid in the thread
+ that obtained it.
+
+ [Legacy documentation]
+
+ This should be used to make short duration mapping of a single page with no
+ restrictions on preemption or migration. It comes with an overhead as mapping
+ space is restricted and protected by a global lock for synchronization. When
+ mapping is no longer needed, the address that the page was mapped to must be
+ released with kunmap().
Mapping changes must be propagated across all the CPUs. kmap() also
requires global TLB invalidation when the kmap's pool wraps and it might
@@ -187,4 +209,5 @@ Functions
=========
.. kernel-doc:: include/linux/highmem.h
+.. kernel-doc:: mm/highmem.c
.. kernel-doc:: include/linux/highmem-internal.h
diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst
index f2a59ed82ed3..7d61b7a8b65b 100644
--- a/Documentation/mm/hmm.rst
+++ b/Documentation/mm/hmm.rst
@@ -1,5 +1,3 @@
-.. _hmm:
-
=====================================
Heterogeneous Memory Management (HMM)
=====================================
@@ -68,7 +66,7 @@ combinatorial explosion in the library entry points.
Finally, with the advance of high level language constructs (in C++ but in
other languages too) it is now possible for the compiler to leverage GPUs and
other devices without programmer knowledge. Some compiler identified patterns
-are only do-able with a shared address space. It is also more reasonable to use
+are only doable with a shared address space. It is also more reasonable to use
a shared address space for all other patterns.
@@ -165,16 +163,7 @@ use::
It will trigger a page fault on missing or read-only entries if write access is
requested (see below). Page faults use the generic mm page fault code path just
-like a CPU page fault.
-
-Both functions copy CPU page table entries into their pfns array argument. Each
-entry in that array corresponds to an address in the virtual range. HMM
-provides a set of flags to help the driver identify special CPU page table
-entries.
-
-Locking within the sync_cpu_device_pagetables() callback is the most important
-aspect the driver must respect in order to keep things properly synchronized.
-The usage pattern is::
+like a CPU page fault. The usage pattern is::
int driver_populate_range(...)
{
@@ -278,7 +267,7 @@ functions are designed to make drivers easier to write and to centralize common
code across drivers.
Before migrating pages to device private memory, special device private
-``struct page`` need to be created. These will be used as special "swap"
+``struct page`` needs to be created. These will be used as special "swap"
page table entries so that a CPU process will fault if it tries to access
a page that has been migrated to device private memory.
@@ -304,7 +293,7 @@ devm_memunmap_pages(), and devm_release_mem_region() when the resources can
be tied to a ``struct device``.
The overall migration steps are similar to migrating NUMA pages within system
-memory (see :ref:`Page migration <page_migration>`) but the steps are split
+memory (see Documentation/mm/page_migration.rst) but the steps are split
between device driver specific code and shared common code:
1. ``mmap_read_lock()``
@@ -333,7 +322,7 @@ between device driver specific code and shared common code:
The ``invalidate_range_start()`` callback is passed a
``struct mmu_notifier_range`` with the ``event`` field set to
``MMU_NOTIFY_MIGRATE`` and the ``owner`` field set to
- the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This is
+ the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This
allows the device driver to skip the invalidation callback and only
invalidate device private MMU mappings that are actually migrating.
This is explained more in the next section.
@@ -411,15 +400,15 @@ Exclusive access memory
Some devices have features such as atomic PTE bits that can be used to implement
atomic access to system memory. To support atomic operations to a shared virtual
memory page such a device needs access to that page which is exclusive of any
-userspace access from the CPU. The ``make_device_exclusive_range()`` function
+userspace access from the CPU. The ``make_device_exclusive()`` function
can be used to make a memory range inaccessible from userspace.
This replaces all mappings for pages in the given range with special swap
entries. Any attempt to access the swap entry results in a fault which is
-resovled by replacing the entry with the original mapping. A driver gets
+resolved by replacing the entry with the original mapping. A driver gets
notified that the mapping has been changed by MMU notifiers, after which point
it will no longer have exclusive access to the page. Exclusive access is
-guranteed to last until the driver drops the page lock and page reference, at
+guaranteed to last until the driver drops the page lock and page reference, at
which point any CPU faults on the page may proceed as described.
Memory cgroup (memcg) and rss accounting
@@ -442,7 +431,7 @@ Same decision was made for memory cgroup. Device memory pages are accounted
against same memory cgroup a regular page would be accounted to. This does
simplify migration to and from device memory. This also means that migration
back from device memory to regular memory cannot fail because it would
-go above memory cgroup limit. We might revisit this choice latter on once we
+go above memory cgroup limit. We might revisit this choice later on once we
get more experience in how device memory is used and its impact on memory
resource control.
diff --git a/Documentation/mm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst
index f143954e0d05..4914fbf07966 100644
--- a/Documentation/mm/hugetlbfs_reserv.rst
+++ b/Documentation/mm/hugetlbfs_reserv.rst
@@ -1,5 +1,3 @@
-.. _hugetlbfs_reserve:
-
=====================
Hugetlbfs Reservation
=====================
@@ -7,10 +5,10 @@ Hugetlbfs Reservation
Overview
========
-Huge pages as described at :ref:`hugetlbpage` are typically
-preallocated for application use. These huge pages are instantiated in a
-task's address space at page fault time if the VMA indicates huge pages are
-to be used. If no huge page exists at page fault time, the task is sent
+Huge pages as described at Documentation/admin-guide/mm/hugetlbpage.rst are
+typically preallocated for application use. These huge pages are instantiated
+in a task's address space at page fault time if the VMA indicates huge pages
+are to be used. If no huge page exists at page fault time, the task is sent
a SIGBUS and often dies an unhappy death. Shortly after huge page support
was added, it was determined that it would be better to detect a shortage
of huge pages at mmap() time. The idea is that if there were not enough
@@ -181,14 +179,14 @@ Consuming Reservations/Allocating a Huge Page
Reservations are consumed when huge pages associated with the reservations
are allocated and instantiated in the corresponding mapping. The allocation
-is performed within the routine alloc_huge_page()::
+is performed within the routine alloc_hugetlb_folio()::
- struct page *alloc_huge_page(struct vm_area_struct *vma,
+ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve)
-alloc_huge_page is passed a VMA pointer and a virtual address, so it can
+alloc_hugetlb_folio is passed a VMA pointer and a virtual address, so it can
consult the reservation map to determine if a reservation exists. In addition,
-alloc_huge_page takes the argument avoid_reserve which indicates reserves
+alloc_hugetlb_folio takes the argument avoid_reserve which indicates reserves
should not be used even if it appears they have been set aside for the
specified address. The avoid_reserve argument is most often used in the case
of Copy on Write and Page Migration where additional copies of an existing
@@ -208,7 +206,8 @@ a reservation for the allocation. After determining whether a reservation
exists and can be used for the allocation, the routine dequeue_huge_page_vma()
is called. This routine takes two arguments related to reservations:
-- avoid_reserve, this is the same value/argument passed to alloc_huge_page()
+- avoid_reserve, this is the same value/argument passed to
+ alloc_hugetlb_folio().
- chg, even though this argument is of type long only the values 0 or 1 are
passed to dequeue_huge_page_vma. If the value is 0, it indicates a
reservation exists (see the section "Memory Policy and Reservations" for
@@ -233,9 +232,9 @@ the scope reservations. Even if a surplus page is allocated, the same
reservation based adjustments as above will be made: SetPagePrivate(page) and
resv_huge_pages--.
-After obtaining a new huge page, (page)->private is set to the value of
-the subpool associated with the page if it exists. This will be used for
-subpool accounting when the page is freed.
+After obtaining a new hugetlb folio, (folio)->_hugetlb_subpool is set to the
+value of the subpool associated with the page if it exists. This will be used
+for subpool accounting when the folio is freed.
The routine vma_commit_reservation() is then called to adjust the reserve
map based on the consumption of the reservation. In general, this involves
@@ -246,8 +245,8 @@ was no reservation in a shared mapping or this was a private mapping a new
entry must be created.
It is possible that the reserve map could have been changed between the call
-to vma_needs_reservation() at the beginning of alloc_huge_page() and the
-call to vma_commit_reservation() after the page was allocated. This would
+to vma_needs_reservation() at the beginning of alloc_hugetlb_folio() and the
+call to vma_commit_reservation() after the folio was allocated. This would
be possible if hugetlb_reserve_pages was called for the same page in a shared
mapping. In such cases, the reservation count and subpool free page count
will be off by one. This rare condition can be identified by comparing the
@@ -272,12 +271,12 @@ to the global reservation count (resv_huge_pages).
Freeing Huge Pages
==================
-Huge page freeing is performed by the routine free_huge_page(). This routine
-is the destructor for hugetlbfs compound pages. As a result, it is only
-passed a pointer to the page struct. When a huge page is freed, reservation
-accounting may need to be performed. This would be the case if the page was
-associated with a subpool that contained reserves, or the page is being freed
-on an error path where a global reserve count must be restored.
+Huge pages are freed by free_huge_folio(). It is only passed a pointer
+to the folio as it is called from the generic MM code. When a huge page
+is freed, reservation accounting may need to be performed. This would
+be the case if the page was associated with a subpool that contained
+reserves, or the page is being freed on an error path where a global
+reserve count must be restored.
The page->private field points to any subpool associated with the page.
If the PagePrivate flag is set, it indicates the global reserve count should
@@ -526,7 +525,7 @@ However, there are several instances where errors are encountered after a huge
page is allocated but before it is instantiated. In this case, the page
allocation has consumed the reservation and made the appropriate subpool,
reservation map and global count adjustments. If the page is freed at this
-time (before instantiation and clearing of PagePrivate), then free_huge_page
+time (before instantiation and clearing of PagePrivate), then free_huge_folio
will increment the global reservation count. However, the reservation map
indicates the reservation was consumed. This resulting inconsistent state
will cause the 'leak' of a reserved huge page. The global reserve count will
diff --git a/Documentation/mm/hwpoison.rst b/Documentation/mm/hwpoison.rst
index b9d5253c1305..483b72aa7c11 100644
--- a/Documentation/mm/hwpoison.rst
+++ b/Documentation/mm/hwpoison.rst
@@ -1,5 +1,3 @@
-.. hwpoison:
-
========
hwpoison
========
@@ -50,7 +48,7 @@ of applications. KVM support requires a recent qemu-kvm release.
For the KVM use there was need for a new signal type so that
KVM can inject the machine check into the guest with the proper
address. This in theory allows other applications to handle
-memory failures too. The expection is that near all applications
+memory failures too. The expectation is that most applications
won't do that, but some very specialized ones might.
Failure recovery modes
diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
index 575ccd40e30c..7aa2a8886908 100644
--- a/Documentation/mm/index.rst
+++ b/Documentation/mm/index.rst
@@ -1,9 +1,6 @@
-=====================================
-Linux Memory Management Documentation
-=====================================
-
-Memory Management Guide
-=======================
+===============================
+Memory Management Documentation
+===============================
This is a guide to understanding the memory management subsystem
of Linux. If you are looking for advice on simply allocating memory,
@@ -23,34 +20,37 @@ see the :doc:`admin guide <../admin-guide/mm/index>`.
highmem
page_reclaim
swap
+ swap-table
page_cache
shmfs
oom
-Legacy Documentation
-====================
+Unsorted Documentation
+======================
-This is a collection of older documents about the Linux memory management
-(MM) subsystem internals with different level of details ranging from
-notes and mailing list responses for elaborating descriptions of data
-structures and algorithms. It should all be integrated nicely into the
-above structured documentation, or deleted if it has served its purpose.
+This is a collection of unsorted documents about the Linux memory management
+(MM) subsystem internals with different level of details ranging from notes and
+mailing list responses for elaborating descriptions of data structures and
+algorithms. It should all be integrated nicely into the above structured
+documentation, or deleted if it has served its purpose.
.. toctree::
:maxdepth: 1
active_mm
+ allocation-profiling
arch_pgtable_helpers
balance
damon/index
free_page_reporting
- frontswap
hmm
hwpoison
hugetlbfs_reserv
ksm
memory-model
+ memfd_preservation
mmu_notifier
+ multigen_lru
numa
overcommit-accounting
page_migration
@@ -58,11 +58,9 @@ above structured documentation, or deleted if it has served its purpose.
page_owner
page_table_check
remap_file_pages
- slub
split_page_table_lock
transhuge
unevictable-lru
vmalloced-kernel-stacks
vmemmap_dedup
- z3fold
zsmalloc
diff --git a/Documentation/mm/ksm.rst b/Documentation/mm/ksm.rst
index 9e37add068e6..2806e3e4a10e 100644
--- a/Documentation/mm/ksm.rst
+++ b/Documentation/mm/ksm.rst
@@ -1,5 +1,3 @@
-.. _ksm:
-
=======================
Kernel Samepage Merging
=======================
@@ -8,7 +6,7 @@ KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y,
added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation,
and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/
-The userspace interface of KSM is described in :ref:`Documentation/admin-guide/mm/ksm.rst <admin_guide_ksm>`
+The userspace interface of KSM is described in Documentation/admin-guide/mm/ksm.rst
Design
======
@@ -26,7 +24,7 @@ tree.
If a KSM page is shared between less than ``max_page_sharing`` VMAs,
the node of the stable tree that represents such KSM page points to a
-list of struct rmap_item and the ``page->mapping`` of the
+list of struct ksm_rmap_item and the ``page->mapping`` of the
KSM page points to the stable tree node.
When the sharing passes this threshold, KSM adds a second dimension to
diff --git a/Documentation/mm/memfd_preservation.rst b/Documentation/mm/memfd_preservation.rst
new file mode 100644
index 000000000000..66e0fb6d5ef0
--- /dev/null
+++ b/Documentation/mm/memfd_preservation.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================
+Memfd Preservation via LUO
+==========================
+
+.. kernel-doc:: mm/memfd_luo.c
+ :doc: Memfd Preservation via LUO
+
+Memfd Preservation ABI
+======================
+
+.. kernel-doc:: include/linux/kho/abi/memfd.h
+ :doc: DOC: memfd Live Update ABI
+
+.. kernel-doc:: include/linux/kho/abi/memfd.h
+ :internal:
+
+See Also
+========
+
+- :doc:`/core-api/liveupdate`
+- :doc:`/core-api/kho/concepts`
diff --git a/Documentation/mm/memory-model.rst b/Documentation/mm/memory-model.rst
index 3779e562dc76..7957122039e8 100644
--- a/Documentation/mm/memory-model.rst
+++ b/Documentation/mm/memory-model.rst
@@ -1,7 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _physical_memory_model:
-
=====================
Physical Memory Model
=====================
@@ -167,7 +165,7 @@ The users of `ZONE_DEVICE` are:
* pmem: Map platform persistent memory to be used as a direct-I/O target
via DAX mappings.
-* hmm: Extend `ZONE_DEVICE` with `->page_fault()` and `->page_free()`
+* hmm: Extend `ZONE_DEVICE` with `->page_fault()` and `->folio_free()`
event callbacks to allow a device-driver to coordinate memory management
events related to device-memory, typically GPU memory. See
Documentation/mm/hmm.rst.
diff --git a/Documentation/mm/mmu_notifier.rst b/Documentation/mm/mmu_notifier.rst
index df5d7777fc6b..c687bea4922f 100644
--- a/Documentation/mm/mmu_notifier.rst
+++ b/Documentation/mm/mmu_notifier.rst
@@ -1,5 +1,3 @@
-.. _mmu_notifier:
-
When do you need to notify inside page table lock ?
===================================================
diff --git a/Documentation/mm/multigen_lru.rst b/Documentation/mm/multigen_lru.rst
new file mode 100644
index 000000000000..52ed5092022f
--- /dev/null
+++ b/Documentation/mm/multigen_lru.rst
@@ -0,0 +1,269 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+Multi-Gen LRU
+=============
+The multi-gen LRU is an alternative LRU implementation that optimizes
+page reclaim and improves performance under memory pressure. Page
+reclaim decides the kernel's caching policy and ability to overcommit
+memory. It directly impacts the kswapd CPU usage and RAM efficiency.
+
+Design overview
+===============
+Objectives
+----------
+The design objectives are:
+
+* Good representation of access recency
+* Try to profit from spatial locality
+* Fast paths to make obvious choices
+* Simple self-correcting heuristics
+
+The representation of access recency is at the core of all LRU
+implementations. In the multi-gen LRU, each generation represents a
+group of pages with similar access recency. Generations establish a
+(time-based) common frame of reference and therefore help make better
+choices, e.g., between different memcgs on a computer or different
+computers in a data center (for job scheduling).
+
+Exploiting spatial locality improves efficiency when gathering the
+accessed bit. A rmap walk targets a single page and does not try to
+profit from discovering a young PTE. A page table walk can sweep all
+the young PTEs in an address space, but the address space can be too
+sparse to make a profit. The key is to optimize both methods and use
+them in combination.
+
+Fast paths reduce code complexity and runtime overhead. Unmapped pages
+do not require TLB flushes; clean pages do not require writeback.
+These facts are only helpful when other conditions, e.g., access
+recency, are similar. With generations as a common frame of reference,
+additional factors stand out. But obvious choices might not be good
+choices; thus self-correction is necessary.
+
+The benefits of simple self-correcting heuristics are self-evident.
+Again, with generations as a common frame of reference, this becomes
+attainable. Specifically, pages in the same generation can be
+categorized based on additional factors, and a feedback loop can
+statistically compare the refault percentages across those categories
+and infer which of them are better choices.
+
+Assumptions
+-----------
+The protection of hot pages and the selection of cold pages are based
+on page access channels and patterns. There are two access channels:
+
+* Accesses through page tables
+* Accesses through file descriptors
+
+The protection of the former channel is by design stronger because:
+
+1. The uncertainty in determining the access patterns of the former
+ channel is higher due to the approximation of the accessed bit.
+2. The cost of evicting the former channel is higher due to the TLB
+ flushes required and the likelihood of encountering the dirty bit.
+3. The penalty of underprotecting the former channel is higher because
+ applications usually do not prepare themselves for major page
+ faults like they do for blocked I/O. E.g., GUI applications
+ commonly use dedicated I/O threads to avoid blocking rendering
+ threads.
+
+There are also two access patterns:
+
+* Accesses exhibiting temporal locality
+* Accesses not exhibiting temporal locality
+
+For the reasons listed above, the former channel is assumed to follow
+the former pattern unless ``VM_SEQ_READ`` or ``VM_RAND_READ`` is
+present, and the latter channel is assumed to follow the latter
+pattern unless outlying refaults have been observed.
+
+Workflow overview
+=================
+Evictable pages are divided into multiple generations for each
+``lruvec``. The youngest generation number is stored in
+``lrugen->max_seq`` for both anon and file types as they are aged on
+an equal footing. The oldest generation numbers are stored in
+``lrugen->min_seq[]`` separately for anon and file types as clean file
+pages can be evicted regardless of swap constraints. These three
+variables are monotonically increasing.
+
+Generation numbers are truncated into ``order_base_2(MAX_NR_GENS+1)``
+bits in order to fit into the gen counter in ``folio->flags``. Each
+truncated generation number is an index to ``lrugen->folios[]``. The
+sliding window technique is used to track at least ``MIN_NR_GENS`` and
+at most ``MAX_NR_GENS`` generations. The gen counter stores a value
+within ``[1, MAX_NR_GENS]`` while a page is on one of
+``lrugen->folios[]``; otherwise it stores zero.
+
+Each generation is divided into multiple tiers. A page accessed ``N``
+times through file descriptors is in tier ``order_base_2(N)``. Unlike
+generations, tiers do not have dedicated ``lrugen->folios[]``. In
+contrast to moving across generations, which requires the LRU lock,
+moving across tiers only involves atomic operations on
+``folio->flags`` and therefore has a negligible cost. A feedback loop
+modeled after the PID controller monitors refaults over all the tiers
+from anon and file types and decides which tiers from which types to
+evict or protect. The desired effect is to balance refault percentages
+between anon and file types proportional to the swappiness level.
+
+There are two conceptually independent procedures: the aging and the
+eviction. They form a closed-loop system, i.e., the page reclaim.
+
+Aging
+-----
+The aging produces young generations. Given an ``lruvec``, it
+increments ``max_seq`` when ``max_seq-min_seq+1`` approaches
+``MIN_NR_GENS``. The aging promotes hot pages to the youngest
+generation when it finds them accessed through page tables; the
+demotion of cold pages happens consequently when it increments
+``max_seq``. The aging uses page table walks and rmap walks to find
+young PTEs. For the former, it iterates ``lruvec_memcg()->mm_list``
+and calls ``walk_page_range()`` with each ``mm_struct`` on this list
+to scan PTEs, and after each iteration, it increments ``max_seq``. For
+the latter, when the eviction walks the rmap and finds a young PTE,
+the aging scans the adjacent PTEs. For both, on finding a young PTE,
+the aging clears the accessed bit and updates the gen counter of the
+page mapped by this PTE to ``(max_seq%MAX_NR_GENS)+1``.
+
+Eviction
+--------
+The eviction consumes old generations. Given an ``lruvec``, it
+increments ``min_seq`` when ``lrugen->folios[]`` indexed by
+``min_seq%MAX_NR_GENS`` becomes empty. To select a type and a tier to
+evict from, it first compares ``min_seq[]`` to select the older type.
+If both types are equally old, it selects the one whose first tier has
+a lower refault percentage. The first tier contains single-use
+unmapped clean pages, which are the best bet. The eviction sorts a
+page according to its gen counter if the aging has found this page
+accessed through page tables and updated its gen counter. It also
+moves a page to the next generation, i.e., ``min_seq+1``, if this page
+was accessed multiple times through file descriptors and the feedback
+loop has detected outlying refaults from the tier this page is in. To
+this end, the feedback loop uses the first tier as the baseline, for
+the reason stated earlier.
+
+Working set protection
+----------------------
+Each generation is timestamped at birth. If ``lru_gen_min_ttl`` is
+set, an ``lruvec`` is protected from the eviction when its oldest
+generation was born within ``lru_gen_min_ttl`` milliseconds. In other
+words, it prevents the working set of ``lru_gen_min_ttl`` milliseconds
+from getting evicted. The OOM killer is triggered if this working set
+cannot be kept in memory.
+
+This time-based approach has the following advantages:
+
+1. It is easier to configure because it is agnostic to applications
+ and memory sizes.
+2. It is more reliable because it is directly wired to the OOM killer.
+
+``mm_struct`` list
+------------------
+An ``mm_struct`` list is maintained for each memcg, and an
+``mm_struct`` follows its owner task to the new memcg when this task
+is migrated.
+
+A page table walker iterates ``lruvec_memcg()->mm_list`` and calls
+``walk_page_range()`` with each ``mm_struct`` on this list to scan
+PTEs. When multiple page table walkers iterate the same list, each of
+them gets a unique ``mm_struct``, and therefore they can run in
+parallel.
+
+Page table walkers ignore any misplaced pages, e.g., if an
+``mm_struct`` was migrated, pages left in the previous memcg will be
+ignored when the current memcg is under reclaim. Similarly, page table
+walkers will ignore pages from nodes other than the one under reclaim.
+
+This infrastructure also tracks the usage of ``mm_struct`` between
+context switches so that page table walkers can skip processes that
+have been sleeping since the last iteration.
+
+Rmap/PT walk feedback
+---------------------
+Searching the rmap for PTEs mapping each page on an LRU list (to test
+and clear the accessed bit) can be expensive because pages from
+different VMAs (PA space) are not cache friendly to the rmap (VA
+space). For workloads mostly using mapped pages, searching the rmap
+can incur the highest CPU cost in the reclaim path.
+
+``lru_gen_look_around()`` exploits spatial locality to reduce the
+trips into the rmap. It scans the adjacent PTEs of a young PTE and
+promotes hot pages. If the scan was done cacheline efficiently, it
+adds the PMD entry pointing to the PTE table to the Bloom filter. This
+forms a feedback loop between the eviction and the aging.
+
+Bloom filters
+-------------
+Bloom filters are a space and memory efficient data structure for set
+membership test, i.e., test if an element is not in the set or may be
+in the set.
+
+In the eviction path, specifically, in ``lru_gen_look_around()``, if a
+PMD has a sufficient number of hot pages, its address is placed in the
+filter. In the aging path, set membership means that the PTE range
+will be scanned for young pages.
+
+Note that Bloom filters are probabilistic on set membership. If a test
+is false positive, the cost is an additional scan of a range of PTEs,
+which may yield hot pages anyway. Parameters of the filter itself can
+control the false positive rate in the limit.
+
+PID controller
+--------------
+A feedback loop modeled after the Proportional-Integral-Derivative
+(PID) controller monitors refaults over anon and file types and
+decides which type to evict when both types are available from the
+same generation.
+
+The PID controller uses generations rather than the wall clock as the
+time domain because a CPU can scan pages at different rates under
+varying memory pressure. It calculates a moving average for each new
+generation to avoid being permanently locked in a suboptimal state.
+
+Memcg LRU
+---------
+An memcg LRU is a per-node LRU of memcgs. It is also an LRU of LRUs,
+since each node and memcg combination has an LRU of folios (see
+``mem_cgroup_lruvec()``). Its goal is to improve the scalability of
+global reclaim, which is critical to system-wide memory overcommit in
+data centers. Note that memcg LRU only applies to global reclaim.
+
+The basic structure of an memcg LRU can be understood by an analogy to
+the active/inactive LRU (of folios):
+
+1. It has the young and the old (generations), i.e., the counterparts
+ to the active and the inactive;
+2. The increment of ``max_seq`` triggers promotion, i.e., the
+ counterpart to activation;
+3. Other events trigger similar operations, e.g., offlining an memcg
+ triggers demotion, i.e., the counterpart to deactivation.
+
+In terms of global reclaim, it has two distinct features:
+
+1. Sharding, which allows each thread to start at a random memcg (in
+ the old generation) and improves parallelism;
+2. Eventual fairness, which allows direct reclaim to bail out at will
+ and reduces latency without affecting fairness over some time.
+
+In terms of traversing memcgs during global reclaim, it improves the
+best-case complexity from O(n) to O(1) and does not affect the
+worst-case complexity O(n). Therefore, on average, it has a sublinear
+complexity.
+
+Summary
+-------
+The multi-gen LRU (of folios) can be disassembled into the following
+parts:
+
+* Generations
+* Rmap walks
+* Page table walks via ``mm_struct`` list
+* Bloom filters for rmap/PT walk feedback
+* PID controller for refault feedback
+
+The aging and the eviction form a producer-consumer model;
+specifically, the latter drives the former by the sliding window over
+generations. Within the aging, rmap walks drive page table walks by
+inserting hot densely populated page tables to the Bloom filters.
+Within the eviction, the PID controller uses refaults as the feedback
+to select types to evict and tiers to protect.
diff --git a/Documentation/mm/numa.rst b/Documentation/mm/numa.rst
index 99fdeca917ca..0f1b56809dca 100644
--- a/Documentation/mm/numa.rst
+++ b/Documentation/mm/numa.rst
@@ -1,5 +1,3 @@
-.. _numa:
-
Started Nov 1999 by Kanoj Sarcar <kanoj@sgi.com>
=============
@@ -64,7 +62,7 @@ In addition, for some architectures, again x86 is an example, Linux supports
the emulation of additional nodes. For NUMA emulation, linux will carve up
the existing nodes--or the system memory for non-NUMA platforms--into multiple
nodes. Each emulated node will manage a fraction of the underlying cells'
-physical memory. NUMA emluation is useful for testing NUMA kernel and
+physical memory. NUMA emulation is useful for testing NUMA kernel and
application features on non-NUMA platforms, and as a sort of memory resource
management mechanism when used together with cpusets.
[see Documentation/admin-guide/cgroup-v1/cpusets.rst]
@@ -110,7 +108,7 @@ to improve NUMA locality using various CPU affinity command line interfaces,
such as taskset(1) and numactl(1), and program interfaces such as
sched_setaffinity(2). Further, one can modify the kernel's default local
allocation behavior using Linux NUMA memory policy. [see
-:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`].
+Documentation/admin-guide/mm/numa_memory_policy.rst].
System administrators can restrict the CPUs and nodes' memories that a non-
privileged user can specify in the scheduling or NUMA commands and functions
diff --git a/Documentation/mm/overcommit-accounting.rst b/Documentation/mm/overcommit-accounting.rst
index a4895d6fc1c2..e2263477f6d5 100644
--- a/Documentation/mm/overcommit-accounting.rst
+++ b/Documentation/mm/overcommit-accounting.rst
@@ -8,8 +8,7 @@ The Linux kernel supports the following overcommit handling modes
Heuristic overcommit handling. Obvious overcommits of address
space are refused. Used for a typical system. It ensures a
seriously wild allocation fails while allowing overcommit to
- reduce swap usage. root is allowed to allocate slightly more
- memory in this mode. This is the default.
+ reduce swap usage. This is the default.
1
Always overcommit. Appropriate for some scientific
diff --git a/Documentation/mm/page_cache.rst b/Documentation/mm/page_cache.rst
index 75eba7c431b2..138d61f869df 100644
--- a/Documentation/mm/page_cache.rst
+++ b/Documentation/mm/page_cache.rst
@@ -3,3 +3,13 @@
==========
Page Cache
==========
+
+The page cache is the primary way that the user and the rest of the kernel
+interact with filesystems. It can be bypassed (e.g. with O_DIRECT),
+but normal reads, writes and mmaps go through the page cache.
+
+Folios
+======
+
+The folio is the unit of memory management within the page cache.
+Operations
diff --git a/Documentation/mm/page_frags.rst b/Documentation/mm/page_frags.rst
index 7d6f9385d129..503ca6cdb804 100644
--- a/Documentation/mm/page_frags.rst
+++ b/Documentation/mm/page_frags.rst
@@ -1,5 +1,3 @@
-.. _page_frags:
-
==============
Page fragments
==============
@@ -27,7 +25,7 @@ to be disabled when executing the fragment allocation.
The network stack uses two separate caches per CPU to handle fragment
allocation. The netdev_alloc_cache is used by callers making use of the
netdev_alloc_frag and __netdev_alloc_skb calls. The napi_alloc_cache is
-used by callers of the __napi_alloc_frag and __napi_alloc_skb calls. The
+used by callers of the __napi_alloc_frag and napi_alloc_skb calls. The
main difference between these two calls is the context in which they may be
called. The "netdev" prefixed functions are usable in any context as these
functions will disable interrupts, while the "napi" prefixed functions are
diff --git a/Documentation/mm/page_migration.rst b/Documentation/mm/page_migration.rst
index 11493bad7112..34602b254aa6 100644
--- a/Documentation/mm/page_migration.rst
+++ b/Documentation/mm/page_migration.rst
@@ -1,5 +1,3 @@
-.. _page_migration:
-
==============
Page migration
==============
@@ -9,8 +7,8 @@ nodes in a NUMA system while the process is running. This means that the
virtual addresses that the process sees do not change. However, the
system rearranges the physical location of those pages.
-Also see :ref:`Heterogeneous Memory Management (HMM) <hmm>`
-for migrating pages to or from device private memory.
+Also see Documentation/mm/hmm.rst for migrating pages to or from device
+private memory.
The main intent of page migration is to reduce the latency of memory accesses
by moving pages near to the processor where the process accessing that memory
@@ -65,32 +63,31 @@ and then a low level description of how the low level details work.
In kernel use of migrate_pages()
================================
-1. Remove pages from the LRU.
+1. Remove folios from the LRU.
- Lists of pages to be migrated are generated by scanning over
- pages and moving them into lists. This is done by
- calling isolate_lru_page().
- Calling isolate_lru_page() increases the references to the page
- so that it cannot vanish while the page migration occurs.
+ Lists of folios to be migrated are generated by scanning over
+ folios and moving them into lists. This is done by
+ calling folio_isolate_lru().
+ Calling folio_isolate_lru() increases the references to the folio
+ so that it cannot vanish while the folio migration occurs.
It also prevents the swapper or other scans from encountering
- the page.
+ the folio.
-2. We need to have a function of type new_page_t that can be
+2. We need to have a function of type new_folio_t that can be
passed to migrate_pages(). This function should figure out
- how to allocate the correct new page given the old page.
+ how to allocate the correct new folio given the old folio.
3. The migrate_pages() function is called which attempts
to do the migration. It will call the function to allocate
- the new page for each page that is considered for
- moving.
+ the new folio for each folio that is considered for moving.
How migrate_pages() works
=========================
-migrate_pages() does several passes over its list of pages. A page is moved
-if all references to a page are removable at the time. The page has
-already been removed from the LRU via isolate_lru_page() and the refcount
-is increased so that the page cannot be freed while page migration occurs.
+migrate_pages() does several passes over its list of folios. A folio is moved
+if all references to a folio are removable at the time. The folio has
+already been removed from the LRU via folio_isolate_lru() and the refcount
+is increased so that the folio cannot be freed while folio migration occurs.
Steps:
@@ -149,18 +146,33 @@ Steps:
18. The new page is moved to the LRU and can be scanned by the swapper,
etc. again.
-Non-LRU page migration
-======================
+movable_ops page migration
+==========================
+
+Selected typed, non-folio pages (e.g., pages inflated in a memory balloon,
+zsmalloc pages) can be migrated using the movable_ops migration framework.
+
+The "struct movable_operations" provide callbacks specific to a page type
+for isolating, migrating and un-isolating (putback) these pages.
+
+Once a page is indicated as having movable_ops, that condition must not
+change until the page was freed back to the buddy. This includes not
+changing/clearing the page type and not changing/clearing the
+PG_movable_ops page flag.
+
+Arbitrary drivers cannot currently make use of this framework, as it
+requires:
-Although migration originally aimed for reducing the latency of memory
-accesses for NUMA, compaction also uses migration to create high-order
-pages. For compaction purposes, it is also useful to be able to move
-non-LRU pages, such as zsmalloc and virtio-balloon pages.
+(a) a page type
+(b) indicating them as possibly having movable_ops in page_has_movable_ops()
+ based on the page type
+(c) returning the movable_ops from page_movable_ops() based on the page
+ type
+(d) not reusing the PG_movable_ops and PG_movable_ops_isolated page flags
+ for other purposes
-If a driver wants to make its pages movable, it should define a struct
-movable_operations. It then needs to call __SetPageMovable() on each
-page that it may be able to move. This uses the ``page->mapping`` field,
-so this field is not available for the driver to use for other purposes.
+For example, balloon drivers can make use of this framework through the
+balloon-compaction infrastructure residing in the core kernel.
Monitoring Migration
=====================
@@ -183,7 +195,7 @@ The following events (counters) can be used to monitor page migration.
4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split.
5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had
- to be split. After splitting, a migration retry was used for it's sub-pages.
+ to be split. After splitting, a migration retry was used for its sub-pages.
THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or
PGMIGRATE_FAIL events. For example, a THP migration failure will cause both
diff --git a/Documentation/mm/page_owner.rst b/Documentation/mm/page_owner.rst
index f5c954afe97c..6b12f3b007ec 100644
--- a/Documentation/mm/page_owner.rst
+++ b/Documentation/mm/page_owner.rst
@@ -1,5 +1,3 @@
-.. _page_owner:
-
==================================================
page owner: Tracking about who allocated each page
==================================================
@@ -26,6 +24,14 @@ fragmentation statistics can be obtained through gfp flag information of
each page. It is already implemented and activated if page owner is
enabled. Other usages are more than welcome.
+It can also be used to show all the stacks and their current number of
+allocated base pages, which gives us a quick overview of where the memory
+is going without the need to screen through all the pages and match the
+allocation and free operation. It's also possible to show only a numeric
+identifier of all the stacks (without stack traces) and their number of
+allocated base pages (faster to read and parse, eg, for monitoring) that
+can be matched with stacks later (show_handles and show_stacks_handles).
+
page owner is disabled by default. So, if you'd like to use it, you need
to add "page_owner=on" to your boot cmdline. If the kernel is built
with page owner and page owner is disabled in runtime due to not enabling
@@ -38,22 +44,10 @@ not affect to allocation performance, especially if the static keys jump
label patching functionality is available. Following is the kernel's code
size change due to this facility.
-- Without page owner::
-
- text data bss dec hex filename
- 48392 2333 644 51369 c8a9 mm/page_alloc.o
-
-- With page owner::
-
- text data bss dec hex filename
- 48800 2445 644 51889 cab1 mm/page_alloc.o
- 6662 108 29 6799 1a8f mm/page_owner.o
- 1025 8 8 1041 411 mm/page_ext.o
-
-Although, roughly, 8 KB code is added in total, page_alloc.o increase by
-520 bytes and less than half of it is in hotpath. Building the kernel with
-page owner and turning it on if needed would be great option to debug
-kernel memory problem.
+Although enabling page owner increases kernel size by several kilobytes,
+most of this code is outside page allocator and its hot path. Building
+the kernel with page owner and turning it on if needed would be great
+option to debug kernel memory problem.
There is one notice that is caused by implementation detail. page owner
stores information into the memory from struct page extension. This memory
@@ -64,7 +58,7 @@ pages are investigated and marked as allocated in initialization phase.
Although it doesn't mean that they have the right owner information,
at least, we can tell whether the page is allocated or not,
more accurately. On 2GB memory x86-64 VM box, 13343 early allocated pages
-are catched and marked, although they are mostly allocated from struct
+are caught and marked, although they are mostly allocated from struct
page extension feature. Anyway, after that, no page is left in
un-tracking state.
@@ -73,7 +67,7 @@ Usage
1) Build user-space helper::
- cd tools/vm
+ cd tools/mm
make page_owner_sort
2) Enable page owner: add "page_owner=on" to boot cmdline.
@@ -82,6 +76,76 @@ Usage
4) Analyze information from page owner::
+ cat /sys/kernel/debug/page_owner_stacks/show_stacks > stacks.txt
+ cat stacks.txt
+ post_alloc_hook+0x177/0x1a0
+ get_page_from_freelist+0xd01/0xd80
+ __alloc_pages+0x39e/0x7e0
+ allocate_slab+0xbc/0x3f0
+ ___slab_alloc+0x528/0x8a0
+ kmem_cache_alloc+0x224/0x3b0
+ sk_prot_alloc+0x58/0x1a0
+ sk_alloc+0x32/0x4f0
+ inet_create+0x427/0xb50
+ __sock_create+0x2e4/0x650
+ inet_ctl_sock_create+0x30/0x180
+ igmp_net_init+0xc1/0x130
+ ops_init+0x167/0x410
+ setup_net+0x304/0xa60
+ copy_net_ns+0x29b/0x4a0
+ create_new_namespaces+0x4a1/0x820
+ nr_base_pages: 16
+ ...
+ ...
+ echo 7000 > /sys/kernel/debug/page_owner_stacks/count_threshold
+ cat /sys/kernel/debug/page_owner_stacks/show_stacks> stacks_7000.txt
+ cat stacks_7000.txt
+ post_alloc_hook+0x177/0x1a0
+ get_page_from_freelist+0xd01/0xd80
+ __alloc_pages+0x39e/0x7e0
+ alloc_pages_mpol+0x22e/0x490
+ folio_alloc+0xd5/0x110
+ filemap_alloc_folio+0x78/0x230
+ page_cache_ra_order+0x287/0x6f0
+ filemap_get_pages+0x517/0x1160
+ filemap_read+0x304/0x9f0
+ xfs_file_buffered_read+0xe6/0x1d0 [xfs]
+ xfs_file_read_iter+0x1f0/0x380 [xfs]
+ __kernel_read+0x3b9/0x730
+ kernel_read_file+0x309/0x4d0
+ __do_sys_finit_module+0x381/0x730
+ do_syscall_64+0x8d/0x150
+ entry_SYSCALL_64_after_hwframe+0x62/0x6a
+ nr_base_pages: 20824
+ ...
+
+ cat /sys/kernel/debug/page_owner_stacks/show_handles > handles_7000.txt
+ cat handles_7000.txt
+ handle: 42
+ nr_base_pages: 20824
+ ...
+
+ cat /sys/kernel/debug/page_owner_stacks/show_stacks_handles > stacks_handles.txt
+ cat stacks_handles.txt
+ post_alloc_hook+0x177/0x1a0
+ get_page_from_freelist+0xd01/0xd80
+ __alloc_pages+0x39e/0x7e0
+ alloc_pages_mpol+0x22e/0x490
+ folio_alloc+0xd5/0x110
+ filemap_alloc_folio+0x78/0x230
+ page_cache_ra_order+0x287/0x6f0
+ filemap_get_pages+0x517/0x1160
+ filemap_read+0x304/0x9f0
+ xfs_file_buffered_read+0xe6/0x1d0 [xfs]
+ xfs_file_read_iter+0x1f0/0x380 [xfs]
+ __kernel_read+0x3b9/0x730
+ kernel_read_file+0x309/0x4d0
+ __do_sys_finit_module+0x381/0x730
+ do_syscall_64+0x8d/0x150
+ entry_SYSCALL_64_after_hwframe+0x62/0x6a
+ handle: 42
+ ...
+
cat /sys/kernel/debug/page_owner > page_owner_full.txt
./page_owner_sort page_owner_full.txt sorted_page_owner.txt
@@ -94,6 +158,11 @@ Usage
Page allocated via order XXX, ...
PFN XXX ...
// Detailed stack
+ By default, it will do full pfn dump, to start with a given pfn,
+ page_owner supports fseek.
+
+ FILE *fp = fopen("/sys/kernel/debug/page_owner", "r");
+ fseek(fp, pfn_start, SEEK_SET);
The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows
in buf, uses regexp to extract the page order value, counts the times
@@ -185,7 +254,7 @@ STANDARD FORMAT SPECIFIERS
at alloc_ts timestamp of the page when it was allocated
ator allocator memory allocator for pages
- For --curl option:
+ For --cull option:
KEY LONG DESCRIPTION
p pid process ID
diff --git a/Documentation/mm/page_table_check.rst b/Documentation/mm/page_table_check.rst
index 1a09472f10a3..c59f22eb6a0f 100644
--- a/Documentation/mm/page_table_check.rst
+++ b/Documentation/mm/page_table_check.rst
@@ -1,7 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _page_table_check:
-
================
Page Table Check
================
@@ -16,7 +14,7 @@ Page table check performs extra verifications at the time when new pages become
accessible from the userspace by getting their page table entries (PTEs PMDs
etc.) added into the table.
-In case of detected corruption, the kernel is crashed. There is a small
+In case of most detected corruption, the kernel is crashed. There is a small
performance and memory overhead associated with the page table check. Therefore,
it is disabled by default, but can be optionally enabled on systems where the
extra hardening outweighs the performance costs. Also, because page table check
@@ -24,6 +22,13 @@ is synchronous, it can help with debugging double map memory corruption issues,
by crashing kernel at the time wrong mapping occurs instead of later which is
often the case with memory corruptions bugs.
+It can also be used to do page table entry checks over various flags, dump
+warnings when illegal combinations of entry flags are detected. Currently,
+userfaultfd is the only user of such to sanity check wr-protect bit against
+any writable flags. Illegal flag combinations will not directly cause data
+corruption in this case immediately, but that will cause read-only data to
+be writable, leading to corrupt when the page content is later modified.
+
Double mapping detection logic
==============================
@@ -54,3 +59,22 @@ Build kernel with:
Optionally, build kernel with PAGE_TABLE_CHECK_ENFORCED in order to have page
table support without extra kernel parameter.
+
+Implementation notes
+====================
+
+We specifically decided not to use VMA information in order to avoid relying on
+MM states (except for limited "struct page" info). The page table check is a
+separate from Linux-MM state machine that verifies that the user accessible
+pages are not falsely shared.
+
+PAGE_TABLE_CHECK depends on EXCLUSIVE_SYSTEM_RAM. The reason is that without
+EXCLUSIVE_SYSTEM_RAM, users are allowed to map arbitrary physical memory
+regions into the userspace via /dev/mem. At the same time, pages may change
+their properties (e.g., from anonymous pages to named pages) while they are
+still being mapped in the userspace, leading to "corruption" detected by the
+page table check.
+
+Even with EXCLUSIVE_SYSTEM_RAM, I/O pages may be still allowed to be mapped via
+/dev/mem. However, these pages are always considered as named pages, so they
+won't break the logic used in the page table check.
diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_tables.rst
index 96939571d7bc..e7c69cc32493 100644
--- a/Documentation/mm/page_tables.rst
+++ b/Documentation/mm/page_tables.rst
@@ -3,3 +3,279 @@
===========
Page Tables
===========
+
+Paged virtual memory was invented along with virtual memory as a concept in
+1962 on the Ferranti Atlas Computer which was the first computer with paged
+virtual memory. The feature migrated to newer computers and became a de facto
+feature of all Unix-like systems as time went by. In 1985 the feature was
+included in the Intel 80386, which was the CPU Linux 1.0 was developed on.
+
+Page tables map virtual addresses as seen by the CPU into physical addresses
+as seen on the external memory bus.
+
+Linux defines page tables as a hierarchy which is currently five levels in
+height. The architecture code for each supported architecture will then
+map this to the restrictions of the hardware.
+
+The physical address corresponding to the virtual address is often referenced
+by the underlying physical page frame. The **page frame number** or **pfn**
+is the physical address of the page (as seen on the external memory bus)
+divided by `PAGE_SIZE`.
+
+Physical memory address 0 will be *pfn 0* and the highest pfn will be
+the last page of physical memory the external address bus of the CPU can
+address.
+
+With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at
+address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000
+and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are
+at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3ffff.
+
+As you can see, with 4KB pages the page base address uses bits 12-31 of the
+address, and this is why `PAGE_SHIFT` in this case is defined as 12 and
+`PAGE_SIZE` is usually defined in terms of the page shift as `(1 << PAGE_SHIFT)`
+
+Over time a deeper hierarchy has been developed in response to increasing memory
+sizes. When Linux was created, 4KB pages and a single page table called
+`swapper_pg_dir` with 1024 entries was used, covering 4MB which coincided with
+the fact that Torvald's first computer had 4MB of physical memory. Entries in
+this single table were referred to as *PTE*:s - page table entries.
+
+The software page table hierarchy reflects the fact that page table hardware has
+become hierarchical and that in turn is done to save page table memory and
+speed up mapping.
+
+One could of course imagine a single, linear page table with enormous amounts
+of entries, breaking down the whole memory into single pages. Such a page table
+would be very sparse, because large portions of the virtual memory usually
+remains unused. By using hierarchical page tables large holes in the virtual
+address space does not waste valuable page table memory, because it will suffice
+to mark large areas as unmapped at a higher level in the page table hierarchy.
+
+Additionally, on modern CPUs, a higher level page table entry can point directly
+to a physical memory range, which allows mapping a contiguous range of several
+megabytes or even gigabytes in a single high-level page table entry, taking
+shortcuts in mapping virtual memory to physical memory: there is no need to
+traverse deeper in the hierarchy when you find a large mapped range like this.
+
+The page table hierarchy has now developed into this::
+
+ +-----+
+ | PGD |
+ +-----+
+ |
+ | +-----+
+ +-->| P4D |
+ +-----+
+ |
+ | +-----+
+ +-->| PUD |
+ +-----+
+ |
+ | +-----+
+ +-->| PMD |
+ +-----+
+ |
+ | +-----+
+ +-->| PTE |
+ +-----+
+
+
+Symbols on the different levels of the page table hierarchy have the following
+meaning beginning from the bottom:
+
+- **pte**, `pte_t`, `pteval_t` = **Page Table Entry** - mentioned earlier.
+ The *pte* is an array of `PTRS_PER_PTE` elements of the `pteval_t` type, each
+ mapping a single page of virtual memory to a single page of physical memory.
+ The architecture defines the size and contents of `pteval_t`.
+
+ A typical example is that the `pteval_t` is a 32- or 64-bit value with the
+ upper bits being a **pfn** (page frame number), and the lower bits being some
+ architecture-specific bits such as memory protection.
+
+ The **entry** part of the name is a bit confusing because while in Linux 1.0
+ this did refer to a single page table entry in the single top level page
+ table, it was retrofitted to be an array of mapping elements when two-level
+ page tables were first introduced, so the *pte* is the lowermost page
+ *table*, not a page table *entry*.
+
+- **pmd**, `pmd_t`, `pmdval_t` = **Page Middle Directory**, the hierarchy right
+ above the *pte*, with `PTRS_PER_PMD` references to the *pte*:s.
+
+- **pud**, `pud_t`, `pudval_t` = **Page Upper Directory** was introduced after
+ the other levels to handle 4-level page tables. It is potentially unused,
+ or *folded* as we will discuss later.
+
+- **p4d**, `p4d_t`, `p4dval_t` = **Page Level 4 Directory** was introduced to
+ handle 5-level page tables after the *pud* was introduced. Now it was clear
+ that we needed to replace *pgd*, *pmd*, *pud* etc with a figure indicating the
+ directory level and that we cannot go on with ad hoc names any more. This
+ is only used on systems which actually have 5 levels of page tables, otherwise
+ it is folded.
+
+- **pgd**, `pgd_t`, `pgdval_t` = **Page Global Directory** - the Linux kernel
+ main page table handling the PGD for the kernel memory is still found in
+ `swapper_pg_dir`, but each userspace process in the system also has its own
+ memory context and thus its own *pgd*, found in `struct mm_struct` which
+ in turn is referenced to in each `struct task_struct`. So tasks have memory
+ context in the form of a `struct mm_struct` and this in turn has a
+ `struct pgt_t *pgd` pointer to the corresponding page global directory.
+
+To repeat: each level in the page table hierarchy is a *array of pointers*, so
+the **pgd** contains `PTRS_PER_PGD` pointers to the next level below, **p4d**
+contains `PTRS_PER_P4D` pointers to **pud** items and so on. The number of
+pointers on each level is architecture-defined.::
+
+ PMD
+ --> +-----+ PTE
+ | ptr |-------> +-----+
+ | ptr |- | ptr |-------> PAGE
+ | ptr | \ | ptr |
+ | ptr | \ ...
+ | ... | \
+ | ptr | \ PTE
+ +-----+ +----> +-----+
+ | ptr |-------> PAGE
+ | ptr |
+ ...
+
+
+Page Table Folding
+==================
+
+If the architecture does not use all the page table levels, they can be *folded*
+which means skipped, and all operations performed on page tables will be
+compile-time augmented to just skip a level when accessing the next lower
+level.
+
+Page table handling code that wishes to be architecture-neutral, such as the
+virtual memory manager, will need to be written so that it traverses all of the
+currently five levels. This style should also be preferred for
+architecture-specific code, so as to be robust to future changes.
+
+
+MMU, TLB, and Page Faults
+=========================
+
+The `Memory Management Unit (MMU)` is a hardware component that handles virtual
+to physical address translations. It may use relatively small caches in hardware
+called `Translation Lookaside Buffers (TLBs)` and `Page Walk Caches` to speed up
+these translations.
+
+When CPU accesses a memory location, it provides a virtual address to the MMU,
+which checks if there is the existing translation in the TLB or in the Page
+Walk Caches (on architectures that support them). If no translation is found,
+MMU uses the page walks to determine the physical address and create the map.
+
+The dirty bit for a page is set (i.e., turned on) when the page is written to.
+Each page of memory has associated permission and dirty bits. The latter
+indicate that the page has been modified since it was loaded into memory.
+
+If nothing prevents it, eventually the physical memory can be accessed and the
+requested operation on the physical frame is performed.
+
+There are several reasons why the MMU can't find certain translations. It could
+happen because the CPU is trying to access memory that the current task is not
+permitted to, or because the data is not present into physical memory.
+
+When these conditions happen, the MMU triggers page faults, which are types of
+exceptions that signal the CPU to pause the current execution and run a special
+function to handle the mentioned exceptions.
+
+There are common and expected causes of page faults. These are triggered by
+process management optimization techniques called "Lazy Allocation" and
+"Copy-on-Write". Page faults may also happen when frames have been swapped out
+to persistent storage (swap partition or file) and evicted from their physical
+locations.
+
+These techniques improve memory efficiency, reduce latency, and minimize space
+occupation. This document won't go deeper into the details of "Lazy Allocation"
+and "Copy-on-Write" because these subjects are out of scope as they belong to
+Process Address Management.
+
+Swapping differentiates itself from the other mentioned techniques because it's
+undesirable since it's performed as a means to reduce memory under heavy
+pressure.
+
+Swapping can't work for memory mapped by kernel logical addresses. These are a
+subset of the kernel virtual space that directly maps a contiguous range of
+physical memory. Given any logical address, its physical address is determined
+with simple arithmetic on an offset. Accesses to logical addresses are fast
+because they avoid the need for complex page table lookups at the expenses of
+frames not being evictable and pageable out.
+
+If the kernel fails to make room for the data that must be present in the
+physical frames, the kernel invokes the out-of-memory (OOM) killer to make room
+by terminating lower priority processes until pressure reduces under a safe
+threshold.
+
+Additionally, page faults may be also caused by code bugs or by maliciously
+crafted addresses that the CPU is instructed to access. A thread of a process
+could use instructions to address (non-shared) memory which does not belong to
+its own address space, or could try to execute an instruction that want to write
+to a read-only location.
+
+If the above-mentioned conditions happen in user-space, the kernel sends a
+`Segmentation Fault` (SIGSEGV) signal to the current thread. That signal usually
+causes the termination of the thread and of the process it belongs to.
+
+This document is going to simplify and show an high altitude view of how the
+Linux kernel handles these page faults, creates tables and tables' entries,
+check if memory is present and, if not, requests to load data from persistent
+storage or from other devices, and updates the MMU and its caches.
+
+The first steps are architecture dependent. Most architectures jump to
+`do_page_fault()`, whereas the x86 interrupt handler is defined by the
+`DEFINE_IDTENTRY_RAW_ERRORCODE()` macro which calls `handle_page_fault()`.
+
+Whatever the routes, all architectures end up to the invocation of
+`handle_mm_fault()` which, in turn, (likely) ends up calling
+`__handle_mm_fault()` to carry out the actual work of allocating the page
+tables.
+
+The unfortunate case of not being able to call `__handle_mm_fault()` means
+that the virtual address is pointing to areas of physical memory which are not
+permitted to be accessed (at least from the current context). This
+condition resolves to the kernel sending the above-mentioned SIGSEGV signal
+to the process and leads to the consequences already explained.
+
+`__handle_mm_fault()` carries out its work by calling several functions to
+find the entry's offsets of the upper layers of the page tables and allocate
+the tables that it may need.
+
+The functions that look for the offset have names like `*_offset()`, where the
+"*" is for pgd, p4d, pud, pmd, pte; instead the functions to allocate the
+corresponding tables, layer by layer, are called `*_alloc`, using the
+above-mentioned convention to name them after the corresponding types of tables
+in the hierarchy.
+
+The page table walk may end at one of the middle or upper layers (PMD, PUD).
+
+Linux supports larger page sizes than the usual 4KB (i.e., the so called
+`huge pages`). When using these kinds of larger pages, higher level pages can
+directly map them, with no need to use lower level page entries (PTE). Huge
+pages contain large contiguous physical regions that usually span from 2MB to
+1GB. They are respectively mapped by the PMD and PUD page entries.
+
+The huge pages bring with them several benefits like reduced TLB pressure,
+reduced page table overhead, memory allocation efficiency, and performance
+improvement for certain workloads. However, these benefits come with
+trade-offs, like wasted memory and allocation challenges.
+
+At the very end of the walk with allocations, if it didn't return errors,
+`__handle_mm_fault()` finally calls `handle_pte_fault()`, which via `do_fault()`
+performs one of `do_read_fault()`, `do_cow_fault()`, `do_shared_fault()`.
+"read", "cow", "shared" give hints about the reasons and the kind of fault it's
+handling.
+
+The actual implementation of the workflow is very complex. Its design allows
+Linux to handle page faults in a way that is tailored to the specific
+characteristics of each architecture, while still sharing a common overall
+structure.
+
+To conclude this high altitude view of how Linux handles page faults, let's
+add that the page faults handler can be disabled and enabled respectively with
+`pagefault_disable()` and `pagefault_enable()`.
+
+Several code path make use of the latter two functions because they need to
+disable traps into the page faults handler, mostly to prevent deadlocks.
diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst
index 2ab7b8c1c863..b76183545e5b 100644
--- a/Documentation/mm/physical_memory.rst
+++ b/Documentation/mm/physical_memory.rst
@@ -3,3 +3,633 @@
===============
Physical Memory
===============
+
+Linux is available for a wide range of architectures so there is a need for an
+architecture-independent abstraction to represent the physical memory. This
+chapter describes the structures used to manage physical memory in a running
+system.
+
+The first principal concept prevalent in the memory management is
+`Non-Uniform Memory Access (NUMA)
+<https://en.wikipedia.org/wiki/Non-uniform_memory_access>`_.
+With multi-core and multi-socket machines, memory may be arranged into banks
+that incur a different cost to access depending on the “distance” from the
+processor. For example, there might be a bank of memory assigned to each CPU or
+a bank of memory very suitable for DMA near peripheral devices.
+
+Each bank is called a node and the concept is represented under Linux by a
+``struct pglist_data`` even if the architecture is UMA. This structure is
+always referenced by its typedef ``pg_data_t``. A ``pg_data_t`` structure
+for a particular node can be referenced by ``NODE_DATA(nid)`` macro where
+``nid`` is the ID of that node.
+
+For NUMA architectures, the node structures are allocated by the architecture
+specific code early during boot. Usually, these structures are allocated
+locally on the memory bank they represent. For UMA architectures, only one
+static ``pg_data_t`` structure called ``contig_page_data`` is used. Nodes will
+be discussed further in Section :ref:`Nodes <nodes>`
+
+The entire physical address space is partitioned into one or more blocks
+called zones which represent ranges within memory. These ranges are usually
+determined by architectural constraints for accessing the physical memory.
+The memory range within a node that corresponds to a particular zone is
+described by a ``struct zone``. Each zone has
+one of the types described below.
+
+* ``ZONE_DMA`` and ``ZONE_DMA32`` historically represented memory suitable for
+ DMA by peripheral devices that cannot access all of the addressable
+ memory. For many years there are better more and robust interfaces to get
+ memory with DMA specific requirements (Documentation/core-api/dma-api.rst),
+ but ``ZONE_DMA`` and ``ZONE_DMA32`` still represent memory ranges that have
+ restrictions on how they can be accessed.
+ Depending on the architecture, either of these zone types or even they both
+ can be disabled at build time using ``CONFIG_ZONE_DMA`` and
+ ``CONFIG_ZONE_DMA32`` configuration options. Some 64-bit platforms may need
+ both zones as they support peripherals with different DMA addressing
+ limitations.
+
+* ``ZONE_NORMAL`` is for normal memory that can be accessed by the kernel all
+ the time. DMA operations can be performed on pages in this zone if the DMA
+ devices support transfers to all addressable memory. ``ZONE_NORMAL`` is
+ always enabled.
+
+* ``ZONE_HIGHMEM`` is the part of the physical memory that is not covered by a
+ permanent mapping in the kernel page tables. The memory in this zone is only
+ accessible to the kernel using temporary mappings. This zone is available
+ only on some 32-bit architectures and is enabled with ``CONFIG_HIGHMEM``.
+
+* ``ZONE_MOVABLE`` is for normal accessible memory, just like ``ZONE_NORMAL``.
+ The difference is that the contents of most pages in ``ZONE_MOVABLE`` is
+ movable. That means that while virtual addresses of these pages do not
+ change, their content may move between different physical pages. Often
+ ``ZONE_MOVABLE`` is populated during memory hotplug, but it may be
+ also populated on boot using one of ``kernelcore``, ``movablecore`` and
+ ``movable_node`` kernel command line parameters. See
+ Documentation/mm/page_migration.rst and
+ Documentation/admin-guide/mm/memory-hotplug.rst for additional details.
+
+* ``ZONE_DEVICE`` represents memory residing on devices such as PMEM and GPU.
+ It has different characteristics than RAM zone types and it exists to provide
+ :ref:`struct page <Pages>` and memory map services for device driver
+ identified physical address ranges. ``ZONE_DEVICE`` is enabled with
+ configuration option ``CONFIG_ZONE_DEVICE``.
+
+It is important to note that many kernel operations can only take place using
+``ZONE_NORMAL`` so it is the most performance critical zone. Zones are
+discussed further in Section :ref:`Zones <zones>`.
+
+The relation between node and zone extents is determined by the physical memory
+map reported by the firmware, architectural constraints for memory addressing
+and certain parameters in the kernel command line.
+
+For example, with 32-bit kernel on an x86 UMA machine with 2 Gbytes of RAM the
+entire memory will be on node 0 and there will be three zones: ``ZONE_DMA``,
+``ZONE_NORMAL`` and ``ZONE_HIGHMEM``::
+
+ 0 2G
+ +-------------------------------------------------------------+
+ | node 0 |
+ +-------------------------------------------------------------+
+
+ 0 16M 896M 2G
+ +----------+-----------------------+--------------------------+
+ | ZONE_DMA | ZONE_NORMAL | ZONE_HIGHMEM |
+ +----------+-----------------------+--------------------------+
+
+
+With a kernel built with ``ZONE_DMA`` disabled and ``ZONE_DMA32`` enabled and
+booted with ``movablecore=80%`` parameter on an arm64 machine with 16 Gbytes of
+RAM equally split between two nodes, there will be ``ZONE_DMA32``,
+``ZONE_NORMAL`` and ``ZONE_MOVABLE`` on node 0, and ``ZONE_NORMAL`` and
+``ZONE_MOVABLE`` on node 1::
+
+
+ 1G 9G 17G
+ +--------------------------------+ +--------------------------+
+ | node 0 | | node 1 |
+ +--------------------------------+ +--------------------------+
+
+ 1G 4G 4200M 9G 9320M 17G
+ +---------+----------+-----------+ +------------+-------------+
+ | DMA32 | NORMAL | MOVABLE | | NORMAL | MOVABLE |
+ +---------+----------+-----------+ +------------+-------------+
+
+
+Memory banks may belong to interleaving nodes. In the example below an x86
+machine has 16 Gbytes of RAM in 4 memory banks, even banks belong to node 0
+and odd banks belong to node 1::
+
+
+ 0 4G 8G 12G 16G
+ +-------------+ +-------------+ +-------------+ +-------------+
+ | node 0 | | node 1 | | node 0 | | node 1 |
+ +-------------+ +-------------+ +-------------+ +-------------+
+
+ 0 16M 4G
+ +-----+-------+ +-------------+ +-------------+ +-------------+
+ | DMA | DMA32 | | NORMAL | | NORMAL | | NORMAL |
+ +-----+-------+ +-------------+ +-------------+ +-------------+
+
+In this case node 0 will span from 0 to 12 Gbytes and node 1 will span from
+4 to 16 Gbytes.
+
+.. _nodes:
+
+Nodes
+=====
+
+As we have mentioned, each node in memory is described by a ``pg_data_t`` which
+is a typedef for a ``struct pglist_data``. When allocating a page, by default
+Linux uses a node-local allocation policy to allocate memory from the node
+closest to the running CPU. As processes tend to run on the same CPU, it is
+likely the memory from the current node will be used. The allocation policy can
+be controlled by users as described in
+Documentation/admin-guide/mm/numa_memory_policy.rst.
+
+Most NUMA architectures maintain an array of pointers to the node
+structures. The actual structures are allocated early during boot when
+architecture specific code parses the physical memory map reported by the
+firmware. The bulk of the node initialization happens slightly later in the
+boot process by free_area_init() function, described later in Section
+:ref:`Initialization <initialization>`.
+
+
+Along with the node structures, kernel maintains an array of ``nodemask_t``
+bitmasks called ``node_states``. Each bitmask in this array represents a set of
+nodes with particular properties as defined by ``enum node_states``:
+
+``N_POSSIBLE``
+ The node could become online at some point.
+``N_ONLINE``
+ The node is online.
+``N_NORMAL_MEMORY``
+ The node has regular memory.
+``N_HIGH_MEMORY``
+ The node has regular or high memory. When ``CONFIG_HIGHMEM`` is disabled
+ aliased to ``N_NORMAL_MEMORY``.
+``N_MEMORY``
+ The node has memory(regular, high, movable)
+``N_CPU``
+ The node has one or more CPUs
+``N_GENERIC_INITIATOR``
+ The node has one or more Generic Initiators
+
+For each node that has a property described above, the bit corresponding to the
+node ID in the ``node_states[<property>]`` bitmask is set.
+
+For example, for node 2 with normal memory and CPUs, bit 2 will be set in ::
+
+ node_states[N_POSSIBLE]
+ node_states[N_ONLINE]
+ node_states[N_NORMAL_MEMORY]
+ node_states[N_HIGH_MEMORY]
+ node_states[N_MEMORY]
+ node_states[N_CPU]
+
+For various operations possible with nodemasks please refer to
+``include/linux/nodemask.h``.
+
+Among other things, nodemasks are used to provide macros for node traversal,
+namely ``for_each_node()`` and ``for_each_online_node()``.
+
+For instance, to call a function foo() for each online node::
+
+ for_each_online_node(nid) {
+ pg_data_t *pgdat = NODE_DATA(nid);
+
+ foo(pgdat);
+ }
+
+Node structure
+--------------
+
+The nodes structure ``struct pglist_data`` is declared in
+``include/linux/mmzone.h``. Here we briefly describe fields of this
+structure:
+
+General
+~~~~~~~
+
+``node_zones``
+ The zones for this node. Not all of the zones may be populated, but it is
+ the full list. It is referenced by this node's node_zonelists as well as
+ other node's node_zonelists.
+
+``node_zonelists``
+ The list of all zones in all nodes. This list defines the order of zones
+ that allocations are preferred from. The ``node_zonelists`` is set up by
+ ``build_zonelists()`` in ``mm/page_alloc.c`` during the initialization of
+ core memory management structures.
+
+``nr_zones``
+ Number of populated zones in this node.
+
+``node_mem_map``
+ For UMA systems that use FLATMEM memory model the 0's node
+ ``node_mem_map`` is array of struct pages representing each physical frame.
+
+``node_page_ext``
+ For UMA systems that use FLATMEM memory model the 0's node
+ ``node_page_ext`` is array of extensions of struct pages. Available only
+ in the kernels built with ``CONFIG_PAGE_EXTENSION`` enabled.
+
+``node_start_pfn``
+ The page frame number of the starting page frame in this node.
+
+``node_present_pages``
+ Total number of physical pages present in this node.
+
+``node_spanned_pages``
+ Total size of physical page range, including holes.
+
+``node_size_lock``
+ A lock that protects the fields defining the node extents. Only defined when
+ at least one of ``CONFIG_MEMORY_HOTPLUG`` or
+ ``CONFIG_DEFERRED_STRUCT_PAGE_INIT`` configuration options are enabled.
+ ``pgdat_resize_lock()`` and ``pgdat_resize_unlock()`` are provided to
+ manipulate ``node_size_lock`` without checking for ``CONFIG_MEMORY_HOTPLUG``
+ or ``CONFIG_DEFERRED_STRUCT_PAGE_INIT``.
+
+``node_id``
+ The Node ID (NID) of the node, starts at 0.
+
+``totalreserve_pages``
+ This is a per-node reserve of pages that are not available to userspace
+ allocations.
+
+``first_deferred_pfn``
+ If memory initialization on large machines is deferred then this is the first
+ PFN that needs to be initialized. Defined only when
+ ``CONFIG_DEFERRED_STRUCT_PAGE_INIT`` is enabled
+
+``deferred_split_queue``
+ Per-node queue of huge pages that their split was deferred. Defined only when ``CONFIG_TRANSPARENT_HUGEPAGE`` is enabled.
+
+``__lruvec``
+ Per-node lruvec holding LRU lists and related parameters. Used only when
+ memory cgroups are disabled. It should not be accessed directly, use
+ ``mem_cgroup_lruvec()`` to look up lruvecs instead.
+
+Reclaim control
+~~~~~~~~~~~~~~~
+
+See also Documentation/mm/page_reclaim.rst.
+
+``kswapd``
+ Per-node instance of kswapd kernel thread.
+
+``kswapd_wait``, ``pfmemalloc_wait``, ``reclaim_wait``
+ Workqueues used to synchronize memory reclaim tasks
+
+``nr_writeback_throttled``
+ Number of tasks that are throttled waiting on dirty pages to clean.
+
+``nr_reclaim_start``
+ Number of pages written while reclaim is throttled waiting for writeback.
+
+``kswapd_order``
+ Controls the order kswapd tries to reclaim
+
+``kswapd_highest_zoneidx``
+ The highest zone index to be reclaimed by kswapd
+
+``kswapd_failures``
+ Number of runs kswapd was unable to reclaim any pages
+
+``min_unmapped_pages``
+ Minimal number of unmapped file backed pages that cannot be reclaimed.
+ Determined by ``vm.min_unmapped_ratio`` sysctl. Only defined when
+ ``CONFIG_NUMA`` is enabled.
+
+``min_slab_pages``
+ Minimal number of SLAB pages that cannot be reclaimed. Determined by
+ ``vm.min_slab_ratio sysctl``. Only defined when ``CONFIG_NUMA`` is enabled
+
+``flags``
+ Flags controlling reclaim behavior.
+
+Compaction control
+~~~~~~~~~~~~~~~~~~
+
+``kcompactd_max_order``
+ Page order that kcompactd should try to achieve.
+
+``kcompactd_highest_zoneidx``
+ The highest zone index to be compacted by kcompactd.
+
+``kcompactd_wait``
+ Workqueue used to synchronize memory compaction tasks.
+
+``kcompactd``
+ Per-node instance of kcompactd kernel thread.
+
+``proactive_compact_trigger``
+ Determines if proactive compaction is enabled. Controlled by
+ ``vm.compaction_proactiveness`` sysctl.
+
+Statistics
+~~~~~~~~~~
+
+``per_cpu_nodestats``
+ Per-CPU VM statistics for the node
+
+``vm_stat``
+ VM statistics for the node.
+
+.. _zones:
+
+Zones
+=====
+As we have mentioned, each zone in memory is described by a ``struct zone``
+which is an element of the ``node_zones`` array of the node it belongs to.
+``struct zone`` is the core data structure of the page allocator. A zone
+represents a range of physical memory and may have holes.
+
+The page allocator uses the GFP flags, see :ref:`mm-api-gfp-flags`, specified by
+a memory allocation to determine the highest zone in a node from which the
+memory allocation can allocate memory. The page allocator first allocates memory
+from that zone, if the page allocator can't allocate the requested amount of
+memory from the zone, it will allocate memory from the next lower zone in the
+node, the process continues up to and including the lowest zone. For example, if
+a node contains ``ZONE_DMA32``, ``ZONE_NORMAL`` and ``ZONE_MOVABLE`` and the
+highest zone of a memory allocation is ``ZONE_MOVABLE``, the order of the zones
+from which the page allocator allocates memory is ``ZONE_MOVABLE`` >
+``ZONE_NORMAL`` > ``ZONE_DMA32``.
+
+At runtime, free pages in a zone are in the Per-CPU Pagesets (PCP) or free areas
+of the zone. The Per-CPU Pagesets are a vital mechanism in the kernel's memory
+management system. By handling most frequent allocations and frees locally on
+each CPU, the Per-CPU Pagesets improve performance and scalability, especially
+on systems with many cores. The page allocator in the kernel employs a two-step
+strategy for memory allocation, starting with the Per-CPU Pagesets before
+falling back to the buddy allocator. Pages are transferred between the Per-CPU
+Pagesets and the global free areas (managed by the buddy allocator) in batches.
+This minimizes the overhead of frequent interactions with the global buddy
+allocator.
+
+Architecture specific code calls free_area_init() to initializes zones.
+
+Zone structure
+--------------
+The zones structure ``struct zone`` is defined in ``include/linux/mmzone.h``.
+Here we briefly describe fields of this structure:
+
+General
+~~~~~~~
+
+``_watermark``
+ The watermarks for this zone. When the amount of free pages in a zone is below
+ the min watermark, boosting is ignored, an allocation may trigger direct
+ reclaim and direct compaction, it is also used to throttle direct reclaim.
+ When the amount of free pages in a zone is below the low watermark, kswapd is
+ woken up. When the amount of free pages in a zone is above the high watermark,
+ kswapd stops reclaiming (a zone is balanced) when the
+ ``NUMA_BALANCING_MEMORY_TIERING`` bit of ``sysctl_numa_balancing_mode`` is not
+ set. The promo watermark is used for memory tiering and NUMA balancing. When
+ the amount of free pages in a zone is above the promo watermark, kswapd stops
+ reclaiming when the ``NUMA_BALANCING_MEMORY_TIERING`` bit of
+ ``sysctl_numa_balancing_mode`` is set. The watermarks are set by
+ ``__setup_per_zone_wmarks()``. The min watermark is calculated according to
+ ``vm.min_free_kbytes`` sysctl. The other three watermarks are set according
+ to the distance between two watermarks. The distance itself is calculated
+ taking ``vm.watermark_scale_factor`` sysctl into account.
+
+``watermark_boost``
+ The number of pages which are used to boost watermarks to increase reclaim
+ pressure to reduce the likelihood of future fallbacks and wake kswapd now
+ as the node may be balanced overall and kswapd will not wake naturally.
+
+``nr_reserved_highatomic``
+ The number of pages which are reserved for high-order atomic allocations.
+
+``nr_free_highatomic``
+ The number of free pages in reserved highatomic pageblocks
+
+``lowmem_reserve``
+ The array of the amounts of the memory reserved in this zone for memory
+ allocations. For example, if the highest zone a memory allocation can
+ allocate memory from is ``ZONE_MOVABLE``, the amount of memory reserved in
+ this zone for this allocation is ``lowmem_reserve[ZONE_MOVABLE]`` when
+ attempting to allocate memory from this zone. This is a mechanism the page
+ allocator uses to prevent allocations which could use ``highmem`` from using
+ too much ``lowmem``. For some specialised workloads on ``highmem`` machines,
+ it is dangerous for the kernel to allow process memory to be allocated from
+ the ``lowmem`` zone. This is because that memory could then be pinned via the
+ ``mlock()`` system call, or by unavailability of swapspace.
+ ``vm.lowmem_reserve_ratio`` sysctl determines how aggressive the kernel is in
+ defending these lower zones. This array is recalculated by
+ ``setup_per_zone_lowmem_reserve()`` at runtime if ``vm.lowmem_reserve_ratio``
+ sysctl changes.
+
+``node``
+ The index of the node this zone belongs to. Available only when
+ ``CONFIG_NUMA`` is enabled because there is only one zone in a UMA system.
+
+``zone_pgdat``
+ Pointer to the ``struct pglist_data`` of the node this zone belongs to.
+
+``per_cpu_pageset``
+ Pointer to the Per-CPU Pagesets (PCP) allocated and initialized by
+ ``setup_zone_pageset()``. By handling most frequent allocations and frees
+ locally on each CPU, PCP improves performance and scalability on systems with
+ many cores.
+
+``pageset_high_min``
+ Copied to the ``high_min`` of the Per-CPU Pagesets for faster access.
+
+``pageset_high_max``
+ Copied to the ``high_max`` of the Per-CPU Pagesets for faster access.
+
+``pageset_batch``
+ Copied to the ``batch`` of the Per-CPU Pagesets for faster access. The
+ ``batch``, ``high_min`` and ``high_max`` of the Per-CPU Pagesets are used to
+ calculate the number of elements the Per-CPU Pagesets obtain from the buddy
+ allocator under a single hold of the lock for efficiency. They are also used
+ to decide if the Per-CPU Pagesets return pages to the buddy allocator in page
+ free process.
+
+``pageblock_flags``
+ The pointer to the flags for the pageblocks in the zone (see
+ ``include/linux/pageblock-flags.h`` for flags list). The memory is allocated
+ in ``setup_usemap()``. Each pageblock occupies ``NR_PAGEBLOCK_BITS`` bits.
+ Defined only when ``CONFIG_FLATMEM`` is enabled. The flags is stored in
+ ``mem_section`` when ``CONFIG_SPARSEMEM`` is enabled.
+
+``zone_start_pfn``
+ The start pfn of the zone. It is initialized by
+ ``calculate_node_totalpages()``.
+
+``managed_pages``
+ The present pages managed by the buddy system, which is calculated as:
+ ``managed_pages`` = ``present_pages`` - ``reserved_pages``, ``reserved_pages``
+ includes pages allocated by the memblock allocator. It should be used by page
+ allocator and vm scanner to calculate all kinds of watermarks and thresholds.
+ It is accessed using ``atomic_long_xxx()`` functions. It is initialized in
+ ``free_area_init_core()`` and then is reinitialized when memblock allocator
+ frees pages into buddy system.
+
+``spanned_pages``
+ The total pages spanned by the zone, including holes, which is calculated as:
+ ``spanned_pages`` = ``zone_end_pfn`` - ``zone_start_pfn``. It is initialized
+ by ``calculate_node_totalpages()``.
+
+``present_pages``
+ The physical pages existing within the zone, which is calculated as:
+ ``present_pages`` = ``spanned_pages`` - ``absent_pages`` (pages in holes). It
+ may be used by memory hotplug or memory power management logic to figure out
+ unmanaged pages by checking (``present_pages`` - ``managed_pages``). Write
+ access to ``present_pages`` at runtime should be protected by
+ ``mem_hotplug_begin/done()``. Any reader who can't tolerant drift of
+ ``present_pages`` should use ``get_online_mems()`` to get a stable value. It
+ is initialized by ``calculate_node_totalpages()``.
+
+``present_early_pages``
+ The present pages existing within the zone located on memory available since
+ early boot, excluding hotplugged memory. Defined only when
+ ``CONFIG_MEMORY_HOTPLUG`` is enabled and initialized by
+ ``calculate_node_totalpages()``.
+
+``cma_pages``
+ The pages reserved for CMA use. These pages behave like ``ZONE_MOVABLE`` when
+ they are not used for CMA. Defined only when ``CONFIG_CMA`` is enabled.
+
+``name``
+ The name of the zone. It is a pointer to the corresponding element of
+ the ``zone_names`` array.
+
+``nr_isolate_pageblock``
+ Number of isolated pageblocks. It is used to solve incorrect freepage counting
+ problem due to racy retrieving migratetype of pageblock. Protected by
+ ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled.
+
+``span_seqlock``
+ The seqlock to protect ``zone_start_pfn`` and ``spanned_pages``. It is a
+ seqlock because it has to be read outside of ``zone->lock``, and it is done in
+ the main allocator path. However, the seqlock is written quite infrequently.
+ Defined only when ``CONFIG_MEMORY_HOTPLUG`` is enabled.
+
+``initialized``
+ The flag indicating if the zone is initialized. Set by
+ ``init_currently_empty_zone()`` during boot.
+
+``free_area``
+ The array of free areas, where each element corresponds to a specific order
+ which is a power of two. The buddy allocator uses this structure to manage
+ free memory efficiently. When allocating, it tries to find the smallest
+ sufficient block, if the smallest sufficient block is larger than the
+ requested size, it will be recursively split into the next smaller blocks
+ until the required size is reached. When a page is freed, it may be merged
+ with its buddy to form a larger block. It is initialized by
+ ``zone_init_free_lists()``.
+
+``unaccepted_pages``
+ The list of pages to be accepted. All pages on the list are ``MAX_PAGE_ORDER``.
+ Defined only when ``CONFIG_UNACCEPTED_MEMORY`` is enabled.
+
+``flags``
+ The zone flags. The least three bits are used and defined by
+ ``enum zone_flags``. ``ZONE_BOOSTED_WATERMARK`` (bit 0): zone recently boosted
+ watermarks. Cleared when kswapd is woken. ``ZONE_RECLAIM_ACTIVE`` (bit 1):
+ kswapd may be scanning the zone. ``ZONE_BELOW_HIGH`` (bit 2): zone is below
+ high watermark.
+
+``lock``
+ The main lock that protects the internal data structures of the page allocator
+ specific to the zone, especially protects ``free_area``.
+
+``percpu_drift_mark``
+ When free pages are below this point, additional steps are taken when reading
+ the number of free pages to avoid per-cpu counter drift allowing watermarks
+ to be breached. It is updated in ``refresh_zone_stat_thresholds()``.
+
+Compaction control
+~~~~~~~~~~~~~~~~~~
+
+``compact_cached_free_pfn``
+ The PFN where compaction free scanner should start in the next scan.
+
+``compact_cached_migrate_pfn``
+ The PFNs where compaction migration scanner should start in the next scan.
+ This array has two elements: the first one is used in ``MIGRATE_ASYNC`` mode,
+ and the other one is used in ``MIGRATE_SYNC`` mode.
+
+``compact_init_migrate_pfn``
+ The initial migration PFN which is initialized to 0 at boot time, and to the
+ first pageblock with migratable pages in the zone after a full compaction
+ finishes. It is used to check if a scan is a whole zone scan or not.
+
+``compact_init_free_pfn``
+ The initial free PFN which is initialized to 0 at boot time and to the last
+ pageblock with free ``MIGRATE_MOVABLE`` pages in the zone. It is used to check
+ if it is the start of a scan.
+
+``compact_considered``
+ The number of compactions attempted since last failure. It is reset in
+ ``defer_compaction()`` when a compaction fails to result in a page allocation
+ success. It is increased by 1 in ``compaction_deferred()`` when a compaction
+ should be skipped. ``compaction_deferred()`` is called before
+ ``compact_zone()`` is called, ``compaction_defer_reset()`` is called when
+ ``compact_zone()`` returns ``COMPACT_SUCCESS``, ``defer_compaction()`` is
+ called when ``compact_zone()`` returns ``COMPACT_PARTIAL_SKIPPED`` or
+ ``COMPACT_COMPLETE``.
+
+``compact_defer_shift``
+ The number of compactions skipped before trying again is
+ ``1<<compact_defer_shift``. It is increased by 1 in ``defer_compaction()``.
+ It is reset in ``compaction_defer_reset()`` when a direct compaction results
+ in a page allocation success. Its maximum value is ``COMPACT_MAX_DEFER_SHIFT``.
+
+``compact_order_failed``
+ The minimum compaction failed order. It is set in ``compaction_defer_reset()``
+ when a compaction succeeds and in ``defer_compaction()`` when a compaction
+ fails to result in a page allocation success.
+
+``compact_blockskip_flush``
+ Set to true when compaction migration scanner and free scanner meet, which
+ means the ``PB_compact_skip`` bits should be cleared.
+
+``contiguous``
+ Set to true when the zone is contiguous (in other words, no hole).
+
+Statistics
+~~~~~~~~~~
+
+``vm_stat``
+ VM statistics for the zone. The items tracked are defined by
+ ``enum zone_stat_item``.
+
+``vm_numa_event``
+ VM NUMA event statistics for the zone. The items tracked are defined by
+ ``enum numa_stat_item``.
+
+``per_cpu_zonestats``
+ Per-CPU VM statistics for the zone. It records VM statistics and VM NUMA event
+ statistics on a per-CPU basis. It reduces updates to the global ``vm_stat``
+ and ``vm_numa_event`` fields of the zone to improve performance.
+
+.. _pages:
+
+Pages
+=====
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
+
+.. _folios:
+
+Folios
+======
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
+
+.. _initialization:
+
+Initialization
+==============
+
+.. admonition:: Stub
+
+ This section is incomplete. Please list and describe the appropriate fields.
diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst
index e8618fbc62c9..7f2f3e87071d 100644
--- a/Documentation/mm/process_addrs.rst
+++ b/Documentation/mm/process_addrs.rst
@@ -3,3 +3,914 @@
=================
Process Addresses
=================
+
+.. toctree::
+ :maxdepth: 3
+
+
+Userland memory ranges are tracked by the kernel via Virtual Memory Areas or
+'VMA's of type :c:struct:`!struct vm_area_struct`.
+
+Each VMA describes a virtually contiguous memory range with identical
+attributes, each described by a :c:struct:`!struct vm_area_struct`
+object. Userland access outside of VMAs is invalid except in the case where an
+adjacent stack VMA could be extended to contain the accessed address.
+
+All VMAs are contained within one and only one virtual address space, described
+by a :c:struct:`!struct mm_struct` object which is referenced by all tasks (that is,
+threads) which share the virtual address space. We refer to this as the
+:c:struct:`!mm`.
+
+Each mm object contains a maple tree data structure which describes all VMAs
+within the virtual address space.
+
+.. note:: An exception to this is the 'gate' VMA which is provided by
+ architectures which use :c:struct:`!vsyscall` and is a global static
+ object which does not belong to any specific mm.
+
+-------
+Locking
+-------
+
+The kernel is designed to be highly scalable against concurrent read operations
+on VMA **metadata** so a complicated set of locks are required to ensure memory
+corruption does not occur.
+
+.. note:: Locking VMAs for their metadata does not have any impact on the memory
+ they describe nor the page tables that map them.
+
+Terminology
+-----------
+
+* **mmap locks** - Each MM has a read/write semaphore :c:member:`!mmap_lock`
+ which locks at a process address space granularity which can be acquired via
+ :c:func:`!mmap_read_lock`, :c:func:`!mmap_write_lock` and variants.
+* **VMA locks** - The VMA lock is at VMA granularity (of course) which behaves
+ as a read/write semaphore in practice. A VMA read lock is obtained via
+ :c:func:`!lock_vma_under_rcu` (and unlocked via :c:func:`!vma_end_read`) and a
+ write lock via vma_start_write() or vma_start_write_killable()
+ (all VMA write locks are unlocked
+ automatically when the mmap write lock is released). To take a VMA write lock
+ you **must** have already acquired an :c:func:`!mmap_write_lock`.
+* **rmap locks** - When trying to access VMAs through the reverse mapping via a
+ :c:struct:`!struct address_space` or :c:struct:`!struct anon_vma` object
+ (reachable from a folio via :c:member:`!folio->mapping`). VMAs must be stabilised via
+ :c:func:`!anon_vma_[try]lock_read` or :c:func:`!anon_vma_[try]lock_write` for
+ anonymous memory and :c:func:`!i_mmap_[try]lock_read` or
+ :c:func:`!i_mmap_[try]lock_write` for file-backed memory. We refer to these
+ locks as the reverse mapping locks, or 'rmap locks' for brevity.
+
+We discuss page table locks separately in the dedicated section below.
+
+The first thing **any** of these locks achieve is to **stabilise** the VMA
+within the MM tree. That is, guaranteeing that the VMA object will not be
+deleted from under you nor modified (except for some specific fields
+described below).
+
+Stabilising a VMA also keeps the address space described by it around.
+
+Lock usage
+----------
+
+If you want to **read** VMA metadata fields or just keep the VMA stable, you
+must do one of the following:
+
+* Obtain an mmap read lock at the MM granularity via :c:func:`!mmap_read_lock` (or a
+ suitable variant), unlocking it with a matching :c:func:`!mmap_read_unlock` when
+ you're done with the VMA, *or*
+* Try to obtain a VMA read lock via :c:func:`!lock_vma_under_rcu`. This tries to
+ acquire the lock atomically so might fail, in which case fall-back logic is
+ required to instead obtain an mmap read lock if this returns :c:macro:`!NULL`,
+ *or*
+* Acquire an rmap lock before traversing the locked interval tree (whether
+ anonymous or file-backed) to obtain the required VMA.
+
+If you want to **write** VMA metadata fields, then things vary depending on the
+field (we explore each VMA field in detail below). For the majority you must:
+
+* Obtain an mmap write lock at the MM granularity via :c:func:`!mmap_write_lock` (or a
+ suitable variant), unlocking it with a matching :c:func:`!mmap_write_unlock` when
+ you're done with the VMA, *and*
+* Obtain a VMA write lock via :c:func:`!vma_start_write` for each VMA you wish to
+ modify, which will be released automatically when :c:func:`!mmap_write_unlock` is
+ called.
+* If you want to be able to write to **any** field, you must also hide the VMA
+ from the reverse mapping by obtaining an **rmap write lock**.
+
+VMA locks are special in that you must obtain an mmap **write** lock **first**
+in order to obtain a VMA **write** lock. A VMA **read** lock however can be
+obtained without any other lock (:c:func:`!lock_vma_under_rcu` will acquire then
+release an RCU lock to lookup the VMA for you).
+
+This constrains the impact of writers on readers, as a writer can interact with
+one VMA while a reader interacts with another simultaneously.
+
+.. note:: The primary users of VMA read locks are page fault handlers, which
+ means that without a VMA write lock, page faults will run concurrent with
+ whatever you are doing.
+
+Examining all valid lock states:
+
+.. table::
+
+ ========= ======== ========= ======= ===== =========== ==========
+ mmap lock VMA lock rmap lock Stable? Read? Write most? Write all?
+ ========= ======== ========= ======= ===== =========== ==========
+ \- \- \- N N N N
+ \- R \- Y Y N N
+ \- \- R/W Y Y N N
+ R/W \-/R \-/R/W Y Y N N
+ W W \-/R Y Y Y N
+ W W W Y Y Y Y
+ ========= ======== ========= ======= ===== =========== ==========
+
+.. warning:: While it's possible to obtain a VMA lock while holding an mmap read lock,
+ attempting to do the reverse is invalid as it can result in deadlock - if
+ another task already holds an mmap write lock and attempts to acquire a VMA
+ write lock that will deadlock on the VMA read lock.
+
+All of these locks behave as read/write semaphores in practice, so you can
+obtain either a read or a write lock for each of these.
+
+.. note:: Generally speaking, a read/write semaphore is a class of lock which
+ permits concurrent readers. However a write lock can only be obtained
+ once all readers have left the critical region (and pending readers
+ made to wait).
+
+ This renders read locks on a read/write semaphore concurrent with other
+ readers and write locks exclusive against all others holding the semaphore.
+
+VMA fields
+^^^^^^^^^^
+
+We can subdivide :c:struct:`!struct vm_area_struct` fields by their purpose, which makes it
+easier to explore their locking characteristics:
+
+.. note:: We exclude VMA lock-specific fields here to avoid confusion, as these
+ are in effect an internal implementation detail.
+
+.. table:: Virtual layout fields
+
+ ===================== ======================================== ===========
+ Field Description Write lock
+ ===================== ======================================== ===========
+ :c:member:`!vm_start` Inclusive start virtual address of range mmap write,
+ VMA describes. VMA write,
+ rmap write.
+ :c:member:`!vm_end` Exclusive end virtual address of range mmap write,
+ VMA describes. VMA write,
+ rmap write.
+ :c:member:`!vm_pgoff` Describes the page offset into the file, mmap write,
+ the original page offset within the VMA write,
+ virtual address space (prior to any rmap write.
+ :c:func:`!mremap`), or PFN if a PFN map
+ and the architecture does not support
+ :c:macro:`!CONFIG_ARCH_HAS_PTE_SPECIAL`.
+ ===================== ======================================== ===========
+
+These fields describes the size, start and end of the VMA, and as such cannot be
+modified without first being hidden from the reverse mapping since these fields
+are used to locate VMAs within the reverse mapping interval trees.
+
+.. table:: Core fields
+
+ ============================ ======================================== =========================
+ Field Description Write lock
+ ============================ ======================================== =========================
+ :c:member:`!vm_mm` Containing mm_struct. None - written once on
+ initial map.
+ :c:member:`!vm_page_prot` Architecture-specific page table mmap write, VMA write.
+ protection bits determined from VMA
+ flags.
+ :c:member:`!vm_flags` Read-only access to VMA flags describing N/A
+ attributes of the VMA, in union with
+ private writable
+ :c:member:`!__vm_flags`.
+ :c:member:`!__vm_flags` Private, writable access to VMA flags mmap write, VMA write.
+ field, updated by
+ :c:func:`!vm_flags_*` functions.
+ :c:member:`!vm_file` If the VMA is file-backed, points to a None - written once on
+ struct file object describing the initial map.
+ underlying file, if anonymous then
+ :c:macro:`!NULL`.
+ :c:member:`!vm_ops` If the VMA is file-backed, then either None - Written once on
+ the driver or file-system provides a initial map by
+ :c:struct:`!struct vm_operations_struct` :c:func:`!f_ops->mmap()`.
+ object describing callbacks to be
+ invoked on VMA lifetime events.
+ :c:member:`!vm_private_data` A :c:member:`!void *` field for Handled by driver.
+ driver-specific metadata.
+ ============================ ======================================== =========================
+
+These are the core fields which describe the MM the VMA belongs to and its attributes.
+
+.. table:: Config-specific fields
+
+ ================================= ===================== ======================================== ===============
+ Field Configuration option Description Write lock
+ ================================= ===================== ======================================== ===============
+ :c:member:`!anon_name` CONFIG_ANON_VMA_NAME A field for storing a mmap write,
+ :c:struct:`!struct anon_vma_name` VMA write.
+ object providing a name for anonymous
+ mappings, or :c:macro:`!NULL` if none
+ is set or the VMA is file-backed. The
+ underlying object is reference counted
+ and can be shared across multiple VMAs
+ for scalability.
+ :c:member:`!swap_readahead_info` CONFIG_SWAP Metadata used by the swap mechanism mmap read,
+ to perform readahead. This field is swap-specific
+ accessed atomically. lock.
+ :c:member:`!vm_policy` CONFIG_NUMA :c:type:`!mempolicy` object which mmap write,
+ describes the NUMA behaviour of the VMA write.
+ VMA. The underlying object is reference
+ counted.
+ :c:member:`!numab_state` CONFIG_NUMA_BALANCING :c:type:`!vma_numab_state` object which mmap read,
+ describes the current state of numab-specific
+ NUMA balancing in relation to this VMA. lock.
+ Updated under mmap read lock by
+ :c:func:`!task_numa_work`.
+ :c:member:`!vm_userfaultfd_ctx` CONFIG_USERFAULTFD Userfaultfd context wrapper object of mmap write,
+ type :c:type:`!vm_userfaultfd_ctx`, VMA write.
+ either of zero size if userfaultfd is
+ disabled, or containing a pointer
+ to an underlying
+ :c:type:`!userfaultfd_ctx` object which
+ describes userfaultfd metadata.
+ ================================= ===================== ======================================== ===============
+
+These fields are present or not depending on whether the relevant kernel
+configuration option is set.
+
+.. table:: Reverse mapping fields
+
+ =================================== ========================================= ============================
+ Field Description Write lock
+ =================================== ========================================= ============================
+ :c:member:`!shared.rb` A red/black tree node used, if the mmap write, VMA write,
+ mapping is file-backed, to place the VMA i_mmap write.
+ in the
+ :c:member:`!struct address_space->i_mmap`
+ red/black interval tree.
+ :c:member:`!shared.rb_subtree_last` Metadata used for management of the mmap write, VMA write,
+ interval tree if the VMA is file-backed. i_mmap write.
+ :c:member:`!anon_vma_chain` List of pointers to both forked/CoW’d mmap read, anon_vma write.
+ :c:type:`!anon_vma` objects and
+ :c:member:`!vma->anon_vma` if it is
+ non-:c:macro:`!NULL`.
+ :c:member:`!anon_vma` :c:type:`!anon_vma` object used by When :c:macro:`NULL` and
+ anonymous folios mapped exclusively to setting non-:c:macro:`NULL`:
+ this VMA. Initially set by mmap read, page_table_lock.
+ :c:func:`!anon_vma_prepare` serialised
+ by the :c:macro:`!page_table_lock`. This When non-:c:macro:`NULL` and
+ is set as soon as any page is faulted in. setting :c:macro:`NULL`:
+ mmap write, VMA write,
+ anon_vma write.
+ =================================== ========================================= ============================
+
+These fields are used to both place the VMA within the reverse mapping, and for
+anonymous mappings, to be able to access both related :c:struct:`!struct anon_vma` objects
+and the :c:struct:`!struct anon_vma` in which folios mapped exclusively to this VMA should
+reside.
+
+.. note:: If a file-backed mapping is mapped with :c:macro:`!MAP_PRIVATE` set
+ then it can be in both the :c:type:`!anon_vma` and :c:type:`!i_mmap`
+ trees at the same time, so all of these fields might be utilised at
+ once.
+
+Page tables
+-----------
+
+We won't speak exhaustively on the subject but broadly speaking, page tables map
+virtual addresses to physical ones through a series of page tables, each of
+which contain entries with physical addresses for the next page table level
+(along with flags), and at the leaf level the physical addresses of the
+underlying physical data pages or a special entry such as a swap entry,
+migration entry or other special marker. Offsets into these pages are provided
+by the virtual address itself.
+
+In Linux these are divided into five levels - PGD, P4D, PUD, PMD and PTE. Huge
+pages might eliminate one or two of these levels, but when this is the case we
+typically refer to the leaf level as the PTE level regardless.
+
+.. note:: In instances where the architecture supports fewer page tables than
+ five the kernel cleverly 'folds' page table levels, that is stubbing
+ out functions related to the skipped levels. This allows us to
+ conceptually act as if there were always five levels, even if the
+ compiler might, in practice, eliminate any code relating to missing
+ ones.
+
+There are four key operations typically performed on page tables:
+
+1. **Traversing** page tables - Simply reading page tables in order to traverse
+ them. This only requires that the VMA is kept stable, so a lock which
+ establishes this suffices for traversal (there are also lockless variants
+ which eliminate even this requirement, such as :c:func:`!gup_fast`). There is
+ also a special case of page table traversal for non-VMA regions which we
+ consider separately below.
+2. **Installing** page table mappings - Whether creating a new mapping or
+ modifying an existing one in such a way as to change its identity. This
+ requires that the VMA is kept stable via an mmap or VMA lock (explicitly not
+ rmap locks).
+3. **Zapping/unmapping** page table entries - This is what the kernel calls
+ clearing page table mappings at the leaf level only, whilst leaving all page
+ tables in place. This is a very common operation in the kernel performed on
+ file truncation, the :c:macro:`!MADV_DONTNEED` operation via
+ :c:func:`!madvise`, and others. This is performed by a number of functions
+ including :c:func:`!unmap_mapping_range` and :c:func:`!unmap_mapping_pages`.
+ The VMA need only be kept stable for this operation.
+4. **Freeing** page tables - When finally the kernel removes page tables from a
+ userland process (typically via :c:func:`!free_pgtables`) extreme care must
+ be taken to ensure this is done safely, as this logic finally frees all page
+ tables in the specified range, ignoring existing leaf entries (it assumes the
+ caller has both zapped the range and prevented any further faults or
+ modifications within it).
+
+.. note:: Modifying mappings for reclaim or migration is performed under rmap
+ lock as it, like zapping, does not fundamentally modify the identity
+ of what is being mapped.
+
+**Traversing** and **zapping** ranges can be performed holding any one of the
+locks described in the terminology section above - that is the mmap lock, the
+VMA lock or either of the reverse mapping locks.
+
+That is - as long as you keep the relevant VMA **stable** - you are good to go
+ahead and perform these operations on page tables (though internally, kernel
+operations that perform writes also acquire internal page table locks to
+serialise - see the page table implementation detail section for more details).
+
+.. note:: We free empty PTE tables on zap under the RCU lock - this does not
+ change the aforementioned locking requirements around zapping.
+
+When **installing** page table entries, the mmap or VMA lock must be held to
+keep the VMA stable. We explore why this is in the page table locking details
+section below.
+
+**Freeing** page tables is an entirely internal memory management operation and
+has special requirements (see the page freeing section below for more details).
+
+.. warning:: When **freeing** page tables, it must not be possible for VMAs
+ containing the ranges those page tables map to be accessible via
+ the reverse mapping.
+
+ The :c:func:`!free_pgtables` function removes the relevant VMAs
+ from the reverse mappings, but no other VMAs can be permitted to be
+ accessible and span the specified range.
+
+Traversing non-VMA page tables
+------------------------------
+
+We've focused above on traversal of page tables belonging to VMAs. It is also
+possible to traverse page tables which are not represented by VMAs.
+
+Kernel page table mappings themselves are generally managed but whatever part of
+the kernel established them and the aforementioned locking rules do not apply -
+for instance vmalloc has its own set of locks which are utilised for
+establishing and tearing down page its page tables.
+
+However, for convenience we provide the :c:func:`!walk_kernel_page_table_range`
+function which is synchronised via the mmap lock on the :c:macro:`!init_mm`
+kernel instantiation of the :c:struct:`!struct mm_struct` metadata object.
+
+If an operation requires exclusive access, a write lock is used, but if not, a
+read lock suffices - we assert only that at least a read lock has been acquired.
+
+Since, aside from vmalloc and memory hot plug, kernel page tables are not torn
+down all that often - this usually suffices, however any caller of this
+functionality must ensure that any additionally required locks are acquired in
+advance.
+
+We also permit a truly unusual case is the traversal of non-VMA ranges in
+**userland** ranges, as provided for by :c:func:`!walk_page_range_debug`.
+
+This has only one user - the general page table dumping logic (implemented in
+:c:macro:`!mm/ptdump.c`) - which seeks to expose all mappings for debug purposes
+even if they are highly unusual (possibly architecture-specific) and are not
+backed by a VMA.
+
+We must take great care in this case, as the :c:func:`!munmap` implementation
+detaches VMAs under an mmap write lock before tearing down page tables under a
+downgraded mmap read lock.
+
+This means such an operation could race with this, and thus an mmap **write**
+lock is required.
+
+Lock ordering
+-------------
+
+As we have multiple locks across the kernel which may or may not be taken at the
+same time as explicit mm or VMA locks, we have to be wary of lock inversion, and
+the **order** in which locks are acquired and released becomes very important.
+
+.. note:: Lock inversion occurs when two threads need to acquire multiple locks,
+ but in doing so inadvertently cause a mutual deadlock.
+
+ For example, consider thread 1 which holds lock A and tries to acquire lock B,
+ while thread 2 holds lock B and tries to acquire lock A.
+
+ Both threads are now deadlocked on each other. However, had they attempted to
+ acquire locks in the same order, one would have waited for the other to
+ complete its work and no deadlock would have occurred.
+
+The opening comment in :c:macro:`!mm/rmap.c` describes in detail the required
+ordering of locks within memory management code:
+
+.. code-block::
+
+ inode->i_rwsem (while writing or truncating, not reading or faulting)
+ mm->mmap_lock
+ mapping->invalidate_lock (in filemap_fault)
+ folio_lock
+ hugetlbfs_i_mmap_rwsem_key (in huge_pmd_share, see hugetlbfs below)
+ vma_start_write
+ mapping->i_mmap_rwsem
+ anon_vma->rwsem
+ mm->page_table_lock or pte_lock
+ swap_lock (in swap_duplicate, swap_info_get)
+ mmlist_lock (in mmput, drain_mmlist and others)
+ mapping->private_lock (in block_dirty_folio)
+ i_pages lock (widely used)
+ lruvec->lru_lock (in folio_lruvec_lock_irq)
+ inode->i_lock (in set_page_dirty's __mark_inode_dirty)
+ bdi.wb->list_lock (in set_page_dirty's __mark_inode_dirty)
+ sb_lock (within inode_lock in fs/fs-writeback.c)
+ i_pages lock (widely used, in set_page_dirty,
+ in arch-dependent flush_dcache_mmap_lock,
+ within bdi.wb->list_lock in __sync_single_inode)
+
+There is also a file-system specific lock ordering comment located at the top of
+:c:macro:`!mm/filemap.c`:
+
+.. code-block::
+
+ ->i_mmap_rwsem (truncate_pagecache)
+ ->private_lock (__free_pte->block_dirty_folio)
+ ->swap_lock (exclusive_swap_page, others)
+ ->i_pages lock
+
+ ->i_rwsem
+ ->invalidate_lock (acquired by fs in truncate path)
+ ->i_mmap_rwsem (truncate->unmap_mapping_range)
+
+ ->mmap_lock
+ ->i_mmap_rwsem
+ ->page_table_lock or pte_lock (various, mainly in memory.c)
+ ->i_pages lock (arch-dependent flush_dcache_mmap_lock)
+
+ ->mmap_lock
+ ->invalidate_lock (filemap_fault)
+ ->lock_page (filemap_fault, access_process_vm)
+
+ ->i_rwsem (generic_perform_write)
+ ->mmap_lock (fault_in_readable->do_page_fault)
+
+ bdi->wb.list_lock
+ sb_lock (fs/fs-writeback.c)
+ ->i_pages lock (__sync_single_inode)
+
+ ->i_mmap_rwsem
+ ->anon_vma.lock (vma_merge)
+
+ ->anon_vma.lock
+ ->page_table_lock or pte_lock (anon_vma_prepare and various)
+
+ ->page_table_lock or pte_lock
+ ->swap_lock (try_to_unmap_one)
+ ->private_lock (try_to_unmap_one)
+ ->i_pages lock (try_to_unmap_one)
+ ->lruvec->lru_lock (follow_page_mask->mark_page_accessed)
+ ->lruvec->lru_lock (check_pte_range->folio_isolate_lru)
+ ->private_lock (folio_remove_rmap_pte->set_page_dirty)
+ ->i_pages lock (folio_remove_rmap_pte->set_page_dirty)
+ bdi.wb->list_lock (folio_remove_rmap_pte->set_page_dirty)
+ ->inode->i_lock (folio_remove_rmap_pte->set_page_dirty)
+ bdi.wb->list_lock (zap_pte_range->set_page_dirty)
+ ->inode->i_lock (zap_pte_range->set_page_dirty)
+ ->private_lock (zap_pte_range->block_dirty_folio)
+
+Please check the current state of these comments which may have changed since
+the time of writing of this document.
+
+------------------------------
+Locking Implementation Details
+------------------------------
+
+.. warning:: Locking rules for PTE-level page tables are very different from
+ locking rules for page tables at other levels.
+
+Page table locking details
+--------------------------
+
+.. note:: This section explores page table locking requirements for page tables
+ encompassed by a VMA. See the above section on non-VMA page table
+ traversal for details on how we handle that case.
+
+In addition to the locks described in the terminology section above, we have
+additional locks dedicated to page tables:
+
+* **Higher level page table locks** - Higher level page tables, that is PGD, P4D
+ and PUD each make use of the process address space granularity
+ :c:member:`!mm->page_table_lock` lock when modified.
+
+* **Fine-grained page table locks** - PMDs and PTEs each have fine-grained locks
+ either kept within the folios describing the page tables or allocated
+ separated and pointed at by the folios if :c:macro:`!ALLOC_SPLIT_PTLOCKS` is
+ set. The PMD spin lock is obtained via :c:func:`!pmd_lock`, however PTEs are
+ mapped into higher memory (if a 32-bit system) and carefully locked via
+ :c:func:`!pte_offset_map_lock`.
+
+These locks represent the minimum required to interact with each page table
+level, but there are further requirements.
+
+Importantly, note that on a **traversal** of page tables, sometimes no such
+locks are taken. However, at the PTE level, at least concurrent page table
+deletion must be prevented (using RCU) and the page table must be mapped into
+high memory, see below.
+
+Whether care is taken on reading the page table entries depends on the
+architecture, see the section on atomicity below.
+
+Locking rules
+^^^^^^^^^^^^^
+
+We establish basic locking rules when interacting with page tables:
+
+* When changing a page table entry the page table lock for that page table
+ **must** be held, except if you can safely assume nobody can access the page
+ tables concurrently (such as on invocation of :c:func:`!free_pgtables`).
+* Reads from and writes to page table entries must be *appropriately*
+ atomic. See the section on atomicity below for details.
+* Populating previously empty entries requires that the mmap or VMA locks are
+ held (read or write), doing so with only rmap locks would be dangerous (see
+ the warning below).
+* As mentioned previously, zapping can be performed while simply keeping the VMA
+ stable, that is holding any one of the mmap, VMA or rmap locks.
+
+.. warning:: Populating previously empty entries is dangerous as, when unmapping
+ VMAs, :c:func:`!vms_clear_ptes` has a window of time between
+ zapping (via :c:func:`!unmap_vmas`) and freeing page tables (via
+ :c:func:`!free_pgtables`), where the VMA is still visible in the
+ rmap tree. :c:func:`!free_pgtables` assumes that the zap has
+ already been performed and removes PTEs unconditionally (along with
+ all other page tables in the freed range), so installing new PTE
+ entries could leak memory and also cause other unexpected and
+ dangerous behaviour.
+
+There are additional rules applicable when moving page tables, which we discuss
+in the section on this topic below.
+
+PTE-level page tables are different from page tables at other levels, and there
+are extra requirements for accessing them:
+
+* On 32-bit architectures, they may be in high memory (meaning they need to be
+ mapped into kernel memory to be accessible).
+* When empty, they can be unlinked and RCU-freed while holding an mmap lock or
+ rmap lock for reading in combination with the PTE and PMD page table locks.
+ In particular, this happens in :c:func:`!retract_page_tables` when handling
+ :c:macro:`!MADV_COLLAPSE`.
+ So accessing PTE-level page tables requires at least holding an RCU read lock;
+ but that only suffices for readers that can tolerate racing with concurrent
+ page table updates such that an empty PTE is observed (in a page table that
+ has actually already been detached and marked for RCU freeing) while another
+ new page table has been installed in the same location and filled with
+ entries. Writers normally need to take the PTE lock and revalidate that the
+ PMD entry still refers to the same PTE-level page table.
+ If the writer does not care whether it is the same PTE-level page table, it
+ can take the PMD lock and revalidate that the contents of pmd entry still meet
+ the requirements. In particular, this also happens in :c:func:`!retract_page_tables`
+ when handling :c:macro:`!MADV_COLLAPSE`.
+
+To access PTE-level page tables, a helper like :c:func:`!pte_offset_map_lock` or
+:c:func:`!pte_offset_map` can be used depending on stability requirements.
+These map the page table into kernel memory if required, take the RCU lock, and
+depending on variant, may also look up or acquire the PTE lock.
+See the comment on :c:func:`!__pte_offset_map_lock`.
+
+Atomicity
+^^^^^^^^^
+
+Regardless of page table locks, the MMU hardware concurrently updates accessed
+and dirty bits (perhaps more, depending on architecture). Additionally, page
+table traversal operations in parallel (though holding the VMA stable) and
+functionality like GUP-fast locklessly traverses (that is reads) page tables,
+without even keeping the VMA stable at all.
+
+When performing a page table traversal and keeping the VMA stable, whether a
+read must be performed once and only once or not depends on the architecture
+(for instance x86-64 does not require any special precautions).
+
+If a write is being performed, or if a read informs whether a write takes place
+(on an installation of a page table entry say, for instance in
+:c:func:`!__pud_install`), special care must always be taken. In these cases we
+can never assume that page table locks give us entirely exclusive access, and
+must retrieve page table entries once and only once.
+
+If we are reading page table entries, then we need only ensure that the compiler
+does not rearrange our loads. This is achieved via :c:func:`!pXXp_get`
+functions - :c:func:`!pgdp_get`, :c:func:`!p4dp_get`, :c:func:`!pudp_get`,
+:c:func:`!pmdp_get`, and :c:func:`!ptep_get`.
+
+Each of these uses :c:func:`!READ_ONCE` to guarantee that the compiler reads
+the page table entry only once.
+
+However, if we wish to manipulate an existing page table entry and care about
+the previously stored data, we must go further and use an hardware atomic
+operation as, for example, in :c:func:`!ptep_get_and_clear`.
+
+Equally, operations that do not rely on the VMA being held stable, such as
+GUP-fast (see :c:func:`!gup_fast` and its various page table level handlers like
+:c:func:`!gup_fast_pte_range`), must very carefully interact with page table
+entries, using functions such as :c:func:`!ptep_get_lockless` and equivalent for
+higher level page table levels.
+
+Writes to page table entries must also be appropriately atomic, as established
+by :c:func:`!set_pXX` functions - :c:func:`!set_pgd`, :c:func:`!set_p4d`,
+:c:func:`!set_pud`, :c:func:`!set_pmd`, and :c:func:`!set_pte`.
+
+Equally functions which clear page table entries must be appropriately atomic,
+as in :c:func:`!pXX_clear` functions - :c:func:`!pgd_clear`,
+:c:func:`!p4d_clear`, :c:func:`!pud_clear`, :c:func:`!pmd_clear`, and
+:c:func:`!pte_clear`.
+
+Page table installation
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Page table installation is performed with the VMA held stable explicitly by an
+mmap or VMA lock in read or write mode (see the warning in the locking rules
+section for details as to why).
+
+When allocating a P4D, PUD or PMD and setting the relevant entry in the above
+PGD, P4D or PUD, the :c:member:`!mm->page_table_lock` must be held. This is
+acquired in :c:func:`!__p4d_alloc`, :c:func:`!__pud_alloc` and
+:c:func:`!__pmd_alloc` respectively.
+
+.. note:: :c:func:`!__pmd_alloc` actually invokes :c:func:`!pud_lock` and
+ :c:func:`!pud_lockptr` in turn, however at the time of writing it ultimately
+ references the :c:member:`!mm->page_table_lock`.
+
+Allocating a PTE will either use the :c:member:`!mm->page_table_lock` or, if
+:c:macro:`!USE_SPLIT_PMD_PTLOCKS` is defined, a lock embedded in the PMD
+physical page metadata in the form of a :c:struct:`!struct ptdesc`, acquired by
+:c:func:`!pmd_ptdesc` called from :c:func:`!pmd_lock` and ultimately
+:c:func:`!__pte_alloc`.
+
+Finally, modifying the contents of the PTE requires special treatment, as the
+PTE page table lock must be acquired whenever we want stable and exclusive
+access to entries contained within a PTE, especially when we wish to modify
+them.
+
+This is performed via :c:func:`!pte_offset_map_lock` which carefully checks to
+ensure that the PTE hasn't changed from under us, ultimately invoking
+:c:func:`!pte_lockptr` to obtain a spin lock at PTE granularity contained within
+the :c:struct:`!struct ptdesc` associated with the physical PTE page. The lock
+must be released via :c:func:`!pte_unmap_unlock`.
+
+.. note:: There are some variants on this, such as
+ :c:func:`!pte_offset_map_rw_nolock` when we know we hold the PTE stable but
+ for brevity we do not explore this. See the comment for
+ :c:func:`!__pte_offset_map_lock` for more details.
+
+When modifying data in ranges we typically only wish to allocate higher page
+tables as necessary, using these locks to avoid races or overwriting anything,
+and set/clear data at the PTE level as required (for instance when page faulting
+or zapping).
+
+A typical pattern taken when traversing page table entries to install a new
+mapping is to optimistically determine whether the page table entry in the table
+above is empty, if so, only then acquiring the page table lock and checking
+again to see if it was allocated underneath us.
+
+This allows for a traversal with page table locks only being taken when
+required. An example of this is :c:func:`!__pud_alloc`.
+
+At the leaf page table, that is the PTE, we can't entirely rely on this pattern
+as we have separate PMD and PTE locks and a THP collapse for instance might have
+eliminated the PMD entry as well as the PTE from under us.
+
+This is why :c:func:`!__pte_offset_map_lock` locklessly retrieves the PMD entry
+for the PTE, carefully checking it is as expected, before acquiring the
+PTE-specific lock, and then *again* checking that the PMD entry is as expected.
+
+If a THP collapse (or similar) were to occur then the lock on both pages would
+be acquired, so we can ensure this is prevented while the PTE lock is held.
+
+Installing entries this way ensures mutual exclusion on write.
+
+Page table freeing
+^^^^^^^^^^^^^^^^^^
+
+Tearing down page tables themselves is something that requires significant
+care. There must be no way that page tables designated for removal can be
+traversed or referenced by concurrent tasks.
+
+It is insufficient to simply hold an mmap write lock and VMA lock (which will
+prevent racing faults, and rmap operations), as a file-backed mapping can be
+truncated under the :c:struct:`!struct address_space->i_mmap_rwsem` alone.
+
+As a result, no VMA which can be accessed via the reverse mapping (either
+through the :c:struct:`!struct anon_vma->rb_root` or the :c:member:`!struct
+address_space->i_mmap` interval trees) can have its page tables torn down.
+
+The operation is typically performed via :c:func:`!free_pgtables`, which assumes
+either the mmap write lock has been taken (as specified by its
+:c:member:`!mm_wr_locked` parameter), or that the VMA is already unreachable.
+
+It carefully removes the VMA from all reverse mappings, however it's important
+that no new ones overlap these or any route remain to permit access to addresses
+within the range whose page tables are being torn down.
+
+Additionally, it assumes that a zap has already been performed and steps have
+been taken to ensure that no further page table entries can be installed between
+the zap and the invocation of :c:func:`!free_pgtables`.
+
+Since it is assumed that all such steps have been taken, page table entries are
+cleared without page table locks (in the :c:func:`!pgd_clear`, :c:func:`!p4d_clear`,
+:c:func:`!pud_clear`, and :c:func:`!pmd_clear` functions.
+
+.. note:: It is possible for leaf page tables to be torn down independent of
+ the page tables above it as is done by
+ :c:func:`!retract_page_tables`, which is performed under the i_mmap
+ read lock, PMD, and PTE page table locks, without this level of care.
+
+Page table moving
+^^^^^^^^^^^^^^^^^
+
+Some functions manipulate page table levels above PMD (that is PUD, P4D and PGD
+page tables). Most notable of these is :c:func:`!mremap`, which is capable of
+moving higher level page tables.
+
+In these instances, it is required that **all** locks are taken, that is
+the mmap lock, the VMA lock and the relevant rmap locks.
+
+You can observe this in the :c:func:`!mremap` implementation in the functions
+:c:func:`!take_rmap_locks` and :c:func:`!drop_rmap_locks` which perform the rmap
+side of lock acquisition, invoked ultimately by :c:func:`!move_page_tables`.
+
+VMA lock internals
+------------------
+
+Overview
+^^^^^^^^
+
+VMA read locking is entirely optimistic - if the lock is contended or a competing
+write has started, then we do not obtain a read lock.
+
+A VMA **read** lock is obtained by :c:func:`!lock_vma_under_rcu`, which first
+calls :c:func:`!rcu_read_lock` to ensure that the VMA is looked up in an RCU
+critical section, then attempts to VMA lock it via :c:func:`!vma_start_read`,
+before releasing the RCU lock via :c:func:`!rcu_read_unlock`.
+
+In cases when the user already holds mmap read lock, :c:func:`!vma_start_read_locked`
+and :c:func:`!vma_start_read_locked_nested` can be used. These functions do not
+fail due to lock contention but the caller should still check their return values
+in case they fail for other reasons.
+
+VMA read locks increment :c:member:`!vma.vm_refcnt` reference counter for their
+duration and the caller of :c:func:`!lock_vma_under_rcu` must drop it via
+:c:func:`!vma_end_read`.
+
+VMA **write** locks are acquired via :c:func:`!vma_start_write` in instances where a
+VMA is about to be modified, unlike :c:func:`!vma_start_read` the lock is always
+acquired. An mmap write lock **must** be held for the duration of the VMA write
+lock, releasing or downgrading the mmap write lock also releases the VMA write
+lock so there is no :c:func:`!vma_end_write` function.
+
+Note that when write-locking a VMA lock, the :c:member:`!vma.vm_refcnt` is temporarily
+modified so that readers can detect the presense of a writer. The reference counter is
+restored once the vma sequence number used for serialisation is updated.
+
+This ensures the semantics we require - VMA write locks provide exclusive write
+access to the VMA.
+
+Implementation details
+^^^^^^^^^^^^^^^^^^^^^^
+
+The VMA lock mechanism is designed to be a lightweight means of avoiding the use
+of the heavily contended mmap lock. It is implemented using a combination of a
+reference counter and sequence numbers belonging to the containing
+:c:struct:`!struct mm_struct` and the VMA.
+
+Read locks are acquired via :c:func:`!vma_start_read`, which is an optimistic
+operation, i.e. it tries to acquire a read lock but returns false if it is
+unable to do so. At the end of the read operation, :c:func:`!vma_end_read` is
+called to release the VMA read lock.
+
+Invoking :c:func:`!vma_start_read` requires that :c:func:`!rcu_read_lock` has
+been called first, establishing that we are in an RCU critical section upon VMA
+read lock acquisition. Once acquired, the RCU lock can be released as it is only
+required for lookup. This is abstracted by :c:func:`!lock_vma_under_rcu` which
+is the interface a user should use.
+
+Writing requires the mmap to be write-locked and the VMA lock to be acquired via
+:c:func:`!vma_start_write`, however the write lock is released by the termination or
+downgrade of the mmap write lock so no :c:func:`!vma_end_write` is required.
+
+All this is achieved by the use of per-mm and per-VMA sequence counts, which are
+used in order to reduce complexity, especially for operations which write-lock
+multiple VMAs at once.
+
+If the mm sequence count, :c:member:`!mm->mm_lock_seq` is equal to the VMA
+sequence count :c:member:`!vma->vm_lock_seq` then the VMA is write-locked. If
+they differ, then it is not.
+
+Each time the mmap write lock is released in :c:func:`!mmap_write_unlock` or
+:c:func:`!mmap_write_downgrade`, :c:func:`!vma_end_write_all` is invoked which
+also increments :c:member:`!mm->mm_lock_seq` via
+:c:func:`!mm_lock_seqcount_end`.
+
+This way, we ensure that, regardless of the VMA's sequence number, a write lock
+is never incorrectly indicated and that when we release an mmap write lock we
+efficiently release **all** VMA write locks contained within the mmap at the
+same time.
+
+Since the mmap write lock is exclusive against others who hold it, the automatic
+release of any VMA locks on its release makes sense, as you would never want to
+keep VMAs locked across entirely separate write operations. It also maintains
+correct lock ordering.
+
+Each time a VMA read lock is acquired, we increment :c:member:`!vma.vm_refcnt`
+reference counter and check that the sequence count of the VMA does not match
+that of the mm.
+
+If it does, the read lock fails and :c:member:`!vma.vm_refcnt` is dropped.
+If it does not, we keep the reference counter raised, excluding writers, but
+permitting other readers, who can also obtain this lock under RCU.
+
+Importantly, maple tree operations performed in :c:func:`!lock_vma_under_rcu`
+are also RCU safe, so the whole read lock operation is guaranteed to function
+correctly.
+
+On the write side, we set a bit in :c:member:`!vma.vm_refcnt` which can't be
+modified by readers and wait for all readers to drop their reference count.
+Once there are no readers, the VMA's sequence number is set to match that of
+the mm. During this entire operation mmap write lock is held.
+
+This way, if any read locks are in effect, :c:func:`!vma_start_write` will sleep
+until these are finished and mutual exclusion is achieved.
+
+After setting the VMA's sequence number, the bit in :c:member:`!vma.vm_refcnt`
+indicating a writer is cleared. From this point on, VMA's sequence number will
+indicate VMA's write-locked state until mmap write lock is dropped or downgraded.
+
+This clever combination of a reference counter and sequence count allows for
+fast RCU-based per-VMA lock acquisition (especially on page fault, though
+utilised elsewhere) with minimal complexity around lock ordering.
+
+mmap write lock downgrading
+---------------------------
+
+When an mmap write lock is held one has exclusive access to resources within the
+mmap (with the usual caveats about requiring VMA write locks to avoid races with
+tasks holding VMA read locks).
+
+It is then possible to **downgrade** from a write lock to a read lock via
+:c:func:`!mmap_write_downgrade` which, similar to :c:func:`!mmap_write_unlock`,
+implicitly terminates all VMA write locks via :c:func:`!vma_end_write_all`, but
+importantly does not relinquish the mmap lock while downgrading, therefore
+keeping the locked virtual address space stable.
+
+An interesting consequence of this is that downgraded locks are exclusive
+against any other task possessing a downgraded lock (since a racing task would
+have to acquire a write lock first to downgrade it, and the downgraded lock
+prevents a new write lock from being obtained until the original lock is
+released).
+
+For clarity, we map read (R)/downgraded write (D)/write (W) locks against one
+another showing which locks exclude the others:
+
+.. list-table:: Lock exclusivity
+ :widths: 5 5 5 5
+ :header-rows: 1
+ :stub-columns: 1
+
+ * -
+ - R
+ - D
+ - W
+ * - R
+ - N
+ - N
+ - Y
+ * - D
+ - N
+ - Y
+ - Y
+ * - W
+ - Y
+ - Y
+ - Y
+
+Here a Y indicates the locks in the matching row/column are mutually exclusive,
+and N indicates that they are not.
+
+Stack expansion
+---------------
+
+Stack expansion throws up additional complexities in that we cannot permit there
+to be racing page faults, as a result we invoke :c:func:`!vma_start_write` to
+prevent this in :c:func:`!expand_downwards` or :c:func:`!expand_upwards`.
+
+------------------------
+Functions and structures
+------------------------
+
+.. kernel-doc:: include/linux/mmap_lock.h
diff --git a/Documentation/mm/remap_file_pages.rst b/Documentation/mm/remap_file_pages.rst
index 7bef6718e3a9..297091ce257c 100644
--- a/Documentation/mm/remap_file_pages.rst
+++ b/Documentation/mm/remap_file_pages.rst
@@ -1,5 +1,3 @@
-.. _remap_file_pages:
-
==============================
remap_file_pages() system call
==============================
diff --git a/Documentation/mm/slab.rst b/Documentation/mm/slab.rst
index 87d5a5bb172f..2bcc58ada302 100644
--- a/Documentation/mm/slab.rst
+++ b/Documentation/mm/slab.rst
@@ -3,3 +3,10 @@
===============
Slab Allocation
===============
+
+Functions and structures
+========================
+
+.. kernel-doc:: mm/slab.h
+.. kernel-doc:: mm/slub.c
+ :internal:
diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst
deleted file mode 100644
index 43063ade737a..000000000000
--- a/Documentation/mm/slub.rst
+++ /dev/null
@@ -1,452 +0,0 @@
-.. _slub:
-
-==========================
-Short users guide for SLUB
-==========================
-
-The basic philosophy of SLUB is very different from SLAB. SLAB
-requires rebuilding the kernel to activate debug options for all
-slab caches. SLUB always includes full debugging but it is off by default.
-SLUB can enable debugging only for selected slabs in order to avoid
-an impact on overall system performance which may make a bug more
-difficult to find.
-
-In order to switch debugging on one can add an option ``slub_debug``
-to the kernel command line. That will enable full debugging for
-all slabs.
-
-Typically one would then use the ``slabinfo`` command to get statistical
-data and perform operation on the slabs. By default ``slabinfo`` only lists
-slabs that have data in them. See "slabinfo -h" for more options when
-running the command. ``slabinfo`` can be compiled with
-::
-
- gcc -o slabinfo tools/vm/slabinfo.c
-
-Some of the modes of operation of ``slabinfo`` require that slub debugging
-be enabled on the command line. F.e. no tracking information will be
-available without debugging on and validation can only partially
-be performed if debugging was not switched on.
-
-Some more sophisticated uses of slub_debug:
--------------------------------------------
-
-Parameters may be given to ``slub_debug``. If none is specified then full
-debugging is enabled. Format:
-
-slub_debug=<Debug-Options>
- Enable options for all slabs
-
-slub_debug=<Debug-Options>,<slab name1>,<slab name2>,...
- Enable options only for select slabs (no spaces
- after a comma)
-
-Multiple blocks of options for all slabs or selected slabs can be given, with
-blocks of options delimited by ';'. The last of "all slabs" blocks is applied
-to all slabs except those that match one of the "select slabs" block. Options
-of the first "select slabs" blocks that matches the slab's name are applied.
-
-Possible debug options are::
-
- F Sanity checks on (enables SLAB_DEBUG_CONSISTENCY_CHECKS
- Sorry SLAB legacy issues)
- Z Red zoning
- P Poisoning (object and padding)
- U User tracking (free and alloc)
- T Trace (please only use on single slabs)
- A Enable failslab filter mark for the cache
- O Switch debugging off for caches that would have
- caused higher minimum slab orders
- - Switch all debugging off (useful if the kernel is
- configured with CONFIG_SLUB_DEBUG_ON)
-
-F.e. in order to boot just with sanity checks and red zoning one would specify::
-
- slub_debug=FZ
-
-Trying to find an issue in the dentry cache? Try::
-
- slub_debug=,dentry
-
-to only enable debugging on the dentry cache. You may use an asterisk at the
-end of the slab name, in order to cover all slabs with the same prefix. For
-example, here's how you can poison the dentry cache as well as all kmalloc
-slabs::
-
- slub_debug=P,kmalloc-*,dentry
-
-Red zoning and tracking may realign the slab. We can just apply sanity checks
-to the dentry cache with::
-
- slub_debug=F,dentry
-
-Debugging options may require the minimum possible slab order to increase as
-a result of storing the metadata (for example, caches with PAGE_SIZE object
-sizes). This has a higher liklihood of resulting in slab allocation errors
-in low memory situations or if there's high fragmentation of memory. To
-switch off debugging for such caches by default, use::
-
- slub_debug=O
-
-You can apply different options to different list of slab names, using blocks
-of options. This will enable red zoning for dentry and user tracking for
-kmalloc. All other slabs will not get any debugging enabled::
-
- slub_debug=Z,dentry;U,kmalloc-*
-
-You can also enable options (e.g. sanity checks and poisoning) for all caches
-except some that are deemed too performance critical and don't need to be
-debugged by specifying global debug options followed by a list of slab names
-with "-" as options::
-
- slub_debug=FZ;-,zs_handle,zspage
-
-The state of each debug option for a slab can be found in the respective files
-under::
-
- /sys/kernel/slab/<slab name>/
-
-If the file contains 1, the option is enabled, 0 means disabled. The debug
-options from the ``slub_debug`` parameter translate to the following files::
-
- F sanity_checks
- Z red_zone
- P poison
- U store_user
- T trace
- A failslab
-
-Careful with tracing: It may spew out lots of information and never stop if
-used on the wrong slab.
-
-Slab merging
-============
-
-If no debug options are specified then SLUB may merge similar slabs together
-in order to reduce overhead and increase cache hotness of objects.
-``slabinfo -a`` displays which slabs were merged together.
-
-Slab validation
-===============
-
-SLUB can validate all object if the kernel was booted with slub_debug. In
-order to do so you must have the ``slabinfo`` tool. Then you can do
-::
-
- slabinfo -v
-
-which will test all objects. Output will be generated to the syslog.
-
-This also works in a more limited way if boot was without slab debug.
-In that case ``slabinfo -v`` simply tests all reachable objects. Usually
-these are in the cpu slabs and the partial slabs. Full slabs are not
-tracked by SLUB in a non debug situation.
-
-Getting more performance
-========================
-
-To some degree SLUB's performance is limited by the need to take the
-list_lock once in a while to deal with partial slabs. That overhead is
-governed by the order of the allocation for each slab. The allocations
-can be influenced by kernel parameters:
-
-.. slub_min_objects=x (default 4)
-.. slub_min_order=x (default 0)
-.. slub_max_order=x (default 3 (PAGE_ALLOC_COSTLY_ORDER))
-
-``slub_min_objects``
- allows to specify how many objects must at least fit into one
- slab in order for the allocation order to be acceptable. In
- general slub will be able to perform this number of
- allocations on a slab without consulting centralized resources
- (list_lock) where contention may occur.
-
-``slub_min_order``
- specifies a minimum order of slabs. A similar effect like
- ``slub_min_objects``.
-
-``slub_max_order``
- specified the order at which ``slub_min_objects`` should no
- longer be checked. This is useful to avoid SLUB trying to
- generate super large order pages to fit ``slub_min_objects``
- of a slab cache with large object sizes into one high order
- page. Setting command line parameter
- ``debug_guardpage_minorder=N`` (N > 0), forces setting
- ``slub_max_order`` to 0, what cause minimum possible order of
- slabs allocation.
-
-SLUB Debug output
-=================
-
-Here is a sample of slub debug output::
-
- ====================================================================
- BUG kmalloc-8: Right Redzone overwritten
- --------------------------------------------------------------------
-
- INFO: 0xc90f6d28-0xc90f6d2b. First byte 0x00 instead of 0xcc
- INFO: Slab 0xc528c530 flags=0x400000c3 inuse=61 fp=0xc90f6d58
- INFO: Object 0xc90f6d20 @offset=3360 fp=0xc90f6d58
- INFO: Allocated in get_modalias+0x61/0xf5 age=53 cpu=1 pid=554
-
- Bytes b4 (0xc90f6d10): 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
- Object (0xc90f6d20): 31 30 31 39 2e 30 30 35 1019.005
- Redzone (0xc90f6d28): 00 cc cc cc .
- Padding (0xc90f6d50): 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
-
- [<c010523d>] dump_trace+0x63/0x1eb
- [<c01053df>] show_trace_log_lvl+0x1a/0x2f
- [<c010601d>] show_trace+0x12/0x14
- [<c0106035>] dump_stack+0x16/0x18
- [<c017e0fa>] object_err+0x143/0x14b
- [<c017e2cc>] check_object+0x66/0x234
- [<c017eb43>] __slab_free+0x239/0x384
- [<c017f446>] kfree+0xa6/0xc6
- [<c02e2335>] get_modalias+0xb9/0xf5
- [<c02e23b7>] dmi_dev_uevent+0x27/0x3c
- [<c027866a>] dev_uevent+0x1ad/0x1da
- [<c0205024>] kobject_uevent_env+0x20a/0x45b
- [<c020527f>] kobject_uevent+0xa/0xf
- [<c02779f1>] store_uevent+0x4f/0x58
- [<c027758e>] dev_attr_store+0x29/0x2f
- [<c01bec4f>] sysfs_write_file+0x16e/0x19c
- [<c0183ba7>] vfs_write+0xd1/0x15a
- [<c01841d7>] sys_write+0x3d/0x72
- [<c0104112>] sysenter_past_esp+0x5f/0x99
- [<b7f7b410>] 0xb7f7b410
- =======================
-
- FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc
-
-If SLUB encounters a corrupted object (full detection requires the kernel
-to be booted with slub_debug) then the following output will be dumped
-into the syslog:
-
-1. Description of the problem encountered
-
- This will be a message in the system log starting with::
-
- ===============================================
- BUG <slab cache affected>: <What went wrong>
- -----------------------------------------------
-
- INFO: <corruption start>-<corruption_end> <more info>
- INFO: Slab <address> <slab information>
- INFO: Object <address> <object information>
- INFO: Allocated in <kernel function> age=<jiffies since alloc> cpu=<allocated by
- cpu> pid=<pid of the process>
- INFO: Freed in <kernel function> age=<jiffies since free> cpu=<freed by cpu>
- pid=<pid of the process>
-
- (Object allocation / free information is only available if SLAB_STORE_USER is
- set for the slab. slub_debug sets that option)
-
-2. The object contents if an object was involved.
-
- Various types of lines can follow the BUG SLUB line:
-
- Bytes b4 <address> : <bytes>
- Shows a few bytes before the object where the problem was detected.
- Can be useful if the corruption does not stop with the start of the
- object.
-
- Object <address> : <bytes>
- The bytes of the object. If the object is inactive then the bytes
- typically contain poison values. Any non-poison value shows a
- corruption by a write after free.
-
- Redzone <address> : <bytes>
- The Redzone following the object. The Redzone is used to detect
- writes after the object. All bytes should always have the same
- value. If there is any deviation then it is due to a write after
- the object boundary.
-
- (Redzone information is only available if SLAB_RED_ZONE is set.
- slub_debug sets that option)
-
- Padding <address> : <bytes>
- Unused data to fill up the space in order to get the next object
- properly aligned. In the debug case we make sure that there are
- at least 4 bytes of padding. This allows the detection of writes
- before the object.
-
-3. A stackdump
-
- The stackdump describes the location where the error was detected. The cause
- of the corruption is may be more likely found by looking at the function that
- allocated or freed the object.
-
-4. Report on how the problem was dealt with in order to ensure the continued
- operation of the system.
-
- These are messages in the system log beginning with::
-
- FIX <slab cache affected>: <corrective action taken>
-
- In the above sample SLUB found that the Redzone of an active object has
- been overwritten. Here a string of 8 characters was written into a slab that
- has the length of 8 characters. However, a 8 character string needs a
- terminating 0. That zero has overwritten the first byte of the Redzone field.
- After reporting the details of the issue encountered the FIX SLUB message
- tells us that SLUB has restored the Redzone to its proper value and then
- system operations continue.
-
-Emergency operations
-====================
-
-Minimal debugging (sanity checks alone) can be enabled by booting with::
-
- slub_debug=F
-
-This will be generally be enough to enable the resiliency features of slub
-which will keep the system running even if a bad kernel component will
-keep corrupting objects. This may be important for production systems.
-Performance will be impacted by the sanity checks and there will be a
-continual stream of error messages to the syslog but no additional memory
-will be used (unlike full debugging).
-
-No guarantees. The kernel component still needs to be fixed. Performance
-may be optimized further by locating the slab that experiences corruption
-and enabling debugging only for that cache
-
-I.e.::
-
- slub_debug=F,dentry
-
-If the corruption occurs by writing after the end of the object then it
-may be advisable to enable a Redzone to avoid corrupting the beginning
-of other objects::
-
- slub_debug=FZ,dentry
-
-Extended slabinfo mode and plotting
-===================================
-
-The ``slabinfo`` tool has a special 'extended' ('-X') mode that includes:
- - Slabcache Totals
- - Slabs sorted by size (up to -N <num> slabs, default 1)
- - Slabs sorted by loss (up to -N <num> slabs, default 1)
-
-Additionally, in this mode ``slabinfo`` does not dynamically scale
-sizes (G/M/K) and reports everything in bytes (this functionality is
-also available to other slabinfo modes via '-B' option) which makes
-reporting more precise and accurate. Moreover, in some sense the `-X'
-mode also simplifies the analysis of slabs' behaviour, because its
-output can be plotted using the ``slabinfo-gnuplot.sh`` script. So it
-pushes the analysis from looking through the numbers (tons of numbers)
-to something easier -- visual analysis.
-
-To generate plots:
-
-a) collect slabinfo extended records, for example::
-
- while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done
-
-b) pass stats file(-s) to ``slabinfo-gnuplot.sh`` script::
-
- slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN]
-
- The ``slabinfo-gnuplot.sh`` script will pre-processes the collected records
- and generates 3 png files (and 3 pre-processing cache files) per STATS
- file:
- - Slabcache Totals: FOO_STATS-totals.png
- - Slabs sorted by size: FOO_STATS-slabs-by-size.png
- - Slabs sorted by loss: FOO_STATS-slabs-by-loss.png
-
-Another use case, when ``slabinfo-gnuplot.sh`` can be useful, is when you
-need to compare slabs' behaviour "prior to" and "after" some code
-modification. To help you out there, ``slabinfo-gnuplot.sh`` script
-can 'merge' the `Slabcache Totals` sections from different
-measurements. To visually compare N plots:
-
-a) Collect as many STATS1, STATS2, .. STATSN files as you need::
-
- while [ 1 ]; do slabinfo -X >> STATS<X>; sleep 1; done
-
-b) Pre-process those STATS files::
-
- slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN
-
-c) Execute ``slabinfo-gnuplot.sh`` in '-t' mode, passing all of the
- generated pre-processed \*-totals::
-
- slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals
-
- This will produce a single plot (png file).
-
- Plots, expectedly, can be large so some fluctuations or small spikes
- can go unnoticed. To deal with that, ``slabinfo-gnuplot.sh`` has two
- options to 'zoom-in'/'zoom-out':
-
- a) ``-s %d,%d`` -- overwrites the default image width and height
- b) ``-r %d,%d`` -- specifies a range of samples to use (for example,
- in ``slabinfo -X >> FOO_STATS; sleep 1;`` case, using a ``-r
- 40,60`` range will plot only samples collected between 40th and
- 60th seconds).
-
-
-DebugFS files for SLUB
-======================
-
-For more information about current state of SLUB caches with the user tracking
-debug option enabled, debugfs files are available, typically under
-/sys/kernel/debug/slab/<cache>/ (created only for caches with enabled user
-tracking). There are 2 types of these files with the following debug
-information:
-
-1. alloc_traces::
-
- Prints information about unique allocation traces of the currently
- allocated objects. The output is sorted by frequency of each trace.
-
- Information in the output:
- Number of objects, allocating function, minimal/average/maximal jiffies since alloc,
- pid range of the allocating processes, cpu mask of allocating cpus, and stack trace.
-
- Example:::
-
- 1085 populate_error_injection_list+0x97/0x110 age=166678/166680/166682 pid=1 cpus=1::
- __slab_alloc+0x6d/0x90
- kmem_cache_alloc_trace+0x2eb/0x300
- populate_error_injection_list+0x97/0x110
- init_error_injection+0x1b/0x71
- do_one_initcall+0x5f/0x2d0
- kernel_init_freeable+0x26f/0x2d7
- kernel_init+0xe/0x118
- ret_from_fork+0x22/0x30
-
-
-2. free_traces::
-
- Prints information about unique freeing traces of the currently allocated
- objects. The freeing traces thus come from the previous life-cycle of the
- objects and are reported as not available for objects allocated for the first
- time. The output is sorted by frequency of each trace.
-
- Information in the output:
- Number of objects, freeing function, minimal/average/maximal jiffies since free,
- pid range of the freeing processes, cpu mask of freeing cpus, and stack trace.
-
- Example:::
-
- 1980 <not-available> age=4294912290 pid=0 cpus=0
- 51 acpi_ut_update_ref_count+0x6a6/0x782 age=236886/237027/237772 pid=1 cpus=1
- kfree+0x2db/0x420
- acpi_ut_update_ref_count+0x6a6/0x782
- acpi_ut_update_object_reference+0x1ad/0x234
- acpi_ut_remove_reference+0x7d/0x84
- acpi_rs_get_prt_method_data+0x97/0xd6
- acpi_get_irq_routing_table+0x82/0xc4
- acpi_pci_irq_find_prt_entry+0x8e/0x2e0
- acpi_pci_irq_lookup+0x3a/0x1e0
- acpi_pci_irq_enable+0x77/0x240
- pcibios_enable_device+0x39/0x40
- do_pci_enable_device.part.0+0x5d/0xe0
- pci_enable_device_flags+0xfc/0x120
- pci_enable_device+0x13/0x20
- virtio_pci_probe+0x9e/0x170
- local_pci_probe+0x48/0x80
- pci_device_probe+0x105/0x1c0
-
-Christoph Lameter, May 30, 2007
-Sergey Senozhatsky, October 23, 2015
diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
index c08919662704..cc3cd46abd1b 100644
--- a/Documentation/mm/split_page_table_lock.rst
+++ b/Documentation/mm/split_page_table_lock.rst
@@ -1,12 +1,10 @@
-.. _split_page_table_lock:
-
=====================
Split page table lock
=====================
Originally, mm->page_table_lock spinlock protected all page tables of the
mm_struct. But this approach leads to poor page fault scalability of
-multi-threaded applications due high contention on the lock. To improve
+multi-threaded applications due to high contention on the lock. To improve
scalability, split page table lock was introduced.
With split page table lock we have separate per-table lock to serialize
@@ -16,15 +14,24 @@ tables. Access to higher level tables protected by mm->page_table_lock.
There are helpers to lock/unlock a table and other accessor functions:
- pte_offset_map_lock()
- maps pte and takes PTE table lock, returns pointer to the taken
- lock;
+ maps PTE and takes PTE table lock, returns pointer to PTE with
+ pointer to its PTE table lock, or returns NULL if no PTE table;
+ - pte_offset_map_ro_nolock()
+ maps PTE, returns pointer to PTE with pointer to its PTE table
+ lock (not taken), or returns NULL if no PTE table;
+ - pte_offset_map_rw_nolock()
+ maps PTE, returns pointer to PTE with pointer to its PTE table
+ lock (not taken) and the value of its pmd entry, or returns NULL
+ if no PTE table;
+ - pte_offset_map()
+ maps PTE, returns pointer to PTE, or returns NULL if no PTE table;
+ - pte_unmap()
+ unmaps PTE table;
- pte_unmap_unlock()
unlocks and unmaps PTE table;
- pte_alloc_map_lock()
- allocates PTE table if needed and take the lock, returns pointer
- to taken lock or NULL if allocation failed;
- - pte_lockptr()
- returns pointer to PTE table lock;
+ allocates PTE table if needed and takes its lock, returns pointer to
+ PTE with pointer to its lock, or returns NULL if allocation failed;
- pmd_lock()
takes PMD table lock, returns pointer to taken lock;
- pmd_lockptr()
@@ -55,7 +62,7 @@ Support of split page table lock by an architecture
===================================================
There's no need in special enabling of PTE split page table lock: everything
-required is done by pgtable_pte_page_ctor() and pgtable_pte_page_dtor(), which
+required is done by pagetable_pte_ctor() and pagetable_dtor(), which
must be called on PTE table allocation / freeing.
Make sure the architecture doesn't use slab allocator for page table
@@ -65,8 +72,8 @@ This field shares storage with page->ptl.
PMD split lock only makes sense if you have more than two page table
levels.
-PMD split lock enabling requires pgtable_pmd_page_ctor() call on PMD table
-allocation and pgtable_pmd_page_dtor() on freeing.
+PMD split lock enabling requires pagetable_pmd_ctor() call on PMD table
+allocation and pagetable_dtor() on freeing.
Allocation usually happens in pmd_alloc_one(), freeing in pmd_free() and
pmd_free_tlb(), but make sure you cover all PMD table allocation / freeing
@@ -74,7 +81,7 @@ paths: i.e X86_PAE preallocate few PMDs on pgd_alloc().
With everything in place you can set CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK.
-NOTE: pgtable_pte_page_ctor() and pgtable_pmd_page_ctor() can fail -- it must
+NOTE: pagetable_pte_ctor() and pagetable_pmd_ctor() can fail -- it must
be handled properly.
page->ptl
@@ -94,7 +101,7 @@ trick:
split lock with enabled DEBUG_SPINLOCK or DEBUG_LOCK_ALLOC, but costs
one more cache line for indirect access;
-The spinlock_t allocated in pgtable_pte_page_ctor() for PTE table and in
-pgtable_pmd_page_ctor() for PMD table.
+The spinlock_t allocated in pagetable_pte_ctor() for PTE table and in
+pagetable_pmd_ctor() for PMD table.
Please, never access page->ptl directly -- use appropriate helper.
diff --git a/Documentation/mm/swap-table.rst b/Documentation/mm/swap-table.rst
new file mode 100644
index 000000000000..da10bb7a0dc3
--- /dev/null
+++ b/Documentation/mm/swap-table.rst
@@ -0,0 +1,69 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+:Author: Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>
+
+==========
+Swap Table
+==========
+
+Swap table implements swap cache as a per-cluster swap cache value array.
+
+Swap Entry
+----------
+
+A swap entry contains the information required to serve the anonymous page
+fault.
+
+Swap entry is encoded as two parts: swap type and swap offset.
+
+The swap type indicates which swap device to use.
+The swap offset is the offset of the swap file to read the page data from.
+
+Swap Cache
+----------
+
+Swap cache is a map to look up folios using swap entry as the key. The result
+value can have three possible types depending on which stage of this swap entry
+was in.
+
+1. NULL: This swap entry is not used.
+
+2. folio: A folio has been allocated and bound to this swap entry. This is
+ the transient state of swap out or swap in. The folio data can be in
+ the folio or swap file, or both.
+
+3. shadow: The shadow contains the working set information of the swapped
+ out folio. This is the normal state for a swapped out page.
+
+Swap Table Internals
+--------------------
+
+The previous swap cache is implemented by XArray. The XArray is a tree
+structure. Each lookup will go through multiple nodes. Can we do better?
+
+Notice that most of the time when we look up the swap cache, we are either
+in a swap in or swap out path. We should already have the swap cluster,
+which contains the swap entry.
+
+If we have a per-cluster array to store swap cache value in the cluster.
+Swap cache lookup within the cluster can be a very simple array lookup.
+
+We give such a per-cluster swap cache value array a name: the swap table.
+
+A swap table is an array of pointers. Each pointer is the same size as a
+PTE. The size of a swap table for one swap cluster typically matches a PTE
+page table, which is one page on modern 64-bit systems.
+
+With swap table, swap cache lookup can achieve great locality, simpler,
+and faster.
+
+Locking
+-------
+
+Swap table modification requires taking the cluster lock. If a folio
+is being added to or removed from the swap table, the folio must be
+locked prior to the cluster lock. After adding or removing is done, the
+folio shall be unlocked.
+
+Swap table lookup is protected by RCU and atomic read. If the lookup
+returns a folio, the user must lock the folio before use.
diff --git a/Documentation/mm/transhuge.rst b/Documentation/mm/transhuge.rst
index 216db1d67d04..0e7f8e4cd2e3 100644
--- a/Documentation/mm/transhuge.rst
+++ b/Documentation/mm/transhuge.rst
@@ -1,5 +1,3 @@
-.. _transhuge:
-
============================
Transparent Hugepage Support
============================
@@ -33,10 +31,10 @@ Design principles
feature that applies to all dynamic high order allocations in the
kernel)
-get_user_pages and follow_page
-==============================
+get_user_pages and pin_user_pages
+=================================
-get_user_pages and follow_page if run on a hugepage, will return the
+get_user_pages and pin_user_pages if run on a hugepage, will return the
head or tail pages as usual (exactly as they would do on
hugetlbfs). Most GUP users will only care about the actual physical
address of the page and its temporary pinning to release after the I/O
@@ -112,36 +110,33 @@ Refcounts and transparent huge pages
Refcounting on THP is mostly consistent with refcounting on other compound
pages:
- - get_page()/put_page() and GUP operate on head page's ->_refcount.
+ - get_page()/put_page() and GUP operate on the folio->_refcount.
- ->_refcount in tail pages is always zero: get_page_unless_zero() never
succeeds on tail pages.
- - map/unmap of the pages with PTE entry increment/decrement ->_mapcount
- on relevant sub-page of the compound page.
-
- - map/unmap of the whole compound page is accounted for in compound_mapcount
- (stored in first tail page). For file huge pages, we also increment
- ->_mapcount of all sub-pages in order to have race-free detection of
- last unmap of subpages.
+ - map/unmap of a PMD entry for the whole THP increment/decrement
+ folio->_entire_mapcount and folio->_large_mapcount.
-PageDoubleMap() indicates that the page is *possibly* mapped with PTEs.
+ We also maintain the two slots for tracking MM owners (MM ID and
+ corresponding mapcount), and the current status ("maybe mapped shared" vs.
+ "mapped exclusively").
-For anonymous pages, PageDoubleMap() also indicates ->_mapcount in all
-subpages is offset up by one. This additional reference is required to
-get race-free detection of unmap of subpages when we have them mapped with
-both PMDs and PTEs.
+ With CONFIG_PAGE_MAPCOUNT, we also increment/decrement
+ folio->_nr_pages_mapped by ENTIRELY_MAPPED when _entire_mapcount goes
+ from -1 to 0 or 0 to -1.
-This optimization is required to lower the overhead of per-subpage mapcount
-tracking. The alternative is to alter ->_mapcount in all subpages on each
-map/unmap of the whole compound page.
+ - map/unmap of individual pages with PTE entry increment/decrement
+ folio->_large_mapcount.
-For anonymous pages, we set PG_double_map when a PMD of the page is split
-for the first time, but still have a PMD mapping. The additional references
-go away with the last compound_mapcount.
+ We also maintain the two slots for tracking MM owners (MM ID and
+ corresponding mapcount), and the current status ("maybe mapped shared" vs.
+ "mapped exclusively").
-File pages get PG_double_map set on the first map of the page with PTE and
-goes away when the page gets evicted from the page cache.
+ With CONFIG_PAGE_MAPCOUNT, we also increment/decrement
+ page->_mapcount and increment/decrement folio->_nr_pages_mapped when
+ page->_mapcount goes from -1 to 0 or 0 to -1 as this counts the number
+ of pages mapped by PTE.
split_huge_page internally has to distribute the refcounts in the head
page to the tail pages before clearing all PG_head/tail bits from the page
@@ -169,12 +164,12 @@ clear where references should go after split: it will stay on the head page.
Note that split_huge_pmd() doesn't have any limitations on refcounting:
pmd can be split at any point and never fails.
-Partial unmap and deferred_split_huge_page()
-============================================
+Partial unmap and deferred_split_folio() (anon THP only)
+========================================================
Unmapping part of THP (with munmap() or other way) is not going to free
memory immediately. Instead, we detect that a subpage of THP is not in use
-in page_remove_rmap() and queue the THP for splitting if memory pressure
+in folio_remove_rmap_*() and queue the THP for splitting if memory pressure
comes. Splitting will free up unused subpages.
Splitting the page right away is not an option due to locking context in
@@ -182,6 +177,16 @@ the place where we can detect partial unmap. It also might be
counterproductive since in many cases partial unmap happens during exit(2) if
a THP crosses a VMA boundary.
-The function deferred_split_huge_page() is used to queue a page for splitting.
+The function deferred_split_folio() is used to queue a folio for splitting.
The splitting itself will happen when we get memory pressure via shrinker
interface.
+
+With CONFIG_PAGE_MAPCOUNT, we reliably detect partial mappings based on
+folio->_nr_pages_mapped.
+
+With CONFIG_NO_PAGE_MAPCOUNT, we detect partial mappings based on the
+average per-page mapcount in a THP: if the average is < 1, an anon THP is
+certainly partially mapped. As long as only a single process maps a THP,
+this detection is reliable. With long-running child processes, there can
+be scenarios where partial mappings can currently not be detected, and
+might need asynchronous detection during memory reclaim in the future.
diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst
index 4a0e158aa9ce..8d11fe6a0854 100644
--- a/Documentation/mm/unevictable-lru.rst
+++ b/Documentation/mm/unevictable-lru.rst
@@ -1,5 +1,3 @@
-.. _unevictable_lru:
-
==============================
Unevictable LRU Infrastructure
==============================
@@ -12,7 +10,7 @@ Introduction
This document describes the Linux memory manager's "Unevictable LRU"
infrastructure and the use of this to manage several types of "unevictable"
-pages.
+folios.
The document attempts to provide the overall rationale behind this mechanism
and the rationale for some of the design decisions that drove the
@@ -27,8 +25,8 @@ The Unevictable LRU
===================
The Unevictable LRU facility adds an additional LRU list to track unevictable
-pages and to hide these pages from vmscan. This mechanism is based on a patch
-by Larry Woodman of Red Hat to address several scalability problems with page
+folios and to hide these folios from vmscan. This mechanism is based on a patch
+by Larry Woodman of Red Hat to address several scalability problems with folio
reclaim in Linux. The problems have been observed at customer sites on large
memory x86_64 systems.
@@ -44,6 +42,8 @@ The unevictable list addresses the following classes of unevictable pages:
* Those owned by ramfs.
+ * Those owned by tmpfs with the noswap mount option.
+
* Those mapped into SHM_LOCK'd shared memory regions.
* Those mapped into VM_LOCKED [mlock()ed] VMAs.
@@ -52,40 +52,41 @@ The infrastructure may also be able to handle other conditions that make pages
unevictable, either by definition or by circumstance, in the future.
-The Unevictable LRU Page List
------------------------------
+The Unevictable LRU Folio List
+------------------------------
-The Unevictable LRU page list is a lie. It was never an LRU-ordered list, but a
-companion to the LRU-ordered anonymous and file, active and inactive page lists;
-and now it is not even a page list. But following familiar convention, here in
-this document and in the source, we often imagine it as a fifth LRU page list.
+The Unevictable LRU folio list is a lie. It was never an LRU-ordered
+list, but a companion to the LRU-ordered anonymous and file, active and
+inactive folio lists; and now it is not even a folio list. But following
+familiar convention, here in this document and in the source, we often
+imagine it as a fifth LRU folio list.
The Unevictable LRU infrastructure consists of an additional, per-node, LRU list
-called the "unevictable" list and an associated page flag, PG_unevictable, to
-indicate that the page is being managed on the unevictable list.
+called the "unevictable" list and an associated folio flag, PG_unevictable, to
+indicate that the folio is being managed on the unevictable list.
The PG_unevictable flag is analogous to, and mutually exclusive with, the
-PG_active flag in that it indicates on which LRU list a page resides when
+PG_active flag in that it indicates on which LRU list a folio resides when
PG_lru is set.
-The Unevictable LRU infrastructure maintains unevictable pages as if they were
+The Unevictable LRU infrastructure maintains unevictable folios as if they were
on an additional LRU list for a few reasons:
- (1) We get to "treat unevictable pages just like we treat other pages in the
+ (1) We get to "treat unevictable folios just like we treat other folios in the
system - which means we get to use the same code to manipulate them, the
same code to isolate them (for migrate, etc.), the same code to keep track
of the statistics, etc..." [Rik van Riel]
- (2) We want to be able to migrate unevictable pages between nodes for memory
+ (2) We want to be able to migrate unevictable folios between nodes for memory
defragmentation, workload management and memory hotplug. The Linux kernel
- can only migrate pages that it can successfully isolate from the LRU
- lists (or "Movable" pages: outside of consideration here). If we were to
- maintain pages elsewhere than on an LRU-like list, where they can be
- detected by isolate_lru_page(), we would prevent their migration.
+ can only migrate folios that it can successfully isolate from the LRU
+ lists (or "Movable" folios: outside of consideration here). If we were to
+ maintain folios elsewhere than on an LRU-like list, where they can be
+ detected by folio_isolate_lru(), we would prevent their migration.
-The unevictable list does not differentiate between file-backed and anonymous,
-swap-backed pages. This differentiation is only important while the pages are,
-in fact, evictable.
+The unevictable list does not differentiate between file-backed and
+anonymous, swap-backed folios. This differentiation is only important
+while the folios are, in fact, evictable.
The unevictable list benefits from the "arrayification" of the per-node LRU
lists and statistics originally proposed and posted by Christoph Lameter.
@@ -158,7 +159,7 @@ These are currently used in three places in the kernel:
Detecting Unevictable Pages
---------------------------
-The function page_evictable() in mm/internal.h determines whether a page is
+The function folio_evictable() in mm/internal.h determines whether a folio is
evictable or not using the query function outlined above [see section
:ref:`Marking address spaces unevictable <mark_addr_space_unevict>`]
to check the AS_UNEVICTABLE flag.
@@ -167,7 +168,7 @@ For address spaces that are so marked after being populated (as SHM regions
might be), the lock action (e.g. SHM_LOCK) can be lazy, and need not populate
the page tables for the region as does, for example, mlock(), nor need it make
any special effort to push any pages in the SHM_LOCK'd area to the unevictable
-list. Instead, vmscan will do this if and when it encounters the pages during
+list. Instead, vmscan will do this if and when it encounters the folios during
a reclamation scan.
On an unlock action (such as SHM_UNLOCK), the unlocker (e.g. shmctl()) must scan
@@ -176,41 +177,43 @@ condition is keeping them unevictable. If an unevictable region is destroyed,
the pages are also "rescued" from the unevictable list in the process of
freeing them.
-page_evictable() also checks for mlocked pages by testing an additional page
-flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is
-faulted into a VM_LOCKED VMA, or found in a VMA being VM_LOCKED.
+folio_evictable() also checks for mlocked folios by calling
+folio_test_mlocked(), which is set when a folio is faulted into a
+VM_LOCKED VMA, or found in a VMA being VM_LOCKED.
-Vmscan's Handling of Unevictable Pages
---------------------------------------
+Vmscan's Handling of Unevictable Folios
+---------------------------------------
-If unevictable pages are culled in the fault path, or moved to the unevictable
-list at mlock() or mmap() time, vmscan will not encounter the pages until they
+If unevictable folios are culled in the fault path, or moved to the unevictable
+list at mlock() or mmap() time, vmscan will not encounter the folios until they
have become evictable again (via munlock() for example) and have been "rescued"
from the unevictable list. However, there may be situations where we decide,
-for the sake of expediency, to leave an unevictable page on one of the regular
+for the sake of expediency, to leave an unevictable folio on one of the regular
active/inactive LRU lists for vmscan to deal with. vmscan checks for such
-pages in all of the shrink_{active|inactive|page}_list() functions and will
-"cull" such pages that it encounters: that is, it diverts those pages to the
+folios in all of the shrink_{active|inactive|folio}_list() functions and will
+"cull" such folios that it encounters: that is, it diverts those folios to the
unevictable list for the memory cgroup and node being scanned.
-There may be situations where a page is mapped into a VM_LOCKED VMA, but the
-page is not marked as PG_mlocked. Such pages will make it all the way to
-shrink_active_list() or shrink_page_list() where they will be detected when
-vmscan walks the reverse map in folio_referenced() or try_to_unmap(). The page
-is culled to the unevictable list when it is released by the shrinker.
+There may be situations where a folio is mapped into a VM_LOCKED VMA,
+but the folio does not have the mlocked flag set. Such folios will make
+it all the way to shrink_active_list() or shrink_folio_list() where they
+will be detected when vmscan walks the reverse map in folio_referenced()
+or try_to_unmap(). The folio is culled to the unevictable list when it
+is released by the shrinker.
-To "cull" an unevictable page, vmscan simply puts the page back on the LRU list
-using putback_lru_page() - the inverse operation to isolate_lru_page() - after
-dropping the page lock. Because the condition which makes the page unevictable
-may change once the page is unlocked, __pagevec_lru_add_fn() will recheck the
-unevictable state of a page before placing it on the unevictable list.
+To "cull" an unevictable folio, vmscan simply puts the folio back on
+the LRU list using folio_putback_lru() - the inverse operation to
+folio_isolate_lru() - after dropping the folio lock. Because the
+condition which makes the folio unevictable may change once the folio
+is unlocked, __pagevec_lru_add_fn() will recheck the unevictable state
+of a folio before placing it on the unevictable list.
MLOCKED Pages
=============
-The unevictable page list is also useful for mlock(), in addition to ramfs and
+The unevictable folio list is also useful for mlock(), in addition to ramfs and
SYSV SHM. Note that mlock() is only available in CONFIG_MMU=y situations; in
NOMMU situations, all mappings are effectively mlocked.
@@ -227,7 +230,7 @@ In Nick's patch, he used one of the struct page LRU list link fields as a count
of VM_LOCKED VMAs that map the page (Rik van Riel had the same idea three years
earlier). But this use of the link field for a count prevented the management
of the pages on an LRU list, and thus mlocked pages were not migratable as
-isolate_lru_page() could not detect them, and the LRU list link field was not
+folio_isolate_lru() could not detect them, and the LRU list link field was not
available to the migration subsystem.
Nick resolved this by putting mlocked pages back on the LRU list before
@@ -250,8 +253,8 @@ Basic Management
mlocked pages - pages mapped into a VM_LOCKED VMA - are a class of unevictable
pages. When such a page has been "noticed" by the memory management subsystem,
-the page is marked with the PG_mlocked flag. This can be manipulated using the
-PageMlocked() functions.
+the folio is marked with the PG_mlocked flag. This can be manipulated using
+folio_set_mlocked() and folio_clear_mlocked() functions.
A PG_mlocked page will be placed on the unevictable list when it is added to
the LRU. Such pages can be "noticed" by memory management in several places:
@@ -266,7 +269,7 @@ the LRU. Such pages can be "noticed" by memory management in several places:
(4) in the fault path and when a VM_LOCKED stack segment is expanded; or
- (5) as mentioned above, in vmscan:shrink_page_list() when attempting to
+ (5) as mentioned above, in vmscan:shrink_folio_list() when attempting to
reclaim a page in a VM_LOCKED VMA by folio_referenced() or try_to_unmap().
mlocked pages become unlocked and rescued from the unevictable list when:
@@ -295,7 +298,7 @@ treated as a no-op and mlock_fixup() simply returns.
If the VMA passes some filtering as described in "Filtering Special VMAs"
below, mlock_fixup() will attempt to merge the VMA with its neighbors or split
off a subset of the VMA if the range does not cover the entire VMA. Any pages
-already present in the VMA are then marked as mlocked by mlock_page() via
+already present in the VMA are then marked as mlocked by mlock_folio() via
mlock_pte_range() via walk_page_range() via mlock_vma_pages_range().
Before returning from the system call, do_mlock() or mlockall() will call
@@ -308,22 +311,22 @@ do end up getting faulted into this VM_LOCKED VMA, they will be handled in the
fault path - which is also how mlock2()'s MLOCK_ONFAULT areas are handled.
For each PTE (or PMD) being faulted into a VMA, the page add rmap function
-calls mlock_vma_page(), which calls mlock_page() when the VMA is VM_LOCKED
+calls mlock_vma_folio(), which calls mlock_folio() when the VMA is VM_LOCKED
(unless it is a PTE mapping of a part of a transparent huge page). Or when
-it is a newly allocated anonymous page, lru_cache_add_inactive_or_unevictable()
-calls mlock_new_page() instead: similar to mlock_page(), but can make better
+it is a newly allocated anonymous page, folio_add_lru_vma() calls
+mlock_new_folio() instead: similar to mlock_folio(), but can make better
judgments, since this page is held exclusively and known not to be on LRU yet.
-mlock_page() sets PageMlocked immediately, then places the page on the CPU's
-mlock pagevec, to batch up the rest of the work to be done under lru_lock by
-__mlock_page(). __mlock_page() sets PageUnevictable, initializes mlock_count
+mlock_folio() sets PG_mlocked immediately, then places the page on the CPU's
+mlock folio batch, to batch up the rest of the work to be done under lru_lock by
+__mlock_folio(). __mlock_folio() sets PG_unevictable, initializes mlock_count
and moves the page to unevictable state ("the unevictable LRU", but with
-mlock_count in place of LRU threading). Or if the page was already PageLRU
-and PageUnevictable and PageMlocked, it simply increments the mlock_count.
+mlock_count in place of LRU threading). Or if the page was already PG_lru
+and PG_unevictable and PG_mlocked, it simply increments the mlock_count.
But in practice that may not work ideally: the page may not yet be on an LRU, or
it may have been temporarily isolated from LRU. In such cases the mlock_count
-field cannot be touched, but will be set to 0 later when __pagevec_lru_add_fn()
+field cannot be touched, but will be set to 0 later when __munlock_folio()
returns the page to "LRU". Races prohibit mlock_count from being set to 1 then:
rather than risk stranding a page indefinitely as unevictable, always err with
mlock_count on the low side, so that when munlocked the page will be rescued to
@@ -370,20 +373,21 @@ Because of the VMA filtering discussed above, VM_LOCKED will not be set in
any "special" VMAs. So, those VMAs will be ignored for munlock.
If the VMA is VM_LOCKED, mlock_fixup() again attempts to merge or split off the
-specified range. All pages in the VMA are then munlocked by munlock_page() via
+specified range. All pages in the VMA are then munlocked by munlock_folio() via
mlock_pte_range() via walk_page_range() via mlock_vma_pages_range() - the same
function used when mlocking a VMA range, with new flags for the VMA indicating
that it is munlock() being performed.
-munlock_page() uses the mlock pagevec to batch up work to be done under
-lru_lock by __munlock_page(). __munlock_page() decrements the page's
-mlock_count, and when that reaches 0 it clears PageMlocked and clears
-PageUnevictable, moving the page from unevictable state to inactive LRU.
+munlock_folio() uses the mlock pagevec to batch up work to be done
+under lru_lock by __munlock_folio(). __munlock_folio() decrements the
+folio's mlock_count, and when that reaches 0 it clears the mlocked flag
+and clears the unevictable flag, moving the folio from unevictable state
+to the inactive LRU.
-But in practice that may not work ideally: the page may not yet have reached
+But in practice that may not work ideally: the folio may not yet have reached
"the unevictable LRU", or it may have been temporarily isolated from it. In
those cases its mlock_count field is unusable and must be assumed to be 0: so
-that the page will be rescued to an evictable LRU, then perhaps be mlocked
+that the folio will be rescued to an evictable LRU, then perhaps be mlocked
again later if vmscan finds it in a VM_LOCKED VMA.
@@ -410,7 +414,7 @@ However, since mlock_vma_pages_range() starts by setting VM_LOCKED on a VMA,
before mlocking any pages already present, if one of those pages were migrated
before mlock_pte_range() reached it, it would get counted twice in mlock_count.
To prevent that, mlock_vma_pages_range() temporarily marks the VMA as VM_IO,
-so that mlock_vma_page() will skip it.
+so that mlock_vma_folio() will skip it.
To complete page migration, we place the old and new pages back onto the LRU
afterwards. The "unneeded" page - old page on success, new page on failure -
@@ -459,7 +463,7 @@ can request that a region of memory be mlocked by supplying the MAP_LOCKED flag
to the mmap() call. There is one important and subtle difference here, though.
mmap() + mlock() will fail if the range cannot be faulted in (e.g. because
mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail.
-The mmaped area will still have properties of the locked area - pages will not
+The mmapped area will still have properties of the locked area - pages will not
get swapped out - but major page faults to fault memory in might still happen.
Furthermore, any mmap() call or brk() call that expands the heap by a task
@@ -482,19 +486,20 @@ munlock the pages if we're removing the last VM_LOCKED VMA that maps the pages.
Before the unevictable/mlock changes, mlocking did not mark the pages in any
way, so unmapping them required no processing.
-For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
-munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED
+For each PTE (or PMD) being unmapped from a VMA, folio_remove_rmap_*() calls
+munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
(unless it was a PTE mapping of a part of a transparent huge page).
-munlock_page() uses the mlock pagevec to batch up work to be done under
-lru_lock by __munlock_page(). __munlock_page() decrements the page's
-mlock_count, and when that reaches 0 it clears PageMlocked and clears
-PageUnevictable, moving the page from unevictable state to inactive LRU.
+munlock_folio() uses the mlock pagevec to batch up work to be done
+under lru_lock by __munlock_folio(). __munlock_folio() decrements the
+folio's mlock_count, and when that reaches 0 it clears the mlocked flag
+and clears the unevictable flag, moving the folio from unevictable state
+to the inactive LRU.
-But in practice that may not work ideally: the page may not yet have reached
+But in practice that may not work ideally: the folio may not yet have reached
"the unevictable LRU", or it may have been temporarily isolated from it. In
those cases its mlock_count field is unusable and must be assumed to be 0: so
-that the page will be rescued to an evictable LRU, then perhaps be mlocked
+that the folio will be rescued to an evictable LRU, then perhaps be mlocked
again later if vmscan finds it in a VM_LOCKED VMA.
@@ -506,8 +511,8 @@ userspace; truncation even unmaps and deletes any private anonymous pages
which had been Copied-On-Write from the file pages now being truncated.
Mlocked pages can be munlocked and deleted in this way: like with munmap(),
-for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
-munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED
+for each PTE (or PMD) being unmapped from a VMA, folio_remove_rmap_*() calls
+munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
(unless it was a PTE mapping of a part of a transparent huge page).
However, if there is a racing munlock(), since mlock_vma_pages_range() starts
@@ -515,7 +520,7 @@ munlocking by clearing VM_LOCKED from a VMA, before munlocking all the pages
present, if one of those pages were unmapped by truncation or hole punch before
mlock_pte_range() reached it, it would not be recognized as mlocked by this VMA,
and would not be counted out of mlock_count. In this rare case, a page may
-still appear as PageMlocked after it has been fully unmapped: and it is left to
+still appear as PG_mlocked after it has been fully unmapped: and it is left to
release_pages() (or __page_cache_release()) to clear it and update statistics
before freeing (this event is counted in /proc/vmstat unevictable_pgs_cleared,
which is usually 0).
@@ -527,7 +532,7 @@ Page Reclaim in shrink_*_list()
vmscan's shrink_active_list() culls any obviously unevictable pages -
i.e. !page_evictable(page) pages - diverting those to the unevictable list.
However, shrink_active_list() only sees unevictable pages that made it onto the
-active/inactive LRU lists. Note that these pages do not have PageUnevictable
+active/inactive LRU lists. Note that these pages do not have PG_unevictable
set - otherwise they would be on the unevictable list and shrink_active_list()
would never see them.
@@ -543,12 +548,12 @@ Some examples of these unevictable pages on the LRU lists are:
(3) pages still mapped into VM_LOCKED VMAs, which should be marked mlocked,
but events left mlock_count too low, so they were munlocked too early.
-vmscan's shrink_inactive_list() and shrink_page_list() also divert obviously
+vmscan's shrink_inactive_list() and shrink_folio_list() also divert obviously
unevictable pages found on the inactive lists to the appropriate memory cgroup
and node unevictable list.
rmap's folio_referenced_one(), called via vmscan's shrink_active_list() or
-shrink_page_list(), and rmap's try_to_unmap_one() called via shrink_page_list(),
-check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_page()
+shrink_folio_list(), and rmap's try_to_unmap_one() called via shrink_folio_list(),
+check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_folio()
to correct them. Such pages are culled to the unevictable list when released
by the shrinker.
diff --git a/Documentation/mm/vmalloced-kernel-stacks.rst b/Documentation/mm/vmalloced-kernel-stacks.rst
index fc8c67833af6..5bc0f7ceea89 100644
--- a/Documentation/mm/vmalloced-kernel-stacks.rst
+++ b/Documentation/mm/vmalloced-kernel-stacks.rst
@@ -22,7 +22,7 @@ Kernel stack overflows are often hard to debug and make the kernel
susceptible to exploits. Problems could show up at a later time making
it difficult to isolate and root-cause.
-Virtually-mapped kernel stacks with guard pages causes kernel stack
+Virtually mapped kernel stacks with guard pages cause kernel stack
overflows to be caught immediately rather than causing difficult to
diagnose corruptions.
@@ -57,7 +57,7 @@ enable this bool configuration option. The requirements are:
VMAP_STACK
----------
-VMAP_STACK bool configuration option when enabled allocates virtually
+When enabled, the VMAP_STACK bool configuration option allocates virtually
mapped task stacks. This option depends on HAVE_ARCH_VMAP_STACK.
- Enable this if you want the use virtually-mapped kernel stacks
@@ -83,7 +83,7 @@ the latest code base:
Allocation
-----------
-When a new kernel thread is created, thread stack is allocated from
+When a new kernel thread is created, a thread stack is allocated from
virtually contiguous memory pages from the page level allocator. These
pages are mapped into contiguous kernel virtual space with PAGE_KERNEL
protections.
@@ -103,14 +103,14 @@ with PAGE_KERNEL protections.
- This does not address interrupt stacks - according to the original patch
Thread stack allocation is initiated from clone(), fork(), vfork(),
-kernel_thread() via kernel_clone(). Leaving a few hints for searching
-the code base to understand when and how thread stack is allocated.
+kernel_thread() via kernel_clone(). These are a few hints for searching
+the code base to understand when and how a thread stack is allocated.
Bulk of the code is in:
`kernel/fork.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c>`.
stack_vm_area pointer in task_struct keeps track of the virtually allocated
-stack and a non-null stack_vm_area pointer serves as a indication that the
+stack and a non-null stack_vm_area pointer serves as an indication that the
virtually mapped kernel stacks are enabled.
::
@@ -120,8 +120,8 @@ virtually mapped kernel stacks are enabled.
Stack overflow handling
-----------------------
-Leading and trailing guard pages help detect stack overflows. When stack
-overflows into the guard pages, handlers have to be careful not overflow
+Leading and trailing guard pages help detect stack overflows. When the stack
+overflows into the guard pages, handlers have to be careful not to overflow
the stack again. When handlers are called, it is likely that very little
stack space is left.
@@ -148,6 +148,6 @@ Conclusions
- THREAD_INFO_IN_TASK gets rid of arch-specific thread_info entirely and
simply embed the thread_info (containing only flags) and 'int cpu' into
task_struct.
-- The thread stack can be free'ed as soon as the task is dead (without
+- The thread stack can be freed as soon as the task is dead (without
waiting for RCU) and then, if vmapped stacks are in use, cache the
entire stack for reuse on the same cpu.
diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst
index a4b12ff906c4..b4a55b6569fa 100644
--- a/Documentation/mm/vmemmap_dedup.rst
+++ b/Documentation/mm/vmemmap_dedup.rst
@@ -1,3 +1,4 @@
+
.. SPDX-License-Identifier: GPL-2.0
=========================================
@@ -10,14 +11,14 @@ HugeTLB
This section is to explain how HugeTLB Vmemmap Optimization (HVO) works.
The ``struct page`` structures are used to describe a physical page frame. By
-default, there is a one-to-one mapping from a page frame to it's corresponding
+default, there is a one-to-one mapping from a page frame to its corresponding
``struct page``.
HugeTLB pages consist of multiple base page size pages and is supported by many
architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more
details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are
currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page
-consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages.
+consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages.
For each base page, there is a corresponding ``struct page``.
Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to
@@ -179,27 +180,7 @@ this correctly. There is only **one** head ``struct page``, the tail
``struct page`` with ``PG_head`` are fake head ``struct page``. We need an
approach to distinguish between those two different types of ``struct page`` so
that ``compound_head()`` can return the real head ``struct page`` when the
-parameter is the tail ``struct page`` but with ``PG_head``. The following code
-snippet describes how to distinguish between real and fake head ``struct page``.
-
-.. code-block:: c
-
- if (test_bit(PG_head, &page->flags)) {
- unsigned long head = READ_ONCE(page[1].compound_head);
-
- if (head & 1) {
- if (head == (unsigned long)page + 1)
- /* head struct page */
- else
- /* tail struct page */
- } else {
- /* head struct page */
- }
- }
-
-We can safely access the field of the **page[1]** with ``PG_head`` because the
-page is a compound page composed with at least two contiguous pages.
-The implementation refers to ``page_fixed_fake_head()``.
+parameter is the tail ``struct page`` but with ``PG_head``.
Device DAX
==========
@@ -210,6 +191,7 @@ the device (altmap).
The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64),
PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64).
+For powerpc equivalent details see Documentation/arch/powerpc/vmemmap_dedup.rst
The differences with HugeTLB are relatively minor.
diff --git a/Documentation/mm/z3fold.rst b/Documentation/mm/z3fold.rst
deleted file mode 100644
index 224e3c61d686..000000000000
--- a/Documentation/mm/z3fold.rst
+++ /dev/null
@@ -1,30 +0,0 @@
-.. _z3fold:
-
-======
-z3fold
-======
-
-z3fold is a special purpose allocator for storing compressed pages.
-It is designed to store up to three compressed pages per physical page.
-It is a zbud derivative which allows for higher compression
-ratio keeping the simplicity and determinism of its predecessor.
-
-The main differences between z3fold and zbud are:
-
-* unlike zbud, z3fold allows for up to PAGE_SIZE allocations
-* z3fold can hold up to 3 compressed pages in its page
-* z3fold doesn't export any API itself and is thus intended to be used
- via the zpool API.
-
-To keep the determinism and simplicity, z3fold, just like zbud, always
-stores an integral number of compressed pages per page, but it can store
-up to 3 pages unlike zbud which can store at most 2. Therefore the
-compression ratio goes to around 2.7x while zbud's one is around 1.7x.
-
-Unlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not
-return a dereferenceable pointer. Instead, it returns an unsigned long
-handle which encodes actual location of the allocated object.
-
-Keeping effective compression ratio close to zsmalloc's, z3fold doesn't
-depend on MMU enabled and provides more predictable reclaim behavior
-which makes it a better fit for small and response-critical systems.
diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst
index 6e79893d6132..d2bbecd78e14 100644
--- a/Documentation/mm/zsmalloc.rst
+++ b/Documentation/mm/zsmalloc.rst
@@ -1,5 +1,3 @@
-.. _zsmalloc:
-
========
zsmalloc
========
@@ -29,9 +27,8 @@ Instead, it returns an opaque handle (unsigned long) which encodes actual
location of the allocated object. The reason for this indirection is that
zsmalloc does not keep zspages permanently mapped since that would cause
issues on 32-bit systems where the VA region for kernel space mappings
-is very small. So, before using the allocating memory, the object has to
-be mapped using zs_map_object() to get a usable pointer and subsequently
-unmapped using zs_unmap_object().
+is very small. So, using the allocated memory should be done through the
+proper handle-based APIs.
stat
====
@@ -41,13 +38,12 @@ With CONFIG_ZSMALLOC_STAT, we could see zsmalloc internal information via
# cat /sys/kernel/debug/zsmalloc/zram0/classes
- class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage
+ class size 10% 20% 30% 40% 50% 60% 70% 80% 90% 99% 100% obj_allocated obj_used pages_used pages_per_zspage freeable
...
...
- 9 176 0 1 186 129 8 4
- 10 192 1 0 2880 2872 135 3
- 11 208 0 1 819 795 42 2
- 12 224 0 1 219 159 12 4
+ 30 512 0 12 4 1 0 1 0 0 1 0 414 3464 3346 433 1 14
+ 31 528 2 7 2 2 1 0 1 0 0 2 117 4154 3793 536 4 44
+ 32 544 6 3 4 1 2 1 0 0 0 1 260 4170 3965 556 2 26
...
...
@@ -56,10 +52,28 @@ class
index
size
object size zspage stores
-almost_empty
- the number of ZS_ALMOST_EMPTY zspages(see below)
-almost_full
- the number of ZS_ALMOST_FULL zspages(see below)
+10%
+ the number of zspages with usage ratio less than 10% (see below)
+20%
+ the number of zspages with usage ratio between 10% and 20%
+30%
+ the number of zspages with usage ratio between 20% and 30%
+40%
+ the number of zspages with usage ratio between 30% and 40%
+50%
+ the number of zspages with usage ratio between 40% and 50%
+60%
+ the number of zspages with usage ratio between 50% and 60%
+70%
+ the number of zspages with usage ratio between 60% and 70%
+80%
+ the number of zspages with usage ratio between 70% and 80%
+90%
+ the number of zspages with usage ratio between 80% and 90%
+99%
+ the number of zspages with usage ratio between 90% and 99%
+100%
+ the number of zspages with usage ratio 100%
obj_allocated
the number of objects allocated
obj_used
@@ -68,15 +82,188 @@ pages_used
the number of pages allocated for the class
pages_per_zspage
the number of 0-order pages to make a zspage
+freeable
+ the approximate number of pages class compaction can free
+
+Each zspage maintains inuse counter which keeps track of the number of
+objects stored in the zspage. The inuse counter determines the zspage's
+"fullness group" which is calculated as the ratio of the "inuse" objects to
+the total number of objects the zspage can hold (objs_per_zspage). The
+closer the inuse counter is to objs_per_zspage, the better.
+
+Internals
+=========
+
+zsmalloc has 255 size classes, each of which can hold a number of zspages.
+Each zspage can contain up to ZSMALLOC_CHAIN_SIZE physical (0-order) pages.
+The optimal zspage chain size for each size class is calculated during the
+creation of the zsmalloc pool (see calculate_zspage_chain_size()).
+
+As an optimization, zsmalloc merges size classes that have similar
+characteristics in terms of the number of pages per zspage and the number
+of objects that each zspage can store.
+
+For instance, consider the following size classes:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+ ...
+ 94 1536 0 .... 0 0 0 0 3 0
+ 100 1632 0 .... 0 0 0 0 2 0
+ ...
+
+
+Size classes #95-99 are merged with size class #100. This means that when we
+need to store an object of size, say, 1568 bytes, we end up using size class
+#100 instead of size class #96. Size class #100 is meant for objects of size
+1632 bytes, so each object of size 1568 bytes wastes 1632-1568=64 bytes.
+
+Size class #100 consists of zspages with 2 physical pages each, which can
+hold a total of 5 objects. If we need to store 13 objects of size 1568, we
+end up allocating three zspages, or 6 physical pages.
+
+However, if we take a closer look at size class #96 (which is meant for
+objects of size 1568 bytes) and trace `calculate_zspage_chain_size()`, we
+find that the most optimal zspage configuration for this class is a chain
+of 5 physical pages:::
+
+ pages per zspage wasted bytes used%
+ 1 960 76
+ 2 352 95
+ 3 1312 89
+ 4 704 95
+ 5 96 99
+
+This means that a class #96 configuration with 5 physical pages can store 13
+objects of size 1568 in a single zspage, using a total of 5 physical pages.
+This is more efficient than the class #100 configuration, which would use 6
+physical pages to store the same number of objects.
+
+As the zspage chain size for class #96 increases, its key characteristics
+such as pages per-zspage and objects per-zspage also change. This leads to
+dewer class mergers, resulting in a more compact grouping of classes, which
+reduces memory wastage.
+
+Let's take a closer look at the bottom of `/sys/kernel/debug/zsmalloc/zramX/classes`:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ 202 3264 0 .. 0 0 0 0 4 0
+ 254 4096 0 .. 0 0 0 0 1 0
+ ...
+
+Size class #202 stores objects of size 3264 bytes and has a maximum of 4 pages
+per zspage. Any object larger than 3264 bytes is considered huge and belongs
+to size class #254, which stores each object in its own physical page (objects
+in huge classes do not share pages).
+
+Increasing the size of the chain of zspages also results in a higher watermark
+for the huge size class and fewer huge classes overall. This allows for more
+efficient storage of large objects.
+
+For zspage chain size of 8, huge class watermark becomes 3632 bytes:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ 202 3264 0 .. 0 0 0 0 4 0
+ 211 3408 0 .. 0 0 0 0 5 0
+ 217 3504 0 .. 0 0 0 0 6 0
+ 222 3584 0 .. 0 0 0 0 7 0
+ 225 3632 0 .. 0 0 0 0 8 0
+ 254 4096 0 .. 0 0 0 0 1 0
+ ...
+
+For zspage chain size of 16, huge class watermark becomes 3840 bytes:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ 202 3264 0 .. 0 0 0 0 4 0
+ 206 3328 0 .. 0 0 0 0 13 0
+ 207 3344 0 .. 0 0 0 0 9 0
+ 208 3360 0 .. 0 0 0 0 14 0
+ 211 3408 0 .. 0 0 0 0 5 0
+ 212 3424 0 .. 0 0 0 0 16 0
+ 214 3456 0 .. 0 0 0 0 11 0
+ 217 3504 0 .. 0 0 0 0 6 0
+ 219 3536 0 .. 0 0 0 0 13 0
+ 222 3584 0 .. 0 0 0 0 7 0
+ 223 3600 0 .. 0 0 0 0 15 0
+ 225 3632 0 .. 0 0 0 0 8 0
+ 228 3680 0 .. 0 0 0 0 9 0
+ 230 3712 0 .. 0 0 0 0 10 0
+ 232 3744 0 .. 0 0 0 0 11 0
+ 234 3776 0 .. 0 0 0 0 12 0
+ 235 3792 0 .. 0 0 0 0 13 0
+ 236 3808 0 .. 0 0 0 0 14 0
+ 238 3840 0 .. 0 0 0 0 15 0
+ 254 4096 0 .. 0 0 0 0 1 0
+ ...
+
+Overall the combined zspage chain size effect on zsmalloc pool configuration:::
+
+ pages per zspage number of size classes (clusters) huge size class watermark
+ 4 69 3264
+ 5 86 3408
+ 6 93 3504
+ 7 112 3584
+ 8 123 3632
+ 9 140 3680
+ 10 143 3712
+ 11 159 3744
+ 12 164 3776
+ 13 180 3792
+ 14 183 3808
+ 15 188 3840
+ 16 191 3840
+
+
+A synthetic test
+----------------
+
+zram as a build artifacts storage (Linux kernel compilation).
+
+* `CONFIG_ZSMALLOC_CHAIN_SIZE=4`
+
+ zsmalloc classes stats:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ Total 13 .. 51 413836 412973 159955 3
+
+ zram mm_stat:::
+
+ 1691783168 628083717 655175680 0 655175680 60 0 34048 34049
+
+
+* `CONFIG_ZSMALLOC_CHAIN_SIZE=8`
+
+ zsmalloc classes stats:::
+
+ class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable
+
+ ...
+ Total 18 .. 87 414852 412978 156666 0
+
+ zram mm_stat:::
+
+ 1691803648 627793930 641703936 0 641703936 60 0 33591 33591
-We assign a zspage to ZS_ALMOST_EMPTY fullness group when n <= N / f, where
+Using larger zspage chains may result in using fewer physical pages, as seen
+in the example where the number of physical pages used decreased from 159955
+to 156666, at the same time maximum zsmalloc pool memory usage went down from
+655175680 to 641703936 bytes.
-* n = number of allocated objects
-* N = total number of objects zspage can store
-* f = fullness_threshold_frac(ie, 4 at the moment)
+However, this advantage may be offset by the potential for increased system
+memory pressure (as some zspages have larger chain sizes) in cases where there
+is heavy internal fragmentation and zspool compaction is unable to relocate
+objects and release zspages. In these cases, it is recommended to decrease
+the limit on the size of the zspage chains (as specified by the
+CONFIG_ZSMALLOC_CHAIN_SIZE option).
-Similarly, we assign zspage to:
+Functions
+=========
-* ZS_ALMOST_FULL when n > N / f
-* ZS_EMPTY when n == 0
-* ZS_FULL when n == N
+.. kernel-doc:: mm/zsmalloc.c
diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml
new file mode 100644
index 000000000000..57f59fe23e3f
--- /dev/null
+++ b/Documentation/netlink/genetlink-c.yaml
@@ -0,0 +1,406 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://kernel.org/schemas/netlink/genetlink-c.yaml#
+$schema: https://json-schema.org/draft-07/schema
+
+# Common defines
+$defs:
+ uint:
+ type: integer
+ minimum: 0
+ len-or-define:
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+( - 1)?$
+ minimum: 0
+ len-or-limit:
+ # literal int, const name, or limit based on fixed-width type
+ # e.g. u8-min, u16-max, etc.
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+$
+ minimum: 0
+
+# Schema for specs
+title: Protocol
+description: Specification of a genetlink protocol
+type: object
+required: [ name, doc, attribute-sets, operations ]
+additionalProperties: False
+properties:
+ name:
+ description: Name of the genetlink family.
+ type: string
+ doc:
+ type: string
+ protocol:
+ description: Schema compatibility level. Default is "genetlink".
+ enum: [ genetlink, genetlink-c ]
+ uapi-header:
+ description: Path to the uAPI header, default is linux/${family-name}.h
+ type: string
+ # Start genetlink-c
+ c-family-name:
+ description: Name of the define for the family name.
+ type: string
+ c-version-name:
+ description: Name of the define for the version of the family.
+ type: string
+ max-by-define:
+ description: Makes the number of attributes and commands be specified by a define, not an enum value.
+ type: boolean
+ cmd-max-name:
+ description: Name of the define for the last operation in the list.
+ type: string
+ cmd-cnt-name:
+ description: The explicit name for constant holding the count of operations (last operation + 1).
+ type: string
+ # End genetlink-c
+
+ definitions:
+ description: List of type and constant definitions (enums, flags, defines).
+ type: array
+ items:
+ type: object
+ required: [ type, name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ header:
+ description: For C-compatible languages, header which already defines this value.
+ type: string
+ type:
+ enum: [ const, enum, flags ]
+ doc:
+ type: string
+ # For const
+ value:
+ description: For const - the value.
+ type: [ string, integer ]
+ # For enum and flags
+ value-start:
+ description: For enum or flags the literal initializer for the first value.
+ type: [ string, integer ]
+ entries:
+ description: For enum or flags array of values.
+ type: array
+ items:
+ oneOf:
+ - type: string
+ - type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ value:
+ type: integer
+ doc:
+ type: string
+ render-max:
+ description: Render the max members for this enum.
+ type: boolean
+ # Start genetlink-c
+ enum-name:
+ description: Name for enum, if empty no name will be used.
+ type: [ string, "null" ]
+ name-prefix:
+ description: For enum the prefix of the values, optional.
+ type: string
+ enum-cnt-name:
+ description: Name of the render-max counter enum entry.
+ type: string
+ # End genetlink-c
+
+ attribute-sets:
+ description: Definition of attribute spaces for this family.
+ type: array
+ items:
+ description: Definition of a single attribute space.
+ type: object
+ required: [ name, attributes ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ Name used when referring to this space in other definitions, not used outside of the spec.
+ type: string
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the attributes. Default family[name]-set[name]-a-
+ type: string
+ enum-name:
+ description: |
+ Name for the enum type of the attribute, if empty no name will be used.
+ type: [ string, "null" ]
+ doc:
+ description: Documentation of the space.
+ type: string
+ subset-of:
+ description: |
+ Name of another space which this is a logical part of. Sub-spaces can be used to define
+ a limited group of attributes which are used in a nest.
+ type: string
+ # Start genetlink-c
+ attr-cnt-name:
+ description: The explicit name for constant holding the count of attributes (last attr + 1).
+ type: string
+ attr-max-name:
+ description: The explicit name for last member of attribute enum.
+ type: string
+ header:
+ description: For C-compatible languages, header which already defines this attribute set.
+ type: string
+ # End genetlink-c
+ attributes:
+ description: List of attributes in the space.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ type: string
+ type: &attr-type
+ enum: [ unused, pad, flag, binary,
+ uint, sint, u8, u16, u32, u64, s8, s16, s32, s64,
+ string, nest, indexed-array, nest-type-value ]
+ doc:
+ description: Documentation of the attribute.
+ type: string
+ value:
+ description: Value for the enum item representing this attribute in the uAPI.
+ $ref: '#/$defs/uint'
+ type-value:
+ description: Name of the value extracted from the type of a nest-type-value attribute.
+ type: array
+ items:
+ type: string
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ multi-attr:
+ type: boolean
+ nested-attributes:
+ description: Name of the space (sub-space) used inside the attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ checks:
+ description: Kernel input validation.
+ type: object
+ additionalProperties: False
+ properties:
+ flags-mask:
+ description: Name of the flags constant on which to base mask (unsigned scalar types only).
+ type: string
+ min:
+ description: Min value for an integer attribute.
+ $ref: '#/$defs/len-or-limit'
+ max:
+ description: Max value for an integer attribute.
+ $ref: '#/$defs/len-or-limit'
+ min-len:
+ description: Min length for a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ max-len:
+ description: Max length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ exact-len:
+ description: Exact length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ unterminated-ok:
+ description: |
+ For string attributes, do not check whether attribute
+ contains the terminating null character.
+ type: boolean
+ sub-type: *attr-type
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, ipv4-or-v6, uuid ]
+ # Start genetlink-c
+ name-prefix:
+ type: string
+ # End genetlink-c
+
+ # Make sure name-prefix does not appear in subsets (subsets inherit naming)
+ dependencies:
+ name-prefix:
+ not:
+ required: [ subset-of ]
+ subset-of:
+ not:
+ required: [ name-prefix ]
+
+ # type property is only required if not in subset definition
+ if:
+ properties:
+ subset-of:
+ not:
+ type: string
+ then:
+ properties:
+ attributes:
+ items:
+ required: [ type ]
+
+ operations:
+ description: Operations supported by the protocol.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ enum-model:
+ description: |
+ The model of assigning values to the operations.
+ "unified" is the recommended model where all message types belong
+ to a single enum.
+ "directional" has the messages sent to the kernel and from the kernel
+ enumerated separately.
+ enum: [ unified ]
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the command. The name is formed by concatenating
+ the prefix with the upper case name of the command, with dashes replaced by underscores.
+ type: string
+ enum-name:
+ description: |
+ Name for the enum type with commands, if empty no name will be used.
+ type: [ string, "null" ]
+ async-prefix:
+ description: Same as name-prefix but used to render notifications and events to separate enum.
+ type: string
+ async-enum:
+ description: |
+ Name for the enum type with commands, if empty no name will be used.
+ type: [ string, "null" ]
+ list:
+ description: List of commands
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, doc ]
+ properties:
+ name:
+ description: Name of the operation, also defining its C enum value in uAPI.
+ type: string
+ doc:
+ description: Documentation for the command.
+ type: string
+ value:
+ description: Value for the enum in the uAPI.
+ $ref: '#/$defs/uint'
+ attribute-set:
+ description: |
+ Attribute space from which attributes directly in the requests and replies
+ to this command are defined.
+ type: string
+ flags: &cmd_flags
+ description: Command flags.
+ type: array
+ items:
+ enum: [ admin-perm ]
+ dont-validate:
+ description: Kernel attribute validation flags.
+ type: array
+ items:
+ enum: [ strict, dump, dump-strict ]
+ config-cond:
+ description: |
+ Name of the kernel config option gating the presence of
+ the operation, without the 'CONFIG_' prefix.
+ type: string
+ do: &subop-type
+ description: Main command handler.
+ type: object
+ additionalProperties: False
+ properties:
+ request: &subop-attr-list
+ description: Definition of the request message for a given command.
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: |
+ Names of attributes from the attribute-set (not full attribute
+ definitions, just names).
+ type: array
+ items:
+ type: string
+ reply: *subop-attr-list
+ pre:
+ description: Hook for a function to run before the main callback (pre_doit or start).
+ type: string
+ post:
+ description: Hook for a function to run after the main callback (post_doit or done).
+ type: string
+ dump: *subop-type
+ notify:
+ description: Name of the command sharing the reply type with this notification.
+ type: string
+ event:
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: Explicit list of the attributes for the notification.
+ type: array
+ items:
+ type: string
+ mcgrp:
+ description: Name of the multicast group generating given notification.
+ type: string
+ mcast-groups:
+ description: List of multicast groups.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ list:
+ description: List of groups.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ The name for the group, used to form the define and the value of the define.
+ type: string
+ # Start genetlink-c
+ c-define-name:
+ description: Override for the name of the define in C uAPI.
+ type: string
+ # End genetlink-c
+ flags: *cmd_flags
+
+ kernel-family:
+ description: Additional global attributes used for kernel C code generation.
+ type: object
+ additionalProperties: False
+ properties:
+ headers:
+ description: |
+ List of extra headers which should be included in the source
+ of the generated code.
+ type: array
+ items:
+ type: string
+ sock-priv:
+ description: |
+ Literal name of the type which is used within the kernel
+ to store the socket state. The type / structure is internal
+ to the kernel, and is not defined in the spec.
+ type: string
diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml
new file mode 100644
index 000000000000..66fb8653a344
--- /dev/null
+++ b/Documentation/netlink/genetlink-legacy.yaml
@@ -0,0 +1,473 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://kernel.org/schemas/netlink/genetlink-legacy.yaml#
+$schema: https://json-schema.org/draft-07/schema
+
+# Common defines
+$defs:
+ name:
+ type: string
+ pattern: ^[0-9a-z-]+$
+ uint:
+ type: integer
+ minimum: 0
+ len-or-define:
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+( - 1)?$
+ minimum: 0
+ len-or-limit:
+ # literal int, const name, or limit based on fixed-width type
+ # e.g. u8-min, u16-max, etc.
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+$
+ minimum: 0
+
+# Schema for specs
+title: Protocol
+description: Specification of a genetlink protocol
+type: object
+required: [ name, doc, attribute-sets, operations ]
+additionalProperties: False
+properties:
+ name:
+ description: Name of the genetlink family.
+ type: string
+ doc:
+ type: string
+ protocol:
+ description: Schema compatibility level. Default is "genetlink".
+ enum: [ genetlink, genetlink-c, genetlink-legacy ] # Trim
+ uapi-header:
+ description: Path to the uAPI header, default is linux/${family-name}.h
+ type: string
+ # Start genetlink-c
+ c-family-name:
+ description: Name of the define for the family name.
+ type: string
+ c-version-name:
+ description: Name of the define for the version of the family.
+ type: string
+ max-by-define:
+ description: Makes the number of attributes and commands be specified by a define, not an enum value.
+ type: boolean
+ cmd-max-name:
+ description: Name of the define for the last operation in the list.
+ type: string
+ cmd-cnt-name:
+ description: The explicit name for constant holding the count of operations (last operation + 1).
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ kernel-policy:
+ description: |
+ Defines if the input policy in the kernel is global, per-operation, or split per operation type.
+ Default is split.
+ enum: [ split, per-op, global ]
+ version:
+ description: Generic Netlink family version. Default is 1.
+ type: integer
+ minimum: 1
+ # End genetlink-legacy
+
+ definitions:
+ description: List of type and constant definitions (enums, flags, defines).
+ type: array
+ items:
+ type: object
+ required: [ type, name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ header:
+ description: For C-compatible languages, header which already defines this value.
+ type: string
+ type:
+ enum: [ const, enum, flags, struct ] # Trim
+ doc:
+ type: string
+ # For const
+ value:
+ description: For const - the value.
+ type: [ string, integer ]
+ # For enum and flags
+ value-start:
+ description: For enum or flags the literal initializer for the first value.
+ type: [ string, integer ]
+ entries:
+ description: For enum or flags array of values.
+ type: array
+ items:
+ oneOf:
+ - type: string
+ - type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ value:
+ type: integer
+ doc:
+ type: string
+ render-max:
+ description: Render the max members for this enum.
+ type: boolean
+ # Start genetlink-c
+ enum-name:
+ description: Name for enum, if empty no name will be used.
+ type: [ string, "null" ]
+ name-prefix:
+ description: For enum the prefix of the values, optional.
+ type: string
+ enum-cnt-name:
+ description: Name of the render-max counter enum entry.
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ members:
+ description: List of struct members. Only scalars and strings members allowed.
+ type: array
+ items:
+ type: object
+ required: [ name, type ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ type:
+ description: The netlink attribute type
+ enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string, binary ]
+ len:
+ $ref: '#/$defs/len-or-define'
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ doc:
+ description: Documentation for the struct member attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, ipv4-or-v6, uuid ]
+ struct:
+ description: Name of the nested struct type.
+ type: string
+ # End genetlink-legacy
+
+ attribute-sets:
+ description: Definition of attribute spaces for this family.
+ type: array
+ items:
+ description: Definition of a single attribute space.
+ type: object
+ required: [ name, attributes ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ Name used when referring to this space in other definitions, not used outside of the spec.
+ $ref: '#/$defs/name'
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the attributes. Default family[name]-set[name]-a-
+ type: string
+ enum-name:
+ description: |
+ Name for the enum type of the attribute, if empty no name will be used.
+ type: [ string, "null" ]
+ doc:
+ description: Documentation of the space.
+ type: string
+ subset-of:
+ description: |
+ Name of another space which this is a logical part of. Sub-spaces can be used to define
+ a limited group of attributes which are used in a nest.
+ type: string
+ # Start genetlink-c
+ attr-cnt-name:
+ description: The explicit name for constant holding the count of attributes (last attr + 1).
+ type: string
+ attr-max-name:
+ description: The explicit name for last member of attribute enum.
+ type: string
+ header:
+ description: For C-compatible languages, header which already defines this attribute set.
+ type: string
+ # End genetlink-c
+ attributes:
+ description: List of attributes in the space.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ type: &attr-type
+ description: The netlink attribute type
+ enum: [ unused, pad, flag, binary, bitfield32,
+ uint, sint, u8, u16, u32, u64, s8, s16, s32, s64,
+ string, nest, indexed-array, nest-type-value ]
+ doc:
+ description: Documentation of the attribute.
+ type: string
+ value:
+ description: Value for the enum item representing this attribute in the uAPI.
+ $ref: '#/$defs/uint'
+ type-value:
+ description: Name of the value extracted from the type of a nest-type-value attribute.
+ type: array
+ items:
+ type: string
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ multi-attr:
+ type: boolean
+ nested-attributes:
+ description: Name of the space (sub-space) used inside the attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ checks:
+ description: Kernel input validation.
+ type: object
+ additionalProperties: False
+ properties:
+ flags-mask:
+ description: Name of the flags constant on which to base mask (unsigned scalar types only).
+ type: string
+ min:
+ description: Min value for an integer attribute.
+ $ref: '#/$defs/len-or-limit'
+ max:
+ description: Max value for an integer attribute.
+ $ref: '#/$defs/len-or-limit'
+ min-len:
+ description: Min length for a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ max-len:
+ description: Max length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ exact-len:
+ description: Exact length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ unterminated-ok:
+ description: |
+ For string attributes, do not check whether attribute
+ contains the terminating null character.
+ type: boolean
+ sub-type: *attr-type
+ display-hint: *display-hint
+ # Start genetlink-c
+ name-prefix:
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ struct:
+ description: Name of the struct type used for the attribute.
+ type: string
+ # End genetlink-legacy
+
+ # Make sure name-prefix does not appear in subsets (subsets inherit naming)
+ dependencies:
+ name-prefix:
+ not:
+ required: [ subset-of ]
+ subset-of:
+ not:
+ required: [ name-prefix ]
+
+ # type property is only required if not in subset definition
+ if:
+ properties:
+ subset-of:
+ not:
+ type: string
+ then:
+ properties:
+ attributes:
+ items:
+ required: [ type ]
+
+ operations:
+ description: Operations supported by the protocol.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ enum-model:
+ description: |
+ The model of assigning values to the operations.
+ "unified" is the recommended model where all message types belong
+ to a single enum.
+ "directional" has the messages sent to the kernel and from the kernel
+ enumerated separately.
+ enum: [ unified, directional ] # Trim
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the command. The name is formed by concatenating
+ the prefix with the upper case name of the command, with dashes replaced by underscores.
+ type: string
+ enum-name:
+ description: |
+ Name for the enum type with commands, if empty no name will be used.
+ type: [ string, "null" ]
+ async-prefix:
+ description: Same as name-prefix but used to render notifications and events to separate enum.
+ type: string
+ async-enum:
+ description: |
+ Name for the enum type with commands, if empty no name will be used.
+ type: [ string, "null" ]
+ # Start genetlink-legacy
+ fixed-header: &fixed-header
+ description: |
+ Name of the structure defining the optional fixed-length protocol
+ header. This header is placed in a message after the netlink and
+ genetlink headers and before any attributes.
+ type: string
+ # End genetlink-legacy
+ list:
+ description: List of commands
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, doc ]
+ properties:
+ name:
+ description: Name of the operation, also defining its C enum value in uAPI.
+ $ref: '#/$defs/name'
+ doc:
+ description: Documentation for the command.
+ type: string
+ value:
+ description: Value for the enum in the uAPI.
+ $ref: '#/$defs/uint'
+ attribute-set:
+ description: |
+ Attribute space from which attributes directly in the requests and replies
+ to this command are defined.
+ type: string
+ flags: &cmd_flags
+ description: Command flags.
+ type: array
+ items:
+ enum: [ admin-perm, uns-admin-perm ]
+ dont-validate:
+ description: Kernel attribute validation flags.
+ type: array
+ items:
+ enum: [ strict, dump, dump-strict ]
+ config-cond:
+ description: |
+ Name of the kernel config option gating the presence of
+ the operation, without the 'CONFIG_' prefix.
+ type: string
+ # Start genetlink-legacy
+ fixed-header: *fixed-header
+ # End genetlink-legacy
+ do: &subop-type
+ description: Main command handler.
+ type: object
+ additionalProperties: False
+ properties:
+ request: &subop-attr-list
+ description: Definition of the request message for a given command.
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: |
+ Names of attributes from the attribute-set (not full attribute
+ definitions, just names).
+ type: array
+ items:
+ type: string
+ # Start genetlink-legacy
+ value:
+ description: |
+ ID of this message if value for request and response differ,
+ i.e. requests and responses have different message enums.
+ $ref: '#/$defs/uint'
+ # End genetlink-legacy
+ reply: *subop-attr-list
+ pre:
+ description: Hook for a function to run before the main callback (pre_doit or start).
+ type: string
+ post:
+ description: Hook for a function to run after the main callback (post_doit or done).
+ type: string
+ dump: *subop-type
+ notify:
+ description: Name of the command sharing the reply type with this notification.
+ type: string
+ event:
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: Explicit list of the attributes for the notification.
+ type: array
+ items:
+ type: string
+ mcgrp:
+ description: Name of the multicast group generating given notification.
+ type: string
+ mcast-groups:
+ description: List of multicast groups.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ list:
+ description: List of groups.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ The name for the group, used to form the define and the value of the define.
+ type: string
+ # Start genetlink-c
+ c-define-name:
+ description: Override for the name of the define in C uAPI.
+ type: string
+ # End genetlink-c
+ flags: *cmd_flags
+
+ kernel-family:
+ description: Additional global attributes used for kernel C code generation.
+ type: object
+ additionalProperties: False
+ properties:
+ headers:
+ description: |
+ List of extra headers which should be included in the source
+ of the generated code.
+ type: array
+ items:
+ type: string
+ sock-priv:
+ description: |
+ Literal name of the type which is used within the kernel
+ to store the socket state. The type / structure is internal
+ to the kernel, and is not defined in the spec.
+ type: string
diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml
new file mode 100644
index 000000000000..b020a537d8ac
--- /dev/null
+++ b/Documentation/netlink/genetlink.yaml
@@ -0,0 +1,353 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://kernel.org/schemas/netlink/genetlink-legacy.yaml#
+$schema: https://json-schema.org/draft-07/schema
+
+# Common defines
+$defs:
+ name:
+ type: string
+ pattern: ^[0-9a-z-]+$
+ uint:
+ type: integer
+ minimum: 0
+ len-or-define:
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+( - 1)?$
+ minimum: 0
+ len-or-limit:
+ # literal int, const name, or limit based on fixed-width type
+ # e.g. u8-min, u16-max, etc.
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+$
+ minimum: 0
+
+# Schema for specs
+title: Protocol
+description: Specification of a genetlink protocol
+type: object
+required: [ name, doc, attribute-sets, operations ]
+additionalProperties: False
+properties:
+ name:
+ description: Name of the genetlink family.
+ $ref: '#/$defs/name'
+ doc:
+ type: string
+ protocol:
+ description: Schema compatibility level. Default is "genetlink".
+ enum: [ genetlink ]
+ uapi-header:
+ description: Path to the uAPI header, default is linux/${family-name}.h
+ type: string
+
+ definitions:
+ description: List of type and constant definitions (enums, flags, defines).
+ type: array
+ items:
+ type: object
+ required: [ type, name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ header:
+ description: For C-compatible languages, header which already defines this value.
+ type: string
+ type:
+ enum: [ const, enum, flags ]
+ doc:
+ type: string
+ # For const
+ value:
+ description: For const - the value.
+ type: [ string, integer ]
+ # For enum and flags
+ value-start:
+ description: For enum or flags the literal initializer for the first value.
+ type: [ string, integer ]
+ entries:
+ description: For enum or flags array of values.
+ type: array
+ items:
+ oneOf:
+ - type: string
+ - type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ value:
+ type: integer
+ doc:
+ type: string
+ render-max:
+ description: Render the max members for this enum.
+ type: boolean
+
+ attribute-sets:
+ description: Definition of attribute spaces for this family.
+ type: array
+ items:
+ description: Definition of a single attribute space.
+ type: object
+ required: [ name, attributes ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ Name used when referring to this space in other definitions, not used outside of the spec.
+ $ref: '#/$defs/name'
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the attributes. Default family[name]-set[name]-a-
+ type: string
+ enum-name:
+ description: Name for the enum type of the attribute.
+ type: string
+ doc:
+ description: Documentation of the space.
+ type: string
+ subset-of:
+ description: |
+ Name of another space which this is a logical part of. Sub-spaces can be used to define
+ a limited group of attributes which are used in a nest.
+ type: string
+ attributes:
+ description: List of attributes in the space.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ type: &attr-type
+ enum: [ unused, pad, flag, binary,
+ uint, sint, u8, u16, u32, u64, s8, s16, s32, s64,
+ string, nest, indexed-array, nest-type-value ]
+ doc:
+ description: Documentation of the attribute.
+ type: string
+ value:
+ description: Value for the enum item representing this attribute in the uAPI.
+ $ref: '#/$defs/uint'
+ type-value:
+ description: Name of the value extracted from the type of a nest-type-value attribute.
+ type: array
+ items:
+ type: string
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ multi-attr:
+ type: boolean
+ nested-attributes:
+ description: Name of the space (sub-space) used inside the attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ checks:
+ description: Kernel input validation.
+ type: object
+ additionalProperties: False
+ properties:
+ flags-mask:
+ description: Name of the flags constant on which to base mask (unsigned scalar types only).
+ type: string
+ min:
+ description: Min value for an integer attribute.
+ $ref: '#/$defs/len-or-limit'
+ max:
+ description: Max value for an integer attribute.
+ $ref: '#/$defs/len-or-limit'
+ min-len:
+ description: Min length for a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ max-len:
+ description: Max length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ exact-len:
+ description: Exact length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ sub-type: *attr-type
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, ipv4-or-v6, uuid ]
+
+ # Make sure name-prefix does not appear in subsets (subsets inherit naming)
+ dependencies:
+ name-prefix:
+ not:
+ required: [ subset-of ]
+ subset-of:
+ not:
+ required: [ name-prefix ]
+
+ # type property is only required if not in subset definition
+ if:
+ properties:
+ subset-of:
+ not:
+ type: string
+ then:
+ properties:
+ attributes:
+ items:
+ required: [ type ]
+
+ operations:
+ description: Operations supported by the protocol.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ enum-model:
+ description: |
+ The model of assigning values to the operations.
+ "unified" is the recommended model where all message types belong
+ to a single enum.
+ "directional" has the messages sent to the kernel and from the kernel
+ enumerated separately.
+ enum: [ unified ]
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the command. The name is formed by concatenating
+ the prefix with the upper case name of the command, with dashes replaced by underscores.
+ type: string
+ enum-name:
+ description: Name for the enum type with commands.
+ type: string
+ async-prefix:
+ description: Same as name-prefix but used to render notifications and events to separate enum.
+ type: string
+ async-enum:
+ description: Name for the enum type with notifications/events.
+ type: string
+ list:
+ description: List of commands
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, doc ]
+ properties:
+ name:
+ description: Name of the operation, also defining its C enum value in uAPI.
+ $ref: '#/$defs/name'
+ doc:
+ description: Documentation for the command.
+ type: string
+ value:
+ description: Value for the enum in the uAPI.
+ $ref: '#/$defs/uint'
+ attribute-set:
+ description: |
+ Attribute space from which attributes directly in the requests and replies
+ to this command are defined.
+ type: string
+ flags: &cmd_flags
+ description: Command flags.
+ type: array
+ items:
+ enum: [ admin-perm ]
+ dont-validate:
+ description: Kernel attribute validation flags.
+ type: array
+ items:
+ enum: [ strict, dump, dump-strict ]
+ config-cond:
+ description: |
+ Name of the kernel config option gating the presence of
+ the operation, without the 'CONFIG_' prefix.
+ type: string
+ do: &subop-type
+ description: Main command handler.
+ type: object
+ additionalProperties: False
+ properties:
+ request: &subop-attr-list
+ description: Definition of the request message for a given command.
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: |
+ Names of attributes from the attribute-set (not full attribute
+ definitions, just names).
+ type: array
+ items:
+ type: string
+ reply: *subop-attr-list
+ pre:
+ description: Hook for a function to run before the main callback (pre_doit or start).
+ type: string
+ post:
+ description: Hook for a function to run after the main callback (post_doit or done).
+ type: string
+ dump: *subop-type
+ notify:
+ description: Name of the command sharing the reply type with this notification.
+ type: string
+ event:
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: Explicit list of the attributes for the notification.
+ type: array
+ items:
+ type: string
+ mcgrp:
+ description: Name of the multicast group generating given notification.
+ type: string
+ mcast-groups:
+ description: List of multicast groups.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ list:
+ description: List of groups.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ The name for the group, used to form the define and the value of the define.
+ $ref: '#/$defs/name'
+ flags: *cmd_flags
+
+ kernel-family:
+ description: Additional global attributes used for kernel C code generation.
+ type: object
+ additionalProperties: False
+ properties:
+ headers:
+ description: |
+ List of extra headers which should be included in the source
+ of the generated code.
+ type: array
+ items:
+ type: string
+ sock-priv:
+ description: |
+ Literal name of the type which is used within the kernel
+ to store the socket state. The type / structure is internal
+ to the kernel, and is not defined in the spec.
+ type: string
diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml
new file mode 100644
index 000000000000..0166a7e4afbb
--- /dev/null
+++ b/Documentation/netlink/netlink-raw.yaml
@@ -0,0 +1,517 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://kernel.org/schemas/netlink/netlink-raw.yaml#
+$schema: https://json-schema.org/draft-07/schema
+
+# Common defines
+$defs:
+ name:
+ type: string
+ pattern: ^[0-9a-z-]+$
+ name-cap:
+ type: string
+ pattern: ^[0-9a-zA-Z-]+$
+ uint:
+ type: integer
+ minimum: 0
+ len-or-define:
+ type: [ string, integer ]
+ pattern: ^[0-9A-Za-z_-]+( - 1)?$
+ minimum: 0
+
+# Schema for specs
+title: Protocol
+description: Specification of a raw netlink protocol
+type: object
+required: [ name, doc, attribute-sets, operations ]
+additionalProperties: False
+properties:
+ name:
+ description: Name of the netlink family.
+ type: string
+ doc:
+ type: string
+ protocol:
+ description: Schema compatibility level.
+ enum: [ netlink-raw ] # Trim
+ # Start netlink-raw
+ protonum:
+ description: Protocol number to use for netlink-raw
+ type: integer
+ # End netlink-raw
+ uapi-header:
+ description: Path to the uAPI header, default is linux/${family-name}.h
+ type: string
+ # Start genetlink-c
+ c-family-name:
+ description: Name of the define for the family name.
+ type: string
+ c-version-name:
+ description: Name of the define for the version of the family.
+ type: string
+ max-by-define:
+ description: Makes the number of attributes and commands be specified by a define, not an enum value.
+ type: boolean
+ cmd-max-name:
+ description: Name of the define for the last operation in the list.
+ type: string
+ cmd-cnt-name:
+ description: The explicit name for constant holding the count of operations (last operation + 1).
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ kernel-policy:
+ description: |
+ Defines if the input policy in the kernel is global, per-operation, or split per operation type.
+ Default is split.
+ enum: [ split, per-op, global ]
+ # End genetlink-legacy
+
+ definitions:
+ description: List of type and constant definitions (enums, flags, defines).
+ type: array
+ items:
+ type: object
+ required: [ type, name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ header:
+ description: For C-compatible languages, header which already defines this value.
+ type: string
+ type:
+ enum: [ const, enum, flags, struct ] # Trim
+ doc:
+ type: string
+ # For const
+ value:
+ description: For const - the value.
+ type: [ string, integer ]
+ # For enum and flags
+ value-start:
+ description: For enum or flags the literal initializer for the first value.
+ type: [ string, integer ]
+ entries:
+ description: For enum or flags array of values.
+ type: array
+ items:
+ oneOf:
+ - type: string
+ - type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ value:
+ type: integer
+ doc:
+ type: string
+ render-max:
+ description: Render the max members for this enum.
+ type: boolean
+ # Start genetlink-c
+ enum-name:
+ description: Name for enum, if empty no name will be used.
+ type: [ string, "null" ]
+ name-prefix:
+ description: For enum the prefix of the values, optional.
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ members:
+ description: List of struct members. Only scalars and strings members allowed.
+ type: array
+ items:
+ type: object
+ required: [ name, type ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name-cap'
+ type:
+ description: |
+ The netlink attribute type. Members of type 'binary' or 'pad'
+ must also have the 'len' property set.
+ enum: [ u8, u16, u32, u64, s8, s16, s32, s64, string, binary, pad ]
+ len:
+ $ref: '#/$defs/len-or-define'
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ doc:
+ description: Documentation for the struct member attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ display-hint: &display-hint
+ description: |
+ Optional format indicator that is intended only for choosing
+ the right formatting mechanism when displaying values of this
+ type.
+ enum: [ hex, mac, fddi, ipv4, ipv6, ipv4-or-v6, uuid ]
+ struct:
+ description: Name of the nested struct type.
+ type: string
+ if:
+ properties:
+ type:
+ const: pad
+ then:
+ required: [ len ]
+ if:
+ properties:
+ type:
+ const: binary
+ then:
+ oneOf:
+ - required: [ len ]
+ - required: [ struct ]
+ # End genetlink-legacy
+
+ attribute-sets:
+ description: Definition of attribute spaces for this family.
+ type: array
+ items:
+ description: Definition of a single attribute space.
+ type: object
+ required: [ name, attributes ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ Name used when referring to this space in other definitions, not used outside of the spec.
+ $ref: '#/$defs/name'
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the attributes. Default family[name]-set[name]-a-
+ type: string
+ enum-name:
+ description: |
+ Name for the enum type of the attribute, if empty no name will be used.
+ type: [ string, "null" ]
+ doc:
+ description: Documentation of the space.
+ type: string
+ subset-of:
+ description: |
+ Name of another space which this is a logical part of. Sub-spaces can be used to define
+ a limited group of attributes which are used in a nest.
+ type: string
+ # Start genetlink-c
+ attr-cnt-name:
+ description: The explicit name for constant holding the count of attributes (last attr + 1).
+ type: string
+ attr-max-name:
+ description: The explicit name for last member of attribute enum.
+ type: string
+ header:
+ description: For C-compatible languages, header which already defines this attribute set.
+ type: string
+ # End genetlink-c
+ attributes:
+ description: List of attributes in the space.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ $ref: '#/$defs/name'
+ type: &attr-type
+ description: The netlink attribute type
+ enum: [ unused, pad, flag, binary, bitfield32,
+ uint, sint, u8, u16, u32, u64, s8, s16, s32, s64,
+ string, nest, indexed-array, nest-type-value,
+ sub-message ]
+ doc:
+ description: Documentation of the attribute.
+ type: string
+ value:
+ description: Value for the enum item representing this attribute in the uAPI.
+ $ref: '#/$defs/uint'
+ type-value:
+ description: Name of the value extracted from the type of a nest-type-value attribute.
+ type: array
+ items:
+ type: string
+ byte-order:
+ enum: [ little-endian, big-endian ]
+ multi-attr:
+ type: boolean
+ nested-attributes:
+ description: Name of the space (sub-space) used inside the attribute.
+ type: string
+ enum:
+ description: Name of the enum type used for the attribute.
+ type: string
+ enum-as-flags:
+ description: |
+ Treat the enum as flags. In most cases enum is either used as flags or as values.
+ Sometimes, however, both forms are necessary, in which case header contains the enum
+ form while specific attributes may request to convert the values into a bitfield.
+ type: boolean
+ checks:
+ description: Kernel input validation.
+ type: object
+ additionalProperties: False
+ properties:
+ flags-mask:
+ description: Name of the flags constant on which to base mask (unsigned scalar types only).
+ type: string
+ min:
+ description: Min value for an integer attribute.
+ type: integer
+ min-len:
+ description: Min length for a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ max-len:
+ description: Max length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ exact-len:
+ description: Exact length for a string or a binary attribute.
+ $ref: '#/$defs/len-or-define'
+ unterminated-ok:
+ description: |
+ For string attributes, do not check whether attribute
+ contains the terminating null character.
+ type: boolean
+ sub-type: *attr-type
+ display-hint: *display-hint
+ # Start genetlink-c
+ name-prefix:
+ type: string
+ # End genetlink-c
+ # Start genetlink-legacy
+ struct:
+ description: Name of the struct type used for the attribute.
+ type: string
+ # End genetlink-legacy
+ # Start netlink-raw
+ sub-message:
+ description: |
+ Name of the sub-message definition to use for the attribute.
+ type: string
+ selector:
+ description: |
+ Name of the attribute to use for dynamic selection of sub-message
+ format specifier.
+ type: string
+ # End netlink-raw
+
+ # Make sure name-prefix does not appear in subsets (subsets inherit naming)
+ dependencies:
+ name-prefix:
+ not:
+ required: [ subset-of ]
+ subset-of:
+ not:
+ required: [ name-prefix ]
+
+ # type property is only required if not in subset definition
+ if:
+ properties:
+ subset-of:
+ not:
+ type: string
+ then:
+ properties:
+ attributes:
+ items:
+ required: [ type ]
+
+ # Start netlink-raw
+ sub-messages:
+ description: Definition of sub message attributes
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, formats ]
+ properties:
+ name:
+ description: Name of the sub-message definition
+ type: string
+ formats:
+ description: Dynamically selected format specifiers
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ value ]
+ properties:
+ value:
+ description: |
+ Value to match for dynamic selection of sub-message format
+ specifier.
+ type: string
+ fixed-header:
+ description: |
+ Name of the struct definition to use as the fixed header
+ for the sub message.
+ type: string
+ attribute-set:
+ description: |
+ Name of the attribute space from which to resolve attributes
+ in the sub message.
+ type: string
+ # End netlink-raw
+
+ operations:
+ description: Operations supported by the protocol.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ enum-model:
+ description: |
+ The model of assigning values to the operations.
+ "unified" is the recommended model where all message types belong
+ to a single enum.
+ "directional" has the messages sent to the kernel and from the kernel
+ enumerated separately.
+ enum: [ unified, directional ] # Trim
+ name-prefix:
+ description: |
+ Prefix for the C enum name of the command. The name is formed by concatenating
+ the prefix with the upper case name of the command, with dashes replaced by underscores.
+ type: string
+ enum-name:
+ description: |
+ Name for the enum type with commands, if empty no name will be used.
+ type: [ string, "null" ]
+ async-prefix:
+ description: Same as name-prefix but used to render notifications and events to separate enum.
+ type: string
+ async-enum:
+ description: |
+ Name for the enum type with commands, if empty no name will be used.
+ type: [ string, "null" ]
+ # Start genetlink-legacy
+ fixed-header: &fixed-header
+ description: |
+ Name of the structure defining the optional fixed-length protocol
+ header. This header is placed in a message after the netlink and
+ genetlink headers and before any attributes.
+ type: string
+ # End genetlink-legacy
+ list:
+ description: List of commands
+ type: array
+ items:
+ type: object
+ additionalProperties: False
+ required: [ name, doc ]
+ properties:
+ name:
+ description: Name of the operation, also defining its C enum value in uAPI.
+ $ref: '#/$defs/name'
+ doc:
+ description: Documentation for the command.
+ type: string
+ value:
+ description: Value for the enum in the uAPI.
+ $ref: '#/$defs/uint'
+ attribute-set:
+ description: |
+ Attribute space from which attributes directly in the requests and replies
+ to this command are defined.
+ type: string
+ flags: &cmd_flags
+ description: Command flags.
+ type: array
+ items:
+ enum: [ admin-perm ]
+ dont-validate:
+ description: Kernel attribute validation flags.
+ type: array
+ items:
+ enum: [ strict, dump ]
+ # Start genetlink-legacy
+ fixed-header: *fixed-header
+ # End genetlink-legacy
+ do: &subop-type
+ description: Main command handler.
+ type: object
+ additionalProperties: False
+ properties:
+ request: &subop-attr-list
+ description: Definition of the request message for a given command.
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: |
+ Names of attributes from the attribute-set (not full attribute
+ definitions, just names).
+ type: array
+ items:
+ type: string
+ # Start genetlink-legacy
+ value:
+ description: |
+ ID of this message if value for request and response differ,
+ i.e. requests and responses have different message enums.
+ $ref: '#/$defs/uint'
+ # End genetlink-legacy
+ reply: *subop-attr-list
+ pre:
+ description: Hook for a function to run before the main callback (pre_doit or start).
+ type: string
+ post:
+ description: Hook for a function to run after the main callback (post_doit or done).
+ type: string
+ dump: *subop-type
+ notify:
+ description: Name of the command sharing the reply type with this notification.
+ type: string
+ event:
+ type: object
+ additionalProperties: False
+ properties:
+ attributes:
+ description: Explicit list of the attributes for the notification.
+ type: array
+ items:
+ type: string
+ mcgrp:
+ description: Name of the multicast group generating given notification.
+ type: string
+ mcast-groups:
+ description: List of multicast groups.
+ type: object
+ required: [ list ]
+ additionalProperties: False
+ properties:
+ list:
+ description: List of groups.
+ type: array
+ items:
+ type: object
+ required: [ name ]
+ additionalProperties: False
+ properties:
+ name:
+ description: |
+ The name for the group, used to form the define and the value of the define.
+ type: string
+ # Start genetlink-c
+ c-define-name:
+ description: Override for the name of the define in C uAPI.
+ type: string
+ # End genetlink-c
+ flags: *cmd_flags
+ # Start netlink-raw
+ value:
+ description: Value of the netlink multicast group in the uAPI.
+ type: integer
+ # End netlink-raw
diff --git a/Documentation/netlink/specs/binder.yaml b/Documentation/netlink/specs/binder.yaml
new file mode 100644
index 000000000000..0f0575ad1265
--- /dev/null
+++ b/Documentation/netlink/specs/binder.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+#
+# Copyright 2025 Google LLC
+#
+---
+name: binder
+protocol: genetlink
+uapi-header: linux/android/binder_netlink.h
+doc: Binder interface over generic netlink
+
+attribute-sets:
+ -
+ name: report
+ doc: |
+ Attributes included within a transaction failure report. The elements
+ correspond directly with the specific transaction that failed, along
+ with the error returned to the sender e.g. BR_DEAD_REPLY.
+
+ attributes:
+ -
+ name: error
+ type: u32
+ doc: The enum binder_driver_return_protocol returned to the sender.
+ -
+ name: context
+ type: string
+ doc: The binder context where the transaction occurred.
+ -
+ name: from-pid
+ type: u32
+ doc: The PID of the sender process.
+ -
+ name: from-tid
+ type: u32
+ doc: The TID of the sender thread.
+ -
+ name: to-pid
+ type: u32
+ doc: |
+ The PID of the recipient process. This attribute may not be present
+ if the target could not be determined.
+ -
+ name: to-tid
+ type: u32
+ doc: |
+ The TID of the recipient thread. This attribute may not be present
+ if the target could not be determined.
+ -
+ name: is-reply
+ type: flag
+ doc: When present, indicates the failed transaction is a reply.
+ -
+ name: flags
+ type: u32
+ doc: The bitmask of enum transaction_flags from the transaction.
+ -
+ name: code
+ type: u32
+ doc: The application-defined code from the transaction.
+ -
+ name: data-size
+ type: u32
+ doc: The transaction payload size in bytes.
+
+operations:
+ list:
+ -
+ name: report
+ doc: |
+ A multicast event sent to userspace subscribers to notify them about
+ binder transaction failures. The generated report provides the full
+ details of the specific transaction that failed. The intention is for
+ programs to monitor these events and react to the failures as needed.
+
+ attribute-set: report
+ mcgrp: report
+ event:
+ attributes:
+ - error
+ - context
+ - from-pid
+ - from-tid
+ - to-pid
+ - to-tid
+ - is-reply
+ - flags
+ - code
+ - data-size
+
+mcast-groups:
+ list:
+ -
+ name: report
diff --git a/Documentation/netlink/specs/conntrack.yaml b/Documentation/netlink/specs/conntrack.yaml
new file mode 100644
index 000000000000..db7cddcda50a
--- /dev/null
+++ b/Documentation/netlink/specs/conntrack.yaml
@@ -0,0 +1,642 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+---
+name: conntrack
+protocol: netlink-raw
+protonum: 12
+
+doc: >-
+ Netfilter connection tracking subsystem over nfnetlink
+
+definitions:
+ -
+ name: nfgenmsg
+ type: struct
+ members:
+ -
+ name: nfgen-family
+ type: u8
+ -
+ name: version
+ type: u8
+ -
+ name: res-id
+ byte-order: big-endian
+ type: u16
+ -
+ name: nf-ct-tcp-flags-mask
+ type: struct
+ members:
+ -
+ name: flags
+ type: u8
+ enum: nf-ct-tcp-flags
+ enum-as-flags: true
+ -
+ name: mask
+ type: u8
+ enum: nf-ct-tcp-flags
+ enum-as-flags: true
+ -
+ name: nf-ct-tcp-flags
+ type: flags
+ entries:
+ - window-scale
+ - sack-perm
+ - close-init
+ - be-liberal
+ - unacked
+ - maxack
+ - challenge-ack
+ - simultaneous-open
+ -
+ name: nf-ct-tcp-state
+ type: enum
+ entries:
+ - none
+ - syn-sent
+ - syn-recv
+ - established
+ - fin-wait
+ - close-wait
+ - last-ack
+ - time-wait
+ - close
+ - syn-sent2
+ - max
+ - ignore
+ - retrans
+ - unack
+ - timeout-max
+ -
+ name: nf-ct-sctp-state
+ type: enum
+ entries:
+ - none
+ - cloned
+ - cookie-wait
+ - cookie-echoed
+ - established
+ - shutdown-sent
+ - shutdown-received
+ - shutdown-ack-sent
+ - shutdown-heartbeat-sent
+ -
+ name: nf-ct-status
+ type: flags
+ entries:
+ - expected
+ - seen-reply
+ - assured
+ - confirmed
+ - src-nat
+ - dst-nat
+ - seq-adj
+ - src-nat-done
+ - dst-nat-done
+ - dying
+ - fixed-timeout
+ - template
+ - nat-clash
+ - helper
+ - offload
+ - hw-offload
+
+attribute-sets:
+ -
+ name: counter-attrs
+ attributes:
+ -
+ name: packets
+ type: u64
+ byte-order: big-endian
+ -
+ name: bytes
+ type: u64
+ byte-order: big-endian
+ -
+ name: packets-old
+ type: u32
+ -
+ name: bytes-old
+ type: u32
+ -
+ name: pad
+ type: pad
+ -
+ name: tuple-proto-attrs
+ attributes:
+ -
+ name: proto-num
+ type: u8
+ doc: l4 protocol number
+ -
+ name: proto-src-port
+ type: u16
+ byte-order: big-endian
+ doc: l4 source port
+ -
+ name: proto-dst-port
+ type: u16
+ byte-order: big-endian
+ doc: l4 source port
+ -
+ name: proto-icmp-id
+ type: u16
+ byte-order: big-endian
+ doc: l4 icmp id
+ -
+ name: proto-icmp-type
+ type: u8
+ -
+ name: proto-icmp-code
+ type: u8
+ -
+ name: proto-icmpv6-id
+ type: u16
+ byte-order: big-endian
+ doc: l4 icmp id
+ -
+ name: proto-icmpv6-type
+ type: u8
+ -
+ name: proto-icmpv6-code
+ type: u8
+ -
+ name: tuple-ip-attrs
+ attributes:
+ -
+ name: ip-v4-src
+ type: u32
+ byte-order: big-endian
+ display-hint: ipv4
+ doc: ipv4 source address
+ -
+ name: ip-v4-dst
+ type: u32
+ byte-order: big-endian
+ display-hint: ipv4
+ doc: ipv4 destination address
+ -
+ name: ip-v6-src
+ type: binary
+ checks:
+ min-len: 16
+ byte-order: big-endian
+ display-hint: ipv6
+ doc: ipv6 source address
+ -
+ name: ip-v6-dst
+ type: binary
+ checks:
+ min-len: 16
+ byte-order: big-endian
+ display-hint: ipv6
+ doc: ipv6 destination address
+ -
+ name: tuple-attrs
+ attributes:
+ -
+ name: tuple-ip
+ type: nest
+ nested-attributes: tuple-ip-attrs
+ doc: conntrack l3 information
+ -
+ name: tuple-proto
+ type: nest
+ nested-attributes: tuple-proto-attrs
+ doc: conntrack l4 information
+ -
+ name: tuple-zone
+ type: u16
+ byte-order: big-endian
+ doc: conntrack zone id
+ -
+ name: protoinfo-tcp-attrs
+ attributes:
+ -
+ name: tcp-state
+ type: u8
+ enum: nf-ct-tcp-state
+ doc: tcp connection state
+ -
+ name: tcp-wscale-original
+ type: u8
+ doc: window scaling factor in original direction
+ -
+ name: tcp-wscale-reply
+ type: u8
+ doc: window scaling factor in reply direction
+ -
+ name: tcp-flags-original
+ type: binary
+ struct: nf-ct-tcp-flags-mask
+ -
+ name: tcp-flags-reply
+ type: binary
+ struct: nf-ct-tcp-flags-mask
+ -
+ name: protoinfo-dccp-attrs
+ attributes:
+ -
+ name: dccp-state
+ type: u8
+ doc: dccp connection state
+ -
+ name: dccp-role
+ type: u8
+ -
+ name: dccp-handshake-seq
+ type: u64
+ byte-order: big-endian
+ -
+ name: dccp-pad
+ type: pad
+ -
+ name: protoinfo-sctp-attrs
+ attributes:
+ -
+ name: sctp-state
+ type: u8
+ doc: sctp connection state
+ enum: nf-ct-sctp-state
+ -
+ name: vtag-original
+ type: u32
+ byte-order: big-endian
+ -
+ name: vtag-reply
+ type: u32
+ byte-order: big-endian
+ -
+ name: protoinfo-attrs
+ attributes:
+ -
+ name: protoinfo-tcp
+ type: nest
+ nested-attributes: protoinfo-tcp-attrs
+ doc: conntrack tcp state information
+ -
+ name: protoinfo-dccp
+ type: nest
+ nested-attributes: protoinfo-dccp-attrs
+ doc: conntrack dccp state information
+ -
+ name: protoinfo-sctp
+ type: nest
+ nested-attributes: protoinfo-sctp-attrs
+ doc: conntrack sctp state information
+ -
+ name: help-attrs
+ attributes:
+ -
+ name: help-name
+ type: string
+ doc: helper name
+ -
+ name: nat-proto-attrs
+ attributes:
+ -
+ name: nat-port-min
+ type: u16
+ byte-order: big-endian
+ -
+ name: nat-port-max
+ type: u16
+ byte-order: big-endian
+ -
+ name: nat-attrs
+ attributes:
+ -
+ name: nat-v4-minip
+ type: u32
+ byte-order: big-endian
+ -
+ name: nat-v4-maxip
+ type: u32
+ byte-order: big-endian
+ -
+ name: nat-v6-minip
+ type: binary
+ -
+ name: nat-v6-maxip
+ type: binary
+ -
+ name: nat-proto
+ type: nest
+ nested-attributes: nat-proto-attrs
+ -
+ name: seqadj-attrs
+ attributes:
+ -
+ name: correction-pos
+ type: u32
+ byte-order: big-endian
+ -
+ name: offset-before
+ type: u32
+ byte-order: big-endian
+ -
+ name: offset-after
+ type: u32
+ byte-order: big-endian
+ -
+ name: secctx-attrs
+ attributes:
+ -
+ name: secctx-name
+ type: string
+ -
+ name: synproxy-attrs
+ attributes:
+ -
+ name: isn
+ type: u32
+ byte-order: big-endian
+ -
+ name: its
+ type: u32
+ byte-order: big-endian
+ -
+ name: tsoff
+ type: u32
+ byte-order: big-endian
+ -
+ name: conntrack-attrs
+ attributes:
+ -
+ name: tuple-orig
+ type: nest
+ nested-attributes: tuple-attrs
+ doc: conntrack l3+l4 protocol information, original direction
+ -
+ name: tuple-reply
+ type: nest
+ nested-attributes: tuple-attrs
+ doc: conntrack l3+l4 protocol information, reply direction
+ -
+ name: status
+ type: u32
+ byte-order: big-endian
+ enum: nf-ct-status
+ enum-as-flags: true
+ doc: conntrack flag bits
+ -
+ name: protoinfo
+ type: nest
+ nested-attributes: protoinfo-attrs
+ -
+ name: help
+ type: nest
+ nested-attributes: help-attrs
+ -
+ name: nat-src
+ type: nest
+ nested-attributes: nat-attrs
+ -
+ name: timeout
+ type: u32
+ byte-order: big-endian
+ -
+ name: mark
+ type: u32
+ byte-order: big-endian
+ -
+ name: counters-orig
+ type: nest
+ nested-attributes: counter-attrs
+ -
+ name: counters-reply
+ type: nest
+ nested-attributes: counter-attrs
+ -
+ name: use
+ type: u32
+ byte-order: big-endian
+ -
+ name: id
+ type: u32
+ byte-order: big-endian
+ -
+ name: nat-dst
+ type: nest
+ nested-attributes: nat-attrs
+ -
+ name: tuple-master
+ type: nest
+ nested-attributes: tuple-attrs
+ -
+ name: seq-adj-orig
+ type: nest
+ nested-attributes: seqadj-attrs
+ -
+ name: seq-adj-reply
+ type: nest
+ nested-attributes: seqadj-attrs
+ -
+ name: secmark
+ type: binary
+ doc: obsolete
+ -
+ name: zone
+ type: u16
+ byte-order: big-endian
+ doc: conntrack zone id
+ -
+ name: secctx
+ type: nest
+ nested-attributes: secctx-attrs
+ -
+ name: timestamp
+ type: u64
+ byte-order: big-endian
+ -
+ name: mark-mask
+ type: u32
+ byte-order: big-endian
+ -
+ name: labels
+ type: binary
+ -
+ name: labels-mask
+ type: binary
+ -
+ name: synproxy
+ type: nest
+ nested-attributes: synproxy-attrs
+ -
+ name: filter
+ type: nest
+ nested-attributes: tuple-attrs
+ -
+ name: status-mask
+ type: u32
+ byte-order: big-endian
+ enum: nf-ct-status
+ enum-as-flags: true
+ doc: conntrack flag bits to change
+ -
+ name: timestamp-event
+ type: u64
+ byte-order: big-endian
+ -
+ name: conntrack-stats-attrs
+ attributes:
+ -
+ name: searched
+ type: u32
+ byte-order: big-endian
+ doc: obsolete
+ -
+ name: found
+ type: u32
+ byte-order: big-endian
+ -
+ name: new
+ type: u32
+ byte-order: big-endian
+ doc: obsolete
+ -
+ name: invalid
+ type: u32
+ byte-order: big-endian
+ doc: obsolete
+ -
+ name: ignore
+ type: u32
+ byte-order: big-endian
+ doc: obsolete
+ -
+ name: delete
+ type: u32
+ byte-order: big-endian
+ doc: obsolete
+ -
+ name: delete-list
+ type: u32
+ byte-order: big-endian
+ doc: obsolete
+ -
+ name: insert
+ type: u32
+ byte-order: big-endian
+ -
+ name: insert-failed
+ type: u32
+ byte-order: big-endian
+ -
+ name: drop
+ type: u32
+ byte-order: big-endian
+ -
+ name: early-drop
+ type: u32
+ byte-order: big-endian
+ -
+ name: error
+ type: u32
+ byte-order: big-endian
+ -
+ name: search-restart
+ type: u32
+ byte-order: big-endian
+ -
+ name: clash-resolve
+ type: u32
+ byte-order: big-endian
+ -
+ name: chain-toolong
+ type: u32
+ byte-order: big-endian
+
+operations:
+ enum-model: directional
+ list:
+ -
+ name: get
+ doc: get / dump entries
+ attribute-set: conntrack-attrs
+ fixed-header: nfgenmsg
+ do:
+ request:
+ value: 0x101
+ attributes:
+ - tuple-orig
+ - tuple-reply
+ - zone
+ reply:
+ value: 0x100
+ attributes:
+ - tuple-orig
+ - tuple-reply
+ - status
+ - protoinfo
+ - help
+ - nat-src
+ - nat-dst
+ - timeout
+ - mark
+ - counters-orig
+ - counters-reply
+ - use
+ - id
+ - nat-dst
+ - tuple-master
+ - seq-adj-orig
+ - seq-adj-reply
+ - zone
+ - secctx
+ - labels
+ - synproxy
+ dump:
+ request:
+ value: 0x101
+ attributes:
+ - mark
+ - filter
+ - status
+ - zone
+ reply:
+ value: 0x100
+ attributes:
+ - tuple-orig
+ - tuple-reply
+ - status
+ - protoinfo
+ - help
+ - nat-src
+ - nat-dst
+ - timeout
+ - mark
+ - counters-orig
+ - counters-reply
+ - use
+ - id
+ - nat-dst
+ - tuple-master
+ - seq-adj-orig
+ - seq-adj-reply
+ - zone
+ - secctx
+ - labels
+ - synproxy
+ -
+ name: get-stats
+ doc: dump pcpu conntrack stats
+ attribute-set: conntrack-stats-attrs
+ fixed-header: nfgenmsg
+ dump:
+ request:
+ value: 0x104
+ reply:
+ value: 0x104
+ attributes:
+ - searched
+ - found
+ - insert
+ - insert-failed
+ - drop
+ - early-drop
+ - error
+ - search-restart
+ - clash-resolve
+ - chain-toolong
diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml
new file mode 100644
index 000000000000..837112da6738
--- /dev/null
+++ b/Documentation/netlink/specs/devlink.yaml
@@ -0,0 +1,2338 @@
+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
+---
+name: devlink
+
+protocol: genetlink-legacy
+
+doc: Partial family for Devlink.
+
+definitions:
+ -
+ type: enum
+ name: sb-pool-type
+ entries:
+ -
+ name: ingress
+ -
+ name: egress
+ -
+ type: enum
+ name: port-type
+ entries:
+ -
+ name: notset
+ -
+ name: auto
+ -
+ name: eth
+ -
+ name: ib
+ -
+ type: enum
+ name: port-flavour
+ entries:
+ -
+ name: physical
+ -
+ name: cpu
+ -
+ name: dsa
+ -
+ name: pci-pf
+ -
+ name: pci-vf
+ -
+ name: virtual
+ -
+ name: unused
+ -
+ name: pci-sf
+ -
+ type: enum
+ name: port-fn-state
+ entries:
+ -
+ name: inactive
+ -
+ name: active
+ -
+ type: enum
+ name: port-fn-opstate
+ entries:
+ -
+ name: detached
+ -
+ name: attached
+ -
+ type: enum
+ name: port-fn-attr-cap
+ entries:
+ -
+ name: roce-bit
+ -
+ name: migratable-bit
+ -
+ name: ipsec-crypto-bit
+ -
+ name: ipsec-packet-bit
+ -
+ type: enum
+ name: rate-type
+ entries:
+ -
+ name: leaf
+ -
+ name: node
+ -
+ type: enum
+ name: sb-threshold-type
+ entries:
+ -
+ name: static
+ -
+ name: dynamic
+ -
+ type: enum
+ name: eswitch-mode
+ entries:
+ -
+ name: legacy
+ -
+ name: switchdev
+ -
+ name: switchdev-inactive
+ -
+ type: enum
+ name: eswitch-inline-mode
+ entries:
+ -
+ name: none
+ -
+ name: link
+ -
+ name: network
+ -
+ name: transport
+ -
+ type: enum
+ name: eswitch-encap-mode
+ entries:
+ -
+ name: none
+ -
+ name: basic
+ -
+ type: enum
+ name: dpipe-header-id
+ entries:
+ -
+ name: ethernet
+ -
+ name: ipv4
+ -
+ name: ipv6
+ -
+ type: enum
+ name: dpipe-match-type
+ entries:
+ -
+ name: field-exact
+ -
+ type: enum
+ name: dpipe-action-type
+ entries:
+ -
+ name: field-modify
+ -
+ type: enum
+ name: dpipe-field-mapping-type
+ entries:
+ -
+ name: none
+ -
+ name: ifindex
+ -
+ type: enum
+ name: resource-unit
+ entries:
+ -
+ name: entry
+ -
+ type: enum
+ name: reload-action
+ entries:
+ -
+ name: driver-reinit
+ value: 1
+ -
+ name: fw-activate
+ -
+ type: enum
+ name: param-cmode
+ entries:
+ -
+ name: runtime
+ -
+ name: driverinit
+ -
+ name: permanent
+ -
+ type: enum
+ name: flash-overwrite
+ entries:
+ -
+ name: settings-bit
+ -
+ name: identifiers-bit
+ -
+ type: enum
+ name: trap-action
+ entries:
+ -
+ name: drop
+ -
+ name: trap
+ -
+ name: mirror
+ -
+ type: enum
+ name: trap-type
+ entries:
+ -
+ name: drop
+ -
+ name: exception
+ -
+ name: control
+ -
+ type: enum
+ name: var-attr-type
+ entries:
+ -
+ name: u8
+ value: 1
+ -
+ name: u16
+ -
+ name: u32
+ -
+ name: u64
+ -
+ name: string
+ -
+ name: flag
+ -
+ name: nul-string
+ value: 10
+ -
+ name: binary
+ -
+ name: rate-tc-index-max
+ type: const
+ value: 7
+
+attribute-sets:
+ -
+ name: devlink
+ name-prefix: devlink-attr-
+ attributes:
+ -
+ name: bus-name
+ type: string
+ value: 1
+ -
+ name: dev-name
+ type: string
+ -
+ name: port-index
+ type: u32
+ -
+ name: port-type
+ type: u16
+ enum: port-type
+ -
+ name: port-desired-type
+ type: u16
+ -
+ name: port-netdev-ifindex
+ type: u32
+ -
+ name: port-netdev-name
+ type: string
+ -
+ name: port-ibdev-name
+ type: string
+ -
+ name: port-split-count
+ type: u32
+ -
+ name: port-split-group
+ type: u32
+ -
+ name: sb-index
+ type: u32
+ -
+ name: sb-size
+ type: u32
+ -
+ name: sb-ingress-pool-count
+ type: u16
+ -
+ name: sb-egress-pool-count
+ type: u16
+ -
+ name: sb-ingress-tc-count
+ type: u16
+ -
+ name: sb-egress-tc-count
+ type: u16
+ -
+ name: sb-pool-index
+ type: u16
+ -
+ name: sb-pool-type
+ type: u8
+ enum: sb-pool-type
+ -
+ name: sb-pool-size
+ type: u32
+ -
+ name: sb-pool-threshold-type
+ type: u8
+ enum: sb-threshold-type
+ -
+ name: sb-threshold
+ type: u32
+ -
+ name: sb-tc-index
+ type: u16
+ -
+ name: sb-occ-cur
+ type: u32
+ -
+ name: sb-occ-max
+ type: u32
+ -
+ name: eswitch-mode
+ type: u16
+ enum: eswitch-mode
+ -
+ name: eswitch-inline-mode
+ type: u8
+ enum: eswitch-inline-mode
+ -
+ name: dpipe-tables
+ type: nest
+ nested-attributes: dl-dpipe-tables
+ -
+ name: dpipe-table
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-table
+ -
+ name: dpipe-table-name
+ type: string
+ -
+ name: dpipe-table-size
+ type: u64
+ -
+ name: dpipe-table-matches
+ type: nest
+ nested-attributes: dl-dpipe-table-matches
+ -
+ name: dpipe-table-actions
+ type: nest
+ nested-attributes: dl-dpipe-table-actions
+ -
+ name: dpipe-table-counters-enabled
+ type: u8
+ -
+ name: dpipe-entries
+ type: nest
+ nested-attributes: dl-dpipe-entries
+ -
+ name: dpipe-entry
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-entry
+ -
+ name: dpipe-entry-index
+ type: u64
+ -
+ name: dpipe-entry-match-values
+ type: nest
+ nested-attributes: dl-dpipe-entry-match-values
+ -
+ name: dpipe-entry-action-values
+ type: nest
+ nested-attributes: dl-dpipe-entry-action-values
+ -
+ name: dpipe-entry-counter
+ type: u64
+ -
+ name: dpipe-match
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-match
+ -
+ name: dpipe-match-value
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-match-value
+ -
+ name: dpipe-match-type
+ type: u32
+ enum: dpipe-match-type
+ -
+ name: dpipe-action
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-action
+ -
+ name: dpipe-action-value
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-action-value
+ -
+ name: dpipe-action-type
+ type: u32
+ enum: dpipe-action-type
+ -
+ name: dpipe-value
+ type: binary
+ -
+ name: dpipe-value-mask
+ type: binary
+ -
+ name: dpipe-value-mapping
+ type: u32
+ -
+ name: dpipe-headers
+ type: nest
+ nested-attributes: dl-dpipe-headers
+ -
+ name: dpipe-header
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-header
+ -
+ name: dpipe-header-name
+ type: string
+ -
+ name: dpipe-header-id
+ type: u32
+ enum: dpipe-header-id
+ -
+ name: dpipe-header-fields
+ type: nest
+ nested-attributes: dl-dpipe-header-fields
+ -
+ name: dpipe-header-global
+ type: u8
+ -
+ name: dpipe-header-index
+ type: u32
+ -
+ name: dpipe-field
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-dpipe-field
+ -
+ name: dpipe-field-name
+ type: string
+ -
+ name: dpipe-field-id
+ type: u32
+ -
+ name: dpipe-field-bitwidth
+ type: u32
+ -
+ name: dpipe-field-mapping-type
+ type: u32
+ enum: dpipe-field-mapping-type
+ -
+ name: pad
+ type: pad
+ -
+ name: eswitch-encap-mode
+ type: u8
+ enum: eswitch-encap-mode
+ -
+ name: resource-list
+ type: nest
+ nested-attributes: dl-resource-list
+ -
+ name: resource
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-resource
+ -
+ name: resource-name
+ type: string
+ -
+ name: resource-id
+ type: u64
+ -
+ name: resource-size
+ type: u64
+ -
+ name: resource-size-new
+ type: u64
+ -
+ name: resource-size-valid
+ type: u8
+ -
+ name: resource-size-min
+ type: u64
+ -
+ name: resource-size-max
+ type: u64
+ -
+ name: resource-size-gran
+ type: u64
+ -
+ name: resource-unit
+ type: u8
+ enum: resource-unit
+ -
+ name: resource-occ
+ type: u64
+ -
+ name: dpipe-table-resource-id
+ type: u64
+ -
+ name: dpipe-table-resource-units
+ type: u64
+ -
+ name: port-flavour
+ type: u16
+ enum: port-flavour
+ -
+ name: port-number
+ type: u32
+ -
+ name: port-split-subport-number
+ type: u32
+ -
+ name: param
+ type: nest
+ nested-attributes: dl-param
+ -
+ name: param-name
+ type: string
+ -
+ name: param-generic
+ type: flag
+ -
+ name: param-type
+ type: u8
+ enum: var-attr-type
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: param-value-cmode
+ type: u8
+ enum: param-cmode
+ value: 87
+ -
+ name: region-name
+ type: string
+ -
+ name: region-size
+ type: u64
+ -
+ name: region-snapshots
+ type: nest
+ nested-attributes: dl-region-snapshots
+ -
+ name: region-snapshot
+ type: nest
+ nested-attributes: dl-region-snapshot
+ -
+ name: region-snapshot-id
+ type: u32
+ -
+ name: region-chunks
+ type: nest
+ nested-attributes: dl-region-chunks
+ -
+ name: region-chunk
+ type: nest
+ nested-attributes: dl-region-chunk
+ -
+ name: region-chunk-data
+ type: binary
+ -
+ name: region-chunk-addr
+ type: u64
+ -
+ name: region-chunk-len
+ type: u64
+ -
+ name: info-driver-name
+ type: string
+ -
+ name: info-serial-number
+ type: string
+ -
+ name: info-version-fixed
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-info-version
+ -
+ name: info-version-running
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-info-version
+ -
+ name: info-version-stored
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-info-version
+ -
+ name: info-version-name
+ type: string
+ -
+ name: info-version-value
+ type: string
+ -
+ name: sb-pool-cell-size
+ type: u32
+ -
+ name: fmsg
+ type: nest
+ nested-attributes: dl-fmsg
+ -
+ name: fmsg-obj-nest-start
+ type: flag
+ -
+ name: fmsg-pair-nest-start
+ type: flag
+ -
+ name: fmsg-arr-nest-start
+ type: flag
+ -
+ name: fmsg-nest-end
+ type: flag
+ -
+ name: fmsg-obj-name
+ type: string
+ -
+ name: fmsg-obj-value-type
+ type: u8
+ enum: var-attr-type
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: health-reporter
+ type: nest
+ value: 114
+ nested-attributes: dl-health-reporter
+ -
+ name: health-reporter-name
+ type: string
+ -
+ name: health-reporter-state
+ type: u8
+ -
+ name: health-reporter-err-count
+ type: u64
+ -
+ name: health-reporter-recover-count
+ type: u64
+ -
+ name: health-reporter-dump-ts
+ type: u64
+ -
+ name: health-reporter-graceful-period
+ type: u64
+ -
+ name: health-reporter-auto-recover
+ type: u8
+ -
+ name: flash-update-file-name
+ type: string
+ -
+ name: flash-update-component
+ type: string
+ -
+ name: flash-update-status-msg
+ type: string
+ -
+ name: flash-update-status-done
+ type: u64
+ -
+ name: flash-update-status-total
+ type: u64
+ -
+ name: port-pci-pf-number
+ type: u16
+ -
+ name: port-pci-vf-number
+ type: u16
+ -
+ name: stats
+ type: nest
+ nested-attributes: dl-attr-stats
+ -
+ name: trap-name
+ type: string
+ -
+ name: trap-action
+ type: u8
+ enum: trap-action
+ -
+ name: trap-type
+ type: u8
+ enum: trap-type
+ -
+ name: trap-generic
+ type: flag
+ -
+ name: trap-metadata
+ type: nest
+ nested-attributes: dl-trap-metadata
+ -
+ name: trap-group-name
+ type: string
+ -
+ name: reload-failed
+ type: u8
+ -
+ name: health-reporter-dump-ts-ns
+ type: u64
+ -
+ name: netns-fd
+ type: u32
+ -
+ name: netns-pid
+ type: u32
+ -
+ name: netns-id
+ type: u32
+ -
+ name: health-reporter-auto-dump
+ type: u8
+ -
+ name: trap-policer-id
+ type: u32
+ -
+ name: trap-policer-rate
+ type: u64
+ -
+ name: trap-policer-burst
+ type: u64
+ -
+ name: port-function
+ type: nest
+ nested-attributes: dl-port-function
+ -
+ name: info-board-serial-number
+ type: string
+ -
+ name: port-lanes
+ type: u32
+ -
+ name: port-splittable
+ type: u8
+ -
+ name: port-external
+ type: u8
+ -
+ name: port-controller-number
+ type: u32
+ -
+ name: flash-update-status-timeout
+ type: u64
+ -
+ name: flash-update-overwrite-mask
+ type: bitfield32
+ enum: flash-overwrite
+ enum-as-flags: true
+ -
+ name: reload-action
+ type: u8
+ enum: reload-action
+ -
+ name: reload-actions-performed
+ type: bitfield32
+ enum: reload-action
+ enum-as-flags: true
+ -
+ name: reload-limits
+ type: bitfield32
+ enum: reload-action
+ enum-as-flags: true
+ -
+ name: dev-stats
+ type: nest
+ nested-attributes: dl-dev-stats
+ -
+ name: reload-stats
+ type: nest
+ nested-attributes: dl-reload-stats
+ -
+ name: reload-stats-entry
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-reload-stats-entry
+ -
+ name: reload-stats-limit
+ type: u8
+ -
+ name: reload-stats-value
+ type: u32
+ -
+ name: remote-reload-stats
+ type: nest
+ nested-attributes: dl-reload-stats
+ -
+ name: reload-action-info
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-reload-act-info
+ -
+ name: reload-action-stats
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-reload-act-stats
+ -
+ name: port-pci-sf-number
+ type: u32
+ -
+ name: rate-type
+ type: u16
+ enum: rate-type
+ -
+ name: rate-tx-share
+ type: u64
+ -
+ name: rate-tx-max
+ type: u64
+ -
+ name: rate-node-name
+ type: string
+ -
+ name: rate-parent-node-name
+ type: string
+ -
+ name: region-max-snapshots
+ type: u32
+ -
+ name: linecard-index
+ type: u32
+ -
+ name: linecard-state
+ type: u8
+ -
+ name: linecard-type
+ type: string
+ -
+ name: linecard-supported-types
+ type: nest
+ nested-attributes: dl-linecard-supported-types
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: selftests
+ type: nest
+ value: 176
+ nested-attributes: dl-selftest-id
+ -
+ name: rate-tx-priority
+ type: u32
+ -
+ name: rate-tx-weight
+ type: u32
+ -
+ name: region-direct
+ type: flag
+ -
+ name: rate-tc-bws
+ type: nest
+ multi-attr: true
+ nested-attributes: dl-rate-tc-bws
+ -
+ name: health-reporter-burst-period
+ type: u64
+ doc: Time (in msec) for recoveries before starting the grace period.
+
+ # TODO: fill in the attributes in between
+
+ -
+ name: param-reset-default
+ type: flag
+ doc: Request restoring parameter to its default value.
+ value: 183
+ -
+ name: dl-dev-stats
+ subset-of: devlink
+ attributes:
+ -
+ name: reload-stats
+ -
+ name: remote-reload-stats
+
+ -
+ name: dl-reload-stats
+ subset-of: devlink
+ attributes:
+ -
+ name: reload-action-info
+
+ -
+ name: dl-reload-act-info
+ subset-of: devlink
+ attributes:
+ -
+ name: reload-action
+ -
+ name: reload-action-stats
+
+ -
+ name: dl-reload-act-stats
+ subset-of: devlink
+ attributes:
+ -
+ name: reload-stats-entry
+
+ -
+ name: dl-reload-stats-entry
+ subset-of: devlink
+ attributes:
+ -
+ name: reload-stats-limit
+ -
+ name: reload-stats-value
+
+ -
+ name: dl-info-version
+ subset-of: devlink
+ attributes:
+ -
+ name: info-version-name
+ -
+ name: info-version-value
+
+ -
+ name: dl-port-function
+ name-prefix: devlink-port-fn-attr-
+ attr-max-name: devlink-port-function-attr-max
+ attributes:
+ -
+ name-prefix: devlink-port-function-attr-
+ name: hw-addr
+ type: binary
+ value: 1
+ -
+ name: state
+ type: u8
+ enum: port-fn-state
+ -
+ name: opstate
+ type: u8
+ enum: port-fn-opstate
+ -
+ name: caps
+ type: bitfield32
+ enum: port-fn-attr-cap
+ enum-as-flags: true
+
+ -
+ name: dl-dpipe-tables
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-table
+
+ -
+ name: dl-dpipe-table
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-table-name
+ -
+ name: dpipe-table-size
+ -
+ name: dpipe-table-name
+ -
+ name: dpipe-table-size
+ -
+ name: dpipe-table-matches
+ -
+ name: dpipe-table-actions
+ -
+ name: dpipe-table-counters-enabled
+ -
+ name: dpipe-table-resource-id
+ -
+ name: dpipe-table-resource-units
+
+ -
+ name: dl-dpipe-table-matches
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-match
+
+ -
+ name: dl-dpipe-table-actions
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-action
+
+ -
+ name: dl-dpipe-entries
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-entry
+
+ -
+ name: dl-dpipe-entry
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-entry-index
+ -
+ name: dpipe-entry-match-values
+ -
+ name: dpipe-entry-action-values
+ -
+ name: dpipe-entry-counter
+
+ -
+ name: dl-dpipe-entry-match-values
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-match-value
+
+ -
+ name: dl-dpipe-entry-action-values
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-action-value
+
+ -
+ name: dl-dpipe-match
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-match-type
+ -
+ name: dpipe-header-id
+ -
+ name: dpipe-header-global
+ -
+ name: dpipe-header-index
+ -
+ name: dpipe-field-id
+
+ -
+ name: dl-dpipe-match-value
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-match
+ -
+ name: dpipe-value
+ -
+ name: dpipe-value-mask
+ -
+ name: dpipe-value-mapping
+
+ -
+ name: dl-dpipe-action
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-action-type
+ -
+ name: dpipe-header-id
+ -
+ name: dpipe-header-global
+ -
+ name: dpipe-header-index
+ -
+ name: dpipe-field-id
+
+ -
+ name: dl-dpipe-action-value
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-action
+ -
+ name: dpipe-value
+ -
+ name: dpipe-value-mask
+ -
+ name: dpipe-value-mapping
+
+ -
+ name: dl-dpipe-headers
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-header
+
+ -
+ name: dl-dpipe-header
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-header-name
+ -
+ name: dpipe-header-id
+ -
+ name: dpipe-header-global
+ -
+ name: dpipe-header-fields
+
+ -
+ name: dl-dpipe-header-fields
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-field
+
+ -
+ name: dl-dpipe-field
+ subset-of: devlink
+ attributes:
+ -
+ name: dpipe-field-name
+ -
+ name: dpipe-field-id
+ -
+ name: dpipe-field-bitwidth
+ -
+ name: dpipe-field-mapping-type
+
+ -
+ name: dl-resource
+ subset-of: devlink
+ attributes:
+ # -
+ # name: resource-list
+ # This is currently unsupported due to circular dependency
+ -
+ name: resource-name
+ -
+ name: resource-id
+ -
+ name: resource-size
+ -
+ name: resource-size-new
+ -
+ name: resource-size-valid
+ -
+ name: resource-size-min
+ -
+ name: resource-size-max
+ -
+ name: resource-size-gran
+ -
+ name: resource-unit
+ -
+ name: resource-occ
+
+ -
+ name: dl-resource-list
+ subset-of: devlink
+ attributes:
+ -
+ name: resource
+
+ -
+ name: dl-param
+ subset-of: devlink
+ attributes:
+ -
+ name: param-name
+ -
+ name: param-generic
+ -
+ name: param-type
+
+ # TODO: fill in the attribute param-value-list
+
+ -
+ name: dl-region-snapshots
+ subset-of: devlink
+ attributes:
+ -
+ name: region-snapshot
+
+ -
+ name: dl-region-snapshot
+ subset-of: devlink
+ attributes:
+ -
+ name: region-snapshot-id
+
+ -
+ name: dl-region-chunks
+ subset-of: devlink
+ attributes:
+ -
+ name: region-chunk
+
+ -
+ name: dl-region-chunk
+ subset-of: devlink
+ attributes:
+ -
+ name: region-chunk-data
+ -
+ name: region-chunk-addr
+
+ -
+ name: dl-fmsg
+ subset-of: devlink
+ attributes:
+ -
+ name: fmsg-obj-nest-start
+ -
+ name: fmsg-pair-nest-start
+ -
+ name: fmsg-arr-nest-start
+ -
+ name: fmsg-nest-end
+ -
+ name: fmsg-obj-name
+
+ -
+ name: dl-health-reporter
+ subset-of: devlink
+ attributes:
+ -
+ name: health-reporter-name
+ -
+ name: health-reporter-state
+ -
+ name: health-reporter-err-count
+ -
+ name: health-reporter-recover-count
+ -
+ name: health-reporter-graceful-period
+ -
+ name: health-reporter-auto-recover
+ -
+ name: health-reporter-dump-ts
+ -
+ name: health-reporter-dump-ts-ns
+ -
+ name: health-reporter-auto-dump
+ -
+ name: health-reporter-burst-period
+
+ -
+ name: dl-attr-stats
+ name-prefix: devlink-attr-
+ attributes:
+ - name: stats-rx-packets
+ type: u64
+ value: 0
+ -
+ name: stats-rx-bytes
+ type: u64
+ -
+ name: stats-rx-dropped
+ type: u64
+
+ -
+ name: dl-trap-metadata
+ name-prefix: devlink-attr-
+ attributes:
+ -
+ name: trap-metadata-type-in-port
+ type: flag
+ value: 0
+ -
+ name: trap-metadata-type-fa-cookie
+ type: flag
+
+ -
+ name: dl-linecard-supported-types
+ subset-of: devlink
+ attributes:
+ -
+ name: linecard-type
+
+ -
+ name: dl-selftest-id
+ name-prefix: devlink-attr-selftest-id-
+ attributes:
+ -
+ name: flash
+ type: flag
+ -
+ name: dl-rate-tc-bws
+ name-prefix: devlink-rate-tc-attr-
+ attributes:
+ -
+ name: index
+ type: u8
+ checks:
+ max: rate-tc-index-max
+ -
+ name: bw
+ type: u32
+ doc: |
+ Specifies the bandwidth share assigned to the Traffic Class.
+ The bandwidth for the traffic class is determined
+ in proportion to the sum of the shares of all configured classes.
+
+operations:
+ enum-model: directional
+ list:
+ -
+ name: get
+ doc: Get devlink instances.
+ attribute-set: devlink
+ dont-validate: [strict, dump]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 1
+ attributes: &dev-id-attrs
+ - bus-name
+ - dev-name
+ reply: &get-reply
+ value: 3
+ attributes:
+ - bus-name
+ - dev-name
+ - reload-failed
+ - dev-stats
+ dump:
+ reply: *get-reply
+
+ -
+ name: port-get
+ doc: Get devlink port instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ value: 5
+ attributes: &port-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ reply:
+ value: 7
+ attributes: *port-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply:
+ value: 3 # due to a bug, port dump returns DEVLINK_CMD_NEW
+ attributes: *port-id-attrs
+
+ -
+ name: port-set
+ doc: Set devlink port instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - port-index
+ - port-type
+ - port-function
+
+ -
+ name: port-new
+ doc: Create devlink port instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - port-index
+ - port-flavour
+ - port-pci-pf-number
+ - port-pci-sf-number
+ - port-controller-number
+ reply:
+ value: 7
+ attributes: *port-id-attrs
+
+ -
+ name: port-del
+ doc: Delete devlink port instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ attributes: *port-id-attrs
+
+ -
+ name: port-split
+ doc: Split devlink port instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - port-index
+ - port-split-count
+
+ -
+ name: port-unsplit
+ doc: Unplit devlink port instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ attributes: *port-id-attrs
+
+ -
+ name: sb-get
+ doc: Get shared buffer instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 11
+ attributes: &sb-id-attrs
+ - bus-name
+ - dev-name
+ - sb-index
+ reply: &sb-get-reply
+ value: 13
+ attributes: *sb-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-get-reply
+
+ -
+ name: sb-pool-get
+ doc: Get shared buffer pool instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 15
+ attributes: &sb-pool-id-attrs
+ - bus-name
+ - dev-name
+ - sb-index
+ - sb-pool-index
+ reply: &sb-pool-get-reply
+ value: 17
+ attributes: *sb-pool-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-pool-get-reply
+
+ -
+ name: sb-pool-set
+ doc: Set shared buffer pool instances.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - sb-index
+ - sb-pool-index
+ - sb-pool-threshold-type
+ - sb-pool-size
+
+ -
+ name: sb-port-pool-get
+ doc: Get shared buffer port-pool combinations and threshold.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ value: 19
+ attributes: &sb-port-pool-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - sb-index
+ - sb-pool-index
+ reply: &sb-port-pool-get-reply
+ value: 21
+ attributes: *sb-port-pool-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-port-pool-get-reply
+
+ -
+ name: sb-port-pool-set
+ doc: Set shared buffer port-pool combinations and threshold.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - port-index
+ - sb-index
+ - sb-pool-index
+ - sb-threshold
+
+ -
+ name: sb-tc-pool-bind-get
+ doc: Get shared buffer port-TC to pool bindings and threshold.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ value: 23
+ attributes: &sb-tc-pool-bind-id-attrs
+ - bus-name
+ - dev-name
+ - port-index
+ - sb-index
+ - sb-pool-type
+ - sb-tc-index
+ reply: &sb-tc-pool-bind-get-reply
+ value: 25
+ attributes: *sb-tc-pool-bind-id-attrs
+ dump:
+ request:
+ attributes: *dev-id-attrs
+ reply: *sb-tc-pool-bind-get-reply
+
+ -
+ name: sb-tc-pool-bind-set
+ doc: Set shared buffer port-TC to pool bindings and threshold.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit-port
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - port-index
+ - sb-index
+ - sb-pool-index
+ - sb-pool-type
+ - sb-tc-index
+ - sb-threshold
+
+ -
+ name: sb-occ-snapshot
+ doc: Take occupancy snapshot of shared buffer.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ value: 27
+ attributes:
+ - bus-name
+ - dev-name
+ - sb-index
+
+ -
+ name: sb-occ-max-clear
+ doc: Clear occupancy watermarks of shared buffer.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - sb-index
+
+ -
+ name: eswitch-get
+ doc: Get eswitch attributes.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes: *dev-id-attrs
+ reply:
+ value: 29
+ attributes: &eswitch-attrs
+ - bus-name
+ - dev-name
+ - eswitch-mode
+ - eswitch-inline-mode
+ - eswitch-encap-mode
+
+ -
+ name: eswitch-set
+ doc: Set eswitch attributes.
+ attribute-set: devlink
+ dont-validate: [strict]
+ flags: [admin-perm]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes: *eswitch-attrs
+
+ -
+ name: dpipe-table-get
+ doc: Get dpipe table attributes.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - dpipe-table-name
+ reply:
+ value: 31
+ attributes:
+ - bus-name
+ - dev-name
+ - dpipe-tables
+
+ -
+ name: dpipe-entries-get
+ doc: Get dpipe entries attributes.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ - dpipe-table-name
+ reply:
+ attributes:
+ - bus-name
+ - dev-name
+ - dpipe-entries
+
+ -
+ name: dpipe-headers-get
+ doc: Get dpipe headers attributes.
+ attribute-set: devlink
+ dont-validate: [strict]
+ do:
+ pre: devlink-nl-pre-doit
+ post: devlink-nl-post-doit
+ request:
+ attributes:
+ - bus-name
+ - dev-name
+ reply:
+ attributes:
+ - bus-name
+ - dev-name
+ - dpipe-headers
+
+ -